JP2005301638A - ディスクアレイ装置及びディスクアレイ装置のリザーブ解除制御方法 - Google Patents

Abstract

【課題】 ホストのシステムダウン等によってLDEVに残されたリザーブ状態を簡単に確認して解除できるようにする。
【解決手段】 サーバ１がLDEV４をリザーブして排他的に使用している。サーバ１が障害等でシステムダウンした場合（Ｓ１）、LDEV４は、リザーブされたままの状態となる（Ｓ２）。このため、サーバ２は、LDEV４にアクセスすることができない。システム管理者は、管理端末７を介してメモリ５内の排他制御情報６を読み出す。これにより、各LDEV単位のリザーブ状態を端末画面に表示して確認できる。ユーザは、管理端末７からリザーブ状態の解除を指示する（Ｓ３）。ディスクアレイ装置３は、この解除指示を受けて、排他制御情報６を部分的に書き換え、リザーブ状態を解除する。
【選択図】 図１

Description

本発明は、ディスクアレイ装置及びディスクアレイ装置のリザーブ解除制御方法に関する。

例えば、企業や自治体あるいは学校等のような各種の組織では、多種多様のデータを多量に管理する。これらの多量のデータは、ホストコンピュータとは別体に形成されたストレージシステムにより管理される。ストレージシステムは、例えば、ディスクアレイ装置のような記憶装置を少なくとも一つ以上備えて構成される。

ディスクアレイ装置は、例えば、ハードディスクドライブや半導体メモリ装置等の記憶デバイスをアレイ状に配設して構成される。ディスクアレイ装置は、RAID（Redundant Array of Independent Inexpensive Disks）に基づく論理的な記憶領域を提供する。この論理的な記憶領域は、論理ボリューム（ＬＵ：Logical Unit）とも呼ばれる。

そして、ホストコンピュータは、ディスクアレイ装置の通信ポートを介して論理ボリュームにアクセスし、データの読み書き（Ｉ／Ｏ）を行う。ホストコンピュータは、データの整合性等を維持するために、論理ボリュームをリザーブし、排他的に論理ボリュームを使用する場合がある。論理ボリュームの使用を終えた場合、ホストコンピュータは、リザーブ状態を解除する。

ここで、ホストコンピュータが論理ボリュームをリザーブしている状態で、ホストコンピュータに何らかの障害が発生した場合は、リザーブ状態を解除しないままホストコンピュータがシステムダウンする可能性がある。この場合、他のホストコンピュータは、リザーブ状態に置かれたままの論理ボリュームを利用できない。従って、例えば、ディスクアレイ装置の電源を落としたり、通信ポートに接続されるケーブルを取り外したり、ディスクアレイ装置に接続されるチャネルスイッチの電源を落とすことにより、リセット処理を行い、リザーブ状態を解除する。

なお、ディスク装置をリザーブしているホストがハングアップしたときは、ディスク制御装置とホストとの間で応答確認を行い、ホストからの応答が無い場合にリザーブ状態を強制的に解除するようにした技術は知られている（特許文献１）。
特開平５−１８９３９６号公報

論理ボリュームのリザーブ状態を解除するために、ディスクアレイ装置の電源を落としてリセット処理を行う場合は、ディスクアレイ装置が再起動するまで、ホストコンピュータはストレージサービスを利用することができない。また、チャネルスイッチの電源を落としたり、通信ポートに接続されるケーブルを取り外すことによりリセット処理を行う場合は、リセットされるポートを介して他のホストコンピュータが他の論理ボリュームにアクセスすることができなくなる。

近年では、ディスクアレイ装置の高性能化高容量化に伴い、ディスクアレイ装置は、多数のホストコンピュータによって利用されることが多い。ディスクアレイ装置が備える複数の通信ポートには、それぞれ複数の論理ボリュームを関連付けることができる。従って、論理ボリュームに残されたリザーブ状態を解除するために、通信ポートにリセットをかけた場合は、その通信ポートに関連付けられる他の論理ボリュームへのアクセスも行うことができなくなる。

また、ディスクアレイ装置側で通信ポートをリセットし、論理ボリュームに残されたリザーブ状態を解除する場合、他のホストコンピュータは、リザーブ状態が解除されたことを認識することができない。従って、多数のホストコンピュータとディスクアレイ装置との間で、リザーブ状態の有無に関する認識が相違するおそれもある。

なお、上記文献に記載の技術は、ディスク装置へのリザーブ状態を解除するもので、ディスク装置上に設けられる論理ボリュームへのリザーブ状態を解除するものではない。従って、この従来技術は、論理ボリュームをリザーブしてアクセスするシステムに適用することができない。

本発明は、上記の問題点に鑑みてなされたもので、その目的の一つは、論理ボリューム単位で排他的使用状態を解除できるようにしたディスクアレイ装置及びディスクアレイ装置のリザーブ解除制御方法を提供することにある。本発明の目的の一つは、論理ボリューム単位で排他的使用状態を確認することができ、論理ボリューム単位で排他的使用を解除することができるようにしたディスクアレイ装置及びディスクアレイ装置のリザーブ解除制御方法を提供することにある。本発明の目的の一つは、アクセスの優先度に基づいて、リザーブ状態を論理ボリューム単位で解除可能としたディスクアレイ装置及びディスクアレイ装置のリザーブ解除制御方法を提供することにある。本発明の更なる目的は、後述する実施の形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明のディスクアレイ装置は、複数の上位装置とのデータ授受を通信ポートを介してそれぞれ制御する上位インターフェース制御部と、記憶デバイスとのデータ授受を制御する下位インターフェース制御部と、上位インターフェース制御部及び下位インターフェース制御部により共用されるメモリ部と、記憶デバイス上に設けられ、通信ポートを介してアクセス可能な論理ボリュームと、各上位装置のうちいずれか一つの上位装置が通信ポートを介して論理ボリュームを排他的に使用するための排他制御情報を記憶する排他制御情報記憶領域と、上位インターフェース制御部に設けられ、排他制御情報に基づいて論理ボリュームの排他制御を実行する排他制御部と、解除指示を検出した場合に、排他制御情報を更新することにより、排他的使用を論理ボリューム単位で解除させる解除制御部と、を備えている。

論理ボリュームの排他的使用としては、例えば、上位装置から発行されるリザーブコマンドに基づくものを挙げることができる。これ以外に、論理ボリュームの排他的使用として、エラー等によるアクセス不可状態を含めることもできる。複数の上位装置は、フェイルオーバクラスタを構成することができる。論理ボリュームは、ディスクアレイ装置内に存在する必要は必ずしもなく、外部の他のディスクアレイ装置内に存在してもよい。なお、上位装置がいわゆるオープン系のコンピュータ装置である場合、この上位装置は、論理ボリュームを直接認識するのではなく、LUNを介して間接的に認識する。上位装置がいわゆるメインフレーム系のコンピュータ装置である場合、この上位装置は、論理ボリュームを直接的に認識する。

排他制御情報記憶領域は、メモリ部または上位インターフェース制御部の少なくともいずれか一方に設けることができる。

解除制御部は、上位インターフェース制御部に設けることができる。なお、排他制御情報をメモリ部または下位インターフェース制御部のいずれかに設ける場合は、解除制御部を下位インターフェース制御部に設けることもできる。

論理ボリュームは複数設けられており、通信ポートには複数の論理ボリュームを対応付けることができる。即ち、一つの通信ポートには、複数の論理ボリュームをそれぞれ接続することができる。

排他制御情報の全部または一部に基づいて、論理ボリュームの排他的使用に関する所定の情報を表示させる表示部を備えることもできる。

表示部により表示された所定の情報に基づいて、解除指示を解除制御部に与える解除対象選択部を備えることもできる。

各上位装置の優先度を管理するための優先度管理情報を記憶する優先度管理情報記憶領域と、相対的に優先度が低い上位装置が論理ボリュームを排他的に使用している場合において、相対的に優先度が高い上位装置が論理ボリュームへのアクセスを要求した場合は、解除指示を解除制御部に与える優先度判定部とを備えることもできる。

解除制御部は、論理ボリュームの排他的使用を解除した場合に、論理ボリュームの状態変更を各上位装置にそれぞれ通知することもできる。

本発明に従うディスクアレイ装置及びディスクアレイ装置のリザーブ解除制御方法は、その構成の少なくとも一部をコンピュータプログラムから構成可能である。そして、このコンピュータプログラムは、例えば、ハードディスクや半導体メモリまたは光ディスク等の記憶媒体を介して流通することができる。あるいは、このコンピュータプログラムは、インターネット等の通信ネットワークを介して配信することもできる。

以下、図面に基づき、本発明の実施の形態を説明する。本実施形態では、詳細はさらに後述するが、複数の上位装置とのデータ授受を通信ポートを介してそれぞれ制御する上位インターフェース制御部と、記憶デバイスとのデータ授受を制御する下位インターフェース制御部と、上位インターフェース制御部及び下位インターフェース制御部により共用されるメモリ部と、記憶デバイス上に設けられ、通信ポートを介してアクセス可能な論理ボリュームと、各上位装置のうちいずれか一つの上位装置が通信ポートを介して論理ボリュームをリザーブして使用するためのリザーブ情報を記憶するリザーブ情報記憶領域と、を備えたディスクアレイ装置が開示されている。そして、本実施形態では、論理ボリューム単位で解除指示を発生させる解除指示発生ステップと、解除指示が発生された場合は、リザーブ情報を更新することにより、リザーブ状態を解除させるリザーブ解除ステップと、を含むディスクアレイ装置のリザーブ解除制御方法が示されている。

図１は、本実施形態の全体概念を示す説明図である。このストレージシステムは、複数のサーバ１，２と、これらサーバ１，２により利用されるディスクアレイ装置３とを備えている。ディスクアレイ装置３は、少なくとも一つ以上の論理ボリューム（図中、「LDEV」と表記）４と、メモリ５とを備えることができる。メモリ５には、論理ボリューム４に対する排他制御の情報６が記憶されている。ディスクアレイ装置３には、管理端末７が接続されている。

サーバ１とサーバ２とは、例えば、LAN（Local Area Network）等の通信ネットワーク８を介して接続されている。サーバ１，２とディスクアレイ装置３とは、例えば、SAN（Storage Area Network）等の通信ネットワーク９Ａ，９Ｂを介して接続されている。

サーバ１は、例えば、論理ボリューム４を特定するための情報を含むリザーブコマンドを発行することにより、論理ボリューム４をリザーブ状態に置き、排他的に使用することができる。サーバ１が論理ボリューム４をリザーブしている間、サーバ２は論理ボリューム４にアクセスすることはできない。サーバ１による論理ボリューム４のリザーブは、排他制御情報６に記憶される。図１中では、サーバ１は、LUN（Logical Unit Number）０を介して論理ボリューム４にアクセスしている。また、論理ボリューム４がサーバ１によりリザーブされていない場合、サーバ２は、LUN１を介して論理ボリューム４にアクセスすることができる。

図１（ａ）では、サーバ１が論理ボリューム４をリザーブして使用している。図１（ｂ）に示すように、サーバ１が論理ボリューム４をリザーブしている状態で、サーバ１に障害が発生したとする（Ｓ１）。論理ボリューム４のリザーブ状態は解除されていないため（Ｓ２）、サーバ２は論理ボリューム４にアクセスすることができない。

システム管理者は、管理端末７を介して、リザーブ状態の解除を指示する（Ｓ３）。ディスクアレイ装置３は、サーバ１によるリザーブを強制的に除去して排他制御情報６を更新させる。これにより、サーバ２は、論理ボリューム４にアクセスすることができる。ここで、論理ボリューム４がリザーブされていない状態であることを示す情報が、排他制御情報６に設定される。この排他制御情報６を用いて、論理ボリューム４がリザーブされていない旨をサーバ２に通知することができる。

まず最初に、図２及び図３に基づいて、ディスクアレイ装置の一例について説明し、次に、図４以下を参照しながら本発明に特有の構成について説明する。

図２は、ディスクアレイ装置１０の外観構成を示す概略斜視図である。ディスクアレイ装置１０は、例えば、基本筐体１１と複数の増設筐体１２とから構成可能である。

基本筐体１１は、ディスクアレイ装置１０の最小構成単位であり、記憶機能及び制御機能の両方を備えている。増設筐体１２は、ディスクアレイ装置１０のオプションであり、基本筐体１１の有する制御機能により制御される。例えば、最大４個の増設筐体１２を基本筐体１１に接続可能である。

基本筐体１１には、複数の制御パッケージ１３と、複数の電源ユニット１４と、複数のバッテリユニット１５と、複数のディスクドライブ２６とがそれぞれ着脱可能に設けられている。増設筐体１２には、複数のディスクドライブ２６と、複数の電源ユニット１４及び複数のバッテリユニット１５が着脱可能に設けられている。また、基本筐体１１及び各増設筐体１２には、複数の冷却ファン１６もそれぞれ設けられている。

制御パッケージ１３は、後述するチャネルアダプタ（以下、CHA）２１、ディスクアダプタ（以下、DKA）２２及びキャッシュメモリ２３等をそれぞれ実現するためのモジュールである。即ち、基本筐体１１には、複数のCHAパッケージ、複数のDKAパッケージ及び一つ以上のメモリパッケージがそれぞれ着脱可能に設けられ、パッケージ単位で交換可能となっている。

図３は、ディスクアレイ装置１０の全体概要を示すブロック図である。ディスクアレイ装置１０は、通信ネットワークＣＮ１を介して、複数のホストコンピュータ３０と双方向通信可能にそれぞれ接続可能である。

通信ネットワークＣＮ１は、例えば、LAN、SAN、インターネットまたは専用回線等である。LANを用いる場合、ホストコンピュータ３０とディスクアレイ装置１０との間のデータ転送は、例えば、TCP/IPに従う。SANを用いる場合、ホストコンピュータ３０とディスクアレイ装置１０とは、例えば、ファイバチャネルプロトコルに従ってデータ転送を行う。

また、ホストコンピュータ３０がメインフレームの場合は、例えば、FICON（Fibre Connection：登録商標）、ESCON（Enterprise System Connection：登録商標）、ACONARC（Advanced Connection Architecture：登録商標）、FIBARC（Fibre Connection Architecture：登録商標）等の通信プロトコルに従ってデータ転送が行われる。

各ホストコンピュータ３０は、例えば、サーバ、パーソナルコンピュータ、ワークステーション、メインフレーム等として実現されるものである。例えば、各ホストコンピュータ３０は、図外に位置する複数のクライアント端末と別の通信ネットワークを介して接続されている。各ホストコンピュータ３０は、例えば、各クライアント端末からの要求に応じて、ディスクアレイ装置１０にデータの読み書きを行うことにより、各クライアント端末へのサービスを提供する。

各CHA２１は、各ホストコンピュータ３０との間のデータ転送を制御するもので、通信ポート２１Ａを備えている。ディスクアレイ装置１０には、例えば３２個のCHA２１を設けることができる。CHA２１は、例えば、オープン系用CHA、メインフレーム系用CHA等のように、ホストコンピュータ３０の種類に応じて用意される。各CHA２１は、それぞれ複数の通信ポート（以下「ポート」と略記）２１Ａを備えている。後述のように、各ポート２１Ａにはそれぞれ少なくとも一つ以上のLDEVを接続できる。

各CHA２１は、それぞれに接続されたホストコンピュータ３０から、データの読み書きを要求するコマンド及びデータを受信し、ホストコンピュータ３０から受信したコマンドに従って動作する。

DKA２２の動作も含めて先に説明すると、CHA２１は、ホストコンピュータ３０からリードコマンドを受信すると、このリードコマンドを共有メモリ２４に記憶させる。DKA２２は、共有メモリ２４を随時参照しており、未処理のリードコマンドを発見すると、ディスクドライブ２６からデータを読み出して、キャッシュメモリ２３に記憶させる。CHA２１は、キャッシュメモリ２３に移されたデータを読み出し、ホストコンピュータ３０に送信する。

一方、CHA２１は、ホストコンピュータ３０からライトコマンドを受信すると、このライトコマンドを共有メモリ２４に記憶させる。また、CHA２１は、受信したデータ（ユーザデータ）をキャッシュメモリ２３に記憶させる。CHA２１は、キャッシュメモリ２３にデータを記憶した後、ホストコンピュータ３０に書込み完了を報告する。DKA２２は、共有メモリ２４に記憶されたライトコマンドに従って、キャッシュメモリ２３に記憶されたデータを読出し、所定のディスクドライブ２６に記憶させる。

各DKA２２は、ディスクアレイ装置１０内に例えば４個や８個等のように複数個設けることができる。各DKA２２は、各ディスクドライブ２６との間のデータ通信をそれぞれ制御する。各DKA２２と各ディスクドライブ２６とは、例えば、SAN等の通信ネットワークＣＮ４を介して接続されており、ファイバチャネルプロトコルに従ってブロック単位のデータ転送を行う。各DKA２２は、ディスクドライブ２６の状態を随時監視しており、この監視結果は、内部ネットワークＣＮ３を介して、SVP２９に送信される。

各CHA２１及び各DKA２２は、例えば、プロセッサやメモリ等が実装されたプリント基板と、メモリに格納された制御プログラム（いずれも不図示）とをそれぞれ備えており、これらのハードウェアとソフトウェアとの協働作業によって、それぞれ所定の機能を実現するようになっている。

キャッシュメモリ２３は、例えば、ユーザデータ等を記憶するものである。キャッシュメモリ２３は、例えば不揮発メモリから構成される。ボリュームコピーや差分コピー等を行う場合は、コピー対象のデータがキャッシュメモリ２３に読み出され、キャッシュメモリ２３からCHA２１またはDKA２２のいずれか一方により、あるいはCHA２１及びDKA２２の両方により、コピー先に転送される。

共有メモリ（あるいは制御メモリ）２４は、例えば不揮発メモリから構成される。共有メモリ２４には、例えば、制御情報や管理情報等が記憶される。共有メモリ２４及びキャッシュメモリ２３は、それぞれ複数個設けることができる。また、同一のメモリ基板にキャッシュメモリ２３と共有メモリ２４とを混在させて実装することもできる。あるいは、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。

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

ディスクアレイ装置１０は、多数のディスクドライブ２６を実装可能である。各ディスクドライブ２６は、例えば、ハードディスクドライブ（ＨＤＤ）や半導体メモリ装置等として実現することができる。

ディスクドライブ２６は、物理的な記憶デバイスである。RAID構成等によっても相違するが、例えば、４個１組のディスクドライブ２６が提供する物理的な記憶領域上には、仮想的な論理領域であるRAIDグループ２７が構築される。さらに、RAIDグループ２７上には、仮想的な論理ボリューム（LDEV）２８を一つ以上設定可能である。

なお、ディスクアレイ装置１０により使用される記憶資源は、全てディスクアレイ装置１０内に設けられている必要はない。ディスクアレイ装置１０は、ディスクアレイ装置１０の外部に存在する記憶資源を、あたかも自己の記憶資源であるかのように取り込んで、利用することもできる。

サービスプロセッサ（SVP）２９は、LAN等の内部ネットワークＣＮ３を介して、各CHA２１及び各DKA２２とそれぞれ接続されている。また、SVP２９は、LAN等の通信ネットワークＣＮ２を介して、複数の管理端末３１に接続可能である。SVP２９は、ディスクアレイ装置１０内部の各種状態を収集し、管理端末３１に提供する。

管理端末３１は、SVP２９を介して、ディスクアレイ装置１０のRAID構成等のような各種設定を行うためのものである。

図４は、LDEV毎にそれぞれリザーブ状態を解除できるようにしたディスクアレイ装置２００を含むストレージシステムの概略ブロック図である。このストレージシステムは、複数のサーバ１１０，１２０，１３０と、ディスクアレイ装置２００と、ファイバチャネルスイッチ（「スイッチ」と略記）３００と、管理端末３１０とを備えている。

各サーバ１１０，１２０，１３０は、業務アプリケーションプログラム（「アプリケーション」と略記）１１１，１２１，１３１と、通信制御を行うためのHBA（Host Bus Adapter）１１２，１２２，１３２とを備えている。

サーバ１１０（Ｎ１）とサーバ１２０（Ｎ２）とは、LAN等の通信ネットワークＣＮ１２を介して接続されており、フェイルオーバクラスタを構成している。フェイルオーバクラスタとは、疎結合された各サーバのいずれか一つが障害等でダウンした場合に、フェイルオーバ先のサーバが業務を引き継ぐようなシステムである。フェイルオーバクラスタは、そのクラスタを利用するクライアント端末からは、全体として一つのコンピュータとして認識される。

ディスクアレイ装置２００は、例えば、図２及び図３で述べたような構成を備えることができる。ディスクアレイ装置２００は、例えば、複数のCHA２１０と、複数のDKA２２０（１個のみ図示）と、キャッシュメモリ２３０と、共有メモリ２４０と、複数のLDEV２５０と、SVP２６０と、を備えている。

詳細は図５と共に後述するが、CHA２１０は、複数のポートを備えている。各ポートには、それぞれ少なくとも一つ以上のLUNを割り当てることができる。CHA２１０は、図３中のCHA２１に対応する。

DKA２２０は、各LDEV２５０とのデータ授受を行うものである。DKA２２０は、図３中のDKA２２に対応する。キャッシュメモリ２３０は、サーバ１１０〜１３０から書込みを要求されたデータや読出しを要求されたデータを記憶するメモリである。キャッシュメモリ２３０は、図３中のキャッシュメモリ２３に対応する。共有メモリ２４０は、制御情報や管理情報等を記憶するためのメモリである。共有メモリ２４０は、図３中の共有メモリ２４に対応する。詳細は後述するが、共有メモリ２４０には、ポート−LUN構成情報Ｔ１及びLDEV排他制御情報（LDCB：Logical Device Control Block）Ｔ２がそれぞれ記憶される。

LDEV２５０は、物理的な記憶デバイス（例えば、図３中のディスクドライブ２６）が提供する記憶領域上に設定される論理的な記憶デバイス（論理ボリューム）である。LDEV２５０は、図３中のLDEV２８に対応する。一つのLDEV２５０には、少なくとも一つ以上のLUNが割り当てられる。一つのLDEV２５０に対し、複数のLUN（あるいは複数のポート）を割り当てることもできる。

SVP２６０は、ディスクアレイ装置２００内の各種状態に関する情報を収集したり、管理端末３１０から指示された設定変更を反映させるものである。SVP２６０は、図３中のSVP２９に対応する。詳細は後述するが、SVP２６０は、管理端末３１０からの指示に基づいて、共有メモリ２４０に記憶されているLDCB（Ｔ２）を更新する。図３中に示す内部ネットワークＣＮ３のような通信経路（図示せず）を介して、SVP２６０と各CHA２１０、各CHA２１０と共有メモリ２４０等が接続されている。SVP２６０は、いずれか一つのCHA２１０を介して、共有メモリ２４０にアクセス可能である。なお、DKA２２０と共有メモリ２４０とも内部の通信ネットワークによって接続されるため、SVP２６０は、いずれか一つのDKA２２０を介して共有メモリ２４０にアクセスすることも可能である。

スイッチ３００は、複数のサーバ１１０〜１３０とディスクアレイ装置２００とをそれぞれ接続するための接続回路である。スイッチ３００とHBA１１２，１２２，１３２とは、ケーブルＦ１を介してそれぞれ接続されている。スイッチ３００と各CHA２１０の各ポートとは、ケーブルＦ２を介してそれぞれ接続されている。ケーブルＦ１，Ｆ２は、例えば、光ファイバケーブルやメタルケーブルとして構成される。

管理端末３１０は、SVP２６０を介して、ディスクアレイ装置２００の各種設定を行ったり、ディスクアレイ装置２００の各種状態を表示させて監視するものである。管理端末３１０は、図３中の管理端末３１に対応する。管理端末３１０は、通信ネットワークＣＮ１１を介して、各サーバ１１０〜１３０に接続することもできる。

図５は、サーバ１１０，１２０及びCHA２１０のより詳細な構成を示すブロック図である。サーバ１１０は、例えば、業務アプリケーションプログラム１１１及びHBA１１２以外に、ハートビート監視部１１３と、起動停止制御部１１４と、排他制御部１１５とを備えることができる。ハートビート監視部１１３は、相手方のサーバ１２０との間でハートビート通信を行うことにより、相手方サーバ１２０がシステムダウン等したか否かを監視するものである。起動停止制御部１１４は、アプリケーション１１１の起動及び停止を制御するものである。排他制御部１１５は、各サーバ１１０，１２０により共有されるLDEV２５０を排他的に使用するためのものである。

サーバ１２０は、サーバ１１０と同様に、アプリケーション１２１と、HBA１２２と、ハートビート監視部１２３と、起動停止制御部１２４と、排他制御部１２５とを備えて構成することができる。これら各部の機能は、サーバ１１０で述べたと同様であるため、説明を省略する。

各CHA２１０は、例えば、ポート制御部２１１と、CHP（CHannel Processor）２１２と、メモリ２１３とを備えることができる。ポート制御部２１１は、例えば、ファイバチャネルプロトコル等の所定のプロトコルに基づいてデータの送受信等を行う。CHP２１２は、CHA２１０の全体動作を制御する。メモリ２１３には、ポート−LUN構成情報Ｔ１等が記憶される。

図示の例では、ディスクアレイ装置２００が備える所定のLDEV２５０が、サーバ１１０，１２０により共有されている。サーバ１１０を稼働系サーバとし、サーバ１２０を待機系サーバとすると、通常時は、サーバ１１０がLDEV２５０をリザーブし、アクセスロックを取得して排他的に使用している。サーバ１１０がシステムダウンした場合は、サーバ１２０がLDEV２５０のアクセスロックを取得し、サーバ１１０で提供されていた業務サービスを引き継ぐ。

図６は、ポート−LUN構成情報Ｔ１の一例を示す説明図である。このポート−LUN構成情報Ｔ１は、例えば、各CHA２１０のメモリ２１３と共有メモリ２４０との両方にそれぞれ記憶される。

ポート−LUN構成情報Ｔ１は、例えば、連番（＃）と、各ポートの番号と、各ポートに対応付けられるLUNと、各LUNに対応付けられるLDEV２５０のLDEV番号とを含んで構成される。CHA２１０は、サーバ１１０〜１３０からアクセスを要求された場合に、ポート−LUN構成情報Ｔ１を参照する。サーバ１１０〜１３０は、アクセス先ポート番号（ポート名）及びアクセス先LUNとを特定して、コマンドを発行する。CHA２１０は、このポート番号及びLUNに基づいて、ポート−LUN構成情報Ｔ１を参照し、アクセス対象のLDEV２５０を特定する。

図６に示す例では、LDEV番号「０００１」で特定されるLDEV２５０は、２つのパスを介してアクセス可能であることがわかる。一つのパスは、ポート番号「１」からLUN「１」を介するパスである。他の一つのパスは、ポート番号「２」からLUN「１」を介してアクセスするパスである。

図７は、LDEV２５０の状態を管理するための制御情報LDCB（Ｔ２）の一例を示す説明図である。LDCB（Ｔ２）は、例えば、連続番号と、ポート番号と、LUNと、LDEV番号と、リザーブ状態を示すフラグと、リザーブが設定されているパス情報と、パーシステントリザーブ状態を示すフラグと、パーシステントリザーブが設定されているパス情報と、ACA（Automatic Contingent Allegiance）状態を示すフラグと、ACA状態となっているパスの情報と、UA（Unit Attention）状態を示すフラグと、を対応付けて構成することができる。

ここで、ACA状態とは、例えば、あるアクセスパスに障害が発生した場合にそのアクセスパスを使用禁止にするために設定される状態である。ACA状態は、ACA状態を設定したサーバからの解除コマンドにより解除可能である。但し、本実施形態では、管理端末３１０からSVP２６０を介して、ACA状態を解除することもできる。

UA状態とは、例えば、ディスクアレイ装置２００の起動直後等に設定される状態である。後述のように、管理端末３１０からSVP２６０を介してリザーブ状態を解除した場合は、UA状態が設定されるようになっている。

パーシステントリザーブ状態とは、予め設定された複数のアクセスパスを介して、一つまたは複数のLDEV２５０をリザーブする状態である。通常のリザーブ状態では、一つのアクセスパスのみから所定のLDEV２５０にアクセス可能である。パーシステントリザーブ状態では、複数のアクセスパスのそれぞれから所定のLDEV２５０にアクセスすることができる。本実施形態では、管理端末３１０からSVP２６０を介して、パーシステントリザーブ状態を解除することができる。

図８〜図１４に基づいて、ディスクアレイ装置２００等の動作を説明する。図８は、ディスクアレイ装置２００において実行されるリザーブ処理の概略を示すフローチャートである。このリザーブ処理は、サーバが所望のLDEVをリザーブして排他的に使用する場合の処理である。リザーブ処理は、例えば、リザーブコマンドを受信したCHA２１０（より詳しくはCHP２１２）により実行される。

CHA２１０は、サーバ１１０〜１３０からのリザーブコマンドを受信したか否かを監視している（Ｓ１１）。リザーブコマンドを受信した場合（S11：YES）、CHA２１０は、リザーブコマンドに含まれているポート番号及びLUN番号に基づいて、ポート−LUN構成情報Ｔ１を参照し、リザーブ対象のLDEV番号を特定する（Ｓ１２）。

次に、CHA２１０は、LDCB（Ｔ２）を参照し（Ｓ１３）、リザーブ対象のLDEVが既にリザーブされているか否かを判定する（Ｓ１４）。リザーブ対象のLDEVがリザーブ状態に無い場合（S14：NO）、CHA２１０は、リザーブ対象のLDEVにリザーブ情報を設定する（Ｓ１５）。ここでいうリザーブ情報とは、どのアクセスパス（HBAのWWN（World Wide Name）やポート番号）によってリザーブされたかを示す情報である。このリザーブ情報は、LDCB（Ｔ２）に反映される。CHA２１０は、要求されたLDEVにリザーブ状態を設定した後、リザーブコマンドを発行したサーバに正常終了を応答する（Ｓ１５）。

一方、リザーブ対象のLDEVが既に別のサーバからリザーブされている場合（S14：YES）、CHA２１０は、リザーブコマンドを発行したサーバに対し、リザーブすることができない旨を応答する（Ｓ１７）。従って、例えば、サーバ１１０が所定のLDEV２５０をリザーブしている場合、サーバ１１０によるリザーブ状態が継続されている限り、他のサーバ１２０，１３０は、そのLDEV２５０をリザーブすることはできない。

図９は、ディスクアレイ装置２００において実行されるリード／ライト処理（Ｉ／Ｏ処理）の概略を示すフローチャートである。このＩ／Ｏ処理は、例えば、CHA２１０によって、あるいはCHA２１０及びDKA２２０によって、実行される。

CHA２１０は、サーバ１１０〜１３０からリードコマンドまたはライトコマンドを受信したか否かを監視している（Ｓ２１）。リードコマンドまたはライトコマンドのいずれかを受信した場合（S21：YES）、CHA２１０は、コマンドに含まれるポート番号及びLUN番号に基づいて、ポート−LUN構成情報Ｔ１を参照し、コマンド処理の対象とされたLDEV番号を特定する（Ｓ２２）。

次に、CHA２１０は、LDCB（Ｔ２）を参照し（Ｓ２３）、対象となるLDEVにアクセスしてＩ／Ｏ処理が可能か否かを判定する（Ｓ２４）。例えば、データの書込み等が要求されたLDEVが、ライトコマンドの発行元サーバ以外のサーバによってリザーブされているような場合は、そのLDEVにアクセスすることはできない。その他、コマンド発行元サーバが、そのLDEVへのアクセス権限を有しない場合も、コマンド処理を行うことができない。逆に、コマンド処理の対象であるLDEVに何の制限（リザーブ等）も設定されていない場合やコマンド発行元サーバが所定のアクセス権限を有する場合は、そのLDEVにアクセスしてコマンド処理を行うことができる。

Ｉ／Ｏ処理が可能な場合（S24：YES）、CHA２１０は、コマンドに応じた処理を実行し（Ｓ２５）、コマンド発行元のサーバに正常終了を応答する（Ｓ２６）。例えば、ライトコマンドの場合、書込みを要求されたデータをキャッシュメモリ２３０に格納した時点で、コマンド発行元サーバに書込み完了を報告することができる。これにより、ディスクアレイ装置２００の応答性が高まる。サーバから受信したデータは、キャッシュメモリ２３０上で多重管理され、タイミングを見計らってディスクドライブに書き込まれる。

要求されたＩ／Ｏ処理ができない場合（S24：NO）、CHA２１０は、コマンド発行元サーバに対し、エラーを通知する（Ｓ２７）。

図１０は、ディスクアレイ装置２００において実行されるリリース処理の概略を示すフローチャートである。このリリース処理は、LDEVをリザーブしているサーバが、このリザーブ状態を自発的に解除するような場合に行われる。リリース処理は、例えば、リリースコマンドを受信したCHA２１０により実行される。

CHA２１０は、サーバ１１０〜１３０からリリースコマンドを受信したか否かを監視している（Ｓ３１）。リリースコマンドを受信した場合（S31：YES）、CHA２１０は、リリースコマンドに含まれるポート番号及びLUN番号に基づいて、ポート−LUN構成情報Ｔ１を参照し、リリース対象のLDEV番号を特定する（Ｓ３２）。

次に、CHA２１０は、LDCB（Ｔ２）を参照し（Ｓ３３）、リリース可能か否かを判定する（Ｓ３４）。ここで、リリース可能な場合とは、例えば、リリースコマンド発行元サーバがリリース対象のLDEVへのアクセス権限を有しており、かつ、そのLDEVがリザーブ状態に置かれているような場合である。リリース不能な場合とは、例えば、リリースコマンド発行元サーバがリリース対象のLDEVに関してアクセス権限を有しない場合、または、リリース対象のLDEVがリザーブされていない場合のいずれかまたは両方の場合である。

リリース可能な場合（S34：YES）、CHA２１０は、リリース対象のLDEVに設定されているリザーブ状態を解除し（Ｓ３５）、リリースコマンド発行元サーバに正常終了を応答する（Ｓ３６）。リリース不能な場合（S34：NO）、CHA２１０は、リリースコマンド発行元サーバに対して、リリース処理を実行不能である旨を応答する（Ｓ３７）。

図１１は、ディスクアレイ装置２００において実行されるリザーブ状態表示処理の概略を示すフローチャートである。このリザーブ状態表示処理は、例えば、システム管理者等のユーザがディスクアレイ装置２００の各LDEV毎に、そのリザーブ状態を把握するために実行される。リザーブ状態表示処理は、例えば、SVP２６０とCHA２１０との協働作業により実現される。なお、説明の便宜上、リザーブコマンドによるリザーブ状態を中心に述べるが、これに限らず、パーシステントリザーブ状態やACA状態も含めて、管理端末３１０の端末画面に表示し、確認することができる。

LDEV単位のリザーブ状態の確認を希望するユーザは、管理端末３１０を介してSVP２６０にログインし、リザーブ状態の表示を要求する（Ｓ４１）。この際、ユーザは、表示を希望するLDEVを一つまたは複数指定する。ユーザは、LDCB（Ｔ２）に示す連番（＃）やパス情報（ポート番号やWWN）でLDEVを間接的に指定することもできるし、あるいは、LDEV番号を直接指定することもできる。

SVP２６０は、管理端末３１０からリザーブ状態の表示を要求されると（S41：YES）、CHA２１０に対して、LDCB（Ｔ２）の取得を要求する（Ｓ４２）。ここで、LDCB（Ｔ２）の全体を要求する必要はなく、管理端末３１０からリザーブ状態の表示を要求されたLDEVに関するLDCB情報のみを要求すれば足りる。ユーザが全てのLDEVについてリザーブ状態の表示を希望するような場合は、LDCB（Ｔ２）に登録されている全ての情報を要求することができる。

CHA２１０は、共有メモリ２４０にアクセスし、SVP２６０から要求された情報をLDCB（Ｔ２）から読み出す（Ｓ４３）。CHA２１０は、この読み出した情報をSVP２６０に転送する（Ｓ４４）。

ＳＶＰ２６０は、CHA２１０からLDCBを取得し（Ｓ４５）、このLDCBに基づいて、LDEV毎のリザーブ状態を管理端末３１０の端末画面に表示させる（Ｓ４６）。これにより、ユーザは、例えば、図７に示すような形態で、所望のLDEVの状態を確認することができる。

図１２は、ディスクアレイ装置２００において実行されるリザーブ状態解除処理の概略を示すフローチャートである。このリザーブ状態解除処理は、ユーザがLDEV単位でリザーブ状態を解除するために実行される。このリザーブ状態解除処理は、例えば、SVP２６０とCHA２１０との協働作業により実現される。

まず、ユーザは、管理端末３１０を介して、リザーブ状態の解除を希望するLDEVを指定する（Ｓ５１）。ここで、ユーザは、図１１で述べたように、端末画面に表示されたLDEV単位のリザーブ状態に基づいて、リザーブ状態の解除を希望するLDEVを一つまたは複数指定することができる。あるいは、ユーザは、リザーブ状態表示画面を確認することなく、リザーブ状態の解除を希望するLDEVを指定することもできる。

SVP２６０は、管理端末３１０からリザーブ状態の解除指示を受信すると（Ｓ５１）、CHA２１０に対して、リザーブ状態の解除を指示する（Ｓ５２）。この解除指示情報には、リザーブ状態を解除すべきLDEVを特定可能な情報（連番、パス情報、LDEV番号）が含まれている。

CHA２１０は、SVP２６０からの解除指示を受信すると、解除対象のLDEVを特定する（Ｓ５３）。CHA２１０は、共有メモリ２４０内のLDCB（Ｔ２）にアクセスし、解除対象のLDEVについて設定されているリザーブ状態フラグをリセットして、リザーブ状態を解除する（Ｓ５４）。続いて、CHA２１０は、リザーブ状態を解除したLDEVについて、UA状態を示すフラグをセットし（Ｓ５５）、SVP２６０にリザーブ状態の解除が完了した旨を報告する（Ｓ５６）。

SVP２６０は、CHA２１０からの解除通知を受信すると、要求されたLDEVについてリザーブ状態が解除された旨を管理端末３１０の端末画面に表示させる（Ｓ５７）。

図１３は、ディスクアレイ装置２００とサーバ１１０〜１３０との間で実行されるリザーブ状態解除後の新たなリザーブ処理を示すフローチャートである。説明の便宜上、ここでは、サーバ１１０によってリザーブされていた共有LDEVのリザーブ状態を、図１２に示すリザーブ状態解除処理により解除し、その後で、サーバ１２０が共有LDEVにリザーブを設定するものとする。

サーバ１２０は、サーバ１１０との間で共有するLDEVについて、Ｉ／Ｏコマンド（リードコマンド、ライトコマンド、リザーブコマンド等）を発行する（Ｓ６１）。CHA２１０は、サーバ１２０からのコマンドを受信すると（S62：YES）、ポート−LUN構成情報Ｔ１を参照し、コマンド処理の対象となるLDEVを特定する（Ｓ６３）。

CHA２１０は、特定されたLDEVに関してLDCB（Ｔ２）を参照し（Ｓ６４）、このLDEVがUA状態に置かれていることを検出する。上述のように、本実施形態では、ディスクアレイ装置２００側でリザーブ状態を解除した後、UA状態に設定する。そこで、CHA２１０は、サーバ１２０に対して、目的のLDEVがUA状態に置かれていることを通知する（Ｓ６５）。

サーバ１２０は、CHA２１０からUA状態の通知を受けることにより、目的とするLDEVにリザーブが設定されていないことを把握することができる（Ｓ６６）。そこで、サーバ１２０は、目的とするLDEVを排他的に使用すべく、リザーブコマンドを発行する（Ｓ６７）。CHA２１０は、このリザーブコマンドを受信すると、図８に示したようなリザーブ処理を行う（Ｓ６８）。

以上図面に基づいて、各機能毎の処理をそれぞれ説明した。図１４は、リザーブの設定からリザーブの再設定までの間の全体的な処理の流れを示すシーケンス図である。図中、「サーバＮ１」はサーバ１１０を、「サーバＮ２」はサーバ１２０を示す。

サーバ１１０は、例えば、inquiryコマンドを発行することにより、ディスクアレイ装置２００で利用可能なLDEVに関する情報を取得する（Ｓ１０１，Ｓ１０２）。サーバ１１０は、リザーブコマンドを発行する（Ｓ１０３）。このリザーブコマンドに対して、ディスクアレイ装置２００は、チェックコンディション応答を返す（Ｓ１０４）。このチェックコンディション応答には、リザーブを要求されたLDEVがUA状態に置かれていることが示されている。ディスクアレイ装置２００の起動時には、LDEVにUA状態が設定される。このUA状態は、何らかのコマンドを受信した時点でリセットされる。

サーバ１１０は、チェックコンディション応答によって、所望のLDEVがリザーブ状態に置かれておらず、リザーブ可能であることを把握する。そこで、サーバ１１０は、改めてリザーブコマンドを発行する（Ｓ１０５）。ディスクアレイ装置２００は、リザーブコマンドを受信すると、要求されたLDEVについてLDCB（Ｔ２）の情報を書き換えることにより、リザーブ状態を設定する。ディスクアレイ装置２００は、リザーブ状態に設定した旨の応答をサーバ１１０に返す（Ｓ１０６）。

ここで、ディスクアレイ装置２００がサーバ１１０から再度のリザーブコマンドを受信した時点で、そのLDEVのUA状態は解除され、通常状態にされる。そして、そのLDEVについてリザーブ状態が設定されると、そのLDEVは通常状態からリザーブ状態に遷移する。サーバ１１０は、目的とするLDEVをリザーブした後で、Ｉ／Ｏ要求を発行する（Ｓ１０７）。ディスクアレイ装置２００は、サーバ１１０から要求された処理を行って応答を返す（Ｓ１０８）。

サーバ１１０とサーバ１２０とはフェイルオーバクラスタを構成しており、定期的にハートビート通信を行っている（Ｓ１０９）。サーバ１１０に何らかの障害が発生してシステムダウンした場合（Ｓ１１０）、LDEVのリザーブ状態は解除されない。サーバ１２０は、ハートビート通信の途絶を検出すると、フェイルオーバ処理を開始する。

サーバ１２０は、サーバ１１０で提供されていた業務アプリケーションサービスを引き継ぐために、共有しているLDEVのリザーブを要求する（Ｓ１１１）。しかし、サーバ１１０の突然のシステムダウンによって、そのLDEVにはリザーブ状態が設定されたままである。そこで、ディスクアレイ装置２００は、サーバ１２０に対して「リザーブコンフリクト」を返し、リザーブが設定不可である旨を通知する（Ｓ１１２）。サーバ１２０は、続けてリクエストコマンドを再送信することができる（リトライ処理）。あるいは、サーバ１２０から管理端末３１０に対して、リザーブ状態の強制解除を依頼することもできる。この依頼は、コンピュータ間の自動的な通信であってもよいし、システム管理者等のユーザに対する電子的な通知（電子メール等）でもよい。

ユーザは、管理端末３１０を介してSVP２６０にログインし、SVP２６０に対してLDEV毎のリザーブ状態の表示を要求する。管理端末３１０からの要求を受けたSVP２６０は、ディスクアレイ装置２００の共有メモリ２４０からLDCB（Ｔ２）の全部または一部を取得する（Ｓ１１３）。SVP２６０は、各LDEV毎のリザーブ状態（パーシステントリザーブ状態及びACA状態を含めることができる）を、管理端末３１０の端末画面に表示させる（Ｓ１１４）。

ユーザは、端末画面に表示された各LDEVのリザーブ状態に基づいて、問題となっているリザーブ状態を把握する。ユーザは、サーバ１１０によりリザーブ状態に設定されたままのLDEVを選択し、そのリザーブ状態の解除を要求する。管理端末３１０からの解除指示を受信したSVP２６０は、ディスクアレイ装置２００のCHA２１０に対し、共有LDEVのリザーブ状態の解除を指示する（Ｓ１１６）。ここで、SVP２６０は、予め設定された所定のCHA２１０に対して解除指示を出すこともできるし、あるいは、複数のCHA２１０内から任意のCHA２１０を選択して解除指示を出すこともできる。

CHA２１０は、指定されたLDEVについてLDCB（Ｔ２）中のリザーブ情報を削除することにより、リザーブ状態を解除する。この際、CHA２１０は、リザーブ状態を解除したLDEVについて、UA状態を設定する。

サーバ１２０は、継続してリザーブコマンドを発行している。目的とするLDEVの状態がサーバ１１０によるリザーブ状態からUA状態に変更された後で、サーバ１２０がリザーブコマンドを発行した場合、ディスクアレイ装置２００は、チェックコンディション応答を返す（Ｓ１１８）。このチェックコンディション応答には、目的のLDEVがUA状態に置かれていることが示されている。

そこで、サーバ１２０は、改めてリザーブコマンドを発行する（Ｓ１１９）。ディスクアレイ装置２００は、リザーブコマンドを受信すると、リザーブ対象のLDEVのUA状態を解除する。続いて、ディスクアレイ装置２００は、このLDEVについてリザーブ状態を設定し、サーバ１２０にリザーブ完了を報告する（Ｓ１２０）。

なお、サーバ１２０がリザーブコマンドを継続して発行する構成に限らず、ディスクアレイ装置２００（SVP２６０やCHA２１０）または管理端末３１０からの電子的な通知をトリガとして、サーバ１２０がリザーブコマンドを発行する構成でもよい。

本実施例は上述のように構成したので、以下の効果を奏する。本実施例では、各LDEV単位でリザーブ状態を確認できるようにした。従って、ユーザは、各LDEV毎にリザーブ状態を容易に確認することができ、問題の所在を早期に把握することができる。

特に、ディスクアレイ装置２００に多数のサーバが接続されているような場合は、どのサーバから解除すればよいのか等を把握するのが難しい。従って、サーバからリザーブ状態を解除するのに手間と時間がかかり、メンテナンス性が低下する。これに対し、本実施例では、多数のサーバがディスクアレイ装置２００に接続されている場合でも、ディスクアレイ装置２００側からリザーブ解除を一元的に実行できる。従って、本実施例では、メンテナンス性や使い勝手が向上する。

本実施例では、管理端末３１０からSVP２６０を介して、各LDEV単位でリザーブ状態の解除を指示できるようにした。従って、リザーブ状態を設定したままでサーバがシステムダウンしたような場合でも、ディスクアレイ装置２００側でリザーブ状態を容易に解除することができる。特に、一つのポートに複数のLDEVが関連付けられているような場合は、もしもポート全体やディスクアレイ装置全体でリセット処理を実行すると、問題となっているLDEVとは無関係なLDEVを使用する他のサーバにも影響を与える。これに対し、本実施例では、LDEV単位でリザーブ状態を解除できるため、影響を与える範囲を最小限に抑制することができる。

本実施例では、リザーブコマンドに基づくリザーブ状態以外に、パーシステントリザーブ状態やACA状態についても、各LDEV単位で状況を確認することができ、ディスクアレイ装置２００側で一元的に状態を変更（解除）することができる。

図１５〜図１７に基づいて第２実施例を説明する。本実施例は、第１実施例の変形例に該当する。本実施例の一つの特徴は、アクセス優先度が低いサーバにより設定されたリザーブ状態を、アクセス優先度の高いサーバからのアクセスに基づいて強制的かつ自動的に解除できるようにした点にある。

図１５は、ストレージシステムの全体構成を示す概略ブロック図である。第１実施例との相違点を中心に説明する。サーバ１１０Ａは、本番系サーバとして使用されており、サーバ１２０Ａは開発系サーバとして使用されている。本番系サーバ１１０Ａとは、実際の業務を提供するサーバである。開発系サーバ１２０Ａとは、本番用業務アプリケーション１１１の開発等に使用されるサーバである。

共有メモリ２４０にはLDCB（Ｔ２Ａ）が記憶されている。図１６に示すように、本実施例におけるLDCB（Ｔ２Ａ）には、前記実施例で述べた情報以外に、「アクセス優先度」が設定されている。アクセス優先度とは、サーバ１１０Ａ，１２０Ａからのアクセスに対して優劣を付けるための情報である。例えば、サーバ１１０Ａ，１２０Ａからのアクセスパス（例えば、ポート番号及びＷＷＮ）に対して、優先度が設定される。図示の例では、本番系のサーバ１１０Ａに対して高いアクセス優先度が設定されている。開発系のサーバ１２０Ａには、特にアクセス優先度が設定されていない。従って、相対的に、本番系サーバ１１０Ａの方が開発系サーバ１２０Ａよりもアクセス優先度が高くなっている。このように、高いアクセス優先度を設定するアクセスパス（サーバ）にのみアクセス優先度のレベル情報を設定することができる。これに限らず、例えば、「レベル１」、「レベル２」、「レベル３」等のように、複数段階でアクセス優先度を設定することもできる。アクセス優先度は、例えば、ユーザが管理端末３１０からSVP２６０を介して事前に登録しておくことができる。

図１７は、本実施例による全体動作を示すシーケンス図である。Ｓ２０１〜Ｓ２０８は、図１４中のＳ１０１〜Ｓ１０８にそれぞれ対応するので、詳細な説明を省略する。Ｓ２０１〜Ｓ２０８は、開発系サーバ１２０Ａによって所定のLDEVがリザーブされ、使用されている状況を示している。

開発系サーバ１２０ＡがLDEVをリザーブしている状況下で、本番系サーバ１１０ＡがLDEVの使用を要求する（Ｓ２１１）。ディスクアレイ装置２００（CHA２１０）は、LDCB（Ｔ２Ａ）を参照し、アクセスパスの優先度を判定する（Ｓ２１２）。

上述の通り、本番系サーバ１１０Ａの方が、開発系サーバ１２０Ａよりもアクセス優先度が高く設定されている。従って、ディスクアレイ装置２００は、開発系サーバ１２０Ａによるリザーブ状態を解除する。これにより、開発系サーバ１２０ＡによりリザーブされていたLDEVは、リザーブ状態からUA状態に遷移する。

ディスクアレイ装置２００は、本番系サーバ１１０Ａに対して、チェックコンディション応答を返す（Ｓ２１４）。このチェックコンディション応答により、本番系サーバ１１０Ａは、目的のLDEVがUA状態に置かれていることを認識する。そこで、本番系サーバ１１０Ａは、改めてリザーブコマンドを送信する（Ｓ２１５）。このリザーブコマンドの受信によって、そのLDEVは、UA状態から通常状態に変化する。

ディスクアレイ装置２００は、サーバ１１０Ａから要求されたLDEVにリザーブ状態を設定する。そのLDEVの状態は、通常状態からリザーブ状態に変化する。ディスクアレイ装置２００は、要求されたLDEVにリザーブ状態を設定した後、リザーブが完了した旨をサーバ１１０Ａに報告する（Ｓ２１６）。

所望のLDEVのリザーブを確認したサーバ１１０Ａは、このLDEVに対してデータの読み書きを行う（Ｓ２１７，Ｓ２１８）。これにより、サーバ１１０Ａは、本番業務を図外のクライアント端末に対して提供する。

本実施例は、第１実施例と同様の効果を奏する。これに加えて、本実施例では、サーバ１１０Ａ，１２０Ａからのアクセスパスに対して予めアクセス優先度を設定し、アクセス優先度の高いサーバ１１０Ａからアクセス要求があった場合は、アクセス優先度の低いサーバ１２０Ａによるリザーブ状態を解除する構成とした。従って、優先度の低いサーバ１２０Ａのリザーブによって、優先度の低いサーバ１１０Ａの業務処理に影響が及ぶのを防止することができ、使い勝手が向上する。

特に、例えば、本番系と開発系、あるいは稼働系と待機系等のように、ストレージシステムの構成上、サーバ間の優劣が明確に定まっているような場合は、重要性や緊急性の高いサーバの稼働を保証することができ、利便性等が高まる。

図１８は、本発明の第３実施例に係わるディスクアレイ装置２００を含むストレージシステムの全体構成図である。本実施例は、第１実施例の変形例に相当する。本実施例の特徴は、通信インターフェースがそれぞれ異なる複数種類のサーバ１１０Ｂ，１２０Ｂ，１３０Ｂをサポートするディスクアレイ装置２００に適用した点にある。

サーバ１１０Ｂは、例えば、SAN（ファイバチャネル）に従ってデータ通信を行う。サーバ１２０Ｂは、例えば、iSCSI（internet Small Computer System Interface）に従ってデータ通信を行う。サーバ１３０Ｂは、例えば、TCP／IPに従ってデータ通信を行う。iSCSIとは、サーバとディスクアレイ装置との間のSCSIコマンドを、ＩＰネットワーク経由で送受信するためのプロトコルである。

ディスクアレイ装置２００には、各種プロトコルに対応したCHA２１０Ｂがそれぞれ設けられている。一つのCHAパッケージ内において、それぞれ異なる種類のプロトコルをサポートするように構成することができる。あるいは、NAS（TCP／IP）用CHAやメインフレーム用CHA等のように、各CHAパッケージ単位で異種プロトコルに対応させる構成でもよい。

本実施例も第１実施例と同様の効果を奏する。これに加えて、いわゆるマルチプラットフォームの環境下では、各サーバ１１０Ｂ，１２０Ｂ，１３０Ｂ毎にそれぞれ通信プロトコルやＯＳ等が相違する。従って、サーバ側からLDEVのリザーブを解除するための具体的な操作は、各サーバ毎にそれぞれ異なる。このため、LDEVに残されたリザーブ状態をサーバ側から解除するのは、手間と時間がかかる。

これに対し、本実施例では、通信プロトコルが異なっている場合でも、各LDEVのリザーブ状態等を一元的に管理するLDCB（Ｔ２）を直接操作することで、各LDEV単位でリザーブ状態を解除できるようにした。これにより、メンテナンス性や使い勝手等を向上させることができる。

図１９は、本発明の第４実施例を示すブロック図である。本実施例は、第１実施例の変形例に相当する。本実施例の特徴は、LDCB（Ｔ２）を共有メモリ２４０に記憶させるのではなく、各CHA２１０のメモリ２１３にそれぞれ記憶させる点にある。

各CHA２１０のメモリ２１３には、それぞれLDCB（Ｔ２）が記憶されている。各CHA２１０は、互いに通信を行って、LDCB（Ｔ２）の内容を一致させる。LDCB（Ｔ２）の内容がいずれか一つのCHA２１０で変更された場合、この変更は、他のCHA２１０にそれぞれ保持されているLDCB（Ｔ２）にも反映される。

なお、場合によっては、LDCB（Ｔ２）を各DKA２２０のメモリにそれぞれ記憶させる構成でもよい。

図２０，図２１に基づいて本発明の第５実施例を説明する。本実施例は、第１実施例の変形例に相当する。本実施例の特徴は、外部のディスクアレイ装置が有する記憶資源を取り込んで使用する点にある。

ディスクアレイ装置２００は、外部に位置する他のディスクアレイ装置４００とSAN等の通信ネットワークを介して接続されている。この外部ディスクアレイ装置４００は、ポート４１０及びLDEV４２０を備える。

外部のLDEV４２０は、例えば、ディスクアレイ装置２００のLUNにマッピングされて、LDEV２５０Ｖを構築している。即ち、LDEV２５０Ｖの実体は、外部ディスクアレイ装置４００内に存在する。ディスクアレイ装置２００は、サーバ１１０，１２０に対して、LDEV２５０Ｖがあたかも自己に備わっている記憶資源であるかのように見せかけ、振る舞う。

例えば、図２１に示すように、ポート−LUN構成情報Ｔ１Ａ内に、外部のボリューム（LDEV）４２０へのパス情報を含めることにより、外部の記憶資源をディスクアレイ装置２００内に取り込むことができる。なお、外部のLDEV４２０をLUNに直接的にマッピングするのではなく、中間の仮想的な記憶層を追加し、この中間記憶層に外部のLDEV４２０をマッピングする構成でもよい。

本実施例も第１実施例と同様の効果を奏する。これに加えて、本実施例では、外部の記憶資源を有効に利用することができ、外部の記憶資源に対するリザーブ状態の解除もディスクアレイ装置２００側から一元的に行うことができる。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。

本発明の実施形態の全体概念を示す説明図である。 本発明に使用可能なディスクアレイ装置の外観図である。 ディスクアレイ装置の構成例を示すブロック図である。 リザーブ状態の解除を行うことができるディスクアレイ装置のブロック図である。 サーバとCHAとのより詳細な構成を示すブロック図である。 ポート−LUN構成情報を示す説明図である。 LDEVの状態を制御するためのLDCBを示す説明図である。 リザーブ処理のフローチャートである。 リード／ライト処理のフローチャートである。 リリース処理のフローチャートである。 各LDEV単位のリザーブ状態表示処理を示すフローチャートである。 各LDEV単位のリザーブ状態解除処理を示すフローチャートである。 リザーブ状態をいったん解除した後における新たなリザーブ処理を示すフローチャートである。 全体動作の流れを示すシーケンス図である。 第２実施例に係るディスクアレイ装置のブロック図である。 LDCBの構成を示す説明図である。 全体動作の流れを示すシーケンス図である。 第３実施例に係るディスクアレイ装置のブロック図である。 第４実施例に係るディスクアレイ装置のブロック図である。 第５実施例に係るディスクアレイ装置のブロック図である。 ポート−LUN構成情報の説明図である。

符号の説明

１，２…サーバ、３…ディスクアレイ装置、４…論理ボリューム、５…メモリ、６…排他制御情報、７…管理端末、８，９Ａ，９Ｂ…通信ネットワーク、１０…ディスクアレイ装置、１１…基本筐体、１２…増設筐体、１３…制御パッケージ、１４…電源ユニット、１５…バッテリユニット、１６…冷却ファン、２１Ａ…通信ポート、２２…チャネルアダプタ、２３…キャッシュメモリ、２４…共有メモリ、２５…スイッチ部、２６…ディスクドライブ、２７…RAIDグループ、２８…LDEV（論理ボリューム）、２９…SVP（サービスプロセッサ）、３０…ホストコンピュータ、３１…管理端末、１１０，１２０，１３０…サーバ、１１１，１２１，１３１…業務アプリケーションプログラム、１１２，１２２，１３２…HBA、１１３，１２３…ハートビート監視部、２００…ディスクアレイ装置、２１０…チャネルアダプタ、２２０…ディスクアダプタ、２３０…キャッシュメモリ、２４０…共有メモリ、２５０…LDEV、２６０…SVP、３００…ファイバチャネルスイッチ、３１０…管理端末、４００…外部のディスクアレイ装置、４１０…通信ポート、４２０…LDEV、ＣＮ…通信ネットワーク

Claims (20)

1. 複数の上位装置とのデータ授受を通信ポートを介してそれぞれ制御する上位インターフェース制御部と、
   記憶デバイスとのデータ授受を制御する下位インターフェース制御部と、
   前記上位インターフェース制御部及び前記下位インターフェース制御部により共用されるメモリ部と、
   前記記憶デバイス上に設けられ、前記通信ポートを介してアクセス可能な論理ボリュームと、
   前記各上位装置のうちいずれか一つの上位装置が前記通信ポートを介して前記論理ボリュームを排他的に使用するための排他制御情報を記憶する排他制御情報記憶領域と、
   前記上位インターフェース制御部に設けられ、前記排他制御情報に基づいて前記論理ボリュームの排他制御を実行する排他制御部と、
   解除指示を検出した場合に、前記排他制御情報を更新することにより、前記排他的使用を前記論理ボリューム単位で解除させる解除制御部と、
   を備えたディスクアレイ装置。
2. 前記排他制御情報記憶領域は、前記メモリ部または前記上位インターフェース制御部の少なくともいずれか一方に設けられている請求項１に記載のディスクアレイ装置。
3. 前記解除制御部は、前記上位インターフェース制御部に設けられている請求項１に記載のディスクアレイ装置。
4. 前記論理ボリュームは複数設けられており、前記通信ポートには前記複数の論理ボリュームが対応付けられている請求項１に記載のディスクアレイ装置。
5. 前記排他制御情報の全部または一部に基づいて、前記論理ボリュームの排他的使用に関する所定の情報を表示させる表示部を備えた請求項１に記載のディスクアレイ装置。
6. 前記排他制御情報の全部または一部に基づいて、前記論理ボリュームの排他的使用に関する所定の情報を表示させる表示部と、
   前記表示部により表示された前記所定の情報に基づいて、前記解除指示を前記解除制御部に与える解除対象選択部とを備えた請求項１に記載のディスクアレイ装置。
7. 前記各上位装置の優先度を管理するための優先度管理情報を記憶する優先度管理情報記憶領域と、
   相対的に優先度が低い上位装置が前記論理ボリュームを排他的に使用している場合において、相対的に優先度が高い上位装置が前記論理ボリュームへのアクセスを要求した場合は、前記解除指示を前記解除制御部に与える優先度判定部とを備えた請求項１に記載のディスクアレイ装置。
8. 前記解除制御部は、前記論理ボリュームの排他的使用を解除した場合に、前記論理ボリュームの状態変更を前記各上位装置にそれぞれ通知する請求項１に記載のディスクアレイ装置。
9. 前記論理ボリュームの排他的使用は、前記上位装置から発行されるリザーブコマンドに基づくものである請求項１に記載のディスクアレイ装置。
10. 前記各上位装置は、フェイルオーバクラスタを構成している請求項１に記載のディスクアレイ装置。
11. 前記論理ボリュームは、外部装置が有する他の論理ボリュームにより提供される請求項１に記載のディスクアレイ装置。
12. 複数の上位装置とのデータ授受を通信ポートを介してそれぞれ制御する上位インターフェース制御部と、
    記憶デバイスとのデータ授受を制御する下位インターフェース制御部と、
    前記上位インターフェース制御部及び前記下位インターフェース制御部により共用されるメモリ部と、
    前記記憶デバイス上に設けられ、前記通信ポートを介してアクセス可能な論理ボリュームと、
    前記各上位装置のうちいずれか一つの上位装置が前記通信ポートを介して前記論理ボリュームをリザーブして使用するためのリザーブ情報を記憶するリザーブ情報記憶領域と、を備えたディスクアレイ装置のリザーブ解除制御方法であって、
    前記論理ボリューム単位で解除指示を発生させる解除指示発生ステップと、
    前記解除指示が発生された場合は、前記リザーブ情報を更新することにより、リザーブ状態を解除させるリザーブ解除ステップと、
    を含むディスクアレイ装置のリザーブ解除制御方法。
13. 前記論理ボリュームは複数設けられており、前記通信ポートには前記複数の論理ボリュームが対応付けられている請求項１２に記載のディスクアレイ装置のリザーブ解除制御方法。
14. 前記解除指示発生ステップの前に、前記リザーブ管理情報の全部または一部に基づいて前記論理ボリュームのリザーブ状態を表示させるリザーブ状態表示ステップを備える請求項１２に記載のディスクアレイ装置のリザーブ解除制御方法。
15. 前記解除指示発生ステップの前に、相対的に優先度が低い上位装置によりリザーブされている前記論理ボリュームに対して、相対的に優先度が高い上位装置がアクセスを要求したか否かを判定する優先度判定ステップを備えた請求項１２に記載のディスクアレイ装置のリザーブ解除制御方法。
16. 前記リザーブ解除ステップの後に、前記論理ボリュームのリザーブ状態が解除された旨を前記各上位装置にそれぞれ通知可能な解除通知ステップを備えた請求項１２に記載のディスクアレイ装置のリザーブ解除制御方法。
17. 前記リザーブ解除ステップの後に、前記論理ボリュームのリザーブ状態が解除された旨の状態変更情報を前記リザーブ管理情報に設定する設定ステップを備えた請求項１２に記載のディスクアレイ装置のリザーブ解除制御方法。
18. 前記設定ステップの後に、前記各上位装置からの問合せに対して前記リザーブ管理情報の前記状態変更情報を参照することにより、前記リザーブ状態が解除された旨をそれぞれ通知可能な解除通知ステップを備えた請求項１２に記載のディスクアレイ装置のリザーブ解除制御方法。
19. 前記各上位装置は、フェイルオーバクラスタを構成している請求項１２に記載のディスクアレイ装置のリザーブ解除制御方法。
20. 前記論理ボリュームは、外部装置が有する他の論理ボリュームにより提供される請求項１２に記載のディスクアレイ装置のリザーブ解除制御方法。

Images