Ubuntu の mdadm アレイで故障したドライブを交換する
出版された: 2025年2月15日 22:02:23 UTC
mdadm RAID アレイでドライブ障害が発生するという恐ろしい状況に陥っている場合、この記事では Ubuntu システムでドライブを正しく交換する方法について説明します。
Replacing a Failed Drive in an mdadm Array on Ubuntu
この投稿の情報は、Ubuntu 18.04 とそのリポジトリに含まれる mdadm のバージョン (v4.1-rc1 の執筆時点) に基づいています。他のバージョンでは有効ではない可能性があります。
最近、自宅のファイル サーバーで突然ドライブ障害が発生しました。このサーバーは、mdadm RAID-6 アレイの 9 つのドライブで構成されています。これは常に恐ろしいことですが、幸いなことに、交換用ドライブをすぐに入手でき、翌日には配達されていたため、再構築を開始することができました。
最初にファイル サーバーをセットアップしたとき、私は確かに少しケチりすぎました。ドライブのうち、実際の NAS ドライブは 2 つだけ (Seagate IronWolf)、残りはデスクトップ ドライブ (Seagate Barracuda) です。予想通り、故障したのはデスクトップ ドライブの 1 つでした (ただし、ほぼ 3 年間使用した後)。完全に死んでいました。デスクトップ USB エンクロージャに移動した後、不気味なクリック音が鳴るだけで、Ubuntu 20.04 も Windows 10 もそれを検出できませんでした。
さて、交換部品の話に移ります (そう、私が購入した新しいドライブは IronWolf でした。教訓を得ました)。稼働中のアレイでドライブを失うのは恐ろしいことですが、交換の正しい手順を知らないとさらに恐ろしいです。mdadm アレイで故障したドライブを交換しなければならなかったのは今回が初めてではありませんが、幸いにも非常にまれなことなので、通常は適切なコマンドを調べる必要があります。今回は、今後の参考のために自分用の小さなガイドを作成することにしました。
したがって、まず最初に、mdadm から恐ろしい障害イベントの電子メールを受け取ったら、どのドライブに障害が発生したかを特定する必要があります。もちろん、デバイス名 (私の場合は /dev/sdf) は表示されますが、マシンの起動時に名前が変わる可能性があるため、実際にどの物理ドライブであるかは明らかではない可能性があります。
どのデバイス名に障害が発生したかさえわからない場合は、次のコマンドを使用して確認できます (/dev/md0 を RAID デバイスに置き換えます)。
前述したように、私の場合は /dev/sdf だったので、それを続けましょう。
次に、次のコマンドを発行して、故障したドライブのシリアル番号を見つけます。
(smartctl が見つからない場合は、Ubuntu に smartmontools パッケージをインストールする必要があります)
次に、シリアル番号をドライブの物理ラベルのシリアル番号と比較し、どのドライブが故障したかを判別します。
しかし、今回はそれほど幸運ではありませんでした。ドライブは完全に壊れていて、シリアル番号を含む SMART やその他のデータも提供できませんでした。
サーバーに物理的にアクセスできたので (物理ドライブを自分で交換する場合には、これが本当に必要だと思います ;-)) 、ディスク障害が発生したときにサーバーは実際に稼働していたので (RAID-6 冗長性のおかげで正常に稼働し続けました)、非常に原始的ですが、実際には非常に効果的で明白な方法、つまり、大きなファイルをサーバーにコピーして、どの HDD ライトが点滅しないかを確認する方法を採用しました。数秒以内に、原因を特定できました。
さて、物理ドライブを取り外す前に、次のコマンドを発行して、この意図を mdadm に正式に通知することをお勧めします (デバイス名は必要に応じて独自のものに置き換えてください)。
成功すると、mdadm はドライブを「ホット リムーブ」したというメッセージを返します。これは、その時点で仮想 RAID デバイスが実際に実行されているためと思われます。
「デバイスまたはリソースがビジーです」のようなエラー メッセージが表示されて失敗した場合は、mdadm が実際にはドライブが完全に故障したと登録していない可能性があります。これを実行するには、次のコマンドを発行します (この場合も、デバイス名を適切なものに置き換えることを忘れないでください)。
その後、前のコマンドを使用してアレイからデバイスを削除できるはずです。
次は、実際にドライブを交換するときです。マシンとコントローラがホットスワップに対応していることが本当に確実であれば、マシンをシャットダウンせずにこれを実行できます。これは、実際に対応できることがわかっている実際の適切なサーバー ハードウェアで実行されている重要な実稼働システムでは、実行すべき方法です。ただし、私の自宅のファイル サーバーは、より多くの SATA ポートを提供するために、PCIe スロットにセミノーネームの SATA コントローラを 2 つ搭載したコンシューマー グレードのデスクトップ マザーボードに基づいています。
SATA は一般的にホットスワップをサポートしているはずですが、このセットアップではリスクを冒したくなかったので、ドライブを交換する間はマシンをシャットダウンすることにしました。
それを実行する前に、/etc/fstab ファイルで RAID デバイスをコメント アウトして、Ubuntu が次回の起動時に自動的にマウントしないようにすることをお勧めします。RAID アレイの劣化により、Ubuntu がハングアップしてリカバリ モードに強制される可能性があるためです。デスクトップ システムであれば大きな問題にはならないかもしれませんが、私はこのサーバーをモニターやキーボードを接続せずにヘッドレスで実行しているので、これは少し面倒です。
新しいドライブをインストールしたマシンを起動した後、lsblk または他の手段を使用してドライブを識別します。他に何も変更していない場合は、おそらく(必ずしもそうとは限りませんが) 交換したドライブと同じ名前が付けられます。私の場合はそのとおりだったので、新しいドライブも /dev/sdf と呼ばれます。
私のアレイは物理デバイスではなくパーティションに基づいているため、動作中のドライブから新しいドライブにパーティション テーブルをコピーして、それらが完全に同じであることを確認する必要がありました。代わりに物理デバイスでアレイを実行する場合は、この手順を省略できます。
この目的のために sgdisk を使用し、パーティション テーブルを /dev/sdc から /dev/sdf にコピーしました。デバイス名は、必要に応じて自分のデバイス名に置き換えてください。
ここでの順序に注意してください。最初に「to」ドライブをリストします。これは私にとっては直感に反しますが、アレイで別のドライブ障害が発生しないように、正しく実行してください ;-)
次に、UUID の競合を避けるために、新しいドライブに新しい UUID を生成します。
そしてついに、新しいドライブをアレイに追加して再構築パーティーを始める時が来ました! (まあ、これはパーティーではなく、実際には非常に遅くて不安なプロセスです。この時点で別のドライブが故障することは絶対に避けたいからです。ビールが役立つかもしれませんが)
とにかく、新しいドライブをアレイに追加するには、次のコマンドを発行します (ここでも、デバイス名を必要に応じて独自のものに置き換えてください)。
すべてがうまくいけば、ドライブは問題なくアレイに追加されます。実際にはデフォルトで「ホット スペア」として追加されると思いますが、このアレイにはディスク (障害が発生したディスク) がないため、すぐに使用されて再構築プロセスが開始されます。
次のように監視することができます:
これにはおそらくしばらく時間がかかるでしょう。私の低性能サーバー (主に消費者向けハードウェアとデスクトップ ドライブをベースとしています) では、100 MB/秒弱の速度を達成できました。これは RAID-6 であるため、再構築には多くのパリティ計算が伴うことに留意してください。RAID-10 であれば、はるかに高速だったでしょう。この特定のマシンには、AMD A10 9700E クアッド コア CPU が搭載されています (「E」は、低速のエネルギー効率モデル、つまり超高速ではないことを意味します)。これは、期待できる結果をお伝えするだけです。私のセットアップには 9 台の 8 TB ドライブがあり、完全な再構築には 24 時間強かかりました。
再構築中は、必要に応じてファイルシステムをアレイにマウントして通常どおり使用できますが、再構築が完了するまでそのままにしておくことをお勧めします。1 つのドライブに障害が発生すると、すぐに別のドライブにも障害が発生する可能性があることに留意してください。再構築中に別のドライブに障害が発生することは避けたいので、再構築はできるだけ早く完了する必要があります。したがって、厳密に必要ではない他の IO で負荷をかけないでください。
完了したら、/etc/fstab ファイルに再度追加し、再起動してファイルをお楽しみください :-)