仲裁之所以成为关键点，最重要的原因还是在于，从整体上看，存储跨站点双活技术是一个对称式的方案架构，两边一比一配比，中间通过链路（ FC 或者 IP ）连接，其最核心的难点公认是链路这个部分，这点从各家厂商方案披露支持的 RTT （往返延迟）和距离可以看出端倪。链路中断将造成两端健康的存储节点都认为对方挂掉，试图争取 Shared Resource （共享资源），并试图修改集群成员关系，各自组成一个集群，产生 Brain-Split （脑裂）现象，如果没有合理的机制去防范脑裂，将因互相抢夺共享资源自立集群，而导致共享卷数据读写不一致，产生更严重的后果。在存储双活方案，防范脑裂通用的做法就是使用仲裁机制，在第三站点放置仲裁服务器或者仲裁存储阵列。通常有以下三种方式：一是优先级站点方式。这种方式最简单，在没有第三方站点的情况下使用，从两个站点中选一个优先站点，发生脑裂后优先站点仲裁成功。但如集群发生脑裂后，优先站点也发生故障，则会导致业务中断，因此这种方案并非推荐的方案；二是软件仲裁方式。这种方式应用比较普遍，采用专门的仲裁软件来实现，仲裁软件放在第三站点，可以跑在物理服务器或虚拟机上，甚至可以部署到公有云上；三是阵列仲裁盘方式。这种方式是在第三站点采用另外一台阵列创建仲裁盘。这种方式稳定性，可靠性比较高。
本文转载自微信公众号： talkwithtrend
除了仲裁之外，两地三中心（ 3DC ）扩展方案也是企业上存储双活方案考量较多的关键点。所谓 3DC 即两地三中心，即一份数据有 3 份备份（包括自己）且分布在三个不同的地理位置即称之为三数据中心，通常是指生产中心，加上同城灾备中心以及异地灾备中心。近年来，大范围自然灾害时有发生， 3DC 容灾解决方案越来越受到业界重视和认可，企业在选型建设同城存储双活之前，也需要结合企业各项业务系统连续性保护要求，对存储双活方案之上的异地灾备扩展能力进行额外的考量，其考量点主要体现在以下四个方面：一是受银监和人行监管要求，同城存储双活除了需满足业务连续性指标 RTO 和 RPO 的要求之外，还需要在异地建立数据级以上的保护，以防范城市级重大自然灾害；二是所采用的异地灾备机制，是否会对现有生产和同城引入新的风险问题或者性能影响；三是两地三中心整体架构的完整性问题，在生产中心出现问题后，同城灾备中心接管，异地灾备是否具备持续的保护能力的问题，如果不具备持续保护能力，异地灾备接管的 RPO 将在生产站点恢复之前，不断滞后，灾备站点的单点时间将持续延长；四是在两地三中心架构下，异地灾备的资源是否具备被访问的能力，资源能否得到部分利用，提升整体资源利用率。
下面就这五种方案的仲裁方式和特点，以及两地三中心扩展方案一一解析。
一、 华为 HyperMetro
1、 仲裁
（ 1 ）仲裁需求：可选择采用仲裁设备的方式进行仲裁，仲裁设备可以是物理服务器，也可以是虚拟机，或者是公有云上的虚拟机；要求两套双活的存储阵列能够通过 IP 网络访问仲裁设备，网络带宽需大于 2MB/s ；独立的物理服务器或者虚拟机作为仲裁设备时，建议部署在第三方站点，这样可以避免单数据中心整体发生灾难时，仲裁设备也同时故障，导致脑裂问题的发生。
（ 2 ）统一管理：如下图所示，能够实现一套仲裁统一管理 SAN 与 NAS 双活，任何故障场景实现 SAN 和 NAS 在相同站点提供服务。
（ 3 ）双重仲裁模式：提供静态优先与仲裁服务器两种仲裁模式，最大限度保障存储双活方案的高可用。静态优先级模式主要应用在无第三方仲裁服务器的场景，在发生链路中断脑裂现象时，强制使优先的存储节点继续提供服务，一般不建议采用该方式，因为在静态优先存储发生故障时，非静态优先的存储和优先的存储间通讯也中断，按照该模式，主机存储访问将全部中断； HyperMetro 支持按双活 Pair 或双活一致性组（多对双活 Pair ）为单位进行仲裁，仲裁精细度高，通常可配置以业务为粒度进行仲裁（双活一致性组），仲裁之后，业务均衡分布访问两个存储，实现站点间链路故障时，主机就近访问。
2 、两地三中心扩展
华为 OceanStor HyperMetro 方案支持存储双活之上的异地容灾，通过与 OceanStor 统一存储系统的 HyperReplication 特性组合，并结合 BCManager 专业容灾管理软件实现 3DC 容灾。
当生产中心发生灾难，可在同城灾备中心进行接管业务，并保持与异地灾备中心的容灾关系。若生产中心和同城灾备中心均发生灾难，可在异地灾备中心对远程复制进行主从切换，并拉起业务。相对于传统的同步复制 + 异步复制的 3DC 方案，这种双活 + 异步复制的方案具有更好的资源利用率和故障切换速度。双活数据中心实现同城容灾时，可将同一关键业务负载均衡到双数据中心，并且在单数据中心发生故障，业务零中断，数据零丢失。在部署层面，双活数据中心支持平滑扩展为两地三中心，可先期实现同城双活，待异地数据中心建设完成后，再添加异步复制，实现应用异地保护。
另外，在 3DC 方案中，华为 BCManager 能够提供简化管理的容灾拓扑展示与端到端监控功能，直观清晰的展示保护方案的状态与变化，实时监控相关设备部件，实现业务灾难切换前就识别问题与故障并协助用户排除，规避影响业务和增加成本的容灾切换发生。
二、 EMC Vplex
1 、仲裁
（ 1 ）仲裁需求： Vplex Metro 和 Vplex Geo 系统具有专属的仲裁节点： Witness ，在搭建 Vplex 双活时，可根据需要包括或不包括 Witness 。 Witness 只能作为虚拟机部署，且只支持 VMware 虚拟化，并部署在与两个 Vplex 集群不同的故障域中 ( 第三方站点 ) 。在两个 Vplex 集群之间进行仲裁，发生站点故障和集群间通信中断时， Witness 起到仲裁效果，提高业务连续性。
（2） 防脑裂规则： Vplex 有着自己专属的防脑裂规则。第一种是分离规则：分离规则是在与远程集群间的连接中断（例如，链路或远程集群故障）时，确定 I/O 一致性组处理方式的预定义规则。在异常情况下，集群通信恢复之前，大多数工作负载需要获得特定虚拟卷集，才能在一个 Vplex 集群上继续 I/O 访问，并在另一个 Vplex 集群上暂停 I/O 访问。在 Vplex Metro 配置中，分离规则可以设置为静态优选集群，方法是设置： winner:cluster-1 、 winner:cluster-2 或 No Automatic Winner （无自动优胜者）。在没有部署 Vplex Witness 情况下， I/O 一致性组将在优选集群中继续提供 I/O 服务，并在非首选集群中暂停 I/O 服务。
第二种是 Vplex Witness,Vplex Witness 通过管理 IP 网络连接至两个 Vplex Metro 集群。 Vplex Witness 通过将其自身的观察与集群定期报告的信息进行协调，让集 群可区分是集群内故障还是集群间链路故障，并在这些情况下自动继续相应站点上的 I/O 服务。 Vplex Witness 仅影响属于 Vplex Metro 配置中同步一致性组成员的虚拟卷，并且仅当分离规则没有指明集群 1 或集群 2 是一致性组优选集群时才会影响（也就是说，“无自动优胜者”规则生效时， Vplex Witness 才会影响一致性组）。在没有 Vplex Witness 时，如果两个 Vplex 集群失去联系，生效的一致性组分离规则将定义哪个集群继续 I/O 服务以及哪个集群暂停 I/O 服务。
如上所述，如果仅使用分离规则来决定哪个站点是优胜者时，可能会增加站点故障时不必要的复杂性，因为可能需要手动干预才能恢复正常运行的站点 I/O 。而采用 Vplex Witness 则会动态地自动处理此类事件，这也是它成为 Oracle Extend RAC 部署时，绝对必要项的原因。 Vplex Witness 提供了以下几项内容： 一是在数据中心之间自动实现负载均衡；二是两个数据中心为 Active/Active 模式；三是可以实现存储层故障处理完全自动化。
为了让 Vplex Witness 能够正确区分各种故障情况，必须将 Vplex Witness 部署在独立于两个站点集群之外的故障域，并且采用互不相同的网络接口。这将规避单个站点故障同时影响 Vplex 集群和 Vplex Witness 的风险。例如，如果将 Vplex Metro 配置的两个集群部署在同一数据中心的两个不同楼层，则建议将 Vplex Witness 部署在其他楼层；如果将 Vplex Metro 配置的两个集群部署在两个不同的数据中心，则建议在第三个数据中心部署 Vplex Witness 。
2、 两地三中心扩展
Vplex 的两地三中心扩展方案有两种实现方式，第一种是借助 EMC RecoverPoint 设备实现。在 Vplex Metro 双活 +CDP 方案中， Vplex 接受到主机写 I/O 之后，同时写入两个数据中心的存储。此外 Vplex 内部集成 I/O 分流软件， Vplex 将每个主机写 I/O 同步复制到 RecoverPoint 。 RecoverPoint 将每个 I/O 记录下来，采用 CDP 实现任意时间点恢复，如下图 1 所示。在该方案之上还可进阶实现 3DC 方案：站点 2 的 RecoverPoint 通过异步复制将 I/O 复制到站点 3 部署的 RecoverPoint 设备，站点 2 的 RecoverPoint 都将每个 IO 记录下来，实现任意时间点恢复，站点 3 的 RecoverPoint 设备异步记录从站点 2 RecoverPoint 设备传输过来得 I/O ，并落地至后端的存储阵列。站点 2/3 的 RecoverPoint 设备对接的存储需要能够支持 RecoverPoint ，可以是 Vplex Local 集群，也可以是存储阵列，如下图 2 和 3 所示。由 EMC RecoverPoint 、 VPLEX Local （或存储阵列）和 Metro 组成的三个站点拓扑将减少主站点或存储阵列故障相关的停机时间，同时能够快速从应用程序数据损坏、病毒或人为错误中恢复，即具备物理和逻辑性错误的双重防范能力。如果丢失多个 VPLEX 站点或虚拟卷的逻辑损坏，可以通过第三方软件集成 , 自动恢复远程站点（第三站点）到虚拟卷的一致时间点。
图 1 Vplex Metro + RecoverPoint CDP
图 2 Vplex Metro to Vplex Local
图 3 Vplex Metro to Array-based Splitter
第二种是在 Vplex Metro 的基础上，借助 EMC 存储自身的复制技术实现 3DC 方案，即 Vplex Metro+EMC SRDF/A 方案，如下图所示，主站点和同城灾备站点为双活，主站点 Vplex 集群的底层存储为 EMC 存储（需具备 SRDF 复制许可），通过 SRDF 异步将数据传输至异地灾备站点后端的 EMC 存储（也需具备 SRDF 复制许可），实现数据级异地灾备。
三、 IBM SVC
1 、仲裁
（ 1 ）仲裁需求：对于 SVC ESC 和 SVC HyperSwap 存储双活方案架构而言，整体呈现的是一种对称式的整体架构，为了防范脑裂，仲裁站点是必需的。在仲裁站点中，基于 IP 的 Quorum 节点和物理 Quorum 磁盘都可以提供脑裂的仲裁服务，存储双活集群最多能够拥有 3 个物理 Quorum 磁盘，也可以选择最多 5 个基于 IP 的 Quorum 节点，这个基于 IP 的 Quorum 节点可以是任何站点的任何服务器，或者公有云的一个虚拟机，在这个服务器内运行一个简单的仲裁 JAVA 程序即可。相较于 Quorum 磁盘，基于 IP 的 Quorum 节点大大提高了仲裁站点的选择方式，节省了企业双活建设成本，只要求 IP 可达，延时在 80ms 之内即可。但是只有物理 Quorum 磁盘的仲裁方式才能够被用来做 SVC ESC 集群的 T3 Recovery ，所有的 SVC 节点都会将节点和集群的相关信息同步至该物理 Quorum 磁盘，当 SVC ESC 整个集群出现无法恢复的故障时，采用 SVC Manage 方式管理的底层存储 LUN ，将无法脱离 SVC 集群直接挂载给主机恢复业务，只能通过第三站点的物理 Quorum 磁盘进行 T3 Recovery 。对于 SVC HyperSwap 双活方案，由于两个站点存在两个互相保护集群，其中一个集群出现故障时，另一个集群可以接管故障，则不存在集群性整体故障无法启动，导致需要第三站点 Quorum 磁盘去做 T3 Recovery 的情景。
（ 2 ）仲裁机制：在 SVC 集群中有一个概念称为 Configuration Node ，即配置节点，是配置 SVC 集群后，系统自动产生的保存着所有系统配置行为的节点，不能人工更改配置节点。当配置节点失效后，系统会自动选择新的配置节点，配置节点十分重要，它对 SVC 节点仲裁胜利起着决定性作用，仲裁胜利的排序规则通常如下： a 、配置节点（配置节点获得仲裁胜利的概率最高）； b 、距离仲裁站点近的节点（探测延时较低的 SVC 节点获得仲裁胜利的概率次之）； c 、距离仲裁站点远的节点（探测延时较低的 SVC 节点获得仲裁胜利的概率最低）。例如，当两站点间光纤链路中断，第三站点仲裁节点活动时，脑裂发生，将通过投票仲裁选举获胜的站点，按照上述的仲裁胜利规则， Configuration Node 位于节点 2 ，选举站点 2 优先赢得仲裁，通过站点 2 恢复业务的正常存储访问。当第三站点仲裁节点不活动时，不影响主机的正常存储访问。但倘若此时，两站点间光纤链路也中断了，发生脑裂，这时因为节点 2 为 Configuration Node ，它所拥有候选的 Quorum 将变为 Active Quorum ，该 Quorum 选举站点 2 为仲裁胜利站点，通过站点 2 恢复业务的正常存储访问。
2 、两地三中心扩展
从存储网关层的角度，基于 SVC 的两种双活方案中只有 SVC ESC 方案具有 3DC
扩展能力，受限于 SVC Metro Mirror 或 Global Mirror 的技术体系，无法进行两个以上的 SVC 集群级联扩展， SVC HyperSwap 的复制核心技术为两个集群间的 Metro Mirror ，无法继续在 MM 之上，继续扩展为三个集群间的 MGM （这点与 IBM DS8000 系列的 MGM 技术体系有所差异）。而 SVC ESC 方案的复制核心技术为 Vdisk Mirror ，为同一 SVC 集群下的镜像技术，在此基础之上可以继续扩展为 VDM+MM 或 GM 的架构。从下图 SVC ESC 扩展两地三中心的架构来看，异地灾备站点既可以部署 SVC+ 兼容的后端存储阵列，也可以直接部署 V7000/V5000 等 IBM 存储（这两款存储和 SVC 具有相同的虚拟化软件），通过 GM 异步和 SVC ESC 集群保持复制关系。
而从底层存储的角度，依靠存储阵列的复制技术，可以是 IBM DS8000 系列的 MM 或者 GM ，也可以是 EMC 的 SRDF/S 或者 SRDF/A ，亦或者是 HDS 的 TrueCopy 或者 Universal Replicator 等等， SVC ESC 和 SVC HyperSwap 均可以实现 3DC 扩展。存储网关层的 3DC 扩展和底层存储层的 3DC 扩展有一个比较重要的区别，如果主机的 SVC 虚拟卷条带化分散在底层存储的不同 LUN 上（ Manage 模式），采用底层存储复制技术实现 3DC 方案，可能会导致异地灾备的存储 LUN 无法挂载给主机使用，这种 3DC 方案显然是不推荐的；而采用存储网关层的 3DC 方案，则可以有效避免这种问题，异地灾备的主机可以顺利挂载 SVC/V7000/V5000 上的虚拟机卷。如果主机的 SVC 虚拟卷和底层存储 LUN 是一一对应的（ IMAGE 模式），采用底层存储复制技术则不会遇到该问题。
四、 HDS GAD
1 、仲裁
（ 1 ）仲裁需求：分布式集群和双活方案都需要仲裁机制防止脑裂，保证心跳故障后，整个集群系统能对外提供数据一致性存储服务。 GAD 的仲裁机制原理是采用仲裁磁盘的方式实现，暂不支持通过 IP 仲裁节点实现；仲裁磁盘是第三站点外部存储系统虚拟化的卷，可以是存储阵列，也可以是受支持的服务器磁盘，用于当链路路径或存储系统发生故障时，确定主机 I/O 应在哪个存储系统上继续访问。主存储和从存储每 500 毫秒检查一次仲裁磁盘的物理路径状态；另外，建议外部存储系统的响应时间尽量小，如果响应时间超过 100 毫秒，需要执行必要的操作以减少响应时间。
（ 2 ）仲裁机制： HDS GAD 具有独特的磁盘仲裁机制，如下图所示，当主存储系统和从存储系统无法通信时，将执行以下操作： a 、当主存储系统无法通过数据路径和从存储系统进行通信时，会将此状态写入仲裁磁盘； b 、当从存储系统从仲裁磁盘检测到发生路径故障时，它将停止接受主机的读写操作 ;c 、从存储系统将与仲裁磁盘进行通信 , 将已停止读写操作的状态通知仲裁磁盘 ;d 、当主存储系统检测到从存储系统无法接受主机读写操作时，主存储系统将挂起 GAD Pair Volume;e 、主存储系统恢复主机读写访问操作。
如果主存储系统在通信中断后的 5 秒内，无法从仲裁磁盘检测到从存储系统不接受主机 I/O 的状态通知，主存储系统将挂起 GAD Pair Volume ，并恢复主机 I/O 访问；如果主存储和从存储系统同时向仲裁磁盘写入通信停止的状态，则认为该通信中断由存储序列号较小的存储系统写入。由该存储系统挂起 GAD Pair Volume ，恢复该存储的主机读写访问操作。如果仲裁磁盘故障，两个存储间的通信中断时，主存储和从存储系统均无法写入通信中断状态到仲裁磁盘，将导致两个存储的全都无法接收主机读写 I/O ，需要强制删除删除 GAD Pair Volume 恢复业务。
针对对应系统（主存储或者从存储）是否能够被检测到已经停止了主机 I/O 访问，有以下两种仲裁机制：
一是在对应系统中检测到主机 I/O 访问停止：当在对应系统中 5 秒内检测到停止时，将根据 GAD Pair Volume 的状态（见下表）来确定停止后将继续接收读写的 Pair Volume 。 a 、当 Pair Volume 的状态为 PAIR 时，将通信中断写入仲裁磁盘的存储卷将恢复主机读写访问； b 、当 Pair Volume 的状态为 INIT/COPY 时， P-VOL 的主机读写访问继续，而对 S-VOL 的主机读写访问将保持停止状态； c 、当 Pair Volume 状态为 PSU 、 PSU 、 SSW 或 SSU 时， I/O 模式为 Local 的卷将恢复主机读写访问， I/O 模式为 Block 的卷将停止主机读写。
二是对应系统中未检测到主机 I/O 访问停止：当对应系统在 5 秒内未检测到中断时，将通信中断写入仲裁磁盘的存储卷在中断后恢复接收主机读写访问。读写处理机制取决于 Pair Volume 状态和未检测到写的 I/O 模式。 a 、当 Pair Volume 的状态为 PAIR 时，两个存储的主机读写访问继续； b 、当 Pair Volume 状态为 INIT/COPY 时， P-VOL 的主机读写访问继续，而对 S-VOL 的主机读写访问保持停止状态； c 、当 Pair Volume 状态为 PSU 、 PSU 、 SSW 或 SSU 时， I/O 模式为 Local 的卷将恢复主机读写访问， I/O 模式为 Block 的卷将停止主机读写。
2 、两地三中心扩展
HDS 存储两地三中心方案有三种成熟的架构，所采用的技术也有所差异，分
为级联三中心拓扑、多目标拓扑和异步复制的存储集群拓扑，如下表所示。相较于其他存储架构方案， HDS 在两地三中心方案上提供了不同层次的数据和业务连续性保护能力。下面一一详细介绍：
（1） 级联三中心拓扑：下图为该拓扑架构图，生产中心和同城灾备中心间保持同步复制关系，同城灾备中心和异地灾备中心保持异步复制关系，在该拓扑下，当同城灾备中心发生故障的情况时，异地灾备中心与其在该时间点接收的数据将被暂时冻结。随后，决策层必须决定是否在不具备持续保护的情况下继续运行 IT 生产系统。如决定继续运行，异地灾备中心的数据差异量将进一步增加，并且如果接下来生产中心发生故障，则可能会导致重大的永久性数据丢失。管理员可以选择停止生产中心，直到同城灾备中心恢复，或可以建立从生产中心到异地灾备中心的链路。在这种情况下，会导致生产恢复时间延长，但可最大限度地降低数据丢失量。对于在较小地理区域内的企业，级联三中心拓扑能使业务开展更加顺利。导致生产中心和同城灾备中心同时发生故障的灾难将可能只对大多数本地客户造成影响。对于跨国企业，尤其是提供关键基础架构服务的企业，级联三中心拓扑可能无法满足更为严格的要求。
（2） 多目标拓扑：下图为多目标拓扑，生产中心和同城灾备中心保持同步复制关系，同时也和异地灾备中心保持异步复制关系，同城灾备中心和异地灾备保持差异数据再同步复制关系。多目标拓扑与级联三中心拓扑和之间的区别在于：在多目标拓扑中，生产中心同时将数据备份到两个中心。这是 HDS 存储最新的技术能力，并且需要非常高性能的控制器来对此流程进行管理。该方案可以确保在生产中心或同城灾备中心丢失时不会出现永久性数据丢失。任一中心可以将数据传送到异地灾备中心，以确保零数据丢失。为确保快速恢复，存储控制器技术必须能使异地灾备中心上的控制器与生产中心或同城灾备中心重新同步，并仅传递更改的数据（增量重新同步）。而在级联三中心拓扑中，如果同城灾备中心关闭，则不能将数据传送到异地灾备中心。多目标架构的主要缺点是三中心链路的成本较高。而主要优势是，如果同城灾备中心中有备份服务器，则可以在生产中心和同城灾备中心之间进行故障切换和故障自动恢复。由此将显著缩短业务恢复时间。此外，还可以在任一备份中心创建和挂载远程快照或克隆，以启用辅助用途。这些用途包括将数据备份到磁带、开发测试使用生产数据或进行生产数据恢复测试等操作，而不会对生产系统的性能或可用性造成影响。
（3） 异步复制的存储集群拓扑：如下图所示，该架构和多目标拓扑架构类似，差别在于生产中心和同城灾备中心的高可用方式，多目标拓扑为 ACTIVE-STANDBY 模式，而存储集群拓扑为 ACTIVE-ACTIVE 集群模式。该架构为 HDS 的最新技术，有关存储故障恢复能力和数据可用性的最新发展成果都在 GAD 存储集群技术中有所体现。这些功能是 Hitachi Virtual Storage Platform 系列系统的存储虚拟化操作系统的一部分。通过 GAD ，可配备两个生产中心，每个中心均有所有数据的活动拷贝。如任一中心发生故障，则其数据在其他中心是透明可用的，无需执行故障切换或故障将自动恢复。 Universal Replicator 异步复制用于将数据从任一生产中心复制到异地灾备中心。上述有关多目标配置的所有额外优势均适用于此架构。存储集群的 3DC 模型可提供最大级别的数据可用性和故障恢复能力，同时实现零数据丢失。
五、 NetApp MetroCluster
1 、仲裁
（ 1 ）仲裁需求： NetApp MCC 的 MetroCluster 仲裁软件称为 TieBreak ，它支持部署在第三站点的 Linux 的主机上，该软件通过对节点 SSH 的 Session 进行检查，实现对 HA Pair 和集群状态进行监控。 TieBreak 软件能够在 3 到 5 秒内检查到 SSH Session 的故障，重试的时间间隔为 3 秒。仲裁软件的这种方式具有灵活性的优势，第三站点可以选择两个数据中心中的一个，可以选择公有云中的一个虚拟机，也可以选择其他建筑内的任意一台 Linux 虚拟机，保证 SSH 网络可达即可。下图为 NetApp MCC+TieBreak 的拓扑架构。
（2） 仲裁机制： MetroCluster 仲裁的机制有两种，第一种为静态模式，在站点发生故障后， MetroCluster 配置本身不会检测并启动切换。此时不能依靠一个站点去监视另一个站点的故障，因为从一个集群到另一个集群的响应超时可能是由于活动的站点故障引起的，或者可能是由于所有站点间链路的故障引起的，站点间的监视无法发现真实的故障引发原因。在静态模式下，如果站点间所有链路都出现故障时， MetroCluster 配置将继续运行，提供本地 I/O 服务，但无法将写 I/O 同步至远程站点。当站点间一条以上链接线路恢复后，会自动恢复复制关系，并追上异常时产生的数据差异。在这种情况下，不会产生自动切换，因为每个集群都认为另一个集群已经失败，并且两者都可能尝试执行切换，从而导致脑裂场景，造成数据不一致。至于是否需要切换，可以由管理员或领导确定。第二种为仲裁模式， NetApp 提供完全功能支持的 MetroCluster Tiebreaker 软件进行仲裁，该软件安装在第三个站点，并与两个集群中的每个集群建立独立连接。 Tiebreaker 软件的目的是监控和检测单个站点故障和站点间的链路故障。如果发生站点灾难， MetroCluster Tiebreaker 软件可能会引发 SNMP 陷阱。它以观察者模式运行，并且可以在发生需要切换的灾难时检测并发送警报。管理员收到告警后，可以手动发出切换命令进行灾备切换，也可以将 Tiebreaker 软件配置为在发生灾难时自动发出切换命令。
为了创建站点可用性的聚合逻辑视图， Tiebreaker 软件监视节点， HA Pair 和集群级别的相关对象，通过对集群硬件、直接链接和间接链接检查来更新其链接和集群状态。通过不断的更新来判断 Tiebreaker 是否检测到 HA 接管事件、站点故障或所有站点间链路故障等场景。直接链接是通过 Secure Shell （ SSH ）到节点的管理 LIF 。所有到集群的直接链接失败都表示该站点出现故障，其特征是集群停止提供任何数据（所有 SVM 都已关闭）。间接链接确定集群是否可以通过任何站点间（ FC-VI ）链接或集群间 LIF 到达另一个集群。如果集群之间的间接链接失败，而到节点的直接链接成功，则表明站点间链接已关闭，并且集群彼此隔离。在这种情况下， MetroCluster 将按照静态模式继续运行；如果到单个站点节点的直接链接失败，则表明站点可能出现故障。在这种情况下， MetroCluster 将按照仲裁模式，产生告警事件，进行自动或手动切换。
2 、两地三中心扩展
NetApp MetroCluster 采用 SnapMirror 数据复制来实现两地三中心扩展方案，从 ONTAP 9.5 开始， MetroCluster 增加了对 SVM DR 的支持， MetroCluster 配置中的活动存储虚拟机（ SVM ）可用作具有 SnapMirror SVM 灾难恢复功能的源，以获得更高级别的保护，但目标 SVM 必须位于 MetroCluster 配置之外的第三个群集上。如下图所示，可分别为两个站点的不同 SVM 建立相同的异地容灾保护。
然而将 SVM 与 SnapMirror 灾难恢复一起使用时，具有以下要求和限制：
（ 1 ）只有 MetroCluster 配置中的活动 SVM 才能成为 SVM 灾难恢复关系的来源。源可以是切换前的同步源 SVM ，也可以是切换后的同步目标 SVM 。
（ 2 ）当 MetroCluster 配置处于稳定状态时， MetroCluster 同步目标 SVM 不能成为 SVM 灾难恢复关系的来源，因为卷是离线状态，无法读写。也就是说，无法通过 MetroCluster 同步目标 SVM 来继续扩展多数据中心。
下图左显示了在 MetroCluster 稳定状态下的 SVM 灾难恢复架构：
（ 1 ）当同步源 SVM 是 SVM DR 关系的源时，源 SVM DR 关系信息也将复制到 MetroCluster 的 Partner, 这样可以在 MetroCluster 集群切换后，由 Partner 继续维持 SVM DR 架构，主站点故障，同城灾备站点依旧具备完备的灾难恢复能力，如下图中所示：
（2） 在 MetroCluster 集群内部发生切换和切回过程中，到 SVM DR 目标的复制可能会失败。但是在切换或切回过程完成后，将重新建立起 SVM DR 复制关系。
上图右为灾难恢复站点上的 SVM 重新同步架构，在重新同步期间， MetroCluster 配置上的存储虚拟机（ SVM ）灾难恢复（ DR ）源将从非 MetroCluster 站点上的目标 SVM 还原，建立重新同步关系，在重新同步期间，由源 SVM （ cluster_A ）暂时充当目标 SVM 。
（ 1 ）如果在重新同步期间， MetroCluster 集群内部发生非计划性的意外切换，将停止重新同步的数据传输。如果发生意外切换，则满足以下条件： a 、 MetroCluster 站点上的目标 SVM （在重新同步之前是源 SVM ，图中为 cluster_A ）仍然是目标 SVM 。 MetroCluster Partner 集群（图中为 cluster_B ）中的 SVM 依旧保留其子类型并保持不活动状态； b 、必须使用同步目标 SVM 作为目标手动重新创建 SnapMirror 关系； c 、除非执行 SnapMirror 创建操作，否则在幸存者站点切换后， SnapMirror 关系不会出现在 SnapMirror show 的输出中体现。
（ 2 ）当需要对重新同步期间的意外切换，执行回切操作时，必须断开并删除重新同步关系。如果 MetroCluster 配置中有任何 SnapMirror DR 目标 SVM ，或者集群具有子类型 “dp-destination” 的 SVM ，则不允许使用回切。
