綜合業務網關容災切換的方法和裝置與流程

2023-06-01 14:23:12

本發明涉及移動網際網路技術領域，特別是涉及綜合業務網關容災切換的方法和綜合業務網關容災切換的裝置。

背景技術：

現有通信網絡中，關於綜合業務網關容災切換的技術包括：基於綜合業務網關內的數通設備檢測和基於Wap業務的Radius消息檢測。

其中，基於綜合業務網關內的數通設備檢測方法為：通過檢測綜合業務網關內部的數通設備運行情況，判斷綜合業務網關的業務是否需要切換。當數通設備出現故障，將該綜合業務網關的全部業務切換至另一條GRE(通用路由封裝協議)隧道，即將所述綜合業務網關所有業務均遷移至另一套網關。此方案考慮到綜合業務網關內的業務伺服器故障率較低，而數通設備的故障率相對較高，因此使用數通設備的故障檢測作為綜合業務網關容災切換的判別條件。然而，此方案需對綜合業務網關對應的全部業務進行整體切換，使得綜合業務網關內部很多可用的計算資源浪費；並且，當數通設備正常，即使綜合業務網關內部某業務伺服器因宕機或負荷過高，也無法觸發實現業務切換。

基於Wap業務的Radius消息檢測的方法為：通過檢測用戶WAP(Wireless Application Protocol，無線應用協議)的Radius消息，當綜合網業務關內部的Radius伺服器檢測到與用戶交互消息超時或不正常的時候，對GRE隧道對應種類的業務流進行整體切換。此方案考慮到現階段綜合業務網關一般都需要處理WAP業務，在WAP用戶較多的時候，用戶與綜合網關的Radius消息交互頻繁，因此可作為檢測GRE隧道及綜合業務網關系統是否正常的判別指標。然而，Radius消息僅在用戶上/下線的時候產生，因此在其它過程是無法對業務及隧道情況進行檢測；並且，隨著WAP業務的大幅萎縮，當WAP用戶較少時，Radius消息交互不再頻繁，此方案的判別準確性難以保證；若綜合業務網關取消WAP業務，則無法判別GRE隧道的通斷情況。

可見，現有的綜合業務網關容災切換方法存在如下問題：

1)切換判別條件缺乏準確性和可擴展性：若基於數通設備的運行情況，無法有效代表各業務伺服器的運行情況；若基於WAP業務的Radius消息，僅利用某一種業務的通斷情況來代表整體業務，檢測風險較高，可擴展性不強；

2)業務切換是隧道級：一旦切換，將是綜合業務網關的所有業務進行整體切換，對網絡資源及業務的影響較大，並且使得所述綜合網關中存在的大量可用資源被浪費；

3)網絡資源利用率不高：網絡一旦切換，把業務流量切換至事先規劃好的容災節點，這需要對容災節點進行更大的帶寬規劃，而平時容災節點的利用率比較低，因而造成帶寬資源浪費。

技術實現要素：

基於此，本發明提供一種綜合業務網關容災切換的方法和裝置，能夠提高容災切換判斷的準確性和擴展性，同時降低容災成本，提高網絡利用率。

本發明一方面提供一種綜合業務網關容災切換的方法，包括：

獲取綜合業務網關的狀態檢測信息，檢測綜合業務網關對應的GRE隧道是否為可用隧道，獲取可用隧道的綜合業務網關的狀態檢測信息，根據所述狀態檢測信息檢測所述綜合業務網關中各業務伺服器的CPU利用率是否高於設定門限值；

將不可用的GRE隧道對應的全部業務或CPU利用率高於設定門限值的業務伺服器對應的業務標記為待調整業務，並觸發預設的容災切換程序；

通過所述容災切換程序計算待調整業務對應的成本最低的切換策略，根據所述切換策略將所述待調整業務切換至對應的綜合業務網關。

優選的，所述獲取可用隧道的各綜合業務網關的狀態檢測信息，之前還包括：

接收核心網產生的業務，對所述業務進行分類，並將所述業務分別映射到對應的GRE隧道，以將所述業務分別發送至對應的綜合業務網關。

優選的，所述獲取各綜合業務網關的狀態檢測信息，包括：

通過預設的業務均衡設備向各綜合業務網關發送獲取狀態信息的GRE控制報文請求；將返回GRE控制報文成功的綜合業務網關對應的GRE隧道確定為可用隧道，並根據返回成功的GRE控制報文獲取所述綜合業務網關的狀態檢測信息；以及，將返回GRE控制報文失敗的綜合業務網關對應的GRE隧道確定為不可用的GRE隧道。

優選的，所述返回成功的GRE控制報文中包括：業務標識、從所述業務均衡設備至對應綜合業務網關的網絡跳數、以及對應綜合業務網關中各業務伺服器的CPU利用率信息。

優選的，所述GRE控制報文頭部格式為：包括Protocol Type欄位、Key欄位、PayLoad欄位以及Sequence Number欄位；

Protocol Type欄位用於標識控制報文的類型，Key欄位用於區分不同的業務，PayLoad欄位用於裝載對應業務的狀態信息，Sequence Number欄位用於標記報文收發是否正常。

優選的，所述GRE控制報文包括：從所述業務均衡設備發給各綜合業務網關的發送報文、以及從各綜合業務網關反饋至所述業務均衡設備的接收報文，

在發送報文中，若Key欄位的對應位設置為1，表示查詢對應位的業務狀態，若設置為0，表示不查詢對應位的業務狀態；

在接收報文中，若Key欄位的對應位置位為1，表示針對該位對應的業務有數據反饋；若置位為0，則表示反饋方沒有該位對應的業務；

所述Payload欄位為8個Byte，用每個Byte表示一個業務的狀態；每個Byte的前4位用於裝載業務流從所述業務均衡設備通過對應GRE隧道傳輸至對應綜合業務網關的網絡跳數，後4位用於裝載所述綜合業務網關中對應業務伺服器的CPU利用率；

在發送報文中，為所述Sequence Number欄位分配一個隨機值n，若對應的接收報文中Sequence Number欄位為n+1，表示報文收發成功，否則，表示報文收發失敗。

優選的，計算待調整業務對應的成本最低的切換策略，包括：

根據待調整業務對應的IP傳輸網成本和伺服器計算資源消耗成本，構建對應的成本模型；

求解所述成本模型的最小值，得出最小值時對應的GRE隧道和業務流類型，根據所述GRE隧道和業務流類型得到所述待調整業務對應的成本最低的切換策略。

優選的，所述根據待調整業務對應的IP傳輸網成本和伺服器計算資源消耗成本，構建對應的成本模型，包括：

根據業務流經過IP網絡每一跳對數據設備的帶寬成本和每跳傳輸電路的帶寬成本，得出待調整業務x對應的IP傳輸網成本為：

根據對應業務伺服器的TPMC容量消耗成本計算待調整業務x對應的伺服器計算資源消耗成本為：

根據所述IP傳輸網成本、伺服器計算資源消耗成本構建所述待調整業務x對應的成本模型為:

式中，m為可用的GRE隧道總數，n為每條GRE隧道可傳輸的業務流總數；

xik為通過第i條GRE隧道發出的第k種業務流；

Hopi為業務流通過第i條GRE隧道至對應綜合業務網關的網絡跳數；

Cip為IP網絡的帶寬擴容成本；

Clink為傳輸電路的帶寬擴容成本；

Bnowik為第i條GRE隧道發出的第k種業務流的帶寬；

Tnowik為第i條GRE隧道發出的第k種業務流對應的業務伺服器的當前可用容量；

Tadj為調整周期；

T maxik為第i條GRE隧道發出的第k種業務流對應的業務伺服器的最大處理能力；

CTik為處理第i條GRE隧道發出的第k種業務流的單位成本；

F為核心網產生的業務流總量，Bi為第i條GRE隧道的出口帶寬，Max％為最大帶寬利用率；

所述求解所述成本模型的最小值，得出最小值時對應的GRE隧道和業務流類型，根據所述GRE隧道和業務流類型得到所述待調整業務對應的成本最低的切換策略，包括：

求解成本模型Z(xik)的最小值，得到Z(xik)最小值時對應的i和k的取值，根據所述i和k的取值得到所述待調整業務x對應的成本最低的切換策略為第i條GRE隧道的第k種業務流。

本發明另一方面還提供一種綜合業務網關容災切換的裝置，包括：

檢測綜合業務網關對應的GRE隧道是否為可用隧道，獲取可用隧道的綜合業務網關的狀態檢測信息，根據所述狀態檢測信息檢測綜合業務網關中各業務伺服器的CPU利用率是否高於設定門限值；

切換決策模塊，用於將不可用的GRE隧道對應的全部業務或CPU利用率高於設定門限值的業務伺服器對應的業務標記為待調整業務，並觸發預設的容災切換程序；

業務映射模塊，用於通過所述容災切換程序計算待調整業務對應的成本最低的切換策略，根據所述切換策略將所述待調整業務切換至對應的綜合業務網關。

優選的，所述計算待調整業務對應的成本最低的切換策略，包括：

根據待調整業務對應的IP傳輸網成本和伺服器計算資源消耗成本，構建對應的成本模型；

求解所述成本模型的最小值，得出最小值時對應的GRE隧道和業務流類型，根據所述GRE隧道和業務流類型得到所述待調整業務對應的成本最低的切換策略。

優選的，所述業務映射模塊，還用於接收核心網產生的業務，對所述業務進行分類，並將所述業務分別映射到對應的GRE隧道，以將所述業務分別發送至對應的綜合業務網關。

優選的，所述狀態判別模塊，還用於向各綜合業務網關發送獲取狀態信息的GRE控制報文請求，將返回GRE控制報文成功的綜合業務網關對應的GRE隧道確定為可用隧道，並根據返回成功的GRE控制報文獲取所述綜合業務網關的狀態檢測信息；還用於將返回GRE控制報文失敗的綜合業務網關對應的GRE隧道確定為不可用的GRE隧道。

優選的，還包括：存儲模塊，用於存儲綜合業務網關反饋的GRE控制報文；

隧道執行模塊，用於建立與各綜合業務網關的GRE隧道，以及將業務封裝到對應的GRE隧道上，以通過所述GRE隧道傳輸給對應的綜合業務網關。

上述方案的綜合業務網關容災切換的方法和裝置，通過獲取GRE隧道正常的各綜合業務網關的狀態檢測信息，根據所述狀態檢測信息檢測綜合業務網關中各業務伺服器的CPU利用率是否高於設定門限值；將GRE隧道不正常或CPU利用率高於設定門限值的業務伺服器對應的業務標記為待調整業務，並觸發預設的容災切換程序；通過所述容災切換程序計算待調整業務對應的成本最低的切換策略，根據所述切換策略將所述待調整業務切換至對應的綜合業務網關。通過本發明的方案可實現業務級容災切換，提高了容災切換判斷的準確性和擴展性，對於需切換的業務流從當前可用的資源中選擇成本最低的路徑進行疏導，有利於降低容災成本，提高網絡效率。

附圖說明

圖1為實施例一的綜合業務網關容災切換的方法的示意性流程圖；

圖2為實施例二的綜合業務網關容災切換的方法的示意性流程圖；

圖3為實施本發明綜合業務網關容災切換的方法的系統框架示意圖；

圖4為GRE控制報文的頭部格式示意圖；

圖5為Key欄位的定義示意圖；

圖6為實施例三的綜合業務網關容災切換的裝置的示意性結構圖。

具體實施方式

為了使本發明的目的、技術方案及優點更加清楚明白，以下結合附圖及實施例，對本發明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發明，並不用於限定本發明。

本發明提供的實施例包括綜合業務網關容災切換的方法實施例，還包括相應的綜合業務網關容災切換的裝置實施例。以下分別進行詳細說明。

實施例一：

圖1為實施例一的綜合業務網關容災切換的方法的示意性流程圖；如圖1所示，本實施例的綜合業務網關容災切換的方法包括如下步驟S1至S3，各步驟詳述如下：

S1，檢測綜合業務網關對應的GRE隧道是否為可用隧道，獲取可用隧道的各綜合業務網關的狀態檢測信息，根據所述狀態檢測信息檢測綜合業務網關中各業務伺服器的CPU利用率是否高於設定門限值；

需要說明的是，本步驟之前，接收到核心網邊緣設備發送的若干業務，對所述業務進行分類，並將所述業務分別映射到對應的可用GRE隧道，以將所述業務分別發送至對應的綜合業務網關。所述業務被分發到各自對應的綜合業務網關後，可定時獲取各綜合業務網關的狀態檢測信息，以探測各綜合業務網關內部運行情況。

優選的，本實施例中，可定時向各綜合業務網關發送獲取狀態信息的GRE控制報文請求，以獲取各綜合業務網關的狀態檢測信息；或者各綜合業務網關定時以GRE控制報文的形式對其內部運行情況進行主動反饋。其中，所述GRE控制報文中包括的信息有：業務標識、通過對應GRE隧道至對應綜合業務網關的網絡跳數、以及綜合業務網關中各業務伺服器的CPU利用率等。基於綜合業務網關反饋的GRE控制報文可獲取對應綜合業務網關的狀態檢測信息。

S2，將不可用的GRE隧道對應的全部業務或CPU利用率高於設定門限值的業務伺服器對應的業務標記為待調整業務，並觸發預設的容災切換程序；

當業務伺服器的CPU利用率高於設定門限值，表明所述業務伺服器的業務處理能力較弱，無法對對應類型的業務進行有效處理，此時需要將對應類型的業務切換至其它綜合業務網關，交由其它綜合業務網關中內的業務伺服器進行處理。

本實施例中，只有當檢測到有待調整業務時，容災切換程序才會被觸發啟動。

S3，通過所述容災切換程序計算待調整業務對應的成本最低的切換策略，根據所述切換策略將所述待調整業務切換至對應的綜合業務網關。

優選的，本實施例計算待調整業務對應的成本最低的切換策略的實現方式可為：根據待調整業務對應的IP傳輸網成本和伺服器計算資源消耗成本，構建對應的成本模型；然後求解所述成本模型的最小值，得出最小值時對應的GRE隧道和業務流類型，根據所述GRE隧道和業務流類型得到所述待調整業務對應的成本最低的切換策略。

作為一優選實施方式，可根據業務流經過IP網絡每一跳對數據設備的帶寬成本和每跳傳輸電路的帶寬成本，得出待調整業務x對應的IP傳輸網成本為：

式中，m為可用的GRE隧道的總數，n為每條GRE隧道的業務流總數；xik為一個調整周期內通過第i條GRE隧道發出的第k種業務流；Hopi為業務流通過第i條GRE隧道傳輸至對應的綜合業務網關的網絡跳數；Cip為IP網絡的帶寬擴容成本，單位為元/Gbps；Clink為傳輸電路的帶寬擴容成本，單位為元/條1G電路。其中，Hopi可從綜合業務網關GRE路由器對應的IP協議路由表中查詢得到，Cip和Clink可根據運營商的歷史建設成本情況得到，為特定的常數。

作為一優選實施方式，可根據對應業務伺服器的TPMC容量消耗成本計算待調整業務x對應的伺服器計算資源消耗成本為：

式中，Bnowik為第i條GRE隧道發出的第k種業務流的帶寬，單位為Gbps；Tnowik為第i條GRE隧道發出的第k種業務流對應的業務伺服器的當前處理能力，單位為TPMC；Tadj為一個調整周期；T maxik為第i條GRE隧道發出的第k種業務流對應的業務伺服器所能處理的最大處理能力；CTik為處理第i條GRE隧道發出的第k種業務流的單位平均成本，單位可為元/TPMC。其中，Bnowik可根據運營商路由及Qos的設置策略為每種業務分配。

由於業務伺服器的處理容量一般與伺服器的CPU處理能力成正比關係，根據工程經驗，Tnowik可近似使用T maxik*CPUik％得到(T maxik在網絡規劃建設中已經明確，CPUik％為伺服器的CPU利用率)；而處理xik所需的容量需求，由於在實際網絡規劃中帶寬的規劃與伺服器處理容量成正比，則可近似通過得到。

進一步的，根據所述IP傳輸網成本、伺服器計算資源消耗成本構建所述待調整業務x對應的成本模型為：

其中，該成本模型需滿足的邊界條件包括：

1)所有業務流的總和不得超過核心網產生業務流總量，即

2)第i條GRE隧道發出的所有業務流的總帶寬不超過其網絡出口帶寬能力，即

F為核心網產生的業務流總量，Bi為第i條GRE隧道的出口帶寬，Max％為運營商對帶寬規劃的最大帶寬利用率(一般取值在50-80％之間)；

3)任意一條業務流對綜合業務網關的業務伺服器產生的容量不超過所述伺服器的最大容量，即

基於上述邊界條件求解Z(xik)的最小值，得到對應的i和k，則待調整業務x對應的成本最低的切換策略可確定為第i條GRE隧道的第k種業務流。即將待調整業務x映射到第i條GRE隧道的第k種業務流，進而將所述待調整業務x切換至第i條GRE隧道對應的綜合業務網關，將所述業務x交由該綜合業務網關中對應的業務伺服器處理。至此，完成了待調整業務的切換。

通過上述實施例的綜合業務網關容災切換的方法，可實現業務級容災切換，提高容災切換判斷的準確性和擴展性；並且對於需切換的業務流量可選擇出最經濟的路徑進行疏導，提升了網絡利用率和容災流量的疏導效率。

實施例二：

圖2為實施例二的綜合業務網關容災切換的方法的示意性流程圖；本實施例與上述實施例一的主要區別在於，本實施例通過設定的GRE控制報文獲取綜合業務網關的狀態檢測信息，並且還可通過綜合業務網關反饋GRE控制報文的情況判別對應的GRE隧道是否異常，若檢測到GRE隧道異常，還需執行相關隧道業務的整體切換。

如圖2所示，本實施例的綜合業務網關容災切換的方法包括如下步驟S21至S25，各步驟詳述如下：

S21，接收核心網邊緣設備發送的若干業務，對所述業務進行分類，並將所述業務分別映射到對應的GRE隧道，以將所述業務分別發送至對應的綜合業務網關；

優選的，本實施例中，預先在核心網邊緣設備與綜合業務網關之間設置一個業務均衡設備，系統框架如圖3所示。所述業務均衡設備能夠與綜合業務網關建立GRE隧道(GRE隧道1、GRE隧道2…GRE隧道n)，並把核心網產生的業務封裝到對應的GRE隧道。

S22，向各綜合業務網關發送獲取狀態信息的GRE控制報文請求；

本實施例中，通過所述業務均衡設備向各綜合業務網關發送獲取狀態信息的GRE控制報文請求。其中，所述GRE控制報文的頭部格式如圖4所示，包括Protocol Type欄位、Key欄位、PayLoad欄位以及Sequence Number欄位。其中，Protocol Type欄位用於標識控制報文，Key欄位用於區分綜合業務網關內不同的業務，PayLoad欄位用於裝載對應業務的狀態信息，Sequence Number欄位用於標記報文收發是否正常。

具體的，還可通過ProtocolType欄位標記業務流報文，Protocol Type欄位設置為FFFF(RFC 1701中定義為保留欄位)時，表示為控制報文；業務流時，Protocol Type欄位可根據其具體的封裝協議設定。

具體的，所述Payload欄位為8個Byte，每個Byte表示一個業務的狀態，每個Byte的前4位裝載業務流通過對應GRE隧道至對應綜合業務網關的網絡跳數(考慮到一般綜合業務網需匹配核心網布局，其傳輸距離一般不超過16跳)，後4位裝載對應的業務伺服器的CPU利用率(CPU的利用率無需做過細的分檔，4bit可把CPU利用率量化步長控制在10％以內，足以滿足運營商系統要求)；

另外，本實施例中的GRE控制報文分為發送報文、接收報文兩類型。其中發送報文是指從所述業務均衡設備發給各綜合業務網關的報文；接收報文指各綜合業務網關反饋給業務均衡設備的報文，均遵循圖4所示的GRE報文頭部格式。

S23，等待綜合業務網關反饋GRE控制報文；

優選的，在發送報文中，為所述Sequence Number欄位隨機分配一個數值n，若對應的接收報文中Sequence Number欄位為n+1，表示綜合業務網關反饋GRE控制報文成功，否則，表示綜合業務網關反饋GRE控制報文失敗。

S24，是否有綜合業務網關反饋GRE控制報文失敗？若否，執行下一步驟；若是，將返回GRE控制報文失敗的綜合業務網關對應的GRE隧道確定為不可用的GRE隧道(或異常隧道)，並將所述不可用的GRE隧道對應的全部業務標記為待調整業務，執行步驟S27；

本實施例中，發送報文中事先隨機定義一個Sequence Number的數值n，對應的接收報文則設置為n+1，通過此握手機制進行發送與接收的確認。當在一個採樣周期內沒有收到Sequence Number為n+1的接收報文，則表明對應GRE隧道不正常，需要進行業務切換。

S25，將反饋GRE控制報文成功的綜合業務網關對應的GRE隧道確定為可用隧道，並根據返回成功的GRE控制報文獲取所述綜合業務網關的狀態檢測信息。

如上述GRE控制報文的格式設定，本實施例中所述GRE控制報文中包括有業務標識、從所述業務均衡設備至對應的綜合業務網關的網絡跳數、以及綜合業務網關中各業務伺服器的CPU利用率等信息。因此，可根據返回成功的GRE控制報文獲取對應綜合業務網關的狀態檢測信息。

優選的，在發送報文中，若Key欄位的對應位設置為1，表示查詢對應位的業務的狀態，若設置為0，表示不查詢對應位的業務；在接收報文中，Key欄位的對應位置位為1，表示針對該位對應的業務有數據反饋；若置位為0，則表示反饋方沒有該位對應的業務。

具體的，通過Key欄位(4個Byte)的位數來表示不同業務的種類是，收發雙方需事先約定不同的位數表示不同的業務(例如WAP業務、普通web業務或者視頻流業務，如圖5所示)，發送方(業務均衡設備)將對應位均設置為1，表示對不同業務的狀態均進行查詢。接收報文(綜合業務網關反饋的報文)中對對應的位進行置位，若置位為1，表示該位對應的業務有數據反饋；若置位為0，則表示所述綜合業務網關沒有該位對應的業務。

另外，業務均衡設備根據綜合業務網關反饋的Key欄位，在下一次向所述綜合業務網關發送GRE控制報文請求時，可將Key欄位的對應位設置為0，即業務均衡設備根據綜合業務網關反饋的Key欄位，調整下一次向所述綜合業務網關發送GRE控制報文請求。

S26，根據所述狀態檢測信息檢測綜合業務網關中各業務伺服器的CPU利用率是否高於設定門限值？若是，將CPU利用率高於設定門限值的業務伺服器對應的業務標記為待調整業務，執行下一步，否則，返回步驟S21；

S27，觸發預設的容災切換程序，通過所述容災切換程序計算待調整業務對應的成本最低的切換策略；

S28，根據所述切換策略將所述待調整業務切換至對應的綜合業務網關。

本實施例中，當檢測到GRE隧道異常時，觸發預設的容災切換程序，通過所述容災切換程序對異常隧道對應的業務計算成本最低的切換策略，實現隧道級的容災切換，保證切換效率；當檢測到綜合業務網關中對應業務伺服器的CPU利用率高於設定門限值時，也會觸發預設的容災切換程序，通過所述容災切換程序對相應的一個或者多個業務計算成本最低的切換策略，進行業務級的容災切換，保證切換的準確性。其中，計算成本最低的切換策略的方式可參照上述實施例一所述，不做贅述。

通過實施例二的綜合業務網關容災切換的方法，通過特定的GRE控制報文格式，實現了核心網與綜合業務網關之間的信息傳遞，為實現業務級的容災提供了有效的檢測機制，進而提高容災切換判斷的準確性和擴展性；在需要進行容災切換時，根據網絡狀態、伺服器處理能力，將待切換的業務流按最經濟的方式分配到其它可用的GRE隧道進行容災，降低容災成本，提高網絡效率。

需要說明的是，對於前述的各方法實施例，為了簡便描述，將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本發明並不受所描述的動作順序的限制，因為依據本發明，某些步驟可以採用其它順序或者同時進行。

以下對可用於執行上述綜合業務網關容災切換的方法的綜合業務網關容災切換的系統實施例進行說明。為了便於說明，綜合業務網關容災切換的系統實施例的結構示意圖中，僅僅示出了與本發明實施例相關的部分，本領域技術人員可以理解，圖中示出的系統結構並不構成對系統的限定，可以包括比圖示更多或更少的部件，或者組合某些部件，或者不同的部件布置。

實施例三：

圖6為本發明實施例三的綜合業務網關容災切換的裝置的示意性結構圖；如圖6所示，本實施例的綜合業務網關容災切換的裝置包括：狀態判別模塊310、切換決策模塊320以及業務映射模塊330，各模塊詳述如下：

所述狀態判別模塊310，用於檢測綜合業務網關對應的GRE隧道是否為可用隧道，獲取可用隧道的綜合業務網關的狀態檢測信息，根據所述狀態檢測信息檢測綜合業務網關中各業務伺服器的CPU利用率是否高於設定門限值；

所述切換決策模塊320，用於將不可用的GRE隧道對應的全部業務或CPU利用率高於設定門限值的業務伺服器對應的業務標記為待調整業務，並觸發預設的容災切換程序。

所述業務映射模塊330，用於通過所述容災切換程序計算待調整業務對應的成本最低的切換策略，根據所述切換策略將所述待調整業務切換至對應的綜合業務網關。

優選的，所述業務映射模塊330計算待調整業務對應的成本最低的切換策略的具體實現方式可包括：根據待調整業務對應的IP傳輸網成本和伺服器計算資源消耗成本，構建對應的成本模型；求解所述成本模型的最小值，得出最小值時對應的GRE隧道和業務流類型，根據所述GRE隧道和業務流類型得到所述待調整業務對應的成本最低的切換策略。具體如上述方法實施例所述，不做贅述。

優選的，所述業務映射模塊310，還用於接收核心網邊緣設備發送的業務，對所述業務進行分類，並將所述業務分別映射到對應的GRE隧道，以將所述業務分別發送至對應的綜合業務網關。

作為另一優選實施方式，所述狀態判別模塊310，還用於向各綜合業務網關發送獲取狀態信息的GRE控制報文請求，以及將返回GRE控制報文成功的綜合業務網關對應的GRE隧道確定為可用隧道，並根據返回成功的GRE控制報文獲取所述綜合業務網關的狀態檢測信息；還用於將返回GRE控制報文失敗的綜合業務網關對應的GRE隧道確定為不可用的GRE隧道(異常隧道)。

進一步的，本實施例所述綜合業務網關容災切換的裝置還可包括：存儲模塊，用於存儲綜合業務網關反饋的GRE控制報文，所述GRE控制報文還可包括綜合業務網關各種業務伺服器的負載、GRE隧道的網絡鏈路負載等信息。所述存儲模塊可根據綜合業務網關反饋的GRE控制報文進行實時更新。

優選的，所述綜合業務網關容災切換的裝置還可包括：隧道執行模塊，用於與綜合業務網關建立GRE隧道，以及將業務封裝到對應的GRE隧道上，以通過所述GRE隧道傳輸給對應的綜合業務網關。例如根據所述業務映射模塊310的輸出結果，把待調整業務封裝到對應的GRE隧道上，通過對應的GRE隧道傳輸給對應的綜合業務網關。

需要說明的是，上述示例的綜合業務網關容災切換的系統的實施方式中，各模塊/單元之間的信息交互、執行過程等內容，由於與本發明前述方法實施例基於同一構思，其帶來的技術效果與本發明前述方法實施例相同，具體內容可參見本發明方法實施例中的敘述，此處不再贅述。

此外，上述示例的綜合業務網關容災切換的系統的實施方式中，各功能模塊的邏輯劃分僅是舉例說明，實際應用中可以根據需要，例如出於相應硬體的配置要求或者軟體的實現的便利考慮，將上述功能分配由不同的功能模塊完成，即將所述綜合業務網關容災切換的系統的內部結構劃分成不同的功能模塊，以完成以上描述的全部或者部分功能。

另外，上述示例的綜合業務網關容災切換的系統的實施方式中，各功能模塊可以集成在一個處理模塊中，也可以是各個模塊單獨物理存在，也可以兩個或兩個以上模塊集成在一個模塊中。上述集成的模塊既可以採用硬體的形式實現，也可以採用軟體功能模塊的形式實現。

所述集成的模塊如果以軟體功能模塊的形式實現並作為獨立的產品銷售或使用時，可以存儲在一個計算機可讀取存儲介質中。本領域普通技術人員可以理解本發明的任意實施例指定的方法的全部或部分步驟是可以通過程序來指令相關的硬體(個人計算機、伺服器、或者網絡設備等)來完成。該程序可以存儲於一計算機可讀存儲介質中。該程序在執行時，可執行上述任意實施例指定的方法的全部或部分步驟。前述存儲介質可以包括任何可以存儲程序代碼的介質，例如只讀存儲器(Read-Only Memory，ROM)、隨機存取器(Random Access Memory，RAM)、磁碟或光碟等。

在上述實施例中，對各個實施例的描述都各有側重，某個實施例中沒有詳述的部分，可以參見其它實施例的相關描述。

以上所述實施例僅表達了本發明的幾種實施方式，不能理解為對本發明專利範圍的限制。應當指出的是，對於本領域的普通技術人員來說，在不脫離本發明構思的前提下，還可以做出若干變形和改進，這些都屬於本發明的保護範圍。因此，本發明專利的保護範圍應以所附權利要求為準。