企业官网建设流程全解析

本来一切正常的 vCenter Server，某天突然连登录页面都进不去了。我遇到过最典型的场景是：生产环境早上突然收到告警，说业务访问异常，打开 vSphere Client 发现连接直接超时，Web 端始终转圈；转向 5480 的 VAMI 管理页倒是能进去，但点开“服务”标签页的一瞬间，心里就咯噔一下——一长串服务挂着 invalid。

这个页面我劝你先别急着点重启。invalid 不是“服务坏了”这么简单的一个状态描述，它背后牵着一整条服务依赖链，也经常是磁盘、时间、认证、数据库某一处出了问题的最终体现。这篇文章就围绕“页面上大量服务显示 invalid”这个现象，从排查思路到具体修复步骤一条线捋下来，适合正在处理同类故障的虚拟化运维人员，也适合准备接手 vCenter 日常维护的工程师收藏备用。

1. 页面打不开、服务页一片 invalid：先把现象量化到可排查

故障处理的第一步永远是“搞清楚现在到底是个什么状态”，而不是急着动手。很多人在 VAMI 看到一堆 invalid 就想去重启服务，结果重启到一半又失败，反而把现场破坏了，后面查日志都查不到根因。

1.1 三个入口都试一遍：VAMI、vSphere Client、SSH

vCenter Server 这个产品至少有三个入口可以观察它的健康状态，每个入口看到的信息层级不一样。遇到故障时三个入口都要试，并且记录各自的表现，这是判断故障范围的关键。

我遇到的大部分情况是 vSphere Client 完全进不去，但 5480 还能勉强打开，说明控制面服务（vmon、VAMI 这套）还活着，但业务面的核心服务已经掉的差不多了。如果 5480 也打不开，问题往往更底层，例如 vmon 本身不在运行、系统级资源耗尽或网络异常。

1.2 先记录是哪些服务 invalid，而不是急着重启

打开服务页后，先把 invalid 和 stopped 的服务列表截个图，或者抄下来。不同主机上 VCSA 的服务列表不完全一样，但常见的那几个你在任何一套环境里都会遇到：

• vpxd：vCenter Server 主服务，负责 ESXi 主机和虚拟机管理，它挂了整个平台就瘫了。
• vpostgres：嵌入式 PostgreSQL 数据库，所有 vCenter 数据都存在里面。
• vsphere-ui：新版本 Web Client 界面服务，登录页面能不能显示全看它。
• sps / vdcs：存储策略服务、内容库服务，属于扩展功能模块。
• vmware-vmafd / vmcad / vmdir：认证框架、证书颁发、身份目录，这三个是“底座中的底座”。

记录的时候要多想一步：这些服务之间是什么依赖关系。vpxd 要起来，必须先有 vpostgres 能连、认证栈（vmafdd、vmcad、vmdir）能签发令牌，vsphere-ui 又在 vpxd 之上。所以如果整页都是 invalid，突破口往往不在最上层的 vpxd，而在它下面挂着的公共依赖。

2. invalid 不是一句“服务坏了”，背后是 vmon 的状态机

很多第一次接触 VCSA 的人会拿 Windows 服务的思路去理解这个状态，总觉得“查一下服务依赖图，把没启动的启动一下就好了”。但 VCSA 里这套服务编排机制跟 Windows 差别很大，理解了底层机制以后，才能知道 invalid 到底意味着什么。

2.1 VCSA 的服务骨架：vmon、VAMI、systemd 各管什么

VCSA 从 6.5 开始内置的服务管理框架叫vmon（VMware Service Manager）。它负责服务的生命周期管理、健康状态跟踪、启动顺序编排和故障迭代重启。VAMI 5480 页面里的服务列表，就是由 vmon 聚合出来的状态展示。

到了 VCSA 7.0 及以后，底层跑的还是 Linux systemd，但 systemd 管理的进程其实只有很少几个底层服务，其中最关键的是vmonit这个守护进程。绝大部分 vCenter 服务（vpxd、vpostgres、vsphere-ui 等）都是由 vmon 拉起和监控的，而不是直接写 systemd unit。所以你就算在 shell 里用systemctl status vpxd也查不到什么有意义的信息，正确姿势是用service-control这个封装好的命令。

invalid 在这个状态机里到底什么意思？从实际表现来看，vmon 把服务状态标成 invalid，通常发生在三种情况：状态文件读不出来、服务启动脚本无法解析、或进程状态与预期严重不一致。举个例子，服务已经死掉但 pid 文件残留，vmon 去检查时发现“进程不在但 pid 文件还在”，这种对不上号的中间状态，显示出来就是 invalid。

2.2 大量服务同时 invalid：优先找公共依赖

单一服务 invalid 可以聚焦到那个服务本身，但如果页面上一次出现七八个服务全是 invalid，基本可以断定问题出在公共层。我自己排查下来，公共层无非下面这几类：

• 磁盘写满：vmon 每做一次状态变更都要往状态目录写文件，服务本身也要写日志。磁盘空间没了，状态文件写不进去，服务启动到一半失败，最后被标记成 invalid。
• 时间不同步：VCSA 服务之间的认证、令牌校验对时间偏差极其敏感，偏差超过默认容差后，认证栈签出来的令牌全部失效，依赖认证的所有服务集体启动失败。
• 认证 / 证书服务异常：vmafdd、vmcad、vmdir 这三个是 vCenter 身份体系的支柱，任何一个异常，上层服务一个都起不来。
• vmon 自身的状态库异常：/var/opt/vmware/vmon/ 下的状态文件如果被写坏，vmon 对现有服务全部失去判断依据，页面就会整片刷 invalid。

公共依赖的选择其实有一条符合直觉的判断顺序：先看硬件资源够不够，再看时间准不准，接着查认证，最后看数据库。这个顺序务必在脑子里固化下来，因为它能让排查效率明显提升。

3. 我的排查顺序：磁盘、时间、日志、进程，一层层剥开

故障排查讲究一个“先定位，再修复”。我从 invalid 现象出发的排查链路基本是固定的五步，而且在大多数场景里，前两步就能直接命中问题。

3.1 五条命令快速定位系统基本面

拿到 VCSA 的 shell（SSH 或控制台）之后，不要到处翻日志，先跑下面这组命令，把基本面看清楚：

df -h free -h timedatectl ntpq -pn # 或者 chronyc sources uptime

这一组命令里，我最先看的是df -h。说实话，生产环境里 vCenter 突然大量服务异常，磁盘满的占比相当高。VCSA 默认分区布局里，/storage/log、/storage/seat、/storage/archive 是典型的“日志重灾区”，尤其是 /storage/log 分区，默认给的容量本来就不算大，如果部署时图省事选了个小容量规格，日志增长一两年后就可能塞满。

timedatectl这步很多人会跳过，但我建议别跳。VCSA 服务之间用的是证书和令牌互相验证，时间一偏整个信任链全断，表现出来就是 vpxd、vsphere-ui 全 invalid，但日志里只有一堆看似莫名其妙的“token validation failed”。

3.2 从 vmon 日志追到具体服务的真实报错

基本面检查做完，如果还没定位到根因，就要去翻 vmon 自己的日志了，它记录着每个服务被拉起和被判 invalid 的原因：

tail -n 200 /var/log/vmware/vmon/vmon.log

vmon 日志会非常直接地告诉你服务失败时的退出码、启动超时还是状态检查失败。看到类似 “No space left on device” 的报错，可以投奔磁盘问题；看到超时类错误，多半和服务启动慢、数据库起不来有关。

针对最核心的那几个服务，再单独看它们的业务日志：

tail -n 200 /var/log/vmware/vpxd/vpxd.log tail -n 100 /var/log/vmware/vpostgres/pg.log tail -n 100 /var/log/vmware/vmafd/vmafd.log

这里有个读日志的小技巧：不要从头刷到尾，先看最后 50 行左右，把里面最后一组连续报错的原因搞清楚，然后往上翻一点找这个报错第一次出现的位置。如果日志末尾是“connection refused”指向本机 5432 端口，那就去查 vpostgres 的状态；如果是证书相关报错，时间同步和认证栈就是重点。

3.3 CLI 与 UI 状态不一致时要留个心眼

排查中还会遇到一种情况：VAMI 页面上服务显示 invalid，但 SSH 里执行状态查询，发现服务实际是 running 的。这种“假 invalid”很可能不是服务本身坏了，而是前端展示或会话层出了问题。

判断方法很简单，在 shell 里执行：

service-control --status --all

对比 CLI 输出和 VAMI 页面。如果 CLI 大部分服务都是 running，只有 VAMI 显示 invalid，先硬刷新一下浏览器（Ctrl+F5），或者换个无痕窗口重新登录 5480 再看。如果刷新后仍不一致，那问题基本出在前端链路上，例如 vsphere-ui 或 vmon API 服务状态异常，这时优先排查这两个服务的日志，而不是盲目操作底层服务。

4. 按根因分类处理：哪些可以直接修，哪些必须慎重

定位到具体根因之后，修复手段就要分层。有些操作可以大胆做，有些操作有风险，动手前一定要权衡清楚。

4.1 磁盘写满时的清理与扩容流程

如果df -h看到某个分区使用率到了 95% 以上，优先处理磁盘问题。清理顺序建议先软后硬：

先清理日志和临时文件：

# 清理 systemd 日志，保留 500MB 以内 journalctl --vacuum-size=500M # 查看 /storage 下哪些目录占用大 du -h --max-depth=2 /storage 2>/dev/null | sort -hr | head -20

重点看两个目录：/storage/core 下可能堆着崩溃时的 core dump，这种文件往往几个 GB 一个，确认不影响取证后可以直接删掉；/storage/log 下的历史日志如果保留了太久，可以做归档压缩，或者把超过一定天数的旧日志清掉。

清理之后如果空间仍然紧张，就该考虑给 VCSA 扩容磁盘了。操作路径大致是：在 vSphere Client 里给 vCenter 虚拟机加虚拟磁盘容量，然后去 VAMI 5480 的“存储”页签看是否能直接扩展分区。如果 VAMI 不支持在线扩展，需要在 shell 里对 LVM 做 pvresize、lvextend、文件系统扩容。任何扩容动作执行前，都先确认这次故障已经通过清理方式缓解了，扩容只是为未来留空间，不要在服务还没稳定的时候折腾底层存储操作。

4.2 时间不同步引发 token 链失效的处理

如果你发现 VCSA 与 NTP 服务器时间偏移很大，或者timedatectl显示系统时间明显不对，先把时间校准。临时应急可以直接手动设置时间：

timedatectl set-ntp false date -s "2025-01-01 12:00:00" timedatectl set-ntp true

不过这只是应急，真正要做的是检查 NTP 配置是否正常，确保 vCenter 与 ESXi 主机、以及彼此之间的时间基准一致。VCSA 的网络时间同步来源可能是 NTP 服务器，也可能选择“与 ESXi 主机同步”，两种方式都行，关键是管理面要明确统一。

时间校准后，认证令牌链一般会自动恢复，但某些服务可能还需要重启才能重建会话，建议对涉及认证的这些服务执行重启：

service-control --restart vmware-vmafd service-control --restart vpxd service-control --restart vsphere-ui

这里强调一句：ESXi 主机的时间也要一起查。很多时候 vCenter 时间本身没问题，但底层主机时间偏了，导致虚拟机里能看到的心跳、任务时间戳全是乱的，而这种问题最容易在巡检中被忽略。

4.3 vmon 状态文件异常的处理与风险提示

如果日志确认了问题出在 vmon 自身状态库，也就是 /var/opt/vmware/vmon/ 下的文件损坏或缺失，那么处理思路是“清掉旧的错误状态，让 vmon 重新认识所有服务”。这个操作的完整流程如下：

# 1. 停掉所有 vCenter 服务 service-control --stop --all # 2. 确认没有残留进程 ps -ef | grep -E "vpxd|vmon|vpostgres" | grep -v grep # 3. 备份状态目录 tar -czf /tmp/vmon-backup.tar.gz /var/opt/vmware/vmon/ # 4. 清空状态目录（或者把里面所有文件挪到备份目录） cd /var/opt/vmware/vmon && find . -type f -delete # 5. 重启 vmonit 守护进程 systemctl restart vmonit # 6. 重新启动所有服务 service-control --start --all

这条路径对部分故障是有效的，但我要明确提示：它属于风险较高的修复手段。如果状态目录里其实是某个服务正常的注册信息，清空之后反而会让 vmon 失去对现有进程的认知，出现“不知道服务已经在跑”的问题。所以执行前务必确认备份完好，而且必须是在维护窗口内操作，不建议业务高峰期直接动这套流程。

另外提醒一下，service-control里有一个--reset参数，可以重置服务状态。这个参数不是万能的，某些版本上执行后反而会把服务的启动配置打回默认状态，原配置丢失后更难收拾。我的原则是能不动就不动，真到了那一步，优先考虑从备份恢复。

4.4 数据库、证书、快照回滚场景的兜底思路

vpostgres 数据库异常也很容易导致 vpxd 挂掉。查 pg.log 如果发现是因为磁盘没空间导致的临时文件写入失败，清理磁盘后单独拉起数据库即可：

service-control --start vpostgres service-control --start vpxd

如果日志显示数据库文件本身损坏，或者认证栈 vmafdd 起不来、VECS 证书存储读取异常，不要试图在生产环境里临场重签证书，那是一个非常深的坑。更稳妥的路径是：

• 如果故障前有近期有效的快照，先评估快照是否覆盖到故障发生前的状态；但要注意 vCenter 快照回滚存在数据库与文件不一致的风险，快照不能当作常规备份使用。
• 如果有 VAMI 的文件级备份（File-Based Backup），直接用它恢复整个 VCSA 往往比在坏掉的环境里修得快。

我之前还踩过一种情况：vCenter 虚拟机因为底层做了快照回滚，开机后整片服务 invalid。这种多半是数据库文件和配置状态不在同一时间点导致的，继续在原地修半天往往无解，尽快切换到备份恢复才是正确决策。这个经验值一次就够你记一辈子。

5. 这次踩坑之后，我把这些检查列进了日常巡检

处理完一次故障，如果不把防护措施建立起来，那只是把问题往后推迟了几个月。我自己在经历了几次“大清早 vCenter 打不开”的折腾后，把以下检查项固化成了每月例行巡检内容。

5.1 磁盘、时间、证书与备份的四项例行检查

日志轮转这块特别提一句。vCenter 的某些日志默认不会无限增长，但一旦出现异常，日志量会快速膨胀。我建议对 /storage/log 设置空间阈值监控，而不是只看系统盘根分区是否满，因为 VCSA 很容易出现根分区没事，但 /storage/log 悄悄满掉的情况。

5.2 变更与应急纪律：别让一次简单修复变成二次故障

vCenter 属于整个虚拟化环境的“控制面”，你对它做的任何变更都要以伺候核心系统的标准来对待。

升级或打补丁前，先做文件级备份，不要只依赖快照。快照在 vCenter 上的使用非常敏感，长时间保留快照会影响虚拟机性能，跨版本回滚还会带来数据库不一致风险，但实际运维中还是经常有人拿快照当“后悔药”用。

变更窗口内处理故障，也要遵守“先记录、再定位、后操作”的原则。我在第 3 节里说的那几步，看起来简单，但真到紧急时刻，人的第一反应往往是直接重启服务。我的经验是：如果判断不了一台 VCSA 上服务为什么 invalid，就先慢下来跑一轮排查命令，把日志留底，再决定是否动手。日志就是事故现场，破坏了现场，后面只能靠猜。

最后再分享一个操作细节：每次重启服务后，我都习惯在 shell 里执行一次service-control --status --all，确认所有服务都回到 running，再回到 VAMI 页面刷新看状态。CLI 和 UI 两组状态互相印证之后，才算真正把这次故障处理完。这套习惯帮我避过不少“以为好了、其实还坏着”的尴尬，也顺手验证了前端展示是否正常。