JP2010522914A - 順次メディアのリクラメーション及びレプリケーション・システム、方法、及びコンピュータ・プログラム - Google Patents

Abstract

【課題】 リクラメーション及びレプリケーション速度の向上、ならびに関連するデータベース更新の減少を実現する。
【解決手段】 順次メディア・リクラメーションは通常、順次アクセス・ボリュームのデータ部分が不要になり、ボリュームの不使用部分が閾値を超えた後に実行される。改良型順次メディア・リクラメーションは、スパース・ファイルとして体現される順次アクセス・ディスク・ボリューム（例えば、仮想テープ・ライブラリ（ＶＴＬ）のボリューム）を使用することによって実行される。ボリューム内に記憶されているオブジェクトのリクラメーションは、不要になったオブジェクトが含まれるスパース・ファイルの領域をヌル・アウトすることによって達成される。レプリケーション中にスパース・ファイル内に記憶されるオブジェクトに関する情報（オフセットや長さ等）を使用して、（スパース・ファイルとして体現される）ターゲット・ボリューム内のヌル・アウトすべき部分をヌル・アウトし、それによって（やはりスパース・ファイルとして体現される）ソース・ボリュームとの整合をとることが可能となる、レプリケーション方法も提供される。
【選択図】 図４

Description

本発明は一般にデータ・ストレージ管理に関するものである。より具体的には、本発明は仮想テープのような順次ストレージ・メディアのリクラメーションに関するものである。

順次メディア・リクラメーションは、順次メディア上に記憶されているデータ部分が不要になった後に、当該メディア上のスペースをリクレームする処理である。この処理が実行される最も一般的なタイプの順次メディアは、磁気テープである。ストレージ管理システムは、「リクラメーション（ｒｅｃｌａｍａｔｉｏｎ）」又は「リサイクリング（ｒｅｃｙｃｌｉｎｇ）」と呼ばれる動作を実行して、ソース・ボリュームがリクレームあるいは再利用され得るように必要なデータをある順次メディア・ボリュームから新しいボリュームにコピーすることにより、スペースをリクレームすることができる。この動作は、典型的には順次ボリュームがいっぱいになり、当該ボリューム上の使用可能データが典型的には製品ユーザ又は管理者によって定められる指定の閾値を下回った後に実行される。この動作では、典型的には後の復元動作又は検索動作で必要とされたときに該当するデータの位置を特定することができるように新しいボリューム上のデータ位置をデータベース内で更新しておく必要があるので、データ移動に加えてかなりの数のデータベース更新アクティビティも必要となる。

特定のストレージ管理システムでは、順次メディア上に記憶されているバックアップ・データ又はアーカイブ・データは、管理ポリシー（保持ポリシーやバージョニング・ポリシー等）で規定される保持期間が経過したときに有効期限が切れることになる。メディア上には複数のファイルが順次記憶されるが、各ファイルの有効期限はそれぞれ異なる可能性があるので、メディア上に記憶されるデータの各セグメントは、時間の経過とともに不要になる。データ・オブジェクトの有効期限が切れると、ストレージ管理サーバは、当該データ・オブジェクトの記憶位置への参照を除去することによって当該データ・オブジェクトを論理的に削除することができる。このようなデータ・オブジェクトの有効期限切れならびに他の理由によってデータ・オブジェクトが削除されることにより、ストレージ・ボリューム内の論理的空き領域（ｌｏｇｉｃａｌ ｖａｃａｎｃｙ）が発生することになる。このような論理的空き領域は、不要になったオブジェクトによって占有されるスペースである。順次メディアではデータの追加（ａｐｐｅｎｄ）は許可されるが、メディアの内部セクションの上書きは許可されないため、論理的空き領域については、メディアを最初から書き換えない限り再利用することはできない。

図１乃至図３は、順次メディア・リクラメーションを示す。図１において、第１のストレージ・ボリューム１０５．１は、オブジェクトＡ １１０〜Ｆ １１０のラベルが付された一連のデータ・オブジェクトを記憶するのに使用される。図示されていないストレージ管理サーバは、ストレージ・ボリュームに対する読出し及び書込み動作を制御する。各データ・オブジェクト１１０は、ストレージ・ボリューム上に順次記憶される。図１は、最後のデータ・オブジェクト１１０の後に使用可能部分１１５が残っていることを示している。例示のため、要素１２０は、最終データ・オブジェクトの終点位置、したがって使用可能部分１１５の始点位置を示している。

図２は、図１と比較した後のある時点の同一のストレージ・ボリュームを示している。図１から図２までの間に、データ・オブジェクトＧ〜Ｍがボリュームに追加され、オブジェクトＢ、Ｅ、Ｇ、Ｊ、及びＬの削除によって論理的空き領域２０５が導入されている。例えば、データ・オブジェクトは、保持ポリシー又はバージョニング・ポリシーによって削除される可能性がある。図２では論理的空き領域をデータの間隙として示してあるが、これは単なる例示にすぎない。従来、データ・オブジェクトを除去する場合、そのデータ・オブジェクトは論理的に削除されるだけであり、その結果論理的空き領域が生み出されることになる。データ・オブジェクトの論理的削除は、ストレージ管理サーバ・データベース内の当該データ・オブジェクトへの参照を除去することによって実現され得る。

図３は、図２の第１のストレージ・ボリューム１０５．１の物理的リクラメーションによって作成された新しいストレージ・ボリューム１０５．２を示している。第１のストレージ・ボリューム１０５．１上に記憶されている残りのデータ・オブジェクト１１０をこの第２のストレージ・ボリュームに順次書き込むことにより、論理的空き領域２０５がリクレームされ、それ故第２のストレージ・ボリューム１０５．２の使用可能部分１１５は、先の第１のストレージ・ボリュームの使用可能部分より大きくなる。リクラメーション後は、それまで図２に示される第１のストレージ・ボリューム上に所在していたデータ・オブジェクトが図３に示される第２のストレージ・ボリューム上に記憶される。これにより、再びテープの先頭からデータ・オブジェクトを書き込むことが可能となり、第１のストレージ・ボリュームの再利用が可能となる。

上述の物理的リクラメーション処理は、ストレージ管理サーバのリソースを利用する。例えば、第１のストレージ・ボリュームに由来するデータ・オブジェクトを第２のストレージ・ボリュームにコピーする上でサーバ・リソースが必要とされる。別の例として、リクラメーションでは、典型的には後の復元動作又は検索動作で必要とされたときに該当するデータの位置を特定することができるように新しいボリューム上のデータ位置をデータベース内で更新しておく必要があるので、かなりの数のデータベース更新アクティビティが必要となる。

一実施形態において、順次アクセス・ディスク・ボリュームをリクレームする方法は、スパース・ファイル（ｓｐａｒｓｅ ｆｉｌｅ）を使用して順次アクセス・ディスク・ボリュームに関する１組のオブジェクトを維持することによって実施される。本実施形態において、不要になったオブジェクトのリクレームは、領域データ（オフセットや長さ等）を計算し、当該領域データを使用して前記スパース・ファイル内のそれぞれの領域をヌルにすることにより、前記オブジェクトを除去することによって行われる。

別の実施形態において、前記順次アクセス・ディスク・ボリュームは、仮想テープ・ライブラリ・ボリュームである。また別の実施形態において、前記方法は、オブジェクトの有効期限が切れ、又は他の何らかの理由で前記オブジェクトが不要になったために、前記オブジェクトをリクレームする命令を受信するステップを含む。また別の実施形態において、前記スパース・ファイルからのオブジェクトの除去は、前記順次アクセス・ディスク・ボリュームがリクラメーション閾値指標（ｒｅｃｌａｍａｔｉｏｎ ｔｈｒｅｓｈｏｌｄ ｉｎｄｉｃａｔｏｒ）を満たすときにトリガされる。また別の実施形態において、前記スパース・ファイルから前記オブジェクトが除去された後は、前記スパース・ファイルのサイズに関する情報でデータベースが更新される。

本発明の他の実施形態は、スパース・ファイルとして実装されるソース順次アクセス・ディスク・ボリュームを、やはりスパース・ファイルとして実装されるターゲット順次アクセス・ディスク・ボリュームにレプリケートする方法を提供する。一実施形態において、前記ソース・ボリュームに関するサーバは、前記ターゲット・ボリュームに関するサーバにメッセージを送信する。前記ターゲット・ボリュームに関する前記サーバは、前記メッセージを構文解析（ｐａｒｓｅ）して領域データ（オフセットや長さ等）を抽出し、その後、当該領域データを使用して前記スパース・ファイル内のそれぞれの領域をヌルにすることによって各オブジェクトが除去される。一実施形態において、前記ターゲット・ファイル及びソース・ファイルは、仮想テープ・ライブラリ・ボリュームである。

データ・オブジェクトが記憶されるストレージ・ボリュームのグラフィック図である。 いくつかの論理的空き領域を伴う図１と同一のストレージ・ボリュームのグラフィック図である。 図２に示されるボリュームの物理的リクラメーションによって作成される第２のストレージ・ボリュームのグラフィック図である。 例示的なストレージ管理システムのブロック図である。 仮想テープ・ライブラリ・システムとストレージ・レポジトリ・コンポーネントとが通信可能な様子を示す、図４のシステムのサブセットに関するブロック図である。 本発明の一実施形態のフローチャートである。 図２のストレージ・ボリュームのリクラメーション前の論理ビューと、対応するデータベース情報とを示す図である。 いずれもスパース・ファイルであるソース・ボリューム及びターゲット・ボリュームのレプリケーション動作を示す図である。

図４及び図５に示されるように、ストレージ管理システム４００は、ストレージ管理サーバ４１０に接続された１組のクライアント４０５を有することができる。サーバ４１０は、プロセッサと、ランダム・アクセス・メモリ（ＲＡＭ）のようなメモリとを含む。サーバ４１０は、メモリに記憶されたｚ／ＯＳ（Ｒ）、Ｌｉｎｕｘ（Ｒ）、Ｕｎｉｘ（Ｒ）、Ｗｉｎｄｏｗｓ（Ｒ）、Ｍａｃ ＯＳ（Ｒ）、他のオペレーティング・システムのようなオペレーティング・システムの制御下で動作する。サーバ４１０は、データベース４２５と通信することが好ましい。

本発明は好ましいことに、コンピュータ使用可能な媒体（ディスク等）上に記憶され、ストレージ管理サーバ４１０（又は他のタイプのコンピュータ）によって読み込まれ実行されたときに、本発明の実施又は使用に必要な各ステップを当該サーバに実行させるコンピュータ・プログラムとすることができる。このコンピュータ・プログラム又はオペレーティング・システムは、サーバのメモリ内に有形に実装されるものであっても、ネットワークを介してアクセスされるものであってもよい。本発明は、本発明の実施又は使用に必要な各ステップの実行方法とすることもできる。また別の実施形態では、本発明は、ハードウェア又はソフトウェア・コンポーネントから成るシステムとすることができる。本発明の各実施形態には、本発明の範囲を逸脱しない限り様々な修正を施すことができることが当業者には理解されるだろう。本発明の様々な実施形態に関して論じる各特徴は互いに組み合わせることができ、１つの実施形態に必ずしもすべての特徴が含まれる必要はない。フローチャートを使用して説明される実施形態において、各ステップは、本発明の範囲を逸脱しない限り互いに組み合わせることができ、あるいは順序を入れ替えることもできる。

本システムは、ストレージ管理サーバ４１０を利用してクライアント４０５からストレージ・レポジトリ４１５へのデータ・オブジェクトのバックアップ又はアーカイビングを管理することができる。いくつかの実施形態において、ストレージ・レポジトリ４１５は、それぞれ１つ又は複数の論理ストレージ・ボリューム又は物理ストレージ・ボリュームを含む１組の論理ストレージ・プール４２０から成る。データ・オブジェクトがストレージ・プール４２０に記憶されると、当該データ・オブジェクトをストレージ・レポジトリ４１５内の他のストレージ・プールにコピーあるいは再配置することが可能となる。

本発明は、仮想テープ・ライブラリ（ＶＴＬ）を利用する。ＶＴＬはテープをシミュレートするものであるが、実際のストレージ・メディアとしては通常ディスクが利用される。ディスクが使用されても、ＶＴＬはテープ動作のセマンティクスを維持する。図５には、仮想テープ・ライブラリ・システム４４０が図４のストレージ・レポジトリ４１５と通信する様子が示されている。

ＶＴＬシステム４４０は、１つ又は複数のＶＴＬボリューム４３５と通信する１つ又は複数のＶＴＬサーバ４３０を含むことができる。ストレージ・レポジトリ４１５に記憶されているデータは、ＶＴＬシステム４４０を介してＶＴＬボリューム４３５にバックアップすること、アーカイブすること、あるいは他の方法で移動することができる。別の代替実施形態では、ＶＴＬシステムをストレージ・レポジトリ４１５の一部とすることができ、また、論理ストレージ・プール４２０又はストレージ・ボリューム１０５の代わりに使用することができる。

本発明の一部として、ＶＴＬのディスク・ストレージ内の不要になった領域のマーク付けが行われる。好ましい一実施形態において、本発明はこのタスクにスパース・ファイルを利用する。かかるスパース・ファイルは、ＶＴＬメディア内の不要になった領域をヌル・アウト（ｎｕｌｌ ｏｕｔ）する。これらのファイルは疎（ｓｐａｒｓｅ）であるので、依然として有効なデータのオフセット位置は維持され、その有効なデータの新しい位置を記録する上でデータベース更新は必要とされない。また、スパース・ファイルが必要とするディスク・スペースは小さいため、これらのファイルを使用することにより、新しいボリューム又はファイルにファイルの大部分をコピーする場合と同様に、スペースのリクレームが実現されることになる。本発明は、物理リクラメーションではなく論理リクラメーションを用いるため、リクラメーション速度を向上することができる。本明細書ではスパース・ファイルについて説明されているが、当業者ならＶＴＬメディア内の不要になった領域をマーク付けする他の技法が存在することを理解するだろう。

ディスク・メディアによって支援（ｂａｃｋ）されることが知られる順次メディア・ボリュームに対するリクラメーションの実行は、ボリューム内の不要になった領域（そのオフセット及び長さ）を特定することを含む。その後、この情報を使用して不要になった領域をヌル・アウトし、ファイル・システムによって最適化されるスパース・ファイルとすることにより、必要な領域だけがディスク上に記憶されるように、ボリューム（ファイル）内に「ホール（ｈｏｌｅ）」が生み出される。ボリューム（ファイル）・サイズは論理的には変化しないが、利用される物理ディスク・スペースは小さくなる。残りの必要なデータ・オブジェクトのオフセット及び長さは変更されず、したがって新しい位置を記録するためのデータベース更新は必要とされない。また、リクレームされたデータは（ファイルの形で記憶される）同一の論理ボリューム上に残るため、新しい論理ボリュームにコピーする必要はなく、したがってデータベース更新も必要とされない。本発明をサポートすることが可能なＶＴＬを使用することにより、仮想テープ・ボリューム内で不要になったスペース（ｕｎｎｅｅｄｅｄ ｓｐａｃｅ）のリクラメーションに要するデータベース・アクティビティ及びデータ移動を低減することが可能となる。

ＶＴＬと共に本発明の技法を使用することにより、ストレージ管理システム内で直接サポートされる順次アクセス・ディスク・ボリューム内のスペースをリクレームすることが可能となる。順次アクセス・ストレージ・ボリューム（ＩＢＭ Ｔｉｖｏｌｉ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｒのような製品におけるタイプ「ＦＩＬＥ」の装置クラスのボリューム等）は、テープ・ボリュームの場合と同様に管理者によって指定されるサイズのファイルとして実装し、順次埋めていくことができる。テープ又はＶＴＬのディスク・ファイルの場合と同様に、不要になったスペースを再利用するにはファイルをリクレームする必要がある。そのため、本発明はストレージ管理システムによって直接使用することができ、ＶＴＬを必要としない。

本発明の追加的な一実施形態は、別々の場所に所在するシステム上のストレージ・ボリュームがネットワークを介してレプリケートされる構成に適用することができる。かかる環境では、本発明のリクラメーション技法により、ソース・システムはリクラメーション手続きにおいて他のシステム内のターゲット・ボリューム上でヌル・アウトすべき領域のオフセット及び長さを通信するだけで済むので、ネットワーク上のデータ転送量が大幅に減少する可能性がある。このような実装形態では、ソース・システムとターゲット・システムとの間の新しいインターフェースが必要となる可能性があることが当業者には理解されるだろう。

本発明の上記の実装形態は、データベースに記録される順次メディア・ボリュームの論理サイズ及び物理サイズを有することが好ましい。物理サイズは、既にリクレームされたスペース（例えば、スパース・ファイルによって支援されるターゲット・ボリュームに既にホールが作成されているスペース等）をシステムが繰り返しリクレームするのを防止するのに使用することができる。リクラメーション動作は、順次アクセス・ボリューム内で不要になったが、スパース処理によるヌル・アウトがまだ実行されていないスペースの量を計算することによってトリガすることができる。このようなリクレーム可能スペース（ｒｅｃｌａｉｍａｂｌｅ ｓｐａｃｅ）が特定の閾値に達したとき又はそれを上回ったときに、ボリュームをリクレームすることが可能となる。

本発明は、ボリュームの終点に書き込まれた順次ボリュームであって、論理的に削除されたデータ・オブジェクトを有する順次ボリュームの一例を用いて説明することができる。順次ボリュームは、１ＧＢの論理サイズ及び１ＧＢの物理サイズを有するものとする。換言すると、この順次ボリュームにはヌル・アウトされたスペースがまだ含まれていない。ストレージ管理システムは、ボリューム内のスペースの２５％が依然として必要であることを判定することができる。したがって、このスペースの７５％は不要になっている。ストレージ管理システムは、本発明を利用してデータベースにアクセスし、ボリューム内の不要になった領域のオフセット及び長さを計算することができる。その後、この情報を使用してファイルの各領域をヌル・アウトすることができ、それによってボリューム内にホールが導入される可能性がある。これらのホールが作成された後、ボリュームの論理サイズは１ＧＢのままであり得るが、物理サイズは僅か２５０ＭＢとなる可能性がある。

本例の後続のリクラメーション動作では、上記のボリュームが７５％の空きスペースを有することを判定することができ、これによって当該ボリュームをリクレームする必要があることが示され得る。追加的な検査によってこのボリュームの物理サイズを調べることにより、当該スペースの７５％が既にリクレーム済みであることが判定され得る。これにより、リクラメーション動作を再度実行する必要はないことが示され得る。好ましいことに、ボリュームが本発明を利用してリクレームされるとき、データベースは、反復リクラメーション動作が不必要に実行されることがないように物理サイズ、論理サイズ、及び使用スペースを追跡する必要がある。その後、ボリュームがその時点で９０％空いており、且つ物理サイズが論理サイズの７５％未満であることがストレージ管理システムによって判定された場合は、リクラメーションを再度実行して場合によっては物理サイズを僅か１００ＭＢまで減少させることが可能となる。

以上、本発明の例示的な使用形態について説明したが、以下では、本発明で使用され得る処理の一実施形態を示すフローチャートである図６に焦点を当てる。本処理は、ストレージ・レポジトリ内の各ボリュームあるいは任意のボリュームに適用することができる。本処理のステップ５１０で、必要なファイル（ｎｅｅｄｅｄ ｆｉｌｅ）によって使用されるボリューム上のスペースが計算される。必要なファイルとは、有効期限が切れておらず、削除もされておらず、旧バージョンでもないファイル等を指す。

ステップ５１５で、そのボリュームがリクラメーションに適格であるかどうかを判定することができる。これを判定する１つの手法は、ボリューム上の使用スペース（ステップ５１０の結果）とボリュームの論理サイズとを比較することである。例えば、これを判定する１つの式は、以下のように書くことができる。
（論理サイズ−使用スペース）／論理サイズ ＞ リクラメーション閾値

そのボリュームがリクラメーションに適格である場合は、当該ボリューム上に疎でない不使用スペース（即ち、まだヌル・アウトされていない不使用スペース）が存在するかどうかを突き止めることができる（ステップ５２０）。これを突き止める１つの方法は、ボリューム上の使用スペースとボリュームの物理サイズとを比較することである。使用スペースがボリュームの物理サイズ未満である場合は、当該ボリュームはまだスパース化されていない空きスペースを有することになる。このことは、物理サイズと使用スペースの差が何らかの固定値を上回ること、又はその差を論理ボリューム・サイズで割った比率が何らかの閾値を上回ることを要件とすることによって判定することができる。

図６に示される処理では、スペースをリクレームすべきかどうかを判定する上で２つの検査が行われる。１番目の検査はステップ５１５、２番目の検査はステップ５２０である。他の実施形態では、異なる検査及び異なる回数の検査が実施され得る。様々な検査に基づいてスペースをリクレームすべきと判定された場合は、ステップ５２５でホール領域を計算することができる。ここでは、ヌル・アウトすべき各領域（即ち、各ホール）のオフセット及び長さが計算される。ステップ５３０では、ステップ５２５で計算された領域をヌル・アウトすることによって各ホールがスパース化される。ファイルのスパース化処理は、ＶＴＬシステム４４０自体によって実行され、その結果、サーバ及び残りのストレージ・レポジトリへのアクティビティ負荷が取り除かれることが好ましい。先に論じたように、本発明のいくつかの実施形態は、ＶＴＬを使用せずに実現することができる。本発明の範囲は、ＶＴＬを用いた実施形態とＶＴＬを用いない実施形態の両方に及ぶことが当業者には理解されるだろう。

ステップ５３５で、好ましくはボリュームの新しい物理サイズでデータベースが更新される。これにより、既にリクレームされたスペースをシステムが繰り返しリクレームすることが防止される。

図７は、本発明の別の態様を示している。図７は、図２のストレージ・ボリュームがリクレームされる前の論理ビュー６０５である。図７は、対応するデータベース情報６１０も含む。図７に示されるように、このストレージ・ボリューム上には１３個のデータ・オブジェクト１１０が記憶されている。これらのデータ・オブジェクトにはＡ〜Ｍのラベルが付されている。データベース４２５は、各データ・オブジェクトに関するオブジェクト・オフセット及びオブジェクト長を含めた情報を記憶する。当業者には理解されるように、図７に示されるデータベース情報では、実際に各オブジェクトが順次ディスク上に論理的に記憶されることを想定している。実際には、ＶＴＬは、それらのオブジェクトをディスクの様々なセクタ領域上に非連続的に物理的に記憶することができる。

図７は、図２のストレージ・ボリュームを模したＶＴＬボリューム６０５を示している。図７では、データ・オブジェクトＢ、Ｅ、Ｇ、Ｊ、及びＬが、不要になったデータ・オブジェクトの場合と同様に除去されている。データベース情報６１０は、これらのデータ・オブジェクトが既に存在しないことを示しており、実際、先のデータ・オブジェクト６１５に関する「ホール」が作成されている。サーバ４１０が除去されたオブジェクトのうちの１つ（オブジェクトＢ等）を要求した場合、ＶＴＬは、当該データ・オブジェクトがシステム上に存在しないことを示すゼロ又は別の標識を返す。データ・オブジェクトがデータベース内に順番に配列される場合、本発明は、残りのデータ・オブジェクト間のギャップを認識することにより、先のデータ・オブジェクトによって生じた空き領域（ｖａｃａｎｃｙ）のオフセット及び長さを検出することができる。例えば、データ・オブジェクトＡはオフセット１０００で終了し、データ・オブジェクトＣはオフセット３０００まで開始しないので、本発明は、データ・オブジェクトＡとデータ・オブジェクトＣとの間のギャップを検出することができる。一代替実施形態において、データベースは、データ・オブジェクトが論理的に除去されたことを示すフラグを用いて更新することができる。また別の実施形態において、データベースは、論理的に除去されたデータ・オブジェクトのゼロ・オフセット及びゼロ長を示すように更新することができる。当業者なら、ヌル・アウトすべき領域に対応する空き領域を認識するのに使用可能な他の技法が存在することを理解するだろう。

本発明は、リクラメーション中のデータ・オブジェクトの移動を回避する。更に、リクラメーション中にボリューム上のオブジェクトが移動されないことから、残りのオブジェクトのデータベース・レコードを更新する必要もない。それ故、本発明をリクラメーションに使用することにより、リクラメーション速度の向上及びデータベース更新の減少が実現され得る。

本発明は、リクラメーションだけでなくレプリケーションにも有用である。例えば、図８は、一方のＶＴＬシステムがソースＶＴＬボリューム７０５を含むことができ、それに関するレプリカＶＴＬボリューム７１０が他方のＶＴＬシステム上で維持され得る、２つのＶＴＬシステム４４０を示している。このレプリカとしてのターゲットＶＴＬボリューム７１０は、その時々にソース・ボリューム７０５の複写となるようにレプリケートされる。本発明の一実施形態において、ソースＶＴＬサーバ４３０．１は、メッセージ７１５をターゲットＶＴＬサーバ４３０．２に送信することができる。このメッセージは、不要になった領域に関する情報を含むことができる。この情報は、例えば不要になった各領域のオフセット及び長さであってもよい。ここで、レプリケーション処理とは、ターゲットＶＴＬサーバ４３０．２がメッセージ７１５で示されるターゲット・スパース・ファイル７１０内の領域をヌル・アウトする処理を指す。このようにして、本発明は、レプリケーション処理中にネットワークを介して転送されるデータ量を大幅に減少させることができる。

本明細書には、順次アクセス・ディスク・ボリュームのリクラメーション方法、ならびにソース及びターゲット順次アクセス・ディスク・ボリュームのレプリケーション方法を提供する本発明の様々な実施形態が記載されている。上記の論述の一部では、仮想テープ・ライブラリ・ボリュームに関する諸実施形態が論じられている。本発明は、他の形態の順次アクセス・ディスク・ボリュームにも適用可能であることが当業者には理解されるだろう。例えば、本発明は、ＩＢＭ Ｔｉｖｏｌｉ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｒのような製品におけるタイプ「ＦＩＬＥ」の装置クラスのボリューム等と共に実施することもできる。

本明細書に記載され添付図面に示される各実施形態は、方法及びシステムを含む。本発明の範囲は、各ステップの順序が入れ替えられ又は各ステップが異なる形で達成される方法にも及ぶことが当業者には理解されるだろう。システムとしては、本発明はハードウェア又はソフトウェアの形で提供される一連のコンポーネントとして実施することができる。例えば、本発明は、計算コンポーネント、オブジェクト除去コンポーネント（ｏｂｊｅｃｔ ｒｅｍｏｖａｌ ｃｏｍｐｏｎｅｎｔ）、受信機、エバリュエータ（ｅｖａｌｕａｔｏｒ）、アップデータ（ｕｐｄａｔｅｒ）、レプリケーション・メッセージ、パーザ（ｐａｒｓｅｒ）等を利用することができる。これらのコンポーネントは、添付の特許請求範囲の各請求項でも確認され得るが、上記の詳細な説明及び図面に基づいて当業者によって容易に作成される。また、本発明は、コンピュータ可読媒体上に記憶されるコンピュータ・プログラムとしても実施可能であることが当業者には理解されるだろう。本明細書には様々な実施形態が記載されているが、いずれの実施形態も本発明の範囲を本明細書に記載される各ステップ、コンポーネント、及びコンピュータ・コードに限定するものと解釈すべきではなく、本発明の概念を当業者に教示する１つの手法として供されるものであることを理解していただきたい。

Claims (23)

1. 順次アクセス・ディスク・ボリュームをリクレームするシステムであって、
   順次アクセス・ディスク・ボリュームに関する複数のオブジェクトが記憶されるスパース・ファイルと、
   前記複数のオブジェクトに由来する第１のオブジェクトを表す領域データを計算する計算コンポーネントと、
   前記領域データに基づいて前記スパース・ファイルの領域をヌルにするオブジェクト除去コンポーネントと、
   を備えるシステム。
2. 前記順次アクセス・ディスク・ボリュームは、仮想テープ・ライブラリ・ボリュームである、請求項１に記載のシステム。
3. 前記第１のオブジェクトをリクレームする命令を受信する受信機
   を更に備える、請求項１又は２に記載のシステム。
4. 前記順次アクセス・ディスク・ボリュームがリクラメーション閾値指標を満たすことを判定するエバリュエータ
   を更に備える、請求項１、２又は３に記載のシステム。
5. 前記スパース・ファイルから前記第１のオブジェクトが除去されたことに基づくサイズ・データでデータベースを更新するアップデータ
   を更に備える、請求項１、２、３、又は４に記載のシステム。
6. レプリケーション・システムであって、
   レプリケーション・メッセージを受信する受信機と、
   ターゲット・スパース・ファイルとして実装されるターゲット順次アクセス・ディスク・ボリューム内の領域を記述する、前記レプリケーション・メッセージの領域データを構文解析（ｐａｒｓｅ）するパーザ（ｐａｒｓｅｒ）と、
   前記ターゲット・スパース・ファイルをソース・スパース・ファイルとして実装されるソース順次アクセス・ディスク・ボリュームのレプリカとするために、前記領域データに基づいて前記ターゲット・スパース・ファイルの領域をヌルにするオブジェクト除去コンポーネントと、
   を備えるレプリケーション・システム。
7. 前記ソース順次アクセス・ディスク・ボリューム及び前記ターゲット順次アクセス・ディスク・ボリュームは、仮想テープ・ライブラリ・ボリュームである、請求項６に記載のレプリケーション・システム。
8. 順次アクセス・ディスク・ボリュームをリクレームする方法であって、
   順次アクセス・ディスク・ボリュームに関する複数のオブジェクトが記憶されるスパース・ファイルを維持するステップと、
   前記複数のオブジェクトに由来する第１のオブジェクトを表す領域データを計算するステップと、
   前記領域データに基づいて前記スパース・ファイルの領域をヌルにすることによって前記第１のオブジェクトを除去するステップと、
   を含む方法。
9. 前記順次アクセス・ディスク・ボリュームは、仮想テープ・ライブラリ・ボリュームである、請求項８に記載の方法。
10. 前記第１のオブジェクトをリクレームする命令を受信するステップ
    を更に含む、請求項８又は９に記載の方法。
11. 前記順次アクセス・ディスク・ボリュームがリクラメーション閾値指標を満たすことを判定するステップ
    を更に含む、請求項８、９、又は１０に記載の方法。
12. 前記スパース・ファイルから前記第１のオブジェクトが除去されたことに基づくサイズ・データでデータベースを更新するステップ
    を更に含む、請求項８、９、１０、又は１１に記載の方法。
13. レプリケーション方法であって、
    レプリケーション・メッセージを受信するステップと、
    ターゲット・スパース・ファイルとして実装されるターゲット順次アクセス・ディスク・ボリューム内の領域を記述する、前記レプリケーション・メッセージの領域データを構文解析するステップと、
    前記ターゲット・スパース・ファイルをソース・スパース・ファイルとして実装されるソース順次アクセス・ディスク・ボリュームのレプリカとするために、前記領域データに基づいて前記ターゲット・スパース・ファイルの領域をヌルにするステップと、
    を含むレプリケーション方法。
14. 前記ソース順次アクセス・ディスク・ボリューム及び前記ターゲット順次アクセス・ディスク・ボリュームは、仮想テープ・ライブラリ・ボリュームである、請求項１３に記載のレプリケーション方法。
15. 順次アクセス・ディスク・メディアのリクレーム用コンピュータ・プログラムであって、コンピュータに読み込み可能なプログラムを有するコンピュータ使用可能な媒体を備え、前記コンピュータに読み込み可能なプログラムは、それ自体がコンピュータ上で実行されたときに、前記コンピュータに
    順次アクセス・ディスク・ボリュームに関する複数のオブジェクトが記憶されるスパース・ファイルを維持するステップと、
    前記複数のオブジェクトに由来する第１のオブジェクトを表す領域データを計算するステップと、
    前記領域データに基づいて前記スパース・ファイルの領域をヌルにすることによって前記第１のオブジェクトを除去するステップと、
    を実行させる、コンピュータ・プログラム。
16. 前記順次アクセス・ディスク・ボリュームは、仮想テープ・ライブラリ・ボリュームである、請求項１５に記載のコンピュータ・プログラム。
17. 前記コンピュータに読み込み可能なプログラムは、前記コンピュータに
    前記第１のオブジェクトをリクレームする命令を受信するステップ
    を更に実行させる、請求項１５又は１６に記載のコンピュータ・プログラム。
18. 前記コンピュータに読み込み可能なプログラムは、前記コンピュータに
    前記順次アクセス・ディスク・ボリュームがリクラメーション閾値指標を満たすことを判定するステップ
    を更に実行させる、請求項１５、１６、又は１７に記載のコンピュータ・プログラム。
19. 前記コンピュータに読み込み可能なプログラムは、前記コンピュータに
    前記スパース・ファイルから前記第１のオブジェクトが除去されたことに基づくサイズ・データでデータベースを更新するステップ
    を更に実行させる、請求項１５乃至１８のいずれか一項に記載のコンピュータ・プログラム。
20. 順次アクセス・ディスク・メディアのレプリケート用コンピュータ・プログラムであって、コンピュータに読み込み可能なプログラムを有するコンピュータ使用可能な媒体を備え、前記コンピュータに読み込み可能なプログラムは、それ自体がコンピュータ上で実行されたときに、前記コンピュータに
    レプリケーション・メッセージを受信するステップと、
    ターゲット・スパース・ファイルとして実装されるターゲット順次アクセス・ディスク・ボリューム内の領域を記述する、前記レプリケーション・メッセージの領域データを構文解析するステップと、
    前記ターゲット・スパース・ファイルをソース・スパース・ファイルとして実装されるソース順次アクセス・ディスク・ボリュームのレプリカとするために、前記領域データに基づいて前記ターゲット・スパース・ファイルの領域をヌルにするステップと、
    を実行させる、コンピュータ・プログラム。
21. 前記ソース順次アクセス・ディスク・ボリューム及び前記ターゲット順次アクセス・ディスク・ボリュームは、仮想テープ・ライブラリ・ボリュームである、請求項２０に記載のレプリケート用コンピュータ・プログラム。
22. 順次アクセス・ディスク・ボリュームをリクレームするシステムであって、
    順次アクセス・ディスク・ボリュームに関する複数のオブジェクトが記憶されるスパース・ファイルと、
    前記複数のオブジェクトに由来する第１のオブジェクトを表す領域データを計算する計算コンポーネントと、
    前記領域データに基づいて前記スパース・ファイルの領域をヌルにするオブジェクト除去コンポーネントと、
    を備え、
    前記スパース・ファイルの領域をヌルにすることにより、リクラメーション速度が向上し、リクラメーション中のデータベース更新が減少する、
    システム。
23. レプリケーション・システムであって、
    レプリケーション・メッセージを受信する受信機と、
    ターゲット・スパース・ファイルとして実装されるターゲット順次アクセス・ディスク・ボリューム内の領域を記述する、前記レプリケーション・メッセージの領域データを構文解析するパーザと、
    前記ターゲット・スパース・ファイルをソース・スパース・ファイルとして実装されるソース順次アクセス・ディスク・ボリュームのレプリカとするために、前記領域データに基づいて前記ターゲット・スパース・ファイルの領域をヌルにするオブジェクト除去コンポーネントと、
    を備え、
    前記ターゲット・スパース・ファイルの領域をヌルにすることにより、レプリケーション速度が向上し、レプリケーション中のデータベース更新が減少する、
    レプリケーション・システム。

Images