(57)【要約】      （修正有）【課題】HCI環境において、ノードの計算機資源の上限を超えることなく、新規VM/コンテナやボリュームの作成するVM／コンテナおよびボリューム等のリソース配置決定方法を提供する。【解決手段】ハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定に関し、各ノード上で動作する、仮想マシン及びストレージコントローラが、共用する計算機資源の利用状況を管理し、利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する。【選択図】図１
2020052730.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
前記複数のノードの各ノードは、
データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置とを含む計算機資源を有し、
前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を管理し、
管理部が、前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
【請求項２】
前記計算機資源の利用状況は、前記各ノードにおける記憶装置から構成される記憶容量の利用状況、前記各ノードにおけるCPUの利用状況、前記ノードにおけるメモリの利用状況及びネットワーク帯域の利用状況の少なくとも一つである、ことを特徴とする請求項１記載のリソース配置決定方法。
【請求項３】
前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの第１のノード上の仮想マシン、コンテナ、ボリューム及び前記ストレージコントローラの何れかを他のノードに移行させ、前記第１のノードを前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項２に記載のリソース配置決定方法。
【請求項４】
前記複数のノードの第２のノードで障害が発生した場合、第２のノード上で動作する仮想マシン或いはコンテナを特定し、
前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有するノードに、前記第２のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを第３のノードに作成する、ことを特徴とする請求項１に記載のリソース配置決定方法。
【請求項５】
前記複数のノードの第２のノードで障害が発生した場合、第２のノード上で動作する仮想マシン或いはコンテナを特定し、
前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有するノードに、前記第２のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを第３のノードに作成する、ことを特徴とする請求項３に記載のリソース配置決定方法。
【請求項６】
複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
前記複数のノードのそれぞれは、
データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
前記複数のノードの第４のノードは、第１のストレージコントローラと第１のボリュームと第１のドライブを有し、前記第１のストレージコントローラは、前記仮想マシンからの前記ボリュームに対するIO要求を処理し、前記第１のドライブにデータを書き込み、
前記複数のノードの第５のノードは、第２のストレージコントローラと第２のボリュームと第２のドライブとを有し、前記第２のストレージコントローラは、前記第１のストレージコントローラの冗長先のストレージコントローラとして動作し、前記第１のストレージコントローラから冗長データを受け取って、前記第２のドライブに冗長データを書き込み、
前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが共用する前記計算機資源の利用状況に、前記冗長データの書き込みのための計算機リソースも合わせて管理し、
管理部が、
前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
【請求項７】
前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの特定のノードの仮想マシン、コンテナ、ボリューム及び前記ストレージコントローラの何れかを他のノードに移行させ、前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項６に記載のリソース配置決定方法。
【請求項８】
前記複数のノードの第６のノードで障害が発生した場合、第６のノード上で動作する仮想マシン或いはコンテナを特定し、
前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有する第7のノードに、前記第６のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを、作成する、ことを特徴とする請求項７に記載のリソース配置決定方法。
【請求項９】
複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン(VM)及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
前記複数のノードの各ノードは、
データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
前記複数のノードの内、データの冗長化を行うための冗長構成を管理し、
前記ストレージコントローラは、データの記憶領域となるボリュームを経由して自ノードのドライブに対するデータの読み書き制御と、前記冗長構成に基づき、他ノードのドライブに対する冗長化処理を実行し、
前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を、前記冗長構成を考慮して管理し、
管理部が、
前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
【請求項１０】
前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの一つのノード上の仮想マシン、コンテナ及び前記ストレージコントローラの何れかを他のノードに移行させ、前記複数のノードの内の特定のノードを前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項９に記載のリソース配置決定方法。
【請求項１１】
前記複数のノードの第８のノードで障害が発生した場合、第８のノード上で動作する仮想マシン或いはコンテナを特定し、
前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有する第９のノードに、前記第８のノード上で動作する仮想マシン或いはコンテナを、作成する、ことを特徴とする請求項９に記載のリソース配置決定方法。
【請求項１２】
複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおいて、
前記複数のノードの各ノードは、
データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
前記ストレージコントローラは、データの記憶領域となるボリュームを経由して自ノードのドライブに対するデータの読み書き制御と、他ノードのドライブに対する冗長化処理を実行し、
前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を管理し、
前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する管理部とを、有することを特徴とするストレージシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ハイパーコンバージドインフラストラクチャ（HCI）環境でのVM／コンテナおよびデータ配置決定に関する技術である。
【背景技術】
【０００２】
近年、ソフトウェア（例えば、OS）の層を追加することによって、ハードウェア（例えば、CPUおよび周辺機器）を仮想化して、ユーザからのハードウェアとのインターフェース方法の詳細を「隠す」技術である仮想化技術が広く用いられている。
【０００３】
この仮想化技術は、複数の仮想化コンピュータ（例えば、VM、コンテナ）が物理リソースを共有することを可能にし、１つの仮想化コンピュータによる非活動期間中に別の仮想コンピュータが共有リソースを利用して、物理デバイスを効率よく使用可能となりリソース管理コストが改善される。しかしながら、VMを搭載した多くのストレージネットワーク環境では、VMまたは仮想サーバがSAN内の同じファイルシステムを共有するため、輻輳やボトルネックが発生する可能性がある。複数のサーバによって構成されるシステムにおいて、ストレージIO負荷分散方法は、VMを異なる物理サーバに移動することによって負荷の分散する技術が、特許文献１に開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開第２００９／０１７２６６６号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１は、VMとストレージOSで計算機資源を共有する、所謂ハイパーコンバージド（HCI）環境での計算機資源の有効利用については言及されていない。即ち、VMで動作するアプリケーションによるデータを処理するための計算機資源と、ストレージOS（ストレージコントローラ）がアプリケーションからのデータのリード/ライトを処理するための計算機資源の双方を考慮して、どのノードにVMやボリューム等を配置すべきかについて言及されていない。
【０００６】
また、複数ノード間でデータの冗長化を行っている場合に、他のノードのストレージコントローラからの冗長化データのライト処理のためにストレージコントローラが利用する計算機資源を考慮した、VMやボリュームの配置については言及されていない。
【０００７】
そこで、本発明の目的は、HCI環境において、ノードの計算機資源の上限を超えることなく、新規VM/コンテナやボリュームを作成するVM／コンテナおよびボリューム配置決定方法およびストレージシステムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、上記の課題を解決するためのリソース配置決定方法の一例を挙げるならば、複数のノードを有し、複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、複数のノードの各ノードは、データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置とを含む計算機資源を有し、各ノード上で動作する、仮想マシン及びストレージコントローラが、共用する前記計算機資源の利用状況を管理し、管理部が、前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する。
【発明の効果】
【０００９】
本発明によれば、VM/コンテナ、ボリュームの条件に基づいて、ノードの計算機資源の上限を超えることなく、新規VM/コンテナやボリュームの作成をすることができる。
【００１０】
また、新規に作成するVM/コンテナやボリュームの条件を満たすノードがない場合であっても、既存のVM/コンテナやボリュームを移動した結果、条件を満たす計算機資源が確保できるノードがあった場合、条件を満たすように既存のVM/コンテナやボリュームを移動し、ノードの計算機資源の上限を超えることなく、新規にVM/コンテナやボリュームを作成することができる。
【００１１】
ノード障害時に、障害が発生したノード上に配置されていたVM、コンテナやボリュームを、ノードの計算機資源を超えることなく、新規に作成されるVM/コンテナやボリュームの配置先を算出し、再冗長化することができる。
【００１２】
マルチノード構成のストレージシステムで、データの冗長度に基づいて他ノードからのIOを考慮して、ノードで発生するIO量を計算して、VM/コンテナやボリュームの配置先を計算することができる。
【図面の簡単な説明】
【００１３】
【図１】システムの全体構成の概要説明図である。
【図２】システムの全体構成図である。
【図３】ノードのハードウェア構成図である。
【図４】複数のノードを用いたクラスタの論理構成を示した図である。
【図５】ノードのメモリに格納される各種プログラムと制御情報を示した図である。
【図６】ノードのメモリに格納されるストレージノード物理構成表を示した図である。
【図７】ノードのメモリに格納されるVM管理表を示した図である。
【図８】ノードのメモリに格納されるコンテナ管理表を示した図である。
【図９】ノードのメモリに格納されるアプリ管理表を示した図である。
【図１０】ノードのメモリに格納されるストレージノード構成表を示した図である。
【図１１】ノードのメモリに格納される容量稼働情報を示した図である。
【図１２】ノードのメモリに格納されるIO量管理表を示した図である。
【図１３】ノードのメモリに格納される性能稼働情報を示した図である。
【図１４】ノードのメモリに格納されるノード単位稼働情報を示した図である。
【図１５】新規作成VM/コンテナおよびボリュームの配置決定する処理フロー図である。
【図１６】VM/コンテナ作成条件を満たすノード群を算出するフロー図である。
【図１７】既存VM/コンテナの移動により条件を満たすか計算するフロー図である。
【図１８】実施例２のノード障害時のVM/コンテナおよびボリューム配置を決定するフロー図である。
【図１９】実施例３の異なる二つのノード内の二つのストレージコントローラによりペアを組んだ構成を示した図である。
【図２０】実施例３のストレージコントローラの構成情報を示した図である。
【図２１】実施例３のVM/コンテナ作成条件を満たすノード群を算出するフロー図である。
【図２２】実施例３の既存VM/コンテナの移動により条件を満たすかを計算処理するフロー図である。
【図２３】実施例４のノード障害時のVM/コンテナおよびボリュームの配置決定処理を示すフロー図である。
【図２４】実施例５の新規作成VM/コンテナおよびボリュームの配置決定する処理フロー図である。
【図２５】実施例５のVM/コンテナ作成条件を満たすノード群を算出するフロー図である。
【図２６】実施例５の既存VM/コンテナの移動により条件を満たすか計算するフロー図である。
【図２７】実施例６のシステムの全体構成図である。
【発明を実施するための形態】
【００１４】
＜明細書中の用語の定義＞
以下、本発明の実施の形態を、図を用いて説明する。各図において、同一の構成には同一の符号を付す。
以下、発明の実施の形態を、図面を参照して詳細に説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。
【００１５】
図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。
【００１６】
以下の説明では、「テーブル」、「リスト」、「キュー」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」、「Ｒｅｇｉｏｎ」等の表現を用いるが、これらについてはお互いに置換が可能である。
【００１７】
同一あるいは同様な機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。
【００１８】
また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ、ＧＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えば記憶装置）および／またはインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、制御部であれば良く、特定の処理を行う専用回路（例えばＦＰＧＡやＡＳＩＣ）を含んでいてもよい。
【００１９】
プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
【００２０】
＜仮想化の概要＞
本発明が適用される「仮想化」について、以下説明する。
「仮想化」という用語は、コンピュータやオペレーティングシステム（OS）の領域、ストレージとネットワークの領域で多くの意味を持っている。ソフトウェア（例えば、OS）の層を追加することによって、ハードウェア（例えば、CPUおよび周辺機器）を仮想化して、ユーザからのハードウェアとのインターフェース方法の詳細を「隠す」ことができる。同様に、OSは、ソフトウェアの層（例えば、ハイパーバイザ）を追加することによって、OSとのインターフェース方法の詳細を「隠す」ように、仮想化することができる。ユーザは、特定のOSや特定のベンダーやハードウェアの特定の構成など、基盤となるインフラストラクチャに強く依存することなく、いくつかの機能を実行するためのコードを書くことができる。
【００２１】
「仮想マシン」または「VM」とは、実際のコンピュータ（例えば、CPU、メモリなど）のハードウェアリソースを仮想化または仮想化環境に変換する、仮想化環境における特定のソフトウェアベースのマシンの実装を意味する。本明細書では、「仮想マシン」を単に「VM」と表記する場合がある。実際のコンピュータと同じように、基本的な物理リソース上で独自のOSとアプリケーションを実行できる、完全に機能する仮想マシンをサポートする。仮想化は、コンピュータハードウェアまたはホストOS上にソフトウェアの薄い層を直接挿入することによって機能する。このソフトウェア層には、ハードウェアリソースを動的かつ透過的に割り当てる仮想マシンモニターまたは「ハイパーバイザ」が含まれている。複数のOSが単一の物理コンピュータ上で同時に実行され、ハードウェアリソースを互いに共有する。
【００２２】
近年、コンテナベースの仮想化技術が普及している。ホストのOS上で実行される仮想マシンを作成して独立した物理マシンを模倣する仮想マシンと比較して、コンテナはOSのカーネル上で、直接ユーザ空間で実行できるアプリケーションを仮想化する。コンテナ内から実行されるWebサーバやデータベースなどのアプリケーションでは、物理マシンとのインターフェースにエミュレーションレイヤーまたはハイパーバイザーレイヤーは必要がない。代わりに、"コンテナ化された"アプリケーションは、OSの通常のシステムコールを使用して機能することができる。このようにして、コンテナは仮想化されたゲストOSを必要としないため、コンテナは、仮想マシンより一般的に速い（例えば、転送が速く、ブートまたはロードが速い）OSレベルの仮想化を提供する。
【００２３】
仮想マシンやコンテナなどの仮想化テクノロジが広く採用されている理由の１つは、仮想アーキテクチャによって提供されるリソースの利点があるためである。仮想化がなければ、物理マシンが単一の専用OSに限定されている場合、専用OSによる非アクティブ期間中、物理マシンは有益な作業を実行するために使用されない。これは、現在コンピューティングリソースを待っている他の物理マシン上のユーザがいる場合、無駄で非効率的なものとなる。対照的に、仮想化は、複数の仮想化コンピュータ（例えば、VM、コンテナ）が物理リソースを共有することを可能にし、１つの仮想化コンピュータによる非アクティブ期間中に別の仮想コンピュータが共有リソースを利用して、物理デバイスを効率よく使用可能となりリソース管理コストが改善される可能性がある。
【実施例１】
【００２４】
実施例１では、基本構成での処理を説明する。基本構成とは、各ノードのCPUやメモリ等の計算機資源を、ハイパーバイザを用いて論理的に分割したハイパーコンバージド構成のことを言う。
【００２５】
＜システム概要＞
図１は、システムの全体構成の概要説明図である。各ノード100には、ハイパーバイザ104が動作しており、物理的なノードの中に、仮想的なコンピュータ（バーチャルマシンVM）を作り出し、同じ物理ノード100内で複数の異なるOSを並列に実行する。
【００２６】
まず、実施例1が動作するシステムの構成について説明する。システムは、複数のノード100から構成され、各ノード100はCPU101、メモリ102、記憶装置であるドライブ103等の計算機資源を有する。実施例１の実施される環境は、一般的なサーバにコンピューティング機能とストレージ機能を統合し、シンプルな構成を実現した仮想化基盤として知られる、所謂ハイパーコンバージドインフラストラクチャ（HCI）環境である。HCI環境では、アプリケーションを動作させるアプリVM、コンテナとストレージコントローラを動作させるストレージVMが同一ノードに存在し、計算機資源（CPU,メモリなど）を共有する。本明細書では、一般サーバのようにIO命令を出すアプリVM、ストレージコントローラとして動作するストレージVM、およびコンテナを仮想化ソフトと呼ぶ。
【００２７】
従って、各ノード100は、仮想マシン(VM)及びコンテナの少なくとも一つが動作し、仮想マシンの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御する。
【００２８】
アプリVMとコンテナを、単にVM/コンテナと記載することもあるし、ストレージコントローラとして動作するストレージVM（ストレージコントローラ）と対比して単にVM等と記載することもある。
【００２９】
各VM105上のOSはストレージコントローラによって提供されるボリューム経由で記憶装置ドライブへアクセスする。複数のノード100からなるマルチノード構成において、データを冗長化するために、ストレージコントローラの機能によりドライブから構成されるボリュームへライトされるデータは、他のノードのドライブへのライトが実行される冗長化処理を行う。冗長化処理は、例えば、ミラーリング、Erasure Coding技術を用いて実行される。図１において、実線で記載されるライト動作は、ストレージコントローラの機能によりドライブから構成されるボリュームへライトされる動作を示し、点線で記載されるライト動作は、他のノードのドライブへのライトが実行される冗長化処理を示す。
【００３０】
ボリュームへのインプット/アウトプット（IO）を実行するために、物理的には、ドライブへデータを書き込む、またはドライブからデータを読む動作のために、ストレージコントローラはノードのCPUを利用する。点線で示すように、別のノードから冗長化のために転送されたデータを書き込む場合のIO処理でも、ストレージコントローラとしてCPUを利用することとなる。
【００３１】
そのため、各ノードにおいて、アプリVMのIO量により、ストレージコントローラで必要となるCPU利用量の変動の方が、一般的には大きい。
【００３２】
HCI環境では、アプリVMとストレージコントローラVMが共有する計算機資源を考慮して各VMやボリュームを配置する必要があり、本発明では、例えばアプリVMとストレージVMが必要とする計算機資源が、各ノードの計算機資源内に収まるように、アプリVMとストレージVMやボリュームを配置する技術を提案する。尚、実施例１においては、アプリVMとしてコンテナが含まれる形態として説明する。
【００３３】
ストレージコントローラ側で必要なCPU利用量は、アプリVMによるデータR/WのIO量に基づいて、ストレージコントローラとして必要となるCPUリソースを計算する。このときに冗長化度合い（ミラーリング、Erasure Codingのユーザデータとデータ保護のためのパリティデータの比率)も考慮する必要があるが、実施例1では、冗長化によるIO量の計算の説明はしない。冗長化によるIO量の計算については、実施例３以降において説明する。
【００３４】
ボリュームおよびアプリVMの配置（デプロイ）する時に、全てのVMが利用するCPUのCPU利用量の和が、ノードのCPU利用量の上限に収まるようにVMとボリュームを配置する。配置できない場合は、既存のアプリVMとボリュームを別のノードに移動し、ボリュームおよびアプリVMを配置できるように、ノードの計算機資源の利用をシステム内で平準化する。
【００３５】
上記はCPU利用量の例であるが、アプリVMとストレージコントローラVMで共有するリソース（メモリ、 drive容量、NW帯域、etc.）の全てについて、同様に、各リソースの利用量が各ノードの上限値を超えることがないようにするため、各リソースについてボリュームおよびアプリVMを配置できるように、ノードの計算機資源の利用をシステム内で平準化する。
【００３６】
図１において、各ノード100では、アプリVMがノード内のドライブに対し、データの書き込みや読み出し（IO）処理107を実行している状態を示している。
ノード100aでは２つのアプリVMがIO処理を実行し、ドライブは2つのアプリVMからのIO処理を実行している。ノード100bでは、１つのアプリVMがIO処理を実行し、ドライブにIO処理を実行している。ノード100cではドライブに対するIO処理を実行していない。
【００３７】
アプリVM側とドライブ側のIO処理の合計は、ノード100aでは「２」、ノード100bでは「１」、ノード100cでは「０」となり、ノード間で負荷が偏っている状態である。
【００３８】
図１では、実施例1として、各ノード100がドライブCPU101、メモリ102、各VM105、ドライブ103等の計算機資源の稼働情報を収集106し、ノード100aが稼働情報に基づき、ノード間の負荷が平準化するようにボリュームとアプリVMを、ノード100cに配置するための配置計算を行い、実際にノード100cに新しいVMやボリュームを作成する配置実行処理108を行う方法について説明する。
【００３９】
図２は、システムの全体構成図である。図２に示したように、通常、複数のノード100によりクラスタ203を構成し、フロントエンドネットワーク201によりクライアントノード200と接続され、バックエンドネットワーク202によりクラスタを構成する複数のノード100が接続されている。但し、フロントエンドネットワーク201とバックエンドネットワーク202は同一のネットワークで構成されていても良く、フロントエンドネットワーク201とバックエンドネットワーク202の他に管理用ネットワークにより複数のノードが接続される構成であっても良い。
【００４０】
各ノード100では、ハイパーバイザが動作しており、ハイパーバイザ上に作成されたVM上でストレージコントローラ、アプリケーションやコンテナが動作している。
【００４１】
図３は、ノード100のノードのハードウェア構成図である。図３に示したように、各ノード100は、一般的な汎用サーバと同様の構成で、CPU101、メモリ102、記憶装置であるNVMeドライブ103a、SASドライブ103b、SATAドライブ103cとこれらを接続する内部バス302で構成される。さらに、外部装置とのデータの送受信等のためのネットワークI/F301を備えている。尚、CPU101、メモリ102は複数備えていてもよい。また、ドライブは、不揮発メモリ（SCM）や光ドライブであっても良い。また、ネットワークI/F301は、ファイバチャネル（FC）、イーサネット（Ethernet）（登録商標）の他、インフィニバンドでも良く、異なる種類のネットワークを用いても良い。
【００４２】
図４は、複数のノードを用いたクラスタの論理構成を示した図である。クラスタ内には、1以上のプール404がある。プールは、物理ドライブ103の容量を仮想的に管理したものである。プールは、ノード内のドライブのみを扱うノード内プール404aと異なるノードのドライブも管理する跨りプール404bがある。また、管理容易化のため、例えば、複数のノード内プールを組み合わせて、一つの跨りプールとするように、階層構造として管理しても良い。
【００４３】
プールの物理記憶領域は、ドライブ103を所定の小領域に分割し、分割された単位で管理する。ボリューム403は、プールから切り出して作成される。Thin Provisioning技術を用いる場合には、ボリューム403に対するライト要求に応じて、プール404から物理記憶領域がボリュームに対して割り当てられ、ライト処理を実行する。尚、ボリュームはプールを定義することなく、ボリュームに直接ドライブ103の物理記憶領域を割り当てるように構成することもできる。
【００４４】
データストア402は、ボリューム403から作成される。データストア402は仮想マシン（VM）のデータを格納するボリュームであって、VMの構成情報やOSが格納される。VM401は、データストア402から作成される。
【００４５】
ボリューム、データストア、VMの個数の関係は、特に決まったものはなく、例えば、（ボリューム：データストア：VM＝１：１：１でも良いし、１：１：N（Nは正の整数））であっても良い。これらの関係は、後述するストレージ管理プログラム502によって管理される。
【００４６】
図５は、ノード100のメモリ102に格納される各種プログラムと制御情報を示した図である。
各種プログラムとして、ストレージ制御プログラム501、ストレージ管理プログラム502、VM管理プログラム503、コンテナ管理プログラム504、アプリ管理プログラム514、稼働情報収集プログラム505がある。
【００４７】
各種制御情報として、ストレージノード物理構成表507、ストレージノード論理構成表508、VM管理表509、コンテナ管理表510、IO量管理表511、アプリ管理表515、性能稼働情報506、容量稼働情報512、ノード単位稼働情報513がある。
【００４８】
ストレージIO制御プログラム501は、VM/コンテナに提供するボリュームに対するIOの制御を行う（ストレージVM、ストレージコントローラと呼ぶ場合がある）。また、ストレージコントローラ間、ノード間のIOも制御する。また、ストレージIO制御プログラムが制御するIO量を計測する。
【００４９】
ストレージ管理プログラム502は、プール404やボリューム403の作成を実現し、ストレージリソースを管理する。
【００５０】
VM管理プログラム503は、データストア402やVM401を作成したり、VMを異なるノードに移行する。
【００５１】
コンテナ管理プログラム504は、コンテナを作成、管理する。Linux（登録商標）にその機能が付されているものがある。
【００５２】
アプリ管理プログラム514は、VM上で動作するアプリケーションを管理する。
【００５３】
ストレージノード物理構成表507は、各ノード100のCPU、メモリ、ドライブ、ポート等の物理資源を示す情報を管理する。詳細は図６で説明する。
【００５４】
ストレージ論理構成表508は、ノードのプールやボリューム等の論理ストレージ構成を示す情報を管理する。詳細は、図１０で説明する。
【００５５】
VM管理表509は、ノード、ボリュームとVMの構成及びVMに割り当てられる物理資源を管理する情報であり。詳細は、図７で説明する。
【００５６】
コンテナ管理表510は、VMとコンテナの関連およびコンテナに割当てられる資源を管理する情報である。詳細は、図８で説明する。
【００５７】
稼働情報収集プログラム505は、IO量や性能、容量といった各種稼働情報を定期的に収集する機能を実現する。VMの性能やIO量収集処理については、VM管理の一般的なハイパーバイザとハイパーバイザ管理ソフトの機能、およびノードについてはOS付属の一般的な機能（sar等）を利用する。容量収集処理は、一般的なストレージ管理の情報取得機能を利用する。
【００５８】
IO量管理表511は、各VMのリード/ライト量を時系列で管理する情報である。詳細は、図１２で説明する。
【００５９】
アプリ管理表515は、VM上で動作するアプリケーションに関する情報である。詳細は、図９に示す。
【００６０】
性能稼働情報506は、ノード及びVM毎に利用するリソースの利用量を示す。詳細は、図１３に示す。
【００６１】
容量稼働情報512は、ストレージリソースおよびVMの容量を時系列に示す。詳細は、図１１に示す。
【００６２】
ノード単位稼働情報513は、ノード単位でのVM/コンテナ等についてのCPU,メモリ等の計算機資源の利用状況を示す。詳細は、図１４に示す。
【００６３】
制御情報として、ノード間のデータの冗長性を確保するために、同一ノードに配置できないストレージコントローラ等の配置条件表を含めても良い。
【００６４】
これらの表は全ノードで常にコピーして同じ情報を保持しても良いし、事前に決められた１つ以上のノードだけに保持してもよい。また、各ノードに関する情報だけを各ノードに分散して保持してもよい。ストレージ管理プログラム502、VM管理プログラム503、コンテナ管理プログラム504は、各ノードで協調して動作してもよいし、全クラスタのうち、代表プログラムが１つ動作し、全てのクラスタの管理を実行してもよい。また、ノードとは異なる管理サーバ(図示せず)に、ノード単位稼働情報513、ストレージノード論理構成表508を格納し、ストレージ管理プログラム502、VM管理プログラム503、コンテナ管理プログラム504、アプリ管理プログラム514を動作させることにより、VMやコンテナ、ボリューム等の配置先ノードを決定することができる。本明細書では、ノード単位稼働情報513、ストレージノード論理構成表508に基づき、ストレージ管理プログラム502、VM管理プログラム503、コンテナ管理プログラム504、アプリ管理プログラム514によって実現される管理部によって、VMやコンテナ、ボリューム等の配置先ノードを決定する。即ち、管理部は、管理サーバあるいは複数のノードの内の少なくとも一つに実装されることとなる。
実施例１では１ノードの代表プログラムが動作する例を示す。
【００６５】
＜各種制御情報＞
図６は、ノード100のメモリ102に格納されるストレージノード物理構成表507の内容を示した図である。ストレージノード物理構成表507は、ストレージ管理プログラム502によって管理され、ストレージIO制御プログラム501によって参照される。
【００６６】
ストレージノード物理構成表507は、ノード物理リソース表601、CPU物理リソース表602、drive物理リソース表603及びポート物理リソース表604を含む。
【００６７】
ノード物理リソース表601は、ノードを一意に識別する識別子であるノードID6011に対し、各ノードが具備するCPUを一意に識別する識別子であるCPU_IDs6012、メモリ量を示すメモリ6013、ドライブを構成するディスクを一意に識別するディスク_ID6014、ノードのポートを一意に識別するポート_IDs6015を管理する。例えば、ノードID「１」は、CPU_IDが「１」で特定されるCPUと、メモリ量「100」のメモリと、ディスク_ID「１」のドライブと、ポート_ID「１」のポートを有する。これにより、各ノード（ストレージ）の物理構成を管理している。
【００６８】
CPU物理リソース表602は、CPUを一意に識別するCPU_ID6021、CPU_IDに対し、各CPUのコア数6022、周波数6023、ノードとの関連を示すノード_ID6025を管理する。尚、CPUはコア毎に別のIDで管理してもよい。例えば、CPU_ID「１」で示されるCPUは、コア数「１」、周波数「１」GHzで、ノード「１」に配置されていることを示す。
【００６９】
drive物理リソース表603は、ディスクを一意に識別するディスク_ID6031に対し、各ディスクの容量6032、ドライブの種別6033、ノードとの関連の情報であるノード_ID6035等を管理する。
【００７０】
ポート物理リソース表604は、ポートを一意に識別するポート_ID6041に対し、各ポートの種別（FC,iSCSI等）6042、速度6043、ノードとの関連の情報であるノード_ID6045などを管理する。尚、上記各IDは数字でも文字列でもよい。図６では表形式で説明したが、各項目の関係が管理できれば、ドキュメント形式等、他の形式で値を保持してよい。
【００７１】
図７は、ノードのメモリに格納されるVM管理表509の内容を示した図である。この制御情報は、VM管理プログラム503によって管理される。
【００７２】
VM管理表509は、VMを一意に識別する識別子VM_ID7011に対し、VMが配置されているノードを示すノードID7012、VMに対応するデータストアを一意に識別するデータストア_ID7013等の対応を管理する。役割7014は、対VMの役割を示す。例えば「ストレージ制御・管理用」、「VM管理用」、「コンテナ管理用」、「ユーザアプリケーション」などの値を取りうる。「ストレージ制御・管理用」、「VM管理用」、「コンテナ管理用」は一つにまとめて例えば「クラスタ管理用」としてもよい。
【００７３】
また、VMに割り当てられる計算機資源として、CPU、メモリ量、また、必要に応じて、driveを構成するディスク、ポート、ボリュームのIDを7015〜7019のそれぞれのカラムで管理する。
【００７４】
例えば、VM_ID「１」で示されるVMは、ノード_ID「１」に配置され、その役割は、「ストレージ制御・管理」であり、CPU_ID7015は「１」である。
【００７５】
CPUはコアごとに別のカラムとして管理してよい。計算機資源の情報は、IDの他、具体的に各VMに割り当てられる値を保持しても良い。図7のようなテーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。VM_ID等のIDは数字でも文字列でもよい。
【００７６】
図８は、ノードのメモリに格納されるコンテナ管理表510を示した図である。コンテナ管理表510は、コンテナを一意に識別する識別子コンテナID8011に対し、VMを識別するVM_ID8012、IPアドレス8013、コンテナに割り当てられる計算機資源であるCPUのID、メモリ量を管理する。IPアドレスはIPv4でもIPv6でもよい。またIPアドレスでなく、FCで通信をするためのWWNでもよいしその他のプロトコルで通信するための識別情報であっても良い。コンテナ管理表510は、図８に示したようなテーブル形式で無く、ドキュメント形式等、他の形式で値を保持してよい。また、コンテナIDは数字でも文字列でもよい。例えば、コンテナID「１」に対し、VM_ID「１」、CPU_ID「３」、メモリ量「50」が対応している。
【００７７】
図９は、アプリ管理表515の内容を示した図である。この情報は、アプリ管理プログラム514によって管理されている。アプリケーションを一意に識別するApp_ID901に対し、VM（コンテナ）を識別するVM_ID902、ノードID903、用途904を管理する。図９に示したようなテーブル形式で無く、ドキュメント形式等、他の形式で値を保持してよい。また、コンテナIDは数字でも文字列でもよい。例えば、App_ID「１」に対し、VM_ID「１」、ノード_ID「１」、用途「ストレージコントローラ」が対応して管理されている。
【００７８】
図１０は、ノードのメモリに格納されるストレージノード論理管理表508を示した図である。ストレージノード論理管理表508には、プールの構成情報1001とボリュームの構成情報1002が含まれる。ストレージノード論理管理表508は、プールやボリュームといったストレージの論理リソースを示す表である。各リソースに表が存在する。ここでは代表的なものとして、プールとボリュームの例を示す。
【００７９】
プールの構成情報1001には、システム内でプールを一意に識別するプールID10011に対し、プールの容量10012、プールの名前10013、プールが配置されるノードのID10014、ミラー、EC(Erasure Coding)のプールの冗長度10015、冗長先のノードID10016が対応されて管理されている。
【００８０】
ボリュームの構成情報1002は、ボリュームを識別するボリュームID10021に対し、ボリュームの名前10022、ボリュームの容量10023、ブロック数10024、ボリュームが属するプールのID10025、プールが属するノードのID10026、ボリュームと関連するデータストアのID10027、データストアから作成されるVMのID10028や関連するコンテナのID10029などの情報を表す。図９に示したように、テーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
【００８１】
図１１は、ノードのメモリに格納される容量稼働情報512を示した図であり、ストレージリソースおよびVMの中で容量を持つリソースの時系列の情報を示す。容量稼働情報512は、記憶装置から構成される記憶容量の利用状況を管理する。
【００８２】
管理対象がプールの場合は、プールの容量稼働情報1101で管理される。プールの容量稼働情報1101は、システム内でプールを一意に識別するプールのID11011に対し、プールの自体の総容量11012、時刻11013と時刻毎の使用量11014の情報などを管理する。
【００８３】
管理対象がボリュームの場合は、ボリュームの容量稼働情報1102で管理される。ボリュームの容量稼働情報1102は、システム内でボリュームを一意に識別するボリュームID11021、ボリュームの容量11022、時刻11023、時刻毎の使用量11024等の情報を管理する。
【００８４】
管理対象がVMの場合は、VMの容量稼働情報1103で管理される。VMの容量稼働情報1103は、システム内でVMを一意に識別するVM_ID11031、VMの容量11032、時刻11033、時刻毎の使用量11034等の情報を管理する。尚、各情報は、図示したようなテーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
【００８５】
管理対象がアプリケーションの場合は、アプリの容量稼働情報1104で管理される。システム内でアプリを一意に識別するアプリ_ID11041、容量11042、時刻11043、時刻毎の使用量11044等の情報を管理する。
【００８６】
図１２は、ノードのメモリに格納されるVM毎のIO量管理表511を示した図であり、VMのRead/WriteのIO量の時系列での情報を示す。VM毎のIO量管理表511は、VMを一意に識別するVM_ID1201に対し、IOがリードかライトかを示すIO種類1202と、時刻1203、一定時間ごとのIO量1204を対応させて管理する。IO種類には、Sequential R/W, Random R/Wの区別があっても良い。一般的なVMの管理ソフトとして提供されているVM管理プログラム503によって記録される。図１２ではVM毎にIO量を管理している例を説明したが、コンテナ単位でIO量を管理してもよい。また、図１２に示したテーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
【００８７】
図１３は、ノードのメモリに格納される性能稼働情報506を示した図であり、ノード、およびVMごとに利用するリソースの利用量を示す。稼働情報収集プログラム505によって参照、更新される。ノードの性能稼働情報1301は、ノードを一意に識別するノードID13011に対し、CPU利用率、メモリ利用量、使用通信帯域などのメトリック13012、時刻13013、一定時間ごとのCPU利用率、メモリ利用量、使用通信帯域13014を管理する。
【００８８】
また、VMの性能稼働情報1302は、VMを一意に識別するVM_ID13021に対し、CPU利用率、メモリ利用量、使用通信帯域などのメトリック13022、時刻13023、一定時間ごとのCPU利用率、メモリ利用量、使用通信帯域13024を管理する。ノードの性能稼働情報1301とVMの性能稼働情報1302は、他の情報（メモリWrite Pending Rateなど）を保持してもよい。また、コンテナ毎、アプリ毎に同様の性能稼働情報を管理しても良い。また、図１３に示したテーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
【００８９】
他の制御情報として、配置条件表を含めることもできる。例えば、VMごとの配置条件として、VM_IDに対し、VMのタイプを識別するタイプID、NoSQL DB等のアプリケーションの種類を示すタイプ、ボリュームと同一ノード、同一タイプと同じノードで同居しない等の条件を管理する。タイプの情報は、例えば、条件でタイプIDが同じものは同一ノードに作成しない、という目的で利用する。この条件には、VMとボリュームが同一ノードに必ず存在させる必要がある（もしくはボリュームとVMが同一ノードでなくてもよい）、タイプが同じものは異なるノードに存在させる、といった条件を設定する。これらの条件はVMデプロイ時にユーザがVM管理プログラム経由で設定してもよいし、アプリケーションによって自動で設定されるように設定ファイルに記載しておいてもよい。
【００９０】
図１４は、ノードのメモリに格納されるノード単位稼働情報表513を示した図である。ノード単位で、VM/コンテナ、及びアプリごとの、CPU,メモリ、NW帯域等の計算機資源の利用状況を管理する。図は、VMの例として、VM＿IDを管理しているが、コンテナを対象としコンテナ_ID、アプリを対象としてアプリ_IDを管理しても良い。
【００９１】
ノード単位稼働情報表513は、各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を管理する情報である。
【００９２】
図６のストレージノード物理構成表507、図１１の容量稼働情報512、図１２のIO管理表511、図１３の性能稼働情報506、図７のVM管理表509（コンテナの場合は図８のコンテナ管理表、アプリの場合は図９のアプリ管理表）の情報から、ストレージ管理プログラム502が定期的に作成する。図１１、図１２、図１３の稼働情報の履歴からは最新の時刻の情報を抽出して保存する例を示すが、最新の情報だけでなく、履歴情報を保存してもよい。この例はVMごとの情報を記載しているが、コンテナごと、アプリごとの情報を管理してもよい。
【００９３】
例えば、図６のストレージノード物理構成表507からは、各ノードのCPU_ID等の物理的な計算機資源を特定できる。これにより、ノード毎のCPUの上限1402、メモリ上限1404、NW帯域上限1406が把握できる。図７のVM管理表509から各VMと、ノードとCPU_ID等の物理的な計算機資源の対応を把握できる。これにより、ノード_ID1401とVM_ID1410の対応が明らかになる。
【００９４】
図１１の容量稼働情報512から各VMの容量と、各時刻における使用量を特定できるため、VM_IDに対する容量上限11032と使用量11034から、VM毎の容量使用量1414が把握される。VMとボリュームとの対応を管理する図１０ボリューム構成情報1002により、VM毎に割り当てられているボリューム容量を把握することができる。図１２のIO量管理表511から、VM毎のIO量1415が把握できる。また、図１３のVMの性能稼働情報1302から、VM毎のCPU利用率1411、メモリ利用量1412、NW帯域利用量1414が把握できる。
【００９５】
つまり、ノード毎に管理される計算機資源の上限1402、1404、1406と容量上限1408、及びVM毎に管理される利用状況1411−1415が把握される。また、VM毎に割り当てられているボリューム容量も図１０のボリューム構成情報から把握できる。各ノードに配置されるVMは、各ノードに配置されているVMを図７のVM管理表で把握できる。
【００９６】
従って、各ノードに配置される計算機資源（CPU、メモリ、帯域、容量）の上限値と、VMが利用する計算機資源、ボリューム容量の総和を比較することで、図１４に示す対応表が管理され、各ノードにおいて利用されているCPU、メモリ、NW帯域等の計算機資源、記憶装置から構成される記憶容量の利用状況（容量の利用量(率)）を把握することができる。
【００９７】
図１４ではVMごとの情報を記載しているが、コンテナごと、アプリごとの情報を管理してもよい。また、テーブル形式で無くドキュメント形式等、他の形式で値を保持してよい。
【００９８】
＜VM/コンテナおよびボリュームの配置決定処理＞
図１５は、新規作成VM/コンテナおよびボリュームの配置決定する処理フロー図である。この処理は、IOの冗長度を考慮することなく、新規作成VM/コンテナの想定IO量とボリュームの条件を、管理者であるユーザが入力してVM/コンテナを配置するケースである。図１５に示した処理は、主として管理部のストレージ管理プログラム502によって処理されるが、ステップ1508と1504の処理は、新規VMを作成する場合にはVM管理プログラム503により、新規コンテナを作成する場合にはコンテナ管理プログラム504により、処理される。
【００９９】
まず、ステップ1501で、ユーザにより新規作成VM/コンテナの想定IO量、容量、作成個数を入力される。
【０１００】
次に、ステップ1502で、入力情報からVM/コンテナ作成条件を満たすノード群を算出する。この処理の詳細は、図１６を用いて説明する。
【０１０１】
次に、ステップ1503で、条件を満たすノード群があるか判定し、ある場合にはステップ1504に進み、条件を満たすノード群に新規ボリュームと新規VM/コンテナを作成する。
【０１０２】
ステップS1503の判断の結果、条件を満たすノード群がない場合、ステップS1505に進み、既存VM/コンテナの移動により、条件を満たすことができるか計算する。このステップの詳細は、図１７を用いて説明する。
【０１０３】
ステップS1506で、ステップS1505で計算された内容が条件を満たす移動方法があるかを判断する。条件を満たす移動方法がある場合には、ステップS1508に進み、既存ボリュームと既存VM/コンテナを他のノードに移動する。ステップS1508で作成条件を満たしたうえで、ステップS1504の新規ボリュームと新規VM/コンテナの作成処理を実行する。
【０１０４】
ステップS1506で条件を満たす移動方法がないと判断された場合、エラーを返し（S1507）、処理を終了する。
【０１０５】
図１５では、ユーザによる入力情報として、IO量だけでなく、想定負荷としてメモリ使用量等他の値を入力してもよい。
【０１０６】
図１６は、VM/コンテナ作成条件を満たすノード群を算出する処理を示したフロー図である。図１６に示した処理は、図１５のステップS1502の処理に相当し、管理部のストレージ管理プログラム502によって実行される。
【０１０７】
まず、ストレージ管理プログラム502は、図１４に示したノード単位稼働情報1400の容量上限1408と容量利用量1409を参照することで、新規VM/コンテナ向けの空き容量（記憶領域の容量）があるノード群があるかを判定する（S1601）。この処理で、ノード群がなかった場合、容量条件を満たすノード群無し、と判定する（S1607）。
【０１０８】
次に、CPU処理単価とIO量から各ノードで必要なCPU量（CPU時間）を計算する(S1602)。ここで、CPU処理単価は、IO処理に要するCPU時間をIO量で除算した値であって、一つのIOを処理するのに必要となるCPU利用時間と定義される。
【０１０９】
次に、新規VM/コンテナを作成して増加するCPU量（CPU時間）にノード単位稼働情報のCPU利用率1403を加え、ノードのCPU上限1402を超えないノード群を検索する（S1603）。検索の結果、ステップS1603のCPU条件を満たすノードがあれば、ステップ1606に進み、条件を満たすノード群ありと判定する。ステップS1603のCPU条件を満たすノードがなければ、ステップS1605に進み、CPU条件を満たすノード群無し、と判定する。
以上により、容量と計算機資源であるCPUに余力があるノードに新規VM等を作成することができる。
【０１１０】
なお、ボリュームが、Thin Provisioning（仮想的に容量を利用する）の場合は、容量条件のチェックを省略してよい。CPU処理単価は固定で値を持っておいてもよいし、ノードのCPUコア周波数から計算してもよい。この例ではCPU処理単価×IO量でCPU量（CPU時間）の計算によりCPU利用量を算出しているが別の方法でもよい。検索処理は動的計画法等を利用して求められる一つの解を出して条件チェック処理実行、を繰り返してもよいし、全検索をして最も利用率の少ないノード群を検出しても、チェック処理による絞り込みをするようにしてもよい。
CPU条件だけでなく、IO処理のために必要なメモリ量のチェックや通信帯域のチェックを入れてもよい。
【０１１１】
図１７は、既存VM/コンテナの移動により条件を満たすか計算するフロー図である。図１７に示した処理は、図１５のステップS1505の処理に相当し、管理部のストレージ管理プログラム502によって実行される。
【０１１２】
図１６の処理で、容量条件を満たすノード群があり、と判定された場合は、ステップS1702 に進み、ノード単位稼働情報表の情報から既存VM/コンテナのIO1405量を取得する。次に、CPU処理単価とIO量から既存および新規VM/コンテナによるCPU量（CPU時間）を計算する（S1703）。ここで、CPU処理単価とは、IO処理に要するCPU時間をIO量で除算した値であって、一つのIOを処理するのに必要となるCPU利用時間と定義される。
【０１１３】
次に、既存VM/コンテナの移動を考慮してCPU性能上限を超えない組み合わせがあるか検索し（S1704）、CPU条件を満たすノード群ありか判定する（S1707）。判定の結果、CPU条件を満たすノード群がある場合、移動対象のVM/コンテナおよびボリュームとその移動先ノード、さらに新規作成で利用するノードの情報を返却する（S1709）。
【０１１４】
図１６の処理で、容量条件を満たすノード群がない、と判定された場合、ステップS1705に進み、VM/コンテナと紐づくボリュームを移動すれば容量条件を満たせるかを判定する（S1705）。S1705の判定結果がネガティブな場合、移動しても新規VM/コンテナ作成に十分なリソース無し、と返却する（S1708）。S1705の判定結果、VM/コンテナと紐づくボリュームを移動すれば容量条件を満たせる、と判定された場合、VM/コンテナおよびボリュームを移動すると仮定し、図１６の算出処理を再計算する（S1706）。その後ステップS1707に進み、CPU条件を判定し、判定結果に従って、ステップS1708、ステップS1709の処理を実行する。
【０１１５】
このように、図１７の処理は、計算機資源或いは容量に、新規VM等を作成する余力がない場合であっても、既存のVM等を移動することで、ノード間の計算機資源や容量の配分を適正化することで、既存VM等を移動することにより、計算機資源に余力が生じたノード上に新規VM等を作成するための方法を示している。
【０１１６】
図１７では、図１６の算出処理を再計算するときに、移動対象のVM/コンテナおよびボリュームと、これから作成するVM/コンテナおよびボリュームを全て新規作成すると考えて計算する。また、移動VM/コンテナ/ボリューム分の利用リソースは現在の利用量から減算して計算する。移動を考慮した組み合わせが複数検索される場合に、 現在のシステム影響を考慮して、現在のIO量が少ない既存VM/コンテナを移動させる、というように追加の絞り込み検索を実施しても良い。CPU条件だけでなく、IOを処理するために必要なメモリ量のチェックやNW帯域のチェックを入れてもよい。
【０１１７】
図１５から図１７に示したように、既存のVM/コンテナの情報に基づいて、ノードのCPU量の上限を超えることなく、配置条件を満たして新規VM/コンテナを作成することができる。また、新規ボリュームについても、ノードのCPU量や配置条件、容量条件を満たすように作成することができる。また、新規に作成するVM/コンテナやボリュームの条件を満たすノードがない場合であっても、既存のVM/コンテナやボリュームを移動した結果、条件を満たす計算機資源が確保できるノードがあった場合、条件を満たすように既存のVM/コンテナやボリュームの移動を実行することができる。
【０１１８】
上記VM/コンテナ、ボリュームの作成、既存のVM/コンテナやボリュームを移動は、管理サーバや、代表ノードの管理部によって実行される。
【０１１９】
図１５の処理で最終的にエラーが返ってきた場合、システムの管理者は、計算機の物理資源を増やすために、新たなノードをシステムに追加する処理を行うことができる。計算機の物理資源を増やすために追加ノードが必要な場合のみノードの追加を行えばよく、効率の良いシステム運用を可能とする。
【実施例２】
【０１２０】
図１８は、実施例２のノード障害時のVM/コンテナおよびボリューム配置を決定するフロー図である。図１８に示した処理は、管理部のストレージ管理プログラム502によって実行され、実施例１の図１５の処理の変形例として理解できる。この処理は、あるノード障害により、障害発生ノードで動作していたVM/コンテナを再冗長化するケースである。例として、５ ノード（N1,N2,N3,N4,N5）中の３ノード（N1,N2,N3）で２冗長化して動かしていたアプリが動作するVM/コンテナがあり、N1に障害が発生した場合に、N2〜N5のどこかに再冗長化するケースを考える。
【０１２１】
実施例１の図１５の処理では、S1501で、ユーザにより新規作成VM/コンテナの想定IO量、容量、作成個数を入力されていたのに対し、実施例２では、ノード障害を検知（S1801）し、障害ノードで動作していたVM/コンテナのIDを特定（S1802）することで、障害が生じたノードの想定IO量、容量、作成個数を把握する点が異なる。その後、ステップS1803からステップS1808の処理は、図１５で説明したステップS1502からステップS1507と同様であるため、説明は省略する。障害ノードは選択候補からは除外して条件を満たすノード選択処理を実施する。
【０１２２】
実施例２によれば、ノード障害時に、障害が発生したノード上に配置されていたVM、コンテナやボリュームを、ノードの計算機資源を超えることなく、どこに配置すべきかを算出し、再冗長化することができる。
【実施例３】
【０１２３】
図１９は、実施例３の異なる二つのNode内の二つのストレージVM（一つのストレージVMに2台のストレージコントローラ1901、1902を構成）し、各Nodeで2台のストレージコントローラ（1901、1903）によりペアを組んだ構成を示した図である。
【０１２４】
ストレージコントローラ（1901、1904）がNode間で冗長構成（ActiveとStandbyの間で冗長構成）を組む。常に少なくとも１NodeでActiveストレージコントローラ（1901）が動作。この例はActive/Standbyの例を示す。
【０１２５】
あるノードに障害が発生すると、Activeストレージ コントローラに対応するStandbyストレージ コントローラがActiveストレージ コントローラに昇格し、IO処理を継続する（これをFailoveｒと呼ぶ）。図１９の例ではNode2(100b)に障害が発生すると、Activeストレージ コントローラ2が停止し、Node3(100c)のStandbyストレージ コントローラ2がActiveに昇格し、Activeストレージ コントローラ2の処理を継続して実施する。この場合、Node3にActiveストレージ コントローラが2つ存在するため他のノードよりも処理量が増加する。
【０１２６】
あるActiveストレージ コントローラ経由でアクセスしていたデータは他のノードに冗長化されており、Failover後もStandbyストレージ コントローラが昇格後にデータにアクセス可能となる。
【０１２７】
つまり、ノード100aは、ストレージコントローラ1901とボリューム(図示せず)を有し、ストレージコントローラ1901は、Activeのストレージコントローラ1901がIOを処理する。つまり、ストレージコントローラ1901は、アプリVM等の仮想マシンからのボリュームに対するIO要求を処理するアクティブモードとして動作し、ボリュームにデータを書き込む。
【０１２８】
また、ノード100bは、ストレージコントローラ1904とボリューム(図示せず)を有し、ストレージコントローラ1904は、ストレージコントローラ1901の冗長構成となるスタンバイモードとして、ストレージコントローラ1901から冗長データを受け取って、ノード２(100b)のボリュームに冗長データを書き込む。
【０１２９】
図２０は、実施例１の図１０の情報に加え、ストレージコントローラ毎の状態等のストレージコントローラの構成情報を示した図である。図１０と同様、ノードのメモリに格納され、ストレージ管理プログラム502によって管理される。
【０１３０】
ストレージコントローラの構成情報2000は、ストレージコントローラを識別するための識別子2001、に対し、Active/Passive/Standby等の状態2002、ペアの識別子であるグループID2003、ストレージコントローラが配置されている稼働ノードID2004、VM_ID2005が対応して管理されている。状態2002には、障害を示す状態（例：Dead）を保持してもよい。
【０１３１】
図２１は、実施例３の新規作成VM/コンテナおよびボリュームの配置決定する処理フロー図である。実施例１を図１９の構成を利用し、管理部によるデータの冗長化を行う例となる。実施例１の図１６に対応するものが図２１、実施例１の図１７に対応するものが図２２となる。
【０１３２】
基本的な流れは、実施例１の図１６に示した処理と対応する。図１６のステップS1601とステップS1602の間に、ステップS2102のストレージコントローラの冗長度から自ノード以外で発生するIO量を計算する処理を追加している。その他のステップは、図１６のステップに対応するため、説明は省略する。この処理は、データの冗長性を確保するため、異なるノードにデータの複製を記憶するため、自ノードのアプリVMからのIOの他に、他ノードのストレージVMからのIOを考慮するためのステップである。
【０１３３】
図２２は、管理部により実行され、実施例３の既存VM/コンテナの移動により条件を満たすかを計算処理するフロー図である。図２２は、実施例１の図１７に対応し、図１７のステップ1702とステップS1703の間に、ステップS2203において、ストレージコントローラの冗長度から自ノード以外で発生するIO量を計算するステップを設けている。
【０１３４】
他ノードの情報は、図２０から、同一グループIDが同一の値をとるストレージコントローラを特定する。例えば、ノードID「１」に対して、他ノードのIOとして考慮されるストレージコントローラは、ノード「１」のストレージコントローラ「２６」と同一のグループ_ID「３」、即ち、ペアとして管理されるノード「３」のストレージコントローラ「２０」であることが分かる。ストレージコントローラ「２０」は、VM上に乗っているアプリであり、App_IDによって識別可能である。従って、図１３のアプリの性能管理情報をアプリ毎に管理することで、他ノードからのIO量を把握することができる。
【０１３５】
実施例３によれば、マルチノード構成のストレージシステムで、他ノードからのIOを考慮して、ノードで発生するIO量を計算することができる。即ち、自ノードのストレージコントローラと他ノードのストレージコントローラとがペアとなり、他ノードのストレージコントローラがアクティブ状態でアプリVMからのIO処理を行い、自ノードのストレージコントローラがスタンバイ状態となり、冗長データを自ノードに記憶する場合に、他ノードからのIO量を特定し、自ノードで使用するCPU、容量等の計算機資源を計算することが可能となる。
【実施例４】
【０１３６】
実施例４のノード障害時のVM/コンテナおよびボリュームの配置決定処理を示すフロー図である。実施例２の図１８に対応するものであるが、図２３の処理は、ノード障害によりActiveストレージ コントローラが別のノードにFailoverしたときに、障害ノードで動いていたユーザVM/コンテナをどこに配置すべきかを算出する、管理部のVM/コンテナ管理プログラムによる処理である。
【０１３７】
まず、ノード障害を検知する（S2301）。次に、ストレージノード論理構成表のストレージコントローラの関係からActiveストレージコントローラが動作するノードを切替る（S2302）。次に、VM管理表509を参照し、障害ノードで動作していたVM/コンテナのIDを特定する（S2303）。次に、VM/コンテナのIDから性能稼働情報506、IO量管理表511、容量稼働情報512を取得（S2304）する。
【０１３８】
次に、障害ノードにあったVM/コンテナをActiveに昇格したノードに配置してリソース（容量、性能）が問題なく収まるかを判定し(S2306)、リソースが収まる場合、Active昇格ノードに新規ボリュームと新規VM/コンテナ作成する(S2308)。リソースが収まらない場合、障害ノードにあったVM/コンテナを新規作成すると考え、図１５の処理を実施する。
【０１３９】
図２３で示した処理により、ノード障害によりActiveストレージ コントローラが別のノードにFailoverしたときに、ノードの計算機資源の上限の範囲内で、障害ノードで動いていたユーザVM/コンテナをどこに配置すべきかを算出することができる。
【実施例５】
【０１４０】
図２４は、実施例５の新規作成VM/コンテナおよびボリュームの配置決定する管理部の処理フロー図である。図２４の処理は、図１５の処理に対応し、S2407とS2408を除き、ストレージ管理プログラム502によって実行される。実施例３との違いとして、指定された冗長度、および図１０のプールの構成情報で保持している冗長度と冗長化先ノードIDの情報から、他ノードのIO量を特定し、自ノードで使用するCPU、容量等の計算機資源を計算する。
【０１４１】
最初のステップは、ユーザにより新規作成VM/コンテナの想定IO量、容量、データの冗長度、作成個数を入力が入力される（S2401）。データの冗長度が加わる点が、図１５とは異なる。次に、入力情報からVM/コンテナ作成条件を満たすノード群を算出する（S2402）。この処理は、冗長度が加わるため、図２５の処理を行うこととなる。尚、冗長度は、図１０の構成情報に記載の冗長度に対応させる。
【０１４２】
ステップS2403で条件を満たすノードがない場合、既存VM/コンテナの移動により条件を満たすか計算する（S2404）が、冗長度が加わったため、図２６の処理を行う。それ以外は、図１５の処理と同様である。
【０１４３】
図２５は、実施例５のVM/コンテナ作成条件を満たすノード群を算出する、管理部の処理フロー図である。この処理は、実施例１の図１６及び実施例３の図２１の処理に対応する。入力された冗長度から自ノード以外で発生するIO量の計算ステップS2502が追加された点、新規VM/コンテナを作成して増加するCPU量（CPU時間）とノードの性能管理情報のCPU利用率が、ノードのCPU上限を超えないノード群を、指定された冗長度の領域を作成可能なプールを持っているノードの条件下で、検索するステップS2504が追加されている。
【０１４４】
図２６は、実施例５の既存VM/コンテナの移動により条件を満たすか計算する、管理部の処理フロー図である。図２６は、実施例１の図１７及び実施例３の図２２に示した処理と対応する。入力された冗長度から自ノード以外で発生するIO量を計算するステップS2603、既存VM/コンテナの移動を考慮してCPU性能上限を超えない組み合わせが、冗長度条件を満たすプールを持つノードの条件下であるか検索するステップS2605が異なる。
【０１４５】
実施例５によれば、プールの構成情報から冗長化の相手ノードを判断し、他ノードで発生するIO量を考慮して、VMやボリュームの配置先を、ノードの計算機資源の上限値を超えることなく決定することができる。
【実施例６】
【０１４６】
図２７は、実施例６のシステムの全体構成図である。実施例１の図２、実施例３の図１９との相違は、コンテナをHypervisorのVM上OSではなく、Hypervisorを経由しないOS上に作成する構成とした点である。
【０１４７】
この構成では、ユーザデータヘのアクセスはストレージコントローラが提供するボリューム経由である。コンテナ経由の場合はHypervisorを経由せずにIO可能となる。実施例１との違いは、コンテナを特定するときにVMを必要としないこと（VM管理表、コンテナ管理表、ストレージノード論理構成表でコンテナIDとVM_IDの関係を持たないこと。コンテナ管理表のVM_IDカラムがノードIDカラムと変わる）である。
【０１４８】
本発明の観点では、構成のみが変更となり処理フローは変わらない。変形例として、最下層のOSの上に直接ストレージコントローラが動作する構成でもよい。
【符号の説明】
【０１４９】
100：ノード、101：CPU、102：メモリ、103：ドライブ、104：ハイパーバイザ、105：VM、200：クライアントノード、201：フロントエンドネットワーク、202：バックエンドネットワーク、203：クラスタ、301：ネットワークインタフェース、402：データストア、403ボリューム、404：プール、501：ストレージIO制御プログラム、502：ストレージ管理プログラム、503：VM管理プログラム、504：コンテナ管理プログラム、505：稼働情報収集プログラム、506：性能稼働情報、507：ストレージノード物理構成表、508：ストレージノード論理構成表、509：VM管理表、510：コンテナ管理表、511：IO量管理表、512：容量稼働情報、513：ノード単位稼働情報、514：アプリ管理プログラム、515：アプリ管理表。
【図１】
2020052730.tif 000003
【図２】
2020052730.tif 000004
【図３】
2020052730.tif 000005
【図４】
2020052730.tif 000006
【図５】
2020052730.tif 000007
【図６】
2020052730.tif 000008
【図７】
2020052730.tif 000009
【図８】
2020052730.tif 000010
【図９】
2020052730.tif 000011
【図１０】
2020052730.tif 000012
【図１１】
2020052730.tif 000013
【図１２】
2020052730.tif 000014
【図１３】
2020052730.tif 000015
【図１４】
2020052730.tif 000016
【図１５】
2020052730.tif 000017
【図１６】
2020052730.tif 000018
【図１７】
2020052730.tif 000019
【図１８】
2020052730.tif 000020
【図１９】
2020052730.tif 000021
【図２０】
2020052730.tif 000022
【図２１】
2020052730.tif 000023
【図２２】
2020052730.tif 000024
【図２３】
2020052730.tif 000025
【図２４】
2020052730.tif 000026
【図２５】
2020052730.tif 000027
【図２６】
2020052730.tif 000028
【図２７】
2020052730.tif 000029
【手続補正書】
【提出日】令和1年5月30日(2019.5.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンおよびコンテナの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
前記複数のノードの各ノードは、
データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置とを含む計算機資源を有し、
前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を管理し、
管理部が、前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
【請求項２】
前記計算機資源の利用状況は、前記各ノードにおける記憶装置から構成される記憶容量の利用状況、前記各ノードにおけるCPUの利用状況、前記ノードにおけるメモリの利用状況及びネットワーク帯域の利用状況の少なくとも一つである、ことを特徴とする請求項１記載のリソース配置決定方法。
【請求項３】
前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの第１のノード上の仮想マシン、コンテナ、ボリューム及び前記ストレージコントローラの何れかを他のノードに移行させ、前記第１のノードを前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項２に記載のリソース配置決定方法。
【請求項４】
前記複数のノードの第２のノードで障害が発生した場合、第２のノード上で動作する仮想マシン或いはコンテナを特定し、
前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有するノードに、前記第２のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを第３のノードに作成する、ことを特徴とする請求項１に記載のリソース配置決定方法。
【請求項５】
前記複数のノードの第２のノードで障害が発生した場合、第２のノード上で動作する仮想マシン或いはコンテナを特定し、
前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有するノードに、前記第２のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを第３のノードに作成する、ことを特徴とする請求項３に記載のリソース配置決定方法。
【請求項６】
複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、前記仮想マシンおよび前記コンテナの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
前記複数のノードのそれぞれは、
データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
前記複数のノードの第４のノードは、第１のストレージコントローラと第１のボリュームと第１のドライブを有し、前記第１のストレージコントローラは、前記仮想マシンからの前記ボリュームに対するIO要求を処理し、前記第１のドライブにデータを書き込み、
前記複数のノードの第５のノードは、第２のストレージコントローラと第２のボリュームと第２のドライブとを有し、前記第２のストレージコントローラは、前記第１のストレージコントローラの冗長先のストレージコントローラとして動作し、前記第１のストレージコントローラから冗長データを受け取って、前記第２のドライブに冗長データを書き込み、
前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが共用する前記計算機資源の利用状況に、前記冗長データの書き込みのための計算機リソースも合わせて管理し、
管理部が、
前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
【請求項７】
前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの特定のノードの仮想マシン、コンテナ、ボリューム及び前記ストレージコントローラの何れかを他のノードに移行させ、前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項６に記載のリソース配置決定方法。
【請求項８】
前記複数のノードの第６のノードで障害が発生した場合、第６のノード上で動作する仮想マシン或いはコンテナを特定し、
前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有する第7のノードに、前記第６のノード上で動作する仮想マシン、コンテナ及びボリュームの少なくとも一つを、作成する、ことを特徴とする請求項７に記載のリソース配置決定方法。
【請求項９】
複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン(VM)及びコンテナの少なくとも一つが動作し、前記仮想マシンおよび前記コンテナの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、
前記複数のノードの各ノードは、
データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
前記複数のノードの内、データの冗長化を行うための冗長構成を管理し、
前記ストレージコントローラは、データの記憶領域となるボリュームを経由して自ノードのドライブに対するデータの読み書き制御と、前記冗長構成に基づき、他ノードのドライブに対する冗長化処理を実行し、
前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を、前記冗長構成を考慮して管理し、
管理部が、
前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する、こと特徴とするリソース配置決定方法。
【請求項１０】
前記計算機資源の利用状況に基づき、新規の仮想マシン或いはボリュームの配置先となるべきノードがない場合、前記複数のノードの一つのノード上の仮想マシン、コンテナ及び前記ストレージコントローラの何れかを他のノードに移行させ、前記複数のノードの内の特定のノードを前記新規の仮想マシン或いはボリュームの配置先となる、ことを特徴とする請求項９に記載のリソース配置決定方法。
【請求項１１】
前記複数のノードの第８のノードで障害が発生した場合、第８のノード上で動作する仮想マシン或いはコンテナを特定し、
前記特定された仮想マシン或いはコンテナが利用する、記憶領域の容量、CPU量を計算し、
前記計算機資源の利用状況に基づき、前記計算された記憶領域の容量およびCPU量を有する第９のノードに、前記第８のノード上で動作する仮想マシン或いはコンテナを、作成する、ことを特徴とする請求項９に記載のリソース配置決定方法。
【請求項１２】
複数のノードを有し、前記複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、前記仮想マシンおよび前記コンテナの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおいて、
前記複数のノードの各ノードは、
データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置を含む計算機資源を有し、
前記ストレージコントローラは、データの記憶領域となるボリュームを経由して自ノードのドライブに対するデータの読み書き制御と、他ノードのドライブに対する冗長化処理を実行し、
前記各ノード上で動作する、前記仮想マシン及び前記ストレージコントローラが、共用する前記計算機資源の利用状況を管理し、
前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する管理部とを、有することを特徴とするストレージシステム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
本発明は、上記の課題を解決するためのリソース配置決定方法の一例を挙げるならば、複数のノードを有し、複数のノードのそれぞれが、仮想マシン及びコンテナの少なくとも一つが動作し、仮想マシンおよびコンテナの少なくとも一つはストレージOSが動作するストレージコントローラとなり、データの記憶領域となるボリュームに対するデータの読み書きを制御するハイパーコンバージドインフラストラクチャ環境のシステムにおける、仮想マシン、コンテナ及びボリュームの少なくとも一つの配置を決定するリソース配置決定方法において、複数のノードの各ノードは、データを処理するCPUと、メモリと、プログラム、制御情報及びデータを記憶する記憶装置とを含む計算機資源を有し、各ノード上で動作する、仮想マシン及びストレージコントローラが、共用する前記計算機資源の利用状況を管理し、管理部が、前記利用状況に基づいて、配置先ノードの計算機資源の上限を超えないように、新規の仮想マシン、コンテナ或いはボリュームの配置先ノードを決定する。