简介这是华为服务器专用的RAID阵列卡驱动升级包面向负责服务器存储维护的系统工程师解决SR130阵列卡基于LSI3008芯片在Windows Server 2012 R2等环境下的驱动更新与固件升级问题。资源共9个文件压缩包仅2.37MB包含bin格式固件如3008IR.bin、rom格式SAS控制器ROM、sas3flash刷写工具、flashoem固件升级程序、install.sh自动化安装脚本及version.xml版本信息文件等结构清晰便于按需选用。已有514人学习下载。通过该资源可完成从驱动加载、固件刷写到阵列卡状态验证的完整流程并借助sas3ircu等工具进行配置与监控覆盖RAID 0/1/5/6/10等多种级别场景有助于提升服务器存储稳定性与数据安全性是排查阵列卡兼容性及驱动异常的有用工具包。1. 华为 RAID 驱动包 RAID-SR130-3008IR-FW-15.00.07.00-Update1这张包到底管什么服务器存储栈里最容易被当成装完就忘的一层就是 RAID 控制器。某天业务侧报 IO 延迟飙升或重启后阵列降级你再回头翻固件版本才发现控制器固件还在出厂时的老版本OS 里的驱动也两年没动过。这张名为华为 RAID 驱动 RAID-SR130-3008IR-FW-15.00.07.00-Update1 的升级包就是针对 SR130 这张 RAID 卡的一次完整固件与配套驱动更新版本号 15.00.07.00Update1 表示它不是首个发布版而是修正过一轮问题的迭代版。这个包解决的是两类痛点一是控制器固件层面的兼容性修复比如与某些 SSD 型号的协议握手异常、掉电后 RAID 日志记录不完整二是操作系统驱动层与固件不匹配导致的链路不稳定。适合的人群非常明确——机房里有 SR130 控卡、系统盘或数据盘挂在它后面的运维和集成工程师准备做一次版本收敛把存储底座的隐患在业务上线前或低峰期处理掉。下面按我自己的操作习惯把这个包从拆解、准备到刷写、验证讲完整过程中会给出能直接抄的命令和必须注意的坑。2. 先搞清楚手里的东西RAID-SR130、3008IR 与固件驱动的边界很多人在这个标题上犯的第一个错是把驱动升级包当成一个东西。实际上这个包里至少装着两层内容控制器的固件Firmware和操作系统用的驱动程序Driver。固件跑在 RAID 卡自己的处理器上驱动跑在 OS 内核里两者通过 PCIe 总线通信。升级固件不重启系统有时也能生效但驱动版本和固件版本不匹配时阵列性能和稳定性都会受影响。2.1 型号拆解SR130 是什么3008IR 又是什么SR130 是华为服务器上常见的入门级 RAID 控制器型号面向单路或双路机架服务器支持 RAID 0/1/10 这些基础级别也支持直通模式JBOD。它采用的底层芯片是 LSI 的 3008IR——注意这个 IR 结尾代表它在硬件层面只做 RAID 0/1/10不支持 RAID5/6。如果你在 feiquan 上看到有人讨论 SR130 是否能做 RAID5答案是不行这不是固件锁出来的功能而是 3008IR 芯片本身的定位。驱动包命名里的 3008IR 直接标注了芯片方案这对排查问题非常关键。Linux 内核里和它对应的驱动模块是 mpt3sas而不是老的 mpt2sas。很多人在服务器上 lsmod 一看有 mpt2sas 就以为驱动没问题实际上 SR130 必须走 mpt3sas 这条链路。查看当前生效的模块用下面这个命令lsmod | grep mpt # 明确看是否有 mpt3sas若只有 mpt2sas说明驱动装错或内核未加载正确模块逻辑说明lsmod列出当前加载的内核模块grep mpt过滤出与 SAS/RAID 相关的部分。正常情况下应该看到 mpt3sas 及其依赖的 mpt3ctl 等模块。如果输出为空说明驱动根本没装上盘虽然能认出来但走的是内核里的通用 SCSI 路径性能和异常处理都会打折。参数说明这里不需要额外参数。重点是判断模块名而不是看设备节点。部分服务器厂商定制内核里会把 mpt3sas 编译进内核built-in此时lsmod查不到是正常的需要用cat /proc/modules | grep mpt3sas或直接看/sys/module/mpt3sas目录是否存在来确认。2.2 固件和驱动各管一段互不替代初做服务器运维的人最容易产生一个误区驱动更新到最新固件就无所谓或固件刷了新驱动就不用管。这个认知在 SR130 这套组合上很容易翻车。固件负责 RAID 元数据管理、盘状态迁移、掉电保护策略驱动负责把内核的块 IO 请求翻译成控制器能理解的 SCSI 命令。两者版本差距过大常见现象是系统能启动、盘能识别但高负载下 io 超时或者smartctl读不到盘的健康信息。我在本地某模拟项目X 里维护一台安装了多块 SSD 的服务器升级包刚放出来时我只刷了固件没有升驱动结果连续跑了两天 fio 后一块盘掉线日志里满是mpt3sas: log_info报错。把驱动同步升上去之后同样压力下再没有出现异常。这个经验让我养成了习惯凡是带 FW 字样的更新包驱动部分也要一起评估不要只挑固件刷。注意一款 RAID 卡的固件和驱动并不是同一个发布节奏厂商在打包时已经做过组合验证所以优先使用同编号包内的配对版本不建议固件用 A 包、驱动用 B 包。2.3 升级包的 Update1 到底改了什么Update1 通常意味着首版发布后收到过缺陷反馈。对于 RAID 控制器这类底层设备常见修复点包括特定型号 SAS SSD 的间歇性断链、RAID 重建过程中异常掉电导致元数据不一致、以及某些 Linux 内核版本下 IO 队列深度设置不合适造成的性能回退。具体到这个版本文本里的 15.00.07.00它遵循的是 LSI/AVAGO 时代的固件版本编号习惯——大版本加小版本加构建号15 开头代表这是一条长期维护分支。如果当前固件已经是 15.00.06.xx 或更早的 15.00.05.xx升级到 15.00.07.00 的风险很小因为整个 15 分支的元数据格式没有变化。如果当前固件是 4.x 或 6.x 这类老分支升级路径就要谨慎一些部分场景下控制器会连同 BIOS 配置一起重置导致启动时找不到引导设备。3. 升级前准备必查的六项信息和一张回退方案固件升级是有风险的操作但风险是可以被前置动作压低的。我的习惯是任何 RAID 卡刷写前先做一轮信息收集把每一项输出保存到离线文件。别嫌繁琐掉电半分钟就能让你理解后悔药为什么要在事前准备。3.1 实测当前版本固件、驱动、管理工具一个都不能少先把现网状态摸清楚。SR130 在 Linux 下可以通过 storcli 工具查看这是 LSI/Avago 系的通用管理工具华为官方配套文档里也推荐用这种方式。如果系统里还没装 storcli需要先从厂商支持目录里获取与系统架构匹配的版本安装后建议用绝对路径执行避免 PATH 问题/opt/MegaRAID/storcli/storcli /c0 show # 输出里的 Firmware Package 一行即固件版本逻辑说明/c0表示第一个控制器多卡环境里依次为 /c1、/c2。show子命令输出控制器基本信息。看到Firmware Package 15.00.07.00说明目标已经达成如果看到更低版本继续往下走。参数说明有些场景下系统里存在多张 RAID 卡先执行storcli /call show看控制器列表再逐一指定。show命令不加额外参数时输出的是概要包含 FW Version、BIOS Version、Driver Version 三行关键信息。再确认内核里实际加载的驱动版本cat /sys/module/mpt3sas/version # 当前加载的 mpt3sas 驱动版本 modinfo mpt3sas | grep version # 内核模块文件自带的版本信息二者不一致时以实际加载为准逻辑说明/sys/module/mpt3sas/version是当前加载进内核的版本modinfo读取的是模块文件里的信息。如果系统重启后加载了旧模块文件前者可能比后者低。这个差异常常是升级完忘记重建 initramfs 导致的后面会细说。参数说明modinfo还可以带-F version只输出版本字段写进自动化脚本里更干净。注意在 chroot 环境或容器里执行时/sys/module对应的是宿主机内核状态不能代表目标服务器务必在物理机本机执行。3.2 备份 RAID 配置阵列降级的后悔药固件升级最怕的不是失败而是升级成功后控制器读取配置失败所有 VD虚拟磁盘变成 Foreign 状态盘上的数据像没发生过一样。虽然现在多数控制器支持从盘上重建配置但备份才是指数级降低事故概率的动作。用 storcli 把配置导出成文件/opt/MegaRAID/storcli/storcli /c0 show config /root/raid_config_before_upgrade.txt /opt/MegaRAID/storcli/storcli /c0 show event /root/raid_events_before_upgrade.txt # 第一行是完整配置导出第二行是控制器事件日志用于升级后对比异常逻辑说明配置文件导出的目的是留底。升级固件后如果 VD 状态异常可以通过对比配置文本判断是元数据丢失还是仅状态标记变化。事件日志同样重要控制器内部的事件记录在固件刷写后可能被清空。参数说明show config输出文本里包含每个 RAID 的级别、成员盘、热备盘、缓存策略。执行后务必用more或wc -l确认文件非空不要只凭命令返回码判断。有条件的场景建议再导出一份storcli /c0 /eall show all的磁盘级信息方便升级后核对盘位映射。3.3 判断系统里还有没有依赖 RAID 上数据的进程这一步很多人会漏。不是问有没有数据而是问升级操作期间会不会有进程读写。如果是数据库或容器存储目录挂在 RAID 卷上刷写过程 IO 可能短暂中断事务型应用会出现大量锁等待。我的做法是升级前用lsof D /mnt/raid_volume查一下打开的文件列表同时把业务侧维护窗口时间同步给相关的所有人。另外要检查系统是否配置了 multipath 多路径。如果同一块盘通过多路径软件暴露成了多个设备固件升级期间路径的切换可能会导致 dm-multipath 触发 failback 动作IO 路径在短时间内反复切换应用侧表现为慢但不报错。处理方式是在维护窗口内先暂停 multipath 的路径检查服务升级确认稳定后再恢复具体命令在 systemd 环境里是systemctl stop multipathd # 升级期间暂停路径健康检查避免刷写过程中误判掉线 systemctl start multipathd # 升级完成后恢复并观察日志是否有路径切换告警参数说明systemctl stop/start适用于几乎所有主流发行版。如果你用的是较老的 SysV init 系统对应命令是service multipathd stop和service multipathd start。这里不是让你默认禁用多路径而是把检查频率在关键操作期间降为不检查。4. Linux 下更新驱动从安装 RPM 到重建 initramfs 的完整路径把驱动装进系统不是简单地rpm -ivh就结束内核模块需要被加载、启动镜像要同步更新重启后才能生效。这一步是新手最容易忽略的因为装完 RPM 后系统不报错实际内核还在用旧模块等于没装过。4.1 安装驱动包的正确顺序华为这个 Update1 包在 Linux 侧通常以 RPM 形式提供驱动命名类似 kmod-mpt3sas。先确认当前内核版本与包要求的匹配度uname -r rpm -q kmod-mpt3sas # 若返回 not installed说明驱动走的是内核自带模块 rpm -Uvh kmod-mpt3sas-xxxx.rpm逻辑说明第一步查内核版本驱动 RPM 一般针对某个内核分支编译。第二步查是否已装过同名包如果系统原本用内核自带的 mpt3sasRPM 查询结果为未安装。第三步用-U升级或全新安装-Uvh中的 v 和 h 只是显示进度不影响行为。参数说明如果系统里已经存在旧版 kmod-mpt3sasrpm -Uvh会覆盖安装。这里不建议用--force除非你明确知道自己在处理残留文件冲突。RPM 安装失败时先看输出里的依赖冲突名单常见原因是内核版本与包的kernel-devel不匹配。4.2 重建 initramfs不重启就能让模块信息正确的唯一方式RPM 安装完成后模块文件已落到/lib/modules/$(uname -r)/extra/路径但当前运行的内核不会自动加载新文件。为了让重启后系统使用的是新驱动必须重建 initramfs。这里还有一个更隐蔽的点即使不重启某些操作也会因为模块文件被更新而产生异常重建 initramfs 是通用的兜底习惯。dracut -f /boot/initramfs-$(uname -r).img $(uname -r) # 强制重建当前内核的 initramfs模块更新后必须执行逻辑说明dracut是主流发行版生成 initramfs 的工具-f表示强制覆盖已有文件。命令最后的$(uname -r)指定内核版本号确保生成的是对应当前内核的镜像。生成的镜像文件里会写入 mpt3sas 模块路径重启时内核才能加载到新版本。参数说明在 Ubuntu/Debian 系系统里对应的命令是update-initramfs -u而不是 dracut。另外如果你的服务器启用了 Secure Bootinitramfs 重建后还要注意模块是否签名未签名模块在 Secure Boot 开启时会被拒绝加载现象是启动到存储初始化阶段卡住。此时要么进 BIOS 关闭 Secure Boot要么用厂商提供的签名驱动包。4.3 加载模块并验证版本衔接驱动装上后不重启的情况下可以手动卸载再加载模块让新驱动立即生效但这对生产系统不是好主意因为卸载模块会导致所有挂载在 RAID 卷上的文件系统瞬间失去后端设备。我的建议是modprobe -r mpt3sas # 仅建议在业务可停、无盘挂载的场景执行 modprobe mpt3sas逻辑说明这两条命令组合是让新驱动模块在当前内核里重载通常配合lsmod | grep mpt3sas确认。生产环境中卸载模块时如果系统根目录或数据盘挂载点依赖此设备内核会拒绝卸载并报Device or resource busy。与其折腾热重载不如直接在维护窗口内重启一次顺带验证 initramfs 是否重建正确。参数说明重启后第一时间执行dmesg | grep mpt3sas看启动日志里的版本号是否与预期一致。dmesg输出里会有一行mpt3sas_cm0: mpt3sas version xx.xx.xx.xx这是驱动加载成功的标志也是和 storcli 输出里 Driver Version 对账的依据。5. 固件刷写避坑从备份配置到掉电恢复的完整流程固件刷写这个环节里玄学成分最少但翻车后果最重。刷写工具选择、写保护开关、掉电防护、刷写失败后的恢复手段每一样都要提前想好。这一章我专门写避坑把所有踩过的坑按现象 → 原因 → 解决整理出来。5.1 刷写前的最后检查与刷写命令确认当前控制器没有进行中的 RAID 重建或一致性检查这一步用 storcli 就能看到/opt/MegaRAID/storcli/storcli /c0 show rebuild # 查看是否有后台任务运行输出里 rebuild 状态为 None 才安全确认无任务后在带外管理已连接、服务器处于维护窗口的前提下执行固件刷写。SR130 这类 LSI 系控制器常见方法是通过 storcli 的 download 子命令也可以使用厂商提供的专用刷写脚本逻辑一致/opt/MegaRAID/storcli/storcli /c0 download fileSR130_FW_15.00.07.00.rom # 将控制器固件写入 flash刷写过程通常持续 3~5 分钟逻辑说明download 子命令把 rom 文件写入控制器的 flash。命令执行后控制器在写入期间会短暂离线系统日志里出现控制器复位相关记录是正常现象。刷写完成后部分控制器会自动重启部分需要手动重启才能完成初始化。参数说明file参数后面的路径必须是控制器能读取到的文件系统路径建议放在/root下避免路径带空格。如果你的升级包里是 .bin 格式而非 .rom命令保持不变只改文件名。刷写过程中屏幕会打印进度百分比建议保持终端连接不要中断会话。5.2 避坑一刷写进度 100% 但版本没变现象命令执行完毕无报错storcli 查询版本还是旧版本。原因多数情况是控制器启动时加载的是备份固件分区HII 里叫 Backup Firmware主分区刷写成功但未激活少部分是 rom 文件与控制器型号不匹配被固件拒绝但状态码没有正确返回。解决重启一次服务器让控制器从主分区重新初始化。如果重启后仍未生效用 storcli 查询当前激活的固件分区再强制从备份分区刷写storcli /c0 download filexx.rom backup。如果还是不行检查 rom 文件的 MD5 是否与官方发布值一致文件传输损坏是常见坑。5.3 避坑二刷写完成后所有 VD 显示 Foreign现象重启后进入 OS逻辑盘全部消失storcli 显示Foreign状态盘在位但没有形成卷。原因固件升级过程中配置区域发生了偏移或校验方式改变控制器无法自动识别旧配置把盘上的 RAID 元数据标记为外部配置。绝大多数情况是元数据格式兼容问题不是数据丢失。解决先用storcli /c0 /fall show查看外来的配置确认盘序和 RAID 级别无异常然后执行导入操作storcli /c0 /fall import。导入完成后立即再次导出配置并对比升级前的文本重点核对每个 VD 的成员盘与容量。建议导入前拍下show config的截图导入失败时还可以用force参数重试但 force 会覆盖控制器上的配置务必在无其他 VD 的前提下使用。注意Foreign 状态不要一上来就点清除clear。清除操作是物理性的会把盘上的配置元数据标记为无效届时除了从备份重建外没有别的路可走。5.4 避坑三升级过程中断电控制器彻底失联现象刷写进行到一半断电恢复供电后系统无法识别 RAID 卡带外管理界面里 PCIe 设备列表都看不到它。原因固件写入 flash 的过程是整块擦除再写入断电时如果恰好处于擦除阶段固件引导区不完整控制器无法自举。这个状态叫变砖对 RAID 卡来说绝大多数不是硬件物理损坏而是引导区数据不完整。解决LSI 系控制器通常保留了串口刷写恢复模式需要把服务器断电通过短接卡上的特定跳线进入恢复模式再通过串口或专用工具把固件重新灌入。不过这属于机房现场操作普通运维环境里没有串口线往往会陷入僵局。最实际的防范手段是刷写前确认服务器接在 UPS 上远程管理口有独立供电机房断电告警有人能 5 分钟内响应。血的教训是不要在雷雨天气做固件升级也不要在园区停电倒闸的窗口期做。5.5 避坑四驱动和固件升级完成后系统盘启动失败现象固件和驱动都升完后重启服务器BIOS 自检能找到 RAID 卡但引导阶段报Boot Device Not Found。原因主板 BIOS 里的启动项还指向旧的引导条目固件升级导致设备路径或 PCIe 地址描述变化Boot Option 失效。不是盘上的系统坏了也不是 RAID 卷丢了。解决开机进 BIOS 设置找到 Boot Priority重新把启动项指向 RAID 卡上的逻辑盘或者直接选择 UEFI 自动检测。部分服务器平台上有单独的Boot Mode设置从 Legacy 切到 UEFI 或反过来都可能造成这个问题。升级固件前建议先把原启动模式记录下来刷写后优先还原原模式再考虑切换。6. 刷写后的三种验证方法与一条长期习惯升级结束不等于实施完验证环节至少覆盖三件事控制器视角能看到固件新版本并在持续工作系统 IO 路径上没有新增错误盘的健康数据能被正常读取。只跑一个storcli show就宣布升级完成后面会很被动。第一种验证控制器的状态以 storcli 为准。刷写完成后执行storcli /c0 show确认 Firmware Package 是目标版本同时看Status是否为OK、Boot Time是否为本轮重启时间。再执行storcli /c0 /cx show看每个 VD 的 State 是Optl还是Degraded后者说明盘序或成员盘有问题。第二种验证系统侧检查 dmesg 和磁盘错误计数。dmesg | grep -i mpt3sas\|scsi | tail -n 50 # 确认驱动加载版本和链路协商情况重点看有无 Failed 字样 cat /sys/block/sda/device/../../../../vendor cat /sys/block/sda/device/../../../../model # 确认系统识别到的盘与 RAID 配置里成员盘一致第三种验证用 fio 做一轮 5 分钟的读写压测观察延迟曲线。这一步不是为了测性能极限而是让新固件在加载态跑一遍真实 IO暴露潜在链路问题。命令参数上我习惯用--rwrandread加--rwrandwrite各跑一遍队列深度 32块大小 4k。一个额外的验证点是事件日志。升级前我导出了一份事件日志升级后在 storcli 里对比新增的事件条目如果出现USB或PDM相关的错误码序列说明控制器与盘之间在握手阶段有异常需要进一步排查盘固件版本。最后说一条我坚持了很多年的习惯每次 RAIDAID 卡升级我都会把升级包的版本号、适用型号、当前系统内核版本、驱动版本、刷写前后的 storcli 输出截图放到一个目录里以日期命名保存。下次遇到 IO 异常先在故障时间线里查这次升级记录排除是升级引发的连锁问题后再去排查应用层。这样处理问题的速度会快很多。顺带一提这套验证流程在我维护过的某跨平台系统的生产节点上反复跑过多次最有价值的就是那 5 分钟 fio——它比任何检测工具都能更快暴露新驱动的 IO 路径问题。希望你下次给 SR130 做升级时也能在维护窗口里留出这 5 分钟不要刷完固件就直接恢复业务。希望帮到你。本文还有配套的精品资源点击获取