金融行业云灾备建设思路相对于传统灾备有何提升和局限？
@gobackto 2000 系统架构师 某银行：
一、传统灾备：
金融行业一般都已经基于传统技术体系实现了灾备，分别是应用级别灾备，和基于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）大量使用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）分布式数据库分库分表、同城灾备后，交易一致性是一个难点 ，数据备份和数据恢复是一个难点。
希望听听金融行业的朋友们你们在云灾备和传统灾备建设下的思路、提升与局限？
@张鹏 数备中心技术总监 中国金融电子化公司：
几点想法，不妥的地方请指正：
1. 传统灾备：您在文中提到的应用级别灾备，存储级别灾备，数据库级别灾备，我觉得用应用系统灾备，存储系统灾备保护，数据库系统灾备保护，这种说法歧异性小，更为合适。
2. SRM 您提到的是VMware 的SRM 产品吧，实际上还是做作业流程管理的系统，这个产品并不能替代灾备复制技术或产品。
云计算现在已经不是新潮的技术了，但是金融机构应用系统上云的步伐相对缓慢。个人观点，应用上云会有几个阶段，初期阶段是为了上云而上云，传统架构上的应用系统移动到云环境中，中级阶段部分应用组件适应于云环境部署，终极阶段符合云环境的云原生应用真正在云上生根。每个阶段所涉及不同的灾备技术。
@赵海 技术经理：
对于这个问题，我觉得可能需要从以下几个方面去分析：
首先，传统灾备建设和云环境下的灾备建设不能去比较，在金融行业当中，什么样的系统需要在传统环境下去运行，什么样的系统需要在云环境下去运行，这个是完全根据业务的特点来决策的，并不能以基础架构技术的所谓先进性来决策。不能简简单单说容器技术一定会优于IAAS技术，也不能简简单单说分布式数据库一定优于关系型数据库。根据业务的特点选择最适合的架构，选择最适合的灾备架构。
其次，灾备的建设目标根据不同的业务连续性要求，会有很大的区别。如果我的RTO要求是15分钟，RPO要求是0，这是一种建设方案。如果我的RTO要求是60分钟，RPO可以容忍15分钟，那么灾备方案是另外一种模式。金融行业在云环境下可以运行的应用，相信和自己传统资源池当中的应用系统的要求一定不一样，所以呢云环境下的灾备个人觉得主要的关注度放在业务快速切换上，而不要过于关注RPO，特殊的环境造就了特殊的关注点上。
再有，不能简简单单评价金融行业的云计算发展步伐太慢。过去是业务驱动科技发展，现在是科技引领业务创新，这个不否认。但是归根结底技术是为了金融业务服务。在所有金融业务当中，金融风险是至关重要的。所以我不认为今天的所有公有云都具备了抗金融风险的所有条件，所以为了科技的荣耀，过快的公有云发展步伐是一种不负责任的发展思路。稳健有序可持续的发展是金融科技发展的最好模式。
@liuqijun KLB：
您说的问题我们也在考虑。
一个企业信息系统在架构上存在太多的历史包袱，影响未来信息建设工作开展，就如灾备。先聊下应用系统吧。无论是在传统的物理或逻辑主机架构下，我个人认为是应该改造应用与基础架构实现系统跨地域多活功能，当然改造成本代价确实太大，此时就要制定标准有选择的进行改造。对于重要程度低的还是建传统模式的灾备，监管在这方面也有宽限度的。
运行在云上的基于虚拟机平台的业务系统，理论上来说这类系统对运行平台的计算、存储资源要求不是非常高，但业务在并发处理的事务上可能要求高，应用集群部署最简单的方式解决此类问题，也是直接实现应用双活或多活的最大动力，可以说顺理成章。
前面聊的都是应用系统方面的实现，问题是数据库该怎么办？据了解现在就连技术专家云集的谨慎的银行业也少有把数据库放到虚拟化上的，无论在处理能力、IO（说明下是虚拟I/O，非虚拟机+物理I/O）上存在顾虑是必然的。在灾备中，解决关系型数据库灾备建设确实也是难点，我之前了解一个企业实现应用双写，难度不是一般，例如最简单问题就是要考虑两边全部写成功才能反回此事务是完成，又要考虑两边的基础环境是否一致，否则交易响应时间太长，客户体验感太差。
分布式数据库是不是最佳解决办法？ACID问题一直困扰所有人，分布式数据库这方面实现都是基于两个阶段提交实现强一制的，想必有很早使用分布式数据库的企业在这方面经历的问题也积攒太多经验财富，选择ORA\DB2，还是分布式，看的是一是魄力二是技术发展战略。如果使用分布式数据库，我想前面提到容灾的问题就不再是问题。
@RDR_DOCTOR 系统架构师 信诺保险
对RPO、RTO要求不同，采用的技术也不同。
@孙振正 售前技术支持：
灾备建设核心内容还是要围绕降低RPO和RTO来进行展开。不同的要求对应着不同的实现方案。而不同的实现方案对应了不同的项目资金投入。
传统容灾建设和云环境并不应该是各自独立的方案，而是如何通过叠加的方式更好的实现容灾方案。例如应用级别的容灾在云环境中扩大了容灾环境的区域，可以减少人工依赖，采用更加自动化的方式提供快速的切换。
从整个架构的角度需要通过分层之后逐层的设计相应的容灾方案，例如在中间件层面无数据存储的情况下，通过地址切换就可解决高可用的问题，而在消息队列应用方面如何保证主节点故障之后数据的完整性？
而对于灾备方案来说最困难的一点还是在于如何保证主用站点与灾备站点在数据库层面的一致性，这个对于各大存储包括数据库厂商都可以提供一些相关的解决方案。而这又将基于最开始的核心内容。
不可避免需要面临另一个问题是在于灾备环境中的设备投入。是否需要搭建一套与主用环境相同规模的容灾环境？如何更好的提高资源利用率？也是企业在考虑搭建容灾环境需要考虑的问题。
另外提供一个思路，分布式存储厂商提供的双活方案是否可以满足一部分特殊的需求。
对于虚拟机层面来说，还有一些其他厂商产品可以实现Hypervisor层面的容灾。RPO可以做到秒级。
欢迎点击文末阅读原文到社区讨论交流，发表您的观点
觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 “灾备”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/3457
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场