4. 高可用与故障域设计

在 NetApp ONTAP 的统一文件与块存储系统设计中，高可用不是单一功能，而是由多个层次叠加而成的故障域体系。理解这些层次的关键，是分清“什么故障由谁接管、接管需要多长时间、接管后数据是否仍然一致”。本章围绕 HA Pair、集群互连、ONTAP Mediator、MetroCluster IP 与 MetroCluster FC 五类机制，说明它们的部署场景与切换逻辑。

一、HA Pair：节点级故障域的第一道防线

HA Pair 是 ONTAP 最基础的冗余单元。两个节点通过集群互连（cluster interconnect）直连，并共享一组磁盘架。正常情况下，两个节点各自拥有本地磁盘的所有权，同时互为接管伙伴。当其中一个节点发生电源、主板、ONTAP 内核或网络路径故障时，存活节点会执行 takeover，把故障节点的 LUN、卷和逻辑接口（LIF）接管过来，继续对外提供服务。

HA Pair 的切换是“本地”的：数据不需要跨站点复制，因为两个节点访问的是同一组磁盘。接管后，存活节点通过 HA 互连访问故障节点的磁盘，因此 HA 互连本身必须低延迟、高带宽，通常使用专用万兆或更高速链路，且不应与业务数据网络混用。判断 HA 是否健康，可以观察 storage failover show 中的 Takeover Possible 是否为 true，以及 HA 互连的链路状态和丢包计数。

需要强调的是，HA Pair 只解决节点级故障，不解决机架级、站点级故障。如果两个节点位于同一机架、同一供电回路，机架掉电仍会导致整个 HA Pair 不可用。因此故障域设计必须继续向上叠加。

二、集群互连与集群级故障域

多个 HA Pair 组成一个 ONTAP 集群，节点之间通过集群互连（cluster network）通信。集群互连承载集群心跳、配置同步、卷位置信息和跨节点数据访问。它与 HA 互连不同：HA 互连是“伙伴之间”的直连，集群互连是“集群内所有节点”的交换网络。

集群互连的故障域设计要点是：交换机应双上联、双电源，节点应至少两条链路分别接入不同交换机。如果集群互连完全中断，节点可能被判定为“失去集群”，触发隔离（quorum）机制。ONTAP 使用 epsilon 和 quorum 来避免脑裂：当节点数较少时，可通过 cluster quorum 查看投票状态。对于两节点集群，通常需要借助 ONTAP Mediator 或外部仲裁来避免双方都认为自己应继续服务。

三、ONTAP Mediator：两节点集群的仲裁者

ONTAP Mediator 是部署在第三方站点（或云上）的轻量仲裁组件，用于两节点 ONTAP 集群。它不存储用户数据，只参与 quorum 投票。当两个节点之间的集群互连中断时，Mediator 帮助判断哪一侧应继续服务，从而避免两个节点同时接管、造成数据不一致。

典型部署场景是：两个节点分别位于两个机房，通过集群互连和业务网络互联，Mediator 部署在第三个故障域。当站点间链路中断时，能联系到 Mediator 的节点保留服务，联系不到的一侧停止服务。Mediator 的价值在于把“两节点无法形成多数”的问题转化为“第三方仲裁”，使两节点集群也能具备站点级容错判断能力。

四、MetroCluster IP 与 MetroCluster FC 的部署场景

MetroCluster 是 ONTAP 的跨站点高可用方案，目标是在一个站点整体故障时，由另一站点接管并继续提供数据访问。它分为两种形态：MetroCluster FC 和 MetroCluster IP。

MetroCluster FC 使用 FC 交换机或 FC 直连，把两个站点的磁盘架通过 FC 链路互联，并配合 FC-VI 适配器同步节点间的数据。它的特点是数据路径基于 FC，适合已有 FC 基础设施、对延迟和稳定性要求极高的场景。MetroCluster IP 则使用 IP 网络承载站点间复制和磁盘访问，通常基于以太网交换机，部署成本更低、扩展更灵活，适合希望复用 IP 网络或跨较远距离部署的场景。

两者的共同点是：两个站点各有一套完整的控制器和存储，站点间持续同步。正常运行时，本地站点处理本地 I/O，同步复制保证两端数据一致。发生站点故障时，对端站点接管，业务 LIF 迁移到存活站点，客户端通过 DNS 或 LIF 重定位继续访问。

五、切换机制与结果判断

不同层次的切换机制可以归纳为：HA Pair 是节点接管，集群互连是 quorum 判断，Mediator 是两节点仲裁，MetroCluster 是站点切换。切换是否成功，不能只看“服务是否恢复”，还要看数据一致性和切换时间。

以 MetroCluster 为例，切换后应检查：metrocluster show 中两端状态是否正常，metrocluster check run 是否通过，以及业务 LIF 是否已在存活站点上线。对于 HA Pair，接管后应确认 storage failover show 中 State 为 takeover，并检查被接管卷的可用性。对于 Mediator，应确认 mediator show 中连接状态为 connected，且 quorum 判断符合预期。

从设计角度看，这四层不是互斥的，而是叠加的：一个生产集群通常同时具备 HA Pair、集群互连和 quorum 机制；如果业务要求跨站点容灾，再叠加 MetroCluster 和 Mediator。每一层都要单独验证，不能因为上层存在就忽略下层。例如，MetroCluster 站点切换成功，不代表 HA Pair 的本地接管一定正常；反之亦然。只有把每一层的切换条件、切换时间和数据一致性都验证清楚，故障域设计才算真正闭环。