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

　　定義

　　基于流量的(de)轉發有時(shí)候被定義爲單獨傳輸層對(duì)話(huà)的(de)轉發(有時(shí)候被稱作是微流量)，大(dà)量事實表明(míng)這(zhè)種方法不能做(zuò)擴展，其他(tā)人(rén)将基于流量的(de)轉發定義爲所有不是僅限目的(de)地地址的(de)轉發，我不了(le)解這(zhè)些定義欲MPLS Forwarding Equivalence Class (FEC)有何不同，也(yě)不知道我們爲什(shén)麽要弄個(gè)新的(de)令人(rén)費解的(de)詞語來(lái)定義。

　　在Open vSwitch中的(de)微數據流轉發

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

　　如果你還(hái)記得(de)Catalyst 5000，或許你會想起Netflow交換機一些令人(rén)不愉快(kuài)的(de)記憶，但這(zhè)個(gè)方案的(de)問題應該是硬件和(hé)CPU的(de)性能不佳造成的(de)。事實表明(míng)，虛拟交換機也(yě)不會好到哪兒(ér)去。

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

　　爲什(shén)麽?

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

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

　　如何修複?

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

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