服务器在长期运行中，存储需求增长是必然的。当原有RAID阵列空间不足，或当前RAID级别无法提供足够冗余时，传统做法需要停机重做阵列，这意味着业务中断数小时甚至更久。现代硬件RAID控制器和Linux软RAID均支持在线扩容与级别迁移，核心思路是在阵列保持挂载和可读写的状态下，逐步重构数据分布。本文以常见场景为例，说明如何在不关机、不卸载生产数据的前提下完成RAID容量扩展与级别变更。
在线扩容与级别迁移的底层原理
在线扩容依赖控制器的多步重构能力。以硬件RAID卡为例，当插入新磁盘后，控制器会在后台将新盘加入阵列，并按新的条带布局重新计算奇偶校验或镜像关系。这个过程对操作系统表现为逻辑卷容量变大，但底层数据块的实际分布被逐步迁移。业务进程的读写请求仍被正常响应，只是部分I/O会因重构而延迟略微上升。
RAID级别迁移比单纯扩容更复杂。例如从RAID 1迁移到RAID 5，需要将镜像结构改为带奇偶校验的条带结构；从RAID 5迁移到RAID 6，则要增加第二份校验数据。控制器必须在保留旧数据的同时计算出新增的校验块，因此迁移时间通常数倍于普通扩容。理解这一点，才能合理规划维护窗口与监控策略。
软RAID（如Linux mdadm）的实现逻辑类似，但由CPU承担校验计算。其优势是透明度高，管理员可用监控文件查看重构进度；劣势是迁移时CPU占用明显，需评估业务负载是否容忍。无论硬件还是软件方案，无停机的前提都是：电源冗余正常、备份可用、阵列当前状态健康。
操作前的必要检查与准备
任何在线操作前，先确认阵列状态无降级或坏盘。硬件RAID可通过厂商管理工具（如MegaCLI、storcli）查看；Linux软RAID可读取 /proc/mdstat 内容。若已有磁盘故障，必须先替换并同步完成，否则迁移中再失效将直接引发数据丢失。同时核对控制器固件版本，部分老旧固件不支持跨级别迁移，仅允许同级别扩容。
备份是最后防线。虽然在线操作理论安全，但意外断电、控制器bug仍可能造成元数据损坏。建议将关键数据同步到异地存储，并记录当前分区表与文件系统类型。另外，准备一台带带外管理（如iDRAC、IPMI）的终端，确保网络中断时仍能操作服务器。
容量规划常被忽略。RAID 5扩容后可用空间为（N-1）乘单盘容量，而RAID 6为（N-2）。若从4盘RAID 5迁到5盘RAID 6，可用空间反而可能下降。用下表对比常见迁移路径的空间变化：
| 原配置 | 目标配置 | 磁盘数 | 可用空间系数 |
|---|---|---|---|
| RAID 1 | RAID 5 | 3 | 2/3 单盘 |
| RAID 5 | RAID 5 扩容 | 4 到 5 | 3/4 到 4/5 单盘 |
| RAID 5 | RAID 6 | 4 到 5 | 2/4 到 3/5 单盘 |
硬件RAID卡的无停机实施步骤
以常见的LSI/Avago控制器为例，先通过storcli确认磁盘枚举状态：storcli /c0 /eall /sall show。新盘显示为Unconfigured Good即代表可加入。执行扩容命令如 storcli /c0 /v0 start migrate type=raid6 option=add drives=252:5，其中v0为逻辑卷编号，252:5为新盘 enclosure:slot。命令返回后，迁移即在后台启动。
迁移进度可用 storcli /c0 /v0 show migrate 监控。此阶段严禁重启或移除任何盘。若业务对延迟敏感，可在管理界面限制重构速率，例如设为30%，让出带宽给生产I/O。完成后，逻辑卷容量变大，但操作系统内文件系统仍识别旧大小，需到系统层扩展。
Windows平台使用磁盘管理中的扩展卷向导；Linux下若用LVM，先 pvresize 再 lvextend；若是直连分区，用 growpart 修改分区表，随后 resize2fs 或 xfs_growfs。注意文件系统类型决定命令，XFS只能用 xfs_growfs 且必须挂载状态执行。全部完成后，建议用压力工具跑一轮读写，确认无报错。
Linux软RAID的迁移与扩容实操
软RAID添加磁盘使用 mdadm --manage /dev/md0 --add /dev/sde。随后变更级别：mdadm --grow /dev/md0 --level=6 --raid-devices=4。内核会开始 reshape，进度存于 /proc/mdstat。此过程极耗CPU，可用 ionice 与 nice 调整优先级，避免影响数据库等进程。
reshape 完成后，同样需扩展上层存储。若 md0 是 LVM 物理卷，执行 pvresize /dev/md0 即可，后续逻辑卷扩展与硬件方案一致。有个细节：旧版 mdadm 在 RAID 1 转 RAID 5 时要求先设 raid-devices 数量，否则报错。因此操作前务必查阅对应版本手册，避免卡在半路无法回退。
监控方面，可配置 mdadm 监控邮件，当重构异常时报警。同时在 crontab 中定时记录 cat /proc/mdstat 输出，便于事后分析性能拐点。无停机不代表无风险，只有把每一步输出留痕，出问题才能快速定位。
常见故障与规避办法
第一类问题是迁移到一半断电。带BBU缓存的RAID卡可凭电池恢复，但软RAID只能靠UPS。因此操作前确认UPS电量大于预计迁移时间的两倍。第二类是误把数据盘当热备盘加入，导致原阵列降级，务必用 smartctl 或厂商工具核对序列号。
第三类是文件系统未对齐。扩容后若直接用 fdisk 新建分区，可能忽略4K对齐，长期引发性能衰减。推荐用 parted 并设置对齐单位为 optimal。最后，迁移完成别急着删备份，保留至少一周，待业务指标平稳后再清理，这是很多运维踩坑后的经验。
无停机RAID操作的本质，是用后台计算换业务连续性。只要准备充分、监控到位，在线扩容与级别迁移完全可以成为常规维护动作，而非高危演练。