Pandora: Documentation ja: Anexo Volumetría

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

1 キャパシティ分析

1.1 概要

Pandora FMS は、正しく設定しないとボトルネックになりうる複数の要素がある複雑なアプリケーションです。ここでは、特定のキャパシティを得るための必要条件を知るために、特定のパラメータに関する Pandora FMS のスケーラビリティの詳細を見ていきます。

最初は、クラスタを使ったシステムを対象にしたロードテストです。データベースクラスタの中に一つの Pandora サーバがあります。ロードテストは、サーバ一台ごとの最大のキャパシティを見るのに便利です。現在(バージョン 3.0以降)のアーキテクチャでは、N台の個別のサーバと一つのメタコンソールでスケーラビリティはリニアに伸びますが、一台のサーバではそうはなりません。(次のグラフに示します。)

1.1.1 データストレージと圧縮

実際に Pandora は、リアルタイムでデータを圧縮しています。これは、保存されるデータ量を計算するためにはとても重要です。最初に、データの保存方法に関して従来のシステムと Pandora FMS の "非同期" のデータ保存方法の違いについてみてみます。以下に図を示します。

従来のシステム

チェックを一日平均20実施すると、1年で 5MB の容量が必要です。エージェントあたり 50チェックでは、1年 250MB になります。

従来とは異なる Pandora FMS のような非同期システム

チェックにおいて 1日平均 0.1の状態変化では、1年で 12.3KBの容量になります。エージェントあたり 50チェックでは、1年で 615KB です。

1.1.2 用語の定義

次に、より理解を深められるように、ここで使われている用語について説明します。

• 情報の断片化: Pandora FMS が扱う情報によりパフォーマンスは変化します。情報には、常に変化するもの(CPUの使用率など)や、固定(あるサービスの状態など)のものがあります。Pandora FMS は、これらをデータベースに圧縮して保存します。これはパフォーマンスおよびキャパシティに対して重要な要素となります。そこで、より断片化し、データベースにたくさん保存し、処理量を増やすことが、同じ情報を処理するために必要となります。
• モジュール: モニタリングにおいて情報を収集する基本的な単位です。いくつかの環境では、イベントでもあります。
• 間隔: 一つのモジュールで情報を収集する時間間隔です。
• アラート: データがしきい値を越えたり状態が障害状態や警告状態になったときに、Pandora FMS が実行する通知です。

1.2 容量考察の例

1.2.1 これまでの考察と対象範囲

次の 3種類のパターンで設定を行う場合を考えてみます。

• ステージ1: 500エージェントでの設定
• ステージ2: 3000エージェントでの設定
• ステージ3: 6000エージェントでの設定

このデータ量において、正しく Pandora FMS の要求スペックを決めるためには、どのような種類のモニタリングをする予定であるかを知る必要があります。次の例では、"QUASAR TECNOLOGIES" という架空の会社の特徴を示しています。

• 90% のモニタリングをソフトウエアエージェントで実施。
• 技術/ポリシーでグループ化できる似たようなシステムがある。
• モニタするモジュールやイベント間で、実行間隔が異なる。
• 大量の非同期情報がある(イベントやログなど)。
• あまり変化がない状態を確認する処理がたくさんある。
• 全体的にパフォーマンスに関する情報は少ない。

すべての技術的な内容とその実装に関する調査(システムとそのモニタ方法の確認)の結果、次のような結論に至ります。

• 1システムあたり、平均して 40個のモジュールやイベントが存在する。
• 平均モニタリング間隔は、1200秒(20分)である。
• 5分ごとに情報を送ってくるモジュールもあれば、1週間に一度だけのモジュールもある。
• 全グループの全モジュール (240,000) のうち、確認のたびに変更が発生する可能性があるのは 25% である。
• モジュールごとのアラート比率は 1.3 (モジュール/イベントごとに 1.3 アラート) である。
• アラートの発生率は、1% と仮定する。(これは我々の経験上の予測です)

この結論は、予測を策定するための基本となります。理解しやすいように Excel シートにまとめてみます。

これらの初期データに対して必要な計算をあてはめます。データベースのサイズおよび、モニタリングに必要となる一秒間あたりのモジュール実行数、その他パラメータを予測できます。

1.2.2 キャパシティの考察

それぞれのフェーズで実装のための基本的な要求事項 (秒あたりのモジュール実行数)、アラートの数、日ごとのモジュール実行数、月ごとの容量がわかったら、本番に近いシステムで実際にサーバの負荷テストを行います。(ここでのテストは、本番に近いシステムでは実行できていません。)

これらの負荷テストでは、Pandora FMS の処理能力がわかり、どの程度で性能劣化するかがわかります。これは、次のような目的において便利です。

1. 対象のハードウエアで最大どれくらいの規模まで対応できるかを推定する場合。
2. ストレージの限界および、ヒストリー DB へ情報を移すポイントを知りたい場合。
3. サービス停止や計画停止により、処理する情報がたまった場合の最大処理量に対する余裕を知りたい場合。
4. モニタ対象の情報の変化率が変わった場合のパフォーマンスに与える影響を知りたい場合。
5. 大量のアラート処理の影響を知りたい場合。

テストは、Intel Core Duo プロセッサ 2.5GHz および、メモリ 2GB を積んだ DELL のサーバ PowerEdge T100 にて実施しました。このサーバでは、Ubuntu Server 8.04 が動いており、HA 環境のテストに使っています。テストは、QUASAR TECHNOLOGIES プロジェクトに似たエージェント設定で実施しました。同じハードウエアではありませんが、同じような HA 環境で、WUASAR TECHNOLOGIES と似たパフォーマンスの影響および大量のデータを扱うことによるその他問題(主に利便性)を評価できる環境です。

得られた結果はとても良く、システムは非常に過負荷にもかかわらず、非常に興味深い情報量を処理することができました(180,000モジュール、6000エージェント、120,000アラート）。これから得られた結論は次の通りです。

1. リアルタイムの情報は、最大 15日間でヒストリーデータベースへ移動させるべきである。一週間より古いデータを動かすことがベストです。これにより、より早い動作が保障されます。

2. 情報量を考慮して、処理の余裕は想定能力よりも高い最大能力の 50% ほどである。

3 システムを構築する場合のパフォーマンスと必要な容量を決定するには、データの細分化の割合がとても重要である。