ONOS 太笨重：有 90 萬行代碼，擴展難，該分解了

軟體定義網路（SDN）已經改變了網路界格局，但在這個過程中也帶來了自身的問題。美國普渡大學的Doug Comer認為，對諸如開源網路操作系統（ONOS）之類的SDN控制器進行分解也許不失為一條出路。

Comer經歷了激動人心的互聯網早期階段，是互聯網架構委員會的成員，寫過探討網路的多本著作（數量之多堪稱小型圖書館），還開發了Xinu嵌入式操作系統。

他擔心，SDN可能會因變得過於笨重而無法擴展，這就是為什麼他的大名出現在了預印本平台arXiv上的這篇論文（https://arxiv.org/pdf/1901.02585.pdf）上，論文合著者是他在普渡大學計算機科學系的博士生Adib Rastegarnia。

該論文題為《對軟體定義網路中的數據包處理進行外部化》，提議正如當初SDN對專有網路界進行分解那樣對SDN進行分解。

而在硬體領域，這意味著拿來曾經在專用的專有設備中共存的功能，轉變成可以在通用計算機上運行的軟體。

然而SDN中存在一個問題：控制器本身已經變成了擁有大批貢獻者的龐大項目，這使控制器成為了要處理其環境中每路數據流的瓶頸。

Comer稱，ONOS含有「遠超100項」功能，太過繁瑣而笨重。在問世後的四年多時間裡，ONOS已吸引了近14000次代碼提交，擁有近90萬行代碼，這不是你輕鬆就能實時重新編譯的系統。

他和Rastegarnia提出的方案的基本思想是，其中一些功能應該從控制器分解出來。

架構

論文著重介紹的SDN架構特點包括：

整體式控制器不是模塊化的，無法在不引起干擾的情況下進行更新，可能無法擴展以適應未來的兆兆位網路；

SDN中充分利用REST協議（RESTful）的北向API標準化程度很低，依賴單單一個控制器；

面對不同的控制器，軟體模塊不容易重複使用。

今天的控制器採用了一種主動式方法，程序員要在其創建的數據流規則中涵蓋所有可能出現的情況。（論文認為，分解法將讓程序員得以開發能夠更好地響應變化的被動式管理應用程序。）

Comer稱，想法很簡單：不是把所有功能都放在ONOS中，讓ONOS做它擅長的事情，但是將功能與控制器分離開來，「而不是將所有功能都放在裡面、編譯一個無比龐大的映像。」

Comer表示，分解軟體時，「我們要做的就是將諸如創建路由或防火牆設置之類的服務移到控制器軟體本身外面。」

為什麼這麼做？他解釋道，因此這樣一來，分解式方法讓人們更容易將功能移到數據流所需的地方，而不是將數據包路由到某功能，處理數據包，然後將數據包發回到網路上。

不可否認，這種方法存在諸多風險，最主要的風險就是效率問題：與如今的SDN環境相比，處理和需要移動的消息數量方面都會帶來額外的開銷。

Comer 說：「每當你說分散式系統，有人會說『效率低下』，確實如此。它需要多大的開銷？有沒有一項技術能做到這一點？」

借鑒Kafka

正如論文所述，Comer和Rastegarnia選定了Apache Kafka消息傳遞環境。

他們決定實施消息路由作為控制器中的一個組件：它接收所有消息，決定哪些消息需要轉發、轉發到哪些功能以及如何最有效地傳遞消息。

Comer/Rastegarnia分解架構

消息傳遞架構是Comer /Rastegarnia論文的核心。

在SDN控制器中，Kafka消息分發應用程序將入站數據包的副本提供給外部進程。它偵聽入站數據包，並在集群上發布，外部管理應用程序和進程可以訪問這些數據包；

應用程序和服務使用HTTP請求來訂閱Kafka消息分發應用程序。

就目前而言，Comer表示，有必要記住arXiv上的這篇論文代表非常初步性的工作：它帶來的問題比解答的問題還多，而消息傳遞是最重要的問題之一。

然而，他認為該論文展示了分解方法的一個核心特點：控制器的角色簡化為處理諸如數據流設置、路由創建和轉發規則之類的任務。他稱：「如果你走那條路，我認為我們已經證明這條路是可行的。」

比如說，分解意味著，在10Gbps網路中，如果非核心網路功能轉變成微服務，就不再需要推送每個數據包或每路數據流通過控制器來傳輸。

他說：「如果我願意的話，可以將Docker容器放在任何地方並移動它。我可以將容器移到當前最合適的地方。」

「因此，不是將流量路由傳輸到網路功能在運行的物理伺服器，而是將功能移到更靠近數據流的地方。」比如說，可以複製防火牆之類的系統，以便可以為網路中的每個網路點啟動一個防火牆。

論文全文：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！