運行中虛機跨vSphere傳輸　大量移轉/RAV技術搞定

前篇文章（https://pse.is/4bjsvg）與大家進行VMware HCX的方案簡述及基礎效益說明，並討論了採用Cold Migration、vMotion的移轉方式，但這兩種方式有個大弱點：即使管理者同時選擇多個虛機進行轉移，同時間只能有一個進行作業。此時進行虛機移轉的時間肯定就大幅拉長，而這並非採用VMware HCX時想要達成的效益。所以，接下來在本文想和大家討論真正一般系統管理者採用HCX時會想要用的方式：Bulk Migration與Replication Assisted vMotion。

認識Bulk Migration機制

Bulk Migration底層是採用vSphere Replication技術（再加上廣域網路加速與加密）。管理者一次選擇多個正在運作的虛機，在不影響虛機作業的狀況下，底層啟用Replication將虛機抄寫到另一端。當抄寫完成，可以進入虛機切換的作業，此時HCX會把來源端的原始虛機關閉，而同時將已抄寫到目的端的虛機開啟。並且，管理者可以選擇是要馬上進行轉移，或是在選定的維護時間進行轉移。

這裡想要直接抓圖給大家看並進行說明。圖1所示是展示情境，因為配置的關係，要利用Bulk Migration機制，將數個虛機由右邊的vSphere環境反向送到左邊的環境內。

如圖2所示，在右邊的vCenter介面內，可以看到web-02-1621、web-06-1621這兩個虛機，目前是正常開機運作狀態。

如圖3所示，在HCX介面內選擇了要一次移轉這兩個虛機，兩個虛機都是開機狀況，且移轉方式選定要採用Bulk Migration。

Bulk Migration過程中包含了前期的Replication作業以及後期將目的端複製出的虛機開啟，來源端的虛機關閉。後期的動作因為會有虛機本身的開機關機，虛機的服務會中斷。此時，管理者可能會想要選擇一段維護時間，僅有在這段時間內可以做虛機開關機的移轉作業。如圖4所示，選擇3:30～3:45這段時間可以進行切換作業。

因為作業內允許目的端的虛機開關機，因此除了把指定虛機複製到目的端外，管理者還可以進行一些其他想要做的客製與升級作業。從圖5中可以看到，可以選定對於移轉過去的虛機，MAC Address要不要保留，HW Version與VMTools要不要升版，以及其他類似vCenter內進行Customization Spec的作業。且不僅止於此，對於每個虛機甚至可以進一步設定，在轉移到目的端環境時，要不要進行IP Address、Default GW等等的修改，如圖6所示。

當管理者完成相關設定，就可以開始這次的批次作業了。圖7要請大家注意看的是，當有多個虛機進行Bulk Migration時，這些虛機是「同時」進行需求的複製移轉作業，端看各個虛機的大小以及底層網路頻寬，決定這樣的移轉作業快慢。但重點在於，並不是序列進行（Serialization），一台做完再做另一台。多個虛機是平行處理的。

預設值是當一個虛機複製到目的端完成，就可以開始進行下一階段Switchover的作業。但如同前面討論，此時的動作會造成虛機服務中斷。因此，若有設定一段維護時間，複製完的虛機就會暫停，等待維護時間到達，如圖8所示。

當時間已經到達維護時間，此時就開始進行Switchover切換動作，如圖9所示。

在進行Switchover這個動作時，HCX於Bulk Migration會進行的作業包括：

1. 把來源端的虛機關機。

2. 把目的端的虛機開機。

3. 依據管理者需求，將目的端虛機進行必要的客製化作業，像前面談到的改IP地址、改虛機HW版本，升級VMTools，重新產生SID（Windows）這些作業。依據需要進行的程序，可能會有一次到多次的重開機。

4. HCX確認目的地虛機依據指示正常開啟。如果有出現任何問題（例如目的端資源不夠、虛機開不起等等），此時HCX會重新將來源端的虛機開啟。

如圖10所示，作業完成後，在左邊的vSphere內，可以看到兩個虛機已經在這邊運作了。當然，此時在右邊的環境，就沒有這兩個機器了。

從前面的描述，大家應該可以看到Bulk Migration具有下列的好處，再重新整理如下：

1. 可以一次進行大量虛機批次移轉。虛機複製作業為多台平行進行，加速移轉時間。

2. 可以指定維護時間，虛機在一般時間可以正常提供服務，但此時已經開始進行底層的儲存複製作業。當維護時間到了，底層的拷貝作業也都完成，此時再進行接下來的切換作業。因為在維護時間內，切換時雖然會終止服務，影響也較小。

3. 可以在過程中進行VM的升級，以及網路地址與作業系統的參數修改。

很不錯吧！但畢竟有一個問題，那就是在切換時，同個虛機從來源端關閉，目的端開啟，這中間會有幾分鐘服務中斷。有沒有更完美的做法，先平行地把多台虛機底層複製到目的端，然後再改用vMotion方式讓機器不停機切換過去呢？這種機制就是接下來要介紹的Replication Assisted vMotion（RAV）。

採用Replication Assisted vMotion

Replication Assisted vMotion（RAV）運作時，先採用vSphere Replication技術把來源虛機抄寫到目的端。抄寫完成後，進入虛機切換Switchover的作業，但此時就改用vMotion機制，把底層的儲存異動以及Memory內的資訊送到目的地。在過程當中，可以完全虛機服務不中斷。

圖11是展示情境，此時要利用RAV機制，將數個虛機由左邊的vSphere環境送到右邊的環境內。

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

如圖13所示，在HCX介面中，選擇要移轉這兩個虛機，兩個虛機都是開機狀況，且移轉方式選定了Replication Assisted vMotion。

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

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

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

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

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

有得有失，RAV會有下列的限制：

1. 與vMotion的限制相同，HW Version必須在第9版以上才能提供。

2. 只能從舊環境移轉到新環境。由於不停機要求的關係，不能從新環境轉移到早期版本CPU的環境內（除非新環境內有啟用EVC把CPU指令集降版）。

3. 其中最大的限制是，這個功能需要HCX Enterprise的授權。這是很多客戶後續無法採用RAV機制的原因。當這邊的限制難以突破時，管理者可能採用的Workaround方式就會是選擇大部分的VM採用Bulk Migration方式移轉，但少部分無法停機的核心重要機器，則採用vMotion方式一個個進行。

在前文與本文中，討論了VMware HCX內不同移轉的方式，包含Cold Migration、vMotion、Bulk Migration、Replication Assisted vMotion等，最後用表1來做一個簡單比較。

結語

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

＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞