金融行业云环境的灾备建设与传统灾备建设的思路、提升与局限探讨?

一、传统灾备:金融行业使用一般都已经基于传统技术体系实现了灾备,分别应用级别灾备,和基于FC网络的数据库灾备。具体形态(1)应用级别灾备,在本地和同城机房部署相同应用,访问主中心的数据库;(2)存储级别灾备,特点是平时灾备中心不启动,例如EMC Symantec,IBM的PPRC,华为的Hyper metro(3)...显示全部

一、传统灾备:金融行业使用一般都已经基于传统技术体系实现了灾备,分别应用级别灾备,和基于FC网络的数据库灾备。具体形态(1)应用级别灾备,在本地和同城机房部署相同应用,访问主中心的数据库;(2)存储级别灾备,特点是平时灾备中心不启动,例如EMC Symantec,IBM的PPRC,华为的Hyper metro(3)数据库级别灾备,比如DB2 HADR技术(4)数据库级别的双活,需要数据库双活+文件系统双活+存储双活。比如Oracle的RAC或ADG+GPFS文件系统+存储的Vplex、SVC或Hyper metro(5)网络方面: 使用二层延伸的方法,本地系统和同城灾备在一个网段内,灾备切换中,需要将灾备中心的IP修改为生产中心IP。

二、云环境下的灾备:1、思路与提升(1)大量使用IP存储网络替代FC存储网络,IP比FC网络组网个灵活,使用更方面,扩容更容易(2)使用DNS实现大二层。这样切换IP更容易(3)通过智能DNS实现了应用双活,基于域名的灾备切换(4)使用虚拟机、容器替代实体机。出现了通过Vmware的SRM实现的整体系统在灾备,并实现了灾备调度系统(5)基于CDP技术,实现数据同步和灾备(6)分布式数据库,替代传统数据库,通过一主多从实现数据库级别灾备。

局限与待改进探讨:(1)分布式架构下,系统更范围,节点更多,急切需要实现云平台在发布资源时整套环境 (2)SRM的基于IP的数据传输,默认是15分钟,RPO太长(3)SRM是整个虚拟机的同步,不能像SAN存储那样实现只同步一个卷的数据(4)分布式存储,目前还不能像SAN存储那样实现可靠的存储级别的灾备 (5)分布式数据库分库分表、同城灾备后,交易一致性是一个难点 ,数据备份和数据恢复是一个难点。
发出来希望听听金融行业的朋友们你们在云灾备和传统灾备建设下的思路,提升与局限?

收起
参与40
  • 云计算现在已经不是新潮的技术了,但是金融机构应用系统上云的步伐相对缓慢。个人观点,应用上云会有几个阶段,初期阶段是为了上云而上云,传统架构上的应用系统移动到云环境中,中级阶段部分应用组件适应于云环境部署,终极阶段符合云环境的云原生应用真正在云上生根。 每个阶段所涉及不同的灾备技术。
    2019-04-16

查看其它 5 个回答liuqijun的回答

liuqijunliuqijun  其它 , KLB

您说的问题我们也在考虑。

    一个企业信息系统在架构上存在太多的历史包袱,影响未来信息建设工作开展,就如灾备。先聊下应用系统吧。无论是在传统的物理或逻辑主机架构下,我个人认为是应该改造应用与基础架构实现系统跨地域多活功能,当然改造成本代价确实太大,此时就要制定标准有选择的进行改造。对于重要程度低的还是建传统模式的灾备,监管在这方面也有宽限度的。
    运行在云上的基于虚拟机平台的业务系统,理论上来说这类系统对运行平台的计算、存储资源要求不是非常高,但业务在并发处理的事务上可能要求高,应用集群部署最简单的方式解决此类问题,也是直接实现应用双活或多活的最大动力,可以说顺理成章。
    前面聊的都是应用系统方面的实现,问题是数据库该怎么办?据了解现在就连技术专家云集、谨慎的银行业也少有把数据库放到虚拟化上的,无论在处理能力、IO(说明下是虚拟I/O,非虚拟机+物理I/O)上存在顾虑是必然的。在灾备中,解决关系型数据库灾备建设确实也是难点,我之前了解一个企业实现应用双写,难度不是一般,例如最简单问题就是要考虑两边全部写成功才能反回此事务是完成,又要考虑两边的基础环境是否一致,否则交易响应时间太长,客户体验感太差。
    分布式数据库是不是最佳解决办法?ACID问题一直困扰所有人,分布式数据库这方面实现都是基于两个阶段提交实现强一制的,想必有很早使用分布式数据库的企业在这方面经历的问题也积攒太多经验财富,选择ORA\\DB2,还是分布式,看的是一是魄力二是技术发展战略。如果使用分布式数据库,我想前面提到容灾的问题就不再是问题。
银行 · 2019-04-16
浏览4366

回答者

liuqijun
其它KLB
擅长领域: 分布式系统服务器存储

回答状态

  • 发布时间:2019-04-16
  • 关注会员:9 人
  • 回答浏览:4366
  • X社区推广