容灾项目方案设计说明

1、 . . . 1 / 82容灾项目方案设计 . . . 2 / 82目 录第第 1 1 章容灾技术规章容灾技术规 .6 61.1 容灾的总体规划 .61.1.1 技术指标 RPO、RTO .61.1.2 国际标准 SHARE 78 .71.1.2.1Tier 0.81.1.2.2Tier 1.91.1.2.3Tier 2.91.1.2.4Tier 3.101.1.2.5Tier 4.101.1.2.6Tier 5.101.1.2.7Tier 6.111.1.3 界定灾备系统的适用围 .111.1.4 界定灾备建设的目标 .121.1.5 界定灾备系统的总体架构 .12第第 2 2 章主流容灾技

2、术说明章主流容灾技术说明 .14142.1 数据备份 .142.2 实时数据保护 .142.2.1 数据镜像（Mirroring） .152.2.2 数据复制（Replication） .152.2.2.1 软件复制（卷复制） .152.2.2.2 硬件复制 .162.2.2.3 数据库复制 .192.2.2.4IBM SVC.202.3 应用系统恢复 .202.4 网络系统恢复 .202.5 容灾切换过程 .212.6 消防演习 .21第第 3 3 章主流容灾技术分析与对比章主流容灾技术分析与对比 .22223.1 数据备份 .223.2 实时数据保护 .233.2.1 数据镜像（Mirro

3、ring） .233.2.1.1 硬件镜像 .233.2.1.2 软件镜像 .243.2.1.3 镜像技术在容灾中的利用 .243.2.2 数据复制（Replication） .243.2.2.1 软件复制（卷复制） .253.2.2.2 硬件复制 .273.2.2.3 数据库复制 .283.2.2.4 数据库双活 .29 . . . 3 / 823.2.3 瞬间快照(Instant Snapshot) .303.3 应用系统恢复 .313.4 网络系统恢复 .323.5 容灾切换过程 .333.6 消防演习 .33第第 4 4 章某容灾方案主要技术介绍章某容灾方案主要技术介绍 .33334.

4、1 某 NETBACKUP数据备份技术.344.1.1 无限可伸缩性 .344.1.2 平台独立性 .344.1.3 基于策略的集中式管理 .344.1.4 无与伦比的性能 .344.1.5 透明的不间断备份 .344.1.6 支持最新存储硬件 .344.1.7 可伸缩三/四层体系架构 .354.1.7.1NetBackup Master Server.364.1.7.2NetBackup Media Server.364.1.7.3NetBackup Client.364.1.7.4 全球管理与实时报告：NOM .364.1.7.5 先进报表：NetBackup Advanced Repor

5、ter .374.1.7.6 数据库在线备份：Database Agent .384.1.7.7 数据库归档：NetBackup Database Archiver .384.1.7.8 块级增量备份：Block-Level Incremental Backup .394.1.7.9 系统灾难恢复：Bare Metal Restore .394.1.7.10 高速闪备份：NetBackup FlashBackup .414.1.7.11 打开文件备份：Open Transaction Manager .424.1.7.12 磁带库动态共享：Shared Storage Option .424.

6、1.7.13 无主机备份：NetBackup ServerFree Agent .434.1.7.14 磁带容灾和管理：NetBackup Vault .434.1.7.15 网络存储备份：NetBackup for NDMP .444.1.7.16 备份数据加密：Client Encryption Option .454.1.7.17 磁带库驱动：Tape Library Support .454.1.7.18 其它功能 .454.2 某 STORAGE FOUNDATION.464.2.1 某 Volume Manager.474.2.1.1 更高的系统与应用性能 .474.2.1.2 数

7、据完整性提高，停机时间缩短 .474.2.1.3 硬件与软件投资保护 .474.2.2 某 File System.484.2.2.1 用户与管理员工作效率提高 .484.2.2.2 可靠的系统数据带来可靠的业务解决方案 .484.2.2.3 简单而强大的系统管理功能 .484.2.3 某 Storage Foundation 解决方案说明 .484.2.3.1 性能、可用性与安全性 .494.2.3.2 可扩展性 .504.2.3.3 集中式管理 .51 . . . 4 / 824.2.3.4 异类环境支持 .524.2.3.5 优异的集成性能 .524.2.4 逻辑卷快照 .534.2.5

8、snapshot 快速重镜像(FastResync) .534.2.6 动态拆分和重组（Dynamic split and Join） .544.2.7 逻辑卷快照技术的特点 .544.2.8Snapshot 如何工作 .544.2.9 瞬间快照(Instant Snapshot) .564.3 领先的企业级高可用性应用软件解决方案 .564.3.1 某 Cluster Server 特征 .574.3.2 领先的异构平台 HA 解决方案 .574.3.3 可伸缩性 .584.3.4 可定制 .584.3.5 补充保护 .584.3.6 灾难恢复解决方案的重要组成成分 .584.3.7 某 C

9、luster Server 特性优势 .594.3.7.1 全面的高可用性特性 .594.3.7.2 最广泛的应用支持 .594.3.7.3 异构平台和存储器支持 .594.3.7.4 行业最具伸缩性的解决方案 .604.3.7.5 多种存储支持 .604.3.7.6 用于集群管理，基于 JAVA 的直觉图形用户界面（GUI） .604.3.7.7 通用原子广播机（GAB） .604.3.7.8 自动集群传播 .614.4 集群的集群 .614.4.1Global Cluster Option 的特点 .614.4.2Global Cluster Option 运作过程 .62第第 5 5 章

10、系统详细设计方案章系统详细设计方案 .64645.1 第一步，深化数据备份系统 .645.2 第二步，存储、应用整合 .655.2.1 存储整合 .655.2.2 应用整合 .655.3 第三步，实现远程实时数据卷保护 .665.4 第四步，建立远程切换消防演习机制 .665.5 第五步，建立远程切换机制 .675.6ORACLE 数据库切换详解 .67第第 6 6 章数据容灾的性能分析章数据容灾的性能分析 .69696.1 同步数据容灾的性能分析 .696.1.1 带宽696.1.2 距离696.1.3 中间链路设备和协议转换的时延 .706.2 异步数据容灾的性能分析 .72 . . .

11、5 / 826.3 有关半同步 .776.4 容灾技术对照 .78第第 7 7 章系统预算章系统预算 .7979第第 8 8 章主要技术的应用实例章主要技术的应用实例 .80808.1 中国联通 .808.2ICON CLINICAL.808.3BLUESTAR.81第第 9 9 章应急预案的编制章应急预案的编制 .82829.1 某技术力量 .829.2 某项目组成员 .83第第 1010 章定期灾难性恢复测试计划与检验章定期灾难性恢复测试计划与检验 .8484第第 1111 章售后服务方式、方法章售后服务方式、方法 .848411.1 某中国技术支持服务中心 .8411.2 技术支持服务介

12、绍 .8411.3 提供支持的流程： .8511.4 某公司向用户提供如下支持服务： .85第第 1 1 章章 容灾技术容灾技术规规作为风险防系统，灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行，以与真正面对灾难时的切换操作等方面也存在着潜在的风险。 计算机信息系统实现数据大集、应用大集中后，系统的运行安全成为风险控制的焦点。目前，已经有多系统开始或准备进行灾备系统的建设，灾备系统建设的目标是减灾容灾，使计算机信息系统和数据能够最大限度地防和化解各种意外和灾害所带来的风险。然而，与大多数工程一样，灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行，以与真正面对灾难时的切换操

13、作等方面也存在着潜在的风险。 . . . 6 / 82可以说，风险防系统本身也存在风险点，需要小心应对。 灾备系统建设中所涉与的潜在风险大致可分为技术风险、管理风险和投资风险，其中尤以技术选择风险最大，技术方案选择优越，可以规避一定的管理风险和投资风险。而这三者也存在在的相互关联，不同灾备级别对应的建设投资规模、所采用的技术以与实施和管理的复杂度也不同，应考虑保护计算机系统的原有投资并提高灾备系统建设投资的利用率。 1.1 1.1 容灾的总体规划容灾的总体规划真正的容灾是数据被不间断的一致性访问！在灾难备份的世界里，是有等级观念的，级别不同，灾备系统所采用的技术和达到的功能是不同的，在系统建设

14、资金投入方面的差距也很巨大。所以，对用户来说，明确灾备系统建设的总体规划十分必要。1.1.1 1.1.1 技术指标技术指标 RPORPO、RTORTO衡量容灾技术的两个技术指标 RPO、RTORPO(Recovery Point Objective): 以数据为出发点，主要指的是业务系统所能容忍的数据丢失量。与在发生灾难，容灾系统接替原生产系统运行时，容灾系统与原生产中心不一至的数据量。RPO 是反映恢复数据完整性的指标，在同步数据复制方式下，RPO 等于数据传输时延的时间；在异步数据复制方式下，RPO 基本为异步传输数据排队的时间。在实际应用中，考虑到数据传输因素，业务数据库与容灾备份数据库

15、的一致性（SCN）是不一样的，RPO 表示业务数据与容灾备份数据的 SCN 的时间差。发生灾难后，启动容灾系统完成数据恢复，RPO 就是新恢复业务系统的数据损失量。RTO(Recovery Time Objective):以应用为出发点，即应用的恢复时间目标，主 . . . 7 / 82要指的是所能容忍的应用停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。是反映业务恢复与时性的指标，表示业务从中断到恢复正常所需的时间。RTO 值越小，代表容灾系统的数据恢复能力越强。各种容灾解决方案的 RTO 有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业

16、务中心与备份中心的高可用管理，这种容灾解决方案具有最小的RTO。容灾系统为获得最小的 RTO，需要投入大量资金。不同容灾方案的 RTO 和 RPO 是不一样的。1.1.2 1.1.2 国际标准国际标准 SHARESHARE 7878要建设容灾系统，就必须提出相应 的设计指标，以此作为衡量和选择容灾解决方案的参数。目前，国际上通用的容灾系统的评审标准为 SHARE 78，主要包括以下容。备份/恢复的围灾难恢复计划的状态业务中心与容灾中心之间的距离业务中心与容灾中心之间如何连接数据是怎样在两个中心之间传送的允许有多少数据丢失保证更新的数据在容灾中心被更新容灾中心可以开始容灾进程的能力 . . .

17、8 / 82SHARE 78 是建立容灾系统的一种评审标准。建立容灾系统的最终目的，是为了在灾难发生后能够以最快速度恢复数据服务，主要体现在 RTO Objective)和 RPO 上。SHARE 78, M028 报告中定义的灾备的七个级别和与其对应的数据丢失量与恢复时间情况详见下表： 灾难备份等级与业务恢复情况对照表等级描述PRORTO企业百分比0 级无灾备计划-48 小时0.1%2 级车辆运送热备份2448 小时24 小时90%3 级电子传送24 小时24 小时6%4 级活动状态备份中心秒级24 小时0.5%5 级两中心、两阶段确认秒级2 小时0.1%6 级零数据丢失零丢失2 小时3%1

18、 1. .1 1. .2 2. .1 1 T Ti ie er r 0 0Tier 0 - 无异地数据备份(No off-site Data)Tier 0 被定义为没有信息存储的需求，没有建立备份硬件平台的需求，也没有发展应急计划的需求，数据仅在本地进行备份恢复， 没有数据送往异地。这种方式是最为低成本的灾难备份解决方案，但事实上这种灾难备份并没有真正灾难备份的能力，因为它的数据并没有被送往远离本地的地方，而数据的恢复也仅是利用本地的记录。 1 1. .1 1. .2 2. .2 2 T Ti ie er r 1 1Tier 1- PTAM 车辆转送方式( Pickup Truck Acces

19、s Method)作为 Tier 1 的灾难备份方案需要设计一个应急方案，能够备份所需要的信息并将它存储在异地，然后根据灾难备份的具体需求，有选择地建立备份平台， 但事 . . . 9 / 82先并不提供数据处理的硬件平台。 PTAM 是一种用于许多中心备份的标准方式，数据在完成写操作之后，将会被送到远离本地的地方，同时具备有数据恢复的程序。在灾难发生后，一整套系统和应用安装动作需要在一台未启动的计算机上重新完成。系统和数据将被恢复并重新与网络相连。这种灾难备份方案相对来说成本较低(仅仅需要传输工具的消耗以与存储设备的消耗)。 但同时有难于管理的问题，即很难知道什么样的数据在什么样的地方。一旦

20、系统可以工作，标准的做法是首先恢复关键应用，其余的应用根据需要恢复。这样的情况下，恢复是可能的，但需要一定的时间，同时依赖于什么时候硬件平台能够被提供准备好。1 1. .1 1. .2 2. .3 3 T Ti ie er r 2 2Tier 2 - PTAM 卡车转送方式+热备份中心 (PTAM+Hot Site)Tier 2 相当于是 Tier 1 再加上具有热备份能力中心的灾难备份。热备份中心拥有足够的硬件和网络设备去支持关键应用的安装需求。对于十分关键的应用，在灾难发生的同时，必须在异地有正运行着的硬件平台提供支持。这种灾难备份的方式依赖于用 PTAM 的方法去将日常数据放在异地存储，

21、当灾难发生的时候，数据再被移动到一个热备份的中心。虽然移动数据到一个热备份中心增加了成本，但却明显降低了灾难备份的时间。1 1. .1 1. .2 2. .4 4 T Ti ie er r 3 3Tier 3 - 电子传送(Electronic Vaulting)Tier 3 是在 Tier 2 的基础上用电子链路取代了车辆进行数据传送的灾难备份。接收方的硬件平台必须与生产中心物理地相分离，在灾难发生后，存储的数据用于灾难备份。由于热备份中心要保持持续运行，因此增加了成本。但确实是消除了运送工具的需要，提高了灾难备份的速度。 . . . 10 / 821 1. .1 1. .2 2. .5 5

22、 T Ti ie er r 4 4Tier 4 - 活动状态的备份中心 (Active Secondary Site)Tier 4 这种灾难备份要求两个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个方向发生。接收方硬件平台必须保证与另一方平台物理地相分离，在这种情况下，工作负载可以在两个中心之间被分担，两个中心之间之间彼此备份。在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。在灾难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢复时间也可降低到了小时级。1 1. .1 1. .2 2. .6 6 T Ti ie er r 5 5Tier 5 -

23、 两中心两阶段确认 (Two-Site Two-Phase Commit)Tier 5 是在 Tier 4 的基础上在镜像状态上管理着被选择的数据 (根据单一commit 围，在本地和远程数据库中同时更新着数据)，也就是说，在更新请求被认为是满意之前，Tier 5 需要生产中心与备份中心的数据都被更新。我们可以想象这样一种情景，数据在两个中心之间相互映像，由远程 two-phase commit 来同步，因为关键应用使用了双重在线存储，所以在灾难发生时，仅仅传送中的数据被丢失，恢复的时间被降低到了小时级。1 1. .1 1. .2 2. .7 7 T Ti ie er r 6 6Tier 6

24、- 零数据丢失 (Zero Data Loss)Tier 6 可以实现零数据丢失率，同时保证数据立即自动地被传输到备份中心。Tier 6 被认为是灾难备份的最高的级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力。Tier 6 是灾难备份中最昂贵的方式， . . . 11 / 82也是速度最快的恢复方式，恢复的时间被降低到了分钟级。对于 Tier 6 的灾难备份解决方案，可以应用两种远程拷贝技术来实现，即 PPRC 同步远程拷贝和 XRC 异步远程拷贝。 因此，企业需要根据其计算机处理系统中数据的重要性，以与需要恢复的速度和程度，来进行灾备系统建设的整体考虑和不同

25、灾难对业务冲击的分析，并最终确定灾备系统建设的总体规划。灾备系统建设的总体规划应包括以下几个方面： 1.1.3 1.1.3 界定灾备系统的适用围界定灾备系统的适用围分析不同的应用系统，确定灾备系统是一个覆盖整个计算机系统的工程，根据业务的重要性，对不同的系统采用不同级别的容灾方案，如针对关键的业务应用子系统，实施高级别的容灾工程；对低级别的业务系统，实施低级别的容灾工程。总之要建立一个综合性的整体灾备建设工程。 1.1.4 1.1.4 界定灾备建设的目标界定灾备建设的目标生产系统在单位时间的数据处理能力或 IO 流量确定的情况下，RPO 实际上成为一个反映灾备恢复过程中的数据丢失量的指标。而

26、RTO 则是指从灾难发生到备份系统可以接管原有生产系统所需要花费的时间，这不仅要考虑数据的恢复时间，还应该考虑恢复后数据的完整性、一致性的修复和确认、备份中心计算机处理系统的启动和备份中心的网络切换等全部时间。总体规划中应为灾备系统设定明确的 RPO 和RTO 指标。 但是设计容灾系统不能只看 RTO 和 RPO，对于不同的业务系统和用户特殊的要求，其它一些指标有可能成为选择容灾解决方案的主要因素。例如，某些地区为了防一些特定自然灾害的风险，要求容灾备份中心与业务中心保持足够的距离，在这种情况下，容灾备份中心与业务中心的距离要求就是容灾系统的重要指标。 . . . 12 / 82通信网络是容灾

27、系统的组成部分，通信线路的质量也是容灾系统的性能指标之一，其中包括网络的数据传输带宽、网络传输通道的冗余和网络服务商的服务水平（网络年中断率）。如果容灾系统使用的通信网络是确定的，为了比较不同容灾解决方案，可以用单位存储容量的数据库在同一通信网络上的数据完全恢复时间作为一项设计指标。大部分业务系统都是数据库应用结构，但业务系统容灾并不等于是数据库容灾，还包括访问数据库的应用程序和相关配置信息。实现数据库容灾是容灾的基础，在保数据库数据一致的前提下，还要实现应用程序和配置信息的一致性；实现应用系统的高可用性、应用程序在容灾中心与生产中心接管和切回的过程，因此，还要考虑应用的模式是 C/S、B/S

28、，两层、三层、多层次的应用结构等等。1.1.5 1.1.5 界定灾备系统的总体架构界定灾备系统的总体架构根据实际需求、现有技术、所在地域、计划防的灾难种类和预算投入的资金量等实际情况，确定灾备系统预期达到的级别，并以此来确定灾备系统与生产运行系统在地理位置上的距离（同城还是异地或两者兼备堡垒节点），备份数据存储所在的介质（磁盘还是磁带或两者兼备），备份数据在生产中心与备份中心传输的方式（这就涉与到了具体的计算机存储与网络技术），以与备份中心计算机系统的处理能力和网络接管所需的具体架构（是否与生产中心采用完全同等数量、容量和性能的计算机、存储设备和网络体系结构）。 . . . 13 / 82第第

29、 2 2 章章 主流容灾技术说明主流容灾技术说明根据 SHARE 78 评审标准，容灾技术必需涵盖了如下容：2.1 2.1 数据备份数据备份数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高端容灾（实时数据保护）的有力保障。目前备份技术主要有快照备份、离线备份、异地存储备份。备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数据库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不能被立刻访问，必须通过相应操作,如恢复等方式使用备份数据。这也解决了高端容灾（实时数据保护）不能解决的问题：人为误操作、恶意性操作等，这类操作，计算机系统是不能区分的，一旦执

30、行，将造成数据中心、灾备中心同时修改；对于数据库系统，在日志方式下，可以通过回滚方式修改，对于文件系统、操作系统等其他配置信息是不能回滚的，将造成毁灭性的结果。因此在建设高端容灾系统的前提，一定要做好本地系统的备份，这是容灾技术的起点。目前成熟的备份软件有某 NetBackup、EMC Legato，IBM TSM，HP Protect Server 等等。2.2 2.2 实时数据保护实时数据保护实时数据保护，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时的保存同一份数据的多份存储，目的是为了避免物理故障，数据不会因为一块磁盘、一个阵列、一台服务器、一个数据中心的故障，而不能访问。注

31、意，实时数据保护需要以数据备份作为前提，它不能防人为误操作和恶性操作。这里我们要强调容灾的目的是让数据在灾难发生时，还能被访问，通过实时数据保护，保证数据的完整性；因此实时数据保护是容灾手段，而不是目的。 . . . 14 / 82目前实时数据保护的技术主要有两种：数据镜像和数据复制。2.2.1 2.2.1 数据镜像（数据镜像（MirroringMirroring）数据镜像（Mirroring）是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全一样的副本即为镜像。分软件镜像与硬件镜像，它们的的区别就在于实现镜像所需的 CPU 周期所处的位置。最终，都是根据程序的指令，为硬件（磁盘，以

32、与磁盘上存储的数据）制作一个镜像副本。镜像可以保证两份数据完全一样。镜像软件有某 Volume Manager；各硬件厂商都有基于自己阵列的硬件镜像方式。2.2.2 2.2.2 数据复制（数据复制（ReplicationReplication）数据复制（Replication）是将一个原数据的与其改动，通过后续机制拷贝到另外一处，可以是另一个磁盘、另一个阵列、另一个服务器、另一个数据中心。由于实现的机制不同，又分为同步复制和异步复制两种方式。同步复制，能够确保两份数据完全一致，但对系统的影响较大，一般不会采用；异步复制，通过后续机制，确保将本地改动的数据复制的异地，对系统的影响较小，但数据同步

33、有延迟，是目前实现远程数据同步的主要方法。根据实现机制，数据复制分为软件方式和硬件方式；硬件方式往往又被称为远程镜像。软件复制有某 Volume Replicator；硬件复制有 EMC SRDF、HDSTrueCopy等。2 2. .2 2. .2 2. .1 1 软软件件复复制制（卷卷复复制制）某 Volume Replicator(简称 VVR)负责远程数据复制。VVR 复制基于 Volume 进行。复制的数据可以是数据库中的数据（文件方式或裸设备方式），数据库日志，复制的数据也可以是各种文件，如应用和数据库配置文件，应用程序，库文件，等等。复制的示意图见图四。 . . . 15 / 8

34、2VVR 与 VxVM 完全集成在一起。用 VxVM 管理界面和命令统一配置管理；由于 VVR仅仅将 Volume 上每次 I/O 的实际数据实时复制到远程节点，所以在网络线路上传输的数据量很少，对带宽的需求也很小，因此也与应用无关，只要是在定义的复制卷上的仍和操作，都会被复制到异地。2 2. .2 2. .2 2. .2 2 硬硬件件复复制制以 EMC 的 SRDF 为例，如下图：1系统定期检测磁盘物理数据块的改变状况。 . . . 16 / 82如果发现有数据块改动，将会被系统记录，并一次性将改动过的数据块考到复制缓存，这一动作被称为 Switch。拷贝到缓存中的数据块，在下一个 Swit

35、ch 来临之前，被复制到异地相应的阵列缓存中。 . . . 17 / 82在下一个 Switch 时，本地数据块被复制到本地存中，而异地缓存中上一次被改动过的数据块才被复制到容灾系统中。根据实应用围，数据复制分为应用复制、数据库复制、卷复制、控制器复制。应用复制，是指通过应用系统直接向原生产中心和容灾中心同时发交易，生产中心和容灾中心都处理成功，该笔交易才算成功；只要有一边应用处理失败，该笔 . . . 18 / 82交易就算失败。由于交易的延迟性较大、健壮性较差，应用复制一般不会考虑。应用数据库操作系统控制器物理磁盘数据块SITE A应用数据库操作系统控制器物理磁盘SITE BIO LogS

36、QL/Log交易2 2. .2 2. .2 2. .3 3 数数据据库库复复制制数据库复制，如 Oracle 的 Data Guard、Quest SharePlex、DSG RealSync 等，通过分析数据库 Redo Log 和 Archive Log 实现日志的复制，将分析结果直接或转化为 SQL 语句传到容灾中心，在容灾过心 Aply 数据库日志或将日志转化的 SQL 语句重做，来保证数据库数据的一致性。数据库复制实际上是应用复制的数据库实现，复制方式通过异步完成。卷复制如上某 Volume Replicator。控制器复制，如上 EMC 的复制过程。 . . . 19 / 822

37、2. .2 2. .2 2. .4 4 I IB BM M S SV VC C实际上还有一种新的复制方式，称为基于 SAN 网络的卷复制，如 IBM 的 SVC。它是通过特殊的设备 SAN 控制器，建立基于 SAN 控制器的卷，通过这种与主机应用无关，但与 SAN 控制器直接相关的卷实现复制。由于技术较新，且只有 IBM 一家推出，未得到其他硬件厂商支持，非主流技术，以下不再阐述。2.3 2.3 应用系统恢复应用系统恢复正如前所述，数据复制是容灾的手段，不是目的，容灾的目的是数据的访问。正如前所述，数据复制是容灾的手段，不是目的，容灾的目的是数据的访问。因此应用的恢复和以下的网络的恢复也是容灾

38、的关键。因此应用的恢复和以下的网络的恢复也是容灾的关键。应用系统恢复，这和系统的应用模式直接相关。需要考虑应用系统的应用架构。是 Client/Server 架构，还是 Broswer/Server 架构；是 2 层架构、还是 3 层架构、还是多层架构。两层架构，表示容灾中心的应用只要启动数据库就可以服务了。如果是三层架构，就意味着应用系统除数据库以外，还有网络服务程序，如中间件Tuxedo、CICS、WebLogic、WebSphere、9iAS、SAP 等等。在容灾应用切换时，能够手工或自动化的将这些服务一一启动。2.4 2.4 网络系统恢复网络系统恢复在灾难发生后，应用切换到灾备中心了，

39、本地的应用前端需要重新访问容灾节点的服务，带来另外一个问题，网络如何切换？是建立新的网络，还是使用动态路由，还是有其它办法？实际上最简单的办法，就是通过外部 DNS 服务器，改变服务器名和 IP 的映射关系，将原服务器名映射到新的 IP 地址上，就可以利用容灾网络，实现前端对容灾中心服务器数据的访问。 . . . 20 / 822.5 2.5 容灾切换过程容灾切换过程就是在灾难发生后，数据库切换、应用重新启动、网络实现切换等等,容灾中心接管原生产中心的整个过程；同时还包含了在原数据中心修复后，数据库、应用、网络需要重新切会来的整个过程。这些过程，可以通过手工切换、也可以通过自动化过程完成。2.

40、6 2.6 消防演习消防演习大部分的容灾方案，在项目实施后，很难有机会来实现预演，因为对于大部分方案来说，这种预演活动，需要耗费大量的人力财力。但是消防预演是必不可少的，它是实时测试目前的容灾方案的漏洞，保证容灾方案在灾难发生时，能够真正生效。第第 3 3 章章 主流容灾技术分析与对比主流容灾技术分析与对比没有一种技术可以解决所有得 IT 问题，因此，也没有一个解决方案是完美无缺 . . . 21 / 82得，依据现状、技术要求、和未来的拓展，我们在此讨论的是最合适容灾技术的解决方案。3.1 3.1 数据备份数据备份SHARE 78 评审标准中，Tier 0、Tier 1、Tier2 级别容灾

41、要解决的问题。如前面所阐述的，数据备份是容灾系统的起点，是最低端的容灾方案。不是说有了高端的实时容灾方案，就可以不要备份系统了，因为实时容灾不能解决恶性操作、误操作等故障，而备份系统可以解决。在此我们要讨论的是，如何利用现有的备份系统，是容灾方案更加完备。正如 Veritas 的备份软件 NetBackup, 对目前所有的操作系统AIX、Solaris、HPUnix、Windows、数据库 Oracle、SQL Server、DB2、SybaseASE 等，Veritas NetBackup 除了可以很好的备份相关的文件系统数据、数据库系统数据外，同时通过 BMR(Bare Metal Res

42、tore:裸金属恢复)模块，可以对 AIX、Solaris、HPUnix、Windows、Linux 操作系统实现备份，备份这些操作系统的相关补丁、外设驱动程序、相关的文件系统配置信息、相关的卷配置信息、核参数等。在灾难修复时，可以通过恢复的方式快速恢复相关操作系统。实际经验，操作系统安装、打补丁，安装相关驱动程序、恢复核参数、恢复文件系统配置、恢复卷管理系统配置等整个过程，可以缩短在 1 小时完成，并且降低了人为错误操作过程。这样大大提高了原生产中心容灾恢复的能力。而其他备份产品，或没有类似与 BMR 的模块；或是不能支持AIX、Solaris、HPUnix、Windows、Linux 全部

43、操作系统，也就是说，不能实现统一的容灾应对策略，反而会增加容灾的复杂度。Veritas NetBackup 还有另外一个叫 Vault 的模块，可以实现对备份数据的自动拷贝，并实现异地存放和管理。Share 78 中 Tier 1 、Tier 2 级别容灾。 . . . 22 / 82Veritas NetBackup 还能构实现快照备份，就是备份时对原盘做磁盘级快照。Veritas NetBackup 可以和 Veritas Volume Snapshot、EMC TimeFinder 等业界主流的快照工具做整合，实现 Server-Free (OFF-Host)的备份，既备份时，原应用服务

44、器不参与的备份，大大提供了备份系统的能力。Veritas NetBackup 针对 AIX、Solaris、HPUnix、Windows、Linux 的备份，无论选择何种平台作为主控服务器、无论如何调整，都是通过同一 Java GUI 和 Web GUI 实现管理，简单易用，用户容易掌握。3.2 3.2 实时数据保护实时数据保护SHARE 78 评审标准中，Tier 3 级别容灾。3.2.1 3.2.1 数据镜像（数据镜像（MirroringMirroring）数据镜像分软件镜像与硬件镜像。3 3. .2 2. .1 1. .1 1 硬硬件件镜镜像像通过硬件级别的 Raid-1 实现，其实现过

45、程简单，但要求严格。只能基于同一厂商、同一阵列、同样容量大小的两块磁盘来实现。3 3. .2 2. .1 1. .2 2 软软件件镜镜像像Veritas Volume Manager 实现逻辑卷级镜像，对存储空间要求较低，只要有空间且至少两块磁盘就行。不要求同一厂商、同一阵列、同样容量大小的两块磁盘，Veritas Volume Manager 能够实现跨厂商、跨阵列的镜像，在磁盘空间不均时，能够实现 1 块磁盘对多块磁盘、N 块磁盘对 M 块磁盘的镜像。 . . . 23 / 823 3. .2 2. .1 1. .3 3 镜镜像像技技术术在在容容灾灾中中的的利利用用在通过 SAN 的支持，

46、DWDM 的拓展，光纤网络可以扩展到 100 公里或更远，镜像可以在较远的两个数据中心的磁盘上建立。但由于镜像系统是以同步方式实现的，受到距离、光纤协议、和相关协议转换的影响，同步方式会影响本地服务器的性能，所以，一般建议在20 公里的同城容灾中使用，在远程容灾中可作为一种加强方案与远程容灾方案整合，将在我们的详细方案中描述。常说的远程磁盘镜像，实际上是远程磁盘复制，不是真正意义上的镜像。我们将在后续文章描述。基于 SAN 的镜像，在容灾实现中，使用围较小，如上说述，适用于同城容灾，但支持所有的类型数据同步，包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等，因而支持各类应用系

47、统容灾，包括数据库、中间件、客户自己开发的应用，适用于 2 层架构、3 层或多层应用架构。3.2.2 3.2.2 数据复制（数据复制（ReplicationReplication）数据复制是运程容灾实现的基础。3 3. .2 2. .2 2. .1 1 软软件件复复制制（卷卷复复制制）VERITAS Volume Replicator(简称 VVR)负责远程数据复制。VVR 复制基于Volume 进行，将数据特别是需要进行远程复制的相关文件系统、数据库、裸设备、应用程序等，存放在复制卷组中，系统便能自动同步本地和异地相应的复制卷组。 . . . 24 / 82复制的示意图见图四。VVR 与 V

48、xVM 完全集成在一起。用 VxVM 管理 GUI 界面和命令统一配置管理；由于VVR 仅仅将 Volume 上每次 I/O 的操作复制到远程节点，复制的信息是卷的日志，所以在网络线路上传输的数据量很少，对带宽的需求也较小。；Storage Replicator Log(简称 SRL)是 VVR 中的重要部件。需要复制的 I/O 操作，首先要写入 SRL，然后传到异地。VVR 通过 SRL 保证数据复制严格按照写顺序进行，这在异步工作方式下非常重要。当网络中断或异地系统出现故障时，本地数据将记录在 SRL 中，当 SRL 满后，VVR 将使用 DCM(Data Change Map)记录变化的

49、数据块的块号，等系统恢复正常时再将 SRL 中的数据按照先进先出的顺序传送到异地，最后再将 DCM 中记录的块传送到异地。 VVR 数据流程见图五： . . . 25 / 82 图五数据复制的工作模式缺省为同步/异步自适应，即在网络延时情况较好、数据能够与时复制时，工作在同步方式，完全保证两边数据的一致性；当网络延时情况较差、数据不能与时复制时，工作在异步方式下，保证主节点的 I/O 性能。数据复制根据实际情况，自行在两种工作模式之间切换。并且基于卷的日志（SRL：先进先出）保正了再极端情况下，如容灾网络中断、数据复制不能正常进行，容灾中心数据于生产中心数据有延迟，在一切故障排除后，能够严格保

50、证所以 I/O 的写顺序，这类似于数据库数据块和数据库日志的关系，通过带时间戳的数据块和顺序日志，保证数据的一致性。基于软件的远程复制，在容灾实现中，使用围最广，支持所有的类型数据同步，包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等，支持各类应用系统容灾，包括数据库、中间件、客户自己开发的应用，适用于 2 层架构、3 层或多层应用架构。 . . . 26 / 823 3. .2 2. .2 2. .2 2 硬硬件件复复制制通过所谓的远程磁盘镜像实现，其实现要求严格。只能基于同一厂商、同型号阵列、同样容量大小的两个阵列来实现。厂商一般建议使用间歇性复制。远程磁盘镜像（复制），

51、在容灾实现中，支持所有的类型数据同步，包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等，支持各类应用系统容灾，包括数据库、中间件、客户自己开发的应用，适用于 2 层架构、3 层或多层应用架构。与应用无关，但与磁盘阵列直接相关。只能基于同一厂商、同样容量大小的两个阵列来实现。受光纤线路影响、复制数据量大，在使用间歇性复制时，数据延迟大，磁盘容量要求 4 倍于源数据，并且在极端情况下，不能保证数据一致性。硬件复制的过程，在上文已经描述。下面我们将描述极端情况。磁盘复制在生产中心和容灾中心复制的是改动过的物理数据块，而物理数据块的写是无序的。为了保证数据的一致性，通过带时间戳的数据

52、块，改善了一定的数据块的无序性，但仍然不能解决。我们看到，数据库是通过带时间戳的数据块和联机日志一起来解决，如果一个数据文件中的数据块的时间戳不一致，数据库需要日志来修正，日志中记录的是一些有序的数据库操作，通过 Recover 的动作，将不一致的数据文件，前滚或后滚到某一特定时间点。带时间戳的数据文件和有序的日志，二者缺一不可，否则不能保证数据的一致性。在磁盘复制中，唯独少了至关重要的磁盘写日志（不可能有）。更有甚，如果这种磁盘块的无序写，发生在数据库的联机日志上，那将对数据库数据的一致性造成破坏。3 3. .2 2. .2 2. .3 3 数数据据库库复复制制数据库复制，如 Oracle

53、的 Data Guard、Quest SharePlex、DSG RealSync 等，通过分析数据库 Redo Log 和 Archive Log 实现日志的复制，将分析结果直接或转 . . . 27 / 82化为 SQL 语句传到容灾中心，在容灾过心 Aply 数据库日志或将日志转化的 SQL 语句重做，来保证容灾中心数据与生产中心数据一致。数据库复制，在简单的环境中，实现两个较小的数据库数据同步，可以说是一个简化的解决方案。对于容灾环境，我们认为大大不合适，原因如下。数据库复制，是专门针对相应数据库的，只能实现单一的数据库复制。现有的数据库就有 Oracle ,SQL Server，DB

54、2，Sybase ASE。在容灾系统中，如果使用数据库复制方式，管理员将要维护 Oracle 一套、SQL Server 一套、DB2 一套、等相互各不一样的数据库复制技术，管理和维护工作根本不能保证其能够正常运行。下面我们就以 Oracle 为例，虽然有众多厂商、技术方案支持的数据库复制，仍然有不可逾越的技术障碍。Oracle 数据库的容灾复制被称为 Standby Database, 其产生于 Oracle 7.3，在 Oracle 9i 后，改称为 Data Guard。Standby Database 又分为 Physical Standby，和 Logical Standby。Phy

55、sical 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容灾的目的是使数据能够被正常访问，业务能够正常运行。数据库复制技术，不是一个完整的容灾解决方案，只能有限的复制数据库

56、数据，不能复制其他的应用程序，配置文件，就是 Oracle 自己的 tnsnames.ora, listner.ora，initSID.ora, *.ctl 也不能复制，一旦这些文件改动过，将需要管员人为操作或者需要其他软件的管理，保证容灾中心与生产中心同步应用、程序、配置文件同步。2由于 Data Guard 是通过日志来实现的，这要求数据库必须运行在归档日志 . . . 28 / 82模式下。但我们知道，并不是所有的数据库操作都写日志：oracle 的 DML（Data Manipulation Language）或 DDL（Data Dictionary Language）语句是不能被复

57、制的，如 create index、table，alter table 等等；触发器、存储过程操作不能被复制；系统升级、patchs 更新不能被复制。3与备份软件的冲突。如前所述，对于核心应用系统，数据备份必不可少。对于数据库的备份，也要求数据库在归档模式下运行。备份系统在备份作用发起时，需要备份数据文件、control file、归档日志、甚至需要数据库实现强制归档，来备份归档日志，备份作业成功后，由备份系统自动删除备份过的归档日志，应为当数据库运行在归档日志模式下时，归档日志往往因数据库繁忙而快速大量产生，需要备份软件自动清除维护，否则当归档日志空间占满后，联机日志不能归档时，生产数据库不

58、在运作，则所有应用业务不能操作，酿成生产事故。为了不影响生产环境，问题一，在备份作业发起，强制归档；备份完成后，删除归档日志后，数据库复制软件，该如何操作，将严重造成生产中心和容灾中心数据不一致。如果备份作用不删除归档日志，系统管理员将不定时的来维护归档目录，他必须知道本地归档目录中，哪一个归档日志已经被备份，通过检查容灾中心数据库中哪一个归档日志已经被 apply，这将是一个恶梦一样的维护工作。4极限情况下的危害。当生产中心和容灾中心的复制链路一定时期不能恢复时，同样需要在生产主机中保留所有的归档日志，这又需要管理员大量的维护工作。3 3. .2 2. .2 2. .4 4 数数据据库库双双

59、活活在 Data Guard 中 PhysicalStandby 模式下，数据库可以通过 read-only 方式打开。正如前面所述，Physical Standby 通过 apply 数据日志，实现数据库复制。但数据库被以 read-only 方式打开时，新的日志将不能被追加，必须将数据库重新切换到 recover 模式下，才能继续 apply 日志。也就是说数据库是被间歇式打开，影响数据库日志的追加不说，试问，什么应用对数据库的操作是间歇式，应用程序也要间歇式的启动和停止。并且在 read-only 方式下，一切在数据库中又修改、增加的操作，都会被以错误方式返回，什么应用不写数据库？ .

60、. . 29 / 82Data Guard 中 Logical Standby 模式下（Quest SharePlex、DSG Realsync 类似）数据库可以被正常打开和操作。这也是需要大量的系统维护工作作为保障的，如前面描述的日志的维护问题。是的，该功能有一定的应用场所，但也是需要高量的管理和维护来保证。因为在这种模式下，生产中心和容灾中心实际上是两个独立的数据库，两个数据库的数据有可能出现不一致的情况。因此，如何确定两个数据库的一致性，又将是一个技术难题，如果不一致，又将以谁为准？容灾中心的数据库数据是生产中心的备份，数据应完全一致，这是容灾的宗旨，为此，我们花费了大量的人力、物力和财