特開 2023-96958 ストレージシステム及びストレージシステム制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023096958

(43)【公開日】2023-07-07

(54)【発明の名称】ストレージシステム及びストレージシステム制御方法

(51)【国際特許分類】

   G06F 3/06 20060101AFI20230630BHJP

   G06F 13/10 20060101ALI20230630BHJP

   G06F 11/20 20060101ALI20230630BHJP

【ＦＩ】

G06F3/06 305C

G06F3/06 301X

G06F3/06 304F

G06F13/10 340A

G06F11/20 694

G06F3/06 540

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2021213045

(22)【出願日】2021-12-27

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】大平 良徳

(72)【発明者】

【氏名】山本 貴大

(72)【発明者】

【氏名】江原 寛人

【テーマコード（参考）】

5B034

【Ｆターム（参考）】

5B034CC04

(57)【要約】

【課題】ストレージユニットの負荷を抑えつつ、ネットワーク転送量を低減すること。
【解決手段】１つ又は複数のストレージユニットと計算機を備えたストレージシステムにおいて、ストレージユニットは複数の物理記憶デバイスとプロセッサを有し、計算機は、プロセッサによってストレージユニットに入出力するデータを処理するコントローラを有し、ストレージシステムは、データを冗長化して格納し、一部の物理記憶デバイスからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な物理記憶デバイスからデータを読み出してリード要求にかかるデータを復旧させ、リード要求の要求元に復旧させたデータを送信し、読み出したデータからリード要求にかかるデータを復旧させる処理は、計算機のコントローラ及びストレージユニットのプロセッサで選択的に実行可能であることを特徴とする。
【選択図】図１３

【特許請求の範囲】

【請求項1】

１つ又は複数のストレージユニットと、
１つ又は複数のストレージユニットに通信ネットワークを介して接続された計算機と、
を備えたストレージシステムにおいて、
前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイスと、
プロセッサと、を有し、
前記計算機は、プロセッサによって、前記ストレージユニットに入出力するデータを処理するコントローラを有し、
前記ストレージシステムは、前記データを冗長化して格納し、一部の前記物理記憶デバイスからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理記憶デバイスからデータを読み出し、読み出したデータから前記リード要求にかかるデータを復旧させ、前記リード要求の要求元に前記復旧させたデータを送信し、
前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能である
ことを特徴とするストレージシステム。

【請求項2】

前記計算機のコントローラがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記計算機に送信し、前記コントローラが前記送信された複数のデータから前記リード要求にかかるデータを復旧し、
前記ストレージユニットのプロセッサがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記リード要求にかかるデータを復旧し、前記復旧させたデータを計算機に送信する
ことを特徴とする請求項１に記載のストレージシステム。

【請求項3】

前記計算機のコントローラは、前記障害が発生している物理記憶デバイスについてのリード要求を受信した場合に、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかを決定し、
前記決定を、前記リード要求とともに、前記ストレージユニットに送信する
ことを特徴とする請求項２に記載のストレージシステム。

【請求項4】

前記冗長化には、１のストレージユニット内のデータでデータ復旧を可能にする第１の冗長化と、複数のストレージユニット内のデータでデータ復旧を可能にする第２の冗長化と、の両方が含まれており、
前記計算機のコントローラは、前記第１の冗長化と前記第２の冗長化のいずれでデータ復旧を行うかと、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかと、を決定する
ことを特徴とする請求項３に記載のストレージシステム。

【請求項5】

前記計算機のコントローラは、前記第１の冗長化でデータ復旧を行う場合には、前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、前記第２の冗長化でデータ復旧を行う場合には、前記計算機のコントローラが前記データ復旧処理を行うと決定する
ことを特徴とする請求項４に記載のストレージシステム。

【請求項6】

前記計算機のコントローラは、前記第１の冗長化でデータ復旧が可能かどうかを判断し、可能な場合には、前記第１の冗長化を用いて前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、可能ではない場合には、前記第２の冗長化を用いて前記計算機のコントローラが前記データ復旧処理を行うと決定する
ことを特徴とする請求項５に記載のストレージシステム。

【請求項7】

前記ストレージユニットは、前記障害が発生している物理記憶デバイスについてのリード要求を受信した場合に、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかを、前記ストレージユニットの負荷状況に基づいて決定する
ことを特徴とする請求項２に記載のストレージシステム。

【請求項8】

前記冗長化には、１のストレージユニット内のデータでデータ復旧を可能にする第１の冗長化と、複数のストレージユニット内のデータでデータ復旧を可能にする第２の冗長化と、の両方が含まれており、
前記計算機のコントローラは、前記第１の冗長化でデータ復旧が可能かどうかを判断して、その判断結果を前記リード要求とともに前記ストレージユニットに送信し、
前記判断が前記第１の冗長化でデータ復旧が可能ではない場合には、前記計算機のコントローラは、複数のストレージユニットからデータを読み出し、前記第２の冗長化により前記リード要求にかかるデータを復旧させ、
前記判断が前記第１の冗長化でデータ復旧が可能である場合には、前記計算機のコントローラは、一のストレージユニットにリード要求を送信し、前記リード要求を受信したストレージユニットは、自己の負荷状況に基づいて、自身で前記第１の冗長化を用いて前記リード要求にかかるデータを復旧させるかどうかを決定し、読み出した複数のデータまたはそれを用いて前記第１の冗長化を用いて復旧させたリード要求にかかるデータのいずれかを、前記計算機に送信する
ことを特徴とする請求項２に記載のストレージシステム。

【請求項9】

１つ又は複数のストレージユニットと、１つ又は複数のストレージユニットに通信ネットワークを介して接続された計算機と、を備えたストレージシステムにおけるストレージシステム制御方法であって、
前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイスと、プロセッサと、を有し、
前記計算機は、プロセッサによって、前記ストレージユニットに入出力するデータを処理するコントローラを有し、
前記ストレージシステムが、
前記データを冗長化して格納する処理と、
一部の前記物理記憶デバイスからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理記憶デバイスからデータを読み出す処理と、
前記読み出したデータから前記リード要求にかかるデータを復旧させる処理と、
前記リード要求の要求元に前記復旧させたデータを送信する処理と、を含み
前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能である
ことを特徴とするストレージシステム制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ストレージシステム及びストレージシステム制御方法に関する。

【背景技術】

【0002】

従来のストレージシステムのアーキテクチャは、専用ハードウェアを用いたデュアルコントローラ型が主流であった。近年では、汎用サーバでストレージシステムを構築するＳｏｆｔｗａｒｅ－ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ（ＳＤＳ）が主流となってきている。またＳＤＳの一形態として、汎用サーバ上にアプリケーションとストレージ制御ソフトとを同梱するＨｙｐｅｒ Ｃｏｎｖｅｒｇｅｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ（ＨＣＩ）が広く認知されるようになってきている。このように、ストレージシステムのアーキテクチャは多様化している。

【0003】

一方で、近年のストレージシステムでは、高速なデータを読み出しが可能なＦｌａｓｈデバイスの適用範囲を広げる技術として、ネットワーク経由で高速にデータ通信を行うプロトコルであるＮｏｎ Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ Ｅｘｐｒｅｓｓ ｏｖｅｒ Ｆａｂｒｉｃ（ＮＶＭｅ－ｏＦ）技術が広がりつつある。当該プロトコルを使うことで、ネットワークを介したＦｌａｓｈデバイスでも高速にデータ読み出しを行うことが可能になる。ネットワーク上にＦｌａｓｈを集約することを目的に、Ｆａｂｒｉｃ－ａｔｔａｃｈｅｄ Ｂｕｎｃｈ ｏｆ Ｆｌａｓｈ（ＦＢＯＦ）と呼ぶ、当該技術でデータ通信可能なＤｒｉｖｅ Ｂｏｘ製品も市場に現れつつある。

【0004】

ＳＤＳ／ＨＣＩに関し、特許文献１がある。特許文献１には「複数の物理記憶デバイス（ＰＤＥＶ）を含んだ１つ又は複数のストレージユニットと、当該１つ又は複数のストレージユニットに通信ネットワークを介して接続された複数の計算機とが備えられる。２つ以上の計算機が、それぞれ、ストレージ制御プログラム（以下、制御プログラム）を実行する。２つ以上の制御プログラムが、複数のＰＤＥＶが提供する複数の記憶領域および当該複数の記憶領域に関するメタデータを共有する。制御プログラムに障害が発生した場合、メタデータを共有する他の制御プログラムが、記憶領域に格納されたデータにアクセスする。ＰＤＥＶに障害が発生した場合、障害の発生していない他のＰＤＥＶに記憶された冗長化させたデータを用いて、制御プログラムが、障害の発生したＰＤＥＶのデータを復元する。」との記載がある。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０２１－１５７５８８号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

ネットワーク接続型Ｄｒｉｖｅ Ｂｏｘ（ＦＢＯＦ）を用いたストレージシステムでは、ドライブからの転送データがネットワークを流れるため、ネットワークがボトルネックとなりやすい。ネットワーク接続型Ｄｒｉｖｅ Ｂｏｘ（ＦＢＯＦ）をストレージユニットとし、ストレージユニットにネットワークを介して接続されるストレージコントローラを計算機とすれば、計算機がストレージユニットに読み書きを行う場合には、常にネットワークにデータ転送が発生する。

【0007】

特に、ドライブ障害時に必要なデータ復旧処理（リビルド処理）では、ストレージコントローラでデータ復旧を行うと、ストレージコントローラがデータ復旧のために大量のデータをネットワーク経由で読み出す必要があり、データ復旧処理の遅延やホスト性能の不安定さを招く。

【0008】

本課題の解決策として、データ冗長化機能を有するＦＢＯＦを用いる方法が考えうる。しかしながら、当該方法では、ＦＢＯＦが性能ボトルネックとなってシステム性能が劣化する点や、ＦＢＯＦ間でデータの冗長化ができずに信頼性が劣化する点が懸念となる。このため、ストレージコントローラでデータ冗長化を行ってＦＢＯＦコントローラの負荷を抑えつつ、ネットワーク転送量が少ないリビルド方法が必要である。

【課題を解決するための手段】

【0009】

上記目的を達成するために、代表的な本発明のストレージシステム及びストレージシステム制御方法の一つは、１つ又は複数のストレージユニットと、１つ又は複数のストレージユニットに通信ネットワークを介して接続された計算機と、備えたストレージシステムにおいて、前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイスと、プロセッサと、を有し、前記計算機は、プロセッサによって、前記ストレージユニットに入出力するデータを処理するコントローラを有し、前記ストレージシステムは、前記データを冗長化して格納し、一部の前記物理記憶デバイスからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理記憶デバイスからデータを読み出し、読み出したデータから前記リード要求にかかるデータを復旧させ、前記リード要求の要求元に前記復旧させたデータを送信し、前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能であることを特徴とする。

【発明の効果】

【0010】

本発明によれば、ネットワークを介してストレージユニットにアクセスするストレージシステムにおいて、ストレージユニットの負荷を抑えつつ、ネットワーク転送量を低減することができる。上記した以外の課題、構成及び効果は以下の実施の形態の説明により明らかにされる。

【図面の簡単な説明】

【0011】

【図1】本発明における、ストレージシステムの概要図である。

【図2】本発明における、ストレージシステムの構成の変形例である。

【図3】本発明における、サーバおよびＤｒｉｖｅ Ｂｏｘのハード構成例である。

【図4】本発明における、ストレージシステムの別の構成例である。

【図5】本発明における、Ｄｏｍａｉｎ Ｇｒｏｕｐ管理テーブルの構成例である。

【図6】本発明における、Ｄｒｉｖｅ Ｂｏｘに搭載された複数台のドライブの領域管理方法の一例である。

【図7】本発明における、Ｃｈｕｎｋ Ｇｒｏｕｐ管理テーブルの構成例である。

【図8】本発明における、ページマッピングテーブルと空きページ管理テーブルの構成例である。

【図9】本発明における、ページマッピングテーブル、空きページ管理テーブル、Ｃｈｕｎｋ Ｇｒｏｕｐ管理テーブルの各サーバへの配置方法の例である。

【図10】実施例１における、Ｃｈｕｎｋ Ｇｒｏｕｐ構成例である。

【図11】実施例１における、Ｃｈｕｎｋ Ｇｒｏｕｐ作成プログラムの構成例である。

【図12】実施例１における、ライトプログラムの構成例である。

【図13】実施例１における、リードプログラムの構成例である。

【図14】実施例１における、データ復旧プログラムの構成例である。

【図15】実施例２における、Ｃｈｕｎｋ Ｇｒｏｕｐ構成例である。

【図16】実施例２における、Ｃｈｕｎｋ Ｇｒｏｕｐ作成プログラムの構成例である。

【図17】実施例２における、ライトプログラムの構成例である。

【図18】実施例２における、リードプログラムの構成例である。

【図19】実施例２における、データ復旧プログラムの構成例である。

【図20】実施例２における、復旧可否変更プログラムの構成例である。

【発明を実施するための形態】

【0012】

以下、実施例を図面を用いて説明する。

【実施例0013】

図１は、本実施例における、分散ストレージシステムの概要図である。本実施例の分散ストレージシステムは、ネットワークで接続された複数台のサーバ１０１と複数台のＤｒｉｖｅ Ｂｏｘ１０６、管理サーバ１０５とで構成される。各サーバには、単一個のストレージ制御ソフト１０３と複数個のアプリ１０２とが共存して動作する。但し、アプリのみのサーバやストレージ制御ソフトのみのサーバが存在した場合でも同一の効果を実現することが可能である。アプリから書き込まれるデータは、ストレージ制御ソフトを介して、ネットワーク接続されたＤｒｉｖｅ Ｂｏｘのいずれかに格納される。ネットワーク１０４には、Ｅｔｈｅｒｎｅｔ、Ｆｉｂｒｅ Ｃｈｕｎｎｅｌ等の汎用的なネットワーク技術を用いることができる。ネットワークは、サーバとＤｒｉｖｅ Ｂｏｘとを直接接続してもよいし、１個以上のスイッチを介して接続してもよい。通信プロトコルには、ｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ ＳＣＳＩ）やＮＶＭｅ－ｏＦ等の汎用技術を用いることが可能である。

【0014】

図２は、もう一つ別のストレージシステムの構成例であり、本構成においても同様の効果を得ることができる。
本構成では、ネットワーク１０４よりも高速なインターフェース２５０２で接続した一組のストレージコントローラ２５０３を複数組並べて、ストレージシステムを構成する。各コントローラ２５０１には、単一個のストレージ制御ソフト１０３が動作し、互いに通信する。本構成では、組となるコントローラ間でメタデータの冗長化を行い、あるコントローラに障害が発生した場合に、当該コントローラと組となったコントローラにフェイルオーバーを行って処理を継続する。ストレージコントローラが受領する書込みデータは、ストレージ制御ソフトを介して、ネットワーク接続されたＤｒｉｖｅ Ｂｏｘ１０６のいずれかに格納される。

【0015】

図３は、本実施例における、サーバおよびＤｒｉｖｅ Ｂｏｘのハード構成例である。サーバは、複数個のプロセッサ２０１、メモリ２０２、ネットワークＩ／Ｆ２０３とで構成される。一方、Ｄｒｉｖｅ Ｂｏｘは、複数個のプロセッサ、メモリ、ネットワークＩ／Ｆの他、複数台のドライブ２０４で構成される。ＦＢＯＦ内のメモリには、リードバッファ２１０と呼ぶ論理領域を確保され、ストレージコントローラとドライブとのデータ転送に用いることができる。サーバとＤｒｉｖｅ Ｂｏｘとは、ネットワークＩ／Ｆ経由でネットワークに接続され、互いに通信が可能である。ドライブには、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）やＳｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）といった汎用的なドライブを用いることが可能である。当然ながら、本発明はドライブの種類やフォームファクタに依存せず、他の種類のドライブを用いてもよい。

【0016】

図４は、本実施例における、分散ストレージシステムの別の構成例である。本構成では、サーバやＤｒｉｖｅ Ｂｏｘが、Ｄｏｍａｉｎ Ｇｒｏｕｐ３０１、３０２と呼ぶ単位でグループ管理される。本構成において、アプリが書き込むデータは、ストレージ制御ソフトを介して、アプリが動作するサーバと同じＤｏｍａｉｎ Ｇｒｏｕｐに属するＤｒｉｖｅ Ｂｏｘのいずれかに格納される。例えば、Ｄｏｍａｉｎ Ｇｒｏｕｐ３０１に属するサーバ＃０００および＃００１のデータは、Ｄｒｉｖｅ Ｂｏｘ＃０００および＃００１に格納され、Ｄｏｍａｉｎ Ｇｒｏｕｐ３０２に属するサーバ＃００２および＃００３のデータは、Ｄｒｉｖｅ Ｂｏｘ＃００２に格納される。このようにＤｏｍａｉｎ Ｇｒｏｕｐを用いて分散ストレージシステムを構成することで、Ｄｒｉｖｅ Ｂｏｘやドライブに障害が発生した場合の、サーバ性能影響をＤｏｍａｉｎ Ｇｒｏｕｐ間で分離することが可能となる。

【0017】

図５は、Ｄｏｍａｉｎ Ｇｒｏｕｐ管理テーブル４００の構成例である。Ｄｏｍａｉｎ Ｇｒｏｕｐ管理テーブルは、Ｄｏｍａｉｎ Ｇｒｏｕｐを構成するサーバ群とＤｒｉｖｅ Ｂｏｘ群とを管理する。Ｄｏｍａｉｎ Ｇｒｏｕｐ管理テーブルは、Ｄｏｍａｉｎ Ｇｒｏｕｐ番号４０１、サーバ構成４０２、Ｄｒｉｖｅ Ｂｏｘ構成４０３とで構成される。Ｄｏｍａｉｎ Ｇｒｏｕｐ番号４０１には、Ｄｏｍａｉｎ Ｇｒｏｕｐの識別子を格納する。サーバ構成４０２には、当該Ｄｏｍａｉｎ Ｇｒｏｕｐに属するサーバの識別子を格納する。Ｄｒｉｖｅ Ｂｏｘ構成４０３には、当該Ｄｏｍａｉｎ Ｇｒｏｕｐに属するＤｒｉｖｅ Ｂｏｘの識別子を格納する。

【0018】

図６は、本実施例における、Ｄｒｉｖｅ Ｂｏｘに搭載された複数台のドライブの領域管理方法の一例である。本実施例では、Ｄｒｉｖｅ Ｂｏｘに搭載された複数台のドライブをＣｈｕｎｋ５０１と呼ぶ複数個の固定サイズ領域に分割して管理する。

【0019】

図７は、Ｃｈｕｎｋ Ｇｒｏｕｐ管理テーブル６００の構成例である。Ｃｈｕｎｋ Ｇｒｏｕｐ管理テーブルは、ＲＡＩＤ構成を組むＣｈｕｎｋの組み合わせを管理する。Ｃｈｕｎｋ Ｇｒｏｕｐ管理テーブルは、Ｃｈｕｎｋ Ｇｒｏｕｐ番号６０１、データ冗長度６０２、Ｃｈｕｎｋ構成６０３、ＦＢＯＦ復旧可否フラグ６０４で構成される。Ｃｈｕｎｋ Ｇｒｏｕｐ番号６０１には、Ｃｈｕｎｋ Ｇｒｏｕｐの識別子を格納する。データ冗長度６０２には、Ｃｈｕｎｋ Ｇｒｏｕｐが示すデータ保護方法を格納する。Ｃｈｕｎｋ構成６０３には、ＲＡＩＤ構成を組むＣｈｕｎｋの組み合わせを格納する。例えばＣｈｕｎｋ Ｇｒｏｕｐ＃０００は、４個のＣｈｕｎｋ（Ｃ１１、Ｃ２１、Ｃ３１、Ｃ４１）を使って、ＲＡＩＤ５（３Ｄ＋1Ｐ）で保護されることを示している。ＦＢＯＦ復旧可否フラグ６０４には、ＦＢＯＦにてデータ復旧可能か否かを示すフラグであり、ＯＫ／ＮＧのいずれかを格納する。

【0020】

図８は、ページマッピングテーブル７００と空きページ管理テーブル７１０の構成例である。本実施例では、一般的な分散ストレージ同様、ＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ）と呼ぶ単位でアプリに書き込み領域を提供する。各Ｃｈｕｎｋの領域は、Ｃｈｕｎｋよりも小さい固定サイズ領域（以下、ページ）で管理され、ＬＵの領域と対応づけられる。ページマッピングテーブルは、ＬＵの領域とＣｈｕｎｋの領域との対応関係を管理する。尚、本実施例では、ＬＵ作成時、ＬＵの全領域に、対応するページを割り当てる想定で記載をしているが、Ｔｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇと呼ぶ汎用技術を用いて、特定領域にのみページを割り当てても構わない。

【0021】

ページマッピングテーブル７００は、ＬＵ番号７０１、部分領域先頭アドレス７０２、Ｃｈｕｎｋ番号７０３、Ｃｈｕｎｋ内オフセット７０４で構成される。ＬＵ番号７０１には、アプリに提供するＬＵの識別子を格納する。部分領域先頭アドレス７０２には、ページのサイズで分割した部分領域の先頭アドレスを格納する。Ｃｈｕｎｋ番号７０３とＣｈｕｎｋ内オフセット７０４には、各部分領域に割り当てるページの領域情報を格納する。

【0022】

空きページ管理テーブル７１０は、各サーバが別サーバと通信することなく、ＬＵに割り当て可能なページ群（空きページ）を管理するテーブルである。Ｃｈｕｎｋ Ｇｒｏｕｐ番号７１１とＣｈｕｎｋ Ｇｒｏｕｐ内オフセット７１２には、各空きページの領域情報を格納する。当該空きページは、代表サーバによって、各サーバに割り当てが行われ、当該テーブルに追加される。また、ＬＵ作成時に割り当てた空きページは、当該テーブルから削除する。あるサーバの空きページが不足する場合は、代表サーバによって、新しいＣｈｕｎｋ Ｇｒｏｕｐが作成され、Ｃｈｕｎｋ Ｇｒｏｕｐ内の領域が、新たな空きページとして追加される。
ＬＵ作成時のページ割当て制御や、空きページ制御のシーケンスの詳細については、記載を省略する。

【0023】

図９は、本発明における、ページマッピングテーブル、空きページ管理テーブル、Ｃｈｕｎｋ Ｇｒｏｕｐ管理テーブルの各サーバへの配置方法の一例である。まず各サーバは、ＬＵに関連するページマッピングテーブルと空きページ管理テーブルについて、自身で稼働中のアプリが使用するＬＵの情報のみを所有をする。ページマッピングテーブルを全サーバで共有すると、各サーバが所有するメタデータ量が肥大化し、テーブル更新に時間がかかり、スケーラビリティに影響を与えるためである。サーバ障害時のメタデータ消失に対応するため、ページマッピングテーブルは、分散ストレージシステムを構成する別のサーバにバックアップしておく。また、後述のデータ復旧機能は、サーバとＤｒｉｖｅ Ｂｏｘの両方が有する（９００、９０１）。

【0024】

一方、Ｃｈｕｎｋ Ｇｒｏｕｐ管理テーブルは、分散ストレージシステムを構成する、ストレージ制御ソフトが稼働しているサーバ間で同期し、全てのサーバで同一の構成情報を参照可能にする。これにより、アプリとＬＵとを別サーバに移動する時に、データやパリティを再構成することなく、データコピーなしで移動でき、移動先サーバでもデータ保護を継続することが可能となる。
本発明のストレージシステムは、各ＦＢＯＦに搭載される全てのドライブの状態を監視し、状態管理することができる。ドライブ状態は「正常」「障害」のいずれかを管理する。システムは、定期的に各ドライブ状態を監視し、「正常」「障害」を最新に保つ。

【0025】

実施例１では、単一ＦＢＯＦにデータを格納する構成において、ＦＢＯＦ内のいずれかのドライブに障害が発生する場合に、ストレージコントローラとＦＢＯＦコントローラとが連携してＦＢＯＦ内部でデータ復旧し、復旧結果となるデータのみをＦＢＯＦからサーバに転送する方法を開示する。当該方法により、データ復旧時のネットワークの読出しコストを抑え、システム性能を安定化することができる。

【0026】

図１０は、本実施例において、ＦＢＯＦに搭載する各ドライブの領域管理方法に関する構成図である。ＦＢＯＦに搭載する各ドライブは、Ｃｈｕｎｋと呼ぶ固定長の単位で分割管理する。ストレージコントローラは、複数個のＣｈｕｎｋを異なるドライブから選択し、Ｃｈｕｎｋ間でデータを冗長化する。選択した複数個のＣｈｕｎｋを、Ｃｈｕｎｋ Ｇｒｏｕｐと呼ぶ。

【0027】

本構成図では、４Ｄ２Ｐのデータ冗長化方式を例に詳細を示す。４Ｄ２Ｐの場合、ストレージコントローラは、同一ＦＢＯＦに搭載する異なるデバイスの中から６個のＣｈｕｎｋ（それぞれＤ１、Ｄ２、Ｄ３、Ｄ４、Ｐ１、Ｐ２とラベル付けする）を選択し、Ｃｈｕｎｋ Ｇｒｏｕｐを構成する。当該Ｃｈｕｎｋ Ｇｒｏｕｐでは、Ｄ１、Ｄ２、Ｄ３、Ｄ４の領域にデータを格納する。また、当該データ群を用いて２個のパリティを作成し、Ｐ１、Ｐ２の領域に格納する。パリティの作成方法は、従来ＲＡＩＤ６の手法と同様の手法を利用できる。このため、本実施例では詳細を省略する。

【0028】

尚、本実施例の構成は、データ冗長度方式に依存しない。すなわち任意のデータ数・パリティ数でＣｈｕｎｋ Ｇｒｏｕｐを構成することが可能であり、例えば６Ｄ１Ｐのデータ方式を採用したとしても、同様の効果を得ることが可能である。

【0029】

図１１は、本実施例における、Ｃｈｕｎｋ Ｇｒｏｕｐ作成プログラムの構成例である。Ｃｈｕｎｋ Ｇｒｏｕｐ作成プログラムは、データが冗長化される新しいデータ格納領域（Ｃｈｕｎｋ Ｇｒｏｕｐ）を提供するプログラムである。当該プログラムは、ストレージシステムのデータ格納領域が不足する契機で、ストレージコントローラにより実行される。本実施例では、ＦＢＯＦ内でデータ復旧を行えるように、単一個のＦＢＯＦ内の異なるドライブから必要数のＣｈｕｎｋを選択し、Ｃｈｕｎｋ Ｇｒｏｕｐを作成する。

【0030】

まず、Ｃｈｕｎｋ Ｇｒｏｕｐ作成プログラムは、ストレージコントローラに設定されたデータ冗長化方式を確認する（例：４Ｄ２Ｐ）（１００１）。次に、Ｃｈｕｎｋ Ｇｒｏｕｐを作成するＦＢＯＦを選択する（１００２）。ＦＢＯＦ選択方法は様々な方法がある。例えば、空きＣｈｕｎｋ数が少ないＦＢＯＦを選択する方法があるが、この限りではない。次に、データ冗長化方式で指定する台数のドライブから（４Ｄ２Ｐの場合は６個）、それぞれ、いずれのＣｈｕｎｋ Ｇｒｏｕｐにも属していないＣｈｕｎｋを選択し（１００３）、新規Ｃｈｕｎｋ Ｇｒｏｕｐを構成する（１００４）。

【0031】

（１００３）において、Ｃｈｕｎｋ Ｇｒｏｕｐを構成するＣｈｕｎｋを選択できなかった場合、別のＦＢＯＦを選択し、Ｃｈｕｎｋ Ｇｒｏｕｐの作成を試みる。全てのＦＢＯＦについて、Ｃｈｕｎｋ Ｇｒｏｕｐを作成できなかった場合、複数個のＦＢＯＦに属するドライブからＣｈｕｎｋを選択し（１００６）、Ｃｈｕｎｋ Ｇｒｏｕｐを作成する。このように作成したＣｈｕｎｋ Ｇｒｏｕｐは、ＦＢＯＦ側で完全なデータ復旧を行うことができないため、Ｃｈｕｎｋ Ｇｒｏｕｐテーブルにて、当該Ｃｈｕｎｋ ＧｒｏｕｐのＦＢＯＦ復旧可否フラグにＮＧを書込み、ＦＢＯＦを跨がない場合（ＯＫ）と区別可能にする。

【0032】

図１２は、本実施例におけるライトプログラムの構成例である。ライトプログラムは、ライトデータの書込み先となるＣｈｕｎｋ Ｇｒｏｕｐの構成情報に従い、データに対応するパリティを作成し、データとパリティとを適切なドライブに書込むことで、書込みデータを冗長化するプログラムである。

【0033】

まず、ストレージシステム内のいずれかのサーバのストレージコントローラが、ホストからのライト要求を受領する。ストレージコントローラは、当該データのオーナー権を有するストレージコントローラに、ライト要求を転送する（１１０１）。転送先ストレージコントローラは、適切にライト処理を行い、ライト結果を転送元ストレージコントローラに応答する。最後に、転送元ストレージコントローラが、ライト結果をホストに応答する（１１０６）。

【0034】

ライト処理を行うストレージコントローラは、要求されたライトサイズが、ストライプサイズを超えるか否かを判定する（１１０２）。ライトサイズがストライプサイズ以上の場合、ストレージコントローラはフルストライプライトを行う。フルストライプライトでは、まず、ストレージコントローラがページマッピングテーブルを参照し、書込み先アドレスに対応するＣｈｕｎｋ番号とオフセットの組を確認する（１１０３）。次に、ライトデータ（Ｄ１、Ｄ２、Ｄ３、Ｄ４）からパリティ（Ｐ１、Ｐ２）を計算し（１１０４）、それぞれ、Ｃｈｕｎｋ番号/オフセットに対応するドライブ番号/オフセットにＤ１～Ｄ４、Ｐ１、Ｐ２を書き込む（１１０５）。

【0035】

ライトサイズがストライプサイズを超えない場合、ストレージコントローラは部分ライトを行う。部分ライトは、まず、ストレージコントローラがページマッピングテーブルを参照し、書込み先アドレスに対応するＣｈｕｎｋ番号とオフセットの組を確認する。説明の都合上、確認の結果、Ｄ１とラベル付けされた領域へのライトであったとする。この場合、ストレージコントローラは、Ｄ１、Ｐ１、Ｐ２の書込み先アドレスに格納されたデータ・パリティを読み出し（１１０７）、パリティ計算を行い（１１０４）、それぞれ、Ｃｈｕｎｋ番号/オフセットに対応するドライブ番号/オフセットにＤ１、Ｐ１、Ｐ２を書き込む（１１０５）。

【0036】

図１３は、本実施例における、リードプログラムの一例である。リードプログラムは、リード対象領域のＣｈｕｎｋ Ｇｒｏｕｐの構成情報に従い、ドライブからデータを読み出すプログラムである。特に、読出し対象のドライブに障害があった場合は、ＦＢＯＦ内部でデータ復旧し、復旧結果となるデータのみをＦＢＯＦからサーバに転送する。

【0037】

まず、ストレージシステム内のいずれかのサーバのストレージコントローラが、ホストからのリード要求を受領する。ストレージコントローラは、当該データのオーナー権を所有するストレージコントローラにリード要求を転送する（１２０１）。転送要求を受領したストレージコントローラは、適切にリード処理を行い、リード結果を転送元ストレージコントローラに応答する。最後に、転送元ストレージコントローラが、リード結果をホストに応答する（１２０５）。

【0038】

リード処理を行うストレージコントローラは、まず、ページマッピングテーブルを参照し、読出し先アドレスに対応するＣｈｕｎｋ番号とオフセットの組を確認する（１２０２）。次に、確認したＣｈｕｎｋ番号が格納されているドライブの障害状態を確認する（１２０３）。全てのドライブの障害状態が「正常」の場合、ストレージコントローラは、Ｃｈｕｎｋ番号/オフセットに対応するドライブ番号/オフセットデータを読み出してホストに応答する（１２０４、１２０５）。

【0039】

障害状態が「障害」のドライブを含む場合、ストレージコントローラは、ＦＢＯＦにてデータ復旧してデータを読出せるかを判定する（１２０６）。要求されたリードサイズが、ストライプサイズ以上で、ＦＢＯＦ復旧可否フラグがＯＫの場合にデータ復旧可能と判定する。データ復旧が可能な場合、ストレージコントローラはＦＢＯＦコントローラに対し、データ復旧付き読出し要求を発行する（１２０７）。データ復旧付き読出し要求には、障害箇所を含む読出しアドレス（前記ドライブ番号とオフセット）と読出し量（読出し範囲）の他、データ復旧時の復旧方法（対応するパリティの位置と符号化方式（ＸＯＲ等））を含める。

【0040】

データ復旧付き読出し要求を受領したＦＢＯＦコントローラは、指定された読出し範囲のデータをドライブから読出し、リードバッファに格納する（１２０８）。その後、ＦＢＯＦコントローラは、自身の稼働率情報を確認し、データ復旧付き読み出し処理を受領可能か判定する（１２０９）。稼働率情報には、ＦＢＯＦコントローラのＣＰＵ稼働率やリードバッファ使用率、メモリ帯域使用率などの一般的な情報を用いることができる。前記の稼働率/使用率が一定閾値より低く、受領可能と判断した場合、ドライブ障害で読み出すことができなかったデータを、リードバッファ内に読出したデータから復旧する（１２１０、９０１）。この時、データ復旧方法はストレージコントローラが指定した復旧方式を用いる。例えばパリティ位置のデータを読み出し、既にリードバッファに読み出したデータとのＸＯＲを計算することでデータ復旧する。データ復旧の結果、要求された全てのデータが準備できた契機で、ＦＢＯＦコントローラが、当該データをストレージコントローラに応答する。

【0041】

１２０６にてＦＢＯＦでのデータ復旧が不可と判断した場合、ＦＢＯＦコントローラに対して、復旧なしの読み出し要求を発行する（１２１１）。当該読み出し要求には、読出しアドレスと読出し量（前記ドライブ番号とオフセット）と、パリティの位置を含む。読出し要求を受領したＦＢＯＦコントローラは、障害ドライブを除くドライブからデータおよびパリティを読み出してリードバッファに格納する（１２１２）。その後、ＦＢＯＦコントローラがストレージコントローラにデータおよびパリティを転送し、ストレージコントローラが前記パリティを使ってデータを復旧する（１２１３、９００）。１２０９にてＦＢＯＦでのデータ復旧が不可と判断した場合も同様に、ＦＢＯＦコントローラがストレージコントローラにデータを転送し、「復旧失敗」を応答し、ストレージコントローラがデータを復旧する。

【0042】

図１４は、本実施例における、データ復旧（リビルド）プログラムの構成例である。データ復旧プログラムは、ドライブ障害が発生した契機で、ストレージコントローラによって実行されるプログラムであり、障害ドライブのデータを復旧した後、指定された領域に復旧データを書込む。

【0043】

まず、いずれかのストレージコントローラが、ＦＢＯＦ内のドライブの障害を検知する（１３０１）。一定時間後、もしくはユーザ指示に応じて、ストレージコントローラは、障害発生したドライブのデータ復旧を開始する（１３０２）。ストレージコントローラは、障害影響あるＣｈｕｎｋに別の空きＣｈｕｎｋを割当てる（１３０３）。ストレージコントローラは、障害ドライブにＣｈｕｎｋの各アドレスについて、障害ドライブを搭載するＦＢＯＦのＦＢＯＦコントローラに対して、データ復旧要求を繰り返し発行する（１３０４）。データ復旧要求には、データ復旧に必要なアドレス情報の組と、復旧データの書き込み先アドレスと、復旧方法とを含む。ＦＢＯＦコントローラは、指定されたデータおよびパリティをリードバッファに読出し（１３０５）、指定された方式でデータを復旧し、復旧結果を指定された領域に書き込む（１３０６）。
このデータ復旧プログラムの処理においても、図１３と同様に、ＦＢＯＦコントローラによるデータの復旧が可能である。なお、冗長化したデータが複数のＦＢＯＦに分散している場合には、図１３と同様に、ストレージコントローラによるデータの復旧を行う。また、ＦＢＯＦの稼働率に応じて、ストレージコントローラでデータの復旧を行ってもよい。

【0044】

以上、単一ＦＢＯＦにデータを格納する構成において、ＦＢＯＦ内のいずれかのドライブに障害が発生する場合に、ストレージコントローラとＦＢＯＦコントローラとが連携してＦＢＯＦ内部でデータ復旧し、復旧結果となるデータのみをＦＢＯＦからサーバに転送する方法を示した。

【実施例0045】

実施例２では、複数ＦＢＯＦにデータを分割格納する構成において、ＦＢＯＦ内のいずれかのドライブに障害が発生している場合でも、ストレージコントローラとＦＢＯＦコントローラとが連携し、ＦＢＯＦ内部でデータ復旧し、復旧結果となるデータのみをＦＢＯＦからサーバに転送する方法を開示する。当該方法により、実施例１と比べた信頼性を高めつつ、データ復旧時のネットワークの読出しコストを抑え、システム性能を安定化することができる。

【0046】

図１５は、本実施例における、ＦＢＯＦに搭載する各ドライブの領域管理方法に関する構成図である。実施例１同様、ＦＢＯＦに搭載する各ドライブはＣｈｕｎｋ単位で領域管理する。実施例１との相違点として、実施例２のストレージコントローラは、複数個のＦＢＯＦ内のドライブからＣｈｕｎｋを選択してＣｈｕｎｋ Ｇｒｏｕｐを作成し、ＦＢＯＦ間でデータを冗長化する。

【0047】

実施例２のＣｈｕｎｋ Ｇｒｏｕｐは、ＦＢＯＦコントローラが、自身に搭載されたドライブのデータのみからデータ復旧可能にするため、二種類のパリティを格納できるよう構成する。第一のパリティは、単一ＦＢＯＦ内に搭載されたデバイスに格納するデータから作成したパリティであり、ローカルパリティ（ＬＰ）と呼ぶ。第二のパリティは、異なるＦＢＯＦに搭載されたデバイスに格納するデータから作成したパリティであり、グローバルパリティ（ＧＰ）と呼ぶ。

【0048】

二種類のパリティを格納可能にすることで、障害ドライブが１台の場合は、ローカルパリティを用いてＦＢＯＦ内でデータ復旧でき、ローカルパリティでデータ復旧できない場合は、ストレージコントローラでグローバルパリティを用いてデータ復旧できる。当該方式により、信頼性向上とネットワーク・コスト低減とを両立することが可能となる。

【0049】

以降、ローカルパリティとグローバルパリティとを用いたデータ冗長化方式を(Ｌ、Ｍ、Ｎ)方式と定義する。(Ｌ、Ｍ、Ｎ)方式では、Ｌ＋Ｍ＋Ｎ個のＣｈｕｎｋを選択してＣｈｕｎｋ Ｇｒｏｕｐを構成する。Ｃｈｕｎｋ Ｇｒｏｕｐを構成するＣｈｕｎｋのうち、Ｌ個にはデータを、Ｍ個にはローカルパリティを、Ｎ個にはグローバルパリティを格納する。Ｃｈｕｎｋ Ｇｒｏｕｐは、Ｍ＋Ｎ個のＦＢＯＦに分割配置し、Ｍ個のＦＢＯＦにはそれぞれＬ÷Ｍ個、Ｎ個のＦＢＯＦにはそれぞれ１個のＣｈｕｎｋを配置する。

【0050】

本構成図では、(４、２、１)方式を例に詳細を示す。(４、２、１)方式の場合、ストレージコントローラは、３個のＦＢＯＦから、それぞれ３個/３個/１個のＣｈｕｎｋ（それぞれＤ１、Ｄ２、Ｄ３、Ｄ４、ＬＰ１、ＬＰ２、ＧＰ１とラベル付けする）を選択し、Ｃｈｕｎｋ Ｇｒｏｕｐを構成する。

【0051】

各ＦＢＯＦには、以下のようにＣｈｕｎｋを配置する。まず、１個目のＦＢＯＦに、Ｄ１、Ｄ２、ＬＰ１を配置する。ＬＰ１は、Ｄ１、Ｄ２とで構成したパリティを格納する領域である。同様に、Ｄ３、Ｄ４、ＬＰ２を２個目のＦＢＯＦに配置する。ＬＰ２は、Ｄ３、Ｄ４とで構成したパリティを格納する領域である。ＧＰ１は、３個目のＦＢＯＦ内に配置する。ＧＰ１は、Ｄ１、Ｄ２、Ｄ３、Ｄ４とで構成したパリティを格納する領域である。

【0052】

尚、本実施例の構成は、データ冗長度方式に依存しない。すなわち任意のデータ数・パリティ数でＣｈｕｎｋ Ｇｒｏｕｐを構成することが可能であり、例えば(６、２、２)方式のデータ方式を採用したとしても、同様の効果を得ることが可能である。(６、２、２)方式の場合、４個のＦＢＯＦに、（Ｄ１、Ｄ２、Ｄ３、ＬＰ２）（Ｄ１、Ｄ２、Ｄ３、ＬＰ２）（ＧＰ１）（ＧＰ２）のように配置すればよい。

【0053】

図１６は、本実施例における、Ｃｈｕｎｋ Ｇｒｏｕｐ作成プログラムの構成例である。実施例２の、Ｃｈｕｎｋ Ｇｒｏｕｐ作成プログラムは、複数個のＦＢＯＦ内の異なるドライブからＣｈｕｎｋを選択し、Ｃｈｕｎｋ Ｇｒｏｕｐを作成する。

【0054】

まず、Ｃｈｕｎｋ Ｇｒｏｕｐ作成プログラムは、ストレージコントローラに設定された、データ冗長化方式を確認する（例：(４、２、１)方式）（１５０１）。次に、Ｃｈｕｎｋ Ｇｒｏｕｐを作成するＦＢＯＦをＭ＋Ｎ個（ (４、２、１)方式では３個）のＦＢＯＦを選択する（１５０２）。ＦＢＯＦの選択方法は、実施例１で説明した方法を用いることができる。次に、データ冗長化方式で指定する台数のドライブから、それぞれ、いずれのＣｈｕｎｋ Ｇｒｏｕｐにも属していないＣｈｕｎｋを必要個数分選択し（１５０３）、新規Ｃｈｕｎｋ Ｇｒｏｕｐを構成する（１５０４）。

【0055】

（１５０３）において、Ｃｈｕｎｋ Ｇｒｏｕｐを構成できなかった場合、別のＦＢＯＦを選択し、Ｃｈｕｎｋ Ｇｒｏｕｐを作成する。全てのＦＢＯＦについて、Ｃｈｕｎｋ Ｇｒｏｕｐを作成できなかった場合、Ｍ＋Ｎ個を超えるＦＢＯＦに属するドライブからＣｈｕｎｋを選択し（１５０５）、Ｃｈｕｎｋ Ｇｒｏｕｐを作成する。このように作成したＣｈｕｎｋ Ｇｒｏｕｐは、ＦＢＯＦ側で完全なデータ復旧を行うことができないため、ＦＢＯＦ復旧可否フラグにＮＧを書込み、区別可能にする。

【0056】

図１７は、本実施例におけるライトプログラムの一例である。実施例２のライトプログラムは、データに対応するローカルパリティとグローバルパリティとを作成し、データとローカルパリティ、グローバルパリティとを適切なドライブに書込むことで、書込みデータを冗長化するプログラムである。

【0057】

ライト処理を行うストレージコントローラは、要求されたライトサイズが、ストライプサイズを超えるか否かを判定する（１６０３）。ライトサイズがストライプサイズを超える場合、ストレージコントローラはフルストライプライトを行う。Ｃｈｕｎｋ Ｇｒｏｕｐ管理テーブルを参照し、書込み先アドレスに対応するＣｈｕｎｋ番号、Ｏｆｆｓｅｔ番号を確認する。次に、Ｄ１、Ｄ２からなるローカルパリティ（ＬＰ１）と、Ｄ３、Ｄ４からなるローカルパリティ（ＬＰ２）とを作成する。また、Ｄ１、Ｄ２、Ｄ３、Ｄ４からなるグローバルパリティ（ＧＰ１）を作成する（１６０４）。ストレージコントローラは、新データ、ローカルパリティ（ＬＰ２）、ローバルパリティ（ＧＰ１）を対応する領域に書き込む（１６０５５）。その後、ストレージコントローラは、ライト結果を応答し（１６０６）、処理を終了する。

【0058】

ライトサイズがストライプサイズを超えない場合、ストレージコントローラは部分ライトを行う。部分ライトは、まず、ストレージコントローラがＣｈｕｎｋ Ｇｒｏｕｐ管理テーブルを参照し、書込み先アドレスに対応するＣｈｕｎｋ番号とオフセットの組を確認する。説明の都合上、確認の結果、Ｄ１とラベル付けされた領域へのライトであったとする。この場合、ストレージコントローラは、Ｄ１、ＬＰ１、ＧＰ１の書込み先アドレスに格納されたデータ・パリティを読み出し（１６０７）、パリティ計算を行い（１６０４）、それぞれ、Ｃｈｕｎｋ番号/オフセットに対応するドライブ番号/オフセットにＤ１、ＬＰ１、ＧＰ１を書き込む（１６０５）。その後、ストレージコントローラは、ライト結果を応答し（１６０６）、処理を終了する。

【0059】

図１８は、本実施例における、リードプログラムの一例である。ドライブ状態が全て「正常」の場合は、実施例１のリードプログラムと同一の方法でデータを読み出すことができるため、記載は省略する。

【0060】

読出し範囲に障害状態が「障害」のドライブを含む場合、ストレージコントローラは、ＦＢＯＦにてデータ復旧してデータを読出せるかを判定する（１７０６）。要求されたリードサイズが、（ストライプサイズ÷Ｍ）以上で、障害ドライブが１台で、かつ、ＦＢＯＦ復旧可否フラグがＯＫの場合にデータ復旧可能と判定する（１７０７）。データ復旧が可能な場合、ストレージコントローラはＦＢＯＦコントローラに対し、データ復旧付き読出し要求を発行する。データ復旧付き読出し要求には、障害箇所を含む読出しアドレス（前記ドライブ番号とオフセット）と読出し量（読出し範囲）の他、データ復旧時の復旧方法（対応するパリティの位置と符号化方式（ＸＯＲ等））を含む。

【0061】

データ復旧付き読出し要求を受領したＦＢＯＦコントローラは、指定された読出し範囲のデータをドライブから読出し、リードバッファに格納する（１７０８）。その後、自身の稼働率情報を確認し、データ復旧付き読み出し処理を受領可能か判定する（１７０９）。稼働率情報には、ＦＢＯＦコントローラのＣＰＵ稼働率やリードバッファ使用率、メモリ帯域使用率などの一般的な情報を用いることができる。前記の稼働率/使用率が一定閾値より低く、受領可能と判断した場合、ドライブ障害で読み出すことができなかったデータを、リードバッファ内に読出したデータから復旧する（１７１０）。データ復旧にはローカルパリティを用い、データ復旧方法はストレージコントローラが指定した復旧方式を用いる。１７０９にて、受領不可と判断した場合、ＦＢＯＦコントローラは、ストレージコントローラに「復旧失敗」を応答し、読みだせたデータのみを応答する。この場合、ストレージコントローラが、復旧に必要なデータとグローバルパリティを追加で読み出し、データ復旧を行い（１７１３）、ホストに応答する。

【0062】

図１９は、本実施例における、データ復旧（リビルド）プログラムの構成例である。データ復旧プログラムは、ドライブ障害が発生した契機で、ストレージコントローラによって実行されるプログラムであり、障害ドライブのデータを復旧した後、指定された領域に復旧データを書込む。

【0063】

まず、いずれかのストレージコントローラが、ＦＢＯＦ内のドライブの障害を検知する（１８０１）。一定時間後、もしくはユーザ指示に応じて、ストレージコントローラは、障害発生したドライブのデータ復旧を開始する（１８０２）。ストレージコントローラは、障害影響あるＣｈｕｎｋに別の空きＣｈｕｎｋを割当てる（１８０３）。ストレージコントローラは、障害ドライブにＣｈｕｎｋの各アドレスについて、障害ドライブを搭載するＦＢＯＦのＦＢＯＦコントローラに対して、データ復旧要求を繰り返し発行する（１８０４）。データ復旧要求には、データ復旧に必要なアドレス情報の組と、復旧データの書き込み先アドレスと、復旧方法とを含む。ＦＢＯＦコントローラは、指定されたデータおよびローカルパリティをリードバッファに読出し（１８０５）、指定された方式でデータを復旧し、復旧結果を指定された領域に書き込む（１８０６）。
このデータ復旧プログラムの処理においても、図１８と同様に、ＦＢＯＦコントローラによるデータの復旧が可能である。なお、冗長化したデータが複数のＦＢＯＦに分散している場合には、図１８と同様に、ストレージコントローラによるデータの復旧を行う。また、ＦＢＯＦの稼働率に応じて、ストレージコントローラでデータの復旧を行ってもよい。

【0064】

図２０は、復旧可否変更プログラムの構成例である。復旧可否変更プログラムは、リードプログラム１２００・１７００やデータ復旧プログラム１１００・１６００で実施する、ＦＢＯＦコントローラでの復旧可否判断を、コントローラやＦＢＯＦ以外（例えば、管理サーバ１０５）で実施し、ＦＢＯＦに設定するプログラムである。

【0065】

まず、管理サーバ１０５が、各ＦＢＯＦのＣＰＵ稼働率やリードバッファ使用率、メモリ帯域使用率などを定期的に収集する（１９０１）。その後、収集した情報を基に各ＦＢＯＦが過負荷か否かを判断し、復旧可否を決定する（１９０２）。例えば、ＦＢＯＦの稼働率が一定未満の場合は復旧可、一定以上である場合は復旧否と決定する。最後に、決定した復旧可否情報をＦＢＯＦに設定する（１９０３）。ＦＢＯＦは、当該設定値に基づいて復旧可否を判断する。

【0066】

尚、復旧可否判断は、ユーザが手動で設定することも可能である。この場合、管理サーバが復旧可否判断を手動入力するインターフェースを備え、当該インターフェースへのユーザ入力値をＦＢＯＦに設定する。

【0067】

以上、複数ＦＢＯＦにデータを格納する構成においても、ＦＢＯＦ内のいずれかのドライブに障害が発生する場合に、ストレージコントローラとＦＢＯＦコントローラとが連携してＦＢＯＦ内部でデータ復旧し、復旧結果となるデータのみをＦＢＯＦからサーバに転送する方法を示した。

【0068】

以上、本発明の実施形態を説明したが、本発明が上記の実施形態に限定されるものではない。当業者であれば、上記の実施形態の各要素を、本発明の範囲において容易に変更、追加、変換することが可能である。

【0069】

上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

【0070】

上述してきたように、開示のストレージシステムは、１つ又は複数のストレージユニット（ドライブボックス１０６）と、１つ又は複数のストレージユニットに通信ネットワーク（ネットワーク１０４）を介して接続された計算機（サーバ１０１、コントローラ２５０１）とを備える。
前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイス（ドライブ２０４）と、プロセッサ２０１と、を有する。
また、前記計算機は、プロセッサ２０１によって、前記ストレージユニットに入出力するデータを処理するコントローラを有する。
前記ストレージシステムは、前記データを冗長化して格納し、一部の前記物理ドライブからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理ドライブからデータを読み出し、読み出したデータから前記リード要求にかかるデータを復旧させ、前記リード要求の要求元に前記復旧させたデータを送信する。
この前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能である。
このように、冗長構成を計算機で管理し、コントローラで修復と、ストレージユニットで修復の二通りが可能であるので、ストレージユニットの負荷を抑えつつ、ネットワーク転送量を低減することができる。

【0071】

具体的には、前記計算機のコントローラがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記計算機に送信し、前記コントローラが前記送信された複数のデータから前記リード要求にかかるデータを復旧する。
一方、前記ストレージユニットのプロセッサがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記リード要求にかかるデータを復旧し、前記復旧させたデータを計算機に送信する。
このように、計算機のコントローラがデータ復旧処理を行う場合にはストレージユニットの負荷を抑制し、ストレージユニットのプロセッサがデータ復旧処理を行う場合にはネットワーク転送量を削減することができる。

【0072】

また、前記計算機のコントローラは、前記障害が発生している物理記憶デバイスについてのリード要求を受信した場合に、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかを決定し、前記決定を、前記リード要求とともに、前記ストレージユニットに送信する。
このため、状況に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。

【0073】

また、前記冗長化には、１のストレージユニット内のデータでデータ復旧を可能にする第１の冗長化と、複数のストレージユニット内のデータでデータ復旧を可能にする第２の冗長化と、の両方が含まれており、前記計算機のコントローラは、前記第１の冗長化と前記第２の冗長化のいずれでデータ復旧を行うかと、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかと、を決定する。
このように、ローカルパリティによる第１の冗長化とグローバルパリティによる第２の冗長化を用いることで、信頼性を高めつつ、データ復旧時のネットワークの読出しコストを抑え、システム性能を安定化することができる。

【0074】

また、前記計算機のコントローラは、前記第１の冗長化でデータ復旧を行う場合には、前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、前記第２の冗長化でデータ復旧を行う場合には、前記計算機のコントローラが前記データ復旧処理を行うと決定する。
前記計算機のコントローラは、前記第１の冗長化でデータ復旧が可能かどうかを判断し、可能な場合には、前記第１の冗長化を用いて前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、可能ではない場合には、前記第２の冗長化を用いて前記計算機のコントローラが前記データ復旧処理を行うと決定する。
このため、データの所在に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。

【0075】

また、前記ストレージユニットは、前記障害が発生している物理記憶デバイスについてのリード要求を受信した場合に、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかを、前記ストレージユニットの負荷状況に基づいて決定する。
このため、ストレージユニットの負荷に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。