我想大家現(xiàn)在應(yīng)該都清楚，基于流量的轉(zhuǎn)發(fā)并不適合現(xiàn)有硬件。為大流量設(shè)計的交換機，如轉(zhuǎn)發(fā)入口(NEC ProgrammableFlow交換機，Entersys 數(shù)據(jù)中心交換機等)或許是個例外，但即便他們不能應(yīng)付反應(yīng)流安裝所要求的巨大數(shù)據(jù)流更新速度，我們當(dāng)然期望虛擬交換機能運行更好，但遺憾的是，情況并非如此。

　　定義

　　基于流量的轉(zhuǎn)發(fā)有時候被定義為單獨傳輸層對話的轉(zhuǎn)發(fā)(有時候被稱作是微流量)，大量事實表明這種方法不能做擴展，其他人將基于流量的轉(zhuǎn)發(fā)定義為所有不是僅限目的地地址的轉(zhuǎn)發(fā)，我不了解這些定義欲MPLS Forwarding Equivalence Class (FEC)有何不同，也不知道我們?yōu)槭裁匆獋€新的令人費解的詞語來定義。

　　在Open vSwitch中的微數(shù)據(jù)流轉(zhuǎn)發(fā)

　　Open vSwitch的原始版本是基于理想微流的典型轉(zhuǎn)發(fā)架構(gòu)：內(nèi)核轉(zhuǎn)發(fā)模塊執(zhí)行微流轉(zhuǎn)發(fā)，并將所有未知數(shù)據(jù)包發(fā)給用戶模式的后臺程序，然后，用戶模式的后臺程序會執(zhí)行數(shù)據(jù)包檢查(使用OpenFlow轉(zhuǎn)發(fā)條目或其他轉(zhuǎn)發(fā)法則),并且為內(nèi)核模塊中心發(fā)現(xiàn)的數(shù)據(jù)流安裝微流量條目。

　　如果你還記得Catalyst 5000，或許你會想起Netflow交換機一些令人不愉快的記憶，但這個方案的問題應(yīng)該是硬件和CPU的性能不佳造成的。事實表明，虛擬交換機也不會好到哪兒去。

　　向Open vSwitch深入挖掘發(fā)現(xiàn)一個有意思的事情：流量驅(qū)逐，一旦內(nèi)核模塊達到微流量的峰值，它就會拋出之前的流量，直到你意識到默認(rèn)峰值為2500微流量，這個數(shù)值已經(jīng)足夠一個Web服務(wù)器使用，而對托管50或100個虛擬機的Hypervisor而言,數(shù)量級肯定太低。

　　為什么?

　　微流量緩存非常小，沒有很明顯的效果，畢竟，Web服務(wù)器可以輕易應(yīng)對10000個對話，而一些基于Linux的負(fù)載平衡器為每個服務(wù)器控制的對話數(shù)可以多出一個數(shù)量級，你可以增加默認(rèn)的緩沖OVS流量，這下會有人好奇為什么默認(rèn)數(shù)值如此低了?

　　我不能說明造成這種情況的潛在原因，但我懷疑和單位流量計數(shù)有關(guān)——流量計數(shù)器必須周期性地從內(nèi)核模塊轉(zhuǎn)到用戶模式后臺程序。在比較短的間隔期里，在用戶-內(nèi)核槽之間復(fù)制成千上萬的流量計數(shù)器或許會占用很多CPU空間。

　　如何修復(fù)?

　　還不夠明顯嗎?放下所有關(guān)于基于微流量轉(zhuǎn)發(fā)的概念包袱，按傳統(tǒng)方式來做，OVS在1.11版本中走的就是這個路子，OVS 1.11在內(nèi)核模塊中部署了兆位流量，再從內(nèi)核把流量發(fā)送到用戶模式OpenFlow代理那里(因為內(nèi)核轉(zhuǎn)發(fā)條目幾乎可以與用戶模式OpenFlow條目做精確匹配，所以效果顯著)。

　　不出意外，沒有哪個虛擬機使用基于微流量的轉(zhuǎn)發(fā)。VMware vSwitch，思科Nexus 1000V和IBM的5000V根據(jù)目的地的MAC地址做轉(zhuǎn)發(fā)決定，Hyper-V和Contrail根據(jù)目的地的IP地址做轉(zhuǎn)發(fā)決定，甚至用于vSphere的VMware NSX也使用分布式vSwitch和核內(nèi) Layer -3轉(zhuǎn)發(fā)模塊。