【存储双活集群保护】存储双活通常是作为一个集群的存储，如何对这个双活集群进一步保护？

有些存储跨中心双活方案是通过镜像复制技术（VDM、MetroSync、SyncMirror、TrueCopy等）将底层两个存储虚拟成一个虚拟卷，再挂载给上层的主机，由于这个卷是虚拟的卷，底层存储有可能无法脱离这个虚拟化（集群）而单独挂载给主机使用，所以这个虚拟化（集群）软件的可靠性和稳定性就变得非常重要了，如果出现重大软件BUG或者这个集群的所有节点先后故障，就将造成数据丢失的重大风险。当然这种问题出现十分罕见，但对于数据的安全性，是企业最为重要的资产，是企业的生命，所以我们也不能大意，依旧需要一套完善的集群保障体系和数据保障体系。

通常可以把这种双活集群的保护分为三种：

一种是虚拟化网关+底层存储的复制技术

通过虚拟化网关实现的存储双活，虚拟化网关的集群保护就需要靠虚拟化网关自身自带的数据保护体系，或者底层存储的数据保护体系，比如说SVC ESC是基于VDM的复制技术实现的双活，再配备SVC METRO MIRRO或者GLOBAL MIRROR实现两地三种的数据级容灾，当SVC ESC的双活集群完全不可用时，可以将SVC切至容灾端就行数据的恢复，保障数据的安全。又如VPLEX METRO或者VPLEX GEO双活，由于这套架构本身就是两套集群，两套集群同时故障的可能性更小，几乎不需要再对VPLEX METRO再做集群的保护，如果要做异地的话，可以通过VPLEX底层的存储，比如EMC VMAX的SRDF再做一份数据至同城或者异地容灾端，或者DS8000系列的MM或者GM再做一份数据至同城或者异地。前面SVC ESC的容灾保护体系适合所有的高中低端存储，直接通过SVC的容灾技术就实现了两地三中心+存储同城双活，而后面的VPLEX要实现集群的进一步保护，需要底层高端存储的同步复制技术的支持。

第二种是底层存储复制技术

直接通过底层存储控制器实现的双活，是需要专有存储或者高端存储的支持，再进一步实现两地三中心整体架构，也是需要在原有双活复制技术之上，将数据异步扩展至异地，或者支持多份数据同步技术。

第三种是上层应用/数据库的复制技术

对于这种方式的保护也是非常多案例的，既起到从数据库事物层方式起到数据逻辑性保护的目的，又达到了对双活集群的容灾目的，像DB2 HADR和ORACLE ADG超异步，ORACLE的far sync复制已经支持跨超远距离的异步复制了。

比较好的办法是双活数据中心上的应用或数据库做应用层的复制到远端数据中心。通常双活方案+异步容灾，只能保证底层数据块层的一致性，无法确保应用数据是否可用，数据库是否可回滚。
对于双活的方案，带来的好处是显而易见的。但是微码故障，不会因为是一个集群模式或两个集群模式而降低微码风险。远有北美大型客户的Metro集群同样由于微码原因一起趴下，近也有国内南方某银行非核心系统同样出现类似问题。

一般来说，集群出现问题，不会影响数据的安全，但是会影响业务。如果你想对数据在存储双活的层面再保护一次，那要看你采用了系统层、存储虚拟化层、存储底层等那种双活技术，每种技术都有缺陷，没有完美的技术，如果是那样，技术就不会发展，所以这要看你采用了何种层面技术，然后综合评估性能、成本，最后考虑数据保护技术，技术永远都不是问题，问题是money 和必要性。

这类集群软件重大故障，大多由数据中心之间通讯链路不稳定、第三方仲裁站点失效、存储上层数据同步逻辑错误等问题引发。因此，可以考虑如何通过相关手段防范这几点隐患。如对通讯链路进行实施监控，做好主备管理，防止链路抖动等。

存储双活的集群如果担心集群整体失效，需要一个保护机制的话，在我看来有两种方式。一个是存储上再做灾备，复制出一份非活的拷贝。一种是跳出存储层，利用数据库，中间件，或者第三方软件技术对数据进行逻辑复制到异地。