JP6190969B2 - マルチテナントリソース調停方法 - Google Patents

Description

本発明は、マルチテナント間のリソースを調停する技術に関する。

近年，利用者の要求に応じてオンデマンドに計算機リソース（以降，リソースと呼称する）を提供するクラウドコンピューティングと呼ばれる計算機環境が広く普及している。クラウドコンピューティング環境では，様々な要件を持った異なる種別の業務システム（以降，テナントと呼称する）が計算機環境のリソースを共有しながら複数稼働する構成が一般的であり，そのような構成をマルチテナント環境と呼称する。マルチテナント環境では、新規のテナントを投入する場合や稼働中のテナントにリソースを追加する場合に，マルチテナント環境に要求されるリソース確保要求に対して十分な空きが存在しない状況が生じ得る。特許文献１には，計算機環境のリソース量または使用量を参照して，要求されるリソース確保要求に対して割り当てリソース量を調節する機能を備えたリソース割当方法が開示されている。

特許第５２５６７４４号

テナントがリソース確保を要求する際，例えば夜間バッチジョブなど、処理の種類によってはリソースを利用する期間が限定されている場合があるため、リソース確保期間に応じて他テナントがリソース提供可能か否かを考慮することが必要である。テナントで稼動する業務システムの繁忙期以外の期間であれば中長期にリソース提供可能と判断することができる。特許文献１では，計算機環境のリソース量または使用量のみ考慮したリソース調停であるため，テナントのリソース確保要求の期間を考慮した調停は考えられていない。

またテナント間のリソースのやりとりを円滑に行うためには，リソースを貸す側のリソース提供方法を適切に選択する必要がある。例えば，テナントが短期にリソース追加を要求する場合には，リソース利用終了後にそのリソースを元のテナントへ返却することが容易であることが望ましい。特許文献１では，リソースのやりとりを考慮したリソース確保手段の決定は考えられていない。

さらに，テナントのリソース確保要求を満足するためにリソースの機能形態を考慮する必要が生じ得る。例えば，テナントが仮想マシン２台分のリソース追加を要求し，なおかつ高可用性を考慮して仮想マシンを別々の物理マシン上で稼働させるＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）構成を要求する，といった場合への対応が求められ得る。特許文献１では，リソースの機能形態を考慮したリソース調停方法は考えられていない。

本発明では、上記の事情を鑑みて、リソースの割り当てを要求するテナントのリソース確保要求の要求期間や利用している機能など、テナントのリソース利用形態を考慮して、提供可能なリソースを算出してリソースの調停を行う方法を提供する。

複数のテナントが存在する環境下でのリソース調停の効率の向上を図ることができる。

本発明の実施例１の概要を示した図である。 本発明の実施例１の調停サーバのモジュール構成を示した図である。 本発明の実施例１のテナント構成情報を示した図である。 本発明の実施例１のテナントポリシー情報を示した図である。 本発明の実施例１のテナント利用状況情報を示した図である。 本発明の実施例１のリソース調停結果情報を示した図である。 本発明の実施例１の全体処理のフローチャートである。 本発明の実施例１のリソース提供候補算出処理のフローチャートである。 本発明の実施例１の提供可能リソース量算出処理のフローチャートである。 本発明の実施例２のテナントポリシー情報を示した図である。 本発明の実施例２のリソース調停レベル情報を示した図である。 本発明の実施例２のリソース提供候補算出処理のフローチャートである。 本発明の実施例２のリソース提供候補算出処理のフローチャートである。

図１は，実施例１の概略を説明した図である。

はじめにリソースを必要とする「テナント１」が各種条件を含む「リソース確保要求」を「調停サーバ」へ送信する。「リソース確保要求」には，リソースの種別，リソースの各要求量，およびリソースの利用期間を含む。次に「調停サーバ」は「リソース確保要求」と「テナントポリシー情報」に基づき他のテナントである「テナント２」「テナント３」のリソース調停を指示する。ここで「テナントポリシー情報」には，テナント毎の制限事項，リソース確保方法，といった情報を含んでいる。「調停サーバ」にリソースの調停を指示された「テナント２」および「テナント３」は，「テナントポリシー情報」に定義されたリソース確保方法に従い，リソースの確保を実施する。図１の例では，「テナント２」は「テナント１」のリソース確保要求が短期間であると判断し，「テナント１」のリソース利用が終了次第すぐにリソースを回収できるよう，仮想マシンに割り当てられているリソース量の割当を変更することでリソース確保を実施している。同様に「テナント３」は「テナント１」のリソース確保要求が長期間であると判断し，長期に自テナントのリソースを解放するため仮想マシンを削除することでリソース確保を実施している。このように，テナントが要求するリソース確保要求の条件の一つである利用期間に応じて，各テナントがリソース確保する方法を適切に選択することで，テナント間のリソース調停を効率的に実施できる。

図２は，調停サーバ１の詳細な構成を示した図である。

調停サーバ１は，マルチテナント環境でテナントを管理し、テナントのリソース確保要求を調停する計算機であって，ＣＰＵ１１，記憶資源１２，および通信インターフェース１３を含む。後ほど詳細を示すが、記憶資源１２は、各種調停処理モジュールと、各種情報を格納し、ＣＰＵ１１は、各種調停処理モジュールを実行することで、各種調停処理を行う。なお、記憶資源１２は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、フラッシュメモリ、ＤＲＡＭ、及びこれら組み合わせであることが考えられるが、プログラム及び情報を格納できるデバイスであれば、どのようなデバイスでもよい。

テナント３は，調停サーバ１に対してリソース確保要求を送信する計算機群，または調停サーバ１からの指示に従ってリソース調停を実行する計算機群であって，ネットワーク２を介して調停サーバ１に管理される。マルチテナント環境におけるテナントは、１つ以上の物理リソースまたは仮想リソースで構成される。また、物理リソースは1以上の物理サーバ７で構成され、物理サーバはリソースとして通信I/F 71、CPU 72、メモリ73、ディスク74を備え、仮想サーバ75を実行する。テナントで稼動するサービスやアプリケーションには，例えばＷｅｂサーバとＤＢサーバで構成されるＷｅｂシステムや，バッチ処理を実行するバッチ処理基盤システムが含まれる。

管理プログラム１０００は，リソース状態監視モジュール１００と，リソース要求応答モジュール１０１と，リソース提供候補算出モジュール１０２と，リソース調停指示モジュール１０３で構成される。

リソース状態監視モジュール１００は，テナント３の構成情報およびリソース利用情報を定期的または監視要求時に取得し，テナント構成情報２００およびテナント利用状況情報２０２に格納する。

リソース要求処理モジュール１０１は，テナント３からのリソース確保要求を受信し，リソース調停処理後の結果をリソース確保要求元のテナント３へ送信する。

ここでリソース確保要求には，物理計算機，仮想計算機，プログラム，サービスに割り当て可能なリソースの種別と量，当該リソースの利用期間を示す情報を含む。

リソースの種別としては，例えば，マシン台数，ＣＰＵ数，ＣＰＵ周波数，ＣＰＵ１個あたりの占有量や予約量、メモリ量，Ｉ／Ｏスループット量，Ｉ／Ｏ帯域量，Ｉ／Ｏ容量あたりの占有量や予約量、キャッシュ容量などを記載できる。

リソースの利用期間としては，始期と期間を指定する方法や、終期を指定する方法、あるいは始期のみを指定する方法がある。始期と期間を指定する方法の例としては「現時刻から３時間利用」「１５：００から２０時間利用」といった記載が挙げられる。終期を指定する方法の例としては，「本日０６：００まで利用」「２０１４年７月２日 １０：００まで利用」といった記載が挙げられる。始期のみを指定する方法の例としては「現時刻より利用開始」「２０１４年７月２９日 １８：００より利用開始」といった記載が挙げられる。

リソース提供候補算出モジュール１０２は，テナント３からのリソース確保要求を基に，他のテナント３が提供可能なリソース量を算出し，算出結果をリソース調停結果情報２３０に格納する。

リソース調停指示モジュール１０３は，リソース提供候補算出モジュール１０２の算出したリソース調停結果情報２３０の内容に従い，テナント３へリソース確保手段の実行を指示する。

管理計算機４は、物理および仮想のリソース構成を制御する計算機であって、リソース構成を制御する構成モジュール５と、リソース構成情報６をメモリ上に持つ。構成モジュール５が制御を実行する契機としては、管理計算機４や調停サーバ１、または他の計算機で稼動するプログラムからの実行命令が挙げられるが、これに限定されず、管理者からの操作受付を契機に制御を実行してもよい。リソース構成情報６は管理計算機４で稼動するプログラムが作成するが、これに限定されず、他の計算機で稼動するプログラムの持つ情報を定期的に収集したり、管理者や他プログラムからの収集命令を契機に他の計算機で稼動するプログラムの持つ情報を収集したり、あるいは管理者が入力することで作成されてもよい。さらにリソース構成情報６は構成モジュール５により利用されうるが、これに限定されず、他のプログラムからの開示命令に応答して情報提供してもよい。

次に，図３乃至図６を用いて格納情報について説明する。

図３は，テナント構成情報２００を示している。テナント構成情報２００は、図３−ａで示すテナント毎の仮想マシン構成を定義するテナント内仮想マシン構成情報２０１と、図３−ｂで示す物理マシン構成情報２０６で構成される。テナント内仮想マシン構成情報２０１は，テナントに所属する仮想マシン名２０２と，当該仮想マシンが稼働する稼働マシン名２０３と，当該仮想マシンに割り当てられているＣＰＵ数２０４と，当該仮想マシンに割り当てられているメモリ量２０５を含む。さらに稼働マシン名２０３にある各マシンの構成情報は物理マシン構成情報２０６で定義されており、物理マシン構成情報２０６は物理マシン名２０７と，マシンの総ＣＰＵ数２０８と，マシンの総メモリ量２０９を含む。

仮想マシン名２０２は仮想マシンが一意に識別できる情報であればよく，管理者が手動で記録してもよいし，仮想マシンに設定されている情報をソフトウェアが読み取り記録してもよい。同様に稼働マシン名２０３も稼働マシンが一意に識別できる情報であればよく，管理者が手動で記録してもよいし，稼働マシンに設定されている情報をソフトウェアが読み取り記録してもよい。

ＣＰＵ割当数２０４は仮想マシンに割り当てられているＣＰＵの数を示しているが，仮想マシンに割り当てられているＣＰＵの程度を示す情報であればよく，ＣＰＵ周波数を使用してもよい。仮想マシンに割り当てられているＣＰＵの種別は物理ＣＰＵまたは仮想ＣＰＵである。

図４は，テナントポリシー情報２１０を示している。テナントポリシー情報２１０は，ポリシー項目２１１，ポリシー内容２１２を含む。

ポリシー項目２１１には，テナントの優先度，最低必要量，期間定義，短期期間リソース提供方法，長期期間リソース提供方法，を含む。

テナント優先度は他のテナントと優先度比較ができる情報であればよく，例えば図５では当該テナントの優先度が高いことを示す「Ｈｉｇｈ」が格納されている。優先度は，Ｈｉｇｈ，ＬｏｗやＧｏｌｄ，Ｓｉｌｖｅｒ，Ｂｒｏｎｚｅ等の文字列の他に数値やアルファベットを使用してもよい。さらにテナント優先度情報は静的に定義する以外に，時間帯や曜日，日付といった情報を基に動的に変化してもよい。

最低必要量は当該テナントが最低限保持することを保証しなければならないリソース量を示しており，図４では仮想マシン４台を最低限保持することを示す「４ＶＭ」が格納されている。テナントを構成する仮想マシン台数で指定する他に，ＣＰＵ量やメモリ量等のリソース種別ごとに指定してもよい。

期間定義は，テナントがリソース確保要求を出す際に要求する期間を，当該テナントが短期、中期または長期と判断する基準値を示しており，時間や日数等の時間情報を指定する。図４では要求期間が２４時間未満であれば短期，２４時間以上で７日未満であれば中期、７日以上であれば長期と判断する情報が格納されている。

短期期間リソース提供方法、中期期間リソース提供方法および長期期間リソース提供方法は，期間定義で定義した基準に基づいてリソースの要求期間を判断した際，各期間でのリソース提供方法を定義する。図４では，短期期間のリソース確保を要求されている場合には仮想マシンのＣＰＵ割当量に制限を課すＣＰＵキャッピングを利用して，ＣＰＵリソース割当量を変更してリソースを提供する手段を選択し，中期期間のリソース確保を要求されている場合には不要な仮想マシンをシャットダウンしてリソース提供する手段を選択し、長期期間のリソース確保を要求されている場合には不要な仮想マシンを削除してリソースを提供する手段を選択することを示す情報が格納されている。

リソース確保要求期間の長短に応じてリソース提供方法を変えるのは、各テナントがリソースを他テナントへ提供可能かを判断する際に、リソース提供手段適用時の自テナントの安定性の観点、リソース提供手段の処理時間の観点、リソース提供手段実行時の負荷の観点を考慮する必要がある点ためである。安定性の観点では、ＣＰＵキャッピングによるリソース提供方法は、仮想マシンのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が認識しているＣＰＵ割当量よりも少ない量のＣＰＵのみ利用可能とするよう仮想化基盤側で制限する機能であるため、ＯＳの認識する構成と仮想化基盤で制限をかけた構成とでギャップが生じ、システムの挙動の安定性の点で長期間のＣＰＵキャッピング利用は控えたいニーズがある。そのため、中期または長期にリソースを他のテナントへ提供する際には、仮想マシンをシャットダウンまたは削除して仮想マシン単位にリソースの開放と提供を実施するほうが、リソース提供側のシステム安定性の点で優れる。

またリソース提供手段の処理時間の観点では、リソースを提供する際の処理時間と、リソース提供が終了した後に自テナントのリソース割当量を回復するための処理時間を考慮する必要がある。図４のリソース提供方法では、ＣＰＵキャッピングによるリソース提供および回復の処理時間が最も短いため、短期期間のリソース提供時にはＣＰＵキャッピングによるリソース提供を選択するよう定義している。またＶＭシャットダウンによるリソース提供方法では、リソース回復のためにはＶＭを再び起動するだけでよいのに対し、ＶＭ削除によるリソース提供方法では、リソース回復のためには新規にＶＭを作成する処理が必要となる。またＶＭシャットダウンではシャットダウン後に利用しないＶＭが環境に残るためＶＭ未稼働の間はリソース利用の観点で無駄が生じるが、ＶＭ削除によるリソース提供では削除したＶＭ分のリソースが開放されるためリソースの無駄が生じない。それら特性を考慮し、中期期間のリソース提供に対してはリソース回復処理も考慮してＶＭシャットダウンによるリソース提供方法を定義し、長期間のリソース提供に対しては未使用リソース削減を考慮してＶＭ削除によるリソース提供方法を定義している。

またリソース提供手段実行時の負荷の観点では、各手段を実行した際の自テナントまたは他テナントへ与える負荷影響を考慮する必要がある。図４のリソース提供方法では、ＣＰＵキャッピングによるリソース提供手段の負荷が最も小さく、次に負荷が小さいのはＶＭシャットダウン（および回復時のＶＭ起動処理）で、ＶＭ削除（および回復時のＶＭ新規作成処理）の負荷が最も大きい。そのため、各処理の発生頻度を考慮して、短期期間のリソース提供時にはＣＰＵキャッピングによるリソース提供手段を定義し、中期期間に対してはＶＭシャットダウン、長期期間に対してはＶＭ削除を定義している。

以上のように、リソース提供手段適用時の自テナントの安定性の観点、リソース提供手段の処理時間の観点、リソース提供手段実行時の負荷の観点から、リソースを提供する期間に応じて異なるリソース提供手段を定義することでテナント間のリソース調停をより効果的に実施できる。本実施例では期間で区分したため図４のような内容にしたが、ポリシー次第では、安定性や負荷を数値化し、これらをリソース提供方法の区分をする基準として用いてもよい。

図５は，テナント利用状況情報２２０を示している。テナント利用状況情報２２０は，テナントを構成する仮想マシン名２２１と，当該仮想マシンのＣＰＵ利用量２２２と，当該仮想マシンのメモリ利用量２２３と，当該仮想マシンのディスク利用量２２４と，当該仮想マシンのネットワーク利用量２２５を含む。

ＣＰＵ利用量２２２は仮想マシンに割り当てられているＣＰＵに対する利用量が分かる情報であればよく，図５ではＣＰＵ割当量に対する使用比率を格納しているが，使用中の仮想ＣＰＵ数や周波数といった情報を使用してもよい。

メモリ利用量２２３は仮想マシンに割り当てられているメモリに対する利用量が分かる情報であればよく，図５ではメモリ割当量に対する使用比率を格納しているが，使用中のメモリ量を使用してもよい。

ディスク利用量２２４は仮想マシンに割り当てられているディスクに対する利用量が分かる情報であればよく，図５ではディスクに対するＩＯＰＳ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）を格納しているが，ディスクの読み込み／書き込み性能値やディスクの読み込み／書込み量，ディスクの使用容量や空き容量といった情報を使用してもよい。

ネットワーク利用量２２５は仮想マシンのネットワーク利用量が分かる情報であればよく，図５では単位時間あたりに仮想マシンが送受信するデータ量を格納しているが，単位時間あたりに仮想マシンが送受信するパケット数や，特定時間内に仮想マシンが送受信する総データ量や総パケット数といった情報を使用してもよい。

図６は，リソース調停結果情報２３０を示している。リソース調停結果情報２３０は，リソース調停の結果，リソースを提供する先のテナント情報２３１と，リソースを提供する元のテナント情報２３２と，リソース提供量２３３と，リソースの提供手段２３４と，リソースの提供期間２３５を含む。

リソース提供量２３３は提供元テナント２３２が提供先テナント２３１へ提供するリソース量を示す情報であればよく，図６ではテナント「Ｔ２」がＣＰＵ２個相当のリソースをテナント「Ｔ１」へ提供し，テナント「Ｔ３」がＣＰＵ４個相当のリソースをテナント「Ｔ１」へ提供することを示す情報が格納されている。リソース提供量２３３に格納する情報は複数のリソース種別を含んでもよく，例えば「ＣＰＵ：２個，メモリ：１ＧＢ」のようにＣＰＵとメモリを提供することを示す情報を格納してもよい。

またリソースの単位をリソース種別ではなく仮想マシン単位で表現してもよく，例えばリソースを提供するために自テナントの仮想マシンを１台削除した場合、削除した仮想マシンを「仮想マシン：ＶＭ１ 削除」のように記録することで、提供したリソース量として特定の仮想マシンを示す情報を格納してもよい。

リソース提供手段２３４は提供元テナント２３２が提供先テナント２３１へリソース提供する手段を示す情報であればよく，図６ではテナント「Ｔ２」が「ＣＰＵキャッピングによる割当量変更」手段を使用して提供量２３３に示すリソース量をテナント「Ｔ１」へ提供し，テナント「Ｔ３」が「ＶＭ削除」手段を使用して提供量２３３に示すリソース量をテナント「Ｔ１」へ提供することを示す情報が格納されている。

提供期間２３５は提供元テナント２３２が提供量２３３のリソースを提供先テナント２３１へ提供する期間を示している。図６では，テナント「Ｔ２」は「２０１４／０６／３０ ０６：００：００まで」の期間でリソースをテナント「Ｔ１」へ提供し，テナント「Ｔ３」は提供期間の指定なしでリソースをテナント「Ｔ１」へ提供することを示す情報が格納されている。

図７は，マルチテナント環境でリソース確保要求を処理するフローチャートを示す図である。以下，フローに沿って説明する。

管理プログラムは，テナントからのリソース確保要求を受信する（ステップＳ１０１）。リソース確保要求には物理計算機，仮想計算機，プログラム，サービスに割り当て可能なリソースの種別と量，当該リソースの利用期間を示す情報を含み，例えば「ＣＰＵ：８コア，利用期間：６時間」といった内容を含む。

次に管理プログラムは，（ステップＳ１０１）で受信したリソース確保要求に基づき，リソースを提供するテナントの候補を算出する（ステップＳ１０２）。本処理の詳細は図８および図９を用いて説明する。

次に管理プログラムは，（ステップＳ１０２）で算出したテナント候補に対してリソース調停の実行を指示し，結果を受信する（ステップＳ１０３）。リソース調停の実行指示は物理マシン，仮想マシン，物理リソース，仮想リソース，論理分割されたリソース等を管理するソフトウェアに対してＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）やＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）等を介して送信してよく，またリソース調停の実行指示をメール等の手段により計算機環境を管理する管理者へ送信してもよい。

次に管理プログラムは、（ステップＳ１０３）で調停した結果を使用して管理計算機にリソース調停処理を実行させる（ステップＳ１０４）。管理プログラムが管理計算機にリソース調停処理を実行させる手段としては、管理計算機が外部へ公開しているＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）や）を介して実行指示を与えることができる他、管理計算機が提供するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）やＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）を管理プログラムまたは管理者が操作して実行指示を与えてもよい。管理プログラムがリソース調停指示を管理計算機に与えた後に、調停処理の結果を知るために一定周期で管理プログラムが調停処理の結果を管理計算機に問い合わせるが、その他の方法により調停処理の結果を確認してもよく、管理計算機が管理プログラムに対して調停結果を通知することで確認してもよい。

次に管理プログラムは，（ステップＳ１０４）で調停した結果をリソース確保要求送信元のテナントへ送信する（ステップＳ１０５）。調停結果は，確保完了したリソース種別と量，およびリソースを確保したサーバの識別情報を含む。例えば「Ｓｅｒｖｅｒ−１：ＣＰＵ：４コア確保，Ｓｅｒｖｅｒ−２：ＣＰＵ：４コア確保」といった内容を含む場合，サーバ名「Ｓｅｒｖｅｒ−１」からはＣＰＵ４コアを確保し，サーバ名「Ｓｅｒｖｅｒ−２」からはＣＰＵ４コアを確保したことを示す。

図８は，管理プログラム内のリソース提供候補算出モジュールが実行する（ステップＳ１０２）のリソース提供候補算出処理の詳細を示すフローチャートである。以下，フローに沿って説明する。

リソース提供候補算出モジュールは，テナント構成情報２００を参照してテナント一覧を取得し，各テナントに対して（ステップＳ２０２）乃至（ステップＳ２０４）の処理を実行する（ステップＳ２０１）。

次にリソース提供候補算出モジュールは，テナント構成情報２００，テナントポリシー情報２１０，およびテナント利用状況情報２２０を参照し，
当該テナントの現在のリソース割当量がテナントポリシーで定義される必要最低量より多いかを確認する（ステップＳ２０２）。図４の例では，「テナント１」の最低必要量が「４ＶＭ」（仮想マシン４台）であることを示している。さらに「テナント１」のテナント内仮想マシン構成情報（図３−ａ）を参照して、「テナント１」で現在稼動している仮想マシンの台数を取得し、必要最低量である仮想マシン４台を満足する台数が稼動しているかを（ステップＳ２０２）で確認する。

必要最低量以下の場合，他のテナントへ提供可能なリソースは無いと判断し，（ステップＳ２０１）の処理対象を次のテナントに変更する。必要最低量より多くのリソースが割り当てられている場合は（ステップＳ２０３）の処理へ進む。

次にリソース提供候補算出モジュールは，当該テナントが提供することのできるリソース量を算出する（ステップＳ２０３）。本処理の詳細は図１０を用いて説明する。
次にリソース提供候補算出モジュールは，（ステップＳ２０３）で算出した結果をリソース提供元テナント候補に登録する（ステップＳ２０４）。リソース提供元テナント候補は管理プログラムにより保持され、リソース提供元テナント候補には、リソース提供もとのテナント名、および提供可能なリソース情報が登録される。

次にリソース提供候補算出モジュールは，リソース提供元テナント候補を参照して各テナント候補に対し（ステップＳ２０６）乃至（ステップＳ２０８）の処理を実行する（ステップＳ２０５）。

次にリソース提供候補算出モジュールは，当該算出結果を提供可能リソース量として加算する（ステップＳ２０６）。

次にリソース提供候補算出モジュールは，当該算出結果を提供候補リストへ登録する（ステップＳ２０７）。

次にリソース提供候補算出モジュールは，（ステップＳ２０６）で加算した値が，リソース確保要求に含まれる要求量以上であるか確認する（ステップＳ２０８）。加算の合計値が要求量未満である場合，次の算出結果を取得して（ステップＳ２０６）の処理へ戻る。合計値が要求量以上である場合，（ステップＳ２０５）のループ処理を終了し，提供候補リストに登録した情報をリソース調停結果情報２３０へ格納する。

（ステップＳ２０５）でリソース提供元テナント候補からリソース提供元テナントを選択する方法は，テナントポリシー２１０を参照して最も優先度の低いテナントから順に選択してよく，他の選択方法としては，リソースを提供するサーバ台数を少なくするために，リソース確保要求に含まれるリソース要求量に最も近いリソース提供量を含むテナントから順に選択してもよい。またテナント利用状況情報２２０を参照してリソースの利用率が低いテナントを優先して選択してもよい。

図９は，管理プログラム内のリソース提供候補算出モジュールが実行する（ステップＳ２０３）の提供可能リソース量算出処理の詳細を示すフローチャートである。以下，フローに沿って説明する。

リソース提供候補算出モジュールは，リソース確保要求を参照して，リソースの要求期間を示す情報を取得する（ステップＳ３０１）。例えば、リソース確保要求が「ＣＰＵ：８コア，利用期間：６時間」といった内容を含む場合，確保要求期間は「利用期間：６時間」である。

次にリソース提供候補算出モジュールは，テナントポリシー情報２１０を参照し，（ステップＳ３０１）で取得した期間情報に応じたリソース提供方法を選択する（ステップＳ３０２）。図４の例では，確保要求期間として「利用期間：６時間」を取得した場合，テナントポリシー情報２１０より確保要求期間が２４時間未満であるため「短期」と判断し、リソース提供方法として「ＣＰＵキャッピングによる割当量の変更」を選択する。

次にリソース提供候補算出モジュールは，テナントポリシー情報２１０を参照し，（ステップＳ３０２）で選択したリソース提供方法を使用して確保可能なリソース量を算出する（ステップＳ３０３）。図４の例でリソース提供方法として「ＣＰＵキャッピングによる割当量の変更」を選択した場合、リソース提供方法に応じた確保可能リソース量の算出には，例えばテナント利用状況情報２２０の履歴情報を利用して定常時のＣＰＵリソースの利用傾向を算出することで，余剰に割り当てられているＣＰＵリソース量を，確保可能なリソース量として算出する方法が利用できる。

さらにリソース提供方法として複数の提供方法の組み合わせを利用してもよい。仮想マシンを削除するリソース提供方法を選択する場合，仮想マシン削除後にそのテナントに対して突発的に処理負荷が増加すると，テナントの処理性能を上げるために仮想マシンを新たに追加して元の構成に戻す必要が生じ得る。仮想マシンを追加するためには時間を要するため，その間にテナントは処理性能不足となり，テナントの利用者に対して満足なサービスを提供できない事態が生じ得る。そこで仮想マシンを削除する際には，テナント内に残る他の仮想マシンを予めＣＰＵキャッピングしておき，処理負荷の急増時にはＣＰＵキャッピングの設定を変更することで一時的に仮想マシンの処理性能を向上させ，そのバックエンドの処理で仮想マシンの新規追加処理を実行する方法が利用できる。例えば，６コアを割り当てられた仮想マシンに対して２コア分のＣＰＵキャッピングを設定して仮想的に４コアの仮想マシンとみなしている場合を考える。この仮想マシン３台で構成されるテナントに対して，仮想マシン１台削除を実施すると，２コア分の余力を持つ仮想マシンが２台残るため，負荷の急増時にこれら仮想マシンのＣＰＵキャッピング設定を変更して仮想マシンを６コア割当に再構成することで，削除した仮想マシン１台に相当する合計４コアの処理性能が追加される。６コア割当の仮想マシン２台で処理している間に，新規に４コア割当の仮想マシン（６コア割当に対して２コア分をキャッピングしてもよい）の追加処理を実行し，仮想マシンの追加が完了後に，ＣＰＵキャッピングの設定を変更した２台の仮想マシンに対して再度２コア分のＣＰＵキャッピングを設定して，４コア割当の仮想マシン３台で構成される元のテナント構成を復元することができる。

以上によって，リソースを必要とするテナントのリソース確保要求に対して，要求条件の一部である利用期間を考慮したリソース確保手段を実施してリソースを確保するため，テナント間のリソース調停を効率的に実施できる。

以下，本発明の実施例２について図１０乃至図１２を用いて説明する。

実施例１では、リソース確保要求期間を判断するための「期間定義」情報を管理者が予めテナントポリシー情報に定義する必要があるが、「期間定義」はテナントごとに異なることは十分に考えられることであるため、管理者がテナントの利用履歴情報や特性を考慮して全てのテナントに対する「期間定義」を予め定義することは作業負担が大きい。そこで、実施例２では各テナントに期間定義を設定する代わりに、調停するレベルを設定することでリソースの調停方法を自動的に選択してリソースの提供を行う。

図１０は、本実施例におけるテナントポリシー情報２１０を示す。テナントポリシー情報２１０に新たに「リソース調停レベル」項目を加え、また「期間定義」項目は未定義とする。ここで「リソース調停レベル」とは調停サーバがリソース提供方法を選択する際の指針となる情報であり、実施例２では５段階の値で表現し、「リソース調停レベル」の値が１に近ければ当該テナントのリソース提供方法を選択する際にテナントの安定性を重視して提供方法を選択するといったより保守的なリソース調停を実施し、値が５に近ければリソース提供方法の処理時間の短さや実行の容易さを重視して提供方法を選択するといったより積極的なリソース調停を実施する。

図１１は、管理プログラムが持つリソース調停レベル情報３００を示している。リソース調停レベル情報３００は、リソース調停レベル３０１とリソース確保要求期間３０２の２つの軸を持つ。図１０の例ではリソース調停レベルに「２」が設定されている。さらに図１１の例でテナントからのリソース確保要求に含まれるリソース確保要求期間が「中期」である場合には、リソース調停レベル３０１の値が「２」でありリソース確保要求期間３０２が「中期」である箇所を参照し、リソース提供方法に「長期用方法」を選択する。図１０の例で長期期間のリソース提供方法に「仮想マシンの削除」が定義されているため、この例では管理プログラムは「仮想マシンの削除」をリソース提供方法として選択する。

図１２は，実施例２で管理プログラム内のリソース提供候補算出モジュールが実行する（ステップＳ２０３）の提供可能リソース量算出処理の詳細を示すフローチャートである。以下，フローに沿って説明する。実施例２では，実施例１で説明したフローチャートのうち，（ステップＳ３０１）および（ステップＳ３０３）の処理ステップは同じであるため，差分となる（ステップＳ４０１）および（ステップＳ４０２）の処理ステップについて説明する。

リソース提供候補算出モジュールは，テナントポリシー情報２１０を参照し、リソース調停レベルを取得する（ステップＳ４０１）。図１０の例では、リソース調停レベルとして「２」を取得する。

次にリソース提供候補算出モジュールは、（ステップＳ３０１）で取得したリソース確保要求期間と、（ステップＳ４０１）で取得したリソース調停レベルと、リソース調停レベル情報３００と、テナントポリシー情報２１０と、を使用して、リソース提供方法を選択する（ステップＳ４０２）。

ここで（ステップＳ３０１）で取得したリソース確保要求期間を「短期」「中期」「長期」と判断する方法の一例について説明する。

リソース確保要求期間を「短期」と判断する方法として、「システムが正常な安定挙動を示す期間」にリソース確保要求期間が含まれる場合に「短期」と判断する方法が挙げられる。システムの「正常な安定挙動」には、ＣＰＵ利用率などのリソース利用率がシステム監視製品の規定する正常値以下に収まっている状態や、リソース利用率の値の推移がシステム監視製品の規定する正常状態に収まっている状態を利用できる。例えば、業務システムを２４時間枠で分析した場合に、業務システムの利用者が多く、リソース利用率の推移も大きい昼間は対象外とし、業務システムの利用者が少ない夜間の期間を「正常な安定挙動」と判断することが考えられる。

またリソース確保要求期間を「中期」と判断する方法として、「短期」「長期」の期間判断に一致しない、または「短期」「長期」の期間判断の間に含まれる期間を「中期」と判断する方法が挙げられる。別の方法として、システム監視製品が繁忙期と判断する時期の間を「中期」と判断する方法でもよく、例えばバッチ処理システムでは週末や月末にバッチ処理が集中する場合が多いため、１週間のうちの平日を「中期」と判断したり、月末日を除く期間を「中期」と判断したりすることができる。また「短期」の規定数倍を「中期」と判断する方法でもよい。

またリソース確保要求期間を「長期」と判断する方法として、リソース確保要求期間が始期のみで終期の指定が無い場合に「長期」と判断する方法が挙げられる。また「中期」の規定数倍を「長期」と判断する方法でもよい。

リソース提供候補算出モジュールはシステム監視製品にリソース確保要求期間の判断を問い合わせて結果を取得でき、あるいはリソース提供候補算出モジュールがシステム監視製品のリソース監視情報を取得して判断してもよい。

次にリソース提供候補算出モジュールは、（ステップＳ４０２）で選択したリソース提供方法に基づき、実施例１と同様に（ステップＳ３０３）で確保可能なリソース量を算出する。

以上によって，管理者は予め「短期」「中期」「長期」の定義をテナントポリシー情報に定義することなく、リソース調停レベルのみをテナントポリシー情報へ定義するだけで、リソース確保要求期間に基づいて調停サーバが自動的にリソース提供方法を選択してリソース確保を実施するため，管理者の作業負担を軽減することができる。

以下，本発明の実施例３について図１３を用いて説明する。

実施例３では，リソース要求処理モジュール１０１がテナント３から受信するリソース確保要求に，実施例１のリソース確保要求の内容に加え，当該リソースの利用形態を示す情報をさらに含む。

リソースの利用形態としては，例えば，信頼性を確保するためのＨＡ（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ）構成が挙げられる。ＨＡ構成では，２台以上のサーバを利用し，１台を現用系，他を待機系として設定することで，現用系のサーバに障害が発生した場合に素早く待機系のサーバを切り替え可能とする。そのため，仮想マシンでＨＡ構成を構築する場合は，現用系と待機系の仮想マシンは異なる物理マシン上に設置する必要があり，リソース確保要求でＨＡ構成を利用形態に指定されている場合にはリソースを複数の物理マシンから調達しなければならない。ＨＡ構成をリソース確保要求のリソース利用形態に含む場合，例えば「ＨＡ構成のためにＣＰＵ４コア，メモリ４ＧＢの仮想マシン２台分」といった記載が挙げられる。

図１３は，実施例３において，管理プログラム内のリソース提供候補算出モジュールが実行する（ステップＳ２０３）の提供可能リソース量算出処理の詳細を示すフローチャートである。実施例３では，実施例１で説明したフローチャートのうち，（ステップＳ２０１）乃至（ステップＳ２０４）の処理ステップは同じであるため，差分となる（ステップＳ５０１）乃至（ステップＳ５０４）の処理ステップについて説明する。以下，フローに沿って説明する。

リソース提供候補算出モジュールは，リソース確保要求を参照し，（ステップＳ２０３）で算出した提供可能リソース量がリソース利用形態を満足するために必要な量以上であるかを確認する（ステップＳ５０１）。例えば，リソース確保要求に「ＨＡ構成のためにＣＰＵ４コア，メモリ４ＧＢの仮想マシン２台分」というリソース利用形態情報が含まれる場合，ＨＡ利用形態を満足するためには仮想マシン１台分のリソースを提供可能なテナントが２つ以上存在する必要がある。そのため，リソース提供の候補となり得るテナントは最低でも仮想マシン１台に要求される分のリソースを提供可能なテナントである必要があるため，「ＨＡ構成のためにＣＰＵ４コア，メモリ４ＧＢの仮想マシン２台分」というリソース確保要求に対してリソース利用形態を満足するために必要なリソース量を、仮想マシン1台に対する「ＣＰＵ４コア，メモリ４ＧＢ」のリソースと判断でき，（ステップＳ２０３）で算出した提供可能リソース量が上記を満たす場合は算出結果リストへ登録する（ステップＳ２０４）。（ステップＳ２０３）で算出した提供可能リソース量が上記を満たさない場合は算出結果リストへの登録は行わないで次のテナントに処理を移す。

次にリソース提供候補算出モジュールは，算出結果リストを参照し，利用形態を満足するリソース確保ができたかを確認する（ステップＳ５０２）。具体的には、「ＣＰＵ４コア，メモリ４ＧＢ」のリソースがテナント２つ以上から確保できたか否かで判断する。リソース確保できている場合はＳ３０４の処理へ進む。リソース確保できていない場合，（ステップＳ５０３）の処理へ進む。

次にリソース提供候補算出モジュールは，テナント構成情報２００を参照し，テナント構成を再構成することでリソース確保要求を満足するリソースを確保可能か算出する（ステップＳ５０３）。算出には例えば，仮想マシンを現在の物理マシンから別の物理マシンへ移動させることで物理マシン上のリソースを確保できるか否かを，物理マシンと仮想マシンの組み合わせの組を基に算出する手法がある。例として、２台の物理サーバＡと物理サーバＢが存在する場合、どちらかの物理サーバ上のみで仮想マシン２台分のリソースを確保しても、ＨＡ構成の要件を満たすことができない。そこで、例えば物理サーバＢ上の仮想マシン１台以上を物理サーバＡまたは他の物理サーバ上へ移行させることで、物理サーバＢ上に仮想マシン１台分のリソース確保ができるかを確認し、もし可能であれば物理サーバＡと物理サーバＢ上に仮想マシンをそれぞれ１台ずつ作成してＨＡ構成の要件を満たせると判断できる。

最後にリソース提供候補算出モジュールは，提供可能リソース情報を提供候補リストへ登録する（ステップＳ５０４）。

リソースの利用形態は実施例３で説明したＨＡ構成に限られず、他の利用形態としては正サイトと副サイトで構成されるＤＲ（Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ）構成を構成する際に、正サイトと副サイトでリソース確保を調停するために利用できる。また別の利用形態としては、複数の仮想サーバを利用してロードバランサによる負荷分散構成を構成する際に、できる限り負荷分散の効果を高めるためにロードバランサ配下の複数の仮想サーバを別々の物理サーバ上で稼動するようにリソース確保を調停するために利用できる。

以上によって，リソースを必要とするテナントのリソース確保要求に対して，要求条件の一部である機能形態を考慮したリソース確保手段を実施してリソースを確保するため，テナント間のリソース調停を効率的に実施できる。

なお、以上の実施例では調停サーバが調停に関する処理を行う形で示したが、管理計算機が調停サーバの処理を兼ねても良い。

１・・・管理計算機 ２・・・ネットワーク ３・・・テナント ４・・・管理計算機 １０００・・・管理プログラム

Claims (6)

1. マルチテナント環境を構成する計算機システムに接続する調停サーバであって、
   前記マルチテナント環境に含まれる複数のテナントの構成を示す構成情報、
   前記複数のテナントの利用状況を示す利用状況情報及び
   リソース利用期間に対応するリソース提供方法の情報を含むポリシー情報を有し、
   前記複数のテナントの中のリソースを要求するテナントから、リソース割当要求量及び前記リソース利用期間の情報を含むリソース割当要求を受け付け、
   前記構成情報、前記利用状況情報、前記ポリシー情報及び前記リソース割当要求を参照して、前記複数のテナントの中のリソースを提供するテナント、該テナントから提供されるリソース量及び該テナントからリソースを提供される方法を含む調停情報を作成し、
   前記調停情報に基づいて前記リソースを提供するテナントにリソース調停を指示する
   ことを特徴とする調停サーバ。
2. 請求項１記載の調停サーバであって、
   前記リソース提供方法は、前記リソースを提供するテナントの利用する仮想計算機を削除する方法、前記仮想計算機をシャットダウンする方法及び前記仮想計算機に割り当てられているCPUの量をキャッピングにより減らす方法を含む
   ことを特徴とする調停サーバ。
3. 請求項２記載の調停サーバであって、
   前記リソース提供方法は、前記リソース利用期間が短期だった場合はCPUの量をキャッピングにより減らす方法であり、前記リソース利用期間が中期だった場合は前記仮想計算機をシャットダウンする方法であり、前記リソース利用期間が長期だった場合は前記仮想計算機を削除する方法である
   ことを特徴とする調停サーバ。
4. マルチテナント環境を構成し、調停サーバを含む計算機システムにおいて、
   前記マルチテナント環境に含まれる複数のテナントの中のリソースを要求するテナントから前記調停サーバに対して、リソース割当要求量及びリソース利用期間の情報を含むリソース割当要求を送受信するステップ、
   前記複数のテナントの構成を示す構成情報、前記複数のテナントの利用状況を示す利用状況情報、前記リソース利用期間に対応するリソース提供方法の情報を含むポリシー情報及び前記リソース割当要求を参照し、前記複数のテナントの中のリソースを提供するテナント、該テナントから提供されるリソース量及び該テナントからリソースを提供される方法を含む調停情報を作成するステップ、及び
   前記調停情報に基づいて前記リソースを提供するテナントにリソース調停を指示するステップを含む
   ことを特徴とするリソース調停方法。
5. 請求項４記載のリソース調停方法であって、
   前記リソース提供方法は、前記リソースを提供するテナントの利用する仮想計算機を削除する方法、前記仮想計算機をシャットダウンする方法及び前記仮想計算機に割り当てられているCPUの量をキャッピングにより減らす方法を含む
   ことを特徴とするリソース調停方法。
6. 請求項５記載のリソース調停方法であって、
   前記リソース提供方法は、前記リソース利用期間が短期だった場合はCPUの量をキャッピングにより減らす方法であり、前記リソース利用期間が中期だった場合は前記仮想計算機をシャットダウンする方法であり、前記リソース利用期間が長期だった場合は前記仮想計算機を削除する方法である
   ことを特徴とするリソース調停方法。

Images