欢迎来到 Microsoft Q&A。
感谢您提出这个问题。
根据您的描述,为了确定意外的群集迁移或故障转移(Failover)为何超出了内部 SLA,建议通过关联源节点群集日志、目标节点群集日志、系统事件日志以及工作负载相关日志(应用程序、数据库、存储等),构建一条统一的时间线。
为了简化分析,建议使用本地时间戳生成群集日志:
Get-ClusterLog -UseLocalTime -Destination C:\ClusterLogs
之后,可以将整个中断过程拆分为以下几个时间阶段进行分析:
1. 初始故障时间(Initial Failure Time)
识别第一个表明底层问题的事件,例如:
- 健康检查失败(Health Check Failure)
- 资源故障(Resource Failure)
- 心跳丢失(Lost Heartbeat)
- 网络通信故障(Network Communication Failure)
- 节点驱逐(Node Eviction)
检查故障转移群集(Failover Clustering)事件(例如 Event ID 1069、1146 和 1230),并将其与群集日志中的以下条目进行关联:
- IsAlive has indicated failure
- IsAlive sanity checks failed
2. 故障检测时间(Failure Detection Time)
测量从首次观察到故障到群集将节点、资源或角色标记为失败之间的时间间隔。此阶段通常包括:
- 心跳监控(Heartbeat Monitoring)
- 健康检查(Health Checks)
- 重试机制(Retries)
- 超时处理(Timeout Processing)
- 故障阈值评估(Failure Threshold Evaluation)
如果该阶段耗时最长,应重点检查网络延迟、健康检查配置以及资源响应能力。
3. 成员资格与仲裁时间(Membership and Quorum Time)
测量故障发生后,存活节点建立有效群集成员关系并维持或重新获得仲裁(Quorum)所需的时间。
重点查找以下事件和日志条目:
- Lost quorum
- Cluster service has terminated
- 节点移除消息(Node Removal Messages)
- 成员重新加入事件(Membership Rejoin Events)
其中,Event ID 1135 和 1177 通常与节点移除及仲裁丢失有关。
由于群集在没有足够仲裁票数的情况下无法继续正常运行,因此应单独分析仲裁阶段。见证(Witness)配置和节点投票设置将直接影响故障转移行为和恢复时间。
4. 故障转移决策与组迁移时间(Failover Decision and Group Move Time)
测量从达成稳定成员关系/仲裁状态到开始角色所有权转移之间的时间间隔。查找以下日志关键字:
- Group move
- Move of group
- 资源所有权变更(Resource Ownership Changes)
该阶段用于确定群集选择目标节点并启动故障转移所需的时间。
5. 资源离线与清理时间(Resource Offline and Cleanup Time)
测量在原拥有节点上停止、清理及释放资源所花费的时间。
重点检查:
- 重复离线尝试(Repeated Offline Attempts)
- 挂起状态(Pending States)
- Resource Hosting Subsystem(RHS)活动
- 超时事件(Timeout Events)
即使故障检测速度很快,过长的清理过程仍可能显著延迟恢复时间。
6. 资源启动时间(Resource Startup Time)
在目标节点上,测量从首次 Online 请求发出到所有依赖资源成功联机所需的时间。
检查以下依赖资源的启动顺序:
- 存储(Storage)
- IP 地址(IP Address)
- 网络名称(Network Name)
- 数据库或应用服务(Database or Application Services)
- 面向客户端的资源(Client-facing Resources)
重点查找以下日志条目:
- Resource <name> has come online
- Group move for <name> has completed
- Online for resource <name> failed
7. 应用程序恢复时间(Application Recovery Time)
测量从群集角色状态变为 Online 到应用程序真正可以处理请求之间的时间。
请注意,群集资源显示为 Online 并不一定意味着应用程序已经完全就绪。应用程序可能仍在执行以下操作:
- 初始化(Initialization)
- 恢复过程(Recovery)
- 缓存预热(Cache Warmup)
8. 客户端服务恢复时间(Client Service Restoration Time)
测量从应用程序准备就绪到第一个成功的客户端连接或健康探测完成之间的时间。
此阶段有助于发现以下原因造成的延迟:
- DNS 注册
- Listener 可用性
- 身份验证处理
- 客户端重试间隔
- 应用程序预热流程
9. 关键指标(Key Metrics)
Failure Detection Duration
= Cluster failure declaration - First observable fault
Membership/Quorum Duration
= Stable membership or quorum - Cluster failure declaration
Group Move Duration
= Destination online request - Failover decision
Resource Startup Duration
= Last required resource online - First destination online request
Application Recovery Duration
= Application ready - Clustered role online
End-to-End Outage Duration
= First observable service impact - First successful client operation
将端到端中断时长(End-to-End Outage Duration)与您的 SLA 进行比较,同时也应将每个独立阶段与已知正常的故障转移基线(Baseline)进行对比。这有助于确定延迟究竟发生在哪个环节,例如:
- 故障检测(Failure Detection)
- 仲裁处理(Quorum Processing)
- 所有权转移(Ownership Transfer)
- 资源启动(Resource Startup)
- 应用程序恢复(Application Recovery)
- 客户端重新连接(Client Reconnection)
如果最大的延迟出现在以下阶段,请重点关注对应的组件:
- 在故障被正式判定之前: 检查心跳机制(Heartbeat)以及健康检测(Health Check)行为。
- 在仲裁形成期间: 检查节点间通信情况以及 Witness(见证资源)的可用性。
- 在组迁移(Group Move)之后: 检查依赖资源启动情况、存储性能、应用程序初始化过程以及资源联机失败问题。
建议在进行完整的根本原因分析(Root Cause Analysis)时,收集以下信息:
- 群集日志(Cluster Logs)
- Application 事件日志
- System 事件日志
- FailoverClustering 事件日志
- 群集验证报告(Cluster Validation Report)
- 资源状态信息(Resource States)
- 网络和存储运行状况信息(Network/Storage Health Information)
重要提示: 在执行时长分析之前,请确保所有节点均同步到同一时间源,并将所有日志时间戳统一转换到相同的时区。节点之间的时间差异可能导致故障转移调查过程中时间线重建不准确。
更多信息请参阅:
Get-ClusterLog (FailoverClusters) | Microsoft Learn
Windows Server 群集故障转移运行状况服务故障排除指南 - Windows Server | Microsoft Learn
排查意外群集故障转移问题指南 - Windows Server | Microsoft Learn
在 Windows Server 中在没有仲裁的情况下恢复故障转移群集 | Microsoft Learn
排查 AlwaysOn 可用性组的故障转移问题 - SQL Server | Microsoft Learn
了解 Azure 本地群集和 Windows Server 群集上的群集和池仲裁 | Microsoft Learn
Windows Server 群集故障转移运行状况服务故障排除指南 - Windows Server | Microsoft Learn
如果此回答对您有所帮助,请考虑点击 “接受答案(Accept Answer)” 。
感谢您使用 Microsoft Q&A!