mdadm RAIDの問題の通知を受け取る方法は？
Ubuntu 12.04LTSを実行しています。昨日、メールボックスにサーバーがシャットダウンされたというメッセージが表示されました。システムを再起動しましたが、数分経っても起動せず、カーネルが端末に何を出力しているかを確認するためのハードウェア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：bind 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 [snip] 5月20日15:52:33カーネル：カーネルロギング（proc）が停止しました。 5月20日15：52：33rsyslogd：[Origin software = "rsyslogd" swVersion = "5.8.6" x-pid = "845" x-info = "http：/ /www.rsyslog.com "]シグナル15で終了します。
ご覧のとおり、システム（レスキューシステムではなく通常のシステム）は、システムの起動中にRAIDアレイに問題があることをすでに検出しています。その後すぐに、何か（私ではない）がシステムを停止しました。
だから私の質問は：
- ディスクが突然同期しなくなる原因は何ですか？
- メールで通知されなかったのはなぜですか？
- システムを停止する前に、エラーがsyslogに正しく記録されなかったのはなぜですか？システムがsyslogにログを記録しようとしたが、syslogデーモンを停止した後にログを記録した可能性がありますか？もしそうなら、私はそれを防ぐために何ができますか？
- 何が起こったのかを知るために何ができますか？または、何が起こったのかを今すぐ知る方法がない場合、次回より良い事後分析ができるように、ロギングと通知を改善するにはどうすればよいですか？
私の質問はnot適切なバックアップ方法についてです。 RAIDがバックアップなどではないことはすでに知っています。私の質問は通知と診断だけです。
ディスクが突然同期しなくなる原因は何ですか？
ドライブプラッタとメモリ内のデータの間のパスにあるハードウェアまたはソフトウェアの障害である可能性があります。これは、ドライブヘッド、ドライブコントローラ、ケーブルの接続ヘッド、ケーブル自体（内部断線）、ケーブルがドライブに接続されているポート、マザーボードまたはドーターカードのポートを意味しますが、これらに限定されません。 、マザーボードまたはドーターカードのコントローラーチップ、またはソフトウェアの障害（どこか）。
実話：私はかつて、不安定なRAIDミラーを持っていて、理由もなくドライブを落としていました。ドライブは正常にチェックアウトされ、プラッターはきれいで（繰り返しSMARTパスは何も表示されませんでした））、すべてが正常に機能しました-それが再び剥がれるまで、そして何度も。問題即座に消えました。話の教訓：うまくいかない可能性のあるLOTがあり、パス内のすべてのコンポーネントをチェックしないと、「すべてが正常である」と常に想定できるとは限りません。データの。
メールで通知されなかったのはなぜですか？
電子メール通知は、（a）アレイをアクティブに監視している場合、または（b）アレイに問い合わせがあった場合にのみ発生します。
私のアドバイスは、mdadmにプロセスとしてドライブアレイをアクティブに監視させる必要があるということです。これは、次のようなもので実現できます（ただし、正確には同じではありません）。
mdadm --monitor --scan --syslog
上記の行を特定のインストールに合わせて調整する必要があります。
システムを停止する前に、エラーがsyslogに正しく記録されなかったのはなぜですか？システムがsyslogにログを記録しようとしたが、syslogデーモンを停止した後にログを記録した可能性がありますか？もしそうなら、私はそれを防ぐために何ができますか？
ロギングがドロップされる原因となったさまざまな問題があった可能性があります。
まず、syslogが一般的にどのように機能するかという問題全体があります。堅牢で信頼性の高いものにするために何年も費やされてきましたが、データがディスクに到達しない可能性がある特定のエッジケースがあります。これはよく知られた設計上の問題であり、監視スタイルのサービス管理（別名daemontoolsとその同類）で積極的に対処された問題です。そこでの解決策は、syslogを完全にバイパスし、ファイル記述子が常に開いているロガーに出力を書き込むことでした。これにより、何もドロップされず、ロガーは出力をできるだけ速くディスクにダンプします。 100％効果的なソリューションではありませんが、カーネルがパニックになるかシャットダウンする前に、ドライブにイベントが書き込まれる可能性が大幅に向上します。
第2に、カーネルに完全なパニックが発生したか、マシンをコーナーに追いやるようなその他のイベントが発生した可能性があります。障害のあるハードウェアでも問題が発生する可能性があります。PSUの電力が不足しているマシンでは、Windows 8で自発的なシャットダウンが発生します。PSUを交換すると、シャットダウンの問題が恒久的に修正されました。明らかに、nothingカーネルが実行できることは、「これで十分だ」と判断し、リブートランドにたどり着いたマシンから保護します。
何が起こったのかを知るために何ができますか？または、何が起こったのかを今すぐ知る方法がない場合、次回より良い事後分析ができるように、ロギングと通知を改善するにはどうすればよいですか？
いくつかのアプローチがあります：
ロギングを別のパーティションに配置します。これは完全なログを取得することを保証するものではありませんが、disk-full-ca n-t-write、再マウントを読み取り専用にする破損など、ファイルシステムの問題を切り分けるのに役立ちます。特定の場合。
リモートロギングの重要なシステム情報を見てください。繰り返しになりますが、これは保証ではありませんが、最後のパケットが再起動が発生する前に「ドアから出て行く」ことができ、そのパケットに再起動が発生した理由の重要な手がかりがある場合に役立ちます。
特定の重要なサービスについては、syslogへの出力を、専用のロガーが出力をインターセプトしてできるだけ早くディスクに書き込む監視スタイルのロギングなど、別のものに置き換えることを検討してください。これにより、出力の信頼性が高まり、ストレージに送られます。少しの作業で、他のサービス管理の取り決めと並べて共存させることができます。
ディスクが突然同期しなくなる原因は何ですか？
ドライブ障害、コントローラー障害、その他のハードウェア障害。いくつかのあいまいなソフトウェアの問題。
メールで通知されなかったのはなぜですか？
Ubuntuにはcronjobがあります/etc/cron.d/mdadmこれにより、RAIDボリュームは1日1回00:57にチェックされます。その時点でシステムに問題がなかった場合、またはそれまでにすでに障害が発生していた場合は、メッセージを送信する方法がありませんでした。
システムを停止する前に、エラーがsyslogに正しく記録されなかったのはなぜですか？
ドライブに障害が発生している場合、ドライブに書き込もうとしても意味がありません。それ以上書き込むと、残っているものがすべて破棄される可能性があるためです。障害の正確な性質がわからない場合は、ボリュームまたはファイルシステムが読み取り専用になっている可能性があります。デフォルトでは、Ubuntuは、ルートボリュームにエラーがある場合に読み取り専用ファイルシステムに切り替えるように設定されています。
次回より良い事後分析ができるように、ロギングと通知を改善するにはどうすればよいですか？
リモートsyslogホストへのログを設定します。そうすれば、ストレージ障害は何もログに記録できないことを意味しません。