JP4555040B2 - ストレージ装置及びストレージ装置のライトアクセス処理方法 - Google Patents

Description

本発明は、ストレージ装置及びストレージ装置のライトアクセス処理方法に関する。

ストレージ装置は、例えば、ハードディスクドライブ等のディスクドライブをアレイ状に配設し、RAID（Redundant Arrays of Inexpensive Disks）に基づく記憶領域を提供する。ホストコンピュータ（以下、「ホスト」）は、ストレージ装置により提供される論理的な記憶領域にアクセスし、データの読み書きを行う。

ストレージ装置は、ホストから受信したライトデータを、キャッシュメモリを介してディスクドライブに記憶させる。また、例えば、ストレージ装置は、ホストから要求されたデータがキャッシュメモリに記憶されていない場合、ホストから要求されたデータをディスクドライブから読出してキャッシュメモリに格納し、キャッシュメモリを介してホストにデータを提供する。

このように、ホストから書込みを要求されたライトデータは、キャッシュメモリに保持された後、所定のディスクドライブに書き込まれる。キャッシュメモリからディスクドライブにデータを書き込む方式としては、大きく２種類に大別可能である。

一つの方式は、例えば、ライトスルー方式と呼ばれるもので、ライトデータのキャッシュメモリへの書込みと、ライトデータのディスクドライブへの書込みとを、ほぼ同時期に実行する方式である。他の一つの方式は、例えば、コピーバック方式またはアフターライト方式と呼ばれるもので、ライトデータをキャッシュメモリにのみ記憶させ、その後所定のタイミングで、キャッシュメモリ上のライトデータをディスクドライブに書き込む方式である（特許文献１）。

ライトスルー方式の場合は、ライトデータをディスクドライブに書き込んだ後で、ホストに書込み完了を報告する。アフターライト方式の場合は、ライトデータをキャッシュメモリに格納した時点で、ホストに書込み完了を報告する。従って、アフターライト方式の方が、ライトスルー方式よりも応答時間を短縮することができる。
特開平６−３０９２３２号公報

従来のストレージ装置では、ライトスルー方式とアフターライト方式との両方式をストレージ装置全体で切り換えることはできるが、例えば、論理ボリューム毎にそれぞれ異なる方式を適用する等のように、ユーザの希望する単位毎に個別に方式を設定することはできず、使い勝手が低い。

そこで、本発明の一つの目的は、所定の単位毎に、複数のライトアクセス用の処理モードのうちいずれか一つの処理モードをそれぞれ個別に適用可能なストレージ装置及びストレージ装置のライトアクセス処理方法を提供することにある。本発明の一つの目的は、所定の単位毎にライトアクセス用の処理モードをそれぞれ個別に設定することができ、互いの関連性のある所定の単位同士に同一の処理モードを適用させるストレージ装置及びストレージ装置のライトアクセス処理方法を提供することにある。本発明の一つの目的は、他のストレージ装置の状況に応じて、設定済みの処理モードを変更可能なストレージ装置及びストレージ装置のライトアクセス処理方法を提供することにある。本発明の更なる目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明に係るストレージ装置は、上位装置及び記憶デバイス群との間のデータ授受をそれぞれ制御するためのコントローラと、コントローラにより使用され、上位装置から受信したライトデータを非冗長記憶または冗長記憶するキャッシュメモリと、を備える。そして、コントローラは、上位装置からのライトコマンドを受け付けた場合の処理モードとして、（１）ライトデータをキャッシュメモリに冗長記憶させた場合に上位装置に処理完了を通知し、キャッシュメモリに冗長記憶されたライトデータを所定のタイミングで記憶デバイス群に書き込む第１処理モードと、（２）キャッシュメモリに非冗長記憶されたライトデータを記憶デバイス群に書き込んだ場合に、上位装置に処理完了を通知する第２処理モードと、（３）ライトデータをキャッシュメモリに非冗長記憶させた場合に上位装置に処理完了を通知し、キャッシュメモリに非冗長記憶されたライトデータを所定のタイミングで記憶デバイス群に書き込む第３処理モードと、を予め備えており、コントローラは、予め設定された所定の単位毎に、各処理モードのうちいずれか一つの処理モードを実行可能となっている。

ここで、所定の単位としては、例えば、記憶デバイス群の物理的な記憶領域の集合体上に設定される論理ボリューム、記憶デバイス群の物理的な記憶領域の集合体上に設定される論理ボリュームに対応付けられる論理ユニット（ＬＵ）、記憶デバイス群の物理的な記憶領域の集合体、記憶デバイスの種別、記憶デバイス群及びキャッシュメモリを論理的に分割して生成される仮想筐体、のいずれか又はこれらの組合せを採用可能である。

また、冗長記憶とは、データロスを防止するために、本来のデータ以外の他のデータを合わせて記憶することを意味し、例えば、ライトデータを複数のキャッシュ領域にそれぞれ保持させる場合や、パリティデータ等を用いてデータを復元可能に保持する場合を挙げることができる。これに対し、非冗長記憶とは、本来のデータのみをそのまま記憶することを意味する。従って、キャッシュメモリに冗長記憶されたデータは、データロスに対する耐性が高い。

コントローラは、第１処理モードを優先的に実行し、キャッシュメモリがライトデータを冗長記憶できない場合に、第２処理モードまたは第３処理モードのいずれか一つを実行することができる。

コントローラは、第１処理モードを優先的に実行し、キャッシュメモリがライトデータを冗長記憶できない場合に、予め設定されたモード選択情報に基づいて、第２処理モードまたは第３処理モードのいずれか一つを実行することもできる。

コントローラは、キャッシュメモリがライトデータを冗長記憶可能な場合は第１処理モードを優先的に実行し、キャッシュメモリがライトデータを冗長記憶できない場合は第２処理モードを優先的に実行し、キャッシュメモリがライトデータを冗長記憶できない場合であって、かつ、モード選択情報により第３処理モードが選択されている場合は、第３処理モードを実行することができる。

コントローラは、外部からの指示に基づいて、各処理モードの優先順位を予め設定するためのモード選択情報を各所定の単位毎にそれぞれ対応付けて管理可能である。

コントローラは、各所定の単位のうち関連性のある所定の単位同士にそれぞれ同一の処理モードを適用することもできる。

コントローラは、ライトデータを受領して記憶する他のストレージ装置の状況を考慮して、各処理モードのうちいずれか一つの処理モードを前記所定の単位毎にそれぞれ設定することもできる。

コントローラは、ライトデータを受領して記憶する他のストレージ装置に障害が発生した場合には、第３処理モードに設定されている所定の単位を、第２処理モードまたは第１処理モードのいずれかに変更することもできる。

本発明の他の観点に従うストレージ装置のライトアクセス処理方法は、（１）ライトデータをキャッシュメモリに冗長記憶させた場合に上位装置に処理完了を通知し、キャッシュメモリに冗長記憶されたライトデータを所定のタイミングで記憶デバイス群に書き込む第１処理モードと、（２）キャッシュメモリに非冗長記憶されたライトデータを記憶デバイス群に書き込んだ場合に、上位装置に処理完了を通知する第２処理モードと、（３）ライトデータをキャッシュメモリに非冗長記憶させた場合に上位装置に処理完了を通知し、キャッシュメモリに非冗長記憶されたライトデータを所定のタイミングで記憶デバイス群に書き込む第３処理モードと、を備えており、所定の単位毎にそれぞれモード選択情報を設定するステップと、上位装置からライトデータを受信するステップと、キャッシュメモリが冗長記憶可能か否かを判定するステップと、キャッシュメモリが冗長記憶可能であると判定された場合は、第１処理モードを実行させるステップと、キャッシュメモリが冗長記憶不能であると判定された場合は、設定されたモード選択情報により第２処理モードが選択されているか否かを判定するステップと、モード選択情報により第２処理モードが選択されていると判定された場合は、第２処理モードを実行させるステップと、モード選択情報により第２処理モードが選択されていないと判定された場合は、第３処理モードを実行させるステップと、を含んで構成可能である。

本発明の手段、機能、ステップの少なくとも一部は、マイクロコンピュータにより読み込まれて実行されるコンピュータプログラムとして構成できる場合がある。このようなコンピュータプログラムは、例えば、ハードディスクや光ディスク等のような記憶媒体に固定して流通させることができる。または、インターネット等のような通信ネットワークを介して、コンピュータプログラムを供給することもできる。

以下、図面に基づき、本発明の実施の形態を説明する。図１は、本実施形態の全体概念を示す説明図である。本実施形態のストレージシステムは、ホスト１と、ストレージ装置２とを含んで構成される。ストレージ装置２は、コントローラ３と、複数の論理ボリューム（以下、「ボリューム」と省略する場合もある）６Ａ，６Ｂを備える。そして、コントローラ３は、ストレージ装置２の動作を制御するもので、第１キャッシュ領域４及び第２キャッシュ領域５を有するキャッシュメモリを備えている。

以下に述べるように、コントローラ３は、ホスト１からのライトアクセスを処理するモードを３種類備えており、各ボリューム６Ａ，６Ｂ毎に、適用する処理モードを予め設定可能となっている。

図１（ａ）は、キャッシュメモリが正常な場合の第１のライトアクセス処理を示す。コントローラ３は、ホスト１からのライトコマンドを受信すると（Ｓ１ａ）、ホスト１から受信したライトデータを、各キャッシュ領域４，５にそれぞれ書き込み、ライトデータを冗長記憶させる（Ｓ２ａ）。そして、コントローラ３は、各キャッシュ領域４，５にライトデータをそれぞれ書き込んだ直後に、ホスト１に対して、ライトコマンドの処理完了を通知する（Ｓ３ａ）。その後、コントローラ３は、キャッシュ領域４，５に書き込まれたライトデータのいずれかを、所定のボリューム６Ａに書き込む（Ｓ４ａ）。この例では、ボリューム６Ａにライトデータを書き込む場合を例示するが、他方のボリューム６Ｂにライトデータを書き込んでもよく、あるいは、両方のボリューム６Ａ，６Ｂにそれぞれライトデータを書き込んでもよい。

図１（ａ）に示すように、キャッシュメモリが正常に動作しており、ライトデータを冗長記憶できる場合は、ホスト１へ書込み完了を報告する時期と、ボリューム６Ａまたは６Ｂへライトデータを書込む時期とが一致せず、両時期は非同期で実施される。

図１（ｂ）は、キャッシュメモリに異常が発生して冗長記憶が不能となった場合の第２ライトアクセス処理を示す。例えば、いずれか一方のキャッシュ領域に不具合を生じて、そのキャッシュ領域を閉塞処理した場合において、ホスト１から受け付けたライトアクセスを処理する様子を示している。ここでは、第２キャッシュ領域５に障害が発生し、第１キャッシュ領域４のみを正常に使用可能な場合を例に挙げる。

コントローラ３は、ホスト１からライトコマンドを受信すると（Ｓ１ｂ）、ホスト１から受信したライトデータを正常な方のキャッシュ領域４に記憶させる（Ｓ２ｂ）。そして、コントローラ３は、キャッシュ領域４に記憶させたライトデータを直ちに所定のボリューム６Ａに書き込む（Ｓ３ｂ）。コントローラ３は、ボリューム６Ａへのライトデータの書込み完了を確認すると、ホスト１に書込み完了を報告する（Ｓ４ｂ）。

このように、キャッシュメモリに障害が発生した場合の一つの例として、ホスト１から受信したライトデータを直ちに所定のボリューム６Ａに書き込んで、ホスト１に書込み完了を報告する。

図１（ｃ）は、キャッシュメモリに異常が発生して冗長記憶が不能となった場合の第３ライトアクセス処理を示す。この場合、コントローラ３は、ホスト１からのライトコマンドを受信すると（Ｓ１ｃ）、ホスト１から受信したライトデータを正常なキャッシュ領域４に書込む（Ｓ２ｃ）。コントローラ３は、ライトデータを正常なキャッシュ領域４に書き込むと直ちに、ホスト１に対して書込み完了を報告する（Ｓ３ｃ）。そして、コントローラ３は、書込み完了を報告した後で、キャッシュ領域４に記憶されているライトデータを所定のボリューム６Ａに書き込む（Ｓ４ｃ）。

このように、キャッシュメモリに障害が発生した場合の他の例として、ホスト１から受信したライトデータを正常なキャッシュ領域４に書き込んだ時点で、直ちにホスト１に書込み完了を報告し、その後、ライトデータを所定のボリューム６Ａに書き込む。

本実施形態では、各ボリューム６Ａ，６Ｂ毎に、ライトアクセス時の処理モードを予め設定することができる。一つの例として、キャッシュメモリが正常な場合は、図１（ａ）に示すアフターライト方式で各ボリューム６Ａ，６Ｂへのライトアクセスを処理することができる。そして、キャッシュメモリに異常が生じた場合は、図１（ｂ）に示すライトスルー方式または図１（ｃ）に示す非冗長記憶型ライトアフター方式のうち、事前に選択されている方式で、各ボリューム６Ａ，６Ｂへのライトアクセスを処理可能である。

即ち、例えば、ボリューム６Ａについて図１（ｃ）に示す方式が選択されている場合、このボリューム６Ａに対するライトアクセスは、キャッシュメモリが正常なときは、図１（ａ）に示すアフターライト方式で処理されるが、キャッシュメモリに異常が生じたときは、図１（ｃ）に示す非冗長記憶型アフターライト方式で処理される。また、例えば、他のボリューム６Ｂについて図１（ｂ）に示す方式が選択されている場合、このボリューム６Ｂに対するライトアクセスは、キャッシュメモリが正常なときは、図１（ａ）に示すアフターライト方式で処理され、キャッシュメモリに異常が生じたときは、図１（ｂ）に示すライトスルー方式で処理される。

このように、本実施例では、各ボリューム６Ａ，６Ｂ毎に、ライトアクセス時の処理モードを違えることができる。詳細は後述するが、処理モードの指定は、ユーザが各ボリューム毎にそれぞれ手動で行ってもよいし、予め設定されたポリシーに基づいてコントローラ３が自動的に行ってもよい。また、ユーザによる手動指定をコントローラ３が補うことにより、各ボリューム毎にそれぞれ適切な処理モードを設定することもできる。

これにより、ストレージシステムの構成や運用形態等に応じて、各所定の単位毎に適切な処理モードをそれぞれ設定することができ、使い勝手が向上する。例えば、重要なデータを記憶するボリュームについては、データの安全性を最優先して、キャッシュメモリ異常時の処理モードをライトスルー方式に設定し、逆に、重要性の低いデータを記憶するボリュームについては、アクセス性能の維持を優先して、キャッシュメモリ異常時の処理モードを非冗長記憶型アフターライト方式に設定することができる。

なお、後述の実施例からも明らかなように、ライトアクセス時の処理モードは、ボリューム単位に限らず、論理ユニット単位、RAIDグループ単位等のように、種々の論理的または物理的な組織単位毎にそれぞれ設定することができる。

図２は、ストレージシステムのブロック図を示す。このストレージシステムは、例えば、少なくとも一つ以上のホスト１０と、少なくとも一つ以上のストレージ装置１００と、ホスト１０とストレージ装置１００との通信ネットワークを構成するためのスイッチ２０と、管理端末３０とを備えて構成することができる。後述のように、ストレージシステムは、複数のストレージ装置１００，２００を含んで構成することができる。

ホスト１０は、例えば、いわゆるオープン系ホストとメインフレーム系ホストとに大別できる。オープン系ホストとしては、例えば、Windows（登録商標）やUNIX（登録商標）等の汎用的なOS（Operating System）を搭載し、ＦＣ（Fibre Channel）、iSCSI（Internet SCSI）、TCP/IP（Transmission Control Protocol/Internet Protocol）等の比較的汎用性のある通信プロトコルを介してストレージ装置１００にアクセスするサーバマシンを挙げることができる。メインフレーム系ホストとしては、例えば、FICON（Fibre Connection：登録商標）、ESCON（Enterprise System Connection：登録商標）、ACONARC（Advanced Connection Architecture：登録商標）、FIBARC（Fibre Connection Architecture：登録商標）等の通信プロトコルを介してストレージ装置１００にアクセスするメインフレームマシンを挙げることができる。

ホスト１０は、例えば、メタルケーブルや光ファイバケーブル、スイッチ２０等を含むことができる通信ネットワークＣＮ１を介して、ストレージ装置１００に接続される。先に、図３を参照して、ホスト１０の構成を説明すると、ホスト１０は、例えば、一つまたは複数のHBA（Host Bus Adapter）１１と、パス制御部１２と、アプリケーションプログラム１３とを備えて構成可能である。HBA１１は、所定のプロトコルに基づいてデータの送受信を行う。パス制御部１２は、例えば、負荷分散や障害回避等を行うもので、いずれのパスを用いてデータ授受を行うか等を制御する。アプリケーションプログラム１３は、例えば、電子メール処理プログラムやデータベース管理ソフトウェア等のようなプログラムであり、図外のクライアント端末に対し、情報処理サービスを提供する。

図２に戻る。管理端末３０は、後述のサービスプロセッサ（SVP）１７０を介して、ストレージ装置１００の各種情報を収集したり、ストレージ装置１００に必要な指令を与えるための装置である。管理端末３０は、例えば、LAN（Local Area Network）等の通信ネットワークＣＮ２を介して、SVP１７０に接続されている。管理端末３０は、例えば、ウェブブラウザをベースとしたGUI（Graphical User Interface）を備えており、SVP１７０が提供するWWW（World Wide Web）サーバにログインすることにより、各種情報の収集と指令の入力とを行う。

ストレージ装置１００は、例えば、複数のCHA１１０と、複数のDKA１２０と、キャッシュメモリ１３０と、共有メモリ１４０と、接続制御部１５０と、記憶部１６０と、SVP１７０とを備えて構成することができる。

ストレージ装置１００には、複数のCHA１１０を設けることができる。各CHA１１０は、各ホスト１０との間のデータ転送を制御するためのパッケージである。各CHA１１０は、複数の通信ポート１１１（図２参照）を備えており、少なくとも一つ以上のホスト１０と接続可能である。各CHA１１０は、ホスト１０との間のデータ転送をそれぞれ個別に制御する。

ストレージ装置１００には、複数のDKA１２０を設けることができる。各DKA１２０は、記憶部１６０とのデータ転送をそれぞれ制御するものである。各DKA１２０は、例えば、ホスト１０から指定された論理ブロックアドレス（LBA）を物理ディスクのアドレスに変換等することにより、各ディスクドライブ１６１にアクセスし、データの読出しまたはデータの書込みを行う。

キャッシュメモリ１３０は、ホスト１０から書き込まれたライトデータや、ホスト１０に読み出されたリードデータを記憶するものである。キャッシュメモリ１３０は、例えば、揮発または不揮発のメモリから構成可能である。キャッシュメモリ１３０が揮発性メモリを含んで構成される場合、図示せぬバッテリ電源等によりメモリバックアップを行うことが好ましい。

キャッシュメモリ１３０は、例えば、リードキャッシュ領域とライトキャッシュ領域との２つの領域から構成することができる。ライトキャッシュ領域は、例えば、キャッシュ面１３１とNVS（Non-volatile Storage）面１３２とを含んで構成することができる。これにより、ライトキャッシュ領域に格納されたデータは、多重記憶（冗長記憶）することができる。つまり、同一のデータがディスクドライブ１６１にも存在するリードデータは、仮に失われたとしても再びディスクドライブ１６１から読み出せば足りるので、多重化する必要はない。これに対し、ライトデータは、ストレージ装置１００内においては、キャッシュメモリ１３０にのみ存在するため、原則として、多重化記憶させるのが信頼性の点で好ましい。

共有メモリ（あるいは制御メモリとも呼ばれる）１４０は、例えば、不揮発メモリから構成可能であるが、揮発メモリから構成してもよい。共有メモリ１４０には、例えば、制御情報や管理情報等が記憶される。これらの制御情報等の情報は、複数のメモリ１４０により多重管理することができる。

共有メモリ１４０及びキャッシュメモリ１３０は、それぞれ別々のメモリパッケージとして構成することもできるし、同一のメモリパッケージ内にキャッシュメモリ１３０及び共有メモリ１４０を設けてもよい。また、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。つまり、共有メモリとキャッシュメモリとは、同一のメモリまたはメモリ群として構成することもできる。

接続制御部１５０は、各CHA１１０と、各DKA１２０と、キャッシュメモリ１３０と、共有メモリ１４０とをそれぞれ相互に接続するものである。これにより、全てのCHA１１０，DKA１２０は、キャッシュメモリ１３０及び共有メモリ１４０にそれぞれ個別にアクセス可能である。接続制御部１５０は、例えば、超高速クロスバスイッチ等として構成することができる。

なお、CHA１１０，DKA１２０，キャッシュメモリ１３０及び共有メモリ１４０を一つまたは複数のコントローラに集約することもできる。

記憶部１６０は、多数のディスクドライブ１６１を備えて構成される。記憶部１６０は、各CHA１１０及び各DKA１２０等のコントローラ部分と共に同一の筐体内に設けることもできるし、コントローラ部分とは別の筐体内に設けることもできる。

記憶部１６０は、例えば、複数種類のディスクドライブ１６１を混在させて構成することができる。ディスクドライブ１６１としては、例えば、ＦＣディスク（ファイバチャネルディスク）、SCSI（Small Computer System Interface）ディスク、SATA（Serial AT Attachment）ディスク等を用いることができる。なお、ディスクの種類は、上記のものに限定されず、例示したディスクドライブと同等の記憶デバイスまたは将来開発されるであろう記憶デバイスを利用可能な場合もある。

ここで、一般的には、ＦＣディスク、SCSIディスク、SATAディスクの順番で、データ処理性能が低下する。現在最もデータ処理性能が高いのは、ＦＣディスクである。データ処理性能には、例えば、IOPS（input/output per second）性能やMB/秒性能、データへのアクセス時間等を含めることができる。例えば、高性能で信頼性の高いＦＣディスクは、ミッションクリティカルなデータに高速にアクセスする必要がある場合に使用され、ＦＣディスクほど高性能ではないSATAディスクは、高速アクセス等が要求されないアーカイブデータの保存等に使用される。

記憶部１６０には、複数のパリティグループ（RAIDグループとも呼ばれる）１６２を設けることができる。各パリティグループ１６２は、同一種類の物理ディスク１６１からそれぞれ構成される。即ち、あるパリティグループ１６２は、ＦＣディスクのみから構成され、他のパリティグループ１６２は、SATAディスクのみから構成される。また、あるパリティグループ１６２は、SCSIディスクのみから構成される。

そして、詳細はさらに後述するが、各パリティグループ１６２がそれぞれ提供する論理的な記憶領域には、少なくとも一つ以上の論理ボリューム（LDEVとも呼ぶ）１６３を設けることができる。この論理ボリューム１６３をＬＵ（Logical Unit）１６４に対応付けることにより、オープン系のホスト１０は、物理的な記憶デバイスとして認識し、利用することができる。なお、オープン系ホスト１０のアクセス対象ボリュームはＬＵであるが、メインフレーム系ホストのアクセス対象は、論理ボリューム（LDEV）となる。

ところで、ストレージ装置１００が使用する記憶資源は、全てストレージ装置１００内に存在する必要はない。ストレージ装置１００は、ストレージ装置１００の外部に存在する記憶資源を、あたかも自己の記憶資源であるかのように取り込んで、利用することもできる。即ち、例えば、ストレージ装置１００は、ホスト１０を介さずに、外部に設置された自社の又は他社のストレージ装置（不図示）とSAN（Storage Area Network）等を介して直接的に接続することができる。そして、ストレージ装置１００は、外部のストレージ装置が有する論理ボリュームを、自己のＬＵやLDEVあるいは中間ボリュームにマッピングすることにより、外部の論理ボリュームを取り込むことができる。

SVP１７０は、LAN等の内部ネットワークＣＮ３を介して、各CHA１１０及び各DKA１２０とそれぞれ接続されている。SVP１７０は、ストレージ装置１００内部の各種状態を収集し、そのままで又は加工して、管理端末３０に提供する。

図３は、複数のストレージ装置１００，２００を含むストレージシステムの概略構成を示す説明図である。他のストレージ装置２００は、例えば、ストレージ装置１００と同様に構成することができ、コントローラ２０１，LDEV２６３，SVP２７０等を備え、コントローラ２０１は、キャッシュ面２３１及びNVS面２３２を備える。

ホスト１０は、各ストレージ装置１００，２００に対し、それぞれ同一のライトデータを書き込んで保持させることができる。この場合は、一方のストレージ装置１００のキャッシュメモリ１３０に異常が発生し、冗長記憶が不能となった場合でも、他方のストレージ装置２００に同一のライトデータが保持される。

従って、ストレージシステム全体としてライトデータの冗長性が確保されており、ストレージ装置１００のキャッシュメモリ異常時のライトアクセスをアフターライト方式で処理しても、信頼性は低下しない。

図４は、ストレージ装置１００の記憶構造に着目した構成説明図である。ストレージ装置１００の記憶構造は、物理的なディスクであるPDEV（Physical Device）１６１と、グループ化された複数のPDEV１６１が提供する仮想的な記憶領域であるVDEV（Virtual Device）１６２と、このVDEV１６２に設定されたLDEV（Logical Device）１６３とから構成することができる。ここで、PDEV１６１は、図２中のディスクドライブ１６１に対応し、VDEV１６２は、図２中のパリティグループ１６２に対応する。

ここで、幾つかの論理ボリューム（LDEV）には、LUN（Logical Unit Number ）がそれぞれ割り当てられており、オープン系ホスト１０からＬＵ１６４として認識される。オープン系ホスト１０は、ターゲットポート１１１を介して、アクセス権限のある論理ボリューム（ＬＵ１６４）にそれぞれアクセスする。ターゲットポート１１１は、図２中の各CHA１１０が提供する通信ポートである。

図４及び図５に示すように、パリティグループ（VDEV）の提供する記憶領域上には、それぞれ複数のLDEVを設けることができる。そして、図４中の左側に示すように、一つのLDEVを一つのＬＵに対応付けることもできるし、図４中の右側に示すように、複数のLDEVを一つのＬＵに対応付けることもできる。なお、図４では、一つの種類のPDEV１６１Ａと他の種類のPDEV１６１Ｂとが混在し、それぞれのパリティグループからLDEVが形成される様子が示されている。

さらに、図５の右側に示すように、それぞれ別々のパリティグループに所属する複数のLDEVを一つのＬＵに対応付けることもできる。また、図５に示すように、各ＬＵ「＃０」，「ＬＵ＃１２」には、それぞれライトスルーフラグが対応付けられている。詳細は後述するが、疑似スルーフラグとは、キャッシュ異常時におけるライトアクセスの処理モードを予め指定する情報であり、所定の単位毎にそれぞれ異なる値を設定可能である。ＬＵ単位でライトスルーフラグを設定する実施例については、後述する。

図６は、LDEV制御テーブルＴ１の一例を示す説明図である。LDEV制御テーブルＴ１は、図６（ｂ）に例えばＴ１ａ〜Ｔ１ｃとして示すように、各LDEV毎にそれぞれ設けられる。LDEV制御テーブルＴ１は、例えば、そのLDEVのRAIDレベル、スロットサイズ（記憶容量）等の属性情報と、上述のライトスルーフラグとを含んで構成可能である。

ライトスルーフラグは、各LDEV毎にそれぞれ個別に設定される。各LDEV毎に設定されたライトスルーフラグをそれぞれ抽出すると、図６（ｂ）に示すようなライトスルーフラグ管理テーブルＴ２を得ることができる。

図７は、LDEV番号変換テーブルＴ３及びパリティグループ−LDEV対応テーブルＴ４の一例を示す説明図である。LDEV番号テーブルＴ３は、例えば、ポート番号と、LUN（Logical Unit Number）と、LDEV番号とを対応付けることにより、構成可能である。このLDEV番号変換テーブルＴ３を参照することにより、いずれのLDEVを対象するアクセスであるかを判別することができる。

パリティグループ−LDEV対応テーブルＴ４は、LDEV番号と、そのLDEVが所属するパリティグループ番号とを対応付けることにより、構成可能である。これにより、あるパリティグループに属する全てのLDEVを抽出したり、あるLDEVがいずれのパリティグループに所属するのか調べることができる。

図８は、各LDEV毎にライトスルーフラグを設定するためのライトスルーフラグ設定処理の概要を示すフローチャートである。この処理は、例えば、SVP１７０により実行することができる。

例えば、システム管理者等のユーザは、管理端末３０のウェブヴラウザを介してSVP１７０の提供するウェブサーバにログインし（Ｓ１１）、パリティグループ管理画面を呼び出す（Ｓ１２）。そして、ユーザは、パリティグループ管理画面を見ながら、所望する一つまたは複数のLDEVについて、ライトスルーフラグを個別にセットする（Ｓ１３）。ユーザによるライトスルーフラグのセットが完了すると、SVP１７０は、共有メモリ１４０に格納されているLDEV制御テーブルＴ１を更新する（Ｓ１４）。また、SVP１７０は、更新されたLDEV制御テーブルＴ１の情報を各CHA１１０に転送させる（Ｓ１５）。そして、各CHA１１０は、共有メモリ１４０に記憶されたLDEV制御テーブルＴ１の更新結果に基づいて、ローカルメモリ（不図示）に記憶されているLDEV制御テーブルＴ１を更新させる。

図９は、ライトスルーフラグを設定する画面の様子を示す説明図である。ユーザは、図９（ａ）に示すようなパリティグループ管理画面を呼び出し、所望のLDEVが所属するパリティグループを選択し、ディステージボタンＢ１を押す。すると、図９（ｂ）に示すように、そのパリティグループに属する全てのLDEVのライトスルーフラグ設定状態を示す一覧表が画面に表示される。ここで、ライトスルーフラグが「オン」に設定されている場合は、ライトスルー（ライトスルー）方式でライトアクセスが処理され、ライトスルーフラグが「オフ」に設定されている場合は、ライトスルーは行われず、ライトアフター方式でライトアクセスが処理される。但し、ライトスルーフラグは、キャッシュメモリ１３０が冗長記憶できない異常時に参照される情報であり、キャッシュメモリ１３０が正常に動作している場合は、ライトスルーフラグの設定内容に拘わらず、ライトアフター方式でライトアクセスが処理される。

さて、次に、ユーザは、一覧表示された中から、所望のLDEVを一つまたは複数選択し、変更ボタンＢ２を押す。これにより、図９（ｃ）に示すように、選択されたLDEVのライトスルーフラグは、オンからオフに、あるいは、オフからオンに変化する。即ち、変更ボタンＢ２を操作すると、既に設定されているライトスルーフラグの値が反転する。なお、ライトスルーフラグの初期値は、オンに設定されている。これにより、キャッシュメモリ１３０の異常時には、ライトスルーフラグがオフに設定されていない限り、そのLDEVを対象とするライトアクセスは、ライトスルー方式で処理される。即ち、キャッシュメモリ１３０の片方のライトキャッシュに記憶されたライトデータは、直ちにLDEVにも書き込まれ、LDEVへの書込みを完了した後で、ホスト１０に書込み完了が報告される。

図１０は、ライトコマンド処理の全体概要を示すフローチャートである。この処理には、以下に述べるように、３種類のライトアクセス処理モードが含まれている。この処理は、CHA１１０またはDKA１２０のいずれか又は双方により実行される。

まず、CHA１１０がホスト１０からのライトコマンドを受信すると、CHA１１０は、ライトコマンドに含まれているポート番号やLUNに基づいてLDEV番号変換テーブルＴ３を参照することにより、目的のLDEV番号に変換する（Ｓ２１）。

次に、CHA１１０は、キャッシュメモリ１３０のキャッシュ面１３１及びNVS面１３２の両方が正常に使用可能であるか否かを判定する（Ｓ２２）。両面とも正常な場合は（S22：YES）、両方の面１３１，１３２にそれぞれライトデータ格納用の記憶領域を設定し、ホスト１０から受信したライトデータをそれぞれ記憶させる（Ｓ２３）。CHA１１０は、キャッシュ面１３１及びNVS面１３２の両方でそれぞれライトデータを保持させた後、直ちに、ホスト１０に対して書込み完了を報告する（Ｓ２４）。

キャッシュ面１３１及びNVS面１３２のそれぞれにライトデータが格納されたことは、例えば、共有メモリ１４０を介してDKA１２０に通知される。DKA１２０は、キャッシュ面１３１からライトデータを読み取り、そのライトデータが書き込まれるべきLDEVを構成する所定のディスクドライブ１６１に、ライトデータを書き込む（Ｓ２５）。以上のＳ２３〜Ｓ２５の処理は、キャッシュメモリ１３０が正常な場合（冗長記憶可能な場合）においてライトアクセスを処理するための第１処理モード（アフターライト方式）に該当する。

一方、キャッシュメモリ１３０に異常が発生し、ライトキャッシュの片面が閉塞されたような場合（S22：NO）、CHA１１０は、ライトアクセスの対象となっているLDEVに設定されているライトスルーフラグを参照し、ライトスルーフラグがオフにセットされているか否かを判定する（Ｓ２６）。

ライトスルーフラグがオフに設定されていない場合（S26：NO）、即ち、そのLDEVのライトスルーフラグがオンに設定されている場合、CHA１１０は、DKA１２０によって、ホスト１０から受信したライトデータを直ちにそのLDEVに書き込ませる（Ｓ２７）。DKA１２０がそのLDEVを構成するディスクドライブ１６１への書込みを完了すると、CHA１１０は、ホスト１０に対して、書込み完了を報告する（Ｓ２８）。以上述べたＳ２６及びＳ２７の処理は、キャッシュメモリ１３０が異常な場合（冗長記憶できない場合）においてライトアクセスを処理するための第２処理モード（ライトスルーモード）に該当する。

キャッシュメモリに異常が発生している場合において、ライトアクセスの対象となっているLDEVのライトスルーフラグが「オフ」に設定されている場合（S26：YES）、CHA１１０は、正常なライトキャッシュにライトデータを書き込んだ後（Ｓ２９）、直ちにホスト１０に対して書込み完了を報告する（Ｓ３０）。そして、DKA１２０は、第１処理モードと同様に、ホスト１０への書込み完了報告と非同期に、ライトデータを所定のLDEVに書き込む（Ｓ３１）。以上のＳ２９〜Ｓ３１の処理は、キャッシュメモリが異常な場合においてライトアクセスを処理するための第３処理モードに該当する。

以下、各処理モードの詳細を説明する。図１１は、第１処理モードの動作を示すフローチャートである。まず、CHA１１０は、ホスト１０からライトコマンドを受信すると（Ｓ４１）、このライトコマンドを解析し（Ｓ４２）、書込みを要求されたLDEV番号を検出する。次に、書込みを要求されたデータがキャッシュメモリ１３０上に存在するか否かを判定する（Ｓ４３）。通常の場合、ここではキャッシュミスと判定され（S43：YES）、CHA１１０は、キャッシュメモリ１３０のキャッシュ面１３１及びNVS面１３２の両方に、それぞれ必要な量だけキャッシュスロットを割り当てる（Ｓ４４）。このキャッシュスロットは、ライトデータを格納するための記憶領域である。

CHA１１０は、キャッシュスロットの割当によってライトデータの受信準備が完了すると、ホスト１０からライトデータを受信して各面１３１，１３２にそれぞれ記憶させる（Ｓ４５）。CHA１１０は、ライトデータを各面１３１，１３２にそれぞれ記憶させた後、ホスト１０に対して書込み完了を報告する（Ｓ４６）。そして、CHA１１０は、ライトデータを格納したキャッシュスロットを、ダーティキューに登録する（Ｓ４７）。キャッシュスロットの状態は、例えば、共有メモリ１４０に記憶されているキャッシュスロット管理テーブルＴ６により管理される。キャッシュスロット管理テーブルＴ６は、例えば、キャッシュスロット番号と、各キャッシュスロットの状態（ダーティ状態、クリーン状態、フリー状態）とを対応付けることにより、構成することができる。

ここで、ダーティキューとは、ディスクドライブ１６１にデータが書き込まれていない状態のキャッシュスロットを管理するためのキューである。なお、このほかに、例えば、ディスクドライブ１６１にデータを反映済みのキャッシュスロットを管理するクリーンキュー、未使用のキャッシュスロットを管理するフリーキューがある。

キャッシュスロットのステータスは、ダーティキューに登録されたダーティ状態と、クリーンキューに登録されたクリーン状態と、フリーキューに繋がれたフリー状態との間で遷移する。例えば、ダーティキューに繋がれたキャッシュスロットのデータがディスクドライブ１６１に書き込まれると、そのキャッシュスロットはクリーンキューに再登録され、クリーン状態に遷移する。そして、そのキャッシュスロットを開放するとフリー状態に遷移する。フリー状態のキャッシュスロットは、他のライトアクセスまたはリードアクセスのために確保されて再使用される。

DKA１２０は、共有メモリ１４０を随時参照しており、ダーティキュー内に未処理のキャッシュスロットを発見すると（S51：YES）、ディステージ処理を開始する。ディステージ処理とは、キャッシュメモリ１３０に記憶されているデータを所定のディスクドライブ１６１に書き込む処理である。まず、DKA１２０は、ディステージすべきライトデータがキャッシュメモリ１３０に記憶されているか否かを判定する（Ｓ５２）。ここでは、通常、キャッシュヒットと判定されるが、万が一キャッシュミスと判定された場合は（S52：YES）、本処理を異常終了する。

処理すべきライトデータを発見した場合（S52：NO）、DKA１２０は、そのライトデータに対応付けられた論理アドレスを物理アドレスに変換し（Ｓ５３）、転送用のスクリプトを生成する（Ｓ５４）。この転送用のスクリプトは、ホスト１０から受信したライトデータを所定のディスクドライブ１６１に書き込ませるためのプログラムである。

転送用スクリプトによって、ライトデータのディスクドライブ１６１への書込みが開始される（Ｓ５５）。ディスクドライブ１６１への書込みが完了すると（S56：YES）、DKA１２０は、キャッシュ面１３１及びNVS面１３２の両方で管理されているライトデータうち、NVS面１３２を破棄する（Ｓ５７）。これにより、そのライトデータのステータスは、冗長記憶されるダーティ状態から非冗長記憶されるクリーン状態に遷移する。

そして、DKA１２０は、キャッシュ面１３１に記憶されているキャッシュスロットについて、ステージングビットマップ（不図示）を設定し、処理を終了する（Ｓ５８）。ここで、ステージングビットマップとは、キャッシュメモリ１３０上に置かれているデータであることを示す管理用の情報であり、このステージングビットマップを参照することにより、ホスト１０からのリードアクセスに速やかに応答することができる。

図１２は、第２処理モードの動作を示すフローチャートである。CHA１１０は、ホスト１０からライトコマンドを受信すると（Ｓ６１）、ライトコマンドを解析してLDEV番号を検出し（Ｓ６２）、キャッシュミスか否かを判定する（Ｓ６３）。

キャッシュミスと判定された場合（S63：YES）、CHA１１０は、キャッシュ面１３１のみに、必要な量だけキャッシュスロットを割り当て（Ｓ６４）、ホスト１０からのライトデータを受信してキャッシュ面１３１に記憶させる（Ｓ６５）。CHA１１０は、ライトデータをキャッシュ面１３１に記憶させた後、DKA１２０に対して、ディステージ処理を要求する（Ｓ６６）。

そして、CHA１１０は、DKA１２０からディステージ処理の完了が報告されるのを待ち（Ｓ６７）、ディステージ処理の完了を確認した後で（S67：YES）、ホスト１０に対して書込み完了を報告する（Ｓ６８）。

DKA１２０は、CHA１１０からディステージ要求が発行されると（S71：YES）、ディステージ処理を開始する。即ち、第２処理モードでは、ディステージ処理の開始とホスト１０への書込み完了報告とが同期している。

まず、DKA１２０は、キャッシュミスの判定を行い（Ｓ７２）、処理すべきライトデータを発見した場合（S72：NO）、DKA１２０は、そのライトデータの論理アドレスを物理アドレスに変換し（Ｓ７３）、転送用スクリプトを生成する（Ｓ７４）。

転送用スクリプトにより、ライトデータのディスクドライブ１６１への書込みが開始され（Ｓ７５）、ディスクドライブ１６１への書込みが完了すると（S76：YES）、DKA１２０は、キャッシュ面１３１に記憶されているキャッシュスロットについて、ステージングビットマップを設定する（Ｓ７７）。そして、DKA１２０は、ディステージ処理が完了した旨をCHA１１０に報告する（Ｓ７８）。

図１３は、第３処理モードの動作を示すフローチャートである。第３処理モードは、第１処理モードと同様の処理を行う。しかし、第３処理モードは、片面のライトキャッシュにのみライトデータを保持した時点で、ホスト１０に書込み完了を報告するため、第１処理モードとは幾つかのステップが相違する。

CHA１１０は、ホスト１０からライトコマンドを受信すると（Ｓ８１）、このライトコマンドを解析し（Ｓ８２）、書込みを要求されたLDEV番号を検出する。次に、CHA１１０は、キャッシュミスか否かの判定を行った後（Ｓ８３）、キャッシュ面１３１にのみ、必要な量だけキャッシュスロットを割り当てる（Ｓ８４）。

CHA１１０は、ホスト１０からライトデータを受信してキャッシュ面１３１に記憶させた後（Ｓ８５）、ホスト１０に対して書込み完了を報告する（Ｓ８６）。そして、CHA１１０は、ライトデータを格納したキャッシュスロットを、ダーティキューに登録する（Ｓ８７）。

DKA１２０は、ダーティキュー内に未処理のキャッシュスロットを発見すると（S91：YES）、ディステージ処理を開始する。DKA１２０は、ディステージすべきライトデータがキャッシュメモリ１３０に記憶されているか否かを判定し（Ｓ９２）、処理すべきライトデータを発見した場合（S92：NO）、そのライトデータに対応付けられた論理アドレスを物理アドレスに変換し（Ｓ９３）、転送用スクリプトを生成する（Ｓ９４）。

転送用スクリプトによって、ライトデータのディスクドライブ１６１への書込みが開始される（Ｓ９５）。ディスクドライブ１６１への書込みが完了すると（S96：YES）、DKA１２０は、キャッシュ面１３１に記憶されているキャッシュスロットについて、ステージングビットマップを設定し、処理を終了する（Ｓ９７）。

図１４は、ホスト１０からリードアクセスがあった場合の処理を示すフローチャートである。まず、CHA１１０は、ホスト１０からリードコマンドを受信すると（Ｓ１０１）、このリードコマンドを解析し（Ｓ１０２）、ステージングビットマップを参照することにより、読出しを要求されたデータがキャッシュメモリ１３０上に存在するか否かを判定する（Ｓ１０３）。

要求されたデータが既にキャッシュメモリ１３０に記憶されている場合（S103：NO）、CHA１１０は、そのデータを読出してホスト１０に送信する（Ｓ１０７）。要求されたデータがキャッシュメモリ１３０に記憶されていない場合（S103：YES）、CHA１１０は、ディスクドライブ１６１から読み出されたデータを格納するために、キャッシュ面１３１にキャッシュスロットを割り当て（Ｓ１０４）、DKA１２０にステージング処理の開始を要求する（Ｓ１０５）。ステージング処理とは、ディスクドライブ１６１から所定のデータを読出してキャッシュメモリ１３０に記憶させる処理である。

CHA１１０は、DKA１２０からのステージング処理の完了報告を待ち（Ｓ１０６）、ステージング処理の完了を確認すると（S106：YES）、キャッシュ面１３１に記憶されたデータを読出して、ホスト１０に送信する（Ｓ１０７）。

一方、DKA１２０は、CHA１１０からのステージング要求を受信すると（S111：YES）、要求されたリードデータがキャッシュメモリ１３０上に存在するか否かを判定する（Ｓ１１２）。キャッシュメモリ１３０上にリードデータが存在しない場合（S112：YES）、DKA１２０は、要求されたリードデータの論理アドレスを物理アドレスに変換し（Ｓ１１３）、データ読出し用の転送スクリプトを生成する（Ｓ１１４）。この転送スクリプトに基づいて、所定のディスクドライブ１６１からリードデータが読み出され（Ｓ１１５）、読み出されたデータはキャッシュ面１３１に記憶される。要求されたリードデータの読出しを完了すると（S116：YES）、DKA１２０は、ステージング処理が完了した旨をCHA１１０に報告する（Ｓ１１７）。

本実施例は上述のように構成されるので、以下の効果を奏する。各LDEV毎に、それぞれ異なるライトアクセス時の処理モードを個別に設定できるため、例えば、各LDEVの利用形態や運用方針等に従って柔軟な処理を行うことができ、使い勝手が向上する。

また、キャッシュメモリ１３０が正常な場合は、全てのLDEVについて第１処理モードをそれぞれ適用し、キャッシュメモリ１３０に異常状態が発生した場合は、ライトスルーフラグに基づいて、第２処理モードまたは第３処理モードのいずれかを適用する構成を採用した。従って、キャッシュメモリ１３０が正常な場合は、データロスの耐久性とアクセス性とを両立させ、キャッシュメモリ１３０の異常時には、データロスの耐久性を高めるか、それともライトアクセスの性能維持を図るかのいずれかを、ユーザが適宜自由に選択することができ、使い勝手が向上する。

さらに、ライトスルーフラグの初期値として第２処理モードを選択するようにしたので、ユーザが明示の選択を行わない限り、データロスの発生を回避することができ、信頼性が向上する。例えば、データマイグレーションやボリュームコピー等のような属性の移行を伴わないデータ移動イベントが発生した場合に、そのボリューム（LDEV）のライトスルーフラグを初期値に設定することにより、信頼性を高めることができる。

図１５〜図１７に基づいて、本発明の第２実施例を説明する。以下に述べる各実施例は、第１実施例の変形例に相当する。本実施例の特徴は、一つのＬＵを構成する複数のLDEVのうち、いずれかのLDEVについて処理モードが変更された場合は、他のLDEVの処理モードも自動的に変更させる点にある。

図１５のLDEV番号変換テーブルＴ３に示すように、例えば、LDEV「＃０」とLDEV「＃１０」との２つのLDEVから一つのＬＵ「＃０」を構成することができる。図１６は、ライトスルーフラグの設定処理及び補正処理を示すフローチャートである。本実施例では、SVP１７０によって所望のLDEVのライトスルーフラグを変更すると、このLDEVに関連する他のLDEVのライトスルーフラグがCHA１１０によって自動的に変更される。

Ｓ１１〜Ｓ１５の処理は既に述べたので説明を省略するが、この処理では、ユーザは、所望のLDEVについてライトスルーフラグを設定する。所定のCHA１１０は、同一のＬＵを構成するLDEVを検出する（Ｓ１２１）。CHA１１０は、関連するLDEV同士のライトスルーフラグを検出し（Ｓ１２２）、関連するLDEV同士のライトスルーフラグが一致しているか否かを判定する（Ｓ１２３）。

例えば、同一のＬＵを構成するLDEV群のうちいずれか一つのLDEVに設定されているライトスルーフラグが、他のLDEVに設定されているライトスルーフラグと異なる場合（S123：NO）、他のLDEVのライトスルーフラグを変更させることにより、関連するLDEV群のライトスルーフラグを一致させる（Ｓ１２４）。例えば、ライトスルーフラグの変更が行われた時期に基づいて、最新のライトスルーフラグを優先し、他のライトスルーフラグを最新のライトスルーフラグと同一の値となるように補正する。関連するLDEV群のライトスルーフラグが一致する場合（S123：YES）、Ｓ１２４の補正処理はスキップされる。そして、CHA１１０は、共有メモリ１４０及びローカルメモリに記憶されたLDEV制御テーブルＴ１をそれぞれ更新させる（Ｓ１２５）。

図１７は、CHA１１０によって関連するLDEVのライトスルーフラグが補正される様子を示す説明図である。図１７の左側に示すように、ユーザがSVP１７０を介してLDEV「＃０」のライトスルーフラグを「オン」に設定した場合、CHA１１０は、図１７の右側に示すように、このLDEV「＃０」と共に同一のＬＵを構成する他のLDEV「＃１０」のライトスルーフラグを「オン」に設定する。

本実施例によれば、同一のＬＵに属する複数のLDEVのうちいずれか一つのLDEVについて、ユーザがライトスルーフラグを変更した場合でも、そのLDEVと共に同一のＬＵを構成する他のLDEVのライトスルーフラグを自動的に変更する構成とした。従って、キャッシュメモリ１３０の異常時に、同一のＬＵに属する各LDEVを同一の処理モードで運用することができる。また、ユーザは、ＬＵの構成を意識することなく、自由にLDEV単位でライトスルーフラグを設定することができ、使い勝手が向上する。

図１８は、本発明の第３実施例に係るライトスルーフラグ設定処理を示すフローチャートである。本実施例では、SVP１７０において、ライトスルーフラグの設定及び補正の両方を実行する。

即ち、ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ１３１）、パリティグループ管理画面を呼び出して（Ｓ１３２）、所望のLDEVについてライトスルーフラグを個別に設定する（Ｓ１３３）。

SVP１７０は、ユーザによるライトスルーフラグの設定が完了すると、同一のＬＵに属するLDEVを検出し（Ｓ１３４）、これら互いに関連するLDEV群のライトスルーフラグが一致するか否かを検査する（Ｓ１３５）。関連するLDEV群のライトスルーフラグが一致しない場合（S136：NO）、SVP１７０は、先の実施例で述べたと同様の方法で、ライトスルーフラグを一致させる（Ｓ１３７）。そして、第１実施例で述べたように、SVP１７０は、LDEV制御テーブルＴ１を更新し（Ｓ１３８）、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ１３９）。

図１９及び図２０に基づいて第４実施例を説明する。本実施例では、各ＬＵ毎にそれぞれライトアクセス用の処理モードを個別に設定する。

ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ１４１）、図２０の上側に示すようなライトスルーフラグ設定画面を呼び出して、所望のＬＵについてライトスルーフラグを設定する（Ｓ１４２）。

SVP１７０は、例えば、LDEV番号変換テーブルＴ３を参照することにより、ユーザによってライトスルーフラグが設定（変更）されたＬＵに所属するLDEVをそれぞれ検出する（Ｓ１４３）。SVP１７０は、例えば、図２０の下側にライトスルーフラグ管理テーブルＴ２として示すように、そのＬＵに属する全てのLDEVのライトスルーフラグを変更させる（Ｓ１４４）。なお、ライトスルーフラグ管理テーブルＴ２は、説明の便宜上使用されるもので、SVP１７０は、そのＬＵに属する各LDEVを管理する各LDEV制御テーブルＴ１中のライトスルーフラグを直接変更することができる（Ｓ１４５）。そして、SVP１７０は、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ１４６）。

図２１は、第５実施例に係るライトスルーフラグ設定処理のフローチャートを示す。本実施例では、ユーザは、SVP１７０によってＬＵ毎に処理モードを設定し、CHA１１０によってそのＬＵに属する各LDEVのライトスルーフラグが変更される。

ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ１５１）、所望のＬＵについてライトスルーフラグを個別に設定する（Ｓ１５２）。SVP１７０は、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ１５３）。

各CHA１１０のうち所定の一つのCHA１１０は、ライトスルーフラグが変更されたＬＵに所属するLDEVを検出し（Ｓ１６１）、検出された各LDEVのライトスルーフラグを変更し（Ｓ１６２）、LDEV制御テーブルＴ１を更新させる（Ｓ１６３）。

このように、見かけ上はＬＵ単位でライトスルーフラグを個別に設定するが、実際には、そのＬＵに属する各LDEVのライトスルーフラグを変更する。そして、見かけ上のライトスルーフラグの設定単位と実際の設定単位とを階層化することにより、より使い勝手が向上する。

図２２及び図２３に基づいて、第６実施例を説明する。本実施例では、あるLDEVについてライトスルーフラグを変更した場合に、そのLDEVと同一のパリティグループに所属する他のLDEVのライトスルーフラグを自動的に変更して一致させる。

ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ１７１）、所望のLDEVについてライトスルーフラグを設定（変更）する（Ｓ１７２）。SVP１７０は、LDEV制御テーブルＴ１を更新し（Ｓ１７３）、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ１７４）。

所定のCHA１１０は、LDEV制御テーブルＴ１が更新されたことを検知すると、ライトスルーフラグが更新されたLDEVと同一のパリティグループに属する全てのLDEVを検出する（Ｓ１８１）。CHA１１０は、同一のパリティグループに属する各LDEVのライトスルーフラグを検出し、これら各フラグが一致するか否かを判定し（Ｓ１８３）、各フラグが一致しない場合は（S183：NO）、図２３に示すように、同一パリティグループ内の各ライトスルーフラグを一致させる（Ｓ１８４）。そして、CHA１１０は、LDEV制御テーブルＴ１を更新させて処理を終了する（Ｓ１８５）。

図２３には、LDEV「＃０」〜「＃３」がそれぞれ同一のパリティグループに所属している場合に、LDEV「＃０」のライトスルーフラグが「オン」に設定された場合は、他のLDEV「＃１」〜「＃３」の全てのライトスルーフラグも「オン」に設定される様子が示されている。

図２４に基づいて第７実施例を説明する。本実施例では、SVP１７０内において、同一のパリティグループに属する各LDEVのライトスルーフラグを一致させる。

ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ１９１）、パリティグループ管理画面を呼び出して（Ｓ１９２）、所望のLDEVについてライトスルーフラグを設定（変更）する（Ｓ１９３）。そして、SVP１７０は、ライトスルーフラグが更新されたLDEVと同一のパリティグループに属する全てのLDEVを検出し（Ｓ１９４）、それらに設定されたライトスルーフラグをそれぞれ検出する（Ｓ１９５）。

SVP１７０は、検出された各ライトスルーフラグが一致するか否かを判定し（Ｓ１９６）、各フラグが一致しない場合は（S196：NO）、同一パリティグループ内の各ライトスルーフラグを一致させる（Ｓ１９７）。SVP１７０は、LDEV制御テーブルＴ１を更新し（Ｓ１９８）、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ１９９）。

図２５及び図２６に基づいて第８実施例を説明する。本実施例では、パリティグループ単位でライトアクセス用の処理モードをそれぞれ個別に設定可能としている。図２５は、本実施例によるライトスルーフラグ設定処理を示すフローチャートである。

ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ２０１）、図２６の上側に示すようなライトスルーフラグ設定画面を呼び出して、所望のパリティグループについてライトスルーフラグを設定する（Ｓ２０２）。

SVP１７０は、例えば、パリティグループ−LDEV対応テーブルＴ４を参照することにより、ユーザによってライトスルーフラグが設定（変更）されたパリティグループに所属する全てのLDEVをそれぞれ検出する（Ｓ２０３）。

SVP１７０は、例えば、図２６の下側にライトスルーフラグ管理テーブルＴ２として示すように、そのパリティグループに属する全てのLDEVのライトスルーフラグを変更させる（Ｓ２０４）。SVP１７０は、そのパリティグループに属する各LDEVを管理する各LDEV制御テーブルＴ１中のライトスルーフラグを更新し（Ｓ２０５）、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ２０６）。

図２７は、第９実施例に係るライトスルーフラグ設定処理のフローチャートを示す。本実施例では、ユーザは、SVP１７０によってパリティグループ毎に処理モードを設定し、CHA１１０によってそのパリティグループに属する各LDEVのライトスルーフラグがそれぞれ変更される。

ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ２１１）、所望のパリティグループについてライトスルーフラグを個別に設定する（Ｓ２１２）。SVP１７０は、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ２１３）。

所定のCHA１１０は、ライトスルーフラグが変更されたパリティグループに所属するLDEVを検出し（Ｓ２２１）、検出された各LDEVのライトスルーフラグを変更し（Ｓ２２２）、LDEV制御テーブルＴ１を更新させる（Ｓ２２３）。

図２８及び図２９に基づいて第１０実施例を説明する。本実施例では、ディスクドライブ１６１の種別毎にライトアクセス用の処理モードをそれぞれ個別に設定できるようにしている。図２８は、ライトスルーフラグ設定処理を示すフローチャートである。

ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ２３１）、図２９の上側に示すようなライトスルーフラグ設定画面を呼び出して、所望のディスク種別についてライトスルーフラグを設定する（Ｓ２３２）。

SVP１７０は、例えば、共有メモリ１４０に記憶されているパリティグループ管理テーブルＴ５を参照することにより、ユーザによってライトスルーフラグが設定（変更）されたディスク種別のディスクドライブ１６１を用いるパリティグループをそれぞれ検出する（Ｓ２３３）。ここで、パリティグループ管理テーブルＴ５は、例えば、パリティグループ番号と、そのRAIDレベルと、ドライブタイプとをそれぞれ対応付けることにより、構成することができる。さらにドライブタイプには、例えば、ディスク種別と、記憶容量と、ディスクドライブの供給者名とを含めることができる。

そして、SVP１７０は、パリティグループ−LDEV対応テーブルＴ４を参照することにより、検出された各パリティグループにそれぞれ属するLDEVを全て検出し（Ｓ２３４）、例えば、図２９の下側にライトスルーフラグ管理テーブルＴ２として示すように、そのパリティグループに属する全てのLDEVのライトスルーフラグをそれぞれ変更させる（Ｓ２３５）。SVP１７０は、そのパリティグループに属する各LDEVを管理する各LDEV制御テーブルＴ１中のライトスルーフラグを更新し（Ｓ２３６）、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ２３７）。

これにより、例えば、ディスクの種別に応じて、キャッシュメモリ１３０に異常が発生した場合のライトアクセスを処理することができる。

図３０に基づいて第１１実施例を説明する。本実施例では、SVP１７０とCHA１１０との協働により、ディスクドライブ１６１の種別毎にライトアクセス用の処理モードをそれぞれ個別に設定する。

図３０は、ライトスルーフラグ設定処理を示すフローチャートである。ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ２４１）所望のディスク種別についてライトスルーフラグを設定する（Ｓ２４２）。SVP１７０は、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ２４３）。

所定のCHA１１０は、ライトスルーフラグが設定されたディスク種別のディスクドライブ１６１を用いるパリティグループをそれぞれ検出し（Ｓ２５１）、検出された各パリティグループにそれぞれ属するLDEVを全て検出し（Ｓ２５２）、そのパリティグループに属する全てのLDEVのライトスルーフラグをそれぞれ変更させる（Ｓ２５３）。CHA１１０は、そのパリティグループに属する各LDEVを管理する各LDEV制御テーブルＴ１中のライトスルーフラグをそれぞれ更新する（Ｓ２５４）。

図３１及び図３２に基づいて第１２実施例を説明する。本実施例では、RAIDレベル毎にライトアクセス用の処理モードをそれぞれ個別に設定できるようにしている。図３１は、ライトスルーフラグ設定処理を示すフローチャートである。

ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ２６１）、図３２の上側に示すようなライトスルーフラグ設定画面を呼び出して、所望のRAIDレベルについてライトスルーフラグを設定する（Ｓ２６２）。SVP１７０は、ライトスルーフラグが設定されたRAIDレベルのパリティグループをそれぞれ検出する（Ｓ２６３）。

SVP１７０は、パリティグループ−LDEV対応テーブルＴ４を参照することにより、検出された各パリティグループにそれぞれ属するLDEVを全て検出し（Ｓ２６４）、例えば、図３２の下側にライトスルーフラグ管理テーブルＴ２として示すように、そのパリティグループに属する全てのLDEVのライトスルーフラグをそれぞれ変更させる（Ｓ２６５）。SVP１７０は、そのパリティグループに属する各LDEVを管理する各LDEV制御テーブルＴ１中のライトスルーフラグを更新し（Ｓ２６６）、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ２６７）。

これにより、例えば、RAIDレベルに応じて、キャッシュメモリ１３０に異常が発生した場合のライトアクセスを処理することができる。例えば、RAID０の場合は、単に記憶容量を結合させているだけであり、ライトスルー動作を行っても、処理時間はそれほどかからない。即ち、ライトペナルティは小さい。また、RAID１の場合は、ミラーリングを行うだけで複雑な演算等は必要としないため、ライトペナルティは小さい。従って、例えば、RAID０やRAID１については、ライトスルーフラグをオンに設定し、ライトスルーでライトアクセスを処理することができる。また、RAID５のようなパリティ計算を必要するRAIDレベルの場合は、旧データ及び旧パリティを読出した後、パリティを再計算し、新データ及び新パリティを書込む必要があり、ライトペナルティが大きい。そこで、RAID５等の場合は、ライトスルーフラグをオフに設定して、応答性の維持を図ることができる。

図３３に基づいて第１３実施例を説明する。本実施例では、SVP１７０とCHA１１０との協働により、ディスクドライブ１６１の種別毎にライトアクセス用の処理モードをそれぞれ個別に設定する。

図３３は、ライトスルーフラグ設定処理を示すフローチャートである。ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ２７１）所望のRAIDレベルについてライトスルーフラグを設定する（Ｓ２７２）。SVP１７０は、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ２７３）。

所定のCHA１１０は、ライトスルーフラグが設定されたRAIDレベルのパリティグループをそれぞれ検出する（Ｓ２８１）。CHA１１０は、検出された各パリティグループにそれぞれ属するLDEVを全て検出し（Ｓ２８２）、そのパリティグループに属する全てのLDEVのライトスルーフラグをそれぞれ変更させる（Ｓ２８３）。CHA１１０は、そのパリティグループに属する各LDEVを管理する各LDEV制御テーブルＴ１中のライトスルーフラグをそれぞれ更新する（Ｓ２８４）。

図３４〜図３６に基づいて第１４実施例を説明する。本実施例では、ストレージ装置１００内に設けられた仮想筐体（SLPR）毎に、キャッシュメモリ異常時のライトアクセス用の処理モードをそれぞれ設定可能としている。

図３４は、ストレージシステムの構成を簡略化して示す説明図である。ストレージ装置１００には、複数のSLPRを設けることができる。SLPRとは、ストレージ装置１００のキャッシュメモリやボリューム等の資源を論理的に分割して形成されるもので、各SLPRは、一つのストレージ装置１００内に存在する独立した仮想的なストレージ装置のように振る舞う。

各SLPR１，２は、仮想的なコントローラ１０１Ａ，１０１Ｂと、仮想的なキャッシュメモリと、ボリューム１６３Ａ，１６３Ｂとをそれぞれ有する。SLPR１は、ライトキャッシュとしてキャッシュ面１３１Ａ及びNVS面１３２Ａを備え、同様に、SLPR２は、ライトキャッシュとしてキャッシュ面１３１Ｂ及びNVS面１３２Ｂを備えている。但し、これらのコントローラ１０１Ａ，１０１Ｂやライトキャッシュ等は、その物理的存在が別々に形成されているわけではなく、ストレージ装置１００の有する制御機能やキャッシュメモリが論理的に分割されて構成されている。

図３５は、ライトスルーフラグ設定処理を示すフローチャートである。ユーザは、管理端末３０を介してSVP１７０にログインし（Ｓ２９１）、図３６の上側に示すようなライトスルーフラグ設定画面を呼び出して、所望のSLPRについてライトスルーフラグを設定する（Ｓ２９２）。SVP１７０は、ライトスルーフラグが設定されたSLPR内のパリティグループをそれぞれ検出する（Ｓ２９３）。

SVP１７０は、パリティグループ番号とSLPR番号とを対応付けて管理するSLPR管理テーブルＴ７及びパリティグループ−LDEV対応管理テーブルＴ４を参照することにより、検出された各パリティグループにそれぞれ属するLDEVを全て検出する（Ｓ２９４）。SVP１７０は、例えば、図３６の下側にライトスルーフラグ管理テーブルＴ２として示すように、そのパリティグループに属する全てのLDEVのライトスルーフラグをそれぞれ変更させる（Ｓ２９５）。SVP１７０は、そのパリティグループに属する各LDEVを管理する各LDEV制御テーブルＴ１中のライトスルーフラグを更新し（Ｓ２９６）、更新された情報を各CHA１１０にそれぞれ転送させる（Ｓ２９７）。

図３７及び図３８に基づいて第１５実施例を説明する。本実施例では、同一のデータをそれぞれ記憶する複数のストレージ装置１００，２００において、一方のストレージ装置に障害が発生した場合は、他方のストレージ装置のキャッシュメモリ異常時におけるライトアクセス用処理モードを変更する。

図３７は、本実施例によるストレージシステムの全体構成を示す。このストレージシステムには、２つのストレージ装置１００，２００が含まれている。ストレージ装置２００は、ストレージ装置１００と同様に構成することができ、例えば、コントローラ２０１，LDEV２６３，SVP２７０等を備える。なお、各ストレージ装置１００，２００は、同一の構成を備える必要はない。

ホスト１０は、ストレージ装置１００のLDEV１６３とストレージ装置２００のLDEV２６３との両方にそれぞれ同一のデータを書き込む。ストレージ装置１００は、ホスト１０からのライトデータをキャッシュ面１３１，NVS面１３２の両方に記憶させた後、書込み完了を報告する。同様に、ストレージ装置２００も、ホスト１０からのライトデータをキャッシュ面２３１，NVS面２３２の両方に記憶させた後、書込み完了を報告する。

ここで、例えば、ストレージ装置１００のキャッシュメモリ１３０に障害が発生した場合、このストレージ装置１００は、上述のように第２処理モードまたは第３処理モードのいずれかに従ってライトアクセスを処理する。他方のストレージ装置２００が正常に稼働している場合、同一のライトデータがストレージ装置２００にも記憶されるため、ストレージ装置１００においては、第３処理モードをより多く用いることができる。

ストレージ装置１００のキャッシュメモリ１３０のみに記憶されたライトデータが仮に失われたとしても、このライトデータと同一のデータは、ストレージ装置２００に記憶されている。

しかし、ストレージ装置２００に障害が発生してシステムダウンしたような場合は、ストレージ装置１００のみがライトデータを保持することになり、ストレージシステムにおけるストレージ装置１００の重要性が高まる。同様に、先にストレージ装置２００がシステムダウンした場合も、残されたストレージ装置１００のみがライトデータを保持することになる。そこで、本実施例では、相手方のストレージ装置２００に障害が発生した場合に、ストレージ装置１００のライトアクセス用処理モードを変更する。

図３８は、ライトスルーフラグ変更処理を示すフローチャートである。ストレージ装置１００で実行される場合を例に挙げて説明すると、ストレージ装置１００のSVP１７０とストレージ装置２００のSVP２７０とは、LAN等の通信ネットワークＣＮ４を介して互いに作動状況を監視している（Ｓ３０１）。

SVP１７０は、相手方のストレージ装置２００に異常が発生したことを検知すると（S302：YES）、所定の単位（例えば、LDEV、ＬＵ、パリティグループ、ディスク種別等）毎にそれぞれ設定されているライトスルーフラグをオンに変更する（Ｓ３０３）。SVP１７０は、LDEV制御テーブルを更新し（Ｓ３０４）、更新された情報を各CHA１１０に転送させる（Ｓ３０５）。

このように、本実施例では、ストレージシステム全体としての冗長度が低下した場合は、ストレージ装置単体での冗長度を高めることにより、ストレージシステムの信頼性を維持する。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、ライトデータをライトキャッシュにより二重記憶させる場合に限らず、RAID５等のようにパリティとデータとに分解して冗長記憶させる構成でもよい。

本発明の実施形態の概念を示す説明図である。 ストレージ装置のハードウェア構成に着目したブロック図である。 ライトアクセスの処理に着目したストレージシステムの概略構成図である。 ストレージ装置の論理的構成に着目した説明図である。 パリティグループと論理ボリューム（LDEV）と論理ユニット（LU）との対応関係を示す説明図である。 （ａ）はLDEV制御テーブルを、（ｂ）は各LDEV制御テーブルに設定されたライトスルーフラグを抽出して一覧形式で示すライトスルーフラグ管理テーブルを、それぞれ示す説明図である。 LDEV番号変換テーブルとパリティグループ−LDEV対応テーブルとの関係を示す説明図である。 ライトスルーフラグ設定処理を示すフローチャートである。 各LDEV単位でライトスルーフラグを設定する画面例を示す説明図である。 ライトアクセス処理の全体概要を示すフローチャートである。 キャッシュメモリが正常な場合のライトアクセス処理を示すフローチャートである。 キャッシュメモリに異常を生じた場合のライトアクセス処理を示すフローチャートである。 キャッシュメモリに異常を生じた場合の別のライトアクセス処理を示すフローチャートである。 リードアクセス処理を示すフローチャートである。 第２実施例で用いられるLDEV番号変換テーブルを示す説明図である。 ライトスルーフラグの設定及び補正を行うフローチャートである。 関連するライトスルーフラグ同士が補正される様子を示す説明図である。 第３実施例で用いられるライトスルーフラグ設定処理を示すフローチャートである。 第４実施例で用いられるライトスルーフラグ設定処理を示すフローチャートである。 ＬＵ単位でライトスルーフラグを設定する画面例を示す説明図である。 第５実施例で用いられるライトスルーフラグの指定処理及び設定処理を示すフローチャートである。 第６実施例で用いられるライトスルーフラグの設定処理及び補正処理を示すフローチャートである。 互いに関連するライトスルーフラグ同士が補正される様子を示す説明図である。 第７実施例で用いられるライトスルーフラグ設定処理のフローチャートである。 第８実施例で用いられるライトスルーフラグ設定処理のフローチャートである。 パリティグループ単位でライトスルーフラグを設定する画面例を示す説明図である。 第９実施例で用いられるライトスルーフラグ設定処理のフローチャートである。 第１０実施例で用いられるライトスルーフラグ設定処理のフローチャートである。 ディスク種別毎にライトスルーフラグを設定する画面例を示す説明図である。 第１１実施例で用いられるライトスルーフラグの指定処理及び設定処理を示すフローチャートである。 第１２実施例で用いられるライトスルーフラグ設定処理のフローチャートである。 RAIDレベル毎にライトスルーフラグを設定する画面例を示す説明図である。 第１３実施例で用いられるライトスルーフラグの指定処理及び設定処理を示すフローチャートである。 第１４実施例のストレージシステムの概要を示す説明図である。 ライトスルーフラグ設定処理を示すフローチャートである。 SLPR（仮想筐体）毎にライトスルーフラグを設定する画面例を示す説明図である。 第１５実施例のストレージシステムの概要を示す説明図である。 ライトスルーフラグ変更処理を示すフローチャートである。

符号の説明

１…ホスト、２…ストレージ装置、３…コントローラ、４，５…キャッシュ領域、６Ａ，６Ｂ…ボリューム、１０…ホスト、１２…パス制御部、１３…アプリケーションプログラム、２０…スイッチ、３０…管理端末、１００，２００…ストレージ装置、１０１，１０１Ａ，１０１Ｂ，２０１…コントローラ、１１１…通信ポート、１３０…キャッシュメモリ、１３１，２３１…キャッシュ面、１３２，２３２…NVS面、１４０…共有メモリ、１５０…接続制御部、１６０…記憶部、１６１…ディスクドライブ（PDEV）、１６２…パリティグループ（VDEV）、１６３，２６３…論理ボリューム（LDEV）、１６４…論理ユニット（LU）、１７０，２７０…SVP、ＣＮ１〜ＣＮ４…通信ネットワーク、Ｔ１〜Ｔ７…テーブル

Claims (1)

1. 上位装置及び記憶デバイス群との間のデータ授受をそれぞれ制御するためのコントローラと、
   前記コントローラにより使用され、前記上位装置から受信したライトデータを非冗長記憶または冗長記憶するキャッシュメモリと、を備え、
   前記コントローラは、前記上位装置からのライトコマンドを受け付けた場合の処理モードとして、
   （１）前記ライトデータを前記キャッシュメモリに冗長記憶させた場合に前記上位装置に処理完了を通知し、前記キャッシュメモリに冗長記憶された前記ライトデータを所定のタイミングで前記記憶デバイス群に書き込む第１処理モードと、
   （２）前記キャッシュメモリに非冗長記憶された前記ライトデータを直ちに前記記憶デバイス群に書き込んだ場合に、前記上位装置に処理完了を通知する第２処理モードと、
   （３）前記ライトデータを前記キャッシュメモリに非冗長記憶させた場合に前記上位装置に処理完了を通知し、前記キャッシュメモリに非冗長記憶された前記ライトデータを所定のタイミングで前記記憶デバイス群に書き込む第３処理モードと、を予め備えており、
   論理ボリューム単位に前記第２処理モードと前記第３処理モードのいずれを選択するかを示すモード選択情報が予め設定されており、
   前記コントローラは、
   前記第１処理モードを優先的に実行し、前記キャッシュメモリが前記ライトデータを冗長記憶できない場合に、前記モード選択情報に基づいて前記第２処理モードまたは前記第３処理モードのいずれか一つを実行し、
   さらに、前記コントローラは、関連性の論理ボリューム同士に同一の処理モードを適用し、
   さらに、前記ライトデータを受領して記憶する他のストレージ装置に障害が発生した場合には、前記第３処理モードに設定されている論理ボリュームを、前記第２処理モードに変更するストレージ装置。
   

Images