☰

mdadm RAID の問題を通知するにはどうすればよいですか?

tag-icon • tag-icon linux raid software-raid mdadm
mdadm RAID の問題を通知するにはどうすればよいですか?

私は Ubuntu 12.04 LTS を実行しています。昨日、メールボックスにサーバーがシャットダウンしたというメッセージを見つけました。システムを再起動しましたが、何分経っても起動せず、カーネルがターミナルに何を出力しているかを確認するためのハードウェア KVM システムもありませんでした。そこで、システムを Linux レスキュー イメージに再起動したところ、ソフトウェア RAID 1 アレイが同期していないことがわかりました。レスキュー システムも RAID アレイの再構築を開始しました。

これまでのところ、ディスクにハードウェア エラーがあるという証拠はありません。SMART ステータスは今のところ良好です。

/etc/mdadm/mdadm.conf で電子メール通知が有効になっているにもかかわらず、mdadm から電子メール通知を受信しませんでした。

このサーバーは、すべての syslog メッセージをログ ホストに転送するようにも構成されているため、ログ ホストをチェックしました。関連する部分は次のとおりです。

5月20日 15:38:40 カーネル: [ 1.869825] md0: 0から536858624への容量変更を検出しました
5月20日 15:38:40 カーネル: [ 1.870687] md0: 不明なパーティションテーブル
5月20日 15:38:40 カーネル: [ 1.877412] md: バインド
5月20日 15:38:40 カーネル: [ 1.878337] md/raid1:md1: クリーンではありません -- バックグラウンド再構築を開始しています
5月20日 15:38:40 カーネル: [ 1.878376] md/raid1:md1: 2つのミラーのうち2つがアクティブ
5月20日 15:38:40 カーネル: [ 1.878418] md1: 0から3000052808704への容量変更を検出しました
5月20日 15:38:40 カーネル: [ 1.878575] md: RAIDアレイmd1の再同期
[をちょきちょきと切る]
5月20日 15:52:33 カーネル: カーネルのログ記録 (proc) が停止しました。
5 月 20 日 15:52:33 rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="845" x-info="http://www.rsyslog.com"] がシグナル 15 で終了します。

ご覧のとおり、システム (レスキュー システムではなく通常のシステム) は、システムの起動中に RAID アレイに何らかの問題があることをすでに検出しています。その後すぐに、何か (私ではありません) がシステムを停止しました。

私の質問は次のとおりです:

  1. ディスクが突然同期しなくなる原因は何でしょうか?
  2. なぜメールで通知されなかったのですか?
  3. システムを停止する前に、なぜエラーが syslog に適切に記録されなかったのでしょうか? システムが syslog に記録しようとしたが、syslog デーモンを停止した後に記録した可能性はありますか? もしそうなら、それを防ぐにはどうすればよいですか?
  4. 何が起こったのかを知るにはどうしたらいいでしょうか? あるいは、今何が起こったのかを知る方法がない場合、次回にもっと良い事後検証ができるように、ログ記録と通知をどのように改善できるでしょうか?

私の質問はない適切なバックアップ方法について。RAID はバックアップではないことはすでに知っています。私の質問は通知と診断についてのみです。

答え1

ディスクが突然同期しなくなる原因は何でしょうか?

ドライブ プラッターとメモリ内のデータ間のパスにおけるハードウェアまたはソフトウェアの障害である可能性があります。ドライブ ヘッド、ドライブ コントローラー、ケーブルの接続ヘッド、ケーブル自体 (内部断線)、ケーブルが差し込まれているドライブのポート、マザーボードまたはドーター カードのポート、マザーボードまたはドーター カードのコントローラー チップ、またはソフトウェア (どこか) の障害など、さまざまな原因が考えられますが、これらに限定されるわけではありません。

本当の話です。以前、RAIDミラーが不安定で、理由もなくドライブが落ちたことがあります。ドライブは正常にチェックされ、プラッターはクリーン（SMARTパスを繰り返しても何も検出されませんでした）で、すべてうまく機能していましたが、再び不安定になり、再び落ちてしまいました。3ドルのSATAケーブルを交換したら、問題は解決しました。即座に消え去りました。教訓: 問題が発生する可能性は非常に多く、データのパスにあるすべてのコンポーネントをチェックしなければ、常に「すべてが正常」であると想定することはできません。

なぜメールで通知されなかったのですか?

電子メール通知は、(a) アレイをアクティブに監視している場合、または (b) アレイが照会されている場合にのみ発生します。

私のアドバイスは、mdadm がプロセスとしてドライブ アレイをアクティブに監視する必要があるということです。これは、次のような方法で実現できます (ただし、まったく同じではありません)。

mdadm --monitor --scan --syslog

上記の行を特定のインストールに合わせて調整する必要があります。

システムを停止する前に、なぜエラーが syslog に適切に記録されなかったのでしょうか? システムが syslog に記録しようとしたが、syslog デーモンを停止した後に記録した可能性はありますか? もしそうなら、それを防ぐにはどうすればよいですか?

ログ記録が中止される原因としては、さまざまな問題が考えられます。

まず、syslog が一般的にどのように動作するかという問題があります。syslog を堅牢で信頼性の高いものにするために何年も費やされてきましたが、データがディスクに書き込まれない特定のエッジ ケースがあります。これはよく知られた設計上の問題であり、監視スタイルのサービス管理 (daemontools など) で積極的に対処されてきました。解決策は、syslog を完全にバイパスし、常に開いているファイル記述子を持つロガーに出力を書き込むことでした。これにより、何もドロップされず、ロガーは出力を可能な限り高速にディスクにダンプします。これは 100% 効果的な解決策ではありませんが、カーネルがパニックまたはシャットダウンする前にイベントがドライブに書き込まれる可能性が大幅に高まります。

2 つ目は、カーネルが完全にパニックを起こしたか、マシンを窮地に追い込むような他のイベントが発生した可能性があります。ハードウェアの故障でも問題が発生する可能性があります。電源ユニットの電力が不足しているマシンが Windows 8 で突然シャットダウンするのを見たことがあります。電源ユニットを交換すると、シャットダウンの問題は永久に解決しました。何もないカーネルが実行できるのは、「もう十分だ」と決めて再起動の世界に足を踏み入れるマシンを防ぐことです。

何が起こったのかを知るにはどうしたらいいでしょうか? あるいは、今何が起こったのかを知る方法がない場合、次回にもっと良い事後検証ができるように、ログ記録と通知をどのように改善できるでしょうか?

いくつかのアプローチがあります:

  • ログを別のパーティションに配置します。これは完全なログが取得されることを保証するものではありませんが、ディスクがいっぱいで書き込みができない、破損により読み取り専用で再マウントされるなど、ファイルシステムの問題を切り分けるのに役立ちます。このような特定のケースでは確かに役立ちます。

  • 重要なシステム情報をリモート ログに記録します。繰り返しますが、これは保証ではありませんが、再起動が発生する前に最後のパケットが「送信」され、そのパケットに再起動が発生した理由に関する重要な手がかりが含まれている場合は役立ちます。

  • 特定の重要なサービスについては、syslog への出力を、専用のロガーが出力をインターセプトしてできるだけ早くディスクに書き込む監視スタイルのログなど、他のものに置き換えることを検討してください。これにより、ストレージに送信される出力の信頼性が向上します。少し作業するだけで、他のサービス管理構成と並行して共存させることができます。

答え2

ディスクが突然同期しなくなる原因は何でしょうか?

ドライブ障害、コントローラ障害、その他のハードウェア障害。不明なソフトウェアの問題。

なぜメールで通知されなかったのですか?

Ubuntu には、1 日に 1 回 00:57 に RAID ボリュームをチェックする cronjob があります/etc/cron.d/mdadm。その時点でシステムに問題がなかった場合、またはその時点ですでに障害が発生していた場合は、メッセージを送信する方法がありませんでした。

システムを停止する前にエラーが syslog に適切に記録されなかったのはなぜですか?

まあ、ドライブが故障している場合、それ以上の書き込みは残っているものを破壊してしまう可能性があるため、ドライブに書き込もうとしてもあまり意味がありません。故障の正確な性質はわかりませんが、ボリュームまたはファイルシステムが読み取り専用になっている可能性があります。デフォルトでは、Ubuntu はルート ボリュームにエラーがある場合に読み取り専用ファイルシステムに切り替えるように設定されています。

次回、より適切な事後検証が行えるように、ログ記録と通知をどのように改善すればよいでしょうか?

リモート syslog ホストへのログ記録を設定します。こうすることで、ストレージ障害が発生しても何もログに記録されないことがなくなります。

関連情報