點擊上方藍字關注我們

多年以前，由于基于傳統協議的控制平面缺乏靈活性，無法滿足多樣的業務對數據平面的轉發需求，軟件定義網絡(SDN)被提了出來。業界希望通過一種轉控分離、開放解耦的架構，讓網絡資源能夠被上層應用通過標準的API，更加靈活的按需分配。在這種架構下，SDN控制器提供北向接口給上層應用，實現網絡資源的動態管理；并通過OpenFlow、NETCONF、SNMP、RESTCONF等南向接口控制底層網絡設備數據平面轉發行為及設備管理。可見，SDN控制器的架構以及南向接口是SDN的關鍵技術點，不夸張的說，這兩方面是決定整個SDN方案成敗的關鍵因素。在控制器領域，盡管OpenDaylight，ONOS和Ryu等開源系統已經逐漸被各個廠家和用戶所接受，但由于南向接口OpenFlow的天然缺陷以及單體架構控制器的日漸臃腫，使得基于傳統架構和技術的SDN解決方案，遲遲無法達到最初的設計理念，很難適應業務對網絡的需求。

從本期開始，小編將連續出三篇系列文章，以ONOS(開放網絡操作系統)為例，詳細分析控制器的架構、網絡設備可編程接口的發展趨勢，解析以去中心化、云原生、協議無關為設計目標的下一代SDN體系結構，并分享星融在這方面的最新實踐。

什么是ONOS？

ONOS是領先的開源SDN控制器，被廣泛應用于構建下一代SDN / NFV解決方案。它為SDN提供控制平臺和管理網絡的組件(例如交換機和鏈接)，并運行網絡應用程序提供通信服務。如果您熟悉傳統的嵌入式交換機操作系統，則會發現ONOS可以管理整個網絡而不是單個設備，可以大大簡化多臺交換機的軟硬件配置管理和部署。如果您熟悉SDN控制器，則應該感到賓至如歸，因為ONOS是一個可擴展的模塊化的分布式SDN控制器。

接下來我們看看ONOS的設計原則和總體架構。

ONOS的設計遵循四條基本原則：

第一，高可用性，高可擴展性和高性能；

第二，要對網絡資源進行高度抽象并簡練地表示出來；

第三，要做到協議無關及硬件無關；

第四，網絡應用程序的模塊化。

? ? ? ? ? ? ? ? ? ? ?? ?圖1?ONOS的總體架構

? ? ? ONOS整體架構可分為三層，分別為：

1、北向接口(NBI)，應用程序使用這些接口來了解網絡狀態(例如遍歷拓撲圖、攔截網絡數據包)，并控制網絡數據平面。

2、分布式核心，負責管理網絡狀態，并將狀態的變化通知給網絡應用程序。核心層內部使用的數據庫是可擴展的分布式鍵/值存儲數據庫Atomix。

3、南向接口(SBI)，由共享協議庫和特定設備的驅動程序構成的插件集合。

接下來我們主要介紹下分布式核心和南向接口層如何通過P4runtime協議與設備交互。

分布式核心

ONOS分布式核心由許多子系統組成，子系統負責網絡拓撲、主機跟蹤、數據包攔截、流編程等的維護和管理。主要的子系統有：

• Device Subsystem- 管理網絡設備集群

• Link Subsystem- 管理網絡鏈路

• Host Subsystem- 管理主機及其在網絡上的位置

• Topology Subsystem- 管理網絡拓撲及實時狀態的更新

• Packet Subsystem- 允許應用程序收發業務報文(從/往網絡設備)

• Path Subsystem-計算/查找網絡設備之間或終端主機之間的路徑

• FlowRule Subsystem- 管理網絡設備的流表規則

這些服務大多是使用分布式表(映射)構建的，而這些表存儲在atomix數據庫中，接下來讓我們來看下Atomix數據庫。

它可以跨一組分布式服務器進行擴展，并實現故障時的容錯處理。Atomix是構建分布式系統的通用工具，它是一個基于Java開發的系統，其支持以下功能特性：

• 分布式數據結構，包括maps、sets、trees、counters

• 分布式通信，包括直接消息傳遞和發布/訂閱

• 分布式協作，包括locks、leader elections、barriers

• 管理群組成員

Atomix在ONOS中的一個重要作用是協調ONOS的所有實例，主要體現在兩個方面：首先，ONOS具備水平可擴展的能力，在任何時間運行的ONOS實例的數量取決于工作的負載情況和在出現故障時為保證系統可用性所需的備份情況。Atomix group membership原語用于確定可用實例的集合，從而可以檢測到已轉換的新實例和已失敗的現有實例。其次，每個ONOS實例的主要工作是監視和控制網絡中物理交換機的子集。ONOS采取的方法是為每個交換機選擇一個主實例，只有主實例可以向給定的交換機發出(寫入)控制指令，而所有實例都可以監視(讀取)交換機狀態。這些實例使用Atomix leader-election原語來確定每個交換機的主實例(主控制器)。如果一個ONOS實例發生故障，則使用相同的原語為交換機選擇新的主控制器。當有新交換機上線時也采用相同的方法來為其選舉主實例。接下來看看ONOS是如何實現對P4Runtime的支持。P4Runtime在傳統SDN方案中，OpenFlow一直被看做是控制底層網絡數據平面的理想接口之一，但由于硬件支持度不高，在實際部署中并未達到預期效果。P4Runtime作為一種控制器和網絡設備之間的數據轉發控制接口，和OpenFlow同樣具備協議無關性，是一套基于Protobuf和gRPC框架定義的協議。通過P4Runtime協議，SDN控制器可以控制配置支持P4的網絡設備。現在P4是數據平面可編程的主流代表，其匹配域和動作域可以任意定制，流表流水線也可以根據網絡需求的改變而修改。ONOS是如何支持流水線可變性的呢？首先，ONOS為了解決這個問題，在Core層諸多子系統中橫向擴展了一個子系統，叫做PI 框架。PI = Protocol/Program/Pipeline Independent，代表了協議無關、程序無關、以及處理流水線的無關。PI框架是圍繞著P4和PSA進行建模的，但PI框架在設計上是面向通用的協議無關思想的，能容納未來各種協議無關的語言或者協議，目前僅僅是適配到了P4語言。PSA(Portable Switch Architecture)就是P4設備的一個通用架構描述，類似OpenFlow的TTP(Table Type Patterns)。PI架構里包含了一些類、服務和設備驅動的功能描述來建模和控制可編程數據平面，定義了抽象的表項和計數器等等。圖2：? PI框架在ONOS中的架構設計首先，最底層是協議插件，有P4 Runtime和gRPC；往上一層是Driver子系統，有P4Runtime、Tofino和BMv2等；最上層是核心層也是PI框架核心所在，它包含了PI模型、FlowRuleTranslation子系統和還有Pipeconf子系統等三大模塊。而流水線流表可變性?實現的關鍵，就是這個FlowRuleTranslation子系統，下文統稱為“流表翻譯子系統”。PI框架向上既可以支持pipeline無感知的應用，比如之前針對OpenFlow設備編寫的程序?；也可以支持對Pipeline有感知的應用，也就是針對特定的P4程序編寫的控制應用。接下來介紹下流表翻譯子系統：

? ? ? ? ? ? ? ? ? ???圖3 FlowRule Translation

PI框架里的流表操作涉及到三個階段的轉換操作，分別對應Pipeliner、Interpreter、P4Info這三個元素，也就是上圖中的藍色部分，是我們pipeconf(.oar)應用里的內容。如果我們使用FlowObjective來下發決策，就會經過Pipeliner把它轉換成FlowRule，當然我們也可以直接使用FlowRule。然后P4設備驅動會調用PI框架的FlowRuleTranslation 子系統，借助Pipeline Interpreter把FlowRule轉換成PI Table Entry，它是PI框架對一條表項的抽象。最后PI Table Entry會在南向協議插件的P4Runtime Client中借助P4Info轉換成P4 Runtime Message這個通信報文，然后在網絡中傳遞給P4設備。如上圖3所示，流表操作主要就是三次轉換。介紹完分布式核心和P4Runtime，讓我們來看看ONOS的發展現狀。ONOS的發展現狀隨著ONOS 2.0版本的發布，當今的ONOS架構提供了一個穩定的基礎平臺，包含了許多的功能特性，例如簡單的第三方應用開發、輕松的分布式集群部署、服務自動導入、已存在大量的第三方應用和拓展組件。但是，ONOS架構當前也同樣存在一些限制，比如有限的資源隔離、基于平臺的應用僅支持java或JVM-based語言開發；比如應用/服務水平擴展困難、組件無法遷移到平臺之外(控制平面功能無法卸載到設備)；再比如與NFV的集成受限且對NFV的支持也同樣有限等等。盡管上述限制在本質上都是技術性的，但它們還是限制了ONOS在一些重要的行業場景中的應用，因此我們必須解決ONOS的這些限制。ONF(Open Network Foundation)正在開發一個新的開源架構Micro ONOS(μONOS)以提供真實網絡控制、零接觸配置和可驗證/安全的網絡，并使運營商可以完全控制其網絡?，這也是下一代SDN的發展趨勢。那么μONOS架構到底如何呢？下篇文章再做介紹。

點點在看行不行

---

總結

以上是生活随笔為你收集整理的modbus报文解析实例_云原生、全栈可编程的下一代SDN解析与实践 （一）丨传统SDN架构演进...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。