作者： 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都在此中心內，此時在邏輯網路上的虛機還能夠正常連通嗎？