前期文章討論了NSX於跨中心Cross-VC架構的管理構件關聯，並介紹新功能CDO模式是如何避免災備發生時單點失效。本期將繼續說明在Cross-VC 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這邊的所有進出口都失效的狀況下會怎麼樣？如圖11所示，此時外部的企業實體網路環境甚至是Internet路由內，會失去來自Site 1 ESG所送來的路由交換，因此即使是比較不被喜愛的路徑，外部環境要往邏輯網路的Ingress Traffic，將會自動改由Site 2的南北向ESG路徑進來。
 |
| ▲圖11 主中心Site 1整個失效或是ESG的所有進出口都失效。 |
至於內部的邏輯路由器，同樣地，因為來自Site 1的路由更新都會消失，因此路由表運算時僅剩由Site 2 ESG來的路由更新。此時，所有對外的Egress Traffic都會自動改由Site 2的南北向ESG路徑離開。
這種方法的優點很明確，可以做到網路南北向路徑切換自動化。當Site 1出事時，透過路由交換與學習，Site 2這裡的路徑會自動浮出，進、出的路由均能切換，不需要手動控制，但缺點呢？
南北向路徑僅走單邊，跨Site的網路傳輸並非路徑最佳化，Client-Server或Browser-Web間的網路延遲時間拉長，可能造成業務反應遲鈍。但必須要說的是，在一些大製造業廠區應用或像證券、金融的業務系統，對網路延遲確實很敏感，但在Web/Container時代內的新應用，前端大部分像是Web-based的連線，即使額外的延遲加上來，未必一定代表業務不能運作。
實體網路這段對於兩個資料中心間必須有統合的路由控制。此處談到的可能是一個大企業跨廠區跑BGP/OSPF的路由環境，或甚至是跨Internet的BGP環境。當然，能這樣做的環境就受限。
如果外部路由無法統合，無法交換，那怎麼辦？那就得由網路Team手動控制。Site 1的設備壞掉時，用DNS、改IP、切路徑各種不同的方式來做。但如果得這樣做，這種方法最漂亮的優點就失去了。
方案二：以Local Egress控制，北向傳輸均經由本地出口
圖12這張圖雖然亂，但比較容易繪出NSX Local Egress的運作機制。在這個機制下，對於同一個通用分散式邏輯路由器，在每一個資料中心（vCenter）內都要有一個對應的Universal Control VM。
 |
| ▲圖12 NSX Local Egress的運作情形。 |
接著，在每一個獨立的資料中心內，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方案系列內的最後一篇，所要介紹的是在跨中心架構內進行微分段東西向防護的功能介紹。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞