《云數據中心網絡與SDN：技術架構與實現》——2.5　回歸軟件本源——從N到D再到S

2.5　回歸軟件本源——從N到D再到S

說到SDN，人們最常聯想到的有這么幾個詞，OpenFlow、數據中心虛擬化、廣域網優化。從最開始的喊口號到前幾年討論場景，目前SDN已經開始真正地沉淀技術，商業上也進入了加速落地的階段。或者也可以這么說，SDN近十年的發展逐步經歷了從理解網絡需求（Networking）到完善南向協議（Defined），再到打造健壯系統（Software）的過程。

在SDN的框架下，或者說在軟件的世界里，實現大部分現有的網絡功能都不會是一件太復雜的事情。拋開分布式協議的枷鎖后，網絡的創新再也不用等IEEE/IETF這些標準組織慢吞吞地輸出文檔了，用戶對網絡的需求會普遍轉向個性化的定制和敏捷的交付，是時候從廠商主導的傳統網絡思維轉向為用戶按需提供網絡服務的云計算思維了。

控制器是SDN向用戶交付的主要產品，既然控制器在網絡功能的實現方面足夠靈活，那么SDN控制器的擴展性、可用性與性能往往會超越接口協議和網絡業務本身，成為決定SDN能否商用的核心因素。因此，如何構建起一套可擴展、高可用的SDN控制器，才是推動SDN真正走向大規模落地的關鍵。

2.5.1　模塊管理

長久以來，垂直一體化的行業特性使得網絡技術的集合變得無比龐雜。雖然有標準協議的規范，但是各大廠商的產品之間，甚至同一廠商不同的產品線之間的設計區別都很大，跨廠商難于互通一直是用戶的一塊心病，這也導致了更為顯著的廠商鎖定現象。SDN除了能夠提升業務敏捷度以外，用戶同時還希望SDN能夠幫助他們擺脫對于廠商的依賴，從而在談判桌上拿到更多的話語權。除了肩負著驅動異構網絡設備的重任以外，SDN控制器還要承載各式各樣的網絡基礎服務的運行。因此，SDN控制器的目標應定位于在網絡基礎服務和設備驅動間構建起一個可擴展的、通用的網絡控制平臺。

早期的一些輕量級的開源SDN控制器，如Floodlight、POX和RYU等，用戶都需要在啟動前把需要加載的模塊在配置文件中事先指定好，或者在啟動的命令行中指定模塊。在控制器運行過程中，如果希望啟動另外一個模塊，需要把控制器關掉后修改配置文件重啟，或者在啟動命令行中指定新的參數。而且加入一個服務出錯了，那么整個控制器也就掛掉了。

上述問題在生產環境中顯然是不可接受的，因此OpenDaylight和ONOS在設計之初都采用了OSGi（面向Java的動態模型系統）的框架。在這類框架下，SDN控制器中只保留少數的用于平臺管理的核心模塊，而將各種網絡基礎服務和設備驅動看作可插拔的外圍模塊，這些模塊可以動態地加載/卸載到SDN控制器的核心中，各個模塊間能夠實現良好的隔離。這樣的好處在于，新的SDN服務的部署、測試或者上線，并不需要對控制器進行停機升級，以保證現有服務的可用性。如果新的SDN服務的運行出現了問題，通常也不會影響到其他現有服務的工作。相比于Java在企業級應用框架方面不可比擬的優勢，C/C++/Python在SDN控制器領域都暫時落在了下風。

網絡 SDN 邊緣數據中心管理 EDCM

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。