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

　　定義

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

　　在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ā)給用戶模式的后臺(tái)程序，然后，用戶模式的后臺(tái)程序會(huì)執(zhí)行數(shù)據(jù)包檢查(使用OpenFlow轉(zhuǎn)發(fā)條目或其他轉(zhuǎn)發(fā)法則),并且為內(nèi)核模塊中心發(fā)現(xiàn)的數(shù)據(jù)流安裝微流量條目。

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

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

　　為什么?

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

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

　　如何修復(fù)?

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

　　不出意外，沒有哪個(gè)虛擬機(jī)使用基于微流量的轉(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ā)模塊。