![](https://blogs.vmware.com/wp-content/uploads/2023/11/330-1-300x131-1.jpg)
作者: Colin Jao 饒康立 – VMware資深技術顧問,主要負責VMware NSX產品線,目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。
前篇網誌內我們討論了在微分段方案的雙中心/災備規劃內的兩個起始議題:建議採用NSX Multisite架構,並說明了控制層NSX Management Cluster的災備回復時間選擇。本篇網誌我想繼續就資料層虛機相關回復機制做討論。
在NSX Multisite架構內,站點失效時,資料層業務虛機回復機制的選擇有哪些?
雖然不同的文件寫的洋洋灑灑有各式各樣的做法,但整體說來,不出兩種選擇如下:
![](https://blogs.vmware.com/wp-content/uploads/2023/11/330-1.jpg)
基於客戶實際環境的條件限制與預算,如果允許,採用vSphere Stretch Cluster當然是最快最自動最讚的做法。但大部分客戶的選擇仍然會比較偏向採用 SRM (Site Recovery Manager),因為在站點間的線路品質、頻寬費用等要求上遠低於vSphere Stretch Cluster。這也是我們多個客戶實際部署的機制。
NSX環境內已經官方確認能夠搭配SRM做災備復原嗎?
沒有問題,目前的NSX方案(由3.1之後)已經與SRM 完整地進行測試。官方文件如NSX 4.1 Administration Guide也明確列出相關訊息 (https://docs.vmware.com/en/VMware-NSX/4.1/administration/GUID-E1412B0E-A661-4400-AF81-82CC31D73A98.html) 。
- 在NSX控制層部分,各台Manager虛機可以藉由SRM複製到災備中心,並於需要時直接啟動NSX Management Cluster回復,如前篇網誌情境三內所示。
- NSX資料層部分,SRM可以備份各台業務虛機到災備中心,並在NSX Management Cluster回復運作後,將虛機掛回NSX網路。
這裡我想特別 Highlight 一下與分散式防火牆非常相關,SRM可解決的微分段技術問題,SRM架構下雖然主中心與備援中心會對應到不同的vCenter,但在備援回復時,不會修改業務虛機的UUID。這代表了
- 群組 (Group) 內直接以靜態 (static) 方式指定虛機成員時,不會因為虛機透過SRM還原在另一台vCenter上UUID不同,NSX認不得,而造成原本群組內的虛機成員消失
- 相同的原因,群組內直接以動態 (dynamic) 方式以NSX Tag來選擇虛機成員時, NSX Tag與虛機的對應不受影響。不會因為虛機透過SRM還原在另一台vCenter上而失效,造成群組內的虛機成員消失
我們有眾多的客戶採用群組、而非僅用 IP 地址的方式,來配置NSX防火牆;因此SRM方案在備份還原過程中,不會影響到群組物件的設定(而得修改防火牆規則或重新對虛機打Tag)在管理上至為重要。這也是為何我們非常推薦採用SRM作為NSX災備機制選擇的重要原因。
如果不用SRM,可以用其他第三方備份軟體來做災備復原嗎?
先不打官腔說只有SRM+NSX是VMware驗證過的架構這些。如果大家一定要採用其他第三方的備份軟體來做跨Site的虛機災備復原,在微分段情境內最重要需考慮的就是前面提到的虛機UUID問題:
- 復原後的業務虛機是否可以具有與原本相同的UUID,讓NSX Group / Tag的配置在復原的虛機上仍然能夠生效;而不需要在復原流程內,還需要對防火牆與群組的規則進行修改。
其次我們在之前網誌也提到,NSX Manager VM是不能夠被快照的。其他第三方的備份軟體極為可能因為此限制,不能用來備份控制層的NSX Manager虛機,但SRM方案已經被驗證過,能夠正常運作沒有問題。這也是大家可以納入考量的。
綜合以上討論,可否說明NSX搭配SRM來做災備復原的流程大致為何?
我們用一個很典型的案例來進行簡要說明。假設客戶有主備兩中心,距離長因此網路延遲時間過長無法建立vSphere Stretch Cluster,故採用SRM作為備援機制選擇。下圖內,
- 主備兩中心各有自己的vCenter與vSphere資源池
- 管理網路跨中心二層連通。業務網路無二層連通需求。
- 兩個中心的vCenter均連接到同一組NSX Management Cluster(在主中心)
- 主備中心建立相同IP配置的網路環境(用NSX Overlay或實體VLAN網路均可),正常時間,相關網段均僅由主中心進行發布;備援中心內網段未配置虛機也並未對外連接
- 在正常狀況時,透過SRM機制進行三台NSX Manager虛機的備份至災備中心
- 在正常狀況時,透過SRM機制進行業務虛機的備份至災備中心
![](https://blogs.vmware.com/wp-content/uploads/2023/11/330-2.jpg)
在主中心整個站點失效時,管理者需進行
- 由SRM回復機制,於災備中心重新啟動NSX Management Cluster,約需花費20分鐘。完成後,vCenter / vSphere可重新連接至NSX,回復網路部分運作
- 由SRM回復機制,於災備中心重新啟動各業務虛機,需花費時間依據虛機大小、數量、及回復劇本複雜度而定
- 管理者可進行網路部分配置,將完成回復之應用及網段透過路由發布,重新進行運作
![](https://blogs.vmware.com/wp-content/uploads/2023/11/330-3.jpg)
當然上述的流程說明相當簡略,但展示了一種極為典型的有NSX微分段環境的災備環境設計,供大家參考。
在這兩篇網誌我們討論了企業部署了NSX微分段機制,在有多中心運作時的相關考量議題,希望對大家後續的相關規劃有幫助。後續網誌還是繼續專注在微分段,但我們會轉向於功能面常碰到的相關問題討論。