BOSS容灾系统解决方案

shujuhuifu802

               

[color="#000066"]系统背景
[color="#000066"]
在各种自然或人为的灾难面前，目前企业的信息系统的确是非常脆弱的。当越来越多的人已经习惯于工作、生活在互联网环境中，任何关键信息系统运转的中断或者数据的丢失都将导致不可估量的损失。一个已经证实的数据是：网上银行每分钟运转中断成本为7000美元，企业资源管理系统为13000美元，而呼叫中心更是高达27000美元！据IDC的统计数字表明，美国在2000年以前的10年间，发生过灾难的公司中，有55%当时倒闭，剩下的45%中，因为数据丢失，有29%也在两年之内倒闭，生存下来的仅占16%。
一项调查表明，因灾难而丢失关键数据并且在几天内不能恢复关键业务的企业将会从市场上消失。对于依赖计算机系统运作的金融、电信、保险、民航、铁路和制造业而言，系统停机的可忍受时间更短。在“9·11”恐怖事件造成世贸大楼倒塌后，名列财富500强的金融机构摩根斯坦利公司在新泽西州灾难备份中心立刻切换运行，从而保障了公司全球业务的不间断运行，有效降低了灾难对于整个企业发展的影响，而很多没有建立灾难备份系统的企业却没有这样幸运。
容灾系统(Disaster Recover System)，是指为了保证关键业务和应用，在出现灾难情况时（如地震、水灾、火灾、瘟疫、人为灾难故障），能够有效对系统和应用进行恢复，以降低风险和损失而建立的系统。从容灾的方式上来说，一般分为数据级的容灾和应用级的容灾。通过容灾系统的建设，可以达到针对目前系统潜在的中断风险，提供预防机制，提高系统连续运行能力，对无法抗拒的严重灾难，提供系统恢复机制，将引发的业务损失降低到可接受的程度。
目前，全球移动市场正在逐渐走向开放和自由化，各个移动运营商在加快进行业务运营网基础设施建设的同时，不断加强计算机业务支撑系统平台的建设。随着支撑系统的不断建设，系统的数据量、应用规模、系统安全性和重要程度也在不断增加，容灾系统建设也越来越成为业务支撑系统建设中一个相当关键的环节。

[color="#000066"]系统目标
[color="#000066"]
（1）在不影响BOSS业务功能和性能的前提下，实现计费、帐务、客服等关键业务的异地容灾。以确保生产中心发生意外灾难或有计划的长时间停机时，容灾备份系统可以在4小时内接替生产任务，保证关键业务的连续性，部分关键业务恢复时间小于1小时。实现非关键业务系统容灾备份：统计分析、结算等业务的异地容灾，并实现24小时内恢复业务。
（2）可以实现子系统切换和回切。
（3）通过BOSS容灾备份系统的建设实现企业有效资源的高度共享，并和BOSS系统互为备份，负载分担，优化业务流程，提高客户管理水平，提高服务质量；为管理决策提供科学、准确、及时的依据。

[color="#000066"]系统建设范围

BOSS容灾系统工程的业务范围涉及到传统的话音、短消息、梦网和GPRS等多种移动通信业务，并包含了前台和后台关键业务处理。系统功能主要如下：
1.    计费包含：采集、数据传输、预处理、分拣、剔重、一次批价、二次批价、参数管理、漫游话单处理、系统管理等系统功能。
2.    帐务处理包含：帐务数据采集、出帐、稽核、系统管理等。
3.    帐务管理包含：销帐管理、欠费管理、帐单管理、帐务核算、帐务维护等。
4.    客服管理包含：资源管理、客户管理、大客户管理、代销商管理、密码管理、客服维护、积分管理、资费管理等部分。
5.    查询业务包含：对话音、短消息、梦网、GPRS等清单的查询和维护。
6.    外部接口包含：与营业厅、多媒体查询、网上营业厅、银行、HLR/AUC接口、1860/1861、充值卡系统、秘书台、智能网、短信中心等的接口。

[color="#000066"]　　系统方案制定原则

　　（1）实用性与成熟性：使用业界成熟、可靠和实用的容灾技术；
　　（2）开放性和标准化：基于业界开放式标准和协议支持整个系统的运行，兼容性和恢复性强；
　　（3）安全可靠性：提供良好的安全可靠性策略，支持多种安全可靠性技术手段，制定严格的安全可靠性管理措施；
　　（4）先进性：采用先进成熟的设备和技术，确保系统的技术先进性，保证投资的有效性和延续性；
　　（5）自动化和操作的简单化：系统各部分有机集成，集中控制，操作界面简单易学；
　　（6）为减少系统开发和维护工作量，容灾备份系统逻辑结构、软件架构和BOSS基本保持一致；
　　（7）容灾备份系统关键业务系统处理能力要求和BOSS中心保持一致，并有足够的扩展能力；
　　（8）容灾备份系统和BOSS的数据状态保持同步,尽可能地达到零丢失；
　　（9）要减轻容灾系统日常维护工作，承担部分业务处理和业务测试的工作；
　　（10）容灾备份系统接管恢复时间要尽可能短；
　　（11）可实现部分子系统切换和回切，如：仅进行计费系统的切换和回切工作，帐务和营业不进行切换。
　　(12) 尽量减少对在线BOSS系统的修改
　　（13）整个工程分两个阶段进行建设，第一阶段实现关键业务系统计费、营帐、客服、查询子系统的容灾备份；第二阶段实现非关键业务系统网间结算、统计分析系统的容灾备份。

[color="#000066"]　　总体设计框架

BOSS系统的容灾备份保护，主要着眼于对业务处理平台，数据平台和接入平台这三个重要的系统领域的保护，系统的总体框架如下：



　　　　　　　　　　　　　图1 BOSS系统容灾总体框架

　　[color="#000066"]容灾应用系统管理平台的系统架构


　　　　　　　图2容灾应用系统管理平台的系统架构
　　容灾应用系统管理平台采用三层软件架构，有数据层、应用层、界面层。也符合MVC的设计模式。数据层负责数据的存储，为业务层提供统一数据基础，对应于MVC的M(即Modal)。业务层负责数据处理分析，供界面层访问和调用，对应于MVC的C(即Control)。界面层负责通过用户友好向管理员提供查看，分析和管理的接口，对应于MVC的V(即View)。整个系统分工明确，结构清晰，具有良好的可扩展性和易维护性。

　　[color="#000066"]RTO&RPO指标

项目建设的RTO和RPO目标是在不影响BOSS业务功能和性能的前提下，实现计费、帐务、客服等关键业务的异地容灾。以确保生产中心发生意外灾难或有计划的长时间停机时，容灾备份系统可以在4小时内接替生产任务，保证关键业务的连续性，部分关键业务恢复时间小于1小时。实现非关键业务系统容灾备份：统计分析、结算等业务的异地容灾，并实现24小时内恢复业务。并且在大多数灾难情况下做到数据无丢失。
　　我们的方案从技术实现上能够满足RTO和RPO目标，请参考如下图示说明：


　　　　　　　　　　　　　关键业务RTO&RPO指标


　　　　　　　　　　　　部分关键业务RTO&RPO指标

[color="#000066"] 　　[color="#000066"]模拟演习

灾难过程具有突发性和不确定性，系统中所有环节都存在发生灾难的可能，针对每种可能又有不同的处理方案，每个方案步骤、操作也不尽相同，可见灾难恢复过程多么复杂！
然而，灾难又不常发生，当不幸发生时，需要我们马上解决。所谓养兵千日，用兵一时，关键时刻灾难恢复处理小组必须能够经得起考验。要达到这一点，日常训练必不少！
一年一次的训练显然不够，但为减少对生产系统的冲击，又不能频繁进行实战演习，风险及代价太大了。在下面“类型分析”章节中，我们将提出不同层次的演习方案。
演习应该达到以下几个目的：
1)       检阅系统状态，是否Ready，随时可以迎接灾难的挑战
2)       锻炼队伍，提供整个灾难恢复小组技术水平和团队协同工作能力
3)       检验和完善灾难恢复规范和流程，使之吻合实际切换要求
4)       改进和优化容灾系统，评估现有系统风险等级
5)       提高团队灾难风险意思，从思想意识上减少灾难的发生，如减少误操作
根据对生产系统影响多寡以及演出成本代价高低，由低到高，我们定义了四个等级，即：模拟演习、数据平台切换演习、灾备系统切换恢复演习、灾备系统切换回切演习。如下图所示：



对这四种模式比较如下：


模拟演习
数据平台
切换恢复
切换回切
对生产系统影响度
无
低
中
高
生产系统风险
无
中
较高
很高
实施难易程度
易
中
较高
很高
准备时间长短
短
中
较长
长
实施成本
小
中
较高
很高
建议实施频度
>4次/年
1-2次/年
1次/年
1次/年


1.       演习内容与方式
模拟系统能够模拟多种形式下的切换，如全系统切换、计费系统切换、营帐系统切换。也能模拟其他演示测试模式，如：数据平台切换测试、灾备系统切换恢复测试、灾备系统切换回切测试。
模拟演示内容应该包括以下方面：
n         流程演示
n         操作指令输入，屏幕显示
n         动画效果
n         人员之间配合演习
n         实际案例影片
n         文档介绍

2.       建议演习频度
建议每季度一次，每次尽量按实际流程走一遍，灾备恢复人员必须全员参加。
对于新手的培训，可以考虑每月一次，灾备人员不用全员参加，只需老师参加，部分人员指导即可。
3.       日常管理制度
建立配套的管理制度，特别是以下几个方面：
n         灾难等级评估制度
n         故障申告流程及响应制度
n         日周月检查制度
n         制值班制度
n         文档管理制度
n         建立紧急联系名单
(新大陆)
[/url]
               

本文来自ChinaUnix博客，如果查看原文请点：[url]http://blog.chinaunix.net/u3/93145/showart_1892109.html