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

我們在這一篇網誌繼續上一篇的討論：在 NSX 與 vSphere 的整合架構內的規劃注意點有哪些。上一篇我們討論的重點是在伺服器與 vSphere 規劃的注意項目，這一篇我們會Focus 在硬體網路設備的注意事項上。

硬體交換器的選擇考量

我們在前面的網誌有一篇特別談這個 Topic：https://www.facebook.com/notes/vmware-taiwan/342118785996949 。很快的把重點整理一下：

• 底層的網路交換器只有功能的要求，沒有指定網路設備廠牌或型號。基本上標準的企業等級交換器都能夠符合作為 NSX 底層 underlay 設備，大家可以選擇最熟悉或 CP 值最高、服務最好的合作廠商

• 網路交換器必須具備的功能包括 Jumbo Frame、VLAN Tagging and Trunking、IGMP Snooping

• 網路交換器建議的需求功能包括了可以支援Clustering or Stacking堆疊功能、LACP or Ether-Channel、L3 Routing

資料中心內的硬體網路架構需求：完整備援及足夠的頻寬容量

底層硬體網路設備應該要提供的是一個高速、完整備援並快速回復的底層架構，但到底大家要採用 Spine-Leaf IP Fabric 或是 L2 Fabric 還是傳統三層式架構，NSX 並不是很在意。

那如果用上面這幾個面向來看，架構的考量如下：

• 高速：Top-of-Rack (ToR) 網路交換器的 throughput 與容量當然應該是越大越好。建議與 vSphere 端伺服器的介接為 10 GE 介面，至少也需要多個 1 GB 介面。Uplink 到企業資料中心網路建議為 40 or 100 GE 介面，至少也需要多個 10 GB 介面。資料中心核心網路的資料處理能力，當然也應該具備足夠 throughput

• 完整備援：網路所有的地方應該都有備援。伺服器應該有多張網卡多個 Port 連接到 ToR 交換器，每個機櫃內應該要至少兩台 ToR 交換器避免單台設備硬體失效。ToR 交換器往核心網路的連結同樣也應該多個實體路徑，連接到不同的核心交換器

• 快速回復：任何因為設備或線路失效的問題，除了具有備援外，也盡量能夠在短時間內恢復底層的連結。因此與伺服器的接取處應該要啟用 Portfast 功能，能不要用spanning-tree，而改用 IP Routing 快速收斂的方式，當然是比較推薦，兩台 ToR 交換器能用堆疊的就用堆疊的避免收斂運算

所以Top-of-Rack交換器的建議架構應該長成……

下面這張圖的左邊是一個實體示意圖。各台 vSphere Host (Hypervisor) 用 10G Link 往ToR 介接，兩個 Link 分別接到不同的實體交換器。兩台實體交換器如果可以，採用Stacking 是管理與收斂較好的方法。ToR 交換器再以多個 40GB or 100GB 的 Link 往核心交換器進行接取。

而 vSphere Host 與實體交換器間應該是跑 Trunk (802.1Q)。實體交換器上應該要具備能夠跑 Management / vMotion / Storage / VXLAN 的不同 VLAN，而各個 VLAN 能夠對應到 vSphere Host 內 vDS 的不同 Port Group，分別接取不同功能的 VM Kernel Ports。

資料中心內還需不需要大二層網路？

這不是一個簡單回答的問題，須由不同的面相討論。但首先，如果貴單位的 vSphere 環境伺服器主機沒有超過一個機櫃的話，這其實不是一個很需要討論的問題。兩三個機櫃，要把大二層打通也還好，十幾二十個或更多個機櫃，這是一個需要面對的架構設計考量。

VSphere + NSX 的環境內，哪些 Traffic 可以已經可以跨 L3 網路進行運作呢？有四種：

• Management VM-Kernel Network

• vMotion VM-Kernel Network (vSphere 6 開始支援，用來做 Live Migration)

• Provisioning VM-Kernel Network (vSphere 6 開始支援，用來做 Cold Migration / Clone / 快照)

• NSX VXLAN VM-Network (NSX 功能，所以 Logical Switch 都可以跨 L3)

但大家需要思考的問題不只這樣，而還包含到vSphere 內其他的 Kernel Network 需求。舉例來說：

• 如果要使用 FT (Fault Tolerance)， 會需要獨立的 VM-Kernel 網路與網段，此時這個網路就不能跨 L3

• 如果使用 VSAN 功能，一般來說標準的架構建議也都會採用獨立的 VM-Kernel 網路與網段，此時這個網路也不能跨 L3

• IP Storage 當然可以與 Management Network 整合，但通常我們會獨立一個 VM-Kernel 網路來接，避免影響到 Management Network。此時如果 IP Storage 採用獨立的 Kernel 網路，那也無法接取到 Default Gateway

當然，我們在 vSphere 內可以用 API 再去新增新的 TCP/IP Stack 來支援這些新的 VM-Kernel，但除了設定複雜外，問題也沒有這麼簡單。比如說，VSAN 底層的網路事實上是走 Multicast 的機制，這代表如果要跨 L3，L3 網路就得要支援 PIM 這樣的協定，架構設計會變得更複雜……

我個人的建議是，在同一個 vSphere Cluster 的所有主機內，放在同一個 L2 網路內是較單純且易於維護的。但如果是不同的 vSphere Cluster，此時放到不同的跨 L3 網路內，應該很合適且沒有太多問題。下面的圖是 vSphere + NSX Design Guide 內的建議圖，在這個設計下，

• 單一Cluster內的 VM-Kernel 網路都可在同一個 L2 網路內。但 L2 網路的 Scope 僅限制在少數機櫃內，無需延展到整個 Data Center

• 單一 Cluster 內的 vSphere Host 可以分散到不同機櫃，當單一機櫃出事時，Cluster 內的其他機器可以進行負載的備援

• 不同的 Cluster 跨 L3 運作，核心網路利用快速收斂的路由協定， 確保核心網路的穩定性

• 透過NSX，業務需求所接取的邏輯網路可以跨 L3，橫越整個資料中心使用

當然，如果貴單位現有的環境已經是非常強大的 Fabric 架構， 比如 FabricPath / QFabric 等，NSX 可以在上面跑得非常順暢。而如果是一個全新的資料中心，大家可以在功能與價格上做思考與取捨，單以 vSphere + NSX 來說，我們僅需要 L2 網路於小規模的環境內建置，無需整個資料中心都用大二層技術打通。

總結起來，好的虛擬環境底層網路應該是具備下面的特性：

• 建立起來後 IT 單位就不需要花太多的心力去管理與更動組態，IT 單位僅需要能監控底層網路環境的狀態，並且在設備或線路失效時能快速發現並更換

• 易於橫向擴充，虛擬環境 / 雲環境要成長時，能夠非常快速的擴展，且不影響現有的架構，或必須進行設備更換

• 架構開放且不鎖定特定技術與廠牌，具備好的 CP 值

希望上面的說明能讓大家對 NSX 的底層網路建置架構規劃方式有更進一步的理解。