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

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

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

(11)【公開番号】P2023055998

(43)【公開日】2023-04-18

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

(51)【国際特許分類】

   G06F 3/06 20060101AFI20230411BHJP

【ＦＩ】

G06F3/06 304E

【審査請求】有

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2023021560

(22)【出願日】2023-02-15

(62)【分割の表示】P 2021055362の分割

【原出願日】2021-03-29

(71)【出願人】

【識別番号】000005108

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

(74)【代理人】

【識別番号】110001678

【氏名又は名称】藤央弁理士法人

(72)【発明者】

【氏名】別納 健市

(72)【発明者】

【氏名】長尾 尚

(72)【発明者】

【氏名】清田 雄策

(72)【発明者】

【氏名】吉原 朋宏

(57)【要約】

【課題】複数のコントローラから構成され、追記型データ格納方式を採用するストレージシステムにおいて、障害発生時におけるデータの一貫性を確保しつつ高いＩ／Ｏ処理性能を実現する。
【解決手段】メタデータの二重化に先立ち、ロールフォワードまたはロールバックを実施するために必要な情報を含んだリカバリデータを各コントローラに格納してから、メタデータの二重化を行う。また、リカバリデータの格納処理とメタデータの二重化をハードウェアアクセラレータにオフロードする。
【選択図】図２

【特許請求の範囲】

【請求項1】

複数のストレージ制御部と、アクセラレータと、データを格納する記憶媒体を有するストレージドライブと、を有するストレージシステムであって、
前記複数のストレージ制御部の各々は、プロセッサと、メモリと、を有し、
前記複数のストレージ制御部のうち第１のストレージ制御部の前記メモリ及び前記複数のストレージ制御部のうち第２のストレージ制御部の前記メモリには、それぞれ、前記ストレージドライブに格納されたデータにアクセスするためのメタデータが保持され、
前記格納されたデータを更新する書き込み要求を受信した場合に、
前記第１のストレージ制御部の前記プロセッサは、
更新されるデータのデータ量削減処理を実行し、
前記更新されるデータにかかるメタデータを前記データ量削減処理により更新し、
前記更新したメタデータの処理要求を前記アクセラレータに送信し、
前記アクセラレータは、
前記処理要求に基づいて、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記メタデータを格納することを特徴とするストレージシステム。

【請求項2】

請求項１に記載のストレージシステムであって、
前記第１のストレージ制御部の前記プロセッサは、前記メタデータとともに前記メタデータの一貫性を回復するための情報を含むリカバリデータ及びその処理要求を前記アクセラレータに送信し、
前記アクセラレータは、前記処理要求に基づいて、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記リカバリデータを格納することを特徴とするストレージシステム。

【請求項3】

請求項２に記載のストレージシステムであって、
前記アクセラレータは、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記メタデータを格納した後に、前記第１のストレージ制御部の前記メモリの前記リカバリデータ及び前記第２のストレージ制御部の前記メモリの前記リカバリデータを無効にし、
前記第１のストレージ制御部の前記プロセッサ及び前記第２のストレージ制御部の前記プロセッサは、前記メタデータの少なくとも一部の前記メモリへの格納が正常に終了しなかった場合、有効である前記リカバリデータに基づいて、前記メタデータの一貫性を回復することを特徴とするストレージシステム。

【請求項4】

請求項３に記載のストレージシステムであって、
前記リカバリデータは、前記メタデータを更新された後の状態に回復するための情報を含み、
前記アクセラレータは、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記メタデータを格納した後に、前記第２のストレージ制御部の前記メモリの前記リカバリデータを無効にし、その後、前記第１のストレージ制御部の前記メモリの前記リカバリデータを無効にすることを特徴とするストレージシステム。

【請求項5】

請求項３に記載のストレージシステムであって、
前記リカバリデータは、前記メタデータを更新される前の状態に回復するための情報を含み、
前記アクセラレータは、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記メタデータを格納した後に、前記第１のストレージ制御部の前記メモリの前記リカバリデータを無効にし、その後、前記第２のストレージ制御部の前記メモリの前記リカバリデータを無効にすることを特徴とするストレージシステム。

【請求項6】

請求項１に記載のストレージシステムであって、
前記メタデータは、前記データにアクセスするための、書き込み先論理アドレスと書き込み先物理アドレスとの対応関係を含んでおり、
書き込み対象のデータのデータ量削減処理により前記対応関係が更新されることを特徴とするストレージシステム。

【請求項7】

請求項６に記載のストレージシステムであって、
前記データ量削減処理は、圧縮処理又は重複排除処理であることを特徴とするストレージシステム。

【請求項8】

複数のストレージ制御部と、アクセラレータと、データを格納する記憶媒体を有するストレージドライブと、を有するストレージシステムの制御方法であって、
前記複数のストレージ制御部の各々は、プロセッサと、メモリと、を有し、
前記複数のストレージ制御部のうち第１のストレージ制御部の前記メモリ及び前記複数のストレージ制御部のうち第２のストレージ制御部の前記メモリには、それぞれ、前記ストレージドライブに格納されたデータにアクセスするためのメタデータが保持され、
前記制御方法は、前記格納されたデータを更新する書き込み要求を受信した場合に、
前記第１のストレージ制御部の前記プロセッサが、更新されるデータのデータ量削減処理を実行する手順と、
前記第１のストレージ制御部の前記プロセッサが、前記更新されるデータにかかるメタデータを前記データ量削減処理により更新する手順と、
前記第１のストレージ制御部の前記プロセッサが、前記更新したメタデータの処理要求を前記アクセラレータに送信する手順と、
前記アクセラレータが、前記処理要求に基づいて、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記メタデータを格納する手順と、を含むことを特徴とするストレージシステムの制御方法。

【請求項9】

請求項８に記載のストレージシステムの制御方法であって、
前記第１のストレージ制御部の前記プロセッサが、前記メタデータとともに前記メタデータの一貫性を回復するための情報を含むリカバリデータ及びその処理要求を前記アクセラレータに送信する手順と、
前記アクセラレータが、前記処理要求に基づいて、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記リカバリデータを格納する手順と、を含むことを特徴とするストレージシステムの制御方法。

【請求項10】

請求項９に記載のストレージシステムの制御方法であって、
前記制御方法は、さらに、
前記アクセラレータが、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記メタデータを格納した後に、前記第１のストレージ制御部の前記メモリの前記リカバリデータ及び前記第２のストレージ制御部の前記メモリの前記リカバリデータを無効にする手順と、
前記第１のストレージ制御部の前記プロセッサ及び前記第２のストレージ制御部の前記プロセッサが、前記メタデータの少なくとも一部の前記メモリへの格納が正常に終了しなかった場合、有効である前記リカバリデータに基づいて、前記メタデータの一貫性を回復する手順と、を含むことを特徴とするストレージシステムの制御方法。

【請求項11】

請求項１０に記載のストレージシステムの制御方法であって、
前記リカバリデータは、前記メタデータを更新された後の状態に回復するための情報を含み、
前記リカバリデータを無効にする手順において、前記アクセラレータは、前記第２のストレージ制御部の前記メモリの前記リカバリデータを無効にし、その後、前記第１のストレージ制御部の前記メモリの前記リカバリデータを無効にすることを特徴とするストレージシステムの制御方法。

【請求項12】

請求項１０に記載のストレージシステムの制御方法であって、
前記リカバリデータは、前記メタデータを更新される前の状態に回復するための情報を含み、
前記リカバリデータを無効にする手順において、前記アクセラレータは、前記第１のストレージ制御部の前記メモリの前記リカバリデータを無効に更新し、その後、前記第２のストレージ制御部の前記メモリの前記リカバリデータを無効にすることを特徴とするストレージシステムの制御方法。

【請求項13】

請求項８に記載のストレージシステムの制御方法であって、
前記メタデータは、前記データにアクセスするための、書き込み先論理アドレスと書き込み先物理アドレスとの対応関係を含んでおり、
書き込み対象のデータのデータ量削減処理により前記対応関係が更新されることを特徴とするストレージシステムの制御方法。

【請求項14】

請求項１３に記載のストレージシステムの制御方法であって、
前記データ量削減処理は、圧縮処理又は重複排除処理であることを特徴とするストレージシステムの制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ストレージシステムに関する。

【背景技術】

【0002】

ストレージシステムの記憶媒体に掛かるコストを低減する手段として、データ圧縮技術や重複排除技術などのデータ削減技術が普及している。これらのデータ削減技術を適用する場合、ホストからストレージシステムに対して書き込まれるデータサイズと、実際に記憶媒体に書き込まれるデータサイズとの間に差が生じる。そのため、記憶媒体の記憶領域を効果的に利用するために、データ削減適用後のデータを前詰めで書き込んでいく追記型データ格納方式（例えば、Ｌｏｇ－Ｓｔｒｕｃｔｕｒｅｄ Ｓｔｏｒａｇｅ）が用いられている。

【0003】

また、冗長性を高めるために複数のコントローラを搭載したストレージシステムが普及している。こうしたストレージシステムでは、搭載コントローラのうちの一つに障害が発生した場合においても、記録されたユーザデータの一貫性を保つ必要がある。これを実現する手段として、キャッシュメモリ二重化と呼ばれる技術が広く用いられている。これは、ストレージシステムが書き込み要求を受領した際、書き込み要求の処理を担当するコントローラのキャッシュメモリに加えて、別のコントローラのキャッシュメモリに受領したユーザデータを格納してから、ホストへの完了応答を返す方法である。この方法を用いると、一つのコントローラに障害が発生した場合であっても、別のコントローラにユーザデータが格納されているため、データの一貫性を維持することができる。ただし、キャッシュメモリの二重化は、コントローラ間のデータ転送処理を伴うため、ＣＰＵの負荷を増加させ、ストレージシステムのＩ／Ｏ性能の低下を引き起こす。ＣＰＵの負荷を低減させるためには、ユーザデータ転送処理の実行をＣＰＵから専用ハードウェアへオフロードする方式が考えられる。

【0004】

ユーザデータ転送処理をハードウェアオフロードする技術として、例えば、特表２０１４－５０４７４９号公報（特許文献１）に記載の技術が知られている。特許文献１には、ハードウェアを用いたデータ転送を制御するシーケンサを導入することで、複数のユーザデータの転送処理をまとめてオフロードし、ＣＰＵの負荷を低減させる技術が開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特表２０１４－５０４７４９号公報

【発明の概要】

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

【0006】

追記型データ格納方式では、ユーザデータの論理アドレスと、実際にデータが物理的に格納される位置（物理アドレス）との対応関係が可変となる。このため、ストレージシステムは、ホストから書き込まれたユーザデータに加えて、論理アドレスと物理アドレスの対応関係をメタデータとして記録しておく必要がある。また、複数のコントローラを搭載したストレージシステムでは、コントローラ間のデータの一貫性を保つために、複数コントローラのキャッシュメモリ上にメタデータを二重化する必要がある。また、二重化処理を実行している途中でストレージシステムに障害（例えば、コントローラ間の接続が切断される等）が発生した場合でも、コントローラ間のメタデータの一貫性を維持する必要がある。

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

【0007】

上記の課題の少なくとも一つを解決するための本発明の一態様は、複数のストレージ制御部と、アクセラレータと、データを格納する記憶媒体を有するストレージドライブと、を有するストレージシステムであって、前記複数のストレージ制御部の各々は、プロセッサと、メモリと、を有し、前記複数のストレージ制御部のうち第１のストレージ制御部の前記メモリ及び前記複数のストレージ制御部のうち第２のストレージ制御部の前記メモリには、それぞれ、前記ストレージドライブに格納されたデータにアクセスするためのメタデータが保持され、前記格納されたデータを更新する書き込み要求を受信した場合に、前記第１のストレージ制御部の前記プロセッサは、更新されるデータのデータ量削減処理を実行し、前記更新されるデータにかかるメタデータを前記データ量削減処理により更新し、前記更新したメタデータの処理要求を前記アクセラレータに送信し、前記アクセラレータは、前記処理要求に基づいて、前記第１のストレージ制御部の前記メモリ及び前記第２のストレージ制御部の前記メモリに前記メタデータを格納することを特徴とする。

【発明の効果】

【0008】

本発明の一態様によれば、追記型データ格納方式を採用するストレージシステムにおいて、データの一貫性を保ちつつ、Ｉ／Ｏ処理性能を向上させることができる。

【0009】

前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0010】

【図1】本発明の実施例におけるストレージシステムの概略を示す図である。

【図2】本発明の実施例におけるメタデータ更新処理の概要を示す図である。

【図3】本発明の実施例におけるＬＤＥＶ管理テーブルを説明する図である。

【図4】本発明の実施例におけるメタデータ管理テーブルを説明する図である。

【図5】本発明の実施例におけるリカバリデータ管理テーブルを説明する図である。

【図6】本発明の実施例におけるリード処理を説明するフローチャートである。

【図7】本発明の実施例におけるライト処理を説明するフローチャートである。

【図8】本発明の実施例におけるデステージ処理を説明するフローチャートである。

【図9】本発明の実施例におけるデータ量削減処理を説明するフローチャートである。

【図10】本発明の実施例におけるメタデータ更新処理を説明するフローチャートである。

【図11】本発明の実施例におけるメタデータリカバリ処理を説明するフローチャートである。

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

【0011】

以下、図面に基づいて、本発明の実施例を説明する。添付図面では、機能的に同じ要素を同じ番号で表示する場合がある。添付図面は、本発明の原理に則った具体的な実施形態と実施例とを示している。それらの実施形態及び実施例は、本発明の理解のためのものであり、本発明を限定的に解釈するために用いてはならない。

【0012】

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号を使用し、同種の要素を区別する場合は、参照符号（又は要素のＩＤ（例えば識別番号））を使用することがある。例えば、複数のストレージコントローラを区別しない場合には、「ストレージコントローラ２２」と記載し、各ストレージコントローラを区別する場合には、「ストレージコントローラ１＿２２Ａ」、「ストレージコントローラ２＿２２Ｂ」のように記載する。他の要素（例えばキャッシュ領域２０３、バッファ領域２０２等）も同様である。

【0013】

また、ＣＰＵ２４をＣＰＵ２４Ａと記載するなど、ストレージコントローラ１＿２２Ａ及びストレージコントローラ２＿２２Ｂに属するものをそれぞれ参照符号に付した「Ａ」及び「Ｂ」によって区別する。

【0014】

本実施例では、障害発生時にロールフォワードによってメタデータの一貫性を保つ方法を述べる。

【0015】

図１は、本発明の実施例におけるストレージシステム１００の概略を示す図である。ストレージシステム１００は、ストレージ装置１１と、ストレージ装置１１に接続されたホスト計算機４０とを含む。ホスト計算機４０は、ネットワーク４１を介してストレージ装置１１に接続される。ホスト計算機４０は、物理的な計算機でもよいし、物理的な計算機上で実行される仮想的な計算機でもよい。また、ホスト計算機４０は、ストレージシステム１００において実行される仮想的な計算機でもよい。

【0016】

ストレージ装置１１は、２以上のストレージコントローラ２２と、１以上のアクセラレータ３１と、各々が１以上のストレージコントローラ２２に接続された複数のドライブ２９と、ストレージコントローラ２２とアクセラレータ３１を接続するネットワーク３０とを有する。

【0017】

ストレージコントローラ２２は、ホスト計算機との通信を行うＦＥ＿Ｉ／Ｆ（フロントエンドインターフェイスデバイス）２３、装置全体の制御を行うＣＰＵ２４、ＣＰＵ２４で使用されるプログラムおよび情報を格納するメモリ２５、ドライブ２９との通信を行うＢＥ＿Ｉ／Ｆ（バックエンドインターフェイスデバイス）２７、ネットワーク３０を介してストレージコントローラ２２間を接続するＣＴＬ＿Ｉ／Ｆ（コントローラ間インターフェイス）２８、及びそれらを接続する内部ネットワーク２６を備える。

【0018】

メモリ２５は、プログラムを格納するプログラム領域２０１、データ転送及びデータコピー時の一時的なデータ格納領域であるバッファ領域２０２、ホスト計算機４０からのライト対象データ（ホスト計算機４０からのライト要求に応答して書き込まれるデータ）やドライブ２９からのリード対象データ（ホスト計算機４０からのリード要求に応答して読み出されたデータ）やメタデータを一時的に格納するキャッシュ領域２０３、種々のテーブルを格納するテーブル管理領域２０４、メタデータのロールフォワードまたはロールバックを実施するための情報を格納するリカバリデータ領域２０８、及びＣＰＵ２４とアクセラレータ３１との間のデータのやり取りに用いるローカルメモリ領域２０９を有する。

【0019】

テーブル管理領域２０４には、ＬＤＥＶに関する情報を保持するＬＤＥＶ管理テーブル２０５、及び、メタデータ情報を保持するメタデータ管理テーブル２０６が格納される。ここでＬＤＥＶ（Ｌｏｇｉｃａｌ Ｄｅｖｉｃｅ）とは、ストレージシステムによって管理される論理的な記憶デバイスである。

【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】

＜デステージ処理＞
図８は、本発明の実施例におけるデステージ処理を説明するフローチャートである。

【0076】

デステージ処理は、キャッシュ上のユーザデータをドライブ２９の指定された物理アドレスへ書き込む処理である。デステージ処理は、ライト処理において、ストレージ装置１１へのライト処理の完了応答をホスト計算機４０に返した後、図７のステップＳ７０９で実行される。なお、デステージ処理は、ホスト計算機４０からのライト要求と同期的に実行されてもよいし、非同期的に（例えば一定の時間周期ごとに）実行されてもよい。

【0077】

以下、図８を用いて、デステージ処理の処理フローを説明する。

【0078】

Ｓ８０１：ＣＰＵ２４Ａは、キャッシュ領域２０３Ａ上のデステージ処理対象データを含むスロット領域の排他を確保する。

【0079】

Ｓ８０２：ＣＰＵ２４Ａは、デステージ対象データのパリティを生成する。

【0080】

Ｓ８０３：ＣＰＵ２４Ａは、デステージ対象データ及びステップＳ８０２において生成したパリティデータをドライブ２９に書き出す。

【0081】

Ｓ８０４：ＣＰＵ２４Ａは、ステップＳ８０１において確保したスロット領域の排他を解放し、処理を終了する。

【0082】

＜データ量削減処理＞
図９は、本発明の実施例におけるデータ量削減処理を説明するフローチャートである。

【0083】

データ量削減処理は、ライト処理において、ストレージ装置１１に対するライト要求の完了応答をホスト計算機４０に返した後、図７のステップＳ７０８で実行される。なお、データ量削減処理は、ホスト計算機４０からのライト要求と同期的に実行されてもよいし、非同期的に実行されてもよい。

【0084】

図９内のステップＳ９０３で行う圧縮処理は、ライトデータに対して実行する所定の処理の一例である。ＣＰＵ２４Ａは、圧縮以外の処理（例えば、重複排除処理または暗号化処理など）を実行してもよい。また、本実施例では、圧縮処理をＣＰＵ２４Ａが実行しているが、代わりに例えばＦＰＧＡなどを用いて実装される専用ハードウェアが実行してもよい。

【0085】

以下、図９を用いて、データ量削減処理の処理フローを説明する。

【0086】

Ｓ９０１：ＣＰＵ２４Ａは、データ量削減処理の対象データを含んだキャッシュ領域２０３Ａのスロット領域の排他を確保する。

【0087】

Ｓ９０２：ＣＰＵ２４Ａは、データ量削減処理の対象データに対して圧縮処理を適用し、得られた圧縮データをバッファ領域２０２Ａに格納する。

【0088】

Ｓ９０３：ＣＰＵ２４Ａは、バッファ領域２０２Ａの圧縮データをキャッシュ領域２０３Ａへ転送する。

【0089】

Ｓ９０４：ＣＰＵ２４Ａは、キャッシュ領域２０３Ｂに対して、圧縮データを転送する。

【0090】

Ｓ９０５：ＣＰＵ２４Ａは、後述するメタデータ更新処理（図１０参照）を実行する。

【0091】

Ｓ９０６：ＣＰＵ２４Ａは、対象スロット領域の排他を解放する。

【0092】

Ｓ９０７：ＣＰＵ２４Ａは、デステージ処理を行い、データ量削減処理を終了する。なお、先述のとおり、デステージ処理は、ホスト計算機４０からのライト要求と同期的に実行されてもよいし、非同期的に（例えば一定の時間周期ごとに）実行されてもよい。

【0093】

＜メタデータ更新処理＞
図１０は、本発明の実施例におけるメタデータ更新処理を説明するフローチャートである。

【0094】

Ｓ１００１：ＣＰＵ２４Ａは、更新後メタデータ５０を作成し、ローカルメモリ領域２０９Ａに格納する。

【0095】

Ｓ１００２：ＣＰＵ２４Ａは、更新後メタデータ５０に対応するリカバリデータ５１を作成し、ローカルメモリ領域２０９Ａに格納する。ここでリカバリデータ５１は、図５に示したように、更新後メタデータ５０のバックアップデータ（例えば論理アドレス２０７１～圧縮後サイズ２０７３）と、有効フラグ２０７４と、コントローラ２２Ａのメタデータ格納先アドレス２０７５と、コントローラ２２Ｂのメタデータ格納先アドレス２０７６とによって構成される。このとき、有効フラグ２０７４の値は「有効」に設定される。

【0096】

Ｓ１００３：ＣＰＵ２４Ａは、メタデータ更新依頼メッセージを作成する。更新依頼メッセージは、更新対象メタデータ情報のリストからなる。リストの各要素は、更新後メタデータ５０が格納されたローカルメモリ領域２０９Ａのアドレス、更新後メタデータ５０に対応するリカバリデータ５１が格納されたローカルメモリ領域２０９Ａのアドレス、ストレージコントローラ２２Ａのキャッシュ領域２０３Ａ内の更新後メタデータ格納先アドレス、及び、ストレージコントローラ２２Ｂのキャッシュ領域２０３Ｂ内の更新後メタデータ格納先アドレスを含む。

【0097】

Ｓ１００４：ＣＰＵ２４Ａは、アクセラレータ３１に対してメタデータ更新処理要求を送信する。

【0098】

Ｓ１００５：アクセラレータ３１は、ＣＰＵ２４Ａからメタデータ更新処理要求を受領する。

【0099】

Ｓ１００６：アクセラレータ３１は、更新対象メタデータのリストの先頭から順に、ステップＳ１００７からステップＳ１０１１までの処理を行う。

【0100】

Ｓ１００７：アクセラレータ３１は、ストレージコントローラ２２Ａのローカルメモリ領域２０９Ａからリカバリデータ５１を読み出す。その後、アクセラレータ３１は、リカバリデータ５１をストレージコントローラ２２Ａのリカバリデータ領域２０８Ａに格納する。

【0101】

Ｓ１００８：アクセラレータ３１は、リカバリデータ５１をストレージコントローラ２２Ｂのリカバリデータ領域２０８Ｂに格納する。

【0102】

Ｓ１００９：アクセラレータ３１は、ストレージコントローラ２２Ａのローカルメモリ領域２０９Ａから更新後メタデータ５０を読み出す。その後、アクセラレータ３１は、指定された更新後メタデータ格納先アドレスに基づき、更新後メタデータ５０をストレージコントローラ２２Ａのキャッシュ領域２０３Ａおよびストレージコントローラ２２Ｂのキャッシュ領域２０３Ｂにそれぞれ格納する。

【0103】

Ｓ１０１０：アクセラレータ３１は、ストレージコントローラ２２Ｂのリカバリデータ領域２０８Ｂに格納したリカバリデータ５１の有効フラグの値を「無効」に書き換え、リカバリデータを無効化する。

【0104】

Ｓ１０１１：アクセラレータ３１は、ストレージコントローラ２２Ａのリカバリデータ領域２０８Ａに格納したリカバリデータ５１の有効フラグの値を「無効」に書き換え、リカバリデータを無効化する。

【0105】

Ｓ１０１２：アクセラレータ３１は、ＣＰＵ２４Ａから受領した更新対象メタデータリストに未処理の要素が残っている場合は、ステップＳ１００６に進む。リストの全要素の処理が完了した場合は、ステップＳ１０１３に進む。

【0106】

Ｓ１０１３：アクセラレータ３１は、ＣＰＵ２４Ａに対して、メタデータ更新処理の実行結果を通知する。

【0107】

Ｓ１０１４：ＣＰＵ２４Ａは、アクセラレータ３１からメタデータ更新処理の実行結果を受け取り、処理を終える。

【0108】

このように、メタデータ二重化を行う前にリカバリデータを各コントローラに転送することで、コントローラ間でメタデータの一貫性が失われた場合でも、リカバリデータからメタデータのロールバックあるいはロールフォワードを行うことができる。これによって、メタデータの一貫性を回復することができる。また、リカバリデータの転送とメタデータの二重化処理を、まとめてＣＰＵからアクセラレータにオフロードすることによって、ＣＰＵの処理負荷が低減されるため、ストレージシステムのＩ／Ｏ処理性能の向上が期待できる。

【0109】

＜メタデータリカバリ処理＞
図１１は、本発明の実施例におけるメタデータリカバリ処理を説明するフローチャートである。

【0110】

メタデータリカバリ処理は、メタデータ更新処理が、外的要因（例えばコントローラ間接続の切断等）によって完了しなかった場合に実行される処理である。メモリ上に格納されたリカバリデータを元に、メタデータに対してロールフォワードまたはロールバックを適用することで、両コントローラ間でメタデータの内容が整合した状態に戻す。メタデータリカバリ処理は、両コントローラでそれぞれ実行される。

【0111】

以下、図１１を用いて、リカバリ処理の処理フローを説明する。ここではロールフォワードを用いる方法を述べる。

【0112】

Ｓ１１０１：ＣＰＵ２４は、リカバリデータ領域２０８のリカバリデータ管理テーブル２０７内の各エントリに対して、ステップＳ１１０２からステップＳ１１０７までの処理を行う。

【0113】

Ｓ１１０２：ＣＰＵ２４は、対象のリカバリデータエントリ内の有効フラグ２０７４を参照する。

【0114】

Ｓ１１０３：ＣＰＵ２４は、Ｓ１１０２で参照した有効フラグ２０７４の値が「有効」かどうか判定する。有効フラグ２０７４の値が「有効」のとき、当該リカバリデータに対応するメタデータは更新が適用されたことが保証されていない。すなわち、この場合、自系のストレージコントローラ２２と他系のストレージコントローラ２２とで二重化されたメタデータの一貫性が損なわれている可能性がある。このため、当該メタデータをロールフォワード対象とする。有効フラグ２０７４の値が「無効」のとき、当該リカバリデータに対応するメタデータは更新が適用されている状態であるため、メタデータの一貫性が確保されており、ロールフォワードは不要である。この判定結果が真の場合、ステップＳ１１０４に進む。判定結果が偽の場合、ステップＳ１１０６に進む。

【0115】

Ｓ１１０４：ＣＰＵ２４は、リカバリデータ管理テーブル２０７を参照し、当該エントリのメタデータ格納先アドレス２０７５および２０７６を取得する。

【0116】

Ｓ１１０５：ＣＰＵ２４は、リカバリデータ管理テーブル２０７の当該エントリのメタデータバックアップ情報（論理アドレス２０７１、物理アドレス２０７２、及び圧縮後サイズ２０７３）を、Ｓ１１０４で取得したメタデータ格納先アドレスにコピーする。コピーが完了したら、当該エントリの有効フラグの値を「無効」に設定する。

【0117】

Ｓ１１０６：ＣＰＵ２４は、リカバリデータ管理テーブルに未処理のエントリが残っている場合、次エントリの対して同様に処理を行うためステップＳ１１０１に進む。未処理のエントリが残っていない場合はリカバリ処理を終了する。

【0118】

以上、ロールフォワードを用いてメタデータの一貫性を回復する方法を述べた。

【0119】

なお、ロールバックを用いる方法についても、本実施例の処理の一部を次のように変更することで実現可能である。

【0120】

具体的には、メタデータ更新処理のステップＳ１００２において、リカバリデータ５１の内部に更新後のメタデータではなく、更新前のメタデータを格納するようにする。

【0121】

また、ステップＳ１０１０とステップＳ１０１１の実施順序を入れ替える。具体的には、アクセラレータ３１は、ストレージコントローラ２２Ａのリカバリデータ領域２０８Ａに格納したリカバリデータ５１の有効フラグ２０７４を「無効」に書き換えてから、ストレージコントローラ２２Ｂのリカバリデータ領域２０８Ｂに格納したリカバリデータ５１の有効フラグ２０７４を「無効」に書き換える。

【0122】

ロールバックが行われると、有効フラグ２０７４が「有効」であるリカバリデータに対応するメタデータは更新前のものに書き換えられる。このとき、上記の順に有効フラグ２０７４を書き換えることによって、Ｉ／Ｏ処理を直接担当する自系のストレージコントローラ２２Ａが優先的に更新後のメタデータを保持した状態となる。

【0123】

上記のように処理を変更することで、メタデータリカバリ処理のステップＳ１１０５において復元されるメタデータが更新前のメタデータとなるため、ロールバックが実現できる。

【0124】

以上の本発明の実施例によれば、障害発生時に、それぞれのストレージコントローラがメタデータ更新処理のロールフォワードまたはロールバックを行うことで、メタデータの一貫性が維持される。このため、メタデータ更新処理においては、まずロールフォワードまたはロールバックに必要な情報（リカバリデータ）を各ストレージコントローラのメモリ上に格納してから、メタデータの二重化が行われる。メタデータ更新処理が異常終了した場合、各ストレージコントローラは、リカバリデータに基づいてメタデータのロールフォワードまたはロールバックを実施することで、メタデータの一貫性を回復する。また、リカバリデータの送信とメタデータの二重化をハードウェアアクセラレータにオフロードすることで、ストレージコントローラのＣＰＵ処理負荷が削減され、ストレージシステムの処理性能が向上する。

【0125】

また、本発明の実施形態のシステムは次のように構成されてもよい。

【0126】

（１）複数のストレージ制御部（例えばストレージコントローラ２２）と、アクセラレータ（例えばアクセラレータ３１）と、データを格納する記憶媒体を有するストレージドライブ（例えばドライブ２９）と、を有するストレージシステムであって、複数のストレージ制御部の各々は、プロセッサ（例えばＣＰＵ２４）と、メモリ（例えばメモリ２５）と、を有し、複数のストレージ制御部のうち第１のストレージ制御部のメモリ及び複数のストレージ制御部のうち第２のストレージ制御部のメモリには、それぞれ、ストレージドライブに格納されたデータにアクセスするためのメタデータ（例えばメタデータ管理テーブル２０６）が保持され、格納されたデータを更新する書き込み要求を受信した場合に、第１のストレージ制御部のプロセッサは、更新されるデータにかかるメタデータを更新したメタデータと、メタデータの一貫性を回復するための情報を含むリカバリデータ（例えばリカバリデータ管理テーブル２０７）とを生成し（例えばステップＳ１００１及びＳ１００２）、メタデータ及びリカバリデータの処理要求をアクセラレータに送信し（例えばステップＳ１００４）、アクセラレータは、処理要求に基づいて、第１のストレージ制御部のメモリ及び第２のストレージ制御部のメモリにリカバリデータを格納し、その後に（例えばステップＳ１００７及びＳ１００８）第１のストレージ制御部のメモリ及び第２のストレージ制御部のメモリにメタデータを格納する（例えばステップＳ１００９）。

【0127】

これによって、追記型データ格納方式を採用するストレージシステムにおいて、データの一貫性を保ちつつ、Ｉ／Ｏ処理性能を向上させることができる。

【0128】

（２）上記（１）において、アクセラレータは、第１のストレージ制御部のメモリ及び第２のストレージ制御部のメモリにメタデータを格納した後に、第１のストレージ制御部のメモリのリカバリデータ及び第２のストレージ制御部のメモリのリカバリデータを無効にし（例えばステップＳ１０１０及びＳ１０１１）、第１のストレージ制御部のプロセッサ及び第２のストレージ制御部のプロセッサは、メタデータの少なくとも一部のメモリへの格納が正常に終了しなかった場合、有効であるリカバリデータに基づいて、メタデータの一貫性を回復する（例えばステップＳ１１０２～Ｓ１１０６）。

【0129】

これによって、メタデータを一貫性が確保された状態に回復することができる。

【0130】

（３）上記（２）において、リカバリデータは、メタデータを更新された後の状態に回復するための情報を含み、アクセラレータは、第１のストレージ制御部のメモリ及び第２のストレージ制御部のメモリにメタデータを格納（例えばステップＳ１００９）した後に、第２のストレージ制御部のメモリのリカバリデータを無効にし（例えばステップＳ１０１０）、その後、第１のストレージ制御部のメモリのリカバリデータを無効にする（例えばステップＳ１０１１）。

【0131】

これによって、メタデータを一貫性が保たれた状態にロールフォワードすることができる。

【0132】

（４）上記（２）において、リカバリデータは、メタデータを更新される前の状態に回復するための情報を含み、アクセラレータは、第１のストレージ制御部のメモリ及び第２のストレージ制御部のメモリにメタデータを格納（例えばステップＳ１００９）した後に、第１のストレージ制御部のメモリのリカバリデータを無効にし（例えばステップＳ１０１１）、その後、第２のストレージ制御部のメモリのリカバリデータを無効にする（例えばステップＳ１０１０）。

【0133】

これによって、メタデータを一貫性が保たれた状態にロールバックすることができる。

【0134】

（５）上記（１）において、メタデータは、データにアクセスするための、書き込み先論理アドレスと書き込み先物理アドレスとの対応関係を含んでおり、書き込み先論理アドレスと書き込み先物理アドレスとの対応関係が更新される場合とは、書き込み対象のデータのデータ量削減処理が実行される場合である。

【0135】

これによって、追記型データ格納方式を採用するストレージシステムにおいて、データの一貫性を保つことができる。

【0136】

（６）上記（５）において、データ量削減処理は、圧縮処理又は重複排除処理である。

【0137】

これによって、追記型データ格納方式を採用するストレージシステムにおいて、データの一貫性を保つことができる。

【0138】

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明のより良い理解のために詳細に説明したものであり、必ずしも説明の全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

【0139】

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

【0140】

また、制御線及び情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

【符号の説明】

【0141】

１００…ストレージシステム
１１…ストレージ装置
２２…ストレージコントローラ
２５…メモリ
２９…ドライブ
３０…ネットワーク
３１…アクセラレータ
４０…ホスト計算機
２０２…バッファ領域
２０３…キャッシュ領域
２０８…リカバリデータ領域
２０９…ローカルメモリ領域

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】