夏仕俊

（國網(wǎng)上海市電力公司 信息通信公司，上海 200122）

1 設(shè)計方案背景

網(wǎng)絡(luò)設(shè)計的簡約化和簡單化，促使了網(wǎng)絡(luò)的飛速增長和不斷創(chuàng)新，但網(wǎng)絡(luò)本身仍然相當(dāng)難以改變，并且極其脆弱和難以管理。這些問題的根源是在整個網(wǎng)絡(luò)中的所有交換機和路由器上運行的控制層過于復(fù)雜［1］。為了緩解這個問題，2008年美國斯坦福大學(xué)提出了一種新型網(wǎng)絡(luò)架構(gòu)SDN（Software Defined Network），它的核心技術(shù)是OpenFlow技術(shù)，它將網(wǎng)絡(luò)設(shè)備控制面與數(shù)據(jù)面分離，靈活實現(xiàn)對網(wǎng)絡(luò)流量的控制，是SDN中一種最具革命性的數(shù)據(jù)平面抽象技術(shù)。

OpenFlow提出了解耦控制（決策制定）和數(shù)據(jù)（數(shù)據(jù)包轉(zhuǎn)發(fā)）層，將控制功能委托給1個邏輯上集中的控制器［2］。這種分離，簡化了對網(wǎng)絡(luò)控制邏輯的修改，使數(shù)據(jù)層和控制層獨立地發(fā)展和伸縮，并且顯著地降低了數(shù)據(jù)層元素的開銷［3］。因而，OpenFlow成功地吸引了大量廠商［4］。

為簡單起見，OpenFlow最初的設(shè)計和實施只使用單個控制器。正如文獻(xiàn)［5］所說，基于OpenFlow的單個控制器，給各個交換機安裝包處理規(guī)則集，規(guī)則集實現(xiàn)客戶端網(wǎng)絡(luò)流的引導(dǎo)以達(dá)到服務(wù)的負(fù)載均衡。然而，隨著部署Open-Flow的生產(chǎn)網(wǎng)絡(luò)數(shù)量和規(guī)模的增大，整個網(wǎng)絡(luò)依賴單一的控制器變得不可行了。首先，隨著交換機數(shù)量的增長，與集中控制器之間的控制流量增加；其次，如果網(wǎng)絡(luò)直徑較大，無論在哪里放置控制器，都會有交換機遇到網(wǎng)絡(luò)流建立時的長延遲；最后，由于系統(tǒng)受限于控制器的處理能力，隨著網(wǎng)絡(luò)規(guī)模的增加，網(wǎng)絡(luò)流的需求增加，導(dǎo)致網(wǎng)絡(luò)流建立的時間顯著增加。

提出1種新的設(shè)計理念和實現(xiàn)方法，它為OpenFlow提供分布式的基于事件的控制層，使得網(wǎng)絡(luò)運營商在管理網(wǎng)絡(luò)里部署任意數(shù)量的控制器；在提高可擴展性的同時，保持網(wǎng)絡(luò)控制邏輯集中，即所有控制器共享統(tǒng)一的網(wǎng)絡(luò)級視圖，響應(yīng)請求本地化，而不需要主動聯(lián)系任何遠(yuǎn)程節(jié)點，從而減少網(wǎng)絡(luò)流建立的時間。此外，不需要對Open-Flow的標(biāo)準(zhǔn)做任何改動，只需要對現(xiàn)有的控制應(yīng)用做少量修改［4］。新方案保證無循環(huán)轉(zhuǎn)發(fā)，并免疫網(wǎng)絡(luò)分割和組件故障。此外，它使得Open-Flow可以增加管理區(qū)域，以便于其能夠與其他獨立管理的OpenFlow區(qū)域互聯(lián)。

2 目前分布式控制設(shè)計的問題

目前，分布式控制的一種典型設(shè)計是FlowVisor［6］。FlowVisor通過將網(wǎng)絡(luò)資源切片并委派每個不同切片的控制，到1個不同的控制器，以使多個控制器在1個OpenFlow的網(wǎng)絡(luò)中并存；另一種典型設(shè)計是分布式存儲控制器的狀態(tài)，并啟用獨立控制器的本地緩存。即使決策可以通過只詢問本地緩存來實現(xiàn)，也難免有些流量需要從遠(yuǎn)程控制器進(jìn)行狀態(tài)檢索，以致占用一些控制層的服務(wù)時間。此外，這種設(shè)計需要修改應(yīng)用程序來將狀態(tài)存儲在分布式數(shù)據(jù)存儲區(qū)。

將方案作為NOx（一種OpenFlow控制器平臺）的1個應(yīng)用來實現(xiàn)［7］。這個應(yīng)用負(fù)責(zé)同步各控制器的網(wǎng)絡(luò)級視圖（通過傳播特定的本地控制器事件），將指向間接控制交換機的OpenFlow命令重定向到該交換機相應(yīng)的控制器，將回應(yīng)從交換機重定向回發(fā)起請求的控制器，并使用發(fā)布／訂閱消息模式來進(jìn)行控制器間通信。

3 設(shè)計與實現(xiàn)

采用OpenFlow分布式部署方案的網(wǎng)絡(luò)，由作為轉(zhuǎn)發(fā)單元的OpenFlow交換機、NOx控制器和作為控制器間通信服務(wù)的事件傳播系統(tǒng)組成。所有控制器都按照標(biāo)準(zhǔn)的網(wǎng)絡(luò)級視圖，運行相同的控制器軟件和應(yīng)用程序集，而每個交換機連接到其接近的最佳控制器。一旦控制器出現(xiàn)故障，受影響的交換機重新配置連接到1個附近的活動控制器。每個控制器直接管理連接到它的交換機，通過與其他控制器通信進(jìn)行調(diào)整或查詢，間接地管理其余交換機。采用OpenFlow分布式部署方案的系統(tǒng)結(jié)構(gòu)框圖如圖1所示。

圖1 系統(tǒng)結(jié)構(gòu)框圖

為了實現(xiàn)控制器之間網(wǎng)絡(luò)級視圖的一致性，在每個控制器中的控制器應(yīng)用程序?qū)嵗?，通過1個發(fā)布／訂閱系統(tǒng)發(fā)布會改變系統(tǒng)狀態(tài)的事件，其他控制器重播所有已發(fā)布的事件來重建狀態(tài)。采用這種設(shè)計理念是基于以下4個方面：一是控制器網(wǎng)絡(luò)級視圖的任何改變都源于1個網(wǎng)絡(luò)事件，單個事件可能會影響多個應(yīng)用程序的狀態(tài)，因此隨著應(yīng)用數(shù)量增長的直接狀態(tài)同步所帶來的流量增長需要控制；二是只有非常小部分網(wǎng)絡(luò)事件會更改網(wǎng)絡(luò)級視圖（數(shù)千臺主機的網(wǎng)絡(luò)上，每秒大概發(fā)生幾十次事件），多數(shù)網(wǎng)絡(luò)事件（如事件數(shù)據(jù)包）只請求服務(wù)（如路由服務(wù)）；三是除非針對同1個交換機，事件的時間順序不影響網(wǎng)絡(luò)級視圖；四是應(yīng)用程序只需最低限度地修改，以動態(tài)地識別影響它們狀態(tài)的事件。

3.1 事件傳播機制

為了傳播控制器事件給其他控制器，方案使用發(fā)布／訂閱消息模式。發(fā)布／訂閱系統(tǒng)必須提供發(fā)布事件的持久性存儲（提供有保證的事件交付），保持同1個控制器發(fā)布事件的順序，并能免疫網(wǎng)絡(luò)分割（比如，每個分割必須獨立繼續(xù)運行并在重新連接時實現(xiàn)同步）；應(yīng)盡量減少傳播事件所需的跨站點的流量，即1個站點的控制器應(yīng)該從附近的控制器得到大多數(shù)其他站點的更新，以避免跨區(qū)域鏈接的擁塞；應(yīng)加強訪問控制，以確保訪問擁有授權(quán)。

使用WheelFS可實現(xiàn)1個滿足上述要求的分布式發(fā)布／訂閱系統(tǒng)［8］。當(dāng)然，也可使用任何滿足上述要求的其他發(fā)布／訂閱系統(tǒng)。WheelFS分布式文件系統(tǒng)旨在為分布式應(yīng)用提供靈活的廣域存儲。它帶來了應(yīng)用程序的可控性、一致性、耐久性以及根據(jù)語義線索的要求放置數(shù)據(jù)的能力。語義線索可以直接嵌入在路徑名中，以改變文件系統(tǒng)的行為。在WheelFS中，目錄表示信道以及文件表示信息。為檢測消息的到達(dá)，控制器應(yīng)用程序會定期輪詢目錄，以檢測改變。

每個控制器訂閱網(wǎng)絡(luò)中的數(shù)據(jù)信道、控制信道以及自身信道，并被授予權(quán)限，以發(fā)布和訂閱信息?？刂破鲗⒈镜鼐W(wǎng)絡(luò)和應(yīng)用事件發(fā)布到數(shù)據(jù)信道中。針對1個特定的控制器事件和OpenFlow命令在相應(yīng)的控制器的信道內(nèi)發(fā)布。此外，每個控制器必須在控制信道周期性地通告自己，以便實現(xiàn)控制器發(fā)現(xiàn)故障和檢測故障。這些信道的訪問控制是通過發(fā)布／訂閱系統(tǒng)執(zhí)行的。

2018年全國高考生物試題大多提供特定情境，學(xué)生通過運用科學(xué)思維，結(jié)合從題干中獲取的信息和所學(xué)知識解決問題，進(jìn)一步實現(xiàn)對學(xué)生生物核心素養(yǎng)的評價考查。

WheelFS的使用使得本部署方案能夠免疫網(wǎng)絡(luò)分割。一旦網(wǎng)絡(luò)被分割，每個分割上WheelFS繼續(xù)獨立運作。每個分割上的控制器不再接收其他分割控制器的信息，認(rèn)為它們都失聯(lián)了。分割重新連接后，兩個分割中的WheelFS節(jié)點被重新同步?？刂破鲿玫椒指顢嚅_時其他分割中所有發(fā)生的事件，經(jīng)過重播后使得所有控制器的網(wǎng)絡(luò)級視圖重新一致。

3.2 控制器應(yīng)用的主要功能

本方案基于NOx平臺實現(xiàn)，作為一種NOx應(yīng)用運行，用以確保所有的控制器都具有一致的網(wǎng)絡(luò)級視圖。每個控制器運行1個應(yīng)用程序?qū)嵗瑢崿F(xiàn)時需要對核心控制器代碼進(jìn)行小的改動，主要是為客戶提供合適的鉤子來截獲命令和序列化事件。主要功能和過程如下：

1）初始化 在NOx啟動時，應(yīng)用程序啟動WheelFS客戶端和存儲服務(wù)，訂閱該網(wǎng)絡(luò)的數(shù)據(jù)信道和控制信道，并開始在控制信道周期性地通告本身。該通告間隔必須比網(wǎng)絡(luò)控制器間最高的回合時間大。通告消息包含有關(guān)該控制器的信息包括直接控制交換機的標(biāo)識符信息。

2）發(fā)布事件 應(yīng)用捕獲所有NOx內(nèi)置事件以及程序在應(yīng)用中注冊的事件。然后，對本地產(chǎn)生并影響控制器狀態(tài)的事件進(jìn)行序列化和發(fā)布。為此，應(yīng)用程序必須標(biāo)記影響其狀態(tài)的事件。此外，應(yīng)用程序應(yīng)該找出它們發(fā)起的非內(nèi)置事件的父事件。這樣一來，可以跟蹤每1個高級別活動到底層較低級別的事件并傳播它。使用這種方法，可以確保傳播的事件的數(shù)量，僅限于局部控制器產(chǎn)生的OpenFlow的消息事件的數(shù)量。發(fā)布的消息的名稱包含源控制器標(biāo)識符和發(fā)布者的本地事件標(biāo)識符，有效地將控制器之間的消息命名空間劃分，避免了任何寫沖突的可能性。此外，消息的緩存副本（文件）在系統(tǒng)中永遠(yuǎn)保持最新。

3）事件回放 應(yīng)用重播所有發(fā)布的事件，這是因為源控制器在應(yīng)用的幫助下有選擇地進(jìn)行過濾，只發(fā)布其他控制器重建應(yīng)用程序狀態(tài)所需的活動。當(dāng)網(wǎng)絡(luò)上的數(shù)據(jù)信道或控制器本身的信道收到新消息時，應(yīng)用反序列這一消息并觸發(fā)它。

4）重定向針對非本地交換機的命令 控制器只能對直接連接到它的交換機進(jìn)行編程。為了編程非直接控制的交換機，當(dāng)OpenFlow的消息即將被發(fā)送到這樣的交換機時，應(yīng)用程序?qū)r截并發(fā)布命令到網(wǎng)絡(luò)的控制信道。已發(fā)布消息的名稱包含源控制器的標(biāo)識符、目標(biāo)交換機標(biāo)識符以及本地命令標(biāo)識符。

5）代理OpenFlow消息和答復(fù) 獲取針對其控制下交換機的命令消息，并將其發(fā)送到目標(biāo)交換機。為了將答復(fù)返回源控制器，應(yīng)用程序保持消息的事務(wù)標(biāo)識符（XID）和源控制器標(biāo)識符之間的映射。應(yīng)用程序檢查由控制器本地產(chǎn)生OpenFlow的消息事件的XID。如果1個事件的XID在XID控制器映射中被發(fā)現(xiàn)，則該事件停止進(jìn)一步處理，并發(fā)布到網(wǎng)絡(luò)上的數(shù)據(jù)信道。該消息的名稱中包含兩個控制器的標(biāo)識符。初始的源控制器獲取回執(zhí)并重放事件。

4 控制器應(yīng)用的要求

對于大多數(shù)控制器應(yīng)用，只需動態(tài)標(biāo)記影響其狀態(tài)的事件。他們中的一些基于某種要求則必須進(jìn)行修改，以確保在時序事件重排和控制器視圖瞬時沖突時的正確操作，并保證可擴展性，以便獨立管理的OpenFlow網(wǎng)絡(luò)實現(xiàn)互連。

1）事件重排 除了那些針對同1個實體的控制應(yīng)用外，應(yīng)用的正確操作不能依賴于事件的時間順序，因為不同的控制器以不同的順序感知事件。此外，對網(wǎng)絡(luò)分割免疫，意味著控制應(yīng)用要在不犧牲正確性的前提下，容忍無序事件傳遞（甚至滯后幾個小時）。這是因為每個分割在重新連接時才被告知其他分割的狀態(tài)。

2）正確性 控制器之間的瞬態(tài)不一致可能導(dǎo)致有沖突的決策。因此，為了確保在所有狀況下正確操作，控制應(yīng)用程序必須將請求轉(zhuǎn)發(fā)給權(quán)威的控制器。給定的權(quán)威控制器是該數(shù)據(jù)流源交換機的管理控制器。以交換／路由應(yīng)用程序為例：為了確保無循環(huán)轉(zhuǎn)發(fā)，流路徑必須由管理數(shù)據(jù)流的源交換機的控制器建立。其他控制器如果收到1個流發(fā)起事件，必須將請求重定向到該流的權(quán)威控制器。

3）測量應(yīng)用 主動查詢交換機的應(yīng)用表現(xiàn)，因為查詢數(shù)量隨著控制器的數(shù)量線性增長。這樣的應(yīng)用程序必須改為分布式的方式，對控制器集合進(jìn)行劃分，將查詢分配到各個劃分并在各劃分間交換結(jié)果（封裝在自定義事件里）。

4）網(wǎng)絡(luò)互聯(lián) 連接兩個獨立管理的基于本方案的OpenFlow網(wǎng)絡(luò)（區(qū)），控制器應(yīng)用程序需要進(jìn)行修改，以進(jìn)行區(qū)域感知，偵聽來自方案的區(qū)域發(fā)現(xiàn)事件，實施用策略語言聲明的區(qū)域策略，并與鄰近區(qū)域通過提供發(fā)布／訂閱服務(wù)的安全通道交流更新。應(yīng)用程序應(yīng)該把更新封裝在自定義事件里，并傳播到鄰近地區(qū)。

5 分析評估

進(jìn)行評估，要求測試時保證控制器之間不一致性，在有限范圍內(nèi)可以支持網(wǎng)絡(luò)動態(tài)的最高水平。在實驗中，使用10臺服務(wù)器，每臺服務(wù)器配備了千兆網(wǎng)卡，既是 WheelFS客戶機，又是存儲節(jié)點。每個NOx實例每秒處理大約30KB的流安裝。通過應(yīng)用發(fā)布的事件，只影響控制器的狀態(tài)，不引發(fā)與控制器的任何交互。因此，使用本方案，網(wǎng)絡(luò)運營商可以很容易地添加更多的控制器來處理流事件，同時保持流配置等待時間最小。

各個控制器的操作由于不依賴于其它的控制器，即使在重同步負(fù)載的狀況下仍能繼續(xù)操作。在給定的1個控制器之間有界不一致窗口下，為找到本方案可以處理的事件數(shù)量，以獨立的WheelFS為基準(zhǔn)，找出3KB大小可以讀寫文件的數(shù)量（樣本是XML格式的序列化數(shù)據(jù)路徑聯(lián)通事件）。為此，使用實現(xiàn)的應(yīng)用程序代碼來衡量需要讀取和反序列化1000個這樣文件的時間（擁有最終一致性），以及序列化和寫（寫在本地，不等待與副本同步）同樣文件的時間。每個測試做了10次，取平均值的結(jié)果。本方案每秒可以讀取和反序列化987個，或者序列化并寫入233個這樣的事件。在這種狀況下，限制因素是讀取數(shù)，因為多個控制器可以同時進(jìn)行發(fā)布（寫）。

基于以上分析，假設(shè)有足夠的控制帶寬，在網(wǎng)絡(luò)變化觸發(fā)事件數(shù)量低于大約1000個／s時，本方案可以保證控制器間的不一致性是在可控范圍內(nèi)?？梢酝ㄟ^修改WheelFS或設(shè)計替代的發(fā)布／訂閱系統(tǒng)，以提高實驗方案的性能。

6 結(jié)語

介紹了1種基于OpenFlow的分布式控制應(yīng)用設(shè)計方案和實現(xiàn)，使OpenFlow可以部署在數(shù)據(jù)中心和企業(yè)網(wǎng)絡(luò)一類的任務(wù)關(guān)鍵型網(wǎng)絡(luò)中。使網(wǎng)絡(luò)運營商可以根據(jù)自己的需求部署任何數(shù)量的控制器來調(diào)整控制層的性能。此外，它使網(wǎng)絡(luò)控制邏輯集中化，每個控制器的決策本地化，以減少控制層的響應(yīng)時間。在NOx基礎(chǔ)上實現(xiàn)的本方案應(yīng)用，通過傳播影響控制器狀態(tài)的事件來同步控制器的網(wǎng)絡(luò)級視圖。

選擇通過重播事件建立狀態(tài)，盡量減少同步控制器狀態(tài)所需的控制流量，避免了在應(yīng)用程序的狀態(tài)中發(fā)生沖突的可能性，并最大限度地減少了應(yīng)用程序進(jìn)行修改的負(fù)擔(dān)。本方案對網(wǎng)絡(luò)分割和組件故障免疫，最大限度地減少了跨區(qū)域控制流量，并允許獨立管理的OpenFlow網(wǎng)絡(luò)互連。

［1］ Greenberg A，Hjalmtysson G，Maltz D A，et al.Clean slate 4Dapproach to network control and management.SIGCOMM Computer Communication Review 35，5（2005），54.

［2］ McKeown N，Anderson T，Balakrishnan H，et al.Open-Flow：enabling innovation in campus networks.SIGCOMM Computer Communication Review 38，2 （2008），69-74.

［3］ Naous J，Erickson D，Covington G A，et al.Implementing an OpenFlow switch on the NetFPGA platform.In ANCS（2008），M.A.Franklin，D.K.Panda，and？D.Stiliadis，Eds.，ACM，1-9.

［4］ OpenFlow Consortium.http：／／openflowswitch.org／.

［5］ Wang R，Butnariu D，Rexford J.OpenFlow-based server load balancing gone wild.Proceedings of the 11th USENIX conference on Hot topics in management of internet，cloud，and enterprise networks and services［J］.USENIX Association，2011：12-12.

［6］ Sherwood R，Gibb G，et al.FlowVisor：A Network Virtu-alization Layer.Tech.Rep.OPENFLOW-TR-2009-01，OpenFlow Consortium，October 2009.

［7］ Gude N，Koponen T，Pettit J，et al.NOx：towards an operating system for networks［J］.SIGCOMM Computer Communication Review2008，38（3）：105-110.

［8］ Stribling J，Sovran Y，Zhang I，et al.Flexible，wide-area storage for distributed systems with WheelFS.In Proceed-ings of the 6th USENIX Symposium on Networked Systems Design and Implementation（NSDI’09）（Boston，MA，A-pril 2009）.