コマンドセンター

コマンドセンター

Pandora FMS バージョン 756 から、中央管理モードの環境における同期システムを一から再設計し、これまでの手動同期を必要とせずに変更がノードに自動的に複製されるようになったため、より高速で効率的になりました。

この変更により、以前のシステムは古いシステムと見なされるため、それが有効だった環境では、新しい中央管理システムを利用しかつ データの整合性を保証できるように するために、以前のシステムを自動マージするシステムを利用する必要があります。

更新時に、すでに中央管理化されているすべてのメタコンソール環境は、再び正しく中央管理できるように、新しい コマンドセンター を通るように強制されます。

コマンドセンターは、ノードデータベースとメタコンソールデータベース(メタコンソールから管理する必要があるデータベース)のさまざまな要素を次のようにマージします。優先順位は、メタコンソールのノードとメタコンソール自体の間で確立され、優先度が最も高い要素がリストの一番上に配置され、優先度が低い要素が一番下に配置されます。

例:


メタコンソールで設定された無効化されていないノードのみがマージ処理で考慮されます。

この優先順位リストは、同じ要素が異なるノードに存在するが、設定が異なる場合に使用されます。 たとえば、2つのノードとメタコンソールにグループ “Databases” があるとします。 この優先順位では、メタコンソールの例では、すべてに対して最も優先度の高い要素の設定が採用されます。

別のケースでは、たとえばノード 1 と 2 のみに “Windows” というポリシーがある場合、すべてのノードとメタコンソールにおいて、そのポリシーの設定はノード 1 の設定になります(メタコンソールにはそれがないためスキップします)。


ポリシー自体の設定(グループ、説明など)の場合のみ、モジュール、アラート、およびその他のポリシー要素は、ポリシーとは独立した別個の要素と見なされるため、同様にマージされます。

ポリシーの場合は、そのの設定方法により、同期されるすべての要素の中で最も特殊なものになります。なぜなら、すべてのモジュール、アラート、プラグイン… が独立した要素として扱われ、次の場合はモジュールでのみ表示されるためです。


コマンドセンターの結果は次のようになります。

これにより、結果として可能な限り多くの異なる構成を設定できるため、メタコンソールからそれらを管理できるようになります。

コマンドセンターによって一元化される要素

次の要素は、新しいコマンドセンターから一元化される要素です。

  • ユーザ: メタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じID を持つユーザは同じユーザと見なされます(前述の優先ルールに従います)。
  • ユーザプロファイル: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前を持つユーザは同じユーザと見なされます(前述の優先ルールに従います)。
  • エージェントグループ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。
  • コマンドセンターから統合することにより、同じ名前を持つものは同じグループからのものと見なされます(前述の優先ルールに従います)。

コマンドセンターから統合した後、サーバ設定ファイル pandora_server.conf のパラメーター autocreate_group を有効なグループIDで調整してください。

  • ファイルコレクション: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ短い名前を持つものは同じコレクションと見なされます(前述の優先ルールに従います)。
  • エージェントテンプレート: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前を持つものは同じテンプレートと見なされます(前述の優先ルールに従います)。
  • アラートコマンド: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前を持つものは同じコマンドと見なされます(前述の優先ルールに従います)。
  • アラートアクション: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前を持つものは同じアクションと見なされます(前述の優先ルールに従います)。
  • サーバプラグイン : それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前と実行ファイルを持つものは同じプラグインと見なされます(前述の優先ルールに従います)。
  • OS: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前を持つものは同じOS と見なされます(前述の優先ルールに従います)。
  • モジュールタグ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 コマンドセンターから統合することにより、同じ名前を持つものは同じタグと見なされます(前述の優先ルールに従います)。
  • モジュールカテゴリ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 コマンドセンターから統合することにより、同じ名前を持つものは同じカテゴリと見なされます(前述の優先ルールに従います)。
  • モジュールグループ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 コマンドセンターから統合することにより、同じ名前を持つものは同じグループと見なされます(前述の優先ルールに従います)。
  • コンポーネントグループ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 コマンドセンターから統合することにより、同じ名前を持つものは同じグループと見なされます(前述の優先ルールに従います)。
  • ネットワークコンポーネント: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 コマンドセンターから統合することにより、同じ名前とOS を持つものは同じコンポーネントと見なされます(前述の優先ルールに従います)。
  • ローカルコンポーネント: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前とOS を持つものは同じコンポーネントと見なされます(前述の優先ルールに従います)。
  • コンポーネントテンプレート: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前を持つものは同じテンプレートと見なされます(前述の優先ルールに従います)。
  • インベントリモジュール: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 コマンドセンターから統合することにより、同じ名前とOS を持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
  • 監視ポリシー: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前を持つものは同じポリシーと見なされます(前述の優先ルールに従います)。
  • ポリシーモジュール: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前のポリシー内で同じ名前のモジュールを持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
  • ポリシーインベントリモジュール: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 コマンドセンターから統合することにより、同じ名前のポリシー内で同じ名前のモジュールと OS を持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
  • ポリシープラグイン : それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 コマンドセンターから統合することにより、同じ名前のポリシー内で同じ実行ファイルを持つものは同じプラグインと見なされます(前述の優先ルールに従います)。
  • ポリシーコレクション: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前のポリシー内で同じ短い名前を持つものは同じコレクションと見なされます(前述の優先ルールに従います)。
  • アラートとポリシー外部アラート: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前のポリシー内の同じモジュール名に同じテンプレートを持つものは同じアラートと見なされます(前述の優先ルールに従います)。
  • アラートおよびポリシー外部アラートのアクション: れらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前のポリシー内の同じモジュール名の同じテンプレート上の同じ名前を持つものは、同じアクションと見なされます(前述の優先ルールに従います)。
  • ポリシー内エージェント: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。コマンドセンターから統合することにより、同じ名前のポリシー内の同じ名前のエージェントは、同じポリシー内のエージェントと見なされます。(アプリケーションの動作に関わる)メタコンソールポリシー内のエージェントログは破棄され、ノードログは考慮されません。
  • エージェント: メタコンソールから実行する必要がある削除を除いて、ノードでのエージェント管理が許可されます。

これらの一元管理される要素はメタコンソールからのみ管理できます。ノードからこれらの要素にアクセスする場合は、それらを一覧表示するだけで、編集および作成オプションは表示されなくなります。 また、環境が中央管理モードになっていることを示す警告と、要素の設定に対応するメタコンソールでの管理画面へのリンクがあります。

コマンドセンターによるデータベースマージを起動するための前提条件

  • メタコンソールは、すべてのデータベースとすべてのノード API接続できる必要があります。“コンソールのセットアップ” の設定が正しく、インジケーターが緑色であることを確認してください。

  • ノードコンソールは、メタコンソールデータベースに接続できる必要があります。 Pandora FMS サーバとは別のマシンにコンソールがあるような場合でなければ、通常、これは問題にはなりません。ノード上で セットアップ(Setup)Enterprise のメタコンソール設定パラメーターが正しいことを確認してください。

  • 全ノードのサーバは、メタコンソールAPI接続できる必要があります。メタコンソールで公開 URL を設定することをお勧めします。

  • ノードサーバは、“pandora_server.conf” で正しいAPI設定や、コンソールのセットアップでの公開URL設定が必要です。
console_api_url http://localhost/pandora_console/include/api.php
console_api_pass pandora

  • それぞれのノードは、それ自身のヒストリデータベースへの接続ができる必要があります。

  • すべてのノードとメタコンソールは同じバージョンである必要があります。
  • すべてのノードとメタコンソールは同じMRである必要があります。

  • すべてのノードとメタコンソールには、セットアップにて同じ最大コレクションサイズを設定する必要があります。

  • エラーを回避するには、メタコンソールおよびノード設定ファイル php.inimemory_limit-1 の設定が必要です。つまり、無制限です。ただしマージプロセスのみ です。 終了後、以前の値に戻すことをお勧めします。これは、ノードのマージに大量のメモリが使用され、非常に大規模な環境(多くの異なる要素がある)では大量のメモリを使用できるようにシステムが使用可能なすべてのメモリを確実に使用できるようにするためです。 マージされるアイテムがサーバで使用可能な物理メモリの値を超えると、予期しないエラーが原因でコマンドセンターが失敗し、コンソール/Apache ログに、メモリ超過が発生したことを示す行が表示されます。
  • すべてのノードとメタコンソールでは、php.inipost_max_size の値は、upload_max_file_size より大きいか等しい必要があります。
  • すべてのノードとメタコンソールは、データベースとコレクションのバックアップを実行できるように、“attachment ディレクトリが存在するディスクに十分な空きがある必要があります。

  • すべてのノードとメタコンソールでは、コンピューターの日付と時刻が正しく設定されている必要があります(NTPサーバの使用をお勧めします)。


これらの要件がすべて満たされていない場合、ノードはマージされず、エラーが返されます。 エラー結果を確認すると、満たされていない条件に関するメッセージを確認できます。

データベースのマージが完了したら、設定ファイル php.ini に対応する memory_limit の値を再設定することが重要です。 変更を有効にするには、 Apache httpd サービスを再起動する必要があることに注意してください。

コマンドセンターを起動する前の推奨事項

データベース統合プロセスの必須条件ではありませんが、次の処理も実行することをお勧めします。

  • 処理全体を通してで、すべてのノードの pandora_server とメタコンソールを停止します。グループなどの重要な要素が変更されるため、それらの ID が変更されることがありあす。また、処理中は、環境にアクセスするような処理を動かすことはお勧めしません。 ただし、ほとんどの場合、実行中のサーバは問題にはなりません。
  • サーバと同じ理由で、処理中は、cron pandora_db プロセスを一時的に停止します。

マージ処理が開始されると、ノードとメタコンソールの両方がメンテナンスモードになります。 これの目的は、サーバーと pandora_db を停止して、ユーザが処理中に要素を変更してエラーや不整合を引き起こすことを防ぐためです。

マージ処理の実行

マージ処理には 2つの段階があり、メタコンソールから管理できるさまざまな要素を同期する最初の段階と、イベント内の情報を一元化された要素内で更新する 2番目の段階があります。 この処理は、コンソールができるだけ早く再びアクセスできるようにするためのものです。イベントの更新は、通常、より多くの情報を扱うため、最も時間がかかる可能性がある処理であるためです。 両方のステージは、2つの進捗バーで区別され、さらに 2つのサブステージに分割されます。

ステージ 1 要素

このステージでは、メタコンソールから管理できるすべてのノードのデータベースで要素の同期が行われます。 それ自体がマージ処理であり、2つのサブステージに細分され、それぞれに独自の進捗バーがあります。

  • 初期化: すべての要件をチェックし、(要件が満たされている場合は)処理のいずれかの部分が失敗した場合に対応するバックアップを生成し、メモリ内でデータベースをマージした結果を生成します。この処理が何らかの理由で失敗した場合、データベースはまだ変更されていないため、バックアップを復元する必要はありません。 バックアップは、各ノード/メタコンソールの次のディレクトリに保存されます: /attachment/merge_backups
  • 適用: 前の初期化段階が成功した場合、統合の結果はすべてのノードとメタコンソールに適用され始めます。このプロセスは優先度の高い順に実行されるため、1つが終了すると、次のプロセスが開始されます。

この処理中にエラーが発生した場合(たとえば、データベースとの接続が失われた場合)、プロセス自体が生成されたバックアップの復元を試みます(復元の進行状況を示す 3番目の赤い進行状況バーが表示されます)。 失敗の理由によりバックアップのリカバリができない場合は、手動でリカバリを実行する必要があります。


障害の原因によってバックアップのリカバリが妨げられている場合、リカバリは手動で実行する必要があります。



メタコンソールとノードのデータベース間の接続がしばらく失われたり、十分なディスク容量がないためにバックアップを作成できなかったりするなど、予期しない障害が発生する場合があります。そのため、表示されるエラーメッセージは一般的なものになる可能性があります。その場合にサポートが必要であれば、Pandora FMS サポートチームに連絡して支援を受けてください。

ステージ 2: イベント更新

このステージでは、イベント内のさまざまな同期要素への参照情報が更新されます(たとえばグループごとに)。 ステージは、メインデータベースのイベントの更新とヒストリデータベースのイベントの更新に細分され、マージ処理を開始する前に存在していたイベントにのみ影響します。環境を一元化した後に新しく生成されたイベントには、すべての正しい参照情報が含まれているため、更新する必要はありません。

  • メインデータベース: CA イベントは大量の情報であり、影響も受けます。この更新処理は、すでにマージされた環境の通常の操作と並行して行われます。 この時点で、サーバと pandora_db を正常に再起動でき、標準ユーザはコンソールに再度アクセスできます。 もちろん、イベント表示では、すべてのイベントの更新処理バーが表示されますが、マージ前に存在していたイベントについてのみ(フィルターなどに関して)不整合が発生する可能性があります。 新しいイベントは通常どおり生成されます。 このステージと処理は、コンソールの cron の特定のタスクを介して、各ノードによって起動されます。 情報量が多いため、それは重くて時間のかかる作業になる可能性があります。可能な限り、環境の負荷が少ないタイミングがよいでしょう(Pandora FMS に負荷がかかっていない時間に起動してみてください)。
  • ヒストリデータベース: これは上記の続きであり、すでに示したのと同じようにヒストリデータベース内のイベントを更新します。

コマンドセンターを通してすでに一元化された環境

ステージ1が終了すると、環境は一元化されていると見なされ、そこ時点よりメタコンソールからすべてを管理できるようになります。要素の同期も変更され、各ノードの pandora_ha プロセスがデータベースとメタコンソールのデータベースの同期を担当するようになります。

メタコンソールで変更を加えると(たとえば、ユーザを作成すると)、ノードデータベースへの必要なクエリ(INSERTS, UPDATES など)がキューに入れられます。それは順番に server_threshold ごとに pandora_ha によって読み取られ実行されます。 これにより、サーバがしばらくダウンした場合でも、サーバを再起動したときに正しく追いつくことができます。

この保留中のクエリのリストは、メタコンソールのコンソールセットアップから確認できます。 何らかの理由でクエリが失敗した場合、ノードは残りのクエリを続行せず、コンソールセットアップにエラーが表示され、管理者が手動で処理する必要があります。ほとんどの場合、コマンドセンターでマージ処理を再度起動することで修正できるはずです。

新たなノードを含める

すでに一元化されている環境で、新しいノードを追加したり、編集したり、マージから除外された既存のノードを再度有効にしたりする場合は、コマンドセンター を再度実行する必要があります。

管理者にこのタスクを実行するよう警告するメッセージが表示されます。 未実行の間は、ノードはマージ保留中状態で、ロックされてアクセスできない状態のままになります。 加えられた変更はそれに割り当てられないか、マージ処理が完了するまでコンソールにアクセスできます。


マージ処理のバグを修正するためにコンソールで変更を加える必要がある場合(OUM の適用など)は、ノード一覧からアイテムを削除して、一時的にロックを解除できます。

Pandora FMS ドキュメント一覧に戻る