我(wǒ)(wǒ)想大(dà)家現在應該都清楚，基于流量的轉發并不适合現有硬件。爲大(dà)流量設計的交換機，如轉發入口(NEC ProgrammableFlow交換機，Entersys 數據中(zhōng)心交換機等)或許是個例外(wài)，但即便他們不能應付反應流安裝所要求的巨大(dà)數據流更新速度，我(wǒ)(wǒ)們當然期望虛拟交換機能運行更好，但遺憾的是，情況并非如此。

　　定義

　　基于流量的轉發有時候被定義爲單獨傳輸層對話(huà)的轉發(有時候被稱作是微流量)，大(dà)量事實表明這種方法不能做擴展，其他人将基于流量的轉發定義爲所有不是僅限目的地地址的轉發，我(wǒ)(wǒ)不了解這些定義欲MPLS Forwarding Equivalence Class (FEC)有何不同，也不知(zhī)道我(wǒ)(wǒ)們爲什麽要弄個新的令人費(fèi)解的詞語來定義。

　　在Open vSwitch中(zhōng)的微數據流轉發

　　Open vSwitch的原始版本是基于理想微流的典型轉發架構：内核轉發模塊執行微流轉發，并将所有未知(zhī)數據包發給用戶模式的後台程序，然後，用戶模式的後台程序會執行數據包檢查(使用OpenFlow轉發條目或其他轉發法則),并且爲内核模塊中(zhōng)心發現的數據流安裝微流量條目。

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

　　向Open vSwitch深入挖掘發現一(yī)個有意思的事情：流量驅逐，一(yī)旦内核模塊達到微流量的峰值，它就會抛出之前的流量，直到你意識到默認峰值爲2500微流量，這個數值已經足夠一(yī)個Web服務器使用，而對托管50或100個虛拟機的Hypervisor而言,數量級肯定太低。

　　爲什麽?

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

　　我(wǒ)(wǒ)不能說明造成這種情況的潛在原因，但我(wǒ)(wǒ)懷疑和單位流量計數有關——流量計數器必須周期性地從内核模塊轉到用戶模式後台程序。在比較短的間隔期裏，在用戶-内核槽之間複制成千上萬的流量計數器或許會占用很多CPU空間。

　　如何修複?

　　還不夠明顯嗎(ma)?放(fàng)下(xià)所有關于基于微流量轉發的概念包袱，按傳統方式來做，OVS在1.11版本中(zhōng)走的就是這個路子，OVS 1.11在内核模塊中(zhōng)部署了兆位流量，再從内核把流量發送到用戶模式OpenFlow代理那裏(因爲内核轉發條目幾乎可以與用戶模式OpenFlow條目做精确匹配，所以效果顯著)。

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