转 -- 容灾方案的选型分析

选择一个合适的容灾技术方案，需要进行多方面的评估，以确定灾备方案的基本环境、基础构件、容灾效果及期望的恢复时间。例如：1、应用系统的类型；2、期望的RTO（恢复时间）是什么；3、灾备的距离；4、需要的带宽？5、RPO目标，是否允许数据丢失？6、兼容性；7、人力资源；8、成本……等等。
在没有明确选择目标的阶段，我们可以首先从技术问题入手，最佳的选择方法之一是采用排除法，根据评估参数的要求逐步剔除不合适的技术，来定义初步、候选的灾难方案。

由于本项目没有明确的要求，因此我们主要从产品的技术特性、兼容性等角度进行考察，最终的选择结果很可能是多个推荐方案，这都是正常的，因为它们都是可用的方案。

2.3.3. 当前可用的容灾技术

目前主流的容灾技术按照系统层次划分，主要有以下5种类型:

l 基于磁盘（阵列）存储系统

l 基于存储网络（SAN）的虚拟化设备

l 基于操作系统逻辑卷

l 基于数据库

l 基于应用程序

为了更清晰的分析各种技术类型的特点，我们用以下表格来进行说明：

类型	应用条件	优势特点	典型产品
基于磁盘阵列	具有指定的硬件	性能好与应用无关不占用系统资源管理简单	IBM PPRC、 EMC SRDF、 HDS True-COPY等
基于 SAN	具有SAN环境	性能好与应用无关不占用系统资源管理简单	IBM SVC、 ipstor、 StoreAge等
基于操作系统	操作系统兼容性	与应用无关距离不受限制	IBM GeoRM/HAGEO、 Veritas VVR等
基于数据库	具有指定数据库	支持异构距离不受限制带宽要求低应用灵活	Oracle、 Sybase、 DB2、 SQLserver
基于应用	开发团队支持	支持异构距离不受限制带宽要求低	IBM Websphere/CICS、 BEA Tuxdo/Weblogic等

2.3.4. 容灾技术选择

选择一种合适的容灾技术，首先要具备最基本的应用条件。对上面的表格进行分析我们可以发现，并不是所有的技术都支持本项目的系统应用环境。

系统现有的IBM 7133 D40阵列在没有复制功能，无法实现基于阵列的容灾。从第一节的需求分析我们得出的结论，目前的系统并不适合进行大规模的硬件更换，单纯地更换磁盘子系统去实现容灾方案，不但影响现有系统的稳定性、而且投资过高，与服务器在性能上也不匹配，影响到未来系统的整体升级策略。

基于SAN的方案也无法实现，现有的HA环境基于SSA磁盘总线技术，与基于FC协议的SAN环境并不兼容，SVC、ipstor、StoreAge等设备也都不支持7133阵列。

基于应用的方案也不适合现有的环境。目前的应用系统运行稳定、结构成熟，很难进行体系结构上的修改。而且应用开发的难度也是尽人皆知，在设计和实施周期上相对很难把握，国内成功案例寥寥无几。

基于操作系统和基于数据库的容灾技术没有以上诸多的制约，例如它们与硬件的关联度都不是很大，比较适合现有设备环境；或者只是涉及到OS、DB的运行平台，而不必涉及开发团队。这些条件都满足我们最初对系统稳定性和实施成本的期望。下一节我们将从这两类技术中选择出最佳的产品方案。

2.3.5. 产品方案选择

进一步分析基于操作系统和基于数据库容灾技术的产品。我们收集了国内主流的相关产品信息，仍然使用简单清晰的表格方式说明：

类型	产品	特点优势	潜在问题
基于操作系统卷	IBM GeoRM	IP传输距离无限制与应用无关同步/异步	必须是AIX系统
	IBM HAGEO	IP传输距离无限制容灾+自动切换与应用无关同步/异步	必须是AIX系统成本较高
	Veritas VVR	IP传输距离无限制与应用无关同步/异步	操作系统同构兼容性问题
基于数据库	Oracle DataGuard	IP传输距离无限制免费同步/异步	仅支持Oracle 操作系统同构
	Quest SharePlex for Oracle	IP传输距离无限制支持异构	仅支持Oracle 仅支持异步模式
	DataMirror iReflect for Oracle	IP传输距离无限制支持异构	仅支持Oracle 仅支持异步模式
	DSG RealSync for Oracle	IP传输距离无限制支持异构	仅支持Oracle 仅支持异步模式
	Sybase Replicator Server	IP传输距离无限制同步/异步支持异构	仅支持Sybase
	INFORMIX HDR	IP传输距离无限制同步/异步	仅支持Informix 操作系统同构
	IBM DB2 HADR	IP传输距离无限制同步/异步	仅支持DB2 操作系统同构

从上表的信息可以看出，所有产品都是基于IP传输技术，在容灾上没有距离的限制；对存储子系统也没有要求。因此选择基于操作系统还是基于数据库的主要因素在于数据的类型和管理人员知识结构。如果是数据库+文件系统混合应用，则基于操作系统的技术是最佳选择；如果系统只有数据库应用，则两种技术都适合。另外还要评估系统管理员的技术结构，如果精通操作系统，则应该选择基于操作系统的技术；反之，DBA应该选择基于数据库的技术。

如果以上问题都不成为障碍，那么基于数据库的技术在资源占用、传输效率、异构配置上要优于基于操作系统的技术，应该优先选择。

操作系统容灾技术产品的筛选：

上表中，基于操作系统的技术有三种产品可以选择：IBM GeoRM、IBM HAGEO以及Veritas VVR。

对于本项目来说，Veritas VVR的使用有一些难度，主要原因是必须替换AIX系统现有的LVM和JFS，用Veritas的VxVM和VxFS代替。从我们的经验看，这一部署改动过大，不符合系统稳定的方案设计的原则，而且VVR与AIX系统的兼容性也存在一些问题，因此首先排除。

IBM GeoRM 和HAGEO都是IBM自有的解决方案，兼容性有较好的保证。HAGEO具有自动容灾切换功能，同时成本也高出许多，但是自动切换在容灾领域是一项颇具争议的技术。相比较而言，GeoRM更加简单实用，满足本项目的要求，且成本较低。综合分析，GeoRM产品方案是最佳选择。

数据库容灾技术产品的筛选：

上表中，基于数据库容灾的产品种类较多，总体上可以分为两大类：基于Oracle和基于非Oracle。

在Oracle数据库领域，既有Oracle自带的DataGuard，也有第三方厂商的产品。根据我们的经验，分析结果如下表所示：

	效率	模式	优势
Oracle DataGuard	一般	同步、异步	Oracle兼容性最佳
Quest SharePlex	高	异步	支持异构，容灾端数据库可打开
DataMirror iReflect	高	异步	支持异构，容灾端数据库可打开 Oracle官方认证
DSG RealSync	高	异步	支持异构，容灾端数据库可打开

第三方产品与Oracle的DataGuard相比较，在满足容灾功能的前提下，效率更高、应用更加灵活、配置和维护也更简单。特别是支持异构（主机、OS、存储、数据库版本都可以异构）和容灾端数据库可打开的特点，能够带来很多实用价值 — 降低硬件成本、容灾数据可检验、数据复用等。综合投资回报率往往比DataGuard更高。

第三方产品SharePlex、iReflect、RealSync均采用数据库日志分析的机制，因此在效率和架构方面没有本质差别。其中，DataMirror iReflect是唯一通过Oracle认证的产品，与另外两种产品对比功能更丰富，价格适中。因此我们推荐iReflect产品作为基于Oracle数据库容灾的最佳方案。

目前在国内，非Oracle数据库的第三方容灾方案选择较少，基本上都是数据库自身附带的容灾功能。

经过以上信息的综合分析结构，我们推荐以下容灾技术方案供用户选择：

l IBM GeoRM 操作系统卷复制容灾方案；

l DataMirror iReflect Oracle 数据库复制容灾方案；

l Sybase Replicator Server 数据库容灾方案

l IBM Informix HDR 数据库容灾方案

l IBM DB2 HADR 数据库容灾方案

注：基于数据库的容灾产品与数据库的版本、配置、使用的数据对象类型息息相关，在选择时要着重考虑以上因素。本方案因为系统信息不明确，无法评估这些因素对方案的影响。因此在下面的章节中，只介绍IBM GeoRM操作系统卷复制容灾方案。

3. 容灾方案设计

3.1. GeoRM简介

IBM 的GeoRM是Geography Remote Mirror 的缩写，是基于 IBM AIX 操作系统平台的远程实时灾难备份解决方案。GeoRM在理论上对备份中心距离没有限制，利用 IP 网络，无需铺设专用光纤，而且对数据库类型和存储设备的类型透明，对应用程序也透明，即在GeoRM下应用程序无需修改。同样地，GeoRM 也可以做到零数据丢失，并提供同步及异步实时镜像模式以适应不同的需求。

基于 GeoRM 的灾难备份方案在使数据得到实时保护的同时，必须另外考虑应用的整体切换方案，当灾难发生时，也需要手工干预来恢复数据和应用。因此，除了选择容灾技术之外，用户还需要定义BCP（业务连续性计划）来保证容灾体系的其他操作流程，因为生产的恢复时间取决于应用的恢复速度。

3.1.1. GeoRM的工作原理

略。

3.1.2. GeoRM的复制模式

对于容灾系统来说，首先要保证复制数据的安全。其次，是在灾难发生时尽快恢复系统正常运行。其中，保证数据的安全就是要确保生产系统和备份系统的数据一致性。

GeoRM 针对逻辑卷和文件系统进行实时镜像，有三种方式可供选择：

■ 同步（SYNC ）模式

数据先写到远端，等完成后再回到本地做写入动作。同步模式能保证两个地点的数据在任何时刻都保持精确的一致，但它显然速度较慢，本地生产中心的应用的执行效率低，因为它总是要等待两端的数据都写好以后才能继续下一个写操作。

■ 镜像写一致（ SYNC with Mirror Write Consistency）模式

同时远端和本地写操作，并在本地维护一个写记录，记录两端所有未完成的动作。这种方式保证最佳数据一致性。

■ 异步（ASYNC）模式

数据先写到本地，但不等完成即在远端做写入动作，这种方式受网络延迟影响最小，性能最优。

如果生产中心与容灾中心之间的网络带宽足够，建议使用镜像写一致模式，保证两端数据的绝对一致性。值得一提的是，GeoRM进行数据镜像时是采用Kernel RPC，其传输效率远比传统RPC快。

如果带宽有限或可能出现延迟，则异步模式对生产系统应用的性能影响最小。GeoRM的异步模式充分考虑了数据一致性的问题，随时跟踪灾备中心硬盘数据写入的信息，一旦发现远程硬盘内写入的数据比本地硬盘内写入的数据差了一定的KB数（默认值为128KB），数据镜像自动转换成同步（Sync）方式，直至两地硬盘写入的数据量的差距缩小，才转换成异步方式。

3.2. 实施容灾方案的准备

3.1.1. 容灾地点规划：

容灾地点是建立一个容灾系统首先应该考虑的问题，地点的选择往往会影响技术类型的选择以及容灾的效果。评估一个地点是否合适，主要应考虑以下因素：

l 距离；

l 通讯线路技术；

l 通讯成本；

l 地理风险；

l 当地机房条件；

l 当地人员技术条件；

l 管理成本；

l 交通情况等。

地点没有所谓的最佳标准，公司可以根据自身条件选择。但是有一些因素我们不应该忽略，譬如该地区是否经常发生自然灾害？治安是否稳定？有没有战争风险。另外一些常识性问题也很重要，例如8级地震的破坏范围可能超过100公里等等。

3.1.2. 容灾网络规划：

容灾是一套跨区域的异地工作系统，其可用性受到网络的影响非常大。采用的复制技术决定了带宽的配置，反之带宽成本也会影响技术方案的选择。本方案主要从两个方面评估带宽的需求：

l 同步时间的估算：

同步时间是指生产系统的数据初始化镜像到灾备系统的时间。计算方法如下：

同步时间 = 数据量×8/(线路带宽×0.8网络效率比)/3600

数据量 = 实际数据量 *（1+30%冗余数据）

下表是计算后的结果，可见如果数据量在10GB以上，E1线路可以满足基本需求，如果数据量达到在100GB，这10Mb带宽是必不可少的。

l 网络带宽的估算：

我们可以在操作系统中通过跟踪应用系统对复制卷的写操作来计算GeoRM镜像所需要的最低网络带宽。其结果与应用的压力密切相关。根据我们的经验，一般情况下，2Mbps是最基本的要求。如果采用同步模式，则必须更多。该参数需要生产系统上详细测试后才能确定。

3.1.3. 应用系统的考虑：

GeoRM 技术方案本身对应用透明，因此无论是数据库应用还是文件系统操作都可以支持。但是我们仍然需要在方案确定前对生产系统做一个综合测试，主要评估以下因素：

l 生产系统当前的空闲资源是否满足GeoRM的需要；

l 生产系统现有应用业务的性能参数；

评估的目的主要是为了计算系统的承受能力。因为在GeoRM实施运行后，生产系统的性能肯定会受到一些影响，我们只是希望少量的性能下降不会对应用产生重大影响。

某第三方公司的测试报告显示，GeoRM对生产系统的CPU占用平均在8%左右。

3.1.4. 容灾软硬件系统规划：

和生产系统的环境调查一样，容灾设备的计划也应该详尽。对于GeoRM方案来说，软件兼容性是重要条件。我们应尽量在灾备端选择与生产端一致的平台，AIX的版本也要与GeoRM兼容。

硬件方面，大部分行业的容灾规范都要求灾备端系统性能至少应该达到生产端的50%，我们推荐尽量采用设备利旧原则，以节约整体成本。

网络方面，为了保证GeoRM的工作效率，生产主机和灾备主机应该预留专用的网卡端口给GerRM使用。GeoRM支持多路并行通信及负载均衡，强烈建议用户在生产主机和灾备主机之间配置多条线路，以避免网络中断导致生产应用不能写操作。

	项目	生产设备	容灾设备
主机配置	CPU
	RAM
	Network
	磁盘已用空间
	磁盘剩余空间
	TPM-C值
	OS版本
	HACMP版本
应用系统	应用类型
	版本
	数据量

整个灾备系统的部署工作包括以下步骤：

l 生产系统数据备份；

l 硬件采购、安装调试；

l 网络通讯调试；

l 系统软件升级；

l GeoRM 安装、配置；

l 镜像初始化；

l 实施同步；

3.3. 方案介绍

3.3.1. 方案描述

本方案是基于GeoRM的操作系统级容灾方案，计划在安全容灾距离范围建立一套灾难系统，包括一台RS6000或pSerise服务器，一台直连磁盘阵列子系统。容灾端安装与生产端相同版本的操作系统和应用程序。容灾端划分与生产端相同的卷结构，利用GeoRM进行实时镜像。镜像尽量采用同步写一致模式，保证应用数据，特别是数据库数据的绝对一致性，以及零数据丢失。

生产系统和容灾中心之间推荐采用2条或者多条捆绑的E1网络线路，WAN以及LAN设备均采用冗余配置，同时配置GeoRM多路通讯功能，以避免因为某一条线路中断而导致生产系统应用不能写操作。

容灾机制的基本模式为，生产环境是两台RS/6000服务器，组成一个本地的双机热备份环境。当本地的一台服务器发生故障时，应用会自动切换到本地另外一台服务器上。在灾备中心，容灾服务器处于运行状态，但应用程序不启动。当生产环境中的两台服务器都不能工作时，人工发出容灾指令，并手工启动容灾服务器上的应用程序，接管生产系统。接管操作的时间一般可以控制在半小时左右。