智能网业务控制点容灾备份的组网方案研究

易传美，刘世峰，孙启昌

（中国移动通信集团河南有限公司，郑州 450008）

目前移动话音类增值业务需要核心网进行智能触发至智能网平台，再通过智能网平台为用户提供各种丰富的话音增值服务。中国移动自1999年开展智能网业务以来，业务种类不断增多，智能用户规模不断扩大，移动智能网的网络地位越来越显得重要。保持智能业务高质量、稳定可靠的运行是网络维护工作的重要目标之一。

现在智能网系统核心设备业务控制点一直采用多点分区方式承载业务，每套业务控制点单点独立运行，对于大规模用户的业务如虚拟专用移动网（VPMN）业务，每套SCP各自承载某一个业务区或几个业务区的虚拟专用移动网用户。这种单点SCP独立运行在一定程度上存在较大的灾难隐患，单点SCP软件或硬件故障有可能导致所辖区域业务用户不能进行通话或者使用话音增值业务，有可能产生大量直接或间接的各种损失。因此，在中国移动智能网中有必要针对智能网核心设备SCP建立容灾系统，以便进行动态数据备份，并在生产设备发生灾难时，快速接管智能业务。

1 现有业务控制点容灾备份组网方案分析

1.1 现有业务控制点的容灾备份组网方案

现阶段对业务控制点的容灾备份组网方案一般有以下3种。

（1）循环容灾备份方案，各生产设备之间互相容灾备份，每台设备在容灾其它设备的同时又作为主用系统承担部分智能业务。SCP上的相关业务数据可以依赖于业务管理点（SMP）实时分发或者后台应用进行定时导入。从处理能力上考虑，各SCP需留被容灾SCP的业务处理能力，例如当SCP2作为SCP1的容灾节点时，SCP2考虑的处理能力应该为SCP2话务量+SCP1话务量。

（2）1+1容灾备份方案，对每一套生产系统均建设一套容灾系统对其进行容灾，采用专用路由完成生产系统与容灾系统的业务数据同步，在正常情况下，只有生产系统承载业务，容灾系统保持空转，随时准备接管生产系统上的业务。该方案可以实现远程容灾。

（3）N+1容灾备份方案，一套容灾系统对N台生产系统进行容灾，采用专用路由完成生产系统与容灾系统的业务数据同步，比较适合用于对多台设备的容灾，可以实现远程容灾。

1.2 现有业务控制点容灾备份组网方案存在问题

由于循环容灾备份方案存在以下缺点，在现网一般不采用：每个容灾节点SCP的处理能力需要考虑被容灾设备话务量+容灾设备本身话务量，要求SCP容量保持比较大的富余，设备资源浪费较大，当业务量增大时，也并不能节省投资；循环容灾备份方案的容灾链可能导致智能网系统的连环瘫机，比较危险。

现网一般采用1+1容灾备份方案或N+1容灾备份方案，据统计，现网需要容灾的生产系统只有1套时，一般采用1+1容灾备份；现网需要容灾的生产系统套数较多时，一般采用N+1容灾备份。现网业务控制点采用的容灾备份方案，存在以下缺点。

（1）1+1容灾备份方案正常情况下业务全部有1套生产系统承担，容灾系统完全处于空转或轻载状态，设备负荷十分不均，设备利用率非常低，投资大。因此该方案一般只限于需要容灾的生产系统只有1套且非常重要时采用。

（2）N+1（N>1）容灾备份方案，需要容灾的生产系统大于1套时，一般采用该方案。该方案要求容灾系统处于空转或轻载状态，N较大时，同时容灾性能将下降，多个设备出现问题时，同时接管多个生产系统对本身处理能力要求高，要求一套容灾设备的处理能力能达到多个故障设备处理能力的总和，或者需要建多套容灾设备来容灾这N套设备，投资也会随之增大。

无论是1+1容灾备份方案还是N+1容灾备份方案，都需要有一个空转或轻载设备作为容灾设备，存在着设备负荷不均衡，设备利用率低，设备资源浪费较大的缺点，当N+1方案里的多套设备故障时，容灾系统的接管能力也将受限。

针对上述方案存在的缺陷，本论述将提供一种针对业务控制点容灾问题的负荷分担组网解决方案，通过采用虚拟全局码GT，将多套业务控制点SCP组成一个负荷分担的集群组，同一个集群组里的每个业务控制点加载相同的业务逻辑和业务数据，用户数据也同时分发到集群组里的所有业务控制点，集群组里的业务控制点分布在不同的机房，负荷分担处理触发上来的呼叫，其中任何一个业务控制点或任何一个机房的设备故障时，业务自动切换到集群组里的其它业务控制点，由其它的业务控制点共同负荷分担处理业务，不影响业务。从而在不闲置设备的情况下，有效解决业务控制点的容灾问题。

2 实现SCP容灾备份新组网方案的网络结构

图1 现阶段SCP组网方案

将传统的SCP多点分区承载组网方式（如图1所示）改为SCP多点负荷分担组网方式，如图2所示， 一个SCP负荷分担集群组包括n个SCP站点，集群组引入虚拟GT0，由整个集群组共同承载全省或n个区的某一项业务，只需将智能网用户签约到GT0即可，同一个集群组里的每个SCP加载相同的业务逻辑和业务数据，用户数据由SMP同时分发到集群组里的所有SCP，集群组里的SCP负荷分担处理触发上来的呼叫。SCP站点分布在不同的机房，SCP任何一个设备故障均不影响业务（下图以所有端局都通过信令转接点（STP）转接到SCP为例，其它信令组网方式原理相同）。

图2 SCP新组网方案

3 SCP容灾备份新组网方案的实现方式

3.1 集群组内呼叫负荷分担实现方式

负荷分担集群组各SCP配置共同的虚拟GT0，每个站点的实际GT仍然是不同的（GT1、GT2……GTn），所有业务用户均签约到虚拟GT0，STP根据负荷分担原则将GT0分别翻译到该集群组内的各个目的信令点（DPC），实现信令转接点将GT0负荷分担到该集群组里的各个SCP (集群组SCP的数量应考虑本省STP支持GT到DPC负荷分担的数量、SCP数据的查询效率因素)，SCP收到首消息后把GT0识别为自己的GT。 根据协议规范，首消息的地址可以不是真实的地址，在响应侧回真实地址后，整个对话链接才真正建立，后续都使用真实地址进行通信，这些移动交换中心（MSC）都支持，也是 handover方式的实现基础。

呼叫从MSC发起后，第一条消息经过MSC→STP→SCP的过程由STP随机送到SCPx，使用虚拟GT0，然后SCPx回的响应消息中使用实际GTx；第二条消息随机到达STP后，按照消息中携带的实际GTx来路由，即GT1翻译到SCP1 ，GT2翻译到SCP2，保证一个呼叫的所有消息到达同一个SCP；SCP1或SCPn故障后，STP将所有消息分发到该集群组内剩余其它SCP上。

3.2 负荷分担集群组内SCP数据同步实现方式

承载用户时首次采用手工全量导入方法导入本集群组内所有用户数据，后期则由SMP向各SCP实时同步变更的用户数据。

SMP向集群内所有SCP发出修改本集群组内所承载用户数据的请求，使得SMP数据库和各个SCP的数据保持完全一致性。

在单个SCP升级或故障时采用“缓存同步”技术，SMP自动将故障SCP状态设置为broken，由SMP将指令存在缓存中，当SCP恢复连接后SMP修改SCP状态为同步，重新发送缓存中的指令。SMP缓存中可以存放的指令数量可以根据实际情况设置。

当缓存达到一定数量（例如60%、80%、100%）可以上报不同级别的告警，告警阈值可以自己设置。

3.3 负荷分担集群组内SCP用户数据放置方式

在业务设计时考虑可能承载的用户数据量，对集群内用户数据在500万（可结合数据访问效率实际情况界定）以下时，采用全号段放置模式。所有用户数据不分号段，分布在同一张用户表中。对容量超过500万（可结合数据访问效率实际情况界定）的用户数据采用号段分配模式，按号段分布在SCP上不同的用户表中，以便提高SCP大容量数据访问效率。

3.4 负荷分担集群组内SCP容灾实现方式

负荷分担集群组里SCP站点分布在不同的机房，其中任何一个生产机或任何一个机房的设备故障时，业务自动切换到集群里其它的生产机，由其它的生产机共同负荷分担处理业务，不影响业务，防止SCP的单点故障影响用户业务使用。

管理者可以定义在呼叫、数据访问或其它情况下的容灾切换检测机制。容灾切换的方式可以有自动切换和手工切换两种：可以配置是否支持自动切换，若配置为支持自动切换，在呼叫、数据访问或其它情况满足管理者定义的规则后触发容灾切换条件后，将自动发生容灾切换；也可以通过网管系统手工操作，进行容灾的切换，手工切换的对象可以是单套SCP也可以是集群中的多套SCP。

3.5 SCP负荷分担集群组网方案适用范围

该组网方案可以应用到以下业务SCP。

（1）现网用户数据参数（包括账户余额、剩余免费时长、充值卡状态标志）不随呼叫实时改变的业务SCP，如没有包月时长的VPMN业务SCP、计费已迁移到BOSS的业务SCP。

（2）没有用户数据的业务SCP，如欠费风险控制业务、统一充值业务。

4 实现SCP容灾备份的负荷分担组网方案优点

与传统的SCP多点分区承载业务用户相比，该负荷分担集群组网方案存在以下几个主要的优点。

首先，该方案可以大大提高各SCP设备的利用率，均衡各SCP的负荷，降低用户搬迁频次，节省投资。如现网900万的用户按照70%的设备利用率来放置到SCP，若采用负荷分担集群组网，则共需要容量1 285万，仅需13套100万容量的SCP来承载，且集群组内的13套设备负荷分担处理呼叫，每套SCP设备的利用率都可以保持在69%左右；若采用SCP多点分区承载，通过人为分配用户到各SCP，不可能把900万用户完全平均的分配到各SCP承载，根据现网实际运行情况来看，最好的均衡效果也至少需要15套100万容量的SCP来分别承载，各SCP平均设备利用率能达到60%左右，而且随着各业务区用户数的变化，即使用户总数没变，也还需通过不断的用户搬迁调整来均衡各SCP负荷。

其次，该方案不需额外新建设备对该组内的设备进行应用级容灾备份，负荷分担的SCP分布在不同地理位置的机房，不用再另外单独部署容灾设备，就能实现业务的地理容灾，保证了设备业务的安全性，大大节省了容灾建设的投资成本。如第二点里提到的900万用户，若采用15套SCP多点分区承载方式，由于SCP故障后只能将整个故障SCP的话务指向容灾SCP，至少再新建1套100万容量的SCP来容灾，且这1套容灾设备只能同时容灾1套生产SCP。若采用13套SCP负荷分担集群组方式承载，由于故障SCP的话务会被平均分摊到组内其它SCP，则在不新建设备的情况下也能实现容灾，能同时容灾的设备套数及设备利用率情况如表1所示。

表1 容灾故障SCP情况

由于SCP处理能力和容量设计已经考虑了话务高峰的情况，所以SCP平常的实际处理能力能满足设备利用率为100%的要求。从表1可以得出，在非话务高峰时段，最多可以同时容灾4套故障SCP，在话务高峰时段最多也能同时容灾3套SCP。如果13套设备平均分布在3个不同物理位置的机房，则在不新建设备的情况下不但能实现单套SCP故障的容灾，而且还几乎能实现单个机房所有SCP故障的容灾。

第三，该方案降低了用户搬迁难度，节约了人力和时间。随着用户数的增加，各业务区不会因为单套SCP的处理能力达到上限而进行频繁的用户割接数据修改，只需在该集群组内新扩容SCP，然后将该集群组内的用户数据导入新设备即可，不再需要各业务区修改用户签约的GT码，从而大大节约了人力、时间，降低了用户搬迁难度。

第四，该方案大大提高了应对话务高峰的冲击能力。由于采取了负荷分担处理呼叫的方式，单个地区或几个地区的高话务并不能对整个集群组内SCP造成大的冲击。

5 结束语

本文详细从组网、数据同步、数据放置等方面阐述了SCP容灾备份负荷分担组网方案的实现方案。此方案在集团重点课题2011_LH_25《智能网多次业务触发机制及安全性保障研究》中已研究应用到业务中间件SCOM组网中，并在河南测试通过，后续在欠费风险控制业务SCP、统一充值业务SCP中也投入使用，并取得了良好的效果。从移动智能网的发展趋势来看，以后新业务将趋向于放在BOSS批价计费，目前已有业务如VPMN业务的计费也正在陆续搬迁到BOSS实现，因此SCP负荷分担集群组网方案的应用空间将会越来越大。

[1]中国移动智能网设备冗灾建议书[Z]. 2011,2.

[2]廖建新. 移动智能网[M]. 北京：北京邮电大学出版社有限公司，2000,11.

[3]康晓非，暴宇. 数字移动通信[M]. 北京：人民邮电出版社，2010,8.

[4]何欢，何倩. 数据备份与恢复[M]. 北京：机械工业出版社，2010,9.

[5]中华人民共和国信息产业部，中国国内电话网No.7信号方式技术规范[S]. GF 001-9001.