以下、本発明の一実施形態を添付図面に基づいて説明する。
<第1の実施形態>
<全体ブロック図>
図1は、第1の実施形態を示し、本発明を適用する計算機モニタリングシステムを含む計算機システムの全体ブロック図である。計算機システムは、監視対象となる計算機リソース(以下、監視対象リソースとする)400、モニタリングシステム(モニタリング装置)100、稼動情報集計部300と、監視対象リソース400の構成を管理する構成管理マネージャ360、およびモニタリングシステム100が収集した情報を参照するモニタ端末350とから構成される。
監視対象リソース400の中には、物理的なサーバ(物理計算機)と、ストレージと、ネットワークおよびそれらの上で動作するソフトウェアと、仮想化を実現するソフトウェア(ハイパバイザまたは仮想マシンモニタ)などの物理リソース410、および物理リソース410の上に実装された仮想的なサーバ(仮想計算機)、ストレージ、ネットワーク、および仮想的なサーバ上で動作するソフトウェアなどの仮想リソース420を含む。なお、物理リソース410や仮想リソース420の稼動情報から求めた統計値情報を仮想リソース420に含めても良い。
稼動情報集計部300は監視対象リソース400と同一の計算機上で動作する場合も、異なる計算機上で動作する場合もある。本実施形態では稼動情報集計部300は物理サーバ411−1〜411−nのいずれかひとつで実行するものとする。なお、稼動情報集計部300を実行するサーバは、物理サーバでも良いし、仮想サーバであってもよい。構成管理マネージャ360とモニタリングシステム100も同様であり、異なる計算機上で実行させても良い。いずれの場合も差異は本発明の本質には影響しない。なお、本実施形態では、構成管理マネージャ360とモニタリングシステム100も物理サーバ411−1〜411−nのいずれかひとつで実行するものとする。
監視対象リソース400の物理リソース410は、複数の計算機で構成され、各計算機はプロセッサとメモリ及びインタフェースを有し、インタフェースを介してストレージ装置とネットワークに接続される。物理リソース410と仮想リソース420を含む監視対象リソース400の具体的な例としては、例えば、図43のようになる。
図43は、監視対象リソース400の一例を示す仮想計算機システムのブロック図である。物理リソース410は、複数の物理サーバ411−1〜411−nとネットワーク430とSAN(Storage Area Network)440及びストレージ装置450から構成される。物理サーバ411−1〜411−nは同一の構成であるので、以下では物理サーバ411−1のみについて説明する。
物理サーバ411−1は、プロセッサ412、メモリ413、NIC(Network Interface Card)414、HBA(Host Bus Adapter)415から構成される。なお、図示はしないが物理サーバの起動、停止や監視を行うBMC(Baseboard Management Controller)を備えて入れも良い。
プロセッサ412は、メモリ413内に格納された各種プログラムを実行する。HBA415はSAN440を介してストレージ装置450に接続される。NIC414はネットワーク430に接続される。NIC414は、主にメモリ413上の各種プログラムからの要求に応じて他のサーバと通信する。ネットワーク430には、物理リソース410の仮想リソース420への割り当てを管理する構成管理マネージャ360や物理リソース410及び仮想リソース420の稼動情報を収集する稼動情報収集部305が接続される。なお、図示はしないが、ネットワーク430にはモニタリングシステム100やモニタ端末350が接続されても良い。
メモリ413上には、サーバ仮想化部421が稼働することで、複数の仮想サーバ422−1〜422−mを構築することができる。なお、仮想サーバ422−1〜422−mの総称を仮想サーバ422とする。仮想サーバ422は、それぞれ独立してOS(Operating System)423を稼働させることができる。プロセッサ412によりサーバ仮想化部421が実行されると、サーバ仮想化部421上で複数の仮想サーバ422を構築することができる。サーバ仮想化部41は構成管理マネージャ360の指令に応じて物理サーバ411−1の物理リソース410を仮想サーバ422−1〜422−mの仮想リソース420に割り当てる。また、サーバ仮想化部421は、NIC414やHBA415を仮想化して仮想サーバ422−1〜422−mに提供する。
仮想サーバ422はストレージ装置450に予め格納されたOSイメージをサーバ仮想化部421が読み込んで実行することで、それぞれ独立した仮想サーバ422が構築される。
なお、以下では物理サーバ411−1〜411−nの総称を物理サーバ411とし、仮想サーバ422−1〜422−mの総称を仮想サーバ422とする。
図2は、モニタリングシステム100の内部構成を示したブロック図である。モニタリングシステム100は、各種情報を格納するモニタ情報データベース110、モニタ端末350とのインタフェースを制御する統計情報GUI制御部250、構成情報GUI制御部260、履歴情報GUI制御部270と、GUI制御部250からの指令に基づきモニタ情報データベース110をアクセスして出力する情報を決定する統計情報管理部190、構成情報管理部200、履歴情報管理部210と、が含まれる。これらの各機能はプログラムとして実装され、後述の図43に示す記憶媒体としてのストレージ装置に格納され、物理サーバのプロセッサによりメモリにロードされて実行される。
モニタ情報データベース110の中には、稼動統計テーブル120と、構成情報管理テーブル130と、構成情報変更履歴管理テーブル140と、コンポーネント履歴管理テーブル150などが格納される。なお、構成情報変更履歴管理テーブル140およびコンポーネント履歴管理テーブル150は構成情報管理テーブル130から二次的に生成される情報なので、本発明の実施においては必ずしも必要ではなく、表示を高速化するために用意されたテーブルである。また、構成管理マネージャ360から得られた構成情報245および構成情報生成ポリシー240に従って新たな構成情報を生成し、構成情報管理テーブル130へと格納する構成情報関連管理部230と構成情報に割当てるIDを管理する割当済ID管理テーブル160もモニタリングシステム100に含まれる。
構成管理マネージャ360から受け付ける構成情報生成ポリシー240の一例としては、例えば、同一の構成情報のリビジョン更新時には、各構成情報にそれぞれ付与されるコンポーネントIDを引き継ぎ、新たな構成情報の追加時には、新たなコンポーネントIDを割り当てる。また、構成情報の削除時にはコンポーネントIDを回収し、コンポーネントIDの使い回しを禁止する等のポリシーを予め設定したものである。
図41は、構成管理マネージャ360の詳細を示すブロック図である。
構成管理マネージャ360は、物理サーバ411の物理リソース410に対する仮想サーバ422等の仮想リソース420の割り当てを制御する。また、構成管理マネージャ360は、物理サーバ411の稼動状態を制御する。構成管理マネージャ360は、仮想サーバ422の生成や削除あるいは移動の指令(構成情報及び構成情報生成ポリシーを含む構成変更指令)を監視対象リソース400の仮想化部421に指令して、各物理サーバ411の仮想サーバ422を制御する。また、構成管理マネージャ360は、監視対象リソース400に指令した構成変更指令の構成情報245及び構成情報生成ポリシー240をモニタリングシステム100に通知する。
構成管理マネージャ360は、入出力装置から監視対象リソース400に対する構成変更要求366を受け付け、構成変更要求366が完了すると入出力装置へ構成変更完了通知367を出力する構成変更要求処理部361と、監視対象リソース400の構成情報を格納する構成情報データベース365と、構成変更要求処理部361からの構成変更要求361と構成情報データベース365の構成情報に基づいて、変更前の構成情報245xと変更後の構成情報245yと構成情報の生成ポリシー240を生成する構成変更要求生成部364と、変更前構成情報245yと変更後構成情報245yを構成情報245とし、構成情報生成ポリシー240と構成情報245をモニタリングシステム100の構成情報関連管理部230と構成変更処理指示部363に送信する構成変更情報送信部362と、構成情報生成ポリシー240と構成情報245に基づいて監視対象リソース400のサーバ仮想化部421に構成変更の指令を送信する構成変更処理指示部363と、を含んで構成される。
構成情報データベース365は、後述の図4に示す構成情報管理テーブル130と同様の構成を備える。ただし、構成情報データベース365は、構成情報管理テーブル130の構成情報500に含まれるコンポーネントIDを有していない。コンポーネントIDは、モニタリングシステム100の構成情報関連管理部230が、新たな構成情報245を受け付けると新たなコンポーネントIDを付与する。
構成管理マネージャ360は、入出力装置から構成変更要求366を受け付けると、構成変更要求361に含まれるポリシーと、変更前(現在)の構成情報245xと変更後の構成情報245yを受け付けて、構成情報245と構成情報生成ポリシー240をモニタリングシステム100と監視対象リソース400に送信する。そして、構成管理マネージャ360は、構成変更要求361の処理が完了すると入出力装置へ構成変更完了通知367を出力し、新たな構成情報245yで構成情報データベース365を更新する。
また、構成情報管理テーブル130の構成情報500に付与されるコンポーネントIDは、構成情報関連管理部230が付与するモニタリングシステム100内で一意の値である。このコンポーネントIDは、構成情報500の木構造に関わりなく、一意の識別子を構成情報の構成要素毎に構成情報関連管理部230が割り当てるものである。コンポーネントIDは、監視対象リソース400の物理リソース410の構成要素と、仮想リソース420の構成要素のそれぞれについて一意の値が割り当てられる。
すなわち、監視対象リソース400の構成情報は木構造で構成される階層的な情報であるのに対し、コンポーネントIDはモニタリングシステム100内で一意の識別子として機能する。コンポーネントIDは、後述する割当済ID管理テーブル160のように、物理リソース410の構成要素と仮想リソース420の構成要素及び統計値に対してそれぞれ割り当てられる。マイグレーションなどの構成を実施するときは、このコンポーネントIDを構成変更が行われた構成要素が引き継ぐことで、構成要素に関連付けられた統計値を、構成変更の前後で結びつけることが可能となる。
図42は、構成変更要求生成部364が出力する構成情報生成ポリシー240の一例を示す説明図である。構成変更要求生成部364は、構成変更要求処理部361から受け付けた構成変更要求366から、変更前の構成情報のノード(部分木)と変更後の構成情報のノード情報及びノード間の関係を抽出し、変更前の構成情報のノードを変更前ノード241とし、変更後の構成情報のノードを変更後ノード242とし、ノード間の関係をノード間関連243として構成情報生成ポリシー240を生成する。
ノード間関連243としては、「重複しない割当」、「同一ノードを継承」、「移動元」、「移動先」、「交替元」、「交替先」などに分類される。
「重複しない割当」のノード間関連243は、ひとつの仮想サーバを、昼夜で切り替えて使用する場合などで、変更対象のノードが同一で、異なる構成情報IDが割り当てられた構成情報間では、コンポーネントIDが重複しないように割り当てるように、モニタリングシステム100に指令する。図示の「重複しない割当」の例では、ノードaで構成情報を切り替えて、変更後のノードaの構成情報に新たなコンポーネントIDを付与することを示す。
「同一ノードを継承」のノード間関連243は、構成情報が変化しない場合であり、図示の例ではノードbは構成情報変更の前後で同一のコンポーネントIDを引き継ぐことを示す。
「移動元」および「移動先」のノード間関連243は、ノードが移動する場合であり、図示の例ではノードcがノードdとして移動することを示す。この場合、モニタリングシステム100ではノードcに割り当てられた構成情報のコンポーネントIDを変更後の構成情報ではノードdのコンポーネントIDとして付与する。
「交替元」と「交替先」のノード間関連243は、現用系と待機系で系切替を行う場合であり、図示の例ではノードeを交替元として、ノードfに構成情報を移動することを示す。この場合、モニタリングシステム100ではノードeに割り当てられた構成情報のコンポーネントIDを、ノードfの構成情報に割り当てられたコンポーネントIDに上書きする。
<処理の概要>
図1の計算機システムで行われる処理の一例を以下に示す。
構成管理マネージャ360は、監視対象リソース400の構成を変更する度にモニタリングシステム100に通知し、モニタリングシステム100は通知を受けた構成情報245と構成情報生成ポリシー240から構成情報管理テーブル130を更新する。モニタリングシステム100は、例えば、新たな構成情報245を受け付けると、構成情報管理テーブル130に当該構成情報245の内容(例えば、物理サーバ411や仮想サーバ422あるいはI/Oデバイス)を構成情報134の構成情報XMLに加え、構成情報XMLに含まれる構成要素毎に計算機システム内でユニークなコンポーネントID161を割り当てる。
一方、モニタ端末350から、監視対象リソース400に対する稼動情報の収集要求が稼動情報集計部300に送信されると、稼動情報集計部300は要求された監視対象リソース400に対する稼動情報の収集及び稼動情報の統計値に関する定義を格納し、統計値に対して統計値IDを付与する。稼動情報集計部300は、稼動情報の統計値の収集対象となった監視対象リソース400の構成情報IDと統計値情報(CPU利用率、メモリ使用量など)と統計値IDを対応させてモニタリングシステム100に通知する。
モニタリングシステム100は、稼動情報集計部300から構成情報IDと統計値IDを受け付けて、構成情報管理テーブル130の該当するレコードの構成情報XMLに統計値IDと統計値情報を格納する。これにより、計算機システム内で一意の識別子であるコンポーネントIDと統計値IDが関連づけられる。
次に、構成管理マネージャ360が仮想サーバ422の移動を実施すると、モニタリングシステム100は構成管理マネージャ360から構成情報245と構成情報生成ポリシー240を受け付けて、構成情報生成ポリシー240の内容が「交替(交替元、交替先)」であれば、構成情報245で指定された移動元のコンポーネントIDとコンポーネントIDに関連付けられた統計値IDを移動先の構成情報のコンポーネントIDに引き継がせる。これにより、コンポーネントIDに関連付けられた統計値IDも構成情報の移動先に引き継がれる。また、構成情報管理テーブル130では、構成情報の変更の履歴をリビジョンとして記録する。
稼動情報集計部300は、所定のタイミングで監視対象リソース400の監視を行い、指定された稼動情報を収集し、稼動情報を統計処理した統計値情報をモニタリングシステム100の稼動統計テーブル120に統計値IDとともに格納する。
モニタ端末350が、統計値情報をモニタリングシステム100に要求すると、モニタリングシステム100は指定された構成情報のコンポーネントIDを構成情報管理テーブル130から検索し、当該コンポーネントIDに関連づけられた統計値IDを取得する。そして、モニタリングシステム100は、統計値IDに対応する統計値情報を稼動統計テーブル120から取得して、モニタ端末350に出力する。
仮想サーバ422を物理サーバ411間で移動させても、コンポーネントIDと統計値IDはそのまま移動先の構成情報134(構成情報XML)に引き継がれるので、仮想サーバ422の統計値IDに対応する統計値情報を、移動の前後を跨いでモニタ端末350で表示することが可能となる。また、モニタ端末350が構成情報の履歴をモニタリングシステム100に要求すると、移動の前後の構成情報の履歴をモニタ端末350に出力することができる。
以下図3〜図30までの例では、仮想サーバが物理サーバ間を移動するケースについての実施の形態を示す。
<モニタ情報データベース内の各種テーブル>
図3は稼動統計テーブル120の構成例である。統計情報管理部190が管理する統計値を格納するテーブルである。各レコードは統計値ID121、タイムスタンプ122および1つ以上の統計値123から構成される。ここでは統計値123として平均値124、最小値125、最大値126、標準偏差127、標本数128を選んだが、一部でも良いし、これ以外の統計値を持っていても構わない。
稼動統計テーブル120は、後述するように稼動情報集計部300が収集した監視対象リソース400の稼動情報の統計値を格納する。統計値123は、統計値ID毎に設定された単位を有し、例えば、プロセッサの使用率(%)やメモリの使用量(GB)や単位時間当たりのインタフェースのデータ転送量(I/Oトラフィック:GB/sec)などである。
図4は、構成情報管理テーブル130の構成例である。構成情報管理テーブル130は、構成管理マネージャ360から受信した構成情報245を蓄積するテーブルで、構成情報管理部200が管理する構成情報の履歴(リビジョン)を格納する。モニタリングシステム100は、起動すると構成管理マネージャ360から構成情報データベース365を受信して、現在の監視対象リソース400の構成情報を構成情報管理テーブル130に格納する。各レコードは構成情報ID135、リビジョン131、開始日時132、終了日時133、および構成情報134から構成される。構成情報を管理する手法は色々考えられるが、たとえばXML形式の構成情報データ500を作成し、そこへのリンクやファイル名をレコードに登録する方法が考えられる。終了日時133が“−”またはNULLであるレコードは、最新であることを示している。
図4の例では、構成情報ID135=1である構成情報に対して、3つのリビジョン131の構成情報が登録されており、リビジョン131=1とリビジョン131=2のレコードには終了日時133が設定されているが、リビジョン131=3のレコードには終了日時133が設定されておらず(”−”)、リビジョン131=3の構成情報が現在使用中(最新)のリビジョンであることを示す。各リビジョンに対応する構成情報XML500a、500b、500cをそれぞれ後述する図7、図8a、図8bに示す。
構成情報管理テーブル130は、構成管理マネージャ360から構成情報245を受け付けて、監視対象リソース400の構成情報を世代(リビジョン)毎に格納する。構成情報管理テーブル130と構成管理マネージャ360の構成情報データベース365は、上述したように同様の構成である。このため、構成管理マネージャ360は、新たな構成情報245yを生成すると、新たな構成情報ID135とリビジョン131=1を生成する。
なお、構成管理マネージャ360で監視対象リソース400の構成情報の履歴(世代)を管理しない場合では、モニタリングシステム100の構成情報管理部200がリビジョン131を管理すればよい。この場合、構成情報管理部200は、同一の構成情報ID135に対して新たな構成情報245を受け付けると、現在のリビジョン131をインクリメントした値を、新たな構成情報を格納するレコードのリビジョン131に最新の世代を示す値を設定する。
図5は構成情報変更履歴管理テーブル140の構成例である。構成情報変更履歴管理テーブル140は、履歴情報管理部210が管理する構成情報の履歴(リビジョン)を格納する。各レコードは履歴ID141、構成変更のあった時点のタイムスタンプ142、構成情報ID147、変更前リビジョン143、変更後リビジョン144、作業手順830へのリンク145、関連コンポーネントIDリスト146、から構成される。
履歴ID141は、構成情報管理部210が設定する値で、一意の識別子が付与される。作業手順830は構成情報変更時にどのような変更があったのかをモニタ端末350へ出力して管理者やユーザが見てわかりやすくするためのテキスト列で、構成情報の差分から自動的に生成する方法や、構成管理マネージャ360での構成変更指示時に管理者にコメントとして入力させる方法などが考えられる。関連コンポーネントIDリスト146は、該当する構成変更の影響を受けるコンポーネントIDのリストである。
図6はコンポーネント履歴管理テーブル150の構成例である。コンポーネント履歴管理テーブル150は、履歴情報管理部210が管理するテーブルで、構成変更の影響を受けたコンポーネントID151に関してのみレコードが登録される。
各レコードはコンポーネントID151、新たな構成の開始日時152、当該構成の終了日時153、構成情報ID155、リビジョン154から構成される。終了日時153が”−”あるいはNULLであるレコードは、そのリビジョンが最新であることを示す。
図6の例では、コンポーネントID151が「3」であるコンポーネントはリビジョン154が「1」から「2」に変更された時の影響は受けたが、リビジョン154が「2」から「3」へ変更されたときには構成変更の影響は受けていないため、リビジョン154=2が最新である。一方、コンポーネントID151が「5」であるコンポーネントは、リビジョン154=1が最新のまま変更の影響を受けていない。さらにコンポーネントID151が「6」であるコンポーネントは2回の構成変更の影響を共に受けているため、リビジョン154=3が最新となっている。
<構成情報XMLのツリー表現>
図7は構成情報XML500aのツリー表現の一部を抜粋した図である。図7の例は、図4に示したリビジョン131=1の構成情報134をツリー(部分木)にて表現した例である。
図7では一例としてサーバラック510を頂点とする構成ツリーを示す。サーバラック510の下にサーバシャーシ520、その下に物理サーバ411、その下に仮想サーバ422が存在している。また物理サーバ411の下に物理サーバ411の統計値情報560と、仮想サーバ422の下に仮想サーバの統計値情報550が関連づけられている。なお、サーバラック510、サーバシャーシ520と物理サーバ411の関係等のモニタリングシステム100が識別できない構成については、管理者などがモニタ端末350から設定する。
ここで仮想サーバ422の統計値情報としては、例えばOS423が取得したCPU利用率やメモリ使用量といった情報が考えられる。すなわち、サーバ仮想化部421が仮想サーバ422へ提供する仮想CPUの利用率やメモリの使用量(または使用率)、あるいは仮想I/O(HBAやNIC等を仮想化したI/Oデバイス)の利用率(転送量)等を仮想サーバ422の性能を示す統計値情報とすることができる。
一方、物理サーバ411の統計値情報としては、ハイパバイザ自身のCPU使用率やメモリ413の使用量や、I/O(HBAやNIC)の利用率(転送量)等を仮想化部421の性能を示す統計値情報といった情報が考えられる。
そして、本実施形態では、この構成情報XML500の各ノードに一意なコンポーネントID(CID)を割り当て、また各統計値情報にも一意な統計値IDを割り当てることで、構成情報変更前後での履歴や統計情報の追跡を容易にする。なお、構成情報におけるノードとしては、物理サーバ411や仮想サーバ422に付与したコンポーネントIDをノードとして扱うことができる。同様に統計値IDもノードとして扱うようにしても良い。
また、コンポーネントIDと統計値IDとを区別する必要は必ずしもなく、お互いに重ならないような値をつけて管理する方法もある。以下の例では、各テーブルのフィールド数を省略するためにコンポーネントIDと統計値IDを同一フィールドで示しているが、両者を区別するようなフィールドを追加して管理する方法もある。どちらの場合も本発明の適用に当たっては本質的な差異を生じない。
図8aは構成情報XML500aから仮想サーバδを移動させた後の構成情報XML500bのツリー表現の一部を抜粋した図である。この構成情報XML500bは、図4に示したリビジョン131=2の構成情報134をツリーにて表現した例である。リビジョン131=1から2の移動の前後で、移動した仮想サーバδに関連するコンポーネントIDおよび統計値IDは同一であることが保証される。これにより、構成変更による移動の前後で稼動統計情報を連続的に追跡できるようになる。
すなわち、コンポーネントID=3の物理サーバAに割り当てられたコンポーネントID=6の仮想サーバを、物理サーバBへ移動したときに、物理サーバAに関連付けられた仮想サーバδのコンポーネントID=3と、当該仮想サーバの配下の仮想リソースの識別子(統計値ID)を削除し、移動する仮想サーバδのコンポーネントID=3及び当該仮想サーバδの配下の仮想リソースの識別子(統計値ID)と同一のコンポーネントIDと統計値IDを移動先の物理サーバBに割り当てる。
<割当済ID管理テーブル>
図9は構成情報関連管理部230が管理するコンポーネントIDの状態遷移図である。コンポーネントIDは、物理リソース410や仮想リソース420に構成情報関連管理部230が割り当てたモニタリングシステム100内で一意の識別子である。これらのコンポーネントIDと識別子IDは、構成情報関連管理部230が管理する割当済ID管理テーブル160に格納される。
構成情報関連管理部230が物理リソース410や仮想リソース420にコンポーネントIDを割り当てると、コンポーネントIDの状態を管理するために割当済ID管理テーブル160へと登録する。
コンポーネントIDは、まだ割り当てていない状態未割当170(テーブルに未登録のIDを含む)から、割り当てられると使用中171へと遷移する。また、待機用のコンポーネントなどのためにIDを予約した場合は予約済あるいは待機中172へと遷移する。使用中171と待機中172の間は、障害や移動などによる交替があった場合、お互いの間を遷移することがある。コンポーネントの削除や廃棄が行われた場合、そのIDは別の目的で再利用されないように回収済173へと遷移する。新たなIDの値の生成方法としては、たとえば単調増加な自然数を使用する方法が考えられる。
図10は図7の構成情報XML500aに相当する割当済ID管理テーブル160の構成例である。各レコードはコンポーネントIDまたは統計値ID161、構成情報ID162、リビジョン163、XMLパス表現164、親コンポーネントID165、コンポーネントIDの状態166といったフィールドから構成される。
ここでXMLパス表現164は、XMLツリーにおける各ノードを特定するために必要な情報を含む。図10の例ではサーバラック510のID、サーバシャーシ520のID、物理サーバ411のID、仮想サーバ422のIDを順に指定する方法を示したが、この他にも物理サーバ411や仮想サーバ422にユーザがつけたサーバ名を指定する方法や、稼動するゲストOSのUUIDを指定する方法などが考えられる。いずれの方法でもノード(各コンポーネント)が一意に特定できさえすれば本発明の適用に当たっては差異を生じない。
<構成情報XMLのXML表現>
図11は図7に示した物理サーバ=「A」の仮想サーバδを物理サーバ「B」へ移動する前の構成情報XML500aのXML表現である。サーバラック510を示すServerRackノード、サーバシャーシ520を示すServerChassisノード、物理サーバ530を示すPhysicalServerノード、仮想サーバ540を示すVirtualServerノードが階層的にツリー構造をなしており、各ノードの属性としてコンポーネントIDを示すcomponent_idを持つ。またVirtualServerノードの下にはサーバ名を示すServerName、CPU利用率を示すCPUUsage、メモリ使用量を示すMemoryUsageの各ノードがあり、CPUUsageおよびMemoryUsageノードは統計値IDを示すstatistics_id属性を持つ。なお、コンポーネントIDと統計値IDを特に区別せずに管理する場合はstatistics_id属性の代わりにcomponent_id属性を持たせる実装も考えられる。どちらの場合も本質的な差異は生じない。
図12は図8aに示した物理サーバ=「A」の仮想サーバδを物理サーバ「B」へ移動する際の構成情報XML500aと構成情報XML500bを生成する場合のXML表現での変更手順を示した図である。構成情報XML500aにおける仮想サーバδ配下のノードを、構成情報XML500bでは物理サーバAの配下から物理サーバBの配下へと移動させる。この処理において、仮想サーバδを含む配下のコンポーネントIDおよび統計値IDは同一のIDを引き継ぐことで、移動前後における稼動統計情報や変更履歴の追跡を可能とする。
図13は、仮想サーバδの移動後の割当済ID管理テーブル160を示す。移動の結果、仮想サーバδ(コンポーネントID161=6)および配下のCPU利用率(統計値ID161=406)とメモリ使用量(統計値ID161=407)は、移動によりXMLパス表現164が変更となったため、新たなエントリとして追加される。
<フローチャート>
以下、各部で行われる処理のフローチャートについて説明する。
図14は、モニタリングシステム100の構成情報関連管理部230で行われる処理のフローチャートを示す。この処理は、例えば、構成情報関連管理部230が構成管理マネージャ360から構成情報Xと新たな構成情報Yからなる構成情報245と構成情報生成ポリシー240を受け付けたときに開始される。構成情報245は、構成情報生成ポリシー240の内容が移動(マイグレーション)の場合、構成情報Xが移動元の構成情報245xであり、構成情報Yが移動先の構成情報245y、換言すれば未割当の構成情報である。また、構成情報生成ポリシー240の内容が構成情報の追加の場合、構成情報Xが追加先の構成情報245xであり、構成情報Yが追加する構成情報245yとなる。
構成情報関連管理部230では、コンポーネントID161を割当済の構成情報Xと未割当の構成情報Y、および構成情報生成ポリシー240から、構成情報Yに対するコンポーネントID161の割当を行う。構成情報関連管理部230は、既割り当ての構成情報Xについて、割当済ID管理テーブル160からコンポーネントIDを読み込んでおく。
構成情報関連管理部230は、まず、各構成情報(構成情報X、Y)の頂点ノードnを引数としてこの処理ルーチンが呼ばれる(ステップ1000)。なお、頂点ノードnは、構成情報X及び構成情報Yをそれぞれ部分木x、yとして解析したときにルートとなるノードである。部分木xまたは部分木yの解析は、構成情報関連管理部230が行っても良い。
次に構成情報関連管理部230は、上記のように受け取った引数nを元にして後述するようなID割当処理分岐1010を呼び出す。構成情報関連管理部230は、ID割当処理分岐1010を実行し、この結果として得たノードと、さらに配下の全子ノードに対してそれぞれの子ノードを引数としてID割当処理1000を再帰的に呼び出す(ステップ1020〜1040)。
ID割当処理分岐1010を呼び出した結果の全子ノードに対する割当済ID管理テーブル160に、ノードn自身の割当リストを追加して、割当処理の呼び出し元へと返答し、戻る(ステップ1050〜1060)。
図15にID割当処理分岐1010のフローチャートを示す。
構成情報関連管理部230は、変更前のノード241を、ノードkとし、変更後のノード242をノードnとし、構成情報生成ポリシー240を読み込んで、構成の重複を許可しないか否かを判定する。構成情報生成ポリシー240が「重複しない割当」を指定している場合(ステップ1110)、ステップ1190へと分岐する。そうでない場合はステップ1120へと進む。
ステップ1120では部分木x、y共にノードnが存在するか否かを判断する。存在する場合はステップ1150へと進む。部分木x、y共にノードnが存在しない場合ステップ1130へと進む。
ステップ1130では、未割当の部分木yにのみノードnが存在するか否かを判断する。存在しない場合はステップ1140へ、存在する場合はステップ1160へと分岐する。
ステップ1140では、割当済の部分木xにのみノードkが存在するか否かを判断する。割当済の部分木xにのみノードnが存在しない場合はID割当処理分岐1010を終了する(ステップ1250)。存在する場合はステップ1170へと進む。
ステップ1150では、構成情報生成ポリシー240に従い、ノードnがノードkの交替の対象であるか否かを判断する。交替の対象である場合はステップ1210へと進む。交替の対象で無い場合は部分木xのノードnと同じIDを部分木yのノードnにも割り当てて(ステップ1180)、ID割当処理分岐1010を終了する。
ステップ1160では、ノードnがノードkの移動先であるか否かを判定する。ノードnがノードkの移動先である場合はステップ1230へ進む。ノードnがノードkの移動先で無い場合は部分木yのノードnに新たなIDを割り当て、割り当てリストに追加し、ID割当処理分岐1010を終了する。
ステップ1170では、ノードkが移動の対象であるか否かを判定する。ノードkが移動の対象である場合はID割当分岐処理1010を終了する(ステップ1250)。ノードkが移動の対象で無い場合は部分木xのノードkの状態を「回収済」に変更し(ステップ1200)、ID割当処理分岐1010を終了する。
ステップ1210では、交替元ノードをkとして部分木yのノードnのIDとして、部分木xのノードkのIDと状態を引き継ぎ(ステップ1210〜1220)、ID割当処理分岐1010を終了する。
ステップ1230では、部分木xのノードkを部分木yのノードnへと部分木ごと移動する。この処理は図12で示したようなXMLツリーの操作によって行われる。さらに部分木xのノードkのIDを部分木yのノードnへと割り当て(ステップ1240)、ID割当処理分岐1010を終了する。
上記処理により、構成情報関連管理部230は、新規の構成情報Yに対しては、コンポーネントID161を割り当てて、XMLパス表現164を生成して割当済ID管理テーブル160に格納する。一方、構成情報Yが構成情報Xの変更の場合には、構成情報関連管理部230は、該当するコンポーネントID161のリビジョン163を更新し、構成情報XのコンポーネントIDを引き継いで変更後の構成情報YのXMLパス表現164を生成して割当済ID管理テーブル160に格納する。
以上の処理によって、仮想サーバ422がマイグレーションなどの構成変更によって移動した場合でも、コンポーネントIDを構成変更後にも同一のコンポーネントIDを引き継ぐことが可能となって、コンポーネントIDに関連づけられた統計値IDも引き継ぐことができる。これにより、構成変更の前後で、関連する統計情報を連続的に集計することが可能となる。
<稼動統計情報表示>
図16に稼動統計情報表示時に統計情報管理部190で行われる処理のフローチャートを示す。この処理は、統計情報GUI制御部250がモニタ端末350から統計情報の要求を受け付けたときに実行される。この要求は、統計情報表示期間の開始日時を変数bに格納し、終了日時を変数eに、コンポーネントの構成情報IDを変数dに、コンポーネントIDを変数cに格納する。
まずステップ1300で、統計情報管理部190は統計情報GUI制御部250から統計情報表示期間の開始日時bと終了日時eを得る。ステップ1310へ進む。
ステップ1310では、構成情報管理部200が構成情報GUI制御部260から、指定されたコンポーネントの構成情報ID135=dとコンポーネントID=cを得る。ステップ1320へ進む。
ステップ1320では、履歴情報管理部210が、統計情報管理部190および構成情報管理部200から得た変数b、e、d、cを元に、コンポーネント履歴管理テーブル150から<d、c>をキーとして、開始日時152<eかつ終了日時153≧bとなるリビジョン154のリスト(R1、R2、...、Rn)を得る。ここで各リビジョンの開始日時152を(b1、b2、...、bn)、終了日時153を(e1、e2、...、en)とする。eiは最新リビジョンの場合NULLの場合もある。ステップ1330へ進む。
次に得られた各リビジョンRi(ただし、i=1〜n)について、ステップ1340〜1390までを繰り返す。
ステップ1340では、構成情報管理テーブル130から、構成情報ID135=d、リビジョン131=Riであるレコードを選び、構成情報管理テーブル130の構成情報134から構成情報XML500を取得する。ステップ1350へ進む。
ステップ1350ではコンポーネントIDが変数cの配下の統計値IDのリスト(s1、 s2、 ... sm)を得る。ステップ1360へ進む。
次に得られた各sjに対してステップ1370〜1380を繰り返す。
ステップ1370では、稼動統計テーブル120から統計値ID=sjをキーにして、bi≦タイムスタンプ122<eiとなるレコードのタイムスタンプと値の組<t、v>のリストを得る。ステップ1380に進む。
ステップ1380では、稼動情報GUI制御部250に<t、v>のリストを送り、これによりモニタ端末350の表示装置にグラフを出力する。
以上が稼動統計情報表示時のフローチャートである。
上記処理により、統計情報管理部190は、同一のコンポーネントIDに関連づけられた統計値IDについて、マイグレーションなどの構成変更があった場合にも、構成変更の時点を跨いで連続的に表示させることが可能となる。
以下図17〜図23を用いて、構成情報と稼動統計情報を連携させる処理について示す。
図17は本発明を適用したモニタリングシステム100のモニタ端末350に表示される稼動統計モニタ画面の一例である。
稼動統計モニタ画面は、図中左側に表示期間を表示する部分700とラックやシャーシといった構成管理を行う部分710を備える。また、図中右側には構成情報および稼動統計情報を表示するエリアがあり、図中上部から物理構成情報(物理リソース410の構成情報)を表示する物理構成情報表示エリア720、仮想構成情報(仮想リソース420の構成情報)を表示仮想構成情報表示するエリア730、稼動統計情報を表示する稼動統計情報表示エリア740から構成される。
物理構成情報表示エリア720と仮想構成情報表示エリア730および稼動統計情報表示エリア740は連動しており、物理構成情報エリア720において指定されたコンポーネント(ここでは物理サーバA)についての仮想構成情報の詳細が仮想構成情報表示エリア730に表示される。また、この場合、物理サーバAに対応した稼働統計情報が740に表示される。
ここで仮想構成情報表示エリア730の仮想サーバαをモニタ端末350の入力装置で指定した場合、仮想サーバαに関連する稼働統計情報のみが抽出されて稼働統計情報表示エリア740へと表示される。このように、着目するコンポーネントが物理コンポーネントか仮想コンポーネントかに応じて、稼働統計情報740に表示されるグラフの種類が変わる点が本モニタリングシステム100の特徴の一つである。
以下、図18〜図23の例では、図7、図8aで示したように仮想サーバδが物理サーバAから物理サーバB上へとある時刻に移動したという前提で説明する。
図18は図17に示した物理構成情報表示エリア720の物理サーバAを、モニタ端末350の入力装置から指定した場合の稼動統計モニタ画面の表示例を示す。稼働統計情報表示エリア740には指定した物理サーバAのCPU利用率として、物理サーバA上の各仮想サーバの使用している内訳のグラフが表示される(実際にはこの他にサーバ仮想化部421分の使用率などもあるが、ここでは説明の簡略化のために省略する)。統計期間の途中で仮想サーバδは物理サーバAから移動して行ったため、仮想サーバδ分が途中から消えている。また稼働統計情報表示エリア740のタイムライン741は仮想サーバδが物理サーバA上にある時刻を示している。このため、仮想構成情報表示エリア730には、仮想サーバδが物理サーバA上に載っている構成図が表示される。
なお、このようにタイムライン741をカーソル等で示す方法の他に、常に注目するタイムラインが中央に来るように表示期間の方を変える方法も考えられるが、どちらの方法でも本発明の本質には影響しない。
次に図18の状態で稼動統計モニタ画面に表示されている物理構成情報表示エリア720の物理サーバBを指定した場合の表示例を図19に示す。
図19の稼働統計情報表示エリア740には、物理サーバBの内訳が表示されているが、仮想サーバδは統計期間の途中から出現している。またタイムライン741は仮想サーバδが物理サーバA上にある日時を指しているため、仮想構成情報表示エリア730にはまだ仮想サーバδが無い状態の物理サーバBが表示される。
図20は、図18の状態から稼動統計モニタ画面に表示されているタイムライン741を、モニタ端末350の入力装置により操作して仮想サーバδの移動後にずらした場合の表示例である。この時のGUIの操作としては、タイムライン741をカーソルでクリックしてそのままドラッグして右側にずらす操作や、稼働統計情報表示エリア740の移動時刻(点線で表示)より右側で右クリックメニューによって選択する、などの操作が考えられる。図18と異なり、図20ではタイムライン741を仮想サーバδの移動後の時刻にしたために、仮想構成情報表示エリア730には仮想サーバδが存在しない構成図が表示される。
図21は図19の状態から稼動統計モニタ画面に表示されていたタイムライン741を仮想サーバδ移動後の時刻まで動かした場合の表示例である。こちらは物理サーバB上に仮想サーバδが移動した後なので、仮想構成情報表示エリア730には仮想サーバδが存在している構成図が表示される。
図22は図21の状態から稼動統計モニタ画面に表示されていた仮想構成情報表示エリア730の仮想サーバδを指定した場合の表示例である。仮想サーバδに関する稼動統計情報(ここではCPU利用率とI/Oトラフィックを例にとった)が稼働統計情報表示エリア740に表示される。本発明を適用することで、仮想サーバの移動の前後で稼働統計情報を連続的に追跡できる。
すなわち、仮想サーバ422をマイグレーションやフェイルオーバなどで他の物理サーバ411へ移動しても、当該仮想サーバ422に割り当てられたコンポーネントIDを移動先へ引き継ぐことで、当該コンポーネントIDの配下の統計値IDも移動先に引き継がれるので、仮想サーバ422の移動の有無にかかわらず、仮想サーバ422の稼働に関する統計情報を連続に追跡することが可能となる。これにより、仮想サーバ422のリソースのボトルネックを検出するまでの時間を前記従来例に比して大幅に短縮でき、多数の計算機を備えた環境における運用管理の効率を改善できるのである。
<構成変更履歴表示>
図23に変更履歴情報表示時の履歴情報管理部210で行われる処理のフローチャートを示す。この処理はモニタ端末350から変更履歴の表示要求があったときに実行される。
ステップ1410では、履歴情報管理部210が構成情報GUI制御部260から、モニタ端末350で指定されたコンポーネントの構成情報IDを変数dに格納し、コンポーネントIDを変数cに格納する。ステップ1420へ進む。
ステップ1420では、履歴情報管理部210がコンポーネント履歴管理テーブル150からコンポーネントの構成情報IDを格納した変数dおよびコンポーネントIDを格納した変数cをキーとして、リビジョン154のリスト(R1、R2、...、Rn)を抽出する。この時各リビジョンの開始日時152を(b1、b2、...、bn)、終了日時153を(e1、e2、...、en)とする。ステップ1430へ進む。
以下、履歴情報管理部210は、各リビジョンRi(ただし、i=1〜n)に対して、ステップ1430〜ステップ1480を繰り返す。
ステップ1440では、履歴情報管理部210が構成管理テーブル130から、構成情報ID135=dでかつリビジョン131=Riであるレコードを検索し、対応する構成情報XML500を取得し、ステップ1450へ進む。
ステップ1450では、履歴情報管理部210が取得した構成情報XML500を元にリビジョンRiの構成情報のサムネイル800をモニタ端末350に出力し、ステップ1460へ進む。
ステップ1460では履歴情報管理部210は、リビジョンRiが最新リビジョン(対応するei=NULL)か否かを判定する。最新リビジョンだった場合は、ステップ1490へ進む。そうでない場合はステップ1470へ進む。
ステップ1470では、モニタ端末350に出力リビジョンRiとリビジョンRi+1のサムネイル800の間に構成変更アイコン810をモニタ端末350に出力し、ステップ1480へ進む。
ステップ1480では、履歴情報管理部210が構成情報変更履歴管理テーブル140から、構成情報ID147=d、変更前リビジョン143=Ri、変更後リビジョン144=Ri+1に相当するレコードを検索し、対応する作業手順830を呼び出す。構成変更アイコン810のリンク先820として出力の準備をする。ここで用意されたリンク先の構成変更図820は、モニタ端末350に出力する構成変更アイコン810をクリックした時にポップアップや別ウインドウとして表示しても良いし、構成変更アイコン810上にマウスオーバーされた時にポップアップとして表示しても良い。ステップ1490へ進む。
ステップ1490では、履歴情報管理部210はリビジョンRiがまだ残っている場合、ステップ1430に戻って繰り返す。全てのリビジョンについて処理が完了した場合は完了する。
以上が変更履歴表示時のフローチャートである。
次に図24〜図26を用いて、モニタリングシステム100の変更履歴表示機能の処理について説明する。
変更履歴表示機能はモニタリングシステム100のモニタ端末350に表示される物理構成情報表示エリア720または仮想構成情報表示エリア730の任意のコンポーネントから右クリックメニュー等で呼び出すことができる。また、稼働統計情報表示エリア740の構成変更を示す時刻上(図18〜図22の点線の位置)や、グラフの特定の領域を指定して右クリックメニューで呼び出せるとしても良い。また以下の例では図4に示した3つの構成情報500a〜500cのリビジョンが登録されており、図7、図8a、図8bで示したように仮想サーバδが物理サーバAから物理サーバB、物理サーバBから物理サーバCへと移動したという前提で説明する。
図24は物理構成情報表示エリア720の物理サーバAをモニタ端末350から指定して構成変更履歴を呼び出した場合の図である。物理サーバAは構成情報リビジョン1からリビジョン2への変更の影響は受けているが、構成情報リビジョン2から3への変更の影響は受けていないことが、コンポーネント履歴管理テーブル150よりわかる。
そこで構成変更履歴表示機能では2つのリビジョンがサムネイル800−A1、800−A2の形で表示され、その間に構成変更アイコン810−Aが表示される。サムネイル800をクリックあるいは右クリックメニューで選択することで、当該リビジョンの構成情報がメインの構成情報表示エリア720や730に反映され、あるいは別ウインドウとして表示される。また構成変更アイコン810をクリックあるいはマウスオーバーすることで、作業手順830を含むリビジョン間の構成変更情報820がポップアップあるいは別ウインドウで表示される。
図25は仮想サーバδに関して構成変更履歴表示をモニタ端末350で行った場合の図である。仮想サーバδはリビジョン1、2、3の全てに変更の影響を受けていることがコンポーネント履歴管理テーブル150よりわかる。そこでリビジョン1、2、3に相当する構成情報サムネイル800−B1、800−B2、800−B3がそれぞれモニタ端末350に表示され、図示のようにそれらのリビジョンの間に構成変更アイコン810−B1、810−B2が表示される。
図26は仮想サーバαに関して構成変更履歴表示をモニタ端末350で行った場合の図である。仮想サーバαはリビジョン2、3に変更した影響を受けていないことがコンポーネント履歴管理テーブル150よりわかる。そこでリビジョン1に相当する構成情報サムネイル800−C1のみがモニタ端末350に表示され、構成変更アイコン810は表示されない。
以上のように、コンポーネントID単位で構成情報や統計情報の履歴を管理することによって、コンポーネント単位で構成変更履歴のフィルタリングを行えるため、着目しているコンポーネントが影響を受けた構成変更のみに着目することができ、稼働状況分析の際に必要となる構成変更の影響範囲の追跡が容易になる。
<稼働情報収集部の動作>
以下図27〜図30を用いて稼働情報収集部300の詳細動作を示す。
図27は稼働情報収集部300の構成を示したブロック図である。稼働情報収集部300は稼働情報収集パラメータ310を保持し、稼働情報収集パラメータ310の内容はパラメータ設定インタフェース345を介してモニタ端末350から設定される。
稼働情報収集パラメータ310の内容は、監視対象リソース400の通常の運用では最初に収集する項目を決めて設定された後は、特に監視対象リソース400に大きな変更が加わらない限り変更されることはない。稼働情報収集部300は、さらに稼働統計情報収集パラメータ310に従って収集コマンドを実行する収集コマンド実行320、および収集コマンドの実行結果である稼動情報を受け取って処理する収集コマンド結果取得部330、さらに収集した稼動情報の中で予め設定した条件に合致した結果から統計値を生成し、稼働統計テーブル120へと格納する稼働統計値登録部340、およびタイマ341から構成される。
図28は稼働情報収集部300が使用する稼働情報収集パラメータ310の定義である。1つのパラメータの行(またはレコード)は、構成情報ID311、パラメータ生成式312、収集コマンド313、モニタ間隔314、およびフィルタ条件315、統計値情報生成式316、統計値ID検索式317からなる統計情報生成リスト318が1つ以上、から構成される。稼働情報収集パラメータ310の内容については、上述のように管理者などが操作するモニタ端末350から設定される。構成情報ID311には、図4の構成情報管理テーブル130の構成情報ID135に対応する値が格納される。収集コマンド313には、対象となる構成情報ID311に対して実行させる稼動情報の収集コマンドを格納する。モニタ間隔314には、モニタ端末350で設定する稼動情報の収集周期が格納される。
モニタ端末350は、パラメータ設定インタフェースに対して統計値の生成を要求し、構成情報管理テーブル130の構成情報ID135を指定して、上記各パラメータを設定する。設定されたパラメータは新たなレコードとして稼働情報収集パラメータ310に格納される。稼働情報収集部300は、構成情報IDと統計値IDをモニタリングシステム100に通知し、構成情報管理テーブル130の構成情報500に統計値IDが格納される。
図29に稼働情報収集部300で行われる処理のフローチャートを示す。
稼働情報収集部300は、予め設定された稼働情報収集パラメータ310をパラメータとして起動される。ここでは説明を簡易にするため、稼働情報収集パラメータ310の各行ごとに別パラメータを与えて起動するとしているが、一つのプログラムで複数の収集コマンドを発行できるようにしても良い。
ステップ1500で稼働情報収集部300のプログラムが起動され、ステップ1510へ進む。
ステップ1510では、稼働情報収集部300は構成情報ID311をキーにして構成情報管理テーブル130から最新のリビジョン131を持つレコードの構成情報XML500を取得し、ステップ1520へと進む。
ステップ1520では、稼働情報収集部300が構成情報XML500からパラメータ生成式312に従って、収集コマンド313の起動に必要なパラメータを補完し、ステップ1530へ進む。
ここでパラメータ生成式312は、構成情報XML500に含まれるインスタンスを特定するのに必要なパラメータ(サーバ名やIPアドレス等)を指定するための式であり、一例としてはXMLパス形式で指定する方法が考えられる。例えば図11で示したXML表現から、仮想サーバのサーバ名を抽出するためのXMLパス形式の一例は”/ServerRack/ServerChassis/PhysicalServer/VirtualServer/ServerName”となる。
一般にパラメータ生成式312にマッチするノードは一つの構成情報XML500に複数存在するために、生成されるパラメータは複数のリストとなる。
ステップ1530では、ステップ1520で生成されたパラメータの数に応じて稼働情報収集部300のインスタンスを生成する。インスタンスを複製する方法としては例えばUnix(登録商標)のforkシステムコールを使って複製する方法や、スレッドを分ける方法などが考えられる。稼働情報収集処理を並行に実行することさえできれば必ずしもプロセスやスレッドを複製する必要は無い。ステップ1540に進む。
ステップ1540では、収集コマンド実行部320が生成されたパラメータを引数にして収集コマンド313を監視対象リソース400に対して実行する。収集コマンド313としては、稼働情報を収集するプロトコルであるSNMPに従ったコマンドや、予めインストールしたエージェントに対する通信、あるいはリモートシェルなどを使って稼働状態を取得するコマンド(Linux(登録商標)でのvmstatやiostatなど)を発行する方法などが考えられる。ステップ1550へ進む。
ステップ1550では、収集コマンド結果取得部330がステップ1540で実行した収集コマンド313の結果をパイプ(標準出力)あるいはファイル経由で取得する。ステップ1560へ進む。
ステップ1560では、パラメータとして与えられたフィルタ条件315と統計値情報生成式316と統計値ID検索式317の組からなる稼働情報生成リスト318のそれぞれについて、ステップ1570〜ステップ1590までを繰り返し実行する。
ステップ1570では、得られた結果がフィルタ条件315に一致しているかを判断する。フィルタ条件315に一致していない場合は集計対象に該当する統計値は含まれていないため、ステップ1590へ進む。フィルタ条件315に一致していた場合は稼働統計値登録部340がステップ1580の統計値登録処理を行ってからステップ1590へと進む。
ステップ1580の統計値登録処理については後に図32にて詳細に説明する。
ステップ1590では、フィルタ条件315と統計値情報生成式316と統計値ID検索式317の組の統計情報生成リスト318の残りについて、ステップ1560に戻り繰り返す。全て完了した場合ステップ1600へと進む。
ステップ1600では、モニタ間隔314が経過しているか否かをタイマ341をチェックし、経過するまで待つ。経過後ステップ1540へと戻る。
以上が稼働情報収集部300の動作を示すフローチャートである。
続いて図30に稼働統計値登録部340で行われる統計値登録処理1580の詳細なフローチャートを示す。
ステップ1610で、稼働統計値登録部340は、稼動情報収集パラメータ310の統計情報生成式316に従い、統計値を算出する。ここで、統計値とは、稼働統計テーブル120に登録する統計値123に対応する統計値であり、平均値や最小値、最大値、標準偏差あるいは標本数、などから構成される。1つの値のみから統計値を算出する場合は、平均値=最小値=最大値となり、標準偏差は0、標本数は1とする。稼動情報収集パラメータ310の統計情報生成式316は、ステップ1550で取得した収集コマンド313の出力結果から、統計値を生成する式である。統計情報生成式316は、パーセントの数字の場合に100で割るといった処理や、2つの値の平均や合計を求めるといった処理が考えられる。ステップ1620へ進む。
ステップ1620では、構成情報XML500から統計値ID検索式317に従って統計値IDを取得し変数sに格納する。ここで、統計値ID検索式317とは、構成情報XML500のインスタンスから、対応する統計値ID(構成情報XMLノード上でインスタンスノードの配下にあるケースが多い)を求める式であり、一例としてはXMLパス形式を使うことが考えられる。たとえば、図11の構成情報XML500aの場合、仮想サーバのインスタンスを示す式が”/ServerRack/ServerChassis/PhysicalServer/VirtualServer”であり、その仮想サーバのCPU利用率の統計値IDを示すXMLパス式は”./CPUUsage@statistics_id”となる。ステップ1630に進む。
ステップ1630では、タイマ341からタイムスタンプtを取得し、ステップ1640へ進む。
ステップ1640では、稼働統計テーブル120に、統計値ID121=s、タイムスタンプ122=t、統計値123=(v1、v2、...、vn)を登録する。
以上で統計値登録処理1580が完了する。
以上、仮想サーバが移動する際の実施の形態例を示した。
<階層関係が変化する例>
なお、ここでは説明を簡易にするために仮想サーバ422がある物理サーバ411上から別の物理サーバ411上へと移動する例を示したが、本発明の適用によれば、構成情報の階層関係に依存しないコンポーネントIDや統計値IDによる構成要素の管理が可能である。従って、物理サーバ411上の業務を仮想サーバ421上に移動して集約するP2Vと呼ばれる操作や、逆に開発・テスト環境は仮想サーバ421上で行い本番環境は性能が保証できる物理サーバ411上に移動するV2Pと呼ばれるような、階層関係を跨いでの構成情報の変更があった場合にでも本発明は適用できる。また、仮想サーバ421上にさらに仮想マシンモニタを動作させ、その上にさらに複数の仮想サーバ421を立ち上げるような多重の仮想サーバ環境を想定した場合に、仮想サーバ421を仮想の仮想サーバ上に移動させたり、あるいは仮想の仮想サーバを仮想サーバ上に移動させたりといった操作に対しても、本発明は適用できる。
<構成情報生成のバリエーション>
以下図31〜図34で、仮想サーバ421の移動以外の構成情報管理の適用例を示す。
図31は、昼夜切替システムにおける構成情報管理テーブル130の例を示す。このシステムでは、例えば昼間はオンライン処理、夜間はバッチ処理のように、同一の計算機リソース上に全く異なる業務を載せて切り替えて運用している。
本例では毎日午前6時から午後9時までは昼間の処理(構成情報ID135=1、構成情報134=500d)を行い、午後9時から翌朝6時までは夜間の処理(構成情報ID135=2、構成情報134=500e)を行う。
このように全く異なる業務を同一計算機リソース上で切り替えて使用する場合に、たとえ同一の物理サーバ上にある同一の仮想サーバであっても、これら複数の業務が混じっているとすると、それらの稼働情報を混ぜて統計値(平均や最大・最小)を計算してしまうことに意味がなくなってしまう。
そこで、このような異なる業務に対応する構成情報に対しては異なる構成情報ID135を付加し、構成情報生成ポリシー240として「重複しない割り当て」を指定することにより、それらの構成情報XML500におけるコンポーネントID及び統計値IDが重複しないように管理を行う。
図32に、図31の昼夜切替システムにおける割当済ID管理テーブル160を示す。この表で例えばコンポーネント/統計値ID161=5の行と505の行を比較する。XMLパス表現164を比較すると、どちらもラックID=1配下のシャーシID=1配下の物理サーバA配下の仮想サーバαを指していて、同一の計算機リソースを使用していることがわかる。しかし構成情報ID162およびコンポーネント/統計値ID161が異なる値となっているため、稼働統計情報および構成変更履歴情報はそれぞれの構成で重複することなく管理される。
図33は、待機系切替ケースにおける構成情報管理テーブル130の例を示している。このシステムでは、3つの物理サーバ上で稼働している複数業務の現用系に対して、2つの物理サーバ上のリソースが待機系として用意されており、現用系の障害の際には待機系リソースが切り替わって業務を行う。この図の例では’09/11/04の02:57:14に障害が起こり、待機系に切り替わった構成500gへと切り替わったことを示している。
図34は、図33の待機系切替ケースにおける割当済ID管理テーブル160を示す。構成情報ID162=1、リビジョン163=1である項目のうち、状態166が「待機中」となっているリソース(コンポーネント/統計値ID161=503、505、507など)は待機系のために予約されているリソースである。
障害発生時には構成情報生成ポリシー240として、障害を起こした現用系のコンポーネントIDと待機系のコンポーネントIDの間で「交替」が指定される。従って新たな構成情報ID162=1、リビジョン163=2が生成される場合に、現用系と待機系のIDの交換が行われる。たとえば構成情報ID162=1、リビジョン163=1のうち、仮想サーバαの持つコンポーネント/統計値ID161は5、仮想サーバεが持つコンポーネント/統計値ID161は505である。
一方、交替後の構成情報ID162=1、リビジョン163=2になると、仮想サーバαの持つコンポーネント/統計値ID161は505、仮想サーバεが持つコンポーネント/統計値ID161は5となっており、仮想サーバα⇔仮想サーバε間で交替が起こったことがわかる。仮想サーバだけでなく、配下の統計値の持つ統計値IDや、親コンポーネントID165、状態166も交替により引き継がれている。
以上が、本発明の第一の実施の形態の説明である。
<変形例1>
続いて図35〜図36を用いて本発明の第一の実施例の第一の変形例を示す。
図35は第一の変形例の全体構成を示した計算機システムのブロック図である。前記第一の実施形態との違いは、既存のモニタリングシステム950が監視対象リソース400の稼働統計情報を取得しており、本発明によるモニタリングシステム100は構成情報・統計情報変換部900を介して間接的に既存のモニタリングシステム950と接続している点である。
本変形例では、既存のモニタリングシステム950により採取された稼働統計情報と構成情報の履歴を、構成情報・統計情報変換部900によって時系列順に整理し、複数構成情報間のリソースの関連付けを行うことで、モニタリングシステム100により構成変更を挟んでの稼働統計情報の参照や変更履歴の追跡を容易にすることを想定している。
図36は構成情報・統計情報変換部900の詳細を示したブロック図である。既存のモニタリングシステム950内の既存の稼働統計情報960を吸い出し、構成情報の関連付けを行った変換をした上で稼働統計テーブル120に格納する稼働統計情報変換部910、既存のモニタリングシステム950内の既存の構成情報970を変換して構成情報管理テーブル130に格納する構成情報変換部920、稼働統計情報・構成情報の変換におけるパラメータを設定する変換パラメータ930、および変換パラメータ930を設定するためのパラメータ設定インタフェース940から構成される。
パラメータ設定インタフェース940はモニタ端末350と接続される。この変形例により、例えば既存のモニタリングシステム950の稼働統計をテキスト形式(CSV形式など)に変換した上で、構成情報を考慮したIDの変換を行い、モニタリングシステム100に取り込むことで、本発明による効果である稼働統計情報の追跡や構成情報履歴の追跡が容易になる。
以上が第一の実施形態の第一の変形例である。
<変形例2>
図37〜図40で第一の実施例の第二の変形例について説明する。
図37は第二変形例におけるモニタ情報データベース110を示している。前記第1実施形態の図2と比べると、構成関連管理テーブル180が追加されている。
図38aは第二変形例における構成情報管理テーブル130を示し、図39は第二変形例における稼働統計テーブル120の例を示している。
図38によれば、’09/11/11 17:00:00を境にリビジョン131=1の構成情報とリビジョン131=2の構成情報の2つの構成情報が存在する。図38b、図38cはそれぞれのリビジョンに対応する構成情報XML500の木構造を示している。図39は、第二変形例における稼動統計テーブル120を示し、構成変更の前後の統計値がレコードとして記録されている。ここで統計値ID121は、406と612という異なる値である。従って、これだけの情報では、構成変更前後の2つのレコードが同一の業務に関連する情報なのか、異なる情報なのかは判別できない。
図40は構成関連管理テーブル180の構成例である。構成関連ID181は、レコードが登録される度にインクリメンタルに増えていくインデックスである。構成情報ID182とリビジョン183は構成情報管理テーブル130の構成情報ID135とリビジョン131に相当する。統計値ID184は、稼働統計テーブル120の統計値ID121に相当する。次の構成関連ID185は、構成関連管理テーブル180における次の参照先を示しており、レコード間でのリンクトリストを実現している。次の宛先が無い場合(リストの終端)はNULLで表すこととする。
このテーブルの構成関連ID181=1のレコードによれば、構成情報ID182=1、リビジョン183=1における統計値ID184=406は、構成関連ID181=41、すなわち構成情報ID182=1、リビジョン183=2、統計値ID184=612と関連していることがわかる。これにより、稼働統計テーブル120における2つのレコードが同一であることがわかる。
このように、構成変更がある度に関連のあるコンポーネントや統計値のIDの関係を構成関連管理テーブル180に登録していくことで、構成情報変更をまたいでの稼働統計情報の追跡や構成変更履歴の追跡が可能となる。
以上が第一の実施例の第二の変形例である。
<変形例3>
図44は、本発明の第1の実施形態の第三の変形例を示す物理サーバのブロック図である。
図1に示した監視対象リソース400の物理リソース410と仮想リソース420の他の例として、図44の物理サーバ411−1が複数のサーバ仮想化部421a、421b−1〜421−iを実行する構成を示す。サーバ仮想化部421a、421b−1〜421−iの他は前記図1と同様の構成である。
第1サーバ仮想化部421aは、第1の仮想化部として機能し、物理サーバ411−1のI/Oデバイス(NIC414,HBA415)を直接使用させるI/O直接割付型で構成される。第1サーバ仮想化部421aとしては、例えば、複数の論理区画を提供するハイパーバイザを用いることができる。
第1サーバ仮想化部421a上では、複数の第2サーバ仮想化部421−b−1〜421−b−iが稼動する。これら第2サーバ仮想化部421−b−1〜421−b−iは、物理サーバ411−1のI/Oデバイスの種類やリビジョンを隠蔽する仮想I/O割付型で構成される。第2サーバ仮想化部421−b−1〜421−b−iは、例えば、VMM(Virtual Machine Monitor)で構成することができる。第2サーバ仮想化部421−b−1〜421−b−iは、第1サーバ仮想化部421aが生成した論理区画上で実行される。
各第2サーバ仮想化部421−b−1〜421−b−i上では、それぞれ複数の仮想サーバ422が実行される。
上記のような監視対象リソース400に本発明を適用することで、各仮想サーバ422と第1サーバ仮想化部421a及び第2サーバ仮想化部421b−1〜421−iにそれぞれコンポーネントIDを付与することで、仮想サーバ422の移動等の構成変更をモニタリングシステム100で把握することができる。
なお、上記実施形態及び各変形例においては、物理的なサーバと、ストレージと、ネットワークおよびそれらの上で動作するソフトウェアと、仮想化を実現するサーバ仮想化部(ハイパバイザまたは仮想マシンモニタ)などを物理リソース410としたが、サーバ仮想化部などのソフトウェアを除外して物理的なサーバと、ストレージと、ネットワークを物理リソース410として管理するようにしてもよい。
また、上記実施形態及び各変形例においては、仮想サーバ422の配下に統計値情報が関連付けられている例を示したが、仮想サーバ422の配下にストレージ装置450やネットワークなどの物理リソース410が関連付けられていても同様に管理することができる。
また、上記実施形態及び各変形例においては、物理リソース410と仮想リソース420を分類したが、物理あるいは仮想であるか否かを問わずに、計算機リソースの階層構造において、各階層の構成要素に対して一意のコンポーネントIDをそれぞれ付与して、上記したように管理しても良い。
また、上記実施形態及び各変形例においては、稼動情報集計部300が計算機式により統計値情報(稼動情報)の統計値IDを付与する例を示したが、構成情報関連管理部230がコンポーネントIDと同様に統計値IDを付与するようにしてもよい。