FC 存储环境下 vCenter 无法启动的排查与修复实战

适用环境：

• vCenter Server Appliance

• FC SAN（双交换 / 单交换均适用）

• 企业级阵列（如 Lenovo / EMC / HPE / Huawei 等）

• vSphere 7.x / 8.x

在 FC 存储架构中，vCenter Server 的稳定性不仅取决于自身服务状态，还高度依赖 FC 链路、LUN 状态以及多路径完整性。一旦维护过程中顺序错误，很容易出现“虚拟机能开，但 vCenter 起不来”的情况。

本文结合 FC 生产环境的实际经验，总结一次 vCenter 因 FC 存储异常导致服务无法启动的完整处理过程。

⸻

一、故障背景

1️⃣ 环境架构简述

• vCenter Server Appliance（VCSA）

• vCenter 虚拟机磁盘存放在 FC SAN LUN 上

• ESXi 主机通过 HBA 卡接入 FC 交换机

• 存储阵列对 ESXi 以 VMFS 方式提供 LUN

⸻

2️⃣ 异常操作场景

维护过程中存在以下不规范操作之一：

• FC 存储阵列先于 ESXi / vCenter 下电

• FC 交换机断电或重启

• vCenter 虚拟机仍运行时，存储 LUN 不可达

• 未确认多路径恢复即启动 vCenter

⸻

二、典型故障现象（FC 环境特有）

在 FC 架构下，vCenter 故障通常伴随以下特征：

• vCenter VM 可以开机，但启动极慢

• 控制台卡在某个启动阶段数分钟

• Web 页面 503 或直接无法访问

• vmware-vpxd 服务启动失败

• ESXi 主机日志提示 APD / PDL

⸻

三、FC 环境下的排查优先级（非常关键）

⚠️ FC 环境中，一定先确认“存储是否完全正常”，再动 vCenter 服务

推荐排查顺序：

存储 → FC 链路 → ESXi → vCenter 服务

⸻

四、详细排查与修复步骤

⸻

✅ 第一步：确认 FC 存储状态（最优先）

在存储阵列侧确认：

• vCenter 所在 LUN 是否已正常映射

• LUN 状态为 Online

• 未发生控制器切换或降级

• WWPN 映射未丢失

⚠️ 只要 vCenter 所在 LUN 不稳定，后续所有操作都是无效的

✅ 第二步：检查 ESXi 主机 FC 多路径状态

在 ESXi Shell 中执行：

esxcli storage core path list

关注字段：

• State: active

• Is Working: true

如果存在 dead、standby 异常路径，需先处理 FC 链路或交换机。

查看 LUN 状态：

esxcli storage core device list

✅ 第三步：确认 vCenter 虚拟机磁盘是否正常

在 ESXi Web / Host Client 中：

• 查看 vCenter VM 是否存在 I/O 错误

• 是否提示 datastore 不可达

• 磁盘是否显示异常延迟

若 datastore 曾出现 APD/PDL，建议 等待 5~10 分钟 再启动 vCenter。

⸻

✅ 第四步：启动 vCenter 后检查服务状态

进入 vCenter 控制台：

service-control --status --all

FC 环境中常见问题是：

• vPostgres 数据库未能及时启动

• vpxd 因数据库连接超时而失败

⸻

✅ 第五步：避免“存储未稳就重启服务”的错误操作

❌ 错误做法：

• FC 链路刚恢复就立即重启 vCenter

• 反复 service-control --start --all

✔ 正确做法：

• 确认 ESXi 上 所有 FC 路径稳定

• 等待 datastore I/O 正常

• 再启动 vCenter 服务

⸻

✅ 第六步：日志中 FC 相关的典型错误

重点查看：

/var/log/vmware/vpxd/vpxd.log

/var/log/vmware/vpostgres/postgresql.log

常见 FC 诱发错误包括：

• 数据库 I/O timeout

• 文件系统短暂只读

• 存储延迟导致服务依赖启动失败

⸻

五、问题根因分析（FC 环境总结）

本次问题本质

• FC 存储恢复晚于 vCenter 启动

• 多路径未完全恢复

• vCenter 数据库启动时访问 LUN 超时

• 服务依赖失败后未自动重试

⸻

六、FC 环境下的标准关机 / 启动 SOP（强烈建议收藏）

✔ 关机顺序（FC）

1. 关闭所有业务虚拟机

2. 关闭 vCenter Server

3. 关闭 ESXi 主机

4. 最后维护 FC 交换机和存储阵列

⸻

✔ 启动顺序（FC）

1. 启动存储阵列（确认 LUN Online）

2. 启动 FC 交换机

3. 启动 ESXi 主机

4. 确认多路径正常

5. 最后启动 vCenter Server

⸻

七、运维经验总结（FC 环境血的教训）

• FC 环境最怕“顺序错误”

• vCenter 问题 70% 源于底层存储未完全恢复

• 服务问题≠服务本身坏了

• 存储一不稳，vCenter 一定出事

⸻

八、结语

在 FC 架构中，vCenter 更像“最上层的指挥官”，而 FC 存储是地基。

地基没稳，指挥部永远起不来。

把存储状态检查放在服务之前，是 FC 环境最重要的运维思维。