基于流量的轉發并不適合現有硬件的微流量設計

我想現在大家應該都清楚了，基于流量的轉發并不適合現有的硬件。為大流量設計的交換機，例如轉發入口（NEC交換機、數據中心交換機等）可能是個例外

，但即使他們無法處理反應式流媒體安裝所需的巨大流更新率，我們當然希望虛擬交換機性能更好，但不幸的是，事實并非如此。

定義

基于流的轉發有時被定義為單個傳輸層會話的轉發（有時稱為微流量），許多事實表明這種方法無法擴展，其他人將基于流的轉發定義為任何地址轉發，我不'不知道這些定義與 MPLS 類 (FEC) 有何不同，也不知道為什么我們需要使用新的和令人困惑的詞來定義它們。

Open中的微流轉發

Open的原始版本基于理想微流的典型轉發架構：內核轉發模塊執行微流轉發并將所有未知數據包發送到用戶模式守護進程，然后執行數據包檢查（使用轉發條目或其他轉發規則），并為內核模塊集線器發現的數據流安裝微流條目。

如果你還記得5000，你可能對交換機有一些不愉快的回憶武漢服務器運維，但是這個方案的問題應該是硬件和CPU的性能不佳。事實證明，虛擬交換機也好不了多少。

深入挖掘Open發現了一個有趣的東西：流量驅逐，一旦內核模塊達到微流量的峰值，它就會拋出之前的流量武漢服務器運維，直到你意識到默認峰值是2500微流量，這足夠一個網絡服務器。，而對于托管 50 或 100 臺虛擬機，數量級肯定太低了。

微流量緩存非常小，沒有明顯的效果，畢竟一個 web 服務器可以輕松處理 10,000 個會話，而一些基于 Linux 的負載均衡器可以控制每臺服務器多一個數量級的會話，可以增加默認的 OVS流量，有人會奇怪為什么默認值這么低？

我無法說明這可能的原因，但我懷疑它與單位流量計數有關 - 流量計數器必須定期從內核模塊轉到用戶模式守護程序。在相對較短的時間間隔內，在用戶內核插槽之間復制數千個流量計數器會占用大量 CPU 空間。

怎么修？

還不夠明顯嗎？放下所有基于微流量轉發的概念包袱，用傳統的方式來做，這就是OVS在1.11版本中所做的。OVS 1.11 在內核模塊中部署兆位流量，然后從內核重定向流量。發送到用戶模式代理（這很重要，因為內核轉發條目幾乎可以與用戶模式條目完全匹配）。

毫不奇怪，沒有一個虛擬機使用基于微流量的轉發。、Cisco Nexus 1000V 和 IBM 的 5000V 根據目的地的 MAC 地址做出轉發決策，Hyper-V 并根據目的地的 IP 地址做出轉發決策，甚至 NSX 用于分布式和核心內第 3 層轉發模塊。