計算機のモニタリングシステム及びモニタリング方法
【課題】仮想サーバが利用する計算機リソースの関係を漏れなくツリー構造で表現し、物理リソースを共有する仮想リソースの統計情報を自動的に集計する。
【解決手段】物理計算機で実行されて仮想計算機を稼働させる仮想化部と、仮想化部上で稼動する仮想計算機と、物理計算機と仮想計算機の構成要素とを監視するモニタリング部を備え、モニタリング部は、物理計算機と仮想化部の構成要素とを併せてベースリソースとし、仮想計算機の構成要素を仮想リソースとして管理し、仮想リソースとベースリソースの構成要素を所定のプラットフォーム毎に木構造を抽出してプラットフォームツリーを生成し、仮想リソースの構成要素から変換情報で設定されたベースリソースまたは仮想リソースを起点とする木構造を抽出してサービス提供ツリーを生成し、プラットフォームツリーに含まれ、かつサービス提供ツリーに含まれる構成要素について参照関係を設定する。
【解決手段】物理計算機で実行されて仮想計算機を稼働させる仮想化部と、仮想化部上で稼動する仮想計算機と、物理計算機と仮想計算機の構成要素とを監視するモニタリング部を備え、モニタリング部は、物理計算機と仮想化部の構成要素とを併せてベースリソースとし、仮想計算機の構成要素を仮想リソースとして管理し、仮想リソースとベースリソースの構成要素を所定のプラットフォーム毎に木構造を抽出してプラットフォームツリーを生成し、仮想リソースの構成要素から変換情報で設定されたベースリソースまたは仮想リソースを起点とする木構造を抽出してサービス提供ツリーを生成し、プラットフォームツリーに含まれ、かつサービス提供ツリーに含まれる構成要素について参照関係を設定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の物理リソースと仮想リソースから構成される計算機システムのモニタリングシステムに関する。
【背景技術】
【０００２】
＜運用管理における業界の傾向＞
計算機システムを運用するデータセンタなどでは、ネットワーク機器、ストレージ装置、サーバ装置、ＯＳ、サーバ仮想化ソフトウェア等の管理情報をＸＭＬ形式で記述をサポートあるいはサポートを計画しているベンダが増加している。さらに、機器間や運用ソフト間での管理情報のやり取りをＸＭＬ形式のファイルで行う傾向も高まっている。
【０００３】
これらの運用管理情報の標準化仕様として、ＤＭＴＦ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｍａｎａｇｅｍｅｎｔ Ｔａｓｋ Ｆｏｒｃｅ）が策定したシステムの管理情報のモデルＣＩＭ（Ｃｏｍｍｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ）をベースにした管理情報の記述方法が浸透しつつある。ＣＩＭはＵＭＬでモデリングするが、装置に関するデータはＸＭＬ形式で操作される。このような背景のもと、システムの構成情報をＸＭＬで記述することが運用管理に関わる分野では標準的手法となりつつある。
【０００４】
＜モニタリングシステムについて＞
企業の情報システムやデータセンタなどでは、業務開発に合わせて構築した多数の計算機システムを統合し、一括運用管理をしていくニーズが高まっている。システム統合をしていく上でサーバ仮想化をはじめとしたシステムの仮想化技術がベースとなり広く普及しつつある。
【０００５】
一方、計算機システムの定常的な維持保守作業の中で、各種装置に関する統計情報は、性能モニタリングツールで採取し、シェルスクリプト等の実行をスケジューリングできるツールを使って自動的に運用することで監視対象のサーバ等のシステム装置から定期的に収集されている。
【０００６】
計算機システムの構成情報は表計算ソフトウェアのワークシート上で管理していることが多い。構成情報の更新には、構成情報の記録が正しいか否かを、管理者などが現在の構成情報の調査をする必要がある。この構成情報の調査では、ＳＮＭＰ等の業界標準インタフェースを用いて自動的に集められるものや、装置単位で担当者が異なるため、当該装置の担当者にインタビューして確認するなど様々であるため、現実的にはシステム全体（サーバとストレージ、ネットワークなど）の接続関係は、ワークシート上の図面で記録しているケースが多い。図面上での接続関係の調査は、グループ化やオブジェクトの順序等の機能を駆使して調査する。
【０００７】
また、データセンタ等では、計算機システムの構成情報に加えて、稼動している計算機や装置の稼動に関する統計情報をソフトウェアなどで自動的に収集し、管理者などが統計情報から稼動状態の分析を行う。稼働状態分析を行うトリガとしては、顧客への稼働状態の定期レポートの作成や、統計情報の閾値監視でアラートが発生したケースがある。稼働状態分析では、調査をしたい時点の計算機システムの構成情報から、仮想サーバが共有している物理リソースを見つけ出す作業を管理者等が試行錯誤しながら実行している。あるいは、計算機システムの性能に関して問題が発生した時点の構成情報と、問題発生前の構成情報とを管理者などが比較して、問題発生箇所のあたりをつけるといったことが日常的に行われている。例えば、管理者等は統計情報から物理リソースのトータルでの使用率を見て、当該個所が性能ボトルネックを起こしているか判断する。そして、管理者等はどの仮想サーバが性能に影響を与えているか統計情報を見て判断する。
【０００８】
構成情報上で注目した物理リソースの統計情報が直接採取できていない場合は、構成情報から採取できている他の統計情報から推測できないかを管理者等が検討し、既存のデータから物理リソース上の仮想サーバごとの利用状況を推測する必要がある。しかし、稼働状態監視の為の作業において、（１）構成情報の管理、（２）稼働情報と構成情報の関係調査、（３）仮想化で共有された物理資源の稼働情報の推定を、管理者等が手作業で試行錯誤しながら実行しており、非常に工数がかかっている。
【０００９】
一方、データセンタ等においては仮想化技術の導入で、運用すべき仮想化サーバ台数が数万のオーダになる可能性がある。数万台のオーダの仮想サーバの運用管理を効率化するためには、上述の稼働状態分析を省力化していく必要がある。
【００１０】
特許文献１の技術では、構成情報についてはＸＭＬを使って記述をしているが、稼働統計情報と構成情報を紐づけて表示することは行っていない。
【００１１】
特許文献２の技術は、ストレージ装置を中心に仮想サーバとストレージ装置の現在の関係を自動的に取得して構成図として表示し、システム要素の統計情報との関連を表示している。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特表２００７−５２４８８９号公報
【特許文献２】米国特許出願公開第２００８／０１６４３４４号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかし、上記従来例の特許文献１の技術では、統計情報の履歴は記録するが、構成情報の履歴は取得していない。また、特許文献２の技術では、システム要素間にまたがる統計情報の分析、例えば、ストレージのデータからＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｏｒ）の性能予測は行わない。
【００１４】
特許文献２の技術では、構成情報の履歴を取得しないので、必要に応じて構成図を作りなおす必要が生じる。構成情報の履歴について、仮に表の履歴をとると仮定する。システム要素数をＭ、システム要素間の関係（グループ）の数をＮとし、操作の回数（手間）をＯとすると、以下の考え方でサーバ台数ＳのときにはＯ（Ｓ2）回の手間（コスト）がかかる。
【００１５】
つまり、仮想サーバを異なる物理サーバ上に移動するケースを想定すると、表の場合、仮想サーバが追加されると新たな行と列を追加することになるので、構成変更のたびに表を作りなおすことになる。システム要素間の関係数とサーバの数とシステム要素数の関係は、
Ｎ∝Ｓ かつ Ｍ∝Ｓであることから、
Ｏ（Ｎ×Ｍ）＝Ｏ（Ｓ×Ｓ）＝Ｏ（Ｓ2）となる。
【００１６】
将来のデータセンタでは仮想サーバ台数は数万台になり、かつ仮想サーバの追加削除が日常的に頻繁に行われることが予想されている。この前提条件のもとでは、表でシステム要素間の関係を管理する場合、仮想サーバの変更が行われる度にＯ（Ｓ2）回の手間(データ量と表生成のコスト)がかかる、という問題があった。
【００１７】
上述の技術的背景や先行技術の問題を解決するために、計算機システムの構成情報の履歴管理と統計情報の取得を行って、構成情報の履歴と統計情報と構成情報の紐づけを行い、仮想サーバで共有している物理リソースの稼働状態を容易に分析可能とすることが必要であり、さらに、仮想サーバの追加削除等の構成変更の際のコストを低減させる、という課題があった。
【００１８】
そこで、本発明の目的は、計算機システムの構成情報と統計情報の関連付けを表示するモニタリングシステムにおいて、仮想サーバが利用する計算機リソースの関係を漏れなくツリー構造で表現し、かつ物理リソースを共有する仮想リソースの統計情報を自動的に集計することを可能にするものである。
【課題を解決するための手段】
【００１９】
本発明は、１つ以上の物理計算機と、前記物理計算機で実行されて１つ以上の仮想計算機を稼働させる仮想化部と、前記仮想化部上で稼動する１つ以上の仮想計算機と、前記物理計算機の構成要素と、前記仮想計算機の構成要素と、を監視するモニタリング部と、を備えた計算機のモニタリングシステムであって、前記モニタリング部は、前記物理計算機の構成要素である物理リソースと、前記仮想化部の構成要素とを併せてベースリソースとし、前記仮想化部上で稼動する仮想計算機の構成要素を仮想リソースとして管理し、前記仮想リソースの構成要素と前記ベースリソースの構成要素を所定のプラットフォーム毎に木構造を抽出してプラットフォームツリーを生成し、前記仮想リソースの構成要素から、所定の変換情報に設定された前記ベースリソースまたは仮想リソースを起点とする木構造を抽出してサービス提供ツリーを生成し、前記プラットフォームツリーに含まれ、かつ、前記サービス提供ツリーに含まれる構成要素について参照することを示す参照情報を設定し、前記プラットフォームツリーと前記サービス提供ツリーの構成要素の参照関係を設定する。
【発明の効果】
【００２０】
したがって、本発明によれば、仮想サーバと、仮想サーバが利用するベースリソースの関係を漏れなく、かつ少ない手数で管理することが可能となる。さらに、稼働に関する統計情報を任意の構成要素から、仮想サーバごとの使用状況を分析することが可能となる。また、木構造に従ってユーザが統計情報を分析することで効率的な統計情報の見方をナビゲートすることが可能となる。これらにより、稼動情報から計算機リソースのボトルネックを検出するまでの時間を短縮でき、多数の計算機を備えた環境における運用管理の効率を改善できる。
【００２１】
上記特許文献１と比較して、本発明は木構造で構成情報を出力するので追加や削除に要するコストは、サーバ台数をＳとすると、サーバ台数によらず当該サーバが関係している部分だけの変更にとどまるためＯ（１）のコストで実行でき、データ量はサーバ台数に比例するのでＯ（Ｓ）となり、上記従来技術と比較すると管理に要するコストとデータ量を低減できる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態を示し、本発明を適用する計算機モニタリングシステムを含む計算機システムの全体のブロック図である。
【図２】本発明の実施形態を示し、モニタリングシステム１００の内部構成を示したブロック図である。
【図３】本発明の実施形態を示し、稼動統計テーブル１２０の構成例である。
【図４】本発明の実施形態を示し、構成情報管理テーブル１３０の構成例である。
【図５】本発明の実施形態を示し、構成情報変更履歴管理テーブル１４０の構成例である。
【図６】本発明の実施形態を示し、コンポーネント履歴管理テーブル１５０の構成例である。
【図７】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのツリー表現の一部を抜粋した説明図である。
【図８】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのツリー表現の一部を抜粋した説明図である。
【図９】本発明の実施形態を示し、構成情報ＸＭＬ５００ｂのツリー表現の一部を抜粋した説明図である。
【図１０】本発明の実施形態を示し、構成情報ＸＭＬ５００ｃのツリー表現の一部を抜粋した説明図である。
【図１１】本発明の実施形態を示し、構成情報関連管理部２３０が管理するコンポーネントＩＤの状態遷移図である。
【図１２】本発明の実施形態を示し、構成情報ＸＭＬ５００ａに相当する割当済ＩＤ管理テーブル１６０の構成例である。
【図１３】本発明の実施形態を示し、構成情報ＸＭＬ５００ａに相当する割当済ＩＤ管理テーブル１６０の構成例である。
【図１４】本発明の実施形態を示し、稼動統計情報表示時に統計情報管理部１９０で行われる処理のフローチャートを示す。
【図１５】本発明の実施形態を示し、モニタリングシステム１００のモニタ端末３５０に表示される稼動統計モニタ画面の一例を示す画面イメージである。
【図１６】本発明の実施形態を示し、稼働情報収集部３００の構成を示すブロック図である。
【図１７】本発明の実施形態を示し、稼働情報収集部３００が使用する稼働情報収集パラメータ３１０の定義の説明図である。
【図１８】本発明の実施形態を示し、稼動情報収集部３００で行われる処理のフローチャートを示す。
【図１９】本発明の実施形態を示し、稼働統計値登録部３４０で行われる統計値登録処理１５８０の詳細なフローチャートを示す。
【図２０】本発明の実施形態を示し、構成管理マネージャ３６０の詳細を示すブロック図である。
【図２１】本発明の実施形態を示し、構成変更要求生成部３６４が出力する構成情報生成ポリシー２４０の一例を示す説明図である。
【図２２】本発明の実施形態を示し、監視対象リソース４００の一例を示す仮想計算機システムのブロック図である。
【図２３】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのツリー表現の一部を抜粋した図である。
【図２４】仮想化を適用した計算機システムの構成図をノード（頂点）とエッジ（辺）を用いて表現した例の説明図である。
【図２５】自動的にサービス提供レイヤーの統計情報からプラットフォームレイヤーの統計情報を算出するためのデータ表現を示した例である。
【図２６】本発明の実施形態を示し、稼働統計分析テーブル１１５の構成例である。
【図２７】本発明の実施形態を示し、稼働統計分析の演算を指定するポップアップウィンドウ入力画面２０１５の構成例である。
【図２８】本発明の実施形態を示し、自動的にサービス提供レイヤーの統計情報からプラットフォームレイヤーの統計情報を算出するフローチャートを示した図である。
【図２９】本発明の実施形態を示し、自動的にサービス提供レイヤーの統計情報からプラットフォームレイヤーの統計情報を算出した出力画面の構成例を示した画面イメージである。
【図３０】本発明の第１の変形例の実施形態を示し、性能分析ナビゲーション画面の構成例を示した図である。
【図３１】本発明の第１の変形例の実施形態を示し、性能分析ナビゲーションのフローチャートを示した図である。
【図３２Ａ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのＸＭＬ表現の一部を抜粋した図の前半部である。
【図３２Ｂ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのＸＭＬ表現の一部を抜粋した図の後半部である。
【図３３】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのＸＭＬ表現の一部を抜粋した図である。
【図３４Ａ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａから構成情報ＸＭＬ５００ｂに構成変更したときのＸＭＬ表現の変更部分を示した図の前半部である。
【図３４Ｂ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａから構成情報ＸＭＬ５００ｂに構成変更したときのＸＭＬ表現の変更部分を示した図の後半部である。
【図３５Ａ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａから構成情報ＸＭＬ５００ｂに構成変更したときのＸＭＬ表現の変更部分を示した図の前半部である。
【図３５Ｂ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａから構成情報ＸＭＬ５００ｂに構成変更したときのＸＭＬ表現の変更部分を示した図の後半部である。
【図３６】本発明の実施形態を示し、基準構成テーブルの一例を示す説明図である。
【図３７】本発明の実施形態を示し、ｘｐａｔｈ生成テーブルの一例を示す説明図である。
【図３８】本発明の実施形態を示し、構成管理マネージャで行われるノード生成処理の一例を示すフローチャートである。
【図３９】本発明の実施形態を示し、構成管理マネージャで行われる木構造生成処理の一例を示すフローチャートである。
【図４０】本発明の実施形態を示し、構成管理マネージャで行われるｘｐａｔｈ生成テーブル設定処理の一例を示すフローチャートである。
【図４１】本発明の実施形態を示し、構成管理マネージャで行われる構成情報生成処理の一例を示すフローチャートである。
【図４２】本発明の実施形態を示し、暫定構成ＸＭＬ３８５の構成例である。
【発明を実施するための形態】
【００２３】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００２４】
＜全体ブロック図＞
図１は、第１の実施形態を示し、本発明を適用する計算機モニタリングシステムを含む計算機システムの全体ブロック図である。計算機システムは、監視対象となる計算機リソース（以下、監視対象リソースとする）４００と、モニタリングシステム（モニタリング装置）１００、稼動情報集計部３００と、監視対象リソース４００の構成を管理する構成管理マネージャ３６０、およびモニタリングシステム１００が収集した情報を参照するモニタ端末３５０とから構成される。
【００２５】
監視対象リソース４００は、ラックや物理的なサーバ（物理計算機）と、ストレージと、ネットワークおよび物理的なサーバのリソース（物理リソース）を仮想化するソフトウェア（ハイパーバイザまたは仮想マシンモニタ）などを含むベースリソース４１０と、ベースリソース４１０の上に実装された仮想的なサーバ（仮想計算機）や、仮想的（または論理的）なストレージ、仮想的なネットワーク、および仮想的なサーバ上で動作するソフトウェア（ゲストＯＳ）などの仮想リソース４２０を含む。
【００２６】
仮想リソース４２０には、ベースリソース４１０や仮想リソース４２０のリソース使用状況を示す稼働情報の統計値（統計情報）や、ベースリソース４１０の消費電力、装置からの排気の温度等の環境情報、および稼働状態を表すログといった情報が含まれる。
【００２７】
稼動情報集計部３００は監視対象リソース４００と同一の計算機上で動作する場合も、異なる計算機上で動作する場合もある。本実施形態では稼動情報集計部３００は図２２に記載の物理サーバ４１１−１〜４１１−ｎのいずれかひとつで実行するものとする。なお、稼動情報集計部３００を実行するサーバは、物理サーバでも良いし、仮想サーバであってもよい。構成管理マネージャ３６０とモニタリングシステム１００も同様であり、異なる計算機上で実行させても良い。いずれの場合も差異は本発明の本質には影響しない。なお、本実施形態では、構成管理マネージャ３６０とモニタリングシステム１００も物理サーバ４１１−１〜４１１−ｎのいずれかひとつで実行するものとする。
【００２８】
本実施形態では、監視対象リソース４００がベースリソースと仮想リソースで構成されているものとする。
【００２９】
監視対象リソース４００のベースリソース４１０は、図２２に示す複数の物理計算機（物理サーバ）４１１−１〜４１１−ｎと仮想サーバ４２２を生成するサーバ仮想化部４２１を主体にして構成される。各計算機は物理的なプロセッサとメモリ及びインタフェースを有し、インタフェースを介してストレージ装置４５０とネットワーク４３０に接続される。これらの物理的な計算機リソースを物理リソースとする。そして、ベースリソース４１０には、メモリ４１３にロードされてプロセッサ４１２で実行されるサーバ仮想化部（ハイパーバイザまたはＶＭＭ）４２１が含まれる。つまり、ベースリソース４１０は物理リソースにサーバ仮想化部４２１（論理リソース）を加えたものである。したがって、以下の説明ではベースリソース４１０からサーバ仮想化部４２１を除いたものを物理リソースとする。
【００３０】
そして、本発明では、ベースリソース上で仮想リソースが稼動する、と定義する。
【００３１】
仮想リソース４２０は、仮想サーバ４２２−１〜４２２−ｍと、各仮想サーバ上で実行されるＯＳ４２３及びＯＳ４２３がアクセスするストレージ装置４５０のＬＵ（論理ディスク）４６５−１〜４６５−ｋや、仮想化されたＩ／Ｏデバイス（仮想ＮＩＣを、仮想ＨＢＡ）が含まれる。仮想リソース４２０は、サーバ仮想化部４２１が仮想サーバ４２２に対して割り当てる仮想または論理的なリソースで構成される。
【００３２】
なお、図示はしないが、サーバ仮想化部４２１上の仮想サーバ４２２でさらにサーバ仮想化部を稼動させる場合では、仮想サーバ４２２上のサーバ仮想化部をベースリソースとして扱うことができる。
【００３３】
ベースリソース４１０と仮想リソース４２０を含む監視対象リソース４００の具体的な例としては、例えば、図２２のようになる。
【００３４】
図２２は、監視対象リソース４００の一例を示す仮想計算機システムのブロック図である。ベースリソース４１０は、複数の物理サーバ４１１−１〜４１１−ｎとネットワーク４３０とＳＡＮ（Storage Area Network）４４０及びストレージ装置４５０及びサーバ仮想化部４２１から構成される。物理サーバ４１１−１〜４１１−ｎは同一の構成であるので、以下では物理サーバ４１１−１のみについて説明する。
【００３５】
物理サーバ４１１−１は、プロセッサ４１２、メモリ４１３、ＮＩＣ（Network Interface Card）４１４、ＨＢＡ（Host Bus Adapter）４１５から構成される。なお、図示はしないが物理サーバの起動、停止や監視を行うＢＭＣ（Baseboard Management Controller）を備えても良い。
【００３６】
プロセッサ４１２は、メモリ４１３内に格納された各種プログラムを実行する。ＨＢＡ４１５はＳＡＮ４４０を介してストレージ装置４５０に接続される。ＮＩＣ４１４はネットワーク４３０に接続される。ＮＩＣ４１４は、主にメモリ４１３上の各種プログラムからの要求に応じて他のサーバと通信する。ネットワーク４３０には、ベースリソース４１０を仮想リソース４２０へ割り当てる構成管理マネージャ３６０や、ベースリソース４１０及び仮想リソース４２０の構成要素の稼動情報を収集する稼動情報収集部３０５が接続される。なお、ネットワーク４３０にはモニタリングシステム１００やモニタ端末３５０が接続されても良い。
【００３７】
メモリ４１３上には、サーバ仮想化部４２１が稼働することで、複数の仮想サーバ４２２−１〜４２２−ｍを構築することができる。サーバ仮想化部４２１にはハイパーバイザとも呼ばれる仮想化技術が含まれる。なお、仮想サーバ４２２−１〜４２２−ｍの総称を仮想サーバ４２２とする。仮想サーバ４２２は、それぞれ独立してＯＳ（Operating System）４２３を稼働させることができる。プロセッサ４１２によりサーバ仮想化部４２１が実行されると、サーバ仮想化部４２１上で複数の仮想サーバ４２２を構築することができる。
【００３８】
サーバ仮想化部４２１は、構成管理マネージャ３６０の指令に応じて物理サーバ４１１−１の物理リソースを仮想化して、仮想サーバ４２２−１〜４２２−ｍを主体とする仮想リソース４２０に割り当てる。また、サーバ仮想化部４２１は、ＮＩＣ４１４やＨＢＡ４１５を仮想化して仮想サーバ４２２−１〜４２２−ｍに提供する。仮想化したＮＩＣ４１４やＨＢＡ４１５は、仮想ＮＩＣ（ｖＮＩＣ）や仮想ＨＢＡ（ｖＨＢＡ）とする。また、サーバ仮想化部４２１は、仮想サーバ４２２−１〜４２２−ｍに対してプロセッサ４１２（物理プロセッサ４１２）を仮想化した仮想プロセッサや、メモリ４１３を仮想化した仮想メモリを割り当てる。なお、サーバ仮想化部４２１がハイパーバイザの場合、プロセッサ４１２の複数のコアのうち所望のコア数を仮想サーバ４２２−１〜４２２−ｍに対して割り当てる。
【００３９】
仮想サーバ４２２はストレージ装置４５０に予め格納されたＯＳイメージをサーバ仮想化部４２１が読み込んで実行することで、それぞれ独立した仮想サーバ４２２が構築される。なお、以下では物理サーバ４１１−１〜４１１−ｎの総称を物理サーバ４１１とする。
【００４０】
ストレージ装置４５０は、コントローラ４８０とＲＡＩＤ Ｇｒｏｕｐ（以下、ＲＧ）４８５−１〜４８５−ｈとで構成されている。図２２ではコントローラ４８０は１個のみ存在しているが複数個存在することもある。コントローラ４８０は、ディスクドライブへのデータの読み書きやＳＡＮ４４０と接続するファイバチャネルインターフェースの制御を行っている。ＲＧ４８５−１〜４８５−ｈは、それぞれハードディスクドライブ（ＨＤＤ）を１個以上纏めたＲＡＩＤで構成される。各ＲＧ４８５−１〜４８５−ｈは、論理的なディスク装置（またはストレージデバイス）であるＬｏｇｉｃａｌ Ｕｎｉｔ（ＬＵ）４６５−１〜４６５−ｋに論理的に分割されている。それぞれのＬＵ４６５−１〜４６５−ｋは、個別に仮想サーバ４２２−１〜４２２−ｍからアクセス可能になっている。なお、ＬＵ４６５−１〜４６５−ｋは不揮発性の記憶媒体であればよく、ＨＤＤや不揮発性メモリで構成することができる。なお、本実施形態ではＲＧ４８５−１〜４８５−ｈをベースリソース４１０として扱い、ＬＵ４６５−１〜４６５−ｋを仮想リソース４２０として扱う。
【００４１】
複数の物理サーバ４１１−１〜４１１−ｎは、図８に示す複数のサーバシャーシ５２０にそれぞれ格納され、サーバシャーシ５２０はサーバラック５１０に格納されるラックマウントサーバで構成した例を示す。
【００４２】
図２は、モニタリングシステム１００の内部構成を示したブロック図である。モニタリングシステム１００は、各種情報を格納するモニタ情報データベース１１０、モニタ端末３５０とのインタフェースを制御する統計情報ＧＵＩ制御部２５０、構成情報ＧＵＩ制御部２６０、履歴情報ＧＵＩ制御部２７０と、統計情報ＧＵＩ制御部２５０からの指令に基づきモニタ情報データベース１１０をアクセスしてモニタ端末３５０へ出力する情報を決定する統計情報管理部１９０、構成情報管理部２００、履歴情報管理部２１０、稼働情報を統計処理するための計算式が登録されている稼働統計分析テーブル１１５と、が含まれる。これらの各機能はプログラムとして実装され、後述の図２２に示す記憶媒体としてのストレージ装置４５０に格納され、物理サーバ４１１のプロセッサ４１２によりメモリ４１３にロードされて実行される。
【００４３】
モニタ情報データベース１１０の中には、稼動統計テーブル１２０と、構成情報管理テーブル１３０と、構成情報変更履歴管理テーブル１４０と、コンポーネント履歴管理テーブル１５０などが格納される。なお、構成情報変更履歴管理テーブル１４０およびコンポーネント履歴管理テーブル１５０は構成情報管理テーブル１３０から二次的に生成される情報なので、本発明の実施においては必ずしも必要ではなく、表示を高速化するために用意されたテーブルである。また、構成管理マネージャ３６０から得られた構成情報２４５および構成情報生成ポリシー２４０に従って新たな構成情報を生成し、構成情報管理テーブル１３０へと格納する構成情報関連管理部２３０と、構成情報に割当てるＩＤを管理する割当済ＩＤ管理テーブル１６０もモニタリングシステム１００に含まれる。
【００４４】
構成管理マネージャ３６０から受け付ける構成情報生成ポリシー２４０の一例としては、例えば、同一の構成情報のリビジョン更新時には、各構成情報にそれぞれ付与されるコンポーネントＩＤを引き継ぎ、新たな構成情報の追加時には、新たなコンポーネントＩＤを割り当てる。また、構成情報の削除時にはコンポーネントＩＤを回収し、コンポーネントＩＤの使い回しを禁止する等のポリシーを予め設定したものである。
【００４５】
図２０は、構成管理マネージャ３６０の詳細を示すブロック図である。構成管理マネージャ３６０は、監視対象リソース４００についてベースリソース４１０と仮想リソース４２０の構成情報を格納する構成情報ＤＢ３６５と、ベースリソース４１０と仮想リソース４２０からプラットフォームツリー６００とサービス提供ツリー６１０を生成するための基準構成テーブル３８３と、ｘｐａｔｈ生成テーブル３８４と、暫定構成ＸＭＬ３８５を管理する。
【００４６】
構成管理マネージャ３６０は、構成情報ＤＢ３６５が更新される度にモニタリングシステム１００へ通知する。あるいは、図１のモニタ端末３５０から入力されるツリー変換要求３７３を受けたツリー変換設定３８１が、構成情報ＤＢ３６５に格納された構成情報を基準構成テーブル３８３に格納されているシステム要素間の関係を基準にして、ｘｐａｔｈ生成テーブル３８４や暫定構成ＸＭＬ３８５を用いてＸＭＬ形式の構成情報（構成情報ＸＭＬ３８６）を生成する。ツリー変換設定３８１が、この構成情報ＸＭＬ３８６を受けとった構成変更要求生成部３６４が、構成情報２４５でモニタリングシステム１００へ通知する。
【００４７】
モニタリングシステム１００は、構成管理マネージャ３６０からの通知を受信すると、割当済みＩＤ管理テーブル１６０や構成情報管理テーブル１３０等を更新する。
【００４８】
基準構成テーブル３８３と、ｘｐａｔｈ生成テーブル３８４は、上述の監視対象リソース４００（ベースリソース４１０と仮想リソース４２０）の構成要素を、後述する２つのデータ（ツリー）の各構成要素の親子関係の定義とツリーを分類するための定義を格納したものである。基準構成テーブル３８３に格納する要素は、基本的にモニタ端末３５０の入力装置等から管理者が設定する。あるいは、取得構成情報３７５のデータ型式が基準構成テーブル３８３の形式（図３６）で定義されているケースでは、取得構成情報３７５が基準構成テーブル３８３に格納される。構成管理マネージャ３６０は、モニタ端末３５０からプラットフォームツリー６００の要素とサービス提供ツリー６１０の要素を定義する基準構成入力３８２を受信すると、基準構成テーブル３８３を更新する。
【００４９】
なお、基準構成テーブル３８３と、ｘｐａｔｈ生成テーブル３８４と、暫定構成ＸＭＬ３８５は、モニタリングシステム１００から参照または更新することも可能である。また、モニタリングシステム１００は、基準構成テーブル３８３と、ｘｐａｔｈ生成テーブル３８４と、暫定構成ＸＭＬ３８５の複製をモニタ情報データベース１１０に保持しておいてもよい。
【００５０】
基準構成テーブル３８３は、プラットフォームツリー６００の親ノードと子ノードの木構造と、サービス提供ツリー６１０の親ノードと子ノードの木構造をそれぞれ定義するものである。
【００５１】
ｘｐａｔｈ生成テーブル３８４と暫定構成ＸＭＬ３８５は、モニタリングシステム１００がプラットフォームツリー６００とサービス提供ツリー６１０を生成するときに利用される。プラットフォームツリー６００とサービス提供ツリー６１０の生成については後述する。
【００５２】
構成管理マネージャ３６０は、サーバ仮想化部４２１に対して、仮想リソース４２０に対する物理リソース割り当てを制御する。つまり、構成管理マネージャ３６０は、仮想サーバ４２２に割り当てる物理サーバ４１１やストレージ装置４５０の監視対象リソース４００（計算機リソース）をサーバ仮想化部４２１に対して指令する。
【００５３】
また、構成管理マネージャ３６０は、物理サーバ４１１の稼動状態を制御する。構成管理マネージャ３６０は、仮想サーバ４２２の生成や削除あるいは移動の指令（構成情報及び構成情報生成ポリシーを含む構成変更指令）を監視対象リソース４００の仮想化部４２１に指令して、各物理サーバ４１１の仮想サーバ４２２を制御する。また、構成管理マネージャ３６０は、監視対象リソース４００に指令した構成変更指令の構成情報２４５及び構成情報生成ポリシー２４０をモニタリングシステム１００に通知する。
【００５４】
モニタリングシステム１００が監視する監視対象リソース４００が、予め構築されている場合、構成管理マネージャ３６０に対して管理者が構成取得要求３７２を入力し、構成取得要求生成部３７１で構成取得コマンド３７４を生成し、監視対象リソース４００に発行する。構成取得コマンド３７４の実装形態の一つとしてはＳＮＭＰやＣＩＭ、ＳＭＩ−Ｓ、ＳＭＡＳＨのようなシステムの運用管理の為の標準インタフェースが挙げられる。
【００５５】
構成取得コマンド３７４の応答として監視対象リソース４００からの応答である取得構成情報３７５を構成管理マネージャ３６０が受信すると、構成変更要求生成部３６４に入力され、構成情報ＤＢ３６５に格納される。また、取得構成情報３７５のデータ型式が基準構成テーブル３８３（図３６）と同じ形式である場合は、基準構成テーブル３８３にも入力される実装をしてもよい。
【００５６】
構成取得コマンド３７４に対して監視対象リソース４００からの応答である取得構成情報３７５は、構成変更要求生成部３６４によって構成情報ＤＢ３６５に格納される。次に、構成変更要求生成部３６４は、ツリー変換設定３８１に構成情報ＸＭＬを作成するように要求を出し、ツリー変換設定３８１は、構成情報ＤＢ３６５と基準構成テーブル３８３とｘｐａｔｈ生成テーブルと３８４と暫定構成ＸＭＬ３８５とを使って構成情報ＸＭＬ３８６を作成する。次に、構成変更要求生成部３６４は、構成情報ＸＭＬ３８６を変更後構成情報２４５ｙとして構成変更情報送信部３６２に送り、構成情報２４５として構成情報関連管理部２３０に転送する。このとき、変更前構成情報２４５ｘは、“空”のデータが渡される。構成情報関連管理部２３０では、図２の構成情報管理部２００を経て、構成情報管理テーブルに格納される。
【００５７】
構成取得コマンド３７４で自動的に採取できない構成情報、例えば運用管理機構を持たないラックマウントのような情報処理装置を格納する棚のような場合、管理者が、構成入力３７２０や基準構成入力３８２を通して、直接的に構成管理マネージャ３６０に入力する。
【００５８】
構成管理マネージャ３６０は、モニタ端末３５０の図示しない入出力装置から監視対象リソース４００に対する構成変更要求３６６を受け付け、構成変更要求３６６が完了すると入出力装置へ構成変更完了通知３６７を出力する構成変更要求処理部３６１と、監視対象リソース４００の構成情報を格納する構成情報データベース３６５と、構成変更要求処理部３６１からの構成変更要求処理部３６１と構成情報データベース３６５の構成情報に基づいて、変更前の構成情報２４５ｘと変更後の構成情報２４５ｙと構成情報の生成ポリシー２４０を生成する構成変更要求生成部３６４と、変更前構成情報２４５ｙと変更後構成情報２４５ｙを構成情報２４５とし、構成情報生成ポリシー２４０と構成情報２４５をモニタリングシステム１００の構成情報関連管理部２３０と構成変更処理指示部３６３送信する構成変更情報送信部３６２と、構成情報生成ポリシー２４０と構成情報２４５に基づいて監視対象リソース４００のサーバ仮想化部４２１に構成変更要求３６６を送信する構成変更処理指示部３６３と、を含んで構成される。
【００５９】
構成情報データベース３６５は、後述の図４に示す構成情報管理テーブル１３０のプラットフォームツリー６００とサービス提供ツリー６１０と同様の構成を備える。ただし、構成情報データベース３６５は、構成情報管理テーブル１３０の構成情報５００（構成情報ＸＭＬ５００ａ〜５００ｃの総称）に含まれる構成要素についてコンポーネントＩＤを有していない。コンポーネントＩＤは、モニタリングシステム１００の構成情報関連管理部２３０が、新たな構成情報２４５を受け付けると新たなコンポーネントＩＤを付与する。
【００６０】
構成管理マネージャ３６０は、モニタ端末３５０の入出力装置（図示省略）から構成変更要求３６６を受け付けると、構成変更要求３６６に含まれるポリシーと、変更前（現在）の構成情報２４５ｘと変更後の構成情報２４５ｙを受け付けて、構成情報２４５と構成情報生成ポリシー２４０をモニタリングシステム１００と監視対象リソース４００に送信する。
【００６１】
そして、構成管理マネージャ３６０は、構成変更要求処理部３６１の処理が完了すると入出力装置へ構成変更完了通知３６７を出力し、新たな構成情報２４５ｙで構成情報データベース３６５を更新する。
【００６２】
また、構成情報管理テーブル１３０の構成情報５００の構成要素に付与されるコンポーネントＩＤは、構成情報関連管理部２３０が付与するモニタリングシステム１００内で一意の値である。このコンポーネントＩＤは、構成情報５００を構成する構成要素の木構造に関わりなく、一意の識別子を構成情報の構成要素毎に構成情報関連管理部２３０が割り当てるものである。コンポーネントＩＤは、監視対象リソース４００の構成要素であるベースリソース４１０の構成要素と、仮想リソース４２０の構成要素のそれぞれについて一意の値が割り当てられる。
【００６３】
すなわち、監視対象リソース４００の構成要素は木構造で構成される階層的な情報であるのに対し、コンポーネントＩＤはモニタリングシステム１００内で一意の識別子として機能する。コンポーネントＩＤは、後述する割当済ＩＤ管理テーブル１６０のように、ベースリソース４１０の構成要素と仮想リソース４２０の構成要素及び統計情報に対してそれぞれ割り当てられる。マイグレーションなどの構成要素の変更を実施するときは、このコンポーネントＩＤを構成変更が行われた構成要素が引き継ぐことで、構成要素に関連付けられた統計情報を、構成変更の前後で結びつけることが可能となる。
【００６４】
図２１は、構成管理マネージャ３６０の構成変更要求生成部３６４が出力する構成情報生成ポリシー２４０の一例を示す説明図である。構成変更要求生成部３６４は、構成変更要求処理部３６１から受け付けた構成変更要求３６６から、変更前の構成情報のノード（部分木）と変更後の構成情報のノード情報及びノード間の関係を抽出し、変更前の構成情報のノードを変更前ノード２４１とし、変更後の構成情報のノードを変更後ノード２４２とし、ノード間の関係をノード間関連２４３として構成情報生成ポリシー２４０を生成する。
【００６５】
ノード間関連２４３としては、「重複しない割当」、「同一ノードを継承」、「移動元」、「移動先」、「交替元」、「交替先」などに分類される。
【００６６】
「重複しない割当」のノード間関連２４３は、ひとつの仮想サーバ４２２を、昼夜で切り替えて使用する場合などで、変更対象のノードが同一で、異なる構成情報ＩＤ（１６２）が割り当てられた構成情報間では、コンポーネントＩＤが重複しないように割り当てるように、構成管理マネージャ３６０はモニタリングシステム１００に指令する。図示の「重複しない割当」の例では、ノードａで構成要素を切り替えて、変更後のノードａの構成要素に新たなコンポーネントＩＤを付与することを示す。
【００６７】
図２１の「同一ノードを継承」のノード間関連２４３は、構成要素が変化しない場合であり、図示の例ではノードｂは構成情報変更の前後で同一のコンポーネントＩＤを引き継ぐことを示す。また、「移動元」および「移動先」のノード間関連２４３は、ノードが移動する場合であり、図示の例では移動元のノードｃがノードｄとして移動することを示す。この場合、モニタリングシステム１００ではノードｃに割り当てられた構成要素のコンポーネントＩＤを変更後の構成情報ではノードｄのコンポーネントＩＤとして付与する。
【００６８】
「交替元」と「交替先」のノード間関連２４３は、現用系と待機系で系切替を行う場合であり、図示の例ではノードｅを交替元として、ノードｆに構成要素を移動することを示す。この場合、モニタリングシステム１００ではノードｅに割り当てられた構成要素のコンポーネントＩＤを、ノードｆの構成要素に割り当てられたコンポーネントＩＤに上書きする。
【００６９】
＜構成変更処理の概要＞
図１の計算機システムで行われる処理の一例を以下に示す。
【００７０】
構成管理マネージャ３６０は、監視対象リソース４００の構成を変更する度にモニタリングシステム１００に構成情報２４５と構成情報生成ポリシー２４０及び基準構成テーブル３８３を通知し、モニタリングシステム１００は通知を受けた構成情報２４５と構成情報生成ポリシー２４０と基準構成テーブル３８３から構成情報管理テーブル１３０のプラットフォームツリー６００とサービス提供ツリー６１０を更新する。
【００７１】
モニタリングシステム１００は、例えば、新たな構成情報２４５を受け付けると、構成情報管理テーブル１３０に当該構成情報２４５の内容（例えば、物理サーバ４１１や仮想サーバ４２２あるいはＩ／Ｏデバイス）を構成情報１３４の構成情報ＸＭＬに加え、構成情報ＸＭＬに含まれる構成要素毎に計算機システム内でユニークなコンポーネントＩＤ１６１を割り当てる。
【００７２】
一方、モニタ端末３５０から、監視対象リソース４００に対する稼動情報の収集要求が稼動情報集計部３００に送信されると、稼動情報集計部３００は要求された監視対象リソース４００に対する稼動情報の収集及び稼動情報の統計値（統計情報）に関する定義を格納し、統計値に対して統計値ＩＤを付与する。稼動情報集計部３００は、稼動情報の統計値の収集対象となった監視対象リソース４００の構成情報ＩＤと統計情報（ＣＰＵ使用率、メモリ使用量など）と統計値ＩＤを対応させてモニタリングシステム１００に通知する。
【００７３】
モニタリングシステム１００は、稼動情報集計部３００から構成情報ＩＤと統計値ＩＤを受け付けて、構成情報管理テーブル１３０のプラットフォームツリー６００とサービス提供ツリー６１０の該当するレコードの構成情報ＸＭＬに、統計値ＩＤと統計情報を格納する。これにより、監視対象リソース４００内で一意の識別子であるコンポーネントＩＤと統計値ＩＤが関連づけられる。
【００７４】
次に、構成管理マネージャ３６０が仮想サーバ４２２の移動を実施すると、モニタリングシステム１００は構成管理マネージャ３６０から構成情報２４５と構成情報生成ポリシー２４０を受け付けて、構成情報生成ポリシー２４０の内容が「交替（交替元、交替先）」であれば、構成情報２４５で指定された移動元のコンポーネントＩＤとコンポーネントＩＤに関連付けられた統計値ＩＤを、移動先の構成情報のコンポーネントＩＤに引き継がせる。これにより、コンポーネントＩＤに関連付けられた統計値ＩＤも構成情報の移動先に引き継がれる。また、構成情報管理テーブル１３０では、構成情報の変更の履歴をリビジョンとして記録する。
【００７５】
稼動情報集計部３００は、所定のタイミングで監視対象リソース４００の監視を行い、指定された稼動情報を収集し、稼動情報に所定の統計処理を施した統計情報をモニタリングシステム１００の稼動統計テーブル１２０に統計値ＩＤとともに格納する。稼動情報集計部３００が監視対象リソース４００の監視を行うタイミングは、構成情報収集パラメータ３１０のモニタ間隔３１４で定義される。なお、統計処理は、平均値や最大値または最小値、標準偏差など、稼動情報に所定の統計処理を施して統計情報を生成する処理である。
【００７６】
モニタ端末３５０が、統計情報をモニタリングシステム１００に要求すると、モニタリングシステム１００は指定された構成情報のコンポーネントＩＤを構成情報管理テーブル１３０から検索し、当該コンポーネントＩＤに関連づけられた統計値ＩＤを取得する。そして、モニタリングシステム１００は、統計値ＩＤに対応する統計情報を稼動統計テーブル１２０から取得して、モニタ端末３５０に出力する。
【００７７】
仮想サーバ４２２を物理サーバ４１１間で移動させても、構成情報生成ポリシー２４０のノード間関連２４３が「同一ノードを継承」等であれば、コンポーネントＩＤと統計値ＩＤはそのまま移動先の構成情報１３４（構成情報ＸＭＬ）に引き継がれるので、仮想サーバ４２２の統計値ＩＤに対応する統計情報を、移動の前後を跨いでモニタ端末３５０で表示することが可能となる。また、モニタ端末３５０が構成情報の履歴をモニタリングシステム１００に要求すると、仮想サーバ４２２の移動の前後の構成情報の履歴をモニタ端末３５０に出力することができる。
【００７８】
以下では、モニタリングシステムの構成要素、及び動作について図面を用いて説明をする。
【００７９】
＜モニタ情報データベース内の各種テーブル＞
図３は稼動統計テーブル１２０の構成例である。統計情報管理部１９０が管理する統計値（統計情報）１２３を格納するテーブルである。各レコードはデータ名称１２９、統計値ＩＤ１２１、タイムスタンプ１２２および１つ以上の統計値１２３から構成される。ここでは統計値１２３として平均値１２４、最小値１２５、最大値１２６、標準偏差１２７、標本数１２８を選んだが、一部でも良いし、これ以外の統計情報で表現してもよい。
【００８０】
稼動統計テーブル１２０は、後述するように稼動情報集計部３００が収集した監視対象リソース４００の稼動情報の統計値を格納する。統計値１２３は、統計値ＩＤ毎に予め設定された単位を有し、例えば、プロセッサの使用率（％）やメモリの使用量（ＧＢ）や単位時間当たりのインタフェースのデータ転送量（Ｉ／Ｏトラフィック：ＧＢ／ｓｅｃ）などである。
【００８１】
図４は、モニタリングシステム１００の構成情報管理テーブル１３０の構成例である。構成情報管理テーブル１３０は、構成管理マネージャ３６０から受信した構成情報２４５を蓄積するモニタ情報データベース１１０のテーブルで、構成管理マネージャ３６０が管理する構成情報の履歴（リビジョン）を格納する。モニタリングシステム１００は、起動すると構成管理マネージャ３６０から構成情報データベース３６５を受信して、現在の監視対象リソース４００の構成情報２４５を構成情報管理テーブル１３０に格納する。
【００８２】
構成情報管理テーブル１３０の各レコードは構成情報ＩＤ１３５、リビジョン１３１、開始日時１３２、終了日時１３３、および構成情報１３４のフィールドから構成される。ここで、構成情報１３４を管理する手法は色々考えられるが、たとえばＸＭＬ形式の構成情報データ５００を作成し、当該構成情報データへのリンクやファイル名を構成情報１３４のフィールドに登録する方法が考えられる。もちろん、構成情報１３４のフィールドにＸＭＬ形式の構成情報データを格納することもできる。なお、終了日時１３３の値が“−”またはＮＵＬＬであるレコードは、最新の構成情報であることを示している。
【００８３】
図４の例では、構成情報ＩＤ１３５＝１である構成情報に対して、３つのリビジョン１３１の構成情報が登録されており、リビジョン１３１＝１とリビジョン１３１＝２のレコードには終了日時１３３が設定されているが、リビジョン１３１＝３のレコードには終了日時１３３が設定されておらず（”−”）、リビジョン１３１＝３の構成情報が現在使用中（最新）のリビジョンであることを示す。各リビジョンに対応する構成情報ＸＭＬ５００ａ、５００ｂ、５００ｃをそれぞれ後述する図８、図９、図１０に示す。ただし、図８、図９、図１０では説明を簡単化するため、稼動情報の統計情報に係る構成情報は省略してある。
【００８４】
モニタリングシステム１００は、構成管理マネージャ３６０から構成情報２４５を受け付けて、監視対象リソース４００の構成情報を世代（リビジョン）毎に構成情報管理テーブル１３０へ格納する。構成情報管理テーブル１３０と構成管理マネージャ３６０の構成情報データベース３６５は、上述したように同様の構成である。このため、構成管理マネージャ３６０は、新たな構成情報２４５ｙを生成すると新たな構成情報ＩＤ１３５とリビジョン１３１＝１を生成する。
【００８５】
なお、構成管理マネージャ３６０で監視対象リソース４００の構成情報の履歴（世代）を管理しない場合では、モニタリングシステム１００の構成情報管理部２００がリビジョン１３１を管理すればよい。この場合、構成情報管理部２００は、同一の構成情報ＩＤ１３５に対して新たな構成情報２４５を受け付けると、現在のリビジョン１３１をインクリメントした値を、新たな構成情報を格納するレコードのリビジョン１３１に最新の世代を示す値を設定する。
【００８６】
図５は構成情報変更履歴管理テーブル１４０の構成例である。構成情報変更履歴管理テーブル１４０は、モニタリングシステム１００の履歴情報管理部２１０が管理する構成情報の履歴（リビジョン）を格納する。各レコードは履歴ＩＤ１４１、構成変更のあった時点のタイムスタンプ１４２、構成情報ＩＤ１４７、変更前リビジョン１４３、変更後リビジョン１４４、作業手順８３０へのリンク１４５、関連コンポーネントＩＤリスト１４６、の各フィールドから構成される。
【００８７】
履歴ＩＤ１４１は、構成情報管理部２１０が設定する値で、一意の識別子が付与される。作業手順１４５は構成情報変更時にどのような変更があったのかをモニタ端末３５０へ出力して管理者やユーザが見てわかりやすくするためのテキスト列またはテキスト列へのポインタで、構成情報の差分から自動的に生成する方法や、構成管理マネージャ３６０での構成変更指示時に管理者にコメントとして入力させる方法などが考えられる。関連コンポーネントＩＤリスト１４６は、該当する構成変更の影響を受けるコンポーネントＩＤのリストである。
【００８８】
図６はコンポーネント履歴管理テーブル１５０の構成例である。コンポーネント履歴管理テーブル１５０は、モニタリングシステム１００の履歴情報管理部２１０が管理するテーブルで、構成変更の影響を受けたコンポーネントＩＤ１５１に関してのみレコードが登録される。
【００８９】
各レコードはコンポーネントＩＤ１５１、新たな構成の開始日時１５２、当該構成の終了日時１５３、構成情報ＩＤ１５５、リビジョン１５４の各フィールドから構成される。終了日時１５３の値が”−”あるいはＮＵＬＬであるレコードは、そのリビジョンが最新であることを示す。
【００９０】
図６の例では、コンポーネントＩＤ１５１が「３」であるコンポーネントはリビジョン１５４が「１」から「２」に変更された時の影響は受けたが、リビジョン１５４が「２」から「３」へ変更されたときには構成変更の影響は受けていないため、リビジョン１５４＝２が最新である。一方、コンポーネントＩＤ１５１が「９」であるコンポーネントは２回の構成変更の影響を共に受けているため、リビジョン１５４＝３が最新となっている。
【００９１】
＜構成情報ＸＭＬのツリー表現＞
図７は構成情報管理テーブル１３０の構成情報１３４に格納される構成情報ＸＭＬ５００ａのツリー表現の一部を抜粋した図である。図７の例は、図４に示したリビジョン１３１＝１の構成情報１３４をツリー（部分木）にて表現した例である。
【００９２】
構成情報は、プラットフォームツリー６００とサービス提供ツリー６１０の二種類のデータ構造に分割される。
【００９３】
プラットフォームツリー６００は、物理リソースを主体としたシステム構成や仮想リソースを主体とした構成のように、ある一種類の“プラットフォーム”という界面で閉じた空間に存在するシステム要素の接続関係を表したデータである。換言すれば、プラットフォームツリー６００は、計算機リソースのカテゴリー（プラットフォーム）毎に、構成要素の接続関係を解析した木構造のデータである。
【００９４】
一方、サービス提供ツリー６１０は、ある一つの計算機リソースを仮想的（または論理的に）に１個以上の要素に分割した接続関係を表すデータである。換言すれば、サービス提供ツリー６１０は、監視対象リソース４００を利用するクライアント計算機（図示省略）が識別可能な仮想リソースを子ノードに持ち、当該子ノードとプラットフォームツリー６００の親ノードの関係を示す木構造のデータである。
【００９５】
そして、プラットフォームツリー６００の要素と、サービス提供ツリー６１０の親ノードの接続関係は、相互参照４９０（図中破線）で示される。相互参照４９０は、基準構成テーブル３８３で定義された親属性（図３６中でｐａｒｅｎｔと記載）要素と子属性（図３６中でｃｈｉｌｄと記載）要素の接続関係を示すデータであり、図３７のｘｐａｔｈ生成テーブル３８３のプラットフォームツリーｘｐａｔｈ３９６とサービス提供ツリーｘｐａｔｈ３９７のデータで表現される。なお、親属性は上位要素となり、子属性は下位要素となる。
【００９６】
なお、ネットワーク４３０を介して仮想サーバ４２２を利用するクライアント計算機が存在する場合、クライアント計算機がアクセスする仮想サーバ４２２、ＯＳ４２３、ＬＵ４６５等の仮想リソース４２０がサービス提供ツリー６１０に含まれる。換言すれば、仮想サーバ４２２のユーザが利用するクライアント計算機から識別可能な計算機リソースをサービス提供ツリー６１０として扱うことができる。
【００９７】
監視対象リソース４００の全体構成は、プラットフォームツリー６００とサービス提供ツリー６１０を相互参照４９０のポインタ（または参照情報）で接続することで表現する。このように、計算機リソース（ベースリソース４１０と仮想リソース４２０）の構成要素を主旨の異なる別々のツリー構造にする理由を、図２４を用いて示す。
【００９８】
図２４は、仮想化を適用した計算機システム（監視対象リソース４００）の構成図をノード（頂点）とエッジ（辺）を用いて表現した例の説明図である。図２４のように、仮想化された計算機システムをグラフで表現すると、木構造にはなっておらずＸＭＬ形式で構成を管理することは困難である。例えば、仮想サーバα、βに接続しているディスクパーティション（図２４のＬＵ０、ＬＵ１）が、論理的には分離していても物理的には同一のＲＡＩＤ上（図２４のＲＧ０）上に構成されている。このため、木構造で計算機システムを表現すると、図２４のＬＵ０，ＬＵ１のように、どの仮想リソースが同じ物理リソース上に展開されているか判断がつかなくなる。つまり、図２４において、ストレージ装置のＲａｉｄＧｒｏｕｐ０には、ＬＵ０とＬＵ１が存在するが、ＬＵ０にアクセスする仮想ＨＢＡ（ｖＨＢＡ００）は、物理的なＩ／ＯデバイスであるＨＢＡ０に接続されたパスと、仮想サーバαに接続される２つのパスが存在する。このため、木構造のデータとして表現することが難しい。
【００９９】
このような仮想計算機システムで、ある仮想サーバに接続したＬＵに対して過大な負荷、例えば、データベースで全件検索をかけるようなケースでは、同一のＲＧ上に展開した他のＬＵを使っている別の仮想サーバの性能が何の前触れもなく性能がスローダウンしてしまうケースも起こりうる。このような事態の原因分析を迅速に行うためには、物理リソースを含むベースリソース４１０と仮想リソース４２０の関係を正確に把握できることが必要であり、一つのベースリソース４１０を１個以上の仮想リソース４２０として分割して使用している部分を切り出して管理することで原因分析の効率が向上する。一方、実際の仮想サーバのシステム構築のケースにおいては、物理リソースを論理的に分割する操作は必ず一つの作業として定義される。例えば、ハイパーバイザを操作して仮想マシンを構築する操作が挙げられる。このような仮想化の作業を別に切り出すことができるという事実から、構成情報を表すデータ構造上でも仮想化をしている部分を別に切り出して管理することは、実作業とのマッチングが図りやすくモニタリングツールを使った管理作業のイメージが管理者につかみやすいという利点もある。
【０１００】
図２３は、図７から木構造のデータだけを抽出した監視対象リソース４００の構成要素を表している。プラットフォームツリー６００は、サーバラック５１０をルートノードにして物理サーバをプラットフォームとして表すツリーと、仮想サーバをプラットフォームとして表すツリーと、ストレージ装置をプラットフォームとして表すツリーが別々に定義されている。
【０１０１】
プラットフォームツリー６００で親ノードと子ノードになる構成要素の定義は、構成管理マネージャ３６０の基準構成テーブル３８３で定義される。基準構成テーブル３８３は、図３６で示すように、管理者などがモニタ端末３５０で設定した監視対象リソース４００の親子関係を示す定義情報で構成される。
【０１０２】
図３６において、基準構成テーブル３８３は、要素名３９０と、プラットフォームツリー構成要素ＸＭＬ３９１と、サービス提供ツリー構成要素ＸＭＬ３９２からひとつのレコードが構成される。
【０１０３】
要素名３９０には、監視対象リソース４００の構成要素の名称（または識別子）が格納される。プラットフォームツリー構成要素ＸＭＬ３９１には、子ノードとなる構成要素が＜ｃｈｉｌｄ＞に設定され、サービス提供ツリー６１０で親ノードとなる構成要素の場合では＜ｐａｒｅｎｔ＞に当該要素名の構成要素が設定される。サービス提供ツリー構成要素ＸＭＬ３９２には、親ノードとなる構成要素が＜ｐａｒｅｎｔ＞に設定され、子ノードとなる構成要素が＜ｃｈｉｌｄ＞に設定される。
【０１０４】
例えば、図３６において、要素名３９０＝「サーバラック」は、プラットフォームツリー構成要素ＸＭＬ３９１に、「ＳｅｖｅｒＣｈａｓｓｉｓ」が＜ｃｈｉｌｄ＞に設定されて、子ノードがサーバシャーシ５２０であることを示す。そして、プラットフォームツリー構成要素ＸＭＬ３９１の＜ｐａｒｅｎｔ＞には空（ｎｕｌｌ）が設定されて、親ノードが存在しないルートノードであることを示す。また、要素名３９０＝「サーバラック」は、サービス提供ツリー構成要素ＸＭＬ３９２の各構成要素の全てが空（ｎｕｌｌ）であるため、サービス提供ツリー６１０には存在しないことを示す。
【０１０５】
一方、要素名３９０＝「ハイパーバイザ」は、プラットフォームツリー構成要素ＸＭＬ３９１の＜ｐａｒｅｎｔ＞に「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」が設定され、＜ｃｈｉｌｄ＞には＜ｘｐａｔｈ＞として「ＶｉｒｔｕａｌＳｅｒｖｅｒ」が設定される。これにより、プラットフォームツリー６００では、ハイパーバイザの親ノードが物理サーバで、子ノードが仮想サーバであることを示す。また、要素名３９０＝「ハイパーバイザ」のサービス提供ツリー構成要素３９２は、＜ｃｈｉｌｄ＞に＜ｘｐａｔｈ＞として「ＶｉｒｔｕａｌＳｅｒｖｅｒ」が設定される。これにより、サービス提供ツリー６１０では、ハイパーバイザが親ノードで、子ノードが仮想サーバであることを示す。
【０１０６】
そして、プラットフォームツリー構成要素ＸＭＬ３９１とサービス提供ツリー構成要素ＸＭＬ３９２の＜ｘｐａｔｈ＞で定義された「ｖａｌｕｅ」が、相互参照４９０を構成してプラットフォームツリー６００のノードと、サービス提供ツリー６１０の親ノードの接続関係を定義する。
【０１０７】
図７に示すプラットフォームツリー６００は、図３６の基準構成テーブル３８３で、サーバラック５１０，仮想サーバ４２２、ストレージ装置４５０をルートノードとして定義した例を示し、サービス提供ツリー６１０の親ノードとしてサーバ仮想化部４２１０，ＨＢＡ４１５０、ＲＧ４８５０を設定したものである。そして、サービス提供ツリー６１０の各親ノードとプラットフォームツリー６００の子ノードの接続関係は＜ｘｐａｔｈ＞によって定義される。
【０１０８】
また、モニタリングシステム１００は、後述の基準構成テーブル３８１（図３６）を参照して、モニタ端末３５０の入力装置から指定された構成情報について、基準構成テーブル３８３の定義に基づいて親ノードを抽出してサービス提供ツリー６１０を生成する。親ノードの抽出は、基準構成テーブル３８１の各要素で、ｐａｒｅｎｔ属性の要素がｎｕｌｌ（＜ｐａｒｅｎｔ＞＜／ｐａｒｅｎｔ＞と図３６では記載）になっていれば親ノードであることが抽出できる。
【０１０９】
なお、プラットフォームツリー６００とサービス提供ツリー６１０は、図３２Ａ、図３２Ｂに示すＸＭＬ情報としてモニタリングシステム１００の構成情報管理テーブル１３０に格納される。
【０１１０】
仮想化環境のプラットフォームとしての物理サーバを表すツリーは、サーバラック５１０を親ノード（頂点）とし、その下位にサーバラック５１０に格納されるサーバシャーシ５２０と、その下位にサーバシャーシ５２０に格納される物理サーバ４１１、さらにその下位には、物理サーバ４１１に接続されたＨＢＡ４１５と、物理サーバ４１１で実行されるサーバ仮想化部（ハイパーバイザ）４１２の階層関係を示す。また、物理サーバ４１１の下位には、物理サーバ４１１の統計情報５６０Ａ、５６０Ｂが関係づけられている。さらに、サーバ仮想化部４２１の下位にはハイパーバイザの統計情報５７０が関連付けられている。なお、サーバラック５１０、サーバシャーシ５２０と物理サーバ４１１の関係等のモニタリングシステム１００が識別できない構成については、管理者などがモニタ端末３５０から設定する。
【０１１１】
仮想サーバのプラットフォームを表すツリーは、仮想サーバ４２２を親ノードとし、その下位に仮想ＨＢＡ（ｖＨＢＡ）４６０、その下位にＬＵ４６５、その下位にパーティション４７０の接続関係を示している。仮想サーバ４２２には、仮想サーバ４２２のＣＰＵ使用率やメモリ使用量といった統計情報５５０が関連付けされている。さらに、パーティション４７０には、ディスク（ＬＵ）のスループットやアクセス要求の待ち行列長、ディスクのビジー率といった統計情報５８０が関連付けされている。
【０１１２】
ストレージ装置４５０のプラットフォームを表すツリーは、ストレージ装置４５０を親ノードとし、その下位にコントローラ４８０、その下位にＲＧ（ＲＡＩＤ Ｇｒｏｕｐ）４８５が存在する接続関係を示している。
【０１１３】
サービス提供ツリー６１０には、基準構成テーブル３８３の各要素で定義された親子関係（ｐａｒｅｎｔ属性とｃｈｉｌｄ属性の関係）から、構成要素のツリーが生成される。例えば、図３６のサービス提供ツリー構成要素ＸＭＬ３９２においては、要素名３９０の“ハイパーバイザ“の行にある要素（ＸＭＬ記述）がサーバ仮想化部（ハイパーバイザ）４２１０を親ノードとして表し、そのハイパーバイザの下には要素名３９０が”仮想サーバ“の行にある要素（ＸＭＬ記述）が仮想サーバ４２２０をして表現されている。また、それぞれのノードの接続関係は、各要素ＸＭＬのｐａｒｅｎｔ属性やｃｈｉｌｄ属性で表現されている。後述する図２５のように、サービス提供ツリー６１０の各要素（ツリーを構成する各ノード）にも、プラットフォームツリー６００で存在した統計情報が関連付けられている。
【０１１４】
プラットフォームツリー６００とサービス提供ツリー６１０は、図７に示すような相互参照４９０（図７の凡例）で関連するノードが相互に接続されている。データ構造上は、図３２Ａ、図３２Ｂ、図３３、図３６に示すｘｐａｔｈで関連付けをしている。なお、相互参照４９０には、図３６で示す＜ｘｐａｔｈＩＤ＞が付与され、この識別子により相互参照４９０の特定を行うことができる。
【０１１５】
図７において、プラットフォームツリー６００の子ノードであるサーバ仮想化部４２１が、サービス提供ツリー６１０の子ノードである仮想サーバ４２２０に参照される。そして、サービス提供ツリー６１０の子ノードである仮想サーバ４２２０が、プラットフォームツリー６００の仮想サーバ４２２に参照される。また、プラットフォームツリー６００の仮想ＨＢＡ４６５は、サービス提供ツリー６１０の子ノードである仮想ＨＢＡ（ｖＨＢＡ）４６５０を参照し、ｖＨＢＡ４６５０の親ノードであるＨＢＡ４１５０がプラットフォームツリー６００のＨＢＡ４１５を参照する。また、プラットフォームツリー６００の子ノードであるＲＧ４８５は、サービス提供ツリー６１０の親ノードであるＲＧ４８５０に参照され、子ノードであるＬＵ４６５０は、プラットフォームツリー６００のＬＵ４６５を参照する。
【０１１６】
このように、本発明のプラットフォームツリー６００とサービス提供ツリー６１０により、仮想サーバ４２２と、仮想サーバ４２２が利用するベースリソースの関係を漏れなく、かつ少ない手数で管理することが可能となる。
５を参照する。
【０１１７】
＜構成情報の生成＞
次に、プラットフォームツリー６００とサービス提供ツリー６１０を提供する図３２Ａ〜図３３の構成情報ＸＭＬ５００ａの生成について以下に説明する。
【０１１８】
構成管理マネージャ３６０は、監視対象リソース４００の構成要素と基準構成テーブル３８３から構成情報５００を生成して、構成情報データベース３６５に格納する。そして、構成管理マネージャ３６０は構成情報５００をモニタリングシステム１００に通知する。モニタリングシステム１００では、構成情報５００にコンポーネントＩＤを付与した情報を構成情報ＸＭＬ５００ａとして構成情報管理テーブル１３０に格納する。構成情報ＸＭＬ５００ａは、図３２Ａ、図３２Ｂに示すプラットフォームツリー６００と、図３３に示すサービス提供ツリー６１０に分類される。
【０１１９】
図３８〜図４１は、構成管理マネージャ３６０で行われる構成情報５００の生成処理の一例を示すフローチャートである。
【０１２０】
構成管理マネージャ３６０は、モニタ端末３５０からの指示によって図３８のフローチャートを実行し、暫定構成ＸＭＬ３８５を生成し、プラットフォームツリー６００とサービス提供ツリー６１０のノードを設定する（ノード生成処理）。次に、構成管理マネージャ３６０は、図３９のフローチャートを実行して、暫定構成ＸＭＬ３８５から各ノードの木構造を生成する。次に、構成管理マネージャ３６０は、図４０のフローチャートを実行して、暫定構成ＸＭＬ３８５からプラットフォームツリー６００とサービス提供ツリー６１０の相互参照４９０を示すｘｐａｔｈを抽出し、図３７に示すｘｐａｔｈ生成テーブル３８４を生成する。最後に、構成管理マネージャ３６０は、図４１のフローチャートを実行して、暫定構成ＸＭＬ３８５とｘｐａｔｈ生成テーブル３８４から、暫定構成ＸＭＬ３８５にｘｐａｔｈを組み込んで、構成情報５００を生成し、構成情報２４５としてモニタリングシステム１００に送る。この構成情報５００は構成情報管理テーブル１３０に格納される。また、構成情報５００は、構成情報データベース３６５に登録してもよい。
【０１２１】
まず、図３８のノード生成処理について説明する。構成管理マネージャ３６０は、モニタ端末３５０から構成取得要求３７２を受信する（ステップ３９０１）。構成管理マネージャ３６０では、構成取得要求３７２を構成取得要求生成部３７１で監視対象リソース４００の構成取得コマンド３７４に変換し、監視対象リソース４００へ構成要素の取得を指令する（ステップ３９０２）。
【０１２２】
構成管理マネージャ３６０は、監視対象リソース４００から取得構成情報３７５を受信すると、構成取得要求生成部３７１で取得構成情報３７５を受け付け、構成変更要求生成部３６４に送り、構成情報ＤＢ３６５に格納する（ステップ３９０３）。構成取得要求生成部３７１は、受信した取得構成情報３７５を解析して監視対象リソース４００の構成要素を抽出する（ステップ３９０４）。なお、抽出された構成要素はＸＭＬで記述され、構成要素の名称が設定されているものとする。この構成要素の名称は監視対象リソース４００側で付与してもよいし、構成取得要求生成部３７１が構成要素を解析するときに付与してもよい。
【０１２３】
構成管理マネージャ３６０は、ステップ３９０４で抽出した全ての構成要素についてステップ３９０５からステップ３９０８の処理を行い、親ノードを暫定構成ＸＭＬ３８５に格納し、親ノードに相互参照４９０を示すｘｐａｔｈＩＤを設定する。
【０１２４】
まず、ステップ３９０６では、ツリー変換設定３８１は、抽出された構成要素のうちの一つを選択して、基準構成テーブル３８３を検索し、図３６の要素名３９０が一致したプラットフォームツリー構成要素ＸＭＬ３９１またはサービス提供ツリー構成要素ＸＭＬ３９２を取得する。この検索は、選択した構成要素のＸＭＬに含まれる構成要素の名称が基準構成テーブル３８３の要素名に一致すれば、プラットフォームツリー構成要素ＸＭＬ３９１またはサービス提供ツリー構成要素ＸＭＬ３９２を取得する。
【０１２５】
次に、ステップ３９０７では、ツリー変換設定３８１は、取得したプラットフォームツリー構成要素ＸＭＬ３９１またはサービス提供ツリー構成要素ＸＭＬ３９２があれば暫定構成ＸＭＬ３８５に格納する。このとき、基準構成テーブル３８３のプラットフォームツリー構成要素ＸＭＬ３９１とサービス提供ツリー構成要素ＸＭＬ３９２の間に相互参照４９０の関係があれば、図３６の「ハイパーバイザ」のＸＭＬの記述のように＜ｘｐａｔｈＩＤ＞が含まれる。
【０１２６】
そして、ステップ３９０８では、ツリー変換設定３８１は、暫定構成ＸＭＬ３８５に格納したプラットフォームツリー構成要素ＸＭＬ３９１またはサービス提供ツリー構成要素ＸＭＬ３９２内に＜ｘｐａｔｈＩＤ＞の記述があるか否かを判定し、＜ｘｐａｔｈＩＤ＞の記述があり、かつｖａｌｕｅの値がｎｕｌｌであれば構成情報５００内（または監視対象リソース４００内）で一意のｘｐａｔｈＩＤの値をｖａｌｕｅに設定し、ｘｐａｔｈ生成テーブル３８４に登録する。
【０１２７】
ここで、ｘｐａｔｈ生成テーブル３８４は、図３７で示すように、ｘｐａｔｈＩＤ３８５と、プラットフォームツリーｘｐａｔｈ３９６とサービス提供ツリーｘｐａｔｈ３９７からひとつのエントリが構成される。
【０１２８】
上記処理を全ての構成要素について実行することで、構成管理マネージャ３６０のツリー変換設定３８１は暫定構成ＸＭＬ３８５に、プラットフォームツリー構成要素ＸＭＬ３９１の親ノード及びサービス提供ツリー６１０の親ノードを格納し、相互参照４９０を示すｘｐａｔｈＩＤがあればユニークな識別子を付与する。
【０１２９】
次に、構成管理マネージャ３６０は、図３９のフローチャートを実行して、図３８の処理で求めた暫定構成ＸＭＬ３８５に格納された親ノードの配下の木構造を設定する。ステップ４００１では、構成取得要求生成部３７１が暫定構成ＸＭＬ３８５に格納された全ての構成要素ＸＭＬ３９１、３９２を抽出する。暫定構成ＸＭＬ３８５には、親ノード（ｐａｒｅｎｔ）の内容がブランク（空）の構成要素ＸＭＬが格納されている。抽出された構成要素ＸＭＬは親ノードの構成要素ＸＭＬ３９１、３９２であり、以下、親ノードの構成要素ＸＭＬとする。
【０１３０】
次に、構成管理マネージャ３６０のツリー変換設定３８１は、図３８のステップ３９０４で抽出された全ての構成要素のうちｐａｒｅｎｔがブランク以外の子ノードの全てについて、ステップ４００２、４００３の処理を実行する。
【０１３１】
ステップ４００３では、ツリー変換設定３８１が、ｐａｒｅｎｔがブランク以外の子ノードの構成要素ＸＭＬをひとつ取得する。そして、取得した子ノードの構成要素ＸＭＬが、ステップ４００１で抽出した親ノードの構成要素ＸＭＬのいずれの配下に属するかを決定する。この決定は、子ノードの構成要素ＸＭＬのｐａｒｅｎｔの要素名が、親ノードの構成要素ＸＭＬの要素名に一致すれば、当該親ノードを現在着目している子ノードの親とする。
【０１３２】
そして、ツリー変換設定３８１は、暫定構成ＸＭＬ３８５のうち、上記決定した親ノードの構成要素ＸＭＬの配下に、子ノードの構成要素ＸＭＬを組み込む。
【０１３３】
上記処理を全ての子ノードについて実行することで、ステップ３９０４で抽出された構成要素は、暫定構成ＸＭＬ３８５内で親ノードの配下に子ノードが組み込まれて、プラットフォームツリー構成要素ＸＭＬ３９１とサービス提供ツリー６１０が構築される。
【０１３４】
暫定構成ＸＭＬ３８５の例を図４２に示す。基準構成テーブル３８３の要素が階層的に配置され、各要素に固有な名称（図４２の＜ＳｅｒｖｅｒＲａｃｋＮａｍｅ＞や＜ＳｅｒｖｅｒＣｈａｓｓｉｓＮａｍｅ＞や＜ＳｅｒｖｅｒＮａｍｅ＞や＜ＨｙｐｅｒｖｉｓｏｒＮａｍｅ＞や＜ＨＢＡＮａｍｅ＞で定義されている名称）とｘｐａｔｈＩＤが設定されている。
【０１３５】
次に、ツリー変換設定３８１は、図４０のフローチャートを実行してｘｐａｔｈ生成テーブル３８４を更新する。図３８、図３９の処理では、暫定構成ＸＭＬ３８５の親ノード同士のｘｐａｔｈは設定されているが、プラットフォームツリー６００の子ノードとサービス提供ツリー６１０の親ノードのｘｐａｔｈが設定されていない。そこで、図４０のフローチャートでは、プラットフォームツリー６００の子ノードとサービス提供ツリー６１０の親ノードのｘｐａｔｈを設定する。
【０１３６】
ツリー変換設定３８１は、図４０のステップ４１０１〜４１０３の処理をｘｐａｔｈ生成テーブル３８４の全ての要素について実行する。
【０１３７】
ステップ４１０１では、暫定構成ＸＭＬ３８４を検索し、全親ノードを見つける。その親ノード全てについて、ステップ４１０２とステップステップ４１０３を実施する。
【０１３８】
ステップ４１０２では、ツリー変換設定３８１が暫定構成ＸＭＬ３８５を検索して、＜ｘｐａｔｈＩＤ＞を検出する。検索は、深さ優先でも幅優先でもかまわない。
【０１３９】
ステップ４１０３では、ツリー変換設定３８１が上記ステップ４１０２で検出するまでに暫定構成ＸＭＬ３８５をたどったパスをｘｐａｔｈとして、ｘｐａｔｈ生成テーブル３８４のプラットフォームツリーｘｐａｔｈ３９６またはサービス提供ツリーｘｐａｔｈ３９７に登録する。なお、プラットフォームツリーとサービス提供ツリーの判定は、ｘｐａｔｈＩＤを検出した構成要素ＸＭＬには、図３６の基準構成テーブル３８３に格納された＜ｐｌａｔｆｏｒｍ＞または＜ｓａｅｒｖｉｃｅ＞の何れかの識別子を取得することでツリー変換設定３８１が判定することができる。また、ｘｐａｔｈ生成テーブル３８４のｘｐａｔｈＩＤ３９５は、ステップ４１０２で検出したｘｐａｔｈＩＤを引き継げばよい。
【０１４０】
次に、ツリー変換設定３８１は、図４１のフローチャートを実行してｘｐａｔｈ生成テーブル３８４に登録されたｘｐａｔｈを暫定構成ＸＭＬ３８５に組み込んで、構成情報５００を生成する。
【０１４１】
ツリー変換設定３８１は、ステップ４２０１〜４２０３の処理をｘｐａｔｈ生成テーブル３８４の要素の全てについて実行する。
【０１４２】
ステップ４２０２では、ツリー変換設定３８１が、ｘｐａｔｈ生成テーブル３８４の一つのエントリを選択する。そして、選択したｘｐａｔｈ生成テーブル３８４のエントリのプラットフォームツリーｘｐｔｈ３９６のｘｐａｔｈを、暫定構成ＸＭＬ３８５でサービス提供ツリーの当該ｘｐａｔｈＩＤが設定されている部分と入れ替える。これにより、暫定構成ＸＭＬ３８５のサービス提供ツリーの当該ｘｐａｔｈＩＤには、プラットフォームツリーｘｐｔｈ３９６の記述（ＸＭＬ）が組み込まれる。
【０１４３】
次に、ステップ４２０３では、ツリー変換設定３８１が、現在選択しているｘｐａｔｈ生成テーブル３８４のエントリのサービス提供ツリーｘｐｔｈ３９７のｘｐａｔｈを、暫定構成ＸＭＬ３８５でプラットフォームツリーの当該ｘｐａｔｈＩＤが設定されている部分と入れ替える。これにより、暫定構成ＸＭＬ３８５のプラットフォームツリーの当該ｘｐａｔｈＩＤには、サービス提供ツリーｘｐｔｈ３９７の記述（ＸＭＬ）が組み込まれる。
【０１４４】
上記ステップ４２０２、４２０３の処理が全てのｘｐａｔｈ生成テーブル３８４のエントリについて終了すると、ステップ４２０４へ進む。ステップ４２０４では、ツリー変換設定３８１が、暫定構成ＸＭＬ３８５の内容を構成情報ＸＭＬ５００として構成情報データベース３６５に格納する。
【０１４５】
以上の処理により、図３２Ａ、図３２Ｂに示すプラットフォームツリー６００と、図３３に示すサービス提供ツリー６１０の構成情報ＸＭＬ５００ａが生成される。なお、図３２Ａ、図３２Ｂ、図３３の構成情報ＸＭＬ５００ａは、上述したようにモニタリングシステム１００が一意のコンポーネントＩＤを付与したものである。
【０１４６】
＜統計情報の関連付け＞
次に、統計情報と構成情報の関連付けについて説明する。
【０１４７】
仮想サーバ４２２の統計情報としては、例えばＯＳ４２３が取得したＣＰＵ使用率やメモリ使用量といった稼動情報に上述のような統計処理した情報が考えられる。すなわち、サーバ仮想化部４２１が仮想サーバ４２２へ提供する仮想ＣＰＵの使用率やメモリの使用量（または使用率）、あるいは仮想Ｉ／Ｏデバイス（ＨＢＡやＮＩＣ等を仮想化したＩ／Ｏデバイス）の使用率（転送量）等を仮想サーバ４２２の性能を示す稼動情報とし、所定の統計処理を行って統計情報とすることができる。
【０１４８】
一方、物理サーバ４１１の統計情報としては、サーバ仮想化部４２１自身のＣＰＵ使用率やメモリ４１３の使用量や、Ｉ／Ｏ（ＨＢＡやＮＩＣ）の使用率（転送量）等を仮想化部４２１の性能を示す稼動情報とし、所定の統計処理を行って統計情報とすることが考えられる。
【０１４９】
そして、本実施形態では、モニタリングシステム１００が、構成情報ＸＭＬ５００ａの各ノードに一意なコンポーネントＩＤ（図中ＣＩＤ）を割り当て、このコンポーネントＩＤに各統計情報に設定した統計値ＩＤを関連付けることで、構成情報の変更の前後での構成の履歴や統計情報の追跡を容易にする。なお、構成情報におけるノードとしては、物理サーバ４１１や仮想サーバ４２２に付与したコンポーネントＩＤをノードとして扱うことができる。同様に統計値ＩＤもノードとして扱うようにしても良い。
【０１５０】
また、コンポーネントＩＤと統計値ＩＤとを区別する必要は必ずしもなく、お互いに重複しない値をつけて管理する方法もある。以下の例では、各テーブルのフィールド数を省略するためにコンポーネントＩＤと統計値ＩＤを同一フィールドで示しているが、両者を区別するようなフィールドを追加して管理する方法もある。どちらの場合も本発明の適用に当たっては本質的な差異を生じない。
【０１５１】
図９は図７に示した構成情報ＸＭＬ５００ａから仮想サーバαを物理サーバＢへ移動させた後の構成情報ＸＭＬ５００ｂのツリー表現の一部を抜粋した図である。この構成情報ＸＭＬ５００ｂは、図４に示したリビジョン１３１＝２の構成情報１３４をツリーにて表現した例である。リビジョン１３１＝１から２の移動の前後で、移動した仮想サーバαに関連するコンポーネントＩＤおよび統計値ＩＤは同一であることが保証される。これにより、構成変更による移動の前後で稼動に関する統計情報を連続的に追跡できるようになる。
【０１５２】
すなわち、図７に示すように、コンポーネントＩＤ＝３の物理サーバＡに割り当てられたコンポーネントＩＤ＝９の仮想サーバを、物理サーバＢへ移動したときには、物理サーバＡに関連付けられた仮想サーバαのコンポーネントＩＤ＝３と、当該仮想サーバの配下の仮想リソースの識別子（統計値ＩＤ）を図９で示すように削除し、移動する仮想サーバαのコンポーネントＩＤ＝９及び当該仮想サーバαの配下の仮想リソースの識別子（統計値ＩＤ）と同一のコンポーネントＩＤと統計値ＩＤを移動先のコンポーネントＩＤ＝４の物理サーバＢに割り当てる。
【０１５３】
＜割当済ＩＤ管理テーブル＞
図１１は構成情報関連管理部２３０が管理するコンポーネントＩＤの状態遷移図である。コンポーネントＩＤは、ベースリソース４１０や仮想リソース４２０の構成要素に構成情報関連管理部２３０が割り当てたモニタリングシステム１００内で一意の識別子である。これらのコンポーネントＩＤと統計値ＩＤは、構成情報関連管理部２３０が管理する割当済ＩＤ管理テーブル１６０（図１２、図１３）のコンポーネント／統計値ＩＤ１６１に格納される。
【０１５４】
構成情報関連管理部２３０がベースリソース４１０や仮想リソース４２０の構成要素にコンポーネントＩＤを割り当てると、コンポーネントＩＤの状態を管理するために割当済ＩＤ管理テーブル１６０へと登録する。
【０１５５】
コンポーネントＩＤは、まだ割り当てていない状態未割当１７０（テーブルに未登録のＩＤを含む）から、割り当てられると使用中１７１へと遷移する。また、待機用のコンポーネントなどのためにＩＤを予約した場合は予約済あるいは待機中１７２へと遷移する。使用中１７１と待機中１７２の間は、障害や移動などによる交替があった場合、お互いの間を遷移することがある。コンポーネントの削除や廃棄が行われた場合、そのＩＤは別の目的で再利用されないように回収済１７３へと遷移する。新たなＩＤの値の生成方法としては、たとえば単調増加な自然数を使用する方法が考えられる。
【０１５６】
図１２、図１３は図７の構成情報ＸＭＬ５００ａの構成要素に付与される割当済ＩＤ管理テーブル１６０の構成例である。各レコードはコンポーネントＩＤまたは統計値ＩＤ１６１、構成情報ＩＤ１６２、リビジョン１６３、ＸＭＬパス表現１６４、親コンポーネントＩＤ（図中親ＩＤ）１６５、コンポーネントＩＤの状態１６６といったフィールドから構成される。これらの値は、モニタリングシステム１００が付与するものである。
【０１５７】
ここでＸＭＬパス表現１６４は、ＸＭＬツリーにおける各ノードを特定するために必要な情報を含む。図１２、図１３の例ではサーバラック５１０のＩＤと、サーバシャーシ５２０のＩＤと、物理サーバ４１１のＩＤと、仮想サーバ４２２のＩＤを順に指定する方法を示したが、この他にも物理サーバ４１１や仮想サーバ４２２にユーザがつけたサーバ名を指定する方法や、稼動するゲストＯＳのＵＵＩＤを指定する方法などが考えられる。いずれの方法でもノード（各コンポーネント）が一意に特定できさえすれば本発明の適用に当たっては差異を生じない。
【０１５８】
また、親コンポーネントＩＤ（図中親ＩＤ）１６５が「−」の構成要素は、プラットフォームツリー６００おいて親ノードとなることを示している。
【０１５９】
＜構成情報ＸＭＬのＸＭＬ表現＞
図３２Ａ、図３２Ｂ、図３３は図７に示した物理サーバ＝「Ａ」の仮想サーバαを物理サーバ「Ｂ」へ移動する前の構成情報ＸＭＬ５００ａのＸＭＬによる階層構造の表現である。
【０１６０】
図３２Ａ、図３２Ｂでは、サーバラック５１０を示すＳｅｒｖｅｒＲａｃｋノードと、サーバシャーシ５２０を示すＳｅｒｖｅｒＣｈａｓｓｉｓノードと、物理サーバ５３０を示すＰｈｙｓｉｃａｌＳｅｒｖｅｒノードと、サーバ仮想化部４２１を表すＨｙｐｅｒｖｉｓｏｒノードとＨＢＡ４１５を表すＨＢＡノードとが階層的にツリー構造をしている。
【０１６１】
また、仮想サーバ５４０を示すＶｉｒｔｕａｌＳｅｒｖｅｒノードと、ｖＨＢＡ４６０を表すｖＨＢＡノード、ＬＵ４６５を表すＬＵノード、パーティション４７０を表すＰａｒｔｉｔｉｏｎノードとが、図７に示したプラットフォームツリー６００と同じく階層的にツリー構造をなしている。
【０１６２】
各ノードには、各ノードの属性としてコンポーネントＩＤを示すｃｏｍｐｏｎｅｎｔ＿ｉｄを持つ。またＶｉｒｔｕａｌＳｅｒｖｅｒノードの下にはサーバ名を示すＳｅｒｖｅｒＮａｍｅ、ＣＰＵ使用率を示すＣＰＵＵｓａｇｅ、メモリ使用量を示すＭｅｍｏｒｙＵｓａｇｅの各ノードがあり、ＣＰＵＵｓａｇｅおよびＭｅｍｏｒｙＵｓａｇｅノードは統計値ＩＤを示すｓｔａｔｉｓｔｉｃｓ＿ｉｄ属性を持つ。なお、コンポーネントＩＤと統計値ＩＤを特に区別せずに管理する場合はｓｔａｔｉｓｔｉｃｓ＿ｉｄ属性の代わりにｃｏｍｐｏｎｅｎｔ＿ｉｄ属性を持たせる実装も考えられる。どちらの場合も本質的な差異は生じない。
【０１６３】
一方、図３３では、図７に示したサービス提供ツリー６１０の階層構造が、上記のプラットフォームツリー６００と同様にして、ＸＭＬにより記述されている。図３３の構成情報５００ａは、図３６に示した基準構成テーブル３８１で定義された各要素３９０で定義されている親子関係の属性（ｐａｔｒｅｎｔとｃｈｉｌｄ）をツリー上の階層構造で単一のＸＭＬで記述したものである。
【０１６４】
そして、図３２Ａ、図３２Ｂでは図７に示したプラットフォームツリー６００の各ノードと図３３のサービス提供ツリー６１０の各ノードとの間の相互参照４９０として、上述のｘｐａｔｈが設定されている。
【０１６５】
図３４Ａ、図３４Ｂ、図３５、図３５Ｂは図９に示した物理サーバ＝「Ａ」の仮想サーバαを物理サーバ「Ｂ」へ移動する際の構成情報ＸＭＬ５００ａと構成情報ＸＭＬ５００ｂを生成する場合のＸＭＬ表現での変更手順を示した図である。
【０１６６】
図３４Ａ〜図３５Ｂでは、構成情報ＸＭＬ５００ａにおける仮想サーバα配下のノードを、構成情報ＸＭＬ５００ｂでは物理サーバＡの配下から物理サーバＢの配下へと移動させる。この処理において、仮想サーバαを含む配下のコンポーネントＩＤおよび統計値ＩＤは同一のＩＤを引き継ぐことで、移動前後における稼動の統計情報や変更履歴の追跡を可能とする。また、移動する仮想サーバαを含むプラットフォームツリーの記述はｘｐａｔｈだけの変更だけでよく、サービス提供ツリー６１０で新たに仮想サーバを追加するだけでサーバの移行に対して対処可能である。
【０１６７】
＜稼動統計情報表示＞
図１４は稼動に関する統計情報をモニタ端末３５０へ表示する時にモニタリングシステム１００の統計情報管理部１９０で行われる処理のフローチャートを示す。この処理は、統計情報ＧＵＩ制御部２５０がモニタ端末３５０から統計情報の要求を受け付けたときに実行される。この要求は、統計情報の表示期間の開始日時を変数ｂに格納し、終了日時を変数ｅに、コンポーネントの構成情報ＩＤを変数ｄに、コンポーネントＩＤを変数ｃに格納する。
【０１６８】
まずステップ１３００で、統計情報管理部１９０は統計情報ＧＵＩ制御部２５０から統計情報表示期間の開始日時ｂと終了日時ｅを得る。ステップ１３１０へ進む。
【０１６９】
ステップ１３１０では、構成情報管理部２００が構成情報ＧＵＩ制御部２６０から、指定されたコンポーネントの構成情報ＩＤ１３５＝ｄとコンポーネントＩＤ＝ｃを得る。ステップ１３２０へ進む。
【０１７０】
ステップ１３２０では、履歴情報管理部２１０が、統計情報管理部１９０および構成情報管理部２００から得た変数ｂ、ｅ、ｄ、ｃを元に、コンポーネント履歴管理テーブル１５０から＜ｄ、ｃ＞をキーとして、開始日時１５２＜ｅかつ終了日時１５３≧ｂとなるリビジョン１５４のリスト（Ｒ１、Ｒ２、．．．、Ｒｎ）を得る。ここで各リビジョンの開始日時１５２を（ｂ１、ｂ２、．．．、ｂｎ）、終了日時１５３を（ｅ１、ｅ２、．．．、ｅｎ）とする。ｅｉ（ただし、ｉ＝１〜ｎ）は最新リビジョンの場合ＮＵＬＬの場合もある。ステップ１３３０へ進む。
【０１７１】
次に得られた各リビジョンＲｉ（ただし、ｉ＝１〜ｎ）について、ステップ１３４０〜１３９０までを繰り返す。
【０１７２】
ステップ１３４０では、構成情報管理テーブル１３０から、構成情報ＩＤ１３５＝ｄ、リビジョン１３１＝Ｒｉであるレコードを選び、構成情報管理テーブル１３０の構成情報１３４から構成情報ＸＭＬ５００（５００ａ〜５００ｃ）を取得する。ステップ１３５０へ進む。なお、以下の説明では構成情報ＸＭＬ５００ａ〜５００ｃの総称を構成情報ＸＭＬとする。
【０１７３】
ステップ１３５０では、取得した構成情報ＸＭＬ５００についてコンポーネントＩＤが変数ｃの配下の統計値ＩＤのリスト（ｓ１、 ｓ２、 ．．． ｓｍ）を得る。ただし、統計値ＩＤのリストはｓｊで表され、ｊ＝１〜ｍである。ステップ１３６０へ進む。
【０１７４】
次に得られた各ｓｊに対してステップ１３７０〜１３８０を繰り返す。
【０１７５】
ステップ１３７０では、稼動統計テーブル１２０から統計値ＩＤ１２１＝ｓｊをキーにして、ｂｉ≦タイムスタンプ１２２＜ｅｉとなるレコードのタイムスタンプ１２２と統計値１２３の組＜ｔ、ｖ＞のリストを得る。ステップ１３８０に進む。
【０１７６】
ステップ１３８０では、稼動情報ＧＵＩ制御部２５０に＜ｔ、ｖ＞のリストを送り、このリスト＜ｔ、ｖ＞とコンポーネントＩＤによりモニタ端末３５０の表示装置にグラフを出力する。
【０１７７】
以上が稼動に関する統計情報の表示時に統計情報管理部１９０で実行される処理のフローチャートである。
【０１７８】
上記処理により、統計情報管理部１９０は、同一のコンポーネントＩＤに関連づけられた統計値ＩＤ１２１について、マイグレーションなどの構成変更があった場合にも、構成変更の時点を跨いで連続的に統計情報を表示させることが可能となる。
【０１７９】
図１５は本発明を適用したモニタリングシステム１００のモニタ端末３５０に表示される稼動統計モニタ画面の一例である。
【０１８０】
稼動統計モニタ画面は、図中左側に表示期間を表示する部分７００とラックやシャーシといったプラットフォームツリー６００に従って構成管理を行う部分７１０を備える。また、図中右側には構成要素および稼動に関する統計情報を表示するエリアが設定され、図中上部から物理構成情報（ベースリソース４１０の構成要素）を表示する物理構成情報表示エリア７２０、仮想構成情報（仮想リソース４２０の構成要素）を表示仮想構成情報表示するエリア７３０、統計情報を表示する稼動統計情報表示エリア７４０から構成される。
【０１８１】
物理構成情報表示エリア７２０と仮想構成情報表示エリア７３０および稼動統計情報表示エリア７４０は連動しており、物理構成情報エリア７２０において指定されたコンポーネント（ここでは物理サーバＡ）についての仮想構成情報（仮想リソースの構成要素）の詳細が仮想構成情報表示エリア７３０に表示される。また、この場合、物理サーバＡに対応した稼働統計情報が７４０に表示される。
【０１８２】
ここで仮想構成情報表示エリア７３０の仮想サーバαをモニタ端末３５０の入力装置（例えば、マウスなどのポインティングデバイス）で指定した場合、仮想サーバαに関連する統計情報のみが抽出されて稼働統計情報表示エリア７４０に表示される。図示の例では、稼動統計情報表示エリア７４０の左側の領域に仮想サーバαのＣＰＵ使用率が時系列的なグラフで表示され、右側の領域には仮想サーバαのＩ／Ｏ使用率（リード、ライトの使用率など）が時系列的なグラフで表示される。
【０１８３】
なお、物理構成情報表示エリア７２０の物理サーバＡ〜Ｃの何れかをモニタ端末３５０の入力装置で指定した場合には、選択した物理サーバに関連する統計情報が抽出されて稼働統計情報表示エリア７４０に表示される。また、図１５では、物理構成情報表示エリア７２０にサーバ仮想化部４２１を省略した例を示したが、物理サーバ上にサーバ仮想化部が階層的に稼動している場合には、物理サーバとサーバ仮想化部を表示することができる。
【０１８４】
このように、着目するコンポーネントが物理コンポーネントか仮想コンポーネントかに応じて、稼働統計情報７４０に表示されるグラフの種類が変わる点が本モニタリングシステム１００の特徴の一つである。
【０１８５】
上記図１５の稼動統計モニタ画面は、モニタリングシステム１００の統計情報ＧＵＩ制御部２５０、構成情報ＧＵＩ制御部２６０、履歴情報ＧＵＩ制御部２７０により一つの画面情報が生成され、モニタリングシステム１００は当該画面情報をモニタ端末３５０へ出力する。そして、モニタ端末３５０では、受信した画面情報を表示装置に描画する。
【０１８６】
＜稼働情報収集部の動作＞
以下図１６〜図１９を用いて稼働情報集計部３００で行われる処理の詳細を示す。
【０１８７】
図１６は稼働情報集計部３００の構成を示したブロック図である。稼働情報集計部３００は稼働情報収集パラメータ３１０を保持し、稼働情報収集パラメータ３１０の内容はパラメータ設定インタフェース３４５を介してモニタ端末３５０の入力装置等から設定される。
【０１８８】
稼働情報収集パラメータ３１０の内容は、監視対象リソース４００の通常の運用では最初に収集する項目を決めて設定された後は、特に監視対象リソース４００に大きな変更が加わらない限り変更されることはない。稼働情報集計部３００は、さらに稼働統計情報収集パラメータ３１０に従って収集コマンドを実行する収集コマンド実行３２０、および収集コマンドの実行結果である稼動情報を受け取って所定の処理を行う収集コマンド結果取得部３３０、さらに収集した稼動情報の中で予め設定した条件に合致した結果から統計値を生成し、稼働統計テーブル１２０へと格納する稼働統計値登録部３４０、およびタイマ３４１から構成される。
【０１８９】
図１７は稼働情報集計部３００が使用する稼働情報収集パラメータ３１０の定義である。図１７は稼働情報収集パラメータ３１０の１つのパラメータの行（またはレコード）を示し、構成情報ＩＤ３１１、パラメータ生成式３１２、収集コマンド３１３、モニタ間隔３１４、およびフィルタ条件３１５ａ、３１５ｂ、統計情報生成式３１６ａ、３１６ｂ、統計値ＩＤ検索式３１７ａ、３１７ｂからなる統計情報生成リスト３１８ａ、３１８ｂが１つ以上、から構成される。なお、以下では、フィルタ条件３１５ａ、３１５ｂの総称をフィルタ条件３１５とし、統計情報生成式３１６ａ、３１６ｂの総称を統計情報生成式３１６とし、統計値ＩＤ検索式３１７ａ、３１７ｂの総称を統計値ＩＤ検索式３１７とし、統計情報生成リスト３１８ａ、３１８ｂの総称を統計情報生成リスト３１８とする。
【０１９０】
稼働情報収集パラメータ３１０の内容については、上述のように管理者などが操作するモニタ端末３５０の入力装置等から設定される。構成情報ＩＤ３１１には、図４の構成情報管理テーブル１３０の構成情報ＩＤ１３５に対応する値が格納される。収集コマンド３１３には、対象となる構成情報ＩＤ３１１に対して実行させる稼動情報の収集コマンドを格納する。モニタ間隔３１４には、モニタ端末３５０で設定する稼動情報の収集周期が格納される。
【０１９１】
モニタ端末３５０は、パラメータ設定インタフェースに対して統計値の生成を要求し、構成情報管理テーブル１３０の構成情報ＩＤ１３５を指定して、上記各パラメータを設定する。設定されたパラメータは新たなレコードとして稼働情報収集パラメータ３１０に格納される。稼働情報集計部３００は、構成情報ＩＤと統計値ＩＤをモニタリングシステム１００に通知し、構成情報管理テーブル１３０の構成情報５００に統計値ＩＤが格納される。
【０１９２】
パラメータ生成式３１２は、後述するように、構成情報ＸＭＬ５００に含まれるサーバ名やＩＰアドレス等を指定するための式が設定される。
【０１９３】
収集コマンド３１３の一例としては、後述するように、稼働情報を収集するプロトコルであるＳＮＭＰに従ったコマンド等が設定される。
【０１９４】
フィルタ条件３１５の一例としては、図１７に示す＄FilterElemで示すような条件が設定される。
【０１９５】
統計情報生成式３１６の一例としては、図１７に示すように、収集した稼動情報の百分率や平均値や合計値を求める式が設定される。
【０１９６】
統計値ＩＤ検索式３１７の一例としては、図１７に示すように、構成情報ＸＭＬ５００のインスタンスに対応する統計値ＩＤを求める式が設定される。
【０１９７】
図１８に稼働情報集計部３００で行われる処理のフローチャートを示す。
【０１９８】
稼働情報集計部３００は、図１７のように予め設定された稼働情報収集パラメータ３１０をパラメータとして読み込んで起動される。ここでは説明を簡易にするため、稼働情報収集パラメータ３１０の各行ごとに別パラメータを与えて起動するとしているが、一つのプログラムで複数の収集コマンドを発行できるようにしても良い。
【０１９９】
ステップ１５００で稼働情報集計部３００のプログラムが起動され、ステップ１５１０へ進む。
【０２００】
ステップ１５１０では、稼働情報集計部３００は図１７の稼働情報収集パラメータ３１０を参照し、構成情報ＩＤ３１１をキーにして構成情報管理テーブル１３０から最新のリビジョン１３１を持つレコードの構成情報ＸＭＬ５００を取得し、ステップ１５２０へと進む。
【０２０１】
ステップ１５２０では、稼働情報集計部３００が構成情報ＸＭＬ５００から稼働情報収集パラメータ３１０のパラメータ生成式３１２に従って、収集コマンド３１３の起動に必要なパラメータを補完し、ステップ１５３０へ進む。
【０２０２】
ここでパラメータ生成式３１２は、構成情報ＸＭＬ５００に含まれるインスタンスを特定するのに必要なパラメータ（サーバ名やＩＰアドレス等）を指定するための式であり、一例としてはＸＭＬパス形式で指定する方法が考えられる。例えば図３２で示したＸＭＬ表現から、仮想サーバのサーバ名を抽出するためのＸＭＬパス形式の一例は”／ＶｉｒｔｕａｌＳｅｒｖｅｒ／ＳｅｒｖｅｒＮａｍｅ”となる。
【０２０３】
一般にパラメータ生成式３１２にマッチするノードは一つの構成情報ＸＭＬ５００に複数存在するために、生成されるパラメータは複数のリストとなる。
【０２０４】
ステップ１５３０では、ステップ１５２０で生成されたパラメータの数に応じて稼働情報集計部３００のインスタンスを生成する。インスタンスの生成は、複製により生成することもできる。インスタンスを複製する方法としては例えばＵｎｉｘ（登録商標）のｆｏｒｋシステムコールを使って複製する方法や、スレッドを分ける方法などが考えられる。なお、稼働情報の収集処理を並行に実行することさえできれば必ずしもプロセスやスレッドを複製する必要は無い。ステップ１５４０に進む。
【０２０５】
ステップ１５４０では、収集コマンド実行部３２０が上記生成されたパラメータを引数にして収集コマンド３１３を監視対象リソース４００に対して実行する。収集コマンド３１３としては、稼働情報を収集するプロトコルであるＳＮＭＰに従ったコマンドや、予めインストールしたエージェントに対する通信、あるいはリモートシェルなどを使って稼働状態を取得するコマンド（Ｌｉｎｕｘ（登録商標）でのｖｍｓｔａｔやｉｏｓｔａｔなど）を発行する方法などが考えられる。ステップ１５５０へ進む。
【０２０６】
ステップ１５５０では、収集コマンド結果取得部３３０はステップ１５４０で実行した収集コマンド３１３の結果をパイプ（標準出力）あるいはファイル経由で取得する。ステップ１５６０へ進む。
【０２０７】
ステップ１５６０では、パラメータとして与えられたフィルタ条件３１５と統計情報生成式３１６と統計値ＩＤ検索式３１７の組からなる稼働情報生成リスト３１８のそれぞれについて、ステップ１５７０〜ステップ１５９０までを繰り返し実行する。
【０２０８】
ステップ１５７０では、得られた結果がフィルタ条件３１５に一致しているかを判断する。フィルタ条件３１５に一致していない場合は集計対象に該当する統計値は含まれていないため、ステップ１５９０へ進む。フィルタ条件３１５に一致していた場合は稼働統計値登録部３４０がステップ１５８０の統計値の登録処理を行ってからステップ１５９０へと進む。
【０２０９】
ステップ１５８０の統計値の登録処理については後に図１９にて詳細に説明する。
【０２１０】
ステップ１５９０では、フィルタ条件３１５と統計情報生成式３１６と統計値ＩＤ検索式３１７の組の統計情報生成リスト３１８の残りについて、ステップ１５６０に戻り繰り返す。全て完了した場合ステップ１６００へと進む。
【０２１１】
ステップ１６００では、モニタ間隔３１４が経過しているか否かをタイマ３４１をチェックし、経過するまで待つ。経過後ステップ１５４０へと戻る。
【０２１２】
以上が稼働情報集計部３００の動作を示すフローチャートである。
【０２１３】
続いて図１９に稼働統計値登録部３４０で行われる統計値登録処理１５８０の詳細なフローチャートを示す。
【０２１４】
ステップ１６１０で、稼働統計値登録部３４０は、稼動情報収集パラメータ３１０の統計情報生成式３１６に従い、統計値を算出する。ここで、統計値とは、稼働統計テーブル１２０に登録する統計値１２３に対応する統計値であり、収集した稼動情報の平均値や最小値、最大値、標準偏差あるいは標本数、などから構成される。１つの値のみから統計値を算出する場合は、平均値＝最小値＝最大値となり、標準偏差は０、標本数は１とする。稼動情報収集パラメータ３１０の統計情報生成式３１６は、ステップ１５５０で取得した収集コマンド３１３の出力結果から、統計値を生成する式である。統計情報生成式３１６は、パーセントの数字の場合に稼動情報を１００で割るといった処理や、２つの値の平均や合計を求めるといった処理が考えられる。ステップ１６２０へ進む。
【０２１５】
ステップ１６２０では、構成情報ＸＭＬ５００から統計値ＩＤ検索式３１７に従って統計値ＩＤを取得し変数ｓに格納する。ここで、統計値ＩＤ検索式３１７とは、構成情報ＸＭＬ５００のインスタンスから、対応する統計値ＩＤ（構成情報ＸＭＬノード上でインスタンスノードの配下にあるケースが多い）を求める式であり、一例としてはＸＭＬパス形式を使うことが考えられる。たとえば、図３２、図３３の構成情報ＸＭＬ５００ａの場合、ハイパーバイザのインスタンスを示す式が”／ＳｅｒｖｅｒＲａｃｋ／ＳｅｒｖｅｒＣｈａｓｓｉｓ／ＰｈｙｓｉｃａｌＳｅｒｖｅｒ／Ｈｙｐｅｒｖｉｓｏｒ”であり、その仮想サーバのＣＰＵ使用率の統計値ＩＤを示すＸＭＬパス式は”．／ＣＰＵＵｓａｇｅ＠ｓｔａｔｉｓｔｉｃｓ＿ｉｄ”となる。ステップ１６３０に進む。
【０２１６】
ステップ１６３０では、タイマ３４１からタイムスタンプｔを取得し、ステップ１６４０へ進む。
【０２１７】
ステップ１６４０では、稼働統計テーブル１２０に、統計値ＩＤ１２１＝ｓ、タイムスタンプ１２２＝ｔ、統計値１２３＝（ｖ１、ｖ２、．．．、ｖｎ）を登録する。
【０２１８】
以上で統計値の登録処理１５８０が完了する。
【０２１９】
＜ベースリソースの構成要素の自動的な統計情報分析＞
図２９を用いて監視対象リソース４００の仮想リソース４２０で共有しているベースリソース４１０の構成要素について行う自動的な統計情報分析の概要を説明する。
【０２２０】
図２９は、図１のモニタリングシステム１００のモニタ端末３５０で表示する構成情報と統計情報の関連を一画面で表示している例である。
【０２２１】
ここでは、仮想サーバ４２２で共有しているＨＢＡ４１５の稼働状況を調査し、どの仮想サーバ４２２が最も当該ＨＢＡ４１５を使用しているのかをモニタリングシステム１００の利用者が調査をするシナリオを想定している。
【０２２２】
まず、モニタリングシステム１００のユーザがモニタ端末３５０で、監視したいシステム要素をマウス等の入出力装置でクリックする。図２９では、ＨＢＡ０をクリックしている（２０４０）。そして、モニタリングシステム１００は後述の統計情報分析処理を実行した後、ＨＢＡ０上のデータ転送速度（スループット）を仮想サーバ毎に色（またはパターン）を変えて積み上げグラフの形式で表示する（２０４１）。このような仮想サーバ毎の統計情報の積み上げグラフを作成するには、直接該当するデータを計測できているケース、例えば、サーバ仮想化部４２１が仮想サーバ４２２毎に割り当てているプロセッサ４１２のＣＰＵ使用率のようなケースでは、計測した数値をそのまま積み上げグラフで表示すればよい。しかし、図２９のようにＨＢＡ４１５では仮想サーバ４２２毎の統計情報を得るためには、特別なハードウェアを搭載していなければ計測はできない。そこで、ＨＢＡ０を経由するディスクアクセスのスループットをＨＢＡ０のデータスループットとみなして、仮想サーバ４２２毎のスループット値の積み上げグラフを生成することでＨＢＡ０のスループットが分析できる。本発明では、このような分析処理を自動化すること目的としている。
【０２２３】
＜データ構造＞
図２５を用いて統計情報のデータ構造について説明する。基本的には図７、図３２、図３３を用いて説明したプラットフォームツリー６００とサービス提供ツリー６１０を相互参照で結合したものである。プラットフォームツリー６００では、物理サーバ４１１の下にＨＢＡ４１５が存在している。ＨＢＡ４１５に関連付けられている統計情報５８２は空集合になっている。一方、仮想サーバ４２２の下にはｖＨＢＡ４６０が存在し、その下にはＬＵ４６５が存在し、さらにその下にはパーティション４７０が存在する。ｖＨＢＡ４６０に関連付けされている統計情報５８１は空集合となっている。さらに、パーティション４７０に紐づけられた統計値（ディスクの統計情報）５８０がある。
【０２２４】
サービス提供ツリー６１０に属する統計情報のデータについて説明する。サービス提供ツリー６１０では、ＨＢＡ４１５０を親ノードとし、その下にｖＨＢＡ４６５０が存在する。ＨＢＡ４１５０は統計情報４５８０と関連付けされている。そして、ＨＢＡ４１５とＨＢＡ４１５０の間と、ｖＨＢＡ４６０とｖＨＢＡ４６５０の間には相互参照が張られている（図２５の破線）。
【０２２５】
サービス提供ツリー６１０上の統計情報４５８０（統計値ＩＤ＝４００１〜４００２）、４５８２（統計値ＩＤ＝４１０１〜４１０４）は、図２６に示す稼働統計分析テーブル１１５で統計情報が定義されている。図２６の稼働統計分析テーブル１１５は、図２のモニタリングシステム１００の構成要素の一つである。稼働統計分析テーブル１１５の構成は、統計値ＩＤ２００１、データ名２００２、表示２００３、演算２００４から一つのレコードが構成される。
【０２２６】
表示２００３はモニタ端末３５０に表示するグラフの形式を指定するものである。表示２００３では子ノードに相当するデータは表示対象ではないことを示す“−”が設定される。親ノードに対しては演算２００４の演算内容で集計したデータを表示２００３の形式でモニタ端末３５０の表示装置に画面表示される。表示２００３に設定される“合計”は子ノードの数値をすべて加算した数値で、”積み上げ”は子ノードの数値を、それぞれのノードの数値が占める割合が分かるように積み上げたグラフを意味している。
【０２２７】
演算２００４の列には、統計値の演算方法が指定されている。演算名が“集合｛ ｝“は、”｛ ｝“で指定された集合をそのまま集合として返す。演算名が”合計値[ ]“は、”[ ]“で指定された集合の数値をすべて加算したものが返り値となる。図では記載されていないが、演算としては、平均値、最大値、最小値など他の集合演算も指定できる。
【０２２８】
稼働統計分析テーブル１１５の設定は、図２７の稼働時計分析の演算を指定する入力画面２０１５から、管理者がモニタ端末３５０の入力装置から入力して指定する。この入力画面２０１５は、管理者が図２のモニタ端末３５０から構成情報ＧＵＩ制御部２６０に対してモニタ端末３５０で表示されるメニュー画面から呼び出す。そして、構成情報管理部２００が構成情報管理テーブル１３０から、サービス提供ツリー６１０の一覧を検索し、検索結果を構成情報ＧＵＩ制御部２８０がモニタ端末３５０上にウィンドウ（画面２０１５）を新規に開いて表示する。
【０２２９】
このとき同時に統計情報の種類（使用率やスループットなど）も同時に検索する。入力画面２０１５は、サービス提供ツリー６１０の構成要素の一覧を場変換２０１１の列に表示し、モニタリングシステム１００のユーザは演算２０１２の列に表示されるプルダウンメニュー２０１４から所望の演算を選択する。さらに統計値の種類２０１３もプルダウンメニュー（図示なし）で選択する。なお、統計値の種類２０１３は、統計値ＩＤ２００１が指し示す稼動統計分析テーブル１１５のデータ名２００２に対応し、統計情報の単位（Ｒｅａｄ／ｓｅｃやｗｒｉｔｅ／ｓｅｃ等）を設定する。また、統計情報の単位のＲｅａｄ／ｓｅｃやｗｒｉｔｅ／ｓｅｃは、データ転送速度＝データ量（ＭＢ）／ｓｅｃや転送速度＝トランザクション数／ｓｅｃなど予め設定した単位を意味する。
【０２３０】
＜分析のフローチャート＞
図２８を用いてモニタリングシステム１００が実行する図２９の分析処理２０３５の流れを説明する。
【０２３１】
モニタ端末３５０で、モニタリングシステム１００のユーザが注目するシステム要素（仮想化されている物理リソース＝ベースリソース４１０の構成要素）を図２９の画面に表示したシステム構成図上から選択操作（クリック等）を受け付ける（ステップ２０２０）とステップ２０２１に進む。
【０２３２】
ステップ２０２１では、選択操作で選択されたシステム要素（図２５のＨＢＡ４１５）に紐づけられた統計情報をモニタリングシステム１００が構成情報管理テーブル１３０を検索する。統計情報が登録されている場合、ステップ２０３０に遷移し、統計情報を画面上に表示して処理は終了。統計情報が登録されていない場合は、ステップ２０２３に移る（ステップ２０２２）。
【０２３３】
ステップ２０２３では、モニタリングシステム１００がプラットフォームツリー６００から相互参照のあるサービス提供ツリー６１０をたどり、サービス提供ツリー６１０の子ノード（図２５のｖＨＢＡ４６５０）を検索する。そして、モニタリングシステム１００は子ノード（ｖＨＢＡ４６５０）に紐付けられたサービス提供ツリー６１０上のＨＢＡの統計情報として、統計値ＩＤ＝４００１と統計値ＩＤ＝４００２を取得する。次に、モニタリングシステム１００は稼働統計分析テーブル１１５を参照して検索した子ノードの統計値ＩＤのレコードで演算２００４で指定されたデータを参照する（ステップ２０２４）。
【０２３４】
図２６では、統計値ＩＤ４００１または４００２の演算２００４列で指定されているリンク先要素の統計値を検索する。ここでいうリンク先とは、ｘｐａｔｈ（図３２Ａ、図３２Ｂ）で指定されているプラットフォームツリー６００上のノードを指している。ステップ２０２５，２０２６，２０２７では、サービス提供ツリー６１０上で注目している（クリックした）親ノードに接続しているすべての子ノードで統計値を検索し、発見した統計値を返す。上記処理の終了後、ステップ２０２８に進む。
【０２３５】
ステップ２０２８では発見した統計情報を、稼働統計分析テーブル１１５で指定した親ノードの表示形式に統計情報管理部１９０で変換し、ステップ２０２９に進む。
【０２３６】
ステップ２０２９では、サービス提供ツリーの親ノードと相互参照のあるプラットフォームツリーのノードの統計値として数値を統計情報ＧＵＩ制御部２６０がモニタ端末３５０の画面上に表示する（ステップ２０３０）。
【０２３７】
上記処理によりモニタ端末３５０の表示装置には、図２９の統計情報（２０４１）が所定のグラフで表示される。
【０２３８】
＜変形例＞
本発明の変形例として、性能分析ナビゲーションシステムを説明する。システムの概略を、図３０を用いて説明する。構成情報と統計情報の関連を一つの画面上に表示することは先に述べた実施形態と同様である。モニタ端末３５０の表示装置の画面上の分析ナビゲーション開始ボタン２１０２を入力装置等により選択する（クリック）と、物理リソースを含むベースリソース４１０を共有している仮想リソース（仮想リソース４２０）の利用状況の積み上げグラフが表示される（第一ステップ：共有リソースの状況２１０１）。
【０２３９】
例えば、物理サーバ４１１の物理ＣＰＵ（プロセッサ４１２）を各仮想サーバ（０〜２）でどのくらい利用しているかを判別するためのグラフ（ＣＰＵ使用率）や、ＨＢＡを各仮想サーバ毎にどのくらい使用しているのかを判別するための各仮想サーバのＩＯスループットの積み上げグラフ（ＨＢＡ０のデータ転送速度）等が挙げられる。
【０２４０】
管理者は、このグラフを見ることで、どの仮想サーバ０〜２が物理リソースを多く使い、どの仮想サーバ０〜２の動作に影響を及ぼしているかを判定することが可能である。更に、管理者がモニタ端末３５０の入力装置で監視対象切換えボタン２１０３を操作することで、各仮想サーバ０〜２で計測された統計情報（例えば、ＣＰＵ使用率やＩＯスループットなど）のグラフが表示され、それぞれの稼働状態を検証できる。このようにして、仮想化された計算機システムでの性能分析を支援することが可能である。
【０２４１】
性能分析ナビゲーションシステムの動作を図３１のフローチャートを用いて説明する。初めにナビゲーションの初期画面をモニタリングシステム１００がモニタ端末３５０に表示する（ナビゲート２１００ 開始）。システムの管理者は、モニタ端末３５０の入力装置等から表示されている画面上のナビゲート開始ボタン２１０２をクリックし、モニタリングシステム１００はモニタ端末３５０の入力装置からの信号を受け付ける（ステップ２１１１）と、ステップ２１１２に進む。
【０２４２】
ステップ２１１２では、モニタリングシステム１００では、図２の統計情報ＧＵＩ制御部は統計情報管理部１９０にナビゲート開始を通知する。統計情報管理部１９０は構成情報管理部２００にサービス提供ツリー６１０の親ノードをリストアップするように指示し、ステップ２１１３に進む。
【０２４３】
ステップ２１１３では、構成情報管理部２００でリストアップされた親ノードに対して、図２８の分析処理２０３５を実行する（ステップ２１１４）。ただし、ステップ２５０２でユーザがクリックして注目するノードを指定する代わりに、リストアップされたサービス提供ツリー６１０の親のノードが関連付けられているプラットフォームツリー６００のノードが入力される。これは例えば図２５のサービス提供ツリー６１０のＨＢＡ４１５０に相互参照がつけられているプラットフォームツリー６００のＨＢＡ４１５のことである。一つのノードについて処理が終了したら次のノードに対して同じ処理を実行する（ステップ２１１５）。
【０２４４】
全ての親ノードの処理が終了したらモニタ端末３５０に積み上げグラフを表示する。次にステップ２１１７、２１１８、２１１９、２１２０で全ての仮想サーバの統計情報についてグラフを作成する処理をする。グラフの表示に必要な処理は既に説明した図１４の手順で実行されるので、ここでは省略する。
【０２４５】
全ての仮想サーバ０〜２の情報を一度にモニタ端末３５０の表示装置の画面に表示しても、管理者はどこを見るべきか判断が難しくなるため、ステップ２１１８ではモニタリングシステム１００が画面上の監視対象切替ボタン２１０３の操作を受け付けると、表示するデータを切換える。ステップ２１１９では、モニタリングシステム１００が、各仮想サーバ０〜２に関連付けられた統計情報をモニタ端末３５０の表示装置へ出力する。上記処理を全ての仮想サーバ０〜２について繰り返した後（ステップ２１２０）、処理を終了する。
【０２４６】
上記処理によって、監視対象リソース４００を構成するベースリソース４１０の物理的な構成と仮想リソース４２０の仮想化された構成について、モニタ端末３５０の表示装置へ表示を行い、ベースリソース４１０の構成要素である物理サーバ４１１を共有する全ての仮想サーバのリソースの利用状況（２１０１）と仮想サーバ毎のリソースの利用状況をそれぞれグラフとして表示することができる。
【０２４７】
以上のように、本発明の実施形態及び変形例によれば、監視対象リソース４００について、物理リソースを含むベースリソース４１０と、ベースリソース４１０のリソースを使用する仮想リソースを含む仮想リソース４２０に分ける。そして、ベースリソース４１０と仮想リソース４２０の構成要素の関係を漏れなく、かつ少ない手数で構成情報と統計情報の管理を行うことが可能となる。ベースリソース４１０または仮想リソース４２０の統計情報は、モニタリングシステム１００によって、任意の構成要素から、物理リソース（ベースリソース４１０のリソース）を共有する仮想リソースごとの統計情報を容易に分析することが可能となる。また、構成情報のデータ構造に従って統計情報を分析することで、モニタリングシステム１００を利用する管理者等に効率的な統計情報の管理をナビゲートすることが可能となる。これらにより、稼動情報から計算機リソースのボトルネックを検出するまでの時間を短縮でき、多数の計算機、特に多数の仮想サーバを備えた計算機システムにおける運用や管理に要する管理者の効率を改善できる。
【０２４８】
上記従来技術の特許文献１と比較して、本発明では木構造のプラットフォームツリー６００とサービス提供ツリー６１０に分類し、木構造の相互参照を定義しておくことで構成要素の追加や変更を容易に管理することが可能となる。
【０２４９】
監視対象リソース４００の構成要素の追加や削除のコストは、サーバ台数をＳとすると、サーバ台数によらず当該サーバが関係している部分だけの変更にとどまるためＯ（１）回のコストで実行でき、データ量はサーバ台数に比例するのでＯ（Ｓ）であるといえる。したがって、従来技術と比較するとコスト面で本特許の方式でコストを低減できる。
【０２５０】
また、上記実施形態では、モニタリングシステム１００と構成管理マネージャ３６０と稼動情報集計部３００が異なる計算機で稼動する例を示したが、これらが同一の計算機で稼動することもでき、この場合にはモニタリング部と構成管理部と稼動情報集計部をソフトウェアとして実装することができる。
【産業上の利用可能性】
【０２５１】
以上のように、物理サーバと仮想サーバを備えて構成情報または統計情報の履歴を管理する計算機システムに適用することができる。
【符号の説明】
【０２５２】
１００ モニタリングシステム
１１０ モニタ情報データベース
１１５ 稼働統計分析テーブル
１２０ 稼動統計テーブル
１３０ 構成情報管理テーブル
１５０ コンポーネント履歴管理テーブル
１６０ 割当済ＩＤ管理テーブル
１８０ 構成関連管理テーブル
１９０ 統計情報管理部
２００ 構成情報管理部
２１０ 履歴情報管理部
２５０ 統計情報ＧＵＩ制御部
２６０ 構成情報ＧＵＩ制御部
２７０ 履歴情報ＧＵＩ制御部
３００ 稼動情報収集部
３５０ モニタ端末
３６０ 構成管理マネージャ
３８１ ツリー変換設定
３８３ 基準構成テーブル
３８４ ｘｐａｔｈ生成テーブル
４００ 監視対象リソース
４１０ ベースリソース
４２０ 仮想リソース
４９０ 相互参照
６００ プラットフォームツリー
６１０ サービス提供ツリー
【技術分野】
【０００１】
本発明は、複数の物理リソースと仮想リソースから構成される計算機システムのモニタリングシステムに関する。
【背景技術】
【０００２】
＜運用管理における業界の傾向＞
計算機システムを運用するデータセンタなどでは、ネットワーク機器、ストレージ装置、サーバ装置、ＯＳ、サーバ仮想化ソフトウェア等の管理情報をＸＭＬ形式で記述をサポートあるいはサポートを計画しているベンダが増加している。さらに、機器間や運用ソフト間での管理情報のやり取りをＸＭＬ形式のファイルで行う傾向も高まっている。
【０００３】
これらの運用管理情報の標準化仕様として、ＤＭＴＦ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｍａｎａｇｅｍｅｎｔ Ｔａｓｋ Ｆｏｒｃｅ）が策定したシステムの管理情報のモデルＣＩＭ（Ｃｏｍｍｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ）をベースにした管理情報の記述方法が浸透しつつある。ＣＩＭはＵＭＬでモデリングするが、装置に関するデータはＸＭＬ形式で操作される。このような背景のもと、システムの構成情報をＸＭＬで記述することが運用管理に関わる分野では標準的手法となりつつある。
【０００４】
＜モニタリングシステムについて＞
企業の情報システムやデータセンタなどでは、業務開発に合わせて構築した多数の計算機システムを統合し、一括運用管理をしていくニーズが高まっている。システム統合をしていく上でサーバ仮想化をはじめとしたシステムの仮想化技術がベースとなり広く普及しつつある。
【０００５】
一方、計算機システムの定常的な維持保守作業の中で、各種装置に関する統計情報は、性能モニタリングツールで採取し、シェルスクリプト等の実行をスケジューリングできるツールを使って自動的に運用することで監視対象のサーバ等のシステム装置から定期的に収集されている。
【０００６】
計算機システムの構成情報は表計算ソフトウェアのワークシート上で管理していることが多い。構成情報の更新には、構成情報の記録が正しいか否かを、管理者などが現在の構成情報の調査をする必要がある。この構成情報の調査では、ＳＮＭＰ等の業界標準インタフェースを用いて自動的に集められるものや、装置単位で担当者が異なるため、当該装置の担当者にインタビューして確認するなど様々であるため、現実的にはシステム全体（サーバとストレージ、ネットワークなど）の接続関係は、ワークシート上の図面で記録しているケースが多い。図面上での接続関係の調査は、グループ化やオブジェクトの順序等の機能を駆使して調査する。
【０００７】
また、データセンタ等では、計算機システムの構成情報に加えて、稼動している計算機や装置の稼動に関する統計情報をソフトウェアなどで自動的に収集し、管理者などが統計情報から稼動状態の分析を行う。稼働状態分析を行うトリガとしては、顧客への稼働状態の定期レポートの作成や、統計情報の閾値監視でアラートが発生したケースがある。稼働状態分析では、調査をしたい時点の計算機システムの構成情報から、仮想サーバが共有している物理リソースを見つけ出す作業を管理者等が試行錯誤しながら実行している。あるいは、計算機システムの性能に関して問題が発生した時点の構成情報と、問題発生前の構成情報とを管理者などが比較して、問題発生箇所のあたりをつけるといったことが日常的に行われている。例えば、管理者等は統計情報から物理リソースのトータルでの使用率を見て、当該個所が性能ボトルネックを起こしているか判断する。そして、管理者等はどの仮想サーバが性能に影響を与えているか統計情報を見て判断する。
【０００８】
構成情報上で注目した物理リソースの統計情報が直接採取できていない場合は、構成情報から採取できている他の統計情報から推測できないかを管理者等が検討し、既存のデータから物理リソース上の仮想サーバごとの利用状況を推測する必要がある。しかし、稼働状態監視の為の作業において、（１）構成情報の管理、（２）稼働情報と構成情報の関係調査、（３）仮想化で共有された物理資源の稼働情報の推定を、管理者等が手作業で試行錯誤しながら実行しており、非常に工数がかかっている。
【０００９】
一方、データセンタ等においては仮想化技術の導入で、運用すべき仮想化サーバ台数が数万のオーダになる可能性がある。数万台のオーダの仮想サーバの運用管理を効率化するためには、上述の稼働状態分析を省力化していく必要がある。
【００１０】
特許文献１の技術では、構成情報についてはＸＭＬを使って記述をしているが、稼働統計情報と構成情報を紐づけて表示することは行っていない。
【００１１】
特許文献２の技術は、ストレージ装置を中心に仮想サーバとストレージ装置の現在の関係を自動的に取得して構成図として表示し、システム要素の統計情報との関連を表示している。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特表２００７−５２４８８９号公報
【特許文献２】米国特許出願公開第２００８／０１６４３４４号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかし、上記従来例の特許文献１の技術では、統計情報の履歴は記録するが、構成情報の履歴は取得していない。また、特許文献２の技術では、システム要素間にまたがる統計情報の分析、例えば、ストレージのデータからＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｏｒ）の性能予測は行わない。
【００１４】
特許文献２の技術では、構成情報の履歴を取得しないので、必要に応じて構成図を作りなおす必要が生じる。構成情報の履歴について、仮に表の履歴をとると仮定する。システム要素数をＭ、システム要素間の関係（グループ）の数をＮとし、操作の回数（手間）をＯとすると、以下の考え方でサーバ台数ＳのときにはＯ（Ｓ2）回の手間（コスト）がかかる。
【００１５】
つまり、仮想サーバを異なる物理サーバ上に移動するケースを想定すると、表の場合、仮想サーバが追加されると新たな行と列を追加することになるので、構成変更のたびに表を作りなおすことになる。システム要素間の関係数とサーバの数とシステム要素数の関係は、
Ｎ∝Ｓ かつ Ｍ∝Ｓであることから、
Ｏ（Ｎ×Ｍ）＝Ｏ（Ｓ×Ｓ）＝Ｏ（Ｓ2）となる。
【００１６】
将来のデータセンタでは仮想サーバ台数は数万台になり、かつ仮想サーバの追加削除が日常的に頻繁に行われることが予想されている。この前提条件のもとでは、表でシステム要素間の関係を管理する場合、仮想サーバの変更が行われる度にＯ（Ｓ2）回の手間(データ量と表生成のコスト)がかかる、という問題があった。
【００１７】
上述の技術的背景や先行技術の問題を解決するために、計算機システムの構成情報の履歴管理と統計情報の取得を行って、構成情報の履歴と統計情報と構成情報の紐づけを行い、仮想サーバで共有している物理リソースの稼働状態を容易に分析可能とすることが必要であり、さらに、仮想サーバの追加削除等の構成変更の際のコストを低減させる、という課題があった。
【００１８】
そこで、本発明の目的は、計算機システムの構成情報と統計情報の関連付けを表示するモニタリングシステムにおいて、仮想サーバが利用する計算機リソースの関係を漏れなくツリー構造で表現し、かつ物理リソースを共有する仮想リソースの統計情報を自動的に集計することを可能にするものである。
【課題を解決するための手段】
【００１９】
本発明は、１つ以上の物理計算機と、前記物理計算機で実行されて１つ以上の仮想計算機を稼働させる仮想化部と、前記仮想化部上で稼動する１つ以上の仮想計算機と、前記物理計算機の構成要素と、前記仮想計算機の構成要素と、を監視するモニタリング部と、を備えた計算機のモニタリングシステムであって、前記モニタリング部は、前記物理計算機の構成要素である物理リソースと、前記仮想化部の構成要素とを併せてベースリソースとし、前記仮想化部上で稼動する仮想計算機の構成要素を仮想リソースとして管理し、前記仮想リソースの構成要素と前記ベースリソースの構成要素を所定のプラットフォーム毎に木構造を抽出してプラットフォームツリーを生成し、前記仮想リソースの構成要素から、所定の変換情報に設定された前記ベースリソースまたは仮想リソースを起点とする木構造を抽出してサービス提供ツリーを生成し、前記プラットフォームツリーに含まれ、かつ、前記サービス提供ツリーに含まれる構成要素について参照することを示す参照情報を設定し、前記プラットフォームツリーと前記サービス提供ツリーの構成要素の参照関係を設定する。
【発明の効果】
【００２０】
したがって、本発明によれば、仮想サーバと、仮想サーバが利用するベースリソースの関係を漏れなく、かつ少ない手数で管理することが可能となる。さらに、稼働に関する統計情報を任意の構成要素から、仮想サーバごとの使用状況を分析することが可能となる。また、木構造に従ってユーザが統計情報を分析することで効率的な統計情報の見方をナビゲートすることが可能となる。これらにより、稼動情報から計算機リソースのボトルネックを検出するまでの時間を短縮でき、多数の計算機を備えた環境における運用管理の効率を改善できる。
【００２１】
上記特許文献１と比較して、本発明は木構造で構成情報を出力するので追加や削除に要するコストは、サーバ台数をＳとすると、サーバ台数によらず当該サーバが関係している部分だけの変更にとどまるためＯ（１）のコストで実行でき、データ量はサーバ台数に比例するのでＯ（Ｓ）となり、上記従来技術と比較すると管理に要するコストとデータ量を低減できる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態を示し、本発明を適用する計算機モニタリングシステムを含む計算機システムの全体のブロック図である。
【図２】本発明の実施形態を示し、モニタリングシステム１００の内部構成を示したブロック図である。
【図３】本発明の実施形態を示し、稼動統計テーブル１２０の構成例である。
【図４】本発明の実施形態を示し、構成情報管理テーブル１３０の構成例である。
【図５】本発明の実施形態を示し、構成情報変更履歴管理テーブル１４０の構成例である。
【図６】本発明の実施形態を示し、コンポーネント履歴管理テーブル１５０の構成例である。
【図７】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのツリー表現の一部を抜粋した説明図である。
【図８】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのツリー表現の一部を抜粋した説明図である。
【図９】本発明の実施形態を示し、構成情報ＸＭＬ５００ｂのツリー表現の一部を抜粋した説明図である。
【図１０】本発明の実施形態を示し、構成情報ＸＭＬ５００ｃのツリー表現の一部を抜粋した説明図である。
【図１１】本発明の実施形態を示し、構成情報関連管理部２３０が管理するコンポーネントＩＤの状態遷移図である。
【図１２】本発明の実施形態を示し、構成情報ＸＭＬ５００ａに相当する割当済ＩＤ管理テーブル１６０の構成例である。
【図１３】本発明の実施形態を示し、構成情報ＸＭＬ５００ａに相当する割当済ＩＤ管理テーブル１６０の構成例である。
【図１４】本発明の実施形態を示し、稼動統計情報表示時に統計情報管理部１９０で行われる処理のフローチャートを示す。
【図１５】本発明の実施形態を示し、モニタリングシステム１００のモニタ端末３５０に表示される稼動統計モニタ画面の一例を示す画面イメージである。
【図１６】本発明の実施形態を示し、稼働情報収集部３００の構成を示すブロック図である。
【図１７】本発明の実施形態を示し、稼働情報収集部３００が使用する稼働情報収集パラメータ３１０の定義の説明図である。
【図１８】本発明の実施形態を示し、稼動情報収集部３００で行われる処理のフローチャートを示す。
【図１９】本発明の実施形態を示し、稼働統計値登録部３４０で行われる統計値登録処理１５８０の詳細なフローチャートを示す。
【図２０】本発明の実施形態を示し、構成管理マネージャ３６０の詳細を示すブロック図である。
【図２１】本発明の実施形態を示し、構成変更要求生成部３６４が出力する構成情報生成ポリシー２４０の一例を示す説明図である。
【図２２】本発明の実施形態を示し、監視対象リソース４００の一例を示す仮想計算機システムのブロック図である。
【図２３】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのツリー表現の一部を抜粋した図である。
【図２４】仮想化を適用した計算機システムの構成図をノード（頂点）とエッジ（辺）を用いて表現した例の説明図である。
【図２５】自動的にサービス提供レイヤーの統計情報からプラットフォームレイヤーの統計情報を算出するためのデータ表現を示した例である。
【図２６】本発明の実施形態を示し、稼働統計分析テーブル１１５の構成例である。
【図２７】本発明の実施形態を示し、稼働統計分析の演算を指定するポップアップウィンドウ入力画面２０１５の構成例である。
【図２８】本発明の実施形態を示し、自動的にサービス提供レイヤーの統計情報からプラットフォームレイヤーの統計情報を算出するフローチャートを示した図である。
【図２９】本発明の実施形態を示し、自動的にサービス提供レイヤーの統計情報からプラットフォームレイヤーの統計情報を算出した出力画面の構成例を示した画面イメージである。
【図３０】本発明の第１の変形例の実施形態を示し、性能分析ナビゲーション画面の構成例を示した図である。
【図３１】本発明の第１の変形例の実施形態を示し、性能分析ナビゲーションのフローチャートを示した図である。
【図３２Ａ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのＸＭＬ表現の一部を抜粋した図の前半部である。
【図３２Ｂ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのＸＭＬ表現の一部を抜粋した図の後半部である。
【図３３】本発明の実施形態を示し、構成情報ＸＭＬ５００ａのＸＭＬ表現の一部を抜粋した図である。
【図３４Ａ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａから構成情報ＸＭＬ５００ｂに構成変更したときのＸＭＬ表現の変更部分を示した図の前半部である。
【図３４Ｂ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａから構成情報ＸＭＬ５００ｂに構成変更したときのＸＭＬ表現の変更部分を示した図の後半部である。
【図３５Ａ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａから構成情報ＸＭＬ５００ｂに構成変更したときのＸＭＬ表現の変更部分を示した図の前半部である。
【図３５Ｂ】本発明の実施形態を示し、構成情報ＸＭＬ５００ａから構成情報ＸＭＬ５００ｂに構成変更したときのＸＭＬ表現の変更部分を示した図の後半部である。
【図３６】本発明の実施形態を示し、基準構成テーブルの一例を示す説明図である。
【図３７】本発明の実施形態を示し、ｘｐａｔｈ生成テーブルの一例を示す説明図である。
【図３８】本発明の実施形態を示し、構成管理マネージャで行われるノード生成処理の一例を示すフローチャートである。
【図３９】本発明の実施形態を示し、構成管理マネージャで行われる木構造生成処理の一例を示すフローチャートである。
【図４０】本発明の実施形態を示し、構成管理マネージャで行われるｘｐａｔｈ生成テーブル設定処理の一例を示すフローチャートである。
【図４１】本発明の実施形態を示し、構成管理マネージャで行われる構成情報生成処理の一例を示すフローチャートである。
【図４２】本発明の実施形態を示し、暫定構成ＸＭＬ３８５の構成例である。
【発明を実施するための形態】
【００２３】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００２４】
＜全体ブロック図＞
図１は、第１の実施形態を示し、本発明を適用する計算機モニタリングシステムを含む計算機システムの全体ブロック図である。計算機システムは、監視対象となる計算機リソース（以下、監視対象リソースとする）４００と、モニタリングシステム（モニタリング装置）１００、稼動情報集計部３００と、監視対象リソース４００の構成を管理する構成管理マネージャ３６０、およびモニタリングシステム１００が収集した情報を参照するモニタ端末３５０とから構成される。
【００２５】
監視対象リソース４００は、ラックや物理的なサーバ（物理計算機）と、ストレージと、ネットワークおよび物理的なサーバのリソース（物理リソース）を仮想化するソフトウェア（ハイパーバイザまたは仮想マシンモニタ）などを含むベースリソース４１０と、ベースリソース４１０の上に実装された仮想的なサーバ（仮想計算機）や、仮想的（または論理的）なストレージ、仮想的なネットワーク、および仮想的なサーバ上で動作するソフトウェア（ゲストＯＳ）などの仮想リソース４２０を含む。
【００２６】
仮想リソース４２０には、ベースリソース４１０や仮想リソース４２０のリソース使用状況を示す稼働情報の統計値（統計情報）や、ベースリソース４１０の消費電力、装置からの排気の温度等の環境情報、および稼働状態を表すログといった情報が含まれる。
【００２７】
稼動情報集計部３００は監視対象リソース４００と同一の計算機上で動作する場合も、異なる計算機上で動作する場合もある。本実施形態では稼動情報集計部３００は図２２に記載の物理サーバ４１１−１〜４１１−ｎのいずれかひとつで実行するものとする。なお、稼動情報集計部３００を実行するサーバは、物理サーバでも良いし、仮想サーバであってもよい。構成管理マネージャ３６０とモニタリングシステム１００も同様であり、異なる計算機上で実行させても良い。いずれの場合も差異は本発明の本質には影響しない。なお、本実施形態では、構成管理マネージャ３６０とモニタリングシステム１００も物理サーバ４１１−１〜４１１−ｎのいずれかひとつで実行するものとする。
【００２８】
本実施形態では、監視対象リソース４００がベースリソースと仮想リソースで構成されているものとする。
【００２９】
監視対象リソース４００のベースリソース４１０は、図２２に示す複数の物理計算機（物理サーバ）４１１−１〜４１１−ｎと仮想サーバ４２２を生成するサーバ仮想化部４２１を主体にして構成される。各計算機は物理的なプロセッサとメモリ及びインタフェースを有し、インタフェースを介してストレージ装置４５０とネットワーク４３０に接続される。これらの物理的な計算機リソースを物理リソースとする。そして、ベースリソース４１０には、メモリ４１３にロードされてプロセッサ４１２で実行されるサーバ仮想化部（ハイパーバイザまたはＶＭＭ）４２１が含まれる。つまり、ベースリソース４１０は物理リソースにサーバ仮想化部４２１（論理リソース）を加えたものである。したがって、以下の説明ではベースリソース４１０からサーバ仮想化部４２１を除いたものを物理リソースとする。
【００３０】
そして、本発明では、ベースリソース上で仮想リソースが稼動する、と定義する。
【００３１】
仮想リソース４２０は、仮想サーバ４２２−１〜４２２−ｍと、各仮想サーバ上で実行されるＯＳ４２３及びＯＳ４２３がアクセスするストレージ装置４５０のＬＵ（論理ディスク）４６５−１〜４６５−ｋや、仮想化されたＩ／Ｏデバイス（仮想ＮＩＣを、仮想ＨＢＡ）が含まれる。仮想リソース４２０は、サーバ仮想化部４２１が仮想サーバ４２２に対して割り当てる仮想または論理的なリソースで構成される。
【００３２】
なお、図示はしないが、サーバ仮想化部４２１上の仮想サーバ４２２でさらにサーバ仮想化部を稼動させる場合では、仮想サーバ４２２上のサーバ仮想化部をベースリソースとして扱うことができる。
【００３３】
ベースリソース４１０と仮想リソース４２０を含む監視対象リソース４００の具体的な例としては、例えば、図２２のようになる。
【００３４】
図２２は、監視対象リソース４００の一例を示す仮想計算機システムのブロック図である。ベースリソース４１０は、複数の物理サーバ４１１−１〜４１１−ｎとネットワーク４３０とＳＡＮ（Storage Area Network）４４０及びストレージ装置４５０及びサーバ仮想化部４２１から構成される。物理サーバ４１１−１〜４１１−ｎは同一の構成であるので、以下では物理サーバ４１１−１のみについて説明する。
【００３５】
物理サーバ４１１−１は、プロセッサ４１２、メモリ４１３、ＮＩＣ（Network Interface Card）４１４、ＨＢＡ（Host Bus Adapter）４１５から構成される。なお、図示はしないが物理サーバの起動、停止や監視を行うＢＭＣ（Baseboard Management Controller）を備えても良い。
【００３６】
プロセッサ４１２は、メモリ４１３内に格納された各種プログラムを実行する。ＨＢＡ４１５はＳＡＮ４４０を介してストレージ装置４５０に接続される。ＮＩＣ４１４はネットワーク４３０に接続される。ＮＩＣ４１４は、主にメモリ４１３上の各種プログラムからの要求に応じて他のサーバと通信する。ネットワーク４３０には、ベースリソース４１０を仮想リソース４２０へ割り当てる構成管理マネージャ３６０や、ベースリソース４１０及び仮想リソース４２０の構成要素の稼動情報を収集する稼動情報収集部３０５が接続される。なお、ネットワーク４３０にはモニタリングシステム１００やモニタ端末３５０が接続されても良い。
【００３７】
メモリ４１３上には、サーバ仮想化部４２１が稼働することで、複数の仮想サーバ４２２−１〜４２２−ｍを構築することができる。サーバ仮想化部４２１にはハイパーバイザとも呼ばれる仮想化技術が含まれる。なお、仮想サーバ４２２−１〜４２２−ｍの総称を仮想サーバ４２２とする。仮想サーバ４２２は、それぞれ独立してＯＳ（Operating System）４２３を稼働させることができる。プロセッサ４１２によりサーバ仮想化部４２１が実行されると、サーバ仮想化部４２１上で複数の仮想サーバ４２２を構築することができる。
【００３８】
サーバ仮想化部４２１は、構成管理マネージャ３６０の指令に応じて物理サーバ４１１−１の物理リソースを仮想化して、仮想サーバ４２２−１〜４２２−ｍを主体とする仮想リソース４２０に割り当てる。また、サーバ仮想化部４２１は、ＮＩＣ４１４やＨＢＡ４１５を仮想化して仮想サーバ４２２−１〜４２２−ｍに提供する。仮想化したＮＩＣ４１４やＨＢＡ４１５は、仮想ＮＩＣ（ｖＮＩＣ）や仮想ＨＢＡ（ｖＨＢＡ）とする。また、サーバ仮想化部４２１は、仮想サーバ４２２−１〜４２２−ｍに対してプロセッサ４１２（物理プロセッサ４１２）を仮想化した仮想プロセッサや、メモリ４１３を仮想化した仮想メモリを割り当てる。なお、サーバ仮想化部４２１がハイパーバイザの場合、プロセッサ４１２の複数のコアのうち所望のコア数を仮想サーバ４２２−１〜４２２−ｍに対して割り当てる。
【００３９】
仮想サーバ４２２はストレージ装置４５０に予め格納されたＯＳイメージをサーバ仮想化部４２１が読み込んで実行することで、それぞれ独立した仮想サーバ４２２が構築される。なお、以下では物理サーバ４１１−１〜４１１−ｎの総称を物理サーバ４１１とする。
【００４０】
ストレージ装置４５０は、コントローラ４８０とＲＡＩＤ Ｇｒｏｕｐ（以下、ＲＧ）４８５−１〜４８５−ｈとで構成されている。図２２ではコントローラ４８０は１個のみ存在しているが複数個存在することもある。コントローラ４８０は、ディスクドライブへのデータの読み書きやＳＡＮ４４０と接続するファイバチャネルインターフェースの制御を行っている。ＲＧ４８５−１〜４８５−ｈは、それぞれハードディスクドライブ（ＨＤＤ）を１個以上纏めたＲＡＩＤで構成される。各ＲＧ４８５−１〜４８５−ｈは、論理的なディスク装置（またはストレージデバイス）であるＬｏｇｉｃａｌ Ｕｎｉｔ（ＬＵ）４６５−１〜４６５−ｋに論理的に分割されている。それぞれのＬＵ４６５−１〜４６５−ｋは、個別に仮想サーバ４２２−１〜４２２−ｍからアクセス可能になっている。なお、ＬＵ４６５−１〜４６５−ｋは不揮発性の記憶媒体であればよく、ＨＤＤや不揮発性メモリで構成することができる。なお、本実施形態ではＲＧ４８５−１〜４８５−ｈをベースリソース４１０として扱い、ＬＵ４６５−１〜４６５−ｋを仮想リソース４２０として扱う。
【００４１】
複数の物理サーバ４１１−１〜４１１−ｎは、図８に示す複数のサーバシャーシ５２０にそれぞれ格納され、サーバシャーシ５２０はサーバラック５１０に格納されるラックマウントサーバで構成した例を示す。
【００４２】
図２は、モニタリングシステム１００の内部構成を示したブロック図である。モニタリングシステム１００は、各種情報を格納するモニタ情報データベース１１０、モニタ端末３５０とのインタフェースを制御する統計情報ＧＵＩ制御部２５０、構成情報ＧＵＩ制御部２６０、履歴情報ＧＵＩ制御部２７０と、統計情報ＧＵＩ制御部２５０からの指令に基づきモニタ情報データベース１１０をアクセスしてモニタ端末３５０へ出力する情報を決定する統計情報管理部１９０、構成情報管理部２００、履歴情報管理部２１０、稼働情報を統計処理するための計算式が登録されている稼働統計分析テーブル１１５と、が含まれる。これらの各機能はプログラムとして実装され、後述の図２２に示す記憶媒体としてのストレージ装置４５０に格納され、物理サーバ４１１のプロセッサ４１２によりメモリ４１３にロードされて実行される。
【００４３】
モニタ情報データベース１１０の中には、稼動統計テーブル１２０と、構成情報管理テーブル１３０と、構成情報変更履歴管理テーブル１４０と、コンポーネント履歴管理テーブル１５０などが格納される。なお、構成情報変更履歴管理テーブル１４０およびコンポーネント履歴管理テーブル１５０は構成情報管理テーブル１３０から二次的に生成される情報なので、本発明の実施においては必ずしも必要ではなく、表示を高速化するために用意されたテーブルである。また、構成管理マネージャ３６０から得られた構成情報２４５および構成情報生成ポリシー２４０に従って新たな構成情報を生成し、構成情報管理テーブル１３０へと格納する構成情報関連管理部２３０と、構成情報に割当てるＩＤを管理する割当済ＩＤ管理テーブル１６０もモニタリングシステム１００に含まれる。
【００４４】
構成管理マネージャ３６０から受け付ける構成情報生成ポリシー２４０の一例としては、例えば、同一の構成情報のリビジョン更新時には、各構成情報にそれぞれ付与されるコンポーネントＩＤを引き継ぎ、新たな構成情報の追加時には、新たなコンポーネントＩＤを割り当てる。また、構成情報の削除時にはコンポーネントＩＤを回収し、コンポーネントＩＤの使い回しを禁止する等のポリシーを予め設定したものである。
【００４５】
図２０は、構成管理マネージャ３６０の詳細を示すブロック図である。構成管理マネージャ３６０は、監視対象リソース４００についてベースリソース４１０と仮想リソース４２０の構成情報を格納する構成情報ＤＢ３６５と、ベースリソース４１０と仮想リソース４２０からプラットフォームツリー６００とサービス提供ツリー６１０を生成するための基準構成テーブル３８３と、ｘｐａｔｈ生成テーブル３８４と、暫定構成ＸＭＬ３８５を管理する。
【００４６】
構成管理マネージャ３６０は、構成情報ＤＢ３６５が更新される度にモニタリングシステム１００へ通知する。あるいは、図１のモニタ端末３５０から入力されるツリー変換要求３７３を受けたツリー変換設定３８１が、構成情報ＤＢ３６５に格納された構成情報を基準構成テーブル３８３に格納されているシステム要素間の関係を基準にして、ｘｐａｔｈ生成テーブル３８４や暫定構成ＸＭＬ３８５を用いてＸＭＬ形式の構成情報（構成情報ＸＭＬ３８６）を生成する。ツリー変換設定３８１が、この構成情報ＸＭＬ３８６を受けとった構成変更要求生成部３６４が、構成情報２４５でモニタリングシステム１００へ通知する。
【００４７】
モニタリングシステム１００は、構成管理マネージャ３６０からの通知を受信すると、割当済みＩＤ管理テーブル１６０や構成情報管理テーブル１３０等を更新する。
【００４８】
基準構成テーブル３８３と、ｘｐａｔｈ生成テーブル３８４は、上述の監視対象リソース４００（ベースリソース４１０と仮想リソース４２０）の構成要素を、後述する２つのデータ（ツリー）の各構成要素の親子関係の定義とツリーを分類するための定義を格納したものである。基準構成テーブル３８３に格納する要素は、基本的にモニタ端末３５０の入力装置等から管理者が設定する。あるいは、取得構成情報３７５のデータ型式が基準構成テーブル３８３の形式（図３６）で定義されているケースでは、取得構成情報３７５が基準構成テーブル３８３に格納される。構成管理マネージャ３６０は、モニタ端末３５０からプラットフォームツリー６００の要素とサービス提供ツリー６１０の要素を定義する基準構成入力３８２を受信すると、基準構成テーブル３８３を更新する。
【００４９】
なお、基準構成テーブル３８３と、ｘｐａｔｈ生成テーブル３８４と、暫定構成ＸＭＬ３８５は、モニタリングシステム１００から参照または更新することも可能である。また、モニタリングシステム１００は、基準構成テーブル３８３と、ｘｐａｔｈ生成テーブル３８４と、暫定構成ＸＭＬ３８５の複製をモニタ情報データベース１１０に保持しておいてもよい。
【００５０】
基準構成テーブル３８３は、プラットフォームツリー６００の親ノードと子ノードの木構造と、サービス提供ツリー６１０の親ノードと子ノードの木構造をそれぞれ定義するものである。
【００５１】
ｘｐａｔｈ生成テーブル３８４と暫定構成ＸＭＬ３８５は、モニタリングシステム１００がプラットフォームツリー６００とサービス提供ツリー６１０を生成するときに利用される。プラットフォームツリー６００とサービス提供ツリー６１０の生成については後述する。
【００５２】
構成管理マネージャ３６０は、サーバ仮想化部４２１に対して、仮想リソース４２０に対する物理リソース割り当てを制御する。つまり、構成管理マネージャ３６０は、仮想サーバ４２２に割り当てる物理サーバ４１１やストレージ装置４５０の監視対象リソース４００（計算機リソース）をサーバ仮想化部４２１に対して指令する。
【００５３】
また、構成管理マネージャ３６０は、物理サーバ４１１の稼動状態を制御する。構成管理マネージャ３６０は、仮想サーバ４２２の生成や削除あるいは移動の指令（構成情報及び構成情報生成ポリシーを含む構成変更指令）を監視対象リソース４００の仮想化部４２１に指令して、各物理サーバ４１１の仮想サーバ４２２を制御する。また、構成管理マネージャ３６０は、監視対象リソース４００に指令した構成変更指令の構成情報２４５及び構成情報生成ポリシー２４０をモニタリングシステム１００に通知する。
【００５４】
モニタリングシステム１００が監視する監視対象リソース４００が、予め構築されている場合、構成管理マネージャ３６０に対して管理者が構成取得要求３７２を入力し、構成取得要求生成部３７１で構成取得コマンド３７４を生成し、監視対象リソース４００に発行する。構成取得コマンド３７４の実装形態の一つとしてはＳＮＭＰやＣＩＭ、ＳＭＩ−Ｓ、ＳＭＡＳＨのようなシステムの運用管理の為の標準インタフェースが挙げられる。
【００５５】
構成取得コマンド３７４の応答として監視対象リソース４００からの応答である取得構成情報３７５を構成管理マネージャ３６０が受信すると、構成変更要求生成部３６４に入力され、構成情報ＤＢ３６５に格納される。また、取得構成情報３７５のデータ型式が基準構成テーブル３８３（図３６）と同じ形式である場合は、基準構成テーブル３８３にも入力される実装をしてもよい。
【００５６】
構成取得コマンド３７４に対して監視対象リソース４００からの応答である取得構成情報３７５は、構成変更要求生成部３６４によって構成情報ＤＢ３６５に格納される。次に、構成変更要求生成部３６４は、ツリー変換設定３８１に構成情報ＸＭＬを作成するように要求を出し、ツリー変換設定３８１は、構成情報ＤＢ３６５と基準構成テーブル３８３とｘｐａｔｈ生成テーブルと３８４と暫定構成ＸＭＬ３８５とを使って構成情報ＸＭＬ３８６を作成する。次に、構成変更要求生成部３６４は、構成情報ＸＭＬ３８６を変更後構成情報２４５ｙとして構成変更情報送信部３６２に送り、構成情報２４５として構成情報関連管理部２３０に転送する。このとき、変更前構成情報２４５ｘは、“空”のデータが渡される。構成情報関連管理部２３０では、図２の構成情報管理部２００を経て、構成情報管理テーブルに格納される。
【００５７】
構成取得コマンド３７４で自動的に採取できない構成情報、例えば運用管理機構を持たないラックマウントのような情報処理装置を格納する棚のような場合、管理者が、構成入力３７２０や基準構成入力３８２を通して、直接的に構成管理マネージャ３６０に入力する。
【００５８】
構成管理マネージャ３６０は、モニタ端末３５０の図示しない入出力装置から監視対象リソース４００に対する構成変更要求３６６を受け付け、構成変更要求３６６が完了すると入出力装置へ構成変更完了通知３６７を出力する構成変更要求処理部３６１と、監視対象リソース４００の構成情報を格納する構成情報データベース３６５と、構成変更要求処理部３６１からの構成変更要求処理部３６１と構成情報データベース３６５の構成情報に基づいて、変更前の構成情報２４５ｘと変更後の構成情報２４５ｙと構成情報の生成ポリシー２４０を生成する構成変更要求生成部３６４と、変更前構成情報２４５ｙと変更後構成情報２４５ｙを構成情報２４５とし、構成情報生成ポリシー２４０と構成情報２４５をモニタリングシステム１００の構成情報関連管理部２３０と構成変更処理指示部３６３送信する構成変更情報送信部３６２と、構成情報生成ポリシー２４０と構成情報２４５に基づいて監視対象リソース４００のサーバ仮想化部４２１に構成変更要求３６６を送信する構成変更処理指示部３６３と、を含んで構成される。
【００５９】
構成情報データベース３６５は、後述の図４に示す構成情報管理テーブル１３０のプラットフォームツリー６００とサービス提供ツリー６１０と同様の構成を備える。ただし、構成情報データベース３６５は、構成情報管理テーブル１３０の構成情報５００（構成情報ＸＭＬ５００ａ〜５００ｃの総称）に含まれる構成要素についてコンポーネントＩＤを有していない。コンポーネントＩＤは、モニタリングシステム１００の構成情報関連管理部２３０が、新たな構成情報２４５を受け付けると新たなコンポーネントＩＤを付与する。
【００６０】
構成管理マネージャ３６０は、モニタ端末３５０の入出力装置（図示省略）から構成変更要求３６６を受け付けると、構成変更要求３６６に含まれるポリシーと、変更前（現在）の構成情報２４５ｘと変更後の構成情報２４５ｙを受け付けて、構成情報２４５と構成情報生成ポリシー２４０をモニタリングシステム１００と監視対象リソース４００に送信する。
【００６１】
そして、構成管理マネージャ３６０は、構成変更要求処理部３６１の処理が完了すると入出力装置へ構成変更完了通知３６７を出力し、新たな構成情報２４５ｙで構成情報データベース３６５を更新する。
【００６２】
また、構成情報管理テーブル１３０の構成情報５００の構成要素に付与されるコンポーネントＩＤは、構成情報関連管理部２３０が付与するモニタリングシステム１００内で一意の値である。このコンポーネントＩＤは、構成情報５００を構成する構成要素の木構造に関わりなく、一意の識別子を構成情報の構成要素毎に構成情報関連管理部２３０が割り当てるものである。コンポーネントＩＤは、監視対象リソース４００の構成要素であるベースリソース４１０の構成要素と、仮想リソース４２０の構成要素のそれぞれについて一意の値が割り当てられる。
【００６３】
すなわち、監視対象リソース４００の構成要素は木構造で構成される階層的な情報であるのに対し、コンポーネントＩＤはモニタリングシステム１００内で一意の識別子として機能する。コンポーネントＩＤは、後述する割当済ＩＤ管理テーブル１６０のように、ベースリソース４１０の構成要素と仮想リソース４２０の構成要素及び統計情報に対してそれぞれ割り当てられる。マイグレーションなどの構成要素の変更を実施するときは、このコンポーネントＩＤを構成変更が行われた構成要素が引き継ぐことで、構成要素に関連付けられた統計情報を、構成変更の前後で結びつけることが可能となる。
【００６４】
図２１は、構成管理マネージャ３６０の構成変更要求生成部３６４が出力する構成情報生成ポリシー２４０の一例を示す説明図である。構成変更要求生成部３６４は、構成変更要求処理部３６１から受け付けた構成変更要求３６６から、変更前の構成情報のノード（部分木）と変更後の構成情報のノード情報及びノード間の関係を抽出し、変更前の構成情報のノードを変更前ノード２４１とし、変更後の構成情報のノードを変更後ノード２４２とし、ノード間の関係をノード間関連２４３として構成情報生成ポリシー２４０を生成する。
【００６５】
ノード間関連２４３としては、「重複しない割当」、「同一ノードを継承」、「移動元」、「移動先」、「交替元」、「交替先」などに分類される。
【００６６】
「重複しない割当」のノード間関連２４３は、ひとつの仮想サーバ４２２を、昼夜で切り替えて使用する場合などで、変更対象のノードが同一で、異なる構成情報ＩＤ（１６２）が割り当てられた構成情報間では、コンポーネントＩＤが重複しないように割り当てるように、構成管理マネージャ３６０はモニタリングシステム１００に指令する。図示の「重複しない割当」の例では、ノードａで構成要素を切り替えて、変更後のノードａの構成要素に新たなコンポーネントＩＤを付与することを示す。
【００６７】
図２１の「同一ノードを継承」のノード間関連２４３は、構成要素が変化しない場合であり、図示の例ではノードｂは構成情報変更の前後で同一のコンポーネントＩＤを引き継ぐことを示す。また、「移動元」および「移動先」のノード間関連２４３は、ノードが移動する場合であり、図示の例では移動元のノードｃがノードｄとして移動することを示す。この場合、モニタリングシステム１００ではノードｃに割り当てられた構成要素のコンポーネントＩＤを変更後の構成情報ではノードｄのコンポーネントＩＤとして付与する。
【００６８】
「交替元」と「交替先」のノード間関連２４３は、現用系と待機系で系切替を行う場合であり、図示の例ではノードｅを交替元として、ノードｆに構成要素を移動することを示す。この場合、モニタリングシステム１００ではノードｅに割り当てられた構成要素のコンポーネントＩＤを、ノードｆの構成要素に割り当てられたコンポーネントＩＤに上書きする。
【００６９】
＜構成変更処理の概要＞
図１の計算機システムで行われる処理の一例を以下に示す。
【００７０】
構成管理マネージャ３６０は、監視対象リソース４００の構成を変更する度にモニタリングシステム１００に構成情報２４５と構成情報生成ポリシー２４０及び基準構成テーブル３８３を通知し、モニタリングシステム１００は通知を受けた構成情報２４５と構成情報生成ポリシー２４０と基準構成テーブル３８３から構成情報管理テーブル１３０のプラットフォームツリー６００とサービス提供ツリー６１０を更新する。
【００７１】
モニタリングシステム１００は、例えば、新たな構成情報２４５を受け付けると、構成情報管理テーブル１３０に当該構成情報２４５の内容（例えば、物理サーバ４１１や仮想サーバ４２２あるいはＩ／Ｏデバイス）を構成情報１３４の構成情報ＸＭＬに加え、構成情報ＸＭＬに含まれる構成要素毎に計算機システム内でユニークなコンポーネントＩＤ１６１を割り当てる。
【００７２】
一方、モニタ端末３５０から、監視対象リソース４００に対する稼動情報の収集要求が稼動情報集計部３００に送信されると、稼動情報集計部３００は要求された監視対象リソース４００に対する稼動情報の収集及び稼動情報の統計値（統計情報）に関する定義を格納し、統計値に対して統計値ＩＤを付与する。稼動情報集計部３００は、稼動情報の統計値の収集対象となった監視対象リソース４００の構成情報ＩＤと統計情報（ＣＰＵ使用率、メモリ使用量など）と統計値ＩＤを対応させてモニタリングシステム１００に通知する。
【００７３】
モニタリングシステム１００は、稼動情報集計部３００から構成情報ＩＤと統計値ＩＤを受け付けて、構成情報管理テーブル１３０のプラットフォームツリー６００とサービス提供ツリー６１０の該当するレコードの構成情報ＸＭＬに、統計値ＩＤと統計情報を格納する。これにより、監視対象リソース４００内で一意の識別子であるコンポーネントＩＤと統計値ＩＤが関連づけられる。
【００７４】
次に、構成管理マネージャ３６０が仮想サーバ４２２の移動を実施すると、モニタリングシステム１００は構成管理マネージャ３６０から構成情報２４５と構成情報生成ポリシー２４０を受け付けて、構成情報生成ポリシー２４０の内容が「交替（交替元、交替先）」であれば、構成情報２４５で指定された移動元のコンポーネントＩＤとコンポーネントＩＤに関連付けられた統計値ＩＤを、移動先の構成情報のコンポーネントＩＤに引き継がせる。これにより、コンポーネントＩＤに関連付けられた統計値ＩＤも構成情報の移動先に引き継がれる。また、構成情報管理テーブル１３０では、構成情報の変更の履歴をリビジョンとして記録する。
【００７５】
稼動情報集計部３００は、所定のタイミングで監視対象リソース４００の監視を行い、指定された稼動情報を収集し、稼動情報に所定の統計処理を施した統計情報をモニタリングシステム１００の稼動統計テーブル１２０に統計値ＩＤとともに格納する。稼動情報集計部３００が監視対象リソース４００の監視を行うタイミングは、構成情報収集パラメータ３１０のモニタ間隔３１４で定義される。なお、統計処理は、平均値や最大値または最小値、標準偏差など、稼動情報に所定の統計処理を施して統計情報を生成する処理である。
【００７６】
モニタ端末３５０が、統計情報をモニタリングシステム１００に要求すると、モニタリングシステム１００は指定された構成情報のコンポーネントＩＤを構成情報管理テーブル１３０から検索し、当該コンポーネントＩＤに関連づけられた統計値ＩＤを取得する。そして、モニタリングシステム１００は、統計値ＩＤに対応する統計情報を稼動統計テーブル１２０から取得して、モニタ端末３５０に出力する。
【００７７】
仮想サーバ４２２を物理サーバ４１１間で移動させても、構成情報生成ポリシー２４０のノード間関連２４３が「同一ノードを継承」等であれば、コンポーネントＩＤと統計値ＩＤはそのまま移動先の構成情報１３４（構成情報ＸＭＬ）に引き継がれるので、仮想サーバ４２２の統計値ＩＤに対応する統計情報を、移動の前後を跨いでモニタ端末３５０で表示することが可能となる。また、モニタ端末３５０が構成情報の履歴をモニタリングシステム１００に要求すると、仮想サーバ４２２の移動の前後の構成情報の履歴をモニタ端末３５０に出力することができる。
【００７８】
以下では、モニタリングシステムの構成要素、及び動作について図面を用いて説明をする。
【００７９】
＜モニタ情報データベース内の各種テーブル＞
図３は稼動統計テーブル１２０の構成例である。統計情報管理部１９０が管理する統計値（統計情報）１２３を格納するテーブルである。各レコードはデータ名称１２９、統計値ＩＤ１２１、タイムスタンプ１２２および１つ以上の統計値１２３から構成される。ここでは統計値１２３として平均値１２４、最小値１２５、最大値１２６、標準偏差１２７、標本数１２８を選んだが、一部でも良いし、これ以外の統計情報で表現してもよい。
【００８０】
稼動統計テーブル１２０は、後述するように稼動情報集計部３００が収集した監視対象リソース４００の稼動情報の統計値を格納する。統計値１２３は、統計値ＩＤ毎に予め設定された単位を有し、例えば、プロセッサの使用率（％）やメモリの使用量（ＧＢ）や単位時間当たりのインタフェースのデータ転送量（Ｉ／Ｏトラフィック：ＧＢ／ｓｅｃ）などである。
【００８１】
図４は、モニタリングシステム１００の構成情報管理テーブル１３０の構成例である。構成情報管理テーブル１３０は、構成管理マネージャ３６０から受信した構成情報２４５を蓄積するモニタ情報データベース１１０のテーブルで、構成管理マネージャ３６０が管理する構成情報の履歴（リビジョン）を格納する。モニタリングシステム１００は、起動すると構成管理マネージャ３６０から構成情報データベース３６５を受信して、現在の監視対象リソース４００の構成情報２４５を構成情報管理テーブル１３０に格納する。
【００８２】
構成情報管理テーブル１３０の各レコードは構成情報ＩＤ１３５、リビジョン１３１、開始日時１３２、終了日時１３３、および構成情報１３４のフィールドから構成される。ここで、構成情報１３４を管理する手法は色々考えられるが、たとえばＸＭＬ形式の構成情報データ５００を作成し、当該構成情報データへのリンクやファイル名を構成情報１３４のフィールドに登録する方法が考えられる。もちろん、構成情報１３４のフィールドにＸＭＬ形式の構成情報データを格納することもできる。なお、終了日時１３３の値が“−”またはＮＵＬＬであるレコードは、最新の構成情報であることを示している。
【００８３】
図４の例では、構成情報ＩＤ１３５＝１である構成情報に対して、３つのリビジョン１３１の構成情報が登録されており、リビジョン１３１＝１とリビジョン１３１＝２のレコードには終了日時１３３が設定されているが、リビジョン１３１＝３のレコードには終了日時１３３が設定されておらず（”−”）、リビジョン１３１＝３の構成情報が現在使用中（最新）のリビジョンであることを示す。各リビジョンに対応する構成情報ＸＭＬ５００ａ、５００ｂ、５００ｃをそれぞれ後述する図８、図９、図１０に示す。ただし、図８、図９、図１０では説明を簡単化するため、稼動情報の統計情報に係る構成情報は省略してある。
【００８４】
モニタリングシステム１００は、構成管理マネージャ３６０から構成情報２４５を受け付けて、監視対象リソース４００の構成情報を世代（リビジョン）毎に構成情報管理テーブル１３０へ格納する。構成情報管理テーブル１３０と構成管理マネージャ３６０の構成情報データベース３６５は、上述したように同様の構成である。このため、構成管理マネージャ３６０は、新たな構成情報２４５ｙを生成すると新たな構成情報ＩＤ１３５とリビジョン１３１＝１を生成する。
【００８５】
なお、構成管理マネージャ３６０で監視対象リソース４００の構成情報の履歴（世代）を管理しない場合では、モニタリングシステム１００の構成情報管理部２００がリビジョン１３１を管理すればよい。この場合、構成情報管理部２００は、同一の構成情報ＩＤ１３５に対して新たな構成情報２４５を受け付けると、現在のリビジョン１３１をインクリメントした値を、新たな構成情報を格納するレコードのリビジョン１３１に最新の世代を示す値を設定する。
【００８６】
図５は構成情報変更履歴管理テーブル１４０の構成例である。構成情報変更履歴管理テーブル１４０は、モニタリングシステム１００の履歴情報管理部２１０が管理する構成情報の履歴（リビジョン）を格納する。各レコードは履歴ＩＤ１４１、構成変更のあった時点のタイムスタンプ１４２、構成情報ＩＤ１４７、変更前リビジョン１４３、変更後リビジョン１４４、作業手順８３０へのリンク１４５、関連コンポーネントＩＤリスト１４６、の各フィールドから構成される。
【００８７】
履歴ＩＤ１４１は、構成情報管理部２１０が設定する値で、一意の識別子が付与される。作業手順１４５は構成情報変更時にどのような変更があったのかをモニタ端末３５０へ出力して管理者やユーザが見てわかりやすくするためのテキスト列またはテキスト列へのポインタで、構成情報の差分から自動的に生成する方法や、構成管理マネージャ３６０での構成変更指示時に管理者にコメントとして入力させる方法などが考えられる。関連コンポーネントＩＤリスト１４６は、該当する構成変更の影響を受けるコンポーネントＩＤのリストである。
【００８８】
図６はコンポーネント履歴管理テーブル１５０の構成例である。コンポーネント履歴管理テーブル１５０は、モニタリングシステム１００の履歴情報管理部２１０が管理するテーブルで、構成変更の影響を受けたコンポーネントＩＤ１５１に関してのみレコードが登録される。
【００８９】
各レコードはコンポーネントＩＤ１５１、新たな構成の開始日時１５２、当該構成の終了日時１５３、構成情報ＩＤ１５５、リビジョン１５４の各フィールドから構成される。終了日時１５３の値が”−”あるいはＮＵＬＬであるレコードは、そのリビジョンが最新であることを示す。
【００９０】
図６の例では、コンポーネントＩＤ１５１が「３」であるコンポーネントはリビジョン１５４が「１」から「２」に変更された時の影響は受けたが、リビジョン１５４が「２」から「３」へ変更されたときには構成変更の影響は受けていないため、リビジョン１５４＝２が最新である。一方、コンポーネントＩＤ１５１が「９」であるコンポーネントは２回の構成変更の影響を共に受けているため、リビジョン１５４＝３が最新となっている。
【００９１】
＜構成情報ＸＭＬのツリー表現＞
図７は構成情報管理テーブル１３０の構成情報１３４に格納される構成情報ＸＭＬ５００ａのツリー表現の一部を抜粋した図である。図７の例は、図４に示したリビジョン１３１＝１の構成情報１３４をツリー（部分木）にて表現した例である。
【００９２】
構成情報は、プラットフォームツリー６００とサービス提供ツリー６１０の二種類のデータ構造に分割される。
【００９３】
プラットフォームツリー６００は、物理リソースを主体としたシステム構成や仮想リソースを主体とした構成のように、ある一種類の“プラットフォーム”という界面で閉じた空間に存在するシステム要素の接続関係を表したデータである。換言すれば、プラットフォームツリー６００は、計算機リソースのカテゴリー（プラットフォーム）毎に、構成要素の接続関係を解析した木構造のデータである。
【００９４】
一方、サービス提供ツリー６１０は、ある一つの計算機リソースを仮想的（または論理的に）に１個以上の要素に分割した接続関係を表すデータである。換言すれば、サービス提供ツリー６１０は、監視対象リソース４００を利用するクライアント計算機（図示省略）が識別可能な仮想リソースを子ノードに持ち、当該子ノードとプラットフォームツリー６００の親ノードの関係を示す木構造のデータである。
【００９５】
そして、プラットフォームツリー６００の要素と、サービス提供ツリー６１０の親ノードの接続関係は、相互参照４９０（図中破線）で示される。相互参照４９０は、基準構成テーブル３８３で定義された親属性（図３６中でｐａｒｅｎｔと記載）要素と子属性（図３６中でｃｈｉｌｄと記載）要素の接続関係を示すデータであり、図３７のｘｐａｔｈ生成テーブル３８３のプラットフォームツリーｘｐａｔｈ３９６とサービス提供ツリーｘｐａｔｈ３９７のデータで表現される。なお、親属性は上位要素となり、子属性は下位要素となる。
【００９６】
なお、ネットワーク４３０を介して仮想サーバ４２２を利用するクライアント計算機が存在する場合、クライアント計算機がアクセスする仮想サーバ４２２、ＯＳ４２３、ＬＵ４６５等の仮想リソース４２０がサービス提供ツリー６１０に含まれる。換言すれば、仮想サーバ４２２のユーザが利用するクライアント計算機から識別可能な計算機リソースをサービス提供ツリー６１０として扱うことができる。
【００９７】
監視対象リソース４００の全体構成は、プラットフォームツリー６００とサービス提供ツリー６１０を相互参照４９０のポインタ（または参照情報）で接続することで表現する。このように、計算機リソース（ベースリソース４１０と仮想リソース４２０）の構成要素を主旨の異なる別々のツリー構造にする理由を、図２４を用いて示す。
【００９８】
図２４は、仮想化を適用した計算機システム（監視対象リソース４００）の構成図をノード（頂点）とエッジ（辺）を用いて表現した例の説明図である。図２４のように、仮想化された計算機システムをグラフで表現すると、木構造にはなっておらずＸＭＬ形式で構成を管理することは困難である。例えば、仮想サーバα、βに接続しているディスクパーティション（図２４のＬＵ０、ＬＵ１）が、論理的には分離していても物理的には同一のＲＡＩＤ上（図２４のＲＧ０）上に構成されている。このため、木構造で計算機システムを表現すると、図２４のＬＵ０，ＬＵ１のように、どの仮想リソースが同じ物理リソース上に展開されているか判断がつかなくなる。つまり、図２４において、ストレージ装置のＲａｉｄＧｒｏｕｐ０には、ＬＵ０とＬＵ１が存在するが、ＬＵ０にアクセスする仮想ＨＢＡ（ｖＨＢＡ００）は、物理的なＩ／ＯデバイスであるＨＢＡ０に接続されたパスと、仮想サーバαに接続される２つのパスが存在する。このため、木構造のデータとして表現することが難しい。
【００９９】
このような仮想計算機システムで、ある仮想サーバに接続したＬＵに対して過大な負荷、例えば、データベースで全件検索をかけるようなケースでは、同一のＲＧ上に展開した他のＬＵを使っている別の仮想サーバの性能が何の前触れもなく性能がスローダウンしてしまうケースも起こりうる。このような事態の原因分析を迅速に行うためには、物理リソースを含むベースリソース４１０と仮想リソース４２０の関係を正確に把握できることが必要であり、一つのベースリソース４１０を１個以上の仮想リソース４２０として分割して使用している部分を切り出して管理することで原因分析の効率が向上する。一方、実際の仮想サーバのシステム構築のケースにおいては、物理リソースを論理的に分割する操作は必ず一つの作業として定義される。例えば、ハイパーバイザを操作して仮想マシンを構築する操作が挙げられる。このような仮想化の作業を別に切り出すことができるという事実から、構成情報を表すデータ構造上でも仮想化をしている部分を別に切り出して管理することは、実作業とのマッチングが図りやすくモニタリングツールを使った管理作業のイメージが管理者につかみやすいという利点もある。
【０１００】
図２３は、図７から木構造のデータだけを抽出した監視対象リソース４００の構成要素を表している。プラットフォームツリー６００は、サーバラック５１０をルートノードにして物理サーバをプラットフォームとして表すツリーと、仮想サーバをプラットフォームとして表すツリーと、ストレージ装置をプラットフォームとして表すツリーが別々に定義されている。
【０１０１】
プラットフォームツリー６００で親ノードと子ノードになる構成要素の定義は、構成管理マネージャ３６０の基準構成テーブル３８３で定義される。基準構成テーブル３８３は、図３６で示すように、管理者などがモニタ端末３５０で設定した監視対象リソース４００の親子関係を示す定義情報で構成される。
【０１０２】
図３６において、基準構成テーブル３８３は、要素名３９０と、プラットフォームツリー構成要素ＸＭＬ３９１と、サービス提供ツリー構成要素ＸＭＬ３９２からひとつのレコードが構成される。
【０１０３】
要素名３９０には、監視対象リソース４００の構成要素の名称（または識別子）が格納される。プラットフォームツリー構成要素ＸＭＬ３９１には、子ノードとなる構成要素が＜ｃｈｉｌｄ＞に設定され、サービス提供ツリー６１０で親ノードとなる構成要素の場合では＜ｐａｒｅｎｔ＞に当該要素名の構成要素が設定される。サービス提供ツリー構成要素ＸＭＬ３９２には、親ノードとなる構成要素が＜ｐａｒｅｎｔ＞に設定され、子ノードとなる構成要素が＜ｃｈｉｌｄ＞に設定される。
【０１０４】
例えば、図３６において、要素名３９０＝「サーバラック」は、プラットフォームツリー構成要素ＸＭＬ３９１に、「ＳｅｖｅｒＣｈａｓｓｉｓ」が＜ｃｈｉｌｄ＞に設定されて、子ノードがサーバシャーシ５２０であることを示す。そして、プラットフォームツリー構成要素ＸＭＬ３９１の＜ｐａｒｅｎｔ＞には空（ｎｕｌｌ）が設定されて、親ノードが存在しないルートノードであることを示す。また、要素名３９０＝「サーバラック」は、サービス提供ツリー構成要素ＸＭＬ３９２の各構成要素の全てが空（ｎｕｌｌ）であるため、サービス提供ツリー６１０には存在しないことを示す。
【０１０５】
一方、要素名３９０＝「ハイパーバイザ」は、プラットフォームツリー構成要素ＸＭＬ３９１の＜ｐａｒｅｎｔ＞に「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」が設定され、＜ｃｈｉｌｄ＞には＜ｘｐａｔｈ＞として「ＶｉｒｔｕａｌＳｅｒｖｅｒ」が設定される。これにより、プラットフォームツリー６００では、ハイパーバイザの親ノードが物理サーバで、子ノードが仮想サーバであることを示す。また、要素名３９０＝「ハイパーバイザ」のサービス提供ツリー構成要素３９２は、＜ｃｈｉｌｄ＞に＜ｘｐａｔｈ＞として「ＶｉｒｔｕａｌＳｅｒｖｅｒ」が設定される。これにより、サービス提供ツリー６１０では、ハイパーバイザが親ノードで、子ノードが仮想サーバであることを示す。
【０１０６】
そして、プラットフォームツリー構成要素ＸＭＬ３９１とサービス提供ツリー構成要素ＸＭＬ３９２の＜ｘｐａｔｈ＞で定義された「ｖａｌｕｅ」が、相互参照４９０を構成してプラットフォームツリー６００のノードと、サービス提供ツリー６１０の親ノードの接続関係を定義する。
【０１０７】
図７に示すプラットフォームツリー６００は、図３６の基準構成テーブル３８３で、サーバラック５１０，仮想サーバ４２２、ストレージ装置４５０をルートノードとして定義した例を示し、サービス提供ツリー６１０の親ノードとしてサーバ仮想化部４２１０，ＨＢＡ４１５０、ＲＧ４８５０を設定したものである。そして、サービス提供ツリー６１０の各親ノードとプラットフォームツリー６００の子ノードの接続関係は＜ｘｐａｔｈ＞によって定義される。
【０１０８】
また、モニタリングシステム１００は、後述の基準構成テーブル３８１（図３６）を参照して、モニタ端末３５０の入力装置から指定された構成情報について、基準構成テーブル３８３の定義に基づいて親ノードを抽出してサービス提供ツリー６１０を生成する。親ノードの抽出は、基準構成テーブル３８１の各要素で、ｐａｒｅｎｔ属性の要素がｎｕｌｌ（＜ｐａｒｅｎｔ＞＜／ｐａｒｅｎｔ＞と図３６では記載）になっていれば親ノードであることが抽出できる。
【０１０９】
なお、プラットフォームツリー６００とサービス提供ツリー６１０は、図３２Ａ、図３２Ｂに示すＸＭＬ情報としてモニタリングシステム１００の構成情報管理テーブル１３０に格納される。
【０１１０】
仮想化環境のプラットフォームとしての物理サーバを表すツリーは、サーバラック５１０を親ノード（頂点）とし、その下位にサーバラック５１０に格納されるサーバシャーシ５２０と、その下位にサーバシャーシ５２０に格納される物理サーバ４１１、さらにその下位には、物理サーバ４１１に接続されたＨＢＡ４１５と、物理サーバ４１１で実行されるサーバ仮想化部（ハイパーバイザ）４１２の階層関係を示す。また、物理サーバ４１１の下位には、物理サーバ４１１の統計情報５６０Ａ、５６０Ｂが関係づけられている。さらに、サーバ仮想化部４２１の下位にはハイパーバイザの統計情報５７０が関連付けられている。なお、サーバラック５１０、サーバシャーシ５２０と物理サーバ４１１の関係等のモニタリングシステム１００が識別できない構成については、管理者などがモニタ端末３５０から設定する。
【０１１１】
仮想サーバのプラットフォームを表すツリーは、仮想サーバ４２２を親ノードとし、その下位に仮想ＨＢＡ（ｖＨＢＡ）４６０、その下位にＬＵ４６５、その下位にパーティション４７０の接続関係を示している。仮想サーバ４２２には、仮想サーバ４２２のＣＰＵ使用率やメモリ使用量といった統計情報５５０が関連付けされている。さらに、パーティション４７０には、ディスク（ＬＵ）のスループットやアクセス要求の待ち行列長、ディスクのビジー率といった統計情報５８０が関連付けされている。
【０１１２】
ストレージ装置４５０のプラットフォームを表すツリーは、ストレージ装置４５０を親ノードとし、その下位にコントローラ４８０、その下位にＲＧ（ＲＡＩＤ Ｇｒｏｕｐ）４８５が存在する接続関係を示している。
【０１１３】
サービス提供ツリー６１０には、基準構成テーブル３８３の各要素で定義された親子関係（ｐａｒｅｎｔ属性とｃｈｉｌｄ属性の関係）から、構成要素のツリーが生成される。例えば、図３６のサービス提供ツリー構成要素ＸＭＬ３９２においては、要素名３９０の“ハイパーバイザ“の行にある要素（ＸＭＬ記述）がサーバ仮想化部（ハイパーバイザ）４２１０を親ノードとして表し、そのハイパーバイザの下には要素名３９０が”仮想サーバ“の行にある要素（ＸＭＬ記述）が仮想サーバ４２２０をして表現されている。また、それぞれのノードの接続関係は、各要素ＸＭＬのｐａｒｅｎｔ属性やｃｈｉｌｄ属性で表現されている。後述する図２５のように、サービス提供ツリー６１０の各要素（ツリーを構成する各ノード）にも、プラットフォームツリー６００で存在した統計情報が関連付けられている。
【０１１４】
プラットフォームツリー６００とサービス提供ツリー６１０は、図７に示すような相互参照４９０（図７の凡例）で関連するノードが相互に接続されている。データ構造上は、図３２Ａ、図３２Ｂ、図３３、図３６に示すｘｐａｔｈで関連付けをしている。なお、相互参照４９０には、図３６で示す＜ｘｐａｔｈＩＤ＞が付与され、この識別子により相互参照４９０の特定を行うことができる。
【０１１５】
図７において、プラットフォームツリー６００の子ノードであるサーバ仮想化部４２１が、サービス提供ツリー６１０の子ノードである仮想サーバ４２２０に参照される。そして、サービス提供ツリー６１０の子ノードである仮想サーバ４２２０が、プラットフォームツリー６００の仮想サーバ４２２に参照される。また、プラットフォームツリー６００の仮想ＨＢＡ４６５は、サービス提供ツリー６１０の子ノードである仮想ＨＢＡ（ｖＨＢＡ）４６５０を参照し、ｖＨＢＡ４６５０の親ノードであるＨＢＡ４１５０がプラットフォームツリー６００のＨＢＡ４１５を参照する。また、プラットフォームツリー６００の子ノードであるＲＧ４８５は、サービス提供ツリー６１０の親ノードであるＲＧ４８５０に参照され、子ノードであるＬＵ４６５０は、プラットフォームツリー６００のＬＵ４６５を参照する。
【０１１６】
このように、本発明のプラットフォームツリー６００とサービス提供ツリー６１０により、仮想サーバ４２２と、仮想サーバ４２２が利用するベースリソースの関係を漏れなく、かつ少ない手数で管理することが可能となる。
５を参照する。
【０１１７】
＜構成情報の生成＞
次に、プラットフォームツリー６００とサービス提供ツリー６１０を提供する図３２Ａ〜図３３の構成情報ＸＭＬ５００ａの生成について以下に説明する。
【０１１８】
構成管理マネージャ３６０は、監視対象リソース４００の構成要素と基準構成テーブル３８３から構成情報５００を生成して、構成情報データベース３６５に格納する。そして、構成管理マネージャ３６０は構成情報５００をモニタリングシステム１００に通知する。モニタリングシステム１００では、構成情報５００にコンポーネントＩＤを付与した情報を構成情報ＸＭＬ５００ａとして構成情報管理テーブル１３０に格納する。構成情報ＸＭＬ５００ａは、図３２Ａ、図３２Ｂに示すプラットフォームツリー６００と、図３３に示すサービス提供ツリー６１０に分類される。
【０１１９】
図３８〜図４１は、構成管理マネージャ３６０で行われる構成情報５００の生成処理の一例を示すフローチャートである。
【０１２０】
構成管理マネージャ３６０は、モニタ端末３５０からの指示によって図３８のフローチャートを実行し、暫定構成ＸＭＬ３８５を生成し、プラットフォームツリー６００とサービス提供ツリー６１０のノードを設定する（ノード生成処理）。次に、構成管理マネージャ３６０は、図３９のフローチャートを実行して、暫定構成ＸＭＬ３８５から各ノードの木構造を生成する。次に、構成管理マネージャ３６０は、図４０のフローチャートを実行して、暫定構成ＸＭＬ３８５からプラットフォームツリー６００とサービス提供ツリー６１０の相互参照４９０を示すｘｐａｔｈを抽出し、図３７に示すｘｐａｔｈ生成テーブル３８４を生成する。最後に、構成管理マネージャ３６０は、図４１のフローチャートを実行して、暫定構成ＸＭＬ３８５とｘｐａｔｈ生成テーブル３８４から、暫定構成ＸＭＬ３８５にｘｐａｔｈを組み込んで、構成情報５００を生成し、構成情報２４５としてモニタリングシステム１００に送る。この構成情報５００は構成情報管理テーブル１３０に格納される。また、構成情報５００は、構成情報データベース３６５に登録してもよい。
【０１２１】
まず、図３８のノード生成処理について説明する。構成管理マネージャ３６０は、モニタ端末３５０から構成取得要求３７２を受信する（ステップ３９０１）。構成管理マネージャ３６０では、構成取得要求３７２を構成取得要求生成部３７１で監視対象リソース４００の構成取得コマンド３７４に変換し、監視対象リソース４００へ構成要素の取得を指令する（ステップ３９０２）。
【０１２２】
構成管理マネージャ３６０は、監視対象リソース４００から取得構成情報３７５を受信すると、構成取得要求生成部３７１で取得構成情報３７５を受け付け、構成変更要求生成部３６４に送り、構成情報ＤＢ３６５に格納する（ステップ３９０３）。構成取得要求生成部３７１は、受信した取得構成情報３７５を解析して監視対象リソース４００の構成要素を抽出する（ステップ３９０４）。なお、抽出された構成要素はＸＭＬで記述され、構成要素の名称が設定されているものとする。この構成要素の名称は監視対象リソース４００側で付与してもよいし、構成取得要求生成部３７１が構成要素を解析するときに付与してもよい。
【０１２３】
構成管理マネージャ３６０は、ステップ３９０４で抽出した全ての構成要素についてステップ３９０５からステップ３９０８の処理を行い、親ノードを暫定構成ＸＭＬ３８５に格納し、親ノードに相互参照４９０を示すｘｐａｔｈＩＤを設定する。
【０１２４】
まず、ステップ３９０６では、ツリー変換設定３８１は、抽出された構成要素のうちの一つを選択して、基準構成テーブル３８３を検索し、図３６の要素名３９０が一致したプラットフォームツリー構成要素ＸＭＬ３９１またはサービス提供ツリー構成要素ＸＭＬ３９２を取得する。この検索は、選択した構成要素のＸＭＬに含まれる構成要素の名称が基準構成テーブル３８３の要素名に一致すれば、プラットフォームツリー構成要素ＸＭＬ３９１またはサービス提供ツリー構成要素ＸＭＬ３９２を取得する。
【０１２５】
次に、ステップ３９０７では、ツリー変換設定３８１は、取得したプラットフォームツリー構成要素ＸＭＬ３９１またはサービス提供ツリー構成要素ＸＭＬ３９２があれば暫定構成ＸＭＬ３８５に格納する。このとき、基準構成テーブル３８３のプラットフォームツリー構成要素ＸＭＬ３９１とサービス提供ツリー構成要素ＸＭＬ３９２の間に相互参照４９０の関係があれば、図３６の「ハイパーバイザ」のＸＭＬの記述のように＜ｘｐａｔｈＩＤ＞が含まれる。
【０１２６】
そして、ステップ３９０８では、ツリー変換設定３８１は、暫定構成ＸＭＬ３８５に格納したプラットフォームツリー構成要素ＸＭＬ３９１またはサービス提供ツリー構成要素ＸＭＬ３９２内に＜ｘｐａｔｈＩＤ＞の記述があるか否かを判定し、＜ｘｐａｔｈＩＤ＞の記述があり、かつｖａｌｕｅの値がｎｕｌｌであれば構成情報５００内（または監視対象リソース４００内）で一意のｘｐａｔｈＩＤの値をｖａｌｕｅに設定し、ｘｐａｔｈ生成テーブル３８４に登録する。
【０１２７】
ここで、ｘｐａｔｈ生成テーブル３８４は、図３７で示すように、ｘｐａｔｈＩＤ３８５と、プラットフォームツリーｘｐａｔｈ３９６とサービス提供ツリーｘｐａｔｈ３９７からひとつのエントリが構成される。
【０１２８】
上記処理を全ての構成要素について実行することで、構成管理マネージャ３６０のツリー変換設定３８１は暫定構成ＸＭＬ３８５に、プラットフォームツリー構成要素ＸＭＬ３９１の親ノード及びサービス提供ツリー６１０の親ノードを格納し、相互参照４９０を示すｘｐａｔｈＩＤがあればユニークな識別子を付与する。
【０１２９】
次に、構成管理マネージャ３６０は、図３９のフローチャートを実行して、図３８の処理で求めた暫定構成ＸＭＬ３８５に格納された親ノードの配下の木構造を設定する。ステップ４００１では、構成取得要求生成部３７１が暫定構成ＸＭＬ３８５に格納された全ての構成要素ＸＭＬ３９１、３９２を抽出する。暫定構成ＸＭＬ３８５には、親ノード（ｐａｒｅｎｔ）の内容がブランク（空）の構成要素ＸＭＬが格納されている。抽出された構成要素ＸＭＬは親ノードの構成要素ＸＭＬ３９１、３９２であり、以下、親ノードの構成要素ＸＭＬとする。
【０１３０】
次に、構成管理マネージャ３６０のツリー変換設定３８１は、図３８のステップ３９０４で抽出された全ての構成要素のうちｐａｒｅｎｔがブランク以外の子ノードの全てについて、ステップ４００２、４００３の処理を実行する。
【０１３１】
ステップ４００３では、ツリー変換設定３８１が、ｐａｒｅｎｔがブランク以外の子ノードの構成要素ＸＭＬをひとつ取得する。そして、取得した子ノードの構成要素ＸＭＬが、ステップ４００１で抽出した親ノードの構成要素ＸＭＬのいずれの配下に属するかを決定する。この決定は、子ノードの構成要素ＸＭＬのｐａｒｅｎｔの要素名が、親ノードの構成要素ＸＭＬの要素名に一致すれば、当該親ノードを現在着目している子ノードの親とする。
【０１３２】
そして、ツリー変換設定３８１は、暫定構成ＸＭＬ３８５のうち、上記決定した親ノードの構成要素ＸＭＬの配下に、子ノードの構成要素ＸＭＬを組み込む。
【０１３３】
上記処理を全ての子ノードについて実行することで、ステップ３９０４で抽出された構成要素は、暫定構成ＸＭＬ３８５内で親ノードの配下に子ノードが組み込まれて、プラットフォームツリー構成要素ＸＭＬ３９１とサービス提供ツリー６１０が構築される。
【０１３４】
暫定構成ＸＭＬ３８５の例を図４２に示す。基準構成テーブル３８３の要素が階層的に配置され、各要素に固有な名称（図４２の＜ＳｅｒｖｅｒＲａｃｋＮａｍｅ＞や＜ＳｅｒｖｅｒＣｈａｓｓｉｓＮａｍｅ＞や＜ＳｅｒｖｅｒＮａｍｅ＞や＜ＨｙｐｅｒｖｉｓｏｒＮａｍｅ＞や＜ＨＢＡＮａｍｅ＞で定義されている名称）とｘｐａｔｈＩＤが設定されている。
【０１３５】
次に、ツリー変換設定３８１は、図４０のフローチャートを実行してｘｐａｔｈ生成テーブル３８４を更新する。図３８、図３９の処理では、暫定構成ＸＭＬ３８５の親ノード同士のｘｐａｔｈは設定されているが、プラットフォームツリー６００の子ノードとサービス提供ツリー６１０の親ノードのｘｐａｔｈが設定されていない。そこで、図４０のフローチャートでは、プラットフォームツリー６００の子ノードとサービス提供ツリー６１０の親ノードのｘｐａｔｈを設定する。
【０１３６】
ツリー変換設定３８１は、図４０のステップ４１０１〜４１０３の処理をｘｐａｔｈ生成テーブル３８４の全ての要素について実行する。
【０１３７】
ステップ４１０１では、暫定構成ＸＭＬ３８４を検索し、全親ノードを見つける。その親ノード全てについて、ステップ４１０２とステップステップ４１０３を実施する。
【０１３８】
ステップ４１０２では、ツリー変換設定３８１が暫定構成ＸＭＬ３８５を検索して、＜ｘｐａｔｈＩＤ＞を検出する。検索は、深さ優先でも幅優先でもかまわない。
【０１３９】
ステップ４１０３では、ツリー変換設定３８１が上記ステップ４１０２で検出するまでに暫定構成ＸＭＬ３８５をたどったパスをｘｐａｔｈとして、ｘｐａｔｈ生成テーブル３８４のプラットフォームツリーｘｐａｔｈ３９６またはサービス提供ツリーｘｐａｔｈ３９７に登録する。なお、プラットフォームツリーとサービス提供ツリーの判定は、ｘｐａｔｈＩＤを検出した構成要素ＸＭＬには、図３６の基準構成テーブル３８３に格納された＜ｐｌａｔｆｏｒｍ＞または＜ｓａｅｒｖｉｃｅ＞の何れかの識別子を取得することでツリー変換設定３８１が判定することができる。また、ｘｐａｔｈ生成テーブル３８４のｘｐａｔｈＩＤ３９５は、ステップ４１０２で検出したｘｐａｔｈＩＤを引き継げばよい。
【０１４０】
次に、ツリー変換設定３８１は、図４１のフローチャートを実行してｘｐａｔｈ生成テーブル３８４に登録されたｘｐａｔｈを暫定構成ＸＭＬ３８５に組み込んで、構成情報５００を生成する。
【０１４１】
ツリー変換設定３８１は、ステップ４２０１〜４２０３の処理をｘｐａｔｈ生成テーブル３８４の要素の全てについて実行する。
【０１４２】
ステップ４２０２では、ツリー変換設定３８１が、ｘｐａｔｈ生成テーブル３８４の一つのエントリを選択する。そして、選択したｘｐａｔｈ生成テーブル３８４のエントリのプラットフォームツリーｘｐｔｈ３９６のｘｐａｔｈを、暫定構成ＸＭＬ３８５でサービス提供ツリーの当該ｘｐａｔｈＩＤが設定されている部分と入れ替える。これにより、暫定構成ＸＭＬ３８５のサービス提供ツリーの当該ｘｐａｔｈＩＤには、プラットフォームツリーｘｐｔｈ３９６の記述（ＸＭＬ）が組み込まれる。
【０１４３】
次に、ステップ４２０３では、ツリー変換設定３８１が、現在選択しているｘｐａｔｈ生成テーブル３８４のエントリのサービス提供ツリーｘｐｔｈ３９７のｘｐａｔｈを、暫定構成ＸＭＬ３８５でプラットフォームツリーの当該ｘｐａｔｈＩＤが設定されている部分と入れ替える。これにより、暫定構成ＸＭＬ３８５のプラットフォームツリーの当該ｘｐａｔｈＩＤには、サービス提供ツリーｘｐｔｈ３９７の記述（ＸＭＬ）が組み込まれる。
【０１４４】
上記ステップ４２０２、４２０３の処理が全てのｘｐａｔｈ生成テーブル３８４のエントリについて終了すると、ステップ４２０４へ進む。ステップ４２０４では、ツリー変換設定３８１が、暫定構成ＸＭＬ３８５の内容を構成情報ＸＭＬ５００として構成情報データベース３６５に格納する。
【０１４５】
以上の処理により、図３２Ａ、図３２Ｂに示すプラットフォームツリー６００と、図３３に示すサービス提供ツリー６１０の構成情報ＸＭＬ５００ａが生成される。なお、図３２Ａ、図３２Ｂ、図３３の構成情報ＸＭＬ５００ａは、上述したようにモニタリングシステム１００が一意のコンポーネントＩＤを付与したものである。
【０１４６】
＜統計情報の関連付け＞
次に、統計情報と構成情報の関連付けについて説明する。
【０１４７】
仮想サーバ４２２の統計情報としては、例えばＯＳ４２３が取得したＣＰＵ使用率やメモリ使用量といった稼動情報に上述のような統計処理した情報が考えられる。すなわち、サーバ仮想化部４２１が仮想サーバ４２２へ提供する仮想ＣＰＵの使用率やメモリの使用量（または使用率）、あるいは仮想Ｉ／Ｏデバイス（ＨＢＡやＮＩＣ等を仮想化したＩ／Ｏデバイス）の使用率（転送量）等を仮想サーバ４２２の性能を示す稼動情報とし、所定の統計処理を行って統計情報とすることができる。
【０１４８】
一方、物理サーバ４１１の統計情報としては、サーバ仮想化部４２１自身のＣＰＵ使用率やメモリ４１３の使用量や、Ｉ／Ｏ（ＨＢＡやＮＩＣ）の使用率（転送量）等を仮想化部４２１の性能を示す稼動情報とし、所定の統計処理を行って統計情報とすることが考えられる。
【０１４９】
そして、本実施形態では、モニタリングシステム１００が、構成情報ＸＭＬ５００ａの各ノードに一意なコンポーネントＩＤ（図中ＣＩＤ）を割り当て、このコンポーネントＩＤに各統計情報に設定した統計値ＩＤを関連付けることで、構成情報の変更の前後での構成の履歴や統計情報の追跡を容易にする。なお、構成情報におけるノードとしては、物理サーバ４１１や仮想サーバ４２２に付与したコンポーネントＩＤをノードとして扱うことができる。同様に統計値ＩＤもノードとして扱うようにしても良い。
【０１５０】
また、コンポーネントＩＤと統計値ＩＤとを区別する必要は必ずしもなく、お互いに重複しない値をつけて管理する方法もある。以下の例では、各テーブルのフィールド数を省略するためにコンポーネントＩＤと統計値ＩＤを同一フィールドで示しているが、両者を区別するようなフィールドを追加して管理する方法もある。どちらの場合も本発明の適用に当たっては本質的な差異を生じない。
【０１５１】
図９は図７に示した構成情報ＸＭＬ５００ａから仮想サーバαを物理サーバＢへ移動させた後の構成情報ＸＭＬ５００ｂのツリー表現の一部を抜粋した図である。この構成情報ＸＭＬ５００ｂは、図４に示したリビジョン１３１＝２の構成情報１３４をツリーにて表現した例である。リビジョン１３１＝１から２の移動の前後で、移動した仮想サーバαに関連するコンポーネントＩＤおよび統計値ＩＤは同一であることが保証される。これにより、構成変更による移動の前後で稼動に関する統計情報を連続的に追跡できるようになる。
【０１５２】
すなわち、図７に示すように、コンポーネントＩＤ＝３の物理サーバＡに割り当てられたコンポーネントＩＤ＝９の仮想サーバを、物理サーバＢへ移動したときには、物理サーバＡに関連付けられた仮想サーバαのコンポーネントＩＤ＝３と、当該仮想サーバの配下の仮想リソースの識別子（統計値ＩＤ）を図９で示すように削除し、移動する仮想サーバαのコンポーネントＩＤ＝９及び当該仮想サーバαの配下の仮想リソースの識別子（統計値ＩＤ）と同一のコンポーネントＩＤと統計値ＩＤを移動先のコンポーネントＩＤ＝４の物理サーバＢに割り当てる。
【０１５３】
＜割当済ＩＤ管理テーブル＞
図１１は構成情報関連管理部２３０が管理するコンポーネントＩＤの状態遷移図である。コンポーネントＩＤは、ベースリソース４１０や仮想リソース４２０の構成要素に構成情報関連管理部２３０が割り当てたモニタリングシステム１００内で一意の識別子である。これらのコンポーネントＩＤと統計値ＩＤは、構成情報関連管理部２３０が管理する割当済ＩＤ管理テーブル１６０（図１２、図１３）のコンポーネント／統計値ＩＤ１６１に格納される。
【０１５４】
構成情報関連管理部２３０がベースリソース４１０や仮想リソース４２０の構成要素にコンポーネントＩＤを割り当てると、コンポーネントＩＤの状態を管理するために割当済ＩＤ管理テーブル１６０へと登録する。
【０１５５】
コンポーネントＩＤは、まだ割り当てていない状態未割当１７０（テーブルに未登録のＩＤを含む）から、割り当てられると使用中１７１へと遷移する。また、待機用のコンポーネントなどのためにＩＤを予約した場合は予約済あるいは待機中１７２へと遷移する。使用中１７１と待機中１７２の間は、障害や移動などによる交替があった場合、お互いの間を遷移することがある。コンポーネントの削除や廃棄が行われた場合、そのＩＤは別の目的で再利用されないように回収済１７３へと遷移する。新たなＩＤの値の生成方法としては、たとえば単調増加な自然数を使用する方法が考えられる。
【０１５６】
図１２、図１３は図７の構成情報ＸＭＬ５００ａの構成要素に付与される割当済ＩＤ管理テーブル１６０の構成例である。各レコードはコンポーネントＩＤまたは統計値ＩＤ１６１、構成情報ＩＤ１６２、リビジョン１６３、ＸＭＬパス表現１６４、親コンポーネントＩＤ（図中親ＩＤ）１６５、コンポーネントＩＤの状態１６６といったフィールドから構成される。これらの値は、モニタリングシステム１００が付与するものである。
【０１５７】
ここでＸＭＬパス表現１６４は、ＸＭＬツリーにおける各ノードを特定するために必要な情報を含む。図１２、図１３の例ではサーバラック５１０のＩＤと、サーバシャーシ５２０のＩＤと、物理サーバ４１１のＩＤと、仮想サーバ４２２のＩＤを順に指定する方法を示したが、この他にも物理サーバ４１１や仮想サーバ４２２にユーザがつけたサーバ名を指定する方法や、稼動するゲストＯＳのＵＵＩＤを指定する方法などが考えられる。いずれの方法でもノード（各コンポーネント）が一意に特定できさえすれば本発明の適用に当たっては差異を生じない。
【０１５８】
また、親コンポーネントＩＤ（図中親ＩＤ）１６５が「−」の構成要素は、プラットフォームツリー６００おいて親ノードとなることを示している。
【０１５９】
＜構成情報ＸＭＬのＸＭＬ表現＞
図３２Ａ、図３２Ｂ、図３３は図７に示した物理サーバ＝「Ａ」の仮想サーバαを物理サーバ「Ｂ」へ移動する前の構成情報ＸＭＬ５００ａのＸＭＬによる階層構造の表現である。
【０１６０】
図３２Ａ、図３２Ｂでは、サーバラック５１０を示すＳｅｒｖｅｒＲａｃｋノードと、サーバシャーシ５２０を示すＳｅｒｖｅｒＣｈａｓｓｉｓノードと、物理サーバ５３０を示すＰｈｙｓｉｃａｌＳｅｒｖｅｒノードと、サーバ仮想化部４２１を表すＨｙｐｅｒｖｉｓｏｒノードとＨＢＡ４１５を表すＨＢＡノードとが階層的にツリー構造をしている。
【０１６１】
また、仮想サーバ５４０を示すＶｉｒｔｕａｌＳｅｒｖｅｒノードと、ｖＨＢＡ４６０を表すｖＨＢＡノード、ＬＵ４６５を表すＬＵノード、パーティション４７０を表すＰａｒｔｉｔｉｏｎノードとが、図７に示したプラットフォームツリー６００と同じく階層的にツリー構造をなしている。
【０１６２】
各ノードには、各ノードの属性としてコンポーネントＩＤを示すｃｏｍｐｏｎｅｎｔ＿ｉｄを持つ。またＶｉｒｔｕａｌＳｅｒｖｅｒノードの下にはサーバ名を示すＳｅｒｖｅｒＮａｍｅ、ＣＰＵ使用率を示すＣＰＵＵｓａｇｅ、メモリ使用量を示すＭｅｍｏｒｙＵｓａｇｅの各ノードがあり、ＣＰＵＵｓａｇｅおよびＭｅｍｏｒｙＵｓａｇｅノードは統計値ＩＤを示すｓｔａｔｉｓｔｉｃｓ＿ｉｄ属性を持つ。なお、コンポーネントＩＤと統計値ＩＤを特に区別せずに管理する場合はｓｔａｔｉｓｔｉｃｓ＿ｉｄ属性の代わりにｃｏｍｐｏｎｅｎｔ＿ｉｄ属性を持たせる実装も考えられる。どちらの場合も本質的な差異は生じない。
【０１６３】
一方、図３３では、図７に示したサービス提供ツリー６１０の階層構造が、上記のプラットフォームツリー６００と同様にして、ＸＭＬにより記述されている。図３３の構成情報５００ａは、図３６に示した基準構成テーブル３８１で定義された各要素３９０で定義されている親子関係の属性（ｐａｔｒｅｎｔとｃｈｉｌｄ）をツリー上の階層構造で単一のＸＭＬで記述したものである。
【０１６４】
そして、図３２Ａ、図３２Ｂでは図７に示したプラットフォームツリー６００の各ノードと図３３のサービス提供ツリー６１０の各ノードとの間の相互参照４９０として、上述のｘｐａｔｈが設定されている。
【０１６５】
図３４Ａ、図３４Ｂ、図３５、図３５Ｂは図９に示した物理サーバ＝「Ａ」の仮想サーバαを物理サーバ「Ｂ」へ移動する際の構成情報ＸＭＬ５００ａと構成情報ＸＭＬ５００ｂを生成する場合のＸＭＬ表現での変更手順を示した図である。
【０１６６】
図３４Ａ〜図３５Ｂでは、構成情報ＸＭＬ５００ａにおける仮想サーバα配下のノードを、構成情報ＸＭＬ５００ｂでは物理サーバＡの配下から物理サーバＢの配下へと移動させる。この処理において、仮想サーバαを含む配下のコンポーネントＩＤおよび統計値ＩＤは同一のＩＤを引き継ぐことで、移動前後における稼動の統計情報や変更履歴の追跡を可能とする。また、移動する仮想サーバαを含むプラットフォームツリーの記述はｘｐａｔｈだけの変更だけでよく、サービス提供ツリー６１０で新たに仮想サーバを追加するだけでサーバの移行に対して対処可能である。
【０１６７】
＜稼動統計情報表示＞
図１４は稼動に関する統計情報をモニタ端末３５０へ表示する時にモニタリングシステム１００の統計情報管理部１９０で行われる処理のフローチャートを示す。この処理は、統計情報ＧＵＩ制御部２５０がモニタ端末３５０から統計情報の要求を受け付けたときに実行される。この要求は、統計情報の表示期間の開始日時を変数ｂに格納し、終了日時を変数ｅに、コンポーネントの構成情報ＩＤを変数ｄに、コンポーネントＩＤを変数ｃに格納する。
【０１６８】
まずステップ１３００で、統計情報管理部１９０は統計情報ＧＵＩ制御部２５０から統計情報表示期間の開始日時ｂと終了日時ｅを得る。ステップ１３１０へ進む。
【０１６９】
ステップ１３１０では、構成情報管理部２００が構成情報ＧＵＩ制御部２６０から、指定されたコンポーネントの構成情報ＩＤ１３５＝ｄとコンポーネントＩＤ＝ｃを得る。ステップ１３２０へ進む。
【０１７０】
ステップ１３２０では、履歴情報管理部２１０が、統計情報管理部１９０および構成情報管理部２００から得た変数ｂ、ｅ、ｄ、ｃを元に、コンポーネント履歴管理テーブル１５０から＜ｄ、ｃ＞をキーとして、開始日時１５２＜ｅかつ終了日時１５３≧ｂとなるリビジョン１５４のリスト（Ｒ１、Ｒ２、．．．、Ｒｎ）を得る。ここで各リビジョンの開始日時１５２を（ｂ１、ｂ２、．．．、ｂｎ）、終了日時１５３を（ｅ１、ｅ２、．．．、ｅｎ）とする。ｅｉ（ただし、ｉ＝１〜ｎ）は最新リビジョンの場合ＮＵＬＬの場合もある。ステップ１３３０へ進む。
【０１７１】
次に得られた各リビジョンＲｉ（ただし、ｉ＝１〜ｎ）について、ステップ１３４０〜１３９０までを繰り返す。
【０１７２】
ステップ１３４０では、構成情報管理テーブル１３０から、構成情報ＩＤ１３５＝ｄ、リビジョン１３１＝Ｒｉであるレコードを選び、構成情報管理テーブル１３０の構成情報１３４から構成情報ＸＭＬ５００（５００ａ〜５００ｃ）を取得する。ステップ１３５０へ進む。なお、以下の説明では構成情報ＸＭＬ５００ａ〜５００ｃの総称を構成情報ＸＭＬとする。
【０１７３】
ステップ１３５０では、取得した構成情報ＸＭＬ５００についてコンポーネントＩＤが変数ｃの配下の統計値ＩＤのリスト（ｓ１、 ｓ２、 ．．． ｓｍ）を得る。ただし、統計値ＩＤのリストはｓｊで表され、ｊ＝１〜ｍである。ステップ１３６０へ進む。
【０１７４】
次に得られた各ｓｊに対してステップ１３７０〜１３８０を繰り返す。
【０１７５】
ステップ１３７０では、稼動統計テーブル１２０から統計値ＩＤ１２１＝ｓｊをキーにして、ｂｉ≦タイムスタンプ１２２＜ｅｉとなるレコードのタイムスタンプ１２２と統計値１２３の組＜ｔ、ｖ＞のリストを得る。ステップ１３８０に進む。
【０１７６】
ステップ１３８０では、稼動情報ＧＵＩ制御部２５０に＜ｔ、ｖ＞のリストを送り、このリスト＜ｔ、ｖ＞とコンポーネントＩＤによりモニタ端末３５０の表示装置にグラフを出力する。
【０１７７】
以上が稼動に関する統計情報の表示時に統計情報管理部１９０で実行される処理のフローチャートである。
【０１７８】
上記処理により、統計情報管理部１９０は、同一のコンポーネントＩＤに関連づけられた統計値ＩＤ１２１について、マイグレーションなどの構成変更があった場合にも、構成変更の時点を跨いで連続的に統計情報を表示させることが可能となる。
【０１７９】
図１５は本発明を適用したモニタリングシステム１００のモニタ端末３５０に表示される稼動統計モニタ画面の一例である。
【０１８０】
稼動統計モニタ画面は、図中左側に表示期間を表示する部分７００とラックやシャーシといったプラットフォームツリー６００に従って構成管理を行う部分７１０を備える。また、図中右側には構成要素および稼動に関する統計情報を表示するエリアが設定され、図中上部から物理構成情報（ベースリソース４１０の構成要素）を表示する物理構成情報表示エリア７２０、仮想構成情報（仮想リソース４２０の構成要素）を表示仮想構成情報表示するエリア７３０、統計情報を表示する稼動統計情報表示エリア７４０から構成される。
【０１８１】
物理構成情報表示エリア７２０と仮想構成情報表示エリア７３０および稼動統計情報表示エリア７４０は連動しており、物理構成情報エリア７２０において指定されたコンポーネント（ここでは物理サーバＡ）についての仮想構成情報（仮想リソースの構成要素）の詳細が仮想構成情報表示エリア７３０に表示される。また、この場合、物理サーバＡに対応した稼働統計情報が７４０に表示される。
【０１８２】
ここで仮想構成情報表示エリア７３０の仮想サーバαをモニタ端末３５０の入力装置（例えば、マウスなどのポインティングデバイス）で指定した場合、仮想サーバαに関連する統計情報のみが抽出されて稼働統計情報表示エリア７４０に表示される。図示の例では、稼動統計情報表示エリア７４０の左側の領域に仮想サーバαのＣＰＵ使用率が時系列的なグラフで表示され、右側の領域には仮想サーバαのＩ／Ｏ使用率（リード、ライトの使用率など）が時系列的なグラフで表示される。
【０１８３】
なお、物理構成情報表示エリア７２０の物理サーバＡ〜Ｃの何れかをモニタ端末３５０の入力装置で指定した場合には、選択した物理サーバに関連する統計情報が抽出されて稼働統計情報表示エリア７４０に表示される。また、図１５では、物理構成情報表示エリア７２０にサーバ仮想化部４２１を省略した例を示したが、物理サーバ上にサーバ仮想化部が階層的に稼動している場合には、物理サーバとサーバ仮想化部を表示することができる。
【０１８４】
このように、着目するコンポーネントが物理コンポーネントか仮想コンポーネントかに応じて、稼働統計情報７４０に表示されるグラフの種類が変わる点が本モニタリングシステム１００の特徴の一つである。
【０１８５】
上記図１５の稼動統計モニタ画面は、モニタリングシステム１００の統計情報ＧＵＩ制御部２５０、構成情報ＧＵＩ制御部２６０、履歴情報ＧＵＩ制御部２７０により一つの画面情報が生成され、モニタリングシステム１００は当該画面情報をモニタ端末３５０へ出力する。そして、モニタ端末３５０では、受信した画面情報を表示装置に描画する。
【０１８６】
＜稼働情報収集部の動作＞
以下図１６〜図１９を用いて稼働情報集計部３００で行われる処理の詳細を示す。
【０１８７】
図１６は稼働情報集計部３００の構成を示したブロック図である。稼働情報集計部３００は稼働情報収集パラメータ３１０を保持し、稼働情報収集パラメータ３１０の内容はパラメータ設定インタフェース３４５を介してモニタ端末３５０の入力装置等から設定される。
【０１８８】
稼働情報収集パラメータ３１０の内容は、監視対象リソース４００の通常の運用では最初に収集する項目を決めて設定された後は、特に監視対象リソース４００に大きな変更が加わらない限り変更されることはない。稼働情報集計部３００は、さらに稼働統計情報収集パラメータ３１０に従って収集コマンドを実行する収集コマンド実行３２０、および収集コマンドの実行結果である稼動情報を受け取って所定の処理を行う収集コマンド結果取得部３３０、さらに収集した稼動情報の中で予め設定した条件に合致した結果から統計値を生成し、稼働統計テーブル１２０へと格納する稼働統計値登録部３４０、およびタイマ３４１から構成される。
【０１８９】
図１７は稼働情報集計部３００が使用する稼働情報収集パラメータ３１０の定義である。図１７は稼働情報収集パラメータ３１０の１つのパラメータの行（またはレコード）を示し、構成情報ＩＤ３１１、パラメータ生成式３１２、収集コマンド３１３、モニタ間隔３１４、およびフィルタ条件３１５ａ、３１５ｂ、統計情報生成式３１６ａ、３１６ｂ、統計値ＩＤ検索式３１７ａ、３１７ｂからなる統計情報生成リスト３１８ａ、３１８ｂが１つ以上、から構成される。なお、以下では、フィルタ条件３１５ａ、３１５ｂの総称をフィルタ条件３１５とし、統計情報生成式３１６ａ、３１６ｂの総称を統計情報生成式３１６とし、統計値ＩＤ検索式３１７ａ、３１７ｂの総称を統計値ＩＤ検索式３１７とし、統計情報生成リスト３１８ａ、３１８ｂの総称を統計情報生成リスト３１８とする。
【０１９０】
稼働情報収集パラメータ３１０の内容については、上述のように管理者などが操作するモニタ端末３５０の入力装置等から設定される。構成情報ＩＤ３１１には、図４の構成情報管理テーブル１３０の構成情報ＩＤ１３５に対応する値が格納される。収集コマンド３１３には、対象となる構成情報ＩＤ３１１に対して実行させる稼動情報の収集コマンドを格納する。モニタ間隔３１４には、モニタ端末３５０で設定する稼動情報の収集周期が格納される。
【０１９１】
モニタ端末３５０は、パラメータ設定インタフェースに対して統計値の生成を要求し、構成情報管理テーブル１３０の構成情報ＩＤ１３５を指定して、上記各パラメータを設定する。設定されたパラメータは新たなレコードとして稼働情報収集パラメータ３１０に格納される。稼働情報集計部３００は、構成情報ＩＤと統計値ＩＤをモニタリングシステム１００に通知し、構成情報管理テーブル１３０の構成情報５００に統計値ＩＤが格納される。
【０１９２】
パラメータ生成式３１２は、後述するように、構成情報ＸＭＬ５００に含まれるサーバ名やＩＰアドレス等を指定するための式が設定される。
【０１９３】
収集コマンド３１３の一例としては、後述するように、稼働情報を収集するプロトコルであるＳＮＭＰに従ったコマンド等が設定される。
【０１９４】
フィルタ条件３１５の一例としては、図１７に示す＄FilterElemで示すような条件が設定される。
【０１９５】
統計情報生成式３１６の一例としては、図１７に示すように、収集した稼動情報の百分率や平均値や合計値を求める式が設定される。
【０１９６】
統計値ＩＤ検索式３１７の一例としては、図１７に示すように、構成情報ＸＭＬ５００のインスタンスに対応する統計値ＩＤを求める式が設定される。
【０１９７】
図１８に稼働情報集計部３００で行われる処理のフローチャートを示す。
【０１９８】
稼働情報集計部３００は、図１７のように予め設定された稼働情報収集パラメータ３１０をパラメータとして読み込んで起動される。ここでは説明を簡易にするため、稼働情報収集パラメータ３１０の各行ごとに別パラメータを与えて起動するとしているが、一つのプログラムで複数の収集コマンドを発行できるようにしても良い。
【０１９９】
ステップ１５００で稼働情報集計部３００のプログラムが起動され、ステップ１５１０へ進む。
【０２００】
ステップ１５１０では、稼働情報集計部３００は図１７の稼働情報収集パラメータ３１０を参照し、構成情報ＩＤ３１１をキーにして構成情報管理テーブル１３０から最新のリビジョン１３１を持つレコードの構成情報ＸＭＬ５００を取得し、ステップ１５２０へと進む。
【０２０１】
ステップ１５２０では、稼働情報集計部３００が構成情報ＸＭＬ５００から稼働情報収集パラメータ３１０のパラメータ生成式３１２に従って、収集コマンド３１３の起動に必要なパラメータを補完し、ステップ１５３０へ進む。
【０２０２】
ここでパラメータ生成式３１２は、構成情報ＸＭＬ５００に含まれるインスタンスを特定するのに必要なパラメータ（サーバ名やＩＰアドレス等）を指定するための式であり、一例としてはＸＭＬパス形式で指定する方法が考えられる。例えば図３２で示したＸＭＬ表現から、仮想サーバのサーバ名を抽出するためのＸＭＬパス形式の一例は”／ＶｉｒｔｕａｌＳｅｒｖｅｒ／ＳｅｒｖｅｒＮａｍｅ”となる。
【０２０３】
一般にパラメータ生成式３１２にマッチするノードは一つの構成情報ＸＭＬ５００に複数存在するために、生成されるパラメータは複数のリストとなる。
【０２０４】
ステップ１５３０では、ステップ１５２０で生成されたパラメータの数に応じて稼働情報集計部３００のインスタンスを生成する。インスタンスの生成は、複製により生成することもできる。インスタンスを複製する方法としては例えばＵｎｉｘ（登録商標）のｆｏｒｋシステムコールを使って複製する方法や、スレッドを分ける方法などが考えられる。なお、稼働情報の収集処理を並行に実行することさえできれば必ずしもプロセスやスレッドを複製する必要は無い。ステップ１５４０に進む。
【０２０５】
ステップ１５４０では、収集コマンド実行部３２０が上記生成されたパラメータを引数にして収集コマンド３１３を監視対象リソース４００に対して実行する。収集コマンド３１３としては、稼働情報を収集するプロトコルであるＳＮＭＰに従ったコマンドや、予めインストールしたエージェントに対する通信、あるいはリモートシェルなどを使って稼働状態を取得するコマンド（Ｌｉｎｕｘ（登録商標）でのｖｍｓｔａｔやｉｏｓｔａｔなど）を発行する方法などが考えられる。ステップ１５５０へ進む。
【０２０６】
ステップ１５５０では、収集コマンド結果取得部３３０はステップ１５４０で実行した収集コマンド３１３の結果をパイプ（標準出力）あるいはファイル経由で取得する。ステップ１５６０へ進む。
【０２０７】
ステップ１５６０では、パラメータとして与えられたフィルタ条件３１５と統計情報生成式３１６と統計値ＩＤ検索式３１７の組からなる稼働情報生成リスト３１８のそれぞれについて、ステップ１５７０〜ステップ１５９０までを繰り返し実行する。
【０２０８】
ステップ１５７０では、得られた結果がフィルタ条件３１５に一致しているかを判断する。フィルタ条件３１５に一致していない場合は集計対象に該当する統計値は含まれていないため、ステップ１５９０へ進む。フィルタ条件３１５に一致していた場合は稼働統計値登録部３４０がステップ１５８０の統計値の登録処理を行ってからステップ１５９０へと進む。
【０２０９】
ステップ１５８０の統計値の登録処理については後に図１９にて詳細に説明する。
【０２１０】
ステップ１５９０では、フィルタ条件３１５と統計情報生成式３１６と統計値ＩＤ検索式３１７の組の統計情報生成リスト３１８の残りについて、ステップ１５６０に戻り繰り返す。全て完了した場合ステップ１６００へと進む。
【０２１１】
ステップ１６００では、モニタ間隔３１４が経過しているか否かをタイマ３４１をチェックし、経過するまで待つ。経過後ステップ１５４０へと戻る。
【０２１２】
以上が稼働情報集計部３００の動作を示すフローチャートである。
【０２１３】
続いて図１９に稼働統計値登録部３４０で行われる統計値登録処理１５８０の詳細なフローチャートを示す。
【０２１４】
ステップ１６１０で、稼働統計値登録部３４０は、稼動情報収集パラメータ３１０の統計情報生成式３１６に従い、統計値を算出する。ここで、統計値とは、稼働統計テーブル１２０に登録する統計値１２３に対応する統計値であり、収集した稼動情報の平均値や最小値、最大値、標準偏差あるいは標本数、などから構成される。１つの値のみから統計値を算出する場合は、平均値＝最小値＝最大値となり、標準偏差は０、標本数は１とする。稼動情報収集パラメータ３１０の統計情報生成式３１６は、ステップ１５５０で取得した収集コマンド３１３の出力結果から、統計値を生成する式である。統計情報生成式３１６は、パーセントの数字の場合に稼動情報を１００で割るといった処理や、２つの値の平均や合計を求めるといった処理が考えられる。ステップ１６２０へ進む。
【０２１５】
ステップ１６２０では、構成情報ＸＭＬ５００から統計値ＩＤ検索式３１７に従って統計値ＩＤを取得し変数ｓに格納する。ここで、統計値ＩＤ検索式３１７とは、構成情報ＸＭＬ５００のインスタンスから、対応する統計値ＩＤ（構成情報ＸＭＬノード上でインスタンスノードの配下にあるケースが多い）を求める式であり、一例としてはＸＭＬパス形式を使うことが考えられる。たとえば、図３２、図３３の構成情報ＸＭＬ５００ａの場合、ハイパーバイザのインスタンスを示す式が”／ＳｅｒｖｅｒＲａｃｋ／ＳｅｒｖｅｒＣｈａｓｓｉｓ／ＰｈｙｓｉｃａｌＳｅｒｖｅｒ／Ｈｙｐｅｒｖｉｓｏｒ”であり、その仮想サーバのＣＰＵ使用率の統計値ＩＤを示すＸＭＬパス式は”．／ＣＰＵＵｓａｇｅ＠ｓｔａｔｉｓｔｉｃｓ＿ｉｄ”となる。ステップ１６３０に進む。
【０２１６】
ステップ１６３０では、タイマ３４１からタイムスタンプｔを取得し、ステップ１６４０へ進む。
【０２１７】
ステップ１６４０では、稼働統計テーブル１２０に、統計値ＩＤ１２１＝ｓ、タイムスタンプ１２２＝ｔ、統計値１２３＝（ｖ１、ｖ２、．．．、ｖｎ）を登録する。
【０２１８】
以上で統計値の登録処理１５８０が完了する。
【０２１９】
＜ベースリソースの構成要素の自動的な統計情報分析＞
図２９を用いて監視対象リソース４００の仮想リソース４２０で共有しているベースリソース４１０の構成要素について行う自動的な統計情報分析の概要を説明する。
【０２２０】
図２９は、図１のモニタリングシステム１００のモニタ端末３５０で表示する構成情報と統計情報の関連を一画面で表示している例である。
【０２２１】
ここでは、仮想サーバ４２２で共有しているＨＢＡ４１５の稼働状況を調査し、どの仮想サーバ４２２が最も当該ＨＢＡ４１５を使用しているのかをモニタリングシステム１００の利用者が調査をするシナリオを想定している。
【０２２２】
まず、モニタリングシステム１００のユーザがモニタ端末３５０で、監視したいシステム要素をマウス等の入出力装置でクリックする。図２９では、ＨＢＡ０をクリックしている（２０４０）。そして、モニタリングシステム１００は後述の統計情報分析処理を実行した後、ＨＢＡ０上のデータ転送速度（スループット）を仮想サーバ毎に色（またはパターン）を変えて積み上げグラフの形式で表示する（２０４１）。このような仮想サーバ毎の統計情報の積み上げグラフを作成するには、直接該当するデータを計測できているケース、例えば、サーバ仮想化部４２１が仮想サーバ４２２毎に割り当てているプロセッサ４１２のＣＰＵ使用率のようなケースでは、計測した数値をそのまま積み上げグラフで表示すればよい。しかし、図２９のようにＨＢＡ４１５では仮想サーバ４２２毎の統計情報を得るためには、特別なハードウェアを搭載していなければ計測はできない。そこで、ＨＢＡ０を経由するディスクアクセスのスループットをＨＢＡ０のデータスループットとみなして、仮想サーバ４２２毎のスループット値の積み上げグラフを生成することでＨＢＡ０のスループットが分析できる。本発明では、このような分析処理を自動化すること目的としている。
【０２２３】
＜データ構造＞
図２５を用いて統計情報のデータ構造について説明する。基本的には図７、図３２、図３３を用いて説明したプラットフォームツリー６００とサービス提供ツリー６１０を相互参照で結合したものである。プラットフォームツリー６００では、物理サーバ４１１の下にＨＢＡ４１５が存在している。ＨＢＡ４１５に関連付けられている統計情報５８２は空集合になっている。一方、仮想サーバ４２２の下にはｖＨＢＡ４６０が存在し、その下にはＬＵ４６５が存在し、さらにその下にはパーティション４７０が存在する。ｖＨＢＡ４６０に関連付けされている統計情報５８１は空集合となっている。さらに、パーティション４７０に紐づけられた統計値（ディスクの統計情報）５８０がある。
【０２２４】
サービス提供ツリー６１０に属する統計情報のデータについて説明する。サービス提供ツリー６１０では、ＨＢＡ４１５０を親ノードとし、その下にｖＨＢＡ４６５０が存在する。ＨＢＡ４１５０は統計情報４５８０と関連付けされている。そして、ＨＢＡ４１５とＨＢＡ４１５０の間と、ｖＨＢＡ４６０とｖＨＢＡ４６５０の間には相互参照が張られている（図２５の破線）。
【０２２５】
サービス提供ツリー６１０上の統計情報４５８０（統計値ＩＤ＝４００１〜４００２）、４５８２（統計値ＩＤ＝４１０１〜４１０４）は、図２６に示す稼働統計分析テーブル１１５で統計情報が定義されている。図２６の稼働統計分析テーブル１１５は、図２のモニタリングシステム１００の構成要素の一つである。稼働統計分析テーブル１１５の構成は、統計値ＩＤ２００１、データ名２００２、表示２００３、演算２００４から一つのレコードが構成される。
【０２２６】
表示２００３はモニタ端末３５０に表示するグラフの形式を指定するものである。表示２００３では子ノードに相当するデータは表示対象ではないことを示す“−”が設定される。親ノードに対しては演算２００４の演算内容で集計したデータを表示２００３の形式でモニタ端末３５０の表示装置に画面表示される。表示２００３に設定される“合計”は子ノードの数値をすべて加算した数値で、”積み上げ”は子ノードの数値を、それぞれのノードの数値が占める割合が分かるように積み上げたグラフを意味している。
【０２２７】
演算２００４の列には、統計値の演算方法が指定されている。演算名が“集合｛ ｝“は、”｛ ｝“で指定された集合をそのまま集合として返す。演算名が”合計値[ ]“は、”[ ]“で指定された集合の数値をすべて加算したものが返り値となる。図では記載されていないが、演算としては、平均値、最大値、最小値など他の集合演算も指定できる。
【０２２８】
稼働統計分析テーブル１１５の設定は、図２７の稼働時計分析の演算を指定する入力画面２０１５から、管理者がモニタ端末３５０の入力装置から入力して指定する。この入力画面２０１５は、管理者が図２のモニタ端末３５０から構成情報ＧＵＩ制御部２６０に対してモニタ端末３５０で表示されるメニュー画面から呼び出す。そして、構成情報管理部２００が構成情報管理テーブル１３０から、サービス提供ツリー６１０の一覧を検索し、検索結果を構成情報ＧＵＩ制御部２８０がモニタ端末３５０上にウィンドウ（画面２０１５）を新規に開いて表示する。
【０２２９】
このとき同時に統計情報の種類（使用率やスループットなど）も同時に検索する。入力画面２０１５は、サービス提供ツリー６１０の構成要素の一覧を場変換２０１１の列に表示し、モニタリングシステム１００のユーザは演算２０１２の列に表示されるプルダウンメニュー２０１４から所望の演算を選択する。さらに統計値の種類２０１３もプルダウンメニュー（図示なし）で選択する。なお、統計値の種類２０１３は、統計値ＩＤ２００１が指し示す稼動統計分析テーブル１１５のデータ名２００２に対応し、統計情報の単位（Ｒｅａｄ／ｓｅｃやｗｒｉｔｅ／ｓｅｃ等）を設定する。また、統計情報の単位のＲｅａｄ／ｓｅｃやｗｒｉｔｅ／ｓｅｃは、データ転送速度＝データ量（ＭＢ）／ｓｅｃや転送速度＝トランザクション数／ｓｅｃなど予め設定した単位を意味する。
【０２３０】
＜分析のフローチャート＞
図２８を用いてモニタリングシステム１００が実行する図２９の分析処理２０３５の流れを説明する。
【０２３１】
モニタ端末３５０で、モニタリングシステム１００のユーザが注目するシステム要素（仮想化されている物理リソース＝ベースリソース４１０の構成要素）を図２９の画面に表示したシステム構成図上から選択操作（クリック等）を受け付ける（ステップ２０２０）とステップ２０２１に進む。
【０２３２】
ステップ２０２１では、選択操作で選択されたシステム要素（図２５のＨＢＡ４１５）に紐づけられた統計情報をモニタリングシステム１００が構成情報管理テーブル１３０を検索する。統計情報が登録されている場合、ステップ２０３０に遷移し、統計情報を画面上に表示して処理は終了。統計情報が登録されていない場合は、ステップ２０２３に移る（ステップ２０２２）。
【０２３３】
ステップ２０２３では、モニタリングシステム１００がプラットフォームツリー６００から相互参照のあるサービス提供ツリー６１０をたどり、サービス提供ツリー６１０の子ノード（図２５のｖＨＢＡ４６５０）を検索する。そして、モニタリングシステム１００は子ノード（ｖＨＢＡ４６５０）に紐付けられたサービス提供ツリー６１０上のＨＢＡの統計情報として、統計値ＩＤ＝４００１と統計値ＩＤ＝４００２を取得する。次に、モニタリングシステム１００は稼働統計分析テーブル１１５を参照して検索した子ノードの統計値ＩＤのレコードで演算２００４で指定されたデータを参照する（ステップ２０２４）。
【０２３４】
図２６では、統計値ＩＤ４００１または４００２の演算２００４列で指定されているリンク先要素の統計値を検索する。ここでいうリンク先とは、ｘｐａｔｈ（図３２Ａ、図３２Ｂ）で指定されているプラットフォームツリー６００上のノードを指している。ステップ２０２５，２０２６，２０２７では、サービス提供ツリー６１０上で注目している（クリックした）親ノードに接続しているすべての子ノードで統計値を検索し、発見した統計値を返す。上記処理の終了後、ステップ２０２８に進む。
【０２３５】
ステップ２０２８では発見した統計情報を、稼働統計分析テーブル１１５で指定した親ノードの表示形式に統計情報管理部１９０で変換し、ステップ２０２９に進む。
【０２３６】
ステップ２０２９では、サービス提供ツリーの親ノードと相互参照のあるプラットフォームツリーのノードの統計値として数値を統計情報ＧＵＩ制御部２６０がモニタ端末３５０の画面上に表示する（ステップ２０３０）。
【０２３７】
上記処理によりモニタ端末３５０の表示装置には、図２９の統計情報（２０４１）が所定のグラフで表示される。
【０２３８】
＜変形例＞
本発明の変形例として、性能分析ナビゲーションシステムを説明する。システムの概略を、図３０を用いて説明する。構成情報と統計情報の関連を一つの画面上に表示することは先に述べた実施形態と同様である。モニタ端末３５０の表示装置の画面上の分析ナビゲーション開始ボタン２１０２を入力装置等により選択する（クリック）と、物理リソースを含むベースリソース４１０を共有している仮想リソース（仮想リソース４２０）の利用状況の積み上げグラフが表示される（第一ステップ：共有リソースの状況２１０１）。
【０２３９】
例えば、物理サーバ４１１の物理ＣＰＵ（プロセッサ４１２）を各仮想サーバ（０〜２）でどのくらい利用しているかを判別するためのグラフ（ＣＰＵ使用率）や、ＨＢＡを各仮想サーバ毎にどのくらい使用しているのかを判別するための各仮想サーバのＩＯスループットの積み上げグラフ（ＨＢＡ０のデータ転送速度）等が挙げられる。
【０２４０】
管理者は、このグラフを見ることで、どの仮想サーバ０〜２が物理リソースを多く使い、どの仮想サーバ０〜２の動作に影響を及ぼしているかを判定することが可能である。更に、管理者がモニタ端末３５０の入力装置で監視対象切換えボタン２１０３を操作することで、各仮想サーバ０〜２で計測された統計情報（例えば、ＣＰＵ使用率やＩＯスループットなど）のグラフが表示され、それぞれの稼働状態を検証できる。このようにして、仮想化された計算機システムでの性能分析を支援することが可能である。
【０２４１】
性能分析ナビゲーションシステムの動作を図３１のフローチャートを用いて説明する。初めにナビゲーションの初期画面をモニタリングシステム１００がモニタ端末３５０に表示する（ナビゲート２１００ 開始）。システムの管理者は、モニタ端末３５０の入力装置等から表示されている画面上のナビゲート開始ボタン２１０２をクリックし、モニタリングシステム１００はモニタ端末３５０の入力装置からの信号を受け付ける（ステップ２１１１）と、ステップ２１１２に進む。
【０２４２】
ステップ２１１２では、モニタリングシステム１００では、図２の統計情報ＧＵＩ制御部は統計情報管理部１９０にナビゲート開始を通知する。統計情報管理部１９０は構成情報管理部２００にサービス提供ツリー６１０の親ノードをリストアップするように指示し、ステップ２１１３に進む。
【０２４３】
ステップ２１１３では、構成情報管理部２００でリストアップされた親ノードに対して、図２８の分析処理２０３５を実行する（ステップ２１１４）。ただし、ステップ２５０２でユーザがクリックして注目するノードを指定する代わりに、リストアップされたサービス提供ツリー６１０の親のノードが関連付けられているプラットフォームツリー６００のノードが入力される。これは例えば図２５のサービス提供ツリー６１０のＨＢＡ４１５０に相互参照がつけられているプラットフォームツリー６００のＨＢＡ４１５のことである。一つのノードについて処理が終了したら次のノードに対して同じ処理を実行する（ステップ２１１５）。
【０２４４】
全ての親ノードの処理が終了したらモニタ端末３５０に積み上げグラフを表示する。次にステップ２１１７、２１１８、２１１９、２１２０で全ての仮想サーバの統計情報についてグラフを作成する処理をする。グラフの表示に必要な処理は既に説明した図１４の手順で実行されるので、ここでは省略する。
【０２４５】
全ての仮想サーバ０〜２の情報を一度にモニタ端末３５０の表示装置の画面に表示しても、管理者はどこを見るべきか判断が難しくなるため、ステップ２１１８ではモニタリングシステム１００が画面上の監視対象切替ボタン２１０３の操作を受け付けると、表示するデータを切換える。ステップ２１１９では、モニタリングシステム１００が、各仮想サーバ０〜２に関連付けられた統計情報をモニタ端末３５０の表示装置へ出力する。上記処理を全ての仮想サーバ０〜２について繰り返した後（ステップ２１２０）、処理を終了する。
【０２４６】
上記処理によって、監視対象リソース４００を構成するベースリソース４１０の物理的な構成と仮想リソース４２０の仮想化された構成について、モニタ端末３５０の表示装置へ表示を行い、ベースリソース４１０の構成要素である物理サーバ４１１を共有する全ての仮想サーバのリソースの利用状況（２１０１）と仮想サーバ毎のリソースの利用状況をそれぞれグラフとして表示することができる。
【０２４７】
以上のように、本発明の実施形態及び変形例によれば、監視対象リソース４００について、物理リソースを含むベースリソース４１０と、ベースリソース４１０のリソースを使用する仮想リソースを含む仮想リソース４２０に分ける。そして、ベースリソース４１０と仮想リソース４２０の構成要素の関係を漏れなく、かつ少ない手数で構成情報と統計情報の管理を行うことが可能となる。ベースリソース４１０または仮想リソース４２０の統計情報は、モニタリングシステム１００によって、任意の構成要素から、物理リソース（ベースリソース４１０のリソース）を共有する仮想リソースごとの統計情報を容易に分析することが可能となる。また、構成情報のデータ構造に従って統計情報を分析することで、モニタリングシステム１００を利用する管理者等に効率的な統計情報の管理をナビゲートすることが可能となる。これらにより、稼動情報から計算機リソースのボトルネックを検出するまでの時間を短縮でき、多数の計算機、特に多数の仮想サーバを備えた計算機システムにおける運用や管理に要する管理者の効率を改善できる。
【０２４８】
上記従来技術の特許文献１と比較して、本発明では木構造のプラットフォームツリー６００とサービス提供ツリー６１０に分類し、木構造の相互参照を定義しておくことで構成要素の追加や変更を容易に管理することが可能となる。
【０２４９】
監視対象リソース４００の構成要素の追加や削除のコストは、サーバ台数をＳとすると、サーバ台数によらず当該サーバが関係している部分だけの変更にとどまるためＯ（１）回のコストで実行でき、データ量はサーバ台数に比例するのでＯ（Ｓ）であるといえる。したがって、従来技術と比較するとコスト面で本特許の方式でコストを低減できる。
【０２５０】
また、上記実施形態では、モニタリングシステム１００と構成管理マネージャ３６０と稼動情報集計部３００が異なる計算機で稼動する例を示したが、これらが同一の計算機で稼動することもでき、この場合にはモニタリング部と構成管理部と稼動情報集計部をソフトウェアとして実装することができる。
【産業上の利用可能性】
【０２５１】
以上のように、物理サーバと仮想サーバを備えて構成情報または統計情報の履歴を管理する計算機システムに適用することができる。
【符号の説明】
【０２５２】
１００ モニタリングシステム
１１０ モニタ情報データベース
１１５ 稼働統計分析テーブル
１２０ 稼動統計テーブル
１３０ 構成情報管理テーブル
１５０ コンポーネント履歴管理テーブル
１６０ 割当済ＩＤ管理テーブル
１８０ 構成関連管理テーブル
１９０ 統計情報管理部
２００ 構成情報管理部
２１０ 履歴情報管理部
２５０ 統計情報ＧＵＩ制御部
２６０ 構成情報ＧＵＩ制御部
２７０ 履歴情報ＧＵＩ制御部
３００ 稼動情報収集部
３５０ モニタ端末
３６０ 構成管理マネージャ
３８１ ツリー変換設定
３８３ 基準構成テーブル
３８４ ｘｐａｔｈ生成テーブル
４００ 監視対象リソース
４１０ ベースリソース
４２０ 仮想リソース
４９０ 相互参照
６００ プラットフォームツリー
６１０ サービス提供ツリー
【特許請求の範囲】
【請求項１】
１つ以上の物理計算機と、
前記物理計算機で実行されて１つ以上の仮想計算機を稼働させる仮想化部と、
前記仮想化部上で稼動する１つ以上の仮想計算機と、
前記物理計算機の構成要素と、前記仮想計算機の構成要素と、を監視するモニタリング部と、
を備えた計算機のモニタリングシステムであって、
前記モニタリング部は、
前記物理計算機の構成要素である物理リソースと、前記仮想化部の構成要素とを併せてベースリソースとし、前記仮想化部上で稼動する仮想計算機の構成要素を仮想リソースとして管理し、
前記仮想リソースの構成要素と前記ベースリソースの構成要素を所定のプラットフォーム毎に木構造を抽出してプラットフォームツリーを生成し、
前記仮想リソースの構成要素から、所定の変換情報に設定された前記ベースリソースまたは仮想リソースを起点とする木構造を抽出してサービス提供ツリーを生成し、
前記プラットフォームツリーに含まれ、かつ、前記サービス提供ツリーに含まれる構成要素について参照することを示す参照情報を設定し、前記プラットフォームツリーと前記サービス提供ツリーの構成要素の参照関係を設定することを特徴とする計算機のモニタリングシステム。
【請求項２】
請求項１に記載の計算機のモニタリングシステムであって、
前記ベースリソースと仮想リソースの稼働情報を収集し、前記稼動情報に所定の統計処理を施して統計情報を生成する稼動情報集計部をさらに有し、
前記モニタリング部は、
前記ベースリソースと前記仮想リソース及び前記統計情報に一意の識別子を付与し、前記統計情報には前記稼動情報を収集した前記ベースリソースまたは仮想リソースの前記識別子を親の識別子として設定することを特徴とする計算機のモニタリングシステム。
【請求項３】
請求項１に記載の計算機のモニタリングシステムであって、
前記変換情報は、
前記ベースリソースの構成要素のうち仮想化または論理化して仮想リソースを生成する上位要素と、前記上位要素を仮想化または論理化して、仮想リソースの複数の構成要素に分割する下位要素を設定することを特徴とする計算機のモニタリングシステム。
【請求項４】
請求項３に記載の計算機のモニタリングシステムであって、
前記モニタリング部は、
前記上位要素の構成要素と前記下位要素の構成要素と、前記上位要素及び下位要素の前記統計情報をひとつの画面として出力するＧＵＩ制御部を有することを特徴とする計算機のモニタリングシステム。
【請求項５】
請求項４に記載の計算機のモニタリングシステムであって、
前記ＧＵＩ制御部は、
前記上位要素または前記下位要素の構成要素を受け付けて、前記受け付けた構成要素に対応付けられた前記統計情報を出力することを特徴とする計算機のモニタリングシステム。
【請求項６】
１つ以上の物理計算機と、前記物理計算機で実行されて１つ以上の仮想計算機を稼働させる仮想化部と、前記仮想化部上で稼動する１つ以上の仮想計算機と、前記物理計算機の構成要素と、前記仮想計算機の構成要素と、を監視するモニタリング部を備えて、計算機のリソースを監視する計算機のモニタリング方法であって、
前記モニタリング部が、前記物理リソースの構成要素と前記仮想化部の構成要素をそれぞれ取得してベースリソースとして管理する第１のステップと、
前記モニタリング部が、前記仮想化部上で稼動する仮想計算機の構成要素を取得して仮想リソースとして管理する第２のステップと、
前記モニタリング部が、前記仮想リソースの構成要素と前記ベースリソースの構成要素を所定のプラットフォーム毎に木構造を抽出してプラットフォームツリーを生成する第３のステップと、
前記仮想リソースの構成要素から、所定の変換情報に設定された前記ベースリソースまたは仮想リソースを起点とする木構造を抽出してサービス提供ツリーを生成する第４のステップと、
前記プラットフォームツリーに含まれ、かつ、前記サービス提供ツリーに含まれる構成要素について参照することを示す参照情報を設定し、前記プラットフォームツリーと前記サービス提供ツリーの構成要素の参照関係を設定する第５のステップと、
を含むことを特徴とする計算機のモニタリング方法。
【請求項７】
請求項６に記載の計算機のモニタリング方法であって、
前記モニタリング部が、前記ベースリソースと仮想リソースの稼働情報を収集し、前記稼動情報に所定の統計処理を施して統計情報を生成する第６のステップと、
前記モニタリング部が、
前記ベースリソースと前記仮想リソース及び前記統計情報に一意の識別子を付与し、前記統計情報には前記稼動情報を収集した前記ベースリソースまたは仮想リソースの前記識別子を親の識別子として設定する第７のステップと、
をさらに含むことを特徴とする計算機のモニタリング方法。
【請求項８】
請求項６に記載の計算機のモニタリング方法であって、
前記変換情報は、
前記ベースリソースの構成要素のうち仮想化または論理化して仮想リソースを生成する上位要素と、前記上位要素を仮想化または論理化して、仮想リソースの複数の構成要素に分割する下位要素を設定することを特徴とする計算機のモニタリング方法。
【請求項９】
請求項８に記載の計算機のモニタリング方法であって、
前記モニタリング部が、前記上位要素の構成要素と前記下位要素の構成要素と、前記上位要素及び下位要素の前記統計情報をひとつの画面として出力する第８のステップをさらに含むことを特徴とする計算機のモニタリング方法。
【請求項１０】
請求項９に記載の計算機のモニタリング方法であって、
前記第８のステップは、
前記モニタリング部が、上位要素または前記下位要素の構成要素を受け付けて、前記受け付けた構成要素に対応付けられた前記統計情報を出力することを特徴とする計算機のモニタリング方法。
【請求項１】
１つ以上の物理計算機と、
前記物理計算機で実行されて１つ以上の仮想計算機を稼働させる仮想化部と、
前記仮想化部上で稼動する１つ以上の仮想計算機と、
前記物理計算機の構成要素と、前記仮想計算機の構成要素と、を監視するモニタリング部と、
を備えた計算機のモニタリングシステムであって、
前記モニタリング部は、
前記物理計算機の構成要素である物理リソースと、前記仮想化部の構成要素とを併せてベースリソースとし、前記仮想化部上で稼動する仮想計算機の構成要素を仮想リソースとして管理し、
前記仮想リソースの構成要素と前記ベースリソースの構成要素を所定のプラットフォーム毎に木構造を抽出してプラットフォームツリーを生成し、
前記仮想リソースの構成要素から、所定の変換情報に設定された前記ベースリソースまたは仮想リソースを起点とする木構造を抽出してサービス提供ツリーを生成し、
前記プラットフォームツリーに含まれ、かつ、前記サービス提供ツリーに含まれる構成要素について参照することを示す参照情報を設定し、前記プラットフォームツリーと前記サービス提供ツリーの構成要素の参照関係を設定することを特徴とする計算機のモニタリングシステム。
【請求項２】
請求項１に記載の計算機のモニタリングシステムであって、
前記ベースリソースと仮想リソースの稼働情報を収集し、前記稼動情報に所定の統計処理を施して統計情報を生成する稼動情報集計部をさらに有し、
前記モニタリング部は、
前記ベースリソースと前記仮想リソース及び前記統計情報に一意の識別子を付与し、前記統計情報には前記稼動情報を収集した前記ベースリソースまたは仮想リソースの前記識別子を親の識別子として設定することを特徴とする計算機のモニタリングシステム。
【請求項３】
請求項１に記載の計算機のモニタリングシステムであって、
前記変換情報は、
前記ベースリソースの構成要素のうち仮想化または論理化して仮想リソースを生成する上位要素と、前記上位要素を仮想化または論理化して、仮想リソースの複数の構成要素に分割する下位要素を設定することを特徴とする計算機のモニタリングシステム。
【請求項４】
請求項３に記載の計算機のモニタリングシステムであって、
前記モニタリング部は、
前記上位要素の構成要素と前記下位要素の構成要素と、前記上位要素及び下位要素の前記統計情報をひとつの画面として出力するＧＵＩ制御部を有することを特徴とする計算機のモニタリングシステム。
【請求項５】
請求項４に記載の計算機のモニタリングシステムであって、
前記ＧＵＩ制御部は、
前記上位要素または前記下位要素の構成要素を受け付けて、前記受け付けた構成要素に対応付けられた前記統計情報を出力することを特徴とする計算機のモニタリングシステム。
【請求項６】
１つ以上の物理計算機と、前記物理計算機で実行されて１つ以上の仮想計算機を稼働させる仮想化部と、前記仮想化部上で稼動する１つ以上の仮想計算機と、前記物理計算機の構成要素と、前記仮想計算機の構成要素と、を監視するモニタリング部を備えて、計算機のリソースを監視する計算機のモニタリング方法であって、
前記モニタリング部が、前記物理リソースの構成要素と前記仮想化部の構成要素をそれぞれ取得してベースリソースとして管理する第１のステップと、
前記モニタリング部が、前記仮想化部上で稼動する仮想計算機の構成要素を取得して仮想リソースとして管理する第２のステップと、
前記モニタリング部が、前記仮想リソースの構成要素と前記ベースリソースの構成要素を所定のプラットフォーム毎に木構造を抽出してプラットフォームツリーを生成する第３のステップと、
前記仮想リソースの構成要素から、所定の変換情報に設定された前記ベースリソースまたは仮想リソースを起点とする木構造を抽出してサービス提供ツリーを生成する第４のステップと、
前記プラットフォームツリーに含まれ、かつ、前記サービス提供ツリーに含まれる構成要素について参照することを示す参照情報を設定し、前記プラットフォームツリーと前記サービス提供ツリーの構成要素の参照関係を設定する第５のステップと、
を含むことを特徴とする計算機のモニタリング方法。
【請求項７】
請求項６に記載の計算機のモニタリング方法であって、
前記モニタリング部が、前記ベースリソースと仮想リソースの稼働情報を収集し、前記稼動情報に所定の統計処理を施して統計情報を生成する第６のステップと、
前記モニタリング部が、
前記ベースリソースと前記仮想リソース及び前記統計情報に一意の識別子を付与し、前記統計情報には前記稼動情報を収集した前記ベースリソースまたは仮想リソースの前記識別子を親の識別子として設定する第７のステップと、
をさらに含むことを特徴とする計算機のモニタリング方法。
【請求項８】
請求項６に記載の計算機のモニタリング方法であって、
前記変換情報は、
前記ベースリソースの構成要素のうち仮想化または論理化して仮想リソースを生成する上位要素と、前記上位要素を仮想化または論理化して、仮想リソースの複数の構成要素に分割する下位要素を設定することを特徴とする計算機のモニタリング方法。
【請求項９】
請求項８に記載の計算機のモニタリング方法であって、
前記モニタリング部が、前記上位要素の構成要素と前記下位要素の構成要素と、前記上位要素及び下位要素の前記統計情報をひとつの画面として出力する第８のステップをさらに含むことを特徴とする計算機のモニタリング方法。
【請求項１０】
請求項９に記載の計算機のモニタリング方法であって、
前記第８のステップは、
前記モニタリング部が、上位要素または前記下位要素の構成要素を受け付けて、前記受け付けた構成要素に対応付けられた前記統計情報を出力することを特徴とする計算機のモニタリング方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図１１】
【図１２】
【図１３】
【図１４】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２４】
【図２６】
【図２８】
【図２９】
【図３１】
【図３２Ａ】
【図３２Ｂ】
【図３３】
【図３４Ａ】
【図３４Ｂ】
【図３５Ａ】
【図３５Ｂ】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図７】
【図８】
【図９】
【図１０】
【図１５】
【図２３】
【図２５】
【図２７】
【図３０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図１１】
【図１２】
【図１３】
【図１４】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２４】
【図２６】
【図２８】
【図２９】
【図３１】
【図３２Ａ】
【図３２Ｂ】
【図３３】
【図３４Ａ】
【図３４Ｂ】
【図３５Ａ】
【図３５Ｂ】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図７】
【図８】
【図９】
【図１０】
【図１５】
【図２３】
【図２５】
【図２７】
【図３０】
【公開番号】特開２０１２−９９０４８（Ｐ２０１２−９９０４８Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１０−２４８２５３（Ｐ２０１０−２４８２５３）
【出願日】平成２２年１１月５日（２０１０．１１．５）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願日】平成２２年１１月５日（２０１０．１１．５）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]