容灾项目方案设计.doc

容灾项目方案设计

39 / 39
目 录
第 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 软件复制 13
2.2.2.2 硬件复制 15
2.2.2.3 数据库复制 18
2.2.2.4 Datacore SDS 19
2.3 应用系统恢复 19
2.4 网络系统恢复 19
2.5 容灾切换过程 20
2.6 消防演习 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 应用系统恢复 27
3.4 网络系统恢复 29
第 4 章 容灾系统设计步骤 29
4.1 第一步，深化数据备份系统 30
4.2 第二步，存储、应用整合 31
4.2.1 存储整合 31
4.2.2 应用整合 31
4.3 第三步，实现远程实时数据卷保护 31
4.4 第四步，建立远程切换消防演习机制 32
4.5 第五步，建立远程切换机制 32
第 5 章 数据容灾性能分析 32
5.1 同步数据容灾性能分析 32
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
RTO
企业百分比
0级
无灾备计划
-
-
<0.3%
1级
车辆运送方式
24~48小时
>48小时
<0.1%
2级
车辆运送＋热备份
24~48小时
24小时
90%
3级
电子传送
<24小时
<24小时
6%
4级
活动状态备份中心
秒级
<24小时
<0.5%
5级
两中心、两阶段确认
秒级
<2小时
<0.1%
6级
零数据丢失
零丢失
<2小时
3%

1.1.2.1 Tier 0

Tier 0 - 无异地数据备份(No off-site Data)

Tier 0 被定义为没有信息存储需求，没有建立备份硬件平台需求，也没有发展应急计划需求，数据仅在本地进行备份恢复， 没有数据送往异地。这种方式是最为低成本灾难备份解决方案，但事实上这种灾难备份并没有真正灾难备份能力，因为它数据并没有被送往远离本地地方，而数据恢复也仅是利用本地记录。

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可以实现异构存储子系统集中管理，打破了单一厂商选择限制，对于磁盘子系统选择更加灵活。其复制示意图如下：

通过整合原有存储子系统以及新购存储子系统，将数据改动记录在DatacoreSDS设备当中，采用存储转发传输机制，利用cache技术和buffer技术，记录数据改变，然后通过传输机制将所有应用数据传输到对端，该软件支持一对多远程复制。类似于硬件复制，但是可以不受品牌限制。
2.2.2.2 硬件复制

以EMCSRDF为例，如下图：

1．系统定期检测磁盘物理数据块改变状况。

如果发现有数据块改动，将会被系统记录，并一次性将改动过数据块考到复制缓存，这一动作被称为Switch。

拷贝到缓存中数据块，在下一个Switch来临之前，被复制到异地相应阵列缓存中。

在下一个Switch时，本地数据块被复制到本地存中，而异地缓存中上一次被改动过数据块才被复制到容灾系统中。

根据实应用范围，数据复制分为应用复制、数据库复制、卷复制、控制器复制。

应用复制，是指通过应用系统直接向原生产中心和容灾中心同时发交易，生产中心和容灾中心都处理成功，该笔交易才算成功；只要有一边应用处理失败，该笔交易就算失败。由于交易延迟性较大、健壮性较差，应用复制一般不会考虑。

应用
数据库
操作系统
控制器
物理磁盘
数据块
SITE A
应用
数据库
操作系统
控制器
物理磁盘
SITE B
IO Log
SQL/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网络卷复制，如DatacoreSDS。它是通过特殊运行于操作系统上SDS SAN 控制器，实际是将低端无智能存储变为高端智能存储，使得他们得以建立基于智能SAN 控制器卷，通过这种及主机应用无关，但及SDS控制器直接相关卷实现复制。此种技术较新，目前具有多家厂商均向此方向发展，其中Datacore是较早研发厂商，当中还有IBMSVC和HDSUSP系列也是采用此种技术。

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块磁盘镜像。软件镜像产品有SymantecStorage 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