从运维失误到数据重生：一次vSAN集群故障的完整救援实录
1. 灾难降临：30TB业务数据突然"消失"
那天早上接到报警电话时，我的手都在发抖。客户那边三台服务器组成的vSAN集群突然集体罢工，26个虚拟机对象显示"不可访问"，其中包括客户最核心的SVN代码仓库和30TB容量的Edisk文件服务器。更可怕的是，这个刚上线一年的系统还没有配置任何备份方案。
事情的起因简直像教科书级的运维事故：同事想修改vCenter的主机名配置，操作失败后直接在主机上部署新vCenter。要命的是在将主机加入新vCenter时，他通过主机本地界面进入维护模式，而这里默认勾选的是"无数据迁移"选项（正常通过vCenter操作默认是"确保数据迁移安全"）。三台主机反复进出维护模式的操作，直接导致vSAN存储组件进入脑裂状态。
我当时用RVC命令行工具检查集群状态时，终端不断刷新的红色警告至今难忘：
vsan.check_state ~/computers/VSAN集群 2023-08-27 13:45:04 +0000: Step 1: Check for inaccessible vSAN objects Detected 26 objects to be inaccessible Detected d2928164-b62c-650b-0cbc-5853c0642b44...2. 绝地求生：四阶段救援方案
2.1 紧急组建作战室
我们立即成立应急小组，制定分阶段救援计划：
- 首要目标：48小时内恢复关键业务系统
- 次要目标：完整修复所有不可访问对象
- 应急方案：同时准备重建环境，从外部系统手动恢复数据
时间线规划如下：
Day1白天：尝试恢复vCenter服务 Day1晚上：评估数据损坏程度 Day2全天：集中修复存储对象 Day3凌晨：最终验证和系统加固2.2 技术手段组合拳
我们准备了多套技术方案备选：
- 官方方案：通过VMware支持获取专业救援
- 社区智慧：在技术论坛寻求实战经验
- 自主开发：基于RVC工具编写修复脚本
- 物理提取：万不得已时直接读取磁盘数据
3. 实战救援全记录
3.1 第一阶段：vCenter服务恢复
原vCenter由于主机名修改导致服务无法启动。我们尝试了：
- 回退主机名配置（失败）
- 重置SSL证书（部分成功）
- 最终采用备用方案：激活2号节点上的vCenter备份实例
关键操作步骤：
# 在ESXi主机上查找备用vCenter vim-cmd vmsvc/getallvms | grep vCenter # 启动备用实例 vim-cmd vmsvc/power.on <vm-id>3.2 第二阶段：存储组件深度检测
使用RVC工具全面诊断vSAN状态：
vsan.disks_stats # 查看磁盘健康状态 vsan.object_info <object-uuid> # 检查对象元数据发现关键问题：多个组件的CSN（版本号）不一致，导致系统无法自动修复。比如某个RAID1对象的三个副本：
Component1: CSN=888 (STALE) Component2: CSN=891 (STALE) Witness: CSN=897 当前对象CSN=8983.3 第三阶段：多方求援
官方支持：VMware工程师远程分析两天后，给出的结论是"数据无法恢复"。他们主要做了：
- 收集vm-support日志包
- 检查vSAN集群配置文件
- 分析操作历史记录
社区高手：一位论坛网友提供了关键命令：
vsish -e set /vmkModule/vsan/dom/ownerAbdicate <uuid>这个命令强制重新选举对象所有者，成功恢复了25个不可访问对象。
3.4 第四阶段：自主修复突破
最后的30TB大文件始终无法同步。我们尝试了"场景重现法"：
- 按照原始故障发生时主机的操作顺序
- 反向执行正确的维护模式流程：
# 按特定顺序进入维护模式 esxcli system maintenanceMode set -e true -m vsan # 等待5分钟后退出 esxcli system maintenanceMode set -e false - 观察同步进度：
watch -n 10 "vsan.check_state -r 1"
经过三次循环操作，控制台突然开始刷出同步进度条，30TB数据开始逐步恢复。
4. 血泪换来的经验
4.1 必须建立的防护措施
这次事故后，我们立即实施了以下改进：
- 备份方案：
- 部署Veeam定时备份关键VM
- 设置vSAN原生快照策略
- 操作规范：
- 禁止直接登录主机操作
- 维护模式操作需双人确认
- 监控预警：
- 配置vSAN健康状态告警
- 关键操作前自动创建快照
4.2 救命的知识点
每个vSAN管理员都应该掌握这些救命命令：
# 紧急检查 vsan.health_check vsan.check_state -r 1 # 对象修复 vsan.cmd repair_object <uuid> vsan.obj_status_report <uuid> # 组件管理 vsan.resync_dashboard # 查看同步进度 vsan.clear_inaccessible <uuid> # 强制清除5. 写给同行的建议
这次救援让我深刻体会到：vSAN就像精密的瑞士手表，普通用户看到的是优雅的界面，但真正出问题时，你必须理解内部数百个齿轮如何咬合。有些经验值得分享：
- 维护模式是双刃剑：主机本地操作会绕过vCenter的安全检查，就像用root权限执行rm -rf
- 版本号是关键：vSAN的CSN机制类似Git的commit hash，脑裂时需要有策略地选择保留哪个版本
- 社区力量不可忽视：官方支持有时过于流程化，而实战高手往往藏在论坛里
最让我后怕的是，30TB数据能恢复纯属侥幸。现在我的手机里永远存着vSAN应急手册，就像医生随身带着急救包。记住：没有备份的存储，就像没有降落伞的跳伞，你可能成功99次，但失败一次就结束了。