特許 6202026 データ管理装置、データ管理方法およびデータ管理プログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6202026

(24)【登録日】2017年9月8日

(45)【発行日】2017年9月27日

(54)【発明の名称】データ管理装置、データ管理方法およびデータ管理プログラム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20170914BHJP

【ＦＩ】

   G06F12/00 514E

   G06F12/00 531M

   G06F12/00 517

【請求項の数】10

【全頁数】25

(21)【出願番号】特願2015-55670(P2015-55670)

(22)【出願日】2015年3月19日

(65)【公開番号】特開2016-177407(P2016-177407A)

(43)【公開日】2016年10月6日

【審査請求日】2016年7月15日

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100124154

【弁理士】

【氏名又は名称】下坂 直樹

(72)【発明者】

【氏名】上浦 朋花

【審査官】 桜井 茂行

(56)【参考文献】

【文献】 特開２０１３−２１０７０４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１３／０２６２８０４（ＵＳ，Ａ１）

【文献】 特開２００９−１４６２２８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０１５７９９０（ＵＳ，Ａ１）

【文献】 特開２０１０−０２６９３９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１０／００２３７１６（ＵＳ，Ａ１）

【文献】 米国特許第０７５１６２８６（ＵＳ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

元データの更新に伴って、当該元データを複製データ記憶領域に格納するデータ管理装置において、
前記元データの更新に伴って連続した世代として保持される第１の階層の前記複製データ記憶領域に、前記元データを差分データとして格納すると共に、当該第１の階層における、自世代および上位世代の前記複製データ記憶領域の少なくともいずれかに前記差分データがあるか無いかをデータごとに示すデータ有無情報を前記複製データ記憶領域に関連付けて生成する更新手段と、
前記複製データ記憶領域へのアクセスに応じて、前記データ有無情報に基づいてアクセスを行うアクセス手段と
を備えたデータ管理装置。

【請求項2】

前記更新手段は、前記データ有無情報が関連付けられた前記複製データ記憶領域に格納される前記差分データの更新に伴って連続した世代として保持される第２以降の階層の前記複製データ記憶領域に、前記差分データを格納し、
前記アクセス手段は、所定の階層の前記複製データ記憶領域に関連付けられた前記データ有無情報に基づいて、当該階層の前記複製データ記憶領域に前記アクセスの対象となるデータがないと判定した場合、当該階層よりも上位の階層の前記複製データ記憶領域に関連付けられた前記データ有無情報に基づいてアクセスを行う
請求項１記載のデータ管理装置。

【請求項3】

前記アクセス手段は、所定の階層の前記複製データ記憶領域に関連付けられた前記データ有無情報に基づいて、当該階層の前記複製データ記憶領域に前記アクセスの対象となるデータがあると判定した場合、当該階層のいずれかの前記複製データ記憶領域に保持される前記データにアクセスする
請求項２記載のデータ管理装置。

【請求項4】

前記アクセス手段は、前記データ有無情報に基づいて、すべての階層の前記複製データ記憶領域に前記アクセスの対象となるデータがないと判定した場合、前記元データにアクセスを行う
請求項２または請求項３記載のデータ管理装置。

【請求項5】

前記更新手段は、自世代および上位世代の少なくともいずれかの前記複製データ記憶領域に前記差分データがある場合、当該差分データがあるアドレスに対応する前記データ有無情報のフラグをセットする
請求項１ないし４のいずれか１項記載のデータ管理装置。

【請求項6】

元データの更新に伴って、当該元データを複製データ記憶領域に格納するデータ管理方法において、
前記元データの更新に伴って連続した世代として保持される第１の階層の前記複製データ記憶領域に、前記元データを差分データとして格納すると共に、当該第１の階層における、自世代および上位世代の前記複製データ記憶領域の少なくともいずれかに前記差分データがあるか無いかをデータごとに示すデータ有無情報を前記複製データ記憶領域に関連付けて生成し、
前記複製データ記憶領域へのアクセスに応じて、前記データ有無情報に基づいてアクセスを行う
データ管理方法。

【請求項7】

前記元データを差分データとして格納するに際し、前記データ有無情報が関連付けられた前記複製データ記憶領域に格納される前記差分データの更新に伴って連続した世代として保持される第２以降の階層の前記複製データ記憶領域に、前記差分データを格納し、
前記アクセスを行うに際し、所定の階層の前記複製データ記憶領域に関連付けられた前記データ有無情報に基づいて、当該階層の前記複製データ記憶領域に前記アクセスの対象となるデータがないと判定した場合、当該階層よりも上位の階層の前記複製データ記憶領域に関連付けられた前記データ有無情報に基づいてアクセスを行う
請求項６記載のデータ管理方法。

【請求項8】

前記アクセスを行うに際し、所定の階層の前記複製データ記憶領域に関連付けられた前記データ有無情報に基づいて、当該階層の前記複製データ記憶領域に前記アクセスの対象となるデータがあると判定した場合、当該階層のいずれかの前記複製データ記憶領域に保持される前記データにアクセスする
請求項７記載のデータ管理方法。

【請求項9】

前記アクセスを行うに際し、前記データ有無情報に基づいて、すべての階層の前記複製データ記憶領域に前記アクセスの対象となるデータがないと判定した場合、前記元データにアクセスを行う
請求項７または請求項８記載のデータ管理方法。

【請求項10】

元データの更新に伴って、当該元データを複製データ記憶領域に格納するデータ管理装置に、
前記元データの更新に伴って連続した世代として保持される第１の階層の前記複製データ記憶領域に、前記元データを差分データとして格納すると共に、当該第１の階層における、自世代および上位世代の前記複製データ記憶領域の少なくともいずれかに前記差分データがあるか無いかをデータごとに示すデータ有無情報を前記複製データ記憶領域に関連付けて生成する処理と、
前記複製データ記憶領域へのアクセスに応じて、前記データ有無情報に基づいてアクセスを行う処理と
を実行させるデータ管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、スナップショット技術を利用した仮想マシンにおけるデータアクセスに関する。

【背景技術】

【0002】

近年、コスト削減や運用管理の容易化の観点から、仮想マシンを作成する仮想化技術が普及している。仮想化技術では、例えばＶＭＷａｒｅ（登録商標）社のＬｉｎｋｅｄ Ｃｌｏｎｅ技術を用いた製品がリリースされている。Ｌｉｎｋｅｄ Ｃｌｏｎｅ技術は、例えば、特許文献１に開示されるように、共有するマシンのディスクイメージ（マシンイメージ）のスナップショットをとり、共有するマシンイメージとの差分データのみを管理することにより、ディスク容量を削減する技術である。

【0003】

また、例えば特許文献２に開示されるように、マスタとなる仮想マシンのボリューム（マスタボリューム）の複製を世代管理する技術としても、スナップショット技術が知られている。この場合も、スナップショット作成時点からのマスタボリュームに更新があったアドレスのみスナップショットボリュームに更新前データを保持するので、ディスク容量を削減することができる。

【0004】

ここで、スナップショットとは、指定された時点における所定のボリュームの状態を保持するための技術またはその状態をキャプチャした結果である。以降、元データを記憶するボリュームを「マスタボリューム」と称し、元データを記憶するボリュームの更新前データを保持するために定義された複製データ記憶領域となるボリュームを「スナップショットボリューム」と称する。

【0005】

図１７を参照して、スナップショット技術の一例について説明する。図１７（ａ）に示すようなデータを記憶したマスタボリュームのスナップショットをとる場合、まず、このマスタボリュームと同等の記憶容量を有するスナップショットボリュームが図１７（ａ）に示すように記憶装置内に生成される。

【0006】

そして、マスタボリュームにおけるデータ”ＢＢ”の記憶領域（アドレス）にデータ”ＥＥ”の書き込みを行おうした段階で、更新前のデータ”ＢＢ”が図１７（ｂ）に示すようにスナップショットボリュームの同一アドレスに格納される。このスナップショットボリュームは、第１世代のスナップショットとして機能する。

【0007】

続いて、改めてマスタボリュームのスナップショットをとる場合、このマスタボリュームと同等の記憶容量を有するスナップショットボリュームが図１７（ｂ）に示すよう新たに記憶装置内に生成される。このスナップショットボリュームは、第２世代のスナップショットとなる。

【0008】

続いて、更にマスタボリュームにおけるデータ”ＣＣ”の記憶領域にデータ”ＦＦ”の書き込みを行おうとすると、更新前のデータ”ＣＣ”が図１７（ｃ）に示すように第２世代のスナップショットとして機能するスナップショットボリュームの同一アドレスに格納される。このとき、第１世代のスナップショットとして機能するスナップショットボリュームの内容は、図１７（ｂ）および図１７（ｃ）に示すように保持されたままである。

【0009】

なお、「（ＡＡ）」、「（ＢＢ）」等は、そのボリュームにはデータが存在しないが、上位世代またはマスタの該当するページからデータＡ１、Ｂ１が読み出せることを意味する。

【0010】

上記のようなスナップショット技術を用いてデータの複製を管理するディスクアレイサブシステムでは、マスタボリュームへの更新があったアドレスのデータのみスナップショットボリュームに保持される。スナップショットボリュームは、自ボリュームがデータを保持するか否かを、アドレス毎に管理する保持データ管理テーブルを有している。したがって、ディスクアレイサブシステムのデータアクセス手段は、スナップショットボリュームへのリード命令を受けた場合、対象となるデータのアドレスに対応する保持データ管理テーブルの情報を調べる。その結果、データがあると判断された場合は、データアクセス手段は、スナップショットボリュームからそのデータを読み出す。一方、データがないと判断された場合は、データアクセス手段は、マスタボリュームからそのデータを読み出す。

【0011】

仮想マシンを複数ユーザに提供する際、マシンイメージのバージョン管理を、上記のようなスナップショット技術を用いて実施することが可能である。また、１つのバージョンについて更にスナップショット技術によりサブバージョン管理をすることも可能である。更に、Ｌｉｎｋｅ Ｃｌｏｎｅ技術によってサブバージョンのスナップショットを複数作成し、ユーザに提供することも可能である。

【0012】

このように、Ｌｉｎｋｅｄ Ｃｌｏｎｅ技術を含むスナップショット技術を階層的に用いることにより、少ないディスク容量で複数のユーザそれぞれに適したマシンイメージを提供することができると共に、運用管理も容易となる。

【0013】

上述のようなスナップショット技術を用いたＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）イメージのバージョン管理、およびＯＳイメージをユーザに提供する方法の例について説明する。

【0014】

ＯＳが更新される際、更新前のＯＳイメージのボリュームのスナップショットを作成する。ここで、バージョンアップやパッチなどで更新される前のＯＳイメージのボリュームを、「共通ＯＳイメージボリューム」と称する。

【0015】

共通ＯＳイメージボリュームをマスタとしたスナップショットボリューム（以降、「各バージョンＯＳボリューム」と称する）は、図１７（ｂ）に示したように、上位世代の各バージョンＯＳボリュームまたは共通ＯＳイメージボリュームとの差分のみを保持している。なお、共通ＯＳイメージボリュームは、上述の「マスタボリューム」に相当し、共通ＯＳイメージボリュームをマスタとして作成された各バージョンＯＳボリュームは、上述の「スナップショットボリューム」に相当する。

【0016】

ユーザには、各バージョンＯＳボリュームをマスタとしたスナップショット（以降、「ユーザボリューム」と称する）が提供される。ユーザボリュームは、作成された時点ではマスタである各バージョンＯＳボリュームと同じイメージを有し、その後各バージョンＯＳボリュームが更新されたアドレスのデータのみを保持する。

【0017】

ここで、特許文献１は、例えば、ディスクアレイサブシステムにおけるスナップショット動作において、更新データのみを保持するデータ格納システムを開示する。

【0018】

また、特許文献２は、シンプルな処理により既存の仮想マシンのディスクイメージの重複排除を実現できるストレージ管理システムを開示する。

【先行技術文献】

【特許文献】

【0019】

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

【特許文献2】特開２００５−２０８９５０号公報

【発明の概要】

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

【0020】

上述のようなスナップショット技術によりユーザボリュームを管理するディスクアレイサブシステムにおいて、ユーザボリュームへのアクセスは、以下の手順で行われる。上述のように、ユーザボリュームは、マスタとなる各バージョンＯＳボリュームに更新がない場合はデータを保持しない。したがって、この場合、ディスクアレイサブシステムのデータアクセス手段は、ユーザボリュームへのアクセスに際して、マスタである各バージョンＯＳボリュームにデータが存在するか否かを調べる。

【0021】

マスタボリュームにデータが存在しない場合、データアクセス手段は、スナップショットのさらなる上位世代である各バージョンＯＳボリュームにデータが存在するか否かを調べる。

【0022】

このように、スナップショットによるボリューム管理では、ユーザボリューム（下位階層の複製データ記憶領域）へのアクセスに対して、データが存在するボリュームまで世代を辿って調べる必要がある。したがって、ＯＳのバージョンが複数存在する場合は、ユーザボリュームへのアクセス時間が遅延してしまうという課題がある。

【0023】

特許文献１および特許文献２には、このようなユーザボリュームへのアクセス時間の遅延を防ぐ技術は開示されていない。

【0024】

本願発明は、上記課題を鑑みてなされたものであり、下位階層の複製データ記憶領域へのアクセス時間を短縮することができるデータ管理装置等を提供することを主要な目的とする。

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

【0025】

本発明の第１のデータ管理装置は、元データの更新に伴って、当該元データを複製データ記憶領域に格納するデータ管理装置において、前記元データの更新に伴って連続した世代として保持される第１の階層の前記複製データ記憶領域に、前記元データを差分データとして格納すると共に、自世代および上位世代の前記複製データ記憶領域におけるデータ有無状況を示す差分管理テーブルを前記複製データ記憶領域に関連付けて生成する更新手段と、前記複製データ記憶領域へのアクセスに応じて、前記差分管理テーブルに示されるデータ有無状況に基づいてアクセスを行うアクセス手段とを備える。

【0026】

本発明の第１のデータ管理方法は、元データの更新に伴って、当該元データを複製データ記憶領域に格納するデータ管理方法において、前記元データの更新に伴って連続した世代として保持される第１の階層の前記複製データ記憶領域に、前記元データを差分データとして格納すると共に、自世代および上位世代の前記複製データ記憶領域におけるデータ有無状況を示す差分管理テーブルを前記複製データ記憶領域に関連付けて生成し、前記複製データ記憶領域へのアクセスに応じて、前記差分管理テーブルに示されるデータ有無状況に基づいてアクセスを行う。

【0027】

なお同目的は、上記の各構成を有するデータ管理方法を、コンピュータによって実現するコンピュータ・プログラム、およびそのコンピュータ・プログラムが格納されている、コンピュータ読み取り可能な記憶媒体によっても達成される。

【発明の効果】

【0028】

本願発明によれば、データ格納装置において、ユーザボリュームへのアクセス時間を短縮することができるという効果が得られる。

【図面の簡単な説明】

【0029】

【図1】本発明の第１の実施形態に係るディスクアレイサブシステムの構成を示すブロック図である。

【図2】本発明の第１の実施形態に係るディスクアレイサブシステムのボリューム対応テーブルの例を示す図である。

【図3】本発明の第１の実施形態に係るディスクアレイサブシステムの保持データ管理テーブルの例を示す図である。

【図4】本発明の第１の実施形態に係るディスクアレイサブシステムの上位世代差分管理テーブルの例を示す図である。

【図5】本発明の第１の実施形態に係るディスクアレイサブシステムのボリューム更新許否テーブルの例を示す図である。

【図6】本発明の第１の実施形態に係るディスクアレイサブシステムのボリューム構成の例を示す図である。

【図7】本発明の第１の実施形態に係るディスクアレイサブシステムのユーザボリュームへの通常のリード処理について説明する図である。

【図8】本発明の第１の実施形態に係るディスクアレイサブシステムの共通ＯＳイメージボリュームを増加したボリューム構成におけるユーザボリュームへのリード処理について説明する図である。

【図9】本発明の第１の実施形態に係るディスクアレイサブシステムのボリューム管理部の動作を示すフローチャートである。

【図10】本発明の第１の実施形態に係るディスクアレイサブシステムの上位世代差分管理テーブルの更新について説明する図である。

【図11】本発明の第１の実施形態に係るディスクアレイサブシステムのライト処理の流れを示すフローチャートである。

【図12】本発明の第１の実施形態に係るディスクアレイサブシステムのリード処理の流れを示すフローチャートである。

【図13】本発明の第１の実施形態に係るディスクアレイサブシステムのリード処理について説明する図である。

【図14】本発明の第２の実施形態に係るディスクアレイサブシステムのリード処理について説明する図である。

【図15】本発明の第３の実施形態に係るデータ管理装置の構成を示すブロック図である。

【図16】本発明の各実施形態に係る装置を実現するハードウエア構成の一例を示す図である。

【図17】スナップショット技術の一例を説明する図である。

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

【0030】

以下、本発明の実施形態について図面を参照して詳細に説明する。

【0031】

第１の実施形態
図１は、本発明の第１の実施形態に係るディスクアレイサブシステム１００の構成を示すブロック図である。図１に示すように、ディスクアレイサブシステム１００は、１または複数のホスト２００−１乃至２００−ｎと接続される。

【0032】

ホスト２００は、データ管理を行うボリューム群を備えたディスクアレイサブシステム１００に対して、ボリュームへの書き込み、ボリュームからの読み出し、スナップショットの作成、ＯＳの更新、ＯＳの更新抑止、ＯＳの更新許可等の命令（コマンド）を送る。以降、１または複数のホスト２００−１乃至２００−ｎを総称して「ホスト２００」と称する。

【0033】

図１に示すように、ディスクアレイサブシステム１００は、ボリューム管理部１１０、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）処理部１３０、ボリューム群１５０およびテーブル記憶部１７０を備える。

【0034】

ボリューム管理部１１０は、ホスト２００からのボリューム管理コマンドに応じて、ボリューム群１５０に含まれるボリュームを管理する処理を実行すると共に、処理が完了すると、ホスト２００にレスポンスを返却する。ボリューム管理部１１０は、ボリューム管理コマンド取得部１１１、スナップショット実行部１１２、ＯＳ更新抑止部１１３およびＯＳ更新許可部１１４を備える。

【0035】

Ｉ／Ｏ処理部１３０は、ホスト２００からのＩ／Ｏコマンドに応じて、ボリューム群１５０に含まれるボリュームにリード処理またはライト処理を実行し、処理が完了すると、ホスト２００にレスポンスを返却する。Ｉ／Ｏ処理部１３０は、Ｉ／Ｏコマンド取得部１３１、ライト命令実行部１３２およびリード命令実行部１３３を備える。

【0036】

ボリューム群１５０は、複数のボリュームを含む。具体的には、ボリューム群１５０は、共通ＯＳイメージボリューム１５１、各バージョンＯＳボリューム１５２、ユーザボリューム１５３およびプールボリューム１５４を備える。

【0037】

テーブル記憶部１７０は、ボリューム群１５０に含まれるボリュームを管理するテーブルを含む。具体的には、テーブル記憶部１７０は、ボリューム対応テーブル１７１、ボリューム更新許否テーブル１７２、保持データ管理テーブル１７３および上位世代差分管理テーブル（差分管理テーブル）１７４を備える。

【0038】

ディスクアレイサブシステム１００の各構成要素の概要を説明する。

【0039】

ボリューム管理部１１０のボリューム管理コマンド取得部１１１は、ホスト２００からボリューム管理コマンドを受けとり、そのコマンドに応じてスナップショット実行部１１２、ＯＳ更新抑止部１１３またはＯＳ更新許可部１１４にコマンドを渡す。

【0040】

スナップショット実行部１１２は、ボリューム管理コマンド取得部１１１からのスナップショット作成コマンドを受けとると、該コマンドにて指定されるマスタボリュームからスナップショットを作成する。そして、スナップショット実行部１１２は、作成したスナップショットに関してテーブル記憶部１７０に含まれるテーブルに情報を追加する。

【0041】

ＯＳ更新抑止部１１３は、ボリューム管理コマンド取得部１１１からのＯＳ更新抑止コマンドに応じて、ボリューム更新許否テーブル１７２にフラグをセットする。また、ＯＳ更新抑止部１１３は、ＯＳ更新抑止コマンドに応じて、上位世代差分管理テーブル１７４に情報を追加する。

【0042】

ＯＳ更新許可部１１４は、ボリューム管理コマンド取得部１１１からのＯＳ更新許可コマンドに応じて、ボリューム更新許否テーブル１７２のフラグをクリアする。また、ＯＳ更新許可部１１４は、ＯＳ更新許可コマンドに応じて、上位世代差分管理テーブル１７４のフラグをクリアする。

【0043】

図２は、スナップショット実行部１１２により情報を追加されるボリューム対応テーブル１７１の例を示す図である。ボリューム対応テーブル１７１は、スナップショットが作成されたマスタボリュームとスナップショットボリュームの対応関係を含むテーブルである。図２に示すボリューム対応テーブル１７１は、詳細を後述する図６に示すボリューム構成に対応する。図２に示すように、ボリューム対応テーブル１７１は、マスタボリューム番号と、スナップショットのボリューム番号を含む。図２では、例えば、「MV_OS1」はマスタボリュームの番号であり、このマスタボリュームのスナップショットボリュームとして「SV_OSVer3」、「SV_OSVer2」「SV_OSVer1」がそれぞれ第３世代、第２世代、第１世代として作成されたことを示す。このように、スナップショットは、マスタボリューム（元データ）の更新に伴って連続した世代として保持される。

【0044】

スナップショット実行部１１２は、また、スナップショットが作成されると、保持データ管理テーブル１７３に情報を追加する。図３は、保持データ管理テーブル１７３の例を示す図である。図３に示すように、保持データ管理テーブル１７３は、スナップショットボリュームに、マスタボリュームに記憶しているデータと対応するデータが存在するか否かを管理するテーブルである。

【0045】

保持データ管理テーブル１７３は、当該対応するデータが存在するか否かを、データの複製処理を行う単位であるスナップショットＩ／Ｏ処理単位（以下、ページ単位と称する。）毎にフラグで管理する。例えば、フラグが「１」のときは対応するデータが存在することを示し、フラグが「０」のときは対応するデータが存在しないことを示す。図３では、例えば、スナップショットボリューム「SV_OSVer1」の「page0」にはフラグが「１」に設定されるので、スナップショットボリューム「SV_OSVer1」の「page0」にはデータが存在すること示す。

【0046】

ここで、スナップショット実行部１１２は、マスタボリュームへの書き込みがあると、そのページ単位でマスタボリュームの書き込み前のデータをスナップショットボリュームに複製する（以下、この動作を追い出しコピーと称する）。

【0047】

スナップショット実行部１１２は、また、作成したスナップショットボリュームのマスタボリュームが、各バージョンＯＳボリュームである場合、上位世代差分管理テーブル１７４に情報を追加する。

【0048】

図４は、上位世代差分管理テーブル１７４の一例を示す図である。図４に示すように、上位世代差分管理テーブル１７４は、各バージョンＯＳボリュームに関連付けられたテーブルであり、自ボリューム（自世代）またはスナップショット上位世代の各バージョンＯＳボリュームのいずれかにデータが存在するか否か（データ有無状況）を、ページ単位毎にフラグで管理する。図４では、例えば、ボリューム「SV_OSVer1」の「page0」はフラグが「１」に設定されているので、「SV_OSVer1」または上位世代の「SV_OSVer2」、「SV_OSVer3」いずれかにデータが存在することを示す。ここで、上位世代とは、自ボリュームの後に作成されたスナップショットボリュームを指し、例えば、マスタボリュームから第１世代、第２世代および第３世代のスナップショットボリュームが作成されている場合、第１世代の上位世代は、第２世代および第３世代のスナップショットボリュームを指す。

【0049】

図５は、ＯＳ更新抑止部１１３により管理されるボリューム更新許否テーブル１７２の例を示す図である。図５に示すように、ボリューム更新許否テーブル１７２は、ボリュームへのライト処理を禁止するか否かを示すフラグを含む。図５では、ボリューム「MV_OS2」のフラグが「１」に設定されているので、ボリューム「MV_OS2」へのライト処理は禁止されることを示す。なお、本実施形態における運用形態では、ボリューム更新許否テーブル１７２には、共通ＯＳイメージボリュームに関するフラグのみ設定されるが、別の運用形態では、各バージョンＯＳボリューム等に関するフラグが設定されてもよい。

【0050】

次に、ボリューム群１５０について説明する。ボリューム群１５０における共通ＯＳイメージボリューム１５１は、共通のＯＳイメージを保持するボリュームであり、各バージョンＯＳボリューム１５２のスナップショットマスタボリュームである。

【0051】

各バージョンＯＳボリューム１５２は、共通ＯＳイメージボリューム１５１をマスタとするスナップショットボリュームであり、共通ＯＳイメージボリューム１５１の所定時点のイメージについて、マスタボリュームとの差分データのみを保持する。各バージョンＯＳボリューム１５２の実データはプールボリューム１５４に保存され、アドレス毎のデータ有無を、保持データ管理テーブル１７３により管理される。

【0052】

ユーザボリューム１５３は、ユーザが使用するボリュームであり、各バージョンＯＳボリューム１５２をマスタとするスナップショットボリュームである。ユーザボリューム１５３は、作成直後はマスタである各バージョンＯＳボリュームと同じイメージを持ち、ユーザが更新したデータのみを保持する。ユーザボリュームの実データはプールボリューム１５４に保存され、アドレス毎のデータ有無を保持データ管理テーブル１７３により管理される。

【0053】

プールボリューム１５４は、スナップショットボリュームである各バージョンＯＳボリュームとユーザボリュームの実データを保持する。

【0054】

図６は、共通ＯＳイメージボリューム「MV_OS1」をマスタとして各バージョンＯＳボリューム「SV_OSVer1」、「SV_OSVer2」、「SV_OSVer3」が順に作成された構成を示す。また、各バージョンＯＳボリューム「SV_OSVer1」をマスタとしてユーザボリューム「SV_USR1」、「SV_USR2」が、各バージョンＯＳボリューム「SV_OSVer2」をマスタとしてユーザボリューム「SV_USR3」が、各バージョンＯＳボリューム「SV_OSVer3」をマスタとしてユーザボリューム「SV_USR4」が、それぞれ作成された構成を示す。ここで、各バージョンＯＳボリューム「SV_OSVer1」、「SV_OSVer2」、「SV_OSVer3」を、それぞれ第１世代各バージョンＯＳボリューム、第２世代各バージョンＯＳボリューム、第３世代各バージョンＯＳボリュームと称する。

【0055】

図６において、「Ａ１」、「Ｂ１」等はデータを示し、「１７３」、「１７４」は、それぞれ保持データ管理テーブル１７３、上位世代差分管理テーブル１７４における、各データを格納するページ（アドレス）に対応するフラグを示す。また、「（Ａ１）」、「（Ｂ１）」等は、そのボリュームにはデータが存在しないが、上位世代またはマスタの該当するページからデータＡ１、Ｂ１が読み出せることを意味する。

【0056】

例えば、データＢ０について説明する。スナップショット実行部１１２がスナップショット「SV_OSVer2」を作成した時点では、「SV_OSVer2」のＢ０に対応するアドレスには（Ｂ０）が示される。その後、共通ＯＳイメージボリュームへの更新がありＢ０に対応するアドレスにＢ１が書き込まれると、スナップショット実行部１１２は追い出しコピーを行い、「SV_OSVer2」のＢ０に対応するアドレスのデータを（Ｂ０）からＢ０に変更する。このとき、スナップショット実行部１１２は、保持データ管理テーブル１７３の該当ページのフラグに「１」をセットする。続いて、スナップショット実行部１１２は新たにスナップショット「SV_OSVer3」を作成すると、「SV_OSVer3」のＢ０に対応するアドレスは、共通ＯＳイメージボリュームの値（Ｂ１）となる。

【0057】

このように、各バージョンＯＳボリュームは、上位世代の更新前のデータを保持すると共に、自ボリュームにデータが存在することを示すフラグを有する保持データ管理テーブル１７３が関連付けられる。また、各バージョンＯＳボリュームは、自ボリュームまたは上位世代のボリュームのいずれかにデータが存在することを示すフラグを有する上位世代差分管理テーブル１７４が関連付けられる。

【0058】

ユーザボリュームは、ユーザに更新されたデータを保持すると共に、自ボリュームにデータが存在することを示すフラグを有する保持データ管理テーブル１７３が関連付けられる。

【0059】

ここで、図７を参照して、ユーザボリュームに対する通常のリード処理について説明する。通常のリード処理を実行する部を、通常リード処理部（不図示）と称する。通常のリード処理において、各バージョンＯＳボリュームは、上位世代差分管理テーブル１７４を持たず、保持データ管理テーブル１７３のみを持つと仮定する。

【0060】

図７に示す構成では、共通ＯＳイメージボリュームをマスタとして各バージョンＯＳボリュームのスナップショットが作成され、さらに各バージョンＯＳボリュームは第１世代から第３世代まで作成されている。また、第１世代の各バージョンＯＳボリュームをマスタとしてユーザボリューム２が、第２世代の各バージョンＯＳボリュームをマスタとしてユーザボリューム１が、それぞれ作成されている。

【0061】

ユーザボリューム２のＤ０に対してリード命令（リードａ）がなされたと仮定する。この場合、通常リード処理部は、ユーザボリューム２の保持データ管理テーブル１７３を調べる。図７では、Ｄ０に該当するページの保持データ管理テーブル１７３のフラグが「０」であるので、ユーザボリューム２にはデータは存在しない。

【0062】

そこで、通常リード処理部は、スナップショットペアのマスタボリュームである第１世代各バージョンＯＳボリュームの保持データ管理テーブル１７３を調べる（図７において「ｂ」で示す）。ここでも、Ｄ０に該当するページのフラグは「０」であるので、データは存在しない。同様に、通常リード処理部は、上位世代である第２世代、第３世代のスナップショットの保持データ管理テーブル１７３を順に調べる（図７において「ｃ」、「ｄ」で示す）が、いずれもフラグが「０」であるのでデータは存在しない。

【0063】

その結果、通常リード処理部は、共通ＯＳイメージボリュームからデータＤ０を読み出す（図７において「ｅ」で示す）。

【0064】

ここで、ＯＳのバージョンアップやパッチでは、ボリュームの限られたエリアのみへの更新が多いので、ユーザボリュームにデータがなく、上述のように上位世代を辿って最終的に共通ＯＳボリュームを参照するケースが多い。つまり、多くのユーザボリュームへのアクセスにおいて、複数の保持データ管理テーブル１７３を検索する必要が生じるので、ユーザボリュームのアクセス時間が遅延する。ＯＳのバージョンが増加すると検索する保持データ管理テーブル１７３も増加するので、更にユーザボリュームへのアクセス性能が低下してしまう。

【0065】

そこで、例えば、図８のように、共通ＯＳイメージボリュームを増加することにより各バージョンＯＳボリュームを管理することも考えられる。図８では、共通ＯＳイメージボリューム１をマスタとして第１ａ世代、第２ａ世代の各バージョンＯＳボリュームが作成され、共通ＯＳイメージボリューム２をマスタとして第１ｂ世代の各バージョンＯＳボリュームが作成された構成を示す。さらに、第１ａ世代各バージョンＯＳボリュームをマスタとしてユーザボリューム１が作成され、第１ｂ世代各バージョンＯＳボリュームをマスタとしてユーザボリューム２が作成されている。

【0066】

図７の構成と同様に、ユーザボリューム２のＤ０に対してリード命令（リードｆ）がなされた場合、通常リード処理部は、ユーザボリューム２の保持データ管理テーブル１７３を調べる。図８では、Ｄ０に該当するアドレスのデータは存在しないので、通常リード処理部は、マスタボリュームである第１ｂ世代各バージョンＯＳボリュームの保持データ管理テーブル１７３を調べる（図８において「ｇ」で示す）。Ｄ０に該当するページのフラグは「０」であるので、通常リード処理部は、共通ＯＳイメージボリューム２からデータＤ０を読み出す（図８において「ｈ」で示す）。

【0067】

図８に示す構成では、ユーザボリューム２に関連する各バージョンＯＳボリュームの数が１つであり、検索する保持データ管理テーブル１７３も１つであるので、ユーザボリュームへのアクセス時間は遅延しない。このように共通ＯＳイメージボリュームを増加することにより、ユーザボリュームへのアクセス時間の遅延を防ぐことが考えられるが、共通ＯＳイメージボリュームは、実データを保持するボリュームであるので、ディスクの容量を消費してしまうという問題がある。

【0068】

そこで、本実施形態に係るディスクアレイサブシステム１００は、以下のように、ディスク容量の消費を増加させることなく、ユーザボリュームへのアクセス時間を短縮する。

【0069】

まず、ディスクアレイサブシステム１００の運用方法について説明する。ディスクアレイサブシステム１００は、ＯＳがバージョンアップやパッチなどにより更新される際、更新前の共通ＯＳボリュームイメージのスナップショットを作成することにより、更新前のＯＳバージョンを、各バージョンＯＳボリューム１５２として保持する。ＯＳの更新は、スナップショットが作成された後の共通ＯＳボリュームイメージへのライト処理により実施される。

【0070】

各バージョンをユーザに提供する際、各バージョンＯＳボリュームをマスタとして、スナップショット実行部１１２により、更にスナップショットをユーザ毎に作成する。各バージョンのＯＳイメージであるユーザボリュームが、ユーザ毎に提供される。各ユーザは、ユーザボリュームにアクセスする。

【0071】

共通ＯＳイメージボリュームへの更新がない通常運用中は、ホスト２００から送信されるＯＳ更新抑止コマンドに応じて、ディスクアレイサブシステム１００は、共通ＯＳイメージボリュームへの更新を抑止する。これにより、上位世代差分管理テーブルが有効になるので、上位世代差分管理テーブルを有効利用したユーザボリュームへのリード処理が実施される（詳細は後述する）。

【0072】

共通ＯＳイメージボリュームに対して、バージョンアップやパッチ適用による更新がある場合、ディスクアレイサブシステム１００は、事前にホスト２００から送信されるＯＳ更新許可コマンドに応じて、共通ＯＳイメージボリュームの更新を許可する。この際、上位世代差分管理テーブル１７４はクリアされフラグはすべて「０」になるので、各バージョンＯＳボリュームの保持データ管理テーブル１７３を１つずつ検索することになる（詳細は後述する）。共通ＯＳイメージボリュームの更新が完了すると、ホスト２００からＯＳ更新抑止コマンドが送られ、ディスクアレイサブシステム１００は、共通ＯＳイメージボリュームへの更新を抑止すると共に、上位世代差分管理テーブル１７４を更新する（詳細は後述する）。

【0073】

次に、ディスクアレイサブシステム１００の各構成要素の詳細について説明する。

【0074】

図９は、ホスト２００からディスクアレイサブシステム１００にボリューム管理コマンドが送られた際のボリューム管理部１１０の動作を示すフローチャートである。図９を参照して、ボリューム管理部１１０の動作について説明する。

【0075】

ホスト２００からボリューム管理コマンドが送られると、ボリューム管理コマンド取得部１１１は、そのコマンドを受信する（Ｓ１０１）。ボリューム管理コマンド取得部１１１は、受け取ったコマンドの種別を判定し、コマンドがスナップショット作成コマンドである場合（Ｓ１０２においてＹｅｓ）、コマンドをスナップショット実行部１１２に渡す。スナップショット実行部１１２は、受け取ったコマンドにて指定されたマスタボリュームからスナップショットボリュームを作成する（Ｓ１０３）。そして、スナップショット実行部１１２は、作成したスナップショットボリュームと、マスタボリュームとの対応関係を、ボリューム対応テーブル１７１に追加する（Ｓ１０４）。

【0076】

続いて、スナップショット実行部１１２は、作成したスナップショットボリュームに関する情報を、保持データ管理テーブル１７３に追加する（このとき、すべてのページに対応するフラグは「０」である）（Ｓ１０５）。

【0077】

続いて、作成したスナップショットボリュームのマスタが、共通ＯＳイメージボリュームである場合（Ｓ１０６においてＹｅｓ）、スナップショット実行部１１２は、上位世代差分管理テーブル１７４に、作成したスナップショットボリュームに関する情報を追加する。例えば、スナップショット実行部１１２は、図６に示す共通ＯＳイメージボリューム「MV_OS1」をマスタとする各バージョンＯＳボリューム「SV_OSVer3」を作成した場合、図４に示すように上位世代差分管理テーブル１７４に「SV_OSVer3」の情報を追加する（このとき、すべてのページに対応するフラグは「０」である）（Ｓ１０７）。

【0078】

一方、Ｓ１０２におけるコマンドの種別の判定の結果、コマンドがスナップショット作成コマンドでない場合（Ｓ１０２においてＮｏ）、コマンドは、ＯＳ更新抑止コマンドまたはＯＳ更新許可コマンドである。ＯＳ更新抑止コマンドは、後述する図１０のＳ２０５に示す共通ＯＳイメージボリュームの更新が完了した際のレスポンスに応じて、ホスト２００からディスクアレイサブシステム１００に送られる。ＯＳ更新抑止コマンドは、ＯＳが更新済みであり次に更新されるまで上位世代差分管理テーブル１７４は有効であることを示す。ＯＳ更新許可コマンドは、共通ＯＳイメージボリュームを更新（ライト処理）する前にホスト２００からディスクアレイサブシステム１００に送られる。ＯＳ更新許可コマンドに応じて共通ＯＳイメージボリュームが更新されるので、上位世代差分管理テーブル１７４は無効、つまりフラグはクリアされる。

【0079】

ホスト２００から受信したコマンドがＯＳ更新抑止コマンドである場合（Ｓ１０８においてＹｅｓ）、ボリューム管理コマンド取得部１１１は、そのコマンドをＯＳ更新抑止部１１３に渡す。ＯＳ更新抑止部１１３は、コマンドを受け取ると、ボリュームに対する更新を抑止するために、コマンドにて指定されたボリュームのボリューム更新許否テーブル１７２のフラグに「１」をセットする（Ｓ１０９）。

【0080】

続いて、ＯＳ更新抑止部１１３は、ＯＳ更新抑止コマンドにより更新抑止を指定されたボリュームが共通ＯＳイメージボリュームである場合、そのボリュームをマスタとするスナップショットであるすべての各バージョンＯＳボリュームの上位世代差分管理テーブル１７４のフラグを更新する（Ｓ１１０）。このとき、ＯＳ更新抑止部１１３は、対象となる各バージョンＯＳボリュームとその上位世代すべての各バージョンＯＳボリュームが持つ保持データ管理テーブル１７３の論理和（ＯＲ）をとる。論理和が「１」である場合、ＯＳ更新抑止部１１３は、上位世代差分管理テーブル１７４の該当するページのフラグを「１」に更新する。

【0081】

図１０を参照して、共通ＯＳイメージボリュームのデータが更新された場合に上位世代差分管理テーブル１７４を更新する例について説明する。図１０（ａ）に示すように、「MV_OS1」をマスタとしたスナップショットボリューム「SV_OSVer2」が作成され、その後、図１０（ｂ）に示すように、「MV_OS1」のデータＢ０がＢ１に更新されたと仮定する。このとき、通常のスナップショット技術により、「SV_OSVer2」の保持データ管理テーブル１７３の、データＢ１に該当するページのフラグに「１」が設定される（後述する図１１のＳ２０５において実施される）。

【0082】

このとき、ＯＳ更新抑止部１１３は、更新された共通ＯＳイメージボリュームをマスタとするスナップショットであるすべての各バージョンＯＳボリューム（この場合、「SV_OSVer2」、「SV_OSVer1」）について、該当するページの上位世代差分管理テーブル１７４を更新する。すなわち、ＯＳ更新抑止部１１３は、各ボリュームとその上位世代のボリュームの、該当するページの保持データ管理テーブル１７３の論理和（ＯＲ）をとる。

【0083】

図１０（ｂ）に示すように、「SV_OSVer2」について、上述のように保持データ管理テーブル１７３の該当するページのフラグに「１」が設定されたので、ＯＳ更新抑止部１１３は、このページに対応する上位世代差分管理テーブル１７４のフラグに「１」をセットする（図１０（ｂ）において「ｎ」で示す）。「SV_OSVer1」について、自ボリューム「SV_OSVer1」と上位世代「SV_OSVer2」の保持データ管理テーブル１７３の該当するページの論理和をとると「１」となるので、ＯＳ更新抑止部１１３は、「SV_OSVer1」の上位世代差分管理テーブル１７４の該当するページのフラグに「１」をセットする（図１０（ｂ）において「ｏ」で示す）。以上の手順で、ＯＳ更新抑止部１１３は、上位世代差分管理テーブル１７４を更新する。

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

１０ プロセッサ
１１ ＲＡＭ
１２ ＲＯＭ
１３ Ｉ／Ｏデバイス
１４ ストレージ
１５ バス
１００ ディスクアレイサブシステム
１１０ ボリューム管理部
１１１ ボリューム管理コマンド取得部
１１２ スナップショット実行部
１１３ ＯＳ更新抑止部
１１４ ＯＳ更新許可部
１３０ Ｉ／Ｏ処理部
１３１ Ｉ／Ｏコマンド取得部
１３２ ライト命令実行部
１３３ リード命令実行部
１５０ ボリューム群
１５１ 共通ＯＳイメージボリューム
１５２ バージョンＯＳボリューム
１５３ ユーザボリューム
１５４ プールボリューム
１７０ テーブル記憶部
１７１ ボリューム対応テーブル
１７２ ボリューム更新許否テーブル
１７３ 保持データ管理テーブル
１７４ 上位世代差分管理テーブル
２００ ホスト

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】