虛擬雲網路

網路虛擬化NSX 技術文章系列二百二十: NSX Federation:方案說明與討論(六)

作者: 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內的安全機制。

相关文章

评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注