容灾中心方案建议书.doc

XX省XX公司BOSS容灾系统技术建议书XXX公司（V1.5）二期扩容改造及容灾工程项目容灾中心技术建议书YY公司科技（中国）有限公司2004年11月目录1.前言32.容灾方案概述32.1.容灾整体模型32.2.容灾地点选择32.3.容灾方案指标32.3.1RPO32.3.2RTO32.4.容灾技术32.4.1数据复制技术32.4.1.1数据复制分类32.4.1.2基于存储的复制技术32.4.1.3基于卷的复制技术32.4.1.4 基于数据库的复制技术32.4.1.4.1全库复制32.4.1.4.2表级复制32.4.1.4.3 针对Oracle数据库的第三方产品32.4.1.5基于应用的复制技术32.4.1.5.1基于Log的应用复制实现方式32.4.1.5.2基于Log的应用复制实现方式对应用系统的要求32.4.1.5.3基于应用系统的复制方式特点32.4.1.6复制技术比较32.4.2 数据恢复技术32.4.3网络切换技术32.4.3.1切换目标32.4.3.2浮动IP地址方案32.4.3.3智能DNS方案32.4.3.4 L4 Switch方案32.4.4应用系统切换技术32.4.4.1容灾切换方式32.4.4.2切换流程32.4.4.3自动化切换程序32.4.5资源复用技术32.4.5.1资源复用的意义32.4.5.2资源复用的技术手段32.5容灾级别选择32.5.1数据级容灾32.5.2应用级容灾33.容灾需求分析34XX省XX公司BOSS系统容灾方案34.1营帐系统容灾方案34.1.1营帐系统生产中心配置34.1.2营帐系统灾备中心配置34.1.3营帐系统数据复制方案3方案一3方案二34.1.4营业系统数据恢复方案34.1.5营业系统网络切换方案34.1.6营业系统应用切换方案3部分切换方案3全部切换方案3系统回切方案34.2计费系统容灾方案34.2.1计费系统生产中心配置34.2.2计费系统灾备中心配置34.2.3计费系统数据复制方案34.2.4计费系统数据恢复方案34.2.5计费系统应用切换方案34.3帐务系统容灾方案34.3.1生产中心帐务系统配置34.3.2灾备中心帐务系统配置34.3.3帐务系统数据复制方案34.3.4帐务系统数据恢复方案34.3.5帐务系统应用切换方案34.4结算系统容灾方案34.4.1 结算系统生产中心配置34.4.2 结算系统灾备中心配置34.4.3结算系统数据复制方案34.5数据备份方案34.6网络方案35容灾管理系统AIDRM35.1AIDRM软件体系结构35.2软件功能模块35.2.1系统管理35.2.2软件版本管理35.2.3应用切换控制36容灾管理规范36.1恢复规划设计36.1.1目的36.1.2恢复规划文档的制定策略36.1.2.1紧急处置流程36.1.2.2组建灾难恢复小组36.1.2.3灾难事件通知36.1.2.4灾难识别与级别判断机制36.1.2.5异地中心接管36.2测试36.2.1测试的目的36.2.2测试计划的内容36.2.3测试的类型36.2.3.1数据验证计划36.2.3.2模拟运行计划36.2.3.3 IT系统变更36.2.3测试的流程36.3演习36.3.1目的36.3.2演习内容36.3.3演习的实施流程36.4维护36.4.1目的36.4.2维护规划内容3维护实施流程包括37总结31. 前言甚至仅仅在几年以前，我们都无法想象存储在硬盘等设备上的数据会在一个企业运营中占据如此重要的地位。现在可以毫不夸张地说，一个企业若部分或完全丢失的数据，也就丢失了一切。中国有句古话叫做“天有不测风云，人有旦夕祸福”，说明灾难的不可测性。911事件是对这句话的最好注解。从911事件中我们可以吸取的教训是一定要建立核心数据和业务的容灾系统，并且平时要加强管理和演习，加强人员的培训，核心管理技术的分散，以提高计算机系统因为天灾或人为因素等意外事故导致系统毁坏无法运行时的抵御能力，至少将省内或者局部地区核心业务支持系统故障时损失减至最小。有许多计算机系统内部以及计算机所处环境中的潜在因素可能会造成数据丢失情况的发生。据不完全统计，造成数据丢失的事件中，n 软硬件和网络故障占11左右n 断电和电源故障占50左右n 火灾地震爆炸和雷电等灾害占18左右n 人为因素占17左右n 其他因素占4左右。随着XX省XX公司BOSS系统集中的完成，所有关键业务数据和应用系统全部集中到了一个生产中心，其数据量有巨大增加，对主机和存储设备都造成了较大的压力。如此庞大的数据集中在一个中心，一旦发生意外，企业的商业信誉必将受到致命的打击，在竞争中处于劣势，造成不可估量的后果。在本方案中我们最强调XX省XX公司BOSS系统数据的完整性和可用性，在此基础上我们再考虑投资规模和投资保护。XX省XX公司业务运营支撑系统主要面临的风险有：计划内n 应用软件等的升级,n 备份/恢复/归档n 数据中心迁移、整合n 测试、容灾演习计划外n 系统处理能力下降n 人为操作故障：错误删除文件数据，造成不可恢复；错误执行程序或命令，造成系统死机n 系统软硬件故障，主要包括电源及UPS故障、硬盘故障、通讯控制器故障、系统总线、内存、CPU故障等n 安全体系被攻破n 生产地点的灾难：水灾、火灾、地震及其他机房事故等n 其它：包括灾难的潜在影响，如水灾、地震等， 常伴随着电力的供应问题。2. 容灾方案概述2.1. 容灾整体模型XX省XX公司容灾系统的建设，可以按照需求分析、方案设计、方案实施、测试/演习/维护的科学流程进行。特别应该提到，容灾系统的建设不仅仅是考虑技术实现手段，技术应该只是整个系统中的一个环节。要想真正达到容灾的目的，必须充分考虑人员、流程等因素，参考以下模型：业务运营支撑网业务连续性系统建设模型人员、流程和技术是保证容灾系统成功实施、有效运行的三个重要方面： n 技术，是手段、是载体；n 流程，是技术的补充和完善。包括恢复、测试、演习和维护等；n 人员，是技术和流程的制定者和执行者。人员、流程和技术通过管理机制有效结合。管理机制包括计划、映射、驱动、调控等手段。2.2. 容灾地点选择确定生产中心与异地中心之间的距离是容灾系统建设方案选择的受限需要考虑的问题。两个中心的距离越远，两个中心之间共同依存的因素就越少，可预防灾难的种类就越多，但当距离超过一定量时，容灾系统所采用的技术、项目的实施难度以及系统建成后的管理和维护难度将发生质的变化，归结到一点，即项目成本将发生重大的变化。因此，在地点选择过程中，应仔细权衡系统目标和方案成本之间的关系。当然，从现实情况出发，地点的选择首先要有满足要求的异地机房。异地中心应符合数据中心需求。n 机房环境符合要求。n 局域网（LAN）基础设施和广域网（WAN）出口完备n 本地伺服电力设备和配线基础设施满足要求n 设备安全和通道控制满足要求n 灾难切换后，人员工作条件满足基本要求n 交通设施（例如停车场和通道）和个人支持服务满足要求n 备用地点的技术支持的可用n 管理支持服务的可用另外在选择异地中心时， 应该避免如下因素：n 邻近机场n 邻近化工厂n 邻近天然气n 邻近铁路/运输公路n 邻近电磁、电波干扰源n 地势很低的地区n 邻近大海n 高层建筑物n 交通拥挤的地区n 邻近军事演习区域n 火源（临近餐厅、高压电等）n 地质状况(地震、地裂、火山等等)n 工业企业n 配套环境恶略（交通、 通信、服务等）n 与生产中心位于同一性质的地域（如，同为目标显眼的区域-政治中心、金融中心、商业中心等）生产中心和灾备中心距离的远近直接影响到数据的复制效率、复制方式和复制成本。对于不同的灾难所要求的距离也是不一样的。举例说明如下：n 火灾：同城异址，通常距离超过5公里就足够n 地震（地裂、火山等等）：不同的城市，距离越远影响越小n 战争：不同的城市，距离越远影响越小n 水灾：不同地理特点的城市n 断电：不同的城市n 计划内停机：对距离没有要求n 人为操作故障：对距离没有要求n 系统处理能力下降：对距离没有要求n 系统软硬件故障：对距离没有要求n 安全体系被攻破：对距离没有要求2.3. 容灾方案指标2.3.1 RPO数据容灾需要重点考虑的一个参数是RPO。RPO参数的不同，直接影响到数据同步所采集的技术手段及相应成本的高低。恢复数据目标（Recovery Point Objective- RPO）是灾难发生后业务能够容忍的数据丢失量；或者说灾难发生造成的数据丢失量。一般来说，恢复数据目标（RPO）越高（即，丢失的数据越少），方案的成本越高，但是由于灾难造成的业务损失就越小；反之，恢复数据目标（RPO）越低（即，丢失的数据较多），方案的成本较低，但灾难造成的业务损失也较大。不同类型的数据所需要的RPO也是不一样的。比方说和钱的数量发生直接关系的数据就要求非常高的RPO，甚至是0数据丢失。而对于如统计类数据则可以要求低一些。同时，可以通过某种途径让数据重生的数据所要求的RPO可以低一些，而不可重生的数据则要求就高一些，比如说某些数据的采集可以通过重采手段获得，有比如说，客户的业务受理数据可以通过营业厅保存的受理纸介质进行数据恢复。数据保护主要目的有两个：第一是在生产数据发生逻辑故障（如人为误操作、病毒破坏等）或后台业务处理（如磁带备份、新软件测试、报表生成、统计分析等）而影响业务系统的运作之前，生成定点拷贝；第二是在生产运行过程中，连续不断地将生产数据复制到异地，应对生产中心的灾难对生产数据的整体或局部物理性损坏。2.3.2 RTO对于应用级容灾RTO是一个非常重要的参数，决定的因素也非常多。恢复时间目标（Recovery Time Objective- RTO）是灾难发生后业务能够容忍的停顿时间；或者说灾难发生后，恢复业务运行所需要的时间。一般来说，恢复时间（RTO）越短，那么灾难恢复方案的成本就越高，但是由于灾难造成的业务损失就越小；反之，恢复时间（RTO）越长，灾难恢复方案的成本较低，但是由于灾难造成的业务损失就较大；2.4. 容灾技术容灾系统建设中主要涉及的技术问题包括以下几个方面：l 数据复制技术l 数据恢复技术l 系统切换技术l 资源复用技术下面就这些技术问题分别论述。2.4.1 数据复制技术2.4.1.1 数据复制分类容灾的主要技术难点在数据复制实现，就是说如何保持主备节点的数据同步，包括应用软件、数据库、业务数据等方面。数据复制设计需完整考虑以下方面：完整性：对维持业务正常运行的所有生产数据进行保护。可以采取两种策略：分而治之或统一解决。分而治之即对生产数据的不同组成部分采用不同的方法，如对操作系统软件和数据库数据分别采用不同的方法；统一解决即用一种方法保护所有的生产数据。虽然两种方法都能实现完整性，但统一解决方法独立性强、易于扩展、维护，而且易于实现以下的一致性、管理性等指标。一致性：保证被保护的生产数据的各部分的业务逻辑上的一致。可以采取事后一致性检验和事前同一时间点生产数据冻结技术。事后一致性检验技术主要针对分而治之的完整性实现方法，在保护生成后验证各部分数据的逻辑一致性；事前同一时间点生产数据冻结技术对生产数据各部分在同一时间的映像进行保护，主要针对统一解决的完整性实现方法，从数据各部分之间时间上的同步性实现业务逻辑一致性。可验证性：针对备份或复制的数据，具有事先验证手段。可验证性保证在需要利用保护介质恢复业务状态时，可顺利读出生产数据、恢复业务状态。时效性：生成完整的生产数据的保护工作进行频率。频率越高，时效性越强，在业务终止时，不能恢复或需要人工恢复的数据就越少，业务就越易于准确的恢复，业务的停顿时间和相关的损失就越少。可扩展性：生产数据保护机制随着IT基础结构和业务的变化而不断扩展、适应的能力。可扩展性的优劣将决定保护机制的可持续发展能力和投资保护能力。可操作性：在保证完整性、一致性、可验证性、时效性、可扩展性的前提下，所选择的技术手段的技术复杂度、可实施能力。可重用性：所生成的生产数据的保护的多重利用能力。生成生产数据的保护会占用IT的一部分资源，在利用其恢复业务状态之前，利用其进行其他任务，如磁带备份、软件测试、报表生成、统计分析将充分发挥这部分IT资源的价值。可管理性：监控业务状态的保护机制的运行状态、运行性能、故障处理的能力，保证其按照设定的保护要求运行。集成性：业务状态的保护机制与业务的运行和恢复机制的整合性。整合性高地决定保护机制是否可顺利和业务当前运行体系良好配合，以及当业务中断时，如何和业务处理能力恢复系统一起顺利恢复业务的运行。从一个应用系统的构建基础看有以下各层次，数据在不同层次上均有相应复制技术实现。在存储系统一级包括磁盘阵列和逻辑卷管理系统称作基于存储系统的复制；BOSS系统一般都是基于数据库的应用，所有主要的数据都是存放在数据库中的，通过数据库技术复制的方式称为基于数据库的复制；除了以上2种方式外，复制还可以在应用系统上作，称为基于应用的数据复制。2.4.1.2基于存储的复制技术磁盘系统利用自身的处理能力，通过磁盘系统之间的通道连接复制磁盘系统内的数据更新，从而在异地中心保存生产数据的记录。磁盘系统是信息的真正所在地，利用磁盘复制可以独立于服务器、操作系统、卷管理系统、数据库、文件系统、中间件、应用程序。磁盘系统数据的物理构成单位为扇区（Sector）、簇（Cluster）、磁道（Track）、柱面（Cylindar）、卷（Volume）。一般基于卷建立磁盘复制的对应关系，复制过程中的数据传输单位可能为簇、磁道或柱面。一个典型的存储方案可以总结为以下结构：数据复制可以通过网络连接、存储交换机连接、磁盘阵列连接三种方式实现备份。支持磁盘阵列连接复制的磁盘阵列主要有IBM Shark系列、EMC Symmtrix 8000、DMX系列、Hitachi 9900（HP XP/Sun StorEdge9900）系列。连接主要以直接光纤连接或走SDH网络。直接光纤连接距离大约支持30KM。支持存储交换机连接复制的交换机主要有McData、Brocade的交换机系列。连接方式与盘阵连接类似。基于存储的复制技术均支持同步复制与异步复制。l 同步复制流程1. 工作主机向主工作盘阵发出 I/O 写请求，主盘阵将更改的数据记入 cache 当中。2. 主工作盘阵通过光纤向备份盘阵发出 I/O 写请求操作。3. 备份盘阵做完记录更改后，向主盘阵发送写操作结束请求。4. 主盘阵收到备份盘阵发回的写结束响应后，向主机发送写操作结束的响应。5. 至此写操作完成。l 异步复制流程1. 工作主机向主工作盘阵发出 I/O 写请求，主盘阵将更改的数据记入 cache 当中。2. 主工作盘阵向主盘阵发送写操作结束请求。3. 主工作盘阵通过光纤向备份盘阵发出 I/O 写请求4. 备份盘阵做完记录更改后，向主盘阵发送写操作结束请求。5. 至此写操作和备份操作完成。基于存储复制时的系统延迟计算方法基于存储级复制的时系统延迟可以由下面公式计算：系统相应延迟协议转换时间数据传输时间信号延迟l 协议转换时间取决与采用的传输协议： 裸光纤 DWDM SDH ATM IP裸光纤和DWDM的协议转换时间可以忽略，如果采用同步复制尽量不要采用其他协议传输。l 数据传输时间最大数据传输量 / 传输速率在作存储复制计算时，最大的数据量为在存储系统上（不是应用层的数据量）检测到的最大数据写入量（读数据不需要复制）。存储级复制一般采用光纤传输，数据传输速率可以达到2Gbit/s。l 信号延迟距离 / 光速距离为生产节点到容灾节点距离的2倍，光速为光在玻璃中的传播速率，为20万公里/秒。2.4.1.3 基于卷的复制技术服务器卷方式复制嵌入到操作系统的卷管理系统中，不同操作系统采用不同的卷管理系统，也有第三方的卷管理系统适用于多个操作系统平台，但目前没有一个卷管理系统被所有操作系统使用。下面讨论服务器卷复制的技术共性。操作系统的卷管理系统位于磁盘设备驱动程序之上，屏蔽各设备驱动程序看到的裸设备的差别，为上层实体（如文件系统、数据库管理系统）提供统一的逻辑磁盘设备。卷发生的变化分为结构的变化和卷内容的变化。卷内容的变化通过数据复制过程将引起该变化的操作在异地中心重现获得。操作的粒度为针对卷的基本块的修改、插入、删除等操作。卷结构的变化包括卷组中包含设备的变化、逻辑卷的大小变化等，该变化不能通过数据复制过程获得，需要由系统管理员在异地中心执行同样的结构变化操作。由于卷复制部件引入的服务器CPU、Memory运行开销和TCP/IP网络的传输延迟，同步方式将对业务的正常运行产生性能影响。性能影响的程度和当前的IT资源配置和业务繁忙程度相关。从保持数据复制的一致性看，某个复制进程只能复制一台服务器所管理的数据，多台服务器的数据复制需采用多个复制进程，其数据一致性通过数据复制机制实现。从卷复制的过程看，操作复制时要求卷管理系统的结构保持稳定；当卷系统结构发生变化，如卷包含设备发生增删，由于异地中心设备配置的不同，必须重新检查复制的配置状况，重新设置复制过程。从保证业务状态的完整性看，该技术只能特定卷管理系统所管理的数据，需要采用其他技术复制裸设备中（如操作系统启动盘）的数据。服务器卷方式复制适用于单卷管理系统、无裸设备应用，对于多平台、业务及卷管理结构将发生变化的企业级的IT生产系统的数据复制，需妥善维护多个复制系统，保证相互之间的数据一致性。基于服务器卷方式的复制产品包括VERITAS Volume Replication，IBM GeoHA等。2.4.1.4 基于数据库的复制技术数据库方式的数据复制通过数据库管理系统对数据更新操作的交易管理来实现，不同数据库的数据复制机制各不相同，以下讨论其共性的原理实现。数据库的更新分为两种更新，元数据（metadata）的改变和用户数据的改变。元数据的改变即数据库结构的改变，如数据库的表空间的扩展等；用户数据的改变如用户数据库表中记录的增、删、改等。应用的某个交易可能涉及到多个数据库表的增删改等。为了实现应用交易的完整性，数据库管理程序将多个用户数据修改操作定义为数据库交易，而在交易日志中具体记录交易的开始、子操作细节和结束(commit)。当数据库重启或进行数据恢复操作时，利用日志中记录的信息，执行前滚操作（roll forward）保证已结束的数据库交易数据的不丢失，执行回滚操作（roll back）完全丢弃未完成的交易的部分更新。数据库交易的复制机制利用日志的这种特性，在生产中心将日志传输到异地中心；如果异地中心的数据库结构和生产中心的数据库结构保持一致，则异地中心的数据库对日志中记载的交易执行前滚操作，即实现了对异地中心数据库数据的更新。日志分为联机日志和归档日志。联机日志在生产中心执行数据库交易时实时生成，而归档日志为联机日志写满关闭后的状态。同步方式由于同时复制归档日志和联机日志，而联机日志与数据库交易的本地提交存在时序关系，会因为复制过程引入的处理开销和网络延迟而影响本地数据库的性能，因而适用于近距离、低数据库交易负载的场合。其异步方式由于只复制归档日志，可在长距离下避免复制联机日志而对生产数据库产生的影响，但要承受不复制联机日志而带来的交易丢失。从数据库复制的过程看，数据库交易复制时要求数据库的结构保持稳定；当数据库结构发生变化，如扩展表空间时，必须重新初始化复制过程。从保证业务状态的完整性看，该技术只能复制数据库中的数据，需要采用其他技术复制系统状态和为与数据库之外的如位于文件系统中的业务数据。数据库方式复制适用于单数据库应用，对于异构多数据库、数据库结构将发生变化的企业级的IT生产环境，需同时妥善维护多个数据库方式复制系统。基于数据库的数据复制技术主要关系型数据库均支持，如：Oracle、Sybase。数据库复制可以分有两个级别，全库复制，表级复制。下面以Oracle数据库为例介绍，全库复制和表级复制。2.4.1.4.1全库复制Oracle的全库复制主要是利用ORACLE数据库的STANDBY DB技术实现。STANDBY DB实质上就是一个主系统数据库在发生灾害时候的一个拷贝，它实现的原理是利用了ORACLE数据库的归档日志文件，将归档日志文件通过文件传输系统发送到容灾端系统，进行对数据库的恢复过程。l 数据流程l Standby DB复制技术主要特点是：1. 备份数据库是由主数据库的日志恢复的，所以可以保障数据的可用性。2. 不影响主数据库性能，STANDBY DB不会影响主数据库的任何操作。3. 由于恢复过程中备数据库处于mount状态，所以备数据库的数据在复制过程中不能被访问。4. 由于备份数据库的数据是由主数据库的归当日志恢复的，所以备数据库的数据比主数据库要少一些，主数据库失效后会损失一部分数据，损失的数据量取决于日志文件的大小。5. 由于主数据库要处于日志归档模式，会影响一定的主数据库性能。因为BOSS中的营帐数据库一般都处于归档模式，因此，这部分的影响可以忽略。2.4.1.4.2表级复制Oracle数据库也提供一种基于表的复制方式，复制流程是：1. 在主备数据库上安装Oracle Replication Option，在系统缺省安装时并不安装此部分。2. 启动相关复制进程。3. 指定要复制的表，系统会对要复制的表作好触发器(trigger)。4. 应用程序在对表进行修改时，会触发相关程序，把对表的操作命令写入复制队列。5. 复制进程把命令复制到备数据库上，并在复制系统上执行，修改相应表。表级数据复制模式也分同步复制和异步复制，这种复制的优点是，复制原理简单，数据量少时速度快，不需要额外投资；但维护工作相对复杂，对大数据量不适合。2.4.1.4.3 针对Oracle数据库的第三方产品现在BOSS系统普遍采用的是Oracle数据库，针对Oracle数据库，有些第三方产品可以支持基于Log的复制，实现机制与Oracle的Standby DB有所不同。主要的厂商有Quest，DSG。l 复制实现机制基本原理如下图所示：该类技术针对数据库提供了基于逻辑的交易复制方式。该方式通过直接捕获运营数据库的交易，将数据库的改变逻辑复制到容灾系统数据库中，实现运营系统和容灾系统数据的一致性。如上图所示，复制软件通过对生产系统数据库的在线日志进行实时跟踪，当应用系统向数据库中进行任何操作时时，这些信息都将在在线日志中存储，复制软件通过对实时获取的数据库在线日志进行分析，获得本次操作的交易指令和交易数据，然后将这些交易指令和交易数据通过网络传送到容灾系统。容灾端系统的代理对接收到的交易进行处理，按照交易的先后顺序在容灾系统中重新执行该交易。同时，系统还提供数据一致性监测功能，系统将自动监控运营系统和容灾系统的数据一致性状态，如果发现不一致，马上进行重新同步。采用这种容灾方式，可以保证数据完全不丢失，并且实现非常高的实时性。该类复制软件从生产系统上实时获取系统交易，将交易数据通过TCP/IP网络传送到异地容灾系统，在该网络上只传输交易的纯数据，无需其他的额外信息，这样减少对广域网络带宽的需求。同时，系统提供队列存储机制，为用户提供异步的数据复制功能，系统在生产系统端和容灾系统端都保存自己的数据队列，当系统处于业务量高峰时，如果系统处理处理出现瓶颈时，系统自动保存未处理的交易，并延迟提交。保证数据的完整性和一致性。2.4.1.5基于应用的复制技术基于应用的复制技术也分为同步和异步两种方式，基本实现方式可以分为，二次提交，和Log复制。2次提交可以实现同步复制，Log复制可以实现异步复制。通常来讲，基于异步的方式比较容易实现，主要是基于文件传输的方式进行同步，同时对系统性能影响也较小。但会导致一定的数据丢失，数据丢失的大小和复制的频率相关，通常这一部分丢失的数据在灾难发生时可以通过其他手段补足，适合于RTO要求相对较低的系统或允许少部分数据丢失的系统。2.4.1.5.1基于Log的应用复制实现方式由于采用应用同步复制技术难度较大，而且会造成应用系统较大的维护工作量，所以，在实际应用环境下，基于Log的复制方式应用比较广泛。实现原理如下图所示： 生产系统的应用系统在提交数据的同时，把所提交的交易记录到Log文件中。 复制进程把日志传送到容灾节点。 容灾节点的接收进程，接收文件后把交易内容提交到容灾节点数据库中。2.4.1.5.2基于Log的应用复制实现方式对应用系统的要求对于基于应用的复制方式要求应用系统必须做到，在每个对数据库操作进程必须都要写日志，才能保证主备节点数据保存一致。最好系统应用系统的体系结构类似下图：应用系统不直接操作数据库，而是由应用中间层操作数据库，所有应用系统对数据库的操作都通过中间层进行。由中间层程序负责把应用系统的交易写成日志。2.4.1.5.3基于应用系统的复制方式特点应用模式发生改变或交易的原子操作发生变化时，两个中心内嵌的复制代码必须同步更新，从而增加同时同步维护多个外部系统的要求，否则会发生交易复制缺失或交易复制不完整的错误。由于需要重新初始化复制过程、重新测试复制机制，将增加系统升级的周期，增大新业务投产的风险。当生产数据发生结构性变化时，这种结构性变化往往不能通过交易复制受到传输到异地中心；此时必须终止交易复制机制，在异地中心进行同样的数据结构改变。从而要求系统管理人员实际上维护两个生产系统。基于应用的数据复制技术特点：基于应用的数据复制是由应用系统控制的，所以应用对流程的控制力度较强，灵活性大；但基于应用系统的复制对应用系统开发要求较高，在一定程度上增加了应用的复杂程度。2.4.1.6复制技术比较以上介绍的复制方式，在容灾系统的建设中都有应用，在选择时应根据具体软硬件环境，下表对以上几种复制作一个比较：技术 特色存储级复制第三方数据库复制技术应用复制备注基于磁盘阵列基于逻辑卷复制距离同步裸光纤 35KMDWDM 100KM 100KM不适用不适用异步无限制无限制无限制无限制数据库100%可用同步模式可用性高；异步模式不能100%保证可用同步模式可用性高；异步模式不能100%保证可用100%保证可用100%保证可用恢复时间指标RTO一小时左右一小时左右20分钟秒级存储级复制数据库启动时间要视当时数据库配置、脏数据量等情况而定。数据恢复时间点RPO分钟级或零丢失丢失至少一个交易几个交易丢失一个LOG带宽需求大大较小小数据复用需要额外空间需要额外空间方便更方便投资大较大较小小维护复杂度小小较小大误操作无法挽回无法挽回较好好数据的一致性可保证可保证可保证可保证对主机性能的影响同步模式影响大；异步模式影响小 同步模式影响大；异步模式影响小影响小影响大2.4.2 数据恢复技术从上面的分析可以看出，无论采用哪种数据复制技术都无法保证数据不丢失，对于RPO0的应用系统（如营业系统），需要采用相应的数据恢复技术实现已丢失数据的再生。数据恢复的关键是从什么时刻开始进行数据恢复。对于一个应用级的BOSS容灾系统来说，一旦确定了恢复数据目标（Recovery Point Objective- RPO）和恢复时间目标（Recovery Time Objective- RTO）之后，最重要的是确定一个全局控制的检查点CheckPoint,用来控制各个子系统的数据在逻辑上的一致性。否则即使各个子系统都达到自身的目标（RTO、RPO），但是由于各个子系统数据的关联性，最终无法拼凑成为一个完整的BOSS应用系统，应用级容灾的目标无法完成，最后只是达到了数据级容灾的目标。容灾系统数据恢复的问题最终可以理解成在某些点(CheckPoint)上，BOSS各个子系统在逻辑上的一致性。在灾难发生的时候，整个系统能够从某个CheckPoint开始恢复。下图描述了灾难发生时，单个子系统中CheckPoint的作用。注释：A0：整个系统的CheckPoint，与其他子系统的共用；A1：各个子系统自身的CheckPoint，每个子系统可以取不同的值；A2：系统崩溃点；A2：子系统检查开始点（大于A2）；A3：子系统检查结束，恢复开始；A4：子系统恢复完毕；B0：和整个系统CheckPoint点A0的差异；B1：子系统崩溃时和容灾端的差异；B2：子系统检查时间；B3：系统启动后恢复数据所用时间其中：A4A2=RTO；从上图我们可以看到，只要恢复差异值B1，对子系统本身来说就可以到应用级容灾的目的，但是对整个系统来说，恢复B1有时只能到达数据级别容灾的目的,具体原因请见下图的分析。注释：D1:子系统恢复量差异D2：子系统S2的B1假设子系统S1和子系统S2都只恢复B1，在子系统S1和子系统S2没有交互的情况下，各自恢复B1之后，系统再次达到逻辑上的一致性，应用级容灾的目标就可以到达。但对于BOSS系统来说，各个系统之间存在大量的数据交换，所以这种数据逻辑上的一致性就不可能达到。比如，在D1这个时间段中，存在S1到S2的输入，这样S1在D1这个时间段的向S2的输出会有两份，同时在D2这个时间段中，存在S2到S1的输入，这样S2在D2这个时间段的向S1的输出也会有两份，这样都会导致数据恢复的失败。由于系统S1和系统S2的A1不同，这种情况下只有两个子系统都回退到A0才能到达逻辑上的完整性。对于只存在S1到S2的输入的情况，可以先从S1的A1恢复，S1的恢复完成之后，在把S2从A0恢复，而且A0到A2期间所有S1到S2的输入必须做一次REDO操作。或者两个子系统都回退到A0开始恢复。同样对于只存在S2到S1的输入的情况，可以先从S2的A1恢复，S2的恢复完成之后，在把S1从A0恢复，而且A0到A2期间所有S2到S1的输入必须做一次REDO操作。或者两个子系统都回退到A0开始恢复。理论上讲B越小越好，但是这样的代价是，随着期望值B的减小，风险（投资大小、实施难易程度等）成级数上升。通过对XX省BOSS系统的分析，我们建议各个子系统设置以下两种CheckPoint点，即A0（系统级的CheckPoint）、A1（子系统级的CheckPoint），具体情况如下：l 将A0设置为天，这样即使出现错误，我们可以只对崩溃当天的数据进行恢复；其余数据可以启动流程重新处理，从而完整的恢复数据；l 每天凌晨（1点左右），设置断点，获得A0，将生产系统与灾备系统主要对平（灾备系统自然就平衡了），即使在0点到1点之间系统崩溃，我们需要恢复的数据也不会超过48小时；l A1设置时间可以根据各个子系统进行具体定义，当系统崩溃时，根据两个系统的系统处理实时标志，进行稽核处理，作为恢复起点的标志，如果这个点无法使用，可以回溯到A0点。l 尽量缩小B，我们可以将B做如下分解：BB0B1B2B3，n B0需要缩小，可以通过减少同步周期来实现，但是这样的后果可能会增加生产系统的负担和修改程序的风险；n B1需要缩小，通过管理手段实现；n B2需要缩小，分析B2，我们可以将B2分解为TA0（稽核A0所用时间）和TA1（稽核A0，A1所用时间），我们将这两个时间进行分别对待;u TA0每天进行一次，选择时间可以在凌晨进行，这部分的时间可以作为一个相对固定的时间考虑；u TA1可以通过生产和容灾同时输出处理标记的方式进行对比，将实时更新的数据在处理过程中进行时间标记、数量标记、金额标记等必要的标记，这样在对比时可以减少对比所消耗的时间， n B3需要缩小，需要通过完善的管理手段、人员的业务技术熟练程度、系统的处理程度，程序的优化程度等多方面的因素。是无法通过灾备系统本身程序能够实现的。2.4.3网络切换技术2.4.3.1切换目标容灾系统也叫业务连续（Business Continue Plan），所以应用的切换目标应该是，整个业务系统，而不是某个具体应用，在容灾切换中需要考虑整个业务系统中所有应用系统的切换。如计费业务的切换，需要把采集、预处理、批价、入库等应用系统同时切换，并要有一定顺序。而且为保障业务的连续性，需要考虑非IT系统因素，如人员等。所以，切换不仅是IT系统问题，而是这个企业协调运作的结果。2.4.3.2浮动IP地址方案生产中心、灾备中心相应的主机采用相同的IP地址，将生产中心、灾备中心相同子系统的业务主机与交换机相连的端口划分在同一个VLAN，在正常情况下，生产中心的主机的网卡处于工作状态，灾备中心的主机网卡处于禁用状态。如下图所示： 采用生产中心与灾备中心相同的IP地址的方案不用对客户端、DCN网做任何改动。这是因为，在正常情况下这部分地址从生产中心的核心交换机广播到DCN网，在生产中心不可用时，这部分地址通过灾备中心的核心交换机广播到DCN网，这些路由的切换可以通过DCN网的域内路由协议（OSPF或IS-IS）自动实现。2.4.3.3智能DNS方案如果采用DNS方案，需要准备的条件是：l 在生产中心和灾备中心配置DNS服务器：DNS1、DNS2；l 对于某个特定的域名，每台DNS服务器需要有两条记录：IP1、IP2；l 客户端的DNS Server优先指向DNS1，超时则指向DNS2则正常情况下，客户端的DNS请求先指向DNS1，DNS1 Server返回IP1；在生产中心业务主机不可用时，客户端的DNS请求先指向DNS1，DNS1 Server返回IP2；在生产中心业务DNS1 Server不可用时，客户端的DNS请求先指向DNS2，DNS2 Server返回IP1；在生产中心都不可用时，客户端的DNS请求先指向DNS2，DNS2 Server返回IP2；上述的复杂的DNS处理流程是现有的BIND软件不能实现的，因此在容灾应用环境，如采用DNS方案，需要增加智能DNS方案。如下图所示：2.4.3.4 L4 Switch方案由于现有的营业应用都是基于固定端口号的应用，因此可以通过L4 Switch实现应用负载的动态分配。客户端将连接请求指向L4 Switch的虚拟IP地址VIP，由L4 Switch根据检测到的后台应用服务器的健康状况和负载情况进行任务分配。在L4 Switch中生产中心、灾备中心的应用服务器都是可以使用的资源。如果某台应用服务器出现故障，可以通过L4 Switch实现无缝切换。如下图所示：2.4.4应用系统切换技术2.4.4.1容灾切换方式当生产系统的处理能力只是部分损坏，仍然保留一定的系统处理能力的时候，可以只进行局部切换。局部切换相对于全部切换而言所影响和涉及的范围相对要小一些，所以如果只是局部切换就可以满足业务需求的时候应优先考虑局部切换。局部切换后将由生产系统和容灾系统一起协同对外提供业务能力。在BOSS系统中通常根据具体功能的不同，可分为数据核心层、业务逻辑层和接口层三个部分。数据层相关的IT基础系统包括存储数据的磁盘阵列、数据库以及运行数据库的主机，而业务逻辑层相关的IT基础系统包括BOSS应用程序、中间件及相关服务器等。视损坏的具体IT基础单元，局部切换可分为应用程序切换、数据库切换和部分系统切换三种方式。l 应用程序切换当生产系统的业务逻辑层相关的IT基础系统（包括应用程序、中间件和相关的服务器）出现短时间不可恢复的故障而核心数据相关系统还可以正常工作时，可以考虑应用程序切换方式。可能的情况包括但不限于：进行应用处理的多台机器同时DOWN机而且短时间内无法恢复；进行应用处理的服务器性能严重下降或严重不稳定而短时间内无法排除故障。切换后由容灾系统提供业务逻辑处理部分，原生产系统提供数据核心层的相关服务。容灾系统的业务逻辑处理部分远程访问原生产系统中的核心数据服务。由于进行了应用程序的切换，相应的对外接口部分也需要进行切换。l 数据库切换当生产系统的核心数据相关的IT基础系统（包括磁盘阵列、数据库和相关的服务器）出现短时间不可恢复的故障而应用程序相关系统还可以正常工作时，可以考虑数据库切换方式。可能的情况包括但不限于：磁盘阵列损坏、数据库无法正常工作、多台数据库服务器同时DOWN机或不稳定等情况。切换后由容灾系统提供核心数据处理部分，原生产系统提供应用程序的相关服务。生产的业务逻辑处理部分远程访问容灾系统中的数据服务。由于没有进行应用程序的切换，相应的对外接口也无需进行切换。l 部分系统切换按照完整的业务处理逻辑进行划分切换，比如计费模块，将计费模块相关的应用程序、中间件、数据库、数据、磁盘阵列和主机切换到容灾系统中去，而帐务处理模块相关的的应用程序、中间件、数据库、数据、磁盘阵列和主机仍然在原生产系统中完成。可能的情况包括但不限于：生产系统业务逻辑处理能力下降，无法支持全部模块的正常运行；生产系统的数据部分损坏等。由于进行了应用程序的切换，相应的对外接口部分也需要进行切换。l 全部切换当生产系统发生了毁灭性的灾难如地震、火灾、电源损坏等情况导致生产系统的处理能力完全丧失；或虽然生产系统还具备部分业务逻辑处理和核心数据能力，但由于整个系统模块间的逻辑关系、整个系统的部署方式而导致无法进行部分切换等时候，可以进行全部切换。全部切换主要阶段如下：n 利用复制数据恢复数据启动异地中心的各处理要素（如数据库、应用等）n 开通异地中心的对外服务网络，恢复业务的运行针对具体情况，可以利用各处理要素提供的编程接口，编写自动化脚本，从而简化灾难切换的人工操作步骤；在生产中心的故障排除后，需将生产从异地中心回迁到生产中心。此时的回切过程相当于一次有计划的从异地中心向生产中心的切换，步骤如下：n 从异地中心向生产中心传输自灾难发生后新产生的生产数据n 暂停异地中心将被回切的生产任务n 在生产中心重启生产n 恢复生产中心向数据中心的数据复制过程2.4.4.2切换流程在实施应用级的远程容灾方案之后，当主数据中心因为各种突发性灾难造成无法正常运行时，原来运行在主数据中心的营业系统和银行前置业务系统将切换到备份中心继续运行；切换方式分为两种，即手工方式和自动方式容灾监控和切换控制有商业软件，如：Veritas Global Cluster、MC/SERVICE GARUD。容灾系统的切换与局域网内的高可用系统（HA）切换不同，一般不能使用自动切换，否则会造成系统数据混乱。而且这些软件的控制切换时也需要针对应用写大量的检测脚本和切换脚本。所以建议系统监控采用网管系统，对BOSS设备和BOSS应用系统监控。人工判断故障程度，手动切换应用系统。YY公司公司专门为容灾系统的监控和切换控制开发了AIDRM（YY公司容灾管理系统）系统。2.4.4.3自动化切换程序当用户选择采用手工方式进行应用切换时，在主数据中心因为突发性灾难造成崩溃后，需由容灾系统管理员在备份数据中心启动预先编写的，并已通过严格测试的业务系统切换脚本完成应用系统的切换过程当用户不希望因为各种偶然性的因素（如网络故障，应用程序bug等）造成业务系统的远程切换，以及手工切换造成的业务中断时间在营业系统和银行前置业务可以接受的时间范围内，或备份数据中心24小时有人值守的条件下，可以选择使用手工切换的方式完成应用系统的远程切换，这种方式可以使容灾系统管理人员对灾难备份与恢复操作进行更多的控制与管理。为提高手工操作切换速度，并减少手工操作带来的风险，YY公司公司可以为BOSS的各子业务系统开发相应的切换程序。当生产系统发生不可短时间恢复的故障时，手动执行这些程序可以迅速把相关应用切换到容灾系统上。系统恢复后，在执行切换脚本容灾系统切换回生产系统。需要说明的是整个系统切换的过程不可能完全依靠切换程序自动完成，自动切换程序通常无法有效的处理切换过程中的异常情况。切换程序将尽可能地把一些步骤自动化，切换过程必须要人的参与并监控。切换程序将针对不同的灾难情况、不同的应用系统模块编制不同的切换程序，切换程序的开发需要在工程中不断充实完善。2.4.5资源复用技术容灾系统的建设是非常大的一项投资，对于运营商来说，经常把容灾投资比喻为买保险，但容灾投资和买保险是不同的，保险是只有出事时才会起作用，而合理的容灾建设方案应该能够在正常生产过程中发挥作用，分担生产系统的负担。2.4.5.1资源复用的意义在容灾系统上作资源复用有以下三个方面的意义：分担生产系统负担，可以把读数据的应用放到容灾节点运行，以减轻生产系统压力。如，经营分析系统的ETL工作；统计报表工作；用户自查询工作；系统数据备份工作等。验证数据复制的可靠性，在使用存储级复制过程中，数据不能被正