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

前篇網誌內我們討論了在微分段方案的雙中心/災備規劃內的兩個起始議題：建議採用NSX Multisite架構，並說明了控制層NSX Management Cluster的災備回復時間選擇。本篇網誌我想繼續就資料層虛機相關回復機制做討論。

在NSX Multisite架構內，站點失效時，資料層業務虛機回復機制的選擇有哪些？

雖然不同的文件寫的洋洋灑灑有各式各樣的做法，但整體說來，不出兩種選擇如下：

基於客戶實際環境的條件限制與預算，如果允許，採用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機制進行業務虛機的備份至災備中心

在主中心整個站點失效時，管理者需進行

  • 由SRM回復機制，於災備中心重新啟動NSX Management Cluster，約需花費20分鐘。完成後，vCenter / vSphere可重新連接至NSX，回復網路部分運作
  • 由SRM回復機制，於災備中心重新啟動各業務虛機，需花費時間依據虛機大小、數量、及回復劇本複雜度而定
  • 管理者可進行網路部分配置，將完成回復之應用及網段透過路由發布，重新進行運作

當然上述的流程說明相當簡略，但展示了一種極為典型的有NSX微分段環境的災備環境設計，供大家參考。

在這兩篇網誌我們討論了企業部署了NSX微分段機制，在有多中心運作時的相關考量議題，希望對大家後續的相關規劃有幫助。後續網誌還是繼續專注在微分段，但我們會轉向於功能面常碰到的相關問題討論。