JP7106603B2 - 計算機システム及び計算機システムの運用管理方法 - Google Patents

Description

本発明は、計算機システム及び計算機システムの運用管理方法に関する。

近年、計算機システムなどの運用コストを削減するため、運用管理操作の自動化が進んでおり、テンプレートや構成定義ファイルを利用して一連の運用管理操作を自動実行する技術がある。例えば特許文献１には、サービステンプレートを作成し、サービステンプレートと、サービステンプレートの入力プロパティへの入力値とに基づいて運用サービスを生成し実行することで対象装置を運用する管理システムが開示されている。

国際公開第２０１６／０８４２５５号公報

しかしながら、上述の従来技術では、サービステンプレート実行後に、負荷が偏りリソースを効率よく利用できない場合があるという問題がある。サービステンプレートを実行することで一連の運用管理操作を自動化しても、運用サービスの実行基盤について知識がある管理者が管理ツールなどで負荷状況等を把握しなければ、負荷の偏る処理を実行してしまう可能性がある。特にプライベートクラウドのように多くのワークロードが動作する環境や、スケールアウト環境のような大規模環境では、負荷が偏りリソースを効率よく利用できないことで、運用コストが増大する。

本発明は、上述の点を考慮してなされたものであって、負荷を考慮した対象装置の運用管理の自動化を実現することを１つの目的とする。

上記課題を解決するために、本発明においては、一態様として、プロセッサを有する複数のノードと、記憶装置とを有し、前記ノードは、プロセッサにより、ホストが前記記憶装置に入出力するデータを処理する計算機システムにおいて、管理部は、ホストが提供するサービスを記載したサービステンプレートと、所定のパラメータにて前記サービスを実行するために前記ノードが要するリソースのリソース量を記載した必要リソース表と、を保持し、前記管理部は、前記サービステンプレート及びパラメータの入力を受け付け、前記必要リソース表を参照し、前記入力されたサービステンプレート及びパラメータの組み合せに基づいて必要リソース量を算出し、前記算出した必要リソース量の条件を充足するノードを選択して、サービステンプレートにかかるサービスを実行させ、前記サービスの実行前と実行中の前記リソースの負荷の変化に基づいて、前記必要リソース表を更新するようにした。

本発明によれば、例えば、負荷を考慮した対象装置の運用管理の自動化を実現することができる。

実施形態１の概要の説明図。 実施形態１にかかる計算機システムの全体構成を示す図。 実施形態１にかかるノードの構成図。 実施形態１にかかるホストの構成図。 実施形態１にかかる計算機システムの論理構成を示す図。 実施形態１にかかるノード内のメモリ上のプログラム及び情報を示す図。 実施形態１にかかる装置ハードウェア構成表に含まれるノードハードウェア情報を示す図。 実施形態１にかかる装置ハードウェア構成表に含まれるノードポートハードウェア情報を示す図。 実施形態１にかかる装置ハードウェア構成表に含まれるドライブハードウェア情報を示す図。 実施形態１にかかる装置ハードウェア構成表に含まれるホストポートハードウェア情報を示す図。 実施形態１にかかる論理構成表に含まれるプール構成情報を示す図。 実施形態１にかかる論理構成表に含まれるボリューム構成情報を示す図。 実施形態１にかかる稼働情報管理表に含まれるボリュームＩＯ量稼働情報を示す図。 実施形態１にかかる稼働情報管理表に含まれるノード性能稼働情報を示す図。 実施形態１にかかるサービステンプレートを示す図。 実施形態１にかかる必要リソース表を示す図。 実施形態１にかかるサービス実行処理を示すフローチャート。 実施形態１にかかる必要リソース表更新処理を示すフローチャート。 実施形態２にかかる計算機システムの機能構成を示す図。 実施形態２にかかるノード内のメモリ上のプログラム及びデータを示す図。 実施形態２にかかる論理構成表にさらに含まれるデータストア構成情報を示す図。 実施形態２にかかる論理構成表にさらに含まれるＶＭ構成情報を示す図。 実施形態２にかかる稼働情報管理表にさらに含まれるＶＭ性能稼働情報を示す図。 実施形態３にかかる計算機システムの全体構成を示す図。 実施形態４にかかるノード内のメモリ上のプログラム及びデータを示す図。 実施形態４にかかるＳＬＡ表を示す図。 実施形態４にかかるホスト割り当てリソース表を示す図。 実施形態４にかかるサービス実行処理を示すフローチャート。 実施形態４にかかるサービス実行処理を示すフローチャート。

以下、本発明の好適な実施形態を説明する。以下において、同一又は類似の要素及び処理に同一の符号を付して差分を説明し、重複説明を省略する。また、後出の実施形態では、既出の実施形態との差分を説明し、重複説明を省略する。

また、以下の説明及び各図で示す構成及び処理は、本発明の理解及び実施に必要な程度で実施形態の概要を例示するものであり、本発明に係る実施の態様を限定することを意図する趣旨ではない。また、各実施形態及び各変形例は、本発明の趣旨を逸脱せず、整合する範囲内で、一部又は全部を組合せることができる。

以下において、数字に付加された添え字や枝番号によって区別される符号が付与された類似の要素を、数字のみの符号によって、添え字や枝番号に関係なく総称する。例えば「１００ａ」「１００ｂ」や「２００－１」「２００－２」といった符号が付与された要素を、「１００」や「２００」といった符号を付与して総称する。また、「ＸＸインターフェース１４ａ」「ＹＹインターフェース１４ｂ」といった、数字に添え字や枝番が付加された符号が付与された類似の要素を、「インターフェース１４」のように、要素の名称の共通部分と数字のみの符号部分を以って総称する。

また、以下において、各種情報を表（テーブル）形式にて説明するが、情報は表形式に限らず、ドキュメント形式やその他の形式であってもよい。また、表の構成は一例であり、表は適宜統合及び分散できる。また、以下において、各表の項目（カラム）として挙げられているＩＤや名前は、レコードを区別可能であれば、番号及び文字列の何れでもよい。

また、以下では、「プログラム」を主語として処理を説明する場合がある。プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェイスデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。

また、プログラムを実行するプロセッサを、目的の処理機能を実現する装置として「ＸＸＸ部」と呼ぶこともできる。また、プロセッサは、処理の一部又は全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記憶メディアであってもよい。

［実施形態１］
＜実施形態１の概要＞
先ず図１を参照して、本発明の実施形態１の概要を説明する。図１は、実施形態１の概要の説明図である。図１に例示する計算機システム１Ｓは、ノード１０ａ，１０ｂを含んで構成されるストレージのクラスタ１を有する。クラスタ１が有するメモリ１２は、ストレージサービス管理プログラム１２１２、稼働情報取得プログラム１２１３、装置ハードウェア構成表１２２１、稼働情報管理表１２２３、サービステンプレート１２２４、及び必要リソース表１２２５を記憶する。ノード１０ａ，１０ｂのそれぞれは、クラスタ１に対してＩＯを発行するホストへVolume（ボリューム）を提供する。

ステップＳ１は、稼働情報取得処理である。稼働情報取得プログラム１２１３は、ステップＳ１の処理を定期的に実行する。ステップＳ１では、稼働情報取得プログラム１２１３は、管理対象の全装置（図１ではノード１０ａ，１０ｂ）から稼働情報を収集する。稼働情報は、例えばボリュームの場合はホストとの間のＩＯ数などの時系列情報であり、ノードの場合はＣＰＵ使用率、メモリ使用量、使用通信帯域などの時系列情報である。続いて、稼働情報取得プログラム１２１３は、収集した稼働情報を、稼働情報管理表１２２３へ履歴として保存する。

ステップＳ２～Ｓ６は、サービス実行処理である。ステップＳ２では、ストレージサービス管理プログラム１２１２は、運用管理者ｈによる管理操作に応じて、サービステンプレート１２２４から、実行するサービスのテンプレート（処理とその実行順序が記載されたテンプレート）を選択する。

次にステップＳ３では、ストレージサービス管理プログラム１２１２は、運用管理者ｈにより管理端末を介して入力された、ステップＳ３で選択されたサービステンプレートに対するパラメータ値の入力を受け付ける。パラメータは、サービス実行によって動作するアプリケーション（以下、アプリと呼ぶ）の要件（アプリ要件）を含む。

次にステップＳ４では、ストレージサービス管理プログラム１２１２は、ステップＳ３で選択されたサービステンプレートと、ステップＳ３で入力されたパラメータに基づいて処理を決定する。次にステップＳ５では、ストレージサービス管理プログラム１２１２は、必要リソース表１２２５に、ステップＳ３で入力されたパラメータが同一のサービステンプレートが存在すれば、そのサービス実行に必要なリソース情報（必要リソース量）を確認する。

次にステップＳ６では、ストレージサービス管理プログラム１２１２は、ステップＳ６で確認した必要リソース量の条件を充足するノード１０を探索し、条件を充足するノード１０で、ステップＳ４で決定した処理を実行（サービス実行）する。図１の例では、処理がボリュームデプロイであり、条件が計算機リソースの充足であり、最も条件が良い（例えば最も負荷が低い）ノード１０ｂにボリュームをデプロイする。

なお、処理は、ストレージボリュームデプロイのほか、プール作成、スナップショット作成、コピーなど、ストレージに係る各種運用操作がある。また、条件には、計算機リソースの充足のほか、例えば処理を複数のノードで行い障害耐性を高めるといった可用性充足がある。

ステップＳ７～Ｓ１０は、サービス実行後の必要リソース表更新処理である。ステップＳ７では、ストレージサービス管理プログラム１２１２は、稼働情報管理表１２２３を参照し、サービス実行前後の稼働情報の差分を計算する。

次にステップＳ８では、ストレージサービス管理プログラム１２１２は、装置ハードウェア構成表１２２１を取得する。次にステップＳ９では、ストレージサービス管理プログラム１２１２は、ステップＳ７で計算した稼働情報の差分と装置ハードウェア構成表１２２１から、サービス実行後の必要リソース量を計算する。次にステップＳ１０では、ストレージサービス管理プログラム１２１２は、ステップＳ９で計算した必要リソース量をもとに必要リソース表１２２５を更新する。

このようにして更新された必要リソース表１２２５をもとにサービスを実行することで、個々の顧客環境に適し、かつ顧客環境の動的な負荷の変化を考慮して適切な場所で処理を実行できるように運用管理の自動化を実現する。

＜実施形態１の計算機システム１Ｓの全体構成＞
図２は、実施形態１にかかる計算機システム１Ｓの全体構成を示す図である。計算機システム１Ｓは、クラスタ１と、１以上のホスト２と、管理端末３とを含む。計算機システム１Ｓにおいて、ホスト２とノード１０は、フロントエンドネットワークＮ１を介して接続される。また、ノード１０同士は、バックエンドネットワークＮ２を介して接続される。また、管理端末３とノード１０は、管理ネットワークＮ３を介して接続される。

なお、フロントエンドネットワークＮ１、バックエンドネットワークＮ２、及び管理ネットワークＮ３は、同一ネットワークでも異なるネットワークでも何れでもよい。また、これらのネットワークは冗長化されていてもよい。また、これらのネットワークは、Ethernet（登録商標、以下同様）、InfiniBand（登録商標、以下同様）、無線の何れでもよい。

クラスタ１は、１以上のノード１０を含んで構成される。ノード１０は、一般的な汎用サーバで構築されたストレージノードである。

ホスト２は、クラスタ１に対してデータＩＯを発行する。ホスト２は、ベアメタルサーバでもハイパーバイザが稼働するサーバでもよい。ハイパーバイザが稼働するサーバであれば、ハイパーバイザ上で仮想マシン（ＶＭ：Virtual Machine）が動作する。

管理端末３は、クラスタ１内のストレージサービス管理プログラム１２１２を操作するための端末である。例えば、管理端末３は、ブラウザなどのＧＵＩを介して入力された操作リクエストを、ストレージサービス管理プログラム１２１２（図６を参照して後述）へ送信する。また、管理端末３は、クラスタ１内のメモリ１２に記憶されるストレージサービス管理プログラム１２１２、稼働情報取得プログラム１２１３や、各種テーブルを記憶してもよい。

なお、図２では、クラスタ１が、ノード１０ａ，１０ｂ，１０ｃを含んで構成される例を示す。また、図２では、ホスト２が、ホスト２ａ，２ｂの２つである例を示す。しかし、クラスタ１を構成するノード１０の数及びホスト２の数はこれに限らない。

＜実施形態１のノード１０の構成＞
図３は、実施形態１にかかるノード１０の構成図である。ノード１０は、プロセッサの一例であるＣＰＵ（Central Processing Unit）１１、記憶部の一例であるメモリ１２、Drive（ドライブ）１３、及びネットワークＩ/Ｆ１４を有する。ＣＰＵ１１及びメモリ１２の数は、図示に限らない。Drive１３は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、その他の不揮発メモリ（ＳＣＭ：Storage Class Memory）など何れでもよい。また、図３では、Drive１３として、NVMe（登録商標、以下同様）_Drive１３ａ、SAS_Drive１３ｂ、SATA_Drive１３ｃの３つを例示するが、ドライブのインターフェース種別及びドライブ数は図示に限らない。

ネットワークＩ/Ｆ１４には、ＦＥ（Front End）ネットワークＩ/Ｆ１４ａ、ＢＥ（Back End）ネットワークＩ/Ｆ１４ｂ、及び管理ネットワークＩ/Ｆ１４ｃが含まれる。ＦＥネットワークＩ/Ｆ１４ａは、ホスト２と通信するためのフロントエンドネットワークＮ１と接続するインターフェースである。ＢＥネットワークＩ/Ｆ１４ｂは、ノード１０間で通信するためのバックエンドネットワークＮ２と接続するインターフェースである。管理ネットワークＩ/Ｆ１４ｃは、管理端末３と通信するための管理ネットワークＮ３と接続するためのインターフェースである。

なお、ネットワークＩ/Ｆ１４は、Fibre Channel、Ethernet、InfiniBandの何れのインターフェースでもよい。ネットワークＩ/Ｆ１４は、ネットワーク毎に設けられていても、共通のインターフェースとして設けられていてもよい。

＜実施形態１のホスト２の構成＞
図４は、実施形態１にかかるホスト２の構成図である。ホスト２は、ＣＰＵ２１、メモリ２２、Drive（ドライブ）２３、及びネットワークＩ/Ｆ２４を有する。ＣＰＵ２１及びメモリ２２の数は、図示に限らない。Drive２３は、ＨＤＤやＳＳＤ、その他の不揮発メモリなど何れでもよい。また、図４では、Drive２３として、NVMe_Drive２３ａ、SAS_Drive２３ｂ、SATA_Drive２３ｃの３つを例示するが、ドライブのインターフェース種別及びドライブ数は図示に限らない。

ネットワークＩ/Ｆ２４には、ＦＥネットワークＩ/Ｆ２４ａ及び管理ネットワークＩ/Ｆ２４ｃが含まれる。ＦＥネットワークＩ/Ｆ２４ａは、ホスト２と通信するためのフロントエンドネットワークＮ１と接続するインターフェースである。管理ネットワークＩ/Ｆ２４ｃは、管理端末３と通信するための管理ネットワークＮ３と接続するためのインターフェースである。

＜実施形態１の計算機システム１Ｓの論理構成＞
図５は、実施形態１にかかる計算機システム１Ｓの論理構成を示す図である。図５に示す計算機システム１Ｓの論理構成例において、Drive（Drive１０ａ１，１０ｂ１，１０ｃ１）のみが各ノード１０（１０ａ，１０ｂ，１０ｃ）に物理的に紐付けられており、Drive以外は論理的なリソースである。Pool（１０ａ２，１０ｂ２）より上の階層は、ストレージサービス管理プログラム１２１２（図６を参照して後述）から見た論理構成を示している。

図５に示すように、１つのクラスタ１内に１つ以上のPoolがある。Poolは、ノード１０を跨いで設けられてもノード１０内に閉じて設けられても何れでもよい。また、Poolは、管理容易化のために階層構造になっていてもよい。階層構造としては、ノード１０内に閉じるPoolを１つ以上組み合わせてノード１０を跨るPoolとする例がある。

Poolの物理記憶領域は、Driveから割り当てられる。Volume（Volume１０ａ３，１０ｂ３，１０ｃ３）は、Poolから切り出される。Volumeは、ノード１０内に閉じてもよいし、ノード１０を跨ってもよい。なお、Poolを定義せず、Volumeに１つ以上のDriveの物理記憶領域を直接割り当ててもよい。

ホスト２には、ＶＭ（Virtual Machine）を管理するためのHypervisorが動作するサーバと、Volumeを直接マウントするベアメタルサーバとがある。図５の例では、ホスト２ａが、Hypervisorが動作するサーバであり、ホスト２ｂがベアメタルサーバである。

Hypervisorが動作するサーバは、マウントしたVolumeを論理記憶領域として利用するDatastoreを作成する。図５の例では、ホスト２ａは、ノード１０ａのVolume１０ａ３を論理記憶領域として利用するDatastore２ａ１と、ノード１０ｂのVolume１０ｂ３を論理記憶領域として利用するDatastore２ａ２を作成する。

ベアメタルサーバは、サーバ上のＯＳ（Operating System）がVolumeを論理記憶領域としてマウントする。図５の例では、ホスト２ｂは、サーバ上のＯＳがノード１０ｃのVolume１０ｃ３を論理記憶領域としてマウントする。

ホスト２ａは、DatastoreからＶＭをデプロイする。図５の例では、Datastore２ａ１からＶＭ２ａ１１をデプロイし、Datastore２ａ２からＶＭ２ａ２１，２ａ２２をデプロイする。

なお、VolumeとDataStoreとＶＭの数の関係は、特に限定されるものではなく、任意の正整数ｘ，ｙ，ｚについてVolume：Datastore：ＶＭ＝ｘ：ｙ：ｚである。VolumeとDataStoreとＶＭの関係は、後述するように、メモリ１２内のストレージサービス管理プログラム１２１２と、論理構成表１２２２によって管理される。

＜実施形態１のノード１０内のメモリ１２上のプログラム及びデータ＞
図６は、実施形態１にかかるノード１０内のメモリ１２上のプログラム及び情報を示す図である。メモリ１２には、ストレージＩＯ制御プログラム１２１１、ストレージサービス管理プログラム１２１２、及び稼働情報取得プログラム１２１３が記憶されている。また、メモリ１２には、装置ハードウェア構成表１２２１、論理構成表１２２２、稼働情報管理表１２２３、サービステンプレート１２２４、及び必要リソース表１２２５が記憶されている。

なお、図６に示すようにメモリ１２に記憶される各種プログラム及び情報は、クラスタ１を構成する何れか１つのノード１０のメモリ１２に記憶されていても、クラスタ１を構成する複数のノード１０のメモリ１２に、同一内容が配置されても分散配置されてもよく、限定されない。

ストレージＩＯ制御プログラム１２１１は、ストレージコントローラを実現するプログラムであり、ホスト２との間のＩＯを制御する。すなわちホスト２に提供するVolumeに対するRead/WriteのＩＯを制御する。

ストレージサービス管理プログラム１２１２は、ストレージサービス全般の管理機能を提供するプログラムである。すなわち、ストレージサービス管理プログラム１２１２は、ストレージ管理機能（ボリューム作成削除、ボリュームパス設定、コピー作成削除機能等）と、サービス管理機能（サービステンプレート１２２４に記載された処理を解釈し実行する機能等）を提供する。

稼働情報取得プログラム１２１３は、ストレージＩＯ制御プログラム１２１１と連携して、ノード１０及びVolumeの稼働情報（ＩＯＰＳ、Latency、帯域幅、ＣＰＵ利用率、メモリ利用率等）を取得し、保存するプログラムである。

装置ハードウェア構成表１２２１は、ノード１０に関連するハードウェア情報としてＣＰＵ、メモリ、ＦＥ／ＢＥポート、ドライブの情報を示し、ホスト２に関連するハードウェア情報としてクラスタ１と接続するポートの情報を示す。装置ハードウェア構成表１２２１には、ノードハードウェア情報１２２１ａ、ノードＦＥ／ＢＥポートハードウェア情報１２２１ｂ、ドライブハードウェア情報１２２１ｃ、及びホストポートハードウェア情報１２２１ｄが含まれる。

ノードハードウェア情報１２２１ａは、図７Ａに示すように、クラスタ１を構成するノード１０（ノードＩＤ）毎に、ＣＰＵ１１のコア数、周波数、及び処理単価と、メモリ１２の容量及び処理単価とを管理する。ノードＦＥ／ＢＥポートハードウェア情報１２２１ｂは、ノード１０が有するポートの情報を管理し、図７Ｂに示すように、ＩＤ毎に、ノードＩＤ、ＦＥ／ＢＥのネットワーク種別、プロトコル、速度、及び処理単価を管理する。

ドライブハードウェア情報１２２１ｃは、図７Ｃに示すように、ドライブＩＤ毎に、ノードＩＤ、ドライブ種別、容量、速度、Latency、及び処理単価を管理する。

ホストポートハードウェア情報１２２１ｄは、図７Ｄに示すように、ホスト２のInitiatorのＩＤ毎に、ホストＩＤ、プロトコル、速度、及び処理単価を管理する。

処理単価情報は、「１つのＩＯを処理するために必要な時間又はその計算モデル」を示し、ハードウェア毎に異なる。例えばＨＤＤの場合の処理単価は、「シークタイム＋回転待ち時間＋データ転送時間」等でモデル化される。ドライブのＩＯＰＳ（１秒当たりの処理）は、処理単価の逆数から理論上計算できる。本実施形態では、この処理単価情報は、事前にハードウェア毎に測定又は計算したモデルを用いるが、ユーザ入力等により設定及び変更可能としてもよい。

論理構成表１２２２は、リソース毎にストレージの論理リソースを示す情報である。ここでは代表的なものとして、論理リソースとして、プール及びボリュームの例を示す。例えば、論理構成表１２２２には、プール構成情報１２２２ａ及びボリューム構成情報１２２２ｂが含まれる。

プール構成情報１２２２ａは、図８Ａに示すように、プールＩＤ、名前、プールの全容量、全空き容量、プールへ物理記憶領域を割り当てるドライブのＩＤ、プールを構成するノードＩＤとそのノード毎の物理容量、及び空き容量を管理する。

ボリューム構成情報１２２２ｂは、図８Ｂに示すように、ボリュームＩＤ、名前、容量、ブロックサイズ、ボリュームが属するプールのＩＤ、ＩＯ接続可能なホスト２のInitiator情報を管理する。Initiator情報が指定されていない場合は、ホスト２からのアクセス設定が完了していない状態である。

稼働情報管理表１２２３は、ボリュームやノード１０などの稼働情報を時系列で管理する。ここでは稼働情報管理表１２２３が、ボリュームＩＯ稼働情報１２２３ａ及びノード性能稼働情報１２２３ｂを含む例を説明する。

図９Ａでは、ボリュームＩＯ稼働情報１２２３ａとして、ボリュームＩＤ毎に、５秒毎のＩＯ数（Read IO回数、Write IO回数）を記載している。しかし、ＩＯ数に限らず、レイテンシ（応答時間）や転送量であってもよい。また、Read/Writeも、Sequential R/W及びRandom R/Wの区別があってもよい。時刻も任意の時間間隔でよい。また、図９Ａでは、瞬時値を記しているが，ＩＯＰＳのように時刻間の平均値を管理してもよい。

また、図９Ｂでは、ノード性能稼働情報１２２３ｂとして、ノードＩＤ毎に、ＣＰＵ利用率、メモリ利用量、及び通信帯域などのメトリックに対する５秒毎の量を記載している。しかし、メトリックはこれらに限らず、ＣＰＵ１１が余力としてさらに処理可能なＩＯ量（ＣＰＵ残り利用率（１００％－ＣＰＵ利用率）と単位時間にRead/Write可能なＩＯ数から計算）や、メモリ利用率等の情報を保持してもよい。また、メトリックとして、他にポートのデータ転送量、ドライブの稼働率などの情報を保持してもよい。

サービステンプレート１２２４は、サービスと、サービスを実現する構成の作成のための一連の処理及び順序を記載したテンプレートである。サービステンプレート１２２４は、図１０に示すように、テンプレートＩＤ、テンプレートの名前、処理内容、アプリ要件、その他構成を作成するために必要なその他入力情報などを含む。なお、サービス及びアプリは、ストレージを含んだ計算機システム１Ｓの用途の一例である。

処理内容は、サービスを実現するための構成の作成のための処理を実行順で記載した疑似コードであり、図１０では一例を記載している。アプリ要件は、該当サービスを実現するための規模、可用性などの、ストレージ装置構成とは直接関係しないアプリの要件を設定する。ただし、一連の処理を自動で実現するためにサービステンプレート１２２４を利用する場合は、ストレージ装置構成を示すパラメータを入力する場合もある。アプリ要件は、１つだけでなく複数個入力してよい。アプリ要件は、テンプレートの種類（処理内容に記載されている一連の処理）によって決まる。

その他入力情報は、アプリ要件だけでは決定されない必須入力情報を示し、図１０では“Initiators”の１つのみを示すが、複数個入力してよい。

図１０に示す例は、“メールサーバアプリＡ向け”で必要な構成をデプロイするための操作のテンプレートを示す。メールを利用するユーザ数の規模により必要となるデータ領域とログ領域のサイズと必要なボリューム数が異なるため、アプリ要件としてメールサービスのユーザ数の入力が必要になる。また、図１０は、構成を作成するためにさらに必要な、どのホスト２とパス設定をするかを示すInitiator情報を、その他入力情報として入力する必要があることを示している。

必要リソース表１２２５は、サービステンプレート１２２４のテンプレートＩＤとパラメータ（アプリ要件）の組み合わせ毎に、必要とされるリソース量を保持する情報である。必要リソース表１２２５は、構成のデプロイ又はデプロイ変更時に、適所に構成をデプロイするために利用される。必要リソース表１２２５は、サービスをデプロイするために必要なリソース量を示し、ストレージサービス管理プログラム１２１２により管理される。必要リソース表１２２５は、図１１に示すように、必要リソースＩＤ毎に、テンプレートＩＤ、名前、アプリ要件、及び必要リソース量の対応関係を示す。

アプリ要件は、該当アプリを実行するための要件となる情報であり、図１０で示したアプリ要件と同様の情報である。図１１の例では、必要リソースＩＤ：１のレコードには、メールサーバアプリＡの利用ユーザ数を意味する“１００”がアプリ要件に設定されている。アプリ要件には、ユーザ数のほか、複数の情報を含めてよい。

必要リソース量は、該当アプリで設定されたアプリ要件を満たすために必要なハードウェアの要件を示す。必要リソースＩＤ：１の場合は、ＣＰＵ利用率が１０％必要、メモリが１０ＧＢ必要、ということを示している。すなわち、メールサーバアプリＡをユーザ数１００でデプロイする場合は、ＣＰＵ１０％、メモリ１０ＧＢの空きリソースのあるノード１０にデプロイすべき、と判断される。

なお、図１１の例では、全てのノード１０のハードウェアスペックが均質として、必要リソース表１２２５において、各必要リソースＩＤに対して、必要リソース量が１行だけの場合を示している。しかし、これに限らず、各必要リソースＩＤに対して、物理リソース毎に行を分けて複数行の必要リソース量を持ち、各ノードのハードウェア毎に必要リソース量を記載してよい。必要リソース表１２２５における、同一の必要リソースＩＤに対する複数行の必要リソース量に基づいて、ノード１０を分散させて複数のボリュームをデプロイすることもできる。

また、同じアプリをデプロイするテンプレートであっても、アプリ要件が異なる場合は、必要リソース量が異なってくるため、別の必要リソースＩＤを設定する。

そして、必要リソース表１２２５は、図１３を参照して後述する必要リソース量更新処理において、構成のデプロイ及び変更というサービス実行後に必要リソースの見直しを行った際、見直し結果を反映するために更新される。必要リソース表１２２５の更新時において、必要リソース表１２２５における未登録のアプリとアプリ要件の組み合わせの場合には、レコードを新規追加する。

なお、必要リソース表１２２５は、図１３に示す必要リソース量更新処理におけるサービス実行後に更新されるが、運用当初ではアプリとアプリ要件の組み合わせに対応する該当レコードが存在しない。このため、必要リソース表１２２５に、一般的に想定される必要リソース量の値を予め設定したレコードを用意しておいてもよい。

＜実施形態１の処理フロー＞
実施形態１における処理フローは、サービス実行処理と、サービス実行後の必要リソース表更新処理の２つの処理フローに分かれる。サービス実行処理及びサービス実行後の必要リソース表更新処理は、稼働情報取得プログラム１２１３によって、管理対象の全装置から稼働情報が定期的に収集され、稼働情報管理表１２２３に保存されていることを前提とする。

＜実施形態１のサービス実行処理＞
先ず、サービス実行処理について説明する。図１２は、実施形態１にかかるサービス実行処理を示すフローチャートである。

先ずステップＳ１１では、ストレージサービス管理プログラム１２１２は、管理端末３を介してユーザにより入力されたサービステンプレート選択（テンプレートＩＤ）及びパラメータ（アプリ要件とその他項目情報）を受け付ける。

次にステップＳ１２では、ストレージサービス管理プログラム１２１２は、ステップＳ１１で選択されたテンプレートと、入力されたパラメータの値から処理を決定する。次にステップＳ１３では、ストレージサービス管理プログラム１２１２は、必要リソース表１２２５に、ステップＳ１１で入力されたものと同一のサービステンプレートとアプリ要件の組み合わせのレコードが存在するか否かを確認する。サービステンプレートとアプリ要件の組み合わせは、完全一致でなくてもよく、事前に決められた範囲内の値であれば同一とみなしてもよい。

ストレージサービス管理プログラム１２１２は、必要リソース表１２２５に、ステップＳ１１で入力されたものと同一のテンプレートＩＤとアプリ要件の組み合わせのレコードが存在する場合（ステップＳ１４Ｙｅｓ）、ステップＳ１５へ処理を移し、存在しない場合（ステップＳ１４Ｎｏ）、ステップＳ１９へ処理を移す。

ステップＳ１５では、ストレージサービス管理プログラム１２１２は、ステップＳ１４で同一と判断した必要リソース表１２２５のレコードに記載されている必要リソース量の条件を満足するノード１０を探索する。次にステップＳ１６では、ストレージサービス管理プログラム１２１２は、必要リソース量の条件を満足するノード１０が存在するか否かを判定する。ストレージサービス管理プログラム１２１２は、必要リソースの条件を満足するノード１０が存在する場合（ステップＳ１６Ｙｅｓ）、ステップＳ１７へ処理を移し、存在しない場合、ステップＳ１８へ処理を移す。

なお、アプリ要件が、Ｎ倍（又は１／Ｎ倍）すれば一致するように比例関係にある場合は、Ｎ倍（又は１／Ｎ倍）の必要リソースが必要となるとみなしてもよい。例えば、ステップＳ１１で入力されたサービステンプレートがメールサーバアプリＡ向け（テンプレートＩＤ：１）でアプリ要件がUserNum（ユーザ数）＝３００であれば、図１１に示す必要リソース表１２２５において、必要リソースＩＤ：１、テンプレートＩＤ：１、・・・、アプリ要件：UserNum＝１００に対応する必要リソース量（ＣＰＵ：１０％、メモリ：１０ＧＢ）に、アプリ要件の倍数Ｎ＝３を乗じたＣＰＵ：３０％、メモリ：３０ＧＢを、ステップＳ１５のノード探索の条件とする必要リソース量としてもよい。

または、必要リソース表１２２５のレコードを例えばクラスタリングなどによりグループ化しておく。そして、ステップＳ１３では、ステップＳ１１で選択されたテンプレート及び入力されたパラメータの値の組み合わせと所定以上の類似度を有するテンプレート及びパラメータのグループの必要リソース量を、ステップＳ１５のノード探索の条件とする必要リソース量としてもよい。

ステップＳ１７では、ストレージサービス管理プログラム１２１２は、必要リソースの条件を満足する何れかのノード１０でサービスを実行する。一方、ステップＳ１８では、ストレージサービス管理プログラム１２１２は、必要リソースの条件を満足するノード１０が存在しない旨を、管理端末３を介してユーザへ通知する。

またステップＳ１９では、ストレージサービス管理プログラム１２１２は、任意のノード１０でサービスを実行する。

サービス実行処理の結果、サービステンプレート１２２４に記載されている一連の処理が実行される。初回実行時に必要リソース表１２２５においてテンプレートＩＤ及びアプリ要件の組み合わせに該当する必要リソース量の情報が存在しない場合は、任意のノード１０で実行される。２回目以降は、必要リソース表１２２５における必要リソース量の情報に基づいて、必要リソースの条件を充足する適切なノード１０で処理を実行することが可能となる。

＜実施形態１の必要リソース表更新処理＞
次に、必要リソース表更新処理について説明する。図１３は、実施形態１にかかる必要リソース表更新処理を示すフローチャートである。必要リソース表更新処理は、前回のサービス実行後の運用の負荷傾向を見るため、前回のサービス実行から一定時間経過してから次のサービス実行までの間に実行される。

先ずステップＳ２１では、ストレージサービス管理プログラム１２１２は、稼働情報管理表１２２３を参照し、稼働情報を取得する。例えば、ステップＳ２１で取得する稼働情報は、サービス実行前を基準とした過去２４時間分の稼働情報と、サービス実行後を基準とした過去２４時間分の稼働情報である。

次にステップＳ２２では、ストレージサービス管理プログラム１２１２は、サービス実行前とサービス実行後の稼働情報の差を計算する。

次にステップＳ２３では、ストレージサービス管理プログラム１２１２は、装置ハードウェア構成表１２２１に含まれる各ハードウェア情報を取得する。次にステップＳ２３で取得したハードウェア情報とサービス実行前後で変動した稼働情報の値から、今回のサービス実行による影響（サービス実行後に必要なリソース量）を再計算する。

ここで、サービス実行の影響の計算は、一般的な性能見積もり計算方法を利用する。一例として、過去２４時間の平均ＩＯＰＳの最大値増加数を見る。サービス処理実行前後で増加した平均ＩＯＰＳと、図７ＡのＣＰＵの処理単価から、必要なＣＰＵ利用率が算出できる。また、実際に増加したＣＰＵ利用率も取得し、算出されたＣＰＵ利用率と乖離がないかチェックする。このとき、乖離があれば、高い方のＣＰＵ利用率を採用する。同様にメモリやドライブの処理単価から必要な物理リソースを計算する。

より精度を上げるためには、時系列で必要リソース量を保存しておき、影響計算において、一定時間（例えば１時間単位）といった時間刻みで必要リソース量を再計算する。これにより、特定のアプリの時刻や日単位でのワークロード特性を考慮したノード配置が可能となる。

なお、リソース量を見積もるための計算方法（ＩＯの処理単価に基づく見積り）や計算対象（ＩＯＰＳの算出起点）は、限定されるものではなく、例えば単純なＣＰＵ利用率等の最大値増加量を見たり、計算対象をデータ転送量起点としてＩＯＰＳと図８Ｂに記載のブロックサイズから計算する方法などを用いたりしてもよい。

次にステップＳ２５では、ストレージサービス管理プログラム１２１２は、必要リソース表１２２５に、実行されたサービス処理と同一のサービステンプレート（テンプレートＩＤ）とアプリ要件の組み合わせのレコードが存在するか否かを確認する。

ストレージサービス管理プログラム１２１２は、必要リソース表１２２５に、実行されたサービス処理と同一のテンプレートＩＤとアプリ要件の組み合わせのレコードが存在する場合（ステップＳ２６Ｙｅｓ）、ステップＳ２７へ処理を移し、存在しない場合（ステップＳ２６Ｎｏ）、ステップＳ２８へ処理を移す。

ステップＳ２７では、ストレージサービス管理プログラム１２１２は、ステップＳ２６で存在するとされた必要リソース表１２２５の該当レコードの必要リソース量の値を更新する。必要リソース表１２２５の更新方法は、単純に上書きする方法や、前回と今回の計算の平均値をとる方法、再計算された必要リソース量または過去に更新された必要リソース表１２２５を履歴として保存しておき、履歴の学習結果に基づいて必要リソース表１２２５を更新するといった任意の手段であってもよい。履歴の学習結果に基づいて必要リソース表１２２５を更新することで、極端に外れた値は除外するなど、必要リソース量の精度を向上させることができる。

一方ステップＳ２８では、ストレージサービス管理プログラム１２１２は、今回実行したサービステンプレートと、アプリ要件と、今回算出した必要リソース量の各値を持つ必要リソース表１２２５の行を新規追加する。

本実施形態によれば、対象装置の運用管理操作において、アプリ要件などのパラメータさえ入力すれば、アプリやサービスの実行基盤や負荷状態を管理者が把握しなくても、個々の顧客環境により適した、負荷バランスが考慮された構成の作成や変更を行うことができる。

［実施形態２］
実施形態１では、ストレージのクラスタ１が、Hypervisor上にDatastoreとＶＭがマウントされたホスト２を含まない構成を説明した。これに対し、実施形態２では、ＨＣＩ（Hyper Converged Infrastructure）構成を採用し、ストレージのクラスタ１Ｂが、Hypervisor上にDatastoreとＶＭがマウントされたホストを内包する構成について説明する。

＜実施形態２の計算機システム２Ｓの機能＞
図１４は、実施形態２にかかる計算機システム２Ｓの機能構成を示す図である。図１４に示すように、計算機システム２Ｓは、クラスタ１Ｂを含む。図１４において、ホスト及び管理端末の図示を省略している。

クラスタ１Ｂは、ノード１０Ｂａ、１０Ｂｂ、及び１０Ｂｃを含む。ノード１０Ｂａは、Drive１０ａ１、Pool１０ａ２、Volume１０ａ３、Datastore１０ａ４、及びＶＭ１０ａ５を含む。ノード１０Ｂｂは、Drive１０ｂ１、Pool１０ｂ２、Volume１０ｂ３、Datastore１０ｂ４、ＶＭ１０ｂ５、及びＶＭ１０ｂ６を含む。ノード１０Ｂｃは、Drive１０ｃ１、Pool１０ｂ２、Volume１０ｃ３、Datastore１０ｃ４、ＶＭ１０ｃ５、及びＶＭ１０ｃ６を含む。Pool１０ｂ２は、ノード１０Ｂｂ及びノード１０Ｂｃに跨って設けられる。なお、ＶＭは、Volumeと同一のノードに確保されても、Volumeと異なるノードに確保されても何れでもよい。

＜実施形態２のメモリ１２上のプログラム及びデータ＞
図１５は、実施形態２にかかるノード１０Ｂ内のメモリ１２上のプログラム及びデータを示す図である。実施形態１と比較して、実施形態２では、メモリ１２上に、さらにＶＭ管理プログラム１２１４が記憶されている。

ＶＭ管理プログラム１２１４は、ＶＭの作成及び削除など、ＶＭに関する操作を実行すると共に、ＶＭの稼働情報を管理するプログラムである。ＶＭ管理プログラム１２１４は、ストレージサービス管理プログラム１２１２がサービスを実行する過程でＶＭ操作を行う場合に呼び出される。また、ＶＭ管理プログラム１２１４は、稼働情報取得プログラム１２１３から受け付けたＶＭに関する稼働情報の問い合わせに対して、稼働情報を返す。

また、実施形態１と比較して、実施形態２では、論理構成表１２２２にさらにデータストア構成情報１２２２ｃ及びＶＭ構成情報１２２２ｄが含まれている。データストア構成情報１２２２ｃは、図１６Ａに示すように、データストアＩＤ、データストアの名前、容量、及びデータストアが利用するVolumeのＩＤを管理する。ＶＭ構成情報１２２２ｄは、図１６Ｂに示すように、ＶＭ_ＩＤ、ＶＭの名前、容量、及びＶＭが利用するデータストアのＩＤを管理する。

また、実施形態２では、稼働情報管理表１２２３にさらにＶＭ性能稼働情報１２２３ｃが含まれている。ＶＭ性能稼働情報１２２３ｃは、図１７に示すように、ＶＭのＩＤ毎に、ＩＯＰＳ及びLatencyなどのメトリックに対する５秒毎の量を管理する。実施形態１と同様、時刻は任意の時間間隔でよい。なお、メトリックは、図１７の図示のものに限らない。

本実施形態によれば、ストレージのクラスタが、Hypervisor上にDatastoreとＶＭがマウントされたホストを内包するＨＣＩ構成においても、ＶＭを考慮した必要リソース量をもとに、実施形態１と同様に、個々の顧客環境により適した、負荷バランスが考慮された構成の作成や変更を行うことができる。

［実施形態３］
実施形態３は、実施形態１及び２と比較して、各ノードのメモリ１２に記憶される各種プログラム及びデータが、外部の管理サーバ３Ｃに記憶される点が異なる。また、管理サーバ３Ｃが、複数のストレージクラスタを管理対象とし、またクラスタ構成でないストレージシステムも管理対象とする点が異なる。

図１８は、実施形態３にかかる計算機システム３Ｓの全体構成を示す図である。管理サーバ３Ｃは、プログラムを実行するＣＰＵとメモリ（不図示）を有する。管理サーバ３Ｃは、そのメモリ上に、図６に示したメモリ１２上のプログラム及び情報のうち、ストレージＩＯ制御プログラム１２１１を除く、ストレージサービス管理プログラム１２１２、稼働情報取得プログラム１２１３、装置ハードウェア構成表１２２１、論理構成表１２２２、稼働情報管理表１２２３、サービステンプレート１２２４、及び必要リソース表１２２５を記憶する。また、管理サーバ３Ｃは、クラスタ及びストレージシステム毎に、装置ハードウェア構成表１２２１、論理構成表１２２２、稼働情報管理表１２２３、サービステンプレート１２２４、及び必要リソース表１２２５を管理する。これらの表には、例えば、クラスタ又はストレージシステムを識別するＩＤを格納する列が追加される。

本実施形態によれば、複数のクラスタ及びストレージシステムが管理サーバにより管理される構成であっても、クラスタ毎に、実施形態１と同様に、個々の顧客環境により適した、負荷バランスが考慮された構成の作成や変更を行うことができる。

［実施形態４］
実施形態４では、実施形態１と比較して、アプリ要件だけでなく、実行するユーザ毎にＳＬＡの要件（以下、ＳＬＡ要件という）が設定される例を説明する。ＳＬＡ（Service Level Agreement）は、一般的に、サービス提供事業者とユーザとの間で決定される、遵守すべきサービスのレベルである。

本実施形態では、ＳＬＡの情報をもとに実行する制御の例として、ユーザ毎にＳＬＡ要件とユーザが利用するホストとを対応付け、ＳＬＡ要件を遵守するようにホスト毎にリソースを割り当てる。これにより、サービスのレベルが保証される。割り当てるリソースは、物理的なリソース（ＣＰＵコア、メモリ、ドライブ、ポート）でもよいし、仮想的なリソースであってもよい。仮想的なリソースとは、物理的なリソースを仮想的な世界にマッピングし分割したリソースであり、物理的なリソースと仮想的なリソースとのマッピング情報が必要である。本実施形態では、簡単のために、物理的なリソースを割り当てる例を示す。

図１９は、実施形態４にかかるノード内のメモリ１２上のプログラム及びデータを示す図である。図６と比較して、メモリ１２上に、ＳＬＡ表１２２６及びホスト割り当てリソース表１２２７がさらに記憶されている点が異なる。

＜ＳＬＡ表１２２６＞
図２０は、実施形態４にかかるＳＬＡ表１２２６を示す図である。ＳＬＡ表１２２６は、ＳＬＡを保証する単位であるユーザ毎のＳＬＡの情報を表し、ストレージサービス管理プログラム１２１２によって管理される。ＳＬＡ表１２２６は、ＳＬＡの識別子となるＳＬＡ_ＩＤ、ユーザＩＤ、ユーザ名、テンプレートＩＤ、ユーザが利用するホストのＩＤ、ＳＬＡ値を含む。ホストＩＤは、１つのホストＩＤに限らず、複数のホストＩＤを持ってもよい。ＳＬＡ値は、ユーザが利用するサービスで遵守されるべきサービスのレベルを示す。

例えば図２０に示す例では、ＳＬＡ_ＩＤ：１のレコードは、テンプレートＩＤ：１、ホストＩＤ：１及び２のホストを利用するユーザＩＤ：１には、ＩＯＰＳが１００以上であり、Latencyが５０ｍｓｅｃ以内であることが保証されることを示す。

＜ホスト割り当てリソース表１２２７＞
図２１は、実施形態４にかかるホスト割り当てリソース表１２２７を示す図である。ホスト割り当てリソース表１２２７は、ストレージサービス管理プログラム１２１２によって管理され、ホスト毎に割り当てるリソースを示す。本実施形態では、簡単のために、物理リソースを割り当てる例を示すが、仮想リソースを管理し、その仮想リソースを割り当ててもよい。

ホスト割り当てリソース表１２２７は、ホストの識別子となるホストＩＤ、ＣＰＵコアの識別子となるＣＰＵコアＩＤ、メモリの識別子となるメモリＩＤ、ＦＥポートの識別子となるＦＥポートＩＤ、ＢＥポートの識別子となるＢＥポートＩＤ、Driveの識別子となるドライブＩＤなどの値を持つ。

図２１の例では、１レコードに対して各列の値を１つずつ持つ例を示しているが、これに限らず、各列についてそれぞれ複数の値を持ってもよい。また、同一リソースを異なるホストＩＤのホストに同時に割り当ててもよい。また、ホスト割り当てリソース表１２２７において、各ホストＩＤに対して各列に該当する全てのリソースが割り当てられる必要はなく、設定されず空欄があってもよい。

＜実施形態４のサービス実行処理＞
以下、実施形態４のサービス実行処理について説明する。図２２Ａ及び図２２Ｂは、実施形態４にかかるサービス実行処理を示すフローチャートである。

先ずステップＳ３１では、ストレージサービス管理プログラム１２１２は、管理端末３を介してユーザにより入力されたサービステンプレート選択（テンプレートＩＤ）、パラメータ（アプリ要件とその他項目情報）、利用するホストＩＤ、及びＳＬＡ値を受け付ける。ストレージサービス管理プログラム１２１２は、受け付けたテンプレートＩＤ、利用するホストＩＤ、及びＳＬＡ値に基づいてＳＬＡ表１２２６を更新する。なお、ＳＬＡ表１２２６は、ユーザ毎に事前に設定されていてもよい。

次にステップＳ３２では、ストレージサービス管理プログラム１２１２は、ＳＬＡ表１２２６のＳＬＡ値を保証するために必要なリソース量を計算し、ホスト割り当てリソース表１２２７において未割り当てのリソースの中に、計算した必要リソース量を割り当て可能なノード及びリソースが存在するか否かを探索する。ステップＳ３２において、ＳＬＡ表１２２６のＳＬＡ値から必要なノード及びリソース量を計算する方法は、実施形態１の図１３のステップＳ２４のサービス影響の算出で用いた一般的な必要性能見積もり方式を利用する。例えば、ＳＬＡのうちＩＯＰＳ：１００を保証したい場合には、ＩＯＰＳの逆数からＣＰＵの処理単価を計算し、空きのあるＣＰＵがあるかを探索する。同様にメモリ、ポート、ドライブについても処理単価を計算し、必要リソースを見積もる。

次にステップＳ３３では、ストレージサービス管理プログラム１２１２は、ステップＳ２２の探索の結果、割り当て可のノード及びリソースが存在するか否かを判定する。ストレージサービス管理プログラム１２１２は、割り当て可のノード及びリソースが存在する場合（ステップＳ３３ＹＥＳ）にステップＳ２４へ処理を移し、割り当て可のリソースが存在しない場合（ステップＳ３３ＮＯ）に図２２ＢのステップＳ４３へ処理を移す。

次にステップＳ３４では、ストレージサービス管理プログラム１２１２は、ステップＳ３３で存在すると判定された割り当て可のリソース及びノードを、利用候補として記憶領域に一時記憶する。

ステップＳ３４に続くステップＳ３５、Ｓ３６、及び図２２ＢのステップＳ３７は、それぞれ図１２のステップＳ１２、Ｓ１３、及びＳ１４と同様である。

図２２ＢのステップＳ３８では、ストレージサービス管理プログラム１２１２は、ステップＳ２７で同一と判断した必要リソース表１２２５のレコードに記載されている必要リソース量の条件を満足するノード１０及びリソースを探索する。次にステップＳ３９では、ストレージサービス管理プログラム１２１２は、必要リソース量の条件を満足するノード１０及びリソースが存在するか否かを判定する。ストレージサービス管理プログラム１２１２は、必要リソースの条件を満足するノード１０及びリソースが存在する場合（ステップＳ２９Ｙｅｓ）、ステップＳ４０へ処理を移し、存在しない場合、ステップＳ４３へ処理を移す。

ステップＳ４０では、ストレージサービス管理プログラム１２１２は、ステップＳ２９で存在すると判定された条件を満足するノード及びリソースが、ステップＳ３４で一時記憶した利用候補に存在するか否かを判定する。ストレージサービス管理プログラム１２１２は、利用候補に存在する場合（ステップＳ３０ＹＥＳ）にステップＳ４１へ処理を移す。一方、ストレージサービス管理プログラム１２１２は、利用候補に存在しない場合（ステップＳ３０ＮＯ）にステップＳ４３へ処理を移す。

ステップＳ４１では、ストレージサービス管理プログラム１２１２は、ホスト割り当てリソース表１２２７において、ユーザが利用するホストに対してステップＳ３３で割り当て可と判定されたノード及びリソースの情報を追加する。次にステップＳ４２では、ストレージサービス管理プログラム１２１２は、ステップＳ４１でホスト割り当てリソース表１２２７に追加したノード及びリソースの情報に従って、該当ノードで該当リソースを割り当てるように、サービスを実行する。リソースが、ホスト毎に固定で割り当てられることで、ＳＬＡの保証精度を高めることができる。

他方、ステップＳ４３では、ストレージサービス管理プログラム１２１２は、条件を充足するノード及びリソースが存在しない旨をユーザへ通知する。ステップＳ４２又はＳ４３が終了すると、ストレージサービス管理プログラム１２１２は、実施形態４のサービス実行処理を終了する。

なお、必要リソース表更新処理は、実施形態と同様であるため、説明を省略する。

本実施形態では、アプリ要件に基づく必要リソース量と、ＳＬＡを保証するための必要リソース量の両方の条件を充足するかを検証し、両方の条件を充足するリソースをホストに割り当てる。アプリ要件に基づく必要リソース量の条件が無い場合には、ＳＬＡを保証するための必要リソース量の条件を充足するリソースを割り当てる。

よって、本実施形態によれば、ＳＬＡ値をもとにＱｏＳ（Quality of Service）やキャッシュメモリ論理分割機能などの設定を実施することができるため、計算機システムの運用において、顧客に対して性能保証をしつつ、実施形態１と同様に、個々の顧客環境により適した、負荷バランスが考慮された構成の作成や変更を行うことができる。

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例を含む。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、矛盾しない限りにおいて、ある実施形態の構成の一部を他の実施形態の構成で置き換え、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、構成の追加、削除、置換、統合、又は分散をすることが可能である。また実施形態で示した構成及び処理は、処理効率又は実装効率に基づいて適宜分散、統合、又は入れ替えることが可能である。

１Ｓ，２Ｓ，３Ｓ：計算機システム、１，１Ｂ：クラスタ、２，２ａ，２ｂ：ホスト、３：管理端末、３Ｃ：管理サーバ、１０，１０ａ，１０ｂ，１０ｃ，１０Ｂ，１０Ｂａ，１０Ｂｂ，１０Ｂｃ：ノード、１１：ＣＰＵ、１２：メモリ、１３：Drive、１２２４：サービステンプレート、１２２５：必要リソース表、１２２６：ＳＬＡ表、１２２７：ホスト割り当てリソース表

Claims (6)

1. プロセッサを有する複数のノードと、記憶装置とを有し、
   前記ノードは、プロセッサにより、ホストが前記記憶装置に入出力するデータを処理する計算機システムにおいて、
   管理部は、ホストが提供するサービスを記載したサービステンプレートと、所定のパラメータにて前記サービスを実行するために前記ノードが要するリソースのリソース量を記載した必要リソース表と、を保持し、
   前記管理部は、
   前記サービステンプレート及びパラメータの入力を受け付け、
   前記必要リソース表を参照し、前記入力されたサービステンプレート及び前記入力されたパラメータと、レコードをグループ化した前記必要リソース表におけるサービステンプレート及びパラメータとの類似度を計算し、該類似度が所定以上である該サービステンプレート及び該パラメータの組み合せにかかる必要リソース量を用いて、前記入力されたサービステンプレート及び前記入力されたパラメータの必要リソース量を算出し、
   前記算出した必要リソース量の条件を充足するノードを選択して、サービステンプレートにかかるサービスを実行させ、
   前記サービスの実行前と実行中の前記リソースの負荷の変化に基づいて、前記必要リソース表を更新する
   ことを特徴とする計算機システム。
2. 請求項１に記載の計算機システムにおいて、
   前記管理部は、
   前記サービスの実行前と実行中の前記リソースの負荷の変化を記録し、記録した前記リソースの負荷の変化を学習して前記必要リソース表を更新する
   ことを特徴とする計算機システム。
3. 請求項１に記載の計算機システムにおいて、
   前記管理部は、
   さらに、前記サービスに係るＳＬＡ（ServiceLevelAgreement）に基づいて、前記必要リソース量を算出する
   ことを特徴とする計算機システム。
4. 請求項１に記載の計算機システムにおいて、
   前記ノードの上で前記サービスにかかるホストの処理を行うハイパーコンバージドインフラストラクチャ構成である
   ことを特徴とする計算機システム。
5. 請求項１に記載の計算機システムにおいて、
   複数のノードで構成されるストレージクラスタを複数と、前記管理部を有する管理サーバとを含み、
   前記管理部は、
   前記ストレージクラスタ毎に前記必要リソース表を保持し、
   前記ストレージクラスタ毎の前記必要リソース表を参照し、前記ストレージクラスタ毎に受け付けた前記入力されたサービステンプレート及び前記入力されたパラメータの組み合せに基づいて必要リソース量を算出し、
   前記算出した必要リソース量の条件を充足するノードを前記ストレージクラスタ毎に選択し、
   前記ストレージクラスタ毎に選択したノードで、前記ストレージクラスタ毎に受け付けた前記選択されたサービステンプレートに記載されたサービスを実行する
   ことを特徴とする計算機システム。
6. プロセッサを有する複数のノードと、記憶装置とを有し、
   前記ノードは、プロセッサにより、ホストが前記記憶装置に入出力するデータを処理する計算機システムの運用管理方法において、
   管理部は、ホストが提供するサービスを記載したサービステンプレートと、所定のパラメータにて前記サービスを実行するために前記ノードが要するリソースのリソース量を記載した必要リソース表と、を保持し、
   前記管理部が、
   前記サービステンプレート及びパラメータの入力を受け付け、
   前記必要リソース表を参照し、前記入力されたサービステンプレート及び前記入力されたパラメータと、レコードをグループ化した前記必要リソース表におけるサービステンプレート及びパラメータとの類似度を計算し、該類似度が所定以上である該サービステンプレート及び該パラメータの組み合せにかかる必要リソース量を用いて、前記入力されたサービステンプレート及び前記入力されたパラメータの必要リソース量を算出し、
   前記算出した必要リソース量の条件を充足するノードを選択して、サービステンプレートにかかるサービスを実行させ、
   前記サービスの実行前と実行中の前記リソースの負荷の変化に基づいて、前記必要リソース表を更新する
   ことを特徴とする計算機システムの運用管理方法。

Images