為什么基于流量的轉發不適合虛擬機

時間:2018/6/21 17:45:25瀏覽次數:668
我想大家現在應該都清楚,基于流量的轉發并不適合現有硬件。為大流量設計的交換機,如轉發入口(NEC ProgrammableFlow交換機,Entersys 數據中心交換機等)

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

  定義

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

  在Open vSwitch中的微數據流轉發

  Open vSwitch的原始版本是基于理想微流的典型轉發架構:內核轉發模塊執行微流轉發,并將所有未知數據包發給用戶模式的后臺程序,然后,用戶模式的后臺程序會執行數據包檢查(使用OpenFlow轉發條目或其他轉發法則),并且為內核模塊中心發現的數據流安裝微流量條目。

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

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

  為什么?

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

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

  如何修復?

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

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

VIP客戶

  • 上海長寧煙草集團長寧煙草糖酒有限公司
  • 艾蒙斯特朗流體系統(上海)有限公司
  • 莫泰酒店上海桃浦店監控系統服務
  • 上海莘莊市容市政管理有限公司
  • 締展國際貿易(上海)有限公司
  • 康百世朝田液壓機電(中國)有限公司

咨詢電話:

021-51697581
掃一掃,關注官方微信
實時掌握逾仕最新動態
Copyright 2005-2021 逾仕科技(IT服務外包/系統集成), All Rights Reserved 備案/許可證號: 滬ICP備09088264號-6
021-51697581
在線客服

在線咨詢Online consulting

  • 點擊這里給我發消息
  • 點擊這里給我發消息
  • 點擊這里給我發消息
  • 點擊這里給我發消息
  • 點擊這里給我發消息
  • 點擊這里給我發消息
感謝您訪問逾仕官方網站,如果您有好的意見或建議,請與我們聯系!
400-880-7581