(57)【特許請求の範囲】
【請求項１】
他のリソース管理機能との間で処理を分担してリソースを管理するリソース管理プログラムにおいて、
コンピュータを、
依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションハンドラが、前記アクションハンドラに定義された処理が作用する対象のリソース種別と、処理の種別とを含む処理の依頼内容毎に登録されたアクションハンドラテーブルを記憶する記憶手段、
少なくとも処理が作用する対象のリソース種別、処理の種別および処理の実行順を指定した処理の依頼内容が、前記他のリソース管理機能との間で共通化された共通データ構造で示された第１のアクションリクエストを受け取ると、前記第１のアクションリクエストによる依頼内容を解析し、前記第１のアクションリクエストに示される依頼内容に含まれる各処理について、処理が作用する対象のリソース種別と処理の種別とに対応する前記アクションハンドラを前記アクションハンドラテーブルから検索するアクションハンドラ検索手段、
前記アクションハンドラ検索手段で検出された前記アクションハンドラを、前記第１のアクションリクエストにおいて指定された順で起動して、前記アクションハンドラに定義された処理を実行し、前記第１のアクションリクエストに示される依頼内容が未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエストを生成し、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して前記第２のアクションリクエストを送信するアクション実行手段、
として機能させることを特徴とするリソース管理プログラム。
【請求項２】
前記コンピュータを、さらに、
前記アクションハンドラ検索手段が受け取った前記第１のアクションリクエストの内容、前記アクション実行手段における処理の実行内容、および前記アクション実行手段が送信した前記第２のアクションリクエストの内容を取得し、ログデータベースに格納するログ採取手段、
として機能させることを特徴とする請求項１記載のリソース管理プログラム。
【請求項３】
前記コンピュータを、さらに、
前記アクションハンドラ検索手段で前記アクションハンドラが検出されなかった場合、前記第１のアクションリクエストに含まれる処理の対象となる管理対象機器を管理する他のリソース管理機能に対して、前記第１のアクションリクエストと同じ依頼内容を有する第３のアクションリクエストを送信するアクションリクエスト転送手段、
として機能させることを特徴とする請求項１記載のリソース管理プログラム。
【請求項４】
コンピュータにより、他のリソース管理機能との間で処理を分担してリソースを管理するためのリソース管理方法において、
記憶手段が、依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションハンドラが、前記アクションハンドラに定義された処理が作用する対象のリソース種別と、処理の種別とを含む処理の依頼内容毎に登録されたアクションハンドラテーブルを予め記憶しており、
アクションハンドラ検索手段が、少なくとも処理が作用する対象のリソース種別、処理の種別および処理の実行順を指定した処理の依頼内容が、前記他のリソース管理機能との間で共通化された共通データ構造で示された第１のアクションリクエストを受け取ると、前記第１のアクションリクエストによる依頼内容を解析し、前記第１のアクションリクエストに示される依頼内容に含まれる各処理について、処理が作用する対象のリソース種別と処理の種別とに対応する前記アクションハンドラを、前記アクションハンドラテーブルから検索し、
アクション実行手段が、前記アクションハンドラ検索手段で検出された前記アクションハンドラを、前記第１のアクションリクエストにおいて指定された順で起動して、前記アクションハンドラに定義された処理を実行し、前記第１のアクションリクエストに示される依頼内容が未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエストを生成し、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して前記第２のアクションリクエストを送信する、
ことを特徴とするリソース管理方法。
【請求項５】
他のリソース管理機能との間で処理を分担してリソースを管理するリソース管理装置において、
依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションハンドラが、前記アクションハンドラに定義された処理が作用する対象のリソース種別と、処理の種別とを含む処理の依頼内容毎に登録されたアクションハンドラテーブルを記憶する記憶手段と、
少なくとも処理が作用する対象のリソース種別、処理の種別および処理の実行順を指定した処理の依頼内容が、前記他のリソース管理機能との間で共通化された共通データ構造で示された第１のアクションリクエストを受け取ると、前記第１のアクションリクエストによる依頼内容を解析し、前記第１のアクションリクエストに示される依頼内容に含まれる各処理について、処理が作用する対象のリソース種別と処理の種別とに対応する前記アクションハンドラを前記アクションハンドラテーブルから検索するアクションハンドラ検索手段と、
前記アクションハンドラ検索手段で検出された前記アクションハンドラを、前記第１のアクションリクエストにおいて指定された順で起動して、前記アクションハンドラに定義された処理を実行し、前記第１のアクションリクエストに示される依頼内容が未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエストを生成し、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して前記第２のアクションリクエストを送信するアクション実行手段と、
を有することを特徴とするリソース管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はハードウェアやソフトウェアなどのＩＴ(Information Technology)リソースを管理するリソース管理プログラム、リソース管理方法、およびリソース管理装置に関し、特に他の管理システムと連携して動作可能なリソース管理プログラム、リソース管理方法、およびリソース管理装置に関する。
【背景技術】
【０００２】
データセンターなどでは、人手による作業を軽減するために、ハードウェアやソフトウェアなどのＩＴリソースを管理するリソースマネージャと呼ばれるソフトウェアが広く利用されている。リソースマネージャは複数のリソースを統合管理できる場合が多い。ただし、リソース種別ごとに管理方法が異なる。そのため、１つのリソースマネージャ単独で管理可能なリソースの種別は限定される。したがって、様々な種類のリソースを有するシステムでは、複数のリソースマネージャによってシステム全体のリソース管理が行われる。【０００３】
しかも、各リソースの機能が高度化するのに伴い、各リソースを管理するためには、専用のリソースマネージャを用いるのが一般的である。例えば、サーバ、ストレージ、ネットワークなどのハードウェア機器毎にリソースマネージャが設けられたり、各社製品向けに独自のリソースマネージャが設けられたりする。このような傾向が促進されることは、処理の分散、独自機能の最適利用などを考慮すると、しごく自然な流れである。【０００４】
複数のリソースマネージャが同一システム上で稼働していると、リソースの構成変更などの各種操作がシステムの広範囲に及ぶ場合には、リソースマネージャ間で協調動作する必要がある。【０００５】
ところが、一般的には、リソースマネージャごとに、外部とメッセージの受け渡しをするためのインタフェースが異なっている。そのため、複数のリソースマネージャを相互に連携して運用するのは困難である。例えば、新規にサーバとストレージ製品を導入したとしても、サーバ・リソースマネージャとストレージ・リソースマネージャとの間で相互接続できない。そのため、サーバ・リソースマネージャ、ストレージ・リソースマネージャそれぞれに対してまったく独立に、管理者が手動で環境設定内容を指示しなければならない。その結果、設定ミスなどにより両者を正しく接続できないといったトラブルが発生しやすくなり、サービス運用に支障をきたす原因となっていた。【０００６】
そこで、異なるアーキテクチャの元で作られたリソースマネージャが混在するヘテロ環境における複数のリソースマネージャによるシステム運用が不可欠となる。すなわち、管理対象リソースとの間で独自プロトコルで通信することが前提として設計されている専用のリソースマネージャ相互の通信技術が必要である。【０００７】
例えば、マネージャとリソースマネージャとの間に配置したエージェントで、インタフェースの違いを吸収する技術がある。この技術では、マネージャとエージェント間の通信は標準プロトコルを使い、エージェントは、受け取った操作要求をリソースマネージャ用の独自コマンドに変換する。これにより、開発負荷の低減、保守性の向上を図る手段が提案されている（例えば、特許文献１参照）。
【特許文献１】特開１０−１１３４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、エージェントによってコマンドを変更する手法では、独自プロトコルで通信を行うリソースマネージャが複数存在した場合、対応が困難となる。すなわち、独自プロトコルで通信を行うリソースマネージャが複数存在した場合、各リソースマネージャに対応するエージェントは、他のリソースマネージャに応じた全てのプロトコルに対応する必要がある。独自プロトコルで通信を行うリソースマネージャが追加される度に、他の全てのリソースマネージャのエージェントを更新するのは、システム管理効率上困難である。【０００９】
特に、今後は同一サイト内の統合運用管理から、企業内複数サイト間、企業間、さらにはグリッドによる全世界的なリソース運用へと展開されると予想される。そのため、リソースマネージャを階層化することで、大規模なシステムのリソース管理が求められる。以上のことから、階層化されたヘテロ環境において、リソース管理間の相互接続性が確保されることが望まれている。【００１０】
本発明はこのような点に鑑みてなされたものであり、各リソース管理機能における処理内容の独自性を維持しながら、階層化されたリソース管理機能同士で相互に処理を依頼できるリソース管理プログラム、リソース管理方法、およびリソース管理装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明では上記課題を解決するために、図１に示すような機能をコンピュータで実現するリソース管理プログラムが提供される。本発明のリソース管理プログラムは、他のリソース管理機能との間で処理を分担してリソースを管理するものである。このリソース管理プログラムを実行するコンピュータは、図１に示す機能を有する。【００１２】
記憶手段１ａは、依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションハンドラが処理の依頼内容毎に登録されたアクションハンドラテーブル１ａａを記憶する。アクションハンドラ検索手段１ｂは、他のリソース管理機能との間で共通化された共通データ構造で処理の依頼内容が示された第１のアクションリクエスト７ａを受け取ると、第１のアクションリクエスト７ａによる依頼内容を解析し、第１のアクションリクエスト７ａに示される依頼内容に対応するアクションハンドラをアクションハンドラテーブル１ａａから検索する。アクション実行手段１ｄは、アクションハンドラ検索手段１ｂで検出されたアクションハンドラを起動して、アクションハンドラに定義された処理を実行し、第１のアクションリクエスト７ａに示される依頼内容が未完了の場合、共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエスト７ｂを生成し、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して第２のアクションリクエスト７ｂを送信する。【００１３】
このような機能が実現されたコンピュータは、第１のアクションリクエスト７ａが入力されると、アクションハンドラ検索手段１ｂにより、第１のアクションリクエスト７ａによる依頼内容が解析され、第１のアクションリクエスト７ａに示される依頼内容に対応するアクションハンドラがアクションハンドラテーブル１ａａから検索される。すると、アクション実行手段１ｄにより、アクションハンドラ検索手段１ｂで検出されたアクションハンドラが起動され、起動されたアクションハンドラに定義された処理が実行され、第１のアクションリクエスト７ａに示される依頼内容が未完了の場合、共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエスト７ｂが生成され、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して第２のアクションリクエスト７ｂが送信される。【００１４】
また、本発明では上記課題を解決するために、コンピュータにより、他のリソース管理機能との間で処理を分担してリソースを管理するためのリソース管理方法において、記憶手段が、依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションハンドラが処理の依頼内容毎に登録されたアクションハンドラテーブルを予め記憶しており、アクションハンドラ検索手段が、前記他のリソース管理機能との間で共通化された共通データ構造で処理の依頼内容が示された第１のアクションリクエストを受け取ると、前記第１のアクションリクエストによる依頼内容を解析し、前記第１のアクションリクエストに示される依頼内容に対応するアクションハンドラを、前記アクションハンドラテーブルから検索し、アクション実行手段が、前記アクションハンドラ検索手段で検出されたアクションハンドラを起動して、アクションハンドラに定義された処理を実行し、前記第１のアクションリクエストに示される依頼内容が未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエストを生成し、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して前記第２のアクションリクエストを送信する、ことを特徴とするリソース管理方法が提供される。【００１５】
さらに、本発明では上記課題を解決するために、他のリソース管理機能との間で処理を分担してリソースを管理するリソース管理装置において、依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションハンドラが処理の依頼内容毎に登録されたアクションハンドラテーブルを記憶する記憶手段と、前記他のリソース管理機能との間で共通化された共通データ構造で処理の依頼内容が示された第１のアクションリクエストを受け取ると、前記第１のアクションリクエストによる依頼内容を解析し、前記第１のアクションリクエストに示される依頼内容に対応するアクションハンドラを前記アクションハンドラテーブルから検索するアクションハンドラ検索手段と、前記アクションハンドラ検索手段で検出されたアクションハンドラを起動して、アクションハンドラに定義された処理を実行し、前記第１のアクションリクエストに示される依頼内容が未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエストを生成し、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して前記第２のアクションリクエストを送信するアクション実行手段と、を有することを特徴とするリソース管理装置が提供される。
【発明の効果】
【００１６】
本発明では、共通データ構造で処理の依頼内容が示された第１のアクションリクエストに応じて、依頼内容に対応するアクションハンドラに定義された処理を実行し、依頼内容が未完了の場合、共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエストを他のリソース管理機能に対して送信するようにした。これにより、処理の依頼内容を定義するためのデータ構造が共通化されることで相互接続が可能となるとともに、依頼された処理の実行内容はアクションハンドラによって独自の定義が可能となる。しかも、未完了分の処理の依頼内容を第２のアクションリクエストで他のリソース管理機能に送信することで、階層化されたリソース管理機能で分散して第１のアクションリクエストに応じた処理を実行できる。【００１７】
本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
【図面の簡単な説明】
【００１８】
【図１】実施の形態に適用される発明の概念図である。
【図２】本実施の形態のシステム構成を示す図である。
【図３】本発明の実施の形態に用いる管理サーバコンピュータのハードウェア構成例を示す図である。
【図４】リソース管理機能の構成を示す図である。
【図５】システムＲＭの内部構造を示す図である。
【図６】エージェントの内部構造を示す図である。
【図７】アクション情報のデータモデルを示すＵＭＬ(Unified Modeling Language)モデル図である。
【図８】アクションハンドラテーブルのデータ構造例を示す図である。
【図９】アクションリクエストに応じたリソースマネージャの処理手順を示すフローチャートである。
【図１０】アクションリクエストに応じたエージェントの処理手順を示すフローチャートである。
【図１１】アクションリクエストの伝搬の概念を示す図である。
【図１２】ログＤＢのデータ構造例を示す図である。
【図１３】統括管理を行う管理サーバコンピュータに格納されたアクションハンドラテーブルの例を示す図である。
【図１４】サーバを管理する管理サーバコンピュータに格納されたアクションハンドラテーブルの例を示す図である。
【図１５】ネットワーク機器を管理する下位の管理サーバコンピュータに格納されたアクションハンドラテーブルの例を示す図である。
【図１６】Ｗｅｂサービスを提供可能なサーバコンピュータに格納されたアクションハンドラテーブルの例を示す図である。
【図１７】サーバ追加処理の手順を示す第１のシーケンス図である。
【図１８】サーバ追加処理の手順を示す第２のシーケンス図である。
【図１９】サーバ追加処理の手順を示す第３のシーケンス図である。
【図２０】サーバの構成情報を取得する際のアクションリクエストの伝搬図である。
【図２１】サーバの構成情報を取得する際に最初に出力されるアクションリクエストの例を示す図である。
【図２２】システムＲＭで転送された後のアクションリクエストの例を示す図である。
【図２３】サーバを追加する際のアクションリクエストの伝搬図である。
【図２４】サーバを追加する際に最初に出力されるアクションリクエストの例を示す図である。
【図２５】システムＲＭで転送された後のアクションリクエストの例を示す図である。
【図２６】システムＲＭで転送された後のアクションリクエストの例を示す図である。
【図２７】システムＲＭで転送された後のアクションリクエストの例を示す図である。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。【００２０】
図１は、実施の形態に適用される発明の概念図である。図１では、管理サーバコンピュータ１，２，３，４に、本発明を適用したリソース管理プログラムが実装されている。
記憶手段１ａは、アクションハンドラテーブル１ａａを記憶する。アクションハンドラテーブル１ａａには、依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションハンドラが処理の依頼内容毎に登録されている。【００２１】
アクションハンドラ検索手段１ｂは、他のリソース管理機能との間で共通化された共通データ構造（共通データフォーマット）で処理の依頼内容が示された第１のアクションリクエスト７ａを、他のリソース管理機能（図１の例では、管理サーバコンピュータ２内のリソース管理機能）から受け取ると、第１のアクションリクエスト７ａによる依頼内容を解析する。そして、アクションハンドラ検索手段１ｂは、第１のアクションリクエスト７ａに示される依頼内容に対応するアクションハンドラをアクションハンドラテーブル１ａａから検索する。【００２２】
アクション実行手段１ｄは、アクションハンドラ検索手段１ｂで検出されたアクションハンドラを起動して、アクションハンドラに定義された処理を実行する。なお、アクションハンドラに定義された処理を実行しても、第１のアクションリクエスト７ａに示される依頼内容が未完了の場合がある。この場合、アクション実行手段１ｄは、共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエスト７ｂを生成する。そして、アクション実行手段１ｄは、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能（図１の例では、管理サーバコンピュータ４内のリソース管理機能）に対して第２のアクションリクエスト７ｂを送信する。【００２３】
アクションリクエスト転送手段１ｃは、アクションハンドラ検索手段１ｂでアクションハンドラが検出されなかった場合、第１のアクションリクエスト７ａに含まれる処理の対象となる管理対象機器を管理する他のリソース管理機能（図１の例では、管理サーバコンピュータ３内のリソース管理機能）に対して、第１のアクションリクエスト７ａと同じ依頼内容を有する第３のアクションリクエスト７ｃを送信する。【００２４】
このような機能を管理サーバコンピュータ１が有していれば、第１のアクションリクエスト７ａが入力されると、アクションハンドラ検索手段１ｂにより、第１のアクションリクエスト７ａによる依頼内容が解析される。そして、アクションハンドラ検索手段１ｂにより、第１のアクションリクエスト７ａに示される依頼内容に対応するアクションハンドラがアクションハンドラテーブル１ａａから検索される。【００２５】
すると、アクション実行手段１ｄにより、アクションハンドラ検索手段１ｂで検出されたアクションハンドラが起動され、起動されたアクションハンドラに定義された処理が実行される。ここで、第１のアクションリクエスト７ａに示される依頼内容が未完了の場合、アクション実行手段１ｄにより、共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエスト７ｂが生成される。そして、アクション実行手段１ｄにより、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して第２のアクションリクエスト７ｂが送信される。【００２６】
また、アクションハンドラ検索手段１ｂでアクションハンドラが検出されなかった場合、アクションリクエスト転送手段１ｃにより、第１のアクションリクエスト７ａに含まれる処理の対象となる管理対象機器を管理する他のリソース管理機能に対して、第１のアクションリクエスト７ａと同じ依頼内容を有する第３のアクションリクエスト７ｃが送信される。【００２７】
なお、第１のアクションリクエスト７ａ、第２のアクションリクエスト７ｂ、および第３のアクションリクエスト７ｃには、例えば、そのアクションリクエストを生成したリソース管理機能の名称、中継したリソース管理機能の名称、そして操作対象のリソースに関する情報、操作対象リソースの作用部分に関する情報、および実行したいアクションの内容が格納される。【００２８】
このような共通データ構造で依頼内容が定義されたアクションリクエストを、管理サーバコンピュータ１〜４に実装されたリソース管理機能で受け渡すことで、各管理サーバコンピュータ１〜４では、受け取ったアクションリクエストによる依頼内容を解析できる。しかも、依頼内容に応じた実行内容は、アクションハンドラで独自に定義することができる。そのため、各リソース管理機能独自の高度な管理機能を維持したまま、リソース管理機能間のアクションリクエストの受け渡しが可能となる。【００２９】
すなわち、リソース管理機能間でやりとりされるアクションリクエストのデータフォーマットを共通化したことで、処理を依頼する側では、依頼相手の処理機能に依存せずにアクションリクエストを生成できる。そして、アクションリクエストで示された依頼内容は、アクションハンドラテーブル１ａａを介して、各リソース管理機能毎の高度なリソース管理を行うアクションハンドラに対応付けられる。【００３０】
その結果、独自プロトコルでのメッセージ交換を前提に作られたリソースマネージャ同士の協働処理が可能となる。例えば、異なるオペレーティングシステム（ＯＳ）が搭載された２台のサーバコンピュータで、同じ内容のリソース管理処理を実行する場合、各サーバコンピュータでは、異なるコンポーネントが機能している。このような場合でも、外部のリソースマネージャからは同じ内容のアクションリクエストを送れば良く、相互運用がやりやすくなる。【００３１】
しかも、アクションハンドラに基づく処理を実行しても、まだ依頼内容が未完了の場合、未完了の処理に応じたアクションリクエストが出力される。これにより、リソース管理機能が階層構造を採っている場合であっても、上位のリソース管理機能から下位のリソース管理機能へ、自動的に処理が依頼される。【００３２】
すなわち、最初に第１のアクションリクエスト７ａを出力した管理サーバコンピュータ２では、管理サーバコンピュータ１より先のリソース管理機能が、階層構造になっているか否かを認識する必要がない。その結果、階層構造でリソース管理が行われているシステムであっても、アクションリクエストによる処理の依頼が容易となる。【００３３】
次に、本発明の実施の形態について詳細に説明する。なお、以下の説明では、リソースを管理する管理サーバコンピュータに配置されたリソース管理機能を、リソースマネージャと呼ぶ。また、管理対象であるリソースを有する機器に配置され、リソースマネージャの指示に従ってリソースを管理するリソース管理機能をエージェントと呼ぶ。また、リソースマネージャとエージェントとの双方のリソース管理機能を纏めて、コンポーネントと呼ぶ。【００３４】
さらに、以下の説明で単に「サーバ」と呼んだ場合は、サーバアプリケーションをコンピュータが実行することによって実現されるサーバ機能を指すものとする。「サーバコンピュータ」と呼んだ場合は、サーバアプリケーションを実行するコンピュータを指す。【００３５】
なお、以下の実施の形態では、図１に示した機能に加え、各コンポーネントは、送受信したアクションリクエストや実行したアクション等のログを格納するデータベースを有する。送受信したアクションリクエストおよびアクション実行のログを各コンポーネントで保持しておくことにより、対象アクションリクエストが影響を及ぼしたコンポーネント、リソースを追跡することができ、アクションの取り消しや影響範囲の可視化などを容易に行えるようになる。【００３６】
図２は、本実施の形態のシステム構成を示す図である。本実施の形態では、クライアント２１，２２，・・・に対してネットワーク１０を介してサービスを提供するシステムを想定している。この実施の形態では、複数のサイト１００，２００に分けてリソースが管理されている。なお、図２において、システム管理用の接続関係は、破線で示されている。【００３７】
サイト１００には、管理サーバコンピュータ１１０，１２０，１３０、サーバコンピュータ１４０，１５０、およびネットワーク機器１６０，１７０が属している。管理サーバコンピュータ１１０は、管理サーバコンピュータ１２０，１３０に接続されており、サイト１００内の全体のリソースを統括管理する。管理サーバコンピュータ１２０は、サーバコンピュータ１４０，１５０に接続されており、サーバコンピュータ１４０，１５０で提供されるリソースを管理する。管理サーバコンピュータ１３０は、ネットワーク機器１６０，１７０に接続されており、ネットワーク機器１６０，１７０で提供されるリソースを管理する。【００３８】
サーバコンピュータ１４０，１５０は、ネットワーク１０を介してクライアント２１，２２，・・・に接続されており、例えば、Ｗｅｂサーバアプリケーション等の機能をクライアント２１，２２，・・・に対して提供する。ネットワーク機器１６０，１７０は、サーバコンピュータ１４０，１５０と、サイト２００に属するストレージ装置２３０，２４０との間に接続されており、各装置間のパケット転送機能を有する。【００３９】
サイト２００には、管理サーバコンピュータ２１０，２２０およびストレージ装置２３０，２４０が属している。管理サーバコンピュータ２１０は、管理サーバコンピュータ２２０に接続されており、サイト２００内の全体のリソースを統括管理する。管理サーバコンピュータ２２０は、ストレージ装置２３０，２４０に接続されており、ストレージ装置２３０，２４０で提供されるリソースを管理する。ストレージ装置２３０，２４０は、情報の記憶および管理を行っており、サーバコンピュータ１４０，１５０に対して情報の入出力機能を提供する。
【００４０】
図３は、本発明の実施の形態に用いる管理サーバコンピュータのハードウェア構成例を示す図である。管理サーバコンピュータ１１０は、ＣＰＵ(Central Processing Unit)１１０ａによって装置全体が制御されている。ＣＰＵ１１０ａには、バス１１０ｇを介してＲＡＭ(Random Access Memory)１１０ｂ、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１１０ｃ、グラフィック処理装置１１０ｄ、入力インタフェース１１０ｅ、および１つまたは複数の通信インタフェース１１０ｆが接続されている。【００４１】
ＲＡＭ１１０ｂには、ＣＰＵ１１０ａに実行させるＯＳ(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１１０ｂには、ＣＰＵ１１０ａによる処理に必要な各種データが格納される。ＨＤＤ１１０ｃには、ＯＳやアプリケーションプログラムが格納される。【００４２】
グラフィック処理装置１１０ｄには、モニタ１１が接続されている。グラフィック処理装置１１０ｄは、ＣＰＵ１１０ａからの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１１０ｅには、キーボード１２とマウス１３とが接続されている。入力インタフェース１１０ｅは、キーボード１２やマウス１３から送られてくる信号を、バス１１０ｇを介してＣＰＵ１１０ａに送信する。【００４３】
通信インタフェース１１０ｆは、ネットワークに接続されている。通信インタフェース１１０ｆは、ネットワークを介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には、管理サーバコンピュータ１１０のハードウェア構成のみを示したが、他の管理サーバコンピュータ１２０，１３０，サーバコンピュータ１４０，１５０、管理サーバコンピュータ２１０，２２０、ストレージ装置２３０，２４０、も同様のハードウェア構成で実現することができる。【００４４】
図４は、リソース管理機能の構成を示す図である。まず、サイト１００、２００それぞれに属する各装置が有する機能およびデータについて説明する。
管理サーバコンピュータ１１０内には、アクションハンドラテーブル１１１ａとログＤＢ（データベース）１１１ｂとを有するシステムＲＭ（リソースマネージャ）１１１が設けられている。管理サーバコンピュータ１２０内には、アクションハンドラテーブル１２１ａとログＤＢ（データベース）１２１ｂとを有するサーバＲＭ（リソースマネージャ）１２１が設けられている。管理サーバコンピュータ１３０内には、アクションハンドラテーブル１３１ａとログＤＢ（データベース）１３１ｂとを有するネットワークＲＭ（リソースマネージャ）１３１が設けられている。【００４５】
サーバコンピュータ１４０内には、アクションハンドラテーブル１４１ａとログＤＢ（データベース）１４１ｂとを有するエージェント１４１が設けられている。サーバコンピュータ１５０内には、アクションハンドラテーブル１５１ａとログＤＢ（データベース）１５１ｂとを有するエージェント１５１が設けられている。【００４６】
システムＲＭ１１１は、サイト１００全体もしくはその一部分を統合管理する上位のリソースマネージャである。システムＲＭ１１１は、サーバＲＭ１２１、ネットワークＲＭ１３１と連携して、サイト１００内の全リソースを管理することができる。【００４７】
サーバＲＭ１２１は、エージェント１４１，１５１と連携して、サーバコンピュータ１４０，１５０で提供されるリソースを管理する。ネットワークＲＭ１３１は、ネットワーク機器１６０，１７０で提供されるリソースを管理する。エージェント１４１，１５１は、サーバＲＭ１２１からの指示に従って、それぞれサーバコンピュータ１４０，１５０内のリソースを管理する。
【００４８】
管理サーバコンピュータ２１０内には、アクションハンドラテーブル２１１ａとログＤＢ（データベース）２１１ｂとを有するシステムＲＭ（リソースマネージャ）２１１が設けられている。管理サーバコンピュータ２２０内には、アクションハンドラテーブル２２１ａとログＤＢ（データベース）２２１ｂとを有するストレージＲＭ（リソースマネージャ）２２１が設けられている。【００４９】
ストレージ装置２３０内には、アクションハンドラテーブル２３１ａとログＤＢ（データベース）２３１ｂとを有するエージェント２３１が設けられている。ストレージ装置２４０内には、アクションハンドラテーブル２４１ａとログＤＢ（データベース）２４１ｂとを有するエージェント２４１が設けられている。【００５０】
システムＲＭ２１１は、サイト２００全体もしくはその一部分を統合管理する上位のリソースマネージャである。システムＲＭ２１１は、ストレージＲＭ２２１と連携して、サイト２００内の全リソースを管理することができる。【００５１】
ストレージＲＭ２２１は、エージェント２３１，２４１と連携して、ストレージ装置２３０，２４０で提供されるリソースを管理する。エージェント２３１，２４１は、ストレージＲＭ２２１からの指示に従って、それぞれストレージ装置２３０，２４０内のリソースを管理する。
【００５２】
各装置に設けられたアクションハンドラテーブル１１１ａ，１２１ａ，１３１ａ，１４１ａ，１５１ａ，２１１ａ，２２１ａ，２３１ａ，２４１ａは、各装置に送られたアクション情報に応じた処理を実行する。各装置に設けられたログＤＢ１１１ｂ，１２１ｂ，１３１ｂ，１４１ｂ，１５１ｂ，２１１ｂ，２２１ｂ，２３１ｂ，２４１ｂには、各装置に送られたアクション情報および各装置で生成されたアクション情報の履歴が格納される。【００５３】
ここで、各機能間の通信インタフェースについて説明する。システムＲＭ１１１とサーバＲＭ２１１との間、システムＲＭ１１１とサーバＲＭ１２１との間、システムＲＭ１１１とサーバＲＭ１２１との間、サーバＲＭ１２１とエージェント１４１との間、サーバＲＭ１３１とエージェント１５１との間、システムＲＭ２１１とストレージＲＭ２２１との間、ストレージＲＭ２２１とエージェント２３１との間、ストレージＲＭ２２１とエージェント２４１との間は、それぞれ共通インタフェース２１〜２８で相互に接続される。
【００５４】
また、ネットワークＲＭ１３１とネットワーク機器１６０，１７０との間は、共通化されていない非共通インタフェース３１で接続される。共通化されていない非共通インタフェース３１としては、例えば、ＳＮＭＰ(Simple Network Management Protocol)やＣＬＩ(Command-Line Interface)などの標準化されたインタフェースが用いられる。【００５５】
なお、図４に示す各リソースマネージャは、対象リソースを直接管理する以外にも、複数のリソースを仮想的に１つのリソースとしたり、同じアーキテクチャのリソース群をグルーピングしたり、様々な管理機能を提供することができる。【００５６】
また、図４では、サイト１００内では、システムＲＭ１１１の下位構造にサーバＲＭ１２１とネットワークＲＭ１３１とが配置された２階層構造になっている。同様に、サイト２００内では、システムＲＭ２１０の下位構造にストレージＲＭ２２１が配置された２階層構造になっている。この階層構造は、一例であり、より深い階層構造になっていてもよい。
【００５７】
なお、ネットワーク機器１６０，１７０のようにエージェントが設けられていない場合、当該リソースに対して実行できるアクションは外部から指示可能なアクションに限定される。【００５８】
また、本実施の形態は、説明の便宜上、２つのサイト、２台のサーバ機器、２台のストレージ機器、および２台のネットワーク機器の構成例を示しているが、任意数のサイト、サーバ機器、ストレージ機器、ネットワーク機器で構成可能である。
【００５９】
以上の構成において、リソースマネージャ間、リソースマネージャ・エージェント間の通信は共通インタフェース２１〜２８を用いて行われる。ただし、エージェントが備わっていないリソースと当該リソースのマネージャ間は独自インタフェースやＳＮＭＰなどの非共通インタフェース３１が用いられる。【００６０】
上記の構成において、例えば、システムＲＭ２１１から、サーバコンピュータ１４０が実行すべきアクションを含むアクション情報が発行された場合を考える。この場合、アクション情報が、システムＲＭ２１１から共通インタフェース２１を使用してシステムＲＭ１１１に渡される。【００６１】
システムＲＭ１１１は、アクションハンドラテーブル１１１ａを参照して、受け取ったアクション情報に応じたアクションを判断する。そして、システムＲＭ１１１は、自分が実行すべきアクションを実行すると共に、サーバＲＭ１２１に接続されたサーバコンピュータ１４０に対するアクション情報であることを認識し、共通インタフェース２２を介して、アクション情報をサーバＲＭ１２１に送信する。この際、システムＲＭ１１１は、受け取ったアクション情報の内容、システムＲＭ１１１で実行したアクションの内容、および送信したアクション情報の内容をログＤＢ１１１ｂに格納する。【００６２】
サーバＲＭ１２１は、アクションハンドラテーブル１２１ａを参照して、受け取ったアクション情報に応じたアクションを判断する。そして、サーバＲＭ１２１は、自分が実行すべきアクションを実行すると共に、サーバコンピュータ１４０に対するアクション情報であることを認識し、共通インタフェース２４を介して、アクション情報をエージェント１４１に送信する。この際、サーバＲＭ１２１は、受け取ったアクション情報の内容、サーバＲＭ１２１で実行したアクションの内容、送信したアクション情報の内容をログＤＢ１２１ｂに格納する。【００６３】
エージェント１４１は、アクションハンドラテーブル１４１ａを参照して、受け取ったアクション情報に応じた処理を判断し、その処理を実行する。この際、エージェント１４１は、受け取ったアクション情報の内容とエージェント１４１が実行したアクションの内容とをログＤＢ１４１ｂに格納する。【００６４】
このように、システムＲＭ２１１で発行されたアクション情報が、システムＲＭ１１１、サーバＲＭ１２１、エージェント１４１と順に伝達され、そして最終的にエージェント１４１によって指定されたアクション情報に対応するコマンド等が実行される。【００６５】
次に、図４に示す各コンポーネント（リソースマネージャとエージェント）が有する機能について具体的に説明する。
図５は、システムＲＭの内部構造を示す図である。システムＲＭ１１１は、アクションハンドラテーブル１１１ａ、ログＤＢ１１１ｂ、複数のアクションハンドラ１１１ｃ、アクションハンドラ検索部１１１ｄ、アクションリクエスト転送部１１１ｅ、アクション実行部１１１ｆ、およびログ採取部１１１ｇを有している。アクションハンドラテーブル１１１ａとログＤＢ１１１ｂとの内容は、図４を用いて説明した通りである。【００６６】
複数のアクションハンドラ１１１ｃは、アクション情報に応じて実行するリソース管理処理の内容が記述されたプログラム（コマンドやスクリプト等）である。
アクションハンドラ検索部１１１ｄは、他のコンポーネントからアクションリクエスト３３を受け取ると、アクションハンドラテーブル１１１ａ参照し、そのアクションリクエスト３３で示されるアクションに対応するアクションハンドラを検索する。そして、アクションハンドラ検索部１１１ｄは、検出されたアクションハンドラの名称をアクション実行部１１１ｆに通知する。また、アクションハンドラを検出できなかった場合、アクションハンドラ検索部１１１ｄは、対応するアクションハンドラが無いことをアクションリクエスト転送部１１１ｅに通知する。【００６７】
アクションリクエスト転送部１１１ｅは、アクションハンドラ検索部１１１ｄからの通知により、アクションリクエスト３３に対応するアクションハンドラが無いことを認識し、アクションリクエスト３３で示されるアクションを実行すべき他のコンポーネントを判断する。例えば、アクションリクエスト３３で示される管理対象がサーバであれば、アクションリクエスト転送部１１１ｅは、サーバＲＭ１２１を、アクションリクエスト３３で示されるアクションを実行すべきコンポーネントと判断する。そして、アクションリクエスト転送部１１１ｅは、アクションリクエスト３３で示されるアクションを実行すべきコンポーネントに対して、アクションリクエスト３３と同じアクションを依頼するアクションリクエスト３４を送信する。【００６８】
アクション実行部１１１ｆは、アクションハンドラ検索部１１１ｄからアクションハンドラの名称を受け取ると、複数のアクションハンドラ１１１ｃの中から該当するアクションハンドラを取得する。そして、アクション実行部１１１ｆは、取得したアクションハンドラを起動し、そのアクションハンドラで定義されている処理を実行する。【００６９】
このとき、起動したアクションハンドラにおいて、他のコンポーネントへの依頼すべき処理が発生すると、アクション実行部１１１ｆは、新たなアクションを生成する。そして、アクション実行部１１１ｆは、生成したアクションを依頼するためのアクションリクエスト３５を、他のコンポーネントへ送信する。また、アクション実行部１１１ｆは、処理が終了すると、アクションリクエスト３３におけるアクションの生成元に対して、処理結果３６を応答する。【００７０】
なお、アクションリクエストを定義した共通化データ構造では、複数の処理を依頼することができると共に、各処理の実行順を指定可能である。入力されたアクションリクエストにおいて複数処理の実行順が指定されていた場合、アクション実行部１１１ｆは、指定された順に、各処理に対応するアクションハンドラを起動する。【００７１】
ログ採取部１１１ｇは、アクションリクエスト転送部１１１ｅとアクション実行部１１１ｆから、実行した処理の内容をログ情報として取得する。そして、ログ採取部１１１ｇは、取得したログ情報をログＤＢ１１１ｂに格納する。【００７２】
以上のような機能をシステムＲＭ１１１が有していることで、他のコンポーネントとの間で、共通インタフェースを用いたアクションリクエストの受け渡し、および受け取ったアクションリクエストで指定されたアクションの実行が可能となる。なお、図５には、システムＲＭ１１１の機能を示したが、他のリソースマネージャも同様の機能を有している。【００７３】
図６は、エージェントの内部構造を示す図である。エージェント１４１は、アクションハンドラテーブル１４１ａ、ログＤＢ１４１ｂ、複数のアクションハンドラ１４１ｃ、アクションハンドラ検索部１４１ｄ、アクション実行部１４１ｅ、およびログ採取部１４１ｆを有している。アクションハンドラテーブル１４１ａ、ログＤＢ１４１ｂ、複数のアクションハンドラ１４１ｃについては、それぞれシステムＲＭ１１１のアクションハンドラテーブル１１１ａ、ログＤＢ１１１ｂ、複数のアクションハンドラ１１１ｃと同様の情報である。【００７４】
アクションハンドラ検索部１４１ｄは、図５に示したシステムＲＭ１１１のアクションハンドラ検索部１１１ｄと同様に、アクションリクエスト３７に応じて、アクションハンドラテーブル１４１ａからアクションハンドラを検索する。ただし、検索により該当するアクションハンドラが検出されない場合には、アクションリクエスト３７の送信元に対してエラーメッセージを応答する。【００７５】
アクション実行部１４１ｅは、図５に示したシステムＲＭ１１１のアクション実行部１１１ｆと同様に、アクションハンドラ検索部１４１ｄで検出されたアクションハンドラに基づいて処理を実行し、処理結果３８を出力する。但し、他のコンポーネントに対するアクションリクエストの生成処理は行われない。ログ採取部１４１ｆは、アクション実行部１４１ｅの処理内容等のログを、ログＤＢ１４１ｂに格納する。【００７６】
このように、エージェント１４１は、他のコンポーネントへ処理を依頼する必要がない。そのため、エージェント１４１には、アクションリクエスト転送部１１１ｅに対応する機能は不要である。なお、図６には、サーバコンピュータ１４０のエージェント１４１の機能を示したが、他のエージェントも同様の機能を有している。【００７７】
次に、アクション情報のデータ構造について詳細に説明する。共通インタフェースとしてコンポーネント間で交換されるアクション情報には、当該指示を生成したコンポーネント、中継したコンポーネント、そして操作対象のリソースに関する情報と、操作対象リソースの作用部位に関する情報およびアクションの種別情報が含まれる。【００７８】
図７は、アクション情報のデータモデルを示すＵＭＬ(Unified Modeling Language)モデル図である。以下、要素に含まれるデータの内容について説明する。
ActionRequest要素４１は最上位の要素である。ActionRequest要素４１を単位としてコンポーネント間でアクションリクエストが送受信される。ActionRequest要素４１は、属性としてＩＤと生成された日時を示すcreateDateとを有する。また、ActionRequest要素４１は、Creator要素４２、Sender要素４３、およびActionEntity要素４７を内容として保持する。【００７９】
Creator要素４２では、アクションを生成したコンポーネント情報（リソースマネージャの識別情報）を有する。
Sender要素４３は、アクションリクエストを転送してきた転送元のコンポーネント情報を有する。【００８０】
ManagedObject要素４４は、操作実行対象となるコンポーネントもしくはリソースを意味する。ManagedObject４４は責務に応じてさらに３つのCreator要素４２、Sender要素４３、Target要素５０に派生する。また、ManagedObject要素４４は、属性として名前属性であるnameおよびＩＤを有する。【００８１】
ActionGroup要素４５はアクションの集合を表すクラスである。ActionGroup要素４５には、１つ以上のActionEntity要素４７が含まれる。また、ActionGroup要素４５は、ActionGroup要素４５に含まれる複数のActionEntitty要素４７の実行順序を指定するorder属性を有する。【００８２】
Action要素４６は個々のアクション内容を表す抽象クラス（抽象的な定義を行うクラスであり、インスタンスを生成できず、継承を行うことを前提としたクラス）である。
ActionEntity要素４７はアクション内容を示す抽象クラスであり、Action要素４６およびActionGroup要素４５が派生する。ActionRequest要素４１には１つのActionEntity要素４７のみ含まれるが、それはActionRequest要素４１に含まれるのがAction要素４６でもActionGroup要素４５でもよいことを意味する。つまり、アクションリクエストとして、単一のアクションを指定する以外に、複数のアクションから成るアクショングループを指定したり、また内部にさらに複数のアクショングループが含まれる階層構造を成すアクショングループを指定したりすることも可能である。また、ActionEntity要素４７はＩＤ属性と、結果が返ってくるまで待つかどうかを指定するsync属性、および当該アクションの優先度を示すpriority属性を持ってもよい。【００８３】
GetAction要素４８とSetAction要素４９とは、共にActionクラスの具象クラス（抽象クラスではないクラス）である。GetAction要素４８とSetAction要素４９とは、それぞれ情報取得(get)、情報設定(set)系のアクションを指定する際に使用される。get, set以外にも、アクション実行対象に対してどのようなアクションを実行可能かは予め定義してアクションハンドラテーブルに登録しておくことにより、その中から適切なアクションをGetAction要素４８、SetAction要素４９と同様の形で、アクションリクエストに指定することができる。【００８４】
Target要素５０は、アクションを実行する対象のオブジェクトを指定している。一般的にはサーバ／ストレージ／ネットワーク／ソフトウェアといったリソースが、アクションの実行対象である。なお、サービスや複数のサーバを論理的にグループ化したサーバドメインなどもターゲットとすることができる。【００８５】
Target要素５０は、ターゲット種類を示す属性としてclass属性を有する。さらに、Target要素５０は、そのクラスの具体的にどのインスタンスかを示す情報としてname, id属性を有する。また、Target要素５０内には、どのサイトにあるターゲットなのかを指定するsite属性も存在する。【００８６】
Property要素５１は、アクションが作用する部位を指定するための要素であり、Target要素５０で指定されたオブジェクトの状態や構成を指し示す。Property要素５１は、属性として、作用する部位のキーを指定するkey属性を有する。また、Property要素５１は、設定系のアクションの場合には指定された部位に対する設定値をvalue属性に指定する。Property要素５１は、状態を表すState要素５２、構成を表すConfiguration要素５５へと派生する。【００８７】
State要素５２は、対象オブジェクトの状態を指す。サーバの使用率やソフトウェアのSTART/STOP状態などの状態がState要素５２として扱われ、その状態のオブジェクトに対して取得・設定などのアクションが実行される。State要素５２は、さらにInternalState要素５３、ExternalState要素５４に派生する。【００８８】
InternalState要素５３は、対象オブジェクトの内部状態を示している。例えば、サーバのＣＰＵ使用率やソフトウェアのSTART/STOP状態などがnternalState要素５３に該当する。【００８９】
ExternalState要素５４は、対象オブジェクトの外部状態を指す。これは、外部（対象オブジェクト以外の要素）から観測される対象オブジェクトの状態のことである。例えば、サーバの生死状態などが、外部状態に該当する。したがって、ExternalState要素５４のクラスを指定したアクションの場合は、対象オブジェクトを監視するコンポーネントが責任を持って対応しなければならないことを意味する。【００９０】
Configuration要素５５は、対象オブジェクトの構成・設定を指す。対象オブジェクトに含まれるリソース量の増減や設定パラメータなどがConfiguration要素５５として扱われ、それに対して取得・設定などのアクションが実行される。Configuration要素５５のクラスは、さらにStructure要素５６、Parameter要素５７に派生する。【００９１】
Configuration要素５５には、ファイルなど外部エンティティを参照するためのuri属性が設けてある。外部エンティティとはファイルやＷｅｂページなどであり、取得・設定したい構成情報などが格納されていることを想定している。格納されている情報のフォーマットに関しては、当該アクションを実行するコンポーネントが解釈できる形式であればよい。【００９２】
Structure要素５６は、対象オブジェクトの構成を指す。例えば、サーバドメインに登録されているサーバ群やサービスを構成するアプリケーションの組み合わせなどが該当する。【００９３】
Parameter要素５７は、対象オブジェクトの設定を指す。例えば、ソフトウェアが使用するメモリ量やスイッチのＶＬＡＮ(Virtual Local Area Network)の設定などが該当する。【００９４】
図７に示すように、データには上記以外の例えばアクション生成日時情報など付加情報を含んでいてもよい。また、データ形式は、最低限上記情報が含まれていればどのような形式で送受信してもよいが、可搬性、拡張性の観点からＸＭＬ(eXtensible Markup Language)形式が望ましい。【００９５】
図８は、アクションハンドラテーブルのデータ構造例を示す図である。アクションハンドラテーブル１０２には、対象種別、プロパティ、アクション、および実行内容の各項目が設けられており、各項目のデータが互いに関連付けられ、１つのレコードとして登録されている。【００９６】
対象種別には、アクションが作用する対象の種別が設定される。例えば、サービス（ユーザに提供されるサービス）／サーバ（サービスを提供するための処理を行う処理機能）／ネットワーク機器／ソフトウェア等が、種別として設定される。【００９７】
プロパティには、アクションが作用する対象の属性が設定される。例えば、構成（システム構成に関する処理）／パラメータ（パラメータの設定等の操作）／状態（運用状態の監視処理）などが、プロパティに設定される。【００９８】
アクションには、アクションが作用する対象オブジェクトのプロパティに対して実行可能なアクションの種別が設定されている。例えば、「set」や「get」が設定される。
実行内容には、実際に実行されるコマンドやスクリプト等のアクションハンドラの識別情報（例えば、ファイル名）が設定される。【００９９】
次に、各コンポーネントがアクションリクエストを受け取った際の処理について説明する。
図９は、アクションリクエストに応じたリソースマネージャの処理手順を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。ここで、システムＲＭ１１１に対してアクションリクエストが送られた場合のシステムＲＭ１１１の処理として説明するが、他のリソースマネージャでも同様の処理が行われる。【０１００】
［ステップＳ１１］システムＲＭ１１１のアクションハンドラ検索部１１１ｄは、アクションリクエスト３３を受信する。
［ステップＳ１２］アクションハンドラ検索部１１１ｄは、受信したアクションリクエスト３３内のアクションを解釈して、そのアクションに対応するアクションハンドラがアクションハンドラテーブル１１１ａに登録されているかどうか検索する。具体的には、アクションハンドラ検索部１１１ｄは、アクションハンドラテーブル１１１ａを参照し、アクションリクエストに記載されている対象オブジェクト種別、プロパティ、アクション種別をキーに、適切なレコードを検索する。そして、検索の結果合致するレコードがあった場合には、アクションハンドラ検索部１１１ｄは、合致するレコードの実行内容（アクションハンドラの名称）を取得する。【０１０１】
［ステップＳ１３］アクションハンドラ検索部１１１ｄは、アクションハンドラが登録されていれば、そのアクションハンドラの名称をアクション実行部１１１ｆに通知し、処理をステップＳ１６に進める。また、アクションハンドラ検索部１１１ｄは、アクションハンドラが登録されていなければ、アクションハンドラが登録されていな旨をアクションリクエスト転送部１１１ｅに通知し、処理をステップＳ１４に進める。【０１０２】
［ステップＳ１４］アクションリクエスト転送部１１１ｅは、アクションハンドラテーブル１１１ａに合致するレコードが登録されていなかった場合には、アクションリクエスト３３の送信元情報（Sender）を修正する。具体的には、システムＲＭ１１１は、アクションリクエスト３３の送信元情報を、自分自身の識別情報に書き換える。【０１０３】
［ステップＳ１５］アクションリクエスト転送部１１１ｅは、アクションリクエスト３３を処理するのに適切なコンポーネントに対して、ステップＳ１４で修正したアクションリクエスト３４を転送する。その後、処理がステップＳ２１に進められる。【０１０４】
［ステップＳ１６］アクション実行部１１１ｆは、アクションテーブル１１１ａを参照したときに、アクションリクエストに記載されている対象オブジェクト種別、プロパティ、アクション種別をキーに適切なレコードを検索し、合致するものがあった場合には、合致したレコードの実行内容として記載されているアクションハンドラ（コマンド、スクリプト等）を実行する。この際、アクション実行部１１１ｆは、アクション内容を、指定されたコマンド、スクリプトの入力に適切な形式に変換して、コマンドやスクリプトの実行プロセスに渡す。
【０１０５】
［ステップＳ１７］アクション実行部１１１ｆは、アクションリクエスト３３を満たすために必要な全ての処理が完了しているか否かを判断する。全ての処理が完了していれば、処理がステップＳ２０に進められ、未完了の処理があれば、処理がステップＳ１８に進められる。【０１０６】
［ステップＳ１８］アクション実行部１１１ｆは、アクションリクエスト３３を満たすための未完了の処理があれば、その処理を実行するための新規のアクションリクエスト３５を作成する。【０１０７】
［ステップＳ１９］アクション実行部１１１ｆは、アクションリクエスト３３の未完了の処理を実行するのに適切なコンポーネントに対して、ステップＳ１８で作成したアクションリクエスト３５を送信する。その後、処理がステップＳ２１に進められる。【０１０８】
［ステップＳ２０］アクション実行部１１１ｆは、アクションリクエスト３３を満たすために必要な全ての処理が完了した場合は、その実行結果をリクエスト送信元に返す。
［ステップＳ２１］システムＲＭ１１１は、処理内容をログＤＢ１１１ｂに格納する。その後、処理が終了する。【０１０９】
次に、アクションリクエストに応じたエージェントの処理について説明する。
図１０は、アクションリクエストに応じたエージェントの処理手順を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。ここで、エージェント１４１に対してアクションリクエストが送られた場合のエージェント１４１の処理として説明するが、他のエージェントでも同様の処理が行われる。【０１１０】
［ステップＳ３１］アクションハンドラ検索部１４１ｄは、アクションリクエスト３７を受信する。
［ステップＳ３２］アクションハンドラ検索部１４１ｄは、受信したアクションリクエスト３７内のアクションを解釈して、そのアクションに対応するアクションハンドラをアクションハンドラテーブル１４１ａから検索する。具体的には、アクションハンドラ検索部１４１ｄは、アクションハンドラテーブル１４１ａを参照し、アクションリクエスト３７に記載されている対象オブジェクト種別、プロパティ、アクション種別をキーに、適切なレコードを検索する。そして、検索の結果合致するレコードがあった場合には、アクションハンドラ検索部１４１ｄは、合致するレコードの実行内容（アクションハンドラの名称）を取得する。【０１１１】
［ステップＳ３３］アクション実行部１４１ｅは、アクションハンドラテーブル１４１ａを参照したときに、アクションに記載されている対象オブジェクト種別、プロパティ、アクション種別をキーに適切なレコードを検索し、合致したレコードの実行内容として記載されているコマンド、スクリプト等を実行する。この際、アクション実行部１４１ｅは、アクション内容を、指定されたコマンド、スクリプトの入力に適切な形式に変換して、コマンドやスクリプトの実行プロセスに渡す。【０１１２】
［ステップＳ３４］アクション実行部１４１ｅは、実行結果をリクエスト送信元に返す。
［ステップＳ３５］アクション実行部１４１ｅは、処理内容をログＤＢ１４１ｂに格納する。その後、処理が終了する。【０１１３】
このように、エージェント１４１は、他のコンポーネントにアクションリクエストを送信する必要はないため、アクションリクエストの変更、生成等の処理は行われない。
図９、図１０に示したフローチャートからも明らかのように、本実施の形態のシステムでは、生成元からアクションを実行するコンポーネントにアクションリクエストが直接配送されるとは限らない。【０１１４】
図１１は、アクションリクエストの伝搬の概念を示す図である。この図には、７つのコンポーネント６１〜６７が示されている。コンポーネント６１〜６７は、リソースマネージャもしくはリソース上で稼動するエージェントである。図中、各コンポーネント６１〜６７内には、そのコンポーネントで生成されるか、あるいは他のコンポーネントから渡されたアクション６１ａ，６２ａ，６３ａ，６３ｂ，６３ｃ，６３ｄ，６３ｅが示されている。同一のアクションは、同じ形状、同じ模様で示されている。【０１１５】
図１１において、コンポーネント６１で生成されたアクション６１ａは、まずコンポーネント６２に送信される。すると、コンポーネント６２において、別のアクションリクエストに変更される。つまり、コンポーネント６２のアクションハンドラテーブルに、受け取ったアクションリクエストに該当するアクションハンドラが登録してあり、そのハンドラを呼び出した結果新たなアクション６２ａが生成されたことを意味する。このような状況になるのは、以下の２通りの場合である。【０１１６】
これは、例えば、コンポーネント６２において、受け取ったアクションリクエストの要求を満たす処理をしたが、それは一部分であり、残りの処理を実行するために他のコンポーネントに処理を依頼する必要がある場合、あるいは、コンポーネント６２が受け取ったアクションリクエストをより適切かつ具体的なアクションリクエストに修正して他のコンポーネントに渡す場合の２通りが考えられる。【０１１７】
次に、コンポーネント６２で変更されたアクションリクエストは、コンポーネント６３に送られる。そして、コンポーネント６３において、新たな複数のアクション６３ａ，６３ｂ，６３ｃ，６３ｄ，６３ｅが生成されている。アクション６３ａのアクションリクエストは、コンポーネント６４に対して出されている。アクション６３ｂのアクションリクエストは、コンポーネント６５に対して出されている。アクション６３ｃ，６３ｄ，６３ｅのアクションリクエストは、コンポーネント６６に対して出されている。【０１１８】
このように、他の複数のコンポーネント６４〜６６に対してアクションの処理依頼を発行する場合もある。また、アクション６３ｃ，６３ｄ，６３ｅのように、同一コンポーネントに対して複数のアクションを発行する場合もある。これは、ある処理を実行してから次の処理を実行する必要がある場合などに用いられる。コンポーネント６３は、複数のアクション６３ｃ，６３ｄ，６３ｅを１つのコンポーネント６６に送信する場合、アクション６３ｃ，６３ｄ，６３ｅ間の順序関係を指定しておき、アクショングループとして複数のアクション６３ｃ，６３ｄ，６３ｅを１つのリクエストにまとめて送信する。【０１１９】
コンポーネント６３で生成されたアクション６３ａは、コンポーネント６４において、アクションリクエストに応じたアクションが実行される。
さらに、コンポーネント６３で生成されたアクション６３ｂはコンポーネント６５を経由してコンポーネント６７にそのまま渡されている。例えば、コンポーネント６３がサイト全体を管理するシステムＲＭ、コンポーネント６５がサーバ群を管理するサーバＲＭ、そしてコンポーネント６７があるサーバ上で稼動するエージェントだとする。【０１２０】
この場合、システムＲＭは生成したアクション６３ｂがサーバ関連のアクションであることは認識しているが実際どのサーバのものなのか、もしくはそのサーバがどこにあるかまでは認識する必要はないことを意味する。すなわち、システムＲＭは、サーバ全体を管理するサーバＲＭにアクション６３ａを投げて、サーバＲＭによって実際に担当すべきエージェントにそのアクション６３ａを渡してもらう。このようにして、処理の委譲を行うことができる。【０１２１】
ただし、サーバＲＭは渡されたアクションリクエストをそのまま下位のエージェントに渡すわけではなく、少なくとも送信元情報（Sender）はサーバＲＭに変更してから送信する。これは後述のアクション伝播の追跡可能性を確保するためである。【０１２２】
コンポーネント６１で生成されたアクション６１ａは様々なアクションに分かれ、最終的にコンポーネント６４，６６，６７にまで反映される。このような構成をとることにより、各コンポーネントは必ずしも他のコンポーネント全ての存在を知る必要はなくなる。【０１２３】
例えば図４のような構成の場合、サイト１００内ではどのようなサーバがあるかは、サーバＲＭ１２１のみが知っていればよい。また、上位のシステムＲＭ１１１はサイト１００内のサーバを統一管理しているのがサーバＲＭ１２１であることを認識しさえすればよい。ネットワークに関しても同様である。【０１２４】
一方、サイト２００のシステムＲＭ２１１は、サイト１００全体を管理するシステムＲＭ１１１の存在を知ってそれとのみ通信できればよい。サイト１００のリソースに関するアクションリクエストは全てシステムＲＭ１１１に対して送信することで、後は適切なリソースマネージャを介して指定されたアクションが実行される。【０１２５】
また、ストレージＲＭ２２１からサイト１００のリソースに対してアクションリクエストを発行する場合は、一旦上位のシステムＲＭ２１１に処理を委譲して、後は上述同様に処理を進めればよい。つまり、ストレージＲＭ２２１は、他サイトのリソースマネージャ構成はまったく意識しなくても済む。【０１２６】
図１１はアクション６１ａに関係のあるアクションを網羅したアクション伝播図を示していることになる。本実施の形態のシステムでは、各コンポーネントにアクションに関するログを保持するデータベースを持たせることで、このようなアクション伝播関係を容易に取得可能とする。つまり追跡可能性を確保することができる。これにより、アクションリクエスト後に任意のアクションに関係するアクション全てを取得したり、発行したリクエストを取り消したりすることが可能となる。【０１２７】
図１２は、ログＤＢのデータ構造例を示す図である。ログＤＢ１０３には、動作種別とログ情報との欄が設けられている。
動作種別の欄には、コンポーネントで実行された動作の種別を示している。例えば、アクションリクエスト生成、アクションリクエスト送信、アクションリクエスト受信、アクション実行などが動作種別として登録される。【０１２８】
ログ情報には、動作の内容を示す情報が登録される。例えば、アクションリクエスト生成時には、生成したアクションリクエストの内容全体が保持される。この時、当該リクエストが、先行するアクションリクエストに応じたアクションを実行することで生成された場合は、その先行するアクションリクエストのリクエストＩＤも記録する。アクションリクエスト送信時は、送信されたアクションリクエストのリクエストＩＤと送信先が記録される。アクションリクエスト受信時は、受信したアクションリクエストＩＤと送信元が記録される。そして、アクション実行時は、アクションリクエストのリクエストＩＤと、実行されたアクションのアクションＩＤとが記録される。【０１２９】
基本的に送受信するアクションリクエストすべての内容を保持するので、図７のデータモデルに示すCreator要素４２、Sender要素４３およびログの通信相手情報を辿ることで図１１に示すような伝播図を求めることができる。さらに、各アクションでどのようなコマンド、スクリプトを実行したかも各コンポーネントのアクションハンドラテーブルと照らし合わせることで把握できる。【０１３０】
次に、本実施の形態のシステムを利用したシステム管理用のアクション実施例を、具体的に説明する。本実施の形態において、サイト２００のストレージ装置２３０とサイト１００のサーバコンピュータ１５０とを利用して、Ｗｅｂサービスを提供しているものとする。このとき、サーバコンピュータ１４０は、サービスの提供を行っていないものとする。また、ネットワーク機器（例えば、スイッチ）１６０では、当該サービス用にＶＬＡＮを設定することで、他のリソースへの影響を防いでいる。【０１３１】
ここで、サーバの処理性能が足らず、ストレージ性能を活かしきれていないことをシステムＲＭ２１１が検出した場合を想定して、具体的なリソース管理例を説明する。この状況において、システムＲＭ２１１が当該サービスに対して新たにサーバコンピュータ１４０のサーバ機能を追加指示する際の処理手順を示す。なお、サイト１００，２００に存在するシステムＲＭ１１１、２１１は互いの存在は認識するものの他サイトのほかのリソースマネージャに関しては認識していないものとする。また、今回は明示的にシステムＲＭ２１１から特定のサーバコンピュータ１４０のサーバ機能を追加する旨の指示を発行する場合を示すが、どのサーバを追加するかは他のリソースマネージャ（例えば、システムＲＭ１１１やサーバＲＭ１２１）に委任することもありうる。【０１３２】
なお、システムＲＭ２１０が当該サービスに対するサーバコンピュータ１４０の追加指示をする際の処理手順では、サイト１００側の管理サーバコンピュータ１１０，１２０，１３０、およびサーバコンピュータ１４０に設定されたアクションハンドラテーブル１１１ａ，１２１ａ，１３１ａ，１４１ａが参照される。そこで、処理手順を説明する前に、参照されるアクションハンドラテーブル１１１ａ，１２１ａ，１３１ａ，１４１ａの内容を、図１３〜図１６を参照して説明する。【０１３３】
図１３は、統括管理を行う管理サーバコンピュータに格納されたアクションハンドラテーブルの例を示す図である。統括管理を行う管理サーバコンピュータ１１０に格納されたアクションハンドラテーブル１１１ａには、サービスの構成に対するset（設定）アクションに関するアクションハンドラ「svcctl」と、サービスの構成に対するget（取得）アクションに関するアクションハンドラ「svcctl」とが設定されている。なお、この例では、実行内容で指定されるプログラムが同じである。これは、該当するプログラムでは、アクション実行時に入力する変数に応じて、setアクション若しくはgetアクションが実行されることを示している。【０１３４】
このアクションハンドラテーブル１１１ａは、システムＲＭ１１１によって参照される。
図１４は、サーバを管理する管理サーバコンピュータに格納されたアクションハンドラテーブルの例を示す図である。サーバを管理する管理サーバコンピュータ１２０に格納されたアクションハンドラテーブル１２１ａには、サーバの電源ステータスに対するset（設定）アクションに関するアクションハンドラ「powerctl」、サーバドメインの構成に対するset（設定）アクションに関するアクションハンドラ「svrdomainctl.sh」、およびサーバドメインの構成に対するget（取得）アクションに関するアクションハンドラ「svrdomainctl.sh」が設定されている。【０１３５】
このアクションハンドラテーブル１２１ａは、サーバＲＭ１２１によって参照される。
図１５は、ネットワーク機器を管理する下位の管理サーバコンピュータに格納されたアクションハンドラテーブルの例を示す図である。ネットワーク機器を管理する管理サーバコンピュータ１３０に格納されたアクションハンドラテーブル１３１ａには、ネットワーク機器のパラメータに対するset（設定）アクションに関するアクションハンドラ「nwctl」とネットワーク機器のパラメータに対するset（取得）アクションに関するアクションハンドラ「nwctl」とが設定されている。【０１３６】
このアクションハンドラテーブル１３１ａは、ネットワークＲＭ１３１によって参照される。
図１６は、Ｗｅｂサービスを提供可能なサーバコンピュータに格納されたアクションハンドラテーブルの例を示す図である。Ｗｅｂサービスを提供可能なサーバコンピュータ１４０に格納されたアクションハンドラテーブル１４１ａには、ソフトウェアの状態のset（設定）アクションに関するアクションハンドラ「swctl」と、ソフトウェアの状態のget（取得）アクションに関するアクションハンドラ「swctl」とが設定されている。【０１３７】
このアクションハンドラテーブル１４１ａは、エージェント１４１によって参照される。
以下、図１７〜図１９に示すシーケンス図を参照して、サーバ追加処理手順を、シーケンス図内に示したステップ番号に沿って説明する。【０１３８】
図１７は、サーバ追加処理の手順を示す第１のシーケンス図である。
［ステップＳ４１］システムＲＭ２１１は、まず、どのような空きサーバがあるかの情報を取得するためのアクションリクエストを生成し、システムＲＭ１１１に対して送信する。【０１３９】
［ステップＳ４２］システムＲＭ１１１は、アクションハンドラテーブル１１１ａを取得し、アクションリクエストで指定されたアクションを検索する。
［ステップＳ４３］この例では適当なハンドラが存在しないため、システムＲＭ１１１は、サーバ関連を受け持つサーバＲＭ１２１に対してアクションリクエストを転送する。【０１４０】
［ステップＳ４４］アクションリクエストを受け取ったサーバＲＭ１２１は、アクションハンドラテーブル１２１ａを取得し、アクションリクエストで指定されたアクションを検索する。これにより、スクリプト名を指定したコマンド「svrdomainctl.sh」が検出される（図１４参照）。【０１４１】
［ステップＳ４５］サーバＲＭ１２１は、該当したコマンド「svrdomainctl.sh」を呼び出す。サーバＲＭ１２１はコマンド「svrdomainctl.sh」を実行することにより、フリー（現在サービスを提供していないサーバコンピュータ）のサーバリスト情報を取得する。【０１４２】
［ステップＳ４６］サーバＲＭ１２１は、取得したサーバリストをシステムＲＭ１１１に通知する。
［ステップＳ４７］システムＲＭ１１１は、サーバＲＭ１２１から受け取ったフリーのサーバリストを、システムＲＭ２１１に通知する。【０１４３】
［ステップＳ４８］システムＲＭ２１１は、取得したフリーのサーバリストで示されるサーバ情報に基づいて、サーバコンピュータ１４０をサービスに追加するアクションリクエストを生成する。そして、システムＲＭ２１１は、サイト１００全体を管理するシステムＲＭ１１１に対して、生成したアクションリクエストを送信する。【０１４４】
［ステップＳ４９］システムＲＭ１１１は、アクションハンドラテーブル１１１ａを取得し、アクションリクエストで指定されたアクションを検索する。これにより、アクションハンドラ「svcctl」が検出される（図１３参照）。
【０１４５】
［ステップＳ５０］システムＲＭ１１１は、検索の結果得られたアクションハンドラ「svcctl」を呼び出す。そして、システムＲＭ１１１は、アクションハンドラ「svcctl」を実行する。【０１４６】
［ステップＳ５１］システムＲＭ１１１は、アクションハンドラ「svcctl」で定義された処理を実行する。すると、システムＲＭ１１１は、指定されたアクションを実行するためにはまずはＶＬＡＮの設定をしてから新規サーバ上でアプリケーションを起動する必要があることを認識する。そして、システムＲＭ１１１は、アクションハンドラ「svcctl」内での定義に従って、ネットワーク設定用のアクションリクエストとサーバ設定用のアクションリクエストを生成する。【０１４７】
［ステップＳ５２］システムＲＭ１１１は、まずはネットワークＲＭ１３１に対して、ネットワーク設定用のアクションリクエストを送信する。
図１８は、サーバ追加処理の手順を示す第２のシーケンス図である。【０１４８】
［ステップＳ５３］ネットワークＲＭ１３１は、アクションハンドラテーブル１３１ａを取得し、アクションリクエストで指定されたアクションを検索する。これにより、アクションハンドラ「nwctl」が検出される（図１５参照）。【０１４９】
［ステップＳ５４］ネットワークＲＭ１３１は、アクションハンドラ「nwctl」のsetアクションを実行する。
［ステップＳ５５］ネットワークＲＭ１３１は、ネットワーク機器１６０にはエージェントが存在しないので、アクションハンドラに従って、ＳＮＭＰ等の標準もしくは独自プロトコルを用いてネットワーク機器１６０ＶＬＡＮに関する設定を行う。【０１５０】
［ステップＳ５６］ネットワーク機器１６０は、実行結果をネットワークＲＭ１３１に返す。
［ステップＳ５７］ネットワークＲＭ１３１は、ネットワーク機器１６０の設定結果を、システムＲＭ１１１に返す。【０１５１】
図１９は、サーバ追加処理の手順を示す第３のシーケンス図である。
［ステップＳ５８］システムＲＭ１１１は、ネットワーク機器の設定が完了したのを受けて、アプリケーション起動のアクションリクエストをサーバＲＭ１２１に対して送信する。【０１５２】
［ステップＳ５９］サーバＲＭ１２１は、アクションハンドラテーブル１２１ａを取得し、アクションリクエストで指定されたアクションを検索する。この場合、アクションハンドラテーブル１２１ａからは、適当なレコードが見つからない。【０１５３】
［ステップＳ６０］サーバＲＭ１２１は、Target要素５０（図７参照）に基づいて、受け取ったアクションリクエストがサーバコンピュータ１４０に対するものであることを認識する。そこで、サーバＲＭ１２１は、サーバコンピュータ１４０のエージェント１４１に向けてアクションリクエストを転送する。【０１５４】
［ステップＳ６１］エージェント１４１は、アクションハンドラテーブル１４１ａを取得し、アクションリクエストで指定されたアクションを検索する。このとき、ソフトウェアのsetアクションのアクションハンドラ「swclt」が検出される（図１６参照）。【０１５５】
［ステップＳ６２］エージェント１４１は、アクションハンドラ「swctl」のsetアクションを実行する。
［ステップＳ６３］エージェント１４１は、アクションハンドラに基づくアクションとして、サービスを起動する。【０１５６】
［ステップＳ６４］エージェント１４１は、アプリケーションを起動したことを、サーバＲＭ１２１に通知する。
［ステップＳ６５］サーバＲＭ１２１は、アプリケーションを起動したことを、システムＲＭ１１１に通知する。【０１５７】
［ステップＳ６６］システムＲＭ１１１は、アプリケーションを起動したことを、システムＲＭ２１１に通知する。
以上のようにして、サイト２００側のシステムＲＭ２１１からの指示によって、サイト１００で管理されているシステム内で、Ｗｅｂサーバの追加が行われる。以下、アクションリクエストの伝搬の様子およびアクションリクエストの具体例を説明する。【０１５８】
なお、以下の説明において、各コンポーネントの名称に図４中の符号を付加した文字列を、本システム内で各コンポーネントを一意に識別するための名称とする。例えば、システムＲＭ２１１（「２１１」は図４における符号）の名称を「システムＲＭ２１１」とする。【０１５９】
図２０は、サーバの構成情報を取得する際のアクションリクエストの伝搬図である。システムＲＭ２１１において、どのような空きサーバがあるかの情報を取得するためのアクション７１が生成される。そして、システムＲＭ２１１からシステムＲＭ１１１に、そのアクション７１を依頼するためのアクションリクエスト８１が渡される。【０１６０】
システムＲＭ１１１では、指定されたアクション７１の処理内容に対応するアクションハンドラ（空きサーバの情報取得）を有していない。そのため、システムＲＭ１１１は、アクションリクエスト８１の送信元の内容を書き換え、アクションリクエスト８２とする。そして、システムＲＭ１１１は、アクションリクエスト８２をサーバＲＭ１２１に渡す。【０１６１】
サーバＲＭ１２１では、アクションリクエスト８２で指定されたアクション７１に対応する処理（空きサーバの情報取得）を実行する。
図２１は、サーバの構成情報を取得する際に最初に出力されるアクションリクエストの例を示す図である。このアクションリクエスト８１は、ＸＭＬで記述されている。【０１６２】
<?xml version="1.0" ?>は、ＸＭＬのバーションが示されている。<ActionRequest id="aq1" createDte="2004-08-24T12:00:00">は、アクションリクエストの識別情報"aq1"と、生成日時"2004-08-24T12:00:00"とを示している。【０１６３】
<Creator name="システムＲＭ２１１" id="SysRM2"/>は、システムＲＭ２１１で生成されたことを示している。<Sender name="システムＲＭ２１１" id="SysRM2"/>は、システムＲＭ２１１から送信されたことを示している。【０１６４】
<!-- フリーのサーバリスト情報を取得する-->以下の記述でアクションが定義されている。
<GetAction id="action 1" sync="false">は、getのアクションであり、識別情報が"action 1"であることを示している。【０１６５】
<Target site="Site1" class="ServerDomain" name="ServerPool" id="svcpool">は、対象のサイト名、処理の対象種別等を示している。
<Structure key="FreeServerList"/>は、結果として取得すべきデータの名称を示している。【０１６６】
このようなアクションリクエスト８１がシステムＲＭ２１１からシステムＲＭ１１１に渡される。システムＲＭ１１１からサーバＲＭ１２１へは、アクションリクエスト８１に基づいて生成されたアクションリクエスト８２が渡される。【０１６７】
図２２は、システムＲＭで転送された後のアクションリクエストの例を示す図である。このアクションリクエスト８２では、アクションリクエストの識別情報が"aq2"に変更され、送信元の名称が"システムＲＭ１１１"に変更されている。アクションの内容は同じである。【０１６８】
このようなアクションリクエスト８２がサーバＲＭ１２１に渡されることで、サーバＲＭ１２１においてフリーのサーバリスト情報が生成され、アクションの生成もとであるシステムＲＭ２１１にサーバリスト情報が送られる。【０１６９】
次に、システムＲＭ２１１からの指示に応じたサーバ追加処理の際のアクションリクエストの伝搬の様子およびアクションリクエストの具体例を説明する。
図２３は、サーバを追加する際のアクションリクエストの伝搬図である。システムＲＭ２１１では、サーバコンピュータ１４０をサービスに追加するアクション７２が生成される。そして、システムＲＭ２１１は、生成したアクション７２の処理を依頼するためのアクションリクエスト９１を生成し、システムＲＭ１１１に渡す。【０１７０】
システムＲＭ１１１では、ネットワークＲＭ１３１に渡すべきアクション７３と、サーバＲＭ１２１に渡すべきアクション７４とが生成される。そして、アクション７３の処理を依頼するアクションリクエスト９２が生成され、ネットワークＲＭ１３１に渡される。すると、ネットワークＲＭ１３１において、アクション７３の処理が実行される。【０１７１】
その後、システムＲＭ１１１において、アクション７４の処理を依頼するアクションリクエスト９３が生成され、サーバＲＭ１２１に渡される。サーバＲＭ１２１では、アクション７４に対応するアクションハンドラが登録されていないことを確認し、アクション７４の処理を依頼するアクションリクエスト９４をエージェント１４１に渡す。すると、エージェント１４１において、アクション７４の処理が実行される。【０１７２】
図２４は、サーバを追加する際に最初に出力されるアクションリクエストの例を示す図である。このアクションリクエスト９１は、ＸＭＬで記述されている。アクションリクエスト９１では、生成元としてシステムＲＭ２１１の名称が設定され、送信元としてシステムＲＭ２１１が設定されている。そして、稼働中のサービスにサーバを新たに割り当てるためのアクションが設定されている。【０１７３】
このようなアクションリクエスト９１がシステムＲＭ２１１からシステムＲＭ１１１に渡される。システムＲＭ１１１からネットワークＲＭ１３１へは、アクションリクエスト９１に基づいて生成されたアクションリクエスト９２が渡される。【０１７４】
図２５は、システムＲＭで転送された後のアクションリクエストの例を示す図である。このアクションリクエスト９２では、生成元としてシステムＲＭ１１１の名称が設定され送信元として、システムＲＭ１１１の名称が設定されている。また、アクションの内容が、ネットワーク機器１６０のＶＬＡＮ設定を変更するためのアクションに変更されている。【０１７５】
このようなアクションリクエスト９２がネットワークＲＭ１３１に渡されることで、ネットワークＲＭ１３１において、ネットワーク機器１６０のＶＬＡＮ設定が行われる。
その後、システムＲＭ１１１からネットワークＲＭ１３１へ、アクションリクエスト９１に基づいて生成されたアクションリクエスト９３が渡される。【０１７６】
図２６は、システムＲＭで転送された後のアクションリクエストの例を示す図である。このアクションリクエスト９３では、生成元としてシステムＲＭ１１１の名称が設定され送信元として、システムＲＭ１１１の名称が設定されている。また、アクションの内容が、サーバコンピュータ１４０によるアプリケーションの起動処理に変更されている。【０１７７】
このようなアクションリクエスト９３がシステムＲＭ１１１からサーバＲＭ１２１に渡される。サーバＲＭ１２１からエージェント１４１へは、アクションリクエスト９３に基づいて生成されたアクションリクエスト９４が渡される。【０１７８】
図２７は、サーバＲＭ１２１で転送された後のアクションリクエストの例を示す図である。このアクションリクエスト９４では、アクションリクエストの識別情報が"aq5"に変更され、送信元の名称が"サーバRM121"に変更されている。アクションの内容は同じである。
【０１７９】
このようなアクションリクエスト９４がエージェント１４１に渡されることで、エージェント１４１において、サーバコンピュータ１４０内でのサーバアプリケーションの起動処理が行われる。【０１８０】
以上のようにして、リソースマネージャ間の相互接続性を向上させ、さらに高度な管理機能を提供することが可能となる。これは、高機能、高信頼、高可用なリソース管理システムの構築に対して有用である。【０１８１】
すなわち、本実施形態のリソース管理方法によれば、リソースマネージャおよびリソース上で稼動するエージェント間を共通インタフェースを用いてやりとりする。そして、コンポーネントごとに用意するアクションハンドラによって、指定されたアクションが当該コンポーネント独自のコマンド、スクリプトに割り付けられる。これによって、従来よりも相互接続性が格段に向上する。その結果、これまで人手で各リソースマネージャ、リソースの設定を行っていた処理を自動化することが可能となり、リソース管理の容易化、コスト削減へと結びつく。【０１８２】
また、各コンポーネントではアクション関係の処理実行履歴はすべてログに記録される。例えば、各アクションリクエストはそのリクエストを生成したコンポーネント上のログＤＢに保持される。なお、ログとしては、図１２に示す情報以外にも様々な情報を記録することもできる。これにより、アクションの追跡可能性を確保することができ、管理機能の向上につながる。【０１８３】
なお、図２に示した例では、各コンポーネントが個別のサーバコンピュータに実装されているが、１つのサーバコンピュータ内に複数のコンポーネントを実装することもできる。【０１８４】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、管理サーバコンピュータやサーバコンピュータが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。【０１８５】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。【０１８６】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。【０１８７】
上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。
【符号の説明】
【０１８８】
１，２，３，４  管理サーバコンピュータ
１ａ  記憶手段
１ａａ  アクションハンドラテーブル
１ｂ  アクションハンドラ検索手段
１ｃ  アクションリクエスト転送手段
１ｄ  アクション実行手段
７ａ  第１のアクションリクエスト
７ｂ  第２のアクションリクエスト
７ｃ  第３のアクションリクエスト
【図１】
0004522413.tif 000002
【図２】
0004522413.tif 000003
【図３】
0004522413.tif 000004
【図４】
0004522413.tif 000005
【図５】
0004522413.tif 000006
【図６】
0004522413.tif 000007
【図７】
0004522413.tif 000008
【図８】
0004522413.tif 000009
【図９】
0004522413.tif 000010
【図１０】
0004522413.tif 000011
【図１１】
0004522413.tif 000012
【図１２】
0004522413.tif 000013
【図１３】
0004522413.tif 000014
【図１４】
0004522413.tif 000015
【図１５】
0004522413.tif 000016
【図１６】
0004522413.tif 000017
【図１７】
0004522413.tif 000018
【図１８】
0004522413.tif 000019
【図１９】
0004522413.tif 000020
【図２０】
0004522413.tif 000021
【図２１】
0004522413.tif 000022
【図２２】
0004522413.tif 000023
【図２３】
0004522413.tif 000024
【図２４】
0004522413.tif 000025
【図２５】
0004522413.tif 000026
【図２６】
0004522413.tif 000027
【図２７】
0004522413.tif 000028