(57)【要約】  オペレーショナルデータ・レコードを、冗長なデータコピーを減らす方法で同期するためのシステムおよび方法を提供する。一連のオペレーショナルデータ・レコードが格納され、各データレコードには固有のＩＤが、データレコードの生成時間を基礎として昇順で割り当てられる。一連のオペレーショナルデータ・レコードにおけるオペレーショナルデータ・レコードから、最高位の固有のＩＤが識別される。公差数未満の数だけ離れた固有のＩＤを有するオペレーショナルデータ・レコードに、オペレーショナルデータ・レコード作成順の固有のＩＤが割り当てられたことが保証され得ないように、同時に処理されることが可能な固有のＩＤの範囲を示す公差数が識別される。最高位の固有のＩＤから公差数を減じることを含み、同期化ＩＤが計算される。同期化ＩＤは、ソースのオペレーショナルデータ・ストアへ送信される。
2015525419.tif 000002
【特許請求の範囲】
【請求項１】
バックアップフレームワークにおけるプロセス内通信のためのコンピュータ化された方法であって、
コンピューティングデバイスにより、カスタムリクエスタを、１つまたは複数のリクエスタおよび１つまたは複数のプロバイダを実行しかつ調和するように構成されるフレームワークに登録することであって、前記フレームワークは、前記１つまたは複数のリクエスタおよび前記１つまたは複数のプロバイダのためのアプリケーション・プログラマ・インタフェースを提供するが、前記フレームワークは、前記１つまたは複数のリクエスタと前記１つまたは複数のプロバイダとの間の直接的な通信のためのインタフェースを提供せず、
前記１つまたは複数のリクエスタのそれぞれは、あるアプリケーションに関連づけられるデータセットのバックアップを要求するように構成されるコンピュータ化されたプロセスであり、かつ、
前記１つまたは複数のプロバイダのそれぞれは、あるアプリケーションに関連づけられるデータセットのバックアップを生成するように構成されるコンピュータ化されたプロセスを備えることと、
前記コンピューティングデバイスにより、前記１つまたは複数のリクエスタからの第１のリクエスタを用いて、第１のアプリケーションに関連づけられる第１のデータセットのためのバックアッププロセスを開始することと、
前記コンピューティングデバイスにより、前記第１のリクエスタを用いて、前記第１のデータセットおよび前記第１のアプリケーションに関連づけられるデータ・ストレージ・デバイスが、前記コンピューティングデバイスに関連づけられるデータ管理システムによってエクスポートされることを決定することと、
前記コンピューティングデバイスにより、前記第１のリクエスタを用いて、前記バックアッププロセスのための前記第１のデータセットのバックアップを生成するために、前記１つまたは複数のプロバイダから第１のプロバイダを選択することであって、前記第１のリクエスタおよび前記第１のプロバイダは、前記第１のリクエスタおよび第１のプロバイダが１つまたは複数のプロセス内通信チャネルを用いて互いに直に通信できるように、同じプロセススペースにおける別個のスレッドであること、を含むコンピュータ化された方法。
【請求項２】
前記コンピューティングデバイスにより、前記第１のリクエスタを用いて、前記第１のデータセットおよび前記第１のアプリケーションに関連づけられるデータ・ストレージ・デバイスが、前記コンピューティングデバイスに関連づけられる前記データ管理システムによってエクスポートされないことを決定することと、
前記コンピューティングデバイスにより、前記フレームワークへ、前記フレームワークが前記バックアッププロセスのための前記第１のデータセットのバックアップを生成すべく前記１つまたは複数のプロバイダから第２のプロバイダを選択するように、バックアッププロセスの要求を送信することであって、前記第１のリクエスタおよび第２のプロバイダは、前記第１のリクエスタおよび第２のプロバイダが互いに直に通信できない代わりに前記フレームワークを介して通信できるように別個のプロセスであること、をさらに含む、請求項１に記載のコンピュータ化された方法。
【請求項３】
前記フレームワークは、ＭｉｃｒｏｓｏｆｔのＶｏｌｕｍｅ  Ｓｈａｄｏｗ  Ｃｏｐｙ  Ｓｅｒｖｉｃｅであり、かつ前記第２のプロバイダは、ＭｉｃｒｏｓｏｆｔのＳｎａｐｓｈｏｔ  Ｐｒｏｖｉｄｅｒである、請求項２に記載のコンピュータ化された方法。
【請求項４】
前記リクエスタが、前記フレームワークにより、前記第１のプロバイダがその関連の機能を完了するまでブロックされるように、前記第１のリクエスタにより、前記フレームワークへ前記バックアップを開始する要求を送信することと、
前記第１のプロバイダにより、前記フレームワークから、前記第１のデータセットのスナップショットを生成する第２の要求を受信することと、
前記第１のプロバイダにより、前記第１のリクエスタへ、前記フレームワークは前記スナップショットを生成する用意が調っているという通知を送信すること、をさらに含む、請求項２に記載のコンピュータ化された方法。
【請求項５】
前記第１のリクエスタにより、前記データ管理システムへ、前記第１のデータセットのスナップショットを生成するためのメッセージを送信することと、
前記第１のリクエスタにより、前記データ管理システムから、前記スナップショットが生成されつつあることを示す第２のメッセージを受信することと、
前記第１のリクエスタにより、前記第１のプロバイダへ、前記スナップショットが生成されたというメッセージを送信すること、をさらに含む、請求項４に記載の方法。
【請求項６】
前記フレームワークは、ＭｉｃｒｏｓｏｆｔのＶｏｌｕｍｅ  Ｓｈａｄｏｗ  Ｃｏｐｙ  Ｓｅｒｖｉｃｅ（ＶＳＳ）であり、前記１つまたは複数のプロバイダは、ＶＳＳプロバイダであり、かつ前記１つまたは複数のリクエスタは、ＶＳＳリクエスタである、請求項１に記載の方法。
【請求項７】
前記フレームワークは、さらに、前記フレームワークにより管理されるデータを書き込みかつ更新するように構成されるＶＳＳライタを備える、請求項６に記載の方法。
【請求項８】
前記第１のリクエスタにより、コールバックハンドラを前記第１のプロバイダに登録することと、
前記第１のプロバイダにより、前記コールバックハンドラを用いて前記第１のリクエスタと通信すること、をさらに含む、請求項１に記載の方法。
【請求項９】
バックアップフレームワークにおけるプロセス内通信のためのコンピューティングデバイスであって、サーバは、
データベースと、
前記データベースと通信状態にあり、かつメモリに格納されるモジュールを実行するように構成されるプロセッサと、を備え、前記モジュールは、前記プロセッサに、
カスタムリクエスタを、１つまたは複数のリクエスタおよび１つまたは複数のプロバイダを実行しかつ調和するように構成されるフレームワークに登録させ、前記フレームワークは、前記１つまたは複数のリクエスタおよび前記１つまたは複数のプロバイダのためのアプリケーション・プログラマ・インタフェースを提供するが、前記フレームワークは、前記１つまたは複数のリクエスタおよび前記１つまたは複数のプロバイダとの間の直接的な通信のためのインタフェースを提供せず、
前記１つまたは複数のリクエスタのそれぞれは、あるアプリケーションに関連づけられるデータセットのバックアップを要求するように構成されるコンピュータ化されたプロセスであり、かつ、
前記１つまたは複数のプロバイダのそれぞれは、あるアプリケーションに関連づけられるデータセットのバックアップを生成するように構成されるコンピュータ化されたプロセスであり、
前記１つまたは複数のリクエスタからの第１のリクエスタを用いて、第１のアプリケーションに関連づけられる第１のデータセットのためのバックアッププロセスを開始させ、
前記第１のリクエスタを用いて、前記第１のデータセットおよび前記第１のアプリケーションに関連づけられるデータ・ストレージ・デバイスが、前記コンピューティングデバイスに関連づけられるデータ管理システムによってエクスポートされることを決定させ、かつ、
前記第１のリクエスタを用いて、前記バックアッププロセスのための前記第１のデータセットのバックアップを生成するために、前記１つまたは複数のプロバイダから第１のプロバイダを選択させるように構成され、前記第１のリクエスタおよび前記第１のプロバイダは、前記第１のリクエスタおよび第１のプロバイダが１つまたは複数のプロセス内通信チャネルを用いて互いに直に通信できるように、同じプロセススペースにおける別個のスレッドである、コンピューティングデバイス。
【請求項１０】
実行可能命令を有する非一時的コンピュータ可読媒体であって、前記実行可能命令は、装置に、
カスタムリクエスタを、１つまたは複数のリクエスタおよび１つまたは複数のプロバイダを実行しかつ調和するように構成されるフレームワークに登録させ、前記フレームワークは、前記１つまたは複数のリクエスタおよび前記１つまたは複数のプロバイダのためのアプリケーション・プログラマ・インタフェースを提供するが、前記フレームワークは、前記１つまたは複数のリクエスタおよび前記１つまたは複数のプロバイダとの間の直接的な通信のためのインタフェースを提供せず、
前記１つまたは複数のリクエスタのそれぞれは、あるアプリケーションに関連づけられるデータセットのバックアップを要求するように構成されるコンピュータ化されたプロセスであり、かつ、
前記１つまたは複数のプロバイダのそれぞれは、あるアプリケーションに関連づけられるデータセットのバックアップを生成するように構成されるコンピュータ化されたプロセスであり、
前記１つまたは複数のリクエスタからの第１のリクエスタを用いて、第１のアプリケーションに関連づけられる第１のデータセットのためのバックアッププロセスを開始させ、
前記第１のリクエスタを用いて、前記第１のデータセットおよび前記第１のアプリケーションに関連づけられるデータ・ストレージ・デバイスが、前記コンピューティングデバイスに関連づけられるデータ管理システムによってエクスポートされることを決定させ、かつ、
前記第１のリクエスタを用いて、前記バックアッププロセスのための前記第１のデータセットのバックアップを生成するために、前記１つまたは複数のプロバイダから第１のプロバイダを選択させるように動作可能であり、前記第１のリクエスタおよび前記第１のプロバイダは、前記第１のリクエスタおよび第１のプロバイダが１つまたは複数のプロセス内通信チャネルを用いて互いに直に通信できるように、同じプロセススペースにおける別個のスレッドである、非一時的コンピュータ可読媒体。
【請求項１１】
アウトオブバンド・ストレージをバックアップするためのコンピュータ化された方法であって、
コンピューティングデバイスにより、リモートホストにおけるアウトオブバンド・ストレージの保護ポリシーを起動することであって、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスによる物理的なアクセスは不可であり、よって、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスを介して前記リモートホストと通信していないことと、
前記コンピューティングデバイスにより、前記リモートホストへ、前記保護ポリシーに従ってバックアップすべき前記アウトオブバンド・ストレージのボリュームを示すデータを含むバックアップ要求を送信することと、
前記コンピューティングデバイスにより、前記ボリュームのステージングディスク要件を示すデータを含む前記バックアップ要求に対する応答を受信することであって、前記ステージングディスク要件は、前記ボリュームをバックアップするために要するステージングディスクのサイズを含むことと、
前記コンピューティングデバイスにより、前記応答を基礎としてステージングディスクを決定することと、
前記コンピューティングデバイスにより、前記ステージングディスクを前記リモートホストへ提示することと、
前記コンピューティングデバイスにより、前記リモートホストから、前記ボリュームの前記ステージングディスクへのバックアップが成功したか失敗したかを示すデータを含むバックアップ結果を受信すること、を含むコンピュータ化された方法。
【請求項１２】
前記バックアップの結果を基礎として、前記バックアップが失敗したことを決定することと、
前記バックアップ結果におけるエラーコードを識別し、かつ前記エラーコードを格納すること、をさらに含む、請求項１１に記載の方法。
【請求項１３】
前記バックアップの結果を基礎として、前記バックアップが成功したことを決定することと、
前記ステージングディスクのポイントインタイム・スナップショットを生成することと、
前記ステージングディスクの前記ポイントインタイム・スナップショットを前記ボリュームの最新バックアップとしてカタログに入れること、をさらに含む請求項１１に記載の方法。
【請求項１４】
前記応答を基礎として前記ステージングディスクを決定することは、
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットを識別することと、
前記先にカタログに入れられているボリュームのポイントインタイム・イメージを前記ステージングディスクとして用いること、を含み、前記アウトオブバンド・ストレージにおける前記ポイントインタイム・イメージから変化した情報のみをコピーするために、前記ファイルシステム情報を用いて前記先にカタログに入れられているポイントインタイム・イメージが前記アウトオブバンド・ストレージと比較される、請求項１１に記載の方法。
【請求項１５】
前記応答を基礎として前記ステージングディスクを決定することは、
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットは存在しないことを決定することと、
前記コンピューティングデバイスのデータストレージからの、前記ステージングディスク要件からの前記要求されたサイズに基づくサイズを有するステージングディスクを割り付けること、を含む、請求項１１に記載の方法。
【請求項１６】
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットが期限切れになったことを決定することと、
前記先にカタログに入れられているポイントインタイム・スナップショットを削除すること、をさらに含む、請求項１１に記載の方法。
【請求項１７】
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットが前記ステージングディスク要件からの前記要求されたサイズより少ないサイズを含む先行するステージングディスクに関連づけられることを決定することと、
前記ステージングディスク要件からの前記要求されたサイズに基づくサイズを有する前記コンピューティングデバイスのデータストレージからのステージングディスクを割り付けること、をさらに含み、前記ステージングディスクは、前記先にカタログに入れられているポイントインタイム・スナップショットを含まない、請求項１１に記載の方法。
【請求項１８】
前記リモートホストに格納される前記アウトオブバンド・ストレージには、前記リモートデバイスの内蔵ディスク、ネットワークドライブまたはこれらの任意の組合せが含まれる、請求項１１に記載の方法。
【請求項１９】
アウトオブバンド・ストレージをバックアップするためのコンピューティングデバイスであって、サーバは、
ストレージプールと、
データベースと通信状態にあり、かつメモリに格納されるモジュールを実行するように構成されるプロセッサと、を備え、前記モジュールは、前記プロセッサに、
リモートホストにおけるアウトオブバンド・ストレージの保護ポリシーを起動させ、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスによる物理的なアクセスは不可であり、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスを介して前記リモートホストと通信しておらず、
前記リモートホストへ、前記保護ポリシーに従ってバックアップすべき前記アウトオブバンド・ストレージのボリュームを示すデータを含むバックアップ要求を送信させ、
前記ボリュームのステージングディスク要件を示すデータを含む前記バックアップ要求に対する応答を受信させ、前記ステージングディスク要件は、前記ボリュームをバックアップするために要するステージングディスクのサイズを含み、
前記応答を基礎として前記ストレージプールからステージングディスクを決定させ、
前記ステージングディスクを前記リモートホストへ提示させ、かつ、
前記リモートホストから、前記ボリュームの前記ステージングディスクへのバックアップが成功したか失敗したかを示すデータを含むバックアップ結果を受信させるように構成される、コンピューティングデバイス。
【請求項２０】
実行可能命令を有する非一時的コンピュータ可読媒体であって、前記実行可能命令は、装置に、
リモートホストにおけるアウトオブバンド・ストレージの保護ポリシーを起動させ、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスによる物理的なアクセスは不可であり、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスを介して前記リモートホストと通信しておらず、
前記リモートホストへ、前記保護ポリシーに従ってバックアップすべき前記アウトオブバンド・ストレージのボリュームを示すデータを含むバックアップ要求を送信させ、
前記ボリュームのステージングディスク要件を示すデータを含む前記バックアップ要求に対する応答を受信させ、前記ステージングディスク要件は、前記ボリュームをバックアップするために要するステージングディスクのサイズを含み、
前記応答を基礎としてステージングディスクを決定させ、
前記ステージングディスクを前記リモートホストへ提示させ、かつ、
前記リモートホストから、前記ボリュームの前記ステージングディスクへのバックアップが成功したか失敗したかを示すデータを含むバックアップ結果を受信させるように構成される、非一時的コンピュータ可読媒体。
【請求項２１】
データベースストレージをバックアップするためのコンピュータ化された方法であって、
コンピューティングデバイスにより、リモートホストにおけるデータベースストレージの保護ポリシーを起動することであって、前記データベースストレージは、前記コンピューティングデバイスによる物理的なアクセスは不可であり、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスを介して前記リモートホストと通信していないことと、
前記コンピューティングデバイスにより、前記リモートホストへ、前記保護ポリシーに従ってバックアップすべき前記データベースストレージのボリュームを示すデータを含むバックアップ要求を送信することと、
前記コンピューティングデバイスにより、前記ボリュームのステージングディスク要件を示すデータを含む前記バックアップ要求に対する応答を受信することであって、前記ステージングディスク要件は、前記ボリュームをバックアップするために要するステージングディスクのサイズを含むことと、
前記コンピューティングデバイスにより、前記応答を基礎としてステージングディスクを決定することと、
前記リモートホストが、前記データベースストレージのベンダーによって提供されるデータベース・バックアップ・ツールを用いて前記ボリュームの前記ステージングディスクへのバックアップを実行できるように、前記コンピューティングデバイスにより、前記ステージングディスクを前記リモートホストへ提示することと、
前記コンピューティングデバイスにより、前記リモートホストから、前記ボリュームの前記ステージングディスクへのバックアップが成功したか失敗したかを示すデータを含むバックアップ結果を受信することであって、前記ボリュームの前記ステージングディスクへのバックアップは、前記データベースストレージのベンダーによって提供されるデータベース・バックアップ・ツールを用いて実行されたこと、を含むコンピュータ化された方法。
【請求項２２】
前記バックアップの結果を基礎として、前記バックアップが失敗したことを決定することと、
前記バックアップ結果におけるエラーコードを識別し、かつ前記エラーコードを格納すること、をさらに含む、請求項２１に記載の方法。
【請求項２３】
前記バックアップの結果を基礎として、前記バックアップが成功したことを決定することと、
前記ステージングディスクのポイントインタイム・スナップショットを生成することと、
前記ステージングディスクの前記ポイントインタイム・スナップショットを前記ボリュームの最新バックアップとしてカタログに入れること、をさらに含む、請求項２１に記載の方法。
【請求項２４】
前記応答を基礎として前記ステージングディスクを決定することは、
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットを識別することと、
前記先にカタログに入れられているポイントインタイム・イメージを前記ステージングディスクとして用いること、をさらに含む、請求項２１に記載の方法。
【請求項２５】
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットを識別することは、
前記バックアップ要求への応答における前記ステージングディスク要件において固有の署名を受信することと、
前記要求されるサイズおよび前記固有の署名を基礎として、前記先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットを識別すること、を含む、請求項２４に記載の方法。
【請求項２６】
前記応答を基礎として前記ステージングディスクを決定することは、
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットは存在しないことを決定することと、
前記コンピューティングデバイスのデータストレージからの、前記ステージングディスク要件からの前記要求されたサイズに基づくサイズを有するステージングディスクを割り付けること、を含む、請求項２１に記載の方法。
【請求項２７】
前記サイズは、ストレージを使い果たすことなく前記ステージングディスクへのバックアップを繰り返すことができる前記ステージングディスクのサイズを指定する予め決められたしきい値を基礎として計算される、請求項２６に記載の方法。
【請求項２８】
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットが期限切れになったことを決定することと、
前記先にカタログに入れられているポイントインタイム・スナップショットを削除すること、をさらに含む、請求項２１に記載の方法。
【請求項２９】
先にカタログに入れられている前記ボリュームのポイントインタイム・スナップショットが前記ステージングディスク要件からの前記要求されたサイズより少ないサイズを含む先行するステージングディスクに関連づけられることを決定することと、
前記ステージングディスク要件からの前記要求されたサイズに基づくサイズを有する前記コンピューティングデバイスのデータストレージからのステージングディスクを割り付けること、をさらに含み、前記ステージングディスクは、前記先にカタログに入れられているポイントインタイム・スナップショットを含まない、請求項２１に記載の方法。
【請求項３０】
前記リモートホストに格納される前記データベースストレージには、前記リモートデバイスの内蔵ディスク上のデータベース、ネットワークドライブ上のデータベースまたはこれらの任意の組合せが含まれる、請求項２１に記載の方法。
【請求項３１】
前記データベースストレージは、Ｏｒａｃｌｅのデータベースであり、かつ前記データベース・バックアップ・ツールは、ＯｒａｃｌｅのＲＭＡＮコマンドである、請求項２１に記載の方法。
【請求項３２】
データベースストレージをバックアップするためのコンピューティングデバイスであって、サーバは、
ストレージプールと、
前記データベースと通信状態にあり、かつメモリに格納されるモジュールを実行するように構成されるプロセッサと、を備え、前記モジュールは、前記プロセッサに、
リモートホストにおけるデータベースストレージの保護ポリシーを起動させ、前記データベースストレージは、前記コンピューティングデバイスによる物理的なアクセスは不可であり、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスを介して前記リモートホストと通信しておらず、
前記リモートホストへ、前記保護ポリシーに従ってバックアップすべき前記データベースストレージのボリュームを示すデータを含むバックアップ要求を送信させ、
前記ボリュームのステージングディスク要件を示すデータを含む前記バックアップ要求に対する応答を受信させ、前記ステージングディスク要件は、前記ボリュームをバックアップするために要するステージングディスクのサイズを含み、
前記応答を基礎としてステージングディスクを決定させ、
前記ステージングディスクを前記リモートホストへ提示させ、前記ステージングディスクは、前記ストレージプールから割り付けられ、よって、前記リモートホストは、前記データベースストレージのベンダーによって提供されるデータベース・バックアップ・ツールを用いて前記ボリュームの前記ステージングディスクへのバックアップを実行することができ、かつ、
前記リモートホストから、前記ボリュームの前記ステージングディスクへのバックアップが成功したか失敗したかを示すデータを含むバックアップ結果を受信させるように構成され、前記ボリュームの前記ステージングディスクへのバックアップは、前記データベースストレージのベンダーによって提供されるデータベース・バックアップ・ツールを用いて実行された、コンピューティングデバイス。
【請求項３３】
実行可能命令を有する非一時的コンピュータ可読媒体であって、前記実行可能命令は、装置に、
リモートホストにおけるデータベースストレージの保護ポリシーを起動させ、前記データベースストレージは、前記コンピューティングデバイスによる物理的なアクセスは不可であり、よって、前記アウトオブバンド・ストレージは、前記コンピューティングデバイスを介して前記リモートホストと通信しておらず、
前記リモートホストへ、前記保護ポリシーに従ってバックアップすべき前記データベースストレージのボリュームを示すデータを含むバックアップ要求を送信させ、
前記ボリュームのステージングディスク要件を示すデータを含む前記バックアップ要求に対する応答を受信させ、前記ステージングディスク要件は、前記ボリュームをバックアップするために要するステージングディスクのサイズを含み、
前記応答を基礎としてステージングディスクを決定させ、
前記リモートホストが、前記データベースストレージのベンダーによって提供されるデータベース・バックアップ・ツールを用いて前記ボリュームの前記ステージングディスクへのバックアップを実行できるように、前記ステージングディスクを前記リモートホストへ提示させ、かつ、
前記リモートホストから、前記ボリュームの前記ステージングディスクへのバックアップが成功したか失敗したかを示すデータを含むバックアップ結果を受信させるように構成され、前記ボリュームの前記ステージングディスクへのバックアップは、前記データベースストレージのベンダーによって提供されるデータベース・バックアップ・ツールを用いて実行された、非一時的コンピュータ可読媒体。
【請求項３４】
データ管理仮想化システムの一連のサービスに亘ってユーザインタフェースの動作を自動的に実行するデータ管理仮想化ディスプレイを実装するためのコンピュータ化された方法であって、前記データ管理仮想化システムは、一連のサブシステムを含み、前記コンピュータ化された方法は、
コンピューティングデバイスにより、一連のサービスをデータストアに格納することであって、
各サービスは、前記各サービスに関連づけられる一連のユーザインタフェースを含み、かつ、
各サービスは、共有サービスキャッシュを用いて残りのサービスと通信することができ、前記共有サービスキャッシュは、前記各サービスが、前記一連のサービスにおける前記残りのサービスからデータを受信し、前記一連のサービスにおける前記残りのサービスへデータを送信し、前記一連のサービスに亘ってデータを保存すること、またはこれらの任意の組合せの実行を可能にすることと、
前記コンピューティングデバイスにより、前記データ管理仮想化システム、前記一連のサブシステムまたはこれらの双方に関連づけられるプロファイルを認識することなく前記データ管理仮想化システムのユーザに前記一連のサービスにおける２つ以上のサービスに亘って一連のウェブページを手動でナビゲートするように要求するデータ管理仮想化ジョブ、を実行する要求を受信することと、
前記コンピュータデバイスにより、前記共有サービスキャッシュを使用し、前記データ管理仮想化システム、前記一連のサブシステムまたはこれらの双方に関連づけられるプロファイルを基礎として前記データ管理仮想化ジョブのためのクイックリンクを画定すること、を含み、前記クイックリンクは、前記データ管理仮想化ジョブの前記手動ナビゲーションのうちの１つまたはそれ以上を排除する、コンピュータ化された方法。
【請求項３５】
前記データ管理仮想化ディスプレイは、モデル・ビュー・コントローラ（ＭＶＣ）を拡張し、前記データ管理仮想化ディスプレイのデータは、各サービスの一連のユーザインタフェースをデータへリンクするコントローラによって、各サービスの一連のユーザインタフェースから、かつ前記一連のサービスから分離される、請求項３４に記載の方法。
【請求項３６】
各サービスは、サービスオブジェクトによって規定され、前記サービスオブジェクトは、その関連のサービスについて、
前記サービスの前記一連のユーザインタフェースと、
前記サービスの前記一連のユーザインタフェースを制御するように構成される前記サービスのウィンドウマネージャと、
前記一連のサービスからの他のサービスとの前記共有キャッシュを介する一連の相互作用と、を規定する、請求項３４に記載の方法。
【請求項３７】
前記一連のサブシステムには、データ管理サブシステム、データ保護サブシステム、災害リカバリサブシステムおよびビジネス継続サブシステムが含まれる、請求項３４に記載の方法。
【請求項３８】
データ管理仮想化システムの一連のサービスに亘ってユーザインタフェースの動作を自動的に実行するデータ管理仮想化ディスプレイを実装するためのコンピューティングデバイスであって、前記データ管理仮想化システムは、一連のサブシステムを含み、前記コンピューティングデバイスは、
メモリと、
前記メモリと通信状態にあり、かつメモリに格納されるモジュールを実行するように構成されるプロセッサと、を備え、前記モジュールは、前記プロセッサに、
一連のサービスをデータストアに格納させ、
各サービスは、前記各サービスに関連づけられる一連のユーザインタフェースを含み、かつ、
各サービスは、共有サービスキャッシュを用いて残りのサービスと通信することができ、前記共有サービスキャッシュは、前記各サービスが、前記一連のサービスにおける前記残りのサービスからデータを受信し、前記一連のサービスにおける前記残りのサービスへデータを送信し、前記一連のサービスに亘ってデータを保存すること、またはこれらの任意の組合せの実行を可能にし、
前記データ管理仮想化システム、前記一連のサブシステムまたはこれらの双方に関連づけられるプロファイルを認識することなく前記データ管理仮想化システムのユーザに前記一連のサービスにおける２つ以上のサービスに亘って一連のウェブページを手動でナビゲートするように要求するデータ管理仮想化ジョブ、を実行する要求を受信させ、かつ、
前記共有サービスキャッシュを使用し、前記データ管理仮想化システム、前記一連のサブシステムまたはこれらの双方に関連づけられるプロファイルを基礎として前記データ管理仮想化ジョブのためのクイックリンクを画定させるように構成され、前記クイックリンクは、前記データ管理仮想化ジョブの前記手動ナビゲーションのうちの１つまたはそれ以上を排除する、コンピューティングデバイス。
【請求項３９】
実行可能命令を有する非一時的コンピュータ可読媒体であって、前記実行可能命令は、装置に、
一連のサービスをデータストアに格納させ、
各サービスは、前記各サービスに関連づけられる一連のユーザインタフェースを含み、かつ、
各サービスは、共有サービスキャッシュを用いて残りのサービスと通信することができ、前記共有サービスキャッシュは、前記各サービスが、前記一連のサービスにおける前記残りのサービスからデータを受信し、前記一連のサービスにおける前記残りのサービスへデータを送信し、前記一連のサービスに亘ってデータを保存すること、またはこれらの任意の組合せの実行を可能にし、
前記データ管理仮想化システム、前記一連のサブシステムまたはこれらの双方に関連づけられるプロファイルを認識することなく前記データ管理仮想化システムのユーザに前記一連のサービスにおける２つ以上のサービスに亘って一連のウェブページを手動でナビゲートするように要求するデータ管理仮想化ジョブ、を実行する要求を受信させ、かつ、
前記共有サービスキャッシュを使用し、前記データ管理仮想化システム、前記一連のサブシステムまたはこれらの双方に関連づけられるプロファイルを基礎として前記データ管理仮想化ジョブのためのクイックリンクを画定させるように動作可能であり、前記クイックリンクは、前記データ管理仮想化ジョブの前記手動ナビゲーションのうちの１つまたはそれ以上を排除する、非一時的コンピュータ可読媒体。
【請求項４０】
データ管理オペレーションの間に生成されるオペレーショナルデータ・レコードを、同期中の冗長なデータコピーを減らす方法で同期するための方法であって、
中央オペレーショナルデータ・ストアにより、一連のオペレーショナルデータ・レコードを格納することであって、各データレコードには固有の識別子（ＩＤ）が、前記データレコードの生成時間を基礎として昇順で割り当てられることと、
前記中央オペレーショナルデータ・ストアにより、前記一連のオペレーショナルデータ・レコードにおける前記オペレーショナルデータ・レコードから最高位の固有のＩＤを識別することと、
公差数未満の数だけ離れた固有のＩＤを有する前記オペレーショナルデータ・レコードに、前記オペレーショナルデータ・レコードの作成順で固有のＩＤが割り当てられたことが保証され得ないように、前記中央オペレーショナルデータ・ストアにより、同時に処理されることが可能な固有のＩＤの範囲を示す前記公差数を識別することと、
前記最高位の固有のＩＤから前記公差数を減算することを含み、前記中央オペレーショナルデータ・ストアにより、同期ＩＤを計算することと、
前記ソースのオペレーショナルデータ・ストアに、前記ソースのオペレーショナルデータ・ストアに格納されている前記同期ＩＤより大きい固有のＩＤを有する任意のオペレーショナルデータ・レコードを送信するように指示するために、前記中央オペレーショナルデータ・ストアにより、前記ソースのオペレーショナルデータ・ストアへ前記同期ＩＤを送信すること、を含む、方法。
【請求項４１】
一連の固有のＩＤを前記一連のオペレーショナルデータ・レコードから識別することであって、前記一連の固有のＩＤにおける各固有のＩＤは、前記最高位の固有のＩＤと前記同期ＩＤとの間に存在することと、
前記ソースのオペレーショナルデータ・ストアに前記一連の固有のＩＤを有するオペレーショナルデータ・レコードを送信しないように指示するために、前記一連の固有のＩＤを前記ソースのオペレーショナルデータ・ストアへ送信すること、をさらに含む、請求項４０に記載の方法。
【請求項４２】
前記ソースのオペレーショナルデータ・ストアに前記最高位の固有のＩＤを有するオペレーショナルデータ・レコードを送信しないように指示するために、前記最高位の固有のＩＤを前記ソースのオペレーショナルデータ・ストアへ送信することをさらに含む、請求項４０に記載の方法。
【請求項４３】
前記公差数を、許可される同時的トランザクションの数、および最大遅延を基礎として計算することをさらに含む、請求項４０に記載の方法。
【請求項４４】
前記同時的トランザクションの数を２倍にすることをさらに含む、請求項４３に記載の方法。
【請求項４５】
各固有のＩＤは、単調増加する固有のＩＤである、請求項４０に記載の方法。
【請求項４６】
前記一連のオペレーショナルデータ・レコードは、１００，０００個を超えるオペレーショナルデータ・レコードを含む大規模なオペレーショナルデータ・レコード・セットであり、かつ前記一連のオペレーショナルデータ・レコードにおける前記データレコードは、一旦生成されると変わらない、請求項４０に記載の方法。
【請求項４７】
データ管理オペレーションの間に生成されるオペレーショナルデータ・レコードを、同期中の冗長なデータコピーを減らす方法で同期するための方法であって、
中央オペレーショナルデータ・ストアにより、一連のオペレーショナルデータ・レコードを格納することであって、各データレコードにはタイムスタンプが、前記データレコードの生成時間または修正時間の何れかを基礎として割り当てられることと、
前記中央オペレーショナルデータ・ストアにより、ソースのオペレーショナルデータ・ストアから前記一連のオペレーショナルデータ・レコードの最終のバックアップ時間を識別することと、
公差数未満の数だけ離れたタイムスタンプを有する前記オペレーショナルデータ・レコードに、前記オペレーショナルデータ・レコードの作成順または修正順、または双方のタイムスタンプが割り当てられたことが保証され得ないように、前記中央オペレーショナルデータ・ストアにより、経過時間を基礎として、同時に処理されることが可能なタイムスタンプの範囲を示す前記公差数を計算することと、
前記最終のバックアップ時間から前記公差数を減算することを含み、前記中央オペレーショナルデータ・ストアにより、同期化タイムスタンプを計算することと、
前記ソースのオペレーショナルデータ・ストアに、前記ソースのオペレーショナルデータ・ストアに格納されている前記同期化タイムスタンプより大きいタイムスタンプを有する任意のオペレーショナルデータ・レコードを送信するように指示するために、前記中央オペレーショナルデータ・ストアにより、前記ソースのオペレーショナルデータ・ストアへ前記同期化タイムスタンプを送信すること、を含む、方法。
【請求項４８】
各々が前記同期化タイムスタンプ後に生じるタイムスタンプを有する一連のオペレーショナルデータ・レコードと、
前記ソースのオペレーショナルデータ・ストアによって格納される各データレコードの固有のＩＤのリストと、を含む応答を受信することをさらに含む、請求項４７に記載の方法。
【請求項４９】
前記一連のオペレーショナルデータ・レコードにおける、前記固有のＩＤのリストに存在しない固有のＩＤを有するオペレーショナルデータ・レコードは、何れも削除することをさらに含む、請求項４８に記載の方法。
【請求項５０】
前記一連のオペレーショナルデータ・レコードは、１，０００個を超えるオペレーショナルデータ・レコードを含む、但し１００，０００個のオペレーショナルデータ・レコードより少ない中型のオペレーショナルデータ・レコード・セットである請求項４７に記載の方法。
【請求項５１】
実行可能命令を有する非一時的コンピュータ可読媒体であって、前記実行可能命令は、装置に、
一連のオペレーショナルデータ・レコードを格納させ、各データレコードには、前記データレコードの生成時間または修正時間の何れかを基礎としてタイムスタンプが割り当てられ、
ソースのオペレーショナルデータ・ストアから前記一連のオペレーショナルデータ・レコードの最終のバックアップ時間を識別させ、
公差数未満の数だけ離れたタイムスタンプを有する前記オペレーショナルデータ・レコードに、前記オペレーショナルデータ・レコードの作成順または修正順、または双方のタイムスタンプが割り当てられたことが保証され得ないように、経過時間を基礎として、同時に処理されることが可能なタイムスタンプの範囲を示す前記公差数を計算させ、
前記最終のバックアップ時間から前記公差数を減算することを含み、同期化タイムスタンプを計算させ、
前記ソースのオペレーショナルデータ・ストアに、前記ソースのオペレーショナルデータ・ストアに格納されている前記同期化タイムスタンプより大きいタイムスタンプを有する任意のオペレーショナルデータ・レコードを送信するように指示するために、前記ソースのオペレーショナルデータ・ストアへ前記同期化タイムスタンプを送信させるように動作可能である、非一時的コンピュータ可読媒体。
【請求項５２】
重複排除されたデータ用のハッシュを、一連のハッシュを備える持続的なヘッダを用いてデータが格納される重複排除データストアにキャッシュするためのコンピュータ化された方法であって、前記一連のハッシュにおける各ハッシュは、前記重複排除データストアにおいて前記持続的なヘッダの後に格納されるデータであって、前記一連のハッシュにおける残りのハッシュによって表される他のデータとコロケートされるデータを表し、前記コンピュータ化された方法は、
コンピューティングデバイスにより、前記重複排除データストアからデータを読み取る要求を受信することと、
前記コンピューティングデバイスにより、前記コンピューティングデバイスのメモリに格納されていない第１のハッシュ構造において、重複排除データストアに格納される持続的なヘッダを識別することであって、
前記持続的なヘッダは、前記コンピューティングデバイスが読み取りを要求したデータを指すハッシュを含む一連のハッシュを備え、かつ、
前記一連のハッシュにおける各ハッシュは、前記重複排除データストアにおいて前記持続的なヘッダの後に格納されるデータである、前記一連のハッシュにおける残りのハッシュによって表される他のデータと同一場所に配置されるデータを表すことと、
前記コンピューティングデバイスにより、前記コンピューティングデバイスのメモリに格納される第２のハッシュ構造における前記一連のハッシュをキャッシュすること、を含み、これにより、前記コンピューティングデバイスが追加データの読み取りを要求すれば、前記コンピューティングデバイスは、前記追加データを、前記追加データが前記持続的なヘッダによって表されているかどうかの前記第２のハッシュ構造を用いて識別することができる、コンピュータ化された方法。
【請求項５３】
前記コンピューティングデバイスのメモリに格納される前記第２のハッシュ構造における前記一連のハッシュをキャッシュすることは、
ハッシュテーブル構造を、前記持続的なヘッダを基礎としてハッシュテーブル・アレイに格納することを含み、前記ハッシュテーブル構造は、
前記データのハッシュの一部を備えるハッシュフラグメントと、
持続的ヘッダ参照アレイへのインデックスと、
前記データのハッシュを識別する前記持続的なヘッダの前記一連のハッシュへのハッシュインデックスと、を備える、請求項５２に記載の方法。
【請求項５４】
前記ハッシュテーブル構造を、前記ハッシュテーブル・アレイにおいて、前記ハッシュフラグメントを基礎として識別することをさらに含む、請求項５３に記載の方法。
【請求項５５】
持続的なヘッダの参照構造を、前記持続的なヘッダを基礎として持続的なヘッダの参照アレイに格納することをさらに含み、前記持続的なヘッダの参照構造は、
メモリ内の前記持続的なヘッダを識別するキャッシュ・ページ・アレイへのキャッシュ・ページ・インデックスと、
前記キャッシュ・ページ・インデックスにより識別されるキャッシュ・ページ・アレイ・エントリの同一性を検証するためのハッシュコードとを備える、請求項５３に記載の方法。
【請求項５６】
前記持続的ヘッダに関連づけられるデータを読み取ることをさらに含み、
前記ハッシュテーブル・アレイにおける前記ハッシュテーブル構造を前記ハッシュフラグメントを基礎として識別することと、
前記持続的なヘッダの参照アレイにおける前記持続的なヘッダの参照構造を前記インデックスを基礎として識別すること、を含む、請求項５５に記載の方法。
【請求項５７】
前記キャッシュ・ページ・インデックスにおける前記キャッシュ・ページ・アレイ・エントリを、前記キャッシュ・ページ・インデックスを基礎として識別することと、
前記キャッシュ・ページ・アレイ・エントリの同一性を、前記ハッシュコードを基礎として検証すること、をさらに含む、請求項５６に記載の方法。
【請求項５８】
メモリ内の前記持続的ヘッダを、前記キャッシュ・ページ・アレイを基礎として識別することと、
前記一連のハッシュにおける前記ハッシュを、前記インデックスを基礎として識別すること、をさらに含む、請求項５７に記載の方法。
【請求項５９】
前記重複排除データストアから第２のデータを読み取る第２の要求を受信することと、
前記第２のデータを、前記第１のハッシュ構造ではなく前記第２のハッシュ構造を用いて識別すること、をさらに含み、前記第２のデータは、前記一連のハッシュにおける第２のハッシュを備える、請求項５２に記載の方法。
【請求項６０】
前記重複排除データストアから第２のデータを読み取る第２の要求を受信することと、
前記第２のデータの第２のハッシュが前記第２のハッシュ構造内に存在しないことを決定することと、
前記第１のハッシュ構造における第２の持続的なヘッダを識別することであって、
前記第２の持続的なヘッダは、前記第２の持続的なヘッダ内に格納される第２のハッシュセット内に第２のハッシュを含み、かつ、
前記第２のハッシュは、前記コンピューティングデバイスが読み取りを要求した前記第２のデータを示すことと、
前記第２のハッシュセットを、前記コンピューティングデバイスのメモリに格納される前記第２のハッシュ構造内にキャッシュすること、を含む、請求項５２に記載の方法。
【請求項６１】
重複排除されたデータ用のハッシュを、一連のハッシュを備える持続的なヘッダを用いてデータが格納される重複排除データストアにキャッシュするためのコンピューティングデバイスであって、前記一連のハッシュにおける各ハッシュは、前記重複排除データストアにおいて前記持続的なヘッダの後に格納されるデータである、前記一連のハッシュにおける残りのハッシュによって表される他のデータと同一場所に配置されるデータを表し、前記コンピューティングデバイスは、
重複排除データストアと、
前記重複排除データストアと通信状態にあり、かつメモリに格納されるモジュールを実行するように構成されるプロセッサと、を備え、前記モジュールは、前記プロセッサに、
前記重複排除データストアからデータを読み取る要求を受信させ、
前記コンピューティングデバイスのメモリに格納されていない第１のハッシュ構造において、重複排除データストアに格納される持続的なヘッダを識別させ、
前記持続的なヘッダは、前記コンピューティングデバイスが読み取りを要求したデータを指すハッシュを含む一連のハッシュを備え、かつ、
前記一連のハッシュにおける各ハッシュは、前記重複排除データストアにおいて前記持続的なヘッダの後に格納されるデータである、前記一連のハッシュにおける残りのハッシュによって表される他のデータと同一場所に配置されるデータを表し、
前記コンピューティングデバイスのメモリに格納される第２のハッシュ構造における前記一連のハッシュをキャッシュさせるように構成され、これにより、前記コンピューティングデバイスが追加データの読み取りを要求すれば、前記コンピューティングデバイスは、前記追加データを、前記追加データが前記持続的なヘッダによって表されているかどうかの前記第２のハッシュ構造を用いて識別することができる、コンピューティングデバイス。
【請求項６２】
実行可能命令を有する非一時的コンピュータ可読媒体であって、前記実行可能命令は、装置に、
重複排除データストアからデータを読み取る要求を受信させ、
前記コンピューティングデバイスのメモリに格納されていない第１のハッシュ構造において、重複排除データストアに格納される持続的なヘッダを識別させ、
前記持続的なヘッダは、前記コンピューティングデバイスが読み取りを要求したデータを指すハッシュを含む一連のハッシュを備え、かつ、
前記一連のハッシュにおける各ハッシュは、前記重複排除データストアにおいて前記持続的なヘッダの後に格納されるデータである、前記一連のハッシュにおける残りのハッシュによって表される他のデータと同一場所に配置されるデータを表し、
前記コンピューティングデバイスのメモリに格納される第２のハッシュ構造における前記一連のハッシュをキャッシュさせるように動作可能であり、これにより、前記コンピューティングデバイスが追加データの読み取りを要求すれば、前記コンピューティングデバイスは、前記追加データを、前記追加データが前記持続的なヘッダによって表されているかどうかの前記第２のハッシュ構造を用いて識別することができる、非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（なし）
【背景技術】
【０００２】
アプリケーションデータのライフサイクルを管理するためのビジネス要件は、従来から、各々がライフサイクルの一部に対処する複数のポイントソリューションを配備することによって満たされてきている。その結果、多大なデータコピーが作製されて個々の記憶レポジトリへと何度も移動される複雑かつ高価なインフラストラクチャが生じている。サーバ仮想化の採用は、単純で敏捷かつ低コストの計算インフラのためのきっかけとなった。これにより、仮想ホストおよびストレージの配備がより大規模になっていて、出現する計算モデルと現行のデータ管理実装との間のギャップは、さらに悪化している。
【０００３】
ビジネスサービスを提供するアプリケーションは、そのライフサイクルの様々な段階において、そのデータの格納に依存する。図１は、給与支払管理等のビジネスサービスの根底にあるデータベース等のアプリケーションデータへ適用される、ある典型的なデータ管理オペレーションセットを示している。ビジネスサービスを提供するために、アプリケーション１０２は、何らかの短縮レベルの信頼性および可用性を有する一次データストレージ１２２を必要とする。
【０００４】
バックアップ１０４は、ハードウェアまたはソフトウェアの故障または人為的過誤による一次データストレージの破損を警戒して作られる。典型的には、バックアップは、ローカルディスクまたはテープ１２４へ毎日または毎週行われて、物理的に安全なリモートロケーション１２５へ頻度を下げて（毎週または毎月）移動される場合がある。
【０００５】
同じデータベースを基礎とする新たなアプリケーションの同時的な開発および試験１０６は、データの別のコピー１２６へのアクセスを有するための開発チームを必要とする。このようなスナップショットは、開発日程に依存して毎週作成される場合もある。
【０００６】
法的または自発的なポリシーのコンプライアンス１０８は、将来の安全なアクセスのために何らかのデータが何年間か保持されることを必要とする場合があり、通常、データは、長期アーカイブシステム１２８へ定期的に（例えば、毎月）コピーされる。
【０００７】
災害リカバリサービス１１０は、一次ビジネスサービスを提供するシステムが何らかの物理的災害に起因して故障した場合の、データの破壊的損失を警護する。一次データは、１３０において、他の制約（コスト等）を考えて可能な限り頻繁に、物理的に別個のロケーションへコピーされる。災害が発生すれば、一次サイトは復元され、かつデータは、このセーフコピーから戻されることが可能である。
【０００８】
ビジネス継続サービス１１２は、一次サイトがコンプロマイズされた場合に、継続されたビジネスサービスを保証するためのファシリティを提供する。通常、これは、一次データとほぼロックステップ状態にある一次データのホットコピー１３２のみならず、複製システムおよびアプリケーション、および着信する要求をビジネス継続サービスへ切換するための機構を必要とする。
【０００９】
したがって、データ管理は、現在のところ、ライフサイクルの異なる部分を管理するポイントアプリケーションのコレクションである。これは、この二十年間に亘って、データ管理ソリューションの進化におけるアーティファクトとなっている。
【発明の概要】
【００１０】
開示する発明対象に従って、高度なデータ管理仮想化システムのためのシステム、方法および非一時的コンピュータ可読媒体を提供する。
【００１１】
開示する発明対象は、データ管理オペレーションの間に生成されるオペレーショナルデータ・レコードを、同期中の冗長なデータコピーを減らす方法で同期するための方法を含む。本方法は、中央オペレーショナルデータ・ストアにより、一連のオペレーショナルデータ・レコードを格納することを含み、各データレコードには一意の（固有の）識別子（ＩＤ）が、そのデータレコードの生成時間を基礎として昇順で割り当てられる。本方法は、中央オペレーショナルデータ・ストアにより、一連のオペレーショナルデータ・レコードにおけるオペレーショナルデータ・レコードから最高位の一意の（固有の）ＩＤを識別することを含む。本方法は、公差数未満の数だけ離れた一意のＩＤを有するオペレーショナルデータ・レコードに、オペレーショナルデータ・レコード作成順の一意のＩＤが割り当てられたことが保証され得ないように、中央オペレーショナルデータ・ストアにより、同時に処理されることが可能な一意のＩＤの範囲を示す公差数を識別することを含む。本方法は、最高位の一意のＩＤから公差数を減算することを含み、中央オペレーショナルデータ・ストアにより、同期ＩＤを計算することを含む。本方法は、ソースのオペレーショナルデータ・ストアに、ソースのオペレーショナルデータ・ストアに格納されている同期ＩＤより大きい一意のＩＤを有する任意のオペレーショナルデータ・レコードを送信するように指示するために、中央オペレーショナルデータ・ストアにより、ソースのオペレーショナルデータ・ストアへ同期ＩＤを送信することを含む。
【００１２】
実施形態によっては、一連の一意のＩＤは、一連のオペレーショナルデータ・レコードから識別され、一連の一意のＩＤにおける各一意のＩＤは、最高位の一意のＩＤと同期ＩＤとの間に存在し、この一連の一意のＩＤは、ソースのオペレーショナルデータ・ストアにこの一連の一意のＩＤを有するオペレーショナルデータ・レコードを送信しないように指示するために、ソースのオペレーショナルデータ・ストアへ送信される。最高位の一意のＩＤは、ソースのオペレーショナルデータ・ストアに最高位の一意のＩＤを有するオペレーショナルデータ・レコードを送信しないように指示するために、ソースのオペレーショナルデータ・ストアへ送信されることが可能である。
【００１３】
実施形態によっては、公差数は、許可される同時的トランザクションの数、および最大遅延を基礎として計算される。同時トランザクションの数は、２倍にされることが可能である。各一意のＩＤは、単調増加する一意のＩＤであることが可能である。一連のオペレーショナルデータ・レコードは、１００，０００個を超えるオペレーショナルデータ・レコードを含む大規模なオペレーショナルデータ・レコード・セットであることが可能であり、一連のオペレーショナルデータ・レコードにおけるデータレコードは、一旦生成されると変わらない。
【００１４】
開示する発明対象は、データ管理オペレーションの間に生成されるオペレーショナルデータ・レコードを、同期中の冗長なデータコピーを減らす方法で同期するための方法を含む。本方法は、中央オペレーショナルデータ・ストアにより、一連のオペレーショナルデータ・レコードを格納することを含み、各データレコードにはタイムスタンプが、そのデータレコードの生成時間または修正時間の何れかを基礎として割り当てられる。本方法は、中央オペレーショナルデータ・ストアにより、ソースのオペレーショナルデータ・ストアから一連のオペレーショナルデータ・レコードの最終のバックアップ時間を識別することを含む。本方法は、公差数未満の数だけ離れたタイムスタンプを有するオペレーショナルデータ・レコードに、オペレーショナルデータ・レコードの作成順または修正順、または双方のタイムスタンプが割り当てられたことが保証され得ないように、中央オペレーショナルデータ・ストアにより、経過時間を基礎として、同時に処理されることが可能なタイムスタンプの範囲を示す公差数を計算することを含む。本方法は、最終のバックアップ時間から公差数を減算することを含み、中央オペレーショナルデータ・ストアにより、同期化タイムスタンプを計算することを含む。本方法は、ソースのオペレーショナルデータ・ストアに、ソースのオペレーショナルデータ・ストアに格納されている同期化タイムスタンプより大きいタイムスタンプを有する任意のオペレーショナルデータ・レコードを送信するように指示するために、中央オペレーショナルデータ・ストアにより、ソースのオペレーショナルデータ・ストアへ同期化タイムスタンプを送信することを含む。
【００１５】
実施形態によっては、各々が同期化タイムスタンプ後に生じるタイムスタンプを有する一連のオペレーショナルデータ・レコードと、ソースのオペレーショナルデータ・ストアによって格納される各データレコードの一意のＩＤのリストとを含む応答が受信される。一連のオペレーショナルデータ・レコードにおける、この一意のＩＤのリストに存在しない一意のＩＤを有するオペレーショナルデータ・レコードは、何れも削除されることが可能である。一連のオペレーショナルデータ・レコードは、１，０００個を超えるオペレーショナルデータ・レコードを含む、但し１００，０００個のオペレーショナルデータ・レコードより少ない中型のオペレーショナルデータ・レコード・セットであることが可能である。
【００１６】
開示する発明対象は、重複排除されたデータ用のハッシュを、一連のハッシュを備える持続的なヘッダを用いてデータが格納される重複排除データストアにキャッシュするためのコンピュータ化された（コンピュータに実行させる）方法を含み、一連のハッシュにおける各ハッシュは、重複排除データストアにおいて持続的なヘッダの後に格納されるデータであって、一連のハッシュにおける残りのハッシュによって表される他のデータと同一場所に配置される（コロケートされる）データを表す。本コンピュータ化された方法は、コンピューティングデバイスにより、重複排除データストアからデータを読み取る要求を受信することを含む。本コンピュータ化された方法は、コンピューティングデバイスにより、コンピューティングデバイスのメモリに格納されていない第１のハッシュ構造において、重複排除データストアに格納される持続的なヘッダを識別することを含む。持続的なヘッダは、コンピューティングデバイスが読み取りを要求したデータを指すハッシュを含む一連のハッシュを備える。一連のハッシュにおける各ハッシュは、重複排除データストアにおいて持続的なヘッダの後に格納されるデータであって、一連のハッシュにおける残りのハッシュによって表される他のデータと同一場所に配置される（コロケートされる）データを表す。本コンピュータ化された（コンピュータに実行させる）方法は、コンピューティングデバイスにより、コンピューティングデバイスのメモリに格納される第２のハッシュ構造における一連のハッシュをキャッシュすることを含み、これにより、コンピューティングデバイスが追加データの読み取りを要求すれば、コンピューティングデバイスは、この追加データを、追加データが持続的なヘッダによって表されているかどうかの第２のハッシュ構造を用いて識別することができる。
【００１７】
実施形態によっては、コンピューティングデバイスのメモリに格納される第２のハッシュ構造における一連のハッシュをキャッシュすることは、ハッシュテーブル構造を、持続的なヘッダを基礎としてハッシュテーブル・アレイに格納することを含む。ハッシュテーブル構造は、データのハッシュの一部を備えるハッシュフラグメントと、持続的ヘッダ参照アレイへのインデックスと、データのハッシュを識別する持続的なヘッダの一連のハッシュへのハッシュインデックスとを含むことが可能である。ハッシュテーブル構造は、ハッシュテーブル・アレイにおいて、ハッシュフラグメントを基礎として識別されることが可能である。
【００１８】
実施形態によっては、持続的なヘッダの参照構造は、持続的なヘッダを基礎として持続的なヘッダの参照アレイに格納される。持続的なヘッダの参照構造は、メモリ内の持続的なヘッダを識別するキャッシュ・ページ・アレイへのキャッシュ・ページ・インデックスと、キャッシュ・ページ・インデックスにより識別されるキャッシュ・ページ・アレイ・エントリの同一性を検証するためのハッシュコードとを含む。持続的なヘッダに関連づけられるデータは、ハッシュテーブル・アレイにおけるハッシュテーブル構造をハッシュフラグメントを基礎として識別することと、持続的なヘッダの参照アレイにおける持続的なヘッダの参照構造をインデックスを基礎として識別することを含み、読み取られることが可能である。キャッシュ・ページ・アレイ・エントリは、キャッシュ・ページ・インデックスにおいてキャッシュ・ページ・インデックスを基礎として識別されることが可能であり、かつキャッシュ・ページ・アレイ・エントリの同一性は、ハッシュコードを基礎として検証されることが可能である。持続的なヘッダは、メモリにおいてキャッシュ・ページ・アレイを基礎として識別されることが可能であり、かつハッシュは、一連のハッシュにおいてインデックスを基礎として識別されることが可能である。
【００１９】
実施形態によっては、重複排除データストアから第２のデータを読み取る第２の要求が受信され、第２のデータは、第１のハッシュ構造ではなく第２のハッシュ構造を用いて識別され、この場合の第２のデータは、一連のハッシュにおける第２のハッシュを備える。重複排除データストアから第２のデータを読み取る第２の要求が受信されると、第２のデータの第２のハッシュが第２のハッシュ構造内に存在しないことが決定される可能性があり、第２の持続的なヘッダは、第１のハッシュ構造において識別される。第２の持続的なヘッダは、第２の持続的なヘッダ内に格納される第２のハッシュセット内に第２のハッシュを含むことが可能である。第２のハッシュは、コンピューティングデバイスが読み取りを要求した第２のデータを示すことが可能である。第２のハッシュセットは、コンピューティングデバイスのメモリに格納される第２のハッシュ構造内にキャッシュされることが可能である。
【００２０】
開示する発明対象は、アウトオブバンド・ストレージをバックアップするためのコンピュータ化された（コンピュータに実行させる）方法を含む。本コンピュータ化された方法は、コンピューティングデバイスにより、リモートホストにおけるアウトオブバンド（帯域外「out-of-band」）・ストレージの保護ポリシーを起動することを含み、この場合のアウトオブバンド・ストレージは、コンピューティングデバイスによる物理的なアクセスは不可であり、よって、アウトオブバンド・ストレージは、コンピューティングデバイスを介してリモートホストと通信していない。本コンピュータ化された方法は、コンピューティングデバイスにより、リモートホストへ、保護ポリシーに従ってバックアップすべきアウトオブバンド・ストレージのボリューム（「volume」、量、号、巻）を示すデータを含むバックアップ要求を送信することを含む。本コンピュータ化された方法は、コンピューティングデバイスにより、ボリュームのステージングディスク要件を示すデータを含むバックアップ要求に対する応答を受信することを含み、ステージングディスク要件は、ボリュームをバックアップするために要するステージングディスクのサイズを含む。本コンピュータ化された方法は、コンピューティングデバイスにより、応答を基礎としてステージングディスクを決定することを含む。本コンピュータ化された方法は、コンピューティングデバイスにより、ステージングディスクをリモートホストへ提示することを含む。本コンピュータ化された方法は、コンピューティングデバイスにより、リモートホストから、ボリュームのステージングディスクへのバックアップが成功したか失敗したかを示すデータを含むバックアップ結果を受信することを含む。
【００２１】
実施形態によっては、バックアップの結果を基礎として、バックアップが失敗したことが決定され、かつバックアップの結果におけるエラーコードが識別されて格納される。バックアップの結果を基礎として、バックアップが成功したことが決定される可能性もあり、ステージングディスクのポイントインタイム・スナップショットを生成することができ、かつステージングディスクのポイントインタイム・スナップショットをボリュームの最新バックアップとしてカタログに入れることができる。応答を基礎としてステージングディスクを決定することは、先にカタログに入れられているボリュームのポイントインタイム・スナップショットを識別し、かつこの先にカタログに入れられているボリュームのポイントインタイム・イメージをステージングディスクとして用いることを含むことが可能であり、よってアウトオブバンド・ストレージにおけるポイントインタイム・イメージから変化した情報のみをコピーするために、ファイルシステム情報を用いてこの先にカタログに入れられているポイントインタイム・イメージがアウトオブバンド・ストレージと比較される。
【００２２】
実施形態によっては、応答を基礎としてステージングディスクを決定することは、先にカタログに入れられているボリュームのポイントインタイム・スナップショットは存在しないことを決定し、かつコンピューティングデバイスのデータストレージからの、ステージングディスク要件からの要求されたサイズに基づくサイズを有するステージングディスクを割り付けることを含むことが可能である。先にカタログに入れられているボリュームのポイントインタイム・スナップショットが期限切れになったことが決定される可能性もあり、よって先にカタログに入れられているポイントインタイム・スナップショットは、削除されることが可能である。
【００２３】
実施形態によっては、先にカタログに入れられているボリュームのポイントインタイム・スナップショットは、ステージングディスク要件からの要求されたサイズより少ないサイズを含む先行するステージングディスクに関連づけられることが決定され、このステージングディスクは、コンピューティングデバイスのデータストレージからの、ステージングディスク要件からの要求されたサイズに基づくサイズを有するものが割り付けられ、この場合のステージングディスクは、先にカタログに入れられているポイントインタイム・スナップショットを含まない。リモートホストに格納されるアウトオブバンド・ストレージは、リモートデバイスの内蔵ディスク、ネットワークドライブまたはこれらの任意の組合せを含むことができる。
【００２４】
開示する発明対象は、バックアップフレームワークにおけるプロセス内通信のためのコンピュータ化された方法を含む。本方法は、コンピューティングデバイスにより、１つまたは複数のリクエスタおよび１つまたは複数のプロバイダを実行しかつ調和させるように構成されるフレームワークにカスタムリクエスタを登録することを含み、この場合のフレームワークは、１または複数のリクエスタおよび１つまたは複数のプロバイダのアプリケーション・プログラマ・インタフェースを提供するが、１または複数のリクエスタと１つまたは複数のプロバイダとの間の直接的な通信のためのインタフェースは提供しない。１つまたは複数のリクエスタは、各々、あるアプリケーションに関連づけられるデータセットのバックアップを要求するように構成されるコンピュータ化された（コンピュータに実行させる）プロセスである。１つまたは複数のプロバイダは、各々、あるアプリケーションに関連づけられるデータセットのバックアップを生成するように構成されるコンピュータ化されたプロセスを含む。コンピューティングデバイスは、１つまたは複数のリクエスタからの第１のリクエスタを用いて、第１のアプリケーションに関連づけられる第１のデータセットのバックアッププロセスを開始する。コンピューティングデバイスは、第１のリクエスタを用いて、第１のデータセットおよび第１のアプリケーションに関連づけられるデータ・ストレージ・デバイス（データ記憶装置）がコンピューティングデバイスに関連づけられるデータ管理システムによってエクスポートされることを決定する。コンピューティングデバイスは、第１のリクエスタを用いて、バックアッププロセスのための第１のデータセットのバックアップを生成するための１つまたは複数のプロバイダからの第１のプロバイダを選択し、この場合の第１のリクエスタおよび第１のプロバイダは、同じプロセススペースにおける別個のスレッドであり、よって、第１のリクエスタおよび第１のプロバイダは、１つまたは複数のプロセス内通信チャネルを用いて互いに直に通信することができる。
【００２５】
実施形態によっては、コンピューティングデバイスは、第１のリクエスタを用いて、第１のデータセットおよび第１のアプリケーションに関連づけられるデータ・ストレージ・デバイス（データ記憶装置）がコンピューティングデバイスに関連づけられるデータ管理システムによってエクスポートされないことを決定し、かつフレームワークへ、フレームワークがバックアッププロセスのための第１のデータセットのバックアップを生成すべく１つまたは複数のプロバイダから第２のプロバイダを選択するように、バックアッププロセスの要求を送信し、この場合の第１のリクエスタおよび第２のプロバイダは、第１のリクエスタおよび第２のプロバイダが互いに直に通信できない代わりにフレームワークを介して通信できるように別個のプロセスである。
【００２６】
実施形態によっては、このフレームワークは、ＭｉｃｒｏｓｏｆｔのＶｏｌｕｍｅ  Ｓｈａｄｏｗ  Ｃｏｐｙ  Ｓｅｒｖｉｃｅであり、かつ第２のプロバイダは、ＭｉｃｒｏｓｏｆｔのＳｎａｐｓｈｏｔ  Ｐｒｏｖｉｄｅｒである。第１のリクエスタは、フレームワークへバックアップを開始する要求を送信することができ、よって、リクエスタは、フレームワークにより、第１のプロバイダがその関連の機能を完了するまでブロックされる。第１のプロバイダは、フレームワークから第１のデータセットのスナップショットを生成する第２の要求を受信し、かつ第１のリクエスタへ、フレームワークはスナップショットを生成する用意が調っているという通知を送信することができる。第１のリクエスタは、データ管理システムへ、第１のデータセットのスナップショットを生成するためのメッセージを送信することができ、データ管理システムから、スナップショットが生成されつつあることを示す第２のメッセージを受信することができ、かつ第１のプロバイダへ、スナップショットが生成されたというメッセージを送信することができる。
【００２７】
実施形態によっては、このフレームワークは、ＭｉｃｒｏｓｏｆｔのＶｏｌｕｍｅ  Ｓｈａｄｏｗ  Ｃｏｐｙ  Ｓｅｒｖｉｃｅ（ＶＳＳ）であり、１つまたは複数のプロバイダは、ＶＳＳプロバイダであり、かつ１つまたは複数のリクエスタは、ＶＳＳリクエスタである。フレームワークは、フレームワークにより管理されるデータを書き込みかつ更新するように構成されるＶＳＳライタを含むことが可能である。第１のリクエスタは、コールバックハンドラを第１のプロバイダに登録することができ、第１のプロバイダは、コールバックハンドラを用いて第１のリクエスタと通信することができる。
【００２８】
開示する発明対象は、データ管理仮想化システムの一連のサービスに亘ってユーザインタフェース行動を自動的に実行するデータ管理仮想化ディスプレイを実装するためのコンピュータ化された（コンピュータに実行させる）方法を含み、この場合のデータ管理仮想化システムは、一連のサブシステムを含む。本コンピュータ化された方法は、コンピューティングデバイスにより、一連のサービスをデータストアに格納することを含む。各サービスは、各サービスに関連づけられる一連のユーザインタフェースを含み、かつ各サービスは、共有サービスキャッシュを用いて残りのサービスと通信することができ、共有サービスキャッシュは、そのサービスが、一連のサービスにおける残りのサービスからデータを受信し、一連のサービスにおける残りのサービスへデータを送信し、一連のサービスに亘ってデータを保存すること、またはこれらの任意の組合せを行うことを可能にする。本コンピュータ化された方法は、コンピューティングデバイスにより、データ管理仮想化システム、一連のサブシステムまたはこれらの双方に関連づけられるプロファイルを認識することなくデータ管理仮想化システムのユーザに一連のサービスにおける２つ以上のサービスに亘って一連のウェブページを手動でナビゲートするように要求するデータ管理仮想化ジョブ、を実行する要求を受信することを含む。本コンピュータ化された方法は、コンピュータデバイスにより、共有サービスキャッシュを使用し、データ管理仮想化システム、一連のサブシステムまたはこれらの双方に関連づけられるプロファイルを基礎としてデータ管理仮想化ジョブのためのクイックリンクを画定することを含み、この場合のクイックリンクは、データ管理仮想化ジョブの手動ナビゲーションのうちの１つまたはそれ以上を排除する。
【００２９】
実施形態によっては、データ管理仮想化ディスプレイは、モデル・ビュー・コントローラ（ＭＶＣ）を拡張し、データ管理仮想化ディスプレイのデータは、各サービスの一連のユーザインタフェースをデータへリンクするコントローラによって、各サービスの一連のユーザインタフェースから、かつ一連のサービスから分離される。
【００３０】
実施形態によっては、各サービスは、サービスオブジェクトによって規定され、サービスオブジェクトは、その関連のサービスについて、サービスの一連のユーザインタフェース、サービスの一連のユーザインタフェースを制御するように構成されるサービスのウィンドウマネージャおよび一連のサービスからの他のサービスとの共有キャッシュを介する一連の相互作用を規定する。一連のサブシステムは、データ管理サブシステム、データ保護サブシステム、災害リカバリサブシステムおよびビジネス継続サブシステムを含むことができる。
【００３１】
開示する発明対象は、データベースストレージをバックアップするためのコンピュータ化された方法を含む。本方法は、コンピューティングデバイスにより、リモートホストにおけるデータベースストレージの保護ポリシーを起動することを含み、この場合のデータベースストレージは、コンピューティングデバイスによる物理的なアクセスは不可であり、よって、アウトオブバンド・ストレージは、コンピューティングデバイスを介してリモートホストと通信していない。本方法は、コンピューティングデバイスにより、リモートホストへ、保護ポリシーに従ってバックアップすべきデータベースストレージのボリュームを示すデータを含むバックアップ要求を送信することを含む。本方法は、コンピューティングデバイスにより、ボリュームのステージングディスク要件を示すデータを含むバックアップ要求に対する応答を受信することを含み、ステージングディスク要件は、ボリュームをバックアップするために要するステージングディスクのサイズを含む。本方法は、コンピューティングデバイスにより、応答を基礎としてステージングディスクを決定することを含む。本方法は、コンピューティングデバイスにより、リモートホストがデータベースストレージのベンダーにより提供されるデータベース・バックアップ・ツールを用いてボリュームのステージングディスクへのバックアップを実行できるように、ステージングディスクをリモートホストへ提示することを含む。本方法は、コンピューティングデバイスにより、リモートホストから、ボリュームのステージングディスクへのバックアップが成功したか失敗したかを示すデータを含むバックアップ結果を受信することを含み、この場合のボリュームのステージングディスクへのバックアップは、データベースストレージのベンダーによって提供されるデータベース・バックアップ・ツールを用いて実行されている。
【００３２】
実施形態によっては、本方法は、バックアップの結果を基礎として、バックアップが失敗したことを決定しかつバックアップ結果におけるエラーコードを識別し、かつこのエラーコードを格納することを含む。本方法は、バックアップの結果を基礎として、バックアップが成功したことを決定し、ステージングディスクのポイントインタイム（「point-in-time」瞬間的な、非常に短い時間の）・スナップショットを生成しかつステージングディスクのポイントインタイム（瞬間的な）・スナップショットをボリュームの最新バックアップとしてカタログに入れる（分類する）ことを含む。
【００３３】
実施形態によっては、応答を基礎としてステージングディスクを決定することは、先にカタログに入れられているボリュームのポイントインタイム・スナップショットを識別し、かつこの先にカタログに入れられているポイントインタイム・イメージをステージングディスクとして用いることを含む。先にカタログに入れられているボリュームのポイントインタイム・スナップショットを識別することは、バックアップ要求への応答におけるステージングディスク要件において一意の署名を受信し、かつ要求されるサイズおよび一意の署名を基礎として先にカタログに入れられているボリュームのポイントインタイム・スナップショットを識別することを含む可能性がある。応答を基礎としてステージングディスクを決定することは、先にカタログに入れられているボリュームのポイントインタイム・スナップショットは存在しないことを決定し、かつコンピューティングデバイスのデータストレージからの、ステージングディスク要件からの要求されたサイズに基づくサイズを有するステージングディスクを割り付けることを含むことが可能である。サイズは、ストレージを使い果たすことなくステージングディスクへのバックアップを繰り返すことができるステージングディスクのサイズを指定する予め決められたしきい値を基礎として計算されることが可能である。
【００３４】
実施形態によっては、本方法は、先にカタログに入れられているボリュームのポイントインタイム・スナップショットが期限切れになったことを決定して、先にカタログに入れられているポイントインタイム・スナップショットを削除することを含む。本方法は、先にカタログに入れられているボリュームのポイントインタイム・スナップショットがステージングディスク要件からの要求されたサイズより少ないサイズを含む先行するステージングディスクに関連づけられることを決定し、かつステージングディスク要件からの要求されたサイズに基づくサイズを有するコンピューティングデバイスのデータストレージからのステージングディスクを割り付けることを含む可能性があり、この場合のステージングディスクは、先にカタログに入れられているポイントインタイム・スナップショットを含まない。
【００３５】
実施形態によっては、リモートホストに格納されるデータベースストレージには、リモートデバイスの内蔵ディスク上、ネットワークドライブ上またはこれらの任意の組合せにおけるデータベースが含まれる。データベースストレージは、Ｏｒａｃｌｅのデータベースであってもよく、データベース・バックアップ・ツールは、ＯｒａｃｌｅのＲＭＡＮコマンドであってもよい。
【００３６】
開示する発明対象のこれらの、および他のケイパビリティは、下記の図面、詳細な説明およびクレームを精査後に、より完全に理解されるであろう。本明細書において使用される表現法および用語法が説明を目的とするものであって、限定として考慮されるべきでないことは、理解されるべきである。
【図面の簡単な説明】
【００３７】
【図１】図１は、ビジネスサービスのデータライフサイクルを管理するために配備される現行方法を示す略図である。
【図２】図２は、データのそのライフサイクルを通じた、単一のデータ管理仮想化システムによる管理の概観を示す。
【図３】図３は、データ管理仮想化システムの略ブロック図である。
【図４】図４は、データ管理仮想化エンジンを示したものである。
【図５】図５は、オブジェクト管理およびデータ移動エンジンを示す。
【図６】図６は、ストレージ・プール・マネージャを示す。
【図７】図７は、サービス・レベル・アグリーメントの分解図である。
【図８】図８は、アプリケーション指定モジュールを示す。
【図９】図９は、サービス・ポリシー・マネージャを示す。
【図１０】図１０は、サービス・ポリシー・スケジューラを示すフローチャートである。
【図１１】図１１は、コンテンツアドレス可能ストレージ（ＣＡＳ）のプロバイダを示すブロック図である。
【図１２】図１２は、ＣＡＳシステム内のオブジェクトハンドルの定義を示す。
【図１３】図１３は、オブジェクトに関してＣＡＳ内に格納される時間関連グラフのデータモデルおよびオペレーションを示す。
【図１４】図１４は、ＣＡＳにおけるガーベージ・コレクション・アルゴリズムのオペレーションを表す図である。
【図１５】図１５は、あるオブジェクトをＣＡＳにコピーするオペレーションのフローチャートである。
【図１６】図１６は、データ管理仮想化システムの典型的な配備を示すシステム図である。
【図１７】図１７は、従来技術におけるＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）のオペレーティングシステム上のＶＳＳフレームワークを示す略図である。
【図１８Ａ】図１８Ａは、幾つかの実施形態による、ＶＳＳリクエスタとＶＳＳプロバイダとの組合せを示す。
【図１８Ｂ】図１８Ｂは、幾つかの実施形態による、組み合わされたＶＳＳリクエスタおよびＶＳＳプロバイダの例示的なデータフローを示す。
【図１９Ａ】図１９Ａは、幾つかの実施形態による、アウトオブバンド保護を提供するシステムを示す略図である。
【図１９Ｂ】図１９Ｂは、幾つかの実施形態による、アウトオブバンド保護を提供するための例示的なコンピュータ化された方法を示す。
【図２０Ａ】図２０Ａは、幾つかの実施形態による、データベースの保護を示す略図である。
【図２０Ｂ】図２０Ｂは、幾つかの実施形態による、データベースを保護するためのコンピュータ化された方法を示す。
【図２０Ｃ】図２０Ｃは、幾つかの実施形態による、データベースを保護するためのコンピュータ化された方法を示す。
【図２１】図２１は、幾つかの実施形態による、保護および可用性ストレージ（ＰＡＳ）アプライアンスのためのシステムおよび方法を実装するユーザインタフェースであるデスクトップを示す。
【図２２】図２２は、幾つかの実施形態による、クイックリンクを有するサービス・マネージャ・インタフェースを示す略図である。
【図２２Ａ】図２２Ａは、幾つかの実施形態による、サービスオブジェクトを示す略図である。
【図２３】図２３は、幾つかの実施形態による、アプリケーション・マネージャ・サービスを示す。
【図２４】図２４は、幾つかの実施形態による、デスクトップにおいて、ジョブに関連してユーザが見ることのできる全てのアクティビティの、監視および管理を含む処理を担当するシステムモニタ・サービスを示す。
【図２５】図２５は、幾つかの実施形態による、システムモニタ・サービス内からの特定のジョブの特有の詳細のディスプレイを示す。
【図２６】図２６は、幾つかの実施形態による、クイックリンクのないユーザフローを記述したものである。
【図２７】図２７は、幾つかの実施形態による、クイックリンクを有するユーザフローを記述したものである。
【図２８】図２８は、幾つかの実施形態による、管理コンソールを示す。
【図２９】図２９は、幾つかの実施形態による、企業マネージャのオペレーショナルデータを示す。
【図３０Ａ】図３０Ａは、幾つかの実施形態による、データ管理オペレーショナルデータの例を示す。
【図３０Ｂ】図３０Ｂは、幾つかの実施形態による、データ管理オペレーショナルデータにおける中サイズデータの保護データの例を示す。
【図３０Ｃ】図３０Ｃは、幾つかの実施形態による、データ管理オペレーショナルデータにおける中サイズデータの同期化要求の例を示す。
【図３０Ｄ】図３０Ｄは、幾つかの実施形態による、データ管理オペレーショナルデータにおける中サイズデータの同期化要求に対する応答の一例を示す。
【図３０Ｅ】図３０Ｅは、幾つかの実施形態による、データ管理オペレーショナルデータにおける大型サイズデータの履歴データの一例を示す。
【図３０Ｆ】図３０Ｆは、幾つかの実施形態による、データ管理オペレーショナルデータにおける大型サイズデータの履歴データの同期化要求の一例を示す。
【図３０Ｇ】図３０Ｇは、幾つかの実施形態による、データ管理オペレーショナルデータにおける大型サイズデータの履歴データの同期化要求に対する応答の一例を示す。
【図３１】図３１は、幾つかの実施形態による、持続的なヘッダを示す略図である。
【図３２】図３２は、幾つかの実施形態による、ハッシュインデックスを示す略図である。
【図３３】図３３は、幾つかの実施形態による、ストレージシステムにおけるインデックスページを示す略図である。
【図３４】図３４は、幾つかの実施形態による、ページキャッシュを示す略図である。
【図３５】図３５は、幾つかの実施形態による、キー／値ハッシュテーブルを示す略図である。
【図３６】図３６は、幾つかの実施形態による、スコアボードを用いてハッシュを発見するシステムのオペレーションを示すフローチャートである。
【図３７】図３７は、幾つかの実施形態による、ハッシュを発見する際のスコアボードのオペレーションを示すフローチャートである。
【図３８】図３８は、所定の実施形態による、所定のエレメントを実装し得るコンピュータ化されたシステムの様々なコンポーネントを示す図である。
【発明を実施するための形態】
【００３８】
以下の説明では、開示する発明対象の完全な理解をもたらすために、開示する発明対象のシステムおよび方法ならびにこのようなシステムおよび方法の作動、他を行い得る環境に関する多くの特有の詳細について述べる。しかしながら、当業者にとって、開示する発明対象がこのような特有の詳細なしに実施され得ること、かつ技術上周知である所定の特徴が、開示する発明対象を不必要に複雑にしないために詳述されていないことは明らかであろう。さらに、後述する実施形態が例示的なものであること、および開示する発明対象の範囲に含まれる他のシステムおよび方法の存在が企図されていることも理解されるであろう。
【００３９】
これまでに述べたような現行のデータ管理のアーキテクチャおよび実装は、データライフサイクル管理の異なる部分に対処する複数のアプリケーションを包含し、これらは全て、所定の共通する機能を実行し、即ち（ａ）アプリケーションデータのコピーを作る（このアクションの頻度は、一般に目標復旧地点（ＲＰＯ）と称される）、（ｂ）データのコピーを、排他的なストレージレポジトリに、典型的には独自仕様のフォーマットで格納し、かつ（ｃ）コピーを、保持時間として測定される所定の持続時間に亘って保持する。各ポイントソリューションにおける主要な相違は、ＲＰＯの頻度、保持時間、および容量、コストおよび地理的位置を含む使用される個々のストレージレポジトリの特性に存在する。
【００４０】
本開示は、データ管理仮想化に関する。バックアップ、複製およびアーカイブ等のデータ管理アクティビティは、仮想化され、これらは個々に、かつ別個に構成されて実行される必要がない。代わりに、ユーザは、データのライフサイクルに関するそのビジネス要件を規定し、データ管理仮想化システムは、これらのオペレーションを自動的に実行する。一次ストレージから二次ストレージへスナップショットが取られ、このスナップショットは、次に、他の二次ストレージへのバックアップオペレーションのために使用される。基本的には、これらのバックアップは、任意数が取られてもよく、サービス・レベル・アグリーメントにより指定されるレベルのデータ保護が提供される。
【００４１】
また、本開示は、画像の一部が符号化された形式で直にハッシュテーブルに格納される、重複排除画像を格納する方法にも関し、本方法は、各データオブジェクトの一意の（固有の）コンテンツを複数のコンテンツセグメントとして編成し、かつこのコンテンツセグメントをデータストアに格納することと、各データオブジェクトについて、ハッシュ構造の編成された配置を生成することであって、ハッシュ構造のサブセットの各構造は、対応するコンテンツセグメントのハッシュ署名を包含するためのフィールドを含みかつ対応するコンテンツセグメントへの参照に関連づけられ、前記配置の論理的編成は、コンテンツセグメントの論理的編成を、これらがデータオブジェクト内部に表されるにつれて表すことと、データオブジェクトの重複排除画像に含まれるべきコンテンツを受信することと、受信されたコンテンツが、予め規定された無損失の符号化技術を用いて符号化され得るかどうか、かつこの場合、符号化された値がハッシュ署名を包含するためのフィールド内に嵌まるかどうかを決定することと、符号化され得るのであれば、符号化をフィールド内に配置し、かつハッシュ構造をマーキングしてこのフィールドが重複排除画像のための符号化されたコンテンツを含むことを示すことと、符号化され得ないのであれば、受信されたコンテンツのハッシュ署名を生成し、かつハッシュ署名をフィールド内に配置し、かつ受信されたコンテンツを、それが一意であれば、前記データストアにおける対応するコンテンツセグメント内に配置すること、を含む。
【００４２】
本開示によるデータ管理仮想化の技術は、下記の指針に基づくアーキテクチャおよび実装を基礎とする。
【００４３】
第１に、そのデータライフサイクル全体に関するサービス・レベル・アグリーメント（ＳＬＡ）を有するアプリケーションのビジネス要件を規定する。ＳＬＡは、単一のＲＰＯ、目標保持および復旧時間（ＲＴＯ）を遙かに超える存在である。これは、データライフサイクルの各段階のデータ保護特性について記述している。各アプリケーションは、異なるＳＬＡを有してもよい。
【００４４】
第２に、様々なストレージレポジトリに亘ってデータを移動してデータ保護のライフサイクルを管理する、改良された記憶容量およびネットワーク帯域幅を有する統合されたデータ管理仮想化エンジンを提供する。データ管理仮想化システムは、これらの改良を、経時的に変化しているデータ部分の追跡、およびコピーされかつ移動される必要があるデータの量を減らすデータ重複排除および圧縮アルゴリズムにより、最新のストレージシステムの拡張されたケイパビリティを活用することによって達成する。
【００４５】
第３に、アプリケーションデータの単一のマスターコピーを、ライフサイクル内の複数のエレメントの基礎となるように活用する。バックアップ、アーカイブおよび複製等のデータ管理オペレーションの多くは、保護されるべきデータの安定的な整合したコピーに依存する。データ管理仮想化システムは、データの単一コピーを多目的に活用する。本システムにより保全されるデータの単一のインスタンスは、各データ管理機能が必要に応じて追加コピーを作り得るソースとして機能してもよい。これは、アプリケーションデータが複数の独立したデータ管理アプリケーションによって何度もコピーされることを必要とする伝統的なアプローチとは対照的である。
【００４６】
第４に、物理ストレージリソースを一連のデータ保護ストレージプールへ抽象化し、これらが、ローカルおよびリモートディスク、ソリッド・ステート・メモリ、テープおよび光学媒体、秘密、公開および／または混成ストレージクラウドを含む異なるクラスのストレージから仮想化される。ストレージプール（記憶装置の貯蔵場所）は、タイプ、物理的位置または基礎を成すストレージ技術とは独立したアクセスを提供する。データライフサイクルのビジネス要件は、データを異なる時間に異なるタイプの記憶媒体へコピーすることを求めてもよい。データ管理仮想化システムにより、ユーザが異なる記憶媒体を分類してストレージプールへ、例えば、高速ディスクより成るクイック・リカバリ・プール、高容量ディスク上の重複排除ストアであり得る費用効率的長期ストレージプール、またはテープライブラリ、へ統合することが可能になる。データ管理仮想化システムは、各記憶媒体の固有の特性を利用するために、データをこれらのプール間で移動することができる。ストレージプールの抽象化は、タイプ、物理的位置または基礎を成すストレージ技術とは独立したアクセスを提供する。
【００４７】
第５に、ストレージプールと災害位置との間のデータ移動を、基礎を成すデバイスケイパビリティおよび重複排除後のアプリケーションデータを利用して改善する。データ管理仮想化システムは、ストレージプールを備えるストレージシステムのケイパビリティを発見し、かつこれらのケイパビリティを利用してデータを効率的に移動させる。ストレージシステムが、データボリュームのスナップショットまたはクローンを生成するケイパビリティをサポートするディスクアレイであれば、データ管理仮想化システムは、ある場所からデータを読み取ってこれを別の場所に書き込むのではなく、このケイパビリティを利用しかつスナップショットを用いてデータのコピーを作る。同様に、ストレージシステムが変化の追跡をサポートしていれば、データ管理仮想化システムは、変化のみを用いて古いコピーを更新し、新しいコピーを効率的に生成する。ネットワーク上でデータを移動する場合、データ管理仮想化システムは、ネットワークの反対側で既に利用可能であるデータの送信を回避する重複排除および圧縮アルゴリズムを用いる。
【００４８】
データ移動を改善する１つの重要な態様は、アプリケーションデータが、経時的にゆっくりと変わる点を認識することである。今日作られるアプリケーションのコピーは、概して、昨日作られた同じアプリケーションのコピーと多くの類似点を有する。実際に、データの今日のコピーは、一連のデルタ変換を有する昨日のコピーとして表されることも可能であり、デルタ変換のサイズ自体は、通常、コピーにおける全てのデータ自体より遙かに小さい。データ管理仮想化システムは、これらの変換を捉え、かつビットマップまたはエクステントリストの形式で記録する。本システムの一実施形態において、基礎を成すストレージリソース−ディスクアレイまたはサーバ仮想化システム−は、ボリュームまたはファイルに対して行われる変更を追跡することができ、これらの環境において、データ管理仮想化システムは、ストレージリソースにこれらの変更リストを入手するように問い合わせ、かつこれらを、保護されるデータと共に保存する。
【００４９】
データ管理仮想化システムのこの好ましい実施形態では、アプリケーションの一次データアクセス経路を傍受するための機構が存在し、これにより、データ管理仮想化システムは、アプリケーションデータのどの部分が修正されているかを観察し、かつ修正されたデータのその固有のビットマップを生成することができる。例えば、アプリケーションが、ある特定期間中にブロック１００、２００および３００を修正すれば、データ管理仮想化システムは、これらのイベントを傍受し、かつこれらの特定のブロックが修正されたことを示すビットマップを生成する。アプリケーションデータの次のコピーを処理する場合、データ管理仮想化システムは、修正されているのがブロック１００、２００および３００のみであることを知っていることから、これらのブロックのみを処理する。
【００５０】
アプリケーションの一次ストレージが最新のディスクアレイまたはストレージ仮想化アプライアンスである、システムの一実施形態において、データ管理仮想化システムは、基礎を成す記憶デバイスのポイントインタイム・スナップショット・ケイパビリティを利用してデータの最初のコピーを作る。この仮想コピー機構は、全てのビットがコピーされる、または共に格納されることを保証しない、最初のコピーを生成する高速、効率的かつ低衝撃性の技術である。代わりに、アクセス時にコピーを再構築できるようにする、コピーオンライトのボリュームビットマップまたはエクステント等のメタデータおよびデータ構造体を保全することにより、仮想コピーが構築される。このコピーがアプリケーションに、および一次記憶デバイスに与える衝撃は、軽量である。アプリケーションがＶＭｗａｒｅまたはＸｅｎ等のサーバ仮想化システムを基礎とする別の実施形態では、データ管理仮想化システムは、サーバ仮想化システムに組み込まれる同様の仮想マシン・スナップショット・ケイパビリティを用いる。仮想コピーケイパビリティを利用できない場合、データ管理仮想化システムは、その固有の内蔵スナップショット機構を含んでもよい。
【００５１】
スナップショットを、システムによりサポートされる全てのデータ管理機能の基礎を成すデータプリミティブとして用いることは可能である。軽量であることに起因して、スナップショットは、要求されるオペレーションが本来スナップショットでない場合でも、内部オペレーションとして使用されることが可能であり、これは、他のオペレーションを有効化しかつ容易にするために生成される。
【００５２】
スナップショットの生成時点では、画像がアプリケーションにより使用可能な状態へ復元され得るように、コヒーレントなスナップショットまたはコヒーレントな画像を生成するために包含される所定の準備オペレーションが存在してもよい。これらの準備オペレーションは、スナップショットが、ポリシーに従ってスケジュールされるバックアップコピー等のシステム内の複数のデータ管理機能に亘って活用されるとしても、１回だけ実行されればよい。準備オペレーションは、データキャッシュをフラッシュすることとアプリケーションの状態をフリーズすることを含むアプリケーション静止を含んでもよく、これはまた、技術上周知である他のオペレーション、および画像と共に格納されるべきメタデータ情報をアプリケーションから収集すること等の、完全な画像の保持に有益な他のオペレーションも含んでもよい。
【００５３】
図２は、これらの原理による、仮想化されたデータ管理システムが先に述べたデータライフサイクル要件に対処できる１つの方法を示す。
【００５４】
ローカルバックアップ要件を満たすために、ローカル高可用性ストレージ２０２内に一連の効率的なスナップショットが作成される。これらのスナップショットの中には、別のコピーを作成することなく開発／試験要件を満たすために使用されるものがある。ローカルバックアップの保持期間をより長くするために、コピーは、長期ローカルストレージ２０４に効率的に作られ、この実装において、長期ローカルストレージ２０４は、重複排除を用いてコピーの反復を減らす。長期ストレージ内のコピーは、ＳＬＡにより適用される保持ポリシーに依存して、バックアップとしてアクセスされても、アーカイブとして扱われてもよい。データのコピーは、リモートバックアップおよびビジネス継続の要件を満たすために、リモートストレージ２０６に作られるが、この場合もやはり、１セットのコピーで双方の目的を果たすに足りる。リモートバックアップおよび災害リカバリの代替例として、データのさらなるコピーが、商用または私的なクラウド・ストレージ・プロバイダによりホストされるレポジトリ２０８へ効率的に作成されてもよい。
データ管理仮想化システム
【００５５】
図３は、上述の原理を実装するデータ管理仮想化システムの高レベルコンポーネントを示す。好ましくは、本システムは、詳述する下記の基本的な機能コンポーネントを備える。
【００５６】
アプリケーション３００は、データを生成しかつ所有する。これは、何らかの計算ニーズを満たすために、ユーザにより、例えばｅメールシステム、データベースシステムまたは財政報告システムとして配備されているソフトウェアシステムである。アプリケーションは、典型的には、サーバ上で実行され、かつストレージを利用する。例示を目的として、アプリケーションは１つしか示されていない。実際には、単一のデータ管理仮想化システムにより管理される何百、または何千ものアプリケーションが存在し得る。
【００５７】
ストレージリソース３０２は、アプリケーションデータがそのライフサイクルを通じて格納される場所である。ストレージリソースは、内蔵ディスクドライブ、ディスクアレイ、光学およびテープ・ストレージ・ライブラリ、およびデータ格納要件に対処するためにユーザが獲得したクラウドベースのストレージシステムを含む、物理ストレージアセットである。ストレージリソースは、アプリケーションデータのオンライン・アクティブ・コピーが格納される一次ストレージ３１０と、バックアップ、災害リカバリ、アーカイブ、インデクシング、レポートおよび他の用途等を目的としてアプリケーションデータの追加コピーが格納される二次ストレージ３１２とから成る。二次ストレージリソースは、一次ストレージと同じエンクロージャ内に追加のストレージを含んでもよいだけでなく、同じデータセンタ、別のロケーションまたはインターネット上に類似の、または異なるストレージ技術を基礎とするストレージも含んでもよい。
【００５８】
１つまたは複数の管理ワークステーション３０８により、ユーザが、アプリケーションデータのライフサイクルを規定するサービス・レベル・アグリーメント（ＳＬＡ）３０４を指定できるようになる。管理ワークステーションは、データ管理仮想化システムを構成し、監視しかつ制御するために使用されるデスクトップまたはラップトップコンピュータ、またはモバイル・コンピューティング・デバイスである。サービス・レベル・アグリーメントは、アプリケーションデータの二次コピーの生成、保持および削除に関する詳細なビジネス要件をキャプチャする詳細な仕様書である。ＳＬＡは、伝統的なデータ管理アプリケーションにおいて単一クラスの二次ストレージのコピー頻度および予想される復元時間を表すために使用される単純なＲＴＯおよびＲＰＯの枠を遙かに超えた存在である。ＳＬＡは、データライフサイクル仕様における複数のステージをキャプチャし、かつＳＬＡは二次ストレージ内の各クラスにおける非一様な頻度および保持仕様を許容している。ＳＬＡについては、図７においてさらに詳しく述べる。
【００５９】
データ管理仮想化エンジン３０６は、アプリケーションデータの全てのライフサイクルをＳＬＡに明記されている通りに管理する。これは、潜在的に、多数のアプリケーションの多数のＳＬＡを管理する。データ管理仮想化エンジンは、ユーザから管理ワークステーションを介して入力を受け取り、かつアプリケーションの一次ストレージリソースを発見するためにアプリケーションと相互作用する。データ管理仮想化エンジンは、保護される必要のあるデータはどれか、および保護ニーズを最もよく満たす二次ストレージリソースはどれか、に関して決定を下す。例えば、ある企業が、その会計データを、ビジネス継続目的のみならずバックアップをも目的としてかなり短い間隔でコピーを作成する必要があると指定すれば、本エンジンは、適切なＳＬＡセットに従って、第１のストレージプールへ会計データのコピーを短い間隔で生成すること、かつまた第２のストレージプールへ会計データのバックアップコピーをより長い間隔で生成することを決定してもよい。これは、ストレージアプリケーションのビジネス要件によって決定される。
【００６０】
本エンジンは、次に、利用可能な状態のストレージリソースの高度なケイパビリティを用いてアプリケーションデータのコピーを作成する。上述の例において、本エンジンは、短い間隔のビジネス継続コピーを、ストレージアプライアンスに内蔵される仮想コピーまたはスナップショットケイパビリティを用いてスケジュールしてもよい。データ管理仮想化エンジンは、ＳＬＡにキャプチャされているビジネス要件を満たすために、アプリケーションデータをストレージリソース間で移動させる。データ管理仮想化エンジンについては、図４においてさらに詳しく述べる。
【００６１】
データ管理仮想化システムは、全体として、単一のホスト・コンピュータ・システムまたはアプライアンス内に配備されてもよく、またはこれは、１つの論理エンティティであるが、汎用および専用システムのネットワーク上へ物理的に分散されるものであってもよい。また、本システムの所定のコンポーネントは、コンピューティングまたはストレージクラウド内に配備されてもよい。
【００６２】
データ管理仮想化システムの一実施形態において、データ管理仮想化エンジンは、主として、フォールトトレラントな冗長コンピュータペア上で複数のプロセスとして実行される。データ管理仮想化エンジンの所定のコンポーネントは、アプリケーションサーバ内ではほぼアプリケーションとして実行されてもよい。他のコンポーネントの中には、ストレージファブリック内、またはストレージシステム自体において、ほぼ一次および二次ストレージとして実行されてもよいものがある。管理ステーションは、典型的には、セキュアなネットワーク上でエンジンへ接続するデスクトップおよびラップトップコンピュータおよびモバイルデバイスである。
データ管理仮想化エンジン
【００６３】
図４は、本発明の所定の実施形態による、データ管理仮想化エンジン３０６のアーキテクチャ概要を示す。エンジン３０６は、下記のモジュールを含む。
【００６４】
アプリケーション指定モジュール４０２：このモジュールは、アプリケーション３００からメタデータを制御して収集することを担当する。アプリケーションメタデータは、アプリケーションのタイプ、その構成に関する詳細、そのデータストアのロケーション、その現行の動作状態等のアプリケーション関連情報を含む。アプリケーションのオペレーションを制御することは、キャッシュデータをディスクへフラッシュすること、アプリケーションＩ／Ｏをフリーズしかつ解凍すること、ログファイルをローテーションまたはトランケートすること、およびアプリケーションをシャットダウンしかつ再開すること、等のアクションを含む。アプリケーション指定モジュールは、これらのオペレーションを実行し、かつ後述するサービス・レベル・ポリシー・エンジン４０６からのコマンドに応答してメタデータを送受信する。アプリケーション指定モジュールについては、図８に関連してさらに詳述する。
【００６５】
サービス・レベル・ポリシー・エンジン４０６は、ユーザにより提供されるＳＬＡ３０４に作用して、アプリケーションデータのコピーの生成、移動および削除に関する決定を下す。各ＳＬＡは、あるアプリケーションの保護に関連するビジネス要件を記述している。サービス・レベル・ポリシー・エンジンは、各ＳＬＡを分析して、各々があるストレージロケーションから別のストレージロケーションへのアプリケーションデータのコピーを含む一連のアクションに到達する。サービス・レベル・ポリシー・エンジンは、次に、これらのアクションを精査して優先順位および依存関係を決定し、かつデータ移動ジョブをスケジュールして開始する。サービス・レベル・ポリシー・エンジンについては、図９に関連してさらに詳述する。
【００６６】
オブジェクトマネージャおよびデータ移動エンジン４１０は、アプリケーションデータ、アプリケーションメタデータおよびＳＬＡより成る複合オブジェクトを生成し、かつこれを、ポリシーエンジンからの命令に従って異なるストレージプールを介して移動させる。オブジェクトマネージャは、サービス・ポリシー・エンジン４０６から、アプリケーション３００に属する、または別のプールにおける既存のコピー、例えば４１５、からのライブの一次データ４１３を基礎として特定のプールにアプリケーションデータのコピーを生成する命令をコマンドの形式で受信する。オブジェクトマネージャおよびデータ移動エンジンにより生成される複合オブジェクトのコピーは、アプリケーションデータだけでなくアプリケーションメタデータおよびアプリケーションのＳＬＡも含むことにおいて、自足的かつ自己記述的である。オブジェクトマネージャおよびデータ移動エンジンについては、図５に関連してさらに詳述する。
【００６７】
ストレージ・プール・マネージャ４１２は、基礎を成す物理ストレージリソース３０２を適合化して抽象化しかつこれらを仮想ストレージプール４１８として提示するコンポーネントである。物理ストレージリソースは、ユーザがユーザのアプリケーションのデータライフサイクルをサポートする目的で配備しているディスクアレイおよびテープライブラリ等の事実上のストレージアセットである。これらのストレージリソースは、ディスク、テープ、フラッシュメモリまたは光ストレージ等の異なるストレージ技術を基礎とするものである場合もある。また、ストレージリソースは、異なる地理的位置、コストおよび速度属性も有してもよく、かつ異なるプロトコルをサポートしてもよい。ストレージ・プール・マネージャの役割は、ストレージリソースを結合して統合し、かつこれらのプログラミングインタフェース間の相違をマスキングすることである。ストレージ・プール・マネージャは、物理ストレージリソースをオブジェクトマネージャ４１０へ、これらのプールをアプリケーションデータのライフサイクルにおける特定のステージに適するものにする特性を有する一連のストレージプールとして提示する。ストレージ・プール・マネージャについては、図６に関連してさらに詳述する。
オブジェクトマネージャおよびデータ移動エンジン
【００６８】
図５は、オブジェクト管理およびデータ移動エンジン４１０を示す。オブジェクトマネージャおよびデータ移動エンジンは、プールマネージャ５０４により提示される仮想ストレージリソース５１０を発見して用いる。本エンジンは、サービス・レベル・ポリシー・エンジン４０６からの、リソースのデータ・ストレージ・オブジェクトのインスタンスを生成して仮想ストレージプールに保全する要求を受諾し、かつサービス・レベル・ポリシー・エンジンからの命令に従って、仮想ストレージプールからストレージオブジェクトのインスタンス間のアプリケーションデータをコピーする。コピーするように選択されるターゲットプールは、選択されるビジネスオペレーション、例えばバックアップ、複製または復元を暗に示す。サービス・レベル・ポリシー・エンジンは、オブジェクトマネージャにローカルに（同じシステム上に）、またはリモート的に存在し、かつ標準的なネットワーキング通信上のプロトコルを用いて通信する。ある好ましい実施形態では、十分に理解されていて、広く利用可能であり、かつサービス・レベル・ポリシー・エンジンをほとんど修正なくオブジェクトマネージャにローカルに、またはリモート的に位置決めすることができるという理由で、ＴＣＰ／ＩＰが使用されてもよい。
【００６９】
ある実施形態において、本システムは、実装の容易さのために、サービス・レベル・ポリシー・エンジンをオブジェクトマネージャと同じコンピュータシステム上に配備してもよい。別の実施形態において、本システムは、アプリケーションにとって有益または便利であれば、設計の変更なしに、各々がコンポーネントのサブセットをホストする複数のシステムを使用してもよい。
【００７０】
オブジェクトマネージャ５０１およびストレージ・プール・マネージャ５０４は、ストレージリソースと、これらのストレージリソースを用いる、ユーザのアプリケーションが存在するコンピュータシステムとを相互接続するコンピュータ・システム・プラットフォーム上に存在し得るソフトウェアコンポーネントである。これらのソフトウェアコンポーネントの相互接続プラットフォーム上への配置は、好ましい実施形態として指定されていて、カスタマシステムをこのようなアプリケーションに広く使用される通信プロトコル（例えば、Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ、ｉＳＣＳＩ、他）を介してストレージへ接続する能力を提供する場合があり、かつまた、様々なソフトウェアコンポーネントを配備する容易さも提供する場合がある。
【００７１】
オブジェクトマネージャ５０１およびストレージ・プール・マネージャ５０４は、基礎を成すストレージ仮想化プラットフォームと、このプラットフォームにより利用可能にされるアプリケーション・プログラミング・インタフェースを介して通信する。これらのインタフェースにより、コンピュータシステムの挙動について、およびプラットフォームがストレージリソースとユーザのアプリケーションが存在するコンピュータシステムとをどのように相互接続するかについて、これらのソフトウェアコンポーネントが問い合わせて制御できるようになる。これらのコンポーネントにより、一般的慣習であるモジュール化技法を適用して、所定のプラットフォームに固有の交信コードの差替をすることが可能になる。
【００７２】
オブジェクトマネージャとストレージ・プール・マネージャは、プロトコルを介して通信する。これらは、標準的なネットワーキングプロトコル、例えばＴＣＰ／ＩＰ、または典型的にはコンピュータシステム上で利用可能な標準的なプロセス間通信（ＩＰＣ）機構上で送信される。これにより、固有のコンピュータプラットフォームに依存して、これらのコンポーネントが同じコンピュータプラットフォーム上に存在するか、ネットワークで接続される複数のコンピュータプラットフォーム上に存在する場合に、両者間の同等の通信を可能になる。現行の構成は、配備を容易にするために、同じコンピュータシステム上に存在する全てのローカル・ソフトウェア・コンポーネントを有する。先に述べたように、これは、厳格な設計要件ではなく、将来的には、必要に応じて再構成されることが可能である。
オブジェクトマネージャ
【００７３】
オブジェクトマネージャ５０１は、データ・ストレージ・オブジェクトを保全するためのソフトウェアコンポーネントであって、これを制御するための一連のプロトコルオペレーションを提供する。オペレーションは、データの生成、破壊、複製およびオブジェクト間へのコピー、オブジェクトへのアクセスの保全を含み、かつ具体的には、コピーの生成に使用されるストレージプールを指定できるようにする。全てのプールにサポートされる共通の機能サブセットは存在しないが、ある好ましい実施形態では、一次プールがパフォーマンスを最適化されてもよく、即ち待ち時間が短縮されてもよく、一方でバックアップまたは複製プールがキャパシティを最適化されて、より大量のアドレス可能なデータおよびコンテンツをサポートしてもよい。プールは、リモートであってもローカルであってもよい。ストレージプールは、ユーザが、例えばストレージの１ギガバイト当たりのコストといったビジネス上の決定を下し得る手段を含む様々な基準に従って分類される。
【００７４】
第１に、ストレージを引き出す特定のストレージデバイスは、異なるビジネス目的毎に機器が割り付けられることから、関連コストおよび他の実用的検討事項と並ぶ検討事項であり得る。デバイスの中には、実際にはハードウェアでさえなく、サービスとして提供されるキャパシティであり得るものがあり、よってこのようなリソースの選択は、実際的なビジネス目的に即して行われることが可能である。
【００７５】
第２に、近いストレージは、典型的には待ち時間が短い安価なネットワークリソースによって接続され、一方で遠いストレージは、待ち時間が長く帯域幅が制限される高価なネットワークリソースによって接続され得ることから、ネットワークトポロジー的な「近接性」が考慮され、逆に、ローカルリソースに影響する物理的災害に対して地理的多様性が防護となる場合には、ソースとストレージプールとの相対距離が有益となり得る。
【００７６】
第３に、何らかのストレージがスペース効率的なストレージとして最適化されるが、計算時間およびリソースをかけてデータを分析または変換した上でなければデータを格納できず、一方で、比較として他のストレージは「パフォーマンスが最適化され」、比較としてより多くのストレージリソースを取り込むが、データの変換に使用する計算時間またはリソースは、あるにしても比較的少ない場合には、ストレージ最適化特性が考慮される。
【００７７】
第４に、ストレージ・コンピュータ・プラットフォームに内在する幾つかのリソースが、例えば仮想ＳＣＳＩブロックデバイスとしてユーザのアプリケーションにとって容易かつ即時に利用可能にされ、一方で幾つかのリソースが間接的にしか使用できない場合には、「アクセス速度」特性が考慮される。リカバリのこの容易さおよび速度は、使用されるストレージの種類によって決定される場合が多く、このことによって適切な分類が可能になる。
【００７８】
第５に、使用されるストレージキャパシティは、縮小または拡大の何れにも有益さがあり得ることから、使用されるストレージの量、および所定のプールにおける利用可能な量が考慮される。
【００７９】
後述するサービス・レベル・ポリシー・エンジンは、ユーザにより提供されるＳＬＡと分類基準とを組み合わせて、アプリケーションデータを保持する方法および時間、およびサービス・レベル・アグリーメント（ＳＬＡ）を満たすために必要なリソースをどのストレージプールから引き出すかを決定する。
【００８０】
オブジェクトマネージャ５０１は、パフォーマンスプール内のデータオブジェクト上で実行される一連のオペレーションを追跡し、かつこれらのオペレーションを、オブジェクトを他のストレージプール、具体的にはキャパシティが最適化されたもの、へ移動させる他のオペレーションと相関するために、履歴機構を生成し、保全しかつ使用する。データオブジェクト毎のこの一連のレコードは、一次プール内の全てのデータオブジェクトについてオブジェクトマネージャで保全され、まず、一次データオブジェクトによって相関され、次に、オペレーション順、即ち各オブジェクトのタイムライン順および全てのこのようなタイムラインのリストによって相関される。実行される各オペレーションは、基礎を成す仮想化プリミティブを活用して、所定の時点におけるデータオブジェクトの状態をキャプチャする。
【００８１】
さらに、基礎を成すストレージ仮想化アプライアンスは、データオブジェクト内のデータの一部の修正を示すビットマップ等の内部データ構造体の検索をエクスポーズしかつ許容するように修正されてもよい。これらのデータ構造体は、ある時点におけるデータオブジェクトの状態、例えばデータオブジェクトのスナップショットをキャプチャし、かつ特定の時間に取られるスナップショット間の相違を提供するように活用され、これにより、最適なバックアップおよび復元が有効化される。特定の実装およびデータ構造体は、異なるベンダーからの異なるアプライアンス間で変わる場合があるが、データ構造体は、データオブジェクトに対する変化を追跡するために使用され、かつストレージは、オブジェクトのこれらの変化した部分のオリジナル状態を保全するために使用され、即ちデータ構造体における表示は、ストレージに保持されるデータに対応する。スナップショットへアクセスする場合、データオブジェクトは修正されたという表示のあるエリアにおいて修正されていることに起因して、データ構造体が調べられ、かつ変更されている部分について、カレントデータではなく保存されたデータがアクセスされる。使用される典型的なデータ構造体は、各ビットがデータオブジェクトの一セクションに対応するビットマップである。ビットの設定は、セクションがスナップショットオペレーションの時点後に修正されたことを示す。基礎を成すスナップショットプリミティブ機構は、スナップショットオブジェクトが存在する限りこれを保全する。
【００８２】
上述のタイムラインは、所定の一次データオブジェクトに対照して、オペレーションの開始時、その停止時（停止する場合）、スナップショットオブジェクトの参照、および内部データ構造体（例えば、ビットマップまたはエクステントリスト）の参照を含む、スナップショットオペレーションのリストを保全し、よってこれは、基礎を成すシステムから入手されることが可能である。また、任意の所定の時点におけるデータオブジェクトの状態の別のプールへのコピー、一例として、オブジェクトハンドルにおけるコンテンツアドレス指定結果を用いるデータオブジェクトの状態のキャパシティ最適化プール４０７へのコピー、の結果の参照も保全される。このオブジェクトハンドルは、所定のスナップショットに対応し、かつスナップショットオペレーションによってタイムラインに格納される。この相関は、適切な始点を識別するために使用される。
【００８３】
最適バックアップおよび復元は、オペレーションリストを所望される始点から終点まで調べる。オペレーションの時間順リストおよびその対応するデータ構造体（ビットマップ）は、開始から終了までの連続する時系列が実現されるように、即ち、時系列におけるオペレーションの開始時間間に隙間がないように構築される。これは、データオブジェクトに対する全ての変更が対応するビットマップデータ構造体によって表されることを保証する。検索は、開始から終了までの全てのオペレーションについて行う必要はなく、同時に存在するデータオブジェクトおよび基礎を成すスナップショットは、時間が重複する。必要な点は、単に、追跡されなかった変化が発生している可能性がある場合でも時間的な隙間が存在しないことである。ビットマップは、ストレージの所定のブロックが変化したことは示すが、どういった変化であるかは示さないことから、時間間隔において発生した一連の全ての変化を理解するためのビットマップが追加または合わせて組み立てられてもよい。システムは、このデータ構造体を用いてある時点における状態にアクセスする代わりに、データ構造体が時間の進行と共に修正されるデータを表す、という事実を活用する。逆に、示されたエリアにおけるデータオブジェクトの最終状態がアクセスされ、よって、所定のデータオブジェクトに対する所定の開始時から終了時までの一連の変化が返される。
【００８４】
バックアップオペレーションは、このタイムライン、相関された参照、および内部データ構造体へのアクセスを活用して、我々のバックアップオペレーションを実現する。同様に、これは、システムを相補的に用いて我々の復元オペレーションを達成する。具体的なステップについては、後の「最適バックアップ／復元」の項目において述べる。
仮想ストレージプールのタイプ
【００８５】
図５は、ストレージプールの幾つかの代表的なタイプを示している。本図には、１つの一次ストレージプールおよび２つの二次ストレージプールが描かれているが、実施形態によっては、さらに多くが構成されてもよい。
【００８６】
一次ストレージプール５０７−ユーザアプリケーションがそのデータを格納する、データオブジェクトを生成するために使用されるストレージリソースを含む。これは、主としてデータ管理仮想化エンジンのオペレーションを履行するために存在する他のストレージプールとは対照的である。
【００８７】
パフォーマンス最適化プール５０８−高性能バックアップ（即ち、後述する時点複製）ならびにユーザアプリケーションによるバックアップ画像への高速アクセスを提供できる仮想ストレージプール。
【００８８】
キャパシティ最適化プール５０９−主として、データオブジェクトのストレージを、後述する複製技術を用いて高スペース効率的に提供する仮想ストレージプール。この仮想ストレージプールは、データオブジェクトのコピーへのアクセスを提供するが、上述のパフォーマンス最適化プールとは対照的に、これをその主たる目的ほど高いパフォーマンスで行うわけではない。
【００８９】
初期配備は、先に述べたようなストレージプールを最小オペレーションセットとして含む。本設計は、完全に、先に示した基準の様々な組合せを表す様々なタイプの複数のプール、および将来の配備における全てのストレージを表すのに便利な複数のプールマネージャを予期している。先に示した得失評価は、コンピュータ・データ・ストレージ・システムには典型的である。
【００９０】
実用上の見地から、これらの３つのプールは、大部分のユーザ要件に極めて単純な方法で対処する好ましい実施形態を表す。大部分のユーザは、クイックリカバリを与える緊急復元ニーズ用の１つのストレージプール、および他の、低コストであり、よって多数の画像を長期間に亘って保持することができる１つのプールを有していれば、データ保護のほぼ全てのビジネス要件は、ほとんどコンプロマイズなしに満たされ得ることを発見する。
【００９１】
各プールにおけるデータのフォーマットは、そのプール内で使用される目的および技術によって決定づけられる。例えば、クイック・リカバリ・プールは、必要な変換を最小限に抑えかつリカバリ速度を向上させるために、オリジナルデータに極めて似た形式で保全される。一方で、長期ストレージプールは、重複排除および圧縮を用いてデータサイズを縮小し、ひいてはストレージコストを低減する。
オブジェクト管理オペレーション５０５
【００９２】
オブジェクトマネージャ５０１は、サービス・レベル・ポリシー・エンジン４０６から送られる命令に従って、仮想ストレージプール４１８からデータ・ストレージ・オブジェクト５０３のインスタンスを生成し、かつ保全する。オブジェクトマネージャは、データ・オブジェクト・オペレーションを５つの主要エリア、即ちポイントインタイム複製またはコピー（一般に、「スナップショット」と称される）、標準的コピー、オブジェクトメンテナンス、マッピングおよびアクセスメンテナンス、およびコレクション、において提供する。
【００９３】
また、オブジェクト管理オペレーションは、仮想ストレージプール自体を保全しかつこれらに関する情報を検索するための一連のリソース発見オペレーションも含む。プールマネージャ５０４は、最終的に、これらのための機能を供給する。
ポイントインタイム・コピー（「スナップショット」）オペレーション
【００９４】
スナップショットオペレーションは、特定の時点における初期オブジェクトインスタンスを表すデータ・オブジェクト・インスタンスを生成する。より具体的には、スナップショットオペレーションは、コレクションメンバの完全な仮想コピーを、指定された仮想ストレージプールのリソースを用いて生成する。これは、データ・ストレージ・オブジェクトと呼ばれる。データ・ストレージ・オブジェクトの複数の状態が経時的に保全され、よって、ある時点において存在したデータ・ストレージ・オブジェクトの状態が入手可能である。先に述べたように、仮想コピーは、複製データの全てのビットをディスクにコピーして格納する代わりに、コピーオンライトまたは他のインバンド技術を用いてコピーを軽量式に生成できるようにする、基礎を成すストレージ仮想化ＡＰＩを用いて実装されるコピーである。これは、実施形態によっては、ＥＭＣ、ｖｍｗａｒｅまたはＩＢＭにより提供されるようなオフザシェルフの基礎を成すストレージ仮想化システムのケイパビリティへアクセスするために書き込まれるソフトウェアモジュールを用いて実装されてもよい。このような基礎を成す仮想化が利用可能でない場合、記述するシステムは、アンインテリジェントハードウェアとインタフェースするために固有の仮想化層を提供してもよい。
【００９５】
スナップショットオペレーションは、画像データがコヒーレントであるように、かつ後にスナップショットを用いてこのスナップショット時点におけるアプリケーションの状態を復元し得るように、データの状態をある特定の点までフリーズさせることをアプリケーションに要求する。また、他の準備段階が必要とされてもよい。これらは、後続の項目において記述するアプリケーション指定モジュール３０２によって処理される。したがって、ライブアプリケーション用には、最も軽量なオペレーションが望ましい。
【００９６】
スナップショットオペレーションは、システム内の全ての高位オペレーションのためのデータプリミティブとして使用される。実際には、これらは、特定の時点におけるデータの状態へのアクセスを提供する。さらに、スナップショットは、典型的には、ディスク上に存在するものから何が変化しているかを区別するコピーオンライト技術を用いて実装されることから、これらのスナップショットは、システムを通じてデータを効率的にコピーするようにも構成され得る、または追加され得る相違を提供する。スナップショットのフォーマットは、後述するデータムーバ５０２によってコピーされるデータのフォーマットであってもよい。
標準的なコピーオペレーション
【００９７】
あるコピーオペレーションがスナップショットでない場合、これは、標準的なコピーオペレーションであると考慮されてもよい。標準的なコピーオペレーションは、あるストレージプールにおけるソース・データ・オブジェクトの全てまたはサブセットを別のストレージプールにおけるデータオブジェクトへコピーする。結果、２つの区別可能なオブジェクトが得られる。使用され得る標準的なコピーオペレーションの一タイプは、最初の「ベースライン」コピーである。これは、典型的には、データが、あるパフォーマンス最適化プールからキャパシティ最適化ストレージプールへ等、まずある仮想ストレージプールから別の仮想ストレージプールへコピーされる場合に行われる。別のタイプの標準的なコピーオペレーションは、ターゲットオブジェクトを更新するために、変化したデータまたは相違のみがターゲット・ストレージ・プールへコピーされる場合に使用されてもよい。これは、最初のベースラインコピーが先行して実行された後に発生するものである。
【００９８】
オブジェクトの完全網羅バージョンは、データ仮想化システムが最初に初期化される際にベースラインコピーが必要とされる場合でも、コピーが作成される度にシステムに保存される必要はない。これは、各仮想コピーが完全コピーへのアクセスを提供することに起因する。任意のデルタまたは相違は、ベースラインとの関連ではなく、仮想コピーに関連して表現されることが可能である。これは、一連の変化リストをウォークスルーする一般的なステップを仮想的に排除する、という有利な副次的効果を有する。
【００９９】
標準的なコピーオペレーションは、データ・ストレージ・オブジェクト間でデータを移動させかつデータ・ストレージ・オブジェクト自体を保全するためにプールマネージャにより供給されかつデータムーバにより受信される一連の命令または要求によって開始される。コピーオペレーションにより、指定された仮想ストレージプールのリソースを用いて、指定されたデータ・ストレージ・オブジェクトのコピーを生成できるようになる。結果、ストレージプールにおけるターゲット・データ・オブジェクト内にソース・データ・オブジェクトのコピーが生じる。
【０１００】
スナップショットオペレーションおよびコピーオペレーションは、各々、準備オペレーションおよび起動オペレーションによって構成される。これらの２つの準備および起動ステップにより、準備段階の典型である長期リソース割付けオペレーションを作動から切り離せる。これは、実際には達成に有限ではあるがゼロではない時間量を要する、スナップショットオペレーションのポイントインタイム特性を満たすために短時間しか休止され得ないアプリケーションによって必要とされる。コピーおよびスナップショットオペレーションの場合も同様に、準備および起動のこの２ステップ構造により、ポリシーエンジンが、全てのコレクションメンバのリソースの割付けが可能である場合にのみオペレーションを進行できるようになる。
オブジェクトメンテナンス
【０１０１】
オブジェクト・メンテナンス・オペレーションは、データオブジェクトを保全するための、生成、破壊および複製を含む一連のオペレーションである。オブジェクトマネージャおよびデータムーバは、プール要求ブローカ（後に詳述する）により提供される機能を用いてこれらのオペレーションを実装する。データオブジェクトは、グローバルレベル、ストレージプール毎、または好ましくはこれらの双方で保全されてもよい。
コレクション
【０１０２】
コレクションオペレーションは、補助機能である。コレクションは、抽象的なソフトウェア概念であり、オブジェクトマネージャによってリストがメモリに保全されている。コレクションは、ポリシーエンジン２０６がコレクションにおける全てのメンバに対して一連のオペレーションを要求できるようにし、全てのメンバに対する一貫した要求の適用を可能にする。コレクションの使用は、複数のデータ・ストレージ・オブジェクトが全て正確に同時にキャプチャされるように、ポイントインタイム・スナップショットの同時的起動を可能にしているが、これは典型的には論理的に正しい復元のためにアプリケーションにより必要とされるためである。コレクションの使用は、アプリケーションが複数のストレージオブジェクトを論理的全体として用いる場合において、コレクションの全メンバに亘るコピーオペレーションの簡便な要求を可能にしている。
リソース発見オペレーション
【０１０３】
オブジェクトマネージャは、プールマネージャ５０４へオブジェクト管理オペレーション５０５を発することによって仮想ストレージプールを発見し、かつ各プールについて入手される情報を用いて所定の要求に必要とされる基準を満たすものを選択し、または、満たすものがない場合にはデフォルトのプールが選択され、そしてオブジェクトマネージャは、次に、選択された仮想ストレージプールからのリソースを用いてデータ・ストレージ・オブジェクトを生成することができる。
マッピングおよびアクセス
【０１０４】
また、オブジェクトマネージャは、これらのオブジェクトの外部アプリケーションによる可用性を許容しかつ保全するために一連のオブジェクト管理オペレーションも提供する。第１のセットは、ユーザのアプリケーションが存在するコンピュータを登録しかつ登録解除するためのオペレーションである。コンピュータは、使用中のストレージネットワークに典型的な識別（例えば、Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ  ＷＷＰＮ、ｉＳＣＳＩ識別、他）によって登録される。第２のセットは、「マッピング」オペレーションであって、あるオブジェクトが生成されるストレージプールによって許可されると、データ・ストレージ・オブジェクトは、「マップ」されることが可能であり、即ち、ユーザアプリケーションが存在するコンピュータによる使用が可能にされる。
【０１０５】
この可用性は、例えばＳＡＮ上にＦｉｂｒｅ  Ｃｈａｎｎｅｌディスクまたはネットワーク上のｉＳＣＳＩデバイスとして提示されるブロックデバイス、ファイル共有ネットワーク上のファイルシステム、他である、ストレージに適する形式をとり、かつアプリケーションコンピュータ上のオペレーティングシステムによって使用可能である。同様に、「アンマッピング」オペレーションは、ユーザアプリケーションによるネットワーク上での仮想ストレージデバイスの可用性を無効にする。この方法では、あるアプリケーション用に格納されるデータ、即ちバックアップは、後に別のコンピュータ上の別のアプリケーションによる利用が可能にされる、即ち復元されることが可能である。
５０２データムーバ
【０１０６】
データムーバ５０２は、オブジェクトマネージャから受信されるスナップショット（ポイントインタイム）コピー要求および標準コピー要求の命令に従って様々なデータ・ストレージ・オブジェクト５０３間でデータを読み取りかつ書き込む、オブジェクトマネージャおよびデータムーバ内のソフトウェアコンポーネントである。データムーバは、システム全体のデータオブジェクトのインスタンス間でデータを読み取りかつ書き込むためのオペレーションを提供する。また、データムーバは、オブジェクトマネージャが実行を要求している長期オペレーションの状態を問い合わせかつ保全することを可能にするオペレーションも提供する。
【０１０７】
データムーバは、プール機能プロバイダ（図６参照）からの機能を用いてそのオペレーションを達成する。スナップショット機能プロバイダ６０８は、特定の時点における初期オブジェクトインスタンスを表すデータ・オブジェクト・インスタンスの生成を可能にする。差エンジン機能プロバイダ６１４は、時間連鎖で関連づけられる２つのデータオブジェクト間の差の記述を要求するために使用される。コンテンツアドレス可能ツールに格納されるデータオブジェクトに対しては、任意の２つのデータオブジェクト間の差を提供できる特別な機能が提供される。この機能は、パフォーマンス最適化プールに対しても、幾つかの事例では、基礎を成すストレージ仮想化システムによって提供され、かつ他の事例では、これをコモディティストレージの上に実装するモジュールによって提供される。データムーバ５０２は、この差に関する情報を用いて、データオブジェクト５０３のインスタンス間でコピーするデータセットを選択する。
【０１０８】
所定のプールに関して、差エンジンプロバイダは、経時的なデータ・ストレージ・オブジェクトの２つの状態間の差の特有の表現を提供する。スナップショットプロバイダの場合、２つの時点間の変化は、データ・ストレージ・オブジェクトの所定の部分への書き込みとして記録される。ある実施形態において、この差は、各ビットがデータオブジェクト・エリアの、第１番目に始まり最後へと昇順に順序づけられたリストに対応するビットマップとして表され、あるセットビットは、修正された一エリアを示す。このビットマップは、基礎を成すストレージ仮想化システムにより使用されるコピーオンライトビットマップから導出される。別の実施形態では、この差は、変化したデータエリアに対応するエクステントのリストとして表現されてもよい。コンテンツアドレス可能ストレージプロバイダ６１０の場合、この表現については後述するが、２つのコンテンツアドレス可能データオブジェクトの異なるパーツを効率的に決定するために使用される。
【０１０９】
データムーバは、この情報を用いて異なるセクションのみをコピーし、よって、データオブジェクトの新しいバージョンは、既存のバージョンから、まず既存のバージョンを複製し、差のリストを取得し、次いでリストにおけるこれらの差に対応するデータのみを移動することによって生成されることが可能である。データムーバ５０２は、差のリストをトラバースし、示されるエリアをソース・データ・オブジェクトからターゲット・データ・オブジェクトへ移動させる。（「データのバックアップおよび復元の最適方法」を参照されたい。）
５０６コピーオペレーション−要求変換および命令
【０１１０】
オブジェクトマネージャ５０１は、一連のオペレーションを介してデータムーバ５０２に、仮想ストレージプール４１８内のデータオブジェクト間でデータをコピーするように命令する。この手順は、命令の受信に始まり、下記のステップを含む。
【０１１１】
第１に、コレクション要求を生成する。コレクションの名前が返される。
【０１１２】
第２に、コレクションへオブジェクトを加える。上述の名前、ならびにコピーされるべきソース・データ・オブジェクトの名前、および２つの先例、即ちソース・ストレージ・リソース・プールにおいて差が取得される基準となるデータオブジェクト、およびターゲット・ストレージ・リソース・プールにおける対応するデータオブジェクト、の名前が使用される。このステップは、このセットにおいて動作されるべきソース・データ・オブジェクト毎に反復される。
【０１１３】
第３に、コピー要求を準備する。ターゲットとなるコレクション名、ならびにストレージ・リソース・プールが供給される。準備コマンドは、オブジェクトマネージャに、コレクション内の各ソースに対応する必要なターゲット・データ・オブジェクトを生成すべくストレージ・プール・マネージャに連絡するように命令する。また、準備コマンドは、複製されるべき対応するターゲット・ストレージ・リソース・プール内のデータオブジェクトも供給し、よって、プロバイダは、提供されたオブジェクトを複製しかつこれをターゲットオブジェクトとして用いることができる。コピー要求の参照名が返される。
【０１１４】
第４に、コピー要求を起動する。上述の返されたコピー要求の参照名が供給される。データムーバは、所定のソースオブジェクトをその対応するターゲットオブジェクトへコピーするように命令される。各要求は、参照名、ならびにジョブ全般（ソース・ターゲット・ペアセット全体）を記述するためのシーケンス番号ならびに個々のソース−ターゲットペアを記述するためのシーケンス番号を含む。ソース−ターゲットペアに加えて、対応する先例の名前がコピー命令の一部として供給される。
【０１１５】
第５に、コピーエンジンは、ソースプール内のデータオブジェクトの名前を用いて、先例と、ソースにおける差エンジンからのソースとの差を取得する。示された差は、次に、ソースからターゲットへ送信される。ある実施形態では、これらの差は、ビットマップおよびデータとして送信される。別の実施形態では、これらの差は、エクステントリストおよびデータとして送信される。
５０３データ・ストレージ・オブジェクト
【０１１６】
データ・ストレージ・オブジェクトは、コンピュータデータ処理機器およびソフトウェアにとってなじみのある語法および方法を用いたアプリケーションデータの格納および検索を許容するソフトウェア構築物である。実際には、これらは、現在、例えばＳＣＳＩ  ＬＵＮであるストレージネットワーク上のＳＣＳＩブロックデバイス、またはコンテンツの指示子がそこから構築されかつその内部のデータを一意に識別するコンテンツアドレス可能コンテナの形式をとっている。データ・ストレージ・オブジェクトは、プールマネージャへ命令を発することによって生成されかつ保全される。アプリケーションデータを存続するための実際のストレージは、データ・ストレージ・オブジェクトが生成される仮想ストレージプールから引き出される。
【０１１７】
データ・ストレージ・オブジェクトの構造は、それが生成されるソースプールに依存して変わる。ストレージネットワーク上のブロックデバイスの形式をとるオブジェクトの場合、所定のブロックデバイス・データオブジェクトのデータ構造体は、デバイス識別子に対するデータオブジェクト内の各ブロックの論理ブロックアドレス（ＬＢＡ）と、実際のストレージロケーションのＬＢＡとの間のマッピングを実装する。データオブジェクトの識別子は、使用されるべきマッピングセットを識別するために使用される。現行の実施形態は、基礎を成す物理コンピュータプラットフォームによりこのマッピングを実装するために提供されるサービスに依存し、かつビットマップまたはエクステントリスト等のその内部データ構造体に依存する。
【０１１８】
コンテンツアドレス可能コンテナの形式をとるオブジェクトの場合、コンテンツ署名が識別子として使用され、かつデータオブジェクトは、重複排除に関する項目において後述するようにして格納される。
５０４プールマネージャ
【０１１９】
プールマネージャ５０４は、仮想ストレージリソースおよび後述するような関連の機能および特性を管理するためのソフトウェアコンポーネントである。オブジェクトマネージャ５０１およびデータ移動エンジン５０２は、データ・ストレージ・オブジェクト５０３を保全するために１つまたは複数のプールマネージャ５０４と通信する。
５１０仮想ストレージリソース
【０１２０】
仮想ストレージリソース５１０は、後述するように、プールマネージャがストレージプール機能を実装するために利用可能にされる様々な種類のストレージである。この実施形態では、ストレージバーチャライザを用いて、様々な外部Ｆｉｂｒｅ  ＣｈａｎｎｅｌまたはｉＳＣＳＩストレージＬＵＮが仮想化ストレージとしてプールマネージャ５０４へ提示される。
ストレージ・プール・マネージャ
【０１２１】
図６は、ストレージ・プール・マネージャ５０４を詳述している。ストレージ・プール・マネージャの目的は、基礎を成す仮想ストレージリソースをオブジェクトマネージャ／データムーバへ、システムの他のコンポーネントにより利用される共通のインタフェースを有するストレージおよびデータ管理機能の抽象化であるストレージ・リソース・プールとして提示することにある。これらの共通インタフェースは、典型的には、特有の時間状態に関連づけられるデータオブジェクトを識別してアドレス指定するための機構と、ビットマップまたはエクステント形式のデータオブジェクト間の差を作り出すための機構とを含む。この実施形態では、プールマネージャは、一次ストレージプール、パフォーマンス最適化プールおよびキャパシティ最適化プールを提示する。共通インタフェースにより、オブジェクトマネージャがこれらのプールにおいてデータ・ストレージ・オブジェクトを、他のデータ・ストレージ・オブジェクトのコピーまたは新しいオブジェクトの何れかとして生成しかつ削除できるようになり、かつデータムーバは、データ・ストレージ・オブジェクト間でデータを移動させることができ、かつデータオブジェクト・ディファレンシング・オペレーションの結果を用いることができる。
【０１２２】
ストレージ・プール・マネージャは、何らかの機能が基礎を成す「スマート」なリソースによって提供されかつ他の機能は基礎を成すより低い機能性のリソースの上に実装されなければならない類似機能の多様な実装、への共通インタフェースを実装するための典型的なアーキテクチャを有する。
【０１２３】
プール要求ブローカ６０２およびプール機能プロバイダ６０４は、オブジェクトマネージャ／データムーバと同じプロセス、またはＴＣＰ等のローカルまたはネットワークプロトコルを介して通信する別のプロセスの何れかで実行するソフトウェアモジュールである。この実施形態において、プロバイダは、一次ストレージプロバイダ６０６と、スナップショットプロバイダ６０８と、コンテンツアドレス可能プロバイダ６１０と、差エンジンプロバイダ６１４とを備えるが、これらについては後に詳述する。別の実施形態において、このプロバイダセットは、図６に示されているもののサブセットであってもよい。
【０１２４】
仮想ストレージリソース５１０は、プールマネージャがストレージプール機能を実装するために利用可能にされる異なる種類のストレージである。この実施形態において、仮想ストレージリソースは、プールマネージャと同じハードウェア上で実行されかつプログラマティックインタフェースを介して（データオペレーションおよび管理オペレーションの双方のために）アクセス可能なストレージ仮想化システムからのＳＣＳＩ論理ユニットセットを備え、即ち、標準的なブロックストレージ機能に加えて、スナップショットの生成および削除および変化したボリューム部分の追跡を含む、追加のケイパビリティを利用可能である。別の実施形態において、仮想リソースは、類似のケイパビリティをエクスポーズする、またはインタフェース（例えば、ファイルシステムを介して、またはＣＩＦＳ、ｉＳＣＳＩまたはＣＤＭＩ等のネットワークインタフェースを介してアクセスされる）、ケイパビリティ（例えば、リソースがコピーオンライト・スナップショットを作成するオペレーションをサポートするかどうか）または非機能態様（例えば、ソリッド・ステート・ディスク等の高速／限定キャパシティ対ＳＡＴＡディスク等の低速／高キャパシティ）を異にする、外部ストレージシステムからである可能性がある。ケイパビリティおよび利用可能なインタフェースは、どのプロバイダが仮想ストレージリソースを消費できるか、および１つまたは複数のプロバイダによってどのプール機能がプールマネージャ内に実装される必要があるか、を決定し、例えば、コンテンツアドレス可能ストレージプロバイダによるこの実装は、「ダム」ストレージを必要とするだけであって、この実装は、完全にコンテンツアドレス可能プロバイダ６１０の範囲内にあり、基礎を成すコンテンツアドレス可能仮想ストレージリソースは、代わりにより単純な「パススルー」プロバイダによって使用される可能性もある。逆に、スナップショットプロバイダのこの実装は、ほとんど「パススルー」であって、迅速なポイントインタイム・コピーオペレーションをエクスポーズするストレージを必要とする。
【０１２５】
プール要求ブローカ６０２は、構成された仮想ストレージリソース５１０に対して適切なプール機能プロバイダセットを実行することによりストレージプール固有機能の要求を提供する単純なソフトウェアコンポーネントである。提供され得る要求には、プール内にオブジェクトを生成することと、プールからオブジェクトを削除することと、オブジェクトへデータを書き込むことと、オブジェクトからデータを読み取ることと、プール内にオブジェクトをコピーすることと、プール間でオブジェクトをコピーすることと、プール内の２オブジェクト間の差の要約を要求すること、が含まれるが、この限りではない。
【０１２６】
一次ストレージプロバイダ６０６は、同じくファイバチャネル、ｉＳＣＳＩ、ＮＦＳまたはＣＩＦＳ等のインタフェースを介して直にアプリケーションへエクスポーズされる仮想ストレージリソースへの管理インタフェース（例えば、スナップショットの生成および削除、および変化したファイル部分の追跡）を有効化する。
【０１２７】
スナップショットプロバイダ６０８は、一次リソースプールからのデータのポイントインタイム・コピーを作成する機能を実装する。これにより、スナップショットでポピュレートされた別のリソースプールの抽象物が生成される。この管理機能は、一次ストレージおよびスナップショットプロバイダに使用される仮想ストレージリソースによってエクスポーズされることから、実装に際して、このポイントインタイム・コピーは、一次リソースプールからのオブジェクトのコピーオンライト・スナップショットであり、コピーオンライト・コピーを収容するために第２の仮想ストレージリソースを消費する。
【０１２８】
差エンジンプロバイダ６１４は、プール内の時間連鎖において接続される２オブジェクトの比較要求を満たすことができる。２オブジェクト間の差セクションは、プロバイダ固有の方法で、例えばビットマップまたはエクステントを用いて識別され、かつ要約される。例えば、差セクションは、各セットビットが２オブジェクトで異なる固定サイズ領域を示すビットマップとして表される場合もあれば、これらの差が、手順的に一連の関数呼び出しまたは呼び戻しとして表される場合もある。
【０１２９】
プールが基礎とする仮想ストレージリソース、またはプールを実装する他のプロバイダに依存して、差エンジンは、結果を効率的に様々な方法でもたらしてもよい。実装に際して、スナップショットプロバイダを介して実装される、プールに作用する差エンジンは、スナップショットプロバイダのコピーオンライト的性質を用いて、スナップショットを作らせていたオブジェクトの変化を追跡する。したがって、変化する単一の一次オブジェクトの連続するスナップショットは、スナップショットプロバイダによってスナップショットと共に格納される差のレコードを有し、スナップショットプールの差エンジンは、単に、この変化のレコードを検索する。同じく実装に際して、プールに作用する、コンテンツアドレス可能プロバイダを介して実装される差エンジンは、コンテンツアドレス可能実装の効率的な木構造（後述の図１２参照）を用いてオンデマンドでオブジェクト間の高速比較を実行する。
【０１３０】
コンテンツアドレス可能プロバイダ６１０は、消費する仮想ストレージリソースへのライトワンス・コンテンツ・アドレス可能インタフェースを実装する。これは、読み取り、書き込み、複製および削除のオペレーションを履行する。書き込まれた、またはコピーされたオブジェクトは、各々、そのコンテンツから導出される一意のハンドルによって識別される。コンテンツアドレス可能プロバイダについては、後に詳述する（図１１）。
プールマネージャのオペレーション
【０１３１】
プール要求ブローカ５０２は、動作中、プールまたはオブジェクト上でのコピー、スナップショットまたは削除等のデータ操作オペレーションの要求を受け付ける。要求ブローカは、プール５０４からのどのプロバイダコードを実行するかを、名前を見ること、またはプールまたはオブジェクトへの参照によって決定する。ブローカは、次に、着信するサービス要求を、特有のプール機能プロバイダによって処理されることが可能な形式に変換し、かつ適切なシーケンスのプロバイダオペレーションを呼び出す。
【０１３２】
例えば、着信する要求は、一次ストレージプールにおけるボリュームからのスナップショットをスナップショットプール内へ作成するように求める可能性もある。着信する要求は、一次ストレージプール内のオブジェクト（ボリューム）を名前によって識別し、名前とオペレーション（スナップショット）との組合せは、基礎を成すスナップショットケイパビリティを用いて一次プールからポイントインタイム・スナップショットを作成することができるスナップショットプロバイダが呼び出されるべきであることを決定する。このスナップショットプロバイダは、要求を、ネイティブなコピーオンライト機能が必要とする、基礎を成すストレージ仮想化アプライアンスにより実行されるビットマップまたはエクステント等の厳密な形式へ変換し、かつスナップショットプロバイダは、ネイティブのコピーオンライト機能の結果をストレージ・ボリューム・ハンドルへ変換し、これは、オブジェクトマネージャへ戻されることが可能であって、プールマネージャに対する将来の要求において使用される。
オブジェクトマネージャおよびデータムーバを用いる最適なデータバックアップ方法
【０１３３】
最適なデータバックアップ方法は、経時的にアプリケーション・データ・オブジェクトの連続的なバージョンを作成し、同時に、オブジェクトムーバに格納されるビットマップ、エクステントおよび他の時間差情報を用いることによってコピーされなければならないデータの量を最小限に抑える、一連のオペレーションである。これは、アプリケーションデータをデータ・ストレージ・オブジェクトに格納し、かつ経時的に、これと、様々な変化を経時的にアプリケーションデータに関連させるメタデータとを関連づけ、よって、経時的な変化を即座に識別することができる。
【０１３４】
ある好ましい実施形態において、手順は、下記のステップを含む。
１．機構は、データ・ストレージ・オブジェクト内にアプリケーションデータの最初の参照状態、例えばＴ０を提供する。
２．オンデマンドで経時的に、差エンジンプロバイダを有する仮想ストレージプール内に、データ・ストレージ・オブジェクトの後続インスタンス（バージョン）が生成される。
３．連続する各バージョン、例えばＴ４、Ｔ５は、仮想ストレージプールの差エンジンプロバイダを用いて各バージョンと先行して生成されたインスタンスとの差を取得し、よってＴ５は、Ｔ４の参照として、かつＴ５とＴ４との差集合として格納される。
４．コピーエンジンは、あるデータオブジェクト（ソース）からのデータを別のデータオブジェクト（宛先）へコピーする要求を受信する。
５．宛先オブジェクトが生成されることになる仮想ストレージプールが、先行バージョンのソース・データ・オブジェクトから生成された他のオブジェクトを含んでいなければ、宛先仮想ストレージプール内に新しいオブジェクトが生成され、ソース・データ・オブジェクトのコンテンツ全体がこの宛先オブジェクトへコピーされて手順は完了する。そうでなければ、次のステップへ続く。
６．宛先オブジェクトが生成される仮想ストレージプールが、先行バージョンのソース・データ・オブジェクトから生成されたオブジェクトを含んでいれば、宛先仮想ストレージプールにおける最近生成された先行バージョンのうちの、ソース・データ・オブジェクトの仮想ストレージプール内に対応する先行バージョンが存在するものが選択される。例えば、Ｔ５のコピーがスナップショットプールから開始され、かつ時間Ｔ３において生成されたオブジェクトがターゲットにおいて利用可能な最新バージョンであれば、Ｔ３が先行バージョンとして選択される。
７．ソース・データ・オブジェクトのバージョンの、先行ステップにおいて識別された最初のバージョンで始まり、まさにコピーされようとしているソース・データ・オブジェクトで終わる時間順リストを構築する。上述の例において、スナップショットプールでは、オブジェクトの全状態が利用可能であるが、関心対象は、Ｔ３以降、即ちＴ３、Ｔ４、Ｔ５の状態のみである。
８．リスト内の連続する各バージョン間の差の対応するリストを、リストの初めのバージョンから終わりまでの全ての差が表現されるように構築する。双方に区別を立て、対応する時間の間にデータのどの部分が変化しかつ新しいデータを含むかを識別する。これにより、ターゲットバージョンからソースバージョンまでの差集合、例えばＴ３とＴ５との差が生成される。
９．宛先オブジェクトを、宛先仮想ストレージプール、例えばターゲットストアにおけるオブジェクトＴ３において、ステップ６で識別された先行バージョンのオブジェクトを複製することにより生成する。
１０．ステップ８で生成されたリストにおいて識別される差集合をソース・データ・オブジェクトから宛先オブジェクトへコピーし、手順が完了する。
【０１３５】
宛先仮想ストレージプール内の各データオブジェクトは、完全であり、即ちこれは、データオブジェクト全体を表していて、他の時点における状態または表現への外的参照を必要とすることなく、その時点での全アプリケーションデータへのアクセスを許容する。オブジェクトは、ベースライン状態から全デルタを現在状態へリプレイすることなくアクセス可能である。さらに、データオブジェクトの最初の、および後続バージョンの宛先仮想ストレージプールへの複製は、前記プールにおけるアプリケーション・データ・コンテンツの網羅的複製を必要としない。最後に、第２の、かつ後続の状態へ到達するには、先に述べたように、データ・ストレージ・オブジェクトのコンテンツを網羅的にトラバースする、伝達する、または複製することなく、追跡されかつ保全された変化を伝達するだけでよい。
オブジェクトマネージャおよびデータムーバを用いる最適なデータ復元方法
【０１３６】
直観的に言えば、最適なデータ復元方法のオペレーションは、最適なデータバックアップ方法の逆である。宛先仮想ストレージプールにおいて所定の時点で所望されるデータオブジェクトの状態を再現する手順は、下記のステップを含む。
１．差エンジンプロバイダを有する別の仮想ストレージプールにおける、再現されるべき所望される状態に対応するバージョンのデータオブジェクトを識別する。これは、ソース仮想ストレージプールにおけるソース・データ・オブジェクトである。
２．宛先仮想ストレージプールにおける、再現されるべき先行バージョンのデータオブジェクトを識別する。
３．ステップ２においてデータオブジェクトのバージョンが識別されなければ、宛先仮想ストレージプール内に新しい宛先オブジェクトを生成し、かつソース・データ・オブジェクトからのデータを宛先データオブジェクトへコピーする。手順は、完了する。そうでなければ、下記のステップへ進む。
４．ステップ２においてデータオブジェクトのバージョンが識別されれば、ソース仮想ストレージプールにおける、ステップ２で識別されたデータオブジェクトに対応するデータオブジェクトを識別する。
５．ステップ４においてデータオブジェクトが識別されなければ、宛先仮想ストレージプール内に新しい宛先オブジェクトを生成し、かつソース・データ・オブジェクトからのデータを宛先データオブジェクトへコピーする。手順は、完了する。そうでなければ、下記のステップへ進む。
６．ステップ２で識別されたデータオブジェクトを複製することにより、宛先仮想ストレージプール内に新しい宛先データオブジェクトを生成する。
７．ソース仮想ストレージプールの差エンジンプロバイダを使用して、ステップ１で識別されたデータオブジェクトと、ステップ４で識別されたデータオブジェクトとの差集合を取得する。
８．ステップ７で生成されたリストにより識別される、ソース・データ・オブジェクトからのデータを宛先データオブジェクトへコピーする。手順は、完了する。
【０１３７】
所望される状態へのアクセスは、完了し、これは、他のコンテナへの外的参照または他の状態を必要としない。参照状態を所与として所望される状態を確立することは、網羅的なトラバーサルも網羅的な伝達も必要とせず、ソース仮想ストレージプール内に提供される表現により示される検索された変化を要するのみである。
サービス・レベル・アグリーメント
【０１３８】
図７は、サービス・レベル・アグリーメントを示す。サービス・レベル・アグリーメントは、アプリケーションデータの二次コピーに関する詳細なビジネス要件をキャプチャする。最も単純に説明すると、ビジネス要件は、コピーを生成する時間および頻度、その保持時間およびこれらのコピーを入れるストレージプールのタイプを規定する。このあまりに単純な説明は、ビジネス要件の幾つかの態様について述べていない。所定のタイプのプールのコピー生成頻度は、一日２４時間、または一週間で毎日一様でなくてもよい。一日のうちの所定の時間、または一週間もしくは一か月のうちの所定の日は、アプリケーションデータにおけるより多い（またはより少ない）臨界期間を表してもよく、よって、より多い（またはより少ない）頻度のコピーを求めてもよい。同様に、ある特定のプールにおけるアプリケーションデータの全てのコピーは、同じ時間長さに亘って保持されるように要求されなくてもよい。例えば、月極の処理の終わりに生成されるアプリケーションデータのコピーは、同じストレージプールにおいて月の半ばで生成されるコピーより長い期間に亘って保持されなければならない場合がある。
【０１３９】
所定の実施形態のサービス・レベル・アグリーメント３０４は、ビジネス要件に存在するこれらの複雑さを全て表すように設計されている。サービス・レベル・アグリーメントは、４つの主要部分、即ちサービス・レベル・ポリシーの名前、記述、ハウスキーピング属性およびコレクション、を有する。先に述べたように、ＳＬＡは、アプリケーション毎に１つ存在する。
【０１４０】
名前属性７０１は、各サービス・レベル・アグリーメントが１つの一意の名前を有することを許容する。
【０１４１】
記述属性７０２は、ユーザがサービス・レベル・アグリーメントに関して有用な記述を挙げることができる場所である。
【０１４２】
また、サービス・レベル・アグリーメントは、サービス・レベル・アグリーメントを保全しかつ改訂できるようにする幾つかのハウスキーピング属性７０３も有する。これらの属性には、所有者の識別、生成、修正およびアクセスの日時、優先性、イネーブル／ディスエーブルフラグ、が含まれるが、この限りではない。
【０１４３】
また、サービス・レベル・アグリーメントは、複数のサービス・レベル・ポリシー７０５も含む。サービス・レベル・アグリーメントの中には、単一のサービス・レベル・ポリシーだけを有してもよいものがある。より典型的には、単一のＳＬＡが何十ものポリシーを含んでもよい。
【０１４４】
各サービス・レベル・ポリシーは、所定の実施形態において、少なくとも次のもの、即ち、ソース・ストレージ・プールのロケーション７０６およびタイプ７０８、ターゲット・ストレージ・プールのロケーション７１０およびタイプ７１２、時間期間で表されるコピー生成頻度７１４、時間期間で表されるコピーの保持長さ７１６、この特定のサービス・レベル・ポリシーの一日当たりのオペレーション時間数７１８、およびこのサービス・レベル・ポリシーを適用する一週間、一か月または一年当たりの日数７２０、より成る。
【０１４５】
各サービス・レベル・ポリシーは、ソースおよびターゲットのストレージプール、およびこれらのストレージプール間で所望されるアプリケーションデータのコピー頻度を指定する。さらに、サービス・レベル・ポリシーは、サービス・レベル・ポリシーを適用できるそのオペレーション時間および日数を指定する。各サービス・レベル・ポリシーは、アプリケーションデータ保護のためのビジネス要件における単一のステートメントを表現したものである。例えば、ある特定のアプリケーションが、月締め後に毎月アーカイブコピーを生成しかつ３年間保持するというビジネス要件を有していれば、これは、月末日の真夜中にローカル・バックアップ・ストレージ・プールから長期アーカイブ・ストレージ・プールへコピーして３年間保持することを求めるサービス・レベル・ポリシーに書き換えられる場合もある。
【０１４６】
ソースおよび宛先のプールおよびロケーションのある特定の組合せ、例えばソースの一次ストレージプールと宛先のローカル・スナップショット・プールとの組合せを有する全てのサービス・レベル・ポリシーは、全体で、この特定の宛先プールへコピーを生成するためのビジネス要件を指定する。ビジネス要件は、例えば、正規の勤務時間内では毎時にスナップショットコピーを生成するが、時間外では４時間おきに一度だけ生成するように命じてもよい。同じソースおよびターゲット・ストレージ・プールを有する２つのサービス・レベル・ポリシーは、これらの要件を、サービス・ポリシー・エンジンによって実施されることが可能な形式で効果的にキャプチャする。
【０１４７】
この形式のサービス・レベル・アグリーメントは、毎日、週間および月間のビジネス活動のスケジュールを表現できるようにし、ひいては、アプリケーションデータを保護しかつ管理するためのビジネス要件を、伝統的なＲＰＯスキームおよびＲＰＯベースのスキームより遙かに正確にキャプチャする。年間のオペレーションの時間、日数、週間数および月数を見込むことにより、スケジューリングは、「カレンダーベース」で発生することが可能である。
【０１４８】
全体として、ソースおよび宛先のある特定の組合せ、例えば「ソース：ローカル一次、および宛先：最適化されたローカルパフォーマンス」、を有する全てのサービス・レベル・ポリシーは、あるタイプのストレージの非一様なデータ保護要件をキャプチャする。一方で、単一のＲＰＯ数は、データ保護の単一の一様な頻度を一日中および毎日強要する。例えば、ある組合せのサービス・レベル・ポリシーは、多数のスナップショットが１０分等の短時間保存され、かつより少ない数のスナップショットが８時間等のより長い時間に亘って保存されることを要求してもよく、これにより、誤って削除された少量の情報を過去１０分以内の状態に戻すことが可能になり、しかも同時に、相当なデータ保護が、より長い計画対象期間において、１０分おきに取られる全てのスナップショットを格納するストレージオーバーヘッドを必要とすることなく提供される。別の例として、バックアップデータ保護機能には、週間労働の間はある頻度、かつ週末は別の頻度で動作する１つのポリシーが与えられてもよい。
【０１４９】
全ての異なるクラスのソースおよび宛先ストレージのサービス・レベル・ポリシーが含まれる場合、サービス・レベル・アグリーメントは、ローカルスナップショット、ローカル長持続時間ストア、オフサイトストレージ、アーカイブ、他を含む、アプリケーション全体のデータ保護要件を全て完全にキャプチャする。ＳＬＡ内のポリシーのコレクションは、所定の機能がいつ実行されるべきかを表すことができ、かつ所定のデータソース上で実行されるべき複数のデータ管理機能を表すことができる。
【０１５０】
サービス・レベル・アグリーメントは、ユーザにより、管理ワークステーション上のユーザインタフェースを介して生成され、かつ修正される。これらのアグリーメントは、サービス・ポリシー・エンジンによって、サービス・ポリシー・エンジンが管理する構造化されたＳＱＬデータベースまたは他のレポジトリに格納される電子文書である。ポリシーは、後述するように、サービス・ポリシー・エンジンにより、その通常のスケジューリングアルゴリズムを介して検索され、電子的に分析されかつ作用される。
【０１５１】
図８は、アプリケーション指定モジュール４０２を示す。アプリケーション指定モジュールは、（先に述べたように）アプリケーション３００に密着して実行され、かつアプリケーションおよびその動作環境と相互作用してメタデータを集め、かつデータ管理オペレーションの必要に応じてアプリケーションに問い合わせを行いかつこれを制御する。
【０１５２】
アプリケーション指定モジュールは、アプリケーション・サービス・プロセスおよびデーモン８０１、アプリケーション構成データ８０２、オペレーティング・システム・ストレージ・サービス８０３（Ｗｉｎｄｏｗｓ（登録商標）上のＶＳＳおよびＶＤＳ等）、論理ボリューム管理およびファイルシステムサービス８０４およびオペレーティング・システム・ドライバおよびモジュール８０５を含む、アプリケーションおよびその動作環境の様々なコンポーネントと相互作用する。
【０１５３】
アプリケーション指定モジュールは、サービス・ポリシー・エンジン４０６からの制御コマンドに応答してこれらのオペレーションを実行する。アプリケーションとのこれらの相互作用には、メタデータコレクションおよびアプリケーション整合性という２つの目的がある。
【０１５４】
メタデータコレクションは、アプリケーション指定モジュールがアプリケーションに関するメタデータを収集するプロセスである。実施形態によっては、メタデータは、アプリケーションの構成パラメータ、アプリケーションの状態およびステータス、アプリケーションの制御ファイルおよびスタートアップ／シャットダウンスクリプト、アプリケーションのデータファイル、ジャーナルおよびトランザクションログのロケーション、およびシンボルリンク、ファイルシステム・マウント・ポイント、論理ボリューム名およびアプリケーションデータへのアクセスに影響を与える可能性がある他のエンティティ等の情報を含む。
【０１５５】
メタデータは、アプリケーションデータおよびＳＬＡ情報と共に収集されかつ保存される。これは、システム内のアプリケーションデータの各コピーが自足的であって、アプリケーションデータの復元に必要とされる全ての詳細を含むことを保証する。
【０１５６】
アプリケーション整合性は、アプリケーションデータのコピーが生成される場合、そのコピーが有効であって、アプリケーションの有効なインスタンスへ復元され得ることを保証する一連のアクションである。これは、ビジネス要件が、アプリケーションをそのオンラインの動作可能状態においてライブである間に保護することを命じる場合に極めて重要である。アプリケーションは、そのデータストア内で相互依存的なデータ関係を有してもよく、よって、これらの関係性が整合状態でコピーされなければ、有効な復元可能画像を提供しない。
【０１５７】
アプリケーション整合性を達成する正確なプロセスは、アプリケーション毎に変わる。アプリケーションの中には、キャッシュデータをディスクへ押し込む単純なフラッシュコマンドを有するものがある。アプリケーションの中には、ホットバックアップ・モードをサポートするものがあるが、この場合、アプリケーションは、アプリケーションデータが変化しつつある場合でもそのオペレーションが整合性を保証する方式でジャーナルされることを保証する。アプリケーションの中には、整合性を保証するために、ＶＳＳおよびＶＤＳ等のオペレーティング・システム・ストレージ・サービスとの相互作用を必要とするものがある。アプリケーション指定モジュールは、ある特定のアプリケーションと共働するために、かつそのアプリケーションの整合性を保証するために特設される。アプリケーション指定モジュールは、基礎を成すストレージ仮想化デバイスおよびオブジェクトマネージャと相互作用してアプリケーションデータの整合したスナップショットを提供する。
【０１５８】
効率のために、アプリケーション指定モジュール４０２のこの好ましい実施形態は、アプリケーション３００と同じサーバ上で実行される。これは、アプリケーションとの相互作用における最短の待ち時間を保証し、かつアプリケーションホスト上のストレージサービスおよびファイルシステムへのアクセスを提供する。アプリケーションホストは、典型的には、一次ストレージとされ、これは次に、パフォーマンス最適化ストアへスナップショットされる。
【０１５９】
準備ステップを最小限に抑えることを含み、実行中のアプリケーションの中断を最小限に抑えるために、アプリケーション指定モジュールは、ある特有の時間にアプリケーションデータへのアクセスが必要とされる場合、かつオブジェクトマネージャによる追跡によれば、その時間にシステム内で他にスナップショットが存在しない場合に限って、スナップショットの作成をトリガされる。いつの時点でスナップショットが作成されているかを追跡することにより、オブジェクトマネージャは、二次キャパシティ最適化プールから出される場合のある複数のバックアップおよび複製要求を満たすためであることを含み、パフォーマンス最適化データストアからの後続のデータ要求を満たすことができる。オブジェクトマネージャは、オブジェクトハンドルをパフォーマンス最適化ストア内のスナップショットへ提供することができてもよく、かつパフォーマンス最適化ストアを、基礎を成すストレージアプライアンスに依存する、スナップショットのフォーマットに固有のネイティブフォーマットに方向づけてもよい。実施形態によっては、このフォーマットは、どのブロックが変化しているかを示す１つまたは複数のＬＵＮビットマップと結合されるアプリケーションデータであってもよく、他の実施形態では、これは、特有のエクステントであってもよい。したがって、データ転送に使用されるフォーマットは、ビットマップまたはエクステントを用いて、２つのスナップショット間のデルタまたは差のみを転送することができる。
【０１６０】
アプリケーションのバージョン番号等のメタデータは、アプリケーション毎にスナップショットと共に格納される場合もある。ＳＬＡポリシーが実行される場合、アプリケーションメタデータが読み取られ、かつポリシーに使用される。このメタデータは、データオブジェクトと共に格納される。アプリケーションデータのコピーはそのメタデータと共に複数のデータ管理機能に使用され得るが、各ＳＬＡについて、アプリケーションメタデータは、ライトウェイト・スナップショット・オペレーションの間に一度読み取られるだけであり、かつその時点で発生するキャッシュフラッシュ等の準備オペレーションは、ライトウェイト・スナップショット・オペレーションの間に一度実行されるだけである。
サービス・ポリシー・エンジン
【０１６１】
図９は、サービス・ポリシー・エンジン４０６を示す。サービス・ポリシー・エンジンは、サービス・ポリシー・スケジューラ９０２を含み、これは、ユーザにより設定される全てのサービス・レベル・アグリーメントを調べてサービス・レベル・アグリーメントを満たすスケジューリング決定を下す。これは、情報をキャプチャしてこれを長時間持続させるために、実施形態によっては、設定されたサービス・レベル・アグリーメントが持続されかつ更新されるＳＬＡストア９０４と、論理ストレージプール名と実際のストレージプールとの間のマッピングを提供するリソースプロファイルを格納するリソース・プロファイル・ストア９０６と、まだ期限切れになっていない様々なプールにおいて生成された先行する成功したコピーに関する情報がカタログにされる保護カタログストア９０８と、集中化された履歴ストア９１０と、を含む幾つかのデータストアに依存する。
【０１６２】
履歴ストア９１０は、全てのデータ管理アプリケーションの使用のために、各アプリケーションの様々なストレージプールへの先行コピーのタイムスタンプ、順序および階層を含む過去のアクティビティに関する履歴情報が保存される場所である。例えば、午後１時に開始されて午後９時に終了する予定の一次データストアからキャパシティ最適化データストアへのスナップショットコピーは、履歴ストア９１０の、午前１１時および午後１２時に行われた同じソースおよびターゲットのスナップショットのリンクされたオブジェクトデータも含む時間データストアに記録される。
【０１６３】
これらのストアは、サービス・ポリシー・エンジンによって管理される。例えば、ユーザが、管理ワークステーションを介してサービス・レベル・アグリーメントを生成する、またはその中のポリシーの１つを修正する場合、この新しいＳＬＡをそのストアに持続させ、かつＳＬＡが命じる通りにコピーをスケジュールすることによってこの修正に反応するものは、サービス・ポリシー・エンジンである。同様に、サービス・ポリシー・エンジンがデータ移動ジョブを首尾良く完了して、ストレージプールにアプリケーションの新しいコピーが生じると、ストレージ・ポリシー・エンジンは、履歴ストアを更新し、よってこのコピーは、将来の決定において考慮される。
【０１６４】
サービス・ポリシー・エンジンにより使用される様々なストアの好ましい実施形態は、サービス・ポリシー・エンジンに近接するリレーショナルデータベース管理システムにおけるテーブルの形式である。これにより、ストアの照会および更新時の整合したトランザクションのセマンティクスが保証され、かつ相互依存的データの検索における自在性が見込まれる。
【０１６５】
サービス・ポリシー・スケジューラ９０２のスケジューリングアルゴリズムを、図１０に示す。サービス・ポリシー・スケジューラは、あるストレージプールから別のストレージプールへアプリケーションデータのコピーを作成する必要があると決定すると、データ移動リクエスタおよびモニタタスク９１２を開始する。これらのタスクは、繰返し発生するタスクではなく、完了した時点で終了する。サービス・レベル・ポリシーが指定される方法に依存して、これらのリクエスタは、複数が同時に動作可能である場合もある。
【０１６６】
サービス・ポリシー・スケジューラは、どの追加的タスクを引き受けるかを決定する際に、サービス・レベル・アグリーメントの優先順位を考慮する。例えば、あるサービス・レベル・アグリーメントが、ミッションクリティカルなアプリケーションの保護を規定していることに起因して高い優先順位を有し、これに対して別のＳＬＡが、テストデータベースの保護を規定していることに起因してより低い優先順位を有していれば、サービス・ポリシー・エンジンは、ミッションクリティカルなアプリケーションの保護のみの実行を選択してもよく、かつより低い優先順位のアプリケーションの保護を後回しにする、または完全に省いてしまってもよい。これは、より高い優先順位のＳＬＡをより低い優先順位のＳＬＡより先にスケジュールするサービス・ポリシー・エンジンによって達成される。この好ましい実施形態では、このような状況において、サービス・ポリシー・エンジンは、監査を目的として、管理ワークステーションへの通知イベントもトリガする。
ポリシー・スケジューリング・アルゴリズム
【０１６７】
図１０は、ポリシー・スケジュール・エンジンのフローチャートを示す。ポリシー・スケジュール・エンジンは、規定された全てのＳＬＡを介して絶えず循環する。ポリシー・スケジュール・エンジンは、全てのＳＬＡの終わりに達すると、短時間、例えば１０秒間スリープし、かつＳＬＡを介する調査を再開する。各ＳＬＡは、１つのアプリケーションの完全なデータ保護ビジネス要件をカプセル化し、よって、全てのＳＬＡは、全てのアプリケーションを表現する。
【０１６８】
各ＳＬＡについて、スケジュールエンジンは、１００４において、１０００におけるプロセス状態で同じソースプールおよび宛先プールを有する全てのサービス・レベル・ポリシーを纏めて収集し、かつ１００２において、一連のＳＬＡにおける次のＳＬＡに対してこれを反復する。纏めて収集されることにより、サービス・レベル・ポリシーのこのサブセットは、このソース・ストレージ・プールからこの特定の宛先ストレージプールへのコピーに関する要件を全て表現する。
【０１６９】
サービス・レベル・ポリシーのこのサブセットの中で、サービス・ポリシー・スケジューラは、その日に適用されないポリシー、またはその動作時間外のポリシーを捨てる。１００６では、残ったポリシーの中から、最短頻度を有するポリシーが発見され、かつ１００８では、履歴データを基礎として、かつ履歴ストア９１０において、次に実行される必要がある最も長く保持されているポリシーが発見される。
【０１７０】
次に、その時点でのアプリケーションデータの新しいコピー作りを、まだ新しいコピーを作成する時ではない、コピーが既に進行中である、またはコピーする新しいデータが存在しないことを理由に阻止する一連のチェック１０１０−１０１４が存在する。これらの条件のうちの何れかが該当すれば、サービス・ポリシー・スケジューラは、１００４において、ソースおよび宛先プールの次の組合せへと移る。これらの条件の何れにも該当しなければ、新しいコピーが開始される。１０１６において、コピーは、このＳＬＡにおける対応するサービス・レベル・ポリシーに明記されている通りに実行される。
【０１７１】
次に、１０１８において、スケジューラは、同じサービス・レベル・アグリーメントの次のソースおよび宛先プールの組合せへ移る。他に明確な組合せが存在しなければ、１０２０において、スケジューラは、次のサービス・レベル・アグリーメントへ進む。
【０１７２】
サービス・ポリシー・スケジューラは、全てのサービス・レベル・アグリーメントの全てのソース／宛先プールの組合せを調べ終わると、短期間休止し、次いでサイクルを再開する。
【０１７３】
２つのポリシーしか規定されていない、スナップショットストアおよびバックアップストアを有する単純なシステム例は、サービス・ポリシー・スケジューラと下記のように相互作用する。一方が「毎時バックアップし、バックアップを４時間保持する」と規定し、かつもう一方が「２時間おきにバックアップし、バックアップを８時間保持する」と規定する２つのポリシーを所与とすれば、結果として、毎時単一のスナップショットが取られ、スナップショットはバックアップストアへその度にバックアップストアへコピーされるが、スナップショットストアおよびバックアップストアの双方において保持される時間が異なる。「２時間おきにバックアップ」というポリシーは、システム管理者によって午後１２時に発効するようにスケジュールされる。
【０１７４】
サービス・ポリシー・スケジューラは、ステップ１０００において、午後４時に動作を開始すると、ステップ１００２において、２つのポリシーを発見する。（午後１２時以降、２時間が複数回経過していることから、双方のポリシーが適用される。）ステップ１００４では、ソースおよび宛先プールの組合せが１つだけ存在する。ステップ１００６では、２つの頻度が存在し、システムは、２時間頻度より短いという理由で１時間頻度を選択する。ステップ１００８では、異なる持続時間を有する２つのオペレーションが存在し、システムは、より長い保持時間値を有するという理由で、保持８時間を有するオペレーションを選択する。１つのコピーが４時間の要件を満たして作成され、かつ別のコピーが８時間の要件を満たして作成される代わりに、これらの２つの要件は、単一のスナップショット・コピー・オペレーションによってより長い８時間要件に合体され、かつ満たされる。システムは、ステップ１０１０において、コピーをすべきときであることを決定し、かつ履歴ストア９１０における関連オブジェクトをチェックして、コピーがターゲット（ステップ９１２）およびソース（ステップ９１４）において既に作成されているかどうかを決定する。これらのチェックに合格すれば、システムは、ステップ９１６においてコピーを開始し、かつこのプロセスにおいて、スナップショットストアにおいてスナップショットが作成されかつ保存されることをトリガする。スナップショットは、次に、スナップショットストアからバックアップストアへコピーされる。システムは、次に、１０２２でスリープ状態になり、１０秒等の短期間後に再びウェイクアップする。その結果、バックアップストアに１つのコピーが、かつスナップショットストアに１つのコピーが生じ、偶数時毎のスナップショットは８時間持続し、かつ奇数時毎のスナップショットは、４時間持続する。バックアップストアおよびスナップショットストアにおける偶数時のスナップショットは、共に８時間の保持時間でタグ付けされ、かつその時点で自動的に、別のプロセスによりシステムから削除される。
【０１７５】
双方のポリシーが適用されるとしても、単一のコピーで双方のポリシーが満たされることから、２時に２つのスナップショットを取る、または２つのバックアップコピーを作成することに理由はない点に留意されたい。これらのスナップショットを組み合わせて合体させると、不必要なオペレーションが減ると同時に、複数の別個のポリシーによる自在性が保持される。さらに、異なる保持時間を有する同じターゲットに対して２つのポリシーを同時に活性化させることは、有用である場合がある。記述したこの例では、２時間毎のコピーより多い１時間毎のコピーが存在し、結果として、現時点により近い時点における復元の細分性が高まる。例えば、先のシステムにおいて、午後７時３０分に午後の早い時点からの損傷が発見されれば、先の４時間に関して１時間毎、即ち午後４時、５時、６時および７時でのバックアップが利用可能となる。さらに、午後２時からの、および午後１２時からの、２つのバックアップも保持されていたことになる。
コンテンツアドレス可能ストア
【０１７６】
図１１は、コンテンツアドレス可能プロバイダ５１０のコンテンツアドレス可能ストアを実装するモジュールを示すブロック図である。
【０１７７】
コンテンツアドレス可能ストア５１０の実装は、先に述べたスナップショットを介して実装されるパフォーマンス最適化プールの場合がそうであると思われるようなコピーインまたはコピーアウト速度ではなく、キャパシティが最適化されるストレージ・リソース・プールを提供し、よって、典型的には、オフラインのバックアップ、複製およびリモートバックアップのために使用される。コンテンツアドレス可能ストレージは、異なるオブジェクトの共通するサブセットを１回だけ格納する方法を提供し、これらの共通するサブセットのサイズは変わっていてもよいが、典型的には小さい４キビバイトであってもよい。コンテンツアドレス可能ストアのストレージオーバーヘッドは、スナップショットストアよりも低いが、通常、アクセス時間はより長い。概して、コンテンツアドレス可能ストア内のオブジェクトは、コンテンツをかなりの割合で共有し得るとしても、互いに対する内在的関係性を持たないが、本実装においては、記述される様々な最適化の実現要因である履歴関連性も保全される。これは、複数のスナップショットが元来鎖を形成し、各々が先行するスナップショットまたはベースラインコピーからのデルタのみを格納するスナップショットストアとは対照的である。具体的には、コンテンツアドレス可能ストアは、単一オブジェクト内で複数回反復されるデータサブセットのコピーを１つだけ格納するが、スナップショットベースのストアは、任意のオブジェクトの少なくとも１つのフルコピーを格納する。
【０１７８】
コンテンツアドレス可能ストア５１０は、プールマネージャと同じシステム上で、同じプロセスにおいて、またはＴＣＰ等のローカルトランスポートを介して通信する別個のプロセスにおいて、の何れかで実行されるソフトウェアモジュールである。この実施形態において、コンテンツアドレス可能ストアモジュールは、異なるコンポーネントからのソフトウェア不良による影響を最小限に抑えるために、別個のプロセスにおいて実行される。
【０１７９】
このモジュールの目的は、データ・ストレージ・オブジェクト４０３のストレージを、コンテンツを重複排除すること（即ち、単一または複数のデータオブジェクト内の反復されるコンテンツは、１回だけ格納されるように保証すること）により、高度に空間効率的な方式で可能にすることにある。
【０１８０】
コンテンツアドレス可能ソフトウェアモジュールは、プログラマティックＡＰＩを介してプールマネージャへサービスを提供する。これらのサービスには、下記が含まれる。
【０１８１】
マッピングをハンドルするオブジェクト１１０２：ＡＰＩを介してストアへデータを書き込むことにより、オブジェクトを生成することができ、一旦データが完全に書き込まれると、ＡＰＩは、オブジェクトのコンテンツにより決定されるオブジェクトハンドルを返す。逆に、データは、ハンドルを提供することにより、オブジェクト内のオフセットからバイトストリームとして読み取られてもよい。ハンドルがどのようにして構築されるかについては、図１２の説明に関連して詳述する。
【０１８２】
時間木管理１１０４は、格納されるデータオブジェクト間の親／子関係を追跡する。データオブジェクトがストア５１０へ書き込まれると、ＡＰＩにより、これが既にストア内に存在する親オブジェクトへ子としてリンクされることが可能になる。これは、コンテンツアドレス可能ストアへ、子オブジェクトが親の修正であることを示す。例えば、あるアプリケーションのデータがしばらくの間ストアに規則的に保存され、よって早期コピーが復元されて後続修正の新規始点として使用される場合にあり得るように、単一の親は、異なる修正を有する複数の子を有してもよい。時間木管理オペレーションおよびデータモデルについては、後により詳しく述べる。
【０１８３】
差エンジン１１０６は、ストア内の２つの任意オブジェクト間の差領域のサマリを生成することができる。ディファレンシングオペレーションは、比較されるべき２オブジェクトのハンドルを指定するＡＰＩを介して呼び出され、かつ差分サマリの形式は、連続する差セクションのオフセットおよびサイズを有するコールバックシーケンスである。差は、オブジェクトの２つのハッシュ表現を並行比較することによって計算される。
【０１８４】
ガーベージコレクタ１１０８は、ストアを分析して、如何なるオブジェクトハンドルによっても参照されていない保存データを発見し、かつこのデータにコミットされたストレージスペースを取り戻すサービスである。多くのデータが複数のオブジェクトハンドルによって参照されること、即ち、データオブジェクト間でデータが共有されることは、コンテンツアドレス可能ストアの本質であり、データの中には、単一のオブジェクトハンドルによって参照されるものがあるが、（オブジェクトハンドルがコンテンツアドレス可能システムから削除されている場合にあり得るように）オブジェクトハンドルによって参照されないデータは、新しいデータによって安全に上書きされることが可能である。
【０１８５】
オブジェクトレプリケータ１１１０は、２つの異なるコンテンツアドレス可能ストア間でデータオブジェクトを複製するためのサービスである。複数のコンテンツアドレス可能ストアは、オフラインバックアップまたはリモートバックアップ等の追加的なビジネス要件を満たすために使用されてもよい。
【０１８６】
これらのサービスは、図１１に示される機能モジュールを用いて実装される。データ・ハッシュ・モジュール１１１２は、データチャンクのための固定長キーを一定の限界サイズまで生成する。例えば、この実施形態において、ハッシュ生成器がそのキーを作るチャンクの最大サイズは、６４キビバイトである。固定長キーは、使用されるハッシュスキームを示すようにタグ付けされたハッシュ、または無損失アルゴリズム符号化の何れかである。この実施形態に使用されるハッシュスキームは、ＳＨＡ−１であり、これは、一様な分布と、衝突を検出して対処するためのファシリティをこのシステムに組み込む必要がない、ほとんどゼロに近いハッシュ衝突の確率とを有するセキュア暗号ハッシュを生成する。
【０１８７】
データ・ハンドル・キャッシュ１１１４は、データマッピングおよびハンドル−データマッピングのためのエフェメラルストレージを提供するメモリ内データベースを管理するソフトウェアモジュールである。
【０１８８】
永続的ハンドル管理インデックス１１０４は、ＣＡＨ−データマッピングの高信頼性永続的データベースである。この実施形態において、これは、ハッシュ生成器からのハッシュを、永続的データストア１１１８における、このハッシュのデータを含むページへマップするＢ木として実装される。メモリは、Ｂ木全体を一度に保持することができないことから、効率のために、この実施形態は、メモリ内ブルームフィルタも用いて、不在となることが知られているハッシュの高価なＢ木探索を回避する。
【０１８９】
永続的データ・ストレージ・モジュール１１１８は、データおよびハンドルを長期永続的ストレージへ格納し、データが格納される場所を示すトークンを返す。ハンドル／トークンペアは、続いて、データを検索するために使用される。データは、永続的ストレージへ書き込まれることから、この実施形態ではｚｌｉｂを用いて実装される無損失データ圧縮の層１１２０、およびこの実施形態ではイネーブルされない任意選択である可逆性暗号化の層１１２２を通過する。
【０１９０】
例えば、データオブジェクトをコンテンツアドレス可能ストアへコピーすることは、着信するオブジェクトは格納されかつハンドルはリクエスタへ返されるという理由で、オブジェクト／ハンドルマッパ・サービスにより提供されるオペレーションである。オブジェクト／ハンドルマッパは、着信するオブジェクトを読み取り、ハッシュがデータハッシュ生成器によって生成されることを要求し、データを永続的データストレージへ格納し、かつハンドルを永続的ハンドル管理インデックスへ格納する。データ・ハンドル・キャッシュは、ハンドルデータの将来の迅速なルックアップ用に更新され続ける。永続的データストレージへ格納されるデータは、圧縮されかつ（場合により）暗号化された後にディスクへ書き込まれる。典型的には、データオブジェクトにおけるコピーの要求は、オブジェクトの履歴レコードを作成するために時間的木管理サービスも呼び出し、よってこれも、永続的データストレージを介して存続される。
【０１９１】
別の例として、データオブジェクトを、そのハンドルを所与としてコンテンツアドレス可能ストアからコピーすることは、オブジェクト／ハンドルマッパ・サービスにより提供される別のオペレーションである。ハンドルは、対応するデータをロケーティングするためにデータ・ハンドル・キャッシュにおいて検索され、データがキャッシュ内に存在しなければ、永続的インデックスが使用され、データは、ディスク上で一旦ロケーティングされると、（ディスクデータを復号しかつ解凍する）永続的データ・ストレージ・モジュールを介して検索され、かつ次に、リクエスタへ返すために再構成される。
コンテンツアドレス可能ストアハンドル
【０１９２】
図１２は、コンテンツアドレス指定オブジェクトのハンドルがどのように生成されるかを示す。データオブジェクト・マネージャは、コンテンツアドレス可能ハンドルを用いて全てのコンテンツアドレス可能オブジェクトを参照する。このハンドルは、３つの部分で構成される。第１の部分１２０１は、ハンドルが即座にポイントする、基礎を成すデータオブジェクトのサイズである。第２の部分１２０２は、ハンドルがポイントするオブジェクトの深さである。第３の部分１２０３は、ハンドルがポイントするオブジェクトのハッシュである。フィールド１２０３は、場合により、ハッシュが基礎を成すデータの無損失符号化であることを示すタグを含む。タグは、データチャンクを十分に短いランレングス符号化（ＲＬＥ）として完全に表すことができればアルゴリズム符号化として使用されるデータのＲＬＥ形式等の、使用される符号化スキームを示す。基礎を成すデータオブジェクトが大きすぎて無損失符号化として表せなければ、ハッシュからポインタへのマッピング、またはデータの参照は、別に永続的ハンドル管理インデックス１１０４に格納される。
【０１９３】
コンテンツアドレス可能オブジェクトのデータは、複数のチャンク１２０４へ分けられる。各チャンクのサイズは、１つのコンテンツアドレス可能ハンドル１２０５によってアドレス指定可能でなければならない。データは、データ・ハッシュ・モジュール１１０２によってハッシュされ、かつチャンクのハッシュは、ハンドルを作成するために使用される。オブジェクトのデータが１つのチャンクに嵌まれば、生成されるハンドルは、オブジェクトの最終ハンドルである。嵌まらなければ、ハンドル自体が纏めて複数のチャンク１２０６にグループ化され、ハンドルグループ毎に１つのハッシュが生成される。１２０７において、ハンドルのこのグルーピングは、１２０８において生成されるハンドルが１つだけになるまで継続され、この唯一のハンドルがオブジェクトのハンドルになる。
【０１９４】
コンテンツハンドルからオブジェクトが再構成される場合（ストレージ・リソース・プールのコピーアウトオペレーション）、トップレベルのコンテンツハンドルが参照外しされて次のレベルのコンテンツハンドルのリストが取得される。次には、これらも、コンテンツハンドルのさらなるリストを取得するために、深さ０のハンドルが取得されるまで参照外しされる。これらは、ハンドル管理インデックスまたはキャッシュにおいてハンドルを検索すること、または（ランレングス符号化等のアルゴリズムハッシュの場合）フルコンテンツまで確定的に拡大することの何れかによって、データへ拡大される。
時間木管理
【０１９５】
図１３は、コンテンツアドレス可能ストア内に格納されるデータオブジェクトのために生成される時間木の関係性を示す。この特定のデータ構造体は、コンテンツアドレス可能ストアの内部でのみ利用される。時間木管理モジュールは、データ構造体１３０２を、各コンテンツアドレス指定データオブジェクトを親（リビジョンシーケンスにおける筆頭を示すためにヌルであってもよい）へ関連づける永続的ストア内に保全する。木の個々のノードは、単一のハッシュ値を含む。このハッシュ値は、ハッシュが深さ０のハッシュであれば、データチャンクを参照し、または、ハッシュが深さ１以上のハッシュであれば、他のハッシュのリストを参照する。ハッシュ値へマップされる参照は、永続的ハンドル管理インデックス１１０４内に含まれる。実施形態によっては、木の縁は重さまたは長さを有してもよく、これらは、近傍を発見するためのアルゴリズムにおいて使用されてもよい。
【０１９６】
これは、標準的な木データ構造であって、モジュールは、標準的な操作オペレーション、具体的には、親の下に葉を追加し、その結果、木に初期状態１３０２と追加後の状態１３０４との間のような変化が生じる１３１０Ａｄｄ、およびノードを除去し（かつその親子関係を再構成し）、その結果、木に追加後の状態１３０４と除去後の状態１３０６との間のような変化が生じる１３１２Ｒｅｍｏｖｅ、をサポートする。
【０１９７】
「Ａｄｄ」オペレーションは、オブジェクトが外部プールからＣＡＳへコピーインされる場合にいつも使用される。コピーインが、最適なデータバックアップ方法を介するものであれば、またはオブジェクトが異なるＣＡＳプールを起源とするものであれば、先行オブジェクトが指定されることが要求され、かつＡｄｄオペレーションが、この先行／後続関係を記録するために呼び出される。
【０１９８】
「Ｒｅｍｏｖｅ」オペレーションは、ポリシーマネージャがオブジェクトの保持期間が終了していることを決定すると、オブジェクトマネージャによって呼び出される。これにより、ＣＡＳ内に格納されるデータは、データを参照するオブジェクトを時間木内に持たなくなる場合があり、よって、後続のガーベージコレクション・パスは、そのデータのためのストレージスペースを再使用のために利用可能として解放することができる。
【０１９９】
１つの先行オブジェクトは、複数の後続のものまたは子ノードを有することが可能である点に留意されたい。例えば、これは、あるオブジェクトがまず時間Ｔ１において生成されかつ時間Ｔ２において修正され、修正が復元オペレーションを介してロールバックされ、かつ後続の修正が時間Ｔ３において行われる場合に生じてもよい。この例では、状態Ｔ１は、２つの子、即ち状態Ｔ２および状態Ｔ３、を有する。
【０２００】
リモートロケーションにおける災害リカバリの提供等の異なるビジネス目標を達成するためには、異なるＣＡＳプールが使用されてもよい。あるＣＡＳから別のＣＡＳへコピーする場合、コピーは、ターゲットＣＡＳ固有の重複排除ケイパビリティを利用してハッシュおよびオフセットとして送られてもよい。また、任意の新しいハッシュによってポイントされる基礎を成すデータも、必要に応じて送られる。
【０２０１】
時間木構造は、様々なサービス実装の一部として読み取られ、またはナビゲートされる。
・ガーベージコレクションは、後述するように、「マーク」段階のコストを減らすように木をナビゲートする。
・異なるＣＡＳプールへの複製は、時間木内に、同じく既に他のＣＡＳプールへ転送されていることが知られている一連の近傍のものを発見し、よって、小さい差セットのみが追加的に転送されるだけでよい。
・最適なデータ復元方法は、時間木を用いて、復元オペレーションのベースとして使用されることが可能な先行するものを発見する。ＣＡＳ時間木データ構造では、子は、例えばアーカイブポリシーにより命じられるような後続バージョンである。複数の子は、同じ親ノード上でサポートされ、この事例は、親ノードが変えられ、次に復元の基礎として使用されかつ続いて再び変更される場合に発生することがある。
ＣＡＳ差エンジン
【０２０２】
ＣＡＳ差エンジン１１０６は、図１１および図１２におけるようなハッシュ値またはハンドルにより識別される２つのオブジェクトを比較し、オブジェクトデータが相違することが知られているオブジェクト内にオフセットおよびエクステントのシーケンスを生成する。このシーケンスは、図１２のハッシュデータ構造において２つのオブジェクト木を並行してトラバースすることにより達成される。木のトラバースは、標準的な深さ優先または幅優先トラバーサルである。トラバーサルの間、現行深さにおけるハッシュが比較される。あるノードのハッシュが両側で同一である場合、木をさらに下降する必要はなく、よって、トラバーサルは、削られてもよい。あるノードのハッシュが同一でなければ、トラバーサルは、木の次の最低位へと下降を続ける。トラバーサルが、その相手方と同じでない深さ０のハッシュに達すれば、非同一データが発生する場合に比較されているデータオブジェクトへの絶対オフセットは、データ長と共に、出力シーケンスへ発せられる。あるオブジェクトのサイズが別のオブジェクトのサイズより小さければ、そのトラバーサルは、早期に完了し、かつ他方のオブジェクトのトラバーサルにおいて遭遇される全ての後続オフセットは、差分として発せられる。
ディファレンシングを介するガーベージコレクション
【０２０３】
図１１に関して述べたように、ガーベージコレクタは、ある特定のＣＡＳストアを分析して、ＣＡＳストアの木データ構造において如何なるオブジェクトハンドルによっても参照されていない保存データを発見し、かつこのデータにコミットされたストレージスペースを取り戻すサービスである。ガーベージコレクションは、標準的な「マークアンドスイープ」手法を用いる。「マーク」段階は、極めて高価であり得ることから、マーク段階に使用されるアルゴリズムは、同じデータを何回もマークすることを、これが何度も参照される場合でも最小限に抑えようとするが、スイープ段階の後、マークされていないデータはやがて新しいデータによって上書きされるためにストアからのデータ損失に繋がるという理由で、マーク段階は、参照されたデータがマークされずに残らないことを保証して完了しなければならない。
【０２０４】
参照されるデータのマーキングに使用されるアルゴリズムは、ＣＡＳ内のオブジェクトが、図１３に描かれているデータ構造を用いて時間的関係性によってグラフに配列される、という事実を用いる。これらのグラフにおける縁を共有するオブジェクトは、ほんの少しのデータが相違するだけであると思われ、また、オブジェクトが先行オブジェクトから生成される場合に出現する新しいデータチャンクも、他の任意の２オブジェクト間で再び現れることはほとんどない。したがって、ガーベージコレクションのマーク段階は、時間グラフの接続された各コンポーネントを処理する。
【０２０５】
図１４は、所定の実施形態における、時間的関係性を用いるガーベージコレクションの一例である。矢印１４０２で表される深さ優先探索は、時間的関係性を含むデータ構造で構成される。木トラバーサルは、１４０４を開始ノードとして始まる。ノード１４０４は、木の根であって、オブジェクトを参照しない。ノード１４０６は、オブジェクト１のハッシュ値およびオブジェクト２のハッシュ値を示すオブジェクトＨ１およびＨ２への参照を含む。ノード１４０６によって参照される全ての深さ０、深さ１およびより高位のデータオブジェクト、ここではＨ１およびＨ２、は、参照されたものとして列挙されかつマークされている。
【０２０６】
次に、ノード１４０８が処理される。これは、マークされているノード１４０６と１つの縁を共有していることから、１４０６により参照されるオブジェクトと１４０８により参照されるオブジェクトとの間の差分に差エンジンが適用され、マークされていないオブジェクト内に存在するがマークされたオブジェクト内には存在しない一連の深さ０、深さ１およびより高位のハッシュが取得される。本図において、ノード１４０８内に存在するがノード１４０６内には存在しないハッシュは、Ｈ３であり、よってＨ３は参照されたとしてマークされる。この手順は、全ての縁が使い果たされるまで続けられる。
【０２０７】
従来技術のアルゴリズム１４１８および本実施形態１４２０によりもたらされた結果の比較は、ノード１４０８が従来技術のアルゴリズムによって処理される場合、新しいハッシュＨ３と共に、先に参照されたハッシュＨ１およびＨ２が出力ストリームへ発せられることを示している。本実施形態１４２０は、先に参照されたハッシュを出力ストリームへ発せず、結果的に、新しいハッシュＨ３、Ｈ４、Ｈ５、Ｈ６、Ｈ７のみが出力ストリームへ発せられ、パフォーマンスが相応に改善される。この方法は、データが２回以上マーキングされないことを保証するものではない点に留意されたい。例えば、ノード１４１６において、ハッシュ値Ｈ４が単独で発生すれば、これは、単独で２度目のマーキングをされる。
オブジェクトをＣＡＳへコピーする
【０２０８】
別のプールからのオブジェクトのＣＡＳへのコピーは、図１２におけるようなオブジェクトハンドルにより参照されるデータ構造を生成するために、図１１に記述されているソフトウェアモジュールを用いる。このプロセスへの入力は、（ａ）深さ０のハンドルを作るために適切なサイズにされた、指定されたオフセットにおけるデータチャンクのシーケンス、および場合により、（ｂ）同じオブジェクトの先行バージョン、である。暗に、新しいオブジェクトは、入力データが提供されかつそれ自体が先行バージョンとは異なる場合を除いて、先行バージョンと同一になる。コピーインオペレーションのアルゴリズムは、図１５のフローチャートに示されている。
【０２０９】
先行バージョン（ｂ）が提供されれば、シーケンス（ａ）は、（ｂ）からの変化の疎集合であってもよい。コピーされるべきオブジェクトと先行オブジェクトとの相違が数ポイントでしかないことが知られている場合、これは、コピーインされる必要のあるデータの量を大幅に減らすことができ、よって、必要とされる計算およびｉ／ｏアクティビティを減らすことができる。これは、例えば、オブジェクトが、先に述べた最適なデータバックアップ方法によってコピーインされる場合がそうである。
【０２１０】
シーケンス（ａ）が、先行するものからさほど変化していないセクションを含むとしても、先行するもの（ｂ）の識別により、コピーイン手順が、データが実際に変化しているかどうかについてクイックチェックをすること、故に、ＣＡＳへ入力を提供する他の何らかのストレージプールにおける差エンジンで予期される細分性より細かいレベルの細分性でのデータ複製を回避することが可能になる。
【０２１１】
よって、暗に、新しいオブジェクトは、入力データが提供されかつそれ自体が先行バージョンとは異なる場合を除いて、先行バージョンと同一になる。コピーインオペレーションのアルゴリズムは、図１５のフローチャートに示されている。
【０２１２】
プロセスは、ステップ１５００において、時間ストア内の任意サイズのデータオブジェクトが提供された時点で開始され、１５０２へ進んで、そうしたものが提供されていれば先行オブジェクトにおけるハッシュ値により参照される全てのハッシュ（深さ０から最高位まで）を列挙する。これは、先行するものの中に既に含まれているデータを格納することを回避するためのクイックチェックとして使用される。
【０２１３】
ステップ１５０４において、先行するものが入力されれば、そのクローンへの参照を、コンテンツアドレス可能データストアの時間的データ構造内に生成する。このクローンは、新しいオブジェクトになるように更新される。したがって、新しいオブジェクトは、コピー側ソースプールからＣＡＳへコピーされる差分によって修正された先行するもののコピーとなる。
【０２１４】
ステップ１５０６、１５０８において、データムーバ５０２は、データをＣＡＳへ押し込む。データには、オブジェクト参照、およびデータのターゲットロケーションであるオフセットが添付される。データは、先行するものとの差分のみが新しいオブジェクトへ移動されればよいことから、僅かであってもよい。この時点で、着信データは、各々が１つの深さ０のハッシュによって表され得るに足る小さいサイズにされた深さ０のチャンクに分けられる。
【０２１５】
ステップ１５１０において、データ・ハッシュ・モジュールは、深さ０の各チャンクにハッシュを生成する。
【０２１６】
ステップ１５１２において、同じオフセットにおける先行ハッシュを読み取る。データのハッシュが同じオフセットにおける先行のハッシュと一致すれば、データが格納される必要はなく、かつ深さ１のオブジェクトおよびより高位のオブジェクトがこの深さ０のチャンクに関して更新される必要はない。この場合、次の深さ０のデータチャンクを受け入れるために戻る。これにより、高価な全体的ルックアップを行う必要なしに時間的重複排除が達成される。ソースシステムが、理想的には、ＣＡＳに先行して格納されているデータとの差分のみを送信するものであるとしても、ソースシステムが異なるレベルの細分性でディファレンシングを実行するものであれば、またはデータが変化したものとしてマークされているが、その先行して格納された値に戻されていれば、このチェックが必要である場合がある。ディファレンシングは、例えば、ソースシステムが３２キビバイトの境界上でデルタを生成するスナップショットプールであり、かつＣＡＳストアが４キビバイトのチャンク上でハッシュを生成すれば、異なるレベルの細分性で実行されてもよい。
【０２１７】
一致が見出されなければ、データは、ハッシュされて格納されてもよい。データの書き込みは、オフセットの提供された時点に始まり、新しいデータがなくなれば終了する。一旦データが格納されると、ステップ１５１６においてオフセットが同じ深さ１のオブジェクト内にまだ含まれていれば、１５１８において、深さ１、深さ２およびより高位である全てのオブジェクトが更新されてレベル毎に新しいハッシュが生成され、かつステップ１５１４において、深さ０、深さ１およびより高位である全てのオブジェクトがローカルキャッシュへ格納される。
【０２１８】
しかしながら、ステップ１５２０において、格納されるべきデータの量が深さ１のチャンクサイズを超え、かつオフセットが新しい深さ１のオブジェクト内に含まれるべきものであれば、現行の深さ１は、それが既にそこへ格納されるべく決定されていない限り、ストアへ落とされなければならない。まず、これをグローバルインデックス１１１６においてルックアップする。これが、グローバルインデックス１１１６において見出されれば、１５２２において、深さ１および関連する全ての深さ０のオブジェクトをローカルキャッシュから除去し、新しいチャンクに進む。
【０２１９】
ステップ１５２４では、グローバルインデックスを訪ねることを回避するクイックチェックとして、ローカルキャッシュにおける深さ０、深さ１およびより高位のオブジェクトの各々について、そのハッシュを１５０２で確立されたローカルストアにおいてルックアップする。一致するもの全てを廃棄する。
【０２２０】
ステップ１５２６では、ローカルキャッシュにおける各深さ０、深さ１およびより高位のオブジェクトについて、そのハッシュをグローバルインデックス１１１６においてルックアップする。一致するもの全てを廃棄する。これにより、データが全体的に重複排除されることが保証される。
【０２２１】
ステップ１５２８では、残りの全コンテンツをローカルキャッシュから永続的ストアへ格納し、次いで新しいチャンクの処理を続ける。
【０２２２】
オブジェクトのＣＡＳからの読み取りは、さらに単純なプロセスであって、ＣＡＳの多くの実装に亘って共通する。オブジェクトのハンドルは、グローバルインデックスを介して永続的データオブジェクトへマップされ、必要とされるオフセットが、この永続的データ内から読み取られる。事例によっては、オブジェクトハンドル木における幾つかの深さまで再帰的に処理することが必要である場合がある。
ＣＡＳオブジェクトのネットワーク複製
【０２２３】
図１１に関して述べたように、レプリケータ１１１０は、２つの異なるコンテンツアドレス可能ストア間でデータオブジェクトを複製するためのサービスである。複製プロセスは、１つのストアからの読み取り、および別のストアへのライトバックによって達成されることも可能であるが、このアーキテクチャにより、ローカル・エリア・ネットワークまたは広域ネットワーク等の限定された帯域幅接続上でのより効率的な複製が可能になる。
【０２２４】
各ＣＡＳストア上で動作する複製システムは、先に述べた差エンジンサービスを図１３に記述されているような時間的関係構造と共に使用し、かつさらに、ＣＡＳストアにより使用される時間的データ構造内に、毎オブジェクトベースで、オブジェクトがどのリモートストアへ複製されたかに関するレコードを格納する。これは、所定のデータストアにおけるオブジェクトの存在の決定的な認識を提供する。
【０２２５】
時間的データ構造を使用して、システムは、どのオブジェクトがどのデータストアに存在するかを決定することが可能である。この情報は、データムーバおよび差エンジンにより、ターゲット・データストアを最新式にすべくコピーオペレーションの間にネットワーク上で送信されるべき最小限のデータサブセットを決定するために活用される。例えば、データオブジェクトＯが時間Ｔ３においてボストン所在のサーバからシアトル所在のリモートサーバへコピーされていれば、保護カタログストア９０８は、時間Ｔ３においてボストンおよびシアトル双方に存在するこのオブジェクトＯを格納する。ボストンからシアトルへの後続コピーの間の時間Ｔ５では、ボストン所在のソースサーバ上でディファレンシングに使用されるべきものであるシアトルにおけるオブジェクトＯの先行状態を決定するために、時間的データ構造が調べられる。ボストンのサーバは、次に、Ｔ５とＴ３の差分を取得し、この差分をシアトルのサーバへ送る。
【０２２６】
よって、オブジェクトＡを複製するプロセスは、次の通りである。ローカルストアにおいて、既にターゲットストアへ複製されているとして記録されるオブジェクトＡ０、およびＡの近傍オブジェクトを識別する。このようなオブジェクトＡ０が存在しなければ、Ａをリモートストアへ送り、かつこれを送信済みとして局所的に記録する。ローカルオブジェクトをリモートストアへ送るために、本明細書において具現される典型的な方法は、オブジェクト内のデータチャンクの全てのハッシュおよびオフセットを送信すること、どのハッシュが遠隔的に存在しないデータを表すかについて、リモートストアに問い合わせること、必要とされるデータをリモートストアへ送ること（この実施形態において、データおよびハッシュの送信は、これらをＴＣＰデータストリームにカプセル化することにより実装される）、である。
【０２２７】
逆に、Ａ０が識別されれば、差エンジンを実行して、Ａに存在するがＡ０には存在しないデータチャンクが識別される。これは、リモートストアへ送信される必要があるデータのスーパーセットであるべきものである。Ａに存在するがＡ０には存在しないチャンクのハッシュおよびオフセットを送信する。どのハッシュが、遠隔的に存在しないデータを表すかについて、リモートストアに問い合わせ、必要とされるデータをリモートストアへ送信する。
サンプル配備アーキテクチャ
【０２２８】
図１６は、データ管理仮想化（ＤＭＶ）システムの一実施形態を構成するソフトウェアおよびハードウェアコンポーネントを示す。このシステムを構成するソフトウェアは、３つの分散コンポーネントとして実行される。
【０２２９】
ホストエージェントのソフトウェア１６０２ａ、１６０２ｂ、１６０２ｃは、先に述べた幾つかのアプリケーション指定モジュールを実装する。これらは、データが管理下にあるアプリケーションと同じサーバ１６１０ａ、１６１０ｂ、１６１０ｃ上で実行される。
【０２３０】
ＤＭＶサーバソフトウェア１６０４ａ、１６０４ｂは、ここで説明するようなシステムの残りの部分を実装する。これらは、同じく高可用性の仮想化されたストレージサービスを提供する一連のＬｉｎｕｘ（登録商標）サーバ１６１２、１６１４上で実行される。
【０２３１】
本システムは、デスクトップまたはラップトップコンピュータ１６２０上で実行される管理クライアントソフトウェア１６０６によって制御される。
【０２３２】
これらのソフトウェアコンポーネントは、ＩＰネットワーク１６２８上のネットワーク接続を介して互いに通信する。データ管理仮想化システムは、公衆インターネットバックボーン等のＩＰネットワーク上で、一次サイト１６２２およびデータ複製（ＤＲ）サイト１６２４を相手に互いに通信する。
【０２３３】
一次サイトおよびＤＲサイトにおけるＤＭＶシステムは、ファイバ・チャネル・ネットワーク１６２６を介して１つまたは複数のＳＡＮストレージシステム１６１６、１６１８にアクセスする。一次アプリケーションを実行するサーバは、ＤＭＶシステムにより仮想化されたストレージに、ファイバ・チャネル・ネットワーク上のファイバチャネルを介して、またはＩＰネットワーク上のｉＳＣＳＩを介してアクセスする。リモートＤＲサイトにおけるＤＭＶシステムは、Ｌｉｎｕｘ（登録商標）サーバ１６２８上でＤＭＶサーバソフトウェア１６０４ｃの並行インスタンスを実行する。Ｌｉｎｕｘ（登録商標）サーバ１６２８は、Ａｍａｚｏｎ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  ＥＣ２インスタンス、または他の類似するクラウド計算リソースである場合もある。
単一のプロセススペースにおけるＶＳＳリクエスタおよびＶＳＳプロバイダ
【０２３４】
ＶＳＳ（Ｖｏｌｕｍｅ  Ｓｈａｄｏｗ  Ｃｏｐｙ  Ｓｅｒｖｉｃｅ）は、２００３年以降、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのバージョン上に存在するフレームワークである。このフレームワークは、アプリケーション整合性のあるバックアップを生成するために、バックアッププロダクト、アプリケーションおよびストレージコンポーネント間の協調を促進する。しかしながら、ＶＳＳフレームワークは、各コンポーネントが特定のタスクを独自に実行することを見込んでいて、これにより、後に詳述するように、不必要な非効率およびオーバーヘッドがもたらされる可能性がある。
【０２３５】
図１７は、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）のオペレーティングシステム上のＶＳＳフレームワークを示す略図である。ＶＳＳフレームワークは、ボリューム・シャドウ・コピー・サービス１７０１と、ＶＳＳリクエスタ１７０２と、ＶＳＳライタ１７０３と、ＶＳＳプロバイダ１７０４とを含む。
【０２３６】
ボリューム・シャドウ・コピー・サービス１７０１は、ＶＳＳリクエスタ１７０２、ＶＳＳライタ１７０３およびＶＳＳプロバイダ１７０４等の様々なＶＳＳフレームワークコンポーネント間の通信を調和し、かつアプリケーション整合性のあるスナップショットの生成を有効化する。ボリューム・シャドウ・コピー・サービス１７０１は、例えば、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの一部であって、Ｍｉｃｒｏｓｏｆｔにより提供される。ボリューム・シャドウ・コピー・サービス１７０１は、Ｗｉｎｄｏｗｓ（登録商標）ベースシステム上でＶＳＳアプリケーションを実行するためのシステムインフラを提供する。ボリューム・シャドウ・コピー・サービス１７０１は、ユーザおよび開発者に対してかなりトランスペアレントである可能性がある。実施形態によっては、ボリューム・シャドウ・コピー・サービス１７０１は、シャドウコピー（例えば、シャドウコピーは、ボリューム上に保持される全てのデータをある明確に規定された瞬間に複製する、ボリュームのスナップショットである）の生成および使用におけるプロバイダ（例えば、ＶＳＳプロバイダ１７０４）、ライタ（例えば、ＶＳＳライタ１７０３）およびリクエスタ（例えば、ＶＳＳリクエスタ１７０２）のアクティビティの調和等の幾つかの異なるタスクを実行し、デフォルトのシステムプロバイダを装備し、かつ任意のプロバイダが作動するために必要な低レベルのドライバ機能を実装するように構成される。
【０２３７】
バックアップのベンダーは、ＶＳＳリクエスタ１７０２を開発する。ＶＳＳリクエスタは、バックアップオペレーションを開始し得るバックアッププログラムまたはエージェントである。典型的には、ＶＳＳリクエスタは、バックアップされる必要があるシステム上にインストールされ、かつ別個のプロセスとして実行される。ＶＳＳリクエスタは、ＶＳＳ  ＡＰＩ（例えば、ＩＶｓｓＢａｃｋｕｐＣｏｍｐｏｎｅｎｔｓインタフェース）を用いて、１つまたは複数のボリュームのシャドウコピーおよびシャドウコピー・セットを生成しかつ管理するボリューム・シャドウ・コピー・サービス１７０１のサービスを要求する、任意のアプリケーションであることが可能である。リクエスタの例示的な一例は、ＶＳＳアウェアなバックアップ／復元アプリケーションであり、これは、シャドウコピーされたデータをそのバックアップオペレーションの安全なソースとして用いる。
【０２３８】
Ｍｉｃｒｏｓｏｆｔおよび他のベンダーによって開発されたアプリケーション（例えば、ＳＱＬ、Ｏｒａｃｌｅ、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅアプリケーション）には、アプリケーションをフリーズしかつディスク上のアプリケーションストアを自己整合的かつリカバリ可能にする能力を有するプロダクトに固有のＶＳＳライタ１７０３が付いている。各ＶＳＳライタは、１つのアプリケーション専用に構築され、かつ典型的には、このアプリケーションと共にインストールされる。例えば、ＳＱＬサーバのＶＳＳライタは、Ｉ／ＯオペレーションをＳＱＬサーバのＶＳＳサービスと調和する。ＶＳＳライタは、ＶＳＳサービスにより、ＶＳＳプロバイダがアプリケーション・データ・ストアのアプリケーション整合性のあるスナップショットをキャプチャすることを可能にするように要求されると、アプリケーションＩ／Ｏオペレーションをフリーズしかつ解凍する。ＶＳＳバックアップオペレーションの間にライタが存在しなければ、シャドウコピーがまだ生成される可能性がある。
【０２３９】
ストレージ技術のベンダーは、ＶＳＳプロバイダ１７０４を開発し、ＶＳＳプロバイダ１７０４は、ＶＳＳリクエスタ１７０２によってアプリケーションがフリーズされる瞬間にアプリケーションの自己整合的な画像の状態をキャプチャすることができ、よって、このアプリケーションは、正常なオペレーションを再開することができる。ＶＳＳプロバイダ１７０４は、何らかの種類のスナップショットを、例えばシステム上のソフトウェア内部から、またはシステム外部のハードウェアおよび／またはソフトウェアを用いることの何れかで入手する。ＶＳＳプロバイダは、アプリケーションが実行されるシステム上にインストールされ、かつ典型的には、独立したプロセスとして実行される。例示的な一例として、プロバイダは、リクエスタからの要求に応答して、着信するシャドウコピーのアプリケーションを信号で伝えるためのイベントを生成し、次に、このコピーを生成しかつこれをそれ以上必要がなくなるまで保全する。シャドウコピーが存在している間、プロバイダは、効果的にはシャドウコピーされている任意のボリュームの２つの独立したコピー、即ち、一方は、実行中のディスクが正常に使用されかつ更新されているコピー、および他方は、バックアップ用にディスクが固定されかつ安定しているコピー、が存在する環境を生成することができる。デフォルトのプロバイダは、Ｗｉｎｄｏｗｓ（登録商標）のオペレーティングシステムの一部として供給されることが可能である。
【０２４０】
ＶＳＳフレームワークの従来的な使用では、リクエスタおよびプロバイダは、独立したプロセスであって、互いに直には通信しない。これらは、汎用であるように設計されていて、各々他のプロバイダおよびリクエスタと共動する。ＶＳＳリクエスタがＶＳＳサービスへ要求を行うと、ＶＳＳサービスは、ＶＳＳプロバイダから応答を受信するまでＶＳＳリクエスタのスレッドをブロックする。さらに、ＶＳＳフレームワークは、ＶＳＳライタに、ＶＳＳリクエスタに関してＶＳＳサービスにＶＳＳプロバイダを呼び出させた如何なるコンテキストも提供しない。
【０２４１】
ＶＳＳアプリケーションのプログラミングインタフェースは、リクエスタが様々なプロバイダの存在を知ってそのうちの１つを選択すること以外、ＶＳＳリクエスタおよびＶＳＳプロバイダが互いに通信しあう手段を含まない。ＶＳＳリクエスタおよびプロバイダの全てのアクションは、ＶＳＳサービスによって調和される。
【０２４２】
ここに記述する技術は、同じプログラムの一部である別々のスレッドとして実装されるＶＳＳリクエスタおよびＶＳＳプロバイダを提供する。したがって、例えば、ＶＳＳサービスが、スナップショットを生成するためにＡＰＩを呼び出したＶＳＳリクエスタのスレッドをブロックしても、ＶＳＳプロバイダは、依然として同じプログラムの一部として実行され、よって、プロセス内通信手段を用いてＶＳＳリクエスタと通信することができる。例えば、ＶＳＳプロバイダは、何が生成されるべきか（例えば、どんな種類のコピーか、どのプログラムのためか、他）、どの程度のストレージスペースを用いるか、ストレージスペースをどこから割り付けるか、および／またはＶＳＳプロバイダが別段では入手できない他の情報、を決定することができる。例によっては、ＶＳＳリクエスタとＶＳＳプロバイダとの間の通信に使用される機構は、プロセス内通信を提供するコールバックハンドラである。例えば、ＶＳＳプロバイダは、コールバックハンドラを用いてＶＳＳリクエスタと通信し、ＶＳＳリクエスタにスナップショット・コミット・イベント等の特有のイベントがいつ発生するかを通知する。
【０２４３】
また、ＶＳＳプロバイダは、ステルスプロバイダとして生成されることも可能であり、よってこれは、他のＶＳＳリクエスタのプロバイダとしては現れない。例えば、ＶＳＳリクエスタは、ＶＳＳフレームワークＡＰＩを用いてバックアップオペレーションを開始する時点でカスタムＶＳＳプロバイダをＶＳＳフレームワークに登録し、かつバックアップオペレーションが完了するとＶＳＳプロバイダを登録解除することができる。これにより、ＶＳＳプロバイダをバックアップオペレーションの間に限ってシステム上で利用可能にすることができる。
【０２４４】
リクエスタおよびプロバイダを互いに通信させることによって実現され得る利点が存在する。例えば、リクエスタは、プロバイダにバックアップジョブから、リクエスタが実行間近であるという設定情報を提供することができ、この情報は、プロバイダによって、スナップショットの生成におけるリソースプールまたは他のパラメータを選ぶために使用されてもよい。通信メッセージを必要とし得る機能の他の例には、複数のホストに亘るスナップショットの調和、まさに整合の瞬間における外部バックアップサーバへのシグナリング、または他の多くのユースケースが含まれる。
【０２４５】
本開示では、上述の利点を実現する、リクエスタとプロバイダとの通信手法を提示する。
【０２４６】
図１８Ａは、幾つかの実施形態による、ＶＳＳリクエスタとＶＳＳプロバイダとの組合せを示す。図１７に示されているように、ボリューム・シャドウ・コピー・サービス１７０１およびＶＳＳライタ１７０３が存在する。この実施形態において、ＶＳＳリクエスタ１８０２およびＶＳＳプロバイダ１８０４は、同じ１つのプロセススペース１８０５における別々のスレッドセットとして互いに連結されている。これは、リクエスタおよびプロバイダが、グローバルメモリ、リクエスタおよびプロバイダスレッド間で情報を同期しかつ交換するためのポインタパッシングまたはスレッドシグナリング等の幾つかのプロセス内通信チャネル１８０６のうちの１つまたはそれ以上を用いることを有効化する。
【０２４７】
カスタムＶＳＳプロバイダ１８０４は、ソフトウェアまたはハードウェア・スナップショット・プロバイダであることが可能である。これは、ＶＳＳフレームワークにより規定されるＩＶｓｓＳｏｆｔｗａｒｅＳｎａｐｓｈｏｔＰｒｏｖｉｄｅｒ、ＩＶｓｓＰｒｏｖｉｄｅｒＣｒｅａｔｅＳｎａｐｓｈｏｔＳｅｔ、他等のＣＯＭインタフェースを実装することができる。ＶＳＳサービス１７０１は、これらのインタフェースを用いてカスタムＶＳＳプロバイダを呼び出す。さらに、ＶＳＳプロバイダ１８０４は、コールバックハンドラをＶＳＳプロバイダ１８０４に登録することによって、ＶＳＳリクエスタ１８０２の存在を認識させられる。コールバックハンドラは、ＶＳＳリクエスタ１８０２によって登録され、かつＶＳＳリクエスタ１８０２とＶＳＳプロバイダ１８０４との間の通信チャネルとして作用する。ＶＳＳプロバイダは、所定のイベントが発生すると、コールバックハンドラを用いてＶＳＳリクエスタに通知する。
【０２４８】
ＶＳＳリクエスタ１８０２は、ＩＶｓｓＢａｃｋｕｐＣｏｍｐｏｎｅｎｔｓインタフェース等のＶＳＳフレームワークＡＰＩを用いてＶＳＳフレームワークの機能を呼び出す。ＶＳＳリクエスタ１８０２は、コールバックハンドラをカスタムＶＳＳプロバイダにこのプロバイダから通知を受信するように登録し、かつプロバイダから受信されるコールバック通知メッセージを処理する。
【０２４９】
この実施形態は、リクエスタまたはプロバイダをそれらの従来の役割で機能することから除外するものではない。これは、データ保護およびデータリカバリ問題に対してより効率的かつ効果的なソリューションを提供することができる追加機能を有効化する。
【０２５０】
図１８Ｂは、ある例示的なバックアップシーケンスにおけるＶＳＳリクエスタ１８０２とＶＳＳプロバイダ１８０４との間のプロセス内通信スキームを示す。この例示においては、単一のコネクタプロセス１８４４がＶＳＳプロバイダおよびＶＳＳリクエスタの双方をホストする。コネクタ１８４４は、バックアップのベンダーによりアプリケーションをバックアップするために開発されるバックアッププログラムである。これは、単一のプロセスとして実行され、ＶＳＳリクエスタおよびＶＳＳプロバイダにより消費される全てのリソースは、このプロセスによって所有される。
【０２５１】
コネクタは、ステップ１８１０において実行を開始すると、ステップ１８１２において、カスタムＶＳＳプロバイダ１８０４をＶＳＳフレームワークに登録する。コネクタは、一旦完全に作動しかつ実行状態になると、バックアップ要求の聞き取りを開始する。
【０２５２】
ステップ１８１４において、データ管理仮想化システムからアプリケーションのバックアップ要求が受信されると、コネクタは、ステップ１８１６において、ＶＳＳリクエスタ１８０２を用いてバックアップシーケンスを開始する。ステップ１８１６において、ＶＳＳリクエスタ１８０２は、アプリケーションが実行されていてバックアップに利用可能であり、かつバックアップされている各アプリケーションのライタが健全な状態にあるかどうかをチェックする。
【０２５３】
ステップ１８１８において、アプリケーションにより使用されるストレージがデータ管理仮想化システム（「ＤＭＶ」）からエクスポートされていれば、ＶＳＳリクエスタ１８０２は、１８２０においてバックアップシーケンス用のカスタムＶＳＳプロバイダ１８０４を選択し、ＶＳＳプロバイダ１８０４にアプリケーション固有情報を提供し、かつコールバックハンドラをＶＳＳプロバイダに登録する。例えば、ＶＳＳリクエスタ１８０２は、ＶＳＳ  ＡＰＩ（例えば、ＩＶｓｓＢａｃｋｕｐＣｏｍｐｏｎｅｎｔｓ：：ＡｄｄＴｏＳｎａｐｓｈｏｔＳｅｔ）を用いてＶＳＳプロバイダを選択することができる。カスタムＶＳＳプロバイダを用いる決定は、アプリケーションに使用されるストレージボリュームのＬＵＮ（論理ユニット番号）ｉｄをＤＭＶによりエクスポートされるボリュームのＬＵＮ  ｉｄと比較することによって行われる。
【０２５４】
バックアップされる必要がある各アプリケーションについて、ＶＳＳリクエスタ１８０２は、そのアプリケーションのデータストアによりＶＳＳスナップショットのために使用されるボリュームを選択する。スナップショットのボリュームを選択した後、ステップ１８２４において、ＶＳＳリクエスタ１８０２は、（例えば、ＩＶｓｓＢａｃｋｕｐＣｏｍｐｏｎｅｎｔｓインタフェースを用いて）スナップショットの生成を要求する。ＶＳＳサービスは、スナップショットが成功するか失敗するまで呼び出しスレッドをブロックすることから、スナップショットの生成要求は、別個のスレッドを用いて行われる。これにより、スナップショットの生成がまだ進行中である間に、ＶＳＳリクエスタ１８０２が先に登録されたコールバックハンドラを用いてＶＳＳプロバイダ１８０４からコールバックメッセージを受信し続けることが可能になる。スナップショット生成の一部として、ＶＳＳサービス１７０１は、ＶＳＳライタ１８０３に、バックアップされつつあるアプリケーションをフリーズするように要求する。アプリケーションがフリーズされると、ＶＳＳサービス１７０１は、ＶＳＳプロバイダ１８０４に、アプリケーションにより使用されるボリュームのスナップショットを生成するように要求する。ステップ１８２６において、ＶＳＳプロバイダは、スナップショットの生成要求に応答して、先に登録されたコールバックハンドラを用いて、ＶＳＳフレームワークにスナップショット生成の用意が整っていることをＶＳＳリクエスタ１８０２に通知し、かつ自らをサスペンドする。
【０２５５】
ステップ１８２６においてＶＳＳプロバイダから通知を受信すると、ステップ１８２８において、ＶＳＳリクエスタ１８０２は、ＤＭＶに、アプリケーション・データ・ストアにより使用されるボリュームのスナップショットを生成するように要求しかつ応答を待機する。次に、ＤＭＶは、ステップ１８３０において、要求されたボリュームのコピーオンライト・スナップショットを生成し、かつステップ１８３２において、要求のステータスでＶＳＳリクエスタ１８０２に応答する。スナップショットが首尾良く生成されると、ステップ１８３４において、ＶＳＳリクエスタ１８０２は、ＶＳＳプロバイダ１８０４に、アプリケーションが正常な処理を再開できるようにＶＳＳ処理を再開するように通知する。例えば、スナップショットの生成が首尾良く完了した後、またはスナップショットの生成が失敗すると、アプリケーションは、ＶＳＳサービスによってアンフリーズされる。
【０２５６】
ステップ１８２４からステップ１８３４までの処理全体は、所定の時間フレーム（例えば、１０秒）内に完了されることが必要とされ、完了しなければ、ＶＳＳライタ１８０３は、アプリケーションのフリーズ要求を拒絶する。同じプロセス内にＶＳＳリクエスタおよびＶＳＳプロバイダの双方を有することは、プロセス間通信に関連づけられる通信オーバーヘッドを減らすことができ、かつスナップショット処理の時間間隔内での完了を助ける。
【０２５７】
ＶＳＳリクエスタ１８０２は、ステップ１８３６においてバックアップを完了し、かつステップ１８３８において、ＤＭＶにバックアップ要求のステータスを通知する。
【０２５８】
コネクタは、ステップ１８４０においてＶＳＳプロバイダ１８０４を登録解除し、かつステップ１８４２において実行を停止する。
【０２５９】
例によっては、リクエスタおよびプロバイダは、同じプロセススペース内に存在しない。例えば、リクエスタおよびプロバイダは、それらの固有のプロセススペース内でマルチスレッドされることが可能であり、かつ共有メモリ、ソケットまたはさらにディスクベースファイル等のプロセス間通信チャネルを用いてサイドチャネルにより互いに通信することができる。
アウトオブバンド・データのためのＳｍａｒｔＣｏｐｙ保護
【０２６０】
本開示は、内部ドライブまたはネットワークドライブ上に存在するデータの保護をカバーする仮想データパイプライン（ＶＤＰ）技術への拡張について述べる。アウトオブバンド（ＯＯＢ）とは、ストレージがＶＤＰシステムによってホストへ提示されないという事実を指す。例えば、アウトオブバンド・ストレージは、ＶＤＰシステムによって物理的にアクセスされ得ない、デスクトップ／ラップトップのローカルドライブ（例えば、「Ｃ」ドライブ）等のストレージ、または専用ネットワークから提供されるネットワークストレージである可能性がある。ストレージは、ＶＤＰシステムによりＶＤＰシステムがストレージへ直にアクセスできるような方法で使用されるようには提供されない、何らかの他の経路を介してホストには見える。このようなアウトオブバンド（帯域外「out-of-band」）・ストレージは、例えば、ファイルシステム（例えば、Ｗｉｎｄｏｗｓ（登録商標）のファイルシステム、Ｌｉｎｕｘ（登録商標）のファイルシステム、他）に格納されるデータであることが可能である。
【０２６１】
本開示以前には、ＶＤＰシステムによって直にはアクセスされ得ない、ホストシステム内（例えば、ラップトップまたはデスクトップ内）の直付けドライブ、または外部ファイルサーバによりその固有のストレージと共に（例えば、企業ネットワーク等の専用ネットワークにおいて）供給されるネットワーク接続ストレージ等のアウトオブバンド・ドライブ上に存在するデータをキャプチャしかつ保護するために、バックアップされるべきホストシステムから位置決めされるＶＤＰ技術を用いるための手段は存在しなかった。
【０２６２】
本開示によって、ＶＤＰシステムの全ての利点によりデータを保護することが可能になる。画像は、インクリメンタルにキャプチャされ、しかもなお仮想フル画像として利用可能である。データは、時間的に編成され、時間順の依存関係をキャプチャすること、およびより小さいストレージスペース、より効果的な重複排除およびより効率的なデータ管理という利点を導出することがより可能にされる。また、仮想フル画像は、フルの上にインクリメンタルに次ぐインクリメンタルを層化する必要のないホストへの容易な提示も有効化し、復元または模造する時間が低減され、かつマウントキャパシティが有効化される。
【０２６３】
データは、保護されるべきホスト上で実行されるスマート・コピー・エージェントを用いて保護されることが可能である。スマート・コピー・エージェントは、ＶＤＰシステムからのストレージを提示されることが可能であり、かつ提示されたストレージを用いてホストにしか見えないデータをコピーする。最初のコピー後の後続コピーについては、スマート・コピー・エージェントは、最後のコピー以降に変化した新しいデータのみをコピーすることができる。例えば、スマート・コピー・エージェントは、データをコピーと比較して、変化しているデータのみを更新することができる。例えば、タイムスタンプを用いるのではなく、スマート・コピー・エージェントは、ファイル構造をウォークして、何らかの新しいファイルが存在するかどうか、（例えば、最後のコピー以降、ファイルが修正されていることを示して）ファイルのメタデータの何れかが変化しているかどうか、または最後のコピー以降、何れかのファイルが削除されたかどうか、を確認することができる。
【０２６４】
図１９Ａは、幾つかの実施形態による、アウトオブバンド保護を提供するシステム１９００を示す略図である。システム１９００は、スマートコピーエージェント１９０２を実行するホスト１９０１を含む。スマートコピーエージェント１９０２は、本明細書においてさらに詳述する、ホスト１９０１上のバックグラウンドにおいて実行されるプロセスである。システム１９００は、ホスト１９０１と通信状態にある一次データベースストレージ１９０３も含み、これは、ＶＤＰシステム１９０４によって直にアクセスされ得ない。保護されるべきデータは、直付けの、またはアウトオブバンドの、またはネットワーク接続のストレージ１９０３上に存在する。スマートコピーエージェント１９０２は、ＶＤＰシステム１９０４と通信状態にある。ＶＤＰシステム１９０４は、パフォーマンスプール１９０６と通信状態にあり、パフォーマンスプール１９０６は、ＶＤＰシステム１９０４へ直にアクセス可能である。また、システム１９００は、パフォーマンスプール１９０６がホスト１９０１、スマートコピーエージェント１９０２およびパフォーマンスプール１９０６と通信状態にあるようにパフォーマンスプール１９０６から割り付けられるバックアップ・ステージング・ボリューム１９０５（本明細書では、「ステージングディスク」とも称される）も含む。
【０２６５】
ホスト１９０１を参照すると、これは、例えば、スマートコピーエージェント１９０２によりサポートされるＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、ＡＩＸ、ＳｏｌａｒｉｓまたはＨＰ−ＵＸのオペレーティングシステムを実行するコンピュータまたは仮想マシンであることが可能である。ホスト１９０１は、ネットワーク接続を介して（例えば、かつ場合により、ファイバチャネルを介して）ＶＤＰ１９０４へ接続されることが可能である。
【０２６６】
スマートコピーエージェント１９０２を参照すると、これは、例えば、ホスト１９０１上で実行される特有のオペレーティングシステムのために実行可能なスマートコピープログラムであることが可能である。このプログラムは、特有のオペレーティングシステムのための標準的なパッケージインストール手順を用いて、ホスト上へインストールされることが可能である。例えば、Ｗｉｎｄｏｗｓ（登録商標）上で、ユーザは、スマートコピーエージェントを１つのサービスとして実行するためにインストールするセットアッププログラムを実行する。別の例として、Ｌｉｎｕｘ（登録商標）ホスト上で、ユーザは、スマートコピーエージェントをデーモンプロセスとしてインストールするＲＰＭパッケージをインストールする。実施形態によっては、スマートコピーエージェントは、バックグラウンドにおいて継続的に実行され、かつＴＣＰ／ＩＰを用いてＶＤＰシステムと通信する。
【０２６７】
一次ストレージ１９０３を参照すると、これは、例えば、インストールされたＳＡＴＡ、ＳＣＳＩまたはＳＡＳハードディスク等の、ホスト１９０１による使用が可能なディスクシステム、または、ＮｅｔＡｐｐまたはＥＭＣ  ＳＡＮデバイス等の、ファイバチャネルまたは他の高速ディスクインターコネクトによって接続されるＳＡＮ提供ディスクであることが可能である。保護されたホスト１９０１は、一次ストレージ１９０３を用いてファイルシステム上でファイルの読み取りおよび書き込みを行う。
【０２６８】
ＶＤＰシステム１９０４を参照すると、これは、例えば、本明細書に記述するＶＤＰシステムであることが可能である。
【０２６９】
バックアップ・ステージング・ボリューム１９０５を参照すると、これは、例えば、パフォーマンスプール１９０６において利用可能な空き領域から提供される仮想ディスクデバイスであることが可能である。
【０２７０】
パフォーマンスプール１９０６を参照すると、これは、例えば、ファイバチャネルを介してＶＤＰシステム１９０４へ接続される、ＮｅｔＡｐｐまたはＥＭＣ  ＳＡＮデバイス等のディスクシステムであることが可能である。
【０２７１】
図１９Ｂは、アウトオブバンド保護を提供するシステムのメッセージおよびデータの流れを記述している。１９０７において、ＶＤＰシステム１９０４は、（例えば、ＳＬＡによる）保護ポリシーを起動する。次に、ステップ１９０８において、ＶＤＰシステムは、エージェント１９０２へバックアップ要求を送る。ステップ１９０９において、スマートコピーエージェント１９０２は、バックアップ要求を受信する。次に、ステップ１９１０において、スマートコピーエージェント１９０２は、ステージングディスク要件要求をＶＤＰシステムへ送り返す。ＶＤＰシステム１９０４は、スマートコピーエージェント１９０２から応答を受信する。ＶＤＰシステム１９０４は、次に、保護されるホスト１９０２へステージングディスクを提示する。ステップ１９１３において、スマートコピーエージェント１９０２は、提示されたステージングディスクをマウントする。次に、ステップ１９１４において、スマートコピーエージェント１９０２は、コンテンツが一次ストレージ１９０３と一致するように、ステージングディスク１９０５上のファイルをコピーし、削除し、または更新する。ステップ１９１５において、スマートコピーエージェント１９０２は、バックアップの結果をＶＤＰシステム１９０４へ送る。ステップ１９１６において、ＶＤＰシステム１９０４は、バックアップの結果を受信し、かつ保護されたホスト１９０１からステージングディスクをアンマップする。バックアップが成功していれば、ＶＤＰシステム１９０４は、ステージングディスク１９０５のポイントインタイム・スナップショットを取る。ＶＤＰシステム１９０４は、次に、バックアップメタデータを分類する（カタログに入れる）。
【０２７２】
ステップ１９０７を参照すると、これは、保護ポリシーの起動である。これは、例えば、ユーザが手動で保護ポリシーを実行することにより開始されることが可能であり、またはこれは、保護ポリシーに関して規定されたスケジュールの一部として実行されている。この保護ポリシーは、保護されたホスト１９０１上の特定のデータピース、この場合は一次ストレージ１９０３、を保護するように、ユーザによって事前に生成されることが可能である。
【０２７３】
ステップ１９０８を参照すると、ＶＤＰシステム１９０４は、どのボリュームがバックアップされるべきかを記述するＸＭＬを含むストリング等の要求をスマートコピーエージェント１９０２へ送る。
【０２７４】
ステップ１９０９を参照すると、スマートコピーエージェント１９０２は、例えば、どのボリュームがバックアップされるべきかを記述するＸＭＬを含むストリングである要求を受信する。バックアップされるべきボリュームは、オペレーティングシステム固有の名前を用いて識別される。例えば、Ｗｉｎｄｏｗｓ（登録商標）では、ボリュームは、Ｃ：、Ｄ：、Ｅ：、他と称される可能性がある。Ｌｉｎｕｘ（登録商標）では、ボリュームは、／、／ｕｓｒ、／ｍｎｔ／ｖｏｌｕｍｅ１、他と称される可能性がある。例えば、ＸＭＬを用いて送信される場合、ＸＭＬは、ホスト側での認証用資格認証情報、他のバックアップ機能を制御するためにユーザが指定するオプション等の、ボリュームをバックアップするために必要とされる他の任意のデータも包含することができる。また、ＸＭＬは、ＶＤＰがジョブを追跡できるように、ジョブ識別子も含むことができる。このＸＭＬは、パースされ、かつ結果がステップ１９１０において使用される。
【０２７５】
ステップ１９１０を参照すると、スマートコピーエージェント１９０２は、このバックアップに必要とされるステージングディスクのサイズを計算する。例えば、要求が４０ギガバイトのサイズであるボリュームをバックアップすることであれば、ステージングディスクのサイズも、少なくとも４０ギガバイトでなければならないことが決定される。この要件は、要件を記述するＸＭＬを含むストリングとしてＶＤＰシステム１９０４へ送られる。
【０２７６】
ステップ１９１１を参照すると、ＶＤＰシステム１９０４は、ステージングディスクに必要なサイズを含む応答（例えば、ＸＭＬ応答ストリング）を受信する。ＶＤＰシステムは、その時点で実行中である、保護ポリシーの既存のステージングディスクを見つけ出す。既存のステージングディスクが、少なくとも必要とされるステージングディスクのサイズに等しいサイズであれば、この既存のステージングディスクをステージングディスクとして用いることができる。既存のステージングディスクが見出されない（例えば、これがこの保護ポリシーの最初のバックアップである、または先行するステージングディスクが期限切れになっている）、または既存のステージングディスクが必要なサイズより小さい場合は、パフォーマンスプール１９０６から新しいステージングディスクを割り付けることができる。バックアップ用にステージングディスクが割り付けられると、ディスクサイズの増大を余儀なくされない限り、この同じステージングディスクを同じ保護ポリシーの後続バックアップの全てに用いることができ、サイズの増大を余儀なくされる場合には、より大きいステージングディスクが生成されて将来のバックアップに使用される。ユーザが保護ポリシーの全てのバックアップを終了させると、ステージングディスクは、削除され、かつ同じ保護ポリシーの後続のバックアップのために、新しいステージングディスクが割り付けられなければならない。ステップ１９１７におけるポイントインタイム・スナップショットは、これらのスナップショットが生成された元のステージングディスクに依存するが、これらは、ステージングディスクとしては使用されず、ステージングディスクの変更は、ポイントインタイム・スナップショットに影響を与えず、またポイントインタイム・スナップショットの変更も、これらが依存するステージングディスクのコンテンツに影響を与えない。
【０２７７】
ステップ１９１２を参照すると、ＶＤＰシステム１９０４は、保護されたホスト１９０１へステージングディスクを提示する。これは、例えば、ｉＳＣＳＩを介して、または１９０１が物理コンピュータであればファイバチャネルを介して実行されることが可能である。例えば、ステージングディスクは、ディスクをｉＳＣＳＩ上で、またはファイバチャネル上で見えるようにするための標準技術を用いて提示されることが可能である。ＶＤＰシステムは、ターゲットであり、かつ保護されるホストは、ＳＣＳＩ用語法を用いるイニシエータである。実施形態によっては、１９０２が仮想マシンであれば、ディスクは、まずＶＭｗａｒｅ  ＥＳＸｉ等の仮想マシンハイパーバイザへ提示され、次に、仮想マシン１９０１へステージングディスクが追加される。実施形態によっては、ＶＤＰシステムは、スマートコピーエージェントへ、ステップ１９１３において使用されるステージングディスクのＬＵＮ識別子を含むＸＭＬストリングを送る。
【０２７８】
ステップ１９１３を参照すると、スマートコピーエージェント１９０２は、物理マシンのｉＳＣＳＩまたはファイバチャネル・ディスクを見出すために、そのストレージバスをスキャンする。１９０１が仮想マシンであれば、ディスクは、ハイパーバイザにより提示されるＳＣＳＩディスクとして現れ、ステージングディスクを見出すためにＳＣＳＩバスがスキャンされる。スマートコピーエージェントは、ステップ１９１２においてＶＤＰシステムが送った同じＬＵＮ識別子を有するディスクを見出すまで、バスのスキャンを続ける。ストレージバス上でステージングディスクが見出されていれば、これは、分割され、かつこのステージングディスクがまだフォーマットされていなければ、フォーマットされる。ディスクは、一次ストレージ１９０３と同じファイルシステムを用いてフォーマットされる。一次ストレージ１９０３のファイルシステムを決定することができない、またはこれがサポートされていなければ、ステージングディスクは、保護されるホスト１９０１が実行するオペレーティングシステムのタイプのための標準的なファイルシステムを用いてフォーマットされる。例えば、ＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ（登録商標）システムは、ＮＴＦＳを用いることができ、Ｌｉｎｕｘ（登録商標）は、ｅｘｔ３を用いることができる。ステージングディスクは、次に、保護されるホスト１９０１上のマウントポイントにおいてマウントされる。例えば、Ｌｉｎｕｘ（登録商標）システム上では、これは、／ａｃｔ／ｍｎｔに位置決めされるディレクトリの下にマウントされることが可能であり、カレントジョブの識別子および時間を基礎として特有のディレクトリを指名することができる。別の例として、Ｗｉｎｄｏｗｓ（登録商標）システム上では、これは、Ｃ：＼Ｗｉｎｄｏｗｓ＼ａｃｔに位置決めされるディレクトリの下にマウントされることが可能であり、カレントジョブの識別子および時間を基礎として特有のディレクトリを指名することができる。
【０２７９】
ステップ１９１４を参照すると、スマートコピーエージェント１９０２は、一次ストレージ１９０３からステージングボリューム１９０５へ任意のファイルまたはディレクトリを、そのファイルが一次ストレージに存在しかつステージングボリュームに存在していなければ、コピーする。一次ストレージには存在しないが、ステージングボリュームには存在するファイルまたはディレクトリは、何れも、ステージングボリュームから削除される。実施形態によっては、タイムスタンプ、ファイル属性またはセキュリティ記述子等の異なるコンテンツまたはメタデータを有するファイルまたはディレクトリは、何れも、一次ストレージに合わせてステージングボリューム上で更新される。このステップが完了すると、ステージングボリュームは、一次ストレージのレプリカとなる。相違があるとすれば、それは、唯一、ファイルシステム不適合性の結果、またはボリューム識別子等のディスク固有のファイルシステム・メタデータであり得る。ステージングボリュームは、コピーおよび削除の完了後にホストからアンマウントされる。
【０２８０】
ステップ１９１５を参照すると、バックアップの結果が、スマートコピーエージェント１９０２からＶＤＰシステム１９０４へ送られる。これは、バックアップが成功したかどうか等のバックアップの結果を記述するＸＭＬと、バックアップが成功していなければ、発生したエラーを記述するエラーコードとを含むストリングである。
【０２８１】
ステップ１９１６を参照すると、ＶＤＰシステム１９０４は、ＸＭＬを含むストリングであるバックアップ結果を受信する。これは、バックアップが成功したか否かを決定するためにパースされる。ステージングディスクは、次に、保護されるホスト１９０１からアンマップされる。
【０２８２】
ステップ１９１７を参照すると、このステップは、ステップ１９１６の結果がバックアップの成功を示す場合にのみ到達される。ステージングディスクのポイントインタイム・スナップショットが、ＶＤＰシステムのフラッシュコピー機能を用いて生成される。ステージングディスクのこのスナップショットは、ステージングディスク上のファイルシステムの仮想フルコピーであって、パフォーマンスプール１９０６内に格納される。これは、ＶＤＰシステム内のインバンド・バックアップと同じ特性を有する。これらのスナップショットは、完全に独立したディスクとしてマウントされることが可能であり、これらは、模倣され、復元され、長期格納用に複製され、または災害リカバリおよびビジネス継続用にＷＡＮを通じてトランスポートされることが可能である。
【０２８３】
ステップ１９１８を参照すると、新しいポイントインタイム・スナップショットがもしあれば、これが、ホストファイルシステムの最新のバックアップとしてカタログに入れられる。このステージングディスクは、保護される同じホスト１９０１上の同じファイルシステムを保護する必要があれば次の機会に再使用され、将来のバックアップにおいてスマートコピーエージェントによりコピーされなければならないデータの量が大幅に低減される。
データベースバックアップのスマートコピー
【０２８４】
本開示は、別段ではＶＤＰシステムへアクセスすることができないデータベースシステムの保護および複製をサポートするための仮想データパイプライン（ＶＤＰ）システムへの拡張について述べる。例えば、本拡張により、ＶＤＰシステムが、ＶＤＰシステムによって直に通信できないデータベース（例えば、データベースがシステムのローカルドライブに格納されている、またはＶＤＰシステムではアクセスできない専用ネットワークにより提供されるネットワークストレージに格納されている）を保護することが可能になる。
【０２８５】
本開示に記述される実施形態を用いれば、Ｏｒａｃｌｅ、ＳＱＬサーバおよびＳｙｂａｓｅ等のリレーショナル・データベース・システム（ＲＤＢＭＳ）は、仮想データパイプライン・システムのワークフローの全ての利点によって保護されかつ複製されることが可能である。データキャプチャは、効率的かつインクリメンタルに行われてもよく、かつバックアップは、仮想フルバックアップであってもよく、仮想フルバックアップは、迅速かつ効率的にマウントされ、模倣されかつ復元されることが可能である。
【０２８６】
本開示以前には、ホストシステム内の直付けドライブ上のリレーショナルデータベース内、または外部ファイルサーバによりその固有のストレージと共に供給されるネットワーク接続ストレージ内に存在するデータをキャプチャしかつ保護するために、バックアップされるべきホストシステムとは異なるホスト上へ位置決めされる仮想データパイプライン（ＶＤＰ）技術を用いるための手段は存在しなかった。ＶＤＰシステムがデータベースを管理するためにこのようなデータベースと直に通信する方法は存在せず、ホストには、何らかの他の経路を介してデータベースが見える。
【０２８７】
本開示によって、ＶＤＰシステムの全ての利点によってデータベースのデータを保護することが可能になる。バックアップ画像は、インクリメンタルにキャプチャされ、しかもなお仮想フル画像として利用可能である。データは時間的に編成され、時間順の依存関係をキャプチャすること、およびより小さいストレージスペース、より効果的な重複排除およびより効率的なデータ管理という利点を導出することがより容易になる。また、仮想フル画像により、フルコピーの上にインクリメンタルコピーに次いでインクリメンタルコピー（等々）を層化する必要なしにホストへ容易に提示することも可能になり、復元または模造する時間が低減され、かつ瞬間的マウントケイパビリティが有効化される。
【０２８８】
データは、保護されるべきホスト上で実行されるＲＤＢＭＳエージェントを用いて保護されることが可能である。ＲＤＢＭＳエージェントは、ＶＤＰシステムからのストレージを提示されることが可能であり、かつ提示されたストレージを用いてデータベースをコピーするが、これはホストにしか見えない。ＲＤＢＭＳエージェントは、データベース・コピー・ツールを用いるように構成されることが可能であり、よって、データベースシステムは、後続のインクリメンタルコピー後でもデータベースコピーをロードして用いることができる。
【０２８９】
図２０Ａは、幾つかの実施形態による、データベースを保護するためのコンフィギュレーション２０００を示す。コンフィギュレーション２０００は、ＲＤＢＭＳ対応エージェント２００２を実行するホスト２００１を含む。ＲＤＢＭＳエージェント２００２は、本明細書においてさらに詳述する、ホスト２００１上のバックグラウンドにおいて実行されるプロセスである。コンフィギュレーション２０００は、ホスト２００１上へマウントされる一次データベースストレージ２００３も含み、これは、ＶＤＰシステム２００４によって直にアクセスされ得ない。保護されるべきデータベースデータは、直付けの、またはアウトオブバンドの、またはネットワーク接続のストレージ２００３上に存在する。ＲＤＢＭＳエージェント２００２は、ＶＤＰシステム２００４と通信状態にある。ＶＤＰシステム２００４は、パフォーマンスプール２００６と通信状態にあり、パフォーマンスプール２００６は、ＶＤＰシステム２００４へ直にアクセス可能である。コンフィギュレーション２０００は、バックアップ中にホスト２００１上へマウントされかつパフォーマンスプール２００６から割り付けられ、かつＲＤＢＭＳエージェント２００２と通信状態にあるバックアップ・ステージング・ボリューム（（「volume」、量、号、巻））２００５も含み、ステージングボリュームは、パフォーマンスプール２００６から生成される。
【０２９０】
ホスト２００１は、バックアップ保護を必要とする実際的なデータベースである、実行中のＲＤＢＭＳを備えるサーバである。ホスト２００１上で実行されるＲＤＢＭＳは、ＶＤＰシステム２００４に対してアウトオブバンドであるとされる一次データベースストレージを用いる。例えば、Ｏｒａｃｌｅのデータベースは、パフォーマンスプール２００６以外のアレイから供給されるデータベースストレージを有するＬｉｎｕｘ（登録商標）サーバ上で実行される。このデータベースサーバは、データセンタ内に存在し、かつ様々なアプリケーション用の永続的データレポジトリとして機能する。
【０２９１】
ＲＤＢＭＳエージェント２００２は、ホスト２００１上で実行されるソフトウェアコンポーネントである。ＲＤＢＭＳエージェント２００２は、ホスト２００１上へ配備され、データベースのバックアップ中にＶＤＰシステム２００４、一次データベースストレージ２００３およびバックアップ・ステージング・ボリューム２００５と通信する。ＲＤＢＭＳエージェント２００２は、ＲＤＢＭＳと通信し、かつインクリメンタルな永久的方法論として利用可能な従来方法を利用する。
【０２９２】
一次データベースストレージ２００３は、ホスト２００１上で実行されるＲＤＢＭＳのデータストレージである。一次データベースストレージ２００３は、ホスト２００１上で実行されるＲＤＢＭＳによって消費されるローカル接続ディスクドライブ、またはネットワーク接続ストレージの何れかであることが可能である。
【０２９３】
ＶＤＰシステム２００４は、本明細書に記述する仮想化データ保護システムの一実施形態であることが可能である。
【０２９４】
バックアップ・ステージング・ボリューム２００５は、パフォーマンスプール２００６から提供されかつＶＤＰシステム２００４により管理されるバックアップ宛先である。バックアップ・ステージング・ボリューム２００５は、ホスト２００１へマウントされ、それによって、読み取りおよび書き込みオペレーションの実行が可能になる。ＲＤＢＭＳエージェント２００２は、ＲＤＢＭＳのバックアップアーティファクトをバックアップ・ステージング・ボリューム２００５上へ書き込む。
【０２９５】
パフォーマンスプール２００６は、ＶＤＰシステム２００４により保護オペレーションを実行するために使用されるストレージプールである。保護オペレーションは、バックアップ用にパフォーマンスプール２００６からのストレージが使用されることを要求し、例えば、パフォーマンスプール２００６からバックアップ・ステージング・ボリューム２００５が提供され、かつホスト２００１へマップされる。
【０２９６】
図２０Ｂは、ＶＤＰシステムが用いるためのデータベースを設定する例示的なプロセスを示す。ステップ２０５０において、ＶＤＰシステム２００４からＲＤＢＭＳエージェント２００２へ、バックアップ・ステージング・ボリューム２００５の要件に対するバックアップ要求が送られる。ステップ２０５０については、後に、図２０Ｂのステップ２００７−２０１２に関連してさらに詳しく説明する。ステップ２０５１において、ＶＤＰシステム２００４は、バックアップ・ステージング・ボリューム２００５の要件メッセージを処理し、かつバックアップ・ステージング・ボリューム２００５を準備する。ステップ２０５１については、後に、図２０Ｂのステップ２０１３−２０１５に関連してさらに詳しく説明する。ステップ２０５２において、ＶＤＰシステム２００４は、バックアップ・ステージング・ボリューム２００５をホスト２００１へマップし、ＲＤＢＭＳエージェント２００２は、バックアップＩ／Ｏを受信するようにバックアップ・ステージング・ボリューム２００５を用意させる。ステップ２０５２については、後に、図２０Ｂのステップ２０１６−２０１７に関連してさらに詳しく説明する。ステップ２０５３において、ＲＤＢＭＳエージェント２００２は、一次データベースストレージ２００３のバックアップを実行する。ステップ２０５３については、後に、図２０Ｂのステップ２０１８−２０２０に関連してさらに詳しく説明する。ステップ２０５４において、ＲＤＢＭＳエージェント２００２は、インクリメンタルな変化を最終バックアップでマージしてこれを最新のものにし、かつ必要なデータベースアーティファクトをバックアップ・ステージ・ボリューム２００５上へコピーする。ステップ２０５４については、後に、図２０Ｂのステップ２０２１−２０２４に関連してさらに詳しく説明する。ステップ２０５５において、ＶＤＰシステム２００４は、バックアップ・ステージング・ボリューム２００５のスナップショットを生成し、メタデータをカタログに入れる。ステップ２０５５については、後に、図２０Ｂのステップ２０２５−２０２７に関連してさらに詳しく説明する。
【０２９７】
図２０Ｃは、インクリメンタルな永久的バックアップ保護の例示的なメッセージおよびデータの流れを詳述している。図２０Ａ、図２０Ｂは、ＶＤＰシステム２００４とＲＤＢＭＳエージェント２００２との間の通信、およびＶＤＰシステム２００４およびＲＤＢＭＳエージェント２００２の実行ステップを詳述している。
【０２９８】
保護ポリシーは、ステップ２００７において、ＶＤＰシステム２００４のスケジューラによって起動される。保護ポリシーは、エンドユーザにより規定されかつＶＤＰシステム２００４により格納されるＳＬＡ（サービス・レベル・アグリーメント）の一部であって、保護されるべきホスト２００１上のＲＤＢＭＳへ適用される。ＳＬＡは、ＶＤＰシステム２００４のスケジューラによって規定されかつ評価されているスケジュールを有する。ポリシーは、規定された基準が満たされたことが決定されると、スケジュールによって起動される。
【０２９９】
ステップ２００８において、ＶＤＰシステム２００４は、保護されるホスト２００１上のＲＤＢＭＳエージェント２００２へ要求を送る。ステップ２００８の要求は、ＲＤＢＭＳエージェント２００２によってバックアップオペレーションを消費する命令より成る。
【０３００】
ステップ２００９において、ＶＤＰシステム２００４からバックアップ命令を受信した後、ＲＤＢＭＳエージェント２００２は、バックアップ命令を処理する。
【０３０１】
ステップ２０１０において、ＲＤＢＭＳエージェント２００２は、ＲＤＢＭＳと通信して、バックアップ・ステージング・ボリューム２００５のサイズとして使用されるべきＲＤＢＭＳの設定サイズを決定する。例によっては、エンドユーザは、計算されたサイズに優先してユーザ指定のサイズを用いる、というオプションを有する。バックアップ・ステージング・ボリューム２００５のサイズは、バックアップのためのスペースがなくなることなくインクリメンタルなバックアップを永久的に実行できるような方法で計算される。
【０３０２】
ステップ２０１１において、ＲＤＢＭＳエージェント２００２は、バックアップ・ステージング・ボリューム２００５のサイズ要件および一意の署名をＶＤＰシステム２００４へ送る。一意の署名は、パフォーマンス・ストレージ・プール２００６におけるバックアップ・ステージング・ボリュームを一意に識別するために使用されることが可能なストリングである。例えば、Ｏｒａｃｌｅのデータベースの場合、そのＳＩＤ（ＯｒａｃｌｅのシステムＩＤ）は、バックアップ・ステージング・ボリューム２００５の一意の署名として使用されることが可能である。
【０３０３】
ステップ２０１２において、ＶＤＰシステム２００４は、バックアップ・ステージング・ボリューム２００５のサイズ要件および一意の署名をＲＤＢＭＳエージェント２００２から受信する。
【０３０４】
ステップ２０１３において、ＶＤＰシステム２００４は、パフォーマンスプール２００６内の既存のステージングディスクをチェックして、一意の署名および必要なサイズを有するディスクが既に存在しているかどうかを決定する。本方法は、パフォーマンスプール２００６内にステージングディスクが見出されなければステップ２０１４へ移動し、または、ステージングディスクが見出されればステップ２０１５へ進む。
【０３０５】
ステップ２０１４において、ＶＤＰシステム２００４は、パフォーマンスプール２００６から、必要なサイズおよび署名を有するバックアップ・ステージング・ディスクを生成する。
【０３０６】
ステップ２０１５において、ＶＤＰシステム２００４は、パフォーマンスプール２００６から、ステップ２０１３において見出されたバックアップ・ステージング・ディスクを検索する。
【０３０７】
ステップ２０１６において、ＶＤＰシステム２００４は、ステップ２０１４において生成された、またはステップ２０１５においてバックアップ・ステージング・ボリューム２００５として検索された何れかのステージングディスクを、保護されるべきホスト２００１へ提示する。提示により、ステージングディスクは、保護されるべきホスト２００１へマップされ、一意のディスク署名が保護されるべきホスト２００１へ送られる。
【０３０８】
ステップ２０１７において、ＲＤＢＭＳエージェントは、バスをスキャンして提示されたバックアップ・ステージング・ボリューム２００５を見出し、これらが初期化されていないボリュームであれば、データを受信するためにこれらをフォーマットしてファイルシステムを生成する。ファイルシステムとしては、本来ホストのオペレーティングシステム上でサポートされ、かつデータベースソフトウェアと互換性があれば、如何なるタイプも受け入れられる。本好ましい実施形態では、ＮＴＦＳファイルシステムがＷｉｎｄｏｗｓ（登録商標）のシステムに使用され、かつｅｘｔ３ファイルシステムがＬｉｎｕｘ（登録商標）のシステムに使用される。
【０３０９】
ステップ２０１８において、ＲＤＢＭＳエージェント２００２は、まず、バックアップ・ステージング・ボリューム２００５を調べることにより、ＲＤＢＭＳのバックアップにフルインジェストが必要とされるかどうかを決定する。先行するバックアップアーティファクトが見出され、かつフルインジェストは不要であることが決定されれば、ＲＤＢＭＳエージェント２００２は、ステップ２０２０へ移動する。そうでなければ、ＲＤＢＭＳエージェント２００２は、フルインジェストのためにステップ２０１８へ移動する。
【０３１０】
ステップ２０１９において、ＲＤＢＭＳエージェント２００２は、保護されるべきデータベースの論理コンテンツをバックアップ・ステージング・ボリューム２００５上へコピーする。このコピーの目的は、データベースデータの画像を、それが類似のホストマシン上で起動されることが可能なフォーマットで生成することにある。データベースのキャプチャ画像のコンテンツは、ある特定の時点におけるオリジナルデータベースの正確なコピーである。
【０３１１】
画像コピーを生成するための方法論は、データベースアプリケーション毎に変わってもよい。当業者である者にとって、データベースのベンダーの従来方法を用いて特定のデータベースシステムの画像をどのように生成するかは、明白であろう。例えば、ベンダーは、データベースを、それがオペレーショナルデータベースとしてロードされ得るようにしてコピーできるようにする、データベースシステムのバックアップツールを提供する場合が多い。例えば、Ｏｒａｃｌｅのデータベースの場合、画像を生成する好ましい方法は、ＯｒａｃｌｅのＲＭＡＮコマンド「インクリメンタルレベル０をタグ「ｘｙｚ」を付したコピーデータベースとしてバックアップする」を用いることである。その他、データベース用に設計されていない従来のバックアップ方法論を用いれば、データベース構造が保存されない場合があり、よって、従来のバックアップ方法論を用いてバックアップされるデータベースは、オペレーショナルデータベースにならない場合がある（例えば、バックアップされたデータベースは、データベースユーティリティによってロードされ得ず、かつ使用され得ない）。
【０３１２】
ステップ２０２０において、ＲＤＢＭＳエージェント２００２は、一次データベースストレージ２００３のインクリメンタルなバックアップを実行し、バックアップ・ステージング・ボリューム２００５上へバックアップアーティファクトを書き込む。
【０３１３】
ステップ２０２１において、ＲＤＢＭＳエージェント２００２は、バックアップ・ステージング・ボリューム２００５上で変化をデータファイルの画像コピーとマージし、これらの画像コピーを最新のものにする。
【０３１４】
ステージングディスク上での画像生成が完了すると、ステップ２０２２において、ＲＤＢＭＳエージェントは、バックアップ画像を自己整合的にするために、必要に応じて追加的なアーティファクトをステージングディスクへコピーしてもよい。当業者は、バックアップ制御ファイル、アーカイブ・ログ・ファイル、データベース構成ファイルおよびＶＳＳライタのメタデータドキュメントを、バックアップ・ステージング・ボリューム２００５へコピーされてもよいアーティファクトとして認識する場合がある。
【０３１５】
ステップ２０２３において、ＲＤＢＭＳエージェント２００２は、バックアップデータの完全性を保つために、画像コピーおよび他のバックアップアーティファクトが上書きされる、または損傷されることを防止すべくバックアップ・ステージング・ボリューム２００５をアンマウントする。
【０３１６】
ステップ２０２４において、ＲＤＢＭＳエージェント２００２は、バックアップのメタデータを含むバックアップ結果メッセージをＶＤＰシステム２００４へ送ってバックアップオペレーションを終了させる。これで、ＲＤＢＭＳエージェント２００２の関与は完了する。
【０３１７】
ステップ２０２５において、ＶＤＰシステム２００４は、バックアップ・ステージング・ボリューム２００５を保護されるべきホスト２００１からアンマップする。エンドユーザは、デフォルト挙動に優先してバックアップ・ステージング・ボリューム２００５のホスト２００１へのマッピングを維持する、という選択肢を有する。
【０３１８】
ステップ２０２６において、ＶＤＰシステム２００４は、バックアップ・ステージング・ボリューム２００５のポイントインタイム・スナップショットを生成する。このステップは、バックアップ・ステージング・ボリューム２００５のポイントインタイム・フラッシュコピーを生成するためのものである。フラッシュコピーは、スナップショットが取られた時点の状態を有するデータコンテンツを用いる複数の用途を目的とすることが可能である。例えば、バックアップ・ステージング・ボリューム２００５おフラッシュコピー画像は、試験用に品質保証部門におけるホストへマウントされることが可能である。
【０３１９】
ステップ２０２７において、バックアップ・ステージング・ボリューム２００５のスナップショットは、ＲＤＢＭＳアプリケーションの最新バックアップとしてカタログに入れられる。
【０３２０】
次回、保護ポリシーが予定通りに同じ保護下のデータベースへ起動される場合は、バックアップ・ステージング・ボリューム２００５を表す同じ画像モードディスクが再使用されてもよく、潜在的に必要とされ得るデータ移動量が低減される。この状況では、ステップ２０１５において行われるように、ＶＤＰシステム２００４は、同じバックアップ・ステージング・ボリューム２００５をホスト２００１へ提示する。ＲＤＢＭＳエージェント２００２は、ステップ２０１７において、これらのボリュームをスキャンしてファイルシステムをマウントし、先に生成された画像がホストに見えるようにする。ＲＤＢＭＳエージェント２００２は、次に、ステップ２０２０およびステップ２０２１において、ステージングディスク上の画像を更新し、より最新の時点のものにする。この場合もやはり、詳細な方法論は、データベースのベンダーの従来方法に従って変わってもよい。一例として、Ｏｒａｃｌｅのデータベースの場合、この手順は、ＲＭＡＮコマンド「タグ「ｘｙｚ」のデータベースを有するコピーを回復するためにインクリメンタルレベル１をバックアップする」を実行し、続いてコマンド「タグ「ｘｙｚ」を有するデータベースのコピーを回復する」を実行する。ステップ２０２２では、ステップ２０２３におけるステージングボリュームのアンマウントに先行してステージングボリュームへの自己整合のために再度アーティファクトがコピーされ、ＶＤＰシステム２００４へメッセージが送られる。ＶＤＰシステム２００４は、ホスト２００１からステージングディスクをアンマップし、かつステップ２０２６において、ステージングボリュームの最新時点のスナップショットを生成する。このスナップショットセットは、ステップ２０２７において、データベースアプリケーションの最新バックアップとしてカタログに入れられる。
【０３２１】
ステージングディスクのスナップショットは、保護されているデータベースの仮想フルバックアップであって、ＶＤＰシステム内のインバンド・バックアップにおける全ての特性を有する。これらのバックアップ画像は、マウントされかつ独立したフルインスタンスとして開始されることが可能であり、これらは、模造または復元され、長期ストレージ用に重複排除され、または災害リカバリおよびビジネス継続用にＷＡＮを通じてトランスポートされることが可能である。
【０３２２】
ＲＤＢＭＳデバイスからのコピーが実行される場合、最初のコピーは、ホスト２００１上で実行される。コピーオペレーションは、ＲＤＢＭＳエージェント２００２によって実行される。コピーは、ＶＤＰシステム２００４により提示される一連のボリューム２００５に対して行われる。
ユーザインタフェースにおけるクイックリンクサービス
【０３２３】
本開示は、データ管理仮想化スペースにおけるプロダクトのためのユーザインタフェースに関する。より具体的には、これは、本明細書に記述しているようなデータ管理プロバイダからのストレージ管理スタック上で実行されるデータ管理、データ保護、災害リカバリおよびビジネス継続サービスに亘るクイックリンクのためのシステムおよび方法について記述する。クイックリンクは、サービスオブジェクトにより規定される幾つかの異なるサービス間で共有サービスキャッシュを用いてデータおよび情報を共有することによりサービス間をまたぐアクションのために、規定されることが可能である。クイックリンクサービスは、システム実装のサブシステム（例えば、データ管理、データ保護、災害リカバリおよびビジネス継続サービス）のためのコンテキスト情報を基礎としてワークフロー内のステップを自動的に実行するために使用されることが可能であるが、コンテキスト情報がなければ、これらのステップは、（例えば、システムユーザにより）手動で実行されなければならなくなる。例えば、ユーザの役割および権利は、元来ビュー内に表現され、サービス内で利用可能な機能は、適宜スコープされる。クイックリンクは、コンテキストアウェアネスおよびユーザ開始ジョブ識別の問題を解決することができ、同時にエンドツーエンドのワークフローが単純化される。データ管理仮想化ディスプレイの基礎を成すサブシステムへのアクセスにより、データ管理仮想化ディスプレイが、基礎を成すサブシステムから収集されることが可能なデータおよび他の情報と結合される特定のデータ管理仮想化実装のペルソナを使用することが可能になり、それにより、ユーザによって手動で制御されかつ操作されなければならなかったジョブステップを自動的に実行する。
データ管理プロバイダのデスクトップ
【０３２４】
図２１は、幾つかの実施形態によるデータ管理プロバイダのデスクトップを描いたものである。データ管理プロバイダのデスクトップは、データ管理仮想化エンジン３０６のためのシステムおよび方法を実装するユーザインタフェースである。データ管理プロバイダのデスクトップにより、ユーザが、管理データ、アプリケーションおよびその関連ストレージをデータ管理仮想化エンジン３０６から見えるものとして管理し、監視し、設定しかつレポートすることが可能になる。データ管理プロバイダのデスクトップ内では、主要なユースケースの各々が、システムを用いる実行においてユーザのペルソナが関心を持ち得るアクショングループに分類される。ペルソナベースの各論理グルーピングは、１つの「サービス」を構成する。
【０３２５】
実施形態によっては、サポートされるサービスはダッシュボードを含むことができる。ダッシュボードは、システムコンポーネントの現在およびこれまでのデータおよびパフォーマンスの集合ビューを含むことができるが、これに限定されない。また、これは、データ管理仮想化エンジンを構成する主要コンポーネントの時点状態、即時的なユーザ介入を必要とする任意の重大イベントも含むことができる。
【０３２６】
実施形態によっては、サポートされるサービスはドメインマネージャを含むことができる。ドメインマネージャは、組織内でコンフィギュレーション管理、ホスト管理およびセキュリティ管理を担当するユーザによって従来実行されていた機能のグループを含むことができる。
【０３２７】
実施形態によっては、サポートされるサービスはサービス・レベル・アグリーメント（ＳＬＡ）アーキテクトを含むことができる。これにより、ユーザが、アプリケーションのビジネス要件をそのデータライフサイクルに関して規定するＳＬＡを生成しかつ管理することが可能になる。本明細書において詳述されるように、ＳＬＡは、アプリケーションデータのコピーの生成、保持および削除に関する詳細なビジネス要件をキャプチャする詳細な仕様書である。
【０３２８】
実施形態によっては、サポートされるサービスはアプリケーションマネージャを含むことができるが、これに関しては、図２３を参照してさらに詳述する。
【０３２９】
実施形態によっては、サポートされるサービスはレポートマネージャを含むことができる。レポートマネージャは、データ集積および基礎を成すプラットフォームサブシステムとの結合性を基礎として、基本的なレポーティングおよびビジネスアナリティクスを提供する。
【０３３０】
実施形態によっては、サポートされるサービスはシステムモニタを含むことができるが、これに関しては、図２４に関連してさらに詳述する。
【０３３１】
データ管理プロバイダのデスクトップ２１００は、（例えば、Ｗｉｎｄｏｗｓ（登録商標）またはＭａｃのＯＳを実行する）クライアントＰＣ上で実行され、かつＩＰネットワーク２１０１上で（例えば、図３を参照して記述される）データ管理仮想化エンジン３０６と通信する。実施形態によっては、通信は、安全なＨＴＴＰＳプロトコルを用いる。実施形態によっては、ＡＰＩは、ＲＥＳＴベースである。データ管理仮想化エンジンは、ＩＰまたはファイバチャネル（ＦＣ）ネットワーク２１０４の何れかを介してホスト２１０３およびストレージリソース２１０２へ接続される。ホスト２１０３は、例えば、関心のあるプログラム、アプリケーションおよびファイルシステムが存在する物理または仮想マシンであることが可能である。ストレージリソース２１０２は、実データが格納されるロケーションであることが可能である。
【０３３２】
図２２は、幾つかの実施形態による、クイックリンクを有するデータ管理プロバイダのデスクトップＵＩ内のサービス・マネージャ・インタフェースを示す略図である。サービスマネージャは、デスクトップＵＩ内で実行される。サービスグループ２２０１は、ウィンドウマネージャ２２００内に存在する。これらのサービス、即ちダッシュボード２２０２、ドメインマネージャ２２０３、ＳＬＡアーキテクト２２０４、アプリケーションマネージャ２２０５およびシステムモニタ２２０６は、各々、クイックリンク２２０８を介して互いに接続される。各サービスは、共有キャッシュ２２０７上に存在し、ＵＩコントローラ２２０９によって管理され、かつモデル・ビュー・コントローラのアーキテクチャに準じる。データモデル２２１０は、問題のサービスのオブジェクトを保持する。クイックリンクは、これらのサービスへのエントリポイントを提供することに加えて、サービス間でのデータの共有も提供する。
【０３３３】
ウィンドウマネージャ２２００を参照すると、ウィンドウマネージャは、内部にビューおよびサービスが構築されかつ視覚化されるシェルであることが可能である。ウィンドウマネージャは、基礎を成すＯＳを底に抽象化し、かつウィンドウフレームワークと共働するためのファシリティ（例えば、リサイジング、スタイリングおよびレイアウト）を提供する。
【０３３４】
クイックリンク２２０８を参照すると、クイックリンク２２０８は、そのユーザケースを介してユーザをシームレスに案内するために複数のサービス２２０１を互いに結びつける。例えば、クイックリンク機構は、バックアップデータ管理に関連する、マウント、模造、復元、アンマウント、アンマウントおよび削除、終了、フェイルオーバ、テストフェイルオーバ、シンクバックおよび／またはこれらに類似するものを含む、但しこれらに限定されないユーザアクションを開始する様々なジョブに使用されることが可能である。クイックリンク２２０８は、サービス２２０１間でコンテキストを交換する視覚的かつ直観的手法を提供し、一方で、ユーザにその既存のサブシステムに関するリアルタイムステータスおよびフィードバックを提供する。
【０３３５】
クイックリンクは、複数のサービスを互いに通信させ、そのコンテキストを更新させ、かつ最終的に、カスタマのニーズに関係しているユースケースを解決することができるプロセスである。クイックリンクは、サービスオブジェクトのファシリティおよびケイパビリティを用いて実装され、サービスの任意の組合せによって呼び出されかつ管理されることが可能である。基礎を成すプラットフォーム上のＡＰＩは、コンテキストを交換するプロセスで重要な役割を果たし、クイックリンクのユースケースを基礎としてルックアップおよび複雑なクワイアのためのファシリティを提供する。
【０３３６】
共有サービスキャッシュ２２０７を参照すると、これは、データを名前／値ペアで保持するデータ構造であることが可能である。これらのデータセットは、公開メソッドを介して全てのサービスにアクセス可能である。例えばハッシュマップ等の共有サービスキャッシュを実装する方法は、複数存在する。
【０３３７】
ＵＩコントローラ２２０９を参照すると、ＵＩコントローラ２２０９は、モデル・ビュー・コントローラ（ＭＶＣ）ベースのアーキテクチャと同様に実装されることが可能であって、ＵＩコントローラ２２０９にはビジネス知識が存在し、ウィンドウマネージャ２２００におけるＵＩビューをデータモデル２２１０から分離する。ＵＩコントローラ２２０９は、ＵＩビューおよび／またはデータモデルの双方の変化に聴き入るように構成されることが可能である。
【０３３８】
データモデル２２１０を参照すると、これは、大部分のサービスセントリックなデータが格納される場所である。各サービスは、その固有のデータモデルを伴って構成されることが可能であり、コントローラは、ビューからイベントを得てエンティティへ変換し、モデルを更新する。
【０３３９】
図２２Ａは、サービスの実装およびアーキテクチャ、およびその連係を示す。サービスオブジェクト２２２２は、ウィンドウマネージャ２２２０および幾つかのターゲットビュー２２２４を実装する。また、これは、共有サービスキャッシュ２２０７へのポインタも有する。ＵＩコントローラ２２０９は、サービスオブジェクト内の大部分の機能を働かせる。
【０３４０】
本明細書に開示するシステムおよび方法によれば、データ管理仮想化システムの様々なビューは、論理的に、一連のサービス２２０１に纏めてグルーピングされる。このアーキテクチャは、全てのサービスがサービス２２０１間でデータにアクセスし、トランスポートしかつ保存できるようにする共有サービスキャッシュ２２０７を提供する。また、このアーキテクチャは、ある特定のサービスのコンポーネント（例えば、そのサービスの特定のウィンドウマネージャ、そのサービスのターゲットビュー、サービスと共有キャッシュとの相互作用方法、およびコントローラがサービスを管理する方法を含む）を定義するために使用されることが可能なサービスオブジェクト２２２２も提供する。サービスオブジェクト２２２２は、サービスオブジェクトの名前と、ウィンドウマネージャ２２２０の参照と、サービスオブジェクト２２２２に関してロードされている現行ビューの表示と、共有サービスキャッシュ２２０７への一連のアクセス方法と、他のサービスオブジェクトが用いてこのサービスオブジェクトへアクセスするための公開アクセス方法と、データモデル（例えば、データモデル２２１０）とを含む。
【０３４１】
ウィンドウマネージャ２２２０は、ある特定のサービスオブジェクト２２２２のために実装されることが可能である。本明細書で記述しているように、ウィンドウマネージャは、内部にビューが構築されかつユーザに対して可視化されるシェルである。ウィンドウマネージャ２２２０は、ウィンドウマネージャ２２２０の名前と、ウィンドウマネージャのインスタンスと、ロードの現行状態と、視覚的な現行状態と、ウィンドウマネージャ２２２０への公開アクセス方法とを含む。
【０３４２】
ターゲットビュー２２２４は、サービスオブジェクト２２２２のためのビューである。各ターゲットビュー２２２４は、ターゲットビュー２２２４の名前と、ターゲットビュー２２２４のＨＴＭＬテンプレートと、ターゲットビュー２２２４への公開アクセス方法とを含む。
【０３４３】
ＵＩコントローラ２２０９は、サービスオブジェクト２２２２を管理するように構成される。実施形態によっては、ＵＩコントローラ２２０９は、共有サービスキャッシュ２２０７を介するサービスオブジェクト２２２２間のデータ転送を管理する。先に述べたように、共有サービスキャッシュ２２０７は、キー／値ペアのアレイにおいてデータを共有するために使用されることが可能である。データは、例えば、機能上のコンテキスト、視覚的なコンテキストおよび／またはこれらに類似するコンテキストのために共用されることが可能である。
ジョブ
【０３４４】
データ管理のドメインには、システム状態に影響し得る多くのユーザ開始オペレーションが存在し、これらは、慎重な監視および報告を必要とする場合が多い。ユーザ駆動によるこれらのエンドツーエンド・タスクは各々、システムレベルのアクティビティ（例えば、データ管理仮想化エンジン３０６におけるプロセス）をトリガする。以後、これを「ジョブ」と称する。ジョブは、固有の状態およびライフサイクルを有する複数のサブジョブを含んでもよい。データ管理仮想化サブシステム内のジョブの管理および監視は、重要なアクティビティであって、システムモニタ・サービス内から実行される。
【０３４５】
実施形態によっては、ジョブの管理をサービス・ポリシー・エンジンが担当する。データ管理仮想化エンジン３０６は、複数のストレージプールをまたぐバックアップ、リカバリ、他等の幾つかのジョブを実行する。例えば、オペレーションが関係するボリュームが複数存在すれば、各ジョブは、他のサブジョブをインスタンス化する。
サービス２２０１
【０３４６】
サービス２２０１を参照すると、各サービスは、その固有のウィンドウマネージャ内の独立したアプリケーションとして実装される。各サービスは、共通の機能的挙動および視覚的コンポーネントに関して書かれたライブラリおよびコードのフレームワークを共有する。ベース・ウィンドウ・マネージャ内には、サービスオブジェクトのアレイが格納され、デスクトップアプリケーションが立ち上げられるとインスタンス化される。
アプリケーションマネージャ２２０５
【０３４７】
図２３は、ある例示的なアプリケーション・マネージャ・サービスを描いたものである。アプリケーション・マネージャ・サービスは、アプリケーションのライフサイクルを発見し、保護しかつ管理するためのグラフィカル・ユーザ・インタフェースを提供する。サービス・レベル・アグリーメント（ＳＬＡ）によって保護される全てのアプリケーションは、論理的に、そのフレームワーク内に表示されかつ編成される。バックアップ、復元および他のデータ管理仮想化エンジン３０６のオペレーションは、このサービスから開始される。
【０３４８】
アプリケーション・マネージャ・サービス２３０１の視覚化は、データ管理仮想化サブシステムの管理下にある全てのアプリケーションを含む、アプリケーションマネージャ・エレメントのためのナビゲーションリスト２３０２を含む。バックアップリスト２３０３は、選択されたアプリケーションに関連し、画像ＩＤ２３０４は、画像の識別に使用され、かつ２３０５は、画像上でサポートされるアクションである。画像は、サービスのサンプルビジュアルであり、ユーザは、ここで、クイックリンクを開始するためにアクションをトリガすることも可能である。
システムモニタ２２０６
【０３４９】
図２４は、データ管理プロバイダのデスクトップにおいて、ジョブに関連してユーザが見ることのできる全てのアクティビティの、監視および管理を含む処理を担当する例示的なシステムモニタ・サービスを示す。また、図２４は、システムモニタのレイアウトも明らかにしている。
【０３５０】
システムモニタ・サービス２４０１は、サブシステムにおけるジョブおよびイベントをリストする。ジョブリスト２４０２は、ユーザにデータグリッドのコンテキストを選択させる。フィルタ２４０３により、予め決められたフィルタを基礎としてグリッド内のデータセットを絞り込むことが可能になる。個々のジョブ２４０４は、グリッド内に、各々対応するジョブＩＤ２４０５を伴ってリストされる。
【０３５１】
図２５は、システムモニタ・サービス内からの特定のジョブの特有の詳細のディスプレイを描いたものである。ユーザは、あるロウをダブルクリックして個々のジョブを選択することができ、あるいは、オプションの「詳細を見る」を選べば、図２５に表示されているような詳細が現れる。
サービスマネージャ
【０３５２】
サービスマネージャは、個々のサービスインスタンスの管理を見込んだフレームワークである。これは、新しいサービスの追加、既存のサービスの除去、サービスの表示および隠し、およびその視覚的状態の管理を含む、幾つかのサービス関連オペレーションを提供する。
クイックリンク
【０３５３】
先に述べたように、クイックリンク２２０８は、そのユーザケースを介してユーザをシームレスに案内するために複数のサービス２２０１を互いに結びつける。これらの技術を例示するために、バックアップ・マウント・オペレーションのサンプルタスクを使用する。バックアップ・マウント・オペレーションに使用されるサービスには、アプリケーションマネージャ２２０５およびシステムモニタ２２０６が含まれる。ユーザは、マウントオペレーションをアプリケーションマネージャ２２０５内から開始する。システムは、マウントされ得るアプリケーションおよびその関連バックアップを識別し、マウントポイントおよびマウントされることが望まれる個々のバックアップボリュームに関するユーザからの入力を取り込む。ユーザ入力が検証されると、データ管理仮想化エンジン３０６システムは、対応するジョブおよび／または必要とされるサブジョブをインスタンス化するマウント要求を開始する。
【０３５４】
ジョブ間の関連づけは、データ管理仮想化エンジン３０６のプラットフォームサブシステム内に保全される。ジョブおよび／または必要とされるサブジョブをインスタンス化するための要求は、データ管理プロバイダのデスクトップ２１００からデータ管理仮想化エンジン３０６へ送られる。ジョブのインスタンス化が成功すると、データ管理仮想化エンジン３０６は、ジョブ（または、必要とされるサブジョブが存在する場合は、親ジョブ）の一意の（固有の）ＩＤをデータ管理プロバイダのデスクトップ２１００へ返す。例によっては、要求は、ウェブサービスのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を介してデータ管理仮想化エンジン３０６へ送信されることが可能である。ウェブサービスは、リプリゼンテーショナル・ステート・トランスファ（ＲＥＳＴ）アーキテクチャ原理のＪａｖａ（登録商標）ベースサービスのカスタム実装であることが可能である。プラットフォームとユーザインタフェースとの間の通信は、ハイパーテキスト転送プロトコル−セキュア（ＨＴＴＰＳ）プロトコルの上のＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記法（ＪＳＯＮ）−フォーマットストリングを用いることができる。データ管理プロバイダのデスクトップ２１００は、次に、このＩＤを用いて利用可能な全てのジョブのリストをウォークスルーする。
【０３５５】
図２５は、幾つかの実施形態による、システムモニタ・サービス２２０６内からの特定のジョブの特有の詳細のディスプレイを描いたものである。ジョブとの整合が識別されると、データ管理仮想化エンジン３０６からジョブの詳細が要求される。これらの詳細は、適切にフォーマットされ、視覚化され、かつ適切なサービスにおいてユーザが利用できるようにされる。本例では、サービスコンテキストがシステムモニタ２２０６へ切換され、ユーザへジョブ詳細ウィンドウが提示される。ジョブが実行中の状態にあれば、ジョブの詳細は、動的に更新される。ステータス情報は、データ管理プロバイダのデスクトップ２１００によりクライアント側のポーリングループの一部として開始される問い合わせから、５秒毎に検索される。ポーリングは、ジョブが首尾良く立ち上げられたことがジョブプラットフォームによって確認され次第開始される。
【０３５６】
グラフィカルコンテキストでは、アプリケーションマネージャ２２０５のビュー（図２３）がジョブ詳細のビュー（図２５）へ切り換わり、かつバックグラウンドサービスがシステムモニタ２２０６のビュー（図２４）へ切り換わる。
サービスコンテキストの切り換え
【０３５７】
ロードされている現行サービスのアレイは、データ管理プロバイダのデスクトップ２１００のインスタンスレベル上に保全され、かつこれは、サービスがユーザに見えているかどうかを含む各サービスの状態も格納する。スイッチングコンテキストが生じると、これは、ロードされているサービスのアレイに格納されている状態を更新し、かつウィンドウマネージャ２２００を用いて視覚的コンテキストを変える。また、これは、サービスインスタンスが先にロードされていなければ（例えば、ロードされている現行サービスのアレイ内に存在しなければ）、サービスインスタンスをインスタンス化することも含む。
【０３５８】
図２６は、クイックリンクなしのユーザフローを記述している。ステップ２６０１において、ユーザは、アプリケーションマネージャ２２０５からのジョブを開始する。ステップ２６０２において、システムは、ユーザ要求に応答してジョブまたはジョブリストをトリガする。ステップ２６０３において、システムモニタ２２０６は、ジョブを開始日、ステータスおよびジョブタイプによって編成する。ステップ２６０４において、システムモニタ２２０６は、命じられたジョブリストを表示し、これは、新しいユーザ要求を基礎として定期的に更新する。ステップ２６０５において、ユーザは、サービスをアプリケーションマネージャ２２０５からシステムモニタ２２０６へ切り換える。ステップ２６０６において、ユーザは、適切なフィルタを選んでシステムモニタ２２０６における可能なジョブのリストを絞り込む。ステップ２６０７において、ユーザは、システムモニタ２２０６におけるアクションタイプを基礎としてジョブを識別する。ステップ２６０８において、ユーザは、ジョブを選択し、かつ選択されたロウをダブルクリックしてシステムモニタ２２０６におけるジョブ固有の詳細を入手する。このプロセスは、幾つかの複合したステップを必要とすることがある。
【０３５９】
図２７は、クイックリンクを有するユーザフローを記述している。ステップ２７０１において、ユーザは、アプリケーションマネージャ２２０５からのジョブを開始する。ステップ２７０２において、データ管理プロバイダのデスクトップ２１００は、クイックリンクを用いて適切なジョブの詳細を表示する。プロセスは、ユーザからの追加的な相互作用なしに完了する。
スマートデータの同期化
【０３６０】
次項では、データ管理システム内のオペレーショナルデータについて論じる。データは、システム内に格納されることから、スナップショットの時刻、コンテンツアドレス可能ハンドルおよびこのような他のメタデータに関するメタデータがシステム内に蓄積する。このデータは、オペレーショナルデータと呼ばれる。オペレーショナルデータには、ポリシー、スケジュールおよびシステムコンフィギュレーションも含まれる。プラットフォームサーバは、プラットフォームサーバが管理している各サブシステムについて、各サブシステムから局所的にオペレーショナルデータのコピーを収集しかつ保全する、集中化されたデータ管理システムである。さらに、リモートサイト複製は、各サイトに１つのシステムを必要とする。２つのサイトが近接していれば、１つの管理コンソールが双方に使用されてもよい。
【０３６１】
状況によっては、複数のデータ管理システムの使用が利点を提供することがある。これは、例えば、システムに格納されるユーザデータの量が１２７テラバイト（ＴＢ）等の最大しきい値を超える場合に生じることがある。複数のデータ管理システムの使用は、複数のデータ管理システムの各々のオペレーショナルデータを同期する中央管理サーバの使用によって容易にされる場合がある。以下、オペレーショナルデータを複製しかつ同期するための手法について論じる。実施形態によっては、データの同期戦略は、データ自体を基礎として異なるものを配備することができる。実施形態によっては、データの同期戦略は、データレコードの数（例えば、少数のレコード、中サイズのレコードセット、または大サイズのレコードセット）を基礎として異なるものを配備することができる。オペレーショナルデータの同期化は、例えば、中央管理サーバのユーザが各システムを管理するために各データ管理システムまで行く必要をなくすことができ、代わりに、ユーザは単に、中央管理サーバを介して全てのデータ管理システムを管理することができる。ユーザは、中央管理サーバを活用して、ユーザが担当する全てのデータ管理システムのグローバルビューを容易に入手することができる。
【０３６２】
従来は、オペレーショナルデータは、ソースおよびターゲットからのデータを比較し、ソースにのみ存在するデータをターゲットへ追加し、ターゲットにのみ存在するデータを削除し、かつソースとターゲットとでデータが異なれば、ソースからのデータでターゲットデータを更新することによって同期される。本明細書では、オペレーショナルデータを複製するための技術を開示している。オペレーショナルデータ・レコードの数を基礎として、異なる技術の使用が可能である。例えば、小型のセットであれば、データは変わる場合が多くかつ直ぐに完了し得ることに起因して、単に、同期が発生する度に交換されることが可能である。中型セットの場合、（例えば、ＩＤの数が管理可能であることに起因して）タイムスタンプおよびレコードＩＤの双方を用いてデータを同期することができ、かつ削除情報を示すことができる。大型セットの場合、（例えば、オペレーションの中には、他のオペレーションより先に発生することが保証され得ないものがあることに起因して）同時的な処理ウィンドウを説明するために、公差数に関連してデータを同期すべく、レコードＩＤだけを使用することができる。これが可能である理由は、大型のデータセットは、典型的には、一旦生成されると変化せず、かつ典型的には、何らかの保持ポリシーを基礎として削除されることにある。
【０３６３】
図２８は、幾つかの実施形態による、複数のデータ移動仮想化エンジン３０６を管理することができる管理コンソール２８０１を描いている。これは、複数のデータ移動仮想化エンジン３０６上のデータが単一の管理コンソール２８０１へいつ同期されるか、を描いている。管理コンソール２８０１は、企業マネージャのオペレーショナルデータ２８０２のデータベースを含んでもよく、これは、管理コンソール２８０１へ同期される複数のデータ移動仮想化エンジン３０６の各々に関するデータ管理オペレーショナルデータ３００１の複製コピーを含む。これらのデータ管理オペレーショナルデータ３００１は、通常のオペレーションを保全し、または、正常なオペレーションから生成される。これらは、典型的には、リレーショナル・データベース・システムに格納されるが、他のタイプのストレージも可能である。
【０３６４】
図２９は、幾つかの実施形態による、企業マネージャのオペレーショナルデータ２８０２のデータベースを示す。このデータベースは、例えば、オペレーションの実行に必要なデータに関連するオペレーショナルデータ、およびこれらのオペレーションの結果を格納することができる。データベースに格納されるオペレーショナルデータには、サービス・レベル・アグリーメント（ＳＬＡ）データ２９０２、保護データ２９０４、履歴データ２９０５、イベントストア・データ２９０３およびアプリケーションデータが含まれる。データ移動仮想化エンジン内の一意の（固有の）ＩＤは、データベースに格納される各レコードを一意に識別するために使用されることが可能である。
【０３６５】
管理コンソール２８０１が複数のデータ移動仮想化エンジン３０６を管理するために、これらのオペレーショナルデータは、同じくリレーショナルデータベース内に存在する管理コンソール２８０１へ同期されてもよい。各データ移動仮想化エンジン３０６も、一意の（固有の）ＩＤに関連づけられる。一意のレコードＩＤと、データ移動仮想化エンジンのＩＤとの組合せは、管理コンソール内のレコードおよびレコードのオリジンを一意に識別する。
【０３６６】
図２９は、データ移動仮想化エンジンから複製されるデータを含む、管理コンソールのオペレーショナルデータ２８０２の例を描いたものである。図３０Ａは、幾つかの実施形態による、データ管理オペレーショナルデータ３００１の例を描いたものである。これらのデータには、ＳＬＡデータ３００２、保護データ３００４および履歴データ３００５が含まれてもよい。オペレーショナルデータ３００１には、イベントストア・データ３００６、アプリケーションデータ３３０６も同一場所に配置され（コロケートされ）てもよい。アプリケーションデータは、データ管理システムが管理するアプリケーションを表す。ＳＬＡデータは、アプリケーションを保護するために使用されるポリシーを表す。保護データは、様々なアプリケーションを保護するために使用されるポリシーを表す。履歴データは、成功であるか否かに関わらず、システム上で実行される全ての保護オペレーションを表す。イベントデータは、データ管理システム上で発生した全てのイベントを収集する。
【０３６７】
概して、オペレーショナルデータは、ＳＬＡ３００２等の、典型的には数百未満のレコードである小型のデータセット、または保護データ３００４等の、通常数千である中型のデータセット、または履歴データ３００５等の、何十万またはそれ以上であり得る大型のデータセットに分割されることが可能である。実施形態によっては、問題は、レコードのサイズではなく、単にレコードの数にある。大型のデータセットの場合、かなりの高速で生成されることから、これらは、典型的には修正されず、単に纏めて削除される。履歴データ３００５は、データ管理オペレーショナルデータ３００１において実行される全てのオペレーションの履歴レコードを表すことから、この基準に当てはまる。別の例は、イベントデータ３００３である。
小型データセットの同期化（または、データセットの頻繁な変更）
【０３６８】
小型のレコードセットを含むテーブル（レコードセット）の場合、従来の全レコードの比較で足りる。これは、ソースからターゲットへ全データをコピーすることと、これらを比較することを含む。データセットが小さいことから、ネットワーク帯域幅の消費および処理するためのＣＰＵは、典型的には最小限である。小型データセットは、１，０００個未満のオペレーショナルデータ・レコードを含むことが可能である。
中型データセットの同期化
【０３６９】
レコードセットのサイズが増大するにつれて、全てのレコードをフェッチして比較するコストも上昇する。より効率的にデータを同期するには、異なる戦略を用いることができる。中型データセットは、１，０００個を超えかつ１００，０００個未満のオペレーショナルデータ・レコードを包含することができる。
【０３７０】
実施形態によっては、レコードが変えられる（例えば、更新または生成）時点毎のカレントタイムスタンプが含まれる。各レコードは、最終修正日を含むことから、最後の同期化以降に変化したレコードのみを調べることが可能である。各同期化要求には、最終の同期化時間が付され、よって、新しい変化のみがソースからターゲットへ送られる。
【０３７１】
リレーショナルデータベースにおける変化の保存は、瞬間的には生じないことから、同時に保存される２つの変化を区別するのに最終の同期化時間の使用では足りない場合がある。さらに、レコードのタイムスタンプがまさに割り当てられたタイムスタンプと同期化時間との間であれば、レコードは見逃される場合がある。この問題は、同期化時間に公差調整を追加する（または、ロールバックする）ことによって回避することができる。これにより、送信されるデータ量が増える結果となる場合があるが、各レコードは、引き続き比較され、かつ変化があれば更新され、または変化がなければ廃棄されることから、正当性は保証され得る。公差は、変化に関わる必要な最大持続時間として計算されることが可能である。
【０３７２】
タイムスタンプがレコード上に設定される時間と、実際に保存される時間との間にはしばしば遅れが存在し、よって、第１のレコードが第２のレコードより前に保存されても、システム内で実行中の同時的なトランザクションは、結果的に第２のレコードが第１のレコードより前にタイムスタンプされる場合がある。公差は、この期間、およびさらなる期間をカバーするに余りあるように計算されることが可能である。より大きい公差は、調査されるレコードを増加させると同時に、正当性をさらに保証することができる。許容される同時的トランザクション、およびデータの実際の保存に起因する最大遅延を調べることにより、妥当な公差を選ぶことができる。次いで、安全のために、追加的なファクタを加えることができる（例えば、計算された公差を２倍にすれば、パフォーマンスにさほど影響はないが、データの適正な同期が保証される）。例えば、公差２分は、追加のファクタとして使用されることが可能である。
【０３７３】
この同期化手順は、データが絶対に削除されない場合によく機能する。しかしながら、レコードを削除できる場合には、レコードがもはや存在しないことからレコード内にタイムスタンプを格納する場所がない。データがソースから削除されることを説明するためには、異なる戦略を適用することができる。各レコードには、一意のＩＤがタグ付けされることから、最終の同期化時間の送信に加えて、ターゲットシステムにおける全ての既知のＩＤをソース側へ送ることができる。ソース側は、次に、ソースＩＤを調べて、もはやソース側に存在しないＩＤのリストを送り返すことができる。ターゲット側は、次に、ソースにより削除されるべきものとしてタグ付けされたデータを削除することができる。
【０３７４】
図３０Ｂは、データ管理オペレーショナルデータ３００１における保護データ３００４を描いたものであり、これは、１月１日（１−１；本例では、年は不要）に修正されてＩＤ１０００２が付された保護データレコード、１月１３日（１−１３）に修正されてＩＤ１０００４が付された保護データレコード、１月１２日（１−１２）に修正されてＩＤ１００１２が付された保護データレコード、１月１６日（１−１６）に修正されてＩＤ１００１５が付された保護データレコードおよび１月２０日（１−２０）に修正されてＩＤ１００２０が付された保護データレコードを有する。保護データ３００４における各エントリ用の長円は、他のフィールドのみならずそのレコード自体のデータも包含され得ることを指す。先行する同期化の間には、管理コンソール２８０１において、１月１日（１−１）に修正されたＩＤ１０００２、１月１３日（１−１３）に修正されたＩＤ１０００４、１月２日（１−２）に修正されたＩＤ１０００７、１月１２日（１−１２）に修正されたＩＤ１００１２および１月１２日（１−１２）に修正されたＩＤ１００１５が保護データ２９０４へ同期されている。本例では、保護データ３００４の保護データ２９０４への最終の同期化が１月１５日（１−１５）に発生し、よって、保護データ３００４におけるレコードＩＤ１００１５の修正１−１６およびレコードＩＤ１００２０の修正１−２０は、管理コンソール２８０１（保護データ２９０４）へ同期されておらず、またレコード１０００７は、保護データ３００４から削除され、管理コンソール２８０１には反映されていない。最終の同期化時間（例えば、本例では１−１５）は、次の同期化の計算を容易にするために記録される。
【０３７５】
次の同期化の間、管理コンソール２８０１は、図３０Ｃに示されているように、データ管理仮想化エンジン３０６へ保護データの同期化要求を送ることができる。要求３００４１は、先に述べたような、システムが公差（本例の場合、１日を用いる）を減じるタイムスタンプを含む。よって、要求３００４１では、管理コンソール２８０１によりデータ管理仮想化エンジン３０６へ、１−１５以降ではなく、１日の公差を減じた後の１−１４以降の全データに対する要求が送られる。別の例として、タイムスタンプは、分情報、秒情報、他を含むことが可能である。例えば、公差が６０秒であって、最終バックアップのタイムスタンプが１−１５の１：００ｐｍであれば、管理コンソール２８０１は、データ管理仮想化エンジン３０６から、１−１５の１２：５９ｐｍ以降のデータを要求する。
【０３７６】
データ管理仮想化エンジン３０６は、要求３００４１を受信すると、１−１４以降に生成／修正されている保護データ、即ち１−１６に修正されたＩＤ１００１５、１−２０に修正されたＩＤ１００２０を検索する。図３０Ｄに示されている応答３００４２では、ＩＤ１００１５（１−１６）およびＩＤ１００２０（１−２０）のコンテンツが管理コンソール２８０１へ送り返され、さらに、保護データ３００４における全ての既知のＩＤ（ＩＤ１０００２、ＩＤ１０００４、ＩＤ１００１２、ＩＤ１００１５、ＩＤ１００２０）が管理コンソール２８０１へ送り返される。管理コンソール２８０１は、単にＩＤ１００１５を更新し、かつＩＤ１００２０を生成することができる。次いで、レコード１０００７は、もはや応答３００４２における既知のＩＤリストにないことから削除されるが、これは、レコード１０００７が保護データ２９０４への最終の同期化以降に保護データ３００４から削除されていることを意味する。このプロセスは、管理コンソール２８０２が管理する必要のあるデータ管理仮想化エンジン３０６の各々（例えば、各データ管理仮想化エンジン３０６の固有の修正データおよびＩＤリストの各々）について反復されることが可能である。
大型データセット（データは全く変化せず、旧データが纏めて削除される）の同期化
【０３７７】
最終修正時間の使用は、現在時刻を検索しかつレコードに時刻をタグ付けするコストを生じる。各レコードは、一意のＩＤがタグ付けされることから、データが生成後に修正されなければ、ＩＤ生成戦略を使用することにより、大型データセットを同期する効率をさらに上げることができる。大型データセットは、例えば、１００，０００個を超えるオペレーショナルデータ・レコードを有するセットであることが可能である。
【０３７８】
１つの戦略は、増加し続けるＩＤを割り当てることであり、同じＩＤは再使用されない。これらのＩＤには、順序にずれがある場合があるが、概して、より大きいＩＤは、そのレコードが後のほうに生成されていることを示す。このシステムまたは方法の場合、レコード毎に生成時間をタグ付けする必要がない。
【０３７９】
増加し続けるＩＤ番号を効率的に割り当てるためには、次の戦略を使用することができる。分配用にＩＤのチャンク（例えば、１０２４ＩＤ、２０４８ＩＤ、他）が確保され、最後に割り当てられる可能性のあるＩＤ（例えば、ＩＤ１０２４、ＩＤ２０４８、他）がデータベースに記録される。ＩＤが必要とされる度に、１つが使用される。全てのＩＤが使用されると、別のＩＤチャンクが確保され、同じく最も大きいものである可能性のあるＩＤが記録される。システムがクラッシュすれば、分配されていないＩＤは廃棄されることが可能であって、プロセスは、記録された最も大きいＩＤから再開することができる。この方法では、ＩＤを効率的に割り当てることができ、かつＩＤは、概して時間順であって、より大きいＩＤは、概して後の時間に発生するデータに割り当てられる。ＩＤに６４ビット等の予め決められたサイズを用いれば、ＩＤがループしないことを保証することができる。
【０３８０】
同期化の間、ターゲットシステムにおける最大のＩＤ（タイムスタンプの場合のように何らかの公差数を減じたもの）が、同期化タイムスタンプの代わりにソースシステムへ送られる。ターゲットシステムへは、より大きいＩＤを有するレコードのみが送られる。さらに、公差内の既知のＩＤも、ターゲットからソースへ送られる。よって、ソースは、公差期間中に存在するＩＤのリストにあるものではなく、ターゲットから送られたＩＤより大きいＩＤを送るだけでよい。このシステムまたは方法を用いれば、ターゲットシステムは、レコードを比較する必要なしに、ソースから送られるレコードをそのまま採用することができる。
【０３８１】
図３０Ｅは、データ管理オペレーショナルデータ３００１における履歴データ３００５を描いたものであり、これは、ＩＤ１、２、等々から１００１０、１００１１、１００１２、１００１３、１００１４、さらには１０１００までを有するレコードを含む。各ＩＤは、１つのジョブに関連づけられる（例えば、ＩＤ１は、ジョブ＿００００１に関連づけられる）。保護データ３００４における各エントリ用の長円は、他のフィールドのみならずそのレコード自体のデータも包含され得ることを指す。ＩＤ１、２、．．．、１００１０、１００１１および１００１３は、履歴データ３００５の履歴データ２９０５への先行する同期化において、既に管理コンソール２８０１において履歴データ２９０５へ同期されている。
【０３８２】
次の同期化の間、管理コンソール２８０１は、図３０Ｆに示されている履歴データの同期化要求３００５１をデータ管理仮想化エンジン３０６へ送る。要求を生成するために、管理コンソール２８０１は、まず、管理コンソール２８０１が所有する最も大きいＩＤ、即ち１００１３を調べる。管理コンソール２８０１は、次に、この最大のＩＤからレコードの公差数を減じる。本例では、公差数３を用いることができる。１００１３から３レコードを遡ってカウントすると、ＩＤ１００１０になる。よって、要求３００５１は、１００１０より大きい全ての履歴データに対して行われる。別の例では、公差２００の使用が可能であり、よって最大のＩＤ１００１３から２００レコードを遡ってカウントしたＩＤは、ＩＤ９８０１になると思われる。公差は、同時的なトランザクションおよびトランザクションを行う際の最大遅延を安全上の何らかのファクタと合わせて調査することにより選ぶことができる。
【０３８３】
管理コンソール２８０１は、計算されたＩＤ１００１０と最大のＩＤ１０１４との間で既に何らかのレコードを有しているかどうかも決定する。管理コンソール２８０１は、履歴データ２９０５がＩＤ１００１１および１００１３を含んでいることを決定し、よって、このデータの別のコピーを受信する必要はない。よって、管理コンソール２８０１は、（１００１１、１００１３）を除く、ＩＤ１００１０より大きい全てのデータに対する要求３００５１を生成する。要求３００５１は、次に、データ管理仮想化エンジン３０６へ送られる。
【０３８４】
図３０Ｇは、要求３００５１を受信した後のデータ管理仮想化エンジン３０６を描いたものであり、これは、１００１０より大きいＩＤを検索するが、ＩＤ１００１１および１００１３を有するデータを除外している。データ管理仮想化エンジン３０６は、応答３００５２において結果を管理コンソール２８０１へ送り返す。管理コンソール２８０１は、次に、応答３００５２には履歴データ２９０５がもはや有していないデータしか含まれないことから、単に履歴データを追加するだけでよい。このプロセスは、管理コンソール２８０１が管理する必要のあるデータ管理仮想化エンジン３０６の各々（例えば、各データ管理仮想化エンジン３０６の固有の修正データおよびＩＤリストの各々）について反復されることが可能である。
【０３８５】
先に述べたように、データの性質に依存して、システム内の異なるタイプのデータには、異なる戦略が適用されてもよい。システム内にデータが蓄積していくにつれて、データの性質が事前に知られる場合があり、これらの性質を基礎として、増大されたパフォーマンスを達成すべく異なる戦略を適用することができる。
【０３８６】
データ移動仮想化エンジン３０６からのデータの管理コンソール２８００への同期化は、これらの戦略の組合せを介して達成されてもよい。このような組合せの例には、下記が含まれる。
【０３８７】
小型データセットの戦略によって、データ移動仮想化エンジン３０６上のＳＬＡ２９０２が管理コンソール２８００上のＳＬＡ３００２へ同期される。
【０３８８】
中型データセットの戦略によって、データ移動仮想化エンジン３０６上の保護２９０４が管理コンソール２８００上の保護３００４へ同期される。
【０３８９】
大型データセットの戦略によって、データ移動仮想化エンジン３０６上の履歴２９０５が管理コンソール２８００上の履歴３００５へ同期される。
ロケーションベースのハッシュ・インデックス・キャッシング
【０３９０】
開示しているデータストレージおよび重複排除エンジンは、任意サイズのコンピュータファイルまたはディスク画像ソースを１つまたは複数の固定サイズのデータブロックに変換する。これらのデータブロックは、先にステップ１５２８で述べたように、キャパシティ最適化ストレージプール（ＣＡＳ）に書き込まれてもよい。データがＣＡＳへと読み込まれるにつれて、データブロックは、ファイルシステムへ、受信された順にバッチ式で書き込まれ、または存続される。各バッチは、持続的なヘッダブロックによって先行される。持続的なヘッダは、持続的なヘッダに続く各データブロックに関して、サイズ、ロケーションおよびハッシュコードを含む情報を含む。１つのバッチ持続オペレーションは、一度に僅か１つのソースからの約２０００個のデータブロックを含む。
【０３９１】
本明細書に記述するシステムおよび方法は、重複排除データストアからデータを読み取るパフォーマンスを向上させる。重複排除データストアからのデータの読み取りは、重複排除データストアに格納されるデータが、まさにその性質上、重複するデータを回避するために様々なポインタ（および／またはこれに類似するもの）によってしばしばデータストア中に拡散されることに起因して、時間がかかる場合が多い。したがって、重複排除データストアからの読み取りは、（例えば、ディスク上に格納された単一ファイルの読み取り等の順次的なものではなく）データストア中に拡散されたデータを読み取ることを必要とする。例えば、データの各ハッシュは、まず位置決めされた上で、関連データが格納されているディスク上の場所のインデックスをルックアップするために使用されなければならず、データをシステムから読み取れるのは、この次である（例えばこれは、ハードドライブによる多くの時間を要する機械的動作を必要とする場合が多い）。ハッシュ情報は、しばしばＢ木を用いて格納されるが、これは、格納されるデータを保持し、かつ対数時間における探索、順次アクセス、挿入および削除を許容するデータ構造である。しかしながら、重複排除データストアからの読み取りに際しては、Ｂ木の使用では速度が不十分であることが多い。
【０３９２】
本明細書に記述するシステムおよびコンピュータ化された（コンピュータに実行させる）方法は、新しいデータを重複排除データストアへの書き込みに伴って格納するために使用されるカスタム持続的ヘッダデータ構造を提供する。持続的なヘッダは、この持続的なヘッダによって表されるデータのハッシュセットを含む。また、本システムおよびコンピュータ化された方法は、最近にアクセスされたハッシュ、ならびに最近にアクセスされたハッシュに近いハッシュをキャッシュするために使用される、退行するハッシュテーブル（「スコアボード」とも称される）も提供する。例えば、持続的なヘッダに格納されているデータに関して１つのハッシュが読み取られれば、この持続的なヘッダに関連づけられる残りのハッシュは、読み取り速度を上げるためにメモリへ事前にキャッシュされることが可能である（これは、例えば、ルックアップされるハッシュの後のデータは、重複排除データストアへの同じ書き込みオペレーションの間に書き込まれていることから、これも同時に読み取られる可能性が高いことに起因する）。次のデータ要求が、退行するハッシュテーブルに事前にロードされたハッシュに対するものであれば、この事前にロードされたデータは、マスタ・ハッシュ・インデックスにおけるデータをルックアップする（時間がかかる可能性がある）必要を省く。
【０３９３】
図３１は、幾つかの実施形態による、ディスク上の持続的なヘッダおよび後続データを示す略図である。持続的なヘッダ３１００は、論理的には単一のオペレーションとしてディスクへ書き込まれるべき幾つかのデータブロック０、１、２、３、４、．．．、１９１９に先行する。持続的なヘッダ３１００に関連するブロック０−１９１９は、ソース画像３１０２の第１のブロック０−１９１９を表す。また、持続的なヘッダ３１０４も、１９２０個のブロック（０、１、２、３、４、．．．、１９１９）に先行する。持続的なヘッダ３１０４に関連するブロック０−１９１９は、１９２０個の第２のブロック、またはソース画像３１０２のブロック１９２０−３８３９を表す。データが格納されるにつれて、ディスクへ、まず持続的なヘッダが書き込まれ、続いて１９２０個までのデータブロックが個々に書き込まれる。持続的なヘッダは、個々のデータブロック確保に関する識別ハッシュ情報を保全する。
【０３９４】
各持続的なヘッダに格納されるデータは、ソース画像上に格納されるデータに線形的に対応して示されているが、これは、単に例示のためである。例えば、重複排除データストレージの場合、新しいデータのみがソース画像から重複排除データストアへ書き込まれる（重複データは書き込まれない）。したがって、これらの実施形態において、持続的なヘッダは、書き込み毎に新しいデータのみを格納し、よって、各持続的ヘッダにより格納されるデータは、必ずしも、ソース画像に格納されるデータとの線形的関係に対応し得ない。しかしながら、持続的なヘッダ内のデータをこの方式で配列することにより、持続的なヘッダは、潜在的に関連のあるコンテンツ、近傍のコンテンツおよび／またはこれらに類似するものを格納する。
【０３９５】
図３２は、持続的なヘッダのデータ構造の略図である。１９２０個のハッシュより成るアレイ３２０５は、図３１に記録されているような持続的ヘッダに続く連続したデータブロックの各々のハッシュ値を含む。２５６個のチャンクより成るアレイ３２０４は、１６個までのハッシュ値の「チャンク」の正確なロケーション、フォーマットおよび検証チェックサムに関する情報を含む。
【０３９６】
Ｉ／Ｏヘッダ３２０１は、ディスク上に格納される全てのシステムメタデータのために共有されるデータ構造体（例えば、Ｃ言語構造体）である。この構造は、例えば、エラーチェックのためのデータ、ページ識別番号、ページバージョン、書き込み時刻のタイムスタンプおよびデータタイプ識別子を含むことが可能である。
【０３９７】
チャンクカウント３２０２は、この持続的なヘッダに続くユーザデータのチャンク数を含む整数である。１つの「チャンク」は、４Ｋ（４０９６バイト）のデータを１６個まで含む。
【０３９８】
インデックスカウント３２０３は、持続的なヘッダに続く先に述べた後続チャンク内に含まれるハッシュの数を含む整数である。
【０３９９】
２５６個のチャンクより成るアレイ３２０４は、例えば、ロケーション、圧縮、チェックサム、ハッシュの数（１６まで）および暗号化を含むユーザデータの後続チャンクについて記述する構造体（例えば、Ｃ言語構造体）のアレイである。
【０４００】
１９２０個のハッシュより成るアレイ３２０５は、この持続的なヘッダによって記述される全ての４ＫデータブロックのＳＨＡ１ハッシュ値を含む構造体（例えば、Ｃ言語構造体）のアレイである。
【０４０１】
未使用スペース３２０６は、持続的ヘッダ構造全体をアラインするための６４Ｋ（６５５３６バイト）に対するフィラである。
【０４０２】
チェックサム３２０７は、データ完全性を検証するために使用される構造体の整数のチェックサムである。
【０４０３】
図３３は、重複排除ハッシュインデックスの例示的な略図である。例えば、重複排除ハッシュインデックスは、Ｂ木において実装されることが可能である。内部ページは、葉ページの参照のインデックスアレイを形成し、このインデックスアレイが、持続的なヘッダ（図３２）に含まれるハッシュ値の参照のインデックスアレイとなる。ハッシュ値の一部は、内部ページへのインデックスとして使用される。階層的様式であれば、適切な葉ページを識別するために、より多くのハッシュ値が使用される。最後に、持続的なヘッダは、関連するデータブロックを見出すために使用される。
【０４０４】
「内部ページ」３３０１を参照すると、これは、ディスク上へ格納されかつ「葉ページ」３３０２の参照ブロックのロケーションについて記述する構造体（例えば、Ｃ言語構造体）のアレイである。各内部ページ構造体は、例えば、葉ページを見出すべきディスクロケーションのアレイを含む。
【０４０５】
「葉ページ」３３０２を参照すると、これは、ディスク上へ格納されかつハッシュ値を「持続的なヘッダ」３２００へ相互参照する構造体（例えば、Ｃ言語構造体）である。
【０４０６】
「持続的なヘッダ」については、図３２を参照されたい。
【０４０７】
ハッシュインデックスは、システム内に格納されるデータを、そのハッシュ値を基礎として見出す機構である。図３２に示されている３つのレベル（内部ページ３３０１、葉ページ３３０２および持続的なヘッダ３２００）は、システムＲＡＭ内におけるインデックス全体の位置決めを必要とすることなく、そのハッシュによって任意の特有のデータを位置決めする能力を提供する、３ティア階層を生成する。例えば、内部ページは、ＲＡＭ内に存在することができるが、葉ページは、必要に応じてロードされかつアンロードされる。同様に、持続的なヘッダも、葉ページによって参照されると必要に応じてロードされる。
【０４０８】
図３４は、幾つかの実施形態による、「ページキャッシュ」を示す略図である。ページキャッシュは、システム内の予め割り付けられたメモリページのアレイであり、各メモリページは、「キャッシュページ」と称される。キャッシュページは、「ページキャッシュ」内でＬＲＵ（最長時間未使用）リストとして管理される。ページキャッシュは、システム内のメモリの中央リポジトリとして使用されることが可能である。例えば、アプリケーションによって使用される最も動的なメモリは、このページキャッシュから入手されることが可能である。
【０４０９】
特有のデータが要求されると、ページキャッシュのＬＲＵリストが最も最近に使用されたものから最も長く使われていないものへと線形式に探索され、見出されれば、適切なキャッシュページ３４０３がＬＲＵリストから外されて返される。データが見出されなければ、最長時間未使用のキャッシュページが返される。キャッシュページは、解放されると、再び必要とされれば迅速に見出され得るように、ＬＲＵリストの最前部に置かれる。
【０４１０】
「キャッシュ・ページ・アレイ」３４０１を参照すると、これは、幾つかの事前に割り付けられた６４Ｋ（６５５３６バイト）メモリブロックについて記述するキャッシュ・ページ・アレイ・エントリ３４０２構造体（例えば、Ｃ言語構造体）のアレイである。キャッシュページは、全て、６４Ｋ（６５５３６バイト）であるような大きさにされる。内部ページ３３０１、葉ページ３３０２、持続的なヘッダ３２００、ならびにシステム内の全ての内部構造体は、１つのキャッシュページに嵌まるような大きさにされる。
【０４１１】
「キャッシュ・ページ・アレイ・エントリ」３４０２を参照すると、これは、キャッシュ・ページ・アレイにおける１つのキャッシュページ・エントリについて記述する構造体（例えば、Ｃ言語構造体）である。ここで、「リスト」３４１１は、連結されたリスト含有物を管理するための構造体（例えば、Ｃ言語構造体）である（例えば、これは、ＬＲＵを管理するために使用される）。「インデックス」３４１２は、１つのインデックス値である。「フラグ」３４１３の値は、そのページがアプリケーション内でどのように使用されていくかについて記述するために使用され、例えば、フラグは、そのキャッシュページが使用中であるか否か、またはそれが保存される必要のあるデータを含んでいるか否か、を示してもよい。「ｔｒａｎ＿ｉｄ」３４１４フィールドは、そのキャッシュページを使用するカレントタスクを識別するために使用される。「ハッシュコード」３４１５フィールドは、典型的にはこのエントリによって識別されるキャッシュページのＳＨＡ１ハッシュコードを含む、Ｃ言語構造体である。キャッシュページ３４０３は、内部ページ３３０１、葉ページ３３０２、持続的なヘッダ３２００または他のシステムデータといった、任意数の目的のために使用されてもよい。ハッシュ識別子は、ページキャッシュにおける具体的なキャッシュページを見出すために使用される。「データ」３４１６フィールドは、このエントリによって記述されるメモリをポイントするポインタ（例えば、Ｃ言語ポインタ）である。実施形態によっては、このデータは、図３２に示されているような持続的なヘッダをポイントする。
【０４１２】
図３５は、退行するスコアボードシステムを示す略図である。「ハッシュテーブル・アレイ」３５０１は、１対の数字、即ち「持続的ヘッダ参照」３５０２アレイへのインデックス、および持続的なヘッダの「１９２０個のハッシュより成るアレイ」（図３２）へのインデックス、を含むデータ構造体のアレイである。持続的ヘッダ参照は、持続的ヘッダ・ハッシュコードのＭＲＵ（最短時間未使用）アレイである。持続的ヘッダ・ハッシュコードは、「ページキャッシュ」（図３４）から「持続的なヘッダ」（図３２）を検索するために使用される。データは、その識別用ハッシュ値の一部を、結果的に持続的ヘッダの参照インデックスとなる「ハッシュテーブル・アレイ」３５０１へのインデックス、および持続的ヘッダの「１９２０個のハッシュより成るアレイ」３２０５へのインデックスとして用いることにより見出される。ページヘッダの参照インデックスは、「持続的ヘッダ参照」３５０２から持続的なヘッダ（図３２）のハッシュコードを入手するために使用される。ハッシュコード３５１２は、次に、ページキャッシュ（図３４）から持続的ヘッダデータを検索するために使用される。持続的ヘッダの「１９２０個のハッシュより成るアレイ」３２０４へのインデックスは、具体的な識別用ハッシュコードを位置決めするために使用される。
【０４１３】
「ハッシュテーブル・アレイ」３５０１を参照すると、これは、ハッシュ値を「持続的ヘッダ参照」３５０２内の１つのエントリへリンクする構造体（例えば、Ｃ言語構造体）のアレイである。各エントリは、３つのフィールド、即ち、「ハッシュフラグメント」３５２１、「ページインデックス」３５２２および「ハッシュインデックス」３５２３、より成る。「ハッシュフラグメント」は、見出されるエントリが参照されるハッシュ値に整合することをチェックするために使用される、ＳＨＡ１の一部である。「ページインデックス」は、「持続的ヘッダ参照」への数字インデックスである。「ハッシュインデックス」は、「持続的ヘッダ」の「１９２０個のハッシュより成るアレイ」（図３２）へのインデックスである。
【０４１４】
「持続的ヘッダ参照」３５０２を参照すると、これは、「持続的なヘッダ」（図３２）を「ページキャッシュ」（図３４）内に包含されるものとして参照する構造体（例えば、Ｃ言語構造体）のアレイである。持続的ヘッダ参照における各エントリは、キャッシュページ・エントリ３４０２、ハッシュコードおよびディスク参照への参照を含む。キャッシュページ３５１１は、キャッシュ・ページ・アレイ（図３４参照）へのインデックスとして使用される。ハッシュコードは、そのキャッシュページのキャッシュ・ページ・アレイの探索に際して、適切なキャッシュ・ページ・アレイ・エントリが識別されたことを検証するために使用される。
【０４１５】
ハッシュテーブル・アレイは、退行するハッシュテーブル（または「スコアボード」）として使用される。例えば、データが重複排除データストアから読み取られるにつれて、第１のハッシュが検索され（例えば、Ｂ木における等、図３６に記述されるように）、第１のハッシュを含む持続的なヘッダ３２００からの１９２０個のハッシュより成るアレイ３２０５が、ハッシュテーブル・アレイにロードされる。後続の要求が、ハッシュテーブル・アレイに格納されたハッシュを有するデータに対するものであれば、要求は、（例えば、図３７に記述されるように）退行するハッシュテーブルのみを用いて処理されることが可能である。後続の要求が、ハッシュテーブル・アレイに格納されていない新しいハッシュを有するデータに対するものであれば、要求は、（例えば、図３６に記述されるように）主木を用いて処理され、新しいハッシュを含む新しい持続的ヘッダ３２００からの１９２０個のハッシュより成るアレイ３２０５が、ハッシュテーブル・アレイにロードされる。
【０４１６】
ハッシュテーブル・アレイは、新しいハッシュアレイが追加されるにつれて退行するが、これは、ハッシュテーブル・アレイが固定サイズを有するためである。例えば、ハッシュテーブル・アレイは、１９２０個のハッシュより成るアレイ３２０５のサイズの約１０倍であるように構成されることが可能である。
したがって、ハッシュテーブル・アレイが様々な持続的ヘッダからのハッシュでいっぱいになると、新しいハッシュが追加されるにつれて、先行するハッシュに上書きされる。このプロセスは、ハッシュテーブル・アレイを管理する他の戦略（例えば、ＬＲＵエイジングアルゴリズム）を用いることなく、ハッシュをハッシュテーブル・アレイへ追加する関数として達成されることが可能である。
【０４１７】
図３６は、スコアボードを用いて図３５に示されているスコアボードにより参照されないハッシュを見出す、システムのオペレーションフローを描いたフローチャートである。失敗すると、ハッシュは、（例えば、図３３に示されている）より大きい重複排除インデキシングシステム内に見出され、スコアボードへ追加される。ステップ３６０１では、スコアボードにおいてデータがルックアップされる。ステップ３６１０において、データがハッシュテーブル・アレイにおいて見出されるかどうかを調べる。ハッシュが見つかれば、ステップ３６２０において返される。ハッシュが見つからなければ、ステップ３６３０において、これを（例えば、図３３に示されている）主インデックスにおいてルックアップする。ステップ３６４０において、発見されたかどうかを調べる。ハッシュが見つからなければ、ステップ３６５０において返される。ステップ３６４０が主インデックス内にハッシュを見出せば、ステップ３６６０において、その持続的なヘッダ（図３２）を検索する。ステップ３６７０、ステップ３６８０およびステップ３６９０において、持続的なヘッダの「ハッシュアレイ」を通して反復し、スコアボードを持続的なヘッダからのデータでポピュレートする。
【０４１８】
図３７は、スコアボードを用いてスコアボードにより参照されるハッシュを見出す、システムのオペレーションフローを描いたフローチャートである。ステップ３７０１において、スコアボードは、ハッシュコードを受信する。ステップ３７０５において、ハッシュコードの僅かな部分を用いて「ハッシュフラグメント」が生成される。ステップ３７１０において、「ハッシュフラグメント」は、スコアボード「ハッシュテーブル・アレイ」（図３５）へのインデックスとして使用される。ステップ３７１５において、「ハッシュフラグメント」が「ハッシュテーブル・アレイ」エントリ（図３５）内のフラグメントに一致するかどうかを調べる。ハッシュが一致しなければ、ステップ３７２０において、「発見せず」としてルーチンを出る。ステップ３７２５において、「ハッシュテーブル・アレイ」エントリからの「ページインデックス」を用いて、「ページキャッシュ」（図３４）内に存在するはずの持続的ヘッダ（図３２）のキャッシュページ参照を検索する。ステップ３７３０において、ページキャッシュ内で正しい持続的ヘッダ・ページを見つけることができるかどうかを調べる。見つからなければ、ステップ３７３５において、「発見せず」として退出する。ステップ３７４０において、ステップ３７０１で受信されたハッシュコードを持続的ヘッダにおけるエントリと比較する。ステップ３７４５において、比較結果を調べる。ハッシュ値が一致しなければ、ステップ３７５０において、「発見せず」として退出する。ステップ３７５５において、「発見」を返す。
【０４１９】
本明細書に記述するシステムおよび方法は、データ局所性を用いて一般化されたインデックスシステムを補強することにより、データのロケーティングを高速化することができる。ＳＨＡ１等の暗号ハッシュコードは、意図的に、後続ハッシュ値を予測する方法を提供しない。本明細書に記述するスコアボードは、主ハッシュインデックス（図３３）まで行くことなく、データ局所性の特性を用いてデータを見出すプロセスである。さらに、スコアボードの退行する性質は、アクティブなシステム保全が存在しない場合に、より従来的なキャッシュシステムを管理するオーバーヘッドを減らす。
システムの実装
【０４２０】
図３８は、本開示の所定の実施形態による、所定のエレメントを実装し得るコンピュータ化された（コンピュータに実行させる）システムの様々なコンポーネントを示す図である。記述する論理モジュールは、揮発性メモリ３８０２と、ハードドライブ等の永続的なストレージデバイス３８０８と、プロセッサ３８０３と、ネットワークインタフェース３８０４とを含むホストコンピュータ３８０１上へ実装されてもよい。ネットワークインタフェースを用いることにより、他の実施形態の中でもとりわけ、本システムコンピュータは、ＳＡＮまたはファイバチャネル・デバイス上でストレージプール３８０５、３８０６と相互作用することができる。図３８は、システムコンピュータが様々なストレージプールから分離しているシステムを示しているが、幾つかの、または全てのストレージプールは、ホストコンピュータ内に収容されてもよく、ネットワークインタフェースの必要性が排除される。このプログラマティックなプロセスは、図３８に示されているように、単一のホスト上で実行されてもよく、複数のホストに亘って分散されてもよい。
【０４２１】
図３８に示されているホストコンピュータは、管理ワークステーションとして機能してもよく、または、アプリケーションおよびアプリケーション指定エージェント４０２を実装してもよく、または、データ仮想化システム自体を含む、本明細書に記述されている任意の、および全ての論理モジュールを実装してもよく、または、物理媒体のストレージプールをシステムに暴露するためのストレージコントローラとして機能してもよい。ワークステーションは、グラフィック・ディスプレイ・デバイス３８０７へ、かつマウス３８０９およびキーボード３８１０等の入力デバイスへ接続されてもよい。あるいは、アクティブユーザのワークステーションは、ハンドヘルドデバイスを含んでもよい。
【０４２２】
本明細書を通じて、ソフトウェアコンポーネントを参照しているが、ソフトウェアコンポーネントに関する全ての参照は、ハードウェア上で実行されるソフトウェアにも当てはまることが意図されている。同様に、本明細書において参照されるオブジェクトおよびデータ構造は、揮発性、不揮発性を問わず実際にメモリに格納されるデータ構造にも当てはまることが意図されている。同様に、サーバは、ソフトウェアに当てはまることが意図され、かつエンジンは、ソフトウェアに当てはまることが意図され、全て図３８に記述されているコンピュータシステム等のハードウェア上で実行される。
【０４２３】
以上、発明対象のより多くの関連する特徴のうちの幾つかについて概説した。これらの特徴は、単なる例示として解釈されるべきものである。開示した発明対象を異なる方式で適用すること、または、記述される本発明対象を変更することにより、他の多くの有利な結果を達成することができる。
【図１】
2015525419.tif 000003
【図２】
2015525419.tif 000004
【図３】
2015525419.tif 000005
【図４】
2015525419.tif 000006
【図５】
2015525419.tif 000007
【図６】
2015525419.tif 000008
【図７】
2015525419.tif 000009
【図８】
2015525419.tif 000010
【図９】
2015525419.tif 000011
【図１０】
2015525419.tif 000012
【図１１】
2015525419.tif 000013
【図１２】
2015525419.tif 000014
【図１３】
2015525419.tif 000015
【図１４】
2015525419.tif 000016
【図１５】
2015525419.tif 000017
【図１６】
2015525419.tif 000018
【図１７】
2015525419.tif 000019
【図１８Ａ】
2015525419.tif 000020
【図１８Ｂ】
2015525419.tif 000021
【図１９Ａ】
2015525419.tif 000022
【図１９Ｂ】
2015525419.tif 000023
【図２０Ａ】
2015525419.tif 000024
【図２０Ｂ】
2015525419.tif 000025
【図２０Ｃ】
2015525419.tif 000026
【図２１】
2015525419.tif 000027
【図２２】
2015525419.tif 000028
【図２２Ａ】
2015525419.tif 000029
【図２５】
2015525419.tif 000030
【図２６】
2015525419.tif 000031
【図２７】
2015525419.tif 000032
【図２８】
2015525419.tif 000033
【図２９】
2015525419.tif 000034
【図３０Ａ】
2015525419.tif 000035
【図３０Ｂ】
2015525419.tif 000036
【図３０Ｃ】
2015525419.tif 000037
【図３０Ｄ】
2015525419.tif 000038
【図３０Ｅ】
2015525419.tif 000039
【図３０Ｆ】
2015525419.tif 000040
【図３０Ｇ】
2015525419.tif 000041
【図３１】
2015525419.tif 000042
【図３２】
2015525419.tif 000043
【図３３】
2015525419.tif 000044
【図３４】
2015525419.tif 000045
【図３５】
2015525419.tif 000046
【図３６】
2015525419.tif 000047
【図３７】
2015525419.tif 000048
【図３８】
2015525419.tif 000049
【図２３】
2015525419.tif 000050
【図２４】
2015525419.tif 000051
【国際調査報告】
2015525419.tif 000052
2015525419.tif 000053
2015525419.tif 000054