IcingaDistributed-ステータスマップ/到達可能性の問題
分散型Icingaセットアップを次のようにセットアップしています。 6つのサイトがあるので、2つのノードと中央サーバーのそれぞれで3つを監視しています。
サイトa、b、cはノード1によってアクティブに監視されています
サイトd、e、fはノード2によってアクティブに監視されています
ノード1と2は、パッシブチェックを中央サーバーに送信します
私が直面している問題は、予想どおり、中央サーバーがここでマスターサーバーになることを目的としていることです。このため、ネットワーク全体の到達可能性を理解する必要があります。方法がわからないのは、ステータスマップ上で2つのノードのホストをリンクして、到達可能性を確保することです。以下の例：
Icinga（中央ノード）はUbuntuで実行されていますVMサイト（a）のvSphereサーバー上）中央ノードからサイト（d）にアクセスするには、論理パスはvSphereで構成されます。サーバー、スイッチ、別のスイッチ、そしてルーター。このルーターはサイト（d）の別のルーターに接続し、次に切り替えて、最終的にはホストになります。
私の問題は、ノード2（この場合はサイト（d）のルーター）のホストをノード2に存在しない親（到達可能性の「親」はルーターである必要があります）を持つように設定できないことです。サイト（a））。
これは...説明するのが非常に困難でした。これを回避する方法はありますか？重複が中央サーバーによって無視され、ノードによって使用されるが役に立たないことを期待して、ノード2でサイト（a）ルーターを再度宣言しようとしました。各サイトがIcingaインスタンスを非論理的に生成するだけでなく、中央のステータスマップを論理的に表示できるようにしたいと思います。
私は実際にこれがほとんど私自身の方法論の問題であると考えました。私が試した解決策は、私が行っていた方法ではなく、機能します。
ルーターをノード1と中央に定義し、正しい親を使用します
親のないノード2でルーターを定義します
このようにして、単一のIcingaインスタンスが重複を認識せず、中央サーバーがそれを正しく処理するようになりました。