Home
コマンドセンター(メタコンソール)
コマンドセンター
Pandora FMS バージョン 756 から、中央管理モードの環境における同期システムを一から再設計し、これまでの手動同期を必要とせずに変更がノードに自動的に複製されるようになったため、より高速で効率的になりました。
この変更により、以前のシステムは古いシステムと見なされるため、それが有効だった環境では、新しい中央管理システムを利用しかつ データの整合性を保証できるように するために、以前のシステムを自動マージするシステムを利用する必要があります。
更新時に、すでに中央管理化されているすべてのコマンドセンター環境は、再び正しく中央管理できるように、中央管理(Centralised management) の新たな マージツール(Merging tool) を通るように強制されます。
マージ処理では、コマンドセンターで構成済みの、無効になっていない ノードのみが考慮されます。
マージツールは、ノードデータベースとコマンドセンター (コマンドセンターから管理されるもの) のさまざまな要素を次のようにマージします。コマンドセンターに登録されているノード間で優先順位が確立され、最も優先度の高い項目がリストの先頭に、最も優先度の低い項目が末尾に配置されます。
例:
この優先順位リストは、同じ要素が異なるノードに存在するが、設定が異なる場合に使用されます。
監視ポリシーの場合、ポリシーのモジュール、アラート、その他の要素は、ポリシーの個別の独立した要素と見なされますが、同様にマージされます。
モジュールのみの場合の例:
マージツールによって一元化される要素
次の要素は、新しいマージツールから一元化される要素です。
- ユーザ: コマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じID を持つユーザは同じユーザと見なされます(前述の優先ルールに従います)。
- ユーザプロファイル: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つユーザは同じユーザと見なされます(前述の優先ルールに従います)。
- エージェントグループ: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。
- マージツールから統合することにより、同じ名前を持つものは同じグループからのものと見なされます(前述の優先ルールに従います)。
- ファイルコレクション: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ短い名前を持つものは同じコレクションと見なされます(前述の優先ルールに従います)。
- アラートテンプレート: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じテンプレートと見なされます(前述の優先ルールに従います)。
- アラートコマンド: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じコマンドと見なされます(前述の優先ルールに従います)。
- アラートアクション: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じアクションと見なされます(前述の優先ルールに従います)。
- サーバプラグイン : それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前と実行ファイルを持つものは同じプラグインと見なされます(前述の優先ルールに従います)。
- OS: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じOS と見なされます(前述の優先ルールに従います)。
- モジュールタグ: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前を持つものは同じタグと見なされます(前述の優先ルールに従います)。
- モジュールカテゴリ: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前を持つものは同じカテゴリと見なされます(前述の優先ルールに従います)。
- モジュールグループ: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前を持つものは同じグループと見なされます(前述の優先ルールに従います)。
- コンポーネントグループ: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前を持つものは同じグループと見なされます(前述の優先ルールに従います)。
- ネットワークコンポーネント: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前とOS を持つものは同じコンポーネントと見なされます(前述の優先ルールに従います)。
- ローカルコンポーネント: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前とOS を持つものは同じコンポーネントと見なされます(前述の優先ルールに従います)。
- コンポーネントテンプレート: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じテンプレートと見なされます(前述の優先ルールに従います)。
- インベントリモジュール: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前とOS を持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
- 監視ポリシー: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じポリシーと見なされます(前述の優先ルールに従います)。
- ポリシーモジュール: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前のポリシー内で同じ名前のモジュールを持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
- ポリシーインベントリモジュール: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前のポリシー内で同じ名前のモジュールと OS を持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
- ポリシープラグイン : それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前のポリシー内で同じ実行ファイルを持つものは同じプラグインと見なされます(前述の優先ルールに従います)。
- ポリシーコレクション: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前のポリシー内で同じ短い名前を持つものは同じコレクションと見なされます(前述の優先ルールに従います)。
- アラートとポリシー外部アラート: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前のポリシー内の同じモジュール名に同じテンプレートを持つものは同じアラートと見なされます(前述の優先ルールに従います)。
- アラートおよびポリシー外部アラートのアクション: れらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前のポリシー内の同じモジュール名の同じテンプレート上の同じ名前を持つものは、同じアクションと見なされます(前述の優先ルールに従います)。
- ポリシー内エージェント: それらはコマンドセンターからのみ管理されます。ノード管理は無効になります。マージツールからら統合することにより、同じ名前のポリシー内の同じ名前のエージェントは、同じポリシー内のエージェントと見なされます。(アプリケーションの動作に関わる)コマンドセンターポリシー内のエージェントログは破棄され、ノードログは考慮されません。
- エージェント: コマンドセンターから実行する必要がある削除を除いて、ノードでのエージェント管理が許可されます。
マージツールから統合した後、サーバ設定ファイル pandora_server.conf のパラメーター autocreate_group を有効なグループIDで調整してください。
上記すべてをまとめたもの:
以下の要素は、上記の 優先順位ルール に従って、マージツールを使用してコマンドセンターによって集中管理されます。
| 要素 | ID | プロファイル | 名前 | グループ | Ex.1) | OS |
| ユーザ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| ユーザプロファイル | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| エージェントグループ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| ファイルコレクション | ❌ | ❌ | ✅ 2) | ❌ | ❌ | ❌ |
| アラートテンプレート | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| アラートコマンド | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| 警告アクション | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| サーバプラグイン | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ |
| OS | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| モジュールラベル | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| モジュールカテゴリ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| モジュールグループ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| コンポーネントグループ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| ネットワークコンポーネント | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
| ローカルコンポーネント | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
| コンポーネントテンプレート | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| インベントリモジュール | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
| 監視ポリシー | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| ポリシーモジュール | ❌ | ❌ | ✅ 3) | ❌ | ❌ | ❌ |
| インベントリモジュール ポリシー | ❌ | ❌ | ✅ 4) | ❌ | ❌ | ✅ |
| ポリシープラグイン | ❌ | ❌ | ✅ 5) | ❌ | ✅ 6) | ❌ |
| ポリシーコレクション | ❌ | ❌ | ✅ 7) | ❌ | ❌ | ❌ |
| アラートと外部アラート ポリシーアラート | ❌ | ❌ | ✅ 8) | ❌ | ❌ | ❌ |
| アラートのアクション および外部アラート | ❌ | ❌ | ✅ 9) | ❌ | ❌ | ❌ |
| ポリシー内の エージェント | ❌ | ❌ | ✅ 10) | ❌ | ❌ | ❌ |
| エージェント 11) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
これらの要素が中央管理されているセクションは、コマンドセンターからのみ管理できます。ノードからこれらの要素にアクセスする場合、リスト表示のみが可能で、編集および作成オプションは表示されません。環境が中央管理モードであることを示す警告も表示され、管理者がこれらの要素を設定するための対応するコマンドセンターセクションへのリンクがあります。
マージツールで使われているデータベーステーブル
次のテーブルは、マージツールにおいてコマンドセンターとノード間で同期されます。
- tgroup
- tcollection
- tplugin
- tconfig_os
- ttag
- tcategory
- tmodule_group
- tnetwork_component_group
- tnetwork_component
- tlocal_component
- tnetwork_profile
- tmodule_inventory
- talert_commands
- talert_actions
- talert_templates
- talert_calendar
- talert_special_days
- tprofile
- tuser
- tuser_profile
- tpolicies
- tpolicy_modules
- tpolicy_modules_inventory
- tpolicy_plugins
- tpolicy_collections
- tpolicy_alerts
- tpolicy_alerts_actions
- tautoconfig
- tautoconfig_rules
- tautoconfig_actions
- tpolicy_agents
マージツールによるデータベースマージを起動するための前提条件
- コマンドセンターは、すべてのデータベースとすべてのノード API に接続できる必要があります。“コンソールのセットアップ” の設定が正しく、インジケーターが緑色であることを確認してください。
- ノードコンソールは、コマンドセンターデータベースに接続できる必要があります。 Pandora FMS サーバとは別のマシンにコンソールがあるような場合でなければ、通常、これは問題にはなりません。
- ノード上で 管理(Management) → セットアップ(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.iniのmemory_limitに-1の設定が必要です。つまり、無制限です。ただしマージプロセスのみ です。 終了後、以前の値に戻すことをお勧めします。これは、ノードのマージに大量のメモリが使用され、非常に大規模な環境(多くの異なる要素がある)では大量のメモリを使用できるようにシステムが使用可能なすべてのメモリを確実に使用できるようにするためです。 マージされるアイテムがサーバで使用可能な物理メモリの値を超えると、予期しないエラーが原因でマージツールが失敗し、コンソール/Apache ログに、メモリ超過が発生したことを示す行が表示されます。 - すべてのノードでは、
php.iniのpost_max_sizeの値は、コマンドセンター のupload_max_file_sizeより大きいか等しい必要があります。この値は、存在する最大のファイルコレクションサイズと少なくとも同じ大きさである必要があります。 - すべてのノードでは、
php.iniのupload_max_filesizeの値は、コマンドセンター の同じパラメータより大きいか等しい必要があります。 - すべてのノードでは、
php.iniのpost_max_sizeの値は、コマンドセンター における同じパラメータより大きいか同じ必要があります。この値は、存在する最大のファイルコレクションサイズと少なくとも同じ大きさである必要があります。また、ノードとコマンドセンターの両方で、このパラメーターの値がupload_max_filesizeの値以上である必要があります。 - すべてのノードとコマンドセンターは、データベースとコレクションのバックアップを実行できるように、“attachment ディレクトリが存在するディスクに十分な空きがある必要があります。
- すべてのノードとコマンドセンターでは、コンピューターの日付と時刻が正しく設定されている必要があります(NTPサーバの使用をお勧めします)。
これらの要件がすべて満たされていない場合、ノードはマージされず、エラーが返されます。 エラー結果を確認すると、満たされていない条件に関するメッセージを確認できます。
データベースのマージが完了したら、設定ファイル php.ini に対応する memory_limit の値を再設定することが重要です。 変更を有効にするには、Apache httpd サービスを再起動する必要があることに注意してください。
マージツールを起動する前の推奨事項
データベース統合プロセスの必須条件ではありませんが、次の処理も実行することをお勧めします。
- 処理全体を通してで、すべてのノードの pandora_server とコマンドセンターを停止します。グループなどの重要な要素が変更されるため、それらの ID が変更されることがありあす。また、処理中は、環境にアクセスするような処理を動かすことはお勧めしません。 ただし、ほとんどの場合、実行中のサーバは問題にはなりません。
- サーバと同じ理由で、処理中は、
pandora_dbプロセスを cron から一時的に停止します。
マージ処理が開始されると、ノードとコマンドセンターの両方がメンテナンスモードになります。 これの目的は、サーバと pandora_db を停止して、ユーザが処理中に要素を変更してエラーや不整合を引き起こすことを防ぐためです。
マージ処理の実行
マージ処理には 2つの段階があり、コマンドセンターから管理できるさまざまな要素を同期する最初の段階と、イベント内の情報を一元化された要素内で更新する 2番目の段階があります。 この処理は、コンソールができるだけ早く再びアクセスできるようにするためのものです。イベントの更新は、通常、より多くの情報を扱うため、最も時間がかかる可能性がある処理であるためです。 両方のステージは、2つの進捗バーで区別され、さらに 2つのサブステージに分割されます。
ステージ 1 要素
このステージでは、コマンドセンターから管理できるすべてのノードのデータベースで要素の同期が行われます。 それ自体がマージ処理であり、2つのサブステージに細分され、それぞれに独自の進捗バーがあります。
- 初期化: すべての要件をチェックし、(要件が満たされている場合は)処理のいずれかの部分が失敗した場合に対応するバックアップを生成し、メモリ内でデータベースをマージした結果を生成します。この処理が何らかの理由で失敗した場合、データベースはまだ変更されていないため、バックアップを復元する必要はありません。 バックアップは、各ノード/コマンドセンターの次のディレクトリに保存されます:
/attachment/merge_backups - 適用: 前の初期化段階が成功した場合、統合の結果はすべてのノードとコマンドセンターに適用され始めます。このプロセスは優先度の高い順に実行されるため、1つが終了すると、次のプロセスが開始されます。
この処理中にエラーが発生した場合(たとえば、データベースとの接続が失われた場合)、プロセス自体が生成されたバックアップの復元を試みます(復元の進行状況を示す 3番目の赤い進行状況バーが表示されます)。 失敗の理由によりバックアップのリカバリができない場合は、手動でリカバリを実行する必要があります。
障害の原因によってバックアップのリカバリが妨げられている場合、リカバリは手動で実行する必要があります。
- 同期が中止された場合:
コマンドセンターとノードのデータベース間の接続がしばらく失われたり、十分なディスク容量がないためにバックアップを作成できなかったりするなど、予期しない障害が発生する場合があります。そのため、表示されるエラーメッセージは一般的なものになる可能性があります。その場合にサポートが必要であれば、Pandora FMS サポートチームに連絡して支援を受けてください。
ステージ 2: イベント更新
このステージでは、イベント内のさまざまな同期要素への参照情報が更新されます(たとえばグループごとに)。 ステージは、メインデータベースのイベントの更新とヒストリデータベースのイベントの更新に細分され、マージ処理を開始する前に存在していたイベントにのみ影響します。環境を一元化した後に新しく生成されたイベントには、すべての正しい参照情報が含まれているため、更新する必要はありません。
- メインデータベース: CA イベントは大量の情報であり、影響も受けます。この更新処理は、すでにマージされた環境の通常の操作と並行して行われます。 この時点で、サーバと pandora_db を正常に再起動でき、標準ユーザはコンソールに再度アクセスできます。 もちろん、イベント表示では、すべてのイベントの更新処理バーが表示されますが、マージ前に存在していたイベントについてのみ（フィルターなどに関して）不整合が発生する可能性があります。 新しいイベントは通常どおり生成されます。 このステージと処理は、コンソールの cron の特定のタスクを介して、各ノードによって起動されます。 情報量が多いため、それは重くて時間のかかる作業になる可能性があります。可能な限り、環境の負荷が少ないタイミングがよいでしょう。
- ヒストリデータベース: これは上記の続きであり、すでに示したのと同じようにヒストリデータベース内のイベントを更新します。
マージツールを通してすでに一元化された環境
ステージ1が終了すると、環境は一元化されていると見なされ、そこ時点よりコマンドセンターからすべてを管理できるようになります。要素の同期も変更され、各ノードの pandora_ha プロセスがデータベースとコマンドセンターのデータベースの同期を担当するようになります。
コマンドセンターで変更を加えると(たとえば、ユーザを作成すると)、ノードデータベースへの必要なクエリ(INSERTS, UPDATES など)がキューに入れられます。それは順番に server_threshold ごとに pandora_ha によって読み取られ実行されます。 これにより、サーバがしばらくダウンした場合でも、サーバを再起動したときに正しく追いつくことができます。
この保留中のクエリのリストは、コマンドセンターのコンソールセットアップから確認できます。 何らかの理由でクエリが失敗した場合、ノードは残りのクエリを続行せず、コンソールセットアップにエラーが表示され、管理者が手動で処理する必要があります。ほとんどの場合、マージツールでマージ処理を再度起動することで修正できるはずです。
新たなノードを含める
集中管理環境に新しいノードを追加するには、コマンドセンターで セットアップ(Setup) → メタセットアップ(Metasetup) → コンソールセットアップ(Consoles setup) に移動し、新しいノード(New node) ボタンをクリックします。接続を確立し保存するにはすべてのフィールドに入力する必要があります。データがない完全に新しいノードの場合は 空のノードを登録(Register empty node) ボタンで追加し、それ以外の場合は マージするデータを含むノードを登録(Register node with data to merge) ボタンを使用する必要があります。
- 空のノードを登録(Register empty node) ボタンを使用すると、ノード内のデータが削除されることを示す警告ウィンドウが表示されます。
確認し OK をクリックすると、新しいノードが集中管理化されます。
- マージするデータを含むノードを登録(Register node with data to merge) ボタンを使用すると、既存のノードのデータが一元化されることを示す確認ウィンドウが表示されます。
