1. 报警那天的完整排查链路IMM、前端LED与MegaCLI三方验证1.1 我接到告警后的第一反应先说清楚圈里常说的“3560 M3”其实指的是IBM System x3650 M3一台2U机架式服务器。我手头这台已服役超过十年跑一个老业务系统的数据库内部是四块600GB SAS 10K盘组RAID5阵列卡配的是ServeRAID M5015带512MB缓存和BBU电池。这类老平台现在在各大机房里还大量活着碰到坏盘几乎是每年必有的剧本所以我打算把这次完整更换过程写下来包括排查逻辑、操作步骤、重建阶段要注意什么把“换一块盘”这件事讲透。那天下午我先收到自建监控平台发来“Array Degraded”的告警紧接着是IMM发来的邮件通知。我的第一反应不是拔腿就往机房冲而是先冷静做一件事确认到底是“真坏”还是“假坏”。RAID卡上报坏盘其实分好几种情况最常见的是“Predictive Fail”预计失效和“Failed”已失效还有一种就是纯粹的误报可能是某次瞬时链路抖动、硬盘温度过高或是背板接口接触不良。如果把一块还在线的“Predictive Fail”盘当成坏盘直接拔掉RAID5瞬间掉到Degraded相当于自己主动把窗口期提前了万一期间另一块盘发现问题事态就直接升级。1.2 三种途径确认故障盘位我的排查顺序固定是三路并行互相验证IMM管理口浏览器打开服务器IMM的HTTPS页面在Storage或Event Log里看RAID卡上报的事件能定位到具体的物理盘编号和事件类型前面板LEDx3650 M3的盘位在正面每块盘都有活动灯和琥珀色故障灯。坏盘或定位盘会常亮琥珀灯现场最直观MegaCLI命令行服务器装的是Linux直接跑命令交叉验证MegaCli64 -PDList -a0 | grep -E Enclosure Device ID|Slot Number|Firmware state|Media Error Count|Other Error Count|Predictive Failure Count这次MegaCLI输出里Slot 1那块盘的Firmware state显示为“Failed”Media Error Count积了不少控制器事件日志也有盘掉线的记录。三路信息指到同一块盘我才真正确定要换。1.3 Firmware state先分清Failed和Predictive Fail再动手在RAID卡眼里物理盘有几个典型状态我在表格里列一下方便刚接触的人对照Firmware state含义处理倾向Online, Spun Up正常在线盘已启用无需操作Rebuild正在参与重建不要动它耐心等Failed控制器已判定失效盘不可访问尽快更换Predictive Fail盘还在线但SMART/错误计数异常随时可能挂先观察加备件规划维护窗口更换Unconfigured(good)未配置进阵列但盘本身健康通常就是新换上的盘等着自动重建Foreign盘上残留其他RAID配置需要清除Foreign配置后再使用我见过不少同行看到“Predictive Fail”就当已经坏了其实这类盘只要业务允许可以先用备份策略顶上等低峰期再换避免在业务高峰主动引入一次重建负载。反过来Firmware state已经明确是Failed就别拖了越早换越好。这次的情况属于后者当机立断。2. 四盘RAID5为什么会“只剩三盘还能撑”容错原理与风险窗口2.1 RAID5是怎么用一份校验数据保护N块盘RAID5的原理一句话可以概括把数据分成块均匀分布到所有成员盘同时每块盘都存放与其他盘数据对应的校验块这个校验块是分布式存放的。四块盘组RAID5实际可用容量是“四块中减一块”多出的那一块盘容量全部用来存校验信息。任意一块盘整体挂掉后控制器从剩余三块盘上读取数据块和校验块做异或运算就能把丢失盘上的数据还原出来。这也是为什么降级状态下业务还能继续跑读性能甚至影响不大就是写性能会有所下降。不过这里有个很多人容易忽略的点RAID5的一套校验机制只能顶住一块盘同时故障。这也是“R5”和“R6”最本质的区别。R6用了两个分布式校验块能同时坏两块还能保住数据但写开销也更大。在R5阵列里任何时刻发生两块盘同时掉线的极端情况数据就真的读不出来了。这也是“服务器做的RAID5无法读取数据”这类求助帖最常见的成因——不是R5本身不行而是窗口期没控制好。2.2 M3平台上的阵列链路M5015、背板、BBU这台M3上数据流向是这样的前面板硬盘插入热插拔背板背板通过两条SAS线缆连接ServeRAID M5015阵列卡M5015基于LSI 2108芯片512MB缓存BBU提供掉电保护。搞清楚这个链路能帮你在新盘不被识别时快速定位是盘的问题、线缆问题还是卡的问题而不是上来就瞎折腾。需要顺带一提的是M5015本身支持RAID0/1/5/6/10不需要额外授权而同代常见的M1015只有RAID0/1/10刷了IR模式的固件依然做不了硬RAID5。所以如果你在M3上看到“RAID5”字样那基本就是M5015或更高级别的卡。如果手头机器是M1015还打着RAID5的旗号大概率是主板上Southbridge做的软RAID处理方式完全不同。2.3 从一个“两块盘同时坏”的案例说高危窗口期我认识的一位同行维护过一台类似的M3RAID5里的一块盘报警掉了他因为备件在途决定先撑两天。结果第二天下午第二块盘也亮起故障灯整阵列直接无法识别系统盘读写报错数据库无法启动。虽然后来数据通过专业数据恢复机构救回来一部分但代价相当大。所以我在确认第一块盘是Failed之后几乎同时就把“备件采购”“更换窗口”排进了当日计划里。在重建完成前整个阵列都处于“一触即溃”的脆弱状态。哪怕白天业务忙我也建议至少先和业务方约定一个晚上或者凌晨的替换窗口设备热插拔并不需要停机但换完后的重建风险和业务高峰叠加还是尽量避免为妙。3. 备件选型与换盘前必须完成的功课3.1 盘规格怎么确认SAS/SATA、容量、转速换盘前第一件事是确认替换盘的规格。这一步看似简单其实是最容易翻车的环节接口类型是SAS还是SATA。x3650 M3的背板通常SAS/SATA都兼容但SAS背板插SATA盘没问题反过来就行不通。如果不确定直接从PDList里看Media Type字段或者看盘体标签。容量替换盘容量不能小于原成员盘。拿一块更大的盘也能用但重建时只会使用和阵列一致的那部分容量剩余空间RAID卡不会自动并入不要指望“在线容量扩展”。M5015的阵列如果想真正扩容需要在控制器支持且具备足够空盘位的特定流程下操作那是另一个话题。转速SAS盘常见的有10K和15K建议与原盘保持一致最多允许个别转速差异。混转速盘虽然能重建但会导致整个阵列的性能被最慢的那块拖累。这次我原盘是IBM原装600GB 10K SAS备件也按这个规格准备。这里有一个细节如果你是从二手渠道买盘务必让卖家确认盘体没有被清过SED加密或者做过低格以免插上去以后盘卡在安全锁定状态。3.2 原厂盘和第三方盘的选择建议关于“必须原厂FRU还是第三方也能用”我的系统性说法是M5015物理盘兼容性不算苛刻第三方SAS盘插上去通常能被识别并完成重建但ServeRAID Manager里可能标记为Uncertified部分环境也会因为固件差异导致告警面板不干净。对于核心生产系统我倾向至少保证相同接口、相同规格、相近固件版本最好还是IBM FRU兼容盘。尤其是已经跑了多年的老阵列控制器固件版本可能很旧太新的盘固件反而可能出现不识别或事件噪声这时候先升级M5015固件再换盘会更顺畅。3.3 备份、业务窗口与现场工具清单再急也不要省掉备份这一步。我的流程是数据库做热备份并传到另一台机器检查备份文件大小和日志完整性和业务确认低峰期这次是凌晨1点到6点重建预计在6小时内完成时间刚好准备好防静电手环、螺丝刀备用、酒精棉片清洁盘位触点以及一台能随时连上IMM的笔记本。如果现场条件允许我还习惯在操作前把阵列卡当前配置导出一份MegaCli64 -CfgSave -f /root/raid_config_backup.cfg -a0这样即便后面发生什么意外也能对照原始配置恢复。这个步骤执行只要几秒钟关键时刻是保命的。4. 热插拔换盘实操从盘托拆装到新盘自动入列4.1 三重确认盘位再动手热插拔最怕的就是拔错盘。我给自己定了一条铁律拔盘之前必须完成三重确认——第一重IMM事件日志和MegaCLI里记录的失败物理槽位第二重现场看前面板对应位置是否有琥珀色故障灯常亮第三重再看一眼MegaCLI输出的Slot Number和Enclosure Device ID确认“252:1”这类编号不是后置盘位或别的控制器的盘。M3的前置盘位编号从左到右但如果你机器装了后置盘位模块编号顺序会接在前置之后光看MegaCLI不够。之前我就因为图快差点按记忆中的“第三块”去拔结果那次坏的是第二块这个错误一旦发生就是事故。宁可多花三分钟反复核对也不能凭感觉。4.2 抽旧盘、插新盘的具体动作M3的盘托上方有一个带锁扣的把手操作时按一下锁扣拉出把手就能把整块盘连同盘托抽出来。抽旧盘时动作要平稳SAS盘在运转中拔槽时控制器会感知到物理移除并更新阵列状态为Degraded这是正常现象。抽出后顺手看一眼盘体标签把SN/FRU记录下来既方便找备件也是给这次变更留记录。新盘装进盘托时要注意方向一般盘体接口朝服务器内部推入导轨时不要用蛮力确认完全到位后再压下把手锁紧。插好后前面板的活动灯会闪烁一下接着盘开始旋转然后RAID卡在几十秒内会识别到新盘。4.3 新盘出现Foreign状态的处理很多新手换完盘会蒙新盘虽然被识别了但不管等多久阵列都不重建。这时候大概率是盘状态卡在两个地方——Foreign或Unconfigured(bad)。Foreign在二手盘市场非常常见因为拆机盘身上往往残留着上一台机器写入的RAID配置信息。处理办法是把新盘上的残留配置清掉但执行时绝对要精确到物理盘MegaCli64 -PDList -a0 | grep -E Slot Number|Firmware state MegaCli64 -CfgForeign -Clear -PhysDrv [252:1] -a0这个-CfgForeign -Clear只对指定物理盘生效但风险在于如果你写错了槽位号把阵列里原有的好盘的Foreign状态直接清掉结果就是RAID配置丢失。所以执行前必须用第一条命令确认新盘的Enclosure Device ID和Slot Number准确无误再动手。拿不准的时候重启进webBIOS开机自检按CtrlH界面里会明确标记Foreign盘在那里处理更直观。4.4 重建不自动开始的排查M5015默认开启AutoRebuild正常流程下识别到Unconfigured good的新盘后30秒到几分钟内就会开始重建。如果你等了超过10分钟还没动静依次检查新盘状态是否真的是Unconfigured(good)而不是Foreign或Unconfigured(bad)虚拟盘状态是否还是Degraded而不是因为某种原因已经被删了RAID卡策略是否被人为关闭了AutoRebuild背板连接是否正常盘是否完全插到位。我在现场还碰到过一个比较特殊的案例换进去的SATA盘被控制器识别后Slot映射出现错位导致重建一直没有把盘归入原虚拟盘逻辑槽位后来把盘重新插拔一次映射刷新后才恢复。所以别急着下结论先做基础物理层确认。5. 重建期间必须盯住的几件事进度、时间和性能5.1 重建时间受什么影响怎么估算重建并不是一个简单的“等进度条”它实际上在持续读取阵列里所有存活盘的数据和校验块计算出丢失盘的数据再写入新盘。因此重建速度取决于三方面盘本身的读写速度与容量容量越大时间越长阵列卡缓存策略有BBU时Write Back还能撑一下性能没有BBU被迫切到Write Through性能会差很多重建期间业务负载IO越忙重建越慢。我这次600GB 10K SAS盘在业务空闲时段重建实际耗时约4小时45分钟。以前换过一块1.2TB的盘业务高峰期重建跑了将近10个小时才完成。所以运维在排计划时不要只按“TB数除以理论速度”估时间而要根据历史经验和业务负载留出至少一倍余量。5.2 命令行与webBIOS双角度看进度重建期间我一般用两种方式盯进度一种是通过MegaCLIMegaCli64 -PDRbld -ShowProg -PhysDrv [252:1] -a0输出会显示重建百分比、剩余MB数和预计剩余时间。我习惯写个简单脚本每30分钟抓一次存到日志里形成一条完整的“重建进度曲线”哪段变慢了一目了然。另一种是在webBIOS界面直接看适合没有Linux环境的Windows服务器。开机自检按CtrlH进入M5015的配置界面在Virtual Drive列表里就能看到重建进度百分比。IMM侧也能看到事件日志但进度还是要以RAID卡输出为准。无论Linux还是Windows关键都是看虚拟盘状态重建完成后状态会从Degraded变为Optimal。5.3 重建期间的红线清单我把这段时间该避开的坑整理成了一份清单基本就是我的操作铁律不要随意重启服务器。强制复位会导致重建中断虽然多数情况下能断点续跑但不值得赌不要这时候跑全量备份、批量数据导入、报表大查询等重IO任务尽量把业务负载压到最低不要拔任何一块看起来“空闲”的盘哪怕它状态正常也绝不能在重建期间动它确保IMM远程控制台随时可访问万一现场出问题还能远程操作观察关注机房温度和风扇转速重建期间整机功耗和发热都会上升。实际上重建期间业务是不停的我这边数据库读写延迟有轻微上升但整体还能接受。如果是对IO极其敏感的业务我还是那句话提前申请维护窗口别让重建和业务峰值撞在一起。6. 收尾验证与这次踩过的坑6.1 重建完成后的五步检查重建到100%不代表马上就能拍拍屁股走人我习惯做一轮完整验证虚拟盘状态回到Optimal阵列卡事件日志没有新的警告新盘Firmware state变为Online, Spun UpMedia Error Count没有上涨手动触发一次一致性检查让控制器把整个阵列的条带重新读一遍确保重建后的数据无误MegaCli64 -LDSetProp -StartCC -L0 -a0检查IMM事件日志确认故障告警已恢复后续两天继续观察新盘SMART数据和错误计数确认没有“带病上岗”。6.2 三个值得记录的教训第一个教训是关于“Predictive Fail”误操作的。早年在另一台机器上我看到盘上报Predictive Fail没多想就直接换了。结果拔掉的一瞬间阵列变成Degraded而那块盘其实很可能还能扛很久完全可以安排在低峰期稳妥操作。所以我现在看到Predictive Fail会先看错误计数增长趋势再决定是立刻换还是规划窗口而不是看到告警就冲动。第二个教训是新旧盘固件差异。这次备件盘固件版本和原阵列里四块盘不一致M5015倒是照常识别重建但ServeRAID Manager里一直有“Firmware mismatch”的提示看着很烦。后来用IBM官方固件刷新工具把新盘刷成与原阵列一致提示才消掉。如果你不在意告警面板“不干净”不刷也能凑合但生产环境还是尽量统一。第三个教训是老生常谈但值得再说一次的换盘前后务必做好变更记录。我把这次更换的日期、盘位、旧盘SN、新盘SN、固件版本、重建起止时间全部写进表格里。几个月后再出问题翻记录就能看出这台机器哪块盘是“后换的”备件管理也不会乱。最后分享一个我自己养成的小习惯坏盘拔下来后不要直接丢到废品箱先用马克笔在盘体上标记“坏”字和日期放回防静电袋。因为这些旧盘上的FRU号和固件版本标签有时候就是下次选配件的唯一线索等新盘稳定运行一两个月后再做报废处理也不迟。经历过这次完整流程我对M3这类老平台的态度其实更清楚了设备再老只要监控到位、备件有余、流程规范RAID5阵列依然是可靠的。但如果你问我我会优先建议下回在预算允许时给这类机器加一块热备盘。一块热备盘的成本相比“坏盘后那几小时的高危窗口期”带来的心理压力和潜在风险真的不算贵。