JP7163341B2 - 計算機システム及び計算機システムの制御方法 - Google Patents

Description

本発明は、計算機システム及び計算機システムの制御方法に関する。

複数の物理計算機から構成され、各々の物理計算機ではコンピューティングサービスとストレージサービスとの両方が稼働するハイパーコンバージドインフラストラクチャ（Hyper Converged Infrastructure：ＨＣＩ）がある。

ハイパーコンバージドインフラストラクチャの構成において、コンテナコンピューティングサービスは、物理計算機で稼働するコンテナ基盤上のコンテナとして稼働する場合、物理計算機で稼働するハイパーバイザ上の仮想計算機として稼働する場合がある。ここで、コンピューティングサービスを行うコンテナ、仮想計算機をアプリケーションインスタンスと呼ぶ。

また、ハイパーコンバージドインフラストラクチャの構成において、ストレージサービスは、物理計算機上で稼働するホストＯＳやハイパーバイザ上のプロセスとして稼働する場合、物理計算機で稼働するコンテナ基盤上のコンテナとして稼働する場合、物理計算機で稼働するハイパーバイザ上の仮想計算機として稼働する場合がある。ここで、ストレージサービスを行うプロセス、コンテナもしくは仮想計算機をストレージサービスインスタンスと呼ぶ。ストレージサービスインスタンスは、アプリケーションインスタンスに対してボリュームを提供する。

ハイパーコンバージドインフラストラクチャでは、ある物理計算機やあるストレージサービスインスタンスでリソース不足が発生することがある。リソース不足が発生した場合、アプリケーションインスタンスを別の物理計算機に移動したり、ストレージサービスインスタンスがサービスするボリュームを別の物理計算機で稼働するストレージサービスインスタンスに移動したりすることで、そのリソース不足を解消する。

特許文献１では、仮想計算機（ＶＭ）を物理計算機間でマイグレーションすることでコンピューティングサービスの負荷バランスを行う実施例が開示されている。また、特許文献２では、仮想計算機（ＶＭ）が利用するディスクイメージ（仮想計算機にとってのボリュームに相当）をＬＵＮ間でマイグレーションすることでストレージサービスの負荷バランスを行う実施例が開示されている。

米国特許８，０９５，９２９号明細書 米国特許８，９３５，５００号明細書

ハイパーコンバージドインフラストラクチャの構成において、特許文献１に記載された技術を用いれば、仮想計算機が稼働し、仮想計算機が利用するディスクイメージ（仮想計算機にとってのボリュームに相当）のサービスが行われる物理計算機から、仮想計算機を異なる物理計算機に移動させることができる。

ハイパーコンバージドインフラストラクチャの構成において、特許文献２に記載された技術を用いれば、仮想計算機が稼働し、仮想計算機が利用するディスクイメージのサービスが行われる物理計算機から、ディスクイメージとそのサービスを異なる物理計算機に移動させることができる。

しかしながら、物理計算機のリソース不足を解消する手段としてアプリケーションインスタンスの移動を選択すると、アプリケーションインスタンスが利用しているボリュームのサービスを行う物理計算機とは別の物理計算機にアプリケーションインスタンスが配置されることで、ストレージサービスのための物理計算機間の通信が増加し、全体の処理効率を低下させてしまう。処理効率を落とさないために、アプリケーションインスタンスが利用しているボリュームを、アプリケーションインスタンスの移動先の物理計算機に移動させると、ボリューム移動を実行している期間、さらなるリソース不足を発生させてしまう。

また、ストレージサービスインスタンスのリソース不足を解消する手段としてボリュームの移動を選択すると、こちらも同様にボリューム移動を実行している期間、さらなるリソース不足を発生させてしまう。つまり、全体の処理効率を低下させず、ボリューム移動によるさらなるリソース不足の低減の両立が課題である。

本発明は上記を考慮してなされたものであって、ストレージサービスとアプリケーションが動作する複数の物理計算機を含んで構成された計算機システムにおいて、効率的かつ短時間にリソース不足を解消し得るようにすることを目的とする。

上記課題を解決するため、本発明では、第一の物理計算機及び第二の物理計算機を含む複数の物理計算機から構成される計算機システムであって、前記第一の物理計算機では、アプリケーションサービスを行う１つ以上のアプリケーションインスタンスと、前記アプリケーションインスタンスが使用するボリュームを含むストレージサービスを提供するストレージサービスインスタンスと、が動作し、前記計算機システムは、前記第一の物理計算機の将来のリソース使用状況を予測し、前記予測した将来のリソース使用状況に基づいて、前記第一の物理計算機上で動作する前記アプリケーションインスタンスの１つ以上を前記第二の物理計算機に移動する計画を作成し、作成した計画を実行する、ことを特徴とする。

本発明によれば、ストレージサービスとアプリケーションが動作する複数の物理計算機を含んで構成された計算機システムにおいて、効率的かつ短時間にリソース不足を解消できる。

図１は、一実施形態に係る計算機システムの全体構成図である。 図２は、一実施形態に係るクラスタ用計算機またはクラスタ管理用計算機のハードウェア構成図である。 図３は、一実施形態に係るクラスタ管理用計算機のメモリの構成図である。 図４は、一実施形態に係るクラスタ用計算機のメモリの構成図である。 図５は、一実施形態に係るボリューム配置管理テーブルの構成図である。 図６は、一実施形態に係るアプリケーションコンテナ配置管理テーブルの構成図である。 図７は、一実施形態に係るストレージサービスコンテナ配置管理テーブルの構成図である。 図８は、一実施形態に係るボリューム性能容量管理テーブルの構成図である。 図９は、一実施形態に係るアプリケーションコンテナ性能管理テーブルの構成図である。 図１０は、一実施形態に係るストレージサービスコンテナ性能容量管理テーブルの構成図である。 図１１は、一実施形態に係るクラスタ用計算機性能容量管理テーブルの構成図である。 図１２は、一実施形態に係るリソース不足解消計画テーブルの構成図である。 図１３は、一実施形態に係る稼働状態収集処理のフローチャートである。 図１４は、一実施形態に係るリソース使用量予測処理のフローチャートである。 図１５は、一実施形態に係るリソース不足解消計画処理のフローチャートである。 図１６は、一実施形態に係る特定リソース不足解消計画処理のフローチャートである。 図１７は、一実施形態に係るストレージサービスコンテナ向け特定リソース不足解消計画処理のフローチャートである。 図１８は、一実施形態に係るマイグレーション計画処理のフローチャートである。 図１９は、一実施形態に係るアプリケーションコンテナマイグレーション計画処理のフローチャートである。 図２０は、一実施形態に係るアプリケーションコンテナ・ボリュームマイグレーション計画処理のフローチャートである。 図２１は、一実施形態に係る移動先探索・悪影響評価処理のフローチャートである。 図２２は、一実施形態に係る計画実行指示処理のフローチャートである。 図２３は、他の一実施形態に係るリソース不足解消計画処理のフローチャートである。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

以下の説明では、「ＡＡＡテーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ＡＡＡテーブル」を「ＡＡＡ情報」と呼ぶことができる。

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）である。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明では、「プログラム」を動作の主体として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェース装置（例えばポート）を用いながら行うため、処理の主体がプロセッサとされてもよい。プログラムを動作の主体として説明された処理は、プロセッサを含む装置が行う処理としてもよい。また、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでもよい。コンピュータプログラムは、プログラムソースから装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ、又は、計算機が読み取り可能な記憶メディアであってもよい。

また、以下の説明では、「コンテナ」を管理対象として説明する場合があるが、コンテナの代わりに、物理計算機のハードウェアをエミュレートする仮想化方式である「仮想計算機（ＶＭ）」や物理計算機そのものである「ベアメタル」が管理対象であってもよい。

［実施形態］
本実施形態は、複数の計算機から構成される計算機システム上にコンピューティングサービスとストレージサービスとが動作するハイパーコンバージドインフラストラクチャであって、ハイパーコンバージドインフラストラクチャ（ＨＣＩ）の構成要素である計算機のリソース不足を解消する技術に関する。

まず、本発明の一実施形態に係る計算機システム１００について説明する。図１は、一実施形態に係る計算機システム１００の全体構成図である。

計算機システム１００は、クラスタ管理用計算機１０１と、一台以上のクラスタ用計算機１０２と、管理用端末１０３と、それらを接続するネットワーク１０４とを備える。

クラスタ用計算機１０２には、１つ以上のアプリケーションコンテナ１１０、ストレージサービスコンテナ１１１、コンテナ管理基盤１１２が稼働している。これら計算機システムによりハイパーコンバージドインフラストラクチャのサービスが実現される。

図１に示す計算機システム１００では、クラスタ管理用計算機１０１とクラスタ用計算機１０２とが別に構成されている例を示しているが、クラスタ管理用計算機１０１とクラスタ用計算機１０２とを一つのベアメタル（物理計算機）を用いて構成してもよい。例えば、クラスタ管理用計算機１０１は仮想計算機の形態であってもよく、コンテナ仮想化技術により構成されたコンテナの形態であってもよい。また、クラスタ管理用計算機１０１は必ずしも独立した装置である必要はなく、その機能をクラスタ用計算機１０２のいずれかに内包してもよい。

ストレージサービスコンテナ１１１は、アプリケーションコンテナ１１０に対してボリュームサービスを提供する、ストレージサービスインスタンスの一例である。なお、図１のストレージサービスコンテナ１１１は、独立したＯＳ空間を模擬するコンテナ基盤上で動作する単一のコンテナで構成されているが、物理計算機のハードウェアをエミュレートするハイパーバイザ上で動作する仮想計算機（ＶＭ）の形態であってもよいし、ベアメタルのハイパーバイザやホストＯＳ上で動作するストレージサービスの形態であってもよい。また複数のコンテナや複数の仮想計算機でストレージサービスを提供する形態であってもよい。

アプリケーションコンテナ１１０は、ハイパーコンバージドインフラの利用者が利用するコンテナであり、アプリケーションサービスインスタンスの一例である。アプリケーションコンテナ１１０は、仮想計算機（ＶＭ）の形態であってもよいし、ベアメタルのハイパーバイザやホストＯＳ上で動作するアプリケーションの形態であってもよい。

コンテナ管理基盤１１２はアプリケーションコンテナ１１０とストレージサービスコンテナ１１１を管理する。ストレージサービスとアプリケーションの動作形態に応じて、コンテナ管理基盤１１２は仮想計算機（ＶＭ）管理基盤の形態やベアメタル管理基盤の形態であってもよい。

次に、クラスタ管理用計算機１０１と、クラスタ用計算機１０２とのハードウェアの構成について説明する。図２は、一実施形態に係るクラスタ管理用計算機１０１及びクラスタ用計算機１０２のハードウェア構成図である。本実施形態では、クラスタ管理用計算機１０１とクラスタ用計算機１０２とのハードウェアの基本的な構成は同じである。以下、クラスタ管理用計算機１０１を単に計算機１０１、クラスタ用計算機１０２を単に計算機１０２という場合がある。

計算機１０１（１０２）は、例えば、ＰＣやサーバ等の計算機によって構成され、プロセッサ部の一例としてのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、メモリ２０２、ＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）２０３、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｆｅｒｆａｃｅ Ｃａｒｄ）２０４、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）２０５、ＶＧＡ（Ｖｉｄｅｏ Ｇｒａｐｈｉｃｓ Ａｒｒａｙ）２０６、及びストレージデバイスを含む。これら構成要素は、内部バスや外部バスで接続されている。ストレージデバイスとしては、例えば、ＮＶＭｅ（Ｎｏｎ－Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ ｅｘｐｒｅｓｓ）ドライブ２０７、ＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ）ドライブ２０８、ＳＡＴＡ（Ｓｅｒｉａｌ ＡＴＡ）ドライブ２０９等や、ＨＢＡ２０３で接続された図示しない外部ドライブなどがある。

次に、クラスタ管理用計算機１０１のメモリ２０２（２０２Ａ）の構成について説明する。図３は、一実施形態に係るクラスタ管理用計算機のメモリ２０２（２０２Ａ）の構成図である。

クラスタ管理用計算機１０１のメモリ２０２（２０２Ａ）は、稼働状態収集プログラム３０１、リソース使用量予測プログラム３０２、リソース不足解消計画プログラム３０３、及び計画実行指示プログラム３０４を記憶する。また、メモリ２０２Ａは、ボリューム配置管理テーブル３１１、アプリケーションコンテナ配置管理テーブル３１２、ストレージサービスコンテナ配置管理テーブル３１３、ボリューム性能容量管理テーブル３２１、アプリケーションコンテナ性能管理テーブル３２２、ストレージサービスコンテナ性能容量管理テーブル３２３、クラスタ用計算機性能容量管理テーブル３２４、及びリソース不足解消計画テーブル３３１を記憶する。また、メモリ２０２Ａは、図示しない、その他クラスタ管理を実現するためのプログラムやテーブルを記憶している。

次に、クラスタ用計算機１０２のメモリ２０２（２０２Ｂ）の構成について説明する。図４は、一実施形態に係るクラスタ用計算機のメモリ２０２（２０２Ｂ）の構成図である。クラスタ用計算機１０２のメモリ２０２（２０２Ｂ）は、コンテナ管理基盤用メモリ領域４０１、ストレージサービスコンテナ用メモリ領域４２０、アプリケーションコンテナ用メモリ領域４３０から構成される。

コンテナ管理基盤用メモリ領域４０１は、コンテナ移動プログラム４１１、コンテナ使用可能リソース制御プログラム４１２を記憶する。また、ストレージサービスコンテナ用メモリ領域４２０は、ボリューム移動プログラム４２１、ストレージ制御リソース制御プログラム４２２を記憶する。また、アプリケーションコンテナ用メモリ領域４３０は、１つ以上のアプリケーションプログラム４３１を記憶する。また、メモリ２０２Ｂは、図示しない、その他ハイパーコンバージドインフラストラクチャに必要な各種サービスを実現するためのプログラムやテーブルを記憶している。

次に、ボリューム配置管理テーブル３１１の構成について説明する。図５は、一実施形態に係るボリューム配置管理テーブル３１１の構成図である。ボリューム配置管理テーブル３１１は、アプリケーションコンテナに提供するボリュームがどのストレージサービスコンテナによって提供されているかを示す。ここで、ボリュームは、１つ以上のストレージデバイスの領域から構成され、ｉＳＣＳＩ、ＮＦＳ、ＮＶＭｅ－ｏＦ、ＳＣＳＩなどのストレージプロトコルによって、ストレージサービスコンテナ１１１からアプリケーションコンテナ１１０に提供される。

ボリューム配置管理テーブル３１１は、ボリュームに対応する行を格納する。各行は、列として、ボリューム番号５０１、及びストレージサービスコンテナ番号５０２の項目を含む。

ボリューム番号５０１には、ボリュームを特定する情報が格納される。例えば、ＬＵＮ（Ｌｏｇｉａｃｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）が格納される。ストレージサービスコンテナ番号５０２には、そのボリュームをサービスしているストレージサービスコンテナを特定する情報が格納される。例えば、シリアル番号、ＩＰアドレスなどが格納される。

次に、アプリケーションコンテナ配置管理テーブル３１２の構成について説明する。図６は、一実施形態に係るアプリケーションコンテナ配置管理テーブル３１２の構成図である。

アプリケーションコンテナ配置管理テーブル３１２は、アプリケーションコンテナ１１０に対応する行を格納する。各行は、列として、アプリケーションコンテナ番号６０１、及びクラスタ用計算機番号６０２の項目を含む。

アプリケーションコンテナ番号６０１には、アプリケーションコンテナ１１０が特定する情報が格納される。例えば、シリアル番号、ＩＰアドレスなどが格納される。クラスタ用計算機番号６０２には、そのアプリケーションコンテナが稼働するクラスタ用計算機１０２を特定する情報が格納される。例えば、シリアル番号、ＩＰアドレスなどが格納される。

次に、ストレージサービスコンテナ配置管理テーブル３１３の構成について説明する。図７は、一実施形態に係るストレージサービスコンテナ配置管理テーブル３１３の構成図である。

ストレージサービスコンテナ配置管理テーブル３１３は、ストレージサービスコンテナ１１１に対応する行を格納する。各行は、列として、ストレージサービスコンテナ番号７０１、及びクラスタ用計算機番号７０２の項目を含む。

ストレージサービスコンテナ番号７０１には、ストレージサービスコンテナ１１１を特定する情報が格納される。例えば、シリアル番号、ＩＰアドレスなどが格納される。クラスタ用計算機番号７０２には、そのストレージサービスコンテナ１１１が稼働するクラスタ用計算機１０２を特定する情報が格納される。例えば、シリアル番号、ＩＰアドレスなどが格納される。

次に、ボリューム性能容量管理テーブル３２１の構成について説明する。図８は、ボリューム性能容量管理テーブル３２１の構成図である。

ボリューム性能容量管理テーブル３２１は、ボリュームに対応する行を格納する。各行は、列として、ボリューム番号８０１、ＩＯＰＳ８０２、ＴｒａｎｓｆｅｒＲａｔｅ８０３、及びストレージ容量利用量８０４の項目を含む。

ボリューム番号８０１には、ボリュームを特定する情報が格納される。ＩＯＰＳ８０２には、そのボリュームに対する単位時間当たりのＩＯ数の情報が、ＲｅａｄとＷｒｉｔｅのそれぞれに格納される。ＴｒａｎｓｆｅｒＲａｔｅ８０３には、そのボリュームに対する単位時間当たりのデータ転送量の情報が、ＲｅａｄとＷｒｉｔｅのそれぞれに格納される。ストレージ容量利用量８０４には、そのボリュームに対するストレージ容量の利用量が格納される。各利用量は時間と共に変化するため、ＩＯＰＳ８０２、ＴｒａｎｓｆｅｒＲａｔｅ８０３、及びストレージ容量利用量８０４は、一定時間ごとに新たな情報として格納される。

また、ここではＩＯ性能の指標を格納しているが、ストレージサービスコンテナ１１１においてサービスのためにそのボリュームが消費するＣＰＵ量や、メモリ量を格納してもよい。

図９は、一実施形態に係るアプリケーションコンテナ性能管理テーブル３２２の構成図である。

アプリケーションコンテナ性能管理テーブル３２２は、アプリケーションコンテナ１１０に対応する行を格納する。各行は、列として、アプリケーションコンテナ番号９０１、ＣＰＵ９０２、メモリ９０３、及びネットワーク帯域９０４の項目を含む。

アプリケーションコンテナ番号９０１には、アプリケーションコンテナ１１０を特定する情報が格納される。ＣＰＵ９０２には、そのアプリケーションコンテナに対するＣＰＵの利用量と定義量が格納される。ここでＣＰＵの定義量とはそのアプリケーションコンテナ１１０が利用できるＣＰＵの利用量の最大値である。

メモリ９０３には、そのアプリケーションコンテナ１１０に対するメモリの利用量と定義量が格納される。ここでメモリの定義量とはそのアプリケーションコンテナが利用できるメモリの利用量の最大値である。ネットワーク帯域９０４には、そのアプリケーションコンテナ１１０に対するネットワーク帯域の利用量と定義量が格納される。ここでネットワーク帯域の定義量とはそのアプリケーションコンテナ１１０が利用できるネットワーク帯域の利用量の最大値である。また、ネットワーク帯域９０４には送信と受信の情報がそれぞれ格納される。

各利用量は時間と共に変化するため、ＣＰＵ９０２の利用量、メモリ９０３の利用量、及びネットワーク帯域９０４の送信と受信の利用量は、一定時間ごとに新たな情報として格納される。

図１０は、一実施形態に係るストレージサービスコンテナ性能容量管理テーブル３２３の構成図である。ストレージサービスコンテナ性能容量管理テーブル３２３は、ストレージサービスコンテナ１１１に対応する行を格納する。各行は、列として、ストレージサービスコンテナ番号１００１、ＣＰＵ１００２、メモリ１００３、ネットワーク帯域１００４、及びストレージ容量１００５の項目を含む。

ストレージサービスコンテナ番号１００１には、ストレージサービスコンテナ１１１を特定する情報が格納される。ＣＰＵ１００２には、そのストレージサービスコンテナ１１１に対するＣＰＵの利用量と定義量が格納される。ここでＣＰＵの定義量とはそのストレージサービスコンテナが利用できるＣＰＵの利用量の最大値である。

メモリ１００３には、そのストレージサービスコンテナ１１１に対するメモリの利用量と定義量が格納される。ここでメモリの定義量とはそのストレージサービスコンテナ１１１が利用できるメモリの利用量の最大値である。ネットワーク帯域１００４には、そのストレージサービスコンテナ１１１に対するネットワーク帯域の利用量と定義量が格納される。ここでネットワーク帯域の定義量とはそのストレージサービスコンテナ１１１が利用できるネットワーク帯域の利用量の最大値である。

また、ネットワーク帯域１００４には送信と受信の情報がそれぞれ格納される。ストレージ容量１００５には、そのストレージサービスコンテナ１１１に対するストレージ容量の利用量と定義量が格納される。ここでストレージ容量の定義量とはそのストレージサービスコンテナが利用できるストレージ容量の最大値である。

各利用量は時間と共に変化するため、ＣＰＵ１００２の利用量、メモリ１００３の利用量、ネットワーク帯域１００４の送信と受信の利用量、及びストレージ容量１００５の利用量は、一定時間ごとに新たな情報として格納される。

図１１は、一実施形態に係るクラスタ用計算機性能容量管理テーブル３２４の構成図である。クラスタ用計算機性能容量管理テーブル３２４は、クラスタ用計算機１０２に対応する行を格納する。各行は、列として、クラスタ用計算機番号１１０１、ＣＰＵ１１０２、メモリ１１０３、ネットワーク帯域１１０４、及びストレージ容量１１０５の項目を含む。

クラスタ用計算機番号１１０１には、クラスタ用計算機１０２を特定する情報が格納される。ＣＰＵ１１０２には、そのクラスタ用計算機に対するＣＰＵの利用量と定義量が格納される。ここでＣＰＵの定義量とはそのクラスタ用計算機１０２が利用できるＣＰＵの利用量の最大値である。メモリ１１０３には、そのクラスタ用計算機１０２に対するメモリの利用量と定義量が格納される。ここでメモリの定義量とはそのクラスタ用計算機が利用できるメモリの利用量の最大値である。

ネットワーク帯域１１０４には、そのクラスタ用計算機１０２に対するネットワーク帯域の利用量と定義量が格納される。ここでネットワーク帯域の定義量とはそのクラスタ用計算機が利用できるネットワーク帯域の利用量の最大値である。また、ネットワーク帯域１１０４には送信と受信の情報がそれぞれ格納される。ストレージ容量１１０５には、そのクラスタ用計算機に対するストレージ容量の利用量と定義量が格納される。ここでストレージ容量の定義量とはそのクラスタ用計算機が利用できるストレージ容量の最大値である。

各利用量は時間と共に変化するため、ＣＰＵ１１０２の利用量、メモリ１１０３の利用量、ネットワーク帯域１１０４の送信と受信の利用量、及びストレージ容量１１０５の利用量は、一定時間ごとに新たな情報として格納される。

図１２は、一実施形態に係るリソース不足解消計画テーブル３１１の構成図である。リソース不足解消計画テーブル３３１は、リソース不足解消計画に対応する行を格納する。各行は、列として、計画管理番号１２０１、対象オブジェクト種別１２０２、オブジェクト番号１２０３、アクション種別１２０４、及びアクション内容１２０５の項目を含む。

計画管理番号１２０１には、リソース不足解消計画を特定する情報が格納される。対象オブジェクト種別１２０２には、そのリソース不足解消計画の対象オブジェクトの種別に関する情報が格納される。対象オブジェクトの例としては、ストレージサービスコンテナ、ボリューム、アプリケーションコンテナがある。

オブジェクト番号１２０３には、対象オブジェクトを特定する番号が格納される。アクション種別１２０４には、対象オブジェクトに対して計画するアクションの種類の情報が格納される。アクション内容１２０５には、対象オブジェクトに対するアクションの計画内容が格納される。

例えば、計画管理番号１は、２番のストレージサービスコンテナのＣＰＵの定義量に２０ＧＨｚ追加するという計画である。計画管理番号２は、３番のボリュームを、２番のストレージサービスコンテナに移動するという計画である。計画管理番号３は、２番のアプリケーションコンテナを、２番のクラスタ用計算機に移動するという計画である。

次に、本実施形態に係る計算機システム１００の処理動作について説明する。

まず、稼働状態収集処理について説明する。

図１３は、一実施形態に係る稼働状態収集処理Ｓ１３００のフローチャートである。稼働状態収集処理Ｓ１３００は、クラスタ管理用計算機１０１の稼働状態収集プログラム３０１によって実行される。稼働状態収集プログラム３０１は管理用端末１０３などを経由して管理者から実行される。

先ず、稼働状態収集プログラム３０１は、ボリューム性能容量管理テーブル３２１からボリュームの性能容量情報を取得する（Ｓ１３１０）。

次に、稼働状態収集プログラム３０１は、アプリケーションコンテナ性能管理テーブル３２２からアプリケーションコンテナの性能情報を取得する（Ｓ１３２０）。

次に、稼働状態収集プログラム３０１は、ストレージサービスコンテナ性能容量管理テーブル３２３からストレージサービスコンテナの性能容量情報を取得する（Ｓ１３３０）。

次に、稼働状態収集プログラム３０１は、クラスタ用計算機性能容量管理テーブル３２４からクラスタ用計算機の性能容量情報を取得し（Ｓ１３４０）、稼働状態収集処理を終了する。

なお、本フローチャートで用いる各種テーブルには別のプログラムによって既に時系列の性能容量情報が格納されている。

次に、リソース使用量予測処理Ｓ１４００について説明する。

図１４は、一実施形態に係るリソース使用量予測処理Ｓ１４００のフローチャートである。リソース使用量予測処理Ｓ１４００は、クラスタ管理用計算機１０１のリソース使用量予測プログラム３０２によって実行される。リソース使用量予測プログラム３０２は管理用端末１０３などを経由して管理者から実行される。

リソース使用量予測処理Ｓ１４００では、リソース使用量予測プログラム３０２は、まずオブジェクト種別でのループを開始する（Ｓ１４１０）。ここで、オブジェクト種別とはボリューム、アプリケーションコンテナ、ストレージサービスコンテナ、クラスタ用計算機の４種である。

次に、リソース使用量予測プログラム３０２は、Ｓ１４１０で指定されたオブジェクトの稼働情報から各リソース使用量を予測する（Ｓ１４２０）。ここで、各リソース使用量とは、ＣＰＵ、メモリ、ネットワーク帯域、ストレージ容量である。ボリューム性能容量管理テーブル３２１が、ＩＯＰＳ、ＴｒａｎｓｆｅｒＲａｔｅの形式で格納されている場合は、予測データをＣＰＵ、メモリ、ネットワーク帯域の形式に換算する。

リソース使用量予測プログラム３０２は、全てのオブジェクト種別に対して処理を行い、ループ処理を終了する（Ｓ１４３０）。

次に、リソース使用量予測プログラム３０２は、予測期間内にＣＰＵ、メモリ、ネットワーク帯域、ストレージ容量の観点でリソース不足になる見込みのストレージサービスコンテナ１１１を抽出する（Ｓ１４４０）。

次に、リソース使用量予測プログラム３０２は、予測期間内にＣＰＵ、メモリ、ネットワーク帯域、ストレージ容量の観点でリソース不足になる見込みのクラスタ用計算機１０２を抽出し（Ｓ１４５０）、リソース使用量予測処理Ｓ１４００を終了する。

次に、リソース不足解消計画処理Ｓ１５００について説明する。

図１５は、一実施形態に係るリソース不足解消計画処理Ｓ１５００のフローチャートである。リソース不足解消計画処理Ｓ１５００は、クラスタ管理用計算機１０１のリソース不足解消計画プログラム３０３によって実行される。リソース不足解消計画プログラム３０３は管理用端末１０３などを経由して管理者から実行される。

リソース不足解消計画処理Ｓ１５００では、リソース不足解消計画プログラム３０３は、まずリソース種別でのループを開始する（Ｓ１５１０）。ここで、リソース種別とはＣＰＵ、メモリ、ネットワーク帯域、ストレージ容量の４種である。

次に、リソース不足解消計画プログラム３０３は、Ｓ１５１０で指定されたリソースを設定し（Ｓ１５２０）、特定リソース不足解消計画処理（Ｓ１６００）を呼び出す。特定リソース不足解消計画処理Ｓ１５１０の詳細は後に説明する。

リソース不足解消計画プログラム３０３は、全てのリソース種別に対して処理を行い、ループ処理を終了する（Ｓ１５４０）。以上で、リソース不足解消計画処理Ｓ１５００を終了する。

次に、特定リソース不足解消計画処理Ｓ１６００について説明する。

図１６は、一実施形態に係る特定リソース不足解消計画処理Ｓ１６００のフローチャートである。特定リソース不足解消計画処理Ｓ１６００は、クラスタ管理用計算機１０１のリソース不足解消計画プログラム３０３によって実行されるリソース不足解消計画処理（Ｓ１５００）から呼び出されることによって実行される。リソース不足解消計画プログラム３０３は管理用端末１０３などを経由して管理者から実行される。

特定リソース不足解消計画処理では、リソース不足解消計画プログラム３０３は、まずリソース使用量予測処理（Ｓ１４００）によって得られたリソース不足になる見込みのストレージサービスコンテナ１１１のリストでのループを開始する（Ｓ１６１０）。

次に、リソース不足解消計画プログラム３０３は、Ｓ１６１０で指定されたリソースと指定されたストレージサービスコンテナ１１１についてストレージサービスコンテナ向け特定リソース不足解消計画処理を呼び出す（Ｓ１７００）。ストレージサービスコンテナ向け特定リソース不足解消計画処理Ｓ１７００の詳細は後に説明する。

リソース不足解消計画プログラム３０３は、全てのリソース不足になる見込みのストレージサービスコンテナに対して処理を行い、ループ処理を終了する（Ｓ１６２０）。

次に、リソース不足解消計画プログラム３０３は、リソース使用量予測処理（Ｓ１４５０）によって得られたリソース不足になる見込みのクラスタ用計算機１０２のリストでのループを開始する（Ｓ１６３０）。

次に、リソース不足解消計画プログラム３０３は、Ｓ１６３０で指定されたリソースと指定されたクラスタ用計算機１０２についてマイグレーション計画処理を呼び出す（Ｓ１８００）。マイグレーション計画処理Ｓ１８００の詳細は後に説明する。

リソース不足解消計画プログラム３０３は、全てのリソース不足になる見込みのクラスタ用計算機に対して処理を行い、ループ処理を終了する（Ｓ１６４０）。以上で、特定リソース不足解消計画処理Ｓ１６００を終了する。

次に、ストレージサービスコンテナ向け特定リソース不足解消計画処理Ｓ１７００について説明する。

図１７は、ストレージサービスコンテナ向け特定リソース不足解消計画処理Ｓ１７００のフローチャートである。ストレージサービスコンテナ向け特定リソース不足解消計画処理Ｓ１７００は、クラスタ管理用計算機１０１のリソース不足解消計画プログラム３０３によって実行される特定リソース不足解消計画処理（Ｓ１６００）から呼び出されることによって実行される。リソース不足解消計画プログラム３０３は管理用端末１０３などを経由して管理者から実行される。

ストレージサービスコンテナ向け特定リソース不足解消計画処理Ｓ１７００では、リソース不足解消計画プログラム３０３は、まず指定されたリソースの定義量が変更可能であるかどうかを確認する（Ｓ１７１０）。リソースの定義量が変更可能であるのは、例えば稼働するコンテナのリソース利用可能量を変更できる、稼働するコンテナの数を変更できるなどがある。ストレージサービスを実現するのが仮想計算機（ＶＭ）の場合は、稼働する仮想計算機のリソース利用可能量を変更できる、稼働する仮想計算機の数を変更できるなどがある。ストレージサービスを実現するのがベアメタルの場合、稼働するサービスのプロセスのリソース利用可能量を変更できる、稼働するサービスのプロセスの数を変更できるなどがある。

定義量が変更可能な場合（Ｓ１７１０：Ｙｅｓ）、リソース不足解消計画プログラム３０３は、指定されたリソースの定義量を増加する計画を追加する（Ｓ１７２０）。定義量が変更できない場合（Ｓ１７１０：Ｎｏ）、Ｓ１７２０の処理はスキップする。

次に、リソース不足解消計画プログラム３０３は、これまでの処理によってリソース不足が解消される見込みかどうかを確認する（Ｓ１７３０）。解消される見込みの場合（Ｓ１７３０：Ｙｅｓ）、リソース不足解消計画プログラム３０３は、ストレージサービスコンテナ向け特定リソース不足解消計画処理を終了する。解消されない見込みの場合（Ｓ１７３０：Ｎｏ）、リソース不足解消計画プログラム３０３は、マイグレーション計画処理を呼び出す（Ｓ１８００）。マイグレーション計画処理の詳細は後に説明する。以上で、ストレージサービスコンテナ向け特定リソース不足解消計画処理を終了する。

次に、マイグレーション計画処理Ｓ１８００について説明する。

図１８は、マイグレーション計画処理Ｓ１８００のフローチャートである。マイグレーション計画処理Ｓ１８００は、クラスタ管理用計算機１０１のリソース不足解消計画プログラム３０３によって実行される特定リソース不足解消計画処理（Ｓ１６００）もしくはストレージサービスコンテナ向け特定リソース不足解消計画処理（Ｓ１７００）から呼び出されることによって実行される。リソース不足解消計画プログラム３０３は管理用端末１０３などを経由して管理者から実行される。

マイグレーション計画処理Ｓ１８００では、まず、リソース不足解消計画プログラム３０３は、アプリケーションコンテナマイグレーション計画処理を呼び出す（Ｓ１９００）。アプリケーションコンテナマイグレーション計画処理Ｓ１９００の詳細は後に説明する。

次に、リソース不足解消計画プログラム３０３は、これまでの処理によってリソース不足が解消される見込みかどうかを確認する（Ｓ１８１０）。解消される見込みの場合（Ｓ１８１０：Ｙｅｓ）、マイグレーション計画処理Ｓ１８００を終了する。解消されない見込みの場合（Ｓ１８１０：Ｎｏ）、アプリケーションコンテナ・ボリュームマイグレーション計画処理を呼び出す（Ｓ２０００）。アプリケーションコンテナ・ボリュームマイグレーション計画処理Ｓ２０００の詳細は後に説明する。以上で、リソース不足解消計画プログラム３０３は、マイグレーション計画処理Ｓ１８００を終了する。

次に、アプリケーションコンテナマイグレーション計画処理Ｓ１９００について説明する。図１９は、アプリケーションコンテナマイグレーション計画処理Ｓ１９００のフローチャートである。アプリケーションコンテナマイグレーション計画処理Ｓ１９００は、クラスタ管理用計算機１０１のリソース不足解消計画プログラム３０３によって実行されるマイグレーション計画処理（Ｓ１８００）から呼び出されることによって実行される。

先ず、リソース不足解消計画プログラム３０３は、Ｉ／Ｏ要件が重要でないアプリケーションコンテナ１１０を抽出する（Ｓ１９１０）。ここで、Ｉ／Ｏ要件が重要でない条件の例としては、アプリケーションコンテナ１１０が用いているボリュームのＩＯＰＳが一定値以下、アプリケーションコンテナ１１０が用いているボリュームのＴｒａｎｓｆｅｒＲａｔｅが一定値以下、利用者によってＩ／Ｏ要件が重要であると指定されていないなどがある。これらの条件は論理積（ＡＮＤ）である場合もあるし、論理和（ＯＲ）である場合もある。

次に、リソース不足解消計画プログラム３０３は、Ｓ１９１０で抽出したアプリケーションコンテナ１１０のリストを用いて、呼び出し元から指定されたリソースのリソース使用量の降順でループ処理を開始する（Ｓ１９２０）。リソース不足解消計画プログラム３０３は、ループ処理において、Ｓ１９１０で抽出された対象のアプリケーションコンテナ１１０について、移動先探索・悪影響評価処理（Ｓ２１００）を呼び出す。移動先探索・悪影響評価処理Ｓ２１００の詳細は後に説明する。

リソース不足解消計画プログラム３０３は、Ｓ１９１０で抽出した全てのアプリケーションコンテナ１１０に対して移動先探索・悪影響評価処理Ｓ２１００を行うか、リソース不足が解消するかの条件で、ループ処理を終了する（Ｓ１９３０）。以上で、リソース不足解消計画プログラム３０３は、アプリケーションコンテナマイグレーション計画処理Ｓ１９００を終了する。

次に、アプリケーションコンテナ・ボリュームマイグレーション計画処理Ｓ２０００について説明する。図２０は、アプリケーションコンテナ・ボリュームマイグレーション計画処理Ｓ２０００のフローチャートである。

アプリケーションコンテナ・ボリュームマイグレーション計画処理Ｓ２０００は、クラスタ管理用計算機１０１のリソース不足解消計画プログラム３０３によって実行されるマイグレーション計画処理（Ｓ１８００）から呼び出されることによって実行される。

まず、リソース不足解消計画プログラム３０３は、アプリケーションコンテナ１１０及びアプリケーションコンテナ１１０が使用しているボリュームのグループのリストを用いて、呼び出し元から指定されたリソースのリソース使用量の降順でループを開始する（Ｓ２０１０）。リソース不足解消計画プログラム３０３は、対象のアプリケーションコンテナ１１０及びボリュームのグループについて、移動先探索・悪影響評価処理（Ｓ２１００）を呼び出す。移動先探索・悪影響評価処理の詳細は後に説明する。

リソース不足解消計画プログラム３０３は、対象の全てのアプリケーションコンテナ１１０及びボリュームのグループに対して処理を行うか、リソース不足が解消するかの条件で、ループ処理を終了する（Ｓ２０２０）。以上で、リソース不足解消計画プログラム３０３は、アプリケーションコンテナ・ボリュームマイグレーション計画処理Ｓ２０００を終了する。

次に、移動先探索・悪影響評価処理Ｓ２１００について説明する。図２１は、移動先探索・悪影響評価処理Ｓ２１００のフローチャートである。移動先探索・悪影響評価処理Ｓ２１００は、クラスタ管理用計算機１０１のリソース不足解消計画プログラム３０３によって実行されるアプリケーションコンテナマイグレーション計画処理（Ｓ１９００）とアプリケーションコンテナ・ボリュームマイグレーション計画処理（Ｓ２０００）から呼び出されることによって実行される。

まず、リソース不足解消計画プログラム３０３は、リストを用いて、呼び出し元から指定されたリソースのリソース使用量の降順でループを開始する（Ｓ２１１０）。なお、Ｓ２１１０で用いるリストは、移動先の対象がクラスタ用計算機１０２の場合はクラスタ用計算機１０２のリスト、移動先の対象がストレージサービスコンテナ１１１の場合はストレージサービスコンテナ１１１のリストである。

次に、リソース不足解消計画プログラム３０３は、対象のクラスタ用計算機１０２もしくはストレージサービスコンテナ１１１に対象のオブジェクト（グループ）を移動させた場合に悪影響がないかを検証する（Ｓ２１２０）。ここで、対象のオブジェクト（グループ）とは、アプリケーションコンテナマイグレーション計画処理（Ｓ１９００）から呼び出された場合はアプリケーションコンテナ１１０であり、アプリケーションコンテナ・ボリュームマイグレーション計画処理（Ｓ２０００）から呼び出された場合はアプリケーションコンテナ・ボリュームのグループである。

悪影響とは、対象のオブジェクト（グループ）を、対象のクラスタ用計算機１０２もしくはストレージサービスコンテナ１１１に移動させた場合に、移動先でなんらかのリソース不足にならないかを検証する（Ｓ２１２０）。これはリソース不足の解消対象のリソース（例えば、ＣＰＵ）だけでなく、すべてのリソース種別（ＣＰＵ、メモリ、ネットワーク帯域、ストレージ容量）について検証する。

悪影響がなかった場合、もしくは悪影響が許容できるレベルであった場合（Ｓ２１３０：Ｎｏ）、リソース不足解消計画プログラム３０３は、対象のオブジェクト（グループ）を対象のクラスタ用計算機１０２もしくは対象のストレージサービスコンテナ１１１に移動する計画を、リソース不足解消計画テーブル３３１に追加する（Ｓ２１４０）。

悪影響があった場合、もしくは悪影響が許容できるレベルでなかった場合（Ｓ２１３０：Ｙｅｓ）、リソース不足解消計画プログラム３０３は、計画の追加処理（Ｓ２１４０）をスキップし、次のクラスタ用計算機１０２もしくはストレージサービスコンテナ１１１を対象とする処理へループ処理を移す。

リソース不足解消計画プログラム３０３は、全てのクラスタ用計算機１０２もしくはストレージサービスコンテナ１１１に対してループ処理を行うか、Ｓ２１４０が実行され計画が追加されるかの条件で、ループ処理を終了する（Ｓ２１５０）。以上で、リソース不足解消計画プログラム３０３は、移動先探索・悪影響評価処理を終了する。

次に、計画実行指示処理Ｓ２２００について説明する。図２２は、計画実行指示処理Ｓ２２００のフローチャートである。計画実行指示処理Ｓ２２００は、クラスタ管理用計算機１０１の計画実行指示プログラム３０４によって実行される。計画実行指示プログラム３０４は管理用端末１０３などを経由して管理者から実行される。

先ず、計画実行指示プログラム３０４は、クラスタ用計算機１０２のリストを用いて、ループ処理を開始する（Ｓ２２１０）。

次に、計画実行指示プログラム３０４は、対象のクラスタ用計算機１０２に関する計画を、対象のクラスタ用計算機１０２に指示する（Ｓ２２２０）。アプリケーションコンテナ１１０を移動させる計画の場合は、計画実行指示プログラム３０４は、対象のクラスタ用計算機１０２のコンテナ移動プログラム４１１を呼び出す。これにより、計画で指定されたアプリケーションコンテナ１１０は、計画で指定されたクラスタ用計算機１０２に移動する。また、ストレージサービスコンテナ１１１のリソース定義量を増加させる計画の場合は、計画実行指示プログラム３０４は、対象のクラスタ用計算機１０２のコンテナ使用可能リソース制御プログラム４１２を呼び出す。これにより、計画で指定されたストレージサービスコンテナ１１１のリソース定義量が増加する。

計画実行指示プログラム３０４は、全てのクラスタ用計算機１０２に対してＳ２２２０の処理を行い、ループ処理を終了する（Ｓ２２３０）。

次に、計画実行指示プログラム３０４は、ストレージサービスコンテナ１１１のリストを用いて、ループ処理を開始する（Ｓ２２４０）。次に、計画実行指示プログラム３０４は、対象のストレージサービスコンテナ１１１に関する計画を、対象のストレージサービスコンテナ１１１に指示する（Ｓ２２５０）。

ボリュームを移動させる計画の場合は、計画実行指示プログラム３０４は、対象のストレージサービスコンテナ１１１のボリューム移動プログラム４２１を呼び出す。これにより、計画で指定されたボリュームは、計画で指定されたストレージサービスコンテナ１１１に移動する。また、ストレージサービスコンテナ１１１のリソース定義量を増加させる計画の場合は、計画実行指示プログラム３０４は、対象のストレージサービスコンテナ１１１のストレージ制御リソース制御プログラム４２２を呼び出す。これにより、対象のストレージサービスコンテナ１１１の利用可能なリソース量が再定義され、再定義されたリソース量に応じてストレージサービス処理が最適化される。最適化の例としては、ストレージ機能が仮想マシンで提供される場合にホットプラグやリソースプール制約などの機能を使って、またはストレージ機能がベアメタルやコンテナで提供される場合にストレージサービスを行うためのワーカープロセスやワーカースレッド、ワーカーコンテナを増加することで、リソース利用上限が動的に拡張される。

計画実行指示プログラム３０４は、全てのストレージサービスコンテナ１１１に対してＳ２２５０の処理を行い、ループ処理を終了する（Ｓ２２６０）。以上で、計画実行指示プログラム３０４は、計画実行指示処理Ｓ２２００を終了する。

本実施形態では、ＳＤＳ（Software Defined Storage）やＨＣＩ構成を取る計算機システムの複数のノードからなるクラスタ内においてリソース不足による高負荷状態が発生した場合に、（Ａ）ストレージサービスコンテナのリソース定義量増加、（Ｂ）アプリケーションコンテナのノード間移動、（Ｃ）アプリケーションコンテナとボリュームのノード間移動の優先順位でアクションを実行する。よって、処理負荷が大きいボリュームマイグレーションを極力実行しないことで、ボリュームの移動量を減らし、ボリューム移動に伴うリソース不足を低減することができる。

このようにして、本実施形態によれば、ストレージサービスを行うコンテナとアプリケーションが動作するコンテナが動作する複数の物理計算機を含んで構成された計算機システムにおいて、デメリットや処理コストをできるだけ抑えるように考慮して効率的かつ短時間にコンテナと物理計算機のリソース不足を解消できる。また、全体の処理効率を低下させず、ボリューム移動によるさらなるリソース不足の低減の両立できる。

また、本実施形態では、Ｉ／Ｏ数やＩ／Ｏ量が少ないアプリケーションを、このアプリケーションが利用するボリュームを提供するストレージサービスが稼働する計算機とは異なる計算機に配置するアクションを実行し、Ｉ／Ｏ数やＩ／Ｏ量が多いアプリケーションを、異なる計算機に配置するアクションを実行しない。これにより、アプリケーションとボリュームが異なる計算機に配置されることで計算機システム全体の処理効率が低下することを抑制できる。

（実施形態の変形例）
なお、本実施形態では、上記（Ａ）（Ｂ）（Ｃ）のアクションに加え、アプリケーションの（Ｄ）リソース定義量増加のアクションを実行してもよい。この場合、（Ｄ）のアクションは、（Ｂ）（Ｃ）のアクションに優先して実行されることで、ボリュームの移動量を減らし、ボリューム移動に伴うリソース不足を低減することができる。

なお、処理コストを低減しつつリソース不足を解消できれば、上記（Ａ）（Ｂ）（Ｃ）（Ｄ）のアクションの実行の優先順位は、上述に限られない。また、上記（Ａ）及び／又は（Ｂ）を実行するとしてもよい。

［その他の実施形態］
上述の実施形態では、ＨＣＩ構成を取る計算機システムの複数のノードからなるクラスタ内においてリソース不足による高負荷状態が発生した場合に、上記（Ａ）（Ｂ）（Ｃ）の優先順位でアクションを実行するとした。

これに対し、整数計画法に基づく所定の最適化問題を解くことで、上述の実施形態のリソース不足解消計画処理（図１５）、特定リソース不足解消計画処理（図１６）、ストレージサービスコンテナ向け特定リソース不足解消計画処理（図１７）などに示す上記（Ａ）（Ｂ）（Ｃ）の優先順位のアクションを、ボリュームの性能評価に応じて精細に行うことができる。制約条件下の最適化問題を解く実施形態を、その他の実施形態として説明する。

先ず、リソース不足を解消するための最適化問題の目的関数と制約条件について説明する。目的関数Ｃ＿ａｌｌ（ｋ）を最小化する最適化問題は数式１のように表される。

目的関数Ｃ＿ａｌｌ（ｋ）の第１項のＣ（０，０，ｋ）は、ストレージサービスコンテナのリソース定義量を変更する処理のコスト値である。第２項のＣ（ｉ，ｊ，ｋ）はｘ＿ｉｊｋのアクションを取る際に必要な処理のコスト値である。ｘ＿０とｘ＿ｉｊｋは０か１を取る変数であり、０のときはそのアクションを取らない、１のときはそのアクションを取ることを意味する。ｘ＿０は、ストレージサービスコンテナの定義リソースを変更するアクションに対応する。本実施形態では、目的関数Ｃ＿ａｌｌ（ｋ）を最小化するｘ＿０とｘ＿ｉｊｋの値を得ることで、計画を策定する。

ここで、数式１、後述の数式２、及び後述の数式３のｉは、あるオブジェクトグループ（アプリケーションコンテナとそのアプリケーションコンテナが使用するボリュームのグループ）を表す番号である。また、数式１、数式２、及び数式３のｊは、あるオブジェクトグループに対するアクションを表す番号である。アクションの例としては、あるオブジェクトグループのアプリケーションコンテナのみ移動する、あるオブジェクトグループのアプリケーションコンテナと全てのボリュームを移動する、あるオブジェクトグループのアプリケーションコンテナと一部のボリュームを移動する、などがある。

あるオブジェクトグループのアプリケーションコンテナのみを移動する場合のアクションのコストは、ＩＯＰＳ、ＴｒａｎｓｆｅｒＲａｔｅが大きい程、値が大きくなり、ＩＯＰＳ、ＴｒａｎｓｆｅｒＲａｔｅが小さい程、値が小さくなる。

また、数式１、数式２、及び数式３のｋは、クラスタ用計算機の番号である。数式１では、目的関数をクラスタ用計算機毎に定義したが、クラスタ全体で一つの目的関数を定義してもよい。

また、数式１の最適化問題の制約条件は、数式２及び数式３のように表される。

数式２のＲ＿ｔａｒｇｅｔ（ｋ，ｌ）は、クラスタ用計算機ｋにおいて、減少したいリソース種別ｌのリソース量である。ここで数式２及び数式３のｌは、対象のリソース種別を表す番号である。リソース種別とは、ＣＰＵ、メモリ、ネットワーク帯域、ストレージ容量である。つまりこの制約条件を満たす解を得ることで、必要なリソース量を減らす計画を策定することができる。

数式３は、あるオブジェクトグループに対するアクションは一つ以下にする意味の制約条件である。

次に、本実施形態のリソース不足解消計画処理を説明する。

図２３は、リソース不足解消計画処理のフローチャートである。リソース不足解消計画処理は、クラスタ管理用計算機１０１のリソース不足解消計画プログラム３０３で実行される。リソース不足解消計画プログラム３０３は管理用端末１０３などを経由して管理者から実行される。

リソース不足解消計画処理では、リソース不足解消計画プログラム３０３は、クラスタ用計算機のリストでループを開始する（Ｓ２４１０）。次に、リソース不足解消計画プログラム３０３は、対象のクラスタ用計算機に関して式（１）の目的関数をソルバーを用いて求解する（Ｓ２４２０）。次に、リソース不足解消計画プログラム３０３は、リソース不足解消計画プログラム３０３解で得られた移動候補のオブジェクト（グループ）のリストでループを開始する（Ｓ２４３０）。

次に、リソース不足解消計画プログラム３０３は、対象のオブジェクト（グループ）について、移動先探索・悪影響評価処理を呼び出す（Ｓ２１００）。リソース不足解消計画プログラム３０３は、全ての移動候補のオブジェクト（グループ）に対して処理を行い、ループ処理を終了し（Ｓ２４４０）、次のクラスタ用計算機について処理を行う。

そして、リソース不足解消計画プログラム３０３は、全てのクラスタ用計算機に対して処理を行い、ループ処理を終了する（Ｓ２４５０）。以上で、リソース不足解消計画処理を終了する。

なお、本発明は、上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。また、上記実施形態において、ＣＰＵが行っていた処理の一部又は全部を、専用のハードウェア回路で行うようにしてもよい。また、上記実施形態におけるプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の非一時的な記憶メディア）であってもよい。

１００…計算機システム、１０１…クラスタ管理用計算機、１０２…クラスタ用計算機、１０３…管理用端末、１０４…ネットワーク、１１０…アプリケーションコンテナ、１１１…ストレージサービスコンテナ、１１２…コンテナ管理基盤、２０１…ＣＰＵ、２０２、２０２Ａ、２０２Ｂ…メモリ

Claims (11)

1. 第一の物理計算機及び第二の物理計算機を含む複数の物理計算機から構成される計算機システムであって、
   前記第一の物理計算機では、
   アプリケーションサービスを行う１つ以上のアプリケーションインスタンスと、前記アプリケーションインスタンスが使用するボリュームを含むストレージサービスを提供するストレージサービスインスタンスと、が動作し、
   前記計算機システムは、
   前記第一の物理計算機の将来のリソース使用状況を予測し、
   前記予測した将来のリソース使用状況に基づいて、
   前記ストレージサービスインスタンスの使用可能なリソース量を増加する第一の計画を作成し、
   前記第一の物理計算機上で動作する前記アプリケーションインスタンスの１つ以上を前記第二の物理計算機に移動する第二の計画を作成し、
   作成した前記第一の計画と前記第二の計画を実行する、
   ことを特徴とする計算機システム。
2. 前記計算機システムは、
   前記第一の物理計算機で稼働する前記ボリュームへのＩ／Ｏ状況に基づいて、前記第一の物理計算機で稼働する複数のアプリケーションインスタンスから、前記第二の物理計算機に移動させるアプリケーションインスタンスを選択する
   ことを特徴とする請求項１に記載の計算機システム。
3. 前記計算機システムは、
   前記リソース使用状況に基づいて、
   前記第二の物理計算機へ移動させるアプリケーションインスタンスが使用するボリュームを前記第二の物理計算機に移動する計画を作成する、
   ことを特徴とする請求項２に記載の計算機システム。
4. 前記リソース使用状況は、単位時間当たりのＩ／Ｏ回数、または単位時間当たりのデータ転送量であり、
   前記計算機システムは、
   前記第二の物理計算機へ移動させるアプリケーションインスタンスからの前記単位時間当たりのＩ／Ｏ回数または前記単位時間当たりのデータ転送量が一定値以上であるボリュームを移動する計画を作成する、
   ことを特徴とする請求項３に記載の計算機システム。
5. 前記第二の物理計算機に前記アプリケーションインスタンスを移動することによって、前記第二の物理計算機がリソース不足にならないことを確認した後に、前記アプリケーションインスタンスの１つ以上を前記第二の物理計算機に移動する計画を作成する、
   ことを特徴とする請求項１に記載の計算機システム。
6. 前記ストレージサービスインスタンスと、前記アプリケーションインスタンスは、独立した物理計算機を模擬するハイパーバイザもしくはホストＯＳ上で動作する仮想計算機であることを特徴とする請求項１に記載の計算機システム。
7. 前記ストレージサービスインスタンスと、前記アプリケーションインスタンスは、独立したＯＳ空間を模擬するコンテナ基盤上で動作するコンテナである、
   ことを特徴とする請求項１に記載の計算機システム。
8. 前記ストレージサービスインスタンスは、物理計算機上で稼働するハイパーバイザもしくはホストＯＳで動作するプロセスである、
   ことを特徴とする請求項１に記載の計算機システム。
9. 第一の物理計算機及び第二の物理計算機を含む複数の物理計算機から構成される計算機システムであって、
   前記第一の物理計算機では、
   アプリケーションサービスを行う１つ以上のアプリケーションインスタンスと、前記アプリケーションインスタンスが使用するボリュームを含むストレージサービスを提供するストレージサービスインスタンスと、が動作し、
   前記計算機システムは、
   前記第一の物理計算機の将来のリソース使用状況を予測し、前記予測した将来のリソース使用状況に基づいて、前記ストレージサービスインスタンスのリソース不足を解消する使用可能なリソース量を増加する第一のアクションと、前記第一の物理計算機上で動作する前記アプリケーションインスタンスの１つ以上を前記第二の物理計算機に移動する第二のアクションと、前記アプリケーションインスタンスが使用するボリュームを前記第二の物理計算機に移動する第三のアクションと、
   を含む各アクションに設定された処理コスト値に基づく目的関数が制約条件下でコストが小さくなるようなアクションを実行する計画を作成し、
   作成した計画を実行する、
   ことを特徴とする計算機システム。
10. 前記計算機システムは、
    前記アプリケーションインスタンスが使用するボリュームに対する単位時間当たりのＩ／Ｏ回数、または単位時間当たりのデータ転送量に応じて前記第二のアクションの処理コスト値を設定する、
    ことを特徴とする請求項９に記載の計算機システム。
11. 第一の物理計算機及び第二の物理計算機を含む複数の物理計算機から構成される計算機システムの制御方法であって、
    前記第一の物理計算機では、
    アプリケーションサービスを行う１つ以上のアプリケーションインスタンスと、前記アプリケーションインスタンスが使用するボリュームを含むストレージサービスを提供するストレージサービスインスタンスと、が動作し、
    前記計算機システムが、
    前記第一の物理計算機の将来のリソース使用状況を予測し、
    前記予測した将来のリソース使用状況に基づいて、
    前記ストレージサービスインスタンスの使用可能なリソース量を増加する第一の計画を作成し、
    前記第一の物理計算機上で動作する前記アプリケーションインスタンスの１つ以上を前記第二の物理計算機に移動する第二の計画を作成し、
    作成した前記第一の計画と前記第二の計画を実行する、
    各処理を含むことを特徴とする計算機システムの制御方法。

Images