【集群仲裁一致性】存储跨中心双活集群的仲裁如何和上层数据库集群的仲裁结果保持一致？

跨中心的集群仲裁也就是当两个数据中心间的所有链路都中断时，双活集群的仲裁机制，这里的双活集群可能不只是存储双活集群，也有可能包含了数据库的双活集群、并行文件系统的双活集群，甚至一些特殊应用的双活集群等。这多类双活集群在链路发生中断时，都将按照各自的集群的仲裁算法，投票选举出存活节点，倘若这多个集群的仲裁结果不是一致的，将可能会给业务系统带来灾难性的影响。这里拿存储和数据库双活举例：
存储双活集群的仲裁通常规则有两种：
1.偏好模式
偏好模式的意思就是说，按照系统或者用户的偏好，特定选择一个优先存活的站点，在发生链路中断（脑裂）时，这个站点继续存活，并拥有接管IO读写的优先权。比如说SVC的配置节点、VPLEX的分离规则或者SRDF/METRO的ACTIVE BIAS配置选项等。
2.第三仲裁站点仲裁模式
第三仲裁站点，顾名思义，也就是在除了两个双活的数据中心之外的另一个站点，来对这两个数据中心进行仲裁和选举，防范脑裂。
详细可见：脑裂风险防范
这两种模式通常都是配合起作用的，优先第二种模式。
数据库双活集群的仲裁规则有：
1.磁盘仲裁，拥有磁盘心跳的节点存活
2.节点数仲裁，站点节点数多的存活
3.磁盘和节点的共同仲裁，获得磁盘心跳，并且存活站点节点数+磁盘心跳数大于非存活站点节点数
4.IP地址最大或者最小者存活
5.实例号最小或者最大者存活
因数据库的不同，仲裁规则的算法也不同，但是大多数都会选择磁盘和节点的共同仲裁的方式作为优先的方式。
那么数据库双活和存储双活集群的仲裁一致性是如何做到的呢？
这里以EXTEND ORACLE RAC数据库跨中心双活集群和VPLEX METRO存储跨中心双活集群举例说明：
EXTEND Oracle RAC的部署重点介绍OracleClusterware仲裁文件和Witness第三个站点。也就是说，在采用VPLEX Metro的远距离群集中，Oracle RAC仍需使用Oracle Clusterware仲裁磁盘。但是，群集仲裁磁盘本身驻留在VPLEX虚拟卷上。这可以保证Oracle仲裁磁盘访问Oracle RAC的行为和 VPLEX Metro故障切换行为一致。借助VPLEX，仅VPLEX Witness部署在第三个站点
1.如果只有Oracle互连链路中断（不是真正的站点故障，且不影响 VPLEX 互连），则 Oracle Clusterware将根据多数节点及仲裁磁盘访问进行重新配置。
2.如果是VPLEX互连链路中断（或真正的站点故障），VPLEX将根据站点分离规则的首选项和Cluster Witness指导，立即允许IO在一个群集恢复。因此，仅当VPLEX恢复仲裁磁盘上的I/O时，这些 Oracle 群集节点才有权访问这些仲裁磁盘；而且Oracle Clusterware将相应地重新配置群集。尽管仍需要仲裁磁盘，但无需部署在独立的第3个站点中，因为VPLEX Witness可提供Split-Brain保护并保证Metro 和Oracle Clusterware的行为一致。此外，由于VPLEX Witness控制仲裁文件的访问，因此可跨独立Oracle RAC部署和相关上游用户应用程序保证一致的确定性行为。

1、没有做过跨中心，包含业务和存储双活的实际案例，
2、愚见：存储双活出现问题主要故障场景是网络/硬件，业务双活主要故障场景应该是网络/硬件/软件，针对网络故障，把2个仲裁放在一台设备上就可以解决，比如HyperSwap的JAR和Oracle的iSCSI vote；存储硬件/业务软硬件因为内部结构的不开放性，暂时未听说有比较全面集成解决方案，这个时候或许可以考虑只用一个仲裁，比如Oracle RAC，底层不做存储双活改用fg来做冗余，配置FG的优先本地读取来提高性能。边缘应用也可以考虑使用VMWare Metro Storage Cluster 来做容灾，存储只需要做复制即可。

这个是个非常重要的关键点。实现的方法也很简单粗暴，就是上层集群的仲裁确定时间放的比下层存储集群的仲裁确定时间长。这样能保证上层集群不在下层集群之前做决定。这个在oracle rac和db2 purescale里面官方都这么干的。

双活的站点存活，从技术角度看，要根据当时谁抢占到第3站点仲裁来决定谁能存活。即，每个站点都有50%的机会。
但结合数据库，尤其是Extended RAC，要结合Oracle脑裂规则来进行相应设计。通俗的说，就是要跟Oracle RAC的脑裂机制保持一致性，确认大家都押宝在同一个方向上。在中间链路故障导致脑裂出现时，RAC选择在实例ID小的一边活。此时，押宝在ID小的站点即可。风险就是ID小的站点挂了，另外一个站点需要人为的做恢复。