(57)【要約】リモート・ストレージ・データー集合を更新する。方法は、ローカル・サービスから、リモート・サービスに存在するかもしれないリモート・ストレージ・データー集合のヒントを供給するアクトを含む。リモート・サービスから、そのリモート・ストレージ・データー集合がリモート・サービスに存在することの指示を受ける。この方法は、リモート・サービスにおいて、リモート・ストレージ・データー集合を、リモート・ストレージ・データー集合のコピーにコピーすることを要求するアクトを含む。リモート・ストレージ・データー集合のコピーに適用される変化をリモート・サービスに送る。【選択図】図１
2015519651.tif 000002
【特許請求の範囲】
【請求項１】
リモート・ストレージ・データー集合を更新する方法であって、
ローカル・サービスから、リモート・サービスにおいて存在するかもしれないリモート・ストレージ・データー集合のヒントを供給する動作と、
前記リモート・サービスから、前記リモート・ストレージ・データー集合が当該リモート・サービスにおいて存在することの指示を受ける動作と、
前記リモート・ストレージ・データー集合を、前記リモート・サービスにおいて、前記リモート・ストレージ・データー集合のコピーにコピーすることを要求する動作と、
前記リモート・ストレージ・データー集合のコピーに適用される変化を、前記リモート・サービスに送る動作と、
を含む、方法。
【請求項２】
請求項１記載の方法であって、更に、前記リモート・サービスにデーター集合完全性データーを要求し、前記データー集合完全性データーをローカル完全性データーと比較する動作を含む、方法。
【請求項３】
請求項２記載の方法において、前記ローカル完全性データーが、前記ローカル・データー集合に対するローカルな変更に基づいて決定される、方法。
【請求項４】
請求項２記載の方法において、前記リモート・サービスからのデーター集合完全性データーおよび前記ローカル完全性データーが、１つ以上のハッシュを含む、方法。
【請求項５】
請求項２記載の方法において、前記データー集合完全性データーをローカル完全性データーと比較する動作が、前記データー集合をローカル・データー集合と照合するために実行される、方法。
【請求項６】
請求項１記載の方法において、リモート・ストレージ・データー集合のヒントを供給する動作が、しかるべきリモート・データー集合が発見されるまで、反復的に実行される、方法。
【請求項７】
請求項１記載の方法において、前記ローカル・サービスから送られる変化が、前記ローカル・サービスにおける差分ストレージによって判定される、方法。
【請求項８】
請求項１記載の方法において、前記リモート・ストレージ・データー集合が、前記ローカル・サービスにおける差分ストレージから判定される、方法。
【発明の詳細な説明】
【背景技術】
【０００１】
[0001]  コンピューターおよび計算システムは、現代生活の殆どあらゆる面に影響を及ぼしている。コンピューターは、仕事、リクリエーション、健康管理、輸送、娯楽、家事管理等に全般的に関与する。
【０００２】
[0002]  更に、計算システムの機能性は、ネットワーク接続を介して他の計算システムに相互接続する計算システムの能力によって強化することができる。ネットワーク接続は、有線またはワイヤレス・イーサネット（登録商標）、セルラ接続、あるいはシリアル、パラレル、ＵＳＢ、または他の接続を介したコンピューター対コンピューター接続も含むことができるが、これらに限定されるのではない。これらの接続は、計算システムが他の計算システムにおけるサービスにアクセスすること、そして他の計算システムからアプリケーション・データーを素早く効率的に受信することを可能にする。
【０００３】
[0003]  これらの接続は、計算システムが他の計算システムにおけるサービスにアクセスすること、そして他の計算システムからアプリケーション・データーを素早く効率的に受信することを可能にする。更に、相互接続された計算システムは、クラスタ計算システムを実現するために使用することができる。クラスタ計算システムでは、様々な離散システムが一緒に動作して、全体としてクラスタに割り当てられた計算タスクを遂行する。このようなシステムには、クラウドに展開されるクラスタの全部を有するものまたは一部を有するものもある。クラウド・コンピューティング(cloud computing)は、計算リソースを、配信可能な製品ではなくサービスとして提供することを可能にする。具体的には、計算パワー、ソフトウェア、情報等が、インターネットのようなネットワークを通じて提供される（例えば、貸与契約によって）。
【０００４】
[0004]  クラウド・コンピューティングを使用するためには、ユーザーは、Microsoft（登録商標）CorporationからのWindows Azure（登録商標）、またはWashington州SeattleのAmazon.com Inc.から入手可能なAmazon EC2のようなクラウド・システムに彼らのデーターをアップロードする。次いで、クラウド・システムにおいて、ユーザーがアップロードしたデーターを使用して、このユーザーのために仮想機械が設定される。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
[0005]  仮想ハード・ディスクをアップロードするのは、時間がかかるタスクになることがある。オペレーティング・システムのイメージのために、１０ＧＢ以上が転送されるのが通例である。多くの場合、ディスクは追加データーによって後にリフレッシュされる。リフレッシュは、例えば、オペレーティング・システムの部分置換(patching)、アプリケーションの更新、およびブート問題の解決(troubleshooting)を含むことができる。例えば、ネットワークの帯域幅を保存するために、元のデーターが再送信されない場合もある。
【０００６】
[0006]  本願において特許請求する主題は、いずれかの欠点を解決する実施形態にも、以上で説明したような環境のみにおいて動作する実施形態にも限定されない。逆に、この背景は、本明細書において説明する実施形態を実施することができる技術分野の一例を例示するために提示されるまでである。  
【課題を解決するための手段】
【０００７】
[0007]  本明細書において例示する一実施形態は、リモート・ストレージ・データー集合を更新する方法を目的とする。この方法は、ローカル・サービスから、リモート・サービスにおいて存在するかもしれないリモート・ストレージ・データー集合のヒントを供給するアクトを含む。リモート・サービスから、リモート・ストレージ・データー集合がリモート・サービスに存在するという指示を受ける。この方法は、リモート・ストレージ・データー集合をリモート・サービスにおいて、このリモート・ストレージ・データー集合のコピーにコピーすることを要求するアクトを含む。リモート・ストレージ・データー集合のコピーに適用する変更をリモート・サーバに送る。
【０００８】
[0008]  この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するときに補助として使用されることを意図するのでもない。
【０００９】
[0009]  追加の特徴および利点は、以下に続く説明において明記され、更に部分的にその説明から自明であり、あるいは本明細書における教示の実施によって習得することもできる。本発明の特徴および利点は、添付した特許請求の範囲において特定的に指摘される手段(instruments)およびコンビネーションによって実現し取得することができる。本発明の特徴は、以下の説明および添付した特許請求の範囲から一層明白となり、または以下に明記する本発明の実施によって習得することもできる。
【図面の簡単な説明】
【００１０】
[0010]  以上で列挙した利点および特徴、ならびにその他の利点および特徴を得ることができるやり方について説明するために、以上で端的に説明した本主題の更に特定的な説明を、添付図面において示される具体的な実施形態を参照して示す。これらの図面は典型的な実施形態を図示するのであり、したがって範囲を限定するように解釈してはならないことを理解した上で、添付図面の使用によって、更に具体的にそして詳細に実施形態について説明する(described and explained)。
【図１】図１は、差分仮想ハード・ディスクを示す。
【図２】図２は、スパースネス(sparseness)最適化を含む仮想ハード・ディスクおよび スパースネス 最適化がない仮想ハード・ディスクを含む、仮想ハード・ディスクの表現を示す。
【図３】図３は、ローカル・サービスにおける仮想ハード・ディスク、およびリモート・サービスにおける対応するブロブを示す。
【図４】図４は、リモート・ストレージ・データー集合を更新する方法を示す。
【図５】図５は、リモート・ストレージ・データー集合を更新する他の方法を示す。
【発明を実施するための形態】
【００１１】
[0016] この説明およびそれに続く特許請求の範囲において、「クラウド・コンピューティング」とは、管理の手間またはサービス・プロバイダの仲介を減らしつつ、プロビジョニングおよび解放することができる構成可能な計算リソース（例えば、ネットワーク、サーバー、ストレージ、アプリケーション、およびサービス）の共有プールに対する、遍在的で便利なオンデマンド・ネットワーク・アクセスを可能にするモデルと定義することとする。クラウド・モデルは、種々の特性（例えば、オンデマンド・セルフサービス、高帯域ネットワーク・アクセス、リソース・プーリング（resource pooling）、ラピッド・エラスティシティ（rapid elasticity）、メジャード・サービス（measured service)等）、サービス・モデル（例えば、サービスとしてのソフトウェア（「ＳａａＳ」）、サービスとしてのプラットフォーム（「ＰａａＳ」）、サービスとしてのインフラストラクチャ（「ＩａａＳ」）、および展開モデル（例えば、プライベート・クラウド、コミュニティ・クラウド、公開クラウド、混成クラウド等）で構成することができる。
【００１２】
[0017]  Windows Azure（登録商標）クラウドのようなクラウド・システムは、本来差分ディスク技術をサポートしない。このため、反復アップロードのための最適化は、ツーリング(tooling)によって実行されればよい。差分ディスクをローカルにオンプレミス(on-premise)で利用し、クラウド・ストレージ・プリミティブ(cloud storage primitives)を利用し、そしてクラウド・ベースのイメージ・リポジトリーのセマンティクスを利用することによって、アップロード・ツールがパッチ(patch)、更新、または他のデーター最小化アップロード能力を可能にすることができる。
【００１３】
[0018]  これより一例を例示する。ここで図１を参照すると、ユーザーはローカル・サービス２５０においてファイル１０２−Ａをローカルにオンプレミスで作成し、アップロード・ツールを使用することによって、それをブロブ２０２−Ａとしてリモート・サービス２５２にアップロードする。後に、ユーザーはコンテンツをリフレッシュすることを望む。最初に、ユーザーはファイル１０２−Ｂおよび１０２−Ｃを、それぞれ、差分ディスクとしてファイル１０２−Ａおよび１０２−Ｂ上に作成する。差分ディスク・フォーマットについては、以下で更に詳しく論ずる。しかしながら、図示する例では、階層的差分構造は、リモート・サービスにおけるブロブに対応するエレメントを含むことができる。例えば、ディスク１０２−Ａを含むレベルはブロブ２０２−Ａに対応する。ユーザーがアップロード・ツールを呼び出すとき、ユーザーはブロブ２０２−Ａの位置をヒントとして供給する。リモート・サービス２５２は、ブロブ２０２−Ａの存在を示すことができる。その結果、アップロード・ツールは、ブロブ２０２−Ａをブロブ２０２−Ｃに離れてコピーすることによってブロブ２０２−Ｃを作成する処理に進み、次いでファイル１０２−Ｂおよび１０２−Ｃの差分コンテンツだけをアップロードする。具体的には、ブロック１０４−２Ｂ、１０４−３Ｃ、１０４−４Ｂをアップロードする。その実際の効果は、ヒントを使用せずにそしてファイルの階層を平面化することによって単にファイル１０２−Ｃの全体をアップロードすることにより、アップロードが行われたかのようにブロブ２０２−Ｃが同じコンテンツを含むということである。この時点において、ローカル・サービス２５０における階層差分構造は、リモート・サービス２５２におけるブロブ２０２−Ｃに対応する、ディスク１０２−Ｃを含む階層レベルも含む。
【００１４】
[0019]  実施形態は、仮想ハード・ディスク・フォーマットのサポートも含むことができる。例えば、差分ディスク・フォーマットを解析し、所与のデーター・ブロックの起源を識別し、次いでしかるべき最適化することによって、リモート仮想ハード・ディスクを反復的に組み立てる能力が可能になる。
【００１５】
[0020]  実施形態は、ストレージを利用する機能性も含むことができる。直前の例のように、実施形態は、ブロブ２０２−Ａのコンテンツでブロブ２０２−Ｃを初期化し、次いでブロブ２０２−Ｃを変化させる(mutate)ことができる。
【００１６】
[0021]  実施形態は、完全性を確保する機能性を含むこともできる。ディスクの完全性を確保することは、費用がかかるライブ・サイト(live-site)の調査を回避するのに有用である。これより、パッチ動作の完全性を確保するために実施形態において使用することができる２つのメカニズムについて例示する。最初に、実施形態は、ローカル・ベース・ファイル（例えば、以上で図示した例では１０２−Ａ）がアップロードされて以来変化していないことをチェックする。これは、実施形態では、ローカル・ファイルのハッシュを計算し、このローカル・ファイルが最初にブロブ２０２−Ａとしてアップロードされたときに作成され記録されたハッシュと比較することによって実行することができる。ローカル・ファイルが最初にアップロードされたときに作成され記録されたハッシュは、リモート・ブロブ（即ち、ブロブ２０２−Ａ）においてメタデーターとして格納される。
【００１７】
[0022]  第２に、実施形態はクラウド・イメージ・レポジトリーのセマンティクスを拠り所にすることもできる。所与のディスク・ファイルがクラウドにアップロードされるとき、仮想機械のプロビジョニングにおける使用のために、プラットフォームと共に「イメージ」として登録される。プラットフォームは、その時点後に、ブロブ上に排他的なリース(lease)を保持して、読み取り専用セマンティク(read-only semantic)を確保する。すると、ローカル・サービス２５０におけるアップロード・ツールは、ブロブが変化していないことを確認することができる。
【００１８】
[0023]  種々のディスク・フォーマットを、クラウド・サービスに対して規定されたフォーマットに変換するツールが存在するが、本明細書において説明する実施形態には、プラットフォーム供給アップロード・ツールに変換を統合するものもある。この変換は、アップロードが進む間に直接行われる。これは、ユーザーに効率および便利さを提供することができる。
【００１９】
[0024]  仮想ハード・ディスクの一面は、コンテンツが通例スパースである(sparse)ということである。即ち、情報の仮想ストリームは大きな空のポケットを含む。一例を図２に示す。図２は、仮想ハード・ディスク１０２の表現を示す。仮想ハード・ディスク１０２は、５つのブロック１０４−１〜１０４−５を含む。これらのブロックの内３つ、１０４−１、１０４−２、および１０４−５はデーターを収容する。他の２つのブロック１０４−３および１０４−４はヌル・データーを収容する。スパースネス最適化を実行して、最適化されない仮想ハード・ディスク１０２の代わりに、仮想ハード・ディスク１０２’を動的仮想ハード・ディスクとして作成することができる。仮想ハード・ディスク１０２’は、データーを収容する３つのブロック１０４−１、１０４−２、および１０４−５と、ブロック割り当て表（ＢＡＴ）１０６とを含む。ＢＡＴ１０６は、どのブロックがデーターを収容するか、および／またはどのブロックがヌルを収容するか注記することによって、仮想ハード・ディスク１０２の実際の構造を反映するために使用することができる。仮想ハード・ディスク１０２’は、ローカル・サービス２５０（図１に示したローカル・サービス２５０等）に格納することができる。
【００２０】
[0025]  これより図３を参照すると、リモート・ブロブ２０２も同様にスパースである。何故なら、規定フォーマットはディスク・ページのブロブ・ページの１対１マッピングに基づくからである。しかしながら、リモート・サービス２５２におけるリモート・ブロブは、スパースネスに対して最適化されておらず、逆に、データーを収容するブロック１０４−１、１０４−２、および１０４−５に対応するブロック２０４−１、２０４−２、および２０４−５、ならびに最適化されて仮想ハード・ディスク１０２’では除去されたブロック１０４−３および１０４−４に対応するヌルを収容するブロック２０３−４および２０４−４も含む。
【００２１】
[0026]  図３は、動的仮想ハード・ドライブを使用してブロックをアップロードする例を示す。先に注記したように、動的ＶＨＤに対して、動的フォーマットは、ＢＡＴとして知られるデーター構造を含む。ＢＡＴ１０６は、仮想ブロックの物理ブロックに対するマップを提供する。このマップは、全ての仮想ブロックが物理データーを有するのではなくそして空であると判断されるのではないことから、スパースである。仮想ストリームの実施態様(implementation)は、ＢＡＴ１０６に基づいて、スパースネス・データーを表出させる。仮想ストリームをシークして読み出すときも、ＢＡＴ１０６は同様に使用される。つまり、図３に示すように、ＢＡＴ１０６によって示されるようにデーターを収容するブロック１０４−１、１０４−２、および１０４−５を送るために、ＨＴＴＰ  ＰＵＴ要求２５４を使用することができる。
【００２２】
[0027]  変換およびアップロードをローカル・サービス２５０に統合することによって、サポートされる入力フォーマットでＢＡＴ１０６に格納されたスパースネス・メタデーターが、アップロード性能を向上させるために利用される。具体的には、スパースネス・メタデーターは、どのデーターがローカル・サービス２５０からリモート・クラウド・サービス２５２にアップロードされるかについて、最適化するために使用することができる。仮想ハード・ディスク１０２全体をアップロードしなければならない代わりに、ブロック１０４−１、１０４−２、１０４−５のような、データーを収容する個々のブロックを、リモート・クラウド・サービス２５２におけるブロブ２０２にアップロードすることができる。例えば、ブロック１０４−１をブロック２０４−１にアップロードし、ブロック１０４−２をブロック２０４−２にアップロードし、そしてブロック１０４−５をブロック２０４−５にアップロードするために、１つ以上のＨＴＴＰ「ＰＵＴ」要求２５４を使用することができる。
【００２３】
[0028]   また、オンザフライ変換(on-the-fly conversion)は、それ以外では遅くなるアップフロント動作(up-front operation)を回避して、並列性(parallelism)も改良する。例えば、ブロック１０４−１、１０４−２、および１０４−５は、これらのブロックを並列にアップロードすることができるようにそれら自体の個々のＰＵＴ要求２５４を使用して、各々、リモート・サービス２５２およびブロブ２０２にアップロードすることができる。
【００２４】
[0029] 更に、ユーザーは、彼らの仮想化の必要性に対して、「固定」仮想ハード・ディスク（ＶＨＤ）フォーマット（仮想ハード・ディスク１０２によって示されるもの等）を使用しないのが通例である。「動的」および「差分」ディスクＶＨＤフォーマットが使用される方が多い。動的および差分ディスクは、多数の取り回し性の恩恵(manageability benefits)をもたらし、ワシントン州、RedmondのMicrosoft Corporationから入手可能なHyper-VおよびWindows（登録商標）７のような種々のツールおよびオペレーティング・システムにうまく統合される。動的ワード差分ディスク(dynamic word differencing disk)を、仮想ディスク１０２によって例示されるような固定ディスクに変換するオンフロント変換は遅く、広いローカル・ディスク空間を必要とし、重複性アーチファクトを生ずる。動的および差分ディスク・フォーマットから、リモート・ブロブに適したフォーマットへの変換をアップロード・ツールに統合することによって、ユーザーは彼らが好むディスク・フォーマットで直接作業することができる。
【００２５】
[0030]   このように、実施形態は、ネーティブ・クラウド・フォーマットへの自動変換による、フォーマット認識アップロードを実現することができる。加えてまたは代わりに、実施形態はスパースネスを端末間で保持することができる。具体的には、図３に示すアップロード・メカニズムを利用することができる。
【００２６】
[0031]   再度図１を参照して、追加の詳細を示す。図１はローカル・サービス２５０を示す。ローカル・サービス２５０は、例えば、企業によって維持されるオンプレミス・サービスであってもよい。ローカル・サービス２５０は、多数の入力を受ける。ローカル・サービス２５０は、Hyper-V、Windows７（登録商標）によって生成されるような仮想ハード・ディスク（ＶＨＤ）ファイル１０２−Ｃを参照する、ローカル・ファイル・パス、または他の互換ツールを入力として受ける。ローカル・サービス２５０は、２０２−Ａにおいて示すブロブのような、リモート・サービス２５２におけるブロブを参照する、リモート・ブロブＵＲＩを、ヒント入力として受ける。この入力は、クラウド・システムのイメージ・レポジトリーに登録されたリモート・ブロブを参照する、リモート・イメージ名であってもよい。このレポジトリーは、イメージとして登録されたブロブに対して、読み取り専用セマンティック(read-only semantic)を実施する(enforce)。実施形態では、読み取り専用セマンティックがあるブロブだけが有効な入力と見なされる。ここでは、この入力ブロブを「ベース」と呼ぶ。
【００２７】
[0032]  実施形態は、「ベース」リモート・ブロブを検査するように構成されたモジュールを含むことができる。このリモート・ブロブは、「固定」−フォーマット仮想ハード・ディスクであると判断される。このリモート・ブロブのフッターを解析して、仮想ハード・ディスク「ＩＤ」フィールドを得る。この「ＩＤ」は、仮想ハード・ディスク・ファイルの識別(identity)を表し、後に対応するローカル・ファイルを識別するために使用される。以前のアップロードの間に設定された、ブロブのＭＤ５ヘッダーのようなヘッダーも得られる。
【００２８】
[0033]   ローカル・サービス２５０は、ストレージ信任状を受ける。このストレージ信任状は、ローカル・サービス２５０がリモート・サービス２５２においてリモート・ストレージ・アカウントで認証することを可能にする。
【００２９】
[0034]   実施形態は、ＶＨＤファイル・フォーマットを解析するために、ローカル・サービス２５０において１つ以上のモジュール２５６を含むこともできる。１つ以上のモジュール２５６は、ＶＨＤ１．０仕様のようなＶＨＤ仕様にしたがって、ローカル・ファイルのヘッダー（ＢＡＴ１０６−Ａのような）およびフッターを解析する。
【００３０】
[0035]   ここに示す例では、ＶＨＤは差分ＶＨＤに分類される。仮想ストリームとして知られる内部抽象化(internal abstraction)が生成される。仮想ストリームは、図２に示した仮想ハード・ディスク１０２によって例示されるフォーマットのような、ネーティブ・フォーマットとした仮想ハード・ディスクのスパースネス、シーク可能ビューを与える。入力フォーマット考慮(consideration)が、仮想ストリーム抽象化の後ろにカプセル化される。スパースネス情報は、重要なデーターを収容すると判断されるブロック・アドレスのリストとして露出される。例えば、図２に示すように、ＢＡＴ１０６は、ブロック１０４−１、１０４−２、および１０４−５を、重要なデーターを収容するものとして識別することができる。
【００３１】
[0036] 図１は、どのブロックをアップロードするか決定するために差分ＶＨＤ機能性を使用する例を示す。差分ＶＨＤでは、差分フォーマットは動的フォーマット（図２および図３に示した１０２’で例示される動的フォーマットのような）に対する拡張である。これは、「ペアレント・ロケーター」構造を含み、ローカル・ペアレント・ファイルの位置を与える。ＢＡＴ１０６−Ａが所与の仮想ブロックに対するマッピングを含まないとき、ペアレント・ファイルがその情報を供給することができる。ペアレント・ファイル自体は、任意のタイプのＶＨＤファイルであってよい。しかしながら、ペアレントが差分ファイルである場合、本プロセスは再帰する(recurse)。仮想ストリームの実施態様は、このプロセスをカプセル化する。スパースネス・データーは、ペアレント・ツリー全体の連合(union)に基づく。
【００３２】
[0037]   リモート・ブロブ２０２−Ａは、同様に入力ファイル１０２−Ｃの祖先であるローカル仮想ハード・ディスク・ファイル１０２−Ａに対応すると判断される。リモート・ブロブ２０２−Ａに対応するペアレント・ファイル１０２−Ａを突き止めるために、ペアレント・ツリーが横断される。ペアレント・ファイル１０２−Ａは、先に説明したベース・ブロブから得られる「ＩＤ」によって識別される。尚、ペアレント・ファイル１０２−Ａは入力ファイル１０２−Ｃの直接のペアレントである必要はないことを注記しておく。いずれの先祖深度でも容認可能である。
【００３３】
[0038]  実施形態は、ペアレント・ファイル１０２−Ａの有効性を判断するように構成されたモジュールも含むことができる。プロセス全体の完全性を確保するために、ペアレント・ファイル１０２−ＡのＭＤ５ハッシュのようなヘッダーが計算され、先に説明したようにリモート・ブロブ２０２−Ａから得られるそれと比較される。ペアレント・ファイル１０２−Ａのハッシュは、ペアレント・ファイル１０２−Ａ自体のハッシュではなく、ペアレント・ファイル１０２−Ａに対応する仮想ストリームに基づいて計算される。何故なら、リモート・ブロブに対するＭＤ５ハッシュはその実際のコンテンツを反映するからである。
【００３４】
[0039] 実施形態は、どのブロックをアップロードすべきか決定するように構成されたモジュールも含むことができる。どのブロックをアップロードすべきかの決定は、ローカル・サービス２５０において識別される差分に基づくことができる。
【００３５】
[0040]  図１は、仮想ハード・ディスク・ファイル１０２−Ｂのペアレント・ファイルである仮想ハード・ディスク・ファイル１０２−Ａを示す。一方、仮想ハード・ディスク・ファイル１０２−Ｂは、仮想ハード・ディスク・ファイル１０２−Ｃのペアレント・ファイルである。ハード・ディスク・ファイル１０２−Ｂおよび１０２−Ｃは、それらのペアレント・ファイルとの差分を含むが、それらのペアレント・ファイルやもっと前の先祖ファイルに既に存在する冗長データーではない。ペアレントおよびチャイルドにおいて同じであるデーターでは、その情報のペアレントまたはもっと前の先祖を単純に引用することができる。図１に示す例では、陰影が付いたブロックは特定のファイルに一意のデーターを表し、一方陰影がないブロックは、いずれかの階層的ペアレント（先祖を含む）ファイル（１つまたは複数）において発見することができるデーターを表す。例えば、ブロック１０４−２Ｂは、ブロック１０４−２Ａとは異なるデーターを収容する。しかしながら、ブロック１０４−１Ｂおよびブロック１０４−１Ｃは、ブロック１０４−１Ａにおけると同じデーターを収容する。更に、ブロック１０４−１Ｂおよび１０４−１Ｃは、物理的にデーターを収容せず、代わりに、実際のデーターを発見することができるペアレント・ファイル１０２−Ａおよびブロック１０４−１Ａを参照する。
【００３６】
[0041] また、差分フォーマットは、図１に示したようにファイルの１つ以上に対してＢＡＴを含んでもよいことも注記しておく。例えば、図１は、ＢＡＴ１０６−Ａ、１０６−Ｂ、および１０６−Ｃを示す。差分フォーマット・ディスクの階層的性質のために、ＢＡＴ１０６−Ａに収容されたスパースネス・データーは、チャイルド・ファイル１０２−Ｂおよび１０２−Ｃに保存される。差分ディスクは、所与のブロックがそのペアレントのそれに取って代わることを示すために、ＢＡＴを含む。
【００３７】
[0042]   仮想ハード・ディスク・ファイル１０２−Ｃをリモート・サービス２５２、そしてブロブ２０２−Ｃにアップロードする前に、リモート・ブロブ２０２−Ｃは初期化される。実施形態は、リモート・ブロブ２０２−Ｃを初期化するように構成されたモジュールを含むこともできる。更新またはパッチ動作が必ずしもベース・ブロブ２０２−Ａを変化させるとは限らない。代わりに、これは、新たなブロブ２０２−Ｃを作成し、その初期コンテンツがベース・ブロブ２０２−Ａからコピーされる。このコピーは、リモート・ストレージ・サービスの能力を使用して作成することができる。ベース・ブロブ２０２−Ａをコピーした後、別の初期化が実行される。直前のステップから生成されたリストにおけるブロック毎に、つまり、アップロードしようとするブロック毎に、実施形態はリモート・ブロブ２０２−Ｃの対応するブロックを消去する。これは、通常の「レジューム」機能性を容易にするために行うことができ、どのブロックが潜在的に未処理であるか判断するためにスパースネス・データーを使用する。ブロックを消去するのは、リモート・ストレージ・サービスの能力であってもよい。ブロックを消去することによって、リモート・ブロブのスパースネスが高められる。
【００３８】
[0043] これより、ファイル１０２−Ａとファイル１０２−Ｃとの間の差分を転送するために変化およびパッチの転送について示すと、ブロック１０４−２Ｂがブロック２０４−２Ｃに移動させられ、ブロック１０４−３Ｃがブロック２０４−３Ｃに移動させられ、ブロック１０４−４Ｂがブロック２０４−４Ｃに移動させられる。重要なブロックのリスト、仮想ストリーム抽象化自体は、多数の作業スレッド(worker thread)間で細分化される。各スレッドは、割り当てられたブロックをシークし、このブロックを読み出し、次いでＨＴＴＰ  ＰＵＴ要求をリモート・ストレージ・サービスに発行する処理を進める。ＰＵＴ要求は、ブロブ内のどこにブロックを置くべきか、ストレージ・サービスに示す範囲ヘッダーを含む。過渡エラー(transient error)から回復する(recover)ために、必要に応じて再試行が発行される。最終的に、全ての重要なブロックが転送され終えて、本プロセスは終了する。
【００３９】
[0044] 実施形態は、レジュームするように構成されたモジュールも含むことができる。アップロードが完了するのに何時間もまたは何日もかかるかもしれないとすると、クライアント・コード・コンポーネント(client-code component)がレジュームをサポートする。このレジューム・プロセスは、通常のアップロード・プロセスと同様に動作するが、既にアップロードされたブロックは、実質的なブロックの(substantial block)のリストから削除されることを除く。既にアップロードされたブロックのリストは、リモート・ストレージ・サービス２５２から得ることができる。アップロードのレジュームは、リモート・ストレージ・サービスに問い合わせてブロブについてのスパースネス情報を求めることに基づくとよい。先に得られたブロック・リストとのこれらのギャップの交点(intersection)が、残りの作業を表す。アップロードすることを意図するブロックを消去する初期化ステップが、この能力を可能にする。
【００４０】
[0045] 次に、以下の論述は実行することができる多数の方法および方法のアクトについて言及する。これらの方法のアクトは、ある順序で説明することができる、即ち、フロー・チャートにおいて特定の順序で行われるように示すことができるが、具体的に述べられなければ、または必要とされなければ、特定の順序は要求されない。何故なら、アクトが実行される前に完了した他のアクトに、このアクトは依存するからである。
【００４１】
[0046] これより図４を参照すると、方法４００が示されている。この方法は、リモート・ストレージ・データー集合を更新するアクトを含む。この方法は、ローカル・サービスから、リモート・サービスにおいて存在するかもしれないリモート・ストレージ・データー集合のヒントを供給するアクトを含む（アクト４０２）。例えば、ローカル・サービス２５０は、ブロブ２０２−Ａの位置というような、ブロブ２０２−Ａに関するヒントを供給するのでもよい。方法４００は、ローカル・サービスにおいて差分ストレージからリモート・ストレージ・データー集合を決定するときに実施するとよい。例えば、ローカル・システム２５０は、ファイルの階層構造を使用してファイル１０２−Ａを発見し、その情報をブロブ２０２−Ａに関するヒントとして使用することができる。
【００４２】
[0047]  更に、方法４００は、リモート・サービスにおいてリモート・ストレージ・データー集合が存在するという指示をリモート・サービスから受けるアクトも含む（アクト４０４）。例えば、リモート・サービス２５２は、ブロブ２０２−Ａの存在を示すことができる。
【００４３】
[0048]   更に、方法４００は、リモート・ストレージ・データー集合を、リモート・サービスにおいて、リモート・ストレージ・データー集合のコピーにコピーすることを要求するアクトも含む（アクト４０６）。この結果、ブロブ２０２−Ａがコピーされて、ブロブ２０２−Ｃを作成することができる。
【００４４】
[0049]   更に、方法４００は、リモート・ストレージ・データー集合のコピーに適用すべき変化を、リモート・サービスに送るアクトも含む（アクト４０８）。例えば、図１に示したように、ファイル１０２−Ａとファイル１０２−Ｃとの間の差分を判定することができる。方法４００は、ローカル・サービスにおける差分ストレージによって変化を判定するときに実施することができる。具体的には、ファイル１０２−Ｃにおけるブロック１０４−１Ｃ、１０４−２Ｃ、１０４−４Ｃ、１０４−５Ｃが、ファイル１０２−Ａにおける対応するブロックと異なることを判定することができる。これは、例えば、ローカル・サービス２５０において利用可能な差分ディスク機能性を使用することによって、判定することができる。識別された差分は、コピーされたブロブ２０２−Ｃに適用するために、リモート・サービス２５２に送ることができる。実施形態では、ブロック毎に１つずつ、個別のＨＴＴＰ  ＰＵＴ要求を使用して、ブロックを送ることもできる。
【００４５】
[0050]  更に、方法４００は、リモート・サービスにデーター集合完全性データーを要求し、このデーター集合完全性データーをローカル完全性データーと比較するアクトも含むことができる。例えば、実施形態は、データー集合のハッシュ（ｍｄ５ハッシュのような）を検査して、データー集合の完全性を判定することもできる。前述のように、ファイル１０２−Ａのハッシュをブロブ２０２−Ａのハッシュと比較するのでもよい。
【００４６】
[0051] 方法４００の実施形態は、リモート・データー集合が発見されるまで反復して実行することができる。具体的には、ローカル・サービス２５０が、図１に示したようなファイル階層を含むと仮定し、更に、ブロブ２０２−Ｃが作成される前に以下のことが起こったと仮定する。ローカル・サービス２５０は、最初に、しかるべきヒントを送ることによって、ファイル１０２−Ｃに対応するブロブを識別しようとすることができる。これが成功しなかった場合、ローカル・サービス２５０は、しかるべきヒントを送ることによって、ファイル１０２−Ｂに対応するブロブを識別しようとすることができる。これが成功しなかった場合、ローカル・サービスは、ローカル・ファイル１０２−Ａに対応するブロブを識別しようとすることができる。図１に示すように、この試行は成功する。
【００４７】
[0052]   これより図５を参照すると、方法５００が示されている。方法５００は、リモート・ストレージ・データー集合を更新するアクトを含む。方法５００は、リモート・サービスにおいて、リモート・サービスにおいて存在するかもしれないリモート・ストレージ・データー集合のヒントを受けるアクトを含む（アクト５０２）。例えば、図１に示したように、リモート・サービス２５２が、リモート・サービス２５２において種々のブロブの位置に関するヒントを受けることもできる。図示する例では、ブロブ２０２−Ａの位置に関するヒントを受ける。
【００４８】
[0053] 更に、方法５００は、ヒントに基づいて、リモート・ストレージ・データー集合がリモート・サービスに存在すると判定するアクトを含む（アクト５０４）。
[0054]   更に、方法５００は、リモート・サービスにおけるリモート・ストレージ・データー集合を、リモート・ストレージ・データー集合のコピーにコピーするアクトを含む（アクト５０６）。例えば、図１に示したように、ブロブ２０２−Ａを２０２−Ｃにおけるブロブにコピーすることができる。
【００４９】
[0055]   更に、方法５００は、リモート・サービスにおけるリモート・ストレージ・データー集合のコピーに適用すべき変化を、ローカル・サービスから受けるアクトを含む（アクト５０８）。例えば、図１に示すように、ローカル・サービス２５０は、ファイル１０２−Ｃにおけるファイル１０２−Ａとの間の差分を送ることもできる。本明細書において既に示したように、データーの個々のブロックを送り、ブロブ２０２−Ｃにおける該当するブロックに適用すればよい。
【００５０】
[0056] つまり、方法５００は、リモート・ストレージ・データー集合に変化を適用するアクトを更に含む（アクト５１０）。
[0057] 更に、方法５００は、リモート・ストレージ・データー集合に対して、リモート・サービスからデーター集合完全性データーを提供するアクトを含むこともできる。例えば、方法５００は、リモート・サービスからのデーター集合完全性データーおよびローカル完全性データーが、ｍｄ５ハッシュのようなハッシュを含むときに実施することができる。これらのハッシュは、ローカル・サービス２５０におけるファイルがリモート・サービス２５２において該当するブロブと一致することを確認する(ensure)ために使用することができる。
【００５１】
[0058]   更に、以上の方法は、１つ以上のプロセッサと、コンピューター・メモリーのようなコンピューター読み取り可能媒体とを含むコンピューター・システムによって実施することもできる。具体的には、コンピューター・メモリーは、コンピューター実行可能命令を格納することができ、１つ以上のプロセッサによってこれらの命令が実行されると、実施形態において列挙したアクトのような、種々の機能を実行させる。
【００５２】
[0059]   本発明の実施形態は、以下で更に詳しく論ずるように、コンピューター・ハードウェアを含む特殊目的コンピューターまたは汎用コンピューターを含むまたは利用することができる。また、本発明の範囲内の実施形態は、コンピューター実行可能命令および／またはデーター構造を搬送または格納するために物理的または他のコンピューター読み取り可能媒体も含む。このようなコンピューター読み取り可能媒体は、汎用または特殊目的コンピューター・システムによってアクセスすることができる入手可能なあらゆる媒体とすることができる。コンピューター実行可能命令を格納するコンピューター読み取り可能媒体は、物理的記憶媒体である。コンピューター実行可能命令を搬送するコンピューター読み取り可能媒体は、伝送媒体である。つまり、一例として、そして限定ではなく、本発明の実施形態は少なくとも２つの全く異なる種類のコンピューター読み取り可能媒体、即ち、物理的コンピューター読み取り可能記憶媒体および伝送コンピューター読み取り可能媒体を含むことができる。
【００５３】
[0060]  物理的コンピューター読み取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク・ストレージ（ＣＤ、ＤＶＤ等のような）、磁気ディスク・ストレージまたは他の磁気記憶デバイス、あるいはコンピューター実行可能命令またはデーター構造の形態で所望のプログラム・コード手段を格納するために使用することができ、汎用または特殊目的コンピューターによってアクセスすることができる他のあらゆる媒体も含む。
【００５４】
[0061] 「ネットワーク」とは、コンピューター・システムおよび／またはモジュールおよび／または他の電子デバイス間における電子データーの移送を可能にする１つ以上のデーター・リンクとして定められる。情報がネットワークまたは他の通信接続（ハードワイヤ、ワイヤレス、あるいはハードワイヤまたはワイヤレスの組み合わせ）を通じてコンピューターに転送または提供されるとき、コンピューターはこの接続を伝送媒体として適正に見なす。伝送媒体は、コンピューター実行可能命令またはデーター構造の形態で所望のプログラム・コード手段を搬送するために使用することができ、汎用コンピューターまたは特殊目的コンピューターによってアクセスすることができるネットワークおよび／またはデーター・リンクを含むことができる。以上のものの組み合わせも、コンピューター読み取り可能媒体の範囲内に含まれる。
【００５５】
[0062]   更に、種々のコンピューター・システム・コンポーネントに到達すると、コンピューター実行可能命令またはデーター構造の形態のプログラム・コード手段を自動的に伝送コンピューター読み取り可能媒体から物理的コンピューター読み取り可能記憶媒体に（またはその逆に）転送することができる。例えば、ネットワークまたはデーター・リンクを通じて受信されたコンピューター実行可能命令またはデーター構造を、ネットワーク・インターフェース・モジュール（例えば、「ＮＩＣ」）内にあるＲＡＭにバッファーし、最終的にコンピューター・システムのＲＡＭおよび／またはコンピューター・システムにおける揮発性でないコンピューター読み取り可能物理的記憶媒体に転送することができる。このように、コンピューター読み取り可能物理的記憶媒体は、伝送媒体も利用するコンピューター・システム・コンポーネント（または主に利用するコンピューター・システム・コンポーネントであっても）含むことができる。
【００５６】
[0063] コンピューター実行可能命令は、例えば、汎用コンピューター、特殊目的コンピューター、または特殊目的処理デバイスにある機能または機能の一群を実行させる命令およびデーターを含む。コンピューター実行可能命令は、例えば、バイナリー、アセンブリー言語のような中間フォーマット命令、またはソース・コードであってもよい。構造的特徴および／または方法論的アクトに特定的な文言で本主題について説明したが、添付した特許請求の範囲に定められる主題は、必ずしも以上で説明した特徴やアクトには限定されないことは理解されてしかるべきである。逆に、説明した特徴およびアクトは、特許請求の範囲を実現する形態例として開示されたまでである。
【００５７】
[0064]  尚、本発明は、パーソナル・コンピューター、デスクトップ・コンピューター、ラップトップ・コンピューター、メッセージ・プロセッサ、ハンドヘルド・デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースまたはプログラマブル消費者用電子機器、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター、移動体電話機、ＰＤＡ、ページャー、ルータ、スイッチ等を含む多くのタイプのコンピューター・システム構成を有するネットワーク計算環境において実施できることは、当業者には認められよう。また、本発明は、分散型システム環境において実施することもでき、この場合、ネットワークを通じてリンクされる（ハードワイヤ・データー・リンク、ワイヤレス・データー・リンク、またはハードワイヤおよびワイヤレス・データー・リンクの組み合わせのいずれかによって）ローカルおよびリモート・コンピューター・システムの双方がタスクを実行する。分散型システム環境では、プログラム・モジュールがローカルおよびリモート双方のメモリー記憶デバイスに配置されてもよい。
【００５８】
[0065] 代わりに、または加えて、本明細書において説明した機能性は、少なくとも部分的に、１つ以上のハードウェア・ロジック・コンポーネントによって実行することができる。例えば、そして限定ではなく、使用することができる例示的なタイプのハードウェア・ロジック・コンポーネントには、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、プログラム特定集積回路（ＡＳＩＣ）、プログラム特定標準製品（ＡＳＳＰ）、チップ上システム・システム（ＳＯＣ）、複合プログラマブル・ロジック・デバイス（ＣＰＬＤ）等が含まれる。  
【００５９】
[0066] 本発明は、その主旨や特性から逸脱することなく、他の特定形態においても具体化することができる。説明した実施形態は、あらゆる観点において、限定的ではなく例示的であると解釈されることとする。したがって、本発明の範囲は、以上の説明ではなく、添付した特許請求の範囲によって示される。特許請求の範囲の均等の意味および範囲に該当する全ての変更は、その範囲に包含されるものとする。
【図１】
2015519651.tif 000003
【図２】
2015519651.tif 000004
【図３】
2015519651.tif 000005
【図４】
2015519651.tif 000006
【図５】
2015519651.tif 000007
【国際調査報告】
2015519651.tif 000008
2015519651.tif 000009