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

接續前面對於NSX-T Data Center在兩個中心的自動化與手動災備策略介紹，本篇內，我想就幾個常被詢問的問題與大家進行說明：

 

問題：在上述的自動回復架構內，我們可否把NSX Manager一開始就配置在兩個中心內，這樣單中心失效時，不會三個NSX Manager一起失效，控制層仍然可以運作

 

答案是可以，但是沒有效益。自動復原架構內的Stretch Cluster跨兩個中心。假設主中心有兩台Managers，災備中心一台。當主中心失效，兩台Manager同時死掉，此時NSX Management Cluster的Quorum 2+1備援架構仍然會因為只剩一台Manager進入Read-Only鎖定模式。此時，仍然要管理者將三台Manager重新開機後才能恢復服務。

 

如果企業可以有三中心建Stretch Cluster，每個中心內各放一台NSX Manager，Site失效時只會有單台Manager失效，此時才可以確保在單一Site完全失效時，不會有控制層重啟的需求

 

問題：在上述的架構都是討論Active-Standby。我們可否在Active-Active的環境內實作上述NSX-T的回復機制

 

沒有問題，NSX環境內的Multisite Active-Active架構請先參考下圖。

首先，由於兩個站點間有Overlay網路，因此以單一應用來說，虛機要同時跨兩個站點同時運作是沒有問題的，沒有規定只能在單一站點上運作，而有問題時再透過SRM在另一端重啟。因此雖然以單一應用來說我們僅會在單一站點上提供南北向的進出（NSX-T沒有支援Local Egress），但是在運算層，應用可以同時使用到兩邊的vSphere資源。

 

此外，上圖內的藍色 / 綠色大家可視為是兩個不同的應用，藍色應用主要在左邊的站點運作，備援在右邊站點。而綠色應用則相反，主要在右邊站點運作，備援在左邊站點。NSX也可分別對應藍色、綠色應用需求的T0 / T1等網路及安全配置，以前述的自動或手動方式進行災備。

 

問題：前述兩個架構內，都要求兩中心間底層網路開啟至少1700 MTU。如果實際環境內，線路服務商無法提供企業1700 MTU的線路呢？

 

此時我們不會採用上述的自動 / 手動災備架構。在此狀況下，

 

  • 最傳統的災備方式仍然可以做，也就是說主中心 / 災備中心分別建置完全獨立的vSphere / NSX環境，配置各自的網路與安全配置。當災備發生時，以SRM將主中心失效的虛機在災備中心重新開啟，並透過災備劇本進行必要的IP與其他虛機配置修改

 

  • 如在本系列第一篇說明，在NSX-T 3.0與後續的版本會開始支援NSX Federation功能，也就是說我們可以部署多組NSX環境，但透過Federation機制同時將我們需求的網路 / 安全政策同時配置到多個環境上。當此機制可實現後（本文寫作時，仍在Technical Preview階段），我們在Multisite的支援方式就能有更多彈性、更加簡易了。

 

最後，如果前面的討論與示範大家有興趣想了解更多細節，可以另外由下面的連結取得文件與影片參考：

 

  • https://communities.vmware.com/docs/DOC-39405
  • http://iwan.wiki/Disaster_recovery_using_Multisite_(light)_with_NSX-T_2.4

 

希望相關的說明對各位後續就NSX在多站點的架構規劃有幫助。若有進一步問題，也歡迎大家與VMware的業務及技術顧問尋求協助。