3. ActiveCluster架构与仲裁机制

Pure Storage FlashArray 的 ActiveCluster 是一种基于“双活阵列对”的同步复制架构。它把两台 FlashArray 组成一个逻辑集群，同一卷（Volume）在两个站点同时在线、同时可写，主机通过 MPIO 看到来自两个阵列的同一卷路径。任一站点故障时，主机 I/O 无需人工干预即可继续在存活站点完成，从而实现接近零 RTO 的故障切换。理解 ActiveCluster，关键要抓住三件事：双活写入如何保持一致性、仲裁见证（Mediator）如何防止脑裂、故障切换时主机与阵列如何协同。

双活原理：对称写入与一致性组

ActiveCluster 中，两台阵列通过专用复制链路（通常为 10/25/100GbE 或 FC）建立 Pod。Pod 是 ActiveCluster 的复制与一致性边界，卷被加入 Pod 后即成为“双活卷”。主机写入时，接收 I/O 的阵列称为该卷的“本地阵列”，它必须把写数据同步发送到对端阵列，对端写入其 NVRAM 并确认后，本地才向主机返回写完成。因此，双活卷的写入延迟包含一次站点间往返（RTT）。这也是为什么 ActiveCluster 对站点间链路 RTT 有明确要求：一般建议 RTT ≤ 5ms，最大不超过 10ms，否则主机写延迟会明显上升。

两个站点对同一卷都可写，但同一时刻只有一个阵列作为该卷的“首选阵列”（Preferred Array）。主机侧的 ALUA 路径状态会体现这一点：首选阵列上的路径为 Active/Optimized，对端为 Active/Non-Optimized。主机默认走优化路径，但非优化路径同样可承载 I/O，这正是“双活”而非“主备”的本质。当卷在 Pod 内被放入同一一致性组（Consistency Group），组内所有卷的写入顺序和故障切换动作保持一致，避免跨卷数据不一致。

仲裁见证 Mediator：防脑裂的第三方裁判

双活架构最大的风险是“脑裂”：站点间链路中断，但两台阵列都存活，各自认为对方故障，于是都继续接受写入，导致同一卷出现两份分叉数据。ActiveCluster 用 Mediator 解决这个问题。Mediator 是一台独立的仲裁见证设备，通常以 Pure 提供的 Mediator 虚拟设备形式部署在第三站点或第三方环境（如公有云、独立机房），它不承载任何用户数据，只负责在站点间失联时判定哪一侧应继续服务。

Mediator 的部署要求需要重点规划：

• 位置独立：Mediator 必须部署在独立于两个数据站点的故障域中，不能与任一 FlashArray 同机房、同供电或同网络出口，否则第三站点失去意义。
• 网络可达：Mediator 必须能同时被两台 FlashArray 的管理网络访问，通常使用管理口 IP 通信，端口为 TCP 443。建议为 Mediator 配置独立的管理网段或 VPN 通道。
• 资源规格：Mediator 虚拟设备通常分配 2 vCPU、4GB 内存、约 80GB 磁盘即可满足仲裁需求，关键是网络稳定而非算力。
• 高可用：Mediator 自身若单点故障，虽不会立即中断双活，但会削弱仲裁能力。生产环境建议对 Mediator 虚拟机做 HA 或准备快速恢复手段。
• 延迟要求：两台阵列到 Mediator 的 RTT 建议均小于 100ms，且两侧延迟尽量对称，避免仲裁偏向。

仲裁逻辑可以这样理解：正常时，两台阵列都定期向 Mediator 发送心跳；当站点间复制链路中断，两台阵列无法互相确认时，它们分别向 Mediator 询问“我是否可以继续服务”。Mediator 根据谁先到达、谁仍保持心跳等规则，只允许一侧继续提供双活卷服务，另一侧则把卷置为不可写，从而保证同一时刻只有一份可写数据。若 Mediator 本身也不可达，ActiveCluster 会进入“无仲裁”状态，此时通常采取保守策略，避免双方同时写入。

故障切换逻辑与主机侧行为

ActiveCluster 的故障切换分为几种典型场景。第一种是单台阵列故障：存活阵列检测到对端不可达，且 Mediator 确认对端确实失联后，存活阵列把双活卷提升为可写，主机侧原本指向故障阵列的路径失效，MPIO 将 I/O 切换到存活阵列的路径。由于卷在两个站点都有完整副本，切换过程通常只需数秒，主机应用基本无感。

第二种是站点间链路中断但两台阵列都存活：这是最需要 Mediator 的场景。两台阵列都向 Mediator 请求仲裁，Mediator 根据心跳和优先级规则，只允许一侧继续服务，另一侧将卷置为不可写。此时主机若尝试写入被禁止的一侧，会收到 I/O 错误，MPIO 会把 I/O 重定向到仍可写的一侧。待链路恢复后，两侧阵列重新同步，数据差异通过增量同步补齐，卷恢复双活可写状态。

第三种是 Mediator 不可达：如果站点间链路正常，两台阵列仍可互相确认，双活继续运行，Mediator 缺失不影响正常 I/O。但如果此时恰好站点间链路也中断，系统进入无仲裁状态，通常会采取保守策略，避免双方同时写入。因此，Mediator 的可用性检查应纳入日常运维。

仲裁节点规划与网络连通性检查

规划 Mediator 时，建议按以下要点逐项确认。首先确定部署位置：选择与两个数据站点都不同的第三故障域，可以是独立机房、托管区或公有云 VPC。其次规划 IP 与路由：为 Mediator 分配固定管理 IP，确保两台 FlashArray 的管理口都能路由到该 IP，且路径上无 NAT 或防火墙阻断 TCP 443。第三确认延迟：从两台阵列分别 ping Mediator，记录 RTT，建议两侧均小于 100ms 且差值不大。第四准备恢复方案：记录 Mediator 的部署位置、IP、登录方式，并定期验证其可启动、可访问。

网络连通性检查可以在 FlashArray 命令行或 GUI 中完成。以下示例展示在阵列侧验证到 Mediator 的连通性：

# 在 FlashArray A 上检查到 Mediator 的连通性（示例）
purearray> puremediator list --connectivity
Mediator Name    Status     RTT(ms)   Last Heartbeat
mediator-01      Connected  12        2s ago

# 手动触发一次仲裁状态查询（示例）
purearray> purepod list --arbitration
Pod Name     Preferred Array   Mediator Status   Arbitration State
pod-prod     FlashArray-A      Connected         Normal

# 从阵列管理口测试到 Mediator 的 TCP 443 可达性（示例）
purearray> ping 10.60.0.50
PING 10.60.0.50: 56 data bytes
64 bytes from 10.60.0.50: icmp_seq=0 ttl=62 time=11.8 ms

检查结果判读：若 Mediator 状态为 Connected 且 RTT 稳定，说明仲裁通道正常；若显示 Disconnected 或 RTT 持续偏高，应先排查路由、防火墙和 Mediator 虚拟机状态，再检查两台阵列到 Mediator 的路径是否对称。仲裁状态为 Normal 表示双活运行正常；若出现 Arbitration Lost 或类似告警，说明系统已进入无仲裁或单侧服务状态，需要立即处理。

最后需要强调，ActiveCluster 的双活能力建立在“站点间低延迟链路 + 独立 Mediator + 主机 MPIO 正确配置”三者之上。任何一环缺失，都可能导致切换变慢、仲裁失效甚至数据分叉。规划阶段把 Mediator 的位置、网络和延迟确认清楚，运行阶段把仲裁状态纳入监控，才能真正发挥双活架构的价值。