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

上海移动容灾系统方案设计报告IBM 公司上海分公司Version 5.079 IBM专有信息声明本设计报告属商业机密文件，书中的所有信息均为IBM机密信息，仅供上海移动容灾项目使用。务请妥善保管并且仅在与项目有关人员范围内使用，未经IBM 公司明确做出的书面许可，不得为任何目的、以任何形式或手段（包括电子、机 械、复印、录音或其他形式）对本文档的任何部分进行复制、存储、引入检索系 统或者传播。尽管IBM已经尽力保证本文档内容的完整性和有效性，但仍可能存在某些方 面不够准确的地方或印刷错误。若需求有所变化，IBM将对有关内容进行相对应 的调整，并在本报告的未来版本中体现。IBM是国际商业机器公司的注册商标。本文档提及的其他公司、产品和服务 的名称，可能是其他公司的商标或服务的标志。Copyright IBM China Company LimitedAll rights reserved关于本文档文档信息文档名称上海移动容灾系统方案设计报告作者IBM全球服务部说明本文档是上海移动容灾系统方案设计报告，由IBM公司上海分公司和上海移动容灾系统项目组共同编写。文件名称上海移动容灾系统方案设计报告 v5.0.doc怱订历史 (REVISION HISTORY)RevSectionTypeDateAuthorRemarks1.0AllNew2004-09-13IBMSHMCCteam创 建 方 案 第 一 版本。2.0AllRevised2004-09-22IBMSHMCCteam根据客户反馈怱改而成3.0-3.1AllRevised2004-09-27IBMSHMCCteam根据客户反馈怱改而成，增加存储管 枞 和 灾 难 恢 复 计 划，网络设计考虑多种方案4.0ALLRevised2004-10-08IBMSHMCCteam整枞版本5.0AllRevised2004-10-25IBMSHMCCteam加入摘要，加强存储管枞内容。内容范围本文档是上海移动容灾系统方案设计报告，属于机密文件。 适用的对象本文档适用于参与上海移动容灾项目组的决策者、评估者。目录1摘要72容灾系统建设意义83容灾技术方案选型123.1容灾系统架构方案设计范围123.2容灾技术方案设计方法123.3容灾系统建设目标123.4容灾 7 层技术模型介绍133.5容灾技术方案选型考虑164容灾系统方案设计234.1上海移动系统现状234.2容灾架构整体设计244.3容灾系统详细设计314.3.1本地数据库容灾313.3.2容灾系统主机设计324.3.2容灾系统存储设计463.3.4容灾系统网络设计534.4容灾系统备份方案设计714.4.1数据备份概述714.4.2备份系统现状分析734.4.3容灾备份系统逻辑设计754.4.4容灾备份系统配置设计824.4.5容灾备份系统专业服务844.5容灾系统管理方案设计864.5.1存储资源管理864.5.2存储网络管理915容灾系统实施计划945.1灾难恢复计划945.2上海移动容灾项目实施计划956附录966.1机房工程技术说明966.2上海移动业务支撑系统平台现状概况一览表。1056.3IBM 项目管理服务1076.4支持多厂商的网络存储通用管理软件 SANavigator 版本1146.5容灾系统管理方案设计1216.5.1系统管理现状1216.5.2系统管理需求1226.5.3系统管理架构建议1236.5.4事件管理1266.5.5网络管理1286.5.6数据库管理1296.5.7主机系统监控1316.5.8SLA 管理1336.5.9BOSS 应用管理1346.5.10流程管理1341 摘要一、项目背景随着电信市场的开放以及中国加入 WTO 进程的进行，中国移动通信面临着前 所未有的发展机遇和挑战。作为一个电信运营商，其 IT 系统的应用直接关乎管 理、服务、成本、效率等各个重要环节，并最终全面影响运营商的竞争力。电信 行业是一个讲究系统高可用性的行业，它要求关键应用服务器必须 247 的不间 断运行，以满足超大量用户的实时访问，任何潜在的单点故障都有可能导致整个 系统的瘫痪。为了保证信息系统的稳定和数据的安全，提高业务运营系统的服务 质量，确保在日益激烈的市场竞争中确立主导地位，上海移动决定在现有业务运 营支撑系统的基础上，结合自身的特点和实践经验进行上海移动业务运营支撑容 灾系统工程的建设。本次上海移动业务运营支撑容灾系统工程的目标，是按照移动集团公司 BOSS 系统容灾备份技术规范和业务规范，主要考虑中国移动业务支撑网中的 BOSS 系统，兼顾经营分析系统。对于 BOSS 系统，将主要考虑其中的营帐子系统， 计费子系统，充值子系统，1860 子系统,综合结算中的网间结算子系统。整个容灾系统建设将遵循统一规划，分步实施的原则。二、本设计报告内容结构本容灾设计报告主要分为四大部分：容灾系统建设意义、容灾技术方案选型、 容灾系统方案设计以及容灾系统实施计划。容灾系统建设意义部分主要从行业竞争需要、业务稳定需要和企业管理需要 三方面阐述了容灾系统的建设意义。容灾技术方案选型部分主要根据上海移动 BOSS 系统的现状和将来的发展并 满足对应用和在用系统影响最小以及生产系统变动的需要推荐使用存储层+数据 库层的复合容灾方案。容灾系统方案设计部分主要针对上海移动 BOSS 系统的各个子系统提出了各 自的容灾架构设计，根据各子系统的实时性恢复要求提出对于营帐数据库，充值 数据库和 1860 数据库实施两层容灾设计；对于计费，经营分析，网间结算，批 价等提出存储层的容灾设计。另外还从容灾系统的主机、存储、网络、备份方案 以及存储资源和存储网络管理方案方面作了详细的设计。容灾系统实施计划部分介绍了如何系统的实施灾难恢复计划以保证灾难发 生时业务操作地连续性。2 容灾系统建设意义中国有句古话叫做“天有不测风云，人有旦夕祸福”，充分说明灾难的不可测性。911 事件是对这句话的最好注脚，在里面办公的 286 家公司的 5 万多名员 工是根本不会想到好端端的坐在办公室里居然会有飞机撞过来。在这种近乎毁灭 性的局部灾难面前，是否有异地容灾系统就变成了关乎企业生存的现实问题。最 近国内也发生了类似灾难，大连某个银行的生产中心突然着火，因为没有灾备系 统，造成全部业务停止两天，这还是不幸中的万幸，因为绝大多数机器设备经过 修复还可以使用，尤其是存储设备，否则，后果真是不堪设想。很多企业是从 911 事件后开始真正认真考虑容灾的，以往容灾系统的建设往 往被视为锦上添花的项目而不是一个业务可持续性运行的必须项目。我们可以吸 取的教训是一定要建立核心数据和业务的容灾系统，并且平时要加强管理和演 习，加强人员的培训，核心管理人员和技术的分散，以提高计算机系统因为天灾 或人为因素等意外事故导致系统毁坏无法运行时的抵御能力，至少将局部地区核 心业务支持在系统故障时的损失减至最小。无论是国内还是国外的用户，无论是政府还是企业，现在都在思考这样一个 问题，那就是，假设我们的企业发生了类似的情况，我们是否有足够的备份措施， 企业的数据是否有足够的保障？在美国、日本等一些发达国家，对于关乎国计民 生的行业，有专门的法律要求该企业必须有灾难保护方案，（如美国是 BCC 177） 并且每年都会进行审计和稽核。国内因为目前还没有类似的法律约束，很多企业 对于应用比较重视，但是对于整体系统的可用性考虑得不多，甚至是一些金融企 业，当有类似数据库出错等故障发生时，还依然只能通过倒磁带的方式恢复数据。 这种情况下，丢失数据就是不可避免的了，并且由于恢复时间的漫长，对广大客 户承诺的服务水平又如何能够达到？现在，随着中国加入 WTO，一些国内先进的 有前瞻性的企业也在这方面给予了足够的重视，如上海移动等单位。随着上海移动业务的飞速发展，业务对 IT 系统的依赖性也随之增加，越来 越多的业务集中到生产主机上，对主机和存储设备都造成了较大的压力。当一个 单位越来越依赖于数据处理去进行它的业务行为时，数据处理的高可靠性和高可 用性就尤为关键，大部分单位的业务处理需要数据处理的高可用性。用户发现如 果没有了数据处理，业务的开展变得极端困难，也许手工操作还可以使用，但那 只能用于短期的应付，一个计算机系统的长期停止运转将直接导致明显的业务后 果，也许还会被追究管理责任。更为重要的是，一旦数据由于某种原因永久性丢 失，不但会给企业的运作带来极大的困难，企业的商业信誉必将受到致命的打击， 在竞争中处于劣势，造成不可估量的后果。基于这种考虑，中国移动总部提出了在各省建设 BOSS 系统容灾备份的要求， 这个报告书就是为上海移动的容灾系统进行方案设计。本方案中将重点讨论 BOSS 系统的详细容灾方案，兼顾其他业务系统，同时根据上海移动的实际情况分步实现。当然，我们考虑容灾系统建设时，也应该实事求是，从实际出发。能够防御 所有灾难的方案是不存在的，也是不现实的。我们认为，计算机系统的灾难定义 是可以由用户自己来定义的，各个行业可以有不同的要求。设计容灾系统时，应 该基于一个合理的前提假设，譬如，在主机房发生故障时，备份机房可以保证数 据的完整性，并且可以在最短时间内完成应用、网络和数据的接管。本方案中的 容灾系统正是基于这种前提来设计，我们暂不考虑那种同时损坏主备机房的可能 性。让我们再来看看容灾系统建设的意义，这个在移动总部的容灾系统建设规范 中也有多次强调：行业竞争的需要美国明尼苏达大学研究机构的统计结果表明，对于银行，金融，证券，电信等行业的企业而言，如果业务停顿时间长达两天或更长，那么 25% 的企业将立 刻因信誉和业务问题而倒闭，40% 的企业将因为受不断的后续因素的影响导致综 合竞争力的下降而在今后两至五年内被淘汰，五年以后仅有 7% 的企业能够继续 在此行业内生存。目前，在国内，通讯行业内的竞争本来就很激烈，加之 WTO 之后，国外实力 雄厚的企业对国内市场的窥视，将不可避免地造成企业争夺客户群的白热化的局 面，因此企业总体服务的水平将是影响竞争结果的重要因素。试想，一个时不时 就会抱歉地对客户说：“对不起，由于我们的主机系统有问题，您要求的业务暂 时无法办理”的企业将无法赢得挑剔的客户的芳心。即使在发生众所周知的 灾害，如果系统也是长时间的无法恢复，也会带来极严重的后果。所以，IT 系 统的完善程度是激烈竞争的一个最重要的前提，在此基础上，企业才能开发丰富 多样的业务品种，提供高质量的服务水平，在竞争中取得优势。不久前发生在南 京的“爱立信跳槽事件”已经表明了中国加入 WTO 后行业竞争的残酷性和现实性。 根据业务的不同，对各种程度的中心系统可靠性要求也不同，如从最高等级 的XX服务，到在指定时间内恢复。为了满足这些要求，更好地为客 户服务，上海移动应当未雨绸缪，尽早制定和建立完备的灾难恢复计划系统，以增强系统的抗灾能力，最大限度地减小损失。业务稳定的需要时至今日，企业业务运营对信息系统的运作的依赖性越大，就对信息系统运作的稳定性和可靠性的要求越高。 而信息系统可用的定义已不再局限于主机设备的可用，而是从主机，存储，用户终端，网络设备整体的物理可用，到系统，数据库，应用软件，用户数据的 逻辑可用。然而，由于各种因素的影响，小至一般性的硬件故障，大到区域性的自然灾 害，从物理的设备不可用，到逻辑的人为失误和破坏，都可能造成整个信息系统 的全面瘫痪，从而导致业务运营的停顿。因此，同一机房中的双主机恢复系统有 很多企业已经觉得不能满足需求，特别是因为应用的要求而作了区域集中或全国大集中的企业，在享受数据集中带来的诸多好处时，同时也承担着数据丢失或者IT 系统不可用带来的巨大风险。从以下这份国外的研究报告中我们可以知道这 些担忧不是杞人忧天。这是 1996 年 Source ContingencyPlanning Research Inc。 对于各种因素包括自然灾害：水灾、风灾、地震、大雪、野火 结构破坏：电力中断、火灾、爆炸 操作问题：硬件问题、病毒入侵、操作失误、人为破坏。让我们暂时抛开满脑子的灾难，来考虑一下即使是机器没有发生故障是否也是 7小时可用呢？我们认为，现实环境中，这种情况也是不现实的，我们 经常会进行一些正常的日常维护活动。假设我们认为，所有灾难都是属于非计划 中的系统不可用，那么还有很大一部分系统不可用时间是属于计划中的，从下图 中我们可以看到非计划宕机只是占了 IT 系统不可用的 10%，而计划中的宕机占了 90%。 如果我们有了容灾系统，起码我们可以将很多计划中的停机事件避免，如数据备份，完全可以在容灾中心进行，同时，我们可以利用容灾中心做许多诸如新 的应用程序测试，压力测试等等，若是结合第二份数据镜像功能，我们完全可以 轻松自如的在容灾中心进行数据查询，数据挖掘等业务。当然，这些业务在只有 一份远程镜像时也可以实现，只是需要较为仔细和复杂的操作，并且有可能暂时 中断镜像等，相比之下没有前者操作方便简单，对生产系统的冲突更小。Definition of OutagesMost Customer Outages are caused byData Base Backup andChange ControlPlannedOutages90.0%UnplannedOutages10.0%DBBackup52.0%Operations25.0%Software30.0%Other9.0%Application8.0%Hardware8.0%Software13.0%Network10.0%Hardware15.0%Other3.0%Application27.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/NNYYYYYYY容灾层次01234567保存的信息 (数据，指令，文档)NY/NYYYYYYDetermination of requirementsNYYYYYYY专用的容灾硬件和机房NY/NYYYYYY灾难恢复计划NNYYYYYY选择性的异地数据保存NNYYYYYY支持危机时候的足够的硬件和网络设备NNYYYYYY至少部分信息的电子方式的备份NNNYYYYYActive management of recovery data by aprocessor at the recovery siteNNNNYYYY双向恢复NNNNYYYY物理分离NNNNYYYY所选数据的镜像NNNNNYYY异地部分或全部的硬件备份NNNNNYYY主备中心数据即时异地传输NNNNNNYY根据策略自动切换到灾备中心NNNNNNNY典型恢复时间UptoNever 1week 1day1 day 1day 12hours 6hoursFewMins.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 Automatictakeover）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 为最低。容灾技术技术成熟 度数据丢失情况硬件要求实施难易程度对在用系统影响推荐程度（15）存储服务器层（ tier 6）成熟不丢或少量同一品牌存储较易较少4SAN 层(tier 6)成熟不丢或少量FC 连接较易较少3操作系统层(tier 6 or 7)成熟不丢或少量同一品牌主机较易较大3数据库层(tire4 or 5)成熟部分丢失较易较大3.5由表中可以看出，对于建议采用复合方式的应用来说，我们推荐使用数据库层和存储层结合的复合方案。存储层可以在存储产品层，也可以在 SAN 交换机层。手动/自动启动容灾 我们知道，自动容灾技术可以自动识别灾难的发生并且自动启动恢复程序，将应用在容灾中心自动重启。可是结合国内实情，自动容灾方式并不是很适合上 海移动，因为是否启动容灾系统不仅仅是一个技术问题，其中有一个决策过程， 还有一个切换的程度的问题。采用手动切换，可以将主动权握在手里。传统磁盘远程镜像的基本概念 传统基于磁盘的镜像方式是由存储设备控制通过数据通道，以逻辑卷为基本单位，将本地磁盘阵列上的数据镜像到远端的同构磁盘阵列上比如 IBM的 PPRC 和 EMC 的 SRDF。基于磁盘的镜像功能传统上提供 2 种工作方式，同步（左图）和异步方式（右图）：在同步方式下，磁盘镜像功能只有在本地和远程磁盘都完成写操作后才会向 主机发回“IO 完成”消息，以确保源卷和目的卷的数据彻底一致。好处是：可以保证数据不会丢失可以保证数据的一致性 缺点是：对网络和距离要求很高：需要高带宽和距离一般不能超越城域对生产系统的性能影响也比较大在异步工作方式下，磁盘镜像功能能够在远端更新未完成的情况下，只要本地更新成功就可以向主机返回“写成功”信号。好处是：对网络和距离的要求非常低对性能的影响非常小坏处是：数据一般情况下会丢失普通异步方式无法保证 IO 的次序，所以在进行异步操作时，远程镜 像卷始终处于异步造成的“不一致”状态，直到所有数据“全部传递 完毕”。如果应用是 7*24 小时不间断的，就无法达到数据“全部传 递完毕”状态。所以，异步备份一般只用于数据移植，或者和磁盘本 地镜像结合，用于传递相对静止的数据保证数据一致性的异步远程镜像 为了同时利用同步的数据一致性优势和异步的性能/距离优势，各个存储厂商都推出了一些能够保证数据一致性的异步远程镜像方式，主要是 IBM 的 PPRCGM 和 EMC 的 SRDF/A。为了 100%的保证数据一致性和可用性，所有类似的技术都必须采用 3 份数 据的方式进行操作（本地 1 份，远程 2 份）。IBM PPRC GM 的工作方式如下：工作方式如下（其中绿色为生产站点磁盘，橙色和蓝色为容灾站点磁盘）：1. 绿色和橙色磁盘之间进行 PPRC-XD 异步操作2. 绿色磁盘组根据预先设置的时间，生成“一致性组”（ConsistencyGroup），并记录状态3. 采用 PPRC-XD 异步操作方式，将且只将“一致性组”记录下来的数据 传递从绿色磁盘组传递到橙色磁盘组4. 3 完成后，立刻将橙色磁盘组数据 FlashCopy 到蓝色磁盘组，进行一 致性数据保留5. 4 完成后，回到步骤 1由于有“一致性组”的保护，虽然采用异步方式，一旦每一个“一致性组” 数据包传递成功的那一时刻，橙色磁盘组的数据是一致的；由于步骤 4，蓝色磁 盘组将能够保留最近一次“一致性完全”的数据。一旦出现灾难，客户丢失的是 两次生成“一致性组”间隔之间的数据。如果网络发生故障，PPRC GM 会等待网络恢复，重新生成“一致性组”（对 于经历的较长时间网络故障的系统而言，只是新的“一致性组”中的数据会比较 大而已），继续进行 PPRC GM 的正常操作。PPRC GM 能够每 35 秒生成一次“一致性组”，意味着客户即使采用异步方 式，也有可能只丢失 35 秒的数据。EMC SRDF/A 的工作方式如下：SRDF/A 使用“增量集”来短期维护一组写入操作。增量集是 SRDF/A 所提供的所有功能的基础。SRDF/A 使用四种类型的增量集来管理数据流处理过程。SRDF/A 的数据 流可归结为几个步骤:源位置的增量集：捕获 - 在缓存中捕获所有传入到 SRDF/A 组所涉及的源卷的写入 操作。完成此“捕获增量集”后，该集合中的写入操作将被“折 叠”，并升级为“传输增量集”，同时开始传输其中的内容。（然 后另外创建一个新的捕获增量集，来维护下一个写入操作增量 集。）传输 - 将内容从源系统传输到目标系统，仅传输最近的写入操作 集。目标位置的增量集：接收 - 接收增量集位于目标系统上，用于接收由源位置的传输增 量集传来的数据。接收到全部数据后，它将升级为应用增量集。 应用 - 将增量集中的写入操作应用到目标卷，以创建一致的可重新 启动的远程拷贝。这就完成了增量集循环。如果网络发生故障，由于 SRDF/A 使用“增量集”存在于磁盘系统的高速缓存 中，一定时间的故障会造成高速缓存溢出，此时必须中断 SRDF/A，等待网络恢 复。从网络故障到恢复之间的数据只能够采用传统的 SRDF 异步方式传递，为了 防止异步传递被异常中断而造成对远程数据库的破坏，在传递数据之前必须采用 TimeFinder 保护一下远程的数据，然后才能够继续操作。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/钦州1860P650x2/横浜E20/横浜 经营分析P690x2/钦州EMC/钦州 充值p630x2/钦州7133/钦州 采集H85x1/钦州F20/钦州 网间结算M80x2/钦州F20/横浜下面将会对这些系统的容灾方案进行具体阐述。4.2容灾架构整体设计容灾系统总体架构设计综合以上要求，我们实际如下的容灾系统整体架构，在这个架构中，对实时 性恢复要求高的核心业务的数据库，我们考虑了两层容灾设计。这里的核心业务 我们认为是营帐数据库，充值数据库和1860数据库。对于计费，经营分析，网间 结算，批价等，我们考虑存储层的容灾。由于从实际业务中，以下具体应用模块和数据库是关键性的，所以单独对这 些模块进行进一步说明。由于BOSS 1.5的具体称呼有些变化，但鉴于目前为止改 造项目并没有实施完成，所以，我们主要从数据库和数据一层考虑业务的具体特 性和容灾方式。营帐系统营帐系统是移动业务中的核心系统，实时性要求高，对于容灾系统的要求也 是最高，所以在此我们考虑使用数据库备份模式加上存储层数据镜像模式。使用 业界成熟流行的数据库实时抽取技术或者standby database技术，在生产中心随 时保留一个与生产库基本同步的数据库，该数据库是处于open状态的。这样可以 在发生数据库逻辑可以快速接管。这种方案的缺点是可能会有一些数据需要在事 后进行补录，但丢失的数据是非常少的。具体容灾架构如下图：营帐系统容灾架构图所有营帐数据库里的数据都会通过存储层的方案镜像到金桥中心。本地通过数据抽取另生成一个active的数据库，与源数据库近乎同步， 一旦需要，可立即将应用切换过来。如果本地有两个物理存储，考虑到 高可用性，可以将抽取出来的数据放到另外一个存储设备上。目前计划进行营帐系统“瘦身”计划，拟将目前营帐数据库中的历史库 剥离开，营帐库中仅仅保留核心数据，这样更加适合采用复合方式。如果碰到非数据库逻辑错，本地接管不能恢复，那么就尽快启动金桥中 心的备份。客服1860系统1860系统对于移动维系和提高客户关系和客户满意度有着极其重要的意义， 同时1860系统也是一个实时联机交易系统。目前有计划将C/S结构逐步改造成为 W/S结构，这样本次备份中仅仅考虑数据库服务器。应用服务器可以不必考虑专 用的备份。1860容灾系统架构如下图所示：1860容灾系统架构图所有1860数据库里的数据都会通过存储层的方案镜像到金桥中心。本地通过数据抽取另生成一个active的数据库，与源数据库近乎同步， 一旦需要，可立即将应用切换过来。如果碰到非数据库逻辑错，本地接管不能恢复，那么就尽快启动金桥中 心的备份。不必考虑专用的应用服务器，可以共享。计费系统 计费业务处理属于BOSS后台处理，其业务中断对客户业务受理不产生直接影响，但是，计费业务的中断将间接影响漫游用户处理、帐务处理、交费、用户查询等业务功能，这将会一定程度上影响客户满意度，并导致基于BOSS的预付费业 务产生透支及坏帐，所以一旦计费业务故障发生，也必须在最短时间内恢复。计 费业务的数据主要分为数据库里的数据和文件系统中的原始话单。两部分数据可 以统一用存储层的技术解决，但是较好的办法是：数据库里的数据用存储技术实 现，文件系统的话单可以由应用程序增加分发路径，多放一份拷贝即可。计费系 统由于数据库庞大，同时实时性没有联机交易系统要求高，所以不考虑standby 数据库的方式。计费系统容灾架构如图所示：计费容灾系统架构图数据库里的数据通过存储技术镜像到金桥中心。文件系统的话单通过增加分发路径传输到金桥中心，需要单独专用 的空间存放。目前生产中心是使用三台M80作为批价服务器，金桥中心可以考虑使 用较高端的机器，同时减少机器的数目。充值系统 目前充值系统依然使用7133存储而不是带高级复制功能的只能存储，是用两台p650机器为数据库服务器，两台服务器互为备份。我们建议首先将数据整合到智能存储上，这样就可以统一考虑容灾方案。同时由于充 值系统是实时性很强的系统，可以考虑使用本地standby数据库。建议的 容灾示意图如下：充值容灾系统架构图7133上的数据首先移植到智能高端存储上。然后通过存储层技术将数据镜像到金桥容灾中心。本地通过数据抽取生存active的备份库，随时在数据库逻辑故障发 生时接管。如果本地接管不能胜任，则启动金桥容灾中心的备份系统。采集分发系统 目前采集分发系统依然使用7133存储而不是带高级复制功能的智能存储，是用一台sp宽节点为服务器，数据量为100GB到200GB，我们建议首先将数据整合到智能存储上，这样就可以统一考虑容灾方案。容灾架构 示意图如下：采集子系统容灾架构图7133上的数据首先移植到智能高端存储上。然后通过存储层技术将数据镜像到金桥容灾中心。如果本地接管不能胜任，则启动金桥容灾中心的备份系统。网间结算 结算业务处理属于后台处理，对客户的业务受理不产生直接影响，业务连续性要求相对较低，但如同计费处理一样，结算业务的中断会影响漫游结算，和网 间结算的报表的生成，这会影响与国际运营商、其他运营商的合作关系。对于网 间结算来说，重要的是保证数据在容灾中心由备份。容灾架构示意图如下：网间结算容灾系统架构图网间结算的数据通过存储技术镜像到金桥中心。不必在容灾中心放专用的应用服务器。经营分析 经营分析类数据属于BOSS后台处理，但是，经营分析的中断也会影响一些分析、决策的功能，尤其是营收类的统计会直接影前台的管理和业务支持，因此，对大部分的统计分析功能来说，应该具有7x 8的系统处理 支持能力，其中最重要的无外乎数据库和数据库服务器。容灾架构示意 图如下：经营分析容灾系统架构图4.3容灾系统详细设计4.3.1本地数据库容灾BOSS 系统支撑市场营销、客户服务等前台业务流程以及计费、结算、帐务、 服务开通等后台业务流程，BOSS1.0 和 1.5 中对应用子系统的称法有所不同，由 于其核心数据层采用 Oracle 数据库，所以我们依然以数据库存储数据的类型来 称呼，相对来说比较容易理解。因为这些数据库存储了上海移动的核心数据，因 此对于 Oracle 数据库的备份和保护是最重要的。基于上海移动容灾系统的业务 需求，为了保证生产中心的 Oracle 数据库可用性最大化，能够进行快速接管， 保证一定的统计和报表等业务的进行，保证 Oracle 数据库的数据完整性和一致 性，我们建议实时性要求高的应用采用数据库层面的技术来保证数据库的容灾， 作为存储容灾的有效补充。而由于经营分析系统提取 BOSS 和其它系统的相关数 据，建立统一的数据信息平台，并采用数据仓库技术和分析挖掘工具，为客户服 务、市场营销、经营决策等工作提供有效支撑。所以相对来说对于数据库的实时 可用性没那么高，所以只使用存储层的技术已可满足容灾需求。对于相同数据集合的不同应用，如 OLTP 操作和分析查询操作，可以根据业 务系统的特点分布到主中心和灾备中心的数据库中。这样可以减少对主系统的压力，提高系统性能并减少系统出现故障的几率。4.3.2容灾系统主机设计基于上海移动电信业务支撑系统的现状和发展要求，通过处理能力的需求分 析，设计容灾系统的主机平台技术方案。4.3.2.1系统现状分析和需求分析模型（1） 上海移动电信业务的现状及发展预测下表列出了上海移动 2004 年用户分布情况及 2006 年的用户数预测。用户种类用户类型2004 年用户数（万）2006 年用户数（万）增长率基 础 业 务 （ 语音）用户全球通用户742248313112%神州行用户147941656912%小计8901899712%增 值 业 务用户