mdadm RAID縮退検知から本番リビルド完了まで｜IO抑制・整合性検証・障害再発防止設計

RAID縮退の検知：何が起きているかを正確に把握する

ディスク障害が発生した直後、最初に確認すべきは mdadm --detail の出力です。単に「縮退している」という事実だけでなく、どのデバイスがどのような状態にあるかを正確に把握することが、以降の作業全体の精度を左右します。

mdadm --detail /dev/md0

出力の State フィールドが clean, degraded になっている場合、アレイは動作しているものの冗長性を失った状態です。Active Devices と Working Devices の差分で、何台が脱落したかが分かります。

個別デバイスの状態は /proc/mdstat でも確認できます。

cat /proc/mdstat

[UU_] のようにアンダースコアが含まれる場合、その位置のデバイスが欠落しています。またシステムログには md/raid または ata ドライバのエラーが残っていることが多いため、journalctl -k --since "1 hour ago" | grep -i -E 'md|ata|scsi|sd[a-z]' で前後の文脈を確認しておきます。

メール通知が設定されている環境では、/etc/mdadm/mdadm.conf の MAILADDR 行と mdmonitor.service の稼働を確認します。通知が届いていなかった場合は、検知基盤の見直しが必要です。縮退状態を見落とす時間が長いほど、二次障害のリスクが高まります。

リビルド前のIO抑制：本番負荷を守りながら再同期を進める

mdadmのリビルド（再同期）はデフォルト設定のままでは積極的にディスクIOを使います。本番サービスが稼働しているホストで無制限にリビルドを走らせると、サービスの応答劣化を引き起こすことがあります。

Linuxカーネルは再同期の最低速度と最高速度をパラメータとして持っています。確認と変更はそれぞれ以下のように行います。

# 現在の設定確認
cat /proc/sys/dev/raid/speed_limit_min
cat /proc/sys/dev/raid/speed_limit_max

# 最高速度を絞る（単位: KB/s）
echo 50000 > /proc/sys/dev/raid/speed_limit_max

上記の変更は再起動後に失われます。永続化するには /etc/sysctl.d/99-mdadm.conf に以下のように書いておきます。

dev.raid.speed_limit_max = 50000
dev.raid.speed_limit_min = 1000

適切な値はシステムのストレージ性能とサービスのSLAによって変わります。想定例として、通常時のシーケンシャル書き込みが200 MB/s程度のSATA HDDを持つシステムで業務ピーク時間帯に適用する場合、speed_limit_max を50000〜100000（50〜100 MB/s）程度に設定することが出発点になります。業務時間外に上限を戻して速度を出す、という運用も有効です。

また、ionice を使ってリビルド関連のカーネルスレッドにIO優先度を下げる方法もありますが、mdadmのカーネルスレッドへの直接適用は現行カーネルでは制約があるため、speed_limit_max による帯域制御が現実的です。

新ディスクの追加とリビルド手順

交換するディスクが物理的に取り付けられ、カーネルに認識されたことを lsblk および dmesg で確認します。新しいデバイスパスが /dev/sdd であるとすると、まず障害デバイスをアレイから除去し、新ディスクを追加します。

# 障害デバイスをfailed状態としてマーク（まだアレイに残っている場合）
mdadm /dev/md0 --fail /dev/sdb

# アレイからデバイスを除去
mdadm /dev/md0 --remove /dev/sdb

# 新ディスクを追加してリビルド開始
mdadm /dev/md0 --add /dev/sdd

--add の実行後、/proc/mdstat を確認すると再同期の進行状況が表示されます。

watch -n 10 cat /proc/mdstat

出力例（想定例）：

md0 : active raid5 sdd[3] sdc[2] sda[0]
      2930276352 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [U_U]
      [==>..................]  recovery = 12.5% (183G/1465G) finish=240.0min speed=102200K/sec

リビルド中は [U_U] のように表示され、完了すると [UUU] になります。完了を待つ間も、定期的にシステムログを確認して新ディスクへのエラーが出ていないかを監視します。リビルド中に二次障害が発生した場合はデータ損失につながるため、注意が必要です。

リビルド完了後の整合性検証

リビルドが完了してアレイが clean 状態に戻っても、データの整合性を検証するステップが残っています。mdadmには check アクションがあり、アレイ全体を読み取って不整合ブロックを検出します。

# 整合性チェックの開始
echo check > /sys/block/md0/md/sync_action

# 進行状況の確認
cat /sys/block/md0/md/sync_completed
cat /proc/mdstat

checkが完了したあと、不整合ブロック数を確認します。

cat /sys/block/md0/md/mismatch_cnt

ゼロであれば整合性に問題はありません。ゼロでない場合、その値が極小（数ブロック程度）であればファイルシステム上のメタデータ不整合である可能性があります。一方、大量の不整合が検出された場合は repair アクションで修復することができますが、どのコピーが正しいかをシステムが判断することになるため、内容によってはデータの損失につながります。本番環境ではバックアップを確認してから実施するのが原則です。

checkは月次スケジュールで自動実行するのが一般的です。多くのディストリビューションでは /etc/cron.d/mdadm にスクリプトが用意されており、無効化していなければ定期的に実行されます。確認しておきます。

cat /etc/cron.d/mdadm

障害再発防止のための設計指針

RAIDは可用性を向上させますが、障害の根本原因を解消する仕組みではありません。同一ロット・同一使用時間のディスクを複数台使用している場合、一台が故障すると他のディスクも近い時期に故障するリスクがあります。これは一般的によく知られた現象であり、リビルド中に発生する二次障害はデータ損失の直接的な原因となります。

スペアディスクの配備

mdadmではホットスペアをアレイに組み込んでおくことができます。

mdadm /dev/md0 --add-spare /dev/sde

スペアが存在する場合、障害検知後に自動でリビルドが開始されます。担当者が気づく前に再冗長化が進むため、リードタイムを短縮できます。

SMARTモニタリングの統合

smartd を使ってSMART属性を定期的に監視し、異常な再割り当てセクタ数やCRCエラーの増加を早期に検知する仕組みを入れておきます。/etc/smartd.conf に適切なオプションを設定することで、閾値超過時にメール通知を発行できます。

/dev/sda -a -o on -S on -s (S/../.././02|L/../../6/03) -m root -M exec /usr/share/smartmontools/smartd-runner

RAIDによる縮退通知よりも前に、SMARTで予兆を捉えることができれば、計画的な交換が可能になります。

mdadm.confの最新化と通知テスト

ディスクの追加・交換後は mdadm.conf を更新し、initramfsを再生成しておきます。

mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u   # Debian/Ubuntu系
dracut -f             # RHEL/Fedora系

また、通知メールが実際に届くかどうかを定期的にテストすることを推奨します。設定を入れたまま確認を怠り、いざ障害が発生したときにメールが届いていなかった、というのはよくあるつまずきのひとつです。

2026年現行環境での注意点

2026年時点で一般的に使われているディストリビューション（Ubuntu 24.04 LTS、RHEL 9系、Debian 12）での運用においていくつかの点に注意が必要です。

NVMe SSDとmdadmの組み合わせ：NVMe SSDをmdadmアレイに使う構成は一般的になっていますが、NVMeデバイスは /dev/nvme0n1 のように命名されます。ホットプラグ時のデバイス番号の変動に注意が必要で、/dev/disk/by-id/ または /dev/disk/by-uuid/ を使ってデバイスを参照するほうが安全です。

systemdとmdmonitor：sysVinitのスクリプトでRAID監視を構成していた旧来のシステムとは異なり、現行環境では mdmonitor.service がsystemdのユニットとして管理されます。

systemctl status mdmonitor.service
systemctl enable mdmonitor.service

LVMとの組み合わせ：mdadmアレイの上にLVMを構成している場合（md + LVM構成）、リビルド中にLVMのpvやvgが一時的に不安定になることがあります。リビルド開始前に pvdisplay と vgdisplay で状態を確認しておくことを推奨します。

Btrfs・ZFSとの使い分け：新規構築の場合、ZFSやBtrfsのネイティブRAID機能（ZFS raidz、Btrfs RAID）を選択することも現実的な選択肢です。これらはファイルシステムレベルでのチェックサムを持ち、サイレントデータ破損の検出に優れています。一方、既存のmdadmアレイを運用しているシステムでは、移行コストと安定稼働の実績を踏まえて継続利用することも合理的な判断です。mdadmは引き続きLinuxカーネルでサポートされており、2026年現在も主要ディストリビューションでメンテナンスが続いています。