一、传统灾备:金融行业使用一般都已经基于传统技术体系实现了灾备,分别应用级别灾备,和基于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)分布式数据库分库分表、同城灾备后,交易一致性是一个难点 ,数据备份和数据恢复是一个难点。
发出来希望听听金融行业的朋友们你们在云灾备和传统灾备建设下的思路,提升与局限?
灾备建设核心内容还是要围绕降低RPO和RTO来进行展开。不同的要求对应着不同的实现方案。
而不同的实现方案对应了不同的项目资金投入。
传统容灾建设和云环境并不应该是各自独立的方案,而是如何通过叠加的方式更好的实现容灾方案。例如应用级别的容灾在云环境中扩大了容灾环境的区域,可以减少人工依赖,采用更加自动化的方式提供快速的切换。
从整个架构的角度需要通过分层之后逐层的设计相应的容灾方案,例如在中间件层面无数据存储的情况下,通过地址切换就可解决高可用的问题,而在消息队列应用方面如何保证主节点故障之后数据的完整性?
而对于灾备方案来说最困难的一点还是在于如何保证主用站点与灾备站点在数据库层面的一致性,这个对于各大存储包括数据库厂商都可以提供一些相关的解决方案。而这又将基于最开始的核心内容。
不可避免需要面临另一个问题是在于灾备环境中的设备投入。是否需要搭建一套与主用环境相同规模的容灾环境?如何更好的提高资源利用率?也是企业在考虑搭建容灾环境需要考虑的问题。
另外提供一个思路,分布式存储厂商提供的双活方案是否可以满足一部分特殊的需求。
对于虚拟机层面来说,还有一些其他厂商产品可以实现Hypervisor层面的容灾。RPO可以做到秒级。