存储双活的基本架构及原理

企业容灾架构中，通过存储实现双活复制的架构相对比较常见。一般从应用访问到底层存储的纵向维度会分为网络层、应用层、数据库层、存储网关层以及存储阵列等四层关键层。谈及存储双活架构的容灾切换场景，重点关注存储网关层以及存储阵列层的分析。以存储网关模式的双活架构为例，如图1所示，通常存储双活架构由两个相距较近的数据中心（百公里以内）的存储网关层、存储层、仲裁中心以及相互之间的以太网络和存储网络组成。

图1 存储双活典型架构图

如图1所示，H1&H2表示主机节点，从主机节点到存储网关的访问路径，我们不做详细分析。

SG1&SG2表示存储网关，双中心的存储网关通过存储网络组成一组存储网关集群，提供AA服务。

SA1&SA2表示底层存储磁盘阵列，通过存储网络分别与SG1和SG2相连接。

Q表示SG1和SG2组成集群的仲裁中心，分别以以太网络与两个存储网关相连接。

存储双活架构正常读写原理分析如下：

首先，两个数据中心的主机节点将读写请求通过存储网络发送到存储网关层，两边的主机H1&H2看到的存储空间是一个经过了镜像组合的逻辑磁盘D，具体执行物理读写的时候可以通过SG1执行，也可以通过SG2执行（具体要看存储双活AA策略的粒度，以存储卷为单位还是以每次IO的BLOCK为单位）。

然后，存储网关SG1或者SG2在接收到上层应用发来的写请求之后，直接在其本地将IO镜像为两个同时进行的事务分配到SA1&SA2上，这样主机层发送到逻辑磁盘D上的单次IO在存储网关层就被复制为两个完全相同的IO，从而实现了数据的副本保护机制。

最后，待SA1&SA2两个存储阵列的缓存写完成之后，将ACK结果反馈给SG1或者SG2，当两边的ACK结果都顺利完成之后，最终宣告应用层的数据写完成。

存储双活架构下的容灾切换场景

表 1 存储双活容灾故障切换场景分析

故障仲裁机制

基于第一部分的架构图，如果C1、C2、L2-1-2、L2-2-2出现同时的故障叠加，那会出现什么样的情况？在这种情况下，存储双活架构的健壮性安全性如何考虑？事实上，故障的叠加问题一般属于二次故障，在容灾架构设计当中是不需要做考虑的。一般情况下我们只考虑一次故障，因为二次或者多次故障的场景已经超过了容灾的正常RTO&RPO技术标准约束。但是在以上问题当中所考虑的故障点比较特殊，根据常规判断来讲，如果我们双中心之间的连接完全走的是唯一路由的场景下，这几个点出现同时故障的可能性非常高。因此它也是我们在考虑双活过程当中非常重要的故障切换场景。

当C1出现故障的时候，如果是数据库双活集群（例如Oracle RAC），那么两个节点在网络上失去的仲裁资源是同等的，接下来需要判断的是双活所持存储仲裁资源的状况。但是问题来了，这个时候C2、L2-1-2、L2-2-2同时发生故障，存储层也处于需要仲裁的状态，而存储的仲裁需要根据Q的判断来完成。也就是说当仲裁中心仲裁之后，存储的状态才会到达正常稳定的状态，磁盘资源情况才会明确。当磁盘资源情况明确之后，上层数据库集群的磁盘仲裁资源才可以作为判断依据，然后数据库集群才会有仲裁的可能性，最终整个容灾系统才有可能到正常稳定状态。

因此，在这种架构模式下，数据库集群和存储集群的叠加必然会带来以上所描述的仲裁复杂性的问题。理论上存储双活的仲裁和数据库的仲裁都是有时间参数可以控制他们的触发时间和仲裁时间，只要保证时间顺序按照上述逻辑有序可循就可以了，但是实际容灾场景下的仲裁是否可以如理论所描述的顺利？是否会有更复杂的场景导致理论上的偏差？这些都是未知的。

简言之，如果希望存储双活架构的健壮性和安全性更有保障，就不建议在上层应用方面做更复杂的架构进行叠加使用。

社区专家主张

赵海主编：基于前面的共识，某金融机构架构师李威、江西农信运维技术经理邓毓、某股份制银行系统架构师老谷分别主张本议题下的相关关键点，几位专家的主张在宁夏银行技术经理陈明福及我的复议下，各位专家的主张最终形成一定的共识供同行参考。

李威某金融机构架构师：

不谈业务的双活很大程度上就是耍流氓！双活数据中心架构的另一重点设计是在更高维度的双活数据中心存储（数据核心层）与双活应用（业务核心层）的联动，只有纵向完成闭环切换才能保障业务的连续性。

说到基于存储的双活数据中心架构时，人们很可能在下意识里第一个想到便是“存储”，是某一款存储产品，亦或是某款存储双活架构的方案。在如今信息化浪潮下，笔者认为对此处“存储”的理解应该更加精准一些，可以总结为一个基本点和两个方向：一个基本点，指的是基于通用型存储产品实现；两个方向，分别是同步复制和异步复制两种双活方式。

图2 Active-Active双活模式数据写入

集中式存储产品构建的双活数据中心，会根据企业对双活数据中心的建设目标及双活要求制定方案。若以高性能高可靠为目标，存储多以Active-Active（如图2）同步复制模式配置双活，通过见证仲裁服务，对IO进行拆分，同步写入多端存储，高权重单向读取，确保底层存储数据强一致的同时业务效率也能达到高性能水准。在Active-Active模式下，既要保证IO效率又要保障多端数据的一致性，因此必须有一种处理机制来保驾护航——IO锁机制，这是同步复制的核心也是双活安全的前提。纵观主流存储产品同步复制IO锁核心机制实现，我们根据何时返回IO ACK信标大致可以划分为两个方向：1. 将源端IO数据完全同步到远端后向上层应用返回IO结果。2. 源端存储加锁后便向上层应用返回IO结果。两种锁机制各有利弊，前者需要更高质量的通信链路去保证IO效率，后者需要控制器及仲裁服务更加精准稳定，稍后我们会有详细的分析和介绍。

图3 Active-Passive双活模式数据写入

另一种构建双活数据中心的方式，则是通过存储异步复制实现。本地业务读写请求由本端存储响应，通过特定时间间隔从源端存储到远端存储复制，一定程度上保障多端存储的一致性和高可靠性。相对于上文的Active-Active存储双活，异步复制多以Active-Passive（如图3）模式进行，在实际双活数据中心实践中，生产服务端存储承担Active角色，绝大多数业务请求读写均在生产端，远端存储承担Passive角色，仅实现少量业务查询或统计类业务，只有在生产端存储宕机、切换到远端存储的情况下才进行在线业务的生产支撑。同时，异步复制的实现基础相对较低，仅需满足完全复制增量数据的链路带宽即可，建设成本低廉。

基于存储产品构建的双活数据中心，始终会面临链路质量、数据一致性与可靠性两大类问题的考验。企业通常采用光纤链路进行数据同步，由于两个数据中心之间天然存在物理距离，随着距离的增长链路的延迟也会增大，理论上每增加100KM，会增加1ms的RTT（往返延迟时间），链路的建设成本也呈指数级增长。而在主流高端存储双活实践中，两地距离链路延迟必须小于3ms，极大地限制双活数据中心的物理选址。同时对于TB级别的业务，链路带宽要求通常在8GB及以上，保障业务波峰期双端存储双活的高可靠性。如何平衡链路质量与持续建设成本是双活数据中心建设中一个持久话题。

其次，存储数据一致性与可靠性保障也是一大难关。对于同步复制而言，锁机制是一大关键，因为有锁机制的存在，多端存储才能保持数据的一致性，若锁机制被破坏，双活的意义也荡然无存。在锁机制的实现上，“如何保障数据的时序一致性”的难题首当其冲。在AB双活数据中心， A端应用向A端存储卷写入数据，当这份更新数据还未完全同步到B端存储卷之前，B端某应用如果发起针对同一个目标地址的读写操作，这时B端存储卷就不能响应此次IO，B端存储卷该目标地址的数据仍是旧数据，与A端该目标地址存在数据差异。在存储锁机制的驱动下，A端应用向A端存储卷写入数据前应锁住B端对应的目标地址空间后再执行数据写入，若B端加锁不成功，A端IO则悬挂直至B端加锁成功。B端存储被锁期间均不能响应该目标地址的读写IO，必须等待A端的IO数据同步到B端且更新完成才能响应IO请求。

锁机制不仅复杂，在保障时序一致性的前提下还要克服第二个现实难题，即“如何克服链路延迟导致的IO性能降低”。在上面的示例中，AB双活数据中心因为距离存在链路延迟，那A端存储应该何时返回IO结果给A端应用呢？是B端加锁成功后还是B端成功更新A端该目标地址的全部新数据后？如果是前者，B端加锁成功A端应用即可获得IO结果，B端存储后续还存在同步更新的操作，应用层IO效率虽然得以提升，但加大了丢失数据的风险，一旦B端还未完全同步更新数据时出现链路中断或者A端存储宕机，B端承接业务时整体数据呈不一致的状态，对业务的伤害不言而喻。如果是后者，即传统的同步复制方式，因为需要等到B端存储完全同步更新数据，所以整体IO效率受链路传输质量影响而降低，但鲜少出现AB端数据不一致的情况。存储的高效性能和数据的强一致性保障，鱼和熊掌不可兼得。

克服时序一致性问题，对于异步复制而言则轻松许多。主流存储厂商通常采取周期性复制、连续性复制两种手段实现。周期性复制相对主流，也是较为便捷的一种方式，在双端存储完成初始化同步后，每间隔一段时间源端存储进行一次快照，对比并记录相近的两份快照间的差异数据，并将差异数据拆分成多个IO流片段，同步至远端存储应用更新。若IO流传输过程中或远端存储更新数据时出现失败，则回滚至上一次快照状态，等待下一次同步周期再进行数据更新。若链路质量不佳持续出现多次失败，源端存储和远端存储的数据差异将越来越大，双活RPO显著降低。而连续复制则是不断地向远端进行数据复制，主流存储厂商大部分采用基于日志序列的连续复制。源端存储会开辟一块独立的日志空间，在进行IO时写入一份记录到日志空间中，按照顺序将所有IO操作记录下来形成日志流，然后不断同步日志流至远端应用更新。连续复制的弊端也显而易见，倘若存储同步链路中断或者负载压力持续走高，日志空间可能会被迅速填满，必须借助其他手段缓解压力，若故障长时间持续下去，连续复制的效果会大打折扣甚至中断。

至此，我们可以对基于存储的双活数据中心架构进行一个总结：在双活数据中心架构里，存储同步链路质量很大程度上影响双活的稳定性与可靠性。对于高性能高可靠的双活要求，存储同步复制实现是不错的选择，若项目预算有限或者双活要求不高，则可以选择存储异步复制的方式。

我们讨论了基于存储的双活数据中心架构的存储架构形态、双活机制、问题与挑战，但讨论依旧浅薄，仅局限于存储产品层面。存储数据的RPO与RTO，和业务系统的RPO与RTO是一个概念吗？NO！不谈业务的双活很大程度上就是耍流氓。在企业双活数据中心架构中，存储端同步复制的RPO一定等于0吗？现实往往与理想相悖，在同步复制的场景下通常会出现两种可能性：业务系统能够启动起来，RPO≈0；业务系统启不起来，RPO=RTO=∞，可能永远都启不起来。这就引申出了一个更有意思的话题，双活数据中心架构下应用层双活容灾如何联动数据中心存储，利用存储的生态、发挥存储双活的优势去提升双活的RPO、RTO等级呢？不妨让我们等到应用双活架构再来一探究竟。

邓毓江西农信运维技术经理：

构建既健壮又安全的存储双活解决方案，需同时具有静态优先级模式和仲裁服务器模式两种故障仲裁机制，这样才能覆盖所有灾难场景，才是完整的双活仲裁解决方案。

存储双活解决方案必须要具备足够充分的高可用特性和合理的容灾保护与仲裁机制，以应对各种各样复杂的的灾难故障场景，以极短的故障恢复时间和几乎为零的故障恢复目标，解决可能遇到的故障灾难。存储双活模式下，通常而言具有以下两种故障仲裁机制：

1. 静态优先级模式：主要应用在无第三方仲裁服务器的场景，在发生链路中断脑裂现象时，强制使优先的存储节点继续提供服务。

2. 仲裁服务器模式：应用在有第三方仲裁服务器的场景，将仲裁服务器部署于第三方站点，在这种模式下，可同时设置静态优先模式，实现双仲裁保护能力。

静态优先级模式：

如图4所示为静态优先模式仲裁示意图，列举了三个故障场景和对应的仲裁处理结果：

图4 静态优先模式仲裁示意图

1）当两个站点间链路出现故障时，静态优先模式设置H1站点为静态优先站点，此时H1站点将继续对外提供读写服务，H2站点将停止读写服务，在主机端I/O访问策略设置为优选阵列模式时，H1站点的主机将继续本地读写H1站点存储，H2站点主机既无法读写H2站点存储也无法通过切换跨站点链路访问H1站点存储；

2）当非静态优先的站点H2存储出现故障时，H1站点存储同样继续提供读写服务，但H2站点主机可通过配置的多路径I/O策略，通过跨站点链路继续读写H1站点存储；

3）当静态优先的站点H1存储出现故障时，H1和H2站点均不再对外提供读写服务，两个站点主机的读写将完全中断，此时，只能通过人工的方式，将H2站点的存储激活，继续提供读写服务。

仲裁服务器模式（单故障场景）：

如图5所示，QS为仲裁服务器，S1为静态优先仲裁方。有以下几种故障场景：

图5 单故障场景处理示意图

1）当仲裁服务器本身出现故障时，S1和S2存储能够持续对外提供读写服务，主机业务无任何影响，此时由于缺少了仲裁服务器，将自动进入静态优先模式；

2）当S1或S2存储出现故障时，仲裁服务器能够及时探测到故障存储，停止故障存储的读写，全部读写均由存活存储提供，在主机端I/O访问策略设置为优选阵列模式时，存活存储所在站点的主机可以继续本地读写存活存储，而远端主机则将自动切换至跨站点I/O路径继续读写存活存储；

3）当S1和S2存储间的链路出现故障时，等同于单站点存储故障场景，均需要仲裁服务器进行仲裁，判定某个站点存储失效，全部读写服务由一个存储提供，只有存活的存储所在站点的主机能够读写存活存储，而远端站点主机由于链路故障，无法通过跨站点I/O路径继续读写存活存储。在该场景下，存活的存储将通过划分的额外空间来记录链路故障期间，存储间的数据差异，待链路恢复后，通过差异数据增量同步配置和数据；

4）当S1或S2存储与仲裁服务器间的链路中断时，双活存储间链路正常，不做任何仲裁判断，两端主机正常读写双活存储。

仲裁服务器模式（双故障场景）：

如图6所示，QS为仲裁服务器，S1为静态优先仲裁方。有以下几种故障场景：

图6 双故障场景处理示意图

1）当S1存储与仲裁服务器，S2存储与仲裁服务器间的链路同时或者先后中断时，由于S1和S2间的链路完全正常，主机正常读写双活存储，并且由于缺失了仲裁服务器响应，双活存储将自动进入静态优先模式；

2）当S1和S2存储，其中单个存储与仲裁服务器间的链路同时或者先后中断时，此时仲裁服务器将介入仲裁，判定与仲裁服务器通信正常的存储存活，并对外提供读写服务，且只有存活存储所在站点的主机才能继续访问存活存储；

3）当单个存储出现故障，另一个存储仲裁胜利后，存活存储与仲裁服务器间的链路再出现故障时，由于已经仲裁完成，选举了获胜存储，只要不是该存活存储故障，其他仲裁服务器故障和链路故障都不再影响获胜站点主机的读写访问；

4）当仲裁服务器出现故障后，单个存储也随后出现故障。该场景下，仲裁服务器故障将使得仲裁模式进入静态优先模式，由S1存储继续提供服务，当故障的存储为非静态优先存储时，即S2存储故障，此时S1存储可继续对外读写，S1和S2站点的主机均可通过多路径访问S1存储。当故障的存储为静态优先存储时，即S1存储故障，此时无法继续仲裁，所有存储读写访问中断；

5）当仲裁服务器出现故障，存储间的链路也也随后中断，此时由于仲裁服务器故障将进入静态优先模式，存储间链路中断不会影响优先站点存储继续提供读写服务，但只有优先站点的主机才能读写该存活存储。

老谷某股份制银行系统架构师：

构建基于存储的AA双活架构，本人主张免网关的解决方案，提倡纵向上越精简越有效，切换减少一秒，双活成功一倍！

存储层双活技术路线的对比选择：

基于远程卷管理双活技术架构

典型的技术为AIX LVM、IBM GPFS、OracleASM。

以IBM GPFS为例（如图7、图8），原理如下：

GPFS SAN网络模式架构的跨站点双活方案通过应用负载均衡地把服务请求分发至SiteA和SiteB两个站点，两个站点的所有节点均提供应用服务，SiteA节点的应用在本地对GPFS文件系统读写，SiteB节点的应用跨站点对GPFS文件系统读写。另外，SiteA节点既作为GPFS Servers，同时又担任Application Node，而SiteB节点既可按照容灾方案的第一种方式作为GPFS客户端，又可按照容灾方案的第二种方式作为GPFS的服务端。简单总结这种方式来说，两个站点的节点GPFS I/O读写路径和性能存在些许差异。

将SiteA的NSD Server与Application Node分置于不同节点，SiteA和SiteB节点全部作为GPFS客户端，两个站点的节点GPFS I/O读写路径和性能一致。

上述两种双活方案均是建立在容灾方案的基础之上，SiteA和SiteB的所有节点均加入一个GPFS集群中，利用存储到存储的同步复制功能，SiteA的TiebreakerDisk仲裁，需要自动探测与自动切换脚本。

通过操作系统内的 GPFS 文件系统实现，最大程度不改变传统的物理拓扑，增加整体方案的安全性、可用性；

在操作系统层次，通过 GPFS 文件系统的failure group 功能模块将生产、灾备两个中心的两台存储虚拟为一台存储使用。

通过软件双活方案，双活实现需要依靠主机实现，会造成服务器额外性能开销，对于操作系统，应用程序版本敏感，版本升级操作复杂，性能调优复杂，需对集群中所有计算和存储节点性能调优。

基于存储网关

以EMC VPLEX为例（如图9），原理如下：

图9 EMC VPLEX 双活架构

EMC Vplex存储双活方案是基于Vplex网关产品实现，能够将EMC和其他厂商存储异构整合，虚拟化为统一的存储资源池，实现异构存储双活。Vplex双活方案由两个站点的两套Vplex集群系统组成，每个站点的Vplex集群都有自己专属的本地存储阵列，通过创建分布式镜像卷为跨集群的镜像卷，提供Vplex Access Anywhere功能，两个站点的Vplex集群各有一个卷，两个卷的ID一样。

主机与Vplex集群间访问、Vplex集群与后端存储数据传输、Vplex集群间通信网络全部隔离，为保证最高级别的高可用性，每个Vplex Director前端I/O模块、主机和SAN光纤交换机之间多通过冗余的物理连接，实现多条路径交叉访问。当主机与本地Vplex集群连接中断时，为保证主机能够跨站点访问另一端Vplex集群，主机需要和其他站点的Vplex集群建立连接，可通过PowerPath多路软件来配置ACTIVE/PASSIVE路径来保证主机优先访问本地的Vplex集群。后端存储阵列通过SAN交换机或者直接连接Vplex引擎的后端IO模块，不需要配置到其他Vplex集群的跨站点连接路径；根据需要选用Witness作仲裁，Witness需部署于两个Vplex集群不同的故障域中（第三方站点）。

增加网关设备，成本提高，主机与存储的交互通过网关进行转发。增加了IO链路长度和复杂度，引入了额外的延时。

Vplex作为网关设备，带读缓存，可以把经常访问的数据从存储的cache里读到vplex的cache里，这样能降低读响应时间，提升读的性能。

网关设备的能力约束存储设备自身性能潜力发挥，同时增加硬件故障风险。

通过网关方案横向扩展能力强，可实现异构存储的统一管理。

基于存储卷镜像

以华为存储为例（如图10），原理如下：

图10 华为双活存储架构

采用存储磁盘设备的卷镜像技术实现两站点间的数据实时同步。两台存储设备上的LUN被虚拟化为一个虚拟的卷，主机写操作通过卷虚拟化镜像技术同时写入这两个存储设备，保持数据实时一致。其中任何一个存储设备故障，虚拟卷仍能提供正常的IO读写能力，主机业务不受影响。待存储设备恢复正常后，存储虚拟化设备将增量数据后台同步到修复的存储设备，整个过程对主机“透明”，不会影响主机业务。

HyperMetro双活架构无需额外部署虚拟化网关设备，直接使用两套存储阵列组成集群系统。通过UltraPath主机多路径软件，将两台存储阵列上的双活成员LUN聚合为一个双活LUN，以多路径vdisk方式对应用程序提供I/O读写能力。应用程序访问vdisk时，Ultrapath根据选路模式，选择最佳的访问路径，将I/O请求下发到存储阵列。

不同存储双活路线的优劣势对比如表2。

表2 存储层双活技术路线对比分析