隨著互聯網和數據中心流量的爆炸式增長，SDN已經逐步取代靜態(tài)路由交換設備成為構建網絡的主流方式，本系列是免費電子書《Software-Defined Networks: A Systems Approach》的中文版椿浓，完整介紹了SDN的概念、原理、架構和實現方式。原文: Software-Defined Networks: A Systems Approach

第6章 網絡操作系統(tǒng)(Network OS)

現在爽室，我們準備好從只有單一本地狀態(tài)的獨立交換機，轉向由網絡操作系統(tǒng)維護的全局淆攻、全網視圖阔墩。思考NOS的最佳方式是認識到它和其他可水平伸縮的云應用程序一樣，是由一組松散耦合的子系統(tǒng)(通常與微服務體系架構相關聯)組成瓶珊，包括一個可伸縮的高可用鍵/值存儲啸箫。

本章以ONOS作為參考實現，介紹NOS的總體架構艰毒。其主要核心抽象是基于ONOS實現廣泛的控制程序筐高，并管理同樣廣泛的網絡設備。本章還將討論可伸縮性和高可用性這兩個至關重要的問題丑瞧。

6.1 架構

我們以ONOS為模型，Network OS的架構如圖30所示蜀肘，由三個主要部分組成:

1. 北向接口(NBI)集合绊汹，應用程序通過這些接口保持網絡狀態(tài)(例如拓撲圖穿透，攔截網絡數據包)扮宠，也用來控制網絡數據平面(例如西乖，通過第三章介紹的FlowObjective API對流對象編程)。
2. 分布式核心坛增，負責管理網絡狀態(tài)获雕，并通知應用程序該狀態(tài)的相關更改。核心內部是一個可伸縮的鍵/值存儲收捣，稱為Atomix届案。
3. 由一組插件組成的南向接口(SBI)，包括共享協(xié)議庫和特定于設備的驅動程序罢艾。

圖30. ONOS三層架構楣颠，托管一組控制應用。

如圖30所示咐蚯，這是高度模塊化的設計童漩，對于特定部署可以配置包含所需的子模塊。我們將在最后一節(jié)討論模塊化的確切形式(例如Karaf, Kubernetes)春锋，同時會討論可伸縮性問題矫膨。在此之前，重點是ONOS功能的組織形式。

在深入了解每一層細節(jié)之前侧馅，關于圖30還有三件事需要注意直奋。首先是NBI的廣度。如果將ONOS視為操作系統(tǒng)施禾，這就說得通了脚线，所有對底層硬件的訪問，無論是通過控制程序還是人工運維弥搞，都以ONOS作為中介邮绿。這意味著所有北向API組合在一起必須足以完成網絡的配置、運維和控制攀例。例如船逮，北向接口包括gNMI和gNOI，分別用于配置和運維粤铭。同時也意味著NBI包括一個拓撲API挖胃，控制程序通過它來了解底層網絡狀態(tài)的變化(例如，端口是否可工作)梆惯，以及用于控制底層交換機的FlowObjective API酱鸭。

說個題外話，雖然我們通常把運行在Network OS上的應用程序視為網絡控制平面的實現垛吗，但實際上有各種各樣的應用程序運行在ONOS上凹髓，通過其GUI，可以實現從網絡狀態(tài)監(jiān)控到運維人員用來發(fā)布指令的傳統(tǒng)CLI的一切怯屉。

基于ONOS的應用程序包含零接觸管理平面蔚舀，幫助網絡配置新硬件，確保安裝正確的軟件锨络、證書赌躺、配置參數和流水線定義。如圖31所示羡儿，其引申結論是ONOS沒有固定的NBI礼患，在ONOS上可能有多層應用程序和服務失受，每一層都在其下方的應用程序和服務之上提供更多價值讶泰。無論是聲明在ONOS中提供零接觸配置還是基于ONOS之上提供零接觸配置都是武斷的余寥，這引申出了ONOS與傳統(tǒng)操作系統(tǒng)不同的一個重要方面: 沒有系統(tǒng)調用等效接口來區(qū)分內核特權域和用戶域之間的邊界幻碱。換句話說，ONOS目前運行在單個信任域中凯楔。

圖31. Zero-Touch Provisioning(ZTP)應用程序示例，為被安裝的交換機提供"角色規(guī)范"济似，ONOS為交換機提供相應的配置矫废。

關于圖30要注意的第二點是，ONOS將控制程序希望施加在網絡上的行為的抽象規(guī)范映射到需要與網絡中每個交換機通信的具體指令上砰蠢。應用程序可以從多種方式中選擇影響網絡運行的方式蓖扑。一些應用程序使用高級意圖(Intents)，是網絡范圍內的台舱、與拓撲無關的編程結構律杠。其他需要更細粒度控制的使用Flow Objectives，這是一種以設備為中心的編程構造。Flow Objectives很像流規(guī)則柜去，只不過它們是獨立于流水線的灰嫉。應用程序使用它們來控制固定功能流水線和可編程流水線。如圖32中突出顯示的那樣嗓奢，ONOS被明確設計用來解決在面對各種各樣的轉發(fā)流水線時完成工作所面臨的復雜性讼撒。

圖32. ONOS管理著網絡范圍內行為的抽象規(guī)范映射到每個設備的指令集合。

關于圖30要注意的第三點是股耽，信息通過ONOS同時"向下"和"向上"流動根盒。我們很容易關注到應用程序通過ONOS NBI來控制網絡，但南向插件也會將底層網絡的信息傳遞給ONOS核心豺谈，包括攔截數據包郑象、發(fā)現設備及其端口、報告鏈路質量等茬末。ONOS核心和網絡設備之間的交互是由一組適配器(例如厂榛，OpenFlow, P4Runtime)來處理的，這些適配器隱藏了與設備通信的細節(jié)丽惭，從而將ONOS核心和運行其上的應用程序與多樣化的網絡設備解耦击奶，從而ONOS可被用于控制私有交換機、裸金屬交換機责掏、光設備和蜂窩基站柜砾。

6.2 分布式核心(Distributed Core)

ONOS核心由許多子系統(tǒng)組成，每個子系統(tǒng)負責網絡狀態(tài)的特定方面(例如拓撲結構换衬、主機跟蹤痰驱、包攔截、流編程)瞳浦。每個子系統(tǒng)維護自己的服務抽象(service abstraction)担映，其實現負責在整個集群中傳播狀態(tài)。

許多ONOS服務是通過分布式表(map)構建的叫潦，而分布式表又使用分布式鍵/值存儲來實現蝇完。對于看過現代云服務設計的人來說，應該對這類存儲很熟悉矗蕊，它可以跨一組分布式服務器進行擴展短蜕，并實現一種共識算法來在發(fā)生故障時實現容錯。ONOS中使用的具體算法是Raft傻咖，在Diego Ongaro和John Ousterhout的一篇論文中有很好的描述朋魔，下面提供的網站還有一個很好用的可視化工具。

延伸閱讀:
D. Ongaro and J. Ousterhout. The Raft Consensus Algorithm.

ONOS使用Atomix作為其存儲没龙，Atomix在核心Raft算法的基礎上提供了一組豐富的編程原語铺厨，ONOS使用這些原語來管理分布式狀態(tài)缎玫，并為控制程序提供提供了訪問狀態(tài)的簡單接口。

6.2.1 Atomix原語

前面將Atomix介紹為鍵/值存儲解滓，事實確實如此赃磨，但也可以將Atomix描述為構建分布式系統(tǒng)的通用工具，它是一個基于Java的系統(tǒng)洼裤，支持:

• 分布式數據結構邻辉，包括map、set腮鞍、tree和counter值骇。
• 分布式通信，包括直接消息傳遞和發(fā)布/訂閱移国。
• 分布式協(xié)調吱瘩，包括鎖、leader選舉和屏障(barrier)迹缀。
• 管理組成員使碾。

例如，Atomix包含AtomicMap和DistributedMap原語祝懂，兩者都用額外方法擴展了Java的Map實現票摇。對于AtomicMap來說，該原語使用樂觀鎖執(zhí)行原子更新砚蓬，從而保證所有操作都是原子的(map中的每個值都有一個單調遞增的版本號)矢门。與此相反，DistributedMap原語支持最終一致性灰蛙，而不是強一致性祟剔。這兩個原語都支持對對應map的基于事件的變更通知，客戶端可以通過在map上注冊事件監(jiān)聽器來監(jiān)聽插入/更新/刪除事件摩梧。

我們將在下一小節(jié)中看到峡扩，map是ONOS使用的主要原語。我們通過查看Atomix在ONOS中扮演的另一個角色來結束本節(jié): 協(xié)調所有ONOS實例^[1]障本，這種協(xié)調有兩個方面。

[1] 對于本文的討論响鹃，我們假設ONOS被打包為一個整體驾霜，然后跨多個虛擬化實例進行擴展。另一種將ONOS的功能劃分為可獨立擴展的微服務的方法將在第6.5節(jié)中討論买置。

首先粪糙，作為可水平伸縮的服務，在任何給定時間運行的ONOS實例數量取決于工作負載以及在出現故障時保證可用性所需的副本級別忿项。Atomix組成員(group membership) 原語用于確定可用的實例集蓉冈，從而可以檢測已經啟動的新實例和失敗的現有實例城舞。(請注意，ONOS實例集與Atomix實例集是不同的寞酿，兩者都能獨立擴展家夺。本節(jié)和下一段將重點介紹ONOS實例。)

其次伐弹，每個實例的主要工作是監(jiān)視和控制網絡中物理交換機的一個子集拉馋。ONOS采用的方法是為每個交換機選擇一個主實例，只有主實例向給定交換機發(fā)出(寫入)控制指令惨好。所有實例都能夠監(jiān)視(讀取)交換機狀態(tài)煌茴。然后，這些實例使用Atomix leader-election原語確定每個交換機的主實例日川。如果主實例失效蔓腐，同樣的原語被用來為交換機選擇一個新的主實例，當新的交換機上線時龄句，也可以遵循相同的流程回论。

6.2.2 服務

ONOS通過定義一組構建在Atomix上的核心表(map)而構建，這些表又打包為一組服務撒璧，用于控制應用程序(和其他服務)透葛。表和服務是觀察同一事物的兩種方式: 一種是鍵/值對的集合，另一種是應用程序和其他服務與這些鍵/值對交互的接口卿樱。圖33描述了相應的層次關系僚害，其中中間的三個組件(Topology、Link和Device)是ONOS服務的示例繁调。

圖33. ONOS基于Atomix中對應的表(Map)提供了一組服務萨蚕，如Topology、Device和Link服務蹄胰。

注意岳遥，圖33中的Topology Service沒有關聯的map，而是間接訪問由Link和Device Services定義的map裕寨。Topology Service將產生的網絡拓撲圖緩存到內存中浩蓉，為應用提供了一種低延遲、只讀的方式來訪問網絡狀態(tài)宾袜。Topology Service還計算圖的生成樹捻艳，以確保所有應用程序看到相同的廣播樹。

總的來說庆猫，ONOS定義了一個互聯的服務圖认轨，圖33只顯示了一個子圖。圖34擴展了該視圖月培，展示了ONOS核心的一些其他方面嘁字，不過這次將Atomix map簡化顯示為一些(但不是所有)服務的屬性恩急。

圖34. 在構建Path Service時涉及到的服務依賴圖(有些有自己的鍵/值映射)纪蜒。

關于這個依賴關系圖，有幾點需要注意霍掺。首先，應用程序可以通過查詢Path Service來了解主機對之間的端到端路徑杆烁，它既依賴于Topology Service(跟蹤網絡圖)牙丽，也依賴于Host Service(跟蹤連接到網絡的主機)烤芦。注意，箭頭方向指明依賴關系析校，但是正如我們在圖34中所示构罗，信息是雙向流動的智玻。

其次，Host Service有一個北向接口和一個南向接口盖彭。Path Service通過北向接口讀取與主機相關的信息页滚，而主機位置提供程序(Host Location Provider)使用南向接口寫入與主機相關信息。Host Service本身只不過是Atomix Map的一個包裝器隧熙，存儲關于主機的信息贞盯。我們將在6.4節(jié)中返回到Provider 抽象沪饺，但簡單來說，它們是與底層網絡設備交互的模塊。

第三掘宪，Host Location Provider負責窺探網絡流量，例如攔截ARP镀首、NDP和DHCP數據包以了解連接到網絡的主機鼠次，然后將其提供給Host Service更哄。反過來腥寇，Host Location Provider依賴Packet Service來幫助攔截這些數據包。Packet Service為其他ONOS服務定義了一種設備無關的方式麻敌，用于指示底層交換機捕獲選定的數據包并將其轉發(fā)到控制平面术羔。ONOS服務也可以通過Packet Service向數據平面注入報文乙漓。

最后叭披，雖然圖34中描述的服務圖旨在發(fā)現網絡拓撲，但在許多場景中扛禽，拓撲是固定并且已知的皱坛，當控制平面為特定拓撲量身定制時剩辟，這種情況經常發(fā)生，就像本書中討論的葉脊拓撲一樣熊户。對于這種情況嚷堡，拓撲服務從依賴關系圖^[2]中位于其上方的控制應用程序(或高級服務)接受配置指令艇棕。ONOS包括了這樣一個配置服務，稱為Network Config北苟，如圖35所示友鼻。Network Config反過來接受來自人工運維人員或自動協(xié)調器(例如圖31中的示例ZTP控制程序)的配置指令彩扔。

[2] Topology Service仍然需要從底層網絡收集真實信息，以驗證其是否與上面?zhèn)鬟f來的配置指令相匹配过吻，并在有差異時通知Network Config Service蔗衡。

圖35. Network Config Service支持配置程序和人工運維绞惦。

我們通過剛才的示例(圖33济蝉、34和35)說明了如何通過組件構建ONOS的基本原理。為了完整起見贺嫂，下面總結了最常用的ONOS服務:

• 主機(Host): 記錄連接到網絡的終端系統(tǒng)(裸機或虛擬機)第喳，由一個或多個主機發(fā)現應用程序提供數據踱稍，通常通過攔截ARP珠月、NDP或DHCP報文實現。
• 設備(Device): 記錄包括端口在內的基礎設施設備相關信息(交換機驻谆、ROADM等)旺韭。由一個或多個設備發(fā)現應用程序提供數據。
• 鏈路(Link): 記錄一對基礎設備/端口之間的鏈路屬性。由一個或多個鏈接發(fā)現應用程序提供數據(例如织盼，通過發(fā)送和攔截LLDP數據包)酱塔。
• 拓撲(Topology): 通過圖抽象將網絡表示為一個整體羊娃。它構建在設備和鏈路服務之上蕊玷，并提供由基礎設施設備為頂點以及基礎設施鏈接為邊組成的一致的圖。當接收到有關設備和鏈路的事件時延届，網絡拓撲以最終一致性的方式收斂圖抽象贸诚。
• Mastership: 通過分布式共識算法(使用Atomix leader-election原語)選舉ONOS集群中的主節(jié)點實例酱固。在ONOS實例失效的情況下(例如运悲，服務器斷電)，確保為所有沒有master的設備盡快選舉新的master欺殿。
• 集群(Cluster): 管理ONOS集群配置脖苏，提供Atomix集群節(jié)點以及所有對等ONOS節(jié)點的信息定踱。Atomix節(jié)點形成了實際的集群，這是共識的基礎恤浪，而ONOS節(jié)點實際上只是用于將控制邏輯和I/O擴展到網絡設備的客戶機肴楷。ONOS使用Atomix membership原語設置條目赛蔫。
• 網絡配置(Network Config): 定義網絡元信息，如設備及其端口鞠值、主機渗钉、鏈接等鳄橘。提供關于網絡的外部信息，以及告訴ONOS核心和應用程序應該如何管理網絡抵恋。由調度器弧关、ZTP控制程序或運維人員手動設置唤锉。
• 組件配置(Component Config): 管理ONOS核心和應用中各種軟件組件的配置參數窿祥。這些參數(例如晒衩，如何處理外部流規(guī)則、地址或DHCP服務器贝奇、輪詢頻率掉瞳，等等)允許定制軟件的行為，由運營商根據部署需要設置霎褐。
• 報文(Packet):　允許核心業(yè)務和應用程序攔截報文冻璃，并將報文發(fā)送回網絡损合。這是大多數主機和鏈路發(fā)現方法(如ARP塌忽、DHCP土居、LLDP)的基礎嬉探。

因為這些服務提供了關于網絡設備及其拓撲結構的信息涩堤，因此幾乎每個應用程序都需要使用這些服務胎围。然而，還有更多服務汽纤，包括那些允許應用程序使用不同構造和不同抽象級別對網絡行為進行編程的服務蕴坪。我們將在下一節(jié)更深入討論背传，但現在台夺，我們先列舉其中的一部分:

• 路由(Route): 定義到下一跳映射的前綴谒养。可通過控制程序設置薯定，也可由運維人員手動配置抑片。
• 多播(Mcast): 定義組IP年堆、源和匯聚位置变丧。由控制程序設置或由運維人員手動配置痒蓬。
• 組(Group): 聚合設備中的端口或動作攻晒。流條目可以指向一個已定義的組班挖，從而允許復雜的轉發(fā)方式萧芙，例如組內端口之間的負載均衡末购、組內端口之間的故障轉移或組內指定的所有端口的多播。組還可以用于聚合不同流的通用操作曹质，因此在某些場景中羽德，只需要修改所引用的流條目宅静，而不必修改所有條目站欺。
• 測量(Meter): 表示對設備處理的特定網絡流量強制執(zhí)行服務質量的速率限制。
• 流規(guī)則(Flow Rule): 提供以設備為中心的match/action對峭沦，用于對設備的數據平面轉發(fā)行為進行編程吼鱼。要求流規(guī)則條目按照設備的流水線結構和功能進行組合菇肃。
• Flow Objective: 提供一個以設備為中心的抽象取募，以流水線無關的方式對設備的轉發(fā)行為進行編程玩敏。它依賴于Pipeliner子系統(tǒng)(請參閱下一節(jié))來實現表無關的flow objective和表特定的流(或組)規(guī)則(flow rule)的映射聊品。
• 意圖(Intent): 提供一種拓撲無關的方式建立跨網絡的流翻屈。高級規(guī)范(既意圖)指出端到端路徑的各種提示和約束伸眶，包括流量類型以及源和目標主機刽宪，或請求連接的入口和出口端口圣拄。該服務通過適當的路徑提供這種連通性庇谆，然后持續(xù)監(jiān)測網絡饭耳，在面對變化的網絡條件時，隨著時間的推移改變路徑纲酗，從而持續(xù)滿足意圖定義的目標觅赊。

上述每個服務都含有自己的分布式存儲和通知功能茉兰，各個應用可以自由使用自己的服務擴展這一集合，并用自己的分布式存儲支持自己的實現坯约。這就是ONOS為應用程序提供直接訪問Atomix原語(如AtomicMaps和DistributedMaps)的原因闹丐。當我們在下一章仔細研究SD-Fabric時卿拴，將看到這種擴展的例子堕花。

6.3 北向接口

ONOS北向接口由多個部分組成缘挽。首先壕曼，在ONOS特定配置中包含的每個服務都有相應的API等浊。例如筹燕，圖30所示的"Topology"接口正是圖33所示的Topology Service所提供的API撒踪。其次糠涛，由于ONOS允許應用程序定義和使用自己的Atomix表忍捡，因此可以將Atomix編程接口視為ONOS NBI的一部分。第三纬霞，ONOS NBI包括gNMI和gNOI诗芜，這些是獨立于ONOS的標準化接口埃疫，但作為ONOS NBI的一部分栓霜。注意胳蛮，gNMI和gNOI后面的實現也是封裝在Atomix映射上的ONOS服務仅炊。最后抚垄，也是最有趣的一點是督勺，ONOS提供了一組用于控制底層交換機的接口智哀。圖30描述了其中兩個瓷叫，Flow Rule和Flow Objective摹菠。前一種借鑒自OpenFlow次氨，跟特定流水線有關煮寡。第二個是流水線中立的，也是本節(jié)其余部分的重點薇组。

有三種類型的流對象: 過濾(Filtering)律胀、轉發(fā)(Forwarding) 和下一步(Next)炭菌。Filtering對象根據流量選擇器(Selector) 確定是否允許流量進入流水線娃兽。Forwarding對象通常通過匹配數據包中的選擇字段與轉發(fā)表決定哪些流量被允許流出流水線投储。Next對象指出應該對流量做出什么樣的處理(Treatment)玛荞，例如如何重寫報頭勋眯。如果你覺得這聽起來像是一個抽象的三階段流水線:

<center><b>Filtering → Forwarding → Next</b></center>

你就會理解流對象背后的理念。例如下梢，Filter對象(階段)可以指定匹配特定MAC地址客蹋、VLAN標簽和IP地址的數據包被允許進入管道；相應的Forwarding對象(階段)在路由表中查找IP地址孽江；最后Next對象(階段)根據需要重寫報頭讶坯，并將數據包轉發(fā)給輸出端口。當然岗屏，所有這三個階段都不知道底層交換機到底使用了哪些表組合來實現相應的match/action對序列辆琅。

挑戰(zhàn)在于將這些流水線無關的對象映射到相應的流水線依賴規(guī)則上这刷。在ONOS中婉烟，此映射由Flow Objective Service管理，如圖36所示暇屋。為了簡單起見似袁，該示例主要關注Filtering對象指定的選擇器(match)，關鍵是表示希望選擇的特定輸入端口、MAC地址叔营、VLAN標記和IP地址組合屋彪，而不考慮實現該組合的流水線表的確切序列。

圖36. Flow Objective Service管理流水線無關的對象到流水線特定規(guī)則的映射绒尊。

在內部畜挥，Flow Objective Service被組織為一組特定設備處理程序的集合，每個處理程序都使用ONOS設備驅動機制實現婴谱。將流對象指令映射到具體流規(guī)則操作實現的設備驅動行為被稱為Pipeliner蟹但。圖36顯示了兩個示例交換機流水線的Pipeliners。

Pipeliner能夠將流對象映射到流規(guī)則(在固定功能流水線的情況下)和P4編程流水線上谭羔。圖36中給出的示例顯示了前一種情況华糖，包括到OpenFlow 1.3的映射。在后一種情況下瘟裸，Pipeliner利用了Pipeconf 結構客叉，該結構維護以下元素之間的關聯:

1. 每個目標交換機的流水線模型。
2. 需要在特定交換機上部署流指令的驅動程序话告。
3. 用于將流對象映射到特定目標的轉換器兼搏。

如第5.2節(jié)所述，Pipeconf基于P4編譯器輸出的.p4info文件中提取的信息來維護這些綁定沙郭。

如今佛呻，(1)中所說的"模型"是ONOS定義的，意味著對于開發(fā)人員來說病线，端到端的工作流包括在編程數據平面時使用P4架構模型(例如v1model.p4)吓著，以及在使用流對象編程控制平面時使用ONOS模型。最終送挑，P4很可能將會統(tǒng)一這些流水線模型的不同層绑莺。

站在編程角度，流對象是用相關的構造函數例程打包的數據結構惕耕》牟茫控制程序構建一個對象列表，并傳遞給ONOS執(zhí)行赡突。下面的代碼示例顯示了構建流對象以指定通過網絡的端到端流，將其應用到底層設備的過程在其他地方完成区赵，沒有包括在示例中惭缰。

public void createFlow(
      TrafficSelector originalSelector,
      TrafficTreatment originalTreatment,
      ConnectPoint ingress, ConnectPoint egress,
      int priority, boolean applyTreatment,
      List<Objective> objectives,
      List<DeviceId> devices) {
   TrafficSelector selector = DefaultTrafficSelector.builder(originalSelector)
      .matchInPort(ingress.port())
      .build();

   // Optionally apply the specified treatment
   TrafficTreatment.Builder treatmentBuilder;
   if (applyTreatment) {
      treatmentBuilder = DefaultTrafficTreatment.builder(originalTreatment);
   } else {
      treatmentBuilder =
      DefaultTrafficTreatment.builder();
   }

   objectives.add(DefaultNextObjective.builder()
      .withId(flowObjectiveService.allocateNextId())
      .addTreatment(treatmentBuilder.setOutput(
      egress.port()).build())
      .withType(NextObjective.Type.SIMPLE)
      .fromApp(appId)
      .makePermanent()
      .add());
   devices.add(ingress.deviceId());

   objectives.add(DefaultForwardingObjective.builder()
      .withSelector(selector)
      .nextStep(nextObjective.id())
      .withPriority(priority)
      .fromApp(appId)
      .makePermanent()
      .withFlag(ForwardingObjective.Flag.SPECIFIC)
      .add());
   devices.add(ingress.deviceId());
}

上面的例子創(chuàng)建了一個Next對象和一個Forwarding對象，Next對象對流應用了一個Treatment笼才，改Treatment會設置輸出端口漱受，但也可以選擇將originalTreatment作為createFlow的輸入參數。

6.4 南向接口

ONOS靈活性的一個關鍵點是能夠適應不同的控制協(xié)議。雖然控制交互和相關抽象的本質是受到OpenFlow協(xié)議的啟發(fā)昂羡，但ONOS的設計是為了確保核心(以及在核心之上編寫的應用程序)與控制協(xié)議的細節(jié)解耦絮记。

本節(jié)將詳細介紹ONOS如何適應多種協(xié)議和異構網絡設備，基本方法是基于插件架構虐先，有兩種類型的插件: 協(xié)議提供程序(Protocol Providers) 和設備驅動程序(Device Drivers)怨愤，下面章節(jié)將依次對展開描述。

6.4.1 Provider插件

ONOS定義了南向接口(SBI)插件框架蛹批，其中每個插件定義了南向(面向網絡)API撰洗，每個插件也被稱為協(xié)議提供者(Protocol Provider)，充當SBI和底層網絡之間的代理腐芍，在底層網絡中差导，沒有限制每個插件可以使用什么控制協(xié)議與網絡通信。Provider將自己注冊到SBI插件框架中猪勇，并開始充當ONOS應用程序和核心服務(上層)以及網絡環(huán)境(下層)之間傳遞信息和控制指令的通道设褐，如圖37所示。

圖37. 通過Provider插件擴展ONOS南向接口(SBI)泣刹。

圖37包含了兩種常見的Provider插件助析。第一種類型是特定于協(xié)議的，典型例子是OpenFlow和gNMI项玛。這些Provider中的每一個都將API與實現相應協(xié)議的代碼有效捆綁在一起貌笨。第二種類型(圖中顯示的是DeviceProvider、HostProvider和LinkProvider)使用一些其他ONOS服務與環(huán)境間接交互襟沮。我們在6.2.2節(jié)看到了一個例子锥惋，Host Location Provider(一個ONOS服務)位于HostProvider(一個SBI插件)之后，后者定義了主機發(fā)現API开伏，而前者定義了一種發(fā)現主機的特定方法(例如膀跌，使用包服務攔截ARP、NDP和DHCP報文)固灵。同樣捅伤，LLDP Link Provider Service(對應于LinkProvider SBI插件)通過Packet Service攔截LLDP和BDDP報文，用于推測基礎設施設備之間的鏈路巫玻。

6.4.2 設備驅動(Device Drivers)

除了將核心與協(xié)議細節(jié)隔離開來之外丛忆，SBI框架還支持設備驅動插件作為一種機制，將代碼(包括Provider)與特定設備解耦仍秤。設備驅動是一組模塊的集合熄诡，每個模塊都實現控制或配置功能的一部分。與Protocol Provider一樣诗力，對設備驅動如何實現這些功能沒有任何限制凰浮。設備驅動程序也被部署為ONOS應用程序，從而允許被動態(tài)安裝和卸載，允許運維人員動態(tài)引入新的設備類型和型號袜茧。

6.5 可擴展性能(Scalable Performance)

ONOS是一個邏輯上集中的SDN控制器菜拓，必須確保能夠及時響應可伸縮規(guī)模的控制事件，還必須在失效時保持可用笛厦。本節(jié)描述ONOS如何擴展以滿足這些性能和可用性需求纳鼎。我們從一些規(guī)模和性能數據出發(fā)，從而介紹集中式網絡控制最先進的進展(在撰寫本文時):

• 規(guī)模(Scale): ONOS最多支持50個網絡設備递递、5000網絡端口喷橙、5萬用戶、1百萬線路登舞、5百萬流量規(guī)則/組/測量器贰逾。
• 性能(Performance): ONOS支持每天高達10k的配置操作、500k流操作/秒(持續(xù))菠秒、1k拓撲事件/秒(峰值)疙剑、50ms內檢測端口/切換事件、5ms內檢測端口/交換機關閉事件践叠、流操作探測在3ms內完成言缤、切換事件(RAN)在6毫秒內完成。

生產部署至少運行三個ONOS實例禁灼，但這更多是為了可用性而不是性能管挟。每個實例都運行在一個32核/128GB內存的服務器上，并以Docker容器部署在Kubernetes上弄捕。每個實例捆綁了一個相同的(但可配置的)核心服務僻孝、控制應用程序和Protocol Provider的集合，ONOS使用Karaf作為其內部模塊化框架守谓。該組件包還包括Atomix穿铆，ONOS還支持其他鍵值存儲的選擇，可以獨立于ONOS的其他部分擴展斋荞。

圖38. 多個ONOS實例通過Atomix共享網絡狀態(tài)荞雏，提供可擴展性能和高可用性。

圖38展示了ONOS跨多個實例的可伸縮性平酿，其中實例集通過Atomix Maps共享網絡狀態(tài)凤优。該圖還顯示，每個實例負責底層硬件交換機的一個子集蜈彼。如果給定實例失效筑辨，其余實例使用Atomix leader-election原語選擇一個新實例來取代它，從而確保高可用性柳刮。

ONOS的重構也在進行中挖垛，以更緊密遵循微服務架構。新版本稱為μONOS秉颗，利用了ONOS現有的模塊化痢毒，但獨立封裝和擴展了不同的子系統(tǒng)。雖然原則上蚕甥，本章介紹的每個核心服務都可以打包為獨立的微服務哪替，但這樣做太細粒度了，且不切實際菇怀。相反凭舶，μONOS采用以下方法。首先爱沟，它將Atomix封裝在自己的微服務中帅霜。其次，它將每個控制應用程序和南向適配器作為單獨的微服務運行呼伸。第三身冀，它將核心劃分為四個不同的微服務: (1)提供網絡圖(Network Graph)API的Topology Management微服務; (2)提供P4Runtime API的Control Management微服務; (3)提供gNMI API的Configuration Management微服務; (4)提供gNOI API的Operations Management微服務。

你好括享，我是俞凡搂根，在Motorola做過研發(fā)，現在在Mavenir做技術工作铃辖，對通信剩愧、網絡、后端架構娇斩、云原生仁卷、DevOps、CICD成洗、區(qū)塊鏈五督、AI等技術始終保持著濃厚的興趣，平時喜歡閱讀瓶殃、思考充包，相信持續(xù)學習、終身成長遥椿，歡迎一起交流學習基矮。
微信公眾號：DeepNoMind