t.cn/rgjffwl
本次演講主要從未來的網路層面**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領域測試中的探索。
我們從2023年開始舉辦sdn/nfv測試活動，主要範圍在協議一致性測試、互通性測試。
2023年聯合onf舉辦國際性測試活動，共20余家廠商參與，交換機和控制器之間通過gre隧道進行跨洋測試。
2015推出of1.3協議一致性測試；在onf測試工作組參與控制器效能測試規範的編寫，發布sdn控制器效能測試***。
2023年推出sdn控制器效能測試工具，在onf測試工作組參與交換機效能測試規範的編寫，並推出sdn交換機效能測試。
2023年積極參與nfv測試工作，成為opnfv pharos lab，參與ovp beta測試，並推出第三方ovp測試。
從2023年起我們累計組織測試活動5次，廠商參與達60餘次，累計測試裝置共100餘次，累計測試解決方案16個。縱觀整個測試活動主要有功能測試、效能測試、互通測試這三項測試。功能測試包含openflow協議測試，sdn控制器集群功能、vnf功能測試。效能測試包含sdn控制器、交換機、nfvi平台網路二三層**以及vnf測試。互通測試包括sdn南向介面互操作性測試、北向介面相容性測試、東西向介面相容性測試、nfvi和vim與vnf及mano的互通測試。
單從總結上不能看出什麼問題，因此我們也梳理了一下這5次測試中所暴露的問題。首先前期由於大家對openflow協議實現的形式不同，導致溝通上出現或多或少的問題。近些年我們也積極組織對南向介面方面的測試，不過南向介面其實測試起來蠻困難的，因為除開openflow有乙個很標準的協議之外，其他的實現方式非常不同，導致這方面的互通測試難度非常大。
最後總結兩個趨勢。第一nfv的測試比重會逐漸增大，sdn則會由於各個廠商對openflow協議的實現趨於成熟，而在測試活動中的積極程度有所下降。第二因為測試內容由sdn轉向nfv互通測試成功率會逐步提高。
openflow1.3的一致性測試包括乙個控制通道的連線和四個資料通道的連線，主要用來測試openflow協議一致性，從15年正式推出到17年累計64款裝置通過of1.3協議一致性認證測試。通過29個測試組，342個測試用例終結openflow體現的協議內容，並且全部的測試協議一致性。
sdn交換機效能測試在提交到onf的測試工作組之後，由於onf的合併問題，導致該專案暫時擱淺。但是我們在推出該草案後也積極推出了sdn交換機效能測試的工具，在關鍵的發包的功能模組上做了一些優化，由於工具上層使用的是python，因此底層是用的c語言進行的重寫，總共包括了7個測試組和30個測試用例。
sdn控制器效能測試可能針對的是的單個控制器也可能是控制器集群。這套工具是我們完全基於c語言編寫的，做了一些多核多執行緒的優化，對cpu親和性進行了調整，使用了記憶體池和執行緒池的技術，通過環形緩衝區解決了tcp粘包的問題。
以前在測試裝置的時候，不管是用專用的硬體測試儀還是在通用伺服器上開發的測試工具都能很方便的測試。但是nfv組網相對複雜，既有底層的undelay網路又有虛擬機器之間的overlay網路。這種情況下測試拓撲其實是可以跟著演進，當然也可以使用傳統的方法將vnf當做黑盒來測試，只需要將外部的測試儀接到伺服器的特定介面上就行了。vnf之間的網路服務更多的可能是vnf串起來的服務功能鏈，這時要想進行內部的網路測試就需要用到虛擬測試儀，這個虛擬測試儀也可以當做是平台上的vnf，用來在虛擬機器之間的overlay網路中進行發包以及打流測試。
雖然目前nfv大多是基於虛擬化的平台，但是還是存在介面不同，整合難度大的問題。通過opnfv ovp測試能夠幫助建立基於opnfv基礎設施的市場，降低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只是單一物理機模擬的形式，主要由測試人員或測試人員解決整體環境部署過程中遇到的問題，也可以通過物理的方式針對開源的伺服器硬體或交換機硬體做一些更具體的配置工作。
從2023年開始我們已經做了很多積極的探索，後續也不會停下腳步，當然也不會一種沿用傳統的方式來做測試工作，而是要在雲時代的環境下推出更適合時代發展的測試服務。我們希望在後續的雲網融合時代推出乙個更為敏捷的平台，在該平台上能夠更靈活的選擇測試內容和範圍。
企業如何推動測試
企業如何推動測試 author vince 軟體測試是產品研發過程中的乙個重要環節，然而在國內軟體業發展的初期，這一環節時常被人們所拋棄。在如今國內軟體業蓬勃發展的今天，軟體系統逐漸龐大，軟體質量難以保證，因此軟體測試這一環節在軟體企業中不得不被重視，這已將成為軟體研發領域的一大熱門話題，那麼乙個企...
基礎設施即服務 PaaS, 平台即服務 IaaS
基礎設施即服務 infrastructure as a service，簡稱iaas 是消費者使用處理 儲存 網路以及各種基礎運算資源，部署與執行作業系統或應用程式等各種軟體。客戶端無須購買伺服器 軟體等網路裝置，即可任意部署和執行處理 儲存 網路和其它基本的計算資源，不能控管或控制底層的基礎設施，...
基於SDN,NFV的服務感知網路架構下篇
本篇文章是繼 基於sdn,nfv的服務感知網路架構上篇 對dpi進行進一步的深入解析，分析了在sdn中可能出現的三種部署情況，對第4 7層的業務需求以及業務感知網路架構作了乙個深入的介紹。在sdn網路中部署dpi sdn架構包括四個或者更多的層次，包括業務流層，業務應用層，控制層和節點層。下圖表示了...