河北省地税11地市数据集中上收及异地容灾备份方案

ydrz5753

1           需求分析
1.1         项目概述
河北省地税税收业务系统目前采用了在各市局分散应用模式，即十一个市局分别有各自的数据中心，负责税务征管和帐务处理。
为了实现对关键业务数据的异地容灾备份，同时实现数据的省级集中用于决策支持系统的数据源，需要在省局建立各市局数据的准实时备份。
同时为了在各市局本地提供查询业务，要求复制到本地另一台服务器上一套税务征管数据用于查询。
1.2         建设目的和建设内容
（一）省中心数据上收系统
该系统提供以下3种功能：
提供数据备份：将11个市局和省直属局的业务数据同步到省局，作为各市局本地备份的补充，当市局数据发生破坏时，可通过省中心的备份数据进行恢复；
提供业务接管：当市局的业务系统有灾难发生而不能在规定的时间内恢复的时候，可以通过省中心的备用系统暂时接管该市局的关键业务，以保证业务的连续性为目的。
数据利用：11个市局和省直属局同步到省局的数据，将作为省中心的数据仓库系统的数据源。
（二）本地报表系统
在市局本地再复制产生一套税收征管数据，用于本地数据查询和报表业务。
1.3         系统现状及应用环境
（一）市局业务系统概况
每个市局由两台IBM服务器组成高可用性架构。在该高可用性架构上运行了税务征管和帐务处理两套系统。每套系统分别运行在1台服务器上，每套系统各自运行一套ORACLE 9i数据库。在正常情况下，两台服务器各自运行税务征管和帐务处理系统。当其中一台服务器出现故障时时，由另外一台服务器接管该服务器上的业务。
各地的数据量为20GB左右。
（二）网络环境概况
每个市局业务系统内部组成100Mbps网络环境，连接市局两台服务器和其他外部配套设备；
目前市局和省中心之间已经实现网络互通，11个市局与省中心的网络连接带宽均为2Mbps。
市局与省中心之间通过防火墙实现隔离；
（三）省中心系统概况
为了实现河北市局本期工程，在河北地税省中心已经购买了多台IBM P690服务器，磁盘阵列和相关的管理软件。
为了实现省中心的数据复制，已经从一台IBM P690上划分出一个逻辑分区用于对11个市局的数据集中。该分区的配置为CPU：3颗、内存：8GB。
2           方案设计
2.1         总体结构
根据河北地税数据复制系统的业务需求，我们建议采用DSG RealSync软件实现数据复制：
系统总体结构如下图所示：
2.2         地市生产系统组成
地市生产中心由石家庄、保定、唐山、刑台等11个地市的征管系统组成。
每个市局由两台IBM服务器组成高可用性架构。在该高可用性架构上运行了税务征管和帐务处理两套系统。每套系统分别运行在1台服务器上，每套系统各自运行一套ORACLE 9i数据库。在正常情况下，两台服务器各自运行税务征管和帐务处理系统。当其中一台服务器出现故障时时，由另外一台服务器接管该服务器上的业务。
每个市局业务系统内部组成100Mbps网络环境，连接市局两台服务器和其他外部配套设备；
目前市局和省中心之间已经实现网络互通，11个市局与省中心的网络连接带宽均为2Mbps。
市局与省中心之间通过防火墙实现隔离；
2.3         省中心系统已有设备
在河北地税省中心已经购买了多台IBM P690服务器，磁盘阵列和相关的管理软件。
为了实现省中心的数据复制，已经从一台IBM P690上划分出一个逻辑分区用于对11个市局的数据集中。该分区的配置为CPU：3颗、内存：8GB。
2.4         复制软件的配置和部署
为了实现河北地税的数据复制需求，我们推荐采用DSG RealSync产品。该产品的配置和部署包括：
(一)数据上收系统
根据业务需求，数据上收系统是将11个地市征管数据库上的数据实时复制到省中心的集中数据库上，集中数据库起到备份、业务接管和数据利用三个目的。
为了实现该功能，需要以下配置：
ü         需要在11个地市的征管数据库服务器上每台服务器上安装一个用于数据上收的realsync agent程序。
ü         需要在省中心的集中数据库服务器上安装一套realsync agent，但启动11个端口(port)，每个端口对应一个地市系统。
ü         在省中心的服务器上安装一套oracle系统，分成11个user，每个user对应一个地市征管系统。
（二）本地报表复制系统
根据业务需求，除了提供省中心的数据上收之外，还需要在本地的服务器上复制一份报表系统。即在地市的帐务数据库上再新增加一个user，将征管库上的数据实时复制到帐务库上的新增加user下面。从而将报表功能部署到帐务数据库服务器的数据库上。
为此，需要配置的DSG RealSync软件模块包括：
ü         需要在11个地市的征管数据库服务器上每台服务器上安装一个用于本地复制的realsync agent程序。
ü         需要在11个地市的帐务数据库服务器上每台服务器上安装一个用于本地复制的realsync agent程序。
以上配置详细模块参见《软件配置清单》
3           业务功能实现
3.1         数据上收功能
根据业务需求，省中心数据上收系统需要提供以下3种功能：
ü         提供数据备份：将11个市局和省直属局的业务数据同步到省局，作为各市局本地备份的补充，当市局数据发生破坏时，可通过省中心的备份数据进行恢复；
ü         提供业务接管：当市局的业务系统有灾难发生而不能在规定的时间内恢复的时候，可以通过省中心的备用系统暂时接管该市局的关键业务，以保证业务的连续性为目的。
ü         数据利用：11个市局和省直属局同步到省局的数据，将作为省中心的数据仓库系统的数据源。
3.1.1                数据备份
在本方案中采用DSG RealSync实现了多对一的容灾结构，各地市将数据统一复制到省数据中心的一台容灾数据库，每个地市在数据库中对应一个用户；
正常情况下各地市的数据可互不干扰的复制到省中心容灾数据库；
在某一地市发生灾难数据丢失时，可在省中心以用户的方式反向复制该地市的容灾数据，最大程度的避免了数据的损失。
采用DSG RealSync解决方案不存在源系统在极端情况下（如掉电、站点失败）灾备数据库无法访问的风险，因为容灾系统的数据库一直处于运行状态，实际上是对数据风险的有效控制。
3.1.2                业务接管
由于在省中心的复制数据库上拥有11个地市的征管库中所有的数据，当某个地市征管系统发生严重故障而无法在短期内修复时，可利用省中心的备份数据以及省中心的备用服务器来临时接管出现故障的地市。具体过程如下：
ü         将省中心复制数据库中对应用户下的数据装载到备用服务器的数据库上；
ü         切换地市应用连接到省中心备用数据库上，恢复业务运行；
ü         当地市系统修复后，将省中心备用数据库上的数据恢复到地市数据库上；
ü         将地市应用切换回到地市服务器上。
3.1.3                数据利用
采用DSG RealSync容灾技术的非常明显的优势还在于省中心集中数据库一直处于open状态，可以对省中心数据库进行实时访问，系统保持生产中心和灾备中心的数据库处于双激活状态；可以从技术上保障目标数据库在线可用，容灾数据库的数据实时可读取，复制过程和数据读取不产生矛盾。RealSync的复制延迟很小，从容灾数据库读取到的数据是实时最新数据，这样可以为省中心的数据仓库系统提供了ETL操作的数据源。
3.2         本地报表功能
同样，在本地系统上，我们配置了从征管系统复制到帐务系统上的支持，那么帐务系统上实际上具有了一个征管系统的副本数据，通过该数据可以完成征管系统上的所有报表、查询业务。
3.3         网络需求
RealSync对数据传输采用TCP/IP网络传输。
RealSync复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。RealSync只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3 .
例如用户峰值每小时生成的日志量为720M。
实际峰值期间每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3=720/3=240M
考虑20%的传输开销，所需要的带宽为240*1.2/3600=80KB/S,系统对传输带宽的要求为640kbps。
3.4         性能和稳定性
3.4.1                对源系统的影响
DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为5个百分点，对内存资源的占用为几十M至100M。
当容灾中心暂停或传输异常中断导致复制停止时，RealSync会将数据库的变化内容存储在源系统或目标系统的队列中，当系统恢复后，RealSync会自动识别复制环境，自动从断点处开始复制工作。在上述过程中，主中心的业务不受任何影响。数据的一致性不会破坏。
当复制环境停止的情况下，需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。例如用户峰值每小时生成的日志量为720M。需要容错24小时。
容错期间需要处理的日志量=每小时日志文件切换的数量*日志文件的大小*1/3＊24=240M*24=5.76G
在网络中断情况下，考虑数据暂时存放在源系统24小时所需要的存储空间。按照50%的存储开销计算，所需要的空间为5.76*1.5=8.64G，也就是说，对于每小时产生720M日志的数据库系统，在保存24小时传输内容的情况下，需予留8.64G的存储空间。
3.4.2                数据延迟
RealSync是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。
3.4.3                复制环境的健壮性
推荐解决方案具备足够的健壮性。源系统和目标系统的任何故障都不会影响到复制环境。在以下故障发生时，RealSync故障处理方法如下：
源系统主机故障：源系统主机故障修复后，当Oracle数据库和操作系统重新启动后，RealSync自动重试连接数据库，并从断点继续进行复制工作。
数据库故障：当源系统数据库故障修复后，当Oracle数据库重新启动后，可以从断点继续进行复制工作。
复制软件故障：复制软件在源系统有三个进程，目标系统有两个进程。当复制软件的进程遇到问题时，可以自动重起相关进程。
网络故障：当网络恢复后可以自动从断点进行复制工作。
目标系统的主机故障：数据存储在目标系统队列中，当目标系统主机故障修复后，从断点继续进行复制工作。
数据库故障：数据存储在目标系统队列中，当目标系统数据库修复后，从断点继续进行复制工作。
3.4.4                事物的完整性和可用性
RealSync是一个数据库级的软件解决方案，其复制的基本单位就是一个事务(Transaction)，RealSync在从oracle log中读取到交易数据后，根据交易的关系，将属于一个事务的所以操作组合在一起，以一个基本单位发送给目标端，目标端在执行时也严格按照交易进行，因此严格保证了交易的完整性。
对于事务与事务之间的顺序，RealSync严格按照ORACLE 的SCN标记进行排序。确保事务之间的先后秩序。
3.5         数据一致性检查
对于ORACLE而言，数据一致性的检查主要通过数据库的SQL接口读取记录进行对比的方式进行。而这种比对方式耗时巨大，效率十分低下，如果对于一些没有主键的表就几乎无法比较。
DSG在数据一致性校验的检查机制方面做的尤为突出，并且使得这一需求变得可行。在其它同类产品中，DSG RealSync不是通过select接口来读取数据并进行比较，而是通过批量读取的方式从数据库底层直接读取记录，并通过rowid的对应关系来定位记录，并通过数据源的记录值、ROWID，目标端的记录值、ROWID，以及realsync所记录的ROWID映射关系来比较双方的记录是否一样。
这种方式省却了大量的从select接口查询记录的资源占用和时间消耗。并且能够比较到每条记录，能够清晰定位不一致的记录。无论被比较的表含有主键或者没有主键，都能进行比较，并且比较的性能一样。
3.6         系统初始化的实现
复制环境的建立，首先需要将生产系统中的已有数据初始化同步到目标系统上，同时记录各种系统状态和映射关系等。因此如何快速、有效的建立复制的初始化环境是每个复制系统都非常关心的问题。
在传统办法中，数据首次同步过程大都采用Oracle的EXP/IMP工具，将源端数据库数据抽取出来，通过网络传输至目标端数据库进行加载。或者是借助第三方的备份软件工具，将源端的数据进行备份，再通过磁带运输至目的地，将磁带数据恢复到目标数据库，从而达到首次数据同步的目的。
这种方式存在大量的问题：
（1）       性能低下：通过Export/Import方式，最大的问题在于性能很慢，对于一个几十GB的数据库，进行一次export/import，则大约费时8－10小时以上。
（2）       完全需要手工干预：数据的导出（Export），传输和装载（Import）等过程都需要手工干预和执行。
（3）       业务必需停止：在执行export/imp过程中，业务必需中断。
（4）       易出错：尤其在Import过程中，由于表之间的关联性存在，往往出现由于违反参照完整性规则而导致装载中断，非常难于操作。
而DSG在数据的一致性同步方面有着非常好的解决方案，这是其它方案所不具备的。DSG的RealSync集成有数据的一致性同步工具，能够自动化的进行数据的首次同步和出现差异情况下进行一致性同步的工作，无需人工干预，维护工作量小，且大大提高了工作效率：
（1）       速度快：
（2）       完全自动化：
（3）       不中断业务：在DSG Realsync在进行首次数据装载时，无需停止源端业务，实现不停机的系统初始化；
3.7         灾难恢复流程
在生产数据库系统发生灾难的情况下，此时可使用容灾数据库首先接管业务，然后进行数据的反向恢复。具体步骤为：
（1）       生产数据发生灾难，生产端业务停止；
（2）       修改TNS的指向，将数据库指向灾备中心的数据库；
（3）       应用系统重新连接灾备数据库，完成业务接管；
（4）       排除生产系统的故障；
（5）       启动生产系统的oracle数据库
（6）       反向恢复生产系统数据
（7）       修改TNS指向，将数据库指向生产中心的数据库；
（8）       应用系统重新连接生产中心数据库，完成业务回切；
（9）       配置realsync进行正向复制；
以上过程是利用灾备中心的系统首先接管业务后，再进行生产中心的修复和数据的反向复制，因此不会造成长时间的业务中断。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/71502/showart_1008570.html