【脑裂风险】存储跨中心双活方案设计阶段该如何尽量避免脑裂？
如何避免脑裂是每个双机系统都要重视的问题，存储双活系统尤其如此，脑裂会带来长时间的存储读写IO HANG住，轻则导致业务性能下降，重则因磁盘IO超时，导致数据库挂起甚至宕机，对生产业务系统造成重大影响。所以在存储跨中心双活架构设计时，究竟应该如何尽量避免脑裂？...显示全部
查看其它 3 个回答haizdl的回答
其实这个问题，我觉得还是要看整体的架构是什么样的？
假设定位到存储双活，那么是不是就割裂了数据库层的仲裁问题。实际上存储最终是为上层数据库及应用服务，如果这个夸中心的架构涉及到数据库、存储两层的组合，比如说存储双活之上是oracle rac，那么就比较复杂了。
首先对于存储本身的仲裁，应该有自己的算法，例如：
1）仲裁中心
2）最坏情况下，默认的算法。
对于夸中心的rac集群，同样有自己的规则：
1）仲裁盘
2）通过网络和磁盘心跳保证获得票数最多的子集活着。
3）实例小的节点存活。
但是当二者结合的时候，就有更复杂的场景可能会出现，尤其是出现两层架构仲裁的结果不一致。
为了避免这个结果出现，那么我们需要攻克以下问题：
- 如何保障仲裁触发的时间序列一致。
- 极端情况下的仲裁算法一致性。
例如，你可以通过oracle的仲裁参数misscount结合vplex的仲裁timeout参数来保障时间序列的一致性。
例如，你也可以调整各自默认算法的最终结果落到一边。
例如，你也可以通过二次开发来实现二者的联动。
最后，所有的前提条件和策略都需要得到模拟实践的检验。