某移动BOSS容灾系统建设方案.doc

XX移动BOSS容灾系统建设方案XX移动BOSS容灾系统建设方案XX移动通信有限责任公司发展计划部 帐务中心2003年5月目录1.必要性32.XX移动BOSS系统现状33.容灾设计综述63.1.容灾系统设计影响因素63.1.1.应对灾难的种类63.1.2.恢复时间目标（Recovery Time Objective）73.1.3.恢复数据目标（Recovery Point Objective）73.2.数据复制技术73.2.1.基于存储的复制技术83.2.2.基于数据库的复制技术103.2.3.基于应用的复制技术124.XX移动BOSS容灾系统建设目标及原则135.XX移动BOSS容灾系统建设规模及需求136.XX移动BOSS容灾系统建设方案156.1.系统结构156.2.数据复制技术选择176.2.1.营帐系统176.2.2.计费系统186.2.3.8地市BGW及采集预处理系统196.2.4.结算系统196.2.4 统计系统206.2.5.客服系统206.2.6.网络216.3.系统监控与切换控制216.4.演习226.5.系统处理能力及存贮容量计算226.6.系统集成307.容灾节点配置方案308投资估算319工程进度321. 必要性甚至仅仅在几年以前，我们都无法想象信息数据会在一个企业运营中占据如此重要的地位。现在可以毫不夸张地说，一个企业若部分或完全丢失数据，也就丢失了一切。中国有句古话叫做“天有不测风云，人有旦夕祸福”，说明灾难的不可测性。911事件是对这句话的最好注解。从911事件中我们可以吸取的教训是一定要建立核心数据和业务的容灾系统，并且平时要加强管理和演习，加强人员的培训，核心管理技术的分散，以提高计算机系统因为天灾或人为因素等意外事故导致系统毁坏无法运行时的抵御能力，至少将省内或者局部地区核心业务支持系统故障时损失减至最小。我公司已于2000年完成了BOSS系统的集中建设，所有关键业务数据和应用系统都全部集中到了一个生产中心，实现了全省业务数据的共享，方便了业务的统一支持及管理，提高了系统对业务灵活的应变及快速响应的能力。但由于集中的系统中数据量巨大，对主机和存储设备都造成了较大的压力，同时系统的集中带来了风险的集中，一旦庞大的系统发生意外，企业的商业信誉及利益必将受到重大的打击，在竞争中处于劣势，造成不可估量的后果。集团公司在企业信息化建设的整体规划中，一方面推进支撑系统集中化的建设，同时也提出了BOSS容灾系统的建设的指导意见，并选择我公司进行BOSS容灾系统建设试点。根据我公司BOSS系统实际情况及集团意见，我公司有必要进行BOSS容灾系统的建设。2. XX移动BOSS系统现状我公司BOSS系统包括计费、营帐、采集、结算统计、查询、客服、IP计费、经营分析等系统。各市公司通过MDCN与省中心连接。（1）计费结算及营帐系统：系统集中设置，生产中心设计满足XX万用户要求。计费结算系统负责完成省内所有话单集中计费分拣、漫游及网间话费结算，并负责监控和管理全省各计费中心的网络、主机、数据库和应用系统的运行状态、性能、故障等等；营业帐务系统负责完成营业前台受理、帐务处理、业务管理、缴费、查询和客户服务等功能。系统分别与交换机HLR系统、银行连接。目前存在两套系统：生产系统设在XX大楼一层，系统容量满足XX万用户要求。系统配置如下：设备用途设备型号应用软件存储运行数据TPCC值(单位：tpmc)计费服务器Sun E10000CPU 48*400Mhz，Memory 16G, Disk 6*18GOracle 8.1.60.8TSY、DL110,000计费服务器Sun E10000CPU 32*400Mhz，Memory 12G, Disk 6*18GOracle 8.1.60.8T除SY、DL外其它地市90,000结算服务器Sun E10000CPU 48*400Mhz，Memory 16G, Disk 6*18GOracle 8.1.61.2T全省、智能网、短信、梦网、GPRS110,000统计服务器Sun E10000CPU 48*400Mhz，Memory 16G, Disk 6*18GOracle 8.1.65T全省统计、详单查询110,000营帐服务器Sun E10000CPU 32*400Mhz，Memory 10G, Disk 8*18GOracle 8.1.61TSY、BX、FS、JZ、PJ、YK110,000营帐服务器Sun E10000CPU 32*400Mhz，Memory 10G, Disk 8*18GOracle 8.1.6IBM MQ 5.21TDL、TL、LY、AS、CY、FX、HL、DD110,000采集预处理服务器Sun E6500CPU 16*400Mhz,Memory 8G, Disk 2*18G0.8T全省33,000营业应用服务器Sun E6500CPU 16*400Mhz,Memory 8G,Disk 2*18GIBM CICS 4.3SY、BX、FS、JZ、PJ、YK33,000营业应用服务器Sun E6500CPU 16*400Mhz, Memory 8G,Disk 2*18GIBM CICS 4.3DL、TL、LY、AS、CY、FX、HL、DD33,000BOSS磁盘阵列EMC Symmtrix 873016光纤通道234 * 73GB 硬盘计费、统计、营帐17T10TBOSS磁盘阵列EMC Symmtrix 873016光纤通道234 * 73GB 硬盘计费、统计、结算、采集17T10T备份系统设在XX机房，系统原设计容量满足XX万用户要求。系统原配置3台SUN E10K主机，现已将2台用于经营分析系统。现有系统配置为：计费主机：SUN E10K32300MHz 8G RAM(60000tpmc) 1台计费磁盘阵列：SUN A5000 (每台1.2T) 6台计费预处理： SUN E3500 2台工单机：SUN E5000 2台漫游结算备份：SUN E6000+5000 2台2000年前用户数据备份：SUN E6000+5000 2台银行接口、充值卡接口、Oracle备份：E3000 3台全省业务支持及计费均在生产系统上处理，与HLR工单处理及与银行的接口通过设在XX机房的工单及接口设备完成。（2）话单采集：各市交换机计费数据的采集采用爱立信公司的Billing Gateway软件，运行于SUN的服务器上。其中沈、大、鞍、抚、营、丹分别设置了采集服务器，其余八个市的计费数据由设置在省计费中心的2台E3000采集服务器集中采集。（3）客服系统：客服系统采用集中建设方式，在省会设置两个呼叫中心，一个数据中心，系统设计容量满足734万用户要求。排队机系统由AVAYA公司提供，分别设置在XX机房及汽贸机房。数据中心设在XX机房，系统配置如下：数据库服务器：2台IBM M660（8CPU700MHz,8G内存）中间件服务器：2台IBM M80（6CPU500MHz，6G内存）磁盘阵列：2台IBM DL7300（2000G）WEB服务器：1台SUN E3500（2300M CPU ,1GB内存）系统分别与计费营帐系统、互联网、网管系统、短信系统存在接口。（4）经营分析系统：利用原XX系统中SUN E10K设备。系统刚开始建设，机房设在XX新机房四楼。系统配置如下：数据库服务器： SUN-E10K 64*464Mhz CPU、48Gmem，两块千兆以太网卡，其处理能力在15万TPCC以上。OLAP/数据挖掘服务器：64*464Mhz/64Gmem，并划分为两个域，每个域容量为32*464Mhz/2Gmem，应用模式为负荷分担，同时兼顾备份模式。（6）MDCN：以省帐务中心为中心与各市形成星形网络。省中心现设置两个结点，XX及XX，各市分别设置一个结点，各结点均采用CISCO路由器。MDCN网承载BOSS、网管、OA/MIS等网络，各系统间相互隔离。各市至省中心现有3条E1电路。网络设计采用155M传输，目前正在实施中。3. 容灾设计综述3.1. 容灾系统设计影响因素我们在规划灾难恢复方案时，首先应根据具体业务要求明确灾难恢复方案所要达到的目标。因为不同的灾难恢复目标，会有不同的灾难恢复技术实现方案，以及炯然不同的投资规模和运行成本。3.1.1. 应对灾难的种类有许多计算机系统内部以及计算机所处环境中的潜在因素可能会造成数据丢失情况的发生。据不完全统计，造成数据丢失的事件中， 软硬件和网络故障占11左右， 断电和电源故障占50左右， 火灾地震爆炸和雷电等灾害占18左右， 人为因素占17左右， 其他因素占4左右。3.1.2. 恢复时间目标（Recovery Time Objective）恢复时间目标（Recovery Time Objective- RTO）是灾难发生后业务能够容忍的停顿时间；或者说灾难发生后，恢复业务运行所需要的时间。一般来说，恢复时间（RTO）越短，那么灾难恢复方案的成本就越高，但是由于灾难造成的业务损失就越小；反之，恢复时间（RTO）越长，灾难恢复方案的成本较低，但是由于灾难造成的业务损失就较大；最佳的恢复时间目标（RTO）应为业务影响（损失）曲线和方案成本曲线的交点所对应的时间。比最佳恢复时间更短的目标，将造成投资浪费；而比最佳恢复时间更长的目标，灾难发生造成的损失会大于方案投资成本，所以灾难损失的风险较大。3.1.3. 恢复数据目标（Recovery Point Objective）恢复数据目标（Recovery Point Objective- RPO）是灾难发生后业务能够容忍的数据丢失量；或者说灾难发生造成的数据丢失量。一般来说，恢复数据目标（RPO）越高（即，丢失的数据越少），方案的成本越高，但是由于灾难造成的业务损失就越小；反之，恢复数据目标（RPO）越低（即，丢失的数据较多），方案的成本较低，但灾难造成的业务损失也较大。最佳的恢复数据目标（RPO）应为业务影响（损失）曲线和方案成本曲线的交点所对应的目标。比最佳恢复数据目标更高的目标，将造成投资浪费；而比最佳恢复数据目标更低的目标，灾难发生造成的损失会大于方案投资成本，所以灾难损失的风险较大。3.2. 数据复制技术容灾的主要技术难点在数据复制实现，就是说如何保持主备节点的数据同步，包括应用软件、数据库、业务数据等方面。从一个应用系统的构建基础看有以下及各层次，数据在不同层次上均有相应复制技术实现。3.2.1. 基于存储的复制技术3.2.1.1. 连接方式一个典型的存储方案可以总结为以下结构：数据复制可以通过网络连接、存储交换机连接、磁盘阵列连接三种方式实现备份。支持磁盘阵列连接复制的磁盘阵列主要有IBM Shark系列、EMC Symmtrix 8000系列、Hitachi 9900（HP XP512/Sun StorEdge9900）系列。连接主要以直接光纤连接或走SDH网络。直接光纤连接距离大约支持30KM。支持存储交换机连接复制的交换机主要有McData、Brocade的交换机系列。连接方式与盘阵连接类似。支持网络连接存储复制的主要是软件，例如：IBM Geographic Remote Mirror (GeoRM)、 Veritas Volume Replication Server。传输协议采用TCP/IP，传输距离没有限制，但一般需要100M以上网络连接。3.2.1.2. 复制模式基于存储的复制技术均支持同步复制与异步复制。l 同步复制流程1. 工作主机向主工作盘阵发出 I/O 写请求，主盘阵将更改的数据记入 cache 当中。2. 主工作盘阵通过光纤向备份盘阵发出 I/O 写请求操作。3. 备份盘阵做完记录更改后，向主盘阵发送写操作结束指示。4. 主盘阵收到备份盘阵发回的写结束响应后，向主机发送写操作结束的响应。5. 至此写操作完成。l 异步复制流程1. 工作主机向主工作盘阵发出 I/O 写请求，主盘阵将更改的数据记入 cache 当中。2. 主工作盘阵向主机返回写操作完成指示。3. 主工作盘阵采用某种机制，缓存未被复制到远端的写操作数据。4. 主工作盘阵在后台，异步地通过网络向备份盘阵发出 I/O 写复制请求。5. 备份盘阵做完记录更改后，向主盘阵发送写操作结束请求。6. 至此复制备份操作完成。3.2.1.3. 基于存储的复制技术特点1. 数据复制在系统底层逻辑结构上完成，与应用无关，对上层应用透明。2. 数据复制在底层实现，一旦实施完成后维护工作相对简单。3. 使用光纤连接或1G以上网络条件下，短距离复制速度快。4. 同步存储复制模式时由于需要在两个存储设备上操作，对应用系统有一定影响，尤其是在传输网络不稳定时。5. 异步存储复制模式下，虽然对应用系统没有什么影响，但由于是异步复制，发生灾难时，异地备份磁盘上的数据较生产盘，可能存在差异，需要通过其他方式进行弥补。6. 生产系统和后备系统必须采用相同厂商的存储器，以保证数据复制软件兼容。3.2.2. 基于数据库的复制技术基于数据库的数据复制技术主要关系型数据库均支持，如：Oracle、Sybase。数据库复制可以分有两个级别，全库复制，表级复制。下面以Oracle数据库为例介绍，全库复制和表级复制。3.2.2.1. 全库复制Oracle的全库复制主要是利用ORACLE数据库的STANDBY DB技术实现。STANDBY DB实质上就是一个主系统数据库在发生灾害时候的一个拷贝，它实现的原理是利用了ORACLE数据库的归档日志文件，将归档日志文件通过文件传输系统发送到被系统，进行对数据库的恢复过程。l 数据流程l Standby DB复制技术主要特点是：1. 备份数据库是由主数据库的日志恢复的，所以可以保障数据的可用性。2. 不影响主数据库性能，STANDBY DB不会影响主数据库的任何操作。3. 由于恢复过程中备数据库处于mount状态，所以备数据库的数据在复制过程中不能被访问。4. 由于备份数据库的数据是由主数据库的归当日志恢复的，所以备数据库的数据比主数据库要少一些，主数据库失效后会损失一部分数据，损失的数据量取决于日志文件的大小。5. 由于主数据库要处于日志归档模式，会影响一定的主数据库性能。3.2.2.2. 表级复制Oracle数据库也提供一种基于表的复制方式，复制流程是：1. 在主备数据库上安装Oracle Replication Option，在系统缺省安装时并不安装此部分。2. 启动相关复制进程。3. 指定要复制的表，系统会对要复制的表作好触发器(trigger)。4. 应用程序在对表进行修改时，会触发相关程序，把对表的操作命令写入复制队列。5. 复制进程把命令复制到备数据库上，并在复制系统上执行，修改相应表。表级数据复制模式也分同步复制和异步复制，这种复制的优点是，复制原理简单，数据量少时速度快，不需要额外投资；但维护工作相对复杂，对生产系统I/O资源占用较大，对大数据量不适合。3.2.3. 基于应用的复制技术基于应用的复制就是在整个系统的最上层是进行数据复制，应用系统在操作数据时在主备系统上同时进行，或应用系统把所有业务数据操作写入日志，复制到备份系统，再由备份系统重作一遍。基于应用的数据复制技术特点：基于应用的数据复制是由应用系统控制的，所以应用对流程的控制力度较强，灵活性大；但基于应用系统的复制对应用系统开发要求较高，增加了应用的复杂程度，应用级数据同步方式加大维护技术难度，系统鲁棒性差。数据同步及时性管理范围数据在平时是否可用主机负荷成本实施难易程度可维护性同构程度磁盘同步复制完全实时同步阵列内部数据不无较高易易完全磁盘异步复制异步同步前数据（半小时1小时)阵列内部数据可用无较高易易完全操作系统复制异步同步前数据（一天)全部数据不10%较高易难数据库，应用，主机数据库同步异步同步（510分钟）数据库数据不无较低易难数据库，应用，主机数据库表复制实时同步数据库内部部分表可用10%较低难难数据库，应用应用数据同步实时同步全部数据可用高较高难难数据库，应用几种同步机制对比表4. XX移动BOSS容灾系统建设目标及原则BOSS容灾不仅仅是建设一套备用系统，而是建立起一种预防性机制。它明确了BOSS系统的关键职能以及可能存在的威胁，并据此采取相应的技术手段，制定计划和流程，确保系统能在任何环境下都能持续发挥作用，即：从计划外停机中实现灾难恢复、在计划停机期间保持连续可用、利用冗余资源提供增值服务。BOSS容灾系统的总体建设目标是：v 针对目前系统潜在的中断风险，提供预防机制，提高系统连续运行能力v 对无法抗拒的严重灾难，提供系统恢复机制，将引发的业务损失降低到可接受的程度具体到本期项目规划和建设的目标是：v 实现关键业务系统及其关联系统的数据安全v 减少计划停机次数/时间，消除对核心数据的争用v 将异地中心接管业务的时间控制在可以接受的范围内v 实现异地中心的软硬件设备和数据的复用系统规划和建设中须遵循以下技术原则：1. 实用性与成熟性使用业界成熟、可靠和实用的业务连续性技术。2. 先进性系统结构能够满足和适应中国移动IT系统快速变化和发展的要求。3. 开放性与标准化采用开放的技术标准和协议支持整个系统的运行，兼容性和恢复性强。4. 自动化和操作的简单化系统各部分有机集成，集中控制。5. XX移动BOSS容灾系统建设规模及需求系统建设应满足2005年中期900万用户要求（根据20032005年发展规划及我公司用户发展现状预测），并能够平滑扩容至1000万用户的处理容量。完善应用系统，使之具备数据及应用同步、系统监控、系统切换及恢复功能，从而实现应用完整性目标。两套系统均可承担生产中心的工作。我公司BOSS系统主要面临的风险有：计划内：1 应用软件等的升级2 备份/恢复/归档3 数据中心迁移、整合4 测试计划外：1. 系统软件缺陷，造成系统逻辑故障；2. 人为操作或应用软件缺陷造成数据逻辑错误，造成不可恢复；错误执行程序或命令，造成系统死机；3. 系统硬件故障，主要包括电源及UPS故障、硬盘故障、通讯控制器故障、系统总线、内存、CPU故障等4. 安全体系被攻破造成数据被恶意破坏5. 生产地点的灾难：水灾、火灾、地震及其他机房事故等6. 其它：包括灾难的潜在影响，如水灾、地震等，常伴随着电力的供应问题。针对BOSS系统中的关键业务，考虑其业务连续性的风险及严重程度，确定BOSS容灾相关要求如下：1. 数据是整个系统赖以运转的基础。要求对BOSS系统的数据进行有效的容灾保护，其中，对业务影响最大的营账数据，要求进行实时保护；其他相关的数据，要求尽量提供保护，使得数据被破坏后，能够在可以容忍的时间内恢复。2. 对核心数据的保护，应当同时具有物理和逻辑两重保护即既可防范物理灾难，用提供从逻辑故障中快速恢复系统的能力。对关键的业务，要求提供恢复能力，由于BOSS系统中各个子系统的紧密偶合性质，要求营账、计费、结算、采集等系统均具有灾难恢复能力。3. 要求容灾系统的各个子系统和生产系统的各个子系统之间具有清晰可靠的接口，并考虑到各个子系统的切换和回切。恢复时间恢复程度计费24小时24小时前营业、账务2小时不允许数据丢失统计计费类统计同计费系统，业务类统计同营帐系统客服内部统计可不保留，数据保存静态查询信息即可，恢复程度1小时。结算同营帐6. XX移动BOSS容灾系统建设方案6.1. 系统结构（1） 范围：完成BOSS核心业务的容灾，包含计费、营帐、结算、统计、查询、8地市采集、客服数据中心等。由于经营分析系统刚开始建设，本期容灾系统不含经营分析系统。BOSS容灾系统需实现： 处理能力的保护、冗余、复用（服务器及操作系统、存储网络、中间件、数据库、应用软件、网络） 业务状态数据的保护、备份和恢复以及复制（交易状态、系统状态、应用参数设置、配置数据、中间数据） 外部接口的冗余和切换（2） 地点选择：容灾是为了在意外情况（如电源故障、系统故障、人为误操作及自然灾害等）发生时保障业务连续性而采取的一种应对机制，因此容灾系统与生产中心需设在不同的地方。我公司容灾系统可设置在省会，也可设置在省会外其它城市，如大连。如果设在省会，系统将省帐务中心统一维护，其维护能力很强，且开发商的开发及本地服务中心也在省会，对系统的支持能力也很强；如果设在省会外其它城市，网络结构会变得复杂，系统维护能力较弱，系统调整及应用的改变的速度较慢，系统远距离管理也不方便。同时根据前文中对各种意外情况的统计，电源及系统故障所占比例较高，地震等自然灾害发生的机率相对要小得多。因此为保证BOSS关键系统的维护，为业务的部署提供灵活的手段和快速的响应，建议我公司BOSS容灾系统设在省会，统一由帐务中心维护。XX机房为省会四个传输结点之一，且经营分析系统也将建在XX，因此建议BOSS容灾系统设在XX新机房四楼。XX机房与XX机房传输距离约为十五公里。（3） 系统需具备现有生产系统所具备的所有功能，并实现对生产系统的异地备份。当灾难发生时，备份系统启动，进行应用接管，从而保证业务的连续性。灾难恢复后，备用系统可将灾难期间变更的数据同步至生产系统中，并将应用切换回生产系统，恢复生产系统的正常运行。（4） 由于容灾系统也需可切换为生产系统使用，因此容灾系统的处理能力应与生产系统相同，并按高可靠性进行设备配置。6.2. 数据复制技术选择BOSS系统中所含子系统较多，且每个系统都有不同的业务运行特点，因此容灾技术的选择需根据各子系统的特点及不同的要求而定。6.2.1. 营帐系统BOSS系统的营业和帐务是BOSS的核心系统，关系到用户服务质量，停机时间不能够超过2小时，而且数据不允许丢失。营帐系统包括数据库服务器、应用服务器、工单服务器、银行接口服务器、一级BOSS WEB服务器等设备。数据库服务器处理数据量比较大，数据十分关键，是整个业务系统数据一致性的核心，要求生产系统数据和容灾系统数据高度一致；营账系统的数据变化量相对较小，但对系统响应时间要求较高，其交易是典型的联机事务处理方式；以上这些特点，要求系统采用磁盘复制技术由于BOSS系统存储的磁盘阵列采用的是EMC Symmtrix8000系列，支持基于存储的复制方式，因此营帐系统数据库建议采用EMC SRDF软件进行基于存储的数据复制，以保证数据的不丢失。磁盘复制技术有同步和异步两种方式。根据前文介绍，同步方式下交易需在两套系统中同时完成，因此可以保证容灾系统中的营账数据库和生产系统中的营账数据库完全一致，从而从根本上保证了业务的完整和一致。而异步方式下，备用系统中数据更新会落后于主系统，因此在主系统发生灾难时，起用备份系统时还需要人工补充丢失的数据，这将直接影响系统恢复的时间，因此建议营帐系统数据采用同步磁盘复制技术。基于目前对容灾中心的规划，由于容灾中心和生产中心之间的距离，采用同步复制技术进行数据复制所形成的额外IO延迟，不会对生产系统形成影响。但是，如果两中心之间的网络带宽不足以支持营账数据库的写操作带宽，则会影响生产系统性能。因此，建议采用裸光纤直连或DWDM的方式，作为存储系统数据复制的网络平台。采用同步复制，理论上能够对生产系统的营账数据库进行完整地保护，但是，当生产系统发生逻辑错误时，由于容灾数据是生产数据的实时精确镜像，所以逻辑错误也会“传播”到容灾系统当中。容灾系统会对这种灾难失去保护作用。为了防范这种逻辑类型的错误，需要辅助快速的数据库复制和恢复技术。因此，对最关键的营账数据库，我们将在生产中心（或容灾中心）部署克隆磁盘，以支持数据库的快速复制和恢复。应用服务器、工单服务器、银行接口服务器没有数据库和磁盘阵列操作，只对其应用程序定时进行同步备份。营帐系统主备结点设备要求同构。（包括主机、产品阵列、数据库）HLR、银行、一级BOSS、智能网、短信、声讯等接口设备部分采用应用级复制方式，由集成商开发，夜间定时启动进程完成两套系统应用程序和配置文件的复制，保证两端程序一致性。6.2.2. 计费系统计费系统是基于文件的处理方式，特点是数据量大，数据变化量也大，但实时性要求较低，可允许较长的停机时间，建议采用应用级的复制方法。话单采集系统将从交换机采集到的话单原始文件同时向生产系统和容灾系统的话单预处理批价系统传送。生产系统处理后将计费合帐后的话单定时（5分钟）形成文件送到查询结算系统后，将这些文件传至容灾系统并实时写入计费系统数据库。容灾系统收到采集系统传来的原始数据后不进行处理，只对原始文件进行备份。生产系统每天夜里定时将用户的帐单、报表数据、用户计费信息数据、基础数据等数据传送容灾系统中入库到同样的表中。当生产系统发生灾难，容灾系统以利用采集系统传来的原始话单文件（灾难发生1小时之前的数据）重新进行计费，并利用数据库的唯一索引进行话单剔重处理，从而保证话单数据很快恢复。对用户的帐单和报表数据可以开发应用程序重新统计当日0点到灾难时刻的数据，与夜里传来的信息进行累加而得到。用户计费信息可以从容灾系统的营业数据库中重新同步得到。在灾难发生时可能会有一小部分数据没有复制到容灾节点，这些数据可以从采集系统找回来。计费系统除数据的处理之外，系统中参数的设定（如费率表、用户资费变更表）等采用数据表复制的方式复制到备用系统中。同时，需定期将对系统运行的相关程序拷贝至备用系统，以保证应用软件及相关参数的同步。计费系统主备结点设备可以异构。6.2.3. 8地市BGW及采集预处理系统8地市集中BGW及采集预处理数据的特点与计费系统相似，主要基于文件处理，并将处理后的数据文件送至下一环节进行处理，建议对此部分数据不作复制，如果需要保存中间数据可以采用与计费系统相同的复制方式。灾难发生时，部分丢失的数据可以从设备上重新采集，由计费系统剔重。同计费系统一样，定期将系统中参数文件及应用程序拷贝至备用系统，以保证应用软件及相关参数的同步。根据爱立信BGW软件硬件平台的要求，容灾结点设备需采用SUN服务器。6.2.4. 结算系统结算系统负责处理与运营商之间的话单结算，同时还负责处理短信、智能网、VPMN、梦网等信息源的计费和查询工作，为了保证两中心数据处理的一致性建议采用与营业系统相同的数据复制方式，即磁盘同步复制方式。同时每天夜间定时将系统中磁盘阵列数据拷贝至备用系统，以保证应用软件及相关参数和数据的同步和及时更新。容灾系统启动时，将各信息源从同步开始时间重新处理，利用程序剔重机制，保证话单计费准确性。结算系统主备结点设备要求同构。6.2.4 统计系统统计查询是来源与计费和营帐系统，计费系统处理完成后将数据送往统计查询主机，对于统计和查询的数据同时还将送往经营分析系统。因此对于此部分数据可以不作复制。但为保障容灾系统的完整性，避免所有数据重算，建议备份节点的统计和结算不保存详细的资料，只保存统计结果，结算帐单。这些数据建议采用表复制方式定期备份至备用系统。结算系统采用与计费系统相同的复制方式。定期将系统中参数文件及应用程序拷贝至备用系统，以保证应用软件及相关参数的同步。容灾系统启动时，历史的统计结果、结算帐单查询可以直接在数据库中执行。新的统计和当月结算帐单，由计费系统、营帐系统中取数据重新生成。6.2.5. 客服系统客服系统包括数据库服务器、应用服务器（CICS）、Web服务器及排队机系统。它也是重要的业务系统，允许业务中断时间短，它的中断将直接影响我公司客户服务的质量。客服系统的主要用户数据都是来源于生产系统，客服数据中主要记录受理信息，允许一定的丢失。系统目前采用的磁盘阵列也不支持磁盘级复制，因此建议对客服系统数据采用数据库表复制方式，对静态表进行同步。排队机系统已建设两个呼叫中心，互为备份，因此本方案中不包括对排队机的容灾。定期将系统中参数文件及应用程序拷贝至备用系统，以保证应用软件及相关参数的同步。客服系统主备结点设备可以异构，建议采用与现有系统相同的配置。6.2.6. 网络容灾系统建成后，将存在两个中心，两个中心间存在大量的数据交换，各市业务终端、其它关联系统也需与两个中心连接。两中心间（即XX与XX）采用裸光纤，用于磁盘数据复制及文件的传送。由于磁盘复制与文件传输所采用的协议不同，可通过光纤复用器对光纤进行复用，在一条光纤上同时传送磁盘复制的数据，以及文件系统同步的数据，以提高线路利用率。同时考虑到传输安全的要求，建议XX至XX系统开通两条光纤进行数据传递。各市结点通过MDCN网分别与两个中心进行连接。现各市至XXMDCN结点采用一条E1及一条155M电路（155M正在实施），至XX机房为2条E1电路。XX系统建设中，XXBOSS机房中相关设备将搬至XX机房，MDCN省中心结点也将搬迁。因MDCN网承载BOSS、网管、OA等公司全部支撑系统数据传送，对其稳定性及可靠性要求很高，因此建议各市至XX结点也采用155M电路进行数据传送。XXMDCN结点已配置了2台CISCO6509。6.3. 系统监控与切换控制灾难切换需根据生产系统和备份系统的具体情况，分阶段完成，主要阶段如下： 利用复制数据恢复数据 启动异地中心的各处理要素（如数据库、应用等） 开通异地中心的对外服务网络，恢复业务的运行容灾系统的切换与局域网内的高可用系统（HA）切换不同，一般不能使用自动切换，否则会造成系统数据混乱。而且这些软件的控制切换时也需要针对应用写大量的检测脚本和切换脚本。建议通过监控系统对系统设备和应用进行监控，人工判断故障程度，手动切换应用系统。为提高手工操作切换速度，简化灾难切换的人工操作步骤，减少手工操作带来的风险，需由软件开发商为各个子系统开发相应的自动化脚本。当生产系统发生不可短时间恢复的故障时，人工触发切换脚本，系统自动执行这些程序，迅速将相关应用切换到容灾系统上。系统恢复后，再执行切换脚本将容灾系统切换回生产系统。包括各个业务系统在内的整个BOSS系统，必须设计流程清晰明确、步骤简洁完整的系统切换业务接管的容灾系统操作指南。6.4. 演习为保障在灾难发生时，容灾系统能够真正实现接替生产系统，需要在系统建成后最系统切换演习，模拟生产系统崩溃，测试容灾系统切换速度，切换后业务影响，检验容灾是否能够达到设计目标。而且可以演练各相关部门的协调运作能力。6.5. 系统处理能力及存贮容量计算计费部分现有系统配置及使用情况：主机配置系统存储容量系统用户数TPCC值CPU利用率存储使用容量数据吞吐量(每日)忙时吞吐量（每小时）SUN E10KCPU48*400MHZ16Gmem0.8T350万11000036%650G40G3.3GSUN E10KCPU32*400MHZ12Gmem0.8T343万9000048%650G38G3.2GSUN E6500CPU16*400MHZ8Gmem0.8TXX万3300025%0.4T30G2.5G服务器处理能力需求计算：集团公司BOSS技术规范书中指出： 每用户12张话单/日 忙时集中率 15% 300BYTE/张话单1）数据库主机处理性能需求话单入库服务器配置：每用户每月360张话单，平均每小时0.5张。考虑到话务量不平均，按忙时集中系数15%计算，系统高峰期按每用户每小时2张话单计算。处理包括：传输、检错、批价、入库和高额分析五个过程。在这五个过程中，入库操作是主要的数据库操作，计算量最大，消耗系统资源最大的操作。与它相比，其他操作过程可以忽略。根据我们的测试及经验，一个话单处理相当于0.25个tpmC交易。同时考虑将增值业务计费处理和详单查询和网间结算处理流程考虑进去，系统开销增加100。同时系统应预留30%的资源。计算公式：话单处理能力tpmC=用户数*每小时每位用户话单数*0.25/60*2*1.3900万用户话单处理能力tpmC9000000*2*0.25/60*2*1.3=195,000tpmC；同时在服务器数量配置考虑以下几个方面的因素：1、 系统备份方式：考虑系统将来作为主用系统，系统备份可以采用双机备份方式，保证计费系统的稳定性。2、 可扩展性：系统考虑将来用户数的不断增加，硬件设备也应该预留一部分可扩展能力。在用户数达到其处理能力时，可以增加CPU来满足，而不需要在购买服务器。3、 业务处理方式：目前系统采用两台主机处理全省话单，容灾中心的服务器结构也建议与生产中心相同。两台主机分别处理沈大和其他12地市话单。营帐部分a现有系统配置及使用情况：主机配置系统存储容量系统用户数TPCC值CPU利用率存储使用容量数据吞吐量(每日)忙时吞吐量（每小时）SUN E10KCPU 48*400MHZ16GMem1T325万11000066%420G40G3.3GSUN E10KCPU 48*400MHZ16GMem1T368万11000069%450G45G3.8G目前营帐系统的两台主机，在系统出完帐的第二天均会出现CPU使用率为100%的现象。因此容灾系统在设备选型应考虑到该因素。b、数据库服务器处理能力： 设计容量略大于当前节点的设计容量，按照全省900万用户，3000台营业终端的容量来设计。营业处理是典型的联机事物处理(OLTP)应用。目前在OLTP领域，机型的配置一般按以下公式配置：tpmC=(并发终端*每笔业务量)/每笔业务处理上限*60*180%*140%注：1）并发终端指同时访问主机的客户端数。2）每笔业务量指6次交易约折合的标准交易，以8个计算。3）每笔业务处理上限指系统要求的每笔交易的反应时间（2秒）。4）60指每分钟60秒。5）考虑后台进程（实时停机等）和与客服、银行等的接口的开销是营业前台受理开销的80。6) 预留40系统处理资源。假设高峰期约20%终端访问主机，则营业处理对主机性能需求为：营业主机处理能力3000*8*20%/2*60*180%*140%=362880 tpmC主机的处理能力应在226800 tpmC以上。考虑营业系统的实时交易性强，系统可靠性要求极高，建议在备份节点也采用并行处理，互为备份的主机系统结构。c、营业中间件及接口服务器：目前采用2台SUN E6500 ，每台16个CPU,6GB内存。CPU负荷在40，服务器处理能力在6万左右。可以采用相同档次服务器作为容灾中心中间件服务器。d、银行、一级BOSS、智能网接口服务器和HLR工单机考虑利旧原有SUN-E5000服务器（四台）。结算部分现有系统配置及使用情况：主机配置系统存储容量系统用户数TPCC值CPU利用率存储使用容量数据吞吐量(每日)忙时吞吐量（每小时）SUN E10KCPU 48*400MHZ16GMem2.4TXX万11000058%1.2T60G5G根据结算系统目前还承担短信、梦网、GPRS、智能网、VPMN等业务话单计费。考虑未来公司业务发展将以数据为主的经营策略。估算系统处理能力时根据目前系统情况，增加冗余程度，满足系统处理能力需求。 目前XX万用户的服务器处理能力是110000*58%=64000tpmc 系统在未来900万用户时需要处理能力为64000/XX*900=83000TPMC 考虑未来新业务增长给系统带来压力，系统预留50的资源。 结算系统处理能力值83000*1.5=125000tpmc 结算系统建议采用双机备份方式，或与计费系统采用3+1备份方式。客服 a、数据库服务器主机配置系统存储容量系统用户数TPCC值CPU利用率存储使用容量数据吞吐量(每日)忙时吞吐量（每小时）IBM M85CPU 8*750MHZ8GMem2T740万10000040%600G30G2.5GIBM M80CPU 6*500MHZ6GMem740万5100058%客服系统主要生产中心在XX客服机房，XX机房出现灾难时，XX容灾系统才会启动。因此建议对XX客服系统的备份系统采用单机方式运行。根据客服系统四期扩容计算结果，客服系统数据库服务器处理能力要求在100,000tpmc以上。b、应用服务器客服系统现采用两台M80作为CICS应用服务器，处理能力为50000tpmc以上。容灾中心建议采用一台IBM服务器，根据客服系统四期扩容计算结果，客服系统应用服务器的处理能力应为50000tpmc以上。八地市采集及采集预处理 目前采用两台SUN-E3000，应用采用主备方式。服务器处理能力在2万左右。采集服务器与交换机之间传输采用MDCN线路，采用TCP/IP协议。为了保证系统切换到容灾中心后，对八地市交换机采集连续性。建议在容灾中心设置两台BGW采集设备作为备用。网络容灾系统建成后，将存在两个中心，两个中心间存在大量的数据交换，各市业务终端、其它关联系统也需与两个中心连接。两中心间（即XX与XX）采用裸光纤，用于磁盘数据复制及文件的传送。由于磁盘复制与文件传输所采用的协议不同，可通过光纤复用器对光纤进行复用，在一条光纤上同时传送磁盘复制的数据，以及文件系统同步的数据，以提高线路利用率。同时考虑到传输安全的要求，建议XX至XX系统开通两条光纤进行数据传递。各市结点通过MDCN网分别与两个中心进行连接。现各市至XXMDCN结点采用一条E1及一条155M电路（155M正在实施），至XX机房为2条E1电路。XX系统建设中，XXBOSS机房中相关设备将搬至XX机房，MDCN省中心结点也将搬迁。因MDCN网承载BOSS、网管、OA等公司全部支撑系统数据传送，对其稳定性及可靠性要求很高，因此建议各市至XX结点也采用155M电路进行数据传送。XXMDCN结点已在经营分析项目中购买了2台CISCO6509。网络拓扑见附图银行接口：各银行目前都只申请了一条DDN到XXBOSS机房或XX机房，目前没有备用线路。可以在XX机房购买一套路由器和防火墙，和各个银行之间再申请一条备用线路。一级BOSS：现在一级BOSS的线路有两条2M，从北京到XXBOSS机房。两台CISCO 3640路由器之间运行HSRP协议，实现热备份。可以另外申请一条2M或者迁移一条2M线路到XX节点，但必须得到集团公司的同意。智能网、短信、声讯：智能网和短信中心、梦网网关、声讯等系统都在省会，目前通过2条线路连接到BOSS系统。一条是10M太网连接到XXBOSS机房，一条是2M连接到XXBOSS机房。省会公司计划在XX智能网机房新建一个MDCN主节点，同XX短信机房（短信三）同址，可以通过网线直联。此MDCN节点到XXBOSS系统、XX节点都有直达线路，可以保证线路的安全。各市HLR、计费采集系统都是先连接到市MDCN主节点，再连接到XXBOSS机房。市MDCN主节点到XXBOSS系统、XX节点都有直达线路，可以保证线路的安全。客服系统：客服一系统同XXBOSS机房同址，共用电源和UPS。如果XX机房发生除电源外等灾难，客服一系统网路可以通过与客服二之间电路迂回到XX机房，从而保证网络传输不会中断。客服二系统在十一纬路省公司五楼，到