如何设计应用和数据的双活，需要考虑那些关键点？

2.2 架构中关键问题及解决方案
2.2.1集群仲裁一致性问题
问题描述
所谓的仲裁一致性问题，是指双中心之间的VPlex存储集群和数据库RAC集群的仲裁结果是否能保证一致性。VPlex集群是靠仲裁站点分别于两个站点之间的网络连通性来判定站点故障。而数据库集群是通过以太网心跳和OCR仲裁盘来做数据库仲裁。而数据库的OCR仲裁盘是存储集群提供的分布式共享卷。二者仲裁时的一致性如何保障是非常重要的一个问题。假设在发生站点级别故障时，数据库集群首先根据网络故障触发仲裁，判定站点A的节点存活。而存储随后再发生存储集群的仲裁，这个时候如果根据Witness判定的结果恰恰仲裁委站点B的节点存活。那么数据库集群整体就会宕掉，这对于业务来讲就是一个灾难。

解决方案
在这个问题上，风险发生的引发点有两个：数据库和集群的仲裁触发以及仲裁过程的时间顺序发生紊乱；资源被1:1割裂之后的默认仲裁策略不一致。也就是说，只要控制这两个引发点，那么这个问题从理论上也就避免了。对于第一个引发点来讲，实际上存储集群的默认仲裁触发时间会是15秒左右，而数据库仲裁触发的控制参数由misscount这个参数来决定，所以只要我们将misscount这个参数调整到45秒之后，也就是说理论上绝对保障存储集群仲裁在前，而数据库仲裁在后，那么第一个引发点就没有了。对于第二个引发点来讲，假设两站点节点资源对等，仲裁选票同样对等的情况下，存储集群会有一个默认的Winner策略，同样在这种情况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要我们保证这两个策略结果的一致性，那么第二个引发点也就不存在了。

2.2.2双中心间通讯不可控
问题描述
双中心间的通讯不可控问题主要表现为两个方面：链路稳定状况不可控；IO延时指标不可控。因为双中心之间的链路是通过租用运营商的裸光纤链路实现的，那么这其中会经历很多的中继设备及节点。无论从管理上还是从技术把控上都是金融企业自身不可控制的因素。假设双中心间链路延时指标不稳定，也就是说数据库节点之间私网传输的延时会经常出现长延时情况，这势必导致这种延时会加倍放大到数据库节点之间的读写热点竞争上。由于数据库集群之间的数据传输量非常大（缓存、锁、心跳等），在读写热点相对突出的业务上，轻则导致数据库读写性能灾难，重则导致数据库节点直接处于僵死状态。另外，链路的不稳定会导致存储链路频繁切换，甚至会导致集群仲裁频繁发生，这对于业务连续性更是一个灾难。

解决方案
对于这个问题来讲，就目前金融行业的传统数据架构来讲，并没有一个十足的解决方案。我们只能通过以下措施来减少这种问题带给我们的风险。
一、业务层面需要进行拆分重组：按照IO特点进行合理拆分，将读写业务尽量分布于不同节点上，减少节点间的锁竞争。按照业务将数据库表进行分区，避免在数据库写上的数据热点块儿。例如，对于银行核心系统来讲，尤其是要将批量业务和联机业务区分对待，批量业务的热点以及数据量非常之巨大，所以一定要将批量业务的数据库读写放在单边实现。对于联机业务来讲可以根据热点状况以及链路质量评测结果可以尝试实现双中心同时读写，但是本文建议对于这种重量级的业务还是要从业务层尽量实现应用上的读写分离，或者在应用层双中心部署而在数据库层将数据引到单边来做。
二、双中心间通讯的整体控制，具体包括对通讯带宽的优先级管理、对通讯的实时监控和控制、对跨中心数据传输的严格策略把控。例如：优先保障存储和数据库通讯的优先级和带宽，严格的规则算法和优先级限定VMOTION、DRS等行为的跨中心随意性，从LTM负载分发上尽可能保障正常情况下纵向IO的单中心效率策略，故障情况下保障跨中心访问的科学性。DWDM上设置双中心间通讯带宽的逻辑隔离以及实时可控。

2.2.3数据同步逻辑错误问题
问题描述
存储层面的复制技术基本以存储块儿为单位进行的数据复制，对于块儿内数据的应用层面的逻辑错误是没有完整校验的，它只保证存储块儿的可用性，这个可用性仅仅保障存储层面的卷可用，并不能完全保证应用层面的数据可用性。假设数据块发生了逻辑错误，那么存储是无法检测到的，它会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。

解决方案
对于这个问题发生的概率是非常低的，但是毕竟存在这个风险，解决这个问题的方法就是对于重要数据增加数据库层面的数据复制方案，比如ORACLE的ADG，比如DB2的HADR。当然这个可能会带来一些功能上的重复，因为无论是存储复制还是数据库复制，其实都是数据保障的手段。但是存储的复制解决的问题不仅仅是数据库层的数据保护，所以在基础架构中的角色，他还是不能丢弃的。

2.2.4跨中心集群会话同步问题
问题描述
网络二层打通的情况下，GTM和LTM的跨数据中心集群就成为可能，但是同时也带来一个问题，那就是会话的跨中心同步问题。毕竟跨地域的集群节点之间会话同步会受到距离延时等多方面影响，而这个会话同步又是应用负载集群中很重要的一个稳定性因素。如果LTM或者GTM的节点之间的会话不同步，那么最终会导致应用负载在故障情况下无法正常切换。

解决方案
对于这个问题来讲，本案例采用的是中心内双节点小集群，然后利用GTM解析的全局性来完成应用负载功能的全局性。假设单中心内LTM集群发生故障时，我们完全可以利用GTM和LTM的联动性来感知到这一故障，而从GTM解析层面将数据流引入另外一个数据中心的LTM集群。功能上，这种模式同样实现应用负载的全局性，同时又避免了双中心LTM节点会话不一致的问题。

2.2.5存储网络故障泛滥问题
问题描述
如果我们把两个中心的SAN环境整合为一张大网，物理上没有任何隔离的大网，那么可能会因为局部的存储网络故障而波及到整个存储网络。尽管我们通过SAN交换机上的逻辑隔离能够解决大部分的安全问题，但是这样的风险毕竟还是存在的。

解决方案
本案例通过对数据中心内部SAN环境前后物理隔离，双中心之间靠专一SAN交换机实现存储后端网络的联通来解决该问题。这样的话，单中心内前段SAN环境故障不会波及存储后端，更不会波及整个基础架构的存储网络。

谢谢赵经理解答，‘’定站点A的节点存活。而存储随后再发生存储集群的仲裁，这个时候如果根据Witness判定的结果恰恰仲裁委站点B的节点存活。那么数据库集群整体就会宕掉，这对于业务来讲就是一个灾难。‘’，vplex或者其它存储网关产品，应该是将底层存储镜像了吧，san网络应该是让两边存储的盘对上层主机都可见吧，发生脑裂后A 去读取B站点的盘，数据都在吧，怎么就发生灾难了，这点不理解，请解释一下。谢谢