容灾项目方案设计

容灾项目方案设计 容灾项目设计方案 目 录 第第 1 1 章章容灾技术规范容灾技术规范 .4 4 1.1容灾的总体规划.4 1.1.1技术指标 RPO、RTO .4 1.1.2国际标准 SHARE 78 .5 1.1.2.1Tier 0 .6 1.1.2.2Tier 1 .7 1.1.2.3Tier 2 .7 1.1.2.4Tier 3 .8 1.1.2.5Tier 4 .8 1.1.2.6Tier 5 .8 1.1.2.7Tier 6 .9 1.1.3界定灾备系统的适用范围.9 1.1.4界定灾备建设的目标.9 1.1.5界定灾备系统的总体架构.10 第第 2 2 章章主流容灾技术说明主流容灾技术说明 .1212 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.4Datacore SDS .19 2.3应用系统恢复.19 2.4网络系统恢复.19 2.5容灾切换过程.20 2.6消防演习.20 第第 3 3 章章主流容灾技术分析与对比主流容灾技术分析与对比 .2121 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 4 章章容灾系统设计步骤容灾系统设计步骤 .2929 4.1第一步，深化数据备份系统.30 4.2第二步，存储、应用整合.31 4.2.1存储整合.31 4.2.2应用整合.31 4.3第三步，实现远程实时数据卷保护.31 4.4第四步，建立远程切换消防演习机制.32 4.5第五步，建立远程切换机制.32 第第 5 5 章章数据容灾的性能分析数据容灾的性能分析 .3232 5.1同步数据容灾的性能分析.32 5.1.1带宽.33 5.1.2距离.33 5.1.3中间链路设备和协议转换的时延.34 5.2异步数据容灾的性能分析.36 容灾项目设计方案 容灾技术容灾技术规范规范 作为风险防范系统，灾备系统建设本身在总体规划、方案选择和投产实施后的 管理运行，以及真正面对灾难时的切换操作等方面也存在着潜在的风险。 计算机信息系统实现数据大集、应用大集中后，系统的运行安全成为风险控制 的焦点。目前，已经有多系统开始或准备进行灾备系统的建设，灾备系统建设的目 标是减灾容灾，使计算机信息系统和数据能够最大限度地防范和化解各种意外和灾 害所带来的风险。然而，与大多数工程一样，灾备系统建设本身在总体规划、方案 选择和投产实施后的管理运行，以及真正面对灾难时的切换操作等方面也存在着潜 在的风险。 可以说，风险防范系统本身也存在风险点，需要小心应对。 灾备系统建设中所涉及的潜在风险大致可分为技术风险、管理风险和投资风险， 其中尤以技术选择风险最大，技术方案选择优越，可以规避一定的管理风险和投资 风险。而这三者也存在内在的相互关联，不同灾备级别对应的建设投资规模、所采 用的技术以及实施和管理的复杂度也不同，应考虑保护计算机系统的原有投资并提 高灾备系统建设投资的利用率。 1.1 容灾的总体规划容灾的总体规划 真正的容灾是数据被不间断的一致性访问！ 在灾难备份的世界里，是有等级观念的，级别不同，灾备系统所采用的技术和 达到的功能是不同的，在系统建设资金投入方面的差距也很巨大。所以，对用户来 说，明确灾备系统建设的总体规划十分必要。 1.1.1 1.1.1 技术指标技术指标 RPORPO、RTORTO 容灾项目设计方案 衡量容灾技术的两个技术指标 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 1.1.2 国际标准国际标准 SHARESHARE 7878 要建设容灾系统，就必须提出相应的设计指标，以此作为衡量和选择容灾解决 方案的参数。目前，国际上通用的容灾系统的评审标准为 SHARE 78，主要包括以下 内容。 备份/恢复的范围 灾难恢复计划的状态 容灾项目设计方案 业务中心与容灾中心之间的距离 业务中心与容灾中心之间如何连接 数据是怎样在两个中心之间传送的 允许有多少数据丢失 保证更新的数据在容灾中心被更新 容灾中心可以开始容灾进程的能力 SHARE 78 是建立容灾系统的一种评审标准。建立容灾系统的最终目的，是为了 在灾难发生后能够以最快速度恢复数据服务，主要体现在 RTO Objective)和 RPO 上。 SHARE 78, M028 报告中定义的灾备的七个级别和与其对应的数据丢失量与恢复时间 情况详见下表： 灾难备份等级与业务恢复情况对照表 等级描述 RPORTO 企业百分比 0 级无灾备计划 -48 小时 0.1% 2 级车辆运送热备份2448 小时24 小时 90% 3 级电子传送24 小时24 小时 6% 4 级活动状态备份中心秒级24 小时 0.5% 5 级两中心、两阶段确认秒级2 小时 0.1% 6 级零数据丢失零丢失2 小时 3% 1.1.2.1Tier 0 Tier 0 - 无异地数据备份(No off-site Data) 容灾项目设计方案 Tier 0 被定义为没有信息存储的需求，没有建立备份硬件平台的需求，也没有 发展应急计划的需求，数据仅在本地进行备份恢复， 没有数据送往异地。这种方式 是最为低成本的灾难备份解决方案，但事实上这种灾难备份并没有真正灾难备份的 能力，因为它的数据并没有被送往远离本地的地方，而数据的恢复也仅是利用本地 的记录。 1.1.2.2Tier 1 Tier 1- PTAM 车辆转送方式( Pickup Truck Access Method) 作为 Tier 1 的灾难备份方案需要设计一个应急方案，能够备份所需要的信息 并将它存储在异地，然后根据灾难备份的具体需求，有选择地建立备份平台， 但事 先并不提供数据处理的硬件平台。 PTAM 是一种用于许多中心备份的标准方式，数据在完成写操作之后，将会被送 到远离本地的地方，同时具备有数据恢复的程序。在灾难发生后，一整套系统和应 用安装动作需要在一台未启动的计算机上重新完成。系统和数据将被恢复并重新与 网络相连。这种灾难备份方案相对来说成本较低(仅仅需要传输工具的消耗以及存储 设备的消耗)。 但同时有难于管理的问题，即很难知道什么样的数据在什么样的地 方。一旦系统可以工作，标准的做法是首先恢复关键应用，其余的应用根据需要恢 复。这样的情况下，恢复是可能的，但需要一定的时间，同时依赖于什么时候硬件 平台能够被提供准备好。 1.1.2.3Tier 2 Tier 2 - PTAM 卡车转送方式+热备份中心 (PTAM+Hot Site) Tier 2 相当于是 Tier 1 再加上具有热备份能力中心的灾难备份。热备份中心拥 有足够的硬件和网络设备去支持关键应用的安装需求。对于十分关键的应用，在灾 难发生的同时，必须在异地有正运行着的硬件平台提供支持。这种灾难备份的方式 容灾项目设计方案 依赖于用 PTAM 的方法去将日常数据放在异地存储，当灾难发生的时候，数据再被移 动到一个热备份的中心。虽然移动数据到一个热备份中心增加了成本，但却明显降 低了灾难备份的时间。 1.1.2.4Tier 3 Tier 3 - 电子传送(Electronic Vaulting) Tier 3 是在 Tier 2 的基础上用电子链路取代了车辆进行数据传送的灾难备份。 接收方的硬件平台必须与生产中心物理地相分离，在灾难发生后，存储的数据用于 灾难备份。由于热备份中心要保持持续运行，因此增加了成本。但确实是消除了运 送工具的需要，提高了灾难备份的速度。 1.1.2.5Tier 4 Tier 4 - 活动状态的备份中心 (Active Secondary Site) Tier 4 这种灾难备份要求两个中心同时处于活动状态并管理彼此的备份数据， 允许备份行动在任何一个方向发生。接收方硬件平台必须保证与另一方平台物理地 相分离，在这种情况下，工作负载可以在两个中心之间被分担，两个中心之间之间 彼此备份。在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。在灾 难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢 复时间也可降低到了小时级。 1.1.2.6Tier 5 Tier 5 - 两中心两阶段确认 (Two-Site Two-Phase Commit) Tier 5 是在 Tier 4 的基础上在镜像状态上管理着被选择的数据 (根据单一 commit 范围，在本地和远程数据库中同时更新着数据)，也就是说，在更新请求被 容灾项目设计方案 认为是满意之前，Tier 5 需要生产中心与备份中心的数据都被更新。我们可以想象 这样一种情景，数据在两个中心之间相互映像，由远程 two-phase commit 来同步， 因为关键应用使用了双重在线存储，所以在灾难发生时，仅仅传送中的数据被丢失， 恢复的时间被降低到了小时级。 1.1.2.7Tier 6 Tier 6 - 零数据丢失 (Zero Data Loss) Tier 6 可以实现零数据丢失率，同时保证数据立即自动地被传输到备份中心。 Tier 6 被认为是灾难备份的最高的级别，在本地和远程的所有数据被更新的同时， 利用了双重在线存储和完全的网络切换能力。Tier 6 是灾难备份中最昂贵的方式， 也是速度最快的恢复方式，恢复的时间被降低到了分钟级。对于 Tier 6 的灾难备 份解决方案，可以应用两种远程拷贝技术来实现，即 PPRC 同步远程拷贝和 XRC 异步 远程拷贝。 因此，企业需要根据其计算机处理系统中数据的重要性，以及需要恢复的速度 和程度，来进行灾备系统建设的整体考虑和不同灾难对业务冲击的分析，并最终确 定灾备系统建设的总体规划。 灾备系统建设的总体规划应包括以下几个方面： 1.1.3 1.1.3 界定灾备系统的适用范围界定灾备系统的适用范围 分析不同的应用系统，确定灾备系统是一个覆盖整个计算机系统的工程，根据 业务的重要性，对不同的系统采用不同级别的容灾方案，如针对关键的业务应用子 系统，实施高级别的容灾工程；对低级别的业务系统，实施低级别的容灾工程。总 之要建立一个综合性的整体灾备建设工程。 1.1.4 1.1.4 界定灾备建设的目标界定灾备建设的目标 容灾项目设计方案 生产系统在单位时间内的数据处理能力或 IO 流量确定的情况下，RPO 实际上成 为一个反映灾备恢复过程中的数据丢失量的指标。而 RTO 则是指从灾难发生到备份 系统可以接管原有生产系统所需要花费的时间，这不仅要考虑数据的恢复时间，还 应该考虑恢复后数据的完整性、一致性的修复和确认、备份中心计算机处理系统的 启动和备份中心的网络切换等全部时间。总体规划中应为灾备系统设定明确的 RPO 和 RTO 指标。 但是设计容灾系统不能只看 RTO 和 RPO，对于不同的业务系统和用户特殊的要求， 其它一些指标有可能成为选择容灾解决方案的主要因素。例如，某些地区为了防范 一些特定自然灾害的风险，要求容灾备份中心与业务中心保持足够的距离，在这种 情况下，容灾备份中心与业务中心的距离要求就是容灾系统的重要指标。 通信网络是容灾系统的组成部分，通信线路的质量也是容灾系统的性能指标之 一，其中包括网络的数据传输带宽、网络传输通道的冗余和网络服务商的服务水平 （网络年中断率）。如果容灾系统使用的通信网络是确定的，为了比较不同容灾解 决方案，可以用单位存储容量的数据库在同一通信网络上的数据完全恢复时间作为 一项设计指标。 大部分业务系统都是数据库应用结构，但业务系统容灾并不等于是数据库容灾， 还包括访问数据库的应用程序和相关配置信息。实现数据库容灾是容灾的基础，在 保障数据库数据一致的前提下，还要实现应用程序和配置信息的一致性；实现应用 系统的高可用性、应用程序在容灾中心与生产中心接管和切回的过程，因此，还要 考虑应用的模式是 C/S、B/S，两层、三层、多层次的应用结构等等。 1.1.5 1.1.5 界定灾备系统的总体架构界定灾备系统的总体架构 根据实际需求、现有技术、所在地域、计划防范的灾难种类和预算投入的资金 量等实际情况，确定灾备系统预期达到的级别，并以此来确定灾备系统与生产运行 系统在地理位置上的距离（同城还是异地或两者兼备堡垒节点），备份数据存储 所在的介质（磁盘还是磁带或两者兼备），备份数据在生产中心与备份中心传输的 容灾项目设计方案 方式（这就涉及到了具体的计算机存储与网络技术），以及备份中心计算机系统的 处理能力和网络接管所需的具体架构（是否与生产中心采用完全同等数量、容量和 性能的计算机、存储设备和网络体系结构）。 容灾项目设计方案 第第 2 2 章章 主流容灾技术说明主流容灾技术说明 2.1 数据备份数据备份 数据备份是系统、数据容灾的基础，也是低端容灾的实现，是高端容灾（实时 数据保护）的有力保障。目前备份技术主要有快照备份、离线备份、异地存储备份。 备份系统通过备份策略，对计算机信息系统的操作系统、文件系统、应用程序、数 据库系统等数据集，实现某一时间点的完整拷贝，拷贝的数据处在非在线状态，不 能被立刻访问，必须通过相应操作,如恢复等方式使用备份数据。这也解决了高端容 灾（实时数据保护）不能解决的问题：人为误操作、恶意性操作等，这类操作，计 算机系统是不能区分的，一旦执行，将造成数据中心、灾备中心同时修改；对于数 据库系统，在日志方式下，可以通过回滚方式修改，对于文件系统、操作系统等其 他配置信息是不能回滚的，将造成毁灭性的结果。因此在建设高端容灾系统的前提， 一定要做好本地系统的备份，这是容灾技术的起点。 目前成熟的备份软件有 Symantec NetBackup、EMC Legato，IBM TSM，HP Protect Server 等等。 2.2 实时数据保护实时数据保护 实时数据保护，就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实 时的保存同一份数据的多份存储，目的是为了避免物理故障，数据不会因为一块磁 盘、一个阵列、一台服务器、一个数据中心的故障，而不能访问。 注意，实时数据保护需要以数据备份作为前提，它不能防范人为误操作和恶性 操作。 这里我们要强调容灾的目的是让数据在灾难发生时，还能被访问，通过实时数 据保护，保证数据的完整性；因此实时数据保护是容灾手段，而不是目的。 目前实时数据保护的技术主要有两种：数据镜像和数据复制。 容灾项目设计方案 2.2.1 2.2.1 数据镜像（数据镜像（MirroringMirroring） 数据镜像（Mirroring）是冗余的一种类型，一个磁盘上的数据在另一个磁盘上 存在一个完全相同的副本即为镜像。分软件镜像与硬件镜像，它们的的区别就在于 实现镜像所需的 CPU 周期所处的位置。最终，都是根据程序的指令，为硬件（磁盘， 以及磁盘上存储的数据）制作一个镜像副本。镜像可以保证两份数据完全一样。镜 像软件有 Symantec Volume Manager；各硬件厂商都有基于自己阵列的硬件镜像方 式。 2.2.2 2.2.2 数据复制（数据复制（ReplicationReplication） 数据复制（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 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.4Datacore 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 3 章章 主流容灾技术分析与对比主流容灾技术分析与对比 没有一种技术可以解决所有得 IT 问题，因此，也没有一个解决方案是完美无缺 得，依据现状、技术要求、和未来的拓展，我们在此讨论的是最合适容灾技术的解 决方案。 3.1 数据备份数据备份 SHARE 78 评审标准中，Tier 0、Tier 1、Tier2 级别容灾要解决的问题。 如前面所阐述的，数据备份是容灾系统的起点，是最低端的容灾方案。不是说 有了高端的实时容灾方案，就可以不要备份系统了，因为实时容灾不能解决恶性操 作、误操作等故障，而备份系统可以解决。 在此我们要讨论的是，如何利用现有的备份系统，是容灾方案更加完备。 备份软件必须具备跨平台能力, 对目前所有的操作系统 AIX、Solaris、HPUnix、Windows、数据库 Oracle、SQL Server、DB2、SybaseASE 等，备份软件除了要可以很好的备份相关的文件系统数据、 数据库系统数据外，同时必须要满足系统的裸机快速恢复功能，减少系统重建时间， 可以对 AIX、Solaris、HPUnix、Windows、Linux 操作系统实现备份，备份这些操 作系统的相关补丁、外设驱动程序、相关的文件系统配置信息、相关的卷配置信息、 内核参数等。在灾难修复时，可以通过恢复的方式快速恢复相关操作系统。实际经 验，操作系统安装、打补丁，安装相关驱动程序、恢复内核参数、恢复文件系统配 置、恢复卷管理系统配置等整个过程，可以缩短在 1 小时内完成，并且降低了人为 错误操作过程。这样大大提高了原生产中心容灾恢复的能力。 目前市场上的备份产品，Veritas 是市场占有率最高，功能相对较全的产品，其 他备份产品，或没有类似与 BMR 的模块；或是不能支持 AIX、Solaris、HPUnix、Windows、Linux 全部操作系统，这些用户可以根据实际 情况来选择。 容灾项目设计方案 备份软件还必须对远程磁带具有管理功能，可以实现对备份数据的自动拷贝， 并实现异地存放和管理。Share 78 中 Tier 1 、Tier 2 级别容灾。 3.2 实时数据保护实时数据保护 SHARE 78 评审标准中，Tier 3 级别容灾。 3.2.1 3.2.1 数据镜像（数据镜像（MirroringMirroring） 数据镜像分软件镜像与硬件镜像。 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 3.2.2 数据复制（数据复制（ReplicationReplication） 数据复制是运程容灾实现的基础。 容灾项目设计方案 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 是通过