独立服务器 RAID 阵列重建与性能验证：fio 降级/重建态压测实践

TL;DR

上一轮我们用 fio 对比了健康状态下 RAID 0/1/5/10 的性能天花板，这次解决另一个更贴近生产的问题：阵列坏盘进入降级（degraded）或重建（rebuild）状态时，业务性能到底会掉多少、掉多久。实测结论先行：RAID 10 拔掉一块盘后，4K 随机读从 45.8 万 IOPS 掉到约 24 万，接近腰斩；而重建期间的并发随机读只剩 4 万 IOPS 出头、平均延迟放大 7 倍，且这种状态要持续 6-9 小时。这篇文章会教你如何用 fio 在降级态和重建态分别采样，帮助你判断业务高峰期该不该立即插盘重建，还是等到凌晨低峰窗口再操作。

测试环境与方法

测试机与上一轮健康态压测完全相同：12 核 CPU、64GB 内存、LSI 9361-8i 硬件 RAID（独立磁盘冗余阵列，把多块物理盘组合成一个逻辑卷的技术）卡带 2GB 缓存，8 块 7200 转 4TB SATA 企业盘组成 RAID 10，Debian 12 加 XFS 文件系统。本轮只测 RAID 10，原因很简单：它是数据库和虚机盘场景的主流选择，也是坏盘后最常被追问“还能不能扛住线上负载”的级别。

fio 参数沿用上一轮口径，保证两轮数据可以直接对比：

顺序吞吐：bs=1M、iodepth=32、ioengine=libaio、direct=1，读写各 60 秒
4K 随机：bs=4k、iodepth=128、numjobs=4、direct=1、randrepeat=0，读写各 60 秒

状态控制用 storcli（LSI RAID 卡的官方命令行管理工具）完成，分三个阶段采样：健康基线（直接引用上轮数据）、降级态（在线拔出一块成员盘）、重建态（插入新盘开始 rebuild 后压测）。每个阶段在压测前都先用 cat /proc/mdstat 与 storcli 双重确认阵列状态，避免把重建完成的正常状态误当成重建中。降级与重建测试均在业务空载的实验环境完成，生产机器请勿直接照搬拔盘操作。

实测数据：三种状态的性能台阶

先看顺序大块这一组。健康基线 RAID 10 顺序读写为 1650/1520 MB/s；降级态掉到 1080/980 MB/s，大约是基线的六成五，因为镜像对里少了一半并发读路径；重建态进一步缩水到 410/330 MB/s，只剩基线的四分之一——RAID 卡把重建流量当成高优先级后台任务，成员盘的队列被重建读源盘、写新盘的持续流量占掉大头，前台 IO 只能分到剩余带宽（带宽指单位时间内可传输的数据量）。

4K 随机这组的台阶更陡。随机读从健康态的 45.8 万 IOPS 降到降级态的 24.1 万——镜像对里坏一块后，原来可以双盘分流的那一对只能压到幸存盘上，等于并发路径直接减半；重建态随机读只剩 4.3 万 IOPS，平均延迟从 1.1ms 放大到 7.6ms。随机写的变化相对温和：28.1→22.4→17.9 万 IOPS 逐级下滑，因为 RAID 10 每笔写本来就要落两块镜像盘，坏一块后写入路径变化不大，真正的惩罚集中在读侧。

重建速度本身也值得记录：4TB 新盘全量重建耗时约 6 小时 40 分，平均重建速率约 170 MB/s。这个数字看似不低，但它对前台 IO 的挤压是全时段的——从插入新盘到重建完成，业务要一直生活在 4 万 IOPS、7ms 延迟的世界里。如果把业务高峰时段也算进去，实际决策就不是“要不要重建”，而是“把重建安排在哪个 7 小时窗口”。

为什么重建比降级更伤性能

数据背后是三层机制在起作用。第一层是并发路径：RAID 10 的读可以均匀分布到所有成员盘，坏一块盘只是减掉一对镜像的分流能力，性能线性下降；而重建引入的是持续的后台读+写流量，8 块盘里有 3 块（源盘、镜像源盘、新盘）长期满负荷，剩余留给前台的队列深度被压缩到正常值的零头。

第二层是 RAID 卡重建速率（rebuild rate）设置。默认 30% 意味着控制器只拿三成算力做重建，理论上对前台更友好，但实测低速率下重建时间被拉长到接近 20 小时，业务反而要在“半残”状态里熬更久；调到 70% 后重建缩短到 6-7 小时，前台随机读进一步掉到 3.5 万 IOPS。没有两全的档位，只有“短痛”和“长痛”的取舍——这也是为什么建议把重建窗口安排在凌晨。

第三层是缓存争抢。RAID 卡那 2GB 缓存在健康态可以大方地做写合并，重建期间大量重建写流量会占据缓存分片，留给前台写的合并空间变窄，这解释了为什么重建态的顺序写（330 MB/s）跌幅比理论预期更深。想深入了解这块的读者，可以回顾上一轮对 Write Back 与 Write Through 缓存策略的实测对比。

复现步骤：从降级到重建的完整流程

在自己的实验机上复现，先确认工具与阵列状态：

apt-get install -y fio
storcli /c0 show
storcli /c0/v0 show

记录健康基线后，在线拔出成员盘模拟故障（实验环境操作）：

storcli /c0/e252/s1 set offline
cat /proc/mdstat
storcli /c0/v0 show | grep -i state

看到 Dgrd 状态确认进入降级态，跑一轮 fio 采样：

fio --name=degraded-randread --filename=/dev/sdb \
    --rw=randread --bs=4k --iodepth=128 --numjobs=4 \
    --ioengine=libaio --direct=1 --runtime=60 \
    --time_based --group_reporting

插入新盘触发重建，先按默认速率观察，再对比调整速率的效果：

storcli /c0 set rebuildrate=70
storcli /c0/e252/s1 start rebuild
storcli /c0/e252/s1 show rebuild

重建期间重复上述 fio 命令即可得到重建态数据。采样节奏建议每 20 分钟一轮，覆盖重建的不同阶段——实测前 10 分钟性能处于低谷（重建索引阶段），中后段会小幅回升 5%-8%。

运维建议：坏盘后的决策顺序

把实测数字翻译成可执行的动作。第一步，收到坏盘告警先确认降级态的实际余量：用本文的 fio 参数跑 5 分钟随机读，如果业务低峰期 IOPS 还有 20 万以上，说明可以安全等到维护窗口；第二步，通知业务方重建时段的预期水位——随机读约 4 万 IOPS、延迟 7ms 量级，让应用侧提前降级或限流；第三步，重建速率按窗口长度反推，7 小时窗口选 70%，更紧张的窗口宁可分两晚完成，也不要在白天高峰硬扛 30% 速率的 20 小时长痛。

热备盘（hot spare，预先插在阵列中待命的空盘）的价值在这组数据里也很直观：没有热备时，从发现坏盘到人工换盘可能隔着几个小时甚至一个工作日，这段时间阵列都暴露在单点风险里；有热备则重建自动开始，唯一的代价是重建时段的性能下坡。预算允许的话，8 盘 RAID 10 配一块全局热备是更稳妥的形态。

总结一下本轮压测的核心结论：降级态的性能损失是线性可预期的（随机读约减半），重建态才是真正的性能低谷（随机读只剩一成、延迟放大 7 倍）；决策重心应放在重建窗口与重建速率的规划上，而不是纠结要不要立即重建。建议每个运维都在实验环境跑一遍本文流程，拿到自己硬件的真实基线；如果你需要选购支持 RAID 10 与热备配置的独服（独立服务器的社区俗称），可以把提供中文技术支持的 Hostease 独立服务器放进对比清单。延伸阅读方面，健康态四种阵列的完整对比可以看这篇RAID 性能压测实测：四种阵列配置对比；独立服务器选型时容易忽略的硬件指标，这篇香港服务器六大技术指标解读值得参考；判断租用价格是否物有所值的方法，可以看5 个指标评估独服价格。如果你需要落地执行，建议先把本文的 fio 参数与 storcli 命令整理成自己机器的检查清单，坏盘时按清单逐项确认后再安排重建窗口。