Ubuntu の mdadm アレイで故障したドライブを交換する

この投稿の情報は、Ubuntu 18.04とそのリポジトリに含まれるmdadmのバージョン（v4.1-rc1執筆時点）に基づいています。他のバージョンでは有効かどうかは不明です。

先日、自宅のファイルサーバーで突然のドライブ故障が発生しました。このサーバーは9台のドライブをmdadm RAID-6アレイで構成しています。故障はいつも不安でしたが、幸いにも交換用ドライブをすぐに入手でき、翌日には届いたので、すぐに再構築を開始することができました。

正直に言うと、ファイルサーバーを最初にセットアップした時は少々ケチでした。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スロットに2つのセミノーブランドSATAコントローラーを搭載しています。

SATA は一般的にホットスワップをサポートしているはずですが、このセットアップではリスクを冒したくなかったので、ドライブを交換する間はマシンをシャットダウンすることを選択しました。

その前に、/etc/fstab ファイルで RAID デバイスをコメントアウトしておくことをお勧めします。そうすることで、Ubuntu が次回起動時に RAID デバイスを自動的にマウントしようとしなくなります。RAID アレイの劣化により、Ubuntu がハングアップしてリカバリモードに強制的に移行してしまう可能性があります。デスクトップシステムであれば大きな問題にはならないかもしれませんが、私はこのサーバーをモニターやキーボードを接続せずにヘッドレスで運用しているので、少し面倒です。

新しいドライブをインストールしたマシンを起動したら、lsblk などの方法でドライブを識別します。他に何も変更していない場合は、おそらく（必ずしもそうとは限りませんが）交換したドライブと同じ名前が付けられます。私の場合は同じ名前だったので、新しいドライブも /dev/sdf という名前になっています。

私のアレイは物理デバイスではなくパーティションに基づいているため、正常に動作しているドライブから新しいドライブにパーティションテーブルをコピーして、完全に同一であることを確認する必要がありました。アレイを物理デバイスで実行する場合は、この手順を省略できます。

この目的のためにsgdiskを使用し、パーティションテーブルを/dev/sdcから/dev/sdfにコピーしました。デバイス名は、ご自身のデバイス名に合わせて適宜置き換えてください。

ここでの順序に注意してください。「to」ドライブを最初にリストします。これは私にとっては少し直感に反しますが、アレイ内の別のドライブ障害が発生しないように、正しく記述してください ;-)

次に、UUID の競合を避けるために、新しいドライブに新しい UUID を生成します。

そしてついに、新しいドライブをアレイに追加して再構築パーティーを始めましょう！（まあ、パーティーというよりは、むしろかなり時間がかかり、不安になるプロセスです。もうこれ以上ドライブが故障するのは絶対に避けたいですからね。ビールが効くかもしれませんけどね）

とにかく、新しいドライブをアレイに追加するには、次のコマンドを発行します (この場合も、デバイス名を必要に応じて独自のものに置き換えてください)。

すべてが順調に進めば、ドライブは問題なくアレイに追加されます。実際にはデフォルトで「ホットスペア」として追加されていると思いますが、このアレイにはディスク（故障したディスク）が1つ欠けているため、すぐに使用可能になり、再構築プロセスが開始されます。

次のように監視することができます:

おそらく時間がかかるでしょう。私の低スペックサーバー（主にコンシューマーグレードのハードウェアとデスクトップドライブをベースにしています）では、100MB/秒弱の速度しか出ませんでした。これはRAID-6なので、再構築には大量のパリティ計算が必要になることに注意してください。RAID-10であれば、はるかに高速だったでしょう。このマシンはAMD A10 9700EクアッドコアCPUを搭載しています（「E」は低クロックの省電力モデル、つまり超高速ではないという意味です）。これは、どれくらいの速度が期待できるかの目安としてお考えください。私のマシンには8TBドライブが9台搭載されており、完全な再構築には24時間強かかりました。

再構築中も、必要に応じてファイルシステムをアレイにマウントして通常通り使用できますが、私は再構築が完了するまでそのままにしておくことを推奨します。1つのドライブに障害が発生すると、すぐに別のドライブにも障害が発生する可能性があるため、再構築はできるだけ早く完了させる必要があります。再構築中に別のドライブに障害が発生するのは避けたいものです。そのため、必要のないI/O処理でアレイに負荷をかけないようにしてください。

完了したら、/etc/fstab ファイルに再度追加し、再起動してファイルをお楽しみください :-)