《天津移动业务支撑应急系统设计与实现.doc》由会员分享，可在线阅读，更多相关《天津移动业务支撑应急系统设计与实现.doc（180页珍藏版）》请在金锄头文库上搜索。
1、天津移动业务支撑应急系统设计与实现12020年5月29日文档仅供参考摘 要当前中国移动集团天津公司NG-CRM/BOSS系统的业务连续性保障体系有三种模式,一种是多节点负荷分担方式,该方式主要用于系统接入层和业务逻辑层,有效地降低了个别节点故障对业务的影响程度;一种是容灾模式,由于多年未升级,系统资源与生产中心已不匹配,在发生突发事件时,容灾系统不能在特定的时间要求内全部或部分恢复关键业务功能;一种是双机备份共享存储(以下简称本地HA)方式,该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性,存在如下风险:1)由于核心系统IO量较大,如发生系统单节点宕机等严重故障可能会
2、造成由于IO未及时写入磁盘而产生的文件系统错误,导致备机启动失败。2)人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断,本地HA将无法解决。NG-CRM/BOSS系统全部业务要求724小时运行,存储阵列的使用强度大大增加,没有时间对存储系统进行定期维修和保养。因此,当使用一段时间后,存储系统的部件连续或同时出现故障的可能性增加。另外,随着存储系统的功能和性能越来越强,存储系统内部的控制软件也日趋复杂,就像一个操作系统,其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。3)在系统割接、平台软硬件维护或应用版本升级等情况下,本
3、地HA都将可能无法满足业务连续性要求。4)生产机房发生火灾、泡水等情况下,多节点负载分担和本地HA模式都不能保障业务连续性。本文将从应急系统的系统架构、建设实现、系统测试各方面对于上述风险及问题进行研究并逐一解决。关键词: 业务支撑系统应急系统运营商ABSTRACTAt present the Tianjin NG-CRM/BOSS business continuity security system has three modes, one is a multi-node load balancing mode, this mode is mainly used for system ac
4、cess layer and business logic, effectively reducing the individual node failuresthe degree of influence of the business; a disaster recovery mode, due to years of not upgraded, the system resources and production center does not match, not within a specific time requirements in whole or in part, to
5、restore critical business functions in the event of an emergency, disaster recovery system; a double backup shared storage (hereinafter referred to as the local HA) mode, which is mainly used for the core of the system layer. The local HA mode for the system core layer to protect business continuity
6、, the following risks:1) due to the large amount of core system IO, such as the occurrence of a serious failure of the system single-node downtime may cause IO is not written to disk file system errors, leading to the backup machine failed to start.2) data corruption caused by human factors, databas
7、e logic error or storage failure causing business interruption, local HA will not resolve. All of NG-CRM/BOSS system requirements 7 24 hours to run, greatly increase the intensity of use of the storage array, do not have time for regular repair and maintenance of the storage system. Therefore, when
8、used for a period of time, the components of the storage system continuously or at the same time increase the probability of failure. In addition, with the growing functionality and performance of storage systems, storage systems within the control software are becoming increasingly complex, as an o
9、perating system, which itself will be failure or vulnerability. Some provinces have also undergone major failure of the business system for a long time downtime, data loss due to a storage failure.3) in the system cutover, platform hardware and software maintenance or application upgrade, the local
10、HA may not be able to meet the requirements of business continuity.4) production engine room fire, flood damage and other circumstances, multi-node load balancing and the local HA mode can not guarantee business continuity.From the emergency system architecture, construction, implementation, system
11、testing all aspects of the risks and problems and solve them one by one. KEY WORDS:NG-CRM/BOSS, Emergency System, Telecom Operators目 录目 录4第一章 绪论11.1研究背景11.2研究目的及意义11.3研究的主要内容及论文结构2第二章天津移动业务支撑系统现状分析及应急建设需求32.1系统现状及风险分析32.1.1功能现状32.1.2软硬件配置现状42.1.3网络组织现状62.1.4风险分析82.1.5风险应对措施92.2 应急建设需求112.2.1业务建设范围11
12、2.2.2接管时间要求152.2.3应急数据同步152.2.3应急数据回切162.2.3应急系统管理功能17第三章天津移动业务支撑应急系统技术研究193.1持续数据保护技术(CDP)193.1.1定义193.1.2与现有数据保护手段对比193.1.3总结203.2基于J2EE的多层技术架构203.2.1J2EE技术介绍203.2.2J2EE四层模型203.2.3J2EE结构223.2.43J2EE优势243.2.5J2EE和.NET体系结构比较263.2.6总结29第四章 天津移动业务支撑应急系统的建设方案304.1应急系统定位304.2应急系统与外围系统边界334.3应急系统目标344.4应
13、急系统架构354.4.1功能架构364.4.2数据流设计414.4.3物理部署474.4.4外围接口切换484.4.5应急系统安全设计484.4.6数据模型设计494.5应急系统建设方案514.5.1应急受理子系统514.5.2应急管理平台系统724.6应急系统硬件及平台软件建设方案794.6.1硬件平台方案794.6.2硬件配置方案和应用部署图854.6.3网络环境874.6.4系统软件87第五章天津移动业务支撑应急系统应急场景的分析和确定895.1应急场景895.1.1应用分析895.1.2分业务分析945.1.3针对风险点的应急分析945.2建设场景955.2.1正常场景955.2.2场
14、景1网上营业厅应用切换场景965.2.3场景2短信营业厅应用切换场景985.2.4场景3联指应用切换场景1005.2.5场景4客服应用切换场景1035.2.6场景5外围接口应用切换场景1055.2.7场景6统一接入应用切换场景1075.2.8场景7CRM应用全切场景1095.2.9场景8全切场景112第六章天津移动业务支撑应急系统演练1166.1演练场景1166.2演练范围1166.3演练流程1166.3.1生产系统切换到应急系统流程1166.3.2应急系统回切生产系统流程1196.4演练总结122第七章结论与展望125参考文献126发表论文和参加科研情况说明127致 谢128第一章 绪论1.
15、1 研究背景中国移动业务支撑系统经过近几年的集中化改造建设和不断完善,经过NGBOSS(新一代业务运营支撑系统)建设,业务支撑系统已经在市场拓展、客户服务等工作中发挥了重要的支撑作用,成为中国移动贯彻落实”服务与业务领先”战略的有力手段。日益激烈的市场竞争和不断提高的客户服务质量需求对BOSS业务支撑能力和可靠稳定运行的要求越来越高,从面向客户服务的角度而言,无论何时出现何种情况,都需要移动运营商提供不间断的业务支撑服务,以保证客户满意度、客户服务质量、企业信誉等不受影响,对企业而言也可避免财务损失,增强企业竞争力。与此同时,BOSS集中化改造、NGBOSS一阶段和二阶段建设在带来业务快速响应等众多优势的同时,也存在着系统故障点集中、风险集中的危险,如:系统故障、人为误操作、火灾、水灾、传输中断、电网停电等系统风险。因此,适时、合理地规划和开展中国移动业务运营支撑系统应急保障体系建设,已
