コマンドセンター

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

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

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

更新時に、すでに中央管理化されているすべてのメタコンソール環境は、再び正しく中央管理できるように、中央管理(Centralised management) の新たな マージツール(Merging tool) を通るように強制されます。

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

例:

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

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

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

マージツールの結果は次のようになります。

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

次の要素は、新しいマージツールから一元化される要素です。

• ユーザ: メタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ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.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サーバの使用をお勧めします)。

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

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

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

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

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

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

• 同期が中止された場合:

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

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

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

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

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

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

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

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