JP5507136B2 - 管理装置及び方法並びに計算機システム - Google Patents

Description

本発明は、管理装置及び方法並びに計算機システムに関し、例えばリソースを管理する管理サーバ及び当該管理サーバを備える計算機システムに適用して好適なものである。

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

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

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

なお、下記特許文献１には、業務用アプリケーションが割り当てられていないコンピュータをプールしておき、リソースが不足している業務アプリケーションに対してプールしておいたコンピュータを追加するシステムにおいて、各コンピュータのスペックを管理すると共に、業務アプリケーションごとに、コンピュータのスペックと当該スペックでその業務アプリケーションを稼働させた場合のリクエスト処理数との関係を管理し、これらの情報に基づいて、リソースが不足している業務アプリケーションに追加するコンピュータを決定する技術が開示されている。

特開２００６−３０６９１号公報

ところで、通常の計算機システムでは、プールされるリソースの質（例えばそのリソースに搭載された機能）が均一でないことが多い。このような状況のもと、従来のようにユーザからの性能要件（スペック等）のみに基づいてそのユーザに割り当てるリソースを選択すると、ユーザの使用目的に合致したリソースを提供できない場合があった。

具体的には、ユーザが重要なアプリケーションの稼働を予定しているにも拘らず、リソース管理者により割り当てられたリソースに可用性（availability）を高める機能が搭載されていないために、リソースの障害発生時などに重要なアプリケーションによる処理の継続を維持できないという事態が生じる場合があった。

このことは、上述の特許文献１に開示された技術についても、同様のことが言える。

本発明は以上の点を考慮してなされたもので、プールされるリソースが均質でない計算機システムにおいて、ユーザの要求に合致したリソースを割り当て得る、信頼性の高い管理装置及び方法並びに計算機システムを提案しようとするものである。

かかる課題を解決するため本発明においては、複数の計算機リソースを管理し、計算機リソースの割り当てを要求するリソース要求に応じて、要求された計算機リソースをユーザに割り当てる管理装置において、前記リソース要求には、割り当てを要求する前記計算機リソースの性能要件及び機能要件が含まれ、前記リソース要求において前記機能要件として要求される各機能にそれぞれ対応付けて、当該機能を構成するために必要となる計算機リソースの種別及び当該計算機リソースの必要数を構成条件として保持すると共に、各前記計算機リソースが備える性能及び機能をリソース情報として保持するメモリと、前記メモリに保持された前記構成条件及び前記リソース情報に基づいて、前記リソース要求において指定された前記機能要件を満たし、かつ当該リソース要求において指定された前記性能要件を満たす計算機リソースを前記複数の計算機リソースの中から検索し、検索結果に基づいて前記ユーザに割り当てる計算機リソースを決定する検索部と、該検索部により決定された計算機リソースを前記ユーザに割り当てる割当て部とを設けるようにした。

また本発明においては、複数の計算機リソースを管理し、計算機リソースの割り当てを要求するリソース要求に応じて、要求された計算機リソースをユーザに割り当てる管理装置において実行される管理方法であって、前記リソース要求には、割り当てを要求する前記計算機リソースの性能要件及び機能要件が含まれ、前記管理装置が、前記リソース要求において前記機能要件として要求される各機能にそれぞれ対応付けて、当該機能を構成するために必要となる計算機リソースの種別及び当該計算機リソースの必要数を構成条件として保持すると共に、各前記計算機リソースが備える性能及び機能をリソース情報として保持する第１のステップと、前記管理装置が、保持した前記構成条件及び前記リソース情報に基づいて、前記リソース要求において指定された前記機能要件を満たし、かつ当該リソース要求において指定された前記性能要件を満たす計算機リソースを前記複数の計算機リソースの中から検索し、検索結果に基づいて前記ユーザに割り当てる計算機リソースを決定する第２のステップと、前記管理装置が、決定した計算機リソースを前記ユーザに割り当てる第３のステップとを設けるようにした。
さらに本発明においては、ユーザが使用するコンピュータ装置でなるクライアントと、複数の計算機リソースと、前記複数の計算機リソースを管理し、計算機リソースの割り当てを要求する前記クライアントからのリソース要求に応じて、要求された計算機リソースを当該クライアントに割り当てる管理装置とを有し、前記リソース要求には、割り当てを要求する前記計算機リソースの性能要件及び機能要件が含まれ、前記管理装置は、前記リソース要求において前記機能要件として要求される各機能にそれぞれ対応付けて、当該機能を構成するために必要となるリソースの種別及び当該リソースの必要数を構成条件として保持すると共に、各前記計算機リソースが備える性能及び機能をリソース情報として保持するメモリと、前記メモリに保持された前記構成条件及び前記リソース情報に基づいて、前記リソース要求において指定された前記機能要件を満たし、かつ当該リソース要求において指定された前記性能要件を満たす計算機リソースを前記複数の計算機リソースの中から検索し、検索結果に基づいて前記クライアントに割り当てる計算機リソースを決定する検索部と、決定した計算機リソースを前記クライアントに割り当てる割当て部とを備えるようにした。

本発明は以上の点を考慮してなされたもので、プールされるリソースが均質でない計算機システムにおいて、ユーザの要求に合致したリソースを割り当て得る、信頼性の高い管理装置及び方法並びに計算機システムを提案しようとするものである。

以下図面について、本発明の一実施の形態を詳述する。

（１）第１の実施の形態
（１−１）本実施の形態による計算機システムの構成
図１において、１は全体として本実施の形態による計算機システムを示す。この計算機システム１は、複数のクライアント２、管理サーバ３及びリソース群４を備えて構成される。そして、これらクライアント２、管理サーバ３及びリソース群４がネットワーク５を介して接続されている。

クライアント２は、ユーザが使用するコンピュータ装置であり、例えばパーソナルコンピュータや、ワークステーション又はメインフレームなどから構成される。クライアント２は、管理サーバ３が管理するリソース群４内のリソース６を使用して各種の処理を実行する。

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

ＣＰＵ１０は、管理サーバ３全体の動作制御を司るプロセッサである。このＣＰＵ１０がメモリ１１に格納された各種プログラムを実行することにより、管理サーバ３全体として各種の制御処理を実行する。メモリ１１は、各種のプログラム及び制御情報を保持するために用いられるほか、ＣＰＵ１０のワークメモリとしても用いられる。

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

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

リソース群４は、サーバ６や、図示しないＩ／Ｏ（Input/Output）インタフェース、ストレージ装置及びネットワークなどの複数の計算機リソースから構成される。サーバ６は、図２に示すように、ＣＰＵ２０及びメモリ２１と、ハードディスクやフラッシュメモリなどの補助記憶装置２２と、１つ以上のＩ／Ｏインタフェース２３とを備える。ただし、補助記憶装置２２は必須ではない。またＩ／Ｏインタフェース２３は、ＮＩＣやＨＢＡ（Host Bus Adaptor）などから構成される。ＣＰＵ２０は、メモリ２１に格納されたプログラム２４に従って必要な制御処理を実行する。

（１−２）本実施の形態によるリソース管理方式
次に、管理サーバ３に搭載された本実施の形態によるリソース管理方式について説明する。本実施の形態においては、ユーザが、要求するリソースの構成要件として、性能要件だけでなく、機能に関する要件（以下、これを機能要件と呼ぶ）をも指定することができる。そして管理サーバ３には、ユーザにより指定された性能要件及び機能要件に基づいて、そのユーザの要求に合致したリソースを検索して割り当てるリソース管理機能が搭載されている。

かかるリソース管理機能によるリソース管理を実現するための手段として、図１に示すように、管理サーバ３のメモリ１１には、リソース管理プログラム３０及びテーブル群４０が格納されている。そしてリソース管理プログラム３０は、要求取得部３１、構成取得部３２、検索部３３、構成部３４、割当て部３５、変更検知部３６、解除部３７及びインタフェース部３８から構成され、テーブル群４０は、機能テーブル４１、リソーステーブル４２、構成テーブル４３及び要求テーブル４４から構成されている。

このうちリソース管理プログラム３０の要求取得部３１は、ユーザに割り当てるリソース構成の性能要件及び構成要件を取得するためのプログラムである。また構成取得部３２は、リソース群４に属する各リソース６の構成情報等を取得するためのプログラムであり、検索部３３は、ユーザにより指定された性能要件及び機能要件を満たすリソース構成をリソース群４の中から検索するためのプログラムである。

さらに構成部３４は、リソースの機能の構成を実行するためのプログラムであり、割当て部３５は、構成したリソースをユーザに割り当てるためのプログラムであり、変更検知部３６は、リソースの構成変更を検知するためのプログラムである。

なお、以下において、「機能を構成する」とは、１又は複数のリソースを組み合わせて１つの機能を発揮できるようにリソースをパッケージ化すること意味する。例えば「コールドスタンバイ」という機能は、２台以上のサーバのうちの１台のサーバが稼働しているときに残りのサーバの電源を落としてスタンバイさせ、かかる稼働していたサーバがダウンしたときに、スタンバイしていたサーバを起動してダウンしたサーバの代わりに用いる機能であるが、この機能を実現するためには少なくとも２台のサーバが必要となる。従って、「コールドスタンバイ機能を構成する」とは、コールドスタンバイ機能を提供できるように、２台以上のサーバを１つのパッケージとして組み合わせることを意味する。

さらに解除部３７は、構成したリソースのユーザへの割り当てを解除するためのプログラムであり、インタフェース部３８は、必要な情報や、リソース管理者が各種設定を行うためのＧＵＩ（Graphical User Interface）又はＣＬＩ（Command Line Interface）を出力装置１５に表示するためのプログラムである。

一方、機能テーブル４１は、リソース群４を構成するリソース６が備える機能を一括管理するためのテーブルであり、図３に示すように、機能欄４１Ａ、主リソース共有欄４１Ｂ及び構成条件欄４１Ｃから構成される。

そして機能欄４１Ａには、リソース群４を構成するいずれかのリソース６が備える機能の機能名が格納される。また主リソース共有欄４１Ｂには、主リソースが共有可能であるか否かを表す共有可否情報が格納される。

ここで、「主リソース」とは、対応する機能を構成した際に、その機能の提供主体となるリソースのことを指す。本実施の形態においては、サーバ６がこれに該当する。ユーザはこのサーバ６上でアプリケーションプログラム等を実行することとなる。なお、「主リソースを共有する」とは、主リソースを複数のユーザで共有することを指し、例えばサーバ仮想化機能を用いて、１台のサーバ６上で複数の仮想的なサーバ（以下、これを仮想サーバと呼ぶ）が稼働し、これら複数の仮想サーバをそれぞれ異なるユーザが使用する場合が該当する。

構成条件欄４１Ｃは、対応する機能を構成するために必要となる条件を管理するためのフィールドであり、種別欄４１Ｄ、必要数欄４１Ｅ及び共有欄４１Ｆから構成される。

そして種別欄４１Ｄには、対応する機能を構成するために必要となるリソースや条件の種別が格納される。例えば、サーバ６や、サーバ６に搭載されたＣＰＵ２０（図２）、メモリ２１（図２）、補助記憶装置２２（図２）、ＮＩＣなどのＩ／Ｏインタフェース２３（図２）、制御プログラムなどのプログラム２４（図２）、電源装置及びＵＰＳ（Uninterruptible Power Source）などが「リソースの種別」に該当する。また、耐震機能など、リソースの設置環境に依存する場合には、この種別欄４１Ｄに設置環境の条件として「耐震施設」などが格納される。

また必要数欄４１Ｅには、種別欄４１Ｄに格納されたリソースの必要数が格納される。なお図３において、「＋Ｎ」（Ｎは１以上の整数）は、種別欄４１Ｄに格納されたリソースの種別がサーバ６の場合であって、その主リソースのサーバ６以外に「Ｎ」台のサーバ６が必要であることを意味する。例えば図３では、「コールドスタンバイ」機能は、主リソースのサーバ６に加えてもう「１」台のサーバが必要であることが示されている。

また「−Ｎ」は、種別欄４１Ｄに格納されたリソースが、サーバ６が備えるＣＰＵ２０（図２）やＩ／Ｏインタフェース２３（図２）などの場合であって、そのリソースを「Ｎ」だけ消費することを意味する。例えば図３では、「サーバ仮想化１」という機能は、主リソースが備える「ＣＰＵ」動作周波数の中から「0.5GHz」分だけ消費することが示されている。

さらに必要数欄４１Ｅにおける「１」は、種別欄４１Ｄに格納されたリソースの種別がソフトウェアの場合であって、対応する機能を構成するためには主リソースのサーバ６に対してそのソフトウェアを配布する必要があることを表している。例えば図３において、「ソフトウェア障害自動リブート」という機能を構成するためには、主リソースであるサーバ６上に、ソフトウェア障害を検知し自動リブートする「監視プログラム」を配布する必要があることが示されている。

さらに必要数欄４１Ｅにおける「０」は、主リソースのサーバ６に種別欄４１Ｄに格納された種別のリソースが実装されている必要があることを表している。

さらに共有欄４１Ｆには、種別欄４１Ｄに格納された種別のリソースが同じ機能を構成する他の主リソースとの間で共有が可能か不可かを表す共有可否情報が格納される。ここで「共有が可能」とは、ある主リソースのサーバ６に搭載する機能を構成する条件として追加されるサーバ６を、新たに他の主リソースに同じ機能を搭載する場合に利用できることを意味する。従って、例えば図３において、ある主リソースに「コールドスタンバイ」機能を搭載する条件として追加されるサーバ６は、他の主リソースに「コールドスタンバイ」機能を搭載する条件として追加されるサーバとしても利用することができる。

なお、機能テーブル４１を作成及び更新する方法としては、リソース群４の管理製品などが提供するＡＰＩ（Application Program Interface）やＣＬＩ（Command Line Interface）を利用する方法や、例えばリソース管理者が機能に関する情報を入力するためのＵＩをインタフェース部２８が提供する方法、又はリソース管理プログラム３０がファイルから取得する方法などを適用することができる。

リソーステーブル４２は、リソース群４を構成する各リソース（ここではサーバ６）を管理するためのテーブルであり、図４に示すように、リソース識別子欄４２Ａ、性能欄４２Ｂ、機能欄４２Ｃ、物理条件欄４２Ｄ及びコスト欄４２Ｅから構成される。

そしてリソース識別子欄４２Ａには、対応するリソースに対して付与された当該リソースに固有の識別子が格納される。具体的には、サーバ６のＵＵＩＤ（Universally Unique Identifier）やシリアル番号、またブレードサーバであればブレードサーバの搭載シャーシや搭載スロット番号などがそのリソースのリソース識別子として用いられる。その他ユーザが定義した名称を用いるようにしてもでも良い。

また性能欄４２Ｂには、対応するリソースの性能情報が格納される。具体的には、そのリソースに搭載されたＣＰＵの種類、動作周波数やコア数、搭載されたメモリの容量、搭載されたＮＩＣの種類及び数、搭載されたＨＢＡの種類及び数などがそのリソースの性能情報として格納される。

機能欄４２Ｃには、そのリソースが備える機能が格納される。リソースが備える機能としては、例えばコールドスタンバイ機能、ネットワーク冗長化機能及び無停電機能などがある。また物理条件欄４２Ｄには、そのリソースの設置サイトが格納される。リソースが複数のデータセンタサイトに跨る場合、そのデータセンタの識別のために利用される。例えばサイトによって地域が異なる場合に、この情報に基づいて特定の地域のリソースを識別できる。

コスト欄４２Ｅには、そのリソースの利用に必要なコストが格納される。このコストには、運用・保守コストや電力コストなどの情報を含ませることができる。

一方、構成テーブル４３は、リソースの構成状態を管理するためのテーブルであり、図５に示すように、リソース構成識別子欄４３Ａ、主リソース欄４３Ｂ、性能欄４３Ｃ、構成済み機能欄４３Ｄ、構成条件リソース欄４３Ｅ及び構成条件共有状態欄４３Ｆから構成される。

そしてリソース構成識別子欄４３Ａには、対応する機能の構成に対して付与された識別子（以下、これをリソース構成識別子と呼ぶ）が格納され、主リソース欄４３Ｂには、そのリソース構成の主リソースの識別子が格納される。

また性能欄４３Ｃには、そのリソース構成が提供可能な性能情報が格納される。なお、性能欄４３Ｃに格納される対応するリソース構成の性能は、主リソースの性能とは必ずしも一致しない。例えば、リソース構成が仮想サーバである場合、主リソースであるサーバ６の性能と、仮想サーバの性能とは一致しない場合がある。また構成済み機能欄４３Ｄには、対応するリソース構成により発揮される機能の機能名が格納される。対応する主リソースは、この構成済み機能欄４３Ｄに格納された機能を提供可能な状態にある。

構成条件リソース欄４３Ｅには、そのリソース構成において構成済み機能欄４３Ｄに格納されている機能を構成するために用いられるリソースの条件が格納される。図５において、「＋」で始まる条件は、そのリソース構成を構築する際に、構成条件リソース欄４３Ｅにリソース名が格納されたリソースが使用されることを意味する。また「−」で始まる条件は、そのリソース構成を構築する際に、主リソースの備えるリソースのうちの構成条件リソース欄４３Ｅにリソース名が格納されたリソースが使用されないことを意味する。

例えば図５において、「サーバ１」の「コールドスタンバイ」という機能を構成するために「サーバ３」が使用され、「サーバ５」の「ネットワーク冗長化」という機能については当該「サーバ５」の「ＮＩＣ１」及び「ＮＩＣ２」を使用しないことが分かる。

さらに構成条件共有状態欄４３Ｆには、構成条件リソース欄４３Ｅに格納されたリソースの共有状態が格納される。例えば図５の「構成１」の例の場合、「コールドスタンバイ」機能に必要な「サーバ３」は、「構成２」と共有していることが示されている。

他方、要求テーブル４４は、後述のように、リソース管理者の操作入力に応じてインタフェース部３８（図１）から要求取得部３１（図１）に与えられるリソース要求を管理するためのテーブルであり、図６に示すように、要求識別子欄４４Ａ、性能要件欄４４Ｂ、機能要件欄４４Ｃ、割当て先ユーザ欄４４Ｄ、主リソース共有欄４４Ｅ、機能構成リソース共有欄４４Ｆ及び割当て先リソース構成欄４４Ｇから構成される。

そして要求識別子欄４４Ａには、インタフェース部３８から要求取得部３１に与えられた対応するリソース要求に付与された識別子（要求識別子）が格納される。また性能要件欄４４Ｂ及び機能要件欄４４Ｃには、そのリソース要求において要求されたリソースの性能要件及び機能要件が格納され、割当て先ユーザ欄４４Ｄには、リソース要求において指定された、リソースの割当て先となるユーザの識別子が格納される。なお、このユーザは、単独のユーザであっても、またユーザの集合であっても良い。

さらに主リソース共有欄４４Ｅには、対応するリソース要求において指定された、主リソースを他のユーザと共有しても良いか否かを表す情報が格納され、機能構成リソース共有欄４４Ｆには、対応するリソース要求において指定された、当該リソース要求において指定された機能の構成に必要なリソースに対して他のユーザと共有を許可するか不許可とするかを表す情報が格納される。

さらに割当て先リソース構成欄４４Ｇには、そのリソース要求に応じて対応するユーザに割り当てられたリソース構成のリソース構成識別子が格納される。この識別子は、図５について上述した構成テーブル４３におけるリソース構成識別子欄４３Ａに格納されたリソース構成識別子と対応する。なお、そのリソース要求に応じてリソース構成が対応するユーザに未だ割り当てられていない場合、割当て先リソース構成欄４４Ｇには、「未割り当て」という情報が格納される。

（１−３）リソース管理プログラムの処理
次に、本実施の形態によるリソース管理方式に関するリソース管理プログラム３０の処理内容について説明する。なお、以下においては、各種処理の処理主体を、リソース管理プログラム３０を構成する要求取得部３１、構成取得部３２、検索部３３、構成部３４、割当て部３５、変更検知部３６、解除部３７又はインタフェース部３８として説明するが、実際には、これら要求取得部３１、構成取得部３２、検索部３３、構成部３４、割当て部３５、変更検知部３６、解除部３７又はインタフェース部３８に基づいて、管理サーバ３（図１）のＣＰＵ１０（図１）によりその処理が実行されることは言うまでもない。

図７は、本実施の形態によるリソース管理方式によるリソース管理に関連して、リソース管理プログラム３０の要求取得部３１、構成取得部３２、検索部３３、構成部３４、割当て部３５、変更検知部３６、解除部３７及びインタフェース部３８により実行される一連の処理の流れを示す。

かかる一連の処理の起点は、要求取得部３１により実行される要求取得処理（ＳＰ２）、変更検知部３６により実行される変更検知処理（ＳＰ３）又は解除部３７により実行される解除処理（ＳＰ４）のいずれかである。要求取得部３１及び解除部３７は、インタフェース部３８が提供するＵＩ（User Interface）の呼び出しや、ＵＩに対する所定の操作入力があったときに要求取得処理や解除処理を開始する。また変更検知部３６は、リソース群４内のいずれかのリソース６の構成変更を検知した場合に変更検知処理を開始する。

その後、構成取得部３２による構成取得処理（ＳＰ５）、検索部３３による検索処理（ＳＰ６）、構成部３４による構成処理（ＳＰ７）、割当て部３５による割当て処理（ＳＰ８）が順次行われる。なお、処理の流れは、必ずしも本フローに従うわけではなく、条件によっては次の処理をスキップする場合や、次の処理に移らずにフローを終了する場合もある。

またインタフェース部３８は、入力装置１４（図１）を介して与えられる操作入力などに応じて必要なＵＩをリソース管理者に提供する一方、図８について後述するリソース割当て設定画面５０の表示命令が入力されたときには要求取得部３１を起動し、リソース構成を解除するためのリソース構成解除画面（図示せず）の表示命令が入力されたときには解除部３７を起動する（ＳＰ１）。

（１−３−１）インタフェース部の処理

図８は、インタフェース部３８が提供するリソース割当て設定画面５０の構成例を示す。このリソース割当て設定画面５０は、ユーザからの要求に応じてリソース管理者がそのユーザ（以下、これを対象ユーザと呼ぶ）にリソースを割り当てる設定を行うためのＵＩである。このリソース割当て設定画面５０は、管理サーバ３の出力装置１５や、管理サーバ３にネットワークを介して接続された他の端末の出力装置等に、その端末に実装されたブラウザや専用のプログラムなどを用いて表示される。

図８からも明らかなように、リソース割当て設定画面５０は、性能要件指定領域５１及び機能要件指定領域５２を備える。そして性能要件指定領域５１には性能要求入力部６０が設けられており、対象ユーザからの要求に応じてリソース管理者がその対象ユーザに割り当てようとするリソースの性能要件を、この性能要求入力部６０内に入力装置１４を介して入力することができる。

また機能要件指定領域５２には、機能一覧表示部６１及び選択機能表示部６２が設けられている。そして機能一覧表示部６１には、リソース群４を構成するいずれかのリソース（サーバ６）が備える機能の一覧が表示され、選択機能表示部６２には、かかる機能一覧表示部６１に表示された機能のうち、対象ユーザに割り当てるべき機能としてリソース管理者により選択された機能が表示される。インタフェース部３８は、この機能一覧表示部６１に表示すべき情報を、機能テーブル４１（図３）及びリソーステーブル４２（図４）から取得する。

追加ボタン６３及び削除ボタン６４は、それぞれ機能一覧表示部６１に表示された機能の中からリソース管理者が選択した機能を選択機能表示部６２に移動させたり、逆に選択機能表示部６２に表示された機能を機能一覧表示部６１に戻すためのボタンである。

また第１のチェックボックス６５は、主リソースについて他のユーザとの共有を許可するか否かを設定するためのものであり、かかる共有を許可する場合には当該第１のチェックボックス６５にチェックマークを表示させる。さらに第２のチェックボックス６６は、選択機能表示部６２に表示された機能の構成に必要なリソースを他のユーザと共有することを許可するか否かを設定するためのものであり、かかる共有を許可する場合には当該第２のチェックボックス６６にチェックマークを表示させる。

そしてリソース割当て設定画面５０では、対象ユーザに割り当てようとするリソースの性能に関する要件（以下、これを性能要件と呼ぶ）を性能要件指定領域５１の性能要求入力部６０に入力すると共に、そのリソースに要求する機能に関する要件（以下、これを機能要件と呼ぶ）を、機能要件指定領域５２の選択機能表示部６２に表示させた後に決定ボタン５３をクリックすることによって、これら性能要件及び機能要件を設定することができる。そして、このときこれらの性能要件及び機能要件と、対象ユーザのユーザ名となどの情報がリソース要求として要求取得部３１に与えられる。またリソース割当て設定画面５０では、キャンセルボタン５４をクリックすることによって、そのときリソース割当て設定画面５０において行われたすべての操作をキャンセルすることができる。

（１−３−２）要求取得部の処理
一方、図９は、要求取得部３１により実行される要求取得処理の処理手順を示す。要求取得部３１は、インタフェース部３８により起動されるとこの要求取得処理を開始し、その後、インタフェース部３８から与えられる上述のリソース要求を取得する（ＳＰ１０）。

続いて要求取得部３１は、取得したリソース要求に含まれる性能要件、機能要件、対象ユーザの識別子、主リソースの共有の可否、及び、機能構成リソースの共有の可否に関する情報を要求テーブル４４（図６）に登録する（ＳＰ１１）。この際、要求テーブル４４が存在しない場合には、要求取得部３１は、要求テーブル４４の作成をも併せて行う。続いて要求取得部３１は、構成取得部３２を起動し（ＳＰ１２）、この後この要求取得処理を終了する。

（１−３−３）構成取得部の処理
図１０は、要求取得処理（図９）のステップＳＰ１２において起動された構成取得部３２により実行される構成取得処理の処理手順を示す。構成取得部３２は、要求取得部３１により起動されるとこの構成取得処理を開始し、まず、リソース群４を構成する各リソースの構成要素に関する情報（図４について上述したリソーステーブル４２の性能欄４２Ｂ、機能欄４２Ｃ、物理条件欄４２Ｄ及びコスト欄４２Ｅにそれぞれ格納する情報）を取得する（ＳＰ２０）。また構成取得部３２は、リソース群４を構成する各リソースの機能の構成状態（図５について上述した構成テーブル４３の主リソース欄４３Ｂ、性能欄４３Ｃ、構成済み機能欄４３Ｄ及び構成条件リソース欄４３Ｅにそれぞれ格納する情報）を取得する（ＳＰ２１）。

なお、上述のステップＳＰ２０及びステップＳＰ２１において、構成取得部３２がリソース群４を構成する各リソースに関する情報を取得する方法としては、リソース群４の管理製品などが提供するＡＰＩやＣＬＩを利用する方法や、例えばリソース管理者が機能に関する情報を入力するためのＵＩをインタフェース部２８が提供する方法、又はリソース管理プログラム３０がファイルから取得する方法などを適用することができる。

次いで構成取得部３２は、ステップＳＰ２０及びステップＳＰ２１において取得した情報をそれぞれリソーステーブル４２及び構成テーブル４３に登録する（ＳＰ２２）。この際、リソーステーブル４２や構成テーブル４３が存在しない場合には、構成取得部３２は、リソーステーブル４２及び又は構成テーブル４３の作成をも併せて行う。そして構成取得部３２は、この後、この構成取得処理を終了する。

（１−３−４）検索部の処理
他方、図１１は、検索部３３により実行される検索処理の処理手順を示す。検索部３３は、定期的又は不定期にこの検索処理を実行することにより、要求テーブル４４に登録されている未処理のリソース要求において要求されている性能要件及び機能要件を備えるリソース構成をリソース群４の中から検索する。

すなわち検索部３３は、この検索処理を開始すると、まず、要求テーブル４４に登録されたリソース要求のうち、リソース構成が未割当てのリソース要求（要求テーブル４４の割当て先リソース構成欄４４Ｇに「未割当て」という情報が格納されたリソース要求）を読み出し（ＳＰ３０）、そのリソース要求において要求された性能要件及び機能要件を備えるリソース構成を既存のリソース構成（以下、適宜、これを既存リソース構成と呼ぶ）から検索する（ＳＰ３１）。

続いて検索部３３は、かかるリソース要求において要求された性能要件及び機能要件を備えるリソース構成を新規に構築する（ＳＰ３２）。そして検索部３３は、この後、ステップＳＰ３１及びステップＳＰ３２の処理の結果、対象ユーザに割り当てる候補（以下、これをリソース構成候補と呼ぶ）となり得るリソース構成があるか否かを判断する（ＳＰ３３）。

そして検索部３３は、この判断において否定結果を得ると、所定のエラー通知をインタフェース部３８に通知し（ＳＰ３４）、この後、この検索処理を終了する。かくしてインタフェース部３８は、このエラー通知に基づいて、対象リソース要求において要求された性能要件及び機能要件を満たす既存及び新規のリソース構成が計算機システム１上に存在しない旨のエラーメッセージを出力装置１５に表示させる。

これに対して検索部３３は、ステップＳＰ３３の判断において肯定結果を得ると、かかるリソース構成候補の中から対象ユーザに割り当てるリソース構成を１つ決定する（ＳＰ３５）。本実施の形態の場合、この決定は、リソーステーブル４２のコスト欄４２Ｅを参照して、リソース構成候補ごとに、そのリソース構成候補に含まれる各リソースのコストの和を当該リソース構成候補のコストとして算出し、算出したコストが最もリソース構成候補を対象ユーザに割り当てるリソース構成として決定する。

続いて検索部３３は、ステップＳＰ３５において決定したリソース構成が既存リソース構成であるか否かを判断する（ＳＰ３６）。そして検索部３３は、この判断において肯定結果を得ると、構成部３４を起動し（ＳＰ３７）、この構成部３４による構成処理（図１５）が終了するとステップＳＰ３８に進む。

これに対して検索部３３は、ステップＳＰ３６の判断において肯定結果を得、又はステップＳＰ３７において起動した構成部３４による構成処理が終了すると、割当て部３５を起動する（ＳＰ３８）。

そして検索部３３は、かかる割当て部３５による割当て処理（図１６）が終了すると、要求テーブル４４に未処理のリソース要求が残っているか否かを判断する（ＳＰ３９）そして検索部３３は、この判断において否定結果を得るとステップＳＰ３０に戻り、この後ステップ３０〜ステップＳＰ３９の処理を繰り返す。

そして検索部３３は、やがて要求テーブル４４に未処理のリソース要求がなくなることによりステップＳＰ３９において否定結果を得ると、この検索処理を終了する。

なお、かかる検索処理のステップＳＰ３１における検索部３３の具体的な処理内容を図１２に示す。検索部３３は、検索処理のステップＳＰ３１に進むと、この既存用リソース構成検索処理を開始し、まず、構成テーブル４３（図５）に登録された既存リソース構成の中から未だユーザに割り当てられていないリソース構成（未割り当てのリソース構成）をすべて抽出する（ＳＰ４０）。

続いて検索部３３は、ステップＳＰ４０において抽出した既存リソース構成の中から、図１１のステップＳＰ３０において取得したそのとき対象としているリソース要求（以下、これを対象リソース要求と呼ぶ）において要求されている機能要件をすべて満たす既存リソース構成を抽出する。ここで「満たす」とは、対象リソース要求において要求されている機能要件のすべての機能項目をその既存リソース構成が備える場合をいう。例えば、対象リソース要求において要求されている機能要件が「ネットワーク冗長化」及び「無停電電源」である場合、検索部３３は、構成テーブル４３の構成済み機能欄４３Ｄを参照して、この両方の機能を備える既存リソース構成をすべて抽出することになる（ＳＰ４１）。

次いで検索部３３は、要求テーブル４４（図６）上の対象リソース要求に対応するエントリの主リソース共有欄４４Ｅ及び機能構成リソース共有欄４４Ｆを参照して、対象リソース要求において、主リソース及び機能構成リソースの双方について、他のユーザとの共有を許可しているか否かを確認する（ＳＰ４２）。

そして検索部３３は、この判断において肯定結果を得るとステップＳＰ４４に進み、これに対して否定結果を得ると、ステップＳＰ４１において抽出した既存リソース構成の中から不要な既存リソース構成を候補から削除する（ＳＰ４３）。具体的には、対象リソース要求において、主リソースの共有を不許可としている場合は、ステップＳＰ４３において抽出した既存リソース構成の中から、既に主リソースが他の既存リソース構成の主リソースとして使用されているものをリソース構成候補から削除する。さらに、機能構成リソースの共有を不許可としている場合には、残りの候補の中から、機能構成リソースが共有となっている既存リソース構成（構成テーブル４３の構成条件共有状態欄４３Ｆが「有」となっている既存リソース構成）をリソース構成候補から削除する。

この後、検索部３３は、現在残っているリソース構成候補の中から対象リソース要求において要求されている性能要件を満たす既存リソース構成を選択し、その既存リソース構成をリソース構成候補として確定する（ＳＰ４４）。そして検索部３３は、この後、この既存用リソース構成検索処理を終了する。

一方、図１３は、検索処理（図１１）のステップＳＰ３２における検索部３３の具体的な処理内容を示す。検索部３３は、検索処理のステップＳＰ３２に進むと、この新規用リソース構成検索処理を開始し、まず、プールリソースを取り出す（ＳＰ５０）。ここで「プールリソース」とは、リソーステーブル４２に登録されたリソースのうち、未だユーザに割り当てられていないリソースのことをいう。いずれかのリソース構成に含まれるリソースであっても、そのリソース構成が未だユーザに割り当てられていなければ、そのリソースもまたプールリソースとする。また、リソース構成に含まれていないリソースはプールリソースである。ただし、対象リソース要求において、主リソースの共有が許可されている場合には、主リソースの共有が可能な機能（図３について上述した機能テーブル４１の主リソース共有欄４１Ｂに格納された共有可否情報が「可」である機能）をサポートするリソース構成に含まれる主リソース（図５について上述した構成テーブル４３の対応するエントリの主リソース欄４３Ｂに格納された主リソース）は、プールリソースに加える。

続いて検索部３３は、プールリソースの中から、対象リソース要求において指定された機能要件をすべて満たすリソースを抽出する（ＳＰ５１）。ここで「満たす」とは、対象リソース要求において要求されている機能要件のすべての機能項目をリソースが備える場合である。例えば、対象リソース要求において要求されている機能要件が「ネットワーク冗長化」及び「無停電電源」の場合、リソーステーブル４２上の対応するエントリの機能欄４２Ｃを参照して、この両方の機能を備えるリソースをすべて抽出することになる。

次いで検索部３３は、対象リソース要求において要求されている機能要件の機能ごとに、構成条件を機能テーブル４１から取得し、機能テーブル４１の対応するエントリの必要数欄４１Ｅに格納された構成条件（具体的には、「＋Ｎ」（Ｎは１以上の整数）又は「−Ｎ」という情報）を機能のリソース条件として取り出す（ＳＰ５２）。

続いて検索部３３は、ステップＳＰ５１において抽出したすべてのリソースの中から主リソースを選択する（ＳＰ５３）。具体的に、検索部３３は、リソーステーブル４２の対応するエントリの性能欄４２Ｂを参照して、ステップＳＰ５１において抽出した各リソースの性能と、対象リソース要求において要求されている性能要件とを比較し、対象リソース要求において要求されている性能要件を満たすリソースの中から１つのリソースを主リソースとして選択する。

なお、ここでの「満たす」とは、リソース要求の性能要件に対して、リソースの性能が一致するかそれ以上である場合をいう。ただし、ステップＳＰ５１において、機能のリソース条件が「−Ｎ」を含む場合、リソース条件における全ての「−Ｎ」を上述のリソースの性能から減算したものが、対象リソース要求の性能要件を満たす必要がある。例えば、あるリソースの性能のうち、ＣＰＵの動作周波数が「3.0GHz」であり、リソース条件の「−Ｎ」が「−CPU 0.5GHz」である場合には、リソースの性能からこれを引いた「2.5GHz」が性能要件を満たす必要がある。

この後、検索部３３は、ステップＳＰ５２において取り出した機能毎のリソース条件のうち、「＋Ｎ」の条件に対応するＮ台のサーバ６を検索する（ＳＰ５４）。ここで、機能毎のリソース条件「＋Ｎ」に対して、プールリソースのうちステップＳＰ５３で選択した主リソース以外のＮ台のリソース（ここではサーバ６を指す）を選択する。ただし、次の（１）及び（２）の両方の条件を満たす場合、当該機能を構成済みの既存のリソース構成を構成テーブル４３から参照し、該当するリソース構成の構成条件リソース（構成テーブル４３の構成条件リソース欄４３Ｅに格納されたリソース）からＮ台のリソースを優先的に選択する。
（１）該当リソース要求において機能構成リソースの共有を許可
（２）機能の構成条件における共有可否（機能テーブル４１の共有欄４１Ｆに格納された可否）が「可」

続いて検索部３３は、ステップＳＰ５３で選択したリソースを「主リソース」とし、ステップＳＰ５４で選択した機能及び各機能のリソース条件に対応するリソースをその主リソースの「機能」及び「構成条件リソース」として、新規リソース構成をリソース構成候補として生成する（ＳＰ５５）。ここで、新規リソース構成の候補が、既存のリソース構成に含まれる主リソースを利用する場合は、その既存のリソース構成を解除したうえで、新規リソース構成を作成することとなる。このため、かかる新規リソース構成については、既存のリソース構成の解除が必要か否かを示す「既存リソース構成解除フラグ」を付与する。

次いで検索部３３は、対象リソース要件に対して妥当な数のリソース構成候補を生成し終えたか否かを判断する（ＳＰ５６）。そして検索部３３は、この判断において否定結果を得るとステップＳＰ５３に戻り、この後、ステップＳＰ５３〜ステップＳＰ５６の処理を繰り返す。この際、検索部３３は、主リソースや機能の構成条件リソースの組み合わせが、すでに生成したリソース構成候補と異なるリソース構成候補を新たに生成する。

ここで妥当な数のリソース構成候補を選ぶ方法としては、例えば取り得るすべてのリソース構成候補が生成されるまでとしても良いし、また対象リソース要求において要求されている性能要件と、主リソースの性能とが近い上位３つの新規リソース構成をリソース構成候補として選択するようにしても良い。さらに、対象リソース要求において指定された機能要件には含まれないが、仮想サーバ機能を備えるリソース構成に絞ってリソース構成候補を選択する、などの方法を適用するようにしても良い。

そして検索部３３は、やがて妥当な数のリソース構成候補を生成し又はこれ以上のリソース構成候補を生成し得なくなると、この新規用リソース構成検索処理を終了して、図１１について上述した検索処理に戻る。

なお、図１１について上述した検索処理のステップＳＰ３５では、既存リソース構成のリソース構成候補及び新規リソース構成のリソース構成候補が掲載されたＵＩ（以下、これをリソース構成候補選択画面と呼ぶ）を出力装置１５に表示すると共に、これらリソース構成候補のコストなどの情報を併せてリソース構成候補選択画面に表示し、このリソース構成候補選択画面に掲載されたリソース構成候補の中からユーザに割り当てるリソース構成をリソース管理者が選択できるようにしても良い。

図１４に、このようなリソース構成候補選択画面の構成例を示す。この図１４に示すリソース構成候補選択画面７０は、性能要件表示領域７１、機能要件表示領域７２及び候補表示領域７３を備えて構成される。そして性能要件表示領域７１及び機能要件表示領域７２には、対象リソース要求において要求された性能要件及び機能要件がそれぞれ表示される。

また候補表示領域７３には、リソース構成候補表示部７４が設けられており、このリソース構成候補表示部７４に、上述の検索処理により検出された幾つかのリソース構成候補がリスト形式で表示される。このリストにおいて、表示項目の「主リソース」欄には、リソース構成候補における主リソースの識別子が表示される。

また、かかるリストの「構成リソース」欄には、そのリソース構成候補の機能構成条件のリソースが表示される。具体的には、既存リソース構成の場合は構成テーブル４３の構成条件リソース欄４３Ｅのうち、「＋」で始まるリソース、新規リソース構成の場合は、新規リソース構成の図１３について上述した新規用リソース構成検索処理のステップＳＰ５４のリソース条件により追加したリソースが表示されることになる。なお、構成リソースが他のユーザとの共有となる場合は「サーバ７（共有）」などと表示される。

さらに、かかるリストの「構成状態」欄には、リソース構成候補が既存リソース構成の場合は「構成済み」、新規リソース構成の場合は「未構成」という文字列が表示される。ただし、そのリソース構成候補が新規リソース構成であって、新規用リソース構成検索処理のステップＳＰ５５にて付与された既存リソース構成の解除フラグが付与されている場合には、かかる「構成状態」欄に「未構成（解除要）」などの文字列が表示される。

さらに、かかるリストの「その他機能」欄には、対応するリソース構成候補において、対象リソース要求において指定された機能要件に含まれないが、そのリソース構成候補が備える機能があるときには、その機能名が表示される。なお、そのような機能がないときには、「その他機能」欄に「なし」という文字列が表示される。

一方、かかるリストの「評価」欄には、そのリソース構成候補の奨励度合いが「★」の個数などで表示される。この表示方法としては、例えば検索処理（図１１）のステップＳＰ３５において算出したコストや、対象リソース要求の性能要件及び機能要件と、そのリソース構成候補の性能及び機能との差を参考に、これらが小さいほど「★」の数を増やす方法を採用することができる。

他方、かかるリストの「コスト」欄には、検索処理（図１１）のステップＳＰ３５において算出したコストが表示される。また「サイト」欄には、そのリソース構成候補に含まれるリソースの設置サイトが表示される。この場合、基本的には「サイト」欄には主リソースの設置サイトを表示することになるが、これと併せて「構成リソース」の設置サイトも表示するようにしても良い。

そしてこのリソース構成候補選択画面７０では、リソース構成候補表示部７４に表示されたリソース構成候補の中から所望のリソース構成候補を１つ選択し、この後、画面下側に表示された決定ボタン７５をクリックすることにより、そのとき選択したリソース構成候補を対象ユーザに割り当てるリソース構成として決定することができる。そしてこの場合、かかる決定が検索部３３に通知される。またリソース構成候補選択画面７０において、画面下側のキャンセルボタン７６をクリックすることにより、そのときリソース構成候補選択画面７０において行われたすべての操作をキャンセルすることができる。

（１−３−５）構成部の処理
図１５は、検索処理（図１１）のステップＳＰ３７において起動された構成部３４により実行される構成処理の処理手順を示す。構成部３４は、立ち上がり処理後、この構成処理を実行することにより、検索処理のステップＳＰ３５において対象ユーザに割り当てるストレージ構成として決定されたリソース構成の生成が必要な場合に、当該リソース構成を新たに構築する。

すなわち構成部３４は、この構成処理を開始すると、まず、検索処理（図１１）のステップＳＰ３５において対象リソース要求に応答してユーザに割り当てるリソース構成として決定したリソース構成候補について、既存リソース構成解除フラグ（図１３について上述した新規用リソース構成検索処理のステップＳＰ５５の説明を参照）が付与されているか否かを判断する（ＳＰ６０）。

そして構成部３４は、この判断において否定結果を得るとステップＳＰ６２に進み、これに対して肯定結果を得ると、そのリソース構成が利用するリソースを主リソースとする既存リソース構成を解除する（ＳＰ６１）。なお、このような既存リソース構成を解除する方法としては、解除操作のため、解除すべきリソース構成に含まれるリソース群４の管理製品などが提供するＡＰＩやＣＬＩを利用して機能の構成解除を実行する方法や、解除すべきリソース構成のリソース及び機能を出力装置に示し、その表示に基づいてリソース管理者が解除操作を行う方法などを適用することができる。

続いて構成部３４は、対応するリソース構成の内容に基づく機能の構成を実行する（ＳＰ６２）。ここでは、そのリソース構成において構成すべき各機能の構成を実行するため、そのリソース構成に含まれる主リソース及び機能に関する構成条件に対して、該当リソース管理製品などが提供するＡＰＩやＣＬＩを利用して機能の構成を実行する。ただし、実行すべきリソース及び機能の構成をインタフェース部３８が出力装置１５に示し、これに基づいてリソース管理者などが機能の構成を実行できるようにしても良い。

次いで構成部３４は、ステップＳＰ６２において新規に構成されたリソース構成を構成テーブル４３に追加登録すると共に、ステップＳＰ６１において解除したリソース構成を構成テーブル４３から削除する（ＳＰ６３）。そして構成部３４は、この後、この構成処理を終了する。

（１−３−６）割当て部の処理
図１６は、検索処理（図１１）のステップＳＰ３８において起動された割当て部３５により実行される割当て処理の処理手順を示す。割当て部３５は、立ち上がり処理後、この割当て処理を実行することにより、ユーザに対して検索処理のステップＳＰ３５において決定されたリソース構成を対象ユーザに割り当てる。

すなわち割当て部３５は、この割当て処理を開始すると、まず、対象ユーザに対して検索処理のステップＳＰ３５において決定されたリソース構成を割り当てる（ＳＰ７０）。ここで「リソース構成をユーザに割り当てる」とは、該当リソース構成が使用中状態になったことを意味する。なお、この結果はインタフェース部３８により出力装置１５に表示される。

続いて割当て部３５は、以上のようなリソース構成の対象ユーザへの割当てに対応して要求テーブル４４（図６）を更新する（ＳＰ７１）。具体的に、割当て部３５は、対象リソース要求に対してそのリソース構成を割り当てたことを示す情報を追加するため、要求テーブル４４の対応するエントリの割当て先リソース構成欄４４Ｇに、かかるリソース構成のリソース構成識別子を追加する。そして割当て部３５は、この後、この割当て処理を終了する。

（１−３−７）変更検知部の処理
一方、図１７は、変更検知部３６により実行される変更検知処理の処理手順を示す。変更検知部３６は、リソース群４に含まれる各リソース（サーバ６）の構成変更の有無を常時監視しており、いずれかのリソース構成に変更が生じたことを検知したときには、この変更検知処理によりそのリソース構成を再構築する。

すなわち変更検知部３６は、リソース群４を構成するいずれかのリソースの構成に変更が生じたことを検知すると、この変更検知処理を開始し、まず、構成テーブル４３（図５）を参照して、そのとき検知したリソースの構成変更の影響を受けるリソース構成を確認する（ＳＰ８０）。なお、ここでの「構成変更」とは、例えばリソースにおいて障害が発生した場合や、リソースの追加や削除が行われた場合を指す。また、ここでの「影響」とは、構成変更を起こしたリソースが、既存のリソース構成に含まれる場合を意味する。

続いて変更検知部３６は、再構成が必要か否かを判断する（ＳＰ８１）。具体的に、変更検知部３６は、ステップＳＰ８０における確認処理の確認結果に基づいて、そのとき検知した構成変更の影響を受けるリソース構成が存在し、かつ当該リソース構成が割り当てられたユーザが存在するか否かを判断する。そして変更検知部３６は、このステップＳＰ８１において否定結果を得るとこの変更処理を終了する。

これに対して変更検知部３６は、ステップＳＰ８１の判断において肯定結果を得ると、ステップＳＰ８０において確認した、かかる構成変更によって影響を受けるリソース構成のユーザへの割り当てを解除し、これに応じて要求テーブル４４を更新する。また変更検知部は、そのリソース構成をユーザに割り当てたときのリソース要求を要求テーブル４４から読み出し、このリソース要求を新たなリソース要求として、構成取得部３２（図１）に通知する（ＳＰ８３）。なお、本ステップＳＰ８３において、リソース構成の構成変更と、その影響を受けるリソース構成への割り当てを変更するリソース要求の情報とをインタフェース部３８が出力装置１５に表示し、リソース構成の再割り当てを行うか否かをリソース管理者などに問い合わせるようにしても良い。

そして変更検知部３６は、この後、この変更検知処理を終了する。

（１−３−８）解除部の処理
他方、図１８は、解除部３７により実行される解除処理の処理手順を示す。解除部３７は、インタフェース部３８により出力装置１５に表示された、リソース要求を解除するための図示しないリソース要求解除設定画面においてリソース要求が指定され、そのリソース要求の解除の実行命令が入力されると、この解除処理を実行することにより、指定されたリソース要求を解除する。

すなわち解除部３７は、この解除処理を開始すると、まず、リソース構成の解除が必要であるか否かを判断する（ＳＰ９０）。そして解除部３７は、この判断において否定結果を得るとステップＳＰ９３に進み、これに対して肯定結果を得ると、かかるリソース要求解除設定画面において指定されたリソース構成を解除する（ＳＰ９１）。この処理には、解除操作のため、解除すべきリソース構成に含まれるリソース群４の各リソースの管理製品などが提供するＡＰＩやＣＬＩを利用して、機能の構成解除を実行する方法や、リソース管理者などに解除すべきリソース構成のリソース及び機能を示し、リソース管理者などが解除の操作を実施できるようにする方法を適用することができる。

続いて解除部３７は、ステップＳＰ９１で解除したリソース構成を、構成テーブル４３（図５）から削除すると共に（ＳＰ９２）、解除対象のリソース要求を要求テーブル４４（図６）から削除し（ＳＰ９３）、この後、この解除処理を終了する。

（１−４）本実施の形態の効果
以上のように本実施の形態によれば、管理サーバ３が対象ユーザに割り当てるリソースを性能及び機能の双方に基づいてプールから検索するようにしているため、性能及び機能の双方においてユーザの要求に合致するリソースを割り当てることができる。かくするにつき、ユーザの用途に応じた最適なリソースを割り当て得る信頼性の高い計算機システムを実現できる。

（２）第２の実施の形態
図１との対応部分に同一符号を付して示す図１９は、第２の実施の形態による計算機システム８０を示す。この計算機システム８０は、重要度に対する機能要件が規定された対応テーブル８６が管理サーバ８１のメモリ１１に格納されており、機能要件をリソース管理者が直接指定しなくても、対応テーブル８６に基づいて機能要件を指定できる点が第１の実施の形態による計算機システム１（図１）と相違する。

ここで図２０は、かかる対応テーブル８６の構成を示す。この対応テーブル８６は、重要度欄８６Ａ、機能要件欄８６Ｂ、主リソース共有欄８６Ｃ、機能構成リソース共有欄８６Ｄ及び理論値欄８６Ｅから構成される。

そして重要度欄８６Ａには、重要度が格納され、機能要件欄８６Ｂには、その重要度に対して予め設定された機能要件が格納される。本実施の形態の場合、この重要度は「１」〜「５」の５段階で設定され、その数値が大きくなるほど重要度が高くなる。

また主リソース共有欄８６Ｃには、主リソースについて他のユーザとの共有を許可するか否かの情報が格納され、機能構成リソース共有欄８６Ｄには、機能の構成に必要なリソースについて他のユーザとの共有を許可するか否かの情報が格納される。

さらに理論値欄８６Ｅには、機能要件欄８６Ｂに格納されているその重要度と対応付けられた機能の理論上のスペック（カタログスペック）が格納される。例えば、可用性に関する機能であれば、「可用性：99.99％」などの情報が格納される。

なお、対応テーブル８６を作成及び更新する方法としては、予めベンダ側において既定値を設定しておく方法や、理論値について、リソース群４の管理製品などが提供するＡＰＩやＣＬＩを利用して更新する方法、インタフェース部３８が表示するＵＩを用いてリソース管理者などが設定する方法、又は本実施の形態によるリソース管理プログラム８２がファイルから取得する方法などを適用することができる。

図２１は、リソース割当て設定画面の表示命令が入力されたときにインタフェース部８４（図１９）が出力装置１５に表示させる第２の実施の形態によるリソース割当て設定画面９０の構成例を示す。このリソース割当て設定画面９０は、管理サーバ８１の出力装置１５や、管理サーバ８１にネットワークを介して接続された他の端末の出力装置等に、その端末に実装されたブラウザや専用のプログラムなどを用いて表示される。

かかるリソース割当て設定画面９０は、性能要件指定領域９１及び重要度指定領域９２を備える。性能要件指定領域９１は、図８について上述した第１の実施の形態によるリソース割当て設定画面５０の性能要件指定領域５１と同様の構成及び機能を有する。

また重要度指定領域９２には、選択重要度表示部９４が設けられ、この選択重要度表示部９４の右横にプルダウンボタン９５が設けられている。そして重要度指定領域９２では、このプルダウンボタン９５をクリックして、重要度を表す「１」から「５」までの数字が掲載されたプルダウンメニュー（図示せず）を表示させ、そのプルダウンメニューの中から所望する数値（重要度）を選択することにより、その数値を選択重要度表示部９４に表示させることができる。そしてこのとき選択重要度表示部９４に表示された数値が、そのときリソース管理者により指定された重要度となる。

また以上のようにして重要度を指定した場合、その指定した重要度に対して対応付けられた構成機能の内容が構成機能表示領域９６に表示され、またその構成機能により期待できる可用性（availability）が論理値表示領域９７に表示される。

そしてリソース割当て設定画面９０では、対象ユーザに割り当てようとするリソースの性能要件を性能要件指定領域９１の性能要求入力部９３に入力すると共に、重要度指定領域９２の選択重要度表示部９４に所望する重要度を表示させた後に決定ボタン９８クリックすることによって、これら性能要件及び重要度を設定することができる。そして、このときこれらの性能要件及び重要度と、対象ユーザのユーザ名となどの情報がリソース要求として要求取得部８３（図１９）に与えられる。またリソース割当て設定画面９０では、キャンセルボタン９９をクリックすることによって、そのときリソース割当て設定画面９０において行われたすべての操作をキャンセルすることができる。

要求取得部８３は、かかるリソース要求をインタフェース部８４から受け取ると、対応テーブル８６を参照して、そのリソース要求に含まれる重要度に対応する機能要件を取得する。また要求取得部８３は、図９について上述した第１の実施の形態による要件取得処理のステップＳＰ１１以降と同様の処理を実行する。

なお、要求取得部８３以外の構成取得部３２により実行される構成取得処理、検索部３３により実行される検索処理、構成部３４により実行される構成処理、割当て部３５により実行される割当て処理、変更検知部３６により実行される変更検知処理及び解除部３７により実行される解除処理は、すべて第１の実施の形態と同様であるため、ここでの説明は省略する。

以上のように本実施の形態による計算機システム８０では、リソース管理者が直接機能要件を指定しなくても、対応テーブル８６に基づいて機能要件を指定できるため、その分リソース管理者の負荷を低減することができる。

（３）第３の実施の形態
図１との対応部分に同一符号を付して示す図２２は、第３の実施の形態による計算機システム１００を示す。この計算機システム１００は、各機能のそれまでの稼働実績に基づいて機能要件を選択できるようになされた点を特徴とする。

そのための手段として、管理サーバ１０１のメモリ１１には、テーブル群１０６の構成要素として稼働実績管理テーブル１０７が格納されている。この稼働実績管理テーブル１０７は、機能ごとの稼働実績を管理するためのテーブルであり、図２３に示すように、番号欄１０７Ａ、構成機能欄１０７Ｂ、稼働実績欄１０７Ｃ及び構成識別子欄１０７Ｄから構成される。

そして番号欄１０７Ａには、そのエントリのエントリ番号が格納され、構成機能欄１０７Ｂには、対応する機能の機能名（例えば「コールドスタンバイ」、「仮想サーバ」など）が格納される。また稼働実績欄１０７Ｃには、その機能のそれまでの稼働実績が格納される。例えば可用性を機能の実績の指標とする場合は、「可用性：99.9%」などをいう具体的な数値が格納される。さらに構成識別子欄１０７Ｄには、その機能を構成するリソース構成の識別子（リソース構成識別子）が格納される。

図２４は、本実施例におけるリソース管理プログラム１０２の要求取得部１０３により実施される要求取得処理の処理手順を示す。この要求取得処理の処理手順が第１の実施の形態による要求取得処理（図９）と異なる点は、ステップＳＰ１００の処理が追加されている点である。

このステップＳＰ１００において、要求取得部１０３は、稼働実績テーブル１０７を参照して、各機能の稼働実績値を算出する。例えば、機能毎の実績の平均値を算出し機能の実績値とする。そして要求取得部１０３は、この後、図９のステップＳＰ１０〜ステップＳＰ１２と同様にしてステップＳＰ１０１〜ステップＳＰ１０３を処理する。

一方、図８との対応部分に同一符号を付して示す図２５は、本実施の形態によるインタフェース部１０５（図２２）が提供するリソース割当て設定画面１１０の構成例を示す。第１の実施の形態のリソース割当て設定画面５０（図８）と異なる点は、機能要件指定領域５２内の選択機能表示部６２の下側に稼働実績表示領域１１１が設けられている点である。そして本実施の形態においては、この稼働実績表示領域１１１に、そのとき選択機能表示部６２に表示された機能要件について算出した稼働実績値が表示される。なお、この図２５のように選択機能表示部６２に複数の機能要件が表示されている場合、かかる稼働実績表示領域１１１に表示される稼働実績値は、これら各機能要件の稼働実績値の平均値である。

図２６は、本実施の形態の検索部１０４（図２２）により実行される検索処理の処理手順を示す。この検索処理の処理手順が第１の実施の形態の検索処理（図１１）と異なる点は、ステップＳＰ１１５の処理が追加されている点である。

このステップＳＰ１１５において、検索部１０４は、稼働実績テーブル１０７を参照して、既存リソース構成のリソース構成候補の稼働実績値をそれぞれ算出する。例えば、機能毎の実績の平均値を算出し機能の実績値とする。これ以外のステップＳＰ１１０〜ステップＳＰ１１５及びステップＳＰ１１６〜ステップＳＰ１２０の処理の処理内容は、第１の実施の形態による検索処理のステップＳＰ３０〜ステップＳＰ３４及びステップＳＰ３５〜ステップＳＰ３９と同様である。

図１４との対応部分に同一符号を付した図２７は、本実施の形態のリソース構成候補選択画面１２０を示す。このリソース構成候補選択画面１２０と、第１の実施の形態のリソース構成候補選択画面７０（図１４）との相違点は、本実施の形態によるリソース構成候補選択画面１２０の場合、候補表示領域１２１のリソース構成候補表示部１２２に、当該リソース構成候補表示部１２２に表示されたリソース構成候補に関する情報として、そのリソース構成候補に搭載された機能要件の稼働実績（図２７では「実績」）が表示される点である。これによりリソース管理者は、リソース構成候補を選択する際に、この稼働実績を参照して、ユーザのニーズにあったリソース構成を選択し易くなる。

以上のように本実施の形態による計算機システム１００では、各機能のそれまでの稼働実績に基づいて機能要件を選択できるため、第２の実施の形態による計算機システム８０と同様に、リソース管理者の負荷を軽減することができる。

（４）他の実施の形態
なお上述の第１〜第３の実施の形態においては、本発明を図１、図１９又は図２２のように構成された計算機システム１，８０，１００に適用するようにした場合について述べたが、本発明はこれに限らず、この他種々の構成の計算機システムに広く適用することができる。

また上述の第１〜第３の実施の形態においては、リソース管理プログラム３０，８２，１０２の要求取得部３１，１０３構成取得部３２等の処理をプログラムとして構成するようにした場合について述べたが、本発明はこれに限らず、例えばその一部又は全部をハードウェア構成とするようにしても良い。

さらに上述の第１〜第３の実施の形態においては、リソース要求設定画面５０，９０１１０を図８、図２１又は図２５のように構成するようにした場合について述べたが、本発明はこれに限らず、かかるリソース要求設定画面の構成としては、この他種々の構成を適用することができる。

同様に、上述の第１〜第３の実施の形態においては、リソース構成候補選択画面７０，１２０を図１４又は図２７のように構成するようにした場合について述べたが、本発明はこれに限らず、かかるリソース構成候補選択画面の構成としては、この他種々の構成を適用することができる。

第１の実施の形態による計算機システムの概略構成を示すブロック図である。 サーバの構成を示すブロック図である。 機能テーブルの構成を示す図表である。 リソーステーブルの構成を示す図表である。 構成テーブルの構成を示す図表である。 要求テーブルの構成を示す図表である。 リソース管理プログラムに基づき実行されるリソース管理処理の流れを示すフローチャートである。 要求取得処理の処理手順を示すフローチャートである。 リソース要求設定画面の概略構成を示す略線図である。 構成取得処理の処理手順を示すフローチャートである。 検索処理の処理手順を示すフローチャートである。 既存用リソース構成検索処理の処理手順を示すフローチャートである。 新規用リソース構成検索処理の処理手順を示すフローチャートである。 リソース構成候補選択画面の概略構成を示す略線図である。 構成処理の処理手順を示すフローチャートである。 割当て処理の処理手順を示すフローチャートである。 変更検知処理の処理手順を示すフローチャートである。 解除処理の処理手順を示すフローチャートである。 第２の実施の形態による計算機システムの概略構成を示すブロック図である。 対応テーブルの構成を示す図表である。 第２の実施の形態によるリソース要求設定画面の概略構成を示す略線図である。 第３の実施の形態による計算機システムの概略構成を示すブロック図である。 稼働実績テーブルの構成を示す図表である。 第３の実施の形態による要求取得処理の処理手順を示すフローチャートである。 第３の実施の形態によるリソース要求設定画面の概略構成を示す略線図である。 第３の実施の形態による検索処理の処理手順を示すフローチャートである。 第３の実施の形態によるリソース構成候補選択画面の概略構成を示す略線図である。

１，８０，１００……計算機システム、２……クライアント、３，８１，１０１……管理サーバ、４……リソース群、６……サーバ、１０，２０……ＣＰＵ、１１，２１……メモリ、１４……入力装置、１５……出力装置、３０，８２，１０２……リソース管理プログラム、３１，８３，１０３……要求取得部、３２……構成取得部、３３……検索部、３４……構成部、３５……割当て部、３６……変更検知部、３７……解除部、３８，８４，１０５……インタフェース部、４０，８５，１０６……テーブル群、４１……機能テーブル、４２……リソーステーブル、４３……構成テーブル、４４……要求テーブル、５０，９０，１１０……リソース要求設定画面、７０，１２０……リソース構成候補選択画面、８６……対応テーブル、稼働実績管理テーブル。

Claims (12)

1. 複数の計算機リソースを管理し、計算機リソースの割り当てを要求するリソース要求に応じて、要求された計算機リソースをユーザに割り当てる管理装置において、
   前記リソース要求には、割り当てを要求する前記計算機リソースの性能要件及び機能要件が含まれ、
   前記リソース要求において前記機能要件として要求される各機能にそれぞれ対応付けて、当該機能を構成するために必要となる計算機リソースの種別及び当該計算機リソースの必要数を構成条件として保持すると共に、各前記計算機リソースが備える性能及び機能をリソース情報として保持するメモリと、
   前記メモリに保持された前記構成条件及び前記リソース情報に基づいて、前記リソース要求において指定された前記機能要件を満たし、かつ当該リソース要求において指定された前記性能要件を満たす計算機リソースを前記複数の計算機リソースの中から検索し、検索結果に基づいて前記ユーザに割り当てる計算機リソースを決定する検索部と、
   該検索部により決定された計算機リソースを前記ユーザに割り当てる割当て部と
   を備えることを特徴とする管理装置。
2. 前記リソース要求において指定された前記機能要件に応じた機能を構成する構成部を備え、
   前記構成部は、
   既に構成されている計算機リソースの機能の構成を必要に応じて解除し、
   当該機能を解除した計算機リソースを用いて前記リソース要求において前記機能要件として指定された機能を構成する
   ことを特徴とする請求項１に記載の管理装置。
3. 前記メモリは、前記計算機リソースごとの利用コストを保持し、
   前記検索部は、
   前記計算機リソースごとの前記利用コストに基づいて、前記ユーザに割り当てる計算機リソースを決定する
   ことを特徴とする請求項１記載の管理装置。
4. 前記メモリは、稼動実績に基づく前記機能の実績値を保持し、
   前記リソース要求において要求する前記性能要件及び前記機能要件を設定するための設定画面を表示すると共に、前記設定画面上で選択された前記機能要件を構成する前記機能の前記実績値を前記設定画面上に表示するインタフェース部を備える
   ことを特徴とする請求項１に記載の管理装置。
5. 複数の計算機リソースを管理し、計算機リソースの割り当てを要求するリソース要求に応じて、要求された計算機リソースをユーザに割り当てる管理装置において実行される管理方法であって、
   前記リソース要求には、割り当てを要求する前記計算機リソースの性能要件及び機能要件が含まれ、
   前記管理装置が、前記リソース要求において前記機能要件として要求される各機能にそれぞれ対応付けて、当該機能を構成するために必要となる計算機リソースの種別及び当該計算機リソースの必要数を構成条件として保持すると共に、各前記計算機リソースが備える性能及び機能をリソース情報として保持する第１のステップと、
   前記管理装置が、保持した前記構成条件及び前記リソース情報に基づいて、前記リソース要求において指定された前記機能要件を満たし、かつ当該リソース要求において指定された前記性能要件を満たす計算機リソースを前記複数の計算機リソースの中から検索し、検索結果に基づいて前記ユーザに割り当てる計算機リソースを決定する第２のステップと、
   前記管理装置が、決定した計算機リソースを前記ユーザに割り当てる第３のステップと
   を備えることを特徴とする管理方法。
6. 前記第２のステップにおいて、前記管理装置は、
   既に構成されている計算機リソースの機能の構成を必要に応じて解除し、
   当該機能を解除した計算機リソースを用いて前記リソース要求において前記機能要件として指定された機能を構成する
   ことを特徴とする請求項５に記載の管理方法。
7. 前記管理装置は、前記計算機リソースごとの利用コストを保持し、
   前記第２のステップにおいて、前記管理装置は、
   前記計算機リソースごとの前記利用コストに基づいて、前記ユーザに割り当てる計算機リソースを決定する
   ことを特徴とする請求項５に記載の管理方法。
8. 前記管理装置は、
   稼動実績に基づく前記機能の実績値を保持し、
   前記リソース要求において要求する前記性能要件及び前記機能要件を設定するための設定画面を表示すると共に、前記設定画面上で選択された前記機能要件を構成する前記機能の前記実績値を前記設定画面上に表示する
   ことを特徴とする請求項５に記載の管理方法。
9. ユーザが使用するコンピュータ装置でなるクライアントと、
   複数の計算機リソースと、
   前記複数の計算機リソースを管理し、計算機リソースの割り当てを要求する前記クライアントからのリソース要求に応じて、要求された計算機リソースを当該クライアントに割り当てる管理装置と
   を有し、
   前記リソース要求には、割り当てを要求する前記計算機リソースの性能要件及び機能要件が含まれ、
   前記管理装置は、
   前記リソース要求において前記機能要件として要求される各機能にそれぞれ対応付けて、当該機能を構成するために必要となるリソースの種別及び当該リソースの必要数を構成条件として保持すると共に、各前記計算機リソースが備える性能及び機能をリソース情報として保持するメモリと、
   前記メモリに保持された前記構成条件及び前記リソース情報に基づいて、前記リソース要求において指定された前記機能要件を満たし、かつ当該リソース要求において指定された前記性能要件を満たす計算機リソースを前記複数の計算機リソースの中から検索し、検索結果に基づいて前記クライアントに割り当てる計算機リソースを決定する検索部と、
   決定した計算機リソースを前記クライアントに割り当てる割当て部とを備える
   ことを特徴とする計算機システム。
10. 前記管理装置は、
    前記リソース要求において指定された前記機能要件に応じた機能を構成する構成部を備え、
    前記構成部は、
    既に構成されている計算機リソースの機能の構成を必要に応じて解除し、
    当該機能を解除した計算機リソースを用いて前記リソース要求において前記機能要件として指定された機能を構成する
    ことを特徴とする請求項９に記載の計算機システム。
11. 前記メモリは、前記計算機リソースごとの利用コストを保持し、
    前記検索部は、
    前記計算機リソースごとの前記利用コストに基づいて、前記クライアントに割り当てる計算機リソースを決定する
    ことを特徴とする請求項９に記載の計算機システム。
12. 前記メモリは、稼動実績に基づく前記機能の実績値を保持し、
    前記管理装置は、
    前記リソース要求において要求する前記性能要件及び前記機能要件を設定するための設定画面を表示すると共に、前記設定画面上で選択された前記機能要件を構成する前記機能の前記実績値を前記設定画面上に表示するインタフェース部を備える
    ことを特徴とする請求項９に記載の計算機システム。

Images