Pandora: Documentation ja: Services

From Pandora FMS Wiki
Jump to: navigation, search

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

1 サービスモニタリング

1.1 概要

1.1.1 サービスモニタリングの概念

サービスは、機能に基づいて IT リソースをグループ化する手法です。例えば、サービスは、公式ウェブサイト、CRM システム、アプリケーション、または、プリンタなどです。サービスは、ホストやルータ、スイッチ、ファイアーウォール、CRM、ERP、ウェブやその他サービスの論理的なグループです。以下の例で、サービスとは何かをより明確にします。

Chip Company は、ウェブサイトを通してコンピュータを世界中に販売しています。オンラインショップ、サポート、および管理の 3つの大きな部門があります。

Chip-departments.png

ご覧の通り、オンラインショップ、サポート、直接ではありませんが管理の 3つのサービスが顧客に提供されています。すべてのサービスは、どれか一つが機能しなくなると他に影響が出て会社としての機会損失を発生させるため、ビジネスに重要です。最終的には、満足した顧客は、他の顧客を連れてきます。

Chip Company のサービスをモニタするには、それぞれのサービスの詳細をより知る必要があります。

オンラインショップ部門は、ショップのウェブサイトが稼働し、買い物がしやすいように、すべての製品の価格が正しい状態であること、製品の分類をし製品の情報を提供すること、配送および支払い方法を正しく示すことに責任があります。このサービスでは、次のようなパラメータをモニタリングしたいと考えます。

Operation-detail.png

サポート部門は、顧客が買ったコンピュータに関する全ての問題解決を行います。この部門の業務は、顧客のコンピュータ設定に対するヘルプ、返品されたコンピュータの交換などです。この部門は、オンラインショップと連携し、顧客サイドのサービスを行っています。そのため、高品質な会社であると認識してもらうためにとても重要です。サポートサービスでは、次のようなパラメータをモニタリングしたいと考えます。

Support-service-detail.png

3番目の部門は、マーケティング、広報など、その他内部管理を目的とした管理部門です。彼らの主な業務は、組織におけるすべてのプロセスが正しいかを見ることです。この部門のサービスは、すべての部門のとりまとめであるため、とても重要です。管理サービスのためのパラメータは次の通りです。

Management-detail.png

サービスをモニタするために、Pandora FMS ビジュアルコンソールで Chip Company のサービス構造を説明した画像を使ってマップを作成します。これらのマップは、リアルタイムで更新されるため、常にサービスの状態を知ることができます。最初に作成するマップは、それぞれのサービスのマップです。

次の画像は、それぞれのパラメータのステータスを含むオンラインショップサービスのマップを示しています。ご覧の通り、Content Updated というパラメータが赤くなっています。これは、そこに問題があることを意味しています。他のパラメータは、緑表示になっているため問題が無いといえます。緑の矢印をクリックすると、全体のビューに行くことができます。次のステップで示します。

Screen-onlineshop-detail.png

どんな問題が発生しているかを知りたい場合は、赤いアイコンをクリックします。すると、問題に関してより詳細を知ることができる、技術的な表示を見ることができます。この表示では、Pandora FMS が CRM、ERP、SAP サーバ、データベース (MySQL、Oracle など)、その他サーバやルータ、PC といったデバイスなど多くのソースから収集したデータが示されています。

Agent-detail.png

また、以下に示すようなサポートサービスのマップも作成します。ご覧の通り、サポートサービスの重要なパラメータが表示され、すべてが緑で問題無いことを示しています。

Screen-support-detail.png

最後に、次に示すような管理サービスのマップを作成します。こちらもまた、重要なパラメータが表示され、すべてが緑で問題無いことを示しています。

Screen-management-detail.png

さらに、全てのサービスの全体のマップを作成します。次の画像に示します。このマップでは、Chip Company のそれぞれのサービス状態と構造を見ることができます。また、それぞれのアイコンをクリックすると、それぞれのサービスマップを見ることができます。それぞれのサービスの状態は、それぞれのサービスのマップで見たものと同じで、管理およびサポートサービスには問題がありませんが、オンラインショップサービスには問題が発生しています。ご覧の通り、サービスの状態が構造的にトップまで影響しています。

Screen-chip-overview.png

1.2 Pandora FMS におけるサービス

1.2.1 Pandora FMS でのサービスの動作

Pandora FMS でのサービスのモニタリングは、ある特定の値だけのモニタリングではなく、異なる種類の要素グループのモニタによる複数の障害情報に基づいて実現します。

サービスモニタリングどのように構成されるのか理解しやすいように、例を示します。

我々は、サービスとしてのウェブクラスタが正常かどうかをモニタしたいとします。 このクラスタは、以下の要素から構成されます。

  • HA 構成の 2つのルータ
  • HA 構成の 2つのスイッチ
  • 20 の apache サーバ
  • 4つの Weblogic アプライアンスサーバ
  • 2つのストレージノードと 2つの SQL プロセスノードから成る 1つの MySQL クラスタ

それぞれの要素は個別にモニタリング可能です。実際、最初にサービスモニタリングを有効にする必要がありますが、サービスに含まれるそれぞれの要素は、Pandora で個別にモニタします。これは、サービスモニタリングの前に設定することです。

サービスモニタリングの概念として必要なこととして、このような疑問がでてきます。例えば、20 の apache サーバのうちの一つなど、一つの項目が障害状態だったとしても、全体としては障害では無いのではないだろうか。実際に、よくダウンするとしても 20ノードあるので警告でもないのではないだろうか。1ノードのダウンに対して警告は発するべきではありません (警告が 寝てる誰かを起こすことを考えてください)。実際、サービスは冗長化されており、より安全になっており、緊急作業は不要です。よりクリティカルな要素 (ルータなど) がダウンしたときや、4,5台の複数のウェブサーバダウンしたときに警告を発するべきです。

次のように、それぞれの要素に "ウエイト" を付与します。

  • スイッチおよびルータ: 個々の障害状態の時は 5ポイント、警告状態の時は 3ポイント
  • ウェブサーバ: 個々の障害状態の場合は 1.2 ポイント、警告状態はポイント無し
  • WebLogic サーバ: 個々の障害状態の場合は 2ポイント
  • MySQL クラスタ: それぞれのノードに 5ポイント、警告状態で 3ポイント

サービスを警告状態と判断する閾値を 4、障害状態と判断する閾値を 6 とします。すべてのモニタリング要素が正常であれば、サービスも正常です。

1台の apache サーバダウンが発生した場合は次のようになります。

  • 1 x 障害状態の Apache サーバ x 1.2 ポイント = 1.2 となり、ここで、1.2 < 4 (警告) であるため、サービスの状態はまだ正常です。

ウェブサーバと Weblogic サーバがダウンすると次のようになります。

  • 1 x 障害状態の apache サーバ x 1.2 ポイント = 1.2
  • 1 x 障害状態の Weblogic サーバ x 2 = 2

合計すると 3.2 となり、まだ < 4 です。そのため、サービスの状態はまだ正常です。オペレータが起きる必要はありません。

2台のウェブサーバと、1台の Weblogic サーバがダウンすると次のようになります。

  • 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4
  • 1 x 障害状態の Weblogic サーバ x 2 = 2

この場合、4.4 > 4 となり、サービスが警告状態になります。オペレータはまだ緊急の SMS を受信しませんが、少なくとも誰かがメールを受け取ります。引き続き例を見ていきましょう。

上記の状態に加え、1台のルータがダウンすると次のようになります。

  • 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4
  • 1 x 障害状態の Weblogic サーバ x 2 = 2
  • 1 x 障害状態のルータ x 5 = 5

合計ポイントは 9.4 となり、障害状態の閾値である 8 を越えています。サービスは障害状態となり、オペレータは起きることになります。

サービスモニタリングは、エンタープライズ版の Pandora FMS のみにある機能です。

1.2.1.1 シンプルモードの動作

監視要件が基本的な内容の場合、ウエイトシステムは複雑すぎるかもしれません。このような状況に対応するために、バージョン 5.1 からはサービス設定に新たなシンプルモードがあります。

このモードでは、どの要素が障害でどれがそうでないかを選択する設定をするだけです。障害の要素のみがサービスの状態の計算に使われ、障害要素の 障害 状態のみが値を持ちます。障害要素の 50% が障害状態になると、サービスは警告状態になります。障害要素の 50% を超えて障害状態になると、サービスは障害状態となります。

シンプルサービスの例を見てみましょう。

  • 障害要素としてのルータ
  • 非障害要素としてのプリンタ
  • 障害要素としての apache サーバ

あるとき、要素が次の状態になります。

  • ルータが障害
  • プリンタが障害
  • apache サーバが警告

サービスの状態は警告になります。なぜならプリンタは障害要素ではなく状態の計算には利用されません。また、apache サーバは障害要素ですが、障害状態の場合のみ計算に利用されます。この場合、一つの障害要素が障害状態であり、障害要素の 50% となります。

別のタイミングで、要素が次の状態になったとします。

  • ルータが障害
  • プリンタが障害
  • apache サーバが障害

障害要素の 50% を超えて障害状態となるため、サービスの状態は障害になります。

最後に、次の状態になったとします。

  • ルータが正常
  • プリンタが障害
  • apache が正常

障害要素の 50% 未満が障害状態なので、サービスの状態は正常になります。プリンタのみ障害状態ですが、障害要素ではないのでサービスの状態計算には含まれません。おそらく、これに関しては誰も対応しません。

1.2.2 新たなサービスの作成

1.2.2.1 Pandora FMS バージョン 5 以降

サービスは、以下を表すことができます。

  • モジュール
  • エージェント
  • 他のサービス

サービスの値は、予測モジュールのデフォルト間隔で予想サーバを使って計算されます。

それぞれのサービスには、作成したサービスをモニタするのに必要な全てのモジュール、エージェント、サブサービスを追加することができます。例えば、オンラインショップをモニタしたい場合、それに関連するモジュール、通信などをモニタするサブサービスなどが必要です。

新たなサービスを作成するには、操作メニューのサービスタブをクリックし、作成ボタンをクリックします。

Pandora 6.0 の場合: 新たなサービスを作成するには、トポロジマップ(Toipology Maps) タブでサービス(Services) をクリックし、サービスの作成(Create Service) ボタンをクリックします。

Menu services.png

定義済みのサービス一覧が表示されます。以下はサービス定義が無い例です。

Services empty v5.png

新たなサービスを作成するには、作成ボタンをクリックし、以下に示す画面に表示されるフォームに入力します。

Services creation v5.png
New service2.png

フィールドの意味は次の通りです。

  • 名前(Name): サービス名。
  • 説明(Description): サービスの説明。
  • グループ(Group): サービスのグループ。組織分けと SLA の条件設定に便利です。
  • モード(Mode): 要素のウエイトの計算モードです。
    • 手動(Manual): サービスとその要素に手動でウエイトを入れます。
    • 自動(Auto): サービスの障害閾値は 1、警告閾値は 0.5です。また、いつでもサービスの要素を作成することができ、正常状態の場合のウエイトは 0、警告状態は 0.1、障害状態は 1 が自動的に割り当てられます。
    • シンプル(Simple): ウエイトを入力する必要がありません。チェックボックスで障害要素とするかどうかを有効化・無効化するだけです。
  • 障害(Critical): 障害状態のウエイト閾値です。自動計算が有効の場合デフォルトで 1 となり、このフィールドは無効です。
  • 警告(Warning): 警告状態のウエイト閾値です。自動計算が有効の場合デフォルトで 0.5 となり、このフィールドは無効です。
  • データ保存エージェント(Agent to store data): サービスモジュールを持つエージェントです。サービスは、特別なモジュール(予測モジュール)にデータを保存します。なぜなら、データを保存するモジュールおよび、サービスのアラート設定のために、エージェントが必要だからです。
  • SLA 間隔(S.L.A. Interval): SLA 計算を行う時間間隔です。デフォルト値は 1ヶ月です。
  • SLA 制限(S.L.A. limit): SLA が正常状態の閾値です。
  • 警告サービスアラート(Warning Service alert): サービスが警告状態になった場合に利用するアラートテンプレートです。
  • 障害サービスアラート(Critical Service alert): サービスが障害状態になった場合に利用するアラートテンプレートです。
  • SLA 障害サービスアラート(S.L.A. critical service alert): SLA 条件が満たされない場合にアラートを発生させるためにサービスが利用するアラートテンプレートです。

ノードを追加するには、'要素設定(Config elements)' タブへ行きます。

Services tab setup v5.png

次のような画面が表示されます。ここで、サービス要素を管理(編集、追加、削除)することができます。

Services elements empty v5.png

サービス設定ページでの重要なアイテムは次の通りです。

  • タイプ(Type): モジュールまたはエージェント。エージェントサービスは全モジュールで動作します。
  • エージェント(Agent): エージェントの検索入力です。要素タイプがエージェントまたはモジュールの場合のみ表示されます。
  • モジュール(Module): 検索で選択したエージェントのモジュールのドロップダウンリストです。これは、モジュールタイプでサービス要素を編集または作成するときのみ表示されます。
  • サービス(Service): アイテムを作成するためのサービス一覧のドロップダウンリストです。アイテム作成またはサービスタイプ編集の場合のみ表示されます。ドロップダウンリストに表示されるサービスは、すべてが依存サービスではないことに注意する必要があります。サービス間の依存関係はツリー表示で見る必要があります。
  • 障害(Critical): 障害要素かどうかを選択するチェックボックスです。サービスがシンプルモードの場合のみ表示されます。
  • 障害ウエイト(weight on critical): 障害状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 1 で操作できません。
  • 警告ウエイト(wight on warning): 警告状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0.5 で操作できません。
  • 不明ウエイト(Weight on Unknown): 不明状態の場合の要素のウエイトです。デフォルト値は '0' です。サービスが自動計算モードの場合は無効化されています。サービスがシンプルモードの場合は表示されません。
  • 正常ウエイト(weight on "OK"): 正常状態の場合の要素のウエイトで、自動計算が設定されている場合は、デフォルトは 0 で操作できません。

このページでサービスアイテムを作成すると、次のような画面で一覧が表示されます。

Services list elements admin v5.png
1.2.2.1.1 サービス設定時に作成されるモジュール
  • SLA Value Service: SLA を満たすパーセンテージです。(async_data)
  • Service_SLA_Service: これは、SLA を満たしているかどうかを表示します。(async_proc)
  • Service_Service: このモジュールはサービスのウエイトの合計を表示します。(async_proc)

1.2.3 サービス表示

1.2.3.1 Pandora FMS 5 およびそれ以上のバージョン

これ以降のバージョンでは、サービスを表示する複数の方法があります。ツリー表示と一覧表示で、サービスの状態の見方を選択できます。

1.2.3.1.1 全サービスの一覧表示

ユーザが参照可能(アクセス制御があります)なサービス一覧です。

この表示をするには、操作(Operation)メニュー >> モニタリング(Monitorization) >> サービス(Services) へ行きます。

Services list services admin v5.png

それぞれの行がサービスで、カラムは次の通りです。

  • 名前(Name): サービス名。
  • 説明(Description): サービスの説明。
  • グループ(Group): サービスが所属するグループのアイコン。
  • 障害(Critical): サービスが障害状態になるウエイトの合計の閾値。
  • 警告(Warning): サービスが警告状態になるウエイトの合計の閾値。
  • 値(Value): サービスのウエイトの合計値。
  • 状態(Status): サービスの状態を表現するアイコン。以下の 4種類があります。
    • : 障害閾値を超え、サービスが障害状態にある場合。
    • 黄色: 警告閾値を超え、サービスが警告状態にある場合。
    • : サービスが正常状態の場合。
    • グレー: サービスが不明状態の場合。これは、サービスが作成されたばかりでモジュールを含んでない場合または、予測サーバがダウンしている場合です。
  • SLA: サービス SLA の現在の値。とりうる値は次の通りです。
    • OK: SLA サービスで定義された間隔で SLA の条件に適合している場合。
    • INCORRECTO: SLA サービスで定義された間隔で SLA の条件に適合していない場合。
    • N/A: 計算のための十分なデータが無く、SLA が不明状態の場合。
1.2.3.1.2 サービスとその要素の一覧表示

この表示をするには、全サービス表示でサービス名をクリックするか、サービス名の近くの虫眼鏡アイコンをクリックします。

Services list elements operation v5.png

2つのパートに分かれており、前述の表示と同じカラムと、以下に示すサービスの要素一覧のカラムがあります。

  • タイプ(Type): 要素のタイプを表すアイコン。モジュールを表すレゴブロック、エージェントを表す積み重なったレゴブロック、サービスのネットワークダイアグラムアイコンです。
  • 名前(Name): モジュール / エージェント / サービスの名前を含んだテキストです。それぞれのセクションへのリンクもあります。
  • 説明(Description): 説明のテキストです。
  • 障害ウエイト(Weight critical): 要素が障害状態の合計値です。
  • 警告ウエイト(Weight warning): 要素が警告状態の合計値です。
  • 正常ウエイト(Weight normal): 要素が正常状態の合計値です。
  • データ(Data): エレメントの値で、次のいずれかです。
    • モジュール(Module) モジュールの値。
    • エージェント(Agents) エージェントの状態を表すテキスト。
    • サービス(Service) 選択したサービスの要素の全ウエイトの合計。
  • 状態(Status) 要素の状態を色とともに表すアイコン。

Template warning.png

サービス要素の計算は、予測サーバによって実施されることに注意してください。リアルタイムのデータではありません。また、サービスにエージェントが追加された場合、サービスのウエイトは、計算が再実行されるまで更新されないことに注意してください。

 


1.2.3.1.3 サービスマップ表示

この表示をするには、次の画面に示すサービス操作画面のヘッダーのタブをクリックします。

Services tab servicemap v5.png

ここでは、次の画面のようにサービスをツリー構造で表示します。これにより、サービスがどのような要素で構成されているかを一目で素早く確認することができます。

Services servicemap v5.png

ノードの種類は次の通りです。

  • モジュールノード(Module node) ハートビートアイコンで表示されます。このノードは常に末端です。
  • エージェントノード(Agent node) CPU ボックスアイコンで表示されます。このモジュールは常に末端です。
  • サービスノード(Service node) ハンマーとスパナアイコンで表示されます。他のノードを含む必要があります。

ノードの色とそれぞれがサービスに接続している線は、ノードの状態に依存します。

ノード内は次の通りです。

  • タイトル(Title) サービス / エージェント / モジュールノードの名前。
  • 値一覧(Value list)
    • 障害(Critical): 障害状態になるウエイトの合計です。ルートサービスノードの場合は、障害状態になる閾値を表します。
    • 警告(Warning): 警告状態になるウエイトの合計です。ルートサービスノードの場合は、警告状態になる閾値を表します。
    • 正常(Normal): 正常状態になるウエイトの合計です。ルートサービスノードの場合は何も表示しません。
    • 不明(Unknown): 不明状態。ルートサービスノードの場合は、不明状態になる閾値を表します。

ツリー内の各ノードはクリックすることができ、ノードの操作画面へのリンクになっています。

Info.png

サービスのモードがシンプルの場合、赤い ! マークが障害要素の右に表示されます。

 


1.2.3.1.4 ビジュアルコンソールでのサービス

Pandora FMS バージョン 5 以降では、マップ内の他のアイテムのように、ビジュアルコンソールにサービスを追加することができます。

Services visualmap v5.png

マップ上にサービスを作成するには、ビジュアルマップの他のアイテムと同じように操作します。

Services visualmap add item v5.png

次の設定があります。

  • ラベル(Label): ビジュアルコンソールノードに表示するタイトル。
  • サービス(Service): 表示するサービス。

サービスのどは、他のビジュアルマップへはリンクできないことに注意してください。リンクは、サービスツリー表示になります。

1.2.4 サービスの値の読み方

計画停止をあとから追加することにより、SLA レポートの値を再計算することができます。最初に設定画面で有効化する必要があります。サービスの要素に影響する計画停止がある場合、SLA レポートでは、計画停止が全体のサービスに影響があったものと認識します。なぜなら、システムは、サービス全体における無効化したサービスコンポーネントの影響を評価できないためです。

あとから設定した計画停止に基づいて変更されないレポートレベル、サービスマップ、ビジュアルコンソールでの表示情報は注目に値します。これらのサービス提供状況のパーセンテージは、同じサービスの過去のデータをもとにリアルタイムで計算されます。ダミーの計画停止を設定した場合と比べてレポートは大きく異なります。

一方で、サービスの順守状況の計算方法を知ることも重要です。

1時間 (実際の場合ではとても短いですが内部アルゴリズムを理解するには良いです) で 95% の稼働率として定義したサービスがあると仮定します。値を表示にして、t が時間、x が(SLAの)パーセンテージ、そして s がサービスが維持できているかどうか(1:正常,0:異常)です。1時間のうちに、5分間隔で 12個の値を取得します。

この場合、最初の 11サンプル(最初の 55分)ではサービスを満たしており、60分のときに満たせずに次のようになったとします。

   t    |   s   |    x  
--------+-------+--------
1          1      100
2          1      100
3          1      100
4          1      100
5          1      100
6          1      100
7          1      100
8          1      100
9          1      100
10         1      100
11         1      100
12         0      91,6

この場合は計算は簡単です。パーセンテージはサンプル数に依存して計算されます。たとえば、t 3 ではサービスを満たすトータル 3つのサンプルがあり 100% です。t 12 では、12 サンプル中満たしているのが 11 なので、11 / 12 です。

途中で問題が発生したと仮定すると、ゆっくり復旧します。

   t    |   s   |    x  
--------+-------+--------
1          1      100
2          1      100
3          1      100
4          1      100
5          1      100
6          0      83,3
7          1      85,7
8          1      87,5
9          1      88,8
10         1      90 
11         1      90,9
12         1      91,6

これまでのシナリオに似ていますが、その後時間が進んでいくとどうなるか見てみましょう。

   t    |   s   |    x  
--------+-------+--------
13        1      91,6
14        1      91,6
15        1      91,6
16        1      91,6
17        1      91,6
18        1      100
19        1      100
....

直感的ではない動作が見られます。なぜなら、t 18 までの間に正常なサンプルの数は 11 あり、異常な値は範囲外になっています。そのため、t 18 では 100% になります。91.6 と 100 の間の差は、対象範囲の大きさで決まります。範囲が大きいと(通常 SLA の計算間隔は日次、週次、月次です)差は急ではなくなります。

1.2.5 サービスグループ

サービスは、ビジネスの構造の一部を表す論理的なグループです。そのために、グループのサービスを表すのに理にかなっています。なぜなら、依存関係がある多くの状態で、例えば個々のサービス(ウェブページ、通信など)から構成される企業全体のサービスを表すからです。サービスをグループ化するには、全体の一つのサービスを作成し、論理的なツリー構造で個々のサービスを全体のサービスとしてまとめる必要があります。

サービスグループは、ビジュアルマップの作成、アラート設定、監視ポリシーなどの設定の手助けをしてくれます。営業部門が動けない状態であったり Web ページが停止しているために、企業としてのサービスが止まっている場合に、特定のアラートを設定することができます。

次に、サービスグループを理解するための 2つの例を示します。

1.2.6 サービス監視の例

1.2.6.1 PandoraFMS サービス

ここでは、PandoraFMS のサービスを監視します。これは、Apache、MySQL、Pandora サーバおよび、Tentacle サーバから構成されます。これらの要素全てがまた、異なるコンポーネントのサービスで構成され、ツリー構造を作ります。

Arbol.JPG

一般的な Pandora のサービスは、ウエイトが 2になると障害状態になり、1 であれば警告状態になります。 ご覧のとおり、4つのコンポーネントが Pandora サービスで異なるウエイトを持っています。

  • MySQL: Pandora サービスにとってクリティカルで、MySQL がダウンしたらウエイトは 2です。警告状態の場合は、ウエイトは 1で、Pandora サービスで黄色の状態表示となります。
  • Pandora Server: Pandora サービスにとってクリティカルで、Pandora サーバがダウンしたらウエイトは 2 です。警告状態の場合のウエイトは 1 で、たとえば CPU のロードが上がった場合に Pandora サービスが警告状態を表示します。
  • Apache: Pandora サービス全体としてはデグレード状態で、完全に止まっているわけではありません。ダウンした場合のウエイトは 1 で、Pandora サービスは警告状態になります。
  • Tentacle: Apache の場合と同じで、Pandora サービス全体としてはデグレード状態で、完全に止まっているわけではありません。ダウンした場合のウエイトは 1 で、警告状態となります。

次の画面では、Pandora サービスにおける要素ごとに異なるウエイトの設定を見ることができます。

Pesos.JPG


1.2.6.2 ストレージクラスタ、サービスのグルーピング

サービスは、企業のビジネス構造の一部を論理的なグループで表現したものです。そのため、サービスのグループを正しく作成する必要があるでしょう。なぜなら、サービス単体では適切な内容を持たないことがあるからです。サービスグループを作成するには、それぞれのサービスを既存のエージェントに追加する必要があります。この場合、サービスはエージェントのモジュールになります。新たな論理的な構造(サービスのグループ)を、これらのグループごとに作成することができます。

次の例では、HA ストレージクラスタがあります。この場合、2つのファイルサーバシステムが並行して稼働しており、それぞれが特定の部署にサービスを提供するために、いくつかの異なるディスクを制御しています。グループ化したサービスでツリー構造を作ります。

Cluster.JPG

この構造では、ストレージサービスが障害状態になるのは、双方のファイルサーバが障害になったときのみです。これはサービス全体が提供できません。もし一方のファイルサーバが障害の場合は、サービスとしてはデグレードという想定です。 以下の画面では、ストレージサービスの 2つのメインの要素のウエイト設定が見られます。

Pesoscluster.JPG

以下の画面では、グループ化したサービス FS01 のウエイト設定を見ることができます。ここでは、要素の状態に応じた特定のウエイトが設定されています。

  • FS01 ALIVE: FS01 サービスの障害ポイントです。1つ目のディスククラスタに割り当てられた仮想 IP です。ダウンした場合のウエイトは 2 で、他の要素は機能しなくなります。この場合、警告の閾値はなく、情報としては OK か NG かです。
  • DHCPserver ping: FS01 サービスの障害ポイントです。ウエイトは 2 を指定しています。これには、警告の閾値はありません。
  • Disks 障害状態の場合のウエイトは 1 で、警告状態では 0.5 です。これにより、2つのディスクが障害状態となった場合または 4つのディスクが警告状態になった場合に、FS01 サービスが障害状態になります。
Pesosfs01.JPG

1.3 Pandora サーバ

予測サーバが起動しており、Pandora FMS Enterprise 版がインストールされていることが必須です。