开机上架一台新服务器，很多人第一件事就是插盘、装系统，等到业务跑起来才发现 IO 抖得厉害、重建一次要十几个小时，甚至阵列崩了数据拿不出来。问题往往不在系统层面，而在最底下那层——Linux服务器硬件选型与RAID配置这件事上。我这些年经手过几十台从 1U 到 4U 的机器，踩过的坑基本都集中在两处：一是盘和阵列卡的关系没理清，二是 RAID 参数按默认值一把梭。这篇就把整条链路拆开讲：从业务画像怎么反推硬件配置，RAID 级别怎么算容量和写惩罚，硬件阵列卡怎么用命令行建阵列，Linux 侧怎么落地文件系统和 LVM，软 RAID 什么时候该上，以及日常巡检和换盘重建的实操细节。适合刚接手服务器运维的朋友，也适合已经会装系统但没深究过阵列参数的老手——如果你曾经因为一个 WriteThrough 策略被业务方追着问“为什么半夜数据库卡了三分钟”，大概率能在这里找到答案。
1. 先把硬件这盘账算清楚：服务器选型与RAID的关系
1.1 从业务画像反推硬件配置
服务器硬件选型最忌讳的做法是先定预算再挑型号，正确的顺序是先画出业务的 IO 画像，再倒推硬件。我通常问三个问题：第一，读写比例大概是多少，是偏读的 Web 服务、偏写日志的采集服务，还是读写混掺的数据库；第二，IO 块大小什么量级，是 4K/8K 的小随机，还是 128K 以上的大顺序；第三，峰值 QPS 和可接受的尾延迟是多少。这三个答案基本决定了该配多少块盘、要不要上 NVMe、阵列卡缓存要多大。
举个我常拿来对照的例子：一台跑在线交易类业务的机器，典型特征是 8K 随机读写混掺、写占比 40% 以上、对 P99 延迟敏感。这种场景我会优先考虑 8 块以上 SSD 做 RAID10，而不是 12 块大盘做 RAID5——原因在后面讲写惩罚时会详细算，简单说就是 RAID5 每次逻辑写要放大成 4 次物理 IO，在小随机写入下这个放大直接吃掉 SSD 的 IOPS 优势。反过来，如果是对象存储的冷数据节点、视频归档、备份落地盘，特征是超大文件顺序写、读少写多、对延迟不敏感，那 12 块大容量 SATA 做 RAID6 加一块全局热备，性价比就高得多。
这里有个容易被忽略的点：硬盘数量不是越多越好。单台机器盘位受背板和机箱限制，而阵列卡本身也有通道数和 PCIe 带宽上限。一台 2U 12 盘位的机器塞满 12 块 SAS SSD，理论带宽早就顶到 PCIe 3.0 x8 的天花板了，再加盘也只是增加 IOPS 不增加吞吐。所以选型时我会先算一遍理论带宽总和，跟阵列卡和主板 PCIe 通道对一下账，避免买回来发现瓶颈在卡上。
1.2 硬盘、背板与阵列卡的三角关系
很多人以为硬盘插上去就归操作系统管，实际上中间隔着背板、线缆、阵列卡（或者直通的 HBA）三道关。这三者里任何一个环节降级，整条链路都会跟着降级。我见过最典型的情况是：机器配了 SAS 3.0 的盘和 12Gb 的阵列卡，但背板是上一代的 6Gb 扩展背板，结果全部盘协商在 6Gb 速率上，顺序读性能只有标称的一半多。
判断方法不复杂，装好系统后看/sys/class/sas_device/或者阵列卡的物理设备信息，关注协商速率（Negotiated Link Speed）和设备状态（Status）。如果发现某块盘协商速率低于同批其他盘，先别急着判定坏盘，优先怀疑线缆、背板插槽或者盘位接触问题——把盘和好盘对调位置，再观察速率是否跟着盘走，是盘的问题还是槽位的问题一次就能分清。
阵列卡这块要区分两种工作模式：RAID 模式和 HBA/直通模式。前者由卡上的处理器和缓存接管所有磁盘，操作系统只看到一个逻辑卷；后者把物理盘直接透给系统，由软件层（mdadm、ZFS、LVM）自己组阵列。这两种模式不能混着理解，也不能指望同一块卡随时切换还保持数据——切换模式基本等于清空配置。选哪种取决于业务：追求稳定、运维简单、有电池或超级电容保护的，走硬件 RAID；要用 ZFS、要跑分布式存储、需要系统直接感知单盘健康的，走 HBA 直通。
1.3 内存、CPU与IO路径的配合
硬件配置里最容易被低估的是内存和 CPU 对 IO 路径的影响。阵列卡缓存是硬件层面的写缓冲，内存是文件系统层面的页缓存，两者不是替代关系。我遇到过一台机器，阵列卡配了 4GB 缓存但 WriteBack 没开，全靠 Linux 页缓存顶着，结果一跑大文件顺序写就把脏页比例顶到上限，内核开始周期性回写，业务侧表现为每隔几秒卡一下。这类问题的根因不在盘上，而在缓存策略没对齐。
CPU 的影响主要在中断和软中断上。万兆网卡加高 IOPS 的 NVMe，中断打满一个核是很常见的事。排查时看mpstat -P ALL 1里 %soft 那一列，如果某个核的软中断长期超过 30%，就要考虑调整中断亲和性，把网卡和存储控制器的中断分散到不同物理核上，配合 NUMA 节点绑核。这一步在小机器上感知不明显，但在 2 路以上、盘多的机器上是实打实的差距。
另外提醒一个采购细节：别在同一台机器上混用不同批次、不同固件版本的盘。同一 RAID 组里盘的固件不一致，重建行为和错误处理策略可能有差异，出问题时排查起来非常痛苦。我现在的做法是新机器到货后先统一刷一遍固件，把这个变量提前消掉。
2. RAID级别怎么选：不是越高越好
2.1 常见RAID级别对照与容量性能计算
RAID 级别选型的核心就三件事：能容忍几块盘同时坏、可用容量是多少、写性能损失多大。这三者天然互相制约，没有全都占的方案。我把常用的几个级别整理成一张表，容量按单盘 4TB 计算，方便直接对照。
| 级别 | 最少盘数 | 容错能力 | 可用容量（8×4TB） | 写惩罚 | 典型读性能 | 典型写性能 |
|---|---|---|---|---|---|---|
| RAID0 | 2 | 0 块 | 32TB | 1 | 最高 | 最高 |
| RAID1 | 2 | 1 块 | 4TB（每组） | 2 | 高 | 中 |
| RAID5 | 3 | 1 块 | 28TB | 4 | 高 | 中偏低 |
| RAID6 | 4 | 2 块 | 24TB | 6 | 高 | 低 |
| RAID10 | 4 | 每组 1 块 | 16TB | 2 | 最高 | 高 |
| RAID50 | 6 | 每组 1 块 | 24TB | 4 | 高 | 中 |
| RAID60 | 8 | 每组 2 块 | 16TB | 6 | 高 | 中偏低 |
容量公式要记牢：RAID5 是 (N-1)×单盘容量，RAID6 是 (N-2)×单盘容量，RAID10 是 N/2×单盘容量，RAID50/60 则是先按子组算再累加。注意这里的“单盘容量”要用厂商标称容量换算后的实际可用值，一块标称 4TB 的盘在系统里大概是 3.64TiB，做容量规划时按 3.6TiB 估比较稳妥，别按 4 算完发现差了一截。
写惩罚的计算逻辑值得单独说一下，因为它直接解释了很多“为什么我的阵列写不上去”的疑问。RAID5 的一次逻辑写，控制器要经历：读旧数据、读旧校验、写新数据、写新校验，共 4 次物理 IO；RAID6 因为有两份校验，变成 6 次；RAID10 是镜像，一次逻辑写落两块盘，算 2 次；RAID0 无校验无镜像，1 次。所以同样 8 块盘，RAID5 的有效写 IOPS 大约是裸盘总和的四分之一，RAID10 则是二分之一。在随机小写上，这个差距非常明显。
2.2 重建时间与不可恢复读错误的现实算法
选 RAID5 还是 RAID6，很多人纠结的点是“RAID5 已经能容一块盘了，够不够”。这个问题不能只看容错数量，要看重建窗口内的风险。重建是把一块盘的完整数据读出来重新算校验写到新盘上，这个过程对阵列是全盘扫描级别的压力。
先算重建时间。以一块 4TB 的 7200 转 SATA 盘为例，顺序读速度在理想状态下大概 150MB/s 到 180MB/s，取中间值 160MB/s，理论上限是 4×1024×1024MB ÷ 160MB/s ≈ 26214 秒，也就是 7.3 小时左右。但实际生产环境不会给你满带宽，重建时还要服务业务 IO，控制器通常会限速，实际耗时往往是 12 到 24 小时，盘越大、负载越重，时间越长。8TB、12TB 的盘，重建一天以上是常态。
再看风险。机械盘的不可恢复读错误率（URE）标称值常见是 10^14 比特，换算下来大约每读取 12.5TB 数据就可能撞上一次无法纠正的读错误。一次 4TB 盘的重建要读 4TB 数据，按这个错误率估算，撞上读错误的概率在三成上下。这个数字不是危言耸听，它意味着：RAID5 在单盘故障后的重建过程中，有一定概率再撞上一块盘的读错误，直接导致阵列失效。RAID6 因为有双校验，能扛住重建期间的第二个错误，这就是它在盘容量越来越大之后成为主流的根本原因。
我的实操判断标准是这样的：单盘容量 2TB 以下、盘数不超过 8 块、数据可重建的场合，RAID5 仍可用；单盘 4TB 以上、或者数据不可重建（没有可靠备份）、或者盘数超过 8 块，一律上 RAID6 或 RAID10。这条线不是拍脑袋，是按上面的重建时间和 URE 概率算出来的。
2.3 业务场景到RAID级别的映射
把上面这些计算落到具体场景，我一般按下面这张表来做初步决策，再根据预算微调。
| 业务场景 | IO 特征 | 推荐级别 | 理由 |
|---|---|---|---|
| 关系型数据库主库 | 8K-16K 随机读写，写占比高 | RAID10 | 写惩罚低，重建快，延迟可预期 |
| 日志/时序数据写入 | 顺序追加为主，写多读少 | RAID6 + 热备 | 容量利用率高，双校验抗重建风险 |
| 静态资源/图片服务 | 大文件顺序读为主 | RAID5 或 RAID6 | 读性能足够，容量优先 |
| 虚拟化宿主机 | 混合随机，IOPS 敏感 | RAID10 | 多虚拟机并发，需要稳定 IOPS |
| 备份落地盘 | 超大文件顺序写 | RAID6 或 RAID0+上层副本 | 容量优先，可靠性由上层保证 |
| 编译/临时计算节点 | 短时高并发，数据可丢弃 | RAID0 或单盘 | 追求吞吐，不做冗余 |
有个反直觉的点：不是所有盘都必须进阵列。系统盘和业务数据盘我向来是分开的。系统盘用两块小容量盘做 RAID1，业务盘按上面表格走。这样做的好处是系统盘的重建和维护完全不影响业务 IO，也避免了“系统装在大阵列里，一不小心把数据盘一起重建了”这种事故。另外，日志盘如果能单独用两块 NVMe 做 RAID1，对数据库类业务的写入延迟改善非常直接。
3. 硬件RAID实操：从上电前检查到阵列建好
3.1 上电前的物理检查与固件统一
机器到手别急着装系统，先做三件事。第一，把背板、线缆、盘位的连接状态过一遍，尤其是 4U 机器有多级扩展背板的，扩展线没插紧导致的掉盘问题我在现场遇到过不止一次。第二，进 BIOS/UEFI 确认启动模式、阵列卡的工作模式（RAID 还是 HBA）、以及是否开启了从阵列卡引导。第三，统一固件版本，包括 BIOS、阵列卡固件、硬盘固件，三者的兼容性表在厂商支持页面能查到，按表对齐能省掉后面很多莫名其妙的掉盘。
固件更新这一步我要强调一下顺序：先升 BIOS，再升阵列卡，最后升硬盘。原因是新版阵列卡固件可能依赖新版 BIOS 的某些接口，反过来做容易卡在中间状态。升级过程中绝对不要断电，也不要并行升级多块盘——一次一块，升完重启确认状态正常再升下一块。我见过有人为了省时间批量刷盘固件，中途一块盘刷失败变成砖，整个阵列组不起来，只能整组重建。
3.2 用命令行工具建阵列
图形化的阵列卡管理界面看着直观，但批量操作和远程操作都不方便，我更倾向用厂商提供的 CLI 工具。各家命令前缀不同，下面以常见的 storcli 风格举例，参数含义是通用的，换成你手上的工具对照文档调整即可。
先看整体状态，确认卡、物理盘、逻辑盘都在：
# 查看控制器概要 storcli /c0 show # 查看所有物理盘状态，重点看 State 和 DG storcli /c0/eall/sall show # 查看已有逻辑盘 storcli /c0/vall show物理盘状态里，UGood表示未配置可用，Onln表示已上线，Rebuild表示正在重建，Failed表示已故障。如果新盘显示UGood但容量识别异常，先查storcli /c0/eall/sall show all里的Device Speed和Media Error Count。
建 RAID6 阵列的典型命令：
# 8块盘建RAID6，条带256K，写策略WriteBack，读策略ReadAhead storcli /c0 add vd type=raid6 drives=252:0-7 \ strip=256 pdcache=on wb ra direct # 建完确认 storcli /c0/vall show这里的drives=252:0-7是“机柜号:槽位号”的写法，实际填你eall/sall show里看到的 Enclosure 和 Slot 值。strip=256是条带大小，单位 KB。pdcache=on开启盘缓存，wb是 WriteBack，ra是 ReadAhead，direct表示不经过控制器缓存直接写盘（一般建完阵列会改成cached，具体下面讲）。
建阵列时有几个参数必须显式指定，不要依赖默认值：条带大小、写策略、读策略、初始化方式。初始化分快速初始化和完整初始化，快速初始化只写元数据，几秒到几分钟完成；完整初始化会把整个阵列写零，几 TB 的阵列要跑几个小时到十几小时。新阵列一定要做完整初始化，原因是快速初始化后盘上可能残留旧的校验数据，一旦触发一致性检查会把残留数据当成有效校验，轻则报不一致，重则误判坏盘。完整初始化虽然慢，但它同时是一次全盘健康巡检，能把有隐患的盘提前暴露出来。
3.3 阵列参数：条带、读写策略、缓存与电池
条带大小的选择逻辑是按业务的 IO 块大小来匹配。原则是：条带大小要大于等于业务的平均 IO 块大小，让一次 IO 尽量落在单个盘上，避免跨盘放大。数据库类小随机 IO，条带设 64K 到 256K；文件服务、备份归档这类大顺序 IO，条带设 512K 到 1M。设小了会导致一次大 IO 被拆到多块盘，控制器要拼装；设大了会让小 IO 在每块盘上只用到一小部分，浪费带宽。
写策略和电池的关系是这套配置里最容易埋雷的地方。WriteBack 的性能明显好于 WriteThrough，但前提是缓存里的数据在断电时不会丢——这就依赖阵列卡上的电池（BBU）或超级电容。如果电池失效、正在学习周期、或者根本没装，控制器会自动把策略降到 WriteThrough，性能会掉一个台阶，而且降级过程是自动的，业务侧只感觉“变慢了”，不一定会报错。
注意：带电池的阵列卡每隔一段时间会做一次电池学习（learn cycle），期间写策略临时降为 WriteThrough。如果你发现业务性能每隔几周就出现一次规律性下滑，先去查电池学习状态，别急着怀疑盘。超级电容方案没有这个问题，但电容寿命有限，通常三年左右需要更换。
相关的检查命令：
# 查看电池/电容状态，重点看 State 和 Learn Cycle storcli /c0/bbu show all # 手动触发一次电池学习（谨慎，会短时降级） storcli /c0/bbu start learn # 查看当前逻辑盘的写策略是否被降级 storcli /c0/vall show all | grep -i "write policy"还有一个参数经常被忽略：Patrol Read（巡检读）和一致性检查（CC）的调度。巡检读是控制器主动扫描盘面，提前发现坏块；一致性检查是校验 RAID5/6 的校验数据是否一致。这两个动作都会占用 IO 带宽，默认通常是自动调度，我一般会把它们手动挪到业务低峰，并且限制速率。命令示例如下：
# 设置巡检读在每天凌晨2点到6点执行，速率限制30% storcli /c0 set patrolread starttime=02:00 duration=4 maxconcurrentpd=1 # 手动启动一致性检查并限速 storcli /c0/v0 start cc storcli /c0 set ccrate=304. Linux侧落地：从块设备到可用文件系统
4.1 识别设备与分区对齐
阵列建好后，Linux 侧看到的是一块逻辑盘，通常是/dev/sdb这样的设备名，或者走 NVMe 的/dev/nvme0n1。设备名不稳定，做任何持久化配置前先拿到 WWN 或 UUID：
# 查看块设备拓扑，确认容量和类型 lsblk -o NAME,SIZE,TYPE,MODEL,ROTA # 获取设备的 WWN，用于 udev 规则或持久化识别 lsblk -o NAME,WWN,SERIAL # 查看文件系统 UUID blkid /dev/sdb1分区对齐这件事，现代工具基本不用手动操心。parted默认从 1MiB 开始，fdisk新版也已默认按 2048 扇区对齐，跟 4K 物理扇区和常见 RAID 条带都能对上。但如果你的机器上还留着老脚本用fdisk的旧行为，或者用dd做过分区表恢复，就有必要验证一下。检查方法是看分区的起始扇区能否被 2048 整除：
# 查看分区起始扇区，Start 列能被 2048 整除即为对齐 parted /dev/sdb unit s print没对齐的后果是每个 IO 都要跨两个物理页，读写性能损失在小随机场景下能到 20% 以上。修正方法只有重建分区表，所以这一步要在业务上线前做完。
另外一个我个人强烈的习惯：整盘做 PV，不要先分区再做 PV。LVM 直接建在整块盘上，少了分区表这一层，扩容和管理都简单，也不会有分区表损坏导致整盘不可读的风险。只有当这台机器需要和其他系统共存、或者需要保留特定的分区布局时，才做分区。
4.2 文件系统选型与挂载参数
Linux 上主流就三个选择：ext4、XFS、以及各种新式文件系统。我的取舍很直接：需要在线缩容的用 ext4，其余几乎一律 XFS。XFS 在大文件、大目录、高并发写入上的表现更稳，元数据操作的开销更低，而且它天然支持在线扩容。代价是不能缩容，所以规划容量时要留足余量。
格式化和挂载的具体参数：
# XFS 格式化，条带参数与 RAID 条带对齐 mkfs.xfs -f -d su=256k,sw=8 -l size=128m /dev/sdb # ext4 格式化，指定条带宽度 mkfs.ext4 -E stride=64,stripe-width=512 /dev/sdbsu是条带单元大小，要和阵列卡上设的条带一致；sw是条带数量，RAID6 的 8 盘组数据盘是 6 块，所以sw应该填 6，上面的 8 是举例，实际按你的阵列算。这个参数如果填错，XFS 在分配大块时会对不齐，顺序写性能会打折扣。写错了也没法在线改，只能备份重格式化，所以建议建完阵列先确认一遍。
挂载参数上，我常用的组合是：
# /etc/fstab 中的挂载条目，用 UUID 而非设备名 UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs \ defaults,noatime,nodiratime,logbsize=256k,largeio,inode64,swalloc 0 0noatime和nodiratime关掉访问时间更新，能省掉大量元数据写，对写密集型业务尤其明显。largeio让大块 IO 走更优的分配路径，inode64允许 inode 分布在整个文件系统而不是挤在开头，swalloc让条带分配更贴合底层阵列。这些都是针对 RAID 后端的调优项，单盘场景收益不大。
4.3 LVM叠加与扩容路径
LVM 的价值在于给未来留了操作空间。我的常规布局是：底层一块或多块 RAID 逻辑盘做 PV，上面建一个 VG，按业务切 LV。这样后续要么加盘扩 VG，要么扩已有 LV，都不用停机迁移数据。
# 创建 PV、VG、LV pvcreate /dev/sdb vgcreate vg_data /dev/sdb lvcreate -l 100%FREE -n lv_app vg_data # 格式化并挂载 mkfs.xfs /dev/vg_data/lv_app mkdir -p /data mount /dev/vg_data/lv_app /data扩容分两种路径，操作完全不同，别搞混。第一种是底层阵列扩容：在阵列卡上给逻辑盘加盘，然后让 Linux 重新识别设备容量。这一步的关键是内核要能感知块设备变大，rescan-scsi-bus.sh或者对 SCSI 设备写/sys/class/scsi_device/*/device/rescan都能触发。设备容量变了之后，pvresize /dev/sdb，然后lvextend，最后 XFS 用xfs_growfs在线扩，全程不用卸载。
第二种是直接加新盘到 VG：新建 PV、vgextend、lvextend，再扩文件系统。这条路更安全，我通常优先选它，因为它不依赖阵列卡在线扩容的兼容性，也不会因为一次扩容失败影响原有数据。
提示：XFS 的
xfs_growfs必须挂载状态执行，参数是挂载点不是设备名，写成/dev/xxx会报错。ext4 则是resize2fs加设备名。这两个命令的参数形式不同，混用是新手最常见的失误之一。
5. 软RAID（mdadm）适用场景与实操
5.1 什么时候该用mdadm而不是硬件RAID
硬件 RAID 稳定、对系统透明、有缓存加速，但不是所有场合都合适。我在这几种情况下会选 mdadm：一是阵列卡只能用 HBA 直通模式，而业务又需要冗余；二是要用 ZFS 或某些分布式存储，它们需要直接管理物理盘，只能在上层自己做冗余；三是预算受限的测试环境，用普通 SATA 控制器加 mdadm 就能搭出可用的冗余盘；四是一些特殊拓扑，比如需要把 SSD 做缓存盘、HDD 做容量盘的分层结构。
mdadm 的短板也要说清楚：它没有硬件缓存的写保护，WriteBack 只能靠文件系统和日志保证一致性，掉电风险比硬件 RAID 高；重建是纯 CPU 参与的，重建期间对 CPU 和 IO 的压力都更大；而且它依赖操作系统，换机器或者系统起不来的时候，数据恢复的路径更复杂。所以生产环境的核心数据库，我仍然优先硬件 RAID，mdadm 用在可重建、可降级、有备份兜底的场景。
5.2 mdadm建阵列与配置持久化
以 4 块盘建 RAID10 为例，完整流程如下：
# 安装工具 apt install -y mdadm # Debian/Ubuntu 系 # yum install -y mdadm # RHEL/CentOS 系 # 建 RAID10，4块盘，条带64K mdadm --create /dev/md0 --level=10 --raid-devices=4 \ --chunk=64 /dev/sdc /dev/sdd /dev/sde /dev/sdf # 查看构建进度 cat /proc/mdstat mdadm --detail /dev/md0/proc/mdstat里的[UUUU]表示四块盘全部在线，[U_UU]表示第二块盘缺失。构建过程中会显示resync进度和预估时间，几 TB 的盘一般要跑几个小时，期间可以正常使用，但性能会下降。
持久化配置是 mdadm 最容易出问题的地方。阵列信息写在盘的超级块里，但开机自动组装依赖/etc/mdadm/mdadm.conf（Debian 系）或/etc/mdadm.conf（RHEL 系）：
# 生成配置文件 mdadm --detail --scan >> /etc/mdadm/mdadm.conf # 更新 initramfs，确保开机时能识别阵列 update-initramfs -u # Debian/Ubuntu # dracut -f # RHEL/CentOS漏掉更新 initramfs 这一步，重启后阵列可能组装不起来，系统进入紧急模式。这个坑我踩过一次，症状是开机后/dev/md0不存在，但盘都在，手动mdadm --assemble --scan又能起来。原因就是 initramfs 里的配置还是旧的。所以每次改动阵列结构，都要重新执行这两步。
软 RAID 的巡检靠两个命令：cat /proc/mdstat看整体状态，mdadm --detail /dev/md0看每块盘的角色和错误计数。另外建议配一个定期的一致性检查任务，放在 crontab 里，每月跑一次：
# 每月1日凌晨3点做一次数据一致性校验 0 3 1 * * /usr/share/mdadm/checkarray --cron --all --quiet6. 监控、巡检与故障排查实录
6.1 日常巡检该盯哪几个指标
巡检不是把所有命令跑一遍，而是盯几个关键指标的变化趋势。硬件 RAID 侧我关注四类：物理盘状态是否全部Onln、有没有Failed或Rebuild、介质错误计数（Media Error）和预测性故障计数（Predictive Failure）是否在增长、电池状态是否正常。其中介质错误计数是最有价值的早期信号——它增长说明盘面开始出现弱扇区，还没到坏的程度，但已经在路上了。我的经验阈值是单盘介质错误超过 10 且持续增长，就安排计划性更换，别等它变成Failed。
Linux 侧的巡检重点是 IO 队列和延迟，而不是单纯的 IOPS。我常用的组合是iostat -x 1看await和%util，sar -d看历史趋势，ioping测实际延迟。判断标准：如果是机械盘阵列，await超过 50ms 就说明有排队，超过 100ms 业务侧大概率能感知；SSD 阵列的await应该长期在个位数毫秒，超过 20ms 就要查原因。
下面这个巡检脚本可以直接放到 crontab 里，输出收集到日志再统一看：
#!/bin/bash # raid_health_check.sh - 硬件RAID与系统IO巡检 LOG=/var/log/raid_check.log DATE=$(date '+%Y-%m-%d %H:%M:%S') echo "===== $DATE =====" >> $LOG # 1. 阵列卡整体状态 storcli /c0 show | grep -Ei "Controller Status|Degraded|Failed" >> $LOG # 2. 物理盘异常项 storcli /c0/eall/sall show | awk '$0 ~ /Failed|UBad|Rebuild/ {print}' >> $LOG # 3. 逻辑盘状态 storcli /c0/vall show | grep -Ei "Degraded|Optimal|Offline" >> $LOG # 4. 介质错误计数非零的盘 storcli /c0/eall/sall show all | grep -B2 -A2 "Media Error Count" \ | awk '/Media Error Count/ && $NF > 0 {print}' >> $LOG # 5. 系统盘 IO 延迟 iostat -x 1 2 | awk '/^(sd|nvme)/ && $NF > 50 {print}' >> $LOG脚本本身不复杂，关键是把“异常”定义清楚，让日志里只有需要看的东西。全量输出丢进日志，等于没人看。
6.2 典型故障速查
下面这张表是我这些年遇到过的高频问题，按现象归档，方便出问题时快速定位。
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 阵列显示 Degraded | 单盘故障或掉线 | 查物理盘 State，Failed 则换盘；Offline 先查线缆和背板 |
| 写性能突然减半 | 电池学习周期，写策略降为 WriteThrough | 查 BBU 状态与学习进度，业务低峰期可忽略 |
| 重建进度卡住不动 | 目标盘有坏块或速率协商异常 | 查重建盘 Media Error，必要时换盘重试 |
| 系统盘识别不到阵列 | initramfs 未更新或阵列卡引导顺序错 | 重做 initramfs，检查 BIOS 启动项 |
| 单盘频繁掉线 | 线缆、背板插槽或固件不匹配 | 对调盘位验证，统一固件版本 |
| 顺序写跑不满带宽 | 条带与文件系统条带参数不匹配 | 核对 mkfs 的 su/sw 与阵列 strip 是否一致 |
| 深夜规律性卡顿 | 巡检读、一致性检查或备份任务撞车 | 调整调度时间，限制任务速率 |
| 扩容后容量没变 | 内核未重新扫描块设备 | 执行 rescan 或重启，再跑 pvresize |
表里最后一条我单独说一下。给阵列卡上的逻辑盘加盘后，Linux 侧看到的/dev/sdb容量不会自动更新，必须主动触发扫描。SCSI 设备可以这样处理：
# 触发 SCSI 设备重新扫描 for host in /sys/class/scsi_host/host*/scan; do echo "- - -" > $host done # 或者对具体设备 rescan echo 1 > /sys/class/block/sdb/device/rescan # 确认容量变化 lsblk /dev/sdb扫描完容量变大，再依次pvresize、lvextend、xfs_growfs。这三步顺序不能乱，跳步会直接报错。
6.3 换盘与重建的实操注意事项
换盘这个动作看着简单，实际有几个细节决定成败。第一步是精确定位。别靠“从左数第三块”这种描述，用阵列卡的点灯功能把目标盘位的指示灯闪起来，现场确认无误再动手：
# 点亮指定槽位，确认位置后关闭 storcli /c0/e252/s3 start locate storcli /c0/e252/s3 stop locate第二步，确认是热插拔还是需要停机。SAS 盘和大部分 SATA 盘在支持热插拔的背板上可以直接拔插，但前提是背板和阵列卡都支持，而且阵列卡工作在 RAID 模式下。如果不确定，宁可停机。拔盘前先在工具里把盘标记为 Offline 或者 Missing，让控制器知道这块盘要走了，避免它还在往这块盘上写数据。
第三步，新盘插上去之后不要急着走开。控制器通常会自动开始重建，但有些型号需要手动指定热备或者手动触发。重建开始后观察前 5% 的进度，确认速率正常（一般每小时 3% 到 8%，取决于盘容量和负载），再离开。我遇到过一次新盘插上去没自动重建，原因是这块盘的固件版本和老盘不一致，控制器把它标记成了不支持的状态，手动改成全局热备才认。
重建期间有几件事绝对不要做：不要在同一个阵列上再跑一致性检查或巡检读，不要做大规模的顺序写压测，不要在重建没完成时再拔第二块盘。最后这条听起来像废话，但真有人为了“一次换完省事”同时拔两块，RAID5 直接失效。
7. 性能验证：建完之后先压一遍再上线
7.1 fio压测的实际用法
阵列配完、系统装完，我坚持做一次压测再交付。目的不是刷跑分，而是确认这组配置的实际表现和预期一致，顺便暴露隐藏问题。工具用 fio，几个关键参数的含义要先搞清：bs是块大小，iodepth是队列深度，numjobs是并发数，rw是读写模式，direct=1绕过页缓存看真实磁盘性能。
# 随机读，4K，队列深度32，4并发，跑60秒 fio -name=randread -filename=/dev/sdb -direct=1 -rw=randread \ -bs=4k -iodepth=32 -numjobs=4 -runtime=60 -group_reporting # 随机写，同样的参数 fio -name=randwrite -filename=/dev/sdb -direct=1 -rw=randwrite \ -bs=4k -iodepth=32 -numjobs=4 -runtime=60 -group_reporting # 顺序读，1M块 fio -name=seqread -filename=/dev/sdb -direct=1 -rw=read \ -bs=1m -iodepth=16 -numjobs=2 -runtime=60 -group_reporting注意filename直接指向裸设备会破坏数据，只能在空盘或者刚建好还没上业务的阵列上跑。已有数据的盘要改成指向一个测试文件，并加-size限制大小。
7.2 结果怎么读才有意义
fio 的输出里，我最关注的是iops、bw、以及clat的 p99 和 p99.9。平均值会骗人，尾延迟才反映业务真实体验。一组 4K 随机写在 RAID10 上的典型表现，8 块 SATA SSD 大概能跑到两万到四万 IOPS，p99 延迟在几毫秒；同样配置 RAID6 的随机写 IOPS 会掉到几千到一万出头，p99 延迟明显抬高。如果你的测试结果远低于这个数量级，先排查三个地方：写策略是不是被降级成 WriteThrough、条带参数和文件系统是否对齐、队列深度是否设得太小导致测不出真实能力。
顺序读写看带宽能不能接近理论值。8 块 SAS HDD 做 RAID6，顺序读跑满到 1.5GB/s 到 2GB/s 是正常区间；如果只有几百 MB/s，多半是条带设置或者背板速率协商的问题，回头查Device Speed。
压测完成后记得清理测试数据、恢复写策略，再交付。我见过有人压测完忘了把阵列从 WriteThrough 改回 WriteBack，业务上线后一直觉得“这台机器怎么比老的慢”，查了两天才发现是压测时手动改了策略没改回来。
8. 我个人在这套流程里的几个固定动作
配置这件事做久了会形成肌肉记忆，我这边有几个不看文档也要做的固定动作，分享出来供参考。
新机器到货，先统一固件再做任何配置，这一条我已经坚持很多年。固件不一致带来的问题最难排查，因为它不在任何一份配置文档里，也不在任何一条报错信息里，只会在某个特定负载下突然出现。把变量提前消掉，后面省下的是几倍的时间。
阵列建完，一定做完整初始化、一定跑一遍 fio、一定把批处理脚本放到 crontab 里。这三个动作加起来不超过半天，但它把“这台机器能不能用、用起来大概什么水平、出问题会不会有人知道”三件事一次性回答了。
最后一个小技巧：给每台机器的阵列配置、文件系统参数、压测结果单独存一份记录，跟着机器编号一起归档。半年后你回头查“这台机器的条带设的多少、当时为什么这么选”，有记录和没记录完全是两种体验。我现在的做法是建完阵列就把storcli /c0 show all和storcli /c0/vall show all的输出直接导出存一份，文件名叫机器编号加日期，成本几秒钟，价值在一年后体现。
