按部就班建置VMware NSX 實現網路安全虛擬化

VMware提供了許多詳細的資訊與相關的課程，讓大家對於NSX的規劃可以有更進一步的瞭解，幾個重要的來源可以和大家分享。

VMware公開的NSX架構設計資訊

大家可以到以下的網址下載NSX最新的公開Design Guide，這邊的內容也會隨著新的版本與技術而隨時更新：

https://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf

此外，也可以使用關鍵字「NSX Deep Dive」在Internet上進行搜尋，例如在YouTube上也有公布VMworld內對於NSX相關技術與規劃的Session錄影，裡面對於NSX規劃設計上也有很多的討論。

正式的NSX架構規劃課程

NSX的架構設計課程內會詳細討論包括NSX在底層Infrastructure、網路設備、安全考量、多站點應用、維運上的不同設計考量。此課程已經可以正式報名，若有興趣可以到網址「http://mylearn.vmware.com/mgrreg/courses.cfm?ui=www_edu&a=one&id_subject=61127」，或是VMware網站上尋找「VMware NSX: Design and Deploy」課程。當然，也可以直接來電VMware Office與其教育訓練經理聯繫課程相關事宜。

與VMware以及有NSX設計和建置經驗的經銷商聯繫

如果有網路暨安全虛擬化的建置需求，VMware以及相關認證的NSX經銷商也相當樂意與大家進行規劃、建置、維運等的經驗分享與討論，歡迎隨時聯繫。

以一篇文章的篇幅，沒有辦法完整地談論到每一個VMware NSX規劃時的細節，下面僅用隨筆的方式將幾個常碰到或常被忽略的幾個點拉出來與大家分享。首先，就虛擬化Infrastructure的面向做討論。

網路Team與Infra Team都應參與並Review規劃

NSX不是單純的網路產品，當然也不是單純的vSphere虛擬化產品。要能夠進行完整架構與維運機制規劃的團隊，必須同時理解在導入NSX時，於vSphere環境以及底層網路環境的需求及改變。

常看到的悲劇是，NSX的規劃僅由網路Team主導，但對vSphere的架構設計一無所悉；或反過來，由Infra Team主導，可是對於網路的架構與需求並不了解。企業導入NSX的團隊應該同時包括兩邊技術的人才，或諮詢有能力進行網路與虛擬化架構整體設計的專業VMware經銷商進行。

不要忽略了vSphere基本的架構設計是最重要的

以NSX for vSphere現有的架構來說，是建立在現有vSphere環境上的新應用與功能。這代表了如果vSphere資源池的架構設計本身就不好有問題，NSX的運作肯定是有狀況的。這裡經常看到vSphere架構設計有問題的點包括以下幾項：

．沒有區分管理與運算資源池，僅建立了單一vSphere Cluster，然後把運算的機器以及vCenter、NSX Manager、NSX Controller等等都丟在一起混用，也不做資源區分。

．沒有針對硬體損壞的狀況做好完整的資源保留與切換機制，像是HA、DRS等機制的導入。

．管理者對於vSphere系統現有的狀況或使用率完全不了解，雖然這些資訊很容易地就能由vCenter或Operations Manager來取得。

．即使已經是一個較大型的環境，但仍然用分散式、手動的方式管理資源池，例如利用大量的VSS而非集中的VDS，採用多個vCenter而非集中的管理環境。

NSX的運作並不佔用太多vSphere Host運算資源，但仍需納入考慮

一般來說，即使在vSphere Kernel內將NSX的網路功能（Logical Switch、Distributed Logical Router）以及安全功能（Distributed Firewall）等等功能全開，最多會比沒有這些功能時的原本CPU使用量多出約20%的負載（Loading）。或者，一個比較直接的計算方法，是預先把每一台vSphere Host內2個核心（Core）的CPU以及3GB的記憶體（Memory）劃出來作為NSX的功能使用。

若以一個全新的部署來說，虛擬化環境Host全新採購時，應該要將以上的NSX需求資源預先考量進去，而如果現有的環境上要安裝NSX，也應先確認現有vSphere Host的未使用資源空間，是否足夠將這些網路與安全使用的資源納入。

伺服器硬體的考量

基本上，NSX本身不挑硬體，在虛擬化規劃內的vSphere Host設計時，僅需要考慮有符合vSphere的HCL（Hardware Compatibility List）相容清單。但如果伺服器上具有10Gb網卡，建議網卡上需要於vSphere驅動程式內具備VXLAN Offload以及RSS（Receive Side Scaling）功能，才能大幅地將CPU的負載解放到網卡上以硬體進行。

簡而言之，請預先檢查伺服器上選擇的10Gb網卡是否有在相容性清單內，檢查的方法如下：

1. 連到網址「http://www.vmware.com/resources/compatibility/search.php?deviceCategory=io」。

2. 在I/O Device Type內選擇Network，Features內選擇RSS以及VXLAN Offload。另外，選擇vSphere的版本及網卡的供應商廠牌。

3. 按下Update and View Results後，可以看到此廠牌有支援上述功能的網卡型號，如圖1所示，請檢視所要採用的網卡是否有列在支援清單內。

▲圖1 查看可支援的網卡型號。

另外要注意的是在Cisco UCS Server和Nexus 7000上的vPC架構設計，因為在這種架構內Cisco不支援動態路由，在NSX的設計上會有特殊考量，如果目前的伺服器選擇是UCS與Nexus的搭配，請參考「https://www.vmware.com/files/pdf/products/nsx/vmware-nsx-on-cisco-n7kucs-design-guide.pdf」這個設計指南。

vSphere版本的考量

NSX僅支援vSphere 5.5之後的版本，因此若現有環境並非5.5版之後，需要先有虛擬化環境升級的作業，才能採用NSX。另外，雖然NSX的部署必定要採用vSphere Distributed Switch，但只要客戶的環境是vSphere 6或是vSphere 5.5 U3之後的版本，在安裝NSX時都會自動將vDS功能打開。因此，無論是規劃採用vSphere Enterprise Plus/Standard或甚至是Essential Plus，都可以搭配NSX的使用。

討論完虛擬化環境，接下來繼續討論在資料中心內實體網路規劃的部分。

硬體交換器的選擇考量

再度重申，在NSX環境內，底層硬體交換器就是用來提供虛擬資源池內各個vSphere Hosts間的封包交換，只有功能的要求，沒有指定網路設備廠牌或型號。基本上，標準的企業等級交換器都能夠符合作為NSX底層Underlay設備，大家可以選擇最熟悉或CP值最高、服務最好的合作廠商。

但是，這些硬體網路交換器必須具備以下的功能，包括Jumbo Frame、VLAN Tagging and Trunking、IGMP Snooping等，而建議的需求功能包含了須支援Clustering或Stacking堆疊功能、LACP或Ether-Channel，以及L3 Routing。

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

底層硬體網路設備應該要提供的是一個高速、完整備援並快速回復的底層架構，但到底要採用Spine-Leaf IP Fabric或是L2 Fabric，還是傳統三層式架構，NSX並不是很在意。那如果用上面這幾個面向來看，架構的考量是：

高速

Top-of-Rack（ToR）網路交換器的Throughput與容量當然應該是越大越好。建議與vSphere端伺服器的介接為10GbE介面，至少也需要多個1Gb介面。Uplink到企業資料中心網路建議為40GbE或100GbE介面，至少也需要多個10Gb介面。資料中心核心網路的資料處理能力當然也應該具備足夠Throughput。

完整備援

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

快速回復

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

Top-of-Rack交換器的建議架構

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

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

▲圖2 Top-of-Rack交換器架構示意圖。

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

這不是一個簡單回答的問題，須從不同的面向來做討論。但首先，如果貴單位的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網路與網段等；如果使用vSAN功能，vSAN會有自己的Kernel介面並搭配HA功能；而IP Storage當然可以與Management Network整合，但通常會獨立一個VM-Kernel網路來接，避免影響到Management Network。

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

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

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

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

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

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

▲圖3 vSphere + NSX Design Guide設計範例。

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

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

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

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

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

以上是針對建置VMware NSX時，於vSphere虛擬環境與底層網路設備的架構規劃簡要討論，希望能讓大家對NSX的架構規劃重點有更進一步的理解。

＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照 ，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞