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