从运维失误到数据重生：一次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-id3.2 第二阶段存储组件深度检测使用RVC工具全面诊断vSAN状态vsan.disks_stats # 查看磁盘健康状态 vsan.object_info object-uuid # 检查对象元数据发现关键问题多个组件的CSN版本号不一致导致系统无法自动修复。比如某个RAID1对象的三个副本Component1: CSN888 (STALE) Component2: CSN891 (STALE) Witness: CSN897 当前对象CSN8983.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次但失败一次就结束了。