从一次机房搬迁说起：老司机复盘VSAN 6.5集群关机重启的那些‘坑’与最佳实践
从机房搬迁实战复盘：VSAN 6.5集群安全关机的九道防火墙
去年冬天参与某金融机构数据中心迁移项目时，面对由vCenter 7.0管理的四台ESXi 6.5主机组成的VSAN集群，我们团队在关机流程上踩过的坑比预想中多得多。当第一台主机进入维护模式后突然出现的虚拟机乱码，至今想起仍让人脊背发凉——这促使我系统梳理出这份混合版本环境下的VSAN集群操作手册，其中包含多个官方文档未明确标注的版本兼容性细节。
1. 版本差异：被忽视的隐形陷阱
混合版本环境如同行走在薄冰上。vCenter 7.0管理ESXi 6.5主机时，界面显示的"关闭集群"功能实际上需要VSAN 7.0组件支持。我们通过对比实验发现：
| 功能可用性 | vCenter 7.0 + ESXi 6.5 | vCenter 7.0 + ESXi 7.0 |
|---|---|---|
| 集群关机向导 | ❌ 不可用 | ✅ 可用 |
| 维护模式数据迁移 | ❌ 仅有无操作选项 | ✅ 完整选项 |
| vCLS撤回支持 | ❌ 无相关配置项 | ✅ 完整支持 |
关键发现：当vCenter版本高于ESXi主机时，UI显示的功能可能因底层组件缺失而无法正常工作，这种情况在VSAN 6.5/6.7时代尤为常见。
2. 数据安全三重防护机制
单副本虚拟机在集群重启时风险最高，我们开发了一套预防性检查流程：
副本验证阶段
# 检查虚拟机存储策略合规性 esxcli vsan storage list | grep -A5 "Policy Compliance"- 标记所有不符合存储策略的虚拟机
- 优先处理系统关键服务虚拟机
临时策略调整
- 将单副本虚拟机临时改为双副本
- 预留至少30%的存储空间用于数据同步
预关机检查清单
- 确认无后台快照任务运行
- 检查vSAN健康状态（通过Skyline Health）
- 验证网络心跳检测正常
3. 维护模式的致命选择
ESXi 6.5的维护模式存在两个隐蔽陷阱：
操作对比实验数据：
| 操作方式 | 成功恢复率 | 平均耗时 | 主要风险 |
|---|---|---|---|
| 无操作模式 | 72% | 4.2小时 | 数据不一致 |
| 完整数据迁移 | 98% | 6.8小时 | 存储空间不足导致中断 |
| 滚动重启方案 | 100% | 8.5小时 | 操作复杂度高 |
我们在实际迁移中采用的折中方案：
# 分批次进入维护模式（每次1台主机） for host in $(esxcli network ip connection list | grep ESTABLISHED | awk '{print $6}'); do esxcli system maintenanceMode set -e true -m noAction sleep 300 done4. vCenter托管位置的连锁反应
当vCenter运行在待关闭的VSAN集群上时，必须严格遵循以下顺序：
关机序列
- 先关闭所有非vCenter虚拟机
- 禁用HA和DRS服务
- 记录vCenter虚拟机所在主机位置
- 最后关闭vCenter
开机黄金30分钟
# 主机启动后立即检查服务状态 tail -f /var/log/vsan-health.log | grep "component state"- 等待所有主机退出维护模式
- 优先启动vCenter虚拟机
- 间隔15分钟再启动其他关键业务VM
那次导致虚拟机乱码的事故，根源就在于第三台主机进入维护模式时，vCenter仍在运行并错误记录了虚拟机状态。后来我们开发了基于SSH的离线状态记录脚本，在完全脱离vCenter的情况下仍能追踪虚拟机分布。
5. 灾备方案：当最坏情况发生时
准备以下应急工具包：
- 最新版本的VMware-VMvisor-Installer-6.5.0.iso
- VSAN 6.5专用诊断工具集
- 预先测试过的数据恢复流程：
- 单主机恢复模式
# 强制加载VSAN数据存储 esxcli vsan storage mount -u <VSAN_UUID> - 对象修复命令
# 重建丢失的存储对象 python /usr/lib/vmware/vsan/bin/objtool.py recreate -u <object_UUID>
6. 实战优化后的关机检查表
基于三次成功迁移经验总结的九步法：
- [ ] 确认无后台任务运行（备份/复制/快照）
- [ ] 检查存储策略合规率100%
- [ ] 临时调整单副本VM为双副本
- [ ] 禁用HA/DRS集群服务
- [ ] 记录vCenter及关键VM位置
- [ ] 逐台进入无操作维护模式
- [ ] 物理关机前确认LED状态
- [ ] 开机后等待完整服务初始化
- [ ] 分批次启动业务虚拟机
7. 性能监控关键指标
在关机前24小时应持续监控：
| 指标 | 安全阈值 | 检测命令 |
|---|---|---|
| 重新同步组件 | <5 | esxcli vsan debug resync list |
| 内存缓存使用率 | <70% | esxcli vsan perfcache stats get |
| 网络延迟 | <2ms | ping -c 10 <其他主机IP> |
8. 混合环境特殊处理技巧
针对vCenter 7.0管理ESXi 6.5的特殊场景：
- 使用PowerCLI替代部分Web UI功能：
# 获取VSAN集群状态 Get-VsanClusterConfiguration -Cluster "ClusterName" | Select-Object -Property * - 手动触发组件健康检查：
# 强制刷新健康状态 python /usr/lib/vmware/vsan/bin/health.py --refresh
9. 从血泪教训中总结的三大铁律
版本确认要双重：不仅检查vCenter版本，更要确认VSAN on-disk格式版本
# 查看VSAN数据存储版本 esxcli vsan debug cluster get | grep "on-disk version"关机如拆弹：每个操作步骤之间至少间隔5分钟观察期
日志即生命线：在开始前确保所有主机的日志级别调整为verbose
# 调整VSAN日志级别 esxcli system syslog config set --loghost=<syslog_server> --v