背景:我们中小型地方性城市商业银行需要自建应用级异地灾备中心,承载10余个重要交易类应用系统,数据量约有30T。我们现在顾虑就是怕异地灾备演练时,数据回写的时间过长,造成数据不一致或演练时间过长不好把控。所以特发一些探讨的话题,希望借助同行的经验,给与一些参考。不吝指教!
问题1:自建异地灾备中心应如何选址?
问题2:采用什么技术性价比比较高?
问题3:数据需要回写的话,带宽应该怎么考虑?
希望大家给与一些建议和经验,感谢!
异地灾备建设主要需要满足两个方面需求:一是监管要求,两地三中心建的不完善,监管一般是会找麻烦的,年年检查都是事。
二是自身需求,满足业务连续性的要求,这个需要自己评估,依次顺序是明确业务范围、明确要建哪些系统、数据复制技术、主机平台及技术等。
问题1:选址问题,一定要满足监管要求,多和监管单位沟通,目前监管貌似新增要求灾备机房所在地必须要有分支机构。
问题2:性价比最高的一定是使用备份恢复技术,找备份厂商做,通过备份设备去复制数据。存储便宜,而且带宽需求低,缺点是rpo时间长,真出了问题切换丢的数据多。
问题3:带宽需要集合你的峰值写数据量、数据复制技术来看,不同的技术、rpo的要求时间不同,对带宽的需求自然不一样。实时同步最高,备份方式每天同步一次最低。
你这个 问题涉及太多了,相当于建应用级机房了,(首要是梳理系统间访问关系,切过去 日终跑批依赖不能有遗漏)
1、中小银行 选址跨地市100KM以上吧。
2、性价比不好论,得结合你的生产应用程序是X86 平台还是AIX平台,AIX平台就贵了。既然是应用平台,又要考虑节约,就用x86 与power虚拟化来实现。应用代码不需要从主中心实时复制过去,直接版本手动更新。只有数据库需要实时复制到异地。那么网络你的采用两套链路 物理分开(一套专用数据库复制链路;一条应用链路回写主中心。) 是x86平台的虚拟化就很好解决了,使用备份系统传输 去重很高,效率好(比如nbu),ESXI主机用多盘位 解决(低成本)。 网络架构可以简化些便于管理。
3、数据需要回写,需要结合重要系统数据库日增量、周增量、与月增量,来做评估。且多家运营商。如果有互联网业务,还得考虑公网接入。
最后你们数据中心上 DNS 没有,上应用交互没有(比如F5),有的话,就依托F5来调度。就好管控了。
1、异地灾备一定要监管沟通,一般要求200KM,具体要看监管要求,灾备自建的话,电力供应需要双路供电,要设置发电机,实现比较困难,租用IDC机房来做会比较容易实现。
2、运营商现在一般都不支持跨城市的裸光纤租用,如果只是做数据级的灾备,根据数据的备份量申请两条专线就行了,现在城商行一般都是做同城双活,异地数据备份。
3、如果做应用双活,可以考虑使用VXLAN技术,使异地灾备中心的服务器与本地的服务器同一个网段,使用F5做调度。
数据库:1、运维维护简单,风险小数据库系统可以使用异地存储复制,RPO时间会长一些,回写的时间也会长一些,但是演练的数据变化量应该不会太大。2、数据库也可以使用逻辑复制,只复制数据库日志,数据量小,同步时间断。
应用:1、应用程序和日志全部通过存储复制,同步完成后,拉起存储资源,变更配置,启动应用程序,平时不需要投产,切换时间长2、如果应用程序无需数据日志传输同步,可以直接投产变更生产与异地一起投产变更。异地应用可以直接启动应用程序。参与日常投产,切换时间短。
要建立应用级异地灾备中心,个人感觉首先考虑必要性,其次考虑投入能否接受,毕竟城市商业银行是区域性银行,如果真要发生异常,需要用到启用了异地数据中心,那灾难级别已经达到了一定程度,异地数据中心能否真正起到作用,起到多大作用,都得进行考量。毕竟建立一个异地应用级灾备中心的投入不是一个小数目。
至于技术方面,建议使用基于TCP网络的数据增量同步软件,减少同步的数据量。
我认为异地选址问题主要考虑两个方面:第一、距离和自然灾害防范问题。 银监办发﹝2010﹞114号《中国银行业监督管理委员会办公厅关于印发<商业银行数据中心监管指引>的通知》中第三条指出 “灾备中心异地模式是指灾备中心与生产中心处于不同地理区域,一般距离在数百公里以上,不会同时面临同类区域性灾难风险,如地震、台风和洪水等。 ”。第二、灾备机房选址中的周边环境问题。主要考虑电力供应、发电机布放、附近是否存在水患、空调外机扰民等情况。如果是专业数据中心园区就不存在这些问题了。
收起看你们的技术水平与硬件环境与预算,图省事就用存储复制,图省带宽就用数据日志复制,图省钱就用异构环境,
收起