存储虚拟化的容灾构建

在这个问题上，首先得看数据库的工作方式：

如果想实现拉伸的数据库集群，也就是说两个数据中心的数据库节点共同组成了一个集群，比如说ORACLE RAC。那么就得实现存储虚拟化集群。无论是操作系统层还是ORACLE的ASM是没法儿实现远距离的存储镜像。但是使用哪种存储虚拟化集群呢？是类似VPLEX的模式还是类似SVC、NetApp MCC的模式呢？如果是VPLEX，存储虚拟化节点之间也是一个AA的集群，它可以两边同时写入，但是这样就会照成数据库层和存储层两层内都会有数据竞争。如果是SVC，那么存储虚拟化节点在同一时刻只能由一边写入，也就是说数据库节点写入的时候，必然有一边需要跨数据中心远距离写，而且存储虚拟化节点还好把这个写再同步回来，保证两边存储数据同步。这样就等于数据写入走了两个来回。很麻烦。

目前这种两边都写入的双活方案，很少。大部分的解决方案都是数据库的单边写入。故障时刻热切换。或者是读写分离。

这个看应用场景的需求，如果有数据库的延伸需求，则可以跨数据中心做同城两地的虚拟化统一部署来实现双活。如果没有数据库的延伸，则可以考虑实现网络双活切换和数据同步即可。至于异地灾备，限于网络条件一般都是异步数据同步，不考虑双活。考虑到性能方面，应尽量将所有的数据I/O在单个数据中心进行处理，以达到性能较好。灾备端则使用快照方式，进行非实时数据的查询采集，出现故障时则通过F5全局流量导引至异地数据中心，实现数据的高可用。

灾备和双活是不一样的。虚拟化整合后再做灾备，最大的好处是可以利用不同厂家的设备。生产中心和灾备中心的存储可以完全不一样。SVC做容灾的案例不少。

存储的容灾只需要通过存储之间的数据拷贝就可以实现，但是成本较高。可以次一级基于数据库或者业务来做数据的异地灾备，这样成本会下降一个数据量级。

感谢楼上大师的回复，这么看来，常规的建议还是通过虚拟化设备，进行存储容灾的部署，而考虑到性能方面，还是尽量考虑所有的数据I/O在单个数据中心进行处理，以达到较为合适的使用场景，

灾备端如果需要使用，可以采用快照方式，进行非实时数据的查询采集