三、虛擬交換機(jī)的性能需要優(yōu)化嗎？

　　前面講這么多，其實主要是想要說明，如果云計算網(wǎng)絡(luò)管理員想要從虛擬交換機(jī)切換到物理交換機(jī)的話，是很容易做到的，不會有什么損失。但接下來網(wǎng)絡(luò)管理員馬上就會問：為什么要切換？有什么好處？答案有多個，主要的兩點是網(wǎng)絡(luò)可視化和網(wǎng)絡(luò)性能。

　　網(wǎng)絡(luò)可視化的問題相對好分析，容易理解。因為如果在Hypervisor上做了Tunnel封裝，報文送到TOR交換機(jī)上時，交換機(jī)已經(jīng)看不到用戶原始報文了，物理網(wǎng)絡(luò)就很難對原始報文做統(tǒng)計和應(yīng)用各種策略。而如果Tunnel封裝在TOR上面做，則沒有這個問題。

　　而對于性能問題大家的看法可能各異，大體可分為三類：

　　第一類是覺得沒有什么性能問題；

　　第二類是覺得有，但還可以忍受；

　　第三類是覺得已到了影響業(yè)務(wù)、無法忍受 的地步了。

　　我相信他們講的都是他們所看到的事實，為什么結(jié)果迥異？我分析過，基本上前面兩類，要么是仍然處于試驗階段，還沒有大業(yè)務(wù)的壓力，要么是已正式 部署，但網(wǎng)絡(luò)規(guī)模不大或者網(wǎng)絡(luò)內(nèi)的業(yè)務(wù)流量壓力不大，當(dāng)然我也不排除有的人技術(shù)能力特別牛，把性能優(yōu)化到了極致。而第三類，則是已經(jīng)有很大業(yè)務(wù)量部署在生 產(chǎn)網(wǎng)絡(luò)中了，或者是用充分的測試手段模擬過實際的業(yè)務(wù)。第三類的典型例子就是國內(nèi)的云服務(wù)提供商UCloud，他們有大量實際用戶（很多是游戲客戶）租用 了他們的公有云網(wǎng)絡(luò)，業(yè)務(wù)量很大。和AWS等云計算平臺一樣，網(wǎng)絡(luò)處理會占用計算資源，帶寬損耗也很大。

　　另外一個云服務(wù)提供商 99Cloud也曾經(jīng)做過這樣的實驗：先是用iPerf進(jìn)行大流量測試，使用vSwitch帶寬大概能到800多MB，后來在iPerf發(fā)包的同時，用迅 雷下載模擬實際網(wǎng)絡(luò)流量，帶寬馬上降到了500多MB，有高達(dá)300MB的帶寬被損耗掉了。所以結(jié)論就是，虛擬交換機(jī)肯定有性能問題，需要優(yōu)化。就算是對 于那種技術(shù)特別牛，能將軟件優(yōu)化做到極致的人，他也無法否認(rèn)，你再怎么優(yōu)化，網(wǎng)絡(luò)處理也要占用計算資源，而按道理網(wǎng)絡(luò)只是工具，計算才是核心價值。

　　前面是定量測試，下面我們來進(jìn)行一些理論分析?，F(xiàn)在服務(wù)器的性能這么強(qiáng)勁，還有網(wǎng)卡加速，為什么虛擬交換機(jī)還有性能問題？我分析主要有以下幾個原因。

　　vSwitch做Tunnel加封裝和解封裝時，報文在內(nèi)存中的移動和拷貝會影響性能。

　　網(wǎng)卡中的TSO是可以對TCP報文進(jìn)行分片加速的，但一旦vSwitch給報文加了VxLan或者GRE Tunnel，網(wǎng)卡一看不是TCP報文，就不會進(jìn)行分片加速了。這對性能損耗也比較大。

　　軟件中的流表查找消耗比較大，特別是在流表數(shù)量比較大，TCP短連接比較多的時候。

　　圖2是使用虛擬交換機(jī)OVS的OpenStack網(wǎng)絡(luò)架構(gòu)。