软件定义网络(SDN)研究进展
寫在前面
這是我入門SDN以來的第一篇論文，它是一篇中文綜述，看起來相對容易。也讓我對SDN有了進(jìn)一步的認(rèn)識。下面是我的一些心得。
全文框架
SDN 將數(shù)據(jù)平面與控制平面解耦合,簡化了網(wǎng)絡(luò)管理.
SDN誕生背景。
SDN三層結(jié)構(gòu)及關(guān)鍵技術(shù)
數(shù)據(jù)層
控制層
應(yīng)用層
SDN 在不同應(yīng)用場景下的最新研究成果。
未來工作。
概述
隨著網(wǎng)絡(luò)規(guī)模的不斷擴(kuò)大,封閉的網(wǎng)絡(luò)設(shè)備內(nèi)置了過多的復(fù)雜協(xié)議,增加了運(yùn)營商定制優(yōu)化網(wǎng)絡(luò)的難度,科研人員無法在真實(shí)環(huán)境中規(guī)模部署新協(xié)議。
同時,互聯(lián)網(wǎng)流量的快速增長(預(yù)計(jì)到2018年,全球流量將達(dá)到1.6′1021字節(jié)),無法做到真正的負(fù)載均衡，網(wǎng)絡(luò)運(yùn)營商的變革意愿強(qiáng)烈。
SDN起源于Stanford的Clean Slate 研究課題，Mckeown 教授正式提出了SDN 概念。
SDN分為三層
控制層：可編程的控制器，掌控全網(wǎng)信息。
數(shù)據(jù)層：啞的(dumb)交換機(jī),僅僅負(fù)責(zé)轉(zhuǎn)發(fā)功能。
應(yīng)用層：通過北向接口與控制層交互，實(shí)現(xiàn)特定的需求。
1. SDN的體系結(jié)構(gòu)
SDN 標(biāo)準(zhǔn)接口機(jī)制確保層次之間既保持相對獨(dú)立,又能正常通信,因此,標(biāo)準(zhǔn)接口設(shè)計(jì)的好壞是SDN 成功設(shè)計(jì)的關(guān)鍵.
1.1 SDN誕生背景
隨著網(wǎng)絡(luò)的快速發(fā)展,傳統(tǒng)互聯(lián)網(wǎng)出現(xiàn)了如傳統(tǒng)網(wǎng)絡(luò)配置復(fù)雜度高等諸多問題,這些問題說明網(wǎng)絡(luò)架構(gòu)需要革新
當(dāng)然最先出現(xiàn)的不是SDN，而是一些其它的可編程網(wǎng)絡(luò)架構(gòu)，這些可編程網(wǎng)絡(luò)的相關(guān)研究為SDN的產(chǎn)生提供了可參考的理論依據(jù)。
| 架構(gòu)名稱 | 特點(diǎn) | 缺陷 |
|---|---|---|
| 主動網(wǎng)絡(luò) | 允許數(shù)據(jù)包攜帶用戶程序,并能夠由網(wǎng)絡(luò)設(shè)備自動執(zhí)行.用戶可以通過編程方式動態(tài)地配置網(wǎng)絡(luò),達(dá)到了方便管理網(wǎng)絡(luò)的目的。 | 需求低、協(xié)議兼容性差 |
| 4D架構(gòu) | 將可編程的決策平面(即控制層)從數(shù)據(jù)平面分離,使控制平面邏輯中心化與自動化。 |
借鑒計(jì)算機(jī)系統(tǒng)的抽象結(jié)構(gòu),未來的網(wǎng)絡(luò)結(jié)構(gòu)將存在轉(zhuǎn)發(fā)抽象、分布狀態(tài)抽象和配置抽象這3 類虛擬化概念。
| 抽象類型 | 簡介 |
|---|---|
| 轉(zhuǎn)發(fā)抽象 | 剝離了傳統(tǒng)交換機(jī)的控制功能,將控制功能交由控制層來完成,并在數(shù)據(jù)層和控制層之間提供了標(biāo)準(zhǔn)接口,確保交換機(jī)完成識別轉(zhuǎn)發(fā)數(shù)據(jù)的任務(wù). |
| 分布狀態(tài)抽象 | 控制層需要將設(shè)備的分布狀態(tài)抽象成全網(wǎng)視圖,以便眾多應(yīng)用能夠通過全網(wǎng)信息進(jìn)行網(wǎng)絡(luò)的統(tǒng)一配置 |
| 配置抽象 | 用戶僅需通過控制層提供的應(yīng)用接口對網(wǎng)絡(luò)進(jìn)行簡單配置,就可自動完成沿路徑轉(zhuǎn)發(fā)設(shè)備的統(tǒng)一部署 |
SDN標(biāo)準(zhǔn)制定組織：ONF（Open Networking Foundation）
1.2 體系結(jié)構(gòu)概述
針對不同的需求，許多組織提出了相應(yīng)的架構(gòu)。
SDN架構(gòu)
SDN 架構(gòu)最先由 ONF 組織提出,并已經(jīng)成為學(xué)術(shù)界和產(chǎn)業(yè)界普遍認(rèn)可的架構(gòu)。
數(shù)據(jù)平面與控制平面之間利用SDN 控制數(shù)據(jù)平面接口(control-data-plane interface,簡稱CDPI)進(jìn)行通信,CDPI 具有統(tǒng)一的通信標(biāo)準(zhǔn),目前主要采用OpenFlow 協(xié)議。
控制平面與應(yīng)用平面之間由SDN 北向接口(northbound interface,簡稱NBI)負(fù)責(zé)通信,NBI 允許用戶按實(shí)際需求定制開發(fā)。用戶無需關(guān)心底層設(shè)備的技術(shù)細(xì)節(jié),僅通過簡單的編程就能實(shí)現(xiàn)新應(yīng)用的快速部署。
數(shù)據(jù)平面由交換機(jī)等網(wǎng)絡(luò)元素組成,各網(wǎng)絡(luò)元素之間由不同規(guī)則形成的SDN 網(wǎng)絡(luò)數(shù)據(jù)通路形成連接。
控制平面包含邏輯中心的控制器,負(fù)責(zé)運(yùn)行控制邏輯策略,維護(hù)著全網(wǎng)視圖。通過訪問CDPI代理來調(diào)用相應(yīng)的網(wǎng)絡(luò)數(shù)據(jù)通路。
NFV架構(gòu)
歐洲電信標(biāo)準(zhǔn)化組織(European Telecommunications Standards Institute,簡稱ETSI)提出的 NFV 架構(gòu)隨之發(fā)展起來,該體系結(jié)構(gòu)主要針對運(yùn)營商網(wǎng)絡(luò)。
網(wǎng)絡(luò)運(yùn)營商的網(wǎng)絡(luò)由專屬設(shè)備來部署,這些專屬設(shè)備功能變得繁雜,而管理這些繁雜的硬件設(shè)備造成運(yùn)營成本及能耗的增加,從而導(dǎo)致運(yùn)營商網(wǎng)絡(luò)的發(fā)展遇到瓶頸。
NFV采用了資源虛擬化的方式,在通用設(shè)備上運(yùn)行虛擬機(jī)或者容器來實(shí)現(xiàn)網(wǎng)絡(luò)功能,NFV降低了設(shè)備成本,縮短了新網(wǎng)絡(luò)服務(wù)的部署周期,從而適應(yīng)網(wǎng)絡(luò)運(yùn)營商的發(fā)展需求。
NFV 既可以基于非OpenFlow 協(xié)議，例如ForCES等多種傳統(tǒng)接口標(biāo)準(zhǔn)化協(xié)議,又能與OpenFlow協(xié)同工作。
OpenDaylight架構(gòu)
由各大設(shè)備廠商和軟件公司共同提出了OpenDaylight,目的是為了具體實(shí)現(xiàn)SDN 架構(gòu),以便用于實(shí)際部署。
OpenDaylight 繼承了SDN架構(gòu)形式,同時又結(jié)合了NFV 的特點(diǎn)。
ODL與SDN都具有三層架構(gòu)，ODL的控制層采用自帶的Java虛擬機(jī)實(shí)現(xiàn)。
ODL與SDN架構(gòu)最大的不同在于:OpenDaylight控制器的南向接口除了支持OpenFlow 協(xié)議之外,還支持NETCONF等配置協(xié)議和BGP等路由協(xié)議,并支持生產(chǎn)廠商的專有協(xié)議(如思科的OnePK 協(xié)議).
為了能夠處理不同的標(biāo)準(zhǔn)協(xié)議,OpenDaylight 增加了服務(wù)抽象層SAL,它負(fù)責(zé)將不同的底層協(xié)議標(biāo)準(zhǔn)轉(zhuǎn)換成OpenDaylight 控制層所理解的請求服務(wù)。
三種架構(gòu)對比
1.3 開放式接口與協(xié)議設(shè)計(jì)
東西向接口
由于單一控制機(jī)制容易造成控制節(jié)點(diǎn)失效,嚴(yán)重影響性能,可采用多控制器方式,此時,多控制器之間將采用東西向通信方式。
南向接口協(xié)議
邏輯上,它既要保證數(shù)據(jù)層與控制層之間的正常通信,又要支持兩層獨(dú)立更新。
物理上,設(shè)備生產(chǎn)廠商需要開發(fā)支持這種標(biāo)準(zhǔn)接口的設(shè)備,因?yàn)?strong>傳統(tǒng)網(wǎng)絡(luò)設(shè)備是不能在SDN 網(wǎng)絡(luò)之中運(yùn)行的。
然而南向接口協(xié)議有很多種。
Openflow
主流的南向接口是Openflow，是基于流的概念來匹配規(guī)則的,因此,交換機(jī)需要維護(hù)一個流表(flow table)來支持OpenFlow,并按流表進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā),而流表的建立、維護(hù)及下發(fā)均由控制器來完成。
Openflow發(fā)展史
| 版本 | 簡介 |
|---|---|
| Openflow 1.0.0 | 規(guī)定流表頭為12 元組(如源/目的IP 地址、源/目的MAC 地址等.然而,1.0.0 版本還不完善,如支持的規(guī)則和動作過少、僅支持單表、無關(guān)聯(lián)動作的組合容易造成組合爆炸等問題。 |
| Openflow 1.1.0 | 增加了部分規(guī)則,并開始支持多級流表、群組表和動作集等功能 |
| Openflow 1.2 | 增加了對IPv6 源/目的地址的支持 |
| Openflow 1.3 | 支持流控機(jī)制 |
| Openflow 1.4.0 | 增加了流表刪除和復(fù)制機(jī)制,并考慮了流表一致性問題. |
隨著OpenFlow 支持的功能不斷增加,流表將容易產(chǎn)生負(fù)載過重的問題。如何支持不同粒度、任意組合的功能,是OpenFlow 下一步發(fā)展的關(guān)鍵所在。
Openflow 并未指定如何配置和管理轉(zhuǎn)發(fā)設(shè)備環(huán)境,因此,ONF 提出了OF-CONFIG 協(xié)議。作為配置協(xié)議,OF-CONFIG 擴(kuò)展了NETCONF 標(biāo)準(zhǔn),采用XML 配置交換機(jī)環(huán)境,填補(bǔ)了OpenFlow 在配置方面的缺失。
ForCES協(xié)議
IETF 提出了ForCES 協(xié)議。
ForCES 對網(wǎng)絡(luò)設(shè)備內(nèi)部結(jié)構(gòu)重新定義,將轉(zhuǎn)發(fā)元素(forwarding element,簡稱FE)和控制元素(control element,簡稱CE)分離,形成兩個獨(dú)立的邏輯實(shí)體。
兩個邏輯實(shí)體之間依靠 ForCES 協(xié)議通信.該協(xié)議工作在主從模式下,即,CE 通過ForCES協(xié)議主動將指令下發(fā)給FE,FE 被動接受這些指令,并通過硬件執(zhí)行每數(shù)據(jù)包級的分組轉(zhuǎn)發(fā)。
OnePK
思科公司提出了OnePK 協(xié)議。
OnePK 則是思科公司針對 SDN 產(chǎn)品專門開發(fā)的接口協(xié)議,該協(xié)議可以運(yùn)行在思科所研發(fā)的專屬平臺上,并支持開發(fā)者用C 或Java 編寫的程序。OnePK 除了支持專有的OnePK 協(xié)議之外,還可支持OpenFlow 協(xié)議等。
典型的三種南向接口協(xié)議對比
北向接口
北向接口并沒有統(tǒng)一標(biāo)準(zhǔn)
北向接口負(fù)責(zé)控制層與各種業(yè)務(wù)應(yīng)用之間的通信,應(yīng)用層各項(xiàng)業(yè)務(wù)通過編程方式調(diào)用所需網(wǎng)絡(luò)抽象資源,掌握全網(wǎng)信息,方便用戶對網(wǎng)絡(luò)配置和應(yīng)用部署等業(yè)務(wù)的快速推進(jìn)。
由于應(yīng)用業(yè)務(wù)具有多樣性,使得北向接口亦呈現(xiàn)多樣性,開發(fā)難度較大。
起初,SDN允許用戶針對不同應(yīng)用場景定制適合的北向接口標(biāo)準(zhǔn)。統(tǒng)一的北向接口標(biāo)準(zhǔn)將直接影響著各項(xiàng)應(yīng)用業(yè)務(wù)的順利開展。
為了統(tǒng)一北向接口,各組織開始制訂北向接口標(biāo)準(zhǔn),如ONF 的NBI 接口標(biāo)準(zhǔn)和OpenDaylight 的REST 接口標(biāo)準(zhǔn)等。然而,這些標(biāo)準(zhǔn)僅對功能作了描述,而未詳細(xì)說明實(shí)現(xiàn)方式。
如何實(shí)現(xiàn)統(tǒng)一的北向接口標(biāo)準(zhǔn),成為業(yè)界下一步主要推動的工作。
2. 數(shù)據(jù)層關(guān)鍵技術(shù)研究
在 SDN 中，數(shù)據(jù)層與控制層分離，交換機(jī)將繁重的控制策略部分交由控制器來負(fù)責(zé)，而它僅根據(jù)控制器下發(fā)的規(guī)則對數(shù)據(jù)包進(jìn)行快速轉(zhuǎn)發(fā)。為了避免交換機(jī)與控制器頻繁交互，雙方約定的規(guī)則是基于流的，而并非基于每個數(shù)據(jù)包的。SDN 數(shù)據(jù)層的功能相對簡單，相關(guān)技術(shù)研究主要集中在交換機(jī)和轉(zhuǎn)發(fā)規(guī)則方面：首先是交換機(jī)設(shè)計(jì)研究，即設(shè)計(jì)可擴(kuò)展的快速轉(zhuǎn)發(fā)設(shè)備，它既可以靈活匹配規(guī)則，又能快速轉(zhuǎn)發(fā)數(shù)據(jù)流；其次是轉(zhuǎn)發(fā)規(guī)則的相關(guān)研究，例如規(guī)則失效后的一致性更新問題等。
2.1 交換機(jī)設(shè)計(jì)問題
交換機(jī)有兩種轉(zhuǎn)發(fā)方式：硬件和軟件。
硬件處理
速度快、成本低和功耗小等優(yōu)點(diǎn)。
硬件分為三種。
| 名稱 | 速度 | 靈活性 |
|---|---|---|
| 交換機(jī)芯片 | 比CPU 處理速度快兩個數(shù)量級 | 遠(yuǎn)低于CPU 和NP 等可編程器件 |
| 網(wǎng)絡(luò)處理器(network processor,簡稱NP) | 比CPU 處理速度快一個數(shù)量級 | 可編程 |
| CPU | - | 可編程 |
做到既保證硬件的轉(zhuǎn)發(fā)速率,同時還能確保識別轉(zhuǎn)發(fā)規(guī)則的靈活性,成為目前研究的熱點(diǎn)問題。
為了使硬件能夠靈活解決數(shù)據(jù)層的轉(zhuǎn)發(fā)規(guī)則匹配嚴(yán)格和動作集元素?cái)?shù)量太少等限制性問題，研究人員提出了如下兩個硬件處理模型。
RMT模型
該模型實(shí)現(xiàn)了一個可重新配置的匹配表,它允許在流水線(pipeline)階段支持任意寬度和深度的流表。
允許隨意替換或增加域定義。
允許指定流表的數(shù)量、拓?fù)洹挾群蜕疃?僅僅受限于芯片的整體資源 (如芯片內(nèi)存大小等)。
允許創(chuàng)建新動作。
可以隨意將數(shù)據(jù)包放到不同的隊(duì)列中,并指定發(fā)送端口。
RMT 模型是由解析器、多個邏輯匹配部件以及可配置輸出隊(duì)列組成
通過修改解析器來增加域定義（包頭域）
修改邏輯匹配部件的匹配表來完成新域的匹配
修改邏輯匹配部件的動作集來實(shí)現(xiàn)新的動作
修改隊(duì)列規(guī)則來產(chǎn)生新的隊(duì)列
所有更新操作是通過解析器來實(shí)現(xiàn)的,無需修改硬件,只需在芯片設(shè)計(jì)時留出可配置的接口即可,實(shí)現(xiàn)了硬件對數(shù)據(jù)的靈活處理。
FlowAdapter模型
FlowAdapter采用交換機(jī)分層的方式來實(shí)現(xiàn)高效、靈活的多表流水線業(yè)務(wù)。
FlowAdapter 交換機(jī)分為3層
最上層是可以通過更新來支持任何新協(xié)議的軟件數(shù)據(jù)平面。
底層是相對固定但轉(zhuǎn)發(fā)效率高的硬件數(shù)據(jù)平面。
中部的FlowAdapter 層負(fù)責(zé)軟件數(shù)據(jù)平面和硬件數(shù)據(jù)平面之間的通信。
當(dāng)控制器下發(fā)規(guī)則時,軟件數(shù)據(jù)平面將存儲這些規(guī)則,形成M 個階段的流表.由于這些規(guī)則相對靈活,不能全部由交換機(jī)直接轉(zhuǎn)化成相應(yīng)轉(zhuǎn)發(fā)動作,而硬件數(shù)據(jù)平面可以實(shí)現(xiàn)規(guī)則的高速匹配轉(zhuǎn)發(fā).因此可利用中間層FlowAdapter將兩個數(shù)據(jù)平面中的規(guī)則進(jìn)行無縫轉(zhuǎn)換,即,將相對靈活的M階段的流表轉(zhuǎn)換成能夠被硬件所識別的N階段的流表.
為了達(dá)到轉(zhuǎn)換目的,FlowAdapter首先檢查軟件數(shù)據(jù)平面的全部規(guī)則,然后根據(jù)完整的規(guī)則將M階段的流表轉(zhuǎn)換成1階段流表,最后再將1階段流表轉(zhuǎn)換成N階段流表發(fā)送給硬件數(shù)據(jù)平面.通過這種無縫轉(zhuǎn)換,理論上解決了傳統(tǒng)交換機(jī)硬件與控制器之間多表流水線技術(shù)不兼容的問題。
另外,FlowAdapter相對控制器完全透明,對FlowAdapter交換機(jī)的更新不會影響控制器的正常運(yùn)行。
軟件處理
軟件處理的優(yōu)點(diǎn)：軟件方式可以最大限度地提升規(guī)則處理的靈活性,同時又能避免由于硬件自身內(nèi)存較小、流表大小受限、無法有效處理突發(fā)流等問題。
軟件處理的缺點(diǎn)：速度低。
使用CPU處理
利用交換機(jī)CPU處理轉(zhuǎn)發(fā)規(guī)則，可以避免硬件靈活性差的問題。由于CPU處理數(shù)據(jù)包的能力變得越來越強(qiáng)，商用交換機(jī)很自然地也會采用這種更強(qiáng)的CPU。這樣，在軟件處理轉(zhuǎn)發(fā)速度與硬件差別變小的同時，靈活處理轉(zhuǎn)發(fā)規(guī)則的能力得到提。
使用NP處理
由于NP 專門用來處理網(wǎng)絡(luò)的各種任務(wù)，如數(shù)據(jù)包轉(zhuǎn)發(fā)、路由查找和協(xié)議分析等，因此在網(wǎng)絡(luò)處理方面，NP比CPU具有更高效的處理能力。
在數(shù)據(jù)平面中，哪些元素可以交給硬件處理，哪些元素可以交給軟件處理，也是值得考慮的問題。例如，原本設(shè)計(jì)到硬件中的計(jì)數(shù)器功能并不合理，而應(yīng)當(dāng)放置到CPU中處理，這樣既可以保證計(jì)數(shù)器的靈活性，又能節(jié)省硬件空間，降低復(fù)雜度，同時還能夠避免硬件計(jì)數(shù)的限制。
2.2 轉(zhuǎn)發(fā)規(guī)則的相關(guān)研究
與傳統(tǒng)網(wǎng)絡(luò)類似,SDN中也會出現(xiàn)網(wǎng)絡(luò)節(jié)點(diǎn)失效的問題,導(dǎo)致網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)規(guī)則被迫改變,嚴(yán)重影響了網(wǎng)絡(luò)的可靠性.此外,流量負(fù)載轉(zhuǎn)移或網(wǎng)絡(luò)維護(hù)等也會帶來轉(zhuǎn)發(fā)規(guī)則的變化。
改變規(guī)則有以下兩種策略：
較低抽象層次(low-level)更新
也就是管理人員自主更新規(guī)則
使用較低抽象層次管理方式來更新規(guī)則容易出現(xiàn)失誤，導(dǎo)致出現(xiàn)規(guī)則更新不一致的現(xiàn)象。
即便沒有出現(xiàn)失誤，由于存在更新延遲問題，在更新過程中，轉(zhuǎn)發(fā)路徑上有些交換機(jī)已經(jīng)擁有新規(guī)則，而另一些交換機(jī)還使用舊規(guī)則，仍然會造成規(guī)則更新不一致性的問題。
較高抽象層次(high-level)更新
使用較高抽象層次(high-level)的管理方式統(tǒng)一更新,就可防止低層管理引起的不一致性問題。
采用兩階段提交方式來更新規(guī)則：
第一階段：當(dāng)某個規(guī)則需要更新時，控制器詢問每個交換機(jī)是否處理完對應(yīng)舊規(guī)則的流，并對處理完畢的所有交換機(jī)進(jìn)行規(guī)則更新。
第二階段：當(dāng)所有交換機(jī)都更新完畢時，才完成更新，否則將取消該更新操作。
兩階段提交方式的具體做法：
在預(yù)處理階段，對數(shù)據(jù)包打上標(biāo)簽以標(biāo)示新舊策略的版本號。在轉(zhuǎn)發(fā)過程中，交換機(jī)將檢查標(biāo)簽的版本，并按照對應(yīng)版本的規(guī)則執(zhí)行相應(yīng)的轉(zhuǎn)發(fā)動作，當(dāng)數(shù)據(jù)包從出口交換機(jī)轉(zhuǎn)發(fā)出去時，則去掉標(biāo)簽。
缺點(diǎn)：這種方式需要等待舊規(guī)則的數(shù)據(jù)包全部處理完畢才能處理新規(guī)則的數(shù)據(jù)包，新規(guī)則的數(shù)據(jù)包需要等待，造成了不必要的開銷。
解決方式：增量式一致性更新算法：
將規(guī)則更新分成多輪進(jìn)行，每一輪都采用二階段提交方式更新一個子集，這樣可以節(jié)省規(guī)則空間，達(dá)到更新時間與規(guī)則空間的折中。
解決安全性問題：
McGeer提出了基于OpenFlow的安全更新協(xié)議來完善抽象層兩階段提交方式的安全性，該協(xié)議將無法識別新舊規(guī)則的報(bào)文發(fā)送至控制器，來保證流轉(zhuǎn)發(fā)的正確性。
解決性能問題：
Ghorbani等人研究了虛擬機(jī)場景下規(guī)則更新算法，該算法可以確保在更新過程中擁有足夠的帶寬,同時不會影響到其他流的正常轉(zhuǎn)發(fā)。
3. 控制層關(guān)鍵技術(shù)研究
控制器是控制層的核心組件，通過控制器，用戶可以邏輯上集中控制交換機(jī)，實(shí)現(xiàn)數(shù)據(jù)的快速轉(zhuǎn)發(fā)，便捷安全地管理網(wǎng)絡(luò)，提升網(wǎng)絡(luò)的整體性能。本節(jié)首先詳細(xì)闡述了以NOX控制器為基礎(chǔ)的兩種技術(shù)改進(jìn)方法：一種是采用多線程的控制模式，另一種是通過增加分布式控制器數(shù)量，實(shí)現(xiàn)扁平式和層次式控制模式。然后介紹了主流接口語言的研究發(fā)展,實(shí)現(xiàn)控制語言抽象。最后,深入分析了控制器的一致性、可用性和容錯性等特性。
3.1 控制器設(shè)計(jì)問題
問題出現(xiàn)：單一結(jié)構(gòu)集中控制的控制器(如NOX)處理能力受到限制，擴(kuò)展困難，遇到了性能瓶頸。
解決方案：
一種是通過提高自身控制器處理能力的方式。
另一種是采用多控制器的方式來提升整體控制器的處理能力。
通過提升自身
NOX-MT
它是具有多線程處理功能的NOX控制器。
并未改變NOX控制器的基本結(jié)構(gòu)，而是利用傳統(tǒng)的并行技術(shù)提升性能。
NOX 可以快速更新至NOX-MT，且不會由于控制器平臺的更替產(chǎn)生不一致性問題。
Maestro
它通過良好的并行處理架構(gòu)，充分發(fā)揮了高性能服務(wù)器的多核并行處理能力
使其在網(wǎng)絡(luò)規(guī)模較大情況下的性能明顯優(yōu)于NOX。
多控制器的方式
集中式控制的缺陷
一個較大規(guī)模的網(wǎng)絡(luò)可分為若干個域。
若保持單一控制器集中控制的方式來處理交換機(jī)請求，因?yàn)榫嚯x等原因，該控制器將與其他域的交換機(jī)之間存在較大延遲。
單一集中控制存在單點(diǎn)失效問題。
通過擴(kuò)展控制器的數(shù)量可以解決上述問題，也就是將控制器物理分布在整個網(wǎng)絡(luò)中，僅需保持邏輯中心控制特性即可。這樣可使每個交換機(jī)都與較近的控制器進(jìn)行交互，從而提升網(wǎng)絡(luò)的整體性能。
扁平式擴(kuò)展方式
所有控制器被放置在不相交的區(qū)域里。各控制器間的地位相等，邏輯上均作為全局控制器，掌握全網(wǎng)狀態(tài)，并通過東西向接口進(jìn)行通信。
當(dāng)網(wǎng)絡(luò)拓?fù)渥兓瘯r，所有控制器將同步進(jìn)行更新，而交換機(jī)僅需調(diào)整與控制器的地址映射即可，無需進(jìn)行復(fù)雜的更新操作，因此，扁平分布式擴(kuò)展對數(shù)據(jù)層的影響較小。
典型案例：Onix。
通過網(wǎng)絡(luò)信息庫(network information base,簡稱NIB)進(jìn)行管理。
每個控制器都有對應(yīng)的NIB,通過保持NIB 的一致性,實(shí)現(xiàn)控制器之間的同步更新。
典型案例：HyperFlow。
通過注冊和廣播機(jī)制進(jìn)行通信。
并在某控制器失效時，通過手動配置的方式將失效控制器管理的交換機(jī)重新配置到新控制器上，保證了可用性。
缺陷：
雖然每個控制器掌握全網(wǎng)狀態(tài),但只控制局部網(wǎng)絡(luò)，造成了一定資源的浪費(fèi)。
增加了網(wǎng)絡(luò)更新時控制器的整體負(fù)載。
在實(shí)際部署中，不同的域可能屬于擁有不同經(jīng)濟(jì)實(shí)體的運(yùn)營商，無法做到控制器在不同域之間的平等通信。
層次式擴(kuò)展方式
層次控制方式按照用途將控制器進(jìn)行了分類。
局部控制器相對靠近交換機(jī)，它負(fù)責(zé)本區(qū)域內(nèi)包含的節(jié)點(diǎn)，僅掌握本區(qū)域的網(wǎng)絡(luò)狀態(tài)。
全局控制器負(fù)責(zé)全網(wǎng)信息的維護(hù)，可以完成需要全網(wǎng)信息的路由等操作。
層次控制器交互存在兩種方式：
一種是局部控制器與全局控制器之間的交互。
一種是全局控制器之間的交互。
典型案例：Kandoo。
當(dāng)交換機(jī)轉(zhuǎn)發(fā)未知報(bào)文時,首先詢問較近的局部控制器。
若該報(bào)文屬于局部信息,局部控制器迅速做出回應(yīng)。
若局部控制器無法處理該報(bào)文,它將詢問全局控制器，并將獲取的信息下發(fā)給交換機(jī)。
該方式避免了全局控制器的頻繁交互，有效降低了流量負(fù)載。
由于這種方式取決于局部控制器所處理信息的命中率，因此在局部應(yīng)用較多的場景中具有較高的執(zhí)行效率。
控制器的開發(fā)語言
高級語言相對計(jì)算機(jī)抽象程度高，對人的抽象程度低。所以開發(fā)相對機(jī)器語言容易，但是執(zhí)行效率卻不高。
相比之下，Python開發(fā)效率較高,執(zhí)行效率較低；而C++執(zhí)行效率很高，開發(fā)效率卻很低。
科研人員致力于開發(fā)通用的平臺，盡可能地在開發(fā)與執(zhí)行之間達(dá)到一個較好的平衡。
典型案例：Beacon。
基于Java的平臺。
它向用戶提供了一系列相關(guān)的庫與接口用于開發(fā)，并提供運(yùn)行時模塊化的功能。實(shí)現(xiàn)了開發(fā)與執(zhí)行兩者之間的平衡。
各種控制器的情況對比
接口語言
因?yàn)楦呒壵Z言存在的缺點(diǎn)，研究人員致力于開發(fā)一種抽象的、高級配置語言。這些抽象語言能夠統(tǒng)一北向接口,改善接口的性能,從而全面降低網(wǎng)絡(luò)的配置成本。
Nettle
是一種描述性語言,采用了函數(shù)響應(yīng)式編程(functional reactive programming,簡稱FRP)方式。
FRP 是基于事件響應(yīng)的編程,符合控制器應(yīng)對各種應(yīng)用的實(shí)際響應(yīng)情況。
Nettle 的目標(biāo)是實(shí)現(xiàn)網(wǎng)絡(luò)配置的可編程化。而可編程化的網(wǎng)絡(luò)配置要求控制器性能足夠高。
McNettle
一種多核Nettle 語言。
McNettle并未改變描述性與FRP的特性。
利用共享內(nèi)存、多核處理的方式增強(qiáng)了用戶開發(fā)體驗(yàn)。
Procera
進(jìn)一步對語言抽象作了優(yōu)化，采用高
級的網(wǎng)絡(luò)策略來應(yīng)對各種應(yīng)用。
Maple
進(jìn)一步抽象，允許用戶使用自當(dāng)以抽象策略。
為了高效的將抽象策略下發(fā)給交換機(jī)，Maple采用了高效的多核調(diào)度器和跟蹤運(yùn)行時優(yōu)化器(tracing runtime optimizer)來優(yōu)化性能。
該優(yōu)化器一方面通過記錄可重用的策略，將負(fù)載盡可能地轉(zhuǎn)移到交換機(jī)來處理。
另一方面,通過動態(tài)跟蹤抽象策略與數(shù)據(jù)內(nèi)容及環(huán)境的依賴性，使流表始終處于最新狀態(tài)，從而確保抽象策略轉(zhuǎn)成可用規(guī)則的效率。
多種接口語言對比
3.3 控制層特性研究
控制層存在一致性、可用性和容錯性等特性，而所提到的這3種特性的需求無法同時滿足，達(dá)到三者之間的平衡，是今后的重要工作之一。
一致性
SDN集中控制，獲取全網(wǎng)的視圖，理論上保證了網(wǎng)絡(luò)配置的一致性。
分布式的控制器任然具有潛在的不一致問題。
嚴(yán)格保證分布式狀態(tài)全局統(tǒng)一的控制器，將無法保證網(wǎng)絡(luò)性能；反之，如果控制器能夠快速響應(yīng)請求，下發(fā)策略，則無法保證全局狀態(tài)一致性。
并發(fā)策略也會導(dǎo)致不一致性，新策略的下達(dá)是通過前面提到的兩階段提交的方式實(shí)現(xiàn)。
我們知道并發(fā)下發(fā)兩種策略可能會造成資源上的沖突，流表下發(fā)錯誤，從而造成不一致性問題的發(fā)生。
利用細(xì)粒度鎖(fine-grained locking)確保組合策略無沖突發(fā)生。
典型案例：HFT。
采用了層次策略方案,它將并發(fā)策略分解，組織成樹的形式。樹的每個節(jié)點(diǎn)都可獨(dú)立形成轉(zhuǎn)發(fā)規(guī)則。
HFT首先對每個節(jié)點(diǎn)進(jìn)行自定義沖突處理操作，這樣，整個沖突處理過程就轉(zhuǎn)化成利用自定義沖突處理規(guī)則逆向搜索樹的過程，從而解決了并發(fā)策略一致性問題。
可用性
規(guī)則備份可以提升網(wǎng)絡(luò)的可用性。
RuleBricks針對規(guī)則備份提出一種高可用性方案。在RuleBricks中，不同的規(guī)則對應(yīng)不同顏色的“磚塊”，“磚塊”的大小由通配符的地址空間大小決定，其中，最上層的“磚塊”對應(yīng)的規(guī)則是目前的活躍規(guī)則。如果因?yàn)榫W(wǎng)絡(luò)節(jié)點(diǎn)失效導(dǎo)致某種顏色的“磚塊”消失，則下面的備份“磚塊”會顯現(xiàn)出來成為新的活躍規(guī)則。
控制器過重的負(fù)載將影響SDN的可用性。
分布式控制器會平衡負(fù)載，特別是層次式架構(gòu)。局部控制器承擔(dān)交換機(jī)的多數(shù)請求，全局控制器則可以更好地為用戶提供服務(wù)。
當(dāng)網(wǎng)絡(luò)流量不均勻時，分布式架構(gòu)也會出現(xiàn)有些控制器利用率低的問題，下面是解決方案：
ElastiCon采用負(fù)載窗口的方式來動態(tài)調(diào)整各控制器間的流量。ElastiCon 周期性地檢查負(fù)載窗口，當(dāng)負(fù)載窗口的總負(fù)荷發(fā)生改變時，將動態(tài)擴(kuò)充或壓縮控制器池，以適應(yīng)當(dāng)前實(shí)際需求。如果負(fù)載超過控制器池最大值時，則需要另外增加新的控制器，以保證網(wǎng)絡(luò)的可用性。
減少交換機(jī)的請求次數(shù)，也可以提高控制層的可用性。下面是案例：
DIFANE架構(gòu)旨在解決數(shù)據(jù)平面轉(zhuǎn)發(fā)規(guī)則粒度過細(xì)和對集中控制依賴的問題。DevoFlow按粒度將數(shù)據(jù)流分成長短流，將短流處理規(guī)則主動下發(fā)到數(shù)據(jù)層面，并在轉(zhuǎn)發(fā)器上建立一些特定規(guī)則。使數(shù)據(jù)層能夠直接處理短流，因此交換機(jī)不再將每流的第1個數(shù)據(jù)包傳到控制器。僅有少量的長流才交由控制層處理。根據(jù)Zipf定律，長流數(shù)量遠(yuǎn)少于短流數(shù)量。因此，DevoFlow采用的策略可以最大程度地降低控制器負(fù)載。
容錯性
SDN同樣面臨著網(wǎng)絡(luò)節(jié)點(diǎn)或鏈路失效的問題。然而,SDN控制器可以通過全網(wǎng)信息快速恢復(fù)失效節(jié)點(diǎn)，具有較強(qiáng)的容錯能力。下面描述一下SDN節(jié)點(diǎn)的收斂過程。
某臺交換機(jī)失效：
當(dāng)某臺交換機(jī)失效時，其他交換機(jī)察覺出變化。
交換機(jī)將變化情況通知控制器。
控制器根據(jù)所掌握的信息，計(jì)算出需要恢復(fù)的規(guī)則。
下發(fā)這些新規(guī)則給交換機(jī)，交換機(jī)更新流表。
在SDN 架構(gòu)中，失效信息一般不是通過洪泛方式通知全網(wǎng)，而是直接發(fā)送給控制層，并由控制器來做恢復(fù)決策，因而不易出現(xiàn)路由振蕩的現(xiàn)象。
交換機(jī)和控制器之間的鏈接失效
可以采用傳統(tǒng)網(wǎng)絡(luò)的IGP(如OSPF 協(xié)議)通信,并通過洪泛方式恢復(fù)。
也可以采用故障轉(zhuǎn)移(failover)方式，同樣能夠緩解鏈路失效收斂時間問題。通過在交換機(jī)上安裝用于驗(yàn)證拓?fù)溥B接性的靜態(tài)轉(zhuǎn)發(fā)規(guī)則,可以更好地實(shí)現(xiàn)網(wǎng)絡(luò)故障的快速收斂
總結(jié)
以上是生活随笔為你收集整理的软件定义网络(SDN)研究进展的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 搭建联盟链
- 下一篇： 新一代互联网传输协议QUIC