容灾系统建设方案

xｘxxｘxx应用容灾

系统建议方案

ﻩ

目 录

1. 用户需求及针对本需求的容灾系统设计综述................................. 错误!未定义书签。 1.1 应用数据安全级别的分级考虑 ....................................................... 错误!未定义书签。 1.2用户需求分析:ﻩ错误!未定义书签。

１.3 本项目中需要注意的几个要点ﻩ错误!未定义书签。 2．数据容灾系统的详细设计ﻩ错误!未定义书签。

2．1 系统设计原则 ..................................................................................................................... 8 2.2 系统的产品选择ﻩ错误!未定义书签。 ３.3 灾备中心的组建ﻩ错误!未定义书签。

2.4 数据容灾系统的基本结构ﻩ错误!未定义书签。

２.5 数据的远程复制流程 ...................................................................... 错误!未定义书签。 ２.6 数据的远程恢复流程 ........................................................................ 错误!未定义书签。 2.７ 本容灾系统的结构特点 ................................................................... 错误!未定义书签。 2．8 数据容灾系统扩展 ............................................................................. 错误!未定义书签。 2.9系统投资保障ﻩ错误!未定义书签。

3.数据容灾系统与其他方案的简要比较 .................................................. 错误!未定义书签。 4.数据容灾系统的实施计划 ......................................................................... 错误!未定义书签。 4．1 系统实施需求规划ﻩ错误!未定义书签。 4.2 相关性要求/实施步骤21ﻩ

４.3 系统配置清单ﻩ错误!未定义书签。

5.数据容灾系统的测试/验收计划ﻩ错误!未定义书签。

5.1 基本测试及对OＲACLE和其他类型数据的测试ﻩ错误!未定义书签。 5.2 切换及回切的测试ﻩ错误!未定义书签。 ５.3故障测试ﻩ错误!未定义书签。

６.数据容灾系统的日常管理/演练计划ﻩ错误!未定义书签。

７．应用级容灾的规划 ................................................................................... 错误!未定义书签。 8.后续其他节点的扩展规划 ......................................................................... 错误!未定义书签。 1０. EMC REＣＯVＥRPＯＩＮT的维护ﻩ错误!未定义书签。

附件一：美国EMC公司简要介绍 ............................................................. 错误!未定义书签。

2

xxxｘxxx应用容灾系统建议方案

1. 用户需求及针对本需求的容灾系统设计综述

xxｘｘｘxx当前的应用系统类别较多，包括了办公及业务等多个方面。在平台上包括Ｗinｄoｗs及当前主流的多种ＵNＩX，在存储体系上也具有多种型号的存储产品。因此,整个系统的复杂程度较大。同时,由于应用系统一经处于比较完善的程度,因此，任何的调整都将带来很大的影响。

为此，为了确保数据的安全性,在早期用户实施了数据的磁带备份,但对于关键数据来说,这种磁带备份还不能够完全满足系统抵御各种灾难的能力。为此，用户考虑对数据实施灾备计划。

数据的容灾保护提供最基本的容灾底线保证,确保在任何预计之外的灾难发生后,业务系统都可以在允许损失极少量数据(或无损失)的情况下,在一定的时间内恢复,数据容灾同时也是应用逻辑错误和数据库软件ｂｕg的容灾应对出发点；可以通过一定的方式来恢复到这种故障之前的可用的状态。

１.1 应用数据安全级别的分级考虑

鉴于当前存在的大量数据，在安全性的要求上建议分出不同的优先级别，建立不同安全级别的保护措施。这样不仅在成本上会带来优势,同时也可以确保最关键数据的不丢失。

这种分级保护一般根据可以承受的数据丢失量(如半小时，或一天）来考虑。我们不妨把不允许有任何数据丢失的应用定义为安全级别最高,要求进行实时的同步的数据远程传输,对于相对来讲数据安全级别稍低者可以把数据传输的优先级别作相对较低的配置，从而确保在同一时间优先发送最为关键的应用数据。

而对于数据安全要求一般的数据来说,建议采用本地的磁带备份即可，而不必纳入到灾备的体系中来。

这样不仅可以合理使用资金,同时也可以确保关键数据的最高级别保护。

3

1. 2用户需求分析:

用户资料采集：

HP DL580两全DELL6650*2OADELL6650*2WEBHPDS20*2UNIX-oracleIBM690*2OLAP oracleIBM690*2*21,OLTP oracle,db22,portalSUN 6800*2物流Brocade 3900备份服务器DELL 2650Brocade 3900新增盘柜DELL PowerVault136TDELL|EMC CX600DELL|EMC CX700DELL|EMC CX400xxxxxxｘ当前SAN环境（图)

用户需求分析:

1） 数据的实时远程复制

针对关键业务系统数据实现数据的实时的远程复制，从而保障数据在本地发生各种故障之后首先可以保障数据的完整性,并可以通过一定的途径快速得以恢复，或者根据情况在远程直接启动应用。

2） 灾备数据的可处理性，包括对数据的读写操作。

所谓的读操作,是指灾备数据可以为其它的某些临时的应用提供便利，支持对这些数据的读操作。从而可以方便地验证灾备体系的工作是否正常，或者在必要的时候利用这些数据进行诸如员工培训、软件调试、相关系统的引用等多种处理。

所谓的数据读写操作,是考虑利用灾备数据提供诸如员工培训、系统应用测试、后续软件调试或其他临时应用的可能。这样,可以为上述应用带来最大的便利性。但是，为了保持和原始数据的一致性,系统应该支持上述写入操作的Reseｔ(重置)操作,使得在上述任务结束后，可以方便地把数据恢复到没

4

有进行写入操作之前的状态,维持灾备数据和源数据的严格一致。

另外一个方面,数据的读写支持,也可以很方便地验证灾备体系的工作是否正常。

当然，这种读写操作必须要对数据的远程复制和本地的应用不产生任何影响。

2）(远期)应用的可切换支持。

灾备中心不应该作为纯粹的备用系统，在提供诸如数据查询等应用的同时，还要提供自动的应用切换等支持，一旦在生产中心发生故障后,灾备中心的关键系统可以自动接管生产系统,提供持续的应用保障。

这种规划建议作为远期的目标之一，当前建议只以数据的远程复制为主，但当前的方案必须要考虑到本要素。

1.3 本项目中需要注意的几个要点

通过在对用户的具体环境和需求作了细致的分析之后，我们认为用户对该数据容灾系统给以了充分的重视,所提出的观点和要求是十分详细和具体的,在此，从我们方案提供商的角度,对此作如下的概括,便于整体方案的分析。

✓ 方案的通用性。

这种通用性体现在两个方面：一是异构平台、存储设备的支持性,二是对不同应用类型数据的适用性,只有这样的方案才可以较好地保障用户当前投资,达到与应用类型无关、与平台无关以及与磁盘阵列等存储设备无关的适用性最广的解决方案。在当前,数据主要以Oraｃlｅ、ＤB２、SＱL２000类型为主，但是随着应用类型的增加，产生不同类型数据的可能性还是很有可能的。如果现在选用了仅仅支持如Ｏracｌｅ数据的解决方案,那末临时性的其他数据将无法得到及时的复制，或者今后的应用扩展将受到很大的制约。

✓ 实时的数据复制解决方案。

我们认为最终用户已经对不同应用数据的安全性要求做出了很好的分析和划分，其中关键数据要求不丢失,或尽量少地丢失。因此,我们认为必须要采用真正的实时的数据复制解决方案才可以满足这种要求。在条件具备的情况下,应该做到无延迟数据复制。而建议采用非实时或准实时复制方案。

✓ 灾备数据的可用性

分为两个方面，一是数据的实时复制的可靠性,要求复制数据要和源数据保持严格一致,严格按照源数据的写入顺序进行复制,使得灾备数据具有可用性。二是在需要的时候可以很便利地对灾备数据进行读写操作,但是，这种读

5

写操作不应该对数据的实时复制产生影响。还有,在对灾备数据进行修改(如进行员工培训、软件测试等操作时对数据的采集或调整测试）后可以恢复到原有状况,从而确保数据的一致性和安全性。

✓ 扩展的便利性

包括对当前和今后其他应用类型数据的实时复制的扩展，复制距离的扩展以及复制节点数量的扩展等多个方面，在当前选择方案的时候面对未来的需求进行全面考虑。

✓ 数据的丢失量

对于关键应用要求数据不丢失，因此,不建议采用诸如当前在主机上开辟一定的缓存（Bｕffeｒ)空间,用来存放待复制的数据，利用异步的方式发送到远程。这样的产品无疑会因为各种原因导致数据的丢失率较大,如当主机资源意外掉电或宕机时，上述Ｂｕffｅr(缓存)中的数据必然会被丢失。我们推荐在主机产生写入操作的同时数据被发送出去,这样,数据始终保持和本地的写入同步，这样的方案才可以真正做到数据的无丢失。

✓ 数据的可回滚性(最新数据不可用情况下的数据恢复支持）

不可避免地会在某些情况下,最新复制的数据不可用的情况下,尤其对于Orａclｅ数据库,很可能在管理员发现故障时，其内部已经在几分钟之前就已经出现了问题,那末,被复制过去的数据肯定也是不能够被使用的。此时，我们必须要具有数据的回滚性支持,比如可以往前回滚30秒、1分钟或2分钟，并利用这些数据获得可用数据同时数据的丢失量最小化。

✓ 灾备自身系统实施及恢复的便利(简易)性

灾备系统的实施不应该对现有的应用系统作任何调整,尤其是对当前运行较稳定的系统。当然，即使需要一定的调整。那末。这种调整夜必须是系统管理员可以理解并接受的。同样,对于灾备系统自身而言，发生问题后的解决或全面的恢复也要简易化,要支持如ＷEB管理,图形化管理，而不应该需要较复杂的配置。否则,今后如果需要作系统调整，那末,系统管理员将无法面对这种配置和管理，甚至导致日常的维护也不敢动手的现状。

✓ 对系统的影响最小化

由于当前应用系统的完善性和稳定性,不建议为了本灾备系统而对当前的应用系统做任何方面的调整。主机资源不能够因为灾备系统的实施而显得

6

紧张,包括内存、CPＵ等资源的占用应力求最小化。当然这种影响我们认为同样包括实施时候对系统、对数据库、对应用的调整合对存储空间的调整等多个方面。

✓ 灾备方案要支持策略化配置

便于不同的应用数据具有不同的复制优先级别,以确保关键数据不丢失。

✓ 灾备系统的管理简易性

为了确保灾备系统的正常运行，在日常的管理中必须要进行一定的演练，以保障需要时候的迅捷相应和确认灾备系统可用性。那末，这种日常的演练活动必须要简单,也就是灾备系统自身必须要具有简易的人性化的管理，同时，在对灾备数据作验证时不应当对生产系统产生任何影响。

还有，系统自身故障后应该具有很便利的方式直接来恢复，而不需要重新配置。

✓ 灾备数据具有不影响复制的读写支持，同时支持写入操作后的

Reset(数据重置)

为了充分利用灾备数据,方案必须要支持对灾备数据的读写,同时,该读写的过程不应该影响数据的继续复制。

这样，我们可以利用灾备数据进行诸如软件调试、员工培训、系统测试、灾备系统测试、演练等多种操作。但是,一旦在这种练习结束后，必须要要保证灾备数据恢复原样,保持和实际数据一致。

✓ 相关故障的自恢复故障报警功能

系统涉及到大量的专业设备或技术,因此,灾备系统必须要具有很强的相关故障自恢复功能。如WAN故障、主机故障、应用系统故障等相关因素在恢复正常后,灾备系统也应该自动恢复运行,保持数据的实时复制。

另外,灾备系统自身应该具有完善的日志和报警机制,减轻管理员的负担。

✓ 灾备系统具有较强的数据传输性能（如高度的压缩等能力)

由于系统基于IP链路设计,因此,必须要具有很高的数据传输能力，才可以保障在有限的带宽资源环境下提高数据的复制性能。这种性能的提高很大程度上是靠较高的压缩率来时实现的,我们建议灾备系统要具有超过10倍的压缩率。

7

2.数据容灾系统的详细设计

2.1 系统设计原则

在基于当前的先进技术及产品的情况下，结合整体造价，提供最高性价比的整体解决方案是我们这次规划的主要原则。同时在遵循用户提出的设计原则的前提下,我们还充分考虑了如下的设计理念:

✓ 最高的性价比。根据用户应用的实际需求，提供适宜的解决方案，在

有限的资金许可范围内,提供符合上述需求的方案,并降低后续的维护成本，从而提高系统的整体性价比。 ✓ 实时的数据复制，数据丢失率最小化。

✓ 策略化的数据复制,保障关键应用和一般应用数据的优先级别策略

化，确保关键数据不丢失。 ✓ 严格的数据一致性。

✓ 灾备数据的可读写支持，在进行读写的同时不影响正常的数据复制,

灾备数据在被操作后致支持重置,确保与原数据一致。 ✓ 基于ＷEB、GUI(图形管理)及CLＩ(命令行)多种管理方式。 ✓ 对应用系统影响最小化；自身故障对应用系统无影响。 ✓ 实施便利,无须对应用作任何调整。

✓ 广泛的适用性，数据复制和应用类型、数据类型没有任何关系,支持

异构的平台和存储设备。

✓ 高性能的数据传输,具有高度的数据压缩率（高于１０倍)，提高数据

复制性能。

２.2 系统的产品选择

我们选用业界最领先的美国EＭC 公司的REＣOＶERＰOINT产品作为本系统数据的实时复制（容灾）产品。

ＥMC公司总部在美国加利福尼亚州,在美国纽约、圣何塞(硅谷)及以色列具有研发基地,专门致力于数据安全解决方案的技术研发。在数据容灾日益成为大家关注的话题的同时，ＥMC推出了新一代的数据复制解决方案。

大体来说，美国EMC产品具有如下的基本特点：

➢ 提供实时的数据复制保障，确保在各种故障发生的情况下数据的完整

性。便于实现应用的远程容灾。 ➢ 支持异构存储和异构服务器平台。

这种功能的实现便于用户提供对当前及未来存储设备投资的保障，最大

8

程度地适应存储设备的多样性,避免在今后磁盘阵列的扩展成为被的一个方面。相反,目前大多的数据容灾解决方案均是以磁盘阵列为基础进行复制，要求本地和远程具有相同的磁盘阵列类型。

➢ 基于标准IP网络进行数据复制，同时采用智能化带宽缩减技术来实

现对带宽需求的空前降低。

目前的数据复制方案均要求在本地和远程之间通过专线连接,这样无疑会带来巨大的成本要求。而EMC的解决方案可以基于IP网络,同时具有带宽约减技术（较高的数据压缩率)，策略化地实现数据和应用对当前带宽的适应性。

➢ 策略化的数据复制解决方案,支持全面的数据保护服务级别。 不同的应用数据具有不同的安全级别，因此，在数据复制的同时也可以按照不同的应用给以不同的策略设置,确保关键数据的安全。如用户可以定义关于延迟、带宽等方面的策略,使得用户可以在性能、安全和成本之间均衡考虑。

➢ 同步、异步以及时间点多种模式的数据复制方式动态全面支持。 REＣOVERPOINT提供了无数据丢失的保护措施。一台主机应用每次进行到本地磁盘子系统的写处理时，会并行处理写操作到本地的EMＣ设备。ＥMC应用这种同步连接,并利用独特的缓冲(Buffer）来移交最新的数据保护级别，达到无数据丢失的保护。EMC的缓冲被内置在设备内，可以被置于远远超过光纤所能达到的距离之外。

➢ 利用快照历史可以允许恢复到任一时间点的数据状态。

除了可以保持始终一致的数据复制之外，EMC还提供了独特的回滚能力:“小径快照”提供频繁的基于几秒间隔的快照能力,这样可以实现到任何时间点（point-in-tiｍｅ）的数据恢复。在最新数据被破坏的情况下，可以从快照历史库中选择最近的一次完好可用的快照数据快速恢复到刚刚故障之前的状态。这一极有价值的能力非常引人注目地减少了数据丢失以及对数据崩溃的保护。

在一定的程度上ＥＭC提供的该功能可以代替数据备份技术,甚至远远超过了后者。

➢ 企业级高可用及可扩展性支持

在每个节点通过放置两台RECOVERＰOＩNＴ产品，可以达到自动化的冗余设计，实现数据复制应用的高可用。

➢ 唯一的真正“ｏut-ｏf-banｄ”技术的采用使得实施简单易行，同时对

应用的影响最小化。

9

EMC基于智能化ｏut-of-band的一种设备，可以连接到SＡＮ和IP结构中。也就是说，这种数据复制的过程是在数据路径之外的,以一种非入侵的方式进行。因此，EMC的实施出人意料的简单易行,另外，与in-band产品相比，ＥMC的out-of-band解决方案提供了无的扩展能力,同时对应用无任何潜在的影响。

➢ 远程数据的可用性支持

EMＣ提供的复制解决方案支持远程数据的可操作性，包括读写。这样某些特定的操作如生产数据的模拟化联系,软件的调整测试、系统开发测试、新软件的升级测试等等都可以在这些基础上进行首先测试，确保没有问题之后再于生产系统之上进行实施。

➢ 远程管理的支持

EMC的ＲECOＶＥRPOIＮT设备支持远程的管理与维护，可以配置Ｅmaiｌ地址,并选择某一类型的信息发送到该地址。同时,经过用户开放许可，在北京的技术服务中心和美国EMC公司的服务人员都可以随时提供远程支持。以最快的速度解决问题。

➢ 便捷的配置恢复

在RECOＶERＰＯIＮT自身发生故障，甚至需要更换时，可以便捷地从原来的配置信息中恢复其配置。该信息被保存在磁盘阵列中，并且该空间只有EMC软件可以支配，从而保障其安全可靠性。

➢ 灵活的扩展支持

EMC的解决方案支持双向的数据复制,支持异构的平台和存储设备,便于扩展。

➢ 任何应用类型的适应性(方案的通用性）

由于EMＣ的独特数据复制方式,决定了该方案可以适应任何的应用类型。这样便为用户提供了灵活便利的应用扩展余地。可以方便地把今后的应用纳入到本书据复制体系中来。

综上,我们认为采用EMＣ的数据容灾解决方案是最合适的选择。

3.3 灾备中心的组建

根据当前的用户应用环境和今后发展的考虑， 我们建议在远程灾备点组建SAN的存储架构用于省数据中心和今后其它生产点数据的集中灾备中心。

基本的架构如下图示意。

10

针对这种架构，我们建议在产品的选择上作如下的基本要求：

1）在经费许可的情况下配置双交换机，配置必要的服务器（但是对于ＲECＯVERPOＩNT的解决方案来说,并不需要在灾备中心配置服务器,我们建议配置服务器的目的仅在于对数据的验证和某些必要的操作)。

初期可以配置单台光纤交换机。

２）磁盘阵列的选择建议采用FC－SＡTA的磁盘。作为数据的灾备系统，日常并不涉及到应用,因此，建议采用价格相对低廉的ＦC-SATA磁盘阵列。

3)关键产品配置冗余部件,提高安全性。磁带库可作为备选设备供远期扩容之用。

２.4 数据容灾系统的基本结构

基于美国EMC公司的产品,我们提供了如下图的数据安全保障体系架构。从下图可以看出,系统的配置简单，结构清晰。在本方案中我们不需要在数据中心的各服务器上安装软件，唯一需要的是在需要做数据复制的系统上安装RECOVERPOIＮT的驱动程序，而不需要在服务器上作任何其他方面的调试。

11

该结构的主要配置如下：

在数据中心和灾备中心分别配置两台REＣOＶＥRPＯIＮT,分别连接到光纤存储交换机和以太网络,每个点的RＥCOVERPOＩNＴ之间可以自动冗余，保障数据容灾系统的不间断运行。

在各服务器上只需要安装REＣOVEＲPOINT的驱动程序,不需要安装其他的任何软件。

具体请参考如下示意图。

12

2.5 数据的远程复制流程

EMC提供了完整的于应用系统之外的数据容灾体系。这样对应用系统的影响被降低到最低。

具体的数据复制过程如下所述：

在需要作数据复制的应用服务器上安装RＥＣOVＥRPOIＮT的驱动软件。在应用数据进行写操作时，这些驱动程序会截取这些写入操作，并把该写入操作在继续其正常写入的同时并行地复制到本地的REＣＯVEＲPOINT设备上。

数据中心的RＥCOVERPＯINT设备在接收到上述数据之后通过诸如压缩等方面的处理,根据策略设置把相关数据传递到远程(灾备中心)的RECOVERＰOINT设备上。远程(灾备中心)的REＣOVERＰOＩNT设备把上述数据按照严格的写入顺序写入到远程（灾备中心)的磁盘存储系统，实现数据的一致性远程保存。

另外的一种方式，EＭC安装在本地服务器上面的驱动在接收到远程磁盘阵列的写入反馈(ACK）应答之后才继续进行下一个写入操作,这样的方式是100%同步的方式，可以保障数据10０%的完整和可用性。

还有，EMC的复制支持某一个时间点的复制方式,可以每隔几秒钟自动产生一次快照,并在远程保存这些快照,这样，快照历史库可以便利地恢复历史库中某一个时间的数据。便于在最新数据被破坏的情况下,可用数据的恢复。

上述几种方式的利用可以由RＥＣＯVERＰOINＴ自动优化选择，无需人工调整或设置。

因此，从该方面来讲，EMC的解决方案不仅仅可以恢复最新的应用数据，同时也可以恢复某一个时间点的数据。

基于上述数据复制原理，ＥＭC适应任何类型的应用数据，同时无需单独购买诸如针对Ｏracｌe、Iｎfｏrmix等等不同应用的选件。这一方面也为用户今后的扩展提供了方便。

这种数据复制可以基于一定的策略设置,针对不同的应用采用不同的诸如延迟、带宽占用等方面的策略设置,确保关键数据的可靠性复制。

由于数据在正常写入的同时被传递到本地ＲECOＶERPOIＮT设备上,因此，这种数据丢失的可能性被降低到最低的程度,在某种程度上EＭＣ提供了无数居丢失的安全保障。

在本地配置两台ＲECOVＥＲPＯＩNT设备,可以保障其中一台故障的情况

13

下,保证数据实时复制的继续性,起到冗余的作用。这种切换是自动的，无需人工调整。

2.6 数据的远程恢复流程

在本地数据出现故障的情况下，可以通过RECOVＥRPOINＴ的图形界面方便地把数据恢复过来。完整数据的恢复流程仅仅需要调整原来的数据复制方向，由本地到远程调整为由远程到本地,那末，远程的数据将会作为源数据被复制到本地,从而实现数据的恢复。

这种恢复是最新数据并且是最完整的恢复。

在某些情况下，被复制到远程的数据可能因为在复制的同时本地数据已经被破坏等原因导致最新数据不可用的情况。

此时,我们完全可以通过可用的最新数据快照恢复可用的数据。 由于EＭC提供了数据快照历史库的原因，我们可以根据需要把数据恢复到原来的某一个时刻，在一定程度上取代利用磁带所作的数据备份的功能。当然这种取代是在一定程度上的，并不能完全代替历史数据的备份。

在某些情况下需要对部分文件进行恢复时,可以把灾备中心的数据复制卷加载上来，随意恢复任何一个文件。

4.6 ＲEＣOVEＲPOINT的管理与维护

RＥCOVERPＯＩNＴ支持基于WEB的全局管理，用户可以便利地实现远程监控,并可以通过email来定制一定类型的活全部的系统信息，包括故障、警告等,从而在最短的时间内获得系统得异常信息。

下面是ＲEＣOＶEＲＰOＩNＴ的管理界面示意图:

14

从上图可以看到，系统中的SAN组件，WＡN及主机均可以动态体现出来,无论是其中的任何一个发生故障,那末,都会在该图形上直接显示，一旦故障解决，系统可以自动恢复,无须人工处理。这位系统整体的管理带来了直观性和便利性。

系统的远程维护:

RECOＶEＲPOIＮＴ支持其远程管理，在用户许可并对管理员开放用户名和密码后，可以通过互联网络直接登录到RECOＶERPＯＩNT,从而进行一定的分析与处理。

4．7 基本的策略设置

系统可以根据应用的不同、安全级别要求的不同、线路的利用要求等多方面进行策略设置，这些策略包括:

优先级别的设置,不同的复制组可以设置相对的优先级别，从而保障关键应用数据的不丢失,体现出不同应用数据不同的安全要求。

带宽利用率的设置，如果用户的带宽比较紧张,那末可以数据复制所

15

占用的带宽，从而，全面保障应用带宽，保障应用性能。

高压缩率的设置，系统提供可6-10倍的压缩率,对于数据库应用甚至可以高达15倍的压缩，从而为数据的传输性能带来保障。

高级策略设置：

数据复制系统(RECOＶＥＲPOIＮT)故障后是否保持应用系统的继续运行，否则,一旦RＥCOＶERPOＩNT故障,可以在同一时间终止应用系统的写入，从而保障应用系统数据和灾备数据保持完整地一致。缺省情况下,ＲECOVERPＯINT的故障对应用系统没有任何影响。

在WAN故障情况下，是否允许应用系统得继续运行。 等等。

16

4.８ 整体的成本降低

从发展的角度来看，我们推荐的RＥCOVEＲPOINT方案可以在如下的几个方面为用户带来附加的费用降低，从而带来整体的投资降低:

1）

对不同磁盘阵列的支持:本地和远程的磁盘阵列可以不同,为今后的扩展带来便利。灾备点的磁盘阵列可以根据情况来选用中端或低端的产品。

2）

对不同应用类型的支持，避免了今后不同的应用需要需要采用另外的方案来实现容灾的目的。

3） 4）

低带宽的要求,带来后续带宽成本的降低。

维护成本大大降低，由于涉及内容较少,和磁盘阵列、SAN、应用等多个方面都没有较大的关系，因此，维护的工作量大大降低，同时远程的维护支持带来了7*２4维护的可能，代表着整体的维护成本的降低。

5）

后续扩展的成本，KＢX支持多对一的复制，也支持双向的复制,因此，对于今后的节点加入和扩展带来了保障，无须另外的方案解决。

2.7 本容灾系统的结构特点

从上面的配置介绍及示意图,我们可以清楚看到本子系统的主要特点: ➢ 充分降低数据安全体系对系统的影响； ➢ 真正实时的数据远程复制;

➢ 数据的完整恢复（零数据丢失）保障； ➢ 和应用无关;支持任何应用类型； ➢ 实施维护便利;

➢ 扩展便利；距离无,服务器增加或应用增加不需要重新购买相关软

件；

➢ 支持异构服务器和存储环境(不同厂家的磁盘阵列); ➢ １00%的数据一致性恢复，确保数据的可用性。

➢ 自身具备高可用支持,保障了容灾自身体系的不间段运行。

➢ 对现有的存储系统及应用系统无须调整，确保当前应用系统的稳定

性。

17

➢ 持续的数据保护，可以把数据恢复到任意的时间点。

2．8 数据容灾系统扩展

可以从三个方面来讨论本问题：

1) 应用类型的扩展，不可避免地会存在多种类型数据（应用）的远程

复制（容灾)要求,这样，就要求当前的容灾设计必须要适用这种多种类型数据共存的需求。我们提供的解决方案和应用类型没有任何关系,因此,无论是何种应用类型产生的数据或任何的数据类型都能够被本容灾系统复制到远程。

2) 应用服务器的扩展,我们提供的方案支持异构的平台和磁盘阵列,

因此，面向未来的发展，无论是服务器的增加还是其他厂家(或型号）的磁盘阵列的加入,都可以被轻松地纳入到本容灾体系中。还有我们提供的方案在造价上和应用服务器的数量和类型没有关系，便于随时扩展服务器。

3) 基于应用级容灾需求的扩展。由于我们提供的方案保障了远程数据

的可用性，因此，可以便利地利用其他高可用软件来实现应用的远程切换。

4) 今后其他点的加入:

如果有其他地点的数据需要作容灾规划,那末,只需要和本配置一样配置相应的ＲECＯＶＥＲＰOＩNＴ硬件产品即可。其他完全可以利用本灾备中心的所有资源。因此,这种扩展将极为便利,无须再添加其他的相关产品/设备。对当前整个的灾备系统业没有任何影响。

2.９系统投资保障

由于ＥMＣ的RECＯVERＰOINT产品和应用类型无关,支持异构的平台和存储设备,因此,可以充分利用现有的系统环境,充分保障用户现有的投资。

同时上面对扩展性的灵活支持也是对用户当前投资的一种充分保障。

3．数据容灾系统与其他方案的简要比较

当前，还有一些厂商提供了基于磁盘阵列的数据复制解决方案。主要包括EＭC、IBM等厂家。其主要结构是在本地数据中心和灾备中心均配置同一厂家的磁盘阵列产品，中间通过光纤通道连接,以逻辑卷为基本单位，将本地磁盘阵列上的数据同步镜像到远程的磁盘阵列上。

18

一般这样的方案可以工作在同步和异步两种模式下，同步要求带宽要足够宽，异步则存在可能的数据丢失或对本地应用产生影响。

一般这些方案都不支持自动得快照功能,另外,快照也不是基于增量的,占用较大空间的同时，对应用等都将产生一定得影响。从而在最新数据不能够利用的情况下,数据的可用性恢复和数据的丢失量无法保障。

就此，我们作如下的简要比较列表供大家参考：

序 功能 ＥMC ＲECOVEＲＰOINT １ 2 实时性 通用性 实时 和磁盘阵列无关 基于磁盘阵列的方案 准实时 只能适用于同一个厂家的磁盘阵列产品 3 远程数据处理（正常复制过程中） 远程数据的写操作及数据重置 4 数据的可用性 最新生产数可用时 始终可用 支持，并支持数据重置（Reset）,保持灾备数据始终保持与本地数据的一致性。 远程数据可用性 远程数据处理对复制的影响 不影响 不支持数据操作(处理),如果需要进行处理，那末，必须中断复制过程。 不支持，如果远程数据被更改,那末，没有办法恢复本地和远程数据的一致性。 可用 支持读写，对生产应用无任何影响, 不支持读，不支持写入操作。 备注 19

５ 最新生产数据不可用时 可以通过回滚，来恢复如1５秒或30秒或几分钟之前的数据,在保证恢复可用数据的同时，也保障数据的丢失量最小 必须结合利用其他工具进行快照处理，但是,快照的频率较小,数据可能的丢失率较大。 部支持自动的快照产生。 后者(基于盘阵的解决方案)的快照对应用具有很大的影响，因为产生快照的时候,需要暂停应用。 6 快照 增量、自动 非增量、需要脚本实现自动化 7 占用空间 较小 较大 快照需要的附加空间 8 带宽 一般,无需专线 很高，必须专线， 一般为光纤专线。 9 技术复杂度 极其简单，支持WEB、较复杂,两套软GUI、CLＩ方式的集中管理。 件分别管理 10 后期演练 难度 快照数据的利用 简单 直接利用 复杂 间接利用 11 成本 较低 较高 整体的购买成本及维护成本。 12 1３ 14 自身高可用 高度压缩 对应用系统的影响 支持 6-10倍 无影响 不支持 无 自身故障,对应用系统有影响 15 策略化 支持 不支持

4.数据容灾系统的实施计划

4．1 系统实施需求规划

初步建议用户在每个点采用单台RECOＶERPＯINT设备，今后可以扩展到

20

两台,达到冗余的目的。在此情况下我们作如下的基本规划:

在灾备中心的磁盘阵列上分别划分出多个不同的LＵN,分别供复制时接收不同的应用类型数据使用。

在本地和和灾备中心的磁盘阵列上再分别划分出２个ＬUＮ,分别作为EMC Volumｅ和Sｎapshot Hisｔory Ｖｏlume。前者用来保存RＥCOＶＥRPOIＮＴ的所有配置信息,以及ＲＥＣOVＥＲＰOINT相关的集群状态数据,空间要求为1０GＢ左右即可。后者，用来保存快照记录,用于在最新数据不可用的情况下,通过回滚来恢复可用数据,并保持最小化的数据丢失量。该卷的空间大小根据用户说明，需要考虑长达2４小时的数据复制中断情况下的数据变化量来综合考虑。

在本地和灾备中心的光纤交换机上分别配置两个光纤口，连接REＣOVERPOＩNＴ。

在本地和灾备中心的以太网络交换机上分别配置两个口,分别连接ＲＥCOVEＲPOINT,其中每台RECＯVEＲＰOＩＮT具有两个以太网口,一个连接内部局域网,另一个连接WAＮ。

进行简单的图形化配置ＲECＯVERPＯINT,完成数据的初始化，进入正常数据复制。

进行相关测试,验收。 进入后续维护期。

４.2 相关性要求/实施步骤

在系统的实施过程中，需要诸如磁盘阵列厂家、光纤交换机厂家及用户或应用软件开发商提供简单的协助，具体的任务计划如下。（注:黄色部分均为实施前的准备工作，真正的RECOVＥRPＯＩNT的实施步骤为下表中的7-13。整体的实施周期为一周，包括实施及验收、测试。） 序号 １ 确认24小时的数据最大变化量 2 磁盘阵列(数据中心和灾备中心) 创建LUN,用于接收被复制的数据。 软件开发商和用户 磁盘阵列厂商／维护人员 半天 和生产用空间相同。 项目／任务内容 负责方 完成时间 备注 21

创建EMＣ Volume 创建Ｓnａｐshoｔ ２０GＢ~10GB 〉=2４小时的最大数据变化量。 Ｈiｓtoｒｙ Volｕme 3 光纤交换机的 Zｏnｉng设置 光纤交换机厂商&灾备系统实施方 需要把EMC Vｏlume和SnａVolumepshot 及应用LUN进行安全设置。 4 连接RECＯVERPＯINT，数据中心和灾备中心同时进行 5 配置RECOVEＲＰ软件开发商&灾备系统实施方 半天 需要确认 OINT，安装服务器端的RECOVＥRPOINＴ驱动程序 RECOVERPOINT利用的ＩP和Gateway地址,数据中心和灾备中心的KBＸ各需要5个IP地址。 6 申请重新引导系统 系统管理员/主机厂商／软件开发商 需要提前申请 7 现有数据系统初始化 软件开发商&灾备系统实施方 一天 初始化最好在应用停止的情况下进行，当然也支持在线的数据初始化。 8 系统初始化验证 软件开发商&灾备系统实施方 22

９ 数据的持续性实时复制,代表灾备系统正常运行 软件开发商&灾备系统实施方 一天/二天 １０ 11 数据的验证测试 灾备数据的可用性测试 １2 灾备系统的回切(从灾备中心到数据中心）的测试 1３ 进入系统正常运行、维护期 根据需要决定是否进行本项测试 转交给用户进行日常管理。 需要定期的演练 4.３ 系统配置清单 针对上书分析,我们作如下的配置清单列表: 序号 1 产品名称 REＣOVERPＯIＮＴ硬件设备 分布 生产中心和灾备中心各一。 作用 发送/接收数据 备注 远期可以扩展到各两台,达到冗余目的。 ２ EMＣ 数据复制软件 一套 RECOVERPＯIＮT的软件及各服务器的RＥCOＶERPOＩNＴ驱动软件。 ３ Ｅmulｅx光纤卡 两块 用于REＣＲECOＶERＰＯIＮT缺省带有一块单口的光纤卡。 详细清单见附件。 OVERPOINT对双光纤交换机的连接支持

23

5．数据容灾系统的测试/验收计划

在本灾备系统实施完毕,随即就可以进行相应的测试计划。测试的主要步骤列表如下:

５.1 基本测试及对Oracle和其他类型数据的测试

下面是以Oｒａclｅ应用为例,对系统得测试/验收步骤。

Oｒaclｅ应用数据是用户最为关键的，在此,首先针对该应用进行测试。

测试名称 说 明 测试方式 资源/备注 数据的实时复制 察看RＥCＯVERPOINT对数据复制的实时性。 在应用端进行数据的插入或删除等类似操作， 远程节点数据可用性 测试灾备中心数据的可用性。 测试系统数据的实时复制的可靠性。 加载灾备中心的LUN,利用Orａcle作数据的可用性检查 远程数据的完整性 测试灾备中心数据的完整性。 比较双方在某一个时刻点的数据一致性。 数据一致性测试 非Ｏｒaｃlｅ数据的复制测试 灾备中心数据支持读写 测试数据中心和灾备中心数据的一致性。 同上类似步骤 插入/删除记录等操作。 同上类似 验证方案的通用性 在正常的运行状态下，对灾备中心的数据进行读写操作测试 灾备中心数据被写入后的Ｒeｓet在诸如员工培训、软件调试等情况下，对备份数据进行调整治后可以再恢复到原来在灾备中心对数据进行出入操作，之后进行Rｅset操作，察 24

操作 的一致性 看该中间过程忠对数据的变更是否存在,产看数据的一致性。 5.2 切换及回切的测试 在本地节点故障的情况下,用户往往需要在远程节点把应用迅速引导起来，另外，在本地节点正常之后,需要把应用再次切换回来，这样的过程称之为为切换／回切。 测试名称 两个节点都处于Actiｖｅ状态下的切换 描 述 正常运行情况下的手工切换,确认被复制数据的可用性,灾备中心应用的正常运行。 测试方式 装载灾备中心的接收LUN,启动Oracle。察看运行是否正常，数据是否可用。 资源／备注 没有必要影响数据中心应用的正常运行。 用户初始化故障的切换 最新数据被破坏情况下的数据恢复 以某种方式来模拟数据中心数据(应用）故障,察看此时数据的可用性。 需要用户及软件提供商进行故障模拟。 进行一定的故障模拟,如果数据中心的数据发生不可用的现象,利用灾备中心的数据恢复至可用状态。 25

本地数据崩溃后进行回切 进行数据中心的数据从灾备中心进行恢复。 5.３故障测试 各种故障的发生是不可避免的，我们在上面安排的切换及回切等功能的演示,以及下面的如ＷAN故障的测试可以涵盖大多严重的故障现象,从而确保数据保护方案的可行性。

测试名称 WＡN故障 描 述 测试方式和资源 拔出WAN的连接线，导致连接故障，一段时间后恢复该联路，测试ＥMC对该故障的响应。(在联路故障的情况下，保持本地数据正常写入) 拔出WAＮ的连接线，导致连接故障,一段时间后恢复该联路,测试ＥＭC对该故障的响应。(在联路故障的情况下,保持本地数据正常写入) ＫBX故障 (应用正常运行，但是KBX故障的情况下,测试其系统的自动恢复及对复制不影响） 可以拔出KBX的网线、光纤线等,模拟故障。 6.数据容灾系统的日常管理/演练计划 本系统由于维护的便利性和在测试（验证）灾备中心的数据可用性时,不需要对数据中心作任何的调整，也就是整个测试过程不会对数据中心的应用产生任何影响。同时,在对灾备中心的数据进行读写处理时,对RECOVERPＯＩNT的复制也不会产生影响。

所以,整个的测试过程将会极为简单,从而,这种日常的维护将可以作为系统管理人员的日常工作职责,如每周（或每月)做一次测试,系统管理员可以独自进行,不需要厂家的现场支持。

鉴于该生产系统的持续性运行要求,我们不建议作较为频繁的回切测试，在日常只要验证灾备中心的数据可用就可以了,在每个季度或者半年的时间

26

内可以做一次真正的切换及回切演练。

对于日常的员工培训,完全可以利用灾备中心的数据来进行,当然诸如软件调试、系统测试等工作也可以利用上述数据。在对这些数据进行操作完毕,如果担心数据被更改,可以通过简单的Ｒeset操作来完成数据的重置，保证数据的一致性和安全性。

REＣOVERPOＩＮＴ的管理支持ＷEB方式、图形方式和命令行方式,具有丰富的日志和报警机制。

7．应用级容灾的规划

由于EMC的解决方案可以保障数据的可用性,因此，针对未来的应用级容灾考虑，只需要利用当前的高可用软件来完成切换即可。

配置比较简单,不需要作单独的处理,这种切换的时间很短,和正常的手工启动Oracle没有多少的区别，关键在于高可用系统的检测和切换时间。

极端情况下,诸如最新数据不可用的时候,如果需要进行切换，那末,需要的时间会稍微增加。因为,需要确认某个时刻的数据是可用的,也就是需要利用RECOVERPOINT的快照功能。

8.后续其他节点的扩展规划

在本灾备中心建立完毕，适当的时机可以把其他地点的数据也纳入到本灾备体系中来。从而提高本系统的利用率并为更多的数据提供保障。

由于省数据中心的数据量较大,应用将多，因此,建议这次配置的RECＯVERＰOＩＮT专门作为省数据中心数据的灾备只用。今后其他各点可以通过配置新的REＣOＶERPOＩＮT设备来完成。

由于是多个节点到一个节点的规划，因此，我们建议配置一台或两台ＲECOＶERＰOINT设备，在每个生产节点配置一台或两台RＥCOＶＥRPOINT设备，来实现这种集中的灾备体系。

同样的优势,在今后多点规划时,不需要对存储体系和应用体系作任何的变动，实施便利。对当前的投资都可以很好的给以保障。

10. EＭC ＲEＣOVEＲＰOIＮT的维护

RECOＶＥRPＯINT的解决方案是真正的ouｔ-of-ｂand方式,因此，对应用系统没有任何影响，其自身故障也不会对应用系统或相关系统产生任何影响。另外,对于RＥCOＶERＰＯINT的维护具有如下的几个独特之处:

27

RＥＣOVEＲPOINT具有自身的配置快速恢复的能力。RECOVEＲＰOIＮT不仅仅提供了把相关的配置信息eｘporｔ出来的能力，另外还提供了Import的能力,因此,在整体配置完毕且无误之后,可以通过该工具把配置信息保存在ＫBX之外，便于快速恢复。

我们配置的每个地点２台RECOＶERPOＩNT的规划,具有RECOVＥRＰOＩNT自动的冗余配置,一旦其中的一台REＣOVＥＲＰOINT故障，本节点的另外的一台RECOVERＰOＩＮT可以快速接管该故障的ＲECOＶＥRPOINT，从而保持数据容灾系统的持续性。这也为ＲECOVEＲPOIＮT的故障处理带来了充足的时间保障。

RECＯVERPOINT的自身硬件具有备件支持，我们可以在当天把这些备件进行更换，保证系统计是的倒恢复。

RＥCOVERPOINT支持远程维护,如果用户对我们开放临时的用户名和密码,并且可以访问ＲECOVEＲＰOINＴ的话,我们可以（或者美国 ＥMC支持服务中心)都可以提供7*24的远程故障诊断和处理工作。

RＥＣOＶERPOＩNT提供了丰富的报警机制,可以把诸如信息、警告或故障(错误)等多类信息发送到邮件系统，及时通知管理人员。

由此，整个的数据容灾系统将具有很便利的维护手段。对于本项目，我们系统集成商给以了充分的重视,单独安排了技术人员给以本项目各方面的支持，如果用户接收了本解决方案，我们还将单独安排技术人员对本项目提供7*24的技术服务，确保系统的稳定运行。

我们,在项目实施之后还将对用户进行全面的技术培训，从配置到维护,使其不仅掌握了解系统的工作流程，同时也了解简单故障的处理，并在故障发生后及时和我们联系。届时我们将提供7*２4技术服务人员的联系方式。

作为美国EMC公司的代理商，我们不仅得到了原厂商的技术培训。同时，我们还在公司内部组建了测试、演示环境,在为用户提供演示、测试的基础之上、也用于对技术乳粉元的全面培训、技术掌握,从而为系统的后续维护带来保障。

假设在我们不能及时处理故障的情况下,美国ＥMC公司的技术服务中心将对我们提供７*24的技术支持，迅捷有效地解决相关问题

28