容灾方案的选型分析

        以前写过的一个建议书，没有十分明确的需求，只是对各类方案进行了一点分析。 

 

 

1.    前言：... 2

2.    需求分析... 2

2.1      系统拓扑图... 2

2.2      系统配置... 2

2.3      容灾方案选型... 3

2.3.1.      应用现状及选型原则... 3

2.3.2.      容灾模式的选择方法... 3

2.3.3.      当前可用的容灾技术... 3

2.3.4.      容灾技术选择... 4

2.3.5.      产品方案选择... 5

3.    容灾方案设计... 7

3.1.     GeoRM简介... 7

3.1.1.      GeoRM的工作原理... 7

3.1.2.      GeoRM的复制模式... 7

3.2.     实施容灾方案的准备... 8

3.1.1.      容灾地点规划：... 8

3.1.2.      容灾网络规划：... 8

3.1.3.      应用系统的考虑：... 9

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

3.3.     方案介绍... 10

3.3.1.      方案描述... 10

3.3.2.      方案拓扑结构... 11

3.3.3.      容灾操作流程... 11

3.3.4.      方案优点... 11

3.4.     国内成功案例... 12

1.     前言：

本方案建议书以用户现有软、硬件系统环境基础为出发点，充分评估多种容灾技术的特点和部署条件，以实用性、最优综合成本、部署便利性、投资保护等条件为原则，择优向用户推荐最佳解决方案，希望能为技术人员和项目负责人提供有益参考。

2.     需求分析

2.1         系统拓扑图

LAN

SSA

SSA

RS6000 HACMP

RS232

7133 D40

RS6000 HACMP

2.2         系统配置

当前系统配置调查表：

	项目	参数	说明
主机配置	CPU
	RAM
	Network
	磁盘已用空间
	磁盘剩余空间
	TPM-C 值
	OS 版本
	HACMP 版本
应用系统	应用类型
	版本
	数据量

2.3         容灾方案选型

2.3.1. 应用现状及选型原则

本项目的系统为典型的 IBM RS6000 双机配置，从目前采集的系统配置信息分析，该系统使用期超过五年时间，在运行期间，软硬件系统没有经过重大升级，可见该项应用的软件系统及业务压力始终保持稳定的状态，并且会一直持续。在此基础上考虑容灾需求，方案的稳定性、兼容性、实施的便捷性将是侧重点。

此外，该系统在物理结构上比较简单且相对独立，硬件系统特别是磁盘阵列在技术上有一定的封闭性。在容灾设计上，也要考虑方案的简单性和最佳成本，以及对过去的投资保护和已有技术人员能力的特点。

简而言之，该系统的生命周期已经过半，未来很可能进行全面的升级，因此容灾建设也应该进行阶段性的规划，当前阶段主要以现有软硬件为基础设计实施，并适当考虑未来升级条件。

2.3.2. 容灾模式的选择方法

选择一个合适的容灾技术方案，需要进行多方面的评估，以确定灾备方案的基本环境、基础构件、容灾效果及期望的恢复时间。例如： 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 服务器，组成一个本地的双机热备份环境。当本地的一台服务器发生故障时，应用会自动切换到本地另外一台服务器上。在灾备中心，容灾服务器处于运行状态，但应用程序不启动。当生产环境中的两台服务器都不能工作时，人工发出容灾指令，并手工启动容灾服务器上的应用程序，接管生产系统。接管操作的时间一般可以控制在半小时左右。

3.3.2.  方案拓扑结构

 

3.3.3.  容灾操作流程

3.3.4.  方案优点

u GeoRM 源自 IBM 公司解决方案，与现有系统的兼容性最佳；

u 对生产系统的改动最小，保持系统稳定；

u 对应用程序透明，支持所有的数据库和文件类型；

u 三种数据镜像复制方法，可以保证数据一致性和零数据丢失；

u 基于 TCP/IP 传输协议，容灾距离没有限制；

 

3.4. 国内成功案例

GeoRM 国内成功案例请参考：

[url]http://www-935.ibm.com/services/cn/igs/html/bcrs/case_succeed.html[/url]

 

 

 

 

 

 

 

 

 

 

 

oracle ORACLE Oracle ora ORA Ora 数据库 shujuku 9i 10g 11g database db dbms rdbms sqlserver sybase informix db2 mysql postgres 数据仓库 shujuchangku sql SQL 表 table biao 表空间 tablespace biaokongjian 用户 user yonghu 模式 schema moshi 事物 transaction transactions shiwu 交易 jiaoyi 实例 instance RAC rac OPS ops

实时 shishi 定时 传输 chuanshu 自动 auto 缓存 buffer 内存 磁盘 目录 文件系统 file system 操作系统 OS 内核 kernel 分发 集中 fenfa jizhong 数据 data shuju track merge comm communication 程序 进程 网络 距离 远程 异地 公里 跨 跨平台 行业 异构 成功案例 案例 项目 规划 设计 方案 白皮书 技术 报告 测试报告 文档 验收 竞争分析 测试 迁移 migration qianyi 在线 部署 集成 通信 工程 开放 封闭 服务 service fuwu 模块 模块化 地址 体系结构 延迟 时间 特点 优势

dataguard 高级复制 逻辑复制 物理复制 逻辑容灾 物理容灾 log redolog redo 日志 日志分析 analysis stream streams 流 流复制 保护 baohu

对象 object 类型 type 存储过程 procedure trigger 触发器 序列 sequence 权限 sqlplus 外部表 OMS 物化视图 试图 view 索引 index 提交 commit 回滚 rollback OCI imp exp 导入 导出 select insert update where alter recovery recover mount v$obj

emc SRDF timefinder netapp snapassure mirror 镜像 veritas VVR vxfs netbackup hp truecopy ibm pprc sun hds 快照 复制 阵列 阵列复制 存储 存储复制 data guard DSG dsg Quest Shareplex SHAREPLEX SharePlex rongzai fuzi 容灾 复制 备份 恢复 软件 RUANJIAN ruanjian realsync snapassure goldengate ireflect datamirror toad beifen SAN NAS DAS gzip

rongzai 成本 cost 带宽 网络 ip 压缩 yasuo wangluo daikuan chengben iot logminer 进程 process  打开 open

ods ODS OSS BSS BOSS erp crm 交易系统 jiaoyixitong 管理系统 guanlixitong 监控系统 jiankongxitong 采集系统 caijixitong 支撑系统 zhichengxitong 业务系统 yewuxitong 业务 yewu 核心系统 核心 hexin 中间业务 增值业务 前台 后台 houtai 前置 账务 zhangwu 处理 process 管理 management Java j2ee web GUI EJB C C++ unix Linux 界面 游戏 工具 tools 查询 报表 即席查询 抽取 转换 装载 ETL 功能