虛擬雲網路

網路虛擬化NSX 技術文章系列二百: VMware HCX:方案介紹(五)

作者: 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。

相关文章

评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注