JP2005285086A - マルチステージのボリュームロッキングに対する方法と装置 - Google Patents

Abstract

【課題】他のストレージサブシステムのストレージ資源又はボリュームを使用するストレージサブシステムが、ストレージ資源の属性を制御できるようにする。
【解決手段】ストレージサブシステムは、複数のポートを有するコントローラと情報を記憶するように構成された複数のストレージ装置とを備える。ロックテーブルは、ホスト装置に提供される複数のストレージボリュームのそれぞれに対して、属性情報と保存情報を含む。複数のストレージボリュームは、ストレージサブシステムの第一のストレージ装置にマッピングされた仮想的でないボリュームと、関連ストレージサブシステムの第二のストレージ装置にマッピングされた仮想的ボリュームを含む。関連サブシステムは通信路を経由してストレージサブシステムにリンクされる。コントローラはホストからの要求を受信し処理して仮想的ボリュームの属性を変更する様に構成される。
【選択図】図１

Description

本発明は複数のストレージボリュームを有するストレージシステムの管理に関する。

データは全てのコンピュータ処理が基礎とする基本的な資源である。インターネットとイービジネスの最近の急激な成長で、データストレージシステムに対する要求はすさまじく増加してきた。多くのタイプのストレージデバイス、例えば半導体装置、磁気ディスク、磁気テープがある。これらはデータを記憶するために使用される。これらのタイプのストレージ装置のそれぞれは異なったアクセススピードとそれに関係したコストを有している。半導体装置は一般に最も高速で又最も高価である。従って、半導体装置は、大量のデータを記憶する必要があるデータセンターでは一般的には使用されない。

一般に、磁気ディスクと磁気テープは、半導体装置より相当低価格なので、データセンターで使用するのに採用されるストレージ装置である。データセンターのストレージシステムは一般に複数の処理装置を有しており、大量のデータを速く読み出し書き込みするために高度なオペレーティングシステムを備えている。

データセンター又はストレージシステムは一般に複数のストレージユニット又はサブシステムを備えている。そのいくつかは主ストレージ装置として構成されており、その他は従ストレージ装置として構成されている。主ストレージ装置は、ユーザがアクセスするアクティブデータを記憶するように設計されており、一方、従ストレージ装置は主ストレージ装置に障害が発生した場合に使用されるバックアップ装置として動作する。従ストレージ装置はまた、主装置が必要としない“非アクティブ”又は“古い”データを記憶又はアーカイブするのに使用され、主装置のストレージ容量が新しいデータを受け入れることができる。主ストレージ装置は主サイトに配置され、従ストレージ装置は主サイトから数十、数百、又は数千マイルも離れた従サイトに配置される。

これらのデータセンターはストレージエリアネットワーク（ＳＡＮ）を使用して結ばれている。ＳＡＮは、複数のストレージサブシステムをお互いに結び、複数のホストをこれらのストレージサブシステムに結ぶのに使用されるバックエンドネットワークである。ホストを複数のストレージ装置のそれぞれに直接接続するよりも、ホストをＳＡＮに単純に接続することによって、ホストコンピュータは複数のストレージ装置又はサブシステムをアクセスできるので、ＳＡＮはサブシステムのストレージ容量の共有を容易にすることを可能にする。

ＳＡＮの意図した目的は単純化したストレージの解決法を提供することであるが、ＳＡＮの解決法の実施と維持は非常に複雑になるであろう。ＳＡＮとそれに接続したストレージサブシステムに関連した管理上のオーバヘッドは、ＳＡＮの構成がよりますます複雑になるに伴い、非常に大きくなる。この管理上の問題点の一つの解決法はストレージの仮想化を提供することである。

ストレージの仮想化は、物理的なストレージ装置からストレージの表現を分離する抽象的な層である。一つの典型的な構成では、複数の物理的なストレージ装置が単一の仮想的ストレージプールに集約される。仮想的プールに関連したストレージボリュームは、たとえ論理的装置が仮想化されたストレージサブシステムを経由してホストに間接的に接続されても、ホストに部分的に接続された論理的装置として見える。従って、仮想化によって、ＩＴ管理者は、ＳＡＮ又はＮＡＳボリュームとしてあるいは両方として、仮想的プールで使用可能なストレージボリュームを自由に供給できる。

ストレージの仮想化に関係した一つの問題は、他のストレージサブシステムのストレージ資源又はボリュームを使用するストレージサブシステム（又は仮想化されたストレージサブシステム）は、その様なストレージ資源の属性を制御できない、ということである。属性は論理的ユニット又はボリュームのアクセス方針を制御する。

一つの実施例では、ターゲットボリュームに対するリ−ド／ライトオペレーションの完了の後に、ホストのアプリケーションはストレージＡＰＩ機能を呼び出し使用ボリュームの属性を変更する。属性はアクセス方針又は保存期間である。ストレージＡＰＩは状態変更の要求を仮想化されたストレージサブシステムに送る。仮想化されたストレージサブシステムは、属性変更の要求を仮想的ボリュームが実際に定義される関連ストレージシステムに送る。関連ストレージサブシステムは属性を変更し、保持し、実行する。そして関連ストレージサブシステムは仮想化されたストレージサブシステムを経由してホストのストレージＡＰＩに結果を返す。

一つの実施例では、ストレージサブシステムは、複数のポートを有するコントローラと情報を記憶するように構成された複数のストレージ装置とを備える。ロックテーブルは、ホスト装置に提供された複数のストレージボリュームのそれぞれに対する属性情報と保存情報を含む。複数のストレージボリュームは、ストレージサブシステムの第一のストレージ装置にマッピングされた仮想的でないボリュームと、関連ストレージサブシステムの第二のストレージ装置にマッピングされた仮想的ボリュームを含む。関連サブシステムはコミュニケーションリンクを経由してストレージサブシステムにリンクされる。コントローラはホストからの要求を受信し処理して仮想的ボリュームの属性を変更するように構成される。

他の実施例では、ストレージシステムを管理する方法は以下のステップを含む。第一のストレージサブシステム内のストレージ領域にマッピングされた仮想的でないボリュームと第一のサブシステムとは異なる第二のストレージサブシステム内のストレージ領域にマッピングされた仮想的ボリュームとを含む複数のストレージボリュームを第一のストレージサブシステムを経由してホストに提供するステップ、第一のサブシステムでホストから第一の要求を受信しホストに提供される複数のストレージボリュームの中の一つであるターゲットストレージボリュームの属性を変更するステップ、及び、もしターゲットボリュームが仮想的ボリュームであると決定されると第一のサブシステムから第二のサブシステムにターゲットボリュームの属性を変更する第二の要求を送るステップ、である。

さらに他の実施例では、コンピュータで読み取り可能な媒体はストレージサブシステムを管理するコンピュータプログラムを含んでいる。このコンピュータプログラムは以下のプログラムコードを備えている。第一のストレージサブシステム内のストレージ領域にマッピングされた仮想的でないボリュームと第一のサブシステムとは異なる第二のストレージサブシステム内のストレージ領域にマッピングされた仮想的ボリュームとを含む複数のストレージボリュームを第一のストレージサブシステムを経由してホストに提供するプログラムコード、第一のサブシステムでホストから第一の要求を受信しホストに提供される複数のストレージボリュームの一つであるターゲットストレージボリュームの属性を変更するプログラムコード、及び、もしターゲットボリュームが仮想的なボリュームであると決定されると第一のサブシステムから第二のサブシステムにターゲットボリュームの属性を変更する第二の要求を送るプログラムコード、である。

ここで使用されている用語“仮想化されたストレージサブシステム”は、少なくとも一つの仮想的ストレージボリュームをホストに提供するストレージシステムである。従って、仮想化されたストレージサブシステムは、仮想的ボリュームだけか或いは仮想的及び仮想的でないボリュームの両方を備える。

ここで使用されている用語“仮想的でないボリューム”は、仮想化されたストレージサブシステムの一つ以上のストレージ装置で定義される内部ボリュームである。すなわち、仮想的でないボリュームは、仮想的ストレージサブシステムから外部には配置されない。

ここで使用されている用語“仮想的ストレージボリューム”或いは“仮想的ボリューム”或いは“仮想的ＬＵ”は、たとえストレージボリュームが仮想的ストレージサブシステムに配置されていなくても、仮想的ストレージサブシステムを経由してホストに提供されるストレージボリュームである。すなわち、仮想的ストレージボリュームは仮想的ストレージサブシステムとは異なったストレージサブシステムに配置される。

ここで使用されている用語“外部ストレージサブシステム”或いは“外部サブシステム”或いは“関連ストレージサブシステム”或いは“関連サブシステム”は、仮想的ストレージボリュームを仮想的ストレージサブシステムに提供するストレージサブシステムである。

ここで使用されている用語“ストレージシステム”は、データを記憶するために構成されたコンピュータシステムであり、一つ以上のストレージユニット或いはストレージサブシステム、例えばディスクアレイユニットを備える。従って、ストレージシステムは、一つ以上のホストと一つ以上のストレージサブシステム、或いは一つだけのストレージサブシステム又はユニット、或いはコミュニケーションリンクを経由して複数のホストに接続された複数のストレージサブシステム又はユニットを備えるコンピュータシステムである。

ここで使用されている用語“ストレージサブシステム”は、データを記憶するために構成され、ストレージ領域及び一つ以上のホストからの要求を処理するためのストレージコントローラを備えるコンピュータシステムである。ストレージサブシステムはストレージ装置、ストレージユニットなどと呼ばれる。ストレージサブシステムの一つの例はディスクアレイユニットである。

ここで使用されている用語“ホスト”は、一つ以上のストレージシステム又はストレージサブシステムに接続され、ストレージシステム又はストレージサブシステムに要求を送付するように構成されるコンピュータシステムである。ホストはサーバ又はクライアントの機能を実行する。

本発明は仮想的ストレージボリュームを提供するストレージシステムに関係する。一つの実施例は、仮想的および内部ボリュームの両方の属性が仮想化されたストレージサブシステム上で管理されるという方法で、仮想化されたストレージサブシステムを管理することに関係する。仮想化されたストレージシステムは、ホストのストレージＡＰＩが仮想化されたストレージサブシステムを呼び出すときに、仮想的ボリューム（ＶＬＵＮ）に対して属性、たとえばリードオンリ又はリ−ド／ライトを管理する。

図１と図２は、本発明の一つの実施例による仮想化されたストレージサブシステム２０を有するストレージシステム１を示す図である。図１はストレージシステムのハードウェア構成要素とそれらの内部接続を示す。図２はストレージシステムの論理的構成を示す。ストレージシステムは、ホスト１０、仮想化されたストレージサブシステム（ＶＳＳ）２０、一つ以上の関連ストレージサブシステム３０、及び管理コンソール９２を含む。ホストはストレージエリアネットワーク（ＳＡＮ）７０を経由してＶＳＳ２０に接続される。ＶＳＳと関連ストレージサブシステムはＳＡＮ７１を経由して接続される。ＳＡＮ７０と７１は同じネットワークであってもなくても良い。ローカルエリアネットワーク（ＬＡＮ）９１はコンソールとＶＳＳを接続する。

一つの実施例では、ホスト、ＶＳＳ及び関連サブシステムは、アウトオブバンド制御として、イーサネット（イーサネットは登録商標です）をベースとしたネットワークを使用して、一緒に接続される。他の実施例では、インバンド接続、例えばＳＡＮ７０又は７１が、ＶＳＳ及び関連サブシステムを制御するために使用される。さらに他の実施例では、他のタイプのネットワーク、例えばＳＣＳＩ、ｉＳＣＳＩ、トークンリング等が使用される。

ホストは、中央処理装置１１、メモリー１２、ストレージ領域又はディスク１３、及びホストバスアダプタ（ＨＢＡ）１４を備える。ホストは、データを生成し処理できるアプリケーション１９、アプリケーションで発行されるコマンドによってデータを書き込み又は読み出しするためにアプリケーションとストレージサブシステムの間のインタフェース接続をするストレージＡＰＩ１８、ホストでソフトウェアプログラムを実行するためにプラットホームを提供するオペレーティングシステム１７、及びサブシステムのブロック装置例えばディスクをアクセスするためにＨＢＡを制御するドライバ１６を備える（図２を参照）。一つの実施例では、ホストは汎用コンピュータ又はサーバである。ストレージＡＰＩは、ＳＣＳＩコマンドセットを使用するストレージサブシステムを制御するための容量を有する。ストレージサブシステムはターゲット装置であるので、我々は直接にはストレージを制御できない。ＳＣＳＩコマンドセットを使用してストレージ装置を制御するこの技術は、ライン００２２−００４の“ＥＰ１２４６０５０”の一部分としてすでに存在している。ＲＭＬＩＢとコマンド装置に適合したストレージＡＰＩは、ＥＰ１２４６０５０のＣＭに等しい。

ＶＳＳ２０は、本実施例ではスモールコンピュータシステムインタフェース（ＳＣＳＩ）コマンドに従ってストレージボリューム又はＬＵにデータを記憶するように構成される。ＶＳＳはストレージコントローラ２１と複数のディスク２２を含む。コントローラは、ホスト又は関連サブシステムにＶＳＳをリンクするために使用される複数のポート２３、２４、及び２５を含む。

各ポートはワールドワイドネーム（ＷＷＮ）を備えている。これはユニークな識別子であり、ターゲットＩＤと呼ばれる。各ポートで、２５６までのＬＵＮが本実施例において定義できる。ポートはファイバチャネルの物理ポートに等しい。コントローラは各物理ポートから複数の仮想的ポートを定義できる。それでも、ある特定の物理ポートに関係した仮想的ポートは全部で２５６より多くのＬＵＮを有することはできない。

一般的に、コントローラはディスク２２への読み出し及び書き込み要求を管理する処理装置を備える。コントローラはまた、関係した要求を実行する前にデータを一時的に記憶する不揮発性のランダムアクセスメモリ（ＮＶＲＡＭ）を備える。ＮＶＲＡＭは、バッテリバックアップを使用して、電源障害からデータが保護されることを確実にするために使用される。

ＶＳＳはデータと設定情報を記憶するための複数の内部ＬＵ（Ｉ−ＬＵ）を提供する。データを記憶するＩ−ＬＵはデータボリュームと呼ばれ、設定情報を記憶するものは設定ボリュームと呼ばれる。ストレージボリュームは、ハードウェア障害からデータを保護するために種々の既知の構成、例えばＲＡＩＤ０、ＲＡＩＤ５、又は他の技術で構成される。

ここで使用されている用語“データ”は、ホストのアプリケーション１９によって生成又は処理される実際の情報である。用語“設定情報”は、データの保管、回復などを管理するために使用される管理上の情報である。設定情報の例は内部のマッピングテーブル６０、ロックテーブル７０、及びポートマップテーブル８０であり、これらについては後でより詳細に説明する。

関連サブシステム３０のそれぞれは、複数のポート３３と３４有するコントローラ３１及び複数のディスク３２を備える。ポート３３はＶＳＳのポートに接続され、ポート３４はサブシステム内のストレージディスクに接続される。

コンソール９２はＶＳＳと関連サブシステムを含むストレージサブシステムを管理するために使用される。管理機能は、ＬＵの生成、ＬＵの属性の定義などを含む。コンソールは図１では外部のサーバとして示されているが、コンソールはサブシステムの一つ、例えばＶＳＳ又は関連サブシステムに統合されることができる。

図２は本発明の一つの実施例によるストレージシステム１の論理的構成とソフトウェアを示す。ＶＳＳのコントローラ２１は設定情報又はテーブル、すなわちロックテーブル４０、ポートマップテーブル５０、及び内部マップテーブル６０を管理する。

図３Ａは本発明の一つの実施例によるポートマップテーブル５０を示す。テーブルはホストに送出されるＬＵとポートのマッピング情報を含む。ポートマップは特定のポートを示すためのポートフィールド５１、特定のターゲットＩＤを示すためのＷＷＮフィールド５２、及びＬＵとしてホストにＩ−ＬＵを提供するＬＵＮフィールド５３を含む。ホストはアクセスされるストレージ領域を識別するためにマッピング情報を使用する。

図３Ｂは本発明の一つの実施例による内部マップテーブル６０を示す。テーブルはＩ−ＬＵＮフィールド６１、ＷＷＮフィールド６２、及び外部ＬＵＮフィールド６３を含む。テーブルはＩ−ＬＵを外部の論理ボリュームにマッピングする。

本実施例において、ホストに提供されるＩ−ＬＵはＶＳＳ（又は仮想的でないボリューム）に対して内部のＬＵ及びＶＳＳ（又は仮想的ボリューム）に対して外部のＬＵも含む。図２で、ＬＵ２７−１はＶＳＳのストレージディスク又は論理デバイス（ＬＤＥＶ）に関係する内部の論理ボリュームである。しかし、ＬＵ２７−２は関連サブシステム３０に存在するストレージディスク又はＬＤＥＶに関係する外部の論理ボリュームである。従って、ＬＵ２７−１はＶＳＳの中に配置されるといわれ、ＬＵ２７−２はＶＳＳに対して外部に配置されるといわれる。

図３Ｂに戻って、ＶＳＳの内部ストレージであるＩ−ＬＵ６５は、ＷＷＮフィールド６２に値を有さず、またこれらのボリュームはＶＳＳに存在するので、外部のＬＵＮにマッピングされない。しかし、仮想的ボリュームであり関連サブシステムに配置されるＩ−ＬＵ６７は外部のＬＵＮにマッピングされる。

図３Ｃは本発明の一つの実施例によるロックテーブル４０を示す。ロックマップ４０は、Ｉ−ＬＵフィールド４１、許可フィールド４２、及び保存フィールド４３を含む。もしもＩ−ＬＵが外部のストレージサブシステム（関連サブシステム）のストレージ装置又はＬＤＥＶにマッピングされると、フィールド４２と４３に対するエントリーは“−”であり、Ｉ−ＬＵが仮想的ストレージボリュームであることを示す。この様な仮想的ストレージボリュームに対する許可及び保存情報は関連サブシステムのロックテーブルで保持される。これについては後でより詳細に説明する。

示されるように、テーブルはＩ−ＬＵについての属性と保存情報を含む。属性は特定のＬＵのふるまいを定義する。従って、属性はＬＵのふるまいを定義する他のルールと同じく許可情報を含む。保存情報は時間の長さを提供し、特定の属性がＬＵに割り当てられる。本実施例において、特定のＬＵに割り当てられる属性は、特定の保存期間以内は、いいかえれば保存期間が終了するまでは変更することはできない。

本実施例において、許可情報は、読み出しと書き込みの両方のアクセスが特定のＬＵに許可されることを示すＲＥＡＤ／ＷＲＩＴＥモード、読み出しのアクセスだけが特定のＬＵに許可されることを示すＲＥＡＤ ＯＮＬＹモード、及びＳＣＳＩの容量調査コマンドが受信された時にサイズ−ゼロが返答されることを示すＺＥＲＯ−ＣＡＰＡＣＩＴＹを含む。ＺＥＲＯ−ＣＡＰＡＣＩＴＹが割り当てられたＬＵは、バックアップデータを記憶するための従ボリュームとしては動作できない。

従って、数字４５で示されるＩ−ＬＵ１はＲＥＡＤ ＯＮＬＹ属性が割り当てられ、特定の保存期間、すなわち６年間、読み出しのアクセスだけがホスト１０に許可される。ホストはこの期間はＩ−ＬＵ１に書き込みができない。一方、数字４７で示されるＩ−ＬＵ２は永久にＲＥＡＤ ＯＮＬＹ属性が割り当てられ、ここに記憶されたデータはホストによって削除されたり変更されたりすることはできない。

関連サブシステム３０のそれぞれはポートマップテーブル１７０、ロックテーブル１８０、及び内部マップテーブル１７５を含む。これらのテーブルはＶＳＳのテーブルに対応する。ポートマップテーブル１７０はポートフィールド１７１、ＷＷＮフィールド１７２、及びＬＵＮフィールド１７３を含む（図４Ａ）。ロックテーブル１８０はＩ−ＬＵフィールド１８１、許可フィールド１８２、及び保存フィールド１８３を含む（図４Ｂ）。内部マップテーブル１７５は関連サブシステム内で使用される識別情報を示すＬＵＮフィールド１７６、及びホストで使用される識別情報を示すＩ−ＬＵフィールド１７７を含む（図４Ｃ）。従って、テーブル１７５はＩ−ＬＵを関連サブシステムのＬＵＮにマッピングする。

図５は、本発明の一つの実施例による、新しい外部ＬＵ（仮想的なストレージボリューム）を発見するためにＶＳＳで実行されるプロセスを示す。ステップ２００で、ＶＳＳのコントローラ２１はＳＡＮに設置されたポートに調査コマンドを送付する。各ポートはユニークなＷＷＮを有しており、これはＳＣＳＩのターゲットＩＤである。受信した応答をもとに、コントローラ２１は、受信したＷＷＮをポートテーブルのＷＷＮと比較して、新しいターゲットがあるか又はポートが最後の調査コマンド以後にＳＡＮに設置されたかどうかを決定する（ステップ２０１）。もしも新しいターゲットが設置されていると、コントローラは新しいＷＷＮ又はポートを選択する（ステップ２０２）。

コントローラは新しいポートのＬＵＮを調査する（ステップ２０３）。もしも最大のＬＵＮがＬＵＮの最大数（例：一つのポートに対して２５５）より小さければ、プロセスは次のステップに進む。もし最大のＬＵＮが２５５以上であれば、許されたＬＵＮの最大数が本実施例では２５６なので、プロセスはステップ２０１に戻る。すなわち、現在のＳＣＳＩの環境では、物理的なポートは２５５より多いＬＵＮを有することはできない。ＬＵＮの番号は０で始まる。仮想的ポートの機能が使用されると、一つの“物理的なポート”はホストのＷＷＮに関連した数個の仮想的ポートを有する。ストレージサブシステムは、ＬＵを物理的なポートに関連した仮想的ポートにグループ化するために、一つの特定の“物理的な”ポートに５１２より多いＬＵＮを提供できる。

ステップ２０４で、コントローラはＳＣＳＩの調査コマンドを発行して新しいポートのストレージサブシステムに対してベンダ名とシリアル番号を調べる。この時点で、ＬＵに対する属性の状況と対応する保存期間が同じくチェックされる。その後、内部のマッピングテーブル６０は更新され新しいＷＷＮと新しいＬＵＮを含む。

ステップ２０１に戻って、新しいＷＷＮが受信されていなければ、コントローラは新しいポートがＳＡＮに設置されていないと決定する。プロセスは処理を終了し次の処理を始めるのを待つ。

一つの実施例では、オペレータは、ＶＳＳを使用しないで処理を開始し、及び／又はＬＵＮをＩ−ＬＵＮにマッピングすることを決定する。例えば、オペレータはコンソール９２を使用してＬＵＮをＩ−ＬＵＮに割り付け、それをホストに提供する。内部のマッピングテーブル６０はこの情報で更新される。

一方、ホスト１０はＳＣＳＩの調査コマンドを使用してＬＵをスキャンし、新しいＬＵへのアクセスを開始するためにその新しいＬＵに論理ボリューム番号とデバイス名を割り当てる。一つの実施例では、Ｗｉｎｄｏｗｓ（Ｗｉｎｄｏｗｓは登録商標です）のデバイスファイルは/dev/rdsk/c4t1d0のようになり、Unix（Unixは登録商標です）では＼＼．＼PhysicalDisk1となる。

図６は本発明の一つの実施例によるＬＵ又はボリュームの属性をマッピングするプロセスを示す。属性はＬＵをＲＥＡＤ ＯＮＬＹ、ＲＥＡＤ−ＷＲＩＴＥ、ＳＩＺＥ−ＺＥＲＯ、又はそれらの組み合わせに設定することを含む。例えば、ＬＵをＲＥＡＤ ＯＮＬＹとＳＩＺＥ−ＺＥＲＯの両方に設定することができる。

最初、データはＳＣＳＩの書き込みコマンドを使用してＬＵに記憶される。求められるデータがＬＵに記憶される（又はＬＵが満杯である）と、アプリケーションはＬＵの属性を変更する。属性は、本実施例ではＲＥＡＤ−ＷＲＩＴＥからＲＥＡＤ ＯＮＬＹ又はＳＩＺＥ−ＺＥＲＯに変更される。属性はＬＵのふるまいに影響する規則である。従って、もしも必要ならば、他のタイプの属性がＬＵに割り当てられ変更されることができる。属性は、以下に説明する様に、ストレージＡＰＩを呼び出して変更される。

ステップ３００で、アプリケーションはストレージＡＰＩの“set_volume_guard”を呼び出す。ターゲットの内部のＬＵ番号、属性、及び属性の保存期間が提供される。ストレージＡＰＩは属性を管理するために少なくとも二つのＩ／Ｆを提供する。

● int set_volume_guard(internal_LU_num, retention, attribute)
● int unset_volume_guard(internal_LU_num)
第一のコマンド又は要求はボリュームの属性をＲＥＡＤ ＯＮＬＹに変更することである。すなわち、ボリュームはロックされる。ボリューム番号と保存期間は指定される。第二のコマンドはボリュームの属性をＲＥＡＤ ＯＮＬＹからＲＥＡＤ−ＷＲＩＴＥに変更することである。すなわち、ボリュームはアンロックされる。

ステップ３０１で、ストレージＡＰＩはターゲットのＩ−ＬＵをＲＥＡＤ ＯＮＬＹにすることをロッカーモジュール３９に要求する。本実施例では、モジュール３９はマイクロコードの一部であり、ＶＳＳのコントローラ２１に配置される。

ロッカーモジュールはＳＡＮ７０を経由して要求を受信する（ステップ３０２）。Ｉ−ＬＵの位置は内部のマッピングテーブル６０を使用してチェックされる（ステップ３０３）。もしＩ−ＬＵの位置がＶＳＳの中であれば、ロッカーモジュールはＩ−ＬＵの属性を要求される様に変更する（ステップ３０４）。ＶＳＳによって管理されるロックテーブル４０はそれに応じて更新される。この動作の認識はストレージＡＰＩに送付される（ステップ３０９）。次に、ストレージＡＰＩはターゲットのＩ−ＬＵがＲＥＡＤ ＯＮＬＹにロックされたことをアプリケーションに通知する（ステップ３１０）。

ステップ３０３で、もしターゲットのＩ−ＬＵがＶＳＳでなく関連サブシステム３０に配置されていると判定されると、コントローラ２１は関連サブシステム３０に要求を送付する（ステップ３０５）。関連サブシステムのコントローラ３１内のロッカーモジュール４９はＳＡＮ７１を経由して要求を受信する（ステップ３０６）。ターゲットのＩ−ＬＵは要求に従ってロックされる（ステップ３０７）。ロックテーブル８０はそれに応じて更新される。この動作の認識はＶＳＳに送付される（ステップ３０８）。ＶＳＳはそれをストレージＡＰＩに転送する（ステップ３０９）。ストレージＡＰＩはターゲットのＩ−ＬＵがＲＥＡＤ ＯＮＬＹにロックされたことをアプリケーションに通知する（ステップ３１０）。

ＬＵがロックされると、ホストはＬＵに書き込むことを許可されない。もしもＬＵへの書き込み要求がホストによって送付されると、コントローラはホストにエラーメッセージを送付する。一つの実施例では、ＡＰＩとＶＳＳの間、又はＶＳＳと関連サブシステムの間の通信は、アウトオブバンドの通信路、例えばイーサネットを通して行なわれる。代わりに、インバンド通信路が使用されてもよい。

図７は本発明の一つの実施例によるＬＵの保存情報を管理するためのプロセスを示す。ステップ４００で、コントローラのロッカーモジュールは、ターゲットのＬＵが属性を割り当てられたかどうか、例えばＬＵがロックされたかどうかを判定する。もし属性が割り当てられていたならば、ロッカーモジュールは保存情報を変更する（ステップ４１０）。ロックテーブルの保存フィールドは更新される。

本実施例では、保存情報は保存期間を増やすためだけに変更される。すなわち、保存期間は、一度ＬＵに割り当てられると短縮されない。保存期間は毎日１ずつ減らされるように単位として日を使用する。時間の他の単位、例えば秒、分、時間、月、年も使用できる。

ステップ４００に戻って、もしターゲットＬＵがロックされていない場合は、ロッカーモジュールはターゲットＬＵをロックする（ステップ４０１）。ＲＥＡＤ ＯＮＬＹの属性は、もしＬＵがＶＳＳの中に配置されているとロックテーブル４０の許可フィールド４２に記憶され、もしＬＵが関連サブシステムに配置されているとロックテーブル８０の許可フィールド８２に記憶される。

図８は本発明の一つの実施例によるターゲットＬＵの属性を変更するためのプロセスを示す。ステップ５００で、アプリケーションはストレージＡＰＩのunset_volume_guardを呼び出す。識別されるボリュームは、その属性が変更されるべきターゲットＬＵである。ストレージＡＰＩは、ロッカーモジュール３９に要求を送付してターゲットＬＵをアンロックし、ターゲットＬＵをＲＥＡＤ ＯＮＬＹからＲＥＡＤ−ＷＲＩＴＥに転換する（ステップ５０１）。

ロッカーモジュールは適切な通信路を経由して要求を受信する（ステップ５０２）。コントローラは、ターゲットのＬＵがＶＳＳの中に配置されているボリュームか又は関連サブシステムに配置されている仮想的ＬＵかどうかを内部のマップテーブル６０を調べてチェックする（ステップ５０３）。もしもＬＵがＶＳＳの中であると、ロッカーモジュールはターゲットのＬＵの属性をＲＥＡＤ−ＷＲＩＴＥに変更し（ステップ５０４）、ステップ５０９に進む。すなわち、ＬＵはアンロックされる。本実施例では、ＬＵの属性は、保存期間が有効である間は変更又はアンロックされない。

ステップ５０３に戻って、ターゲットＬＵが関連サブシステム３０に配置されていると、コントローラはストレージＡＰＩからの要求を関連サブシステム３０のロッカーモジュール４９に転送する（ステップ５０５）。ロッカーモジュール４９は適切な通信路を経由して要求を受信する（ステップ５０６）。ロッカーはターゲットＬＵをアンロックする（ステップ５０７）。ロックテーブル８０の許可フィールド８２はＲＥＡＤ ＯＮＬＹからＲＥＡＤ−ＷＲＩＴＥに変更される。ロッカーモジュール４９はこの動作をＶＳＳのロッカーモジュール３９に報告し（ステップ５０８）、ロッカーモジュール３９は次にこれをストレージＡＰＩに報告する（ステップ５０９）。ストレージＡＰＩはアプリケーションに通知する（ステップ５１０）。

図９は本発明の一つの実施例によるターゲットのＬＵをアンロックするためのプロセスを示す。上記のステップ５０４と５０７は次のことを実行する。ステップ６００で、ロッカーモジュール３９と４９は、ターゲットのＬＵが属性を割り当てられたか、例えばロックされたかどうかを判定する。もしもターゲットのＬＵがロックされていなければ、エラーメッセージがストレージＡＰＩに返される。これはＬＵがすでにＲＥＡＤ−ＷＲＩＴＥモードであるからである（ステップ６０１）。

もしもＬＵがロックされていると、ロッカーモジュールは、ロックテーブルの保存フィールドをアクセスして保存期間が終了しているかどうかを判定する（ステップ６１０）。保存期間が終了していない場合は、エラーメッセージがストレージＡＰＩに返される。これはターゲットのＬＵは本実施例では保存期間が終了するまでアンロックされることはできないからである（ステップ６０１）。保存期間が終了している場合は、ロッカーモジュールはターゲットのＬＵをアンロックすることを許可される（ステップ６２０）。

本発明は特定の実施例について記述してきた。これらの実施例は説明の目的で提供されており、本発明の範囲から逸脱することなく修正や変更を行なうことができる。本発明の範囲は添付の特許の請求範囲で定義される。

図１は本発明の一つの実施例による仮想化されたストレージサブシステムを有するストレージシステムを示す図である。 図２は本発明の一つの実施例によるストレージシステムの論理的構成とソフトウェアを示す。 図３Ａは本発明の一つの実施例によるポートマップテーブルを示す。 図３Ｂは本発明の一つの実施例による内部マップテーブルを示す。 図３Ｃは本発明の一つの実施例によるロックテーブルを示す。 図４Ａは本発明の一つの実施例によるポートフィールド、ＷＷＮフィールド及びＬＵＮフィールドを含むポートマップテーブル１７０を示す。 図４Ｂは本発明の一つの実施例によるＩ−ＬＵフィールド、許可フィールド及び保存フィールドを含むロックテーブル１８０を示す。 図４Ｃは本発明の一つの実施例による関連サブシステム内で使用されるＩＤ情報を示すＬＵＮフィールド及びホストで使用されるＩＤ情報を示すＩ−ＬＵフィールドを含む内部マップテーブルを示す。 図５は本発明の一つの実施例による新しい外部ＬＵを発見するためにＶＳＳによって実行されるプロセスを示す。 図６は本発明の一つの実施例によるＬＵ又はボリュームの属性を管理するためのプロセスを示す。 図７は本発明の一つの実施例によるＬＵの保存情報を管理するためのプロセスを示す。 図８は本発明の一つの実施例によるターゲットのＬＵの属性を変更するためのプロセスを示す。 図９は本発明の一つの実施例によるターゲットのＬＵをアンロックするためのプロセスを示す。

符号の説明

１０ ホスト
１１ ＣＰＵ
１２ メモリー
１３ ディスク
１４ ＨＢＡ
２０ 仮想化されたストレージ
２１ コントローラ
２２ ディスク
２３ ＦＣ
２４ ＦＣ
２５ ＦＣ
３０ ストレージサブシステム
３１ コントローラ
３２ ディスク
３３ ＦＣ
３４ ＦＣ
７０ ＳＡＮ
７１ ＳＡＮ
９１ ＬＡＮ
９２ コンソール

Claims (17)

1. 複数のポートを有するコントローラと、
   情報を記憶するように構成された複数のストレージ装置と、
   ストレージサブシステムの第一のストレージ装置にマッピングされた仮想的でないボリュームと、コミュニケーションリンクを経由して前記ストレージサブシステムにリンクされた関連ストレージサブシステムの第二のストレージ装置にマッピングされた仮想的ボリュームを含み、ホスト装置に提供される複数のストレージボリュームのそれぞれに対して属性情報と保存情報を含むロックテーブルとを有し、
   前記コントローラがホストからの要求を受信し処理して前記仮想的ボリュームの属性を変更するように構成されていることを特徴とするストレージサブシステム。
2. 前記ロックテーブルが許可フィールドと保存フィールドを含むことを特徴とする請求項１に記載のストレージサブシステム。
3. 前記コントローラが、前記関連サブシステムに配置される前記仮想的ボリュームを変更するために前記ホストからの要求を処理するロッカーモジュールを含むことを特徴とする請求項１に記載のストレージサブシステム。
4. 前記ロッカーモジュールが、前記仮想的なボリュームの属性を変更するための要求を前記関連サブシステムのロッカーモジュールに送付することを特徴とする請求項３に記載のストレージサブシステム。
5. 第一のストレージサブシステム内のストレージ領域にマッピングされた仮想的でないボリュームと、前記第一のサブシステムとは異なる第二のストレージサブシステム内のストレージ領域にマッピングされた仮想的ボリュームを含む複数のストレージボリュームを前記第一のストレージサブシステムを経由してホストに提供するステップと、
   ホストに提供される前記複数のストレージボリュームの一つであるターゲットストレージボリュームの属性を変更するために、前記ホストからの第一の要求を前記第一のサブシステムにおいて受信するステップと、
   もしも前記ターゲットボリュームが前記仮想的ボリュームであると決定されると、前記ターゲットボリュームの属性を変更する要求である第二の要求を前記第一のサブシステムから前記第二のサブシステムへ送付するステップと、
   を有することを特徴とするストレージシステムを管理する方法。
6. 前記第二の要求に従って、前記第二のサブシステムのコントローラによって前記ターゲットボリュームの属性を変更するステップを更に有することを特徴とする請求項５に記載の方法。
7. 前記属性変更の第一の報告を前記第二のサブシステムから前記第一のサブシステムへ送付するステップと、
   前記属性変更の第二の報告を前記第一のサブシステムから前記ホストへ送付するステップと
   を更に有することを特徴とする請求項６に記載の方法。
8. もしも前記ターゲットボリュームが仮想的でないボリュームであると、前記第一のサブシステムのコントローラによって前記ターゲットボリュームの属性を変更するステップを更に有することを特徴とする請求項５に記載の方法。
9. 前記第一のサブシステムが前記ホストからの前記第一の要求を処理する第一のロッカーモジュールを含み、前記第二のサブシステムが前記第一のサブシステムからの前記第二の要求を処理する第二のロッカーモジュールを含むことを特徴とする請求項８に記載の方法。
10. 前記第一の要求が前記ターゲットボリュームへの読み取りアクセスだけを認めるように前記ターゲットボリュームをロックする要求であることを特徴とする請求項５に記載の方法。
11. 前記第二の要求が前記ターゲットボリュームへの読み取りアクセスだけを認めるように前記ターゲットボリュームをロックする要求であることを特徴とする請求項１０に記載の方法。
12. 前記ターゲットボリュームの前記属性が変更されると、前記ターゲットボリュームに関連したロックテーブルが更新されることを特徴とする請求項１０に記載の方法。
13. 前記ロックテーブルが属性フィールドと保存フィールドを含むことを特徴とする請求項１２に記載の方法。
14. もしも前記ターゲットボリュームに対する保存フィールドに関連した保存期間が終了していないと、前記ターゲットボリュームの属性は変更されることができないことを特徴とする請求項１３に記載の方法。
15. 前記第一と第二のサブシステムがディスクアレイユニットであることを特徴とする請求項５に記載の方法。
16. 第一のストレージサブシステム内のストレージ領域にマッピングされた仮想的でないボリュームと、前記第一のサブシステムとは異なる第二のストレージサブシステム内のストレージ領域にマッピングされた仮想的ボリュームを含む複数のストレージボリュームを、前記第一のストレージサブシステムを経由してホストに提供するプログラムコードと、
    ホストに提供される前記複数のストレージボリュームの一つであるターゲットストレージボリュームの属性を変更するために、前記ホストからの第一の要求を前記第一のサブシステムにおいて受信するプログラムコードと、
    もしも前記ターゲットボリュームが前記仮想的ボリュームであると決定されると、前記ターゲットボリュームの属性を変更する要求である第二の要求を前記第一のサブシステムから前記第二のサブシステムへ送付するプログラムコードと、
    を有することを特徴とするコンピュータプログラムを、ストレージサブシステムを管理するために備えるコンピュータが読み取り可能な媒体。
17. 前記コンピュータが読み取り可能な媒体がストレージサブシステムに備えられることを特徴とする請求項１６に記載のコンピュータプログラム。
    

Images