Ubuntu服务器软件RAID阵列维护与监控

接手一台运行多年的Ubuntu服务器，最让人后背发凉的时刻，莫过于在终端里看到那一行“Degraded array”的警告。软件RAID，尤其是mdadm管理的阵列，在Linux生产环境中极其普遍，但很多人对其维护还停留在“能用就行”的层面。一旦磁盘真正离线，而我们连备用盘都没准备，或者忘记了阵列的组装命令，数据丢失的风险就会直线上升。这里直接切入正题，把Ubuntu下软件RAID阵列从监控、日常维护到故障换盘的全流程彻底讲透。

别依赖图形界面，在服务器上最直接有效的方式永远是命令行。要查看所有已激活的RAID阵列的概况，执行cat /proc/mdstat。这个文件是内核实时维护的RAID状态快照。输出会清晰列出设备名如md0，阵列级别如raid1或raid5，以及成员盘状态。标记为[UU]表示所有成员正常，如果出现[U_]或[_U]，说明有一块盘已经掉线或失效。这个命令是巡检第一步，比任何监控脚本都直观。

更详细的信息藏在mdadm --detail /dev/md0里。这里要重点关注几个字段：State必须为clean或active；Active Devices和Working Devices的数量应等于阵列创建时的盘数；最关键的是每个设备条目后的State，正常应为active sync。如果看到faulty、removed或spare rebuilding，就要立刻采取行动。Rebuild Status字段在重建时会显示百分比进度，这个进度条不是线性的，大容量硬盘可能在前50%很快，后面越来越慢，这是正常现象。

被动查看日志等于等故障找上门。mdadm自带的监控功能必须配置起来。编辑/etc/mdadm/mdadm.conf，确保里面有MAILADDR your@email.com这一行，这样当阵列事件触发时，系统会自动发送邮件。如果这个文件里没有定义当前阵列的信息，先用mdadm --detail --scan >> /etc/mdadm/mdadm.conf把现有阵列配置追加进去，再手动补上邮件地址。

仅有邮件还不够，很多服务器环境发邮件本身就不稳定。更可靠的做法是结合系统级的定时任务。在/etc/cron.d/里创建一个mdadm-check文件，内容为每天凌晨执行一次mdadm --monitor --scan --oneshot。这个参数组合会让mdadm扫描所有阵列，只报告当前问题然后退出，不常驻内存，资源占用几乎为零。如果检测到异常，它会通过syslog记录，同时触发邮件告警。配合日志监控工具如logwatch，可以把mdadm相关日志单独提取出来每日汇总推送。

对于需要实时告警的场景，直接让mdadm以守护进程模式运行：mdadm --monitor --scan --daemonise。它会持续监听内核发出的RAID事件，包括磁盘读写错误、热备盘激活、重建完成等。生产环境建议两种方式叠加使用，守护进程保证实时性，定时任务作为兜底，防止守护进程意外退出后出现监控真空。

真正的运维高手不是在故障发生时手忙脚乱查文档，而是已经把操作步骤刻在肌肉记忆里。在测试环境或非核心阵列上，可以主动模拟磁盘故障来验证流程。用mdadm --manage /dev/md0 --fail /dev/sdb1命令，人为将sdb1标记为故障盘。此时再查看mdstat，阵列状态会变为degraded，那块盘显示为(F)。

替换物理盘之前，务必先从阵列中移除故障盘：mdadm --manage /dev/md0 --remove /dev/sdb1。关机更换硬盘后，新盘插入系统，其设备名可能发生变化，这是新手最容易踩的坑。不要假设新盘还是sdb，用lsblk或fdisk -l确认新盘的设备标识。最稳妥的方式是使用UUID或文件系统标签，但在RAID成员盘层面，通常直接用设备名操作，前提是确认清楚。

新盘的分区表必须与原阵列其他成员完全一致。用sgdisk命令可以精确复制分区表：sgdisk -R /dev/sdc /dev/sda，其中sda是原有正常盘，sdc是新盘。随后用sgdisk -G /dev/sdc随机化新盘的GUID，避免冲突。分区完成后，将新分区加入阵列：mdadm --manage /dev/md0 --add /dev/sdc1。阵列会自动开始重建，watch cat /proc/mdstat可以实时观察重建速度。重建期间系统负载会升高，对于生产环境的RAID5阵列，可以通过写入/sys/block/md0/md/sync_speed_min和sync_speed_max来人为限制重建速率，避免影响正常业务。例如echo 50000 > /sys/block/md0/md/sync_speed_max，将最大重建速度限制在每秒50MB左右。

阵列状态显示clean不代表数据真的完好。静默数据损坏是软件RAID最隐蔽的敌人。mdadm提供了check功能，对整个阵列做数据一致性扫描。手动触发命令为echo check > /sys/block/md0/md/sync_action。这个操作会逐条带比对所有成员盘的数据，发现不一致时会自动修复，前提是阵列有冗余能力，如RAID1或RAID5。

建议将check操作做成定期任务。很多Linux发行版默认在每周日凌晨执行，可以在/etc/cron.d/mdadm里看到相关配置。如果系统没有，可以手动添加：在/etc/cron.d/里新建文件，写入每周一次的全量校验。注意check操作会持续数小时甚至数天，对大容量硬盘尤其如此。可以通过echo idle > /sys/block/md0/md/sync_action暂停校验，之后用echo check恢复。校验结果通过查看/sys/block/md0/md/mismatch_cnt获取，这个数字代表不一致的条带数量，正常情况下应为0。如果这个数字持续增长，说明可能存在内存故障、数据线接触不良或控制器问题，需要深入排查硬件。

很多人配置完阵列能用就再也没管过initramfs的更新。一旦内核升级或系统更新，重启后阵列可能无法自动组装，直接掉进initramfs的救援shell。这个场景必须提前预防。每次手动更改阵列配置后，务必执行update-initramfs -u，把最新的mdadm.conf打包进启动镜像。

如果已经掉进了救援模式，不要慌张。首先确认mdadm.conf是否在initramfs环境中被正确加载。可以用cat /proc/mdstat看阵列是否已自动组装。如果没有，手动组装：mdadm --assemble --scan。这个命令会读取默认配置文件尝试组装所有阵列。如果配置文件丢失，可以用更底层的命令：mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1，明确指定成员盘。阵列组装成功后，退出救援shell，系统应该能继续引导。进入系统后第一件事就是重新生成initramfs。

/proc/mdstat里的信息量其实很大，但多数人只看那行状态字母。在重建过程中，它会显示重建速度如[=>...................] recovery = 8.3% (162842432/1953514496) finish=342.8min speed=80000K/sec。这里的finish时间是估算值，speed是当前瞬时速度。如果重建速度波动很大，可能是磁盘I/O竞争导致，可以用iotop找出争抢I/O的进程，临时调整优先级。另外，Personalities行显示了内核当前加载的RAID级别模块，如果这里没有你需要的级别，说明对应内核模块未加载，需要modprobe raid1或raid456等。

在克隆磁盘或从快照恢复的场景中，可能出现两块盘拥有相同的md UUID，导致阵列组装混乱。mdadm是通过超级块里的UUID来识别成员关系的。用mdadm --examine /dev/sda1可以查看某块盘超级块里的详细信息，包括UUID。如果发现冲突，需要对其中一块盘重新生成超级块，这相当于将其踢出原阵列重新加入，操作前务必确认数据已经备份或阵列有其他冗余。

阵列本身的名称如md0也可以自定义，避免多阵列环境下混淆。在创建阵列时用mdadm --create /dev/md/name --name=myarray这样的方式，阵列会出现在/dev/md/目录下，名称更直观。对于已有阵列，可以通过修改mdadm.conf中的ARRAY行，加上name=参数，并更新initramfs来持久化这个名称。

RAID阵列的I/O性能不是一成不变的。用iostat -x 1持续观察每个成员盘和md设备的await和util指标。如果发现md设备的等待时间远高于成员盘，可能是条带大小与工作负载不匹配。RAID的条带大小在创建时就固定了，无法在线修改，只能备份数据后重建。对于顺序大I/O场景，条带越大越好，如512KB甚至1MB；对于随机小I/O，64KB或128KB更合适。

另一个可在线调整的参数是预读缓存。通过blockdev --getra /dev/md0查看当前预读值，用blockdev --setra 65536 /dev/md0设置为较大值，可以提升顺序读性能。但预读过大对随机读无益，还会浪费内存。要根据实际负载类型测试调整。阵列的写意图位图write-intent bitmap也值得关注，它能在意外断电后大幅缩短重建时间，但会带来微小的写性能损失。如果阵列已创建但未开启位图，可以用mdadm --grow /dev/md0 --bitmap=internal在线添加，无需卸载阵列。

当阵列出现一次短暂的降级又自动恢复，或者某个磁盘频繁报错，必须从日志里找线索。所有mdadm事件都会记录在/var/log/syslog里，用grep mdadm /var/log/syslog可以过滤出所有相关条目。重点关注I/O error、sector、medium error这些关键词。如果某个扇区反复报错，说明磁盘可能已经产生了坏道，即使当前阵列状态还是clean，这块盘也应该尽快更换。smartctl -a /dev/sda可以查看磁盘的SMART信息，Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable这三个值只要有一个大于零，就说明硬盘物理层面已经出现问题，继续使用风险极高。

软件RAID的维护不是一次性配置工作，而是一个持续的过程。把监控自动化、把故障处理流程化、把数据校验定期化，这三件事做到位，Ubuntu下的软件RAID阵列完全能够提供不输于硬件RAID卡的可靠性。关键在于别等到看见降级警告才开始想下一步怎么办，而是让系统自己告诉你哪里出了问题，你只需要按预定方案执行即可。