Pandora: Documentation ja: Architecture

From Pandora FMS Wiki
Jump to: navigation, search

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

Pandora FMS アーキテクチャ

この章では Pandora FMS のコンポーネントの一般的な説明をします。インフラの構成によって異なるさまざまな課題を解決するために、どのように Pandora FMS のアーキテクチャを利用するかです。

Pandora FMS は非常にモジュールに細分化されています。もっとも重要なコンポーネントは MySQL データベースであり、そこにすべての情報が保存されます。それぞれの Pandora FMS コンポーネントは、完全に HA 環境でアクティブ・スタンバイ構成や、クラスタ環境でアクティブ・アクティブの負荷分散構成をとったりと、複数用意することができます。データベースの高可用性を確保する手法もあります。


Arquitectu pando.png
Pandora FMS 全体のアーキテクチャ


Pandora FMS は、複数の要素から構成されており、サーバはデータの収集および処理を行います。サーバはまた、収集し処理したデータをデータベースに保存します。コンソールは、データベース内のデータをインタラクティブにユーザに表示します。ソフトウエアエージェントは、監視対象システム(サーバ)で動作させるアプリケーションで、情報を収集して Pandora FMS サーバへ送ります。

Pandora FMS サーバ


Pandora FMS サーバは、定義されたチェック(監視))を実行するコンポーネントです。実行結果からチェック対象のステータスを更新します。また、アラートの生成を行います。

Pandora FMS のデータサーバは、高可用性やロードバランシングモードで動作することができます。とても大きなシステムにおいて、大量の情報を取り扱うために複数の Pandora FMS サーバを同時に利用できます。

Pandora FMS サーバは常に稼働し、アラートとして定義されているいずれかの項目に問題がないか確認します。もし、問題が発生した場合は、SMS の送信、Eメール送信や、スクリプトの実行など、アラームで定義されたアクションを実行します。

1台がマスターサーバで残りがスレーブサーバといった形で、複数のサーバを同時に利用することもできます。マスターサーバは存在しますが、すべての処理は同じように行われます。同じタイプのクラッシュが発生し(たとえばネットワークサーバ)、マスターサーバがダウンしたサーバのすべてのデータ処理を行う場合を除きます。

サーバは、エージェントからデータファイルを取得するかリモートで情報を取得し、それをアラート生成のトリガーとします。

Pandora FMS は、負荷やパラメータ等を見て、それぞれのサーバの状態を自動的に管理します。ユーザは、ウェブコンソールのサーバステータスで、それぞれのサーバの状態を確認することができます。

Pandora FMS 3.x には、上に示した処理を行うための 10種類の特別なサーバが存在します。10種類すべてのサーバは、一つのアプリケーションとして作られています。一般的に "Pandora サーバ" と呼んでおり、インスタンスや Pandora FMS のサーバごとにサブプロセスを分割して実行するマルチスレッド(マルチプロセス)のアプリケーションとなっています。以下では Pandora FMS の個々のサーバについて詳細の説明をします。

データ(Data)サーバ


ソフトウエアエージェントから送信されるデータを処理します。ソフトウエアエージェントからは、XML データがサーバに送信(FTP, SSH, Tentacle のいずれかのプロトコル)され、サーバはその新たなデータファイルを確認・処理します。このプロセスは、処理するデータを "キュー" として貯めるハードディスク上のディレクトリを利用します。 異なるデータサーバを、異なるシステムや同一のホスト(仮想サーバなど)にインストールすることもできます。複数のサーバは、能力の高いハードウエア(たとえばマルチ CPU の環境など)が必要な巨大な環境において一緒に動作することができます。

データサーバは、Pandora FMS のデータベースにアクセスするためのサーバです。データベースは、ウェブサーバと共有しており多くのデータを保存しています。サーバはデーモンとして実行され、多くのデータを保存します。データサーバは、アラートやイベント生成の元となるすべてのエージェントの情報を処理するので、そのシンプルさとわずかな資源の消費にもかかわらず、システムの中で重要な機能となっています。データサーバは、ソフトウエアエージェントから送られてくる XML データの処理のみを実施します。リモートチェック(監視)などは行いません。

ネットワーク(Network)サーバ


ネットワークサーバは、ICMP テスト(Ping, 応答時間)、TCP および SNMP リクエストなど、リモートモニタリングタスクを実行します。エージェントがサーバに割り当てられるときは、ネットワークサーバに割り当てられ、データサーバには割り当てられません。ネットワークの応答確認はネットワークサーバが実行するため、モニタリング処理はネットワークサーバに割り当てられるということが重要だからです。ネットワークサーバが選択した監視対象に接続できるようにする必要があります。例えば、192.168.2.0/24 上の監視サーバで、192.168.1.1 への ping 疎通確認のモジュールを作成した場合、監視サーバが 192.168.1.0/24 にはアクセスできないため、ダウン状態となります。


Pandora 1.3 Network&DataServer Arch.png

SNMP サーバ (SNMP Trap コンソール)


このサーバは、snmptrapdデーモンが受信したトラップを扱います。このデーモンは SNMP トラップを受信し、Pandora FMS の SNMP サーバはそれをデータベースに保存します。それらを分析して、Pandora FMS の SNMP コンソールにおいて、アラートの定義を行うこともできます。

WMI サーバ


WMI は、Microsoft Windows 環境におけるオペレーティングシステムおよびアプリケーションの情報を取得するための、Microsoft 標準です。Pandora FMS には、ネイティブ WMI 呼び出しを実施するための専用サーバがあります。これにより、リモートからエージェントレスで Windows システムのデータを収集することができます。

自動検出(Recognition)サーバ


自動検出(Recon)サーバは、ネットワーク探索および新たなネットワーク上のシステムを検出するために利用します。自動検出サーバは、システムを検出するためにモニタリングのためのテンプレートを適用することもできます。また、新たなシステムをモニタリングできるように、テンプレートに定義されたデフォルトのモジュールを自動的に適用することもできます。 システムアプリケーションの nmap, xprobe, traceroute を利用して、オペレーティングシステムや開いているポート、すでに認識しているシステムを利用したネットワークトポロジによって、システムを特定することができます。

プラグイン(Plugin)サーバ


任意の言語で独自に開発した監視コマンドを、Pandora FMS のインタフェースから組み込み、統合管理できます。これにより Pandora FMS にユーザ自身が開発した、複雑な監視の仕組みや追加機能を組み込むことができるようになっています。

予測(Prediction)サーバ

これは、これまでに収集したデータ(最大 30日間のデータの 4つの値)を元にしてデータ予測を行う小さな AI (人工知能)のコンポーネントです。10〜15分間隔で数値データの予測を行い、これまでに収集したデータと比較して異常を検出します。基本的に、一週間ごとに動的な基準値を生成します。 このサーバは、Pandora FMS 5.0 からはサービスモニタリング(BPM)の計算も管理します。

ウェブサーバ(Goliat)

(Enterprise版のみ)

ウェブサーバは、ウェブアクセスのテストに利用します。ウェブ全体のチェック、ユーザ認証、フォームへのデータ入力、コンテンツチェック、メニューの確認等、組み合わせのチェックが可能です。応答があるか無いかのチェックおよび、全体(画像、全テキストなど)の表示時間の取得ができます。

エクスポート(Export)サーバ

(Enterprise版のみ)

Pandora FMS のエクスポートサーバは、Pandora FMS のモニタデータを他のサーバにコピーすることができます。これは、複数の Pandora FMS が動作している大きな環境で、重要な情報を一カ所に集めたい場合に便利です。

インベントリ(Inventory)サーバ

(Enterprise版のみ)

インベントリサーバは、インストールされているソフトウエア、インストールされているパッチ、搭載されているメモリチップ、ハードディスク、システムで稼働しているサービスなど、システムのインベントリ情報を収集・可視化することができます。これらの情報は、リモートおよび、ソフトウエアエージェントを通してローカルで取得できます。

イベント関連付(Event correlation)サーバ

(Enterprise版のみ)

イベントの関連付けでアラートを生成できる特別なサーバです。これは他のサーバとは違ってモニタは行わない、起動時に設定する特別なサーバです。このサーバは他のサーバとは違いスレッドや冗長化設定はありません。

エンタープライズネットワーク(Enterprise Network)サーバ SNMP & ICMP 用

(Enterprise版のみ)

オープンソースバージョンよりも高いパフォーマンスで ICMP (ping) および SNMP (ポーリング) を実行するための追加の拡張サーバがあります。(特に SNMPで) いくつかのリクエストは、事前にサーバに該当 OID があるかを確認したうえで実行します。

効率的にブロック単位で監視ができるような、サーバの TCP/IP スタックにアクセスするためのバイナリツールを利用します。

サテライトサーバ

サテライトサーバは特別なサーバで、エージェントとサーバの間の中間でリモート監視を行います。また、自動検出サーバのように新たなシステムを検出し、リモートプラグインを実行します。中央データベースへの接続は必要としません。代わりに、データサーバへ XML データを送信します。より詳細については、サテライトサーバによる分散監視 を参照してください。

Pandora FMS ウェブコンソール


これは、Pandora FMS のユーザインタフェースです。この管理およびオペレーションコンソールは、それぞれのユーザに別の権限を設定することが可能で、エージェントの状態の操作、状態の参照、グラフおよびデータの生成、さらにはシステムに組み込まれているインシデント管理までできます。また、レポートの生成や、新たなモジュール、エージェント、アラートおよび、ユーザの作成やポリシー設定を行うことができます。

ウェブコンソールは PHP で書かれており、Java や ActiveX など他の追加ソフトウエアのインストールを必要としません。また、グラフ表示は FLASH で実現しています。ブラウザには FLASH のプラグインが必要です。ブラウザには、HTML および CSS をサポートした最近のものが必要で、Firefox 2.x または IE 7.x 以上が必要です。これまでの経験によると、IE6 は機能不足であり、Pandora FMS 3.0 のウェブコンソールの機能を正しく利用できません。

ウェブコンソールは複数のサーバで動作させることが可能です。ロードバランシングや配置の問題(巨大なネットワーク、多くの異なるユーザグループ、地理的な違い、管理の違いなど)に対してアクセスを簡単にするように、多くのウェブコンソールを立てることができます。唯一の条件は、Pandora FMS のデータ、つまりデータベースにアクセスできることです。エンタープライズ版の場合は、(NFS経由で)エージェント設定リポジトリにもアクセスできる必要があります。

Pandora FMS データベース


Pandora FMS は、MySQL データベースを利用しています。Pandora FMS は、モニタリング対象から受け取ったすべてのデータを関連付けし、非同期にデータベースに維持します。それぞれのエージェントのデータモジュールは、データをデータブロックとして生成します。それは、実際のシステム内では、情報元として 10万ものデータを扱えるということでもあります。

これらのデータは、データベースの定期的な自動メンテナンスが実行されることで Pandora FMS により自動的に管理されます。そのために、Pandora FMS では、データベース管理者、手動オペレータや管理者を必要としません。一定期間(デフォルトでは 30日)が経過した後にデータを圧縮し、さらにまた一定期間が経過(デフォルトでは 90日)した後にデータを削除します。

Software Agents of Pandora FMS


Pandora FMS のエージェントと言った場合、次の 3つの意味が存在します。

  • エージェント
  • ソフトウエアエージェント (アプリケーションであり、サーバ上で動作する Pandora FMS エージェント)
  • 物理エージェント (ハードウエア)

エージェント

Pandora FMS で単純に「エージェント」と言った場合、それはウェブコンソールで作成したモニタ・管理対象を指します。それは、モジュールのグループ(または個々のモニタリング要素)に関連付けられています。そのため、このエージェントは、(オプションで) 1つ以上の IP アドレスに関連付けることが可能です。

エージェントは、ネットワーク、WMI、プラグイン等のサーバを利用して、リモートモジュールに関連付け可能です。

  • 管理対象が起動しオンライン状態であるかどうかの確認 (PING)
  • 管理対象が起動しオンライン状態であるかどうかの確認 (PING)
  • 特定ポートの応答による、ウェブサイトが稼働しているかどうかの確認
  • 特定ポートおよび期待する応答による、ウェブサイトが稼働しているかどうかの確認
  • SNMP (MIB の利用)経由でのハードウエアの確認
  • 管理対象と Pandora FMS サーバの間の通信遅延の確認

エージェントはまた、ローカルモジュールとの関連付けを持つこともできます。これらはソフトウエアエージェントの設定で定義したり、ウェブコンソールのエージェント設定で定義します。最初にエージェントからデータパケットが送られてきた時、学習モード(デフォルト)であれば、これらのローカルモジュールがウェブコンソール上に自動的に設定されます。 したがって、「エージェント」は、リモートもしくはローカルのいずれかのモジュールを含むことが可能です。リモートモジュールはネットワークサーバ等からリモートで情報を取得し、ローカルモジュールはデータサーバによって情報を取得します。

ソフトウエアエージェント

リモートのマシンにインストールされるソフトウエアエージェントは、Pandora FMS のウェブコンソール上でいうエージェントとは異なります。ソフトウエアエージェントは、それが動作しているマシンの情報をコマンドを実行することによりローカルで取得します。 Pandora FMS のソフトウエアエージェントは、それぞれのプラットホームで動作する言語をベースにしており、UNIX ではシェルスクリプトを利用しています。UNIX には、GNU/Linux, Solaris, AIX, HP-UX および BSD を含みます。また、Nokia の IPSO (Check Point ファイアーウォールのオペレーティングシステム)までも含んでいます。

Pandora FMS のエージェントは、多くの言語で開発することが可能です。Pandora FMS のデータサーバとデータをやりとりする API があります(データのやりとりには XML を用いています)。Windows エージェントは、独特の方式で、C++ (Mingw) および UNIX エージェントと同じインタフェースおよびモジュールによる、フリーの環境で開発しています。



図: Pandora FMS におけるデータ収集

RecoleDatospandora.png

これらのスクリプトはサブモジュールとして作られており、それぞれが情報を収集します。

それぞれのエージェントは、さまざまな情報を収集します。そして、一つの情報を一つのファイルに保存し、それをデータパケットと呼びます。

エージェントからサーバへのデータパケットのコピー処理が定期的に実行されます。余分な情報でデータベースを肥大化させたり、システムに負荷をかけないように、(エージェント側にて)間隔の設定が可能です。

間隔は、デフォルトでは 300(秒)、つまり 5分に設定されています。データベースの負荷上昇など、ホストシステムのパフォーマンスに影響するため、100(秒)未満の値はお勧めしません。

実際、Pandora FMS はリアルタイムシステムではないということを認識しておいてください。リアルタイム性に依存しない環境における、アプリケーションやシステムのモニタリングを目的としたシステムです。

図: エージェントおよび物理エージェントの論理構成

PandoraAgent logical schema.png



パケットの転送は、Tentacle プロトコルにより実行されます。SSH や FTP を利用することも可能です。

ネットワークを通してパスワード無しの非暗号化データが流れるため、SSH を利用して Tentacle を暗号化することも可能です。エージェントとサーバの間の接続においてセキュリティが保証されます。SCP(SSH) および Tentacle プロトコルを用いての自動転送のための、キー生成プロセスは、エージェントとサーバのインストールおよび設定のドキュメントにて詳細を説明しています。

転送はまた、FTP やその他ファイル転送システムにより実行することも可能です。Tentacle は、ユーザが信頼できる等、システムのセキュリティが確保されている場合に選択可能です。

他のプロトコルによる転送設定については、補足ドキュメントを参照ください。

Pandora FMS のエージェントは、それがインストールされたマシンから他のホストにアクセスするようなデータ収集も可能です。これをサテライトエージェントと呼びます。

複数の Pandora FMS エージェントを持つように設定することも可能です。これは、たとえば、ソフトウエアエージェントとサテライトエージェントがあるようなまれなケースです。基本的なソフトウエアエージェントはそれが動作しているマシンをモニタし、サテライトエージェントは、telnet や SNMP その他コマンドにてリモートのシステムをモニタするように設定されます。

XML データファイル

データファイルの書式は次のようになっています。

<ホスト名>.<シリアル番号>.data 

このデータファイルは XML 構造で、ファイル名は、エージェントとしてのホスト名、シリアル番号、データパケットである事を示す .data という拡張子を組み合わせてできています。



図: ソフトエアエージェントのモジュール論理構成

Xml transfer.png
<ホスト名>.<シリアル番号>.checksum

データファイルは、.data という拡張子があります。正当性確認用のファイルは、データファイルの MD5 ハッシュを含んでおり、.checksum という拡張子になっています。

エージェントによって生成される XML データファイルは、Pandora FMS の心臓部です。それには、エージェントが収集した情報が含まれています。このデータパケットは、Pandora FMS エージェントを使う多くのユーザが、独自の開発をしたりデータの生成をして、Pandora FMS へ引き渡すことが簡単にできるように、コンパクトで、柔軟性が高く、軽いデザインになっています。

 <agent data os_name=”SunOS” os_version=”5.8” timestamp=”300” agent_name=”pdges01” version=”1.0”>
 <module>
 <name>FTP Daemon</name>
 <type>generic_proc</type>
 <data>0</data>
 </module>
 <module>
 <name>DiskFree</name>
 <type>generic_data</type>
 <data>5200000</data>
 </module>
 <module>
 <name>UsersConnected</name>
 <type>generic_data_inc</type>
 <data>119</data>
 </module>
 <module>
 <name>LastLogin</name>
 <type>generic_data_string</type>
 <data>slerena</data>
 </module>
 </agent_data>

物理エージェント

Pandora FMS には、Asus のルータおよび、Arduino の自動販売機に組み込まれた、物理エージェントがあります。これらは共にセンサーが組み込まれており、次の状態のモニタリングを実現しています。

  • 湿度
  • 温度
  • 明るさ
  • 物(人)の存在

電気的にセンサーは簡単に調整可能で、その値もまた Pandora FMS で簡単に扱うことができます。 実際、センサーは無線 LAN ルータを介して接続され、スペインのいくつかの商用 DPC (データ処理センター)に展開されています。

トポロジ、スキーマ、監視モデル

モニタリングの処理には、ローカルとリモートの異なるモデルがあります。みなさんが分かりやすく問題解決ができるように、異なるトポロジで共通の例を示します。それぞれのソリューションは以降の章に記載しています。

アクセス可能な監視対象

これは標準的な構成ですが、集中型で体系化されています。これは最も実装が簡単なモデルです。

  • 集中リモート監視 Pandora サーバから全てのリモートシステムにアクセスできることを意味します。
  • エージェントベース監視 Pandora エージェントをインストールした監視対象から Pandora にアクセスできます。

アクセスが制限された監視対象

  • リモート監視対象 これは、Pandora からリモートで確認ができない(通信できない)対象を想定します。ソフトウエアエージェントを、他のシステムをリモートで確認するために利用します。このモードを 'サテライトエージェントモード'(エージェントにてリモートチェックを行う) および 'ブローカーエージェントモード'(一つのエージェントから異なるエージェントとして異なるデータを送信) と呼びます。



ブローカーモードでの直接アクセスができないリモート対象の実装モデル

Broker example no access.png



  • Pandora サーバにアクセスできないソフトウエアエージェント この場合、ソフトウエアエージェントのプロキシ機能を利用します。サーバに直接アクセスできないエージェントがそれを通してアクセスできるようになります。



プロキシエージェントを使ったリモートアクセスの実装モデル

Proxy agent schema.png



  • 異なる対象のリモートモニタリング これは、複数の Pandora サーバがある状況です。同じデータベースに接続して、一つのサーバが事前に定義したテストを行い、もう一方が他のテストを行います。双方のサーバは同じ環境で動作し、コンソールから同時に管理できます。

特別な組織構造

  • 異なる設定の監視システムで、複数の本社を監視する必要性があっとします。この場合、個々の Pandora からのモニタリング情報を複製するエクスポート機能を利用します。



エクスポートサーバを使った階層構造モデル

ES1.png



  • 複数のレポート: 異なる Pandora サーバにデータを送るエージェントを設定することができます。ただし、管理は一つから可能です。
  • 分散管理: 必要な時に別の担当者で監視内容を分散管理する必要がある場合に便利です。これは、構成というより管理が重要です。管理ポリシーの権限設定によって調整します。

大規模環境

  • 数千もの監視項目がある大規模環境では、異なるリモートモニタリング手法を利用します。(50,000以上の)大量の監視項目では、一台のサーバに集約することができません。そのため、異なるサーバをリモート監視を分散するブローカーモードで利用します。



ブローカーモードのエージェントを使ったリモート監視の分散モデル

Broker scalation example.png



プライマリサーバのハードウエアが故障した場合にそなえて、冗長化の設定が必要です。 2つのサーバを用意し、一方が停止したときにアクティブになるように一台はスタンバイ状態にしておきます。そうするにはいくつかの手法があります。

  • 大規模システムの監視と集中管理(2500エージェント以上)が必要な場合、そのためには、'メタコンソール'でまとめた異なる Pandora サーバを設定します。これにより、リニアにシステムを拡張できます。



メタコンソールモデル

Pandora metaconsole overview2.png



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