通用邏輯網路連結虛機　跨資料中心實現最佳路徑

這裡特別要提醒大家的是，部署這些通用邏輯網路元件時，必須注意其功能的限制。

通用邏輯網路構件雖然很好用，但並不是每一種本地邏輯交換器、邏輯路由器有支援的功能都具備。筆者在寫作當時，NSX的版本是6.3版，下列幾項功能就不能使用在通用網路構件上：

‧L2 Bridge：Universal Logical Switch無法採用橋接的方式去接取一個實體VLAN。所以實際的問題來了！能夠採用Universal Logical Switch來當作兩個資料中心間，實體機器溝通的橋樑嗎？絕對不能！如之前的文章所述，如果企業考慮的是要把兩邊的實體機器業務網路二層打通，請考慮用實體線路實體設備或是VPN的做法。

‧L2 Hardware VTEP：NSX自己的軟體方式橋接都不支援了，要在第三方協力廠商的硬體交換器上做Universal Logical SW到實體VLAN的橋接，當然就沒辦法。

‧Spoofguard：NSX的Spoofguard功能可以監控各個虛機MAC與IP之間的關係，據以進行安全管控（任意偽造IP的虛機可以阻擋），並且在虛機不安裝VMtools的情境下自動偵測虛機IP地址。但是，這個功能現在也還無法在通用邏輯交換器內做到。

實際發生問題與期待解決辦法

接著，討論另一個問題。通常在與客戶討論有業務網路二層連通的跨中心架構時，大家都希望要做到一件事，但就是有沒有辦法讓同一個業務內的機器都能夠用最短最優化延遲（Latency）最小的路徑互相溝通，而不要出現髮夾彎的狀況，讓業務機器間延遲時間過長而出現問題。

例如，就像圖6所示，大家想必不會希望在右邊Data Center裡面的業務機器，Web與AP溝通或是AP與DB溝通時，結果網路流反而要跑到左邊的路由器或L3 Switch才能交換。至於圖7的情形肯定就符合大家的需求了，左邊走左邊，右邊走右邊。但在實體網路的世界裡，可以將兩台設備設為同一個IP作為Default Gateway嗎？

▲ 圖6 不良的網路運作示意圖。

▲ 圖7 理想的網路運作環境。

而NSX的分散式邏輯路由器就沒有以上這個問題，邏輯路由器原本就是在NSX管理層設定後，直接在每一台vSphere Host上提供路由功能。網路封包轉路由後，再經VXLAN封裝於vSphere底層VTEP間進行IP傳輸。因此，虛機與虛機間跨網段的溝通完全不會受到底層實體路由設計的限制，可以走最短（同機箱、同機櫃或者同一個Data Center）的vSphere間實體路徑送到目的地。

此時，如果大家很在意同一個Application內的業務構件如Web/AP/DB的虛機要走最短路徑的話，必須確認務必把同一個Application的所有構件都「放在同一個Data Center內」。

如果是Stretch Cluster，就利用Affinity Rule等方法把業務機器綁在同一邊。若是多個資料中心的多個叢集，注意別不小心將同一個Application的任一虛機飄到另一個資料中心去。這樣，就可以取得上面的路徑最優化效果。

接著討論另一個每次與客戶討論雙中心架構時，大家馬上就會情緒高張，畫白板技術名詞飛來飛去會議結束不了的話題：如果業務可以在兩個以上資料中心運作，這個業務對外的南北向網路流要如何進出各個資料中心？能不能做到當業務在左邊資料中心時，資料流就由左邊進出，而業務安排在右邊資料中心，進出網路流就應該走右邊，如圖8所示。

▲ 圖8 讓業務在左邊資料中心時，資料流就由左邊進出，若安排在右邊資料中心，資料流就走右邊。

若再更進一步要求，如果因為災備、業務遷移、資源需求等狀況，業務系統要移到另一個資料中心，此時南北向網路流可不可以也自動切換到另一邊，如圖9所示。

▲圖9 讓南北向網路流可以自動切換到另一邊。

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

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

這是一個標準，在許多大型生產環境都在使用的方法，請參考圖10的架構，其中的實際運作情況如下：

▲圖10 正常狀況下的網路運作。