综合业务网关容灾切换的方法和装置与流程

本发明涉及移动互联网技术领域，特别是涉及综合业务网关容灾切换的方法和综合业务网关容灾切换的装置。

背景技术：

现有通信网络中，关于综合业务网关容灾切换的技术包括：基于综合业务网关内的数通设备检测和基于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隧道可传输的业务流总数；

x_ik为通过第i条GRE隧道发出的第k种业务流；

Hop_i为业务流通过第i条GRE隧道至对应综合业务网关的网络跳数；

C_ip为IP网络的带宽扩容成本；

C_link为传输电路的带宽扩容成本；

Bnow_ik为第i条GRE隧道发出的第k种业务流的带宽；

Tnow_ik为第i条GRE隧道发出的第k种业务流对应的业务服务器的当前可用容量；

Tadj为调整周期；

T max_ik为第i条GRE隧道发出的第k种业务流对应的业务服务器的最大处理能力；

C_Tik为处理第i条GRE隧道发出的第k种业务流的单位成本；

F为核心网产生的业务流总量，B_i为第i条GRE隧道的出口带宽，Max％为最大带宽利用率；

所述求解所述成本模型的最小值，得出最小值时对应的GRE隧道和业务流类型，根据所述GRE隧道和业务流类型得到所述待调整业务对应的成本最低的切换策略，包括：

求解成本模型Z(x_ik)的最小值，得到Z(x_ik)最小值时对应的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隧道的业务流总数；x_ik为一个调整周期内通过第i条GRE隧道发出的第k种业务流；Hop_i为业务流通过第i条GRE隧道传输至对应的综合业务网关的网络跳数；C_ip为IP网络的带宽扩容成本，单位为元/Gbps；C_link为传输电路的带宽扩容成本，单位为元/条1G电路。其中，Hop_i可从综合业务网关GRE路由器对应的IP协议路由表中查询得到，C_ip和C_link可根据运营商的历史建设成本情况得到，为特定的常数。

作为一优选实施方式，可根据对应业务服务器的TPMC容量消耗成本计算待调整业务x对应的服务器计算资源消耗成本为：

式中，Bnow_ik为第i条GRE隧道发出的第k种业务流的带宽，单位为Gbps；Tnow_ik为第i条GRE隧道发出的第k种业务流对应的业务服务器的当前处理能力，单位为TPMC；Tadj为一个调整周期；T max_ik为第i条GRE隧道发出的第k种业务流对应的业务服务器所能处理的最大处理能力；C_Tik为处理第i条GRE隧道发出的第k种业务流的单位平均成本，单位可为元/TPMC。其中，Bnow_ik可根据运营商路由及Qos的设置策略为每种业务分配。

由于业务服务器的处理容量一般与服务器的CPU处理能力成正比关系，根据工程经验，Tnow_ik可近似使用T max_ik*CPU_ik％得到(T max_ik在网络规划建设中已经明确，CPU_ik％为服务器的CPU利用率)；而处理x_ik所需的容量需求，由于在实际网络规划中带宽的规划与服务器处理容量成正比，则可近似通过得到。

进一步的，根据所述IP传输网成本、服务器计算资源消耗成本构建所述待调整业务x对应的成本模型为：

其中，该成本模型需满足的边界条件包括：

1)所有业务流的总和不得超过核心网产生业务流总量，即

2)第i条GRE隧道发出的所有业务流的总带宽不超过其网络出口带宽能力，即

F为核心网产生的业务流总量，B_i为第i条GRE隧道的出口带宽，Max％为运营商对带宽规划的最大带宽利用率(一般取值在50-80％之间)；

3)任意一条业务流对综合业务网关的业务服务器产生的容量不超过所述服务器的最大容量，即

基于上述边界条件求解Z(x_ik)的最小值，得到对应的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)、磁盘或光盘等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上所述实施例仅表达了本发明的几种实施方式，不能理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。