OpenFlow的架構是低效的,且限制了性能的改善,甚至還會造成不必要的功率損耗。
這是一串對比出來的結論,是來自澳大利亞brain box Data61和悉尼大學(Sydney University)的科研人員研究的結果,他們評估了四個主要的OpenFlow控制器NOX、Maestro、Floodlight、Beacon。論文發表在Arxiv平臺。
舊版本的OpenDaylight也進行了測試,但是并沒有形成任何報告:“舊版本的OpenDaylight性能太低,不能提供任何有見地的比較。”
參與測試的控制器沒有一個能夠接近線速,無論是在網絡處理器上運行(基于Tilera芯片),或基于Xeon E5-2450服務器(后期將在更高版本上測試)。
就CBench SDN控制器性能指標而言,最佳Tilera設置僅僅勉強達到了每秒500萬個請求,與每秒2900萬請求的最高線速比不相去甚遠。
由此可見Intel長期以來在數據包處理方面的工作卓有成效:在x86的設置下,Beacon能達到每秒2000萬請求;其他控制器最大值是每秒700萬請求。
Line rate? Forget it: the CSIRO/Data61/Sydney Uni benchmark results由于SDN控制器必須處理流量,這意味著他們必須記住MAC地址以便跟蹤通信,跟以太網交換機只需要知道轉發流量到哪個端口相比,其網絡的可擴展性也是一個大問題。
在性能指標里,沒有控制器能處理接近峰值的1000萬唯一MAC地址,基于Java語言的控制器(Beacon和Floodlight)在這方面的幾乎沒有創新。
該論文指出的問題是,OpenFlow本身的架構效率極其低下。作者提到了序列化:I/O現成;學習交換機應用的關鍵數據結構:哈希表。
序列化是迄今為止最大的支出:即使是最有效的控制器在處理數據包的序列化問題上也要花費總時間的五分之一,這個限制是面向對象的控制器設計原則固定的。他們都將每個單獨的數據包作為一個獨立的對象,這導致了每個數據包的開銷變得不可負擔。
作者的建議是謀求一個新的SDN控制器的設計方式,他們寫道:“將新到達的數據包設置預分配的緩沖區進行處理,而不是作為新的對象來處理。”控制器應該“在多核平臺中硬件特性的限制,或利用多核平臺的網絡級芯片。”
原文鏈接:http://www.theregister.co.uk/2016/08/22/sdncontrollerdesignsucksclaimnetworkboffins/