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

Abstract

統合リソース管理部２０２は、リソース３１１ａ、３１１ｂ、３１１ｃの一部を管理し仮想リソースとして提供する複数のコンテナ３１０を、アプリケーションプログラム毎に予め用意している。統合リソース管理部は、使用するリソースを区分けするために予め設定されるテナント３００ａ、３００ｂのうちいずれかのテナントに関して発行される所定の要求に応じて、複数のコンテナの中から選択するコンテナを要求元のテナントに提供する。統合リソース管理部が要求元のテナントに提供するコンテナには、リソースのうち、所定の要求で指定されたアプリケーションプログラムに予め割り当てられているリソースを指定された使用量よりも少なく設定する場合がある。

Description

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

近年、データセンタ全体のリソース利用効率を高めるべく、サーバを仮想化する技術を用いて、複数の業務システムを物理計算機リソース上に集約する情報処理システム基盤が普及している。

リソース上で固定的に稼働していたシステムを仮想化技術によりリソースから分離し、業務アプリケーションの稼働状況に応じて、システムを複数の物理計算機リソース間で移行させる。これにより、負荷の不均衡を動的に平準化できる。

一方、仮想マシンの物理配置に合わせてネットワーク構成を制御することで、特定のユーザグループが使用するシステム群をテナントと呼ばれるリソース空間に隔離できる。これにより、テナントのセキュリティを確保することができる。

例えば特許文献１では、複数のテナントが複数の物理計算機リソースを使用する仮想計算機システムにおいて、グループ間の負荷の不均衡を迅速に解消する技術を開示する。特許文献１では、複数の仮想計算機を複数のリソースグループ上で管理し、負荷に応じて複数の仮想計算機を物理計算機リソース間で移行させることで、負荷を分散する。

米国特許出願公開第２０１２/０２５４４４５号明細書

しかしながら、従来技術では、物理計算機リソースと仮想計算機とを直接的に対応付けて管理するため、柔軟性に乏しく、時々刻々と変化する環境への適応能力についてまだ改善の余地がある。

また、従来技術は、仮想サーバの性能負荷を画一的に評価するものであり、仮想サーバ上に設けられているアプリケーションの性能特性を考慮していない。一般に業務アプリケーションには、リソースに対する要件が存在するが、アプリケーションの種類や構成規模などにより、それらリソース要件は一定ではない。

特にＩａａＳ（Infrastructure as a Service）クラウドと呼ばれ、セルフサービス方式の利用形態をとる計算機システムにおいては、どの仮想サーバにどのアプリケーションを構築するか、という決定権は仮想サーバのユーザに委ねられている。しかし、ユーザの需要傾向や業務サービスの需要傾向を事前に予測するのは困難である。したがって、そのような計算機システムでは、一つのシステム環境に異なる種類のアプリケーションが混在することになる。

混在するアプリケーションの比率によって、利用率の低いリソースが生じる。例えば、ＣＰＵ（Central Processing Unit）性能に対する要求が高くストレージ性能に対する要求が低いアプリケーションと、メモリ性能に対する要求が高くストレージ性能に対する要求が低いアプリケーションとが混在する場合、ストレージリソースの性能に余剰が生じてしまう。

このような非効率なリソース利用を避けるために、テナント内に、アプリケーションの性能特性に応じてサイジングした、専用のリソース領域を定める方法が考えられる。例えば、テナント内に、アプリケーションＡ向けのリソース領域と、アプリケーションＢ向けのリソース領域とを用意する。ユーザは、所望のアプリケーションに応じて、それら専用のリソース領域のリソースを利用して仮想サーバを生成する。この方法によれば、専用のリソース領域それぞれでは効率的に運用できるものの、リソース全体における利用率の向上は望めない。

本発明は、上記の問題に鑑みてなされたもので、その目的は、状況変化に対応して、リソースの利用効率を高めることができるリソース管理システムおよびリソース管理方法を提供することにある。

本発明の一つの観点に係るリソース管理システムは、リソースを提供する複数の物理計算機と、少なくとも一つのアプリケーションプログラムを実行する複数の仮想計算機と、複数の物理計算機および複数の仮想計算機に通信可能に接続される統合リソース管理部とを有し、統合リソース管理部は、対応づけられるリソースの一部を管理し仮想リソースとして提供する複数のコンテナを予め用意し、提供される仮想リソースの利用範囲を定義するリソース区画を管理し、コンテナはアプリケーションプログラムの何れかに対応づけられており、リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられるコンテナに他のコンテナで管理されるリソースを移行し、他のコンテナの管理するリソース量は他のコンテナの提供する仮想リソースより少なくなることがある。

本発明によれば、コンテナはアプリケーションプログラムの何れかに対応づけられており、リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられるコンテナに他のコンテナで管理されるリソースを移行する。したがって、本発明によれば、状況変化に応じてリソースを移行させることができ、リソースの利用効率を高めることができる。

リソースを管理する計算機システムの構成図。 比較例としてのリソース管理方法の概要を示す説明図。 本実施例によるリソース管理方法の概要を示す説明図。 管理コンピュータに設けられる管理プログラムなどを示す説明図。 インスタンスを管理するテーブルの構成図。 テナントを管理するテーブルの構成図。 コンテナを管理するテーブルの構成図。 異なるアプリケーション間で性能を統一的に評価する概念を示す説明図。 アプリケーションの要求するリソース要件を定義するテーブルの例。 コンテナの性能を統一的に評価するテーブルの構成図。 テナントからの要求に応じてコンテナの構成を変更する処理を示すフローチャート。 アクセス権限を移行する処理を示すフローチャート。

以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。本実施形態で開示される複数の特徴は、様々に組み合わせることができる。本実施形態の処理動作の説明では、「コンピュータプログラム」を動作主体（主語）として説明することがある。コンピュータプログラムは、マイクロプロセッサによって実行される。したがって、プロセッサを動作主体として読み替えても良い。

本実施形態では、複数のアプリケーションが混在して稼働するクラウド環境において、テナントごとに定められたリソース領域、あるいはアプリケーションごとに定められたリソース領域を越えて、計算機システムの需要変化に応じてリソースを動的に融通しあうことにより、データセンタ全体のリソース利用効率を向上させる。

本実施形態では、複数のアプリケーションが要求する性能特性（リソース要件）を、それぞれのアプリケーションを管理するためのアプリケーション管理部より取得する。本実施形態では、各アプリケーションの要求する性能特性を考慮して、リソース全体におけるリソース需要を統一的な観点で算出する。

さらに、本実施形態では、アプリケーションの要求する性能特性を考慮したリソース需要に基づいて、リソース全体の配置を計画する。本実施形態では、アプリケーション専用のリソース領域を越えて、リソースプールを再構成する。

本実施形態によれば、テナント毎のリソース管理体系やアプリケーション管理体系に矛盾することなく、時々刻々と需要が変化するデータセンタにおいて、リソース全体の利用率を最適化することができる。また、本実施形態によれば、テナントごとのセキュリティを確保しつつ、従来の運用で培ったアプリケーション管理のノウハウを引き続き活用することができる。

図１〜図１２を用いて第１実施例を説明する。本実施例では、アプリケーションの要求するリソース要件を満足するように各インスタンスを構成し、かつリソース全体の利用率を高める。

＜システム構成＞

図１は、本実施例における計算機システムの構成を示す。計算機システムは、例えば、情報処理サービスを稼働させるホスト１０およびホスト２０と、サービスを要求するユーザが使用するクライアントコンピュータ７０と、計算機システムを管理する管理コンピュータ２００とを含んで構成することができる。

ホスト１０は、例えば、物理的なＣＰＵ、メモリ（主記憶装置）、入出力装置、ネットワークインタフェース、およびそれらを相互に接続する内部バスなどを備える一般的なコンピュータアーキテクチャによって構成されている。

ホスト１０上には、物理的な処理リソースを直接的に制御するＯＳ（Operating System）１３が稼働している。アプリケーション管理者またはユーザは、ホスト１０上のＯＳ１３をゲストＯＳ１３として利用することで、直接的にホスト１０の論理構成を制御することができる。

ゲストＯＳ１３がホスト１０の全ての物理的な処理リソースの構成を制御できるため、本実施例では、ホスト１０をベアメタルホスト１０と呼ぶ。本実施例では、ゲストＯＳ１３により制御される論理的なサーバ構成を、インスタンス１１と呼ぶ。インスタンス１１において、一つ以上のアプリケーション１２を稼働させることで、ユーザは所望の情報処理サービスを享受できる。なお、図中では、アプリケーションを「Ａｐｐ」と略記する場合がある。

ホスト２０も、ホスト１０と同様の構成を有するが、ハイパバイザ２４、または仮想マシンモニタなどと呼ばれる仮想化ソフトウェアを備える。仮想化ソフトウェアにより、物理リソースは論理的に一つ以上のゲストＯＳ領域に分割されて、アプリケーション管理者またはユーザに提供される。これらゲストＯＳ領域を一般に仮想マシン２１または論理パーティションと呼び、ホスト２０を仮想マシンホスト２０と呼ぶ。

これらゲストＯＳ領域は、仮想化ソフトウェアの方式により、例えばタイムスケジューリングによりＣＰＵコアなどの物理コンポーネントを共有する仮想マシンであっても良いし、あるいは、固定的に物理コンポーネントを対応付けておく論理パーティションであっても良い。ここでは簡単のため、特にこれらを区別せず単に仮想マシンと呼ぶ。仮想マシン内ではゲストＯＳ２３が稼働しており、さらにユーザが利用するためのアプリケーション２２が稼働している。仮想マシンは一つの論理的なサーバ構成に相当する。ベアメタルホスト１０と同様に、仮想マシンをインスタンス２１と呼ぶことにする。本実施例にかかる計算機システムは、同様の構成を持つ物理サーバおよびストレージを、ベアメタルホスト１０および仮想マシンホスト２０の二通りに利用する。ただし、以降の説明において特に断らない限り、ベアメタルホスト１０上のインスタンス１１および仮想マシンホスト２０上のインスタンス２１を区別せず、単にインスタンス１１と記載する。

一般にクラウドと呼ばれるような、ユーザの作成要求に応じて動的にインスタンスを作成するシステムでは、仮想マシンを利用する場合が多い。仮想マシンを利用すると、インスタンス構成をホストの物理リソース構成から分離することができる。これにより、アプリケーションを稼働させるサーバ構成を柔軟かつ即座に生成することができ、かつ生成後の構成変更も容易である。

一方、仮想マシンは、仮想マシンホスト２０が有する物理リソースを共有しているため、同一の仮想マシンホスト２０に設けられている他の仮想マシンから性能上の影響を受けざるを得ない。このような環境は、例えば安定したディスクＩ／Ｏ（Input/Output）性能を必要とするデータベースなど、要求性能の厳しいアプリケーションには適さない。

そこで、本実施例では、物理リソースと一対一に対応するベアメタルホスト１０を用意している。本実施例では、ベアメタルホスト１０を活用することで、安定した性能を有するサーバ環境を提供する。さらに、本実施例では、仮想マシンホスト２０とベアメタルホスト１０との両方を利用できる環境を提供することで、アプリケーションの性能要件やライフサイクルに適したリソース割り当てを実現することができる。

ストレージ装置１００は、各インスタンス１１、２１にストレージ資源を提供する機能を有する。ストレージ装置１００は、データ入出力処理に特化したコンピュータシステムであり、ＣＰＵやメモリなどを備える。ストレージ装置１００のＣＰＵは、ストレージ資源の構成を制御するための制御プログラムを稼働させる。この制御プログラムにより、例えばＨＤＤ（ハードディスクドライブ）といった物理的な記憶媒体が、ボリューム１０１と呼ばれる論理的な領域ごとに提供される。記憶媒体としては、ＨＤＤに限らず、例えば、フラッシュメモリデバイス、ＭＲＡＭ（Magnetoresistive Random Access Memory）、相変化メモリ（Phase-Change Memory）、ＲｅＲＡＭ（Resistive random-access memory）、ＦｅＲＡＭ（Ferroelectric Random Access Memory）等を用いてもよい。

ベアメタルホスト１０の場合、ＯＳ１３によりボリューム１０１がストレージ資源（論理デバイス）として認識される。ボリューム１０１に対して、ＯＳ１３およびアプリケーション１２が必要とするデータの読み書きが行われる。

仮想マシンホスト２０では、ハイパバイザ２４がボリューム１０１をさらに仮想ディスク１０２と呼ばれる領域に分割する。仮想ディスクは、多くの場合、ファイルシステム上のファイルである。仮想マシン２１上のＯＳ２３には、仮想ディスク１０２内のデータ領域が仮想的なボリューム１０３として認識される。

ホスト１０、２０とストレージ装置１００とは、ＳＡＮ（Storage Area Network）により接続されている。ＳＡＮの実現例として、ＦＣ＿ＳＡＮがある。ＦＣ＿ＳＡＮは、一つまたは複数のファイバチャネルスイッチ（ＦＣ ＳＷ）５０、ファイバチャネルケーブル５１、各データ入出力装置を接続するＨＢＡ（ホストバスアダプタ）５２を含んで構成される。

ＳＡＮの実装例はファイバチャネルに限らず、大容量データ通信という同じ目的を達成できるものであれば、例えばｉＳＣＳＩ（Internet Small Computer System Interface）やＦＣｏＥ（Fibre Channel over Ethernet（登録商標））、Ｉｎｆｉｎｉ−ｂａｎｄといった他の種類のデバイスおよびプロトコルでもよい。

サービスを提供するホスト１０、２０、サービスを要求するクライアントコンピュータ７０、計算機システムを管理する管理コンピュータ２００は、通信ネットワークを介して相互に接続される。通信ネットワークは、イーサネット（登録商標）スイッチ６０やケーブルにより物理的に結線されており、例えばＴＣＰ／ＩＰといったプロトコルを利用してアプリケーションデータや制御情報を双方向通信する。

本実施例では、それら通信ネットワークを、サービスネットワーク３００と、管理ネットワーク３０１、３０２とに大別する。サービスネットワーク３００には、サービスクライアント７１がアプリケーション１２、２２と通信するトラフィックが主に流れる。サービスネットワーク３００は、情報処理サービスに必要なデータを送受信する。

一方、管理ネットワークでは、管理クライアント７２や各管理サーバ２０１、２０３、２０４、２９５が各装置１０、２０、５０、１００内の制御コンポーネントと通信するトラフィックが主に流れる。管理ネットワークは、各情報処理装置１０、２０、５０、１００の構成を管理する制御データを送受信する。

これらの通信ネットワークは、物理的に分離されても良いし、レイヤ３スイッチの設定やレイヤ２スイッチの設定（ＶＬＡＮ、仮想ローカルエリアネットワーク）などの論理的なネットワーク分割によって構成されてもよい。さらに、管理ネットワーク３０２上には、主にアプリケーション管理サーバ２０１と各ホスト１０、２０との間の通信を制御するための、ファイヤウォール３０３を有する。

ファイヤウォール３０３は、ネットワーク管理部２０４からの要求に応じ、例えば特定のアプリケーション管理サーバ２０１から特定のホストへの接続を許可したり、あるいは遮断したりする機能を有する。ファイアウォール３０３は、ＩＰアドレスやホスト名などを用いて、通信の接続または遮断を実行する。

クライアントコンピュータ７０は、物理的には各ホスト１０、２０と同様に、ＣＰＵやメモリ、不揮発性記憶デバイスといった一般的なコンピュータアーキテクチャに基づき構成されている。クライアントコンピュータ７０は、サービスクライアント７１と、管理クライアント７２を有する。サービスクライアント７１は、ホスト１０、２０上のアプリケーション１２、２２から情報処理サービスの提供を受けるソフトウェアである。管理クライアント７２は、管理コンピュータ２００に接続して、計算機システムの構成を管理するソフトウェアである。

クライアントコンピュータ７０上の各ソフトウェア７１、７２は、必ずしも専用プログラムである必要はなく、同じ目的を達成する機能を有していれば、例えばＷｅｂブラウザのような汎用的なプログラムであってもよい。サービスクライアント７１は、アプリケーションごとに用意してもよいし、複数のアプリケーションを一つのサービスクライアント７１で管理できる構成でもよい。同様に、管理クライアント７２も管理対象の装置ごとに用意してもよいし、複数の対象装置を管理できる構成でもよい。

管理コンピュータ２００は、クライアントコンピュータ７０から送信されるユーザ要求に応じて、計算機システムの構成を変更する。管理コンピュータ２００は、他の計算機と同様に一般的なコンピュータアーキテクチャを有し、各機能を実現するために必要な管理プログラムを内部に稼動させる。

本実施例における管理プログラムとは、例えば、アプリケーション管理サーバ２０１、統合リソース管理部２０２、サーバ管理部２０３、ネットワーク管理部２０４、ストレージ管理部２０５である。それぞれの管理プログラムは、機能ごとに細分化されてもよいし、複数プログラムが一つにまとめて構成されてもよい。複数の管理コンピュータ２００が連携することで、これら管理プログラムを動作させる構成でもよい。管理プログラムの少なくとも一部は、管理対象の一部に分散して配置されてもよい。配置先としては、例えば、ホスト１０やＦＣ ＳＷ５０上の、エージェントプログラムなどがある。

実際には、管理者がこれら管理プログラムを使用している。各管理者が管轄する装置の範囲や職責により、複数の管理プログラムを用意したり、アカウント認証により管理プログラムの各機能に対するアクセス制御を設けたりする。

アプリケーション管理サーバ２０１は、インスタンス１１、２１上のアプリケーション１２、２２を管理する機能を提供する。一般に、アプリケーション１２、２１は、アプリケーション自身が処理するのに適した独自のデータ構造、機能、処理フローを持つ。したがって、アプリケーション１２、２２を管理するためには、専用のアプリケーション管理サーバ２０１が必要となる場合がある。

広く普及しているアプリケーションであれば、そのアプリケーションを管理するアプリケーション管理者は、独自の管理方法や、アプリケーション管理サーバの操作に習熟している。そこで、アプリケーション管理とリソース構成管理とを連携させることで、アプリケーション管理者はノウハウを活かせる、という大きな利便性が得られる。

性能要件の要求などのようにリソース構成に対する要求が発生するアプリケーションについては、アプリケーション管理サーバが、一部のリソース構成を管理する機能を有してもよい。したがって、本実施例では、アプリケーション管理サーバ２０１と統合リソース管理部２０２とは、互いに制御情報を送受信して、管理対象の構成を変更できる構成としている。アプリケーション管理サーバ２０１と統合リソース管理部２０２の連携を実現するために、例えばアプリケーション管理サーバ２０１にプラグインを設けたり、統合リソース管理部２０２にＡＰＩ（Application Programmable Interface）を設けたりする。

アプリケーション管理サーバ２０１は、特定の物理装置を管理対象に指定し、その特定の物理装置の構成を変更する権限を他のアプリケーション管理サーバとは排他的に有することもできる。

物理ホスト上に展開されているという点で、ハイパバイザ２４も一つのアプリケーションであると考えることができる。したがって、ハイパバイザ２４を管理するためのハイパバイザ管理サーバを設ける構成としてもよい。

管理コンピュータ２００が管理する各装置１０、２０、５０、６０、１００のリソース構成は、統合リソース管理部２０２および各装置管理部により管理される。各装置管理部とは、サーバ管理部２０３、ネットワーク管理部２０４、ストレージ管理部２０５のことである。各装置管理部は、管理ネットワーク３０２を経由して、ホスト１０、２０などの物理サーバ装置と、ＦＣ ＳＷ５０やイーサＳＷ６０などのネットワークスイッチと、ストレージ装置１００との、構成を管理する。

より具体的に言えば、各装置管理部は、それぞれの管理対象となる装置上で稼動する論理的なリソースの構成を変更したり、そのリソースの稼働情報を取得したり蓄積したり、あるいは各属性値を設定したりする機能を有する。

各装置管理部は、装置を開発または製造するベンダから提供される専用の管理プログラムであってもよい。各装置管理部と統合リソース管理部２０２とは、例えばＡＰＩなどの管理インタフェースを利用して制御情報を送受信する。

統合リソース管理部２０２は、管理クライアント７２の要求に応じて、各装置管理部を制御する。統合リソース管理部２０２は、各装置管理部を通じて、インスタンスを作成したり、構成変更に必要となる装置構成を変更したりする。統合リソース管理部２０２の具体的な構成については、後述する。

＜テナントにおけるリソースの管理方法＞

サーバ仮想化技術やストレージ仮想化技術が発展した結果、多数の情報処理システムが、一か所のハードウェアに集約されるようになった。これに伴い、従来は、例えば部署ごとにハードウェアを個別に所有するという運用形態であったが、近年では、複数の部署で同じハードウェアを共有する運用形態に変わりつつある。

しかし、部署ごとにシステム環境を分けたいという要求は根強いため、リソースを論理的に区分けするための「テナント」と呼ばれる論理構成が設けられている。テナントは「リソース区画」の一例である。テナントには、例えば、そのテナントに属するユーザやユーザグループ、そのテナントを管理する管理者権限の定義、そのテナントで使用可能なリソースなどの、各構成情報が関連付けられている。リソース区画であるテナントを導入することにより、複数のユーザグループ間でセキュリティおよび処理性能上の独立性を保ちながら、ハードウェアや物理的なデータセンタを共有することができ、リソース全体の利用率を高めることができる。テナントは、例えば、リソースを共用するユーザをグループ化したものである。

各管理プログラムは、複数存在してよいことは前述した。特に複数のテナントを提供する環境では、テナントごとにアプリケーション管理サーバ２０１を用意する。アプリケーション管理サーバ２０１が管理する情報処理システムが、多くの顧客データや業務データなどの機密情報を保持しているためである。

企業セキュリティの観点からは、これらの機密情報を複数のテナントで共有することは許されない。その一方、アプリケーションの中には、扱うデータの意味により、処理方法や管理方法、リソース構成を変えるものが多く存在する。したがって、アプリケーション管理サーバ２０１をテナントごとに独立させて構築したほうが扱い易い。アプリケーション管理サーバ２０１は、アプリケーション管理サーバ２０１自身の管理する物理リソースを特定し、他の種類のアプリケーション管理サーバとは排他的に、それらの物理リソースを利用することができる。

ところで、テナントが有する構成管理情報の中の一つに、リソース量が挙げられる。各ユーザに課される利用料は、ユーザの使用するリソース量に基づいて計算される従量課金である。

仮想化技術により、計算機システムの保持する物理リソース量は、必ずしもユーザが契約可能な量（仮想リソース量）とは一致しない。各ユーザの契約可能なリソース量の合計値は、実際の物理リソース量よりも多くできる。

しかし、ユーザのリソース需要と全くの無関係に、物理リソースの購入頻度や購入台数を決定することはできない。さらには、ユーザが属するグループや使用するアプリケーションによって、需要傾向はまちまちであり、それらを無視してリソースの供給量を予測することは不可能である。

したがって、最も簡潔で一般的なやり方は、契約するユーザのグループ、すなわちテナントごとに使用する物理リソースをある程度、決めておくやり方である。ただし、仮想化技術を用いることで、複数のテナントが一つの物理リソース（装置）を共有する構成を許容して、リソースの利用率を高める。このような、あるテナントの利用可能なリソースの範囲を、リソースプールと呼ぶことにする。

図２に示す比較例を参照し、リソースプールを用いてテナントにおけるリソースを管理する例を説明する。

ユーザ３０１は、所望のアプリケーションを利用するために、インスタンス１１（または２１）を作成する。インスタンスを稼働させるために必要な物理リソースは、事前にリソースプール３０３で管理されている。

リソースプール３０３は、装置管理者が管理コンピュータ２００上の各装置管理部を利用して設定される。装置管理者とは、例えばサーバ管理者３０５ａ、ネットワーク管理者３０５ｂ、ストレージ管理者３０５ｃである。各装置管理部とは、例えばサーバ管理部２０３、ネットワーク管理部２０４、ストレージ管理部２０５である。

リソースプール３０３には、ホスト１０（または２０）や、隔離ネットワーク３０４、ボリューム１０１など、インスタンスを構成するために必要なリソースの組み合わせが各装置管理部により予め登録されている。

ユーザ３０１によるインスタンスの作成やリソース構成変更といった各種管理操作は、管理クライアント７２との交信により行われ、ユーザ３０１のセルフサービスにより完結する。ユーザ３０１は、導入予定のアプリケーションの要求する要件をアプリケーション管理サーバ２０１ａ、２０１ｂに事前に問合せ、各種管理操作の際に要件を指定してもよい。

管理クライアント７２は、少なくともインスタンスの構成管理に関わる操作について、各構成管理コンポーネントに要求する機能を有する。アプリケーション管理サーバ２０１ａ、２０１ｂは、リソースプール３０３に登録されているリソースの中から、それぞれのアプリケーションに専用の領域として管理するものを事前に設定しておく。これにより、アプリケーション管理サーバ２０１ａ、２０１ｂは、物理リソースの詳細な構成や稼働情報を蓄積し、より効率的にアプリケーションを管理できる。以下、特に区別しない場合、アプリケーション管理サーバ２０１ａ、２０１ｂをアプリケーション管理サーバ２０１と呼ぶ。

テナント３００内にインスタンス１１（あるいは２１）が用意されると、ユーザ３０１は、所望のインスタンスをアプリケーション管理サーバ２０１に連絡し、所望のインスタンスの内部に所望のアプリケーションを構築する。

必要であれば、インスタンスを作成する際や、アプリケーションを構築する際に、ユーザ３０１は、アプリケーション管理者３０６と連携してリソース構成の詳細を検討したり、アプリケーション管理者３０６に設計を依頼してもよい。さらに、アプリケーション管理サーバ２０１が、インスタンスの稼働している物理装置を管理できるように、アプリケーションを構築するインスタンスをアプリケーション管理サーバ２０１が新たに作成したり、あるいは、アプリケーション管理サーバ２０１がインスタンスを専用の物理装置上に移行する処理を行ったりしてもよい。

以上の例では、テナント３００ごとに専用のアプリケーション管理サーバ２０１を設け、リソースプール３０３内に配備された物理リソースを利用してインスタンス１１（または２１）を作成する。

各アプリケーション管理サーバ２０１は、特定のリソース（ホスト、ネットワーク、ボリュームなど）を占有する。アプリケーション管理サーバ２０１は、自身の管理対象であるアプリケーションを、他のアプリケーション管理サーバと排他的に管理する。

例えば、仮想マシンホスト２０から構成されるテナントでは、インスタンス２１の性能負荷に応じてアプリケーションを仮想マシンホスト間で移行したり、リソースプール３０３にリソースを追加または削除したりすることで、アプリケーション（業務）を停止することなく負荷の平準化とリソース利用率の向上を実現できるであろう。

しかし、図２の比較例に示す構成におけるリソース利用率の向上は、同一のテナント内部に留まらざるを得ない。また、図２の比較例では、セキュリティ確保の観点から、複数のテナント間でアプリケーション管理サーバを共有することも困難である。

そこで、本実施例のリソース管理システムでは、以下に述べるように、アプリケーション管理とリソース管理とを連携させることで、データセンタ全体のリソース利用率を最適化する。具体的には、本実施例では、アプリケーション要件や稼働情報をもとに、テナントに割り当てるリソースプールを動的に構成する。

図３は、本実施例によるリソース管理システムおよびリソース管理方法の概要を示す説明図である。本実施例に特徴的な概念の一つは、対応づけられるリソースの一部を管理し仮想リソースとして提供するコンテナ３１０である。コンテナ３１０は、図２の比較例においてアプリケーション管理サーバ２０１に対して登録された、物理リソース（物理装置）に相当する構成要素である。コンテナ３１０は、実際の物理ハードウェア構成を仮想化する役割を持つ。なお、以下の説明では、特に区別しない場合、符号に添えるアルファベットを無視して表記する。例えば、テナント３００ａ、３００ｂをテナント３００と、リソースプール３０３ａ、３０３ｂをリソースプール３０３と、アプリケーション管理サーバ２０１ａ、２０１ｂをアプリケーション管理サーバ２０１と、表記する場合がある。

テナント３００内では、コンテナ３１０をアプリケーションごとのリソースプールとして利用する。各テナントでは、テナントごとの契約リソース量等のリソース情報を管理している。

統合リソース管理部２０２は、全ての物理的なリソースを予めコンテナ３１０として構成しておき、各アプリケーション管理サーバ２０１へ管理対象として登録しておく。後述の通り、コンテナ３１０が提供することになる仮想的なリソース構成と、コンテナに登録される物理リソース構成とを一致させる必要はない。したがって、物理的なリソースの総量を超えて、コンテナ３１０のリソース量を定義することができる。

コンテナ３１０に対応付けられる「リソース」としての物理リソースには、例えば、サーバ（計算リソース）、ネットワーク（通信リソース）、ストレージリソースなどがある。コンテナ３１０は、これら物理リソースの組み合わせにより構成されており、アプリケーション管理サーバ２０１の管理対象として登録可能である。

サーバリソース３１１ａの種類としては、例えばベアメタルホスト１０、仮想マシンホスト２０、論理パーティションホストなどを単体で使用する場合、複数のサーバを組み合わせて構成されるサーバクラスタを使用する場合がある。論理パーティション（ＬＰＡＲ）ホストとは、ＣＰＵやネットワークアダプタなどの各コンポーネントを論理的に分割したサーバリソースである。サーバクラスタとしては、例えば、冗長化された仮想マシンホスト２０、冗長化されたベアメタルホスト１０、あるいは、複数サーバのバスを結合してＳＭＰ（対称型マルチプロセッシング）構成としたサーバ群がある。

ネットワークリソース３１１ｂとは、レイヤ２またはレイヤ３で制御される例えば仮想ＬＡＮや、サブネット、仮想プライベートネットワークなどのように、ホスト間で通信可能な範囲（隔離ネットワーク）である。あるいは、ネットワークリソース３１１ｂは、ファイヤウォール、ロードバランサ、ＶＰＮ（Virtual Private Network）ゲートウェイなどの、ネットワーク機能を提供するアプライアンスであっても良い。

ストレージリソース３１１ｃとは、例えば、ストレージ装置１００が提供するボリューム１０１、ネットワークファイルシステム上のディレクトリである。

前述のリソース３１１ａ、３１１ｂ、３１１ｃは、データセンタ内に設けられている特定の装置であってもよいし、外部のＩａａＳクラウドから調達したサーバインスタンスやオブジェクトストレージであってもよい。

コンテナ３１０の構成は、統合リソース管理部２０２により管理される。アプリケーション管理サーバ２０１は、統合リソース管理部２０２へリソースを要求することにより、必要なコンテナ３１０を調達する。

アプリケーション管理サーバ２０１は、所望のコンテナ３１０を占有して、そのコンテナ３１０を当該アプリケーション専用のリソース領域として利用できる。統合リソース管理部２０２は、物理的にどのリソース３１１をどのコンテナ３１０に割り当てるか、という構成管理を制御する。統合リソース管理部２０２は、アプリケーション管理サーバ２０１に関与されることなく、コンテナ３１０の物理構成を変更することができる。したがって、本実施例によれば、アプリケーションの管理体系に干渉せずに、複数アプリケーション間または複数テナント間で、リソースを融通しあい、リソースの利用率を平準化することができる。

例えば図３中の矢印３１２ａに示すように、同一のアプリケーション管理サーバ２０１ａで管理されるリソースを、異なるテナントに提供されているコンテナ間で調整することができる。具体的には、アプリケーションＡの管理サーバ２０１ａが管理する第１のコンテナ３１０（１）の有するリソースは、第１のテナント３００ａのリソースプール３０３ａを介してインスタンス１１ａに使用されている。同じアプリケーション管理サーバ２０１ａの管理する第２のコンテナ３１０（２）の有するリソースは、第２のテナント３００ｂのリソースプール３０３ｂを介して２つのインスタンス１１ｂに使用されている。

複数インスタンス１１ｂにより使用される第２のコンテナ３１０（２）の負荷が増大すると、インスタンス１１ｂを使用するユーザ３０１ｂは、第２のコンテナ３１０（２）へのリソース追加を要求する。このリソース追加要求は、クライアントコンピュータ７０から通信ネットワーク３０１を介して、管理コンピュータ２００に送られる。この要求に従い、同一のアプリケーション管理サーバ２０１ａで管理されている、第１のコンテナ３１０（１）から第２のコンテナ３１０（２）へ、リソースが移行される。説明の理解のために、リソースが減少する第１のコンテナ３１０（１）を移行元コンテナと、リソースが追加される第２のコンテナ３１０（２）を移行先コンテナと、それぞれ呼ぶ場合がある。

ここで、第１のコンテナ３１０は、例えばリソース利用率が低いなどの、所定の移行元選択条件を満たしているものとする。移行元のコンテナを選択するための条件としては、例えば、リソース利用率が基準値以下であること（または利用率が最も低いこと）、リソース移行先のコンテナを使用するアプリケーションに欠かせない機能を有していること（アプリケーション制約条件を満たすこと）、ボトルネックなどの性能劣化が生じていないこと、がある。これら以外の条件を移行元選択条件に加えてもよいし、上記条件の幾つかを移行元選択条件から外してもよい。

第１のコンテナ３１０（１）から第２のコンテナ３１０（２）へリソースを移すことにより、第２のコンテナ３１０（２）の処理能力が増大し、負荷が軽減する。

図３には、異なるアプリケーション間でリソースを調整する例（３１２ｂ）も示されている。図示の例では、アプリケーションＢの管理サーバ２０１ｂの管理する第３のコンテナ３１０（３）は、第１のテナント３００ａのリソースプール３０３ａを介して、インスタンス１１ａに使用されている。なお、アプリケーション管理サーバ２０１ｂは、もう一つのコンテナ３１０も管理しているが、そのコンテナ３１０は使用されていない。

例えばユーザ３０１ａが、第３のコンテナ３１０（３）を使用するインスタンス１１ａの応答性能の改善を希望する場合、第３のコンテナ３１０（３）へのリソース追加を管理コンピュータ２００に要求する。この要求に従い、第１のコンテナ３１０（１）に仮想的に割り当てられているリソースの一部が、第３のコンテナ３１０（３）に移る。上記同様に、第１のコンテナ３１０（１）は所定の移行元選択条件を満たすために、リソースの移行元コンテナとして選択されたとする。

統合リソース管理部２０２が作成して管理するコンテナ３１０により、アプリケーション管理サーバ２０１へ提示するリソースを仮想化することができる。したがって、例えば記憶媒体の追加または削除などの、コンテナ３１０に割り当てられる物理的な装置構成に変更があった場合でも、アプリケーション管理サーバ２０１は物理的装置構成の変更に全く関知しない。アプリケーション管理サーバ２０１は、物理的装置構成の変更と無関係に、アプリケーションを管理することができる。

図４は、管理コンピュータ２００に設けられ、本実施例に特徴的な機能を実現するための管理コンポーネント群を示す。前述の通り、統合リソース管理部２０２は、リソース利用率に応じて、コンテナ間でリソースを配分する機能を提供する。

ユーザ要求管理部２１０は、ユーザ要求を管理する機能である。ユーザ要求管理部２１０は、ユーザのインスタンス作成要求などの構成変更要求を管理クライアント７２から受信する。ユーザ要求管理部２１０は、統合リソース管理部２０２が構成変更した結果を管理クライアント７２に返信する。ユーザ要求管理部２１０は、管理クライアント７２から複数の要求を受け付けた場合、実行順序や進捗状況などを制御する。

統合リソース管理部２０２は、インスタンス管理テーブル２１１やテナント管理テーブル２１２を用いて、ユーザやアプリケーション管理サーバ２０１に提供する構成情報を保持する。テナント３００あるいはアプリケーション管理サーバ２０１に提供される仮想的なリソース構成は、コンテナ３１０ごとに管理され、コンテナ管理テーブル２１５に保持される。

リソース構成管理部２１３は、リソース構成を管理する機能であり、アプリケーション管理サーバ２０１と連携して動作する。リソース構成管理部２１３は、リソース稼働情報データベース２１６に保持されている稼働情報を参照しながら、コンテナ３１０と物理装置（リソース）との関連付けを制御する。

リソース構成管理部２１３は、予め設定された管理方法に従って、各リソースの稼働情報を処理し、処理結果を性能評価テーブル２１４に格納する。具体的には、リソース構成管理部２１３は、アプリケーションの要求するリソース要件（性能要件）に基づいて、リソースの稼働情報を評価したり加工したりし、その結果を性能評価テーブル２１４に記憶する。

統合リソース管理部２０２は、管理対象の各装置１０、２０、５０、１００の構成に対する制御命令を、各装置管理部２０３、２０４、２０５に送信する。

装置管理部２０３、２０４、２０５は、管理対象の各装置から利用率および実性能を取得し、リソース稼働情報データベース２１６に格納する。リソース稼働情報データベース２１６は、コンテナ管理テーブル２１５に保持される装置識別子や時期をキーにして、構成要素毎に稼働情報の履歴を提供する機能を有する。

アプリケーション管理サーバ２０１の機能構成を説明する。アプリケーション管理サーバ２０１は、例えば、リソース管理部２０６、リソース要件定義テーブル２０７、アプリケーション稼働情報データベース２０８を備える。

リソース管理部２０６は、アプリケーションが利用している対象リソースの構成を管理するために、統合リソース管理部２０２に構成変更を要求する。アプリケーション管理サーバ２０１は、アプリケーションに適した要件を定めており、この要件をリソース要件定義テーブル２０７に保持している。リソース要件は、アプリケーションの種類に応じて異なるため、リソース要件を管理するリソース要件定義テーブル２０７の形式も一定ではなく、アプリケーションごとに異なる可能性がある。

アプリケーション稼働情報データベース２０８は、アプリケーションの設定値や性能値などの稼働情報を保持する。アプリケーションの稼働情報とは、例えば、計算リソース、サービスクライアント７１との間に確立されたコネクション、そのコネクションの利用状況などである。計算リソースとは、例えば、当該アプリケーションが利用するプロセス、スレッド、メモリ空間などである。コネクションの利用状況とは、例えば、応答時間、トランザクション数などである。これらの稼働情報は、各アプリケーションの設計に基づき、独自の名称や属性などのデータ構造を有する。

図５は、インスタンスごとに管理される設定値や属性を格納するためのインスタンス管理テーブル２１１を示す。ユーザには、インスタンス管理テーブル２１１に記載の情報がクライアントコンピュータ７０を介して提供される。つまり、ユーザには、インスタンスに割り当てられている物理的装置の識別情報は抽象化されて提供される。ユーザは、自分が利用するインスタンス１１に実際に割り当てられている物理リソースがどれなのか知る必要は必ずしもない。

インスタンス管理テーブル２１１は、例えば、インスタンスの識別子２１１ａ、インスタンスの所有者２１１ｂ、所属しているリソースプール２１１ｃ、コンテナ２１１ｄ、リソース構成２１１ｅ、ネットワークポリシ２１１ｆ、グレード２１１ｇ、消費ポイント２１１ｈ、利用期限２１１ｊ、（必要であれば）アプリケーション管理サーバ識別名２１１ｋを対応付けて保持する。

前述の通り、インスタンス１１とは、それぞれゲストＯＳを有する論理的な計算機を表現している。インスタンス１１は物理装置から抽象化されているという意味で、テーブル２１１には、仮想的なリソース構成２１１ｅが定義されている。

インスタンス識別子２１１ａは、インスタンス１１を一意に識別する情報である。所有者２１１ｂは、インスタンス１１を使用するユーザを一意に識別する情報である。リソースプール２１１ｃは、インスタンス１１が使用するコンテナ３１０の所属しているリソースプール３０３を一意に識別する情報である。コンテナ２１１ｄは、インスタンス１１にリソースを提供するコンテナ３１０を一意に識別する情報である。

リソース構成２１１ｅは、一般的なコンピュータアーキテクチャと同じくＣＰＵやメモリなどの構成要素からなる。リソース構成２１１ｅの内容は、ユーザの要求に応じて個別に設定することもできる。ユーザ要求管理部２１０に保持されるカタログテンプレートとして、リソース構成２１１ｅの雛形データを用意してもよい。ただし、同じコンテナ識別子２１１ｄを有するインスタンスのリソース構成２１１ｅの総計が、コンテナ３１０が提供するリソース容量を超えないように設定される。前述の通り、コンテナ３１０は仮想的なリソース構成を定義したものであるから、リソース構成２１１ｅはコンテナ３１０へ対応付けられた物理的な装置のリソース構成とは必ずしも一致しない。

ネットワークポリシ２１１ｆは、インスタンス間の通信や、公衆通信網上の他のホストとの通信に関して、使用するプロトコルや、通信の許可または不許可を設定する。グレード２１１ｇは、インスタンスに割り当てられるリソース性能に対して、サービスレベルを設定する。

インスタンス１１には、例えばデータセンタ事業者とユーザとの間の契約に基づき、契約情報を関連付けることができる。契約情報としては、例えば、利用料を定めるための消費ポイント２１１ｈや、有効な契約の残り期間を示す利用期限２１１ｊなどがある。契約の主体や形態に応じて、ライセンスに関する情報や、ユーザ申請の識別情報などもテーブル２１１で管理してもよい。

必要であれば、ユーザは、アプリケーション管理サーバ２１１ｋやアプリケーション管理者へ、ユーザのインスタンスが利用しているコンテナの識別子２１１ｄを通知することで、所望のアプリケーションをインスタンスに導入し、運用することができる。

図６は、テナントを管理するためのテナント管理テーブル２１２を示す。テナント管理テーブル２１２は、テナントごとに管理される設定値や属性を格納する。テナント管理テーブル２１２には、例えば、テナントＩＤ２１２ａ、ユーザグループＩＤ２１２ｂ、管理ロール定義２１２ｃ、リソースプールＩＤ２１２ｄ、インスタンス管理テーブルＩＤ２１２ｅ、残り利用可能ポイント２１２ｆを対応付けて保持する。

テナントＩＤ２１２ａは、テナント３００を一意に識別する情報である。ユーザグループＩＤ２１２ｂは、ユーザグループを一意に識別する情報である。管理ロール定義２１２ｃは、ユーザの役割と管理権限とを定義する情報を特定するための情報である。リソースプールＩＤ２１２ｄは、テナントに設けられたリソースプール３０３を一意に識別する情報である。インスタンス管理テーブルＩＤ２１２ｅは、テナントで稼働するインスタンスを管理するためのインスタンス管理テーブル２１１を一意に識別する情報である。

テナントではセキュリティが確保されており、インスタンス管理テーブル２１１で述べたネットワークポリシ２１１ｆのような形式で、リソース構成情報に対するアクセス可否を管理できる。残り利用可能ポイント２１２ｆは、利用可能な契約リソースの利用料を表す情報である。

図７は、コンテナを管理するコンテナ管理テーブル２１５を示す。コンテナ管理テーブル２１５は、コンテナごとに管理される設定値や属性を格納する。コンテナ管理テーブル２１５は、アプリケーション管理サーバ２０１に通知される、コンテナ情報および物理装置（リソース）の対応付けを管理する。

コンテナ管理テーブル２１５において、アプリケーション管理サーバ２０１には、構成変更に必要な、コンテナＩＤ２１５ａとアクセス権限２１５ｂが引き渡される。アプリケーション管理サーバ２０１には、物理装置構成などに関する情報２１５ｃ〜２１５ｋは公開されない。

コンテナＩＤ２１５ａは、コンテナを一意に識別する情報である。アクセス権限２１５ｂは、コンテナにアクセスして、論理的なリソース構成を管理するためのアクセス権限情報を一意に識別する情報である。アプリケーション管理サーバ２１５ｃは、コンテナを利用するアプリケーションを管理しているアプリケーション管理サーバ２０１を一意に識別する情報である。

コンテナ管理テーブル２１５には、コンテナ３１０の内容として、例えば、サーバ２１５ｄ、ネットワーク２１５e、ストレージ２１５ｇの組み合わせが保持される。これらコンテナ３１０を構成するリソースの総量は、仮想リソース容量２１５ｊおよび実リソース容量ｋに保持される。仮想リソース容量２１５ｊおよび実リソース容量ｋは、いずれも統合リソース管理部２０２により管理される量である。ただし、実リソース容量２１５ｋが一つのコンテナとして管理される装置が物理的に有しているリソース容量の総和に等しい一方、仮想リソース容量２１５ｊはアプリケーション管理サーバ２０１へ提供される仮想的なリソース容量である。統合リソース管理部２０２の働きにより、両者は一致しないことがある。

インスタンス種別２１５ｆは、コンテナ上で稼働するインスタンスの種別を示す。インスタンス種別２１５ｆにより、構成の管理方法や装置管理部を管理できる。インスタンス種別２１５ｆには、例えばコンテナが仮想マシンホスト２０であれば“ＶＭ”が、ベアメタルホスト１０であれば“ＰＭ”が設定される。

アプリケーション管理サーバ２０１は、アクセス権限２１５ｂで特定されるアクセス権限情報を利用しなければ、コンテナＩＤ２１５ａで特定されるコンテナ３１０を管理対象とすることができない。ただし、コンテナの構成によっては、特定のアプリケーションのみが利用可能な場合がある。特有の構成を備えるコンテナを利用可能なアプリケーションを識別する情報は、アプリケーション制約２１５ｈに設定される。

特定のアプリケーションのみ利用可能な例としては、例えば、アプリケーション開発元において認証済みのハードウェアのみ動作を保証する場合、アプリケーションを動作させるために所定のハードウェア機能が必要な場合、特定バージョンのファームウェア構成でのみ動作が保証されている場合などがある。

アプリケーション制約フィールド２１５ｈは、管理者またはアプリケーション管理サーバ２０１により手動または自動で設定され、コンテナＩＤ２１５ａで特定されるコンテナの構成に変更が生じた場合、その値が更新される。

＜リソースプールの構成改善方法＞

本実施例では、コンテナ３１０という特徴的な構成を導入することで、物理的な装置構成と、アプリケーション管理サーバ２０１やテナント３００に認識させる論理的な装置構成とを分離することができる。

本実施例では、異種アプリケーション間あるいは異なるテナント間で、コンテナに編入する物理的な装置を融通したり、コンテナ全体を入れ替えたりすることができる。これにより、本実施例では、既存のアプリケーション管理体系やテナント管理体系に影響することなく、業務システム（アプリケーション）に割り当てるリソース構成を使用状況に応じて動的に変更することができる。

コンテナへのリソース割り当てを、異なる複数種類のアプリケーション要件（アプリケーションがリソースに要求する条件）に基づいて実施することで、データセンタ全体のリソース利用率を高めることができる。そこで、異なる種類でのアプリケーション要件を統一された観点で評価し、調整することが重要となる。

図８は、アプリケーション要件を考慮して性能を評価する方法の概念を示す。図８は説明のため２次元平面図としたが、考慮する性能指標の数に応じた任意の正数Ｎ次元で評価する場合も同じである。

図８（ａ）は、ある性能指標（例えばＣＰＵ利用率およびディスクＩＯＰＳ）における各コンテナ３１０ａ〜３１０ｄの分布を表す。図８（ａ）では、リソース管理者が定義する目標性能値の範囲を点線３２１で示している。

一つの考え方として、例えば物理装置（リソース）そのものが有する性能に基づく目標性能値の範囲３２１を用いてサービスレベルを定義し、グレードとしてユーザに提示する方法がある。

各コンテナ上で稼働するアプリケーションごとの要件（リソース要求）を考慮しない場合、図８（ａ）のように、物理装置の性能指標をそのまま採用して評価するより他に方法はない。この場合、原点からの距離により、各コンテナの利用状況を評価する。例えばコンテナ３１０ｃはリソース利用率が比較的低く、コンテナ３１０ｂはリソース利用率が高い、と分析できる。コンテナ３１０ａ、３１０ｂについては、利用傾向が偏っていると判断される。

しかし、コンテナ上で稼働するアプリケーションの種類により、必要となるリソースの種別は異なるのが自然である。したがって、アプリケーションの種類を考慮せずに、性能指標を均一に評価する方法は適切ではない。つまり、アプリケーション管理サーバ２０１が定義するリソース要件や、アプリケーション管理のためのノウハウを考慮することができれば、コンテナでのリソースの需要傾向に基づいてリソース利用率を公平に判定することができる。

図８（ｂ）は、アプリケーションごとに異なるリソースの利用特性を考慮した、性能評価の方法を示す。

例えば、図８（ａ）に記載の各コンテナ３１０ａ〜３１０ｄにおいて、コンテナ３１０ｃおよび３１０ｄでアプリケーションＡを稼働させ、コンテナ３１０ａおよび３１０ｂでアプリケーションＢを稼働させるとする。

アプリケーションＡのリソース利用傾向を性能特性曲線３２２として示す。アプリケーションＡの性能特性曲線３２２と、アプリケーションＡが稼働するコンテナ３１０ｃ、３１０ｄの性能値とを重ね合わせると、コンテナ３１０ｃはアプリケーションＡに適したリソース利用率であることがわかる。しかし、コンテナ３１０ｄはアプリケーションＡに適していないことが判明する。

コンテナ３１０ｄがアプリケーションＡの性能傾向に適していない理由としては、コンテナ３１０ｄに対応付けられている他のリソース要素（例えばネットワーク性能など）にボトルネックが存在している場合や、コンテナ３１０ｄに割り当てられるべきＣＰＵリソース量が多すぎる場合、のいずれか又は両方であると推定される。

アプリケーションＢについても同様の分析が可能である。アプリケーションＢのリソース利用傾向を示す性能特性曲線３２３と、アプリケーションＢが稼働するコンテナ３１０ａ、３１０ｂの性能値とを重ね合わせて判断する。コンテナ３１０ａは、アプリケーションＢの性能傾向に適していないことがわかる。

図８（ｂ）に示す場合は、例えばコンテナ３１０ａと３１０ｄをアプリケーションＡとアプリケーションＢとの間で交換したり、あるいは、コンテナ３１０ａのリソース構成をコンテナ３１０ｄのリソース構成と近くなるよう変更したりする、といった改善方策が考えられる。

本実施例では、少なくとも３つの技術的特徴を備えているため、アプリケーションの特性を考慮して、データセンタ全体のリソース利用率を最大化することができる。第１の技術的特徴は、アプリケーション管理サーバ２０１が対象とするリソース構成と、物理装置の構成とを分離する「コンテナ」の概念である。第２の技術的特徴は、異種アプリケーションのリソース要件を統一的に比較するための表現形式である。これについては、後述する。第３の技術的特徴は、複数コンテナ間で物理装置（リソース）を融通する構成管理方法である。

前述の通り、アプリケーション管理サーバ２０１が必要とするリソース構成に関連する情報は、リソース要件定義テーブル２０７に保持される。これらリソース要件に関する情報は、アプリケーションごとに一定ではなく、アプリケーション管理サーバ２０１が保持するリソース要件の表現形式もそれぞれに異なる。

図９は、リソース要件を定義するリソース要件定義テーブル２０７の例を示す。例えば、図９（ａ）に示すリソース要件定義テーブル２０７は、ターゲット２０７ａ、リソース項目２０７ｂ、要求値２０７ｃ、稼働状況２０７ｄ、評価値２０７ｅを対応付けて管理している。ターゲット２０７ａは、アプリケーションの使用対象となるコンテナ３１０を一意に識別する情報である。リソース項目２０７ｂは、対象コンテナ２０７ａに対応付けられるリソースの項目を示す情報である。要求値２０７ｃは、アプリケーションがリソースに要求する条件である。稼働状況２０７ｄは、リソース項目２０７ｂで示す性能指標の実測値である。評価値２０７ｅは、稼働状況２０７ｄの値が要求値２０７ｃを満たしているか否かを判定した情報である。

図９（ｂ）に、他の形式のリソース要件定義テーブル２０７（１）を示す。このテーブル２０７（１）では、ターゲット２０７ｆと、評価値２０７ｇとを対応付けて管理し、他の項目（リソース項目、要求値、稼働状況）は管理していない。

図９（ａ）に示すように、特定の構成要素（リソース）に対して性能要件（２０７ｂ）が定義されている場合もあれば、図９（ｂ）に示すように、アプリケーションの応答性能や処理スレッド数などの、リソース要件に直接的に関連付けられない性能値を用いて性能要件が定義されている場合もある。

図１０を用いて、アプリケーションがリソースに求めるリソース要件を異種アプリケーション間で統一的に比較するための表現形式を説明する。

図１０は、全体リソースに対する稼働情報を算出するために、リソース管理部２１３が使用する、本実施例に特有の性能評価テーブル２１４を示す。性能評価テーブル２１４では、アプリケーションの種類ごとに定められるリソース要件に基づき、コンテナＩＤ２１４ａに対して、評価が必要な性能指標２１４ｂと、その実計測値２１４ｃとが保持されている。

さらに、テーブル２１４では、複数の異種アプリケーションによるリソース要件を共通的に比較評価するため、補正係数２１４ｄを設けている。それぞれの性能指標２１４ｂの実計測値２１４ｃを補正係数２１４ｄで補正し、その補正結果を補正値２１４ｅに記録する。補正値２１４ｅは、実計測値２１４ｂと補正係数２１４ｄとの単純な積として算出しており、無次元の値である。

性能指標２１４ｂには、リソース利用率の高さを示す指標のみならず、リソース性能の劣化を示す指標が存在する。リソース性能の劣化を示す指標としては、例えばディスクＩ／Ｏの応答時間などのように、性能劣化の大きさが数値の大きさに現れる指標のほか、総合的な性能ボトルネックの判定に使用する指標もある。

例えば、ＣＰＵ利用率が高い場合は、一見すると計算リソースの利用率が高まっているかのように思われる。しかし実際には、メモリ不足に伴ってスワップ処理が発生しており、スワップ処理の影響がＣＰＵ負荷として現れていることもある。

そこで、性能評価テーブル２１４では、性能上のボトルネックを考慮し、リソースの利用率向上のために良い影響を与えていれば「＋」を、悪い影響を与えていれば「−」を、保持するための影響判定２１４ｆを有する。

性能指標２１４ｂとしてどの構成要素（リソース）を選ぶかについては、アプリケーション管理サーバ２０１により自動的に設定されてもよいし、管理者の手によって設定されてもよい。

補正係数２１４ｄは、複数の異なるアプリケーションに対するコンテナ３１０の性能比較を公平に行うために重要な値であり、各性能指標をどの程度、重要視するかという定量値を与えるための重みという意味を持つ。補正係数２１４ｄを用いることにより、前述したアプリケーションごとのリソース性能特性を表現することができる。

例えば、コンテナＩＤ：ＣＮＴ−Ａ０２１におけるＣＰＵ利用率（総処理時間に対するＣＰＵ時間の比率）は４５％であるのに対し、コンテナＩＤ：ＣＮＴ−Ａ０２５のＣＰＵ利用率は６９％である。

この単純な比較では、後者のコンテナＣＮＴ−Ａ０２５のほうが、リソース利用率が高いように思われる。しかし、実は、コンテナＣＮＴ−Ａ０２５上で稼働するアプリケーションは、ＣＰＵに高い演算性能を必要とする。このようなアプリケーションの特性の差を各補正係数２１４ｄにより重みづけして、補正値２１４ｅを得る。実測されたＣＰＵ利用率が４５％のコンテナＣＮＴ−Ａ０２１の補正値は９０となり、実測されたＣＰＵ利用率が６９％のコンテナＣＮＴ−Ａ０２５の補正値は３５となる。このように、アプリケーション間の特性の差を考慮した補正値を算出することで、コンテナＣＮＴ−Ａ０２５ではＣＰＵを利用しきれておらず、見かけ上の数値が低いコンテナＣＮＴ−Ａ０２１のほうが、逆にリソース利用率が高いことを表現することができる。

補正係数２１４ｄは、各アプリケーション管理者の手により設定されてもよいし、アプリケーション管理サーバ２０１により自動的に設定されてもよい。稼働情報を統計処理することで、リソース構成管理部２１３が補正係数を算出してもよい。

統計的な稼働情報をもとに補正係数２１４ｄを算出する方法の例を示す。ただし、本実施例にかかる計算機システムにおいて、アプリケーションを稼働させるコンテナについて十分に多数の稼働実績があり、稼働情報の履歴が保持されているものとする。例えば図９（ａ）に示すように各リソース項目について要求値２０７ｃが設定されている場合、これを閾値にして、下記のように計算する。要求値の不等号の向きにより、下限を定める要求値と上限を定める要求値とを判別する。以下の各式では理解のために、一部の変数にテーブル項目の符号を添える。式中の補正係数は、図１０の補正係数２１４ｄのことであるから符号の記載を省略する。

補正係数＝倍率／下限要求値２０７ｃ，影響判定２１４ｆ＝（＋）・・・式１

補正係数＝倍率／上限要求値２０７ｃ，影響判定２１４ｆ＝（−）・・・式２

上記倍率は、性能値ごとにとり得る値を用いて、例えば次式のように算出する。

倍率＝(アプリケーション倍率)×(履歴最大値−履歴最小値)／定義域・・・式３

アプリケーション倍率は、アプリケーションの重要度や人気の度合いを表し、アプリケーションの導入数（インスタンス台数）に基づいて評価する。あるいは、図９（ｂ）のように、あるインスタンスまたはコンテナに対して、アプリケーション独自の評価値２０７ｇを有する場合には、次式から評価値２０７ｇを算出する。

[全性能指標２１４ｂの総和](補正係数×性能履歴の平均値)＝評価値・・・式４

このとき、同一のアプリケーション内で保持されるリソース要件定義テーブル２０７のレコード数を次数とする連立方程式が成立する。各性能指標２１４ｂが互いに独立であればその連立方程式は解を持ち、補正係数２１４ｄが決定される。各性能指標２１４ｂの一組以上が従属である場合には、最小二乗法等で求めた近似解を補正係数２１４ｄとしてもよい。

図１１は、アプリケーションの要求するリソース要件に基づいて各コンテナの稼働情報を補正し、リソース全体における稼働情報を算出し、リソースを融通するコンテナを決定するための処理のフローチャートである。

リソース構成管理部２１３が、例えばアプリケーション管理サーバ２０１からリソースの追加要求を受信すると（Ｓ１０）、その受信を契機に以降の処理が開始される。リソースの追加要求には、アプリケーション１２（または２２）の種別を含む。さらに追加されるべきリソース量を含む場合もある。コンテナ３１０の構成を変更することによりリソース配分を変更する一連の処理を開始する所定の契機としては、前述のリソースの追加要求の受信に限らない。例えば、システム管理者が明示的に指示した場合に本処理を開始してもよい。統合リソース管理部２０２が本処理を定期的に実行してもよい。ユーザ要求管理部２１０が、インスタンスの構成変更についての要求を受信した場合に、インスタンス管理テーブル２１１からアプリケーション管理サーバ２１１ｋを特定し本処理を実行してもよい。

また、どの種別のリソース（サーバ、ネットワーク、ストレージ）の追加であるかを判別する方法にも複数ある。例えば、ユーザが、必要なリソースの種別を明示して、リソース追加要求を指示してもよい。リソース利用率の履歴をもとに自動計算することで、追加の必要なリソースの種別と量を自動的に特定する構成でもよい。

後者の自動計算には、アプリケーション管理サーバ２０１が有するリソース要求定義テーブル２０７やアプリケーション稼働情報テーブル２０８を利用して、リソースの消費傾向を算出し、消費傾向の大きいリソースを追加対象として決定する方法がある。統合リソース管理部２０２が有する性能評価テーブル２１４のうち、補正係数２１４ｄの値が大きいリソースを、追加すべきリソースであるとして決定する方法も考えられる。

ステップＳ１１において、統合リソース管理部２０２は、アプリケーション管理サーバ２０１に定義されたリソース要件に変更があったか否かを判定する。具体的には、リソース構成管理部２１３が、アプリケーション管理サーバ２０１上のリソース管理部２０６を経由してリソース要件定義テーブル２０７を参照し、更新の有無を判定する。判定の結果、更新があった場合（Ｓ１１：ＹＥＳ）、リソース構成管理部２１３は、ステップＳ１２において、補正係数２１４ｄを再度計算し、性能評価テーブル２１４を最新の状態に更新する。

ステップＳ１３において、リソース構成管理部２１３は、稼働情報の実計測値２１４ｃをリソース稼働情報データベース２１６より取得し、補正値２１４ｅを算出して性能評価テーブル２１４に格納する。

ステップＳ１４において、リソース構成管理部２１３は、コンテナ管理テーブル２１５に記載されたレコードを順に探索し、リソース利用率の低いコンテナを検出する処理を開始する。リソース利用率の低いコンテナは、性能評価テーブル２１４において、正の影響判定（＋）に関する補正値２１４ｅの総和を計算し、その合計値が小さいものを選ぶことにより決定される。

ステップＳ１５において、リソース構成管理部２１３は、コンテナ管理テーブル２１５におけるアプリケーション制約２１５ｈを参照し、リソースの追加を要求するアプリケーションが、処理対象のコンテナ上で稼働可能であるかを判定する。リソース構成管理部２１３は、処理対象コンテナがアプリケーション制約２１５ｈに違反すると判定すると（Ｓ１５：ＹＥＳ）、ステップＳ１４へ戻り、補正値２１４ｅの総和の低い他のコンテナを処理対象コンテナとして選択する。

ステップＳ１６において、リソース構成管理部２１３は、性能評価テーブル２１４の影響判定２１４ｆを参照することで、所定の性能劣化基準値よりも大きい性能劣化があるか判定する。

性能劣化の有無を判定する方法として、例えば、閾値に基づく方法の他に、既に選ばれている候補コンテナと処理対象コンテナとの間で、負の性能影響の度合い２１４ｆの大きさを比較する方法がある。処理対象コンテナの負の性能影響の度合い２１４ｆが候補コンテナの対応する値２１４ｆよりも大きい場合、性能劣化が有ると判定してもよい。

性能劣化が生じていない場合（Ｓ１６：ＹＥＳ）、リソース構成管理部２１３は、ステップＳ１７において、その処理対象コンテナを、リソース構成を見直す候補コンテナとして選定する。候補として選ばれるコンテナは、一つとは限らず、複数のコンテナが候補として選択される場合もある。なお、図７に示すコンテナの種別２１５ｆなどを考慮して、候補コンテナを選定しても良い。

ステップＳ１８において、リソース構成管理部２１３は、コンテナ管理テーブル２１５に記載のコンテナの内、未処理のコンテナが存在するか判定し、存在する場合には（Ｓ１８：ＹＥＳ）、ステップＳ１４へ戻り、前述のステップを繰り返す。

未処理のコンテナが無くなった場合（Ｓ１８：ＮＯ）、ステップＳ１９において、リソース構成管理部２１３は、候補コンテナが一つ以上検出されていた場合、その候補コンテナのリソース構成を変更する。

候補コンテナのリソース構成の変更とは、代表的には、リソースの減設である。ステップＳ１９においてコンテナのリソース構成を減設する処理としては、例えばサーバクラスタから一つ以上のノード（物理サーバ）を削除する処理、ストレージリソースからボリュームを削減する処理、ネットワークリソースに設定された通信優先度を下げる処理、などがある。あるいは、ステップＳ１９では、同じアプリケーション管理サーバ２０１が管理する他のコンテナに、インスタンスを集約する処理を実行してもよい。ステップＳ１９では、候補コンテナよりもリソース容量の小さなコンテナを新たに作成し、その新たに作成した小型コンテナに、候補コンテナ上で稼働しているインスタンスと候補コンテナの識別情報とを引き継がせる処理を実行してもよい。

ただし、前述したステップＳ１９での処理内容の全ての場合において、候補コンテナの識別情報およびインスタンスは削除されることはなく、コンテナ管理テーブル２１５のレコードは、リソース構成管理部２１３により適切な値に更新される。より具体的には、例えばステップＳ１９において、移行元コンテナのサーバクラスタからノードが削除されるとき、当該ノード上に仮想サーバが稼働していた場合には、当該仮想サーバは同じサーバクラスタ内の他のノード上へ移行されて移行元コンテナに留まる。このとき、インスタンス管理テーブル２１１や、コンテナ管理テーブル２１５の仮想リソース容量ｊには変更を生じない。これにより、移行元コンテナを使用しているユーザおよびアプリケーション管理サーバ２０１は、ステップ１９における物理的な構成の変更を察知せず使用を継続できる。一方で、コンテナ管理テーブル２１５において当該移行元コンテナを管理するレコードのサーバフィールド２１５ｄから当該ノードの識別子が削除され、実リソース容量ｋフィールドでは当該ノードが有していた分のリソースが減算される。

ステップＳ１９では、さらに、候補コンテナの減設処理によって生じたリソースの余裕分を、ステップＳ１０でリソース追加が要求されたコンテナに移動する。このとき、移行元コンテナと同様に、リソース構成管理部２１３により、コンテナ管理テーブル２１５のレコードが適切な値に更新される。ただし、コンテナ管理テーブル２１５における、リソース追加が要求された移行先コンテナについてのレコードを更新する際には、いずれかの装置の識別子の追加および実リソース容量ｋフィールドの更新に加え、仮想リソース容量ｊに追加されたリソース分の容量を加算する。

移行元コンテナから移行先コンテナにリソースを移す処理では、移行先コンテナにおいて、当該コンテナを構成するリソースを増設する処理が行われる。その後さらに同一コンテナ内で負荷を平準化する処理、例えば仮想マシンを仮想マシンホストクラスタ内で再配置する処理を行ってもよい。

＜物理装置に関するアクセス情報の管理方法＞

アプリケーション管理サーバ２０１がコンテナ３１０を管理する場合、物理的な装置へのアクセスが必要となる。アプリケーション管理サーバ２０１は、アクセス情報を用いて物理装置にアクセスする。アクセス情報としては、例えば管理ＩＰアドレス、認証アカウント、装置ＩＤを利用することができる。

アプリケーション管理サーバ２０１は、適切なアクセス情報を使用することで、安全かつ確実にコンテナ３１０のリソース構成を変更できる。ここでいう構成変更とは、例えば電源状態の変更、ブートオプションなどＢＩＯＳ（Basic Input/Output System）設定値の変更、物理アドレスなどネットワークアダプタの設定変更、入出力デバイスの切り替え、などを指す。

一方、仮想サーバ環境や、テナント管理を必要としない他のサーバ環境においては、物理装置上のＯＳを利用しているため、ＯＳを再設定したり再インストールしたりすることで、幾らでも新たなアクセス情報を設定することができた。

しかし、仮想化されていないサーバ環境を、複数のアプリケーションごとに権限を委譲して利用させる場合、物理装置に基づくアクセス情報を開示する必要がある。アプリケーション管理サーバ２０１と各物理装置とのアクセスを制御するには、アプリケーション管理サーバ２０１が保持するホストの認証アカウントを変更するか、あるいは管理ネットワーク上のファイヤウォール３０３においてアクセス経路を変更する方法がある。

前述した図１１の処理中のステップＳ１９において、コンテナ３１０が単一の物理装置から構成されていた場合（例えばベアメタルホスト１０を使用する場合）、同じ物理装置を他のアプリケーション管理サーバ用のコンテナへ登録し直す必要がある。このため、移行元アプリケーション管理サーバから移行先アプリケーション管理サーバにアクセス情報を移す必要がある。

ここでアクセス情報の移行とは、移行元で使用していたアクセス情報をそのまま移行先でも使用できるようにするという意味ではなく、移行先のアプリケーション管理サーバが移行先コンテナを安全に使用するためのアクセス情報を移行先アプリケーション管理サーバに設定するという意味である。

移行対象の物理装置についてのアクセス情報が移行先アプリケーション管理サーバに移行されない場合、元々その物理装置を使用していた移行元アプリケーション管理サーバは、今まで通り、その移行された物理装置にアクセス可能である。したがって、不正アクセス、システム障害、データ損失などが生じうる。本実施例では、複数コンテナ間で物理装置を融通するため、アクセス情報の適切な移行は欠かせない。

図１２は、アクセス情報を移行する処理を示すフローチャートである。以下の説明では、アクセス情報をアクセス権限情報と呼ぶ場合がある。

ステップＳ３０において、リソース構成管理部２１３は、移行対象の物理装置に設定されているアクセス権限であって、移行元アプリケーション管理サーバ２０１が使用していたアクセス権限を無効化する。ここで、アクセス権限を完全に削除しないのは、以降の処理中に万が一不測の障害が発生した場合であっても、有効なアクセス権限が失われないようにするためである。

ステップＳ３１において、リソース構成管理部２１３は、移行元アプリケーション管理サーバ２０１のリソース管理部２０６に対して、移行対象の物理装置についてのアクセス権限を削除するよう要求する。移行元アプリケーション管理サーバ２０１が、アクセス権限の変更機能を提供しない場合は、管理ネットワーク上のファイヤウォール３０３が移行元アプリケーション管理サーバ２０１から移行対象の物理装置へのアクセス経路を遮断してもよい。

ステップＳ３２において、リソース構成管理部２１３は、サーバ管理部２０３を通じて移行対象の物理装置上に、新たなアクセス権限を作成し、有効化する。

ステップＳ３３において、リソース構成管理部２１３は、ステップＳ３２で生成した新アクセス権限を、移行先アプリケーション管理サーバ２０１へ通知し、今後は新アクセス権限を使用するよう設定する。

ただし、移行先アプリケーション管理サーバ２０１が、アクセス権限の変更機能を提供しない場合は、管理ネットワーク上のファイヤウォール３０３にて、移行先アプリケーション管理サーバ２０１と移行対象の物理装置とのアクセス経路を許可すればよい。

ステップＳ３４において、リソース構成管理部２１３は、アクセス権限が適切に移行されたことを確認する。確認手段として、例えば、移行元アプリケーション管理サーバおよび移行先アプリケーション管理サーバ２０１から、移行対象の物理装置へそれぞれ接続試験を行う。その接続試験の結果、アクセス権限の移行が失敗していたら（Ｓ３４：ＮＯ）、リソース構成管理部２１３は、ステップＳ３６へ進んで、本フローチャートの開始時点まで状態を戻し、エラー終了する。

アクセス権限が正常に移行した場合（Ｓ３４：ＹＥＳ）、ステップＳ３５において、リソース構成管理部２１３は、ステップＳ３０で一旦無効化しておいた旧アクセス権限を移行対象の物理装置から削除し、本処理を正常に終了する。これにより、恒久的に移行元アプリケーション管理サーバ２０１は、移行された物理装置に恒久的にアクセスすることができず、安全が維持される。

本実施例によれば、リソースの使用状況の変化に対応して、コンテナ間でリソースを動的に移動させることができ、リソースの利用効率を高めることができる。

本実施例によれば、テナント毎のリソース管理体系やアプリケーション管理体系に矛盾することなく、時々刻々と需要が変化するデータセンタにおいて、リソース全体の利用効率を最適化することができる。

また、本実施例によれば、テナントごとのセキュリティを確保しつつ、従来の運用で培ったアプリケーション管理のノウハウを引き続き活用することができる。

本実施例では、アプリケーションプログラムに予め割り当てられているリソースを、リソース追加要求で指定された使用量よりも少なく設定する場合があるが、その後の使用状況に応じて、いつでもリソースの追加割当が可能であり、計算機システムを少ないリソースで効率的に運用することができる。なお、「リソースを指定された使用量よりも少なく設定する場合がある」という表現を、「リソースを指定された使用量よりも少なく設定する」と言い換えてもよい。

なお、本発明は、前述した実施例に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、前述された本発明の技術的特徴は、適宜結合させて実施することができる。

１０、２０：ホスト、１１、２１：インスタンス、５０、６０：スイッチ、７０：クライアントコンピュータ、１００：ストレージ装置、２００：管理コンピュータ、２０１：アプリケーション管理サーバ、２０２：統合リソース管理部、２０３：サーバ管理部、２０４：ネットワーク管理部、２０５：ストレージ管理部

Claims (13)

1. リソースを管理するリソース管理システムであって、
   前記リソースを提供する複数の物理計算機と、
   少なくとも一つのアプリケーションプログラムを実行する複数の仮想計算機と、
   前記複数の物理計算機および前記複数の仮想計算機に通信可能に接続される統合リソース管理部とを有し、
   前記統合リソース管理部は、
   対応づけられる前記リソースの一部を管理し仮想リソースとして提供する複数のコンテナを予め用意し、
   前記提供される仮想リソースの利用範囲を定義するリソース区画を管理し、
   前記コンテナは前記アプリケーションプログラムの何れかに対応づけられており、
   前記リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられる前記コンテナに他のコンテナで管理される前記リソースを移行し、前記他のコンテナの管理する前記リソース量は前記他のコンテナの提供する前記仮想リソースより少なくなることがあるリソース管理システム。
2. 前記統合リソース管理部は、前記複数のリソース区画のうち第１のリソース区画に提供する第１のコンテナに対応付けられている前記リソースの一部である第１所定リソースを、前記複数のリソース区画のうち第２のリソース区画に提供する第２のコンテナに対応付けることで、前記第１所定リソースの所属先を前記第２のリソース区画に移す、請求項１に記載のリソース管理システム。
3. 前記統合リソース管理部は、前記複数のリソースについての前記アプリケーションプログラムによる利用率を管理しており、前記複数のリソースのうち最も利用率の低いリソースを前記第１所定リソースとして選択する、
   請求項２に記載のリソース管理システム。
4. 前記統合リソース管理部は、前記複数のリソースについての性能劣化を管理しており、最も利用率の低い前記リソースについての前記性能劣化が所定値よりも小さい場合に、前記利用率が最も低く、かつ、前記性能劣化が前記所定値よりも小さいリソースを前記第１所定リソースとして選択する、
   請求項３に記載のリソース管理システム。
5. 前記統合リソース管理部は、前記第２のアプリケーションプログラムが使用するための所定の制約条件を前記第１所定リソースが満足するかを判定し、前記利用率が最も低く、かつ、前記性能劣化が前記所定値よりも小さく、かつ、前記所定の制約条件を満たす仮想リソースを前記第１所定リソースとして選択する、
   請求項４に記載のリソース管理システム。
6. 前記統合リソース管理部は、
   前記第１のコンテナを使用する第１のアプリケーションプログラムを管理するための第１アプリケーション管理部と、前記第２のコンテナを使用する第２のアプリケーションプログラムを管理するための第２アプリケーション管理部とに、通信可能に接続されており、
   前記第１所定リソースを前記第１のコンテナから前記第２のコンテナに移す際に、前記第１所定リソースに設定されている、前記第１アプリケーション管理部が前記第１所定リソースにアクセスするための旧アクセス権限情報を無効化し、
   前記旧アクセス権限情報を前記第１アプリケーション管理部から削除し、
   新たなアクセス権限情報を生成して、前記新たなアクセス権限情報を前記第１所定リソースに設定し、
   前記新たなアクセス権限情報を前記第２のアプリケーション管理部に設定し、
   前記第１所定リソースにアクセスするためのアクセス権限が前記第１アプリケーション管理部から前記第２アプリケーション管理部に移行したことを確認し、
   前記旧アクセス権限情報を前記第１アプリケーション管理部から削除する、
   請求項５に記載のリソース管理システム。
7. 前記統合リソース管理部は、前記複数のコンテナに対応付けられている前記リソースのそれぞれに予め設定されている所定の性能指標の実測値を用いて所定の演算を行うことにより、前記コンテナを使用する前記アプリケーションプログラムの種類に依存せずに前記複数のコンテナの性能を評価するための性能評価値を算出し、前記算出した性能評価値を提示する、
   請求項１のいずれかに記載のリソース管理システム。
8. 前記統合リソース管理部は、前記複数のコンテナに対応付けられている前記リソースのそれぞれに予め設定されている所定の性能指標の実測値を用いて所定の演算を行うことにより、前記コンテナを使用する前記アプリケーションプログラムの種類に依存せずに前記複数のコンテナの性能を評価するための性能評価値を算出し、算出した性能評価値を前記所定の要求を発行する装置に通知し、
   前記所定の要求は、前記性能評価値からボトルネックであると判定された前記リソースの追加を要求するものである、
   請求項４に記載のリソース管理システム。
9. 前記統合リソース管理部は、
   前記複数のコンテナに対応付けられている前記リソースのそれぞれに予め設定されている所定の性能指標の実測値を用いて所定の演算を行うことにより、前記コンテナを使用する前記アプリケーションプログラムの種類に依存せずに前記複数のコンテナの性能を評価するための性能評価値を算出し、
   前記算出した性能評価値に基づいて前記複数のコンテナについての性能劣化を管理し、
   最も利用率の低い前記コンテナについての前記性能劣化が所定値よりも小さい場合に、前記利用率が最も低く、かつ、前記性能劣化が前記所定値よりも小さいリソースを前記第１所定リソースとして選択する、
   請求項３に記載のリソース管理システム。
10. 情報処理システムのリソースを管理コンピュータを用いて管理する方法であって、
    前記情報処理システムは、前記リソースを提供する複数の物理計算機と、少なくとも一つのアプリケーションプログラムを実行する複数の仮想計算機と、前記複数の物理計算機および前記複数の仮想計算機に通信可能に接続される管理コンピュータとを有し、
    前記管理コンピュータは、
    対応付けられる前記リソースの一部を管理し仮想リソースとして提供する複数のコンテナを予め用意し、
    前記提供される仮想リソースの利用範囲を定義するリソース区画を管理し、
    前記コンテナは前記アプリケーションプログラムの何れかに対応づけられており、
    前記リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられる前記コンテナに他のコンテナで管理される前記リソースを移行し、前記他のコンテナの管理する前記リソース量は前記他のコンテナの提供する前記仮想リソースより少なくなることがある、
    リソース管理方法。
11. 前記管理コンピュータは、前記複数のリソース区画のうち第１のリソース区画に提供する第１のコンテナに対応付けられている前記リソースの一部である第１所定リソースを、前記複数のリソース区画のうち第２のリソース区画に提供する第２のコンテナに対応付けることで、前記第１所定リソースの所属先を前記第２リソース区画に移す、請求項１０に記載のリソース管理方法。
12. コンピュータを、情報処理システムのリソースを管理するための管理コンピュータとして機能させるためのコンピュータプログラムであって、
    前記情報処理システムは、所定リソースを提供する複数の物理計算機と、少なくとも一つのアプリケーションプログラムを実行する複数の仮想計算機と、前記複数の物理計算機および前記複数の仮想計算機に通信可能に接続される管理コンピュータとを有し、
    前記コンピュータに、対応付けられる前記リソースの一部を管理し仮想リソースとして提供する複数のコンテナを予め用意し、
    前記提供される仮想リソースの利用範囲を定義するリソース区画を管理し、
    前記コンテナは前記アプリケーションプログラムの何れかに対応づけられており、
    前記リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられる前記コンテナに他のコンテナで管理される前記リソースを移行し、前記他のコンテナの管理する前記リソース量は前記他のコンテナの提供する前記仮想リソースより少なくなることがある、
    コンピュータプログラム。
13. 前記コンピュータプログラムは、前記コンピュータに、前記複数のリソース区画のうち第１のリソース区画に提供する第１のコンテナに対応付けられている前記リソースの一部である第１所定リソースを、前記複数のリソース区画のうち第２のリソース区画に提供する第２のコンテナに対応付けることで、前記第１所定リソースの所属先を前記第２仮想リソースに移させる、請求項１２に記載のコンピュータプログラム。

Images