點(diǎn)擊上方藍(lán)字關(guān)注我們

多年以前，由于基于傳統(tǒng)協(xié)議的控制平面缺乏靈活性，無(wú)法滿(mǎn)足多樣的業(yè)務(wù)對(duì)數(shù)據(jù)平面的轉(zhuǎn)發(fā)需求，軟件定義網(wǎng)絡(luò)(SDN)被提了出來(lái)。業(yè)界希望通過(guò)一種轉(zhuǎn)控分離、開(kāi)放解耦的架構(gòu)，讓網(wǎng)絡(luò)資源能夠被上層應(yīng)用通過(guò)標(biāo)準(zhǔn)的API，更加靈活的按需分配。在這種架構(gòu)下，SDN控制器提供北向接口給上層應(yīng)用，實(shí)現(xiàn)網(wǎng)絡(luò)資源的動(dòng)態(tài)管理；并通過(guò)OpenFlow、NETCONF、SNMP、RESTCONF等南向接口控制底層網(wǎng)絡(luò)設(shè)備數(shù)據(jù)平面轉(zhuǎn)發(fā)行為及設(shè)備管理。可見(jiàn)，SDN控制器的架構(gòu)以及南向接口是SDN的關(guān)鍵技術(shù)點(diǎn)，不夸張的說(shuō)，這兩方面是決定整個(gè)SDN方案成敗的關(guān)鍵因素。在控制器領(lǐng)域，盡管OpenDaylight，ONOS和Ryu等開(kāi)源系統(tǒng)已經(jīng)逐漸被各個(gè)廠(chǎng)家和用戶(hù)所接受，但由于南向接口OpenFlow的天然缺陷以及單體架構(gòu)控制器的日漸臃腫，使得基于傳統(tǒng)架構(gòu)和技術(shù)的SDN解決方案，遲遲無(wú)法達(dá)到最初的設(shè)計(jì)理念，很難適應(yīng)業(yè)務(wù)對(duì)網(wǎng)絡(luò)的需求。

從本期開(kāi)始，小編將連續(xù)出三篇系列文章，以O(shè)NOS(開(kāi)放網(wǎng)絡(luò)操作系統(tǒng))為例，詳細(xì)分析控制器的架構(gòu)、網(wǎng)絡(luò)設(shè)備可編程接口的發(fā)展趨勢(shì)，解析以去中心化、云原生、協(xié)議無(wú)關(guān)為設(shè)計(jì)目標(biāo)的下一代SDN體系結(jié)構(gòu)，并分享星融在這方面的最新實(shí)踐。

什么是ONOS？

ONOS是領(lǐng)先的開(kāi)源SDN控制器，被廣泛應(yīng)用于構(gòu)建下一代SDN / NFV解決方案。它為SDN提供控制平臺(tái)和管理網(wǎng)絡(luò)的組件(例如交換機(jī)和鏈接)，并運(yùn)行網(wǎng)絡(luò)應(yīng)用程序提供通信服務(wù)。如果您熟悉傳統(tǒng)的嵌入式交換機(jī)操作系統(tǒng)，則會(huì)發(fā)現(xiàn)ONOS可以管理整個(gè)網(wǎng)絡(luò)而不是單個(gè)設(shè)備，可以大大簡(jiǎn)化多臺(tái)交換機(jī)的軟硬件配置管理和部署。如果您熟悉SDN控制器，則應(yīng)該感到賓至如歸，因?yàn)镺NOS是一個(gè)可擴(kuò)展的模塊化的分布式SDN控制器。

接下來(lái)我們看看ONOS的設(shè)計(jì)原則和總體架構(gòu)。

ONOS的設(shè)計(jì)遵循四條基本原則：

第一，高可用性，高可擴(kuò)展性和高性能；

第二，要對(duì)網(wǎng)絡(luò)資源進(jìn)行高度抽象并簡(jiǎn)練地表示出來(lái)；

第三，要做到協(xié)議無(wú)關(guān)及硬件無(wú)關(guān)；

第四，網(wǎng)絡(luò)應(yīng)用程序的模塊化。

? ? ? ? ? ? ? ? ? ? ?? ?圖1?ONOS的總體架構(gòu)

? ? ? ONOS整體架構(gòu)可分為三層，分別為：

1、北向接口(NBI)，應(yīng)用程序使用這些接口來(lái)了解網(wǎng)絡(luò)狀態(tài)(例如遍歷拓?fù)鋱D、攔截網(wǎng)絡(luò)數(shù)據(jù)包)，并控制網(wǎng)絡(luò)數(shù)據(jù)平面。

2、分布式核心，負(fù)責(zé)管理網(wǎng)絡(luò)狀態(tài)，并將狀態(tài)的變化通知給網(wǎng)絡(luò)應(yīng)用程序。核心層內(nèi)部使用的數(shù)據(jù)庫(kù)是可擴(kuò)展的分布式鍵/值存儲(chǔ)數(shù)據(jù)庫(kù)Atomix。

3、南向接口(SBI)，由共享協(xié)議庫(kù)和特定設(shè)備的驅(qū)動(dòng)程序構(gòu)成的插件集合。

接下來(lái)我們主要介紹下分布式核心和南向接口層如何通過(guò)P4runtime協(xié)議與設(shè)備交互。

分布式核心

ONOS分布式核心由許多子系統(tǒng)組成，子系統(tǒng)負(fù)責(zé)網(wǎng)絡(luò)拓?fù)洹⒅鳈C(jī)跟蹤、數(shù)據(jù)包攔截、流編程等的維護(hù)和管理。主要的子系統(tǒng)有：

• Device Subsystem- 管理網(wǎng)絡(luò)設(shè)備集群

• Link Subsystem- 管理網(wǎng)絡(luò)鏈路

• Host Subsystem- 管理主機(jī)及其在網(wǎng)絡(luò)上的位置

• Topology Subsystem- 管理網(wǎng)絡(luò)拓?fù)浼皩?shí)時(shí)狀態(tài)的更新

• Packet Subsystem- 允許應(yīng)用程序收發(fā)業(yè)務(wù)報(bào)文(從/往網(wǎng)絡(luò)設(shè)備)

• Path Subsystem-計(jì)算/查找網(wǎng)絡(luò)設(shè)備之間或終端主機(jī)之間的路徑

• FlowRule Subsystem- 管理網(wǎng)絡(luò)設(shè)備的流表規(guī)則

這些服務(wù)大多是使用分布式表(映射)構(gòu)建的，而這些表存儲(chǔ)在atomix數(shù)據(jù)庫(kù)中，接下來(lái)讓我們來(lái)看下Atomix數(shù)據(jù)庫(kù)。

它可以跨一組分布式服務(wù)器進(jìn)行擴(kuò)展，并實(shí)現(xiàn)故障時(shí)的容錯(cuò)處理。Atomix是構(gòu)建分布式系統(tǒng)的通用工具，它是一個(gè)基于Java開(kāi)發(fā)的系統(tǒng)，其支持以下功能特性：

• 分布式數(shù)據(jù)結(jié)構(gòu)，包括maps、sets、trees、counters

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

• 分布式協(xié)作，包括locks、leader elections、barriers

• 管理群組成員

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

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

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

點(diǎn)點(diǎn)在看行不行

---

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。