2. vSphere核心组件回顾

在复杂故障诊断中，最容易走弯路的情形往往不是“不会查”，而是“查错了层”。vSphere 并不是一个单体系统，而是由计算、管理、存储、网络四类平面叠加而成的分布式平台。ESXi 提供虚拟化执行环境，vCenter Server 提供集中管理与编排，vSAN 把本地磁盘聚合成分布式存储，NSX 把网络与安全从物理设备中抽象出来。它们之间既有明确的依赖方向，也存在反向影响：存储抖动会拖慢管理操作，网络异常会让 vSAN 误判磁盘故障，vCenter 证书过期又可能让整个集群“看起来全挂”。因此，诊断的第一步不是敲命令，而是先建立一张“谁依赖谁、故障沿哪条路径传播”的组件关系图。

各组件在诊断中的角色定位

ESXi 是故障的最终落点。所有虚拟机最终运行在某个 ESXi 主机的 VMkernel 上，CPU 调度、内存回收、设备队列、PSOD 紫屏、vmkernel.log 与 vobd.log 都发生在这里。诊断时 ESXi 提供最底层的事实：主机是否在 DCUI 可达、管理网络是否通、存储路径是否 Active、HBA 是否上报链路抖动。它既是故障的受害者，也是唯一能给出硬件级证据的地方。

vCenter Server 是控制平面，不是数据平面。虚拟机磁盘 I/O 不经过 vCenter，但几乎所有管理动作——DRS 迁移、HA 重启、克隆、快照、权限校验——都要经过它。因此 vCenter 故障的典型表现是“业务还在跑，但什么都管不了”。诊断时要区分：是 vCenter 服务本身异常（如 STS 证书、VPXD 进程、PostgreSQL），还是它依赖的下游（ESXi 失联、DNS 解析失败）导致它无法工作。

vSAN 是分布式存储平面。它把每台主机的本地磁盘组成磁盘组，通过 vSAN 网络在主机间复制数据。vSAN 的健康同时依赖三件事：磁盘组状态、vSAN VMkernel 网络、集群成员一致性。任何一项异常都会触发组件状态变化，例如“降级但可用”“不可用”“重建中”。诊断 vSAN 必须同时看 RVC/CLI 的组件状态与网络连通性，不能只看容量告警。

NSX 是网络与安全平面。它通过传输节点、逻辑交换机、分布式防火墙和 Edge 网关提供东西向与南北向流量控制。NSX 故障常表现为“虚拟机之间不通但 ping 网关正常”或“DFW 规则未生效”。诊断时要沿控制平面（NSX Manager、控制器）与数据平面（传输节点、TEP、VNI）两条线分别排查。

依赖关系与故障传播路径

这些组件之间的依赖不是单向的，而是形成了一张有向图。理解这张图，就能在故障时快速判断“先查谁、后查谁”。下面这张图展示了核心组件之间的依赖方向与典型故障传播路径。

诊断顺序与依赖倒查

基于上面的依赖图，实际诊断应遵循“自下而上确认事实，自上而下核对配置”的原则。第一步永远是确认物理层：存储 HBA 是否上报链路抖动、物理交换机端口是否有 CRC 错误、MTU 是否端到端一致。这些事实不依赖任何 vSphere 组件，却决定了上层是否稳定。第二步查 ESXi 本地状态：esxcli storage core path list 看路径是否 Active，esxcli network vm list 看 VMkernel 接口是否正常，vmkernel.log 中是否有 ScsiDeviceIO 超时。第三步查 vSAN 与 NSX 的数据平面：vSAN 用 esxcli vsan cluster get 和 RVC 的 vsan.obj_status_report 看组件状态，NSX 用 get logical-switch 和 TEP 连通性测试确认隧道是否通。最后才回到 vCenter 控制平面，检查 STS 证书、VPXD 服务、DNS 解析和数据库连接。

关键依赖参数速查

需要特别强调的是，依赖关系是双向的。vCenter 依赖 ESXi 上报状态，但 ESXi 的 HA 代理也依赖 vCenter 下发策略；vSAN 依赖网络承载复制流量，但 NSX 的分布式防火墙又可能拦截 vSAN 的 TEP 通信。在诊断中如果只沿一个方向查，很容易在“看起来正常”的组件上反复打转。正确做法是：先锁定故障现象属于哪个平面，再沿依赖图向上游和下游各查一层，用日志和状态数据交叉验证，而不是凭经验猜测。