JP4304535B2 - 情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システムと、コンポーネント選択方法 - Google Patents

情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システムと、コンポーネント選択方法 Download PDF

Info

Publication number
JP4304535B2
JP4304535B2 JP2006545084A JP2006545084A JP4304535B2 JP 4304535 B2 JP4304535 B2 JP 4304535B2 JP 2006545084 A JP2006545084 A JP 2006545084A JP 2006545084 A JP2006545084 A JP 2006545084A JP 4304535 B2 JP4304535 B2 JP 4304535B2
Authority
JP
Japan
Prior art keywords
information
virtual
resource
service
risk
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006545084A
Other languages
English (en)
Other versions
JPWO2006054573A1 (ja
Inventor
伸治 加美
隆士 吉川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JPWO2006054573A1 publication Critical patent/JPWO2006054573A1/ja
Application granted granted Critical
Publication of JP4304535B2 publication Critical patent/JP4304535B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant

Description

本発明は情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システムに関する。
近年のインターネットの広範な普及により、コンピュータ、ネットワークをもちいた電子的業務管理システムはビジネス基盤や社会的なインフラとして完全に定着し、インターネット関連システムにおいて高いレベルのミッションクリティカル性が求められている。そのため、そのようなシステムには、一般に障害発生時にも業務を停止することなく予備資源に切り替わるような冗長構成が組まれることが行われる。
冗長化を行う上で、装置内を二重化し片方をアクティブ、もう一方をスタンバイに設定し装置内のコンポーネントレベルでの障害に備え、さらに、電源故障など装置単位の故障に備え複数の装置で冗長グループを構成し、そのうちの一つをアクティブとし、その他をスタンバイ資源とする手法がある。ただしこの際、この装置を使用してサービスを受けるユーザからは単一の装置として見えるよう仮想化されている必要がある。
ひとつの手法として装置間冗長は一般に冗長用の専用プロトコルが使用される。例えば、図２０に記載のルータの場合、ルータ４０５内部において資源４０１および４０２で内部二重化４０１１を設定しておいて、非特許文献１に記載の複数のルータ間での冗長化プロトコル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 とすると、リスクパラメータの平均は、
Figure 0004304535
 となるので、組み合わせ１のリスクパラメータの平均は2.25となる。
また、リスクパラメータの分散は、
Figure 0004304535
 となるので、組み合わせ１のリスクパラメータの分散は0.25となる。
これら求めたリスクパラメータの平均及び分散を組み合わせ１のリスク情報とする。
次に、フラグメント情報ではフラグメントパラメータを算出する。
フラグメントパラメータは一つの各サービスグループのサービスユニットを構成するコンポーネントの偏りを示す数値である。
例えば、組み合わせ１のサービスグループ１のサービスユニット１ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット１ａのフラグメントパラメータは０（＝１−１）である。同様に、組み合わせ１のサービスグループ１のサービスユニット１ｂを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット１ｂのフラグメントパラメータは０（＝１−１）である。同様に、組み合わせ１のサービスグループ１のサービスユニット１ｃを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット１ｃのフラグメントパラメータは０（１−１）である。
同様な方法で、組み合わせ１のサービスグループ２のサービスユニット２ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット２ａのフラグメントパラメータは０（＝１−１）である。サービスユニット２ｂを構成するコンポーネントは、二つのシェルフにまたがって収容されているので、サービスユニット２ｂのフラグメントパラメータは１（＝２−１）である。
同様な方法で、組み合わせ１のサービスグループ３のサービスユニット３ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット３ａのフラグメントパラメータは０（＝１−１）である。サービスグループ３のサービスユニット３ｂを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット３ｂのフラグメントパラメータは０（＝１−１）である。
同様な方法で、組み合わせ１のサービスグループ４のサービスユニット４ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット４ａのフラグメントパラメータは０（＝１−１）である。サービスユニット４ｂを構成するコンポーネントは二つのシェルフにまたがって収容されているので、サービスユニット４ｂのフラグメントパラメータは１（＝２−１）である。
同様な方法で、組み合わせ１のサービスグループ５のサービスユニット５ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット５ａのフラグメントパラメータは０（＝１−１）である。サービスユニット５ｂを構成するコンポーネントは二つのシェルフにまたがって収容されているので、サービスユニット５ｂのフラグメントパラメータは１（＝２−１）である。
同様な方法で、組み合わせ１のサービスグループ６のサービスユニット６ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット６ａのフラグメントパラメータは０（＝１−１）である。サービスユニット６ｂを構成するコンポーネントは二つのシェルフにまたがって収容されているので、サービスユニット６ｂのフラグメントパラメータは１（＝２−１）である。
同様な方法で、組み合わせ１のサービスグループ７のサービスユニット７ａを構成するコンポーネントは同一シェルフ内に収容されているので、サービスユニット７ａのフラグメントパラメータは０（＝１−１）である。サービスユニット７ｂを構成するコンポーネントは、二つのシェルフにまたがって収容されているので、サービスユニット７ｂのフラグメントパラメータは１（＝２−１）である。
ここで、各サービスユニットのフラグメントパラメータをfi とし、サービスユニット数をn とすると、フラグメントパラメータの平均は、
Figure 0004304535
 となるので、組み合わせ１のフラグメントパラメータの平均は0.333333となる。
また、フラグメントパラメータの分散は、
Figure 0004304535
 となるので、組み合わせ１のフラグメントパラメータの分散は0.238095となる。
これら求めたフラグメントパラメータの平均及び分散を組み合わせ１のフラグメント情報とする。
組み合わせ２、３、４についても、上述と同様な方法でリスク情報及びフラグメント情報を算出する。これらの結果を図３１から図３３に記載した。
次に、リスク情報及びフラグメント情報に基づく、各コンポーネントの組み合わせの順位付けについて説明する。
（１）リスクのみ
ポリシーID=1の場合、リスク演算のみで、分割が無限大なので、リスクパラメータ平均でソートする。
各シェルフのリスクパラメータをyi とし、シェルフ数をn とすると、リスクパラメータの平均は、
Figure 0004304535
 となる。
従って、各組み合わせのリスクパラメータの平均は各図に示される通りとなり、組み合わせ４＜組み合わせ２＜組み合わせ１＜組み合わせ３の順でリスクが低くなる。ここで、組み合わせ４と２は平均が同じなので、リスクパラメータの分散の小さい４がよりリスク低となる。
（２）フラグメントのみ
ポリシー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に変える。
新たに更新があった場合は更新した情報を管理者に通知する。
次にシステム変更があったときの自動的な最適化更新手順について詳細に説明する。当該手順は例えば、ユニット物理資源を増設し、それに伴い新たな仮想資源を作成したなどの前回リスク演算、フラグメント演算を行った時点とは変更が生じた場合に、再度、最適化計算を行うことが可能である。
（ステップ１）
トリガーによって中央制御手段３０２はシステム更新フローＦ６０００を開始する。トリガーは管理者から入力されたシステム更新信号の受信によって行われる。また、仮想資源空間情報２３００が更新されたことをトリガーとしてもよい。
（ステップ２）
中央制御手段３０２は仮想資源管理手段３０６に資源情報更新命令を送信。
（ステップ３）
仮想資源管理手段３０２は更新命令をうけて、データベース３０７上にある仮想資源空間情報２２００を最新のものに更新後、更新完了を中央制御装置３０２に通知する。
（ステップ４）
更新完了通知後、図９に記載のＳ１０３〜Ｓ１１０を行う。
ここで、管理者に確認してから行う場合は図９のフローの代わりに図１０のフローにしたがって設定を行うことも可能である。
次に本発明の効果について説明する。
本発明を実施するための最良の形態では、図１８に示すように、管理者が物理資源選択の際に、そのリスクやフラグメントを意識することなく、論理的構成を指定するだけで、自動的に設定することが可能である。
本発明の効果は論理的にはサービス設定を行う管理者に対して、インターフェース４０５０を定義し、サービス要求４０１４に対し、仮想サービスグループ空間４００５を定義し、サービス要求４０１４内のサービスグループ４０１１とサービスユニット４０１２とコンポーネント４０１３とノード４０１０とに対応する仮想サービスグループ４００６と仮想サービスユニット４００７と仮想コンポーネント４００９と仮想ノード４００８を提供し、リスク管理もしくはフラグメント管理を行い、アロケータ４００１をもちいて最適な物理資源４００２内のモジュラー型ユニット物理資源４００４を前記サービスグループ空間４００５内の仮想サービスグループ４００６内の仮想サービスユニット４００７および仮想サービスユニット４００７を構成する仮想コンポーネント４００９に割り当てることが可能な点である。
これにより、サービス設定時、もしくはシステムの変更があった場合などに管理者はリスクやフラグメントの最適化を意識することなく自動的な最適設定が可能となる。
すでに資源の性能や種類などで分類され、仮想資源４１０５を有する仮想資源プール４１０４が用意された仮想化層４１０６を含むシステムに対しても、同様に、図１９に示すようにアロケータ４１１１により、インターフェース４０５０を通してなされたサービス要求４０１４に対し、提供した仮想サービスグループ４００６と仮想サービスユニット４００７と仮想コンポーネント４００９と仮想ノード４００８と、前記仮想化層４１０６上の仮想資源４１０５を割り当てることで、同様の効果が達成できる。
本発明によれば、複数のモジュラー型ユニット物理資源が搭載された複数のプラットフォームを含む大規模管理システムにおけるネットワーク装置、コンピュータ装置などのサービス設定・管理、およびそのプログラムといった用途に適用できる。

Claims (22)

  1. 情報処理装置であって、
    所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報が格納された記憶手段と、
    前記コンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行う処理手段と
    を有することを特徴とする情報処理装置。
  2. 前記処理手段は、リスク情報として、各コンポーネントの組み合わせにおけるリスクの統計量を算出する手段を有することを特徴とする請求項１に記載の情報処理装置。
  3. 前記処理手段は、リスク情報として、各コンポーネントの組み合わせにおけるリスクの統計量であるところの平均及び／又は分散を算出する手段を有することを特徴とする請求項２に記載の情報処理装置。
  4. 前記処理手段は、フラグメント情報として、各コンポーネントの組み合わせにおけるフラグメントの統計量を算出する手段を特徴とする請求項１から請求項３のいずれかに記載の情報処理装置。
  5. 前記処理手段は、フラグメント情報として、各コンポーネントの組み合わせにおけるフラグメントの統計量であるところの平均及び／又は分散を算出する手段を特徴とする請求項４に記載の情報処理装置。
  6. 前記記憶手段に格納されるコンポーネント情報が、物理的な資源の情報であることを特徴とする請求項１から請求項５のいずれかに記載の情報処理装置。
  7. 前記記憶手段に格納されるコンポーネント情報が、物理的な資源の物理資源情報と、前記物理資源情報と関連付けられ、前記物理的な資源を仮想化してコンポーネント化した仮想化資源の仮想化資源情報とから成り、
    前記処理手段は、前記コンポーネント情報に基づいて、一つの仮想化された資源を一つのコンポーネントとしてコンポーネントの組み合わせを算出する手段を有することを特徴とする請求項１から請求項６のいずれかに記載の情報処理装置。
  8. 情報処理装置のプログラムであって、
    前記プログラムは情報処理装置を、
    所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行う手段として機能させることを特徴とする情報処理装置のプログラム。
  9. リスク情報が各コンポーネントの組み合わせにおけるリスクの統計量であることを特徴とする請求項８に記載の情報処理装置のプログラム。
  10. リスク情報が各コンポーネントの組み合わせにおけるリスクの統計量であるところの平均及び／又は分散であることを特徴とする請求項９に記載の情報処理装置のプログラム。
  11. フラグメント情報が各コンポーネントの組み合わせにおけるフラグメントの統計量であることを特徴とする請求項８から請求項１０のいずれかに記載の情報処理装置のプログラム。
  12. フラグメント情報が各コンポーネントの組み合わせにおけるフラグメントの統計量であるところの平均及び／又は分散であることを特徴とする請求項１１に記載の情報処理装置のプログラム。
  13. 前記コンポーネントが、物理的な資源であることを特徴とする請求項８から請求項１２のいずれかに記載の情報処理装置のプログラム。
  14. 前記コンポーネントが、物理的な資源を仮想化した資源であることを特徴とする請求項８から請求項１３のいずれかに記載の情報処理装置のプログラム。
  15. モジュラー型システムの運用管理システムであって、
    ネットワークと接続され、管理対象であるモジュラー型システムを構成する物理資源と、
    ネットワークと接続され、前記物理資源が提供する設定項目もしくは稼動データ項目の情報取得要求データ、設定要求データ、並びにポリシーデータを送信する端末と、
    ネットワークに接続され、前記物理資源の情報である物理資源情報と、前記物理資源が提供する設定・稼動データ項目について参照又は変更を行う項目の情報が抽出された仮想資源情報と、前記仮想資源から構成される仮想サービスグループの情報であって、前記仮想資源が提供する設定・稼動データ項目について参照又は変更を行う項目の情報が抽出・加工された仮想サービスグループ空間情報と、前記仮想資源が提供する設定・稼動データ項目について参照又は変更を行う際の処理情報を記載したポリシー情報とを備え、
    前記端末から送信される前記物理資源又は仮想資源の設定要求に応答し、前記仮想資源情報及びポリシー情報に基づいて最適化演算による解を算出し、この解に基づいて、仮想資源サービスグループの最適設定を行い、前記仮想サービスグループ空間情報を作成・管理し、前記端末に送信し、また前記各情報に対する情報取得要求に対して前記端末に情報を送信する手段とを有するコントローラと
    を有することを特徴とするモジュラー型システムの運用管理システム。
  16. 前記コントローラは、前記設定要求に対して、前記物理資源情報又は前記仮想資源情報を用いて、物理的な障害が前記設定要求に及ぼすリスクの情報であるリスク情報を算出し、前記仮想サービスグループ空間情報を作成・管理する手段を有することを特徴とする請求項１５に記載のモジュラー型システムの運用管理システム。
  17. 前記コントローラは、前記設定要求に対して、前記物理資源情報又は前記仮想資源情報を用いて、資源利用状況の偏り度合いであるところのフラグメント情報を算出し、前記仮想サービスグループ空間情報を作成・管理する手段を有することを特徴とする請求項１５又は請求項１６に記載のモジュラー型システムの運用管理システム。
  18. 前記コントローラは、
    前記物理資源の情報が格納される物理資源情報データベースと、
    前記物理資源データベースの読み書き、情報更新、監視等の管理を行う物理資源管理手段と、
    前記仮想資源の情報が格納される仮想資源情報データベースと、
    前記仮想資源データベースの読み書き、情報更新、監視等の管理を行う仮想資源管理手段と、
    前記仮想サービスグループ空間の情報が格納される仮想サービスグループ空間情報データベースと、
    前記仮想サービスグループ空間情報データベースの読み書き、情報更新、監視等の管理を行う仮想サービスグループ管理手段と、
    前記ポリシーの情報が格納されるポリシー情報データベースと、
    前記ポリシー情報データベースの読み書き、情報更新、監視等の管理を行うポリシー管理手段と
    を有することを特徴とする請求項１５から請求項１７のいずれかに記載のモジュラー型システムの運用管理システム。
  19. 前記コントローラは、物理資源とネットワークを介して通信し、必要なデータの送受信を行う通信手段を有することを特徴とする請求項１５から請求項１８のいずれかに記載のモジュラー型システムの運用管理システム。
  20. 前記コントローラは、障害発生時に、物理資源からのアラーム信号の受信、又はコントローラからの定期的な信号送信による状態検査により、異常を検知する手段と、前記物理資源管理手段、前記仮想資源管理手段、前記仮想サービスグループ管理手段に、前記異常検知を通知する手段とを有し、
    前記物理資源管理手段、前記仮想資源管理手段及び前記仮想サービスグループ管理手段は、前記異常検知に基づいて、管理するデータベースの情報を更新することを特徴とする請求項１５から請求項１９のいずれかに記載のモジュラー型システムの運用管理システム。
  21. システム変更時に、前記物理資源管理手段、前記仮想資源管理手段及び前記仮想サービスグループ管理手段は、増設や変更などのシステム変更時に、管理するデータベースの情報を更新し、
    前記コントローラは、前記更新された情報に基づいて、前記最適化演算を自動的に又は管理者の指令によるトリガーによって再演算し、この結果に基づいて仮想資源サービスグループの最適設定を行う手段を有することを特徴とする請求項１５から請求項２０のいずれかに記載のモジュラー型システムの運用管理システム。
  22. サービスで要求されるシステムを構成するに必要なコンポーネントを選択するコンポーネント選択方法であって、
    所定の機能を持つシステムを構成する為のコンポーネントに関するコンポーネント情報に基づいて、サービスで要求されるシステムを構成するに必要なコンポーネントの組み合わせを算出し、
    これらのコンポーネントの組み合わせについて、物理的な障害がサービス要求に及ぼすリスクの情報であるリスク情報、及び／又は、コンポーネントの利用状況の偏り度合いの情報であるフラグメント情報を算出し、
    所定のポリシー、算出したリスク情報及び／又はフラグメント情報に基づいて、選択したコンポーネントの組み合わせに対して順位付けを行う
    ことを特徴とするコンポーネント選択方法。
JP2006545084A 2004-11-17 2005-11-16 情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システムと、コンポーネント選択方法 Expired - Fee Related JP4304535B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2004333778 2004-11-17
JP2004333778 2004-11-17
PCT/JP2005/021003 WO2006054573A1 (ja) 2004-11-17 2005-11-16 情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システムと、コンポーネント選択方法

Publications (2)

Publication Number Publication Date
JPWO2006054573A1 JPWO2006054573A1 (ja) 2008-05-29
JP4304535B2 true JP4304535B2 (ja) 2009-07-29

Family

ID=36407114

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006545084A Expired - Fee Related JP4304535B2 (ja) 2004-11-17 2005-11-16 情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システムと、コンポーネント選択方法

Country Status (4)

Country Link
US (1) US7856572B2 (ja)
JP (1) JP4304535B2 (ja)
CN (1) CN101061464B (ja)
WO (1) WO2006054573A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4663484B2 (ja) * 2005-04-25 2011-04-06 株式会社日立製作所 システムセキュリティ設計・評価支援ツール、システムセキュリティ設計支援ツール、システムセキュリティ設計・評価支援プログラム、およびシステムセキュリティ設計支援プログラム
US8155619B2 (en) * 2007-06-01 2012-04-10 Cisco Technology, Inc. Interoperability and collaboration system with emergency interception monitoring
JPWO2009110111A1 (ja) * 2008-03-04 2011-07-14 三菱電機株式会社 サーバ装置及びサーバ装置の異常検知方法及びサーバ装置の異常検知プログラム
US8463669B2 (en) 2009-01-09 2013-06-11 Ganart Technologies, Inc. System for providing goods and services based on accrued but unpaid earnings
US20110145555A1 (en) * 2009-12-15 2011-06-16 International Business Machines Corporation Controlling Power Management Policies on a Per Partition Basis in a Virtualized Environment
US8589936B2 (en) 2010-03-16 2013-11-19 Alcatel Lucent Method and apparatus for managing reallocation of system resources
US8463908B2 (en) * 2010-03-16 2013-06-11 Alcatel Lucent Method and apparatus for hierarchical management of system resources
CN102497288A (zh) * 2011-12-13 2012-06-13 华为技术有限公司 一种双机备份方法和双机系统实现装置
US8862948B1 (en) * 2012-06-28 2014-10-14 Emc Corporation Method and apparatus for providing at risk information in a cloud computing system having redundancy
US9021307B1 (en) * 2013-03-14 2015-04-28 Emc Corporation Verifying application data protection
US10025610B2 (en) * 2013-04-30 2018-07-17 Telefonaktiebolaget Lm Ericsson (Publ) Availability management of virtual machines hosting highly available applications
US20160125068A1 (en) * 2013-05-13 2016-05-05 Fulcrum Collaborations, Llc System and method for integrated mission critical ecosystem management
JP5678222B2 (ja) * 2014-03-19 2015-02-25 株式会社日立製作所 管理装置及び方法並びに計算機システム
US9286056B2 (en) 2014-05-19 2016-03-15 International Business Machines Corporation Reducing storage facility code load suspend rate by redundancy check
US20160055546A1 (en) 2014-08-21 2016-02-25 Oracle International Corporation Managing progressive statistical ids
US11961105B2 (en) 2014-10-24 2024-04-16 Ganart Technologies, Inc. Method and system of accretive value store loyalty card program
US10447581B2 (en) * 2017-02-28 2019-10-15 Nicira, Inc. Failure handling at logical routers according to a non-preemptive mode
CN108319545B (zh) * 2018-02-01 2021-07-16 联想(北京)有限公司 一种信息处理方法及电子设备
KR20220033056A (ko) * 2019-07-23 2022-03-15 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베. 코어셋 그룹화
US11516277B2 (en) 2019-09-14 2022-11-29 Oracle International Corporation Script-based techniques for coordinating content selection across devices
US11657293B2 (en) * 2019-11-07 2023-05-23 X Development Llc Asynchronous architecture for evolutionary computation techniques
US11960373B2 (en) * 2020-03-20 2024-04-16 UncommonX Inc. Function evaluation of a system or portion thereof

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5504670A (en) * 1993-03-31 1996-04-02 Intel Corporation Method and apparatus for allocating resources in a multiprocessor system
JPH0773061A (ja) * 1993-09-02 1995-03-17 Nec Corp ホットスタンバイシステムにおける待機系配置ホスト決 定方式
US6058490A (en) * 1998-04-21 2000-05-02 Lucent Technologies, Inc. Method and apparatus for providing scaleable levels of application availability
US6779016B1 (en) * 1999-08-23 2004-08-17 Terraspring, Inc. Extensible computing system
US6591373B1 (en) * 1999-12-15 2003-07-08 Lucent Technologies Inc. Uniform configuration controller for replicated component systems
JP3768775B2 (ja) * 2000-04-27 2006-04-19 三菱電機株式会社 バックアップ装置及びバックアップ方法
US7284244B1 (en) * 2000-05-02 2007-10-16 Microsoft Corporation Resource manager architecture with dynamic resource allocation among multiple configurations
US7058947B1 (en) * 2000-05-02 2006-06-06 Microsoft Corporation Resource manager architecture utilizing a policy manager
US6651182B1 (en) * 2000-08-03 2003-11-18 International Business Machines Corporation Method for optimal system availability via resource recovery
JP2002259147A (ja) * 2001-02-27 2002-09-13 Hitachi Ltd 情報処理装置及びリアルタイム分散処理システム
JP2002323986A (ja) * 2001-04-25 2002-11-08 Hitachi Ltd コンピュータリソース流通システム及び方法
US6820218B1 (en) * 2001-09-04 2004-11-16 Microsoft Corporation Persistent stateful component-based applications via automatic recovery
US7747893B2 (en) * 2007-05-15 2010-06-29 International Business Machines Corporation Method and system for managing resources during system initialization and startup

Also Published As

Publication number Publication date
CN101061464B (zh) 2012-07-04
US20090150711A1 (en) 2009-06-11
CN101061464A (zh) 2007-10-24
WO2006054573A1 (ja) 2006-05-26
JPWO2006054573A1 (ja) 2008-05-29
US7856572B2 (en) 2010-12-21

Similar Documents

Publication Publication Date Title
JP4304535B2 (ja) 情報処理装置及びこのプログラムと、モジュラー型システムの運用管理システムと、コンポーネント選択方法
US8135751B2 (en) Distributed computing system having hierarchical organization
US8719832B2 (en) Capacity management of applications on server resources
US7680799B2 (en) Autonomic control of a distributed computing system in accordance with a hierarchical model
JP4374378B2 (ja) 運用実績評価装置、運用実績評価方法、およびプログラム
US7533173B2 (en) Policy driven automation - specifying equivalent resources
KR100998391B1 (ko) 데이터 처리 시스템을 관리하는 규정 설정 방법, 컴퓨터 판독 가능한 저장 매체 및 시스템
CN101040486B (zh) 动态分布式环境中的自动拓扑形成方法及系统
US7590653B2 (en) Automated discovery and inventory of nodes within an autonomic distributed computing system
JP5215840B2 (ja) 非同期イベント通知
US20060015773A1 (en) System and method for failure recovery and load balancing in a cluster network
US20020178262A1 (en) System and method for dynamic load balancing
US20060173857A1 (en) Autonomic control of a distributed computing system using rule-based sensor definitions
US8381222B2 (en) Policy driven automation—specifying equivalent resources
US20050044220A1 (en) Method and system of managing computing resources
US20080148270A1 (en) Method and implementation for storage provisioning planning
CN113382077B (zh) 微服务调度方法、装置、计算机设备和存储介质
Dieye et al. On achieving high data availability in heterogeneous cloud storage systems
CN1954295A (zh) 用于控制分布式处理环境中作业执行的计算机系统、方法及程序
US8892702B2 (en) Policy driven autonomic computing-programmatic policy definitions
Gaonkar et al. Designing dependable storage solutions for shared application environments
CN114741190A (zh) 一种云计算资源的调度方法及装置
CN113760441A (zh) 容器创建方法、装置、电子设备及存储介质
Santos et al. Policy-based resource assignment in utility computing environments
WO2024069949A1 (ja) 通信システムに含まれるハードウェアリソースの管理

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20081016

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090107

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090306

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090401

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090414

R150 Certificate of patent or registration of utility model

Ref document number: 4304535

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120515

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120515

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130515

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140515

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees