基于流量的轉(zhuǎn)發(fā)并不適合現(xiàn)有硬件的微流量設(shè)計

我想現(xiàn)在大家應(yīng)該都清楚了，基于流量的轉(zhuǎn)發(fā)并不適合現(xiàn)有的硬件。為大流量設(shè)計的交換機，例如轉(zhuǎn)發(fā)入口（NEC交換機、數(shù)據(jù)中心交換機等）可能是個例外

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

定義

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

Open中的微流轉(zhuǎn)發(fā)

Open的原始版本基于理想微流的典型轉(zhuǎn)發(fā)架構(gòu)：內(nèi)核轉(zhuǎn)發(fā)模塊執(zhí)行微流轉(zhuǎn)發(fā)并將所有未知數(shù)據(jù)包發(fā)送到用戶模式守護(hù)進(jìn)程，然后執(zhí)行數(shù)據(jù)包檢查（使用轉(zhuǎn)發(fā)條目或其他轉(zhuǎn)發(fā)規(guī)則），并為內(nèi)核模塊集線器發(fā)現(xiàn)的數(shù)據(jù)流安裝微流條目。

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

深入挖掘Open發(fā)現(xiàn)了一個有趣的東西：流量驅(qū)逐，一旦內(nèi)核模塊達(dá)到微流量的峰值，它就會拋出之前的流量武漢服務(wù)器運維，直到你意識到默認(rèn)峰值是2500微流量，這足夠一個網(wǎng)絡(luò)服務(wù)器。，而對于托管 50 或 100 臺虛擬機，數(shù)量級肯定太低了。

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

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

怎么修？

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

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