JP6622273B2 - リソース管理装置、リソース管理方法、及びリソース管理プログラム - Google Patents

Description

本発明は、余剰リソースの投入案を決定し、決定した投入案に従って余剰リソースの割当を制御するリソース管理装置等に関する。

ＩＴ資源（リソース）管理技術としては、ＩＴリソースの割当を動的に変更し、ＩＴリソースの管理コストを削減するための技術が検討されている。例えば、ストレージシステム全体を仮想化し、性能劣化／障害発生時の業務アプリケーション側の設定変更をさせることなくストレージのリソースを割り当てる技術が知られている（例えば、特許文献１参照）。

特開２００５−２１６１５１号公報

例えば、複数のストレージデバイス（例えば、ドライブ）を備えるストレージ装置においては、障害（異常）発生時における冗長性を確保するために、故障したドライブと交換するためのスペア（交換用）のドライブを備えておき、いずれかのドライブが故障した場合には、故障したドライブをスペアのドライブと切換えるようにすることが行われている。また、ストレージ装置においては、ピーク時に必要な性能や容量を見越して、物理ボリュームを構成するドライブの数が決められている。

例えば、上記したように、予めスペアのドライブを用意しておけば、ドライブの障害に対処することができる。しかしながら、ドライブを交換する場合においては、スペアのドライブが元のドライブと同等の性能を有しておく必要があり、コストが高くなるという問題がある。

これに対して、複数の性能の異なるドライブを用意することにより、コストを下げることが考えられるが、これらドライブをどのように使用するのかを決定することが重要となる。例えば、或る異常に対処するために或るドライブを使用した後に、別の異常が発生した場合に、最初に使用したドライブの種類によっては、別の異常に対処できない虞もある。

本発明は、上記事情に鑑みなされたものであり、その目的は、複数の異常が発生した場合において対処できる可能性を向上することのできる技術を提供することにある。

上記目的を達成するため、一観点に係るリソース管理装置は、複数の種類の余剰リソースを含む複数のリソースを備えるストレージ装置における異常の対処に用いる、前記余剰リソースの投入案を決定し、決定した投入案に従って前記余剰リソースの割当を制御するリソース管理装置であって、リソース管理装置は、プロセッサ部を備え、プロセッサ部は、ストレージ装置におけるリソースに関わる異常を検出し、異常を検出した場合に、ストレージ装置におけるリソースの運用情報に基づいて、異常を対処することのできる余剰リソースの投入案を１以上算出し、投入案が複数ある場合に、それぞれの投入案を実行する際に残存する余剰リソースによる、異常と同時に発生する可能性のある他の異常に対する対処可能状況に基づいて、異常の対処に用いる投入案を決定する。

本発明によれば、複数の異常が発生した場合において対処できる可能性を向上することができる。

図１は、一実施形態に係る計算機システムの全体構成図である。 図２は、一実施形態に係るストレージ装置のリソースの構成を説明する図である。 図３は、一実施形態に係るプール管理テーブルの構成図である。 図４は、一実施形態に係るＲＡＩＤ Ｇｒｏｕｐ管理テーブルの構成図である。 図５は、一実施形態に係るボリューム管理テーブルの構成図である。 図６は、一実施形態に係るドライブ管理テーブルの構成図である。 図７は、一実施形態に係るプール監視テーブルの構成図である。 図８は、一実施形態に係るドライブ監視テーブルの構成図である。 図９は、一実施形態に係るドライブ監視履歴テーブルの構成図である。 図１０は、一実施形態に係るプール監視履歴テーブルの構成図である。 図１１は、一実施形態に係る障害テーブルの構成図である。 図１２は、一実施形態に係るＲＡＩＤ Ｇｒｏｕｐ種別テーブルの構成図である。 図１３は、一実施形態に係るドライブ種別テーブルの構成図である。 図１４は、一実施形態に係るＴｉｅｒ種別テーブルの構成図である。 図１５は、一実施形態に係るリソース投入履歴テーブルの構成図である。 図１６は、一実施形態に係るページ移動性能一覧テーブルの構成図である。 図１７は、一実施形態に係るページ移動性能影響一覧テーブルの構成図である。 図１８は、一実施形態に係るリソース投入案一覧テーブルの構成図である。 図１９は、一実施形態に係る構成変更時間一覧テーブルの構成図である。 図２０は、一実施形態に係る構成変更手段一覧テーブルの構成図である。 図２１は、一実施形態に係る性能監視処理のフローチャートである。 図２２は、一実施形態に係るドライブ障害監視処理のフローチャートである。 図２３は、一実施形態に係るリソース投入処理のフローチャートである。 図２４は、一実施形態に係るリソース投入案算出処理のフローチャートである。 図２５は、一実施形態に係る組合せ算出処理のフローチャートである。 図２６は、一実施形態に係るリソース投入案選択処理のフローチャートである。 図２７は、一実施形態に係るリソース割当監視処理のフローチャートである。 図２８は、一実施形態に係るリソース回収処理のフローチャートである。 図２９は、一実施形態に係るリソース管理処理のフローチャートである。

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

以下の説明では、「ＡＡＡテーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ＡＡＡテーブル」を「ＡＡＡ情報」と呼ぶことができる。

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、プロセッサが行う処理の一部又は全部を、ハードウェア回路で行うようにしてもよい。プロセッサが実行するプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば、不揮発性の可搬型の記憶メディア）であってもよい。

また、以下の説明では、「ＲＡＩＤ」は、Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ （ｏｒ Ｉｎｅｘｐｅｎｓｉｖｅ） Ｄｉｓｋｓの略である。ＲＡＩＤ Ｇｒｏｕｐ（ＲＡＩＤグループ）は、複数の物理デバイス（典型的には同種の物理デバイス）で構成され、そのＲＡＩＤ Ｇｒｏｕｐに関連付けられたＲＡＩＤレベルに従いデータを記憶する。ＲＡＩＤ Ｇｒｏｕｐは、パリティグループと呼ばれてもよい。パリティグループは、例えば、パリティを格納するＲＡＩＤ Ｇｒｏｕｐのことでよい。

また、以下の説明では、要素の識別情報として、名前が使用されるが、それに代えて又は加えて他種の識別情報が使用されてもよい。また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られた名前を使用することがある。

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

計算機システム１は、１以上のサーバ１０と、ストレージ装置３０とを含む。サーバ１０と、ストレージ装置３０とは、通信ネットワークの一例としてのＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）２０を介して接続されている。

サーバ１０は、各種処理を実行することが可能であり、処理に伴うストレージ装置３０の仮想ボリューム４０５（図２参照）へのデータの書き込みや、仮想ボリューム４０５からのデータの読み込みを行う。

ストレージ装置３０は、複数のストレージデバイスを含むディスクユニット４０と、リソース管理装置の一例としてのストレージコントローラ５０とを備える。

ストレージコントローラ５０は、ディスクＩ／Ｆ（インターフェース）５１と、通信Ｉ／Ｆ５２と、プロセッサ部の一例としてのプロセッサ５３と、メモリ５４と、入力デバイス５５と、出力デバイス５６とを備えている。

ディスクＩ／Ｆ５１は、ストレージコントローラ５０とディスクユニット４０との間でのデータの転送の処理を行う。

通信Ｉ／Ｆ５２は、ＳＡＮ２０を介して他の装置（例えば、サーバ１０）と通信する。

入力デバイス５５は、例えば、マウス、キーボード等であり、ストレージ装置３０の管理者からの各種入力を受け付ける。出力デバイス５６は、例えば、液晶ディスプレイであり、各種情報を表示出力する。

プロセッサ５３は、メモリ５４に格納されているプログラムに従って各種処理を実行する。

メモリ５４は、例えば、ＲＡＭ（ＲＡＮＤＯＭ ＡＣＣＥＳＳ ＭＥＭＯＲＹ）であり、プロセッサ５３で実行されるプログラムや、各種テーブルや、必要な情報を記憶する。本実施形態では、メモリ５４は、監視プログラム６１と、リソース管理プログラム６５と、リソース割当制御プログラム６７と、テーブル群８０（テーブル８１〜９８）とを記憶する。

監視プログラム６１は、性能監視処理プログラム６２と、ドライブ障害監視処理プログラム６３と、リソース割当監視処理プログラム６４とを含む。リソース管理プログラム６５は、リソース管理処理プログラム６６を含む。リソース割当制御プログラム６７は、リソース投入処理プログラム６８と、リソース回収処理プログラム６９と、リソース投入案算出処理プログラム７０と、組合せ算出処理プログラム７１と、リソース投入案選択処理プログラム７２とを含む。なお、プロセッサ５３が各プログラムを実行することにより実行される処理については、後述する。

テーブル群８０は、プール管理テーブル８１と、ＲＡＩＤ Ｇｒｏｕｐ管理テーブル８２と、ボリューム管理テーブル８３と、ドライブ管理テーブル８４と、プール監視テーブル８５と、ドライブ監視テーブル８６と、ドライブ管理履歴テーブル８７と、プール監視履歴テーブル８８と、障害テーブル８９と、ＲＡＩＤ Ｇｒｏｕｐ種別テーブル９０と、ドライブ種別テーブル９１と、Ｔｉｅｒ種別テーブル９２と、リソース投入履歴テーブル９３と、ページ移動性能一覧テーブル９４と、ページ移動性能影響一覧テーブル９５と、リソース投入案一覧テーブル９６と、構成変更時間一覧テーブル９７と、構成変更手段一覧テーブル９８とを含む。各テーブルの詳細については後述する。

図２は、一実施形態に係るストレージ装置のリソースの構成を説明する図である。

ストレージコントローラ５０は、監視部５７と、リソース管理部５８と、リソース割当制御部５９とを備える。監視部５７は、プロセッサ５３が監視プログラム６１を実行することにより構成される。リソース管理部５８は、プロセッサ５３がリソース管理プログラム６５を実行することにより構成される。リソース割当制御部５９は、プロセッサ５３がリソース割当制御プログラム６７を実行することにより構成される。

ストレージ装置３０のディスクユニット４０は、複数のドライブ４０１を備える。ドライブ４０１は、リソースの一例である。複数のドライブ４０１は、種類や性能の異なるドライブであってもよい。ドライブ４０１としては、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）であってもよく、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）であってもよい。また、ドライブ４０１がＨＤＤである場合には、例えば、ＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ） ＨＤＤを含んでもよく、ＮＬ−ＳＡＳ（ニアラインＳＡＳ） ＨＤＤを含んでもよい。

複数のドライブ４０１のうちの一部の複数のドライブ４０１は、ストレージ装置３０内での異常に対処するために予備的に用意されている余剰リソースであり、余剰リソース群４０６として管理されている。本実施形態においては、余剰リソース群４０６のドライブ４０１の使用用途は、例えば、ドライブの交換専用といったように特定の用途に限定されていない。

ディスクユニット４０においては、複数のドライブ４０１により、１以上のＲＡＩＤ Ｇｒｏｕｐ４０２が構成されている。ＲＡＩＤ Ｇｒｏｕｐ４０２の記憶領域に基づいて、物理ボリューム４０３が構成されている。また、物理ボリューム４０３の記憶領域に基づいて、プール（容量プール）４０４が構成されている。また、ディスクユニット４０においては、サーバ１０に対して提供する、すなわち、サーバ１０がアクセスする対象となる１以上の仮想ボリューム４０５を備える。仮想ボリューム４０５は、その記憶領域が複数のページで管理されている。仮想ボリューム４０５には、このページを単位として、プール４０４の記憶領域が割り当てられる。ここで、ドライブ４０１の記憶領域に基づく、ＲＡＩＤ Ｇｒｏｕｐ４０２、物理ボリューム４０３、プール４０４、仮想ボリューム４０５もリソースの一例といえる。

次に、テーブル群８０に属する各テーブルの構成について詳細に説明する。

図３は、一実施形態に係るプール管理テーブルの構成図である。

プール管理テーブル８１は、ストレージ装置３０内の各プール４０４を管理するためのテーブルであり、各プール４０４に対応する行（レコード）を格納する。プール管理テーブル８１の行は、番号（＃）８１ａと、プール名８１ｂと、物理ボリューム名（Ｔｉｅｒ）８１ｃと、物理容量８１ｄとのフィールドを含む。

番号（＃）８１ａには、プール管理テーブル８１における行の番号が格納される。プール名８１ｂには、行に対応するプール４０４の名前（プール名）が格納される。物理ボリューム名（Ｔｉｅｒ）８１ｃには、行に対応するプール４０４の記憶領域を構成する物理ボリュームの名前と、プール４０４におけるＴｉｅｒ（階層）とが格納される。物理容量８１ｄには、行に対応するプール４０４に対して物理ボリューム名（Ｔｉｅｒ）８１ｃの物理ボリューム名に対応する物理ボリュームから提供されている記憶領域の物理容量が格納される。

図４は、一実施形態に係るＲＡＩＤ Ｇｒｏｕｐ管理テーブルの構成図である。

ＲＡＩＤ Ｇｒｏｕｐ管理テーブル８２は、ストレージ装置３０内の各ＲＡＩＤ Ｇｒｏｕｐ４０２を管理するためのテーブルであり、各ＲＡＩＤ Ｇｒｏｕｐ４０２に対応する行（レコード）を格納する。ＲＡＩＤ Ｇｒｏｕｐ管理テーブル８２の行は、番号（＃）８２ａと、ＲＡＩＤ Ｇｒｏｕｐ名８２ｂと、ドライブ名８２ｃと、ＲＡＩＤ Ｌｅｖｅｌ８２ｄとのフィールドを含む。

番号（＃）８２ａには、 ＲＡＩＤ Ｇｒｏｕｐ管理テーブル８２における行の番号が格納される。ＲＡＩＤ Ｇｒｏｕｐ名８２ｂには、行に対応するＲＡＩＤ Ｇｒｏｕｐ４０２の名前（ＲＡＩＤ Ｇｒｏｕｐ名）が格納される。ドライブ名８２ｃには、行に対応するＲＡＩＤ Ｇｒｏｕｐを構成する複数のドライブ４０１のドライブ名が格納される。ＲＡＩＤ Ｌｅｖｅｌ８２ｄには、行に対応するＲＡＩＤ Ｇｒｏｕｐ４０２のＲＡＩＤ Ｌｅｖｅｌが格納される。

図５は、一実施形態に係るボリューム管理テーブルの構成図である。

ボリューム管理テーブル８３は、ストレージ装置３０内の各ボリューム（物理ボリューム４０３及び仮想ボリューム４０５）を管理するためのテーブルであり、各ボリュームに対応する行（レコード）を格納する。ボリューム管理テーブル８３の行は、番号（＃）８３ａと、ボリューム名８３ｂと、ＲＡＩＤ Ｇｒｏｕｐ名 ｏｒ プール名８３ｃと、容量８１ｄとのフィールドを含む。

番号（＃）８３ａには、ボリューム管理テーブル８３における行の番号が格納される。ボリューム名８３ｂには、行に対応するボリュームの名前（ボリューム名）が格納される。ＲＡＩＤ Ｇｒｏｕｐ名 ｏｒ プール名８３ｃには、行に対応するボリュームの記憶領域を構成するＲＡＩＤ Ｇｒｏｕｐ４０２又はプール４０４の名前が格納される。容量８３ｄには、行に対応するボリュームの記憶領域の容量が格納される。

図６は、一実施形態に係るドライブ管理テーブルの構成図である。

ドライブ管理テーブル８４は、ストレージ装置３０内の各ドライブ４０１を管理するためのテーブルであり、各ドライブ４０１に対応する行（レコード）を格納する。ドライブ管理テーブル８４の行は、番号（＃）８４ａと、ドライブ名８４ｂと、ドライブタイプ８４ｃと、容量８４ｄと、状態８４ｅと、スピンアップ／ダウン８４ｆとのフィールドを含む。

番号（＃）８４ａには、ドライブ管理テーブル８４における行の番号が格納される。ドライブ名８４ｂには、行に対応するドライブの名前（ドライブ名）が格納される。ドライブタイプ８４ｃには、行に対応するドライブ４０１のドライブタイプが格納される。ドライブタイプとしては、例えば、ドライブ４０１がＳＳＤである場合には、ＳＳＤであり、ドライブ４０１がＳＡＳ ＨＤＤである場合には、ＳＡＳである。容量８４ｄには、行に対応するドライブ４０１の記憶領域の容量が格納される。状態８４ｅには、行に対応するドライブ４０１の状態が格納される。ドライブ４０１の状態としては、例えば、正常であることを示すＮＯＲＭＡＬと、異常（障害）であることを示すＥＲＲＯＲとがある。スピンアップ／ダウン８４ｆには、行に対応するドライブ４０１がスピンアップされているか、スピンダウンされているかを示す情報が格納される。

図７は、一実施形態に係るプール監視テーブルの構成図である。

プール監視テーブル８５は、ストレージ装置３０内の各プール４０４の最新の稼動情報を管理するためのテーブルであり、各プール４０４に対応する行（レコード）を格納する。プール監視テーブル８５の行は、番号（＃）８５ａと、プール名８５ｂと、使用率８５ｃと、割当ボリューム名（率）８５ｄと、しきい値［注意］８５ｅと、しきい値［異常］８５ｆと、容量変動率［短期］（間隔）８５ｇとのフィールドを含む。

番号（＃）８５ａには、プール監視テーブル８５における行の番号が格納される。プール名８５ｂには、行に対応するプール４０４のプール名が格納される。使用率８５ｃには、行に対応するプール４０４の記憶領域についての使用率（稼動情報の一例）が格納される。割当ボリューム名（率）８５ｄには、行に対応するプール４０４の記憶領域を割り当てたボリュームの名前と、割り当てた割合（率）とが格納される。しきい値［注意］８５ｅには、行に対応するプール４０４の使用率に関して注意状態（異常の一例）であることを検出するためのしきい値（しきい値［注意］）が格納される。しきい値［異常］８５ｆには、行に対応するプール４０４の使用率に関して異常状態であることを検出するしきい値（しきい値［異常］）が格納される。容量変動率［短期］（間隔）８５ｇには、行に対応するプール４０４の使用容量の短期的な変動率と、変動率に対応する間隔とが格納される。例えば、図７の１番の行は、プール０１のプール４０４は、使用率が５０％であり、物理ボリューム０１に対して記憶領域の１００％を割り当てており、しきい値［注意］が８０％であり、しきい値［異常］が９５％であり、１５分間（１５ｍｉｎ）の容量変動率が０％であることを示している。

図８は、一実施形態に係るドライブ監視テーブルの構成図である。

ドライブ監視テーブル８６は、ストレージ装置３０内の各ドライブ４０１の最新の稼動情報を管理するためのテーブルであり、各ドライブ４０１に対応する行（レコード）を格納する。ドライブ監視テーブル８６の行は、番号（＃）８６ａと、ドライブ名８６ｂと、稼働率８６ｃと、しきい値［注意］８６ｄと、しきい値［異常］８６ｅと、稼働率変動率［短期］（間隔）８６ｆとのフィールドを含む。

番号（＃）８６ａには、ドライブ監視テーブル８６における行の番号が格納される。ドライブ名８６ｂには、行に対応するドライブ４０１のドライブ名が格納される。稼動率８６ｃには、行に対応するドライブ４０１の稼動率（稼動情報の一例）が格納される。しきい値［注意］８６ｄには、行に対応するドライブ４０１の稼動率に関して注意状態（異常の一例）であることを検出するしきい値（しきい値［注意］）が格納される。しきい値［異常］８６ｅには、行に対応するドライブ４０１の稼動率に関して異常状態であることを検出するしきい値（しきい値［異常］）が格納される。稼動率変動率［短期］（間隔）８６ｆには、行に対応するドライブ４０１の稼動率の短期的な変動率と、変動率に対応する間隔とが格納される。例えば、図８の１番の行は、ドライブ０１のドライブ４０１は、稼動率が２０％であり、しきい値［注意］が６０％であり、しきい値［異常］が８０％であり、１５分間（１５ｍｉｎ）の稼動率変動率が０％であることを示している。

図９は、一実施形態に係るドライブ監視履歴テーブルの構成図である。

ドライブ監視履歴テーブル８７は、ストレージ装置３０内の各ドライブ４０１の過去からの稼動情報の履歴を管理するためのテーブルであり、各ドライブ４０１の各時点に対応する行（レコード）を格納する。ドライブ監視履歴テーブル８７の行は、番号（＃）８７ａと、ドライブ名８７ｂと、時間８７ｃと、稼働率８７ｄとのフィールドを含む。

番号（＃）８7ａには、ドライブ監視履歴テーブル８７における行の番号が格納される。ドライブ名８７ｂには、行に対応するドライブ４０１のドライブ名が格納される。時間８７ｃには、行に対応する時点を示す時間が格納される。稼動率８７ｄｃには、行に対応するドライブ４０１及び時点における稼動率が格納される。

図１０は、一実施形態に係るプール監視履歴テーブルの構成図である。

プール監視履歴テーブル８８は、ストレージ装置３０内の各プール４０４の過去からの稼動情報の履歴を管理するためのテーブルであり、各プール４０４の各時点に対応する行（レコード）を格納する。プール監視履歴テーブル８８の行は、番号（＃）８８ａと、プール名８８ｂと、時間８８ｃと、使用率８８ｄと、割当ボリューム（率）８８ｅとのフィールドを含む。

番号（＃）８８ａには、プール監視履歴テーブル８８における行の番号が格納される。プール名８８ｂには、行に対応するプール４０４のプール名が格納される。時間８８ｃには、行に対応する時点を示す時間が格納される。使用率８８ｄには、行に対応するプール４０４及び時点における使用率が格納される。割当ボリューム（率）８８ｅには、行に対応するプール４０４の記憶領域を割り当てたボリュームの名前と、割り当てた割合（率）とが格納される。

図１１は、一実施形態に係る障害テーブルの構成図である。

障害テーブル８９は、ストレージ装置３０内で発生する障害（異常）を管理するためのテーブルであり、障害種別及び障害部位に対応する行（レコード）を格納する。障害テーブル８９の行は、番号（＃）８９ａと、障害種別８９ｂと、障害部位８９ｃと、同時発生する障害８９ｄとのフィールドを含む。

番号（＃）８９ａには、障害テーブル８９における行の番号が格納される。障害種別９８ｂには、行に対応する障害種別が格納される。本実施形態においては、障害種別としては、例えば、アクセス速度等が低い等といった性能不足、プール４０４の記憶容量が枯渇している容量枯渇、ドライブに障害が発生しているドライブ障害等がある。障害部位８９ｃには、行に対応する障害が発生している部位（障害部位）が格納される。同時発生する障害８９ｄには、行に対応する障害種別及び障害部位が示す障害と同時に発生する可能性がある１以上の障害の情報が格納される。ここで、障害種別及び障害部位が示す障害と同時に発生する障害とは、障害種別及び障害部位が示す障害が発生した後において、その障害と並行して発生する可能性のある他の障害である。障害の情報は、例えば、同時に発生する他の障害に対応する障害テーブル８９における行の番号と、その障害の障害部位が複数存在する場合において障害が発生する確率との組を含んでもよい。なお、本実施形態では、同時発生する障害８９ｄにおいて、他の障害が選択的に発生する場合については、それぞれの障害情報をｏｒでつないで格納するようにしている。

例えば、図１１の３番の行は、プール０１のプール４０４についての容量枯渇という障害については、同時発生する他の障害として、障害テーブル８９の１行目の障害（確率１／１）又は２行目の障害（確率１／１）と、４行目の障害（確率１／１）と、５行目の障害（確率１／１６）と、６行目の障害（確率１／１６）とがあることを示している。

図１２は、一実施形態に係るＲＡＩＤ Ｇｒｏｕｐ種別テーブルの構成図である。

ＲＡＩＤ Ｇｒｏｕｐ種別テーブル９０は、ストレージ装置３０内で作成できるＲＡＩＤ Ｇｒｏｕｐの構成の一覧を示すテーブルであり、各ＲＡＩＤ Ｌｅｖｅｌに対応する行（レコード）を格納する。ＲＡＩＤ Ｇｒｏｕｐ種別テーブル９０の行は、番号（＃）９０ａと、ＲＡＩＤ Ｌｅｖｅｌ９０ｂと、信頼性評価値９０ｃと、性能評価値９０ｄとのフィールドを含む。

番号９０ａには、ＲＡＩＤ Ｇｒｏｕｐ種別テーブル９０における行の番号が格納される。ＲＡＩＤ Ｌｅｖｅｌ９０ｂには、行に対応するＲＡＩＤ Ｌｅｖｅｌが格納される。信頼性評価値９０ｃには、行に対応するＲＡＩＤ ＬｅｖｅｌのＲＡＩＤ Ｇｒｏｕｐについての信頼性の評価値（信頼性評価値）が格納される。本実施形態では、信頼性評価値が高いほど、信頼性が高い構成であることを示している。性能評価値９０ｄには、行に対応するＲＡＩＤ ＬｅｖｅｌのＲＡＩＤ Ｇｒｏｕｐについての性能の評価値（性能評価値）が格納される。本実施形態では、性能評価値が高いほど、性能が高い構成であることを示している。

図１３は、一実施形態に係るドライブ種別テーブルの構成図である。

ドライブ種別テーブル９１は、ストレージ装置３０に搭載可能なドライブ種別の一覧を示すテーブルであり、各ドライブ種別（ドライブタイプ）に対応する行（レコード）を格納する。ドライブ種別テーブル９１の行は、番号（＃）９１ａと、ドライブタイプ（容量）９１ｂと、スペアドライブタイプ（容量）９１ｃと、性能評価値９１ｄと、性能比９１ｅとのフィールドを含む。

番号９１ａには、ドライブ種別テーブル９１における行の番号が格納される。ドライブタイプ（容量）９１ｂには、行に対応するドライブタイプ及びドライブの容量が格納される。スペアドライブタイプ（容量）９１ｃには、行に対応するドライブタイプのドライブに障害が発生した際に、スペアドライブ（データ移動先のドライブ）として利用可能なドライブタイプ及びドライブの容量が格納される。なお、スペアドライブとして利用可能なドライブタイプが複数ある場合には、スペアドライブタイプ（容量）９１ｃには、複数のドライブタイプが格納される。性能評価値９１ｄには、行に対応するドライブタイプのドライブの性能評価値が格納される。本実施形態では、性能評価値が高いほど、性能が高いドライブであることを示している。性能比９１ｅには、ＮＬ−ＳＡＳのＨＤＤの性能を１とした場合における、行に対応するドライブタイプのドライブの性能を示す値（すなわち、性能比）が格納される。

図１４は、一実施形態に係るＴｉｅｒ種別テーブルの構成図である。

Ｔｉｅｒ種別テーブル９２は、ストレージ装置３０内で構成可能なプール４０４のＴｉｅｒ構成の一覧を示すテーブルであり、各Ｔｉｅｒ構成に対応する行（レコード）を格納する。Ｔｉｅｒ種別テーブル９２の行は、番号（＃）９２ａと、Ｔｉｅｒ９２ｂと、ドライブタイプ９２ｃとのフィールドを含む。

番号９２ａには、Ｔｉｅｒ種別テーブル９２における行の番号が格納される。Ｔｉｅｒ９２ｂには、行に対応するＴｉｅｒ構成を示す１以上のＴｉｅｒ名が格納される。ドライブタイプ９２ｃには、行に対応するＴｉｅｒ構成の各Ｔｉｅｒを構成することのできるドライブのタイプが格納される。例えば、図１４の８番の行は、Ｔｉｅｒ１とＴｉｅｒ２とによりＴｉｅｒを構成することができ、Ｔｉｅｒ１は、ＳＳＤで構成することができ、Ｔｉｅｒ２は、ＳＡＳ ＨＤＤで構成することができることを示している。

図１５は、一実施形態に係るリソース投入履歴テーブルの構成図である。

リソース投入履歴テーブル９３は、ストレージ装置３０における障害を解消するためのリソース投入の履歴を管理するためのテーブルであり、各リソース投入に対応する行（レコード）を格納する。リソース投入履歴テーブル９３の行は、番号（＃）９３ａと、投入時間９３ｂと、回収時間９３ｃと、障害部位９３ｄと、障害種別９３ｅと、投入リソース９３ｆとのフィールドを含む。

番号９３ａには、リソース投入履歴テーブル９３における行の番号が格納される。投入時間９３ｂには、行に対応するリソース投入を行った時間（例えば、年／月／日 時：分）が格納される。回収時間９３ｃには、行に対応するリソース投入を行ったリソースの回収を行った時間が格納される。なお、まだリソースが回収されていない場合には、回収時間９３ｃは、空白となっている。障害部位９３ｄには、行に対応するリソース投入を行うこととなった障害部位が格納される。障害種別９３ｅには、行に対応するリソース投入の原因となった障害の種別が格納される。投入リソース９３ｆには、行に対応するリソース投入において、投入したリソースが格納される。

例えば、図１５の１番の行は、プール０１の性能不足という障害に対して、ドライブ１３〜１８によりＲＡＩＤ５（５Ｄ＋１Ｐ）のＲＡＩＤ Ｇｒｏｕｐ０３を作成し、このＲＡＩＤ Ｇｒｏｕｐ０３の記憶領域により物理ボリューム０３（容量５００ＧＢ）を作成し、この物理ボリューム０３をプール０１のＴｉｅｒ１に追加するように割り当てるリソース投入が、２０１７／０１／０１ １２：００に行われ、投入されたリソースはまだ回収されていないことを示している。

図１６は、一実施形態に係るページ移動性能一覧テーブルの構成図である。

ページ移動性能一覧テーブル９４は、ストレージ装置３０でのページ移動時の性能（ページ移動性能）を管理するためのテーブルであり、ページ移動性能に対応する行（レコード）を格納する。ページ移動性能一覧テーブル９４の行は、番号（＃）９４ａと、速度種別９４ｂと、速度９４ｃとのフィールドを含む。

番号９４ａには、ページ移動性能一覧テーブル９４における行の番号が格納される。速度種別９４ｂには、行に対応するページ移動性能に対応する速度種別が格納される。速度９４ｃには、行に対応するページ移動性能における転送速度が格納される。

図１７は、一実施形態に係るページ移動性能影響一覧テーブルの構成図である。

ページ移動性能影響一覧テーブル９５は、ストレージ装置３０でのページ移動を行った際の負荷（ここでは、稼働率）の増加量を管理するためのテーブルであり、ページ移動を行うＲＡＩＤ Ｇｒｏｕｐの構成毎に対応する行（レコード）を格納する。ページ移動性能影響一覧テーブル９５の行は、番号（＃）９５ａと、ＲＡＩＤ Ｌｅｖｅｌ９５ｂと、ドライブタイプ９５ｃと、低速時の負荷［移動先／移動元］９５ｄとのフィールドを含む。

番号９５ａには、ページ移動性能影響一覧テーブル９５における行の番号が格納される。ＲＡＩＤ Ｌｅｖｅｌ９５ｂとには、行に対応するＲＡＩＤ ＧｒｏｕｐのＲＡＩＤ Ｌｅｖｅｌが格納される。ドライブタイプ９５ｃには、行に対応するＲＡＩＤ Ｇｒｏｕｐを構成するドライブのタイプが格納される。低速時の負荷［移動先／移動元］９５ｄには、行に対応するＲＡＩＤ Ｇｒｏｕｐの構成において、低速でのページ移動を行った際の移動先のドライブ及び移動元のドライブにおける負荷の増加量（稼動率の増加量）が格納される。

図１８は、一実施形態に係るリソース投入案一覧テーブルの構成図である。

リソース投入案一覧テーブル９６は、ストレージ装置３０における異常を解消（解決）するために算出されたリソース投入案を管理するテーブルであり、各リソース投入案に対応する行（レコード）を格納する。リソース投入案一覧テーブル９６は、例えば、対象とする異常毎に備えられる。リソース投入案一覧テーブル９６の行は、番号（＃）９６ａと、評価値９６ｂと、障害＃（番号）９６ｃと、追加ボリューム（容量）９６ｄと、追加ＲＡＩＤ Ｇｒｏｕｐ９６ｅと、追加ドライブ９６ｆと、構成変更９６ｇとのフィールドを含む。

番号９６ａには、リソース投入案一覧テーブル９６における行の番号が格納される。評価値９６ｂには、行に対応するリソース投入案に対する評価値が格納される。本実施形態では、評価値９６ｂには、例えば、物理ボリュームに係る障害の発生時に、物理ボリュームを追加するリソース投入案であれば、追加する物理ボリュームの信頼性評価値が障害に係る物理ボリュームと同等であり、性能評価値が同等以上である場合には、「１」が設定され、信頼性評価値が障害に係る物理ボリュームと同等であり、性能評価値が同等未満である場合には、「２」が設定される。本実施形態では、評価値９６ｂに設定される評価値は、小さいほど評価が高いことを示している。障害＃（番号）９６ｃには、行に対応するリソース投入案が解消する障害種別に対応する番号（障害種別に対応する障害テーブル８９における行の番号）が格納される。追加ボリューム（容量）９６ｄには、行に対応するリソース投入案により追加されるボリュームのボリューム名と、追加される容量が格納される。追加ＲＡＩＤ Ｇｒｏｕｐ９６ｅには、行に対応するリソース投入案により追加されるＲＡＩＤ ＧｒｏｕｐのＲＡＩＤ Ｌｅｖｅｌが格納される。追加ドライブ９６ｆには、行に対応するリソース投入案で追加されるドライブのタイプ及び個数が格納される。構成変更９６ｇには、この行に対応するリソース投入案による変更される構成の内容が格納される。

図１９は、一実施形態に係る構成変更時間一覧テーブルの構成図である。

構成変更時間一覧テーブル９７は、ストレージ装置３０での構成変更を行った際に要する時間を管理するためのテーブルであり、構成変更の内容毎に対応する行（レコード）を格納する。構成変更時間一覧テーブル９７の行は、番号（＃）９７ａと、構成変更９７ｂと、時間９７ｃとのフィールドを含む。

番号９７ａには、構成変更時間一覧テーブル９７における行の番号が格納される。構成変更９７ｂには、この行に対応する構成変更の内容が格納される。時間９７ｃには、この行に対応する構成変更に要する時間（分（ｍｉｎ））が格納される。

図２０は、一実施形態に係る構成変更手段一覧テーブルの構成図である。

構成変更手段一覧テーブル９８は、ストレージ装置３０での構成変更を行う手段を管理するためのテーブルであり、構成変更を行う手段毎に対応する行（レコード）を格納する。構成変更手段一覧テーブル９８の行は、番号（＃）９８ａと、障害種別９８ｂと、手段９８ｃと、構成変更９８ｄとのフィールドを含む。

番号９８ａには、構成変更手段一覧テーブル９８における行の番号が格納される。障害種別９８ｂには、この行に対応する構成変更を行う手段により解消される障害種別が格納される。手段９８ｃには、この行に対応する手段が格納される。構成変更９８ｂには、この行に対応する構成変更を行う手段による構成変更の内容が格納される。

次に、一実施形態に係るストレージ装置３０における処理動作について説明する。

図２１は、一実施形態に係る性能監視処理のフローチャートである。

性能監視処理は、プロセッサ５３が性能監視処理プログラム６２を実行することにより行われる。この性能監視処理は、例えば、ストレージ装置３０の電源がＯＮとなった後に実行が開始され、継続して実行される。

まず、プロセッサ５３は、ストレージ装置３０の稼動情報（各ドライブ４０４の稼動率、及び各プール４０４の使用率）を取得する（ステップＳ１１）。

次いで、プロセッサ５３は、取得した稼動率と、使用率とに基づいて、監視履歴テーブル（ドライブ監視履歴テーブル８７及びプール監視履歴テーブル８８）を更新する（ステップＳ１２）。

次いで、プロセッサ５３は、以下の式（１）により稼動情報についての変動率［短期］ｈ（容量変動率［短期］及び稼動率変動率［短期］）を算出する（ステップＳ１３）。
ｈ＝１＋（ｄ（１）−ｄ（Ｔ／ｔ））／ｄ（Ｔ／ｔ） ・・・（１）
ここで、Ｔは、変動率［短期］を算出する周期（間隔）であり、ｔは、稼動情報の取得間隔である。また、ｄ（ｎ）は、時点ｎの稼動情報を示し、ｎ＝１は、稼動情報を取得した最新の時点を示し、ｎ＝２，３，・・・は、稼動情報を取得した１周期前の時点，２周期前の時点，・・・を示している。したがって、ｄ（Ｔ／ｔ）は、変動率［短期］の算出周期の１周期前の時点における稼動情報を示している。

次いで、プロセッサ５３は、ステップＳ１１で取得した稼動情報と、ステップＳ１３で算出した変動率［短期］（容量変動率［短期］及び稼動率変動率［短期］）とに基づいて、監視テーブル（プール監視テーブル８５及びドライブ監視テーブル８６）を更新する（ステップＳ１４）。具体的には、プロセッサ５３は、プール監視テーブル８５における各プールに対応する行における使用率８５ｃの値をステップＳ１１で取得した使用率に更新するとともに、容量変動率［短期］（間隔）８５ｇの値をステップＳ１３で算出した容量変動率［短期］及びその間隔に更新し、また、ドライブ監視テーブル８６における各ドライブに対応する行における稼動率８６ｃの値をステップＳ１１で取得した稼動率に更新するとともに、稼働率変動率［短期］（間隔）８６ｆの値をステップＳ１３で算出した稼動率変動率［短期］及びその間隔に更新する。

次いで、プロセッサ５３は、プール監視テーブル８５及びドライブ監視テーブル８６の各行を対象にステップＳ１５の処理を行う。まず、プロセッサ５３は、対象とするレコードの稼動情報（使用率又は稼動率）がその行のしきい値［注意］の値を超過しているか否かを判定し（ステップＳ１５）、稼動情報がしきい値［注意］を超過している場合（ステップＳ１５：ＹＥＳ）には、異常が発生していることを意味しているので、異常を解消するためにリソースを投入するリソース投入処理（ステップＳ１６：図２３参照）を実行させ、稼動情報がしきい値［注意］を超過していない場合（ステップＳ１５：ＮＯ）には、何もしない。

そして、プール監視テーブル８５及びドライブ監視テーブル８６の各行を対象にステップＳ１５以降の処理を行った後に、プロセッサ５３は、次監視周期まで処理を停止し（ステップＳ１７）、その後、処理をステップＳ１１に進める。

図２２は、一実施形態に係るドライブ障害監視処理のフローチャートである。

ドライブ障害監視処理は、プロセッサ５３がドライブ障害監視処理プログラム６３を実行することにより行われる。このドライブ障害監視処理は、例えば、ストレージ装置３０の電源がＯＮとなった後に実行が開始され、継続して実行される。

まず、プロセッサ５３は、ストレージ装置３０の各ドライブ４０１の状態の情報（ドライブ情報）を取得する（ステップＳ２１）。ここで、ドライブ情報とは、例えば、ドライブ４０１が通常動作している状態（ＮＯＲＭＡＬ）であるか、障害が発生している状態（ＥＲＲＯＲ）であるかの情報である。

次いで、プロセッサ５３は、取得したドライブ情報に基づいて、ドライブ管理テーブル８４を更新する（ステップＳ２２）。具体的には、プロセッサ５３は、ドライブ管理テーブル８４の各ドライブ４０１の行の状態８４ｅの値を取得した各ドライブ４０１のドライブ情報の値に更新する。

次いで、プロセッサ５３は、ドライブ管理テーブル８４の各行を対象にステップＳ２３の処理を行う。まず、プロセッサ５３は、行に対応するドライブにドライブ障害が発生しているか否かを判定する（ステップＳ２３）。具体的には、プロセッサ５３は、行の状態８４ｅがＥＲＲＯＲであるか否かに基づいて、ドライブ４０１にドライブ障害が発生しているか否かを判定する。

この結果、ドライブ障害が発生している場合（ステップＳ２３：ＹＥＳ）には、プロセッサは、ドライブ障害を解消するためにリソースを投入するリソース投入処理（ステップＳ１６：図２３参照）を実行させ、ドライブ障害が発生していない場合（ステップＳ２３：ＮＯ）には、何もしない。

そして、ドライブ管理テーブル８４の各行を対象にステップＳ２３からの処理を行った後に、プロセッサ５３は、次監視周期まで処理を停止し（ステップＳ２４）、その後、処理をステップＳ２１に進める。

図２３は、一実施形態に係るリソース投入処理のフローチャートである。

リソース投入処理は、プロセッサ５３がリソース投入処理プログラム６８を実行することにより行われる。このリソース投入処理は、図２１の性能監視処理及び図２２のドライブ障害監視処理のステップＳ１６で実行される処理である。

プロセッサ５３は、障害がドライブ障害（ドライブ４０１のハードウェアの障害）であるか否かを判定する（ステップＳ３１）。ここで、このリソース投入処理がドライブ障害監視処理において実行された場合には、ドライブ障害であると判定される。

この結果、障害がドライブ障害である場合（ステップＳ３１：ＹＥＳ）には、プロセッサ５３は、障害に対処するまでの猶予時間をドライブ障害時の所定の時間（本実施形態では、例えば、０．１（ｍｉｎ））とし（ステップＳ３２）、この障害に対処するためのリソース投入案を算出するリソース投入案算出処理（ステップＳ３５：図２４参照）の実行を開始させる。

一方、障害がドライブ障害でない場合（ステップＳ３１：ＮＯ）には、プロセッサ５３は、ループＡの処理（ステップＳ３３）を実行する。ループＡでは、各変数ｎの値を１から１ずつ増加させて、各変数を対象にステップＳ３３の処理を実行する。

具体的には、プロセッサ５３は、０＞Ｓ−Ｆ（ｎ）であるか否かを判定する（ステップＳ３３）。
ここで、Ｓは、障害が発生しているリソースのしきい値［異常］であり、例えば、プール４０４の障害に対する処理であれば、プール監視テーブル８５の障害が検出されたプール４０４の行におけるしきい値［異常］８５ｆの値であり、例えば、ドライブ４０１の障害（稼動率に対する障害）に対する処理であれば、ドライブ監視テーブル８６の障害が検出されたドライブ４０１の行におけるしきい値［異常］８６ｅの値である。また、Ｆ（ｎ）＝ｄ（１）×ｈ^ｎであり、例えば、Ｆ（１）＝ｄ（１）×ｈ、Ｆ（２）＝ｄ（１）×ｈ×ｈ，Ｆ（３）＝ｄ（１）×ｈ×ｈ×ｈである。Ｆ（ｎ）は、ｎ周期（周期は、変動率［短期］の演算周期）後における稼動情報の推定値を示している。

したがって、０＞Ｓ−Ｆ（ｎ）であるか否かの判定は、ｎ周期後の稼動情報の値が、しきい値［異常］の値を超えているか否かを判定していることを意味している。

この結果、０＞Ｓ−Ｆ（ｎ）である場合（ステップＳ３３：ＹＥＳ）には、稼動情報がしきい値［異常］の値を超えていることを意味しているので、プロセッサ５３は、ループＡの処理を抜けて処理をステップＳ３４に進める。一方、０＞Ｓ−Ｆ（ｎ）でない場合（ステップＳ３３：ＮＯ）には、稼動情報がしきい値［異常］を超えていないことを意味しているので、プロセッサ５３は、ループＡの処理を継続して実行する。このループＡの処理によると、しきい値［異常］を超えるまでの周期を適切に検出することができる。

ステップＳ３４では、プロセッサ５３は、ｎ×Ｔを猶予時間とし、その後、この障害に対処するためのリソース投入案を算出するリソース投入案算出処理（ステップＳ３５：図２４参照）の実行を開始させる。

リソース投入案算出処理が終了した後に、プロセッサ５３は、ステップＳ３５で算出されたリソース投入案から実際に実行するリソース投入案を選択するリソース投入案選択処理（ステップＳ３６：図２６参照）の実行を開始させる。

リソース投入案選択処理が終了した後に、プロセッサ５３は、選択したリソース投入案によるストレージ装置５０の構成変更が反映されるように、管理テーブル（プール管理テーブル８１、ＲＡＩＤ Ｇｒｏｕｐ管理テーブル８２、ボリューム管理テーブル８３、ドライブ管理テーブル８４の少なくともいずれか１つのテーブル）を更新し（ステップＳ３７）、選択したリソース投入案の構成変更を実施する（ステップＳ３８）。この後、プロセッサ５３は、リソース投入履歴テーブル９３に実施したリソース投入案に対応する行を追加する更新を行い（ステップＳ３９）、リソース投入処理を終了する。

図２４は、一実施形態に係るリソース投入案算出処理のフローチャートである。

リソース投入案算出処理は、プロセッサ５３がリソース投入案算出処理プログラム７０を実行することにより行われる。このリソース投入案算出処理は、図２３のリソース投入処理のステップＳ３５で実行される処理である。

プロセッサ５３は、障害がドライブ障害であるか否かを判定する（ステップＳ４１）。

この結果、障害がドライブ障害でない場合（ステップＳ４１：ＮＯ）には、プロセッサ５３は、障害種別が容量枯渇か否かを判定する（ステップＳ４２）。

この結果、障害種別が容量枯渇である場合（ステップＳ４２：Ｙｅｓ）には、プロセッサ５３は、障害が発生している物理ボリューム（以下、本処理の説明において該当物理ボリュームという）と、同等の信頼性評価値及び同等以上の性能評価値となり、且つ、同一Ｔｉｅｒに追加することのできる物理ボリュームについての、ＲＡＩＤ Ｇｒｏｕｐ、ドライブ、及び構成変更手段の組み合わせを算出するために組合せ算出処理（ステップＳ４３：図２５参照）を実行させる。

組合せ算出処理の実行後に、プロセッサ５３は、追加する物理ボリュームに必要な容量を算出する（ステップＳ４４）。具体的には、プロセッサ５３は、以下の式（２）により、必要な容量を算出する。
必要な容量［ＧＢ］＝Ｆ（ｘ）×物理容量［ＧＢ］−ｄ（１）×物理容量［ＧＢ］ ・・・（２）
ここで、ｘは、予め設定されている定数であり、例えば、容量により余裕を持たせる場合には、ｘの値を大きくすればよい。

次いで、プロセッサ５３は、構成変更時間一覧テーブル９７を参照し、ステップＳ４３で算出された各組み合わせの構成変更に必要な時間を算出する（ステップＳ４５）。

次いで、プロセッサ５３は、ステップＳ４３で算出された各組み合わせの中から、追加する容量［ＧＢ］が必要な容量［ＧＢ］よりも多く、且つ、構成変更に必要な時間が猶予時間未満である組み合わせをリソース投入案として抽出し（ステップＳ４６）、新たなリソース投入案一覧テーブル９６を作成し、このリソース投入案一覧テーブル９６に、抽出したリソース投入案に対応する行を追加する（ステップＳ４７）。

次いで、プロセッサ５３は、該当物理ボリュームと、同等の信頼性評価値となり、且つ、下位のＴｉｅｒに追加することのできる物理ボリュームについての、ＲＡＩＤ Ｇｒｏｕｐ、ドライブ、及び構成変更手段の組み合わせを算出するために組合せ算出処理（ステップＳ４８：図２５参照）を実行させる。

組合せ算出処理の実行後に、プロセッサ５３は、該当物理ボリュームから追加する物理ボリュームに対するページ移動に伴う通信量の増加量を算出する（ステップＳ４９）。具体的には、プロセッサ５３は、以下の式（３）により、増加量を算出する。
増加量［Ｍｂｐｓ］＝（物理容量［ＧＢ］×Ｆ（１）−物理容量［ＧＢ］×ｄ（１））×１０２４×８）÷（Ｔ×６０） ・・・（３）

次いで、プロセッサ５３は、構成変更時間一覧テーブル９７を参照し、ステップＳ４８で算出された各組み合わせの構成変更に必要な時間を算出する（ステップＳ５０）。

次いで、プロセッサ５３は、ステップＳ４８で算出された各組み合わせの中から、プール（追加する物理ボリューム）を構成するドライブの稼動率と、ページ移動性能影響一覧テーブル９５から取得されるページ移動時の負荷とを加算した値が、しきい値［注意］よりも小さく、増加量［Ｍｂｐｓ］がページ移動速度（ページ移動性能一覧テーブル９４の行の速度９４ｃの値）よりも小さく、追加する容量［ＧＢ］が必要な容量［ＧＢ］よりも多く、且つ、構成変更に必要な時間が猶予時間未満である組み合わせをリソース投入案として抽出し（ステップＳ５１）、処理をステップＳ６２に進める。

一方、ステップＳ４２において、障害種別が容量枯渇でない場合（ステップＳ４２：ＮＯ）には、障害種別が性能低下であることを示しているので、プロセッサ５３は、該当物理ボリュームと、同等の信頼性評価値及び同等以上の性能評価値となり、且つ、同一Ｔｉｅｒに追加することのできる物理ボリュームについての、ＲＡＩＤ Ｇｒｏｕｐ、ドライブ、及び構成変更手段の組み合わせを算出するために組合せ算出処理（ステップＳ５２：図２５参照）を実行させる。

組合せ算出処理の実行後に、プロセッサ５３は、構成変更時間一覧テーブル９７を参照し、ステップＳ５２で算出された各組み合わせの構成変更に必要な時間を算出する（ステップＳ５３）。

次いで、プロセッサ５３は、ステップＳ５２で算出された各組み合わせの中から、ドライブを該当物理ボリュームと同一のＴｉｅｒに追加した場合に想定される稼動率（想定稼動率）が、しきい値［注意］よりも小さくなり、且つ、構成変更に必要な時間が猶予時間未満である組み合わせをリソース投入案として抽出する（ステップＳ５４）。
ここで、推定稼動率は、例えば、以下の式（４）により算出することができる。
推定稼動率＝（Ｆ（ｘ）×該当物理ボリュームが所属するＴｉｅｒのドライブ数）÷（該当物理ボリュームが所属するＴｉｅｒのドライブ数＋組み合わせでの追加するドライブ数） ・・・（４）

次いで、プロセッサ５３は、新たなリソース投入案一覧テーブル９６を作成し、このリソース投入案一覧テーブル９６に、ステップＳ５４で抽出したリソース投入案に対応する行を追加する（ステップＳ５５）。

次いで、プロセッサ５３は、該当物理ボリュームと、同等の信頼性評価値及び同等以上の性能評価値となり、且つ、上位のＴｉｅｒに追加することのできる物理ボリュームについての、ＲＡＩＤ Ｇｒｏｕｐ、ドライブ、及び構成変更手段の組み合わせを算出するために組合せ算出処理（ステップＳ５６：図２５参照）を実行させる。

次いで、プロセッサ５３は、構成変更時間一覧テーブル９７を参照し、ステップＳ５６で算出された各組み合わせの構成変更に必要な時間を算出する（ステップＳ５７）。

次いで、プロセッサ５３は、ステップＳ５６で算出された各組み合わせの中から、ドライブを該当物理ボリュームの上位のＴｉｅｒに追加した場合に想定される稼動率（上位Ｔｉｅｒ想定稼動率）が、しきい値［注意］よりも小さくなり、且つ、構成変更に必要な時間が猶予時間未満である組み合わせをリソース投入案として抽出し（ステップＳ５８）、処理をステップＳ６２に進める。
ここで、上位Ｔｉｅｒ推定稼動率は、例えば、以下の式（５）により算出することができる。
上位Ｔｉｅｒ推定稼動率＝（Ｆ（ｘ）×該当物理ボリュームが所属するＴｉｅｒのドライブ数×該当物理ボリュームのドライブの性能比）÷（（該当物理ボリュームが所属するＴｉｅｒの上位のｔｉｅｒのドライブ数＋組み合わせでの追加するドライブ数）×追加する物理ボリュームのドライブの性能比） ・・・（５）
なお、物理ボリュームのドライブの性能比は、ドライブ種別テーブル９１のドライブに対応する行の性能比９１ｅの値から取得することができる。

一方、ステップＳ４１で、障害がドライブ障害である場合（ステップＳ４１：ＹＥＳ）と判定された場合には、プロセッサ５３は、障害が発生したドライブのスペアドライブとして利用可能な１以上のドライブ（リソース投入案に相当）を算出し（ステップＳ５９）、障害が発生したドライブをスペアドライブと交換するための構成変更に必要な時間を算出し（ステップＳ６０）、構成変更に必要な時間が猶予時間未満となるようなリソース投入案を抽出し（ステップＳ６１）、処理をステップＳ６２に進める。

ステップＳ６２では、プロセッサ５３は、リソース投入案一覧テーブル９６に、直前のステップ（ステップＳ５１，Ｓ５８，又はＳ６１）で抽出したリソース投入案に対応する行を追加する。なお、ステップＳ６１を経由している場合には、プロセッサ５３は、新たにリソース投入案一覧テーブル９６を作成する。

このリソース投入案算出処理によると、障害の解消に実施できるリソース投入案（複数あれば、複数のリソース投入案）に対応する行がリソース投入案一覧テーブル９６に格納されることとなる。

図２５は、一実施形態に係る組合せ算出処理のフローチャートである。

組合せ算出処理は、プロセッサ５３が組合せ算出処理プログラム７１を実行することにより行われる。この組合せ算出処理は、図２４のリソース投入案算出処理のステップＳ４３，Ｓ４８，Ｓ５２，Ｓ５６で実行される処理である。

プロセッサ５３は、ドライブ管理テーブル８４の中の状態８４ｅの値がＮＯＲＭＡＬである行に対応するドライブ４０１であって、ＲＡＩＤ Ｇｒｏｕｐに所属していないドライブ４０１を特定し、このドライブ４０１を余剰リソースとして把握する（ステップＳ７１）。ドライブ４０１がＲＡＩＤ Ｇｒｏｕｐに所属しているか否かは、ＲＡＩＤ Ｇｒｏｕｐ管理テーブル８２の各行のドライブ名８２ｃとしてドライブ名が設定されているか否かによって特定することができる。

次いで、プロセッサ５３は、ＲＡＩＤ Ｇｒｏｕｐ管理テーブル８２、ボリューム管理テーブル８３、及びドライブ管理テーブル８４を参照して、該当物理ボリューム（組合せ算出処理を実行させたリソース投入案算出処理における該当物理ボリューム）のＲＡＩＤ Ｌｅｖｅｌ、ドライブタイプを取得する。また、プロセッサ５３は、ＲＡＩＤ Ｇｒｏｕｐ種別テーブル９０を参照し、取得したＲＡＩＤ Ｌｅｖｅｌについての信頼性評価値及び性能評価値を取得する。また、プロセッサ５３は、ドライブ種別テーブル９１を参照して、取得したドライブタイプのドライブについての性能評価値を取得する（ステップＳ７２）。

次いで、プロセッサ５３は、ＲＡＩＤ Ｇｒｏｕｐ種別テーブル９０を参照して、取得したＲＡＩＤ Ｌｅｖｅｌの信頼性評価値と、同等の信頼性評価値となるＲＡＩＤ Ｌｅｖｅｌ（同信頼性ＲＡＩＤ Ｌｅｖｅｌ）を取得する（ステップＳ７３）。

次いで、プロセッサ５３は、把握した余剰リソースによって構成可能な同信頼性ＲＡＩＤ ＬｅｖｅｌのＲＡＩＤ Ｇｒｏｕｐの組合せを算出する（ステップＳ７４）。

ここで、例えば、同等な信頼性評価となるＲＡＩＤ ＬｅｖｅｌがＲＡＩＤ５（２Ｄ＋１Ｐ）、ＲＡＩＤ５（３Ｄ＋１Ｐ）であり、余剰リソースが、ＳＳＤが８本、ＳＡＳが３本である場合には、算出される組合せは、例えば、以下に示す９通りとなる。
・ＳＳＤ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×１
・ＳＳＤ：ＲＡＩＤ５（３Ｄ＋１Ｐ）×１
・ＳＡＳ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×１
・ＳＳＤ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×２
・ＳＳＤ：ＲＡＩＤ５（３Ｄ＋１Ｐ）×２
・ＳＳＤ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×１、ＳＳＤ：ＲＡＩＤ５（３Ｄ＋１Ｐ）×１
・ＳＳＤ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×２、ＳＡＳ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×１
・ＳＳＤ：ＲＡＩＤ５（３Ｄ＋１Ｐ）×２、ＳＡＳ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×１
・ＳＳＤ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×１、ＳＳＤ：ＲＡＩＤ５（３Ｄ＋１Ｐ）×１、ＳＡＳ：ＲＡＩＤ５（２Ｄ＋１Ｐ）×１

次いで、プロセッサ５３は、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、同等以上の性能評価値が必要であるか否かを判定する（ステップＳ７５）。同等以上の性能評価値が必要であるか否かについては、リソース投入案算出処理での組合せ算出処理による算出対象の組合せに基づいて決定することができる。例えば、ステップＳ４３での組合せ算出処理であれば、同等以上の性能評価値が必要であると判定される。

この結果、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、同等以上の性能評価値が必要である場合（ステップＳ７５：ＹＥＳ）には、プロセッサ５３は、ステップＳ７４で算出した組合せから、同等未満の性能評価値となるＲＡＩＤ Ｇｒｏｕｐを含む組合せを除外し（ステップＳ７６）、処理をステップＳ７７に進める一方、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、同等以上の性能評価値が必要でない場合（ステップＳ７５：ＮＯ）には、処理をステップＳ７７に進める。

ステップＳ７７では、プロセッサ５３は、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、下位のＴｉｅｒに追加する物理ボリュームが必要であるか否かを判定する。下位のＴｉｅｒに追加する物理ボリュームが必要であるか否かについては、リソース投入案算出処理での組合せ算出処理による算出対象の組合せに基づいて決定することができる。

この結果、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、下位のＴｉｅｒに追加する物理ボリュームが必要である場合（ステップＳ７７：ＹＥＳ）には、プロセッサ５３は、現在の組合せ（ステップＳ７４で算出された組合せ、又はステップＳ７６が実行された場合には、ステップＳ７６の実行後の組合せ）の中から、下位のＴｉｅｒに追加できるＲＡＩＤ Ｇｒｏｕｐの組合せを抽出し（ステップＳ７８）、処理をステップＳ７９に進める一方、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、下位のＴｉｅｒに追加する物理ボリュームが必要でない場合（ステップＳ７７：ＮＯ）には、処理をステップＳ７９に進める。

ステップＳ７９では、プロセッサ５３は、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、上位のＴｉｅｒに追加する物理ボリュームが必要であるか否かを判定する。上位のＴｉｅｒに追加する物理ボリュームが必要であるか否かについては、リソース投入案算出処理での組合せ算出処理による算出対象の組合せに基づいて決定することができる。

この結果、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、上位のＴｉｅｒに追加する物理ボリュームが必要である場合（ステップＳ７９：ＹＥＳ）には、プロセッサ５３は、現在の組合せ（ステップＳ７４で算出された組合せ、又はステップＳ７６が実行された場合には、ステップＳ７６の実行後の組合せ）の中から、上位のＴｉｅｒに追加できるＲＡＩＤ Ｇｒｏｕｐの組合せを抽出し（ステップＳ８０）、処理をステップＳ８１に進める一方、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、上位のＴｉｅｒに追加する物理ボリュームが必要でない場合（ステップＳ７９：ＮＯ）には、処理をステップＳ８１に進める。

ステップＳ８１では、プロセッサ５３は、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、同一のＴｉｅｒに追加する物理ボリュームが必要であるか否かを判定する。同一のＴｉｅｒに追加する物理ボリュームが必要であるか否かについては、リソース投入案算出処理のステップにおける組合せ算出処理による算出対象の組合せに基づいて決定することができる。

この結果、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、同一のＴｉｅｒに追加する物理ボリュームが必要である場合（ステップＳ８１：ＹＥＳ）には、プロセッサ５３は、現在の組合せ（ステップＳ７４で算出された組合せ、又はステップＳ７６が実行された場合には、ステップＳ７６の実行後の組合せ）の中から、同一のＴｉｅｒに追加できるＲＡＩＤ Ｇｒｏｕｐの組合せを抽出し（ステップＳ８２）、抽出したＲＡＩＤ Ｇｒｏｕｐの組合せを組合せ算出処理に返して処理を終了させる一方、組合せとして算出するＲＡＩＤ Ｇｒｏｕｐの組合せに、同一のＴｉｅｒに追加する物理ボリュームが必要でない場合（ステップＳ８１：ＮＯ）には、抽出したＲＡＩＤ Ｇｒｏｕｐの組合せを組合せ算出処理に返して処理を終了させる。

図２６は、一実施形態に係るリソース投入案選択処理のフローチャートである。

リソース投入案選択処理は、プロセッサ５３がリソース投入案選択処理プログラム７２を実行することにより行われる。このリソース投入案選択処理は、図２３のリソース投入処理のステップＳ３６で実行される処理である。

プロセッサ５３は、ループＢの処理（ステップＳ９１，Ｓ９２）を実行する。ループＢでは、変数ｎの値を１から同時に発生する可能性のある障害の数となるまで１ずつ加算して、各変数ｎの値を用いてステップＳ９１，Ｓ９２の処理を実行する。

ループＢでは、まず、プロセッサ５３は、Ｅ（ｎ）を算出するために使用する値を設定する（ステップＳ９１）。ここで、Ｅ（ｎ）は、現在発生している障害（発生障害）と同時に発生するｎ番目の障害に対応するリソース投入案一覧テーブル９６である。ｎは、障害テーブル８９の発生障害に対応する行の同時に発生する障害８９ｄに登録されている順番をｉとし、ｉの確率をｋ（ｉ）、ｉの障害部位の数をｃ（ｉ）とした場合、ｎ＝ＣＥＩＬ（ｋ（１）×ｃ（１））＋ＣＥＩＬ（ｋ（２）×ｃ（２））＋・・・＋ＣＥＩＬ（ｋ（ｉ）×ｃ（ｉ））に対応する。ＣＥＩＬは、小数点以下を切り捨てる関数とする。現在発生している障害（発生障害）と同時に発生する障害の数Ｎは、障害テーブル８９の発生障害に対応する行の同時に発生する障害８９ｄに登録されている障害の数をＩとした場合、Ｎ＝ＣＥＩＬ（ｋ（１）×ｃ（１））＋ＣＥＩＬ（ｋ（２）×ｃ（２））＋・・・＋ＣＥＩＬ（ｋ（Ｉ）×ｃ（Ｉ））となる。

Ｅ（ｎ）を算出するために使用する値として、稼働率又は使用容量をそれに対応するしきい値［注意］に設定し、変動率［短期］を過去に計測した最大の変動率［短期］に設定し、猶予時間を、過去に計測した最大の変動率［短期］としきい値［注意］とに基づいて算出される値に設定する。

次いで、プロセッサ５３は、ステップＳ９１において設定した値を用いて、リソース投入案算出処理（図２４参照）を実行する（ステップＳ９２）。このステップＳ９２の処理によると、発生障害と同時に発生する可能性のある障害が発生した際のリソース投入案を含むリソース投入案一覧テーブル９６が作成される。

そして、変数ｎを同時に発生する障害の数として、ステップＳ９１及びステップＳ９２を行った場合には、プロセッサ５３は、ループＢを抜ける。

次いで、プロセッサ５３は、ループＣの処理（ステップＳ９３〜Ｓ９６）を実行する。ループＣでは各変数ｘの値を１からｘ＿ｍａｘまで１ずつ加算して、各変数ｘの値を用いて、ステップ９３〜Ｓ９６の処理を実行する。ここで、ｘ＿ｍａｘは、発生障害に対応するリソース投入案一覧テーブル９６の行の番号の最大値である。

ループＣでは、設定された変数ｘについて、プロセッサ５３は、Ｅ（０）［ｘ］で使用するドライブ４０１が使用されたと仮定する（ステップＳ９３）。ここで、Ｅ（０）は、発生障害に対応するリソース投入案一覧テーブル９６を示し、Ｅ（０）［ｘ］は、発生障害に対応するリソース投入案一覧テーブル９６におけるｘ番目の行を示す。

次いで、プロセッサ５３は、発生障害と当時に発生する可能性のあるすべての障害のリソース投入案の組合せ（Ｅ（１）［ａ］，Ｅ（２）［ｂ］，・・・の組合せ）を算出する（ステップＳ９４）。

例えば、発生障害と同時に発生する他の障害についてのリソース投入案として、Ｅ（１）［１］，Ｅ（１）［２］，Ｅ（２）［１］，Ｅ（２）［２］，Ｅ（３）［１］，Ｅ（３）［２］が存在し、Ｅ（２）に対応する障害とＥ（３）に対応する障害とが同時に発生しない場合には、ステップＳ９４では、以下の１６通りの組み合わせが算出される。なお、各リソース投入案の順番は、実行順番を示している。
・Ｅ（１）［１］，Ｅ（２）［１］
・Ｅ（１）［１］，Ｅ（２）［２］
・Ｅ（１）［１］，Ｅ（３）［１］
・Ｅ（１）［１］，Ｅ（３）［２］
・Ｅ（１）［２］，Ｅ（２）［１］
・Ｅ（１）［２］，Ｅ（２）［２］
・Ｅ（１）［２］，Ｅ（３）［１］
・Ｅ（１）［２］，Ｅ（３）［２］
・Ｅ（２）［１］，Ｅ（１）［１］
・Ｅ（２）［２］，Ｅ（１）［１］
・Ｅ（３）［１］，Ｅ（１）［１］
・Ｅ（３）［２］，Ｅ（１）［１］
・Ｅ（２）［１］，Ｅ（１）［２］
・Ｅ（２）［２］，Ｅ（１）［２］
・Ｅ（３）［１］，Ｅ（１）［２］
・Ｅ（３）［２］，Ｅ（１）［２］

次いで、プロセッサ５３は、算出された全ての組合せにおいて、使用可能なドライブを使用して解消可能な障害の数（Ｎ）を算出する（ステップＳ９５）。

次いで、プロセッサ５３は、算出されたＮのうちの最も大きな値をＥ（０）［ｘ］についてのＭとする（ステップＳ９６）。ここで、Ｍは、同時に発生する可能性のある障害の中で解消することのできる最大の数を意味している。このＭは、異常と同時に発生する可能性のある他の異常に対する対処可能状況の一例である。

ここで、例えば、ステップＳ９４において算出された組合せが以下の６通りであるとする。
・Ｅ（１）［１］，Ｅ（２）［１］，Ｅ（３）［１］
・Ｅ（１）［１］，Ｅ（３）［１］，Ｅ（２）［１］
・Ｅ（２）［１］，Ｅ（１）［１］，Ｅ（３）［１］
・Ｅ（２）［１］，Ｅ（３）［１］，Ｅ（１）［１］
・Ｅ（３）［１］，Ｅ（１）［１］，Ｅ（２）［１］
・Ｅ（３）［１］，Ｅ（２）［１］，Ｅ（１）［１］

この場合において、Ｅ（１）［１］では、ＳＳＤを８本使用し、Ｅ（２）［１］では、ＳＳＤを４本使用し、Ｅ（３）［１］では、ＳＳＤを４本使用するものとし、余剰リソースとして、ＳＳＤが８本あるものとする。

この場合には、ステップＳ９５において、・Ｅ（１）［１］，Ｅ（２）［１］，Ｅ（３）［１］については、Ｎ＝１、・Ｅ（１）［１］，Ｅ（３）［１］，Ｅ（２）［１］については、Ｎ＝１、
・Ｅ（２）［１］，Ｅ（１）［１］，Ｅ（３）［１］については、Ｎ＝１、・Ｅ（２）［１］，Ｅ（３）［１］，Ｅ（１）［１］については、Ｎ＝２、・Ｅ（３）［１］，Ｅ（１）［１］，Ｅ（２）［１］については、Ｎ＝１、・Ｅ（３）［１］，Ｅ（２）［１］，Ｅ（１）［１］については、Ｎ＝２と算出され、ステップＳ９６においては、Ｅ（０）［ｘ］のＭが２と算出される。

ループＣにおいて、変数ｘをｘ＿ｍａｘとして、ステップＳ９３〜Ｓ９６の処理を終了した場合には、プロセッサ５３は、ループＣを抜ける。

次いで、プロセッサ５３は、Ｅ（０）［１］〜［ｘ＿ｍａｘ］の中で、最大のＭとなっているリソース投入案Ｅ（０）［ｘ］を実行するリソース投入案として抽出（決定）し（ステップＳ９７）、処理を終了する。

このリソース投入案選択処理によると、発生障害を解消するために投入するリソース投入案として、発生障害と同時に発生する可能性のあるより多くの障害に対処できるリソースを残すことのできるリソース投入案に適切に決定することができる。これにより、発生障害を解消するためにリソースを投入した際において、新たに発生する障害に対して対処できる可能性を向上することができる。

図２７は、一実施形態に係るリソース割当監視処理のフローチャートである。

リソース割当監視処理は、プロセッサ５３がリソース割当監視処理プログラム６４を実行することにより行われる。このリソース割当監視処理は、例えば、ストレージ装置３０の電源がＯＮとなった後に実行が開始され、継続して実行される。

まず、プロセッサ５３は、リソース投入履歴テーブル９３を参照し、回収されていないリソースがあるか否かを判定する（ステップＳ１０１）。ここで、リソースが回収されているか否かについては、リソース投入テーブル履歴テーブル９３に、回収時間９３ｃに値が設定されていない行があるか否かにより判定することができる。

この結果、回収されていないリソースがないと判定された場合（ステップＳ１０１：ＮＯ）には、プロセッサ５３は、処理をステップＳ１０３に進める。

一方、回収されていないリソースがあると判定された場合（ステップＳ１０１：ＹＥＳ）には、プロセッサ５３は、回収されていないリソースは、ドライブ障害に対するリソースであるか否かを判定する（ステップＳ１０２）。

この結果、ドライブ障害に対するリソースでない場合（ステップＳ１０２：ＮＯ）には、プロセッサ５３は、対応するリソースを回収するためのリソース回収案（ステップＳ１０３：図２８参照）を実行させ、処理をステップＳ１０５に進める。

一方、ドライブ障害に対するリソースである場合（ステップＳ１０２：ＹＥＳ）には、プロセッサ５３は、障害部位のドライブがＮＯＲＭＡＬになっている場合、すなわち、ドライブ管理テーブル８４の障害部位のドライブに対応する行の状態８４ｅがＮＯＲＭＡＬの場合には、リソース投入履歴テーブル９３の障害部位に対応する行の回収時間９３ｃに現在の時刻を設定し、行の状態８４ｅがＮＯＲＭＡＬでない場合には、何もせず（ステップＳ１０４）、処理をステップＳ１０５に進める。

ステップＳ１０５では、プロセッサ５３は、次監視周期まで処理を停止し、その後、処理をステップＳ１０１に進める。

図２８は、一実施形態に係るリソース回収処理のフローチャートである。

リソース回収処理は、プロセッサ５３がリソース回収処理プログラム６９を実行することにより行われる。このリソース回収処理は、図２７のリソース割当監視処理のステップＳ１０３で実行される処理である。

まず、プロセッサ５３は、ループＤの処理（ステップＳ１１１〜Ｓ１１３）を実行する。ループＤでは、変数ｖの値を１から、リソースを回収する対象のリソース投入案において投入したボリュームの数となるまで１ずつ加算して、各変数ｖの値を用いてステップＳ１１１〜Ｓ１１３の処理を実行する。

ループＤでは、まず、プロセッサ５３は、リソースを回収してもプールの使用率がしきい値［注意］未満（（プールの物理容量×使用率）÷（物理容量−ｖ（ｖ番目の物理ボリューム）の容量）＜しきい値［注意］）であり、且つリソースを回収してもプールのＴｉｅｒの稼動率がしきい値［注意］未満（（ｖの所属するＴｉｅｒのドライブ稼動率の平均値）×ｖの所属するＴｉｅｒのドライブ数÷（ｖの所属するＴｉｅｒのドライブ数−ｖのドライブ数）＜しきい値［注意］）であるか否かを判定する（ステップＳ１１１）。

この結果、リソースを回収してもプールの使用率がしきい値［注意］未満であり、且つリソースを回収してもプールのＴｉｅｒの稼動率がしきい値［注意］未満である場合（ステップＳ１１１：ＹＥＳ）には、プロセッサ５３は、ループＥの処理（ステップＳ１１２，Ｓ１１３）を実行する一方、リソースを回収してもプールの使用率がしきい値［注意］未満であり、且つリソースを回収してもプールのＴｉｅｒの稼動率がしきい値［注意］未満でない場合（ステップＳ１１１：ＮＯ）には、プロセッサ５３は、後述するループＥの処理を抜ける。

ループＥでは、変数ｎの値を１から、同時に発生する障害の数となるまで１ずつ加算して、各変数ｎの値を用いてステップＳ１１２，Ｓ１１３の処理を実行する。

ループＥでは、プロセッサ５３は、Ｅ（ｖ，ｎ）を算出するために使用する値を設定する（ステップＳ１１２）。ここで、Ｅ（ｖ，ｎ）は、ｖに対応する物理ボリュームが回収できたとした場合に、現在発生している障害（発生障害）と同時に発生するｎ番目の障害に対応するリソース投入案一覧テーブル９６である。

Ｅ（ｖ，ｎ）を算出するために使用する値として、稼働率又は使用容量をそれに対応するしきい値［注意］に設定し、変動率［短期］を過去に計測した最大の変動率［短期］に設定し、猶予時間を、過去に計測した最大の変動率［短期］としきい値［注意］とに基づいて算出される値に設定する。

次いで、プロセッサ５３は、ステップＳ１１２において設定した値を用いて、リソース投入案算出処理（図２４参照）を実行する（ステップＳ１１３）。このステップＳ１１３の処理によると、ｖに対応する物理ボリュームを回収したとした場合に、発生障害と同時に発生する可能性のある障害が発生した際のリソース投入案を含むリソース投入案一覧テーブル９６が作成される。

ループＥにおいて、変数ｎを同時に発生する障害の数として、ステップＳ１１２，Ｓ１１３の処理を終了した場合には、プロセッサ５３は、ループＥの処理を抜ける。

また、ループＤにおいて、変数ｖを投入したボリュームの数として、ステップＳ１１１〜Ｓ１１３の処理を終了した場合には、プロセッサ５３は、ループＤの処理を抜ける。

ループＤの処理を抜けると、プロセッサ５３は、ループＦの処理（ステップＳ１１４〜Ｓ１１６）を実行する。ループＦでは、変数ｖの値を１から、リソースを回収する対象のリソース投入案において投入したボリュームの数となるまで１ずつ加算して、各変数ｖの値を用いてステップＳ１１４〜Ｓ１１６の処理を実行する。

ループＦでは、プロセッサ５３は、発生障害と当時に発生する可能性のあるすべての障害のリソース投入案の組合せ（Ｅ（ｖ，１）［ａ］，Ｅ（ｖ，２）［ｂ］，・・・の組合せ）を算出する（ステップＳ１１４）。ここで、Ｅ（ｖ，ｎ）［ａ］は、ｖに対応する物理ボリュームを回収したとした場合における発生障害に対応するリソース投入案一覧テーブル９６におけるａ番目の行を示す。

次いで、プロセッサ５３は、算出された全ての組合せにおいて、使用可能なドライブを使用して解消可能な障害の数（Ｎ）を算出する（ステップＳ１１５）。

次いで、プロセッサ５３は、算出されたＮのうちの最も大きな値を、ｖに対応する物理ボリュームを回収した際におけるＭとする（ステップＳ１１６）。ここで、Ｍは、同時に発生する可能性のある障害の中で解消することのできる最大の数を意味している。このＭは、同時に発生する可能性のある障害についての対処可能状況の一例である。

ループＦにおいて、変数ｖを投入したボリュームの数として、ステップＳ１１４〜Ｓ１１６の処理を終了した場合には、プロセッサ５３は、ループＦの処理を抜ける。

次いで、プロセッサ５３は、１〜ｖ＿ｍａｘ（投入したボリュームの数の最大値）の中で最大のＭとなるｖを選択し（ステップＳ１１７）、プール管理テーブル８１、ＲＡＩＤ Ｇｒｏｕｐ管理テーブル８２、ボリューム管理テーブル８３、及びドライブ管理テーブル８４のうちの関係するテーブルについて、選択したｖに対応する物理ボリュームを回収した場合の状態に更新し（ステップＳ１１８）、選択したｖに対応する物理ボリュームを回収し（ステップＳ１１９）、リソース投入履歴テーブル９３のリソースを回収したリソース投入案に対応する行の回収時間９３ｃに現在の時刻を設定し（ステップＳ１２０）、処理を終了する。

このリソース回収処理によると、リソースを回収した際に解消することのできる障害の数が多いリソースを優先して回収することができる。

図２９は、一実施形態に係るリソース管理処理のフローチャートである。

リソース管理処理は、プロセッサ５３がリソース管理処理プログラム６６を実行することにより行われる。このリソース管理処理は、例えば、ストレージ装置３０の電源がＯＮとなった後に実行が開始され、継続して実行される。

まず、プロセッサ５３は、ループＧの処理（ステップＳ１２１，Ｓ１２２）を実行する。ループＧでは、変数ｎの値を１から同時に発生する可能性のある障害の最大数（ｎ＿ｍａｘ）となるまで１ずつ加算して、各変数ｎの値を用いてステップＳ１２１，Ｓ１２２の処理を実行する。

ループＧでは、まず、プロセッサ５３は、Ｅ（ｎ）を算出するために使用する値を設定する（ステップＳ１２１）。ここで、Ｅ（ｎ）は、各障害に対応するリソース投入案一覧テーブル９６である。

Ｅ（ｎ）を算出するために使用する値として、稼働率又は使用容量をそれに対応するしきい値［注意］に設定し、変動率［短期］を過去に計測した最大の変動率［短期］に設定し、猶予時間を、過去に計測した最大の変動率［短期］としきい値［注意］とに基づいて算出される値に設定する。

次いで、プロセッサ５３は、ステップＳ１２１において設定した値を用いて、リソース投入案算出処理（図２４参照）を実行する（ステップＳ１２２）。このステップＳ１２２の処理によると、発生する可能性のある障害についてのリソース投入案一覧テーブル９６が作成される。

そして、変数ｎを発生する可能性のある障害の最大数として、ステップＳ１２１及びステップＳ１２２を行った場合には、プロセッサ５３は、ループＧの処理を抜ける。

次いで、プロセッサ５３は、発生する可能性のあるすべての障害のリソース投入案の組合せ（Ｅ（１）［ａ］，Ｅ（２）［ｂ］，・・・の組合せ）を算出する（ステップＳ１２３）。

次いで、プロセッサ５３は、算出された全ての組合せにおいて、使用可能なドライブを使用して解消可能な障害の数（Ｎ）を算出する（ステップＳ１２４）。次いで、算出されたＮのうちの最も大きな値を、発生する可能性のある障害の中で解消することのできる最大の数であるＭとする（ステップＳ１２５）。このＭは、同時に発生する可能性のある異常に対する対処可能状況の一例である。

次いで、プロセッサ５３は、Ｍがｎ＿ｍａｘと同じであるか否かを判定する（ステップＳ１２６）。

この結果、Ｍがｎ＿ｍａｘと同じでない場合（ステップＳ１２６：ＮＯ）には、同時に発生する可能性のある障害の全てに対応するためには、余剰リソースが不足していることを意味しているので、プロセッサ５３は、Ｍがｎ＿ｍａｘとなる組合せを実現する際に不足するドライブ数のうちの最も少ない数を算出し（ステップＳ１２７）、プロセッサ５３、例えば、出力デバイス５６に、不足するドライブ数及び種類のドライブの増設を提案するメッセージを表示させ（ステップＳ１２８）、処理をステップＳ１３１に進める。これにより、同時に発生する障害の全てに対処するために必要なリソースの増設を適切に提案することができる。

一方、Ｍがｎ＿ｍａｘと同じである場合（ステップＳ１２６：ＹＥＳ）には、同時に発生する可能性のある障害の全てに対応できることを意味しているので、プロセッサ５３は、Ｍがｎ＿ｍａｘとなる組合せを実現する際に、最も少ないドライブ数となる組合せを選択し（ステップＳ１２９）、例えば、出力デバイス５６に、選択した組合せで使用しないドライブがある場合には、そのドライブの種類及び数の減設を提案するメッセージを表示させ（ステップＳ１３０）、処理をステップＳ１３１に進める。これにより、同時に発生する障害の全てに対処するために不必要となるリソースの減設を適切に提案することができる。

ステップＳ１３１では、プロセッサ５３は、次監視周期まで処理を停止し、その後、処理をループＧの処理に進める。

以上説明したように、リソース管理処理によると、同時に発生する障害に対応するための余剰リソースを適切な数に調整させるように提案することができる。したがって、必要最低限の余剰リソースで、適切に異常に対処することができる。

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

例えば、上記実施形態では、ページ移動性能一覧テーブル９４には、低速に対応するレコードのみを格納するようにしていたが、本発明は、これに限られず、例えば、複数の速度（中速、高速等）についての行を格納するようにしてもよい。また、この場合においては、ページ移動性能影響一覧テーブル９５の行に、各速度に対応する負荷のフィールドを設け、各速度に対応する負荷の値を格納するようにすればよい。そして、ページ移動する際における速度に応じた負荷については、このテーブルを用いて特定するようにすればよい。

また、上記実施形態において、リソース管理装置の一例を、ストレージ装置３０内のストレージコントローラ５０としていたが、本発明はこれに限られず、例えば、ストレージ装置３０とは別のサーバに、ストレージコントローラ５０におけるリソースの管理に必要な機能を実行させるようにしてもよい。

１…計算機システム、１０…サーバ、２０…ＳＡＮ、３０…ストレージ装置、４０…ディスクユニット、５０…ストレージコントローラ、５３…プロセッサ、５４…メモリ、６１…監視プログラム、６５…リソース管理プログラム、６７…リソース割当制御プログラム、８０…テーブル群

Claims (12)

1. 複数の種類の余剰リソースを含む複数のリソースを備えるストレージ装置における異常の対処に用いる、前記余剰リソースの投入案を決定し、決定した投入案に従って前記余剰リソースの割当を制御するリソース管理装置であって、
   前記リソース管理装置は、プロセッサ部を備え、
   前記プロセッサ部は、
   前記ストレージ装置における前記リソースに関わる異常を検出し、
   前記異常を検出した場合に、前記ストレージ装置における前記リソースの運用情報に基づいて、異常を対処することのできる前記余剰リソースの投入案を１以上算出し、
   前記投入案が複数ある場合に、それぞれの前記投入案を実行する際に残存する余剰リソースによる、前記異常と同時に発生する可能性のある他の異常に対する対処可能状況に基づいて、前記異常の対処に用いる投入案を決定し、
   前記プロセッサ部は、
   前記投入案が複数ある場合に、前記残存する余剰リソースによる、対処可能な前記他の異常の数が多い投入案を、対処に用いる投入案として決定する
   リソース管理装置。
2. 前記リソースの運用情報は、前記ストレージ装置における前記リソースの構成情報と、前記リソースの稼動情報とを含む
   請求項１に記載のリソース管理装置。
3. 前記プロセッサ部は、
   前記リソースの稼動情報に基づいて、前記リソースに関わる状態が、第１段階の異常状態からさらに深刻な第２段階の異常状態になるまでの猶予時間を特定し、
   前記猶予時間未満で実行可能な投入案を算出する
   請求項２に記載のリソース管理装置。
4. 前記リソースは、ストレージデバイスであり、
   前記ストレージ装置は、１以上のストレージデバイスの記憶領域に基づく記憶領域により構成される物理ボリュームと、１以上の前記物理ボリュームの記憶領域に基づく容量プールと、前記容量プールの記憶領域が割り当てられる仮想ボリュームとを有し、
   前記リソースに関わる異常は、前記容量プールの記憶領域の容量不足を含み、
   前記プロセッサ部は、
   前記容量プールの記憶領域の容量不足を検出した場合に、異常に対処することのできる前記余剰リソースの投入案として、前記容量プールの容量不足に対応する物理ボリュームを構成するリソースに対して、同等以上の信頼性と、同等以上の性能評価とを有する余剰リソースにより構成される物理ボリュームを追加する投入案を算出する
   請求項１から請求項３のいずれか一項に記載のリソース管理装置。
5. 前記プロセッサ部は、
   前記容量プールの記憶領域の容量不足を検出した場合に、異常の対処に用いる前記余剰リソースの投入案として、前記容量プールの容量不足に対応する物理ボリュームを構成するリソースに対して、同等以上の信頼性を有する余剰リソースにより構成される物理ボリュームを追加する投入案を算出する
   請求項４に記載のリソース管理装置。
6. 前記プロセッサ部は、
   前記異常の対処に用いる投入案として、前記容量プールの容量不足に対応する物理ボリュームを構成するリソースに対して、同等以上の信頼性を有する余剰リソースにより構成される物理ボリュームを追加する投入案に決定した場合に、前記容量不足に対応する前記物理ボリュームの記憶領域が割り当てられている仮想ボリュームのページを、追加された物理ボリュームの記憶領域に再配置させる
   請求項５に記載のリソース管理装置。
7. 前記リソースは、ストレージデバイスであり、
   前記ストレージ装置は、１以上のストレージデバイスの記憶領域に基づく記憶領域により構成される物理ボリュームと、１以上の前記物理ボリュームの記憶領域に基づく容量プールと、前記容量プールの記憶領域が割り当てられる仮想ボリュームとを有し、
   前記リソースに関わる異常は、前記仮想ボリュームのアクセス性能の低下を含み、
   前記プロセッサ部は、前記仮想ボリュームのアクセス性能の低下を検出した場合に、異常を対処することのできる前記余剰リソースの投入案として、前記容量プールの容量不足に対応する物理ボリュームを構成するリソースに対して、同等以上の信頼性と、同等以上の性能評価とを有する余剰リソースにより構成される物理ボリュームを追加する投入案を算出する
   請求項１から請求項３のいずれか１項に記載のリソース管理装置。
8. 前記プロセッサ部は、
   前記ストレージ装置における前記リソースに関わる異常が解消されたか否かを判定し、
   前記異常が解消された場合において、前記異常に対処するために実行された投入案に係る複数の余剰リソースについて、各余剰リソースを回収することによる、前記異常と同時に発生する可能性がある他の異常に対する対処可能状況に基づいて回収する
   請求項１から請求項７のいずれか１項に記載のリソース管理装置。
9. 前記プロセッサ部は、
   前記ストレージ装置において発生する可能性のある異常が発生した場合における異常に対処することのできる１以上の前記余剰リソースの投入案と、前記異常と同時に発生する可能性がある他の異常に対処することのできる１以上の前記余剰リソースの投入案と、前記余剰リソースとに基づいて、前記異常及び前記他の異常の全てに対処可能であるか否かを判定し、
   前記異常及び前記他の異常の全てに対処可能である場合には、前記異常及び前記他の異常の全てに対処した場合において必要最低限のリソースの種類及び数を特定し、
   前記余剰リソースの種類及び数と、前記必要最低限のリソースの種類及び数とに基づいて、不要なリソースの種類及び数のリソース減設するように提案するメッセージを表示させる
   請求項１から請求項８のいずれか一項に記載のリソース管理装置。
10. 前記プロセッサ部は、
    前記異常及び前記他の異常の全てに対処可能でない場合には、前記異常及び前記他の異常の全てに対処した場合において必要最低限のリソースの種類及び数を特定し、
    前記余剰リソースの種類及び数と、前記必要最低限のリソースの種類及び数とに基づいて、不足しているリソースの種類及び数のリソースを増設するように提案するメッセージを表示させる
    請求項９に記載のリソース管理装置。
11. 複数の種類の余剰リソースを含む複数のリソースを備えるストレージ装置における異常の対処に用いる、前記余剰リソースの投入案を決定し、決定した投入案に従って前記余剰リソースの割当を制御するリソース管理装置によるリソース管理方法であって、
    前記リソース管理装置は、
    前記ストレージ装置における前記リソースに関わる異常を検出し、
    前記異常を検出した場合に、前記ストレージ装置における前記リソースの運用情報に基づいて、異常を対処することのできる前記余剰リソースの投入案を１以上算出し、
    前記投入案が複数ある場合に、それぞれの前記投入案を実行する際に残存する余剰リソースによる、前記異常と同時に発生する可能性のある他の異常に対する対処可能状況に基づいて、前記異常の対処に用いる投入案を決定し、
    前記投入案が複数ある場合に、前記残存する余剰リソースによる、対処可能な前記他の異常の数が多い投入案を、対処に用いる投入案として決定する
    リソース管理方法。
12. 複数の種類の余剰リソースを含む複数のリソースを備えるストレージ装置における異常の対処に用いる、前記余剰リソースの投入案を決定し、決定した投入案に従って前記余剰リソースの割当を制御するリソース管理装置を構成するコンピュータに実行させるためのリソース管理プログラムであって、
    前記コンピュータを、
    前記ストレージ装置における前記リソースに関わる異常を検出する手段と、
    前記異常を検出した場合に、前記ストレージ装置における前記リソースの運用情報に基づいて、異常を対処することのできる前記余剰リソースの投入案を１以上算出する手段と、
    前記投入案が複数ある場合に、それぞれの前記投入案を実行する際に残存する余剰リソースによる、前記異常と同時に発生する可能性のある他の異常に対する対処可能状況に基づいて、前記異常の対処に用いる投入案を決定する手段と、して機能させ、
    前記投入案を決定する手段は、前記投入案が複数ある場合に、前記残存する余剰リソースによる、対処可能な前記他の異常の数が多い投入案を、対処に用いる投入案として決定するリソース管理プログラム。