那么如何保证仲裁机制及策略的一致性？
建设双活数据中心，我且将双活数据中心定义如下：
应用层面：同一个业务请求可以同时进入两个数据中心。
数据层面：应用服务器可以同时在两个数据中心进行写入操作。
存储层面：双数据中心的存储实时保持同步。
技术难点：
如果站点间发生链路中断或者是站点级别灾难，那么数据库集群、存储底层以及应用，负载均衡设备等等都会存在一个仲裁问题，那么如何保证仲裁机制及策略的一致性？
4同行回答
- 多谢您的回答！ 如果数据库先发生仲裁，存储后发生仲裁，这种情况下有没有可能发生这样的场景，数据库认为A中心节点可用。而存储恰恰认为B中心节点可用。他们彼此孤立，最终的结果数据库节点全部宕机。
- 没太明白楼主意思。数据库和存储都有各自的仲裁，如果发生脑裂后两个集群仲裁结果不一致则可以tivoli配置脚本保证不会出现一边存储集群活着而另一边数据库集群活着的情况，db2 purescale就是这么弄的，之后应该有人工办法将集群在一边起起来
- 我理解的数据库的双活和存储层的双活，都必须要保障数据的任何节点都要正度访问存储的任意节点，也就是不会出现像你说的数据库A站点不能访问存储B节点，而导致数据库节点的宕机
- 双中心之间的光纤链路完全断裂，挖土机一铲子下去，两根光纤全断了。
- 求求各位大神解决吧，呵呵
测试过oracle extended rac on vplex。
vplex 分有无witness，在oracle心跳断掉（磁盘都可读写）的情况下一般是inst_id小的实例存活，只要vplex的winner设置和oracle一致，没有问题。
oracle心跳断开，两站点vplex站点也断开，两个站点都可以起来，但实际已经是两个单独的数据库，这点需要注意。收起
vplex 分有无witness，在oracle心跳断掉（磁盘都可读写）的情况下一般是inst_id小的实例存活，只要vplex的winner设置和oracle一致，没有问题。
oracle心跳断开，两站点vplex站点也断开，两个站点都可以起来，但实际已经是两个单独的数据库，这点需要注意。收起
浏览2221