企业官网建设流程全解析

1. 为什么要从 vCenter 6.7 升级到 7.0

1.1 升级这件事，拖得越久越被动

vCenter 6.7 这个版本，很多团队从 2018 年前后上线一直用到现在，稳定是真稳定，但问题也很明显：主流支持周期已经走到尾声，补丁更新频率肉眼可见地下降，新采购的硬件和存储阵列在兼容性列表里越来越难找到 6.7 的身影。我见过不少环境，vCenter 还跑在 6.7 上，结果新买的 ESXi 主机是 7.0 甚至 8.0 出厂镜像，加进集群时各种告警，最后不得不临时降级固件，折腾一圈。

升级到 7.0 不是赶时髦，而是解决几个很现实的问题。第一，7.0 对生命周期管理的支持更完整，vLCM 镜像化集群管理在 7.0 上才真正好用，补丁和驱动可以按镜像基线统一推送，不用再一台台主机手动打补丁。第二，7.0 的 vCenter 在性能上有明显提升，尤其是大规模集群下，6.7 的 vpxd 进程内存泄漏和任务队列堆积是老毛病，7.0 做了不少优化。第三，安全合规层面，6.7 的 TLS 版本和加密套件已经跟不上内部审计要求，7.0 默认启用更严格的加密策略。

适合看这篇内容的人，是手里管着几台到几十台 ESXi 主机、vCenter 还停留在 6.7、正在犹豫要不要升、或者已经决定升但不知道从哪下手的运维人员。我会把整个升级路径拆开讲，包括前期检查、备份策略、升级顺序、常见报错和回退方案，尽量让每一步都能直接照着做。

1.2 升级不是点一下按钮，核心风险在哪

很多人以为 vCenter 升级就是挂个 ISO 跑安装程序，其实真正的风险点集中在三个地方：数据库、证书和插件兼容性。

数据库方面，6.7 的 vCenter 可能用的是内置 PostgreSQL，也可能是外接的 PostgreSQL 或 Oracle。7.0 对数据库版本有硬性要求，内置库会随升级自动迁移，但外接库如果版本太老，升级程序会直接拒绝继续。我遇到过外接 PostgreSQL 9.6 的环境，7.0 要求至少 10.x，结果只能先把数据库升上去再动 vCenter。

证书方面，6.7 时代很多环境用的是 VMCA 默认证书，也有不少手动替换过第三方 CA 签发的证书。7.0 对证书链的校验更严格，如果 6.7 上存在证书过期、SAN 字段缺失或者中间证书不完整的情况，升级过程中 STS 证书签发会失败，导致升级卡在 80% 左右。这个坑非常常见，后面我会专门讲怎么提前排查。

插件兼容性是最容易被忽略的。vCenter 上挂了一堆插件，比如备份软件、监控工具、存储插件、网络插件，这些插件在 7.0 上不一定有对应版本。升级前必须逐个确认，否则升级完 vCenter 是起来了，但备份任务全挂，那才是真麻烦。

2. 升级前的环境摸底与兼容性检查

2.1 先搞清楚当前 vCenter 的部署形态

动手之前，第一件事是确认你的 vCenter 是哪种部署方式。6.7 时代主要有两种：Windows 版 vCenter和VCSA（vCenter Server Appliance）。Windows 版在 7.0 已经彻底取消，所以如果你还在用 Windows 版 vCenter，升级路径不是直接升 7.0，而是先迁移到 6.7 的 VCSA，再从 VCSA 升到 7.0。这个迁移本身就是一个大工程，建议单独规划窗口。

如果是 VCSA，还要确认是嵌入式 PSC还是外部 PSC。6.7 支持外部 PSC 部署，但 7.0 已经不再支持外部 PSC 架构，升级前必须先把外部 PSC 收敛到嵌入式。收敛操作在 6.7 的 VAMI 界面里可以做，但过程不可逆，务必先做快照和备份。

确认部署形态的方法很简单，登录 vCenter 的 VAMI 界面（https://vcenter-ip:5480），在“摘要”里能看到版本和部署类型。或者用 SSH 登录 VCSA，执行：

vpxd -v

这个命令会输出 vCenter 的详细版本号。另外，在 vSphere Client 里，进入“系统管理”->“节点”，可以看到 PSC 的状态。

2.2 兼容性矩阵必须逐项核对

升级前一定要去查兼容性矩阵，这不是可选项，是必选项。重点核对以下几项：

DNS 这一项特别容易被忽略。我见过一个环境，vCenter 的 FQDN 正向解析没问题，但反向解析指向了一个旧 IP，升级后 vpxd 启动时一直报证书不匹配，查了半天才发现是 PTR 记录没更新。所以升级前务必用nslookup或dig双向验证。

2.3 备份策略：快照不是备份

这是我最想强调的一点：快照不是备份。很多人升级前给 vCenter 虚拟机打个快照就完事了，结果升级失败后回滚快照，发现数据库已经部分迁移，回滚后 vCenter 直接起不来。正确的做法是三层备份：

第一层，文件级备份。用 VAMI 界面里的“备份”功能，把 vCenter 的配置和数据库备份到外部存储。这个备份是 7.0 升级程序唯一认可的恢复源，如果升级失败，可以用这个备份重新部署一个 6.7 然后恢复。

第二层，虚拟机快照。在文件级备份完成后，再打一个快照，作为快速回退手段。但要注意，快照只能在升级前打，升级过程中如果失败，先尝试用文件级备份恢复，快照作为最后手段。

第三层，数据库单独备份。如果用的是外接数据库，让 DBA 单独做一次全量备份，并确认备份可恢复。内置数据库的话，VAMI 备份里已经包含了。

注意：VAMI 备份的文件要下载到本地或者外部存储，不要留在 vCenter 所在的存储上。我遇到过存储故障导致备份和 vCenter 一起丢的情况，那就真的没救了。

3. 升级实操全流程拆解

3.1 第一阶段：挂载 ISO 与预检查

7.0 的升级 ISO 可以从官方渠道获取，挂载到一台能访问 vCenter 的 Windows 或 Linux 跳板机上。ISO 里有两个安装程序：vcsa-ui-installer是图形界面，vcsa-cli-installer是命令行。生产环境我建议用命令行，因为可以写脚本、可以重复执行、出错时日志更清晰。

图形界面的入口在vcsa-ui-installer/win32/installer.exe，双击后选择“升级”选项。升级程序会分两个阶段：第一阶段是部署新的 7.0 设备，第二阶段是迁移数据和配置。

预检查阶段，安装程序会要求输入源 vCenter 的 IP 和凭据，然后自动跑一遍兼容性检查。这一步会检查前面提到的数据库、证书、DNS 等。如果检查不通过，会给出具体原因，按提示修复后重新跑。

我建议在正式升级前，先用命令行工具跑一次预检查：

vcsa-cli-installer/lin64/upgrade-run.sh \ --source.vc-ip=192.168.1.100 \ --source.vc-user=administrator@vsphere.local \ --source.vc-password='YourPassword' \ --target.temp-ip=192.168.1.101 \ --target.temp-netmask=255.255.255.0 \ --target.temp-gateway=192.168.1.1 \ --target.temp-dns=192.168.1.10 \ --target.temp-hostname=vcenter70-temp.example.com \ --target.deployment-size=small \ --target.storage-size=default \ --target.disk-mode=thin \ --target.enable-ssh=true \ --precheck-only

这个命令只跑预检查，不实际部署。预检查通过后，去掉--precheck-only再跑一次就是正式升级。

3.2 第二阶段：部署临时设备与数据迁移

正式升级开始后，安装程序会先在目标 ESXi 主机上部署一个临时的 7.0 设备。这个临时设备需要独立的 IP、主机名和存储位置。部署完成后，它会从源 6.7 设备拉取数据，包括数据库、证书、配置文件等。

这个阶段有几个关键点：

临时设备的 IP 不能和源 vCenter 冲突，但必须在同一网段，因为迁移过程中两个设备要直接通信。临时设备的主机名也要提前在 DNS 里注册好正反向记录，否则迁移会失败。

存储位置要选对。临时设备的数据盘建议放在性能较好的存储上，因为迁移过程中会有大量随机读写。如果放在慢速存储上，迁移时间会成倍增加。我实测过一个环境，源 vCenter 数据库 50GB，放在全闪存上迁移用了 40 分钟，放在 7.2K 机械盘上用了 3 个多小时。

迁移过程中不要操作源 vCenter。迁移开始后，源 vCenter 会进入只读模式，所有写操作都会被阻塞。这时候如果强行登录去改配置，可能导致数据不一致。正确的做法是提前通知所有用户，迁移窗口内不要动 vCenter。

迁移进度可以在安装程序界面看到，也可以登录临时设备的 VAMI 界面查看。如果卡在某个百分比超过 30 分钟不动，大概率是证书或者数据库的问题，需要看日志排查。

3.3 第三阶段：切换与验证

数据迁移完成后，安装程序会提示关闭源 6.7 设备，然后把临时设备的 IP 和主机名改成源 vCenter 的。这一步是自动的，但需要确认源设备已经关机，否则 IP 冲突会导致切换失败。

切换完成后，用原来的 vCenter FQDN 登录，应该能看到 7.0 的界面。这时候要做几件事验证：

第一，检查所有 ESXi 主机是否正常连接。在“主机和集群”视图里，确认每台主机的状态是“已连接”，没有告警。

第二，检查所有虚拟机的状态。确认没有虚拟机变成“孤立”或“无效”状态。如果有，右键选择“重新注册”即可。

第三，检查插件和扩展。进入“系统管理”->“扩展”，确认所有插件都正常加载。如果有插件显示不兼容，联系厂商获取 7.0 版本。

第四，检查权限和角色。7.0 的权限模型和 6.7 基本一致，但有些自定义角色可能需要微调。用管理员账号登录，逐个检查关键用户的权限。

第五，检查备份任务。如果有第三方备份软件，手动触发一次备份任务，确认能正常完成。

4. 常见报错与排查技巧实录

4.1 升级卡在 80%：STS 证书签发失败

这是最常见的报错，没有之一。现象是升级进度条走到 80% 左右停住，日志里出现Failed to issue STS certificate或者STS certificate chain validation failed。

根本原因是源 6.7 的证书链有问题。7.0 在升级时会重新签发 STS 证书，签发过程中会校验现有证书链的完整性。如果 6.7 上存在以下情况，就会失败：

• 证书已过期或即将过期（剩余有效期少于 30 天）
• 证书的 SAN 字段缺少 vCenter 的 FQDN 或 IP
• 中间证书缺失，信任链不完整
• 证书被手动替换过，但替换时没有包含完整的证书链

排查方法：用 SSH 登录源 6.7 VCSA，执行以下命令检查证书状态：

/usr/lib/vmware-vmafd/bin/dir-cli trustedcert list

这个命令会列出所有受信任的证书。检查每张证书的有效期和 SAN 字段。另外，用浏览器访问 vCenter 的 443 端口，查看证书详情，确认证书链是否完整。

修复方法：如果证书过期或 SAN 缺失，需要先替换证书。6.7 的证书替换可以用 VAMI 界面或者certool命令行。替换完成后，重新跑升级预检查，通过后再升级。

实操心得：如果证书问题一时半会儿修不好，可以先临时延长证书有效期。用certool命令可以重新签发一张有效期更长的证书，但这不是长久之计，升级完成后还是要换成正规证书。

4.2 数据库迁移失败：版本不兼容或空间不足

外接数据库的环境，升级时经常遇到数据库版本不兼容。7.0 要求 PostgreSQL 最低 10.x，Oracle 最低 12c。如果源库版本低于这个要求，升级程序会在预检查阶段就报错。

另一种情况是数据库空间不足。迁移过程中，临时设备需要从源库拉取全量数据，如果源库所在存储空间不够，迁移会中断。我建议源库所在存储至少保留 50% 的可用空间。

排查方法：登录源数据库，执行版本查询命令。PostgreSQL 用SELECT version();，Oracle 用SELECT * FROM v$version;。同时检查数据库大小和存储可用空间。

修复方法：如果版本太低，先升级数据库。PostgreSQL 的升级可以用pg_upgrade工具，Oracle 的升级更复杂，建议让 DBA 操作。升级完数据库后，重新跑预检查。

4.3 升级后 ESXi 主机断开连接

升级完成后，有时候会发现部分 ESXi 主机显示“断开连接”或“无响应”。这通常是因为 7.0 vCenter 的证书和主机上的证书不匹配。

6.7 时代，vCenter 和 ESXi 之间的通信证书是自动管理的。升级到 7.0 后，vCenter 会重新签发证书，但 ESXi 主机上可能还保留着旧的证书指纹。解决方法是在 vCenter 里右键主机，选择“连接”->“重新连接”，然后输入主机的 root 凭据，让 vCenter 重新推送证书。

如果重新连接失败，可以 SSH 登录 ESXi 主机，执行以下命令手动刷新证书：

/etc/init.d/hostd restart /etc/init.d/vpxa restart

然后回到 vCenter 重新连接。如果还是不行，可能需要把主机从集群里移除，再重新添加。移除前确保主机上的虚拟机已经迁移到其他主机，或者确认主机上没有运行虚拟机。

4.4 常见问题速查表

5. 升级后的收尾与优化建议

5.1 清理旧设备与释放资源

升级完成后，源 6.7 设备会被关机，但不会自动删除。建议保留一到两周，确认 7.0 运行稳定后再删除。删除前，把源设备的虚拟机文件从存储上移除，释放空间。

如果升级过程中用了临时设备，临时设备在切换完成后会被自动删除，但有时候会残留一些文件。登录目标 ESXi 主机，检查是否有名为vcenter70-temp的虚拟机残留，有的话手动删除。

另外，检查 vCenter 的数据库大小。7.0 的数据库结构有变化，升级后可能会比 6.7 大一些。如果数据库增长过快，可以调整数据保留策略，清理历史任务和事件。

5.2 启用 7.0 的新特性

7.0 有几个值得关注的新特性，升级后可以逐步启用：

vLCM 镜像化集群管理。这是 7.0 最大的亮点，可以把 ESXi 主机的固件、驱动、补丁打包成镜像，统一推送。启用方法是在集群上右键，选择“映像”，然后创建基线。不过要注意，vLCM 需要主机版本在 7.0 以上，如果集群里还有 6.7 主机，需要先全部升级。

vCenter 文件级备份增强。7.0 的 VAMI 备份支持更细粒度的配置，可以只备份配置不备份数据，也可以备份到 S3 兼容存储。建议配置定期自动备份，备份文件保留至少 7 天。

增强的权限管理。7.0 支持更细粒度的 RBAC，可以按标签、按资源池分配权限。如果之前用 6.7 的权限模型觉得不够灵活，可以在 7.0 上重新设计。

5.3 性能调优与监控

升级后建议观察一周的性能数据，重点关注 vpxd 进程的内存占用、数据库的响应时间、以及 vCenter 的 CPU 使用率。7.0 在性能上有优化，但如果环境规模大，还是需要调优。

vpxd 的内存可以在 VAMI 界面调整，默认是 small 配置，适合 10 台主机以下的环境。如果主机数量超过 20 台，建议调到 medium 或 large。调整后需要重启 vpxd 服务。

数据库方面，7.0 的内置 PostgreSQL 默认配置适合中小规模环境。如果 vCenter 管理的主机超过 50 台，建议调整 PostgreSQL 的shared_buffers和work_mem参数。具体数值可以参考官方文档的性能调优指南。

监控方面，7.0 的 vCenter 自带健康检查功能，在“系统管理”->“健康”里可以看到各个组件的状态。建议配置告警，当数据库空间不足或证书即将过期时自动通知。

6. 我个人在实际操作中的几点体会

升级 vCenter 这件事，技术难度其实不算特别高，但细节特别多，任何一个细节没注意到都可能卡住。我前后做过十几次 6.7 到 7.0 的升级，踩过的坑基本都写在上面了。

最大的体会是：预检查一定要跑，而且要多跑几次。有些问题不是一次预检查就能发现的，比如证书有效期，可能第一次检查时还有 40 天，你觉得没问题，结果升级窗口排到 35 天后，证书只剩 5 天，升级时就报错了。所以预检查最好在升级前一周和升级前一天各跑一次。

另一个体会是：备份一定要验证可恢复。我见过太多人备份做了，但从来没验证过恢复，结果真出问题时发现备份文件损坏或者恢复流程走不通。VAMI 备份恢复的流程建议在测试环境先走一遍，确认没问题再上生产。

最后分享一个小技巧：如果升级窗口时间紧张，可以先把 vCenter 升级，ESXi 主机保持 6.7 不动。7.0 的 vCenter 可以管理 6.7 的 ESXi 主机，这样升级风险更可控。等 vCenter 稳定运行一段时间后，再逐台升级 ESXi 主机。这种分阶段升级的方式，比一次性全升要稳妥得多。