彩铃系统数据库容灾解决方案

孙忠岩

（中国移动通信集团内蒙古有限公司 呼和浩特 010090）

1 彩铃系统数据库容灾的必要性分析

1.1 彩铃业务的重要性

彩铃业务经过多年发展，已经逐渐成为运营商重要的盈利来源。因此确保彩铃业务系统的安全性也具有非常重要的意义。

1.2 彩铃业务系统的安全性考虑

目前彩铃业务系统的平台架构已经比较成熟。通常一套彩铃系统包括管理平面、呼叫平面两大部分，每个平面内部又包含前置交换放音模块和后台数据处理模块，如图1所示。

从安全性角度考虑：

图1 彩铃系统

从数量来讲，管理节点数量较少（通常只有1套），而呼叫节点数量较多（通常3套以上）。呼叫节点由于数量较多，可以通过网络路由方式做到一定的备份冗余。而相比之下，管理节点则存在单点故障风险。

从内容来讲，数据库是彩铃业务系统的核心，其数据极为重要。管理节点保存的是用户铃音订购关系、用户话单等重要数据，而呼叫节点的数据都是从管理节点复制而来，因此管理节点保存的数据更加重要。

从设备组成来讲，前置交换放音模块均为基于交换机改造的CT设备架构，稳定性较高；后台数据处理模块则是基于小型机、PC Server的IT设备架构，稳定性较之CT设备有一定差距。

综合以上对彩铃系统的安全性分析可以看出，彩铃系统的核心在于管理节点的中心数据库。如何保护好彩铃管理节点里存储的数据，保证其稳定可靠地运行，并为业务系统提供快捷可靠的访问，是彩铃系统安全重要的问题之一。

2 彩铃系统数据库容灾方案建议

2.1 彩铃数据库系统

彩铃系统的核心数据主要存储于数据库系统中。彩铃业务数据库系统主要包括管理节点的一个中心数据库和多个呼叫节点的呼叫数据库。

其中，管理流程访问中心数据库，呼叫流程分散在各个呼叫节点上，访问对应的呼叫数据库。呼叫数据库通过IP网络访问管理数据库，并将其中部分数据库表同步到呼叫数据库中，以供呼叫流程使用（如图2所示）。

图2 彩铃数据库系统组网

彩铃数据库容灾解决方案是通过建立一个包含特定软硬件的系统，来实现对彩铃管理平面的中心数据库的保障。

2.2 彩铃数据库容灾系统组成

彩铃数据库容灾系统主要由以下部分组成。

（1）生产系统：即当前业务使用的管理数据库系统；

（2）容灾系统：通常和生产系统处于不同的物理位置，通过网络与生产系统相连。当发生灾害时，能够迅速接管生产系统所有的业务，并能尽量保证数据不丢失。容灾系统的硬件设备可以和生产不同，但是操作系统和数据库版本必须一致。另外考虑到灾难后需要接管生产的应用，因此机器配置性能不应低于生产系统；

（3）容灾网络：容灾网络通常需要独立的数据传输通道以保障数据的同步要求，数据容灾的效率高低与容灾网络有密切关系。容灾网络的带宽可以通过采集主库系统忙时的redo增量进行计算；

（4）容灾技术：根据彩铃的业务特性及业界数据库容灾领域的经验，可以采用Oracle的DataGuard技术来实现数据库容灾。DataGuard是Oracle数据库的重要功能之一。Oracle在发生数据写操作时，会首先将数据写入日志文件（redo log）中。DataGuard技术正是利用了这一点，除将重做信息写到本地外，还写入到远程的容灾数据库中。容灾数据库通过不停的应用重做信息即可实现与生产系统的同步。使用DataGuard功能进行容灾对生产系统性能影响很小。

为了简化运维及容灾切换，还可针对彩铃特性开发容灾专用脚本。通过使用该脚本，可以有效加强数据库的容灾功能以及自管理功能。

2.3 彩铃数据库容灾典型结构

图3 彩铃数据库容灾系统典型结构

在管理中心机房，中心数据库的双机直接连入公共的生产网络提供数据服务，同时建立连接生产机房与容灾机房的容灾网络，以保证容灾系统与生产系统间的数据同步传输；各个呼叫节点机房的呼叫数据库仅接入生产网络即可。

在异地的容灾机房，容灾系统同时连入生产网络和容灾网络，以保证容灾系统接管生产系统后的数据访问。

生产数据库与容灾数据库均采用双机，采用DataGuard技术实现全库的容灾。

在实际组网中，容灾数据库可以新建，也可以与呼叫节点数据库合设。这两种方式在容灾功能上完全一致，都可以实现对生产数据库的容灾备份，所不同的是后者建设成本较低，一方面节约了新建容灾系统的软硬件成本，有效降低CAPEX；另一方面简化了彩铃系统的网元数量，减少运营维护成本，有效降低OPEX。

2.4 彩铃数据库同步模式

数据库容灾提供3种可选的同步策略。

（1）最多保护模式：提供最高程度的数据保护。生产系统数据库的redo信息只有成功传送到至少一个容灾数据库后，数据才能被写入数据库中。否则生产系统数据库将关闭，以避免与容灾数据库间产生数据差异。这种方式能保证数据的一致性，但是对生产系统数据库性能影响严重，有可能造成较大冲击；

（2）最大有效模式：提供次一级的数据保护。与上面模式的区别在于，当redo数据被判断为无法及时传送到容灾数据库时，生产系统数据库会临时将自己的级别降到最大性能模式，这样生产系统数据库仍然能正常工作。这种方式是在保证生产系统数据库有效性前提下的最高数据保护模式；

（3）最大性能模式：默认的数据保护模式。生产系统数据库不会等待信息到容灾数据库后再进行写操作。这种方式是在保证不影响生产系统数据库性能前提下的最高数据保护模式。

2.5 方案收益分析

2.5.1 大大提高业务连续性

通过数据库容灾，能够在核心的数据库系统故障后迅速接管业务，大大提高业务连续性，保障系统的连续运行。

2.5.2 高度保障核心数据安全

彩铃核心数据集中存储在管理节点的中心数据库中。通过中心数据库的异地容灾系统，可以把自然或人为的灾害对当前数据的损失降到最低，从而高度保障核心数据安全。

2.5.3 降低业务风险，提高操作效率

彩铃中心数据库是整个业务的数据核心，一旦出现故障影响很大。实现数据库容灾之后，通过对容灾数据库和生产数据库的交替操作，可以大大减少系统升级、补丁和重装系统等的计划停机时间，从而降低业务风险，提升操作效率。

2.5.4 提高彩铃系统性价比

通过对业务的深度分析，仅对最核心的中心数据库部分进行容灾，以较低的价格实现较好的容灾效果。在容灾数据库的建设上，硬件可以与生产系统合设，软件采用Oracle自带DataGuard功能，无需额外付费。

3 彩铃系统数据库容灾实施方案

容灾系统除了必要的软硬件之外，还需要完善、成熟的流程制度来确保其发挥最大的作用。因此，在完成了容灾方案设计、工程实施之后，相关的容灾切换、容灾测试等也是必不可少的。

3.1 数据库容灾切换方案

3.1.1 IVR管理流程

在正常情况下，IVR管理流程访问管理节点，数据库采用管理节点的数据库。当管理节点数据库发生灾难时，修改VXML/Web Portal/USDP的数据库配置，指向容灾数据库。

3.1.2 呼叫流程

在正常情况下，呼叫流程访问管理节点，数据库采用管理节点的数据库。当管理节点数据库发生灾难时，通过MMP修改管理节点的CTI的aplogic配置，将引用的数据源由原来的生产数据库改为容灾数据库。

3.1.3 Web/Wap业务

管理节点的Web Portal/USDP/VXML/GW正常情况下都挂在管理节点的F5下面，Portal Server使用1个VIP对外，在生产节点防火墙上NAT成公网地址。当生产数据库发生灾难时，修改VXML/Web Portal/USDP/GW的数据库配置，指向容灾数据库。

3.1.4 USDP/GW

管理节点的Web Portal/USDP/VXML/GW正常情况下都挂在管理节点的F5下面。当生产数据库发生灾难时，修改VXML/Web Portal/USDP/GW的数据库配置，指向容灾数据库。

3.1.5 SMS

USDP和短信之间的连接是由USDP发起，所以数据发生灾难时，对短信无影响。

3.1.6 数据库同步

如果数据库是正常的switch over，需要修改同步节点的dblink，指向容灾管理数据库；

如果数据库是异常的fail over，则需要重新建立由同步节点到容灾数据库的同步环境。

3.1.7 总结

在生产数据库发生故障的时候，需要按照下面的步骤来恢复业务。

（1）手工将生产数据库切换到容灾数据库；

（2）修改 VXML/Web Portal/USDP 的数据库配置，指向容灾数据库；

（3）通过MMP修改生产管理节点的CTI的aplogic配置，将引用的数据源由原来的生产数据库改为容灾数据库；

（4）如果数据库是正常的switch over，需要修改同步节点的dblink，指向容灾管理数据库即可；

（5）如果数据库是异常的fail over，则需要重新建立由同步节点到容灾数据库的同步环境。

3.2 数据库容灾测试方案

根据故障情况，按照容灾切换方案进行切换操作，操作完成后进行业务测试和验证，确保容灾切换顺利完成。

（1）各节点呼叫流程能听到定制的彩铃；

（2）管理流程IVR能够接入；

（3）GW能正常访问中央音乐平台；

（4）用户能访问Web页面，并正常完成开销户、下载；

（5）用户能收到提示短信，并通过上行短信能完成开户下载操作。

4 结语

彩铃系统是一个复杂而重要的系统，数据库存储着业务所需的所有关键信息，对核心数据进行完善、有效的保护是非常必要的。通过数据库容灾，可以大大提高彩铃的业务连续性，并有效保障彩铃核心数据安全。

容灾系统的建设，不仅要考虑容灾的需求，还要综合考虑经济性、可操作性和易管理性，结合彩铃系统的实际情况，选择最为科学的建设方案。容灾系统建设完成后，还需要制定科学的切换方案和测试方案，以确保系统发挥最大的作用。