RAID 再構築が本番 I/O に与える影響の背景
Linux のソフトウェア RAID（md デバイス）はディスク故障を検知すると、スペアやホットスワップで追加したドライブへ自動的に再同期（リビルド）を開始します。このリビルドはカーネル内部のスレッドが担うため、アプリケーションからは透過的に見えますが、実際には同じブロックデバイスのキューを競合して使います。
特に回転ディスク（HDD）構成では、シーケンシャルにブロックを読み書きするリビルド処理と、ランダムアクセスが多い本番ワークロードが混在すると、ディスクのシーク動作が増加し、レイテンシが跳ね上がります。SSD や NVMe でも同一コントローラーのキュー帯域を食い合う点は変わりません。
カーネルは /proc/sys/dev/raid/ 配下のパラメータでリビルド速度を調整できる仕組みを持っています。これを使わずにデフォルト設定のまま放置すると、リビルド中に本番データベースやストレージサービスの応答遅延が顕著に現れることがあります。
帯域制限パラメータの仕組みと設定手順
リビルド速度を制御するカーネルパラメータは次の 2 つです。
- speed_limit_min：再構築に割り当てる最低速度（KB/s）。アイドル状態でもこの値以上を確保しようとします。
- speed_limit_max：再構築に割り当てる最大速度（KB/s）。本番 I/O との競合が起きているときは、この上限まで帯域が制限されます。
現在の値を確認するには以下を実行します。
cat /proc/sys/dev/raid/speed_limit_min
cat /proc/sys/dev/raid/speed_limit_maxデフォルト値は多くのディストリビューションで speed_limit_min=1000、speed_limit_max=200000（200 MB/s）程度です。本番帯域への影響を抑えたい場合は speed_limit_max を下げます。
実行中のリビルドに即時反映する
sysctl 経由で書き込めば、再起動なしで即座に反映されます。
# 想定例: 最大 50 MB/s に制限する場合
sysctl -w dev.raid.speed_limit_max=50000
sysctl -w dev.raid.speed_limit_min=1000この変更はカーネルが内部で持つ「リビルドに使ってよい帯域の上限」を更新するものです。本番 I/O が少ない夜間時間帯には speed_limit_max を戻すことで、リビルドを早期完了させることもできます。帯域値はシステムのディスク性能や本番負荷に応じて調整が必要なため、実際の値は監視しながら段階的に変更してください。
再起動後も設定を維持する
再起動後に設定が戻ってしまわないよう、/etc/sysctl.d/ に設定ファイルを置きます。
# /etc/sysctl.d/99-raid-speed.conf
dev.raid.speed_limit_min = 1000
dev.raid.speed_limit_max = 50000設定ファイルを置いた後は sysctl --system で読み込みを確認するか、次回起動時に自動適用されます。なお、夜間だけ帯域を緩めたい運用では、この値をそのまま固定するのではなく、systemd の timer ユニットや cron で時間帯ごとに sysctl -w を切り替える方法が合っています。
リビルド進捗の監視と完了確認
リビルドの進捗は /proc/mdstat をリアルタイムで確認するのが最も手軽です。
watch -n 5 cat /proc/mdstat出力例（想定例）は次のような形式になります。
md1 : active raid5 sdb[0] sdc[1] sdd[2] sde[3]
2929893888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
[===========>.........] recovery = 56.3% (551083520/976631296)
finish=28.5min speed=27815K/sec[UUU_] の _ が再構築中のデバイスを示し、パーセントと完了予測時刻が確認できます。speed=27815K/sec が現在の帯域制限の効き具合を反映しているため、本番ピーク時間帯に値が設定した上限に近ければ制限が有効に機能していると判断できます。
より詳細な状態は mdadm コマンドでも確認できます。
mdadm --detail /dev/md1出力の State フィールドが clean または active になり、すべてのデバイスが active sync 状態になれば、リビルドが完了しています。
完了後の整合性検証フロー
リビルドが完了しても、ビット腐食（silent data corruption）の可能性を排除するため、整合性チェック（スクラブ）を実施することが推奨されます。mdadm はこのためのアクションを提供しています。
チェックアクションの実行
echo check > /sys/block/md1/md/sync_actionこのコマンドはアレイ全体を読み取り、パリティや冗長ブロックが実データと一致するかを検証します。不一致が見つかった場合、カーネルは修復可能な範囲でパリティを使って訂正を試みます。
進捗も同様に /proc/mdstat で確認でき、sync_action が idle に戻ったら完了です。
cat /sys/block/md1/md/sync_action
# idle と表示されれば完了
cat /sys/block/md1/md/mismatch_cnt
# 0 以外であれば不一致ブロックが存在するmismatch_cnt がゼロでない場合は単純なパリティ不一致（ジャーナリングされたファイルシステムでは正常範囲で発生することがある）なのか、真のデータ破損なのかを区別する必要があります。ファイルシステムが ext4 や XFS の場合は fsck でファイルシステム層の検証も合わせて実施し、エラーが出ないことを確認してください。
スクラブの定期スケジューリング
多くのディストリビューションでは mdcheck や mdadm の systemd timer が導入されており、月次・週次でチェックを自動実行できます。Debian/Ubuntu 系では /etc/default/mdadm の AUTOCHECK 設定、RHEL/Rocky 系では mdcheck_start.timer ユニットを確認してください。
# systemd timer の確認（Rocky Linux 9 / RHEL 9 系の想定例）
systemctl list-timers | grep md切り戻しと注意点
帯域制限を下げすぎた場合、リビルドが長期化します。もう一つのディスクが同じ期間中に故障するリスクは低くはないため、できる限り早期にリビルドを完了させることも重要です。speed_limit_min を極端に下げると、本番負荷が高い間はリビルドがほぼ停止する状態になります。
制限を元に戻す場合は以下で即時変更できます。
sysctl -w dev.raid.speed_limit_max=200000また、リビルド中は当該アレイのデバイスに対するパーティション変更やファイルシステムの縮小などを実施しないことが原則です。カーネルのブロックレイヤーは保護しますが、アレイが degraded 状態での高リスク操作は故障拡大につながる可能性があります。
一般的なつまずきとして、/etc/sysctl.conf に直接書いた設定が /etc/sysctl.d/ 配下のファイルに上書きされるケースがあります。設定の優先順位は辞書順で後ろのファイルが勝つため、99-raid-speed.conf のようにプレフィックス番号を大きくして意図的に優先させてください。
2026 年現行環境での差分と留意点
2026 年時点のメジャーディストリビューション（Ubuntu 24.04 LTS・Rocky Linux 9・Debian 12）では、mdadm 4.2 以降が標準パッケージに収録されています。mdadm 4.2 ではクラスター RAID や PPL（Partial Parity Log）のサポートが安定し、RAID 5 の書き込みホールリスクを軽減する構成が取りやすくなっています。
一方で、NVMe を複数束ねたソフトウェア RAID 構成では、speed_limit_max のデフォルト値（200 MB/s）がボトルネックになる場面が増えています。NVMe の帯域は HDD の数十倍に達するため、デフォルトのままではリビルドが不必要に低速になり、アレイが長時間 degraded 状態に置かれます。NVMe 構成では speed_limit_max を数 GB/s 単位に引き上げることも検討してください。
また、btrfs や ZFS をソフトウェア RAID 的に使う構成が増えています。これらはファイルシステム自体がチェックサムとスクラブ機能を持つため、md デバイスの check アクションと二重で実施する意義は薄れます。btrfs では btrfs scrub、ZFS では zpool scrub がそれぞれの整合性検証の主体となります。md デバイスと組み合わせてそれぞれの役割を意識した運用設計が求められます。
カーネル 6.x 系では md_sync_speed_policy という追加パラメータの議論もあり、将来的にはワークロードを自動検知してリビルド帯域を動的調整する機能が標準化される可能性があります。現時点では手動あるいはスクリプトによる時間帯制御が現実的な選択肢です。
「コマンドは打てる。次は”現場で通用する型”を最短で身につけたい」——そんなあなたへ。
ネットの断片的なTipsをコピペするだけでは、体系的な運用スキルはなかなか積み上がりません。リナックスマスター.JPの無料メルマガ「リナマガ」では、現場で実際に使うLinuxサーバー運用の考え方を、順を追って実務目線でお届けしています。いま登録された方には、安全なサーバー構築の「型」をまとめた『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼント中です。
＞＞ 図解60P『Linux入門マニュアル』を無料で受け取る
（メルマガ登録は10秒・いつでも解除OK）
※ 「独学の時間がもったいない」「プロから現場の技術を最短で学びたい」という本気の方には、2日で実務レベルが身につく初心者向けハンズオンセミナーもご用意しています。
PR・広告
コマンド操作から基本運用までを手を動かして学べる定番書。記事で触れた技術の土台固めに。
※ Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
