JP2010073151A - クラスタシステムにおける性能低下の原因箇所の特定方法、クラスタシステム - Google Patents

Abstract

【課題】性能低下を引き起こしている原因箇所を精度良く特定すること。
【解決手段】本発明に係るクラスタシステムにおける性能低下の原因箇所の特定方法は、サービスの提供に必要な複数のリソースにより構成されるクラスタシステムにおける性能低下の原因箇所の特定方法であって、リソースの稼働状況を監視すると共に、当該リソースの性能低下を示唆する性能監視項目を監視するステップ（Ｓ１０１）と、当該監視結果に基づいてリソースの性能低下を判断し、リソース間の影響関係から性能低下の原因であるリソースを特定するステップ（Ｓ１０２）と、を有する。
【選択図】図１

Description

本発明は、クラスタシステムにおける性能低下の原因箇所の特定方法、クラスタシステムに関する。

複数のサーバで構成され、ユーザに提供するサービスの処理性能や可用性を向上させるクラスタシステムと呼ばれるソフトウェア技術が開発されている。クラスタシステムでは、サービスの提供に必要なコンピューティング・リソース（サーバ、アプリケーション、ストレージ・デバイスなど。以下、これらのコンピューティング・リソースを、単にリソースと称することもある。）の状態監視を行い、リソースの障害を感知した場合には、リソースの再起動やサーバ切り替え（フェイルオーバ）などを行うことで、サービスの可用性を向上させている。

例えば、特許文献１には、サービスの負荷状況を判断し、サービスの最適配置を行うクラスタシステムの負荷分散制御方法が開示されている。特許文献１に開示される技術では、サービスの起動又は停止に関する構成変更に際し、必要なリソース量を算定し、算定されたリソース量を必要とするサーバノードについて構成変更の処理のために不足のリソースがあるか否かを判断し、不足のリソースがある場合には不足のリソース量を確保した後に、構成変更を実行する。

また特許文献２には、応答監視モジュールと、情報蓄積モジュールと、マネージャモジュールとを有する性能向上サービス提供システムが開示されている。応答監視モジュールは、ネットワークを介し一定期間毎に一般のエンドユーザと同様の方式でユーザシステムにアクセスを行い、その応答時間の時系列データを収集ログとして格納する。情報蓄積モジュールは、ネットワークを介して一定期間毎にユーザシステムの構成要素の監視を行い、その監視結果を示すリソース情報の時系列データを収集ログとして格納する。マネージャモジュールは、上記の収集ログに基づく分析によりユーザシステムの性能劣化を検知した際に、当該分析および過去の性能向上処置の実施状況をふまえた上で適切な性能向上処置を決定して当該性能向上処置を実施し、その実施状況を示す履歴を保存する。
特開２００７−２４９４４５号公報 特開２００５−１８１０３号公報

しかしながら、関連するクラスタシステムでは、リソースの状態監視は、そのリソースが障害であるか否かの白黒の判断を行うものであり、障害が発生してから他のサーバへの切り替えを行うなど、障害発生事後にクラスタ切り替えを行うものがほとんどである。

また、特許文献１記載の技術では、負荷状況に至った原因を特定する処理を行っていないため、サービスの再配置を行った後においても同様の負荷状況を発生させてしまう可能性を否定できない。

さらに、特許文献２記載の技術では、情報蓄積モジュールにより、ユーザシステムの構成要素の監視を行い、その監視結果を示すリソース情報（ＣＰＵ、メモリ使用率など）を収集しているものの、サービスの提供に必要なコンピューティング・リソース（サーバ、アプリケーション、ストレージ・デバイスなど。）の性能の監視を行うものではない。このため、性能低下を引き起こしている主要因の原因箇所（リソース）を精度良く検出することができない。

従って、関連するクラスタシステムでは、リソースの稼動状況に応じたサービスの提供状況をレポートする仕組みが提供されていないため、性能低下を引き起こしている原因箇所を精度良く特定することができないという問題点がある。

本発明に係るクラスタシステムにおける性能低下の原因箇所の特定方法は、サービスの提供に必要な複数のリソースにより構成されるクラスタシステムにおける性能低下の原因箇所の特定方法であって、前記リソースの稼働状況を監視すると共に、当該リソースの性能低下を示唆する性能監視項目を監視するステップと、当該監視結果に基づいて前記リソースの性能低下を判断し、前記リソース間の影響関係から性能低下の原因であるリソースを特定するステップと、を有するものである。

これにより、リソースの稼動状況の判断に加えて、性能低下を示唆する性能監視項目を監視することで、性能低下を引き起こしている原因箇所を精度良く特定することができる。

本発明に係るクラスタシステムは、サービスの提供に必要な複数のリソースにより構成されるクラスタシステムであって、前記リソースの稼働状況を監視すると共に、当該リソースの性能低下を示唆する性能監視項目を監視して当該監視情報を性能情報データベースに格納するリソース監視手段と、前記性能情報データベースに格納した監視情報に基づいて前記リソースの性能低下を判断し、前記リソース間の影響関係を記述したサービスグループ情報テーブルを参照して、性能低下の原因であるリソースを特定する原因箇所特定手段と、を有するものである。

これにより、リソースの稼動状況の判断に加えて、性能低下を示唆する性能監視項目を監視することで、性能低下を引き起こしている原因箇所を精度良く特定することができる。

本発明にかかるクラスタシステムにおける性能低下の原因箇所の特定方法、クラスタシステムによれば、リソースの性能低下を引き起こしている原因箇所を精度良く特定することができる。

以下、本発明を実施するための最良の形態について、図面を参照しながら詳細に説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略及び簡潔化がなされている。各図面において同一の構成又は機能を有する構成要素及び相当部分には、同一の符号を付し、その説明を省略する。

まず、図１を参照して、本発明に係るクラスタシステムにおける性能低下の原因箇所の特定方法について、その概略を説明する。図１は、本発明に係る性能低下の原因箇所の特定方法を示すフローチャートである。本発明に係るクラスタシステムは、サービスの提供に必要な複数のリソースにより構成されるクラスタシステムである。そして、図１に示すように、本発明に係るクラスタシステムは、まず、ステップＳ１０１において、各リソースの稼働状況を監視すると共に、それらリソースの性能低下を示唆する性能監視項目を監視する。次いで、ステップＳ１０２において、監視結果に基づいて各リソースの性能低下を判断し、リソース間の影響関係から性能低下の原因であるリソースを特定する。

これにより、リソースの稼動状況の判断に加えて、性能低下を示唆する性能監視項目を監視することで、性能低下を引き起こしている原因箇所（リソース）を精度良く特定することができる。

実施の形態１．
以下、図２乃至９を参照して、実施の形態１に係るクラスタシステム、及び、クラスタにおける性能低下の原因箇所の特定方法について説明する。

図２は、本発明に係るクラスタシステムの全体構成を示す図である。クラスタシステム１は、サービスの提供に必要な複数のコンピューティング・リソース（サーバ、アプリケーション、ストレージ・デバイスなど。以下、これらのコンピューティング・リソースを、単にリソースと称することもある。）により構成される。図に示す例では、クラスタシステム１は、サービスを提供する複数のサーバ群７０から構成される。サーバ群７０はパブリックネットワーク１００を介して接続されるサーバ（稼動系）２０とサーバ（待機系）３０から構成される。尚、図２では、サーバ群７０は、２つのサーバ（稼動系）２０とサーバ（待機系）３０を含むものとしたが、３つ以上のサーバを含むものとしてもよい。

サーバ（稼動系）２０は、クラスタソフトウェア２１と、ユーザに提供する複数のサービス１，２とを実行する。サーバ（待機系）３０は、サーバ（稼動系）２０のリソースに障害が発生した場合に、サーバ（稼動系）２０に代わってサービスを提供するサーバであり、クラスタソフトウェア３１と、例えばユーザに提供するサービス２とを実行する。サーバ（稼動系）２０のクラスタソフトウェア２１とサーバ（待機系）３０のクラスタソフトウェア３１は、各リソースの稼働状況を監視すると共に、それらリソースの性能低下を示唆する性能監視項目を監視する。そして、監視結果に基づいて各リソースの性能低下を判断し、リソース間の影響関係から性能低下の原因であるリソースを特定した上で、リソースの再起動やサーバ切り替え（フェイルオーバ）などを行う。サーバ（稼動系）２０のクラスタソフトウェア２１とサーバ（待機系）３０のクラスタソフトウェア３１とは互いに通信を行い、サーバ切り替え（フェイルオーバ）を行う。

クラスタシステム１では、ユーザに提供するサービスをひとつの単位として、フェイルオーバなどを行い、サービスの処理性能や可用性を高めている。以下では、ユーザに提供するサービス単位をサービスグループと称する。サービスグループは、サービスを提供するのに必要なリソースにより構成される。

図２では、サーバ（稼動系）２０が提供するサービス２のサービスグループとして、通常のデータベースサービスの一例を示している。サービスグループとしてのデータベースサービス３２は、ネットワークインタフェース（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）３２１、ＩＰアドレス（ＩＰ ａｄｄｒｅｓｓ）３２２、ストレージ・デバイス（Ｄｉｓｋ）３２３、ファイルシステム（ＦｉｌｅＳｙｓｔｅｍ）３２４、データベースソフトウェア（Ｄａｔａｂａｓｅ）３２５、及びアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ：Ｗｅｂサーバなど）３２６により構成される。すなわち、データベースサービス３２のサービスグループは、リソースとして、ネットワークインタフェース３２１、ＩＰアドレス３２２、ストレージ・デバイス３２３、ファイルシステム３２４、データベースソフトウェア３２５、及びアプリケーション３２６を含む。

本実施の形態に係るクラスタシステム１は、リソースの監視に際して、監視対象装置（リソース）の稼動有無を監視するのに加えて、監視対象装置（リソース）の性能低下を示唆する監視項目（以下、これを性能監視項目と称する。）についても監視する。そして、あるリソースの性能監視項目が極端に変化し性能低下を示唆する状態となった場合には、これをトリガー（性能低下の判断）として、サービスグループを構成している全てのリソースの性能監視項目の動向を調査し、原因箇所（リソース）の絞込みを行う。ここで、リソースによっては、性能監視項目の変動が他のリソースの影響を受けることがあるため、原因箇所の絞込みを行う際には、リソース同士の影響関係を考慮して、その影響を与えているリソースまでの原因箇所の絞込みを行うことを特徴とする。さらに、原因箇所として絞り込まれたリソースについては、そのリソースのクラスタシステム１の構成上の配置を考慮し、原因排除にフェイルオーバが有効であると期待できるか否かを判断し、期待できる場合にはフェイルオーバを実施する。

例えば、リソースをネットワークインタフェースとした場合に、このネットワークインタフェースにおける入出力パケット数の増加比率（すなわち、これを性能監視項目とする。）を測定することにより、リソースのパフォーマンス低下が発生しているか否かの判断を行う。そして、入力パケットの増加数に対して出力パケットの増加数が極端に低い傾向になった場合には、サービスのレスポンスが悪くなっている可能性があるものと考えられる。従って、これをトリガーとして、サービスグループを構成している全てのリソースについてその性能監視項目の動向を調査し、パフォーマンス低下の原因箇所であるリソースの絞込みを行う。

尚、トリガーとするリソース及びトリガー条件は、指定可能とし、サービスの特性を反映できるものとする。すなわち、サービスの特性に応じて、複数のリソースのうち性能低下の判断対象とするリソースと、そのリソースの性能低下を判断するための条件とを指定することができる。

図３は、本実施の形態に係るクラスタシステムのクラスタソフトウェアが有する機能構成を示す全体図である。尚、図２に示したクラスタソフトウェア２１及び３１は同じ機能を有しているため、以下では、代表してクラスタソフトウェア２１が有する機能として説明する。

図３に示すように、クラスタソフトウェア２１は、主に、可用性確保手段１１と、リソース監視手段１２と、原因箇所特定手段１３と、フェイルオーバ判断手段１４を有している。また、上記手段に加えて、ユーザにより予め設定されたリソーストリガーテーブル１５とサービスグループ情報テーブル１６を有している。

可用性確保手段１１は、クラスタシステム１の中心的な役割を担うものであり、リソースの監視を制御し、サービスの可用性を確保するためにリソースの再起動やサーバ切り替え（フェイルオーバ）等の動作を行う。

リソース監視手段１２は、可用性確保手段１１の管理の下で動作し、対象リソースの監視を行う。本実施の形態に係るクラスタシステム１では、リソースの監視に際して、監視対象リソースの稼動有無の判断（すなわち、通常の監視内容）の他に、リソースの性能低下を示唆する監視項目（すなわち、性能監視項目）を加えるものである。尚、各リソースに対応する複数のリソース監視手段１２が存在するが、図３においては、リソース１を監視する監視手段１２のみを代表して示している。

サービスグループ情報テーブル１６は、サービスグループ毎にそのサービスグループを構成するリソースと、そのリソースの他のリソースとの影響関係を記述したサービスグループの情報テーブルである。図３に示す例では、そのリソースが被影響リソースである場合には、被影響フラグの値を１とし、影響を与えるリソースの名称を影響リソース名として示している。すなわち、図３に示すサービスグループ情報テーブル１６では、例えば、リソース２は、被影響リソースであり、リソース２に影響を与えるリソースはリソース３であることを示している。

リソーストリガーテーブル１５は、トリガーとするリソース及びトリガー条件を記述したテーブルである。

原因箇所特定手段１３は、リソースの性能監視項目の動向が極端に変化し性能低下を示唆する状態となった場合をトリガーとして、サービスグループを構成する全てのリソースの性能監視項目の動向を調査し、原因箇所（リソース）の絞込みを行う。ここで、リソースによっては、性能監視項目の変動が他のリソースの影響を受けることがあるため、原因箇所特定手段１３は、原因箇所の絞込みの際には、リソース同士の影響関係を考慮し、影響を与えているリソースまでの原因箇所の絞込みを行う。さらに、原因箇所特定手段１３は、原因箇所として絞り込んだソースがリストアップされた原因箇所リスト１７を作成すると共に、絞り込んだリソースの性能監視項目の動向をレポート１８として表示する。

フェイルオーバ判断手段１４は、原因箇所のリソースがフェイルオーバ（サーバ切り替え）により原因解消可能であるか否かを判断し、原因解消に期待がもてる場合には、可用性確保手段１１に対して、フェイルオーバの実施を指示する。

図４は、本実施の形態に係るクラスタシステムの全体処理の流れを示す概念図である。まず、リソース監視手段１２により、サービスグループを構成している各リソースの監視が行われる。すなわち、図４では、サービスグループ１を構成している各リソースの監視が、対応する各リソース監視手段１２により行われる。尚、それぞれのリソースに対して、そのリソースをトリガーとするか否かを示すトリガーフラグと、そのトリガー条件が定義されている（これらの情報はリソーストリガーテーブル１５に定義されている）。例えば、図４では、リソース１がトリガーとされ、リソース１の監視手段１２にトリガー設定がされている。

ここで、あるリソース（図４に示す例では、リソース１）において、リソーストリガーテーブル１５に定義されたトリガー条件が満たされた場合を想定する。すると、これをトリガーとして、原因箇所特定手段１３により、原因箇所（リソース）の絞込みが行われる。

原因箇所特定手段１３は、サービスグループ情報テーブル１６に従い、サービスグループを構成している全てのリソース（図４に示す例では、４つのリソース）の性能監視項目の動向を調査し（図４において、リソース１（符号４１）、リソース２（符号４２）、・・・、の性能監視項目の動向調査処理を符号４０により示す）、原因箇所（リソース）の絞込みを行う。リソースによっては、性能監視項目の動向が他のリソースの影響を受けることがあるため、原因箇所の絞込みの際には、リソース同士の影響関係を考慮して影響を与えているリソースまでの絞込みを行う。原因箇所特定手段１３は、原因箇所の絞込みの結果を示す原因箇所リスト１７を作成すると共に、原因箇所の絞込み結果を、トリガーとなったリソースを含め、絞り込んだリソースの性能監視項目の動向をレポート１８として表示する。

フェイルオーバ判定手段１４では、作成した原因箇所リスト１７を参照して、原因箇所のリソースがフェイルオーバ（サーバ切り替え）により原因解消可能であるか否かの判断を行い、原因解消が期待できる場合には、可用性確保手段１１に対して、フェイルオーバの実施を指示する。

次に、図５乃至９を参照して、本実施の形態に係るクラスタシステムの動作の詳細について説明する。図５は、リソース監視手段による動作処理を説明するためのフローチャート図である。図５では、各リソース監視手段が行う動作処理を示している。

図５に示すように、リソース監視手段１２は、まず、監視対象リソースの稼働状況の有無を監視（ステップＳ２０１）し、さらに、リソースの性能低下を示唆する性能監視項目を監視する（ステップＳ２０２）。そして、リソース監視手段１２は、性能監視項目の監視情報を性能情報データベース１９に格納する（ステップＳ２０３）。リソース監視手段１２は、監視しているリソースについて、リソーストリガーテーブル１５のトリガーフラグを参照して、そのリソースがトリガーとして定義されているか否か（すなわち、トリガー設定されているか否か）を判断する（ステップＳ２０４）。判断の結果、そのリソースがトリガーとして定義されていない場合には、これでリソース監視の１つのサイクルを終了する。

一方で、判断の結果、そのリソースがトリガーとして定義されている場合には、リソース監視手段１２は、リソーストリガーテーブル１５のトリガー条件を参照して、そのリソースがトリガー条件を満たしているか否かの判断を行う（ステップＳ２０５）。

判断の結果、そのリソースがトリガー条件を満たしているものと判断した場合には（ステップＳ２０５でＹｅｓ）、リソース監視手段１２は、原因箇所特定手段１３を呼び出し、原因箇所特定手段１３による処理（ステップＳ２０６）へと進み、原因箇所の絞込みを行う。一方で、判断の結果、そのリソースがトリガー条件を満たしていないものと判断した場合には（ステップＳ２０５でＮｏ）、リソース監視手段１２は、これでリソース監視の１つのサイクルを終了する。

図６乃至８は、原因箇所特定手段による動作処理を説明するためのフローチャート図である。原因箇所特定手段１３は、２つのステップにおいて原因箇所の絞込みを行う。これら２つのステップをステップ１、ステップ２と称する。さらに、原因箇所特定手段１３は、ステップ３においてレポート表示処理を行う。以下、各ステップの詳細を説明する。

まず、図６を参照してステップ１について説明する。ステップ１において、原因箇所特定手段１３は、リソース抽出処理及び性能監視項目動向調査処理を行い、一次原因箇所リスト１７１を作成する。

まず、原因箇所特定手段１３は、リソース抽出処理を行う（ステップＳ６０１）。すなわち、原因箇所特定手段１３は、トリガーとなったリソースの名前をもとにして、サービスグループ情報テーブル１６から調査対象とすべきリソースを抽出する。すなわち、トリガーとなったリソースが属するサービスグループを特定し、特定したそのサービスグループに属するリソースから一つのリソースを抽出する。

次いで、原因箇所特定手段１３は、抽出対象となる全てのリソースについて後述するステップＳ６０３での性能監視項目動向調査処理を終了したか否かの判断を行う（ステップＳ６０２）。判断の結果、終了した場合には、ステップ２へと進む。

一方で、終了していない場合には、原因箇所特定手段１３は、性能監視項目動向調査処理を行う（ステップＳ６０３）。すなわち、原因箇所特定手段１３は、リソース抽出処理において抽出したリソースに対して、性能情報データベース１９に格納された性能監視項目の監視情報を参照することで、リソースの性能監視項目の動向が極端に変化を示していないか否かを調査する。

次いで、原因箇所特定手段１３は、調査したリソースの性能監視項目の動向が極端に変化を示していないか否かを判断する（ステップＳ６０４）。判断の結果、性能監視項目の動向が極端な変化を示していないものと判断した場合には、原因箇所特定手段１３は、ステップＳ６０１へと戻り、次のリソースの処理を行う。

一方で、判断の結果、性能監視項目の動向が極端な変化を示しているものと判断した場合には、原因箇所特定手段１３は、そのリソースを一次原因箇所リスト１７１に追加する（ステップＳ６０５）。そして、原因箇所特定手段１３は、ステップＳ６０１へと戻り、次のリソースの処理を行う。

次に、図７を参照してステップ２について説明する。ステップ２において、原因箇所特定手段１３は、ステップ１で作成した一次原因箇所リストから、原因箇所リスト１７を作成する。

まず、ステップ２では、原因箇所特定手段１３は、ステップ１で作成した一次原因箇所リスト１７１からリソース抽出処理を行う（ステップＳ７０１）。そして、原因箇所特定手段１３は、抽出したリソースが被影響リソースであるか否かを判断する（ステップＳ７０２）。判断の結果、そのリソースが被影響リソースでない場合には、原因箇所特定手段１３は、そのリソースを原因箇所リスト１７に追加する（ステップＳ７０４）。

一方で、そのリソースが被影響リソースである場合には、原因箇所特定手段１３は、さらに、影響を与えるリソースが一次原因箇所リスト１７１にあるか否かを判断する（ステップＳ７０３）。判断の結果、影響を与えるリソースが一次原因箇所リスト１７１にない場合には、原因箇所特定手段１３は、そのリソースを原因箇所リスト１７に追加する（ステップＳ７０４）。

一方で、判断の結果、影響を与えるリソースが一次原因箇所リスト１７１にある場合には、原因箇所特定手段１３は、ステップＳ７０１へと戻り、一次原因箇所リスト１７１の次のリソースについての処理を行う。

ステップＳ７０４においてリソースを原因箇所リストに追加した後、原因箇所特定手段１３は、ステップＳ７０１での一次原因箇所リスト１７１の全てのリソースに対してリソース抽出処理を終了したか否かを判断する（ステップＳ７０５）。判断の結果、終了した場合にはステップ３へと進む。一方で、終了していない場合には、原因箇所特定手段１３は、ステップＳ７０１へと戻り、一次原因箇所リスト１７１の次のリソースについての処理を行う。

例えば、上述したステップ１での処理の結果、一次原因箇所リストにはリソース２及びリソース３が追加された状況を想定する。ステップ２では、まず、原因箇所特定手段１３は、ステップＳ７０１で、一次原因箇所リストからリソース２を抽出する。次いで、ステップＳ７０２で、図３で示したサービスグループ情報テーブル１６を参照して、リソース２は被影響リソースであるものと判断する（すなわち、ステップＳ７０２でＹｅｓ）。次いで、ステップＳ７０３で、図３で示したサービスグループ情報テーブル１６を参照して、リソース２に影響を与えるリソース３が一次原因箇所リストにあると判断する（すなわち、ステップＳ７０３でＹｅｓ）。次いで、ステップＳ７０１へと戻り、一次原因箇所リストからリソース３を抽出する。次いで、ステップＳ７０２で、図３で示したサービスグループ情報テーブル１６を参照して、リソース２は被影響リソースでないものと判断する（すなわち、ステップＳ７０２でＮｏ）。次いで、ステップＳ７０４で、リソース３を原因箇所リスト１７に追加する。次いで、ステップＳ７０５で、全てのリソースに対してリソース抽出処理を終了したものと判断し（すなわち、ステップＳ７０５でＹｅｓ）、ステップ３へと進む。

このように、原因箇所特定手段１３は、一次原因箇所リスト１７１の中から、リソース同士の影響関係を考慮し、影響を与えているリソースまでの絞込みを行い、原因箇所リスト１７を作成する。

次に、図８を参照してステップ３について説明する。ステップ３において、原因箇所特定手段１３は、レポート表示処理を行う（ステップＳ８０１）。すなわち、原因箇所特定手段１３は、トリガーとなったリソースを含めて、絞り込んだリソース（原因箇所リスト１７にリストアップされたリソース）の性能監視項目の動向（測定情報５０）をレポート１８として表示する。尚、測定情報５０は、リソース監視手段１２により監視され、性能情報データベース１９に格納された性能監視項目の監視情報を含んでいる。

図９は、フェイルオーバ判断手段による動作処理を説明するためのフローチャート図である。

まず、フェイルオーバ判断手段１４は、リソース抽出処理を行う（ステップＳ９０１）。すなわち、フェイルオーバ判断手段１４は、原因箇所リスト１７から、フェイルオーバ有効性判断処理の対象とすべきリソースを抽出する。

次いで、フェイルオーバ判断手段１４は、全てのリソースについてフェイルオーバ有効性判定処理が終了したか否かの判断を行う（ステップＳ９０２）。判断の結果、終了した場合には、フェイルオーバ判断手段１４は、可用性確保手段１１に対して、フェイルオーバの指示を行う（ステップＳ９０５）。すなわち、フェイルオーバ判断手段１４は、原因箇所の全てのリソースにおいて、フェイルオーバが有効であると判断できた場合には、そのサービスグループのフェイルオーバを可用性確保手段１１に指示する。

一方で、ステップＳ９０２における判断の結果、終了していない場合には、フェイルオーバ判断手段１４は、フェイルオーバ有効性判定処理を行う（ステップＳ９０３）。すなわち、リソース抽出処理において抽出したリソースに対して、リソースのクラスタシステム１の構成上の配置を考慮し、原因箇所の排除にフェイルオーバが有効であるか否かを判断する。

次いで、フェイルオーバ判断手段１４は、フェイルオーバが有効であるか否かを判断する（ステップＳ９０４）。例えば、各サーバに固有のリソースについて障害が発生した場合には、原因箇所の排除にフェイルオーバが有効であるものと判断することができる。一方で、各サーバで共有するリソース（ディスクなど）について障害が発生した場合には、フェイルオーバは有効でないものと判断することができる。

判断の結果、フェイルオーバが有効であるものと判断した場合には、フェイルオーバ判断手段１４は、ステップＳ９０１へと戻り、次のリソースの処理を行う。一方で、判断の結果、フェイルオーバが有効でないものと判断した場合には、フェイルオーバ判断手段１４は、処理を終了する。

実施の形態２．
本実施の形態では、実施の形態１に比べて、各サーバのＣＰＵおよびメモリの使用率をトリガーとして指定することを可能とする。これにより、ＣＰＵおよびメモリの使用率の変動の影響が、リソースや、さらにはサービスのパフォーマンスに影響を与えているかの判断が可能となる。なお、以下に特に説明する点を除いて、他の構成、及び処理については、実施の形態１と同様であるため、説明を省略する。

以下、図１０乃至１３を参照して、実施の形態２に係るクラスタシステム、及び、クラスタにおける性能低下の原因箇所の特定方法について説明する。

図１０は、本実施の形態に係るクラスタシステムのクラスタソフトウェアが有する機能構成を示す全体図である。尚、図３に示した実施の形態１に係るクラスタシステムと比べて、図１０に示すクラスタシステムでは、更に、ＣＰＵ監視手段８１とメモリ監視手段８２を有している。

ＣＰＵ監視手段８１およびメモリ監視手段８２は、リソース監視手段１２と同様に動作するものであり、性能監視項目として、それぞれＣＰＵ使用率、メモリ使用率の監視を行うものである。また、トリガーの設定、トリガー条件の設定も、リソース監視手段１２と同様に行うことができる。

次に、図１１乃至１３を参照して、本実施の形態に係るクラスタシステムの動作の詳細について説明する。図１１は、ＣＰＵ監視手段あるいはメモリ監視手段がトリガーとなった場合の原因箇所特定手段による動作処理を説明するためのフローチャート図である。原因箇所特定手段１３は、２つのステップにおいて原因箇所の絞込みを行う。これら２つのステップをステップ１、ステップ２と称する。さらに、原因箇所特定手段１３は、ステップ３においてレポート表示処理を行う。以下、各ステップの詳細を説明する。

まず、図１１を参照してステップ１について説明する。ステップ１において、原因箇所特定手段１３は、リソース抽出処理及び性能監視項目動向調査処理を行い、一次原因箇所リスト１７１を作成する。

まず、原因箇所特定手段１３は、ＣＰＵ監視手段８１あるいはメモリ監視手段８２がトリガーとなった場合には、全てのサービスグループを対象として、サービスグループ情報テーブル１６から調査対象とすべきリソースを抽出する（ステップＳ１１０１）。

次いで、原因箇所特定手段１３は、抽出対象となる全てのリソースについて性能監視項目動向調査処理を終了したか否かの判断を行う（ステップＳ１１０２）。判断の結果、終了した場合には、ステップ２へと進む。

一方で、終了していない場合には、原因箇所特定手段１３は、性能監視項目動向調査処理を行う（ステップＳ１１０３）。すなわち、原因箇所特定手段１３は、リソース抽出処理において抽出したリソースに対して、性能情報データベース１９に格納された性能監視項目の監視情報を参照することで、リソースの性能監視項目の動向が極端に変化を示していないか否かを調査する。

次いで、原因箇所特定手段１３は、調査したリソースの性能監視項目の動向が極端に変化を示していないか否かを判断する（ステップＳ１１０４）。判断の結果、性能監視項目の動向が極端な変化を示していないものと判断した場合には、原因箇所特定手段１３は、ステップＳ１１０１へと戻り、次のリソースの処理を行う。

一方で、判断の結果、性能監視項目の動向が極端な変化を示しているものと判断した場合には、原因箇所特定手段１３は、そのリソースを一次原因箇所リスト１７１に追加する（ステップＳ１１０５）。そして、原因箇所特定手段１３は、ステップＳ１１０１へと戻り、次のリソースの処理を行う。

次に、図１２を参照してステップ２について説明する。ステップ２において、原因箇所特定手段１３は、ステップ１で作成した一次原因箇所リストから、原因箇所リスト１７を作成する。

まず、ステップ２では、原因箇所特定手段１３は、ステップ１で作成した一次原因箇所リスト１７１からリソース抽出処理を行う（ステップＳ１２０１）。そして、原因箇所特定手段１３は、抽出したリソースが被影響リソースであるか否かを判断する（ステップＳ１２０２）。判断の結果、そのリソースが被影響リソースでない場合には、原因箇所特定手段１３は、そのリソースを原因箇所リスト１７に追加する（ステップＳ１２０４）。

一方で、そのリソースが被影響リソースである場合には、原因箇所特定手段１３は、さらに、影響を与えるリソースが一次原因箇所リスト１７１にあるか否かを判断する（ステップＳ１２０３）。判断の結果、影響を与えるリソースが一次原因箇所リスト１７１にない場合には、原因箇所特定手段１３は、そのリソースを原因箇所リスト１７に追加する（ステップＳ１２０４）。

一方で、判断の結果、影響を与えるリソースが一次原因箇所リスト１７１にある場合には、原因箇所特定手段１３は、ステップＳ１２０１へと戻り、一次原因箇所リスト１７１の次のリソースについての処理を行う。

ステップＳ１２０４においてリソースを原因箇所リストに追加した後、原因箇所特定手段１３は、ステップＳ７０１での一次原因箇所リスト１７１の全てのリソースに対してリソース抽出処理を終了したか否かを判断する（ステップＳ１２０５）。判断の結果、終了した場合にはステップ３へと進む。一方で、終了していない場合には、原因箇所特定手段１３は、ステップＳ１２０１へと戻り、一次原因箇所リスト１７１の次のリソースについての処理を行う。

次に、図１３を参照してステップ３について説明する。ステップ３において、原因箇所特定手段１３は、レポート表示処理を行う（ステップＳ１３０１）。すなわち、原因箇所特定手段１３は、トリガーとなったリソースを含めて、絞り込んだリソース（原因箇所リスト１７にリストアップされたリソース）の性能監視項目の動向（測定情報５０）をレポート１８として表示する。原因箇所特定手段１３は、全サービスグループを対象として原因箇所特定処理を実行し、複数のサービスグループのレポートを出力する。これにより、ＣＰＵおよびメモリの使用率の変動の影響がリソース、さらにはサービスのパフォーマンスに影響を与えているかの判断が可能となる。

以下、本発明による効果について説明する。まず、本発明による第１の効果としては、サービスのパフォーマンスに影響を及ぼしているコンピューティング・リソースを特定可能である点が挙げられる。その理由は、サービスのパフォーマンスに影響する性能低下を察知して、これをトリガーとして、サービスの単位でその原因箇所を特定するためである。
また、第２の効果として、サービスの特性を考慮して原因箇所特定の条件を設定可能な点が挙げられる。その理由は、サービスのパフォーマンスに影響する性能低下を察知する条件をカスタマイズできるためである。
さらに、第３の効果として、サービスの性能低下を同様の原因で起こさないように、フェイルオーバを実施可能な点が挙げられる。その理由は、特定した原因箇所において、性能低下の原因排除にフェイルオーバが有効であるか判断した上でフェイルオーバの実施を決定するためである。

尚、本発明は上述した実施の形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

本発明に係る性能低下の原因箇所の特定方法の概略を示すフローチャートである。 本発明の実施の形態１に係るクラスタシステムの全体構成を示す図である。 本発明の実施の形態１に係るクラスタシステムのクラスタソフトウェアが有する機能構成を示す全体図である。 本発明の実施の形態１に係るクラスタシステムの全体処理の流れを示す概念図である。 本発明の実施の形態１に係るリソース監視手段による動作処理を説明するためのフローチャート図である。 本発明の実施の形態１に係る原因箇所特定手段による動作処理を説明するためのフローチャート図である。 本発明の実施の形態１に係る原因箇所特定手段による動作処理を説明するためのフローチャート図である。 本発明の実施の形態１に係る原因箇所特定手段による動作処理を説明するためのフローチャート図である。 本発明の実施の形態１に係るフェイルオーバ判断手段による動作処理を説明するためのフローチャート図である。 本発明の実施の形態２に係るクラスタシステムのクラスタソフトウェアが有する機能構成を示す全体図である。 本発明の実施の形態２に係る原因箇所特定手段による動作処理を説明するためのフローチャート図である。 本発明の実施の形態２に係る原因箇所特定手段による動作処理を説明するためのフローチャート図である。 本発明の実施の形態２に係る原因箇所特定手段による動作処理を説明するためのフローチャート図である。

符号の説明

１ クラスタシステム、
１１ 可用性確保手段、
１２ リソース監視手段、
１３ 原因箇所特定手段、
１４ フェイルオーバ判断手段、
１５ リソーストリガーテーブル、
１６ サービスグループ情報テーブル、
１７ 原因箇所リスト、
１７１ 一次原因箇所リスト、
１８ レポート、
１９ 性能情報データベース、
２０ サーバ（稼動系）、
２１ クラスタソフトウェア、
２２ サービス１、
２３ サービス２、
３０ サーバ（待機系）、
３１ クラスタソフトウェア、
３２ サービス２（データベースサービス）、
３２１ ネットワークインタフェース（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）、
３２２ ＩＰアドレス（ＩＰ ａｄｄｒｅｓｓ）、
３２３ ストレージ・デバイス（Ｄｉｓｋ）、
３２４ ファイルシステム（ＦｉｌｅＳｙｓｔｅｍ）、
３２５ データベースソフトウェア（Ｄａｔａｂａｓｅ）、
３２６ アプリケーション（Ａｐｐｌｉｃａｔｉｏｎ：Ｗｅｂサーバなど）、
４０ 性能監視項目の動向調査処理、
４１、４２ リソース、
５０ 測定情報、
７０ サーバ群、
９１ サービスグループ１（レポート）、
９２ サービスグループ３（レポート）、
１００ パブリックネットワーク、

Claims (9)

1. サービスの提供に必要な複数のリソースにより構成されるクラスタシステムにおける性能低下の原因箇所の特定方法であって、
   前記リソースの稼働状況を監視すると共に、当該リソースの性能低下を示唆する性能監視項目を監視するステップと、
   当該監視結果に基づいて前記リソースの性能低下を判断し、前記リソース間の影響関係から性能低下の原因であるリソースを特定するステップと、
   を有するクラスタシステムにおける性能低下の原因箇所の特定方法。
2. 前記複数のリソースのうち性能低下の判断対象とするリソースと、当該リソースの性能低下を判断するための条件とを指定可能とする
   ことを特徴とする請求項１に記載のクラスタシステムにおける性能低下の原因箇所の特定方法。
3. 前記監視結果の変動から前記リソースの性能低下を判断し、前記複数のリソースのうち少なくとも１つの前記リソースが性能低下を示す状態となった場合には、前記複数のリソース間の影響関係から性能低下の原因であるリソースを特定する
   ことを特徴とする請求項１又は２に記載のクラスタシステムにおける性能低下の原因箇所の特定方法。
4. 前記クラスタシステムが備えるＣＰＵ及びメモリの少なくとも一つの使用率を監視するステップを更に有し、
   当該ＣＰＵ及びメモリ使用率に基づいて前記リソースの性能低下を判断し、前記リソースの監視結果と前記リソース間の影響関係から、性能低下の原因であるリソースを特定する
   ことを特徴とする請求項１乃至３いずれか１項に記載のクラスタシステムにおける性能低下の原因箇所の特定方法。
5. サービスの提供に必要な複数のリソースにより構成されるクラスタシステムであって、
   前記リソースの稼働状況を監視すると共に、当該リソースの性能低下を示唆する性能監視項目を監視して当該監視情報を性能情報データベースに格納するリソース監視手段と、
   前記性能情報データベースに格納した監視情報に基づいて前記リソースの性能低下を判断し、前記リソース間の影響関係を記述したサービスグループ情報テーブルを参照して、性能低下の原因であるリソースを特定する原因箇所特定手段と、
   を有するクラスタシステム。
6. 前記複数のリソースのうち性能低下の判断対象とするリソースと、当該リソースの性能低下を判断するための条件とを記述するトリガーテーブルを更に有し、
   前記原因箇所特定手段は、当該トリガーテーブルを参照して、前記性能情報データベースに格納した監視情報に基づいて前記リソースの性能低下を判断する
   ことを特徴とする請求項５に記載のクラスタシステム。
7. 前記原因箇所特定手段は、前記性能情報データベースに格納した監視情報の変動から前記リソースの性能低下を判断し、前記複数のリソースのうち少なくとも１つの前記リソースが性能低下を示す状態となった場合には、前記サービスグループ情報テーブルを参照して、性能低下の原因であるリソースを特定する
   ことを特徴とする請求項５又は６に記載のクラスタシステム。
8. 前記クラスタシステムが備えるＣＰＵの使用率を監視するＣＰＵ監視手段とメモリの使用率を監視するメモリ監視手段の少なくとも一つを更に有し、
   前記原因箇所特定手段は、当該ＣＰＵ監視手段及びメモリ監視手段によるＣＰＵ使用率及びメモリ使用率に基づいて前記リソースの性能低下を判断し、サービスグループ情報テーブルを参照して、前記性能情報データベースに格納した監視情報から性能低下の原因であるリソースを特定する
   ことを特徴とする請求項５乃至７いずれか１項に記載のクラスタシステム。
9. 前記サービスの可用性を確保するための処置を行う可用性確保手段と、
   前記原因箇所特定手段により特定されたリソースがフェイルオーバにより原因解消可能であるか否かの判断を行い、原因解消が可能である場合には、前記可用性確保手段にフェイルオーバの実施を指示するフェイルオーバ判断手段と、を更に有する
   ことを特徴とする請求項５乃至７いずれか１項に記載のクラスタシステム。

Images