JP2021077213A - ストレージ管理装置、ストレージ管理方法およびストレージ管理プログラム - Google Patents

Abstract

【課題】ＩＯ密度に応じた階層化に対応しつつ、ボリューム配置を適正化する。【解決手段】ストレージ管理装置１は、ノードのＩＯＰＳおよび容量の残量に基づいて残ＩＯ密度を算出し、残ＩＯ密度に基づいてノードの階層を制御し、配置対象のボリュームのＩＯ密度とノードの残ＩＯ密度との差分に基づいて、ボリュームが配置されるノードを選択し、その選択時において配置対象のボリュームのＩＯ密度とノードの残ＩＯ密度との差分が最も小さいノードを、ボリュームの配置先として決定する。【選択図】図１

Description

本発明は、ストレージ管理装置、ストレージ管理方法およびストレージ管理プログラムに関する。

ストレージの性能およびコストを最適化するために、性能の異なる複数のストレージを階層化したストレージシステムが登場し、市場シェアを伸ばしている。性能の異なるストレージとは、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）とＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）が挙げられ、それぞれの中にも性能の異なる装置があるため、多様な階層を実現することができる。

また、ストレージのリソース、すなわちアプリケーションの動作に必要なストレージの性能および容量を提供するクラウドサービスを、多くの企業がリリースしている。そのようなサービスでは、データボリュームごとに利用する性能、すなわちＩＯＰＳ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）および容量の値を指定して契約するメニューが用意されていることがある。

このようなストレージサービスのプロバイダでは、階層化したストレージシステムに、契約したデータボリュームを、その契約値に応じて配置することで、ストレージの性能およびコストの最適化を図っている。

特許文献１には、ＩＯＰＳに応じて階層化したストレージシステムが開示されている。具体的には、特許文献１に開示された技術では、ある階層に対してある範囲のＩＯＰＳを対応させ、そのＩＯＰＳの値に応じた階層にデータボリュームを配置する。

特開２０１４−２４１１１７号公報

現在、拡張性およびコスト削減を目的として、複数台の汎用サーバ（以降、ノードと呼称する）で構成されるソフトウェア定義ストレージ（以降、ＳＤＳ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ）と呼称する）の利用が広がっている。そのＳＤＳにおいては、ノードの物理リソースを有効活用するために、「ＩＯＰＳ／容量」で定義されるＩＯ密度に応じた階層化が採用されることがある。ノードの物理リソースは、例えば、ノードを構成するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）、メモリ、ＨＤＤまたはＳＳＤによって提供可能なＩＯＰＳおよび容量である。

しかしながら、特許文献１に開示された方式では、ＩＯ密度に応じた階層化を採用したときに、ある階層に対してある範囲のＩＯ密度を対応させると、階層ごとに対応するＩＯ密度の範囲が初期値に固定される。このため、特許文献１に開示された方式では、データボリューム群の配置状況によっては、階層を構成するノードのＩＯＰＳまたは容量が余り、ノードの物理リソースを有効活用できないことがあった。

本発明は、上記事情に鑑みなされたものであり、その目的は、ＩＯ密度に応じた階層化に対応しつつ、ボリューム配置を適正化することが可能なストレージ管理装置、ストレージ管理方法およびストレージ管理プログラムを提供することにある。

上記目的を達成するため、第１の観点に係るストレージ管理装置は、ノードのＩＯＰＳおよび容量の残量に基づいて残ＩＯ密度を算出し、残ＩＯ密度に基づいて前記ノードの階層を制御する。

本発明によれば、ＩＯ密度に応じた階層化に対応しつつ、ボリューム配置を適正化することができる。

図１は、第１実施形態に係るストレージ管理装置が適用されるストレージシステムの構成を示すブロック図である。 図２は、図１のストレージ管理装置のボリューム配置方法の一例を示す図である。 図３は、階層ごとに対応するＩＯ密度の範囲が初期値に固定されているときのボリューム配置方法の一例を示す図である。 図４は、図１のストレージ管理装置の残ＩＯ密度の更新方法の一例を示す図である。 図５は、図１のストレージ管理装置の残ＩＯ密度の更新方法のその他の例を示す図である。 図６は、図１のノード管理テーブルの一例を示す図である。 図７は、図１のボリューム管理テーブルの一例を示す図である。 図８は、図１の契約受付部の動作を示すフローチャートである。 図９は、図１のストレージ監視部の動作を示すフローチャートである。 図１０は、図１のボリューム配置算出部の動作を示すフローチャートである。 図１１は、第２実施形態に係るストレージ管理装置が適用されるストレージシステムの構成を示すブロック図である。 図１２は、図１１のボリューム配置算出部の動作を示すフローチャートである。 図１３は、第３実施形態に係るストレージ管理装置が適用されるストレージシステムの構成を示すブロック図である。 図１４は、図１３の更新頻度設定部の動作を示すフローチャートである。 図１５は、第４実施形態に係るストレージ管理装置が適用されるストレージシステムの構成を示すブロック図である。 図１６は、図１５のリソース単価管理テーブルの一例を示す図である。 図１７は、図１のストレージ管理装置のハードウェア構成例を示すブロック図である。

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

図１は、第１実施形態に係るストレージ管理装置が適用されるストレージシステムの構成を示すブロック図である。
図１において、ストレージシステムは、ストレージ管理装置１Ａ、ストレージ装置２、顧客端末３および運用端末４を備える。ストレージ管理装置１Ａは、ストレージ装置２、顧客端末３および運用端末４に接続されている。ストレージ管理装置１Ａは、例えば、ストレージ装置２を管理するサーバである。

ストレージ装置２は、物理ボリュームを提供するストレージノード（以下、単にノードということがある）を構成することができる。ストレージ装置２は、例えば、複数の異なるＩＯ密度を持つノード群によって階層化されたＳＤＳであり、ストレージサービスのプロバイダの運用者によって運用される。

顧客端末３は、例えば、インターネットに接続されたＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレットまたはスマートフォンであり、ストレージサービスの顧客によって操作される。

運用端末４は、例えば、インターネットに接続されたＰＣ、タブレットまたはスマートフォンであり、ストレージサービスのプロバイダの運用者によって操作される。

ストレージ管理装置１Ａは、ストレージサービスのプロバイダの運用者の操作によって、運用端末４を通じてストレージ管理装置１Ａの機能に関する設定を受け付け、ストレージサービスの顧客の操作によって、顧客端末３を通じてデータボリューム（以下、ボリュームと呼称する）の契約を受け付け、当該ボリュームの契約内容、ストレージ装置２におけるノードのリソースの利用状態および運用者による設定内容に応じて、当該ボリュームをストレージ装置２の最適なノードに配置する。

このとき、ストレージ管理装置１Ａは、ノードのＩＯＰＳおよび容量の残量に基づいて残ＩＯ密度を算出し、残ＩＯ密度に基づいてノードの階層を制御する。そして、ストレージ管理装置１Ａは、配置対象のボリュームのＩＯ密度とノードの残ＩＯ密度との差分に基づいて、ボリュームが配置されるノードを選択することができる。このとき、ストレージ管理装置１Ａは、例えば、配置対象のボリュームのＩＯ密度とノードの残ＩＯ密度との差分が最も小さいノードを、ボリュームの配置先として決定する。

以下、ストレージ管理装置１Ａの構成および動作について具体的に説明する。
なお、以下の説明は、１つのボリュームが１台のノードに新規に配置される場合を例にとるが、あるノードに配置済のボリュームを他のノードに移行する場合にも適用可能である。また、１つのボリュームが複数台のノードに跨って配置されるような仮想ボリュームを有効とする場合でも、ボリュームに含まれるデータブロックの配置および移行に対して適用可能である。

ストレージ管理装置１Ａは、通信部１１、契約受付部１２、運用パラメタ設定部１３、画面生成部１４、ボリューム配置算出部１５Ａ、ストレージ制御部１６、ストレージ監視部１７および記憶部１８を備える。

記憶部１８は、ノード管理テーブル１８１、ボリューム管理テーブル１８２および更新頻度設定ファイル１８３を格納する。記憶部１８は、これらのテーブルおよび設定ファイルを格納するＨＤＤまたはＳＳＤで構成したり、これらのテーブルを管理するデータベースで構成したりすることができる。

ノード管理テーブル１８１は、ノードに配置されたボリュームおよびボリュームが配置されたノードの残ＩＯ密度を管理する。ボリューム管理テーブル１８２は、ノードに配置されるボリュームのＩＯＰＳおよび容量を管理する。更新頻度設定ファイル１８３は、ノードの残ＩＯ密度の更新頻度を管理する。

通信部１１は、ストレージ管理装置１Ａがストレージ装置２、顧客端末３および運用端末４と外部通信を行ったり、ストレージ管理装置１Ａを構成する各部位との間で内部通信を行ったりするためのインタフェースである。通信部１１を構成するために、ＮＩＣを用いるようにしてもよい。

契約受付部１２は、顧客端末３からストレージ管理装置１Ａに入力されるボリュームの契約値を、通信部１１を介して受信し、記憶部１８のボリューム管理テーブル１８２の契約値に記録し、新規ボリュームの契約を受信したことをボリューム配置算出部１５Ａに通知する。

運用パラメタ設定部１３は、運用端末４からストレージ管理装置１Ａに入力される設定内容を表すデータを、通信部１１を介して受信し、記憶部１８の更新頻度設定ファイル１８３に記録する。

画面生成部１４は、顧客端末３からストレージ管理装置１Ａへのアクセスに応じて、通信部１１を介して、顧客端末３に顧客用の操作画面を出力する他、運用端末４からストレージ管理装置１Ａへのアクセスに応じて、通信部１１を介して、運用端末４に運用者用の操作画面を出力する。顧客は、表示された操作画面を通じてボリュームの契約を行い、運用者は、表示された操作画面を通じてストレージ管理装置１Ａの機能設定を行う。

このとき、画面生成部１４は、ノードの残ＩＯ密度の更新条件を入力可能な操作画面を生成し、運用端末４に表示させることができる。そして、運用者は、ノードの残ＩＯ密度の更新条件を操作画面上で入力し、ストレージ管理装置１Ａに送信することができる。

ボリューム配置算出部１５Ａは、契約受付部１２から、新規ボリュームの契約を受信したことの通知を受けると、記憶部１８のボリューム管理テーブル１８２から当該ボリュームの契約値を読み込み、ノード管理テーブル１８１からノードのリソース使用状況を読み込み、更新頻度設定ファイル１８３から機能設定を読み込む。そして、ボリューム配置算出部１５Ａは、それらのデータおよび設定を元に当該ボリュームを配置するノードを算出し、ノード管理テーブル１８１とボリューム管理テーブル１８２を更新し、当該ボリュームを指定ノードに作成する指示をストレージ制御部１６に通知する。

ストレージ制御部１６は、ボリューム配置算出部１５Ａから、ボリューム配置を指示する通知を受信すると、通信部１１を介して、ストレージ装置２の指定ノードにボリュームを配置する。

ストレージ監視部１７は、通信部１１を介して、ストレージ装置２のノード群およびボリューム群のリソース利用状況を監視し、その結果を記憶部１８のボリューム管理テーブル１８２の実態値に記録するとともに、ノード管理テーブル１８１の配置済と残量を更新する。

図２は、図１のストレージ管理装置のボリューム配置方法の一例を示す図である。
図２において、図１のボリューム配置算出部１５Ａは、配置対象のボリュームのＩＯ密度とノードの残ＩＯ密度に基づいて、ボリュームが配置されるノードを選択する。

例えば、図１のストレージ装置２には、ノードＡ〜Ｃが設けられているものとする。ここで、ノードＡのＩＯ密度の初期値Ａ１は２．０、ノードＢのＩＯ密度の初期値Ｂ１は１．０、ノードＣのＩＯ密度の初期値Ｃ１は０．５であるものとする。なお、図２では、横軸が容量、縦軸がＩＯＰＳを示す座標上の四角形の縦横比がＩＯ密度に相当する。

また、ノードＡに配置済ボリュームＡ２があるときのノードＡの残ＩＯ密度Ａ３は０．２３、ノードＢに配置済ボリュームＢ２があるときのノードＢの残ＩＯ密度Ｂ３は１．７、ノードＣに配置済ボリュームＣ２があるときのノードＣの残ＩＯ密度Ｃ３は０．８６であるものとする。

そして、ボリューム配置算出部１５Ａは、新規ボリュームＮ１〜Ｎ３の配置先をノードＡ〜Ｃから選択するものとする。このとき、ボリューム配置算出部１５Ａは、各新規ボリュームＮ１〜Ｎ３のＩＯ密度と各ノードＡ〜Ｃの残ＩＯ密度との差分をそれぞれ算出し、その差分が最も小さいノードＡ〜Ｃを各新規ボリュームＮ１〜Ｎ３の配置先として決定する。

例えば、新規ボリュームＮ１のＩＯ密度は０．２５、新規ボリュームＮ２のＩＯ密度は０．９、新規ボリュームＮ３のＩＯ密度は１．８であるものとする。このとき、ボリューム配置算出部１５Ａは、新規ボリュームＮ１の配置先をノードＡに決定し、新規ボリュームＮ２の配置先をノードＣに決定し、新規ボリュームＮ３の配置先をノードＢに決定する。

これにより、各ノードＡ〜Ｃの容量およびＩＯＰＳの配分の偏りを抑えつつ、各新規ボリュームＮ１〜Ｎ３を各ノードＡ〜Ｃに配置することができ、各ノードＡ〜Ｃのリソースを有効活用することができる。

図３は、階層ごとに対応するＩＯ密度の範囲が初期値に固定されているときのボリューム配置方法の一例を示す図である。
図３において、新規ボリュームＮ１〜Ｎ３が与えられたときに、各新規ボリュームＮ１〜Ｎ３のＩＯ密度と各ノードＡ〜ＣのＩＯ密度の初期値との差分をそれぞれ算出し、その差分が最も小さいノードＡ〜Ｃに各新規ボリュームＮ１〜Ｎ３が配置されるものとする。

このとき、新規ボリュームＮ１はノードＣに配置され、新規ボリュームＮ２はノードＢに配置され、新規ボリュームＮ３はノードＡに配置される。新規ボリュームＮ１をノードＣに配置すると、ノードＣの容量が不足し、ノードＣのＩＯＰＳが余る。新規ボリュームＮ２をノードＢに配置すると、ノードＢの容量が不足し、ノードＢのＩＯＰＳが余る。新規ボリュームＮ３をノードＡに配置すると、ノードＡのＩＯＰＳが不足し、ノードＡの容量が余る。

このように、各新規ボリュームＮ１〜Ｎ３のＩＯ密度と各ノードＡ〜ＣのＩＯ密度の初期値との差分に基づいて各新規ボリュームＮ１〜Ｎ３を各ノードＡ〜Ｃに配置すると、各ノードＡ〜Ｃのリソース（ＩＯＰＳと容量）の配分の仕方に偏りが発生し、ＩＯＰＳと容量の片方が大きく余る。このため、ノード追加のタイミングが早まり、ノード数が増加する。

これに対し、図２の方法では、新規ボリュームＮ１はノードＡに配置され、新規ボリュームＮ２はノードＣに配置され、新規ボリュームＮ３はノードＢに配置される。このため、新規ボリュームＮ１をノードＣに配置し、新規ボリュームＮ２をノードＣに配置し、新規ボリュームＮ３をノードＢに配置した場合においても、各ノードＡ〜Ｃの容量およびＩＯＰＳの不足を招くことがなくなり、ノード追加の必要がなくなる。

図４は、図１のストレージ管理装置の残ＩＯ密度の更新方法の一例を示す図である。
図４において、図１のボリューム配置算出部１５Ａは、ボリュームを追加するごとに残ＩＯ密度を更新することができる。

例えば、ノードＢの配置済ボリュームＢ４のＩＯ密度が１．１９であり、ノードＢの残ＩＯ密度Ｂ５は０．９４であるものとする。そして、新規ボリュームＮ４がノードＢに配置されたものとする。

このとき、ボリューム配置算出部１５Ａは、ノードＢの残ＩＯ密度を更新する。例えば、新規ボリュームＮ４がノードＢに配置されると、配置済ボリュームＢ６がノードＢに追加され、ノードＢの残ＩＯ密度Ｂ７は０．８９に更新される。

図５は、図１のストレージ管理装置の残ＩＯ密度の更新方法のその他の例を示す図である。
図５において、図１のボリューム配置算出部１５Ａは、「１日ごと」または「ノードのリソースが所定の比率だけ埋まってから」などのように間隔を開けて残ＩＯ密度を更新するようにしてもよい。

例えば、ボリューム配置算出部１５Ａは、１日ごとに残ＩＯ密度を更新するものとする。そして、１日に新規ボリュームＮ５〜Ｎ７がノードＢに配置され、新規ボリュームＮ５のＩＯ密度は１．１９、新規ボリュームＮ６のＩＯ密度は１．１５、新規ボリュームＮ７のＩＯ密度は１．２２であるものとする。このとき、配置済ボリュームＢ８〜Ｂ１０がノードＢに追加され、ノードＢの残ＩＯ密度Ｂ１１は０．６４に更新される。

これにより、新規ボリュームが配置されるごとに残ＩＯ密度を毎回更新する図４の方法に比べて、計算コストを削減することが可能となるとともに、ボリュームの追加傾向によっては、ノードの利用効率を向上させることが可能となる。

なお、残ＩＯ密度の更新タイミングは、ボリューム追加ごとまたは指定時間経過後以外にも、例えば、各ノードのＩＯＰＳの残量および容量の残量に基づいて設定してもよいし、ノードに追加される新規ボリュームのＩＯＰＳおよび容量に基づいて設定してもよい。

図６は、図１のノード管理テーブルの一例を示す図である。
図６において、ノード管理テーブル１８１は、「ノードＩＤ」、「設置日時」、「初期値」、「配置済」、「残量」、「残ＩＯ密度」および「ボリュームＩＤ」のエントリを備える。

「ノードＩＤ」は、図１のストレージ装置２を構成するノードを一意に表す文字列である。

「設置日時」は、ノードがストレージ装置２に組み込まれた日時である。ストレージ装置２は、初期状態において複数のノードで構成される。そして、各ノードの利用状況に応じて、ストレージ装置２にノードが順次追加される。

「初期値」は、ノードにボリュームが配置されていない状態でノードが提供可能なＩＯＰＳと容量である。「ノードＩＤ」と「初期値」は、ノードが追加されるごとにノード管理テーブル１８１に追記されるが、例えば、ストレージサービスの運用者が運用端末４を操作して書き込むようにしてもよい。

「配置済」は、ノードに配置されているボリュームに配分されているＩＯＰＳと容量である。「配置済」は、ボリューム管理テーブル１８２の「契約値」または「実態値」をノードごとに足し合わせた数値であるが、例えば、ボリューム配置算出部１５Ａがボリューム配置を算出するときに配置先ノードに対して更新してもよいし、ストレージ監視部１７がノードの利用状況を監視するときに当該ノードに対して更新してもよい。

「残量」は、まだボリュームに配分されていないノードのＩＯＰＳと容量であり、「初期値」から「配置済」を引くことで得られる。

「残ＩＯ密度」は、「残量」のＩＯＰＳと容量から算出されるＩＯ密度である。「残量」のＩＯＰＳを残ＩＯＰＳ、「残量」の容量を残容量と言う。このとき、残ＩＯ密度は、残ＩＯＰＳ／残容量で定義することができる。ボリューム配置算出部１５Ａは、更新頻度設定ファイル１８３に記載されるタイミングによって残ＩＯ密度を更新する。

「ボリュームＩＤ」は、各ノードに配置されている全てのボリュームを個別のボリュームごとに示すＩＤの羅列である。ノード管理テーブル１８１のボリュームごとの個別のＩＤは、図７のボリューム管理テーブル１８２に記載される「ボリュームＩＤ」と同じ値である。ボリューム配置算出部１５Ａは、ボリューム配置を算出するときに配置先ノードに対してノード管理テーブル１８１の「ボリュームＩＤ」を更新する。

図７は、図１のボリューム管理テーブルの一例を示す図である。
図７において、ボリューム管理テーブル１８２は、「ボリュームＩＤ」、「ノードＩＤ」、「登録日時」、「契約値」および「実態値」のエントリを備える。

「ボリュームＩＤ」は、顧客が契約するボリュームを一意に表す文字列である。契約受付部１２は、ボリュームの契約を受け付けたときに「ボリュームＩＤ」をボリューム管理テーブル１８２に追記する。

「ノードＩＤ」は、ボリュームの配置先であるノードを示すＩＤであり、図６のノード管理テーブル１８１に記載される「ノードＩＤ」と同じ値である。ボリューム配置算出部は、ボリューム配置を算出するときに、対応するボリュームに対して「ノードＩＤ」をボリューム管理テーブル１８２に追記する。ボリューム配置の算出前は、「ノードＩＤ」は、「未配置」に設定される。

「登録日時」は、「ボリュームＩＤ」がボリューム管理テーブル１８２に登録された日時である。

「契約値」は、ボリュームの契約したＩＯＰＳと容量である。契約受付部１２は、ボリュームの契約を受け付けたときに「契約値」をボリューム管理テーブル１８２に追記する。

「実態値」は、配置後のボリュームの利用実態のＩＯＰＳと容量であり、例えば、ＩＯＰＳは、ボリュームの利用中の最大値とし、容量は、ボリュームの利用状況から一定期間後の利用量として予測される値とする。また、「実態値」は、ノードに対して重複排除または圧縮などのストレージ機能が適用されている場合には、その機能の効果または影響として、容量の削減またはＩＯＰＳの増加を反映した値としてもよい。ストレージ監視部１７は、ボリュームの利用状況を監視するときに当該ボリュームに対して「実態値」を更新するようにしてもよい。

図８は、図１の契約受付部の動作を示すフローチャートである。
図８において、契約受付部１２は、顧客端末３から通信部１１を経由して、ボリュームの新規契約内容として、ＩＯＰＳと容量の契約値を受信する（Ｓ４１）。

次に、契約受付部１２は、当該ボリュームに対して一意に定まる文字列であるボリュームＩＤを生成し、記憶部１８に格納されているボリューム管理テーブル１８２に登録し、登録日時と契約値も登録する（Ｓ４２）。契約受付部１２は、ノードＩＤを「未配置」、実態値を空白とする。

次に、契約受付部１２は、当該ボリュームのボリュームＩＤと、ボリュームの新規契約があったことをボリューム配置算出部１５Ａに通知する（Ｓ４３）。

図９は、図１のストレージ監視部の動作を示すフローチャートである。
図９において、ストレージの監視の対象項目は、ストレージ装置２を構成するノード群に配置されている各ボリュームのＩＯＰＳと容量である。このとき、ストレージ監視部１７は、各ボリュームのＩＯＰＳと容量を同時に監視する。

ＩＯＰＳの監視では、ストレージ監視部１７は、記憶部１８に格納されているボリューム管理テーブル１８２を一定の時間間隔で参照し、各ボリュームのＩＯＰＳの「実態値」を取得するとともに、各ボリュームのＩＯＰＳの利用中の値を計測する。そして、ストレージ監視部１７は、その計測値を対応するボリュームの「実態値」と比較し、計測値が「実態値」よりも大きければ、Ｓ５２に進み、計測値が「実態値」以下であれば、ＩＯＰＳの利用中の値の計測を繰り返す（Ｓ５１）。

次に、ストレージ監視部１７は、あるボリュームにおける計測値が「実態値」よりも大きい場合には、ボリューム管理テーブル１８２の当該ボリュームの行の「実態値」を、計測値に更新する（Ｓ５２）。

次に、ストレージ監視部１７は、記憶部１８に格納されているノード管理テーブル１８１において、当該ボリュームが配置されているノードの行の「配置済」のＩＯＰＳと「残量」のＩＯＰＳを、ボリューム管理テーブル１８２の実態値の更新に応じて更新する（Ｓ５３）。

次に、ストレージ監視部１７は、ノードとして実現可能なＩＯＰＳに補正する（Ｓ５４）。ＳＤＳにおいては、ノードの提供可能なＩＯＰＳは、ＣＰＵを利用して実現される。このため、ストレージ機能によってＣＰＵを消費している場合には、ノードとして実現可能なＩＯＰＳが変化し、ＩＯＰＳの補正が必要となる。

このＩＯＰＳの補正では、例えば、ストレージ装置２において重複排除等のストレージ機能が利用されている場合には、各ノードにおける当該機能のＣＰＵ利用量を計測する。そして、このＣＰＵ利用量の計測値を、例えば、実験等で作成した変換テーブルに従ってＩＯＰＳの値に変換する。ストレージ監視部１７は、このようにして得られたＩＯＰＳの値に基づいて、ノード管理テーブル１８１における当該ノードの「配置済」のＩＯＰＳと「残量」のＩＯＰＳをさらに更新する。

一方、容量の監視では、ストレージ監視部１７は、各ボリュームの容量の利用中の値を一定の時間間隔で計測し、一定の期間分（例えば、１ヶ月）の容量の値を記録する（Ｓ５５）。

次に、ストレージ監視部１７は、その記録した一定の期間分の容量の値の変化を元に、ある時間の経過後（例えば、１ヶ月後）の容量の利用量の予測値を算出する（Ｓ５６）。この予測には、例えば、回帰分析などの方法を利用することができる。

次に、ストレージ監視部１７は、あるボリュームにおける予測値が、記憶部１８に格納されているボリューム管理テーブル１８２の当該ボリュームの「実態値」よりも大きい場合には、その「実態値」を予測値に更新する（Ｓ５７）。

次に、ストレージ監視部１７は、記憶部１８に格納されているノード管理テーブル１８１において、当該ボリュームが配置されているノードの行の「配置済」の容量と「残量」の容量を、実態値の更新に応じて更新する（Ｓ５８）。

ストレージ監視部１７は、以上のような監視とテーブルの更新を、ＩＯＰＳと容量に関して、一定の時間間隔で繰り返す。

図１０は、図１のボリューム配置算出部の動作を示すフローチャートである。
図１０において、ボリューム配置算出部１５Ａは、契約受付部１２から、ボリュームの新規契約があったことの通知と、当該ボリュームのボリュームＩＤを受信する（Ｓ６１）。

次に、ボリューム配置算出部１５Ａは、記憶部１８に格納されているボリューム管理テーブル１８２を参照し、当該ボリュームＩＤに対応した行に記載された「契約値」のＩＯＰＳと容量を取得する（Ｓ６２）。

次に、ボリューム配置算出部１５Ａは、記憶部１８に格納されているノード管理テーブル１８１を参照し、全ノードの「残量」と「残ＩＯ密度」を取得する（Ｓ６３）。

次に、ボリューム配置算出部１５Ａは、記憶部１８に格納されている更新頻度設定ファイル１８３を参照し、「残ＩＯ密度の更新頻度」と「前回更新日時」を取得する（Ｓ６４）。ここで、更新頻度設定ファイル１８３には、「残ＩＯ密度の更新頻度」と「前回更新日時」が記載される。「残ＩＯ密度の更新頻度」は、例えば、「毎回」または「１日ごと」に設定することができる。「毎回」は、図４に示したように、ボリュームの新規契約があるたびにノード管理テーブル１８１の「残ＩＯ密度」を更新する。「１日ごと」は、図５に示したように、ボリュームの新規契約の有無にかかわらずに一定の時間間隔（例えば、１日ごと）が経過したら、「残ＩＯ密度」を更新する。この「残ＩＯ密度の更新頻度」は、ストレージサービスの運用者が運用端末４を用いて設定してもよいし、ある値が初期値として設定されていてもよい。「前回更新日時」は、「残ＩＯ密度」を更新した日時である。

次に、ボリューム配置算出部１５Ａは、「残ＩＯ密度の更新頻度」が「毎回」であるか、または「前回更新日時」と現在時刻を比較して、指定された時間間隔を経過したかを判断する（Ｓ６５）。そして、「残ＩＯ密度の更新頻度」が「毎回」であるか、または「前回更新日時」と現在時刻を比較して指定された時間間隔を経過した場合には、Ｓ６６へ進み、そうではない場合には、Ｓ６７へ進む。

次に、ボリューム配置算出部１５Ａは、「残ＩＯ密度の更新頻度」に該当している場合には、各ノードの「残ＩＯ密度」を「残量」のＩＯＰＳと容量から算出して更新する（Ｓ６６）。

次に、ボリューム配置算出部１５Ａは、新規契約のボリュームの契約値から算出されるＩＯ密度と「残ＩＯ密度」が最も近く、かつ、新規契約のボリュームの契約値のＩＯＰＳと容量が「残量」以内であるノードを探索し、当該ノードを新規契約のボリュームの配置先として決定する（Ｓ６７）。

次に、ボリューム配置算出部１５Ａは、新規契約のボリュームの契約値に従ったボリュームを配置先のノードに作成するように指示する通知をストレージ制御部１６に送信するとともに、ノード管理テーブル１８１の当該ノードの行の「配置済」、「残量」および「ボリュームＩＤ」を更新し、ボリューム管理テーブル１８２の当該ボリュームの行の「ノードＩＤ」を更新する（Ｓ６８）。

なお、Ｓ６７の「残ＩＯ密度」に応じたボリュームの配置先ノードの決定では、例えば、ボリューム配置後の「残ＩＯ密度」が当該ノードの「初期値」から算出されるＩＯ密度に最も近づくようなノードに配置するなど、他の方法を採用してもよい。

また、「残ＩＯ密度の更新頻度」は、「毎回」にすると、ノード数の増加にともなって計算コストが増加するため、一定の時間間隔を指定して計算頻度を抑えるようにしてもよい。また、ボリューム群の契約傾向によっては、残ＩＯ密度の更新頻度がある時間間隔であると、物理リソースの利用効率が向上する可能性があり、利用実態を監視しながら残ＩＯ密度の更新頻度の設定を変更してもよい。

また、ストレージ装置２のノード数に関しては、初期値は、任意のノード数で構わないが、例えば、ある１つのノードの「残量」が一定割合を下回ったら、新しいノードを追加するという運用を行ってもよい。追加するノードの物理リソースは任意で構わないが、例えば、「残量」が一定割合を下回ったノードと同じものを用意してもよいし、直近の契約ボリューム群のＩＯ密度の傾向に近い物理リソースを持ったノードを用意してもよい。

また、ストレージ監視部１７は、必ずしも使用しなくても構わない。ストレージ監視部１７を使用しない場合は、各ノードの「配置済」は、契約値をそのまま足し合わせた数値となる。ストレージ監視部１７を使用する場合は、各ノードの「配置済」の動的な変化およびストレージ機能の影響にも対応でき、ボリューム配置をより適正化することができる。

図１１は、第２実施形態に係るストレージ管理装置が適用されるストレージシステムの構成を示すブロック図である。
図１１において、このストレージシステムは、図１のストレージ管理装置１Ａの代わりにストレージ管理装置１Ｂを備える。ストレージ管理装置１Ｂは、図１のボリューム配置算出部１５Ａの代わりにボリューム配置算出部１５Ｂを備える。また、ストレージ管理装置１Ｂでは、記憶部１８は、図１の内容に加え、デプロイ頻度設定ファイル１８４を格納する。デプロイ頻度設定ファイル１８４は、ストレージ装置２に新規ボリュームをデプロイする頻度を管理する。

デプロイ頻度設定ファイル１８４には、「ボリュームデプロイ頻度」と「前回デプロイ日時」が記載される。「ボリュームデプロイ頻度」は、ストレージ管理装置１Ｂが新規ボリューム群をストレージ装置２にデプロイする頻度であり、例えば、「毎回」または「１日ごと」に設定することができる。「毎回」は、新規の契約があるごとに新規ボリュームをデプロイする。「１日ごと」は、ボリュームの新規契約の数やタイミングにかかわらずに、１日の決まった時間にまとめて新規ボリュームをデプロイする。

この「ボリュームデプロイ頻度」は、ストレージサービスの運用者が運用端末４を用いて設定してもよいし、ある値が初期値として設定されていてもよい。第１実施形態は、「ボリュームデプロイ頻度」が「毎回」の場合に相当する。「前回デプロイ日時」は、ボリューム群をデプロイした日時である。

ボリューム配置算出部１５Ｂは、複数の新規ボリュームの組み合わせのＩＯ密度とノードの残ＩＯ密度に基づいて新規ボリュームが配置されるノードを選択する。例えば、ボリューム配置算出部１５Ｂは、複数のボリュームの組み合わせをノードに仮配置したときのノードごとの仮配置前の残ＩＯ密度と仮配置後の残ＩＯ密度の差分に基づいて、ボリュームの配置の組み合わせを選択する。

図１２は、図１１のボリューム配置算出部の動作を示すフローチャートである。
図１２において、ボリューム配置算出部１５Ｂは、起動時に記憶部１８に格納されたデプロイ頻度設定ファイル１８４を参照する（Ｓ８０）。

次に、ボリューム配置算出部１５Ｂは、デプロイ頻度設定ファイル１８４に記載された「ボリュームデプロイ頻度」が「毎回」かどうかを判断する（Ｓ８１）。「ボリュームデプロイ頻度」が「毎回」の時は、図１０のＳ６１へ進み、図１のボリューム配置算出部１５Ａと同様の処理を実行し、「毎回」ではない時は、Ｓ８２へ進む。

次に、ボリューム配置算出部１５Ｂは、デプロイ頻度設定ファイル１８４に記載された「前回デプロイ日時」と現在時刻を比較して、「ボリュームデプロイ頻度」で指定された時間間隔を経過していた場合には、Ｓ８３へ進み、そうではない場合には待機し、一定時間間隔ごとに、デプロイ頻度の示す時間間隔を経過しているかどうかを確認する（Ｓ８２）。

次に、ボリューム配置算出部１５Ｂは、記憶部１８に格納されているボリューム管理テーブル１８２を参照し、ノードＩＤが「未配置」である全てのボリュームの「契約値」のＩＯＰＳと容量を取得する（Ｓ８３）。

次に、ボリューム配置算出部１５Ｂは、Ｓ８４〜Ｓ８７の処理を実行し、Ｓ８８に進む。Ｓ８４〜Ｓ８７の処理は、図１０のＳ６３〜Ｓ６６の処理と同様である。

次に、ボリューム配置算出部１５Ｂは、新規契約のボリューム群、すなわちＳ８３で取得した「未配置」の全てのボリューム群に対して、足し合わせに関する全ての組合せを生成する。例えば、対象となるボリュームを仮にボリュームＸ〜Ｚの３個とすると、足し合わせに関する全ての組合せとは、（Ｘ，Ｙ，Ｚ）、（Ｘ＋Ｙ，Ｚ）、（Ｘ＋Ｚ，Ｙ）、（Ｘ，Ｙ＋Ｚ）、（Ｘ＋Ｙ＋Ｚ）の５通りのことである。ここで、＋の記号は、ボリュームの契約値のＩＯＰＳと容量をそれぞれ足し合わせることを意味する。

この各組合せに対して、次の手順を実行する。まず、先頭の要素（ここでは、ＸやＸ＋Ｙなど（）内において「，」で区切られた１番目の要素）のＩＯＰＳと容量から算出されるＩＯ密度と、「残ＩＯ密度」が最も近く、かつ、当該要素のＩＯＰＳと容量が、「残量」以内であるノードを探索し、当該ノードを当該要素に対応するボリュームの仮配置先とする。

以降、２番目の要素に対しても、先頭の要素が仮配置された状態のノード群に対して、同様に仮配置を繰り返す。そして、全ての要素の仮配置を終えたら、仮配置先となったノード群に対してのみ、ノードごとに、仮配置前の「残ＩＯ密度」と仮配置後の「残ＩＯ密度」の差の絶対値を計算する。それらの値を全て足し合わせた値を、その組合せに対する残ＩＯ密度の配置残差と呼ぶことにする。この残ＩＯ密度の配置残差を全ての組合せに対して計算し、最も小さくなる組合せを本配置として採用する（Ｓ８８）。例えば、（Ｘ＋Ｙ，Ｚ）という組合せが本配置として採用される時は、あるノードにはボリュームＸとボリュームＹが配置され、ある別のボリュームにはボリュームＺが配置される。

次に、ボリューム配置算出部１５Ｂは、新規契約のボリューム群の契約値に従ったボリューム群を配置先のノード群に作成するように指示する通知をストレージ制御部１６に送信するとともに、ノード管理テーブル１８１の当該ノード群の行の「配置済」、「残量」および「ボリュームＩＤ」を更新し、ボリューム管理テーブル１８２の当該ボリューム群の行の「ノードＩＤ」を更新する（Ｓ８９）。

なお、上述した第２実施形態は、複数個の新規契約のボリュームをいくつかの組合せに分けた上でまとめてノードに配置する例であるが、その配置先の決定方法は、上記以外の方法を採用してもよい。

図１３は、第３実施形態に係るストレージ管理装置が適用されるストレージシステムの構成を示すブロック図である。
図１３において、このストレージシステムは、図１１のストレージ管理装置１Ｂの代わりにストレージ管理装置１Ｃを備える。ストレージ管理装置１Ｃは、ストレージ管理装置１Ｂに更新頻度設定部１９が追加されている。また、ストレージ管理装置１Ｃでは、記憶部１８は、図１１の更新頻度設定ファイル１８３の代わりに更新頻度設定ファイル１８３´を格納する。

更新頻度設定ファイル１８３´には、「残ＩＯ密度の更新頻度」と「前回更新日時」に加え、「見直し頻度」と「仮想頻度」と「前回見直し日時」が記載される。

「見直し頻度」は、「残ＩＯ密度の更新頻度」の値を変更する頻度であり、例えば、「１週間ごと」など値を取り、ストレージサービスの運用者によって運用端末４から設定される。「仮想頻度」は、「残ＩＯ密度の更新頻度」の取り得る値の候補の羅列であり、例えば、「毎回、１日、３日、５日、１週間」などの値を取り、ストレージサービスの運用者によって運用端末４から設定される。「前回見直し日時」は、「残ＩＯ密度の更新頻度」の値を更新した日時である。

更新頻度設定部１９は、配置済のボリュームを配置可能なノードに仮想的に再配置したときのノードおよびリソースの利用状況を計算し、ノードおよびリソースの利用状況に基づいて、ノードの残ＩＯ密度の更新頻度を設定する。例えば、更新頻度設定部１９は、記憶部１８に格納された更新頻度設定ファイル１８３を参照し、更新頻度設定ファイル１８３に設定された「見直し頻度」の値に従った時間間隔で、その時点で配置済のボリューム群の情報を基に、「残ＩＯ密度の更新頻度」の値を「仮想頻度」に含まれる値から選択する。

図１４は、図１３の更新頻度設定部の動作を示すフローチャートである。
図１４において、更新頻度設定部１９は、起動時に図１３の記憶部１８に格納された更新頻度設定ファイル１８３´を参照する（Ｓ１００）。

次に、更新頻度設定部１９は、一定時間間隔ごとに、見直し頻度の示す時間間隔を経過しているかどうかを確認する（Ｓ１０１）。このとき、更新頻度設定部１９は、更新頻度設定ファイル１８３´に記載された「前回見直し日時」と現在時刻を比較し、「見直し頻度」で指定された時間間隔を経過していた場合には、Ｓ１０２に進み、そうではない場合には待機する。

次に、更新頻度設定部１９は、記憶部１８に格納されたボリューム管理テーブル１８２を参照し、その時点でいずれかのノードに配置済の全てのボリュームの「登録日時」と「契約値」のＩＯＰＳと容量を取得する（Ｓ１０２）。

次に、更新頻度設定部１９は、記憶部１８に格納されたノード管理テーブル１８１を参照し、「設置日時」を基に、ストレージ装置２の初期状態を構成していたノード群を特定し、当該ノード群の「初期値」のＩＯＰＳと容量を取得する（Ｓ１０３）。

次に、更新頻度設定部１９は、更新頻度設定ファイル１８３´に記載された「仮想頻度」に列挙された値のうち、「残ＩＯ密度の更新頻度」の値以外の全ての値に対して、次の手順を実行する。まず、Ｓ１０３で取得した初期状態のノード群に対して、Ｓ１０２で取得したボリューム群を、「登録日時」の順番で、例えば、第１実施形態で説明した方式に従い、仮想的に再配置する（Ｓ１０４）。このとき、順次経過する「登録日時」に応じて、「仮想頻度」として指定された値に従って、ノードの「残ＩＯ密度」を更新しながら仮想的な再配置を進める。また、ノードの追加も、あらかじめ規定した基準に従って仮想的に行う。

このような再配置が完了したら、ノード数および各ノードの物理リソースの利用率を計算し、全ノードの利用率の平均値（以降、見直し指標と呼称する）を計算する。ノードの利用率は、例えば、ＩＯＰＳの利用率と容量の利用率を計算し、小さい方を採用する。また、現状の配置状態、すなわち更新頻度設定ファイル１８３´に記載された「残ＩＯ密度の更新頻度」に従った配置におけるノード数および見直し指標を計算する（Ｓ１０５）。以上で、「仮想頻度」に列挙された全ての値に対して、ノード数と見直し指標が得られる。

それらの中で、ノード数が最も小さくなる「仮想頻度」の値が１つであれば、その値を選択し、複数であれば、それらの中で、見直し指標が最も大きくなる値を選択する。その選択された値で、更新頻度設定ファイル１８３´に記載された「残ＩＯ密度の更新頻度」の値を更新する（Ｓ１０６）。以降、ボリューム配置算出部１５は、その更新された値に従って、ボリューム配置を算出する。

なお、本実施形態で説明した「残ＩＯ密度の更新頻度」の見直しは、更新頻度設定ファイル１８３´の「見直し頻度」によらずに、ストレージサービスの運用者によって、運用端末４から任意のタイミングで実行してもよい。

また、上述した第３実施形態では、「契約値」による仮想的な再配置を行ったが、各ボリュームの「実態値」の変更履歴を記録することで、「実態値」による仮想的な再配置と、「残ＩＯ密度の更新頻度」の見直しも可能である。

図１５は、第４実施形態に係るストレージ管理装置が適用されるストレージシステムの構成を示すブロック図である。
図１５において、このストレージシステムは、図１のストレージ管理装置１Ａの代わりにストレージ管理装置１Ｄを備える。ストレージ管理装置１Ｄは、図１のボリューム配置算出部１５Ａの代わりにボリューム配置算出部１５Ｄを備える。また、ストレージ管理装置１Ｄでは、記憶部１８は、図１の内容に加え、リソース単価管理テーブル１８５を格納する。リソース単価管理テーブル１８５は、ノード管理テーブル１８１とマージしても構わない。

ボリューム配置算出部１５Ｄは、新規ボリュームのＩＯ密度とノードの残ＩＯ密度と新規ボリュームをノードに配置したときにかかるコストに基づいて、新規ボリュームが配置されるノードを選択する。例えば、ボリューム配置算出部１５Ｄは、新規ボリュームのＩＯ密度とノードの残ＩＯ密度との差分が所定範囲内にあるノードのうち、コストが最も小さいノードを新規ボリュームの配置先として決定する。

図１６は、図１５のリソース単価管理テーブルの一例を示す図である。
図１６において、リソース単価管理テーブル１８５は、「ノードＩＤ」、「ＩＯＰＳ単価」および「容量単価」のエントリを備える。

「ノードＩＤ」は、図１５のストレージ装置２を構成するノードを一意に表す文字列である。

「ＩＯＰＳ単価」は、各ノードの１ＩＯＰＳあたりの月額、「容量単価」は、各ノードの１ＧＢあたりの月額である。「ＩＯＰＳ単価」および「容量単価」は、各ノードの物理構成とサービスプロバイダの事業計画から決定される。リソース単価管理テーブル１８５は、ストレージサービスの運用者によって運用端末４から設定される。各単価が高い方が、信頼性の高い高価な物理リソースを利用したり、高度な運用体制を整えたりすることが多い。

顧客によっては、ミッションクリティカルなアプリケーションであるなどの理由で、単価が高い、すなわち同じ性能や容量であってもサービスの利用価格が高いとしても、高信頼なノードへのボリューム配置を希望することがある。また、逆に、なるべく安いノードの利用を希望する顧客もいる。

ボリューム配置算出部１５Ｄは、そのような顧客のニーズに対応しつつ、ボリュームの配置先のノードを決定する。具体的には、図１０のＳ６７の処理において、図１のボリューム配置算出部１５Ａは、新規ボリュームの契約値から算出されるＩＯ密度と、「残ＩＯ密度」が最も近いノードをボリュームの配置先としていたが、ボリューム配置算出部１５Ｄは、その最も近いノードに加えて、例えば、２番目に近いノードも探索する。そして、それらの２つのノードに対するＩＯＰＳ単価と容量単価をリソース単価管理テーブル１８５から取得し、ボリュームの価格を算出する。その算出された２つの価格のうち、顧客のニーズに合う価格となったノードの方を、新規ボリュームの配置先として決定する。

このように、ストレージ管理装置１Ｄは、ノードの残ＩＯ密度だけでなく、新規ボリュームをノードに配置したときにかかるコストも参照して新規ボリュームの配置先のノードを選択することにより、顧客のニーズを反映させつつ、ノードのリソース利用効率を向上させることができる。

図１７は、図１のストレージ管理装置のハードウェア構成例を示すブロック図である。
図１７において、ストレージ管理装置１００は、プロセッサ１０１、通信制御デバイス１０２、通信インタフェース１０３、主記憶デバイス１０４、補助記憶デバイス１０５および入出力インタフェース１０７を備える。プロセッサ１０１、通信制御デバイス１０２、通信インタフェース１０３、主記憶デバイス１０４、補助記憶デバイス１０５および入出力インタフェース１０７は、内部バス１０６を介して相互に接続されている。主記憶デバイス１０４および補助記憶デバイス１０５は、プロセッサ１０１からアクセス可能である。

また、ストレージ管理装置１００の外部には、入力装置１１０および出力装置１１１が設けられている。入力装置１１０および出力装置１１１は、入出力インタフェース１０７を介して内部バス１０６に接続されている。入力装置１１０は、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力装置等である。出力装置１１１は、例えば、画面表示装置（液晶モニタ、有機ＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、グラフィックカード等）、音声出力装置（スピーカ等）、印字装置等である。

プロセッサ１０１は、ストレージ管理装置１００全体の動作制御を司るハードウェアである。プロセッサ１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であってもよいし、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であってもよい。プロセッサ１０１は、シングルコアプロセッサであってもよいし、マルチコアプロセッサであってもよい。プロセッサ１０１は、処理の一部または全部を行うハードウェア回路（例えば、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ））を備えていてもよい。プロセッサ１０１は、ニューラルネットワークを備えていてもよい。

主記憶デバイス１０４は、例えば、ＳＲＡＭまたはＤＲＡＭなどの半導体メモリから構成することができる。主記憶デバイス１０４には、プロセッサ１０１が実行中のプログラムを格納したり、プロセッサ１０１がプログラムを実行するためのワークエリアを設けたりすることができる。

補助記憶デバイス１０５は、大容量の記憶容量を備える記憶デバイスであり、例えば、ハードディスク装置またはＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）である。補助記憶デバイス１０５は、各種プログラムの実行ファイルやプログラムの実行に用いられるデータを保持することができる。補助記憶デバイス１０５には、ストレージ管理プログラム１０５Ａおよび管理情報１０５Ｂを格納することができる。ストレージ管理プログラム１０５Ａは、ストレージ管理装置１００にインストール可能なソフトウェアであってもよいし、ストレージ管理装置１００にファームウェアとして組み込まれていてもよい。管理情報１０５Ｂは、例えば、図１のノード管理テーブル１８１、ボリューム管理テーブル１８２および更新頻度設定ファイル１８３である。

通信制御デバイス１０２は、外部との通信を制御する機能を備えるハードウェアである。通信制御デバイス１０２は、通信インタフェース１０３を介してネットワーク１０９に接続される。ネットワーク１０９は、インターネットなどのＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよいし、ＷｉＦｉまたはイーサネット（登録商標）などのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよいし、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよいし、ＷＡＮとＬＡＮとＳＡＮが混在していてもよい。

入出力インタフェース１０７は、入力装置１１０から入力されるデータをプロセッサ１０１が処理可能なデータ形式に変換したり、プロセッサ１０１から出力されるデータを出力装置１１１が処理可能なデータ形式に変換したりする。

プロセッサ１０１がストレージ管理プログラム１０５Ａを主記憶デバイス１０４に読み出し、ストレージ管理プログラム１０５Ａを実行することにより、残ＩＯ密度に基づいてノードの階層を制御し、配置対象のボリュームのＩＯ密度とノードの残ＩＯ密度との差分に基づいて、ボリュームが配置されるノードを選択し、配置対象のボリュームのＩＯ密度とノードの残ＩＯ密度との差分が最も小さいノードを、ボリュームの配置先として決定することができる。

このとき、プロセッサ１０１がストレージ管理プログラム１０５Ａを実行することにより、図１の通信部１１、契約受付部１２、運用パラメタ設定部１３、画面生成部１４、ボリューム配置算出部１５Ａ、ストレージ制御部１６およびストレージ監視部１７の機能を実現することができる。

なお、ストレージ管理プログラム１０５Ａの実行は、複数のプロセッサやコンピュータに分担させてもよい。あるいは、プロセッサ１０１は、ネットワーク１０９を介してクラウドコンピュータなどにストレージ管理プログラム１０５Ａの全部または一部の実行を指示し、その実行結果を受け取るようにしてもよい。

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。

１ ストレージ管理装置、２ ストレージ装置、３ 顧客端末、４ 運用端末、１１ 通信部、１２ 契約受付部、１３ 運用パラメタ設定部、１４ 画面生成部、１５ ボリューム配置算出部、１６ ストレージ制御部、１７ ストレージ監視部、１８ 記憶部、１９ 更新頻度設定部、１８１ ノード管理テーブル、１８２ ボリューム管理テーブル、１８３ 更新頻度設定ファイル、１８４ デプロイ頻度設定ファイル、１８５ リソース単価管理テーブル

Claims (13)

1. ノードのＩＯＰＳ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）および容量の残量に基づいて残ＩＯ密度を算出し、
   残ＩＯ密度に基づいて前記ノードの階層を制御するストレージ管理装置。
2. 配置対象のボリュームのＩＯ密度と前記ノードの残ＩＯ密度に基づいて、前記ボリュームが配置されるノードを選択する請求項１に記載のストレージ管理装置。
3. 前記配置対象のボリュームのＩＯ密度と前記ノードの残ＩＯ密度との差分が最も小さいノードを、前記ボリュームの配置先として決定する請求項２に記載のストレージ管理装置。
4. 配置対象のボリュームのＩＯ密度と前記ノードの残ＩＯ密度と前記ボリュームを前記ノードに配置したときにかかるコストに基づいて、前記ボリュームが配置されるノードを選択する請求項１に記載のストレージ管理装置。
5. 前記配置対象のボリュームのＩＯ密度と前記ノードの残ＩＯ密度との差分が所定範囲内にあるノードのうち、前記コストが最も小さいノードを前記ボリュームの配置先として決定する請求項４に記載のストレージ管理装置。
6. 前記ボリュームの配置要求があるごとに前記ノードの残ＩＯ密度を更新する請求項２に記載のストレージ管理装置。
7. 指定時間を経過するごとに前記ノードの残ＩＯ密度を更新する請求項２に記載のストレージ管理装置。
8. 前記ノードの残ＩＯ密度の更新条件を入力可能な画面を生成し、
   前記画面上で入力された更新条件に基づいて前記ノードの残ＩＯ密度を更新する請求項２に記載のストレージ管理装置。
9. 前記配置対象の複数のボリュームの組み合わせのＩＯ密度と前記ノードの残ＩＯ密度に基づいて、前記ボリュームが配置されるノードを選択する請求項２に記載のストレージ管理装置。
10. 前記配置対象の複数のボリュームの組み合わせを前記ノードに仮配置したときの前記ノードごとの仮配置前の残ＩＯ密度と仮配置後の残ＩＯ密度の差分に基づいて、前記ボリュームの配置の組み合わせを選択する請求項９に記載のストレージ管理装置。
11. 配置済のボリュームを前記ボリュームを配置可能なノードに仮想的に再配置したときの前記ノードおよびリソースの利用状況を計算し、
    前記ノードおよびリソースの利用状況に基づいて、前記ノードの残ＩＯ密度の更新頻度を設定する請求項２に記載のストレージ管理装置。
12. ノードのＩＯＰＳおよび容量の残量に基づいて残ＩＯ密度を算出し、
    残ＩＯ密度に基づいて前記ノードの階層を制御するストレージ管理方法。
13. ノードのＩＯＰＳおよび容量の残量に基づいて残ＩＯ密度を算出するステップと、
    残ＩＯ密度に基づいて前記ノードの階層を制御するステップとをコンピュータに実行させるストレージ管理プログラム。
    
    

Images