JP2014526086A - ストレージゲートウェイ起動プロセス - Google Patents

Abstract

リモートサービスプロバイダへのゲートウェイを起動するための方法、装置、およびコンピュータがアクセス可能なストレージ媒体。ゲートウェイは、例えばリモートデータストアに顧客データを記憶するために、顧客ネットワーク上のプロセスとプロバイダと間のインターフェースとして機能する。ゲートウェイは、公開鍵、およびゲートウェイを説明するメタデータをプロバイダに送る。ゲートウェイは、プロバイダから起動鍵を受け取り、顧客ネットワーク上に該起動鍵を公表する。顧客は、鍵を取得し、該鍵を使用してプロバイダと通信して、ゲートウェイの名前を含む顧客情報を提供し、また、ゲートウェイの登録を許可する。プロバイダは、ゲートウェイに顧客情報を提供する。ゲートウェイは、顧客情報および鍵を使用して、プロバイダにセキュリティ証明書を要求する。プロバイダは、ゲートウェイにセキュリティ証明書を送る。ゲートウェイは、次いで、プロバイダを介して、顧客から構成情報を取得し得る。
【選択図】図１６Ａ

Description

多くの企業および他の組織は、コンピューティングシステムを（例えば、ローカルネットワークの一部として）同じ場所に配置するか、または代わりに（例えば１つ以上のプライベートもしくはパブリック中間ネットワークを介して接続される）複数の別々の地理的な場所に配置する等によって、それらの事業をサポートするために多数のコンピューティングシステムを相互接続する、コンピュータネットワークを運営する。例えば、膨大な数の相互接続されたコンピューティングシステムを収容するデータセンターは、単一の組織によって、およびそれを代表して運営されるプライベートデータセンター、ならびに顧客にコンピューティングリソースを提供する事業として事業体によって運営されるパブリックデータセンター等のように、一般化してきている。ネットワークアクセス、電力、および様々な顧客が所有するハードウェアの安全な導入設備を提供するパブリックデータセンターオペレータもあれば、ハードウェアリソースをそれらの顧客が利用できるようにすることも含む「フルサービス」設備を提供するパブリックデータセンターオペレータもある。しかしながら、標準的なデータセンターの規模および範囲が増大するにつれて、物理的コンピューティングリソースをプロビジョニング、監督、および管理する作業は、ますます複雑になってきている。

商品ハードウェアのための仮想化技術の出現は、多様なニーズを伴う多数の顧客のための大規模なコンピューティングリソースを管理することに関して利益を提供しており、種々のコンピューティングリソースを複数の顧客が効率的かつ安全に共有することを可能にしている。例えば、仮想化技術は、単一の物理的コンピューティングマシンによってホストされる１つ以上の仮想マシンを各ユーザに提供することによって、単一の物理的コンピューティングマシンを複数のユーザの間で共有することを可能にし得、各仮想マシンは、ユーザが所与のハードウェアコンピューティングリソースの唯一のオペレータかつ管理者であるような幻想をユーザに提供する、別個の論理コンピューティングシステムとして作用するソフトウェアシミュレーションにする一方で、種々の仮想マシンの間でのアプリケーションの分離およびセキュリティも提供する。さらに、いくつかの仮想化技術は、複数の別個の物理的コンピューティングシステムに及ぶ複数の仮想プロセッサを伴う単一の仮想マシン等の、２つ以上の物理リソースに及ぶ仮想リソースを提供することができる。

別の例として、仮想化技術は、複数のデータストレージデバイスにわたって分散され得る仮想化データストアを各ユーザに提供することによって、データストレージハードウェアを、複数のユーザの間で共有することを可能にし得、各仮想化データストアは、ユーザがデータストレージリソースの唯一のオペレータおよび管理者であるような幻想をユーザに提供する、別個の論理データストアとして作用する。

ウェブサービス
従来のウェブモデルは、クライアントが、ウェブブラウザ等のＨＴＴＰクライアントプログラムを介して、ウェブリソース（例えば、アプリケーション、サービス、およびデータ）にアクセスすることを可能にする。ウェブサービスと称される技術が、ウェブリソースへのプログラム的アクセスを提供するために開発された。ウェブサービスは、ウェブサービスインターフェースを介したウェブサーバシステム等のウェブ接続されたコンピュータ上でホストされる、技術プラットフォーム（例えば、アプリケーションおよびサービス）およびデータ（例えば、製品カタログおよび他のデータベース）を含む、ウェブリソースへのプログラム的アクセスを提供するために使用され得る。概して、ウェブサービスインターフェースは、いくつかのサービスを行うように要求するクライアントとサービスプロバイダとの間の通信のために、標準クロスプラットフォームのＡＰＩ（アプリケーションプログラミングインターフェース）を提供するように構成され得る。いくつかの実現例において、ウェブサービスインターフェースは、サービス要求およびその要求に対する応答を説明する情報を含む文書またはメッセージの交換をサポートするように構成され得る。そのような文書またはメッセージは、例えばハイパーテキスト転送プロトコル（ＨＴＴＰ）等の標準化されたウェブプロトコルを使用して交換され得、また、例えば拡張マークアップ言語（ＸＭＬ）等のプラットフォームに依存しないデータフォーマットでフォーマットされ得る。

少なくともいくつかの実施形態による、例示的なサービスプロバイダおよび例示的なサービス顧客を含む、例示的なネットワーキング環境の高次ブロック図である。 少なくともいくつかの実施形態による、ストレージゲートウェイの例示的なアーキテクチャおよびその構成要素を図示する図である。 ストレージゲートウェイの実施形態が実現され得る例示的なネットワーク環境の高次ブロック図である。 少なくともいくつかの実施形態による、サービス顧客ネットワークとサービスプロバイダネットワーク上のストレージサービスとの間のインターフェースとして機能するサービス顧客ネットワークにおけるオンサイトのストレージゲートウェイを含む、例示的なネットワーク環境のブロック図である。 少なくともいくつかの実施形態による、ストレージサービスおよびハードウェア仮想化サービスをサービスプロバイダの顧客に提供する、例示的なサービスプロバイダのブロック図である。 ストレージゲートウェイの実施形態がキャッシュされたゲートウェイとして構成される例示的なネットワーク環境のアーキテクチャおよびその中のデータフローを大まかに図示する、高次ブロック図である。 ストレージゲートウェイの実施形態がシャドウ化ゲートウェイとして構成される例示的なネットワーク環境におけるアーキテクチャおよびその中のデータフローを大まかに図示する、高次ブロック図である。 少なくともいくつかの実施形態による、例示的なネットワーク環境におけるシャドウ化ゲートウェイのブートストラッピングを大まかに図示する、高次ブロック図である。 少なくともいくつかの実施形態による、シャドウ化ゲートウェイのためのブートストラッピングプロセスのフローチャートである。 少なくともいくつかの実施形態による、パススルーモードに入る、およびそこから復帰するシャドウ化ゲートウェイのフローチャートである。 少なくともいくつかの実施形態による、ゲートウェイからリモートデータストアにブロックをアップロードする、更新する、および追跡するための方法のフローチャートである。 少なくともいくつかの実施形態による、シャドウ化ゲートウェイのための最適化ブートストラッピングプロセスのフローチャートである。 少なくともいくつかの実施形態による、ストレージゲートウェイのセキュリティモデルの態様を図示する図である。 少なくともいくつかの実施形態による、ストレージゲートウェイの起動中、構成中、および動作中のゲートウェイセキュリティモデルの少なくともいくつかの態様を図示する、フローチャートである。 少なくともいくつかの実施形態による、ゲートウェイ起動プロセスに関与するサービス顧客およびサービスプロバイダの構成要素またはエンティティを図示する、例示的なネットワーキング環境の高次ブロック図である。 少なくともいくつかの実施形態による、ゲートウェイ起動プロセス中の、図１５で図示される構成要素の間の相互作用を図示する、プロセスフロー図である。 少なくともいくつかの実施形態による、ゲートウェイ起動プロセス中の、図１５で図示される構成要素の間の相互作用を図示する、プロセスフロー図である。 少なくともいくつかの実施形態による、ストレージゲートウェイの観点からの起動プロセスのフローチャートである。 少なくともいくつかの実施形態による、ストレージゲートウェイの観点からの起動プロセスのフローチャートである。 少なくともいくつかの実施形態で利用され得る例示的なゲートウェイ制御アーキテクチャを図示する、高次ブロック図である。 少なくともいくつかの実施形態による、ゲートウェイ主導の接続およびロングポーリング手法を使用するリモートゲートウェイ管理のための方法のフローチャートである。 いくつかの実施形態による、ゲートウェイ制御サーバがゲートウェイ要求をそのピアサーバにブロードキャストするための方法のフローチャートである。 いくつかの実施形態による、適切なゲートウェイ制御サーバへのゲートウェイ要求を獲得するための代替の方法のフローチャートである。 少なくともいくつかの実施形態による、ゲートウェイ主導の接続を確立、監視、および維持するための方法のフローチャートである。 少なくともいくつかの実施形態による、ゲートウェイプロキシプレーンを含むサービスプロバイダネットワークのためのアーキテクチャを大まかに図示する、ブロック図である。 少なくともいくつかの実施形態による、ゲートウェイプロキシプレーンを通してゲートウェイにメッセージを送る、ゲートウェイ制御サーバを図示する図である。 少なくともいくつかの実施形態による、ゲートウェイプロキシプレーンを通してゲートウェイ制御サーバ要求に応答するゲートウェイを図示する図である。 少なくともいくつかの実施形態による、ゲートウェイプロキシプレーンのためのｐｉｎｇメッセージ交換を図示する図である。 少なくともいくつかの実施形態による、キャッシュされたゲートウェイのための一般的アーキテクチャおよびそのデータＩ／Ｏ操作を図示する図である。 少なくともいくつかの実施形態による、シャドウ化ゲートウェイのための一般的アーキテクチャおよびそのデータＩ／Ｏ操作を図示する図である。 少なくともいくつかの実施形態による、ブロックデータストア上の書き込みログに書き込むための方法のフローチャートである。 キャッシュされたゲートウェイの少なくともいくつかの実施形態による、読み出し要求を履行するための方法のフローチャートである。 いくつかの実施形態で使用され得る例示的なコンピュータシステムを図示する、ブロック図である。

実施形態は、複数の実施形態および実例となる図面について一例として本明細書で説明されるが、当業者は、実施形態が、説明される実施形態または図面に限定されないことを認識するであろう。図面およびその詳細な説明は、実施形態を、開示される特定の形態に限定することを意図するものではなく、逆に、添付の特許請求の範囲によって定義される趣旨および範囲の範囲内に含まれる全ての修正物、均等物、および代替物を対象とすることを意図することを理解されたい。本明細書で使用される見出しは、編成目的のために過ぎず、説明または特許請求の範囲を限定するために使用されることを意味していない。本出願の全体を通して使用される「してもよい／し得る（ｍａｙ）」という用語は、義務的な意味（すなわち、「〜しなければならない」という意味）ではなく、許容的な意味（すなわち、「〜する可能性がある」という意味）で使用される。同様に、「含む（ｉｎｃｌｕｄｅ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、および「含む（ｉｎｃｌｕｄｅｓ）」という用語は、「含むが、それらに限定されない」ことを意味する。

ローカルゲートウェイをリモートストレージに提供するための方法、装置、およびコンピュータがアクセス可能なストレージ媒体の種々の実施形態の種々の実施形態が説明される。ストレージゲートウェイの実施形態は、インターネット等の中間ネットワークを通じて、ストレージサービスをサービスプロバイダの１人以上の顧客に提供する、サービスプロバイダに関連して本明細書で説明される。ストレージゲートウェイは、顧客のデータセンターで施設内に導入され、顧客のデータセンターとストレージサービスとの間のゲートウェイとして作用する、仮想または物理機器として実現され得る。ストレージゲートウェイは、ストレージサービスを介してリモートに提供される主ストレージへのインターフェースおよびそれのためのローカルキャッシュとして、ならびに／またはストレージサービスによって提供されるリモートストレージへの顧客のネットワーク上に実現される主ストレージをシャドウ化するインターフェースとして構成され得る。ストレージゲートウェイは、機器のフロントエンドで顧客のアプリケーションへの標準的なデータアクセスインターフェースを提示し、機器のバックエンドでデータアクセスをストレージサービス要求に変換し、そして、ストレージサービスインターフェースに従って、ネットワークを通じてデータをストレージサービスに転送し得る。少なくともいくつかの実施形態において、ストレージサービスインターフェースは、ウェブサービスインターフェースとして実現され得る。

ストレージゲートウェイの実施形態は、ストレージサービスを介して提供される本質的に無制限で、柔軟な、かつ拡張可能なリモートストレージへの施設内インターフェースを提供し得る。ストレージゲートウェイは、従来の施設内ストレージソリューションに対して、費用効果的で、柔軟な、かつより容易に拡張可能な代替物を提供し得る。ストレージデバイスの費用が削減され得るが、従来の施設内ストレージソリューションの管理費用、ならびに他のソフトウェアおよびハードウェア費用は、比較的一定のままであるか、または一部の場合では増加している。ストレージゲートウェイの実施形態は、サービスプロバイダの顧客が、ストレージ所有の総費用をより低減することを可能にし、少なくとも一部の管理費用および他の費用がサービスプロバイダにまわる。

少なくともいくつかの実施形態において、ストレージサービスは、ブロックストレージ技術に従って、顧客のデータをリモートデータストアに記憶し得る。少なくともいくつかの実施形態において、ストレージゲートウェイは、フロントエンドで、ブロックストレージプロトコル（例えば、ｉＳＣＳＩ、ＧＮＢＤ（グローバルネットワークブロックデバイス）等）、ファイルストレージプロトコル（例えば、ＮＦＳ（ネットワークファイルストレージ）、ＣＩＦＳ（共通インターネットファイルシステム）等）、および／またはオブジェクトストレージプロトコル（例えば、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ：表現可能な状態の転送））を顧客のアプリケーションに公表し得る。ｉＳＣＳＩ等のブロックストレージプロトコルは、リモートデータストアの下層のデータブロックへの直接アクセスを可能にする。

ストレージゲートウェイによって公表されるＮＦＳまたはＣＩＦＳ等のファイルストレージプロトコルを介して、アプリケーションによってリモートデータストアに書き込まれるファイルは、ブロックストレージ技術に従って、リモートデータストアに記憶され得る。公表されたＮＦＳおよびＣＩＦＳ等のファイルストレージプロトコルを通して、ストレージゲートウェイは、ブロックストレージ技術に従ってリモートデータストアに記憶される顧客のデータが顧客のネットワークを通じてゲートウェイから顧客のアプリケーションに伝送される前に、該顧客のデータをファイルとして顧客のアプリケーションに提示する。公表されたブロックストレージプロトコル、例えばｉＳＣＳＩは、ブロックを顧客のアプリケーションに転送し、したがって、アプリケーションは、データブロックをアプリケーションが求める何らかの形式に翻訳する処理を必要とする。

ｉＳＣＳＩ等のブロックストレージプロトコルは、低次ブロックストレージプロトコルであり、したがって、ＮＦＳおよびＣＩＦＳ等のファイルストレージプロトコルよりも広い範囲の使用事例を可能にし得る。ブロックストレージプロトコルは、Ｍｉｃｒｏｓｏｆｔ（登録商標）、ＳｈａｒｅＰｏｉｎｔ（登録商標）、およびＯｒａｃｌｅ（登録商標）データベース等の、一般的にブロックストアに書き込むアプリケーションに対するサポートを可能にし得、また、下層のストレージをＣＩＦＳまたはＮＦＳファイルサーバに提供するようにも構成され得る。したがって、ストレージゲートウェイの少なくともいくつかの実施形態において、ｉＳＣＳＩ等のブロックストレージプロトコルは、顧客のアプリケーションへの公表されたインターフェースとして利用され得る。

図１は、少なくともいくつかの実施形態による、例示的なサービスプロバイダおよび例示的なサービス顧客を含む、例示的なネットワーキング環境の高次ブロック図である。ストレージゲートウェイ８４は、複数のリモートデータストレージ機能の１つ以上をクライアントネットワーク８０上の顧客プロセス８８（複数可）に提供するために、サービス顧客ローカルネットワークまたはデータセンター（例えば、クライアントネットワーク８０）の中に仮想または物理機器として導入され、起動され、構成され得る。顧客プロセス８８は、クライアントネットワーク８０上に存在し、また、ゲートウェイ８４のデータポートのデータプロトコル（例えば、ｉＳＣＳＩプロトコル）を介して、ストレージゲートウェイ８４に接続し、それと通信することができる、任意のハードウェア、ソフトウェア、および／またはそれらの組み合わせであり得る。ストレージゲートウェイ８４は、例えば、施設内ストレージデバイスとして機能し得、および／またはクライアントネットワーク８０上の顧客プロセス（複数可）８８とサービスプロバイダ６０によって提供されるストレージサービス６４との間のインターフェースとして機能し得る。ストレージサービス６４に加えて、サービスプロバイダ６０も、ハードウェア仮想化サービスが挙げられるが、それに限定されない、他のサービスをサービスプロバイダ６０の顧客に提供し得ることに留意されたい。

サービスプロバイダ６０の顧客は、本明細書において、サービス顧客または単に顧客と称され得、任意のエンティティであり得、該エンティティは、サービスプロバイダ６０によってリモートに提供される１つ以上のサービスを含む、ネットワーク化されたコンピューティングサービスを、ローカルネットワークまたはネットワーク上の１人以上のユーザに提供するために、インターネット等の中間ネットワーク５０に連結される、１つまたは複数のコンピュータネットワークを実現する。サービス顧客は、企業、教育機関、政府機関、または一般に、ネットワーク化されたコンピューティングサービスをユーザに提供する１つまたは複数のコンピュータネットワークを実現する任意の機関であり得る。図１は、単一のクライアントネットワーク８０を示しているが、複数のクライアントネットワーク８０があり得る。各クライアントネットワーク８０は、異なるサービス顧客に対応し得、または２つ以上のクライアントネットワーク８０が、同じサービス顧客の異なるデータセンターもしくは所在地、例えば企業の異なる支社もしくは学校組織の異なるキャンパスに対応し得る。少なくともいくつかの実施形態において、サービスプロバイダ６０の各顧客は、サービスプロバイダ６０とのアカウントを有し得、また、セキュリティ証明書（例えば、アカウント名および／または識別子、パスワード等）が提供され得、該セキュリティ証明書を介して、１人以上の顧客代表者（例えば、クライアントネットワーク管理者）は、サービスプロバイダ６０へのインターフェース（例えば、ウェブページ）にログインして、サービスプロバイダ６０によって提供される、ストレージサービスが挙げられるが、それに限定されない、１つ以上のサービスによって提供される、顧客のリソースを管理し得る。

ストレージゲートウェイ８４の実施形態は、ハードウェア、ソフトウェア、またはそれら組み合わせで実現され得る。少なくともいくつかの実施形態において、ストレージゲートウェイ８４は、例えばホストシステム上でインスタンス化される仮想マシン内で実行し得る、仮想機器として実現され得る。少なくともいくつかの実施形態において、ストレージゲートウェイ８４は、サービス顧客のデータセンターでローカルネットワークインフラストラクチャ（例えば、クライアントネットワーク８０）に連結されるサーバシステム等の、１つ以上のコンピューティングデバイスにダウンロードまたは別様には導入され、起動され、そして構成され得る、仮想機器として実現され得る。あるいは、ストレージゲートウェイ８４は、サービス顧客のデータセンターでローカルネットワークインフラストラクチャ（例えば、クライアントネットワーク８０）に連結され得る、専用のデバイスまたは機器として実現され得、専用のデバイスまたは機器は、ストレージゲートウェイ８４の機能を実現する、ソフトウェアおよび／またはハードウェアを含み得る。図２６は、ストレージゲートウェイ８４の実施形態が実現され得る、例示的なコンピュータシステムを図示する。少なくともいくつかの実現例において、ストレージゲートウェイ８４は、ファイアウォール８２技術を通して、中間ネットワーク５０（例えば、インターネット）を介して、サービスプロバイダ６０ネットワークと通信する。サービスプロバイダ６０ネットワークはまた、中間ネットワーク５０から、およびそれにネットワークトラフィックを渡す、フロントエンド６２技術（例えば、ファイアウォール技術、境界ルータ技術、ロードバランサ技術等）も含み得ることに留意されたい。

ストレージゲートウェイ８４の少なくともいくつかの実施形態は、顧客に対するデータ保護、ならびに顧客または第三者によるゲートウェイ８４の誤用および無許可の使用（例えば、権利の侵害）に対する保護を提供する、セキュリティモデルに従って実現され得る。ストレージゲートウェイ８４とストレージサービス６４との間の通信は、安全にされ、暗号化され得る。起動プロセスは、本文書において後で説明され、その中で、新たに導入されるストレージゲートウェイ８４は、セキュリティ証明書を取得するために、サービスプロバイダ６０のネットワークとの接続を開始し、それに識別される。少なくともいくつかの実施形態において、起動プロセス中に、顧客は、サービスプロバイダ６０との顧客のアカウントにログインし、ゲートウェイ８４を登録する際に使用される情報をサービスプロバイダ６０に提供する。しかしながら、顧客は、ストレージゲートウェイ８４にはログインせず、したがって、顧客のセキュリティ証明書および他のアカウント情報は、ゲートウェイ８４上に公表されない。これは、顧客のセキュリティリスクを最小化し得る。

少なくともいくつかの実施形態において、セキュリティモデルの態様は、ストレージゲートウェイ８４が、クライアントネットワーク８０上の顧客プロセス（複数可）８８に公表される１つ以上のデータポート（例えば、ｉＳＣＳＩポート）に対する、外部主導の接続だけを受け付ける。ストレージゲートウェイは、外部プロセスへの全ての他の接続を開始するが、外部プロセスは、ゲートウェイへの任意の他の接続を開始することができない。例えば、少なくともいくつかの実施形態において、ストレージゲートウェイ８４は、ゲートウェイの管理およびサービスプロバイダ６０への他の接続を開始するが、サービスプロバイダ６０は、ゲートウェイ８４への接続を開始しない。別の例として、クライアントネットワーク８０のネットワーク管理者プロセス９０は、ゲートウェイ８４を較正および管理するために、ストレージゲートウェイ８４に直接接続できない。代わりに、ネットワーク管理者プロセス９０によるストレージゲートウェイ８４の構成および管理は、例えばサービスプロバイダ６０のネットワーク上のコンソールプロセス６８を介して、サービスプロバイダ６０を通して行われ得る。したがって、少なくともいくつかの実施形態において、クライアントネットワーク８０上のユーザ、ネットワークマネージャ、またはプロセス（例えば、ネットワーク管理者プロセス９０または顧客プロセス（複数可）８８）は、ストレージゲートウェイ８４に直接「ログインする」ことができず、また、サービスプロバイダ６０のネットワーク上の、または他の何らかの外部ネットワーク上のユーザ、管理者、もしくはプロセス（例えば、コンソールプロセス６８およびストレージサービス６４）も、ストレージゲートウェイ８４への接続を開始することができない。これは、ストレージゲートウェイ８４関するセキュリティ証明書および他の操作情報が、クライアントネットワーク８０上の人々もしくはプロセスによって、または外部の人々もしくはプロセスによって意図的に、または意図せずに危殆化されることから保護するのを補助する。

ストレージゲートウェイ８４の実施形態は、複数のデータストア６６機能のうちの１つ以上を提供するために、ストレージサービス６４とともに使用するように導入され、起動され、構成され得る。例えば、ストレージゲートウェイ８４は、ストレージサービス６４によって導入され、起動され、構成され、そして利用され得、次のように機能する。
● ファイルシステムゲートウェイ。この構成において、ストレージゲートウェイは、ストレージサービス６４へのＮＡＳストレージインターフェース（例えば、ＣＩＦＳまたはＮＦＳプロトコルを使用する）として機能する。リモートデータストア６６は、オブジェクトストア（例えば、ＲＥＳＴ）としてゲートウェイ８４によって顧客に提示され得る一方で、データストア６６は、ブロックストレージ技術に従って実現される。この構成において、リモートデータストア６６は、顧客がファイルをそれに書き込むことができ、かつ顧客がそこからファイルを読み出すことができる仮想化ファイルシステムとして、顧客に提示され得る。
● クラウドボリュームゲートウェイ。この構成において、ストレージゲートウェイ８４は、ストレージサービス６４を介して、リモートデータストア６６上に実現されるボリューム（複数可）へのインターフェースとして機能する。リモートデータストア６６は、ブロックストレージ技術を使用して実現され得る。ゲートウェイ８４は、ローカルネットワークアクセスポイントを提供し、リモートデータストア６６上のボリューム（複数可）（クラウドボリュームとも称され得る）は、柔軟で本質的に無制限の主ストレージ容量を提供するバックエンドストレージとして機能する。この構成において、リモートデータストア６６は、顧客がそこからデータを読み出し、書き込むためのボリュームをローカルにマウントすることができるクラウドボリュームシステムとして、顧客に提示され得る。
● シャドウ化ゲートウェイ。この構成において、ストレージゲートウェイ８４は、顧客の書き込みデータ（例えば、ｉＳＣＳＩ書き込み）のシャドウ化を、ストレージサービス８４を介して、リモートデータストア６６に提供するために、顧客のアプリケーション（例えば、顧客プロセス（複数可）８８）と顧客のローカルデータストア８６との間で、「バンプインザワイヤ」として作用する。リモートデータストア６６は、ブロックストレージ技術を使用して実現され得る。この構成において、ストレージゲートウェイ８４は、顧客のローカルデータストアをリモートデータストア６６上のスナップショット（複数可）にシャドウ化する、シャドウ化機器としての役割を果たし得る。このシャドウ化は、ローカルネットワーク上のユーザの観点から透過的に行われ得る。必要であるかまたは所望されるときに、顧客は、例えば、スナップショット（複数可）からローカルストア８６への顧客のデータの一部分または全てを回復、復元、またはコピーするために、リモートデータストア６６上の顧客のデータのスナップショット（複数可）を要求し得、またはそれにアクセスし得る。

ファイルシステムゲートウェイおよびクラウドボリュームゲートウェイは、どちらもリモートデータストアへのゲートウェイとしての役割を果たし得ること、およびどちらも、データ、例えば頻繁におよび／または最近使用されたデータをローカルにキャッシュし得ることが類似していることに留意されたい。ファイルシステムゲートウェイおよびクラウドボリュームゲートウェイの双方において、顧客プロセスからのデータ読み出しは、可能であれば、ローカルキャッシュから提供され得、可能でなければ、リモートデータストアから提供され得る。これに対して、シャドウ化ゲートウェイにおいて、データ読み出しは、ゲートウェイを通して顧客のローカルデータストアに渡される。この文書のために、ファイルシステムゲートウェイおよびクラウドボリュームゲートウェイは、これらの実現例とシャドウ化ゲートウェイを区別するために、集合的にキャッシュされたゲートウェイと称され得る。

例示的なストレージゲートウェイ機器のアーキテクチャ
図２は、少なくともいくつかの実施形態による、ストレージゲートウェイの例示的なアーキテクチャおよびその構成要素を図示する図である。図２で図示される構成要素のいくつかは、キャッシュされたゲートウェイの実現例と比較したときに、シャドウ化ゲートウェイの実現例では使用され得ず、または異なって使用もしくは実現され得ることに留意されたい。

ブロックドライバ１０は、顧客プロセス８８をストレージゲートウェイ８４とインターフェースし、概して、ブロックドライバ１０は、顧客プロセス８８が（例えば、読み出し／書き込み要求を介して）ストレージゲートウェイ８４と相互作用することを可能にする。ストレージゲートウェイ８４は、顧客プロセス８８とともにオンサイトであるので、プロセス８８の観点から、データがローカルに記憶されるように見える。しかしながら、ストレージゲートウェイ８４は、データをストレージサービス６４によって提供されるリモートデータストア６６に記憶するために、ストレージサービス６４とインターフェースする。キャッシュされたゲートウェイについて、主データストアは、リモートデータストア６６であるが、頻繁にアクセスされるデータは、ゲートウェイ８４によってローカルにキャッシュされ得る。読み出しは、ローカルキャッシュから、または仮想データストレージ６６から履行され得、書き込みは、ローカルキャッシュの中の、および／または仮想データストレージ６６の中のデータブロックを適切に更新するように処理される。シャドウ化ゲートウェイについて、主データストアは、ローカルデータストア８６であり、読み出しは、ローカルデータストア８６に渡され、書き込みは、仮想データストレージ６６にシャドウ化され、ならびに、ローカルデータストア８６に送られる。

ブロックドライバ１０は、顧客プロセス８８からの読み取り／書き込み要求をインターセプトし、該要求をストレージコントローラ１２に渡す。少なくともいくつかの実施形態において、ブロックドライバ１０は、顧客プロセス８８へのインターフェースとして、ブロックストレージプロトコル（例えば、ｉＳＣＳＩまたはＧＭＢＤ）を提供し得る。いくつかの実施形態において、ブロックストレージプロトコルインターフェースの代わりに、または代替例として、ブロックドライバ１０は、ファイルストレージプロトコルインターフェース（例えば、ＮＦＳまたはＣＩＦＳ）を提供し得、また、ストレージコントローラ１２へのインターフェースとして、ファイルシステムセマンティクスを使用し得る。図２は、１つのブロックドライバ１０を示しているが、２つ以上のブロックドライバがあり得ることに留意されたい。

ストレージコントローラ１２は、キャッシュマネージャ１４を介して、ブロックドライバ１０とストレージとの間のメディエータとして作用する。ストレージコントローラ１２の責任としては、ブロックドライバ１０からストレージに読み出しおよび書き込み要求を転送すること、およびストレージがデータで応答したときのブロックドライバ１０へのコールバックが挙げられ得る。ブロックドライバ１０はまた、進行中の要求の数等の統計も維持し得る。

少なくともいくつかの実施形態において、一方のストレージゲートウェイ８４上のストレージコントローラ１２は、もう一方のストレージゲートウェイ８４上のキャッシュマネージャ１４と通信し得る。少なくともいくつかの実施形態において、各ストレージゲートウェイ８４は、故障の発見および検出のためのハートビートメッセージを送り得る。所与のオブジェクトに対して責任を負うストレージゲートウェイ８４を識別するために、コンシステントハッシングが使用され得、データを獲得するための要求は、ターゲットストレージゲートウェイ８４上のキャッシュマネージャ１４に転送され得る。キャッシュマネージャ１４は、ストレージコントローラ１２によって提供されるコールバックを起動することによって応答し得る。

キャッシュされたゲートウェイの実施形態において、キャッシュマネージャ１４は、例えば頻繁にアクセスされるデータのためのストレージを提供する、ローカルキャッシュ２８を管理し得る。ローカルキャッシュ２８は、ストレージゲートウェイ８４の内部揮発性および／または不揮発性メモリ上に実現され得るか、または代替として、顧客によって提供される外部ローカルデータストア８６上に少なくとも部分的に実現され得る。少なくともいくつかの実施形態において、ローカルキャッシュ２８は、仮想化データストレージ６６に記憶されるデータを表し、顧客プロセス８８からの書き込みは、ローカルキャッシュ２８に直接的に影響を及ぼし得ない。

複数のゲートウェイ８４を利用する少なくともいくつかの実施形態では、分散ローカルキャッシュが使用され得、所与の鍵を保持する責任を負うキャッシュを識別するために、鍵へのコンシステントハッシングが使用され得る。少なくともいくつかの実施形態では、さらなるロードバランシングを必要とし得る、ゲートウェイ８４との間の通信を低減させるために、局所性を認識した要求の配信が使用され得る。

リモートデータストア６６の中の所与のボリュームへの全ての書き込み要求は、特定のゲートウェイ８４ノードに進み得る。ボリュームに対する全ての書き込み要求が特定のゲートウェイ８４ノードに転送されるので、ネットワークのパーティショニングは、問題になり得ない。

ステージング
少なくともいくつかの実施形態において、キャッシュマネージャ１４は、ステージング１６構成要素を含み得るか、またはそれとインターフェースし得る。ステージング１６は、書き込みログ１８へのアクセス含み得るか、または有し得る。少なくともいくつかの実施形態において、データ構造は、書き込みログ１８を通じて構築され得、メタデータストア２６として使用され得る。メタデータストア２６は、特定のブロックに対する全ての書き込みへの高速アクセスを可能にすることができる。メタデータストア２６は、例えば、変化をブロック内の異なるセグメントに適用する際に使用され得る。顧客プロセス８８から書き込みデータを受け取ると、該データは、書き込みログ１８に添付される。ブロックに関連する書き込みデータのメタデータ、例えばオフセットおよび長さは、メタデータストア２６に記憶され得る。少なくともいくつかの実施形態において、書き込みログ１８は、線形または循環どちらかのキューとして実現される、一次元のデータバッファとして実現され得る。少なくともいくつかの実施形態において、メタデータストア２６は、例えばバークレーデータベースとして実現される、鍵／値ストアであり得る。いくつかの実施形態では、書き込みログ１８およびメタデータストア２６双方の他の実現例が使用され得る。

キャッシュされたゲートウェイの実現例において、読み出しが行われたとき、元々のブロックは、ローカルキャッシュ２８から、またはリモートデータストア６６から取得され得、データをそれぞれの顧客プロセス８８に返す前に、書き込みログ１８によって示される任意の保留中の変化が適用され得る。

いくつかの実施形態において、ゲートウェイ８４が故障（例えば、クラッシュ）した場合、インメモリ書き込みデータは、データが既にローカルデータストア８６に書き込まれていない限り、失われ得る。いくつかの実施形態において、顧客サイトに複数のゲートウェイ８４がある場合、別のゲートウェイ８４は、クラッシュしたゲートウェイ８４によって所有される鍵の責任を負い得、もしあれば、ローカルデータストア８６上のスナップショットから書き込みを復旧し、そして、それぞれのボリュームに向けられた要求を受け付けることを開始し得る。いくつかの実施形態において、書き込みログ１８および／またはメタデータストア２６は、多重性およびより良い耐久性を提供するために、２つ以上のゲートウェイ８４を通じて複製され得る。ゲートウェイ８４が故障した場合、他のゲートウェイ８４のうちの１つが、故障したゲートウェイの書き込みログ１８およびメタデータストア２６を引き継ぎ得る。しかしながら、少なくともいくつかの実施形態において、メタデータストア２６は、所有者ゲートウェイ８４上だけで維持され得る。これらの実施形態において、ゲートウェイ８４が故障した場合、他のゲートウェイ８４の１つは、メタデータストア２６を再構築するために、主書き込みログ１８を引き継ぎ、パースし得る。

キャッシュされたゲートウェイの実現例において、ブロックフェッチャ２２は、ストレージサービス６４を介して、リモートデータストア６６から必要とされるブロックのセグメントをフェッチする。少なくともいくつかの実施形態において、ブロックフェッチャ２２は、キャッシングのための完全なブロックをフェッチするために、遅延フェッチ手法を利用し得る。キャッシュされたゲートウェイおよびシャドウ化ゲートウェイの双方について、ブロックストア２４は、ストレージサービス６４を介して、ステージング１６からリモートデータストア６６にデータをプッシュする。少なくともいくつかの実施形態において、ブロックストア２４は、ブロックをプッシュするために、遅延プッシュ手法を利用し得る。

少なくともいくつかの実施形態において、キャッシュされたゲートウェイの読み出し操作中に、ブロックドライバ１０は、ボリュームＩＤ、開始オフセット、および長さを含む、読み出し要求をストレージコントローラ１２に送る。少なくともいくつかの実施形態において、ストレージコントローラ１２は、ボリュームＩＤおよびオフセットをオブジェクト鍵に変換し得る。ストレージコントローラ１２は、読み出し要求情報をキャッシュコントローラ１４に渡し、該キャッシュコントローラは、適切なローカルキャッシュ２８から、読み出し要求を履行するよう試み得る。データがローカルキャッシュ２８の中に存在しない場合、要求は、ブロックフェッチャ２２に転送され、該ブロックフェッチャは、ストレージサービス６４を介して、リモートデータストア６６上の適切なボリュームからデータをフェッチする。データが取得されると、ローカルキャッシュ２８が更新され、書き込みログ１８から変化が適用され、読み出し応答が顧客プロセス８８に返される。少なくともいくつかの実施形態において、複数のブロックが要求された場合は、それぞれが、それぞれのブロックの関連するオフセットを示す、複数の読み出し応答が返され得る。少なくともいくつかの実施形態では、逐次読み出しが検出された場合、逐次ブロックがプリフェッチされ得る。

少なくともいくつかの実施形態において、書き込み操作中に、ブロックドライバ１０は、ボリュームＩＤおよび書き込みデータを含む書き込み要求を、ボリュームに対して責任を負う、ストレージコントローラ１２に送る。書き込みデータは、書き込みログ１８に書き込まれ、メタデータストア２６は、バッファプール２０の中の変化したデータへの参照を含むように更新される。

バッファプール
少なくともいくつかの実施形態において、バッファプール２０は、ストレージコントローラ１２とローカルデータストア８６との間に存在する。バッファプール２０は、以下のタスクのうちの１つ以上を行い得るが、それらに限定されない。いくつかのタスクを、キャッシュされたゲートウェイだけに適用し得ることに留意されたい。
● ローカルデータストレージデバイス（複数可）上のそれらの物理的場所からの、書き込みログ１８およびローカルキャッシュ２８の論理オフセットのデータをキャッシュする。
● 読み出しおよび書き込み操作中に、バッファ上にロックを維持する。
● 追い出し手法、例えば最長未使用時間（ＬＲＵ）追い出し手法を、ローカルキャッシュ２８の物理ストレージに適用する。これは、ゲートウェイのシャドウ化には必要でないことに留意されたい。
● キャッシュされたゲートウェイにおける読み出しについて、要求されたデータがローカルキャッシュ２８の中に見つからなかった場合は、バッファプール２０がブロックフェッチャ２２と通信して、リモートデータストア６６からブロックをフェッチし得る。あるいは、いくつかの実施形態では、ブロックフェッチャ２２がストレージサービス６４と直接通信して、ブロックをフェッチし得る。

少なくともいくつかの実施形態において、バッファプール２０は、そのメタデータストア２６として、データベース、例えばバークレーデータベース（ＢＤＢ）を利用し得る。下で示される表１は、少なくともいくつかの実施形態による、メタデータストア２６に記憶され得る情報を示す。表１のエントリは、内容または配設に従って制限することを意図しないことに留意されたい。

少なくともいくつかの実施形態において、物理ディスクオフセットは、設定された境界、例えば４ＭＢ境界である。少なくともいくつかの実施形態において、これは、ボリュームおよび書き込みログ１８の双方におけるデータの境界を含む。少なくともいくつかの実施形態において、特定のボリュームの書き込みは、逐次書き込みであり得、したがって、ディスク上の断片化を考慮することを必要とし得ない。「チャンク」は、１つのブロックまたは１つ以上のブロックに対応し得ることに留意されたい。

メタデータストア２６が、Ｓ（スナップショット）およびＣ（チャンク）エントリの双方を含み得ること、およびこれらを、ストレージコントローラ１２がそれを介してブロックへのアクセスを試みるスキームによって、最新の状態に保つ必要があることに留意されたい。例えば、ブロックは、最初にスナップショットＩＤを使用して参照され得るが、その後は、毎回チャンクＩＤを使用して参照され得る。これは、メタデータストア２６に保存され得る。スナップショットの完了時点で、ストレージコントローラ１２は、スナップショットＩＤを使用して、スナップショットからブロックを参照し得、したがって、メタデータストア２６の中のＣ（チャンク）エントリは、対応するＳ（スナップショット）エントリに変換され得る。

キャッシュされたゲートウェイ操作
少なくともいくつかの実施形態では、読み出し要求を受け取ると、メタデータストア２６において、ブロックの１つまたは複数の書き込みログ１８エントリがルックアップされる。１つまたは複数の書き込みログ１８エントリを使用して読み出し要求を履行することができる場合、メタデータストア２６において、全ての必要とされるエントリがルックアップされ、バッファに読み出され、平坦化され、そして必要とされる部分が返される。１つまたは複数の書き込みログ１８エントリを使用するだけでは読み出し要求を履行することができない場合、キャッシュデータブロック（例えば、４ＭＢブロック）のオフセットが、読み出し要求のオフセットから計算される。メタデータストア２６において、ブロックの場所がルックアップされる。ブロックがローカルキャッシュ２８の中にある場合、ブロックは、ローカルキャッシュ２８から読み出され、その中にない場合はリモートデータストア６６からフェッチされる。必要とされる書き込みログ１８エントリは、上で説明されるようにフェッチされ、ブロックで平坦化され、そして、必要とされる部分が返される。ブロックがリモートデータストア６６からフェッチされる場合、ブロックは、ローカルキャッシュ２８にキャッシュされ、メタデータストア２６に記録される。ローカルキャッシュ２８の中のブロックに対する最後のアクセス時間も更新される。

少なくともいくつかの実施形態では、書き込み要求を受け取ると、次の書き込みログ１８オフセットで変化が記録され、メタデータ、すなわち、オフセットおよび長さがメタデータストア２６に記録される。

少なくともいくつかの実施形態では、ブロックのアップロードが完了すると、（変化が適用された）最新バージョンのブロックがローカルキャッシュ２８に加えられ、メタデータストア２６に記録される。以前のバージョンのブロックがローカルキャッシュ２８に存在する場合、このブロックは、メタデータストア２６の中で空きとしてマークされる。

少なくともいくつかの実施形態では、スナップショットが完了すると、上で説明されるように、メタデータストア２６を再編成することが必要になり得る。すなわち、スナップショットに属するブロックエントリは、リモートデータストア６６上の対応するスナップショットエントリに変換され得る。

シャドウ化ゲートウェイ操作
少なくともいくつかの実施形態において、読み出し要求は、ローカルデータストア８６に渡される。

少なくともいくつかの実施形態では、書き込み要求を受け取ると、次の書き込みログ１８オフセットで書き込みデータが記録され、書き込みの適切なメタデータがメタデータストア２６に記録される。書き込み要求はまた、ローカルデータストア８６にも渡される。

少なくともいくつかの実施形態では、ブロックをリモートデータストア６６にアップロードするために、アップロードプロセスは、書き込みログ１８を読み出すために、バッファプール２０を呼び出す。バッファプール２０は、メタデータストア２６を使用して、論理書き込みログ１８オフセットから物理オフセットへの変換を行い、次いで、データがメモリバッファに読み出される。バッファは、次いで、アップロードプロセスに提示される。アップロードプロセスは、ブロックをリモートデータストア６６にアップロードし、ブロックをバッファプール２０に発行する。

書き込みログのパージ
少なくともいくつかの実施形態では、書き込みログ１８をパージする必要がある場合、バッファプール２０は、書き込みログ１８をパージすることができるボリュームのための書き込みログオフセットを取得する。少なくともいくつかの実施形態において、書き込みログオフセットは、例えば、各エントリのオフセットを確認する、データベース上のウォークを行うことによって、メタデータストア２６から決定され得る。書き込みログ１８をパージするために、ログのパージ可能な部分に対応する既存の書き込みログエントリが、空きエントリとしてマークされ得る。

例示的な実現例
図３は、ストレージゲートウェイの実施形態が実現され得る例示的なネットワーク環境の高次ブロック図である。中間ネットワーク１００（例えば、インターネット）上のサービスプロバイダ１１０は、同じく中間ネットワーク１００に連結される１つ以上のサービス顧客ネットワーク（例えば、クライアントネットワーク（複数可）１５０）に、ストレージサービス１１２を介してリモートデータストア１１６へのアクセスを提供する。各クライアントネットワーク１５０は、異なるサービス顧客に対応し得、または２つ以上のクライアントネットワーク１５０が、同じサービス顧客の異なるデータセンターまたは所在地、例えば企業の異なる支社もしくは学校組織の異なるキャンパスに対応し得る。サービス顧客は、企業、教育機関、政府機関、個人機関、または一般に、ネットワーク化されたコンピューティングサービスを１人以上のユーザに提供するために、インターネット等の中間ネットワーク１００に連結される、１つまたは複数のコンピュータネットワークを実現する任意の機関であり得る。いくつかの実施形態において、ストレージサービス１１２は、インターフェース、例えばウェブサービスインターフェースを提供し得、それを介して、各サービス顧客のクライアントネットワーク（複数可）１５０は、ストレージサービス１１２によって提供される機能にアクセスし得る。

顧客プロセス１５４Ａおよび１５４Ｂは、サービス顧客のクライアントネットワーク１５０に接続される、物理マシンおよび／もしくは仮想マシンまたはシステムを表す。ストレージサービス１１２によって提供される機能の例として、ユーザは、顧客プロセス１５４を介して、データボリュームを作成し、ストレージサービス１１２を介して、リモートデータストア１１６にマウントすることができる。クライアントネットワーク１５０上のユーザの観点から、ストレージサービス１１２によって提供されるデータボリュームは、あたかもそれらがローカルストレージであるかのように現れ得、したがって、そのようなデータボリュームは、仮想データボリューム１５８と称され得る。仮想データボリューム１５８は、実際に、リモートデータストア１１６がインスタンス化される１つ以上の物理ストレージまたはストレージシステムにマップする。しかしながら、このマッピングは、ストレージサービス１１２によって処理され、したがって、クライアントネットワーク１５０上のユーザの観点からは透過的である。顧客プロセス１５４のユーザは、単にデスクトップ上にマウントされた、またはデバイスリストの中のボリュームだけが見え得る。顧客プロセス１５４のユーザは、あたかもボリューム１５８がローカルに取り付けられたストレージデバイス上に実現されたかのように、データを作成し、データを修正し、データを削除し得、また一般に、仮想データボリューム１５８に対して任意のデータ関連の機能を行い得る。

図４は、少なくともいくつかの実施形態による、クライアントネットワーク２５０とストレージサービス２１２との間のインターフェースとして機能する、サービス顧客のクライアントネットワーク２５０においてオンサイトのストレージゲートウェイ２５２を含む、例示的なネットワーク環境のブロック図である。少なくともいくつかの実施形態において、ストレージゲートウェイ２５２は、サービス顧客のデータセンターにおいてオンサイトで導入されるファイルおよび／またはブロックストレージ機器をしてもよい。

ストレージゲートウェイ２５２は、例えば、ファイルシステムゲートウェイとしての、クラウドボリュームゲートウェイ（集合的にキャッシュされたゲートウェイと称される）としての、またはシャドウ化ゲートウェイとして機能するように、導入され、起動され、そして構成され得る。ファイルシステムゲートウェイは、（例えば、ＣＩＦＳまたはＮＦＳプロトコルを使用して）ストレージサービス２１２へのＮＡＳストレージインターフェースとして機能する。リモートデータストア２１６は、オブジェクトストア（例えば、ＲＥＳＴ）として顧客に提示され得るが、実際にはブロックストレージとして実現される。クラウドボリュームゲートウェイは、ストレージサービス２１２によって提供される仮想化ボリュームストレージへのインターフェースとして機能する。ボリュームストレージは、ブロックストレージとして実現され得る。ゲートウェイ２５２は、ローカルネットワークアクセスポイントを提供し、リモートデータストア２１６（クラウドボリュームとも称され得る）は、柔軟で本質的に無制限の主ストレージ容量を提供する、バックエンドストレージとして機能する。シャドウ化ゲートウェイは、顧客の書き込みデータ（例えば、ｉＳＣＳＩ書き込み）のシャドウ化を、ストレージサービス２１２によって提供されるリモートストレージに提供するために、顧客のアプリケーションと顧客のローカルデータストアとの間の「バンプインザワイヤ」として作用する。リモートデータストア２１６は、ブロックストレージとして実現され得る。

キャッシュされたゲートウェイの実現例において、ストレージゲートウェイ２５２は、頻繁にアクセスされるデータのローカルキャッシュをローカルデータストア２５４に記憶し得る一方で、サービスプロバイダ２１０へ返すデータの移動を安全に暗号化し、迅速化する。同様に、シャドウ化ゲートウェイの実現例は、サービスプロバイダ２１０への書き込みデータの移動を安全に暗号化し、迅速化し得る。この迅速化されたデータの移動は、標準的なインターネット接続と比較して、例えば、データの重複排除、圧縮、並列化、およびＴＣＰウインドウスケーリング手法のうちの１つ以上を使用して達成され得る。ストレージゲートウェイ２５２は、一般的に主ストレージまたはバックアップストレージとしてオンサイトストレージアレイを管理することと関連付けられる、費用、利用率、維持管理、およびプロビジョニングの問題を大幅に低減し得る。ストレージゲートウェイ２５２は、そうでない場合に顧客ごとに数１００テラバイト〜ペタバイトのデータを社内で記憶させ得る、例えばＮＡＳまたはＳＡＮハードウェアといった、高価なハードウェアを、費用効果的な機器と置き換えることによってこれを達成し得る。ストレージゲートウェイ２５２によって、顧客は、オンサイトストレージ（キャッシュされたゲートウェイの実現例において、ゲートウェイ２５２によって維持されるローカルキャッシュによって提供される）の低アクセス待ち時間の利益を享受し得る一方で、サービスプロバイダ２１０によって提供される耐久性があり、有用で、かつ拡張可能な、分散ストレージインフラストラクチャを活用する。

ストレージゲートウェイ２５２の実施形態は、顧客のオンサイトアプリケーションとともにシームレスに機能し得る。少なくともいくつかの実施形態において、顧客は、ＳＡＮ（ｉＳＣＳＩ）、ＮＡＳ（ＮＦＳ、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＣＩＦＳ）、またはＯｂｊｅｃｔ（ＲＥＳＴ）ストレージをサポートするように、ストレージゲートウェイ２５２を構成し得る。少なくともいくつかの実施形態において、ストレージゲートウェイ２５２によって提供されるｉＳＣＳＩインターフェースは、Ｍｉｃｒｏｓｏｆｔ（登録商標）、ＳｈａｒｅＰｏｉｎｔ（登録商標）、およびＯｒａｃｌｅ（登録商標）データベース等の、オンサイトのブロックストレージアプリケーションとの統合化を可能にし得る。少なくともいくつかの実施形態において、顧客は、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、およびＵＮＩＸ（登録商標）環境が挙げられるが、それらに限定されない、環境全体にわたってファイルストレージを一元管理するために、ストレージゲートウェイ２５２によって提供されるＮＦＳおよびＣＩＦＳインターフェースを利用し得る。少なくともいくつかの実施形態において、ストレージゲートウェイ２５２はまた、ＲＥＳＴに基づく要求をサポートするように構成され得る。

少なくともいくつかの実施形態において、ストレージゲートウェイ２５２は、顧客のデータセンターでクライアントネットワーク２５０インフラストラクチャに連結されるサーバシステム等の、１つ以上のコンピューティングデバイスにダウンロードされ、または別様にはそれに導入され、起動され、そして構成され得る、仮想デバイスまたは機器として実現され得る。あるいは、ストレージゲートウェイ２５２は、クライアントネットワーク２５０インフラストラクチャに連結され得る、専用のデバイスまたは機器として実現され得、専用のデバイスまたは機器は、ゲートウェイの機能が実現され得る、ソフトウェアおよび／またはハードウェアを含み得る。

少なくともいくつかの実現例において、ストレージゲートウェイ２５２は、中間ネットワーク２００（例えば、インターネット）を介して、サービスプロバイダ２１０ネットワークと通信する。大量のデータが中間ネットワーク２００を通じてストレージサービス２１２とストレージゲートウェイ２５２との間で転送され得るので、中間ネットワーク２００へのストレージゲートウェイ２５２の連結は、一般に、サービス顧客のクライアントネットワーク２５０によって提供される広帯域の接続を介し得る。例えば、ピーク時間で、接続は、１００メガビット／秒（１００Ｍｂｉｔ／ｓ）以上の速度でのデータ転送をサポートする必要があり得る。しかしながら、少なくともいくつかの実施形態では、ストレージゲートウェイ２５２からストレージサービス２１２にデータをアップロードするときの帯域幅使用量を低減させるために、データ重複排除手法等の手法が利用され得、したがって、より多くの接続の帯域幅が他のアプリケーションで利用可能であり得る。少なくともいくつかの実施形態において利用され得る例示的なデータ重複排除手法は、米国特許出願第１２／９８１，３９３号、名称「ＲＥＣＥＩＶＥＲ−ＳＩＤＥ ＤＡＴＡ ＤＥＤＵＰＬＩＣＡＴＩＯＮ ＩＮ ＤＡＴＡ ＳＹＳＴＥＭＳ」、および米国特許出願第第１２／９８１，３９７号、名称「ＲＥＤＵＣＥＤ ＢＡＮＤＷＩＤＴＨ ＤＡＴＡ ＵＰＬＯＡＤＩＮＧ ＩＮ ＤＡＴＡ ＳＹＳＴＥＭＳ」で説明される。

少なくともいくつかの実施形態において、中間ネットワーク２００を通じたクライアントネットワーク２５０とサービスプロバイダ２１０との間の接続に関する帯域幅は、例えばクライアントネットワーク２５０でネットワーク管理者プロセス２６０を介して、ストレージゲートウェイ２５２および他の顧客アプリケーションに割り当てられ得る。ストレージゲートウェイ２５２は、例えばデータ重複排除手法に従って、変化した（新しいまたは変更された）データをストレージサービス２１２に、連続的またはほぼ連続的にアップロードし得る。しかしながら、クライアントネットワーク２５０のデータの変化率は、経時的に変動し得、例えば、日中の顧客プロセスの書き込みスループットはより高くなり得るが、夜間の書き込みスループットはより低くなり得る。したがって、変化率が高い混雑時に、ストレージゲートウェイ２５２は、ストレージゲートウェイ２５２に割り当てられる帯域幅が、遅れを生じないよう十分高くない場合に、変化したデータをアップロードする際に遅れを生じ得、ストレージゲートウェイ２５２は、次いで、変化率がそれほど高くない非混雑時に、遅れを取り戻し得る。少なくともいくつかの実施形態において、ストレージゲートウェイ２５２が規定の閾値よりも遅れる場合、ストレージゲートウェイ２５２は、さらなる帯域幅の割り当てを要求し得る。少なくともいくつかの実施形態において、ストレージゲートウェイ２５２は、必要であれば、より多くの帯域幅を要求するために警報を発し得る。

図４は、ストレージゲートウェイ２５２とストレージサービス２１２との間の直接接続を示しているが、ストレージゲートウェイ２５２とストレージサービス２１２と間の接続は、ローカルネットワーク２５６を経由し得ることに留意されたい。

ストレージゲートウェイ２５２の少なくともいくつかの実施形態では、要求に応じてリモートデータストア２１６からデータを取り出すのではなく、大きいデータのブロックまたはチャンク、さらにはデータのボリューム全体が、ローカルデータストア２５４にローカルにキャッシュされ得る。ストレージゲートウェイ２５２は、データのローカルキャッシュ、例えば頻繁にアクセスされるデータまたは重要なデータが維持され得る、物理データストレージおよび／またはメモリ（ローカルデータストア２５４）を含み得るか、またはそれへのアクセスを有し得る。ローカルデータストア２５４は、揮発性もしくは不揮発性ストレージもしくはメモリ、またはその組み合わせであり得る。頻繁にアクセスされるデータのローカルキャッシュを維持することは、リモートデータストア２１６からデータを取り出すのではなく、多数のまたは大部分のデータアクセスをローカルキャッシュから提供することができるので、一般に、顧客プロセス２５８のデータアクセス時間を改善し得る。しかしながら、リモートデータストア２１６は、サービス顧客のクライアントネットワーク２５０の主データストアとしての役割を果たし得、したがって、ストレージゲートウェイ２５２は、ローカルキャッシュからリモートデータストア２１６に新しいまたは修正されたデータを定期的に、非定期的に、または連続的にアップロードするために、および必要に応じて、リモートデータストア２１６から要求されたデータをダウンロードするために、中間ネットワーク２００を介して、ストレージサービス２１２と通信し得る。

図４において、リモートデータストア２１６のストレージ（２１８Ａ、２１８Ｂ、２１８Ｃ、．．．）は、リモートデータストア２１６が、サービスプロバイダ２１０のローカルネットワーク２１４に接続される複数の記憶デバイスもしくはシステム上に、またはそれらの全体にわたって実現され得ることを示す。したがって、サービス顧客のデータは、「バックエンド」上の２つ以上の物理ストレージデバイスまたはシステムにわたって展開され得る。バックエンドストレージデバイスは、必ずではないが、他の顧客と共有されるマルチテナントデバイスであり得る。しかしながら、図３に関して述ベられるように、ユーザおよびクライアントネットワーク２５０上のプロセスの観点から、クライアントのデータは、仮想ボリュームまたはファイルとして提示され得る。

少なくともいくつかの実施形態において、図３および図４を参照して説明されるサービスプロバイダはまた、ハードウェア仮想化技術および場合により他の仮想化技術を顧客に提供し得る。サービスプロバイダ２００は、ブロックストレージ能力（すなわち、ブロックに基づくストレージシステム）を顧客に提供するブロックストレージ技術を含む、一連の仮想化コンピューティング技術および仮想化ストレージ技術を提供し得る。サービスプロバイダ２００によって提供されるハードウェア仮想化技術に従って実現される、仮想コンピューティング環境またはシステムは、ブロックストレージ技術によってサポートされ得る。ブロックストレージ技術は、仮想化ストレージシステムを提供し得、該仮想化ストレージシステムは、例えば、標準化されたストレージコールを通して仮想コンピューティングシステムと相互作用することができ、該ストレージコールは、それがサポートするボリュームの構造的および機能的詳細を問わず、また、それがストレージの可用性を提供する仮想コンピューティングシステム（または他のシステム）上で実行するオペレーティングシステムを問わない、ブロックレベルのストレージ機能を提供する。

ストレージゲートウェイ２５２の実施形態は、サービスプロバイダ２００によって提供されるオンサイトの顧客アプリケーションならびに仮想化コンピューティングおよびストレージ技術と統合し得、柔軟な「クラウドに基づく」コンピューティングおよびストレージリソースへのアクセスを顧客に提供する。例えば、ＳＡＮストレージにストレージゲートウェイ２５２を使用する顧客は、それらのデータの一貫したポイントインタイムのブロックに基づくスナップショットを作成し得る。これらのスナップショットは、次いで、ブロックに基づくストレージシステムを提供する高Ｉ／Ｏおよび低待ち時間のデータアクセスを必要とする、ハードウェア仮想化技術アプリケーションおよびインスタンス（例えば、図５の仮想コンピューティングシステム（複数可）２６４を参照されたい）によって処理され得る。別の例として、顧客は、ＮＦＳまたはＣＩＦＳファイルプロトコルを介してＮＡＳストレージのストレージゲートウェイ２５２を構成し得、また、ハードウェア仮想化技術インスタンスからアクセス可能なそれらのファイルデータのポイントインタイムのスナップショットを作成し得る。

いくつかの実施形態において、ストレージゲートウェイ２５２によって提供されるＲＥＳＴに基づくインターフェースを使用して書き込まれるオブジェクトは、ＨＴＴＰまたは他のプロトコルを介してサービスプロバイダによって提供される仮想ストレージ技術から直接アクセスされ得るか、またはサービスプロバイダによって提供される統合したコンテンツ配信技術を使用して配信され得る。いくつかの実施形態において、顧客はまた、ハードウェア仮想化技術インスタンス上でこれらのオブジェクトを並列に処理するための仮想化ストレージ技術によって提供される、高い拡張可能性の分散型インフラストラクチャも利用し得る。

図５は、少なくともいくつかの実施形態による、ストレージサービスおよびハードウェア仮想化サービスをサービスプロバイダの顧客に提供する、例示的なサービスプロバイダのブロック図である。サービス顧客のクライアントネットワーク２５０は、例えば図４を参照して説明されるように、クライアントネットワーク２５０とサービスプロバイダ２１０のストレージサービス２１２との間のインターフェースとして機能する、１つ以上のストレージゲートウェイ２５２を含み得る。サービスクライアント（複数可）は、管理者、ユーザ、またはサービスプロバイダ２１０によって提供されるサービスの１つにアクセスし得る任意のプロセスを表し得る。

ハードウェア仮想化技術は、複数のオペレーティングシステムが、ホストコンピュータ２９２上で並行して、すなわち、ホスト２９２上の仮想マシン（ＶＭ）２９６として動作することを可能にする。ＶＭ２９６は、例えば、サービスプロバイダ２１０の顧客に対して貸借され得る。ホスト２９２上のハイパーバイザーまたは仮想マシンモニタ（ＶＭＭ）２９４は、仮想プラットフォームを伴うホスト２９２上のＶＭ２９６を提示し、ＶＭ２９６の実行を監視する。各ＶＭ２９６には、１つ以上のＩＰアドレスが提供され得、ホスト２９２上のＶＭＭ２９４は、ホスト上のＶＭ２９６のＩＰアドレスを認識し得る。サービスプロバイダ２１０のローカルネットワークは、パケットを、ＶＭ２９６からインターネットの宛先（例えば、クライアントネットワーク２５０上のサービスクライアント（複数可）２６２）に、およびインターネットソース（例えば、サービスクライアント（複数可）２６２）からＶＭ２９６にルーティングするように構成され得る。

サービスプロバイダ２１０は、ローカルネットワーク２５６を介して中間ネットワーク２００に連結される、サービス顧客のクライアントネットワーク２５０に、中間ネットワーク２００およびサービスプロバイダ２１０のローカルネットワークに連結されるハードウェア仮想化サービス２９０を介して、仮想コンピューティングシステム２６４を実現する能力を提供する。いくつかの実施形態において、ハードウェア仮想化サービス２９０は、インターフェース、例えばウェブサービスインターフェースを提供し得、サービスクライアント２６２は、それを介して、ハードウェア仮想化サービス２９０によって提供される機能にアクセスし得る。サービスプロバイダ２１０で、各仮想コンピューティングシステム２６４は、サービス顧客に対して貸借され、または別様には提供される、ホスト２９２システム上の仮想マシン（ＶＭ）２９６を表し得る。

仮想コンピューティングシステム２６４のインスタンスから、ユーザは、上で説明されるように、ストレージサービス２１２の機能にアクセスし得る。したがって、図５で示される仮想化システムの実施形態は、クライアントが、サービスプロバイダ２１０によって提供されるＶＭ２９６上に実現される仮想コンピューティングシステム２６４のローカルインスタンスを作成すること、および仮想コンピューティングシステム２６４のローカルインスタンスから、サービスプロバイダ２１０によって実現されるリモートデータストア２１６からのデータにアクセスし、データをそれに記憶することを可能にし得る。

上で説明されるように、１つ以上のストレージゲートウェイ２５２は、クライアントネットワーク２５０でインスタンス化され得る。ゲートウェイ２５２の少なくとも１つは、少なくともいくつかのデータ、例えば頻繁にアクセスされる、または重要なデータをローカルにキャッシュする、キャッシュされたゲートウェイの実現例であり得る。ストレージゲートウェイ（複数可）２５２は、例えば、キャッシュされたゲートウェイの実現例で、データの主ストア（リモートデータストア２１６）が維持されるように、ローカルキャッシュから新しいまたは修正されたデータをアップロードするために、またはシャドウ化ゲートウェイの実現例で、新しいまたは修正されたデータ（書き込みデータ）をリモートデータストア２１６上のローカル主データストアのスナップショットにアップロードするために、１つ以上の広帯域通信チャネルを介して、ストレージサービス２１２と通信し得る。

キャッシュされたゲートウェイの実現例
図６は、ストレージゲートウェイの実施形態が、集合的にキャッシュされたゲートウェイと称される、ファイルシステムゲートウェイまたはクラウドボリュームゲートウェイとして構成される例示的なネットワーク環境のアーキテクチャおよびその中のデータフローを大まかに図示する、高次ブロック図である。少なくともいくつかの実施形態において、ストレージゲートウェイ２５２は、サービス顧客のデータセンターにおいてオンサイトで導入される、ファイルおよび／またはブロックストレージ機器であり得る。図６において、ストレージゲートウェイ２５２は、例えば、ファイルシステムゲートウェイとして、またはクラウドボリュームゲートウェイとして機能するように、導入され、起動され、そして構成され得る。ファイルシステムゲートウェイは、ストレージサービス２１２へのＮＡＳストレージインターフェース（例えば、ＣＩＦＳまたはＮＦＳプロトコルを使用する）として機能する。リモートデータストア２１６は、オブジェクトストア（例えば、ＲＥＳＴ）として顧客に提示され得る一方で、ブロックストレージとして実現される。クラウドボリュームゲートウェイは、ストレージサービス２１２によって提供される仮想化ボリュームストレージへのインターフェースとして機能する。仮想化ボリュームストレージは、ブロックストレージとして実現され得る。ゲートウェイ２５２は、ローカルネットワークアクセスポイントを提供し、リモートデータストア２１６（クラウドボリュームとも称され得る）は、柔軟で本質的に無制限の主ストレージ容量を提供する、バックエンドストレージとして機能する。

ストレージゲートウェイ２５２が導入され、起動され、そして構成されると、クライアントネットワーク２５０のネットワーク管理者プロセス２６０は、例えば、ストレージサービス２１２を介して、リモートデータストア２１６上に、新しいデータボリューム２７０を作成し得るか、または既存のデータボリューム２７０をマウントし得る。ボリューム要求および他のサービス要求の作成は、サービスプロバイダフロントエンド２８０を介して、サービス２１２に対して行われ得る。フロントエンド２８０はまた、ストレージゲートウェイ２５２への、およびそこからの接続および通信を管理し得る。フロントエンド２８０としては、ファイアウォール、境界ルータ、ロードバランサ、ゲートウェイサーバ、ゲートウェイプロキシ、コンソールプロセス、ならびに一般に、ストレージサービス２１２をクライアントネットワーク（複数可）２５０に公表するために、およびストレージサービス２１２をストレージゲートウェイ（複数可）２５２にインターフェースするために必要であり得る、任意のネットワーキングデバイスおよび／もしくはプロセスのうちの１つ以上が挙げられ得るが、それらに限定されない。

少なくともいくつかの実施形態において、ストレージゲートウェイ２５２は、サービスプロバイダフロントエンド２８０を介して、サービスプロバイダ２１０への全ての接続を開始し、サービスプロバイダ２１０は、ゲートウェイ２５２への接続を開始しない。加えて、ネットワーク管理者プロセス２６０は、ゲートウェイ２５２への接続を直接開始せず、例えばゲートウェイ２５２を構成し、管理するための、ネットワーク管理者プロセス２６０によるゲートウェイ２５２へのアクセスは、サービスプロバイダフロントエンド２８０を介して、サービスプロバイダ２１０を通る。

ストレージゲートウェイ２５２は、１つ以上のデータポート（例えば、ｉＳＣＳＩポート）をクライアントネットワーク２５０上の顧客プロセス２５８に公表する。顧客プロセス２５８は、クライアントネットワーク２５０上に存在し、また、ゲートウェイ２５２のデータポートのデータプロトコル（例えば、ｉＳＣＳＩプロトコル）を介して、ストレージゲートウェイ２５２に接続し、それと通信することができる、任意のハードウェア、ソフトウェア、および／またはそれらの組み合わせであり得る。顧客プロセス２５８は、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）、ＳｈａｒｅＰｏｉｎｔ（登録商標）、およびＯｒａｃｌｅ（登録商標）データベース等のストレージアプリケーション、サーバ（例えば、ＳＱＬサーバ、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ（登録商標）サーバ等）、データベースアプリケーション（例えば、ＳＱＬデータベースアプリケーション、およびＯｒａｃｌｅ（登録商標）データベースアプリケーション）、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ（登録商標）アプリケーション、またはストレージゲートウェイ２５２データポート（複数可）と通信するように動作可能であるクライアントネットワーク２５０上の１つ以上のデバイス上で実行する、任意の他のアプリケーションまたはプロセスであり得る。顧客プロセスは、本明細書で使用されるときに、クライアントネットワーク２５０の中の１つ以上のデバイス上で実行され得る、任意のソフトウェアプロセスを包含する。しかしながら、プロセスを実行する下層のハードウェアは、プロセスを代表するストレージゲートウェイ２５２データポート（複数可）に対する接続および通信に関与し得るか、またはそれらを行い得ることに留意されたい。

マウントされたボリューム２７０は、ストレージゲートウェイ２５２によって顧客プロセス（複数可）２５８に提示され得る。顧客プロセス（複数可）２５８は、次いで、例えばｉＳＣＳＩプロトコルに従って、ストレージゲートウェイ２５２によって公表されるデータポートを介した、ボリューム２７０からの読み出し、およびそれへの書き込みを行い得る。ストレージゲートウェイ２５２は、ボリューム２７０への全ての読み出しおよび書き込み要求を処理する。リモートデータストア２１６上のボリューム（複数可）２７０は、主データストアとして機能するが、ストレージゲートウェイ２５２はまた、頻繁にアクセスされるデータのローカルキャッシュをローカルデータストア２５４に記憶し得る。ローカルデータストア２５４は、ストレージゲートウェイ２５２の内部のストレージハードウェア上、サービス顧客によって提供されるストレージゲートウェイ２５２の外部のストレージハードウェア上、またはそれらの組み合わせ上に実現され得る。

読み出しについて、ストレージゲートウェイ２５２は、最初に、キャッシュから所与の読み出しを履行することができるかどうか、ローカルキャッシュを確認し得る。ローカルキャッシュから読み出しを履行することができない場合、ストレージゲートウェイ２５２は、ストレージサービス２１２からデータを要求し得、該要求は、リモートデータストア２１６から要求されたデータ（または要求されたデータを含むデータのブロックまたはチャンク）を獲得し、要求されたデータをストレージゲートウェイ２５２に返す。ストレージゲートウェイ２５２は、ストレージサービス２１２から受け取られるデータのブロックまたはチャンクをローカルキャッシュに記憶し得る。

書き込みについて、ストレージゲートウェイ２５２は、新しいまたは更新されたデータをローカルキャッシュに書き込み得る。少なくともいくつかの実施形態において、書き込みデータは、ローカルキャッシュに実現されるブロックに基づく書き込みログに添付され得る。ストレージゲートウェイ２５２は、送り側データアップロードプロセス（図示せず）を含み得、該プロセスは、ローカルキャッシュの中の新しいまたは修正されたデータを主データストア２１６に定期的に、非定期的に、または連続的にアップロードするために、サービスプロバイダ２１０で、受け取り側データアップロードプロセス（図示せず）と通信する。書き込みログから書き込みデータをアップロードすることは、ローカルデータストア２５４に対する開始プロセスからの読み出しおよび書き込み操作の処理と非同期で行われ得る。少なくともいくつかの実施形態において、このアップロードプロセスは、データ重複排除、圧縮、並列化、およびＴＣＰウインドウスケーリング手法のうちの１つ以上を利用し得る。図６で示される少なくともいくつかの実施形態において利用され得る例示的なデータ重複排除手法は、米国特許出願第１２／９８１，３９３号および第１２／９８１，３９７号で説明される。

ローカルキャッシュは、大きさが制限され得るが、リモートデータストア２１６は、本質的に無制限のストレージ空間を提供し得る。したがって、ストレージゲートウェイ２５２は、ローカルキャッシュの中のより古いおよび／または比較的非アクティブなデータブロックを除去するか、より新しいおよび／またはアクティブなデータブロックで置き換えるか、または上書きし得る。

シャドウ化ゲートウェイの実現例
図７は、ストレージゲートウェイの実施形態がシャドウ化ゲートウェイとして構成される例示的なネットワーク環境におけるアーキテクチャおよびその中のデータフローを大まかに図示する、高次ブロック図である。図７において、ストレージゲートウェイ２５２は、顧客の書き込みデータ（例えば、ｉＳＣＳＩ書き込み）のシャドウ化を、ストレージサービス２１２によって提供されるリモートストレージに提供するために、顧客のアプリケーションと顧客のローカルデータストアとの間の「バンプインザワイヤ」として作用するシャドウ化ゲートウェイとして機能するように導入され、起動され、そして構成され得る。リモートデータストア２１６は、ブロックストレージとして実現され得る。

リモートデータストア２１６が主データストアとして機能する図６のキャッシュされたゲートウェイの実現例とは対照的に、図７で図示される実施形態では、ローカルデータストア２５４が、クライアントネットワーク２５０上の顧客プロセス（複数可）２５８の主データストアとして機能する。ストレージゲートウェイ２５２がシャドウ化ゲートウェイとして導入され、起動され、そして構成されると、ストレージゲートウェイ２５２は、１つ以上のデータポート（例えば、ｉＳＣＳＩポート）をクライアントネットワーク２５０上の顧客プロセス（複数可）２５８に公表する。クライアントネットワーク２５０上の顧客プロセス（複数可）２５８は、次いで、ストレージゲートウェイ２５２データポート（複数可）を介して、ローカルデータストア２５４から読み出し、それに書き込み得る。顧客プロセス２５８は、クライアントネットワーク２５０上に存在し、また、ゲートウェイ２５２のデータポートのデータプロトコル（例えば、ｉＳＣＳＩプロトコル）を介して、ストレージゲートウェイ２５２に接続し、それと通信することができる、任意のハードウェア、ソフトウェア、および／またはそれらの組み合わせであり得る。顧客プロセス２５８は、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）、ＳｈａｒｅＰｏｉｎｔ（登録商標）、およびＯｒａｃｌｅ（登録商標）データベース等のストレージアプリケーション、サーバ（例えば、ＳＱＬサーバ、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ（登録商標）サーバ等）、データベースアプリケーション（例えば、ＳＱＬデータベースアプリケーション、およびＯｒａｃｌｅ（登録商標）データベースアプリケーション）、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ（登録商標）アプリケーション、またはストレージゲートウェイ２５２データポート（複数可）と通信するように動作可能である、クライアントネットワーク２５０上で１つ以上のデバイスを実行する任意の他のアプリケーションまたはプロセスであり得る。顧客プロセスは、本明細書で使用されるときに、クライアントネットワーク２５０の中の１つ以上のデバイス上で実行され得る、任意のソフトウェアプロセスを包含する。しかしながら、顧客プロセスを実行する下層のハードウェアは、プロセスを代表するストレージゲートウェイ２５２データポート（複数可）に対する接続および通信に関与し得るか、またはそれらを行い得ることに留意されたい。

読み出しおよび書き込み要求は、ゲートウェイ２５２データポート（複数可）によって受け取られ得る。読み出しについて、要求は、ゲートウェイ２５２によるさらなる介入または処理を伴わずに、ローカルデータストア２５４に直接渡され得、要求されたデータは、ローカルデータストア２５４から顧客プロセス２５８に直接渡され得る。ローカルデータストア２５４に向けられる書き込み要求も、ストレージゲートウェイ２５２によってローカルデータストア２５４に渡される。しかしながら、書き込み要求をローカルデータストア２５４に渡すことに加えて、ストレージゲートウェイ２５２は、書き込み要求によって示される新しいまたは更新されたデータを、ストレージサービス２１２を介して、リモートデータストア２１６にシャドウ化し得る。

少なくともいくつかの実施形態において、新しいまたは更新されたデータをリモートデータストア２１６にシャドウ化するために、ストレージゲートウェイ２５２は、リモートデータストア２１６にアップロードされる書き込みデータを、例えば先入れ先出し（ＦＩＦＯ）書き込みログで、ローカルに記憶またはバッファリングし得る。少なくともいくつかの実施形態において、書き込みログは、ブロックストレージ形式で実現され得、書き込みログは、１つ以上のブロック（例えば、４ＭＢブロック）を備える。書き込み要求で受け取られる書き込みデータは、書き込みログに添付され得る。２つ以上の書き込み要求からの書き込みデータは、書き込みログの中の同じブロックに書き込まれ得る。ブロックに関連する書き込みデータのメタデータ、例えば書き込みログブロックにおける長さおよびオフセット、ならびにターゲットデータストアにおけるオフセットは、メタデータストアに記憶され得る。

ストレージゲートウェイ２５２は、送り側データアップロードプロセス（図示せず）を含み得、該プロセスは、リモートデータストア２１６で、ローカルに記憶された書き込みデータを、書き込みログからシャドウ化されたデータボリュームに定期的に、非定期的に、または連続的にアップロードするために、サービスプロバイダ２１０で、受け取り側データアップロードプロセス（図示せず）と通信する。書き込みログから書き込みデータをアップロードすることは、ローカルデータストア２５４に対する開始プロセスからの読み出しおよび書き込み操作の処理と非同期で行われ得る。アップロードプロセスは、ブロックの中の書き込みログから書き込みデータをアップロードし得る。書き込みログブロックが成功裏にアップロードされると、対応するブロックが、書き込みログの中で空きとしてマークされ得る。

少なくともいくつかの実施形態において、アップロードプロセスは、データ重複排除、圧縮、並列化、およびＴＣＰウインドウスケーリング手法のうちの１つ以上を利用し得る。図７で示される少なくともいくつかの実施形態において利用され得る例示的なデータ重複排除手法は、米国特許出願第１２／９８１，３９３号および第１２／９８１，３９７号で説明される。

サービスプロバイダフロントエンド２８０は、ストレージゲートウェイ２５２への接続を管理し得ることに留意されたい。少なくともいくつかの実施形態において、ストレージゲートウェイ２５２は、フロントエンド２８０を介して、サービスプロバイダ２１０への接続を開始し、サービスプロバイダ２１０は、ゲートウェイ２５２への接続を開始しない。フロントエンド２８０としては、ファイアウォール、境界ルータ、ロードバランサ、ゲートウェイサーバ、ゲートウェイプロキシ、コンソールプロセス、ならびに一般に、ストレージサービス２１２をクライアントネットワーク（複数可）２５０に公表するために、およびストレージサービス２１２をストレージゲートウェイ（複数可）２５２にインターフェースするために必要であり得る、任意のネットワーキングデバイスおよび／もしくはプロセスのうちの１つ以上が挙げられ得るが、それらに限定されない。

少なくともいくつかの実施形態において、ストレージゲートウェイ２５２は、サービスプロバイダフロントエンド２８０を介して、サービスプロバイダ２１０への全ての接続を開始し、サービスプロバイダ２１０は、ゲートウェイ２５２への接続を開始しない。加えて、ネットワーク管理者プロセス２６０は、ゲートウェイ２５２への直接接続を開始せず、例えばゲートウェイ２５２を構成し、管理するための、ネットワーク管理者プロセス２６０によるゲートウェイ２５２へのアクセスは、サービスプロバイダフロントエンド２８０を介して、サービスプロバイダ２１０を通る。

シャドウ化ゲートウェイとして、ストレージゲートウェイ２５２によって提供されるシャドウ化操作は、クライアントネットワーク２５０上のユーザの観点から、事実上透過的であり得る。顧客プロセス（複数可）２５８は、クライアントネットワーク２５０上のストレージゲートウェイ２５２によって公表されるデータポート（複数可）（例えば、ｉＳＣＳＩポート（複数可））に対する読み出しおよび書き込みを行う。顧客プロセス２５８の観点から、ストレージゲートウェイ２５２は、任意の他のデータターゲット（例えば、ｉＳＣＳＩターゲット）として現れ得る。データポート上で受け取られる顧客プロセス（複数可）２５８からの読み出し要求は、主データストアとして機能するローカルデータストア２５４に渡される。データポート上で受け取られる顧客プロセス（複数可）２５８からの書き込み要求は、ローカルデータストア２５４に渡され、リモートデータストア２１６にシャドウ化される。ゲートウェイ２５２のシャドウ化操作は、主データストアまたはクライアントネットワーク２５０の性能に大きな影響を及ぼすことなく、バックグラウンドで行われ得る。

図７で図示される「バンプインザワイヤ」のシャドウ化ゲートウェイ構成の例示的な使用事例は、障害からの復元である。ストレージゲートウェイ２５２は、クライアントネットワーク２５０からストレージサービス２１２にデータの更新を送り、該ストレージサービスは、該データを、スナップショット２７０とも称される、１つまたは複数のシャドウボリュームに記憶する。データは、ブロックストレージ形式のスナップショット２７０に記憶され得る。データはまた、ローカルデータストア２５４にも記憶される。ローカルに記憶されたボリュームの一部分または全部の破損または喪失をもたらすような何かが起こった場合、破損または喪失したデータは、データストア２１６に記憶されたボリュームのスナップショット２７０から復元され得る。ストレージプロバイダ２１０は、インターフェースを提供し、それを介して、顧客ネットワーク管理者は、（例えば、ネットワーク管理者プロセス２６０を介して）リモートデータストア２１６上のシャドウ化されたボリュームから、ローカルに記憶されたボリュームの一部分または全部のスナップショット２７０の復元を要求し得る。少なくともいくつかの実施形態において、ストレージゲートウェイ２５２によって維持される書き込みログの少なくとも一部分は、そこからデータが復元されるシャドウ化されたボリュームができる限り最新であることを確実にするために、データのスナップショット２７０を復元する前に、リモートデータストア２１６にアップロードされ得る。一部の場合において、少なくともいくつかのデータは、ストレージゲートウェイ２５２によって維持される書き込みログから直接復元され得ることに留意されたい。

顧客プロセスとゲートウェイとの通信
上で説明されるように、顧客管理者は、ネットワーク管理者プロセス２６０を介して、例えばゲートウェイ２５２を構成するために、サービスプロバイダ２８０フロントエンドを介して、ストレージゲートウェイ２５２（例えば、シャドウ化ゲートウェイ）と通信し得る。少なくともいくつかの実施形態において、１つ以上の顧客プロセス２５８はまた、ゲートウェイ２５２の要求を行うために、サービスプロバイダ２８０フロントエンドを介して、ストレージゲートウェイ２５２と通信するようにも構成され得る。例えば、顧客プロセス２５８は、サービスプロバイダ２８０フロントエンドを介して、ストレージゲートウェイ２５２と通信するように構成される、ＳＱＬサーバであり得る。

シャドウ化ゲートウェイブートストラッピング手法
図７で図示されるように、ストレージゲートウェイ２５２がシャドウ化ゲートウェイとして導入され、起動され、そして構成されると、ストレージゲートウェイ２５２は、１つ以上のデータポート（例えば、ｉＳＣＳＩポート）をクライアントネットワーク２５０上の顧客プロセス（複数可）２５８に公表する。クライアントネットワーク２５０上の顧客プロセス（複数可）２５８は、次いで、ストレージゲートウェイ２５２データポート（複数可）を介して、ローカルデータストア２５４から読み出し、それに書き込み得る。読み出しおよび書き込み要求は、ローカルデータストア２５４に渡され、書き込み要求によって示される書き込みデータは、ローカルデータストアのスナップショット（複数可）２７２が更新され得るように、リモートデータストア２１６にシャドウ化される。

しかしながら、シャドウ化ゲートウェイが顧客のネットワークでオンラインになると、最初に導入され、起動され、そして構成されるときに、または何らかの理由でオフラインになった後に、リモートデータストア２１６上のスナップショット（複数可）２７２にはないデータが、ローカルデータストア２５４の中にあり得る。したがって、少なくともいくつかの実施形態は、ゲートウェイをシャドウ化するためのブートストラッピングプロセスを提供し得、該プロセス中には、現在ローカルデータストア２５４上にあるデータを正確に反映するために、スナップショット（複数可）をポピュレートおよび／または更新できるように、ローカルデータストア２５４からの少なくともいくつかのデータが、リモートデータストア２１６にアップロードされ得る。

図８は、少なくともいくつかの実施形態による、例示的なネットワーク環境におけるシャドウ化ゲートウェイのブートストラッピングを大まかに図示する、高次ブロック図である。ストレージゲートウェイ２５２がクライアントネットワーク２５０上でシャドウ化ゲートウェイとしてオンラインになると、ゲートウェイ２５２は、スナップショット２７２をローカルデータストア２５４と一致させるために、リモートデータストア２１６にアップロードする必要があるデータが、ローカルデータストア２５４の中にあると判定し得る。ゲートウェイ２５２のアップロードプロセスは、次いで、ローカルデータストア２５４からサービスプロバイダ２１０のリモートデータストア２１６にデータのブロックをアップロードし始め得る。ストレージゲートウェイ２５２はまた、そのデータポートを顧客プロセス２５８に公表し、ローカルデータストア２５４に向けられた読み出し要求および書き込み要求を受け付け、処理し始め、書き込み要求によって示される新しい書き込みデータを書き込みログにキャッシュし始め、そして、書き込みログからリモートデータストア２１６に書き込みデータをアップロードし始め得る。したがって、ローカルデータストア２５４からのデータのアップロードは、ストレージゲートウェイ２５２がクライアントネットワーク２５０上でそのシャドウ化機能を行っている間に、バックグラウンドで行われ得る。ローカルデータストア２５４からのデータのアップロードが完了すると、ストレージゲートウェイ２５２は、そのシャドウ化機能を行い続ける。

図９は、少なくともいくつかの実施形態による、シャドウ化ゲートウェイのためのブートストラッピングプロセスのフローチャートである。３００で示されるように、シャドウ化ゲートウェイは、顧客のネットワーク上でオンラインになる。例えば、ストレージゲートウェイの新しいインスタンスは、ネットワーク上のシャドウ化ゲートウェイとして導入され、起動され、そして構成され得る。別の例として、シャドウ化ゲートウェイの既存のインスタンスは、何らかの理由でオフラインになった後に、オンラインに戻り得、ゲートウェイがオフラインである間、顧客プロセス（複数可）は、データの読み出しおよび書き込みを行うために、ローカルデータストアに直接通信した場合がある。別の例として、シャドウ化ゲートウェイがパススルーモードに入った場合があり、その間、シャドウ化操作は、何らかの理由で、例えば書き込みログが満杯になっているため、一時的に中断され、そしてパススルーモードを出て、シャドウ化操作を再開している場合がある。

３０２で示されるように、シャドウ化ゲートウェイは、必要であれば、ローカルデータストアからリモートデータストアに既存のデータをアップロードし始め得る。例えば、これが新しいシャドウ化ゲートウェイであり、かつローカルデータストアが既にポピュレートされている場合は、一致したスナップショットを生成できるように、ローカルデータストアの中の既存のデータが、リモートデータストアにアップロードされる必要がある。別の例として、既存のシャドウ化ゲートウェイがオンラインに戻るか、またはパススルーモードを出てシャドウ化操作を再開する場合は、新しいデータがローカルデータストアに書き込まれた場合があり、したがって、リモートデータストア上のスナップショットを、現在ローカルデータストア上にあるデータと一致させる必要がある。

３０４で示されるように、シャドウ化ゲートウェイは、顧客のネットワークに公表されたゲートウェイデータポート（複数可）を介して、顧客プロセスからの読み出しおよび書き込みを受け付け始め得る。３０６で示されるように、シャドウ化ゲートウェイは、書き込みからの書き込みデータを書き込みログにキャッシュし始め得、また、３０８で示されるように、書き込みログからの書き込みデータをリモートデータストアにアップロードし始め得る。

３０２で開始されるローカルデータストアからのデータのアップロードは、シャドウ化ゲートウェイが、読み出しおよび書き込み要求を受け付け、顧客のネットワーク上でそのシャドウ化機能を行う間に、バックグラウンドで行われ得る。ローカルデータストアからのデータのアップロードが完了すると、シャドウ化ゲートウェイは、そのシャドウ化機能行い続ける。

図９の要素の順序は、異なり得ることに留意されたい。例えば、要素３０２は、３０４〜３０８のうちのいずれか１つの後に行われ得る。換言すれば、シャドウ化ゲートウェイは、ローカルデータストアから既存のデータをアップロードし始める前に、読み出しおよび書き込みを受け付け始め、そのシャドウ化機能を行い始め得る。

図１０は、少なくともいくつかの実施形態による、パススルーモードに入る、およびそこから復帰するシャドウ化ゲートウェイのフローチャートである。３２０で示されるように、シャドウ化ゲートウェイは、顧客のネットワーク上の顧客プロセスからローカルデータストアに向けられた読み出しおよび書き込みを受け付けおよび提供し続けながら、そのシャドウ化機能を中断（すなわち、書き込みデータのキャッシュおよびアップロードを停止）することによって、パススルーモードに入り得る。ゲートウェイは、シャドウ化機能を故障させ得る何らかの状態を検出した時点で、パススルーモードに入り得る。一例として、シャドウ化ゲートウェイは、書き込みログが満杯で、成功裏にアップロードできないことを検出した時点で、パススルーモードに入り得る。ゲートウェイは、検出された状態をローカルネットワーク管理者に警報を出し得、次いで、管理者は、警報によって示される問題に対処し得る。例えば、管理者は、より多くのメモリを書き込みログに割り当て得、および／またはより多くの帯域幅をゲートウェイアップロードプロセスに割り当て得る。管理者は、次いで、問題に対処したことをゲートウェイに通知し得る。

シャドウ化ゲートウェイが、例えばパススルーモードを生じさせた問題を検出し、それに対処した旨の指示を受け取ることによって、パススルーモードを出ることができると判定すると、３２２で示されるように、ゲートウェイは、シャドウ化を再開（すなわち、書き込みデータのキャッシュおよびアップロードを開始）し得る。

パルススルーモードを出た時点で、ローカルデータストアには、リモートデータストアにアップロードされなかったデータがあり得る。ゲートウェイは、パススルーモード中に書き込み要求を受け取り、処理し続けるので、新しいデータがローカルデータストアに書き込まれた場合がある。したがって、３２４で示されるように、シャドウ化ゲートウェイは、ローカルデータストアからリモートデータストアに少なくともいくつかのデータをアップロードして、パススルーモードから復帰するために、図８および図９で図示されるように、ブートストラップを行い得る。

少なくともいくつかの実施形態では、ローカルデータストアからリモートデータストアにアップロードされるデータの量を低減させるために、ゲートウェイをシャドウ化するための最適化されたブートストラッピングプロセスが利用され得る。最適化されたブートストラッピングプロセスは、リモートデータストアに既にアップロードされたデータのブロックを検出し得、したがって、既にアップロードされたブロックをアップロードすることを回避し得る。最適化されたブートストラッピングプロセスは、ゲートウェイからリモートデータストアへの全般的なアップロード中に、ストレージゲートウェイプロセスのために生成され、維持される、追跡データを活用し得る。

図１１は、少なくともいくつかの実施形態による、ゲートウェイからリモートデータストアにブロックをアップロードする、更新する、および追跡するための方法のフローチャートである。３６０で示されるように、標準的なゲートウェイ操作中に、ゲートウェイは、サービスプロバイダで書き込みデータをリモートデータストア、特にストレージデバイスにアップロードする。３４２で示されるように、ストレージサービスは、リモートデータストアから書き込みデータを受け取り、それぞれのブロック（複数可）（例えば、４ＭＢのブロック）を獲得する。３４４で示されるように、ストレージサービスは、次いで、書き込みデータに従ってそれぞれのブロック（複数可）を修正し、新しいバージョン名で、修正されたブロック（複数可）をリモートデータストアにアップロードして返す。３４６で示されるように、各修正されたブロックについて、修正されたブロックを示すトークンがストレージゲートウェイに返される。ストレージゲートウェイは、これらのトークンを追跡し、ブロックが修正される度に、修正されている基準ブロックをストレージサービスに送る必要がある。

３４８で示されるように、ストレージゲートウェイは、定期的または非定期的にサービスプロバイダでトークンマニフェストを更新し得、ローカルに追跡されるトークンの少なくとも一部分をパージし得る。ストレージゲートウェイは、多数のトークンを追跡する必要があり得る。少なくともいくつかの実施形態において、マニフェストは、リモートデータストアに提供され得、多数のトークンをローカルに追跡しなければならないといった、ストレージゲートウェイの負担を軽減し得る。ストレージゲートウェイは、ゲートウェイが受け取ったトークン（複数可）でマニフェストを更新するために、ストレージサービスを定期的または非定期的に呼び出し得、ローカルに記憶されたトークンのそれぞれをパージし得る。

少なくともいくつかの実施形態において、最適化されたブートストラッピングプロセスは、マニフェストを活用して、マニフェストの中のブロックのそれぞれのハッシュを確認するために呼び出しを行うことによって、どのブロックがアップロードされたのか、およびされなかったのかを判定して、マニフェストによって示されるどのブロックがローカルデータストア上のブロックに合致するか、これに対して、マニフェストによって示されるどのブロックがローカルデータストア上のブロックに合致せず、したがって、アップロードされる必要があるのかを判定し得る。換言すれば、マニフェストは、ローカルデータストア上のどのブロックがダーティブロックであるか、およびどれがそうでないかを検出するために使用される。したがって、最適化されたブートストラッピングプロセスは、既にアップロードされたブロックが再度アップロードされず、ダーティブロックだけがアップロードされるように、マニフェストを介して、どのブロックが既にアップロードされたのかを判定することを試みる。少なくともいくつかの実施形態において、最適化されたブートストラッピングプロセスが、アップロードする必要があると判定したブロック（ダーティブロック）について、ダーティブロックから実際にアップロードされるデータの量を低減させるために、これらのブロックをアップロードするときに、データ重複排除手法が適用され得る。

図１２は、少なくともいくつかの実施形態による、シャドウ化ゲートウェイのための最適化ブートストラッピングプロセスのフローチャートである。ブートストラッピングプロセスは、例えばゲートウェイがパススルーモードを出たときに、シャドウ化ゲートウェイのために開始され得る。３６０で示されるように、ブロックは、ローカルデータストアから取得される。３６２で示されるように、リモートデータストアに記憶され得るマニフェストは、現在のブロックが、アップロードする必要があるダーティブロックであるかどうかを判定するために確認され得る。３６４で、マニフェストに従って現在のブロックがダーティブロックである場合は、３６６で示されるように、データ重複排除手法に従って、ブロックの少なくとも一部分が、リモートデータストアにアップロードされ得る。方法は、次いで、３６８に進む。３６４で、現在のブロックがマニフェストに従ってダーティでない場合、方法は、３６８に直接進む。３６８で、より多くのブロックを処理すべき場合、方法は、次のブロックを処理するために、要素３６０に戻る。そうでない場合は、ブートストラッピングプロセスが行われる。

ストレージゲートウェイセキュリティモデル
ストレージゲートウェイの実施形態は、顧客のためのデータ保護、ならびに顧客または第三者によるゲートウェイの誤用および無許可の使用（例えば、権利の侵害）に対する保護を提供する、セキュリティモデルに従って実現され得る。図１３は、少なくともいくつかの実施形態による、ストレージゲートウェイのセキュリティモデルの態様を図示する図である。

少なくともいくつかの実施形態において、セキュリティモデルの態様は、ストレージゲートウェイ８４が、ゲートウェイ８４をサービスプロバイダ６０と通信する際に使用するためのセキュリティ証明書または他の識別情報を伴わずに、クライアントネットワーク８０に送達され、最初に導入される。それを介して顧客ネットワーク上のストレージゲートウェイ８４をサービスプロバイダ６０に登録することができる、起動プロセスが利用され得る。起動プロセスの少なくともいくつかの実施形態において、ストレージゲートウェイ８４は、必要なセキュリティ証明書を取得するために、サービスプロバイダ６０との接続（例えば、ＳＳＬ（セキュアソケットレイヤ）／ＴＣＰ接続）を開始し、それぞれの顧客アカウントの正しいゲートウェイとして、それ自体を該サービスプロバイダに識別させ得る。起動プロセス中に、サービス顧客は、ゲートウェイ８４の名前を指定する。少なくともいくつかの実施形態において、サービス顧客は、サービスプロバイダ６０で顧客のアカウントにログインし、ゲートウェイ８４を登録する際に使用される、ゲートウェイ名が挙げられるが、それに限定されない、情報をサービスプロバイダ６０に提供する。しかしながら、サービス顧客は、ストレージゲートウェイ８４にログインせず、したがって、サービス顧客のセキュリティ証明書および他のアカウント情報は、ゲートウェイ８４上に公表されない。これは、サービス顧客のセキュリティリスクを最小化し得る。このゲートウェイ名は、ゲートウェイ８４およびサービス顧客に関連する他のメタデータとともに、サービスプロバイダ６０によって記憶され得、それぞれのゲートウェイ８４を追跡し、識別する際に使用され得る。サービス顧客は、クライアントネットワーク８０に導入され、そして起動される１つ以上のゲートウェイ８４を有し得、それぞれが、固有の識別名および他のメタデータを有することに留意されたい。図１５〜図１７Ｂは、下の「ストレージゲートウェイ起動プロセス」という標題の項でさらに説明され、少なくともいくつかの実施形態において利用され得る起動プロセスを図示する。起動プロセスにおいて、ゲートウェイ８４は、サービスプロバイダ６０への接続を開始し、公開鍵とともに、ゲートウェイ８４プラットフォームに関するメタデータをサービスプロバイダ６０に提供し得る。サービスプロバイダ６０は、次いで、起動プロセスで使用される一時的な固有の起動鍵をゲートウェイ８４に提供し得る。加えて、サービス顧客は、ゲートウェイ８４を起動させるために、サービスプロバイダコンソールプロセスを介して、顧客のアカウントにログインすることが必要とされ得、したがって、ゲートウェイ８４を、ゲートウェイ８４を起動させることを試みるサービス顧客のアカウントと照合することができる。起動プロセスを介して、ストレージゲートウェイ８４によって取得される、セキュリティ証明書および他のメタデータ（例えば、顧客供給のゲートウェイ名）は、次いで、ゲートウェイ８４をサービスプロバイダ８４プロセスに識別させるために、サービスプロバイダ６０ネットワークの種々のプロセスと通信する際に、ストレージゲートウェイ８４によって使用され得る。

少なくともいくつかの実施形態において、図１３で図示されるセキュリティモデルの別の態様は、ストレージゲートウェイ８４が、クライアントネットワーク８０上の顧客プロセス（複数可）８８に公表される１つ以上のデータポート（例えば、ｉＳＣＳＩポート）への、外部主導の接続だけを受け付ける。ストレージゲートウェイは、他の外部主導の接続を受け付けず、外部プロセスへの全ての必要な接続を開始する。例えば、少なくともいくつかの実施形態において、ストレージゲートウェイ８４は、サービスプロバイダ６０への少なくとも１つの安全な接続９２（例えば、ＳＳＬ（セキュアソケットレイヤ）／ＴＣＰ接続）を開始する。しかしながら、サービスプロバイダ６０は、ゲートウェイ８４への接続を開始することができない。少なくともいくつかの実施形態で使用され得る、ゲートウェイ主導の接続およびロングポーリング手法を使用する、リモートゲートウェイ管理のための例示的な方法は、図１８〜図２０で図示される。

加えて、図１３で図示されるように、少なくともいくつかの実施形態において、サービス顧客（例えば、ネットワーク管理者プロセス９０）は、ゲートウェイ８４を構成し、管理するために、ストレージゲートウェイ８４に直接接続せず、代わりに、サービスプロバイダ６０を通して、ストレージゲートウェイ８４の構成要求および操作要求が行われ、該サービスプロバイダは、ゲートウェイ８４によって開始される安全な通信チャネル９２を介して、該要求をゲートウェイ８４に渡す。例えば、図１８〜図２１で図示されるように、ストレージゲートウェイ８４の構成要求および操作要求は、サービスプロバイダ６０ネットワーク上のコンソールプロセスを通して、ネットワーク管理者プロセス９０によって、またはそれを介して行われ得る。少なくともいくつかの実施形態において、コンソールプロセスは、顧客のゲートウェイ８４に向けられた、受け取った構成要求または操作要求を、ゲートウェイ主導の接続９２を維持するゲートウェイ制御プレーンに転送する。ゲートウェイ制御プレーンは、要求のターゲットであるゲートウェイ８４への現在の接続、例えば特定のゲートウェイ制御サーバ上で維持される接続の場所を特定し、該要求は、該接続を介して、ゲートウェイ８４に転送される。

したがって、少なくともいくつかの実施形態において、ユーザ、ネットワーク管理者、または顧客のプロセスは、ストレージゲートウェイ８４への接続または「ログイン」を直接開始することができず、また、サービスプロバイダ６０ネットワーク上のオペレータまたはプロセス等の、外部の人々またはプロセスも、ストレージゲートウェイ８４への接続を開始することができない。これは、ゲートウェイセキュリティモデルの他の態様とともに、セキュリティ証明書およびストレージゲートウェイ８４に関するセキュリティ証明書および他の操作情報が、外部の人々もしくはプロセスによって意図的に、または意図せずに危殆化されることから保護するのを補助する。

セキュリティモデルの別の態様において、ゲートウェイの起動中および操作中の、ストレージゲートウェイとストレージサービスとの間の全ての通信は、安全にされ、暗号化され得る。上で述べられるように、セキュリティモデルの態様は、ストレージゲートウェイとストレージサービスとの間の通信が、ゲートウェイ主導の安全な接続（例えば、ＳＳＬ／ＴＣＰ接続）を通じて行われる。暗号化方法、例えば公開鍵／秘密鍵暗号化は、ゲートウェイ主導の安全な接続を通じた通信の際に使用され得る。

図１４は、少なくともいくつかの実施形態による、ストレージゲートウェイの起動中、構成中、および動作中のゲートウェイセキュリティモデルの少なくともいくつかの態様を図示する、フローチャートである。４００で示されるように、ストレージゲートウェイは、顧客ネットワーク上にインスタンス化され得る。例えば、ストレージゲートウェイをインスタンス化するために、ストレージゲートウェイは、サービス顧客のローカルネットワークまたはデータセンター上の仮想または物理機器として、一般的にファイアウォールの背後に導入され得る。例えば、少なくともいくつかの実施形態において、ストレージゲートウェイは、サービス顧客のローカルネットワーク上のサーバシステム等の、１つ以上のコンピューティングデバイスにダウンロードされ得る、または別様にはそれに導入され得る、仮想機器として実現され得る。あるいは、ストレージゲートウェイは、サービス顧客のローカルネットワークに連結され得る、専用のデバイスまたは機器として実現され得、専用のデバイスまたは機器は、ストレージゲートウェイの機能を実現する、ソフトウェアおよび／またはハードウェアを含み得る。４０２で示されるように、インスタンス化されたストレージゲートウェイは、ゲートウェイを識別し、ゲートウェイのセキュリティ証明書を取得するために、サービスプロバイダおよび顧客による起動プロセスを開始する。少なくともいくつかの実施形態において、セキュリティ証明書は、ゲートウェイ提供の公開鍵で署名される証明書を含む。例示的な起動プロセスは、図１５〜図１７Ｂを参照して下で説明される。起動プロセスは、ゲートウェイが顧客ネットワークに最初に導入されるときに、ゲートウェイによって開始され得、また、他のとき、例えば、アップグレード、維持管理、または他の何らかの理由でゲートウェイデバイスの電源が切られた後に電源を入れるときにも開始され得ることに留意されたい。図１４の４０４で示されるように、ストレージゲートウェイは、サービスプロバイダへの安全な接続を確立する。少なくともいくつかの実施形態で使用され得るロングポーリング手法を使用する、ゲートウェイ主導の接続のための例示的な方法は、図１８〜図２１で図示される。図１４の４０６で示されるように、顧客は、サービスプロバイダコンソールプロセスを通して、ストレージゲートウェイを構成し、操作する。少なくともいくつかの実施形態で使用され得る、ゲートウェイ主導の接続およびロングポーリング手法を使用するリモートゲートウェイ管理のための例示的な方法は、図１８〜図２１で図示される。図１４の４０８で示されるように、ストレージゲートウェイは、例えばストレージサービスプロセスと通信するために、サービスプロバイダへのゲートウェイを識別するために起動プロセス中に取得される、ゲートウェイセキュリティ証明書および場合により他のメタデータを使用して、サービスプロバイダと通信する。

ストレージゲートウェイ起動プロセス
ストレージゲートウェイの実施形態は、例えば、施設内ストレージデバイスとして、また、サービス顧客のネットワークとサービスプロバイダによって提供されるストレージサービスとの間のインターフェースとして機能し得る。少なくともいくつかの実施形態において、ストレージゲートウェイは、顧客のデータセンターで顧客のローカルネットワークインフラストラクチャに連結されるサーバシステム等の、１つ以上のコンピューティングデバイスにダウンロードまたは別様には導入され得る、仮想デバイスまたは機器として実現され得る。あるいは、ストレージゲートウェイは、顧客のローカルネットワークインフラストラクチャに連結され得る、専用のデバイスまたは機器として実現され得る。専用のデバイスまたは機器は、ゲートウェイの機能を実現する、ソフトウェアおよび／またはハードウェアを含み得る。

少なくともいくつかの実施形態において、ゲートウェイが導入された後にストレージゲートウェイを使用するために、ゲートウェイは、サービスプロバイダによって起動されなければならない。この項は、ストレージゲートウェイのブートストラッピング中または起動中に、それを介してストレージゲートウェイの識別、認証、および許可が行われ得る方法を説明する。ゲートウェイ起動方法において、ストレージゲートウェイは、識別され、顧客のサービスプロバイダアカウントと関連付けられる。しかしながら、顧客の証明書は、起動プロセス中に、ストレージゲートウェイに公表されない。少なくともいくつかの実施形態において、顧客は、サービスプロバイダとの顧客のアカウントにログインし、ゲートウェイ８４を登録する際に使用される、ゲートウェイ名が挙げられるが、それに限定されない、情報をサービスプロバイダに提供する。しかしながら、顧客は、ストレージゲートウェイにログインせず、したがって、顧客のセキュリティ証明書および他のアカウント情報は、ゲートウェイに公表されない。これは、顧客のためのセキュリティリスクを最小化し得る。少なくともいくつかの実施形態において、起動プロセスの際に顧客によって使用されるサービスプロバイダアカウントは、図５で図示されるストレージサービスによって提供される他のストレージリソース、およびハードウェア仮想サービスによって提供される仮想ハードウェアリソースが挙げられるが、それらに限定されない、サービスプロバイダによって顧客に提供される他のリソースを管理するために使用される、顧客のアカウントと同じであり得る。

図１５は、少なくともいくつかの実施形態による、ゲートウェイ起動プロセスに関与するサービス顧客およびサービスプロバイダの構成要素またはエンティティを図示する、例示的なネットワーキング環境の高次ブロック図である。これらに関与するものとしては、ストレージゲートウェイ８４、ネットワーク管理者プロセス９０、コンソールプロセス６８、およびゲートウェイ制御７０が挙げられるが、それらに限定され得ない。ストレージゲートウェイ８４は、サービス顧客ローカルネットワークまたはデータセンター（例えば、クライアントネットワーク８０）上の仮想または物理機器として、一般的にファイアウォールの背後に導入され得る。例えば、ストレージゲートウェイ８４は、例えば仮想マシン内で実行する、仮想機器であり得、クライアントネットワーク８０上のサーバデバイスにダウンロードされ得、インスタンス化され得る。サービスプロバイダ６０ネットワーク上のコンソールプロセス６８は、顧客のアカウントに署名するために、例えばクライアントネットワーク８０上のデバイスから、またはクライアントネットワーク８０の外部のデバイスから、ネットワーク管理者プロセス９０によって、またはそれを介してアクセス可能であり得る。例えば、コンソールプロセス６８は、ネットワーク管理者が、それを介してサービスプロバイダ６０によって提供されるアカウントおよびリソースを閲覧および管理するために、ネットワーク管理者プロセス９０を介して、それぞれのサービス顧客のアカウントに署名し得る、ウェブインターフェースまたは他の何らかのインターフェースを提供し得る。サービスプロバイダ６０ネットワークのゲートウェイ制御７０プロセスまたはプレーンは、サービスプロバイダ６０の１人以上の顧客で導入される１つ以上のストレージゲートウェイ（複数可）８４のための追跡および管理機能を行い得る。ゲートウェイ制御７０およびコンソールプロセス６８は、例えば、サービスプロバイダ６０ネットワーク上の１つ以上のサーバコンピュータデバイス上に実現され得る。少なくともいくつかの実施形態において、ゲートウェイ制御７０は、ロードバランシングおよび高可用性を提供するために２つ以上のゲートウェイ制御サーバを含む、制御プレーンとして実現され得る。

図１６Ａおよび１６Ｂは、少なくともいくつかの実施形態による、ゲートウェイ起動プロセス中の、図１５で図示される構成要素の間の相互作用を図示する、プロセスフロー図である。起動プロセスは、顧客の観点から、２つの点の相互作用を伴う。第１に、図１６Ａで示されるように、顧客は、ゲートウェイ８４と相互作用する。第２に、図１６Ｂで示されるように、顧客は、サービスプロバイダ（ＳＰ）コンソール６８と相互作用する。

図１６Ａは、起動プロセス中の、顧客（図１５で、ネットワーク管理者プロセス９０によって表される）と、ゲートウェイ８４と、サービスプロバイダ（ＳＰ）ゲートウェイ制御７０との間の相互作用を図示する。ゲートウェイ８４が導入された後に、および／または電源が入れられた後に、ゲートウェイ８４は、公開鍵（例えば、ＲＳＡ鍵対）を生成し、ゲートウェイ８４が導入されたデバイスのハードウェアおよび／またはソフトウェアに関するメタデータを収集する。例えば、メタデータは、デバイスのＩＰアドレス、ＭＡＣアドレス、または他のハードウェアおよびソフトウェア特徴を含み得る。ゲートウェイ８４は、次いで、例えばＨＴＴＰ ＰＯＳＴを介して、公開鍵およびメタデータをゲートウェイ制御７０に公開する。それに応じて、ゲートウェイ制御７０は、起動鍵を生成し、該起動鍵をゲートウェイ８４に返し得る。起動鍵は、グローバル一意識別子（ＧＵＩＤ）、例えばＮビットのランダムに生成された数であり得る。ゲートウェイ制御７０は、ゲートウェイ８４から取得される公開鍵およびメタデータとともに、起動鍵を記憶し得る。

ゲートウェイ制御７０から起動鍵を受け取った後に、ゲートウェイ８４は、固定ポート（ＩＰアドレス：ポート）のクライアントネットワーク８０内の起動鍵をゲートウェイ８４ＶＭまたはデバイス上で広告する。顧客は、次いで、ネットワーク管理者プロセス９０を介して、起動鍵を取得するためにゲートウェイ８４の固定ポートにアクセスし得、アクセスは、クエリ文字列での起動鍵を伴うサービスプロバイダ（ＳＰ）コンソール６８プロセスにリダイレクトされる。

少なくともいくつかの実施形態において、起動鍵は、一定の時間または寿命（例えば、３０分）にわたって有効であり、その後に、起動鍵は失効する。少なくともいくつかの実施形態において、起動鍵は、規定の寿命にわたってだけ有効であるので、失効した起動鍵を除去するバックグラウンドガーベージコレクションプロセスがサービスプロバイダ６０に提供される。少なくともいくつかの実施形態において、起動鍵の寿命は、境界事例を処理するために、ゲートウェイ８４上よりもサービスプロバイダ６０側の方が長くなり得る（例えば、サービスプロバイダ６０側で４５分、ゲートウェイ８４上で３０分）。

図１６Ｂは、起動プロセス中の、顧客（図１５で、ネットワーク管理者プロセス９０によって表される）と、サービスプロバイダ（ＳＰ）コンソール６８と、サービスプロバイダ（ＳＰ）ゲートウェイ制御７０との間の相互作用を図示する。ネットワーク管理者プロセス９０が、ゲートウェイ８４から起動鍵を取得すると、起動鍵は、ゲートウェイ９５を顧客のサービスプロバイダ６０アカウントに加えるために使用され得る。ＳＰコンソール６８にリダイレクトされた後に、顧客は、（例えば、ネットワーク管理者プロセス９０を介して）アカウントにログインし、クエリ文字列からの起動鍵は、ゲートウェイ８４がゲートウェイ制御７０に公開したメタデータをフェッチするために使用される。少なくとも、このメタデータの一部は、（例えば、ネットワーク管理者プロセス９０を介して）顧客に表示される。ゲートウェイ制御７０からＳＰコンソール６８に返され、顧客９０に表示されるメタデータは、ゲートウェイ８４によってゲートウェイ制御７０に以前提供されたメタデータであり、ゲートウェイ８４が起動されることに関して顧客９０に通知するために使用され得る。表示されるメタデータは、メタデータによって示されるそれぞれのゲートウェイ８４が、顧客のネットワークに導入されたゲートウェイ８４であることを、顧客９０に確認し得る。例えば、ゲートウェイ８４のＩＰアドレスが表示され得、顧客９０は、ゲートウェイ８４のＩＰアドレスを確認し得る。加えて、アカウントにログインするために顧客９０から取得される証明書（例えば、顧客のアカウント番号および／または他の顧客識別情報）は、顧客９０をそれぞれのゲートウェイ８４を所有する顧客として認証し、顧客９０をそれぞれのゲートウェイ８４と関連付ける際に使用され得る。

顧客９０はまた、ＳＰコンソール６８によって、追加的な情報、例えばゲートウェイ８４の名前を入力するように促し得る。表示されたメタデータを閲覧し、検証した後に、顧客９０は、ＳＰコンソール６８を介して、例えば「確認」または「起動」または「登録」のユーザインターフェース要素を選択することによって、ゲートウェイ制御７０によるゲートウェイ８４の登録を許可し得る。顧客９０が、ＳＰコンソール６８を介して、ゲートウェイ８４の登録を許可すると、ＳＰコンソール６８は、顧客９０から取得される起動鍵をゲートウェイ制御７０に渡し得る。ゲートウェイ８４の顧客供給の名前、顧客アカウントＩＤ等の顧客情報も、ゲートウェイ制御７０に渡され得る。顧客供給の起動鍵は、ゲートウェイ８４によってゲートウェイ制御７０に以前提供された起動鍵と照合される。顧客情報（例えば、ゲートウェイ８４の名前）は、例えばゲートウェイ８４によって以前提供されたメタデータとともに、ゲートウェイ制御７０によって記憶される。

少なくともいくつかの実施形態において、ＳＰコンソール６８とＳＰゲートウェイ制御７０との間、およびゲートウェイ８４とＳＰゲートウェイ制御７０との間で交換される全てのデータは、暗号化され得る。少なくともいくつかの実施形態において、顧客の証明書、アクセス鍵、または秘密鍵等の機密データは、起動プロセスで渡されない。

図１６Ａを再度参照すると、少なくともいくつかの実施形態において、ＳＰゲートウェイ制御７０は、ゲートウェイ８４の登録および起動に関連する全ての情報を維持する責任を負う。ゲートウェイ８４は、その一方で、証明書署名要求（ＣＳＲ）を生成するために情報を要求するＳＰゲートウェイ制御７０に連続的にポーリングする。図１６Ｂで示されるように、ＳＰゲートウェイ制御７０がＳＰコンソール６８を介して顧客９０から許可を受け取り、顧客供給の起動鍵をゲートウェイ８４によって提供される起動鍵と照合すると、ＳＰゲートウェイ制御７０は、図１６Ｂで示されるように、顧客９０から受け取られる顧客情報の少なくともいくつかが挙げられるが、それらに限定されない、メタデータを提供することによって、ゲートウェイ８４のＧＥＴ要求に応答し得る。ゲートウェイ８４は、次いで、ＣＳＲを生成し、ＳＰゲートウェイ制御７０に送る。ＣＳＲに応答して、ＳＰゲートウェイ制御７０は、証明書を生成し、ゲートウェイ８４の以前提供した公開鍵で、該証明書に署名する。少なくともいくつかの実施形態において、証明書は、顧客および／またはゲートウェイ情報、例えば、顧客アカウントＩＤおよび顧客供給のゲートウェイ８４の名前を含み得る。ＳＰゲートウェイ制御７０は、次いで、ゲートウェイ８４によって以前提供される公開鍵で暗号化される、自己署名証明書をゲートウェイ８４に送ることによって応答する。証明書は、次いで、ゲートウェイ８４からサービスプロバイダ６０への将来の通信での認証に使用され得る。

少なくともいくつかの実施形態において、同じ起動鍵を使用して、顧客が複数のゲートウェイ８４を起動することを防止するのを補助するために、ゲートウェイ８４によってＳＰゲートウェイ制御７０に公開される起動鍵とともに、システム／ハードウェア固有の情報も含まれ得る。

図１７Ａおよび１７Ｂは、少なくともいくつかの実施形態による、ストレージゲートウェイの観点からの起動プロセスのフローチャートである。図１７Ａの５００で示されるように、ゲートウェイが導入され、および／または電源が入れられた後に、ゲートウェイは、それが既に起動しているかどうかを判定するために、永続性ストレージを確認する。例えば、ゲートウェイは、アップグレード、維持管理、または他の何らかの理由のために、電源を切っている場合がある。ゲートウェイが起動していた場合、起動プロセスは、図１７Ｂの要素５３０へ進み、そこで、ゲートウェイは、ＳＰゲートウェイ制御から構成情報を取得し得る。

図１７Ａの５００で、ゲートウェイがまだ起動していない場合、起動プロセスは、図１７Ａの要素５０２に進み、そこで、ゲートウェイは、証明書署名要求（ＣＳＲ）を生成するための任意の永続的顧客情報を有するかどうかを確認する。ゲートウェイが永続的顧客情報を有する場合、プロセスは、図１７Ｂの要素５２０に進む。ゲートウェイが永続的顧客情報を有しない場合、プロセスは、図１７Ａの要素５０４に進む。５０４で、ゲートウェイは、公開鍵（例えば、ＲＳＡ鍵対）を生成する。ゲートウェイはまた、ゲートウェイが導入されたデバイスのハードウェアおよび／またはソフトウェアに関するメタデータも収集する。例えば、メタデータは、デバイスのＩＰアドレス、ＭＡＣアドレス、または他のハードウェアおよびソフトウェア特徴を含み得る。５０６で示されるように、ゲートウェイは、次いで、公開鍵およびメタデータをＳＰゲートウェイ制御に公開する。５０８で、ゲートウェイは、ＳＰゲートウェイ制御から起動鍵を受け取る。５１０で、ゲートウェイは、固定ポート（ＩＰアドレス：ポート）の起動鍵をサービス顧客のネットワーク上で広告する。

図１７Ａの５１２〜５１６で示されるように、ゲートウェイは、次いで、ＣＳＲを生成するために必要とされる顧客情報のためのＳＰゲートウェイ制御にポーリングし得る。顧客情報としては、顧客のアカウントＩＤおよびゲートウェイの顧客指定の名前が挙げられるが、それらに限定されない。５１２で、ゲートウェイは、例えば１分間または他の何らかの期間にわたって一時停止し得、次いで、ＳＰゲートウェイ制御から情報を受け取ったかどうかを確認し得る。５１４で、情報を受け取っていなかった場合、５１６で示されるように、ゲートウェイは、起動鍵が失効しているかどうかを確認する。少なくともいくつかの実施形態において、起動鍵は、一定の時間または寿命（例えば、３０分）にわたって有効であり、その後に、起動鍵は失効する。５１６で、起動鍵が失効していなかった場合、起動プロセスは、ＳＰゲートウェイ制御のポーリングを継続するために、図１７Ａの要素５１２に戻る。５１６で、起動鍵が失効していた場合、起動プロセスは、ＳＰ制御プレーンから新しい起動鍵を取得するために、図１７Ａの要素５０４に戻る。

図１７Ａの５１４で、ＳＰゲートウェイ制御から顧客情報を受け取っていた場合、起動プロセスは、図１７Ａの要素５１８に進み、そこで、ゲートウェイは、顧客情報を永続性メモリに記憶する。少なくともいくつかの実施形態において、受け取った顧客情報は、暗号化され得、したがって、ゲートウェイは、情報を記憶する前に、該情報を解読し得る。プロセスは、次いで、図１７Ｂの要素５２０に進む。

図１７Ｂを参照すると、５２０で、ゲートウェイは、既に証明書を有するかどうかを確認し得る。５２０で、ゲートウェイが証明書を既に有する場合、プロセスは、図１７Ｂの要素５３０に進み得、そこで、ゲートウェイは、ＳＰゲートウェイ制御から構成情報を取得し得る。５２０で、ゲートウェイが証明書を有しない場合、プロセスは、要素５２２に進む。５２２で、ゲートウェイは、ＣＳＲを生成し、該ＣＳＲをＳＰ制御プレーンに送る。５２４で、ゲートウェイは、ＣＳＲを受け取ることに応答して、ＳＰ制御プレーンからセキュリティ証明書を受け取り、該証明書は、ゲートウェイのためのセキュリティ証明書として機能し得る。５２６で、ゲートウェイは、起動鍵の広告を無効にし得る（図１７Ａのステップ５１０を参照されたい）。５２８で、ゲートウェイは、起動プロセスで取得した情報（証明書、顧客指定のゲートウェイ名等）を持続するために、その現在の状態を保存し得る。

この時点で、起動プロセスは完了する。５３０で、ゲートウェイは、ＳＰゲートウェイ制御から構成情報を取得し得る。少なくともいくつかの実施形態において、顧客が、ゲートウェイが成功裏に起動したことを通知されると、顧客は、ＳＰコンソールを介して導入され、起動されるゲートウェイを構成し得る。ＳＰコンソールは、顧客が、顧客のアカウントにログオンし、ゲートウェイ（顧客指定の名前によって識別され得る）を選択し、そしてゲートウェイの構成を指定することができる、ユーザインターフェース、例えばウェブインターフェースを提供し得る。少なくともいくつかの実施形態において、ＳＰコンソールは、この構成をＳＰゲートウェイ制御に渡し、次いで、ゲートウェイ自体によって開始される接続（例えば、およびＳＳＬ／ＴＣＰ接続）を介して、規定のゲートウェイを構成する。

起動鍵のセキュリティ
図１７Ａの５１０で示されるように、起動鍵は、サービス顧客のネットワーク上の公開ＩＰアドレスで利用できるようになり、クエリ文字列で暗号化されずに顧客からＳＰコンソールに渡され得る。起動鍵は、有限の寿命を有し、ＩＰアドレスは、顧客にだけ知られているが、それでも、起動鍵がＩＰ：ポートで公表される、短い時間窓がある。同じくゲートウェイによってＳＰゲートウェイ制御に公開されるメタデータがなければ、起動鍵自体が無効であるが、ゲートウェイは、この短い時間窓の間に、ある程度の影響を受け得る。少なくともいくつかの実施形態において、顧客は、悪意のあるユーザまたはプロセスが起動鍵を取得し、他の誰かのゲートウェイを起動するのを防止することを補助するために、セキュリティグループまたは他のセキュリティ手段を利用し得る。加えて、顧客は、ゲートウェイを起動させるために、ＳＰコンソールプロセスにログインすることが必要とされるので、ゲートウェイは、それを起動させることを試みる顧客アカウントと照合することができる。

ゲートウェイ主導の接続を使用するリモートゲートウェイ管理
ストレージゲートウェイの実施形態は、例えば、施設内ストレージデバイスとして、およびサービス顧客のネットワークとサービスプロバイダによって提供されるストレージサービスとの間のインターフェースとして機能し得る。少なくともいくつかの実施形態において、導入されたストレージゲートウェイは、サービスプロバイダで実現されるゲートウェイ制御技術を介してリモートに起動され、追跡され、構成され、そして管理され得る。図１８は、少なくともいくつかの実施形態で利用され得る例示的なゲートウェイ制御アーキテクチャを図示する、高次ブロック図である。少なくともいくつかの実施形態において、図１８で図示されるように、ゲートウェイ制御７０は、一群の２つ以上のゲートウェイ制御サーバ７４（例えば、ゲートウェイ制御サーバ７４Ａ、７４Ｂ、７４Ｃ、．．．）を含み得る。複数のゲートウェイ制御サーバ７４は、ロードバランシングおよび高可用性を提供し得る。操作中、所与の時間に、サービス顧客のネットワーク８０上の、特定の導入され、起動されたストレージゲートウェイ８４が、ゲートウェイ制御サーバ７４の特定の１つに接続される。しかしながら、ストレージゲートウェイ８４は、いずれ異なるゲートウェイ制御サーバ７４に接続され得ることに留意されたい。

ストレージゲートウェイ８４に現在接続されているゲートウェイ制御サーバ７４は、中間ネットワーク５０を介してストレージゲートウェイ８４に要求またはコマンドを送ることによって、ストレージゲートウェイ８４を管理し得る。ストレージゲートウェイ８４を管理するためにゲートウェイ制御サーバ７４から開始される要求としては、構成変更要求および操作要求が挙げられ得るが、それらに限定されない。しかしながら、ストレージゲートウェイ８４は、クライアントネットワーク８０ファイアウォールの背後に展開され得るので、ゲートウェイ制御サーバ７４は、ゲートウェイ８４の例外ルールが作成されない限り、ファイアウォールの外側からゲートウェイ８４に到達することが可能になり得ない。加えて、少なくともいくつかの実施形態において、ストレージゲートウェイ８４のセキュリティモデルは、サービスプロバイダのプロセスが挙げられるが、それに限定されない、外部プロセスが、ストレージゲートウェイ８４への接続を開始することを可能にしないように指示し得る。

少なくともいくつかの実施形態では、ゲートウェイ制御サーバ７４が、要求またはコマンドをストレージゲートウェイ８４に送ることを可能にする一方で、サービスプロバイダがゲートウェイ８４への接続を確立することを可能にしないセキュリティモデルを実施するために、ゲートウェイ主導の接続を使用するリモートゲートウェイ管理のための方法および装置が提供される。リモートゲートウェイ管理方法において、ゲートウェイは、接続要求を送ることによって、サービスプロバイダへの接続を開始する。少なくともいくつかの実施形態において、接続は、ロードバランサ７２を介して、特定のゲートウェイ制御サーバ７４に確立される。しかしながら、ゲートウェイ８４は、ゲートウェイ主導の接続を介して、サービスプロバイダに要求メッセージを送らない。代わりに、サービスプロバイダ（例えば、ゲートウェイ制御サーバ７４）が、ゲートウェイ８４に送られる接続保留要求を保持し、その一方で、ゲートウェイ８４は、応答を待機する。例えばネットワーク管理者プロセス９０またはゲートウェイ８４がインスタンス化されたクライアントネットワーク８０上の他の何らかのプロセスから、ゲートウェイ８４に対する要求を受け取ると、サービスプロバイダ（例えば、ゲートウェイ制御サーバ７４）は、サービスプロバイダ（例えば、ゲートウェイ制御サーバ７４）が保持していたゲートウェイ主導の接続を介して、要求をゲートウェイ８４に送る。ゲートウェイ８４はまた、ゲートウェイ主導の接続を介して、要求に対する応答をサービスプロバイダ８０に送り得る。

少なくともいくつかの実施形態において、ゲートウェイ８４からの接続が確立されるゲートウェイ制御サーバ７４（例えば、ゲートウェイ制御サーバ７４Ａ）は、接続を登録サービス７６に登録し得る。ゲートウェイ制御サーバ７４が、そこへの接続を保持しないゲートウェイ７４に対する要求を受け取る場合、ゲートウェイ制御サーバ７４は、どのゲートウェイ制御サーバ７４が接続を保持しているのかを見つけるために、登録サービス７６に問い合わせ得、該要求を、ゲートウェイ８４への接続を保持するゲートウェイコントロールサーバ７４に転送し得る。いくつかの実施形態において、代替例として、接続を保持しないゲートウェイ７４に対する要求を受け取る、ゲートウェイ制御サーバ７４は、要求を、単に２つ以上の他のゲートウェイ制御サーバ８４にブロードキャストし得る。

少なくともいくつかの実施形態において、サービスプロバイダ８０は、ゲートウェイ主導の接続を監視するために、ｐｉｎｇプロセスを利用し得る。ｐｉｎｇプロセスにおいて、ゲートウェイ７４への接続を維持するゲートウェイ制御サーバ８４は、ｐｉｎｇメッセージをゲートウェイ８４に定期的または非定期的に送り得る。ゲートウェイ８４は、ｐｉｎｇメッセージに応答する。ゲートウェイ８４が、ある規定のタイムアウト期間の間にｐｉｎｇメッセージ（複数可）に応答しなかったことを検出した時点で、ゲートウェイ制御サーバ７４は、接続を中断し得、登録サービス７６から接続を登録解除し得る。

少なくともいくつかの実施形態において、ｐｉｎｇメッセージは、定期的な間隔でゲートウェイ（複数可）７４に送られ得る。少なくともいくつかの実施形態は、ｐｉｎｇメッセージが、接続が不安定であるゲートウェイ８４にはより短い間隔で送られ、また、接続が概ね安定しているゲートウェイにはより長い間隔で送られるように、特定のゲートウェイ８４への接続の安定性に従って、ｐｉｎｇ間隔を調整し得る。ｐｉｎｇ間隔は、接続が安定したままであるときに所与のゲートウェイ８４に対して経時的に増加され得、また、接続が不安定である所与のゲートウェイ８４に対しては減少され得る。

少なくともいくつかの実施形態において、ゲートウェイ８４は、そのゲートウェイ主導の接続が終了または中断されたかどうかを検出し得る。接続が終了したことを検出すると、ゲートウェイ８４は、接続を再確立するために、別の接続要求をサービスプロバイダ８０に送り得る。接続は、以前接続を保持したものと異なるゲートウェイ制御サーバ７４に再確立され得ることに留意されたい。少なくともいくつかの実施形態において、ゲートウェイ８４は、ｐｉｎｇメッセージを監視することによってそのゲートウェイ主導の接続が中断されたと判定し得、また、規定のタイムアウト期間にわたる接続を通じてｐｉｎｇメッセージを受け取らなかったと判定し得る。

したがって、リモートゲートウェイ管理方法において、ゲートウェイ８４は、サービスプロバイダへの接続を確立し、そしてサービスプロバイダからの要求（複数可）を予測し、待機する。サービスプロバイダは、ゲートウェイ８４に対する接続保留要求を保持する。ゲートウェイ８４に対する要求を受け取ると、サービスプロバイダは、ゲートウェイ主導の接続を通じて、該要求をそれぞれのゲートウェイに転送する。サービスプロバイダおよびゲートウェイはどちらも、何らかの理由で接続が中断した場合に、該中断が検出され、ゲートウェイ８４が接続を再確立するように、接続を監視し、管理する。

図１９は、少なくともいくつかの実施形態による、ゲートウェイ主導の接続を使用するリモートゲートウェイ管理のための方法のフローチャートである。６００で示されるように、ゲートウェイは、接続要求を介して、ゲートウェイ制御サーバへの接続を確立する。例えば、ゲートウェイは、接続要求を介して、図１８で図示されるように、ロードバランサを通してゲートウェイ制御サーバとのアウトバウンドＳＳＬ／ＴＣＰ接続を確立し得る。図１９の６０２で示されるように、ゲートウェイへの接続が確立されると、ゲートウェイ制御サーバは、接続を保持し、接続を継続する。図１９の６０４で示されるように、ゲートウェイ制御サーバは、ゲートウェイに対する要求を受け取る。例えば、図１８で図示されるように、ゲートウェイ制御サーバ７４は、コンソールプロセス６８を介して、それぞれのネットワーク管理者プロセス９０から、ゲートウェイ８４に対する構成要求または操作要求を受け取り得る。ゲートウェイ制御サーバがゲートウェイに対する要求を受け取った後に、図１９の６０６で示されるように、ゲートウェイ制御サーバは、ゲートウェイ主導の接続を介して、要求をゲートウェイに転送する。

図１８を再度参照すると、サービス顧客は、示されたストレージゲートウェイ８４に対する構成変更要求または操作要求を開始するために、サービスプロバイダコンソール６０にアクセスし得る。例えば、ネットワーク管理者は、ネットワーク管理者プロセス９０を介して、要求を、コンソールプロセス６８を介して、ゲートウェイ８４に送り得る。コンソールプロセス６８は、次いで、要求を、ロードバランサ７２の背後のゲートウェイ制御サーバ７４に送り得る。しかしながら、コンソールプロセス６８が要求を送るゲートウェイ制御サーバ７２は、それぞれのゲートウェイ８４への接続を保持するゲートウェイ制御サーバ７２ではない場合がある。例えば、ゲートウェイ制御サーバ７２Ｂは、ゲートウェイ８４への接続を保持し得る一方で、ゲートウェイ８４に対する要求は、ゲートウェイ制御サーバ７２Ａに送られ得る。したがって、コンソールプロセス６８から要求を受け取るゲートウェイ制御サーバ７２（例えば、ゲートウェイ制御サーバ７２Ａ）は、要求を適切なゲートウェイ８４に送達するために、要求を、ゲートウェイ８４への接続を保持するゲートウェイ制御サーバ（例えば、ゲートウェイ制御サーバ７２Ｂ）に転送する必要があり得る。したがって、少なくともいくつかの実施形態は、ゲートウェイ制御サーバ７２（例えば、サーバ７２Ａ）が、要求によって示される特定のゲートウェイ８４への接続を現在保持するゲートウェイコントロールサーバ７２（例えば、サーバ７２Ｂ）へのコンソールプロセス６８から受け取られる、特定のゲートウェイ８４に対する要求を獲得するための、１つまたは複数の方法を提供し得る。

いくつかの実施形態では、これを達成するために、サーバ７２が接続を保持しないゲートウェイ８４に対する要求を受け取るゲートウェイ制御サーバ７２（例えば、サーバ７２Ａ）は、要求を、そのピアゲートウェイ制御サーバ７２の全てにブロードキャストし得る。図２０は、いくつかの実施形態による、ゲートウェイ制御サーバがゲートウェイ要求をそのピアサーバにブロードキャストするための方法のフローチャートである。６２０で示されるように、各ゲートウェイ制御サーバ７２がインスタンス化されると、サーバ７２は、登録サービス７６に登録し得る。ゲートウェイ制御サーバ７２を出るときに、サーバ７２は、登録サービス７６から登録解除される。登録サービス７６は、例えば、データベースサービスまたは分散ストレージサービスによってバックアップされ得る。６２２で示されるように、ゲートウェイ制御サーバ７２（例えば、サーバ７２Ａ）は、サーバ７２が接続を保持しないゲートウェイ８４に対する要求を受け取り得る。６２４で示されるように、要求をそのピアゲートウェイ制御サーバ７２にブロードキャストするために、ゲートウェイ制御サーバ７２（例えば、サーバ７２Ａ）は、そのピアゲートウェイ制御サーバ７２（例えば、サーバ７２Ｂおよび７２Ｃ）を発見するために、登録サービス７６をポーリングし得る。６２６で示されるように、ゲートウェイ制御サーバ７２（例えば、サーバ７２Ａ）は、次いで、ゲートウェイ要求を、登録サービス７６を介して発見されたサーバ７２の全てに転送し得る。要求によって示されるゲートウェイ８４への接続を現在保持する、ゲートウェイ制御サーバ７２（例えば、サーバ７２Ｂ）は、次いで、要求をそれぞれのゲートウェイ８４に送り得る。

図２１は、少なくともいくつかの実施形態による、適切なゲートウェイ制御サーバへのゲートウェイ要求を獲得するための代替の方法のフローチャートである。６４０で示されるように、ゲートウェイ制御サーバ７２（例えば、サーバ７２Ｂ）がゲートウェイ８４から接続要求を受け取ると、登録サーバ７６において、サーバ７２は、ペアリングをゲートウェイ８４に登録する。６４２で示されるように、ゲートウェイ制御サーバ７２（例えば、サーバ７２Ａ）は、サーバ７２が接続を保持しないゲートウェイ８４に対する要求を受け取り得る。６４４で示されるように、サーバ７２が接続を保持しないゲートウェイ８４に対する要求を受け取るゲートウェイ制御サーバ７２（例えば、サーバ７２Ａ）は、次いで、どのゲートウェイ制御サーバ７２（例えば、サーバ７２Ｂ）がゲートウェイ８４との接続を現在保持しているのかを見つけるように、登録サーバ７２に問い合わせ得、次いで、６４６で示されるように、要求を、登録サービス７６によって示されるゲートウェイ制御サーバ７２（例えば、サーバ７２Ｂ）に転送し得る。要求によって示されるゲートウェイ８４への接続を現在保持するゲートウェイ制御サーバ７２（例えば、サーバ７２Ｂ）は、次いで、要求を、ゲートウェイ主導の接続を介して、それぞれのゲートウェイ８４に送り得る。

少なくともいくつかの実施形態において、要求がゲートウェイ８４に送達され、それによって処理されると、ゲートウェイ８４から、ゲートウェイ８４への接続を現在保持するゲートウェイ制御サーバ７２（例えば、サーバ７２Ｂ）にステータスが返され、その後に、ステータスを、転送された要求をそこから以前に受け取ったゲートウェイ制御サーバ７２（例えば、サーバ７２Ａ）に返し、次いで、ステータスをコンソールプロセス６８に返す。コンソールプロセス６８は、次いで、要求の結果の指示を、要求を開始した顧客プロセス（例えば、ネットワーク管理者プロセス９０）に提供し得る。何らかの理由で、要求がターゲットゲートウェイ８４への到達に失敗した場合、例えば、要求によって示されるゲートウェイ８４が利用できない、または見つけることができない場合、コンソールプロセス６８は、要求失敗の指示を、要求を開始した顧客プロセス（例えば、ネットワーク管理者プロセス９０）に提供し得る。顧客プロセスは、必要または所望に応じて、要求を再度試み得る。

図２２は、少なくともいくつかの実施形態による、ゲートウェイ主導の接続を確立、監視、および維持するための方法のフローチャートである。６６０で示されるように、ゲートウェイは、クライアントネットワーク上にインスタンス化され得る。６６２で示されるように、インスタンス化の後に、ゲートウェイは、サービスプロバイダへの安全な接続（例えば、ＳＳＬ（セキュアソケットレイヤ）／ＴＣＰ接続）を確立するために、接続要求をサービスプロバイダに送る。少なくともいくつかの実施形態において、６６４で示されるように、サービスプロバイダのゲートウェイ制御プロセスは、接続を保持し得、該接続を登録サービスに登録し得る。サービスプロバイダによって受け取られるゲートウェイに対する要求は、次いで、ゲートウェイ主導の接続を通じてゲートウェイに転送され得る。

６６６で示されるように、ゲートウェイ制御プロセスは、接続を中断し得る。例えば、少なくともいくつかの実施形態において、ゲートウェイ制御プロセスは、接続を通じてゲートウェイに対して定期的または非定期的にｐｉｎｇを実行し得、ゲートウェイがｐｉｎｇに応答しないことを検出した時点で接続を中断し得る。登録サービスに登録する場合、ゲートウェイ制御プロセスは、接続を登録解除し得る。

６６８で示されるように、ゲートウェイは、接続が中断されたことを検出し得る。例えば、少なくともいくつかの実施形態において、ゲートウェイ制御プロセスは、接続を通じてゲートウェイに対して定期的または非定期的にｐｉｎｇを実行し得る。ゲートウェイは、接続を通じてサービスプロバイダからｐｉｎｇを受け取っていないと判定することによって、接続が中断されたことを検出し得る。

いくつかの実施形態では、サービスプロバイダ側またはクライアントネットワーク／ゲートウェイ側のいずれかから、中断された接続を検出するための他の方法が利用され得ることに留意されたい。

ゲートウェイプロキシ
図１８は、上で説明される、複数のゲートウェイ制御サーバ７４を含むゲートウェイ制御プレーンとして実現されるゲートウェイ制御７０を含む、サービスプロバイダネットワークを図示する。少なくともいくつかの実施形態において、サービスプロバイダネットワークは、複数のゲートウェイプロキシノードを含み、また、ストレージゲートウェイと通信するためにゲートウェイ制御プレーンによって使用され得る、ゲートウェイプロキシプレーンを含み得る。ゲートウェイプロキシは、ゲートウェイ制御サーバ７４のゲートウェイ主導の接続を保持し、管理するために使用され得る。ゲートウェイ８４は、ゲートウェイプロキシへの接続を開始する。ゲートウェイプロキシは、ゲートウェイ８４への通信チャネルを維持し得、サービスプロバイダ（例えば、ゲートウェイ制御サーバ７４）とゲートウェイとの間での安全なメッセージの交換を確実にするのを補助し得、ならびに、同じゲートウェイ８４の複数のコピー等の誤用を防止するのを補助し得る。

ゲートウェイ−プロキシ相互作用
図２３Ａは、少なくともいくつかの実施形態による、ゲートウェイプロキシプレーンを含むサービスプロバイダネットワークのためのアーキテクチャを大まかに図示する、ブロック図である。ゲートウェイプロキシプレーンは、２つ以上のプロキシノード７００と、１つのプロキシストア７０２と、外部ネットワークに公表されるクライアント側インターフェースプロセス（ＣＩＰ）７２０と、プロキシノード７００と外部ネットワークに公表されないゲートウェイ制御サーバ（複数可）７４との間のサーバ側インターフェースプロセス（ＳＩＰ）７１０とを含み得る。いくつかの実施形態において、ゲートウェイプロキシ７００は、ゲートウェイ制御サーバ（複数可）７４と同じ物理デバイス上に実現され得る。他の実施形態において、ゲートウェイプロキシ７００は、ゲートウェイ制御サーバ７４とは別のデバイス上に実現され得る。

導入され、起動されるストレージゲートウェイ８４は、ＣＩＰ７２０を介して、ゲートウェイプロキシノード７００への安全な接続要求（例えば、ＳＳＬ／ＴＣＰ接続要求）を開始する。接続要求を受け取るプロキシノード７００（この実施例において、プロキシノード７００Ｂ）は、ゲートウェイ識別子およびこの接続を開始したゲートウェイ８４の顧客アカウント識別子を見つけるために、接続要求と関連付けられるゲートウェイの証明書を検査する。顧客およびゲートウェイ８４は、証明書からのゲートウェイ識別子および顧客アカウント識別子を使用して認証され得る。顧客およびゲートウェイ８４を認証した後に、次いで、プロキシノード７００をプロキシノード７０２に公開するが、それは、接続されたゲートウェイ８４と通信するための、信頼できるプロキシ７００である。プロキシ（例えば、プロキシ７００Ａおよび７００Ｂ）は、特定のゲートウェイへの接続を現在保持する他のプロキシを発見するために、プロキシストア７０２に問い合わせ得る。

少なくともいくつかの実施形態において、プロキシストア７０２は、データベースとして実現され得る。データベースは、分散または集中データベースでもよい。少なくともいくつかの実施形態において、プロキシストア７０２は、以下の関連を記憶し得る。
（ゲートウェイＩＤ、アカウントＩＤ、プロキシエンドポイント）

メッセージをゲートウェイ８４に送るべきであるときに、プロキシ７００は、どのプロキシ７０２がゲートウェイ８４への接続を有するかを見つけるために、プロキシストア７０２に問い合わせ得る。少なくともいくつかの実施形態では、プロキシストア７０２において、１つのゲートウェイ８４につき１つのエントリだけが存在する。

ゲートウェイ制御サーバとプロキシとの相互作用
図２３Ｂは、少なくともいくつかの実施形態による、ゲートウェイプロキシプレーンを通してゲートウェイにメッセージを送る、ゲートウェイ制御サーバを図示する図である。図２３Ｂで示されるように、少なくともいくつかの実施形態において、ゲートウェイ制御サーバ７４は、特定のゲートウェイ８４に送る必要があるメッセージを有し得る。ゲートウェイ制御サーバ７４は、ＳＩＰ７１０を介して、メッセージをゲートウェイプロキシノード７００に送る。メッセージを受け取るプロキシノード７００がゲートウェイ８４への接続を保持する場合、プロキシノード７００は、該接続を介して、メッセージをゲートウェイ８４に転送する。しかしながら、メッセージを受け取るプロキシノード７００がゲートウェイ８４への接続を保持しない場合、プロキシノード７００は、どのプロキシノード７００がゲートウェイ８４への接続を保持するかを判定するために、プロキシストア７０２に問い合わせ、そしてメッセージを信頼できるプロキシノード７００（この実施例において、プロキシ７００Ｂ）に転送する。信頼できるプロキシノード７００は、次いで、接続を介して、メッセージをゲートウェイ８４に転送する。

図２３Ｃは、少なくともいくつかの実施形態による、ゲートウェイプロキシプレーンを通してゲートウェイ制御サーバ要求に応答するゲートウェイを図示する図である。少なくともいくつかの実施形態において、ゲートウェイ８４からゲートウェイ制御サーバ７４への応答は、図２３Ｂで示されるように要求がゲートウェイ制御サーバ７４からゲートウェイ８４にたどる経路とは逆の経路をたどり得、ＣＩＰ７２０がゲートウェイ８４から応答を受け取ることから始まる。ＣＩＰ７２０は、応答を、そこから要求を受け取ったプロキシノード（プロキシ７００Ｂ）に送る。プロキシ７００Ｂは、この応答がどのゲートウェイ制御サーバ７４に対するものであるのか知らないことに留意されたい。プロキシ７００Ｂは、そこから要求を受け取ったプロキシノード（プロキシ７００Ａ）に応答を送ることによって要求を完了する。プロキシ７００Ａは、次いで、応答を、要求を開始したゲートウェイ制御サーバ７４に送る。

接続の監視および管理
少なくともいくつかの実施形態では、ゲートウェイ主導の接続を管理する際にプロキシによって使用される、ｐｉｎｇプロセスが実現され得る。少なくともいくつかの実施形態において、上で説明されるように、ゲートウェイ８４は、ＣＩＰ７２０を介したゲートウェイプロキシ７００への安全な接続、例えばＳＳＬ／ＴＣＰ接続を開始する。ゲートウェイプロキシ７００は、ｐｉｎｇメッセージをゲートウェイ８４に定期的または非定期的に送り得る。各ｐｉｎｇメッセージは、タイムアウトを含み得、ゲートウェイ８４が時間間隔内にｐｉｎｇを受け取らない場合は、ＣＩＰ７２０を介した現在の接続を閉じ、接続を再開する。少なくともいくつかの実施形態において、任意の時点で、プロキシストア７０２には１つのプロキシ−ゲートウェイマッピングだけがある。ゲートウェイプロキシ７００がｐｉｎｇを送り、ゲートウェイ８４からの応答を獲得しない場合は、ゲートウェイ８４への接続を閉じる。

少なくともいくつかの実施形態において、ｐｉｎｇ毎に、ゲートウェイプロキシ７００は、別のプロキシ７００がゲートウェイ８４への接続を確立したかどうかを判定するために、プロキシストア７０２に問い合わせることによって、それが所与のゲートウェイ８４に対する信頼できるプロキシであるかどうかを確認する。それが信頼できるプロキシでない場合、プロキシ７００は、ゲートウェイ８４への接続を閉じる。これは、プロキシノード７００への複数の接続が同じゲートウェイ８４によって開始された場合、例えば、ゲートウェイ８４の証明書が別のゲートウェイにコピーされ、双方のゲートウェイが接続を開始しようとした場合に対処し得る。

図２３Ｄは、少なくともいくつかの実施形態による、ゲートウェイプロキシプレーンのためのｐｉｎｇメッセージ交換を図示する図である。少なくともいくつかの実施形態において、ゲートウェイプロキシに関するｐｉｎｇは、エンドツーエンドのｐｉｎｇである。ｐｉｎｇの理由は、ＴＣＰの「キープアライブ」機能が、２時間という最短の時間間隔を有する一方で、実施形態は、より短い間隔で接続のタイムアウトまたは終了を検出することが必要であり得るからである。

少なくともいくつかの実施形態において、ｐｉｎｇは、図２３Ｄで示されるような経路をたどる。ゲートウェイプロキシノード（この実施例において、プロキシ７００Ｂ）は、ＳＩＰ７１０を介して、ｐｉｎｇメッセージを送る。メッセージは、ゲートウェイプロキシノード７００の１つ、この実施例ではプロキシ７００Ａにヒットする。プロキシ７００Ａは、プロキシストア７０２に問い合わせることによって、ゲートウェイ８４に対する信頼できるプロキシ７００（この実施例において、プロキシ７００Ｂ）を見つけ、ｐｉｎｇメッセージをプロキシ７００Ｂに転送する。プロキシ７００Ｂは、ゲートウェイ８４にメッセージを転送し、ゲートウェイ８４からの返信は、同じ経路をたどる。少なくともいくつかの実施形態において、プロキシ７００Ｂは、ゲートウェイ８４からｐｉｎｇに対する返信を獲得すると、ゲートウェイ８４に対するｐｉｎｇ間隔を増加させる。ゲートウェイ８４への接続が遮断された場合、ｐｉｎｇ間隔は、最小値にリセットされ得る。したがって、不十分なゲートウェイ−プロキシ接続は、より頻繁にｐｉｎｇを実行される傾向がある。

プロキシ７００が最初にｐｉｎｇメッセージをＳＩＰ７１０に送ることによってｐｉｎｇメッセージを開始する、上で説明されるエンドツーエンドのｐｉｎｇ方法は、ゲートウェイプロキシノード７００が制御プレーンから到達できることを確実にするのを補助し得る。ｐｉｎｇに失敗した場合、プロキシ７００は、それが、（例えば、ネットワークパーティションのため）制御プレーンから到達できないと想定し得、ゲートウェイ８４への接続を閉じ得る。

ロングポーリング接続を使用するリモートゲートウェイ管理
いくつかの実施形態では、ゲートウェイ主導の接続のために、ロングポーリング手法が使用され得る。図１８を再度参照すると、ロングポーリングは、サーバ（例えば、ゲートウェイ制御サーバ７４）からクライアント（例えば、ストレージゲートウェイ８４）への情報のプッシュを模倣する、ポーリング手法である。ロングポーリング手法において、クライアント（例えば、ストレージゲートウェイ８４）は、サーバ（例えば、ゲートウェイ制御サーバ７４）へのロングポーリング接続を開始し、標準的なクライアント／サーバポーリングのように、サーバから情報を要求する。しかしながら、サーバが、クライアントで利用可能ないかなる情報も有しない場合、サーバは、空の応答を送る代わりに、クライアントの要求を保持し、クライアントの情報が利用可能になるのを待つ。情報が利用可能になると、サーバ（例えば、ゲートウェイ制御サーバ７４）は、クライアントのロングポーリング要求に応答し得、該応答は、クライアント（例えば、ストレージゲートウェイ８４）に送られる情報を含む。

ロングポーリングを使用するゲートウェイ主導の接続方法において、ゲートウェイ８４は、ロングポーリング要求を介して、ゲートウェイ制御サーバ７４への接続を確立する。例えば、ゲートウェイ８４は、ロングポーリング要求を介して、図１８で図示されるように、ロードバランサ７２を通して、ゲートウェイ制御サーバ７４とのアウトバウンドＳＳＬ／ＴＣＰ接続を確立し得る。ゲートウェイ制御サーバ７４は、要求を保持し、接続を継続する。ゲートウェイ制御サーバ７４は、ゲートウェイ８４に対する要求を受け取る。例えば、図１８で図示されるように、ゲートウェイ制御サーバ７４は、コンソールプロセス６８を介して、それぞれのネットワーク管理者プロセス９０から、ゲートウェイ８４に対する構成要求または操作要求を受け取り得る。ゲートウェイ制御サーバ７４がゲートウェイ８４に対する要求を受け取った後に、ゲートウェイ制御サーバ７４は、ゲートウェイのロングポーリング要求に対する応答を送る。この応答は、ゲートウェイ８４に対する要求（例えば、構成要求または操作要求）を含む。いくつかの実施形態において、代替例として、ゲートウェイ制御サーバ７４は、ゲートウェイ制御サーバがロングポーリング要求に応答せずに維持している、ゲートウェイへの確立された接続上で、受け取った要求をゲートウェイ８４に送り得る。

ストレージゲートウェイに関するブロックストレージのＩ／Ｏ操作
ストレージゲートウェイの実施形態は、上で説明されるように、キャッシュされたゲートウェイまたはシャドウ化ゲートウェイとして実現され得る。例示的な実施形態において、キャッシュされたゲートウェイは、最も頻繁にアクセスされるデータのための、施設内（ローカル）ストレージ、および本質的に無限の総容量のための、ストレージサービスによって提供されるリモートストレージを活用する、施設内ブロックに基づく機器と考えられ得る。図６は、キャッシュされたゲートウェイの実施形態が実現される例示的なネットワーク環境のアーキテクチャおよびその中のデータフローを大まかに図示する、高次ブロック図である。キャッシュされたゲートウェイは、サービス顧客のローカルネットワークとサービスプロバイダのネットワークのストレージサービスとの間のインターフェースとして機能し得る。少なくともいくつかの実施形態において、キャッシュされたゲートウェイは、ｉＳＣＳＩインターフェースを顧客ネットワーク上のプロセスに公表し得るが、いくつかの実施形態では、他のデータインターフェースが公表され得る。このように、キャッシュされたゲートウェイは、クライアントネットワーク内で動作するデータインターフェースターゲット（例えば、ｉＳＣＳＩターゲット）として現れ得、例えば、キャッシュされたゲートウェイは、クライアントネットワーク上にストレージアレイとして現れ得る。キャッシュされたゲートウェイは、例えば、論理ユニット番号（ＬＵＮ）、例えばハードディスク等のブロックに基づくストレージデバイスを、クライアントネットワーク内のデバイス上で実行するプロセスに公表し得る。プロセスは、その結果、ＬＵＮとのデータセッション（例えば、ＳＣＳＩセッション）を開始し得、データコマンド（例えば、ＳＣＳＩコマンド）をキャッシュされたゲートウェイに送り得る。

図２４は、少なくともいくつかの実施形態による、キャッシュされたゲートウェイのための一般的アーキテクチャおよびそのデータＩ／Ｏ操作を図示する。一般に、キャッシュされたゲートウェイ８００において、顧客プロセス８３０から書き込みデータを受け取ると、データが書き込みログ８１４に添付され、データは、後で、アップロードプロセスによって、書き込みログ８１４からリモートデータストア８２０にアップロードされる。ブロックに関連する書き込みデータのメタデータ、例えばブロックの場所、ブロックのタイプ、オフセット（複数可）、および長さが、メタデータストア８０６に加えられ得る。少なくともいくつかの実施形態において、メタデータストア８０６は、データベース、例えばバークレーデータベース（ＢＤＢ）として実現され得る。キャッシュされたゲートウェイ８００はまた、少なくともいくつかのデータ、例えば頻繁におよび／または最近使用されたデータをローカルキャッシュ８１２にローカルにキャッシュするが、これは、いくつかの読み出しが、リモートデータストア８２０からではなく、ローカルキャッシュ８１２から履行され得るので、顧客の読み出し要求に対する応答を改善し得る。ローカルキャッシュ８１２は、読み出しキャッシュと称され得る。メタデータストア８０６はまた、ローカルキャッシュ８１２の中のローカルにキャッシュされた読み出しデータの場所および他の情報を含み得る。図２４は、１つのメタデータストア８０６が読み出しキャッシュエントリおよび書き込みキャッシュエントリの双方を含む実施形態を示すが、いくつかの実施形態において、読み出しキャッシュエントリおよび書き込みキャッシュエントリは、別々のメタデータストア８０６で維持され得る。少なくともいくつかの実施形態において、顧客プロセス８３０からのデータ読み出し要求は、可能であれば、書き込みログ８１４またはローカルキャッシュ８１２から提供され得、可能でない場合、要求されたデータは、リモートデータストア８３０からフェッチされ得る。読み出し要求を履行するためにフェッチされ、（例えば、ブロックバッファ８０４に）バッファリングされる、ローカルキャッシュ８１２またはリモートデータストア８３０からのデータは、データに対する書き込みログ８１４の中に更新が存在する場合、読み出し要求を履行するためにデータが顧客プロセス８３０に返される前に、書き込みログ８１４からのデータで更新され得る。

少なくともいくつかの実施形態において、書き込みログ８１４およびデータキャッシュ８１２は、共通の、ローカルブロックに基づくデータストア８１０で実現され得る。ブロックデータストア８１０は、揮発性メモリ、不揮発性メモリ、またはそれらの組み合わせで実現され得る。ブロックデータストア８１０は、キャッシュされたゲートウェイ８００がその上に実現される物理デバイス内の物理メモリ上、キャッシュされたゲートウェイ８００がその上に実現される物理デバイスの外部のメモリ上（例えば、顧客によってゲートウェイ８００に割り当てられる１つ以上のストレージデバイス上）、またはそれらの組み合わせ上で実現され得る。

書き込みログデータおよびキャッシュされた読み出しデータはどちらも、例えば４ＭＢ（４メガバイト）のブロックとして、ブロックストレージ形式でブロックデータストア８１０に記憶され得る。ブロックデータストア８１０の中のキャッシュされた読み出しブロックは、読み出しキャッシュとみなされ得、ブロックデータストアの中の書き込みログブロックは、書き込みバッファとみなされ得る。メタデータストア８０６は、ブロックデータストア８１０の中の読み出しキャッシュ８１２ブロックおよび書き込みログ８１４ブロックの双方の場所を特定するためのエントリを含み得る。ブロックは、読み出し要求を履行するために、読み出しキャッシュ８１２から（または書き込みログ８１４から）読み出され得、ブロックは、アップロードプロセスを介して、書き込みログ８１４からリモートデータストア８２０にアップロードされ得る。少なくともいくつかの実施形態において、書き込みログ８１４から書き込みブロックをアップロードすると、アップロードされたデータは、新しい読み出しブロックとして、読み出しキャッシュ８１２に加えられ得る。アップロードされた書き込みログ８１４ブロックは、ブロックデータストア８１０の中で「空き」としてマークされ得、メタデータストア８０６は、変更をブロックデータストア８１０に反映するために適切に更新され得る。

少なくともいくつかの実施形態において、書き込み要求は、ブロックの比較的小さい部分だけを修正または変化させ得る。したがって、少なくともいくつかの実施形態では、書き込みログ８１４から１ブロックをアップロードするときには、例えば上で述べられるデータ重複排除手法を使用して、変化した部分だけがリモートデータストア８２０にアップロードされ得る。加えて、書き込みログ８１４は、異なる書き込みログ８１４ブロックに記憶される、２つ以上の重複書き込み（すなわち、同じ論理ブロックへの書き込み）を含み得る。書き込みログ８１４から書き込みデータをアップロードするときに、２つ以上の重複書き込みは、アップロードするために組み合わせられ得る。この組み合わせは、データストアの外側、例えばブロックバッファ８０４のブロックで行われ得、書き込みログ８１４自体のブロックは、変化しない。

上で述べられるように、少なくともいくつかの実施形態において、書き込みログ８１４から書き込みブロックをアップロードするときに、アップロードされたデータは、新しい読み出しブロックとして読み出しキャッシュ８１２に加えられ得る。少なくともいくつかの事例について、例えば書き込みブロックが多数の変化を含むとき、および／または書き込みブロックの大部分が変化したときに、書き込みブロックは、新しい読み出しブロックとして単に読み出しキャッシュ８１２にコピーされ、そしてメタデータストア８０６が更新される。しかしながら、上で述べられるように、書き込み要求は、書き込みログ８１４ブロックの比較的小さい部分だけを修正または変化させ得る。したがって、少なくとも一部の場合において、読み出しキャッシュ８１２の中のブロック全体が最新であることを確実にするために、最初に、それぞれのブロックがリモートデータストア８２０からフェッチされ得、そして、該ブロックを読み出しキャッシュ８１２に加える前に、フェッチされたブロックが、書き込みログ８１４からの変化（複数可）で更新され得る。上で述ベられるように、書き込みログ８１４は、異なる書き込みログ８１４ブロックに記憶される、２つ以上の重複書き込み（すなわち、同じ論理ブロックへの書き込み）を含み得、したがって、フェッチされたブロックは、１つ以上の書き込みログ８１４ブロックに従って更新され得る。少なくともいくつかの実施形態において、フェッチされたブロックは、読み出しキャッシュ８１２に加えられる前に、書き込みログ８０４ブロックから更新するためのブロックバッファ８０４に記憶され得る。

一般に、新しい書き込みは、ブロックデータストア８１０の中の以前に空きになった書き込みログ８１４ブロックに記憶される。しかしながら、ブロックデータストア８１０が満杯またはほぼ満杯であると検出された場合は、書き込みデータのための場所を作るために、１つ以上のキャッシュされた読み出しブロックがパージされ得る。読み出しブロックは、他の理由で、例えば新しい読み出しデータのための空間をあけるために、ブロックデータストア８１０からパージされ得ることに留意されたい。種々の実施形態では、ブロックデータストア８１０から読み出しブロックをパージするために、異なる手法またはポリシーが使用され得る。例えば、いくつかの実施形態では、ブロックデータストア８１０から最も停滞している読み出しブロックをパージするために、最長未使用時間（ＬＲＵ）ポリシーが適用され得る。

少なくともいくつかの実施形態において、キャッシュされたゲートウェイ８００は、インターフェースを、リモートデータストア８２０上の２つ以上のボリューム８２２に提供し得る。少なくともいくつかの実施形態において、別々の書き込みログ８１４および読み出しキャッシュ８１２は、各ボリューム８２２のためのキャッシュされたゲートウェイ８００によって維持され得る。少なくともいくつかの実施形態において、２つ以上のボリューム８２２のための別々の書き込みログ８１４および読み出しキャッシュ８１２は、同じブロックデータストア８１０に実現され得る。しかしながら、少なくともいくつかの実施形態において、異なるボリューム８２２のための書き込みログ８１４および読み出しキャッシュ８１２は、ブロックデータストア８１０上で論理的または物理的に分離され得る。加えて、少なくともいくつかの実施形態では、別々のメタデータストア８０６が、別々のボリューム８２２のために維持され得る。

図２４は、ブロックデータストア８１０において、読み出しキャッシュ８１２および書き込みログ８１４を論理的に別々に示すが、少なくともいくつかの実施形態において、所与のボリューム８２２のための読み出しブロックおよび書き込みログブロックは、ブロックデータストア８１０において物理的に混在し得る。例えば、第１の物理ブロックが読み出しブロックであり得、第２〜第５の物理ブロックが書き込みブロックであり得、次の２つの物理ブロックが読み出しブロックあり得る、等である。

上で述ベられるように、図２４は、少なくともいくつかの実施形態による、キャッシュされたゲートウェイのための一般的アーキテクチャおよびそのデータＩ／Ｏ操作を図示する。しかしながら、ストレージゲートウェイはまた、例えば図７で図示されるように、シャドウ化ゲートウェイとしても構成され得る。図２５は、少なくともいくつかの実施形態による、シャドウ化ゲートウェイのための一般的アーキテクチャおよびそのデータＩ／Ｏ操作を図示する図である。シャドウ化ゲートウェイ８０１は、図２４でキャッシュされたゲートウェイ８００について図示および説明されるものと類似するアーキテクチャ、構成要素、およびデータＩ／Ｏ操作を含み得るが、シャドウ化ゲートウェイ８０１が読み出しキャッシュ８１２または読み出しキャッシュ８１２のためのメタデータストア８０６の中のエントリを含まないこと、およびキャッシュされたゲートウェイのための上で説明される読み出し関連の操作が行われないことを除く。シャドウ化ゲートウェイのための書き込み操作は、キャッシュされたゲートウェイのためのものと類似し得るが、書き込みが読み出しキャッシュに加えられないことを除く。加えて、顧客プロセス（複数可）８３０からの読み出しおよび書き込み要求は、ローカルデータストア８４０に転送される。しかしながら、書き込み要求からの書き込みデータは、リモートデータストア８２０にシャドウ化される。少なくともいくつかの実施形態において、書き込みデータは、ブロックデータストア８１０の中の書き込みログ８１４に添付され、書き込みログ８１４の中の書き込みデータは、リモートデータストア８２０に定期的または非定期的にアップロードされ、該リモートデータストアは、ローカルデータストア８４０上で主データストアのスナップショット８２４を維持する。

少なくともいくつかの実施形態において、例えば図２４で図示されるキャッシュされたゲートウェイのための、および例えば図２５で示されるシャドウ化ゲートウェイのための、書き込みログ８１４および書き込み操作は、書き込み性能のために最適化され得る。少なくともいくつかの実施形態において、ゲートウェイ８００の少なくともいくつかのＩ／Ｏ操作は、逐次データストアとしてブロックデータストア８１０を使用し得る。具体的には、書き込みログ８１４は、逐次データ構造として扱われ得、書き込みログ８１４に対する書き込み操作は、逐次書き込み操作として実現され得る。少なくともいくつかの実施形態において、書き込みログ８１４は、線形または循環キューとして実現される、一次元のデータバッファとして扱われ得る。キャッシュされたゲートウェイについて、リモートデータストア８２０からダウンロードされるデータは、書き込みログ８１４に記憶される顧客プロセス（複数可）８３０からゲートウェイ８００に送られる書き込みデータとは別に、読み出しキャッシュ８１２に記憶され得る。キャッシュされたゲートウェイおよびシャドウ化ゲートウェイの双方について、書き込み要求は、任意の順序で顧客プロセス（複数可）８３０から受け取られ得（すなわち、書き込み要求は、順不同または非逐次であり得）、顧客プロセス（複数可）８３０から受け取られる順不同の書き込み要求によって示される書き込みデータは、任意のサイズであり得、また、ターゲットデータストアの中の任意の場所またはオフセットに向けられ得る。しかしながら、順不同の書き込み要求で顧客プロセス（複数可）８３０から受け取られる任意の書き込みデータは、書き込みログ８１４に逐次的に書き込まれ、添付される。少なくともいくつかの実施形態において、添付することは、サブブロックレベルで行われ得、すなわち、書き込みデータの２つ以上のインスタンスが、書き込みログ８１４の中の同じブロック内に添付され得る。書き込みログ８１４に対する更新のメタデータ、例えば、書き込みログ８１４ブロックの中の書き込みデータのオフセットおよび長さ、ならびに、ターゲットデータストアの中のオフセットは、メタデータストア８０６に記憶される。

図２６は、少なくともいくつかの実施形態による、ブロックデータストア上の書き込みログに書き込むための方法のフローチャートである。逐次データ構造として、例えば一次元のキューとして書き込みログ８１４を実現することは、Ｉ／Ｏハンドラ８０２が、顧客プロセス（複数可）８３０から受け取られる任意の書き込みデータの、ブロックデータストア８１０への逐次書き込みを行うことを可能にし得る。８５０で示されるように、１つ以上の書き込み要求は、顧客プロセス８３０から受け取られ得る。書き込み要求は、任意の順序で受け取られ得（すなわち、書き込み要求は、順不同であり得）、顧客プロセス（複数可）８３０から受け取られる書き込み要求によって示される書き込みデータは、任意のサイズであり得、また、ターゲットデータストアの中の任意の場所またはオフセットに向けられ得る。８５２で示されるように、逐次書き込みは、任意の書き込みデータをブロックデータストア８１０上の書き込みログ８１４に逐次的に書き込むために行われ得る。８５４で示されるように、ブロックデータストア８１０への逐次書き込みのデータは、ブロックデータストア８１０の中の隣接する場所、例えばブロックデータストア８１０を実現するディスクストレージデバイス上の隣接する場所（例えば、セクタ）に書き込まれ得る。隣接する場所は、同じ書き込みログブロック内であり得るが、必ずしもそうではないことに留意されたい。ストレージデバイスに対して逐次書き込みを使用することで、下層のストレージデバイス上のランダムなセクタシークを行う必要性を低減させ、または除去し得る。ランダムなセクタシークを行うことは、Ｉ／Ｏ操作に負の影響を与える。例えば、ディスクＩ／Ｏスループットは、連続書き込みを使用することによって、ランダムなセクタシークを必要とする非逐次で不連続の書き込みと比較して、１０倍〜１００倍増加し得る。８５６で示されるように、メタデータストア８０６は、書き込みを書き込みログ８１４に反映するために、適切に更新され得る。少なくともいくつかの実施形態において、書き込みのメタデータは、メタデータストア８０６に逐次的に加えられ得るが、これは、書き込みログ８１４の中のデータにアクセスする必要があるプロセスによるメタデータストア８０６の読み出しを、メタデータがメタデータストア８０６にランダムに加えられた場合よりも効率的にすることを可能にし得る。

少なくともいくつかの実施形態では、必ずしも全ての書き込みログ８１４データを、ブロックデータストア８１０の隣接する場所に書き込むことが可能であるとは限らない。例えば、読み出しキャッシュ８１２ブロックが、２つの書き込みログ８１４ブロックの間にあり得る。したがって、８５４で、実施形態は、できる限り書き込みログ８１４データを隣接する場所に書き込むことを試み得るが、その場所が使用中であるとマークされている場合は、いくつかの場所（例えば、ブロック）をスキップしなければならない場合がある。メタデータストア８０６は、データが隣接するブロックに記憶されない場合であっても、書き込みログ８１４データの場所を特定することができるように、適切に更新される。

上で説明されるように、論理的に、任意の書き込みデータは、書き込みログの最後に添付される。これを実現するために、少なくともいくつかの実施形態では、ブロックバッファ８０４が、書き込みログ８１４で使用されるのと同じサイズのブロック（例えば、４ＭＢのブロック）で確保される。割り当てられるバッファブロックは、満杯になるまで添付される。新しい書き込みデータを添付するために、別のバッファブロックが割り当てられ得、満杯のバッファブロックは、ブロックデータストア上の書き込みログ８１４に、非同期的かつ逐次的にフラッシュされ得る。書き込みログ８１４の中の満杯のブロックは、アップロードインターフェースによってリモートデータストア８２０に、非同期的かつ逐次的にアップロードされ得、書き込みログ８１４からアップロードされるブロックは、「空き」としてマークされ得る。

図２４で図示されるキャッシュされたゲートウェイの実現例において、データ整合性を維持するために、ゲートウェイ８００が要求されたデータを顧客プロセス８３０に返す前に、読み出しデータを書き込みデータとマージすることが必要になり得る。図２７は、キャッシュされたゲートウェイの少なくともいくつかの実施形態による、読み出し要求を履行するための方法のフローチャートである。８６０で示されるように、読み出し要求は、顧客プロセス８３０から受け取られる。少なくともいくつかの実施形態において、顧客プロセス８３０から読み出し要求が受け取られると、ゲートウェイ８００は、書き込みログ８１４の中に読み出し範囲と重なるデータがあるかどうかを判定するために、メタデータストア８０６の中の読み出しのデータ範囲をルックアップする。図２７の８６２で、書き込みログ８１４の中に読み出し範囲を完全にカバーする重複データが見つかった場合、８６４で示されるように、読み出し要求を直接履行するために、書き込みログ８１４からのデータが使用され得る。そうでない場合、図２７の８６６で、書き込みログ８１４の中に読み出し範囲を部分的にカバーする重複データが見つかった場合、８６８で示されるように、データ範囲に対応するデータが存在するかどうかについて、読み出しキャッシュ８１２が確認され得る。データが読み出しキャッシュ８１２の中にある場合、８７０で示されるように、１つ以上のデータブロックが読み出しキャッシュ８１２からフェッチされ得る。そうでない場合、８７２で示されるように、１つ以上のブロックがリモートデータストア８２０からフェッチされ得る。いくつかの実施形態において、ブロックは、いくつかの読み出し要求を履行するために、読み出しキャッシュおよびリモートデータストア８２０の双方からフェッチされ得ることに留意されたい。図２７の８７４で、フェッチデータブロックは、次いで、書き込みログ８１４からの変化したデータで更新され得る。図２７の８７６で、変化したデータは、読み出し要求を履行するために、要求プロセス８３０に返され得る。いくつかの実施形態において、図２７の８７８で示されるように、更新されたブロックは、読み出しキャッシュ８１２に加えられ得る。

いくつかの実施形態において、読み出し要求を履行するためにリモートデータストア８２０から読み出されるブロックは、読み出しキャッシュ８１２に加えられ得、該ブロックを要求プロセス８３０に送る前に、書き込みログ８１４から更新され得る。あるいは、ブロックは、例えばブロックバッファ８０４にバッファリングされ得、そしてバッファにおいて更新され得る。更新されたブロックは、次いで、バッファ８０４から要求プロセス８３０に送られ得、そしてバッファ８０４から読み出しキャッシュ８１４に加えられ得る。

いくつかの実施形態において、読み出し要求を履行するために使用される読み出しキャッシュ８１２の中のブロックは、書き込みログ８１４からのデータで適所において更新され得、次いで、読み出し要求を履行するために、読み出しキャッシュ８１２から要求プロセス８３０に送られ得る。あるいは、ブロックは、読み出しキャッシュ８１２から読み出され得、例えばブロックバッファ８０４にバッファリングされ、そしてバッファにおいて更新され得る。更新されたブロックは、次いで、バッファ８０４から要求プロセス８３０に送られ得、そしてバッファ８０４から読み出しキャッシュ８１４に加えられ得る。バッファに読み出された読み出しキャッシュ８１２の中の以前のバージョンのブロックは、空きとしてマークされ得、および／または新たに更新されたブロックによって上書きされ得る。

図２７の８６６で、書き込みログ８１４の中にいかなる重複データも見つからなかった場合、図２７の８８０で示されるように、読み出しキャッシュ８１２は、読み出しキャッシュ８１２から読み出し要求を履行することができるかどうかを確認が確認され得る。図２７の８８０で、読み出しキャッシュ８１２から読み出し要求を履行することができる場合、図２７の８８２で示されるように、読み出しキャッシュ８１２からのデータは、読み出し要求を履行するために、顧客プロセス８３０に返され得る。図２７の８８０で、読み出しキャッシュ８１２から読み出し要求を履行することができない場合、図２７の８８４で示されるように、１つ以上のデータブロックがリモートデータストア８２０からフェッチされ得る。図２７の８８６で示されるように、フェッチされたブロックからのデータは、読み出し要求を履行するために、顧客プロセス８３０に返され得る。いくつかの実施形態において、図２７の８８８で示されるように、読み出し要求を履行するためにリモートデータストア８２０からフェッチされるブロックは、読み出しキャッシュ８１２に加えられ得る。

少なくともいくつかの実施形態において、ゲートウェイ８００は、例えばサービスプロバイダによって提供されるコンソールプロセスを通して、顧客が、書き込みログ８１４のスナップショットを取り、リモートデータストア８２０にアップロードするように要求することを可能にし得る。加えてまたはその代わりに、ゲートウェイ８００は、定期的または非定期的に書き込みログ８１４のスナップショットを自動的に取り、リモートデータストア８２０にアップロードし得る。書き込みログ８１４のスナップショットをアップロードすることは、例えば、ハードウェアおよびソフトウェアの故障からのデータの保護を提供し得る。少なくともいくつかの実施形態において、スナップショットは、ポイントインタイムのスナップショットであり、スナップショットが要求された時点で書き込みログの中にある変化したデータだけが、スナップショットでアップロードされる。少なくともいくつかの実施形態において、キャッシュされたゲートウェイの実現例について、変化したデータがアップロードされるときに、ローカルに記憶された読み出しキャッシュ８１２はまた、将来の読み出しのためにリモートデータストア８２０からデータをダウンロードする必要がないように、アップロードされるデータの少なくともいくつかで更新され得る。変化したデータがリモートデータストア８２０にアップロードされた後に、書き込みログ８１４の中のデータおよびメタデータストア８０６の中の対応するデータは、破棄する（例えば、「空き」としてマークする）ことができ、その空間を再使用することができる。

リモートデータストアへのアップロードのための書き込みデータの合体
上で説明されるように、書き込みログブロックは、リモートデータストアに、定期的または非定期的にアップロードされ得る。少なくともいくつかの実施形態では、書き込みログブロックをアップロードする際に、データ重複排除手法が使用され得る。しかしながら、説明されるデータ重複排除手法は、アップロードされる段階にあるブロック（複数可）の中どのようなデータに対しても、アップロードプロセス中に機能する。顧客プロセス（複数可）からの任意の書き込みは、書き込みログに逐次的に添付され、顧客プロセス（複数可）は、ターゲットデータストアの中の同じ場所に２回以上書き込み得るので、１つまたは複数の書き込みログブロックは、ターゲットデータストアの中の同じ場所（例えば、オフセットおよび／または範囲）に向けられる２つ以上の書き込みを含み得る。

したがって、少なくともいくつかの実施形態は、書き込みログブロックの中の書き込みデータに対するアップロード前合体手法を実現し得る。この手法では、ターゲットデータストアの中の同じ場所に向けられる書き込みログブロック（複数可）の中に２つ以上の書き込みがあるかどうかを判定するために、アップロードする段階にある書き込みログブロック（複数可）のメタデータが検査され得る。所与の場所に対する２つ以上の書き込みがある場合、アップロードされるバッファブロックを構築するときに、より早い方の書き込み（複数可）が削除され得る。したがって、例えばデータ重複排除手法に従って、アップロードのためのアップロードプロセスに渡されるブロックは、アップロード前合体手法が適用されなかった場合に存在し得る、同じ場所に対するおそらく２つ以上の書き込みではなく、所与の場所への１つの書き込み（直前の書き込み）だけを含み得る。

実例となるシステム
少なくともいくつかの実施形態において、本明細書で説明されるストレージゲートウェイ技術の１つ以上の一部分または全部を実現するコンピュータシステムは、図２８で図示されるコンピュータシステム３０００等の、１つ以上のコンピュータがアクセス可能な媒体を含む、またはそれにアクセスするように構成される、汎用コンピュータシステムを含み得る。図示される実施形態において、コンピュータシステム３０００は、入力／出力（Ｉ／Ｏ）インターフェース３０３０を介してシステムメモリ３０２０に連結される、１つ以上のプロセッサ３０１０を含む。コンピュータシステム３０００はさらに、Ｉ／Ｏインターフェース３０３０に連結される、ネットワークインターフェース３０４０を含む。

種々の実施形態において、コンピュータシステム３０００は、１つのプロセッサ３０１０を含むユニプロセッサシステム、または複数（例えば、２つ、４つ、８つ、または別の適当数）のプロセッサ３０１０を含むマルチプロセッサシステムであり得る。プロセッサ３０１０は、命令を実行することができる、任意の好適なプロセッサであり得る。例えば、種々の実施形態において、プロセッサ３０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、もしくはＭＩＰＳ ＩＳＡ等の様々な命令セットアーキテクチャ（ＩＳＡ）のいずれか、または任意の他の好適なＩＳＡを実現する、汎用または組み込みプロセッサであり得る。マルチプロセッサシステムにおいて、プロセッサ３０１０のそれぞれは、必ずではないが、一般的に、同じＩＳＡを実現し得る。

システムメモリ３０２０は、プロセッサ（複数可）３０１０によってアクセス可能な命令およびデータを記憶するように構成され得る。種々の実施形態において、システムメモリ３０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、シンクロナスダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュタイプメモリ、または任意の他のタイプのメモリ等の、任意の好適なメモリ技術を使用して実現され得る。図示される実施形態において、ストレージゲートウェイ技術について上で説明される方法、手法、およびデータ等の、１つ以上の所望の機能を実現するプログラム命令およびデータは、システムメモリ３０２０内にコード３０２５およびデータ３０２６として記憶されるように示される。

一実施形態において、Ｉ／Ｏインターフェース３０３０は、プロセッサ３０１０と、システムメモリ３０２０と、ネットワークインターフェース３０４０または他の周辺インターフェースを含む、デバイスの中の任意の周辺デバイスとの間のＩ／Ｏトラフィックを調整するように構成され得る。いくつかの実施形態において、Ｉ／Ｏインターフェース３０３０は、一方の構成要素（例えば、システムメモリ３０２０）からのデータ信号を、もう一方の構成要素（例えば、プロセッサ３０１０）による使用に好適な形式に変換するために、任意の必要なプロトコル、タイミング、または他のデータ変換を行い得る。いくつかの実施形態において、Ｉ／Ｏインターフェース３０３０は、例えば、周辺装置相互接続（ＰＣＩ）バス規格またはユニバーサルシリアルバス（ＵＳＢ）規格の変形等の、種々のタイプの周辺バスを通して取り付けられるデバイスのためのサポートを含み得る。いくつかの実施形態において、Ｉ／Ｏインターフェース３０３０の機能は、例えば、ノースブリッジおよびサウスブリッジ等の、２つ以上の別々の構成要素に分割され得る。また、いくつかの実施形態において、システムメモリ３０２０へのインターフェース等の、Ｉ／Ｏインターフェース３０３０の機能の一部または全部が、プロセッサ３０１０の中へ直接組み込まれ得る。

ネットワークインターフェース３０４０は、例えば、コンピュータシステム３０００と、本明細書で説明される他の図面で図示されるような他のコンピュータシステムまたはデバイス等の、１つまたは複数のネットワーク３０５０に取り付けられる別のデバイス３０６０との間で、データを交換することを可能にするように構成され得る。種々の実施形態において、ネットワークインターフェース３０４０は、例えば、複数のタイプのイーサネット（登録商標）ネットワーク等の、任意の好適な有線または無線の一般的なデータネットワークを介した通信をサポートし得る。加えて、ネットワークインターフェース３０４０は、アナログ音声ネットワークまたはデジタルファイバー通信ネットワーク等の電気通信／電話通信ネットワークを介した通信、ファイバーチャネルＳＡＮ等のストレージエリアネットワークを介した通信、または任意の他の好適なタイプのネットワークおよび／またはプロトコルを介した通信をサポートし得る。

いくつかの実施形態において、システムメモリ３０２０は、ストレージゲートウェイ技術の実施形態を実現するための、他の図面を参照して上で説明されるような、プログラム命令およびデータを記憶するように構成される、コンピュータがアクセス可能な媒体の一実施形態であり得る。しかしながら、他の実施形態において、プログラム命令および／またはデータは、異なるタイプのコンピュータがアクセス可能な媒体で受け取られ、それに送られ、または記憶され得る。概して、コンピュータがアクセス可能な媒体としては、磁気もしくは光媒体等の非一時的な記憶媒体またはメモリ媒体、例えば、Ｉ／Ｏインターフェース３０３０を介してコンピュータシステム３０００に連結されるディスクまたはＤＶＤ／ＣＤが挙げられ得る。非一時的なコンピュータがアクセス可能な記憶媒体としては、コンピュータシステム３０００のいくつかの実施形態においてシステムメモリ３０２０または別のタイプのメモリとして含まれ得る、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の、任意の揮発性または不揮発性媒体も挙げられ得る。さらに、コンピュータがアクセス可能な媒体としては、ネットワークインターフェース３０４０を介して実現され得るようなネットワークおよび／または無線リンク等の通信媒体を介して運搬される、電気信号、電磁信号、もしくはデジタル信号等の、伝送媒体または伝送信号が挙げられ得る。

結論
種々の実施形態はさらに、コンピュータがアクセス可能な媒体に関する、上の説明に従って実現される命令および／またはデータを受け取ること、送ること、または記憶することを含み得る。概して、コンピュータがアクセス可能な媒体としては、磁気または光媒体等の記憶媒体またはメモリ媒体、例えばディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発性または不揮発性媒体、ならびにネットワークおよび／または無線リンク等の通信媒体を介して運搬される、電気信号、電磁信号、またはデジタル信号等の伝送媒体または信号が挙げられ得る。

図面で図示され、本明細書で説明される様々な方法は、例示的な方法の実施形態を表す。それらの方法は、ソフトウェアで、ハードウェアで、またはそれらの組み合わせで実現され得る。方法の順序は、変更され得、また、種々の要素の追加、並べ替え、組み合わせ、省略、修正等が行われ得る。

本開示を利用する当業者には明らかなように、種々の修正および変更が行われ得る。本発明は、全てのそのような修正および変更を含むことが意図され、故に、上の説明は、限定的感覚ではなく、例示的感覚であると見なされるべきである。

本開示の種々の実施形態は、以下の付記を考慮して説明することができる。
付記１． 方法であって、
顧客ネットワーク上のデバイス上に実現されるゲートウェイプロセスによって、リモートゲートウェイ制御プロセスへの接続を開始することと、
ゲートウェイプロセスによって、公開鍵およびデバイスを説明するメタデータをリモートゲートウェイ制御プロセスに送ることと、
ゲートウェイ制御プロセスから、ゲートウェイプロセスによって、起動鍵を受け取ることと、
ゲートウェイプロセスによって、起動鍵を顧客ネットワーク上のプロセスに公表することと、
ゲートウェイプロセスによって、ゲートウェイ制御プロセスから顧客情報を受け取ることとであって、顧客情報は、起動鍵を受け取り、起動鍵をゲートウェイ制御プロセスに提供した顧客ネットワーク上のプロセスから、ゲートウェイ制御プロセスによって取得され、顧客情報は、リモートサービスプロバイダへのゲートウェイプロセスを一意的に識別し、ゲートウェイプロセスを顧客ネットワークの顧客アカウントと関連付ける、受け取ることと、
ゲートウェイ制御プロセスへ、ゲートウェイプロセスによって、セキュリティ証明書の要求を送ることであって、要求は、顧客情報の少なくとも一部分および起動鍵を含む、送ることと、
ゲートウェイプロセスによって、要求されたセキュリティ証明書を受け取ることと、
ゲートウェイプロセスによって、該セキュリティ証明書を受け取った後に、ゲートウェイ制御プロセスから構成情報を取得することと、
を含む、方法。

付記２． 該情報をゲートウェイ制御プロセスに送ること、およびそこから情報を受け取ることは、ゲートウェイプロセスによって開始されるゲートウェイ制御プロセスへの安全な接続を通じて行われる、付記１に記載の方法。

付記３． ゲートウェイプロセスは、顧客データをサービスプロバイダによって提供されるリモートデータストアに記憶するために、顧客ネットワーク上のプロセスの１つ以上とリモートサービスプロバイダとの間のインターフェースとして動作する、付記１に記載の方法。

付記４． ゲートウェイプロセスはさらに、リモートデータストアから顧客データをダウンロードするために、顧客ネットワーク上の１つ以上の顧客プロセスとストレージサービスとの間のインターフェースとして動作し、ストレージゲートウェイは、頻繁にアクセスされる顧客データをローカルにキャッシュする、付記３に記載の方法。

付記５． 顧客ネットワーク上のプロセスから、ゲートウェイ制御プロセスによって顧客情報を取得することは、
起動鍵および顧客情報をコンソールプロセスに提供するために、リモートサービスプロバイダのコンソールプロセスを介して、顧客アカウントにアクセスする、顧客ネットワーク上のプロセスと、
起動鍵および顧客情報をゲートウェイ制御プロセスに提供する、コンソールプロセスと、を含む、付記１に記載の方法。

付記６． 顧客アカウントは、リモートサービスプロバイダの１つ以上のサービスによって、それぞれの顧客に提供される１つ以上のリソースを管理するために、顧客ネットワーク上のプロセスの１つ以上によってアクセス可能である、付記５に記載の方法。

付記７． デバイスであって、
１つのプロセッサと、
プログラム命令を備えるメモリと、を備え、前記プログラム命令は、
リモートゲートウェイ制御プロセスへの接続を開始し、
前記リモートゲートウェイ制御プロセスから起動鍵を受け取り、
前記起動鍵を前記デバイスのポート上に公表し、
前記起動鍵を前記公表することに応じて、前記ゲートウェイ制御プロセスから顧客情報を受け取り、前記顧客情報は、リモートサービスプロバイダへの前記ゲートウェイプロセスを一意的に識別し、前記ゲートウェイプロセスを顧客アカウントと関連付け、
セキュリティ証明書の要求を前記ゲートウェイ制御プロセスに送り、そして、
前記要求されたセキュリティ証明書を受け取る、ように動作可能なゲートウェイを実現するために、前記少なくとも１つのプロセッサによって実行可能である、
デバイス。

付記８． 前記ゲートウェイプロセスはさらに、公開鍵および前記デバイスを説明するメタデータを前記リモートゲートウェイ制御プロセスに送るように動作可能であり、前記起動鍵は、前記公開鍵および前記メタデータを前記リモートゲートウェイ制御プロセスに前記送ることに応じて、前記リモートゲートウェイ制御プロセスから受け取られる、付記７に記載のデバイス。

付記９． 前記ゲートウェイプロセスはさらに、前記要求されたセキュリティ証明書を受け取った後に、前記ゲートウェイ制御プロセスから構成情報を取得するように動作可能である、付記７に記載のデバイス。

付記１０． 前記ゲートウェイプロセスはさらに、前記起動鍵を前記公表した後に、前記顧客情報を受け取ったと判定するまで、または前記起動鍵が満了したと判定するまで、前記顧客情報を受け取ったかどうかを繰り返して確認するように動作可能である、付記７に記載のデバイス。

付記１１． 起動鍵を受け取るために、前記ゲートウェイプロセスはさらに、公開鍵および前記デバイスを説明するメタデータを前記リモートゲートウェイ制御プロセスに送るように動作可能であり、前記ゲートウェイプロセスはさらに、前記起動鍵が満了したと判定した時点で、公開鍵および前記デバイスを説明する前記メタデータを前記リモートゲートウェイ制御プロセスに再度送るように動作可能である、付記１０に記載のデバイス。

付記１２． 前記ゲートウェイプロセスは、顧客データを前記サービスプロバイダによって提供されるリモートデータストアに記憶するために、１つ以上の顧客プロセスと前記リモートサービスプロバイダとの間のインターフェースとして動作する、付記７に記載のデバイス。

付記１３． 前記ゲートウェイプロセスはさらに、前記リモートデータストアから顧客データをダウンロードするために、前記１つ以上の顧客プロセスと前記サービスプロバイダとの間のインターフェースとして動作し、前記ゲートウェイプロセスは、頻繁にアクセスされる顧客データをローカルにキャッシュする、付記１２に記載のデバイス。

付記１４． 前記ゲートウェイプロセスはさらに、前記リモートサービスプロバイダの前記プロセスにそれ自体を識別させるために、前記リモートサービスプロバイダの１つ以上のプロセスへの通信に際して前記セキュリティ証明書を提供するように動作可能である、付記７に記載のデバイス。

付記１５． ゲートウェイプロセスを実現するようにコンピュータが実行可能なプログラム命令を記憶する、非一時的なコンピュータがアクセス可能な記憶媒体であって、該ゲートウェイプロセスは、
公開鍵およびゲートウェイプロセスがリモートゲートウェイ制御プロセスに導入されるデバイスを説明するメタデータを受け取り、
リモートゲートウェイ制御プロセスから起動鍵を受け取り、
起動鍵をローカルネットワーク上の別のプロセスに提供し、
ゲートウェイ制御プロセスから顧客情報を受け取り、顧客情報は、リモートサービスプロバイダへのゲートウェイプロセスを一意的に識別し、ゲートウェイプロセスを顧客アカウントと関連付け、
セキュリティ証明書の要求をゲートウェイ制御プロセスに送り、
ゲートウェイ制御プロセスから要求されたセキュリティ証明書を受け取るように動作可能である、非一時的なコンピュータがアクセス可能な記憶媒体。

付記１６． ゲートウェイプロセスはさらに、ゲートウェイ制御プロセスから構成情報を取得するように動作可能である、請求項１５に記載の非一時的なコンピュータがアクセス可能な記憶媒体。

付記１７． ゲートウェイプロセスはさらに、顧客情報を受け取ったと判定するまで、または起動鍵が満了したと判定するまで、顧客情報を受け取ったかどうかを繰り返し確認するように動作可能である、付記１５に記載の非一時的なコンピュータがアクセス可能な記憶媒体。

付記１８． ゲートウェイプロセスはさらに、起動鍵が満了したと判定した時点で、公開鍵およびデバイスを説明するメタデータをリモートゲートウェイ制御プロセスに再度送るように動作可能である、付記１７に記載の非一時的なコンピュータがアクセス可能な記憶媒体。

付記１９． ゲートウェイプロセスは、顧客データをサービスプロバイダによって提供されるリモートデータストアにアップロードするために、１つ以上の顧客プロセスとリモートサービスプロバイダとの間のインターフェースを提供する、付記１５に記載の非一時的なコンピュータがアクセス可能な記憶媒体。

付記２０． ゲートウェイプロセスはさらに、リモートデータストアから顧客データをダウンロードするために、１つ以上の顧客プロセスとサービスプロバイダとの間のインターフェースを提供し、ゲートウェイプロセスは、頻繁にアクセスされる顧客データをローカルにキャッシュする、付記１９に記載の非一時的なコンピュータがアクセス可能な記憶媒体。

付記２１． 方法であって、
ゲートウェイプロセスから、ゲートウェイ制御プロセスによって、公開鍵および前記ゲートウェイプロセスが導入されるデバイスを説明するメタデータを受け取ることと、
前記ゲートウェイプロセスへ、前記ゲートウェイ制御プロセスによって、起動鍵を送ることと、
顧客プロセスから、前記ゲートウェイ制御プロセスによって、起動鍵を受け取ることであって、前記顧客プロセスは、前記ゲートウェイプロセスから起動鍵を取得する、受け取ることと、
前記顧客プロセスへ、前記ゲートウェイ制御プロセスによって、前記ゲートウェイプロセスが導入される前記デバイスを説明する前記メタデータの少なくとも一部分を送ることと、
前記顧客プロセスから、前記ゲートウェイ制御プロセスによって、顧客情報、および前記ゲートウェイプロセスがリモートサービスプロバイダに登録される旨の確認を受け取ることであって、前記顧客情報は、前記リモートサービスプロバイダへの前記ゲートウェイプロセスを一意的に識別し、前記ゲートウェイプロセスを顧客アカウントと関連付ける、受け取ることと、
前記ゲートウェイプロセスへ前記ゲートウェイ制御プロセスによって、前記顧客情報の少なくとも一部分を送ることと、
前記ゲートウェイプロセスから、前記ゲートウェイ制御プロセスによって、セキュリティ証明書の要求を受け取ることであって、前記要求は、前記顧客情報の少なくとも一部分および前記起動鍵を含む、受け取ることと、
前記ゲートウェイプロセスへ、前記ゲートウェイ制御プロセスによって、前記要求されたセキュリティ証明書を送ることと、
を含む、方法。

付記２２． 前記顧客プロセスから、前記ゲートウェイ制御プロセスによって、前記ゲートウェイプロセスの構成情報を受け取ることと、
前記ゲートウェイプロセスへ、前記ゲートウェイ制御プロセスによって、前記顧客プロセスから受け取った前記構成情報を送ることと、をさらに含む、付記２１に記載の方法。

付記２３． 情報を前記ゲートウェイプロセスに前記送ること、およびそこから情報を受け取ることは、前記ゲートウェイプロセスによって開始される前記ゲートウェイ制御プロセスへの安全な接続を通じて行われる、付記２１に記載の方法。

付記２４． 前記ゲートウェイプロセスは、顧客データを前記サービスプロバイダによって提供されるリモートデータストアに記憶するために、１つ以上の顧客プロセスと前記リモートサービスプロバイダとの間のインターフェースとして動作する、付記２１に記載の方法。

付記２５． 前記ゲートウェイプロセスはさらに、前記リモートデータストアから顧客データをダウンロードするために、前記１つ以上の顧客プロセスと前記ストレージサービスとの間のインターフェースとして動作し、前記ストレージゲートウェイは、頻繁にアクセスされる顧客データをローカルにキャッシュする、付記２４に記載の方法。

付記２６． 前記顧客ネットワーク上の前記プロセスは、前記起動鍵、前記顧客情報、および前記確認を前記ゲートウェイ制御プロセスに提供するために、前記顧客アカウントにアクセスする、付記２１に記載の方法。

付記２７． 前記顧客アカウントは、前記リモートサービスプロバイダの１つ以上のサービスによって、前記それぞれの顧客に提供される１つ以上のリソースを管理するために、前記顧客ネットワーク上の１つ以上のプロセスによってアクセス可能である、付記２６に記載の方法。

Claims (15)

1. デバイスであって、
   少なくとも１つのプロセッサと、
   プログラム命令を備えるメモリと、を備え、前記プログラム命令は、
   リモートゲートウェイ制御プロセスへの接続を開始し、
   前記リモートゲートウェイ制御プロセスから起動鍵を受け取り、
   前記起動鍵を前記デバイスのポート上に公表し、
   前記起動鍵を前記公表することに応じて、前記ゲートウェイ制御プロセスから顧客情報を受け取り、前記顧客情報は、リモートサービスプロバイダへの前記ゲートウェイプロセスを一意的に識別し、前記ゲートウェイプロセスを顧客アカウントと関連付け、
   セキュリティ証明書の要求を前記ゲートウェイ制御プロセスに送り、そして、
   前記要求されたセキュリティ証明書を受け取る、ように動作可能なゲートウェイを実現するために、前記少なくとも１つのプロセッサによって実行可能である、
   デバイス。
2. 前記ゲートウェイプロセスはさらに、公開鍵および前記デバイスを説明するメタデータを前記リモートゲートウェイ制御プロセスに送るように動作可能であり、前記起動鍵は、前記公開鍵および前記メタデータを前記リモートゲートウェイ制御プロセスに前記送ることに応じて、前記リモートゲートウェイ制御プロセスから受け取られる、請求項１に記載のデバイス。
3. 前記ゲートウェイプロセスはさらに、前記要求されたセキュリティ証明書を受け取った後に、前記ゲートウェイ制御プロセスから構成情報を取得するように動作可能である、請求項１に記載のデバイス。
4. 前記ゲートウェイプロセスはさらに、前記起動鍵を前記公表した後に、前記顧客情報を受け取ったと判定するまで、または前記起動鍵が満了したと判定するまで、前記顧客情報を受け取ったかどうかを繰り返して確認するように動作可能である、請求項１に記載のデバイス。
5. 起動鍵を受け取るために、前記ゲートウェイプロセスはさらに、公開鍵および前記デバイスを説明するメタデータを前記リモートゲートウェイ制御プロセスに送るように動作可能であり、前記ゲートウェイプロセスはさらに、前記起動鍵が満了したと判定した時点で、公開鍵および前記デバイスを説明する前記メタデータを前記リモートゲートウェイ制御プロセスに再度送るように動作可能である、請求項４に記載のデバイス。
6. 前記ゲートウェイプロセスは、顧客データを前記サービスプロバイダによって提供されるリモートデータストアに記憶するために、１つ以上の顧客プロセスと前記リモートサービスプロバイダとの間のインターフェースとして動作する、請求項１に記載のデバイス。
7. 前記ゲートウェイプロセスはさらに、前記リモートデータストアから顧客データをダウンロードするために、前記１つ以上の顧客プロセスと前記サービスプロバイダとの間のインターフェースとして動作し、前記ゲートウェイプロセスは、頻繁にアクセスされる顧客データをローカルにキャッシュする、請求項６に記載のデバイス。
8. 前記ゲートウェイプロセスはさらに、前記リモートサービスプロバイダの前記プロセスにそれ自体を識別させるために、前記リモートサービスプロバイダの１つ以上のプロセスへの通信に際して前記セキュリティ証明書を提供するように動作可能である、請求項１に記載のデバイス。
9. 方法であって、
   ゲートウェイプロセスから、ゲートウェイ制御プロセスによって、公開鍵および前記ゲートウェイプロセスが導入されるデバイスを説明するメタデータを受け取ることと、
   前記ゲートウェイプロセスへ、前記ゲートウェイ制御プロセスによって、起動鍵を送ることと、
   顧客プロセスから、前記ゲートウェイ制御プロセスによって、起動鍵を受け取ることであって、前記顧客プロセスは、前記ゲートウェイプロセスから起動鍵を取得する、受け取ることと、
   前記顧客プロセスへ、前記ゲートウェイ制御プロセスによって、前記ゲートウェイプロセスが導入される前記デバイスを説明する前記メタデータの少なくとも一部分を送ることと、
   前記顧客プロセスから、前記ゲートウェイ制御プロセスによって、顧客情報、および前記ゲートウェイプロセスがリモートサービスプロバイダに登録される旨の確認を受け取ることであって、前記顧客情報は、前記リモートサービスプロバイダへの前記ゲートウェイプロセスを一意的に識別し、前記ゲートウェイプロセスを顧客アカウントと関連付ける、受け取ることと、
   前記ゲートウェイプロセスへ前記ゲートウェイ制御プロセスによって、前記顧客情報の少なくとも一部分を送ることと、
   前記ゲートウェイプロセスから、前記ゲートウェイ制御プロセスによって、セキュリティ証明書の要求を受け取ることであって、前記要求は、前記顧客情報の少なくとも一部分および前記起動鍵を含む、受け取ることと、
   前記ゲートウェイプロセスへ、前記ゲートウェイ制御プロセスによって、前記要求されたセキュリティ証明書を送ることと、
   を含む、方法。
10. 前記顧客プロセスから、前記ゲートウェイ制御プロセスによって、前記ゲートウェイプロセスの構成情報を受け取ることと、
    前記ゲートウェイプロセスへ、前記ゲートウェイ制御プロセスによって、前記顧客プロセスから受け取った前記構成情報を送ることと、をさらに含む、請求項９に記載の方法。
11. 情報を前記ゲートウェイプロセスに前記送ること、およびそこから情報を受け取ることは、前記ゲートウェイプロセスによって開始される前記ゲートウェイ制御プロセスへの安全な接続を通じて行われる、請求項９に記載の方法。
12. 前記ゲートウェイプロセスは、顧客データを前記サービスプロバイダによって提供されるリモートデータストアに記憶するために、１つ以上の顧客プロセスと前記リモートサービスプロバイダとの間のインターフェースとして動作する、請求項９に記載の方法。
13. 前記ゲートウェイプロセスはさらに、前記リモートデータストアから顧客データをダウンロードするために、前記１つ以上の顧客プロセスと前記ストレージサービスとの間のインターフェースとして動作し、前記ストレージゲートウェイは、頻繁にアクセスされる顧客データをローカルにキャッシュする、請求項１２に記載の方法。
14. 前記顧客ネットワーク上の前記プロセスは、前記起動鍵、前記顧客情報、および前記確認を前記ゲートウェイ制御プロセスに提供するために、前記顧客アカウントにアクセスする、請求項９に記載の方法。
15. 前記顧客アカウントは、前記リモートサービスプロバイダの１つ以上のサービスによって、前記それぞれの顧客に提供される１つ以上のリソースを管理するために、前記顧客ネットワーク上の１つ以上のプロセスによってアクセス可能である、請求項１４に記載の方法。

Images