1. 课程导入与故障诊断全景

vSphere 复杂故障并不是“某台虚拟机宕机”这类单点问题，而是指在计算、存储、网络、集群服务、权限与外部依赖多个层面同时或先后出现异常，且故障现象之间存在因果耦合、时间错位或相互掩盖的一类问题。它的典型特征是：告警很多但根因只有一个；表面现象与真实故障点不在同一层；重启某个组件后问题短暂消失又复发。因此，本课程的核心不是背命令，而是建立一套可复用的诊断思维框架，把“救火”变成“定位—隔离—恢复—验证”的闭环。

一、复杂故障的典型场景

在真实生产环境中，复杂故障通常集中在以下几类场景：

• 集群级 HA/DRS 异常：主机被误判为隔离，HA 触发大量虚拟机重启，但重启后仍无法访问存储，形成“重启风暴”。
• 存储路径与 APD/PDL：光纤或 iSCSI 路径抖动导致全部路径死亡（APD），虚拟机 I/O 挂起，但 vCenter 仍显示主机“已连接”。
• 网络与分布式交换机：上行链路、VLAN、MTU 或 NIOC 配置不一致，导致 vMotion、FT、iSCSI 流量互相干扰。
• vCenter 与 PSC 依赖：STS 证书过期、SSO 域故障、数据库连接池耗尽，使登录、任务、告警全部失效。
• 权限与编排叠加：自定义角色缺少某对象权限，自动化脚本批量失败，误判为平台故障。

这些场景的共同点是：故障点往往不在最先报警的组件上。例如存储 APD 会先表现为虚拟机卡顿，再表现为 HA 重启，最后才在存储路径状态中暴露。诊断时必须按“时间线 + 依赖链”回溯，而不是按告警数量排序。

二、业务恢复目标与优先级

复杂故障处理中，业务恢复目标必须先于技术修复明确。通常按 RTO（恢复时间目标）和 RPO（恢复点目标）划分优先级：核心交易系统 RTO 可能只有 15 分钟，RPO 接近 0；内部测试环境 RTO 可放宽到数小时。诊断顺序应遵循“先恢复业务、再定位根因、最后消除隐患”。

具体操作上，可先判断是否具备快速切换条件：若存在 SRM 保护组或备份副本，优先执行计划内恢复；若没有，则评估能否通过重启管理代理、重新挂载存储或迁移虚拟机恢复。需要强调的是，任何恢复动作前都应记录当前状态，包括主机连接状态、存储路径、虚拟机清单和最近任务，避免二次破坏现场。

三、诊断思维框架：分层、依赖、时间线

本课程采用“三层三线”诊断框架。三层指计算层、存储层、网络层；三线指依赖线、时间线、证据线。诊断时先画依赖关系，再按时间排序事件，最后用日志和指标验证假设。

以“虚拟机批量重启”为例，依赖线为：vCenter → ESXi 主机 → HA 代理 → 存储路径 → 虚拟机。时间线为：存储路径抖动 → 主机心跳丢失 → HA 判定隔离 → 虚拟机重启 → 存储仍不可用 → 重启失败。证据线为：vobd.log 中的 APD 事件、vmkernel.log 中的路径状态、vpxd.log 中的 HA 任务。只有三条线交叉验证，才能确认根因是存储路径而非 HA 配置。

四、关键工具与数据来源

vSphere 复杂故障诊断依赖以下数据源：

• vCenter 任务与事件：提供操作时间线和触发者，但可能因服务故障缺失。
• ESXi 日志：vmkernel.log、vobd.log、hostd.log、fdm.log，分别对应内核、HA、主机代理和 HA 代理。
• 存储路径状态：esxcli storage core path list、esxcli storage nmp device list。
• 网络与性能：esxtop、vmkping、net-dvs、pktcap-uw。
• 支持包：vm-support 生成的 bundle，适合离线分析。

下面用一张关系图概括复杂故障中“现象—依赖—根因”的对应关系，帮助在诊断初期快速定位方向。

五、诊断记录模板

为了让诊断过程可追溯、可复盘，建议在故障处理时直接填写以下记录表。字段只保留与 vSphere 复杂故障直接相关的信息，避免引入无关管理字段。

六、常见误判与规避

复杂故障中最危险的误判是“按告警数量排序”。例如 vCenter 同时出现 200 条告警，其中 180 条是虚拟机心跳丢失，真正根因可能只是存储路径抖动。规避方法是：先看时间最早的事件，再看依赖链最底层的组件，最后用日志交叉验证。

另一个常见误判是“重启解决一切”。重启 vCenter 或 ESXi 主机可能暂时清除告警，但若根因是证书过期或存储路径配置错误，问题会在数小时或数天后复发，且现场证据已被破坏。因此，重启前应尽量导出支持包和日志。