vCenter 7.0.3 突然打不开管理界面页面直接甩出no healthy upstream当时我整个人都是懵的。毕竟这套环境一直跑得挺稳但真实运维就是这样——你越以为没问题问题就越选在最不该来的时候来。这篇就完整记录我从发现报错到最终恢复的整个过程包括排查链路、日志定位、磁盘清理和验证步骤希望可以帮踩到同一坑的人少走点弯路。1. 故障现场管理界面打不开按F5也没用1.1 vCenter 管理地址直接变成Service Unavailable事情发生在一个普通的工作日业务那边打电话过来说虚拟机控制台打不开我一连 vCenter 的 Web 界面页面直接是 502仔细看反向代理提示的是no healthy upstream刷新了几次都一个样。然后我尝试访问 vCenter 的 VAMI 管理端口https://vCenter-IP:5480结果同样也是这个报错。其实no healthy upstream这个报错本身十足典型vCenter 的 Web 服务比如 nginx 反代和后端的 vsphere-ui之间的健康检查就过不了。反代发现后端服务没有响应就无法把流量转发过去。但是报错只是表象真正的病根可能有好几种。好在还能 SSH 到 vCenter这给了我排查的空间。如果 SSH 也进不去估计就只能去 ESXi 上的主机控制台操作那就更麻烦了。所以遇到这类问题先冷静判断能用 SSH 就从 SSH 入手别傻等着界面自动恢复。1.2 vCenter 7.0.3.01000 到底是个什么版本先交代下我的环境背景VMware VCSAvCenter Server Appliance版本是 7.0 Update 3具体 build 数字是 7.0.3.01000。很多群里朋友见到这个版本号都比较头疼因为它确实处在 7.0 中期的一些典型问题高发期比如证书过期、CLOUDVM 服务异常、磁盘分区告警、服务反复重启等。VCSA 本质上就是个精简的 Linux 虚拟机内部跑了不少容器和服务比如 vsphere-ui、vsphereclient、lookupsvc、sps、sts 等。最外层是 nginx 反向代理负责接收用户的 HTTPS 请求然后分流给对应后端服务。所谓 upstream就是 nginx 配置里定义的一组后端服务器而 no healthy upstream 表示这组后端服务器里没有任何一个通过健康检查于是 nginx 选择直接拒绝请求。所以我的思路就很明确了先确定是 nginx 层出了问题还是后端的 vsphere-ui 等服务挂了。再往下挖如果服务起不来多半是磁盘/证书/网络等底层因素。2. 第一轮排查从 VAMI 和 SSH 查服务状态2.1 尝试用 CLI 查看服务列表先看哪些服务状态异常SSH 到 vCenter 之后习惯性先跑了一下服务状态命令service-control --status --all这个命令会用比较友好的方式把所有 vCenter 服务的运行状态列出来。正常状态应该显示Running但如果显示Stopped或Degraded那基本就能锁定问题服务了。当时我重点看这几个关键服务vsphere-uivsphereclientvpxdpsche结果发现vsphere-ui处于Stopped状态vpxd倒是活着但 UI 没了访问页面当然就是一片红。这里有个小经验vCenter 7.x 里负责管理界面的服务是vsphere-ui它是个 Java 进程占用内存比较高。如果它的状态是Stopped你从 VAMI 里看有时也会是“服务已停止”或者干脆显示no healthy upstream因为 5480 端口的 VAMI 同样要经过反代。2.2 VAMI 获取不了数据日志里的 exception 暗示磁盘空间本来我想再用curl或直接看 VAMI 页面拿一些健康信息但 VAMI 同样不可用。这时候就只能去翻日志。vCenter 的日志路径挺多但我们需要的关键日志在/var/log/vmware/vsphere-ui/logs/*/var/log/vmware/vpxd/vpxd.log/var/log/nginx/error.log我先看了vsphere-ui的日志发现大量和磁盘空间有关的写入失败异常。日志里面频繁出现Out of disk space / No space left on device这就很明确了。vCenter 的 Java 服务需要读写临时目录和各类配置文件缓存一旦磁盘空间满了服务根本无法初始化或者运行中崩溃。所谓no healthy upstream很可能就是因为它后端的 vsphere-ui 一直启动失败于是 nginx 判定上游不健康。3. 日志中的真相根目录和 /storage/archive 分区都已经满了3.1df -h一看根分区 100%归档分区也是满的既然日志提示磁盘满我立刻执行df -h结果几个关键分区的状况相当惨挂载点容量已用使用率/50G50G100%/storage/archive800G800G100%/var/log20G12G60%/storage/dblog100G30G30%问题非常明显根分区和归档分区全部 100%这几乎就是 vCenter 的典型“绝症”之一。vSphere UI 在启动时需要写/storage/archive下的临时文件或者从归档读数据同时 Java 进程也会在根分区/tmp下写文件两个分区都满了服务自然起不来。一般 VCSA 7.0 默认安装时根分区只有 50GB而且里面还包含/usr/lib日志目录/var/log也可能挂载到根分区上。时间一长log 文件、软件更新包、临时归档文件都会把空间蚕食掉。3.2 为什么 nginx 健康检查会失败本质上是上游服务写不了数据这里稍微展开讲一下no healthy upstream的触发机制。nginx 配置里通常会对 vsphere-ui 的某个监控接口做健康检查比如healthz。当后端服务因为磁盘满导致的异常无法响应健康检查请求时nginx 会把对应 upstream 标记为unhealthy。在 nginx 的错误日志里你能看到类似这样的记录[error] ... no live upstreams while connecting to upstream意思是所有 upstream 后端都不存活。所以你想单单通过修改 nginx 配置来“屏蔽”这个报错是没有用的shutdown 的后端服务依然不会恢复。唯一的正确做法是让后端服务重新正常运行起来而为服务腾出可用的磁盘空间是最基础的一步。4. 修复实操清理归档、扩容分区、恢复系统空间4.1 清理 /storage/archive 中的旧日志和归档文件/storage/archive在 VCSA 里保存着不少全局对象、审计日志、备份临时文件不清理的话非常容易爆满。vCenter 自带了一个清理脚本/usr/lib/applmgmt/support/scripts/delete_diagnostics_partition.sh这个脚本可以清理诊断分区中的历史归档日志执行后可能会释放大量空间。不过要注意删除的是日期比较旧的历史数据不影响当前的操作。我跑这个脚本前又确认一下ps -ef | grep delete_diagnostics df -h /storage/archive跑的时候可以观察使用率慢慢降下去。如果你的环境里没有脚本或者脚本被误删了也可以手动找/storage/archive下的大文件比如audit、backup、vpostgres之类的目录把一些明显很老的日志移到其他盘或删除。但稳妥起见还是优先用官方脚本。清完之后/storage/archive从 100% 砍到 56%释放了大约 300 多 GB。但这个步骤只解决归档分区根分区还卡在 100%。4.2 清理根分区里的日志与临时文件根分区/满的话影响比归档分区更直接因为很多系统路径都在根分区下。常见的大户有/var/log下的日志文件/var/tmp/usr/lib/vmware-vpx/下的旧备份/etc/ssh之类的配置目录一般不大基本可以忽略我先看了根目录下最占空间的地方du -xh --max-depth1 / | sort -rh | head -20这条命令从根目录开始只统计本分区的文件不会误入其他挂载点方便找到根目录下的大目录。结果发现/var/log/vmware下积累了一大堆几十 GB 的旧日志。当时还发现/var/log/vmware/vpxd/里有个接近 6GB 的 vpxd 日志文件。处理办法是轮转日志而不是直接删掉正在使用的日志文件cat /var/log/vmware/vpxd/vpxd.log /dev/null或者先停掉相关服务再处理更安全。但当时我急着先恢复空间就先清理了一波旧的.gz文件。另一个占空间的大头是 VCSA 在升级或补丁安装时留下的残留文件一般在/storage/updatemgr或/root/download下更新包不会自动删除导致卷满了。如果确认更新已完成可以删掉这些更新包cd /storage/updatemgr/software ls -lh看到有几个 1GB~2GB 的补丁包直接删除后根分区释放出一部分空间。4.3 手动扩展根分区用 Local CLI 给 vCenter 虚拟机增加磁盘并扩容清理完日志后根分区使用率降到了 82%理论上服务应该能起来。不过既然搞了一次我希望直接给根分区留出足够余量避免才过一个月又满。所以决定给 VCSA 虚拟机加一块磁盘。操作流程是这样的在 ESXi 上找到 vCenter 的虚拟机关机如果还开着的话只能添加磁盘不能扩容系统盘。编辑虚拟机设置给 vCenter 增加一块新硬盘大小视业务需求而定我这边选了 100GB。开机后SSH 进入 vCenter使用vpxd服务识别磁盘再通过 LVM 扩展根分区所在的逻辑卷。注意 VCSA 7.0 的根分区是 LVM默认系统盘上有两个逻辑卷rootvg-root和rootvg-home等。新增加磁盘后需要把它加入卷组再扩展根逻辑卷和文件系统。简单操作路径pvcreate /dev/sdb vgextend rootvg /dev/sdb lvextend -L 50G /dev/rootvg/os xfs_growfs /因为根文件系统是 XFS扩展后直接xfs_growfs在线扩大即可不需要卸载文件系统。这里先解释下pvcreate把裸分区初始化为物理卷然后加入卷组rootvg逻辑卷空间变大后再用xfs_growfs把所有新增空间应用到文件系统上。我在实际扩展时没有直接给rootvg整块新增容量而是预留了一些空间以防别的逻辑卷也紧张比如/home和/var/log如果将来满了同样可以从卷组里分出空间。所以只给了 50GB 到根逻辑卷另外 50GB 留在卷组里做备用。扩容完成后再次df -h根分区使用率降到 30%看到这个数字心里就踏实了。4.4 证书问题也要做一个快速排查防止扩展空间后依然不能启动磁盘空间清理完成不代表服务一定会正常启动。如果 vCenter 证书过期或者生成的 STS 签名有问题也会出现 UI 服务异常。所以我又检查了证书过期时间使用命令/usr/lib/vmware-vmca/bin/certool --serverlocalhost --list以及查看/etc/vmware-vpx/ssl/vpxd.crt的到期时间。如果发现证书接近过期或已经过期就需要重新生成。我当时因为及时升级过版本证书还在有效期内这一步就略过。但如果你在解决no healthy upstream时排查完磁盘空间后发现服务依然起不来请务必查一下证书。5. 重启与验证服务恢复UI 正常放行5.1 正确的服务重启顺序别直接 reboot空间腾出来之后我开始尝试拉起服务。很多新手会直接rebootVCSA这当然能解决部分服务起不来的问题但有时经过一轮强制重启服务启动顺序不对反而可能出现更复杂的“假启动、真失败”状态。更好的做法是先单独启动 vsphere-ui 服务观察日志是否正常。service-control --start --service vsphere-ui如果服务成功启动日志中会出现监听端口和 ready 之类的信息。但要注意单独启动 vsphere-ui 不一定够因为多个服务之间存在依赖关系。安全起见我执行了service-control --all-services --start这个命令会把所有服务按依赖关系按顺序启动通常会花个好几分钟。执行完再用service-control --status --all查看大部分服务都显示 Running。如果出现个别服务启动失败可以再用service-control --start --service service-name单独拉一把配合日志观察。5.2 浏览器访问、API 和日志多方面验证服务正常启动后我先在 vCenter 命令行上验证一下本地的 UI 端口netstat -tlnp | grep 443确认 443 端口在监听。然后从浏览器访问https://vCenter-IP/ui页面能正常弹出登录框没有出现502。接着登录 vCenter检查了之前的健康检查页面以及主机和虚拟机列表都没有问题。我还顺手测试了一下vpxd服务service-control --status --service vpxd显示 Running。再查看 vSphere Client 显示的所有主机为“已连接”状态告警也都消失了。这里要特别提一个验证小细节登录 vCenter Web UI 后最好去“系统配置”里看一下“运行状况”确认告警为绿色。尤其是服务运行了十来分钟后再看一遍防止某些 Java 服务启动后因为内存不足又被 OOM Killer 杀掉。如果出现这种情况可能得考虑给 vCenter 虚拟机增加内存或者在服务配置里调整 Java 堆大小。6. 这个坑的根源与日常预防6.1 为什么 vCenter 7.0.3 特别容易出现 no healthy upstream我在几个群里讨论过发现很多朋友在 VCSA 7.0.3 上遇到同样的报错但为啥这个版本特别多原因是多方面的VCSA 7.0 整体日志体系比 6.x 更加庞大尤其是 vpostgres、vpxd、vsphere-ui 的日志增长得非常快但默认分区大小却依旧保守。/storage/archive分区虽然给得挺大但当数据归档目录里积压了大量历史备份和审计日志时也可能被消耗殆尽。7.0 Update 3 版本在服务健康检查机制上做了一些改动后端服务一旦异常nginx 快速标记 unhealthy 并返回no healthy upstream而不是像旧版那样挂在那里超时。所以故障更容易浮出水面。另外有部分环境从 vCenter 6.7 升级到 7.0.3过程中可能保留了旧的数据和日志导致分区直接被历史数据塞满。所以说白了no healthy upstream是一个“结果”它把问题摆到你面前具体是什么原因还得靠日志和资源状态去定位。磁盘满是最常见的原因但我也遇到过由于 DNS 抖动导致某个服务无法注册最后 UI 挂了的情况。因此在排查时一定要打开/var/log/nginx/error.log看错误提示里到底写了什么后端请求失败。6.2 日常监控和配置建议这次恢复之后我给这套环境加了几条防护措施在这里一并分享给 VCSA 配置磁盘空间监控尤其是根分区、/storage/archive和/storage/dblog使用率超过 80% 就要告警。在 vCenter 虚拟机里配置日志轮转策略可以设置/etc/logrotate.d/vmware-vpx里的保留份数和压缩方式避免日志单文件无限增肥。长期保留的备份任务不要都丢在默认归档目录下可以单独分配存储避免本地磁盘被备份拖垮。有条件的话直接把 VCSA 根分区初始扩容到 100GB 以上。早期部署时就多给点空间比以后在线扩容更省事。另外再用一句话提醒各位no healthy upstream这个报错不等于 vCenter 一定挂了先尽力恢复服务再考虑要不要重新部署 VCSA。不到万不得已不要因为一个报错就放弃原环境。很多时候清理磁盘、重启服务就能解决不必走上重装这条大动干戈的路。最后再分享一个排查时的小技巧。如果 SSH 登录 VCSA 有延迟甚至不响应但能 ping 通可以先看是不是 CPU 和内存跑满不要直接判断系统无响应。使用top快速看一眼进程如果有 Java 进程占用 100% CPU 或内存几乎耗尽可以systemctl restart对应服务或通过service-control --stop/--start重启它往往能让系统缓过来。而如果你连 SSH 都登录不了那就只能在 ESXi 上强制重启 VCSA 虚拟机但这也是最后的手段重启完还是需要重新检查分区空间和服务状态。我的整个排查思路就是从“页面报错”逆向追到“服务不可用”再追到“磁盘满”最后通过清理归档和扩展根分区彻底解决。从发现故障到恢复正常总共花了一个多小时其中一半时间都用在定位分区占用上。所以建议你现在就登录 VCSA 看一眼df -h确认没有隐藏的磁盘隐患别等下一次no healthy upstream找上你。