电信核心业务系统容灾解决方案_电信_计费

电信核心业务系统容灾解决方案

Oracle 技术产品咨询顾问高壮志 2004/05/24

　　随着电信运营商多年的系统建设，其核心业务系统的高可用性越来越受到人们的关注。从整个系统的角度来看高可用性，包括主机、操作系统、数据库、应用、网络设备等许多方面。而这些系统的一个显著特点就是以数据为中心，因此对数据的保护是整个系统高可用性的核心体现。Oracle数据库作为电信运营商核心系统的主流数据库，针对企业用户的重要数据、重要业务高可用性的需求提出了建立在数据库级别的容灾方案-- Oracle Data Guard （数据卫士）。

为什么要使用Data Guard
　　电信行业现有系统在容灾方面基本上有两种做法。一是采用备份的方法，即定期地将数据备份到硬盘和磁带上。这种方法的缺陷是实时性较差，恢复时间较长；另外备份设备和生产系统一般都处于同一物理位置，不能满足异地容灾的要求。另一种做法就是硬件镜像的做法，这种做法在硬件投资上较大，对两点间网络带宽有较大要求。鱼和熊掌，可否兼得？下面让我们来看看Oracle Data Guard解决方案。

Oracle Data Guard
　　Oracle9i Data Guard 维护了一个或多个与客户生产数据的同步备份。Oracle9i Data Guard配置包括一个松散连接的系统集合，由一个生产数据库和若干备用数据库组成，形成一个独立、易于管理的数据保护方案。现有运营商的核心业务系统的数据库在物理位置上往往位于省信息中心或计费中心的机房内，如果在同一城市有其它机房或利用其它城市机房部署同步备份的数据库，通过Oracle网络服务连接到一起，就可以构成一个很好的容灾解决方案。在修改主数据库时，对主数据库更改而生成的更新数据即发送到备用数据库，这些更改在备用数据库被重新应用。当生产数据库出现故障时，备用数据库可以继续提供服务。

图1提供了一个例子。

图1简单的双工作区配置

　　由于只是日志文件在主备用数据库之间的传送，其对应用程序是透明的，所以不需更改现有应用。由于核心业务系统的负载很大，所以我们也会非常关心这种数据同步是否会对生产数据库产生影响？实际上，生产数据库和备用数据库之间数据同步的方式有同步和异步之分，我们可以配置备用数据库使其对主数据库的性能几乎没有任何影响。由于仅对生产数据库所做的更改才发送到备用数据库中，因而这样的应急方案相对于镜像所有数据库文件记录的方式来说，能够与高事务处理率保持同步，在很大程度上降低了网络流量。

　　Oracle8i和Oracle9i的第一个版本只支持物理备用数据库，在Oracle9i的第二个版本革命性地引入了逻辑备用数据库。物理备用数据库和逻辑备用数据库的主要区别在于备用数据库得到日志文件后，如何应用日志文件(见图2)。

图2 Physical Standby & Logical Standby

　　物理备用数据库在应用日志文件时，是基于数据块级别来进行。因此，要求备用数据库和主数据库具有相同的物理结构，而且备用数据库只能处在恢复状态和只读打开两种状态中的一种。而逻辑备用数据库在应用日志文件时，首先将其转化为SQL语句，然后再进行同步应用。因此，逻辑备用数据库一直处于打开状态，在应用日志文件的同时，可以同时读取数据（见图3）。

图3

　　逻辑备用数据库与主数据库只要求逻辑结构相同，因此，还可以建立自己的数据库对象，进行读写操作。这样备用数据库就可以分担一部分主数据库的负载，如生成报表、备份等，在一定程度上提高了用户的投资回报。

　　Oracle9i Data Guard中主数据库和备用数据库的角色切换有两种方式：Switch Over和Fail Over。Switch Over使用于计划内宕机的情况，如主数据库进行硬件和操作系统的升级，Switch Over可以在不产生数据丢失的情况下，可逆地切换主数据库和备用数据库的角色。切换后，备用数据库成为主数据库，主数据库自动成为备用数据库。在需要时，还可切换回来。如果发生计划之外的故障，就需通过Fail Over进行角色切换，使备用数据库担当起主数据库的责任。这时主数据库不会自动成为备用数据库，并且需要一些手工操作来进行恢复。

　　每笔电信业务以及计费对生产数据库中的数据做出修改时，Oracle9i数据库将在一个联机重做日志文件中记录此次更改。在Data Gurard中可配置写日志的这个过程，在大的方面可分为同步方式和异步方式。所谓同步方式就是在提交对生产数据库所做的修改时，要求此次修改已在备用数据库被应用，在生产数据库的操作才能成功。异步方式是通过维护一个本地缓存，当积累到一定程度时才将日志传送到备用数据库，在提交事务时不受备用数据库的影响。可以看出同步方式可更有效地保护数据不丢失，但会对生产数据库的性能有一定影响。异步方式则对生产数据库的性能影响很小，但会存在一定数据丢失的可能。

　　Oracle9i第二版提供了三种模式来完成备用数据库的日志传送，通过一些设置选项，使其可针对不同级别的可用性进行设置。让我们来看看这三种模式的情况，以及哪些模式适用于我们电信行业的业务系统（见图4）。

图4

·最大保护模式
　　最大保护模式为主数据库提供最高级别的数据可用性。它保证在主数据库提交的事务可在备用数据库恢复并可用。当所有的备用数据库都不可用时，主数据库的处理会自动挂起，保证主数据库和备用数据库之间不会出现不一致。

　　在以最大保护模式运行时，日志写进程（LGWR）负责将日志记录从主数据库传送到备用数据库，在没有得到传送数据已在备用数据库可用之前，主数据库的事务不会提交。这会在某种程度上影响主数据库的性能，但最大程度地保护了数据的一致性。

　　当主数据库出现故障时，因为所有在主数据库提交的事务都已在备用数据库同步，所以不会有数据丢失。

·最高可用模式
　　最高可用模式也为主数据库提供了高级别的保护，同最大保护模式相比，当备用数据库不可用时，主数据库不会挂起，而是降为最大性能模式。由于主数据库仍在继续运行，主数据库和备用数据库之间会出现数据不一致的情况。这种模式也是一种同步模式，日志写进程（LGWR）负责将日志记录从主数据库传送到备用数据库，在没有得到传送数据已在备用数据库可用之前，主数据库的事务不会提交。

·最大性能模式
　　最大性能模式是缺省的保护模式，它是一种异步模式。在正常操作过程中，主数据库不会确认数据是否已经在备用数据库可用，就继续进行本地操作。如果备用数据库出现故障，主数据库的处理也不会挂起，因此它对主数据库的性能影响很小。

　　最大保护模式保证了生产数据库和备用数据库的一致性，但带来的问题是，如果备用数据库或网络出现问题也会造成生产数据库的不可用。因此，建议采用多个备用数据库，只要有一个备用数据库可以同步数据，生产数据库依然可用。从现有电信行业容灾建设的情况和业务特点来看最高可用模式和最大性能模式更贴近现状，尤其是最大性能模式对生产数据库的性能影响很小。

实际使用情况
　　在这里简单介绍一个某省移动公司帐务系统采用Oracle Data Guard物理备用数据库的情况（见图5）。

　　这是一个典型的将Oracle集群数据库RAC和Data Guard相结合的容灾方式。在主数据库采用四个节点的集群数据库（RAC），数据存放在共享的裸设备上。集群数据库针对服务器故障提供了保护，并可分担负载，在此基础上，采用异步物理备用数据库来保护数据，其中日志传送的间隔平均为半个小时，主数据库的数据量在1TB左右。

结束语
　　"居安思危"这句成语同样适用于我们电信行业核心业务系统的建设，随着电信行业竞争的加剧，电信运营商在推出各种业务服务用户的同时，如何建设和完善自己内部的核心业务系统，提供可靠的业务保障，Oracle Data Guard正是针对核心业务系统高可用性的需求，从数据库角度提出的解决方案。

中国计费网(www.billingchina.com)