生産性とスタンバイの2つのノードを備えたフェイルオーバー構成でペースメーカー/ corosyncha-clusterをセットアップしました。 3つのDRBDパーティションがあります。これまでのところ、すべて正常に動作しています。
両方のノードでNagiosNRPEを使用して、レポートおよび視覚化ツールとしてicinga2を使用してサーバーを監視しています。フェイルオーバースイッチができるまでスタンバイノードのDRBDパーティションがマウントされないため、次のような重大な警告が常に表示されます。
したがって、これは誤った警告です。私はすでにDISABLE_SVC_CHECKに出くわし、それを実装しようとしました。次に例を示します。
echo "[`date +%s`] DISABLE_SVC_CHECK;$Host_name;$service_name" >> "/var/run/icinga2/cmd/icinga2.cmd"
NagiosまたはIcinga2のスタンバイノードでDRBDのこのチェックを無効にする簡単な方法/ベストプラクティスはありませんか?もちろん、フェイルオーバー後のスタンバイに対してこのチェックを有効にしたいです。
ホストでこれを直接監視しないことをお勧めします。私たちの環境では、Pacemakerを使用してフェイルオーバーを自動化します。 Pacemakerが私たちのために行うことの1つは、フェイルオーバー時にIPアドレスを移動することです。これにより、クライアントが常にプライマリを指していることが保証され、フェイルオーバーがクライアント側から透過的に見えるようになります。
Nagiosの場合、各ホストで多数のサービスを監視して監視しますが、仮想/フローティングIPアドレス用に構成された追加の「ホスト」を使用して、プライマリでのみ実行されているDRBDデバイスとサービスを監視します。
私の環境では、drbdデバイス(従来のlxcコンテナー、dockerコンテナー、データベースなど)上で実行される複数のサービスを管理しています。無料でオープンソースであり、自動フェイルオーバー機能を提供するopensvcスタック( https://www.opensvc.com )を使用します。以下は、drbdとredisアプリケーション(例では無効になっています)を使用したテストサービスです。
最初にクラスターレベルで、 svcmon
出力で次のことを確認できます。
サービスレベルで svcmgr -s servdrbd print status
、私たちは見ることができます:
問題をシミュレートするために、セカンダリノードのdrbdデバイスを切断すると、次のようになります 警告
サービスの可用性ステータスがまだupであることを確認することが重要ですが、全体的なサービスステータスはwarnに低下します、「OK、本番環境はまだ正常に動作していますが、問題が発生しています。ご覧ください」
すべてのopensvcコマンドをjson出力セレクターで使用できることに気づいたらすぐに( nodemgr daemon status --format json
または svcmgr -s servdrbd print status --format json
)、それをNRPEスクリプトにプラグインするのは簡単で、サービスの状態を監視するだけです。ご覧のとおり、プライマリまたはセカンダリの問題はすべてトラップされます。
nodemgr daemon status
は、すべてのクラスターノードで同じ出力であり、すべてのopensvcサービス情報が1回のコマンド呼び出しで表示されるため優れています。
このセットアップのサービス構成ファイルに興味がある場合は、Pastebinに投稿しました ここ
check_multi を使用して、両方のDRBDチェックを単一のNagiosチェックとして実行し、正確に1つの場合にOKを返すように構成できます。サブチェックはOKです。
ただし、チェックを添付するホストも決定する必要がある場合は注意が必要です。 VIPを使用してホストにアタッチするか、両方のホストにチェックをアタッチし、それぞれでNRPE/sshを使用して他方をチェックするなどの方法があります。