JP6743180B2 - 管理システム及び管理方法 - Google Patents

Description

本発明は、概して、リソースの管理に関する。

従来、計算機システムの運用の１つとして、サーバ及びストレージなどの計算機リソース（以下、これを単にリソースと呼ぶ）をプールとして管理しておき、ユーザが必要な場合にプールに属するリソースの中から所望のリソースを利用し、その後そのリソースが不要となった場合に当該リソースをプールに戻す運用がある。

このような運用では、ユーザは、例えばＣＰＵ（Central Processing Unit）の動作周波数や、メモリの搭載容量及びストレージの容量などのリソースの性能に関する要件（以下、これを性能要件と呼ぶ）をリソースの管理者（以下、これをリソース管理者と呼ぶ）に連絡する。

そして、かかる連絡を受けたリソース管理者は、その性能要件を満たすリソースをプールから選択し、そのリソースをユーザに対して割り当てる。かくしてユーザは、リソース管理者から割り当てられたリソースを利用する。

なお、下記特許文献１には、プールされるリソースが均質でない計算機システムにおいて、各リソースの性能に関する性能情報と、各リソースが備える機能に関する機能情報とを取得し、取得した各リソースの性能情報及び機能情報と、リソース要求において要求されている性能要件及び機能要件とに基づいて、複数のリソースの中からユーザに割り当てるリソースの候補を検索し、該検索により検出した候補の中からユーザに割り当てるリソースを決定し、決定したリソースをユーザに割り当てる技術が開示されている。

US2011/0010634

企業のニーズに応じて、サーバシステム（例えば、１以上のサーバ）とストレージシステム（例えば、１以上のストレージ装置）とのうちの少なくとも１つを含んだ計算機システム、その計算機システム上で稼動するソフトウェア、及び、計算機システムの管理システムで稼働する運用管理用ソフトウェアのような複数のエンティティで構成したアプライアンスとしての統合プラットフォームを提供することが知られている。統合プラットフォームを導入した企業は、その統合プラットフォームに対して電源を投入すれば、その企業のニーズに合った運用を開始することができる。

しかし、そのようなアプライアンスは、一般に、ハードウェア構成及び用途のような制約が決まっており、企業のニーズの追加や変更に、アプライアンスの事前の設計を超えて柔軟に対応することが難しい。例えば、空きのサーバがあるからといってその空きのサーバを企業が自由に使用することは、アプライアンスの安定性又はその他の観点から難しい。

そこで、複数種類のリソースを含んだ複数のリソース上に仮想的なアプライアンスを設定することが望まれることが考えられる。

仮想的なアプライアンスに要求される機能性として、単一のリソースが有する機能性のみでは実現できない機能性があり得る。しかし、特許文献１には、必要とされる機能性をいずれの複数のリソースにより提供可能であるかを検出する技術は開示されていない。

リソースプールの管理システムは、リソース管理処理と、システム構築処理とを実行する。リソース管理処理は、機能性を実現する２以上のリソースの組合せをリソースグループとして管理することを含む。システム構築処理は、要求される機能性と、リソースプールに含まれているリソース毎の機能性との他に、管理されているリソースグループ毎の機能性を考慮して、前記リソースプールから、前記要求される機能性を実現するシステムである基盤システムの構成要素とされる１又は２以上のリソースを選択することを含む。

機能性を実現する２以上のリソースの組合せをリソースグループとして管理する。これにより、管理されているリソースグループ毎の機能性を考慮して、基盤システムの構成要素とされるリソースを選択できる。

実施形態に係る情報システムの構成を示すブロック図である。 サーバの構成を示すブロック図である。 リソーステーブルの構成を示す。 リソースグループテーブルの構成を示す。 リソースグループ定義テーブルの構成を示す。 トポロジテーブルの構成を示す。 トポロジ関連テーブルの構成を示す。 基盤システムテンプレートテーブルの構成を示す。 基盤システム配備テーブルの構成を示す。 ラック３が追加された情報システムの構成を示すブロック図である。 検知処理の流れを示すフローチャートの一部である。 検知処理の流れを示すフローチャートの残りである。 検知処理前のリソーステーブル例を示す。 検知処理後のリソーステーブル例を示す。 検知処理後のトポロジテーブル例を示す。 検知処理後のリソースグループテーブル例を示す。 配備処理の流れを示すフローチャートである。

以下の説明では、情報について、テーブルが採用されるが、情報のデータ構造は限定されず、他のデータ構造であってもよい。情報はデータ構造に依存しないため、例えば「ｋｋｋテーブル」を「ｋｋｋ情報」と呼ぶことができる。テーブルのような情報は、２以上の情報要素に分割されてもよいし、２種以上の情報の全部又は一部が同一情報に集約されてもよい。

また、以下の説明において、「インタフェース部」は、１以上のインタフェースを含む。１以上のインタフェースは、１以上の同種のインタフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種のインタフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明において、「記憶部」は、１以上のメモリを含む。少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。記憶部は、１以上のメモリに加えて、１以上のＰＤＥＶを含んでもよい。「ＰＤＥＶ」は、物理的な記憶デバイスを意味し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよい。ＰＤＥＶは、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive)でよい。

また、以下の説明において、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）である。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明において、「管理システム」は、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が表示デバイスを有していて管理計算機が自分の表示デバイスに情報を表示する場合、管理計算機が管理システムでよい。また、例えば、管理計算機（例えばサーバ）が表示用情報を遠隔の表示用計算機（例えばクライアント）に送信し表示用計算機がその情報を表示する場合（管理計算機が表示用計算機に情報を表示する場合）、管理計算機と表示用計算機とのうちの少なくとも管理計算機を含んだシステムが管理システムでよい。管理システムは、インタフェース部、記憶部及びそれらに接続されたプロセッサ部を有してよい。インタフェース部は、ユーザインタフェース部と、通信インタフェース部とのうちの少なくとも１つを含んでよい。ユーザインタフェース部は、１以上のＩ／Ｏデバイス（例えば入力デバイス（例えばキーボード及びポインティングデバイス）と出力デバイス（例えば表示デバイス））と表示用計算機とのうちの少なくとも１つのＩ／Ｏデバイスを含んでよい。通信インタフェース部は、１以上の通信インタフェースデバイスを含んでよい。管理システムにおける計算機が「表示用情報を表示する」ことは、計算機が有する表示デバイスに表示用情報を表示することであってもよいし、計算機が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。

また、以下の説明において、プロセッサ部は、プログラムを実行し、記憶部（例えば、メモリ）及びインタフェース部（例えば、通信ポート）等のうちの少なくとも１つを用いながら処理を行う。処理の主体について、以下の説明ではプログラムを主体とする場合があるが、プログラムを実行するプロセッサ部を主体としてもよい。また、プロセッサ部が主体となっている処理は、１以上のプログラムを実行することにより行われると解釈することができる。プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な記憶メディアであってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以下の説明において、同種の要素を区別しないで説明する場合には、参照符号又は参照符号のうちの共通符号を使用し、同種の要素を区別して説明する場合には、その要素に割り振られた識別子（例えば番号及び符号のうちの少なくとも１つ）又は参照符号全体を使用することがある。

また、以下の説明において、「計算機システム」は、サーバシステムとストレージシステムのうちの少なくとも１つを含んでよい。「サーバシステム」は、１以上の物理的なサーバであってもよいし、少なくとも１つの仮想的なサーバ（例えばＶＭ（Virtual Machine））を含んでもよい。「ストレージシステム」は、１以上の物理的なストレージ装置であってもよいし、少なくとも１つの仮想的なストレージ装置（例えばＳＤＳ（Software Defined Storage））を含んでもよい。

また、以下の説明において、「リソース」とは、計算機システムリソース（計算機リソース）の略であり、単独で又は１以上の他のリソースとの組み合せにより機能性を実現するエレメント、典型的には、サーバ、ストレージ装置（ストレージ）、スイッチ及びネットワークのような装置に該当するものとする。別の言い方をすれば、「リソース」は、ＣＰＵ及びメモリのようなコンポーネント（装置のコンポーネント）に該当しないでよいものとする。

また、以下の説明において、「機能性」とは、１又は複数のリソースによって実現される機能、サービス又はシステムである。

また、以下の説明において、「管理者」とは、サーバ、ストレージ及びネットワークといったリソースの管理を行う者である。管理者は、リソースの追加、削除及び交換等の保守作業と後述の管理サーバ３上のテーブル群３０の管理とのうちの少なくとも１つを行うことができる。

また、以下の説明において、「ユーザ」とは、基盤システムの配備を求める者である。

以下、図面を参照して、本発明の一実施の形態を詳述する。

図１は、本実施形態に係る情報システムの構成を示す。

図１において、情報システムは、リソースプール４と、リソースプール４を管理する管理システム１とを含む。管理システム１は、１又は複数の管理クライアント２、及び、１又は複数の管理サーバ３を含む。そして、これら管理クライアント２及び管理サーバ３が管理ネットワーク５を介して互いに接続されている。また、リソースプール４も、管理ネットワーク５に接続されている。リソースプール４には、１又は複数の電源盤６より電力が供給される。

管理クライアント２は、ユーザが使用するコンピュータ装置であり、例えばパーソナルコンピュータや、ワークステーション又はメインフレームなどから構成される。管理クライアント２は、管理ネットワーク５を介して管理サーバ３にアクセスし、管理サーバ３が提供する各種の処理を実行する。管理クライアント２は、基盤システム配備要求を管理サーバ３に送信する。管理者が操作する管理クライアント２によって、ユーザ毎に、１又は複数の基盤システム配備要求が送信される。「基盤システム配備要求」は、基盤システムを配備する要求である。基盤システム配備要求には、例えば、基盤システムソフトウェアＩＤと配備条件とのうちの少なくとも配備条件が指定される。「基盤システム」とは、リソースプール４から抽出された複数のリソースで構成されたシステムであり、「基盤システムソフトウェア」とは、基盤システムにインストールされるソフトウェア（例えば、仮想サーバソフトウェア（例えばハイパバイザ）、高信頼データベース管理システム、又は、クラスタ型分析ソフトウェア）である。基盤システムと基盤システムソフトウェアとの組合せが、ユーザ所望のサービスを提供する計算機システムのようなシステム（例えば仮想的なアプライアンス）でよい。「配備条件」は、基盤システムとして配備される（割り当てられる）リソースに関する条件であり、例えば、サーバ台数、機能性、及び、リソース共有条件のうちの少なくとも１つを含んでよい。配備条件の少なくとも一部の指定は、後述するテンプレートＩＤ及びバージョンの指定でよい。指定されたテンプレートＩＤ及びバージョンと、それらに関連付いている後述の情報（例えば情報３０６Ｃ〜３０６Ｅ）が、配備条件の少なくとも一部でよい。

管理サーバ３は、リソースプール４を構成する各リソースを検知及び管理する。管理サーバ３は、管理クライアント２からの基盤システム配備要求に応じ、当該配備要求に合致したリソースを抽出し、当該配備要求に従う基盤システムを、抽出したリソースに配備する（割り当てる）。管理サーバ３は、例えば、パーソナルコンピュータ、ワークステーション又はメインフレームなどから構成される。管理サーバ３は、メモリ１１、ＮＩＣ（Network Interface Card）１２、Ｉ／Ｏインタフェース１３、入力デバイス１４、出力デバイス１５、及びそれらに接続されたＣＰＵ１０を備える。

ＣＰＵ１０は、プロセッサ部の一例である。ＣＰＵ１０は、管理サーバ３全体の動作制御を司るデバイスである。このＣＰＵ１０がメモリ１１に格納された各種プログラムを実行することにより、管理サーバ３全体として各種の制御処理を実行する。

メモリ１１は、記憶部の一例である。メモリ１１は、各種のプログラム及び制御情報を保持するために用いられるほか、ＣＰＵ１０のワークメモリとしても用いられる。

ＮＩＣ１２及びＩ／Ｏインタフェース１３のうちの少なくとも１つは、インタフェース部の一例である。ＮＩＣ１２は、管理サーバ３を管理ネットワーク５に接続するためのネットワークインタフェースである。Ｉ／Ｏインタフェース１３は、管理サーバ３に入力デバイス１４及び出力デバイス１５を接続するためのインタフェースであり、ＵＳＢ（Universal Serial Bus）インタフェースなどから構成される。

入力デバイス１４は、キーボード、マウス及びマイクロフォンなどから構成され、管理者が管理サーバ３に対して各種の操作入力を行うときに使用される。出力デバイス１５は、モニタディスプレイ及びスピーカなどから構成され、画像及び音声などの情報を管理者３に提示する。

リソースプール４は、複数のラック４０を有する。複数のラック４０に、複数種類のリソースを含んだ複数のリソースの搭載が可能である。結果として、リソースプール４は、複数種類のリソースを含んだ複数のリソースを含む。ラック４０毎に、１以上の電源盤６が設けられている。なお、図１の例によれば、ラック３は未だ搭載されておらず、ラック３を搭載可能な物理的なスペースがある。ラック３が当該スペースに追加された場合、ラック３に搭載のリソースには、電源盤３及び４から電力が供給されることになる。

複数のリソースは、例えば、標準イーサネットスイッチ４１、高性能イーサネットスイッチ４２、ＦＣ（Fibre Channel）スイッチ４３、標準サーバ４４、高性能サーバ４５、ＦＣストレージ４６、ＰＤＵ（Power Distribution Unit）４７、及び高性能コアイーサネットスイッチ４８を含む（イーサネットは登録商標）。リソースプール４が含む複数のリソースの各々は、そのリソースが持つＩ／Ｏインタフェース（不図示）を介して管理ネットワーク５に接続され、管理サーバ３と通信を行う。各ラック４０を、そのラック４０に搭載されたリソースの物理位置として扱うことが可能である。例えば、ＦＣストレージ１の物理位置は“ラック１”とすることができる。また、高性能コアイーサネットスイッチ１のように全てのラック４０に接続されているリソースについては、そのリソースの物理位置は“共通”とすることができる。標準イーサネットスイッチ４１、高性能イーサネットスイッチ４２、ＦＣスイッチ４３及び高性能コアイーサネットスイッチ４８の各々は、ネットワーク又はスイッチ（例えばネットワークスイッチ）の一例である。標準サーバ４４及び高性能サーバ４５の各々は、サーバの一例である。ＦＣストレージ４６は、ストレージ（ストレージ装置）の一例である。

標準サーバ４４及び高性能サーバ４５の各々は、図２に示すように、メモリ６１、補助記憶装置６２（例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive））、１以上のＩ／Ｏインタフェース６３、拡張カード６４（例えば、ＧＰＧＰＵ（General-purpose computing on graphics processing ｕnits））、及び、それらに接続されたＣＰＵ６０を備える。なお、例えば、補助記憶装置６２及び拡張カード６４のうちの少なくとも１つはなくてもよい。また、Ｉ／Ｏインタフェース６３は、ＮＩＣやＨＢＡ（Host Bus Adaptor）などから構成されてよい。ＣＰＵ６０は、メモリ６１に格納されたプログラム６５に従って必要な制御処理を実行する。

図１に示すように、管理サーバ３のメモリ１１には、リソース管理プログラム２０及びテーブル群３０が格納されている。

リソース管理プログラム２０は、リソース管理部２１、トポロジ管理部２２及び基盤システム管理部２３といった複数のプログラムモジュールを含む。これらのプログラムモジュールの各々が独立したプログラムでもよいし、これらのプログラムモジュールのうちの２以上が１つのプログラムでもよい。

テーブル群３０は、１以上のテーブルである。テーブル群３０は、リソーステーブル３１、リソースグループテーブル３２、リソースグループ定義テーブル３３、トポロジテーブル３４、トポロジ関連テーブル３３、基盤システムテンプレートテーブル３６及び基盤システム配備テーブル３７を含む。

リソース管理部２１は、リソースプール４に存在するリソースに関する情報を管理するためのプログラムである。より具体的には、例えば、リソース管理部２１は、リソースプール４に存在するリソースに関する情報を、リソーステーブル３１を用いて管理する。さらに、リソース管理部２１は、リソースグループ定義テーブル３３にて定義された条件に合致した特定の機能性を持つ１又は複数のリソースを、リソースグループとして検出し、検出したリソースグループに関する情報をリソースグループテーブル４２にて管理する。また、リソース管理部２１は、リソースの追加、更新又は削除行われた際、当該リソースの変更を検知し、リソーステーブル３１を更新する。

トポロジ管理部２２は、リソース間の物理接続関係又は論理接続関係を、既に知られているトポロジ検知手法により検知し、検知した関係をトポロジテーブル３４にて管理する。ここで、当該既知のトポロジ検知手法としては、例えばイーサネットにおいては、ＩＥＥＥの標準規格であるＬＬＤＰ（Link Layer Discovery Protocol）と呼ばれる隣接関係情報の交換プロトコルが挙がられる。本ＬＬＤＰをサポートするイーサネットスイッチや、サーバ、またはサーバ上のＯＳ（Operating System）より当該ＬＬＤＰにより検出された隣接リソースの情報を用いることで、後述するトポロジテーブル３４に示す隣接関係情報を作成することが可能である。また、ＳＡＮ（Storage Area Network）においても、Fabric Loginや、Port Loginと呼ばれる認証処理の結果を例えばＦＣスイッチから収集することで、容易にＦＣスイッチ間、ＦＣスイッチとサーバ間、さらにＦＣスイッチとストレージ間の接続関係を把握することができ、後述するトポロジテーブル３４に示す隣接関係情報を作成することが可能である。

基盤システム管理部２３は、基盤システム配備要求を管理クライアント２から受付けた際に、基盤システムテンプレートテーブル３６にて管理される基盤システムテンプレートを用い、リソース管理部２１が管理するリソースの中から、配備要求に従う配備条件に合致したリソースを選択して、当該配備要求に従う基盤システムを、当該選択されたリソースに対して配備する。また、基盤システム管理部２３は、配備された基盤システムと、当該基盤システムにて使用されているリソースに関する情報を基盤システム配備テーブル３７にて管理する。

以下、テーブル群３０に含まれる各テーブルを説明する。

図３は、リソーステーブル３１の構成を示す。

リソーステーブル３１は、リソースプール４を構成するリソース毎に当該リソースが持つ機能性を管理するためのテーブルである。リソーステーブル３１は、リソース毎に、リソースＩＤ３０１Ａ、リソース種別３０１Ｂ、リソース構成３０１Ｃ、機能性３０１Ｄ及び物理位置３０１Ｅといった情報を保持する。図３の説明において、１つのリソースを例に取り、そのリソースを「対象リソース」と呼ぶ。

リソースＩＤ３０１Ａは、対象リソースを一意に識別するための識別子である。図３に示す一例では、便宜上、リソースＩＤとして、対象リソースの種別が容易に分かる識別子が付与されている。

リソース種別３０１Ｂは、対象リソースの種別を表す情報である。リソース構成３０１Ｃは、対象リソースのコンポーネントに関する情報である。例えば、対象リソースが標準サーバ又は高性能サーバの場合、リソース構成３０１Ｃは、対象リソースのＣＰＵ６０の種別や性能を表す情報、対象リソースのメモリ６１の性能を表す情報、及び、対象リソースのＩ／Ｏインタフェースの詳細を表す情報を含んでよい。

機能性３０１Ｄは、対象リソースが備える１以上の機能性を表す情報である。物理位置３１Ｅは、対象リソースの物理位置を表す情報（例えば当該リソースが搭載れたラック４０のＩＤ）である。なお、物理位置３０１Ｅは、ラック４０のＩＤに代えて又は加えて他種の情報を含んでもよい。

図４は、リソースグループテーブル３２の構成を示す。

リソースグループテーブル３２は、複数のリソースにより構成される機能性に関する情報を管理するためのテーブルである。リソースグループテーブル３２は、リソースグループ毎に、リソースグループＩＤ３０２Ａ、メンバリソース３０２Ｂ及び機能性３０２Ｃといった情報を保持する。本実施形態において、「リソースグループ」とは、複数のリソースの単なる集合ではなく、１以上の機能性を実現する複数のリソースの集合である。図４の説明において、１つのリソースグループを例に取り、そのリソースグループを「対象リソースグループ」と呼ぶ。

リソースグループＩＤ３０２Ａは、対象リソースグループを一意に識別するための識別子である。メンバリソース３０２Ｂは、対象リソースグループに所属すると判定されたリソースのＩＤの一覧である。機能性３０２Ｃは、対象リソースグループが実現する１以上の機能性（典型的には、対象リソースグループのメンバリソース３０２Ｂが表す複数のメンバリソースが共通的に持つ機能性）を表す。

図５は、リソースグループ定義テーブル３３の構成を示す。

リソースグループ定義テーブル３３は、リソースグループをリソースプール４から検出するための方法を表す情報が格納されたテーブルである。リソースグループ定義テーブル３３は、リソースグループ種別毎に、リソースグループ３０３Ａ、対象機能性３０３Ｂ及びメンバリソース発見方法３０３Ｃといった情報を保持する。図５の説明において、１つのリソースグループ種別を例に取り、そのリソースグループ種別を「対象リソースグループ種別」と呼ぶ。

リソースグループ種別３０３Ａは、対象リソースグループ種別を一意に識別するための識別子（例えば名称）である。

対象機能性３０３Ｂは、対象リソースグループ種別に属するリソースグループが実現する１以上の機能性を表す。

メンバリソース発見方法３０３Ｃは、対象リソースグループ種別に属するリソースグループのメンバリソースを発見する手順及び条件のうちの少なくとも１つを含んだ発見方法を表す。例えば、少なくとも１つのリソースグループ種別について、メンバリソース発見方法３０３Ｃが表す発見方法は、メンバリソースとなるリソースが持つ（実現する）機能性と、リソース間の接続構成とを含んだメンバリソース条件を含む。

図６は、トポロジテーブル３４の構成を示す。

トポロジテーブル３４は、リソースの間の接続関係を表す情報を格納するテーブルである。トポロジテーブル３４は、リンク毎に、リンクＩＤ３０４Ａ、第１リンク端ＩＤ３０４Ｂ、第２リンク端ＩＤ３０４Ｃ及びネットワーク種別３０４Ｄといった情報を保持する。図６の説明において、１つのリンクを例に取り、そのリンクを「対象リンク」と呼ぶ。

リンクＩＤ３０４Ａは、対象リンクを一意に識別する識別子である。なお、「リンク」とは、リソース間の接続であって他のリソースが介在しない接続を意味する。

第１リンク端ＩＤ３０４Ｂは、対象リンクの一端である第１リンク端の識別子である。第１リンク端ＩＤ３０４Ｂは、第１リンク端に属するリソースの識別子と、その第１リンク端に属するリソースコンポーネント（例えばポート）の識別子とのうちの少なくともリソース識別子を含む。

第２リンク端ＩＤ３０４Ｃは、対象リンクの他端である第２リンク端の識別子である。第２リンク端ＩＤ３０４Ｃは、第２リンク端に属するリソースの識別子と、その第２リンク端に属するリソースコンポーネント（例えばポート）の識別子とのうちの少なくともリソース識別子を含む。

ネットワーク種別３０４Ｄには、対象リンクを含んだネットワークの種別（例えば“ＩＰネットワーク”や“ＦＣネットワーク”）を表す。

図７は、トポロジ関連テーブル３５の構成を示す。

トポロジ関連テーブル３５は、物理位置と機能性との関係を表す情報を格納するテーブルである。トポロジ関連テーブル３５は、トポロジ関連毎に、トポロジ関連ＩＤ３０５Ａ、トポロジ位置３０５Ｂ、隣接詳細３０５Ｃ、物理位置３０５Ｄ及び機能性３０５Ｅといった情報を保持する。図７の説明において、１つのトポロジ関連を例に取り、そのトポロジ関連を「対象トポロジ関連」と呼ぶ。

トポロジ関連ＩＤ３０５Ａは、対象トポロジ関連を一意に識別するための識別子である。トポロジ位置３０５Ｂは、対象トポロジ関連に対応した隣接詳細３０５Ｃから推定される位置であって、ネットワークトポロジ上の位置を表す。隣接詳細３０５Ｃは、ネットワークトポロジ上の位置を推定するために使用される情報であって、当該位置に隣接する１以上のリソース（又はリソースコンポーネント）の識別子を含んだ情報である。物理位置３０５Ｄは、対象トポロジ関連に対応した隣接詳細３０５Ｃから推定された位置（ネットワークトポロジ上の位置）と関連付けられた物理位置、つまり、推定物理位置（例えばラック４０のＩＤ）を表す。機能性３０５Ｅは、対象トポロジ関連に対応した推定物理位置に関連付けられている機能性（例えば、物理位置３０５Ｄが表すラックに割り当てられている電源系統）を表す。

トポロジ関連テーブル３５の意義は、例えば次の通りである。すなわち、リソースプール４（例えばデータセンタ）に関し、物理位置毎に、その物理位置に対応した電源盤６及びスイッチポート等が事前に設計されている。このため、物理位置にリソース（例えば、リソースが搭載されたラック４０）が追加された場合、リソース管理プログラム２０は、そのリソースが接続されたポートのＩＤから、そのリソースが接続されたネットワーク（トポロジ位置３０５Ｂ）を特定でき、そのネットワークに対応した物理位置（物理位置３０５Ｄ）をテーブル３４から推定し、推定された物理位置に関連付けられた機能性（機能性３０５Ｅ）をテーブル３４から特定する。機能性３０５Ｅが表す機能性は、リソース（物理的なハードウェア）から取得可能な情報が表す機能性（つまりリソースが持つ機能性）とは異なり、リソースが配置され得る物理位置（典型的にはラック４０）という場所に関連付けられた機能性である。つまり、本実施形態では、リソースが配置される物理位置によって、実現可能な機能性が異なり得る。そこで、上述したトポロジ関連テーブル３５を参照することで、リソースが配置される物理位置も考慮して機能性の実現の可否を判断することができる。言い換えれば、物理位置もリソースの一種として扱うことができ、以って物理位置もリソースグループのメンバリソースとして扱うこともできる。

図８は、基盤システムテンプレートテーブル３６の構成を示す。

基盤システムテンプレートテーブル３６は、基盤システムのテンプレートに関する情報が格納されたテーブルである。基盤システムテンプレートテーブル３６は、基盤システムテンプレート（以下、基盤テンプレート）毎に、テンプレートＩＤ３０６Ａ、バージョン３０６Ｂ、メインリソース３０６Ｃ、関連リソース３０６Ｄ、リソース制約３０６Ｅ、非承認環境検証３０６Ｆ、検証実績３０６Ｇ及び自動配備プログラム３０６Ｈといった情報を保持する。図８の説明において、１つの基盤テンプレートを例に取り、その基盤テンプレートを「対象基盤テンプレート」と呼ぶ。

テンプレートＩＤ３０６Ａは、対象基盤テンプレートを一意に識別するための識別子（例えば名称）である。バージョン３０６Ｂは、対象基盤テンプレートのバージョンを表す。

メインリソース３０６Ｃは、対象基盤テンプレートに属するメインリソースとしてのリソース毎に、そのリソースの種別（例えば標準サーバ又は高性能サーバ）を表す情報と、そのリソースに適用すべきファームウェアのバージョンを表す情報とを含む。ここで、「メインリソース」とは、典型的には、基盤システムソフトウェアがインストールされるサーバであるが、これに限定するものではない。

関連リソース３０６Ｄは、対象基盤テンプレートに属する関連リソースとしてのリソース毎に、そのリソースの種別（例えばＦＣスイッチ）を表す情報と、そのリソースに適用すべきファームウェアのバージョンを表す情報と、そのファームウェアバージョンが適用必須か否かのフラグである適用フラグとを含む。ここで、「関連リソース」とは、メインリソースの場所及び接続関係により必然的に使用されるリソース、例えば、メインリソースにネットワークケーブルを介して接続されているイーサネットスイッチやＦＣスイッチであるが、これに限定するものではない。また、適用フラグとしては、適用必須を示す値“strict”と、適用不要を示す値“non−strict”がある。

リソース制約３０６Ｅは、対象基盤テンプレートに属するメインリソース及び関連リソースに関する選択条件（制約）を表す。リソース制約３０６Ｅが表す選択条件は、例えば、対象基盤テンプレートに関連付けられた機能性（つまり、当該テンプレートに対応した基盤システムに必要とされる機能性）を含む。

非承認環境検証３０６Ｆは、対象基盤テンプレートに関連付けられた非承認環境検証プログラムに関する情報（例えば、プログラム又はそのＩＤ）である。非承認環境検証プログラムは、次の（ａ）及び（ｂ）の場合に、現在のファームウェアバージョンが対象基盤テンプレートの要件を満たすか否かチェックするために実行されるプログラムである。
（ａ）関連リソース３０６Ｄが表すリソースが見つかったが、見つかったリソースのファームウェアバージョンが、関連リソース３０６Ｄが表すファームウェアバージョンと合致しない。
（ｂ）関連リソース３０６Ｄが表す適否フラグが示す値が、“non-strict”である。

検証実績３０６Ｇは、対象基盤テンプレートに対応する非承認環境検証３０６Ｆが表す非承認環境検証プログラムを過去に実行した結果を表す情報（例えば、検証が合格となったファームウェアのバージョンを表す情報、及び、当該検証プログラム実行時のログデータ（又はログデータへのポインタ））である。

自動配備プログラム３０６Ｈは、基盤システムソフトウェアのインストール、関連するファームウェアの適用、および各種設定の適用を実行する配備プログラムに関する情報（例えばプログラム又はＩＤ）である。

図９は、基盤システム配備テーブル３７の構成を示す。

基盤システム配備テーブル３７は、配備された基盤システムに関する情報が格納されたテーブルである。基盤システム配備テーブル３７は、基盤システム毎に、配備ＩＤ３０７Ａ、テンプレートＩＤ３０７Ｂ、配備バージョン３０７Ｃ、配備メインリソース３０７Ｄ及び配備関連リソース３０７Ｅといった情報を保持する。図９の説明において、１つの基盤システムを例に取り、その基盤システムを「対象基盤システム」と呼ぶ。

配備ＩＤ３０７Ａは、配備された対象基盤システムを一意に識別するための識別子である。テンプレートＩＤ３０７Ｂは、対象基盤システムの配備に適用された基盤テンプレートの識別子である。配備バージョン３０７Ｃは、その適用された基盤テンプレートのバージョンを表す。

配備メインリソース３０７Ｄは、配備された基盤システムに含まれているメインリソース毎に、メインリソースの識別子とそのメインリソースに適用されているファームウェアバージョンを表す情報とを含む。

配備関連リソース３０７Ｅは、配備された基盤システムに含まれている関連リソース毎に、関連リソースの識別子とその関連リソースに適用されているファームウェアバージョンを表す情報とを含む。

次に、本実施形態に係るリソースグループ管理方式について説明する。

サーバ、ストレージ及びネットワークといったリソースに関する情報がリソーステーブル３１に保持される。リソースがリソースプール４に追加されると、リソース管理プログラム２０は、追加リソースを検知し（例えば、リソースプール４から追加リソースに関する情報を受信し）、検知したリソースに関する情報３０１Ａ〜３０１Ｅをリソーステーブル３１に追加する。また、リソース管理プログラム２０は、追加リソースに関する情報３０１Ａ〜３０１Ｅと、リソースグループ種別毎の対象機能性３０３Ｂ及びメンバリソース発見方法３０３Ｃとを基に、追加リソースを含んだ１又は複数のリソースの組合せにより実現される機能性を持ったリソースグループの有無を検知する。リソース管理プログラム２０は、そのようなリソースグループを検知した場合、検知したリソースグループに関する情報３０２Ａ〜３０２Ｃをリソースグループテーブル３２に格納する。さらに、リソース管理プログラム２０は、管理クライアント２から或るユーザについて基盤システム配備要求を受け付けると、配備要求に従う配備条件に合致したリソースを選択して配備する。

以下、本実施形態に係る検知処理について説明する。なお、検知処理実行前の状態及び構成は、図１及び図３〜図９に示す状態及び構成とする。ここで、リソースグループ定義テーブル３３（図５）、トポロジ関連テーブル３５（図７）、及び基盤システムテンプレートテーブル３６（図８）は、例えば管理者によって、事前に作成されているものとする。リソーステーブル３１（図３）、リソースグループテーブル３２（図４）、トポロジテーブル３４（図６）及び基盤システム配備テーブル３７（図９）は、上述のリソースグループ管理方式により生成されてもよいし、例えば管理者により事前に格納されていてもよい。

このような図１及び図３〜図９に示す状態及び構成において、図１０に示すように、下記が行われたとする。
・ラック３を増設すること。
・ラック３内に各種リソースを追加すること。
・電源系統の接続（具体的には、Ａ系ＰＤＵ３を電源盤３に接続し、Ｂ系ＰＤＵ３を電源盤４に接続すること。）
・ラック３内の高性能イーサネットスイッチ２の任意のポートを、高性能コアイーサネットスイッチ１のポート３（不図示）及び高性能コアイーサネットスイッチ２のポート３（不図示）にネットワークケーブルを用いて接続すること。

なお、ラック３内のリソースは、管理ネットワーク５に接続され、管理サーバ３と通信可能であるものとする。

さらに、ラック３内の高性能イーサネットスイッチ２のメモリ（不図示）上にて、ラック３の管理機能を提供するラック管理プログラム４９が実行されているものとする。ラック管理プログラム４９は、本実施形態では、高性能イーサネットスイッチ２上で動作しているが、これに限るものではなく、例えば高性能サーバ３のメモリ上で動作していてもよい。ラック管理プログラム４９は、例えば、ラック３の中に工場出荷時に組み込まれていてもよく、ラック３に対して電源が投入されたときに起動してよい。ラック管理プログラム４９は、ラック４０毎に存在してよい。

また、管理サーバ３及びラック３内の全てのリソースは、ＩＰ（Internet Protocol）アドレスなどの管理通信に必要な設定が、管理用通信に用いるＩ／Ｏインターフェースに設定してあるものとする。

図１１及び図１２は、検知処理の流れを示す。以下の説明では、図１０の例示の通り、ラック３が増設されたものとする。検知処理は、リソースの管理に関する処理であるリソース管理処理の一例である。リソースは、リソースグループのメンバリソースであることもあれば、リソースグループに属さない単独のリソースであることもある。

ラック管理プログラム４９が、ラック３にネットワークケーブルが接続されたことを検知すると（ラック３がネットワークに接続されたことを検知すると）、リソース管理プログラム２０に、ラック３の増設を通知する（Ｓ１）。

次に、リソース管理プログラム２０は、ラック３の増設の通知を受けると（Ｓ２）、ラック３内のリソースに関する情報をラック管理プログラム４９に要求する（Ｓ３）。

ラック管理プログラム４９は、その要求に応答して、ラック３内のリソースに関する情報をリソース管理プログラム２０に送信する（Ｓ４）。Ｓ４にて送信される情報は、後述する図１３Ａに記載の情報と同様の内容であるとする。

リソース管理プログラム２０は、ラック管理プログラム４９から、ラック３内のリソース３に関する情報を受信し、その情報に従う情報（例えば、受信した情報と、その情報に基づき付与された情報とのうちの少なくとも一方）３０１Ａ〜３０１Ｅを、リソーステーブル３１に追加し、且つ、ラック管理プログラム４９に、隣接詳細に関する情報を要求する（Ｓ５）。ここで、図１３Ａは、Ｓ５にてリソーステーブル３１にラック３内のリソースに関する情報３０１Ａ〜３０１Ｄが追加された状態を示している。図１３Ａによれば、物理位置３０１Ｅが格納されておらず、且つ、リソース“Ａ系ＰＤＵ３”および“Ｂ系ＢＤＵ３”に関する機能性３０１Ｄも格納されていない。なぜなら、Ｓ４にてラック管理プログラム４９ａから送信される情報（ラック３内のリソースに関する情報）は、ラック３（又はリソース）の出荷時のラック管理プログラム４９に登録されている情報であり、通常、出荷時には、ラック３の設置場所、及び、ＰＤＵが接続される電源系統まではわからず、故に、出荷時のラック管理プログラム４９が、物理位置及び電源系統に関する情報を保持していないためである。

次に、ラック管理プログラム４９は、上記ＬＬＤＰ等の既に知られている手法を用い、ラック３の中及び外とのリンクを検知し、検知したリンクに関する情報であるリンク情報をリソース管理プログラム２０に送信する（Ｓ６）。

リソース管理プログラム２０は、リンク情報を受信し、受信した情報が表すリンクに関する情報３０４Ａ〜３０４Ｄを、トポロジテーブル３４に格納する。トポロジテーブル３４に格納された情報の一例を図１４に示す。さらに、リソース管理プログラム２０は、トポロジ関連テーブル３５（図７）の隣接詳細３０５Ｃと、トポロジテーブル３４に格納した情報３０４Ａ〜３０４Ｄ（ラック３に関わるリンクに関する情報）を比較し、一致するレコードを検索する（Ｓ７）。

一致するレコードが見つかった場合（Ｓ８：Ｙ）、Ｓ１０に進む。一致するレコードが見つからなかった場合（Ｓ８：Ｎ）、想定外の接続があったことをemail等の手段を用いて管理者に通知し、処理を終了する（Ｓ９）。

Ｓ１０では、リソース管理プログラム２０は、Ｓ７で見つかったレコード（トポロジ関連テーブル３５のレコード）に格納されている情報を用いて、リソーステーブル３１内のレコードに格納されている情報（Ｓ５で追加された、ラック３内のレコードに関する情報）を更新する。より具体的には、例えば、トポロジ関連テーブル３５から、トポロジ関連ＩＤ３０５Ａ“ＲＬ３”を含んだレコードがＳ７にて見つかったとする。そのレコード内の隣接詳細３０５Ｃが、ラック３内のリソースに関する情報３０１Ａ〜３０１Ｄに適合したためである。リソース管理プログラム２０は、見つかったレコード内の物理位置３０５Ｄ（ここでは“ラック３”）を、リソーステーブル３１内のレコード（ラック３内のリソースに対応したレコード）に、物理位置３０１Ｅとしてコピーする。さらに、リソース管理プログラム２０は、トポロジ関連ＩＤ３０５Ａ“ＲＬ３”を含んだレコード内の機能性３０５Ｅより、Ａ系の“電源系統３”及びＢ系の“電源系統４”を、リソースＩＤ３０１Ａ “Ａ系ＰＤＵ３”を含んだレコード、及び、リソースＩＤ３０１Ａ“Ｂ系ＰＤＵ３”を含んだレコードに、それぞれ、機能性３０１Ｄとして格納する（図１３Ｂ）。

次に、リソース管理プログラム２０は、リソースグループ定義テーブル３３のレコードを先頭から順に抽出し（Ｓ１１）、ラック３内のリソースのうちの、当該抽出したレコード内の対象機能性３０３Ｂと同じ機能性３０１Ｄに対応したリソースを、リソーステーブル３１（図３及び図１３Ｂ）から検索する（Ｓ１２）。

当該同じ機能性３０１Ｄに対応したリソースが見つかった場合（Ｓ１３：Ｙ）、Ｓ１４に進む。そのようなリソースが見つからなかった場合（Ｓ１３：Ｎ）、Ｓ１８に進む。

Ｓ１４では、リソース管理プログラム２０は、Ｓ１１で抽出されたレコード内のメンバリソース発見方法３０３Ｃが表す発見方法で、見つかったリソース以外のメンバリソースを探索する（Ｓ１４）。

ここで、具体的な探索例を、リソースグループＩＤ３０３Ａ“ＦＣ ＳＡＮファブリック”を含んだレコード（図５参照）を例に取り説明する。当該レコードは、対象機能性３０３Ｂ “ＦＣ ＳＡＮ”、及び、メンバリソース発見方法３０３Ｃ“対象機能性をもつリソース群で、相互のＦＣネットワーク隣接関係あり”を含んでいる。そのため、リソース管理プログラム２０は、Ｓ１２にて、図１３Ｂに示すテーブル３１（ラック３内のリソース）の中から、機能性３０１Ｄ“ＦＣ ＳＡＮ”に対応したリソース“高性能サーバ３”、“高性能サーバ４”、“ＦＣストレージ３”及び“ＦＣスイッチ３”を特定する。次に、リソース管理プログラム２０は、それらのリソースの各々に対して、トポロジテーブル３４を用い、ＦＣネットワークにおいて隣接するリソースを検索する。例えば“高性能サーバ３”に関しては、隣接リソースとして、“ＦＣスイッチ３”が検知される。さらに、“ＦＣスイッチ３”に対して、隣接リソースとして、“高性能サーバ４”及び“ＦＣストレージ３”が検知される。以上により、“高性能サーバ３”、“高性能サーバ４”、“ＦＣストレージ３”及び“ＦＣスイッチ３”が、メンバリソース発見方法３０３Ｃで記載の“対象機能性をもつリソース群で、相互のＦＣネットワーク隣接関係あり”により発見されたリソースグループのメンバリソースの一覧である。

次に、リソース管理プログラム２０は、Ｓ１４にて発見された全てのメンバリソースを含んだメンバリソース３０２Ｂを有するレコードがリソースグループテーブル３２にあるか否かを判定する。判定結果が真の場合（Ｓ１５：Ｙ）、Ｓ１７へ進む。判定結果が偽の場合（Ｓ１５：Ｎ）、Ｓ１６に進む。

Ｓ１６では、リソース管理プログラム２０は、リソースグループテーブル３２に対し、新規レコードを追加する。リソース管理プログラム２０は、新規レコードに、リソースグループＩＤ３０２Ａとして、一意に識別可能な識別子を格納し、メンバリソース３０２Ｂとして、Ｓ１４にて発見された全てのメンバリソースのＩＤを格納し、機能性３０２Ｃとして、当該探索に使用したレコード（リソースグループ定義テーブル３３からＳ１１で抽出されたレコード）内のリソースグループ種別３０３Ａの値を格納する。

Ｓ１７では、リソース管理プログラム２０は、Ｓ１５（Ｓ１５：Ｙ）にて見つかったレコード内のメンバリソース３０２Ｂに対し、Ｓ１４で発見したメンバリソースのＩＤを追加する。

Ｓ１８では、リソース管理プログラム２０は、Ｓ１２で検索された全てのリソースに対して実行がされたか否かを判定する。判定結果が偽の場合（Ｓ１８：Ｎ）、Ｓ１４に戻り、残りのリソースに対して同様の処理が実行される。一方、判定結果が真の場合（Ｓ１８：Ｙ）、Ｓ１９に進む。

Ｓ１９では、リソース管理プログラム２０は、全てのリソースグループ定義に対してＳ１１〜Ｓ１８の処理を実行したか判定する。判定結果が真の場合（Ｓ１９：Ｙ）、処理フローが終了する。判定結果が偽の場合（Ｓ１９：Ｎ）、次のリソースグループ定義に対して、Ｓ１１が実行される。

図１５は、ラック３の増設についてＳ１〜Ｓ１９を実行した結果としての更新後リソースグループテーブル３２の例を示す。図１５に示すリソースグループテーブル３２のデータの中で、下線で示しているのが、本実施形態に係るリソースグループ管理方式による検知処理を実施した結果、検知処理実施前のリソースグループテーブル３２（図４）から更新されたデータである。図１５に示すように、“ＧＰＧＰＵクラスタ１”リソースグループには、高性能サーバ及び高性能サーバ４がメンバリソース３０２Ｂに追加され、また、“ＩＰ ＱｏＳ転送ネットワーク１”リソースグループには、高性能イーサネットスイッチ２、高性能サーバ３及び高性能サーバ４がメンバリソース３０２Ｂに追加され、さらに、“ＦＣ ＳＡＮファブリック２”、“電源系統３”及び“電源系統４”が新たにリソースグループテーブル３２に追加されている。

図１６は、本実施形態に係る配備処理の流れを示す。配備処理は、基盤システムの構築に関する処理であるシステム構築処理の一例である。

リソース管理プログラム２０は、管理クライアント２から基盤システム配備要求を受信する（Ｓ３１）。この基盤システム配備要求には、テンプレートＩＤ及びバージョンと、サーバ台数とが少なくとも指定されているものとする。

なお、この配備処理の説明では、上述の検知処理実施後の状態及び構成が採用されるとする。すなわち、図５、図７、図８、図９、図１０、図１３Ｂ、図１４及び図１５に示す構成及び状態が採用されるとする。また、Ｓ３１にて受信した基盤システム配備要求には、テンプレートＩＤ“高性能分析用サーバシステム”、バージョン“００１”及びサーバ台数“２”が配備条件として指定されているとする。

次に、リソース管理プログラム２０は、基盤システムテンプレートテーブル３６から、受信した配備要求で指定されているテンプレートＩＤ及びバージョンに合致するレコードを検索する（Ｓ３２）。ここでは、テンプレートＩＤ３０６Ａ“高性能分析用サーバシステム”及びバージョン３０６Ｂ“００１”を含んだレコード（言い換えれば、当該レコードに対応した基盤テンプレート）が見つかったとする。

次に、Ｓ３３にて、リソース管理プログラム２０は、見つかったレコード内のメインリソース３０６Ｃに記載の選択可能なメインリソースの種別を検索キーとして、リソーステーブル３１より、リソース種別３０１Ｂが当該種別と合致するリソースを検索する。また、Ｓ３３にて、リソース管理プログラム２０は、その検索により見つかったリソースのうち、基盤システム配備テーブル３７の配備メインリソース３０７Ｄに含まれていないリソース、つまり使われていないリソースを抽出する。

本実施形態では、当該見つかった基盤テンプレートのメインリソース３０６Ｃは“高性能サーバ（ｆｉｒｍｗａｒｅ：００−０２）”であるため、リソーステーブル３１より、高性能サーバ１、高性能サーバ２、高性能サーバ３及び高性能サーバ４が抽出される。さらに、図９に示す基盤システム配備テーブル３７より、高性能サーバ１が既に使用されているため、リソース管理プログラム２０は、Ｓ３３の処理結果として、高性能サーバ１以外の高性能サーバ、すなわち、高性能サーバ２、高性能サーバ３及び高性能サーバ４を候補として抽出する。

次に、Ｓ３３の結果、候補となる未使用リソースが見つかった場合（Ｓ３４：Ｙ）、Ｓ３５に進む。見つからなかった場合（Ｓ３４：Ｎ）、Ｓ３７に進む。

Ｓ３７では、リソース管理プログラム２０は、Ｓ３１で受信した配備要求に対応したユーザについて、配備に失敗した事を通知する。

Ｓ３５では、リソース管理プログラム２０は、見つかったリソースが、当該見つかった基盤テンプレートに対応するリソース制約３０６Ｅを満たしているか否かを、見つかったリソースに対応する機能性３０１Ｄ、及び、見つかったリソースを含んだリソースグループに対応する機能性３０２Ｃを用いて判定する。具体的には、例えば、リソース管理プログラム２０は、見つかったリソースに対応する機能性３０１Ｄに、当該リソース制約３０６Ｅを満たす機能性が存在するか否か判定する。判定結果が偽の場合、リソース管理プログラム２０は、当該見つかったリソースを含むリソースグループに対応した機能性３０２Ｃに、当該リソース制約３０６Ｅを満たす機能性が存在するか否か判定する。

本実施形態では、当該見つかった基盤テンプレートに対応するリソース制約３０６Ｅは“ＧＰＧＰＵクラスタ”であるため、図１５に示すリソースグループテーブル３２の中で、“ＧＰＧＰＵクラスタ１”のみが、検索されたリソースのうち少なくとも一つを含み、かつ当該リソース制約３０６Ｅを満たしている。

Ｓ３８では、リソース管理プログラム２０は、Ｓ３５にてリソース制約３０６Ｅを用いて絞り込まれたリソース候補の中で、Ｓ３１で受信した配備要求で指定されているサーバ台数分のリソースの組合せを全て作成する。さらに、リソース管理プログラム２０は、Ｓ３５にてリソース制約３０６Ｅを満たすと判定されたリソースグループに当該リソースの組合せに属するリソースが全て含まれている場合は、当該リソースの組合せを最終候補として選出する。具体的には、例えば、リソース管理プログラム２０は、同一のリソースグループ種別“FC SANファブリック”に属する２以上のリソースグループがある場合、２以上のリソースグループからリソースを選出するのではなく、１つのリソースグループ（同一リソースグループ）からリソースを選出する。

Ｓ３８にて最終候補が見つからなかった場合（Ｓ３９：Ｎ）、Ｓ３７に進み、見つかった場合（Ｓ３９：Ｙ）、Ｓ４０に進む。

Ｓ４０にて、リソース管理プログラム２０は、上記見つかった基盤テンプレートに対応した関連リソース３０６Ｄに含まれているリソース種別及びファームウェアバージョンを抽出する。Ｓ４０で取得されたファームウェアバージョンを、以下、「要求ファームウェアバージョン」と言う。

Ｓ４１にて、リソース管理プログラム２０は、当該最終候補のリソースと隣接しているリソース（当該最終候補のリソースとリンク経由で接続されているリソース）を、トポロジテーブル３４から検索し、当該隣接しているリソースのファームウェアバージョンを確認する。リソース管理プログラム２０は、当該隣接しているリソースのファームウェアバージョンを、当該リソースにアクセスすることにより取得してもよい。また、トポロジテーブル３４の作成のために収集したリソース情報に、リソースのファームウェアバージョンが含まれていてもよく、そのファームウェアバージョンが、トポロジテーブル３４（又は別のテーブル）に登録されてもよく、トポロジテーブル３４から取得されてもよい。リソース管理プログラム２０は、Ｓ４０にて抽出したリソース種別とマッチしたリソースが隣接リソースとして存在する場合、さらに、その隣接リソースのファームウェアバージョンが要求ファームウェアバージョンと一致するか否か判定する。判定結果が真の場合（Ｓ４１：Ｙ）、Ｓ４７に進む。判定結果が偽の場合（Ｓ４１：Ｎ）、Ｓ４２に進む。

Ｓ４２では、リソース管理プログラム２０は、要求ファームウェアバージョンが“strict”か“non-strict”か確認する。要求ファームウェアバージョンが“strict”の場合、Ｓ３７に進む。要求ファームウェアバージョンが“non-strict”の場合、リソース管理プログラム２０は、当該隣接リソースのファームウェアバージョンが、当該基盤テンプレートの検証実績３０６Ｇ（例えば、過去に既に検証済みのファームウェアバージョンを表す情報）に適合するか否か判定する（Ｓ４３）。判定結果が真の場合（Ｓ４３：Ｙ）、Ｓ４７に進む。判定結果が偽の場合（Ｓ４３：Ｎ）、Ｓ４４に進む。

Ｓ４４では、リソース管理プログラム２０は、当該基盤テンプレートに対応する非承認環境検証３０６Ｆが表す検証プログラムを、当該隣接リソース（要求ファームウェアバージョンに一致しないバージョンのファームウェアを持つ隣接リソース（関連リソース））に対して実行する。検証プログラムの実行結果がＮＧの場合（Ｓ４５：Ｎ）、Ｓ３７に進む。検証プログラムの実行結果がＯＫの場合（Ｓ４５：Ｙ）、Ｓ４６に進む。

Ｓ４６では、リソース管理プログラム２０は、当該隣接リソース（関連リソース）の現在のファームウェアバージョンを表す情報と、当該隣接リソースを表す情報（例えばリソースＩＤ）とを含んだ情報を、当該基盤テンプレートに対応した検証実績３０６Ｇに追加する。これにより、当該隣接リソース（関連リソース）の現在のファームウェアバージョンが、検証済みのファームウェアバージョンとして、登録される。検証実績３０６Ｇは、実行結果を表すログに関する情報も含んでもよい。

Ｓ４７では、リソース管理プログラム２０は、当該基盤テンプレートに対応した自動配備プログラム３０６Ｈが表す配備プログラムを実行することで、当該最終候補のリソースに対して基盤システムソフトウェアの配備を実行する。

図１６に示した配備処理によれば、例えば以下の通りである。

リソース管理プログラム２０は、配備要求に適合する基盤テンプレートを探す。リソース管理プログラム２０は、見つかった基盤テンプレート（以下、該当テンプレート）について、下記の（Ａ）乃至（Ｄ）の処理を実行する。
（Ａ）該当テンプレートに対応するリソース制約３０６Ｅ（例えば機能性）を満たしているリソース及びリソースグループである候補リソースを絞り込む、
（Ｂ）絞り込まれた候補リソースの中から、基盤システムソフトウェアのインストール先（デプロイ先）となる空きサーバを検索する（空きサーバは、該当テンプレートに対応するメインリソース３０６Ｃが表すリソース種別に該当するサーバのうちの未使用のサーバ）、
（Ｃ）絞り込まれた候補リソースに隣接するリソースであって、該当テンプレートに対応する関連リソース３０６Ｄが表すリソース種別に属するリソースを検索する、
（Ｄ）（Ｃ）で見つかったリソースのファームウェアバージョンが要求ファームウェアバージョン＿（該当テンプレートに対応する関連リソース３０６Ｄが表すファームウェアバージョン）に一致するか否か判定する、
（Ｅ）（Ｄ）の判定結果が偽の場合、要求ファームウェアバージョンが“non-strict”か否か判定する、
（Ｆ）（Ｅ）の判定結果が真の場合、該当テンプレートに対応する非承認環境検証３０６Ｆが表す検証プログラムを、当該隣接リソース（要求ファームウェアバージョンに一致しないバージョンのファームウェアを持つ隣接リソース（関連リソース））に対して実行する。
（Ｇ）（Ｆ）の実行結果がＯＫの場合、当該隣接リソースの現在のファームウェアバージョンを表す情報を含んだ情報を、該当テンプレートに対応した検証実績３０６Ｇに追加する。

処理（Ｄ）乃至（Ｇ）は、隣接リソース（関連リソース）に代えて又は加えて、メインリソースについても行われてもよい。メインリソース３０６Ｃも、メインリソースとしてのサーバ毎にファームウェアバージョン（“strict”又は“non-strict”を含んだ要求ファームウェアバージョン）を含んでもよい。

上記処理のうちの処理（Ｅ）乃至（Ｇ）の意義は、例えば次の通りである。すなわち、“strict”に対応したリソース種別については、該当テンプレートの提供側での検証により保証されているファームウェアバージョン以外のバージョンのファームウェアの使用が禁止される。しかし、ユーザ側での柔軟なリソース使用が望まれること（例えば、該当テンプレートの提供側に許可を求めることなく特定のリソースを使用することが望まれること）が考えられる。或いは、第１及び第２の基盤システムを含んだ複数の基盤システムのいずれの要素となることが可能な共通リソース（典型的には、ネットワークスイッチのようなスイッチ）も考えられ、且つ、その共通のリソースのファームウェアバージョンは、第１の基盤システムのテンプレートに対応したファームウェアバージョンには適合するものの、第２の基盤システムのテンプレートに対応したファームウェアバージョンには適合しないといったことも考えられる。そこで、或るリソースの或るファームウェアバージョンについては、“non-strict”が採用され得る。“non-strict”とは、要求ファームウェアバージョンとは異なるバージョンのファームウェアの採用を許可し得ることを意味する。具体的には、該当テンプレートに対応する検証プログラムの実行結果がＯＫ（検証成功）の場合に（言い換えれば、テンプレート提供側ではなくユーザ側での検証結果がＯＫの場合に）、その異なるバージョンのファームウェアの採用が許可され、基盤システム配備テーブル３７に、採用されたファームウェアバージョン等の検証実績３０６Ｇが登録される。

なお、処理（Ｅ）の判定結果が真の場合、リソース管理プログラム２０は、該当テンプレートに対応する検証実績３０６Ｇが検証ＯＫ（検証プログラムの実行結果がＯＫであった実績を示す）か否かを判定してもよい。判定結果が偽の場合、リソース管理プログラム２０は、処理（Ｆ）を実行してもよい。

また、“non-strict”及び“strict”といったフラグは必ずしもなくてもよい（例えば、全てのリソースについてファームウェアバージョンは“non-strict”であってもよい）。

以上が、本実施形態の説明である。

本実施形態によれば、個々のリソースに加えて、機能性を提供する複数のリソースの組み合せである「リソースグループ」という概念が導入される。そして、リソースグループ種別毎に、リソースグループに関連付けられている機能性を提供するための条件として、発見方法３０３Ｃが定義されている。発見方法３０３Ｃに従い見つかったリソースを組み合わせれば、対応する対象機能性３０３Ｂが表す機能性を提供することができる。例えば、高品質なネットワーク通信を実現する通信技術として、IEEE（The Institute of Electrical and Electronics Engineers， Inc．）の８０２．１Ｑｂｂ仕様として定義されているＰＦＣ（Priority-based Flow Control）がある。上述した実施形態によれば、機能性としてＰＦＣをサポートしているサーバ間リソースを含んだ複数のリソースにより構成され機能性としてＰＦＣを実現できるリソースグループの構築が可能である。

また、本実施形態によれば、発見方法３０３Ｃに沿ってリソースを見つけるために、トポロジが参照される。なお、トポロジを参照することは、メンバリソースの発見のための一方法に過ぎず、発見方法３０３Ｃの定義によっては、トポロジの参照は不要となり得る。

また、本実施形態によれば、トポロジに基づいて検出されたネットワーク位置（トポロジ上の位置）から推定される物理位置に対して、機能性３０５Ｅが関連付けられている。発見方法３０３Ｃに従いトポロジを参照した場合、トポロジについて関連付けられている機能性３０５Ｅを、リソースグループの機能性３０２Ｃとして関連付けることができる。

また、本実施形態によれば、第１及び第２の基盤システムを含んだ複数の基盤システムのいずれの要素となることが可能な共通リソースについて、第１の基盤システムのテンプレートに対応したファームウェアバージョンには適合するものの、第２の基盤システムのテンプレートに対応したファームウェアバージョンには適合しないといったことも考えられる。そのような場合であっても、第２の基盤システムのテンプレートについて共通リソースに対応した要求ファームウェアバージョンが“non-strict”であれば（更に、そのテンプレートに対応した検証プログラムの実行結果がＯＫとなれば）、共通リソースを、第１の基盤システムの要素としてだけでなく第２の基盤システムの要素として配備することが可能である。

以上、本発明の一実施形態を説明したが、本発明は、この実施形態に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

１：管理システム

Claims (7)

1. リソースプールに接続された１以上のインタフェースを含んだインタフェース部と、
   前記インタフェース部に接続された１以上のプロセッサを含んだプロセッサ部と
   を有し、
   前記プロセッサ部は、リソース管理処理と、システム構築処理とを実行し、
   前記リソース管理処理は、機能性を実現する２以上のリソースの組合せをリソースグループとして管理することを含み、
   前記システム構築処理は、要求される機能性と、前記リソースプールに含まれているリソース毎の機能性との他に、管理されているリソースグループ毎の機能性を用いて、前記リソースプールから、前記要求される機能性を実現するシステムである基盤システムの構成要素とされる１又は２以上のリソースを選択することを含み、
   前記システム構築処理において、前記選択される１又は２以上のリソースのうちの特定のリソースのファームウェアバージョンが、要求されるファームウェアバージョンに一致しないが、ファームウェア検証プログラムの実行結果として検証成功が得られたファームウェアバージョンである、
   管理システム。
2. 前記システム構築処理は、
   それぞれが要求される機能性、要求されるリソース種別及び要求されるファームウェアバージョンが関連付けられている複数の基盤システムテンプレートから１つの基盤システムテンプレートを選択することと、
   前記選択された基盤システムテンプレートに関連付けられている要求されるファームウェアバージョンに、その基盤システムテンプレートに関連付けられているリソース種別に属する前記特定のリソースのファームウェアバージョンが一致しているか否かを判定することと、
   その判定結果が否定の場合、前記特定のリソースについて前記ファームウェア検証プログラムを実行することと、
   を含む、
   請求項１記載の管理システム。
3. 前記システム構築処理は、更に、
   前記ファームウェア検証プログラムの実行結果として検証成功が得られた場合、前記選択された基盤システムテンプレートに、前記特定のリソースのファームウェアバージョンを表す情報を含んだ情報を検証実績として関連付ける、
   請求項１記載の管理システム。
4. 前記ファームウェア検証プログラムは、前記要求されるファームウェアバージョンと一致することが厳密に求められていないことを意味する値が関連付けられている場合に実行される、
   請求項１記載の管理システム。
5. 前記リソースプールは、複数種類のリソースを含む複数のリソースを含み、
   前記複数のリソースは、複数のサーバと１以上のスイッチとを含み、
   前記１以上のスイッチの各々に、前記複数のサーバのうちの１以上のサーバが接続され、
   前記特定のリソースは、前記１以上のスイッチのうちの少なくとも１つである、
   請求項１記載の管理システム。
6. リソースプールと、
   前記リソースプールに接続された管理システムと
   を有し、
   前記管理システムは、リソース管理処理と、システム構築処理とを実行し、
   前記リソース管理処理は、機能性を実現する２以上のリソースの組合せをリソースグループとして管理することを含み、
   前記システム構築処理は、要求される機能性と、前記リソースプールに含まれているリソース毎の機能性との他に、管理されているリソースグループ毎の機能性を用いて、前記リソースプールから、前記要求される機能性を実現するシステムである基盤システムの構成要素とされる１又は２以上のリソースを選択することを含み、
   前記システム構築処理において、前記選択される１又は２以上のリソースのうちの特定のリソースのファームウェアバージョンが、要求されるファームウェアバージョンに一致しないが、ファームウェア検証プログラムの実行結果として検証成功が得られたファームウェアバージョンである、
   情報システム。
7. リソースプールに接続された１以上のインタフェースを含んだインタフェース部と、
   前記インタフェース部に接続された１以上のプロセッサを含んだプロセッサ部と
   を有する管理システムによる管理方法であって、
   前記プロセッサ部は、リソース管理処理と、システム構築処理とを実行し、
   前記リソース管理処理は、機能性を実現する２以上のリソースの組合せをリソースグループとして管理することを含み、
   前記システム構築処理は、要求される機能性と、リソースプールに含まれているリソース毎の機能性との他に、管理されているリソースグループ毎の機能性を用いて、前記リソースプールから、前記要求される機能性を実現するシステムである基盤システムの構成要素とされる１又は２以上のリソースを選択することを含み、
   前記システム構築処理において、前記選択される１又は２以上のリソースのうちの特定のリソースのファームウェアバージョンが、要求されるファームウェアバージョンに一致しないが、ファームウェア検証プログラムの実行結果として検証成功が得られたファームウェアバージョンである、
   管理方法。