作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。

前篇網誌討論的Bulk Migration機制已經是非常好的運作方式，大部分我們客戶使用VMware HCX時就是採用這種方法。但可能就是有些重要虛機不能停機，幾分鐘的中斷都不行。所以除了一台台用vMotion慢慢切換的方法外，可不可以平行地先把多台虛機底層複製到目的端，然後再改用vMotion的方式不停機切換過去呢？

有喔，這邊就是我們接下來討論的Replication Assisted vMotion (RAV) 機制。

Replication Assisted vMotion

RAV運作時，先採用vSphere Replication的技術把來源虛機抄寫到目的端。抄寫完成後進入虛機切換switchover的作業，但此時就改成用vMotion的機制，把底層的儲存異動以及Memory內的資訊送到目的地。在過程當中是可以完全虛機服務不中斷的。 下圖是展示情境，我要利用RAV的機制，將數個虛機由左邊的vSphere環境送到右邊的環境內。

在左邊的vCenter介面內，可以看到web-02-1621 / web-06-1621這兩個虛機，且目前是正常開機運作狀態。

在下圖的HCX介面內，我們選擇了要移轉這兩個虛機，兩個虛機都是開機狀況，且移轉方式選定了要採用Replication Assisted vMotion。

在進行RAV時，同樣也可以選定一段維護時間再來做第二步驟的vMotion切換。但因為RAV本身的設計是不會服務中斷的，因此維護時間的配置就沒有這麼重要。另外，因為這邊是做不停機vMotion，虛機不能重開機，因此在Bulk Migration內可以進行的虛機客製化作業如改IP地址，升級VMTools這些動作，在這邊就不能進行了。

下圖是開始進行RAV作業，本圖的重點是，當有多個虛機進行Replicated Assisted vMotion時，第一階段的虛機複製動作是『同時』進行需求的。依據虛機的大小以及底層網路頻寬會決定移轉作業快慢，但在此階段可以批次、多工地進行移轉作業。

當步驟一的虛機複製完成，就可以立即開始（或在指定的維護時間內）進行步驟二switchover的作業，這邊的作業是將來源端虛機剩餘的儲存以及Memory的資訊，以vMotion的方式轉移目的端，並把來源端關閉。因為是採用vMotion，所以服務不會中斷。

下圖有個重點：在Replication Assisted vMotion的第二階段，如果同時有多個虛機可以進行switchover，此時大家是排隊一個一個來。所以下圖內，web-06-1621的虛機正在進行切換，但是web-02-1621這台則在等。這邊雖然是序列處理，但因為最花時間的底層複製已經在前面階段完成了，因此這邊排一下隊是不會影響太多時間啦。

在作業完成後，右邊的vSphere內可以看到兩個虛機已經在這邊運作了。而且過程當中服務沒有停機喔。

神奇吧～厲害吧～但是當然，RAV會有下列的限制：

  • 與vMotion的限制相同，HW version必須在第9版以上才能提供
  • 只能從舊環境移轉到新環境。由於不停機要求的關係，不能從新環境轉移到早期版本CPU的環境內（除非新環境內有啟用EVC把CPU指令集降版）
  • 最大的限制：這個功能需要HCX Enterprise的授權。這是很多客戶後續無法採用RAV機制的原因。當這邊的限制難以突破時，管理者可能採用的workaround方式就會是選擇大部分的VM採用Bulk Migration的方式移轉，但少部份無法停機的核心重要機器，則採用vMotion的方式來一個個進行。

好的，在前面到現在總共三篇內，我們陸續討論了VMware HCX內不同移轉的方式包含Cold Migration / vMotion / Bulk Migration / Replication Assisted vMotion等。這裡我想用下面的表格來做一個簡單的比較：

本系列到此為止，一直規避了一個問題：如果我們要把虛機在兩個站點間進行移轉，這些虛機接取的底層業務網路要如何處理？如果兩個站點上沒有同樣的業務網路，我們用各種厲害的機制把虛機移轉過去也無法讓業務連通啊？HCX在設計上當然有想到這個問題，因此下篇網誌我們要討論HCX的一個重要底層功能：L2 Network Extension。