知財求人 - 知財ポータルサイト「IP Force」
特開2024-134595リソース管理装置、リソース管理システム、リソース管理方法、およびプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024134595
(43)【公開日】2024-10-04
(54)【発明の名称】リソース管理装置、リソース管理システム、リソース管理方法、およびプログラム
(51)【国際特許分類】
G06Q 10/20 20230101AFI20240927BHJP
G06F 9/50 20060101ALI20240927BHJP
【ＦＩ】
G06Q10/20
G06F9/50 120Z
【審査請求】未請求
【請求項の数】10
【出願形態】ＯＬ
(21)【出願番号】P 2023044864
(22)【出願日】2023-03-22
(71)【出願人】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100149548
【弁理士】
【氏名又は名称】松沼 泰史
(74)【代理人】
【識別番号】100181135
【弁理士】
【氏名又は名称】橋本 隆史
(72)【発明者】
【氏名】後藤 忍
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049CC15
(57)【要約】
【課題】リソース（デバイス）の特性に基づいて、サービスレベルを満たすリソースの払い出しを行うことのできるリソース管理装置を提供する。
【解決手段】リソース管理装置は、動的構成可能ノード装置を制御するため、リソース属性記憶部とリソース管理部とを備える。リソース属性記憶部は、リソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性を記憶する。リソース管理部は、サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、リソース属性記憶部を参照することによってサービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように動的構成可能ノード装置を制御する。
【選択図】図１
【解決手段】リソース管理装置は、動的構成可能ノード装置を制御するため、リソース属性記憶部とリソース管理部とを備える。リソース属性記憶部は、リソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性を記憶する。リソース管理部は、サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、リソース属性記憶部を参照することによってサービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように動的構成可能ノード装置を制御する。
【選択図】図１
【特許請求の範囲】
【請求項1】
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備えるリソース管理装置。
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備えるリソース管理装置。
【請求項2】
前記リソース管理部は、構築した前記ノードを解体する要求を受け付け、当該解体するノードに割り当てられていた前記リソースを解放する処理を行うとともに、当該ノードを解体するように前記動的構成可能ノード装置を制御する、
請求項１に記載のリソース管理装置。
請求項１に記載のリソース管理装置。
【請求項3】
前記リソース属性記憶部は、前記リソース属性のうちの、型式に共通な属性情報を型式属性として記憶する型式属性記憶部、を含む、
請求項１に記載のリソース管理装置。
請求項１に記載のリソース管理装置。
【請求項4】
前記ノード構築の要求は、前記リソースの規模を表す規模情報に関する条件を含み、
前記リソース属性記憶部は、前記規模情報を含む前記リソース属性を記憶し、
前記リソース管理部は、前記ノード構築の要求に含まれる前記規模情報に基づいて、前記リソース属性記憶部を参照することによって、前記規模情報に関する条件に合う前記リソースを、構築するノードに割り当てる、
請求項１に記載のリソース管理装置。
前記リソース属性記憶部は、前記規模情報を含む前記リソース属性を記憶し、
前記リソース管理部は、前記ノード構築の要求に含まれる前記規模情報に基づいて、前記リソース属性記憶部を参照することによって、前記規模情報に関する条件に合う前記リソースを、構築するノードに割り当てる、
請求項１に記載のリソース管理装置。
【請求項5】
前記サービスレベルは、構築されるノードに含まれる前記リソースの許容故障率の情報を含み、
前記リソース属性記憶部は、前記リソースの故障率または前記リソースが属する型式の故障率、を記憶し、
前記リソース管理部は、前記リソース属性記憶部を参照することによって、前記ノード構築の要求に含まれる前記許容故障率以下の故障率のリソースを、構築するノードに割り当てる、
請求項１に記載のリソース管理装置。
前記リソース属性記憶部は、前記リソースの故障率または前記リソースが属する型式の故障率、を記憶し、
前記リソース管理部は、前記リソース属性記憶部を参照することによって、前記ノード構築の要求に含まれる前記許容故障率以下の故障率のリソースを、構築するノードに割り当てる、
請求項１に記載のリソース管理装置。
【請求項6】
前記リソース管理部は、前記動的構成可能ノード装置から受け取る個々の前記リソースの故障のイベントの通知に基づいて統計処理を行うことにより、前記リソース属性記憶部が記憶する前記故障率を更新する、
請求項５に記載のリソース管理装置。
請求項５に記載のリソース管理装置。
【請求項7】
前記サービスレベルは、構築されるノードの最低稼働時間の情報を含み、
前記リソース属性記憶部は、個々の前記リソースごとの過去の累積の稼働時間と、前記リソースの製品としての耐久時間または前記リソースが属する型式の製品としての耐久時間と、を記憶し、
前記リソース管理部は、前記過去の累積の稼働時間と前記最低稼働時間との和が、前記耐久時間を超えないように、リソースを選択し、選択された前記リソースをノードに割り当てる、
請求項１に記載のリソース管理装置。
前記リソース属性記憶部は、個々の前記リソースごとの過去の累積の稼働時間と、前記リソースの製品としての耐久時間または前記リソースが属する型式の製品としての耐久時間と、を記憶し、
前記リソース管理部は、前記過去の累積の稼働時間と前記最低稼働時間との和が、前記耐久時間を超えないように、リソースを選択し、選択された前記リソースをノードに割り当てる、
請求項１に記載のリソース管理装置。
【請求項8】
動的構成可能ノード装置と、リソース管理装置と、を含むリソース管理システムであって、
前記動的構成可能ノード装置は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する装置であり、
前記リソース管理装置は、
前記動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備えるリソース管理装置である、
リソース管理システム。
前記動的構成可能ノード装置は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する装置であり、
前記リソース管理装置は、
前記動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備えるリソース管理装置である、
リソース管理システム。
【請求項9】
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理方法であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部に記憶し、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理過程、
を含んだリソース管理方法。
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部に記憶し、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理過程、
を含んだリソース管理方法。
【請求項10】
リソース管理装置としてコンピューターを機能させるためのプログラムであって、
前記リソース管理装置は、
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備える、
プログラム。
前記リソース管理装置は、
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備える、
プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、リソース管理装置、リソース管理システム、リソース管理方法、およびプログラムに関する。
【背景技術】
【0002】
近年、データセンター管理の領域においてハードウェアの動的構成を可能とするインフラストラクチャーが注目を浴びている。この分野においては、ＤＭＴＦのＲｅｄｆｉｓｈ Ｃｏｍｐｏｓａｂｉｌｉｔｙなど、業界団体による標準化が進められている。このような特徴を有するインフラストラクチャーにおいて、複数のデバイスから構成されるノードのサービスレベルやライフサイクルを適切に管理するためには、個々のデバイスの使用実績や型式ごとの特性を元に信頼性を評価し、与えられた基準を満たす信頼性を有するデバイス（部品）同士でノードを構成することが重要である。
【0003】
ＣＰＵ（中央演算処理装置）や主記憶装置や二次記憶装置などといったデバイスを、要求等に基づいて結合することで計算機のインスタンス、即ちノードを動的に構成する機能を有するハードウェア装置が存在し、また、上記のようなハードウェア装置におけるノードの構成を管理するためのシステムがある。そのシステムは、上記のようなハードウェア装置に搭載されたデバイスの集合、即ちノードを構成するためのデバイスの集合を、リソース（資源）の集合（即ち、リソースプール）として抽象化して管理する。そのシステムは、クライアントからの要求にしたがってリソースプールから必要なリソースを払い出すことによってノードを構築する。以下においては、このようなシステムをリソース管理システムと呼称する。
【0004】
一般に、クライアント側からのリソース管理システムに対する要求には、構築対象のノードの諸元の情報が含まれる。ここでノードの諸元の情報とは、即ちＣＰＵのコア数や、主記憶装置のサイズや、二次記憶装置のサイズや、ネットワークインターフェースカードのポート数などといった、ノードを構成するリソースの種別ごとのスペックおよび数量の情報を含むものである。
【0005】
一方、クライアント側からリソース管理システムに対する要求として、付加情報を含めることのできるリソース管理システムもある。ここで付加情報とは、ノードが提供するサービスに関する要件の情報を含む。具体的には、付加情報は、ノードの品質やライフサイクルを指定するための情報であり、サービスレベルに関する情報やサービス期間に関する情報を含む。サービスレベルは、サービスの業務上の重要度の水準を表すものである。ノードの重要度に応じた信頼性を有するリソースを適切に払い出してノードを構築することが求められる。また、サービス期間は、サービスを提供する期間を事前に指定するものである。
【0006】
リソースの実体はデバイス、即ちハードウェアである。ハードウェアであるデバイスの故障率は、使用実績によって変動するという特性がある。例えば、長期間使用されたデバイスは老朽化により故障しやすい（故障率が相対的に高い）という傾向がある。また、初めて利用されるデバイスにおいては初期不良が起きやすく、その分故障率が高まるという傾向がある。さらに、デバイスを製造するメーカーやデバイスの型式（型番）によっても故障率が異なるという特性もある。
【0007】
特許文献１の段落００１３には、「システム配置決定システムは、システム配置決定装置１０を備える。さらに、システム配置決定装置１０は、ＳＬＡ解析手段１と、構成決定手段２と、パターンＤＢ記憶手段３と、台数決定手段４とを備える。」という記載がある。また、特許文献１の段落００２１－００２２には、「パターンＤＢ記憶手段３は、構築対象システムへの採用候補となる各サーバに関する情報をデータベースとして記憶する記憶装置である。」という記載や、「採用候補となる個々のサーバ毎に、「サーバ名」、「故障率」、・・・を記憶する。」という記載がある。また、特許文献１の段落００３０－００３１には、「構成決定手段２は、故障率が、ＳＬＡから導出された故障率未満となっているサーバであって、構築対象システム以外のシステムで未だ使用されていないサーバのリストを作成する。」という記載や、「台数決定手段４は、・・・ＳＬＡ１１で規定された要求処理量を満たす台数を計算し」という記載がある。
【0008】
特許文献２の段落００６０には、「通常、コンポーザブルインフラストラクチャのサーバーの１つは、アドミニストレーターとして動作するように構成（プログラム）される。一般的な実施形態では、アドミニストレーターは、ストレージグループメンバーシップに従ってシステムのサーバーにドライブを割り当てることや、通常は、ドライブが割り当てられているサーバーのデータ配置ポリシーを実行することを含む、管理プロセスを実行するアプリケーションを実行するようにプログラムされている。」という記載がある。
【0009】
特許文献３の段落００１６には、「取得部１０１は、サーバ３００ごとのハードウェア監視情報、稼働情報、及び、動作環境に関する情報を取得する。ハードウェア監視情報は、サーバ３００内部の各部品の異常傾向を判定するためのハードウェア監視データを示す。稼働情報は、例えば初期配置からの稼働時間、または使用年数など、サーバ３００の稼働状況を示す。・・・さらに、取得部１０１は、算出部１０２が算出した、各サーバ３００のハードウェア、稼働情報、及び、動作環境に基づく個体故障率を取得する。」という記載がある。
【0010】
特許文献４の段落００２３には、「図１は、本発明の第１の実施形態におけるリソース割り当てシステム２００の構成例を示すブロック図である。リソース割り当てシステム２００は、１つまたは複数の物理インフラストラクチャ２７から通信サービス要求に最適量のリソースを割り当てる役割を担う。」という記載がある。また、特許文献４の段落００２４には、「通信サービス要求は、サービス要求とともにユーザによって指定された全てのサービスレベルに関する約束および性能期待を満たす。」という記載がある。また、特許文献４の段落００４７には、「本実施形態によれば、リソース割り当てシステム２００は、サービスに対する信頼性の期待を満たすのに十分なだけの信頼性を割り当てることによって、信頼性のあるリソースの最適な利用を実現できる。」という記載がある。
【0011】
特許文献５の段落００２４には、「リソースプール３は、１または複数の物理サーバであるサーバ４と、リソースプール管理サーバ５を含んで構成される。・・・リソースプール管理サーバ５は、サービス運用端末６を介してオペレータの操作を受付け、その指示によって各サーバ４に仮想マシンを具現化する。」という記載がある。また、特許文献５の段落００２９には、「集計部５８は、サーバ状態管理データベース５７を参照して、ＶＭイメージファイル５４１毎にハードウェア仕様と稼働時間の分布を集計する。これにより、リソースプール３の運用者は、ハードウェア（仕様情報）とソフトウェア（ＶＭイメージ）の各組み合わせにおける各稼働率を把握し、それら特定の組み合わせにおける稼働率の低下も把握することができる。」という記載がある。
【先行技術文献】
【特許文献】
【0012】
【特許文献1】国際公開第２０１１／０５２１４９号
【特許文献2】特表２０２２－５１７８９０号公報
【特許文献3】特開２０２２－０８７３７１号公報
【特許文献4】特表２０２０－５０４５５２号公報
【特許文献5】特開２０１５－２１５８５７号公報
【発明の概要】
【発明が解決しようとする課題】
【0013】
背景となる関連技術では、リソースプールにおいて様々なリソース（デバイス）が混在して管理されるため、要求されるサービスレベルに対して適切な信頼性をもつリソースを払い出すことが難しいという課題があった。また、デバイスのメーカーによってはデバイスのサポート期間や耐久年数を定めているケースがあるが、これらのデバイスの属性を考慮せずにリソースとして払い出してしまうと、ノードのサービス期間内にサポート切れあるいは耐久年数を迎えてしまう可能性があり、サービスの信頼性の低下につながるという問題もあった。
【0014】
本発明は、上記のような事情を考慮して為されたものであり、個々のデバイスの属性や、デバイスの型式ごとの特性（メーカーが定めたサポート期間あるいは耐用年数や、当該型式（あるいはそのロット）の製品（デバイス）が実際にどの程度の時期に故障するか）を考慮して、ＳＬＡ（サービスレベルアグリーメント）を満たすリソースの払い出しを行うが解決すべき課題である。
【0015】
そこでこの発明は、上述の課題を解決するリソース管理装置、リソース管理システム、リソース管理方法、およびプログラムを提供することを目的としている。
【課題を解決するための手段】
【0016】
［１］上記の課題を解決するため、本発明の一態様は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、１と、を備えるリソース管理装置である。
【0017】
［８］また、本発明の一態様は、動的構成可能ノード装置と、リソース管理装置と、を含むリソース管理システムであって、前記動的構成可能ノード装置は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する装置であり、前記リソース管理装置は、前記動的構成可能ノード装置を制御するためのリソース管理装置であって、個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、を備えるリソース管理装置である、リソース管理システムである。
【0018】
［９］また、本発明の一態様は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理方法であって、個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部に記憶し、前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理過程、を含んだリソース管理方法である。
【0019】
［１０］また、本発明の一態様は、リソース管理装置としてコンピューターを機能させるためのプログラムであって、前記リソース管理装置は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、を備える、プログラムである。
【発明の効果】
【0020】
本発明によれば、個々のリソースの属性に基づいて、要求されるサービスレベルを満足するノードを構築するように、リソースの割り当てを行うことができる。
【図面の簡単な説明】
【0021】
【図1】本発明の第１実施形態によるリソース管理システムの概略機能構成を示すブロック図である。
【図2】同実施形態によるリソース管理サーバー装置のリソース管理部が管理する型式テーブルの概略構成を示す概略図である。
【図3】同実施形態によるリソース管理サーバー装置のリソース管理部が管理するリソーステーブルの概略構成を示す概略図である。
【図4】同実施形態によるリソース管理サーバー装置のリソース管理部が管理するサービスレベルテーブルの概略構成を示す概略図である。
【図5】同実施形態によるリソース管理サーバー装置のリソース管理部が、クライアント装置からの要求に基づいてノードの構築を行う処理の手順を示すフローチャートである。
【図6】同実施形態によるリソース管理サーバー装置のリソース管理部が、特定の種別のリソース（デバイス）のリソースＩＤを取得する処理の手順を示すフローチャートである。
【図7】同実施形態によるリソース管理サーバー装置のリソース管理部が、クライアント装置からの要求に基づいてノードの解体を行う処理の手順を示すフローチャートである。
【図8】同実施形態によるリソース管理サーバー装置のリソース管理部が、ＣＤＩ装置から受け取るイベント通知に基づいて、リソース（デバイス）の故障に対応する処理の手順を示すフローチャートである。
【図9】第２実施形態によるリソース管理システムの概略機能構成を示すブロック図である。
【図10】第３実施形態によるリソース装置の最小構成の例を示す機能ブロック図である。
【発明を実施するための形態】
【0022】
次に、本発明の複数の実施形態について、図面を参照しながら説明する。
【0023】
実施形態は、動的構成可能ノード装置の存在を前提とする。以下において、この動的構成可能ノード装置を「ＣＤＩ装置」とも呼ぶ。ＣＤＩ装置は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する装置である。ＣＤＩ装置において１つまたは複数のノードが同時並行的に稼働し得る。ノードは、所謂コンピューターの機能を有し、通常は、演算装置と主記憶装置とネットワークインターフェース装置とを含んで構成される。また、ノードは、多くの場合に二次記憶装置を含んで構成される。
【0024】
演算装置は、下の実施形態において説明する種別として、ＣＰＵ、ＤＳＰ、ＦＰＧＡ、およびＧＰＵ等と呼ばれるものを含む。複数の種別の演算装置が協調して動作するようにノードを構成する場合もある。主記憶装置は、種別として、ＤＩＭＭ、ＤＲＡＭ、およびＮＶＤＩＭＭ等と呼ばれるものを含む。二次記憶装置は、種別として、ＳＳＤ、およびＨＤＤ等と呼ばれるものを含む。ネットワークインターフェース装置は、種別として、ＮＩＣ等と呼ばれるものを含む。ノードを構築するための要求としてリソース管理サーバー装置が受け取る情報としては、どの種別のリソースを含んでノードを構成するかという構成情報が含まれる。各種別の個々のリソースは、リソース属性記憶部が記憶する情報（リソース属性）を用いて管理され得る。また、リソースには型式ＩＤが存在してよい。リソース属性のうち、型式内で共通の属性は、型式属性として管理される場合もある。型式の属性は、型式属性記憶部によって記憶される。
【0025】
リソースは、ノードを構成するためのデバイス（ハードウェアコンポーネント、ハードウェア構成要素、ハードウェア部品）を抽象的に呼ぶ呼び方である。未使用のリソースはリソースプールに属するリソースとして管理される。ノードを構築する際には、リソースプール内から選ばれたリソースをノードに割り当てる。ノードを解体する際には、リソースはその割り当てから解放され、リソースプールに戻される。
【0026】
リソース等を管理するためのデータを、下の実施形態では、リレーショナルモデルに基づいて表現している。リレーショナルモデルにおいて、テーブルに属する１つの行（レコードと呼んでもよい）は、実体（エンティティ）に対応する。テーブルは、通常において、エンティティを識別するためのキーと、そのエンティティの属性情報とを格納する。テーブルに対する操作として、行の挿入や、行のデータの更新や、行の削除等が可能である。こういった操作は、例えばＳＱＬ文を用いて行われ得る。ＳＱＬ文の条件節において操作対象の行に関する条件を記述することが可能である。これにより条件に合う行のみを操作対象とすることできる。また、ＳＱＬ文のＣＯＵＮＴ関数を用いることにより、所定の条件に該当する行の数をカウントすることができる。なお、ＳＱＬ以外の方法でデータにアクセスするようにしてもよい。また、リレーショナルモデル以外のモデルを用いてデータを表現してもよい。
【0027】
［第１実施形態］
図１は、第１実施形態によるリソース管理システムの概略機能構成を示すブロック図である。図示するように、リソース管理システム１０００は、リソース管理サーバー装置１と、ＣＤＩ装置２と、クライアント装置３とを含んで構成される。リソース管理サーバー装置１とＣＤＩ装置２とクライアント装置３のそれぞれの少なくとも一部の機能は、コンピューターとプログラムとで実現することが可能である。またこれらの装置のそれぞれは、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ（ＳＳＤ）といった不揮発性の記憶手段を用いるようにしてもよい。また、上に挙げた装置の少なくとも一部の機能を、プログラムではなく専用の電子回路として実現してもよい。
図１は、第１実施形態によるリソース管理システムの概略機能構成を示すブロック図である。図示するように、リソース管理システム１０００は、リソース管理サーバー装置１と、ＣＤＩ装置２と、クライアント装置３とを含んで構成される。リソース管理サーバー装置１とＣＤＩ装置２とクライアント装置３のそれぞれの少なくとも一部の機能は、コンピューターとプログラムとで実現することが可能である。またこれらの装置のそれぞれは、必要に応じて、記憶手段を有する。記憶手段は、例えば、プログラム上の変数や、プログラムの実行によりアロケーションされるメモリーである。また、必要に応じて、磁気ハードディスク装置やソリッドステートドライブ（ＳＳＤ）といった不揮発性の記憶手段を用いるようにしてもよい。また、上に挙げた装置の少なくとも一部の機能を、プログラムではなく専用の電子回路として実現してもよい。
【0028】
リソース管理サーバー装置１は、リソース管理システムの管理を行うためのサーバーである。リソース管理サーバー装置１は、主に、ＣＤＩ装置２内におけるノードを構築したり解体したりする機能を持つ。言い換えれば、リソース管理サーバー装置１は、ＣＤＩ装置２を制御するための装置である。リソース管理サーバー装置１は、リソース管理部１１と、構成情報データベース１２と、を含んで構成される。なお、リソース管理サーバー装置１は、「リソース管理装置」とも呼ばれる。
【0029】
リソース管理部１１は、例えば、コンピューターの演算装置上でリソース管理プログラムを実行させることによって実現される。リソース管理部１１は本実施形態の中核の機能である。リソース管理部１１は、クライアント装置３からの要求を受信する。また、リソース管理部１１は、クライアント装置からの要求等に基づいてＣＤＩ装置２を制御することによって、ＣＤＩ装置２内におけるノードの構築や、ノードの構成変更や、ノードの解体を実施する。また、ＣＤＩ装置２内におけるリソースに障害が発生した場合には、ＣＤＩ装置２から通知されるイベントを受信することによって、リソース管理部１１は、そのリソースに障害（故障等）が発生したことを認識する。
【0030】
リソース管理部１１は、サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、リソース属性記憶部（型式テーブル４やリソーステーブル５）を参照することによってサービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するようにＣＤＩ装置２を制御する。また、リソース管理部１１は、構築したノードを解体する要求を受け付け、当該解体するノードに割り当てられていたリソースを解放する処理を行うとともに、当該ノードを解体するようにＣＤＩ装置２を制御する。
【0031】
また、リソース管理部１１は、ノード構築の要求に含まれる規模情報（例えば、ＣＰＵのコア数や、主記憶装置あるいは２次記憶装置の容量や、ネットワークインターフェース数などといった情報）に基づいて、リソース属性記憶部を参照することによって、規模情報に関する条件に合うリソースを、構築するノードに割り当てる。
【0032】
また、リソース管理部１１は、リソース属性記憶部（型式テーブル４やリソーステーブル５）を参照することによって、ノード構築の要求に含まれる許容故障率（このとき、要求されるサービスレベルは、構築されるノードに含まれるリソースの許容故障率の情報を含む。許容故障率は、サービスレベルテーブル６に記録されているものであってよい。）以下の故障率のリソースを、構築するノードに割り当てるようにしてもよい。また、リソース属性記憶部は、前記リソースの故障率または前記リソースが属する型式の故障率、を記憶する。
【0033】
また、リソース管理部１１は、ＣＤＩ装置２から受け取る個々のリソース（デバイス）の故障のイベントの通知に基づいて統計処理を行うことにより、リソース属性記憶部（例えば型式テーブル４）が記憶する故障率を更新するものであってよい。リソース管理部１１が故障の統計処理を行って型式テーブルを更新する処理の手順については、後で図８を参照しながら説明する。
【0034】
また、リソース管理部１１は、リソースの過去の累積の稼働時間と、要求されるノードの最低稼働時間との和が、リソースの耐久時間を超えないように、リソースを選択し、選択されたリソースをノードに割り当てるようにしてよい。このとき、構築されるノードの最低稼働時間は、サービスレベルの少なくとも一部として定義される。また、リソース属性記憶部（型式テーブル４やリソーステーブル５）は、個々のリソースごとの過去の累積の稼働時間と、リソースの製品としての耐久時間またはリソースが属する型式の製品としての耐久時間と、を記憶するようにしておく。
【0035】
構成情報データベース１２は、リソース管理部１１が構成情報を格納するために利用するデータベースである。構成情報データベース１２には、個々のリソースの状態や、ノードへの割り当て状況、型式ごとの属性情報が格納される。具体的には、構成情報データベース１２は、少なくとも、型式テーブル４と、リソーステーブル５と、サービスレベルテーブル６とを保持する。これら型式テーブル４、リソーステーブル５、およびサービスレベルテーブル６の構成およびデータ例については、後で別の図を参照しながら説明する。なお、型式テーブル４は、型式に特有の属性を格納するテーブルであり、「型式属性記憶部」とも呼ばれる。また、型式テーブル４およびリソーステーブル５とは、リソースの属性（個々のリソース（個体）に特有の属性と、型式に共通な属性とを含む）を格納するテーブルであり、「リソース属性記憶部」とも呼ばれる。つまり、リソース属性記憶部（型式テーブル４およびリソーステーブル５）は、リソース属性のうちの、型式に共通な属性情報を型式属性として記憶する型式属性記憶部（型式テーブル４）を含む。また、サービスレベルテーブル６を、サービスレベル記憶部と呼んでもよい。つまり、リソース属性記憶部は、サービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶する。サービスレベルは、個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだものである。
【0036】
ＣＤＩ装置２は、計算機とデバイスとの分離および結合を特徴とするインフラストラクチャーを具現化する装置である。ＣＤＩは、「Composable Disaggregated Infrastructure」の略であり、構成可能な、分離されたデバイスリソースによるインフラストラクチャーを意味する。ＣＤＩ装置２は、複数の種別のデバイスリソースを共有可能なリソースプールに集約しておき、要求に応じてそのリソースプールから必要なデバイスリソースを払い出して割り当てる機能を持つ。つまり、ＣＤＩ装置２は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する。
これにより、ＣＤＩ装置２は、リモートからの要求に応じて動的にノードを構築したり解体したりする。このように構築されるノードは、適用領域においてサーバーコンピューター等として機能する。ＣＤＩ装置２は、リソースを動的に割り当てることによって１つまたは複数のノードを構成して稼働させることが可能な装置であり、「動的構成可能ノード装置」とも呼ばれる。
これにより、ＣＤＩ装置２は、リモートからの要求に応じて動的にノードを構築したり解体したりする。このように構築されるノードは、適用領域においてサーバーコンピューター等として機能する。ＣＤＩ装置２は、リソースを動的に割り当てることによって１つまたは複数のノードを構成して稼働させることが可能な装置であり、「動的構成可能ノード装置」とも呼ばれる。
【0037】
本実施形態のＣＤＩ装置２は、ＣＰＵ（Central Processing Unit、中央演算処理装置）、ＤＩＭＭ（Dual Inline Memory Module、ディム、基盤の両面に例えばＤＲＡＭを搭載したメモリーモジュール）、ＳＳＤ（Solid State Drive、半導体ドライブ)、ＮＩＣ（Network Interface Card、ネットワークインターフェースカード）などといった種別のデバイスを複数有している。図１に示す構成では、ＣＤＩ装置２は、ＣＰＵ２０１，２０２，２０３，・・・と、ＤＩＭＭ２１１，２１２，２１３，・・・と、ＳＳＤ２２１，２２２，２２３，・・・と、ＮＩＣ２３１，２３２，２３３，・・・とを備える。なお、ＣＤＩ装置２自体は、既存の技術を用いて実現され得る。
【0038】
リソース管理サーバー装置１上のリソース管理部１１は、ＣＤＩ装置２上の個々のデバイスをリソースとして管理するとともに、これらのリソースの集合をリソースプールとして管理する。図１に示す状況の例では、リソースプールから払い出された複数のリソース（本例では、ＣＰＵ２０２と、ＤＩＭＭ２１２と、ＳＳＤ２２２と、ＮＩＣ２３２）を結合することによってノード２１が構築されている。
【0039】
クライアント装置３は、ＣＤＩ装置２上で構築されるノードに関する要求を、リソース管理サーバー装置１に対して行うための端末装置である。クライアント装置３は、その利用者の操作等に基づいて、ノードの構築や、ノードの構成変更や、ノードの解体などといった事項に関する要求を、リソース管理サーバー装置１のリソース管理部１１に送信することができる。また、これらの要求には、ノードのサービスレベルやサービス期間などといった付加情報が含まれる場合もある。
【0040】
図２は、リソース管理サーバー装置１のリソース管理部１１が管理する型式テーブル４の概略構成を示す概略図である。この型式テーブルは、リソース（デバイス）の型式ごとの属性（特性）に関する情報を保持するテーブルである。図示するように、型式テーブルは、例えば表形式のデータとして実現され得る。ただし、この型式テーブルと等価な情報を他の形式のデータとして保持するようにしてもよい。この型式テーブルは、構成情報データベース１２に格納され得る。この型式テーブルの各行は、リソース（デバイス）の形式に対応する。つまり、特定のメーカーが製造する特定の型番のデバイスの属性が、型式テーブルの１行に保持される。ただし、型番は異なっていても類似の複数の型式のデバイスの情報を、型式テーブルの１行の中に記述してもよい。また、一つの型番のデバイスをさらに複数のタイプに分けてそれぞれのタイプの情報を型式テーブルの１行の中に記述してもよい。前述の通り、型式テーブル４は、リソース属性記憶部の一部であり、且つ型式属性記憶部の全部または一部である。
【0041】
図２に示すように、型式テーブル４は、型式ＩＤ、種別、数量、耐久時間、故障率というそれぞれの列（データ項目）を有する。耐久時間および故障率は、その型式のリソースがサービスレベルを満足するか否かを決定するサービスレベル決定要因である。また、数量は、リソースの規模（ＣＰＵのコア数、記憶容量、ネットワークインターフェース数等のスペックを表す数値）を表す規模情報である。つまり、リソース属性記憶部は、規模情報を含むリソース属性を記憶する。
【0042】
型式ＩＤは、型式をユニークに識別するためのＩＤ（識別情報）である。型式ＩＤは、型式ＩＤテーブルにおける主キーである。つまり、型式ＩＤは、特定のメーカーの特定の型式に対応する情報である。型式ＩＤの値自体は、例えばメーカー名＋型番として構成される値であってもよい。また、あるいは、型式ＩＤは、ここに示す例（ＣＰＵ－１、ＣＰＵ－２、・・・等）のように、リソース管理システム１０００において独自に定めるＩＤであってもよい。図２に示すデータの例では、ＣＰＵ－１、ＣＰＵ－２、ＤＩＭＭ－１、ＤＩＭＭ－２、ＳＳＤ－１、ＳＳＤ－２、ＮＩＣ－１といった型式ＩＤを用いている。なお、型式ＩＤを、例えば「製品ＩＤ」などと呼んでもよい。
【0043】
種別は、リソース（デバイス）の種別を表す情報である。本例では、型式データの種別として、ＣＰＵ、ＤＩＭＭ、ＳＳＤ、ＮＩＣといった値を含む。ただし、ここに例示した種別以外の値を使用するようにしてもよい。本例では、種別が「ＣＰＵ」（中央演算処理装置）であるリソースとして、型式ＩＤ「ＣＰＵ－１」および「ＣＰＵ－２」を含む。また、種別が「ＤＩＭＭ」（主記憶装置）であるリソースとして、型式ＩＤ「ＤＩＭＭ－１」および「ＤＩＭＭ－２」を含む。また、種別が「ＳＳＤ」（二次記憶装置）であるリソースとして、型式ＩＤ「ＳＳＤ－１」および「ＳＳＤ－２」を含む。また、種別が「ＮＩＣ」（ネットワークインターフェースカード）であるリソースとして、型式ＩＤ「ＮＩＣ－１」を含む。本例において、例えば、型式ＩＤ「ＳＳＤ－１」および「ＳＳＤ－２」は、同一の諸元（数量、耐久時間、および故障率）を有するが、これら２つの型式は別々のものとして区別され、異なる型式ＩＤを用いて管理される。
【0044】
数量は、そのリソース（デバイス）の製品としてのスペックを表す数値の情報である。
この数量が表す数値の意味は、デバイスの種別ごとに異なる。例えば、種別「ＣＰＵ」においては、数量はコア数を表す。即ち、型式ＩＤ「ＣＰＵ－１」のリソース（デバイス）のコア数は８であり、型式ＩＤ「ＣＰＵ－２」のリソース（デバイス）のコア数は１６であり、また、種別「ＤＩＭＭ」や種別「ＳＤＤ」においては、数量はデータ容量（単位は例えばギガバイト（ＧＢ））を表す。即ち、形式ＩＤ「ＤＩＭＭ－１」のリソース（デバイス）のデータ容量は６４ギガバイトである。また、形式ＩＤ「ＤＩＭＭ－２」のリソース（デバイス）のデータ容量は１２８ギガバイトである。また、形式ＩＤ「ＳＳＤ－１」および「ＳＳＤ－２」のそれぞれのデータ容量は８１９２ギガバイトである。また、種別「ＮＩＣ」においては、数量はネットワークインターフェース数を表す。即ち、形式ＩＤ「ＮＩＣ－１」においては、ネットワークインターフェース数が２である。
この数量が表す数値の意味は、デバイスの種別ごとに異なる。例えば、種別「ＣＰＵ」においては、数量はコア数を表す。即ち、型式ＩＤ「ＣＰＵ－１」のリソース（デバイス）のコア数は８であり、型式ＩＤ「ＣＰＵ－２」のリソース（デバイス）のコア数は１６であり、また、種別「ＤＩＭＭ」や種別「ＳＤＤ」においては、数量はデータ容量（単位は例えばギガバイト（ＧＢ））を表す。即ち、形式ＩＤ「ＤＩＭＭ－１」のリソース（デバイス）のデータ容量は６４ギガバイトである。また、形式ＩＤ「ＤＩＭＭ－２」のリソース（デバイス）のデータ容量は１２８ギガバイトである。また、形式ＩＤ「ＳＳＤ－１」および「ＳＳＤ－２」のそれぞれのデータ容量は８１９２ギガバイトである。また、種別「ＮＩＣ」においては、数量はネットワークインターフェース数を表す。即ち、形式ＩＤ「ＮＩＣ－１」においては、ネットワークインターフェース数が２である。
【0045】
耐久時間は、そのリソース（デバイス）に関して型式ＩＤごとにメーカーが定める耐久時間を表す数値である。図示する例では、数値の単位は時間（hours）である。例えば、形式ＩＤ「ＣＰＵ－１」のリソース（デバイス）に関して、耐久時間は４３８００時間（約５年）である。
【0046】
故障率は、そのリソース（デバイス）の故障率を表す数値である。故障率は、例えば、ある型式ＩＤのリソース（デバイス）のうちの故障状態にあるリソース（デバイス）の個体の数を、その型式ＩＤのリソース（デバイス）の全体の個体の数で除した値として算出され得る。つまり、故障率は、統計処理によって算出され得る。図示するデータ例では、形式ＩＤ「ＳＳＤ－２」のリソース（デバイス）に関して故障率は０．５であり、その他のリソース（デバイス）に関して故障率は０．０である。
【0047】
なお、変形例として、上記の定義による故障率の他にも、故障の発生の頻度等に関する別の定義による数値を用いて故障の発生度合いを管理するようにしてもよい。例えば、１年あたりの平均故障回数を故障率して管理に用いてもよい。また、他の値（例えば、ＭＴＢＦ（mean time between failures）等）で故障を管理するようにしてもよい。
【0048】
図３は、リソース管理サーバー装置１のリソース管理部１１が管理するリソーステーブル５の概略構成を示す概略図である。このリソーステーブルは、リソース（デバイス）ごとの属性に関する情報を保持するテーブルである。図示するように、リソーステーブルは、例えば表形式のデータとして実現され得る。ただし、このリソーステーブルと等価な情報を他の形式のデータとして保持するようにしてもよい。このリソーステーブルは、構成情報データベース１２に格納され得る。このリソーステーブルの各行は、リリース管理サーバー装置１が管理対象とするリソース（デバイス）のそれぞれに対応する。
【0049】
図３に示すように、リソーステーブル５は、リソースＩＤ、型式ＩＤ、ノードＩＤ、状態、開始時刻、稼働時間というそれぞれの列（データ項目）を有する。状態、開始時刻、および稼働時間は、そのリソースがサービスレベルを満足するか否かを決定するサービスレベル決定要因である。
【0050】
リソースＩＤは、それぞれのリソース（デバイス）をユニークに識別するＩＤ（識別情報）である。図示する例では、それぞれのリソース（デバイス）には、整数値によるリソースＩＤが付与されている。ただし、整数値以外をリソースＩＤとして用いてもよい。
【0051】
型式ＩＤは、図２において説明したものである。つまり、型式ＩＤは、その行のリソース（デバイス）の型式を特定する情報である。図３のリソーステーブル５における型式ＩＤは、図２の型式テーブル４における型式ＩＤと関連付けられる。図示する例では、リソースＩＤが「１」であるリソース（デバイス）の型式ＩＤは「ＣＰＵ－１」である。また、リソースＩＤが「２」であるリソース（デバイス）の型式ＩＤは「ＣＰＵ－２」である。以下同様であり、ここでは説明を省略する。
【0052】
ノードＩＤは、その行のリソース（デバイス）が割り当てられている先のノードをユニークに識別するためのＩＤ（識別情報）である。図示する例では、ノードＩＤとしては、整数値（「１」等）が用いられている。ただし、整数値以外をノードＩＤとして用いてもよい。なお、その行のリソース（デバイス）がノードに割り当てられていない状態である場合には、当該行のノードＩＤの値は未割当であることを表す特別な値（本例におけるＮＵＬＬ等）である。図示する例では、リソースＩＤが「１」と「３」と「５」と「９」であるそれぞれのリソース（デバイス）は、ノードＩＤが「１」であるノードに割り当てられている。また、リソースＩＤが「２」と「４」と「６」と「７」と「８」と「１０」であるそれぞれのリソース（デバイス）のノードＩＤはＮＵＬＬ（ノードに割り当てられていない空きリソース）である。
【0053】
状態は、その行のリソース（デバイス）が正常であるか故障であるかの状態を表すデータである。正常状態である場合、そのリソース（デバイス）は正常に稼働する。故障状態である場合、そのリソース（デバイス）には何らかの故障が発生しており正常に稼働しない。リソース（デバイス）をノードに割り当てようとする際に、この状態を参照することにより、故障状態のリソース（デバイス）をノードに割り当ててしまうといった事態を回避することができる。つまり、故障状態のリソース（デバイス）をノードに割り当てないようにすることができる。
【0054】
開始時刻は、その行のリソース（デバイス）が最後にノードに割り当てられた時刻（日時）を表すデータである。開始時刻は、例えば、「ＹＹＹＹ／ＭＭ／ＤＤ ｈｈ：ｍｍ：ｓｓ」（年・月・日、時・分・秒）の形式で表わされる。なお、そのリソース（デバイス）が一度もノードに割り当てられていない状態である場合には、この開始時刻の値はＮＵＬＬである。
【0055】
稼働時間は、その行のリソース（デバイス）がそれまでにおいてノードに割り当てられていた（ノードを構成する要素として稼働していた）累積の時間を表すデータである。稼働時間は、一例として、時間（hours）の単位で表現され得る。なお、リソースＩＤが「１０」であるリソース（デバイス）は、それまでにノードに割り当てられたことがなく（開始時刻がＮＵＬＬ）、その累積稼働時間も「０」（hours）である。
【0056】
図４は、リソース管理サーバー装置１のリソース管理部１１が管理するサービスレベルテーブル６の概略構成を示す概略図である。このサービスレベルは、サービスレベルごとのサービス要件に関する情報を保持するテーブルである。図示するように、サービスレベルテーブルは、例えば表形式のデータとして実現され得る。ただし、このサービスレベルテーブルと等価な情報を他の形式のデータとして保持するようにしてもよい。このサービスレベルテーブルは、構成情報データベース１２に格納され得る。このサービスレベルテーブルの各行は、それぞれのサービスレベルに対応する。
【0057】
図４に示すように、サービスレベルテーブル６は、サービスレベル名、最低稼働時間、許容故障率というそれぞれの列（データ項目）を有する。
【0058】
サービスレベル名は、サービスレベルを表す名前（文字列）のデータである。図示する例では、「基幹サーバー」、「部門サーバー」、および「検証用サーバー」の３種類のサービスレベルの名前が定義されている。
【0059】
最低稼働時間は、その行のサービスレベルが個々のリソース（デバイス）に要求する最低稼働時間を表す数値である。最低稼働時間の単位は、時間（hours）である。このデータ項目を持つことにより、あるサービスレベルがノードに対して要求される場合に、そのサービスレベルで規定する最低稼働時間に満たない稼働実績しか有さないリソース（デバイス）を、そのノードの構築には使用しないようにすることができる。最低稼働時間に基づいてリソースを選択することにより、初期不良の発生確率が所定レベル以上のリソースをノードの構築のために割り当てないようにすることができる。
【0060】
許容故障率は、その行のサービスレベルが個々のリソース（デバイス）に要求する故障率の上限値を表す数値である。故障率の算出方法については既に説明した通りである。このデータ項目を持つことにより、あるサービスレベルがノードに対して要求される場合に、そのサービスレベルで規定する許容故障率を超えるような故障率を持つリソース（デバイス）を、そのノードの構築には使用しないようにすることができる。
【0061】
【0062】
図５は、リソース管理サーバー装置１のリソース管理部１１が、クライアント装置３からの要求に基づいてノードの構築を行う処理の手順を示すフローチャートである。以下、このフローチャートに沿って説明する。
【0063】
ステップＳ５００において、リソース管理サーバー装置１のリソース管理部１１は、クライアント装置３からＣＤＩ装置２上でのノード構築の要求を受けた際に、ノードのスペック情報と、サービス期間と、サービスレベル名とを、パラメーターとして受け取る。ここでノードのスペック情報とは、ＣＰＵのコア数や、ＤＩＭＭの容量（ギガバイト数）や、ＳＳＤの容量（ギガバイト数）や、ＮＩＣのインターフェース数などといった情報のセットである。つまり、スペック情報は、構築しようとするノードに関して、使用するリソース（デバイス）の種別やその数的規模などを表す情報である。また、サービス期間とは、構築されたノードがサービスを提供する期間である。サービス期間のパラメーター値は、期間の長さを表す数値（例えば、日数や月数など）として与えられてもよいし、サービス期間の終了の時刻（例えば、年・月・日および時・分・秒）として与えられてもよい。サービスレベル名は、構築しようとするノードに要求されるサービスレベルを表す名前であり、例えば、「基幹サーバー」、「部門サーバー」、「検証用サーバー」などといった文字列として表わされる。但し、サービスレベル名は、ここに例示した名前に限られるものではない。サービスレベル名として指定されるのは、図４を参照しながら説明したサービスレベルテーブル６が持つサービスレベル名である。リソース管理部１１が受け取る上記のパラメーターの値は、ノードを構築するために割り当てるリソース（デバイス）を選択する際の条件として用いられ得るものである。
【0064】
次にステップＳ５０１において、リソース管理部１１は、ステップＳ５００において受け取ったパラメーターとして指定されたサービスレベル名をキーとして、サービスレベルテーブル６を検索する。これにより、リソース管理部１１は、指定されたサービスレベル名に対応する最低稼働時間と許容故障率との情報を取得する。なお、サービスレベルテーブルが、サービスレベルの定義に関する他の情報を持っていてもよい。
【0065】
次に、ステップＳ５０２からＳ５０５までの各ステップにおいて、リソース管理部１１は、要求されているノードを構築するために使用するそれぞれの種別のリソースのリソースＩＤを取得する。具体的には、リソース管理部１１は、ステップＳ５０２においてＣＰＵのリソースＩＤを取得する。また、リソース管理部１１は、ステップＳ５０３においてＤＩＭＭのリソースＩＤを取得する。また、リソース管理部１１は、ステップＳ５０４においてＳＳＤのリソースＩＤを取得する。また、リソース管理部１１は、ステップＳ５０５においてＮＩＣのリソースＩＤを取得する。ステップＳ５０２からＳ５０５までの各ステップにおいて、リソース管理部１１を実現するプログラムが、それぞれの種別のリソースのリソースＩＤを取得するためのサブルーチンを呼び出す形態としてもよい。なお、ステップＳ５０２からＳ５０５までの各ステップの処理の詳細については、後で図６のフローチャートを参照しながら説明する。
【0066】
ステップＳ５０２からＳ５０５までの各ステップにおいては、リソース管理部１１は、要求として与えられた情報に基づき、条件に合致するリソース（デバイス）のリソースＩＤを取得する。ここでの条件とは、ステップＳ５００で受け取ったパラメーター（ノードのスペック情報、サービス期間、およびサービスレベル名）によって定まる条件である。
【0067】
なお、ここでは、リソース（デバイス）の種別として、ＣＰＵ、ＤＩＭＭ、ＳＳＤ、およびＮＩＣの４種類を想定した。代わりに、リソース（デバイス）の種別の別の集合に基づいて、リソース管理部１１が、それらの種別のリソースＩＤを取得するようにしてもよい。
【0068】
例えば、主記憶装置として用いるリソース（デバイス）として、ＤＲＡＭおよびＮＶＤＩＭＭの２つの種別を用いるようにしてもよい。この場合、ノードを構成する主記憶装置としては、ＤＲＡＭおよびＮＶＤＩＭＭのいずれか一方あるいは両方を用いるようにすることができる。なお、ＤＲＡＭは、「Dynamic Random Access Memory」の略であり、半導体素子を利用した揮発性の記憶装置である。また、ＮＶＤＩＭＭは、「Non-volatile DIMM」であり、不揮発性の記憶装置である。
【0069】
また、例えば、二次記憶装置として用いるリソース（デバイス）の種別として、ＳＳＤの他にＨＤＤを用いてもよい。この場合、ノードを構成する二次記憶装置としては、ＳＳＤおよびＨＤＤのいずれか一方あるいは両方を用いるようにすることができる。なお、ＨＤＤは、「Hard Disk Drive」の略であり、磁気記録を利用した磁気ディスク装置である。
【0070】
さらに他のリソース（デバイス）の種別として、ＤＳＰや、ＦＰＧＡや、ＧＰＵなどといったリソース（デバイス）を用いてノードを構成することができるようにしてもよい。ＤＳＰは、「Digital Signal Processor」（デジタル信号処理装置）の略である。ＦＰＧＡは、「Field Programmable Gate Array」（フィールド・プログラマブル・ゲート・アレイ）の略であり、現場でプログラム可能（書き換え可能）な論理ゲート配列である。ＧＰＵは、「Graphics Processing Unit」（グラフィクス処理装置）の略である。これらのＤＳＰや、ＦＰＧＡや、ＧＰＵは、演算処理を行うためのリソース（デバイス）である。
【0071】
また、ここに例示・列挙した以外の種別のリソース（デバイス）を用いてノードを構築することができるようにしてもよい。
【0072】
フローチャートに戻り、ステップＳ５０６において、リソース管理部１１は、必要な全種別（ＣＰＵ、ＤＩＭＭ、ＳＳＤ、およびＮＩＣの全種別。あるいは、必要に応じてその他の種別も。）のリソースＩＤがステップＳ５０２からＳ５０６までの処理で取得できたか否かを判断する。必要な全種別のリソースＩＤを取得できた場合（Ｓ５０６：ＹＥＳ）には、次のステップＳ５０７に進む。必要な種別のうちの何らかの種別のリソースＩＤを取得できなかった場合（Ｓ５０６：ＮＯ）には、要求されているノードを構築することができないため、本フローチャート全体の処理を終了する。
【0073】
ステップＳ５０６からステップＳ５０７に進んだ場合には、ステップＳ５０７において、リソース管理部１１は、ノードＩＤを生成する。ここで生成するノードＩＤは、ノードをユニークに識別するための、新たなノードのノードＩＤである。例えば、所定のロジックを用いて未使用のノードＩＤを生成するようにする。
【0074】
次にステップＳ５０８において、リソース管理部１１は、新たに構築するノードのために使用するリソース（デバイス）に関して、リソーステーブル５を更新する。具体的には、リソース管理部１１は、ステップＳ５０２からＳ５０５までにおいて取得したＣＰＵとＤＩＭＭとＳＳＤとＮＩＣのリソースＩＤ（また、さらに、必要に応じて他の種別のリソースのリソースＩＤも）のそれぞれについて、リソーステーブル５上のレコードの、ノードＩＤの列の値と、開始時刻の列の値とを、更新する。具体的には、リソース管理部１１は、ノードＩＤとしては、ステップＳ５０７で生成したノードＩＤの値（即ち、新たに構築するノードのノードＩＤの値）を設定する。また、リソース管理部１１は、開始時刻としては、現在時刻（日付および時刻）の値を設定する。つまり、本ステップにおいて更新後のデータは、これらのリソース（デバイス）が現在時刻において新たなノードとして使用され始めていることを意味する。なお、現在時刻は、リソース管理サーバー装置１が備える不図示のクロック機能を参照することによって取得され得る。
【0075】
次にステップＳ５０９において、リソース管理部１１は、それらのリソース（ステップＳ５０８の処理において更新したレコードに対応するリソース（デバイス））を指定して、ＣＤＩ装置２に対して、ノードの構築を実行するよう制御する。このとき、リソース管理部１１は、必要に応じて、新たなノードのノードＩＤ（ステップＳ５０７において生成したノードＩＤ）をＣＤＩ装置２に渡してよい。
【0076】
ＣＤＩ装置２におけるノードの構築が完了すると、ステップＳ５１０において、リソース管理部１１は、新たなノードのノードＩＤ（ステップＳ５０７において生成したノードＩＤ）をクライアント装置３に戻す。
【0077】
図６は、リソース管理サーバー装置１のリソース管理部１１が、特定の種別のリソース（デバイス）のリソースＩＤを取得する処理の手順を示すフローチャートである。図６に示す特定のリソースのリソースＩＤを取得する処理は、例えば、図５のステップＳ５０２からＳ５０５のそれぞれにおいて実行される処理である。なお、ＣＰＵ、ＤＩＭＭ、ＳＳＤ、あるいはＮＩＣ以外の種別のリソース（デバイス）についても、図６に示す処理は実行され得る。以下、図６のフローチャートに沿って説明する。
【0078】
まずステップＳ６００において、リソース管理部１１は、型式を種別で絞り込む。つまり、リソース管理部１１は、型式テーブル４が持つデータのうち、求められている種別（一例として、「ＣＰＵ」）のデータのみを抽出する。
【0079】
ステップＳ６０１において、リソース管理部１１は、型式を数量で絞り込む。
つまり、リソース管理部１１は、ステップＳ６００において絞り込まれたデータのうち、数量の条件に合致する型式のデータのみを抽出する。ここでの数量の条件は、例えば図５のステップＳ５００の処理において受け取るパラメーターによって定まる条件である。例えば、種別が「ＣＰＵ」である場合に、リソース管理部１１がパラメーターとして受け取るスペック情報の一部において「ＣＰＵのスペックとしてコア数が１６（あるいは１６以上）である」という要件が記述される。あるいは、例えば、種別が「ＤＩＭＭ」である場合に、リソース管理部１１がパラメーターとして受け取るスペック情報の一部において「ＤＩＭＭのスペックとして記憶容量が１２８ギガバイトである」という要件が記述される。その他の種別のリソース（デバイス）についても同様である。
つまり、リソース管理部１１は、ステップＳ６００において絞り込まれたデータのうち、数量の条件に合致する型式のデータのみを抽出する。ここでの数量の条件は、例えば図５のステップＳ５００の処理において受け取るパラメーターによって定まる条件である。例えば、種別が「ＣＰＵ」である場合に、リソース管理部１１がパラメーターとして受け取るスペック情報の一部において「ＣＰＵのスペックとしてコア数が１６（あるいは１６以上）である」という要件が記述される。あるいは、例えば、種別が「ＤＩＭＭ」である場合に、リソース管理部１１がパラメーターとして受け取るスペック情報の一部において「ＤＩＭＭのスペックとして記憶容量が１２８ギガバイトである」という要件が記述される。その他の種別のリソース（デバイス）についても同様である。
【0080】
次にステップＳ６０２において、リソース管理部１１は、許容故障率以下の型式を絞り込む。つまり、リソース管理部１１は、ステップＳ６０１において絞り込まれた型式のデータ（図２を参照）のうち、その故障率の列の値が、基準となる許容故障率以下である形式のデータのみを抽出する。許容故障率は、パラメーターとして指定されたサービスレベル名に対応して図５のステップＳ５０１の処理において取得された値である。リソース管理部１１は、本ステップにおいて絞り込まれた型式ＩＤを持つリソースを、ノードに割り当てることとする。
【0081】
次にステップＳ６０３において、リソース管理部１１は、ステップＳ６０２で絞り込まれた型式ＩＤの集合を用いて、リソーステーブル５（図３を参照）に含まれるリソースの絞り込みを行う。つまり、リソース管理部１１は、リソーステーブル５に含まれるリソース（デバイス）のデータのうち、ステップＳ６０２において絞り込まれた型式ＩＤのいずれかを有するリソース（デバイス）のデータを抽出する。つまり、本ステップでは、リソース管理部１１は、リソーステーブル５を検索して、ステップＳ６００からＳ６０３までにおいて絞り込みに用いた条件に適合するリソース（デバイス）のデータを絞り込む。
【0082】
次にステップＳ６０４において、リソース管理部１１は、ノードに未割当のリソースを絞り込む。つまり、リソース管理部１１は、ステップＳ６０３において絞り込まれたリソース（デバイス）のデータのうち、リソーステーブル５におけるノードＩＤの列の値がノードへの未割当を表している（図３の例の場合には、ＮＵＬＬ値）であるリソース（デバイス）のデータのみを絞り込む。つまり、本ステップの処理によって、既に他のノードに割り当てられているリソース（デバイス）のデータは除外される。
【0083】
次にステップＳ６０５において、リソース管理部１１は、状態が正常であるリソース（デバイス）への絞り込みを行う。つまり、リソース管理部１１は、ステップＳ６０４において絞り込まれたリソース（デバイス）のデータのうち、リソーステーブル５（図３を参照）における状態の列の値が「正常」であるリソース（デバイス）のデータのみを絞り込む。つまり、本ステップの処理によって、故障（異常）状態のリソース（デバイス）のデータは除外される。
【0084】
ステップＳ６０６において、リソース管理部１１は、サービスレベルで指定された最低稼働時間以上の稼働時間で、リソース（デバイス）の絞り込みを行う。つまり、リソース管理部１１は、要求として指定されたサービスレベル名に対応するリソース（デバイス）最低稼働時間を把握する。この最低稼働時間の値は、図５のステップＳ５０１の処理においてリソース管理部１１によって既に取得されている。そして、リソース管理部１１は、ステップＳ６０５において絞り込まれたリソース（デバイス）のデータのうち、リソーステーブル５（図３を参照）における状態の稼働時間の列の値が上記の最低稼働時間の値以上であるリソース（デバイス）のデータのみを絞り込む。つまり、本ステップの処理によって、稼働時間が最低稼働時間未満であるリソース（デバイス）のデータは除外される。言い換えれば、本ステップの処理によって、初期不良による異常が発生する可能性のあるリソース（デバイス）のデータは除外される。
【0085】
ステップＳ６０７において、リソース管理部１１は、ノードのサービス期間内に耐久時間を迎えないリソース（デバイス）のデータへの絞り込みを行う。つまり、リソース管理部１１は、ステップＳ６０６において絞り込まれたリソース（デバイス）のデータの各行について次の処理を行う。即ち、その行のリソース（デバイス）の形式ＩＤの列のデータを取得する。そして、型式テーブル４（図２を参照）を検索して、その型式ＩＤに対応する耐久時間の値を取得する。そして、取得された耐久時間の値から、リソーステーブル５の当該リソースの行が持つ稼働時間の値を減じて、その差を算出する。この差が、当該行が表すリソース（デバイス）の残りの耐久時間である。リソース管理部は、サービスレベル名に基づいて取得されたサービス期間（即ち、図５のステップＳ５０１で取得した、図４のサービスレベルテーブル６の最低稼働時間）が、上記残りの耐久時間以下であるようなリソース（デバイス）のデータのみを絞り込む。本ステップの処理によって、サービスレベルに対応して規定される最低稼働時間よりも上記残りの耐久時間のほうが小さい（短い）リソース（デバイス）のデータが除外される。
【0086】
以上、ステップＳ６００からＳ６０７までの一連の処理によって絞り込まれた結果として残ったリソース（デバイス）のデータが、ノードに割り当てるのに適したリソース（デバイス）のデータである。絞り込みの結果として条件に合うリソースがある場合には、リソース管理部１１は、そのリソースＩＤを特定する。即ち、ステップＳ６０８以下の処理を行う。
【0087】
ステップＳ６０８において、リソース管理部１１は、絞り込まれた結果のリソースのデータが１行以上存在するか否かを判定する。絞り込まれた結果のリソースのデータが存在する場合（当該種別のリソースあり； ステップＳ６０８：ＹＥＳ）には、次のステップＳ６０９に進む。絞り込まれた結果のリソースのデータが存在しない場合（当該種別のリソースなし； ステップＳ６０８：ＮＯ）には、本フローチャート全体の処理を終了する。
そして、絞り込まれたリソースの個数が１以上であった場合は（S６０８）、絞り込み結果から任意のリソースを１つ選択し（Ｓ６０９）、そのリソースIDを返却する（Ｓ６１０）。
そして、絞り込まれたリソースの個数が１以上であった場合は（S６０８）、絞り込み結果から任意のリソースを１つ選択し（Ｓ６０９）、そのリソースIDを返却する（Ｓ６１０）。
【0088】
ステップＳ６０９において、リソース管理部１１は、ステップＳ６０７までの一連の処理によって絞り込まれた結果として存在する１行以上のデータうちの１行のデータ（１つのリソース（デバイス））を選択する。本ステップでの選択のしかたは任意である。複数行のデータから選択する場合には、例えば、要求されるスペックを満たす最小スペックのリソース（デバイス）を選ぶようにしてもよい。あるいは、例えば、複数行のデータの中からランダムに１行のデータを選ぶようにしてもよい。その他の選び方を行ってもよい。
【0089】
次にステップＳ６１０において、リソース管理部１１は、ステップＳ６０９において選択した１つのリソース（デバイス）のリソースＩＤを呼び出し元の処理に返す。
【0090】
以上説明したように、図６に示した処理手順により、リソース管理部１１は、渡された条件に合うリソース（デバイス）を絞り込み、絞り込んだ結果のうちの１つのリソース（デバイス）のリソースＩＤを呼び出し元の処理に返す。
【0091】
なお、図６に示した処理手順においては、ステップＳ６００からＳ６０７までの各ステップにおいて順次絞り込みを行うことによって、最終的に所望のリソース（デバイス）に対応するデータを特定し、リソースＩＤを決定した。このように順次絞り込みを行う代わりに、ステップＳ６００からＳ６０７までに含まれる条件を例えば１文のＳＱＬ文の中に記述して、そのＳＱＬを実行することによって一気にデータの絞り込みを行うようにしてもよい。いかなる手順によってデータの絞り込みを行うかに関わらず、データを選択する条件の宣言的意味付けは同じである。
【0092】
図７は、リソース管理サーバー装置１のリソース管理部１１が、クライアント装置３からの要求に基づいてノードの解体を行う処理の手順を示すフローチャートである。以下、このフローチャートに沿って説明する。
【0093】
ステップＳ７００において、リソース管理部１１は、ノードＩＤをパラメーターとして受け取る。このノードＩＤは、解体対象のノードを識別する情報として、クライアント装置３から送信されたものである。
【0094】
次にステップＳ７０１において、リソース管理部１１は、ステップＳ７００で受け取ったノードＩＤに基づいて、そのノードＩＤを有するノードに割り当てられているリソースを絞り込む。つまり、リソース管理部１１は、ステップＳ７００で受け取ったノードＩＤをキーとしてリソーステーブル５（図３を参照）を検索して、当該ノードＩＤを有するリソース（デバイス）のデータの集合を取得する。
【0095】
ステップＳ７０２において、リソース管理部１１は、ステップＳ７０１における絞り込み（検索）の結果として１行以上のデータがあったか否かを判定する。１行以上のデータがあった（１個以上のリソース（デバイス）が該当した）場合（ステップＳ７０２：ＹＥＳ）には、次のステップＳ７０３に進む。絞り込みの結果としてデータがなかった（０件であった）場合（ステップＳ７０２：ＮＯ）には、本フローチャート全体の処理を終了する。
【0096】
ステップＳ７０３に進んだ場合には、同ステップにおいて、リソース管理部１１は、ＣＤＩ装置２におけるノードの解体を実行する。具体的には、リソース管理部１１は、ステップＳ７００において受け取ったノードＩＤを指定することによって、ＣＤＩ装置２がそのノードを解体するよう制御する。あるいは、リソース管理部１１が、ステップＳ７０１において絞り込まれた結果のリソースＩＤを指定することによってＣＤＩ装置２がそのノードを解体するように制御してもよい。いずれの場合にも、本ステップの処理により、ＣＤＩ装置２におけるノードが解体される。また、そのノードに割り当てられていたリソース（デバイス）は解放され、他のノードに割り当て可能なリソース（デバイス）としてリソースプールに戻される。
【0097】
ステップＳ７０４において、リソース管理部１１は、リソーステーブル５上のリソース（デバイス）ごとの稼働時間の値を更新する。具体的には、リソース管理部１１は、リソーステーブル５上の、解体対象のノードに割り当てられていたリソース（デバイス）の集合の各要素に対応する行において、稼働時間の列の値に、（現在時刻－開始時刻）の演算結果を加算して更新する。ここでの開始時刻（日時）とは、前述の通り、そのリソース（デバイス）がノードに割り当てられた時刻である。本ステップで更新対象となる行は、ステップＳ７０１の処理において絞り込まれたリソースＩＤを有するすべての行である。
【0098】
ステップＳ７０５において、リソース管理部１１は、解放されたリソース（デバイス）のノードＩＤをＮＵＬＬに設定する。つまり、リソース管理部１１は、リソーステーブル５上の、解体対象のノードに割り当てられていたリソース（デバイスの集合の各要素に対応する行において、ノードＩＤの列の値をＮＵＬＬにリセットする。本ステップで更新対象となる行は、ステップＳ７０１の処理において絞り込まれたリソースＩＤを有するすべての行である。
【0099】
以上、ステップＳ７００からＳ７０５までの処理により、指定されたノードＩＤを有するノードがＣＤＩ装置２上で解体され、そのノードに属していたリソース（デバイス）が解放される。また、ノードの解体に合わせて、リソーステーブル５上において必要な個所が更新される。解放されたリソース（デバイス）は、以後、別のノードを構築する際にそのノードに割り当てられ得る。
【0100】
図８は、リソース管理サーバー装置１のリソース管理部１１が、ＣＤＩ装置２から受け取るイベント通知に基づいて、リソース（デバイス）の故障に対応する処理の手順を示すフローチャートである。このフローチャートの処理が実行されるのは、ＣＤＩ装置２からリソース管理サーバー装置１に対してイベントが通知されたときである。以下、このフローチャートに沿って説明する。
【0101】
まずステップＳ８００において、リソース管理サーバー装置１のリソース管理部１１は、ＣＤＩ装置２から通知されたイベントから、リソースＩＤの情報を抽出する。ＣＤＩ装置２からのイベントは、そのリソースＩＤを有するリソース（デバイス）の故障を通知するものである。ＣＤＩ装置２は、特定のリソース（デバイス）の故障を検知したときに、その故障に関する情報（リソースＩＤを含む）をリソース管理サーバー装置１に対して通知する機能を備えている。
【0102】
ステップＳ８０１において、リソース管理部１１は、当該リソース（デバイス）の状態を故障に設定する。つまり、リソース管理部１１は、ステップＳ８００において受け取ったリソースＩＤをキーとしてリソーステーブル５（図３を参照）を検索する。そして、リソース管理部１１は、該当する行にける状態の列の値を「故障」に更新する。
【0103】
次にステップＳ８０２において、リソース管理部１１は、今回故障したリソース（デバイス）と同一の型式のリソース（デバイス）の数をカウントする。具体的には、リソース管理部１１は、リソーステーブル５上の、通知を受けたリソースＩＤの行のデータの型式ＩＤを読み取り、特定する。この型式ＩＤが、今回故障したリソース（デバイス）の型式である。そして、リソース管理部１１は、リソーステーブル５上で、当該型式ＩＤを持つ行の数をカウントする。
【0104】
次にステップＳ８０３において、リソース管理部１１は、今回故障したリソース（デバイス）と同一の型式で且つ故障状態のリソース（デバイス）のリソース（デバイス）数をカウントする。具体的には、リソース管理部１１は、リソーステーブル５上で、ステップＳ８０２において特定した型式ＩＤを持ち、且つ状態の列の値が「故障」である行の数をカウントする。
【0105】
ステップＳ８０４において、リソース管理部１１は、今回故障したリソース（デバイス）と同じ型式ＩＤを持つリソース（デバイス）の故障率を算出する。故障率は、一例として、上のステップＳ８０２およびＳ８０３でそれぞれ求めた数値を用いて、「（当該型式ＩＤを有し且つ故障状態のリソース（デバイス）の個体数）／（当該型式ＩＤを有するリソース（デバイス）の個体数）」という数式によって算出される。
【0106】
ただし、リソース管理部１１は、他の定義の数式によって故障に関する統計を算出するようにしてもよい。
【0107】
そして、ステップＳ８０５において、リソース管理部１１は、ステップＳ８０４で算出した故障率の数値を構成情報データベースに格納する。つまり、リソース管理部１１は、型式テーブル４（図２を参照）において、当該型式ＩＤを有する行の、故障率の列の値を、ステップＳ８０４で算出した故障率の数値で更新する。
【0108】
以上のステップＳ８００からＳ８０５までの処理はＣＤＩ装置２から故障のイベントが通知される都度実行される。これにより、リソーステーブル５上の各リソースにおける状態の列の値が適切に更新される。また、型式テーブル４上の各型式ＩＤについての故障率の値が適切に更新される。つまり、ＣＤＩ装置２からのイベントの通知を受けてテーブルを更新することにより、リソース管理部１１は、常に最新の状態（リソースＩＤごとの状態の値、および型式ＩＤごとの故障率の数値）に基づいて、新たに構築するノードに割り当てるリソース（デバイス）を適切に選択することができる。
【0109】
［第２実施形態］
次に、本発明の第２実施形態について説明する。なお、前実施形態において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。本実施形態の特徴は、リソース管理部１１Ａが、リソース（デバイス）における故障の発生の時期および頻度についての分析機能を持つことである。
次に、本発明の第２実施形態について説明する。なお、前実施形態において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。本実施形態の特徴は、リソース管理部１１Ａが、リソース（デバイス）における故障の発生の時期および頻度についての分析機能を持つことである。
【0110】
図９は、第２実施形態によるリソース管理システムの概略機能構成を示すブロック図である。図示するように、リソース管理システム１０００Ａは、リソース管理サーバー装置１Ａと、ＣＤＩ装置２と、クライアント装置３とを含んで構成される。リソース管理サーバー装置１Ａは、リソース管理部１１Ａと、構成情報データベース１２とを含んで構成される。本実施形態の特徴として、リソース管理部１１Ａは、分析機能部１７を持つ。
【0111】
分析機能部１７は、リソース（デバイス）の故障に関するデータを分析する機能を持つ。分析機能部１７による分析の方法は、次の通りである。
【0112】
［故障率曲線のグラフの管理］
第１に、分析機能部１７は、リソース（デバイス）の型式ごとの故障率曲線のグラフを管理する。故障率曲線のグラフは、リソース（デバイス）個体の稼働時間と、その稼働時間における型式ごとの故障率との関係の集合である。言い換えれば、故障率曲線のグラフは、リソース（デバイス）の型式ごとの、稼働時間に対する故障率の推移を表す。分析機能部１７は、例えば、ある特定の型式について、その型式に属する個々のリソース（デバイス）の、所定の稼働時間経過ごと（例えば、１時間ごと、あるいは２４時間ごと等）の状態が「正常」であるか「故障」であるかの情報を蓄積することによって、上記の故障率曲線のグラフのデータを生成することができる。つまり、分析機能部１７は、ＣＤＩ装置２から通知されるイベントの情報を蓄積して加工することによって故障率曲線のデータを生成できる。なお、分析機能部１７は、その他の方法を用いて故障率曲線のグラフのデータを生成し、管理してもよい。
第１に、分析機能部１７は、リソース（デバイス）の型式ごとの故障率曲線のグラフを管理する。故障率曲線のグラフは、リソース（デバイス）個体の稼働時間と、その稼働時間における型式ごとの故障率との関係の集合である。言い換えれば、故障率曲線のグラフは、リソース（デバイス）の型式ごとの、稼働時間に対する故障率の推移を表す。分析機能部１７は、例えば、ある特定の型式について、その型式に属する個々のリソース（デバイス）の、所定の稼働時間経過ごと（例えば、１時間ごと、あるいは２４時間ごと等）の状態が「正常」であるか「故障」であるかの情報を蓄積することによって、上記の故障率曲線のグラフのデータを生成することができる。つまり、分析機能部１７は、ＣＤＩ装置２から通知されるイベントの情報を蓄積して加工することによって故障率曲線のデータを生成できる。なお、分析機能部１７は、その他の方法を用いて故障率曲線のグラフのデータを生成し、管理してもよい。
【0113】
第１実施形態においては、リソース管理部１１は型式ごとの故障率の単一の数値を型式テーブル４に格納して管理していた。それと比べて、第２実施形態では、より豊富な情報に基づいてリソースを管理することができるようになる。
【0114】
第１実施形態においては、サービスレベルを定義するために、サービスレベルごとの最低稼働時間の数値を管理していた。一方で、第２実施形態では、稼働時間に対する故障率の推移を型式ごとに管理することができる。言い換えれば、例えば、初期不良の発生が収束する稼働時間や、老朽化に伴って故障率が上昇し始める稼働時間を、統計に基づいて型式ごとに管理できる。つまり、型式ごとの故障発生の特性は、故障率曲線のデータに反映されている。このため、サービスレベルの定義としては、最低稼働時間を指定する代わりに、許容故障率を指定すれば十分である。そして、第１実施形態においては特定の種別のリソース（デバイス）のすべての型式に対して一律の最低稼働時間を要求していたのに対して、第２実施形態では、型式ごとの初期不良の特性をリソースの払い出し基準に反映させることができるという利点もある。
【0115】
［耐久時間に関する情報の収集と分析］
本実施形態の分析機能部１７は、型式ごとの耐久時間に関する情報を収集する機能を備える。具体的には、分析機能部１７は、リソース（デバイス）のメーカーやその他の事業体が提供（例えば、ウェブに公開）する耐久時間に関する情報を、ウェブの巡回によって収集する。ウェブを巡回する手法自体としては、既存のクローリング技術を利用することができる。また、収集したデータを分析する機能としては、既存のビッグデータの分析技術を用いることができる。具体的には、分析機能部１７は、ＣＰＵ等の特定の型式のハードウェアのエラッタの情報や、リソース（デバイス）を制御するファームウェアのバグの情報を、ウェブ巡回により収取する。これらは、リソース（デバイス）の障害（故障）の要因となり得る障害要因情報である。分析機能部１７は、例えば、それらの障害要因情報をウェブで検出した場合に、対象の型式の耐久時間（型式テーブル４）を短縮するように更新したり、耐久時間の値をゼロ以下の値に設定したりするなどして、リソースの払い出しを無効化するようにしてもよい。
本実施形態の分析機能部１７は、型式ごとの耐久時間に関する情報を収集する機能を備える。具体的には、分析機能部１７は、リソース（デバイス）のメーカーやその他の事業体が提供（例えば、ウェブに公開）する耐久時間に関する情報を、ウェブの巡回によって収集する。ウェブを巡回する手法自体としては、既存のクローリング技術を利用することができる。また、収集したデータを分析する機能としては、既存のビッグデータの分析技術を用いることができる。具体的には、分析機能部１７は、ＣＰＵ等の特定の型式のハードウェアのエラッタの情報や、リソース（デバイス）を制御するファームウェアのバグの情報を、ウェブ巡回により収取する。これらは、リソース（デバイス）の障害（故障）の要因となり得る障害要因情報である。分析機能部１７は、例えば、それらの障害要因情報をウェブで検出した場合に、対象の型式の耐久時間（型式テーブル４）を短縮するように更新したり、耐久時間の値をゼロ以下の値に設定したりするなどして、リソースの払い出しを無効化するようにしてもよい。
【0116】
［第３実施形態］
次に、本発明の第３実施形態について説明する。なお、前実施形態において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。
次に、本発明の第３実施形態について説明する。なお、前実施形態において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。
【0117】
図１０は本実施形態によるリソース装置の最小構成を示す機能ブロック図である。この最小構成は、前述の課題を解決する機能を備える。本実施形態によるリソース管理装置１Ｂは少なくともリソース属性記憶部１２０と、リソース管理部１１と、の構成を備えればよい。リソース管理装置１Ｂは、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置（ＣＤＩ装置）を制御するための装置である。リソース属性記憶部１２０は、個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するものである。第１実施形態における型式テーブル４およびリソーステーブル５は、本実施形態のリソース属性記憶部１２０に含まれる。個々のリソースの属性であるリソース属性のうちの、型式に共通な属性を型式属性として型式テーブル４に格納することができる。なお、リソース属性記憶部１２０は、第１実施形態において説明した構成情報データベース１２の一部分である。リソース管理部１１は、前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、ものである。
【0118】
第１実施形態、第２実施形態、あるいは第３実施形態のリソース管理システムを実現するために利用されるコンピューター（リソース管理サーバー装置やクライアント装置等）は、例えば、中央処理装置と、ＲＡＭ（主記憶装置）と、入出力ポートと、入出力デバイス等と、バスとを含んで構成される。コンピューター自体は、既存技術を用いて実現可能である。中央処理装置は、ＲＡＭ等から読み込んだプログラムに含まれる命令を実行する。中央処理装置は、各命令にしたがって、ＲＡＭにデータを書き込んだり、ＲＡＭからデータを読み出したり、算術演算や論理演算を行ったりする。ＲＡＭは、データやプログラムを記憶する。ＲＡＭに含まれる各要素は、アドレスを持ち、アドレスを用いてアクセスされ得るものである。なお、ＲＡＭは、「ランダムアクセスメモリー」の略である。入出力ポートは、中央処理装置が外部の入出力デバイス等とデータのやり取りを行うためのポートである。入出力デバイスは、入出力ポートを介して中央処理装置との間でデータをやりとりする。バスは、コンピューター内部で使用される共通の通信路である。例えば、中央処理装置は、バスを介してＲＡＭのデータを読んだり書いたりする。また、例えば、中央処理装置は、バスを介して入出力ポートにアクセスする。
【0119】
なお、上述した実施形態におけるリソース管理部や構成情報データベースの少なくとも一部の機能をコンピューターおよびプログラムで実現することができる。その場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。つまり、「コンピューター読み取り可能な記録媒体」とは、非一過性の（non-transitory）コンピューター読み取り可能な記録媒体であってよい。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、一時的に、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【0120】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【0121】
以上説明したように、いずれかの実施形態によれば、デバイスの使用実績や型式ごとの特性を元に、サービス要件を満たす信頼性をもつデバイスを選択し、ノードを構成することが可能となる。つまり、実施形態によれば、リソースごとの使用実績、および型式ごとの耐久年数や故障率といった属性を基に、クライアント装置から要求されたサービスレベルやサービス期間に対して適切なリソースを払い出すことで、サービスの信頼性を向上させることができる。その理由は、リソースごとの稼働時間、および型式ごとの故障率や耐久時間をリソース払い出しの判断材料とすることで、適切なリソースを選定できるためである。
【0122】
上記の実施形態の一部または全部は、以下の付記のようにも記載され得るが、以下には限られない。
【0123】
（付記１）
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備えるリソース管理装置。
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備えるリソース管理装置。
【0124】
（付記２）
前記リソース管理部は、構築した前記ノードを解体する要求を受け付け、当該解体するノードに割り当てられていた前記リソースを解放する処理を行うとともに、当該ノードを解体するように前記動的構成可能ノード装置を制御する、
付記１に記載のリソース管理装置。
前記リソース管理部は、構築した前記ノードを解体する要求を受け付け、当該解体するノードに割り当てられていた前記リソースを解放する処理を行うとともに、当該ノードを解体するように前記動的構成可能ノード装置を制御する、
付記１に記載のリソース管理装置。
【0125】
（付記３）
前記リソース属性記憶部は、前記リソース属性のうちの、型式に共通な属性情報を型式属性として記憶する型式属性記憶部、を含む、
付記１または２に記載のリソース管理装置。
前記リソース属性記憶部は、前記リソース属性のうちの、型式に共通な属性情報を型式属性として記憶する型式属性記憶部、を含む、
付記１または２に記載のリソース管理装置。
【0126】
（付記４）
前記ノード構築の要求は、前記リソースの規模を表す規模情報に関する条件を含み、
前記リソース属性記憶部は、前記規模情報を含む前記リソース属性を記憶し、
前記リソース管理部は、前記ノード構築の要求に含まれる前記規模情報に基づいて、前記リソース属性記憶部を参照することによって、前記規模情報に関する条件に合う前記リソースを、構築するノードに割り当てる、
付記１から３までのいずれか１つに記載のリソース管理装置。
前記ノード構築の要求は、前記リソースの規模を表す規模情報に関する条件を含み、
前記リソース属性記憶部は、前記規模情報を含む前記リソース属性を記憶し、
前記リソース管理部は、前記ノード構築の要求に含まれる前記規模情報に基づいて、前記リソース属性記憶部を参照することによって、前記規模情報に関する条件に合う前記リソースを、構築するノードに割り当てる、
付記１から３までのいずれか１つに記載のリソース管理装置。
【0127】
（付記５）
前記サービスレベルは、構築されるノードに含まれる前記リソースの許容故障率の情報を含み、
前記リソース属性記憶部は、前記リソースの故障率または前記リソースが属する型式の故障率、を記憶し、
前記リソース管理部は、前記リソース属性記憶部を参照することによって、前記ノード構築の要求に含まれる前記許容故障率以下の故障率のリソースを、構築するノードに割り当てる、
付記１から４までのいずれか１つに記載のリソース管理装置。
前記サービスレベルは、構築されるノードに含まれる前記リソースの許容故障率の情報を含み、
前記リソース属性記憶部は、前記リソースの故障率または前記リソースが属する型式の故障率、を記憶し、
前記リソース管理部は、前記リソース属性記憶部を参照することによって、前記ノード構築の要求に含まれる前記許容故障率以下の故障率のリソースを、構築するノードに割り当てる、
付記１から４までのいずれか１つに記載のリソース管理装置。
【0128】
（付記６）
前記リソース管理部は、前記動的構成可能ノード装置から受け取る個々の前記リソースの故障のイベントの通知に基づいて統計処理を行うことにより、前記リソース属性記憶部が記憶する前記故障率を更新する、
付記５に記載のリソース管理装置。
前記リソース管理部は、前記動的構成可能ノード装置から受け取る個々の前記リソースの故障のイベントの通知に基づいて統計処理を行うことにより、前記リソース属性記憶部が記憶する前記故障率を更新する、
付記５に記載のリソース管理装置。
【0129】
（付記７）
前記サービスレベルは、構築されるノードの最低稼働時間の情報を含み、
前記リソース属性記憶部は、個々の前記リソースごとの過去の累積の稼働時間と、前記リソースの製品としての耐久時間または前記リソースが属する型式の製品としての耐久時間と、を記憶し、
前記リソース管理部は、前記過去の累積の稼働時間と前記最低稼働時間との和が、前記耐久時間を超えないように、リソースを選択し、選択された前記リソースをノードに割り当てる、
付記１から６までのいずれか１つに記載のリソース管理装置。
前記サービスレベルは、構築されるノードの最低稼働時間の情報を含み、
前記リソース属性記憶部は、個々の前記リソースごとの過去の累積の稼働時間と、前記リソースの製品としての耐久時間または前記リソースが属する型式の製品としての耐久時間と、を記憶し、
前記リソース管理部は、前記過去の累積の稼働時間と前記最低稼働時間との和が、前記耐久時間を超えないように、リソースを選択し、選択された前記リソースをノードに割り当てる、
付記１から６までのいずれか１つに記載のリソース管理装置。
【0130】
（付記８）
動的構成可能ノード装置と、リソース管理装置と、を含むリソース管理システムであって、
前記動的構成可能ノード装置は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する装置であり、
前記リソース管理装置は、
前記動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備えるリソース管理装置である、
リソース管理システム。
動的構成可能ノード装置と、リソース管理装置と、を含むリソース管理システムであって、
前記動的構成可能ノード装置は、複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する装置であり、
前記リソース管理装置は、
前記動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備えるリソース管理装置である、
リソース管理システム。
【0131】
（付記９）
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理方法であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部に記憶し、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理過程、
を含んだリソース管理方法。
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理方法であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部に記憶し、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理過程、
を含んだリソース管理方法。
【0132】
（付記１０）
リソース管理装置としてコンピューターを機能させるためのプログラムであって、
前記リソース管理装置は、
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備える、
プログラム。
リソース管理装置としてコンピューターを機能させるためのプログラムであって、
前記リソース管理装置は、
複数の種別のリソースを動的に組み合わせてノードを構築する機能を有する動的構成可能ノード装置を制御するためのリソース管理装置であって、
個々のリソースごとに、最低稼働時間または許容される故障に関する統計情報である許容故障情報の少なくともいずれかを含んだサービスレベルを決定する要因であるサービスレベル決定要因を含んだリソース属性、を記憶するリソース属性記憶部と、
前記サービスレベル決定要因についての条件を含んだノード構築の要求を受け付け、前記リソース属性記憶部を参照することによって前記サービスレベル決定要因の条件を満たすように複数のリソースをノードに割り当てる処理を行い、当該割り当てたリソースを用いてノードを構築するように前記動的構成可能ノード装置を制御する、リソース管理部と、
を備える、
プログラム。
【0133】
（付記１１）
前記ノードを構築するための前記複数のリソースは、演算装置と主記憶装置とネットワークインターフェース装置とを少なくとも含む、
付記１に記載にリソース管理装置。
前記ノードを構築するための前記複数のリソースは、演算装置と主記憶装置とネットワークインターフェース装置とを少なくとも含む、
付記１に記載にリソース管理装置。
【0134】
（付記１２）
前記ノードを構築するための前記複数のリソースは、二次記憶装置をさらに含む、
付記１１に記載のリソース管理装置。
前記ノードを構築するための前記複数のリソースは、二次記憶装置をさらに含む、
付記１１に記載のリソース管理装置。
【産業上の利用可能性】
【0135】
本発明は、例えば、計算リソースを提供する産業（いわゆるデータセンター業やクラウドサーバー提供業）等において利用することができる。但し、本発明の利用範囲はここに例示したものには限られない。
【符号の説明】
【0136】
１，１Ａ，１Ｂ リソース管理サーバー装置（リソース管理装置）
２ ＣＤＩ装置（動的構成可能ノード装置）
３ クライアント装置
４ 型式テーブル（リソース属性記憶部，型式属性記憶部）
５ リソーステーブル（リソース属性記憶部）
６ サービスレベルテーブル（サービスレベル記憶部）
１１，１１Ａ リソース管理部
１２ 構成情報データベース
１７ 分析機能部
１２０ リソース属性記憶部
２０１，２０２，２０３，・・・ ＣＰＵ
２１１，２１２，２１３，・・・ ＤＩＭＭ
２２１，２２２，２２３，・・・ ＳＳＤ
２３１，２３２，２３３，・・・ ＮＩＣ
１０００，１０００Ａ リソース管理システム
２ ＣＤＩ装置（動的構成可能ノード装置）
３ クライアント装置
４ 型式テーブル（リソース属性記憶部，型式属性記憶部）
５ リソーステーブル（リソース属性記憶部）
６ サービスレベルテーブル（サービスレベル記憶部）
１１，１１Ａ リソース管理部
１２ 構成情報データベース
１７ 分析機能部
１２０ リソース属性記憶部
２０１，２０２，２０３，・・・ ＣＰＵ
２１１，２１２，２１３，・・・ ＤＩＭＭ
２２１，２２２，２２３，・・・ ＳＳＤ
２３１，２３２，２３３，・・・ ＮＩＣ
１０００，１０００Ａ リソース管理システム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】