Chinaunix首页 | 论坛 | 博客
  • 博客访问: 411549
  • 博文数量: 157
  • 博客积分: 5010
  • 博客等级: 大校
  • 技术积分: 1975
  • 用 户 组: 普通用户
  • 注册时间: 2009-02-17 15:22
文章分类
文章存档

2013年(19)

2011年(1)

2009年(137)

我的朋友

分类: 服务器与存储

2009-04-05 13:35:00

据中国移动通信有限公司的整体规划,按照先建设BOSS1.5,后实施容灾的原则,我省(江西省)将在BOSS1.5系统顺利交接后进行BOSS容灾项目的建设。
BOSS容灾系统是BOSS系统的有机组成部分,为BOSS系统提供完善的数据保护和恢复机制。BOSS容灾系统与BOSS生产系统互相关联、互为补充,共同确保业务的连续运行和服务的持续提供。
有关业务支撑网业务-应用-网络连续能力的解构图如图1所示。
 
 
 
                  图1业务-应用-网络连续能力解构图
 
参照国际容灾协会DRIIDisasterRecoverInstituteInternational)建议的容灾建设流程,结合各容灾试点省份的成功经验,拟采用图2所示BOSS容灾建设模型。
 
 
 
                            图2BOSS容灾建设模型
 
从上图可知,实施成功的容灾系统项目,除了需要技术保障外,还应定义关键业务、制订切换流程、明确组织架构,并采取业务分析、策略制订、方案实施、测试演练等措施,保证关键业务连续性的目标。
我省BOSS容灾本期工程建设目标为实现全业务数据级容灾和关键业务应用级容灾,BOSS容灾机房和BOSS1.5机房同城异址,并采取主备方式(本期工程不考虑业务级容灾)。
对于数据级容灾,拟采用定期拷贝方式,诸如磁带备份、数据快照、廉价存储等。定期拷贝是在业务运行过程中某一时刻对生产数据的保护。该保护一般在业务正常运行时生成,主要预防业务因生产数据的逻辑故障而造成的停顿;当生产数据因人为误操作而损坏时,可以利用该定期拷贝将业务状态恢复到损坏发生前的某一个时刻(即执行定期拷贝时)的业务正常状态。在业务恢复过程中,辅以其他手段(如手工录入等),补充自定期拷贝生成时刻起至业务中断时这一段时间业务运行产生的生产数据。
对于应用级容灾,拟采用连续复制方式,例如应用分发、数据库复制、文件系统复制、逻辑卷复制、智能存储等。连续复制是对业务状态数据进行持续不断的复制。主要预防业务系统遭遇严重故障而造成生产系统长时间无法修复时,利用该复制作为恢复生产的基础。在进行业务恢复时,利用复制结果可以恢复系统中断现场的生产数据,从而恢复业务。
在实施容灾项目前,还需事先确定几个关键问题:BOSS各子系统的RTO值(恢复时间目标,可以理解为灾难恢复时间);BOSS各子系统的RPO值(恢复点目标,可以理解为灾难损失数据量);
数据的传递方式(采取同步或异步方式);传递数据的媒介(光纤通道还是IP网络)。
本文结合我省业务支撑网各类子系统的设备使用和应用规划,提出对BOSS容灾建设的几点思路,并进行简要描述。
一、计费系统
从计费处理流程来考虑计费系统容灾,首先应保证作为计费处理源头的话单集中采集系统能在尽可能短的时间内恢复。除在容灾中心应提供必要的设备保障外,生产中心集中采集系统还应将实时应用分发至容灾中心集中采集系统,集中采集系统灾难恢复时间RTO4个小时,灾难损失数据RPO0,因为原始话单可以及时地从数字交换机中获取。
其次还应保证内存数据库(MDB)服务器尽快恢复启用,为尽可能减少文件丢失,生产中心MDB服务器通过文件复制方式,将正在内存中的处理文件传递给容灾中心MDB服务器。即使如此,生产中心MDB服务器(双机)宕机时,内存中数据无法完全和容灾中心MDB服务器内存中数据保持一致,导致数据丢失,0小时(尚无具体经验值可供参考),RTO4个小时。< p>
在集中采集系统和MDB启用后,可以完成计费帐务应用、集团上发、综合查询、网上营业厅、经分分发、详单分发等业务。
在发生容灾切换时,因为计费帐务应用不关心历史处理记录,所以平时也不必在生产中心和容灾中心之间实时传递数据,只要保证两端主机应用环境及配置一致即可(可以通过定期备份、远程FTP方式)。考虑到计费帐务应用服务器业务复杂,完全恢复需要一定的时间,因此RTO暂定4个小时。计费数据库与历史处理记录相关,因此需要在生产中心和容灾中心之间实时应用分发,尽可能保持两端数据一致。由于容灾中心计费数据库在线运行,因此发生计费数据库灾难切换时,RTO接近于0。但如果生产机房发生灾难,RTO时间应视集中采集和MDB恢复时间而定。
其它计费应用容灾方式:集团上发采用实时应用分发方式,RTO4小时;综合查询采用文件复制方式,RTO2小时;网上营业厅、经分分发、详单分发等无需数据传递,RTO2小时;统计应用、统计数据库不做应用级容灾,做磁带备份方式的数据容灾。
所有计费系统应用,凡需在两中心之间传递数据的,均采用异步方式,通过IP网络实现。具体流程如图3所示。
 
 
                         3计费系统主要处理流程
 
二、营业系统
营业系统架构与计费系统有所不同,除了营业系统设备数量比计费系统多、设备档次不及计费系统等特点外,最关键的是,营业系统不像计费系统那样存在话单处理流程,全部应用均以营帐数据库为核心,所有业务开展均以营帐数据库正常运行为前提,因此保障营帐数据库的容灾安全,是实现整个营业系统业务连续性的重点。
为便于讨论,将营业系统业务大致分成四类:营帐数据库、中间件、外部接口、克隆数据库和历史数据库。
1.营帐数据库。营帐数据一直是BOSS系统最核心数据之一,在BOSS1.5工程建设之前,我省就已初步实现营帐数据同城异地的实时复制,采用智能存储方式,通过裸纤运行光纤通道协议,同步或异步方式传输数据。
智能存储方式复制数据技术虽然比较成熟,可以控制仅丢失1个或极少IO量的数据,但也不能保证数据完全不丢失。因此在发生灾难切换时,营帐数据库数据丢失量RPO约为几分钟(同步复制方式下)或RPO30分钟(异步复制方式下),恢复时间RTO约为2个小时。
2.中间件。包括营帐中间件、详单查询中间件、客服中间件、WEBSERVER等。由于中间件应用与历史数据记录无关,因此平时在两中心之间也无需进行数据实时复制,发生灾难时,只要保证容灾中心营帐数据库正常运转,那么容灾中心中间件服务就能快速恢复,前提是网络环境冗余。各类中间件业务的RTO拟定2个小时,在考虑营帐数据库顺利恢复的情况下,留半个小时启动中间件应用。
3.外部接口。有短信接入、二卡合一、统一开通、客服接口、银行接口、自助终端、数据业务等等,此类业务容灾时,与中间件情况类似,无需在两中心复制数据,仅保证容灾中心应用正常运行即可,因此外部接口的RTO暂定4个小时。
4.克隆数据库和历史数据库。本期工程不考虑历史数据库应用级容灾,实现磁带备份的数据容灾。克隆数据库实质是生产中心和容灾中心营帐数据库的快照,每日完成一次复制,对外提供报表统计、脱机备份和数据恢复等功能。
 
  
                      图4营帐系统主要体系架构
 
BOSS容灾系统为业务支撑网提供风险预防机制和灾难恢复措施,在确保数据安全的基础上提高业务连续运行能力,降低企业运营风险,将业务损失降低到可接受的程度,以提升服务质量和服务水平,增强企业竞争力。
阅读(788) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~