網絡發展遭遇瓶頸期,如何推動SDN

網絡發展遭遇瓶頸期,如何推動SDN/NFV解決困局?

內容來源:2017 年 11 月 29 日,高級工程師唐志軍在“GNTC全球網絡技術大會2017”進行《測試即服務推動SDN/NFV技術發展與產業落地》演講分享。IT 大咖說作為獨家視頻合作方,經主辦方和講者審閱授權發佈。

閱讀字數:3467 | 9分鐘閱讀

嘉賓演講視頻回放及PPT,請複製鏈接:http://t.cn/RgdaKYx,粘貼至瀏覽器地址欄即可。

網絡發展遭遇瓶頸期,如何推動SDN/NFV解決困局?

摘要

本次演講主要從未來的網絡層面探討SDN/NFV所能帶來的技術優勢,通過實際的測試又是如何推動SDN/NFV的發展和產業落地。

SDN/NFV技術優勢與測試挑戰

隨著網絡發展遇到瓶頸創新變得越發困難,這時SDN以一種控制和轉發分離的可編程形式出現在大家視野中,它讓網絡的配置更加靈活,讓編程人員能自由的決定網絡的轉發形態。

NFV從14年開始浮出水面,現在也越發火熱,它主要是接入了雲計算技術,在虛擬化的形式上將很多原先要依賴專有硬件的東西實現了軟件化,一定程度上打破了專有硬件壟斷趨勢。這種基於虛擬化的技術一方面充分利用了所有通用服務器硬件資源,另一方面獲得很好的水平擴展能力。

我們所理解的SDN加NFV將來的終極形式就是一種智能網絡,改變了原先網絡的封閉和配置複雜的情況,用戶可以根據實際需求用通俗易懂的方式完成網絡的配置,也能夠輕鬆的驗證網絡配置是否符合要求。

測試挑戰

SDN加NFV的引入不光帶來了優勢,同時也帶來了複雜性。以SDN來說控制面和數據面已被分離,一旦網絡出現問題,需要分別對他們進行調試,包括接口協議一致性和設備性能都需要測試。NFV由於是基於虛擬化技術,所以整體平臺組件眾多,接口龐雜,配置項多,調試也變的複雜。

SDN加NFV的方案可能會涉及到軟硬聯調,端到端的業務中斷難以推斷錯誤位置。

SDN/NFV測試挑戰主要是在測試範圍、測試複雜度、測試頻率三個方面。

測試範圍方面如果傳統的硬件網絡採用的是專一的廠商,測試起來可以很方便,而SDN/NFV打破了專有硬件的壟斷,在多廠商、多設備、多功能模塊的情況下測試範圍就變得非常廣了,除了要調試硬件還需要調試軟件。

隨著硬件越來越開放,接口越來越多 ,不同廠商不同功能模塊進行集成的時候,測試複雜度比單一網絡形態或單一廠商的產品解決方案要高很多。一方面基於雲計算的NFV解決方案,要更清晰的定義測試出來的結果能否滿足實際的用戶需求。另一方面由於NFV是軟硬結合,更多的服務是以VNF的形式出現,也就是說基本單位是一個鏡像,這個鏡像涉及到整個平臺的CPU和內存以及其他硬件的使用情況,在滿足服務質量的同時,也要對硬件資源的使用情況進行更緊密的結合分析,以確定服務是否能夠更優化。

軟件領域的持續集成和持續部署是很必要的方式,在成熟的軟件領域每個版本或功能的變化都要去做測試,頻繁的補丁更新帶來的必然是測試頻率的加快。

我們在SDN/NFV測試中的探索

這裡簡要的梳理下我們在SDN和NFV領域測試中的探索。

我們從2013年開始舉辦SDN/NFV測試活動,主要範圍在協議一致性測試、互通性測試。

2014年聯合ONF舉辦國際性測試活動,共20餘家廠商參與,交換機和控制器之間通過GRE隧道進行跨洋測試。

2015推出OF1.3協議一致性測試;在ONF測試工作組參與控制器性能測試規範的編寫,發佈SDN控制器性能測試白皮書。

2016年推出SDN控制器性能測試工具,在ONF測試工作組參與交換機性能測試規範的編寫,並推出SDN交換機性能測試。

2017年積極參與NFV測試工作,成為OPNFV Pharos Lab,參與OVP Beta測試,並推出第三方OVP測試。

測試總覽

從2013年起我們累計組織測試活動5次,廠商參與達60餘次,累計測試設備共100餘次,累計測試解決方案16個。縱觀整個測試活動主要有功能測試、性能測試、互通測試這三項測試。功能測試包含OpenFlow協議測試,SDN控制器集群功能、VNF功能測試。性能測試包含SDN控制器、交換機、NFVI平臺網絡二三層轉發以及VNF測試。互通測試包括SDN南向接口互操作性測試、北向接口兼容性測試、東西向接口兼容性測試、NFVI和VIM與VNF及MANO的互通測試。

暴露的問題

單從總結上不能看出什麼問題,因此我們也梳理了一下這5次測試中所暴露的問題。首先前期由於大家對OpenFlow協議實現的形式不同,導致溝通上出現或多或少的問題。近些年我們也積極組織對南向接口方面的測試,不過南向接口其實測試起來蠻困難的,因為除開OpenFlow有一個很標準的協議之外,其他的實現方式非常不同,導致這方面的互通測試難度非常大。

最後總結兩個趨勢。第一NFV的測試比重會逐漸增大,SDN則會由於各個廠商對OpenFlow協議的實現趨於成熟,而在測試活動中的積極程度有所下降。第二因為測試內容由SDN轉向NFV互通測試成功率會逐步提高。

OF1.3一致性認證測試

OpenFlow1.3的一致性測試包括一個控制通道的連接和四個數據通道的連接,主要用來測試OpenFlow協議一致性,從15年正式推出到17年累計64款設備通過OF1.3協議一致性認證測試。通過29個測試組,342個測試用例終結OpenFlow體現的協議內容,並且全部的測試協議一致性。

SDN交換機性能測試

SDN交換機性能測試在提交到ONF的測試工作組之後,由於ONF的合併問題,導致該項目暫時擱淺。但是我們在推出該草案後也積極推出了SDN交換機性能測試的工具,在關鍵的發包的功能模塊上做了一些優化,由於工具上層使用的是Python,因此底層是用的C語言進行的重寫,總共包括了7個測試組和30個測試用例。

SDN控制器性能測試

SDN控制器性能測試可能針對的是的單個控制器也可能是控制器集群。這套工具是我們完全基於C語言編寫的,做了一些多核多線程的優化,對CPU親和性進行了調整,使用了內存池和線程池的技術,通過環形緩衝區解決了TCP粘包的問題。

NFVI網絡性能測試

以前在測試設備的時候,不管是用專用的硬件測試儀還是在通用服務器上開發的測試工具都能很方便的測試。但是NFV組網相對複雜,既有底層的undelay網絡又有虛擬機之間的overlay網絡。這種情況下測試拓撲其實是可以跟著演進,當然也可以使用傳統的方法將VNF當做黑盒來測試,只需要將外部的測試儀接到服務器的特定接口上就行了。VNF之間的網絡服務更多的可能是VNF串起來的服務功能鏈,這時要想進行內部的網絡測試就需要用到虛擬測試儀,這個虛擬測試儀也可以當做是平臺上的VNF,用來在虛擬機之間的Overlay網絡中進行發包以及打流測試。

OPNFV OVP 與ONF CORD測試介紹

OPNFV OVP測試

雖然目前NFV大多是基於虛擬化的平臺,但是還是存在接口不同,集成難度大的問題。通過OPNFV OVP測試能夠幫助建立基於OPNFV基礎設施的市場,降低NFV最終用戶的使用風險,通過驗證硬件和軟件平臺接口以及各個組件來降低企業測試的成本。

ONF CORD測試

網絡發展遭遇瓶頸期,如何推動SDN/NFV解決困局?

上圖是CORD的原型設計和架構,主要包含RCORE、ECORD、MCORD。這裡對CORD的原理就不多做介紹,主要還是談下CORD官方推出的測試環境。

該測試環境中有一個Cord in a-Box的方式,這是一個完整的解決方案或者說是Cord環境。不過Cord在國內的部署難度很大,它使用的一些鏡像在國內的訪問速度非常的慢,在搭建Cord in a-Box中會遇到很多問題。後續Cord又提出了CATS(Cord自動化測試系統),包含了一個以容器的方式運行的測試套件Cord Tester。Cord in a-Box只是單一物理機模擬的形式,主要由測試人員或測試人員解決整體環境部署過程中遇到的問題,也可以通過物理的方式針對開源的服務器硬件或交換機硬件做一些更具體的配置工作。

雲網融合時代下的測試即服務

從2013年開始我們已經做了很多積極的探索,後續也不會停下腳步,當然也不會一種沿用傳統的方式來做測試工作,而是要在雲時代的環境下推出更適合時代發展的測試服務。我們希望在後續的雲網融合時代推出一個更為敏捷的平臺,在該平臺上能夠更靈活的選擇測試內容和範圍。

以上為今天的全部分享內容,謝謝大家!


分享到:


相關文章: