JP2018185607A - リソース管理システムおよびリソース管理方法 - Google Patents

Abstract

【課題】より正確にリソースの予約の可否を判定する。【解決手段】仮想化されたリソースの予約要求をユーザから受け付けた場合に、リソースの空き状況に基づいてリソースの予約を行うリソース管理システム１００であって、予約対象のリソースを識別するリソース識別子を予約元のユーザから受信する予約受付部１０３と、既存のリソースの識別子を記憶する構成情報テーブル１０８と、予約済みのリソースの識別子を記憶する予約情報テーブル１０９と、既存および予約済みのリソースの識別子と、予約受付部１０３により受信されたリソース識別子とに基づいてリソースの予約を行うか否かを判定する判定部１０４と、判定部１０４による判定結果に基づいてリソースの予約を行うスケジュール登録部１０５と、を備える。【選択図】図１

Description

本発明は、リソース管理システムおよびリソース管理方法に関するものである。

近年、ＩａａＳ(Infrastructure as a Service)を提供するクラウドサービスが発展してきている。ユーザは、クラウドサービス事業者と契約することで、所望の処理能力・ストレージを有する仮想マシン、仮想ネットワーク、仮想ルータ等の仮想機器（リソース）をオンデマンドで利用することができる（例えば、Amazon Web Service（登録商標）、vCenter等）。ユーザがクラウドサービス上で取得したリソースから成る環境をクラウド環境と呼ぶ。

クラウドサービスでは、一般的に、リソースを取得・変更（プロビジョニング）するためのＡＰＩ(Application Programming Interface)が公開されている。クラウド環境の生成や予約を管理するリソース管理システムが、ユーザからリソース予約要求を受け付けると、当該ＡＰＩを用いることによりリソースを取得・変更する処理をすることができる。例えば、「来月1日に仮想マシンを作成する」というユーザからのリソース予約要求を受け付けた場合、リソース管理システムは、上記のＡＰＩを利用したスクリプトおよびスケジューラにより、ユーザのリソース予約要求に応じたタイミングでリソースを取得することができる。このように、リソース管理システムは、リソース予約要求に応じて、省力化してリソースを取得することができる。

上記のようなクラウドサービスの技術として、特許文献１には、リソース管理システムが、複数のソフトウェア開発のテスト実行に利用される共有システムのリソースを管理する旨が記載されている。具体的に、リソース管理システムは、リソース予約要求元の端末から受信した実行条件等に基づいて利用条件を決定し、当該利用条件でリソースを割当てることができると判断した場合に、リソースの割当てを予約する。

特開２０１６−２４６９７号公報

上述した従来技術では、用途（テストの実行条件等）と、クラウドサービス提供側のリソースの空き状況とに基づいて、リソースの予約可否を判定している。

しかしながら、リソースの空きが十分であっても、予約可能と判定することが適切でない場合もある。例えば、ユーザのポリシー（リソース使用制限）に反している場合や仮想リソースの識別情報（識別子）が重複してしまう場合等が挙げられる。この場合、予約する段階では、問題が無くても実際にリソースを割り当てる段階で割り当て失敗してしまう可能性がある。

そこで、本発明の目的は、より正確にリソースの予約の可否を判定することができるリソース管理システムおよびリソース管理方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるリソース管理システムは、仮想化されたリソースの予約要求をユーザから受け付けた場合に、リソースの空き状況に基づいてリソースの予約を行うリソース管理システムであって、予約対象のリソースを識別するリソース識別子を予約元のユーザから受信する受信部と、既存および予約済みのリソースの識別子を記憶する記憶部と、前記記憶部に記憶された既存および予約済みのリソースの識別子と、前記受信部により受信されたリソース識別子とに基づいてリソースの予約を行うか否かを判定する判定部と、前記判定部による判定結果に基づいてリソースの予約を行う予約部と、を備えるものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、より正確にリソースの予約の可否を判定することができる。

本発明の一実施の形態であるリソース管理システムの構成例について概要を示した図である。 本発明の一実施の形態におけるポリシーを登録する処理の流れの例について概要を示した図である。 本発明の一実施の形態における構成情報を登録する処理の流れの例について概要を示した図である。 本発明の一実施の形態におけるリソース予約の可否を判定する処理の流れの例について概要を示した図である。 本発明の一実施の形態におけるリソース取得する処理の流れの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。

＜システム構成＞
図１は、本発明の一実施形態であるリソース管理システムを含む情報処理システムの構成例について概要を示した図である。本実施の形態のリソース管理システム１００は、仮想化されたリソースの予約要求をユーザ２００から受け付けた場合に、リソースの空き状況に基づいてリソースの予約を行うシステムである。仮想化されたリソースとは、仮想マシン、仮想ネットワーク、仮想ルータ等の仮想機器であり、仮想化されたハードウェア資源を示す。

リソース管理システム１００とネットワーク３００を介して接続されるクラウドサービス４００は、上記の仮想化されたリソースを有する。すなわち、クラウドサービス４００は、クラウドサービスを提供するサーバ、ディスク等の装置群（クラウドサービス基盤）である。ユーザ２００は、パーソナルコンピュータ等の端末装置であり、ネットワーク３００を介してリソース管理システム１００と情報の送受信を行うことができる。

リソース管理システム１００、ユーザ２００、およびクラウドサービス４００は、所定のハードウェアおよびソフトウェアにより実装される。例えば、リソース管理システム１００、ユーザ２００、およびクラウドサービス４００は、プロセッサやメモリなどを有する。当該プロセッサにより実行されるメモリ上のプログラムが、リソース管理システム１００、ユーザ２００、およびクラウドサービス４００のコンピュータを機能させる。

本実施の形態のリソース管理システム１００は、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェア上で稼働するソフトウェアプログラムとして実装されたポリシー登録部１０１、構成情報登録部１０２、予約受付部１０３、判定部１０４、予約部として機能するスケジュール登録部１０５、およびスケジュール実行部１０６などの各部を有する。また、データベース等として実装されたポリシーテーブル１０７、構成情報テーブル１０８、予約情報テーブル１０９、およびスケジュールテーブル１１０などの各データストア（記憶部）を有する。

ポリシー登録部１０１は、ユーザ２００からポリシー情報を受信し、受信したポリシー情報をポリシーテーブル１０７へ登録する機能を有する。ポリシーとは、各ユーザ２００によるリソースの使用制限を示すものである。当該制限は、数式などで示される。また、当該制限の例として、実行時に見込まれるクラウドサービスを使用するコストの制限、リソースの容量（ＣＰＵ、メモリ、ストレージ等）の制限、リソースの個数（ＩＰアドレス数、ネットワーク数、仮想マシン台数等）の制限が挙げられる。

ポリシー情報は、ユーザ２００を識別する情報（例えば、ユーザＩＤ）と、当該ユーザ２００のポリシーとを対応付けた情報である。このように、ポリシー登録部１０１が、ポリシー情報をポリシーテーブル１０７へ登録することにより、ポリシーテーブル１０７は、各ユーザ２００の使用制限を示す情報を記憶する。なお、ポリシー情報は、上記の複数の制限を全て含んでもよいし、何れか一つの制限を含むようにしてもよい。

構成情報登録部１０２は、クラウドサービス４００のクラウド環境の構成情報を定期的に収集する機能である。構成情報登録部１０２は、予め定められているタイミング（例えば、１日１回）でクラウドサービス４００に対して構成情報の取得要求（構成情報取得要求）をする。構成情報登録部１０２は、クラウドサービス４００から構成情報を受信すると、当該構成情報を構成情報テーブル１０８へ登録する。構成情報登録部１０２は、クラウドサービス４００によって公開されているＡＰＩを利用して、構成情報取得要求をしたり、クラウドサービス４００から構成情報を取得したりする。

なお、この構成情報は、公知の構成情報であり、例えば、現状のクラウドサービス４００の仮想マシンに関する情報であり、仮想マシンの識別情報を含む。このように、構成情報登録部１０２が構成情報を構成情報テーブル１０８に登録することにより、構成情報テーブル１０８は、既存のリソースの識別子を記憶する。リソースの識別子の例として、リソースの名称（例えば、仮想マシン名）や仮想マシンのＩＰアドレス等が挙げられる。

また、スケジュール登録部１０５によって、予約元のユーザＩＤと、予約対象のリソースの内容（プロビジョニングの内容）とを対応付けた情報（予約情報）が予約情報テーブル１０９に登録される。この予約対象のリソースの内容には、予約対象のリソースの識別子が含まれる。よって、予約情報テーブル１０９は、予約済みのリソースの識別子を記憶することになる。また、上記に予約対象のリソースの内容には、予約対象の仮想マシンの台数、仮想マシンのスペックを示す情報（予約対象のリソースの属性に関する情報）も含まれる。仮想マシンのスペックとは、仮想マシンのＣＰＵの処理能力、メモリ容量、ストレージ容量等を示す。スケジュール登録部１０５が、予約情報テーブル１０９に予約情報を登録する具体的な方法については、後述する。

予約受付部１０３は、ユーザ２００からのリソース予約要求を受信する機能である。具体的に、予約受付部１０３は、予約元のユーザ２００からユーザＩＤと、予約対象のリソースの内容と、実行日時を示す情報とを受信すると共に、リソース予約要求を受信する。このように、予約受付部１０３は、予約対象のリソースの識別子と、予約対象のリソースの属性情報とを受信する。

予約受付部１０３は、ユーザＩＤと、予約対象のリソースの内容と、実行日時を示す情報とを受信すると、これらの情報を判定部１０４へ送出する。

判定部１０４は、ユーザ２００からのリソース予約が適切か否かを判定する機能である。判定部１０４は、予約受付部１０３からユーザＩＤと、予約対象のリソースの内容と、実行日時を示す情報とを取得する。判定部１０４は、これらの情報を取得すると、取得したユーザＩＤに対応するポリシー情報をポリシーテーブル１０７から取得する。また、判定部１０４は、構成情報テーブル１０８から構成情報を取得する。また、判定部１０４は、予約情報テーブル１０９から全ての予約情報を取得する。

続いて、判定部１０４は、予約対象のリソースのリソース識別子が、構成情報に含まれるリソース識別子および予約情報テーブル１０９から取得した予約情報に含まれるリソース識別子の何れかと一致するか否かを判定する（一意性抵触判定）。判定部１０４は、当該判定の結果、一致する場合（一意性制限に抵触する場合）、ユーザ２００からのリソース予約が適切でないと判定する。これは、仮に予約しても、重複するリソース識別子が存在するため、プロビジョニングする段階でプロビジョニングに失敗してしまうからである。

判定部１０４は、上記判定の結果一致しない場合、予約対象のリソースの内容と、ポリシー情報におけるリソースの容量又は個数の制限とを比較して、ポリシー情報が示すリソースの容量又は個数の制限に抵触しないか否かを判定する（容量個数抵触判定）。例えば、ポリシー情報に示されるリソースの容量の制限が５００ＧＢ以下である場合に、予約対象のリソースの容量が７００ＧＢである場合、判定部１０４は、ポリシー情報が示すリソースの容量の制限に抵触すると判定する。また、予約対象のリソースの容量が２００ＧＢであれば、判定部１０４は、原則として、ポリシー情報が示すリソースの容量の制限に抵触しないと判定する。

また、判定部１０４は、予約受付部１０３から取得したユーザＩＤに対応する予約情報がある場合、予約対象のリソース内容に、当該予約情報のリソースの内容を加味して上記の容量個数抵触判定をしてもよい。例えば、予約対象のリソースの容量が２００ＧＢであり、ユーザＩＤに対応する予約情報のリソース内容が示すリソースの容量が４００ＧＢであるとする。この場合、判定部１０４は、それぞれを加算した結果、ポリシー情報が示すリソースの容量の制限を超えれば、ポリシー情報が示すリソースの容量の制限に抵触すると判定する。

判定部１０４は、容量個数抵触判定をした結果、ポリシー情報が示すリソースの容量又は個数の制限に抵触しないと判定した場合、予約対象のリソースの内容に基づいてプロビジョニングを実施した場合のコストを算出する。例えば、容量、個数に対応するコストの情報を予め記憶しておき、当該情報と予約対象のリソースの内容とを用いて、判定部１０４がコストを算出する。続いて、判定部１０４は、算出したコストと、ポリシー情報が示すコストの制限に抵触しないか否かを判定する（コスト抵触判定）。例えば、算出したコストが、ポリシー情報が示すコストの制限を超えた場合、判定部１０４は、ポリシー情報が示すコストの制限に抵触したと判定する。

なお、判定部１０４は、容量個数抵触判定と同様に、予約受付部１０３から取得したユーザＩＤに対応する予約情報がある場合、予約対象のリソース内容に基づいたコストに、当該予約情報のリソースの内容に基づいたコストを加味してもよい。

判定部１０４は、コスト抵触判定をした結果、ポリシー情報が示すコストの制限に抵触しないと判定した場合、予約対象のリソースの内容に基づいて、クラウドサービス４００のリソースの空きがあるか否かを判定する（空きリソース判定）。この判定は、公知の手法により判定することができる。例えば、構成情報、予約情報等を用いて、予約対象のリソースを提供できる程度に空きリソースがあるか否かを判定する。

判定部１０４は、一意性抵触判定、容量個数抵触判定、およびコスト抵触判定の結果、何れかの制限に抵触すると判定した場合、または空きリソース判定でリソースの空きが無いと判定した場合、予約不可と判定する。そして、判定部１０４は、予約不可である旨とユーザＩＤとをスケジュール登録部１０５へ送出する。また、判定部１０４は、空きリソース判定の結果、リソースの空きがあると判定した場合、予約可能と判定する。そして、判定部１０４は、予約可能である旨と、ユーザＩＤと、予約対象のリソースの内容と、実行日時を示す情報とをスケジュール登録部１０５へ送出する。

スケジュール登録部１０５は、判定部１０４による判定結果に基づいてリソースの予約を行う機能である。スケジュール登録部１０５は、判定部１０４からユーザＩＤと、予約不可の旨を取得した場合、当該ユーザＩＤのユーザ２００に対して予約不可の旨を通知する。

また、スケジュール登録部１０５は、予約可能である旨と、ユーザＩＤと、予約対象のリソースの内容と、実行日時を示す情報とを取得した場合、ユーザＩＤと、予約対象のリソースの内容とを対応付けた情報を予約情報として、予約情報テーブル１０９へ登録する。また、スケジュール登録部１０５は、ユーザＩＤと、予約対象のリソースの内容と、実行日時を示す情報とを対応付けた情報をスケジュール情報としてスケジュールテーブル１１０へ登録する。さらに、スケジュール登録部１０５は、当該ユーザＩＤのユーザ２００に対して予約した旨を通知する。

スケジュール実行部１０６は、スケジュールテーブル１１０に記憶されている情報に基づいて、プロビジョニングを実行する機能である。スケジュール実行部１０６は、スケジュールテーブル１１０に記憶されているスケジュール情報の実行日時を示す情報を参照する。そして、スケジュール実行部１０６は、実行日時に該当したことを検知すると、当該スケジュール情報の予約対象のリソース内容をクラウドサービス４００へ送信すると共に、プロビジョニング要求をする。続いて、スケジュール実行部１０６は、クラウドサービス４００からプロビジョニング要求した結果を取得し、当該スケジュール情報に結果を付加する。

また、スケジュール実行部１０６は、当該スケジュール情報のユーザＩＤとリソース内容とを含む予約情報を予約情報テーブル１０９から解放（削除）する。なお、スケジュール実行部１０６は、ＡＰＩを利用したスクリプトおよびスケジューラにより実現されてもよい。

図１の例に示すリソース管理システム１００は、複数のサーバシステム等に機能を分散して構成してもよいし、１つのサーバシステムに集約して構成してもよい。

＜処理の流れ（ポリシー情報の登録）＞
図２は、本実施の形態におけるポリシーを登録する処理の流れの例について概要を示した図である。まず、ユーザ２００の操作者による操作によりポリシーが入力されると、ユーザ２００は、ユーザ２００の識別情報（ユーザＩＤ）と、当該ポリシーとを対応付けたポリシー情報をリソース管理システム１００へ送信する（Ｓ０１）。リソース管理システム１００のポリシー登録部１０１は、上記ポリシー情報を受信し、受信したポリシー情報をポリシーテーブル１０７へ登録し（Ｓ０２）、処理を終了する。

＜処理の流れ（構成情報の登録）＞
図３は、本実施の形態における構成情報を登録する処理の流れの例について概要を示した図である。まず、リソース管理システム１００の構成情報登録部１０２は、取得タイミングになったことを検出した場合、クラウドサービス４００に対して構成情報取得要求をする（Ｓ１１）。クラウドサービス４００は、当該構成情報取得要求を受信すると、当該要求に応じて構成情報をリソース管理システム１００へ送信する（Ｓ１２）。リソース管理システム１００の構成情報登録部１０２は、クラウドサービス４００から構成情報を受信すると、当該構成情報を構成情報テーブル１０８へ登録して（Ｓ１３）、処理を終了する。

＜処理の流れ（リソース予約の可否判定）＞
図４は、本実施の形態におけるリソース予約の可否を判定する処理の流れの例について概要を示した図である。まず、予約受付部１０３は、予約元のユーザ２００からユーザＩＤと、予約対象のリソースの内容と、実行日時を示す情報とを受信すると共に、リソース予約要求を受信する（Ｓ２１）。続いて、判定部１０４は、構成情報と、当該ユーザＩＤに対応するポリシー情報と、予約情報とを取得する（Ｓ２２）。

続いて、判定部１０４は、一意性抵触判定をする（Ｓ２３）。一意性制限に抵触する場合（Ｓ２３：Ｎｏ）、判定部１０４は、予約不可と判定し、ステップＳ２９へ進む。一方、一意性制限に抵触しない場合（Ｓ２３：Ｙｅｓ）、判定部１０４は、容量個数抵触判定をする（Ｓ２４）。容量個数制限に抵触する場合（Ｓ２４：Ｎｏ）、判定部１０４は、予約不可と判定し、ステップＳ２９へ進む。一方、容量個数制限に抵触しない場合（Ｓ２４：Ｙｅｓ）、判定部１０４は、コスト抵触判定をする（Ｓ２５）。コスト制限に抵触する場合（Ｓ２５：Ｎｏ）、判定部１０４は、予約不可と判定し、ステップＳ２９へ進む。一方、コスト制限に抵触しない場合（Ｓ２５：Ｙｅｓ）、判定部１０４は、空きリソース判定をする（Ｓ２６）。

空きリソース判定をした結果、空きリソースが無い場合（Ｓ２６：Ｎｏ）、判定部１０４は、予約不可と判定し、ステップＳ２９へ進む。一方、空きリソースがある場合（Ｓ２６：Ｙｅｓ）、判定部１０４は、予約可能と判定する。そして、スケジュール登録部１０５は、予約情報テーブル１０９に予約情報を登録する（Ｓ２７）。続いて、スケジュール登録部１０５は、スケジュールテーブル１１０にスケジュール情報を登録する（Ｓ２８）。続いて、スケジュール登録部１０５は、判定部１０４による判定結果をユーザ２００へ送信し（Ｓ２９）、処理を終了する。なお、上述のステップＳ２３、Ｓ２４、Ｓ２５、およびＳ２６のそれぞれの判定処理は、上記の順に限らず、何れの判定処理から始めてもよい。

＜処理の流れ（構成情報の登録）＞
図５は、本実施の形態におけるリソース取得する処理（プロビジョニング）の流れの例について概要を示した図である。まず、スケジュール実行部１０６は、スケジュールテーブル１１０に記憶されているスケジュール情報の実行日時を示す情報を参照し、実行日時に該当したことを検知すると、クラウドサービス４００へプロビジョニング要求をする（Ｓ３１）。これに応じて、クラウドサービス４００は、プロビジョニング要求に応じてプロビジョニングを行い、その結果をリソース管理システム１００へ送信する（Ｓ３２）。

スケジュール実行部１０６は、クラウドサービス４００からプロビジョニング要求した結果を取得する。続いて、スケジュール実行部１０６は、スケジュール情報に結果を付加する（Ｓ３３）。最後に、スケジュール実行部１０６は、当該スケジュール情報のユーザＩＤとリソース内容とを含む予約情報を予約情報テーブル１０９から解放して（Ｓ３４）、処理を終了する。

以上に説明したように、本発明の一実施の形態であるリソース管理システム１００によれば、予約対象のリソースのリソース識別子が、構成情報に含まれるリソース識別子および予約情報テーブル１０９から取得した予約情報に含まれるリソース識別子の何れかと一致するか否かを判定し、この判定結果に基づいて予約の可否を判定するので、クラウドサービス４００のリソースの空き状況に基づいて予約の可否を判定する場合と比較して、より正確にリソースの予約の可否を判定することができる。従って、スケジュール実行部１０６が、プロビジョニング処理に失敗してしまうことを回避することができる。この結果、スケジュール実行部１０６は、クラウド環境の運用を適切に自動化することができる。

また、上述のリソース管理システム１００によれば、予約対象のリソースの内容と、ポリシー情報とを比較して、ポリシー情報が示す制限に抵触するか否かを判定し、この判定結果に基づいて予約の可否を判定する。これにより、クラウドサービス４００のリソースの空き状況に基づいて予約の可否を判定する場合と比較して、より正確にリソースの予約の可否を判定することができる。従って、スケジュール実行部１０６が、プロビジョニング処理に失敗してしまうことを回避することができる。この結果、スケジュール実行部１０６は、クラウド環境の運用を適切に自動化することができる。また、ポリシーを逸脱してしまうことも回避することができる。

上述の実施形態では、特に述べなかったが、複数種類の識別子（例えば、リソース名とＩＰアドレス）のそれぞれについて、一意性抵触判定してもよい。この場合、少なくとも一種類の識別子について一意性制限に抵触すると判定した場合、予約不可と判定してもよい。

上述の実施形態では、一意性抵触判定、容量個数抵触判定、およびコスト抵触判定をする場合について述べたが、全て行う必要はなく、何れか一つでもよい。この場合でも、正確にリソースの予約の可否を判定することができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、リソースの予約を行うリソース管理システムに利用可能である。

１００…リソース管理システム、
１０１…ポリシー登録部、１０２…構成情報登録部、１０３…予約受付部、１０４…判定部、１０５…スケジュール登録部、１０６…スケジュール実行部、１０７…ポリシーテーブル、１０８…構成情報テーブル、１０９…予約情報テーブル、１１０…スケジュールテーブル、
２００…ユーザ、３００…ネットワーク、４００…クラウドサービス

Claims (5)

1. 仮想化されたリソースの予約要求をユーザから受け付けた場合に、リソースの空き状況に基づいてリソースの予約を行うリソース管理システムであって、
   予約対象のリソースを識別するリソース識別子を予約元のユーザから受信する受信部と、
   既存および予約済みのリソースの識別子を記憶する記憶部と、
   前記記憶部に記憶された既存および予約済みのリソースの識別子と、前記受信部により受信されたリソース識別子とに基づいてリソースの予約を行うか否かを判定する判定部と、
   前記判定部による判定結果に基づいてリソースの予約を行う予約部と、
   を備えるリソース管理システム。
2. 請求項１に記載のリソース管理システムにおいて、
   前記受信部は、前記予約対象のリソースの属性に関する情報である属性情報をさらに受信し、
   前記記憶部は、各ユーザの使用制限を示す制限情報をさらに記憶し、
   前記判定部は、前記記憶部に記憶されている予約対象のユーザの制限情報と、前記受信部により受信された使用情報とに基づいてリソースの予約を行うか否かを判定する、リソース管理システム。
3. 仮想化されたリソースの予約要求をユーザから受け付けた場合に、リソースの空き状況に基づいてリソースの予約を行うリソース管理システムであって、
   予約の対象となるリソースの属性に関する情報である属性情報を予約元のユーザから受信する受信部と、
   各ユーザのリソースの使用制限を示す制限情報を記憶する記憶部と、
   前記記憶部に記憶されている予約要求元のユーザの制限情報と、前記受信部により受信された使用情報とに基づいて、リソースの予約を行うか否かを判定する判定部と、
   前記判定部による判定結果に基づいてリソースの予約を行う予約部と、
   を備えるリソース管理システム。
4. 仮想化されたリソースの予約要求をユーザから受け付けた場合に、リソースの空き状況に基づいてリソースの予約を行うリソース管理システムにおけるリソース管理方法であって、
   前記リソース管理システムは、既存および予約済みのリソースの識別子を記憶し、
   前記リソース管理システムの受信部が、予約対象のリソースを識別するリソース識別子を予約要求元のユーザから受信する受信ステップと、
   前記リソース管理システムの判定部が、前記リソース管理システムによって記憶されている既存および予約済みのリソースの識別子と、前記受信ステップで受信したリソース識別子とに基づいてリソースの予約を行うか否かを判定する判定ステップと、
   前記リソース管理システムの予約部が、前記判定ステップで判定した判定結果に基づいてリソースの予約を行う予約ステップと、
   を有する、リソース管理方法。
5. 仮想化されたリソースの予約要求をユーザから受け付けた場合に、リソースの空き状況に基づいてリソースの予約を行うリソース管理システムにおけるリソース管理方法であって、
   前記リソース管理システムは、各ユーザのリソースの使用制限を示す制限情報を記憶し、
   前記リソース管理システムの受信部が、予約の対象となるリソースの属性に関する情報である属性情報を予約要求元のユーザから受信する受信ステップと、
   前記リソース管理システムの判定部が、前記リソース管理システムによって記憶されている予約要求元のユーザの制限情報と、前記受信ステップで受信した使用情報とに基づいて、リソースの予約を行うか否かを判定する判定ステップと、
   前記リソース管理システムの予約部が、前記判定ステップで判定した判定結果に基づいてリソースの予約を行う予約ステップと、
   を有する、リソース管理方法。

Images