ストレージデータ暗号化
ストレージ・デバイス上でデータを管理する工程は、暗号化されていないデータがストレージ・デバイスに格納されるのを阻止する工程を含み、暗号化されていないデータを阻止する工程は、ストレージ・デバイス上にデータを格納し、ストレージ・デバイス上への格納に先立ってデータを暗号化するアプリケーションに透過的である。ストレージ・デバイスは、テープ・ドライブおよび／またはディスク・ドライブを含むことができる。ストレージ・デバイス上でデータを管理する工程はまた、第１のストレージ・ロケーションから第２のストレージ・ロケーションへデータを移行する工程を含むことができる。第１のストレージ・ロケーションは第２のストレージ・ロケーションと同じであってもよいか、または第１のストレージ・ロケーションは第２のストレージ・ロケーションとは異なっていてもよい。暗号化されていないデータは、移行中に阻止されうる。ストレージ・デバイス上でデータを管理する工程はまた、ストレージ・デバイスから読み取ったデータを復号化する工程を含むことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、データ・ストレージ設備に関し、具体的には、データ・ストレージ設備内のデータの暗号化に関する。
（関連出願の相互参照）
本出願は、２００４年６月１８日に出願した米国特許出願第１０／８７２，０７４号明細書（係属中）の一部継続出願である２００４年１０月１日に出願した米国特許出願第１０／９５６，４８４号明細書（係属中）の一部継続出願である。
【背景技術】
【０００２】
データ・ストレージ設備は一般に、物理ストレージ媒体および関連するコントロールを含むディスク・アレイ・ストレージ・デバイスを備える。たとえば、標準的なディスク・アレイ・ストレージ・デバイスは一般に、物理ストレージ媒体として複数の物理ディスク・ドライブを含む。コントロールは、キャッシュ・メモリ、相互接続バス、およびアダプタを含む。少なくとも１つのホスト・アダプタは、ホスト・プロセッサ、つまり「ホスト」とバスとの間を接続する。複数のディスク・アダプタは、バスと物理ディスク・ドライブとの間のインターフェイスとして機能する。
【０００３】
ホストによって処理されているアプリケーションの観点からすれば、ディスク・ストレージは通常、「論理デバイス」内に構成される。そのような「論理デバイス」はまた、「論理ストレージ・デバイス」、「論理ボリューム」、および「デバイス」としても知られている。以下の説明では、「論理デバイス」を使用する。各論理デバイスは、単一の物理ディスク・ドライブの一部、または全体に構成されることがある。論理デバイスはまた、複数の物理ディスク・ドライブ上に構成されることもある。論理デバイスは、ファイルとも呼ばれる、１つまたは複数の「データ・セット」を格納する。各データ・セットは、１つまたは複数のエクステントを備える。エクステントは、通常ディスク・ストレージ・システム内の連続するシリンダまたはトラックである、１つまたは複数の連続ストレージ・ロケーションによって定義される。複数のデータ・セットは、「グループ」と呼ばれることがある。
【０００４】
オペレーティング・システムは、制御ルーチンおよびデータ構造を提供して、ホスト・アプリケーションとデータ・ストレージ設備の仲介をする。ホスト・アプリケーションからの入出力要求は一般に、「読み取り」または「書き込み」操作のような操作を定義し、論理デバイスは、それぞれデータが取り出される（読み取られる）元、または送り出される先（書き込まれる）の論理ストレージ・ロケーションをアドレス指定する。
【０００５】
たとえば、ＩＢＭベースのシステムは、アクセス方式、装置制御ブロック（ＵＣＢ）、および各論理デバイスに割り当てられている関連構造を含むＭＶＳ（アイビーエムコーポレーション（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ）の登録商標）オペレーティング・システムを使用する。オペレーティング・システムの入出力制御ルーチンは、これらの装置制御ブロックを使用して、アプリケーションによって提供された論理デバイス・アドレスを、ストレージ設備によって認識される接続ベースのアドレス指定に変換する。ボリューム目録（ＶＴＯＣ）内にあるようなメタデータは、特定のデータ・セットに割り当てられたその論理デバイス上で複数エクステントによって占有された正確なシリンダおよびヘッドの範囲を提供する。単一のエクステントは単一論理デバイス内の連続ストレージ・ロケーションを占有するが、そのようなオペレーティング・システムは、データ・セット内の個々のエクステントを多数の論理デバイスにわたって分散することができる。
【０００６】
格納されるデータの量が増大するのに応じて、既存のデータ・ストレージ設備内のデータの量は最大容量に近づいてゆく。その容量を追加することは、さらに大容量の高いパフォーマンスを備える新しいデータ・ストレージ設備の追加を伴う。したがって、既存のデータ・ストレージ設備を新しいデータ・ストレージ設備の追加で置き換えるか、または補うことが望ましくなっている。結果として生じるパフォーマンスの向上によって利益を得るには、古いデータ・ストレージ設備から１つまたは複数の新しいデータ・ストレージ設備へのデータの移動が必要になることが多い。
【０００７】
さらに、新しいストレージ設備内で個々の論理デバイスの記憶容量を増大させるという長期傾向もある。その１つの理由は、現在のオペレーティング・システム内の装置制御ブロックアドレスの数にアーキテクチャ上の制限があることである。これは、拡張ストレージをサポートするＵＣＢの自由な増設を妨げる。この状況は、単一の論理デバイスのアドレス指定に対して複数のＵＣＢが占有になることを求める特定のスループット最適化方法によってさらに悪化する。たとえば、現在使用可能なシステムは、単一の論理デバイスをアドレス指定するために複数の装置制御ブロックを使用して重複したアクセスを提供する。ビシリツキーら（Ｖｉｓｈｌｉｔｚｋｙ ｅｔ ａｌ．）が取得した米国特許第６，６６５，７３９号明細書では、並列アクセス装置制御ブロックを使用することにより、単一論理デバイスへの重複した入出力要求に関して規定が設けられた機能拡張を開示する。１つのアプリケーションへの並列アクセス装置制御ブロックの各割り当ては、その他の目的に使用可能な装置制御ブロックの数を減少させる。
【０００８】
ポリシーにおけるさまざまな機能拡張および変更は、可能であれば装置制御ブロックの数を節約する必要性を高めている。１つの節約の手法は、複数の小型論理デバイスから１つの大型論理デバイスにデータを統合することである。そのような手法では、既存の論理デバイスから同一または異なるデータ・ストレージ設備内の１つの論理デバイスへデータが移動されることが必要となる。しかし、また、移動または移行されるデータの通常のデータ処理アクティビティを中断することなく、そのような転送が透過的に発生することは、不可欠ではないとしても、目標である。
【０００９】
そのような透過的な並列の移動または移行を提供するために多くの努力がなされてきた。たとえば、アトキン（Ａｔｋｉｎ）が取得した米国特許第６，１４５，０６６号明細書では、完全論理デバイス間のデータの透過的な移行のための方法を開示する。この特許の開示により、ソース論理デバイス内のデータは、マルチフェーズ・プロセスでターゲット論理デバイスに転送される。基本的に、コピー・サブタスクは、データをターゲット論理デバイスにコピーすることによって、ソース論理デバイスのワン・パスを完了する。各タスク中に、ユーザ・アプリケーションは、ソース論理デバイス内のデータと引き続き対話を行う。コピー・サブタスクがワン・パスを終了した後、リフレッシュ段階では、ソース論理デバイスに行われた変更を分析して、変更されたデータをターゲット論理デバイスにコピーする。このリフレッシュ段階は、変更の数があらかじめ定められたしきい値を下回るまで、繰り返し形式で続行する。次に、システムは、ソース論理デバイスへの入出力要求を静止させて、ユーザ・アプリケーションとその論理デバイスとの間のさらなる対話を妨げる。静止中に、残りの変更されたデータは、ターゲット論理デバイスに移動する。次に、スワップ操作は、ターゲット論理デバイスが新しいソース論理デバイスになるようにする。つまり、スワッピング操作が完了した後、ユーザ・アプリケーションとの通信は再び有効になり、静止状態は終了して、ユーザ・アプリケーションと新たなソースとなったターゲット内のデータとの間の対話が可能になる。
【００１０】
前記のように、そのようなデータ移行は、論理デバイス内のすべてのデータに制限される。新しい論理デバイスは、ソース論理デバイスよりも大きい容量を有することもあるが、ソース論理デバイスからのデータは、基本的に損なわれることなくターゲット論理デバイスに転送される。システムは、論理デバイス内のエクステントのデータの処理、または１つの論理デバイス内の異なる論理デバイスからのデータ・エクステントの組み合わせについて提案を行うことはない。
【００１１】
オフェクら（Ｏｆｅｋ ｅｔ ａｌ．）が取得し、本発明の譲受人に譲渡された米国特許第６，３５６，９７７号明細書では、オンラインのリアル・タイム・データ移行のシステムおよび方法を開示する。この特許によれば、置換データ・ストレージ設備は、既存データ・ストレージ設備とホスト・オペレーティング・システムまたはネットワークとの間を接続する。置換データ・ストレージ設備は、移行されるよう指定されたすべての論理デバイスに対するすべての入出力要求を処理する。バックグラウンドのコピー操作は、既存データ・ストレージ設備内の指定された論理デバイスから、置換データ・ストレージ設備内の対応する論理デバイスにデータを移動する。バックグラウンド操作によってデータがまだ移行されていないロケーションへの任意の入出力要求は、優先度ベースで処理され、その特定のロケーションに関して移行が発生したことを示すように状態が更新される。このシステムは基本的に、移行されている論理デバイスを静止させる必要を最小化する。しかし、これはまた、完全論理デバイスの移行に制限される。
【００１２】
前述のアトキン（Ａｔｋｉｎ）およびオフェクら（Ｏｆｅｋ ｅｔ ａｌ．）の特許は、論理デバイス全体を移動するデータ移行システムの例である。これらは、１つまたは複数のソース論理デバイスから、単一のターゲット論理デバイスまたは複数のターゲット論理デバイスへと、エクステント単位ベースで、１つまたは複数のデータ・セットを移行するように適合されていない。これらは、特に論理デバイス内の一部のエクステントが移行中で、他のエクステントは移行されていない場合、ディスク・アレイ・ストレージ・デバイスの論理ボリュームの所定の数に割り当てられる必要のある装置制御ブロックの数を減少させることはできない。
【００１３】
加えて、格納されるデータは機密の場合もあり、許可されたユーザを除いてはアクセス可能にすべきではない。たとえば、オンライン・ベンダまたは銀行の顧客リストは、顧客名および住所、さらにアカウント番号を含むことがある。ストレージ・デバイス上のデータへのアクセスを制限することは可能であるが、情報は、危険にさらされる可能性もあるテープにバックアップされることもある。さらに、場合によっては、悪意のあるユーザが、ディスク上のデータにアクセスを試みて、ストレージ・デバイスのセキュリティを無効にするために、物理的にディスクを移動させることができる。同様のさまざまな場合において、データへのアクセスを許可された者を除いては、データが使用可能にならないとすれば、それは有用なことであろう。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
したがって、１つの論理デバイスからもう１つの論理デバイスへ、論理デバイスよりも小範囲にわたる１つまたは複数のデータ・エクステントを移行する方法および装置を提供することは、本発明の目的である。
【００１５】
本発明のもう１つの目的は、複数のソース論理デバイスから１つまたは複数のターゲット論理デバイスへ、複数のデータ・エクステントを移行する方法および装置を提供することである。
【００１６】
本発明のさらにもう１つの目的は、ユーザ・アプリケーションと移行されているデータ・エクステントとの間の操作に透過的にデータ・エクステントを移行する方法および装置を提供することである。
【００１７】
本発明のさらにもう１つの目的は、複数の論理デバイスを統合するためにデータ・エクステントを動的に複製することにより、データを移行する方法および装置を提供することである。
【００１８】
本発明のさらにもう１つの目的は、論理デバイスの部分のみからデータ・エクステントを動的に複製することによりデータを移行する方法および装置を提供することである。
【課題を解決するための手段】
【００１９】
本発明によれば、ソース論理デバイス内のデータ・セット・エクステントのデータ移行方法は、それぞれソース論理デバイスおよびターゲット論理デバイスのデータ・エクステントの既存のロケーションおよび将来のロケーションを識別して格納する制御データ構造を生成することによって達成される。ソース論理デバイス内の各データ・セット・エクステントは、ターゲット論理デバイスにミラーリングされたエクステントを生成するためにコピーされる。この状態の間、ソース論理デバイスにデータを書き込むよう求める要求は、ソースおよびターゲット論理デバイスの両方に方向付けられる。ソース論理デバイス内のすべてのデータ・セット・エクステントがミラーリングされると、すべての対応するメタデータは状態を確立するように更新され、それにより識別されたエクステントへのデータ要求は１つまたは複数のターゲット論理デバイス内の対応するロケーションに転換される。
【００２０】
さらに本発明によれば、いつデータ・セットを移行すべきかを決定する工程は、データ・セットのパフォーマンス基準を提供する工程と、データ・セットの実測パフォーマンスを提供するためにデータ・セットのパフォーマンスを測定する工程と、データ・セットがパフォーマンス基準に従って実行していないことを実測パフォーマンスが示す場合に、データ・セットを移行する新しいロケーションを選択する工程と、データ・セットを新しいロケーションに移行する工程とを含む。データ・セットを移行する工程は、他のアプリケーションがデータ・セットにアクセスしているかどうかにかかわりなく、データ・セットを新しいロケーションに移動する工程を含むことができる。新しいロケーションを選択する工程は、複数のロケーションの各々を分析して、その予測パフォーマンスがパフォーマンス基準に従っているかどうかを判別する工程を含むことができる。いつデータ・セットを移行するかを決定する工程は、データ・セットが操作可能にされた後にパフォーマンス基準を調整する工程を含むことができる。パフォーマンス基準は、応答時間、読み取りパフォーマンス時間、書き込みパフォーマンス時間、制御パフォーマンス時間、および日付依存パフォーマンス時間からなるグループから選択されてもよい。パフォーマンス基準は、データ管理目標を含むことができる。データ管理目標は、接続タイプ、ローカル・ミラーリング・タイプ、リモート・ミラーリング・タイプ、および最大データ・セット・サイズからなるグループから選択されてもよい。
【００２１】
さらに本発明によれば、いつデータ・セットを移行すべきかを決定する工程は、データ・セットのパフォーマンス基準を提供する工程と、データ・セットの実測パフォーマンスを提供するためにデータ・セットのパフォーマンスを測定する工程と、データ・セットがパフォーマンス基準に従って実行していないことを実測パフォーマンスが示す場合に、データ・セットが移動されることを確認するメッセージをユーザにプロンプト表示する工程と、データが移動されることをユーザが確認する場合に、データ・セットを移行する新しいロケーションを選択する工程と、データ・セットを新しいロケーションに移行する工程とを含む。いつデータ・セットを移行するかを決定する工程はまた、データ・セットが移動されることをユーザが確認しない場合に、その現在のロケーションにデータ・セットを保持する工程を含むことができる。いつデータ・セットを移行するかを決定する工程はまた、データ・セットが移行されることをユーザが確認しなかった後にフラグを設定する工程を含むことができる。データ・セットを移行する工程はまた、他のアプリケーションがデータ・セットにアクセスしているかどうかにかかわりなく、データ・セットを新しいロケーションに移動する工程を含むことができる。新しいロケーションを選択する工程は、複数のロケーションの各々を分析して、その予測パフォーマンスがパフォーマンス基準に従っているかどうかを判別する工程を含むことができる。いつデータ・セットを移行するかを決定する工程はまた、データ・セットが操作可能にされた後にパフォーマンス基準を調整する工程を含むことができる。パフォーマンス基準は、応答時間、読み取りパフォーマンス時間、書き込みパフォーマンス時間、制御パフォーマンス時間、および日付依存パフォーマンス時間からなるグループから選択されてもよい。パフォーマンス基準は、データ管理目標を含むことができる。データ管理目標は、接続タイプ、ローカル・ミラーリング・タイプ、リモート・ミラーリング・タイプ、および最大データ・セット・サイズからなるグループから選択されてもよい。
【００２２】
さらに本発明によれば、いつデータ・セットを移行すべきかを決定するコンピュータ・ソフトウェアは、データ・セットのパフォーマンス基準を提供する実行可能コードと、データ・セットの実測パフォーマンスを提供するためにデータ・セットのパフォーマンスを測定する実行可能コードと、データ・セットがパフォーマンス基準に従って実行していないことを実測パフォーマンスが示す場合に、データ・セットを移行する新しいロケーションを選択して、データ・セットを新しいロケーションに移行する実行可能コードとを含む。データ・セットを移行する実行可能コードは、他のアプリケーションがデータ・セットにアクセスしているかどうかにかかわりなく、データ・セットを新しいロケーションに移動する実行可能コードを含むことができる。新しいロケーションを選択する実行可能コードは、複数のロケーションの各々を分析して、その予測パフォーマンスがパフォーマンス基準に従っているかどうかを判別する実行可能コードを含むことができる。コンピュータ・ソフトウェアはまた、データ・セットが操作可能にされた後にパフォーマンス基準を調整する実行可能コードを含むことができる。パフォーマンス基準は、応答時間、読み取りパフォーマンス時間、書き込みパフォーマンス時間、制御パフォーマンス時間、および日付依存パフォーマンス時間からなるグループから選択されてもよい。パフォーマンス基準は、データ管理目標を含むことができる。データ管理目標は、接続タイプ、ローカル・ミラーリング・タイプ、リモート・ミラーリング・タイプ、および最大データ・セット・サイズからなるグループから選択されてもよい。
【００２３】
さらに本発明によれば、ストレージ・デバイス上でデータを管理する工程は、暗号化されていないデータがストレージ・デバイス上に格納されるのを阻止する工程を含み、暗号化されていないデータを阻止する工程は、ストレージ・デバイス上にデータを格納し、ストレージ・デバイス上への格納に先立ってデータを暗号化するアプリケーションに透過的である。ストレージ・デバイスは、テープ・ドライブおよび／またはディスク・ドライブを含むことができる。ストレージ・デバイス上でデータを管理する工程はまた、第１のストレージ・ロケーションから第２のストレージ・ロケーションへデータを移行する工程を含むことができる。第１のストレージ・ロケーションは第２のストレージ・ロケーションと同じであってもよいか、または第１のストレージ・ロケーションは第２のストレージ・ロケーションとは異なっていてもよい。暗号化されていないデータは、移行中に阻止されうる。ストレージ・デバイス上でデータを管理する工程はまた、ストレージ・デバイスから読み取ったデータを復号化する工程を含むことができる。データを復号化する工程はまた、使用が制限されている秘密復号鍵を使用する工程を含むことができる。ストレージ・デバイス上でデータを管理する工程はまた、不正改ざん防止モジュールを使用して秘密鍵を格納し、データを復号化する工程を含み、不正改ざん防止モジュールは秘密鍵へのアクセスを制限する。
【００２４】
さらに本発明によれば、ストレージ・デバイス上でデータを管理するコンピュータ可読媒体におけるコンピュータ・ソフトウェアは、暗号化されていないデータがストレージ・デバイス上に格納されるのを阻止する実行可能コードを含み、暗号化されていないデータを阻止する工程は、ストレージ・デバイス上にデータを格納するアプリケーション、およびストレージ・デバイス上への格納に先立ってデータを暗号化する実行可能コードに透過的である。コンピュータ・ソフトウェアはまた、第１のストレージ・ロケーションから第２のストレージ・ロケーションへデータを移行する実行可能コードを含むことができる。第１のストレージ・ロケーションは第２のストレージ・ロケーションと同じであってもよいか、または第１のストレージ・ロケーションは第２のストレージ・ロケーションとは異なっていてもよい。コンピュータ・ソフトウェアはまた、移行中に暗号化されていないデータを阻止する実行可能コードを含むことができる。コンピュータ・ソフトウェアはまた、ストレージ・デバイスから読み取ったデータを復号化する実行可能コードを含むことができる。データを復号化する工程は、使用が制限されている秘密復号鍵を使用する工程を含むことができる。復号化は、ストレージ・デバイスに結合された少なくとも１つのホスト上で実行されうる。暗号化は、ストレージ・デバイスに結合された少なくとも１つのホスト上で実行されうる。暗号化は、ストレージ・デバイスに結合された少なくとも１つのホストまたはストレージ・デバイス上のいずれで実行されてもよく、復号化は、ストレージ・デバイスに結合された少なくとも１つのホストまたはストレージ・デバイスのうちのもう一方で実行されてもよい。
【００２５】
添付の特許請求の範囲は、本発明の主題を特に指摘して明瞭に主張する。本発明のさまざまな目的、利点、および新奇な特徴は、類似する参照番号が類似した部分を参照する添付の図面と併せて以下の詳細な説明を読めばさらに完全に明らかとなろう。
【発明を実施するための最良の形態】
【００２６】
図１は、一例として、ホスト２１と、データ・ストレージ設備２２および２３として２つのディスク・アレイ・ストレージ・デバイスを含むデータ処理システム２０を示す。当技術分野において知られているように、ホスト２１は、少なくとも１つの専用領域２５および共通ストレージ領域２６に分割されるメイン・メモリ２４を含む。１つまたは複数のプロセッサ３０は、メモリ２４と対話する。
【００２７】
データ・ストレージ設備２２および２３のような、単一ホスト２１と入出力デバイスとの間の通信は、サブチャネルを介して発生する。本発明を説明するために、サブチャネル３１は、ホスト２１とソース・データ・ストレージ設備２２とを接続し、サブチャネル３２は、ホスト２１とターゲット・データ・ストレージ設備２３とを接続する。２次ホスト２１Ａは、マルチ・プロセッサ３０Ａ、メモリ２４Ａ、サブチャネル３１Ａおよび３２Ａを備える類似した構造を有する。
【００２８】
前述のように、ホスト・アプリケーションおよびデータ・ストレージ設備は、データのロケーションを異なる方法で識別する。つまり、ホスト・アプリケーションは、データを論理レベルで、データ・エクステントまたは「エクステント」および／または１つまたは複数のエクステントのデータ・セットと見なす。ＭＶＳオペレーティング・システム（ｚ／ＯＳ）などのオペレーティング・システムは、データのホスト・アドレス指定フォーマットを、データ・ストレージ設備のアドレス指定フォーマットに変換する。
【００２９】
具体的には、オペレーティング・システムは、ホスト・アプリケーションと、ＥＸＣＰ、メディア・マネージャ、入出力装置ルーチンのような低レベル・ルーチンとの間のインターフェイスとしてアクセス方式を使用する。入出力ドライバルーチンは、ＳＴＡＲＴＩＯ関数のような低レベル関数を呼び出して、サブチャネル経由で入出力を開始し、それによりデータ・ストレージ設備との間で情報をやりとりする。オペレーティング・システムは、特に当技術分野でよく知られているＣａｔａｌｏｇ、ＶＴＯＣ、ＶＶＤＳなどのコンポーネントを含む統合カタログ機能（ＩＣＦ）からの情報を使用して、アプリケーションから受け取ったアドレス指定フォーマットからのデータ・アドレスを、論理デバイス、シリンダ、およびヘッドによってデータを識別するアドレス指定フォーマットに変換する。この情報は一般に、「メタデータ」と呼ばれる。データ・ストレージ設備は、この論理デバイス・アドレス指定フォーマットを物理ディスク・ドライブ・アドレス指定フォーマットに変更するための情報を含む。
【００３０】
本発明の理解を深めるために、図１におけるデータ・ストレージ設備２２は、既存のまたはソースのデータ・ストレージ設備であり、データ・ストレージ設備２３は、ソース・データ・ストレージ設備２２からデータを受け取るターゲットとしての機能を果たす新規または先在のデータ・ストレージ設備であると仮定する。データ・ストレージ設備２２は、論理デバイス２２（１）、２２（２）、２２（ｎ−１）、および２２（ｎ）が図１に示されている「ｎ」個の論理デバイスを有する。データ・ストレージ設備２３は、論理デバイス２３（１）、２３（２）、２３（ｍ−１）、および２３（ｍ）が示されている「ｍ」個の論理デバイスを有する。以下の説明において、データ・ストレージ設備２２の論理デバイスは「ソース論理デバイス」と呼ばれ、データ・ストレージ設備２３の論理デバイスは「ターゲット論理デバイス」と呼ばれる。
【００３１】
図１におけるホスト２１は、ＩＢＭ ＭＶＳオペレーティング・システムで稼働しているＩＢＭメインフレーム・システムなどのような、オペレーティング・システムによって制御される多重処理装置を備える標準的なメインフレーム・システムを表す。そのようなホストにおいて、ユーザ・アプリケーションは、有用なデータを操作するための制御を提供する。ＵＳＲ１アプリケーション３３およびＵＳＲ２アプリケーション３４は、２つのそのようなユーザ・アプリケーションを表す。たとえば、ＵＳＲ１アプリケーション３３は、トランザクション処理を担当する。ＵＳＲ２アプリケーション３４は、ＵＳＲ１アプリケーション３３を通じて供給されたデータに基づいてレポートを生成する。多くの場合、ＵＳＲ１アプリケーション３３のようなアプリケーションは、１日２４時間、週７日使用可能である必要がある。レポート・アプリケーションは、定期的に実行される。
【００３２】
公知のように、データ・セットを形成するエクステントは、あらゆる方法で格納されうる。つまり、１つのデータ・セット内のエクステントは、連続であっても、不連続であってもよい。たとえば、ＵＳＲ１アプリケーション３３およびＵＳＲ２アプリケーション３４は、ソース・データ・ストレージ設備２２のＤＳ１データ・セット３５、ＤＳ２データ・セット３６、およびＤＳ３データ・セット３７として指定された３つの個別のデータ・セットと対話すると仮定する。説明のため、ＤＳ１およびＤＳ２のデータ・セット３５および３６内のすべてのエクステントは連続し、各データ・セットが１つの論理デバイスに備えられると仮定する。ＤＳ３データ・セット３７は、２つのエクステントＤＳ３（１）およびＤＳ３（２）がソース論理デバイス２２（ｎ−１）上に不連続に備わる５つのエクステントを有するが、エクステントＤＳ（３）、ＤＳ（４）、およびＤＳ（５）はソース論理デバイス２２（ｎ）上に連続して備わると仮定する。
【００３３】
本発明は、連続エクステント、不連続エクステント、またはその組み合わせを備えるデータ・セットを移行する能力を有する。図１の具体的な実施形態を参照すると、本発明は、ユーザ・アプリケーション３３および３４と、ＤＳ１データ・セット３５、ＤＳ２データ・セット３６およびＤＳ３データ・セット３７内のデータとの間の対話を中断することなく、ソース論理デバイス２２（１）、２２（２）、２２（ｎ−１）および２２（ｎ）から、データ・ストレージ設備２３のターゲット論理デバイスに、開示されたデータ・セットの各々を移行する能力を有する。たとえば、ＤＳ１データ・セット３５およびＤＳ２データ・セット３６はいずれも、ターゲット論理デバイス２３（１）のような１つの論理デバイスに移行することができる。図１はまた、ＤＳ３データ・セット３７の４つのエクステントが、ターゲット論理デバイス２３（ｍ−１）の連続ロケーションに移行し、第５のエクステントＤＳ３（５）がターゲット論理デバイス２３（ｍ）に移行する動作も示す。
【００３４】
図１におけるメモリ２４は、データ・ストレージ設備２２および２３の両論理デバイスごとに装置制御ブロック（ＵＣＢ）を含む。これらの装置制御ブロックは、メモリ２４の共通領域２６に格納される。一例として、図１は、ＤＳ１データ・セット３５を含むソース論理デバイス２２（１）に関連付けられているＵＣＢ ＬＤＳ１制御ブロック３８を示す。ＵＣＢ ＬＤＳ２装置制御ブロック３９は、ソース論理デバイス２２（２）に関連付けられている。ＵＣＢ ＬＤＴ１装置制御ブロック４０は、ターゲット論理デバイス２３（１）に関連付けられている。その他の装置制御ブロック（図示されず）は、図１に示されるその他の論理デバイスの各々に関連付けられている。
【００３５】
本発明の例示的な実施形態を説明する前に、図２における手順４１によって示されるユーザ・アプリケーションの基本動作工程を検討することが有益であろう。ＵＳＲ２アプリケーション３４のようなユーザ・アプリケーションが初期化されるとき、工程４２は、本発明には関連しない特定の予備機能を実行する。工程４３は、１つまたは複数の関連するデータ・セットを開く。たとえば、ＵＳＲ１アプリケーション３３は、ＤＳ１データ・セット３５およびＤＳ３データ・セット３７を開くが、ＵＳＲ２アプリケーション３４はＤＳ２データ・セット３６を開く。その方法の一部において、ＵＳＲ１アプリケーション３３およびＵＳＲ２アプリケーション３４は、工程４４において対応するデータ・セットのメタデータを取り出す。本発明にとって重要なことに、メタデータは、システムがいずれかの時点で特定の論理デバイスおよびＵＣＢにマップするボリューム通し番号を提供するＭＶＳカタログ情報を含む。ＶＴＯＣは、シリンダおよびヘッド範囲のセットをエクステント・リストに提供する。
【００３６】
工程４５は、たとえば図１のデータ・ストレージ設備２２を含むさまざまな入出力装置により入出力要求を制御するために、取り出したメタデータ、特にＤＳ１データ・セット３５、ＤＳ２データ・セット３６、およびＤＳ３データ・セット３７を使用してアプリケーション機能を実行する。さらに、移行されるべきデータ・セットを開く各アプリケーションは、アプリケーションがそのデータ・セットを閉じるまで、そのデータ・セットの元のメタデータを使用し続ける。つまり、アプリケーションが終了すると、工程４６は、開いているデータ・セット、またはアプリケーションが工程４３において開いたデータ・セットを閉じる。しかし、あるアプリケーションがデータ・セットを閉じる場合、そのデータ・セットが引き続き別のアプリケーションに開かれている可能性もある。移行が発生した後にアプリケーションがデータ・セットを閉じた場合、アプリケーションがその後データ・セットを開くと、アプリケーションはターゲット論理デバイス上の移行されたデータに直接アクセスするので、この方法を理解しておくことは重要である。
【００３７】
論理データ移行−−コマンド
多くの状況において、構成ステートメントは、本発明の論理データ移行アプリケーションのような、一連の制御アプリケーションの動作を制御する。一部の制御アプリケーションにおいて、１つまたは複数の構成ステートメントのセットは、制御アプリケーションの異なる段階を開始する。本発明の１つの実施形態において、さまざまな構成ステートメントは、初期化、移行および転換、および終了の段階の開始を有効にする。制御アプリケーションの機能の知識およびデータ処理システムの特定の構成により必要な構成ステートメントを生成することは、当業者の技術の範囲に含まれる。
【００３８】
この説明のために、「コマンド」は、構成ステートメントのセットを表し、本発明に関連する情報を説明して、必要な構成ステートメントを準備できるようにする。所定のコマンドは、手順の単一の段階または複数の段階の開始を制御する能力を有すると見なされる。さらに、各段階は、その特定の段階を実行するためのモジュールとして実施されるものと見なされる。
【００３９】
この背景をふまえ、図１および図３は、１つまたは複数のソース論理デバイス内の複数のエクステントから、１つまたは複数のターゲット論理デバイスへ、１つまたは複数のデータ・セットを移行することで特徴付けられうる論理デバイス移行（ＬＤＭ）アプリケーション５０の１つの実施例を示す。本発明の理解を助けるものとして、この特定のＬＤＭ論理アプリケーションは、各々特定の機能または関連する機能のグループを表す４つの別個の動作モジュールを有するものとして表される。これらは、初期化モジュール５１、移行および転換モジュール５２、終了モジュール５３、および監視モジュール５４を含む。
【００４０】
専用アプリケーション・メモリ２５におけるように、ＬＤＭアプリケーション５０がメモリ２４に読み込まれると、これはプロセッサ２１が引数またはフィールドの形態で情報を有するＬＤＭコマンドに応答できるようにする。基本的に、コマンドは以下の情報を含む。
【００４１】
１．「ＬＤＭ」または同等の演算コードなどのコマンド識別子。コマンドを論理データ移行コマンドとして識別する。
２．コマンドに応答して実行される図３のモジュールを識別する引数。たとえば、これらは、初期化引数、移行および転換引数、終了引数、監視引数、またはこれらの引数の一部またはすべての組み合わせを含むこともできる。
【００４２】
３．具体的に、またはパターン・マッチングを介して名前により識別され、かつ／またはさまざまなソース・ボリュームを識別することにより識別されるソース・データ・セットの識別。ターゲット論理デバイスの識別は、具体的に、またはＩＢＭのストレージ管理システム、つまり、いわゆるストレージ・グループあるいは同様の機構によって使用されるような、規則を介して行われる。データ・ストレージ設備においてデータ・グループ、セット、およびエクステントを識別するさまざまな方法が当技術分野で知られている。
【００４３】
４．シリンダまたはトラックの数を確立するしきい値引数。その数を下回ると残りのトラックは、完全同期およびミラーリング状態を確立するために静止されたアプリケーション入出力によりコピーされる。
【００４４】
５．データ・セットがデータ・グループに編成されるとき、引数は、グループ移行が一貫した方法で発生するかどうかを決定する。
６．別のホスト２１Ａにより形成される図１に示されるようなマルチホストネットワークにおいて、ホストが１次、またはオーナ、ホストまたは２次、または非オーナ、ホストであるかどうか。
【００４５】
論路データ移行アプリケーションがロードされてアクティブにされると、ＬＤＭまたは同等のコマンドの実行は、図４に示されるようにさまざまな操作または手順のいずれかを開始する。たとえば、工程５５は、コマンドの受信と、そのホストとＬＤＭコマンドに応答して移行される任意のエクステントとの間のトランザクションのための監視モジュール５４のアクティブ化を表す。工程５６および工程５７は、有効な引数に応答して図５に従って初期化モジュール５１を処理する。移行および転換引数が有効である場合、工程５８は、工程６０が、データを移行する図７から１０に示される工程に従って移行および転換モジュール５２を処理できるようにする。終了引数が有効である場合、工程６１は、工程６２が、図１１に示されるように終了モジュールを処理できるようにする。この特定の実施態様は、図３に示されるすべての手順が、１つのコマンドに応答して順序正しく処理されるようにする。しかし、明らかとなるように、第１のコマンドは通常、有効な初期化引数のみ、または有効な初期化引数と移行および転換引数の両方を含むことができる。後に、ＬＤＭコマンドは、有効な終了引数のみにより発行されることになろう。
【００４６】
論理データ移行−−初期化段階
初期化引数を持つＬＤＭコマンドが受信されると、ＬＤＭアプリケーション５０は、初期化モジュール５１を使用して、各エクステントが移行されるべきソース論理デバイス内のエクステントのロケーションおよびターゲット・ストレージ論理デバイスのロケーションを識別する制御データ構造を生成する。初期化モジュールはまた、ソースおよびターゲット論理デバイスに関連する構成情報を格納する。
【００４７】
具体的には、初期化引数セットを持つコマンドを受信すると、図４の工程５７は、工程７１においてＬＤＭコマンドを解析する図５の工程７０に制御を移す。解析は、一貫したデータ移行の必要性およびしきい値を識別するＬＤＭコマンドからの情報をもたらす。ＬＤＭコマンドの解析はさらに、ソース・エクステントおよび対応するターゲット・エクステントのロケーションが決定されうる情報ももたらす。
【００４８】
工程７２は、移行が満足される条件を検証する。たとえば、検証は、ソースおよびターゲット論理デバイスが互換であるかどうかを判別することを含むこともできる。条件が検証されると、工程７３は、制御を工程７４に移して初期化モジュールを続行する。それ以外の場合、工程７３は、制御を工程７５に移して、エラー・メッセージを生成し、コマンドに対するそれ以降の応答を終了して、論理データ移行を事実上中止する。
【００４９】
工程７４は、論理デバイス移行の実行および転換モジュール５２中に使用するために、図６に示されるデータ構造に対応するデータ構造を確立する。この工程はまた、対応する引数またはＬＤＭコマンドにしきい値をロードする。具体的には、図６は、異なるロケーションにおいて、しきい値エントリ７７、グループ状態エントリ７８、およびデータ・セット・ポインタ７９を受け取るグループ・ブロック７６を備えるデータ構造を示す。データ・セット・ポインタ７９は、第１のデータ・セット・ブロック８０のロケーションを識別する。データ・セット・ブロック８２のような、各データ・セット・ブロックは、論理デバイス・ポインタ８１およびデータ・セット状態エントリ８２のロケーションを有する。各データ・セット・ブロックはまた、グループ内のすべてのデータ・セットについて個々のデータ・セット・ブロックをリンクするさまざまな既知の手段のいずれかを含む。
【００５０】
論理デバイス・ポインタ８１は、エクステント・ポインタ８４および論理デバイス状態エントリ８５のロケーションを含む第１の論理デバイス・ブロック８３を指し示す。エクステント・ポインタ８４は通常、選択された論理デバイスについて、エクステント・ブロック９０のような、第１のエクステント・ブロックのロケーションを識別する。データ・セットに関連付けられているその他のすべての論理デバイスへのリンクも存在する。
【００５１】
エクステント・ブロック９０は、特定のエクステントに関する特定の情報を含む。１つのロケーションは、エクステント状態エントリ９１を含む。その他のロケーションは、初期ソースおよびターゲット・アドレス９２および終了アドレス９３などの、アドレスの表現を格納する。アドレス９２および９３は各々、絶対アドレス、基底アドレスまたはオフセットによって、あるいは何らかのアドレス変換によって構成されうる。前述の説明と同様の方法で、単一の論理デバイスに関連付けられているすべてのエクステント・ブロックにリンクが提供される。
【００５２】
さらに図６を参照すると、データ構造は、これ以降「制御ブロック」９４および９５と呼ぶ、トラック−シリンダ制御ブロックを含む。制御ブロック９４およびブロック７６、８０、８３、および９０は、ソース論理デバイスと関連して格納される。図１において、情報は、データ・ストレージ設備２２に格納される。これらのデータ構造は、データ・ストレージ設備の構成に応じて、キャッシュ・メモリ、物理ディスク、またはその両方に格納される。しかし、通常、ソース論理デバイス制御ブロックおよびデータポインタはまた、図１のメイン・メモリ２４に格納される。制御ブロック９５は通常、ターゲット論理デバイスに格納される。
【００５３】
トラック・ベースでの制御が望ましい１つの実施形態において、制御ブロック９４および９５の各エントリは、エクステント状態エントリ９６、列９７に単一ソース・トラック・アドレス、および列１００に対応するターゲット・トラック・アドレスを含む。エクステントが１つまたは複数の完全シリンダを占有する場合、列９７および１００のソースおよびターゲット・アドレス・エントリは、アドレスをシリンダ・レベルに対してのみ定義することができる。その場合、制御ブロック９４および９５の各行は、初期シリンダ・アドレスを識別する。エクステントがシリンダ境界で開始および終了しない場合、エントリは、個々のトラック・アドレス指定を提供するために、シリンダおよびヘッド・アドレスに対するものになる。
【００５４】
ＣＯＰＹ列１０１は、トラックごとに、トラックが引き続きコピーを必要とするかどうかを記録する。場合によっては、ＣＯＰＹ列１０１は、ソース論理デバイスに関連付けられているトラック・テーブルによって構成されうる。そのような場合、制御ブロック９４および９５はまた、コピーされる必要があるトラックを反映するためにＳＹＮＣ列１０２を含むことができる。
【００５５】
図５および図６を共に参照すると、工程７４が図６のデータ構造を確立した後、図５の残りの工程はさまざまなデータ構造を取り込む。この方法の一部として、工程１０３は、データ・セット・ポインタ７９によって識別されたデータ・セットのような、識別されたデータ・セットのうちの１つを選択する。工程１０４および１０５は、ＩＣＦからの情報を使用して、そのデータ・セットのエクステントとエクステントのうちの１つを格納する各論理デバイスのロケーションを識別する。これに応答して、図５Ａに示される方法は、ソース論理デバイスのエクステントの開始および終了アドレスを生成する工程１０６を伴うエクステント・ブロック制御テーブル・エントリを生成する。工程１０７は、ターゲット論理デバイス内のエクステントの開始アドレスをもたらす。この情報がそれぞれ、図６のブロック９２および９３にロードされた場合、工程１０８は、エクステント状態エントリ９１のような、対応するエクステント状態エントリを、ＣＯＰＹ状態を示すように初期ＣＯＰＹ値に設定する。
【００５６】
次いで、工程１１０は、トラック・シリンダ制御ブロック９４および９５の各々にデータを取り込む。つまり、識別されたエクステント内の各トラックまたはシリンダについて、工程１１０は所定の行にエントリを入力する。したがって、所定のエクステントは、トラック・シリンダ制御ブロック９４および９５内に多数の異なるエントリを有することができる。加えて、工程１１０は、列１０１内のすべてのＣＯＰＹビット、および列１０２内のすべてのＳＹＮＣビットに初期値を確立して、各々対応するトラックがコピーされる必要があることを示す。工程１１０はさらに、対応する状態エントリごとに初期状態値を設定する。
【００５７】
戻って図５を参照すると、モジュールは、ループ制御として工程１１１を使用し、図５Ａの手順が識別されたエクステント内のトラックごとにエクステント・ブロック９０およびトラック・シリンダ制御ブロック９４および９５を確実に取り込むようにする。追加のエクステントがデータ・セット内で処理される必要がある場合、制御は工程１１１から工程１０５に戻る。
【００５８】
選択された論理デバイス内のデータ・セットのエクステントのすべての制御データが制御データ構造を取り込んでいる場合、工程１１１は、データ・セット内のすべての論理デバイスが確実に処理されるようにする工程１１２に制御を移す。そうではない場合、制御は工程１０４に戻り、工程１０３において選択されたデータ・セットのエクステントを含む別の論理デバイスを選択する。データ・セットのすべての論理デバイス内のすべてのエクステントが処理されている場合、工程１１２は、工程１１３に制御を移す。工程１１３は、ＬＤＭコマンドで識別されたすべてのデータ・セットが処理されていることを確実にするため、ループ制御である。追加のデータ・セットが存在する場合、制御は工程１１３から工程１０３に戻る。すべてのデータ・セットが処理されている場合、初期化モジュール５１の操作は中断して、図６のデータ構造が完全に取り込まれる。
【００５９】
したがって、初期化モジュール５１がその操作を完了する場合、環境は、データ移行を制御するために存在する。監視機能はアクティブであり、データ構造はアクティブである。ここで、有効な初期化引数と移行および転換引数と共に送信されたＬＤＭコマンド、または有効な移行および転換引数と共に送信された後続のＬＤＭコマンドによって、移行および転換が開始する。
【００６０】
論理データ移行−−移行および転換段階
図７は全般として、データ移行に関与する各データ・セットに対してエクステント・ベースおよび論理デバイス・ベースでデータの移行が発生する移行および転換モジュール５２の操作を示す。方法は、工程１２０において開始し、初期化モジュール５１が初期化段階を完了していることを確認する。初期化段階が完了している場合、工程１２０は工程１２１に進み、移行および転換モジュールの残りの工程を開始する。それ以外の場合、工程１２０は、アボート・メッセージを生成する工程１２２に制御を移し、移行および転換段階は終了する。
【００６１】
工程１２１は、データ・セットを選択し、図６のエントリ８２のような、データ・セット状態エントリをＴＲＡＮＳＩＴＩＯＮ値に変更する。工程１２３は、データ・セットの論理デバイスを選択して、その論理デバイス状態エントリをＴＲＡＮＳＩＴＩＯＮ値に設定することにより、同様の操作を実行する。ＴＲＡＮＳＩＴＩＯＮ値は、論理デバイスがＭＩＧＲＡＴＥＤ状態へ遷移していることを示す。
【００６２】
次に、工程１２４は、ブロック９０によって表されるエクステントなどのエクステントをミラーリングされるように選択する。図７Ａに示されるように、工程１２５は、「ミラー・エクステント」方法における第１の工程である。工程１２５は、エントリ９１などのエクステント状態エントリをＣＯＰＹＩＮＧ値に設定して、エクステントがターゲット論理デバイスにコピーされていることを示す。エクステントが１つまたは複数の完全シリンダによって定義されない場合、工程１２６はエクステント内のトラックを選択する。工程１２７は、図３の監視モジュール５４または他のリソースによって取得された情報に基づいて、任意の外部操作がソース・エクステントを変更したかどうかを判別する。変更が発生した場合、移行および転換段階は、変更を処理する手順１２８を経由して終了する。それ以外の場合、制御は工程１３０に進む。
【００６３】
工程１３０は、トラック行内の識別されたトラックの特定のソース・トラックを識別するために、ソース制御ブロック９４に注目する。列１０１内の対応するＣＯＰＹビットが設定されている場合、工程１３０は工程１３１に進み、ソース論理デバイス・トラック内のデータを、制御ブロック９４でトラック・アドレスによって定義されているように、ターゲット論理デバイス内の対応するトラックにコピーする。工程１３２は、特定の実施形態に応じて、トラック・シリンダ制御ブロック９４および９５内のＣＯＰＹビットおよび／またはＳＹＮＣビットの状態を、トラックがコピーされていること示すように変更する。工程１３２がその機能を実行した後、または選択されたトラックがすでにコピーされていると工程１３０が判別した場合、制御は工程１２３に移る。エクステント内にさらにトラックが存在する場合、工程１３３は、次のトラックを選択する工程１２６に制御を戻す。代替として、データ・セット内の選択されたエクステントがシリンダ・レベルで定義されている場合、工程１３０から工程１３２は、トラック・レベルではなく完全シリンダ・レベルでさまざまな操作を確立するように変更されうる。
【００６４】
エクステントがこのループで処理された場合、工程１３３は、ソース論理デバイス制御ブロック９４に存在するエクステントに対して設定されたＣＯＰＹビットまたはＳＹＮＣビットの数をカウントする工程１３４に制御を移す。後に説明されるように、ユーザ・アプリケーションは、ＣＯＰＹＩＮＧ状態中にエクステント内のデータを変更することができる。したがって、ループ通過を終えた時点で、コピーされたトラックが変更されている可能性もある。そのため、変更されたトラック内のデータは、再度コピーされる必要がある。工程１３４は、再度コピーされる必要のあるトラックの数を決定する。トラックの数が、図６のしきい値ブロック７７において確立された特定のしきい値であるか、またはそれを超える場合、工程１３５は、トラックを選択することによりエクステントを再度処理する工程１２６に制御を戻す。
【００６５】
工程１２６から工程１３５を備えるこのループは、あらかじめ定められた条件が達せられるまで続行する。この特定の実施形態においてコピーを必要とするトラックの数がしきい値を下回る値まで減少したときに、あらかじめ定められた条件は達せられる。次いで、工程１３５は、ターゲット論理デバイス・エクステント内のデータをソース論理デバイス・エクステント内のデータに同期化させる方法において第１の工程である図７Ａの工程１３６に制御を移す。
【００６６】
これは、連続した方法であり、そのため工程１３６はソース論理デバイス内のエクステントをロックして、アプリケーションとソース論理デバイス・エクステントとの間の対話を妨げる。次いで、工程１３７は、残りの変更済みトラックからターゲット論理デバイスにデータを移行することによって、ミラーリング操作を完了する。明らかなように、この間にホスト・アプリケーションとの対話は全く発生しない。この工程が完了すると、ターゲット論理デバイスのエクステント内のデータは、ソース論理デバイスの対応するエクステント内のデータをミラーリングする。工程１４０は、エントリ９１のような、対応するエクステント状態エントリ内のエクステント状態を、同期化がそのエクステントに対して達成されていることを示すＭＩＲＲＯＲＥＤ値に更新する。次いで、工程１４１は、ホストとエクステントとの間の通信を再び可能にするように、ソース・エクステントのロックを解除する。
【００６７】
工程１４１がエクステントのロックを解除した後、エクステントは再びユーザ・アプリケーションに使用可能になる。次いで制御は、図７、特に工程１４２に戻る。論理デバイス内にさらにエクステントがある場合、工程１４２は、次のエクステントをミラーリングする方法を繰り返す工程１２４に制御を移す。
【００６８】
データ・セット内のすべてのエクステントが転送されると、図７の工程１４２は、移行が一貫した方法で実行されているかどうかを判別する工程１３４に制御を移す。具体的には、工程１４３は、ＬＤＭコマンド内の一貫性引数を検査する。引数が有効である場合、１つまたは複数のターゲット論理デバイスに移行されたデータへの転換は、同時に発生するはずである。その場合、工程１４３は、他の論理デバイス内の追加データ・セット・エクステントが処理される必要があるかどうかを判別する工程１４４に進む。データ・セットの追加論理デバイス内のエクステントが処理される必要がある場合、工程１４４は、選択されたデータ・セットのエクステントを含む別の論理デバイスを選択する工程１２３に制御を戻す。すべての論理デバイスが処理されている場合、工程１４４は、追加のデータ・セット内のエクステントが処理される必要があるかどうかを調べる工程１４５に制御を移す。
【００６９】
グループの一貫性が必要とされない場合、工程１４３は、図７Ｂに示される連続した「非一貫性変換」方法を開始するために制御を移し、ここで工程１４６は選択された論理デバイス内のエクステントをロックする。次いで、工程１４７は、論理デバイス内の識別されたデータ・セット・エクステントのメタデータを更新する。次いで、工程１４７はさらに、図６の状態エントリ８６などの論理デバイス状態エントリ、およびエントリ９１などのすべての対応するエクステント状態エントリを更新することにより、ＤＩＶＥＲＴＥＤ状態を示すように、データ・セットの状態を設定する。次いで、工程１４８は、ソース・データ・セット・エクステントのロックを解除して、制御を図７の工程１４４に移す。
【００７０】
すべてのデータ・セットが完了したと工程１４４および工程１４５が判別した場合、工程１４５は制御を工程１５０に移す。グループ一貫性引数がＬＤＭコマンドで設定されていなかったと仮定して、それ以上のアクションは行われない。
【００７１】
グループ一貫性が必要とされる場合、「一貫性エクステント変換」方法が開始する。明らかとなるように、非一貫性エクステント変換および一貫性エクステント変換は、相互に排他的である。非一貫性エクステント変換と同様に、一貫性変換は連続した方法である。この方法は、工程１５０が、グループ内のすべてのデータ・セットのすべてのソース・エクステントを並行してロックする図７Ｃの工程１５１に制御を移すと開始する。次いで、工程１５２は、指定されたグループ内のすべてのソース・データ・セットおよびそれらのエクステントのメタデータを更新する。次の工程１５３は、エントリ７８、８２、８６、および９１などのエクステントおよびデータ・セット状態エントリを更新することによって、グループ内のすべてのデータ・セット、論理デバイスおよびエクステントの状態をＤＩＶＥＲＴＥＤ値に変える。これが完了すると、工程１５４は、グループ内のすべてのソース・エクステントのロックを解除する。次いで、制御は、グループ状態エントリ７８を更新することによって識別されたグループをＤＯＮＥとマークする図７の工程１５５に戻る。
【００７２】
このようにして、図７Ａ、７Ｂ、および７Ｃの手順を含む図７の移行および転換モジュールがその操作を完了すると、すべての入出力要求はターゲット論理デバイスに転換される。最終的に、転換方法はまた終了されうるので、移行されたデータ・セットに関連付けられているストレージ領域は他の目的に使用されうる。
【００７３】
論理データ移行−−入出力要求
ホスト・アプリケーションからの入出力要求の通常の処理と並行して論理データ移行を行うことの影響を最小化するため、エクステントが移行されている間であっても、データに対するそのようなホスト・アプリケーションからの入出力要求に引き続き応答することが必要である。監視モジュール５４は、この必要な機能を実行する。そのようなモジュールは、当技術分野において知られているように、監視モジュール５４により特殊処理に対する入出力要求を代行受信することによって操作することができ、１つの例は、本明細書に援用する米国特許出願第１０／２８３，９７６号明細書において開示されている。図８は、図１におけるＵＳＲ１アプリケーション３３またはＵＳＲ２アプリケーション３４などの、ユーザ・アプリケーションからの入出力要求に応答する監視モジュール５４のアクションを示す。
【００７４】
監視モジュール５４のこの実施形態はまた、複数のホストを有するシステムにおいて使用するように適合される。マルチホスト・システムにおいて、ホスト２１のような１つのホストは、「１次ホスト」または「オーナ」ホストと呼ばれる。「オーナ」は、特定のデータ・セット・グループの方法を管理するために最適なホストとしてグループのアクティブ化時に確立される。特に、実際のデータ移行のすべてではないとしても、移行の多くはオーナによって行われる可能性が高い。特定のコマンド機能は、オーナによってのみ満足されうるが、これはユーザには透過的にすることができる。図１のホスト２１Ａなど、その他のホストは「２次」または「非オーナ」ホストである。非オーナ・ホストは、最低限でも、結果のデータ・セットへの入出力要求を監視して、ミラーリングおよび転換段階にアクティブに参加する必要がある。各１次および２次ホストは、監視モジュール５４のインスタンスを使用して入出力要求を代行受信するが、その間データ移行方法は一部の小規模な変更で進行中である。したがって、複数ホストのアプリケーションにアクセス可能なエクステントからデータを移行することが可能である。
【００７５】
移行されているデータ・セットにおけるデータ転送の要求は、ＬＤＭアプリケーション５０に関連付けられている移行および転換モジュール５２を処理しているものと同じホスト２１から生じていると仮定し、工程１６０は、状態、アドレス、およびその他の情報をソース論理デバイス・データ構造から取得する工程１６１に制御を移す。工程１６０は、図７Ａの工程１２７において有用である変更の監視を含む操作を監視する方法を表している。監視モジュールが２次ホストとして動作している場合、工程１６０は、ターゲット論理デバイスの制御ブロック９５から状態およびその他の情報を取得する工程１６２に制御を移す。工程１６２は、工程１６１と類似している。この情報が取得されると、制御は工程１６３に移る。
【００７６】
工程１６３は、入出力要求が図６のエクステント状態エントリ９０内など、対応するエクステント状態エントリによって示されるような転換されたエクステント内のトラックに方向付けられているかどうかを決定する。方向付けられている場合、図８の工程１６３は、図６の状態およびその他の情報を使用してソース・トラック・アドレスをターゲット・トラック・アドレスに変換する工程１６４に進む。工程１６５は、受け取った入出力要求を、ターゲット論理デバイス内の対応するロケーションへの要求に再キャストする。工程１６６は、ターゲット論理デバイスでこの入出力要求を完了する。それ以上の移動はソース論理デバイス内のトラックでは発生しない。
【００７７】
ＤＩＶＥＲＴＥＤ状態への遷移中、個々のエクステントは、ＣＯＰＹまたはＭＩＲＲＯＲＥＤ状態のいずれかで存在する。その場合、工程１６３は、入出力要求が書き込みコマンドを含むかどうかを判別する工程１６７に進む。入出力要求が読み取りコマンドのみを含む場合、制御は、要求されたデータをソース論理デバイスから取り出す工程１７０に移る。ＤＩＶＥＲＴＥＤ状態への遷移に先立ち、読み取りコマンドがターゲット論理デバイス内のエクステントと対話する必要はない。次いで、読み取り専用入出力要求への応答が完了する。
【００７８】
エクステントへの書き込みコマンドがＤＩＶＥＲＴＥＤ状態へのエクステントの遷移に先立って入出力要求に含まれている場合、各書き込みコマンドは、ターゲット論理デバイス内の識別された各トラックがソース論理デバイス・トラックとの同期を維持できることを確実にするような方法で処理される必要がある。エクステントがＣＯＰＹ状態にある場合、工程１７１および工程１７２は、工程１７３に制御を移す。この工程において、監視モジュール５４は、工程１７４を使用して、識別されたトラックのみをソース論理デバイスで更新することにより各書き込みコマンドを完了する。しかし、工程１７３は、ＣＯＰＹビットおよびＳＹＮＣビットを、トラックが再度コピーされる必要があることを示す状態に更新する。その結果、変更されたデータは、その後ターゲット論理デバイスに転送される。これで、ＣＯＰＹ状態のエクステントを伴う書き込み操作への応答は完了する。
【００７９】
書き込まれるエクステントがＭＩＲＲＯＲＥＤ状態にある場合、工程１７４は再び、ソース論理デバイスに対する要求を完了する。並行して、工程１７１は、使用可能なマッピング・データを使用してターゲット論理デバイスへの要求を生成する工程１７５に制御を移す。工程１７６は、データをターゲット論理デバイス内の対応するトラックに書き込むことにより、ターゲット論理デバイスへの要求を完了する。したがって、データがＭＩＲＲＯＲＥＤエクステントに書き込まれる場合、図８の操作は、２つの結果のトラックに送信された変更済みデータが同一の状態を維持することを保証する。いずれの書き込み操作についても、工程１７７は、書き込み操作が完了したことを示す前に、両方の並行方法の完了を待つアクションを表す。
【００８０】
データ・セットのメタデータが、あるいは一貫性グループの場合は移行されるすべてのデータ・セットが更新されると、データ・セットの構成およびアドレスを識別する必要のあるすべての情報は、一度に、ターゲット・デバイス内の新しいロケーションを指し示すように変更される。しかし、いずれかのアプリケーションが開いている間、図８の転換操作は続行する。ただし、論理デバイス内のデータ・セット・エクステントがＤＩＶＥＲＴＥＤ状態であった後に、アプリケーションが停止されて開始される場合、つまりリサイクルされる場合、アプリケーションは、カタログ、ＶＴＯＣ、およびその他のテーブルなど、ストレージ・ロケーションに関する使用可能なさまざまな情報に基づいて新規または更新されたメタデータでデータ・セットを開く。その後、そのアプリケーションからの読み取り／書き込み要求は、ターゲット・デバイスと直接に対話する。これ以上、ソース論理デバイスと対話する必要、または図８に示される監視モジュール機能の操作の必要はない。
【００８１】
論理デバイス移行−−終了段階
データ移行の時点で稼働していたすべてのアプリケーションが移行後にいったん終了した場合、ソース・データ・セットを保持する必要はなくなる。この条件が存在する場合、システムは終了段階に入ることができる。図９に示されるように、終了モジュール５３は、方法の実行中に使用されうる遅延１８０を含む。工程１８１は、データ移行を引き続き稼働する前に任意のアプリケーションが開始したかどうかを判別するために検査を行う。すべてのアプリケーションはリサイクルされていない場合、工程１８２は、この検査を再度試行する前に任意の時間待機する工程１８０に制御を戻す。場合によっては、終了することが必要になることもあり、終了段階を完了するために論理データ移行に先立って開始した任意のアプリケーションを直ちに制限することもある。
【００８２】
いずれにしても、論理データ移行中にデータと対話していたすべてのアプリケーションが、移行が完了したのでいったん閉じられた場合、工程１８３は、図６に示されるデータ構造などの、論理移行アプリケーションのデータ構造を、データ処理システムのすべての関連する領域から削除する。次いで、工程１８４は、移行されたソース・エクステントのロケーションをその他の目的に使用できるように、ＶＴＯＣまたは同等のデータ構造を更新する。
【００８３】
前述の説明は、１つまたは複数のソース論理デバイスから１つまたは複数のターゲット論理デバイスへ、１つまたは複数のデータ・セットを移行する方法および装置の特定の実施形態に関連する。データ移行は、単一エクステントまたは複数エクステントの単一データ・セットを伴うことができる。さらに、データ移行は、一貫した方法でグループ内のすべてのデータ・セットの転送を実行するオプションを備えるデータ・セットのグループを伴うこともできる。いかなる形式であれ、移行は、データを並行して使用することもある他のアプリケーションに透過的である。方法は、そのようなユーザ・アプリケーションによって処理されるデータにおいて最小の中断しか伴わない。
【００８４】
本発明のさまざまな目的は、コマンドに応答する論理データ移行アプリケーションの利用により実現される。コマンドは、ソース論理デバイス内の移行されるすべてのエクステント、およびそれらのエクステントを受け取るターゲット論理デバイス内のロケーションを識別する。ソース・デバイス内の各エクステントに対してターゲット論理デバイス内に対応するアドレスがあるので、従来技術のデータ移行システムとは異なり、さまざまなエクステントおよびデータ・セットが単一の論理デバイスに転送されることが可能である。初期化時に、方法は、さまざまな制御データ構造を生成して取り込む。移行および転換中に、アプリケーションは、１つまたは複数のソース論理デバイスのエクステントをトラック・ベースまたはシリンダベースで、制御データ構造内のアドレス情報に基づいて、１つまたは複数のターゲット論理デバイスにコピーする。これらの操作中、監視モジュールは、この段階においては要求を処理することにより、書き込み操作の場合には制御データ構造内の情報を更新することにより、他のアプリケーションからエクステントへの入出力要求に応答する。
【００８５】
移行および転換中、ターゲット論理デバイス内の各エクステントは、連続した方法でソース論理デバイス内の対応するエクステントからミラーリングされる。この方法の実行中、まだコピーされていないトラックを、ユーザ・アプリケーションによって中断されることなく、ターゲット・デバイスにコピーするため、ミラーリングされているエクステントに一定時間にわたりロックがかけられる。連続の方法はエクステントに作用するので、中断がアプリケーションに影響を与える可能性は最小化される。エクステントがミラーリングされた後、監視機能は、ソース論理デバイスおよびターゲット論理デバイスを共に更新することにより、書き込み要求に応答する。
【００８６】
論理デバイス内データ・セット・エクステントまたは複数データ・セット内のデータ・セット・エクステントのグループがミラーリングされた後、移行および転換モジュールは、各エクステントをＤＩＶＥＲＴＥＤ状態に遷移させるが、そのタイミングはグループ一貫性の要件によって決まる。論理デバイス内のデータ・セット・エクステントが転換された後、監視機能は、すべての入出力要求を代行受信し、それらをターゲット・アドレスに再キャストして、要求を再発行する。
【００８７】
この転換操作は、アプリケーションがデータ・セットを閉じるときまで、任意のアプリケーションからのすべての入出力要求を処理するよう続行する。アプリケーションがそのデータ・セットを再び開いた場合、転換の時点において転換されたデータ・セットに関連するすべてのメタデータは更新されているので、入出力要求はターゲット論理デバイスに方向付けられる。
【００８８】
本発明は、特定の実施形態に関して開示された。開示された装置に対して、本発明を逸脱することなく多くの変更を加えることができることは明らかとなろう。たとえば、本発明は、本発明の譲受人から入手可能なＳｙｍｍｅｔｒｉｘデータ・ストレージ設備における本発明の特定の実施形態に関して説明された。しかし、本発明の論理データ移行を実施する基本的機能は、他の種類のデータ・ストレージ設備に容易に適合される。開示はさらに、図３に示されるような論理データ移行モジュールの編成、および図４、５、５Ａ、７、７Ａ、７Ｂ、７Ｃ、８、および９に示されるような特定の一連の操作への特定の参照を含む。これらの手順の変形および特定の工程ごとの具体的な機能は、別の種類のデータ・ストレージ設備により本発明を実施するため、または論理データ移行システムを他のアプリケーションと統合する目的で、または市販のオペレーティング・システムで使用可能な既存のユーティリティを使用するために変更されうる。さらに、本発明は、ソース・データ・ストレージ設備内の２つの論理デバイスとターゲット・データ・ストレージ設備内の単一論理デバイスとの間の特定の移動に関して説明された。本発明は、単一データ・ストレージ設備内で移行を実行することに対して同等に適用可能である。
【００８９】
図６が特定のデータ構造および編成を示すことは明らかとなろう。当業者であれば、この特定の構造および編成を実施する知識、または具体的に開示された構造および編成の実施に他の構造および編成を適用する知識を備えるであろう。
【００９０】
前述のように１つまたは複数の論理デバイスから異なる１つまたは複数の論理デバイスへデータを移行するようにシステムを動的に再構成する時期を決定するためのメトリクスを備えることは有用である。場合によっては、データを移行する決定は古いハードウェアの段階的廃止に従って行われることもあるが、データが格納されるデバイスのパフォーマンスが期待に応えていないときにデータを移行することが有用になる場合もある。
【００９１】
アイビーエムコーポレーション（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ）は、データ・セットが作成されたときに入力される基準に基づいてデータ・セットの割り当てを可能にするＤＦＳＭＳを提供する。たとえば、ユーザがデータ・セットの特定のパフォーマンス（たとえば、特定のミリ秒応答時間）を備えることに関心がある場合、ユーザは望ましいパフォーマンス特性をＤＦＳＭＳに入力して、望ましいパフォーマンス特性を満たすかまたはこれを超えるとされる適切なストレージ・デバイスを自動的に割り当てられる。しかし、このシステムには限界がある。まず第１に、最初の割り当て後にストレージ・デバイスがパフォーマンス要件を満たさない場合、データ・セットが別のアプリケーションによってアクセスされている間に、すでに割り当てられたデータ・セットを再割り当てするための機構は、ＤＦＳＭＳでは容易に提供されない。そのような場合、ユーザは、パフォーマンスの不足に気づき、新しいデータ・セット・スペースを別のデバイス上に手動で割り当て、そのデータ・セットにアクセスしているすべてのアプリケーションを終了して、古いデバイス上の古いデータ・セット・スペースから新しいデバイス上の新しいデータ・セット・スペースへデータを移動させる。さらに、時には、データ・セットの望ましいパフォーマンスは変化する。たとえば、ユーザは当初、４ミリ秒の応答時間を備えるデータ・セットを割り当てる場合がある。後に、ユーザは、状況の変化により、あるいはユーザが必要なパフォーマンスを過小評価していたために、３ミリ秒の応答時間のほうがより適切であると判断することもある。先の例の場合と全く同様に、ユーザは、パフォーマンスの不足に気づき、新しいデータ・セット・スペースを別のデバイス上に手動で割り当て、そのデータ・セットにアクセスしているすべてのアプリケーションを終了して、古いデバイス上の古いデータ・セット・スペースから新しいデバイス上の新しいデータ・セット・スペースへデータを移動させることになる。
【００９２】
したがって、データ・セットのパフォーマンスを自動的に監視して、パフォーマンスが適切ではない場合にデータ・セットを再割り当てできることが望ましい。さらに、データ管理目標などの、任意の他の適切な基準に基づいてデータ・セットを自動的に再割り当てできることが望ましい。
【００９３】
図１０を参照すると、流れ図２００は、本明細書に説明されるシステムと関連して実行される、自動的にデータ・セットのパフォーマンスを監視して適切な場合にデータ・セットを異なるデバイスに再割り当て（移動）する工程を示す。場合によっては、データ・セットは複数のデバイスにわたって分散されうることに留意されたい。したがって、データ・セットの一部（たとえば、特定のデバイス上の部分）のみを、他の部分を移動させることなく移動することが可能である。したがって、本明細書の説明では、データ・セットを再割り当て（移動）することはまた、データ・セットの一部のみを再割り当て（移動）することも示すことを理解されたい。
【００９４】
処理は、データ・セットが格納されているストレージ・デバイスの実際のパフォーマンスを測定する最初の工程２０２で開始する。ストレージ・デバイスのパフォーマンスを測定することは、極めて簡単明瞭であり、たとえば、デバイスによって直接提供されるか、またはストレージ・デバイスに関連付けられている他の値に基づいて特性を確認することによって提供されるパフォーマンス特性の記録を伴う。使用されうる可能なパフォーマンス特性については、本明細書の他の部分で説明される。
【００９５】
工程２０２に続くのは、工程２０２において測定された実際のパフォーマンスが望ましいパフォーマンスと比較されて、実際のパフォーマンスが望ましいパフォーマンスを満足するかまたはそれを上回るかどうか判別される工程２０４である。本明細書において使用される「パフォーマンス」は、本明細書の他の部分で説明されるデータ管理目標（たとえば、使用されるリモート・ミラーリングの種類）を含むように広義に解釈されうることに留意されたい。工程２０２と同様に、工程２０４は極めて簡単明瞭である。本明細書の他の部分において詳細に説明されているように、望ましいパフォーマンス特性のセットは、各データ・セットおよび／またはデータ・セットのグループに関連付けられうる。工程２０４に続くのは、工程２０４の比較の結果が良好である（つまり、実際のパフォーマンスが望ましいパフォーマンスを満足するかまたはそれを上回る）かどうかを判別する検査工程２０６である。比較の結果が良好ではない場合、つまり、実際のパフォーマンスがユーザの望ましいパフォーマンスを満足しないかまたはそれ以下になる場合、制御は、検査工程２０６から、データ・セットの新しいデバイスが選択される工程２０８に移る。工程２０８において新しいデバイスを選択することについては、本明細書の他の部分で詳細に説明される。工程２０８に続くのは、本明細書の他の部分で説明されている、データが移行される工程２０９である。
【００９６】
実際のパフォーマンスが望ましいパフォーマンスを満足するかまたはそれを上回る場合に、工程２０９に続く、または工程２０６に続くのは、プロセッサが待機する工程２１２である。工程２１２は任意であるが、流れ図２００におけるループのタイミングを制御するために便宜的に使用されうる。工程２１２に続いて、制御は、前述の工程２０２に戻る。
【００９７】
図１１を参照すると、流れ図２２０は、新しいデバイスが選択される図１０の流れ図２００の工程２０８を詳細に示す。流れ図２２０の処理は、デバイス索引ＤＩが１に設定される最初の工程２２２で開始する。デバイス索引ＤＩは、選択されうるすべての可能なストレージ・デバイスを通して繰り返すために使用される。工程２２２に続くのは、基準索引ＣＩが１に設定される工程２２４である。基準索引ＣＩは、どのデバイスが望ましい基準を満足するかしないか、またはそれを上回るか上回らないかを判別するために、すべての可能な基準を通して繰り返すために使用されうる。
【００９８】
工程２２４に続くのは、デバイス索引基準ＤＩが、可能なデバイスの数に対応するあらかじめ定められた値（工程２２６においてＤＩＭＡＸと呼ばれる）を上回るかどうかを判別する検査工程２２６である。上回る場合、制御は、工程２２６から、エラーが通知される工程２２８に移る。デバイス索引ＤＩが可能なデバイスの数を上回る場合、望ましい基準を満足するデバイスはないことに留意されたい。したがって、許容可能なデバイスがないことを呼び出しルーチンにアラートするために、工程２２８においてエラーが通知される。工程２２８の後、処理は完了する。
【００９９】
ＤＩがデバイスの数よりも大きくないことが検査工程２２６において判別された場合、制御は、検査工程２２６から、基準索引ＣＩが可能な基準の数に対応するあらかじめ定められた数（ＣＩＭＡＸ）を上回るかどうかを判別する検査工程２３２に移る。上回る場合、制御は、工程２３２から、ＤＥＶ［ＤＩ］と呼ばれる検査対象の特定のデバイスをルーチンが返す工程２３４に移る。システムがすべての基準を通して繰り返し、検査対象の特定のデバイスＤＥＶ［ＤＩ］が各基準を満足するかまたは上回る場合、ＣＩは、可能な基準の数（ＣＩＭＡＸ）を超えるまで引き続き増分されるが、その場合デバイスＤＥＶ［ＤＩ］は望ましい基準をすべて満足しているかまたは上回っていることに留意されたい。工程２３４の後、処理は完了する。
【０１００】
基準索引ＣＩが可能な基準の数を超えないことが検査工程２３２において判別された場合、制御は、検査工程２３２から、検査対象のデバイスＤＥＶ［ＤＩ］が特定の基準ＣＲＩＴ［ＣＩ］を満足するかまたは上回るかどうかが判別される検査工程２３６に移る。満足するか上回る場合、制御は、検査工程２３６から、基準索引ＣＩが増分される工程２３８に移る。工程２３８に続いて、制御は、前述の検査工程２３２に戻る。
【０１０１】
工程２３６においてデバイスＤＥＶ［ＤＩ］が特定の基準ＣＲＩＴ［ＣＩ］を満足しない場合、制御は、工程２３６から、デバイス索引ＤＩが増分される工程２４２に移る。したがって、工程２３６は、望ましい基準のすべてを満足しないデバイスを拒否する。工程２４２の後、制御は、別のデバイスの基準の繰り返しを開始するために基準索引ＣＩが１に設定される工程２２４に戻る。したがって、流れ図２２０の工程は、工程２２８によって証明されるように、望ましい基準のすべてを満足するデバイスがなくなるまで、または工程２３４によって証明されるように、すべての望ましい基準を満たすデバイスが少なくとも１つあるまで実行される。このようにして、望ましい基準を満足するデバイスがないことを示す工程２２８に到達するか、または望ましい基準をすべて満足する少なくとも１つのデバイスがあることを示す工程２３４に到達する。
【０１０２】
ＤＦＳＭＳに関連して前述されたミリ秒応答時間の基準に加えて、データ・セットまたはデータ・セットのグループのストレージ・デバイスを選択するために他の基準が使用されうる。その他の基準は、読み取りパフォーマンス時間、書き込みパフォーマンス時間、制御パフォーマンス時間、ミラー・パフォーマンス時間（つまり論理デバイスのミラーリングのパフォーマンス）、ストレージ・デバイスへの接続タイプ（たとえば、ＦＩＣＯＮ、ＥＳＣＯＮ、並列チャネル、ＩＰ接続ストレージなど）、ローカル・ミラーリング・タイプ（たとえば、ＲＡＩＤ１、ＲＡＩＤ５、ＲＡＩＤ１０など）、リモート・ミラーリング・タイプ（たとえば、Ｊ０／Ｊ１ ＲＤＦ、適応コピーＲＤＦ、ＳＲＤＦ／Ａ、ＳＡＲ、ＳＴＡＲ、ＰＰＲＣ（変形を伴う）など）、最大データ・セット・サイズ、日付依存パフォーマンス、バックアップ頻度、およびバックアップの回数を含む。本明細書において使用される「パフォーマンス」は、データ管理目標（たとえば、使用されるリモート・ミラーリングの種類）を含むように広義に解釈されうることに留意されたい。したがって、パフォーマンス基準は、ミラーリングの種類または最大データ・セット・サイズなどの事項を含むように広義に解釈されうる。一般に、パフォーマンス基準は、確認することができ、データ・セットが配置される可能性のあるストレージ・デバイス間で異なることもある、システムの任意の望ましい特性であってもよい。
【０１０３】
工程２０２においてパフォーマンスを測定し、工程２０４においてパフォーマンスを比較するために、適切な機構が使用される。したがって、たとえば、バックアップの頻度の基準が使用される場合、工程２０２における実際のパフォーマンス測定は、特定のストレージ・デバイスのバックアップの頻度であるが、工程２０４において実際の基準２０２と比較される値は、特定のデータ・セットまたはデータ・セットのグループについてユーザにより提供されるバックアップの望ましい頻度である。同様に、基準が接続タイプである場合、工程２０２において測定される実際のパフォーマンスは、工程２０４でデータ・セットまたはデータ・セットのグループについてユーザに望まれる（たとえば、ＥＳＣＯＮ）接続タイプと比較されるストレージ・デバイスへの実際の接続である。これらのさまざまな基準を測定し、これらのさまざまな基準を実際の基準と比較することは、当業者には簡単明瞭である。その他の任意の適切な基準も使用されうる。データ・セットおよび／またはデータ・セットのグループに関連付けられている望ましいパフォーマンスは、それ自体がデータ・セット内に格納されるか、または他の適切な手段によって保持されうることに留意されたい。同様に、測定される実際のパフォーマンスはまた、データ・セットに格納されるか、または他の適切な手段によって保持される。
【０１０４】
本明細書に説明されるシステムは、ＤＦＳＭＳによって提供されるクラスのセットと類似したクラスの並列セットを使用して、ＤＦＳＭＳと共に使用される。本明細書において説明される機能にＤＦＳＭＳを提供するためにフックとして使用される他の機構があってもよい。任意のデータ・セットを移行するかどうか判別するためにシステムが使用するパフォーマンス／管理規則をユーザが指定することができる機構を提供することにより、ＤＦＳＭＳを使用することなく本明細書に説明されるシステムを実施することも可能である。
【０１０５】
図１２を参照すると、流れ図２００’は、図１０の流れ図２００によって示される処理の代替実施形態を表している。図１２の流れ図２００’によって示される実施形態において、ユーザは、たとえ望ましいパフォーマンス（またはデータ管理特性）が満足されていないことをシステムが検出したとしても、移動を中止する選択肢を有する。流れ図２００の要素と同じ参照番号を有する流れ図２００’の要素は、類似した機能を実行するので、以下では説明されない。
【０１０６】
工程２０４の比較の結果が良好ではないことが検査工程２０６（前述）において判別される場合、制御は工程２０６から、データ・セットが移動されるべきであることを確認するプロンプトがユーザに表示される工程２６２に移る。工程２６２に続くのは、ユーザがデータ・セットの移動を中止することを決定したかどうか判別する検査工程２６４である。中止を決定した場合、制御は、工程２６４から、前述の工程２１２に移る。それ以外の場合、ユーザが移動を中止しないことを選択すると、制御は、工程２６４から、前述の工程２０８に移る。場合によっては、データ・セットが移動されないことをユーザが最初に示した後、あまり頻繁に（または絶えず）プロンプトがユーザに表示されないように、フラグを設定することが望ましいこともある。
【０１０７】
一部の実施形態において、ユーザがデバイスおよび／またはデータ・セットのサブセットの選択的な監視を要求することができる機構を提供することが可能であることに留意されたい。そのような機構は、システムによりアクセスされる構成ファイルの使用、ユーザへのプロンプト表示などを含む多くの方法で提供されうる。
【０１０８】
場合によっては、ディスクまたはテープ、あるいは他の媒体上のデータが危険にさらされる可能性があるという懸念もある。特にデータが数千の顧客の個人記録を含むような場合にはなおさらである。状況によっては、データを使用する任意のアプリケーションを変更する必要なく、データ暗号化を提供することが望ましい。以下で詳細に説明されるように、本明細書に説明されるデータ移行機構を使用して、そのようなアプリケーションに依存しない暗号化を提供することも可能である。
【０１０９】
図１３を参照すると、データ移行アプリケーション５０’は、アプリケーション５０’が、初期化モジュール５１、移行および転換モジュール５２、終了モジュール５３、および監視モジュール５４を含むという点において、図３のデータ移行アプリケーション５０と類似している。アプリケーション５０’はまた、データが移行されるときにデータを暗号化するために使用されうる暗号化モジュール３０２を含む。しかし、本明細書の他の部分で説明されるように、データはまた、別のロケーションに移行されることなく暗号化されうる。本明細書に説明されるシステムは、ディスク・ストレージ、テープ、ＤＶＤなどを含む、任意の種類のストレージ媒体またはデバイスとの間で、暗号化／復号化を提供することができる。
【０１１０】
本明細書の１つの実施形態において、暗号化モジュール３０２は一般に知られた、公的に提供されている暗号化／復号化アルゴリズムを使用することができる。たとえば、アルゴリズムは、暗号鍵が公的に周知で使用可能であり、復号鍵がデータの復号化に復号鍵を使用する１つまたは複数のエンティティによって秘密にされるようなものであってもよい。そのような暗号化／復号化システムの場合、公開暗号鍵の知識は、復号鍵および／または暗号化されていないテキストのアクセスまたは知識を提供しない。そのような暗号化／復号化技法の例は、アールエスエイシステムズ（ＲＳＡ Ｓｙｓｔｅｍｓ）［米国マサチューセッツ州ベッドフォード（Ｂｅｄｆｏｒｄ）所在］によって提供される公開鍵暗号化を含む。
【０１１１】
他のシステムも、暗号化／復号化に使用されうる。たとえば、暗号化／復号化は、ＩＢＭによって提供されるＳ／３９０システムなど、ＩＢＭ Ｃｏｍｍｏｎ Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＣＣＡ）を使用する１つまたは複数のシステムによって提供されうる。公開鍵に依存しないが、代わりに秘密鍵のみを使用する他のシステムも使用されうる。そのようなシステムでは、復号時に鍵の暗号漏洩を防ぐために講じられる対策が、暗号化の時点でも鍵に適用されうる。
【０１１２】
図１４を参照すると、平文（暗号化されていない）データを暗号化モジュール３０２に提供する入力を有するものとして、暗号化モジュール３０２が詳細に示される。暗号化モジュール３０２はまた、暗号鍵を入力として受け取る。本明細書の他の部分で説明されるように、暗号鍵は、公的に周知で使用可能であるため、特殊な処理またはボールトを必要としないこともある。図１４はまた、暗号化モジュール３０２の出力が暗号化データであることも示す。操作中、暗号化されていないデータは、暗号鍵と共に暗号化モジュール３０２への入力として提供される。暗号化モジュール３０２は、多くの周知の公的に使用可能な公開鍵暗号化アルゴリズムのうちのいずれかを使用して、データを暗号化することができる。
【０１１３】
図１５を参照すると、流れ図３１０は、データ移行が本明細書に説明される暗号化と結合されるときにデータ移行の一部に関連して実行される工程を示す。流れ図３１０の工程は、トラックがソース論理デバイスからターゲット論理デバイスにコピーされる図７Ａの流れ図の工程１３１に関連して実行される。流れ図３１０の工程はまた、図７Ａの流れ図の工程１３７に関連して実行される。工程１３７において、残りのデータは、データ移行に関連してソース論理デバイスからターゲット論理デバイスにコピーされる。
【０１１４】
流れ図３１０の処理は、暗号鍵が取得される最初の工程３１２で開始する。本明細書の他の部分で説明されるように、暗号鍵は、公的に使用可能で周知であり、ボールトされるかまたは秘密にされる必要はない、公開鍵暗号方式を使用することが可能である。工程３１２に続くのは、ソース論理デバイスからターゲット論理デバイスにコピーされているデータに暗号鍵が適用される工程３１４である。工程３１４に続くのは、暗号化されたデータがターゲット論理デバイスに提供される工程３１６である。工程３１６の後、処理は完了する。
【０１１５】
本明細書の他の部分で説明されるように、このように暗号化されたデータの復号化は、復号鍵が秘密にされる必要があるため、いくぶん複雑になる。本明細書の他の部分で説明されるように、復号鍵の秘密性を保持するいくつかの技法がある。本明細書に説明されるシステムの場合、暗号鍵は、データを格納するストレージ・デバイス内に保持されるか、またはデータ移行アプリケーションで保持されて、悪意のある（無許可の）ユーザが暗号化されたデータをテープまたは他の媒体にコピーしようとするか、またはストレージ・デバイスから１つまたは複数のドライブを削除しようとした場合に、暗号鍵はストレージ・デバイスまたはデータ移行アプリケーションで保持されているので許可のあるユーザにしか使用できないため、暗号化されたデータは使用不可能になるようになっている。これを実施するために使用されうる機構については、本明細書の他の部分で説明される。
【０１１６】
図１６を参照すると、流れ図３２０は、データ暗号化に関連して実行されうる工程を示す。処理は、データが秘密鍵を使用して復号化される最初の工程３２２で開始する。工程３２２においてデータを復号化することについては、本明細書の他の部分で詳細に説明される。工程３２２に続くのは、復号化されたデータがストレージ・デバイスの許可ユーザに提供される工程３２４である。工程３２４の後、処理は完了する。
【０１１７】
本明細書において説明されている機能は、別のロケーションへのデータ移行、「同所」データ移行（本明細書の他の部分で説明）に関連して、または１つまたは複数のボリューム、ファイル、および／またはその他の種類のストレージ・ユニットのストレージ方法の一部として実施されうることに留意されたい。たとえば、ユーザは、機密データを格納するために特定の論理ボリュームを作成することも、そのボリュームに格納されるデータを常時暗号化するようシステムを構成することもできる。その場合、システムは、暗号化されるためにデータがそのボリュームに書き込まれるようにし、復号化されるためにデータが（許可ユーザによって）そのボリュームから読み取られるようにする。本明細書の他の部分で説明される用に、暗号化／復号化は、ホスト上で稼働しているアプリケーションには透過的な方法で実行されうる。たとえば、暗号化／復号化機能は、ストレージ・デバイス上で提供される。代替として、暗号化／復号化機能は、暗号化および復号化を行うために、ストレージ・デバイスからのホストの読み取りおよびストレージ・デバイスへのホストの書き込みを代行受信する方法を使用して、１つまたは複数のホスト上で提供される。
【０１１８】
図１７Ａを参照すると、図３４０は、ストレージ・デバイスが不正改ざん防止モジュール３４２を含む実施形態を示す。図３４０はまた、ストレージ・デバイスの内部にあるメモリ３４６に結合された複数のディレクタ３４４ａ〜３４４ｃを示す。ディレクタ３４４ａ〜３４４ｃはそれぞれ、ホスト・アダプタ、ディスク・アダプタ、および／またはリモート・アダプタを表すことができる。本明細書の実施形態において、最大１６のディレクタがメモリ３４６に結合されうる。もちろん、他の実施形態では、使用されうるディレクタの最大数がこれよりも多いかまたは少ない場合もある。
【０１１９】
３４０で表される図はさらに、ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２の間の代替通信パスを提供するオプションの通信モジュール（ＣＭ）３４８を示す。ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２のうちのいずれかが、メモリ３４６を経由する必要なくメッセージおよび／またはデータを他のディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４４のいずれかに送信することができるように、各ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２はＣＭ３４８に結合される。ＣＭ３４８は、ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２の１つを送信することで適切なアドレスを供給し、メッセージおよび／またはデータがディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２のうちの１つの意図された受信側によって受信されるようにする標準的なＭＵＸ／ルータ技術を使用して実施される。加えて、ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２の１つを送信することで、他のディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２のすべてに同時にメッセージをブロードキャストすることが可能になる。
【０１２０】
図１７Ｂを参照すると、３５０で表される図は、ストレージ・デバイス３５６に結合された複数のホスト３５２〜３５４を含む実施形態を示す。ホスト３５２〜３５４はそれぞれ、相互に独立しているストレージ・デバイス３５６と対話することができる。代替として、ホスト３５２〜３５４の一部または全部は、一斉にストレージ・デバイス３５６と対話することができる。３５０で表される図は、ホスト３５２が不正改ざん防止モジュール３４２を含むが、ホスト３５４は独自のバージョンの不正改ざん防止モジュール３４２’を含むことを示す。３５０で表される図によって示される実施形態において、不正改ざん防止モジュール３４２、３４２’の機能は、ストレージ・デバイス３５６（図１７Ａの図３４０によって表される）から、ホスト３５２〜３５４の各々に移動される。
【０１２１】
ホスト３５２〜３５４のすべてが不正改ざん防止モジュールを有することは必要ではないことに留意されたい。たとえば、３５０で表される図は、不正改ざん防止モジュールを含まないものとして３５３のホストを示す。一部の実施形態において、本明細書に説明される暗号化／復号化機能を実行するホストに不正改ざん防止モジュールを備えることだけが必要である。また、暗号化はストレージ・デバイスまたはホストの１つのいずれでも実行させることは可能であるが、暗号化はもう一方の側で実行されること、そして一般に本明細書に説明される機能は、適切なデバイスまたはデバイスの組み合わせで提供され、操作中であっても移動されうることに留意されたい。
【０１２２】
特定のボリューム、ファイル、または他のストレージ・ユニットに対してデータが常時暗号化される（つまり、データが、作成時点およびその後に暗号化される）ような場合において、ホストとストレージ・デバイス間のデータの平文伝送を防止するために不正改ざん防止モジュール３４２をホストに備えることは有利となることに留意されたい。一方、（同所でまたは別のロケーションへの）データ移行に関連してデータが暗号化されるような場合は、ストレージ・デバイスの一部として不正改ざん防止モジュール３４２を備えることが有利となりうる。もちろん、不正改ざん防止モジュールを、ストレージ・デバイスの一部と１つまたは複数のホストの一部に共に備えることも可能である。加えて、本明細書に説明される機能を、ストレージ・デバイスおよびホストの両方から分離するかまたは少なくとも部分的に分離して提供することも可能である。
【０１２３】
図１７Ａに関連して説明された実施形態および図１７Ｂに関連して説明された実施形態（およびその他の実施形態）について、不正改ざん防止モジュール３４２は、不正改ざん防止モジュール３４２内部のデータの検査を許可しないハードウェア、ソフトウェア、またはそれらの組み合わせを使用して実施される。たとえば、不正改ざん防止モジュール３４２がハードウェア（たとえば、シングル・チップ）を使用して実施される場合、ハードウェアは、誰かがハードウェアを開こうと試みるごとにアクティブ化される自動消滅機構を備えてもよい。不正改ざん防止モジュールは、本明細書の他の部分で説明される、ＩＢＭによって提供される（ｚ／３９０システム（ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ））を使用して実施される。
【０１２４】
図１８を参照すると、図３６０は、不正改ざん防止モジュール３４２のコンポーネントを示す。不正改ざん防止モジュール３４２は、ハードウェア、ソフトウェア、またはその適切な組み合わせを使用して実施されうることに留意されたい。不正改ざん防止モジュール３４２が、ソフトウェアおよび／または大量のソフトウェアを使用して実施される場合、ストレージ・デバイスは、不正改ざん防止モジュール３４２への特定のアクセスのみを許可するように構成されうる。
【０１２５】
３６０で表される図は、鍵データベース３６２および復号モジュール３６４を含むものとして不正改ざん防止モジュール３４２を示す。鍵データベース３６２は、データの暗号化および復号化に使用されるすべての公開鍵／秘密鍵のペアを含むことができる。不正改ざん防止モジュール３４２は、出力として、鍵データベース３６２からの公開鍵（ただし公開鍵のみ）を提供する。本明細書の他の部分で説明されるように、公開鍵は、秘密ではなく、データを暗号化したいと望むエンティティには既知であるかまたは認識可能である。
【０１２６】
鍵データベース３６２に格納されている公開鍵／秘密鍵ペアの秘密鍵は、復号モジュール３６４に提供される。復号モジュール３６４は、不正改ざん防止モジュール３４２の外部から暗号化されたデータを受け取り、不正改ざん防止モジュール３４２の出力として復号化されたデータ（平文データ）を提供する。本明細書の実施形態において、鍵データベース３６２、復号モジュール３６４、またはそれらの間のデータ通信パスには、外部アクセスは全く提供されない。これは、開かれた場合に自動消滅する不正改ざん防止ハードウェア（たとえば、チップ）を使用して実施されうる。代替として、鍵データベース３６２、復号モジュール３６４、および／またはそれらの間のデータ・パスへのアクセスを禁止するソフトウェア／システムの実装があってもよい。
【０１２７】
一部の実施形態において、構成モジュール３６６は、データを鍵データベース３６２に提供するために使用されうる。構成モジュール３６６は、適切に安全であり、許可のあるユーザにのみアクセス可能にすることができる。構成モジュール３６６を使用する実施形態において、構成モジュール３６６のみが、鍵データベース３６２に公開鍵／秘密鍵ペアを提供することができる。そのような機構を備えることで、悪意のあるユーザが、データに不正アクセスするために、その独自の公開鍵／秘密鍵ペアを鍵データベース３６２に提供しないよう防止する。
【０１２８】
構成モジュール３６６を備えているかどうかにかかわらず、エンティティが鍵データベース３６２にデータを書き込むことのみを許可され、データを読み取ることを許可されていない限り、合法的に生成された公開鍵／秘密鍵ペアが危険にさらされることは困難になることに留意されたい。
【０１２９】
本明細書において説明されているシステムは、論理データ移行の後に、（許可ユーザによって）暗号化されたデータの読み取りで、不正改ざん防止モジュール３４２を使用してデータを復号化するような論理データ移行に関連して実施されうる。他の機構が、暗号化されたデータを管理するために使用されうることにも留意されたい。たとえば、ストレージ・システム上に格納されるデータがすべて常時暗号化された状態になるように、データがストレージ・デバイスに書き込まれるときは常に暗号化され、ストレージ・デバイスから読み取られるときは常に復号化されるようなシステムを備えることが可能である。そのような機構は、ユーザがデータを暗号化するかしないかを選択できるように、オプションのフラグによってアクティブ化されてもよい。さらに、本明細書において説明されるシステムは、データの読み取りおよび書き込みを行うストレージ・デバイスのマイクロコードを含む、あらゆるコードのレベルにおいて実装されうることに留意されたい。システムは、書き込まれるデータが暗号化され、（許可ユーザによって）読み取られるデータが復号化されるように、データ読み取りおよびデータ書き込みを代行受信することによって実施されうる。
【産業上の利用可能性】
【０１３０】
本明細書に説明されるシステムは、たとえばデータ圧縮を含む、他の任意のデータ変更アルゴリズムに加えて実装されてもよい。暗号モジュールおよび復号モジュールはデータを同時に圧縮することができ、かつ／またはデータは暗号化／復号化の前または後までに圧縮される。さらに、一部の実施形態について、暗号化／復号化アルゴリズムがユーザ独自のカスタマイズ・アルゴリズムを提供するユーザにしか知られないように、ユーザがデータの暗号化および復号化にカスタマイズ・モジュールを提供し、システムが読み取りおよび書き込み（およびデータ移行）のデータ・ストリームを代行受信するフックを提供する暗号化／復号化がユーザ・モジュールによって提供される。本明細書の実施形態において、暗号化されたデータは、復号化されたデータと同じサイズである。
【０１３１】
本明細書に説明されるシステムは、データが特定のロケーションから読み取られ、暗号化された後、同じロケーションに戻される「同所」データ移行を使用して実施されうる。そのようなシステムにおいて、各ブロックが暗号化されるかどうかを示すために、フラグ（または他の適切な機構）が使用されてもよい。もちろん、データを別のロケーションに移動せざるを得ない状態を避けるために、暗号化されたデータが暗号化されていないデータと同じサイズであれば有益である。また、特定のブロックがすでに暗号化されているかどうかを示すインジケータ（たとえばフラグ）の値に応じて、各ブロックが復号化されることも復号化されないこともある、そのような「同所」移行が発生している間にファイル（またはボリューム）をアクセス可能にできることにも留意されたい。「同所」移行が完了すると、ファイル（またはボリューム）のすべてのデータは暗号化されて、インジケータを確認する必要はもはやなくなる。
【０１３２】
セキュリティを追加するために、公開鍵／秘密鍵ペアがストレージ・デバイスによって認識される機関によりデジタル署名される必要があることを要求することができる。したがって、公開鍵が公認の機関（たとえば、ＰＫＩ ＣＡ）によってデジタル署名されていない限り、すべての公開鍵／秘密鍵ペアを拒否する機構があるので、鍵データベース３６２に独自の公開鍵／秘密鍵ペアを書き込もうと試みる悪意ある（無許可の）ユーザは困難におちいる。一部の実施形態において、セキュリティを追加するために、機関は、証明書が改ざんされていない（つまり引き続き有効である）ことを示す独自のデジタル証明書および証拠を提示することを要求されうる。そのような証拠は、Ｘ−５０９ ＰＫＩ ＣＲＬの形態をとるか、またはデジタル証明書が失効していないことを証明する他の適切な機構であってもよい。一部の実施形態において、機関によって提示されるデジタル証明書は、公開鍵／秘密鍵ペアの一部である公開鍵を含むこともできる。
【０１３３】
したがって、前述のすべての説明と、本発明の真の精神および範囲にあるその他の変形および変更を対象とすることは、添付の特許請求の範囲の目的である。
【図面の簡単な説明】
【０１３４】
【図１】本発明から利益を享受することができ、複数データ・ストレージ設備を含む複数ホスト・データ処理システムを示すブロック図。
【図２】アプリケーションとデータ・セットとの間の標準的な従来技術の対話を示す流れ図。
【図３】本発明により動作する論理移行アプリケーションの編成を示すブロック図。
【図４】コマンドに応答する論理移行アプリケーションの動作を示す流れ図。
【図５】図３に示される初期化モジュールの動作を示す流れ図。
【図５Ａ】図５に示される動作を示す詳細な流れ図。
【図６】図５に示される初期化モジュールによって生成されたデータ構造の１つの例を示すブロック図。
【図７】図３に示される移行および転換モジュールの動作を示す流れ図。
【図７Ａ】図７に示される動作を示す詳細な流れ図。
【図７Ｂ】図７に示される動作を示す詳細な流れ図。
【図７Ｃ】図７に示される動作を示す詳細な流れ図。
【図８】図３に示される監視モジュールの動作を示す流れ図。
【図９】図３に示される終了モジュールの動作を示す流れ図。
【図１０】動的データ・セット移行を実行するかどうかを決定する工程を示す流れ図。
【図１１】データ・セット移行に対するターゲット論理デバイスの選択を示す流れ図。
【図１２】動的データ・セット移行を実行するかどうかを決定する代替実施形態を示す流れ図。
【図１３】本発明により動作する論理移行アプリケーションの代替実施形態の編成を示すブロック図。
【図１４】本明細書において説明されるシステムによる暗号化モジュールの実施形態を示す図。
【図１５】データ移行が本明細書に説明される暗号化と結合されるときにデータ移行に関連して実行される工程を示す流れ図。
【図１６】本明細書に説明されるシステムによるデータ暗号化に関連して実行されうる工程を示す流れ図。
【図１７Ａ】ストレージ・デバイスが不正改ざん防止モジュールを含む実施形態を示す図。
【図１７Ｂ】複数のホストデバイスが各々不正改ざん防止モジュールを含むことができる実施形態を示す図。
【図１８】本明細書に説明されるシステムの実施形態による不正改ざん防止モジュールのコンポーネントを示す図。
【技術分野】
【０００１】
本発明は一般に、データ・ストレージ設備に関し、具体的には、データ・ストレージ設備内のデータの暗号化に関する。
（関連出願の相互参照）
本出願は、２００４年６月１８日に出願した米国特許出願第１０／８７２，０７４号明細書（係属中）の一部継続出願である２００４年１０月１日に出願した米国特許出願第１０／９５６，４８４号明細書（係属中）の一部継続出願である。
【背景技術】
【０００２】
データ・ストレージ設備は一般に、物理ストレージ媒体および関連するコントロールを含むディスク・アレイ・ストレージ・デバイスを備える。たとえば、標準的なディスク・アレイ・ストレージ・デバイスは一般に、物理ストレージ媒体として複数の物理ディスク・ドライブを含む。コントロールは、キャッシュ・メモリ、相互接続バス、およびアダプタを含む。少なくとも１つのホスト・アダプタは、ホスト・プロセッサ、つまり「ホスト」とバスとの間を接続する。複数のディスク・アダプタは、バスと物理ディスク・ドライブとの間のインターフェイスとして機能する。
【０００３】
ホストによって処理されているアプリケーションの観点からすれば、ディスク・ストレージは通常、「論理デバイス」内に構成される。そのような「論理デバイス」はまた、「論理ストレージ・デバイス」、「論理ボリューム」、および「デバイス」としても知られている。以下の説明では、「論理デバイス」を使用する。各論理デバイスは、単一の物理ディスク・ドライブの一部、または全体に構成されることがある。論理デバイスはまた、複数の物理ディスク・ドライブ上に構成されることもある。論理デバイスは、ファイルとも呼ばれる、１つまたは複数の「データ・セット」を格納する。各データ・セットは、１つまたは複数のエクステントを備える。エクステントは、通常ディスク・ストレージ・システム内の連続するシリンダまたはトラックである、１つまたは複数の連続ストレージ・ロケーションによって定義される。複数のデータ・セットは、「グループ」と呼ばれることがある。
【０００４】
オペレーティング・システムは、制御ルーチンおよびデータ構造を提供して、ホスト・アプリケーションとデータ・ストレージ設備の仲介をする。ホスト・アプリケーションからの入出力要求は一般に、「読み取り」または「書き込み」操作のような操作を定義し、論理デバイスは、それぞれデータが取り出される（読み取られる）元、または送り出される先（書き込まれる）の論理ストレージ・ロケーションをアドレス指定する。
【０００５】
たとえば、ＩＢＭベースのシステムは、アクセス方式、装置制御ブロック（ＵＣＢ）、および各論理デバイスに割り当てられている関連構造を含むＭＶＳ（アイビーエムコーポレーション（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ）の登録商標）オペレーティング・システムを使用する。オペレーティング・システムの入出力制御ルーチンは、これらの装置制御ブロックを使用して、アプリケーションによって提供された論理デバイス・アドレスを、ストレージ設備によって認識される接続ベースのアドレス指定に変換する。ボリューム目録（ＶＴＯＣ）内にあるようなメタデータは、特定のデータ・セットに割り当てられたその論理デバイス上で複数エクステントによって占有された正確なシリンダおよびヘッドの範囲を提供する。単一のエクステントは単一論理デバイス内の連続ストレージ・ロケーションを占有するが、そのようなオペレーティング・システムは、データ・セット内の個々のエクステントを多数の論理デバイスにわたって分散することができる。
【０００６】
格納されるデータの量が増大するのに応じて、既存のデータ・ストレージ設備内のデータの量は最大容量に近づいてゆく。その容量を追加することは、さらに大容量の高いパフォーマンスを備える新しいデータ・ストレージ設備の追加を伴う。したがって、既存のデータ・ストレージ設備を新しいデータ・ストレージ設備の追加で置き換えるか、または補うことが望ましくなっている。結果として生じるパフォーマンスの向上によって利益を得るには、古いデータ・ストレージ設備から１つまたは複数の新しいデータ・ストレージ設備へのデータの移動が必要になることが多い。
【０００７】
さらに、新しいストレージ設備内で個々の論理デバイスの記憶容量を増大させるという長期傾向もある。その１つの理由は、現在のオペレーティング・システム内の装置制御ブロックアドレスの数にアーキテクチャ上の制限があることである。これは、拡張ストレージをサポートするＵＣＢの自由な増設を妨げる。この状況は、単一の論理デバイスのアドレス指定に対して複数のＵＣＢが占有になることを求める特定のスループット最適化方法によってさらに悪化する。たとえば、現在使用可能なシステムは、単一の論理デバイスをアドレス指定するために複数の装置制御ブロックを使用して重複したアクセスを提供する。ビシリツキーら（Ｖｉｓｈｌｉｔｚｋｙ ｅｔ ａｌ．）が取得した米国特許第６，６６５，７３９号明細書では、並列アクセス装置制御ブロックを使用することにより、単一論理デバイスへの重複した入出力要求に関して規定が設けられた機能拡張を開示する。１つのアプリケーションへの並列アクセス装置制御ブロックの各割り当ては、その他の目的に使用可能な装置制御ブロックの数を減少させる。
【０００８】
ポリシーにおけるさまざまな機能拡張および変更は、可能であれば装置制御ブロックの数を節約する必要性を高めている。１つの節約の手法は、複数の小型論理デバイスから１つの大型論理デバイスにデータを統合することである。そのような手法では、既存の論理デバイスから同一または異なるデータ・ストレージ設備内の１つの論理デバイスへデータが移動されることが必要となる。しかし、また、移動または移行されるデータの通常のデータ処理アクティビティを中断することなく、そのような転送が透過的に発生することは、不可欠ではないとしても、目標である。
【０００９】
そのような透過的な並列の移動または移行を提供するために多くの努力がなされてきた。たとえば、アトキン（Ａｔｋｉｎ）が取得した米国特許第６，１４５，０６６号明細書では、完全論理デバイス間のデータの透過的な移行のための方法を開示する。この特許の開示により、ソース論理デバイス内のデータは、マルチフェーズ・プロセスでターゲット論理デバイスに転送される。基本的に、コピー・サブタスクは、データをターゲット論理デバイスにコピーすることによって、ソース論理デバイスのワン・パスを完了する。各タスク中に、ユーザ・アプリケーションは、ソース論理デバイス内のデータと引き続き対話を行う。コピー・サブタスクがワン・パスを終了した後、リフレッシュ段階では、ソース論理デバイスに行われた変更を分析して、変更されたデータをターゲット論理デバイスにコピーする。このリフレッシュ段階は、変更の数があらかじめ定められたしきい値を下回るまで、繰り返し形式で続行する。次に、システムは、ソース論理デバイスへの入出力要求を静止させて、ユーザ・アプリケーションとその論理デバイスとの間のさらなる対話を妨げる。静止中に、残りの変更されたデータは、ターゲット論理デバイスに移動する。次に、スワップ操作は、ターゲット論理デバイスが新しいソース論理デバイスになるようにする。つまり、スワッピング操作が完了した後、ユーザ・アプリケーションとの通信は再び有効になり、静止状態は終了して、ユーザ・アプリケーションと新たなソースとなったターゲット内のデータとの間の対話が可能になる。
【００１０】
前記のように、そのようなデータ移行は、論理デバイス内のすべてのデータに制限される。新しい論理デバイスは、ソース論理デバイスよりも大きい容量を有することもあるが、ソース論理デバイスからのデータは、基本的に損なわれることなくターゲット論理デバイスに転送される。システムは、論理デバイス内のエクステントのデータの処理、または１つの論理デバイス内の異なる論理デバイスからのデータ・エクステントの組み合わせについて提案を行うことはない。
【００１１】
オフェクら（Ｏｆｅｋ ｅｔ ａｌ．）が取得し、本発明の譲受人に譲渡された米国特許第６，３５６，９７７号明細書では、オンラインのリアル・タイム・データ移行のシステムおよび方法を開示する。この特許によれば、置換データ・ストレージ設備は、既存データ・ストレージ設備とホスト・オペレーティング・システムまたはネットワークとの間を接続する。置換データ・ストレージ設備は、移行されるよう指定されたすべての論理デバイスに対するすべての入出力要求を処理する。バックグラウンドのコピー操作は、既存データ・ストレージ設備内の指定された論理デバイスから、置換データ・ストレージ設備内の対応する論理デバイスにデータを移動する。バックグラウンド操作によってデータがまだ移行されていないロケーションへの任意の入出力要求は、優先度ベースで処理され、その特定のロケーションに関して移行が発生したことを示すように状態が更新される。このシステムは基本的に、移行されている論理デバイスを静止させる必要を最小化する。しかし、これはまた、完全論理デバイスの移行に制限される。
【００１２】
前述のアトキン（Ａｔｋｉｎ）およびオフェクら（Ｏｆｅｋ ｅｔ ａｌ．）の特許は、論理デバイス全体を移動するデータ移行システムの例である。これらは、１つまたは複数のソース論理デバイスから、単一のターゲット論理デバイスまたは複数のターゲット論理デバイスへと、エクステント単位ベースで、１つまたは複数のデータ・セットを移行するように適合されていない。これらは、特に論理デバイス内の一部のエクステントが移行中で、他のエクステントは移行されていない場合、ディスク・アレイ・ストレージ・デバイスの論理ボリュームの所定の数に割り当てられる必要のある装置制御ブロックの数を減少させることはできない。
【００１３】
加えて、格納されるデータは機密の場合もあり、許可されたユーザを除いてはアクセス可能にすべきではない。たとえば、オンライン・ベンダまたは銀行の顧客リストは、顧客名および住所、さらにアカウント番号を含むことがある。ストレージ・デバイス上のデータへのアクセスを制限することは可能であるが、情報は、危険にさらされる可能性もあるテープにバックアップされることもある。さらに、場合によっては、悪意のあるユーザが、ディスク上のデータにアクセスを試みて、ストレージ・デバイスのセキュリティを無効にするために、物理的にディスクを移動させることができる。同様のさまざまな場合において、データへのアクセスを許可された者を除いては、データが使用可能にならないとすれば、それは有用なことであろう。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
したがって、１つの論理デバイスからもう１つの論理デバイスへ、論理デバイスよりも小範囲にわたる１つまたは複数のデータ・エクステントを移行する方法および装置を提供することは、本発明の目的である。
【００１５】
本発明のもう１つの目的は、複数のソース論理デバイスから１つまたは複数のターゲット論理デバイスへ、複数のデータ・エクステントを移行する方法および装置を提供することである。
【００１６】
本発明のさらにもう１つの目的は、ユーザ・アプリケーションと移行されているデータ・エクステントとの間の操作に透過的にデータ・エクステントを移行する方法および装置を提供することである。
【００１７】
本発明のさらにもう１つの目的は、複数の論理デバイスを統合するためにデータ・エクステントを動的に複製することにより、データを移行する方法および装置を提供することである。
【００１８】
本発明のさらにもう１つの目的は、論理デバイスの部分のみからデータ・エクステントを動的に複製することによりデータを移行する方法および装置を提供することである。
【課題を解決するための手段】
【００１９】
本発明によれば、ソース論理デバイス内のデータ・セット・エクステントのデータ移行方法は、それぞれソース論理デバイスおよびターゲット論理デバイスのデータ・エクステントの既存のロケーションおよび将来のロケーションを識別して格納する制御データ構造を生成することによって達成される。ソース論理デバイス内の各データ・セット・エクステントは、ターゲット論理デバイスにミラーリングされたエクステントを生成するためにコピーされる。この状態の間、ソース論理デバイスにデータを書き込むよう求める要求は、ソースおよびターゲット論理デバイスの両方に方向付けられる。ソース論理デバイス内のすべてのデータ・セット・エクステントがミラーリングされると、すべての対応するメタデータは状態を確立するように更新され、それにより識別されたエクステントへのデータ要求は１つまたは複数のターゲット論理デバイス内の対応するロケーションに転換される。
【００２０】
さらに本発明によれば、いつデータ・セットを移行すべきかを決定する工程は、データ・セットのパフォーマンス基準を提供する工程と、データ・セットの実測パフォーマンスを提供するためにデータ・セットのパフォーマンスを測定する工程と、データ・セットがパフォーマンス基準に従って実行していないことを実測パフォーマンスが示す場合に、データ・セットを移行する新しいロケーションを選択する工程と、データ・セットを新しいロケーションに移行する工程とを含む。データ・セットを移行する工程は、他のアプリケーションがデータ・セットにアクセスしているかどうかにかかわりなく、データ・セットを新しいロケーションに移動する工程を含むことができる。新しいロケーションを選択する工程は、複数のロケーションの各々を分析して、その予測パフォーマンスがパフォーマンス基準に従っているかどうかを判別する工程を含むことができる。いつデータ・セットを移行するかを決定する工程は、データ・セットが操作可能にされた後にパフォーマンス基準を調整する工程を含むことができる。パフォーマンス基準は、応答時間、読み取りパフォーマンス時間、書き込みパフォーマンス時間、制御パフォーマンス時間、および日付依存パフォーマンス時間からなるグループから選択されてもよい。パフォーマンス基準は、データ管理目標を含むことができる。データ管理目標は、接続タイプ、ローカル・ミラーリング・タイプ、リモート・ミラーリング・タイプ、および最大データ・セット・サイズからなるグループから選択されてもよい。
【００２１】
さらに本発明によれば、いつデータ・セットを移行すべきかを決定する工程は、データ・セットのパフォーマンス基準を提供する工程と、データ・セットの実測パフォーマンスを提供するためにデータ・セットのパフォーマンスを測定する工程と、データ・セットがパフォーマンス基準に従って実行していないことを実測パフォーマンスが示す場合に、データ・セットが移動されることを確認するメッセージをユーザにプロンプト表示する工程と、データが移動されることをユーザが確認する場合に、データ・セットを移行する新しいロケーションを選択する工程と、データ・セットを新しいロケーションに移行する工程とを含む。いつデータ・セットを移行するかを決定する工程はまた、データ・セットが移動されることをユーザが確認しない場合に、その現在のロケーションにデータ・セットを保持する工程を含むことができる。いつデータ・セットを移行するかを決定する工程はまた、データ・セットが移行されることをユーザが確認しなかった後にフラグを設定する工程を含むことができる。データ・セットを移行する工程はまた、他のアプリケーションがデータ・セットにアクセスしているかどうかにかかわりなく、データ・セットを新しいロケーションに移動する工程を含むことができる。新しいロケーションを選択する工程は、複数のロケーションの各々を分析して、その予測パフォーマンスがパフォーマンス基準に従っているかどうかを判別する工程を含むことができる。いつデータ・セットを移行するかを決定する工程はまた、データ・セットが操作可能にされた後にパフォーマンス基準を調整する工程を含むことができる。パフォーマンス基準は、応答時間、読み取りパフォーマンス時間、書き込みパフォーマンス時間、制御パフォーマンス時間、および日付依存パフォーマンス時間からなるグループから選択されてもよい。パフォーマンス基準は、データ管理目標を含むことができる。データ管理目標は、接続タイプ、ローカル・ミラーリング・タイプ、リモート・ミラーリング・タイプ、および最大データ・セット・サイズからなるグループから選択されてもよい。
【００２２】
さらに本発明によれば、いつデータ・セットを移行すべきかを決定するコンピュータ・ソフトウェアは、データ・セットのパフォーマンス基準を提供する実行可能コードと、データ・セットの実測パフォーマンスを提供するためにデータ・セットのパフォーマンスを測定する実行可能コードと、データ・セットがパフォーマンス基準に従って実行していないことを実測パフォーマンスが示す場合に、データ・セットを移行する新しいロケーションを選択して、データ・セットを新しいロケーションに移行する実行可能コードとを含む。データ・セットを移行する実行可能コードは、他のアプリケーションがデータ・セットにアクセスしているかどうかにかかわりなく、データ・セットを新しいロケーションに移動する実行可能コードを含むことができる。新しいロケーションを選択する実行可能コードは、複数のロケーションの各々を分析して、その予測パフォーマンスがパフォーマンス基準に従っているかどうかを判別する実行可能コードを含むことができる。コンピュータ・ソフトウェアはまた、データ・セットが操作可能にされた後にパフォーマンス基準を調整する実行可能コードを含むことができる。パフォーマンス基準は、応答時間、読み取りパフォーマンス時間、書き込みパフォーマンス時間、制御パフォーマンス時間、および日付依存パフォーマンス時間からなるグループから選択されてもよい。パフォーマンス基準は、データ管理目標を含むことができる。データ管理目標は、接続タイプ、ローカル・ミラーリング・タイプ、リモート・ミラーリング・タイプ、および最大データ・セット・サイズからなるグループから選択されてもよい。
【００２３】
さらに本発明によれば、ストレージ・デバイス上でデータを管理する工程は、暗号化されていないデータがストレージ・デバイス上に格納されるのを阻止する工程を含み、暗号化されていないデータを阻止する工程は、ストレージ・デバイス上にデータを格納し、ストレージ・デバイス上への格納に先立ってデータを暗号化するアプリケーションに透過的である。ストレージ・デバイスは、テープ・ドライブおよび／またはディスク・ドライブを含むことができる。ストレージ・デバイス上でデータを管理する工程はまた、第１のストレージ・ロケーションから第２のストレージ・ロケーションへデータを移行する工程を含むことができる。第１のストレージ・ロケーションは第２のストレージ・ロケーションと同じであってもよいか、または第１のストレージ・ロケーションは第２のストレージ・ロケーションとは異なっていてもよい。暗号化されていないデータは、移行中に阻止されうる。ストレージ・デバイス上でデータを管理する工程はまた、ストレージ・デバイスから読み取ったデータを復号化する工程を含むことができる。データを復号化する工程はまた、使用が制限されている秘密復号鍵を使用する工程を含むことができる。ストレージ・デバイス上でデータを管理する工程はまた、不正改ざん防止モジュールを使用して秘密鍵を格納し、データを復号化する工程を含み、不正改ざん防止モジュールは秘密鍵へのアクセスを制限する。
【００２４】
さらに本発明によれば、ストレージ・デバイス上でデータを管理するコンピュータ可読媒体におけるコンピュータ・ソフトウェアは、暗号化されていないデータがストレージ・デバイス上に格納されるのを阻止する実行可能コードを含み、暗号化されていないデータを阻止する工程は、ストレージ・デバイス上にデータを格納するアプリケーション、およびストレージ・デバイス上への格納に先立ってデータを暗号化する実行可能コードに透過的である。コンピュータ・ソフトウェアはまた、第１のストレージ・ロケーションから第２のストレージ・ロケーションへデータを移行する実行可能コードを含むことができる。第１のストレージ・ロケーションは第２のストレージ・ロケーションと同じであってもよいか、または第１のストレージ・ロケーションは第２のストレージ・ロケーションとは異なっていてもよい。コンピュータ・ソフトウェアはまた、移行中に暗号化されていないデータを阻止する実行可能コードを含むことができる。コンピュータ・ソフトウェアはまた、ストレージ・デバイスから読み取ったデータを復号化する実行可能コードを含むことができる。データを復号化する工程は、使用が制限されている秘密復号鍵を使用する工程を含むことができる。復号化は、ストレージ・デバイスに結合された少なくとも１つのホスト上で実行されうる。暗号化は、ストレージ・デバイスに結合された少なくとも１つのホスト上で実行されうる。暗号化は、ストレージ・デバイスに結合された少なくとも１つのホストまたはストレージ・デバイス上のいずれで実行されてもよく、復号化は、ストレージ・デバイスに結合された少なくとも１つのホストまたはストレージ・デバイスのうちのもう一方で実行されてもよい。
【００２５】
添付の特許請求の範囲は、本発明の主題を特に指摘して明瞭に主張する。本発明のさまざまな目的、利点、および新奇な特徴は、類似する参照番号が類似した部分を参照する添付の図面と併せて以下の詳細な説明を読めばさらに完全に明らかとなろう。
【発明を実施するための最良の形態】
【００２６】
図１は、一例として、ホスト２１と、データ・ストレージ設備２２および２３として２つのディスク・アレイ・ストレージ・デバイスを含むデータ処理システム２０を示す。当技術分野において知られているように、ホスト２１は、少なくとも１つの専用領域２５および共通ストレージ領域２６に分割されるメイン・メモリ２４を含む。１つまたは複数のプロセッサ３０は、メモリ２４と対話する。
【００２７】
データ・ストレージ設備２２および２３のような、単一ホスト２１と入出力デバイスとの間の通信は、サブチャネルを介して発生する。本発明を説明するために、サブチャネル３１は、ホスト２１とソース・データ・ストレージ設備２２とを接続し、サブチャネル３２は、ホスト２１とターゲット・データ・ストレージ設備２３とを接続する。２次ホスト２１Ａは、マルチ・プロセッサ３０Ａ、メモリ２４Ａ、サブチャネル３１Ａおよび３２Ａを備える類似した構造を有する。
【００２８】
前述のように、ホスト・アプリケーションおよびデータ・ストレージ設備は、データのロケーションを異なる方法で識別する。つまり、ホスト・アプリケーションは、データを論理レベルで、データ・エクステントまたは「エクステント」および／または１つまたは複数のエクステントのデータ・セットと見なす。ＭＶＳオペレーティング・システム（ｚ／ＯＳ）などのオペレーティング・システムは、データのホスト・アドレス指定フォーマットを、データ・ストレージ設備のアドレス指定フォーマットに変換する。
【００２９】
具体的には、オペレーティング・システムは、ホスト・アプリケーションと、ＥＸＣＰ、メディア・マネージャ、入出力装置ルーチンのような低レベル・ルーチンとの間のインターフェイスとしてアクセス方式を使用する。入出力ドライバルーチンは、ＳＴＡＲＴＩＯ関数のような低レベル関数を呼び出して、サブチャネル経由で入出力を開始し、それによりデータ・ストレージ設備との間で情報をやりとりする。オペレーティング・システムは、特に当技術分野でよく知られているＣａｔａｌｏｇ、ＶＴＯＣ、ＶＶＤＳなどのコンポーネントを含む統合カタログ機能（ＩＣＦ）からの情報を使用して、アプリケーションから受け取ったアドレス指定フォーマットからのデータ・アドレスを、論理デバイス、シリンダ、およびヘッドによってデータを識別するアドレス指定フォーマットに変換する。この情報は一般に、「メタデータ」と呼ばれる。データ・ストレージ設備は、この論理デバイス・アドレス指定フォーマットを物理ディスク・ドライブ・アドレス指定フォーマットに変更するための情報を含む。
【００３０】
本発明の理解を深めるために、図１におけるデータ・ストレージ設備２２は、既存のまたはソースのデータ・ストレージ設備であり、データ・ストレージ設備２３は、ソース・データ・ストレージ設備２２からデータを受け取るターゲットとしての機能を果たす新規または先在のデータ・ストレージ設備であると仮定する。データ・ストレージ設備２２は、論理デバイス２２（１）、２２（２）、２２（ｎ−１）、および２２（ｎ）が図１に示されている「ｎ」個の論理デバイスを有する。データ・ストレージ設備２３は、論理デバイス２３（１）、２３（２）、２３（ｍ−１）、および２３（ｍ）が示されている「ｍ」個の論理デバイスを有する。以下の説明において、データ・ストレージ設備２２の論理デバイスは「ソース論理デバイス」と呼ばれ、データ・ストレージ設備２３の論理デバイスは「ターゲット論理デバイス」と呼ばれる。
【００３１】
図１におけるホスト２１は、ＩＢＭ ＭＶＳオペレーティング・システムで稼働しているＩＢＭメインフレーム・システムなどのような、オペレーティング・システムによって制御される多重処理装置を備える標準的なメインフレーム・システムを表す。そのようなホストにおいて、ユーザ・アプリケーションは、有用なデータを操作するための制御を提供する。ＵＳＲ１アプリケーション３３およびＵＳＲ２アプリケーション３４は、２つのそのようなユーザ・アプリケーションを表す。たとえば、ＵＳＲ１アプリケーション３３は、トランザクション処理を担当する。ＵＳＲ２アプリケーション３４は、ＵＳＲ１アプリケーション３３を通じて供給されたデータに基づいてレポートを生成する。多くの場合、ＵＳＲ１アプリケーション３３のようなアプリケーションは、１日２４時間、週７日使用可能である必要がある。レポート・アプリケーションは、定期的に実行される。
【００３２】
公知のように、データ・セットを形成するエクステントは、あらゆる方法で格納されうる。つまり、１つのデータ・セット内のエクステントは、連続であっても、不連続であってもよい。たとえば、ＵＳＲ１アプリケーション３３およびＵＳＲ２アプリケーション３４は、ソース・データ・ストレージ設備２２のＤＳ１データ・セット３５、ＤＳ２データ・セット３６、およびＤＳ３データ・セット３７として指定された３つの個別のデータ・セットと対話すると仮定する。説明のため、ＤＳ１およびＤＳ２のデータ・セット３５および３６内のすべてのエクステントは連続し、各データ・セットが１つの論理デバイスに備えられると仮定する。ＤＳ３データ・セット３７は、２つのエクステントＤＳ３（１）およびＤＳ３（２）がソース論理デバイス２２（ｎ−１）上に不連続に備わる５つのエクステントを有するが、エクステントＤＳ（３）、ＤＳ（４）、およびＤＳ（５）はソース論理デバイス２２（ｎ）上に連続して備わると仮定する。
【００３３】
本発明は、連続エクステント、不連続エクステント、またはその組み合わせを備えるデータ・セットを移行する能力を有する。図１の具体的な実施形態を参照すると、本発明は、ユーザ・アプリケーション３３および３４と、ＤＳ１データ・セット３５、ＤＳ２データ・セット３６およびＤＳ３データ・セット３７内のデータとの間の対話を中断することなく、ソース論理デバイス２２（１）、２２（２）、２２（ｎ−１）および２２（ｎ）から、データ・ストレージ設備２３のターゲット論理デバイスに、開示されたデータ・セットの各々を移行する能力を有する。たとえば、ＤＳ１データ・セット３５およびＤＳ２データ・セット３６はいずれも、ターゲット論理デバイス２３（１）のような１つの論理デバイスに移行することができる。図１はまた、ＤＳ３データ・セット３７の４つのエクステントが、ターゲット論理デバイス２３（ｍ−１）の連続ロケーションに移行し、第５のエクステントＤＳ３（５）がターゲット論理デバイス２３（ｍ）に移行する動作も示す。
【００３４】
図１におけるメモリ２４は、データ・ストレージ設備２２および２３の両論理デバイスごとに装置制御ブロック（ＵＣＢ）を含む。これらの装置制御ブロックは、メモリ２４の共通領域２６に格納される。一例として、図１は、ＤＳ１データ・セット３５を含むソース論理デバイス２２（１）に関連付けられているＵＣＢ ＬＤＳ１制御ブロック３８を示す。ＵＣＢ ＬＤＳ２装置制御ブロック３９は、ソース論理デバイス２２（２）に関連付けられている。ＵＣＢ ＬＤＴ１装置制御ブロック４０は、ターゲット論理デバイス２３（１）に関連付けられている。その他の装置制御ブロック（図示されず）は、図１に示されるその他の論理デバイスの各々に関連付けられている。
【００３５】
本発明の例示的な実施形態を説明する前に、図２における手順４１によって示されるユーザ・アプリケーションの基本動作工程を検討することが有益であろう。ＵＳＲ２アプリケーション３４のようなユーザ・アプリケーションが初期化されるとき、工程４２は、本発明には関連しない特定の予備機能を実行する。工程４３は、１つまたは複数の関連するデータ・セットを開く。たとえば、ＵＳＲ１アプリケーション３３は、ＤＳ１データ・セット３５およびＤＳ３データ・セット３７を開くが、ＵＳＲ２アプリケーション３４はＤＳ２データ・セット３６を開く。その方法の一部において、ＵＳＲ１アプリケーション３３およびＵＳＲ２アプリケーション３４は、工程４４において対応するデータ・セットのメタデータを取り出す。本発明にとって重要なことに、メタデータは、システムがいずれかの時点で特定の論理デバイスおよびＵＣＢにマップするボリューム通し番号を提供するＭＶＳカタログ情報を含む。ＶＴＯＣは、シリンダおよびヘッド範囲のセットをエクステント・リストに提供する。
【００３６】
工程４５は、たとえば図１のデータ・ストレージ設備２２を含むさまざまな入出力装置により入出力要求を制御するために、取り出したメタデータ、特にＤＳ１データ・セット３５、ＤＳ２データ・セット３６、およびＤＳ３データ・セット３７を使用してアプリケーション機能を実行する。さらに、移行されるべきデータ・セットを開く各アプリケーションは、アプリケーションがそのデータ・セットを閉じるまで、そのデータ・セットの元のメタデータを使用し続ける。つまり、アプリケーションが終了すると、工程４６は、開いているデータ・セット、またはアプリケーションが工程４３において開いたデータ・セットを閉じる。しかし、あるアプリケーションがデータ・セットを閉じる場合、そのデータ・セットが引き続き別のアプリケーションに開かれている可能性もある。移行が発生した後にアプリケーションがデータ・セットを閉じた場合、アプリケーションがその後データ・セットを開くと、アプリケーションはターゲット論理デバイス上の移行されたデータに直接アクセスするので、この方法を理解しておくことは重要である。
【００３７】
論理データ移行−−コマンド
多くの状況において、構成ステートメントは、本発明の論理データ移行アプリケーションのような、一連の制御アプリケーションの動作を制御する。一部の制御アプリケーションにおいて、１つまたは複数の構成ステートメントのセットは、制御アプリケーションの異なる段階を開始する。本発明の１つの実施形態において、さまざまな構成ステートメントは、初期化、移行および転換、および終了の段階の開始を有効にする。制御アプリケーションの機能の知識およびデータ処理システムの特定の構成により必要な構成ステートメントを生成することは、当業者の技術の範囲に含まれる。
【００３８】
この説明のために、「コマンド」は、構成ステートメントのセットを表し、本発明に関連する情報を説明して、必要な構成ステートメントを準備できるようにする。所定のコマンドは、手順の単一の段階または複数の段階の開始を制御する能力を有すると見なされる。さらに、各段階は、その特定の段階を実行するためのモジュールとして実施されるものと見なされる。
【００３９】
この背景をふまえ、図１および図３は、１つまたは複数のソース論理デバイス内の複数のエクステントから、１つまたは複数のターゲット論理デバイスへ、１つまたは複数のデータ・セットを移行することで特徴付けられうる論理デバイス移行（ＬＤＭ）アプリケーション５０の１つの実施例を示す。本発明の理解を助けるものとして、この特定のＬＤＭ論理アプリケーションは、各々特定の機能または関連する機能のグループを表す４つの別個の動作モジュールを有するものとして表される。これらは、初期化モジュール５１、移行および転換モジュール５２、終了モジュール５３、および監視モジュール５４を含む。
【００４０】
専用アプリケーション・メモリ２５におけるように、ＬＤＭアプリケーション５０がメモリ２４に読み込まれると、これはプロセッサ２１が引数またはフィールドの形態で情報を有するＬＤＭコマンドに応答できるようにする。基本的に、コマンドは以下の情報を含む。
【００４１】
１．「ＬＤＭ」または同等の演算コードなどのコマンド識別子。コマンドを論理データ移行コマンドとして識別する。
２．コマンドに応答して実行される図３のモジュールを識別する引数。たとえば、これらは、初期化引数、移行および転換引数、終了引数、監視引数、またはこれらの引数の一部またはすべての組み合わせを含むこともできる。
【００４２】
３．具体的に、またはパターン・マッチングを介して名前により識別され、かつ／またはさまざまなソース・ボリュームを識別することにより識別されるソース・データ・セットの識別。ターゲット論理デバイスの識別は、具体的に、またはＩＢＭのストレージ管理システム、つまり、いわゆるストレージ・グループあるいは同様の機構によって使用されるような、規則を介して行われる。データ・ストレージ設備においてデータ・グループ、セット、およびエクステントを識別するさまざまな方法が当技術分野で知られている。
【００４３】
４．シリンダまたはトラックの数を確立するしきい値引数。その数を下回ると残りのトラックは、完全同期およびミラーリング状態を確立するために静止されたアプリケーション入出力によりコピーされる。
【００４４】
５．データ・セットがデータ・グループに編成されるとき、引数は、グループ移行が一貫した方法で発生するかどうかを決定する。
６．別のホスト２１Ａにより形成される図１に示されるようなマルチホストネットワークにおいて、ホストが１次、またはオーナ、ホストまたは２次、または非オーナ、ホストであるかどうか。
【００４５】
論路データ移行アプリケーションがロードされてアクティブにされると、ＬＤＭまたは同等のコマンドの実行は、図４に示されるようにさまざまな操作または手順のいずれかを開始する。たとえば、工程５５は、コマンドの受信と、そのホストとＬＤＭコマンドに応答して移行される任意のエクステントとの間のトランザクションのための監視モジュール５４のアクティブ化を表す。工程５６および工程５７は、有効な引数に応答して図５に従って初期化モジュール５１を処理する。移行および転換引数が有効である場合、工程５８は、工程６０が、データを移行する図７から１０に示される工程に従って移行および転換モジュール５２を処理できるようにする。終了引数が有効である場合、工程６１は、工程６２が、図１１に示されるように終了モジュールを処理できるようにする。この特定の実施態様は、図３に示されるすべての手順が、１つのコマンドに応答して順序正しく処理されるようにする。しかし、明らかとなるように、第１のコマンドは通常、有効な初期化引数のみ、または有効な初期化引数と移行および転換引数の両方を含むことができる。後に、ＬＤＭコマンドは、有効な終了引数のみにより発行されることになろう。
【００４６】
論理データ移行−−初期化段階
初期化引数を持つＬＤＭコマンドが受信されると、ＬＤＭアプリケーション５０は、初期化モジュール５１を使用して、各エクステントが移行されるべきソース論理デバイス内のエクステントのロケーションおよびターゲット・ストレージ論理デバイスのロケーションを識別する制御データ構造を生成する。初期化モジュールはまた、ソースおよびターゲット論理デバイスに関連する構成情報を格納する。
【００４７】
具体的には、初期化引数セットを持つコマンドを受信すると、図４の工程５７は、工程７１においてＬＤＭコマンドを解析する図５の工程７０に制御を移す。解析は、一貫したデータ移行の必要性およびしきい値を識別するＬＤＭコマンドからの情報をもたらす。ＬＤＭコマンドの解析はさらに、ソース・エクステントおよび対応するターゲット・エクステントのロケーションが決定されうる情報ももたらす。
【００４８】
工程７２は、移行が満足される条件を検証する。たとえば、検証は、ソースおよびターゲット論理デバイスが互換であるかどうかを判別することを含むこともできる。条件が検証されると、工程７３は、制御を工程７４に移して初期化モジュールを続行する。それ以外の場合、工程７３は、制御を工程７５に移して、エラー・メッセージを生成し、コマンドに対するそれ以降の応答を終了して、論理データ移行を事実上中止する。
【００４９】
工程７４は、論理デバイス移行の実行および転換モジュール５２中に使用するために、図６に示されるデータ構造に対応するデータ構造を確立する。この工程はまた、対応する引数またはＬＤＭコマンドにしきい値をロードする。具体的には、図６は、異なるロケーションにおいて、しきい値エントリ７７、グループ状態エントリ７８、およびデータ・セット・ポインタ７９を受け取るグループ・ブロック７６を備えるデータ構造を示す。データ・セット・ポインタ７９は、第１のデータ・セット・ブロック８０のロケーションを識別する。データ・セット・ブロック８２のような、各データ・セット・ブロックは、論理デバイス・ポインタ８１およびデータ・セット状態エントリ８２のロケーションを有する。各データ・セット・ブロックはまた、グループ内のすべてのデータ・セットについて個々のデータ・セット・ブロックをリンクするさまざまな既知の手段のいずれかを含む。
【００５０】
論理デバイス・ポインタ８１は、エクステント・ポインタ８４および論理デバイス状態エントリ８５のロケーションを含む第１の論理デバイス・ブロック８３を指し示す。エクステント・ポインタ８４は通常、選択された論理デバイスについて、エクステント・ブロック９０のような、第１のエクステント・ブロックのロケーションを識別する。データ・セットに関連付けられているその他のすべての論理デバイスへのリンクも存在する。
【００５１】
エクステント・ブロック９０は、特定のエクステントに関する特定の情報を含む。１つのロケーションは、エクステント状態エントリ９１を含む。その他のロケーションは、初期ソースおよびターゲット・アドレス９２および終了アドレス９３などの、アドレスの表現を格納する。アドレス９２および９３は各々、絶対アドレス、基底アドレスまたはオフセットによって、あるいは何らかのアドレス変換によって構成されうる。前述の説明と同様の方法で、単一の論理デバイスに関連付けられているすべてのエクステント・ブロックにリンクが提供される。
【００５２】
さらに図６を参照すると、データ構造は、これ以降「制御ブロック」９４および９５と呼ぶ、トラック−シリンダ制御ブロックを含む。制御ブロック９４およびブロック７６、８０、８３、および９０は、ソース論理デバイスと関連して格納される。図１において、情報は、データ・ストレージ設備２２に格納される。これらのデータ構造は、データ・ストレージ設備の構成に応じて、キャッシュ・メモリ、物理ディスク、またはその両方に格納される。しかし、通常、ソース論理デバイス制御ブロックおよびデータポインタはまた、図１のメイン・メモリ２４に格納される。制御ブロック９５は通常、ターゲット論理デバイスに格納される。
【００５３】
トラック・ベースでの制御が望ましい１つの実施形態において、制御ブロック９４および９５の各エントリは、エクステント状態エントリ９６、列９７に単一ソース・トラック・アドレス、および列１００に対応するターゲット・トラック・アドレスを含む。エクステントが１つまたは複数の完全シリンダを占有する場合、列９７および１００のソースおよびターゲット・アドレス・エントリは、アドレスをシリンダ・レベルに対してのみ定義することができる。その場合、制御ブロック９４および９５の各行は、初期シリンダ・アドレスを識別する。エクステントがシリンダ境界で開始および終了しない場合、エントリは、個々のトラック・アドレス指定を提供するために、シリンダおよびヘッド・アドレスに対するものになる。
【００５４】
ＣＯＰＹ列１０１は、トラックごとに、トラックが引き続きコピーを必要とするかどうかを記録する。場合によっては、ＣＯＰＹ列１０１は、ソース論理デバイスに関連付けられているトラック・テーブルによって構成されうる。そのような場合、制御ブロック９４および９５はまた、コピーされる必要があるトラックを反映するためにＳＹＮＣ列１０２を含むことができる。
【００５５】
図５および図６を共に参照すると、工程７４が図６のデータ構造を確立した後、図５の残りの工程はさまざまなデータ構造を取り込む。この方法の一部として、工程１０３は、データ・セット・ポインタ７９によって識別されたデータ・セットのような、識別されたデータ・セットのうちの１つを選択する。工程１０４および１０５は、ＩＣＦからの情報を使用して、そのデータ・セットのエクステントとエクステントのうちの１つを格納する各論理デバイスのロケーションを識別する。これに応答して、図５Ａに示される方法は、ソース論理デバイスのエクステントの開始および終了アドレスを生成する工程１０６を伴うエクステント・ブロック制御テーブル・エントリを生成する。工程１０７は、ターゲット論理デバイス内のエクステントの開始アドレスをもたらす。この情報がそれぞれ、図６のブロック９２および９３にロードされた場合、工程１０８は、エクステント状態エントリ９１のような、対応するエクステント状態エントリを、ＣＯＰＹ状態を示すように初期ＣＯＰＹ値に設定する。
【００５６】
次いで、工程１１０は、トラック・シリンダ制御ブロック９４および９５の各々にデータを取り込む。つまり、識別されたエクステント内の各トラックまたはシリンダについて、工程１１０は所定の行にエントリを入力する。したがって、所定のエクステントは、トラック・シリンダ制御ブロック９４および９５内に多数の異なるエントリを有することができる。加えて、工程１１０は、列１０１内のすべてのＣＯＰＹビット、および列１０２内のすべてのＳＹＮＣビットに初期値を確立して、各々対応するトラックがコピーされる必要があることを示す。工程１１０はさらに、対応する状態エントリごとに初期状態値を設定する。
【００５７】
戻って図５を参照すると、モジュールは、ループ制御として工程１１１を使用し、図５Ａの手順が識別されたエクステント内のトラックごとにエクステント・ブロック９０およびトラック・シリンダ制御ブロック９４および９５を確実に取り込むようにする。追加のエクステントがデータ・セット内で処理される必要がある場合、制御は工程１１１から工程１０５に戻る。
【００５８】
選択された論理デバイス内のデータ・セットのエクステントのすべての制御データが制御データ構造を取り込んでいる場合、工程１１１は、データ・セット内のすべての論理デバイスが確実に処理されるようにする工程１１２に制御を移す。そうではない場合、制御は工程１０４に戻り、工程１０３において選択されたデータ・セットのエクステントを含む別の論理デバイスを選択する。データ・セットのすべての論理デバイス内のすべてのエクステントが処理されている場合、工程１１２は、工程１１３に制御を移す。工程１１３は、ＬＤＭコマンドで識別されたすべてのデータ・セットが処理されていることを確実にするため、ループ制御である。追加のデータ・セットが存在する場合、制御は工程１１３から工程１０３に戻る。すべてのデータ・セットが処理されている場合、初期化モジュール５１の操作は中断して、図６のデータ構造が完全に取り込まれる。
【００５９】
したがって、初期化モジュール５１がその操作を完了する場合、環境は、データ移行を制御するために存在する。監視機能はアクティブであり、データ構造はアクティブである。ここで、有効な初期化引数と移行および転換引数と共に送信されたＬＤＭコマンド、または有効な移行および転換引数と共に送信された後続のＬＤＭコマンドによって、移行および転換が開始する。
【００６０】
論理データ移行−−移行および転換段階
図７は全般として、データ移行に関与する各データ・セットに対してエクステント・ベースおよび論理デバイス・ベースでデータの移行が発生する移行および転換モジュール５２の操作を示す。方法は、工程１２０において開始し、初期化モジュール５１が初期化段階を完了していることを確認する。初期化段階が完了している場合、工程１２０は工程１２１に進み、移行および転換モジュールの残りの工程を開始する。それ以外の場合、工程１２０は、アボート・メッセージを生成する工程１２２に制御を移し、移行および転換段階は終了する。
【００６１】
工程１２１は、データ・セットを選択し、図６のエントリ８２のような、データ・セット状態エントリをＴＲＡＮＳＩＴＩＯＮ値に変更する。工程１２３は、データ・セットの論理デバイスを選択して、その論理デバイス状態エントリをＴＲＡＮＳＩＴＩＯＮ値に設定することにより、同様の操作を実行する。ＴＲＡＮＳＩＴＩＯＮ値は、論理デバイスがＭＩＧＲＡＴＥＤ状態へ遷移していることを示す。
【００６２】
次に、工程１２４は、ブロック９０によって表されるエクステントなどのエクステントをミラーリングされるように選択する。図７Ａに示されるように、工程１２５は、「ミラー・エクステント」方法における第１の工程である。工程１２５は、エントリ９１などのエクステント状態エントリをＣＯＰＹＩＮＧ値に設定して、エクステントがターゲット論理デバイスにコピーされていることを示す。エクステントが１つまたは複数の完全シリンダによって定義されない場合、工程１２６はエクステント内のトラックを選択する。工程１２７は、図３の監視モジュール５４または他のリソースによって取得された情報に基づいて、任意の外部操作がソース・エクステントを変更したかどうかを判別する。変更が発生した場合、移行および転換段階は、変更を処理する手順１２８を経由して終了する。それ以外の場合、制御は工程１３０に進む。
【００６３】
工程１３０は、トラック行内の識別されたトラックの特定のソース・トラックを識別するために、ソース制御ブロック９４に注目する。列１０１内の対応するＣＯＰＹビットが設定されている場合、工程１３０は工程１３１に進み、ソース論理デバイス・トラック内のデータを、制御ブロック９４でトラック・アドレスによって定義されているように、ターゲット論理デバイス内の対応するトラックにコピーする。工程１３２は、特定の実施形態に応じて、トラック・シリンダ制御ブロック９４および９５内のＣＯＰＹビットおよび／またはＳＹＮＣビットの状態を、トラックがコピーされていること示すように変更する。工程１３２がその機能を実行した後、または選択されたトラックがすでにコピーされていると工程１３０が判別した場合、制御は工程１２３に移る。エクステント内にさらにトラックが存在する場合、工程１３３は、次のトラックを選択する工程１２６に制御を戻す。代替として、データ・セット内の選択されたエクステントがシリンダ・レベルで定義されている場合、工程１３０から工程１３２は、トラック・レベルではなく完全シリンダ・レベルでさまざまな操作を確立するように変更されうる。
【００６４】
エクステントがこのループで処理された場合、工程１３３は、ソース論理デバイス制御ブロック９４に存在するエクステントに対して設定されたＣＯＰＹビットまたはＳＹＮＣビットの数をカウントする工程１３４に制御を移す。後に説明されるように、ユーザ・アプリケーションは、ＣＯＰＹＩＮＧ状態中にエクステント内のデータを変更することができる。したがって、ループ通過を終えた時点で、コピーされたトラックが変更されている可能性もある。そのため、変更されたトラック内のデータは、再度コピーされる必要がある。工程１３４は、再度コピーされる必要のあるトラックの数を決定する。トラックの数が、図６のしきい値ブロック７７において確立された特定のしきい値であるか、またはそれを超える場合、工程１３５は、トラックを選択することによりエクステントを再度処理する工程１２６に制御を戻す。
【００６５】
工程１２６から工程１３５を備えるこのループは、あらかじめ定められた条件が達せられるまで続行する。この特定の実施形態においてコピーを必要とするトラックの数がしきい値を下回る値まで減少したときに、あらかじめ定められた条件は達せられる。次いで、工程１３５は、ターゲット論理デバイス・エクステント内のデータをソース論理デバイス・エクステント内のデータに同期化させる方法において第１の工程である図７Ａの工程１３６に制御を移す。
【００６６】
これは、連続した方法であり、そのため工程１３６はソース論理デバイス内のエクステントをロックして、アプリケーションとソース論理デバイス・エクステントとの間の対話を妨げる。次いで、工程１３７は、残りの変更済みトラックからターゲット論理デバイスにデータを移行することによって、ミラーリング操作を完了する。明らかなように、この間にホスト・アプリケーションとの対話は全く発生しない。この工程が完了すると、ターゲット論理デバイスのエクステント内のデータは、ソース論理デバイスの対応するエクステント内のデータをミラーリングする。工程１４０は、エントリ９１のような、対応するエクステント状態エントリ内のエクステント状態を、同期化がそのエクステントに対して達成されていることを示すＭＩＲＲＯＲＥＤ値に更新する。次いで、工程１４１は、ホストとエクステントとの間の通信を再び可能にするように、ソース・エクステントのロックを解除する。
【００６７】
工程１４１がエクステントのロックを解除した後、エクステントは再びユーザ・アプリケーションに使用可能になる。次いで制御は、図７、特に工程１４２に戻る。論理デバイス内にさらにエクステントがある場合、工程１４２は、次のエクステントをミラーリングする方法を繰り返す工程１２４に制御を移す。
【００６８】
データ・セット内のすべてのエクステントが転送されると、図７の工程１４２は、移行が一貫した方法で実行されているかどうかを判別する工程１３４に制御を移す。具体的には、工程１４３は、ＬＤＭコマンド内の一貫性引数を検査する。引数が有効である場合、１つまたは複数のターゲット論理デバイスに移行されたデータへの転換は、同時に発生するはずである。その場合、工程１４３は、他の論理デバイス内の追加データ・セット・エクステントが処理される必要があるかどうかを判別する工程１４４に進む。データ・セットの追加論理デバイス内のエクステントが処理される必要がある場合、工程１４４は、選択されたデータ・セットのエクステントを含む別の論理デバイスを選択する工程１２３に制御を戻す。すべての論理デバイスが処理されている場合、工程１４４は、追加のデータ・セット内のエクステントが処理される必要があるかどうかを調べる工程１４５に制御を移す。
【００６９】
グループの一貫性が必要とされない場合、工程１４３は、図７Ｂに示される連続した「非一貫性変換」方法を開始するために制御を移し、ここで工程１４６は選択された論理デバイス内のエクステントをロックする。次いで、工程１４７は、論理デバイス内の識別されたデータ・セット・エクステントのメタデータを更新する。次いで、工程１４７はさらに、図６の状態エントリ８６などの論理デバイス状態エントリ、およびエントリ９１などのすべての対応するエクステント状態エントリを更新することにより、ＤＩＶＥＲＴＥＤ状態を示すように、データ・セットの状態を設定する。次いで、工程１４８は、ソース・データ・セット・エクステントのロックを解除して、制御を図７の工程１４４に移す。
【００７０】
すべてのデータ・セットが完了したと工程１４４および工程１４５が判別した場合、工程１４５は制御を工程１５０に移す。グループ一貫性引数がＬＤＭコマンドで設定されていなかったと仮定して、それ以上のアクションは行われない。
【００７１】
グループ一貫性が必要とされる場合、「一貫性エクステント変換」方法が開始する。明らかとなるように、非一貫性エクステント変換および一貫性エクステント変換は、相互に排他的である。非一貫性エクステント変換と同様に、一貫性変換は連続した方法である。この方法は、工程１５０が、グループ内のすべてのデータ・セットのすべてのソース・エクステントを並行してロックする図７Ｃの工程１５１に制御を移すと開始する。次いで、工程１５２は、指定されたグループ内のすべてのソース・データ・セットおよびそれらのエクステントのメタデータを更新する。次の工程１５３は、エントリ７８、８２、８６、および９１などのエクステントおよびデータ・セット状態エントリを更新することによって、グループ内のすべてのデータ・セット、論理デバイスおよびエクステントの状態をＤＩＶＥＲＴＥＤ値に変える。これが完了すると、工程１５４は、グループ内のすべてのソース・エクステントのロックを解除する。次いで、制御は、グループ状態エントリ７８を更新することによって識別されたグループをＤＯＮＥとマークする図７の工程１５５に戻る。
【００７２】
このようにして、図７Ａ、７Ｂ、および７Ｃの手順を含む図７の移行および転換モジュールがその操作を完了すると、すべての入出力要求はターゲット論理デバイスに転換される。最終的に、転換方法はまた終了されうるので、移行されたデータ・セットに関連付けられているストレージ領域は他の目的に使用されうる。
【００７３】
論理データ移行−−入出力要求
ホスト・アプリケーションからの入出力要求の通常の処理と並行して論理データ移行を行うことの影響を最小化するため、エクステントが移行されている間であっても、データに対するそのようなホスト・アプリケーションからの入出力要求に引き続き応答することが必要である。監視モジュール５４は、この必要な機能を実行する。そのようなモジュールは、当技術分野において知られているように、監視モジュール５４により特殊処理に対する入出力要求を代行受信することによって操作することができ、１つの例は、本明細書に援用する米国特許出願第１０／２８３，９７６号明細書において開示されている。図８は、図１におけるＵＳＲ１アプリケーション３３またはＵＳＲ２アプリケーション３４などの、ユーザ・アプリケーションからの入出力要求に応答する監視モジュール５４のアクションを示す。
【００７４】
監視モジュール５４のこの実施形態はまた、複数のホストを有するシステムにおいて使用するように適合される。マルチホスト・システムにおいて、ホスト２１のような１つのホストは、「１次ホスト」または「オーナ」ホストと呼ばれる。「オーナ」は、特定のデータ・セット・グループの方法を管理するために最適なホストとしてグループのアクティブ化時に確立される。特に、実際のデータ移行のすべてではないとしても、移行の多くはオーナによって行われる可能性が高い。特定のコマンド機能は、オーナによってのみ満足されうるが、これはユーザには透過的にすることができる。図１のホスト２１Ａなど、その他のホストは「２次」または「非オーナ」ホストである。非オーナ・ホストは、最低限でも、結果のデータ・セットへの入出力要求を監視して、ミラーリングおよび転換段階にアクティブに参加する必要がある。各１次および２次ホストは、監視モジュール５４のインスタンスを使用して入出力要求を代行受信するが、その間データ移行方法は一部の小規模な変更で進行中である。したがって、複数ホストのアプリケーションにアクセス可能なエクステントからデータを移行することが可能である。
【００７５】
移行されているデータ・セットにおけるデータ転送の要求は、ＬＤＭアプリケーション５０に関連付けられている移行および転換モジュール５２を処理しているものと同じホスト２１から生じていると仮定し、工程１６０は、状態、アドレス、およびその他の情報をソース論理デバイス・データ構造から取得する工程１６１に制御を移す。工程１６０は、図７Ａの工程１２７において有用である変更の監視を含む操作を監視する方法を表している。監視モジュールが２次ホストとして動作している場合、工程１６０は、ターゲット論理デバイスの制御ブロック９５から状態およびその他の情報を取得する工程１６２に制御を移す。工程１６２は、工程１６１と類似している。この情報が取得されると、制御は工程１６３に移る。
【００７６】
工程１６３は、入出力要求が図６のエクステント状態エントリ９０内など、対応するエクステント状態エントリによって示されるような転換されたエクステント内のトラックに方向付けられているかどうかを決定する。方向付けられている場合、図８の工程１６３は、図６の状態およびその他の情報を使用してソース・トラック・アドレスをターゲット・トラック・アドレスに変換する工程１６４に進む。工程１６５は、受け取った入出力要求を、ターゲット論理デバイス内の対応するロケーションへの要求に再キャストする。工程１６６は、ターゲット論理デバイスでこの入出力要求を完了する。それ以上の移動はソース論理デバイス内のトラックでは発生しない。
【００７７】
ＤＩＶＥＲＴＥＤ状態への遷移中、個々のエクステントは、ＣＯＰＹまたはＭＩＲＲＯＲＥＤ状態のいずれかで存在する。その場合、工程１６３は、入出力要求が書き込みコマンドを含むかどうかを判別する工程１６７に進む。入出力要求が読み取りコマンドのみを含む場合、制御は、要求されたデータをソース論理デバイスから取り出す工程１７０に移る。ＤＩＶＥＲＴＥＤ状態への遷移に先立ち、読み取りコマンドがターゲット論理デバイス内のエクステントと対話する必要はない。次いで、読み取り専用入出力要求への応答が完了する。
【００７８】
エクステントへの書き込みコマンドがＤＩＶＥＲＴＥＤ状態へのエクステントの遷移に先立って入出力要求に含まれている場合、各書き込みコマンドは、ターゲット論理デバイス内の識別された各トラックがソース論理デバイス・トラックとの同期を維持できることを確実にするような方法で処理される必要がある。エクステントがＣＯＰＹ状態にある場合、工程１７１および工程１７２は、工程１７３に制御を移す。この工程において、監視モジュール５４は、工程１７４を使用して、識別されたトラックのみをソース論理デバイスで更新することにより各書き込みコマンドを完了する。しかし、工程１７３は、ＣＯＰＹビットおよびＳＹＮＣビットを、トラックが再度コピーされる必要があることを示す状態に更新する。その結果、変更されたデータは、その後ターゲット論理デバイスに転送される。これで、ＣＯＰＹ状態のエクステントを伴う書き込み操作への応答は完了する。
【００７９】
書き込まれるエクステントがＭＩＲＲＯＲＥＤ状態にある場合、工程１７４は再び、ソース論理デバイスに対する要求を完了する。並行して、工程１７１は、使用可能なマッピング・データを使用してターゲット論理デバイスへの要求を生成する工程１７５に制御を移す。工程１７６は、データをターゲット論理デバイス内の対応するトラックに書き込むことにより、ターゲット論理デバイスへの要求を完了する。したがって、データがＭＩＲＲＯＲＥＤエクステントに書き込まれる場合、図８の操作は、２つの結果のトラックに送信された変更済みデータが同一の状態を維持することを保証する。いずれの書き込み操作についても、工程１７７は、書き込み操作が完了したことを示す前に、両方の並行方法の完了を待つアクションを表す。
【００８０】
データ・セットのメタデータが、あるいは一貫性グループの場合は移行されるすべてのデータ・セットが更新されると、データ・セットの構成およびアドレスを識別する必要のあるすべての情報は、一度に、ターゲット・デバイス内の新しいロケーションを指し示すように変更される。しかし、いずれかのアプリケーションが開いている間、図８の転換操作は続行する。ただし、論理デバイス内のデータ・セット・エクステントがＤＩＶＥＲＴＥＤ状態であった後に、アプリケーションが停止されて開始される場合、つまりリサイクルされる場合、アプリケーションは、カタログ、ＶＴＯＣ、およびその他のテーブルなど、ストレージ・ロケーションに関する使用可能なさまざまな情報に基づいて新規または更新されたメタデータでデータ・セットを開く。その後、そのアプリケーションからの読み取り／書き込み要求は、ターゲット・デバイスと直接に対話する。これ以上、ソース論理デバイスと対話する必要、または図８に示される監視モジュール機能の操作の必要はない。
【００８１】
論理デバイス移行−−終了段階
データ移行の時点で稼働していたすべてのアプリケーションが移行後にいったん終了した場合、ソース・データ・セットを保持する必要はなくなる。この条件が存在する場合、システムは終了段階に入ることができる。図９に示されるように、終了モジュール５３は、方法の実行中に使用されうる遅延１８０を含む。工程１８１は、データ移行を引き続き稼働する前に任意のアプリケーションが開始したかどうかを判別するために検査を行う。すべてのアプリケーションはリサイクルされていない場合、工程１８２は、この検査を再度試行する前に任意の時間待機する工程１８０に制御を戻す。場合によっては、終了することが必要になることもあり、終了段階を完了するために論理データ移行に先立って開始した任意のアプリケーションを直ちに制限することもある。
【００８２】
いずれにしても、論理データ移行中にデータと対話していたすべてのアプリケーションが、移行が完了したのでいったん閉じられた場合、工程１８３は、図６に示されるデータ構造などの、論理移行アプリケーションのデータ構造を、データ処理システムのすべての関連する領域から削除する。次いで、工程１８４は、移行されたソース・エクステントのロケーションをその他の目的に使用できるように、ＶＴＯＣまたは同等のデータ構造を更新する。
【００８３】
前述の説明は、１つまたは複数のソース論理デバイスから１つまたは複数のターゲット論理デバイスへ、１つまたは複数のデータ・セットを移行する方法および装置の特定の実施形態に関連する。データ移行は、単一エクステントまたは複数エクステントの単一データ・セットを伴うことができる。さらに、データ移行は、一貫した方法でグループ内のすべてのデータ・セットの転送を実行するオプションを備えるデータ・セットのグループを伴うこともできる。いかなる形式であれ、移行は、データを並行して使用することもある他のアプリケーションに透過的である。方法は、そのようなユーザ・アプリケーションによって処理されるデータにおいて最小の中断しか伴わない。
【００８４】
本発明のさまざまな目的は、コマンドに応答する論理データ移行アプリケーションの利用により実現される。コマンドは、ソース論理デバイス内の移行されるすべてのエクステント、およびそれらのエクステントを受け取るターゲット論理デバイス内のロケーションを識別する。ソース・デバイス内の各エクステントに対してターゲット論理デバイス内に対応するアドレスがあるので、従来技術のデータ移行システムとは異なり、さまざまなエクステントおよびデータ・セットが単一の論理デバイスに転送されることが可能である。初期化時に、方法は、さまざまな制御データ構造を生成して取り込む。移行および転換中に、アプリケーションは、１つまたは複数のソース論理デバイスのエクステントをトラック・ベースまたはシリンダベースで、制御データ構造内のアドレス情報に基づいて、１つまたは複数のターゲット論理デバイスにコピーする。これらの操作中、監視モジュールは、この段階においては要求を処理することにより、書き込み操作の場合には制御データ構造内の情報を更新することにより、他のアプリケーションからエクステントへの入出力要求に応答する。
【００８５】
移行および転換中、ターゲット論理デバイス内の各エクステントは、連続した方法でソース論理デバイス内の対応するエクステントからミラーリングされる。この方法の実行中、まだコピーされていないトラックを、ユーザ・アプリケーションによって中断されることなく、ターゲット・デバイスにコピーするため、ミラーリングされているエクステントに一定時間にわたりロックがかけられる。連続の方法はエクステントに作用するので、中断がアプリケーションに影響を与える可能性は最小化される。エクステントがミラーリングされた後、監視機能は、ソース論理デバイスおよびターゲット論理デバイスを共に更新することにより、書き込み要求に応答する。
【００８６】
論理デバイス内データ・セット・エクステントまたは複数データ・セット内のデータ・セット・エクステントのグループがミラーリングされた後、移行および転換モジュールは、各エクステントをＤＩＶＥＲＴＥＤ状態に遷移させるが、そのタイミングはグループ一貫性の要件によって決まる。論理デバイス内のデータ・セット・エクステントが転換された後、監視機能は、すべての入出力要求を代行受信し、それらをターゲット・アドレスに再キャストして、要求を再発行する。
【００８７】
この転換操作は、アプリケーションがデータ・セットを閉じるときまで、任意のアプリケーションからのすべての入出力要求を処理するよう続行する。アプリケーションがそのデータ・セットを再び開いた場合、転換の時点において転換されたデータ・セットに関連するすべてのメタデータは更新されているので、入出力要求はターゲット論理デバイスに方向付けられる。
【００８８】
本発明は、特定の実施形態に関して開示された。開示された装置に対して、本発明を逸脱することなく多くの変更を加えることができることは明らかとなろう。たとえば、本発明は、本発明の譲受人から入手可能なＳｙｍｍｅｔｒｉｘデータ・ストレージ設備における本発明の特定の実施形態に関して説明された。しかし、本発明の論理データ移行を実施する基本的機能は、他の種類のデータ・ストレージ設備に容易に適合される。開示はさらに、図３に示されるような論理データ移行モジュールの編成、および図４、５、５Ａ、７、７Ａ、７Ｂ、７Ｃ、８、および９に示されるような特定の一連の操作への特定の参照を含む。これらの手順の変形および特定の工程ごとの具体的な機能は、別の種類のデータ・ストレージ設備により本発明を実施するため、または論理データ移行システムを他のアプリケーションと統合する目的で、または市販のオペレーティング・システムで使用可能な既存のユーティリティを使用するために変更されうる。さらに、本発明は、ソース・データ・ストレージ設備内の２つの論理デバイスとターゲット・データ・ストレージ設備内の単一論理デバイスとの間の特定の移動に関して説明された。本発明は、単一データ・ストレージ設備内で移行を実行することに対して同等に適用可能である。
【００８９】
図６が特定のデータ構造および編成を示すことは明らかとなろう。当業者であれば、この特定の構造および編成を実施する知識、または具体的に開示された構造および編成の実施に他の構造および編成を適用する知識を備えるであろう。
【００９０】
前述のように１つまたは複数の論理デバイスから異なる１つまたは複数の論理デバイスへデータを移行するようにシステムを動的に再構成する時期を決定するためのメトリクスを備えることは有用である。場合によっては、データを移行する決定は古いハードウェアの段階的廃止に従って行われることもあるが、データが格納されるデバイスのパフォーマンスが期待に応えていないときにデータを移行することが有用になる場合もある。
【００９１】
アイビーエムコーポレーション（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ）は、データ・セットが作成されたときに入力される基準に基づいてデータ・セットの割り当てを可能にするＤＦＳＭＳを提供する。たとえば、ユーザがデータ・セットの特定のパフォーマンス（たとえば、特定のミリ秒応答時間）を備えることに関心がある場合、ユーザは望ましいパフォーマンス特性をＤＦＳＭＳに入力して、望ましいパフォーマンス特性を満たすかまたはこれを超えるとされる適切なストレージ・デバイスを自動的に割り当てられる。しかし、このシステムには限界がある。まず第１に、最初の割り当て後にストレージ・デバイスがパフォーマンス要件を満たさない場合、データ・セットが別のアプリケーションによってアクセスされている間に、すでに割り当てられたデータ・セットを再割り当てするための機構は、ＤＦＳＭＳでは容易に提供されない。そのような場合、ユーザは、パフォーマンスの不足に気づき、新しいデータ・セット・スペースを別のデバイス上に手動で割り当て、そのデータ・セットにアクセスしているすべてのアプリケーションを終了して、古いデバイス上の古いデータ・セット・スペースから新しいデバイス上の新しいデータ・セット・スペースへデータを移動させる。さらに、時には、データ・セットの望ましいパフォーマンスは変化する。たとえば、ユーザは当初、４ミリ秒の応答時間を備えるデータ・セットを割り当てる場合がある。後に、ユーザは、状況の変化により、あるいはユーザが必要なパフォーマンスを過小評価していたために、３ミリ秒の応答時間のほうがより適切であると判断することもある。先の例の場合と全く同様に、ユーザは、パフォーマンスの不足に気づき、新しいデータ・セット・スペースを別のデバイス上に手動で割り当て、そのデータ・セットにアクセスしているすべてのアプリケーションを終了して、古いデバイス上の古いデータ・セット・スペースから新しいデバイス上の新しいデータ・セット・スペースへデータを移動させることになる。
【００９２】
したがって、データ・セットのパフォーマンスを自動的に監視して、パフォーマンスが適切ではない場合にデータ・セットを再割り当てできることが望ましい。さらに、データ管理目標などの、任意の他の適切な基準に基づいてデータ・セットを自動的に再割り当てできることが望ましい。
【００９３】
図１０を参照すると、流れ図２００は、本明細書に説明されるシステムと関連して実行される、自動的にデータ・セットのパフォーマンスを監視して適切な場合にデータ・セットを異なるデバイスに再割り当て（移動）する工程を示す。場合によっては、データ・セットは複数のデバイスにわたって分散されうることに留意されたい。したがって、データ・セットの一部（たとえば、特定のデバイス上の部分）のみを、他の部分を移動させることなく移動することが可能である。したがって、本明細書の説明では、データ・セットを再割り当て（移動）することはまた、データ・セットの一部のみを再割り当て（移動）することも示すことを理解されたい。
【００９４】
処理は、データ・セットが格納されているストレージ・デバイスの実際のパフォーマンスを測定する最初の工程２０２で開始する。ストレージ・デバイスのパフォーマンスを測定することは、極めて簡単明瞭であり、たとえば、デバイスによって直接提供されるか、またはストレージ・デバイスに関連付けられている他の値に基づいて特性を確認することによって提供されるパフォーマンス特性の記録を伴う。使用されうる可能なパフォーマンス特性については、本明細書の他の部分で説明される。
【００９５】
工程２０２に続くのは、工程２０２において測定された実際のパフォーマンスが望ましいパフォーマンスと比較されて、実際のパフォーマンスが望ましいパフォーマンスを満足するかまたはそれを上回るかどうか判別される工程２０４である。本明細書において使用される「パフォーマンス」は、本明細書の他の部分で説明されるデータ管理目標（たとえば、使用されるリモート・ミラーリングの種類）を含むように広義に解釈されうることに留意されたい。工程２０２と同様に、工程２０４は極めて簡単明瞭である。本明細書の他の部分において詳細に説明されているように、望ましいパフォーマンス特性のセットは、各データ・セットおよび／またはデータ・セットのグループに関連付けられうる。工程２０４に続くのは、工程２０４の比較の結果が良好である（つまり、実際のパフォーマンスが望ましいパフォーマンスを満足するかまたはそれを上回る）かどうかを判別する検査工程２０６である。比較の結果が良好ではない場合、つまり、実際のパフォーマンスがユーザの望ましいパフォーマンスを満足しないかまたはそれ以下になる場合、制御は、検査工程２０６から、データ・セットの新しいデバイスが選択される工程２０８に移る。工程２０８において新しいデバイスを選択することについては、本明細書の他の部分で詳細に説明される。工程２０８に続くのは、本明細書の他の部分で説明されている、データが移行される工程２０９である。
【００９６】
実際のパフォーマンスが望ましいパフォーマンスを満足するかまたはそれを上回る場合に、工程２０９に続く、または工程２０６に続くのは、プロセッサが待機する工程２１２である。工程２１２は任意であるが、流れ図２００におけるループのタイミングを制御するために便宜的に使用されうる。工程２１２に続いて、制御は、前述の工程２０２に戻る。
【００９７】
図１１を参照すると、流れ図２２０は、新しいデバイスが選択される図１０の流れ図２００の工程２０８を詳細に示す。流れ図２２０の処理は、デバイス索引ＤＩが１に設定される最初の工程２２２で開始する。デバイス索引ＤＩは、選択されうるすべての可能なストレージ・デバイスを通して繰り返すために使用される。工程２２２に続くのは、基準索引ＣＩが１に設定される工程２２４である。基準索引ＣＩは、どのデバイスが望ましい基準を満足するかしないか、またはそれを上回るか上回らないかを判別するために、すべての可能な基準を通して繰り返すために使用されうる。
【００９８】
工程２２４に続くのは、デバイス索引基準ＤＩが、可能なデバイスの数に対応するあらかじめ定められた値（工程２２６においてＤＩＭＡＸと呼ばれる）を上回るかどうかを判別する検査工程２２６である。上回る場合、制御は、工程２２６から、エラーが通知される工程２２８に移る。デバイス索引ＤＩが可能なデバイスの数を上回る場合、望ましい基準を満足するデバイスはないことに留意されたい。したがって、許容可能なデバイスがないことを呼び出しルーチンにアラートするために、工程２２８においてエラーが通知される。工程２２８の後、処理は完了する。
【００９９】
ＤＩがデバイスの数よりも大きくないことが検査工程２２６において判別された場合、制御は、検査工程２２６から、基準索引ＣＩが可能な基準の数に対応するあらかじめ定められた数（ＣＩＭＡＸ）を上回るかどうかを判別する検査工程２３２に移る。上回る場合、制御は、工程２３２から、ＤＥＶ［ＤＩ］と呼ばれる検査対象の特定のデバイスをルーチンが返す工程２３４に移る。システムがすべての基準を通して繰り返し、検査対象の特定のデバイスＤＥＶ［ＤＩ］が各基準を満足するかまたは上回る場合、ＣＩは、可能な基準の数（ＣＩＭＡＸ）を超えるまで引き続き増分されるが、その場合デバイスＤＥＶ［ＤＩ］は望ましい基準をすべて満足しているかまたは上回っていることに留意されたい。工程２３４の後、処理は完了する。
【０１００】
基準索引ＣＩが可能な基準の数を超えないことが検査工程２３２において判別された場合、制御は、検査工程２３２から、検査対象のデバイスＤＥＶ［ＤＩ］が特定の基準ＣＲＩＴ［ＣＩ］を満足するかまたは上回るかどうかが判別される検査工程２３６に移る。満足するか上回る場合、制御は、検査工程２３６から、基準索引ＣＩが増分される工程２３８に移る。工程２３８に続いて、制御は、前述の検査工程２３２に戻る。
【０１０１】
工程２３６においてデバイスＤＥＶ［ＤＩ］が特定の基準ＣＲＩＴ［ＣＩ］を満足しない場合、制御は、工程２３６から、デバイス索引ＤＩが増分される工程２４２に移る。したがって、工程２３６は、望ましい基準のすべてを満足しないデバイスを拒否する。工程２４２の後、制御は、別のデバイスの基準の繰り返しを開始するために基準索引ＣＩが１に設定される工程２２４に戻る。したがって、流れ図２２０の工程は、工程２２８によって証明されるように、望ましい基準のすべてを満足するデバイスがなくなるまで、または工程２３４によって証明されるように、すべての望ましい基準を満たすデバイスが少なくとも１つあるまで実行される。このようにして、望ましい基準を満足するデバイスがないことを示す工程２２８に到達するか、または望ましい基準をすべて満足する少なくとも１つのデバイスがあることを示す工程２３４に到達する。
【０１０２】
ＤＦＳＭＳに関連して前述されたミリ秒応答時間の基準に加えて、データ・セットまたはデータ・セットのグループのストレージ・デバイスを選択するために他の基準が使用されうる。その他の基準は、読み取りパフォーマンス時間、書き込みパフォーマンス時間、制御パフォーマンス時間、ミラー・パフォーマンス時間（つまり論理デバイスのミラーリングのパフォーマンス）、ストレージ・デバイスへの接続タイプ（たとえば、ＦＩＣＯＮ、ＥＳＣＯＮ、並列チャネル、ＩＰ接続ストレージなど）、ローカル・ミラーリング・タイプ（たとえば、ＲＡＩＤ１、ＲＡＩＤ５、ＲＡＩＤ１０など）、リモート・ミラーリング・タイプ（たとえば、Ｊ０／Ｊ１ ＲＤＦ、適応コピーＲＤＦ、ＳＲＤＦ／Ａ、ＳＡＲ、ＳＴＡＲ、ＰＰＲＣ（変形を伴う）など）、最大データ・セット・サイズ、日付依存パフォーマンス、バックアップ頻度、およびバックアップの回数を含む。本明細書において使用される「パフォーマンス」は、データ管理目標（たとえば、使用されるリモート・ミラーリングの種類）を含むように広義に解釈されうることに留意されたい。したがって、パフォーマンス基準は、ミラーリングの種類または最大データ・セット・サイズなどの事項を含むように広義に解釈されうる。一般に、パフォーマンス基準は、確認することができ、データ・セットが配置される可能性のあるストレージ・デバイス間で異なることもある、システムの任意の望ましい特性であってもよい。
【０１０３】
工程２０２においてパフォーマンスを測定し、工程２０４においてパフォーマンスを比較するために、適切な機構が使用される。したがって、たとえば、バックアップの頻度の基準が使用される場合、工程２０２における実際のパフォーマンス測定は、特定のストレージ・デバイスのバックアップの頻度であるが、工程２０４において実際の基準２０２と比較される値は、特定のデータ・セットまたはデータ・セットのグループについてユーザにより提供されるバックアップの望ましい頻度である。同様に、基準が接続タイプである場合、工程２０２において測定される実際のパフォーマンスは、工程２０４でデータ・セットまたはデータ・セットのグループについてユーザに望まれる（たとえば、ＥＳＣＯＮ）接続タイプと比較されるストレージ・デバイスへの実際の接続である。これらのさまざまな基準を測定し、これらのさまざまな基準を実際の基準と比較することは、当業者には簡単明瞭である。その他の任意の適切な基準も使用されうる。データ・セットおよび／またはデータ・セットのグループに関連付けられている望ましいパフォーマンスは、それ自体がデータ・セット内に格納されるか、または他の適切な手段によって保持されうることに留意されたい。同様に、測定される実際のパフォーマンスはまた、データ・セットに格納されるか、または他の適切な手段によって保持される。
【０１０４】
本明細書に説明されるシステムは、ＤＦＳＭＳによって提供されるクラスのセットと類似したクラスの並列セットを使用して、ＤＦＳＭＳと共に使用される。本明細書において説明される機能にＤＦＳＭＳを提供するためにフックとして使用される他の機構があってもよい。任意のデータ・セットを移行するかどうか判別するためにシステムが使用するパフォーマンス／管理規則をユーザが指定することができる機構を提供することにより、ＤＦＳＭＳを使用することなく本明細書に説明されるシステムを実施することも可能である。
【０１０５】
図１２を参照すると、流れ図２００’は、図１０の流れ図２００によって示される処理の代替実施形態を表している。図１２の流れ図２００’によって示される実施形態において、ユーザは、たとえ望ましいパフォーマンス（またはデータ管理特性）が満足されていないことをシステムが検出したとしても、移動を中止する選択肢を有する。流れ図２００の要素と同じ参照番号を有する流れ図２００’の要素は、類似した機能を実行するので、以下では説明されない。
【０１０６】
工程２０４の比較の結果が良好ではないことが検査工程２０６（前述）において判別される場合、制御は工程２０６から、データ・セットが移動されるべきであることを確認するプロンプトがユーザに表示される工程２６２に移る。工程２６２に続くのは、ユーザがデータ・セットの移動を中止することを決定したかどうか判別する検査工程２６４である。中止を決定した場合、制御は、工程２６４から、前述の工程２１２に移る。それ以外の場合、ユーザが移動を中止しないことを選択すると、制御は、工程２６４から、前述の工程２０８に移る。場合によっては、データ・セットが移動されないことをユーザが最初に示した後、あまり頻繁に（または絶えず）プロンプトがユーザに表示されないように、フラグを設定することが望ましいこともある。
【０１０７】
一部の実施形態において、ユーザがデバイスおよび／またはデータ・セットのサブセットの選択的な監視を要求することができる機構を提供することが可能であることに留意されたい。そのような機構は、システムによりアクセスされる構成ファイルの使用、ユーザへのプロンプト表示などを含む多くの方法で提供されうる。
【０１０８】
場合によっては、ディスクまたはテープ、あるいは他の媒体上のデータが危険にさらされる可能性があるという懸念もある。特にデータが数千の顧客の個人記録を含むような場合にはなおさらである。状況によっては、データを使用する任意のアプリケーションを変更する必要なく、データ暗号化を提供することが望ましい。以下で詳細に説明されるように、本明細書に説明されるデータ移行機構を使用して、そのようなアプリケーションに依存しない暗号化を提供することも可能である。
【０１０９】
図１３を参照すると、データ移行アプリケーション５０’は、アプリケーション５０’が、初期化モジュール５１、移行および転換モジュール５２、終了モジュール５３、および監視モジュール５４を含むという点において、図３のデータ移行アプリケーション５０と類似している。アプリケーション５０’はまた、データが移行されるときにデータを暗号化するために使用されうる暗号化モジュール３０２を含む。しかし、本明細書の他の部分で説明されるように、データはまた、別のロケーションに移行されることなく暗号化されうる。本明細書に説明されるシステムは、ディスク・ストレージ、テープ、ＤＶＤなどを含む、任意の種類のストレージ媒体またはデバイスとの間で、暗号化／復号化を提供することができる。
【０１１０】
本明細書の１つの実施形態において、暗号化モジュール３０２は一般に知られた、公的に提供されている暗号化／復号化アルゴリズムを使用することができる。たとえば、アルゴリズムは、暗号鍵が公的に周知で使用可能であり、復号鍵がデータの復号化に復号鍵を使用する１つまたは複数のエンティティによって秘密にされるようなものであってもよい。そのような暗号化／復号化システムの場合、公開暗号鍵の知識は、復号鍵および／または暗号化されていないテキストのアクセスまたは知識を提供しない。そのような暗号化／復号化技法の例は、アールエスエイシステムズ（ＲＳＡ Ｓｙｓｔｅｍｓ）［米国マサチューセッツ州ベッドフォード（Ｂｅｄｆｏｒｄ）所在］によって提供される公開鍵暗号化を含む。
【０１１１】
他のシステムも、暗号化／復号化に使用されうる。たとえば、暗号化／復号化は、ＩＢＭによって提供されるＳ／３９０システムなど、ＩＢＭ Ｃｏｍｍｏｎ Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＣＣＡ）を使用する１つまたは複数のシステムによって提供されうる。公開鍵に依存しないが、代わりに秘密鍵のみを使用する他のシステムも使用されうる。そのようなシステムでは、復号時に鍵の暗号漏洩を防ぐために講じられる対策が、暗号化の時点でも鍵に適用されうる。
【０１１２】
図１４を参照すると、平文（暗号化されていない）データを暗号化モジュール３０２に提供する入力を有するものとして、暗号化モジュール３０２が詳細に示される。暗号化モジュール３０２はまた、暗号鍵を入力として受け取る。本明細書の他の部分で説明されるように、暗号鍵は、公的に周知で使用可能であるため、特殊な処理またはボールトを必要としないこともある。図１４はまた、暗号化モジュール３０２の出力が暗号化データであることも示す。操作中、暗号化されていないデータは、暗号鍵と共に暗号化モジュール３０２への入力として提供される。暗号化モジュール３０２は、多くの周知の公的に使用可能な公開鍵暗号化アルゴリズムのうちのいずれかを使用して、データを暗号化することができる。
【０１１３】
図１５を参照すると、流れ図３１０は、データ移行が本明細書に説明される暗号化と結合されるときにデータ移行の一部に関連して実行される工程を示す。流れ図３１０の工程は、トラックがソース論理デバイスからターゲット論理デバイスにコピーされる図７Ａの流れ図の工程１３１に関連して実行される。流れ図３１０の工程はまた、図７Ａの流れ図の工程１３７に関連して実行される。工程１３７において、残りのデータは、データ移行に関連してソース論理デバイスからターゲット論理デバイスにコピーされる。
【０１１４】
流れ図３１０の処理は、暗号鍵が取得される最初の工程３１２で開始する。本明細書の他の部分で説明されるように、暗号鍵は、公的に使用可能で周知であり、ボールトされるかまたは秘密にされる必要はない、公開鍵暗号方式を使用することが可能である。工程３１２に続くのは、ソース論理デバイスからターゲット論理デバイスにコピーされているデータに暗号鍵が適用される工程３１４である。工程３１４に続くのは、暗号化されたデータがターゲット論理デバイスに提供される工程３１６である。工程３１６の後、処理は完了する。
【０１１５】
本明細書の他の部分で説明されるように、このように暗号化されたデータの復号化は、復号鍵が秘密にされる必要があるため、いくぶん複雑になる。本明細書の他の部分で説明されるように、復号鍵の秘密性を保持するいくつかの技法がある。本明細書に説明されるシステムの場合、暗号鍵は、データを格納するストレージ・デバイス内に保持されるか、またはデータ移行アプリケーションで保持されて、悪意のある（無許可の）ユーザが暗号化されたデータをテープまたは他の媒体にコピーしようとするか、またはストレージ・デバイスから１つまたは複数のドライブを削除しようとした場合に、暗号鍵はストレージ・デバイスまたはデータ移行アプリケーションで保持されているので許可のあるユーザにしか使用できないため、暗号化されたデータは使用不可能になるようになっている。これを実施するために使用されうる機構については、本明細書の他の部分で説明される。
【０１１６】
図１６を参照すると、流れ図３２０は、データ暗号化に関連して実行されうる工程を示す。処理は、データが秘密鍵を使用して復号化される最初の工程３２２で開始する。工程３２２においてデータを復号化することについては、本明細書の他の部分で詳細に説明される。工程３２２に続くのは、復号化されたデータがストレージ・デバイスの許可ユーザに提供される工程３２４である。工程３２４の後、処理は完了する。
【０１１７】
本明細書において説明されている機能は、別のロケーションへのデータ移行、「同所」データ移行（本明細書の他の部分で説明）に関連して、または１つまたは複数のボリューム、ファイル、および／またはその他の種類のストレージ・ユニットのストレージ方法の一部として実施されうることに留意されたい。たとえば、ユーザは、機密データを格納するために特定の論理ボリュームを作成することも、そのボリュームに格納されるデータを常時暗号化するようシステムを構成することもできる。その場合、システムは、暗号化されるためにデータがそのボリュームに書き込まれるようにし、復号化されるためにデータが（許可ユーザによって）そのボリュームから読み取られるようにする。本明細書の他の部分で説明される用に、暗号化／復号化は、ホスト上で稼働しているアプリケーションには透過的な方法で実行されうる。たとえば、暗号化／復号化機能は、ストレージ・デバイス上で提供される。代替として、暗号化／復号化機能は、暗号化および復号化を行うために、ストレージ・デバイスからのホストの読み取りおよびストレージ・デバイスへのホストの書き込みを代行受信する方法を使用して、１つまたは複数のホスト上で提供される。
【０１１８】
図１７Ａを参照すると、図３４０は、ストレージ・デバイスが不正改ざん防止モジュール３４２を含む実施形態を示す。図３４０はまた、ストレージ・デバイスの内部にあるメモリ３４６に結合された複数のディレクタ３４４ａ〜３４４ｃを示す。ディレクタ３４４ａ〜３４４ｃはそれぞれ、ホスト・アダプタ、ディスク・アダプタ、および／またはリモート・アダプタを表すことができる。本明細書の実施形態において、最大１６のディレクタがメモリ３４６に結合されうる。もちろん、他の実施形態では、使用されうるディレクタの最大数がこれよりも多いかまたは少ない場合もある。
【０１１９】
３４０で表される図はさらに、ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２の間の代替通信パスを提供するオプションの通信モジュール（ＣＭ）３４８を示す。ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２のうちのいずれかが、メモリ３４６を経由する必要なくメッセージおよび／またはデータを他のディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４４のいずれかに送信することができるように、各ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２はＣＭ３４８に結合される。ＣＭ３４８は、ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２の１つを送信することで適切なアドレスを供給し、メッセージおよび／またはデータがディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２のうちの１つの意図された受信側によって受信されるようにする標準的なＭＵＸ／ルータ技術を使用して実施される。加えて、ディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２の１つを送信することで、他のディレクタ３４４ａ〜３４４ｃおよび／または不正改ざん防止モジュール３４２のすべてに同時にメッセージをブロードキャストすることが可能になる。
【０１２０】
図１７Ｂを参照すると、３５０で表される図は、ストレージ・デバイス３５６に結合された複数のホスト３５２〜３５４を含む実施形態を示す。ホスト３５２〜３５４はそれぞれ、相互に独立しているストレージ・デバイス３５６と対話することができる。代替として、ホスト３５２〜３５４の一部または全部は、一斉にストレージ・デバイス３５６と対話することができる。３５０で表される図は、ホスト３５２が不正改ざん防止モジュール３４２を含むが、ホスト３５４は独自のバージョンの不正改ざん防止モジュール３４２’を含むことを示す。３５０で表される図によって示される実施形態において、不正改ざん防止モジュール３４２、３４２’の機能は、ストレージ・デバイス３５６（図１７Ａの図３４０によって表される）から、ホスト３５２〜３５４の各々に移動される。
【０１２１】
ホスト３５２〜３５４のすべてが不正改ざん防止モジュールを有することは必要ではないことに留意されたい。たとえば、３５０で表される図は、不正改ざん防止モジュールを含まないものとして３５３のホストを示す。一部の実施形態において、本明細書に説明される暗号化／復号化機能を実行するホストに不正改ざん防止モジュールを備えることだけが必要である。また、暗号化はストレージ・デバイスまたはホストの１つのいずれでも実行させることは可能であるが、暗号化はもう一方の側で実行されること、そして一般に本明細書に説明される機能は、適切なデバイスまたはデバイスの組み合わせで提供され、操作中であっても移動されうることに留意されたい。
【０１２２】
特定のボリューム、ファイル、または他のストレージ・ユニットに対してデータが常時暗号化される（つまり、データが、作成時点およびその後に暗号化される）ような場合において、ホストとストレージ・デバイス間のデータの平文伝送を防止するために不正改ざん防止モジュール３４２をホストに備えることは有利となることに留意されたい。一方、（同所でまたは別のロケーションへの）データ移行に関連してデータが暗号化されるような場合は、ストレージ・デバイスの一部として不正改ざん防止モジュール３４２を備えることが有利となりうる。もちろん、不正改ざん防止モジュールを、ストレージ・デバイスの一部と１つまたは複数のホストの一部に共に備えることも可能である。加えて、本明細書に説明される機能を、ストレージ・デバイスおよびホストの両方から分離するかまたは少なくとも部分的に分離して提供することも可能である。
【０１２３】
図１７Ａに関連して説明された実施形態および図１７Ｂに関連して説明された実施形態（およびその他の実施形態）について、不正改ざん防止モジュール３４２は、不正改ざん防止モジュール３４２内部のデータの検査を許可しないハードウェア、ソフトウェア、またはそれらの組み合わせを使用して実施される。たとえば、不正改ざん防止モジュール３４２がハードウェア（たとえば、シングル・チップ）を使用して実施される場合、ハードウェアは、誰かがハードウェアを開こうと試みるごとにアクティブ化される自動消滅機構を備えてもよい。不正改ざん防止モジュールは、本明細書の他の部分で説明される、ＩＢＭによって提供される（ｚ／３９０システム（ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ））を使用して実施される。
【０１２４】
図１８を参照すると、図３６０は、不正改ざん防止モジュール３４２のコンポーネントを示す。不正改ざん防止モジュール３４２は、ハードウェア、ソフトウェア、またはその適切な組み合わせを使用して実施されうることに留意されたい。不正改ざん防止モジュール３４２が、ソフトウェアおよび／または大量のソフトウェアを使用して実施される場合、ストレージ・デバイスは、不正改ざん防止モジュール３４２への特定のアクセスのみを許可するように構成されうる。
【０１２５】
３６０で表される図は、鍵データベース３６２および復号モジュール３６４を含むものとして不正改ざん防止モジュール３４２を示す。鍵データベース３６２は、データの暗号化および復号化に使用されるすべての公開鍵／秘密鍵のペアを含むことができる。不正改ざん防止モジュール３４２は、出力として、鍵データベース３６２からの公開鍵（ただし公開鍵のみ）を提供する。本明細書の他の部分で説明されるように、公開鍵は、秘密ではなく、データを暗号化したいと望むエンティティには既知であるかまたは認識可能である。
【０１２６】
鍵データベース３６２に格納されている公開鍵／秘密鍵ペアの秘密鍵は、復号モジュール３６４に提供される。復号モジュール３６４は、不正改ざん防止モジュール３４２の外部から暗号化されたデータを受け取り、不正改ざん防止モジュール３４２の出力として復号化されたデータ（平文データ）を提供する。本明細書の実施形態において、鍵データベース３６２、復号モジュール３６４、またはそれらの間のデータ通信パスには、外部アクセスは全く提供されない。これは、開かれた場合に自動消滅する不正改ざん防止ハードウェア（たとえば、チップ）を使用して実施されうる。代替として、鍵データベース３６２、復号モジュール３６４、および／またはそれらの間のデータ・パスへのアクセスを禁止するソフトウェア／システムの実装があってもよい。
【０１２７】
一部の実施形態において、構成モジュール３６６は、データを鍵データベース３６２に提供するために使用されうる。構成モジュール３６６は、適切に安全であり、許可のあるユーザにのみアクセス可能にすることができる。構成モジュール３６６を使用する実施形態において、構成モジュール３６６のみが、鍵データベース３６２に公開鍵／秘密鍵ペアを提供することができる。そのような機構を備えることで、悪意のあるユーザが、データに不正アクセスするために、その独自の公開鍵／秘密鍵ペアを鍵データベース３６２に提供しないよう防止する。
【０１２８】
構成モジュール３６６を備えているかどうかにかかわらず、エンティティが鍵データベース３６２にデータを書き込むことのみを許可され、データを読み取ることを許可されていない限り、合法的に生成された公開鍵／秘密鍵ペアが危険にさらされることは困難になることに留意されたい。
【０１２９】
本明細書において説明されているシステムは、論理データ移行の後に、（許可ユーザによって）暗号化されたデータの読み取りで、不正改ざん防止モジュール３４２を使用してデータを復号化するような論理データ移行に関連して実施されうる。他の機構が、暗号化されたデータを管理するために使用されうることにも留意されたい。たとえば、ストレージ・システム上に格納されるデータがすべて常時暗号化された状態になるように、データがストレージ・デバイスに書き込まれるときは常に暗号化され、ストレージ・デバイスから読み取られるときは常に復号化されるようなシステムを備えることが可能である。そのような機構は、ユーザがデータを暗号化するかしないかを選択できるように、オプションのフラグによってアクティブ化されてもよい。さらに、本明細書において説明されるシステムは、データの読み取りおよび書き込みを行うストレージ・デバイスのマイクロコードを含む、あらゆるコードのレベルにおいて実装されうることに留意されたい。システムは、書き込まれるデータが暗号化され、（許可ユーザによって）読み取られるデータが復号化されるように、データ読み取りおよびデータ書き込みを代行受信することによって実施されうる。
【産業上の利用可能性】
【０１３０】
本明細書に説明されるシステムは、たとえばデータ圧縮を含む、他の任意のデータ変更アルゴリズムに加えて実装されてもよい。暗号モジュールおよび復号モジュールはデータを同時に圧縮することができ、かつ／またはデータは暗号化／復号化の前または後までに圧縮される。さらに、一部の実施形態について、暗号化／復号化アルゴリズムがユーザ独自のカスタマイズ・アルゴリズムを提供するユーザにしか知られないように、ユーザがデータの暗号化および復号化にカスタマイズ・モジュールを提供し、システムが読み取りおよび書き込み（およびデータ移行）のデータ・ストリームを代行受信するフックを提供する暗号化／復号化がユーザ・モジュールによって提供される。本明細書の実施形態において、暗号化されたデータは、復号化されたデータと同じサイズである。
【０１３１】
本明細書に説明されるシステムは、データが特定のロケーションから読み取られ、暗号化された後、同じロケーションに戻される「同所」データ移行を使用して実施されうる。そのようなシステムにおいて、各ブロックが暗号化されるかどうかを示すために、フラグ（または他の適切な機構）が使用されてもよい。もちろん、データを別のロケーションに移動せざるを得ない状態を避けるために、暗号化されたデータが暗号化されていないデータと同じサイズであれば有益である。また、特定のブロックがすでに暗号化されているかどうかを示すインジケータ（たとえばフラグ）の値に応じて、各ブロックが復号化されることも復号化されないこともある、そのような「同所」移行が発生している間にファイル（またはボリューム）をアクセス可能にできることにも留意されたい。「同所」移行が完了すると、ファイル（またはボリューム）のすべてのデータは暗号化されて、インジケータを確認する必要はもはやなくなる。
【０１３２】
セキュリティを追加するために、公開鍵／秘密鍵ペアがストレージ・デバイスによって認識される機関によりデジタル署名される必要があることを要求することができる。したがって、公開鍵が公認の機関（たとえば、ＰＫＩ ＣＡ）によってデジタル署名されていない限り、すべての公開鍵／秘密鍵ペアを拒否する機構があるので、鍵データベース３６２に独自の公開鍵／秘密鍵ペアを書き込もうと試みる悪意ある（無許可の）ユーザは困難におちいる。一部の実施形態において、セキュリティを追加するために、機関は、証明書が改ざんされていない（つまり引き続き有効である）ことを示す独自のデジタル証明書および証拠を提示することを要求されうる。そのような証拠は、Ｘ−５０９ ＰＫＩ ＣＲＬの形態をとるか、またはデジタル証明書が失効していないことを証明する他の適切な機構であってもよい。一部の実施形態において、機関によって提示されるデジタル証明書は、公開鍵／秘密鍵ペアの一部である公開鍵を含むこともできる。
【０１３３】
したがって、前述のすべての説明と、本発明の真の精神および範囲にあるその他の変形および変更を対象とすることは、添付の特許請求の範囲の目的である。
【図面の簡単な説明】
【０１３４】
【図１】本発明から利益を享受することができ、複数データ・ストレージ設備を含む複数ホスト・データ処理システムを示すブロック図。
【図２】アプリケーションとデータ・セットとの間の標準的な従来技術の対話を示す流れ図。
【図３】本発明により動作する論理移行アプリケーションの編成を示すブロック図。
【図４】コマンドに応答する論理移行アプリケーションの動作を示す流れ図。
【図５】図３に示される初期化モジュールの動作を示す流れ図。
【図５Ａ】図５に示される動作を示す詳細な流れ図。
【図６】図５に示される初期化モジュールによって生成されたデータ構造の１つの例を示すブロック図。
【図７】図３に示される移行および転換モジュールの動作を示す流れ図。
【図７Ａ】図７に示される動作を示す詳細な流れ図。
【図７Ｂ】図７に示される動作を示す詳細な流れ図。
【図７Ｃ】図７に示される動作を示す詳細な流れ図。
【図８】図３に示される監視モジュールの動作を示す流れ図。
【図９】図３に示される終了モジュールの動作を示す流れ図。
【図１０】動的データ・セット移行を実行するかどうかを決定する工程を示す流れ図。
【図１１】データ・セット移行に対するターゲット論理デバイスの選択を示す流れ図。
【図１２】動的データ・セット移行を実行するかどうかを決定する代替実施形態を示す流れ図。
【図１３】本発明により動作する論理移行アプリケーションの代替実施形態の編成を示すブロック図。
【図１４】本明細書において説明されるシステムによる暗号化モジュールの実施形態を示す図。
【図１５】データ移行が本明細書に説明される暗号化と結合されるときにデータ移行に関連して実行される工程を示す流れ図。
【図１６】本明細書に説明されるシステムによるデータ暗号化に関連して実行されうる工程を示す流れ図。
【図１７Ａ】ストレージ・デバイスが不正改ざん防止モジュールを含む実施形態を示す図。
【図１７Ｂ】複数のホストデバイスが各々不正改ざん防止モジュールを含むことができる実施形態を示す図。
【図１８】本明細書に説明されるシステムの実施形態による不正改ざん防止モジュールのコンポーネントを示す図。
【特許請求の範囲】
【請求項１】
ストレージ・デバイス上でデータを管理する方法であって、
該ストレージ・デバイス上に該データを格納するアプリケーションに透過的である、暗号化されていないデータが該ストレージ・デバイス上に格納されることを中断すること、
該ストレージ・デバイス上に格納する前に該データを暗号化すること、
を備える方法。
【請求項２】
前記ストレージ・デバイスはテープ・ドライブを含む、請求項１に記載の方法。
【請求項３】
前記ストレージ・デバイスはディスク・ドライブを含む、請求項１に記載の方法。
【請求項４】
第１のストレージ・ロケーションから第２のストレージ・ロケーションへデータを移行すること
をさらに備える、請求項１に記載の方法。
【請求項５】
前記第１のストレージ・ロケーションは前記第２のストレージ・ロケーションと同じである、請求項４に記載の方法。
【請求項６】
前記第１のストレージ・ロケーションは前記第２のストレージ・ロケーションと異なる、請求項４に記載の方法。
【請求項７】
暗号化されていないデータは移行中に中断される、請求項４に記載の方法。
【請求項８】
前記ストレージ・デバイスから読み取られたデータを復号化すること
をさらに備える、請求項１に記載の方法。
【請求項９】
データを復号化することは、使用が制限されている秘密復号鍵を使用する工程を含む、請求項６に記載の方法。
【請求項１０】
前記秘密鍵へのアクセスを制限する、秘密鍵を格納してデータを復号化する不正改ざん防止モジュールを使用すること
をさらに備える、請求項９に記載の方法。
【請求項１】
ストレージ・デバイス上でデータを管理する方法であって、
該ストレージ・デバイス上に該データを格納するアプリケーションに透過的である、暗号化されていないデータが該ストレージ・デバイス上に格納されることを中断すること、
該ストレージ・デバイス上に格納する前に該データを暗号化すること、
を備える方法。
【請求項２】
前記ストレージ・デバイスはテープ・ドライブを含む、請求項１に記載の方法。
【請求項３】
前記ストレージ・デバイスはディスク・ドライブを含む、請求項１に記載の方法。
【請求項４】
第１のストレージ・ロケーションから第２のストレージ・ロケーションへデータを移行すること
をさらに備える、請求項１に記載の方法。
【請求項５】
前記第１のストレージ・ロケーションは前記第２のストレージ・ロケーションと同じである、請求項４に記載の方法。
【請求項６】
前記第１のストレージ・ロケーションは前記第２のストレージ・ロケーションと異なる、請求項４に記載の方法。
【請求項７】
暗号化されていないデータは移行中に中断される、請求項４に記載の方法。
【請求項８】
前記ストレージ・デバイスから読み取られたデータを復号化すること
をさらに備える、請求項１に記載の方法。
【請求項９】
データを復号化することは、使用が制限されている秘密復号鍵を使用する工程を含む、請求項６に記載の方法。
【請求項１０】
前記秘密鍵へのアクセスを制限する、秘密鍵を格納してデータを復号化する不正改ざん防止モジュールを使用すること
をさらに備える、請求項９に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図５Ａ】
【図６】
【図７】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７Ａ】
【図１７Ｂ】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図５Ａ】
【図６】
【図７】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７Ａ】
【図１７Ｂ】
【図１８】
【公表番号】特表２００８−５４４４１０（Ｐ２００８−５４４４１０Ａ）
【公表日】平成２０年１２月４日（２００８．１２．４）
【国際特許分類】
【出願番号】特願２００８−５１８４５２（Ｐ２００８−５１８４５２）
【出願日】平成１８年６月２３日（２００６．６．２３）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０２４５３５
【国際公開番号】ＷＯ２００７／００２４３８
【国際公開日】平成１９年１月４日（２００７．１．４）
【出願人】（５０３０９３２２４）イーエムシー コーポレイション (63)
【氏名又は名称原語表記】ＥＭＣ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２０年１２月４日（２００８．１２．４）
【国際特許分類】
【出願日】平成１８年６月２３日（２００６．６．２３）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０２４５３５
【国際公開番号】ＷＯ２００７／００２４３８
【国際公開日】平成１９年１月４日（２００７．１．４）
【出願人】（５０３０９３２２４）イーエムシー コーポレイション (63)
【氏名又は名称原語表記】ＥＭＣ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]