《SDN技術(shù)及應(yīng)用》課件-第2章

第2章SDN控制器2.1概述2.2SDN控制器的體系結(jié)構(gòu)

2.3SDN控制器的關(guān)鍵要素

2.4SDN控制器集群2.5SDN控制器的編程接口模式

2.6SDN開源控制器2.7小結(jié)復(fù)習(xí)思考題

SDN控制器是基于SDN架構(gòu)的網(wǎng)絡(luò)核心,并且可能成為全網(wǎng)的性能瓶頸。SDN控制器本身的性能、可靠性、安全性、易操作性、可擴展性等均極大地影響整個網(wǎng)絡(luò)的性能指標(biāo)。本章主要論述SDN控制器的關(guān)鍵技術(shù),這些關(guān)鍵技術(shù)組成了SDN控制器的骨架。SDN的開放性主要體現(xiàn)在SDN控制器的可編程性上,應(yīng)用程序可以通過SDN控制器提供的應(yīng)用編程接口(API)對控制器的功能進(jìn)行擴展和調(diào)用。在規(guī)模較大的SDN中,單個SDN控制器并不能很好地完成整個網(wǎng)絡(luò)的控制、調(diào)度功能,這時候通常需要多個控制器組成集群模式來協(xié)同管理整個SDN系統(tǒng),這就是所謂的分布式SDN控制器架構(gòu)。本章的最后對目前業(yè)界流行的一些開源SDN控制器進(jìn)行了介紹。

2.1概述

與傳統(tǒng)網(wǎng)絡(luò)技術(shù)相比,SDN帶來了網(wǎng)絡(luò)結(jié)構(gòu)上的創(chuàng)新,SDN的技術(shù)特征表現(xiàn)在以下幾個方面:(1)控制平面(ControlPlane)和數(shù)據(jù)平面(DataPlane)解耦;(2)網(wǎng)絡(luò)具有可編程性,有利于網(wǎng)絡(luò)創(chuàng)新;(3)網(wǎng)絡(luò)虛擬化,網(wǎng)絡(luò)具有更大的靈活性;(4)邏輯上的集中控制。

SDN數(shù)據(jù)轉(zhuǎn)發(fā)與轉(zhuǎn)發(fā)策略相分離的原則使得SDN交換機得到了極大的簡化和瘦身,SDN交換機僅僅專注于數(shù)據(jù)的轉(zhuǎn)發(fā),例如,基于OpenFlow協(xié)議的SDN交換機僅僅是根據(jù)SDN控制器下發(fā)的流表進(jìn)行數(shù)據(jù)包的匹配和動作(轉(zhuǎn)發(fā)、丟棄等)。流表就是交換機數(shù)據(jù)包的匹配和轉(zhuǎn)發(fā)規(guī)則,SDN交換機上流表的形成是由SDN控制器根據(jù)上層應(yīng)用程序的應(yīng)用需求而制定的,這也就是所謂的軟件定義網(wǎng)絡(luò)的基本含義。由此可見,SDN控制器成為整個網(wǎng)絡(luò)系統(tǒng)的核心和關(guān)鍵,

SDN控制器本身的性能、可靠性、安全性、易操作性、可擴展性等均極大地影響整個網(wǎng)絡(luò)的性能指標(biāo)。

SDN控制器是純軟件技術(shù)實現(xiàn)的一種“設(shè)備”,該軟件運行的硬件設(shè)備(一般是通用服務(wù)器)沒有具體的要求,通常要根據(jù)實際網(wǎng)絡(luò)的規(guī)模以及業(yè)務(wù)運行情況而考慮,但通用服務(wù)器的CPU和內(nèi)存一般要明顯強于單臺SDN交換機的硬件設(shè)備。SDN控制器除了實現(xiàn)與SDN交換機進(jìn)行通信的基本功能外,還要包含在此基礎(chǔ)上網(wǎng)絡(luò)運轉(zhuǎn)所需要的一些基本功能模塊。這就好比買了一套毛坯的新房,一般是沒法立即住人的(即使將就住了也會感到生活不方便),還需要進(jìn)行裝修、買家電設(shè)施才能住得舒服。這些基本功能主要包括通信協(xié)議實現(xiàn)、模塊管理、事件機制、任務(wù)日志、資源數(shù)據(jù)庫、交換機管理、網(wǎng)絡(luò)拓?fù)涔芾?、被動式流表管理等?/p>

SDN控制器通常需要為上層業(yè)務(wù)提供調(diào)用的接口,這些接口或者API應(yīng)能夠為應(yīng)用程序的使用提供方便,這里所說的上層既包括本地上層應(yīng)用程序,也包括遠(yuǎn)程應(yīng)用程序(不在同一臺硬件設(shè)備上)。另外,如果SDN需要和其他非SDN實現(xiàn)互通,必須具備一些非SDN所要求具備的接口協(xié)議,

如邊界網(wǎng)關(guān)協(xié)議(BGP)。SDN控制器一般具有的基本功能如下:

(1)與交換機實現(xiàn)通信的南向接口功能,如實現(xiàn)OpenFlow協(xié)議;

(2)網(wǎng)絡(luò)的基本功能要素,如鏈路發(fā)現(xiàn)、拓?fù)涔芾砗椭鳈C追蹤;

(3)對外編程接口,如遠(yuǎn)程RESTAPI、本地API;

(4)與其他設(shè)備或路由器互通的網(wǎng)絡(luò)功能,如三層路由協(xié)議。

從編程的模式上看,SDN的可編程性非常類似于傳統(tǒng)的軟件設(shè)計,可以分為兩個層次:一個是細(xì)粒度的函數(shù)級編程,即所謂的網(wǎng)絡(luò)編程語言。它將SDN架構(gòu)的網(wǎng)絡(luò)元素進(jìn)行功能抽象,形成各種用于編程中的庫函數(shù),這些函數(shù)的功能主要集中在向上層應(yīng)用程序提供一系列描述SDN的網(wǎng)絡(luò)狀態(tài)、拓?fù)浣Y(jié)構(gòu)、端口數(shù)據(jù)統(tǒng)計、定義/改變/刪除/查詢/轉(zhuǎn)發(fā)規(guī)則。應(yīng)用程序可以直接調(diào)用這些函數(shù)實現(xiàn)對SDN進(jìn)行編程控制。另一個實際上是模塊化的“組件”設(shè)計,即網(wǎng)絡(luò)功能抽象。

網(wǎng)絡(luò)功能抽象是在網(wǎng)絡(luò)編程語言的基礎(chǔ)上進(jìn)行更高一級的封裝,以實現(xiàn)某個較為復(fù)雜的網(wǎng)絡(luò)功能,如負(fù)載均衡、環(huán)路避免等。

SDN可編程性體現(xiàn)在兩個方面:一個是SDN交換機的可編程性,另一個是SDN控制器的可編程性。對于SDN交換機的可編程一般應(yīng)用較少,目前主要是基于SDN控制器下發(fā)一些轉(zhuǎn)發(fā)策略,而不直接調(diào)用SDN交換機的API或統(tǒng)一資源定位符(URI),例如,目前的OpenFlow主要是依賴下發(fā)流表來改變交換機的行為。但也存在可以直接編程的SDN交換機,例如,擴展的OpenFlow(OpenFlow+Extensions)就是一種可以編程的通信協(xié)議,可以通過編程進(jìn)行數(shù)據(jù)操作和管理操作(如隊列管理、監(jiān)控、測量),擴展的OpenFlow支持SDN的高度可編程性。

SDN交換機的可編程性主要體現(xiàn)在以下幾個方面:

①轉(zhuǎn)發(fā)規(guī)則、算法的可編程;

②網(wǎng)絡(luò)協(xié)議的可編程;

③交換機資源分配和隔離的可編程;

④交換機數(shù)據(jù)緩存的可編程。

如圖2－1所示,SDN控制器向上(北向接口)提供供本地調(diào)用的API和遠(yuǎn)程調(diào)用的RESTAPI,北向接口由于面向具體的應(yīng)用,所以標(biāo)準(zhǔn)化工作一直不理想。SDN控制器向下提供的接口(南向接口)目前主要是OpenFlow協(xié)議,用于下發(fā)轉(zhuǎn)發(fā)策略(流表)。圖2－1SDN網(wǎng)絡(luò)架構(gòu)

2.2SDN控制器的體系結(jié)構(gòu)

SDN控制器是一種純軟件的設(shè)備,從某種意義上可以將SDN控制器看做是一種網(wǎng)絡(luò)操作系統(tǒng),該操作系統(tǒng)所基于的硬件設(shè)備可以看做是SDN交換機設(shè)備,但SDN控制器軟件并不運行于眾多的SDN交換機上,而是運行于分離的或集中的服務(wù)器設(shè)備上,這是SDN區(qū)別于傳統(tǒng)網(wǎng)絡(luò)的一個主要方面。

通常我們將SDN交換機稱為數(shù)據(jù)平面(DataPlane),而將SDN控制器稱為控制平面(ControlPlane)。傳統(tǒng)的交換設(shè)備數(shù)據(jù)平面與控制平面緊密耦合,控制平面分散在每臺交換

設(shè)備中,而SDN技術(shù)將傳統(tǒng)的交換設(shè)備中的控制平面集中到控制器上,并通過南向接口協(xié)議與數(shù)據(jù)平面進(jìn)行互動。

圖2－2給出了SDN控制器的體系結(jié)構(gòu)。SDN控制器的結(jié)構(gòu)通?？梢苑譃榫W(wǎng)絡(luò)驅(qū)動層、網(wǎng)絡(luò)抽象層、網(wǎng)絡(luò)資源層和網(wǎng)絡(luò)應(yīng)用層。

網(wǎng)絡(luò)驅(qū)動層以插件的方式提供不同的南向接口協(xié)議,如OpenFlow、NetConfig、XMPP、PCEP(PathComputationElementProtocol)等,SDN控制器通過南向接口連接SDN數(shù)據(jù)平面,其數(shù)據(jù)傳輸一般采用TCP(傳輸控制器協(xié)議)或SSL(安全的套接字層)連接。網(wǎng)絡(luò)抽象層是對網(wǎng)絡(luò)物理資源的進(jìn)一步抽象,屏蔽了底層網(wǎng)絡(luò)協(xié)議之間的差異,以統(tǒng)一的接口向上提供服務(wù),如邏輯路由、邏輯交換、邏輯VAS(ValueAddedService)、邏輯網(wǎng)絡(luò)等抽象模塊。網(wǎng)絡(luò)資源層是對網(wǎng)絡(luò)抽象層的功能進(jìn)一步拓展,能夠為更多的網(wǎng)絡(luò)應(yīng)用提供較為完整的網(wǎng)絡(luò)服務(wù),如FARIC、拓?fù)浒l(fā)現(xiàn)、路徑計算、主機管理等功能。

網(wǎng)絡(luò)應(yīng)用層實際上是基于SDN控制器的應(yīng)用開發(fā),通常是通過本地API直接調(diào)用控制器所提供的網(wǎng)絡(luò)資源服務(wù),在形式上可以和控制器代碼緊密集成在一起,也可以作為一個相對獨立的應(yīng)用程序存在,如L3VPN應(yīng)用、L2VPN應(yīng)用、BGP應(yīng)用、QoS應(yīng)用等。SDN北向接口為第三方應(yīng)用提供了本地API或遠(yuǎn)程RESTAPI接口,如OpenStack、負(fù)載均衡、網(wǎng)絡(luò)安全策略控制、質(zhì)量保證、流量控制等應(yīng)用,這些應(yīng)用一般具備某種特殊的用途,而SDN控制又不具備這樣的能力(通常適合特定的業(yè)務(wù)或組織機構(gòu)使用)。

圖2－2SDN控制器的體系結(jié)構(gòu)

一個網(wǎng)絡(luò)操作系統(tǒng)通常應(yīng)具備下述功能:

(1)公平合理地為用戶管理網(wǎng)絡(luò)資源。確保所有用戶都擁有同樣的權(quán)利,沒有資源匱乏的用戶,也沒有資源泛濫的用戶,能夠公平合理地分配網(wǎng)絡(luò)資源。

(2)網(wǎng)絡(luò)隔離。每個用戶都希望全權(quán)分配資源,所以需要將用戶相互隔離,在多個應(yīng)用和多個設(shè)備之間進(jìn)行多路傳輸,并且將資源虛擬化,讓用戶享用各自的網(wǎng)絡(luò)操作系統(tǒng)(NOS)虛擬化實例。

(3)提供一個抽象層讓用戶方便地使用操作系統(tǒng)所管理的服務(wù)和資源,并且無需了解網(wǎng)絡(luò)的復(fù)雜性。在不改變應(yīng)用的前提下,可以靈活拓展網(wǎng)絡(luò)操作系統(tǒng)所管理的設(shè)備。

(4)為用戶提供安全保障。

(5)提供敏捷高效的服務(wù)。那么,用戶就不需要創(chuàng)建、重建相同的服務(wù)。

2.3SDN控制器的關(guān)鍵要素

表2－1列出了有關(guān)SDN控制器的10個關(guān)鍵要素,這些要素往往成為評價或決定采用哪種類型控制器的主要依據(jù),這些要素也充分體現(xiàn)了SDN的特點。

2.3.1支持OpenFlow協(xié)議

盡管SDN的南向接口協(xié)議并沒有規(guī)定必須是OpenFlow協(xié)議,但目前幾乎所有的SDN控制器均支持OpenFlow,人們也往往將SDN控制器是否支持OpenFlow最新協(xié)議版本作為衡量一款SDN控制器是否值得采用的重要依據(jù)。

OpenFlow協(xié)議的創(chuàng)意最初來自斯坦福大學(xué)的創(chuàng)新團(tuán)隊,團(tuán)隊于2009年發(fā)布了OpenFlow協(xié)議的第一個正式版本。OpenFlow1.0版本的優(yōu)勢是它可以與現(xiàn)有的商業(yè)交換芯片兼容,通過在傳統(tǒng)交換機上升級固件就可以支持OpenFlow1.

0版本,因此是目前使用和支持最廣泛的協(xié)議版本。隨后在2011年又推出了OpenFlow協(xié)議1.1版,同年3月成立了ONF組織,用于主導(dǎo)并推動OpenFlow協(xié)議的發(fā)展。隨著ONF組織的成立,OpenFlow協(xié)議得到了更快的發(fā)展,目前已經(jīng)發(fā)展到1.5版。

OpenFlow協(xié)議中除了規(guī)定一些必須實現(xiàn)的功能外,還定義了一系列可選的特征選項,這些選項功能并不強制要求實現(xiàn)。另外,廠家在標(biāo)準(zhǔn)協(xié)議之外往往會額外添加一些擴展功能,這些擴展功能通常用于解決一些特殊的問題。在采購SDN控制器設(shè)備時,除了要關(guān)注設(shè)備是否支持OpenFlow相關(guān)版本之外,也需要了解相關(guān)設(shè)備廠商的技術(shù)路線圖。

2.3.2網(wǎng)絡(luò)虛擬化

SDN最重要的優(yōu)點就是網(wǎng)絡(luò)虛擬化。網(wǎng)絡(luò)虛擬化并不是一個新的概念,在SDN概念出現(xiàn)之前網(wǎng)絡(luò)虛擬化的概念就已存在。簡單來講,網(wǎng)絡(luò)虛擬化是指把邏輯網(wǎng)絡(luò)從底層的物理網(wǎng)絡(luò)中分離出來,多個邏輯網(wǎng)絡(luò)共享底層網(wǎng)絡(luò)基礎(chǔ)設(shè)施,從而提高網(wǎng)絡(luò)資源利用率。

在傳統(tǒng)網(wǎng)絡(luò)中,網(wǎng)絡(luò)虛擬化通常指的是虛擬局域網(wǎng)(VLAN)或虛擬路由和轉(zhuǎn)發(fā)(VirtualRoutingandForwarding,VRF)。VLAN可將網(wǎng)絡(luò)劃分為多達(dá)4094個廣播域的子網(wǎng),在以太網(wǎng)包頭中可以為每個廣播域指定一個12位的VLAN標(biāo)識符(ID)。VRF是面向三層網(wǎng)絡(luò)虛擬化的一種,其中的物理路由器支持多個虛擬路由器實例,每個實例各自獨立運行自身的路由協(xié)議,維護(hù)自身的路由轉(zhuǎn)發(fā)表。

由于SDN具有集中控制的能力,因此具備全局網(wǎng)絡(luò)視角,可進(jìn)行全網(wǎng)范圍內(nèi)的流量調(diào)度和資源劃分。傳統(tǒng)網(wǎng)絡(luò)資源的劃分一般是預(yù)先設(shè)置,是一種靜態(tài)劃分,但SDN因能夠?qū)崟r獲知全網(wǎng)的動態(tài)運行狀況,并據(jù)此進(jìn)行資源的動態(tài)分配,所以能夠更精確地、細(xì)粒度地配置網(wǎng)絡(luò)資源,從而實施網(wǎng)絡(luò)虛擬化功能,按需使用、調(diào)配各種網(wǎng)絡(luò)軟硬件資源。

2.3.3網(wǎng)絡(luò)功能化

隨著云應(yīng)用、云技術(shù)的發(fā)展,基于安全因素的考慮,云租戶通常希望能將其業(yè)務(wù)應(yīng)用流量與其他租戶之間相互隔離,互不影響,邏輯上相互獨立。SDN控制器可以在提供網(wǎng)絡(luò)虛擬化的同時提供更好的網(wǎng)絡(luò)隔離措施,例如,OpenFlow協(xié)議中數(shù)據(jù)轉(zhuǎn)發(fā)是根據(jù)流表項匹配規(guī)則進(jìn)行的,流表項涵蓋了從物理層到應(yīng)用層幾乎所有的包頭域信息,包括物理入端口、出端口、MAC源地址、目的地址、源IP地址、目的IP地址、源端口、目的端口等,這種轉(zhuǎn)發(fā)方式允許對業(yè)務(wù)數(shù)據(jù)流進(jìn)行細(xì)粒度的控制。

另一方面,SDN控制器具有集中控制和自動配置的能力,有能力發(fā)現(xiàn)源端到目的端多條轉(zhuǎn)發(fā)路徑,并可以進(jìn)行多條不同路徑的數(shù)據(jù)流分發(fā),即所謂的多徑轉(zhuǎn)發(fā)功能,同時能夠逐跳進(jìn)行QoS的參數(shù)定義。

SDN的多徑轉(zhuǎn)發(fā)能力可以有效避免傳統(tǒng)網(wǎng)絡(luò)中生成樹協(xié)議(SpanningTreeProtocol,STP)的限制,并且不再需要增加更為復(fù)雜的最短路徑橋接(ShortestPathBridging,SPB)和多鏈接透明互聯(lián)(TRansparentInterconnectionofLotsofLinks,TRILL)協(xié)議。

STP的主要應(yīng)用是為了避免局域網(wǎng)中的網(wǎng)絡(luò)環(huán)回,解決成環(huán)以太網(wǎng)中的“廣播風(fēng)暴”問題,從某種意義上說是一種網(wǎng)絡(luò)保護(hù)技術(shù),可以消除由于失誤或者意外帶來的循環(huán)連接。STP也為網(wǎng)絡(luò)提供了備份連接的可能,但是由于協(xié)議機制本身的局限,STP的保護(hù)速度慢,如果在城域網(wǎng)內(nèi)部運用STP技術(shù),用戶網(wǎng)絡(luò)的動蕩會引起運營商網(wǎng)絡(luò)的動蕩。SDN控制器具有全網(wǎng)視圖,按照OpenFlow協(xié)議規(guī)定,當(dāng)一臺主機設(shè)備通過某網(wǎng)絡(luò)端口加入現(xiàn)有網(wǎng)絡(luò)時,由于現(xiàn)有交換機上沒有處理該端口上的流表,因此該臺設(shè)備所發(fā)送的ARP數(shù)據(jù)包將被統(tǒng)一發(fā)送到SDN控制器,這樣,SDN可以獲得任何端設(shè)備的網(wǎng)絡(luò)路徑,并計算出端到端設(shè)備之間的最短路徑,所以在這種情況下沒有形成網(wǎng)絡(luò)環(huán)路的可能。

傳統(tǒng)的局域網(wǎng)是二層和三層網(wǎng)絡(luò)的結(jié)合,SDN的引入不應(yīng)該削弱原有二層和三層網(wǎng)絡(luò)的應(yīng)用功能。例如,SDN控制器必須具有在多租戶的虛擬網(wǎng)內(nèi)創(chuàng)建二層和三層網(wǎng)絡(luò)的能力,這種能力包括在末端設(shè)備之間的二層網(wǎng)絡(luò)流量交換以及將二層流量封裝到三層路由流量中(這實際上是TRILL技術(shù)的原理)。此外,SDN控制器還需要包括使運營商可以實現(xiàn)智能過濾等功能。

2.3.4可擴展性

傳統(tǒng)的局域網(wǎng)中一般存在多個層次架構(gòu)的網(wǎng)絡(luò),三層的路由主要用于不同的二層網(wǎng)絡(luò)之間互聯(lián)。SDN的橫向擴展包括兩種形式的擴展,一種擴展是在同一個SDN控制器所控制的區(qū)域內(nèi)增加SDN交換機,如圖2－3所示;另一種擴展不僅包括交換機的增加,也相應(yīng)地增加SDN控制器的數(shù)量,如圖2－4所示。圖2－3在同一個SDN內(nèi)增加交換機圖2－4增加新的SDN

SDN的結(jié)構(gòu)是一種扁平化的網(wǎng)絡(luò)結(jié)構(gòu),這是由于SDN交換設(shè)備可以處理不同層次的網(wǎng)絡(luò)數(shù)據(jù)包,正如在OpenFlow1.

0協(xié)議中規(guī)定的12元組分屬于不同的網(wǎng)絡(luò)層次。例如,流表項如果設(shè)置為目的MAC地址轉(zhuǎn)發(fā),這就相當(dāng)于傳統(tǒng)網(wǎng)絡(luò)設(shè)備中的交換設(shè)備;如果是以目的IP地址進(jìn)行轉(zhuǎn)發(fā),則就相當(dāng)于一臺路由設(shè)備。這種網(wǎng)絡(luò)處理特點使得SDN可以很方便地進(jìn)行橫向擴展,添加、更改、刪除網(wǎng)絡(luò)設(shè)備并不會對整個網(wǎng)絡(luò)的管理產(chǎn)生影響,對全網(wǎng)的管理就如同對一臺網(wǎng)絡(luò)設(shè)備進(jìn)

行管理一樣。SDN的集中式架構(gòu)的一個重要指標(biāo)就是SDN控制器能夠管理的交換機數(shù)量,網(wǎng)絡(luò)管理人員和機構(gòu)希望這個數(shù)量至少能夠達(dá)到100臺交換機,具體的數(shù)據(jù)應(yīng)根據(jù)實際業(yè)務(wù)來調(diào)整。

影響網(wǎng)絡(luò)擴展性的另一個因素是網(wǎng)絡(luò)廣播,當(dāng)一個網(wǎng)絡(luò)內(nèi)存在大量的網(wǎng)絡(luò)廣播數(shù)據(jù)包時必然增加SDN控制器的處理負(fù)擔(dān),導(dǎo)致SDN控制器控制網(wǎng)絡(luò)的能力下降,因此,網(wǎng)絡(luò)廣播數(shù)據(jù)包的存在可能使SDN控制器的橫向擴張性變差,SDN控制器應(yīng)具備緩解網(wǎng)絡(luò)廣播所造成的影響的能力。針對前面所說的ARP數(shù)據(jù)包,為了避免二層網(wǎng)絡(luò)環(huán)路,很多SDN控制器都對ARP數(shù)據(jù)包進(jìn)行了特殊處理。例如,Floodlight采用多目標(biāo)廣播跨越樹(multicastspanningtree)來避免二層環(huán)路,收到交換機發(fā)上來的ARP包后會先查詢廣播樹,然后決定ARP包該被泛洪或是從某些端口轉(zhuǎn)發(fā)。

流表的數(shù)量也是影響擴展性的一個重要因素,流表數(shù)量大必將降低SDN的性能。SDN控制器必須為每個數(shù)據(jù)流的每跳產(chǎn)生相應(yīng)的轉(zhuǎn)發(fā)規(guī)則(即流表),這樣容易造成大量的流表操作(流表的增加、刪除、更改)。目前雖然有些SDN控制器已經(jīng)具備了很強的處理能力,例如,ONOS控制器的流處理能力是1百萬/秒個流操作,但這在規(guī)模較大的SDN內(nèi)其流處理能力恐怕也是不夠的,因此,SDN控制器必須具備對流表數(shù)量進(jìn)行優(yōu)化的能力,從而最小化流表的產(chǎn)生。例如,通過匹配元組支持通配符的方式將流進(jìn)行分類,不再逐流設(shè)置流表而是按類設(shè)置流表。

此外,SDN控制器的擴展性還體現(xiàn)在是否具備在不同站點之間遷移的能力。例如,兩個不同的SDN站點服務(wù)器和存儲設(shè)備相互備份,當(dāng)其中一個網(wǎng)絡(luò)站點出現(xiàn)故障時,SDN控制器可將出現(xiàn)故障的站點網(wǎng)絡(luò)轉(zhuǎn)發(fā)策略自動應(yīng)用到另一個正常運行的站點的服務(wù)器和存儲設(shè)備上。

2.3.5網(wǎng)絡(luò)性能

SDN控制器的主要功能之一是創(chuàng)建流表,因此,SDN控制器的兩個關(guān)鍵性能指標(biāo)是流表的設(shè)置時間和每秒設(shè)置流表的數(shù)量。當(dāng)網(wǎng)絡(luò)規(guī)模擴大時,交換機所需要的流表數(shù)量超過了SDN控制器的處理能力時,必須增加新的SDN控制器設(shè)備。

流表的設(shè)置分為主動和被動兩種方式,主動方式是在指流表在數(shù)據(jù)流達(dá)到交換機之前就已經(jīng)產(chǎn)生并下發(fā)到交換機上。在這種方式下,當(dāng)?shù)谝粋€數(shù)據(jù)包到達(dá)交換機時,交換機就已經(jīng)知道該如何處理該數(shù)據(jù)包,因此流表的設(shè)置時間可以忽略不計,并且也不限制每秒設(shè)置流表的數(shù)量。所謂的被動方式,是指當(dāng)?shù)谝粋€數(shù)據(jù)包到達(dá)交換機時,交換機上沒有處理該數(shù)據(jù)包的流表,該數(shù)據(jù)包將被交換機轉(zhuǎn)發(fā)到SDN控制器上進(jìn)行處理,同時交換機上緩存該數(shù)據(jù)包,SDN控制器根據(jù)收到的數(shù)據(jù)包被動地產(chǎn)生流表并下發(fā)到交換機上,緩存的數(shù)據(jù)包以及后續(xù)數(shù)據(jù)就可以按此流表進(jìn)行匹配操作。

在被動設(shè)置方式中,流表的設(shè)置時間是以下四部分時間之和:

(1)數(shù)據(jù)包從交換機發(fā)送到SDN控制器的時間;

(2)SDN控制器處理該數(shù)據(jù)包的時間;

(3)新產(chǎn)生的流表發(fā)送到交換機的時間;

(4)流表保存在交換機上的時間。

因此,在被動方式下影響流表設(shè)置時間的關(guān)鍵因素是交換機的處理能力、控制器的處理能力和I/O性能,而控制器的處理能力和I/O性能不僅取決于硬件設(shè)備的能力,也受到軟件的影響。例如,使用C語言編寫的控制器要比Java語言編寫的控制器性能好。

2.3.6網(wǎng)絡(luò)可編程性

在傳統(tǒng)的網(wǎng)絡(luò)環(huán)境中,通常需要對每個交換設(shè)備分別進(jìn)行配置,這既費時又容易導(dǎo)致錯誤,并且容易產(chǎn)生配置信息不一致的情況。而且這種配置方法是靜態(tài)的,不會隨著網(wǎng)絡(luò)狀態(tài)的改變而改變配置信息,這種靜態(tài)性會嚴(yán)重地影響網(wǎng)絡(luò)性能。傳統(tǒng)網(wǎng)絡(luò)由于缺乏開放性,很難對其內(nèi)部網(wǎng)絡(luò)進(jìn)行直接編程處理,一般是通過命令行編寫腳本文件對網(wǎng)絡(luò)進(jìn)行一些參數(shù)配置。

SDN的一個關(guān)鍵特征就是控制器具備開放的編程接口。例如,基于安全因素的考慮,SDN控制器具有數(shù)據(jù)流重定向的可編程能力,網(wǎng)絡(luò)管理員可以將訪問服務(wù)器的輸入數(shù)據(jù)流強制通過一個防火墻進(jìn)行過濾處理,而從服務(wù)器流出的干凈數(shù)據(jù)流則不必經(jīng)過防火墻處理,這樣的處理方式在傳統(tǒng)網(wǎng)絡(luò)中是很難實現(xiàn)的。

2.3.7網(wǎng)絡(luò)可靠性

SDN控制器能夠掌握全網(wǎng)視圖,能夠動態(tài)地、智能化地分析網(wǎng)絡(luò)各鏈路之間運行狀態(tài),可以自動配置網(wǎng)絡(luò)以避免出現(xiàn)手工錯誤,從而提高SDN的可靠性。SDN控制器提高網(wǎng)絡(luò)可靠性的另一技術(shù)就是前面所提到的多徑傳輸,SDN控制器能夠發(fā)現(xiàn)數(shù)據(jù)源端與目的端之間存在的多條傳輸路徑,如果控制器配置的源端到目的端的一條傳輸路徑失效,控制器必須能夠快速地將流量遷移到另一條運行正常的鏈路上,這就需要控制器持續(xù)地監(jiān)控網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。

對于外部連接的可用性,重要的一點是控制器應(yīng)能支持一些可替代的技術(shù)和設(shè)計,如用于提高網(wǎng)絡(luò)可靠性的虛路由冗余協(xié)議(VirtualRouterRedundancyProtocol,VRRP)和多框鏈路聚合組(MultiChassisLinkAggregateGroup,MCLAG)。

人們擔(dān)心的另一個問題是,如此重要的SDN控制器本身的可靠性又如何呢?顯然,單個控制器的故障將會導(dǎo)致整個網(wǎng)絡(luò)的可用性下降,為了解決這一問題,控制器無論在硬件上還是軟件上均要進(jìn)行冗余設(shè)計,SDN控制器集群化是一種必要的手段。例如,兩臺SDN控制器集群,采取一臺主用,一臺熱備份的模式能夠提高網(wǎng)絡(luò)可靠性、可擴展性以及性能。但是為了縮短自愈時間,在這些集群的控制器之間應(yīng)具有內(nèi)存同步能力。

2.3.8網(wǎng)絡(luò)安全性

為了保障網(wǎng)絡(luò)安全,SDN控制器必須能夠在網(wǎng)管系統(tǒng)中支持企業(yè)級鑒別和授權(quán),網(wǎng)絡(luò)管理員必須能夠?qū)刂破髁髁恳约捌渌囊恍╆P(guān)鍵流量進(jìn)行管控。除此之外,SDN的安全性體現(xiàn)在以下幾個方面:

(1)復(fù)雜的包過濾能力,或動態(tài)的、智能的訪問控制列表(ACL);

(2)網(wǎng)絡(luò)多租戶之間的網(wǎng)絡(luò)隔離;

(3)對控制類通信流量的限制;

(4)網(wǎng)絡(luò)受到攻擊時,提供告警機制。

2.3.9網(wǎng)絡(luò)的集中管理和可視化

傳統(tǒng)網(wǎng)絡(luò)的運行過程中,通常首先是網(wǎng)絡(luò)的使用者———用戶,而不是網(wǎng)絡(luò)的管理人員,發(fā)現(xiàn)網(wǎng)絡(luò)的應(yīng)用性能下降,這將導(dǎo)致用戶對網(wǎng)絡(luò)服務(wù)質(zhì)量的抱怨。網(wǎng)絡(luò)管理人員未能及時發(fā)現(xiàn)網(wǎng)絡(luò)性能下降的關(guān)鍵原因是網(wǎng)絡(luò)管理人員無法看到端到端的網(wǎng)絡(luò)流量。

SDN的優(yōu)勢之一就是能夠給網(wǎng)絡(luò)管理人員提供物理網(wǎng)絡(luò)和虛擬網(wǎng)絡(luò)的端到端可視化視圖,這些視圖包括網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)和流量分布。SDN控制器可以隨時掌控網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的變化,一旦網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)發(fā)生變化,第一個獲知者一定是SDN控制器。例如,當(dāng)網(wǎng)絡(luò)增加了一臺設(shè)備時,由于沒有為該設(shè)備設(shè)置相關(guān)的流表,因此與該設(shè)備相關(guān)的ARP數(shù)據(jù)包會第一時間發(fā)給控制器。同樣,當(dāng)SDN中某臺設(shè)備出現(xiàn)故障導(dǎo)致該設(shè)備不可用時,網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)發(fā)生了調(diào)整,SDN控制器同樣能發(fā)現(xiàn)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的變化。其次,SDN針對網(wǎng)絡(luò)流量提供了多種多樣的統(tǒng)計計數(shù)器。

例如,在OpenFlow協(xié)議中,為每個匹配域設(shè)置一個包計數(shù)器,為每個流表也設(shè)置一個計數(shù)器字段。因此,SDN控制器就能夠非常詳細(xì)地了解每一臺設(shè)備、每一條鏈路上的流量分布,把這些信息通過一些圖形化的顯示技術(shù)提供給網(wǎng)絡(luò)管理人員,會極大地提高網(wǎng)絡(luò)管理人員對網(wǎng)絡(luò)運行狀態(tài)的了解。在某些理想情況下,上述網(wǎng)絡(luò)信息也應(yīng)該以RESTAPI的方式開放給網(wǎng)絡(luò)終端用戶。另外,網(wǎng)絡(luò)管理人員通常希望采用標(biāo)準(zhǔn)的協(xié)議和技術(shù)對SDN控制器本身進(jìn)行監(jiān)控。例如,

使用簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)監(jiān)控SDN控制器和虛擬網(wǎng)絡(luò)的健康狀態(tài)。

2.3.10SDN控制器供應(yīng)商

隨著SDN技術(shù)和市場的發(fā)展,各大網(wǎng)絡(luò)廠商爭相進(jìn)入這一領(lǐng)域,出現(xiàn)了越來越多的SDN控制器。由于SDN市場的不穩(wěn)定性和特殊性,除了考慮技術(shù)本身之外,也應(yīng)仔細(xì)考慮供應(yīng)商的品質(zhì),這些品質(zhì)包括供應(yīng)商的財務(wù)、技術(shù)資源、對SDN技術(shù)的持續(xù)投入與關(guān)注、市場定位和競爭能力。

傳統(tǒng)的網(wǎng)絡(luò)協(xié)議在廠商之間具有很大程度的互操作性,例如,一家廠商的使用BGP協(xié)議的設(shè)備可以被其他廠商使用BGP協(xié)議的設(shè)備所理解,雖然廠商可能會在協(xié)議中增加一些私有特性,但是通用網(wǎng)絡(luò)設(shè)備廠商基本上都會遵守一條底線。然而在SDN方面,情況卻并非如此。目前還沒有創(chuàng)建SDN控制器的統(tǒng)一方式,也沒有一套關(guān)于SDN必須具備哪些功能的要求。因為SDN還是一項新興技術(shù),所有廠商都在發(fā)布能夠代表其SDN觀念的控制器,盡可能在市場中突出自己,從而力爭成為市場領(lǐng)導(dǎo)者,因此,在考慮SDN控制器供應(yīng)商時,要謹(jǐn)慎考慮廠商鎖定隱藏的風(fēng)險。

2.4SDN控制器集群

毫無疑問,SDN控制器對于把握全網(wǎng)資源視圖、改善網(wǎng)絡(luò)資源交付都具有非常重要的作用。但是SDN控制器管理著SDN中分布的多臺轉(zhuǎn)發(fā)設(shè)備,隨著網(wǎng)絡(luò)規(guī)模的擴大,控制能力的集中化,意味著控制器本身的安全性和性能成為全網(wǎng)的瓶頸,控制器也會面臨單點失效的問題,一旦控制器在性能或安全性上得不到保障,隨之而來的就是全網(wǎng)的服務(wù)能力的降級甚至是中斷。

另外,單一的控制器也無法應(yīng)對跨地域的SDN問題,因此需要多個SDN控制器組成的分布式集群,以避免單一的控制器節(jié)點在可靠性、擴展性、性能等方面出現(xiàn)的問題。單一的SDN控制器所能控制的SDN交換機轉(zhuǎn)發(fā)節(jié)點數(shù)量有限,不能滿足較大網(wǎng)絡(luò)規(guī)?；虻乩矸秶植驾^廣的網(wǎng)絡(luò)控制集中管理。例如,NOX的處理能力大約為每秒30k個請求。因此,在較大規(guī)模的數(shù)據(jù)中心,必須考慮分級、分層的多級分布式控制的SDN集群控制器。據(jù)某數(shù)據(jù)中心測算,通常一個1500臺服務(wù)器集群每秒產(chǎn)生100K個請求,100臺交換機的數(shù)據(jù)中心每秒產(chǎn)生10000K個請求。

2.4.1SDN控制器集群的關(guān)鍵技術(shù)

如前所述,SDN控制器本質(zhì)上是通用服務(wù)器,因此SDN控制器集群實際上也就是計算機服務(wù)器集群。所謂集群,就是由一些互相連接在一起的計算機構(gòu)成的一個并行或分布式系統(tǒng),這些計算機一起工作并運行一系列共同的應(yīng)用程序,同時為用戶和應(yīng)用程序提供單一的系統(tǒng)映射。從邏輯上看,它們僅僅是一個系統(tǒng),對外提供統(tǒng)一的服務(wù)和接口。通俗地講,服務(wù)器集群系統(tǒng)就是把多臺服務(wù)器通過高速網(wǎng)絡(luò)連接起來,對外就好像是“一臺服務(wù)器”在工作。例如,當(dāng)我們使用Google搜索時,看起來我們的搜索請求像是只被一臺Web服務(wù)器所接受,但事實上我們的搜索請求是被一群Web服務(wù)器(可能成千上萬臺服務(wù)器)所接受,只不過它們是在一個集群中。

控制器的分布式集群從某種程度上解決了SDN控制器的橫向擴展性問題。作為SDN的控制面,分布式架構(gòu)的控制平面相比于分布的數(shù)據(jù)平面要復(fù)雜得多,關(guān)鍵在于必須將分布的網(wǎng)絡(luò)拓?fù)鋽?shù)據(jù)當(dāng)做一個整體來看待,這就需要在集群節(jié)點中建立一個可靠的組播通信系統(tǒng),而不只是對分布的拓?fù)鋽?shù)據(jù)、計算任務(wù)進(jìn)行簡單的劃分。SDN控制器集群的主要作用體現(xiàn)在以下幾個方面:

(1)規(guī)?；?在集群模式下多個控制器可以承擔(dān)更多的任務(wù)或存儲更多的數(shù)據(jù)。

(2)高可用性:如果在多控制器組成的集群中有一個控制器出現(xiàn)故障,其他控制器仍然可以繼續(xù)工作,確保整個網(wǎng)絡(luò)系統(tǒng)的正常運行。

(3)數(shù)據(jù)持久性:單臺控制器重啟或因故障而宕機不會造成數(shù)據(jù)丟失。

基于上述SDN控制器集群的主要特點,通常情況下SDN控制器集群系統(tǒng)的設(shè)計應(yīng)考慮以下方面的一些關(guān)鍵技術(shù)。

1.SDN控制器集群虛IP地址技術(shù)

交換機啟動時首先要向集群控制器發(fā)起連接,但是向集群中哪一臺控制器發(fā)起連接呢?當(dāng)然應(yīng)該是主控制器,問題是主控制器可能會發(fā)生變化,那么,當(dāng)主控制器下線或發(fā)生故障時,交換機就要向新的主控制器發(fā)起新的連接,這樣,交換機實際上要受到主控制器變動的影響。解決這一問題的思路可以采用服務(wù)器負(fù)載均衡技術(shù),集群服務(wù)器對外只有一個統(tǒng)一的IP地址,該IP地址是一個虛IP地址,所有的交換機均以統(tǒng)一的虛IP地址連接控制器,集群服務(wù)器管理系統(tǒng)根據(jù)相關(guān)的負(fù)載均衡策略負(fù)責(zé)將虛IP地址映射到后臺服務(wù)器真實的IP地址上,實現(xiàn)控制器集群對交換機的透明化管理。

2.主控制器選舉算法

在集群的主控制器運行期間,集群的備份控制器需要周期性地監(jiān)控主控制器的狀態(tài),一旦發(fā)現(xiàn)主控制器下線或發(fā)生故障,網(wǎng)絡(luò)訪問不可達(dá)時,就要啟動主控制器的選舉算法。這里需要說明的是,主控制器可以是相對特定交換機而言的,也可以是相對所有交換機而言的。前者意味著交換機A和B可能有不同的主控制器,實現(xiàn)起來比較復(fù)雜,但性能較好;后者則意味著交換機A和B的主控制器是同一臺控制器,實現(xiàn)起來相對比較簡單,但性能肯定不如前者。

假如某控制器成為交換機A的主控制器,其他控制器就成為交換機A的備份控制器,該控制器也可能成為其他交換機的主控制器或備份控制器,但屬于交換機A的主控制器有且僅有一個。例如,交換機A連接主控制器1,該集群中其他的控制器就成為交換機A的備份控制器,一旦主控制器1下線或

發(fā)生故障,就必須確定一臺備份控制器成為交換機A的主控制器,一旦某臺備份控制器成為交換機A的主控制器,那么其他備份控制器就不能再試圖成為交換機A的主控制器,也就是集群中的備份控制器應(yīng)就“誰”成為交換機A的主控制器的問題達(dá)成一致。

解決分布式系統(tǒng)就某個值或決議達(dá)成一致這個問題的一個經(jīng)典算法是Paxos算法,該算法是由LeslieLamport在1990年提

出的,是一種基于消息傳遞的一致性算法。在算法設(shè)計中,需要考慮算法實現(xiàn)的復(fù)雜度,特別是如果控制器集群部署在廣域網(wǎng)中,還要考慮帶寬延遲等網(wǎng)絡(luò)質(zhì)量因素。

3.集群模式下全網(wǎng)絡(luò)拓?fù)涞墨@取、歸集和分發(fā)技術(shù)

在一個大型的SDN中,基于全網(wǎng)的流量分布特點以及網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)進(jìn)行全網(wǎng)流量調(diào)度是一個重要的業(yè)務(wù)功能。SDN區(qū)別于傳統(tǒng)網(wǎng)絡(luò)的一個重要特征是SDN控制器可以比較容易獲得全網(wǎng)的流量分布情況。根據(jù)OpenFlow協(xié)議,一旦某交換機針對某個數(shù)據(jù)流未設(shè)置相匹配的流表,該流將被送到控制器上進(jìn)行處理,因此,控制器很容易獲得與其相連的各個網(wǎng)絡(luò)拓?fù)湟约傲髁拷y(tǒng)計的信息。在單控制器的SDN中,該控制器掌握著全網(wǎng)的拓?fù)湫畔?能夠根據(jù)拓?fù)湫畔崿F(xiàn)資源

的優(yōu)化調(diào)度,但在集群控制器中,這樣的拓?fù)湫畔⒎植荚诓煌闹骺刂破髦?如何將這些拓?fù)湫畔⑦M(jìn)行集中處理以便進(jìn)行全網(wǎng)拓?fù)湫畔⒌墨@取也是SDN控制器集群的一個關(guān)鍵問題。

為了獲得全網(wǎng)控制器和交換機的工作情況,集群管理系統(tǒng)軟件可以定期要求各個主控制器進(jìn)行鏈路發(fā)現(xiàn),并將采集回來的網(wǎng)絡(luò)信息發(fā)送給集群管理軟件進(jìn)行匯總處理,分析出全網(wǎng)的拓?fù)浣Y(jié)構(gòu)以及流量分布特點,再由集群管理系統(tǒng)軟件統(tǒng)一下發(fā)給各個控制器。在定制數(shù)據(jù)流的轉(zhuǎn)發(fā)策略時,控制器一旦發(fā)現(xiàn)數(shù)據(jù)流傳輸涉及的設(shè)備超過其控制的交換機范圍,就會根據(jù)全網(wǎng)拓?fù)涓嬷粨Q機對應(yīng)的控制器,并通過協(xié)商制定一致的策略,然后統(tǒng)一下發(fā)給交換機。

4.主控制器負(fù)載均衡技術(shù)

當(dāng)一臺剛啟動的交換機通過集群虛IP地址連接控制器時,集群中所有的控制器均是該交換機的備份控制器,備份控制器之間根據(jù)相關(guān)算法(如Paxos)選舉出該設(shè)備的主控制器,并將交換機訪問的虛IP地址映射到該主控制器的真實的IP地址上。如果選舉算法中沒有考慮負(fù)載均衡策略,就容易造成某臺控制器成為很多交換機的主控制器,從而導(dǎo)致各控制器負(fù)擔(dān)不均。例如,在ONOS控制器軟件系統(tǒng)中ONOS實例會“搶奪”交換機設(shè)備,可能造成某些ONOS控制器設(shè)備管

理過多的交換機設(shè)備,而另一些ONOS設(shè)備則沒有或只有很少的交換機與其連接。

因此,利用負(fù)載均衡技術(shù)實現(xiàn)主控制器之間的負(fù)載均衡,連接新的交換機或?qū)⒋饲爸概墒У姆?wù)器虛擬IP地址映射到其他工作正常的主控制器上,同時觸發(fā)對全網(wǎng)拓?fù)湫畔⒌母潞瞳@取。對于負(fù)載過重的主控制器,可以通過一些負(fù)載均衡算法讓出一些交換機給其他備份控制器控制。

5.控制器集群中如何確保各網(wǎng)路設(shè)備的邏輯和狀態(tài)的一致性

在集群各控制器之間保存了大量的網(wǎng)絡(luò)拓?fù)浜蜖顟B(tài)信息,這些信息需要在各控制器之間保持信息的同步和一致性,這些信息的同步和一致性以及一致性時延問題是控制器集群高效運轉(zhuǎn)的一個關(guān)鍵指標(biāo)。集群的可用性和一致性往往是矛盾的,一致性強(信息同步時延少)導(dǎo)致可用性差,應(yīng)在確保可用性的前提下盡量做到一致性強。集群控制器邏輯和狀態(tài)一致性設(shè)計的關(guān)鍵是集群通信架構(gòu)的設(shè)計,要采用一些成熟的集群通信架構(gòu),

如JGroups,該架構(gòu)是一個開源的、使用Java編寫的、成熟可靠的組播通信機制,其主要功能包括節(jié)點成員發(fā)現(xiàn)、節(jié)點間的組播通信以及節(jié)點間狀態(tài)信息的傳遞等。JGroups使用TCP作為傳輸方式并且通過UDP多播進(jìn)行組成員節(jié)點的發(fā)現(xiàn),其適合場合有服務(wù)器集群、多服務(wù)器通訊、服務(wù)器復(fù)制、分布式cache緩存等。

利用集群化的控制器,SDN能夠避免單一控制器造成的單點失效問題,同時具有良好的擴展性以應(yīng)對海量的交換機流量。尤其是在廣域網(wǎng)環(huán)境下,多地部署的集群控制器可有效改善OpenFlow數(shù)據(jù)包的傳輸延遲,較好地提升網(wǎng)絡(luò)性能。

試想一下,當(dāng)我們在一個已有的SDN控制器集群系統(tǒng)中引入另一種SDN控制器設(shè)備時,是否需要重新開發(fā)能夠兼容新的SDN控制器設(shè)備的集群管理系統(tǒng)呢?顯然,集群SDN控制器之間需要邏輯和狀態(tài)信息同步,這些信息應(yīng)該以標(biāo)準(zhǔn)化的格式出現(xiàn),而適合于不同操作環(huán)境下信息交互的最好的形式應(yīng)該是XML(擴展標(biāo)記語言),所以不同控制器之間應(yīng)以XML文件格式來實現(xiàn)信息同步。SDN控制器橫向擴展的標(biāo)準(zhǔn)化工作也是未來SDN控制器性能擴展需要考慮的問題。

2.4.2SDN控制器集群的現(xiàn)有方案

針對SDN控制器橫向擴展問題,目前也出現(xiàn)了一些設(shè)計方案,這些方案可以分為兩大類:一類是扁平化的SDN控制器集群;另一類是分層級的SDN控制器集群。分層級控制的主要思想就是將現(xiàn)有網(wǎng)絡(luò)劃分為不同的控制區(qū)域,在每個區(qū)域內(nèi)設(shè)置一個或多個控制器,這些控制器通過保證網(wǎng)絡(luò)狀態(tài)的一致性來實現(xiàn)對網(wǎng)絡(luò)的統(tǒng)一管理和控制,如HyperFlow、Kandoo,控制器之間也可以形成上下級關(guān)系。而所謂的集群模式,實際上是負(fù)載均衡在控制器上的應(yīng)用,如Master/

Slaves、ONOS。

1.ONOS

由斯坦福大學(xué)和加州大學(xué)伯克利分校的SDN先驅(qū)創(chuàng)立的非營利性組織ON.Lab推出的開源SDN操作系統(tǒng)ONOS可以作為服務(wù)器部署在集群和服務(wù)器上,在每臺服務(wù)器上運行相同的ONOS軟件,在ONOS服務(wù)器發(fā)生故障時可以快速地進(jìn)行故障切換。分布式核心平臺是ONOS架構(gòu)特征的關(guān)鍵,它能夠為用戶提供一個運營商級的可靠性的運行環(huán)境。

ONOS1.1.0版支持集群模式,ONOS使用Hazelcast架構(gòu)實現(xiàn)對集群成員的管理,各控制器之間彼此分享各自的運行狀態(tài),共同管理網(wǎng)絡(luò)中的設(shè)備。Hazelcast是一個高度可擴展的Java數(shù)據(jù)分發(fā)和集群平臺,可用于實現(xiàn)分布式數(shù)據(jù)存儲、數(shù)據(jù)緩存。Hazelcast的集群屬于“無主節(jié)點”,不是傳統(tǒng)的客戶端/服務(wù)器(C/S)系統(tǒng)。

在集群中某臺服務(wù)器上的ONOS實例啟動以后,ONOS將“搶奪”網(wǎng)絡(luò)中的設(shè)備,開始請求成為該設(shè)備的主控制器(Master),在成為該設(shè)備的主控制器后,ONOS開始下發(fā)BDDP(BroadcastversionofLLDP)廣播包來探測網(wǎng)絡(luò)鏈路生成拓?fù)?鏈路更新觸發(fā)拓?fù)涓率录V播,其他實例也將同步更新,實現(xiàn)共享全局網(wǎng)絡(luò)視圖。一旦某臺服務(wù)器上的ONOS實例成為網(wǎng)絡(luò)中某臺交換機的主控制器后,其他服務(wù)器上的ONOS實例則自動成為該交換機的備份控制器

(Standby)。

這種機制容易造成ONOS實例間負(fù)擔(dān)不均,極端情況下某一個ONOS實例成為所有網(wǎng)絡(luò)設(shè)備的主設(shè)備。為了緩解這種極端情況的產(chǎn)生,ONOS提供了一種均衡機制,ONOS可以將自己的主控制器身份“轉(zhuǎn)讓”給其他控制器。此外,當(dāng)某臺服務(wù)器上的ONOS實例突然下線或發(fā)生故障時,連接該實例的網(wǎng)絡(luò)設(shè)備會重新連接其他活躍的ONOS實例。

2.HyperFlow

HyperFlow是一種基于OpenFlow的分布式控制平面方案,實際上是基于NOX(一種SDN控制器)的應(yīng)用程序。HyperFlow由控制器組件和事件發(fā)布系統(tǒng)(訂閱/發(fā)布模型)組成。其中,控制器組件的主要功能包括控制器狀態(tài)修改事件的捕獲及序列化、事件發(fā)送與回放、向交換機發(fā)送命令等;事件系統(tǒng)擁有全網(wǎng)視圖,并以訂閱/發(fā)布模式來傳輸控制器節(jié)點之間的網(wǎng)絡(luò)事件,完成節(jié)點間信息的同步。只有捕獲到相應(yīng)的事件,控制器才會改變狀態(tài),通過訂閱/發(fā)布模式序列化并

發(fā)布事件。HyperFlow是基于分布式文件系統(tǒng)WheelFS而設(shè)計的,網(wǎng)絡(luò)事件在不同控制器之間以文件的形式來傳輸。

HyperFlow通過將網(wǎng)絡(luò)劃分為多個邏輯區(qū)域,每個區(qū)域內(nèi)部署一個或者多個控制器來管理OpenFlow交換機,交換機采用就近原則連接控制器,每臺控制器只需要管理特定區(qū)域中的OpenFlow交換機,擁有一定處理局部范圍內(nèi)事件的權(quán)利,而把影響全局的事件不定期地對外發(fā)布,其他控制器接收到事件消息后會重發(fā)該消息以達(dá)到全網(wǎng)視圖的同步。HyperFlow中每個控制器需要維護(hù)全局的網(wǎng)絡(luò)狀態(tài),并且實時地對其進(jìn)行同步更新。這種方式能夠應(yīng)對一些不頻繁更新

的事件,如鏈路狀態(tài)的改變,但對于規(guī)模很大并且狀態(tài)變化頻繁的網(wǎng)絡(luò)來說,控制器間的狀態(tài)維護(hù)會帶來一定的開銷,成為系統(tǒng)的瓶頸。目前,HyperFlow還無法實現(xiàn)對全局?jǐn)?shù)據(jù)流狀態(tài)的實時可見性。

3.MSDN

MSDN是aMechanismforScalableIntra-DomainControlPlaninSDN的簡稱,是由清華大學(xué)提出的一種SDN控制器集群方案,如圖2－5所示。MSDN是一個大型的邏輯意義上的控制器,整個架構(gòu)自頂向下分為三層:第一層是負(fù)載均衡系統(tǒng);第二層是控制器集群系統(tǒng);第三層是分布式的數(shù)據(jù)共享系統(tǒng)。當(dāng)一個數(shù)據(jù)流請求數(shù)據(jù)包到達(dá)這個邏輯的控制器后,首先被負(fù)載均衡系統(tǒng)按照某種調(diào)度算法分發(fā)到第二層某臺實際的物理控制器上,然后物理控制器調(diào)用第三層的數(shù)據(jù)共享系統(tǒng)查看網(wǎng)絡(luò)的全局視圖,計算該數(shù)據(jù)流的轉(zhuǎn)發(fā)路徑并生成、安裝相應(yīng)流表。對于請求的返回數(shù)據(jù)包,物理控制器直接返回,不再經(jīng)過負(fù)載均衡系統(tǒng)。圖2－5負(fù)載均衡思想應(yīng)用于SDN控制器集群

負(fù)載均衡器可以按照多種算法對數(shù)據(jù)包進(jìn)行分發(fā),如輪詢算法,根據(jù)IP地址用哈希算法進(jìn)行散列,所有控制器都是等價的,其任務(wù)是根據(jù)全網(wǎng)視圖計算第一個流的轉(zhuǎn)發(fā)路徑和OpenFlow表項。

4.Kandoo

Kandoo創(chuàng)建了兩層的多控制器設(shè)計方案,該方案將控制器分為如圖2－6所示的兩類:一類是本地控制器(

LocalController);另一類是根控制器(RootController)。在該方案中,將應(yīng)用劃分為僅僅需要使用本地網(wǎng)絡(luò)的本地應(yīng)用以及需要全網(wǎng)視圖的非本地應(yīng)用兩類,前者應(yīng)用運行于LocalController上,LocalController以就近原則管理本地交換機,而RootController則運行非本地的控制器應(yīng)用,控制所有的LocalController。當(dāng)網(wǎng)絡(luò)規(guī)模較大時,LocalController可通過集群的方式實現(xiàn),而Rootcontroller可以采用分布式控制器來實現(xiàn)。圖2－6一種典型的分層結(jié)構(gòu)的控制器集群架構(gòu)

2.5SDN控制器的編程接口模式

SDN控制器的編程接口可以通過編程的方式擴展或利用SDN的功能。SDN控制器的南向接口主要面向SDN交換機,其標(biāo)準(zhǔn)化程度較高,一般情況下不需要進(jìn)行功能擴展,SDN控制器的編程接口主要是指SDN控制器的北向編程接口。

目前,北向API的標(biāo)準(zhǔn)化工作一直是空白,這是因為北向接口面向具體的業(yè)務(wù)層,業(yè)務(wù)層對網(wǎng)絡(luò)層的需求很難抽象出帶有普適性的標(biāo)準(zhǔn),如同在軟件領(lǐng)域提倡多年的面向業(yè)務(wù)的組件(SOA)發(fā)展不盡如人意的原因一樣,很難設(shè)計出可以應(yīng)用于各個領(lǐng)域的SDN業(yè)務(wù)組件,這也恰恰說明北向API實際上是整個SDN應(yīng)用的關(guān)鍵和技術(shù)難點。

應(yīng)用程序需要對SDN進(jìn)行再次編程的理由主要基于兩點:一是應(yīng)用程序需要根據(jù)自身的業(yè)務(wù)需求動態(tài)地改變網(wǎng)絡(luò)設(shè)置;二是沒有一款SDN控制器具備所有的網(wǎng)絡(luò)功能,也就是說,有可能需要在SDN控制器原有的功能之上增加新的功能。例如,對于一款沒有路由功能的SDN控制器,我們可以借助SDN控制器提供的API設(shè)計新的路由模塊(實現(xiàn)BGP協(xié)議)。從這個意義上來說,SDN的開放性和可編程性為我們進(jìn)行網(wǎng)絡(luò)協(xié)議的創(chuàng)新提供了便利,使得傳統(tǒng)意義上所認(rèn)為的

“高貴的”、難于接近的計算機網(wǎng)絡(luò)內(nèi)部協(xié)議的設(shè)計、測試、運行變得“平民化”,其研究手段和方法的難度得到了極大的降低。

SDN控制通常通過兩種方式對上層應(yīng)用程序提供相應(yīng)的網(wǎng)絡(luò)服務(wù),一種是本地API方式,這種方式要求應(yīng)用程序與控制器耦合程度高,具體來說,就是應(yīng)用程序和SDN控制器必須在同一計算機上運行,這樣就限制了應(yīng)用程序的使用環(huán)境,在實際中具有很大的局限性;另一種模式是遠(yuǎn)程調(diào)用API方式,這種模式允許應(yīng)用程序遠(yuǎn)程調(diào)用SDN控制器提供的編程接口,應(yīng)用程序和SDN控制可以部署在不同的物理機器上。后一種模式正式的稱呼就是RESTAPI遠(yuǎn)程調(diào)用。

2.5.1本地API調(diào)用

本地API調(diào)用方式實際上就是控制器提供相應(yīng)的軟件開發(fā)包(SDK),網(wǎng)絡(luò)應(yīng)用程序通過調(diào)用SDK中提供的函數(shù)與控制器緊密耦合在一起,控制器在開發(fā)過程中需要對相關(guān)的網(wǎng)絡(luò)功能進(jìn)行有效的封裝,使開發(fā)者使用起來更為容易。通常,使用C語言開發(fā)的控制器以動態(tài)庫的形式對外提供編程接口,而Java語言開發(fā)的控制器則以jar文件的形式對外提供服務(wù)。

另一方面,隨著開源控制器的出現(xiàn),開發(fā)者也可以在控制器的源代碼上直接增添新的代碼,與控制器源碼一起重新編譯鏈接成新的控制器。例如,在Floodlight和OpenDaylight控制器的新功能的開發(fā)通常是將新功能源碼嵌入到控制器源碼中。該方法的優(yōu)點是可以通過分析控制器源碼更準(zhǔn)確地理解和調(diào)用控制器提供的編程接口,缺點是開發(fā)者入門比較困難,需要了解控制器的整體框架和很多技術(shù)細(xì)節(jié),很多初學(xué)者往往會覺得非常困難。相比而言,直接調(diào)用控制器封裝好的SDK則由于不需要深入了解控制器內(nèi)部實現(xiàn)細(xì)節(jié)而顯得更容易上手。

2.5.2RESTAPI遠(yuǎn)程調(diào)用

REST是表述性狀態(tài)傳輸(REpresentationalStateTransfer)的英文縮寫,是由RoyThomasFielding博士在他2000年發(fā)表的博士論文《ArchitecturalStylesandDesignofNetwork-based

SoftwareArchitectures》中提出的一種軟件框架。這是一種通過URL訪問資源的方法,是一種Web服務(wù)模式,但REST模式與復(fù)雜的SOAP和XMLRPC相比要更簡單實用,是一種輕量級的Web服務(wù)架構(gòu)。RESTAPI調(diào)用是基于HTTP協(xié)議的,API的展現(xiàn)不像傳統(tǒng)的函數(shù)調(diào)用方式,它的參數(shù)就是通過HTTPGet/Post等方法上傳的參數(shù),Web服務(wù)的返回值類型通常以XML或JSON的數(shù)據(jù)形式提供。

一個提供REST調(diào)用風(fēng)格的Web服務(wù)也稱為RESTful,它是一個使用HTTP協(xié)議并遵循REST設(shè)計原則的Web服務(wù),RESTful一般具有以下特征:

(1)基本的統(tǒng)一資源定位符(URI),如http://example.com/resources/。

(2)一種Internet常用的數(shù)據(jù)類型,通常是JSON、XML、Atom、Images等。

(3)標(biāo)準(zhǔn)的HTTP方法,如GET、PUT、POST或DELETE。

(4)通過超鏈接方式引用狀態(tài)。所謂通過超鏈接方式引用狀態(tài),就是說數(shù)據(jù)狀態(tài)信息的維護(hù)是通過超鏈接來實現(xiàn)的。例如,在http:///resources/login.do?name=wang這個URI中,將name傳給了后臺Web服務(wù),后臺Web服務(wù)如何記住這個name呢?在一般的Web應(yīng)用或網(wǎng)站中通?？梢允褂枚喾N方式實現(xiàn)這一目的,如會話(Session)、隱藏表單域或Cookie等方法。但在RESTfulWeb服務(wù)中只能通過超鏈接方式再次在URI后面添加name=wang這樣的方式來實現(xiàn)。

(5)通過超鏈接方式引用相關(guān)資源。

表2－2列出RESTfulAPIHTTP方法的典型應(yīng)用。

REST架構(gòu)遵循CRUD原則,CRUD原則對于資源只需要四種行為:Create(創(chuàng)建)、Read(讀取)、Update(更新)和Delete(刪除)。通過這四種行為就可以完成對資源的操作和處理。這四個操作是一種原子操作,即一種無法再分的操作,通過它們可以構(gòu)造更加復(fù)雜的操作過程。

2.6SDN開源控制器

因為SDN控制器占有重要地位,顯然是兵家必爭之地,因此,很多公司和組織都投入到SDN控制器的研究和開發(fā)中,陸陸續(xù)續(xù)地出現(xiàn)了很多SDN控制器,如OpenDaylight、OpenContrail、Ryu、Floodlight、NOX、SPOX等,其中最受矚目的莫過于OpenDaylight和ONOS。

2.6.1SDN開源控制器簡介

表2－3列出了目前已經(jīng)發(fā)布的SDN控制器,其中很多控制器為開源控制器,這些控制器均支持OpenFlow協(xié)議。

2013年4月,IBM、Cisco、微軟、NEC、Juniper、BigSwitch(后退出)等多家IT巨頭合作啟動了OpenDaylight項目。OpenDaylight采用Java開發(fā),是一套開源的SDN框架。它是一種在Linux基礎(chǔ)上的開源代碼,其目的是進(jìn)一步推行SDN的創(chuàng)新。OpenDaylight的努力方向是建立一種SDN能夠承載并享有執(zhí)行能力的智慧型社區(qū),它將SDN、OpenFlow、OpenStack以及NFV靈活地聚集在一起,同時結(jié)合大數(shù)據(jù)、云計算、OpenStack以及服務(wù)鏈的應(yīng)用。OpenDaylight軟件是一個組合的組件,包括一個完全可插拔控制器、接口、協(xié)議插件和應(yīng)用。這種組合允許供應(yīng)商和客戶能夠利用一個基于標(biāo)準(zhǔn)的技術(shù)創(chuàng)新支撐平臺,在這個共同的平臺上,客戶和供應(yīng)商進(jìn)行創(chuàng)新和合作,提出以商業(yè)化SDN和NFV為基礎(chǔ)的解決方案。

Floodlight是由BigSwitchNetworks公司主導(dǎo)開發(fā)的開源項目,它的目標(biāo)是成為企業(yè)級的OpenFlow控制器。Floodlight遵循的是Apache許可證,是基于Java的OpenFlow控制器,其核心代碼被BigSwitchNetworks的商業(yè)化產(chǎn)品所使用并經(jīng)過專業(yè)測試,具有較高的性能和可靠性。Floodlight不僅僅是一個支持OpenFLow協(xié)議的控制器(FloodlightController),也是一個基于Floodlight控制器的應(yīng)用集。當(dāng)用戶在支持OpenFLow協(xié)議的網(wǎng)絡(luò)上運行各種應(yīng)用程序的時候,Floodlight控制器實現(xiàn)了對網(wǎng)絡(luò)的監(jiān)控和查詢功能。

Floodlight的軟件模塊可以分為兩種類型,即用于實現(xiàn)SDN核心網(wǎng)絡(luò)服務(wù)的控制器模塊和針對不同業(yè)務(wù)應(yīng)用實現(xiàn)解決方案的應(yīng)用模塊?？刂破髂K提供JavaAPI供應(yīng)的模塊調(diào)用,同時兩類模塊還共同支持向上層開放RESTAPI作為

北向接口。

NOX由Nicira公司主導(dǎo)開發(fā)。因為Nicira公司的創(chuàng)始者大多數(shù)來自Stanford大學(xué)的OpenFlow研發(fā)組,所以NOX是和OpenFlow并肩成長的,也是業(yè)界第一款支持OpenFlow協(xié)議的控制器,并在2008年被Nicira公司貢獻(xiàn)給開源社區(qū)。

最初在NOX控制器上的開發(fā)支持Python、C++語言,NOX的核心架構(gòu)和關(guān)鍵部分都是使用C++實現(xiàn)以保證其性能。隨著項目的演進(jìn),當(dāng)前的項目可以分為NOX和POX兩個版本。其中,NOX版本主要面向Linux平臺,利用C++開發(fā),目標(biāo)是提供快速的控制器平臺;POX版本則利用Python開發(fā),能夠在Windows、MacOS、Linux等多種平臺上運行,目標(biāo)是提供控制器部署的便利性。NOX是一個單

件的軟件定義的網(wǎng)絡(luò)生態(tài)系統(tǒng),它為開發(fā)者和研究者提供了一個平臺,以推動家庭網(wǎng)絡(luò)和企業(yè)網(wǎng)絡(luò)的創(chuàng)新,開發(fā)者可以在這個平臺上利用NOX控制網(wǎng)絡(luò)中所有的連接,也可以介入所有的數(shù)據(jù)流的傳輸。

同時,NOX也為網(wǎng)絡(luò)運營商提供了一個有用的網(wǎng)絡(luò)軟件,它可以支持對網(wǎng)絡(luò)中相關(guān)交換機的管理,在用戶和主機層面上進(jìn)行權(quán)限管控,并具備一個完整的策略引擎。

Ryu是由日本NTT公司負(fù)責(zé)設(shè)計研發(fā)的一款開源SDN控制器。同POX一樣,Ryu也是完全由Python語言實現(xiàn),使用者可以在Python語言上實現(xiàn)自己的應(yīng)用。Ryu目前支持OpenFlow1.0、1.2、1.3版,遵循Apache許可證。Ryu控制器中提供了大量的組件和庫函數(shù)供SDN應(yīng)用的開發(fā)。其中,庫函數(shù)是Ryu針對SDN控制器需求抽取出的一些共性功能,這些庫函數(shù)可以在組件的實現(xiàn)中被直接調(diào)用,而組件之間的關(guān)系則是相互獨立的。

Ryu支持與OpenStack云計算管理平臺的整合,這使得網(wǎng)絡(luò)資源能夠與計算資源、存儲資源一起被統(tǒng)一交付給用戶,實現(xiàn)了資源池化和按需調(diào)度,這一點對虛擬主機等云計算典型業(yè)務(wù)而言非常關(guān)鍵。當(dāng)前,Ryu已經(jīng)被Pia8等公司在其推出的面向云計算的網(wǎng)絡(luò)開發(fā)平臺產(chǎn)品中采用,并取得了很好的效果。同時,隨著OpenStack的不斷發(fā)展和成熟,Ryu在利用SDN改善云計算服務(wù)方面將會起到更加重要的作用。

2.6.2OpenDaylight控制器

OpenDaylight是一個項目的名稱,同時也是一個組織的名稱,會員分為鉑金會員、黃金會員和白銀會員,這些會員均來自于IT行業(yè)的知名企業(yè)。鉑金會員主要包括Brocade、Cisco(思科)、Citrix、Ericsson(愛立信)、Hp、IBM、Juniper、Microsoft(微軟)、Redhat。黃金會員有NEC、

Vmware。更多的會員是白銀會員,我國的中興通訊(ZTE)和華為都在白銀會員之列。從這些主要的會員成分來看,OpenDaylight無疑是一個側(cè)重供應(yīng)商的開源項目。

OpenDaylight屬于Linux基金會推出的一個開源項目,其主要目的是通過開源的方式創(chuàng)建共同的供應(yīng)商支持框架,而不依賴于某一個供應(yīng)商,創(chuàng)造一個供應(yīng)商中立的開放環(huán)境,每個人都可以貢獻(xiàn)自己的力量,從而不斷推動SDN的部署和創(chuàng)新,打造一個共同開放的SDN平臺,在這個平臺上進(jìn)行SDN的普及與創(chuàng)新,供開發(fā)者來利用、貢獻(xiàn)和構(gòu)建商業(yè)產(chǎn)品及技術(shù)。OpenDaylight的最終目標(biāo)是建立一套標(biāo)準(zhǔn)化軟件,幫助用戶以此為基礎(chǔ)開發(fā)出具有附加值的應(yīng)用程序。

OpenDaylight項目軟件版本以化學(xué)元素周期表方式命名,至今已經(jīng)推出Hydrogen(氫)、Helium(氦)、Lithium(鋰)、BeryLlium(鈹)、Boron(硼)等版本。Hydrogen1.0又分為三個不同的版本:基礎(chǔ)版(BaseEdition)、虛擬化版(VirtualizationEdition)、服務(wù)提供商版(Service

ProviderEdition)。OpenDaylight項目開始的幾個版本的介紹文檔很少,直到鋰版本的發(fā)布才相應(yīng)地推出配套的用戶手冊。

1.OpenDaylight架構(gòu)

OpenDaylight控制器平臺的系統(tǒng)架構(gòu)如圖2－7所示,該框架平臺包括一系列功能模塊,可動態(tài)組合提供不同的服務(wù),其中主要包括拓?fù)涔芾?、轉(zhuǎn)發(fā)管理、主機監(jiān)測、交換機管理等模塊。服務(wù)抽象層(SAL)是控制器模塊的核心,自動適配底層不同的設(shè)備,使開發(fā)者專注于業(yè)務(wù)應(yīng)用的開發(fā)。SAL北向連接功能模塊以插件的形式提供底層設(shè)備服務(wù),南向接口連接多種協(xié)議插件,屏蔽不同協(xié)議的差異性,為北向功能模塊提供一致性服務(wù),業(yè)務(wù)適配層起到中間調(diào)度的作用。南向接口支持多種不同協(xié)議,如OpenFlow、OpenFlow流表類型匹配、NETCONF、BGP/PCEP以及CAPWAP等。圖2－7OpenDaylight架構(gòu)示意圖

整個框架邏輯上從上到下可以分為四個平面層次,即網(wǎng)絡(luò)應(yīng)用層、控制平面、南向接口和協(xié)議插件層和數(shù)據(jù)平面。網(wǎng)絡(luò)應(yīng)用程序經(jīng)過AAA認(rèn)證登錄控制器并通過控制器提供的API(RESTs)調(diào)用相關(guān)的網(wǎng)絡(luò)服務(wù)。控制平面又可以分為兩層,上層為網(wǎng)絡(luò)服務(wù)層,下層為服務(wù)抽象層,網(wǎng)絡(luò)服務(wù)層包括網(wǎng)絡(luò)基本服務(wù)(網(wǎng)絡(luò)必備的功能,如拓?fù)涔芾?、狀態(tài)管理、交換機管理、流表管理、主機追蹤等)和其他服務(wù)(網(wǎng)絡(luò)可選的功能,如BGP服務(wù),OpenStack服務(wù)、LISP服務(wù)、L2交換服務(wù)等)。

服務(wù)抽象層為網(wǎng)絡(luò)服務(wù)層訪問南向接口和協(xié)議插件層提供統(tǒng)一的訪問界面,屏蔽了南向接口和協(xié)議插件層不同協(xié)議之間的差異。南向接口和協(xié)議插件層以插件的形式包含多種協(xié)

議,利用這些協(xié)議負(fù)責(zé)與SDN交換機進(jìn)行交互,通過下發(fā)各種轉(zhuǎn)發(fā)策略或接收來自交換機的信息來管理數(shù)據(jù)平面。數(shù)據(jù)平面理論上可以包括各種各樣的交換設(shè)備,包括支持OpenFlow協(xié)議的設(shè)備、OpenvSwitch、虛擬或物理設(shè)備。

從上述OpenDaylight的框架內(nèi)容來看,OpenDaylight控制器對網(wǎng)絡(luò)應(yīng)用程序而言,其可供調(diào)用的網(wǎng)絡(luò)服務(wù)就是控制平面網(wǎng)絡(luò)服務(wù)層的各種服務(wù),這些服務(wù)是以組件(也可以稱為插件)的形式存在,支持用熱插拔的方式啟用或卸載,表2－4列出了OpenDaylightHelium版本所支持的組件。

注:all表示該組件可以與其他任何組件一起運行,self+all表示該組件可以和其他任何標(biāo)注為“all”的組件一

起運行,但不能和其他“self+all”的組件一起運行。

2.OpenDaylight核心技術(shù)

OpenDaylight軟件項目使用Java語言開發(fā),在技術(shù)上采用了很多成熟的Java技術(shù)框架,包括OSGI(OpenServiceGatewayInitiative)、Maven、Infinispan、SAL(ServiceAbstractionLayer)、Netty、REST等。

1)OSGI框架

OpenDaylight基于OSGI的實現(xiàn)ApacheKaraf來構(gòu)造系統(tǒng),OSGI是一種面向服務(wù)的架構(gòu),同時也是面向Java的動態(tài)模型系統(tǒng),OSGI將應(yīng)用視為對等模塊的相互協(xié)作,支持控制器運行時對相關(guān)組件的安裝、刪除和更新操作,每一個組件被稱為一個Bundle,OpenDaylight的內(nèi)部應(yīng)用就是一個個的Bundle。借助于OSGI的架構(gòu),OpenDaylight系統(tǒng)具有很好的靈活性和可擴展性,這對于大型系統(tǒng)而言是非常重要的,下面簡單介紹OSGI框架。

在介紹OSGI框架之前,有必須先了解一下OSGI聯(lián)盟。OSGI聯(lián)盟是一個由SunMicrosystems、Ericsson、IBM等公司在1999年3月成立的開放的標(biāo)準(zhǔn)化組織,最初該組織被稱為ConnectedAlliance,它是一個非營利性的國際組織。正如OSGI字面的含義所示,OSGI成立之初的主要想法是為各式各樣的網(wǎng)絡(luò)服務(wù)設(shè)備提供一個統(tǒng)一的網(wǎng)關(guān)服務(wù)平臺,使開發(fā)者能夠創(chuàng)建動態(tài)的、模塊化的Java服務(wù)器系統(tǒng)。

由于OSGI的諸多優(yōu)秀特性(可動態(tài)改變系統(tǒng)行為、熱插拔的插件體系結(jié)構(gòu)、高可復(fù)用性、高效性等),因此被用于許多PC上的應(yīng)用開發(fā)。OSGI框架是一個輕巧的、松耦合的、面向服務(wù)的應(yīng)用程序開發(fā)框架。OSGI發(fā)展到今天已經(jīng)得到了眾多企業(yè)、廠商、開源組織的支持,主流的Java應(yīng)用服務(wù)器(Oracle的Weblogic、IBM的Websphere及Sun的Glassfish等)都已經(jīng)采用了OSGI。

OSGI規(guī)范的核心組件是OSGI框架,在OSGI中的應(yīng)用程序被稱為組件,OSGI的整個框架包括服務(wù)注冊、生命周期管理和規(guī)范服務(wù)三個方面的內(nèi)容。其中,服務(wù)注冊為Bundles的動態(tài)特征提供了協(xié)作模型,Bundles之間可以使用傳統(tǒng)的類共享機制實現(xiàn)協(xié)作,但是類共享機制對于動態(tài)安裝和卸載的模塊來說是不一致的,而服務(wù)注冊表為Bundles之間共享對象提供了一致的模型。生命周期管理用于動態(tài)管理Bundle的生命周期,可以動態(tài)安裝、啟動、停止、更新和卸載這些Bundle,Bundle依賴于模塊層的類載入,但是添加了運行管理的API。

生命周期管理層引入了應(yīng)用程序通常不具有的動態(tài)性,用有擴展的依賴機制來保證環(huán)境的正確運行。服務(wù)層定義了一個動態(tài)的協(xié)作模型,服務(wù)模型定義在Bundle模塊的基礎(chǔ)上,Bundle可以動態(tài)地發(fā)布、查找服務(wù),并且當(dāng)該服務(wù)的狀態(tài)(生命周期)改變時,能夠發(fā)出通知,這樣,所有對該服務(wù)關(guān)心的bundle就可以通過注冊監(jiān)聽器的方式接收消息,作出后續(xù)的處理。

一個Bundle其實就是一個jar文件,這個jar文件和普通的

jar文件唯一不同的地方就是Metainf目錄下的MANIFEST.MF文件的內(nèi)容,關(guān)于Bundle的所有信息都在MANIFEST.MF中進(jìn)行描述,可以稱它為Bundle的元數(shù)據(jù),這些信息中包括Bundle的名稱、描述、開發(fā)商、Classpath、需要導(dǎo)入的包以及輸出的包等。

一個OSGI框架應(yīng)用的典型就是Eclipse,Eclipse在3.

0以前的版本采用的是自己設(shè)計的一套插件體系結(jié)構(gòu),Eclipse的插件體系結(jié)構(gòu)在整個業(yè)界都是非常知名的,也是被認(rèn)為非常成功的一種設(shè)計,但Eclipse在3.0版本時卻做了一個重大決策,就是推翻它自己以前的插件體系結(jié)構(gòu),采用

OSGI作為其插件體系結(jié)構(gòu)。ApacheKaraf項目也是采用OSGI框架的一個輕量級容器的實例,OpenDaylight通過該模塊可以熱部署各種OpenDaylight組件。

2)Maven工具

Maven是軟件構(gòu)建工具,能夠幫助我們自動構(gòu)建軟件的生成、打包、部署、測試、清理以及生成報告等過程。

3)Infinispan集群

Infinispan用于實現(xiàn)OpenDaylight控制器集群,是個開源的數(shù)據(jù)網(wǎng)格平臺,它用公開的一個簡單的數(shù)據(jù)結(jié)構(gòu)(一個Cache)來存儲對象。雖然可以在本地模式下運行Infinispan,但其真正的價值在于分布式模式,在這種模式下,Infinispan可以將集群緩存起來并公開大容量的堆內(nèi)存。

4)SAL

SAL為整個OpenDaylight項目框架提供基礎(chǔ)設(shè)施服務(wù),包括各種OpenDaylight開發(fā)需要用到的基礎(chǔ)功能,它類似于Linux內(nèi)核。SAL將服務(wù)抽象使得上層和下層之間的調(diào)用相互隔離,SAL又可以分為API驅(qū)動的服務(wù)層(API-DrivenSAL,ADSAL)和模型驅(qū)動的服務(wù)層(Model-

DrivenSAL,MDSAL)兩種類型,MDSAL與ADSAL并沒有太多的差別,都是由一些南向/北向的插件(SB/NBPlugin)以及中間的抽象層組成。抽象層主要完成求的路由過程,也

就是將來自北向插件的請求發(fā)送給合適的南向插件,由南向插件執(zhí)行相應(yīng)的請求。通過ADSAL和MDSAL給獨立的網(wǎng)絡(luò)應(yīng)用提供了完善的二次開發(fā)接口。

在ADSAL中并沒有使用Yang對相關(guān)請求與通知功能進(jìn)行建模,而是直接靜態(tài)地使用了JavaAPIs進(jìn)行路由與適配。在MDSAL方式中,首先使用Yang對南向插件需要實現(xiàn)的功能進(jìn)行建模,再使用Yang工具與Maven生成相關(guān)的JavaAPIs,通過對模型的查詢來動態(tài)地進(jìn)行路由與適配。

5)Netty框架

Netty是一個高性能、異步事件驅(qū)動的JavaNIO(

NewI/O)框架,它提供了對TCP、UDP和文件傳輸?shù)闹С?。作為一個異步NIO框架,Netty的所有IO操作都是異步非阻塞的,通過FutureListener機制,用戶可以方便地獲取或者通過通知機制獲得IO操作的結(jié)果。作為當(dāng)前最流行的NIO框架,Netty在互聯(lián)網(wǎng)領(lǐng)域、大數(shù)據(jù)分布式計算領(lǐng)域、游戲行業(yè)、通信行業(yè)等獲得了廣泛的應(yīng)用。OpenDaylight南向使用Netty來管理底層的并發(fā)IO,并建立與SDN交換機之間的

TCP連接。

6)REST調(diào)用接口

REST調(diào)用接口允許上層網(wǎng)絡(luò)應(yīng)用程序與控制器駐留在不同的物理機器上,這樣做可以有效地提高上層應(yīng)用程序和控制器各自的性能,同時避免上層網(wǎng)絡(luò)應(yīng)用程序由于自身的低效率或故障而影響控制器的運行。例如,上層網(wǎng)絡(luò)應(yīng)用程序在短時間內(nèi)占用大量的CPU運算時間或大量的內(nèi)存。

3.OpenDaylight應(yīng)用開發(fā)

OpenDaylight的結(jié)構(gòu)層次從下到上依次劃分為數(shù)據(jù)平面(包括物理交換設(shè)備與虛擬交換設(shè)備等)、南向接口與協(xié)議插件、控制平面(包括核心控制部分與相關(guān)服務(wù))、上層網(wǎng)絡(luò)應(yīng)用與服務(wù)。OpenDaylight的應(yīng)用開發(fā)主要有兩種模式,如圖2－8所示。圖2－8OpenDaylight應(yīng)用開發(fā)方式

(1)外部應(yīng)用(方法一):應(yīng)用通過OpenDaylight提供的RESTful接口使用OpenDaylight提供的全部功能;

(2)內(nèi)部應(yīng)用(方法二):應(yīng)用內(nèi)嵌于OpenDaylight中,同時向外部提供RESTful接口以供外部程序調(diào)用,內(nèi)部應(yīng)用作為OpenDaylight的一個組件進(jìn)行開發(fā)。

外部應(yīng)用模式的開發(fā)更適合于非網(wǎng)絡(luò)功能的應(yīng)用程序,例如,開發(fā)一個防御DDOS的網(wǎng)絡(luò)應(yīng)用程序,程序的主要功能是根據(jù)接收的網(wǎng)絡(luò)數(shù)據(jù)包,應(yīng)用多種形式的模型綜合分析網(wǎng)絡(luò)數(shù)據(jù)包的攻擊特征,從而調(diào)用RESTAPI下發(fā)流表對攻擊源數(shù)據(jù)包進(jìn)行“清洗”。這種需要大量計算的應(yīng)用程序更適合部署在高性能的獨立服務(wù)器上,以確保計算資源(CPU、內(nèi)存等)的充足供應(yīng)。當(dāng)業(yè)務(wù)邏輯復(fù)雜時,完全使用REST的方式可能會導(dǎo)致調(diào)用REST接口過多而影響性能。內(nèi)部應(yīng)用則更適合開發(fā)一些與網(wǎng)絡(luò)功能密切相關(guān)的特殊插件,通常OpenDaylight本身并不具備這些插件的功能,需要更深層次的重新開發(fā),同時該組件也需要對外提供RESTAPI接口。

直接調(diào)用OpenDaylightRESTAPIs開發(fā)上層網(wǎng)絡(luò)應(yīng)用程序,可以使開發(fā)者屏蔽掉底層復(fù)雜的功能實現(xiàn),而專注于功能的創(chuàng)新與開發(fā)。但是直接使用API進(jìn)行開發(fā)仍舊不夠簡便,因為需要進(jìn)行大量的GET/POST/DELETE/UPDATE等操作,因此可以在API的基礎(chǔ)上,將類似的功能用開發(fā)語言進(jìn)行封裝,形成新的軟件開發(fā)包(SDK),從而提升開發(fā)效率,本書第七章將給出基于OpenDaylightRESTAPI開發(fā)應(yīng)用的實例。