麻豆精品无码国产在线播放,国产亚洲精品成人AA片新蒲金,国模无码大尺度一区二区三区,神马免费午夜福利剧场

一種軟件定義網絡中的交換機遷移方法與流程

文檔序號:11410703閱讀:536來源:國知局
一種軟件定義網絡中的交換機遷移方法與流程

本發明屬于軟件定義網絡技術領域,特別是針對軟件定義網絡中的交換機遷移帶來的存活性和安全性等問題,提出一種交換機遷移方法。



背景技術:

隨著云計算、物聯網、大數據等應用的數據時代興起,傳統網絡的發展難以應對靈活的數據資源請求。相應的網絡架構的更新方案相繼出現,首先提出的可編程網絡的研究,為軟件定義網絡(softwaredefinednetworking,sdn)的發展提供了理論基礎;主動網絡允許用戶編寫簡單的程序,但是安全性面臨了極大的威脅,且適用性比較差;4d架構是將決策平面從數據平面進行分離,使得控制邏輯集中化;面向企業安全管理的sane架構,也是以4d架構為設計原則,將控制決策由中央服務器控制;ethane是在sane上進行的功能擴展,初步建立軟件實現轉發決策,硬件緩存決策只需進行報文轉發;2008年研究人員基于ethane的大部分功能的基礎上,提出了openflow技術,更加明確數控分離的基本概念;后基于openflow給網絡帶來可編程的特性,進而使得sdn概念應運而生。

軟件定義網絡是一種在物理上分散、邏輯上集中的基于軟件的新型控制網絡架構,是網絡虛擬化的一種實現方式。該架構的核心技術是通過openflow技術將網絡設備控制平面與數據平面分離開來,進而實現了數據流量的靈活控制,使網絡設備使用更加便捷、智能。與傳統網絡不同點在于,它通過軟件編程形式自定義的設置網絡設備,使得原來分布式的控制平面邏輯上集中。而隨著業務需求及網絡規模的增大,單控制器節點就很容易成為整個網絡性能的瓶頸,因此可擴展性問題是亟待解決的問題。雖然sdn是建立一個邏輯上集中、物理上分散的控制平臺,能有利于系統的可擴展性和穩定性。但是控制器本質上還是分布式和異步操作的,而邏輯的安裝不具備原子性,存在配置有先后順序或者執行有先后順序,造成網絡傳輸一致性問題。

在近期國內外研究探索如何建立必要的組件以實現一個分布式sdn控制器,但存在的問題是交換機和控制器之間的映射是靜態配置,難以使控制平臺適應傳輸負載的變化。在實際網絡應用中,由于數據請求的時間性和空間性都是隨機的,交換機的傳輸負載也時刻在發生變化,有可能造成控制平面上控制器負載不均衡,使得相應的控制器會超負載,而其他控制器沒有得到充分利用。例如一天中網絡傳輸狀況不是恒定的,有高峰期和低谷期;根據應用程序產生的數據流,存在空間傳輸狀況的變化。或者由于控制器發生故障,因此需要實現交換機的遷移來保證數據傳送的安全性和可靠性。交換機遷移是將某個交換機從鏈接它的控制器上遷移到新的控制器的過程。同時也能為以后實現控制器池中的控制器數量的動態增減提供遷移機制。

openflow規范1.3給一個控制器定義了三種操作模式:master、slave和equal。默認情況下,slave控制器對交換機的權限為只讀操作,不能夠接收來自交換機的異步消息(由交換機發起,用來更新控制器中網絡事件或交換機狀態的變化的消息,比如:packet-in、packet-removed等)。然而,master和equal模式下的控制器能夠修改交換機端口狀態、接收交換機發送來的異步消息。每一個交換機最多只有一個master控制器,但可以有多個equal控制器。交換機遷移過程需要它所屬的slave控制器中的一個成為新的master控制器,而先前的master控制器應該角色逆轉變成slave控制器或失效,控制器通過發送role-change消息命令給交換機來改變自己的角色。

已有的交換機遷移機制不具備提供控制器存活性和安全性保障的能力,沒有考慮在遷移過程中如何處理新到達的流表項,沒有考慮在master/equal模式下多個控制器會對交換機進行重復的寫操作,造成數據不一致性等問題,且遷移的機制流程復雜,控制報文較多,控制器的角色轉換復雜。

論文“towardsanelasticdistributedsdncontroller”,在文中提到了交換機遷移機制。首先需要了解的是交換機遷移機制中控制器需要保持存活性和安全性。存活性是指一個交換機所屬的控制器中,至少有一個控制器是活躍的,能完整處理該交換機中所緩存下的消息;安全性是指能保證當前控制器和遷移目標控制器恰好只有一個控制器來主導交換機,控制器不會同時對交換機中的流表項進行重復操作,能避免造成數據存儲的不一致問題。從該論文提出的機制來看,該機制未能將交換機緩存中先后到來的消息區分開來,且目標控制器角色轉換較為復雜,整個遷移過程算法需要6個往返時間(包括inter-controller節點通信)才完成遷移,所花費的時間相對較長。



技術實現要素:

本發明的目的在于克服現有交換機遷移機制的不足,提供一種軟件定義網絡中的交換機遷移方法。

為了達到上述目的,本發明采用了以下技術方案:

交換機遷移預處理設計:

由于交換機的遷移過程中不是將交換機處于離線狀態去遷移的,在這期間仍然會接收數據包存儲到緩存中。交換機遷移過程中消息的到達有先后順序,需要區分哪些到達的緩存消息需要當前控制器處理,哪些需要目標控制器處理,以確保數據包恰好只由一個控制器完整的處理完成。因此,該方法通過發送flow-mod消息在交換機流表中添加一個作為閥門的空流表項,從而實現遷移前預處理,通過當前控制器設置“閥門”使得交換機處于掛起狀態,此時交換機里的緩存消息都交給當前所屬的控制器處理,在此之后到來的消息都只緩存在交換機里面,等當前控制器處理完它應該處理的消息后,然后再刪除前面所設置的“閥門”,結束遷移的前期準備工作。隨后通知目標控制器進行角色轉換,就完成最終交換機遷移的過程。

預處理中“閥門”技術設計(定義當前控制器為控制器a,目標控制器為控制器b,控制器a為交換機x的master控制器):

一張流表存儲許多流表項,每一個流表項表征一個“流”及其相應動作表。控制器的請求或交換機流超時機制,都能使在流表中的流表項刪除。上述“閥門”是通過控制器a發送flow-modaddcommand消息向交換機x發送添加流表項請求,在交換機x流表中添加空流表項所得到。“閥門”的添加,即空流表項(它不包含任何行動指令)的添加,目的是為了讓控制器a在刪除流表時,能夠確保交換機已經處理完屬于控制器a的應該完成的消息,以便及時開展遷移處理。在openflow協議中,并非每一個通過安全通道進行交換的消息都需要響應,因此,使用安全通道發送消息的一方有時并不知道接收方處理消息的程度,為了解決這類似的問題,在協議中有一個barrier消息的機制,barrier消息的目的是掌握消息的處理程度。接收barrier請求消息的一方在接收消息后,結束對在此之前接收到所有消息的處理,通過返回barrier響應消息,通知消息發送方消息處理的完成度。在openflow1.1以上版本中已經明確表明,只要未通過barrier消息發出明確指示,交換機從不考慮從控制器接收到的消息順序,可以按照任意的順序進行處理。此時,預處理機制中控制器a發送barrierrequestmessagefora消息給交換機x,能使交換機的消息處理順序按照接收到的順序處理,處理完在接收該消息之前的交換機緩存流后,交換機x能及時給控制器a回復,告訴控制器a此時可以刪除“閥門”。

軟件定義網絡中交換機遷移機制:

在請求遷移后,軟件定義網絡中的交換機遷移方法設計為二步法:交換機遷移預處理過程(步驟3-8);交換機遷移過程(步驟9-11),具體遷移過程如下:

請求遷移:

1)控制器a發送startmigration消息給控制器b,表示要開始遷移;

2)控制器b返回readyformigration消息給控制器a;

交換機遷移預處理:

3)控制器a發送barrierrequestmessagefora消息給交換機x,詢問交換機x處理屬于控制器a的消息的完成程度,使交換機x按從控制器a接收的順序對消息進行處理,開始交換機遷移的預處理;

4)控制器a發送flow-modadd消息給交換機x,增加一條空流表項在交換機x的流表中;

5)控制器a發送barrierrequest消息給交換機x,交換機x處理完flow-mod消息后回復barrierreply消息,可以確保控制器a將空流表項寫入交換機x的流表中;

6)確定控制器a處理完交換機緩存中的消息之后,交換機x返回barrierreplytoa消息給控制器a;

7)控制器a發送flow-moddelete消息給交換機x,刪除之前交換機x流表中添加的空流表項;

8)對交換機x流表項的刪除觸發交換機x發送flow-removed消息給控制器a,表示已經完成遷移前的預處理;

交換機遷移:

9)控制器a發送endmigration消息給控制器b,表示準備好遷移;

10)控制器b發送role-request消息給交換機x,請求成為新的master;

11)交換機x設定控制器b為新的master(即新的當前控制器),控制器a相應地成為slave。

本發明的有益效果體現在:

本發明利用空流表項的添加作為時間劃分點,在該時間前能保證當前控制器完全主導交換機處理權,刪除空流表項后主導權能完全移交給目標控制器,不僅能夠滿足軟件定義網絡中交換機遷移機制所要求的存活性、安全性性能,還能夠減少網絡傳輸中的控制報文,簡化控制器的狀態轉化。

進一步的,控制器a通過發送barrier消息,例如barrierrequestmessagefora消息給交換機x,確保當前控制器a處理完交換機x緩存流表后可以得到交換機x的回復,告訴控制器a此時可以刪除空流表項,保證先后到達的緩存能夠分開進行處理,避免緩存消息重復被處理,或者一直將處理權交給控制器a,無法使交換機完整遷移出來。

附圖說明

圖1軟件定義網絡多控制部署架構圖;

圖2軟件定義網絡中的交換機遷移方法信令交互圖;

圖3交換機遷移過程中交換機的緩存示意圖;

圖4交換機遷移過程中交換機數據包隨時間變化示意圖。

具體實施方式

下面結合附圖和實施例對本發明做進一步地詳細描述。

本發明是一種軟件定義網絡中確保控制器存活性和安全性的交換機遷移方法。軟件定義網絡多控制器部署架構如圖1,可以從圖1中看出網絡被虛線圈出的兩個部分,左邊虛線圈是由控制器a管理的區域,右邊虛線圈是由控制器b管理的區域。此時的交換機x屬于控制器a管理的范圍,但因為負載的變化等因素,需要將交換機x遷移到控制器b管理的區域。本發明主要針對的就是該交換機的遷移機制。

上述交換機遷移方法的信令交互流程如圖2,能夠完成交換機x從當前控制器(控制器a)遷移到目標控制器(控制器b)下的過程。

下面分別介紹三個階段處理過程:

階段一101:請求遷移

結合圖1所示,控制器a通過向控制器b發送startmigration消息,請求遷移其管理下的交換機x,控制器b準備好遷移之后回復控制器areadyformigration消息,至此階段一結束。這一階段,控制器a是master,控制器b是slave,交換機x有新到來的數據包只能交給控制器a處理,保證了存活性以及安全性。相比其他遷移協議,本發明未讓控制器b成為equal模式控制器,減少網絡傳輸中不必要的控制報文,簡化控制器b的狀態轉化,縮短遷移時間。

階段二102:遷移前預處理

進入遷移預處理階段,此階段是本發明核心點所在。首先結合圖3和圖4,詳細闡述交換機緩存處理的過程,以更好的理解該階段方案設計的由來。

在空間軸上的交換機數據包緩存如圖3所示,虛線代表的是開始進行預處理,此時會通過flow-modadd消息在交換機流表中插入一個空流表項,該流表項不匹配任何到來的數據包,等到cache(a)所指的數據包處理完成后,需要及時刪除空流表項。圖3中cache(b)內虛線框表示的是插入空流表項后,交換機接收到的緩存數據包,此時交換機所緩存的數據包都是可以完全交付給目標控制器b進行處理,很好的將緩存數據包隔離開來處理。

時間軸上的交換機數據包緩存如圖4所示,在遷移準備過程中,即時間段t內,既要考慮交換機緩存中已有的數據包,同時還要考慮之后仍可能會到達交換機的數據包。這個時間段t表示的是空流表項添加至刪除所花的時間。該時間是交換機緩存中已有數據包的函數,即虛線框所示的緩存數據包處理完成花費的時間;而之后到達的數據包又是時間的函數,即因為在t時間段里面,控制器a處理完交換機中緩存的數據包,此時的交換機也會緩存一定的數目的數據包。因此在這一階段需要利用flow-mod設置“閥門”阻止之后可能會到達的數據包交給控制器a處理,同時還要將緩存中已有的數據包處理完畢。

結合圖1所示,控制器a發送flow-modaddcommand消息給交換機x,通過添加空流表項到流表中作為添加的“閥門”,使得到達的數據包在添加空流表項之后的流表中即使匹配不成功也不會再發送消息給控制器a,詢問該如何處理未知數據包。使用barrierrequest和barrierreply消息來確保空流表項成功寫入交換機流表,因為在接收到barrier消息后,openflow規范下的交換機按照從控制器接收的消息順序處理。交換機x回復barrierreplymessage消息給控制器a,表明空流表項寫入交換機x已經成功。此時交換機x已經掛起。

交換機x掛起后,便可以處理緩存中已有的數據包,由于之前控制器a發送barrierrequestmessagefora消息給交換機x,當控制器a處理完畢交換機緩存中的消息后,交換機x會發送barrierreplymessagefora消息給控制器a,保證了存活性。同時得到回復后,告訴控制器a此時可以刪除“閥門”,保證先后到達的數據包能夠分開進行處理,避免緩存數據包重復被處理,或者一直將處理權交給控制器a,無法使交換機完整遷移出來。

在確保控制器a已經處理完緩存中已有的數據包之后,控制器a發送flow-moddeletemessage消息給交換機x,刪除之前添加在流表中的空流表項,當交換機的流表項因為超時或者修改等原因被刪除掉,就會觸發交換機發送flow-removed消息給控制器a,控制器a發送endmigration消息給控制器b以結束遷移預處理階段。

階段二中,控制器a仍然是交換機x的唯一master,控制器b是slave,交換機x的消息只會發送給控制器a,也只有控制器a可以對交換機x進行管理,保證了安全性。

階段三103:交換機遷移(角色轉換)

在結束了遷移前預處理工作之后,控制器b向交換機x發送role-requestmessagetomaster消息,來請求成為交換機x的新master,交換機x回復控制器brole-replymessageformaster消息,同時設置控制器b為交換機x唯一的master,控制器a的角色轉換成為slave。

添加閥門之后達到交換機x的緩存數據包以及還會再到達的數據包都會交給新的master也就是控制器b進行處理,從而保證存活性以及安全性。

本發明具有以下優點:

相比于其他交換機遷移策略,本發明通過barrier請求消息的發送等,保障了控制器完整的執行flow-mod添加空流標項的信息,同時也保障了控制器的存活性和安全性。

“閥門”的加入,給交換機緩存插入一道分界線,能夠清晰的知道哪些緩存需要當前控制器處理,哪些需要送到目標控制器處理,使得信息處理有條不紊的進行,確保一條信息恰好只有一個控制器處理,保障了數據的一致性和安全性。

整個交換機遷移的過程中,與目標控制器交互信息比較少,在遷移前通知控制器做好遷移準備,遷移預處理結束,只需將目標控制器角色進行轉換,減少了網絡傳輸中的控制報文,為交換機減少負擔,也體現出遷移過程的簡潔。

當前第1頁1 2 
網友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點贊!
1
主站蜘蛛池模板: 喀喇| 太保市| 乌鲁木齐市| 陇西县| 德兴市| 灌阳县| 大安市| 长武县| 当阳市| 涡阳县| 元朗区| 沁源县| 木里| 图们市| 金塔县| 潜山县| 扎囊县| 临江市| 枝江市| 栾城县| 星子县| 临潭县| 石楼县| 安阳县| 石渠县| 彰化市| 枣强县| 邳州市| 平邑县| 罗定市| 陆良县| 崇信县| 棋牌| 梅河口市| 浑源县| 白城市| 台东市| 广昌县| 中牟县| 定西市| 田林县|