☰

BTRFS ファイルシステム RAID のエラーを監視するにはどうすればよいでしょうか?

tag-icon • tag-icon linux raid events btrfs
BTRFS ファイルシステム RAID のエラーを監視するにはどうすればよいでしょうか?

さまざまな BTRFS イベントに対してプログラム/スクリプトを実行できるデーモンに関するドキュメントをいくつか見たのですが、もう見つかりません。

BTRFS raid1 アレイのドライブ障害時にスクリプト/プログラムを実行するにはどうすればよいでしょうか。エラーが発生したときにスクリプトを実行して、障害が発生している可能性のあるドライブの早期警告として機能させたいのですが、実際のドライブ障害が最も重要です。その時点でファイルシステムをアンマウントし (BTRFS がそうしない場合は別として)、アラームを設定したいと思います。

答え1

通常のログシステムに加えて、BTRFSには統計ドライブごとにエラー（読み取り、書き込み、破損/チェックサム エラーを含む）を追跡するコマンド:

# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs   0
[/dev/mapper/luks-123].read_io_errs    0
[/dev/mapper/luks-123].flush_io_errs   0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0

したがって、単純なルート cronjob を作成できます。

[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'

これにより、1 時間ごとに正のエラー数がチェックされ、電子メールが送信されます。当然、電子メール通知が機能することを確認するには、このようなシナリオ (破損を引き起こしたり、grep を削除したりして) をテストする必要があります。

さらに、BTRFS (チェックサム機能付き) などの高度なファイルシステムでは、不良ドライブによって発生するサイレント破損を検出するために、2 週間ごとにスクラブをスケジュールすることが推奨されることがよくあります。

@monthly /sbin/btrfs scrub start -Bq /data

この-Bオプションを選択すると、スクラブがフォアグラウンドで実行されるため、cron が送信する電子メールで結果を確認できます。それ以外の場合は、バックグラウンドで実行され、電子メールには結果が含まれていないため、手動で結果を確認する必要があることに注意してください。

アップデート: Michael Kjörling の提案に従って grep を改良しました。ありがとうございます。

アップデート2: スクラブと通常の読み取り操作に関する追加メモ (これは BTRFS だけに当てはまるわけではありません):
Ioan が指摘したように、スクラブはアレイのサイズとタイプ (およびその他の要因) に応じて何時間もかかることがあり、場合によっては 1 日以上かかることもあります。また、これはアクティブ スキャンであり、将来のエラーは検出されません。スクラブの目的は、その時点でドライブのエラーを見つけて修正することです。ただし、他の RAID システムと同様に、定期的なスクラブをスケジュールすることをお勧めします。ファイルの読み取りなどの一般的な I/O 操作では、読み取られたデータが実際に正しいかどうかがチェックされるのは事実です。ただし、単純なミラーについて考えてみましょう。ファイルの最初のコピーが破損している場合 (おそらく故障しそうなドライブによるもの)、正しい 2 番目のコピーが実際に BTRFS によって読み取られた場合、BTRFS はドライブの 1 つに破損があることを認識しません。これは単に、要求されたデータが受信され、BTRFS がこのファイルに対して保存したチェックサムと一致するため、BTRFS が他のコピーを読み取る必要がないためです。つまり、あるドライブ上で破損していることがわかっているファイルを具体的に読み取ったとしても、この読み取り操作によって破損が検出される保証はありません。
ここで、BTRFS が常に正常なドライブからのみ読み取りを行い、不良ドライブの損傷を検出するスクラブが実行されず、その後正常なドライブも故障すると仮定します。その結果、データが失われます (少なくとも BTRFS はどのファイルがまだ正しいかを認識し、それらの読み取りを許可します)。もちろん、これは単純化された例です。実際には、BTRFS は常に 1 つのドライブから読み取り、他のドライブを無視するわけではありません。
ただし、定期的なスクラブは、通常の読み取り操作では必ずしも検出されないエラーを検出 (および修正) するため重要であるという点が重要です。

故障したドライブ: この質問は非常に人気があるため、この「監視ソリューション」は、不良の可能性があるドライブの問題 (たとえば、故障したドライブがエラーを引き起こしているが、まだアクセス可能) を検出するためのものであることを指摘しておきます。

一方、ドライブが突然なくなった場合 (故障してエラーが発生するのではなく、切断または完全に故障した場合)、そのドライブは障害のあるドライブになります (ZFS はそのようなドライブを FAULTED としてマークします)。残念ながら、BTRFS は、ファイルシステムがマウントされている間はドライブがなくなったことを認識しない可能性があります。これは、2015 年 9 月のこのメーリング リストのエントリで指摘されています (これは修正されている可能性があります)。

違いは、マウント時にデバイスが存在しないことを検知するコードはありますが、マウントされたファイルシステムにデバイスがドロップされたことを検知するコードは (まだ) ないということです。デバイスが消えたことを適切に検知することが優先事項ではないように見えるのはなぜか、私にはわかりませんが、それはマウント動作とは別の問題です。

メールアーカイブ[メールアドレス]/メッセージ46598.html

その時点では dmesg に大量のエラー メッセージが存在するため、dmesg を grep しても信頼できない可能性があります。BTRFS
を使用するサーバーの場合、RAID アレイ内のドライブの少なくとも 1 つが失われ、アクセスできなくなった場合にアラートを送信するカスタム チェック (cron ジョブ) を用意することが考えられます...

答え2

btrfs-progs v4.11.1 以降、stats には --check オプションがあり、いずれかの値がゼロでない場合はゼロ以外の値を返すため、正規表現は不要になります。

device stats -c /

答え3

エラー通知には stats コマンドは頼りになりません。ドライブが突然消えてもこのコマンドはエラーを返さないからです。SA​​TA ケーブルを外すかドライブを取り外してテストできますが、重要なファイル システムではお勧めできません。

btrfs device stats /

再起動後、btrfs はドライブが見つからないことを表示しますが、手遅れかもしれません。

btrfs fi show

答え4

システム監視のタスクのようです。Nagios プラグイン API を実装するチェックが存在します:チェック_btrfsソースコードを見るとわかるように、check_dev_statsデバイスの統計情報をチェックし、値がゼロでない場合はクリティカルになるという関数があります。また、割り当ての問題もチェックします。不明なのは、1 つのディスクが欠落しているかオフラインになっている場合のチェックの動作。

PS: プラグインは Debian にパッケージ化されています:監視プラグイン-btrfs

関連情報