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

請接續前幾篇，我們持續地討論NSX Federation內的Global T0 / T1 / Segment這些，搞這麼多做什麼？這篇我們要以大量的抓圖給大家看Federation目前最重要的一個使用情境：全站點失效的狀況。環境一模一樣是之前的展示場景：

如同前面的討論，在此環境內

  • 台北是主站點，此業務與外部網路的進出口是位於台北，T1上的南北向服務提供也是在台北。T0 / T1的Secondary Site都在新竹
  • 業務網路 (Global-APP-Segment, 172.28.100.0/24) 是跨站點的Segment，主要應用 (web-01 / app-01 / db-01) 都位於台北，但額外擴充的應用可以放在新竹 (web-02)

在上圖沒有畫，但實際上有做，且與這邊展示相關連的：

  • 兩個站點有透過SRM進行災備配置，台北站點的web-01 / app-01 / db-01有透過底層vSphere Replication複製到新竹端，反過來新竹站點的web-02也有複製到台北端

接下來這邊的展示直接一點，假設因為某些因素，整個台北Site全部crash無法運作了，如下圖所示。這代表的是包含台北這邊所有的業務機器，Local與Global的NSX Managers，本地端的Edge（支持台北端T0 / T1）通通都不見了。如下圖

先討論一個問題：在此時，底層的網路環境以及用戶的業務機器，有受到什麼影響呢？

  • 單以虛機來說，在新竹的web-02是正常運作沒影響，台北的web-01 / app-01 / db-01消失。
  • 而以整體業務來說，因為app-01 / db-01等後端重要機器都在台北，在整個台北Location失效的狀況下，整體業務當然是無法運作的。如果要將業務恢復，必須要把這些業務機器在新竹重新恢復，如啟用新竹端SRM的Recovery Plan
  • 但這裡我們的重點是NSX網路端的影響。首先，在Global Manager部分，台北端的Active Global Managers已經全部失效。在此狀況下，新竹端的Standby Global Managers雖然有全部的配置，但不會自動啟用。管理者必須要先手動啟用新竹端的Global Managers，才能進行後續的網路配置
  • 此外，因為此業務的南北向進出口原本是在台北（T0 / T1的Primary均在台北），而台北Location所有的Edge都已經失效了。此時Global-APP-Segment本身雖然可以正常運作，但新竹Location的Secondary T0 / T1並不會自動啟用：這代表外部用戶無法連到內部的Global-APP-Segment環境。此時，管理者必須手動啟用新竹端的Secondary T0 / T1 Gateway，才能恢復網段與外部的南北向連線。

當管理者已經發現到台北Location完全失效，並且決定於新竹Location進行災難復原時，此時第一個動作就是要啟用新竹這邊的Secondary Global Manager，將其變為Active：

下面三張圖是管理者到新竹的Global Manager介面內，將其由Standby啟動為Active：

下一個動作則是要將新竹這邊的Secondary T0 / T1 Gateway手動啟用變為Primary。當此動作完成後，內部網路才能改由新竹Location恢復南北向的網路連通：

在改動前我們先看一下外部的實體路由。原本這個環境所有的南北向進出應該是透過台北Location，也就是說，到內部的Global-App-Segment (172.28.100.0/24) 是透過台北這邊的uplink 172.31.52.0 / 172.31.53.0，如網誌最開頭的圖。但在此展示內，因為台北Location已經失效了，此時在外部路由器，會發現找不到往 172.28.100.0/24的路由：

因此接下來要進行移轉：下面兩圖內，我們在新竹的Global Manager（現在已經是Active了）選擇要啟用Network Recovery，然後在後面的選項內將T0 / T1手動切換到新竹Location內：

切換完成後，我們到外部的實體路由器，可以看到172.28.100.0/24這個業務網段路由出現了，並且是透過172.31.54.0 / 172.31.55.0這邊的uplink，代表目前是由新竹Location進行此網段的南北向進出。

到此我們已經完成了Federation環境內，包含Global Manager以及Global T0/T1 Gateway的切換，於台北Site失效的狀況下，業務網路已經可以恢復提供服務，外部用戶也可以改由新竹的T0/T1連接到Global-App-Segment網段了。

但當然，最後需要進行的是將台北Location這邊失效的虛機，在新竹Site以SRM恢復運作。由於整個Global-App-Segment是延伸台北到新竹，這些虛機在新竹備援恢復時也無需做任何的IP與Gateway改動。機器在新竹都重新建立服務回復後，業務就能恢復提供服務了。因為這邊是標準SRM的切換相信大家非常熟悉，我就不抓畫面了。

在本文內我們和大家簡述了NSX Federation內當主站點失效時，其他站點如何進行切換並恢復運作。我想大家可以注意到，Federation內，站點間的切換是『手動』的。不像在原本NSX內，Management Cluster內一個Manager失效不會影響服務，T0 / T1 Gateway內一台Edge失效會有HA自動切換。NSX Federation在做『站點切換』時，必須是管理者介入，確認狀態後再手動切換，如同企業在多站點運作的備援切換一般，也是很合理的機制。

在前面的文章討論的都是NSX Federation下網路的運作。下一篇我們要來看另一個重要的使用情境：Federation內的安全機制。