容灾项目方案设计
容灾项目设计方案
目 录
第 1 章 容灾技术规范 ...................................... 4
1.1 容灾的总体规划 ................................................. 4 1.1.1 技术指标RPO、RTO ................................................. 4 1.1.2 国际标准SHARE 78 ................................................ 5
1.1.2.1 Tier 0 ........................................................ 6 1.1.2.2 Tier 1 ........................................................ 7 1.1.2.3 Tier 2 ........................................................ 7 1.1.2.4 Tier 3 ........................................................ 8 1.1.2.5 Tier 4 ........................................................ 8 1.1.2.6 Tier 5 ........................................................ 8 1.1.2.7 Tier 6 ........................................................ 9 1.1.3 界定灾备系统的适用范围 ............................................ 9 1.1.4 界定灾备建设的目标 ................................................ 9 1.1.5 界定灾备系统的总体架构 ........................................... 10
第 2 章 主流容灾技术说明 ................................. 12
2.1
数据备份 ...................................................... 12
2.2 实时数据保护 .................................................. 12 2.2.1 数据镜像（Mirroring） ............................................ 13 2.2.2 数据复制（Replication） .......................................... 13
2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4
软件复制 ..................................................... 13 硬件复制 ..................................................... 15 数据库复制 ................................................... 18 Datacore SDS ................................................. 19
2.3 2.4 2.5 2.6
应用系统恢复 .................................................. 19 网络系统恢复 .................................................. 19 容灾切换过程 .................................................. 20 消防演习 ...................................................... 20
第 3 章 主流容灾技术分析与对比 ........................... 21
3.1
数据备份 ...................................................... 21
3.2 实时数据保护 .................................................. 22
3.2.1 数据镜像（Mirroring） ............................................ 22
3.2.1.1 硬件镜像 ..................................................... 22 3.2.1.2 软件镜像 ..................................................... 22 3.2.1.3 软件智能存储镜像 ............................................. 23 3.2.1.4 镜像技术在容灾中的利用 ....................................... 23 3.2.2 数据复制（Replication） .......................................... 23 3.2.2.1 软件复制（卷复制） ........................................... 24 3.2.2.2 硬件复制 ..................................................... 24 3.2.2.3 基于软件控制器的复制 ......................................... 25
容灾项目设计方案
3.2.2.4
数据库复制 ................................................... 25
3.3 3.4
应用系统恢复 .................................................. 27 网络系统恢复 .................................................. 29
第 4 章 容灾系统设计步骤 ................................. 30
4.1
第一步，深化数据备份系统 ...................................... 30
4.2 第二步，存储、应用整合 ........................................ 31
4.2.1 存储整合 ......................................................... 31 4.2.2 应用整合 ......................................................... 31 4.3 4.4 4.5
第三步，实现远程实时数据卷保护 ................................ 32 第四步，建立远程切换消防演习机制 .............................. 32 第五步，建立远程切换机制 ...................................... 32
第 5 章 数据容灾的性能分析 ............................... 33
5.1 同步数据容灾的性能分析 ........................................ 33 5.1.1 带宽 ............................................................. 33 5.1.2 距离 ............................................................. 33 5.1.3 中间链路设备和协议转换的时延 ..................................... 34 5.2
异步数据容灾的性能分析 ........................................ 36
容灾项目设计方案
容灾技术规范
作为风险防范系统，灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行，以及真正面对灾难时的切换操作等方面也存在着潜在的风险。
计算机信息系统实现数据大集、应用大集中后，系统的运行安全成为风险控制的焦点。目前，已经有多系统开始或准备进行灾备系统的建设，灾备系统建设的目标是减灾容灾，使计算机信息系统和数据能够最大限度地防范和化解各种意外和灾害所带来的风险。然而，与大多数工程一样，灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行，以及真正面对灾难时的切换操作等方面也存在着潜在的风险。
可以说，风险防范系统本身也存在风险点，需要小心应对。
灾备系统建设中所涉及的潜在风险大致可分为技术风险、管理风险和投资风险，其中尤以技术选择风险最大，技术方案选择优越，可以规避一定的管理风险和投资风险。而这三者也存在内在的相互关联，不同灾备级别对应的建设投资规模、所采用的技术以及实施和管理的复杂度也不同，应考虑保护计算机系统的原有投资并提高灾备系统建设投资的利用率。
1.1 容灾的总体规划
真正的容灾是数据被不间断的一致性访问！
在灾难备份的世界里，是有等级观念的，级别不同，灾备系统所采用的技术和达到的功能是不同的，在系统建设资金投入方面的差距也很巨大。所以，对用户来说，明确灾备系统建设的总体规划十分必要。
1.1.1 技术指标RPO、RTO
容灾项目设计方案
衡量容灾技术的两个技术指标RPO、RTO
RPO(Recovery Point Objective): 以数据为出发点，主要指的是业务系统所能容忍的数据丢失量。及在发生灾难，容灾系统接替原生产系统运行时，容灾系统与原生产中心不一致的数据量。RPO是反映恢复数据完整性的指标，在同步数据复制方式下，RPO等于数据传输时延的时间；在异步数据复制方式下，RPO基本为异步传输数据排队的时间。在实际应用中，考虑到数据传输因素，业务数据库与容灾备份数据库的一致性（SCN）是不相同的，RPO表示业务数据与容灾备份数据的SCN的时间差。发生灾难后，启动容灾系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。
RTO(Recovery Time Objective):以应用为出发点，即应用的恢复时间目标，主要指的是所能容忍的应用停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。是反映业务恢复及时性的指标，表示业务从中断到恢复正常所需的时间。RTO值越小，代表容灾系统的数据恢复能力越强。各种容灾解决方案的RTO有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业务中心与备份中心的高可用管理，这种容灾解决方案具有最小的RTO。容灾系统为获得最小的RTO，需要投入大量资金。
不同容灾方案的RTO和RPO是不相同的。
1.1.2 国际标准SHARE 78
要建设容灾系统，就必须提出相应的设计指标，以此作为衡量和选择容灾解决方案的参数。目前，国际上通用的容灾系统的评审标准为SHARE 78，主要包括以下内容。
●备份/恢复的范围
●灾难恢复计划的状态
●业务中心与容灾中心之间的距离
容灾项目设计方案
●业务中心与容灾中心之间如何连接
●数据是怎样在两个中心之间传送的
●允许有多少数据丢失
●保证更新的数据在容灾中心被更新
●容灾中心可以开始容灾进程的能力
SHARE 78是建立容灾系统的一种评审标准。建立容灾系统的最终目的，是为了在灾难发生后能够以最快速度恢复数据服务，主要体现在RTO Objective)和RPO上。SHARE 78, M028报告中定义的灾备的七个级别和与其对应的数据丢失量与恢复时间情况详见下表：
灾难备份等级与业务恢复情况对照表 等级 描述 RPO 0级 无灾备计划 - 1级 车辆运送方式 24~48小时 2级 车辆运送＋热备份 24~48小时 3级 电子传送 <24小时 4级 活动状态备份中心 秒级 5级 两中心、两阶段确认 秒级 6级 零数据丢失 零丢失
1.1.2.1 Tier 0
Tier 0 - 无异地数据备份(No off-site Data)
Tier 0 被定义为没有信息存储的需求，没有建立备份硬件平台的需求，也没有发展应急计划的需求，数据仅在本地进行备份恢复， 没有数据送往异地。这种方式
RTO - >48小时 24小时 <24小时 <24小时 <2小时 <2小时 企业百分比 <0.3% <0.1% 90% 6% <0.5% <0.1% 3% 容灾项目设计方案
是最为低成本的灾难备份解决方案，但事实上这种灾难备份并没有真正灾难备份的能力，因为它的数据并没有被送往远离本地的地方，而数据的恢复也仅是利用本地的记录。
1.1.2.2 Tier 1
Tier 1- PTAM车辆转送方式( Pickup Truck Access Method)
作为 Tier 1 的灾难备份方案需要设计一个应急方案，能够备份所需要的信息并将它存储在异地，然后根据灾难备份的具体需求，有选择地建立备份平台， 但事先并不提供数据处理的硬件平台。
PTAM是一种用于许多中心备份的标准方式，数据在完成写操作之后，将会被送到远离本地的地方，同时具备有数据恢复的程序。在灾难发生后，一整套系统和应用安装动作需要在一台未启动的计算机上重新完成。系统和数据将被恢复并重新与网络相连。这种灾难备份方案相对来说成本较低(仅仅需要传输工具的消耗以及存储设备的消耗)。 但同时有难于管理的问题，即很难知道什么样的数据在什么样的地方。一旦系统可以工作，标准的做法是首先恢复关键应用，其余的应用根据需要恢复。这样的情况下，恢复是可能的，但需要一定的时间，同时依赖于什么时候硬件平台能够被提供准备好。
1.1.2.3 Tier 2
Tier 2 - PTAM卡车转送方式+热备份中心 (PTAM+Hot Site)
Tier 2相当于是Tier 1再加上具有热备份能力中心的灾难备份。热备份中心拥有足够的硬件和网络设备去支持关键应用的安装需求。对于十分关键的应用，在灾难发生的同时，必须在异地有正运行着的硬件平台提供支持。这种灾难备份的方式依赖于用PTAM的方法去将日常数据放在异地存储，当灾难发生的时候，数据再被移动到一个热备份的中心。虽然移动数据到一个热备份中心增加了成本，但却明显降低了灾
容灾项目设计方案
难备份的时间。
1.1.2.4 Tier 3
Tier 3 - 电子传送(Electronic Vaulting)
Tier 3 是在Tier 2的基础上用电子链路取代了车辆进行数据传送的灾难备份。接收方的硬件平台必须与生产中心物理地相分离，在灾难发生后，存储的数据用于灾难备份。由于热备份中心要保持持续运行，因此增加了成本。但确实是消除了运送工具的需要，提高了灾难备份的速度。
1.1.2.5 Tier 4
Tier 4 - 活动状态的备份中心 (Active Secondary Site)
Tier 4 这种灾难备份要求两个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个方向发生。接收方硬件平台必须保证与另一方平台物理地相分离，在这种情况下，工作负载可以在两个中心之间被分担，两个中心之间之间彼此备份。在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。在灾难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢复时间也可降低到了小时级。
1.1.2.6 Tier 5
Tier 5 - 两中心两阶段确认 (Two-Site Two-Phase Commit)
Tier 5 是在Tier 4的基础上在镜像状态上管理着被选择的数据 (根据单一commit范围，在本地和远程数据库中同时更新着数据)，也就是说，在更新请求被认为是满意之前，Tier 5需要生产中心与备份中心的数据都被更新。我们可以想象这样一种情景，数据在两个中心之间相互映像，由远程two-phase commit来同步，因
容灾项目设计方案
为关键应用使用了双重在线存储，所以在灾难发生时，仅仅传送中的数据被丢失，恢复的时间被降低到了小时级。
1.1.2.7 Tier 6
Tier 6 - 零数据丢失 (Zero Data Loss)
Tier 6 可以实现零数据丢失率，同时保证数据立即自动地被传输到备份中心。Tier 6被认为是灾难备份的最高的级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力。Tier 6是灾难备份中最昂贵的方式，也是速度最快的恢复方式，恢复的时间被降低到了分钟级。对于Tier 6 的灾难备份解决方案，可以应用两种远程拷贝技术来实现，即PPRC同步远程拷贝和XRC异步远程拷贝。
因此，企业需要根据其计算机处理系统中数据的重要性，以及需要恢复的速度和程度，来进行灾备系统建设的整体考虑和不同灾难对业务冲击的分析，并最终确定灾备系统建设的总体规划。
灾备系统建设的总体规划应包括以下几个方面：
1.1.3 界定灾备系统的适用范围
分析不同的应用系统，确定灾备系统是一个覆盖整个计算机系统的工程，根据业务的重要性，对不同的系统采用不同级别的容灾方案，如针对关键的业务应用子系统，实施高级别的容灾工程；对低级别的业务系统，实施低级别的容灾工程。总之要建立一个综合性的整体灾备建设工程。
1.1.4 界定灾备建设的目标
生产系统在单位时间内的数据处理能力或IO流量确定的情况下，RPO实际上成
容灾项目设计方案
为一个反映灾备恢复过程中的数据丢失量的指标。而RTO则是指从灾难发生到备份系统可以接管原有生产系统所需要花费的时间，这不仅要考虑数据的恢复时间，还应该考虑恢复后数据的完整性、一致性的修复和确认、备份中心计算机处理系统的启动和备份中心的网络切换等全部时间。总体规划中应为灾备系统设定明确的RPO和RTO指标。
但是设计容灾系统不能只看RTO和RPO，对于不同的业务系统和用户特殊的要求，其它一些指标有可能成为选择容灾解决方案的主要因素。例如，某些地区为了防范一些特定自然灾害的风险，要求容灾备份中心与业务中心保持足够的距离，在这种情况下，容灾备份中心与业务中心的距离要求就是容灾系统的重要指标。
通信网络是容灾系统的组成部分，通信线路的质量也是容灾系统的性能指标之一，其中包括网络的数据传输带宽、网络传输通道的冗余和网络服务商的服务水平（网络年中断率）。如果容灾系统使用的通信网络是确定的，为了比较不同容灾解决方案，可以用单位存储容量的数据库在同一通信网络上的数据完全恢复时间作为一项设计指标。
大部分业务系统都是数据库应用结构，但业务系统容灾并不等于是数据库容灾，还包括访问数据库的应用程序和相关配置信息。实现数据库容灾是容灾的基础，在保障数据库数据一致的前提下，还要实现应用程序和配置信息的一致性；实现应用系统的高可用性、应用程序在容灾中心与生产中心接管和切回的过程，因此，还要考虑应用的模式是C/S、B/S，两层、三层、多层次的应用结构等等。
1.1.5 界定灾备系统的总体架构
根据实际需求、现有技术、所在地域、计划防范的灾难种类和预算投入的资金量等实际情况，确定灾备系统预期达到的级别，并以此来确定灾备系统与生产运行系统在地理位置上的距离（同城还是异地或两者兼备－堡垒节点），备份数据存储所在的介质（磁盘还是磁带或两者兼备），备份数据在生产中心与备份中心传输的方式（这就涉及到了具体的计算机存储与网络技术），以及备份中心计算机系统的处理能力和网络接管所需的具体架构（是否与生产中心采用完全同等数量、容量和性能的计算机、
容灾项目设计方案
存储设备和网络体系结构）。
容灾项目设计方案
第 2 章 主流容灾技术说明
2.1 数据备份
数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高端容灾（实时数据保护）的有力保障。目前备份技术主要有快照备份、离线备份、异地存储备份。备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数据库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不能被立刻访问，必须通过相应操作,如恢复等方式使用备份数据。这也解决了高端容灾（实时数据保护）不能解决的问题：人为误操作、恶意性操作等，这类操作，计算机系统是不能区分的，一旦执行，将造成数据中心、灾备中心同时修改；对于数据库系统，在日志方式下，可以通过回滚方式修改，对于文件系统、操作系统等其他配置信息是不能回滚的，将造成毁灭性的结果。因此在建设高端容灾系统的前提，一定要做好本地系统的备份，这是容灾技术的起点。
目前成熟的备份软件有Symantec NetBackup、EMC Legato，IBM TSM，HP Protect Server等等。
2.2 实时数据保护
实时数据保护，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时的保存同一份数据的多份存储，目的是为了避免物理故障，数据不会因为一块磁盘、一个阵列、一台服务器、一个数据中心的故障，而不能访问。
注意，实时数据保护需要以数据备份作为前提，它不能防范人为误操作和恶性操作。
这里我们要强调容灾的目的是让数据在灾难发生时，还能被访问，通过实时数据保护，保证数据的完整性；因此实时数据保护是容灾手段，而不是目的。
目前实时数据保护的技术主要有两种：数据镜像和数据复制。
容灾项目设计方案
2.2.1 数据镜像（Mirroring）
数据镜像（Mirroring）是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。分软件镜像与硬件镜像，它们的的区别就在于实现镜像所需的CPU周期所处的位置。最终，都是根据程序的指令，为硬件（磁盘，以及磁盘上存储的数据）制作一个镜像副本。镜像可以保证两份数据完全一样。镜像软件有Symantec Volume Manager；各硬件厂商都有基于自己阵列的硬件镜像方式。
2.2.2 数据复制（Replication）
数据复制（Replication）是将一个原数据的及其改动，通过后续机制拷贝到另外一处，可以是另一个磁盘、另一个阵列、另一个服务器、另一个数据中心。由于实现的机制不同，又分为同步复制和异步复制两种方式。同步复制，能够确保两份数据完全一致，但对系统的影响较大，一般不会采用；异步复制，通过后续机制，确保将本地改动的数据复制的异地，对系统的影响较小，但数据同步有延迟，是目前实现远程数据同步的主要方法。
根据实现机制，数据复制分为软件方式和硬件方式；硬件方式往往又被称为远程镜像。软件复制有Symantec Volume Replicator；Datacore 等；其中Symantec是基于卷的复制，Datacore是基于block的复制，类似于硬件的复制，纯硬件复制有HDS TrueCopy、EMC SRDF等。其中软件复制是可以跨硬件平台，可以实现多厂商集成，一般硬件复制则是相同品牌之间的磁盘子系统的操作。具有一定的限制性。
2.2.2.1 软件复制
Symantec Volume Replicator(简称VVR)负责远程数据复制。VVR复制基于Volume进行。复制的数据可以是数据库中的数据（文件方式或裸设备方式），数据库日志，复制的数据也可以是各种文件，如应用和数据库配置文件，应用程序，库文件，等等。
容灾项目设计方案
复制的示意图见图四。
VVR与VxVM完全集成在一起。用VxVM管理界面和命令统一配置管理；由于VVR仅仅将Volume上每次I/O的实际数据实时复制到远程节点，所以在网络线路上传输的数据量很少，对带宽的需求也很小，因此也与应用无关，只要是在定义的复制卷上的任何操作，都会被复制到异地。
Datacore则是基于软件的块设备复制，处于卷的更底层，属于块设备的远程复制，与基于卷的复制不同的是，他具有应用操作系统的独立性，数据的远程复制与操作系统无关，并且不需要远端主机应用系统的运行，支持异步和同步的方式，并且与硬件存储子系统不同的是，Datacore可以实现异构存储子系统的集中管理，打破了单一厂商选择的限制，对于磁盘子系统的选择更加灵活。其复制示意图如下：
容灾项目设计方案
通过整合原有存储子系统以及新购的存储子系统，将数据的改动记录在
Datacore的SDS设备当中，采用存储转发的传输机制，利用cache的技术和buffer的技术，记录数据的改变，然后通过传输机制将所有应用的数据传输到对端，该软件支持一对多的远程复制。类似于硬件复制，但是可以不受品牌限制。
2.2.2.2 硬件复制
以EMC的SRDF为例，如下图：
1．系统定期检测磁盘物理数据块的改变状况。
容灾项目设计方案
如果发现有数据块改动，将会被系统记录，并一次性将改动过的数据块考到复制缓存，这一动作被称为Switch。
拷贝到缓存中的数据块，在下一个Switch来临之前，被复制到异地相应的阵列缓存中。
容灾项目设计方案
在下一个Switch时，本地数据块被复制到本地存中，而异地缓存中上一次被改动过的数据块才被复制到容灾系统中。
根据实应用范围，数据复制分为应用复制、数据库复制、卷复制、控制器复制。
应用复制，是指通过应用系统直接向原生产中心和容灾中心同时发交易，生产中心和容灾中心都处理成功，该笔交易才算成功；只要有一边应用处理失败，该笔交易
容灾项目设计方案
就算失败。由于交易的延迟性较大、健壮性较差，应用复制一般不会考虑。
SITE A SITE B
应用 数据库 操作系统 控制器 交易 应用 数据库 操作系统 控制器 SQL/Log IO Log 数据块 物理磁盘
2.2.2.3 数据库复制
物理磁盘
数据库复制，如Oracle 的Data Guard、Quest SharePlex、DSG RealSync等，通过分析数据库Redo Log和Archive Log 实现日志的复制，将分析结果直接或转化为SQL语句传到容灾中心，在容灾中通过心Aply数据库日志或将日志转化的SQL语句重做，来保证数据库数据的一致性。数据库复制实际上是应用复制的数据库实现，复制方式通过异步完成。
卷复制如上Symantec Volume Replicator。
控制器复制，如上EMC的复制过程。
容灾项目设计方案
2.2.2.4 Datacore SDS
实际上还有一种新的复制方式，称为基于SAN网络的卷复制，如Datacore的SDS。它是通过特殊的运行于操作系统上的SDS SAN 控制器，实际是将低端的无智能存储变为高端的智能存储，使得他们得以建立基于智能SAN 控制器的卷，通过这种与主机应用无关，但与SDS控制器直接相关的卷实现复制。此种技术较新，目前具有多家厂商均向此方向发展，其中Datacore是较早的研发厂商，当中还有IBM的SVC和HDS的USP系列也是采用此种技术。
2.3 应用系统恢复
正如前所述，数据复制是容灾的手段，不是目的，容灾的目的是数据的访问。因此应用的恢复和以下的网络的恢复也是容灾的关键。
应用系统恢复，这和系统的应用模式直接相关。需要考虑应用系统的应用架构。是Client/Server架构，还是Broswer/Server架构；是2层架构、还是3层架构、还是多层架构。两层架构，表示容灾中心的应用只要启动数据库就可以服务了。如果是三层架构，就意味着应用系统除数据库以外，还有网络服务程序，如中间件Tuxedo、CICS、WebLogic、WebSphere、9iAS、SAP等等。在容灾应用切换时，能够手工或自动化的将这些服务一一启动。
2.4 网络系统恢复
在灾难发生后，应用切换到灾备中心了，本地的应用前端需要重新访问容灾节点的服务，带来另外一个问题，网络如何切换？是建立新的网络，还是使用动态路由，还是有其它办法？实际上最简单的办法，就是通过外部DNS服务器，改变服务器名和IP的映射关系，将原服务器名映射到新的IP地址上，就可以利用容灾网络，实现前端对容灾中心服务器数据的访问。
容灾项目设计方案
2.5 容灾切换过程
就是在灾难发生后，数据库切换、应用重新启动、网络实现切换等等,容灾中心接管原生产中心的整个过程；同时还包含了在原数据中心修复后，数据库、应用、网络需要重新切会来的整个过程。这些过程，可以通过手工切换、也可以通过自动化过程完成。
2.6 消防演习
大部分的容灾方案，在项目实施后，很难有机会来实现预演，因为对于大部分方案来说，这种预演活动，需要耗费大量的人力财力。
但是消防预演是必不可少的，它是实时测试目前的容灾方案的漏洞，保证容灾方案在灾难发生时，能够真正生效。
容灾项目设计方案
第 3 章 主流容灾技术分析与对比
没有一种技术可以解决所有得IT问题，因此，也没有一个解决方案是完美无缺得，依据现状、技术要求、和未来的拓展，我们在此讨论的是最合适容灾技术的解决方案。
3.1 数据备份
SHARE 78评审标准中，Tier 0、Tier 1、Tier2级别容灾要解决的问题。
如前面所阐述的，数据备份是容灾系统的起点，是最低端的容灾方案。不是说有了高端的实时容灾方案，就可以不要备份系统了，因为实时容灾不能解决恶性操作、误操作等故障，而备份系统可以解决。
在此我们要讨论的是，如何利用现有的备份系统，是容灾方案更加完备。
备份软件必须具备跨平台能力, 对目前所有的操作系统AIX、Solaris、HP－Unix、Windows、数据库Oracle、SQL Server、DB2、SybaseASE等，备份软件除了要可以很好的备份相关的文件系统数据、数据库系统数据外，同时必须要满足系统的裸机快速恢复功能，减少系统重建时间，可以对AIX、Solaris、HP－Unix、Windows、Linux操作系统实现备份，备份这些操作系统的相关补丁、外设驱动程序、相关的文件系统配置信息、相关的卷配置信息、内核参数等。在灾难修复时，可以通过恢复的方式快速恢复相关操作系统。实际经验，操作系统安装、打补丁，安装相关驱动程序、恢复内核参数、恢复文件系统配置、恢复卷管理系统配置等整个过程，可以缩短在1小时内完成，并且降低了人为错误操作过程。这样大大提高了原生产中心容灾恢复的能力。
目前市场上的备份产品，Veritas是市场占有率最高，功能相对较全的产品，其他备份产品，或没有类似与BMR的模块；或是不能支持AIX、Solaris、HP－Unix、Windows、Linux全部操作系统，这些用户可以根据实际情况来选择。
备份软件还必须对远程磁带具有管理功能，可以实现对备份数据的自动拷贝，并
容灾项目设计方案
实现异地存放和管理。－Share 78 中 Tier 1 、Tier 2级别容灾。
3.2 实时数据保护
SHARE 78评审标准中，Tier 3级别容灾。
3.2.1 数据镜像（Mirroring）
数据镜像分软件镜像与硬件镜像。
3.2.1.1 硬件镜像
通过硬件级别的Raid-1实现，其实现过程简单，但要求严格。只能基于同一厂商、同一阵列、同样容量大小的两块磁盘来实现。基本上硬件的磁盘子系统供应商都提供能够实现此种功能的设备，但一般价格较高，投入大，并且只能限定在同一厂商品牌。
3.2.1.2 软件镜像
软件镜像可以实现逻辑卷级镜像，对存储空间要求较低，只要有空间且至少两块磁盘就行。不要求同一厂商、同一阵列、同样容量大小的两块磁盘，软件镜像能够实现跨厂商、跨阵列的镜像，在磁盘空间不均时，能够实现1块磁盘对多块磁盘、N块磁盘对M块磁盘的镜像。软件镜像的产品有Symantec的Storage foundation，这种软件通常安装在主机上，通过主机的线程对镜像进行控制。
容灾项目设计方案
3.2.1.3 软件智能存储镜像
目前新兴的虚拟存储技术，使得让原来非智能的存储可以实现智能化，改变了原来只有高端存储才具有的智能功能的局面，这种智能的控制器软件可以实现存储间的镜像和存储内部的硬盘镜像，同时，此种软件的可以实现跨厂商的磁盘子系统设备的镜像。
3.2.1.4 镜像技术在容灾中的利用
在通过SAN的支持，DWDM的拓展，光纤网络可以扩展到100公里或更远，镜像可以在较远的两个数据中心的磁盘上建立。但由于镜像系统是以同步方式实现的，受到距离、光纤协议、和相关协议转换的影响，同步方式会影响本地服务器的性能，所以，一般建议在<20公里的同城容灾中使用，在远程容灾中可作为一种加强方案与远程容灾方案整合，将在我们的详细方案中描述。
常说的基于硬件的远程磁盘镜像，实际上是远程磁盘复制，不是真正意义上的镜像。我们将在后续文章描述。
基于SAN的镜像，在容灾实现中，使用范围较小，如上说述，适用于同城容灾，但支持所有的类型数据同步，包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等，因而支持各类应用系统容灾，包括数据库、中间件、客户自己开发的应用，适用于2层架构、3层或多层应用架构。
3.2.2 数据复制（Replication）
数据复制是运程容灾实现的基础。
容灾项目设计方案
3.2.2.1 软件复制（卷复制）
卷复制软件负责远程数据复制。复制基于卷进行，将数据特别是需要进行远程复制的相关文件系统、数据库、裸设备、应用程序等，存放在复制卷组中，系统便能自动同步本地和异地相应的复制卷组。
卷复制软件与卷管理软件完全集成在一起。由于卷复制软件仅仅将卷上每次I/O的操作复制到远程节点，复制的信息是卷的日志，所以在网络线路上传输的数据量很少，对带宽的需求也较小。；
基于卷的日志（SRL：先进先出）保正了再极端情况下，如容灾网络中断、数据复制不能正常进行，容灾中心数据于生产中心数据有延迟，在一切故障排除后，能够严格保证所以I/O的写顺序，这类似于数据库数据块和数据库日志的关系，通过带时间戳的数据块和顺序日志，保证数据的一致性。
基于软件的远程复制，在容灾实现中，使用范围最广，支持所有的类型数据同步，包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等，支持各类应用系统容灾，包括数据库、中间件、客户自己开发的应用，适用于2层架构、3层或多层应用架构。
3.2.2.2 硬件复制
通过基于硬件的远程磁盘镜像实现，其实现要求严格。只能基于同一厂商、同型号阵列、同样容量大小的两个阵列来实现。厂商一般建议使用间歇性复制。
远程磁盘镜像（复制），在容灾实现中，支持所有的类型数据同步，包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等，支持各类应用系统容灾，包括数据库、中间件、客户自己开发的应用，适用于2层架构、3层或多层应用架构。与应用无关，但与磁盘阵列直接相关。只能基于同一厂商、同样容量大小的两个阵列来实现。受光纤线路影响、复制数据量大，在使用间歇性复制时，数据延迟
容灾项目设计方案
大，磁盘容量要求4倍于源数据，并且在极端情况下，不能保证数据一致性。
硬件复制的过程，在上文已经描述。下面我们将描述极端情况。
磁盘复制在生产中心和容灾中心复制的是改动过的物理数据块，而物理数据块的写是无序的。为了保证数据的一致性，通过带时间戳的数据块，改善了一定的数据块的无序性，但仍然不能解决。我们看到，数据库是通过带时间戳的数据块和联机日志一起来解决，如果一个数据文件中的数据块的时间戳不一致，数据库需要日志来修正，日志中记录的是一些有序的数据库操作，通过Recover的动作，将不一致的数据文件，前滚或后滚到某一特定时间点。带时间戳的数据文件和有序的日志，二者缺一不可，否则不能保证数据的一致性。在磁盘复制中，唯独少了至关重要的磁盘写日志（不可能有）。更有甚，如果这种磁盘块的无序写，发生在数据库的联机日志上，那将对数据库数据的一致性造成破坏。
3.2.2.3 基于软件控制器的复制
基于软件控制器的复制，打破了基于硬件的复制的单厂商设备的限制，并且具有更大的灵活性，通过建立虚拟磁盘卷的镜像关系，真正可以建立数据的镜像，其与软件复制的不同之处又在于其对应用的无关性，这点又与基于硬件的复制相同。
在前面我们提到基于块设备复制的应用无关性，但是也具有对数据库的数据一致性的问题，所幸的是这种基于软件控制器的复制可以具有比基于纯硬件复制更多的定制功能，可以对数据库的数据一致性提供支持，其实现的方式是在数据库的运行主机上安装agent或者是编写脚本的方式实现，并且脚本与软件控制器想结合，从而保证数据库的数据复制一致性，防止在极端情况下的数据损失。
我们可以认为基于软件控制器的数据复制是一种介于卷复制和硬件控制器复制之间的数据复制方式。并且解决了单一硬件厂商平台的限制，是未来的主流发展方向。
3.2.2.4 数据库复制
数据库复制，如Oracle 的Data Guard、Quest SharePlex、DSG RealSync等，
容灾项目设计方案
通过分析数据库Redo Log和Archive Log 实现日志的复制，将分析结果直接或转化为SQL语句传到容灾中心，在容灾中通过心Aply数据库日志或将日志转化的SQL语句重做，来保证容灾中心数据与生产中心数据一致。
数据库复制也存在一定的限制，在简单的环境中，实现两个较小的数据库数据同步，可以说是一个简化的解决方案。对于容灾环境，其部分限制如下。
数据库复制，是专门针对相应数据库的，只能实现单一的数据库复制。现有的数据库就有Oracle ,SQL Server，DB2，Sybase ASE。在容灾系统中，如果使用数据库复制方式，管理员将要维护Oracle 一套、SQL Server一套、DB2一套、等相互各不相同的数据库复制技术，管理和维护工作根本不能保证其能够正常运行。
下面我们就以Oracle为例，虽然有众多厂商、技术方案支持的数据库复制，仍然有不可逾越的技术障碍。
Oracle 数据库的容灾复制被称为Standby Database, 其产生于Oracle 7.3，在Oracle 9i后，改称为Data Guard。Standby Database 又分为Physical Standby，和Logical Standby。Physical Standby方式是将生产中心产生的数据库redo log和archive log，不停复制到容灾中心，不停的apply log，来实现容灾中心的数据库与生产中心一致。Logical Standby，是通过解析redo log和archive log，产生相关的SQL 语句，把这些语句传到容灾中心重做。Quest SharePlex 和DSG 的Realsync类似与Data Guard 的Logical Stand by，复制SQL语句。
1．容灾的目的是使数据能够被正常访问，业务能够正常运行。数据库复制技术，不是一个完整的容灾解决方案，只能有限的复制数据库数据，不能复制其他的应用程序，配置文件，就是Oracle自己的tnsnames.ora, listner.ora，initSID.ora, *.ctl也不能复制，一旦这些文件改动过，将需要管员人为操作或者需要其他软件的管理，保证容灾中心与生产中心同步应用、程序、配置文件同步。
2．由于Data Guard 是通过日志来实现的，这要求数据库必须运行在归档日志模
容灾项目设计方案
式下。但我们知道，并不是所有的数据库操作都写日志：oracle 的DML（Data Manipulation Language）或DDL（Data Dictionary Language）语句是不能被复制的，如create index、table，alter table等等；触发器、存储过程操作不能被复制；系统升级、patchs更新不能被复制。
3．与备份软件的冲突。如前所述，对于核心应用系统，数据备份必不可少。对于数据库的备份，也要求数据库在归档模式下运行。备份系统在备份作用发起时，需要备份数据文件、control file、归档日志、甚至需要数据库实现强制归档，来备份归档日志，备份作业成功后，由备份系统自动删除备份过的归档日志，应为当数据库运行在归档日志模式下时，归档日志往往因数据库繁忙而快速大量产生，需要备份软件自动清除维护，否则当归档日志空间占满后，联机日志不能归档时，生产数据库不在运作，则所有应用业务不能操作，酿成生产事故。为了不影响生产环境，问题一，在备份作业发起，强制归档；备份完成后，删除归档日志后，数据库复制软件，该如何操作，将严重造成生产中心和容灾中心数据不一致。如果备份作用不删除归档日志，系统管理员将不定时的来维护归档目录，他必须知道本地归档目录中，哪一个归档日志已经被备份，通过检查容灾中心数据库中哪一个归档日志已经被apply，这将是一个恶梦一样的维护工作。
4．极限情况下的危害。当生产中心和容灾中心的复制链路一定时期内不能恢复时，同样需要在生产主机中保留所有的归档日志，这又需要管理员大量的维护工作。
3.3 应用系统恢复
对于核心的应用环境，在实现容灾前，一般都要求在本地实现高可用性，通过集群软件，保证应用、数据访问在服务器级故障，如网卡、IP、操作系统、磁盘、其他相关应用的故障时，能够自动切换到另外一台可用的服务器上，能够被用户继续访问。容灾应用切换，就是把这种高可用性的应用，拓展到广域网上。
容灾项目设计方案
也就是说通过HA软件实现生产中心的高可用、实现容灾中心应用的自动启动、实现生产中心在灾难修复后应用的回切过程。
目前主流的高可用方案主要有Symantec VCS、IBM HACMP、HP MC/Service Guard、Sun Cluster、Windows CCS 等。
各厂商软件的名字上，我们就可以看到他们的不足。只能支持自己的平台。也就是意味着如果使用他们的解决方案，得分别熟悉AIX、HP－Unix、Solaris、Windows，得在分别熟悉IBM HACMP、HP MC/Service Guard、Sun Cluster、Windows CCS软件，并且这些软件大部分只提供命令行管理、调试方式，这在管理上又是一大难题。
Symantec VCS 则是目前市场上主流的跨平台集群软件之一，拥有70％的高端应用市场。通过统一得图形化JAVA GUI或Web GUI，提供对AIX、HP－Unix、Solaris、Windows、Linux 所有操作系统平台、所有数据库Oracle、Oracle RAC、SQL Server、Sybase、DB2、所有中间件：Weblogic、WebSphere、9iAs、Tuxedo，甚至是用户自己写得应用程序，实现得集中统一的集群管理和监控。并且能够定义这些服务启动、切换得先后顺序，以确保数据能够快速正常访问。例如在WebLogic Server启动之前，必须先启动Oracle,因为在WebLogic Server 启动是会建立数据库得连接池，如果数据库未启动，WebLogic Server 启动将失败。在灾难发生时，VCS将根据这些服务组之间得关系，先后依次启动各个服务组。大大提供容灾中心服务得接管速度。
容灾项目设计方案
3.4 网络系统恢复
在灾难发生后，本地应用访问路径如何由指向原生产中心改为指向容灾中心。在灾难修复后，又需要指向原生产中心。
我们提到，最简单得方法就是更改外部DNS服务器得IP映射关系。在灾难发生前，IP映射为生产中心服务器；在灾难发生后，IP由映射为容灾中心得服务器；在灾难修复后，IP又映射为生产中心得服务器。
当然，在一些中间件软件中，支持多服务器、多IP得配置，那也是可以考虑的。
容灾项目设计方案
第 4 章 容灾系统设计步骤
如上图，对于容灾系统的建立，我们建议通过分步实施，逐渐建立一套完善的系统容灾解决方案。
第一步，深化数据备份系统； 第二步，存储、应用整合； 第三步，实现远程实时数据保护； 第四步，建立远程切换消防演习机制； 第五步，建立远程切换机制。
4.1 第一步，深化数据备份系统
通过相应的备份软件，对目前所有的计算机系统，做好完善的数据备份，特别是
容灾项目设计方案
做好操作系统备份、文件系统备份、数据库系统文件备份、数据库数据文件备份、相关的核心应用程序备份；建立好完善的备份/恢复机制和远程磁带保管机制。
这也是下一步实现远程数据复制容灾的基础，容灾中心与生产中心的数据初始化同步，都是通过磁带备份恢复方式，实现一个同步起点。
4.2 第二步，存储、应用整合
4.2.1 存储整合
通过相关的产品选择，将各服务器的数据、或应用，通过基于一定的管理及后续，实现数据的快照、镜像等技术，迁移到外置基于SAN的阵列库中，通过唯一的管理接口，实现统一管理，屏蔽不同厂商阵列的差异。
4.2.2 应用整合
通过相应的应用集群管理软件，管理所有的应用系统状态。对现有的数据库系统Oracle、SQL Server、DB2、Sybase、中间件等应用，实现双机、多机或是单机集群管理。操作系统平台相同的，可以整合在一起，实现多机集群，不同的数据库实例，只是作为一个“数据库服务组”，运行在多机或双机中的某一台服务器上，为中间件、其他应用建立“应用服务组”，也纳入到集群软件的管理；并且动过集权软件建立“应用服务组”与“数据库服务组”或其他“应用服务组”的依赖关系，实现对应用启动、关闭的有序管理。
如果是Oracle RAC的应用，则需要集权软件支持，因此在选择集权管理软件时要纳入考虑因素，通过RAC的支持使得数据库的 RAC应用也在集群软件的管理之下。
容灾项目设计方案
4.3 第三步，实现远程实时数据卷保护
通过第二步的存储和应用整合，使得所有需要容灾的核心系统，全部纳入到一个统一的管理平台之下，我们将规划好应用数据的存放方式、数据文件的存放地点、日志的存放地点，然后统一为这些数据指定一定的存储策略，实现远程数据复制。
4.4 第四步，建立远程切换消防演习机制
在数据库复制初始化完成，相关应用复制完成，就可以实现相关应用的消防演习了。这是保证容灾系统正常唯一的、最有效的手段，整个过程生产中心应用在线。
对数据库实现快照； 启动数据库； 启动相关的应用；
通过压力程序或测试程序验证应用。
4.5 第五步，建立远程切换机制
确定外部DNS服务器对本地服务器与容灾中心服务器IP地址的对应关系，确定GCO对DNS 更新的内容。
容灾项目设计方案
第 5 章 数据容灾的性能分析
5.1 同步数据容灾的性能分析
利用同步传输方式建立异地数据容灾，可以保证在本地系统出现灾难时，异地存在一份与本地数据完全一致的数据备份。但利用同步传输方式建立这样一个系统，必须考虑“性能”这个因素。
采用同步数据传输方式时，从前面的描述来看，本地系统必须等到数据成功的写到异地系统，才能进行下一个I/O操作。一个I/O通过远程链路写到异地系统，涉及到3个技术参数：带宽、距离和中间设备及协议转换的时延。
5.1.1 带宽
本地I/O的带宽是100MB/秒，在I/O流量很大的情况下，如果与远程的I/O带宽相对“100MB/秒 == 800Mbit/秒”窄得多的话，如E1：2Mbit/秒；E3：45Mbit/秒，将会明显拖慢生产系统的I/O，从而影响系统性能。
5.1.2 距离
光和电波在线路上传输的速度是30万公里/秒，当距离很长时，这种线路上的延时将会变得很明显。例如：一个异地容灾系统的距离是1000KM，其数据库写盘的数据块大小是10KB（一次I/O的数据量），那么：
•
本地I/O时（100米距离内）：
= 0.1km/300,000km*2次/一个来回
光电在线路上的延时
= 0.67 * 10-6 秒
容灾项目设计方案
1秒钟内允许I/O次 1秒钟允许的I/O量
= 1/（0.67 * 10-6 ）= 1.5 * 10-6 次 = 10KB * 1.5 * 10-6 = 15GB
此数字远远超过光纤通道带宽本身，也就是说，光电在100米距离的线路上的延时对性能的影响可以忽略不计。
•
光电在线路上的延时
1秒钟内允许I/O次 1秒钟允许的I/O量
此数据表明，在1000公里距离上，允许的最大I/O量在不存在带宽限制时，已经远远低于本地I/O的能力。（注：上面分析还未考虑中间设备及协议转换的延时）。
= 1/（1/150 ）= 150次 = 10KB * 150 = 1.5MB
= 1000km/300,000km*2次
异地I/O的（1000公里）：
= 1/150 秒
5.1.3 中间链路设备和协议转换的时延
中间链路设备和协议转换的方式的不同，时延不同，对性能的影响也不同。在对性能影响的分析中，这个因数也应计算在内。目前不同异地数据复制技术所依赖的介质和协议不同，我们将介质、协议和大概时延例表如下，这里提供的数据只精确到数量级，仅供参考，实际数据应该像设备供应上索取。
链路设备和协议 租用线路 ESCON LAN ATM
带宽 任意 136Mbit 1000Mbit 655Mbit 支持的距离 不受限制 66公里 10公里 不受限制 设备和协议转换时延 约1ms（1毫秒） < 100us (100微秒) < 100us < 100us 容灾项目设计方案
IP over FC FC 下面是一个线路时延分析对照表，供参考。 线路时延 / 次 I/O 支持的链路和协议 1000KM 6ms 租用线路 ATM 距离 100KM 600us 租用线路 ATM 10KM 60us 租用线路 ATM ESCON LAN IP over FC FC 本地磁盘 I/O能力 本地 Cache I/O 能力 在1000公里和100公里距离上，采用租用线路和ATM，允许的最大I/O能力（假定带宽足够，数据块大小以10KB为例）： 1000公里 租用线路 线路时延 / 次 I/O 设备和协议时延 写单个盘/写Cache (即本地写响应时间) I/O次数，次 / 秒 I/O 能力，MB/秒 每个I/O响应时间
125~140 1.2~1.4 > 8ms 140~160 1.4~1.6 > 7ms 380~600 3.8~6 > 2.6ms 590~1400 5.9~14 1.7ms 6ms > 1ms 1ms/50ns ATM 6ms < 100us 1ms/50ns 100公里 租用线路 600us > 1ms 1ms/50ns ATM 600us < 100us 1ms/50ns 10MB / 每个磁盘*秒 = 10KB/ms 50ns 800Mbit 800Mbit 60公里 60公里 < 100us < 10us 容灾项目设计方案
I/O流量（MB/秒） 32KB块/写Cache 备注 在10公里距离上，采用各种传输协议允许的最大I/O能力，数据块大小以10KB为例（假定带宽足够）： 租用线路 ATM LAN 线路时延/次 设备协议时延 写单盘/写Cache I/O次数/秒 I/O MB/秒 备注 60us > 1ms 1ms/50ns 485-930 4.8-9.3 60us < 100us 1ms/50ns 900-5800 9-58 10公里 ESCON IP over FC 60us < 100us 1ms/50ns 900-5800 9-58 适合用同步传输 60us < 10us 1ms/50ns 900-12500 9-125 FC 不适合用同步传输 不适合用同步传输方式 4.5 5.3 20 45 5.2 异步数据容灾的性能分析
从前面的分析来看，同步数据容灾一般只能在较短距离内部署（10KM-100KM），大于这个距离，就没有实际应用价值了。因为即使在1000KM距离上，4.5MB的速率足够将数据复制到异地，每个I/O的响应时间也会超过10ms，这种响应速度太慢。
异步数据容灾主要是针对“线路带宽和距离能保证完成数据复制过程，同时，希望异地数据复制不影响生产系统的性能”这样的要求下提出来的。考虑异步数据容灾，应该注意到以下几个技术条件 和事实。
容灾项目设计方案
1. 带宽必须能保证将本地生产数据基本上完全复制到异地容灾端，还要考虑距
离对传输能力的影响。
按照前面的估算：在1000公里范围内，一条带宽足够的线路能支持的I/O流量最大为（数据块大小10KM ）：1.4MB×3600秒×24小时=120GB/天
2. 异地容灾端数据虽然落后,但必须保证该数据库内在的数据完整性（一致
性）、可用性，否则，这种数据复制就没有应用价值了。
3. 异地容灾端数据会比本地生产端数据落后一定时间,这个时间随采用的技
术，带宽、距离、数据流特点的不同而不同。 4. 异步容灾基本不影响本地系统性能。
与同步传输方式相比，异步传输方式对带宽和距离的要求低很多，它只要求在某个时间段内能将数据全部复制到异地即可，同时异步传输方式也不会明显影响应用系统的性能。其缺点是在本地生产数据发生灾难时，异地系统上的数据可能是几分钟以前的数据，即最近几分钟内的交易会丢失。（注：一个经过仔细计算和规划的系统，才能保证其数据丢失只有几分钟。）
通过异步传输模式进行异地数据复制的技术，包括： 1. 基于主机逻辑卷的数据复制方式
2. 基于磁盘系统I/O控制器的数据复制方式 3. 基于软件控制器的数据复制方式
基于主机逻辑卷（Volume），由于采用Log技术作技术保障的数据复制方式，其数据具有较高的完整性保障，而基于磁盘系统I/O控制器的数据复制方式，不能满足前面提到的技术条件二，也即不能保证异地容灾端数据（库）的完整性，所以，这种方式对于基于数据库的应用具有一定的局限性。基于软件控制器的复制由于采用了脚本和控制器的联动，可以支持数据库的文件的一致，但是必须调动脚本的运行时间，在两个脚本运行时间之间的数据会存在不一致的可能性。
容灾项目设计方案
因篇幅问题不能全部显示，请点此查看更多更全内容