(57)【特許請求の範囲】
【請求項１】
情報処理装置であって、
所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報が格納された記憶手段と、
前記コンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行う処理手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記処理手段は、リスク情報として、各コンポーネントの組み合わせにおけるリスクの統計量を算出する手段を有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記処理手段は、リスク情報として、各コンポーネントの組み合わせにおけるリスクの統計量であるところの平均及び／又は分散を算出する手段を有することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記処理手段は、フラグメント情報として、各コンポーネントの組み合わせにおけるフラグメントの統計量を算出する手段を特徴とする請求項１から請求項３のいずれかに記載の情報処理装置。
【請求項５】
前記処理手段は、フラグメント情報として、各コンポーネントの組み合わせにおけるフラグメントの統計量であるところの平均及び／又は分散を算出する手段を特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記記憶手段に格納されるコンポーネント情報が、物理的な資源の情報であることを特徴とする請求項１から請求項５のいずれかに記載の情報処理装置。
【請求項７】
前記記憶手段に格納されるコンポーネント情報が、物理的な資源の物理資源情報と、前記物理資源情報と関連付けられ、前記物理的な資源を仮想化してコンポーネント化した仮想化資源の仮想化資源情報とから成り、
前記処理手段は、前記コンポーネント情報に基づいて、一つの仮想化された資源を一つのコンポーネントとしてコンポーネントの組み合わせを算出する手段を有することを特徴とする請求項１から請求項６のいずれかに記載の情報処理装置。
【請求項８】
情報処理装置のプログラムであって、
前記プログラムは情報処理装置を、
所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行う手段として機能させることを特徴とする情報処理装置のプログラム。
【請求項９】
リスク情報が各コンポーネントの組み合わせにおけるリスクの統計量であることを特徴とする請求項８に記載の情報処理装置のプログラム。
【請求項１０】
リスク情報が各コンポーネントの組み合わせにおけるリスクの統計量であるところの平均及び／又は分散であることを特徴とする請求項９に記載の情報処理装置のプログラム。
【請求項１１】
フラグメント情報が各コンポーネントの組み合わせにおけるフラグメントの統計量であることを特徴とする請求項８から請求項１０のいずれかに記載の情報処理装置のプログラム。
【請求項１２】
フラグメント情報が各コンポーネントの組み合わせにおけるフラグメントの統計量であるところの平均及び／又は分散であることを特徴とする請求項１１に記載の情報処理装置のプログラム。
【請求項１３】
前記コンポーネントが、物理的な資源であることを特徴とする請求項８から請求項１２のいずれかに記載の情報処理装置のプログラム。
【請求項１４】
前記コンポーネントが、物理的な資源を仮想化した資源であることを特徴とする請求項８から請求項１３のいずれかに記載の情報処理装置のプログラム。
【請求項１５】
モジュラー型システムの運用管理システムであって、
ネットワークと接続され、管理対象であるモジュラー型システムを構成する物理資源と、
ネットワークと接続され、前記物理資源が提供する設定項目もしくは稼動データ項目の情報取得要求データ、設定要求データ、並びにポリシーデータを送信する端末と、
ネットワークに接続され、前記物理資源の情報である物理資源情報と、前記物理資源が提供する設定・稼動データ項目について参照又は変更を行う項目の情報が抽出された仮想資源情報と、前記仮想資源から構成される仮想サービスグループの情報であって、前記仮想資源が提供する設定・稼動データ項目について参照又は変更を行う項目の情報が抽出・加工された仮想サービスグループ空間情報と、前記仮想資源が提供する設定・稼動データ項目について参照又は変更を行う際の処理情報を記載したポリシー情報とを備え、
前記端末から送信される前記物理資源又は仮想資源の設定要求に応答し、前記仮想資源情報及びポリシー情報に基づいて最適化演算による解を算出し、この解に基づいて、仮想資源サービスグループの最適設定を行い、前記仮想サービスグループ空間情報を作成・管理し、前記端末に送信し、また前記各情報に対する情報取得要求に対して前記端末に情報を送信する手段とを有するコントローラと
を有することを特徴とするモジュラー型システムの運用管理システム。
【請求項１６】
前記コントローラは、前記設定要求に対して、前記物理資源情報又は前記仮想資源情報を用いて、物理的な障害が前記設定要求に及ぼすリスクの情報であるリスク情報を算出し、前記仮想サービスグループ空間情報を作成・管理する手段を有することを特徴とする請求項１５に記載のモジュラー型システムの運用管理システム。
【請求項１７】
前記コントローラは、前記設定要求に対して、前記物理資源情報又は前記仮想資源情報を用いて、資源利用状況の偏り度合いであるところのフラグメント情報を算出し、前記仮想サービスグループ空間情報を作成・管理する手段を有することを特徴とする請求項１５又は請求項１６に記載のモジュラー型システムの運用管理システム。
【請求項１８】
前記コントローラは、
前記物理資源の情報が格納される物理資源情報データベースと、
前記物理資源データベースの読み書き、情報更新、監視等の管理を行う物理資源管理手段と、
前記仮想資源の情報が格納される仮想資源情報データベースと、
前記仮想資源データベースの読み書き、情報更新、監視等の管理を行う仮想資源管理手段と、
前記仮想サービスグループ空間の情報が格納される仮想サービスグループ空間情報データベースと、
前記仮想サービスグループ空間情報データベースの読み書き、情報更新、監視等の管理を行う仮想サービスグループ管理手段と、
前記ポリシーの情報が格納されるポリシー情報データベースと、
前記ポリシー情報データベースの読み書き、情報更新、監視等の管理を行うポリシー管理手段と
を有することを特徴とする請求項１５から請求項１７のいずれかに記載のモジュラー型システムの運用管理システム。
【請求項１９】
前記コントローラは、物理資源とネットワークを介して通信し、必要なデータの送受信を行う通信手段を有することを特徴とする請求項１５から請求項１８のいずれかに記載のモジュラー型システムの運用管理システム。
【請求項２０】
前記コントローラは、障害発生時に、物理資源からのアラーム信号の受信、又はコントローラからの定期的な信号送信による状態検査により、異常を検知する手段と、前記物理資源管理手段、前記仮想資源管理手段、前記仮想サービスグループ管理手段に、前記異常検知を通知する手段とを有し、
前記物理資源管理手段、前記仮想資源管理手段及び前記仮想サービスグループ管理手段は、前記異常検知に基づいて、管理するデータベースの情報を更新することを特徴とする請求項１５から請求項１９のいずれかに記載のモジュラー型システムの運用管理システム。
【請求項２１】
システム変更時に、前記物理資源管理手段、前記仮想資源管理手段及び前記仮想サービスグループ管理手段は、増設や変更などのシステム変更時に、管理するデータベースの情報を更新し、
前記コントローラは、前記更新された情報に基づいて、前記最適化演算を自動的に又は管理者の指令によるトリガーによって再演算し、この結果に基づいて仮想資源サービスグループの最適設定を行う手段を有することを特徴とする請求項１５から請求項２０のいずれかに記載のモジュラー型システムの運用管理システム。
【請求項２２】
サービスで要求されるシステムを構成するに必要なコンポーネントを選択するコンポーネント選択方法であって、
所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、
これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、
所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行う
ことを特徴とするコンポーネント選択方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システムに関する。
【背景技術】
【０００２】
近年のインターネットの広範な普及により、コンピュータ、ネットワークをもちいた電子的業務管理システムはビジネス基盤や社会的なインフラとして完全に定着し、インターネット関連システムにおいて高いレベルのミッションクリティカル性が求められている。そのため、そのようなシステムには、一般に障害発生時にも業務を停止することなく予備資源に切り替わるような冗長構成が組まれることが行われる。【０００３】
冗長化を行う上で、装置内を二重化し片方をアクティブ、もう一方をスタンバイに設定し装置内のコンポーネントレベルでの障害に備え、さらに、電源故障など装置単位の故障に備え複数の装置で冗長グループを構成し、そのうちの一つをアクティブとし、その他をスタンバイ資源とする手法がある。ただしこの際、この装置を使用してサービスを受けるユーザからは単一の装置として見えるよう仮想化されている必要がある。
ひとつの手法として装置間冗長は一般に冗長用の専用プロトコルが使用される。例えば、図２０に記載のルータの場合、ルータ４０５内部において資源４０１および４０２で内部二重化４０１１を設定しておいて、非特許文献１に記載の複数のルータ間での冗長化プロトコルVRRP(Virtual Router Redundancy Protocol)を用いてVRRP V10により装置間での冗長化を行うことで、前記の冗長化構成をとることができる。この際、本ルータを使用するユーザからは一つの仮想ルータ４０７があるように見えている。【０００４】
また装置内のコンポーネント故障に対する内部での二重化は、物理的装置そのものを変えずに内部での切り替えのみでよいことから、障害復旧手法として装置自体を切り替えるより望ましいが、二重化された装置を冗長のために多数用意するとスタンバイ資源の二重化が生じ、資源利用効率は最大でもａｃｔｉｖｅ：ｓｔａｎｄｂｙ＝１：１の５０％であり、ひとつの冗長化資源をＮ台でシェアするＮ＋１のような構成を組むことは難しい。また、ディスクリートな装置を並べるのはより空間を消費するし、無駄も多い。そこで機能の決まったディスクリートな装置を用いる代わりに、統一されたプラットフォームにモジュラー化されたユニット資源を搭載し、必要な設定を行うことで自由に必要な装置を仮想的に形成すること（以後サービス）で、消費する空間の削減、資源利用効率の向上、利用形態のフレキシビリティ向上などが可能である。また、スタック技術を用いることで、複数の物理的に分離したシェルフをまたいで仮想的に一つのプラットフォーム上の資源として仮想化することも可能である。出荷時にすでにハードウェア設定などの各種設定が行われているディスクリートな装置にくらべ、前記のサービスでは、一般にハードウェア設定などが必要で装置設定などの管理業務が複雑になる。しかし資源の仮想化技術により、仮想資源プールを提供し、物理資源を例えば種類、性能などの性質に基づき対応する仮想資源プールに登録し、資源選択の際に必要でない情報を隠蔽し、仮想装置を構成する設定を容易にすることが行われる。例えば図２５にシェルフ９０４やユニット物理資源９０５を有する物理資源９０６を、物理的な配置などの資源利用者にとって不必要な情報を隠蔽し、その性能、種類などの属性で分類し仮想化プール９０１に登録する。資源利用者は物理資源９０６の情報を直接設定するのではなく、仮想資源プール内の仮想資源の情報をもとに設定を行い、仮想資源９０３とユニット物理資源９０５の間の関係などは管理ソフトウェアが管理し、ユーザはシステムの変更などで物理資源に変更があった場合も設定を変更する必要がなく、管理ソフトウェアの保持する関連情報を変更すればよい。【０００５】
仮想化された資源に対する論理的な設定により、上記のサービスを構成する仮想資源（以後コンポーネント）の二重化において、たとえば一つの仮想資源を、冗長構成を組む複数のサービス内のコンポーネント間で共有することが可能で、資源利用効率を向上することができる。そのため、例えば、あるサービスとしてルータを設定し、前記のように各ルータ内部のコンポーネントは二重化されており、かつ複数台のルータで冗長構成をとる場合、各ルータのstandbyコンポーネントがある資源を共有しながら論理的には複数台の別の装置として設定し、資源の有効利用を実現しながら装置内二重化を実現することなども可能である。また装置間二重化として、VRRPなどの外部冗長プロトコルにより冗長構成を組むが可能である。【０００６】
更に、冗長構成として例えば非特許文献２に記載のAIS（Application Interface Specification)の冗長フレームワークで規定されているように、２N、N+M、N-Wayな冗長構成がある。図２１〜図２３に冗長構成の一例を示す。サービスグループはあるサービスを提供するための集合として定義され、当該サービスグループの中にサービスインスタンス、ノード、サービスユニットが存在する。サービスインスタンスとは供給したいサービスの論理的エンティティであり、ノードは何らかの資源が供給される物理的資源の集まりをあらわす論理的エンティティであり、サービスユニットは当該ノード上に存在する論理的エンティティである。複数のサービスユニットが当該サービスインスタンスと関連付けられており、採用する冗長構成により、各サービスユニットはactiveもしくはstandbyとなり、activeが障害などで使用不能になったときにサービスインスタンスはstandbyのサービスユニットを指定し、障害復旧する。例えば図２１の構成は、サービスグループ５０１に対し、一つのサービスインスタンス５０２が存在し、それぞれノード５０５の上にあるサービスユニット５０３とノード５０６の上にあるサービスユニット５０４が定義され、サービスユニット５０３をａｃｔｉｖｅに、サービスユニット５０４をｓｔａｎｄｂｙに設定した別ノード上の２N（N＝１）冗長設定の例である。図２２、図２３は２Ｎ（Ｎ＝３）冗長構成の例である。【０００７】
ここで、サービスユニットをどういう冗長構成で各々をどのノードに配置するかで様々な冗長構成を指定できる。ノードは物理的資源の集合をさすため、リスクを共有している。そのため、ノード障害が起きると、その上に設定されたサービスユニットは使用不能となる。【０００８】
【非特許文献１】ＲＦＣ２３３８
【非特許文献２】ＳＡＩ−ＡＩＳ−Ａ．０１．０１、Ｐ６７
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、前記のプラットフォーム上のユニット物理資源を用いたサービスの内外での冗長化を構成・設定を行うには次のような問題点がある。【００１０】
第１の問題点は、多くのユニット物理資源を用いてシステム上に複数のサービスを様々な冗長構成で形成する場合、システム全体でのリスク管理が難しくなることである。その理由は、サービスを構成する物理資源や冗長構成といったサービス管理を行う管理者にとって、ディスクリートな装置ではリスク管理は比較的明らかであるが、物理的情報（位置情報、電源配線情報など）が入り組むと、物理的資源の故障部位によるリスク分類が不明瞭となるからである。【００１１】
第２の問題点は、資源の仮想化を行うことで、システム上に複数のサービスを様々な冗長構成で形成する際にシステム全体でのリスク管理が難しくなることである。その理由は、資源の仮想化を行うことで、サービスの設定の自由度が向上し管理システム内の資源をその物理的位置を意識することなく使用可能だが、サービスを構成する物理資源や冗長構成といったサービス管理を行う管理者にとって、仮想化された資源を用いてサービス設定を行う場合、物理的情報（位置情報、電源配線情報など）が入り組むと、物理的資源の故障部位によるリスク分類が不明瞭となる。このため、上記冗長化構成を設定する場合、仮想資源プールを物理リスクという観点から細分化しその情報を管理者に提供し、管理者は資源の詳細情報に基づいて、そのリスク分類をおこなう必要があるが、リスク分類の抽象化は行われていないため、管理者が情報をもとに自分で設定しなければならない。そのためシステムが肥大化・複雑化すると、その複雑さは加速的に増大し、管理業務が非常に困難となるからである。【００１２】
第３の問題点は、要求されるサービスの必要性能を達成できなかったり、資源有効利用効率が低下してしまったりする可能性があることである。その理由は、システムの設定変更・増設などを繰り返している間に、資源利用状況に偏り（以後フラグメント）が生じ、実際は物理的に離れた位置にあるユニット同士を集めてサービスを構成すると、その間の遅延などが原因で性能劣化が起こったり、逆に性能がでないなら使用しないというポリシーに従った場合、利用できない資源が出てきたりする可能性がある。特に同じ装置はなるべく物理的にも近い場所にあることが管理目的上望ましいが、フラグメント管理はシステムの肥大化・複雑化とともに加速的に複雑性を増し、サービス管理を行う管理者に負担を強いることになるからである。【００１３】
第４の問題点は、冗長化を行う場合、システムが大規模であると管理業務の複雑さにより人手による迅速な管理実行が事実上不可能になる可能性があることである。その理由は、大規模システムにおいては管理しなければならない資源の数は膨大であり、更にその上に論理的に集められたサービスおよびその構成物理資源との関連を管理しなければならず、リスク、フラグメント管理という観点から、要求されるサービスに最適なシステム構成を探索することは事実上不可能なほど複雑となるからである。【００１４】
そこで、本発明は上記課題に鑑みて発明されたものであって、複数のサービスを有するシステムにおいて、リスク管理、フラグメント管理を自動化する技術を提供することで、サービスやその冗長構成の設定を容易にし、サービス管理を行う管理者の負担を軽減し、またシステム更新などによる設定変更の際にもサービス設定においてその変更を意識せずに設定可能な情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システム、コンポーネント選択方法を提供することである。
【課題を解決するための手段】
【００１５】
上記課題を解決する第１の発明は、情報処理装置であって、所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報が格納された記憶手段と、前記コンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行う処理手段とを有することを特徴とする。【００１６】
上記課題を解決する第２の発明は、上記第１の発明において、前記処理手段は、リスク情報として、各コンポーネントの組み合わせにおけるリスクの統計量を算出する手段を有することを特徴とする。【００１７】
上記課題を解決する第３の発明は、上記第２の発明において、前記処理手段は、リスク情報として、各コンポーネントの組み合わせにおけるリスクの統計量であるところの平均及び／又は分散を算出する手段を有することを特徴とする。【００１８】
上記課題を解決する第４の発明は、上記第１から第３のいずれかの発明において、前記処理手段は、フラグメント情報として、各コンポーネントの組み合わせにおけるフラグメントの統計量を算出する手段を特徴とする。【００１９】
上記課題を解決する第５の発明は、上記第４の発明において、前記処理手段は、フラグメント情報として、各コンポーネントの組み合わせにおけるフラグメントの統計量であるところの平均及び／又は分散を算出する手段を特徴とする。【００２０】
上記課題を解決する第６の発明は、上記第１から第５いずれかの発明において、前記記憶手段に格納されるコンポーネント情報が、物理的な資源の情報であることを特徴とする。【００２１】
上記課題を解決する第７の発明は、上記第１から第６いずれかの発明において、前記記憶手段に格納されるコンポーネント情報が、物理的な資源の物理資源情報と、前記物理資源情報と関連付けられ、前記物理的な資源を仮想化してコンポーネント化した仮想化資源の仮想化資源情報とから成り、前記処理手段は、前記コンポーネント情報に基づいて、一つの仮想化された資源を一つのコンポーネントとしてコンポーネントの組み合わせを算出する手段を有することを特徴とする。【００２２】
上記課題を解決する第８の発明は、情報処理装置のプログラムであって、前記プログラムは情報処理装置を、所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行う手段として機能させることを特徴とする。【００２３】
上記課題を解決する第９の発明は、上記第８の発明において、リスク情報が各コンポーネントの組み合わせにおけるリスクの統計量であることを特徴とする。【００２４】
上記課題を解決する第１０の発明は、上記第９の発明において、リスク情報が各コンポーネントの組み合わせにおけるリスクの統計量であるところの平均及び／又は分散であることを特徴とする。【００２５】
上記課題を解決する第１１の発明は、上記第８から第１０のいずれかの発明において、フラグメント情報が各コンポーネントの組み合わせにおけるフラグメントの統計量であることを特徴とする。【００２６】
上記課題を解決する第１２の発明は、上記第１１の発明において、フラグメント情報が各コンポーネントの組み合わせにおけるフラグメントの統計量であるところの平均及び／又は分散であることを特徴とする。【００２７】
上記課題を解決する第１３の発明は、上記第８から第１２のいずれかの発明において、前記コンポーネントが、物理的な資源であることを特徴とする。【００２８】
上記課題を解決する第１４の発明は、上記第８から第１２のいずれかの発明において、前記コンポーネントが、物理的な資源を仮想化した資源であることを特徴とする。【００３１】
上記課題を解決する第１５の発明は、モジュラー型システムの運用管理システムであって、ネットワークと接続され、管理対象であるモジュラー型システムを構成する物理資源と、ネットワークと接続され、前記物理資源が提供する設定項目もしくは稼動データ項目の情報取得要求データ、設定要求データ、並びにポリシーデータを送信する端末と、ネットワークに接続され、前記物理資源の情報である物理資源情報と、前記物理資源が提供する設定・稼動データ項目について参照又は変更を行う項目の情報が抽出された仮想資源情報と、前記仮想資源から構成される仮想サービスグループの情報であって、前記仮想資源が提供する設定・稼動データ項目について参照又は変更を行う項目の情報が抽出・加工された仮想サービスグループ空間情報と、前記仮想資源が提供する設定・稼動データ項目について参照又は変更を行う際の処理情報を記載したポリシー情報とを備え、前記端末から送信される前記物理資源又は仮想資源の設定要求に応答し、前記仮想資源情報及びポリシー情報に基づいて最適化演算による解を算出し、この解に基づいて、仮想資源サービスグループの最適設定を行い、前記仮想サービスグループ空間情報を作成・管理し、前記端末に送信し、また前記各情報に対する情報取得要求に対して前記端末に情報を送信する手段とを有するコントローラとを有することを特徴とする。
【００３２】
上記課題を解決する第１６の発明は、上記第１５の発明において、前記コントローラは、前記設定要求に対して、前記物理資源情報又は前記仮想資源情報を用いて、物理的な障害が前記設定要求に及ぼすリスクの情報であるリスク情報を算出し、前記仮想サービスグループ空間情報を作成・管理する手段を有することを特徴とする。
【００３３】
上記課題を解決する第１７の発明は、上記第１５又は第１６の発明において、前記コントローラは、前記設定要求に対して、前記物理資源情報又は前記仮想資源情報を用いて、資源利用状況の偏り度合いであるところのフラグメント情報を算出し、前記仮想サービスグループ空間情報を作成・管理する手段を有することを特徴とする。
【００３４】
上記課題を解決する第１８の発明は、上記第１５から第１７のいずれかの発明において、前記コントローラは、前記物理資源の情報が格納される物理資源情報データベースと、前記物理資源データベースの読み書き、情報更新、監視等の管理を行う物理資源管理手段と、前記仮想資源の情報が格納される仮想資源情報データベースと、前記仮想資源データベースの読み書き、情報更新、監視等の管理を行う仮想資源管理手段と、前記仮想サービスグループ空間の情報が格納される仮想サービスグループ空間情報データベースと、前記仮想サービスグループ空間情報データベースの読み書き、情報更新、監視等の管理を行う仮想サービスグループ管理手段と、前記ポリシーの情報が格納されるポリシー情報データベースと、前記ポリシー情報データベースの読み書き、情報更新、監視等の管理を行うポリシー管理手段とを有することを特徴とする。
【００３５】
上記課題を解決する第１９の発明は、上記第１５から第１８のいずれかの発明において、前記コントローラは、物理資源とネットワークを介して通信し、必要なデータの送受信を行う通信手段を有することを特徴とする。
【００３６】
上記課題を解決する第２０の発明は、上記第１５から第１９のいずれかの発明において、前記コントローラは、障害発生時に、物理資源からのアラーム信号の受信、又はコントローラからの定期的な信号送信による状態検査により、異常を検知する手段と、前記物理資源管理手段、前記仮想資源管理手段、前記仮想サービスグループ管理手段に、前記異常検知を通知する手段とを有し、前記物理資源管理手段、前記仮想資源管理手段及び前記仮想サービスグループ管理手段は、前記異常検知に基づいて、管理するデータベースの情報を更新することを特徴とする。
【００３７】
上記課題を解決する第２１の発明は、上記第１５から第２０のいずれかの発明において、システム変更時に、前記物理資源管理手段、前記仮想資源管理手段及び前記仮想サービスグループ管理手段は、増設や変更などのシステム変更時に、管理するデータベースの情報を更新し、前記コントローラは、前記更新された情報に基づいて、前記最適化演算を自動的に又は管理者の指令によるトリガーによって再演算し、この結果に基づいて仮想資源サービスグループの最適設定を行う手段を有することを特徴とする。
【００３８】
上記課題を解決する第２２の発明は、サービスで要求されるシステムを構成するに必要なコンポーネントを選択するコンポーネント選択方法であって、所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行うことを特徴とする。
【００３９】
図２６を参照して、本発明の作用を説明すると、情報処理部１０の入力として、管理システム内の管理対象である複数のモジュラー型システムを構成するコンポーネントの情報であるコンポーネント情報１１と、システムに対するサービス設定・変更要求のサービス要求１２と、あらかじめ設定されたポリシー情報１３とを持つ。【００４０】
サービスで要求されるシステムはサービスユニットで構成され、サービスユニットはコンポーネントで構成される。コンポーネントとは、サービスで要求されるサービスユニットを構成するに必要な単一の物理的な資源のみならず、異なる物理的資源を複数用いて組み合わせ、一つの機能を持つ仮想的な物理資源群も含む概念である。【００４１】
まず、上記の入力データにおいて、サービス要求を満たすことが可能なコンポーネントの組み合わせを、コンポーネント情報１１に基づいて選択する。これらのコンポーネントの組み合わせの夫々について、リスク情報とフラグメント情報とを求める。【００４２】
リスク情報とは、物理的な障害がサービス要求に及ぼすリスクの情報であり、どの程度のリスクを持っているかという情報を数値化したものである。また、フラグメント情報とは、サービス要求を満たすコンポーネントの組み合わせにおいて、それを構成するコンポーネントの利用状態の偏りの情報を数値化したものである。尚、リスク情報、フラグメント情報を算出する際に、算出に使用する情報を重み付けをして優先度等を反映させても良い。【００４３】
そして、算出したリスク情報とフラグメント情報とをポリシー情報１３に基づいて参照し、コンポーネントの組み合わせの順位付けを行う。
【発明の効果】
【００４４】
第一の効果は、物理的資源や、この物理的資源を仮想化した仮想資源から、装置（仮想装置）やその冗長構成を設定する際に、サービス管理を行うサービス管理者から、システム変更に伴う複雑なリスク管理、資源利用状況のフラグメントの管理が隠蔽されることである。【００４５】
その理由は、図１８に記載の仮想サービスグループ空間４００５を提供し、サービス要求４０１４のサービスグループ４０１１、サービスユニット４０１２、コンポーネント４０１３、ノード４０１０に対して、リスク、フラグメントを最適化した仮想サービスグループ４００６、仮想サービスユニット４００７、仮想コンポーネント４００９、仮想ノード４００８を割り当て、システムの増設、変更などにより最適状態が変化しても、仮想サービスグループ層と仮想資源もしくは物理資源との最適な対応を自動的に設定することが可能な為である。【００４６】
第２の効果は、サービス管理者に負担をかけることなく、サービス要求をみたす設定の候補の中で最も望ましいリスク、又はフラグメントで最適な資源を選択することができることである。【００４７】
その理由は、サービス管理者の要求に伴い、使用可能な資源群の中から要求を満たす資源設定の候補を抽出し、その候補で構成される探索空間の中からリスク演算を行い最適な構成を選択し、その結果を仮想サービスグループに割り当て、登録・管理する機能を有する為である。【００４８】
第３の効果は、サービス管理を行う管理者に負担をかけることなく、サービス要求に記述された要求する性能、冗長構成を実現しながら、望ましいフラグメントで最適な資源を選択し、仮想装置を構成する資源をなるべく一塊にまとめて管理を容易にし、また資源利用効率の向上が可能な点である。【００４９】
その理由は上記仮想サービスグループ空間に対して、前記と同様に使用可能な資源群の中から要求を満たす資源の候補を抽出し、フラグメント演算によりフラグメントを最適化し、その結果を仮想サービスグループに割り当て、登録・管理する機能を有する為である。【００５０】
第４の効果は、フラグメント管理とリスク管理という二つの相互に関連する管理事項双方を同時に考慮して、自動的に望ましい設定を行うことができる点である。【００５１】
その理由は、仮想サービスグループ設定を決定する際に、管理ポリシーに従って適切な処理フローにより演算管理を行うことが可能な為である。
【図面の簡単な説明】
【００５２】
【図１】本発明の実施例１の構成を示すブロック図である。
【図２】実施例１において利用されるポリシー空間情報である。
【図３】実施例１において利用される物理資源空間情報である。
【図４】実施例１において利用される仮想資源空間情報である。
【図５】実施例１において利用される仮想サービスグループ空間情報である。
【図６】実施例１において利用される利用可能仮想資源空間情報である。
【図７】実施例１において利用される仮想サービスグループ探索空間情報である。
【図８】実施例１において利用される管理者サービス要求情報である。
【図９】実施例１における全体の動作を示す流れ図である。
【図１０】実施例１における全体の動作で特に管理者への設定確認を含む動作を示す流れ図である。
【図１１】実施例１における最適設定探索動作の流れ図である。
【図１２】実施例１におけるリスクパラメータ定義の説明図である。
【図１３】実施例１におけるリスク演算動作の流れ図である。
【図１４】実施例１におけるフラグメントパラメータ定義の説明図である。
【図１５】実施例１におけるフラグメント演算動作の流れ図である。
【図１６】実施例１における障害発生時の障害通知動作の流れ図である。
【図１７】実施例１において利用されるＩＤ情報の一例である。
【図１８】実施例１の効果を説明する使用例の模式図である。
【図１９】実施例１をすでに仮想化層がある場合に適用した場合の効果を説明する模式図である。
【図２０】従来のルータによるVRRPを用いた冗長化の例である。
【図２１】異なるノード上で２N（Ｎ＝１）冗長構成をとった例である。
【図２２】異なるノード上で２N（Ｎ＝３）冗長構成をとり、各々のノードにａｃｔｉｖｅとｓｔａｎｄｂｙをとった例である。
【図２３】異なるノード上で２N（Ｎ＝３）冗長構成をとり、かつ一つのノードをｓｔａｎｄｂｙ専用にとった例である。
【図２４】従来のモジュラー型ユニット物理資源が搭載された複数のシェルフなどのプラットフォーム装置で構成されるシステムで物理資源を仮想化し、その上に冗長構成構成をとる例である。
【図２５】従来のモジュラー型ユニット物理資源が搭載された複数のシェルフなどのプラットフォーム装置で構成されるシステムで物理資源を仮想化する例である。
【図２６】実施の形態の概念図である。
【図２７】コンポーネント情報の詳細を示した図である。
【図２８】サービス要求の詳細を示した図である。
【図２９】ポリシー情報の詳細を示した図である。
【図３０】コンポーネントの組み合わせ１の模式図である。
【図３１】コンポーネントの組み合わせ２の模式図である。
【図３２】コンポーネントの組み合わせ３の模式図である。
【図３３】コンポーネントの組み合わせ４の模式図である。
【図３４】複数の物理資源を一つのコンポーネントとして仮想化した例を示す図である。
【符号の説明】
【００５３】
１  端末
２  ネットワーク手段
３  コントローラ
４  物理資源
【発明を実施するための最良の形態】
【００５４】
本発明の実施の形態を説明する。【００５５】
図２６を参照すると、本システムは、情報処理部１０の入力として、管理システム内の管理対象である複数のモジュラー型システムを構成するコンポーネントの情報であるコンポーネント情報１１と、システムに対するサービス設定・変更要求のサービス要求１２と、あらかじめ設定されたポリシー情報１３とを持つ。情報処理部１０は、コンポーネント情報１１に記載のコンポーネントをつかって要求されるサービスを満たす全てのコンポーネントの組み合わせを選択し、この選択した組み合わせを、ポリシーに従ってソートする。そして、このソート結果を出力１４とする。【００５６】
以下の説明において、サービスで要求されるシステムはサービスユニットで構成されるものとする。サービスで要求されるシステムが冗長システムのスイッチ装置である場合、例えば、activeなスイッチ装置が一つのサービスユニットとなり、standbyなスイッチ装置も一つのサービスユニットとなる。【００５７】
更に、サービスユニットはコンポーネントで構成されるものとする。コンポーネントとは、サービスで要求されるサービスユニットを構成するに必要な単一の物理的な資源のみならず、異なる物理的資源を複数用いて組み合わせ、一つの機能を持つ仮想的な物理資源群も含む概念である。以下の説明では、本発明を理解し易いよう、コンポーネントを、シェルフのスロットに格納される単一の機能を持つ一つの物理的資源として説明し、そのコンポーネント情報の詳細を図２７に示す。図２７では、コンポーネント（物理的資源）の種類は一種類のみで、シェルフが４つの場合を示している。【００５８】
次に、サービス要求について説明する。【００５９】
本実施の形態では、図２８に示すように、一つのサービス要求は、サービスグループ１からサービスグループ７の全部で７つのサービスグループからなる。【００６０】
図２８中の各サービスグループの冗長は、サービスユニットを割り当てる冗長タイプを示し、例えば、１＋１は１つのactiveなサービスユニットと、１つのstandbyのサービスユニットとを示す。ここで、サービスユニットとは、上述した通り、要求されるサービスの機能を満たすユニットであり、複数又は単一のコンポーネント（物理的資源）から構成され、具体的には図２８中のコンポーネント数で示される数だけコンポーネントを集め、一つのサービスユニットが構成される。例えば、サービスグループ１の一サービスユニットは、３つのコンポーネントから構成される。【００６１】
図２８中の装置とは、冗長で指定されたサービスユニットを一つの装置として扱うか、別装置として扱うかを示し、例えば同一装置（全てのサービスユニットを一つの装置として扱う）と、別装置（全てのサービスユニットを別装置として扱う）の二種類が指定できる。【００６２】
図２８中のシェルフは、それぞれのサービスユニットを別のシェルフに配置するか、同一シェルフ内に配置するかなどの配置の仕方を記述したもので、同一シェルフ（同一のシェルフ内にサービスユニットを収容する）、別シェルフ（別々のシェルフにサービスユニットを収容する）などがある。【００６３】
図２８中のコンポーネント数は、一つのサービスユニットを構成するのに必要なコンポーネントの数である。この例ではコンポーネントはtype１のみしか持たないので、単純に数だけだが、属性（コンポーネント種類や性能など）が複数ある場合は、それぞれの属性に対する要求資源数を記述する。【００６４】
図２８に示されたサービス要求において、例えば、サービスグループ２は、コンポーネント属性type１のコンポーネントを２つ使って構成されるサービスユニットを二つもち、それぞれのサービスユニットを別のシェルフに格納し、一つはactive、もう一つはstandbyとして割り当てるというものである。【００６５】
次に、ポリシー情報について説明する。【００６６】
ポリシー情報とは、上述したサービス要求を満たすコンポーネントの組み合わせの集合を、どのような条件で優先順位をつけるかという情報である。この優先順位をつける情報として、本発明では、リスク情報、又はフラグメント情報を用いる。リスク情報とは、サービス要求を満たすコンポーネントの組み合わせにおいて、物理的な障害がサービス要求に及ぼすリスクの情報であり、どの程度のリスクを持っているかという情報を数値化したものである。また、フラグメント情報とは、サービス要求を満たすコンポーネントの組み合わせにおいて、それを構成するコンポーネントの利用状態の偏りの情報を数値化したものである。【００６７】
このようなポリシー情報の一例を図２９に示す。図２９中の優先演算は情報処理部１０での演算を記述しており、リスクのみはリスク演算のみでフラグメントを無視する。同様にフラグメントのみはリスクを無視する。リスク→フラグメントはリスクを先に演算し、そのあとフラグメントの低いものを選ぶ。フラグメント→リスクはその逆である。【００６８】
また、分割はリスクパラメータやフラグメントパラメータの平均、分散をどう処理するかを指定し、たとえば分割数が100で、探索する組み合わせの数が1000だった場合、平均値の少ない順に100個の区間に分け、同じ区間に属するものは平均値としては同じリスクとみなし、その区間内で分散値が小さい順にソートする。無限大は有効数字までの範囲で平均値ソートする。つまり分散よりも平均値を優先する。そのほかにも、例えば上位10%を同一リスクとする、分散を先に区間に分けてから平均値でソートするなどの指定も可能である。尚、ここで、リスクパラメータとは、共有リスクと、コンポーネントの故障率とを乗算した値である。また、共有リスクとは、１つのシェルフ内でactiveなサービスユニットの数であり、この数が多ければ、１つのシェルフが故障した場合に影響を与えるサービスユニットが多くなり、リスクが高い。また、フラグメントパラメータとは、サービスユニットを構成するコンポーネントの利用状況の偏りを表す値である。【００６９】
フラグメント上限は、可能な組み合わせの中で一つの装置を形成するのに、またいでいいシェルフ数を示す。例えば、コンポーネント数が４つのサービスユニットを構成する際、フラグメント上限が３に設定されていたら４つのシェルフからそれぞれ一つずつコンポーネントをとってきてサービスユニットを構成することは許されない。【００７０】
また、サービスの優先度等を反映させるため、リスクパラメータ、フラグメントパラメータに重み付けの概念を導入しても良い。例えば、優先度の高いサービスグループとシェルフを共有する場合、そのサービスグループに属するサービスユニットに対して、優先度を反映した重みづけ（例えば、１以上の数値を乗算）を付けるようにする。また、シェルフの故障率を重み付けとして、共有リスクに乗算するようにしても良い。【００７１】
上述のような条件の元で、情報処理部１０で行われる具体的な動作例を示す。【００７２】
まず、上記の入力データにおいて、サービス要求を満たすことが可能なコンポーネントの組み合わせを、コンポーネント情報１１に基づいて選択する。【００７３】
ここでは、サービスグループ１からサービスグループ７の条件を満たすコンポーネントの組み合わせが４つあったものとし、各組み合わせの模式図を図３０から図３３に示す。尚、図３０から図３３において、各コンポーネントの数値はどのサービスグループに使用されているかを示し、太線で囲まれた領域がactiveを示す。また、説明を容易にする為、優先度をあらわす重み及び故障率は一律１とした。【００７４】
ここで、図３０に示される組み合わせ１を用いて、リスク情報及びフラグメント情報の具体的な算出方法について説明する。【００７５】
まず、リスク情報ではリスクパラメータを算出する。【００７６】
シェルフ１において、サービスユニット３ａ及び４ａがactiveであるので、共有リスクは２であり、優先度をあらわす重み及び故障率は一律１なので、リスクパラメータは２（＝２×１×１）となる。シェルフ２において、サービスユニット５ａ及び７ａがactiveであるので、共有リスクは２であり、優先度をあらわす重み及び故障率は一律１なので、リスクパラメータは２（＝２×１×１）となる。シェルフ３において、サービスユニット１ｂ、２ｂ及び６ａがactiveであるので、共有リスクは３であり、優先度をあらわす重み及び故障率は一律１なので、リスクパラメータは３（＝３×１×１）となる。シェルフ４において、サービスユニット１ｃ及び２ｂがactiveであるので、共有リスクは２であり、優先度をあらわす重み及び故障率は一律１なので、リスクパラメータは２（＝２×１×１）となる。【００７７】
ここで、各シェルフのリスクパラメータをxi とし、シェルフ数をn とすると、リスクパラメータの平均は、
【数１】
0004304535.tif 000002
となるので、組み合わせ１のリスクパラメータの平均は2.25となる。【００７８】
また、リスクパラメータの分散は、
【数２】
0004304535.tif 000003
となるので、組み合わせ１のリスクパラメータの分散は0.25となる。【００７９】
これら求めたリスクパラメータの平均及び分散を組み合わせ１のリスク情報とする。【００８０】
次に、フラグメント情報ではフラグメントパラメータを算出する。【００８１】
フラグメントパラメータは一つの各サービスグループのサービスユニットを構成するコンポーネントの偏りを示す数値である。【００８２】
例えば、組み合わせ１のサービスグループ１のサービスユニット１ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット１ａのフラグメントパラメータは０（＝１−１）である。同様に、組み合わせ１のサービスグループ１のサービスユニット１ｂを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット１ｂのフラグメントパラメータは０（＝１−１）である。同様に、組み合わせ１のサービスグループ１のサービスユニット１ｃを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット１ｃのフラグメントパラメータは０（１−１）である。【００８３】
同様な方法で、組み合わせ１のサービスグループ２のサービスユニット２ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット２ａのフラグメントパラメータは０（＝１−１）である。サービスユニット２ｂを構成するコンポーネントは、二つのシェルフにまたがって収容されているので、サービスユニット２ｂのフラグメントパラメータは１（＝２−１）である。【００８４】
同様な方法で、組み合わせ１のサービスグループ３のサービスユニット３ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット３ａのフラグメントパラメータは０（＝１−１）である。サービスグループ３のサービスユニット３ｂを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット３ｂのフラグメントパラメータは０（＝１−１）である。【００８５】
同様な方法で、組み合わせ１のサービスグループ４のサービスユニット４ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット４ａのフラグメントパラメータは０（＝１−１）である。サービスユニット４ｂを構成するコンポーネントは二つのシェルフにまたがって収容されているので、サービスユニット４ｂのフラグメントパラメータは１（＝２−１）である。【００８６】
同様な方法で、組み合わせ１のサービスグループ５のサービスユニット５ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット５ａのフラグメントパラメータは０（＝１−１）である。サービスユニット５ｂを構成するコンポーネントは二つのシェルフにまたがって収容されているので、サービスユニット５ｂのフラグメントパラメータは１（＝２−１）である。【００８７】
同様な方法で、組み合わせ１のサービスグループ６のサービスユニット６ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット６ａのフラグメントパラメータは０（＝１−１）である。サービスユニット６ｂを構成するコンポーネントは二つのシェルフにまたがって収容されているので、サービスユニット６ｂのフラグメントパラメータは１（＝２−１）である。【００８８】
同様な方法で、組み合わせ１のサービスグループ７のサービスユニット７ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット７ａのフラグメントパラメータは０（＝１−１）である。サービスユニット７ｂを構成するコンポーネントは、二つのシェルフにまたがって収容されているので、サービスユニット７ｂのフラグメントパラメータは１（＝２−１）である。【００８９】
ここで、各サービスユニットのフラグメントパラメータをfi とし、サービスユニット数をn とすると、フラグメントパラメータの平均は、
【数３】
0004304535.tif 000004
となるので、組み合わせ１のフラグメントパラメータの平均は0.333333となる。【００９０】
また、フラグメントパラメータの分散は、
【数４】
0004304535.tif 000005
となるので、組み合わせ１のフラグメントパラメータの分散は0.238095となる。【００９１】
これら求めたフラグメントパラメータの平均及び分散を組み合わせ１のフラグメント情報とする。【００９２】
組み合わせ２、３、４についても、上述と同様な方法でリスク情報及びフラグメント情報を算出する。これらの結果を図３１から図３３に記載した。【００９３】
次に、リスク情報及びフラグメント情報に基づく、各コンポーネントの組み合わせの順位付けについて説明する。
（１）リスクのみ
ポリシーID=1の場合、リスク演算のみで、分割が無限大なので、リスクパラメータ平均でソートする。【００９４】
各シェルフのリスクパラメータをyi とし、シェルフ数をn とすると、リスクパラメータの平均は、
【数５】
0004304535.tif 000006
となる。【００９５】
従って、各組み合わせのリスクパラメータの平均は各図に示される通りとなり、組み合わせ４＜組み合わせ２＜組み合わせ１＜組み合わせ３の順でリスクが低くなる。ここで、組み合わせ４と２は平均が同じなので、リスクパラメータの分散の小さい４がよりリスク低となる。
（２）フラグメントのみ
ポリシーID=２の場合、フラグメント演算のみで、分割が無限大なので、フラグメントパラメータ平均でソートする。【００９６】
つまり、組み合わせ１＝組み合わせ２＜組み合わせ３＝組み合わせ４の順でフラグメントが低くなる。ここで、たとえば組み合わせ４と２は平均も分散も同じなのでフラグメントのみでは同順位となる。
（３）リスク→フラグメント
リスク演算で、すでに順序ができているので結果は（１）の場合と同じである。ここで、例えばリスクパラメータ平均aveが同じで、リスクパラメータ分散varが２以下なら同じリスクとする、というポリシーを設定しておいた場合は、組み合わせ４と組み合わせ２は同リスクとなるので、フラグメントの平均値の違いにより、組み合わせ２＜組み合わせ４＜組み合わせ１＜組み合わせ３となる。
（４）フラグメント→リスク
フラグメント演算の結果より、（２）が得られており、例えば、組み合わせ１と組み合わせ２とが同順位であるが、リスク演算からリスクパラメータ平均aveで比較すると設定した場合は、組み合わせ１＜組み合わせ２＜組み合わせ４＜組み合わせ３となる。ただし、リスクパラメータ分散varで比較する場合は、組み合わせ２＜組み合わせ１＜組み合わせ４＜組み合わせ３となる。【００９７】
このようにして、各ポリシー情報に基づいたコンポーネントの組み合わせの順位を結果として出力する。【００９８】
尚、上記説明では、コンポーネントを、シェルフのスロットに格納される単一の機能を持つ一つの物理的資源として説明したが、図３４に示すように、複数の資源を一つのコンポーネントとして仮想化し、この仮想化されたコンポーネントによりサービスユニットを構成しても良い。この場合、仮想化されたコンポーネントと、このコンポーネントを構成する物理資源との関係を記載したデータベースを用意する。そして、コンポーネントの組み合わせのリスク情報及びフラグメント情報は、前記データベースに基づいて、各コンポーネントを構成する実際の物理資源を元に上述と同様な方法で算出する。【００９９】
以下に、上述した本発明の実施の形態を具体的なものにした実施例を説明する。
【実施例１】
【０１００】
次に、本発明の具体的な実施例１について図面を参照して詳細に説明する。尚、以下の説明において、サービスで要求されるシステムの具体例として、ノードを例にして説明する。【０１０１】
図１を参照すると、本発明の実施例１は、端末１と、ネットワーク手段２と、ネットワーク手段２に接続されている、管理システム内の管理対象である複数のモジュラー型装置で構成される物理資源４と、ネットワーク２に接続され、管理者が端末１から管理システムに対するサービス設定・変更要求や各種情報取得要求に応じて、現在使用可能な資源を検索し、その中からあらかじめ設定されたポリシーに従ってサービス要求を満たす装置構成設定を検索し、最適な設定を行い、また必要な情報を送信するコントローラ３から構成される。【０１０２】
以下、端末１の構成および機能について詳細に説明する。【０１０３】
端末１は、管理者が資源情報や各種設定情報取得要求、もしくはサービス設定要求を入力するキーボード、マウス等と、情報を提供する画面等を含む入出力手段１０１と、管理者から入力された各種要求をネットワーク手段２を経由してコントローラ３に送信し、またコントローラ３から送信された情報を受信する通信手段１０２とから構成されている。【０１０４】
次に、物理資源４の構成および機能について詳細に説明する。【０１０５】
物理資源４はある規定のインターフェースを有するモジュラー型資源が共通プラットフォーム上に搭載されており、物理的にはそのプラットフォームを有するシェルフに搭載されたカード状等の形態に代表されるモジュラー型ユニット物理資源（以後ユニット物理資源）の集合である。ただし、シェルフはひとつではなく、一般に複数のユニット物理資源を有する複数のシェルフで構成される。【０１０６】
また、各ユニット物理資源もしくはシェルフには物理情報を管理するローカル管理手段４０１を有し、ネットワーク手段２を通してコントローラ３と相互に通信することが可能である。例えば、管理している物理資源の障害発生などのアラームをコントローラ３に通知したり、コントローラ３からの現在の状態の情報の要求を受信し、答えを送信したりすることなどができる。【０１０７】
次に、コントローラ３の構成および機能について詳細に説明する。【０１０８】
端末１から送信される管理システムに対する仮想装置およびその冗長構成指定といったサービス設定・変更要求である後述する管理者サービス要求情報２７００や、その他の管理情報取得要求を受信し、演算・設定された要求に対する結果や管理者への必要な通知を端末１に送信する通信手段３０１と、サービス要求を設定する上での動作の後述するポリシー情報２１００を保持するデータベース３１１と、それを管理するアドミニストレータ３０３と、物理資源４の性能、種類、物理位置情報、状態などの物理資源管理のための物理資源空間情報群２２００を保持するデータベース３０９と、そのデータベース３０９の情報を管理し、物理資源４の情報を定期的に更新しながら管理し、情報問い合わせに対して返答したり、情報に変化があった時に情報を更新し、通知する物理資源管理手段３０８と、物理資源４の設定や配置を論理的に仮想化した仮想化資源の情報である仮想資源情報、およびその性能、種類、状態、物理資源空間情報２２００との対応関係や仮想サービスグループ空間情報２４００との対応関係などの仮想資源管理のための仮想資源空間情報２３００を保持するデータベース３０７と、データベース３０７の情報を管理し、情報問い合わせに対して返答したり、情報に変化があった時に情報を更新し、通知する仮想資源管理手段３０６と、上記の仮想資源から設定した仮想サービスグループ情報２４００を保持するデータベース３０５と、データベース３０５の情報を管理し、情報問い合わせに対して返答したり、情報に変化があった時に情報を更新し、通知する仮想サービスグループ管理手段３０４と、端末１からの要求に対して、最適な仮想ノード情報を作成するために必要なリスク演算をおこなうリスク演算手段３１２−１と、フラグメント演算を行うフラグメント演算手段３１２−２と、上記のネットワーク手段２を通して前記の物理資源４と情報の通信を行う通信手段３１０と、上記の端末１からの要求に対して、最適な手順で必要な処理を行うようにコントローラ３の処理を管理する中央制御手段３０２とを有する。【０１０９】
なお、コントローラ３内の全ての手段が必ずしも同一装置内に存在しなくてもよく、例えば、物理資源管理手段３０８やデータベース３０９を別装置上に配置し、ネットワーク手段２を通して、物理資源管理手段３０８やデータベース３０９にアクセスするように構成してもよいし、その他、手段を別装置上に配置してネットワーク手段２を通してアクセスする構成にしてもよい。【０１１０】
また、端末１が通信手段３０１に各種要求を送信する際は、telnetやHTTP、SMTP、SOAPといった各種標準プロトコルを利用してもよい。【０１１１】
ここで、ポリシー空間情報２１００とは、図２に示される如く、本発明を用いる際のポリシーの情報であり、ポリシー空間情報２１００の全体的情報であるポリシー空間全体情報２１０１と、個々に設定・保存したポリシー情報の詳細情報をもつポリシー情報２１０２とで構成され、管理者が端末１を通して入力する情報である。【０１１２】
以下に、図２に示されるポリシー空間情報２１００の各情報について説明する。【０１１３】
ポリシー空間全体情報２１０１はポリシー空間情報の全体的情報を保持し、設定更新日時と管理システム内のポリシー数を保持する。設定更新日時は情報の変更があると更新される。ここで、前記ポリシー空間情報２１００にはポリシー数だけ詳細ポリシー情報２１０３が存在する。【０１１４】
詳細ポリシー情報２１０３は、ポリシーＩＤと優先演算と分割数とフラグメント上限を有する。ポリシーＩＤは当該ポリシー情報内で一意に決まる数字、記号などにより表記される。優先演算は、リスク演算を優先するかフラグメント演算を優先するかを記述する。分割数はリスク演算、もしくはフラグメント演算に用いる情報で、演算された結果を区間毎に分割する際の分割数である。フラグメント上限はフラグメントとして許容する上限を示し、例えば何個のシェルフにまたがって仮想サービスユニットを形成するかの上限などを規定する。【０１１５】
物理資源空間情報２２００とは、図３に示される如く、本発明によって管理される物理資源４の各種情報であり、物理資源空間情報２２００の全体的情報である物理資源空間全体情報２２０１と、管理している物理資源情報の詳細情報を保持する物理資源情報２２０２とで構成される。【０１１６】
以下に、図３に示される物理資源空間情報２２００の各情報について説明する。【０１１７】
物理資源空間全体情報２２０１は、更新日時と管理システム内の全シェルフ数とそのシェルフＩＤ情報である構成メンバーＩＤを保持する。更新日時は情報の変更があると更新される。【０１１８】
物理資源情報２２０２は全シェルフ数だけシェルフ情報２２０３が存在する。【０１１９】
シェルフ情報２２０３はシェルフ全体情報２２０４とユニット物理資源空間情報２２０５で構成される。シェルフ全体情報２２０４はシェルフ全体的情報であり、シェルフＩＤと総スロット数と資源数と構成メンバーＩＤと状態と故障率で構成される。シェルフＩＤは数字、記号などを用いて物理資源情報２２０３内で一意にきまるＩＤをふることとする。総スロット数は搭載可能な総スロット数であり、資源数は現在搭載されているユニット物理資源数である。構成メンバーＩＤは搭載されているユニット物理資源のＩＤである。状態は電源、ファンなどのシェルフ全体の稼動状態である。故障率は当該シェルフの故障率である。【０１２０】
ユニット物理資源情報２２０５は、ユニット物理資源ＩＤとユニット物理資源パスと種類と性能と状態と参照仮想資源ＩＤと故障率で構成される詳細ユニット物理資源情報２２０６で構成される。【０１２１】
ユニット物理資源ＩＤは数字、記号などを用いて属するシェルフ内で一意にきまるようにＩＤであり、たとえばスロット番号をもちいてＩＤをふるなどで記述される。例えばスロット３に搭載されたユニット物理資源はＢ３などとなる。ここで記号Ｂはユニット物理資源であることを示すために付け加えた。またユニット物理資源パスはシェルフＩＤと物理資源ＩＤを組み合わせて決定し、各ユニット物理資源が管理システム内で一意に決まるようにし、またそのＩＤの表記からそのユニット物理資源がどのシェルフのどのスロットに属するかがわかるようにパスを振る。たとえばシェルフＩＤがＳｈ３でそのスロット番号３に搭載されたユニット物理資源パスはＳｈ３Ｂ３などとなる。ここで記号Ｓｈはシェルフを示す記号として付け加えた。種類、性能は当該ユニット物理資源の種類および性能情報であり、状態は稼動状態情報で正常時のupと異常時のdownなどである。参照仮想資源ＩＤは当該ユニット物理資源が関連する仮想資源ＩＤである。ここで各故障率は、管理者が直接入力して設定してもよいし、統計的情報から学習したデータを自動的に取得、入力してもよい。プロテクトとは、ユニット物理資源が他システムで既に利用されており、他システムとの共用を許可するか、しないかを示す情報である。プロテクトがＯＮの場合には他のシステムで既に使用されており、共用を許可しない。また、プロテクトがＯＦＦの場合には、他のシステムで未使用又は共用を許可している場合であり、資源としての利用が可能である。【０１２２】
仮想資源空間情報２３００とは、図４に示される如く、本発明によって管理する仮想資源の各種情報であり、仮想資源空間情報２３００の全体的情報である仮想資源空間全体情報２３０１と、管理している仮想資源情報の詳細情報を保持する仮想資源情報２３０２と、で構成される。尚、仮想資源情報２３０２は物理資源空間情報２２００を元に管理者によって設定された情報である。【０１２３】
以下に、図４に示される仮想資源空間情報２３００の各情報について説明する。【０１２４】
仮想資源空間全体情報２３０１は前記仮想資源空間情報２３００の全体的情報であり、更新日時と管理システム内の全仮想資源数と構成する仮想資源のＩＤを保持する。更新日時は情報の変更があると更新される。
仮想資源情報２３０２は現在管理している仮想資源の詳細情報を保持する詳細仮想資源情報２３０３で構成され、前記仮想資源情報２３０２には前記仮想資源数だけ詳細仮想資源情報２３０３が存在する。【０１２５】
詳細仮想資源情報２３０３は仮想資源ＩＤと種類と性能と稼動状態と参照仮想サービスグループＩＤと参照仮想ノードＩＤと参照仮想サービスユニットＩＤと参照仮想コンポーネントIDと参照冗長資源メンバーIDと仮想資源パスで構成される。【０１２６】
仮想資源ＩＤは全仮想資源内で一意に決まるよう数字、記号などを用いてＩＤをふることとし、例えばＶ１などとする。ＩＤは通し番号で１〜全仮想資源数までで振ってもよい。種類、性能はその仮想資源の種類、性能情報であり、状態は仮想資源の稼動状態であり、正常ならup、障害などの異常時はdownであらわす。参照仮想サービスグループＩＤと参照仮想ノードＩＤと参照仮想サービスユニットＩＤと参照仮想コンポーネントIDと参照冗長資源メンバーIDはそれぞれ当該仮想資源が関連する仮想サービスグループ空間情報２４００に記載の仮想サービスグループＩＤと仮想ノードＩＤと仮想サービスユニットＩＤと仮想コンポーネントIDと冗長資源メンバーIDである。複数ある場合は全て列挙する。仮想資源パスは関連のあるユニット物理資源のユニット物理資源パスを用いて作成する。例えば、仮想資源ＩＤがＶ１のある仮想資源がそれぞれユニット物理資源パスSh1B2とSh1B4を有するユニット物理資源で構成されていた場合、その仮想資源パスはV1＠Sh1B2＿Sh1B4などとなる。プロテクトとは、仮想資源が他システムで既に利用されており、他システムとの共用を許可するか、しないかを示す情報である。プロテクトがＯＮの場合には他のシステムで既に使用されており、共用を許可しない。また、プロテクトがＯＦＦの場合には、他のシステムで未使用又は共用を許可している場合であり、仮想資源としての利用が可能である。【０１２７】
仮想サービスグループ空間情報２４００は、図５に示す如く、本発明によって管理者サービス要求に対して、最適な設定探索演算を行い割り当てられた設定結果の情報であり、仮想サービスグループ空間情報２４００の全体的情報である仮想サービスグループ空間全体情報２４０１と、サービス要求に対する設定事項の詳細が保持される仮想サービスグループ情報２４０２とで構成される。【０１２８】
以下に、図５に示される仮想サービスグループ空間情報２４００の各情報について説明する。【０１２９】
仮想サービスグループ空間全体情報２４０１は、前記仮想サービスグループ空間情報２４００の全体的情報であり、設定更新日時と管理システム内の全サービスグループ数を保持する。設定更新日時は情報の変更があると更新される。【０１３０】
ここで前記仮想サービスグループ空間情報２４００には仮想サービスグループ数だけ仮想サービスグループ情報２４０２が存在する。仮想サービスグループ情報２４０２は現在管理している仮想サービスグループの全体的情報を保持する仮想サービスグループ全体情報２４０３と仮想ノード情報２４０４で構成され、仮想ノード情報２４０４は当該仮想サービスグループに存在する仮想ノードの数だけ存在する。【０１３１】
仮想サービスグループ全体情報２４０３は仮想サービスグループ情報２４０２の全体的情報であり、設定更新日時と仮想サービスグループＩＤと参照サービスグループＩＤと参照サービスグループ名と仮想サービスグループの状態と仮想サービスユニット数と仮想サービスユニット構成メンバーＩＤと仮想ノード数と仮想ノード構成メンバーＩＤと優先度で構成される。【０１３２】
設定更新日時はその仮想サービスグループに更新があったときに更新される。仮想サービスグループＩＤは管理システム内で一意に決まるように記号、数字などをもちいてＩＤが振られる。【０１３３】
参照サービスグループＩＤは管理者サービス要求情報２１００などに記載されることによって管理者により指定され、当該ＩＤによって管理者の要求サービスを特定するものである。【０１３４】
参照サービスグループ名は管理者サービス要求情報２１００などに記載されることによって管理者により指定される。【０１３５】
状態は仮想サービスグループの稼動状態を表し、当該仮想サービスグループ内の全ての仮想ノードおよび仮想サービスユニットの状態がupの時はup、一つ以上downやalarmがあり、かつ少なくとも一つの仮想サービスユニットがサービスを提供可能でupの時はalarm、全ての仮想サービスユニットがdownで当該仮想サービスグループ内でサービスを提供できる仮想サービスユニットが存在しない時はdownとなる。【０１３６】
仮想サービスユニット数は当該仮想サービスグループに属する全ての仮想サービスユニットの総数であり、仮想サービスユニット構成メンバーＩＤは当該仮想サービスグループに所属する全ての仮想サービスユニットのＩＤである。【０１３７】
仮想ノード数は当該仮想サービスグループに属する全ての仮想ノードの総数であり、ノード構成メンバーＩＤは当該仮想サービスグループに所属する全ての仮想ノードのＩＤである。【０１３８】
優先度は管理者サービス要求情報２１００などに記載されることによって管理者により当該サービスグループに割り当てられた優先度であり、たとえば１〜５の間の整数値を割り当て、数字の大きいほど優先度が高い、などとする。【０１３９】
仮想ノード情報２４０４は仮想ノード全体情報２４０５と仮想コンポーネント情報２４０８と仮想サービスユニット情報２４０６で構成される。【０１４０】
仮想ノード全体情報２４０５は仮想ノードＩＤと参照ノードIDと属性と当該仮想ノードに属する仮想サービスユニットの数である仮想サービスユニット数と、仮想サービスユニット構成メンバーＩＤと仮想ノードの稼動状態をしめす状態とで構成される。【０１４１】
仮想ノードＩＤは当該仮想サービスグループ空間内に属する仮想ノード全ての中で一意に決まるＩＤが数字、記号などを用いて振られる。たとえば仮想サービスグループＩＤがＶＳＧ１のサービスグループに属するひとつの仮想ノードはＶＳＧ１ＶＮ１などのように表記される。【０１４２】
参照ノードＩＤは管理者サービス要求情報２１００などに記載されることによって管理者により指定され、当該ＩＤによって管理者の要求ノードを特定するものである。【０１４３】
仮想サービスユニット数は当該仮想ノードに属する全ての仮想サービスユニットの総数であり、仮想サービスユニット構成メンバーＩＤは当該仮想ノードに属する全ての仮想サービスユニットのＩＤである。【０１４４】
状態は仮想ノードの稼動状態を表し、up、downのみを持ち、当該仮想ノードに属する全ての仮想サービスユニットがdownのときにdownとする。【０１４５】
仮想サービスユニット情報２４０６は仮想サービスユニット全体情報２４０７と仮想コンポーネント情報２４０８で構成され、仮想コンポーネント情報２４０８は当該仮想サービスユニットに属する仮想コンポーネントの数だけ存在する。【０１４６】
仮想サービスユニット全体情報２４０７は、仮想サービスユニットＩＤと、参照サービスユニットＩＤと、仮想コンポーネント数と、仮想コンポーネント構成メンバーＩＤと、仮想サービスユニットの稼動状態と、プロテクトの情報とを表す状態で構成される。【０１４７】
仮想サービスユニットＩＤは当該仮想サービスグループ空間内に属する仮想サービスユニット全ての中で一意に決まるＩＤが数字、記号などを用いて振られる。たとえば仮想サービスグループＩＤがＶＳＧ１のサービスグループに属し、ＶＮ１の仮想ノードに属するひとつの仮想サービスユニットはＶＳＧ１ＶＮ１などのように表記される。【０１４８】
参照サービスユニットＩＤは、管理者サービス要求情報２１００などに記載されることによって管理者により指定され、当該ＩＤによって管理者の要求サービスユニットを特定するものである。【０１４９】
仮想コンポーネント数は、当該仮想サービスユニットに属する仮想コンポーネントの総数であり、仮想コンポーネント構成メンバーＩＤは当該仮想サービスユニットに属する全ての仮想コンポーネントのＩＤである。【０１５０】
状態は当該仮想サービスユニットの稼動状態を表し、up、alarm、downの三種類をもつ。Upは正常状態、alarmは当該仮想サービスユニットに属する仮想コンポーネントの状態が一つ以上alarmになった場合で、downは一つ以上downになった場合である。【０１５１】
プロテクトとは、仮想サービスユニットが他システムとの共用を許可するか、しないかを示す情報である。プロテクトがＯＮの場合には共用を許可しない。また、プロテクトがＯＦＦの場合には、共用を許可している場合である。【０１５２】
仮想コンポーネント情報２４０８は仮想コンポーネント全体情報２４０９と冗長資源メンバー情報２４１０で構成され、冗長資源メンバー情報２４１０は当該仮想コンポーネントに属する冗長資源メンバーの数だけ存在する。【０１５３】
仮想コンポーネント全体情報２４０９は、仮想コンポーネントＩＤと、参照コンポーネントＩＤと、仮想コンポーネントの稼動状態を表す状態と、設定資源メンバー数と、設定資源メンバーＩＤと、冗長資源メンバー数と、冗長資源メンバーＩＤとで構成される。【０１５４】
仮想コンポーネントＩＤは当該仮想サービスグループ空間内に属する仮想コンポーネント全ての中で一意に決まるＩＤが数字、記号などを用いて振られる。たとえばＶＳＧ１の仮想サービスグループに属し、ＶＮ１の仮想ノードに属するひとつの仮想コンポーネントはＶＳＧ１ＶＮ１ＶＣ１などのように表記される。
参照コンポーネントＩＤは管理者サービス要求情報２１００などに記載されることによって管理者により指定され、当該ＩＤによって管理者の要求コンポーネントを特定するものである。【０１５５】
設定資源メンバーＩＤは冗長資源メンバーの中で、現在アクティブ設定になっている冗長資源メンバーのＩＤであり、設定資源メンバー数はその総数である。【０１５６】
冗長資源メンバー数は当該仮想コンポーネントに属する全ての冗長資源メンバーの総数であり、冗長資源メンバーＩＤは当該仮想コンポーネントに属する全ての冗長資源メンバーのＩＤである。【０１５７】
状態は当該仮想コンポーネントの稼動状態をあらわし、up、alarm、downの三つの状態をもつ。当該仮想コンポーネントに属する冗長資源メンバーのうち、すべてが正常であった場合はup、ひとつ以上downになるが、設定資源メンバー数だけactiveでかつ状態が正常な冗長資源メンバーがいる時はalarm、設定資源メンバー数だけactiveでかつ状態が正常な冗長資源メンバーが存在しない時はdownとなる。【０１５８】
冗長資源メンバー情報２４１０は冗長資源メンバー詳細情報２４１１で構成され、冗長資源メンバー詳細情報２４１１は当該冗長資源メンバー情報に属する冗長資源メンバーの数だけ存在する。【０１５９】
冗長資源メンバー詳細情報２４１１は、ＩＤと仮想資源ＩＤとact/stdと冗長資源メンバーの稼動状態を表す状態と冗長グループを組む冗長資源メンバーを示すバディＩＤとを有する。【０１６０】
ＩＤは当該仮想コンポーネント内で一意に決まるＩＤが数字、記号などを用いて振られる。たとえば仮想コンポーネントＩＤがＶＳＧ１ＶＮ１ＶＣ１の場合、当該ＩＤはＶＳＧ１ＶＮ１ＶＣ１Ｍ１などのように表記される。【０１６１】
仮想資源ＩＤは当該冗長資源メンバーと関連付けられている仮想資源ＩＤであり、複数の仮想資源と関連付けられている場合はすべての関連仮想資源ＩＤを列挙する。【０１６２】
act/stdは当該冗長資源メンバーがacitveなのかstandbyなのかを指定する。【０１６３】
バディＩＤは冗長グループに組む冗長資源メンバーのＩＤを示し、act/stdがactiveの場合はstandbyに指定されている冗長資源メンバーＩＤを、standbyの場合はactiveに指定されている冗長資源メンバーＩＤを示す。なお複数ある場合はすべて列挙する。【０１６４】
利用可能仮想資源空間情報２５００は、図６に示される如く、管理者サービス要求に対して、要求を満たす利用可能な仮想資源の候補およびその詳細情報の集合およびシェルフ故障率などの演算に必要な情報であり、利用可能仮想資源空間情報２５００の全体的情報である利用可能仮想資源空間全体情報２５０１と、利用可能仮想資源の集合である利用可能仮想資源空間情報２５０２と、前記利用可能仮想資源と関連するシェルフの情報である関連シェルフ情報２５０３とで構成される。【０１６５】
以下に、図６に示される利用可能仮想資源空間情報２５００の各情報について説明する。【０１６６】
利用可能仮想資源情報全体情報２５０１は、設定更新日時と管理システム内の利用可能仮想資源情報数と利用可能構成メンバーＩＤと関連シェルフ数と関連シェルフＩＤとを保持する。設定更新日時は情報の変更があると更新される。【０１６７】
ここで、利用可能仮想資源空間情報２５００には利用可能仮想資源情報数だけ詳細利用可能仮想情報２５０４が存在し、関連シェルフ数だけ詳細関連シェルフ情報２５０５が存在する。【０１６８】
利用可能構成メンバーＩＤは現在利用可能な仮想資源ＩＤを利用可能仮想資源情報数だけ列挙したものである。関連シェルフＩＤは現在利用可能な仮想資源ＩＤが関連するシェルフＩＤを関連シェルフ数だけ列挙したものである。【０１６９】
利用可能仮想空間情報２５０２は利用可能仮想資源情報２５０４から構成され、利用可能仮想資源情報２５０４は仮想資源空間情報２３００における仮想資源情報の中で管理者サービス要求２７００に記載されるなどして指定された資源種類、性能などの要求を満たす現在利用可能な資源である。【０１７０】
関連シェルフ情報２５０３は詳細関連シェルフ情報２５０５から構成され、利用可能仮想資源が関連するシェルフについての詳細情報を有する。【０１７１】
各詳細関連シェルフ情報２５０５はシェルフＩＤとその故障率から構成され、故障率は物理資源空間情報２２００のシェルフ情報２２０２から取得する。【０１７２】
尚、本発明では、利用可能仮想資源空間情報２５００は、後述するように管理者よりサービスの要求毎に作成するように構成している。しかし、利用可能仮想資源空間情報２５００をデータベース化して利用可能な仮想資源が変動する毎に更新するように構成し、管理者よりサービスの要求があった場合、利用可能仮想資源空間情報２５００を参照するようにしても良い。【０１７３】
仮想サービスグループ探索空間情報２６００とは、図７に示される如く、本発明によって利用可能仮想資源空間情報から管理者サービス要求を満たす仮想サービス空間の候補の情報であり、仮想サービスグループ探索空間情報２６００の全体的情報である仮想サービスグループ探索空間全体情報２６０１と、管理者サービス要求にある条件を満たす仮想サービスグループの候補の集合の情報である仮想サービスグループ情報２６０２とで構成される。【０１７４】
以下に、図７に示される仮想サービスグループ探索空間情報２６００の各情報について説明する。【０１７５】
仮想サービスグループ探索空間全体情報２６０１は更新日時と候補数と候補IDで構成される。更新日時は情報の変更があると更新される。候補数は候補空間情報２６０２に属する候補２６０３の数であり、候補IDは当該候補２６０３のＩＤである。【０１７６】
候補空間情報２６０２は候補情報２６０３の集合で構成される。【０１７７】
候補情報２６０３は前記利用可能仮想資源空間情報２５００の利用可能仮想資源をもちいて構成される、管理者サービス要求２７００に記載されるなどして要求される設定サービスグループ空間を満たす、仮想サービスグループの設定候補情報であり、仮想サービスグループ空間情報２４００と同様のフォーマットを有する。【０１７８】
管理者サービス要求情報２７００は、図８に示す如く、本発明によって管理者が行いたいサービス設定の要求の情報であり、管理者サービス要求情報２７００の全体的情報である管理者サービス要求全体情報２７０１と、管理者が設定したいサービスグループの詳細情報であるサービスグループ情報２７０２とで構成される。【０１７９】
また、サービスグループ情報２７０２は、当該サービスグループ内で使用するノードの情報であるノード情報２７０４と、前記ノードを構成する仮想資源の情報であるコンポーネント情報２７０８と、当該サービスグループに割り当てあてられるサービスユニットとその冗長構成などの情報を有するサービスユニット情報２７０６とで構成される。【０１８０】
以下に、図８に示される管理者サービス要求情報２７００の各情報について説明する。【０１８１】
管理者サービス要求情報２７００は管理者の設定要求を記載した情報である。【０１８２】
管理者サービス要求情報２７００は管理者サービス要求全体情報２７０１とサービスグループ情報２７０２の集合から構成され、サービスグループ情報２７０２はサービスグループ全体情報２７０３とノード情報２７０４の集合から構成され、ノード情報２７０４はノード全体情報２７０５とコンポーネント情報２７０８とサービスユニット情報２７０６から構成される。【０１８３】
サービスユニット情報２７０６は詳細サービスユニット情報２７０７の集合で構成され、コンポーネント情報２７０８はコンポーネント詳細情報２７０９の集合で構成される。【０１８４】
全体情報２７０１はサービスグループ数と参照ポリシーＩＤからなり、管理者サービス要求情報２７００に存在するサービスグループ情報の数を表し、参照ポリシーＩＤは設定の上でのポリシーをポリシー空間情報２１００から参照するためのＩＤである。【０１８５】
サービスグループ全体情報２７０３はサービスグループID、サービスグループ名、サービスユニット数、ノード数、優先度で構成され、サービスグループIDは数字、記号などを用いた管理者サービス要求情報２７００内で一意に決まるＩＤであり、サービスグループ名は当該サービスグループに割り当てる名前であり、サービスユニット数は当該サービスグループに属するサービスユニットの数であり、ノード数は当該サービスグループに属するノードの数であり、優先度は当該サービスグループに割り当てられた優先度であり、たとえば１〜５の間の整数値を割り当て、数字の大きいほど優先度が高い、などとする。【０１８６】
ノード全体情報２７０５はノードID、属性、コンポーネント数、サービスユニット数で構成され、ノードIDは数字、記号などを用いた管理者サービス要求情報２７００内で一意に決まるＩＤであり、属性はノードの種類、性能などであり、コンポーネント数は当該ノードを構成するコンポーネントの数であり、サービスユニット数は当該ノードに属するサービスユニットの数である。【０１８７】
サービス全体情報２７０７は、サービスユニットIDと、Act/stdと、バディIDと、プロテクトとで構成される。サービスユニットIDは数字、記号などを用いた管理者サービス要求情報２７００内で一意に決まるＩＤである。act/stdは、当該サービスユニットが割り当てられた状態であり、activeとstandbyをもつ。バディＩＤは当該サービスユニットのact/stdがactiveの場合は当該サービスユニットのstandbyとして冗長構成をとる他のサービスユニットのＩＤであり、複数ある場合は全て列挙する。プロテクトとは、サービスで要求されたシステム（ノード）を構成するサービスユニットに対して、他のシステムとの共有を許可するか、許可しないかの情報である。【０１８８】
コンポーネント詳細情報２７０９はコンポーネントID、属性、Act/std、バディＩＤ、active資源メンバー数、standby資源メンバー数で構成され、コンポーネントIDは数字、記号などを用いた管理者サービス要求情報２７００内で一意に決まるＩＤであり、属性は当該コンポーネントを形成する資源の要求資源種類や要求性能であり、Act/stdは当該コンポーネントが割り当てられた状態であり、activeとstandbyをもち、バディＩＤは当該コンポーネントのact/stdがactiveの場合は当該コンポーネントのstandbyとして冗長構成をとる他のコンポーネントのＩＤであり、複数ある場合は全て列挙する。【０１８９】
active資源メンバー数は当該コンポーネントを形成する冗長資源メンバーのうちactiveになるものの数で、standby資源メンバー数はstandbyになるものの数であり、コンポーネント内の仮想資源間での冗長構成を規定する。ここで、詳細な冗長構成ポリシーを記述することも可能である。例えば他のコンポーネントで使われる冗長資源メンバーと仮想資源を共有するかどうかを記述する、などである。【０１９０】
次に、ＩＤ情報Ｉ７００について詳細に説明する。【０１９１】
ＩＤ情報Ｉ７００はある特定の仮想資源から関連するユニット物理資源、仮想サービスグループ、仮想ノード、仮想サービスユニット、仮想コンポーネント、冗長資源メンバーがわかる情報を有する。例えば、図１７に記載の仮想資源ＩＤユニット物理資源ＩＤ、仮想サービスグループＩＤ、仮想ノードＩＤ、仮想サービスユニットＩＤ、仮想コンポーネントＩＤ、冗長資源メンバーＩＤから構成される。【０１９２】
次に、図９のフローチャートを参照して、実施１のサービス要求から設定完了通知までを管理者確認なしに自律的に行う場合の本発明ソフトウェアの全体動作フローについて詳細に説明する。
（ステップＳ１０１）
まず、管理者は端末１の前記入出力手段１０１から前記管理者サービス要求情報２７００を入力し、その情報は通信手段１０２からネットワーク手段２を通して送信される。
（ステップＳ１０２）
次に通信手段３０１は前記要求情報を受けつけ、前記中央制御手段３０２に送る。
（ステップＳ１０３）
次に中央制御手段３０２が要求情報２７００に記載のポリシーＩＤを元にアドミニストレータ３０３に関連ポリシー情報を問い合わせる。アドミニストレータ３０３は前記ポリシーＩＤからポリシー情報２１００に記載のポリシー情報を中央制御手段３０２に返す。
（ステップＳ１０４）
中央制御手段３０２が仮想資源管理手段３０６にサービス要求を満たすのに必要な性能、種類を有する利用可能な仮想資源を仮想資源空間情報2300に問い合わせる。
（ステップＳ１０５）
仮想資源管理手段３０６は中央制御手段３０２から受け付けたサービス要求を満たすための構成資源情報から利用可能な仮想資源情報を検索し、一つ以上の利用可能構成メンバーをもつ使用可能仮想資源空間情報２５００が作成できた場合、それを中央制御手段３０２に返す。一方、前記ステップ１０５において一つも条件を満たす使用可能仮想資源空間情報２５００が作成できなかった場合は管理者にその結果を通知し終了する。
（ステップＳ１０６）
中央制御手段３０２が、利用可能仮想資源空間情報２５００に記載の仮想資源を用いた可能な全ての設定組み合わせの中から、ポリシー情報に記載のフラグメント上限を満たし、サービス要求情報２７００に記載のサービスユニット、コンポーネント、冗長資源メンバー、ノードで構成されるサービスグループを構成可能な仮想資源設定である仮想サービスグループ候補２６０４の集合で構成される仮想サービスグループ探索空間情報２６００を作成し、最適仮想サービスグループ空間演算のための演算フローＦ１０００を呼び出す。
（ステップＳ１０７）
中央制御手段３０２は演算フローＦ１０００に従い、ポリシー情報に記載の優先演算、分割数から、適切な演算手段３１２−１および３１２−２を呼び出し、演算を実行し解として最適仮想サービスグループ空間を求める。
（ステップＳ１０８）
前記のステップＳ１０７において解が存在した場合、中央制御手段３０２は仮想サービスグループ管理手段３０４および仮想資源管理手段３０６に解を通知する。一方、解が存在しなかった場合、管理者に通知して終了する。
（ステップＳ１０９）
仮想サービスグループ管理手段３０４はその解からデータベース３０５上の仮想サービスグループ空間情報２４００を更新して、更新終了を中央制御部３０２に通知する。同様に仮想資源管理手段３０６はデータベース３０７上の仮想資源空間情報２３００を更新して、更新終了を中央制御部３０２に通知する。
（ステップＳ１１０）
中央制御手段３０２は通信手段３０１、ネットワーク手段２を通して端末１に処理完了および設定情報を通知し終了する。【０１９３】
次に、図１０のフローチャートを参照して、本実施の形態における仮想サービスグループの設定において特に管理者に確認を含む場合の動作について詳細に説明する。
（ステップＳ２０１）
前記のステップＳ１０１〜Ｓ１０６と同様である。
（ステップＳ２０２）
中央制御手段３０２は演算フローＦ１０００に従い、ポリシー情報に記載の優先演算、分割数から、適切な演算手段３１２−１および３１２−２を呼び出し、演算を実行し解として最適仮想サービスグループ空間を求める。
（ステップＳ２０３）
前記の解が存在する場合、中央制御手段３０２は通信手段３０１、およびネットワーク手段２を通して端末１にその解を送信し、管理者に確認する。一方、解が一つも存在しなかった場合、管理者に通知して終了する。
（ステップＳ２０４）
管理者が前記の解に対して承認しなかった場合、仮想サービスグループ探索空間２７００の中からその解をのぞき、Ｓ２０２に戻り同じ演算を繰り返す。一方管理者が承認した場合、ステップＳ２０５に進む。
（ステップＳ２０５）
中央制御手段３０２は仮想サービスグループ管理手段３０４および仮想資源管理手段３０６に解を通知する。
（ステップＳ２０６）
前記ステップＳ１０９〜Ｓ１１０と同様な動作を行う。【０１９４】
次に、図１１のフローチャートを参照して、仮想サービスグループ候補空間２６００の中から最適な候補を解として演算する演算フローＦ１０００を詳細に説明する。
（ステップＳ１００１）
仮想サービスグループ探索空間情報２６００に候補数が二つ以上ある場合はステップＳ１００２へ。ない場合はステップＳ１３０１へ進む。
（ステップＳ１００２）
ポリシー情報２１００に記載の優先演算情報をチェックする。リスク演算優先の場合はステップＳ１１０１へ、フラグメント演算優先の場合はＳ１２０１へ進む。
（ステップＳ１１０１）
リスク演算手段３１２−１に仮想サービスグループ探索空間情報２６００および分割数を渡し、処理を依頼する。
（ステップＳ１１０２）
リスク演算手段３１２−１は探索範囲の候補をリスク演算フローＦ２０００に従ってリスクの低い順にソートし、リスク別リストＬ１００を作成し、ステップＳ１００３へ進む。
（ステップＳ１２０１）
フラグメント演算手段３１２−２に仮想サービスグループ探索空間情報２６００および分割数を渡し、処理を依頼する。
（ステップＳ１２０２）
フラグメント演算手段３１２−２は探索範囲の候補をフラグメント演算フローＦ３０００に従ってフラグメントの低い順にソートし、フラグメント別リストＬ２００を作成する。
（ステップＳ１００３）
リストL１００もしくはリストＬ２００もしくはリストＬ３００の最上位に位置するものを解として決定する。
（ステップＳ１３０１）
解がひとつは有る場合はその解のみを記述したリストＬ３００を作成しステップＳ１００３へ、一つもない場合はステップＳ１３０２へすすむ。
（ステップＳ１３０２）
エラー通知して演算を終了する。【０１９５】
次に、リスク演算においてリスクを定量化するリスクパラメータ平均および分散の求め方について図１２を参照して詳細に説明する。【０１９６】
本発明におけるリスク管理は、リスク共有体に障害が発生したときに、そこに割り当てられていたアクティブなサービスユニットが切り替えられる数をなるべく少なくすることを目的にしている。また、同時にどれか一つのリスク共有体にアクティブなサービスユニットの数が偏らないことも目的としている。【０１９７】
図１２は、ある複数のサービスグループの割り当て要求があり、各サービスグループは冗長構成が規定されており、それらの要求を満たすようにサービスグループ、およびそのサービスユニットをシェルフ２００３−１〜２００３−ｎに割り当てた一例の図である。ここでシェルフ２００３−１〜２００３−ｎは何らかの資源が供給される物理的資源の集まりをあらわす論理的エンティティといったリスク共有体を示し、その上に定義されたサービスユニットはシェルフ内の資源の集合である装置や装置内の論理的エンティティである。当該リスクパラメータはこの割り当てられた状態のリスクを定量的に演算するためのパラメータである。【０１９８】
まず、シェルフ２００３−ｉ上のサービスユニット２００２−jの状態を変数σvで記述し、その値をactiveなら１、standbyなら0とする。また、そのサービスの優先度としてサービス設定情報２７００に記載の優先度を用い、その変数をｗvとする。ここで、ｗvは値が大きいほど優先度が高い。【０１９９】
次にシェルフ２００３−iにおける共有リスクｘiをσv x ｗvのシェルフ２００３−i全体での和と定義する。これはシェルフ２００３−i上にあるアクティブなサービスユニットに優先度の重みを掛けたものの和である。【０２００】
次に、シェルフ２００３−iの故障率ｐiを定義する。故障率は利用可能仮想資源空間情報２５００に記載のシェルフ故障率を用い、ここで故障率は管理者が任意に設定してもよい。【０２０１】
次にシェルフ２００３−iの共有リスクｘiと故障率ｐiとをかけたものをシェルフ２００３−iのリスクパラメータｙiとし、管理システム全体でのリスクパラメータｙiの平均aveと分散varを求める。【０２０２】
以上の手続きにより、リスクを定量的に定義するリスクパラメータ平均および分散を求めることができる。ここでリスクパラメータ平均はリスクの大きさを、リスクパラメータ分散はノード間でのリスクの偏りを意味し、リスクが小さく、かつ平坦化されているつまりリスクパラメータの平均、分散とも小さいほうが望ましい。【０２０３】
次に、リスク演算における動作である演算フローＦ２０００を図１３のフローチャートを参照して詳細に説明する。
（ステップＳ２００１）
探索空間、分割数を入力する。ここで探索空間は複数のノードおよび複数のサービスユニットをもつ複数のサービスグループが設定されている候補の集合である。
（ステップＳ２００２）
探索空間の中からまだ選ばれてない一つの候補を選ぶ。
（ステップＳ２００３）
その候補のリスクパラメータの平均、分散を求める。
（ステップＳ２００４）
探索空間内にまだ選ばれてない候補が存在する場合、ステップＳ２００２へ進む。【０２０４】
まだ選ばれてない候補が存在しない場合ステップＳ２００５へ進む。
（ステップＳ２００５）
探索空間のリスクパラメータ平均、分散の計算を終了する。
（ステップＳ２００６）
リスクパラメータ平均が小さい順に集合をソートし、分割数だけの区間に分ける。
（ステップＳ２００７）
区間ごとにリスクパラメータ分散が小さい順に集合をソートする。
（ステップＳ２００８）
探索空間をそのリスクパラメータ平均、また定義区間内で分散が小さい順にソートした解のリストを出力して終了する。【０２０５】
上述の演算フローＦ２０００はリスクの順位付けとして、リスクパラメータ平均がある適当な区間内に入る候補はリスクパラメータ平均ではリスクを同等とみなし、その区間の中で、そのリスクパラメータ分散が一番小さいものをリスク最低とした場合のフローである。【０２０６】
ここで、リスクパラメータ平均が最低なものをリスク最低としてもよいし、リスクパラメータ分散が最低なものをリスク最低としてもよい。【０２０７】
次に、フラグメント演算においてフラグメントを定量化するフラグメントパラメータ平均と分散の求め方について図１４を参照して詳細に説明する。【０２０８】
本発明におけるフラグメント管理は、シェルフに搭載されたモジュラー型ユニット資源を利用してあるサービスユニットを形成する際に、そのサービスユニットを構成する資源が一つの物理的シェルフから選択されているか、複数のシェルフから選択されているかを定量化し、なるべくフラグメントが少ないように管理することを目的としている。【０２０９】
図１４は、複数のサービスユニットを有するサービスユニット空間３００２に、ユニット物理資源が割り当てられている状態を示す図である。サービスユニット３００２と物理資源空間３００１の間の結線３００３はコンポーネントを作成するのに使われている物理資源との関係をしめす。【０２１０】
まず、サービスユニット３０００−ｉに関連シェルフ数ｓiとして関連するシェルフの数から１を減じた数を定義する。例えば、サービスユニットを形成するのに全部で３つの異なるシェルフから資源を使った場合、関連シェルフ数は２となる。【０２１１】
そして各サービスユニット３０００−ｉの優先度ｗiはサービス要求情報２７００に記載されるサービスユニットの優先度とする。数が大きいほど優先度が高いとし、たとえば５段階で１〜５までの整数値を割り当てる、などで指定される。【０２１２】
次に、ｓiとｗiとをかけたものをサービスユニット３０００−ｉのフラグメントパラメータｆiと定義する。【０２１３】
このフラグメントパラメータｆi の管理システム全体での平均aveと分散varを求め、フラグメントパラメータ平均および分散とする。【０２１４】
以上の手続きにより、フラグメントを定量的に定義するフラグメントパラメータ平均および分散を求めることができる。ここでフラグメントパラメータ平均は管理システム内のサービスユニット設定におけるフラグメントの大きさを、フラグメントパラメータ分散はフラグメントの偏りを意味し、フラグメントが小さく、かつ平坦化されているつまりフラグメントパラメータの平均、分散とも小さいほうが望ましい。【０２１５】
次にフラグメント演算における演算フローＦ３０００を図１５のフローチャートを参照して詳細に説明する。
（ステップＳ３００１）
探索空間、分割数を入力する。ここで探索空間は複数の物理資源と関連付けされた複数のサービスユニットが設定されている候補の集合である。
（ステップＳ３００２）
探索空間の中からまだ選ばれてない一つの候補を選ぶ。
（ステップＳ３００３）
その候補のフラグメントパラメータの平均および分散を求める。
（ステップＳ３００４）
探索空間内にまだ選ばれてない候補が存在する場合、ステップＳ３００２へ進む。【０２１６】
まだ選ばれてない候補が存在しない場合ステップＳ３００５へ進む。
（ステップＳ３００５）
探索空間のフラグメントパラメータ平均、分散の計算を終了する。
（ステップＳ３００６）
フラグメントパラメータ平均が小さい順に集合をソートし、ポリシー情報２１００に記載の分割数だけの区間に分ける。
（ステップＳ３００７）
区間ごとにフラグメントパラメータ分散が小さい順に集合をソートする。
（ステップＳ３００８）
探索空間をそのフラグメントパラメータ平均、また定義区間内で分散が小さい順にソートした解のリストを出力して終了する。【０２１７】
上述の演算フローＦ３０００はリスクの順位付けとして、フラグメントパラメータ平均がある適当な区間内に入る候補はフラグメントパラメータ平均ではフラグメントを同等とみなし、その区間の中で、そのフラグメントパラメータ分散が一番小さいものをフラグメント最低とした場合のフローである。【０２１８】
ここで、フラグメントパラメータ平均が最低なものをフラグメント最低としてもよいし、フラグメントパラメータ分散が最低なものをフラグメント最低としてもよい。【０２１９】
ここで、リスク演算とフラグメント演算を組み合わせて実行することも可能である。例えば、リスク管理を優先させた場合は、リスク演算によりリスクでソートされたリストＬ１００のうち許容範囲を決定し、その中でフラグメント演算を行い、フラグメント別にソートされたリストＬ２００を作成することで、リスクは一定水準を保ちながらフラグメントを最低にすることが可能である。同様に、フラグメント管理を優先させた場合、フラグメント演算によりフラグメントでソートされたリストＬ２００のうち許容範囲を設定し、その中でリスク演算を行い、リスク別にソートされたリストＬ１００を作成することで、フラグメントは一定水準を保ちながらリスクを最低にすることができる。【０２２０】
ここで、リスク演算、フラグメント演算とも分割数の代わりにたとえば平均値が小さい順に上位１０％の候補を選択し、その中で分散を用いてソートする、など様々なソートも可能である。【０２２１】
以上がサービス要求から自動設定までの動作の説明である。【０２２２】
次に、障害が発生した時の管理者への障害通知動作について図１６のフローチャートを用いて詳細に説明する。【０２２３】
当該フローにより、運営中のサービスがサービス提供不可能になったことを管理者に通知し、管理者は通知された障害情報に対して、障害復旧処理をとることができる。例えば前記サービスインスタンスにあらかじめ設定しておいたａｃｔｉｖｅなサービスユニットに障害が発生した場合、ｓｔａｎｄｂｙサービスユニットに切り替える、などの処理を行うことができる。また、例えばコンポーネント内部での冗長構成をとっていた前記の冗長資源メンバーのうち、ａｃｔｉｖｅ設定になっていた資源が障害でdownしても、standby資源に切り替わり、コンポーネントとしてはサービス継続が可能であった時など、サービスは継続しているが異常が発生している時は、アラームのみを通知することで、管理者にその旨を通知することができ、管理者は対処が可能である。【０２２４】
次にフローを追いながら詳細動作を説明する。
（ステップＳ３０１）
物理資源４で障害が発生し、その情報を通信手段３１０が受信する。
（ステップＳ３０２）
通信手段３１０は中央制御手段３０２に受信した障害情報を通知し、中層制御手段３０２は障害時プロセスを開始する。ここで障害検知は物理資源４がコントローラ３に発信してもよいし、コントローラ３が定期的に情報取得メッセージを送信し、その情報から障害を判断してもよい。その場合は、例えば中央制御手段３０２が物理資源管理手段３０８に管理する物理資源の定期的情報取得および状態判断を依頼しておき、物理資源管理手段３０８は通信手段３１０を通して物理資源４の状態を監視するなどの方法がとられる。
（ステップＳ３０３）
中央制御手段３０２が物理資源管理手段３０８に障害情報を通知する。
（ステップＳ３０４）
物理資源管理手段３０８はデータベース３０９にある物理資源空間情報２２００の該当する物理資源のデータの状態を更新し、関連する仮想資源ＩＤを中央制御手段３０２に通知する。
（ステップＳ３０５）
中央制御手段３０２は仮想資源管理手段３０６に障害の発生した仮想資源ＩＤを通知する。
（ステップＳ３０６）
仮想資源管理手段３０６はデータベース３０７にある仮想資源空間情報２３００の該当する仮想資源のデータの状態を更新し、更新のあった仮想資源と関連する仮想サービスグループ情報を検索するのに必要な検索ＩＤ情報を中央制御手段３０２情報に通知する。当該検索ＩＤは例えば図１７に示す関連するＩＤ情報Ｉ７００である。
（ステップＳ３０７）
中央制御手段３０２はＩＤ情報Ｉ７００を仮想サービスグループ管理手段３０４に通知する。
（ステップＳ３０８）
仮想サービスグループ管理手段３０４はＩＤ情報Ｉ７００から関連する仮想コンポーネント内の冗長資源メンバーをデータベース３０５にある仮想サービスグループ空間情報２４００から検索し、状態を更新する。
（ステップＳ３０９）
仮想サービスグループ管理手段３０４は更新手順Ｆ５０００により仮想サービスグループ空間情報２４００内の全ての仮想サービスグループの情報更新を行う。
（ステップＳ３１０）
仮想サービスグループ管理手段３０４は仮想サービスグループ、仮想サービスユニット、仮想コンポーネント、冗長資源メンバーの状態がupからalarmもしくはdownに変化したら、その情報をすべて障害情報として中央制御手段３０２に通知する。
（ステップＳ３１１）
中央制御手段３０２は障害情報を端末１に通知し管理者に通知する。次に更新手順Ｆ５０００について詳細に説明する。更新手順Ｆ５０００は仮想サービスグループ空間情報２４００内で状態の更新があった場合に行う動作を規定する。
（冗長資源メンバー２４１１の状態がupからdownになった場合）
冗長資源メンバー２４１１においてact/stdがactiveだった場合、act/stdをerrorに変え、そのバディＩＤをもつ冗長資源メンバーの中で、状態およびact/stdがそれぞれupおよびstandbyであるものを探し、act/stdをstandbyからactiveに切り替え、自分の属する仮想コンポーネント全体情報２４０９の状態をupからalarmに変える。複数ある場合はランダムに一つ選択する。もし一つもなかった場合は仮想コンポーネント全体情報２４０９の状態をupもしくはalarmからdownに変える。
また、冗長資源メンバー２４１１のact/stdがstandbyだった場合、act/stdをerrorに変え、仮想コンポーネント全体情報２４０９の状態をupからalarmに変える。
（仮想コンポーネント全体情報２４０９の状態がupからalarmに変わった場合）
自分の属する仮想ノードの仮想ノード全体情報２４０５の状態、および当該仮想ノードに属する仮想サービスユニットの仮想サービスユニット情報２４０７の状態をupからalarmにかえる。
（仮想コンポーネント全体情報２４０９の状態がupもしくはalarmからdownに変わった場合）
仮想コンポーネント全体情報２４０９の状態がupからdownもしくはalarmからdownに変わった場合、自分の属する仮想ノードの仮想ノード全体情報２４０５の状態をupからdownもしくはalarmからdownにかえる。
（仮想ノード全体状態２４０５の状態がdownに変わった場合）
当該仮想ノードに属する全ての仮想サービスユニットの状態をdownに変える。【０２２５】
当該仮想ノードの属する仮想サービスグループの状態をalarmにかえる。
（仮想サービスユニット全体情報２４０７の状態がupからalarmやdownに変わった場合）
自分の属する仮想サービスグループの仮想サービスグループ全体情報２４０３の状態をupからalarmにかえる。仮想サービスグループ全体情報２４０３の状態がAlarmである場合やdownの場合はそのまま。
（仮想サービスグループに属する全ての仮想サービスユニット全体情報２４０７の状態がdownに変わった場合）
仮想サービスグループ全体情報２４０３の状態をdownに変える。【０２２６】
新たに更新があった場合は更新した情報を管理者に通知する。【０２２７】
次にシステム変更があったときの自動的な最適化更新手順について詳細に説明する。当該手順は例えば、ユニット物理資源を増設し、それに伴い新たな仮想資源を作成したなどの前回リスク演算、フラグメント演算を行った時点とは変更が生じた場合に、再度、最適化計算を行うことが可能である。
（ステップ１）
トリガーによって中央制御手段３０２はシステム更新フローＦ６０００を開始する。トリガーは管理者から入力されたシステム更新信号の受信によって行われる。また、仮想資源空間情報２３００が更新されたことをトリガーとしてもよい。
（ステップ２）
中央制御手段３０２は仮想資源管理手段３０６に資源情報更新命令を送信。
（ステップ３）
仮想資源管理手段３０２は更新命令をうけて、データベース３０７上にある仮想資源空間情報２２００を最新のものに更新後、更新完了を中央制御装置３０２に通知する。
（ステップ４）
更新完了通知後、図９に記載のＳ１０３〜Ｓ１１０を行う。【０２２８】
ここで、管理者に確認してから行う場合は図９のフローの代わりに図１０のフローにしたがって設定を行うことも可能である。【０２２９】
次に本発明の効果について説明する。
本発明を実施するための最良の形態では、図１８に示すように、管理者が物理資源選択の際に、そのリスクやフラグメントを意識することなく、論理的構成を指定するだけで、自動的に設定することが可能である。【０２３０】
本発明の効果は論理的にはサービス設定を行う管理者に対して、インターフェース４０５０を定義し、サービス要求４０１４に対し、仮想サービスグループ空間４００５を定義し、サービス要求４０１４内のサービスグループ４０１１とサービスユニット４０１２とコンポーネント４０１３とノード４０１０とに対応する仮想サービスグループ４００６と仮想サービスユニット４００７と仮想コンポーネント４００９と仮想ノード４００８を提供し、リスク管理もしくはフラグメント管理を行い、アロケータ４００１をもちいて最適な物理資源４００２内のモジュラー型ユニット物理資源４００４を前記サービスグループ空間４００５内の仮想サービスグループ４００６内の仮想サービスユニット４００７および仮想サービスユニット４００７を構成する仮想コンポーネント４００９に割り当てることが可能な点である。【０２３１】
これにより、サービス設定時、もしくはシステムの変更があった場合などに管理者はリスクやフラグメントの最適化を意識することなく自動的な最適設定が可能となる。【０２３２】
すでに資源の性能や種類などで分類され、仮想資源４１０５を有する仮想資源プール４１０４が用意された仮想化層４１０６を含むシステムに対しても、同様に、図１９に示すようにアロケータ４１１１により、インターフェース４０５０を通してなされたサービス要求４０１４に対し、提供した仮想サービスグループ４００６と仮想サービスユニット４００７と仮想コンポーネント４００９と仮想ノード４００８と、前記仮想化層４１０６上の仮想資源４１０５を割り当てることで、同様の効果が達成できる。
【産業上の利用可能性】
【０２３３】
本発明によれば、複数のモジュラー型ユニット物理資源が搭載された複数のプラットフォームを含む大規模管理システムにおけるネットワーク装置、コンピュータ装置などのサービス設定・管理、およびそのプログラムといった用途に適用できる。
【図１】
0004304535.tif 000007
【図２】
0004304535.tif 000008
【図３】
0004304535.tif 000009
【図４】
0004304535.tif 000010
【図５】
0004304535.tif 000011
【図６】
0004304535.tif 000012
【図７】
0004304535.tif 000013
【図８】
0004304535.tif 000014
【図９】
0004304535.tif 000015
【図１０】
0004304535.tif 000016
【図１１】
0004304535.tif 000017
【図１２】
0004304535.tif 000018
【図１３】
0004304535.tif 000019
【図１４】
0004304535.tif 000020
【図１５】
0004304535.tif 000021
【図１６】
0004304535.tif 000022
【図１７】
0004304535.tif 000023
【図１８】
0004304535.tif 000024
【図１９】
0004304535.tif 000025
【図２０】
0004304535.tif 000026
【図２１】
0004304535.tif 000027
【図２２】
0004304535.tif 000028
【図２３】
0004304535.tif 000029
【図２４】
0004304535.tif 000030
【図２５】
0004304535.tif 000031
【図２６】
0004304535.tif 000032
【図２７】
0004304535.tif 000033
【図２８】
0004304535.tif 000034
【図２９】
0004304535.tif 000035
【図３０】
0004304535.tif 000036
【図３１】
0004304535.tif 000037
【図３２】
0004304535.tif 000038
【図３３】
0004304535.tif 000039
【図３４】
0004304535.tif 000040