StorCLI 实战指南：MegaRAID 卡巡检、配置与故障排查技巧

半夜两点被电话叫醒机房说一台数据库服务器 IO 报警。赶到现场系统还活着但 RAID 卡已经开始滴滴响。这个时候没有 IPMI 网页、没有图形面板你面对的就是一个串口终端手里能用的只有一个叫 StorCLI 的命令行工具。StorCLI 是 Broadcom/LSI MegaRAID 系列 RAID 控制器的官方命令行管理工具也是老牌 MegaCli 的继任者几乎所有你在图形界面里能做的事——查状态、建阵列、配热备、看日志、调缓存策略——它都能做而且更适合脚本化运维。这篇文章不是把官方手册翻译一遍而是我这些年用 StorCLI 做 RAID 日常维护攒下来的一些实操经验包括常用命令、参数背后的道理以及那些容易翻车的坑适合刚接手服务器运维的新人也适合被 RAID 状态搞到焦头烂额的老手。1. 从 MegaCli 换到 StorCLI为什么我劝你别再守着老命令1.1 StorCLI 到底管什么StorCLI 服务的对象是 MegaRAID 系列控制卡比如常见的 9361-8i、9460-8i、9560-8i 这些卡。它做的事情概括起来就三件看状态、改配置、查日志。看状态包括控制器健康度、物理盘状态、虚拟盘状态、BBU 备电状态改配置包括创建和删除阵列、加热备盘、调整缓存策略、设置重建速率查日志则是把控制器固件记录的事件和终端日志拉出来用于故障定位。这三件事覆盖了 RAID 硬卡运维的绝大多数场景。有人会问都在 Linux 下用 mdadm 建软 RAID 不也够了我的观点是如果机器上插的是硬 RAID 卡能通过 StorCLI 拿到控制器固件、BBU 电容、盘位物理状态这些底层信息是软 RAID 给不了的。特别是机器不在本地、只能用 SSH 上去处理的时候StorCLI 一套命令下来比拆开机箱看面板灯靠谱得多。和 MegaCli 相比StorCLI 输出更结构化、命令路径更一致而且在新卡新固件上兼容性更好。MegaCli 到后来在不少新固件上根本跑不了。我见过太多人还在网上抄 MegaCli 的旧命令粘贴到新环境直接报 command not found。如果你还在守着旧习惯真的可以考虑换过来了。MegaCli 的维护早就停止了新控制器和固件只保证对 StorCLI 的兼容继续用旧工具等于替自己埋雷。1.2 快速安装版本和平台别搞混StorCLI 的安装包没有像 apt 那样进官方软件源需要去 Broadcom 官网的 MegaRAID 支持页面下载。现在主要形式是 LSI_MR_STORCLI_xxx.zip解压后里面有按操作系统区分的目录通常有 rpm 和 deb 两种包。RHEL/CentOS 系用 rpm 安装Debian/Ubuntu 用 dpkg 安装cd /tmp/LSI_MR_STORCLI rpm -ivh StorCLI-xxx.noarch.rpmDebian/Ubuntu 则是dpkg -i storcli-xxx.deb安装后的默认路径一般是/opt/MegaRAID/storcli/storcli。我会习惯在/usr/local/bin下做一个软链接否则脚本里每次都写全路径非常啰嗦ln -s /opt/MegaRAID/storcli/storcli /usr/local/bin/storcli storcli -v版本选择上有一个常见的坑不要因为手头的卡是老型号就去下最老的包也不要盲目追新。StorCLI 新版本通常向后兼容老控制器但个别大版本会调整输出格式如果你为几十台机器统一封装脚本升级工具版本前最好先在测试机跑一遍 show all确认脚本要解析的关键字段没变。否则同一套脚本在别的机器上表现正常升级之后的机器上就可能 awk 切列切错排查起来非常浪费时间。2. 上机第一件事把控制器和磁盘状态盘清楚2.1 三条命令看清家底拿到一台新机器我的巡检习惯是先用storcli show all确认控制器被系统正确识别。如果这台机器插了 RAID 卡但没有任何输出先别急着怀疑命令很可能是驱动没加载或者 BIOS 里没开启 RAID 模式。storcli show all storcli /c0/eall/sall show storcli /c0/vall show这三条命令分别回答三个问题机器上有几块 RAID 控制器、每个盘位的物理盘状态、控制器上已经建了哪些虚拟盘。物理盘输出大致长这样EID:Slt DID State DG Size Intf Med SED PI SeSz 32:0 4 Onln 0 3.638T SATA HDD N N 512B 32:1 5 UGood - 3.638T SATA HDD N N 512B 32:2 6 Offln 0 3.638T SATA HDD N N 512B这个输出里的 State 列是重点。Onln 是正常在线UGood 是盘被识别到了但还没加进任何虚拟盘Offln 是掉线。看到 Offln 第一反应是赶紧查硬盘灯和物理连接大概率是盘坏了或者背板供电出了问题。再配合storcli /c0/bbu show看备电状态。BBU_Status 正常一般是 Optimal如果出现 Degraded 或者 charge 很低就要安排时间去换电池不然接着掉电就会面临缓存写回数据丢失的风险。BBU 的问题往往是静默发生的系统负载看不出异常但 RAID 卡内部可能已经把写策略从 WriteBack 降级成了 WriteThrough性能悄悄掉一截。2.2 从 EID:Slt 到 /dev/sdX盘位识别是基本功StorCLI 输出里每个盘都有一组 EID:Slt 编号。EID 是磁盘笼子或者 expander 的编号Slt 是物理槽位。很多服务器前面板印的盘位编号和 Slt 是对应的比如 Slt 1 就是前面板第二个硬盘位从 0 开始。这个编号是定位故障盘最重要的依据比 /dev/sda 可靠得多。在同一台机器上/dev/sdX 由内核注册顺序决定重启之后完全可能变。比如原来 /dev/sdb 是 RAID1某次重启后变成了 /dev/sdc。如果在 fstab 里写死 /dev/sdb开机就可能挂不上数据盘。所以识别盘用 /dev/disk/by-id 或者 UUID如果要对应到 StorCLI 的物理盘位则需要先跑storcli /c0/eall/sall show输出里每个物理盘后面会带 Device 列比如Device /dev/sdc表示这个盘位对应系统的 /dev/sdc。多盘机器尤其要注意先确认再操作别凭记忆去格式化。3. 创建和调整 RAID从新盘到可用的完整过程3.1 选 RAID 级别时我在想什么创建 RAID 之前先选级别不假思索全都 RAID5。我习惯用一张表来对比RAID 级别最少盘数容错能力可用容量适用场景RAID02无全部临时缓存、可丢失数据RAID12单盘50%系统盘、小容量关键数据RAID53单盘(N-1)/N读多写少的通用文件存储RAID64双盘(N-2)/N大容量机械盘、重建时间长RAID104偶数每组单盘50%数据库、高随机读写业务实际选型还要看控制器缓存和盘的类型。SSD 的 RAID5 重建时间短但写惩罚依然存在大容量机械盘阵列我更偏好 RAID6因为单盘故障重建要很长时间这段时间里没有双冗余兜底是很吓人的。RAID5 在重建过程中如果又坏一块盘整个阵列直接完蛋这在现实的故障里其实不算少见。还有一点必须强调别把 RAID 当备份。RAID 只解决磁盘故障导致的中断解决不了误删、勒索病毒和控制器损坏。阵列坏了要恢复数据那是另一个层面的故事。所以创建之前问清楚数据丢了能接受重新生成吗能就追求容量不能就把冗余做足并且另找备份方案。3.2 创建虚拟磁盘的命令与参数拆解确认盘位没问题就可以创建虚拟盘。假设控制器是 /c0有 32:0 到 32:3 四块盘我想建一个 RAID10storcli /c0 add vd typeraid10 nameDATA drives32:0,32:1,32:2,32:3命令拆开解释/c0指定控制器 0add vd表示增加虚拟磁盘typeraid10指定 RAID 级别nameDATA是给虚拟盘起个别名强烈建议起后面映射 by-id 时能省不少事drives32:0,32:1,32:2,32:3指定参与阵列的物理盘位多个盘用逗号分隔连续盘位也可以写32:0-3这一步在大多数 MegaRAID 卡上不需要额外指定大小默认会把盘的所有空间用掉如果只想用一部分空间可以加size500gb参数。创建成功之后一般要初始化storcli /c0/v0 start init初始化会清空数据如果是刚从备件库拿出来的新盘这一步很必要如果盘上原来有数据别手滑。创建后立刻用storcli /c0/vall show确认状态State 要从不存在或者 OFLN 变成 Optl。Optl 是 Optimal 的缩写看到这个基本放心了Degrd 表示阵列处于降级状态说明有盘掉线但数据仍可用需要尽快处理。3.3 热备盘与重建速率的正确配置热备盘是阵列的备用轮胎。全局热备可以给这个控制器下所有虚拟盘用专用热备只给指定 DG 用。命令很直接storcli /c0/eall/sall add hotspare drive32:8不加 DG 参数时默认是全局热备如果希望它只保护某个虚拟盘所在的 DG可以加dg0。热备盘平时不参与读写阵列里某块盘坏了控制器会自动拿热备盘顶上状态变成 RtD随后开始重建。重建过程会占用控制器和磁盘 IO拿高速业务盘做重建显然不合适。可以在创建完阵列后设置重建速率storcli /c0 set rebuildrate30这个 30 是百分比官方建议默认值就是 30%。白天高峰不想让重建太抢 IO可以临时调低到 10%晚上再调回 50%。别调成 100%实测重建速度未必提升多少业务卡顿倒是立竿见影。还有一个容易忽略的是 Patrol Read巡读。控制器会定期把阵列里的数据读一遍提前发现坏块。默认配置可能一天跑多次也可能从来不跑取决于固件缺省。可以查看当前状态storcli /c0 show patrol如果业务是 7x24 在线建议把巡读时间错开到凌晨避免白天扫盘引发 IO 延迟。具体参数每个固件版本略有差别但大多可以在开机 BIOS 的 RAID 配置界面里设置。无业务窗口的时候最好让巡读定期跑起来坏道这种东西早发现一天可能就少丢一整块盘的数据。4. 日常巡检脚本用 StorCLI 守住 RAID 的最后一道防线4.1 巡检时我重点盯哪几个指标RAID 控制器处于系统的最底层平时没人注意一旦出问题就是连锁反应。我平时巡检只看四个东西控制器状态、虚拟盘 State、物理盘 State、BBU 状态。串成一条巡检链路最快的方法是写脚本循环跑 StorCLI然后过滤关键状态。下面是一个简化版的巡检脚本思路#!/bin/bash CTRL$(storcli show all | awk /^Ctl / {print $2} | tr -d :) if [ -z $CTRL ]; then echo CRITICAL: No MegaRAID controller found exit 2 fi for c in $CTRL; do echo controller $c storcli /c$c/vall show | grep -E ----|^[0-9] storcli /c$c/eall/sall show | grep -E EID|^32:|^/c storcli /c$c/bbu show | grep -E BBU_Status|Charge done脚本本身不复杂真正有价值的是后面的判断逻辑。虚拟盘 State 只允许出现 Optl其他都算异常物理盘除了 Onln、DHS、GHS 以外的状态比如 UGood 要看是不是新盘还没加入阵列Offln/Foreign/Bad 则必须告警。光看脚本输出还不够很多故障在事件日志里有预兆比如某块盘链路稳定性差、S.M.A.R.T. 错误频繁。单独靠状态列很难发现。所以更完整的巡检要定期把事件日志落盘storcli /c0 show events /var/log/megaraid_events_$(date %F).log再配合 crontab 每周跑一次保留最近三个月出问题时有据可查。等到 RAID 卡开始滴滴叫的时候再去看日志往往已经晚了。4.2 缓存策略WriteBack 与 WriteThrough 怎么选MegaRAID 虚拟盘缓存策略直接影响读写性能。看状态时 Cache 列出现的 RwBd 意思是 Read WriteBack、Direct而 WriteThrough 显示为 RwT。配置命令如下storcli /c0/v0 set rdcachera wrcachewb几个参数的含义rdcachera打开预读适合顺序读随机读场景可以norawrcachewb写回数据先写进控制器缓存再慢慢落盘性能明显更高但如果断电且缓存没有 BBU 保护缓存里的数据就丢了用个比喻WriteThrough 是窗口办事当场办完再放你走WriteBack 是先给你发个号、窗口攒一批统一处理。控制器缓存就是那个等候区。没有 BBU/电容保护等候区断电就清零所以硬件设计成 WriteBack 必须依赖 BBU没有 BBU 就只能 WriteThrough。查看 BBU 状态用storcli /c0/bbu show。如果 BBU 老化到 Optimal 之外控制器会为了安全自动把写策略切回 WriteThrough性能会突然掉下来这种不起眼的劣化在监控里很难发现。有的卡支持 forcewb就是缓存策略强制写回即使 BBU 状态不好也硬来。我的建议是不要在生产环境开这个选项。省下的那点性能与数据丢失风险完全不对等。你有 UPS 不等于 RAID 卡一定安全因为 UPS 切换和服务器电源之间还有各种意外。4.3 事件日志故障发生前的黑匣子StorCLI 的事件日志输出格式很原始一行一条按时间倒序排列。我一般这样用storcli /c0 show events | tail -n 100还有终端日志 termlog如果控制器曾经因错误自动重启termlog 能看到比事件日志更底层的输出。多数时候我们只关注事件里带 WARNING 和 FATAL 的条目。固件版本更新后日志格式也会变脚本解析时最好用关键词匹配而不是死板地按列切。我会在正式巡检脚本里加入这样一段判断逻辑把事件日志里出现 MediaError、PredictiveFailure、RebuildFailed 的行挑出来单独发告警邮件。这几个关键词基本覆盖了磁盘坏道、预测性故障和重建失败三类最常见问题。像这样的细节等出了问题再研究就来不及了。5. 踩坑记录Foreign、JBOD 和重建中的反转5.1 Foreign 状态处理链路运维最怕看到盘位 State 变成 Foreign。Foreign 不是盘坏了而是盘上带着外来配置。最常见场景是从另一台服务器拆下来的盘、RAID 卡故障更换后旧盘插回新卡、或者把盘插到了别的槽位。控制器发现盘上的元数据和自己的配置不一致就把它标记为 Foreign。处理链路分几步先看清楚哪些盘是 Foreignstorcli /c0/eall/sall show确认这些盘是不是别人机器上拔下来的数据重不重要。如果是需要保留的阵列最好先把盘按原顺序插回原卡或者考虑导入外部配置而不是急着删除。确认不需要保留盘上的旧配置后执行storcli /c0/eall/sall delete foreign再跑一遍 show盘应该变成 UGood 或者 Onln就能重新加入阵列。这里必须泼一盆冷水delete foreign 删掉的只是盘上的 RAID 元数据不是用户数据。理论上是这样但实际遇到盘上有专属加密、或旧虚拟盘配置信息时删除之后盘里的逻辑卷数据也可能变成不可读状态。所以任何操作之前先把重要数据备份出来。这不是胆小是吃过亏之后的条件反射。5.2 UGood 盘为什么上不了线新插进服务器的物理盘如果从未被这个控制器使用过状态通常是 UGoodUnconfigured Good。很多新手看到盘显示正常就直接去系统里 mount结果 lsblk 里根本没有对应设备。原因很简单RAID 控制器还没把它加入任何虚拟盘系统层面看不到。这不是盘的问题是它还没有被正式纳入阵列。特殊情况阵列里一块盘坏掉你换了新盘控制器通常会自动开始重建不需要手动 add。如果换上去的盘状态是 UGood 但没有自动重建很可能是它被标记成了热备或者控制器没识别到替换事件。可以先执行storcli /c0/e32/s4 set good force把盘转成可用的 Unconfigured Good 状态再让控制器重新扫描一下通常重建就自动开始了。要警惕的坑是 set good 会把盘从 Foreign 或 Offline 状态强行转回可用状态。如果这块盘是刚才从运行中的阵列里被误拔出来的set good 可能让控制器把它当成一块全新盘反而破坏了原阵列的一致性。处理故障盘时先离线确认原因再决定是否 set good顺序反了就是事故。5.3 盘符漂移别用 sdX 认盘最后聊一个几乎人人都会遇到的坑重启后 /dev/sdb 不见了备份脚本找不到磁盘。原因在于 RAID 虚拟盘最终呈现给系统的 sdX 是驱动扫描顺序决定的盘位、SATA 控制器、Linux 内核版本都会影响。最稳妥的做法是在 fstab 和脚本里用 UUID 或者 /dev/disk/by-id 引用。对 StorCLI 场景创建一个带名字的虚拟盘后by-id 路径里会出现很明确的标识配合 name 参数非常好认。如果你一定要在脚本里映射 sdX 和盘位建议动态解析而不是写死先跑storcli /c0/eall/sall show读出 Device /dev/sdX 那一列再映射到 EID:Slt。这样即使盘位调整过脚本下次运行时也能自动对上。我吃过一次亏给某台机器做过一次盘位交换结果凌晨备份脚本因为盘符变化直接失败白白损失了一个备份窗口。从那以后我所有服务器上的 fstab 和备份配置全部改成 UUID 引用RAID 相关脚本统一以 StorCLI 的 EID:Slt 为准。另外如果你的机器有多个控制器storcli show all会列出多个 Ctl每个控制器下的盘位编号是可以重复的比如 /c0/e32/s0 和 /c1/e32/s0 是两个完全不同的盘。脚本里一定别只拿编号去拼串控制器的 c 编号也要带上。这种低级错误一旦发生轻则误操作盘位重则选错控制器初始化后果不堪设想。