9台虚拟机集体“罢工”：虚拟化环境故障排查与应急复盘

9台服务器集体“罢工”监控大屏上一片红色业务群的消息一分钟弹几十条领导站在工位旁边追问“到底什么情况”——我经历的这场事故已经过去快半年但当时那几分钟的窒息感到现在还记得很清楚。这里说的9台服务器全部是虚拟服务器也就是跑在同一套虚拟化平台上的虚拟机。它们没有自己的物理键盘、显示器和网卡看似只是软件定义出来的“假机器”。可当它们同时失联的那一刻我才真正明白服务器是虚拟的惊魂却是实实在在的。订单系统、客服工单、对账任务、内部OA……这9台虚拟机上承载的东西撑起了公司大半的日常运转。这种“集体罢工”和我以前处理过的单台虚拟机卡死完全不是一个量级。接下来我把这次故障从发现、应急、定位到恢复的全过程拆开来讲也会顺手把虚拟化环境里最容易导致“集体宕机”的几个根因、排查时要避的坑以及监控和备份该补的课一并整理出来。如果你是刚接触虚拟化的运维新人这篇可以当案例读如果是带团队的老手建议重点看第4和第5部分——很多教训都是我用一上午的头发换来的。1. 故障概况与应急处置1.1 故障初现从零星告警到大面积瘫痪那天上午大概9点出头我还在看前一天的巡检报表监控平台突然弹出一条虚拟机无心跳告警。我下意识以为是某台测试机又被人玩坏了点开一看紧接着第二条、第三条告警开始往外冒短短几分钟内9台虚拟机几乎同时从“健康”变成“未知”或“无响应”状态。一开始我还想着逐个远程登录看看结果发现所有虚拟机都连不上了。管理控制台里它们的列表还在但打开VNC视图有的黑屏有的画面完全冻结连时钟都不走。更要命的是业务群里已经开始有人反馈“系统登不上去了”“订单页面打不开”。那时候我才意识到这次不是单台虚拟机出问题是整片虚拟化环境出问题了。我赶紧把团队里另外两个人叫过来一个人继续盯平台状态一个人开始物理链路排查我在群里统一对外同步信息。事后复盘这个分工救了我们一命——如果没有第一时间明确谁干什么光靠一个人在群里回消息、看平台、查日志根本忙不过来而且越急越乱。1.2 先止损当机立断的应急三步面对这种大面积故障最容易犯的错误就是一通乱点。有人会立刻去“强制重启”虚拟机有人会急着去恢复快照还有人会连续刷新管理页面。我当时在群里发了一条置顶消息给团队立了三条规矩。第一先发故障公告同步影响范围让业务部门停止重试操作。这个很重要因为业务人员不知道系统是暂时卡顿还是彻底挂了他们会反复刷新页面、反复提交订单造成数据重复或锁表等系统恢复后反而更麻烦。第二禁止任何人直接点“强制重启”“强制关机”“删除故障虚拟机”之类的按钮。原因很简单我们还不清楚底层是什么情况如果虚拟机正处于IO等待状态强制操作会叠加异常断电的后果轻则文件系统损坏重则整块虚拟磁盘出现不可逆问题。第三分头确认“物理层”是否还活着宿主机能不能ping通存储设备的管理地址能不能访问物理交换机端口有没有异常。这一步是为了判断故障到底出在哪一层——是宿主机挂了是存储掉了还是网络断了。这三步做完我们基本可以确定宿主机和物理网络是通的但虚拟机层面完全没法交互。线索开始指向一个更底层的环节。1.3 快速评估影响面哪些业务在“裸奔”在应急的同时我让同事拉了一张表把9台虚拟机对应的业务功能、重要程度、对外影响全部列出来。这看起来是行政活儿但在真正恢复的时候它就是优先级列表。表格列出来之后我们才发现这9台机器的重要性远比想象中高。订单系统两条链路其中一条主链路就在这批虚拟机上客服工单在跑对账任务当天凌晨刚跑了一半还有内部OA和财务审批虽然不面向客户但内部所有部门都在靠它走流程。开发测试环境里也有几台虽然业务影响小但它的存在提醒我们即便是不重要的虚拟机也会因为底层故障跟着一起瘫。影响面评估完了恢复优先级也就清楚了先救订单、客服、对账再理内部OA最后才是开发测试。整个过程大概花了15分钟这15分钟在事后看来特别值因为业务部门在群里反复问“什么时候能好”的时候我们至少能明确告诉他们“优先恢复哪些、大概按什么顺序”。2. 为什么9台虚拟机会“集体罢工”底层逻辑拆解2.1 虚拟机和宿主机的关系一荣俱荣一损俱损要说清楚虚拟化环境为什么会“集体罢工”首先得理解虚拟机和宿主机的关系。我特别喜欢用一个类比宿主机是一栋公寓楼虚拟机是楼里的住户。住户家的电器、家具、装修可以是自己的但整栋楼的供水、供电、电梯、消防系统是共用的。如果楼里的水压出问题那家家户户的龙头都会变小如果整栋楼停电所有住户家里都黑灯。虚拟化也一样——每台虚拟机有自己的操作系统、应用和数据但它用的CPU、内存、磁盘、网卡都是从宿主机那里分出来的或者说是从宿主机背后的共享资源池里拿的。所以排查故障时有一个最基础的原则单台虚拟机出问题大概率是虚拟机自己或上面跑的应用出问题多台虚拟机同时出问题尤其是一整片同时出问题那就要把怀疑对象从虚拟机本身转移到它们共同依赖的东西上。共同依赖的无非三样宿主机、共享存储、底层网络。2.2 集体宕机的五大典型根因根据我见过的案例虚拟化环境里“多台虚拟机同时罢工”一般逃不出下面几类原因。第一类是宿主机内核崩溃或硬件故障。Hypervisor层直接挂在物理服务器上如果宿主机内存故障、CPU异常、内核panic那它上面所有虚拟机都会跟着停。这种情况最直观通常宿主机本身连管理地址都ping不通虚拟化平台会显示宿主机离线。第二类是共享存储掉线或性能卡死。虚拟机的磁盘文件如果放在共享存储上比如FC SAN或iSCSI存储那么存储控制器故障、光纤链路中断、存储端口拥塞都会导致虚拟机的IO请求全部卡住。虚拟机进程还在但系统处于“IO hang”状态看起来像死机实际是跟磁盘说话的通道断了。第三类是网络层故障。虚拟机的网卡是虚拟网卡流量要经过宿主机的物理网卡和物理交换机。如果业务网段被误删、VLAN配置错了、物理交换机端口异常所有依赖该网段的虚拟机都会“失联”但虚拟机的计算和存储其实还是正常的。第四类是认证服务失联。这一点很容易被忽略。如果公司的虚拟机统一接入活动目录或LDAP认证一旦认证服务挂了用户登录全部失败给人的感觉就是“所有系统都挂了”。但此时虚拟机本身还是健康的CPU、内存、存储都正常。排查的时候要特别注意区分“真挂”和“假挂”。第五类是资源争抢或宿主机内存超配失控。比如某一台虚拟机发生内存泄漏或者宿主机内存超配比例太高导致内核触发OOM把关键进程杀掉严重时整个宿主机进入不可用状态。这种情况通常会伴随宿主机负载飙升的告警。除了这五类还有一个容易忽略的场景虚拟化平台的管理服务本身出问题。虚拟机其实是健康的但管理控制台显示异常操作也没反应造成“看起来集体罢工”的假象。这时候要从管理网络另外的入口验证虚拟机的真实状态。2.3 这次故障为什么优先怀疑存储三个关键特征回到我遇到的这次故障当时我们把范围缩到存储层其实靠的是三个特征。第一个特征宿主机本身是活的。SSH能登上去内存和CPU正常没有内核panic日志虚拟化平台的节点也是在线状态。这就排除了宿主机崩溃和硬件整体故障。第二个特征所有虚拟机几乎同时进入“不可交互”状态而不是同时掉线。控制台能看到虚拟机列表但里面的系统操作不了。这很像IO卡死的表现。如果是网络断了虚拟机系统本身还能动远程连不上但控制台应该能看到在运行如果是认证挂了控制台登录能进系统只是业务验证过不去。这两者都和当时的现象对不上。第三个特征9台虚拟机的系统盘和数据盘全部都放在同一个共享存储上。这一点是最关键的。虚拟化架构里共享存储是所有人共用的“仓库”仓库进出货的通道一堵所有商家都得停业。把这三个特征合在一起存储故障的可能性就远远高于其他选项了。事后验证也证明判断方向没错。这也给了我一个经验遇到多台虚拟机同时卡死先别急着重启虚拟机而是先检查底层依赖的“粮道”——存储链路通不通、存储控制器健康不健康。3. 一步步排查宿主机、网络、存储的定位全过程3.1 第一步确认宿主机自身的生命体征我们排查的第一步是登录宿主机确认它自身的状况。这一步绝对不能跳。很多新手一上来就盯着虚拟机的各种状态看但实际上虚拟机的异常往往是表象底层宿主机才是根源。我先SSH登上一台宿主机执行了uptime、free -h、top这些基础命令看CPU负载、内存占用和整体负载情况。结果负载不高内存也没满说明宿主机层面没有被资源耗尽。接着看了一眼dmesg和系统日志没有发现panic、硬件报错、MCE内存错误之类的东西。再往下查我用ps命令过滤了宿主机上的虚拟机进程比如KVM/QEMU相关的进程发现进程都在但大量线程处于D状态。D状态在Linux里是“不可中断睡眠”嘴说人话就是这些进程正卡在等某个IO操作等不到就一直在那儿耗着。这个发现意义重大——虚拟机进程还活着但IO被堵死了这几乎就是存储IO hang的教科书式症状。到这一步宿主机层面的结论清楚了物理服务器没问题但虚拟机进程都被“卡在等磁盘”这个环节上。3.2 第二步检查虚拟化平台、网络与虚拟机状态宿主机没问题接下来要看虚拟化平台和网络状态。我在管理平台上刷新了一下9台虚拟机的状态栏显示“运行中”但“IP心跳”全部丢失部分虚拟机变成“无法访问”。这个组合很值得琢磨——它告诉你虚拟机进程没消失但已经不能正常干活了。网络层面我们也做了快速验证。宿主机到管理网络是通的物理交换机的端口状态也正常没有看到异常告警。但业务网络的虚拟交换机里对应虚拟机网卡的流量几乎是零。我当时用管理平台看了一眼虚拟机的网络统计发现收发包数量停留在故障发生前后的数值基本不再增长。这说明虚拟机已经不再正常处理网络数据了但网卡本身没显示故障。这一步的核心价值是让我们知道网络基础设施基本健康问题不在“路”上。结合第一步看到的D状态进程嫌疑进一步锁定到存储。3.3 第三步拆开底层检查共享存储与多路径存储检查是整个排查过程里最有戏剧性的一步。我在宿主机上查看存储设备状态先是列出系统识别的存储设备然后看多路径链路状态。正常情况下共享存储到宿主机之间应该有多条路径形成冗余。但当时我看到的情况是部分LUN已经在设备列表里变成了“failed”或“offline”多路径状态从之前的双活变成了单活甚至有的路径直接消失。我顺手做了一个简单的IO测试往某个存储卷上写一个小文件结果命令执行后长时间没有任何响应最后直接超时。这个测试很粗暴但非常直观存储卷已经没法正常读写宿主机的IO请求全堵在那里。这时候我们再登录存储设备的管理端看到的景象更触目惊心。存储控制器的状态告警已经刷了一大片双控制器之间出现心跳异常其中一个控制器反复重启存储端口也处于不稳定状态。LUN的映射关系还在但存储系统内部已经乱了部分LUN进入“不健康”状态无法正常响应读写请求。逻辑上的因果链已经很清晰了存储控制器故障 → 存储端口失联 → 宿主机到存储的多路径链路异常 → 虚拟机对磁盘的IO请求全部卡死 → 9台虚拟机集体失去响应。3.4 第四步让数据说话锁定“真凶”我向来认为排查故障最忌讳“我觉得”“我感觉”一定要用数据说话。所以在根因基本清晰之后我们又花了一点时间收集证据为后面的复盘报告做支撑。首先是时间线。我翻出监控平台的告警记录9台虚拟机的“无心跳”时间几乎集中在同一分钟的区间内。接着看存储侧日志那一时刻前后开始持续出现IO超时和链路重置的记录。两边时间一对照完全吻合。其次是系统日志。登录其中一台勉强还能查询的宿主机翻看虚拟机的系统日志能看到大量SCSI层报错、设备IO错误、文件系统进入只读状态之类的记录。这些记录的时间戳和存储异常时间也能对上。最后是监控曲线。我们平台里存了宿主机层面的历史性能数据可以看到故障发生时宿主机负载没有明显上涨但IO等待时间曲线垂直飙升。这说明问题不在CPU、不在内存而在磁盘IO——和前面所有线索指向一致。到这一步根因算是真正锁死了存储设备控制器层面的故障引发了共享存储链路中断最终导致了9台虚拟机的集体罢工。虚拟化平台的宿主机和虚拟机都是受害者。4. 恢复与复盘监控盲区、备份误区与新机制4.1 关键抉择别急着重启虚拟机先恢复底层链路根因定位之后恢复过程其实没有太多戏剧性但有一个决策很关键是先重启虚拟机还是先恢复存储我们选择先恢复存储。当时联系了存储设备的技术支持远程介入后对故障控制器做了隔离和重启操作让另一个健康的控制器接管全部LUN。几分钟后宿主机上的多路径链路开始重新合拢原先显示offline的LUN陆续回到在线状态。存储恢复之后虚拟机的IO请求开始被放行。大部分虚拟机是自动缓过来的系统从卡死状态慢慢恢复业务陆续能登录了少部分虚拟机因为文件系统出现了不一致需要进维护模式修复一下个别虚拟机干脆做了重启。整个过程又花了大约半小时9台虚拟机的业务全部恢复对外可用。这里我想特别强调一点为什么不能一上来就重启虚拟机因为在IO hang的状态下虚拟机收到的“重启”指令本身就可能卡住你按了强制重启等于是让虚拟机在没有正常刷盘的情况下直接断电。如果存储链路之后恢复了文件系统反而可能已经损坏恢复时间会被成倍拉长。正确做法是先恢复存储链路的底层健康让虚拟机自己把卡住的操作消化掉再决定要不要做进一步修复。4.2 复盘揪出的三个监控盲区故障恢复后第三天我们开了复盘会。会上最扎心的一条结论是我们的监控体系一直“看起来正常”但实际存在的监控盲区正是这次故障没能在更早阶段发现端倪的关键。盲区之一是只监控了虚拟机层面没有监控存储控制器的健康状态。虚拟机CPU高、内存高、磁盘使用率高监控平台都有告警但存储控制器的双控心跳、控制器温度、端口状态这些底层参数完全没有接入告警系统。等于说存储已经“发烧”了我们却连温度计都没插。盲区之二是多路径状态没有设阈值。多路径是不是正常应该是最基本的存储健康指标之一但我们当时的监控只显示链路是否在线不会因为链路从双活降级到单活就告警。这次故障早期多路径其实已经出现了不稳定迹象如果那时候能收到告警很多业务可能根本不会受到实质影响。盲区之三是缺少端到端的业务拨测。虚拟机的CPU、内存监控只说明虚拟机本身资源够不够但用户能不能访问、系统响应快不快需要专门的探测脚本去模拟。我们就吃亏在没有这种脚本——用户都反馈“系统很慢”了我们还在看虚拟机CPU是不是冲高。4.3 重新审视备份与恢复策略复盘到一半我们又发现了一个更吓人的问题这9台虚拟机里有几台压根没有像样的备份有的只是做了平台快照有的备份文件已经好几天没有更新过。这里必须说一句虚拟化平台的快照不等于备份。快照只是虚拟机某一时刻的状态记录而且它通常和虚拟机本身存在同一套存储上。如果存储整个挂掉快照大概率也是不可访问的。真正的备份必须把数据复制到另一套独立的存储介质上不管是另一台存储设备、备份一体机还是云端对象存储总之要和生产环境做物理隔离。我常用一个类比来解释这件事备份不验证等于没有备份。你拍一万张全家福不代表家里真的安全只有定期把照片洗出来、拿到另外一个地方看看能不能正常打开才是真保险。所以我们后来定了一条规矩重要业务的虚拟机每个季度至少做一次恢复演练从备份文件恢复出一台临时虚拟机让业务部门上去验证数据完整性和可用性。4.4 从一次故障里沉淀出的三条机制复盘会最后我们定了三条机制不是什么宏大规划就是几条能落地的规矩。第一条是故障响应分工表。明确谁负责平台操作、谁负责联系存储和网络供应商、谁负责对外沟通。这张表平时贴在墙上没人看但故障一来它就是定海神针避免所有人挤在一起抢键盘。第二条是应急第一件事清单。把“停操作、发通知、查底层、分人处理”四件事做成固定清单贴在监控大屏旁边。遇到任何大面积故障先按清单走不要临场自由发挥。这就像飞机起飞前的检查单看起来繁琐但它能防止你在慌乱中漏掉关键步骤。第三条是恢复后的演练制度。每季度选一个比较空闲的周末主动做一次“存储全断”演练人为断开一台存储设备到宿主机的链路观察监控能不能及时报警验证虚拟机能不能扛过去再测试备份能不能恢复。第一次演练的时候我们发现监控确实会漏报改完再演练效果就完全不一样了。5. 虚拟化故障速查表常见问题与避坑清单5.1 虚拟化环境“集体罢工”速查表这次故障之后我整理了一张速查表给团队当作战术卡用。遇到类似情况照着表里对应关系逐步排查比自己从零开始猜快得多。现象特征优先怀疑方向快速验证手段单台虚拟机卡死、无法登录虚拟机内部操作系统或应用异常管理控制台进去看进程、IO、资源占用多台虚拟机同时无响应宿主机正常共享存储链路或控制器故障看宿主机进程是否大量D状态检查多路径状态虚拟机列表异常但业务实际能访问管理服务或认证服务失联换一个管理入口验证用业务网络直接测存储盘显示离线、降级存储控制器、链路或多路径异常登录存储管理端看控制器健康日志检查多路径链路虚拟机失联但控制台画面还能动网络层故障检查物理网卡、虚拟交换机、VLAN配置宿主机整体不可达宿主机硬件或内核崩溃看物理服务器面板、带外管理口、内核日志这张表不能覆盖所有场景但它能帮你在一开始就框定排查范围不至于在错误方向浪费大量时间。5.2 高危操作避坑清单别亲手把故障放大故障处理过程中人的操作往往决定了故障最终的影响范围。我总结了几条“高危操作”的避坑经验每一条都有人拿血泪教训验证过。第一不要在根因未明时批量重启虚拟机。尤其是多台虚拟机同时卡死的情况你以为在“恢复系统”实际可能在制造更多文件系统损坏。先把底层链路恢复再让虚拟机自我修复才是更稳妥的顺序。第二不要怀疑“是不是被入侵了”就乱断网。集体故障发生时确实会有同事第一反应是“是不是被攻击了”然后有人会想着切断网络隔离风险。但在没有证据之前盲目断网会把本来健康的网络服务也一起干掉影响面更不可控。第三不要在应急时单人操作、不留记录。越是紧张的时候越要在操作前想清楚操作后简单记一笔。否则等故障处理完复盘的时候完全想不起来当时做过什么问题就说不清了。第四不要忽略宿主机日志里零星的存储IO告警。这类告警平时不多出现时容易被人当成“偶发抖动”划掉。但如果你发现有IO延迟变高、链路切换的蛛丝马迹一定要追查到底。这次故障的种子其实在故障前两三天就已经有迹象了。第五监控里配了告警不等于有人负责。告警发出来没人响应跟没有监控是一样的。我们后来在告警规则里强制绑定值班人告警超过15分钟无人确认就会自动升级到团队负责人。5.3 如果再来一次我会做的三个改变复盘的时候我问自己如果时间倒回故障发生的那一天我最想改什么想了一晚上有三个改变特别具体。第一个改变一开始就按“存储事故”的标准来处理而不是先把时间浪费在反复登录虚拟机、查看各种业务日志上。当时我们花了大半个小时的宝贵时间试图从虚拟机内部找线索结果虚拟机根本操作不了。一旦意识到“宿主机正常但虚拟机集体卡死”就应该立刻启动存储侧排查。第二个改变把存储供应商的技术支持电话和应急响应流程贴在所有人的通讯录置顶。这次故障中我们花了差不多20分钟才找到靠谱的联系人和正确的支持入口这20分钟在业务中断的背景下实在过于奢侈。后来我把所有关键供应商的应急联系方式做成了卡片物理打印一份贴在工位上。第三个改变提前把所有重要业务的恢复优先级白纸黑字定下来。当时我们是临时去问业务部门“哪个系统最要紧”业务部门在慌乱中给的回答并不够准确。如果提前有明确的RTO分级和恢复顺序清单应急响应会更快沟通也会更顺畅。把这个优先级表固定成文档每半年review一次业务变动时同步更新。最后再说一点心里话。在虚拟化环境里服务器是“虚”的但可用性和数据是“实”的。故障面前人人平等唯一能对冲不确定性的就是时刻保持对底层依赖的敬畏把监控做深一层把备份做到能真正恢复把演练当成家常便饭。那次“罢工”之后我给自己定了一条规矩每一次故障都要变成下一次更稳的垫脚石。这个行当谁也不敢说永不翻车但翻过车之后至少要让车里的乘客都系好安全带。