(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-10-21
(45)【発行日】2022-10-31
(54)【発明の名称】計算機システム及び計算機システムの制御方法
(51)【国際特許分類】
G06F 9/50 20060101AFI20221024BHJP
G06F 9/455 20060101ALI20221024BHJP
G06F 9/48 20060101ALI20221024BHJP
【FI】
G06F9/50 120Z
G06F9/455 150
G06F9/48 150Z
(21)【出願番号】P 2020100768
(22)【出願日】2020-06-10
【審査請求日】2021-05-27
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002365
【氏名又は名称】特許業務法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】中村 隆喜
(72)【発明者】
【氏名】亀井 仁志
(72)【発明者】
【氏名】坂下 悠貴
(72)【発明者】
【氏名】大平 良徳
(72)【発明者】
【氏名】揚妻 匡邦
【審査官】漆原 孝治
(56)【参考文献】
【文献】特開2020-052730(JP,A)
【文献】特開2017-091001(JP,A)
【文献】特開2018-028746(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/50
G06F 9/455
G06F 9/48
(57)【特許請求の範囲】
【請求項1】
第一の物理計算機及び第二の物理計算機を含む複数の物理計算機から構成される計算機システムであって、
前記第一の物理計算機では、
アプリケーションサービスを行う1つ以上のアプリケーションインスタンスと、前記アプリケーションインスタンスが使用するボリュームを含むストレージサービスを提供するストレージサービスインスタンスと、が動作し、
前記計算機システムは、
前記第一の物理計算機の将来のリソース使用状況を予測し、
前記予測した将来のリソース使用状況に基づいて、
前記ストレージサービスインスタンスの使用可能なリソース量を増加する第一の計画を作成し、
前記第一の物理計算機上で動作する前記アプリケーションインスタンスの1つ以上を前記第二の物理計算機に移動する
第二の計画を作成し、
作成した
前記第一の計画と前記第二の計画を実行する、
ことを特徴とする計算機システム。
【請求項2】
前記計算機システムは、
前記第一の物理計算機で稼働する前記ボリュームへのI/O状況に基づいて、前記第一の物理計算機で稼働する複数のアプリケーションインスタンスから、前記第二の物理計算機に移動させるアプリケーションインスタンスを選択する
ことを特徴とする請求項1に記載の計算機システム。
【請求項3】
前記計算機システムは、
前記リソース使用状況に基づいて、
前記第二の物理計算機へ移動させるアプリケーションインスタンスが使用するボリュームを前記第二の物理計算機に移動する計画を作成する、
ことを特徴とする請求項
2に記載の計算機システム。
【請求項4】
前記リソース使用状況は、単位時間当たりのI/O回数、または単位時間当たりのデータ転送量であり、
前記計算機システムは、
前記第二の物理計算機へ移動させるアプリケーションインスタンスからの前記単位時間当たりのI/O回数または前記単位時間当たりのデータ転送量が一定値以上である
ボリュームを
移動する計画を作成する、
ことを特徴とする請求項
3に記載の計算機システム。
【請求項5】
前記第二の物理計算機に前記アプリケーションインスタンスを移動することによって、前記第二の物理計算機がリソース不足にならないことを確認した後に、前記アプリケーションインスタンスの1つ以上を前記第二の物理計算機に移動する計画を作成する、
ことを特徴とする請求項1に記載の計算機システム。
【請求項6】
前記ストレージサービスインスタンスと、前記アプリケーションインスタンスは、独立した物理計算機を模擬するハイパーバイザもしくはホストOS上で動作する仮想計算機であることを特徴とする請求項1に記載の計算機システム。
【請求項7】
前記ストレージサービスインスタンスと、前記アプリケーションインスタンスは、独立したOS空間を模擬するコンテナ基盤上で動作するコンテナである、
ことを特徴とする請求項1に記載の計算機システム。
【請求項8】
前記ストレージサービスインスタンスは、物理計算機上で稼働するハイパーバイザもしくはホストOSで動作するプロセスである、
ことを特徴とする請求項1に記載の計算機システム。
【請求項9】
第一の物理計算機及び第二の物理計算機を含む複数の物理計算機から構成される計算機システムであって、
前記第一の物理計算機では、
アプリケーションサービスを行う1つ以上のアプリケーションインスタンスと、前記アプリケーションインスタンスが使用するボリュームを含むストレージサービスを提供するストレージサービスインスタンスと、が動作し、
前記計算機システムは、
前記第一の物理計算機の将来のリソース使用状況を予測し、前記予測した将来のリソース使用状況に基づいて、前記ストレージサービスインスタンスのリソース不足を解消する使用可能なリソース量を増加する第一のアクションと、前記第一の物理計算機上で動作する前記アプリケーションインスタンスの1つ以上を前記第二の物理計算機に移動する第二のアクションと、前記アプリケーションインスタンスが使用するボリュームを前記第二の物理計算機に移動する第三のアクションと、
を含む各アクションに設定された処理コスト値に基づく目的関数が制約条件下でコストが小さくなるようなアクションを実行する計画を作成し、
作成した計画を実行する、
ことを特徴とする計算機システム。
【請求項10】
前記計算機システムは、
前記アプリケーションインスタンスが使用するボリュームに対する単位時間当たりのI/O回数、または単位時間当たりのデータ転送量に応じて前記第二のアクションの処理コスト値を設定する、
ことを特徴とする請求項
9に記載の計算機システム。
【請求項11】
第一の物理計算機及び第二の物理計算機を含む複数の物理計算機から構成される計算機システムの制御方法であって、
前記第一の物理計算機では、
アプリケーションサービスを行う1つ以上のアプリケーションインスタンスと、前記アプリケーションインスタンスが使用するボリュームを含むストレージサービスを提供するストレージサービスインスタンスと、が動作し、
前記計算機システムが、
前記第一の物理計算機の将来のリソース使用状況を予測し、
前記予測した将来のリソース使用状況に基づいて、
前記ストレージサービスインスタンスの使用可能なリソース量を増加する第一の計画を作成し、
前記第一の物理計算機上で動作する前記アプリケーションインスタンスの1つ以上を前記第二の物理計算機に移動する
第二の計画を作成し、
作成した
前記第一の計画と前記第二の計画を実行する、
各処理を含むことを特徴とする計算機システムの制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、計算機システム及び計算機システムの制御方法に関する。
【背景技術】
【0002】
複数の物理計算機から構成され、各々の物理計算機ではコンピューティングサービスとストレージサービスとの両方が稼働するハイパーコンバージドインフラストラクチャ(Hyper Converged Infrastructure:HCI)がある。
【0003】
ハイパーコンバージドインフラストラクチャの構成において、コンテナコンピューティングサービスは、物理計算機で稼働するコンテナ基盤上のコンテナとして稼働する場合、物理計算機で稼働するハイパーバイザ上の仮想計算機として稼働する場合がある。ここで、コンピューティングサービスを行うコンテナ、仮想計算機をアプリケーションインスタンスと呼ぶ。
【0004】
また、ハイパーコンバージドインフラストラクチャの構成において、ストレージサービスは、物理計算機上で稼働するホストOSやハイパーバイザ上のプロセスとして稼働する場合、物理計算機で稼働するコンテナ基盤上のコンテナとして稼働する場合、物理計算機で稼働するハイパーバイザ上の仮想計算機として稼働する場合がある。ここで、ストレージサービスを行うプロセス、コンテナもしくは仮想計算機をストレージサービスインスタンスと呼ぶ。ストレージサービスインスタンスは、アプリケーションインスタンスに対してボリュームを提供する。
【0005】
ハイパーコンバージドインフラストラクチャでは、ある物理計算機やあるストレージサービスインスタンスでリソース不足が発生することがある。リソース不足が発生した場合、アプリケーションインスタンスを別の物理計算機に移動したり、ストレージサービスインスタンスがサービスするボリュームを別の物理計算機で稼働するストレージサービスインスタンスに移動したりすることで、そのリソース不足を解消する。
【0006】
特許文献1では、仮想計算機(VM)を物理計算機間でマイグレーションすることでコンピューティングサービスの負荷バランスを行う実施例が開示されている。また、特許文献2では、仮想計算機(VM)が利用するディスクイメージ(仮想計算機にとってのボリュームに相当)をLUN間でマイグレーションすることでストレージサービスの負荷バランスを行う実施例が開示されている。
【先行技術文献】
【特許文献】
【0007】
【文献】米国特許8,095,929号明細書
【文献】米国特許8,935,500号明細書
【発明の概要】
【発明が解決しようとする課題】
【0008】
ハイパーコンバージドインフラストラクチャの構成において、特許文献1に記載された技術を用いれば、仮想計算機が稼働し、仮想計算機が利用するディスクイメージ(仮想計算機にとってのボリュームに相当)のサービスが行われる物理計算機から、仮想計算機を異なる物理計算機に移動させることができる。
【0009】
ハイパーコンバージドインフラストラクチャの構成において、特許文献2に記載された技術を用いれば、仮想計算機が稼働し、仮想計算機が利用するディスクイメージのサービスが行われる物理計算機から、ディスクイメージとそのサービスを異なる物理計算機に移動させることができる。
【0010】
しかしながら、物理計算機のリソース不足を解消する手段としてアプリケーションインスタンスの移動を選択すると、アプリケーションインスタンスが利用しているボリュームのサービスを行う物理計算機とは別の物理計算機にアプリケーションインスタンスが配置されることで、ストレージサービスのための物理計算機間の通信が増加し、全体の処理効率を低下させてしまう。処理効率を落とさないために、アプリケーションインスタンスが利用しているボリュームを、アプリケーションインスタンスの移動先の物理計算機に移動させると、ボリューム移動を実行している期間、さらなるリソース不足を発生させてしまう。
【0011】
また、ストレージサービスインスタンスのリソース不足を解消する手段としてボリュームの移動を選択すると、こちらも同様にボリューム移動を実行している期間、さらなるリソース不足を発生させてしまう。つまり、全体の処理効率を低下させず、ボリューム移動によるさらなるリソース不足の低減の両立が課題である。
【0012】
本発明は上記を考慮してなされたものであって、ストレージサービスとアプリケーションが動作する複数の物理計算機を含んで構成された計算機システムにおいて、効率的かつ短時間にリソース不足を解消し得るようにすることを目的とする。
【課題を解決するための手段】
【0013】
上記課題を解決するため、本発明では、第一の物理計算機及び第二の物理計算機を含む複数の物理計算機から構成される計算機システムであって、前記第一の物理計算機では、アプリケーションサービスを行う1つ以上のアプリケーションインスタンスと、前記アプリケーションインスタンスが使用するボリュームを含むストレージサービスを提供するストレージサービスインスタンスと、が動作し、前記計算機システムは、前記第一の物理計算機の将来のリソース使用状況を予測し、前記予測した将来のリソース使用状況に基づいて、前記第一の物理計算機上で動作する前記アプリケーションインスタンスの1つ以上を前記第二の物理計算機に移動する計画を作成し、作成した計画を実行する、ことを特徴とする。
【発明の効果】
【0014】
本発明によれば、ストレージサービスとアプリケーションが動作する複数の物理計算機を含んで構成された計算機システムにおいて、効率的かつ短時間にリソース不足を解消できる。
【図面の簡単な説明】
【0015】
【
図1】
図1は、一実施形態に係る計算機システムの全体構成図である。
【
図2】
図2は、一実施形態に係るクラスタ用計算機またはクラスタ管理用計算機のハードウェア構成図である。
【
図3】
図3は、一実施形態に係るクラスタ管理用計算機のメモリの構成図である。
【
図4】
図4は、一実施形態に係るクラスタ用計算機のメモリの構成図である。
【
図5】
図5は、一実施形態に係るボリューム配置管理テーブルの構成図である。
【
図6】
図6は、一実施形態に係るアプリケーションコンテナ配置管理テーブルの構成図である。
【
図7】
図7は、一実施形態に係るストレージサービスコンテナ配置管理テーブルの構成図である。
【
図8】
図8は、一実施形態に係るボリューム性能容量管理テーブルの構成図である。
【
図9】
図9は、一実施形態に係るアプリケーションコンテナ性能管理テーブルの構成図である。
【
図10】
図10は、一実施形態に係るストレージサービスコンテナ性能容量管理テーブルの構成図である。
【
図11】
図11は、一実施形態に係るクラスタ用計算機性能容量管理テーブルの構成図である。
【
図12】
図12は、一実施形態に係るリソース不足解消計画テーブルの構成図である。
【
図13】
図13は、一実施形態に係る稼働状態収集処理のフローチャートである。
【
図14】
図14は、一実施形態に係るリソース使用量予測処理のフローチャートである。
【
図15】
図15は、一実施形態に係るリソース不足解消計画処理のフローチャートである。
【
図16】
図16は、一実施形態に係る特定リソース不足解消計画処理のフローチャートである。
【
図17】
図17は、一実施形態に係るストレージサービスコンテナ向け特定リソース不足解消計画処理のフローチャートである。
【
図18】
図18は、一実施形態に係るマイグレーション計画処理のフローチャートである。
【
図19】
図19は、一実施形態に係るアプリケーションコンテナマイグレーション計画処理のフローチャートである。
【
図20】
図20は、一実施形態に係るアプリケーションコンテナ・ボリュームマイグレーション計画処理のフローチャートである。
【
図21】
図21は、一実施形態に係る移動先探索・悪影響評価処理のフローチャートである。
【
図22】
図22は、一実施形態に係る計画実行指示処理のフローチャートである。
【
図23】
図23は、他の一実施形態に係るリソース不足解消計画処理のフローチャートである。
【発明を実施するための形態】
【0016】
実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
【0017】
以下の説明では、「AAAテーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「AAAテーブル」を「AAA情報」と呼ぶことができる。
【0018】
また、以下の説明では、「プロセッサ部」は、1以上のプロセッサを含む。少なくとも1つのプロセッサは、典型的には、CPU(Central Processing Unit)である。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。
【0019】
また、以下の説明では、「プログラム」を動作の主体として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU)によって実行されることで、定められた処理を、適宜に記憶資源(例えばメモリ)及び/又は通信インターフェース装置(例えばポート)を用いながら行うため、処理の主体がプロセッサとされてもよい。プログラムを動作の主体として説明された処理は、プロセッサを含む装置が行う処理としてもよい。また、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでもよい。コンピュータプログラムは、プログラムソースから装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ、又は、計算機が読み取り可能な記憶メディアであってもよい。
【0020】
また、以下の説明では、「コンテナ」を管理対象として説明する場合があるが、コンテナの代わりに、物理計算機のハードウェアをエミュレートする仮想化方式である「仮想計算機(VM)」や物理計算機そのものである「ベアメタル」が管理対象であってもよい。
【0021】
[実施形態]
本実施形態は、複数の計算機から構成される計算機システム上にコンピューティングサービスとストレージサービスとが動作するハイパーコンバージドインフラストラクチャであって、ハイパーコンバージドインフラストラクチャ(HCI)の構成要素である計算機のリソース不足を解消する技術に関する。
【0022】
まず、本発明の一実施形態に係る計算機システム100について説明する。
図1は、一実施形態に係る計算機システム100の全体構成図である。
【0023】
計算機システム100は、クラスタ管理用計算機101と、一台以上のクラスタ用計算機102と、管理用端末103と、それらを接続するネットワーク104とを備える。
【0024】
クラスタ用計算機102には、1つ以上のアプリケーションコンテナ110、ストレージサービスコンテナ111、コンテナ管理基盤112が稼働している。これら計算機システムによりハイパーコンバージドインフラストラクチャのサービスが実現される。
【0025】
図1に示す計算機システム100では、クラスタ管理用計算機101とクラスタ用計算機102とが別に構成されている例を示しているが、クラスタ管理用計算機101とクラスタ用計算機102とを一つのベアメタル(物理計算機)を用いて構成してもよい。例えば、クラスタ管理用計算機101は仮想計算機の形態であってもよく、コンテナ仮想化技術により構成されたコンテナの形態であってもよい。また、クラスタ管理用計算機101は必ずしも独立した装置である必要はなく、その機能をクラスタ用計算機102のいずれかに内包してもよい。
【0026】
ストレージサービスコンテナ111は、アプリケーションコンテナ110に対してボリュームサービスを提供する、ストレージサービスインスタンスの一例である。なお、
図1のストレージサービスコンテナ111は、独立したOS空間を模擬するコンテナ基盤上で動作する単一のコンテナで構成されているが、物理計算機のハードウェアをエミュレートするハイパーバイザ上で動作する仮想計算機(VM)の形態であってもよいし、ベアメタルのハイパーバイザやホストOS上で動作するストレージサービスの形態であってもよい。また複数のコンテナや複数の仮想計算機でストレージサービスを提供する形態であってもよい。
【0027】
アプリケーションコンテナ110は、ハイパーコンバージドインフラの利用者が利用するコンテナであり、アプリケーションサービスインスタンスの一例である。アプリケーションコンテナ110は、仮想計算機(VM)の形態であってもよいし、ベアメタルのハイパーバイザやホストOS上で動作するアプリケーションの形態であってもよい。
【0028】
コンテナ管理基盤112はアプリケーションコンテナ110とストレージサービスコンテナ111を管理する。ストレージサービスとアプリケーションの動作形態に応じて、コンテナ管理基盤112は仮想計算機(VM)管理基盤の形態やベアメタル管理基盤の形態であってもよい。
【0029】
次に、クラスタ管理用計算機101と、クラスタ用計算機102とのハードウェアの構成について説明する。
図2は、一実施形態に係るクラスタ管理用計算機101及びクラスタ用計算機102のハードウェア構成図である。本実施形態では、クラスタ管理用計算機101とクラスタ用計算機102とのハードウェアの基本的な構成は同じである。以下、クラスタ管理用計算機101を単に計算機101、クラスタ用計算機102を単に計算機102という場合がある。
【0030】
計算機101(102)は、例えば、PCやサーバ等の計算機によって構成され、プロセッサ部の一例としてのCPU(Central Processing Unit)201、メモリ202、HBA(Host Bus Adapter)203、NIC(Network Inferface Card)204、USB(Universal Serial Bus)205、VGA(Video Graphics Array)206、及びストレージデバイスを含む。これら構成要素は、内部バスや外部バスで接続されている。ストレージデバイスとしては、例えば、NVMe(Non-Volatile Memory express)ドライブ207、SAS(Serial Attached SCSI)ドライブ208、SATA(Serial ATA)ドライブ209等や、HBA203で接続された図示しない外部ドライブなどがある。
【0031】
次に、クラスタ管理用計算機101のメモリ202(202A)の構成について説明する。
図3は、一実施形態に係るクラスタ管理用計算機のメモリ202(202A)の構成図である。
【0032】
クラスタ管理用計算機101のメモリ202(202A)は、稼働状態収集プログラム301、リソース使用量予測プログラム302、リソース不足解消計画プログラム303、及び計画実行指示プログラム304を記憶する。また、メモリ202Aは、ボリューム配置管理テーブル311、アプリケーションコンテナ配置管理テーブル312、ストレージサービスコンテナ配置管理テーブル313、ボリューム性能容量管理テーブル321、アプリケーションコンテナ性能管理テーブル322、ストレージサービスコンテナ性能容量管理テーブル323、クラスタ用計算機性能容量管理テーブル324、及びリソース不足解消計画テーブル331を記憶する。また、メモリ202Aは、図示しない、その他クラスタ管理を実現するためのプログラムやテーブルを記憶している。
【0033】
次に、クラスタ用計算機102のメモリ202(202B)の構成について説明する。
図4は、一実施形態に係るクラスタ用計算機のメモリ202(202B)の構成図である。クラスタ用計算機102のメモリ202(202B)は、コンテナ管理基盤用メモリ領域401、ストレージサービスコンテナ用メモリ領域420、アプリケーションコンテナ用メモリ領域430から構成される。
【0034】
コンテナ管理基盤用メモリ領域401は、コンテナ移動プログラム411、コンテナ使用可能リソース制御プログラム412を記憶する。また、ストレージサービスコンテナ用メモリ領域420は、ボリューム移動プログラム421、ストレージ制御リソース制御プログラム422を記憶する。また、アプリケーションコンテナ用メモリ領域430は、1つ以上のアプリケーションプログラム431を記憶する。また、メモリ202Bは、図示しない、その他ハイパーコンバージドインフラストラクチャに必要な各種サービスを実現するためのプログラムやテーブルを記憶している。
【0035】
次に、ボリューム配置管理テーブル311の構成について説明する。
図5は、一実施形態に係るボリューム配置管理テーブル311の構成図である。ボリューム配置管理テーブル311は、アプリケーションコンテナに提供するボリュームがどのストレージサービスコンテナによって提供されているかを示す。ここで、ボリュームは、1つ以上のストレージデバイスの領域から構成され、iSCSI、NFS、NVMe-oF、SCSIなどのストレージプロトコルによって、ストレージサービスコンテナ111からアプリケーションコンテナ110に提供される。
【0036】
ボリューム配置管理テーブル311は、ボリュームに対応する行を格納する。各行は、列として、ボリューム番号501、及びストレージサービスコンテナ番号502の項目を含む。
【0037】
ボリューム番号501には、ボリュームを特定する情報が格納される。例えば、LUN(Logiacl Unit Number)が格納される。ストレージサービスコンテナ番号502には、そのボリュームをサービスしているストレージサービスコンテナを特定する情報が格納される。例えば、シリアル番号、IPアドレスなどが格納される。
【0038】
次に、アプリケーションコンテナ配置管理テーブル312の構成について説明する。
図6は、一実施形態に係るアプリケーションコンテナ配置管理テーブル312の構成図である。
【0039】
アプリケーションコンテナ配置管理テーブル312は、アプリケーションコンテナ110に対応する行を格納する。各行は、列として、アプリケーションコンテナ番号601、及びクラスタ用計算機番号602の項目を含む。
【0040】
アプリケーションコンテナ番号601には、アプリケーションコンテナ110が特定する情報が格納される。例えば、シリアル番号、IPアドレスなどが格納される。クラスタ用計算機番号602には、そのアプリケーションコンテナが稼働するクラスタ用計算機102を特定する情報が格納される。例えば、シリアル番号、IPアドレスなどが格納される。
【0041】
次に、ストレージサービスコンテナ配置管理テーブル313の構成について説明する。
図7は、一実施形態に係るストレージサービスコンテナ配置管理テーブル313の構成図である。
【0042】
ストレージサービスコンテナ配置管理テーブル313は、ストレージサービスコンテナ111に対応する行を格納する。各行は、列として、ストレージサービスコンテナ番号701、及びクラスタ用計算機番号702の項目を含む。
【0043】
ストレージサービスコンテナ番号701には、ストレージサービスコンテナ111を特定する情報が格納される。例えば、シリアル番号、IPアドレスなどが格納される。クラスタ用計算機番号702には、そのストレージサービスコンテナ111が稼働するクラスタ用計算機102を特定する情報が格納される。例えば、シリアル番号、IPアドレスなどが格納される。
【0044】
次に、ボリューム性能容量管理テーブル321の構成について説明する。
図8は、ボリューム性能容量管理テーブル321の構成図である。
【0045】
ボリューム性能容量管理テーブル321は、ボリュームに対応する行を格納する。各行は、列として、ボリューム番号801、IOPS802、TransferRate803、及びストレージ容量利用量804の項目を含む。
【0046】
ボリューム番号801には、ボリュームを特定する情報が格納される。IOPS802には、そのボリュームに対する単位時間当たりのIO数の情報が、ReadとWriteのそれぞれに格納される。TransferRate803には、そのボリュームに対する単位時間当たりのデータ転送量の情報が、ReadとWriteのそれぞれに格納される。ストレージ容量利用量804には、そのボリュームに対するストレージ容量の利用量が格納される。各利用量は時間と共に変化するため、IOPS802、TransferRate803、及びストレージ容量利用量804は、一定時間ごとに新たな情報として格納される。
【0047】
また、ここではIO性能の指標を格納しているが、ストレージサービスコンテナ111においてサービスのためにそのボリュームが消費するCPU量や、メモリ量を格納してもよい。
【0048】
図9は、一実施形態に係るアプリケーションコンテナ性能管理テーブル322の構成図である。
【0049】
アプリケーションコンテナ性能管理テーブル322は、アプリケーションコンテナ110に対応する行を格納する。各行は、列として、アプリケーションコンテナ番号901、CPU902、メモリ903、及びネットワーク帯域904の項目を含む。
【0050】
アプリケーションコンテナ番号901には、アプリケーションコンテナ110を特定する情報が格納される。CPU902には、そのアプリケーションコンテナに対するCPUの利用量と定義量が格納される。ここでCPUの定義量とはそのアプリケーションコンテナ110が利用できるCPUの利用量の最大値である。
【0051】
メモリ903には、そのアプリケーションコンテナ110に対するメモリの利用量と定義量が格納される。ここでメモリの定義量とはそのアプリケーションコンテナが利用できるメモリの利用量の最大値である。ネットワーク帯域904には、そのアプリケーションコンテナ110に対するネットワーク帯域の利用量と定義量が格納される。ここでネットワーク帯域の定義量とはそのアプリケーションコンテナ110が利用できるネットワーク帯域の利用量の最大値である。また、ネットワーク帯域904には送信と受信の情報がそれぞれ格納される。
【0052】
各利用量は時間と共に変化するため、CPU902の利用量、メモリ903の利用量、及びネットワーク帯域904の送信と受信の利用量は、一定時間ごとに新たな情報として格納される。
【0053】
図10は、一実施形態に係るストレージサービスコンテナ性能容量管理テーブル323の構成図である。ストレージサービスコンテナ性能容量管理テーブル323は、ストレージサービスコンテナ111に対応する行を格納する。各行は、列として、ストレージサービスコンテナ番号1001、CPU1002、メモリ1003、ネットワーク帯域1004、及びストレージ容量1005の項目を含む。
【0054】
ストレージサービスコンテナ番号1001には、ストレージサービスコンテナ111を特定する情報が格納される。CPU1002には、そのストレージサービスコンテナ111に対するCPUの利用量と定義量が格納される。ここでCPUの定義量とはそのストレージサービスコンテナが利用できるCPUの利用量の最大値である。
【0055】
メモリ1003には、そのストレージサービスコンテナ111に対するメモリの利用量と定義量が格納される。ここでメモリの定義量とはそのストレージサービスコンテナ111が利用できるメモリの利用量の最大値である。ネットワーク帯域1004には、そのストレージサービスコンテナ111に対するネットワーク帯域の利用量と定義量が格納される。ここでネットワーク帯域の定義量とはそのストレージサービスコンテナ111が利用できるネットワーク帯域の利用量の最大値である。
【0056】
また、ネットワーク帯域1004には送信と受信の情報がそれぞれ格納される。ストレージ容量1005には、そのストレージサービスコンテナ111に対するストレージ容量の利用量と定義量が格納される。ここでストレージ容量の定義量とはそのストレージサービスコンテナが利用できるストレージ容量の最大値である。
【0057】
各利用量は時間と共に変化するため、CPU1002の利用量、メモリ1003の利用量、ネットワーク帯域1004の送信と受信の利用量、及びストレージ容量1005の利用量は、一定時間ごとに新たな情報として格納される。
【0058】
図11は、一実施形態に係るクラスタ用計算機性能容量管理テーブル324の構成図である。クラスタ用計算機性能容量管理テーブル324は、クラスタ用計算機102に対応する行を格納する。各行は、列として、クラスタ用計算機番号1101、CPU1102、メモリ1103、ネットワーク帯域1104、及びストレージ容量1105の項目を含む。
【0059】
クラスタ用計算機番号1101には、クラスタ用計算機102を特定する情報が格納される。CPU1102には、そのクラスタ用計算機に対するCPUの利用量と定義量が格納される。ここでCPUの定義量とはそのクラスタ用計算機102が利用できるCPUの利用量の最大値である。メモリ1103には、そのクラスタ用計算機102に対するメモリの利用量と定義量が格納される。ここでメモリの定義量とはそのクラスタ用計算機が利用できるメモリの利用量の最大値である。
【0060】
ネットワーク帯域1104には、そのクラスタ用計算機102に対するネットワーク帯域の利用量と定義量が格納される。ここでネットワーク帯域の定義量とはそのクラスタ用計算機が利用できるネットワーク帯域の利用量の最大値である。また、ネットワーク帯域1104には送信と受信の情報がそれぞれ格納される。ストレージ容量1105には、そのクラスタ用計算機に対するストレージ容量の利用量と定義量が格納される。ここでストレージ容量の定義量とはそのクラスタ用計算機が利用できるストレージ容量の最大値である。
【0061】
各利用量は時間と共に変化するため、CPU1102の利用量、メモリ1103の利用量、ネットワーク帯域1104の送信と受信の利用量、及びストレージ容量1105の利用量は、一定時間ごとに新たな情報として格納される。
【0062】
図12は、一実施形態に係るリソース不足解消計画テーブル311の構成図である。リソース不足解消計画テーブル331は、リソース不足解消計画に対応する行を格納する。各行は、列として、計画管理番号1201、対象オブジェクト種別1202、オブジェクト番号1203、アクション種別1204、及びアクション内容1205の項目を含む。
【0063】
計画管理番号1201には、リソース不足解消計画を特定する情報が格納される。対象オブジェクト種別1202には、そのリソース不足解消計画の対象オブジェクトの種別に関する情報が格納される。対象オブジェクトの例としては、ストレージサービスコンテナ、ボリューム、アプリケーションコンテナがある。
【0064】
オブジェクト番号1203には、対象オブジェクトを特定する番号が格納される。アクション種別1204には、対象オブジェクトに対して計画するアクションの種類の情報が格納される。アクション内容1205には、対象オブジェクトに対するアクションの計画内容が格納される。
【0065】
例えば、計画管理番号1は、2番のストレージサービスコンテナのCPUの定義量に20GHz追加するという計画である。計画管理番号2は、3番のボリュームを、2番のストレージサービスコンテナに移動するという計画である。計画管理番号3は、2番のアプリケーションコンテナを、2番のクラスタ用計算機に移動するという計画である。
【0066】
次に、本実施形態に係る計算機システム100の処理動作について説明する。
【0067】
まず、稼働状態収集処理について説明する。
【0068】
図13は、一実施形態に係る稼働状態収集処理S1300のフローチャートである。稼働状態収集処理S1300は、クラスタ管理用計算機101の稼働状態収集プログラム301によって実行される。稼働状態収集プログラム301は管理用端末103などを経由して管理者から実行される。
【0069】
先ず、稼働状態収集プログラム301は、ボリューム性能容量管理テーブル321からボリュームの性能容量情報を取得する(S1310)。
【0070】
次に、稼働状態収集プログラム301は、アプリケーションコンテナ性能管理テーブル322からアプリケーションコンテナの性能情報を取得する(S1320)。
【0071】
次に、稼働状態収集プログラム301は、ストレージサービスコンテナ性能容量管理テーブル323からストレージサービスコンテナの性能容量情報を取得する(S1330)。
【0072】
次に、稼働状態収集プログラム301は、クラスタ用計算機性能容量管理テーブル324からクラスタ用計算機の性能容量情報を取得し(S1340)、稼働状態収集処理を終了する。
【0073】
なお、本フローチャートで用いる各種テーブルには別のプログラムによって既に時系列の性能容量情報が格納されている。
【0074】
次に、リソース使用量予測処理S1400について説明する。
【0075】
図14は、一実施形態に係るリソース使用量予測処理S1400のフローチャートである。リソース使用量予測処理S1400は、クラスタ管理用計算機101のリソース使用量予測プログラム302によって実行される。リソース使用量予測プログラム302は管理用端末103などを経由して管理者から実行される。
【0076】
リソース使用量予測処理S1400では、リソース使用量予測プログラム302は、まずオブジェクト種別でのループを開始する(S1410)。ここで、オブジェクト種別とはボリューム、アプリケーションコンテナ、ストレージサービスコンテナ、クラスタ用計算機の4種である。
【0077】
次に、リソース使用量予測プログラム302は、S1410で指定されたオブジェクトの稼働情報から各リソース使用量を予測する(S1420)。ここで、各リソース使用量とは、CPU、メモリ、ネットワーク帯域、ストレージ容量である。ボリューム性能容量管理テーブル321が、IOPS、TransferRateの形式で格納されている場合は、予測データをCPU、メモリ、ネットワーク帯域の形式に換算する。
【0078】
リソース使用量予測プログラム302は、全てのオブジェクト種別に対して処理を行い、ループ処理を終了する(S1430)。
【0079】
次に、リソース使用量予測プログラム302は、予測期間内にCPU、メモリ、ネットワーク帯域、ストレージ容量の観点でリソース不足になる見込みのストレージサービスコンテナ111を抽出する(S1440)。
【0080】
次に、リソース使用量予測プログラム302は、予測期間内にCPU、メモリ、ネットワーク帯域、ストレージ容量の観点でリソース不足になる見込みのクラスタ用計算機102を抽出し(S1450)、リソース使用量予測処理S1400を終了する。
【0081】
次に、リソース不足解消計画処理S1500について説明する。
【0082】
図15は、一実施形態に係るリソース不足解消計画処理S1500のフローチャートである。リソース不足解消計画処理S1500は、クラスタ管理用計算機101のリソース不足解消計画プログラム303によって実行される。リソース不足解消計画プログラム303は管理用端末103などを経由して管理者から実行される。
【0083】
リソース不足解消計画処理S1500では、リソース不足解消計画プログラム303は、まずリソース種別でのループを開始する(S1510)。ここで、リソース種別とはCPU、メモリ、ネットワーク帯域、ストレージ容量の4種である。
【0084】
次に、リソース不足解消計画プログラム303は、S1510で指定されたリソースを設定し(S1520)、特定リソース不足解消計画処理(S1600)を呼び出す。特定リソース不足解消計画処理S1510の詳細は後に説明する。
【0085】
リソース不足解消計画プログラム303は、全てのリソース種別に対して処理を行い、ループ処理を終了する(S1540)。以上で、リソース不足解消計画処理S1500を終了する。
【0086】
次に、特定リソース不足解消計画処理S1600について説明する。
【0087】
図16は、一実施形態に係る特定リソース不足解消計画処理S1600のフローチャートである。特定リソース不足解消計画処理S1600は、クラスタ管理用計算機101のリソース不足解消計画プログラム303によって実行されるリソース不足解消計画処理(S1500)から呼び出されることによって実行される。リソース不足解消計画プログラム303は管理用端末103などを経由して管理者から実行される。
【0088】
特定リソース不足解消計画処理では、リソース不足解消計画プログラム303は、まずリソース使用量予測処理(S1400)によって得られたリソース不足になる見込みのストレージサービスコンテナ111のリストでのループを開始する(S1610)。
【0089】
次に、リソース不足解消計画プログラム303は、S1610で指定されたリソースと指定されたストレージサービスコンテナ111についてストレージサービスコンテナ向け特定リソース不足解消計画処理を呼び出す(S1700)。ストレージサービスコンテナ向け特定リソース不足解消計画処理S1700の詳細は後に説明する。
【0090】
リソース不足解消計画プログラム303は、全てのリソース不足になる見込みのストレージサービスコンテナに対して処理を行い、ループ処理を終了する(S1620)。
【0091】
次に、リソース不足解消計画プログラム303は、リソース使用量予測処理(S1450)によって得られたリソース不足になる見込みのクラスタ用計算機102のリストでのループを開始する(S1630)。
【0092】
次に、リソース不足解消計画プログラム303は、S1630で指定されたリソースと指定されたクラスタ用計算機102についてマイグレーション計画処理を呼び出す(S1800)。マイグレーション計画処理S1800の詳細は後に説明する。
【0093】
リソース不足解消計画プログラム303は、全てのリソース不足になる見込みのクラスタ用計算機に対して処理を行い、ループ処理を終了する(S1640)。以上で、特定リソース不足解消計画処理S1600を終了する。
【0094】
次に、ストレージサービスコンテナ向け特定リソース不足解消計画処理S1700について説明する。
【0095】
図17は、ストレージサービスコンテナ向け特定リソース不足解消計画処理S1700のフローチャートである。ストレージサービスコンテナ向け特定リソース不足解消計画処理S1700は、クラスタ管理用計算機101のリソース不足解消計画プログラム303によって実行される特定リソース不足解消計画処理(S1600)から呼び出されることによって実行される。リソース不足解消計画プログラム303は管理用端末103などを経由して管理者から実行される。
【0096】
ストレージサービスコンテナ向け特定リソース不足解消計画処理S1700では、リソース不足解消計画プログラム303は、まず指定されたリソースの定義量が変更可能であるかどうかを確認する(S1710)。リソースの定義量が変更可能であるのは、例えば稼働するコンテナのリソース利用可能量を変更できる、稼働するコンテナの数を変更できるなどがある。ストレージサービスを実現するのが仮想計算機(VM)の場合は、稼働する仮想計算機のリソース利用可能量を変更できる、稼働する仮想計算機の数を変更できるなどがある。ストレージサービスを実現するのがベアメタルの場合、稼働するサービスのプロセスのリソース利用可能量を変更できる、稼働するサービスのプロセスの数を変更できるなどがある。
【0097】
定義量が変更可能な場合(S1710:Yes)、リソース不足解消計画プログラム303は、指定されたリソースの定義量を増加する計画を追加する(S1720)。定義量が変更できない場合(S1710:No)、S1720の処理はスキップする。
【0098】
次に、リソース不足解消計画プログラム303は、これまでの処理によってリソース不足が解消される見込みかどうかを確認する(S1730)。解消される見込みの場合(S1730:Yes)、リソース不足解消計画プログラム303は、ストレージサービスコンテナ向け特定リソース不足解消計画処理を終了する。解消されない見込みの場合(S1730:No)、リソース不足解消計画プログラム303は、マイグレーション計画処理を呼び出す(S1800)。マイグレーション計画処理の詳細は後に説明する。以上で、ストレージサービスコンテナ向け特定リソース不足解消計画処理を終了する。
【0099】
次に、マイグレーション計画処理S1800について説明する。
【0100】
図18は、マイグレーション計画処理S1800のフローチャートである。マイグレーション計画処理S1800は、クラスタ管理用計算機101のリソース不足解消計画プログラム303によって実行される特定リソース不足解消計画処理(S1600)もしくはストレージサービスコンテナ向け特定リソース不足解消計画処理(S1700)から呼び出されることによって実行される。リソース不足解消計画プログラム303は管理用端末103などを経由して管理者から実行される。
【0101】
マイグレーション計画処理S1800では、まず、リソース不足解消計画プログラム303は、アプリケーションコンテナマイグレーション計画処理を呼び出す(S1900)。アプリケーションコンテナマイグレーション計画処理S1900の詳細は後に説明する。
【0102】
次に、リソース不足解消計画プログラム303は、これまでの処理によってリソース不足が解消される見込みかどうかを確認する(S1810)。解消される見込みの場合(S1810:Yes)、マイグレーション計画処理S1800を終了する。解消されない見込みの場合(S1810:No)、アプリケーションコンテナ・ボリュームマイグレーション計画処理を呼び出す(S2000)。アプリケーションコンテナ・ボリュームマイグレーション計画処理S2000の詳細は後に説明する。以上で、リソース不足解消計画プログラム303は、マイグレーション計画処理S1800を終了する。
【0103】
次に、アプリケーションコンテナマイグレーション計画処理S1900について説明する。
図19は、アプリケーションコンテナマイグレーション計画処理S1900のフローチャートである。アプリケーションコンテナマイグレーション計画処理S1900は、クラスタ管理用計算機101のリソース不足解消計画プログラム303によって実行されるマイグレーション計画処理(S1800)から呼び出されることによって実行される。
【0104】
先ず、リソース不足解消計画プログラム303は、I/O要件が重要でないアプリケーションコンテナ110を抽出する(S1910)。ここで、I/O要件が重要でない条件の例としては、アプリケーションコンテナ110が用いているボリュームのIOPSが一定値以下、アプリケーションコンテナ110が用いているボリュームのTransferRateが一定値以下、利用者によってI/O要件が重要であると指定されていないなどがある。これらの条件は論理積(AND)である場合もあるし、論理和(OR)である場合もある。
【0105】
次に、リソース不足解消計画プログラム303は、S1910で抽出したアプリケーションコンテナ110のリストを用いて、呼び出し元から指定されたリソースのリソース使用量の降順でループ処理を開始する(S1920)。リソース不足解消計画プログラム303は、ループ処理において、S1910で抽出された対象のアプリケーションコンテナ110について、移動先探索・悪影響評価処理(S2100)を呼び出す。移動先探索・悪影響評価処理S2100の詳細は後に説明する。
【0106】
リソース不足解消計画プログラム303は、S1910で抽出した全てのアプリケーションコンテナ110に対して移動先探索・悪影響評価処理S2100を行うか、リソース不足が解消するかの条件で、ループ処理を終了する(S1930)。以上で、リソース不足解消計画プログラム303は、アプリケーションコンテナマイグレーション計画処理S1900を終了する。
【0107】
次に、アプリケーションコンテナ・ボリュームマイグレーション計画処理S2000について説明する。
図20は、アプリケーションコンテナ・ボリュームマイグレーション計画処理S2000のフローチャートである。
【0108】
アプリケーションコンテナ・ボリュームマイグレーション計画処理S2000は、クラスタ管理用計算機101のリソース不足解消計画プログラム303によって実行されるマイグレーション計画処理(S1800)から呼び出されることによって実行される。
【0109】
まず、リソース不足解消計画プログラム303は、アプリケーションコンテナ110及びアプリケーションコンテナ110が使用しているボリュームのグループのリストを用いて、呼び出し元から指定されたリソースのリソース使用量の降順でループを開始する(S2010)。リソース不足解消計画プログラム303は、対象のアプリケーションコンテナ110及びボリュームのグループについて、移動先探索・悪影響評価処理(S2100)を呼び出す。移動先探索・悪影響評価処理の詳細は後に説明する。
【0110】
リソース不足解消計画プログラム303は、対象の全てのアプリケーションコンテナ110及びボリュームのグループに対して処理を行うか、リソース不足が解消するかの条件で、ループ処理を終了する(S2020)。以上で、リソース不足解消計画プログラム303は、アプリケーションコンテナ・ボリュームマイグレーション計画処理S2000を終了する。
【0111】
次に、移動先探索・悪影響評価処理S2100について説明する。
図21は、移動先探索・悪影響評価処理S2100のフローチャートである。移動先探索・悪影響評価処理S2100は、クラスタ管理用計算機101のリソース不足解消計画プログラム303によって実行されるアプリケーションコンテナマイグレーション計画処理(S1900)とアプリケーションコンテナ・ボリュームマイグレーション計画処理(S2000)から呼び出されることによって実行される。
【0112】
まず、リソース不足解消計画プログラム303は、リストを用いて、呼び出し元から指定されたリソースのリソース使用量の降順でループを開始する(S2110)。なお、S2110で用いるリストは、移動先の対象がクラスタ用計算機102の場合はクラスタ用計算機102のリスト、移動先の対象がストレージサービスコンテナ111の場合はストレージサービスコンテナ111のリストである。
【0113】
次に、リソース不足解消計画プログラム303は、対象のクラスタ用計算機102もしくはストレージサービスコンテナ111に対象のオブジェクト(グループ)を移動させた場合に悪影響がないかを検証する(S2120)。ここで、対象のオブジェクト(グループ)とは、アプリケーションコンテナマイグレーション計画処理(S1900)から呼び出された場合はアプリケーションコンテナ110であり、アプリケーションコンテナ・ボリュームマイグレーション計画処理(S2000)から呼び出された場合はアプリケーションコンテナ・ボリュームのグループである。
【0114】
悪影響とは、対象のオブジェクト(グループ)を、対象のクラスタ用計算機102もしくはストレージサービスコンテナ111に移動させた場合に、移動先でなんらかのリソース不足にならないかを検証する(S2120)。これはリソース不足の解消対象のリソース(例えば、CPU)だけでなく、すべてのリソース種別(CPU、メモリ、ネットワーク帯域、ストレージ容量)について検証する。
【0115】
悪影響がなかった場合、もしくは悪影響が許容できるレベルであった場合(S2130:No)、リソース不足解消計画プログラム303は、対象のオブジェクト(グループ)を対象のクラスタ用計算機102もしくは対象のストレージサービスコンテナ111に移動する計画を、リソース不足解消計画テーブル331に追加する(S2140)。
【0116】
悪影響があった場合、もしくは悪影響が許容できるレベルでなかった場合(S2130:Yes)、リソース不足解消計画プログラム303は、計画の追加処理(S2140)をスキップし、次のクラスタ用計算機102もしくはストレージサービスコンテナ111を対象とする処理へループ処理を移す。
【0117】
リソース不足解消計画プログラム303は、全てのクラスタ用計算機102もしくはストレージサービスコンテナ111に対してループ処理を行うか、S2140が実行され計画が追加されるかの条件で、ループ処理を終了する(S2150)。以上で、リソース不足解消計画プログラム303は、移動先探索・悪影響評価処理を終了する。
【0118】
次に、計画実行指示処理S2200について説明する。
図22は、計画実行指示処理S2200のフローチャートである。計画実行指示処理S2200は、クラスタ管理用計算機101の計画実行指示プログラム304によって実行される。計画実行指示プログラム304は管理用端末103などを経由して管理者から実行される。
【0119】
先ず、計画実行指示プログラム304は、クラスタ用計算機102のリストを用いて、ループ処理を開始する(S2210)。
【0120】
次に、計画実行指示プログラム304は、対象のクラスタ用計算機102に関する計画を、対象のクラスタ用計算機102に指示する(S2220)。アプリケーションコンテナ110を移動させる計画の場合は、計画実行指示プログラム304は、対象のクラスタ用計算機102のコンテナ移動プログラム411を呼び出す。これにより、計画で指定されたアプリケーションコンテナ110は、計画で指定されたクラスタ用計算機102に移動する。また、ストレージサービスコンテナ111のリソース定義量を増加させる計画の場合は、計画実行指示プログラム304は、対象のクラスタ用計算機102のコンテナ使用可能リソース制御プログラム412を呼び出す。これにより、計画で指定されたストレージサービスコンテナ111のリソース定義量が増加する。
【0121】
計画実行指示プログラム304は、全てのクラスタ用計算機102に対してS2220の処理を行い、ループ処理を終了する(S2230)。
【0122】
次に、計画実行指示プログラム304は、ストレージサービスコンテナ111のリストを用いて、ループ処理を開始する(S2240)。次に、計画実行指示プログラム304は、対象のストレージサービスコンテナ111に関する計画を、対象のストレージサービスコンテナ111に指示する(S2250)。
【0123】
ボリュームを移動させる計画の場合は、計画実行指示プログラム304は、対象のストレージサービスコンテナ111のボリューム移動プログラム421を呼び出す。これにより、計画で指定されたボリュームは、計画で指定されたストレージサービスコンテナ111に移動する。また、ストレージサービスコンテナ111のリソース定義量を増加させる計画の場合は、計画実行指示プログラム304は、対象のストレージサービスコンテナ111のストレージ制御リソース制御プログラム422を呼び出す。これにより、対象のストレージサービスコンテナ111の利用可能なリソース量が再定義され、再定義されたリソース量に応じてストレージサービス処理が最適化される。最適化の例としては、ストレージ機能が仮想マシンで提供される場合にホットプラグやリソースプール制約などの機能を使って、またはストレージ機能がベアメタルやコンテナで提供される場合にストレージサービスを行うためのワーカープロセスやワーカースレッド、ワーカーコンテナを増加することで、リソース利用上限が動的に拡張される。
【0124】
計画実行指示プログラム304は、全てのストレージサービスコンテナ111に対してS2250の処理を行い、ループ処理を終了する(S2260)。以上で、計画実行指示プログラム304は、計画実行指示処理S2200を終了する。
【0125】
本実施形態では、SDS(Software Defined Storage)やHCI構成を取る計算機システムの複数のノードからなるクラスタ内においてリソース不足による高負荷状態が発生した場合に、(A)ストレージサービスコンテナのリソース定義量増加、(B)アプリケーションコンテナのノード間移動、(C)アプリケーションコンテナとボリュームのノード間移動の優先順位でアクションを実行する。よって、処理負荷が大きいボリュームマイグレーションを極力実行しないことで、ボリュームの移動量を減らし、ボリューム移動に伴うリソース不足を低減することができる。
【0126】
このようにして、本実施形態によれば、ストレージサービスを行うコンテナとアプリケーションが動作するコンテナが動作する複数の物理計算機を含んで構成された計算機システムにおいて、デメリットや処理コストをできるだけ抑えるように考慮して効率的かつ短時間にコンテナと物理計算機のリソース不足を解消できる。また、全体の処理効率を低下させず、ボリューム移動によるさらなるリソース不足の低減の両立できる。
【0127】
また、本実施形態では、I/O数やI/O量が少ないアプリケーションを、このアプリケーションが利用するボリュームを提供するストレージサービスが稼働する計算機とは異なる計算機に配置するアクションを実行し、I/O数やI/O量が多いアプリケーションを、異なる計算機に配置するアクションを実行しない。これにより、アプリケーションとボリュームが異なる計算機に配置されることで計算機システム全体の処理効率が低下することを抑制できる。
【0128】
(実施形態の変形例)
なお、本実施形態では、上記(A)(B)(C)のアクションに加え、アプリケーションの(D)リソース定義量増加のアクションを実行してもよい。この場合、(D)のアクションは、(B)(C)のアクションに優先して実行されることで、ボリュームの移動量を減らし、ボリューム移動に伴うリソース不足を低減することができる。
【0129】
なお、処理コストを低減しつつリソース不足を解消できれば、上記(A)(B)(C)(D)のアクションの実行の優先順位は、上述に限られない。また、上記(A)及び/又は(B)を実行するとしてもよい。
【0130】
[その他の実施形態]
上述の実施形態では、HCI構成を取る計算機システムの複数のノードからなるクラスタ内においてリソース不足による高負荷状態が発生した場合に、上記(A)(B)(C)の優先順位でアクションを実行するとした。
【0131】
これに対し、整数計画法に基づく所定の最適化問題を解くことで、上述の実施形態のリソース不足解消計画処理(
図15)、特定リソース不足解消計画処理(
図16)、ストレージサービスコンテナ向け特定リソース不足解消計画処理(
図17)などに示す上記(A)(B)(C)の優先順位のアクションを、ボリュームの性能評価に応じて精細に行うことができる。制約条件下の最適化問題を解く実施形態を、その他の実施形態として説明する。
【0132】
先ず、リソース不足を解消するための最適化問題の目的関数と制約条件について説明する。目的関数C_all(k)を最小化する最適化問題は数式1のように表される。
【数1】
【0133】
目的関数C_all(k)の第1項のC(0,0,k)は、ストレージサービスコンテナのリソース定義量を変更する処理のコスト値である。第2項のC(i,j,k)はx_ijkのアクションを取る際に必要な処理のコスト値である。x_0とx_ijkは0か1を取る変数であり、0のときはそのアクションを取らない、1のときはそのアクションを取ることを意味する。x_0は、ストレージサービスコンテナの定義リソースを変更するアクションに対応する。本実施形態では、目的関数C_all(k)を最小化するx_0とx_ijkの値を得ることで、計画を策定する。
【0134】
ここで、数式1、後述の数式2、及び後述の数式3のiは、あるオブジェクトグループ(アプリケーションコンテナとそのアプリケーションコンテナが使用するボリュームのグループ)を表す番号である。また、数式1、数式2、及び数式3のjは、あるオブジェクトグループに対するアクションを表す番号である。アクションの例としては、あるオブジェクトグループのアプリケーションコンテナのみ移動する、あるオブジェクトグループのアプリケーションコンテナと全てのボリュームを移動する、あるオブジェクトグループのアプリケーションコンテナと一部のボリュームを移動する、などがある。
【0135】
あるオブジェクトグループのアプリケーションコンテナのみを移動する場合のアクションのコストは、IOPS、TransferRateが大きい程、値が大きくなり、IOPS、TransferRateが小さい程、値が小さくなる。
【0136】
また、数式1、数式2、及び数式3のkは、クラスタ用計算機の番号である。数式1では、目的関数をクラスタ用計算機毎に定義したが、クラスタ全体で一つの目的関数を定義してもよい。
【0137】
また、数式1の最適化問題の制約条件は、数式2及び数式3のように表される。
【数2】
【数3】
【0138】
数式2のR_target(k,l)は、クラスタ用計算機kにおいて、減少したいリソース種別lのリソース量である。ここで数式2及び数式3のlは、対象のリソース種別を表す番号である。リソース種別とは、CPU、メモリ、ネットワーク帯域、ストレージ容量である。つまりこの制約条件を満たす解を得ることで、必要なリソース量を減らす計画を策定することができる。
【0139】
数式3は、あるオブジェクトグループに対するアクションは一つ以下にする意味の制約条件である。
【0140】
次に、本実施形態のリソース不足解消計画処理を説明する。
【0141】
図23は、リソース不足解消計画処理のフローチャートである。リソース不足解消計画処理は、クラスタ管理用計算機101のリソース不足解消計画プログラム303で実行される。リソース不足解消計画プログラム303は管理用端末103などを経由して管理者から実行される。
【0142】
リソース不足解消計画処理では、リソース不足解消計画プログラム303は、クラスタ用計算機のリストでループを開始する(S2410)。次に、リソース不足解消計画プログラム303は、対象のクラスタ用計算機に関して式(1)の目的関数をソルバーを用いて求解する(S2420)。次に、リソース不足解消計画プログラム303は、リソース不足解消計画プログラム303解で得られた移動候補のオブジェクト(グループ)のリストでループを開始する(S2430)。
【0143】
次に、リソース不足解消計画プログラム303は、対象のオブジェクト(グループ)について、移動先探索・悪影響評価処理を呼び出す(S2100)。リソース不足解消計画プログラム303は、全ての移動候補のオブジェクト(グループ)に対して処理を行い、ループ処理を終了し(S2440)、次のクラスタ用計算機について処理を行う。
【0144】
そして、リソース不足解消計画プログラム303は、全てのクラスタ用計算機に対して処理を行い、ループ処理を終了する(S2450)。以上で、リソース不足解消計画処理を終了する。
【0145】
なお、本発明は、上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。また、上記実施形態において、CPUが行っていた処理の一部又は全部を、専用のハードウェア回路で行うようにしてもよい。また、上記実施形態におけるプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア(例えば可搬型の非一時的な記憶メディア)であってもよい。
【符号の説明】
【0146】
100…計算機システム、101…クラスタ管理用計算機、102…クラスタ用計算機、103…管理用端末、104…ネットワーク、110…アプリケーションコンテナ、111…ストレージサービスコンテナ、112…コンテナ管理基盤、201…CPU、202、202A、202B…メモリ