天津移动业务支撑应急系统设计与实现.doc
约137页DOC格式手机打开展开
天津移动业务支撑应急系统设计与实现,本文为硕士论文 全文四万多字符。摘 要目前中国移动集团天津公司ng-crm/boss系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特...
内容介绍
此文档由会员 crespo1111 发布
本文为硕士论文 全文四万多字符。
摘 要
目前中国移动集团天津公司NG-CRM/BOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特定的时间要求内全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险：
1) 由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。
2) 人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NG-CRM/BOSS系统全部业务要求7×24小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。
3) 在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。
4) 生产机房发生火灾、泡水等情况下，多节点负载分担和本地HA模式都不能保障业务连续性。
本文将从应急系统的系统架构、建设实现、系统测试各方面对于上述风险及问题进行研究并逐一解决。
关键词： 业务支撑系统 应急系统 运营商
目 录
目 录 4
第一章 绪 论 1
1.1 研究背景 1
1.2 研究目的及意义 1
1.3研究的主要内容及论文结构 2
第二章 天津移动业务支撑系统现状分析及应急建设需求 3
2.1系统现状及风险分析 3
2.1.1功能现状 3
2.1.2软硬件配置现状 4
2.1.3网络组织现状 6
2.1.4风险分析 8
2.1.5风险应对措施 9
2.2 应急建设需求 11
2.2.1业务建设范围 11
2.2.2接管时间要求 15
2.2.3应急数据同步 15
2.2.3应急数据回切 16
2.2.3应急系统管理功能 17
第三章 天津移动业务支撑应急系统技术研究 19
3.1 持续数据保护技术(CDP) 19
3.1.1定义 19
3.1.2与现有数据保护手段对比 19
3.1.3总结 20
3.2 基于J2EE的多层技术架构 20
3.2.1J2EE技术介绍 20
3.2.2J2EE四层模型 20
3.2.3J2EE结构 22
3.2.43J2EE优势 24
3.2.5J2EE和.NET体系结构比较 26
3.2.6总结 29
第四章 天津移动业务支撑应急系统的建设方案 30
4.1应急系统定位 30
4.2应急系统与外围系统边界 33
4.3应急系统目标 34
4.4应急系统架构 35
4.4.1功能架构 36
4.4.2数据流设计 41
4.4.3物理部署 47
4.4.4外围接口切换 48
4.4.5应急系统安全设计 48
4.4.6数据模型设计 49
4.5应急系统建设方案 51
4.5.1应急受理子系统 51
4.5.2应急管理平台系统 72
4.6应急系统硬件及平台软件建设方案 79
4.6.1硬件平台方案 79
4.6.2硬件配置方案和应用部署图 85
4.6.3网络环境 87
4.6.4系统软件 87
第五章 天津移动业务支撑应急系统应急场景的分析和确定 89
5.1应急场景 89
5.1.1应用分析 89
5.1.2分业务分析 94
5.1.3针对风险点的应急分析 94
5.2建设场景 95
5.2.1正常场景 95
5.2.2场景1网上营业厅应用切换场景 96
5.2.3场景2短信营业厅应用切换场景 98
5.2.4场景3联指应用切换场景 100
5.2.5场景4客服应用切换场景 103
5.2.6场景5外围接口应用切换场景 105
5.2.7场景6统一接入应用切换场景 107
5.2.8场景7CRM应用全切场景 109
5.2.9场景8全切场景 112
第六章 天津移动业务支撑应急系统演练 116
6.1演练场景 116
6.2演练范围 116
6.3演练流程 116
6.3.1生产系统切换到应急系统流程 116
6.3.2应急系统回切生产系统流程 119
6.4演练总结 122
第七章 结论与展望 125
参考文献 126
发表论文和参加科研情况说明 127
致 谢 128
摘 要
目前中国移动集团天津公司NG-CRM/BOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特定的时间要求内全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险：
1) 由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。
2) 人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NG-CRM/BOSS系统全部业务要求7×24小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。
3) 在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。
4) 生产机房发生火灾、泡水等情况下，多节点负载分担和本地HA模式都不能保障业务连续性。
本文将从应急系统的系统架构、建设实现、系统测试各方面对于上述风险及问题进行研究并逐一解决。
关键词： 业务支撑系统 应急系统 运营商
目 录
目 录 4
第一章 绪 论 1
1.1 研究背景 1
1.2 研究目的及意义 1
1.3研究的主要内容及论文结构 2
第二章 天津移动业务支撑系统现状分析及应急建设需求 3
2.1系统现状及风险分析 3
2.1.1功能现状 3
2.1.2软硬件配置现状 4
2.1.3网络组织现状 6
2.1.4风险分析 8
2.1.5风险应对措施 9
2.2 应急建设需求 11
2.2.1业务建设范围 11
2.2.2接管时间要求 15
2.2.3应急数据同步 15
2.2.3应急数据回切 16
2.2.3应急系统管理功能 17
第三章 天津移动业务支撑应急系统技术研究 19
3.1 持续数据保护技术(CDP) 19
3.1.1定义 19
3.1.2与现有数据保护手段对比 19
3.1.3总结 20
3.2 基于J2EE的多层技术架构 20
3.2.1J2EE技术介绍 20
3.2.2J2EE四层模型 20
3.2.3J2EE结构 22
3.2.43J2EE优势 24
3.2.5J2EE和.NET体系结构比较 26
3.2.6总结 29
第四章 天津移动业务支撑应急系统的建设方案 30
4.1应急系统定位 30
4.2应急系统与外围系统边界 33
4.3应急系统目标 34
4.4应急系统架构 35
4.4.1功能架构 36
4.4.2数据流设计 41
4.4.3物理部署 47
4.4.4外围接口切换 48
4.4.5应急系统安全设计 48
4.4.6数据模型设计 49
4.5应急系统建设方案 51
4.5.1应急受理子系统 51
4.5.2应急管理平台系统 72
4.6应急系统硬件及平台软件建设方案 79
4.6.1硬件平台方案 79
4.6.2硬件配置方案和应用部署图 85
4.6.3网络环境 87
4.6.4系统软件 87
第五章 天津移动业务支撑应急系统应急场景的分析和确定 89
5.1应急场景 89
5.1.1应用分析 89
5.1.2分业务分析 94
5.1.3针对风险点的应急分析 94
5.2建设场景 95
5.2.1正常场景 95
5.2.2场景1网上营业厅应用切换场景 96
5.2.3场景2短信营业厅应用切换场景 98
5.2.4场景3联指应用切换场景 100
5.2.5场景4客服应用切换场景 103
5.2.6场景5外围接口应用切换场景 105
5.2.7场景6统一接入应用切换场景 107
5.2.8场景7CRM应用全切场景 109
5.2.9场景8全切场景 112
第六章 天津移动业务支撑应急系统演练 116
6.1演练场景 116
6.2演练范围 116
6.3演练流程 116
6.3.1生产系统切换到应急系统流程 116
6.3.2应急系统回切生产系统流程 119
6.4演练总结 122
第七章 结论与展望 125
参考文献 126
发表论文和参加科研情况说明 127
致 谢 128
