故障现象描述
在企业IT基础设施中，Microsoft Exchange Server 2019 通常部署于可用性组（Database Availability Group, DAG）架构以实现高可用性。近期，某中型企业IT团队遇到一个典型且棘手的故障：DAG中的第二台服务器（EXCH-DAG-02）在经历短暂的网络波动或重启后，未能自动重新加入群集，而是长期处于“离线”状态。在Exchange管理控制台（EMC）及PowerShell中，该节点显示为 Persistent Down（持续离线），而非暂时的 Degraded 或 FailedOver。尽管第一台节点（EXCH-DAG-01）正常运行，但数据库副本在该离线节点上无法同步，且由于仲裁机制受损，存在数据丢失风险。
根本原因分析
DAG底层依赖于Windows Server Failover Cluster（WSFC）。当节点出现“持续离线”时，通常由以下核心原因导致：
- 仲裁配置失衡： DAG依赖“多数派”（Quorum）模型来防止脑裂。如果见证服务器（Witness Server）或见证目录（Witness Share Folder）访问异常，导致仲裁票数统计错误，群集可能判定自身无法形成法定多数，从而将某些节点标记为持久离线以保护数据安全。
- 网络心跳中断： WSFC依赖于专用心跳网络进行节点间通信。若DAG复制流量与心跳流量共用同一物理接口或VLAN，且发生拥塞或配置错误，会导致心跳包丢失，触发群集错误。
- 群集服务状态异常： 目标节点上的Cluster Service可能因依赖项（如RPC服务、DNS客户端）启动顺序问题或注册表损坏而未能正确响应群集请求。
排查与修复步骤
第一步：检查群集资源与仲裁状态
首先，需要在正常运行的节点或管理站上使用PowerShell确认当前的仲裁配置。登录到任意一台健康的Exchange服务器，以管理员身份打开Exchange Management Shell，执行以下命令：
# 查看DAG节点的群集健康状态 Get-ClusterNode -Cluster
如果看到目标节点状态为 PersistentDown，接着检查仲裁配置：
# 查看当前仲裁模式和见证设置 Get-ClusterQuorum | Format-List *
确认 QuorumResource 指向的见证服务器或文件共享目录是否可达。同时，使用 Test-ServiceHealth 和 Test-ReplicationHealth cmdlet 检查整体复制健康状态。
第二步：验证网络连通性与防火墙规则
节点离线常源于底层网络问题。需确保两台DAG节点之间、以及节点与见证服务器之间的特定端口畅通：
- TCP 3343： 用于集群心跳通信。
- TCP 64327： 动态端口，用于集群内部通信。
- SMB (TCP 445)： 用于访问文件共享见证服务器。
在离线节点和在线节点上分别执行 Test-NetConnection -ComputerName -Port 3343 进行测试。如果连接失败，需检查组策略或硬件防火墙是否拦截了这些端口。此外，确保两台服务器的网卡“绑定”设置一致，且DAG专用网络未启用无关的协议（如IPX/SPX等）。
第三步：尝试手动重启群集服务
若网络和仲裁配置无误，可尝试在离线节点上手动重启群集服务，使其重新加入群集：
# 在离线节点EXCH-DAG-02上执行 Restart-Service Clussvc -Force
重启后，观察 Get-ClusterNode 的输出。如果节点变为 Up 但状态仍为 PersistentDown，则需要进行更深入的群集对象重置。
第四步：强制移除并重新添加节点（关键步骤）
当自动恢复无效时，必须通过PowerShell强制将该节点从DAG中移除，修复其群集身份后，再重新添加。此操作不会删除数据库副本数据，但会暂时中断该节点上的复制。
- 移除节点： 在管理节点执行：
Remove-DatabaseAvailabilityGroupServer -Identity DAGName -MailboxServer EXCH-DAG-02 -Force - 清理旧群集配置： 进入离线节点的“故障转移集群管理器”，确认该节点所在群集资源组已被清除。如果有残留的“DAG-FileShareWitness”资源，请右键删除。
- 重置节点身份： 在离线节点上，以管理员身份运行：
Reset-ClusterNode -Name EXCH-DAG-02 - 重新添加节点： 回到管理节点，将服务器重新加入DAG：
Add-DatabaseAvailabilityGroupServer -Identity DAGName -MailboxServer EXCH-DAG-02
第五步：恢复仲裁与数据库同步
节点重新上线后，初始状态可能是 Disconnected。此时需确保见证服务器配置正确。若之前见证服务器不可用，建议将其迁移至更稳定的文件服务器或Azure Blob Storage。
最后，初始化数据库副本同步：
# 对所有数据库副本启动初始同步 Get-MailboxDatabaseCopyStatus -Server EXCH-DAG-02 | Start-DatabaseCopy
监控同步进度，直至所有副本状态变为 Healthy 且 InSync。
预防措施与建议
为避免此类故障再次发生，建议采取以下措施：
- 独立心跳网络： 务必为WSFC心跳流量配置专用的VLAN或物理网卡，避免与DAG复制流量争抢带宽。
- 定期维护检查： 每月运行一次
Test-ReplicationHealth和Test-Cluster，提前发现潜在的网络或磁盘I/O瓶颈。 - 见证点冗余： 对于生产环境，推荐使用基于Azure Blob存储的见证点，相比传统文件共享见证，其受本地网络故障影响更小，能提供更稳定的仲裁服务。
通过上述标准化的排查与恢复流程，IT管理人员可以高效解决Exchange DAG节点持续离线的问题，保障邮件系统的高可用性与数据完整性。