JP6878369B2 - ボリューム配置管理装置、ボリューム配置管理方法、及びボリューム配置管理プログラム - Google Patents

Description

本発明は、複数の汎用サーバノードで構成されるストレージシステムにおけるボリュームの配置を管理する技術に関する。

例えば、プライベートクラウドにおいて、ＳＤＳ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ）技術を用いてストレージ機能を実現する構成とすることが知られている。ＳＤＳは、汎用的なサーバのクラスタを用いて、その上にストレージ制御ソフトウェアを稼動させ、ストレージ装置として機能させる技術である。

ＳＤＳでは、汎用的なサーバ（ノード）のクラスタ（ＳＤＳクラスタ）を用いるため、クラスタ内のノード毎あるいは数台のノード毎にＩ／Ｏ負荷の集中度が異なってくる。このＩ／Ｏ負荷は、そのＳＤＳクラスタ上に配置したボリュームのＩ／Ｏ負荷に依存する。言い換えると、ＳＤＳクラスタ上のどのノードに、どのボリュームを配置するかによって、各ノードのＩ／Ｏの偏り(もしくは平準度)を変更しうる。よって、システム全体として特定のノードにＩ／Ｏが偏ってしまい、そこがボトルネックにならないようにするために、ボリュームをクラスタ内のノードに負荷分散させて配置させて運用することが重要となる。既存のＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）のマイグレーション技術などと異なり、ボリュームの移動は大量のデータコピーを伴うため、短期間で再配置する方式は、システム全体に負荷を掛けうる。頻繁な配置移動を避けるため、事前にボリュームに対するＩ／Ｏ負荷を予測し、その予測に基づき、ボリュームの配置、容量を計画することが重要となる。

ストレージの負荷予測に関する技術として、Ｎｕｔａｎｉｘ社は、Ｘ−ＦＩＴと呼ばれる技術を公開している（非特許文献1参照）。この技術では、過去の時系列に基づき、その延長となる負荷予測を複数の方式で行い、最も誤差が少ない手法をそのボリュームの負荷予測手法として選択する。Ｎｕｔａｎｉｘ社のＮｕｔａｎｉｘ Ｃａｌｍという製品では、マーケットプレースからミドル・アプリを構築する技術を用いている。

Ｎｕｔａｎｉｘ、ＮＵＴＡＮＩＸ ＭＡＣＨＩＮＥ ＬＥＡＲＮＩＮＧ ＥＮＧＩＮＥ Ｘ−ＦＩＴ、インターネット（https://www.nutanix.com/go/nutanix-machine-learning-engine-x-fit.html）

既存の負荷予測技術においては、過去の一定期間に処理システムを稼動させ、ボリュームに負荷を与えたことにより時系列のリソース負荷データを収集し、その系列の未来を予測するという手法となる。このため、新規に処理システムをデプロイする場合には、対象ボリュームの過去の時系列データが存在しないため、予測することができない。

新規処理システムに対して適用することを考えると、負荷予測の元となるワークロードのプロファイルを手動で検索し、選択することが必要である。利用するプロファイルが過去のシステム構成と類似していて流用出来るか否かの判断は、人間が行う必要がある。これを行うためには、処理システム毎、処理システムで使用するミドルウェア毎のノウハウを要する。このため、複数の汎用サーバノードで構成されるストレージシステムにおいて、ボリュームをどのノードに配置すればよいかを決定することは困難である。

本発明は、上記事情に鑑みなされたものであり、その目的は、複数の汎用サーバノードで構成されるストレージシステムにおいて、ボリュームを容易且つ適切にノードに配置することのできる技術を提供することにある。

上記目的を達成するため、一観点に係るボリューム配置管理装置は、複数の汎用サーバノードで構成されるストレージシステムにおけるボリュームの配置を管理するボリューム配置管理装置であって、過去ボリュームを利用する過去処理システムにおけるシステム構成情報を取得する過去システム構成情報取得部と、過去処理システムにおける過去ボリュームの性能情報を記憶する過去ボリューム性能情報取得部と、新規ボリュームを利用する新規処理システムのシステム構成情報を取得する構成情報取得部と、過去処理システムのシステム構成情報に基づいて、新規処理システムのシステム構成と類似する過去処理システムを決定する類似システム決定部と、類似すると決定された過去処理システムが利用する過去ボリュームの性能情報に基づいて、新規ボリュームの負荷情報を予測する負荷予測部と、負荷情報の予測内容に基づいて、新規ボリュームの配置案を決定する配置案決定部と、を備える。

本発明によれば、複数の汎用サーバノードで構成されるストレージシステムにおいて、ボリュームを容易且つ適切にノードに配置することができる。

図１は、一実施形態に係る計算機システムの全体構成図である。 図２は、一実施形態に係る計算機システムのサーバ、ノード、計算機の構成図である。 図３は、一実施形態に係る処理システムの構成の一例を示す図である。 図４は、一実施形態に係る処理システムの構成の他の例を示す図である。 図５は、一実施形態に係るシステム構成情報の一例である。 図６は、一実施形態に係るＰａａＳ構成情報履歴情報の構成図である。 図７は、一実施形態に係るサブシステム特性情報を説明する図である。 図８は、一実施形態に係るＰａａＳ構成−性能履歴対応付け情報の構成を説明する図である。 図９は、一実施形態に係る配置最適化処理のフローチャートである。 図１０は、一実施形態に係るサブシステム抽出処理のフローチャートである。 図１１は、一実施形態に係る類似度決定処理のフローチャートである。

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

図１は、一実施形態に係る計算機システムの全体構成図である。

計算機システム１００は、ＳＤＳ管理側１０１に配置された、ＳＤＳ−ＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）管理サーバ１及び記憶装置２と、クラウド基盤側１０２に配置された、複数のＣｏｍｐｕｔｅノード３及び複数のＳＤＳノード４と、クライアント計算機６とを備える。記憶装置２は、例えば、ＨＤＤ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置であり、各種情報を記憶する。

ＳＤＳ−ＰａａＳ管理サーバ１と、複数のＣｏｍｐｕｔｅノード３と、複数のＳＤＳノード４と、クライアント計算機６とは、ネットワークの一例としてのＳＡＮ（Ｓｔｏｒｅｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）５を介して接続されている。

Ｃｏｍｐｕｔｅノード３は、処理システムのワークロード（アプリケーション（アプリ）３１及びミドルウェア３２）を稼働させる。また、Ｃｏｍｐｕｔｅノード３は、ＰａａＳ管理部３３を有する。ＰａａＳ管理部３３は、いわゆるコンテナ管理ツールであり、例えば、オープンソースソフトウェアのＫｕｂｅｒｎｅｔｅｓを後述するＣＰＵ２０１が実行することにより構成される。ＰａａＳ管理部３３は、Ｃｏｍｐｕｔｅノード３上で実行されるアプリ３１、ミドルウェア３２を管理する。例えば、ＰａａＳ管理部３３は、ミドルウェア３２のデプロイ、監視などの制御を実行する。ＰａａＳ管理部３３は、ミドルウェア３２のデプロイ時には、デプロイするミドルウェア３２の構成情報（ミドルウェア構成情報）とボリューム（ストレージボリューム）要件とをＳＤＳ−ＰａａＳ管理サーバ１に送信する。

ＳＤＳノード４は、汎用的なサーバで構成される汎用サーバノードであり、複数のＳＤＳノード４によりストレージクラスタ（ストレージシステムの一例）を構成し、ワークロードが利用するボリューム４１を記憶する。また、ＳＤＳノード４は、性能情報監視部４２を有する。性能情報管理部４２は、ＳＤＳノード４の負荷、ボリューム４１の負荷等を監視し、ＳＤＳ−ＰａａＳ管理サーバ１に通知する。

ここで、本実施例においては、ボリューム４１の配置計画は、ワークロードが利用するボリューム４１を配置するＳＤＳノード４を、クラウド基盤側１０２のストレージクラスタの中から選択する問題に帰着される。

クライアント計算機６は、利用者７に対して、ＰａａＳ管理部３３に対してアクセスするＰａａＳ管理ＵＩ６１を提供する。利用者７は、ＰａａＳ管理ＵＩ６１を介して、ＰａａＳ管理部３３に対して、ミドルウェアを含む新規の処理システム（新規処理システム）のシステム構成を指定して、新規処理システムをデプロイさせる指示を送信することができる。ＰａａＳ管理ＵＩ６１の例としては、例えば、ＰａａＳ管理部３３をＫｕｂｅｒｎｅｔｅｓにより構成した場合には、例えば、オープンソースソフトウェアのＭｏｎｏｃｕｌａｒを用いることができる。Ｍｏｎｏｃｕｌａｒにおいては、デプロイする処理システムの構成を記載したブループリントの情報（Ｃｈａｒｔｓ）を指定して、ミドルウェア３２とそのミドルウェア３２が必要とするストレージとを一括でデプロイするように指示することができる。この指示を受けると、ＰａａＳ管理部３３は、ミドルウェア３３のデプロイ時に、デプロイするミドルウェア３２の構成情報（ミドルウェア構成情報）とボリューム要件とをＳＤＳ−ＰａａＳ管理サーバ１に送信することとなる。

ＳＤＳ−ＰａａＳ管理サーバ１は、ボリューム配置管理装置の一例であり、ＰａａＳ管理部３３及び性能情報監視部４２と連動して、定常的にＳＤＳノード４の負荷情報と、デプロイされたシステムの構成情報とを収集し、管理する。ＳＤＳ−ＰａａＳ管理サーバ１は、過去システム構成情報取得部の一例としての構成情報監視部１１と、過去ボリューム性能情報取得部の一例としての性能情報収集部１２と、構成情報取得部の一例としての構成管理部１３と、負荷予測部の一例としての性能予測部１４と、類似システム決定部、配置案決定部、サブシステム分割部、特徴項目抽出部、類似度判定部、及び選択部の一例としての配置管理部１５とを備える。構成情報監視部１１は、ＰａａＳ管理部３３からミドルウェア構成情報を収集（取得）し、記憶装置２のＰａａＳ構成情報履歴情報２１に格納する。ミドルウェア構成情報の詳細は、後述する。性能情報収集部１２は、性能情報監視部４２からＳＤＳノード４のボリューム毎の性能情報（例えば、Ｒｅａｄ／ＷｒｉｔｅのＩＯＰＳ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ ｐｅｒ Ｓｅｃｏｎｄ）、スループットなど)を定期的に収集し、記憶装置２のＰａａＳ構成−性能履歴対応付け情報２２に格納する。

構成管理部１３は、ＰａａＳ管理部３３からボリューム（新規ボリューム）の配置依頼を受信し、ボリュームの配置に関する処理を実行する。なお、配置依頼には、ミドルウェア構成情報や、ミドルウェア３２に対するボリューム要件(サイズ、可用性など)が含まれる。性能予測部１４は、ボリュームを所定のＳＤＳノード４に配置した場合における性能を予測する処理を実行する。配置管理部１５は、ＳＤＳクラスタのＳＤＳノード４におけるボリュームの配置を管理する。

次に、ＳＤＳ−ＰａａＳ管理サーバ１、Ｃｏｍｐｕｔｅノード３、ＳＤＳノード４、及びクライアント計算機６のハードウェア構成について説明する。

図２は、一実施形態に係る計算機システムのサーバ、ノード、計算機の構成図である。

ＳＤＳ−ＰａａＳ管理サーバ１、Ｃｏｍｐｕｔｅノード３、ＳＤＳノード４、及びクライアント計算機６は、例えば、図２に示すコンピュータ２００により構成することができる。

コンピュータ２００は、プロセッサの一例としてのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、メモリ２０２と、インターフェース２０３と、記憶装置２０５と、イーサネットネットワークカード２０７（イーサネットは登録商標）と、ネットワークポート２０８とを含む。

イーサネットワークカード２０７は、ＳＡＮ５を介して他の装置との通信を仲介する。ネットワークポート２０８は、ＳＡＮ５と接続するためのポートである。

ＣＰＵ２０１は、メモリ２０２及び／又は記憶装置２０５に格納されているプログラムに従って各種処理を実行する。ＣＰＵ２０１がプログラムを実行することにより、各装置における図１に示す各機能部が構成される。例えば、ＳＤＳ−ＰａａＳ管理サーバ１においては、コンピュータ２００の記憶装置２０５に格納されたプログラム（ボリューム配置管理プログラム）をＣＰＵ２０１が実行することにより各機能部１１〜１５が構成される。

メモリ２０２は、例えば、ＲＡＭ（ＲＡＮＤＯＭ ＡＣＣＥＳＳ ＭＥＭＯＲＹ）であり、ＣＰＵ２０１で実行されるプログラムや、必要な情報を記憶する。

記憶装置２０５は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｉｓｋ）等の中の少なくとも一つを含み、ＣＰＵ２０１で実行されるプログラムや、ＣＰＵ２０１に利用されるデータを記憶する。なお、コンピュータ２００を、ＳＤＳ−ＰａａＳ管理サーバ１、Ｃｏｍｐｕｔｅノード３、ＳＤＳノード４、又はクライアント計算機６のいずれに使用するかによって、記憶装置２０３に格納するプログラムや、データが変わっている。

インターフェース２０３は、ＣＰＵ２０１と、記憶装置２０５と、イーサネットネットワークカード２０７との間のデータの仲介を行う。

なお、クライアント計算機６として用いる場合には、コンピュータ２００に、例えば、マウス、キーボード等のユーザによる操作入力を受け付ける入力装置と、例えば、ディスプレイ等の各種情報を表示出力する出力装置とを備えるようにすればよい。

次に、計算機システム１００において、特定のミドルウェア３２を稼働することによりデプロイさせて構成される処理システムについて説明する。

図３は、一実施形態に係る処理システムの構成の一例を示す図であり、図４は、一実施形態に係る処理システムの構成の他の例を示す図である。図３は、オープンソースソフトウェアのＭｏｎｇｏＤＢをデプロイさせた処理システムの例を示し、図４は、オープンソースソフトウェアのＨａｄｏｏｐをデプロイさせた処理システムの例を示す。なお、図３及び図４においては、ＰａａＳ管理部３３は、Ｋｕｂｅｒｎｅｔｅｓ３３１を実行することにより構成した例を示している。

Ｋｕｂｅｒｎｅｔｅｓ３３１は、上記説明したようにミドルウェア３２とアプリケーション３１を、コンテナ技術を用いてデプロイ、監視する仕組みを持つ。図３においては、ミドルウェア３２であるＭｏｎｇｏＤＢ３２１は、コンテナ３３２の中で稼動している。各コンテナ３３２は、データを永続するためのデータ領域を必要とする。このデータ領域がＳＤＳノード４上で確保されたボリューム４１上に割り当てられており、このデータがボリューム４１に格納される。

ＭｏｎｇｏＤＢ３２１を用いる場合には、３つのＣｏｍｐｕｔｅノード３でクラスタ（レプリケーションセット）を構成して、１つの処理システムを構築する。このクラスタにおいては、通常は1つのＣｏｍｐｕｔｅノード３がＡｃｔｉｖｅなノードとして振舞い、他のＣｏｍｐｕｔｅノード３は、データを冗長的に保存するＢａｃｋｕｐノードとして振舞う。

一方、Ｈａｄｏｏｐをデプロイさせた処理システムでは、図４に示すように、Ｋｕｂｅｒｎｅｔｅｓ３３１によって管理されているコンテナの中に、Ｈａｄｏｏｐの各機能が稼動する。Ｈａｄｏｏｐを用いる場合には、例えば、４つのＣｏｍｐｕｔｅノード３でクラスタを構成して、１つの処理システムを構築する。Ｈａｄｏｏｐは、ｎａｍｅｎｏｄｅ、ｄａｔａｎｏｄｅなど、クラスタの各Ｃｏｍｐｕｔｅノード３を、異なる複数の種類のノードとして役割分担させ、各Ｃｏｍｐｕｔｅノード３のそれぞれが占有のデータ領域としてのボリューム４１を確保する構成となっている。

本実施形態では、図３、図４の構成におけるボリューム４１をＳＤＳクラスタ上のＳＤＳノード４のいずれかに対して割り当てる処理を実施する。当然ではあるが、図３、図４におけるボリューム４１に対するＩ／Ｏ特性は異なっており、更に、図３、図４中の各ボリュームも、クラスタ内での役割やＡｃｔｉｖｅ／Ｂａｃｋｕｐなどの状態によりＩ／Ｏ特性が異なる。こういったシステム構成上の特性を考慮してボリュームを配置する必要があるため、特性のベースとなるリソース負荷（ＩＯＰＳなど)を予測した上で、性能のボトルネックが生じないように配置を実施することとなる。

図５は、一実施形態に係るシステム構成情報の一例である。

図５は、ＰａａＳ管理部３３が処理で扱っているシステム構成情報４００の例を示している。なお、ＰａａＳ管理部３３を、Ｋｕｂｅｒｎｅｔｅｓ３３１を実行することにより構成した例を示している。システム構成情報４００は、Ｋｕｂｅｒｎｅｔｅｓ３３１から収集するミドルウェア構成情報４０１と、ＳＤＳノード４のクラスタ（ＳＤＳクラスタ）から収集するボリューム構成情報４０２とを含む。Ｋｕｂｅｒｎｅｔｅｓ３３１では、ミドルウェア構成情報４０１を、ＹＡＭＬ形式のテキスト情報として記述しているが、本質的には、グラフ構造を表現している情報であるため、図５においては、ミドルウェア構成情報４０１をグラフ化した情報として表現する。図５に示すミドルウェア構成情報４０１は、ミドルウェア３２として、ＭｏｎｇｏＤＢを用いた場合の例を示している。

ミドルウェア構成情報４０１は、システムを構成するリソース（システムリソース）を表すノード（リソースノード）４１１と、リソース間の依存関係を表すリンク４１２で表される。システムリソースは、コンテナ、サーバ、ボリュームなど、図３及び図４における各構成要素をあらわす。図５の例では、システムリソースについて、コンテナを「Ｃｏｎｔａｉｎｅｒ」、サーバを「Ｐｏｄ」、ボリュームの要件を「ＰＶＣ」、要件を満たしてコンテナに接続されるボリュームを「ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅ」と表現している。これらのシステムリソースは、Ｋｕｂｅｒｎｅｔｅｓの標準的な構成要素であるため、詳細な説明を省略する。

各リソースノード４１１には、ノード種類４２１と、ノード属性４２２が関連付けられる。ノード種類４２１は、リソースノードの種類をあらわす識別子（リソース種別）である。図５の例では、「Ｐｏｄ」、「ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅ」などが、リソース種別を示す。ノード属性４２２は、そのリソースノードの設定値である。本実施例では、設定値を、例えば、「項目名＝設定値」のようなキーバリューの組合せで表現している。

ボリューム構成情報４０２は、ＳＤＳノード４から取得可能なボリューム４１の構成情報である。ボリューム構成情報４０２は、Ｃｏｍｐｕｔｅノード３から接続するための情報と、ＳＤＳクラスタの中でボリューム４１を一意に特定可能な情報（ボリューム特定情報）を含む。図５の例では、ボリュームリソース４３１のボリューム特定情報を、ｉＳＣＳＩターゲットと、ＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）としている。なお、ボリューム特定情報は、ＳＤＳノード４のプロトコル等に依存する物であり、上記例に限定されるものではない。

本実施例では、Ｋｕｂｅｒｎｅｔｅｓに含まれるリソースノードのＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅと、これに対応するボリュームリソース４３１とは、明示的に対応付けられていることを前提とする。例えば、ｉＳＣＳＩターゲットとＬＵＮとがＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅと、ボリュームリソースの双方に含まれ、これらが関連付けられていること（本例では、同一の値としていること）で紐付けられている。この前提が無い場合、管理者が指定したボリュームリソース４３１を確実に特定のミドルウェアシステム構成に割り当てることを保証することができず、セキュリティの観点、あるいは利用状況の確認の観点から現実的ではないこととなり、この前提は、妥当なものと考えられる。

ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅよりも上方のリソースノードの構成に関しては、構成情報の設計者、あるいはシステムの特徴によって接続関係が異なる可能性が存在する。例えば、図５に示すシステム構成の各リソースノードは、単一のＳｔａｔｅｆｕｌＳｅｔというリソースノードの配下に配置される構成となっており、ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅは、ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅＣｌａｉｍ（ＰＶＣ）というリソースノードを経由してＰｏｄに接続されている。しかし、別のシステム構成としては、ＳｔａｔｅｆｕｌＳｅｔは、Ｄｅｐｌｏｙｍｅｎｔのような異なるノード種類でも定義可能であり、ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅを直接Ｐｏｄと接続する定義も可能である。

このため、システム構成の類似性を、グラフの単純な相似形、或いはツリー構成の比較の手法を持って判断することは困難である。本実施例では、後述するように、観点とすべき対象（本実施例においてはボリューム＝ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅ）に基づいた共通サブシステムを抽出して比較することにより、この問題に対応する。

次に、ＰａａＳ構成情報履歴情報２１について説明する。

図６は、一実施形態に係るＰａａＳ構成情報履歴情報の構成図である。

ＰａａＳ構成情報履歴情報２１には、利用者７がＰａａＳ管理ＵＩ６１を用いて、図５に示すミドル構成情報４０１を指定して、処理システムのデプロイを指示した場合において、指定したミドルウェア構成情報４０１を含むシステム構成情報４００が履歴として蓄積される。ここで、過去にデプロイされた処理システムが過去処理システムに相当し、ＰａａＳ構成情報履歴情報２１に対応するシステム構成情報４００が格納されることとなる。

ＰａａＳ構成情報履歴情報２１は、過去にデプロイされたシステムを特定可能な識別子であるシステム識別子５０１と、それに対応するシステム構成情報４００とが関連付けられて構成されている。システム識別子５０１は、システム構成情報４００とは、Ｎ：１（Ｎは1以上の整数）で対応付けられている。また、システム識別子５０１には、システムの作成日、又は作成日及び削除日を含むサブ属性情報５１１が対応付けられている。このような構成により、ＰａａＳ構成情報履歴情報２１によると、指定された日時に、ボリュームリソース４３１を利用しているシステムのシステム識別子と、そのときのシステム構成情報４００とを検索して特定することができる。なお、ＰａａＳ構成情報履歴情報２１においては、他のミドルウェア（例えば、Ｈａｄｏｏｐ）によりデプロイされたシステムのシステム構成情報４００についても同様に管理することができる。

次に、サブシステム特性情報の抽出（決定）を説明する。

図７は、一実施形態に係るサブシステム特性情報の抽出を説明する図である。

サブシステム特性情報６００は、処理システムにおけるサブシステムの特徴を示す情報であり、新規にデプロイした処理システム（新規処理システム）と、ＰａａＳ構成情報履歴情報２１に記録されている過去にデプロイした処理システム（過去処理システム）と、のシステム構成の類似性を判定するために使用される情報である。図７は、システム構成情報４００が図５に示す状態である場合におけるサブシステム特性情報６００の例を示している。システム構成情報４００からサブシステム特性情報６００を抽出する方法については、後ほど詳細に説明するが、サブシステム特性情報６００は、処理システムに含まれる各ボリュームについての、システム構成上からそのボリュームの固有要素となり得ると考えられる特徴量に相当する。

サブシステム特性情報６００を抽出する処理は、大まかに３つのステップで構成される。まず、第１のステップでは、システム構成情報４００におけるボリュームを起点として、共通のリソースノード種類を経由するグラフ構造上のパスを抽出する。ここでいうパスとは、グラフ構造上でリンク４１２によって接続されているリソースノードを順番に並べたものを指している。図７中のパス６１１、６１２、６１３は、ボリュームリソース４３１、４３２、４３３に対して、例えば、「ボリューム−ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅ−ＰＶＣ−Ｐｏｄ−ＳｔａｔｅｆｕｌＳｅｔと、それぞれのＭｅｔａｄａｔａという、同じノード種類を経由して抽出されたパスである。以降では、このようなパス６１１、６１２、６１３を、ボリュームリソースに対する「共通パス」と呼ぶ。

次に、第２のステップでは、共通パス中に含まれるノード属性の中から、特定のリソースノード種類に特徴付けられる属性値を「特徴属性」として抽出し、この特徴属性をそのボリュームの特性情報とする。図７における属性リスト６３１、６３２、６３３は、それぞれ共通パス６１１、６１２，６１３から抽出された「特徴属性」に相当する。

次に、第３のステップでは、第２ステップで抽出された属性リスト（例えば、属性リスト６３１、６３２、６３３）について、重複する内容の属性リストを１つにまとめる処理を行い、その処理によって最終的に得られたものがサブシステム特性情報６００となる。図７の例では、属性リスト６３１、６３２、６３３から、内容が重複する属性リスト６３２，６３３が１つにまとめられ、属性リスト６３１に対応するサブシステム特性情報要素６２１と、属性リスト６３２，６３３が１つにまとめられたサブシステム特性情報要素６２２が得られることとなる。この内容が重複する属性リストを１つにまとめることは、それらの基となっている共通パスを１つのサブシステムとして取り扱っていることを意味している。この場合には、処理システムにおけるサブシステム数は、２となる。本実施例では、後述するように、このサブシステム数と、サブシステム特性情報６００中の「特徴属性」の文字列の一致率等によって、ボリュームに対する処理システムの類似性が判断されることとなる。

次に、ＰａａＳ構成−性能履歴対応付け情報２２について説明する。

図８は、一実施形態に係るＰａａＳ構成−性能履歴対応付け情報の構成を説明する図である。

図８の例では、図３のシステム構成におけるＰａａＳ構成と、ボリューム毎の性能履歴との対応付けを行った例を示している。ＰａａＳ構成−性能履歴対応付け情報２２は、縦軸方向に、各システム識別子５０１を並べ、横軸方向に、各サブシステム特性情報６００の各要素６２１を並べ、それぞれの交差する欄に、その欄に対応するシステム識別子５０１のサブシステム特性情報６００に対応するボリュームの性能情報（ボリューム性能情報７１１）が時系列で格納されているテーブル構成となっている。ボリュームの性能情報は、ボリュームの負荷情報（ＩＯＰＳ、スループットなど）である。ボリュームの負荷情報は、ＳＤＳノード４の性能情報監視部４２により収集されて、ＳＤＳ−ＰａａＳ管理サーバ１の性能情報収集部１２によって収集される。

一般的に性能情報は、ボリュームリソース４３１等を一意に特定する識別情報（例えば、ｉＳＣＳＩのターゲットＩＱＮと、ＬＵＮとの組など)と対応付けて構成される。ボリュームリソース（例えば、４３１）に対応する属性リスト（６３１）及びサブシステム特性情報６００は、図７に示すように、ＰａａＳ構成情報履歴情報２１のシステム構成情報４００を用いることで計算（抽出）できる。また、システム作成日（又はシステム作成日及び削除日）とボリュームリソースの識別情報とを用い、ＰａａＳ構成情報履歴情報２１の関連付けを辿ることにより、システム識別子５０１を特定することができる。このことから、図８に示すように或るボリュームの性能情報を、テーブル中のどの欄に格納する必要があるか否かを計算することができる。このテーブルを用いることにより、あるサブシステムのサブシステム特性情報６００が判明した場合に、そのサブシステム特性情報６００の類似度が最も高い列を選択し、その行方向の性能情報の履歴群からストレージリソースの負荷を予測することができる。

次に、計算機システム１００において、新規の処理システムＡで使用するＳＤＳノード４をプロビジョニングする場合におけるボリュームの配置を最適化する配置最適化処理を説明する。なお、配置最適化処理においては、新規の処理システムＡに含まれるボリューム（１〜Ｌ）を、クラウド基盤側１０２上のＳＤＳクラスタ内のどのＳＤＳノード４上に作成するかを決定することを問題としており、この問題は、ボリューム（１〜Ｌ）のそれぞれと対応付けられるＳＤＳノード４をＳＤＳノード４(１〜Ｍ)の中からそれぞれ選択する数学的な問題に帰着できる。

図９は、一実施形態に係る配置最適化処理のフローチャートである。

ＳＤＳ−ＰａａＳ管理サーバ１の配置管理部１５は、新規処理システム（この処理の説明において処理システムＡ）、及び、システム構成情報履歴情報２１中に蓄積された全処理システム（過去処理システム：処理システムＢ）に対して、ボリュームを開始点としたサブシステムを抽出する(ステップＳ８０１)。具体的には、ＳＤＳ−ＰａａＳ管理サーバ１は、新規処理システムと、過去処理システムとの全ての処理システムに対して、図７の共通パス６１１、６１２、６１３に示すような共通パス（サブシステム）を抽出する。ステップＳ８０１の詳細については、図１０のステップＳ９０１〜Ｓ９０５において説明する。

次いで、配置管理部１５は、ステップＳ８０１で抽出されたサブシステムの「特性情報」を抽出する。(ステップＳ８０２)。具体的には、配置管理部１５は、サブシステムの共通パス（例えば、図７の共通パス６１１、６１２、６１３）から、ボリューム特性情報（例えば、図７のボリューム特性情報６３１、６３２、６３３）を抽出する。ステップＳ８０２の詳細については、図１０のステップＳ９０６，Ｓ９０７において説明する。

次いで、配置管理部１５は、ステップＳ８０２で抽出された「特性情報」に対して、ＰａａＳ構成情報履歴情報２１に保存された処理システムＢと、処理システムＡとについて、サブシステム数と、「特徴属性」の文字列の一致数とに基づいて処理システムの類似度を計算する(ステップＳ８０３)。ステップＳ８０３の詳細については、図１１のステップＳ１００１〜Ｓ１００５において説明する。

次いで、配置管理部１５は、ステップＳ８０１〜Ｓ８０３について、ＰａａＳ構成情報履歴情報２１1に含まれる全ての処理システムＢと、処理システムＡとの類似度を計算した上で、各処理システムＢを類似度の降順にソートし、類似度が一番高い処理システムＢの構成を選択する（ステップＳ８０４）。

次いで、配置管理部１５は、ＰａａＳ構成−性能履歴対応付け情報２２を参照し、ステップＳ８０４で選択した処理システムＢのリソースの負荷を抽出する（ステップＳ８０５）。具体的には、配置管理部１５は、図７に示すテーブル形式のＰａａＳ構成−性能履歴対応付け情報２２において、列方向にサブシステム特性情報を検索して、新たに配置するボリュームに対応するサブシステム特性情報に該当する列を探し、その列の全ての行方向の性能履歴を抽出し、抽出した性能履歴に基づいて、ボリュームに関するリソース負荷（ＩＯＰＳ等）を計算する。リソース負荷の計算方法としては、例えば、Ｒｅａｄ／Ｗｒｉｔｅの時間当たりの負荷（ＩＯＰＳ）が最大となる値を選択してリソース負荷としたり、ＩＯＰＳの平均値を計算してリソース負荷としたり、ＩＯＰＳの中央値を取ってリソース負荷としたりするなどの方法がある。なお、コンテナやボリュームの容量などが過去の構成と異なる場合、それらの容量に応じてＩＯＰＳを比例計算させるなどして、ＩＯＰＳを現在の状態に対応するように調整してもよい。

次いで、配置管理部１５は、配置案を列挙する（ステップＳ８０６）。ここで、ボリューム配置については、ボリューム（１〜Ｌ）のそれぞれと対応付けられるＳＤＳノード４をＳＤＳノード４(１〜Ｍ)の中からそれぞれ選択する問題に帰着するため、配置管理部１５は、ステップＳ８０４で抽出した過去処理システムの構成に従って、使用するＳＤＳノード４と、ボリュームとを順列で組み合わせた配置案を表示出力する。

次いで、配置管理部１５は、性能予測部１４により各配置案におけるＳＤＳクラスタの性能負荷を予測する（ステップＳ８０７）。具体的には、配置管理部１５は、ステップＳ８０６での配置案を用いてボリュームを配置し、ステップＳ８０５で予測したリソース負荷を掛けた場合に、ＳＤＳクラスタの実際の性能（入力性能、出力性能等）がどの程度になるかを算出する。なお、ＳＤＳクラスタの挙動を予測するシミュレータとしては、既存のシミュレータを用いることができる。例えば、シミュレータとしては、待ち行列をベースとしたＣｌｏｕｄＳｉｍを用いてもよい。

次いで、配置管理部１５は、ステップＳ８０７での性能負荷の予測において、総合性能数値が最も良い配置案を最良配置案として選択し（ステップＳ８０８）、選択した最良配置案に従って、ボリュームのＳＤＳノード４への配置を実行する（ステップＳ８０９）。

上記した配置最適化処理によると、ＰａａＳ管理部３３が新規の処理システムのミドルウェア構成情報４０１を指定することにより、ミドルウェア構成情報４０１に記載されているボリューム要件（図５の例ではＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅ）を満たすボリュームを配置するのに最適なＳＤＳノード４を適切に決定して、配置させることができる。

次に、図９のステップＳ８０１及びＳ８０２に対応するサブシステム抽出処理について説明する。

図１０は、一実施形態に係るサブシステム抽出処理のフローチャートである。

配置管理部１５は、ミドルウェア構成情報４０１及びボリューム構成情報４０２において対象となる種類のボリュームリソースを選択する（ステップＳ９０１）。図７の例では、ボリュームリソース４３１，４３２，４３３を対象のボリュームリソースとして選択する。

次いで、配置管理部１５は、ミドルウェア構成情報４０１に基づいて、ステップＳ９０１で選択したボリュームリソースから、リンクで接続されたリソースノードを任意の回数辿ってたどり着けるリソースノードまでのパスを「構成パス」として収集する（ステップＳ９０２）。図７の例では、全リソースノードがリンクで繋がっているため、全てのボリュームに対して、全てのリンクが抽出される。

次いで、配置管理部１５は、複数のボリュームリソースを起点として「同一種類」のリソースノードを経由する構成パスを「共通パス」として抽出する（ステップＳ９０３）。図７の例では、ボリュームリソース４３１，４３２，４３３のそれぞれを起点として、「ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅ−ＰＶＣ−Ｐｏｄ−Ｃｏｎｔａｉｎｅｒ−Ｍｅｔａｄａｔａ」のように、同じノード種類を経由して辿れる構成パスを共通パスとして抽出する。

次いで、配置管理部１５は、「共通パス」中に、他のボリュームリソースの「構成パス」に含まれるリソースノードが存在する場合、そのパス中の起点のボリュームリソースからそのリソースノードまでのグラフ上の距離が、他のボリュームリソースからそのリソースノードまでの距離以下のリソースノードのみを残す（ステップＳ９０４）。例えば、図７に示すボリュームリソース４３１を起点とする構成パスには、「ＰｅｒｓｉｓｔｅｎｔＶｏｌｕｍｅ−ＰＶＣ−Ｐｏｄ−ＳｔａｔｅｆｕｌＳｅｔ−Ｐｏｄ−ＰＶＣ」というパスが存在するが、ＳｔａｔｅｆｕｌＳｅｔより後の部分については、ボリュームリソース４３２もしくは４３３のほうが距離が近いので、配置管理部１５は、共通パスからＳｔａｔｅｆｕｌＳｅｔより後の部分を破棄する。

次いで、配置管理部１５は、共通パスに含まれる、リソースノードのノード属性、及び、ノード種類を全てそのボリュームの「属性値」として収集する（ステップＳ９０５)。ノード属性には、例えば、Ｃｏｎｔａｉｎｅｒのリソースノードに含まれる「ｉｍａｇｅ：ｍｏｎｇｏＤＢ」や、Ｍｅｔａｄａｔａのリソースノードに含まれる「Ｒｏｌｅ：ｐｒｉｍａｒｙ」などが該当する。共通パスに含まれるとの考え方は任意でよく、例えば、全リソースノードのノード属性値を全て収集して、ボリュームの属性リストとしてもよい。ここで、上記したステップＳ９０１〜Ｓ９０５がステップＳ８０１に対応する。

次いで、各属性値が全処理システムの構成を対象として、何種類のリソースノード内で登場し、また何種類のシステム識別子と対応付けられた構成要素の中で登場するか数え、数えた結果（出現頻度）が一定の閾値を下回る場合に、属性値を「特性属性」として残す（ステップＳ９０６）。例えば、数えた結果に代えて、属性値が登場するノード種類×システム数による算出結果が閾値を下回るか否かを確認し、閾値を下回る場合に、属性値を特性属性として残すようにしてもよい。このようにすることにより、共通パスにおいて特徴と考えられる属性値を特性情報とすることができる。

例えば、「ＣｒｅａｔｉｏｎＴｉｍｅＳｔａｍｐ：ＸＸ−ＹＹ−ＺＺ」というような書式の属性値は、全リソースノードに登場するため、この属性値は全ノード種類で登場する。一方で、「ｉｍａｇｅ：ｙｙｙ」といった属性値は、Ｃｏｎｔａｉｎｅｒなど特定のノード種類のリソースノードにしか登場しない。また、「Ｐｒｉｍａｒｙ」、「Ｓｅｃｏｎｄａｒｙ」といった属性値は、特定のクラスタ構成のシステムにしか登場しないため、ノード種類が限定される上に、登場するシステム数も限られる。属性値が登場するノード種類×システム数による算出結果を閾値と比較するようにすると、普遍的に登場する「ＣｒｅａｔｉｏｎＴｉｍｅＳｔａｍｐ：ＸＸ−ＹＹ−ＺＺ」といった属性値は何度も数えられるため閾値を超えることが多く、特性属性として残されないようにすることができ、また、「ｉｍａｇｅ：ｙｙｙ」や「Ｐｒｉｍａｒｙ」、「Ｓｅｃｏｎｄａｒｙ」などの属性値は、カウントされる数が少ないので、閾値を下回ることが多く、特性属性として残すようにすることができる。

次いで、配置管理部１５は、ボリュームＩＤをキーにして、特性属性のリストを属性リストとして収集し、同種の属性リストを１つにまとめた結果をサブシステム特性情報６００とする（ステップＳ９０７）。このステップによると、図７中のボリューム特性情報６０１が作成され、サブシステム特性情報６００が作成される。同種の属性リストを１つにまとめるようにする、すなわち、同様な共通パスについては、１つの共通パスのボリューム特性情報として取り扱うようにすることで、共通パスの種類ごとに対するボリューム特性情報要素を含むボリューム特性情報６００を管理することができる。図７に示す例においては、システムにおけるサブシステムの数（種類数）は、２つとなる。このようにすることにより、過去処理システムと、新規処理システムとをそのシステム構成におけるサブシステムの種類について比較することができる。ここで、上記したステップＳ９０６，９０７がステップＳ８０２に対応する。

次に、図９のステップＳ８０３に対応する類似度決定処理について説明する。

図１１は、一実施形態に係る類似度決定処理のフローチャートである。

まず、配置管理部１５は、新規処理システムである処理システムＡと、過去に蓄積されている過去処理システムである処理システムＢとのそれぞれについて、図１０に示すサブシステム抽出処理で得られたサブシステム特性情報６００に基づいて、処理システムＡと処理システムＢとのサブシステム数（本実施形態では、種類数ともいえる）が同一であるか否かを判定する（ステップＳ１００１）。この結果、サブシステム数が同一でない場合には（ステップＳ１００１：Ｎ）、配置管理部１５は処理システムＡと処理システムＢとの類似度を最も低いことを示す０と決定し（ステップＳ１００５）、処理を終了する。

一方、サブシステム数が同一である場合には（ステップＳ１００１：Ｙ）、配置管理部１５は、処理システムＡの各サブシステムと、処理システムＢの各サブシステムとの組合せのそれぞれを対象に、ループ１の処理（ステップＳ１００２，Ｓ１００３）を実行する。ここで、処理対象の組合せの処理システムＡのサブシステムをサブシステムａとし、処理システムＢのサブシステムをサブシステムｂとする。

ループ１の処理においては、配置管理部１５は、サブシステムａと、サブシステムｂとの特徴属性を項目毎（行ごと）に文字列として比較し、一致する行数が最大となるような特徴属性の項目同士の対応付けを選択する（ステップＳ１００２）。

次いで、配置管理部１５は、選択した対応付けにおいて値が一致する特徴属性の数をカウントする（ステップＳ１００３）。

ループ１の処理（ステップＳ１００２，Ｓ１００３）をすべての組合せを対象に実行した場合には、配置管理部１５は、ループ１の処理を終了し、ステップＳ１００３でカウントした各組合せについての一致した特徴属性の数についての総和を計算し、この総和を処理システムＡと、処理システムＢとの類似度とし（ステップＳ１００４）、処理を終了する。

サブシステム比較処理によると、新規処理システムと、過去に蓄積されているそれぞれの過去処理システムとについての類似度を適切に決定することができる。

なお、本発明は、上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。

例えば、上記実施形態では、ＳＤＳ−ＰａａＳ管理サーバ１と別体の記憶装置２に、ＰａａＳ構成情報履歴情報２１及びＰａａＳ構成−性能履歴対応付け情報２２を格納するようにしていたが、本発明はこれに限られず、ＰａａＳ構成情報履歴情報２１及びＰａａＳ構成−性能履歴対応付け情報２２の少なくとも一方を、ＳＤＳ−ＰａａＳ管理サーバ１の記憶装置２０５に格納するようにしてもよい。

また、上記実施形態において、ＣＰＵが行っていた処理の一部又は全部を、専用のハードウェア回路で行うようにしてもよい。また、上記実施形態におけるプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

１…ＳＤＳ−ＰａａＳ管理サーバ、２…記憶装置、３…Ｃｏｍｐｕｔｅノード、４…ＳＤＳノード、５…ＳＡＮ、６…クライアント計算機、１１…構成情報監視部、１２…性能情報収集部、１３…構成管理部、１４…性能予測部、１５…配置管理部、２１…ＰａａＳ構成情報履歴情報、２２…ＰａａＳ構成−性能履歴対応付け情報、３１…アプリ、３２…ミドルウェア、３３…ＰａａＳ管理部、４１…ボリューム、４２…性能情報監視部、４００…システム構成情報、４０１…ミドルウェア構成情報、４０２…ボリューム構成情報

Claims (10)

1. 複数の汎用サーバノードで構成されるストレージシステムにおけるボリュームの配置を管理するボリューム配置管理装置であって、
   過去ボリュームを利用する過去処理システムにおけるシステム構成情報を取得する過去システム構成情報取得部と、
   前記過去処理システムにおける前記過去ボリュームの性能情報を記憶する過去ボリューム性能情報取得部と、
   新規ボリュームを利用する新規処理システムのシステム構成情報を取得する構成情報取得部と、
   前記過去処理システムのシステム構成情報に基づいて、前記新規処理システムのシステム構成と類似する過去処理システムを決定する類似システム決定部と、
   類似すると決定された過去処理システムが利用する過去ボリュームの性能情報に基づいて、前記新規ボリュームの負荷情報を予測する負荷予測部と、
   前記負荷情報の予測内容に基づいて、前記新規ボリュームの配置案を決定する配置案決定部と、を備え、
   前記類似システム決定部は、
   前記過去処理システムと、前記新規処理システムとのそれぞれについて、システム構成を利用するボリュームに基づいて１以上のサブシステムに分割するサブシステム分割部と、
   前記新規処理システムにおけるサブシステムの特徴属性と、前記過去処理システムのサブシステムにおける特徴属性との一致度合いに基づいて、類似度を判定する類似度判定部と、
   前記類似度に基づいて、前記新規処理システムのシステム構成と類似する過去処理システムを選択する選択部と、を備える
   ボリューム配置管理装置。
2. 前記類似システム決定部は、
   分割した前記サブシステムの属性情報を取得し、前記属性情報の出現頻度に基づいて、前記サブシステムにおける特徴属性を抽出する特徴項目抽出部を備える
   請求項１に記載のボリューム配置管理装置。
3. 前記サブシステム分割部は、前記過去処理システムと、前記新規処理システムとの前記システム構成における、各ボリュームを起点とするリソースのパスにおける、同種のリソースをたどることができる共通部分の集合のそれぞれをサブシステムとする
   請求項１に記載のボリューム配置管理装置。
4. 前記サブシステム分割部は、前記サブシステムにおける複数のボリュームからたどることができるリソースについては、起点とする一のボリュームよりも他のボリュームの方が近いリソースについては、前記一のボリュームを起点とするサブシステムから削除する
   請求項３に記載のボリューム配置管理装置。
5. 前記負荷予測部は、類似すると決定された前記過去処理システムが利用する過去ボリュームの負荷情報から１つ以上の実績値を抽出し、抽出した実績値の統計情報に基づいて、前記新規ボリュームの負荷情報を予測する
   請求項１から請求項４のいずれか一項に記載のボリューム配置管理装置。
6. 前記過去処理システム又は前記新規処理システムの前記システム構成情報は、前記過去処理システム又は前記新規処理システムを構成するミドルウェアの構成情報と、前記過去処理システム又は前記新規処理システムで使用されるストレージシステムでのボリューム構成情報とを含む
   請求項１から請求項５のいずれか一項に記載のボリューム配置管理装置。
7. 前記類似度判定部は、前記過去処理システムと前記新規処理システムのそれぞれにおいて、その処理システムにおける複数のサブシステムの特徴属性が一致する場合に、特徴属性が一致する複数のサブシステムを一つのサブシステムとし、前記過去処理システムと前記新規処理システムとのサブシステムの個数に基づいて、前記類似度を判定する
   請求項１から請求項６のいずれか一項に記載のボリューム配置管理装置。
8. 前記類似度判定部は、前記過去処理システムと前記新規処理システムとの前記サブシステムの個数が一致しない場合に類似度を最も低い値であると判定する
   請求項７に記載のボリューム配置管理装置。
9. 複数の汎用サーバノードで構成されるストレージシステムにおけるボリュームの配置を管理するボリューム配置管理装置によるボリューム配置管理方法であって、
   過去ボリュームを利用する過去処理システムにおけるシステム構成情報を取得するとともに、前記過去処理システムにおける前記過去ボリュームの性能情報を取得し、
   新規ボリュームを利用する新規処理システムのシステム構成情報を取得し、
   前記過去処理システムと、前記新規処理システムとのそれぞれについて、システム構成を利用するボリュームに基づいて１以上のサブシステムに分割し、
   前記新規処理システムにおけるサブシステムの特徴属性と、前記過去処理システムのサブシステムにおける特徴属性との一致度合いに基づいて、類似度を判定し、
   前記類似度に基づいて、前記新規処理システムのシステム構成と類似する過去処理システムを決定し、
   類似すると決定された過去処理システムが利用する過去ボリュームの性能情報に基づいて、前記新規ボリュームの負荷情報を予測し、
   前記負荷情報の予測内容に基づいて、前記新規ボリュームの配置案を決定する
   ボリューム配置管理方法。
10. 複数の汎用サーバノードで構成されるストレージシステムにおけるボリュームの配置を管理するボリューム配置管理装置を構成するコンピュータにより実行されるボリューム配置管理プログラムであって、
    前記コンピュータを、
    新規ボリュームを利用する新規処理システムのシステム構成情報を取得する構成情報取得部と、
    過去処理システムと、前記新規処理システムとのそれぞれについて、システム構成を利用するボリュームに基づいて１以上のサブシステムに分割し、
    前記新規処理システムにおけるサブシステムの特徴属性と、前記過去処理システムのサブシステムにおける特徴属性との一致度合いに基づいて、類似度を判定し、
    前記類似度に基づいて、前記新規処理システムのシステム構成と類似する過去処理システムを決定する類似システム決定部と、
    類似すると決定された過去処理システムが利用する過去ボリュームの性能情報に基づいて、前記新規ボリュームの負荷情報を予測する負荷予測部と、
    前記負荷情報の予測内容に基づいて、前記新規ボリュームの配置案を決定する配置案決定部として機能させる
    ボリューム配置管理プログラム。

Images