存储双活架构设计规范.docx

存储双活架构设计规范

我们知道，对于容灾架构来讲，脑裂是灾难性的事件。如果从一个统一集群的调度变成两个相互独立的集群调度，意味着双方的写操作相互也是独立的，但是他们的存储空间是共享的，AA模式下通过锁机制控制并发，HA模式下通过存储卷的Owner控制写的权限。但是独立之后意味着两个集群可以随时写入同样的存储地址，必然会造成脏写脏读等一系列数据不一致事件，这对业务来讲是灾难性的。那么存储双活架构的设计当中，应该采用什么样的设计思路或者是方法才能避免这种情况的发生？

四：
为避免脑裂，存储双活架构设计应遵循哪些思想和方法？
本次议题将由本人以及江西农信运维技术经理邓毓、哈尔滨银行系统专家团队存储管理员张鹏分别主张议题下的相关关键点，几位专家的主张在某农信资深技术经理雷智、宁夏银行技术经理陈明福的复议后，最终形成一定的共识供同行参考。
●社区专家主张●

赵海 某金融系统高级主管：
每一种集群都会有相应的解决方法，通常可以通过节点优先级及仲裁的方式来解决，但是我们在利用这些策略进行架构设计的时候必须知道其原理以及最佳实践的方法。

容灾设计过程中避免脑裂问题的思路
§ 默认优先级解决方案
以两个节点的Oracle RAC为例来讲，OracleRAC ASM管理模式下，磁盘组通常有三个（+DATA，+FRA，+OCR），在OCR磁盘组当中所有的磁盘中存储的数据包括两部分，一部分是Vote File，另外一部分就是OCR（Oracle ClusterRegistry）。Vote File是用来记录集群节点的磁盘心跳信息，而OCR是保存集群配置信息的数据。Vote File，以整个文件的方式存储在OCR磁盘上，不做任何条带。表1是其信息记录的一个说明。
表 1 Oracle 仲裁逻辑信息
表1是一个三节点的Oracle RAC集群的VoteFile的一个示意矩阵，每一行是一个节点的写入的信息，例如第一行，Instance1分别把其对集群中的三个成员（1、2、3）进行私网检测的结果写入到仲裁文件当中，Instance2、Instance3同样把其检测结果写入仲裁文件，最终组成了三个节点的仲裁矩阵。当私网发生故障导致网络上导致集群分割为几个孤岛子集的时候，在网络心跳同票数情况下，仲裁算法有两个非常重要的规则：
一、保障隔离后的集群子集中节点数目最多的子集存活。
二、当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。
当两个节点的Oracle RAC集群面临私网故障的时候，必然会遵循以上规则，从规则内容上可以看出，第一条规则基本没有什么意义，双方的资源是对等的；但是第二条规则直接决定了集群的最终状态，那就是实例号小的节点成为新的集群，这就避免了脑裂的存在。
§ 资源失衡配置解决方案
所谓资源失衡配置解决方案，就是要在容灾设计之初就保障主数据中心的资源配置要多于灾备中心，从而使得两个数据中心节点可以获取到的仲裁资源处于不平衡状态。

图1 资源失衡架构
如图1所示，容灾设计的时候可以将主备数据中心的节点分布数量或者仲裁文件分布数量按照2:1的非平衡策略设置。那么按照集群仲裁的一般规则：发生集群分裂故障的时候，可以获得更多仲裁资源的子集将成为新的集群。当发生数据中心之间的网络故障的时候：
1）主数据中心内部两个节点可以获取到更多的网络心跳，自然会接管集群。
2）主数据中心的节点可以获取到更多的磁盘心跳，同样会接管集群。
这也符合我们设计之初衷。但是，这种方法只适合于AA模式的多节点集群，不适合HA模式的架构。
§ 自定义优先级解决方案
自定义优先级的解决方案，其实本质上与Oracle RAC的仲裁算法第二条“当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。”是一样的。只不过对于Oracle RAC，当通过第一条规则无法判断的时候（节点获取的仲裁资源矩阵是平衡的），它默认采用了实例号定义其优先级。

图2 自定义优先级架构
而其他的一些容灾方案，这个优先级定义的灵活性留给了客户。例如图2当中的VPLEX产品，尤其是在双活架构的设计当中，有可能因为地域、设备新旧、运营管理等方面的差异，导致灾备中心的运行能力会稍差，那么发生数据中心之间隔离的这种故障时，大家往往希望保留主数据中心的运行。这个时候客户就可以根据主数据中心的节点标识来固定其仲裁优先级。
§ 仲裁解决方案
o 网络仲裁
网络资源是集群仲裁当中非常重要的一种心跳资源，因此通过第三方网络资源的可达性心跳信息来判断对称集群分裂后的新秩序也是一种非常有效的方法。一般在以存储网关实现数据双写的容灾架构当中比较常见，比如VPLEX、SVC、MCC等。具体原理如图3所示：

图3 三方网络仲裁架构
第三方仲裁点需要满足的条件：与主备两个数据中心L3可达，并且网络质量稳定。
仲裁点一般需要安装具备网络探测功能的虚拟服务器或者物理服务器，具备运行条件。
如图3所示，仲裁点服务器上的软件会与组成集群的存储器网关两个节点分别发送PING/ACK来确认双方的健康情况，集群会把两个节点与第三方仲裁点的网络仲裁心跳看做是最终的裁判。Vplex Witness 通过管理 IP 网络连接至两个集群节点，通过将其自身的观察与集群定期报告的信息进行协调，让集群可区分是集群内故障还是集群间链路故障，并在这些情况下自动继续相应站点上的 I/O 服务。Vplex Witness 仅当分离规则没有定义时才会生效。当然细心的读者可能产生了一个新的问题：

如果数据中心与第三仲裁站点的网络发生故障，那会不会影响集群本身的运行？

什么是仲裁？仲裁是只有发生集群隔离故障的时候才会起作用，如果没有发生数据中心之间的隔离故障的时候，即使他们的一方或者双方于第三方仲裁站点发生网络暂时中断的事件，也不会对既有集群造成任何健康影响。我们需要做的是保障第三方仲裁资源在发生故障的时候有效就可以了（监控&及时修复）。
o 存储仲裁
存储一般是数据库集群当中非常关键的仲裁资源，数据库集群的节点负载比较重，不像存储网关模式的集群，可以再设计与WitnessNode的通讯接口。所以在这类技术方案的容灾设计当中，通常会用第三方存储阵列来作为集群的第三方仲裁点。例如Oracle Extended RAC、HA&Oracle、HA&DB2等。具体原理如图4所示：

图4 三方存储仲裁架构
1）第三方站点放置一个存储阵列、并且与两个数据中心网络稳定可达。
2）存储阵列以NFS或者ISCSI方式提供共享存储卷或文件服务给两个中心的集群节点。
3）集群配置的时候，将这个共享存储卷或者文件作为集群的磁盘仲裁之一。
当双中心的集群发生隔离故障的时候，集群通过第三方的仲裁磁盘或者文件来判断集群的新秩序。
o 对称隔离场景
集群发生的故障场景有很多，有可能是网卡故障导致节点隔离，也有可能是链路问题导致节点隔离。链路问题本身又分很多种，有一种场景即使存在第三仲裁的场景下，依然有可能是对称平衡的状态。如图5所示：

图5 对称隔离架构
如图5所示，当两个中心之间的链路中断，但是其他各条线路都完好无损的情况下，及时存在第三方仲裁，那么集群分裂后的仲裁资源分布依然是平衡对称的，这又该如何解决呢？
一般认为有两种解决方式：
1）优先级定义解决方案，也就是说我们在第二节提到的解决方案必须成为容灾设计的必选项。
2）仲裁争夺方案，无论是三方的网络仲裁还是存储仲裁，假设出现集群隔离故障后各个节点开始争夺这个资源，那么必然有先后顺序之分，以先到先得的规则来重新定义集群新秩序。这种方案尤其适用于以HA模式的容灾架构。当然具体如何争夺，如何确认争夺维度及结果就需要根据不同产品架构来探讨了。
§ 仲裁冲突解决方案
o 什么是仲裁冲突？
我们知道在容灾整体设计当中，需要有网络层、计算层、数据库服务层、存储服务层等各方面的设计。
他们在纵向上是叠加的形态，如图6所示。

图6 仲裁冲突示意图
图6是我们将容灾设计当中纵向抽象出来的几个功能层，其中数据跨中心复制是实现双活容灾的前提条件，它是支撑网络及计算层具备容灾意义的基础，那么如何实现数据复制，我们在《企业容灾选型指南 - 2：数据复制技术》当中介绍了很多方法，基本上集中在数据库层和存储层去实现。假设我们采用了存储层的数据复制技术，存储层提供的虚拟分布式卷对于数据库集群来讲是透明的。

当数据中心之间发生线路故障的时候，数据库集群和存储网关组成的集群是两个不同的集群，他们的仲裁结果会不会不一致？

集群的仲裁是瞬间完成的，其触发条件有可能有片刻的先后顺序之差。数据库层的仲裁先于存储层的仲裁，那么虽然概率小，但是这个冲突是完全有可能的。但是如果存储的仲裁发生在数据库之前，理论上这个冲突是可以避免的，因为存储卷是数据库集群健康运行的前提。
如何解决仲裁冲突问题？
以Oracle RAC和VPLEX结合的架构为例，我们探讨它的解决方法。
风险发生的引发点有两个：
1）集群的仲裁触发条件导致的仲裁顺序发生紊乱；
2）对称平衡状态下的仲裁规则冲突。
资源被1:1割裂之后的默认仲裁策略不一致。也就是说，只要控制这两个引发点，这个问题从理论上也就避免了。对于第一个引发点来讲，实际上存储集群的默认仲裁触发时间会是15秒左右，而数据库仲裁触发的控制参数由misscount这个参数来决定，所以我们只要将misscount这个参数调整到15秒之后，也就是说理论上绝对保障存储集群仲裁在前，数据库仲裁在后，那么第1个引发点就没有了。对于第二个引发点来讲，假设两站点节点资源对等，仲裁选票同样对等的情况下，存储集群会有一个默认的Winner策略，同样在这种情况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要我们保证这两个策略结果的一致性，那么第2个引发点也就不存在了。

邓毓 江西农信运维技术经理：
为防止脑裂发生给企业生产业务带来重大影响，存储跨中心双活方案设计的架构设计和解决思路必须两面抓，一面是“防”，一面是“解”。

存储双活模式下，脑裂问题简单说就是两个数据中心间的网络和存储链路同时发生中断，导致两个数据中心内的应用、数据库或者操作系统同时抢占和利用共享的资源，造成资源的数据不一致，产生重大影响。这个问题是在存储跨中心双活方案设计、实施阶段不可避免要遇到的。遇到该类问题时，通常的架构设计和解决思路有两个方面，一方面是“防”，另一方面是“解”。“防”主要是防止脑裂问题的发生，防止两个数据中心间链路全部中断，将产生脑裂问题的根源掐断。在故障场景下，只要两个数据中心间能够存在链路通讯，就不会有进一步的脑裂问题产生。“解”主要是解决脑裂问题的发生，利用合理、充分的仲裁机制，以极短的故障恢复时间和几乎为零的故障恢复目标，解决脑裂故障灾难。
“防”方面：
1）增加链路冗余度：存储双活模式通常是企业自己购买波分设备，然后租用运营商的裸光纤作为通讯的链路。所以波分设备需要冗余，裸光纤也要冗余。对于波分设备购买即可。裸光纤通常租用两家或两家以上的运营商线路，比如电信和联通。电信的裸光纤也需要冗余，联通的裸光纤也需要冗余，防止单根裸光纤意外割断或者损坏。然而单家运营商的裸纤都通常在一个弱点井中，一起意外割断的事情常有，所以需要两家运营商互相冗余。这两家运营商裸纤的路线还不能一致，弱电井需要在不同的街道，并且分别走不同的路线到达目的地。
2）增强链路监测：对于链路的监测机制一定要在建设存储双活之前建立。由于通常是租用运营商的链路，链路经过了多少中继、多少设备企业是不得知的，企业只能在波分端建立有效的监测机制，有些波分设备也有专门的监控软件支持。而且也要求和运营商建立监测联动机制，运营商监测到链路质量有问题，需要第一时间告知企业，再做出合理的决策。
“解”方面：
在存储双活方案中，防范脑裂通用的做法就是使用仲裁机制，在第三站点放置仲裁服务器或者仲裁存储阵列。通常有以下四种方式：
1）优先级站点方式。这种方式最简单，在没有第三方站点的情况下使用，在发生链路中断脑裂现象时，从两个站点中选一个优先站点，发生脑裂后优先站点仲裁成功，既强制使优先的存储节点继续提供服务。但如集群发生脑裂后，优先站点也发生故障，则会导致业务全部中断，因此这种方案并非推荐的方案。
2）软件仲裁方式。这种方式应用比较普遍，在有第三方站点的情况下使用，采用专门的仲裁软件来实现，仲裁软件放在第三站点，可以跑在物理服务器或虚拟机上，甚至可以部署到公有云上，在发生链路中断脑裂现象时，仲裁软件节点和双活的存储节点一道选举出存活的存储节点继续提供服务。
3）阵列仲裁盘方式。这种方式应用于部分存储双活方案，该方式是在第三站点采用另外一台阵列创建仲裁盘，在发生链路中断脑裂现象时，仲裁磁盘和双活的存储节点一道选举出存活的存储节点继续提供服务。这种方式稳定性、可靠性比较高。
4）双仲裁方式。少部分存储双活方案支持，该方式可同时设置优先级站点和软件仲裁/阵列仲裁盘方式，实现双仲裁保护能力，最大限度保障存储双活方案的高可用。部分方案还支持按双活Pair或双活一致性组（多对双活Pair）为单位进行仲裁，仲裁精细度高，通常可配置以业务为粒度进行仲裁（双活一致性组）。仲裁之后，业务均衡分布访问两个存储，实现站点间链路故障时，主机就近访问。

张鹏 哈尔滨银行系统专家团队存储管理员：
在存储双活容灾系统中，发生脑裂的根本原因是双系统之间心跳中断，导致资源抢占影响数据一致性。为防止脑裂的产生，通常需要在容灾系统中增加仲裁软件对两端阵列系统进行仲裁，一旦出现任一数据中心整体故障或阵列间链路故障时，阵列向仲裁服务器发起仲裁请求，由仲裁服务器综合判断哪端获胜。仲裁获胜的一方继续提供服务，另一方停止服务，由此防止了脑裂现象的产生。

双活系统的仲裁方案主要分如下三种场景模式。
静态优先级模式场景：
用户在未配置仲裁服务器或仲裁服务器无法访问时，双活仲裁模式为静态优先级模式，双活Pair发生仲裁时优先站点端获得仲裁并提供业务。
1） 当存储系统间链路故障（如图7）
双活Pair为待同步状态，经过仲裁，设置的优先站点数据中心A的LUN继续运行业务，非优先站点数据中心B的LUN停止运行业务。

图7 存储间链路故障
2） 当非优先站点数据中心B故障（如图8）
双活Pair为待同步状态，经过仲裁，设置的优先站点数据中心A的LUN继续运行业务，非优先站点数据中心B的LUN停止运行业务。

图8 非优先站点数据中心B故障
3） 当优先站点数据中心A故障（如图9）
双活Pair为待同步状态，数据中心A的LUN无法访问、数据中心B的LUN停止运行业务。此时，非优先站点不能自动接管双活业务，双活业务停止，需要人工强制启动非优先站点双活业务。

图9 优先站点数据中心A故障
单仲裁服务器场景：
仲裁服务器模式下，一旦出现任一数据中心整体故障或阵列间链路故障时，阵列向仲裁服务器发起仲裁请求，由仲裁服务器综合判断哪端获胜，仲裁获胜的一方继续提供服务，另一方停止服务，仲裁服务器模式下优先站点会优先获得仲裁胜利。
1）当存储系统间链路故障（如图10）
双活Pair为待同步状态，优先站点数据中心A的LUN继续运行业务，非优先站点数据中心B的LUN停止业务。

图10 单仲裁存储间链路故障
2）当优先站点数据中心A的存储系统故障（如图11）
双活Pair为待同步状态，优先站点数据中心A的LUN失效、数据中心B的LUN继续运行业务。

图11 单仲裁优先站点数据中心A故障
3）当仲裁服务器故障时，存储系统间复制链路同时故障（如图12）
双活Pair为待同步状态，此时仲裁服务器无法执行仲裁判断，无法决策优先站点，数据中心A的LUN与数据中心B的LUN均停止业务。

图12 单仲裁故障+存储间链路故障
仲裁站点配置两台仲裁服务器时，如果主仲裁服务器到两端阵列之间所有链路断开，且备仲裁服务器与两端阵列连接正常、双活站点间链路也正常时，系统在主仲裁故障后1分钟内自动切换到备仲裁服务器，由备仲裁服务器来执行仲裁功能。
1）一台存储系统与对端存储系统、仲裁服务器之间的链路同时故障（如图13）
双活Pair为待同步状态，主仲裁服务器继续工作，数据中心A的LUN停止业务、数据中心B的LUN继续运行业务。

图13 双仲裁主仲裁A中心链路故障+存储间链路故障
2）一台存储系统故障，且对端存储系统与主仲裁服务器链路故障（如图14）
当存储系统先故障，仲裁链路后故障：
• 当故障间隔时间60秒以内（包括60秒），主仲裁服务器继续工作，数据中心A的LUN无法访问、数据中心B的LUN可能停止运行业务。
• 当故障间隔时间60秒以上 ，主仲裁服务器继续工作，数据中心A的LUN无法访问、数据中心B的LUN继续运行业务。
当仲裁链路先故障，存储系统后故障：
• 主仲裁服务器继续工作，数据中心A的LUN无法访问、数据中心B的LUN停止运行业务。

图14 双仲裁主仲裁B中心链路故障+A中心故障
3）当主仲裁服务器与优先站点（数据中心A）的链路故障，备仲裁服务器到非优先站点（数据中心B）的链路故障，以及存储设备间的链路故障同时发生（如图15）
双活Pair为待同步状态，主仲裁服务器继续工作，数据中心A的LUN停止运行业务，数据中心B的LUN继续运行业务。

图15 双仲裁主仲裁A中心链路故障+备仲裁B中心链路故障+存储间链路故障
4）当主仲裁服务器与非优先站点（数据中心B）的链路故障，备仲裁服务器到优先站点（数据中心A）的链路故障，及存储设备间的链路故障同时故障（如图16）
双活Pair为待同步状态，主仲裁服务器继续工作，数据中心A的LUN继续运行业务，数据中心B的LUN停止运行业务。

图16 双仲裁主仲裁B中心链路故障+备仲裁A中心链路故障+存储间链路故障
5）当主仲裁服务器故障后，存储系统间链路也发生故障（如图17）
双活Pair为待同步状态，仲裁服务器根据两故障间隔时间，有两种结果。
仲裁结果1：当发生主仲裁服务器故障和存储系统间链路故障，且两个故障之间的时间间隔60秒以上时，备仲裁服务器接替主仲裁服务器继续工作。数据中心A通过备仲裁服务器仲裁获胜，数据中心A的LUN继续运行业务，数据中心B的LUN停止业务。
仲裁结果2：当发生主仲裁服务器故障和存储系统间链路故障，且两个故障之间的时间间隔60秒以内（包括60秒）时，备仲裁服务器无法接替主仲裁服务器继续工作。数据中心A及数据中心B的LUN均停止业务。

图17 双仲裁主仲裁故障+存储间链路故障

张鹏 哈尔滨银行系统专家团队存储管理员：
当两个数据中心之间的链路故障或其中一个数据中心故障时，两个数据中心之间无法实时同步，此时只能由双活Pair或双活一致性组中的一端继续提供服务。为了保证数据一致性，双活需通过仲裁机制来决定数据中心的服务优先级。

仲裁方案主要分两种：
1）静态优先级模式：双活Pair中设置为优先站点的站点故障时，非优先站点不能自动接管双活业务，双活业务停止，需要人工强制启动非优先站点双活业务。
2）仲裁服务器模式：仲裁服务器模式下，一旦出现任一数据中心整体故障或阵列间链路故障时，阵列向仲裁服务器发起仲裁请求，由仲裁服务器综合判断哪端获胜。仲裁获胜的一方继续提供服务，另一方停止服务。
仲裁监控目标和参数：
1） 仲裁服务器业务IP配置正确，防火墙端口号（30002）正确打开。
2） 仲裁服务器上的白名单配置正确（默认安全策略下可不检查）。
3） 存储系统用于和仲裁服务器连接的端口已经配置好IP地址，并且和仲裁服务器的业务IP能相互ping通。
4） 本端存储系统及远端存储系统执行完创建仲裁服务器的操作后，登录仲裁服务器运行show server_ip命令查看查看本端和远端存储设备的状态是否为“Established”。
“脑裂”问题应急处置手段：
仲裁服务器无法访问时，双活仲裁模式为静态优先级模式，双活Pair发生仲裁时优先站点端获得仲裁并提供业务。

结束语
为避免脑裂问题，本议题针对架构设计时应遵循的理念和方法提供了一些共识供同行参考，但脑裂问题依然会是IT界经久不衰的话题。该议题希望更多的同行可以持续贡献思想和方法。
-全文完-