上海移动容灾系统方案设计报告.doc

上海移动容灾系统方案设计报告

知识水坝（豆丁网@pologoogle）为您倾心整理（下载后双击删除）

上海移动容灾系统

方案设计报告

IBM 公司上海分公司

Version 5.0

百度一下"知识水坝"

IBM专有信息声明

本设计报告属商业机密文件，书中的所有信息均为IBM机密信息，仅供上海
移动容灾项目使用。务请妥善保管并且仅在与项目有关人员范围内使用，未经IBM 公司明确做出的书面许可，不得为任何目的、以任何形式或手段（包括电子、机 械、复印、录音或其他形式）对本文档的任何部分进行复制、存储、引入检索系 统或者传播。

尽管IBM已经尽力保证本文档内容的完整性和有效性，但仍可能存在某些方 面不够准确的地方或印刷错误。若需求有所变化，IBM将对有关内容进行相对应 的调整，并在本报告的未来版本中体现。

IBM是国际商业机器公司的注册商标。本文档提及的其他公司、产品和服务 的名称，可能是其他公司的商标或服务的标志。

Copyright © IBM China Company Limited

All rights reserved

关于本文档

文档信息

文档名称 上海移动容灾系统方案设计报告

作者 IBM全球服务部

说明 本文档是上海移动容灾系统方案设计报告，由IBM公司上海

分公司和上海移动容灾系统项目组共同编写。

文件名称 上海移动容灾系统方案设计报告 v5.0.doc

怱订历史 (REVISION HISTORY)

Rev Section Type Date Author Remarks

1.0 All New 2004-09-13 IBM
SHMCC
team
创 建 方 案 第 一 版
本。

2.0 All Revis
ed
2004-09-22 IBM
SHMCC
team
根据客户反馈怱改
而成

3.0-

3.1
All Revis
ed
2004-09-27 IBM
SHMCC
team
根据客户反馈怱改
而成，增加存储管 枞 和 灾 难 恢 复 计 划，网络设计考虑
多种方案

4.0 ALL Revis
ed
2004-10-08 IBM
SHMCC
team
整枞版本

5.0 All Revis
ed
2004-10-25 IBM
SHMCC
team
加入摘要，加强存
储管枞内容。

内容范围

本文档是上海移动容灾系统方案设计报告，属于机密文件。 适用的对象
本文档适用于参与上海移动容灾项目组的决策者、评估者。

目录

1
摘要
7
2
容灾系统建设意义
8
3
容灾技术方案选型
12
3.1
容灾系统架构方案设计范围
12
3.2
容灾技术方案设计方法
12
3.3
容灾系统建设目标
12
3.4
容灾 7 层技术模型介绍
13
3.5
容灾技术方案选型考虑
16

4 容灾系统方案设计 23

4.1

上海移动系统现状
23
4.2

容灾架构整体设计
24
4.3

容灾系统详细设计
31

4.3.1
本地数据库容灾
31

3.3.2
容灾系统主机设计
32

4.3.2
容灾系统存储设计
46

3.3.4
容灾系统网络设计
53
4.4

容灾系统备份方案设计
71
4.4.1
数据备份概述
71
4.4.2
备份系统现状分析
73
4.4.3
容灾备份系统逻辑设计
75
4.4.4
容灾备份系统配置设计
82
4.4.5
容灾备份系统专业服务
84
4.5

容灾系统管理方案设计
86

4.5.1
存储资源管理
86

4.5.2
存储网络管理
91

5 容灾系统实施计划 94

5.1
灾难恢复计划

94

5.2
上海移动容灾项目实施计划

95
6
附录

96
6.1

机房工程技术说明
96
6.2

上海移动业务支撑系统平台现状概况一览表。
105
6.3

IBM 项目管理服务
107

6.4

支持多厂商的网络存储通用管理软件 SANavigator 版本

114

6.5

容灾系统管理方案设计

121

6.5.1
系统管理现状
121

6.5.2
系统管理需求
122

6.5.3
系统管理架构建议
123

6.5.4
事件管理
126

6.5.5
网络管理
128

6.5.6
数据库管理
129

6.5.7
主机系统监控
131

6.5.8
SLA 管理
133

6.5.9
BOSS 应用管理
134

6.5.10 流程管理 134

1 摘要

一、项目背景

随着电信市场的开放以及中国加入 WTO 进程的进行，中国移动通信面临着前 所未有的发展机遇和挑战。作为一个电信运营商，其 IT 系统的应用直接关乎管 理、服务、成本、效率等各个重要环节，并最终全面影响运营商的竞争力。电信 行业是一个讲究系统高可用性的行业，它要求关键应用服务器必须 24×7 的不间 断运行，以满足超大量用户的实时访问，任何潜在的单点故障都有可能导致整个 系统的瘫痪。为了保证信息系统的稳定和数据的安全，提高业务运营系统的服务 质量，确保在日益激烈的市场竞争中确立主导地位，上海移动决定在现有业务运 营支撑系统的基础上，结合自身的特点和实践经验进行上海移动业务运营支撑容 灾系统工程的建设。
本次上海移动业务运营支撑容灾系统工程的目标，是按照移动集团公司 BOSS 系统容灾备份技术规范和业务规范，主要考虑中国移动业务支撑网中的 BOSS 系统，兼顾经营分析系统。对于 BOSS 系统，将主要考虑其中的营帐子系统， 计费子系统，充值子系统，1860 子系统,综合结算中的网间结算子系统。整个容灾系统建设将遵循统一规划，分步实施的原则。

二、本设计报告内容结构

本容灾设计报告主要分为四大部分：容灾系统建设意义、容灾技术方案选型、 容灾系统方案设计以及容灾系统实施计划。
容灾系统建设意义部分主要从行业竞争需要、业务稳定需要和企业管理需要 三方面阐述了容灾系统的建设意义。
容灾技术方案选型部分主要根据上海移动 BOSS 系统的现状和将来的发展并 满足对应用和在用系统影响最小以及生产系统变动的需要推荐使用存储层+数据 库层的复合容灾方案。
容灾系统方案设计部分主要针对上海移动 BOSS 系统的各个子系统提出了各 自的容灾架构设计，根据各子系统的实时性恢复要求提出对于营帐数据库，充值 数据库和 1860 数据库实施两层容灾设计；对于计费，经营分析，网间结算，批 价等提出存储层的容灾设计。另外还从容灾系统的主机、存储、网络、备份方案 以及存储资源和存储网络管理方案方面作了详细的设计。
容灾系统实施计划部分介绍了如何系统的实施灾难恢复计划以保证灾难发 生时业务操作地连续性。

2 容灾系统建设意义

中国有句古话叫做“天有不测风云，人有旦夕祸福”，充分说明灾难的不可
测性。911 事件是对这句话的最好注脚，在里面办公的 286 家公司的 5 万多名员 工是根本不会想到好端端的坐在办公室里居然会有飞机撞过来。在这种近乎毁灭 性的局部灾难面前，是否有异地容灾系统就变成了关乎企业生存的现实问题。最 近国内也发生了类似灾难，大连某个银行的生产中心突然着火，因为没有灾备系 统，造成全部业务停止两天，这还是不幸中的万幸，因为绝大多数机器设备经过 修复还可以使用，尤其是存储设备，否则，后果真是不堪设想。
很多企业是从 911 事件后开始真正认真考虑容灾的，以往容灾系统的建设往 往被视为锦上添花的项目而不是一个业务可持续性运行的必须项目。我们可以吸 取的教训是一定要建立核心数据和业务的容灾系统，并且平时要加强管理和演 习，加强人员的培训，核心管理人员和技术的分散，以提高计算机系统因为天灾 或人为因素等意外事故导致系统毁坏无法运行时的抵御能力，至少将局部地区核 心业务支持在系统故障时的损失减至最小。
无论是国内还是国外的用户，无论是政府还是企业，现在都在思考这样一个 问题，那就是，假设我们的企业发生了类似的情况，我们是否有足够的备份措施， 企业的数据是否有足够的保障？在美国、日本等一些发达国家，对于关乎国计民 生的行业，有专门的法律要求该企业必须有灾难保护方案，（如美国是 BCC 177） 并且每年都会进行审计和稽核。国内因为目前还没有类似的法律约束，很多企业 对于应用比较重视，但是对于整体系统的可用性考虑得不多，甚至是一些金融企 业，当有类似数据库出错等故障发生时，还依然只能通过倒磁带的方式恢复数据。 这种情况下，丢失数据就是不可避免的了，并且由于恢复时间的漫长，对广大客 户承诺的服务水平又如何能够达到？现在，随着中国加入 WTO，一些国内先进的 有前瞻性的企业也在这方面给予了足够的重视，如上海移动等单位。
随着上海移动业务的飞速发展，业务对 IT 系统的依赖性也随之增加，越来 越多的业务集中到生产主机上，对主机和存储设备都造成了较大的压力。当一个 单位越来越依赖于数据处理去进行它的业务行为时，数据处理的高可靠性和高可 用性就尤为关键，大部分单位的业务处理需要数据处理的高可用性。用户发现如 果没有了数据处理，业务的开展变得极端困难，也许手工操作还可以使用，但那 只能用于短期的应付，一个计算机系统的长期停止运转将直接导致明显的业务后 果，也许还会被追究管理责任。更为重要的是，一旦数据由于某种原因永久性丢 失，不但会给企业的运作带来极大的困难，企业的商业信誉必将受到致命的打击， 在竞争中处于劣势，造成不可估量的后果。
基于这种考虑，中国移动总部提出了在各省建设 BOSS 系统容灾备份的要求， 这个报告书就是为上海移动的容灾系统进行方案设计。本方案中将重点讨论 BOSS 系统的详细容灾方案，兼顾其他业务系统，同时根据上海移动的实际情况

分步实现。
当然，我们考虑容灾系统建设时，也应该实事求是，从实际出发。能够防御 所有灾难的方案是不存在的，也是不现实的。我们认为，计算机系统的灾难定义 是可以由用户自己来定义的，各个行业可以有不同的要求。设计容灾系统时，应 该基于一个合理的前提假设，譬如，在主机房发生故障时，备份机房可以保证数 据的完整性，并且可以在最短时间内完成应用、网络和数据的接管。本方案中的 容灾系统正是基于这种前提来设计，我们暂不考虑那种同时损坏主备机房的可能 性。
让我们再来看看容灾系统建设的意义，这个在移动总部的容灾系统建设规范 中也有多次强调：

行业竞争的需要

美国明尼苏达大学研究机构的统计结果表明，对于银行，金融，证券，电信
等行业的企业而言，如果业务停顿时间长达两天或更长，那么 25% 的企业将立 刻因信誉和业务问题而倒闭，40% 的企业将因为受不断的后续因素的影响导致综 合竞争力的下降而在今后两至五年内被淘汰，五年以后仅有 7% 的企业能够继续 在此行业内生存。
目前，在国内，通讯行业内的竞争本来就很激烈，加之 WTO 之后，国外实力 雄厚的企业对国内市场的窥视，将不可避免地造成企业争夺客户群的白热化的局 面，因此企业总体服务的水平将是影响竞争结果的重要因素。试想，一个时不时 就会抱歉地对客户说：“对不起，由于我们的主机系统有问题，您要求的业务暂 时无法办理……”的企业将无法赢得挑剔的客户的芳心。即使在发生众所周知的 灾害，如果系统也是长时间的无法恢复，也会带来极严重的后果。所以，IT 系 统的完善程度是激烈竞争的一个最重要的前提，在此基础上，企业才能开发丰富 多样的业务品种，提供高质量的服务水平，在竞争中取得优势。不久前发生在南 京的“爱立信跳槽事件”已经表明了中国加入 WTO 后行业竞争的残酷性和现实性。 根据业务的不同，对各种程度的中心系统可靠性要求也不同，如从最高等级 的７X２４X３６５服务，到在指定时间内恢复。为了满足这些要求，更好地为客 户服务，上海移动应当未雨绸缪，尽早制定和建立完备的灾难恢复计划系统，以增强系统的抗灾能力，最大限度地减小损失。

业务稳定的需要

时至今日，企业业务运营对信息系统的运作的依赖性越大，就对信息系统运
作的稳定性和可靠性的要求越高。 而信息系统可用的定义已不再局限于主机设备的可用，而是从主机，存储，用户终端，网络设备整体的物理可用，到系统，数据库，应用软件，用户数据的 逻辑可用。
然而，由于各种因素的影响，小至一般性的硬件故障，大到区域性的自然灾 害，从物理的设备不可用，到逻辑的人为失误和破坏，都可能造成整个信息系统 的全面瘫痪，从而导致业务运营的停顿。因此，同一机房中的双主机恢复系统有 很多企业已经觉得不能满足需求，特别是因为应用的要求而作了区域集中或全国大集中的企业，在享受数据集中带来的诸多好处时，同时也承担着数据丢失或者IT 系统不可用带来的巨大风险。从以下这份国外的研究报告中我们可以知道这 些担忧不是杞人忧天。这是 1996 年 Source Contingency Planning Research Inc。 对于各种因素包括自然灾害：水灾、风灾、地震、大雪、野火 结构破坏：电力中断、火灾、爆炸 操作问题：硬件问题、病毒入侵、操作失误、人为破坏。
让我们暂时抛开满脑子的灾难，来考虑一下即使是机器没有发生故障是否也是 7Ｘ２４小时可用呢？我们认为，现实环境中，这种情况也是不现实的，我们 经常会进行一些正常的日常维护活动。假设我们认为，所有灾难都是属于非计划 中的系统不可用，那么还有很大一部分系统不可用时间是属于计划中的，从下图 中我们可以看到非计划宕机只是占了 IT 系统不可用的 10%，而计划中的宕机占了 90%。 如果我们有了容灾系统，起码我们可以将很多计划中的停机事件避免，如数据备份，完全可以在容灾中心进行，同时，我们可以利用容灾中心做许多诸如新 的应用程序测试，压力测试等等，若是结合第二份数据镜像功能，我们完全可以 轻松自如的在容灾中心进行数据查询，数据挖掘等业务。当然，这些业务在只有 一份远程镜像时也可以实现，只是需要较为仔细和复杂的操作，并且有可能暂时 中断镜像等，相比之下没有前者操作方便简单，对生产系统的冲突更小。

Definition of Outages

Most Customer Outages are caused by
Data Base Backup and
Change Control
Planned
Outages
90.0%


Unplanned
Outages
10.0%

DB
Backup
52.0%


Operations
25.0%

Software
30.0%

Other
9.0%

Application
8.0% Hardware
8.0%
Software
13.0%

Network
10.0%


Hardware
15.0%


Other
3.0%

Application
27.0%

l a n n e d
 n p la n n e d

图：造成系统不可用的因素

企业管理的需要

美国 911 恐怖袭击事件之后，华尔街上几乎所有的金融机构都未受到致命的
影响，这都要归功于企业制定的业务持续性计划。企业管理标准要求，每个企业 应该具备一套保证企业在发生紧急事故时能够从容应对的管理计划，这就是业务 持续性计划。这套计划将使得客户能够在灾难时启动相关的备份设备，协调人员 流动，应对媒体访问，确保业务的正常运营。
作为业务持续性计划的一部分，信息系统的灾难恢复计划的制定是非常重要 和关键的，它将直接决定企业业务应用的恢复时间，制定信息系统的容灾计划也 是对现有投资的保护。信息系统设备，软件的购买和应用是为了能更好的处理业 务，由此获得的客户满意和竞争实力不应该因为一次严重的故障而丧失殆尽。信 息系统的容灾计划将使企业在紧急状况下仍能够正常营业，从而显示出更强于其 它企业的竞争力。

3 容灾技术方案选型

3.1 容灾系统架构方案设计范围

根据上海移动的要求，本次容灾系统架构方案设计将主要考虑中国移动业务 支撑网中的 BOSS 系统，兼顾经营分析系统。对于 BOSS 系统，将主要考虑其中的 营帐子系统，计费子系统，充值子系统，1860 子系统,综合结算中的网间结算子 系统。整个容灾系统建设将遵循统一规划，分步实施的原则，而不是一蹴而就的。

3.2 容灾技术方案设计方法

移动总部的容灾系统业务规范建议容灾系统按照以下的方法论进行，本设计 是具体的方案设计部分。

人 员
调 控

需 求 分 析

需 求 分 析 方 案 设 计

核核核核 心心心心 业业业业 务务务务 及及及及 其其其其
关关关关 联联联联 业业业业 务务务务

习 、 测 试 、 维 护 方 案 实 施

需 求 分 析 方 案 设 计

核核核核 心心心心 业业业业 务务务务 及及及及 其其其其
关关关关 联联联联 业业业业 务务务务

习 、 测 试 、 维 护 方 案 实 施

核 心 业 务 及 其 关 联 业 务
方 案 设 计


En te rp ri

演 习 、 测 试 、 维 护
驱 动
方 案 实 施 计 划

流 程 技 术

映 射

3.3 容灾系统建设目标

业界在建设容灾系统时，主要考虑以下的目标参数：

恢复时间目标（RTO） 在系统不可用的情况下，你可以忍受多长时间？这 个参数定义了系统能够容忍的最长停机时间；

恢复点目标（RPO）当系统被恢复时，你可以忍受多少数据需要重新建立？
这个参数定义了系统能够容忍的最多数据丢失；
网络恢复目标（NRO） 需要多长时间才可以切换网络？这个参数定义了系 统能够容忍的最长网络停机时间。
一个应用的完全恢复应该包括主机，数据库，应用程序，网络连接，应用服 务器和应用界面的完全可用。所以具体到一个特定的应用，具体的技术指标会不 一样。在移动总部的规范中将 BOSS 的容灾恢复指标定义为 2 级。根据上海移动 的具体实际，我们认为，将联机交易处理类的应用如营帐，1860，充值等业务的 恢复目标定义为 2 小时以内，非联机交易如计费的恢复时间定在 4 小时以内是比 较现实的。（这个时间没有包括决策是时间，但是包括网络切换时间）。

3.4 容灾 7层技术模型介绍

首先让我们看看业界公认的容灾技术方案等级，灾难备援技术方案的七个级 别：7 Tiers for Disaster Recovery Solution，是指根据国际标准 SHARE 78 的定义，灾难备援技术方案可以根据以下主要方面所达到的程度而分为七级：
1、 备份/恢复的范围
2、 灾难恢复计划的状态
3、 应用站点与备援站点之间的距离
4、 应用站点与备援站点之间是如何相互连接的
5、 数据是怎样在两个站点之间传送的
6、 允许有多少数据被丢失
7、 怎样保证更新的数据在备援站点被更新
8、 备援站点可以开始备援工作的能力

即从低到高有七种不同层次的灾难恢复解决方案。 如下图所示，该七个级别的灾难备援的技术方案分别是：

µ Tier 1 - PTAM“卡车”运送访问方式 (Pickup Truck Access Method)
µ Tier 2 - PTAM 卡车运送访问方式+热备份站点 (PTAM + Hotsite)
µ Tier 3 - 电子链接方式 (Electronic Vaulting)
µ Tier 4 - 数据库镜像和日志方式 (Batch/Online Database Shadowing
& Journaling)
µ Tier 5 - 两点两阶段提交 (Two-Site Two-Phase Commit)
µ Tier 6 - 无数据丢失 (Zero Data Loss)
µ Tier 7 - 无数据丢失和应用自动切管 （Zero Data Loss + App Automatic takeover）

以上七个级别的灾难备援的技术方案的特点和区别，可以参照如下描述：

七层模型的可恢复性比较

有无室内备份? Y/N
N
Y
Y
Y
Y
Y
Y
Y

容灾层次
0
1
2
3
4
5
6
7
保存的信息 (数据，指令，文档)
N
Y/N
Y
Y
Y
Y
Y
Y
Determination of requirements
N
Y
Y
Y
Y
Y
Y
Y
专用的容灾硬件和机房
N
Y/N
Y
Y
Y
Y
Y
Y
灾难恢复计划
N
N
Y
Y
Y
Y
Y
Y
选择性的异地数据保存
N
N
Y
Y
Y
Y
Y
Y

支持危机时候的足够的硬件和网络设备

N

N

Y

Y

Y

Y

Y

Y

至少部分信息的电子方式的备份

N

N

N

Y

Y

Y

Y

Y
Active management of recovery data by a
processor at the recovery site

N

N

N

N

Y

Y

Y

Y
双向恢复
N
N
N
N
Y
Y
Y
Y
物理分离

N

N

N

N

Y

Y

Y

Y

所选数据的镜像

N

N

N

N

N

Y

Y

Y
异地部分或全部的硬件备份
N
N
N
N
N
Y
Y
Y
主备中心数据即时异地传输
N
N
N
N
N
N
Y
Y

根据策略自动切换到灾备中心

N

N

N

N

N

N

N

Y

典型恢复时间
Upto
Never
> 1
week
> 1
day

1 day
< 1
day
< 12
hours
< 6
hours
Few
Mins.

Tier 1 - PTAM“卡车”运送访问方式 (Pickup Truck Access Method)

Tier 1 的灾难恢复方案必须设计一个严格的数据备份方案，能够备份所需 要的信息并将它递送存放在异地，然后根据恢复的具体需求，有选择地建立 备份平台，但不提供数据处理的硬件。
PTAM 是一种被用于许多中心的备份的标准的方式，数据在完成写操作的一 些时候，将会被送到远离本地的地方，同时准备有数据恢复的程序。在灾难

发生后，一整套安装需要在一台未开启的计算机上重新完成。系统和数据可
以被恢复并重新与网络相连。这种灾难恢复方案相对来说成本较低(仅仅需 要传输工具的消耗以及存储设备的消耗)。但同时有这样的问题，那就是难 于管理，即很难知道什么样的数据在什么样的地方。

Tier 2 - PTAM 卡车运送访问方式+热备份站点 (PTAM + Hotsite)

Tier 2 相当于 Tier 1 再加上热备份中心能力的进一步的灾难恢复。热备份 中心拥有足够的硬件和网络设备去支持关键应用的安装需求，这样的应用是 十分的关键的，它必须在灾难发生的同时，在异地有与生产环境相类似的硬 件提供支持。这种灾难恢复的方式依赖于 PTAM 方法去将日常数据放入仓库， 当灾难发生的时候，数据再被移动到一个热备份的中心。虽然移动数据到一 个热备份中心增加了成本，但却明显降低了灾难恢复时间。

Tier 3 - 电子链接方式 (Electronic Vaulting)
Tier 3 是在 Tier 2 的基础上用电子链路取代了卡车进行数据的传送的进一 步的灾难恢复。接收方的硬件必须与主中心物理地相分离，在灾难发生后， 存储的数据用于灾难恢复，由于热备份中心要保持持续运行，增加了成本。 但消除了传输工具的需要，提高了灾难恢复速度。

Tier 4 - 数据库镜像和日志方式 (Batch/Online Database Shadowing & Journaling)

Tier 4 是在 Tier3 的基础上，以数据库远程备份为基础。灾难恢复具有两 个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个 方向发生。接收方硬件必须保证与另一方平台物理地分离，在这种情况下， 工作负载可能在两个中心之间分享，中心 1 成为中心 2 的备份，反之亦然。 在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。在灾难发 生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的 恢复也可降低到小时级。

Tier 5 - 两点两阶段提交 (Two-Site Two-Phase Commit)

Tier 5 在 Tier 4 的基础上管理着被选择的数据(根据单一 commit 的范围在 本地和远程数据库中同时更新数据)，也就是说，在更新请求被认为是满意 之前，Tier 5 需要生产中心与备份中心的数据都被更新。我们可以想象这 样一种情景，数据在两个中心之间相互映像，由远程 two-phase commit 来 同步。Tier5 为关键应用使用了双重在线存储，在灾难发生时，仅仅传送中 的数据被丢失，恢复时间被降低到分钟级。

Tier 6 - 无数据丢失 (Zero Data Loss)
Tier 6 可以实现零数据丢失率，同时保证数据立即自动地被传输到恢复中 心。Tier6 被认为是灾难恢复的相当高的级别，通过使用文件系统或存储硬 件底层的数据同步/异步镜像功能，保证数据的实时一致性和完整性。

Tier 7 - 无数据丢失和应用自动切管 （Zero Data Loss + App Automatic
takeover）

Tier 7 在 Tier 6 的基础上，在本地和远程的所有数据被更新的同时，利用 了双重在线活动的主机，备份数据和完全的网络切换能力，实现应用程序的 实时监控和接管。Tier7 是灾难恢复中最昂贵的方式，但也是需人工干预最 少，速度最快的恢复方式。

3.5 容灾技术方案选型考虑

首先让我们确定一下此次容灾建设的一些背景条件：

1. 移动总部发布了 BOSS 1.5 规范，上海移动正在加紧进行 BOSS 应用的改 造。这个说明在容灾系统实施的同时，业务环境也在发生变化。所以对 于具体选用何种技术就有很高的要求，譬如说通过应用程序层来实现容 灾就不现实了，因为一旦业务改动就需要改动容灾方案，基本上是不可 能的事情。
2. 局方同时可能会启动 BOSS 网管项目，整个业务支撑平台的系统管理都 会在网管项目中考虑，所以在这个方案设计报告中就不对系统管理这一 块内容加以详细阐述。
3. 本方案设计书将阐述 BOSS 网管没有具体规定的存储和存储网的管理。

在我们的设计报告中，我们首先对整个容灾系统的架构进行设计，然后对其 中的各个要素分别加以阐述。

容灾系统建设中很重要的是如何将生产数据传输或复制到容灾中心，我们需 要考虑的是在系统的那一个层次上的复制数据和采用何种机制。 技术的发展让 我们有了更多更好的选择而不必受一些具体产品的约束。下图是目前业界最常用 的成熟的技术。

我们认为，首先需要一种技术方案，它的建设实施对应用和在用系统影响最
小，同时又能满足生产系统变动的需要。而对于某些特定应用，如果仅仅采用其 中的一种方案是可能不能完全满足恢复需要，如一些联机的实时交易的应用，一 种方式显得太单薄，所以对这些应用，我们建议用复合式的容灾技术方案。究竟 以那种技术为主，那种为辅，应该考虑实际情况。
下图是最近移动钦州机房发生影响生产的故障统计：

2004年1月到8月影响生产的故障统计

26%

39%

6%

26% 3%

数据库故障
应用故障
网络故障
主机故障
例行维护

从中可以看出，发生频率最高，对生产造成最大影响的是数据库故障，其次
是至少每月一次的例行维护和较高的网络故障，而应用故障和主机故障相对影响 较小。其中的数据库故障大多时候都可以通过重启数据库来解决，这些本身可能 由于 Oracle 8 版本软件的缺陷造成，数据库重启时往往涉及到 recovery 过程， 如果有些意外发生时，recovery 的过程会很长，可能几个小时才能完成，这时 重启数据库就远远不能满足业务需求。针对这种情况，我们认为，保持数据库的 高可用性是最重要的，其次是网络，在上海移动，IP 网络目前的故障较多，而 光网路相对来说比较稳定，这也为采用存储层的使用 DWDM 技术的方案提供的基 础保证。就数据本身而言，字节程度的一致性的重要性比不上交易程度的一致性 来得重要，所以，我们应该强调当生产数据库发生故障时，可以最快速度恢复。

基于以上考虑我们给出下表的推荐，5 为最高，1 为最低。

容灾技术
技术
成熟 度
数据丢失
情况
硬件要求
实施难
易程度
对在用系
统影响
推荐程度
（1－5）
存储服务器层
（ tier 6）
成熟
不丢或少
量
同一品牌
存储
较易
较少
4
SAN 层
(tier 6)
成熟
不丢或少
量
FC 连接
较易
较少
3
操作系统层
(tier 6 or 7)
成熟
不丢或少
量
同一品牌
主机
较易
较大
3

数据库层(tire
4 or 5)
成熟
部分丢失

较易
较大
3.5

由表中可以看出，对于建议采用复合方式的应用来说，我们推荐使用数据库
层和存储层结合的复合方案。存储层可以在存储产品层，也可以在 SAN 交换机层。

手动/自动启动容灾 我们知道，自动容灾技术可以自动识别灾难的发生并且自动启动恢复程序，
将应用在容灾中心自动重启。可是结合国内实情，自动容灾方式并不是很适合上 海移动，因为是否启动容灾系统不仅仅是一个技术问题，其中有一个决策过程， 还有一个切换的程度的问题。采用手动切换，可以将主动权握在手里。
传统磁盘远程镜像的基本概念 传统基于磁盘的镜像方式是由存储设备控制通过数据通道，以逻辑卷为基
本单位，将本地磁盘阵列上的数据镜像到远端的同构磁盘阵列上――比如 IBM
的 PPRC 和 EMC 的 SRDF。

基于磁盘的镜像功能传统上提供 2 种工作方式，同步（左图）和异步方式
（右图）：

在同步方式下，磁盘镜像功能只有在本地和远程磁盘都完成写操作后才会向 主机发回“IO 完成”消息，以确保源卷和目的卷的数据彻底一致。

好处是：
· 可以保证数据不会丢失
· 可以保证数据的一致性 缺点是：
· 对网络和距离要求很高：需要高带宽和距离一般不能超越城域
· 对生产系统的性能影响也比较大

在异步工作方式下，磁盘镜像功能能够在远端更新未完成的情况下，只要本
地更新成功就可以向主机返回“写成功”信号。

好处是：
· 对网络和距离的要求非常低
· 对性能的影响非常小

坏处是：
· 数据一般情况下会丢失
· 普通异步方式无法保证 IO 的次序，所以在进行异步操作时，远程镜 像卷始终处于异步造成的“不一致”状态，直到所有数据“全部传递 完毕”。如果应用是 7*24 小时不间断的，就无法达到数据“全部传 递完毕”状态。所以，异步备份一般只用于数据移植，或者和磁盘本 地镜像结合，用于传递相对静止的数据

保证数据一致性的异步远程镜像 为了同时利用同步的数据一致性优势和异步的性能/距离优势，各个存储厂
商都推出了一些能够保证数据一致性的异步远程镜像方式，主要是 IBM 的 PPRC
GM 和 EMC 的 SRDF/A。
为了 100%的保证数据一致性和可用性，所有类似的技术都必须采用 3 份数 据的方式进行操作（本地 1 份，远程 2 份）。
IBM PPRC GM 的工作方式如下：

工作方式如下（其中绿色为生产站点磁盘<PPRC 源盘>，橙色<PPRC 目标盘
/FlashCopy 源盘>和蓝色< FlashCopy 目标盘>为容灾站点磁盘）：
1. 绿色和橙色磁盘之间进行 PPRC-XD 异步操作
2. 绿色磁盘组根据预先设置的时间，生成“一致性组”（Consistency
Group），并记录状态
3. 采用 PPRC-XD 异步操作方式，将且只将“一致性组”记录下来的数据 传递从绿色磁盘组传递到橙色磁盘组
4. 3 完成后，立刻将橙色磁盘组数据 FlashCopy 到蓝色磁盘组，进行一 致性数据保留
5. 4 完成后，回到步骤 1

由于有“一致性组”的保护，虽然采用异步方式，一旦每一个“一致性组” 数据包传递成功的那一时刻，橙色磁盘组的数据是一致的；由于步骤 4，蓝色磁 盘组将能够保留最近一次“一致性完全”的数据。一旦出现灾难，客户丢失的是 两次生成“一致性组”间隔之间的数据。

如果网络发生故障，PPRC GM 会等待网络恢复，重新生成“一致性组”（对 于经历的较长时间网络故障的系统而言，只是新的“一致性组”中的数据会比较 大而已），继续进行 PPRC GM 的正常操作。

PPRC GM 能够每 3～5 秒生成一次“一致性组”，意味着客户即使采用异步方 式，也有可能只丢失 3～5 秒的数据。

EMC SRDF/A 的工作方式如下：