posted

0 Comments

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

另一個每一次和客戶討論雙中心架構,馬上大家就會情緒高張,畫白板技術名詞飛來飛去會議結束不了的話題就是,如果我們的業務可以在兩個以上資料中心運作,這個業務對外的南北向網路流要如何進出各個資料中心?我們能不能做到如果業務在左邊資料中心,資料流就由左邊進出,而業務安排在右邊資料中心,進出網路流就應該走右邊,像下圖一樣

更進一步,如果因為災備、業務遷移、資源需求等狀況,業務系統要移到另一個資料中心去,此時,南北向網路流可不可以也自動切換到另一邊,像是下面這張圖

我先說結論:在現在的環境裡,要做到這樣的全自動化路由調整切換不容易,但NSX的一些特別做法,或許大家可以思考導入後是否有符合業務的需求。這邊我們要談NSX在跨中心環境裡面,南北向交通控制的兩種做法,各有優缺點,供大家參考。

方案一:以路由控制,所有南北向都走單邊

這是一個標準、在許多大型生產環境都在使用的方法。請大家參考下圖的架構,裡面

  • 各資料中心內,各有一組(2~8台)Edge Service Gateway作為與北向實體路由器介接的出入口,並與北向實體路由器以OSPF / BGP等方式進行路由交換。此時作為主要出入口資料中心Site 1內的ESG,必須要對外發出較高的BGP Weight或是較低的OSPF Cost,讓外部實體設備路由(企業網路或甚至Internet)上,要往邏輯網路走時(Ingress Traffic)會選擇往Site 1走。而反過來,Site 2內的ESG,對北向實體路由器發出的路由交換內,就應該是較低的BGP Weight或是較高的OSPF Cost,不要讓實體網路的Ingress Traffic走來
  • 各資料中心的ESG與下層南向的Universal Distributed Logical Router同樣也要進行路由交換。類似地,作為主要出入口資料中心Site 1內的ESG,必須要UDLR發出較高的BGP Weight或是較低的OSPF Cost,讓邏輯路由器上的封包往外走時(Egress Traffic)會選擇往Site 1走。而反過來,Site 2內的ESG,對南向UDLR發出的路由交換內,就應該是較低的BGP Weight或是較高的OSPF Cost,避免讓邏輯網路的Egress Traffic走來

而如果在主中心Site 1整個失效,或是ESG這邊的所有進出口都失效的狀況下會怎麼樣?如下圖,此時

  • 外部的企業實體網路環境或甚至是Internet路由內,會失去來自Site 1 ESG所送來的路由交換,因此即使是比較不被喜愛的路徑,外部環境要往邏輯網路的Ingress Traffic會自動改由Site 2的南北向ESG路徑進來
  • 內部的邏輯路由器同樣地,因為來自Site 1這邊的路由更新都會消失,因此路由表運算時僅剩由Site 2 ESG內來的路由更新。此時所有對外的Egress Traffic都會自動改由Site 2的南北向ESG路徑離開

這種方法的優點很明確:可以作到網路南北向路徑切換自動化。當Site 1出事時,透過路由交換與學習,Site 2這邊的路徑會自動浮出,進、出的路由均能切換,不需要手動控制。但缺點呢?

1. 南北向路徑僅走單邊,跨Site的網路傳輸並非路徑最佳化,Client-Server or Browser-Web間的網路延遲時間拉長可能造成業務反應遲鈍。但我必須要說,在一些大製造業廠區應用或是像證券、金融的業務系統對網路延遲確實很敏感,但在Web / Container時代內的新應用,前端大部分像是web-based的連線,即使額外的Latency加上來,未必一定代表業務不能運作

2. 實體網路這段對於兩個資料中心間必須有統合的路由控制。這邊我們談到的可能是一個大企業跨廠區跑BGP / OSPF的路由環境,或甚至是跨Internet的BGP環境。而當然,能這樣做的環境就受限了。而如果外部路由無法統合,無法交換怎麼辦?

那就得由網路Team手動控制啊。Site 1的設備壞掉時,用DNS / 改IP / 切路徑各種不同的方式來做。但如果得這樣做,這種方法最漂亮的優點就失去了。

方案二:以Cross-VC NSX內的Local Egress機制進行控制,各業務機器北向傳輸均經由本地出口

下面的這張圖雖然亂,但比較容易繪出NSX Local Egress的運作機制。在這個機制下,對於同一個通用分散式邏輯路由器,在每一個資料中心 (vCenter) 內都要有一個對應的Universal Control VM。接著,在每一個獨立的資料中心內,下列兩個構件:Universal DLR的Control VM / 一個叢集內的所有vSphere Host,要設定為同一個Locale-ID。這個Locale-ID,代表的是位於同一組資料中心內的構件。

接著,各資料中心內的ESG藉由不同的邏輯交換器,僅會與同一個資料中心內的UDLR Control VM進行路由交換。此時,NSX Controller會將各個資料中心內不同UDLR Control VM所運算出的路由,藉由所屬的Locale ID,再送到此資料中心內的vSphere Host內。

也就是說,

  • Site 1內的vSphere Host上,僅會學到來自同一個Locale-ID的UDLR Control VM所發送的路由資訊,也就是由同樣Site 1內的ESG所發送的路由。因此,所有在Site 1內的虛機北向交通 (Egress Traffic),僅會過Site 1內的ESG。
  • 同理,Site 2的所有虛機北向交通僅會走Site 2的ESG出去。因為利用這樣的方式,虛機是位於哪一個資料中心,就僅會由此資料中心的出口離開,這技術在NSX內就叫做Local Egress

聽起來很理想嗎?這機制也不是完美的

  • 我們都僅僅提到北向Egress的傳輸。那進入資料中心的南向Ingress傳輸怎麼辦?NSX無法控制外面的用戶要如何進來,這邊需要管理者以DNS / 路由控制像是Route Redistribution等等方法在外部環境進行設定
  • 如果現在因為種種原因,業務機器從Site 1飄到Site 2去了。此時南北向路徑會自動切換嗎?北向Egress,沒問題。當業務機器切換到另一個中心的叢集內,由於vSphere Host上的Locale-ID變了,Routing Table也變了,就會從本地端出去。但南向Ingress呢?肯定沒辦法。此時,網路Team / 業務Team同樣地,必須用手動的方式進行南向交通切換
  • 如果災備狀態發生,在Site 1內的所有ESG全部都毀了,此時,還在Site 1內的業務機器有辦法由Site 2的ESG離開嗎?也沒辦法,因為在Site 1的vSphere Host上完全看不到在Site 2上的出口路徑(因為Locale-ID不同)。此時,管理者得把這邊的業務機器趁可以時轉到Site 2(或是SRM啟動,Site 2的備援業務機器啟動),並且手動調整南向Ingress Traffic 到Site 2

我的認知是,完美的方案,也就是資料中心間二層打通、虛機可以進行飄移與橫向擴充,而進出路徑都會自動最佳化,而且出事情的時候網路管理者也不用管可以自動切換,這樣的方案應該還不存在。NSX能夠幫助一部分,但如何能夠在業務便利性、維運簡便、效能最佳化間取得平衡點,確實仍還是資料中心架構規劃師需要思量的事情。

下篇網誌內我們要討論另一個Cross-VC NSX架構內常見的詢問:如果單中心失效的狀況發生,而NSX Controller都在此中心內,此時在邏輯網路上的虛機還能夠正常連通嗎?