本文作者為Howard Marks，他目前正在參與到EMC和NetEX公司有關虛擬機遷移和遠程災備的項目中。
過去幾個月中，我對WAN（廣域網）Vmotion（虛擬機遷移）比較關注。這很大程度上是因為一位客戶問我如何衡量他們的產品使流程改善了多少。我不是唯一一個關注這方面的人，因為思科的OTV和EMC的VPLEX直接針對的就是將虛擬機從一個地方遷移到另一個地方。災難恢復解決方案的目的是最小化災難發生后服務中斷概率和數據丟失概率，而WAN Vmotion和/或帶Hyper-V的WAN Live Migration（WAN實時遷移）可以幫助規避災難。
例如，如果預計未來兩天內有颶風來襲，IT部門可以將虛擬機（VM）從他們的Mobile數據中心遷移到Hattiesburg（密西西比州哈德斯堡）數據中心。
我認為WAN Vmotion要想實用化就必須解決三個不同但相互關聯的問題。第一個就是用戶和/或相連的服務器所在的互聯網網絡必須同時存在于兩個地點。過去20年來，互聯網的專家將所有WAN連接予以路由化，以便防止廣播和生成樹傳輸擠占真正的數據所需要的空間。MPLS（多協議標記交換）和OTV等技術可以在橋接子網的同時過濾掉我們不希望在WAN上傳輸的內容，并確保生成樹不會關閉高速WAN連接。第二個問題是如何壓縮vMotion以便使其不超過可用的帶寬。Riverbed、F5、NetEx等公司可以通過TCP刪除和壓縮等方式來解決這個基本的WAN優化問題
存儲這邊的問題是最復雜的。雖然你可以將虛擬機的磁盤從Mobile遷移到Hattiesburg，但是這是GB/TB級的數據，而且如果你要遷移全部關鍵數據的話，那么天氣預報所提供的兩天預警時間可能是不夠用的。此外，我們在此前還要將一些數據復制到Hattiesburg，因為有一些災難是我們無法預測的。我們真正需要的是兩個不同地點的存儲系統在VMware主機面前提供的是同樣的ID（WWN（全局名）等），這樣當VM從一個地方遷移到另一個地方的時候，它可以從本地存儲系統訪問數據。Compellent Live Volume和HDS（日立數據系統）的HAM可以部分解決這種問題，而EMC的VPLEX采用的方式是最正確的。
通過VPLEX Metro，兩個數據中心的VPLEX設備給它們所管理的LUN（邏輯單元號）提供的是同樣的ID。它們還可以在兩個地方提供一致的高速緩存，在兩個站點之間傳送更新。由于VM不共享VMDK（虛擬磁盤文件），而且每個VM只存在于一個數據中心，因此每個VMDK，或這些VM所占用的磁盤塊，在每個時點上只會被寫入一個數據中心。VPLEX Metro采用的是同步功能，因此它需要限制在60英里的連接范圍內，否則它無法處理更長的連接所帶來的延遲性。
我希望出現異步的VPLEX Geo，這種產品可以工作于更長的距離，這樣你就可以將虛擬機從Mobile遷移到亞特蘭大，因為沒有人真正愿意在這么近的Hattiesburg興建另一座數據中心。然后，我們可以將虛擬機遷移到亞特蘭大，讓VPLEX來緩沖寫入，直到異步復制趕上來為止，然后我們可以強行使兩個陣列之間的復制關系倒過來，比如從生產陣列變成災難恢復陣列，或者反過來，這樣的過程甚至都不需要用戶注意到。EMC承諾會提供這種技術，即使針對的不是EMC自己的磁盤陣列。
