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

知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 上海移动容灾系 统 方案设计报 告 IBM 公司上海分公司 Version 5.0 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 IBM专 有 信息 声 明 本设计报 告 属商业机 密 文件，书 中 的所有信 息 均 为 IBM机 密信息， 仅 供上 海 移动容灾项目使用 。务请妥善保管并且仅在与项目有关人员范围内使用 ，未经 IBM 公司明确做出的书面许可 ， 不得为任何目的 、 以任何形式或手 段 （包括电子 、 机 械 、 复印 、 录音或其他形式 ） 对本文档的任何部分进行复制 、 存储 、 引入检索系 统或 者传播。 尽管 IBM已 经尽力保 证 本文档内 容 的完整性 和 有效性， 但 仍可能存 在 某 些 方 面不够 准确 的地方 或印 刷错误 。若 需求有 所变 化， IBM将 对有关 内容 进行相对 应 的调整，并在本报告的未来版本中体现。 IBM是国 际 商业机器 公 司的注册 商 标。本文 档 提及的其 他 公 司 、产 品 和服 务 的名称，可能是其他公司的商标或服务的标志。 Copyright IBM China Company Limited All rights reserved 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 关于本文档 文档信息 文 档 名 称 上海移动容灾系统方案设计报告 作者 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 加入 摘要 ，加 强 存 储管枞内容。 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 内容范围 本文档是上海移动容灾系统方案设计报告，属于机密文件。 适用的对象 本文档适用于参与上海移动容灾项目组的决策者、评估者。 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 目录 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 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 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 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 1 摘要 一、项 目 背景 随着电信市场的开放以及中国加入 WTO 进程的进行，中国移动通信面临着前 所未有的发展机遇和挑战。作为一个电 信运营商，其 IT 系统的应用直接关乎管 理、服务、成本、效率等各个重要环节，并最终全面影响运营商的竞争力。电信 行业是一个讲究系统高可用性的行业，它要求关键应用服务器必须 24 7 的不间 断运行，以满足超大量用户的实时访问，任何潜在的单点故障都有可能导致整个 系统的瘫痪。为了保证信息系统的稳定和数据的安全，提高业务运营系统的服务 质量，确保在日益激烈的市场竞争中确立主导地位，上海移动决定在现有业务运 营支撑系统的基础上，结合自身的特点和实践经验进行上海移动业务运营支撑容 灾系统工程的建设。 本次上海移动 业务运营支撑容灾系统工程的目标，是按照移动集团公司 BOSS 系统容灾备份技术规范和业务规范，主要考虑中国移动业务支撑网中的 BOSS 系统，兼顾经营分析系统。对于 BOSS 系统，将主要考虑其中的营帐子系统， 计费子系统，充值子系统， 1860 子系统 ,综合结算中的网间结算子系统。整个容灾系统建设将遵循统一规划，分步实施的原则。 二、本 设 计报告 内 容结构 本容灾设计报告主要分为四大部分：容灾系统建设意义、容灾技术方案选型、 容灾系统方案设计以及容灾系统实施计划。 容灾系统建设意义部分主要从行业竞争需要、 业务稳定需要和企业管理需要 三方面阐述了容灾系统的建设意义。 容灾技术方案选型部分主要根据上海移动 BOSS 系统的现状和将来的发展并 满足对应用和在用系统影响最小以及生产系统变动的需要推荐使用存储层 +数据 库层的复合容灾方案。 容灾系统方案设计部分主要针对上海移动 BOSS 系统的各个子系统提出了各 自的容灾架构设计，根据各子系统的实时性恢复要求提出对于营帐数据库，充值 数据库和 1860 数据库实施两层容灾设计；对于计费，经营分析，网间结算，批 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 价等提出存储层的容灾设计。另外还从容灾系统的主机、存储、网 络、备份方案 以及存储资源和存储网络管理方案方面作了详细的设计。 容灾系统实施计划部分介绍了如何系统的实施灾难恢复计划以保证灾难发 生时业务操作地连续性。 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 2 容灾系统建设意义 中国有句古话叫做“天有不测风云，人有旦夕祸福”，充分说明灾难的不可 测性。 911 事件是对这句话的最好注脚，在里面办公的 286 家公司的 5 万多名员 工是根本不会想到好端端的坐在办公室里居然会有飞机撞过来。在这种近乎毁灭 性的局部灾难面前，是否有异地容灾系统就变成了关乎企业生存的现实问题。最 近国内也发生了类 似灾难，大连某个银行的生产中心突然着火，因为没有灾备系 统，造成全部业务停止两天，这还是不幸中的万幸，因为绝大多数机器设备经过 修复还可以使用，尤其是存储设备，否则，后果真是不堪设想。 很多企业是从 911 事件后开始真正认真考虑容灾的，以往容灾系统的建设往 往被视为锦上添花的项目而不是一个业务可持续性运行的必须项目。我们可以吸 取的教训是一定要建立核心数据和业务的容灾系统，并且平时要加强管理和演 习，加强人员的培训，核心管理人员和技术的分散，以提高计算机系统因为天灾 或人为因素等意外事故导致系统毁坏无法运 行时的抵御能力，至少将局部地区核 心业务支持在系统故障时的损失减至最小。 无论是国内还是国外的用户，无论是政府还是企业，现在都在思考这样一个 问题，那就是，假设我们的企业发生了类似的情况，我们是否有足够的备份措施， 企业的数据是否有足够的保障？在美国、日本等一些发达国家，对于关乎国计民 生的行业，有专门的法律要求该企业必须有灾难保护方案，（如美国是 BCC 177） 并且每年都会进行审计和稽核。国内因为目前还没有类似的法律约束，很多企业 对于应用比较重视，但是对于整体系统的可用性考虑得不多，甚至是一些金融企 业，当有类似数据库出错等故障发生时，还依然只能通过倒磁带的方式恢复数据。 这种情况下，丢失数据就是不可避免的了，并且由于恢复时间的漫长，对广大客 户承诺的服务水平又如何能够达到？现在，随着中国加入 WTO，一些国内先进的 有前瞻性的企业也在这方面给予了足够的重视，如上海移动等单位。 随着上海移动业务的飞速发展，业务对 IT 系统的依赖性也随之增加，越来 越多的业务集中到生产主机上，对主机和存储设备都造成了较大的压力。当一个 单位越来越依赖于数据处理去进行它的业务行为时，数据处理的高可靠性和高可 用性就尤为 关键，大部分单位的业务处理需要数据处理的高可用性。用户发现如 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 果没有了数据处理，业务的开展变得极端困难，也许手工操作还可以使用，但那 只能用于短期的应付，一个计算机系统的长期停止运转将直接导致明显的业务后 果，也许还会被追究管理责任。更为重要的是，一旦数据由于某种原因永久性丢 失，不但会给企业的运作带来极大的困难，企业的商业信誉必将受到致命的打击， 在竞争中处于劣势，造成不可估量的后果。 基于这种考虑，中国移动总部提出了在各省建设 BOSS 系统容灾备份的要求， 这个报告书就是为上海移动的容灾系统进行方案设 计。本方案中将重点讨论 BOSS 系统的详细容灾方案，兼顾其他业务系统，同时根据上海移动的实际情况 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 分步实现。 当然，我们考虑容灾系统建设时，也应该实事求是，从实际出发。能够防御 所有灾难的方案是不存在的，也是不现实的。我们认为，计算机系统的灾难定义 是可以由用户自己来定义的，各个行业可以有不同的要求。设计容灾系统时，应 该基于一个合理的前提假设，譬如，在主机房发生故障时，备份机房可以保证数 据的完整性，并且可以在最短时间内完成应用、网络和数据的接管。本方案中的 容灾系统正是基于这种前提来设计，我们 暂不考虑那种同时损坏主备机房的可能 性。 让我们再来看看容灾系统建设的意义，这个在移动总部的容灾系统建设规范 中也有多次强调： 行业竞争的需要 美国明尼苏达大学研究机构的统计结果表明，对于银行，金融，证券，电信 等行业的企业而言，如果业务停顿时间长达两天或更长，那么 25% 的企业将立 刻因信誉和业务问题而倒闭， 40% 的企业将因为受不断的后续因素的影响导致综 合竞争力的下降而在今后两至五年内被淘汰，五年以后仅有 7% 的企业能够继续 在此行业内生存。 目前，在国内，通讯行业内的竞争本来就很激烈，加之 WTO 之后，国外实力 雄厚的企业对国内市场的窥视，将不可避免地造成企业争夺客户群的白热化的局 面，因此企业总体服务的水平将是影响竞争结果的重要因素。试想，一个时不时 就会抱歉地对客户说：“对不起，由于我们的主机系统有问题，您要求的业务暂 时无法办理”的企业将无法赢得挑剔的客户的芳心。即使在发生众所周知的 灾害，如果系统也是长时间的无法恢复，也会带来极严重的后果。所以， IT 系 统的完善程度是激烈竞争的一个最重要的前提，在此基础上，企业才能开发丰富 多样的业务品种，提供高质量的服务水平，在竞争中取得优势 。不久前发生在南 京的“爱立信跳槽事件”已经表明了中国加入 WTO 后行业竞争的残酷性和现实性。 根据业务的不同，对各种程度的中心系统可靠性要求也不同，如从最高等级 的 X X服务，到在指定时间内恢复。为了满足这些要求，更好地为客 户服务，上海移动应当未雨绸缪，尽早制定和建立完备的灾难恢复计划系统，以增强系统的知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 抗灾能力，最大限度地减小损失。 业务稳定的需要 时至今日，企业业务运营对信息系统的运作的依赖性越大，就对信息系统运 作的稳定性和可靠性的要求越高。 而信息系统可用的定义已不再局限于主机设 备的可用，而是从主机，存储，用户终端，网络设备整体的物理可用，到系统，数据库，应用软件，用户数据的 逻辑可用。 然而，由于各种因素的影响，小至一般性的硬件故障，大到区域性的自然灾 害，从物理的设备不可用，到逻辑的人为失误和破坏，都可能造成整个信息系统 的全面瘫痪，从而导致业务运营的停顿。因此，同一机房中的双主机恢复系统有 很多企业已经觉得不能满足需求，特别是因为应用的要求而作了区域集中或全国 大集中的企业，在享受数据集中带来的诸多好处时，同时也承担着数据丢失或者 IT 系统不可用带来的巨大风险。从以下这份国外的 研究报告中我们可以知道这 些担忧不是杞人忧天。这是 1996 年 Source Contingency Planning Research Inc 。 对于各种因素包括自然灾害：水灾、风灾、地震、大雪、野火 结构破坏：电力中断、火灾、爆炸 操作问题：硬件问题、病毒入侵、操作失误、人为破坏。 让我们暂时抛开满脑子的灾难，来考虑一下即使是机器没有发生故障是否也是 7小时可用呢？我们认为，现实环境中，这种情况也是不现实的，我们 经常会进行一些正常的日常维护活动。假设我们认为，所有灾难都是属于非计划 中的系统不 可用，那么还有很大一部分系统不可用时间是属于计划中的，从下图 中我们可以看到非计划宕机只是占了 IT 系统不可用的 10%，而计划中的宕机占了 90%。 如果我们有了容灾系统，起码我们可以将很多计划中的停机事件避免，如数据备份，完全可以在容灾中心进行，同时，我们可以利用容灾中心做许多诸如新 的应用程序测试，压力测试等等，若是结合第二份数据镜像功能，我们完全可以 轻松自如的在容灾中心进行数据查询，数据挖掘等业务。当然，这些业务在只有 一份远程镜像时也可以实现，只是需要较为仔细和复杂的操作，并且有可能暂时 中断 镜像等，相比之下没有前者操作方便简单，对生产系统的冲突更小。知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 Definition of Outages Most Customer Outages are caused by D ata Base Backup and C hange 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 图：造成系统不可用的因素 企 业 管理的需要 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 美国 911 恐怖袭击事件之后，华尔街上几乎所有的金融机构都未受到致命的 影响，这都要归功于企业制定的业务持续性计划。企业管理标准要求，每个企业 应该具 备一套保证企业在发生紧急事故时能够从容应对的管理计划，这就是业务 持续性计划。这套计划将使得客户能够在灾难时启动相关的备份设备，协调人员 流动，应对媒体访问，确保业务的正常运营。 作为业务持续性计划的一部分，信息系统的灾难恢复计划的制定是非常重要 和关键的，它将直接决定企业业务应用的恢复时间，制定信息系统的容灾计划也 是对现有投资的保护。信息系统设备，软件的购买和应用是为了能更好的处理业 务，由此获得的客户满意和竞争实力不应该因为一次严重的故障而丧失殆尽。信 息系统的容灾计划将使企业在紧急状况下仍能够正常营 业，从而显示出更强于其 它企业的竞争力。 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 需 求 分 析 方 案 设 计 核核核核 心心心心 业业业业 务务务务 及及及及 其其其其 关关关关 联联联联 业业业业 务务务务 习 、 测 试 、 维 护 方 案 实 施 需 求 分 析 方 案 设 计核核核核 心心心心 业业业业 务务务务 及及及及 其其其其关关关关 联联联联 业业业业 务务务务习 测 试 维 护 方 案 实 施3 容灾技术方案选型 3.1 容灾系统架构方案设计范围 根据上海移动的要求，本次容灾系统架构方案设计将主要考虑中国移动业务 支撑网中的 BOSS 系统，兼顾经营分析系统。对于 BOSS 系统，将主要考虑其中的 营帐子系统，计费子系统，充值子系统， 1860 子系统 ,综合结算中的网间结算子 系统。整个容灾系统建设将遵循统一规划，分步实施的原则，而不是一蹴而就的。 3.2 容灾技术方案设计方法 移动总部的容灾系统业务规范建议容灾系统按 照以下的方法论进行，本设计 是具体的方案设计部分。 人 员 调 控 需 求 分 析核 心 业 务 及 其 关 联 业 务方 案 设 计 En te rp ri 演 习 、 测 试 、 维 护 驱 动 方 案 实 施 计 划 流 程 技 术 映 射 3.3 容灾系统建设目标 业界在建设容灾系统时，主要考虑以下的目标参数： 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 恢复时间目标（ RTO） 在系统不可用的情况下，你可以忍受多长时间？这 个参数定义了系统能够容忍的最长停机时间； 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 恢复点目标（ 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、 备援站点可以开始备援工作的能力 即从低到高有七种不同层次的灾难恢复解决方案。 如下图所示，该七个级别的灾难备援的技术方案分别是： 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 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 是 一种被用于 许 多中心的 备 份的标准 的 方式，数 据 在完成写 操 作的 一 些时候 ， 将会被送到远离本地的地方 ， 同时准备有数据恢复的程序 。 在灾难 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 发生后 ， 一整套安装需要在一台未开启的计算机上重新完成 。 系统和数据可 以被恢 复并 重新与 网络 相连。 这种 灾难恢 复方 案相对 来说 成本较 低 (仅仅 需 要传输 工具 的消耗 以及 存储设 备的 消耗 )。但 同时有 这样 的问题 ， 那 就是 难 于管理，即很难知道什么样的数据在什么样的地方。 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 被认为是灾难恢复的相当高的级别 ， 通过使用文件系统或存储硬 件底层的数据同步 /异步镜像功能，保证数据的实时一致性和完整性。 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 Tier 7 - 无 数 据丢失和 应 用自动切管 （ Zero Data Loss + App Automatic takeover） Tier 7 在 Tier 6 的基础上，在本地和远程的所有数据被更新的同时，利用 了双重在 线活动的主机 ， 备份数据和完全的网络切换能力 ， 实现应用程序的 实时监控和接管 。 Tier7 是灾难恢复中最昂贵的方式 ， 但也是需人工干预最 少，速度最快的恢复方式。 3.5 容灾技术方案选型考虑 首先让我们确定一下此次容灾建设的一些背景条件： 1. 移动总部发布了 BOSS 1.5 规范，上海移动正在加紧进行 BOSS 应用的改 造 。 这个说明在容灾系统实施的同时 ， 业务环境也在发生变化 。 所以对 于具体选用何种技术就有很高的要求 ， 譬如说通过应用程序层来实现容 灾就不现实了 ， 因为一旦业务改动就需要改动容灾 方案 ， 基本上是不可 能的事情。 2. 局方同时可能会启动 BOSS 网管项目，整个业务支撑平台的系统管理都 会在网管项目中考虑 ， 所以在这个方案设计报告中就不对系统管理这一 块内容加以详细阐述。 3. 本方案设计书将阐述 BOSS 网管没有具体规定的存储和存储网的管理。 在我们的设计报告中 ， 我们首先对整个容灾系统的架构进行设计 ， 然后对其 中的各个要素分别加以阐述。 容灾系统建设中很重要的是如何将生产数据传输或复制到容灾中心 ， 我们需 要考虑 的是 在系统 的那 一个层 次上 的复制 数据 和采用 何种 机制 。 技 术的 发展 让 我们有了更多更好的选择而不必受一些具体产品的约束 。 下图是目前业界最常用 的成熟的技术。 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 我们认为 ， 首先需要一种技术方案 ， 它的建设实施对应用和在用系统影响最 小 ， 同时又能满足生产系统变动的需要 。 而对于某些特定应用 ， 如果仅仅采用其 中的一种方案是可能不能完全满足恢复需要 ， 如一些联机的实时交易的应用 ， 一 种方式显得太单薄 ， 所以对这些应用 ， 我们建议用复合式的容灾技术方案 。 究竟 以那种技术为主，那种为辅，应该考虑实际情况。 下图 是最近移动钦州机房发生影响生产的故障统计： 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 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 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 数据库层 (tire 4 or 5) 成熟 部分丢失 较易 较大 3.5 由表中可以看出 ， 对于建议采用复 合方式的应用来说 ， 我们推荐使用数据库 层和存储层结合的复合方案 。存储层可以在存储产品层 ，也可以在 SAN 交换机层。 手 动 /自动启 动 容灾 我们知道，自动容灾技术可以自动识别灾难的发生并且自动启动恢复程序， 将应用在容灾中心自动重启 。 可是结合国内实情 ， 自动容灾方式并不是很适合上 海移动，因为是否启动容灾系统不仅仅是一个技术问题，其中有一个决策过程， 还有一个切换的程度的问题。采用手动切换，可以将主动权握在手里。 传 统 磁盘远程 镜 像的基本 概 念 传统基 于磁 盘的镜 像方 式是由 存储 设备控 制通 过数据 通道 ，以逻 辑卷 为 基 本单位， 将 本地磁盘 阵 列上的数 据 镜像到远 端 的同构磁 盘 阵列上 比 如 IBM 的 PPRC 和 EMC 的 SRDF。 基于磁盘的镜像功能传统上提供 2 种工作方式，同步（左图）和异步方式 （右图）： 在同步方式下 ， 磁盘镜像功能只有在本地和远程磁盘都完成写操作后才会向 主机发回“ IO 完成”消息，以确保源卷和目的卷的数据彻底一致。 好处是： 可以保证数据不会丢失 可以保证数据的一致性 缺点是： 对网络和距离要求很高：需要高带宽和距离一般不能超越城域 对生产系统的性能影响也比较大 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 在异步工作方式下 ， 磁盘镜像功能能够在远端更新未完成的情况下 ， 只要本 地更新成功就可以向主机返回“写成功”信号。 好处是： 对网络和距离的要求非常低 对性能的影响非常小 坏处是： 数据一般情况下会丢失 普通异步方式无法保证 IO 的次序，所以在进行异步操作时，远程镜 像卷始终处于异步造成 的 “不一 致 ” 状态 ， 直 到所有数 据 “全部传递 完毕”。如果应用是 7*24 小时不间断的，就无法达到数据“全部传 递完毕 ” 状 态 。 所以 ， 异步备份一般只用于数据移植 ， 或 者和磁盘本 地镜像结合，用于传递相对 静止的数据 保 证 数据一致 性 的异步远 程 镜像 为了同时利用同步的数据一致性优势和异步的性能/距离优势 ， 各个存储厂 商都推出了一些能够保证数据一致性的异步远程镜像方式，主要是 IBM 的 PPRC GM 和 EMC 的 SRDF/A。 为了 100%的保证数据一致性和可用性 ， 所有类似的技术都必须采用 3 份数 据的方式进行操作（本地 1 份，远程 2 份 ）。 IBM PPRC GM 的 工作方式 如 下： 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 工作方式如下（其中绿色为生产站点磁盘 ，橙色 和蓝色 为容灾站点磁盘 ）： 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 的 工作方式 如 下： 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 SRDF/A 使用“增量集”来短期维护一组写入操作。增量集是 SRDF/A 所 提供的所有功能的基础。 SRDF/A 使 用四 种 类 型 的增 量 集 来 管理 数 据 流 处理 过 程 。 SRDF/A 的 数 据 流可归结为几个步骤 : 源位置的增量集： 捕 获 - 在 缓存 中 捕 获 所有 传 入 到 SRDF/A 组 所涉 及 的 源 卷 的写 入 操 作。 完 成 此“ 捕 获 增量 集 ” 后， 该 集 合中 的 写 入操 作 将被“ 折 叠”， 并升 级为“ 传 输 增量集 ”， 同时开 始传 输其中 的内 容 。（ 然 后另外创建一个新的 捕获增量集 ，来维护下一个写入操作增 量 集 。） 传 输 - 将 内容从 源系 统传输 到目 标系统 ，仅 传输最 近的 写入操 作 集。 目标位置的增量集： 接收 - 接收增量集位于目标系统上 ， 用于接收由源位置的 传输增 量集传来的数据 。 接收到全部数据后 ， 它将升级为 应用增量集 。 应用 - 将增量集中的写入操作应用到目标卷，以创建一致的可重新 启动的远程拷贝。这就完成了增量集循环。 如果网络发生故障 ， 由于 SRDF/A 使用 “ 增量集 ” 存在于磁盘系 统的高速缓存 中，一 定时 间的故 障会 造成高 速缓 存溢出 ，此 时必须 中断 SRDF/A，等待网络 恢 复。从网络故障到恢复之间的数据只能够采用传统的 SRDF 异步方式传递，为了 防止异步传递被异常中断而造成对远程数据库的破坏 ， 在传递数据之前必须采用 TimeFinder 保护一下远程的数据，然后才能够继续操作。 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 4 容灾系统方案设计 4.1 上海移动系统现状 上海移动目前主要有两个生产机房 ， 一个在钦州 ， 一个在横浜 ， 业务分布如 下图所示： 钦州路生产中心： 营帐 、计费、网 间结 算 、充 值 、 经 营 分 析 和 OnDemand 横浜路生产中心： 1860客服 系 统 上海移动目前的主要应用系统均运行在 AIX 433和 Oracle 8174下，部分业务 运行在 AIX 5.1/5.2下，但数据库依然为 oracle 8i；存储设备有 IBM ESS 和 7133 也有 EMC存储。部分产品将根据实际情况升级，但不在本方案中具体涉及。 系统 主 机 设备 /地点 存 储 设备 /地点 营帐 S85x2/钦州 ，2004年 4季度将 F20/钦州 ,2004年 4季度 更新为 p5-570x2 将新增一台 ESS800,计 费与营帐的存储 将分 开。 计费 S85x2/钦州 F20/钦州 1860 P650x2/横浜 E20/ 横浜 经营分析 P690x2/钦州 EMC/ 钦州 充值 p630x2/钦州 7133/钦州 采集 H85x1/钦州 F20/ 钦州 网间结算 M80x2/钦州 F20/横浜 下面将会对这些系统的容灾方案进行具体阐述。 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 4.2 容灾架构整体设计 容 灾 系统总体 架 构设计 综合以上要求 ， 我们实际如下的容灾系统整体架构 ， 在这个架构中 ， 对实时 性恢复要求高的核心业务 的数据库 ， 我们考虑了两层容灾设计 。 这里的核心业务 我们认为是营帐数据库 ， 充值数据库和 1860数据库 。 对于计费 ， 经营分析 ， 网 间 结算，批价等，我们考虑存储层的容灾。 由于从实际业务中 ， 以下具体应用模块和数据库是关键性的 ， 所以单独对这 些模块进行进一步说明 。 由于 BOSS 1.5的具体称呼有些变化 ， 但鉴于目前为止改 造项目并没有实施完成 ， 所以 ， 我们主要从数据库和数据一层考虑业务的具体特 性和容灾方式。 营 帐 系统 营帐系统是移动业务中的核心系统 ， 实时性要求高 ， 对于容灾系统的要求也 是最高 ， 所以在此我 们考虑使用数据库备份模式加上存储层数据镜像模式 。 使用 业界成熟流行的数据库实时抽取技术或者 standby database技术 ， 在生产中心随 时保留一个与生产库基本同步的数据库 ， 该数据库是处于 open状态的 。 这样可以 在发生数据库逻辑可以快速接管 。 这种方案的缺点是可能会有一些数据需要在事 后进行补录，但丢失的数据是非常少的。具体容灾架构如下图： 知识水坝（豆丁网 pologoogle）为您倾心整理（下载后双击删除） 百度一下 知识水坝 营帐系统容灾架构图 所有营帐数据库里的数据都会通过存储层的方案镜像到金桥中心。 本 地通过数据抽取另生成一个 active的数据库，与源数据库近乎同步， 一旦需要，可立即将应用切换过来。如果本地有两个物理存储，考虑到 高可用性，可以将抽取出来的数据放到另外一个存储设备上。 目前计划进行营帐系统“瘦身”计划，拟将目前营帐数据库中的历史库 剥离开，营