Software Switching 優化

最近又看了幾個在twitter上, 關於軟件網絡不規模化, 或是效能不足的爭論. 說實在的, 我覺得這個爭論實在是無意義.  拿軟件網絡跟硬件網絡相比, 就好像拿雞蛋和炸彈相比, 一個是給人吃的,  另一個是要人命的, 風馬牛不相干. 看來看去,  都好像是廠家在市場訊息上,  彼此較勁. 過去我一直想往市場部門移動, 現在想想. 好險沒去成. 當工程師還是比較好, 置身事外看看戲也是不錯, 不然我可能忍不住就會直接在網上罵起髒話來. 我也不要去讚揚或是貶低不同陣營的看法, 對於技術, 我一直希望用客觀和實際應用的場景, 去評斷價值. 畢竟每一條代碼都是工程師用寶貴的時間所寫出來的,  不應該被市場或是銷售等相關議題後的目的, 去被貶低或是傷害. 工程師是一個辛苦且需受人尊敬的職業, 就如當初我第一天加入特戰部隊時, 指揮官說的. 你們的兵種, 是全世界最受尊敬的種類, 不要被別人看不起, 也不要自己褻瀆了你的臂章.

回歸主題,  對於虛擬化之後, 網絡在Hypervisor之內的效能, 被現今網絡或是系統技術人員自動去分割成不同技術領域之後,  這些細節的確是很難在雙方有共識的情況之化去被討論. 所以網絡人員用硬件的架構去看待軟件的網絡技術, 系統軟件人員用不懂網絡佈署的架構角度, 去看待軟件網絡, 說到這邊, 我真對軟件網絡叫屈啊. 軟件網絡弟兄, 你們沉冤太久了.  事實上,  如果你想真的弄清楚軟件網絡的價值,  還真需同時具備多方面的技術知識, 不然在技術討論上很容易就出現盲點或是偏執.

這邊先澄清一個重要的概念,  這之中最大的問題會落在Virtual Machine, Softwre Switching 和Hypervisor System的三角關係. 或是說這因該只是Virtual Machine 和 Hypervisor之間的關係, 因為Software Switching 只是Hypervisor內的一個程序模塊.  基本上, 你可能需要知道,  Virtual Machine只是Hypervisor上的一個應用(Application), 這個應用進行所有的工作都是由Hypervisor 操作系統所支撐的,  也就是說,  當討論到Hypervisor系統優化的時候, 必須以操作系統的角度去思考, 當然這也包含軟件網絡的主題.

在一般x86的系統內, 所有的application其實都是交由CPU作為直接運算處理, 並且由程序來判斷該需要資源或是其他用途的分配. 在一個默認沒有任何優化的狀況下, Hypervisor應用的網絡的程序狀態就會如下圖般：

也就是說,  這其實就是應用(  virtual machine ) 會按照傳統OSI 7 Layer的作法, 並且結合由Hypervisor所提供的網絡程序進行每個layer的數據處理, 當然這些處理全是經過Hypervisor系統程序呼叫CPU的資源進行的. 由於Hypervisor本身需要處理很多程序的, 在加上網絡這個密集的程序請求, CPU的工作自然負擔加重, 網絡效能及穩定當然也就沒那麼好了.

如果想要改善網絡這方面的效能的話, 當然就是找尋一些可以offload系統機制的方式, 只要Hypervisor系統可以了解這些機制, 自然就可以將工作卸載到這些機制上. 今日在Hypervisor上最常見的機制,  無非是使用網卡的TSO, GSO,  LRO等等相關機制. 當然網卡當然必須要能support這些機制,  才能卸載來自於應用 ( virtual machine )的網絡程序請求.

透過Driver與系統的溝通, Hypervisor可以知道有哪些機制可以對網絡數據進行卸載, 從上圖的表示可以看出來, 透過這些機制, 原本需要呼叫Hypervisor網絡程序進行L4～L2的網絡fragmentation的工作, 可以完全卸載到網卡上, 也就是說, 網路程序可以從系統上被縮減, 並且交由網卡進行硬體的處理. 這就是我們常見的TSO機制. 這個方法可以大幅將低CPU對於網絡處理的耗損及透過網卡的處理, 增進Performance.

PS: 每一個L4 Segment最大可支援64K Bytes, 而Ethernet的MTU為1518 Bytes. 一般來說我們計算替換率可能使用一個比較中立的值進行計算, 大約為32K Bytes. 如果以上圖應用數據包 8K來算, 透過TSO可以減少5次對於Hypervisor系統的網絡程序的請求, 降低84%的CPU程序需求對於單一數據.

在實際測試中, 有開啟這個機制和沒開啟, 我個人看過差距最大可以到達6倍左右. 一般來說也有2倍以上的差距,  當然在還是在你使用什麼樣的Hypervisor, 系統規格等等有所不同. 當然這還就算是最佳化了嘛？當然還不是, 因為就算降低了網絡程序對系統的消耗, 但是還是存在網絡程序在CPU上的分配問題, 因為你的網絡流量不是一個8K的數據包而已！！！

一般來說,  當網絡程序被setup之後, 通常是咬在一個CPU被執行, 這樣對於那個CPU來說還是造成一定的負擔, 最終還是影響到網絡效能, 可能導致吞吐到達一個瓶頸點之後就上不去了. 這個問題還是回到了, 網卡的Driver對於CPU工作的分配的優化是沒有信息的, 所以為了要讓網絡的程序可以在CPU之間被負載均衡, 還另外要驅動Receive Side Scaling ( RSS )的機制去驅動負載均衡的工作, 這個部分在我之前的測試上, 有30％的改善增進.
PS: 我使用vSphere 5.5 ＋ NSX vSwitch ＋STT Tunnel, 得到了雙向16Gbps的吞吐量, 對於網絡虛擬化使用隧道來說, 這個值算是相當理想的.

所以如果一台hypervisor可以製造出16Gbps的吞吐量, 那就vSwitch的技術我想就沒有什麼需要好質疑的. 因為vSwitch是支持一台hypervisor上的VM, 並不是一個機櫃上的hypervisor, 這是硬件交換機地盤. 在網絡虛擬化的議題上,  端到端的隧道其實需要透過硬件交換機所建構的高速穩定的IP網絡,  當然如果我拿16Gbps 在Hypervisor優化後的數據去跟一台背板是500Gbps以上ASIC的交換機做比較, 我想我一定是吹到風受寒, 被馬踢到重傷, 被牛頂到內臟破裂, 符合風馬牛的狀態才會做的事.

所以轉發能力,  這點我想短時間內Hypervisor因該還是無法與硬件交換機比擬. 但是如我上述的, 軟件所建構的網絡在利用物理網絡的高轉發性能之後, 與物理網絡設備最大的差異就是在控制平面的規模. 在x86 Server下, 切出一塊256MB的空間作為信息存放是一個極為輕鬆的工作, 但是在物理交換機上, 卻是一個極為昂貴的不可能. 所以對於網絡虛擬化來說, 訴求的是一個控制規模化, 但是效能合理化的組合. 但是硬件網絡追求的是效能極大化但是規模有限的組合, 我相信也很多人不同意這個說法, 因為大家所面臨的問題不一樣, 所以當然看法也不同. 不過軟件網絡的概念其實給傳統網絡的人帶來了一定的思考衝擊,  所以還是一句老話,  守舊沒什麼不好, 不好你就不守了. 創新也沒什麼困難, 怕難就不創新了~ 青菜蘿蔔, 香蕉芭樂～喜歡就好

最後感謝我廣州的同事, Jonathan Peng, 他從Google上發現並且提供給我的這兩張圖, 比我原本自己構思的圖還要好, 這圖真的是很容易的幫助理解.