NSX-T的基礎災備策略分成自動化回復與手動回復兩種，上期文章已經介紹過前者，本文將接著說明NSX-T Data Center的手動災備回復機制，先講解執行時需要留意的細節，然後就三個IT管理者常見的疑問來做分析並提出解決對策。
接續前期投稿介紹了在兩個資料中心進行災備時，NSX-T Data Center方案以自動方式切換的架構簡述。但要達成這樣的架構，底層有需要配合的條件，包含企業在兩座資料中心間的延遲時間必須低於10毫秒（ms）、兩中心間需要建置vSphere Stretch Cluster、儲存同步需求頻寬必須夠大等。上述情境如果無法滿足，但企業可以接受用手動的方式來回復，此時下面的第二種機制便可以考慮了。
瞭解手動災備回復機制
在手動回復機制內，因為不像自動回復機制的管理叢集可以跨雙中心建立vSphere Stretch Cluster，因此當主中心失效時，無法依賴vSphere HA，而需要手動在災備中心回復NSX Management Cluster。此時的流程與需要討論的細節如下：
‧此機制內，需要持續透過NSX定期Backup機制，定時將主中心NSX Management Cluster內的配置送往備援中心內的FTP伺服器。
‧在主中心與災備中心的管理網路如果有二層打通，那控制層的回復機制就會變得單純。災備需求發生時，在災備中心將現有的NSX備份透過Restore機制，管理者在同樣的管理網段上可以回復原本三台NSX Managers，且使用一模一樣的IP。當NSX Management Cluster在災備中心重新建立完成後，原本於災備中心這邊的Edge/vSphere Transport Nodes就可以與控制層重新建立連線。
‧一個變數是如果主中心與災備中心的管理網路無法二層打通，兩組管理網段僅有三層連通，此時NSX Managers的回復就無法以同樣IP在災備中心建立。若企業現有架構如此，那麼有三點須注意。第一、在NSX Management Cluster須以API修改「publish_fqdn」參數，要求Edge/vSphere Nodes要以DNS FQDN的方式與NSX Manager連接，而非採用原生的IP方式；第二、災備啟用時，在災備中心以新的網段IP搭配NSX Restore機制回復NSX Management Cluster；第三、修改DNS設定，手動將DNS內各台NSX Manager的紀錄修改為災備中心內的新IP。此時，災備中心這邊的Edge/vSphere Transport Nodes就可與控制層重新建立連線。
‧NSX Edge Cluster這裡的配置方式可以與自動化的配置大致相同。但如果兩個中心之間距離較遠，而且實體網路跨三層，此時T0路由器設計上就不會與自動化配置環境一般，同時跨兩個中心的實體路由器做BGP路由連接。在手動架構內，通常建議先在災備中心預先建立好另一組獨立的T0路由器，並預先建立災備端的南北向BGP路由配置。此時，T0路由器就沒有限制得用Active-Standby模式了。既然會在主中心和災備中心各自建立獨立的T0路由器，這些T0路由器底層可以藉由多台Edge提供與實體網路間的多路徑連接。
‧當主中心失效時，首先完成NSX Management Cluster的回復。接著，管理者「手動」以API或是於UI介面內，將現有的T1路由器由原有的主中心T0，改接到災備中心之前已建置的T0路由器。此時，所有T1下的業務網段就可透過災備區的T0╱實體路由器，取得對外連通了。
‧與自動機制相同，於災備中心在運算層的vSphere資源池，本來的網路配置仍可運作，且在NSX Management Cluster回復╱T0路由器改接後可恢復通訊。當主中心失效時，用戶僅須啟用SRM機制，將原本主中心的虛機在災備中心的資源池重新部署，且網路配置完全不需改變。
手動回復的配置機制示意如圖1所示。此外，手動回復機制仍有部分底層環境條件需要滿足：
圖1 手動回復的配置機制。
‧兩中心間的網路延遲必須要低於150ms。兩邊的管理網路可以L2打通在同一個網段最好，如果不行的話，兩邊的管理網段必須要路由連通。
‧如果是對外服務，此對外服務的Public IP必須可由企業或同一家電信服務商在災備時進行切換。
‧支援兩中心運算資源連接的實體線路建議支援大於1Gbps的頻寬，以及必須配置至少1700的IP MTU。
‧SRM在進行虛機資料抄寫時也會使用到網路頻寬，同樣需要考量。
常見問題疑難排解
前面與上篇投稿內分別針對NSX-T Multisite Active/Standby的自動與手動回復機制進行說明，各自仍有對應的需求限制。因此，接下來就幾個在與客戶討論NSX-T Multisite架構時，常被詢問的問題與大家進行進一步說明。
問題1：在上述的自動回復架構內，可否把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完全失效時，不會有控制層重啟的需求。但當然，這樣的成本就很高了。
問題2：在上述的架構都是討論Active-Standby，可否在Active-Active的環境內實作上述NSX-T的回復機制？ 沒有問題！NSX環境內的Multisite Active-Active架構，可參考圖2的說明。
首先，由於兩個站點間有Overlay網路，因此以單一應用來說，虛機要同時跨兩個站點同時運作是沒有問題的，沒有規定只能在單一站點上運作，而有問題時再透過SRM在另一端重啟。因此，雖然以單一應用來說僅會在單一站點上提供南北向的進出（NSX-T沒有支援Local Egress），但是在運算層，應用能夠同時使用到兩邊的vSphere資源。
此外，圖2內的上虛線╱下虛線，大家可視為是兩個不同的應用，上虛線應用主要在左邊的站點運作，備援在右邊站點。而下虛線應用則相反，主要在右邊站點運作，備援在左邊站點。NSX也可分別對應上虛線、下虛線應用需求的T0、T1等網路和安全配置，以前述的自動或手動方式進行災備。
圖2 NSX環境內的Multisite Active-Active架構。
問題3：前述兩個架構內都要求兩中心間底層網路開啟至少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的業務及技術顧問尋求協助。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞