JP7244482B2 - ストレージ管理システム、管理方法 - Google Patents

Description

本発明は、ストレージ管理システム、および管理方法に関する。

複数の物理計算機から構成され、各々の物理計算機ではコンピューティングサービスとストレージサービスとの両方が稼働するハイパーコンバージドインフラストラクチャ（Hyper Converged Infrastructure：ＨＣＩ）がある。ＨＣＩの構成において、コンテナコンピューティングサービスは、物理計算機で稼働するコンテナ基盤上のコンテナとして稼働する場合、物理計算機で稼働するハイパーバイザ上の仮想計算機として稼働する場合がある。ここで、コンピューティングサービスを行うコンテナ、仮想計算機をアプリケーションインスタンスと呼ぶ。

ＨＣＩの構成において、ストレージサービスは、物理計算機上で稼働するホストＯＳやハイパーバイザ上のプロセスとして稼働する場合、物理計算機で稼働するコンテナ基盤上のコンテナとして稼働する場合、物理計算機で稼働するハイパーバイザ上の仮想計算機として稼働する場合がある。ここで、ストレージサービスを行うプロセス、コンテナもしくは仮想計算機をストレージサービスインスタンスと呼ぶ。ストレージサービスインスタンスは、アプリケーションインスタンスに対してボリュームを提供する。ストレージサービスにおけるデータ保護として、たとえば特許文献１に記載の方法が知られている。

米国特許出願公開第２０２０／００７３５５２号明細書

特許文献１に記載されている発明では、過剰なデータ保護となる可能性がある。

本発明の第１の態様によるストレージ管理システムは、プロセッサを有し、複数のストレージを管理するストレージ管理システムであって、前記ストレージは、複数の種類のコンポーネントを有して、前記複数のコンポーネントを組み合わせて、格納するデータの冗長化を行い、前記コンポーネント自身に設定されている冗長度を示したコンポーネント管理情報を有し、前記プロセッサは、前記コンポーネント管理情報と、前記ストレージに保存するデータに対するデータ保護の要求と、に基づき、前記ストレージにおいてデータを格納する前記コンポーネントの組み合わせを決定し、前記データ保護の要求には、少なくともデータの冗長度の要求が含まれ、前記プロセッサは、前記コンポーネント管理情報に記されるコンポーネント自身の冗長度と、前記複数のコンポーネントを組み合わせて設定する冗長度と、の合計が、前記データ保護の要求に含まれるデータの冗長度を満たすように前記コンポーネントの組み合わせを決定する。
本発明の第２の態様による管理方法は、プロセッサを有し、複数のストレージを管理するストレージ管理システムが実行する管理方法であって、前記ストレージは、複数の種類のコンポーネントを有して、前記複数のコンポーネントを組み合わせて、格納するデータが冗長化され、前記コンポーネント自身に設定されている冗長度を示したコンポーネント管理情報を有し、前記コンポーネント管理情報と、前記ストレージに保存するデータに対するデータ保護の要求と、に基づき、前記ストレージにおいてデータを格納する前記コンポーネントの組み合わせを決定する決定処理を含み、前記データ保護の要求には、少なくともデータの冗長度の要求が含まれ、前記決定処理には、前記コンポーネント管理情報に記されるコンポーネント自身の冗長度と、前記複数のコンポーネントを組み合わせて設定する冗長度と、の合計が、前記データ保護の要求に含まれるデータの冗長度を満たすように前記コンポーネントの組み合わせを決定することを含む。

本発明によれば、指定されるデータ保護の要求に基づき、適切にデータ保護を実行できる。

計算機システムの構成図 分離型計算機クラスタの構成図 クラスタ管理用計算機およびノードのハードウェア構成図 ノードのメモリに格納される情報を示す図 クラスタ管理用計算機のメモリに格納される情報を示す図 ノード管理テーブルの一例を示す図 バックエンドデバイス管理テーブルの一例を示す図 クラスタ外データ保護先管理テーブルの一例を示す図 ストレージクラス管理テーブルの一例を示す図 冗長化関係性テーブルの一例を示す図 ボリューム管理テーブルの一例を示す図 ストレージクラス設定プログラムが実行するストレージクラス設定処理を示すフローチャート 図１２におけるステップＳ１２３０の処理を示すフローチャート 稼働率計算処理を示すフローチャート ボリューム作成プログラムが実行するボリューム作成処理を示すフローチャート データ冗長度維持回復プログラムが実行するデータ冗長度維持回復処理を示すフローチャート 冗長化処理プログラムが実行する冗長化処理を示すフローチャート 変形例１におけるストレージクラス設定処理を示すフローチャート

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

以下の説明では、「ＡＡＡテーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ＡＡＡテーブル」を「ＡＡＡ情報」と呼ぶことができる。また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）である。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明では、「プログラム」を動作の主体として処理を説明する場合があるが、プログラムは、プロセッサ（たとえばＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（たとえばメモリ）および／または通信インタフェース装置（たとえばポート）を用いながら行うため、処理の主体がプロセッサとされてもよい。プログラムを動作の主体として説明された処理は、プロセッサを含む装置が行う処理としてもよい。また、プロセッサが行う処理の一部または全部を行うハードウェア回路を含んでもよい。コンピュータプログラムは、プログラムソースから装置にインストールされてもよい。プログラムソースは、たとえば、プログラム配布サーバ、または、計算機が読み取り可能な記憶メディアであってもよい。

また、以下の説明では、「コンテナ」を管理対象として説明する場合があるが、コンテナの代わりに、物理計算機のハードウェアをエミュレートする仮想化方式である「仮想計算機（ＶＭ）」や物理計算機そのものである「ベアメタル」が管理対象であってもよい。

―第１の実施の形態―
以下、図１～図１７を参照して、計算機システムの第１の実施の形態を説明する。

図１は、計算機システム１００の構成図である。計算機システム１００は、第１プライベートクラウド１０２－１と、第２プライベートクラウド１０２－２と、第１パブリッククラウド１０３－１と、第２パブリッククラウド１０３－２と、を含む。第１パブリッククラウド１０３－１は、第１サイト１０４－１および第２サイト１０４－２を含む。第１サイト１０４－１は、第１アベイラビリティゾーン１０５－１と第２アベイラビリティゾーン１０５－２を含む。図１では図示の都合によりいくつかのサイトおよびアベイラビリティゾーン（以下では「ＡＺ」とも記載する）の記載を省略している。

第１プライベートクラウド１０２－１には、分離型第１計算機クラスタ１１１－１および第１ストレージシステム１２０－１が含まれる。第２プライベートクラウド１０２－２には、一体型第１計算機クラスタ１１２－１が含まれる。第１パブリッククラウド１０３－１における第１アベイラビリティゾーン１０５－１には、分離型第２計算機クラスタ１１１－２および第２ストレージシステム１２０－２が含まれる。第１パブリッククラウド１０３－１における第２アベイラビリティゾーン１０５－２には、一体型第２計算機クラスタ１１２－２が含まれる。第１パブリッククラウド１０３－１における第２サイト１０４－２には、一体型第３計算機クラスタ１１２－３が含まれる。第２パブリッククラウド１０３－２には、一体型第４計算機クラスタ１１２－４が含まれる。

以下では、分離型第１計算機クラスタ１１１－１と分離型第２計算機クラスタ１１１－２とをあわせて分離型計算機クラスタ１１１と呼ぶ。第１ストレージシステム１２０－１と第２ストレージシステム１２０－２とをあわせてストレージシステム１２０と呼ぶ。一体型第１計算機クラスタ１１２－１と、一体型第２計算機クラスタ１１２－２と、一体型第３計算機クラスタ１１２－３と、一体型第４計算機クラスタ１１２－４と、をあわせて一体型計算機クラスタ１１２と呼ぶ。

図２は、分離型計算機クラスタ１１１の構成図である。分離型計算機クラスタ１１１は、１または複数のノード２０１と、ネットワークスイッチ２０２と、クラスタ管理用計算機２０３と、管理用端末２０４とを含む。ノード２０１のそれぞれは、１または複数のアプリケーションコンテナ２１０と、ストレージサービスコンテナ２１１と、コンテナ管理基盤２１２とを含む。

図２では、クラスタ管理用計算機２０３とノード２０１とが別に構成されている例を示しているが、クラスタ管理用計算機２０３とノード２０１とを一つのベアメタル、すなわち物理計算機を用いて構成してもよい。また、ノード２０１およびクラスタ管理用計算機２０３は仮想計算機の形態であってもよく、コンテナ仮想化技術により構成されたコンテナの形態であってもよい。また、クラスタ管理用計算機２０３は必ずしも独立した装置である必要はなく、その機能をノード２０１のいずれかに内包してもよい。

ストレージサービスコンテナ２１１は、アプリケーションコンテナ２１０に対してボリュームサービスを提供する、ストレージサービスインスタンスの一例である。なお、図２のストレージサービスコンテナ２１１は、独立したＯＳ空間を模擬するコンテナ基盤上で動作する単一のコンテナで構成されているが、物理計算機のハードウェアをエミュレートするハイパーバイザ上で動作する仮想計算機の形態であってもよいし、ベアメタルのハイパーバイザやホストＯＳ上で動作するストレージサービスの形態であってもよい。また複数のコンテナや複数の仮想計算機でストレージサービスを提供する形態であってもよい。

アプリケーションコンテナ２１０は、ハイパーコンバージドインフラの利用者が利用するコンテナであり、アプリケーションサービスインスタンスの一例である。アプリケーションコンテナ２１０は、仮想計算機の形態であってもよいし、ベアメタルのハイパーバイザやホストＯＳ上で動作するアプリケーションの形態であってもよい。コンテナ管理基盤２１２はアプリケーションコンテナ２１０とストレージサービスコンテナ２１１を管理する。ストレージサービスとアプリケーションの動作形態に応じて、コンテナ管理基盤２１２は仮想計算機管理基盤の形態やベアメタル管理基盤の形態であってもよい。

計算機システム１００におけるデータ保護処理は、ユーザが管理用端末２０４を用いてストレージクラスの要件を入力することから始まる。ストレージクラスの要件とは、ストレージに保存するデータに対するデータ保護の要求である。データ保護の要求には、障害の種類と冗長度との組合せ、可用性の確率、およびコストが含まれる。ただしそれぞれのデータ保護の要求には、これら３つのうち少なくとも１つが含まれていればよい。なお以下では、障害の種類と冗長度との組合せを「各コンポーネント観点」と呼ぶことがあり、可用性の確率を「全システム観点」と呼ぶこともある。

計算機システム１００は、要件が入力されるとその要件に合致するデータ保護先の候補を算出し、ストレージクラス管理番号とともに記憶する。次にユーザが、ストレージクラス管理番号と必要なボリュームのサイズとを指定すると、計算機システム１００はボリュームを作成する。作成されたボリュームには、ユーザが指定するデータやユーザがしてするアプリケーションコンテナ２１０が生成するデータが格納される。

図３は、クラスタ管理用計算機２０３およびノード２０１のハードウェア構成図である。以下では図３を参照してノード２０１の構成を説明するが、以下に説明する範囲ではクラスタ管理用計算機２０３のハードウェア構成も同一である。

ノード２０１は、たとえば、ＰＣやサーバ等の計算機によって構成され、プロセッサ部の一例としてのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１、メモリ３０２、ＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）３０３、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｆｅｒｆａｃｅ Ｃａｒｄ）３０４、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）３０５、ＶＧＡ（Ｖｉｄｅｏ Ｇｒａｐｈｉｃｓ Ａｒｒａｙ）３０６、およびストレージデバイスを含む。これら構成要素は、内部バスや外部バスで接続されている。ストレージデバイスにはたとえば、ＮＶＭｅ（Ｎｏｎ－Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ ｅｘｐｒｅｓｓ）ドライブ３１０、ＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ）ドライブ３１１、ＳＡＴＡ（Ｓｅｒｉａｌ ＡＴＡ）ドライブ３１２等である。

ノード２０１は、ストレージシステム１２０とは、ＮＩＣ３０４やＨＢＡ３０３を介して接続する。また、ＮｖＭｅドライブ３１０などのストレージデバイスは、不図示のＲＡＩＤカードを経由してＣＰＵ３０１などと接続されてもよい。

図４は、ノード２０１のメモリ３０２に格納される情報を示す図である。ノード２０１のメモリ３０２は、コンテナ管理基盤用メモリ領域４１０と、ストレージサービスコンテナ用メモリ領域４２０と、アプリケーションコンテナ用メモリ領域４３０とを含む。ストレージサービスコンテナ用メモリ領域４２０には、ボリューム管理テーブル４２１と、ストレージサービス処理プログラム４２２と、冗長化処理プログラム４２３と、冗長度回復処理プログラム４２４と、が格納される。アプリケーションコンテナ用メモリ領域４３０には、１以上のアプリケーションプログラム４３１が格納される。

ボリューム管理テーブル４２１には、ボリュームごとのデータ保護先の情報が格納される。ストレージサービス処理プログラム４２２は、ハイパーコンバージドインフラストラクチャのサービスを実現するための公知の処理を行うプログラムである。ストレージサービス処理プログラム４２２は、必要に応じて冗長化処理プログラム４２３に動作指令を出力する。冗長化処理プログラム４２３は、冗長化処理を実行するプログラムである。冗長化処理プログラム４２３の動作は、後に図１７を参照して詳述する。冗長度回復処理プログラム４２４は、データ冗長度維持回復プログラム５１２から呼び出され、冗長度を回復させるために指定されたデータ保護先へデータの書き込みを行う。

図５は、クラスタ管理用計算機２０３のメモリ３０２に格納される情報を示す図である。ノード２０１のメモリ３０２には、ノード管理テーブル５０１と、バックエンドデバイス管理テーブル５０２と、クラスタ外データ保護先管理テーブル５０３と、ストレージクラス管理テーブル５０４と、冗長化関係性テーブル５０５と、ストレージクラス設定プログラム５１０と、ボリューム作成プログラム５１１と、データ冗長度維持回復プログラム５１２と、が格納される。

ノード管理テーブル５０１には、特定のクラスタ内の各ノードの情報が記載される。ただしクラスタ管理用計算機２０３にノード管理テーブル５０１が格納される代わりに、各ノードのノード管理テーブル５０１に相当する情報が対応する各ノードの内部に格納されてもよい。バックエンドデバイス管理テーブル５０２には、特定のクラスタに含まれるすべての機器に関する情報が格納される。ただしクラスタ管理用計算機２０３にバックエンドデバイス管理テーブル５０２が格納される代わりに、各ノードのバックエンドデバイス管理テーブル５０２に相当する情報が対応する各ノードの内部に格納されてもよい。また以下では、バックエンドデバイス管理テーブル５０２を「コンポーネント管理情報」とも呼ぶ。

クラスタ外データ保護先管理テーブル５０３には、他のクラスタにおけるデータ保存領域の情報が格納される。ストレージクラス管理テーブル５０４には、ユーザが要求するデータ保護の要件事のデータ保護先の候補の一覧が格納される。冗長化関係性テーブル５０５には、冗長性を担保するために、指定されたコンポーネント以外でも同等の冗長性を確保できるコンポーネントが示されている。

ストレージクラス設定プログラム５１０は、管理用端末２０４からストレージクラスの要件を受信して動作を開始し、指定された要件を満たす候補をストレージクラス管理テーブル５０４に記載する。ストレージクラス設定プログラム５１０の動作は後に図１２を参照して詳述する。ボリューム作成プログラム５１１は、管理用端末２０４から指定されるボリュームの要件を満たすボリュームを作成する。ボリューム作成プログラム５１１の動作は後に図１５を参照して詳述する。データ冗長度維持回復プログラム５１２は、障害を検出してデータ冗長の維持回復を行う。データ冗長度維持回復プログラム５１２の動作は後に図１６を参照して詳述する。

図６は、ノード管理テーブル５０１の一例を示す図である。ノード管理テーブル５０１は複数のレコードから構成され、各レコードは、ノード番号６０１、障害耐性リソース６０２、稼働率６０３、ＡＦＲ６０４、ＭＴＢＦ６０５、およびＭＴＴＲ６０６のフィールドを有する。ノード番号６０１には、各ノードの識別子が格納される。本実施の形態ではノードの識別子は「Ｎ」と数字の組み合わせとする。障害耐性リソース６０２には、ノードが有する耐性の種類が格納される。たとえば電源が二重化されているノードは、障害耐性リソース６０２のフィールドに「電源」と記載される。ノード番号「Ｎ１」のノードは、電源、ファン、およびネットワークの耐性があることが示されている。

稼働率６０３には、ノードの稼働率が格納される。ＡＦＲ６０４には、ノードの年間平均故障率（Annual Failure Rate）が格納される。ＭＴＢＦ６０５には、ノードの平均故障間隔（mean time between failures）が格納される。ＭＴＴＲ６０６には、そのノードの平均復旧時間（Mean Time To Repair）が格納される。

図７は、バックエンドデバイス管理テーブル５０２の一例を示す図である。バックエンドデバイス管理テーブル５０２は複数のレコードから構成され、各レコードは、デバイス番号７０１、ノード番号７０２、冗長度７０３、障害耐性リソース７０４、スナップショットイメージ（ＳＳ－ＩＭＧ）バックアップ７０５、稼働率７０６、ＡＦＲ７０７、ＭＴＢＦ７０８、ＭＴＴＲ７０９、およびコスト７１０のフィールドを有する。

デバイス番号７０１には、各デバイスの識別子が格納される。ノード番号７０２には、デバイスが属するノードの識別子が格納される。この識別子は、図６におけるノード番号６０１と同じ意味である。冗長度７０３には、そのデバイスの冗長度合いを示す値が格納される。たとえば、冗長度７０３が「１」のデバイスは冗長性がないことを意味する。換言すると、冗長度７０３が「２」以上のデバイスはクラスタ管理用計算機２０３やストレージサービスコンテナ２１１が管理しないバックエンドでのデータ保護であるバックエンド保護が実行されている。

障害耐性リソース７０４には、そのデバイスが有する耐性の種類が格納される。たとえば、あるデバイスがＲＡＩＤカードなどを内蔵してデバイス内でミラーリングを行う場合には、障害耐性リソース７０４に「デバイス」と記載される。また、外部ストレージシステムなどのボリュームを用いる場合に、そのデバイスがクラスタのノード間で冗長化されている場合は、障害耐性リソース７０４に「ノード」と記載される。

ＳＳ－ＩＭＧバックアップ７０５には、デバイスに格納されている情報のスナップショットイメージ（ＳＳ－ＩＭＧ）のバックアップがされているか否かを示す情報が格納される。稼働率７０６、ＡＦＲ７０７、ＭＴＢＦ７０８、およびＭＴＴＲ７０９は、図６における稼働率６０３、ＡＦＲ６０４、ＭＴＢＦ６０５、およびＭＴＴＲ６０６と同一の情報なので説明を省略する。コスト７１０には、デバイスにデータを保存するコスト、より具体的には１ＧＢのデータを１年間保存するための費用がドル単位で格納される。たとえばデバイスＤ１を用いて１ＧＢのデータを１年間保存すると０．５ドルの費用が発生することが示されている。

図８は、クラスタ外データ保護先管理テーブル５０３の一例を示す図である。クラスタ外データ保護先管理テーブル５０３は複数のレコードから構成され、各レコードは、保護先管理番号８０１、接続情報８０２、ＡＺ８０３、サイト８０４、サービス事業者８０５、稼働率８０６、ＡＦＲ８０７、およびコスト８０８のフィールドを有する。稼働率８０６、ＡＦＲ８０７、およびコスト８０８は、図７における稼働率７０６、ＡＦＲ７０７、およびコスト７１０のそれぞれと同一の情報なので説明を省略する。

保護先管理番号８０１には、クラスタの外部に存在するデータ保護先の識別子が格納される。本実施の形態では、データ保護先の識別子に、「Ｐ」と数字との組合せを用いる。接続情報８０２には、データ保護先の所在地、たとえばＩＰアドレスが格納される。ＡＺ８０３には、クラスタ外データ保護先管理テーブル５０３を有するクラスタとデータ保護先のアベイラビリティゾーンが同一であるか否かを示す情報が格納される。サイト８０４には、クラスタ外データ保護先管理テーブル５０３を有するクラスタとデータ保護先のサイトが同一であるか否かを示す情報が格納される。サービス事業者８０５には、クラスタ外データ保護先管理テーブル５０３を有するクラスタとデータ保護先のサービス事業者が同一であるか否かを示す情報が格納される。

なおクラスタ外データ保護先管理テーブル５０３には、ＭＴＢＦやＭＴＴＲなど他の信頼性、可用性に関する指標が含まれてもよい。ＡＺ８０３、サイト８０４、およびサービス事業者８０５には、同一か否かという情報に替えて、何らかの識別子を格納してもよい。その場合は、管理元のストレージクラスタのＡＺ、サイト、およびサービス事業者のＩＤを別途管理して、そのＩＤとの一致、不一致で同一か別かを判断する。

図９は、ストレージクラス管理テーブル５０４の一例を示す図である。ストレージクラス管理テーブル５０４は複数のレコードから構成され、各レコードは、ストレージクラス管理番号９０１、要件９０２、およびデータ保護先候補９０３のフィールドを有する。ストレージクラス管理番号９０１には、ストレージクラスの識別子が格納される。本実施の形態では、ストレージクラスは「Ｃ」と数字の組み合わせの識別子を用いる。要件９０２には、ユーザから指定されたストレージクラスの要件、換言するとストレージに保存するデータに対するデータ保護の要求が格納される。データ保護先候補９０３には、ユーザから指定された要求を満たすデータ保護先の候補が格納される。この候補は、単独の場合もあるし、組合せの場合もある。

たとえば図９に示す最初のレコードでは、管理番号「Ｃ１」のストレージクラスは、ユーザからデバイスおよびＡＺの障害に耐えられる２冗長が求められており、Ｄ３とＰ５の組合せ、およびＤ４とＰ５の組合せのそれぞれで実現できることが示されている。ストレージクラスが追加されたときに、要件を満たす全ての組み合わせがデータ保護先候補９０３に格納されてもよいし、要件を満たす組合せの一部がデータ保護先候補９０３に格納されてもよい。後者の場合は、空き容量が所定の閾値よりも減少した際に、データ保護先候補９０３に新たなデータ保護先が追加される。

図１０は、冗長化関係性テーブル５０５の一例を示す図である。冗長化関係性テーブル５０５は複数のレコードから構成され、各レコードは、コンポーネント種別１００１、および代替種別１００２のフィールドを有する。コンポーネント種別１００１には、冗長化の対象となるコンポーネントの種別が格納される。代替種別１００２には、代替して冗長化が可能となるコンポーネントの種別が格納される。図１０に示す最初のレコードは、ストレージデバイスの冗長は、ノードの冗長化で代替可能であることが示されている。なお図１０に示されている情報を集約すると、ネットワーク構成における下位のコンポーネントの冗長化は、上位のコンポーネントで代替できることが示されている。

図１１は、ボリューム管理テーブル４２１の一例を示す図である。ボリューム管理テーブル４２１は複数のレコードから構成され、各レコードは、ボリューム管理番号１１０１、ストレージクラス管理番号１１０２、およびデータ保護先１１０３のフィールドを有する。ボリューム管理番号１１０１には、ボリュームの識別子が格納される。本実施の形態ではボリュームの識別子に「Ｖ」と数字との組合せを用いる。ストレージクラス管理番号１１０２は、図９におけるストレージクラス管理番号９０１と同じ意味なので説明を省略する。

データ保護先１１０３は、ボリュームの情報を格納するデバイス等の識別子が格納される。図１１に示す例では、ボリューム管理番号Ｖ１～Ｖ３のいずれもストレージクラスＣ１に対応し、Ｖ１およびＶ２はＤ３とＰ５の組合せを利用し、Ｖ３はＤ４とＰ５の組合せを用いることが示されている。なおボリュームの一部ごとに保護先が異なる場合は、データ保護先に複数の情報が格納される。

（フローチャート）
図１２は、ストレージクラス設定プログラム５１０が実行するストレージクラス設定処理を示すフローチャートである。ＣＰＵ３０１は、まずステップＳ１２１０において、管理用端末２０４からストレージクラスの要件を受信する。続くステップＳ１２２０ではＣＰＵ３０１は、ストレージクラス管理テーブル５０４を参照して新たな管理番号を決定し、その管理番号をストレージクラス管理テーブル５０４のストレージクラス管理番号９０１のフィールドに、ステップＳ１２１０において受信した要件を要件９０２のフィールドに記載する。

続くステップＳ１２３０ではＣＰＵ３０１は、後述するように各コンポーネント観点での冗長化先選定処理、すなわち障害の種類と冗長度との組合せの要件を満たすデータ保護先の候補の決定を行う。ただし、ステップＳ１２１０において受信した要求にコンポーネント観点での条件が含まれない場合には、ＣＰＵ３０１はステップＳ１２３０を実行しない。

続くステップＳ１２４０ではＣＰＵ３０１は、全システム観点での冗長化先選定処理、すなわち可用性の確率の要件を満たすデータ保護先の候補の決定を行う。具体的にはＣＰＵ３０１は、ステップＳ１２１０において受信した要求にシステムの稼働率が含まれる場合に本ステップを実行し、システムの稼働率が要求された値以上となるようにデータ保護先の候補を決定する。なおＣＰＵ３０１は、ノード管理テーブル５０１およびバックエンドデバイス管理テーブル５０２のいずれかに稼働率が設定されていないノードまたはデバイスが存在する場合には、後述する処理により稼働率を算出する。

ステップＳ１２５０ではＣＰＵ３０１は、システム観点でのコスト評価処理を行う。具体的にはＣＰＵ３０１は、ステップＳ１２１０において受信した要求にコストの条件が含まれている場合に実行され、ステップＳ１２３０およびステップＳ１２４０において選定された候補のそれぞれに対して、それぞれの候補に含まれるデバイスのコストを足し合わせて算出する。

続くステップＳ１２６０ではＣＰＵ３０１は、ステップＳ１２１０において受信した要件を全て満たす候補をストレージクラス管理テーブル５０４のデータ保護先候補９０３に格納して図１２に示す処理を終了する。具体的にはＣＰＵ３０１は、ステップＳ１２１０において受信した要件が障害の種類と冗長度との組合せのみの場合はステップＳ１２３０における選定結果を出力する。ＣＰＵ３０１は、ステップＳ１２１０において受信した要件が稼働率の要件のみの場合はステップＳ１２４０における選定結果を出力する。ＣＰＵ３０１は、ステップＳ１２１０において受信した要件にコストが含まれる場合は、ステップＳ１２５０における選定結果を出力する。

なおストレージクラス設定プログラム５１０は、ステップＳ１２１０においてデータ保護の要求を読み込むので、ストレージクラス設定プログラム５１０は「読込部」と呼ぶこともできる。またステップＳ１２３０～Ｓ１２５０の各ステップでは、コンポーネントの観点、システムの観点、およびコストの観点で、ユーザのデータ保護の要求に基づきストレージのデータ保護の方法を決定するので、ストレージクラス設定プログラム５１０は「決定部」と呼ぶこともできる。

図１３は、図１２におけるステップＳ１２３０、すなわち各コンポーネント観点での冗長化先選定処理を示すフローチャートである。まずステップＳ１５１０ではＣＰＵ３０１は、各コンポーネント観点での要件のリストを作成する。そしてＣＰＵ３０１は作成したリストの各項目を順番に処理対象として、ステップＳ１５２０～Ｓ１５４０の処理を実行する。ステップＳ１５２０ではＣＰＵ３０１は、処理対象である要件に合致する候補のデバイスをバックエンドデバイス管理テーブル５０２から抽出して列挙する。

続くステップＳ１５３０ではＣＰＵ３０１は、ステップＳ１５２０の処理により少なくとも１つの候補が存在するか否かを判断する。ＣＰＵ３０１は候補が少なくとも１つは存在すると判断する場合はステップＳ１５５０に進み、候補が１つもないと判断する場合はステップＳ１５４０に進む。ステップＳ１５４０ではＣＰＵ３０１は、冗長化関係性テーブル５０５を参照し、冗長化が代替可能なコンポーネント種別で、要件に合致する候補を列挙してステップＳ１５５０に進む。

ステップＳ１５５０ではＣＰＵ３０１は、ステップＳ１５１０において作成した要件のリストの全てを処理対象としたか否かを判断する。そしてＣＰＵ３０１は、まだ処理対象としていない要件が存在する場合には、未処理の要件を処理対象としてステップＳ１５２０以下の処理を実行する。ＣＰＵ３０１はリストの全てを処理対象としたと判断する場合は図１３に示す処理を終了する。

図１４は、図１２におけるステップＳ１２４０において必要に応じて呼び出される、稼働率計算処理を示すフローチャートである。ＣＰＵ３０１は、稼働率が設定されていない全てのデバイスを対象としてステップＳ１６２０～Ｓ１６４０の処理を繰り返す。具体的にはＣＰＵ３０１は、稼働率が設定されていない全てのデバイスを列挙し、その１つずつを処理対象（以下、「処理対象デバイス」と呼ぶ）としてステップＳ１６２０～Ｓ１６４０の処理を行う。

ステップＳ１６２０ではＣＰＵ３０１は、処理対象デバイスのＭＴＢＦと、処理対象デバイスが接続するノードのＭＴＢＦとを用いて、直列のＭＴＢＦを算出する。処理対象デバイスのＭＴＢＦをＸ、処理対象デバイスが接続するノードのＭＴＢＦをＹ、算出対象である直列のＭＴＢＦをＺと置くと、（１／Ｚ）＝（１／Ｘ）＋（１／Ｙ）の関係にあるＺの値を算出する。

続くステップＳ１６３０ではＣＰＵ３０１は、ノード障害が発生した場合の冗長度回復処理に要する時間をＭＴＴＲに設定する。続くステップＳ１６４０ではＣＰＵ３０１は、ＭＴＢＦとＭＴＴＲとを用いて、ノードとデバイスの直列の稼働率を算出する。具体的にはＣＰＵ３０１は、ＭＴＢＦの値を、ＭＴＢＦとＭＴＴＲの和で除することにより稼働率の値を得る。ＣＰＵ３０１は、稼働率が設定されていない全てのデバイスを対象としてステップＳ１６２０～Ｓ１６４０の処理を繰り返すと、ステップＳ１６６０に進む。ステップＳ１６６０ではＣＰＵ３０１は、各組合せ候補の直列または並列の状況に応じて稼働率を計算し、図１４に示す処理を終了する。

図１５は、ボリューム作成プログラム５１１が実行するボリューム作成処理を示すフローチャートである。ボリューム作成プログラム５１１は、まずステップＳ１３１０において、管理用端末２０４から指定されたボリュームの要件を受信する。この要件には少なくともストレージクラスの管理番号か、過去に伝達済みのストレージクラスの要件が含まれ、ボリュームの容量の指定が含まれてもよい。この要件はたとえば、「管理番号Ｃ１に２ＴＢのボリューム」、「デバイスが２冗長、かつＡＺが２冗長である２ＴＢのボリューム」というものである。なお、図９に示すストレージクラス管理テーブル５０４を前提とすればこの２つの要件は同一である。

続くステップＳ１３２０ではＣＰＵ３０１は、ストレージクラス管理テーブル５０４を参照し、要件で指定されたストレージクラスの組合せ候補を取得する。たとえば先ほどの例ではＣＰＵ３０１は、Ｄ３とＰ５の組合せ、Ｄ４とＰ５の組合せ、およびＤ４とＰ５の組合せを候補として取得する。続くステップＳ１３３０ではＣＰＵ３０１は、ステップＳ１３２０において取得した少なくとも１つに候補に十分な空き容量があるか否かを判断する。十分な空き容量とは、ステップＳ１３１０において容量が指定されている場合にはそれ以上の空き容量であり、ステップＳ１３１０において容量が指定されていない場合には、たとえばあらかじめ定められた容量、たとえば１ＴＢの空き容量である。

ＣＰＵ３０１は、十分な空き容量があると判断する場合はステップＳ１３４０に進み、いずれの候補にも空き容量がないと判断する場合はステップＳ１３６０においてエラーを出力して図１５に示す処理を終了する。ステップＳ１３４０ではＣＰＵ３０１は、ステップＳ１３２０において取得した候補のうち、空き容量を満たす組合せ候補をデータ保護先として決定する。続くステップＳ１３５０ではＣＰＵ３０１は、ステップＳ１３４０において決定したデータ保護先に容量を確保して図１５に示す処理を終了する。なお、シックプロビジョニングの場合は決定した保護先の容量を確保し、シンプロビジョニングの場合は必要最低限の領域のみを確保する。

なおステップＳ１３３０において、空き容量を満たす単一の組合せ候補がない場合は、サブボリューム毎に異なる組合せ候補を用いてもよい。同じくステップＳ１３３０において空き容量が足りないと判断する場合は、エラーとするのではなく、新たに追加されたコンポーネントの有無を確認し、ストレージクラスの仕様を満たす新たな組合せ候補がある場合はストレージクラス管理テーブル５０４を更新し、ボリューム作成処理を再実行してもよい。

図１６は、データ冗長度維持回復プログラム５１２が実行するデータ冗長度維持回復処理を示すフローチャートである。ＣＰＵ３０１は、まずステップＳ１４１０において、各表のノード、デバイス、クラスタ外データ保護先の障害を検出する。続くステップＳ１４２０ではＣＰＵ３０１は、ステップＳ１４１０において何らかの障害が検出されたか否かを判断する。ＣＰＵ３０１は何らかの障害を検出したと判断する場合はステップＳ１４３０に進み、障害を検出していないと判断する場合はステップＳ１４１０に戻る。

ステップＳ１４３０ではＣＰＵ３０１は、ボリューム管理テーブル４２１を参照して障害の発生先がデータ保護先に指定されているボリュームを特定する。たとえばステップＳ１４１０においてデバイスＤ３に障害が検知された場合は、ボリューム管理テーブル４２１を参照してボリュームＶ１とＶ２が特定される。

続くステップＳ１４４０ではＣＰＵ３０１は、ステップＳ１４３０において特定したボリュームのリストを作成し、各ボリュームを順番に処理対象としてステップＳ１４５０～Ｓ１４７０の処理を実行する。ステップＳ１４５０ではＣＰＵ３０１は、ストレージクラス管理テーブル５０４を参照して処理対象のボリュームに対応するストレージクラス管理番号１１０２を特定し、別のデータ保護先の組合せ候補を特定する。処理対象のボリュームがＶ１の場合は、同じくストレージクラス管理番号Ｃ１のＤ４＋Ｐ５が特定される。なおデータ保護先の選択において、元の組合せ候補と重複する複製先が多く含まれている組合せを選択することで、データの冗長度の回復のコストを低減することができる。

続くステップＳ１４６０ではＣＰＵ３０１は、ステップＳ１４５０において新しく選択したデータ保護先候補を、ボリュームを管理するボリューム管理テーブル４２１に登録する。続くステップＳ１４７０ではＣＰＵ３０１は、ボリュームを管理するノードの冗長度回復処理プログラム４２４に対して新しく選択したデータ保護先への複製を指示してステップＳ１４８０に進む。

ステップＳ１４８０ではＣＰＵ３０１は、ステップＳ１４３０において特定した全てのボリュームを処理対象としてステップＳ１４５０～Ｓ１４７０の処理を実行したか否かを判断する。ＣＰＵ３０１は、特定した全てのボリュームを処理対象としてステップＳ１４５０～Ｓ１４７０の処理を実行したと判断する場合はステップＳ１４１０に戻り、未処理のボリュームが存在すると判断する場合は処理対象を変更してステップＳ１４５０に戻る。

図１７は、冗長化処理プログラム４２３が実行する冗長化処理を示すフローチャートである。ＣＰＵ３０１はまずステップＳ１７１０において、ストレージサービス処理プログラム４２２から書込データ、すなわち冗長化のために書き込みを行うべきデータを受信する。

続くステップＳ１７２０ではＣＰＵ３０１は、ボリューム管理テーブル４２１を参照し、データ保護先に対してステップＳ１７１０において受信した書込データを送信する。続くステップＳ１７３０ではＣＰＵ３０１は、同期書き込みが必要な全てのデータ保護先から書き込み完了報告を受信したか否かを判断する。ＣＰＵ３０１は、完了報告を受信していないと判断するとステップＳ１７３０に留まり、完了報告を受信したと判断すると図１７に示す処理を終了する。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）ストレージ管理システムである計算機システム１００は、プロセッサであるＣＰＵ３０１を有し、ストレージシステム１２０や一体型計算機クラスタ１１２に含まれる複数のストレージを管理する。ストレージは、複数の種類のコンポーネントを有して、前記複数のコンポーネントを組み合わせて、格納するデータの冗長化を行う。計算機システム１００は、コンポーネント自身に設定されている冗長度を示したコンポーネント管理情報であるバックエンドデバイス管理テーブル５０２を有する。ＣＰＵ３０１は、バックエンドデバイス管理テーブル５０２と、ストレージに保存するデータに対するデータ保護の要求と、に基づき、ストレージのデータ保護の方法を設定する（ストレージクラス設定プログラム５１０：図１２のステップＳ１２３０～Ｓ１２５０）。そのため、指定されるデータ保護の要求に基づき、適切にデータ保護を実行できる。

（２）ＣＰＵ３０１は、バックエンドデバイス管理テーブル５０２に記されるコンポーネント自身の冗長度と、複数のコンポーネントを組み合わせて設定する冗長度と、の合計が、データ保護の要求に含まれるデータの冗長度を満たすようにストレージのデータ保護の方法を設定する。

（３）データ保護の要求は、データを保護するコンポーネントの障害の種類と、その生涯に対するデータの冗長度との組合せが含まれる。たとえば図９に例示したストレージクラス管理テーブル５０４のストレージクラス管理番号９０１がＣ１とＣ３のストレージクラスには、障害の種類と冗長度の組合せが含まれる。ストレージクラス設定プログラム５１０は、図１２のステップＳ１２３０、すなわち図１３に示す処理により、要求された障害の種類と冗長度の組合せを満たすデバイスの組合せを選択する。そのため計算機システム１００は、要求された障害の種類と冗長度を満たすデータ保護を実行できる。

（４）データ保護の要求は、可用性の確率が含まれる。たとえば図９に例示したストレージクラス管理テーブル５０４のストレージクラス管理番号９０１がＣ２のストレージクラスには、可用性の確率である稼働率が含まれる。ストレージクラス設定プログラム５１０は、図１２のステップＳ１２４０に示す処理、および必要に応じて図１４に示す処理により、要求された可用性の確率を満たすデバイスの組合せを選択する。そのため計算機システム１００は、要求された可用性の要件を満たすデータ保護を実行できる。

（５）データ保護の要求には、データ保護に要するコストが含まれる。たとえば図９に例示したストレージクラス管理テーブル５０４のストレージクラス管理番号９０１がＣ３のストレージクラスには、コストが含まれる。ストレージクラス設定プログラム５１０は、図１２のステップＳ１２５０の処理により、要求されたコストを満たすデバイスの組合せを選択する。そのため計算機システム１００は、要求されたコストの要件を満たすデータ保護を実行できる。

（６）複数のストレージに含まれる少なくとも１つのストレージは、ストレージ管理システムが管理しないバックエンドでのデータ保護であるバックエンド保護が実行されている。決定部（ストレージクラス設定プログラム５１０：図１２のステップＳ１２３０）は、バックエンド保護とデータ保護の要求とに基づきストレージのデータ保護の方法を決定する。そのため、バックエンド保護がされているデバイスを用いる場合に、過剰な保護を防止できる。たとえば要求された保護の要件がデバイス障害について２冗長である場合に、図７のデバイス番号Ｄ２のように「デバイス」の障害耐性を有する場合にはすでに要件を満たしているので、さらなる保護を行わずにデータを保存し過剰な保護を抑制する。たとえば、パブリッククラウドではサービス事業者がデバイスのデータ保護を標準またはオプションで提供し、さらにリージョンやサイトレベルでのバックエンドの保護も提供することがある。このようなパブリッククラウドのデバイスを利用する場合には、バックエンドでの保護を考慮することで過剰な保護を防止できる。

（７）計算機システム１００は、複数のストレージにおける障害を検出し、障害が検出されたストレージに格納されていたデータを、当該データに対するデータ保護の要求に応じて、複数のストレージのうち障害が検出されたストレージを除くいずれかのストレージに保存するデータ冗長度維持回復プログラム５１２を備える。そのため、ストレージに障害が発生した際にも、過不足なく適切なデータ保護を行える。

（８）複数のストレージのそれぞれは、２以上のノードのいずれかによって管理される。決定部（図１３のステップＳ１５４０）は、ストレージの冗長化の代わりにノードの冗長化を選択可能である。そのため、異なる保護レベルでユーザの要求を満たすことができる。

（９）計算機システム１００に含まれるクラスタ管理用計算機２０３が実行する管理方法は、計算機システム１００に含まれる複数のストレージを以下のように管理する。すなわち、複数のストレージに含まれる少なくとも１つのストレージに保存するデータに対するデータ保護の要求を読み込むこと（図１２のステップＳ１２１０）と、データ保護の要求に基づきストレージのデータ保護の方法を決定すること（図１２のステップＳ１２３０～Ｓ１２５０）とを含む。そのため、指定されるデータ保護の要求に基づき、適切にデータ保護を実行できる。

（変形例１）
ストレージクラス設定プログラム５１０は、データを出力するアプリケーションにおけるデータ保護をさらに参酌してもよい。たとえばアプリケーションがデータを複数のアベイラビリティゾーンに保存しており、要求された保護の要件がＡＺ障害について２冗長である場合は、ストレージクラス設定プログラム５１０は、冗長度が「１」のデバイスを単独でデータ保護先に用いる。アプリケーションがすでに二重化を行っているので、ストレージクラス設定プログラム５１０がさらなる保護を行うと過剰になるためである。

本変形例ではユーザは、管理用端末２０４を用いて、ストレージクラスの要件と、ボリュームの作成と、そのボリュームに書き込みを行うことが想定されているアプリケーション（以下、「想定アプリケーション」と呼ぶ）のデータ保護方式とを入力する。データ保護方式とは、データ保護の要件に対応する概念であり、データをどのように保護するかを示す。たとえばデータ保護方式は、異なるデバイスに同一のデータを格納するデバイス保護、異なるノードに同一のデータを格納するノード保護、異なるＡＺに同一のデータを格納するＡＺ保護などである。

なお、ユーザが想定アプリケーションのデータ保護方式を入力する代わりに、想定アプリケーションの識別情報を入力し、ストレージクラス設定プログラム５１０が不図示であるその識別情報とデータ保護方式との対応表を参照してもよい。

図１８は、変形例１におけるストレージクラス設定処理を示すフローチャートであり、第１の実施の形態における図１２に相当する。以下では図１２との相違点を主に説明する。最初に実行されるステップＳ１２１５では、ＣＰＵ３０１は、管理用端末２０４からストレージクラスの要件だけでなく、想定アプリケーションの情報を受信してステップＳ１２２０に進む。ステップＳ１２２０の次に実行されるステップＳ１２２５ではＣＰＵ３０１は、ストレージクラスに作成するボリュームに対して書き込みを行うアプリケーションのデータ保護方式を読み込む。ステップＳ１２１５において受信した想定アプリケーションの情報が想定アプリケーションのデータ保護方式である場合にはその情報をそのまま使用する。また、ステップＳ１２１５において受信した想定アプリケーションの情報が想定アプリケーションの識別情報である場合には、前述の識別情報とデータ保護方式との対応表を参照してデータ保護の方式を読み込む。ステップＳ１２３０およびＳ１２４０ではＣＰＵ３０１は、アプリケーションのデータ保護方式とデータ保護の要求とに基づきストレージのデータ保護の方法を決定する。

この変形例１によれば、次の作用効果が得られる。
（１０）データ保護の要求には、ストレージを利用することが想定される想定アプリケーションが実施するデータ保護の情報が含まれる。決定部（図１８のステップＳ１５３０～Ｓ１５５０）は、想定アプリケーションが実施するデータ保護とデータ保護の要求とに基づきストレージのデータ保護の方法を決定する。そのため計算機システム１００は、ボリュームに書き込みを行うアプリケーションのデータ保護方式を考慮して過不足のないデータ保護を実現できる。

上述した実施の形態および変形例において、機能ブロックの構成は一例に過ぎない。別々の機能ブロックとして示したいくつかの機能構成を一体に構成してもよいし、１つの機能ブロック図で表した構成を２以上の機能に分割してもよい。また各機能ブロックが有する機能の一部を他の機能ブロックが備える構成としてもよい。

１００…計算機システム
１１１…分離型計算機クラスタ
１１２…一体型計算機クラスタ
１２０…ストレージシステム
２０１…ノード
２０３…クラスタ管理用計算機
２０４…管理用端末
２１０…アプリケーションコンテナ
２１１…ストレージサービスコンテナ
４１０…コンテナ管理基盤用メモリ領域
４２０…ストレージサービスコンテナ用メモリ領域
４２１…ボリューム管理テーブル
４２２…ストレージサービス処理プログラム
４２３…冗長化処理プログラム
４２４…冗長度回復処理プログラム
４３０…アプリケーションコンテナ用メモリ領域
４３１…アプリケーションプログラム
５０１…ノード管理テーブル
５０２…バックエンドデバイス管理テーブル
５０３…クラスタ外データ保護先管理テーブル
５０４…ストレージクラス管理テーブル
５０５…冗長化関係性テーブル
５１０…ストレージクラス設定プログラム
５１１…ボリューム作成プログラム
５１２…データ冗長度維持回復プログラム

Claims (9)

1. プロセッサを有し、複数のストレージを管理するストレージ管理システムであって、
   前記ストレージは、複数の種類のコンポーネントを有して、前記複数のコンポーネントを組み合わせて、格納するデータの冗長化を行い、
   前記コンポーネント自身に設定されている冗長度を示したコンポーネント管理情報を有し、
   前記プロセッサは、前記コンポーネント管理情報と、前記ストレージに保存するデータに対するデータ保護の要求と、に基づき、前記ストレージにおいてデータを格納する前記コンポーネントの組み合わせを決定し、
   前記データ保護の要求には、少なくともデータの冗長度の要求が含まれ、
   前記プロセッサは、前記コンポーネント管理情報に記されるコンポーネント自身の冗長度と、前記複数のコンポーネントを組み合わせて設定する冗長度と、の合計が、前記データ保護の要求に含まれるデータの冗長度を満たすように前記コンポーネントの組み合わせを決定するストレージ管理システム。
2. 請求項１に記載のストレージ管理システムであって、
   前記複数のストレージに含まれる少なくとも１つのストレージは、前記ストレージ管理システムが管理しないバックエンドでのデータ保護であるバックエンド保護が実行されており、
   前記データ保護の要求から前記バックエンド保護により保護される要求を除き、残りの要求を満たすように前記ストレージにおいてデータを格納する前記コンポーネントの組み合わせを決定するストレージ管理システム。
3. 請求項１に記載のストレージ管理システムであって、
   前記データ保護の要求には、障害の種類と冗長度との組合せが含まれ、
   前記プロセッサは、前記データ保護の要求に含まれる前記障害の種類について、前記データ保護の要求に含まれる前記冗長度を有するように前記コンポーネントの組み合わせを決定するストレージ管理システム。
4. 請求項１に記載のストレージ管理システムであって、
   前記データ保護の要求には、稼働率が含まれ、
   前記プロセッサは、前記データ保護の要求に含まれる前記稼働率を満たすように前記コンポーネントの組み合わせを決定するストレージ管理システム。
5. 請求項１に記載のストレージ管理システムであって、
   前記データ保護の要求には、データ保護に要するコストが含まれ、
   前記プロセッサは、前記データ保護の要求に含まれる前記コストの条件を満たすように前記コンポーネントの組み合わせを決定するストレージ管理システム。
6. 請求項１に記載のストレージ管理システムであって、
   前記データ保護の要求には、前記ストレージを利用することが想定される想定アプリケーションが実施するデータ保護であるアプリ保護の情報が含まれ、
   前記プロセッサは、前記データ保護の要求から前記アプリ保護により保護される要求を除き、残りの要求を満たすように前記ストレージにおいてデータを格納する前記コンポーネントの組み合わせを決定するストレージ管理システム。
7. 請求項１に記載のストレージ管理システムであって、
   前記複数のストレージにおける障害を検出し、障害が検出されたストレージに格納されていたデータを、当該データに対するデータ保護の要求に応じて、前記複数のストレージのうち前記障害が検出されたストレージを除くいずれかのストレージに保存する回復処理を行うストレージ管理システム。
8. 請求項１に記載のストレージ管理システムであって、
   前記コンポーネントは、ノード、および、ストレージデバイスを含むストレージ管理システム。
9. プロセッサを有し、複数のストレージを管理するストレージ管理システムが実行する管理方法であって、
   前記ストレージは、複数の種類のコンポーネントを有して、前記複数のコンポーネントを組み合わせて、格納するデータが冗長化され、
   前記コンポーネント自身に設定されている冗長度を示したコンポーネント管理情報を有し、
   前記コンポーネント管理情報と、前記ストレージに保存するデータに対するデータ保護の要求と、に基づき、前記ストレージにおいてデータを格納する前記コンポーネントの組み合わせを決定する決定処理を含み、
   前記データ保護の要求には、少なくともデータの冗長度の要求が含まれ、
   前記決定処理には、前記コンポーネント管理情報に記されるコンポーネント自身の冗長度と、前記複数のコンポーネントを組み合わせて設定する冗長度と、の合計が、前記データ保護の要求に含まれるデータの冗長度を満たすように前記コンポーネントの組み合わせを決定することを含む管理方法。

Images