(57)【要約】【課題】  新たにリソースを追加する場合にも、リソースマネージャの更新が不要であり、かつ、システムが多数のリソースを含む場合にも、容易にシステム全体の構成を把握できるようにすること。【解決手段】  コンピュータシステムは、ハードウェアリソース１、OSリソース２、プログラムリソース３、ネットワークリソース４、ストレージリソース５を備え、これらのリソースは、(サーバRM(リソースマネージャ)１０、ソフトウェアRM２０、ネットワークRM３０、ストレージRM４０により管理される。リソースマネージャ１０〜４０の上位に、システム全体を管理するシステムRM５０が存在しており、このシステムＲＭは構成管理５１とイベントコントローラ５２とを備える。構成管理は、XMLベースのテキストで定義されたリソースの構成定義を管理し、イベントコントローラは、構成管理から渡されるイベント、または、リソース独自制御インターフェースを処理する。【選択図】  図１
2006065811.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェア、ソフトウェアの各種リソース毎にリソースマネージャを設けると共に、前記リソースマネージャを含むシステム全体を管理するシステムリソースマネージャを設け、
該システムリソースマネージャの構成管理は、XMLベースで記述された定義情報により、システム構成を把握すると共に、各リソースの制御方法を検知し、
前記システムリソースマネージャは、各リソースへの操作指示を受け付けると、構成管理にて制御が必要なリソースを特定し、イベント制御にて対象リソースを管理する各リソースマネージャへイベントを送信し、イベントを受け取った各リソースマネージャは、構成管理にて制御が必要なリソースを特定し、イベント制御にて、対象リソースに対して制御指示を送ることでリソースを操作することを特徴とするリソース管理方法。
【請求項２】
リソースの前記定義情報を物理情報と論理情報とに分けて管理することを特徴とする請求項１記載のリソース管理方法。
【請求項３】
リソースに対する制御方法を論理的に管理し、論理化した制御方法と実際の呼び出しインターフェースとの関連付けをXMLベースの制御定義情報として定義することを特徴とする請求項２に記載のリソース管理方法。
【請求項４】
ハードウェア、ソフトウェアの各種リソース毎に設けられたリソースマネージャと、
前記リソースマネージャを含むシステム全体を管理するシステムリソースマネージャとを備え、
該システムリソースマネージャの構成管理は、XMLベースで記述された定義情報により、システム構成を把握すると共に、各リソースの制御方法を検知し、
前記システムリソースマネージャは、各リソースへの操作指示を受け付けると、構成管理にて制御が必要なリソースを特定し、イベント制御にて対象リソースを管理する各リソースマネージャへイベントを送信し、イベントを受け取った各リソースマネージャは、構成管理にて制御が必要なリソースを特定し、イベント制御にて、対象リソースに対して制御指示を送ることでリソースを操作することを特徴とするリソース管理装置。
【請求項５】
ハードウェア、ソフトウェアの各種リソース毎に設けられたリソースマネージャと、
前記リソースマネージャを含むシステム全体を管理するシステムリソースマネージャとを備え、
該システムリソースマネージャの構成管理は、XMLベースで記述された定義情報により、システム構成を把握すると共に、各リソースの制御方法を検知し、
前記システムリソースマネージャは、各リソースへの操作指示を受け付けると、構成管理にて制御が必要なリソースを特定し、イベント制御にて対象リソースを管理する各リソースマネージャへイベントを送信し、イベントを受け取った各リソースマネージャは、構成管理にて制御が必要なリソースを特定し、イベント制御にて、対象リソースに対して制御指示を送ることでリソースを操作することを特徴とするリソース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムを構成するハードウェアやソフトウェアを論理情報(リソース)として管理するための方法及び装置に関し、特に、リソース独自の構成定義によらず、各種のリソースを一括して管理することができるリソース管理方法、装置及びプログラムに関する。
【背景技術】
【０００２】
リソースマネージャを用いて複数のハードウェア、ソフトウェアで構成されるコンピュータシステムを管理する方法は従来から知られている。例えば、特許文献１の請求項１には、管理対象である管理対象ノードに対して、管理操作を記述した管理シナリオを送信する管理シナリオ送信手段を備えるマネージャ(リソースマネージャ)が開示されている。
【特許文献１】特開２００２−８２９６５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１を含めて、従来の管理方法では、システムに新しいハードウェア、ソフトウェア(以降、リソースと呼ぶ)を追加してリソースマネージャで管理する場合、各リソースで構成定義、及び制御方法が異なり、かつ、各リソースマネージャで独自のリソース制御機構を実装しているため、各リソースマネージャの定義方法に従ってリソース定義を追加し、かつ、対応プログラムをリソースマネージャにインストールして更新する必要があり、リソースの管理コストが大きいとう問題がある。また、各リソースが独自の構成定義を持つため、リソースの数が増加すると、構成管理が複雑になり、システム全体構成の把握が困難になるという問題もある。
【０００４】
さらに、管理方法が異なる複数のリソースマネージャ間でリソースを管理する場合、リソースをサポートしているリソースマネージャでは管理できるが、リソースをサポートしていないリソースマネージャでは管理できないという問題がある。リソースマネージャが他社ベンダの提供するリソースを管理するためには、ベンダ独自のリソース制御部との連携プログラムを開発する必要があるが、管理方法が異なる複数のリソースマネージャを利用している場合には、各リソースマネージャ毎に同様の連携プログラムを開発しなければならない。
【０００５】
本発明は、上記の問題点に鑑みてなされたものであり、その課題は、新たにリソースを追加する場合にも、リソースマネージャの更新が不要であり、かつ、システムが多数のリソースを含む場合にも、容易にシステム全体の構成を把握することができるリソース管理方法及び装置を提供することにある。
【課題を解決するための手段】
【０００６】
上述した課題を解決するために、本発明によるリソース管理方法は、ハードウェア、ソフトウェアの各種リソース毎にリソースマネージャを設けると共に、前記リソースマネージャを含むシステム全体を管理するシステムリソースマネージャを設け、システムリソースマネージャの構成管理は、XMLベースで記述された定義情報より、システム構成を把握すると共に、各リソースの制御方法を検知し、システムリソースマネージャは、各リソースへの操作指示を受け付けると、構成管理にて制御が必要なリソースを特定し、イベント制御にて対象リソースを管理する各リソースマネージャへイベントを送信し、イベントを受け取った各リソースマネージャは、構成管理にて制御が必要なリソースを特定し、イベント制御にて、対象リソースに対して制御指示を送ることでリソースを操作することを特徴とする。
【０００７】
また、リソースの定義情報を物理情報と論理情報とに分けて管理することが望ましい。さらに、リソースに対する制御方法を論理的に管理してもよい。この場合、制御キーは、例えば、起動(Start)、停止(Stop)、設定(Configure)の３つで管理することができる。そして、論理化した３つの制御方法(制御キー)と実際の呼び出しインターフェースとの関連付けをXMLベースの制御定義情報として定義しておくことが望ましい。
【０００８】
なお、本発明にかかるリソース管理装置及びリソース管理プログラムは、ハードウェア、ソフトウェアの各種リソース毎に設けられたリソースマネージャと、  前記リソースマネージャを含むシステム全体を管理するシステムリソースマネージャとを備え、システムリソースマネージャの構成管理は、XMLベースで記述された定義情報により、システム構成を把握すると共に、各リソースの制御方法を検知し、システムリソースマネージャは、各リソースへの操作指示を受け付けると、構成管理にて制御が必要なリソースを特定し、イベント制御にて対象リソースを管理する各リソースマネージャへイベントを送信し、イベントを受け取った各リソースマネージャは、構成管理にて制御が必要なリソースを特定し、イベント制御にて、対象リソースに対して制御指示を送ることでリソースを操作することを特徴とする。
【発明の効果】
【０００９】
以上のように構成された本発明のリソース管理方法、装置及びプログラムによれば、定義情報をテキストデータであるXMLベースで記載し、各リソースマネージャはこの定義情報に基づいてリソースを運用管理するため、システムに新たなリソースを追加してもリソースマネージャのソフトウェアの更新が不要であり、リソースの管理コストを抑えることができる。また、各リソースの構成定義がXMLベースで記載されるため、構成定義がシステム全体で統一され、複数のリソースマネージャを使用した場合にも、システム全体の把握が容易となる。
【００１０】
さらに、リソース情報を物理情報と論理情報とに分けて管理する場合には、論理情報に基づいてリソースを管理、制御することにより、機種依存性のような物理的な制約を排除したリソース管理が可能になり、リソースのポータビリティ(可搬性)を向上させることができる。また、論理化した制御キーと実際の呼び出しインターフェースとを関連付けておくと、リソース毎の制御方法(呼び出しインターフェース)に依存しないリソース制御が可能となる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明にかかるリソース管理方法及び装置の実施形態を図面に基づいて説明する。
<システム構成> 
最初に、図１に基づいて本実施形態のリソース管理方法及び装置が実施されるコンピュータシステムの概要を説明する。図１のコンピュータシステムは、サーバ等のハードウェアリソース１、OS(オペレーションシステム)リソース２、DB(データベース)、MW(ミドルウェア)、AP(アプリケーション)等のプログラムリソース３から構成されるソフトウェアリソース、IP-COM、SH、Cisco、BL-SW等のネットワークリソース４、ET社製、EMC社製、HITACHI社製等の複数規格のストレージリソース５を備えている。そして、ハードウェアリソース１はハードウェアであるサーバを管理するサーバ・リソースマネージャ(サーバRM)１０により管理されている。OSリソース２はOSI(One-Shot Installer, ワンショットインストーラー)２１、プログラムリソース３はAS(Application Service, アプリケーションサービス)２２をそれぞれ介してソフトウェアを管理するソフト・リソースマネージャ(ソフトウェアRM)２０により管理されている。ネットワークリソース４は、ネットワーク・リソースマネージャ(ネットワークRM)３０により管理され、ストレージリソース５はストレージ・リソースマネージャ(ストレージRM)４０により管理されている。
【００１２】
また、これらのリソースマネージャ１０〜４０の上位に、システム全体を管理するシステム・リソースマネージャ(システムRM)５０が存在しており、このシステムＲＭ５０は、構成管理５１とイベントコントローラ５２とを備えている。なお、システムＲＭ以外の下位のリソースマネージャも、構成管理CとイベントコントローラＥとを備えている。
【００１３】
リソースマネージャは、システムを構成するリソースを管理するリソースマネージャ、または、リソースマネージャを管理するソフトウェアをいう。また、構成管理は、XMLベースのテキストで定義されたリソースの構成定義を管理する機能をいう。実施形態では、システムRMの構成管理は、ユーザからのオペレーションを具体的なリソース制御指示であるイベントのリストへ変換し、イベントコントローラへ渡す機能を果たす。また、システムRMの構成管理は、XMLベースで記述された定義情報(RCXML)の構成管理によりシステム構成を把握し、RCXMLの論理制御機構より各リソースの制御方法を知る。システムRM以外のリソースマネージャの構成管理ではイベントをリソース毎に定義されたリソース独自制御インターフェースへ変換し、イベントコントローラに渡す。さらに、イベントコントローラは、構成管理から渡されるイベント、または、リソース独自制御インターフェースを処理する。実施形態では、システムRMのイベントコントローラは各リソースマネージャへイベントを送信し、システムRM以外の各リソースマネージャのイベントコントローラは、各リソース固有の制御インターフェースを呼び出し、リソースを制御する。
【００１４】
なお、「オペレーション」とは、ユーザからシステムRMへ通知される操作指示、「イベント」とは、システムRMのイベントコントローラから各リソースマネージャへ送られるリソース制御指示をいう。また、「リソース独自制御インターフェース」とは、各リソースマネージャのイベントコントローラが対象リソースを制御するためのリソース固有インターフェースによるリソース制御指示をいう。
【００１５】
上記の構成によれば、システムRM５０は、各リソースへの操作指示(オペレーション)を受け付けると、構成管理５１にて制御が必要なリソースを特定し、イベントコントローラ５２にて対象リソースを管理する各リソースマネージャへイベントを送信する。イベントを受け取った下位のリソースマネージャは、構成管理Ｃにて制御が必要なリソースを特定し、イベントコントローラＥにて、対象リソースに対して制御指示を送ることでリソースを操作する。
【００１６】
<管理概念>
次に、上記のシステムを前提として、実施形態のリソース管理方法における管理概念について説明する。
1) 運用管理対象のハード／ソフトを物理リソースではなく、論理リソースとして共通管理する(リソースの論理化)。
リソースの情報は物理情報と物理情報にリンクした論理情報で管理する。なお、「物理リソース」とは、システムを構成する実際のリソース(物理ハードウェア、ソフトウェア)、「論理リソース」とは、物理リソースを仮想化したり、タイプ別にグルーピングしたものである。各リソースマネージャによって物理リソースの捉え方が異なるので、論理リソースによって最適な形態で情報を保持し、物理リソースへのリンク情報によってリソースマネージャ間の対応関係を取得する。リソースマネージャは、論理リソースに対して操作を行う。物理情報、論理情報は、それぞれ物理リソース、論理リソースに関する情報である。
2) リソースに対する制御方法を論理的に管理する。
制御キーはStart (起動)、Stop (停止)、Configure (設定)の3つの制御キーで管理される(制御方法の論理化)。「Start」は、リソースの起動(例えば、ソフトウェアの起動、ハードウェアの電源オン)、「Stop」は、リソースの停止(例えば、ソフトウェアの停止、ハードウェアの電源オフ)、「Configure」は、リソース導入、追加、および、変更(例えば、サーバの導入/増設、アプリケーションの追加インストール)をそれぞれ意味する。
【００１７】
<提供機能>
また、実施形態のリソース管理方法で提供される機能は、以下の通りである。
3) 論理化した制御方法(3つの制御キー)と実際の呼び出しインターフェースの関連付けを XML ベース(RCXML)の制御定義情報として定義する論理制御機構を提供し、管理対象毎の制御方法(呼び出しインターフェース)に依存しないリソース制御ができるようにする。すなわち、各物理リソースに対して<Actions>要素で各制御キーに対する制御方法を定義し、<Action>要素で各制御方法(url)、および、制御キー(type)を定義する。図２に、RCXMLによる論理キーと実際の呼び出しインターフェースとの対応定義の例を示す。リストの６〜８行目において、３つの制御キーに対応する制御方法が定義されている。
4) 物理リソースとリンクした論理リソースの情報を XML ベースの構成管理機構で定義し、論理情報の変更によりリソース構成の変更を行う。すなわち、RCXML の<Components> スキーマでリソースの物理情報を定義し、<Logical Views>スキーマで論理情報を定義する。リソースの物理情報と論理情報は、論理情報である<Logical Views>スキーマの<LinkId>要素に物理情報の<id>の値を指定することでリンクされる。リソースの追加、変更、削除は<Logical Views>スキーマに定義する各リソース定義の追加、変更、削除により実施される。図３に、RCXMLによるリソースの物理情報と論理情報との対応定義の例を示す。３行目に定義された物理リソースであるサーバのid “psvr001”に対して、<Logical Views>スキーマの２行目で、論理リソースのサーバid “LP001”がリンクしている。
【００１８】
次に、上記の構成を前提として、実際の運用例を２例説明する。
<運用例１>
運用例１では、既存のコンピュータシステムに新規のソフトウェアＡをインストールする場合の手順について説明する。運用例１における XML の記述例を図４に示す。システムRMは、構成管理でRCXML上のソフトウェアリソース追加を検出し、ソフトウェアのインストール、および起動をソフトウェアRMへ指示する必要があることを認識する(0-1)。また、論理制御機構によりリソース追加(制御キー:Configure,および Start)時のリソース制御のための呼び出しインターフェースを認識する(0-2)。
【００１９】
そして、システムRMは、以下のようにソフトウェアRMへConfigure,Startの順でリソース制御指示を送る。図５は、システムＲＭからの指示を受けたソフトウェアＲＭ以下の処理の手順を示す。
(1) ソフトウェアRMは、システムRMからの Configure 指示を受付け、OSI21へソフトウェアのインストールを指示する。OSI21はサーバへソフトウェアをインストールし、ソフトウェア起動のために必要な環境設定を呼び出しインターフェースに指定された方法(/mgr/app1/setappconf.sh 実行)で行う。
(2) 続いてソフトウェアRMは、システムRMからのソフトウェア起動指示を受け、AS22へソフトウェアの起動を指示する。AS22はリソース制御キー(type="Start")で指定された呼び出しインターフェース(/mgr/app1/start.sh 実行)でソフトウェアを起動する。
【００２０】
運用例１の手順を、より具体的に図６及び図７のフローチャートを用いて説明する。以下の手順では、ソフトウェアのインストール前に事前定義を行い、この定義に基づいてソフトウェアをインストールする。図６は事前定義、図７はソフトウェアのインストールの処理をそれぞれ示す。
【００２１】
[事前定義]
リソース識別子mw01で示されるソフトウェアの提供元から提供された、mw01の起動、停止、導入/設定時に呼び出すインターフェースを表1に示すようにリソース制御情報として定義する(S001)。 すなわち、mw01を制御するためのリソース独自制御インターフェースを3つの制御種別にマッピングする。起動(Start)は /mgr/app1/start.sh を呼び出すことで実現される。停止(Stop)は /mgr/app1/stop.sh を呼び出すことで実現される。導入/設定(configure)は /mgr/app1/setappconf.sh を呼び出すことで実現される。実際のリソースに対する制御は上記を組み合わせることで実現する。なお、以下の表中で他の識別子で表されるリソースは、後述の運用例２において利用される。
【００２２】
【表１】
2006065811.tif 000003
【００２３】
次に、mw01を運用する際に必要な表2に示す定義情報(インストール先、チューニングパラメタなど)をmw01の論理リソースlogical_mw01のリソース定義情報として定義する(S002)。
【００２４】
【表２】
2006065811.tif 000004
【００２５】
続いて、表3に示すように、ソフトウェアAの物理リソースmw01を論理リソースlogical_mw01へ結びつけるリンク情報を定義する(S003)。
【００２６】
【表３】
2006065811.tif 000005
【００２７】
ユーザから見たソフトウェアAのインストールは、"ソフトウェアAをインストールする"というオペレーションであるが、システムRMは、この操作を以下のイベントに分割して実施する。この手順を表４に示すイベントリストとして定義する (ユーザからのオペレーションに対する各リソースマネージャへのイベントリストの作成, S004)。
1)ソフトウェアRMへlogical_mw01の導入/設定(Configure)指示
2)ソフトウェアRMへlogical_mw01の起動(Start)指示
【００２８】
【表４】
2006065811.tif 000006
【００２９】
次に、表５に示すように、リソースlogical_mw01を業務service01へ登録する (業務定義情報への登録, S005) 。
【００３０】
【表５】
2006065811.tif 000007
【００３１】
最後に、実運用時の業務、および、ハード構成の関係を定義する(S006)。ここでは、表６に示すように、業務リソースservice01、サーバリソースlogical_server、および、ストレージリソースlogical_storageを1つのインスタンスとしてインスタンス情報へ定義する。
【００３２】
【表６】
2006065811.tif 000008
【００３３】
次に、上記の事前登録に基づき、ソフトウェアAをインストールする場合における各部の働きについて説明する。
[動作]
システムRMの構成管理は、表４に定義される情報に基づいて、表７に示すようなソフトウェアAのインストールに必要な各リソースマネージャへの制御(イベント)のリストを得る(S101)。
【００３４】
【表７】
2006065811.tif 000009
【００３５】
続いて、システムRMの構成管理は、システムRMのイベントコントローラへ、イベントのリスト(表７)を渡す(S102)。
システムRMのイベントコントローラは、構成管理から受け取ったイベントのリスト(表７)について、リストの先頭から"RMのタイプ"に指定されている各リソースマネージャの構成管理へリソース制御イベントを送る(S103)。同じリソースマネージャに対するイベントはまとめて送付する。ここでは、ソフトウェアRMに対して表7のイベントのリストを送付する。
【００３６】
ソフトウェアRM２０の構成管理は、表7のイベントのリストの各リソース制御種別(ConfigureとStart)に対するリソース独自制御インターフェースを以下の手順で求める(S104)。
(1) 表3の物理リソース、論理リソースリンク情報を参照し、表7の論理リソース識別子logical_mw01に対応する物理リソース識別子mw01を求める。
(2) 表1のリソース制御情報を参照し、ソフトウェアmw01に対する制御種別Configureの呼び出しインターフェース/mgr/app1/setappconf.sh、および、Startの呼び出しインターフェース/mgr/app1/start.shを求める。
【００３７】
続いて、ソフトウェアRM２０の構成管理は、表５の業務定義情報よりソフトウェアlogical_mw01が定義されている業務service01を求め(S105)、表６のインスタンス情報より、service01が動作するサーバがlogical_serverであることを認識する(S106)。そして、ソフトウェアRM２０の構成管理は、表７の各行(イベント)について、制御対象のソフトウェアリソース識別子logical_mw01、サーバリソース識別子logical_server、および、制御種別(Configure、または、Start)のリソース独自制御インターフェースを表８に示すように、リソース制御情報として定義し、イベントコントローラへ渡す(S107)。
【００３８】
【表８】
2006065811.tif 000010
【００３９】
ソフトウェアRM２０のイベントコントローラは、表８のリソース制御情報をリストの先頭から順に実行し(S108)、これによりソフトウェアＡがインストールされて実行される。詳細は以下の通りである。
(1)  ソフトウェアlogical_mw01がサーバlogical_server上にインストールされていない場合は、インストールする。
(2)  1行目に定義されているリソース制御を実施する。すなわち、表２のリソース定義情報を参照し、呼び出しインターフェース/mgr/app1/setappconf.shでソフトウェアlogical_mw01の設定(Configure)を行う。
(3)  ２行目に定義されているリソース制御を実施する。すなわち、呼び出しインターフェース/mgr/app1/start.shで、ソフトウェアlogical_mw01の起動(Start)を行う。
【００４０】
<運用例２>
次に、運用例２として、サーバＢをシステムへ追加する場合の手順について説明する。図８は、運用例２の手順を示す。図８では、サーバは、ハードウェアリソースと、OSリソースとから構成されるものとする(実際には後述のようにミドルウェア、ストレージ、ネットワーク等のリソースも必要となるが、ここでは簡単のため２種類のリソースについてのみ示す)。
(1) OSを起動するための設定が存在しないため、サーバはハードウェアのBIOSレベルで停止する必要がある。サーバRMの構成管理は、追加するハードウェアリソースの構成情報(RCXML)に基づいて、ハードウェアリソースにConfigureを指示し、ハードウェア起動時にBIOSレベルで停止するよう設定する。
(2) サーバRMのイベントコントローラは、ハードウェアリソースにStart(power ON)を指示する。サーバは、(1)の設定によりBIOSレベルで停止する。
(3) サーバRMの構成管理は、起動するOSリソースの構成情報(RCXML)に基づいて、OSリソースにConfigureを指示し、OSの起動に必要な情報(例えば、コンピュータ名)をサーバのOSに設定する。
(4) 続いてサーバRMのイベントコントローラは、OSリソースにStartを指示し、OSをブートする。OSが起動することでサーバのシステムへの組み込みは終了する。
【００４１】
運用例２の手順を、より具体的に図９のフローチャートを用いて説明する。以下の手順では、サーバＢの追加前に事前定義を行い、この定義に基づいてサーバＢを追加する。ただし、事前定義の手順の概略は図６に示した運用例１と同様であるため図示は省略し、サーバの追加の処理を図９に示す。
[事前定義]
サーバＢを構成するハードウェア、ストレージ、ネットワーク、ソフトウェア(OS, MW)の各提供元が提供するそれぞれのリソースの起動、停止、導入/設定時に呼び出す以下のインターフェースを表1に示すようにリソース制御情報として定義する (サーバＢを制御するためのリソース独自制御インターフェースを3つの制御種別にマッピングする、S001) 。具体的な内容は以下の通りである。実際のリソースに対する制御は以下を組み合わせることで実現する。
ハードウェアpw01
起動(Start)は /pwmgr/start を呼び出すことで実現される。
停止(Stop)は /pwmgr/stop を呼び出すことで実現される。
導入/設定(configure)は /pwmgr/setpw を呼び出すことで実現される。
ストレージstor01
起動(Start)は /stormgr/start を呼び出すことで実現される。
停止(Stop)は /stormgr/stop を呼び出すことで実現される。
導入/設定(configure)は /stormgr/setstor を呼び出すことで実現される。
ソフトウェア(オペレーティングシステム:OS)os01
起動(Start)は /osmgr/startup を呼び出すことで実現される。
停止(Stop)は/osmgr/shutdown を呼び出すことで実現される。
導入/設定(configure)は /osmgr/setup を呼び出すことで実現される。
ソフトウェア(ミドルウェア)middle01
起動(Start)は /mwmgr/start を呼び出すことで実現される。
停止(Stop)は /mwmgr/stop を呼び出すことで実現される。
導入/設定(configure)は /mwmgr/setmw を呼び出すことで実現される。
ネットワークipcom01
起動(Start)は /netrm/start を呼び出すことで実現される。
停止(Stop)は /netrm/stop を呼び出すことで実現される。
導入/設定(configure)は /netrm/netconf を呼び出すことで実現される。
【００４２】
サーバＢを運用する際に必要な定義情報(インストール先、チューニングパラメタなど)を表2に示すように、サーバＢを構成する各論理リソース(ハードウェアlogical_pw01、ストレージlogical_stor01、オペレーティングシステムlogical_os01、ミドルウェアlogical_middle01、ネットワークlogical_ipcom01)のリソース定義情報として定義する(S002)。
【００４３】
続いて、サーバＢを構成する各物理リソース(pw01, stor01, os01, middle01, ipcom01)を表３に示すように、論理リソース(logical_pw01,logical_stor01, logical_os01, logical_middle01, logical_ipcom01)へ結びつけるリンク情報を定義する(S003)。
【００４４】
ユーザから指示されるサーバＢの追加は、"サーバＢを追加する"というオペレーションであるが、システムＲＭは、この操作を以下のイベントに分割して実施する。この手順を表４に示すイベントリストとして定義する(ユーザからのオペレーションに対する各リソースマネージャへのイベントリストの作成、S004)。
1)サーバRMへlogical_pw01の起動(Start)指示
2)サーバRMへlogical_stor01の設定(Configure)指示
3)ソフトウェアRMへlogical_os01の導入、設定(Configure)指示
4)ソフトウェアRMへlogical_middle01の導入、設定(Configure)指示
5)ソフトウェアRMへlogical_middle01の起動(Start)指示
6)ネットワークRMへlogical_ipcom01の起動(Start)指示
【００４５】
次に、表５に示すように、リソースlogical_os01とlogical_middle01を業務service02へ登録し(業務定義情報への登録、S005)、実運用時の業務、および、ハード構成の関係を定義する(S006)。ここでは、  業務リソースservice02、サーバリソースlogical_pw01、ストレージリソースlogical_stor01、および、ネットワークリソースlogical_ipcom01を表６に示すように、1つのインスタンスとしてインスタンス情報へ定義する。
【００４６】
次に、上記の事前登録に基づき、サーバＢを追加する場合における各部の働きについて説明する。
[動作]
システムRMの構成管理は、表４に定義される情報に基づいて、表９に示すようなサーバＢの追加に必要な各リソースマネージャへの制御(イベント)のリストを得る(S201)。
【００４７】
【表９】
2006065811.tif 000011
【００４８】
続いて、システムRMの構成管理は、システムRMのイベントコントローラへ、イベントのリスト(表９)を渡す(S202)。
システムRMのイベントコントローラは、構成管理から受け取ったイベントのリスト(表９)について、リストの先頭から"RMのタイプ"に指定されている各リソースマネージャの構成管理へリソース制御イベントを送る(S203)。同じリソースマネージャに対するイベントはまとめて送付する。ここでは、サーバRMに対して表１０のイベントのリストを送付し、ストレージRMに対して表１１のイベントのリストを送付し、ソフトウェアRMに対して表１２のイベントのリストを送付し、ネットワークRMに対して表１３のイベントのリストを送付する。
【００４９】
【表１０】
2006065811.tif 000012
【００５０】
【表１１】
2006065811.tif 000013
【００５１】
【表１２】
2006065811.tif 000014
【００５２】
【表１３】
2006065811.tif 000015
【００５３】
以降、各リソースマネージャ(RM)での動作フローを説明する。
サーバRMの構成管理は、表１０のイベントリスト情報のリソース制御種別Startに対するリソース独自制御インターフェースを以下の手順で求める(S204)。
(1) 表3の物理リソース、論理リソースリンク情報を参照し、表１０の論理リソース識別子logical_pw01に対応する物理リソース識別子pw01を求める。
(2) 表1のリソース制御情報を参照し、ソフトウェアpw01に対する制御種別Startの呼び出しインターフェース/pwmgr/startを求める。
【００５４】
そして、サーバRMの構成管理は、表１０のイベントについて、制御対象のサーバリソース識別子logical_pw01、および、制御種別Startの呼び出しインターフェース(リソース独自制御インターフェース)/pwmgr/startを表１４に示すようにリソース制御情報として定義し、イベントコントローラへ渡す(S205)。
【００５５】
【表１４】
2006065811.tif 000016
【００５６】
サーバRMのイベントコントローラは、表１４のリソース制御情報を実行する(S206)。具体的には、1行目に定義されているリソース制御を実施する。すなわち、呼び出しインターフェース/pwmgr/startで、サーバlogical_pw01の起動(Start)を行う。
【００５７】
ストレージRMの構成管理は、表１１のイベントのリストのリソース制御種別Configureに対するリソース固有制御インターフェースを以下の手順で求める(S207)。
(1) 表3の物理リソース、論理リソースリンク情報を参照し、表１１の論理リソース識別子logical_stor01に対応する物理リソース識別子stor01を求める。
(2) 表1のリソース制御情報を参照し、ストレージstor01に対する制御種別Configureの呼び出しインターフェース/stormgr/setstorを求める。
【００５８】
続いて、ストレージRMの構成管理は、表１１のイベントについて、制御対象のストレージリソース識別子logical_stor01、および、制御種別Configureのリソース独自制御インターフェース(呼び出しインターフェース)を表１５に示すようにリソース制御情報として定義し、イベントコントローラへ渡す(S208)。
【００５９】
【表１５】
2006065811.tif 000017
【００６０】
ストレージRMのイベントコントローラは、表１５のリソース制御情報を実行する(S209)。具体的には、1行目に定義されているリソース制御を実施する。すなわち、表2のリソース定義情報を参照し、呼び出しインターフェース/stormgr/setstorでストレージlogical_stor01の設定Configureを行う。
【００６１】
ソフトウェアRMの構成管理は、表１２のイベントのリストの各リソース(logical_os01とlogical_middle01)の各制御種別(ConfigureとStart)に対するリソース独自制御インターフェースを以下の手順で求める(S210)。
(1) 表3の物理リソース、論理リソースリンク情報を参照し、表11の論理リソース識別子logical_os01、および、logical_middle01に対応する物理リソース識別子os01、および、middle01をそれぞれ求める。
(2) 表1のリソース制御情報を参照し、ソフトウェアos01に対する制御種別Configureの呼び出しインターフェース/osmgr/setupを求める。同様に、ソフトウェアmiddle01に対する制御種別Configureの呼び出しインターフェース/mwmgr/setmw、および、Startの呼び出しインターフェース/mwmgr/startを求める。
【００６２】
続いて、ソフトウェアRMの構成管理は、表５の業務定義情報よりソフトウェアlogical_os01、および、logical_middle01が定義されている業務service02を求め、表６のインスタンス情報より、service02が動作するサーバがlogical_pw01であることを認識する(S211)。さらに、ソフトウェアRMの構成管理は、表１２の各行(イベント)について、制御対象のソフトウェアリソース識別子logical_os01、および、logical_middle01、サーバリソース識別子logical_pw01、および、各ソフトウェアリソース識別子の各制御種別(Configure、または、Start)のリソース独自制御インターフェースを表１６に示すように、リソース制御情報として定義し、イベントコントローラへ渡す(S212)。
【００６３】
【表１６】
2006065811.tif 000018
【００６４】
ソフトウェアRMのイベントコントローラは、表１６のリソース制御情報をリストの先頭から順に実行する(S213)。詳細は以下の通りである。
(1) 表１６のリソース制御リスト情報を参照し、ソフトウェアlogical_os01がサーバlogical_pw01上にインストールされていない場合は、インストールする。
(2) 1行目に定義されているリソース制御を実施する。表2のリソース定義情報を参照し、呼び出しインターフェース/osmgr/setupでソフトウェアlogical_os01の設定Configureを行う。
(3) 表１６のリソース制御リスト情報を参照し、ソフトウェアlogical_middle01がサーバlogical_pw01上にインストールされていない場合は、インストールする。
(4) 2行目に定義されているリソース制御を実施する。表2のリソース定義情報を参照し、呼び出しインターフェース/mwmgr/setmwでソフトウェアlogical_ms01の設定Configureを行う。
(5) 3行目に定義されているリソース制御を実施する。呼び出しインターフェース/mwmgr/startで、ソフトウェアlogical_middle01の起動Startを行う。
【００６５】
ネットワークRMの構成管理は、表１３のイベントのリストのリソース制御種別Startに対するリソース独自制御インターフェースを以下の手順で求める(S214)。
(1) 表3の物理リソース、論理リソースリンク情報を参照し、表12の論理リソース識別子logical_ipcom01に対応する物理リソース識別子ipcom01を求める。
(2) 表1のリソース制御情報を参照し、ネットワーク装置ipcom01に対する制御種別Startの呼び出しインターフェース/netrm/startを求める。
【００６６】
続いて、ネットワークRMの構成管理は、表12のイベントについて、制御対象のネットワークリソース識別子logical_ipcom01、および、制御種別Startのリソース独自制御インターフェース(呼び出しインターフェース)/netrm/startを表１７に示すように、リソース制御情報として定義し、イベントコントローラへ渡す(S215)。
【００６７】
【表１７】
2006065811.tif 000019
【００６８】
ネットワークRMのイベントコントローラは、表１７のリソース制御情報を実行する(S216)。具体的には、1行目に定義されているリソース制御を実施する。呼び出しインターフェース/netrm/startで、ネットワークlogical_ipcom01の起動Startを行う。上記の手順により、サーバＢをシステムに追加して作動させることができる。
【００６９】
実施形態のリソース管理方法によれば、新しいハードウェア、ソフトウェアをシステムに追加する際に、XML テキストによるインターフェースを用意するのみで、リソースマネージャのプログラムの更新が不要であり、ハードウェア、ソフトウェアと共に提供されるXMLによる構成定義により、新しい管理対象リソースをリソースマネージャの更新なしに監視対象として追加することが可能である。
【００７０】
また、リソースに関する構成／制御情報の形式を規定することにより(情報の形式化)、ベンダ独自の定義、制御部分を修正する必要がなく、各リソースを共通化された情報で管理、制御することが可能となる。さらに、リソース情報を物理情報と論理情報に分けて管理することにより、操作側は論理情報によりリソースを管理／制御することができるため、物理的な制約を排除したリソース管理が可能となり、リソースのポータビリティ(可搬性)が向上する。
【００７１】
なお、各リソースの構成定義が XML ベースの定義で記述されることで、複数のリソースマネージャを使用したシステム管理においても、システム全体で統一した定義情報を得ることが可能であり、システム全体の構成の把握が容易である。
【図面の簡単な説明】
【００７２】
【図１】本発明のリソース管理方法が実行されるコンピュータシステムの構成を模式的に示すブロック図
【図２】実施形態のリソース管理方法に利用されるXMLファイルのリスト
【図３】実施形態のリソース管理方法に利用されるXMLファイルのリスト
【図４】実施形態のリソース管理方法に利用されるXMLファイルのリスト
【図５】実施形態のリソース管理方法によりソフトウェアを追加する場合の手順を示すブロック図
【図６】実施形態のリソース管理方法によりソフトウェアを追加する場合の事前定義の手順を示すフローチャート
【図７】実施形態のリソース管理方法によりソフトウェアを追加する場合の手順を示すフローチャート
【図８】実施形態のリソース管理方法によりサーバを追加する場合の手順を示すブロック図
【図９】実施形態のリソース管理方法によりサーバを追加する場合の手順を示すフローチャート
【符号の説明】
【００７３】
１      ハードウェアリソース
２      ＯＳリソース
３      プログラムリソース
４      ネットワークリソース
５      ストレージリソース
１０    サーバRM
２０    ソフトウェアRM
３０    ネットワークRM
４０    ストレージRM
５０    システムRM
５１    構成管理
５２    イベントコントローラ
【図１】
2006065811.tif 000020
【図２】
2006065811.tif 000021
【図３】
2006065811.tif 000022
【図４】
2006065811.tif 000023
【図５】
2006065811.tif 000024
【図６】
2006065811.tif 000025
【図７】
2006065811.tif 000026
【図８】
2006065811.tif 000027
【図９】
2006065811.tif 000028