(57)【要約】【課題】ネットワークにより接続されたサーバ、ストレージ及びネットワーク装置から構成される自律制御システムで、制御要件（ポリシー）に応じて柔軟な自律制御を行うこと。【解決手段】ポリシーＤＢ１０２などに各種ポリシーを記憶し、システムを構成する各ノードが他のノードと連携するとともに、ポリシーに基づいて自律制御を行う。また、予備のリソースを共有プール、ベアメタルプール及びスタンバイプールを用いて管理し、障害時や性能劣化時にワークグループシステムリソースマネジャ１０５がスタンバイプール、ベアメタルプールの順に予備のリソースを選択する。【選択図】        図４
2005346204.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラムであって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出手順と、
前記ポリシー読出手順により読み出されたポリシーに基づいて自律制御を行う制御実行手順と、
をコンピュータに実行させることを特徴とする自律制御プログラム。
【請求項２】
前記ポリシーは、前記情報処理システム全体についてのポリシーと、各情報処理装置ごとのポリシーとから構成されることを特徴とする請求項１に記載の自律制御プログラム。
【請求項３】
前記ポリシーは、情報処理システムを運用してサービスを提供するセンターのポリシーと、情報処理システムを利用する顧客のポリシーと、情報処理システムの提供するサービスのポリシーとから構成されることを特徴とする請求項１に記載の自律制御プログラム。
【請求項４】
前記情報処理システムは、提供するサービスのサービスモデルを構成する複数のサービス階層の各階層にリソースである情報処理装置を割り当て、
利用されていない予備のリソースを集めて共有プールとして管理し、
共有プールの中のリソースのうち各サービス階層で利用可能であると判定されたリソースをサービス階層ごとに集めてベアメタルプールとして管理し、
ベアメタルプールの中から選択して各サービス階層での利用に必要な準備を完了したリソースをサービス階層ごとに集めてスタンバイプールとして管理し、
前記制御実行手順は、スタンバイプール、ベアメタルプール、共有プールの順に必要な予備のリソースを探して自律制御を行うことを特徴とする請求項１、２または３に記載の自律制御プログラム。
【請求項５】
前記サービスモデルは、インターネットとイントラネットとを接続するＦｒｏｎｔ層、ウェブサーバが配置されるＷｅｂ層、アプリケーションサーバが配置されるＡＰ層及びデータベースサーバが配置されるＤＢ層から構成されることを特徴とする請求項４に記載の自律制御プログラム。
【請求項６】
前記制御実行手順は、いずれかの情報処理装置に障害が発生した場合には、該障害が発生した情報処理装置の代替装置として動作する情報処理装置を予備のリソースから選択して障害を復旧し、前記情報処理システムに所定の大きさを超える負荷変動が発生した場合には、リソースの再配置を行うことによって自律制御を行うことを特徴とする請求項４に記載の自律制御プログラム。
【請求項７】
前記情報処理システムは、サーバ、ストレージおよびネットワーク装置を情報処理装置として構成されるシステムであることを特徴とする請求項１、２または３に記載の自律制御プログラム。
【請求項８】
ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出手順と、
前記ポリシー読出手順により読み出されたポリシーに基づいて自律制御を行う制御実行手順と、
をコンピュータに実行させる自律制御プログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項９】
ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御装置であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶したポリシー記憶手段と、
前記ポリシー記憶手段により記憶されたポリシーに基づいて自律制御を行う制御実行手段と、
を備えたことを特徴とする自律制御装置。
【請求項１０】
ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御方法であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出工程と、
前記ポリシー読出工程により読み出されたポリシーに基づいて自律制御を行う制御実行工程と、
を含んだことを特徴とする自律制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ネットワークにより接続され複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラム及びその記録媒体、自律制御装置並びに自律制御方法に関し、特に、情報処理システムの制御要件（ポリシー）にしたがって柔軟な自律制御を行うことができる自律制御プログラム及びその記録媒体、自律制御装置並びに自律制御方法に関するものである。
【背景技術】
【０００２】
従来、ＩＴインフラストラクチャ・システムにおいては、サーバ、ストレージ、ネットワークなどのリソースは別々に管理されており、障害や急激な負荷変動が検出された場合、サーバ、ストレージ、ネットワーク各装置からの障害情報、負荷情報を基に人手により障害個所の特定、ボトルネック分析、システム再設計・検証、対処が行われていた。
【０００３】
しかし、システムの大規模化やシステム構成の複雑化にともない、従来の人手による対応では、障害や急激な負荷変動が発生した際の対応に多くの時間と作業工数が必要となり、ひいてはオペミス等によるトラブルの発生等によるＴＣＯの増加を招いていた。
【０００４】
そこで、システムに障害が発生した際の復旧や急激な負荷変動が発生した際のシステムの再構成を自動的に行う自律制御システムが開発されている（例えば、特許文献１及び非特許文献１参照。）。
【０００５】
自律制御システムでは、サーバ、ストレージ、ネットワークなどのリソースの管理を一元化し、障害や急激な負荷変動の検出、分析、システム再設計、検証、対処を自動的に行うことによって、人手を介さずに２４時間３６５日とまる事の無いシステムの実現を目指している。
【０００６】
【特許文献１】特開２００１−２６５７２６号公報
【非特許文献１】「Server Technology」、［平成１６年４月１４日検索］、インターネット＜URL:http://www.ibm.com/ibm/licensing/patents/server.shtml＞
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来の自律制御システムでは、システムの復旧や再配置をシステムの制御要件（ポリシー）に基づいて柔軟に行うことができないという問題があった。例えば、障害からの回復や負荷変動への対応をできるだけ高速に行う場合と、リソースをできるだけ有効活用する場合とでは、システムの復旧や再配置の方式を変える必要があるが、従来の自律制御システムでは復旧や再配置の方式を変えることができないという問題があった。
【０００８】
この発明は、上述した従来技術による問題点を解消するためになされたものであり、情報処理システムの制御要件（ポリシー）にしたがって柔軟な自律制御を行うことができる自律制御プログラム及びその記録媒体、自律制御装置並びに自律制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するため、本発明は、ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラムであって、前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出手順と、前記ポリシー読出手順により読み出されたポリシーに基づいて自律制御を行う制御実行手順と、をコンピュータに実行させることを特徴とする。
【００１０】
また、本発明は、ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出手順と、前記ポリシー読出手順により読み出されたポリシーに基づいて自律制御を行う制御実行手順と、をコンピュータに実行させる自律制御プログラムを記録したことを特徴とする。
【００１１】
また、本発明は、ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御装置であって、前記情報処理システムを管理するにあたっての要件であるポリシーを記憶したポリシー記憶手段と、前記ポリシー記憶手段により記憶されたポリシーに基づいて自律制御を行う制御実行手段と、を備えたことを特徴とする。
【００１２】
また、本発明は、ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御方法であって、前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出工程と、前記ポリシー読出工程により読み出されたポリシーに基づいて自律制御を行う制御実行工程と、を含んだことを特徴とする。
【００１３】
かかる発明によれば、情報処理システムを管理するにあたっての要件であるポリシーを記憶し、記憶したポリシーに基づいて自律制御を行うよう構成したので、ポリシーを変更することによって異なる方式の自律制御を行うことができる。
【００１４】
また、本発明は、上記発明において、前記情報処理システムは、提供するサービスのサービスモデルを構成する複数のサービス階層の各階層にリソースである情報処理装置を割り当て、利用されていない予備のリソースを集めて共有プールとして管理し、共有プールの中のリソースのうち各サービス階層で利用可能であると判定されたリソースをサービス階層ごとに集めてベアメタルプールとして管理し、ベアメタルプールの中から選択して各サービス階層での利用に必要な準備を完了したリソースをサービス階層ごとに集めてスタンバイプールとして管理し、前記制御実行手順は、スタンバイプール、ベアメタルプール、共有プールの順に必要な予備のリソースを探して自律制御を行うことを特徴とする。
【００１５】
この発明によれば、提供するサービスのサービスモデルを構成する複数のサービス階層の各階層にリソースである情報処理装置を割り当て、利用されていない予備のリソースを集めて共有プールとして管理し、共有プールの中のリソースのうち各サービス階層で利用可能であると判定されたリソースをサービス階層ごとに集めてベアメタルプールとして管理し、ベアメタルプールの中から選択して各サービス階層での利用に必要な準備を完了したリソースをサービス階層ごとに集めてスタンバイプールとして管理し、スタンバイプール、ベアメタルプール、共有プールの順に必要な予備のリソースを探して自律制御を行うよう構成したので、スタンバイプールを用いて障害からの回復や負荷変動への対応を高速に行うことができる。
【発明の効果】
【００１６】
本発明によれば、ポリシーを変更することによって異なる方式の自律制御を行うので、ポリシーにしたがって柔軟な自律制御を行うことができるという効果を奏する。
【００１７】
また、本発明によれば、スタンバイプールを用いて障害からの回復や負荷変動への対応を高速に行うので、効率的な自律制御を実現することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１８】
以下に添付図面を参照して、この発明に係る自律制御プログラム及びその記録媒体、自律制御装置並びに自律制御方法の好適な実施例を詳細に説明する。
【実施例】
【００１９】
まず、本実施例に係る自律制御の概念について図１〜図３を用いて説明する。具体的には、本実施例に係る自律制御ループの概念及び本実施例に係る自律制御におけるリソースプールの概念について説明する。
【００２０】
図１は、本実施例に係る自律制御ループの概念を説明するための説明図である。同図に示すように、本実施例に係る自律制御は、「監視・計測」及び「操作」のループと「分析」及び「設計・検証」の２つのループで構成され、制御要件(ポリシー)と知識データベースを基にそれぞれのフェーズを実行する。
【００２１】
「監視・計測」フェーズでは、障害など稼働状況の監視や負荷状況の計測を行い、予め定義した手続きなどで即時対処可能な場合は「操作」フェーズに対処方法の指示、実行依頼を行う。一方、即時対処不可の場合は「分析」フェーズに障害情報・負荷情報を通知する。
【００２２】
「分析」フェーズでは、検出された障害箇所の特定分析・影響範囲の特定分析や、性能のボトルネック分析・他への影響分析を行い必要リソース量の算出を行う。
【００２３】
「設計・検証」フェ−ズでは、分析結果とポリシーをもとに、リソース配分調整を行う。例えば、システムで共有されるリソースプールから必要なリソースを取得したリソース再配分の改善提案の設計を行い、改善提案に従ったシステム構成を検証し、検証結果に問題が無ければ新規リソースを組み込み、且つ周辺リソースへの設定変更も含んだ設計を行う。
【００２４】
「操作」フェーズでは、予め定義した手続き又は、設計・検証結果をもとに、リソースの再構成を行う。
【００２５】
このように、本実施例に係る自律制御システムでは、制御要件（ポリシー）に基づいてリソースの配分調整を行うことによって、柔軟な自律制御システムを実現することができる。
【００２６】
図２は、本実施例に係る自律制御ループの相関図である。同図に示すように、本実施例に係る自律制御は、自律制御ループがサーバ、ストレージ、ネットワークの各ノードで機能し、かつ複数ノードにまたがった形でも機能する。すなわち、個々のノードにおいて、各ノードのリソースについての自律制御ループが機能しており、運用管理を含んだシステム全体でも複数ノードにまたがってリソースを自律制御するために、この自律制御ループは機能している。
【００２７】
図３は、本実施例に係る自律制御におけるリソースプールの概念を説明するための説明図である。同図に示すように、本実施例に係る自律制御では、リソースの配分を調整する手段として、サーバ／ストレージ／ネットワークそれぞれの予備装置または予備部品を、システムで共有されるリソースプールとして用意し、必要に応じてこのリソースプールからの割り当てや返却を行う事でリソース配分の調整を行う。
【００２８】
ここで、サーバプールの場合は、計算処理を行なうサーバ本体がプール対象となり、サーバ選択時には性能緒元が主な指標となる。ストレージプールの場合は、性能はもちろん、容量及び付随するリンクの確保がプールの重要な役割である。ネットワークプールでは、帯域幅・リンクを確保しなければならない。
【００２９】
いずれのプールであっても、リソースの有効活用、レスポンスの早さということを考慮すると、リソースの状態及び結線状況に応じて複数のプールを用意しなければ実運用に耐え得る配分調整機能は提供できない。そこで、本自律制御システムでは、「共有プール(Shared Pool)」「ベアメタルプール(Bare Metal Pool)」「スタンバイプール(Standby Pool)」の３段階のプールを基本構成として、配分調整機能を実現する。
【００３０】
「共有プール」とは、システム全体で共有されるプールであり、遊休状態にあるリソース全てを型番等により分類して保持する。新規導入されたリソースはまずこのプールに入れられる。なお、本プールでは、筺体単位で物理リソースを管理する（ブレードサーバの場合は各ＣＰＵブレードを１筺体として扱う）。
【００３１】
本プール内のリソースは、（使用条件を満たせば）どのサービスからも利用可能であるため、リソースの有効活用という面からは最適であるが、サービスに組み込んで使用するまでにデプロイ（必要なソフトウェアのインストールなどの準備）、各種設定を一から行う必要があるので、サービスを開始するまでに多大な時間を要する。
【００３２】
「ベアメタルプール」とは、各サービスレイヤ専用のプールであり、共有プールの中から当該サービスレイヤに適したリソースを選定して登録しておく。なお、本実施例に係るサービスモデルは、Ｆｒｏｎｔ層、Ｗｅｂ層、ＡＰ層及びＤＢ層の四つのサービスレイヤから構成されるが、サービスモデルの詳細については、後述する。
【００３３】
また、ベアメタルプールへの登録とは、共有プール内のリソースの当該サービスレイヤへの写像を登録することであり、リソースの実体は共有プールに登録されたままである。また、ここでいう“適した”リソースというのは、要求されたハードウェア基準を満たし、なおかつ適切な物理配線が張られているリソースのことを指す。
【００３４】
本段階では、同一リソースが複数のベアメタルプール、つまり複数のサービスレイヤに登録されていても良い（複数のサービスに跨って所属することを許す）。本プール内のリソースは当該サービスレイヤで利用可能であるという検証が既に済んでいるため、サービスを開始するまでの時間は共有プールからリソースを選択する場合よりも若干短い。
【００３５】
この検証時間は、用意されているリソース規模に比例して増大するので、システム規模が大きくなるほどベアメタルプールを用意したほうが効率的である。また、リソース共有に関しては、前述の通り、本プールは共有プールの単なる写像に過ぎないので、共有プールと同程度の自由度がある。
【００３６】
「スタンバイプール」とは、各サービスレイヤ専用のプールであり、当該サービスレイヤのベアメタルプールに登録されたリソースの中からデプロイを済ませて速やかに利用可能な状態にしたリソースを保持する。スタンバイプールに属するリソースは、必ずどれか１つのサービスレイヤにのみ含まれる。
【００３７】
本プール内のリソースは、必要最小限の設定だけでサービスを開始することができるので、要求されてからのレスポンスは３つの中で最も早い。ただし、これらのリソースは当該サービスレイヤ用に専用化されているので、あまり多くのリソースをスタンバイプールに保持しておくのは非効率的である。
【００３８】
このように、本実施例に係る自律制御システムでは、サービスに対する準備状況の異なる三つのリソースプールを用意することによって、柔軟な配分調整機能を提供することができる。
【００３９】
次に、本実施例に係る自律制御システムのシステム構成について説明する。図４は、本実施例に係る自律制御システムのシステム構成を示す機能ブロック図である。同図に示すように、この自律制御システムは、管理ノード１００、サーバノード２１０及び２４０、ストレージノード２２０及び２５０、並びにネットワークノード２３０及び２６０から構成され、これらのノードはネットワークにより接続される。
【００４０】
なお、ここでは、説明の便宜上、２台のサーバノード、ストレージノード及びネットワークノードを示したが、この自律制御システムは、任意の台数のサーバノード、ストレージノード及びネットワークノードから構成される。
【００４１】
管理ノード１００は、サーバノード２１０及び２４０、ストレージノード２２０及び２５０並びにネットワークノード２３０及び２６０を束ねたシステム全体を管理・制御する事を目的としたソフトウェアを搭載したハードウェアである。
【００４２】
サーバノード２１０は、１台のサーバ装置(ＯＳインスタンス単位)内のサーバリソースを管理・制御する事を目的としたソフトウェアを搭載したハードウェアである。ここで、サーバリソースは、ノード内のＣＰＵ、メモリ、ディスク、ＨＢＡ(Host Bus Adapter)、ＮＩＣ(Network Interface Card)等の物理リソース、及び、サーバ装置上で動作するソフトウェア(ノードサーバリソースマネジャ２１４が管理)である。
【００４３】
ストレージノード２２０は、１台のストレージ装置内のストレージリソースを管理・制御する事を目的としたソフトウェアを搭載したハードウェアである。ここで、ストレージリソースは、サーバノード２１０内のＤＢテーブル情報の管理等ストレージに関する論理リソース(ノードストレージリソースマネジャ２１５が管理)及びＳＡＮ、ＮＡＳ等のストレージ装置(ストレージノードリソースマネジャ２２１が管理)である。
【００４４】
ネットワークノード２３０は、１台のネットワーク装置内のネットワークリソースを管理・制御する事を目的としたソフトウェアを搭載したハードウェアである。ここで、ネットワークリソースは、サーバノード２１０内のネットワークに関する論理リソース(ノードネットワークリソースマネジャ２１６が管理)及びルータ、スイッチ、ファイアウォール、ロードバランサ等のネットワーク装置(ネットワークノードリソースマネジャ２３１が管理)である。
【００４５】
サーバノード２４０は、サーバノード２１０と同様、１台のサーバ装置内のサーバリソースを管理・制御する事を目的としたソフトウェアを搭載したハードウェアであるが、サーバノード２１０とはベンダーが異なる。
【００４６】
ストレージノード２５０は、ストレージノード２２０と同様、１台のストレージ装置内のストレージリソースを管理・制御する事を目的としたソフトウェアを搭載したハードウェアであるが、ストレージノード２２０とはベンダーが異なる。
【００４７】
ネットワークノード２６０は、ネットワークノード２３０と同様、１台のネットワーク装置内のネットワークリソースを管理・制御する事を目的としたソフトウェアを搭載したハードウェアであるが、ネットワークノード２３０とはベンダーが異なる。
【００４８】
次に、各ノードが搭載するソフトウェアの機能構成について説明する。管理ノード１００が搭載するソフトウェアには、ポリシーマネジャ(Policy Manager)１０１と、ポリシーＤＢ(Policy DB)１０２と、ワークグループサービスマネジャ(Workgroup Service Manager)１０３と、ワークグループサービスＤＢ(Workgroup Service DB)１０４と、ワークグループシステムリソースマネジャ(Workgroup System Resource Manager)１０５と、ワークグループシステムＤＢ(Workgroup System DB)１０６と、ワークグループリソースコーディネータ(Workgroup Resource Coordinator)１０７と、ワークグループサーバリソースマネジャ(Workgroup Server resource Manager)１０８と、ワークグループサーバＤＢ(Workgroup Server DB)１０９と、ワークグループストレージリソースマネジャ(Workgroup Storage Resource Manager)１１０と、ワークグループストレージＤＢ(Workgroup Storage DB)１１１と、ワークグループネットワークリソースマネジャ(Workgroup Network Resource Manager)１１２と、ワークグループネットワークＤＢ(Workgroup Network DB)１１３と、オープンＩ／Ｆ(Open I/F)１１４とが含まれる。
【００４９】
ポリシーマネジャ１０１は、自律制御システムが扱う全体的なポリシーを管理する処理部である。また、このポリシーマネジャ１０１は、各ブロック（マネジャ）のポリシー管理機能と連携し、ポリシー設定ビューの統合と各ブロックの扱うポリシーへのブレイクダウンを行う。
【００５０】
ポリシーＤＢ１０２は、ポリシーマネジャ１０１が管理するポリシーを記憶するデータベースである。なお、各ブロックのポリシーは、各ブロックが管理するデータベースに記憶される。
【００５１】
ワークグループサービスマネジャ１０３は、システム全体に跨った、サービスの構成管理、性能の計測、分析(予兆分析を含む)を行う処理部である。ワークグループサービスＤＢ１０４は、ワークグループサービスマネジャ１０３が使用するポリシーなどのデータを記憶したデータベースである。
【００５２】
ワークグループシステムリソースマネジャ１０５は、システム全体に跨った、リソースの構成管理と障害の監視・分析及び設計・検証・操作を行う処理部であり、システムとして対処出来ない場合はオペレータに通知する。
【００５３】
ワークグループシステムＤＢ１０６は、ワークグループシステムリソースマネジャ１０５が使用するデータを記憶したデータベースであり、このデータベースの詳細については後述する。
【００５４】
ワークグループリソースコーディネータ１０７は、システム／サーバ／ストレージ／ネットワークの各ノードリソースマネジャとシステム／サーバ／ストレージ／ネットワークの各ワークグループリソースマネジャとの繋ぎ<パイプ>役として動作する処理部である。すなわち、このワークグループリソースコーディネータ１０７は、両者間のデータ通信インフラとして、リソースコーディネータのデータ入出力間での整合性を保証するものである。
【００５５】
ワークグループサーバリソースマネジャ１０８は、管理ノード１００の配下にある全サーバノードに跨った、サーバリソースの構成管理と障害の監視・分析及び検証・操作を行う処理部である。ワークグループサーバＤＢ１０９は、ワークグループサーバリソースマネジャ１０８が使用するポリシーなどのデータを記憶したデータベースである。
【００５６】
ワークグループストレージリソースマネジャ１１０は、管理ノード１００の配下にある全ストレージノード及びサーバノード内ストレージリソースにおける、ストレージリソースの構成管理と障害・性能の監視・計測、分析及び検証、操作を行う処理部である。ワークグループストレージＤＢ１１１は、ワークグループストレージリソースマネジャ１１０が使用するポリシーなどのデータを記憶したデータベースである。
【００５７】
ワークグループネットワークリソースマネジャ１１２は、管理ノード１００の配下にある全ネットワークノード及びサーバノード内ネットワークリソースにおける、ネットワークリソースの構成管理と障害・性能の監視・計測・分析及び検証・操作を行う処理部である。ワークグループネットワークＤＢ１１３は、ワークグループネットワークリソースマネジャ１１２が使用するポリシーなどのデータを記憶したデータベースである。
【００５８】
オープンＩ／Ｆ１１４は、オープンインタフェースを備えた機器（ベンダーが異なる装置）に対するゲートウェイとして動作する処理部であり、管理ノード１００は、このオープンＩ／Ｆ１１４を介してベンダーが異なるサーバノード２４０、ストレージノード２５０及びネットワークノード２６０と通信する。
【００５９】
サーバノード２１０が搭載するソフトウェアには、ノードシステムリソースマネジャ(Node System Resource Manager)２１１と、ノードサービスマネジャ(Node Service Manager)２１２と、ノードリソースコーディネータ(Node Resource Coordinator)２１３と、ノードサーバリソースマネジャ(Node Server Resource Manager)２１４と、ノードストレージリソースマネジャ(Node Storage Resource Manager)２１５と、ノードネットワークリソースマネジャ(Node Network Resource Manager)２１６とが含まれる。
【００６０】
ノードシステムリソースマネジャ２１１は、サーバノード２１０内における、リソースの構成管理と障害の監視・分析及び設計・検証・操作を行う処理部である。また、このノードシステムリソースマネジャ２１１は、障害の分析において、サーバノード２１０内で解決出来ない場合は、ワークグループシステムリソースマネジャ１０５に依頼を行う。
【００６１】
ノードサービスマネジャ２１２は、サーバノード２１０内における、業務の構成管理と性能の計測・分析を行う処理部である。また、このノードサービスマネジャ２１２は、サーバノード２１０内で解決出来ない場合は、ワークグループサービスマネジャ１０３へ依頼を行う。
【００６２】
ノードリソースコーディネータ２１３は、システム／サーバ／ストレージ／ネットワークの各ノードリソースマネジャとシステム／サーバ／ストレージ／ネットワークの各ワークグループリソースマネジャとの繋ぎ<パイプ>役として動作する処理部である。すなわち、両者間のデータ通信インフラとして、リソースコーディネータのデータ入出力間での整合性を保証するものである。
【００６３】
ノードサーバリソースマネジャ２１４は、サーバノード２１０内における、サーバリソースの構成管理と障害・性能での監視・計測及び操作を行う処理部である。
【００６４】
ノードストレージリソースマネジャ２１５は、サーバノード２１０内における、ストレージリソースの構成管理と障害・性能での監視・計測及び操作を行う処理部である。
【００６５】
ノードネットワークリソースマネジャ２１６は、サーバノード２１０内における、ネットワークリソースの構成管理と障害・性能での監視・計測及び操作を行う処理部である。
【００６６】
ストレージノード２２０が搭載するソフトウェアには、ストレージノードリソースマネジャ(Storage Node Resource Manager)２２１が含まれる。ストレージノードリソースマネジャ２２１は、ストレージノード２２０における、ストレージリソースの構成管理と障害での監視・分析・設計・検証、性能での計測及び操作を行う処理部である。また、このストレージノードリソースマネジャ２２１は、障害の分析において、ストレージノード２２０内で解決出来ない場合は、ワークグループストレージリソースマネジャ１１０へ依頼を行う。
【００６７】
ネットワークノード２３０が搭載するソフトウェアには、ネットワークノードリソースマネジャ(Network Node Resource Manager)２３１が含まれる。ネットワークノードリソースマネジャ２３１は、ネットワークノード２３０における、ネットワークリソースの構成管理と障害での監視・分析・設計・検証、性能での計測及び操作を行う処理部である。また、このネットワークノードリソースマネジャ２３１は、障害の分析において、ネットワークノード２３０内で解決出来ない場合は、ワークグループネットワークリソースマネジャ１１２へ依頼を行う。
【００６８】
サーバノード２４０が搭載するソフトウェアには、マルチベンダサーバ／ストレージ／ネットワークリソースマネジャ(Multi-vendor Server/Storage/Network Resource Manager)２４１〜２４３が含まれる。マルチベンダサーバ／ストレージ／ネットワークリソースマネジャ２４１〜２４３は、サーバノード２４０内における、サーバリソース／ストレージリソース／ネットワークリソースそれぞれの構成管理と障害・性能での監視・計測及び操作を行う処理部である。
【００６９】
ストレージノード２５０が搭載するソフトウェアには、ストレージマルチベンダリソースマネジャ(Storage Multi-vendor Resource Manager)２５１が含まれる。ストレージマルチベンダリソースマネジャ２５１は、ストレージノード２５０における、ストレージリソースの構成管理と障害での監視・分析・設計・検証、性能での計測及び操作を行う処理部である。また、このストレージマルチベンダリソースマネジャ２５１は、障害の分析において、ストレージノード２５０内で解決出来ない場合は、ワークグループストレージリソースマネジャ１１０へ依頼を行う。
【００７０】
ネットワークノード２６０が搭載するソフトウェアには、ネットワークマルチベンダリソースマネジャ(Network Multi-vendor Resource Manager)２６１が含まれる。ネットワークマルチベンダリソースマネジャ２６１は、ネットワークノード２６０における、ネットワークリソースの構成管理と障害での監視・分析・設計・検証、性能での計測及び操作を行う処理部である。また、このネットワークマルチベンダリソースマネジャ２６１は、障害の分析において、ネットワークノード２６０内で解決出来ない場合は、ワークグループネットワークリソースマネジャ１１２へ依頼を行う。
【００７１】
なお、図４では、管理ノード１００、サーバノード２１０、ストレージノード２２０、ネットワークノード２３０などがネットワークを介して接続される場合を示したが、管理ノード１００とサーバノード２１０に搭載されるソフトウェアを同一のコンピュータシステムに搭載したり、あるいは、管理ノード１００に搭載されるソフトウェアを複数のコンピュータシステムに分散することもできる。
【００７２】
次に、本実施例に係る自律制御システムのサービスモデル、論理構成及び物理構成について図５〜７を用いて説明する。図５は、本実施例に係る自律制御システムのサービスモデルの構成を示す図である。ここで、サービスとは、エンドユーザに提供する一連の業務のことである。
【００７３】
図５に示すように、本実施例に係る自律制御システムでは、Ｆｒｏｎｔ層、Ｗｅｂ層、ＡＰ層、ＤＢ層の４階層のサービスモデルを基準とする。Ｆｒｏｎｔ層は、インターネットとイントラネットを接続する層であり、このＦｒｏｎｔ層には、ルータ３０１やセンター全体のファイアウォールなどが置かれる。
【００７４】
Ｗｅｂ層は、Ｗｅｂサーバ３０２やディレクトリサーバが置かれる層であり、Ｆｒｏｎｔ層がセンターの出入口であるのに対して、Ｗｅｂ層は当該サービスの出入口に相当する。ＡＰ層は、当該サービスのビジネスロジック部分を処理するＡＰサーバ３０３が置かれる層であり、ＤＢ層は、データベース処理を担当するＤＢサーバ３０４やストレージ３０５が置かれる層である。
【００７５】
このように、サービスを機能別に４階層に分割し、各階層に対して処理内容に適した物理リソースを適切な量だけ割り付けることで当該サービスを効率良く実行でき、なおかつセンター全体としても最適なリソース運用が可能となる。
【００７６】
なお、ルータ３０１は、図４に示したネットワークノード２３０に対応し、Ｗｅｂサーバ３０２、ＡＰサーバ３０３及びＤＢサーバ３０４は、図４に示したサーバノード２１０に対応し、ストレージ３０５は、図４に示したストレージノード２２０に対応する。
【００７７】
図６は、本実施例に係る自律制御システムの論理構成を示す図である。同図に示すように、本実施例に係る自律制御システムでは、Ｆｒｏｎｔ層には論理ネットワーク（ルータ）「ＬＲＴ１」が置かれ、Ｗｅｂ層には論理サーバ「ＬＳｖｒ１」及び「ＬＳｖｒ２」が置かれ、ＡＰ層には論理サーバ「ＬＳｖｒ３」が置かれ、ＤＢ層には論理サーバ「ＬＳｖｒ４」及び論理ストレージ（データベース）「ＬＤＢ１」が置かれる。
【００７８】
そして、「サービス１」は、論理ネットワーク「ＬＲＴ１」、論理サーバ「ＬＳｖｒ１」、論理サーバ「ＬＳｖｒ３」、論理サーバ「ＬＳｖｒ４」及び論理ストレージ「ＬＤＢ１」により提供され、「サービス２」は、論理ネットワーク「ＬＲＴ１」、論理サーバ「ＬＳｖｒ２」、論理サーバ「ＬＳｖｒ３」、論理サーバ「ＬＳｖｒ４」及び論理ストレージ「ＬＤＢ１」により提供される。また、「サービス２」に対するＷｅｂ層のスタンバイプールには、論理サーバ「ＬＳｖｒ５」が登録されている。
【００７９】
この論理システムは、サービスと物理システムの間に設けられる仮想化レイヤであり、物理的なリソースの構成変更が直接サービスに影響を与えることなく、柔軟なリソース運用を可能にするために設けられている。なお、論理サーバ、論理ストレージ、論理ネットワークは、論理リソースと総称される。
【００８０】
図７は、本実施例に係る自律制御システムの物理構成を示す図である。同図に示すように、本実施例に係る自律制御システムでは、Ｆｒｏｎｔ層には物理ネットワーク（ルータ）「ＰＲＴ１」が置かれ、Ｗｅｂ層には物理ネットワーク（スイッチ）「ＰＳＷ１」並びに物理サーバ「ＰＳｖｒ１」、「ＰＳｖｒ２」及び「ＰＳｖｒ７」が置かれ、ＡＰ層には物理ネットワーク「ＰＳＷ２」及び物理サーバ「ＰＳｖｒ４」が置かれ、ＤＢ層には物理ネットワーク「ＰＳＷ３」、物理サーバ「ＰＳｖｒ５」及び物理ストレージ（データベース）「ＰＤＢ１」が置かれる。また、物理ネットワーク「ＰＳＷ１」、「ＰＳＷ２」及び「ＰＳＷ３」は、物理ネットワーク「ＰＲＴ２」を介して管理ノード１００に接続される。
【００８１】
また、「サービス１」に対するＡＰ層のベアメタルプールには、物理サーバ「ＰＳｖｒ６」が登録され、「サービス２」に対するＡＰ層のスタンバイプールには、物理サーバ「ＰＳｖｒ３」が登録され、「サービス２」に対するベアメタルプールには、物理サーバ「ＰＳｖｒ６」が登録されている。なお、物理サーバ「ＰＳｖｒ６」は、共有プールにも登録されている。また、物理サーバ、物理ストレージ、物理ネットワークは、物理リソースと総称される。
【００８２】
次に、図４に示したポリシーＤＢ１０２及び各ブロックが記憶するポリシーについて説明する。図８は、ポリシーの全体イメージを示す図であり、図９は、ポリシーの全体構成を示す図である。図８及び図９に示すように、ポリシーには、センターポリシーと、カスタマポリシーと、サービスポリシーとがある。
【００８３】
センターポリシーはセンター全体のポリシーであり、カスタマポリシーは各顧客のポリシーであり、サービスポリシーは各顧客の各サービスのポリシーである。なお、センターポリシーが最も優先度が高く、サービスポリシーの優先度が最も低い。
【００８４】
また、センターポリシー、カスタマポリシー及びサービスポリシーには、それぞれ管理ポリシーと、設計ポリシーと、運用ポリシーと、障害復旧ポリシーと、保守ポリシーとが含まれる。
【００８５】
図１０は、ポリシーの詳細を示す図である。同図に示すように、管理ポリシーには、認証ポリシー、課金ポリシー、レポーティングポリシーなどがあり、運用ポリシーには、監視ポリシー、分析ポリシー、プロビジョニングポリシーなどがある。
【００８６】
次に、ワークグループシステムＤＢ１０６が記憶する情報について図１１〜図３０を用いて説明する。ワークグループシステムＤＢ１０６が記憶する情報には、ポリシー以外に、自律制御システムの物理リソース及び接続関係、論理リソース及び接続関係、物理リソースと論理リソースとの対応関係、サービスレイヤとリソースとの対応関係、サービスとリソースとの対応関係などの情報が含まれる。
【００８７】
図１１は、物理サーバと型番の対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各物理サーバに対して型番を対応させた情報を記憶する。
【００８８】
図１２は、物理サーバの型番詳細情報の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各物理サーバの型番に対して仕様及び性能値を対応させた情報を記憶する。
【００８９】
図１３は、物理ネットワークと型番の対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各物理ネットワークに対して型番を対応させた情報を記憶する。
【００９０】
図１４は、物理ネットワークの型番詳細情報の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各物理ネットワークの型番に対して仕様及び性能値を対応させた情報を記憶する。
【００９１】
図１５は、物理ストレージと型番の対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各物理ストレージに対して型番を対応させた情報を記憶する。
【００９２】
図１６は、物理ストレージの型番詳細情報の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各物理ストレージの型番に対して仕様及び性能値を対応させた情報を記憶する。
【００９３】
このように、ワークグループサーバ／ストレージ／ネットワークＤＢが各物理サーバ／物理ストレージ／物理ネットワークの仕様及び性能を記憶することによって、ワークグループシステムリソースマネジャ１０５は、各サービスレイヤで必要とされる物理サーバ／物理ストレージ／物理ネットワークを共有プールから選択することができる。
【００９４】
図１７は、物理リソース接続関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、物理リソース間を接続する各リンクに対してリンク番号、接続元及び接続先を対応させた情報を記憶する。
【００９５】
図１８は、物理―論理マッピングの一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、物理リソースと論理リソースの対応関係を記憶する。
【００９６】
図１９は、論理サーバとタイプの対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理サーバに対してサーバのタイプを対応させた情報を記憶する。
【００９７】
図２０は、論理サーバのタイプ詳細情報の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理サーバのタイプに対して搭載するソフトウェア及び必須条件を対応させた情報を記憶する。このように、ワークグループシステムＤＢ１０６が各論理サーバが搭載するソフトウェア及び必須条件を記憶することによって、ワークグループシステムリソースマネジャ１０５は、各サービスレイヤで必要とされる論理サーバをスタンバイプールに準備することができる。
【００９８】
図２１は、論理ネットワークとタイプの対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理ネットワークに対して装置のタイプを対応させた情報を記憶する。
【００９９】
図２２は、論理ネットワークのタイプ詳細情報の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理ネットワークのタイプに対して必須条件を対応させた情報を記憶する。
【０１００】
図２３は、論理ストレージとタイプの対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理ストレージに対して装置のタイプを対応させた情報を記憶する。
【０１０１】
図２４は、論理ストレージのタイプ詳細情報の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理ストレージのタイプに対して必須条件を対応させた情報を記憶する。
【０１０２】
図２５は、論理リソース接続関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、論理リソース間を接続する各リンクに対してリンク番号、接続元及び接続先を対応させた情報を記憶する。
【０１０３】
図２６は、論理サーバとサービスレイヤの対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理サーバが動作するサービスレイヤについての情報を記憶する。
【０１０４】
図２７は、論理ストレージとサービスレイヤの対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理ストレージが動作するサービスレイヤについての情報を記憶する。
【０１０５】
図２８は、論理ネットワークとサービスレイヤの対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各論理ネットワークが動作するサービスレイヤについての情報を記憶する。
【０１０６】
図２９は、サービスとリソースの対応関係の一例を示す図である。同図に示すように、ワークグループシステムＤＢ１０６は、各サービスに対して、サービスレイヤごとに運用中の論理リソース、スタンバイプールに登録されている論理リソース及びベアメタルプールに登録されている物理リソースの情報を記憶する。
【０１０７】
図３０は、共有プールに登録される物理サーバの一例を示す図である。同図に示すように、共有プールには、型番ごとに物理サーバが登録される。なお、物理ネットワーク及び物理ストレージについても同様に型番ごとに共有プールに登録される。
【０１０８】
次に、本実施例に係る自律制御システムの復旧処理についてサーバ故障を例として説明する。図３１−１〜３１−４は、サーバ故障からの復旧処理の処理手順を示すシーケンス図（１）〜（４）である。なお、ここでは、図７に示した物理サーバ「ＰＳｖｒ２」が故障した場合について説明する。
【０１０９】
また、図３１−１〜３１−４において、枠の左上の「alt」は、その枠を２分割する点線の前後での選択処理を示し、「opt」は、指定された条件が満たされた場合の処理を示し、「par」は点線で分割された部分の処理が並列に行われることを示し、「ref」は他のシーケンス図の参照を示す。
【０１１０】
図３１−１〜３１−４に示すように、本実施例に係る自律制御システムでは、「ＰＳｖｒ２」のノードサーバリソースマネジャ２１４がサーバ内部品の故障を検出し、それをノードシステムリソースマネジャ２１１に通知する。すると、ノードシステムリソースマネジャ２１１は、ノード内では処理しきれないと判断し、管理ノード１００のワークグループシステムリソースマネジャ１０５に故障通知をあげる（ステップＳ１０１）。
【０１１１】
すると、ワークグループシステムリソースマネジャ１０５は、図１７に示した物理リソース接続関係を用いて関連する物理リソースの検索を行い（ステップＳ１０２）、図１８に示した物理リソースと論理リソースの対応関係及び図２５に示した論理リソース接続関係を用いて関連する論理リソースの検索を行う（ステップＳ１０３）。
【０１１２】
そして、図２６〜２８に示した論理サーバ／論理ストレージ／論理ネットワークとサービスレイヤの対応関係を用いて関連するサービスの検索を行い（ステップＳ１０４）、故障箇所及び影響を受けるサービスについて管理者に通知する（ステップＳ１０５）。
【０１１３】
そして、図２９に示したサービスとリソースの対応関係を用いてスタンバイプールに代替候補があるか否かを判定し、代替候補がある場合には、スタンバイプールから代替候補を選択する（ステップＳ１０６）。この例では、スタンバイプールの「ＬＳｖｒ５」を選択する。
【０１１４】
一方、スタンバイプールに代替候補がない場合には、ベアメタルプールに代替サーバがあるか否かを判定し、代替サーバがある場合には、ベアメタルプールから代替候補を選択し（ステップＳ１０７）、代替リソースを用いてシステムレイアウトを生成し（ステップＳ１０８）、生成したシステムの検証を行う（ステップＳ１０９）。
【０１１５】
一方、ベアメタルプールに代替サーバがない場合には、縮退運転が可能であるか否かを調べ、縮退運転が可能である場合には、ワークグループサービスマネジャ１０３に縮退運転を依頼する（ステップＳ１１０）。
【０１１６】
そして、関連するノードに縮退運転を指示する。すなわち、関連するサーバノードに対しては、ワークグループサーバリソースマネジャ１０８を介して縮退運転を指示し（ステップＳ１１１〜ステップＳ１１２）、関連するストレージノードに対しては、ワークグループストレージリソースマネジャ１１０を介して縮退運転を指示し（ステップＳ１１３〜ステップＳ１１４）、関連するネットワークノードに対しては、ワークグループネットワークリソースマネジャ１１２を介して縮退運転を指示する（ステップＳ１１５〜ステップＳ１１６）。
【０１１７】
ここで、関連するノードとしては、主に故障したノードが動作するサービスレイヤに属するノード群が対象となるが、場合によっては、同一サービスの他レイヤのノード群にも影響する。
【０１１８】
そして、流量制御が可能でかつ必要であるか否かを調べ、流量制御が可能でかつ必要である場合には、ワークグループサービスマネジャ１０３に流量調整を依頼する（ステップＳ１１７）。なお、流量制御とは、例えば、クライアントからサーバへのリクエスト数を制御することである。
【０１１９】
そして、関連するノードに流量制御を指示する。すなわち、関連するサーバノードに対しては、ワークグループサーバリソースマネジャ１０８を介して流量制御を指示し（ステップＳ１１８〜ステップＳ１１９）、関連するストレージノードに対しては、ワークグループストレージリソースマネジャ１１０を介して流量制御を指示し（ステップＳ１２０〜ステップＳ１２１）、関連するネットワークノードに対しては、ワークグループネットワークリソースマネジャ１１２を介して流量制御を指示する（ステップＳ１２２〜ステップＳ１２３）。また、管理者に縮退運転を通知する（ステップＳ１２４）。
【０１２０】
一方、縮退運転が可能でない場合には、ワークグループサービスマネジャ１０３にサービス停止を依頼する（ステップＳ１２５）。そして、関連するノードにサービス停止を指示する。すなわち、関連するサーバノードに対しては、ワークグループサーバリソースマネジャ１０８を介してサービス停止を指示し（ステップＳ１２６〜ステップＳ１２７）、関連するストレージノードに対しては、ワークグループストレージリソースマネジャ１１０を介してサービス停止を指示し（ステップＳ１２８〜ステップＳ１２９）、関連するネットワークノードに対しては、ワークグループネットワークリソースマネジャ１１２を介してサービス停止を指示する（ステップＳ１３０〜ステップＳ１３１）。また、管理者にサービス停止を通知する（ステップＳ１３２）。
【０１２１】
そして、代替リソースが確保できた場合には、関連するノードに構成検証を指示する。すなわち、関連するサーバノードに対しては、ワークグループサーバリソースマネジャ１０８を介してサーバ状態を確認し（ステップＳ１３３〜ステップＳ１３４）、関連するストレージノードに対しては、ワークグループストレージリソースマネジャ１１０を介してストレージ状態を確認し（ステップＳ１３５〜ステップＳ１３６）、関連するネットワークノードに対しては、ワークグループネットワークリソースマネジャ１１２を介してネットワーク状態を確認する（ステップＳ１３７〜ステップＳ１３８）。
【０１２２】
そして、物理リンクの検証を行い（ステップＳ１３９）、管理者に代替候補を表示する（ステップＳ１４０）。なお、検証結果がＮＧとなった場合には、代替候補の取得から再実行する。
【０１２３】
そして、関連するノードに設定の変更を指示する。すなわち、関連するサーバノードに対しては、ワークグループサーバリソースマネジャ１０８を介してサーバの設定変更を指示し（ステップＳ１４１〜ステップＳ１４２）、関連するストレージノードに対しては、ワークグループストレージリソースマネジャ１１０を介してストレージの設定変更を指示し（ステップＳ１４３〜ステップＳ１４４）、関連するネットワークノードに対しては、ワークグループネットワークリソースマネジャ１１２を介してネットワークの設定変更を指示する（ステップＳ１４５〜ステップＳ１４６）。
【０１２４】
そして、ワークグループサービスマネジャ１０３にリソース構成変更を通知し（ステップＳ１４７）、サーバノード及び代替ノードにアプリケーションの起動を指示する（ステップＳ１４８〜ステップＳ１４９）。また、関連するノードの設定変更と並行して、リソースプールへのリソース補充を行う（ステップＳ１５０）。
【０１２５】
そして、ワークグループサービスマネジャ１０３に構成変更を通知し（ステップＳ１５１）、リソース情報の更新、具体的には図１８に示した論理リソースと物理リソースの対応関係の更新を行い（ステップＳ１５２）、管理者に障害復旧を通知する（ステップＳ１５３）。
【０１２６】
このように、システム内のリソースに障害が発生した場合に、ワークグループシステムリソースマネジャ１０５がスタンバイプールから代替リソースを選択し、システム構成の検証、設定変更を行うことによって、迅速な障害復旧を行うことができる。
【０１２７】
次に、本実施例に係る自律制御システムの性能劣化からの回復処理について説明する。図３２−１〜３２−４は、性能劣化からの回復処理の処理手順を示すシーケンス図（１）〜（４）である。
【０１２８】
図３２−１〜３２−４に示すように、本実施例に係る自律制御システムでは、ワークグループサービスマネジャ１０３が性能劣化を検出すると（ステップＳ２０１）、図２９に示したサービスとリソースの対応関係を用いて対応するサービスの検索を行い（ステップＳ２０２）、ボトルネックの特定を行う（ステップＳ２０３）。そして、ワークグループシステムリソースマネジャ１０５に性能劣化を通知する（ステップＳ２０４）。
【０１２９】
すると、ワークグループシステムリソースマネジャ１０５は、図２５に示した論理リソース接続関係を用いて関連する論理リソースの検索を行い（ステップＳ２０５）、図１７に示した物理リソース接続関係及び図１８に示した物理リソースと論理リソースの対応関係を用いて関連する物理リソースの検索を行う（ステップＳ２０６）。
【０１３０】
そして、各リソースの性能情報を収集する。すなわち、ワークグループサーバリソースマネジャ１０８からサーバの性能情報を収集し（ステップＳ２０７）、ワークグループストレージリソースマネジャ１１０からストレージの性能情報を収集し（ステップＳ２０８）、ワークグループネットワークリソースマネジャ１１２からネットワークの性能情報を収集する（ステップＳ２０９）。そして、性能劣化箇所及びその原因を特定し、管理者に通知する（ステップＳ２１０）。
【０１３１】
そして、図２９に示したサービスとリソースの対応関係を用いてスタンバイプールに追加候補があるか否かを判定し、追加候補がある場合には、スタンバイプールから追加候補を選択する（ステップＳ２１１）。
【０１３２】
一方、スタンバイプールに追加候補がない場合には、ベアメタルプールに追加サーバがあるか否かを判定し、追加サーバがある場合には、ベアメタルプールから追加候補を選択し（ステップＳ２１２）、追加リソースを用いてシステムレイアウトを生成し（ステップＳ２１３）、生成したシステムの検証を行う（ステップＳ２１４）。
【０１３３】
一方、ベアメタルプールに追加サーバがない場合には、流量制御によるアクセス制御が可能であるか否かを調べ、流量制御によるアクセス制御が可能である場合には、ワークグループサービスマネジャ１０３に流量調整を依頼する（ステップＳ２１５）。
【０１３４】
そして、関連するノードに流量制御を指示する。すなわち、関連するサーバノードに対しては、ワークグループサーバリソースマネジャ１０８を介して流量制御を指示し（ステップＳ２１６〜ステップＳ２１７）、関連するストレージノードに対しては、ワークグループストレージリソースマネジャ１１０を介して流量制御を指示し（ステップＳ２１８〜ステップＳ２１９）、関連するネットワークノードに対しては、ワークグループネットワークリソースマネジャ１１２を介して流量制御を指示する（ステップＳ２２０〜ステップＳ２２１）。
【０１３５】
そして、追加リソースが確保できた場合には、論理リソースの構成を更新し（ステップＳ２２２）、関連するノードに構成検証を指示する。すなわち、関連するサーバノードに対しては、ワークグループサーバリソースマネジャ１０８を介してサーバ状態を確認し（ステップＳ２２３〜ステップＳ２２４）、関連するストレージノードに対しては、ワークグループストレージリソースマネジャ１１０を介してストレージ状態を確認し（ステップＳ２２５〜ステップＳ２２６）、関連するネットワークノードに対しては、ワークグループネットワークリソースマネジャ１１２を介してネットワーク状態を確認する（ステップＳ２２７〜ステップＳ２２８）。
【０１３６】
そして、物理リンクの検証を行い（ステップＳ２２９）、管理者に対処策を通知する（ステップＳ２３０）。なお、検証結果がＮＧとなった場合には、追加候補の取得から再実行する。
【０１３７】
そして、関連するノードに設定の変更を指示する。すなわち、関連するサーバノードに対しては、ワークグループサーバリソースマネジャ１０８を介してサーバの設定変更を指示し（ステップＳ２３１〜ステップＳ２３２）、関連するストレージノードに対しては、ワークグループストレージリソースマネジャ１１０を介してストレージの設定変更を指示し（ステップＳ２３３〜ステップＳ２３４）、関連するネットワークノードに対しては、ワークグループネットワークリソースマネジャ１１２を介してネットワークの設定変更を指示する（ステップＳ２３５〜ステップＳ２３６）。
【０１３８】
そして、ワークグループサービスマネジャ１０３にリソース構成変更を通知し（ステップＳ２３７）、サーバノード及び追加ノードにアプリケーションの起動を指示する（ステップＳ２３８〜ステップＳ２３９）。また、関連するノードの設定変更と並行して、リソースプールへのリソース補充を行う（ステップＳ２４０）。
【０１３９】
そして、ワークグループサービスマネジャ１０３に構成変更を通知し（ステップＳ２４１）、リソース情報の更新、具体的には図１８に示した論理リソースと物理リソースの対応関係の更新を行い（ステップＳ２４２）、管理者に対処結果を通知する（ステップＳ２４３）。
【０１４０】
このように、システムに性能劣化が発生した場合に、ワークグループシステムリソースマネジャ１０５が性能劣化の箇所及び原因を特定し、スタンバイプールから追加リソースを選択し、システム構成の検証、設定変更を行うことによって、迅速な回復を行うことができる。
【０１４１】
次に、プールのリソース補充処理について説明する。図３３は、プールのリソース補充処理の処理手順を示すシーケンス図である。同図に示すように、このプールのリソース補充処理は、ワークグループシステムリソースマネジャ１０５が、スタンバイプールのリソースが最低量未満であるか、または、ベアメタルプールのリソースが最低量より多いか否かを調べ、スタンバイプールのリソースが最低量未満であるか、または、ベアメタルプールのリソースが最低量より多い場合には、ベアメタルプールからスタンバイプールへリソース補充を行い（ステップＳ３０１）、共有プールからベアメタルプールへリソース補充を行う（ステップＳ３０２）。
【０１４２】
一方、スタンバイプールのリソースが最低量未満でなく、かつ、ベアメタルプールのリソースが最低量より多くない場合には、まず、共有プールからベアメタルプールへリソース補充を行い（ステップＳ３０３）、共有プールからベアメタルプールへリソース補充ができた場合には、ベアメタルプールからスタンバイプールへリソース補充を行う（ステップＳ３０４）。
【０１４３】
そして、プール補充結果を管理者に通知する（ステップＳ３０５）。
【０１４４】
次に、共有プールからベアメタルプールへのリソース補充処理について説明する。図３４は、共有プールからベアメタルプールへのリソース補充処理の処理手順を示すシーケンス図である。なお、図３４において、「break」は１レベル外の枠へのジャンプを示す。
【０１４５】
同図に示すように、このリソース補充処理は、ワークグループシステムリソースマネジャ１０５が、共有プールに条件を満たす予備サーバが存在するか否かを判定する。なお、共有プールに条件を満たすリソースがあるか否かの判定は、図１１〜１６に示した各リソースの型番、仕様、性能値を用いて行う。
【０１４６】
そして、共有プールに条件を満たす予備サーバが存在する場合には、図３０に示した共有プールから適当なサーバを選択し（ステップＳ４０１）、共有プールからベアメタルプールへサーバを補充する。また、図２９に示したサービスとリソースの対応関係及び図３０に示した共有プールの情報を更新する（ステップＳ４０２）。
【０１４７】
一方、共有プールに条件を満たす予備サーバが存在しない場合には、ベアメタルプールのリソースが最低量未満またはスタンバイプールのリソースが最低量未満であるか否かを調べ、ベアメタルプールのリソースが最低量未満またはスタンバイプールのリソースが最低量未満である場合には、他のサービスのリソースから適当なサーバを検索する（ステップＳ４０３）。
【０１４８】
そして、優先度の低い他のサービスからリソースを横取りすることができるか否かを判定し、横取りできない場合には、管理者にプール補充失敗の通知を行い（ステップＳ４０４）、処理を終了する。
【０１４９】
一方、リソースを横取りできる場合には、ワークグループサービスマネジャ１０３にサービス構成変更を依頼し（ステップＳ４０５）、ワークグループサーバリソースマネジャ１０８を介して対象ノードに設定変更を指示する（ステップＳ４０６〜ステップＳ４０７）。そして、対象ノードから設定完了の通知をワークグループサーバリソースマネジャ１０８を介して受け取ると（ステップＳ４０８〜ステップＳ４０９）、図２９に示したサービスとリソースの対応関係及び図３０に示した共有プールの情報を更新し（ステップＳ４１０）、サービス構成変更をワークグループサービスマネジャ１０３に通知する（ステップＳ４１１）。
【０１５０】
このように、ワークグループシステムリソースマネジャ１０５が、共有プールに条件を満たす予備リソースが存在するか否かを各リソースの型番、仕様、性能値を用いて判定し、条件を満たす予備リソースが存在する場合には、共有プールから適当なリソースを選択してベアメタルプールへ補充することによって、障害の復旧や性能劣化からの回復を迅速に行うことができる。
【０１５１】
次に、ベアメタルプールからスタンバイプールへのリソース補充処理について説明する。図３５は、ベアメタルプールからスタンバイプールへのリソース補充処理の処理手順を示すシーケンス図である。
【０１５２】
同図に示すように、このリソース補充処理は、ワークグループシステムリソースマネジャ１０５が、図２９に示したサービスとリソースの対応関係を用いてベアメタルプールから適当なサーバを選択し（ステップＳ５０１）、ベアメタルプールからスタンバイプールへサーバを補充するとともに、サービスとリソースの対応関係を更新する（ステップＳ５０２）。
【０１５３】
そして、ワークグループサーバリソースマネジャ１０８を介して対象ノードに設定変更を指示し（ステップＳ５０３〜ステップＳ５０４）、対象ノードの状態を「準備中」に更新する（ステップＳ５０５）。
【０１５４】
そして、対象ノードから設定完了の通知をワークグループサーバリソースマネジャ１０８を介して受け取ると（ステップＳ５０６〜ステップＳ５０７）、対象ノードの状態を「準備完了」に更新する（ステップＳ５０８）。
【０１５５】
このように、ワークグループシステムリソースマネジャ１０５が、ベアメタルプールから適当なリソースを選択してスタンバイプールへ補充し、リソースをサービスレイヤに特化した準備完了状態にすることによって、障害の復旧や性能劣化からの回復を最低限のレスポンス時間で行うことができる。
【０１５６】
なお、図３６−１及び３６−２は、本実施例に係る自律制御システムの障害時の監視・計測、分析、設計、検証、操作の各機能を示す図（１）及び（２）である。同図は、障害時に各マネジャが行う監視・計測、分析、設計、検証、操作の対象範囲と、機能と、制御の流れとを示している。
【０１５７】
例えば、ワークグループシステムリソースマネジャ１０５は、障害時に分析としてシステム全体を対象範囲とする影響範囲の特定を行い、(3)-(c)すなわちワークグループシステムリソースマネジャ１０５の設計段階へ移行する。
【０１５８】
また、図３７−１及び３７−２は、本実施例に係る自律制御システムの性能劣化時の監視・計測、分析、設計、検証、操作の各機能を示す図（１）及び（２）である。同図は、性能劣化時に各マネジャが行う監視・計測、分析、設計、検証、操作の対象範囲と、機能と、制御の流れとを示している。
【０１５９】
例えば、ノードサービスマネジャ２１２は、性能劣化時に監視・計測としてサーバノードを対象範囲とするミドルウェアの性能情報収集及びサーバノード単位／業務単位での負荷情報の収集を行い、(10)-(b)すなわちノードサービスマネジャ２１２の分析段階へ移行する。
【０１６０】
次に、本実施例に係るサーバノードとして動作するコンピュータシステムについて説明する。図３８は、本実施例に係るサーバノードとして動作するコンピュータシステムの一例を示す図である。同図に示すように、このコンピュータシステム４００は、本体部４０１と、本体部４０１からの指示により表示画面４０２ａに情報を表示するディスプレイ４０２と、このコンピュータシステム４００に種々の情報を入力するためのキーボード４０３と、ディスプレイ４０２の表示画面４０２ａ上の任意の位置を指定するマウス４０４と、ＬＡＮ４０６または広域エリアネットワーク（ＷＡＮ）に接続するＬＡＮインタフェースと、公衆回線４０７に接続するモデムとを有する。ここで、ＬＡＮ４０６は、他のサーバ４１１、プリンタ４１２などとコンピュータシステム４００とを接続している。
【０１６１】
また、図３９は、図３８に示した本体部４０１の構成を示す機能ブロック図である。同図に示すように、この本体部４０１は、ＣＰＵ４２１と、ＲＡＭ４２２と、ＲＯＭ４２３と、ハードディスクドライブ（ＨＤＤ）４２４と、ＣＤ−ＲＯＭドライブ４２５と、ＦＤドライブ４２６と、Ｉ／Ｏインタフェース４２７と、ＬＡＮインタフェース４２８と、モデム４２９とを有する。
【０１６２】
そして、このコンピュータシステム４００において実行される自律制御プログラムは、フロッピィディスク（ＦＤ）４０８、ＣＤ−ＲＯＭ４０９、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの可搬型記憶媒体に記憶され、これらの記憶媒体から読み出されてコンピュータシステム４００にインストールされる。
【０１６３】
あるいは、この自律制御プログラムは、ＬＡＮインタフェース４２８を介して接続されたサーバ４１１のデータベースなどに記憶され、これらのデータベースから読み出されてコンピュータシステム４００にインストールされる。
【０１６４】
そして、インストールされた自律制御プログラムは、ＨＤＤ４２４に記憶され、ＲＡＭ４２２、ＲＯＭ４２３などを利用してＣＰＵ４２１により実行される。
【０１６５】
上述してきたように、本実施例では、ポリシーＤＢ１０２などに各種ポリシーを記憶し、システムを構成する各ノードが他のノードと連携するとともに、ポリシーに基づいて自律制御を行うこととしたので、障害や急激な負荷変動に対して柔軟な自律制御を行うことができる。
【０１６６】
また、本実施例では、予備のリソースを共有プール、ベアメタルプール及びスタンバイプールを用いて管理することとしたので、スタンバイプールを中心としてリソースを管理することによって障害からの復旧や性能劣化からの回復を高速に行うことが可能であるとともに、共有プールを中心としてリソースを管理することによってリソースを効率良く利用することができる。
【０１６７】
（付記１）ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラムであって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出手順と、
前記ポリシー読出手順により読み出されたポリシーに基づいて自律制御を行う制御実行手順と、
をコンピュータに実行させることを特徴とする自律制御プログラム。
【０１６８】
（付記２）前記ポリシーは、前記情報処理システム全体についてのポリシーと、各情報処理装置ごとのポリシーとから構成されることを特徴とする付記１に記載の自律制御プログラム。
【０１６９】
（付記３）前記ポリシーは、情報処理システムを運用してサービスを提供するセンターのポリシーと、情報処理システムを利用する顧客のポリシーと、情報処理システムの提供するサービスのポリシーとから構成されることを特徴とする付記１に記載の自律制御プログラム。
【０１７０】
（付記４）前記情報処理システムは、提供するサービスのサービスモデルを構成する複数のサービス階層の各階層にリソースである情報処理装置を割り当て、
利用されていない予備のリソースを集めて共有プールとして管理し、
共有プールの中のリソースのうち各サービス階層で利用可能であると判定されたリソースをサービス階層ごとに集めてベアメタルプールとして管理し、
ベアメタルプールの中から選択して各サービス階層での利用に必要な準備を完了したリソースをサービス階層ごとに集めてスタンバイプールとして管理し、
前記制御実行手順は、スタンバイプール、ベアメタルプール、共有プールの順に必要な予備のリソースを探して自律制御を行うことを特徴とする付記１、２または３に記載の自律制御プログラム。
【０１７１】
（付記５）共有プールの中のリソースのうち各サービス階層で利用可能であるか否かの判定は、各リソースのハードウェア仕様と物理接続とに基づいて行われることを特徴とする付記４に記載の自律制御プログラム。
【０１７２】
（付記６）前記制御実行手順は、予備のリソースを使用する場合に、予備のリソースを運用状態にする操作と並行してスタンバイプールおよびベアメタルプールの補充処理を行うことを特徴とする付記４に記載の自律制御プログラム。
【０１７３】
（付記７）前記サービスモデルは、インターネットとイントラネットとを接続するＦｒｏｎｔ層、ウェブサーバが配置されるＷｅｂ層、アプリケーションサーバが配置されるＡＰ層及びデータベースサーバが配置されるＤＢ層から構成されることを特徴とする付記４に記載の自律制御プログラム。
【０１７４】
（付記８）前記制御実行手順は、いずれかの情報処理装置に障害が発生した場合には、該障害が発生した情報処理装置の代替装置として動作する情報処理装置を予備のリソースから選択して障害を復旧し、前記情報処理システムに所定の大きさを超える負荷変動が発生した場合には、リソースの再配置を行うことによって自律制御を行うことを特徴とする付記４に記載の自律制御プログラム。
【０１７５】
（付記９）前記情報処理システムは、サーバ、ストレージおよびネットワーク装置を情報処理装置として構成されるシステムであることを特徴とする付記１、２または３に記載の自律制御プログラム。
【０１７６】
（付記１０）ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラムであって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出手順と、
前記ポリシー読出手順により読み出されたポリシーに基づいて各情報処理装置に制御指示を行う制御指示手順と、
をコンピュータに実行させることを特徴とする自律制御プログラム。
【０１７７】
（付記１１）ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出手順と、
前記ポリシー読出手順により読み出されたポリシーに基づいて自律制御を行う制御実行手順と、
をコンピュータに実行させる自律制御プログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【０１７８】
（付記１２）ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出手順と、
前記ポリシー読出手順により読み出されたポリシーに基づいて各情報処理装置に制御指示を行う制御指示手順と、
をコンピュータに実行させる自律制御プログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【０１７９】
（付記１３）ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御装置であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶したポリシー記憶手段と、
前記ポリシー記憶手段により記憶されたポリシーに基づいて自律制御を行う制御実行手段と、
を備えたことを特徴とする自律制御装置。
【０１８０】
（付記１４）ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御装置であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶したポリシー記憶手段と、
前記ポリシー記憶手段により記憶されたポリシーに基づいて各情報処理装置に制御指示を行う制御指示手段と、
を備えたことを特徴とする自律制御装置。
【０１８１】
（付記１５）ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御方法であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出工程と、
前記ポリシー読出工程により読み出されたポリシーに基づいて自律制御を行う制御実行工程と、
を含んだことを特徴とする自律制御方法。
【０１８２】
（付記１６）ネットワークにより接続された複数の情報処理装置から構成される情報処理システムを自律制御する自律制御方法であって、
前記情報処理システムを管理するにあたっての要件であるポリシーを記憶した記憶装置から該ポリシーを読み出すポリシー読出工程と、
前記ポリシー読出工程により読み出されたポリシーに基づいて各情報処理装置に制御指示を行う制御指示工程と、
を含んだことを特徴とする自律制御方法。
【産業上の利用可能性】
【０１８３】
以上のように、本発明に係る自律制御プログラム及びその記録媒体、自律制御装置並びに自律制御方法は、サーバ、ストレージ及びネットワーク装置から構成される情報処理システムに有用であり、特に、ポリシーに基づいて柔軟な自律制御を行いたい場合に適している。
【図面の簡単な説明】
【０１８４】
【図１】本実施例に係る自律制御ループの概念を説明するための説明図である。
【図２】本実施例に係る自律制御ループの相関図である。
【図３】本実施例に係る自律制御におけるリソースプールの概念を説明するための説明図である。
【図４】本実施例に係る自律制御システムのシステム構成を示す機能ブロック図である。
【図５】本実施例に係る自律制御システムのサービスモデルの構成を示す図である。
【図６】本実施例に係る自律制御システムの論理構成を示す図である。
【図７】本実施例に係る自律制御システムの物理構成を示す図である。
【図８】ポリシーの全体イメージを示す図である。
【図９】ポリシーの全体構成を示す図である。
【図１０】ポリシーの詳細を示す図である。
【図１１】物理サーバと型番の対応関係の一例を示す図である。
【図１２】物理サーバの型番詳細情報の一例を示す図である。
【図１３】物理ネットワークと型番の対応関係の一例を示す図である。
【図１４】物理ネットワークの型番詳細情報の一例を示す図である。
【図１５】物理ストレージと型番の対応関係の一例を示す図である。
【図１６】物理ストレージの型番詳細情報の一例を示す図である。
【図１７】物理リソース接続関係の一例を示す図である。
【図１８】物理―論理マッピングの一例を示す図である。
【図１９】論理サーバとタイプの対応関係の一例を示す図である。
【図２０】論理サーバのタイプ詳細情報の一例を示す図である。
【図２１】論理ネットワークとタイプの対応関係の一例を示す図である。
【図２２】論理ネットワークのタイプ詳細情報の一例を示す図である。
【図２３】論理ストレージとタイプの対応関係の一例を示す図である。
【図２４】論理ストレージのタイプ詳細情報の一例を示す図である。
【図２５】論理リソース接続関係の一例を示す図である。
【図２６】論理サーバとサービスレイヤの対応関係の一例を示す図である。
【図２７】論理ストレージとサービスレイヤの対応関係の一例を示す図である。
【図２８】論理ネットワークとサービスレイヤの対応関係の一例を示す図である。
【図２９】サービスとリソースの対応関係の一例を示す図である。
【図３０】共有プールに登録される物理サーバの一例を示す図である。
【図３１−１】サーバ故障からの復旧処理の処理手順を示すシーケンス図（１）である。
【図３１−２】サーバ故障からの復旧処理の処理手順を示すシーケンス図（２）である。
【図３１−３】サーバ故障からの復旧処理の処理手順を示すシーケンス図（３）である。
【図３１−４】サーバ故障からの復旧処理の処理手順を示すシーケンス図（４）である。
【図３２−１】性能劣化からの回復処理の処理手順を示すシーケンス図（１）である。
【図３２−２】性能劣化からの回復処理の処理手順を示すシーケンス図（２）である。
【図３２−３】性能劣化からの回復処理の処理手順を示すシーケンス図（３）である。
【図３２−４】性能劣化からの回復処理の処理手順を示すシーケンス図（４）である。
【図３３】プールのリソース補充処理の処理手順を示すシーケンス図である。
【図３４】共有プールからベアメタルプールへのリソース補充処理の処理手順を示すシーケンス図である。
【図３５】ベアメタルプールからスタンバイプールへのリソース補充処理の処理手順を示すシーケンス図である。
【図３６−１】本実施例に係る自律制御システムの障害時の監視・計測、分析、設計、検証、操作の各機能を示す図（１）である。
【図３６−２】本実施例に係る自律制御システムの障害時の監視・計測、分析、設計、検証、操作の各機能を示す図（２）である。
【図３７−１】本実施例に係る自律制御システムの性能劣化時の監視・計測、分析、設計、検証、操作の各機能を示す図（１）である。
【図３７−２】本実施例に係る自律制御システムの性能劣化時の監視・計測、分析、設計、検証、操作の各機能を示す図（２）である。
【図３８】本実施例に係るサーバノードとして動作するコンピュータシステムの一例を示す図である。
【図３９】図３８に示した本体部の構成を示す機能ブロック図である。
【符号の説明】
【０１８５】
１００    管理ノード
１０１    ポリシーマネジャ
１０２    ポリシーＤＢ
１０３    ワークグループサービスマネジャ
１０４    ワークグループサービスＤＢ
１０５    ワークグループシステムリソースマネジャ
１０６    ワークグループシステムＤＢ
１０７    ワークグループリソースコーディネータ
１０８    ワークグループサーバリソースマネジャ
１０９    ワークグループサーバＤＢ
１１０    ワークグループストレージリソースマネジャ
１１１    ワークグループストレージＤＢ
１１２    ワークグループネットワークリソースマネジャ
１１３    ワークグループネットワークＤＢ
１１４    オープンＩ／Ｆ
２１０，２４０    サーバノード
２１１    ノードシステムリソースマネジャ
２１２    ノードサービスマネジャ
２１３    ノードリソースコーディネータ
２１４    ノードサーバリソースマネジャ
２１５    ノードストレージリソースマネジャ
２１６    ノードネットワークリソースマネジャ
２２０，２５０    ストレージノード
２２１    ストレージノードリソースマネジャ
２３０，２６０    ネットワークノード
２３１    ネットワークノードリソースマネジャ
２４１    マルチベンダサーバ／ストレージ／ネットワークリソースマネジャ
２５１    ストレージマルチベンダリソースマネジャ
２６１    ネットワークマルチベンダリソースマネジャ
３０１    ルータ
３０２    Ｗｅｂサーバ
３０３    ＡＰサーバ
３０４    ＤＢサーバ
３０５    ストレージ
４００    コンピュータシステム
４０１    本体部
４０２    ディスプレイ
４０２ａ    表示画面
４０３    キーボード
４０４    マウス
４０６    ＬＡＮ
４０７    公衆回線
４０８    フロッピィディスク
４０９    ＣＤ−ＲＯＭ
４１１    サーバ
４１２    プリンタ
４２１    ＣＰＵ
４２２    ＲＡＭ
４２３    ＲＯＭ
４２４    ハードディスクドライブ
４２５    ＣＤ−ＲＯＭドライブ
４２６    フロッピィディスクドライブ
４２７    Ｉ／Ｏインタフェース
４２８    ＬＡＮインタフェース
４２９    モデム
【図１】
2005346204.tif 000003
【図２】
2005346204.tif 000004
【図３】
2005346204.tif 000005
【図４】
2005346204.tif 000006
【図５】
2005346204.tif 000007
【図６】
2005346204.tif 000008
【図７】
2005346204.tif 000009
【図８】
2005346204.tif 000010
【図９】
2005346204.tif 000011
【図１０】
2005346204.tif 000012
【図１１】
2005346204.tif 000013
【図１２】
2005346204.tif 000014
【図１３】
2005346204.tif 000015
【図１４】
2005346204.tif 000016
【図１５】
2005346204.tif 000017
【図１６】
2005346204.tif 000018
【図１７】
2005346204.tif 000019
【図１８】
2005346204.tif 000020
【図１９】
2005346204.tif 000021
【図２０】
2005346204.tif 000022
【図２１】
2005346204.tif 000023
【図２２】
2005346204.tif 000024
【図２３】
2005346204.tif 000025
【図２４】
2005346204.tif 000026
【図２５】
2005346204.tif 000027
【図２６】
2005346204.tif 000028
【図２７】
2005346204.tif 000029
【図２８】
2005346204.tif 000030
【図２９】
2005346204.tif 000031
【図３０】
2005346204.tif 000032
【図３１−１】
2005346204.tif 000033
【図３１−２】
2005346204.tif 000034
【図３１−３】
2005346204.tif 000035
【図３１−４】
2005346204.tif 000036
【図３２−１】
2005346204.tif 000037
【図３２−２】
2005346204.tif 000038
【図３２−３】
2005346204.tif 000039
【図３２−４】
2005346204.tif 000040
【図３３】
2005346204.tif 000041
【図３４】
2005346204.tif 000042
【図３５】
2005346204.tif 000043
【図３６−１】
2005346204.tif 000044
【図３６−２】
2005346204.tif 000045
【図３７−１】
2005346204.tif 000046
【図３７−２】
2005346204.tif 000047
【図３８】
2005346204.tif 000048
【図３９】
2005346204.tif 000049