作者: Colin Jao 饒康立 – VMware資深技術顧問,主要負責VMware NSX產品線,目前致力於網路虛擬化暨分散式安全防護技術方案的介紹與推廣。
接去上一篇對應到vDS的介紹,這一篇我們要特別把一個重點拉出來談:vDS (vSphere Distributed Switch)裡面有不同種類的Teaming Policy,而在使用NSX時,規劃上我們應該會選擇哪一種呢?在下圖裡我們可以看到在邏輯網路安裝時的VXLAN設定,包括VXLAN的Traffic是走在哪一個vDS上,VLAN是哪一個,MTU設定大小等等,但我們要試著去解釋幾個問題:
• VXLAN的Teaming Policy選擇要用哪種比較好?
• 選擇不同的Teaming Policy時,VTEP的數目與IP是如何配置?
首先要解釋vDS內有幾種不同種類的Teaming Policy,不同的Port Group可以選擇不同的Teaming Policy:
Explicit Failover
這個Port Group僅會選擇指定的單一Active Uplink進行Traffic的傳送。除非這個Uplink對應的實體介面出現問題,Traffic才會走到備援的Standby Link進行傳送。
Route based on the originating virtual port or based on source MAC hash
Port Group會依據此VM所接取vDS時的Virtual Port ID,或是不同的vNIC MAC Address來進行Load Sharing。一般來說,採用source MAC hash可以做到更好的負載分散,如果一個VM上有多張vNIC,可以做到不同vNIC的Traffic Load Sharing,但同時也會使用更高的CPU overhead。因此大部分的狀況,大家都是選擇使用Route based on the originating virtual port即可。
這個模式的好處是Switch上不需要做任何額外的LACP / Ether-Channel設定,Teaming相關的控制直接由vSphere Host控制就能做得很好。Route based on the original virtual port是Port Group Teaming Policy的預設模式,也是大部分環境內我們的建議模式
Route based on LACP (IP Hash) or Ether-Channel
如果你原本是一個網路工程師,自然的反應應該就是實體交換器與虛擬交換器間應該是採用LACP或是Ether-Channel來做Teaming,因為這是網路世界標準的做法。但在虛擬環境內,其實我們不會特別鼓勵要採用LACP / Ether-Channel來做Teaming,原因有幾個:
• 用Route Based on Port這些方式,無需設定實體交換器,就已經可以做到很好的實體Port負載平衡
• 你說Switch上面設定一下LACP也沒有什麼難的?這是沒錯。但是考慮一點,vDS上面的Teaming政策是基於Port-Group,也就是說你可以選擇Management要用Fail-over,vMotion要用Route based on Port,VXLAN要用Route based on VXLAN。但是實體交換器上,LACP / Ether-Channel的設定都是基於實體埠。所以當你Switch上LACP一打開,這時候代表所有使用這些對應Uplink之Port Group的Teaming Policy都得要統一成LACP,而不能使用其他的模式…結果造成架構極為不彈性
• 而且LACP有很多不同版本與參數,如果實體交換器上要開,請大家也要確認vDS上的參數設定能夠符合並進行測試
我要說的是,使用LACP模式,沒有太多特別的好處,但管理與維運上麻煩一堆。說真的,我們不是很建議在vSphere環境內用LACP
Route based on Physical NIC Load (LBT)
在vSphere Distributed Switch的Best Practice Guide裡面特別提到,LBT是最被建議的模式。LBT模式會持續monitor physical link的loading,並且依據實際的loading去分配網路流的traffic,甚至於一個實體link壅塞時,將上面的網路流改往另一個空閒的link去送。但要做到上面的能力,會耗用比較高的vSphere Host CPU,而且這個模式僅在vDS支援,不在vSS支援。
上面哈啦這麼多,我們要說的重點其實是,那在使用NSX的邏輯網路功能,於各台vSphere Host上進行VXLAN設定時,VXLAN所使用的Port Group應該要設定哪一種?
下面的表格是NSX的一些Deep Dive投影片常出現的表格,解說的是:
• NSX目前的版本不支援LBT模式,短期內也沒有計畫會支援
• 如果採用的模式是Route based on Port / MAC hash,那vDS上面有幾個Uplink,就會產出幾個VTEP的Kernel Port IP。比如說vDS上面的設定是4個Uplinks,此時若選擇這兩種模式,每台vSphere Host上面會產出4個新的VTEP Kernel Port,各自都有一個IP
• 如果採用的模式是LACP / Ether-Channel / Explicit Failover,由上面的例子,每台vSphere Host上面僅會有一個VTEP Kernel Port,一個IP。
好,囉唆了這麼多,寫了一大堆,重點是什麼呢?
NSX這邊要選擇哪種配置是一個時常被討論的問題,但目前我們收到總部在設計上的最update建議是
• 如果是PoC環境,或是客戶使用VXLAN的環境內,Logical Network的Traffic僅需要單一個10GB的Link就能滿足,使用Explicit Failover是最簡單與建議的方式
• 如果是生產環境,使用Route based on Originating Port是最建議與單純的方法。唯一的缺點是底層VTEP會有很多個Port與多個IP,Troubleshooting略顯繁雜。但這個方式已經可以把Logical Switch的Traffic在多個link上面分散傳送
• LACP當然可以選用,但與帶來在管理、維運上的副作用來比較,我們沒有看到明顯地一定要採用的理由。
Comments
0 Comments have been added so far