本開示の種々の実施形態に従うシステムおよび方法は、電子環境におけるリソースの管理のための従来の手法において経験される前述および他の欠陥のうちの1つ以上を克服することができる。種々の実施形態に従うシステムおよび方法は、顧客または仮想アドレス空間といった第1のアドレス空間と、クラウドネットワークプロバイダまたは物理アドレス空間といった第2のアドレス空間との間の、パケットの処理を提供する。種々のネットワークオフロードデバイスといった商品デバイスのセグメント化およびセグメント結合オフロード特性といった特性は、特に、それが仮想化された環境に関する際、ネットワークトラフィックに関するオーバーヘッドの低減を助長するために使用することができる。セグメント化およびセグメント結合オフロード特性の提供のための種々の手法は、例えば、「2009年9月9日」出願の、「Stateless Packet Segmentation and Processing」と題する、同時係属の米国特許出願第12/556,453号、および2010年9月17日出願の「Framework for Stateless Packet Tunneling」と題する同出願第12/885,258において説明され、これらの各々は、参照することによって、本明細書に組み込まれる。
種々の実施形態は、仮想化されたオーバーレイネットワークを実装するために、シングルルートI/O仮想化(single root I/O virtualization:SR−IOV)といったプロトコルと併せて、オフロードデバイスが、オープンな、および独自のステートレストンネリングをサポートすることを可能にする。SR−IOVは、一般的に、周辺構成要素相互接続(PCI)デバイスといったデバイスが、複数の、独立した物理的デバイスとして考えられることを可能にする、相互運用に関する標準的な仕様を指す。SR−IOVは、物理的機能(PF)および仮想機能(VF)を活用する。
物理的機能は、一般的に、完全装備の機能である一方、仮想機能は、一般的に、少なくとも一部の構成リソースを欠いている場合がある、より軽量な機能である。SR−IOVは、典型的に、BIOSにおけるサポート、ならびにハードウェア上で実行されるハイパーバイザまたはオペレーティングシステムインスタンスにおけるサポートを必要とする。
少なくとも一部の実施形態において、オフロードデバイス(またはかかるデバイスのベンダもしくは製造元)は、パケット処理のための特定の機能性を提供することができる。例えば、Dom−0(即ち、ドメインゼロ、典型的に、起動時にXenハイパーバイザによって開始される最初のドメイン)に基づく実装は、進出パケットをカプセル化する、および進入パケットを脱カプセル化するといった、ある行為を実施するように、オフロードデバイスによって使用することができる種々の規則を利用することができる。進出パケット送信元チェックは、送信元VMに基づき、全ての進出パケットにおいて実施され得、送信元MACアドレスおよび送信元IPアドレスを照合することを含む。一部の実施形態において、オフロードデバイスは、特定のVLAN(仮想ローカルエリアネットワーク)タグを強行するか、またはそうでなければVLANタグを追加することができる。進出パケット送信元チェックの後、パケットを、既存の規則のリストに対して適合させることができる。適合が存在する場合、対応するカプセル化行為をパケット上で行い、適宜、パケットを伝送することができる。そうでない場合、パケットを、さらなる処理のために、Dom−0制御ソフトウェアへ送信することができる。
進入パケットに関して、ある実施形態におけるパケットは、例えば、事前定義されたIPプロトコル番号、およびL2ヘッダエンドからの事前定義されたオフセットでの事前定義された1バイト値に基づく、特別な形式を使用して、カプセル化されているとして識別することができる。これらの値は、各々、Dom−0によって構成することができる。カプセル化されない全ての進入パケットは、Dom−0へ配信することができる。カプセル化された進入に関して、いずれの不明瞭なビット(外部L3ヘッダの直後に位置する)は、事前定義された長さの不明瞭なビットを使用して識別することができる。各パケットは、事前定義されたオフセットでの不明瞭なビット内の1バイトフィールドを使用して、特定の仮想機械(VM)(例えば、SR−IOVベクタ)に属するとしてさらに分類することができる。
各SR−IOV機能は、一組の進入規則とともに構成することができる。各規則は、主に、カプセル化された進入パケット、外部送信元IPアドレス、外部送信先IPアドレス、ならびに送信元および標的MACアドレスの不明瞭なビットと適合する、不明瞭なビットから成ることができる。カプセル化された進入パケットが、特定のSR−IOV機能に対する進入規則のうちの1つと適合する(即ち、不明瞭なビットが適合する)時、パケットは、脱カプセル化することができ(即ち、不明瞭なビットが除去される)、内部IPヘッダのTTLは、規則において指定される値分デクリメントされ、パケットは、SR−IOV機能に対応するVMへ配信される。規則のうちのいずれにも適合しない進入パケットは、Dom−0へ配信することができる。
少なくとも一部の実施形態において、オフロードデバイスは、Dom−0から読み取られ得る、またはリセットされ得る、各カプセル化および脱カプセル化規則に対する、パケット数およびバイト数を維持する。種々の実施形態はまた、Dom−0からSR−IOV機能にパケットを注入する能力を提供することができる。ある実施形態は、各パケットが有効である適合規則にかかわらず、Dom−0を通過するように強制されるデバッグモードを提供することができる。SR−IOV機能に対する最大伝送単位(maximum transmission unit:MTU)は、Dom−0から設定することができ、少なくとも一実施形態においては、1500にデフォルト設定される。ゲストがMTUサイズを変更しようとする場合および時、オフロードデバイスは、提唱されたMTUが、Dom−0によって設定される最大MTUを超過しないということを確実とすることができる。一部の実施形態において、オフロードデバイスはまた、接続追跡を実施することができ、これは、オフロードデバイス上でのステートフルなファイアウォール実装を提供するために使用することができる。
少なくとも一部の実施形態において、進入および進出パケットの両方のためのカプセル化および脱カプセル化規則を管理する、Dom−0制御ソフトウェアを提供することができる。Dom−0制御ソフトウェアは、例えば、オフロードデバイスによって提供されるパケット数統計値、ならびにサブストレートARPクエリを使用して、サブストレートネットワークのためのアドレス解決プロトコル(Address Resolution Protocol:ARP)キャッシュを管理することができる。Dom−0制御ソフトウェアはまた、ある場合、どの規則がオフロードデバイスにプッシュされなければならないか、およびオフロードデバイスが必要とされる規則の全てはサポートしない場合、どの規則が、オーバーフロー規則として、Dom−0によって管理されなければならないかを判断することができる。
図1は、種々の実施形態に従う態様を実装するための環境100の実施例を例解する。理解されるように、ウェブベースの環境が解説目的で使用されるが、種々の実施形態を実装するために、適切な場合、異なる環境が使用されてもよい。示される環境100は、試験または開発部分(もしくは側)および生産部分の両方を含む。電子クライアントデバイス102は、適切なネットワーク104上で要求、メッセージ、または情報を送信および受信し、デバイスのユーザに情報を伝達し戻すように動作可能な任意の適切なデバイスを含むことができる。かかるクライアントデバイスの例としては、パーソナルコンピュータ、携帯電話、手持ち式メッセージングデバイス、ラップトップコンピュータ、セットトップボックス、個人データアシスタント、電子書籍リーダ等が挙げられる。ネットワークは、イントラネット、インターネット、セルラネットワーク、ローカルエリアネットワーク、または任意の他のかかるネットワーク、もしくはこれらの組み合わせを含む、任意の適切なネットワークを含むことができる。かかるシステムのために使用される構成要素は、選択されるネットワークおよび/または環境のタイプに少なくとも部分的に依存し得る。かかるネットワークを介して通信するためのプロトコルおよび構成要素は、公知であり、本明細書においては詳細に述べない。ネットワーク上での通信は、有線または無線接続、およびこれらの組み合わせによって有効にすることができる。本実施例において、ネットワークは、環境が、要求を受信し、かつそれに応答してコンテンツをサーブするためのウェブサーバ106を含むとして、インターネットを含むが、他のネットワークに関しては、当業者には明らかであるように、同様の目的を果たす代替的なデバイスが使用され得る。
例解的な環境は、少なくとも1つのアプリケーションサーバ108と、複数のリソース、サーバ、ホスト、インスタンス、ルータ、スイッチ、データストア、および/または本明細書においてデータプレーン110と称されるものを定義する他のかかる構成要素とを含むが、このプレーンのリソースは、データの記憶、およびそれへのアクセスの提供に限定されないということが理解されるべきである。連鎖されるか、または別様に構成されてもよく、適切なデータストアからのデータの取得といったタスクを実施するように相互作用することができる、いくつかのアプリケーションサーバ、層、または他の要素、プロセス、もしくは構成要素が存在し得ることが理解されるべきである。本明細書において使用される際、「データストア」という用語は、データを記憶する、それへアクセスする、およびそれを取り出すことか可能な任意のデバイスまたはデバイスの組み合わせを指し、任意の標準、分散型、またはクラスタ化環境において、任意の組み合わせおよび数のデータサーバ、データベース、データ記憶デバイス、およびデータ記憶媒体を含んでもよい。アプリケーションサーバは、クライアントデバイスのための1つ以上のアプリケーションの様態を実行するように、必要に応じて、データストアと一体化させ、アプリケーションのためのデータアクセスおよびビジネスロジックの大部分を処理するための任意の適切なハードウェアおよびソフトウェアを含むことができる。アプリケーションサーバは、データストアと協働してアドミッション制御サービスを提供し、ユーザに転送されるべき文字、図、音声、および/またはビデオといったコンテンツを生成することができ、これは、本実施例において、HTML、XML、または別の適切な構造化された言語の形態で、ウェブサーバによってユーザにサーブされ得る。一部の実施形態において、ウェブサーバ106、アプリケーションサーバ108、および同様の構成要素は、データプレーンの一部として見なすことができる。全ての要求および応答の処理、ならびにクライアントデバイス102とアプリケーションサーバ108との間のコンテンツの配信は、ウェブサーバによって処理することができる。本明細書の他の個所で述べられるように、構造化されたコードは、任意の適切なデバイスまたはホスト機械上で実行することができるため、ウェブおよびアプリケーションサーバは必須ではなく、例示的な構成要素であるに過ぎないということが理解されるべきである。
環境はまた、開発および/または試験サイドを含み、これは、開発者、データ管理者、または試験者といったユーザが、システムにアクセスすることを可能にする、ユーザデバイス118を含む。ユーザデバイス118は、クライアントデバイス102に関して上で説明されるようなものといった、任意の適切なデバイスまたは機械とすることができる。環境はまた、開発サーバ120を含み、これは、アプリケーションサーバ108と同様に機能するが、典型的には、例えば、コードが生産サイド上で配備および実行され、外部ユーザにアクセス可能となる前に、開発および試験中にコードを実行する。一部の実施形態において、アプリケーションサーバは、開発サーバとして機能することができ、別個の生産および試験記憶装置を使用しなくてもよい。
データプレーン110のデータストアは、いくつかの別個のデータ表、データベース、または特定の様態に関するデータを記憶するための他のデータ記憶機構および媒体を含むことができる。例えば、例解されるデータプレーンは、生産データ112およびユーザ情報116を記憶するための機構を含み、これらは、生産サイドのためにコンテンツをサーブするために使用することができる。データプレーンはまた、試験データ114を記憶するための機構を含むように示され、これは、試験サイドのためにユーザ情報とともに使用することができる。適切な場合、上で列記される機構のうちのいずれか、またはデータプレーン110における追加の機構に記憶することができる、ページイメージ情報およびアクセス権情報のためといった、データストアに記憶されるために必要とされ得る多くの他の態様が存在し得るということが理解されるべきである。データプレーン110は、それと関連付けられるロジックを通じて、アプリケーションサーバ108または開発サーバ120から命令を受信するように、およびそれに応答して、データ、命令、もしくは他のかかる情報を取得、更新、またはそうでなければ処理するように、動作可能である。一実施例において、ユーザは、あるタイプの項目に対して検索要求を提出する場合がある。この場合、データプレーンの構成要素は、ユーザのアイデンティティを照合するように、ユーザ情報にアクセスする、およびそのタイプの項目についての情報を取得するように、カタログ詳細情報にアクセスする場合がある。次いで、情報は、例えば、ユーザがユーザデバイス102上のブラウザを介して観視することができる、ウェブページ上の結果リストにおいて、ユーザに返すことができる。関心対象の特定の項目に関する情報は、専用ページまたはブラウザのウィンドウにおいて観視することができる。
各サーバは、典型的に、そのサーバの一般管理および動作に対する実行可能なプログラム命令を提供するオペレーティングシステムを含み、典型的に、サーバのプロセッサによって実行される時に、サーバが、その意図される機能を実施することを可能にする命令を記憶する、コンピュータが読み取り可能な媒体を含む。サーバのオペレーティングシステムおよび一般的な機能性に対する好適な実装は、既知であるか、または商業的に利用可能であり、特に本明細書における本開示を考慮すれば、当業者によって容易に実装される。
一実施形態における環境は、1つ以上のコンピュータネットワークまたは直接接続を使用して、通信リンクを介して相互接続される、いくつかのコンピュータシステムおよび構成要素を利用する、分散型コンピューティング環境である。しかしながら、かかるシステムは、図1に例解されるものよりも少ないまたは多い数の構成要素を有するシステムにおいて、同等に良好に動作し得るということが、当業者によって理解されるであろう。このため、図1におけるシステム100の描写は、本質的に例解的なものであり、本開示の範囲を限定しないと捉えられるべきである。
図1に例解されるものといった環境は、複数のホストおよび種々のタイプのリソースが、コンテンツのサーブ、ユーザの認証、リソースの分配、またはいくつかの他のかかるタスクのうちのいずれかの実施といったタスクを実施するために使用される場合がある、種々のコンテンツプロバイダまたは他のかかるエンティティに有用であり得る。これらのホストのうちの一部は、同様の機能性を提供するように構成され得る一方で、他のサーバは、少なくとも何からの異なる機能を実施するように構成される場合がある。かかる場合における電子環境は、以下で詳細に述べられる、図2の構成200において例解されるものといった、追加の構成要素および/または他の配設を含む場合がある。
一実施形態に従うシステムおよび方法は、データ環境の一部として、またはユーザとデータプレーンとの間の経路において、ユーザおよびアプリケーションが、共有および/または専用リソースにアクセスすることを可能にする一方で、顧客、管理者、または他の承認されたユーザが、リソースを、種々のユーザ、クライアント、またはアプリケーションに分配し、それらの分配への順守を確実とすることを可能にする、少なくとも1つのリソースアクセスゲートウェイ、または制御プレーンを提供する。かかる機能性は、ユーザが、リソースを共有する他のユーザによる待ち時間の悪化または他のかかる問題を懸念することなく、クラウドにおいて、リレーショナルデータセットを記憶、処理、およびクエリするといった、タスクを実施することを可能にする。かかる機能性はまた、ゲストユーザが、ストリーミング媒体をレンダリングおよび/もしくはサーブするといった任意の適切な機能性を実施するように、またはいくつかの他のかかる動作のうちのいずれかを実施するように、リソースへのアクセスを取得することを可能にする。本実施例は、インターネット、ウェブサービス、およびインターネットベースの技術に関して述べられるが、種々の実施形態の様態は、電子環境におけるネットワーク上で利用可能であるか、または提供される、任意の適切なリソースまたはサービスとともに使用することができるということが理解されるべきである。さらに、種々の実施例が、ディスク、データ記憶装置、ホスト、および周辺デバイスへの共有アクセスに関して提示されるが、任意の適切なリソースを、任意の適切な目的で種々の実施形態の範囲内において使用することができ、任意の適切なパラメータを、それぞれのユーザのいずれかまたは全てによって、かかるリソースのアクセスまたは使用を調節するために監視および使用することができるということが理解されるべきである。
リソースゲートウェイまたは制御プレーン208は、データプレーン232における種々のリソースへのアクセスを提供および/または管理するように、一部の環境において使用することができる。クラウドコンピューティング環境において、これは、クラウドマネージャ210、またはクラウドにおいて、種々のリソースへのアクセスを管理する同様のシステムに対応し得る。一実施形態において、ユーザまたは顧客が、種々のリソースへのアクセスを要求することを可能にする、一組のアプリケーションプログラミングインターフェース(API)220または他のかかるインターフェースが提供される。一度、アクセスの確立、リソースの分配等が行われると、ユーザは、データ記憶または処理といった、そのリソースに関するあるタスクを実施するように、リソースと直接通信することができる。ユーザは、一度アクセスが確立されると、データインスタンス、ホスト、または他のリソースと通信するように、直接インターフェースまたはAPIを使用することができるが、アクセスを取得するように制御プレーン構成要素(複数を含む)を使用する。
図2は、一実施形態に従って、使用することができる、クラウドコンピューティングマネージャシステムを含み得るといった、構成200の実施例を例解する。本実施例において、エンドユーザのためのコンピューティングデバイス202は、指定されたリソースまたはリソースタイプへのアクセスを取得するといったタスクを実施するように、制御プレーン208(または他のかかるアクセス層)に、ネットワーク206を通じて、呼び出しを行うことができるように示される。エンドユーザコンピューティングデバイスおよびアプリケーションが、解説目的で使用されるが、種々の実施形態において、適切な場合、任意の適切なユーザ、アプリケーション、サービス、デバイス、構成要素、またはリソースが、インターフェース(複数を含む)、ならびに接続構成要素およびデータ環境の構成要素にアクセスすることができるということが理解されるべきである。さらに、ある構成要素は、データ「プレーン」にグループ化されるが、これは、それぞれの機能性を提供するために使用される、少なくとも一部のリソース(例えば、ハードウェアおよび/またはソフトウェア)の実際のまたは仮想の分離を指し得るということが理解されるべきである。さらに、制御プレーンは、ある実施形態において、データプレーンの一部であると見なすことができる。本実施形態において、単一の制御プレーンが示されるが、他の実施形態において、制御またはアクセス管理構成要素もしくはサービスの複数のインスタンスが存在し得る。制御プレーンは、コンピュータが実行可能な命令とともに構成される少なくとも1つのサーバといった、ハードウェアおよび/またはソフトウェアの任意の適切な組み合わせを含むことができる。制御プレーンはまた、ネットワーク206からウェブサービス呼び出しまたは他のかかる要求を受信するための一組のAPI(または他のかかるインターフェース)を含むことができ、ここで、ウェブサービス層212が、呼び出しに作用するまたはそれを処理するために必要とされるステップまたは行為を判断するように、解析または別様に分析することができる。例えば、ユーザに対してクエリを実行するように、データリポジトリへの接続を確立するための要求を含む、ウェブサービス呼び出しが受信される場合がある。本実施例において、ウェブサービス層は、必要とされる接続またはアクセスのタイプ、必要とされるリソースの適切なタイプ(複数を含む)、または他のかかる態様を判断するように、要求を解析することができる。
制御プレーンは、1つ以上のリソース分配マネージャ210を含むことができ、各々が、要求と関連付けられるユーザまたはクライアントの認証、および適切なリソース(複数を含む)へのアクセスの取得または分配といった、タスクを担う。かかるシステムは、種々のタイプの要求を処理し、種々のタイプの接続を確立することができる。かかるシステムはまた、特定のグラフィックプロセッサまたは他のタイプのハードウェアもしくはハードウェア機能性といった、種々のタイプのリソースに対する要求を処理することができ、かつ適切なリソース(複数を含む)へのアクセスを提供することができる。データプレーンの構成要素、またはクラウドのリソース層は、リソースを提供するように、必要なタスクを実施することができる。例えば、データインスタンスへのアクセスに関して、これは、データストアインスタンスのプロビジョニング、オフインスタンス永続記憶装置のボリュームの分配、永続記憶装置ボリュームのデータストアインスタンスへの取り付け、ならびにIPアドレス(DNSマッピングから導出)、または顧客がデータインスタンスにアクセスする、または別様に接続するために使用することができる、他のアドレス、ポート、インターフェース、もしくは識別子の分配および取り付けといった、タスクを含むことができる。例えば、特定のタイプのハードウェアを使用する命令の処理の取得といったタスクに関して、データプレーンの構成要素は、制御プレーンと併せて、ユーザのためのデバイスのプロビジョニング、ならびにリソースへの特定のアクセスレベルにおける、ある期間のリソースへの共有および/または専用アクセスの提供といった、行為を実施することができる。本実施例において、ユーザには、リソースにアクセスするために使用されるべきIPアドレスおよびポートアドレスを提供することができる。次いで、ユーザは、制御プレーン208にアクセスする、またはそれを通過することを必要とせずに、IPアドレスおよびポートを使用して、直接、リソースにアクセスすることができる。
本実施形態における制御プレーン208はまた、少なくとも1つの監視構成要素214を含む。データインスタンスまたは他のリソースが分配される、作成される、またはそうでなければデータプレーン内で利用可能とされる時、リソースに関する情報は、監視データストア216といった、制御プレーンにアクセス可能なデータストアに書き込むことができる。監視データストアは、別個のデータストア、または別のデータストアの一部分とすることができるということが理解されるべきである。監視構成要素214は、種々のユーザによるリソースの過去の使用、ユーザに分配されているスレッドまたはリソースの現在の数もしくはタイプ、および他のかかる使用情報といった情報を判断するように、監視データストア216内の情報にアクセスすることができる。監視構成要素はまた、データ環境における所与のユーザに対するアクティブな接続の数、および各接続の使用についての態様といった情報を判断するように、データ環境の構成要素を呼び出すことができる。監視構成要素は、常に、接続マネージャを通じて提供される分配を有する、ユーザ、クライアント等による、各リソースの使用を監視することができる。監視構成要素はまた、ユーザに与えられる一般的な分配、ユーザに対するスロットリングまたは制限情報、ユーザに対するリソース許可、またはアドミニストレータもしくは他のかかるユーザによって指定および/または更新することができる任意の他のかかる情報といった情報を記憶することができる、管理(「Admin」)または同様のデータストア216に記憶される情報にアクセスすることができる。
ユーザが、種々のデータインスタンスへの接続を要求する実施例において、データ環境における各インスタンス222は、少なくとも1つのデータストア226と、データストアへのアクセスを提供する機械のためのホストマネージャ構成要素228とを含むことができる。一実施形態におけるホストマネージャは、ソフトウェア開発およびデータストア動作、ならびにデータストアおよび/またはそれぞれのインスタンスの状態の監視といったタスクを管理するようにプログラムされる、TomcatもしくはJava(登録商標)アプリケーションサーバといった、インスタンスおよび/またはアプリケーションサーバ上で実行される、アプリケーションまたはソフトウェアエージェントである。ホストマネージャは、論理ボリュームおよびファイルシステムのセットアップ、データベースバイナリおよびシードのインストール、ならびにリポジトリの開始または停止を含む、新しいリポジトリに対するインスタンスのセットアップといったタスクの管理および/または実施を担うことができる。ホストマネージャは、データストアの健全状態を監視することができ、I/Oエラーまたはデータ記憶装置エラーといったエラー条件に関して、データストアを監視し、必要な場合、データストアを再起動することができる。ホストマネージャはまた、ソフトウェアパッチのインストール、ならびにデータストアおよび/またはオペレーティングシステムのアップグレードを実施および/または管理することができる。ホストマネージャはまた、CPU、メモリ、およびI/O使用に関し得るといった、関連メトリックを収集することができる。
リソースマネージャ210は、負荷、使用、容量等といったステータス情報を判断するように、接続が確立されている各ホストマネージャ228と、またはリソース環境の管理サーバもしくは他の構成要素に、定期的に通信することができる。
述べられるように、一度リソースがプロビジョニングされ、ユーザに、DNSマッピングから導出されるIPアドレス、または他のアドレスもしくは場所が提供されると、ユーザは、リソース222と直接相互作用するように、Java Database Connectivity(JDBC)または他のかかるプロトコルを使用して、ネットワークを通じて、データプレーン232の構成要素またはリソースと「直接」通信することができる。種々の実施形態において、述べられるように、データプレーンは、コンピューティングクラウド環境、あるいは「クラウド」、またはハードウェアおよび/もしくはソフトウェア構成要素の動的ネットワークにわたり、データ記憶装置およびアクセスを提供する、一組のウェブサービスおよびリソースの形態を採る(または少なくともそれらを含むか、もしくはそれら一部である)。例えば、インスタンスまたは利用可能性障害は、使用のための任意の適切な置換インスタンスにIPアドレスをプログラムで再マッピングすることによって、マスクすることができるため、DNSマッピングから導出されるIPアドレスは、かかる動的クラウド環境において有益である。例えば、ユーザ202またはアプリケーション204から受信される要求を、ネットワークアドレス翻訳(network address translation:NAT)ルータ224、または他の適切な構成要素に方向付けることができ、これは、実際のリソース222、または要求のマッピングされたアドレスに対応するホストに、要求を方向付けることができる。かかる手法は、ユーザまたはアプリケーションが、インスタンスにアクセスするために使用されるIPアドレスまたは他のアドレスを変更することを必要とせずに、インスタンスが、動的に移動されること、更新されること、複製されること等を可能にする。一部の場合において、データインスタンスといったリソース222は、少なくとも1つのバックアップインスタンス230またはコピーを、永続記憶装置内に有することができる。
述べられるように、リソースは、様々なアクセスまたは分配レベルでもって、同時、または異なる時間のいずれかに、複数のユーザ、クライアント、アプリケーション等間で共有することができる。ユーザが、機械またはリソースへの専用アクセスを有する時、ユーザはまた、必要とされるアクセスのタイプ、および他のかかる要因に依存して、ある期間、リソースへのネイティブまたは「ベアメタル」アクセスを有する場合がある。デバイスへのネイティブアクセスを有するユーザは、リソースに対するファームウェアまたは他の構成情報を修正する能力を有し得、これは、その後のユーザが、最初に再イメージングすること、またはそうでなければリソースの状態を照合することなく、リソースを利用する能力に影響し得るため、リソースへのこのレベルのアクセスの提供は、リソースのプロバイダに対する潜在的なリスクを伴う。
種々の実施形態は、プロバイダが、ユーザまたは顧客に、妥当なレベルのセキュリティを有するハードウェアリソースへの実質的に完全なアクセスを与えることを可能にする。リモートハードウェアへのこのネイティブレベルアクセスは、例えば、サーバ、ホスト、およびクラスタインスタンスといったリソースに提供することができる。クラスタインスタンスといったリソースに関して、顧客は、周辺構成要素相互接続(peripheral component interconnect:PCI)バスといった構成要素を使用して接続される周辺デバイスを含み得るといった、ハードウェアリソースのサブセットへのネイティブアクセスを有し得る。これらの周辺デバイスは、ネットワークインターフェースカード(NIC)、グラフィック処理装置(GPU)、および、現在のクラウド環境において、しばしば、仮想化されるであろう同様のデバイスを含むことができる。一部の場合において、顧客は、その中に組み込まれる任意もしくは全てのデバイスを含む、機械全体、または機械群への完全なアクセスを有する場合がある。サーバのラックといった機械群に関して、ユーザには、ラックの一部として提供される任意のスイッチまたは他のデバイスもしくは構成要素を含む、ラック全体への実質的に完全なアクセスが与えられる場合がある。
あるプロバイダは、物理的ハードウェアの管理を「より信頼できる」実行コンテキストにおいて行うことができるように、また実行を中断することなく、異なるリソースへ顧客を移行させる能力、ならびに顧客または「ゲスト」は特定のハードウェアに結び付いていないため、その価格で最良のユーティリティのコンピューティングの価値を提供することを競合するベンダの能力といった、追加の利益を提供することができるように、かかるハードウェアリソースを仮想化された抽象として提示する。また、ゲストは、多数のハードウェア固有のドライバを必要としないため、より少ないかつより単純なゲストインスタンス画像を使用することができる。しかしながら、仮想化は、仮想化のためのネイティブ加速を含まないハードウェアに対する、桁違いの性能ペナルティを招く可能性があり、特定のハードウェアデバイスの仮想化は、そのデバイス(例えば、ネットワークインターフェースを仮想化するために使用されるプロセッサおよび/またはメモリ)と無関係の相当なリソースを消費する可能性があるため、かかる仮想化は、潜在的に著しい費用を伴う可能性がある。また、仮想化サポートは、新しいハードウェア(例えば、ビデオカード)の商品の利用可能性より数年遅れる可能性があり、あるアプライアンスハードウェアは、しばしば、特殊すぎるか、または「ニッチ」であり、強力な仮想化サポートを保証することができない。利益率の高いニッチアプライアンスのサポートにおける、または新しいハードウェアタイプのクラウドサポートに対して市場初となることにおける、潜在的に大きい市場機会が存在する。しかしながら、ネイティブアクセスを通じてかかるサポートを提供することは、例えば、プロビジョニング技術、支払請求、リソース利用および均衡化、ならびにネットワーク層2レイアウトといった、内部クラウドの種々の態様を脆弱なままにする可能性があり、顧客要件をはるかに超えて、脅威モデルを侵害する可能性がある。
種々の実施形態は、ホストハードウェア、または周辺制御バスもしくは同様のハードウェアデータ経路にプラグインされるカードといった特定のデバイスへのネイティブアクセスをユーザに提供することによって、ホストサーバといったリソースへの「部分的」または「実質的に」完全なアクセスを提供することができる。特定のレベルの性能が問題である、ある実施形態において、入力/出力メモリ管理装置(I/O MMU)といった技術は、周辺デバイスをゲストオペレーティングシステムに「割り当てる」ために使用することができ(例えば、指定I/O(IntelのVT−D)のための仮想化技術)、それらの周辺デバイスのみへのネイティブアクセスを効果的にゲストに与える。当業者には明らかであるはずであるように、ゲストオペレーティングシステム(OS)は、ホスティングプロバイダの管理制御下にない、BIOS、構成等を含む、OSもしくはハイパーバイザが依存する、何らかのハードウェアまたは機械状態への少なくとも部分的に仮想化されていないアクセスを有する、実行中のOSをホストする仮想機械といった、異なる実施形態における、異なるシステムを指すことができる。他の実施形態において、ゲストOSは、完全な仮想化を伴わずに実行するホスティングプロバイダの管理制御下にないOSを指す場合がある。一実施形態において、MMUは、直接メモリアクセス(DMA)可能なI/Oバス(例えば、PCIバス)を、ホスト上の主メモリへ論理的に接続することができ、ゲストから種々のPCIまたは同様のデバイスへの情報の流れを調整するように、物理アドレスへのI/Oデバイスのマッピングを管理することができる。これらのデバイスは、例えば、グラフィック処理装置(GPU)コプロセッサ、高性能NIC、ディスクコントローラ、または暗号カードもしくはハードウェアコードといった他の「ニッチ」共処理デバイスを含むことができる。一部の例において、仮想化または他のかかる技術は、ネイティブアクセスを、所与のホスト上の特定のデバイスに対して潜在的に利用可能にしながら、中央システムハードウェア(例えば、CPU、メモリ等)から、ゲストとホスト機械との間のあるレベルの分離を提供するために使用することができる。他の実施形態において、ネイティブアクセスは、特定のホストに含まれるか、またはそれに対して利用可能ないずれのハードウェアにも提供することができる。
特定のハードウェアへのネイティブアクセスを顧客に提供することに関する主な問題のうちの1つは、顧客が、ホストハードウェア上の特権的構成もしくはBIOS(基本I/Oシステム)設定、または他のファームウェア画像を修正する能力を有し得るということである。これらの変更は、物理的システムの再起動後も持続し得るため、ハードウェアが、その顧客がホストもしくはそのデバイス(複数を含む)へのアクセスを与えられる前のハードウェアと同じ状態に戻ることができない。例えば、Ring−1ハイパーバイザによって管理される仮想機械モニタ(VMM)に対する動的に構成可能な設定の場合、変更は、一般的に、起動後までは持続しないが、仮想化された環境(例えば、IOMMU技術をサポートするためのチップセット設定)における、ゲストオペレーティングシステムのインスタンス化後まで持続する可能性がある。顧客が本来不変であるべき設定またはファームウェアを修正するこの能力は、深刻なセキュリティへの影響を有し得る。例えば、悪意のあるソフトウェア(例えば、トロイの木馬またはウイルス)が、種々のデバイスのためのファームウェアに挿入される可能性がある。しかしながら、ファームウェア変更が、意図的に悪意のあるプログラミングを含まない場合でさえも、変更は、依然として、性能および/または互換性問題を引き起こすことによって、非意図的に損害を与える可能性がある。ファームウェアフラッシングは、潜在的に、ハードウェアを回復不可能なほどにまでに物理的に破壊する可能性がある(ハードウェアの「ブリッキング」としても知られる)。これらの課題のうちの少なくとも一部に、特に、マザーボードファームウェアまたはチップセット構成に対して、対処することができる、ある技術が開発されている。これらの技術には、例えば、信頼されるプラットフォームモジュール(Trusted Platform Module:TPM)、IntelからのLaGrande技術(LT)、メジャーブート技術、トラステッドブート技術、信頼性の動的ルート(Dynamic Root of Trust:DRTM)、および信頼性の静的ルート(Static Root of Trust:SRTM)技術が挙げられる。しかしながら、これらのソリューションのいずれも、デバイスファームウェア、ホスト全体、および他のかかるハードウェア態様に固有の種々の問題に対処することは知られていない。
種々の実施形態に従うシステムおよび方法は、クラウドまたは同様の電子環境における、ゲストによる、ファームウェア画像または構成情報へのアクセスおよび/またはそれらの操作を阻止および/または監視することができる。ある実施形態において、顧客には、数時間またはさらには数分といった、任意の所望の期間、ハードウェアリソースへの専用ゲストアクセスを提供することができる。図3は、一実施形態に従う、顧客にかかるネイティブアクセスを提供するために使用することができる、構成300の実施例を例解する。本実施例は、従来のPCIベースの技術を使用して、ホスト機械における周辺デバイスへのアクセスをユーザに提供することに関して述べられるが、これは、例に過ぎず、種々の実施形態の範囲内の手法を、かかる目的で現在使用されるか、またはその後開発される、任意の適切なハードウェア(異なるバス技術に基づく、または個々の構成要素または「チップ」内のより大きなもしくはより小さな程度のシステム統合を伴うものを含む)、ソフトウェア、およびプロトコルとともに使用することができるということが理解されるべきである。
本実施例の構成300は、各々が、一連のネットワークポート304を有することができる、サーバまたは同様のデバイスといった、一組のホストデバイス302を含む。これらのポートの一部は、各デバイスへの/からのネットワークトラフィックを処理およびルーティングすることが可能な少なくとも1つのネットワークスイッチ306へ、各ホストを接続する、「生産」ポートとして機能することができる。一部の実施形態において、ネットワークスイッチは、「スマート」ネットワークスイッチとすることができる一方、他の実施形態において、スイッチの第1のティアよりも、ネットワークにおけるより高いレベルで分離を行うことができる。データセンタの実施例において、例えば、サーバ308の各ラックに対して、1つのスマートスイッチが存在する場合がある。これらのネットワークポート304のうちの少なくとも1つは、ゲストオペレーティングシステムのためのトラフィックをホストすることができ、ここで、ゲストは、この生産ネットワークポートへのアクセスを有する、分配された、またはパーティションされたホストデバイス(例えば、サーバ)302における、少なくとも1つの中央処理装置(CPU)310「の上部で」効果的に動作している。ホストデバイス302はまた、少なくとも1つのコンソールポート312と、コンソールコントローラ314とを含むことができ、別個のコンソールネットワーク316に接続することができる。この「コンソールネットワーク」はまた、イーサネット(登録商標)技術といった、「生産ネットワーク」と同じネットワーク技術を使用して、実装することができる。一部の実施形態において、これらのポートのうちの少なくとも一部は、マージすることができるが、論理的には分離(例えば、同じ物理的ポート上で多重化)される。各ホストデバイスはまた、コンソールコントローラおよび/または主CPUによってアクセスすることができる、1つ以上の専用電源装置(PSU)318を有することができ、それにより、機械は、例えば、ホストCPUまたはネットワーク上のデバイスのいずれかを介して、電源をオフにすることができる。ラック内の全てのサーバのための電源は、ラック電力分散装置(PDU)320に接続することができ、これは、1つ以上のデータセンタPDU322へより高い電力ケーブルによって接続することができ、これらの各々は、複数のラックPDUをサポートすることができる。一部の場合において、ホスト302は、各デバイスに電力サイクルを行うように、リレーまたは他のかかる構成要素を用いて、ラックPDUからコンソールコントローラへラインを引くことによって、電源をオンおよびオフにすることができる。
少なくとも1つのルータ324は、ホストデバイスを、1つ以上のプロビジョニングシステム326へ接続することができ、スイッチおよび/またはルータは、これらのプロビジョニングシステムへのアクセスを管理することができる。一部の実施形態において、ラック内のネットワークトラフィックは、各ラックから出るケーブルの数を最小化するために、集約される。一部の実施形態において、起動前実行環境(PXE)といった能力は、電力をコンソールを使用してサイクルすることができ、かつ機械がPXEを起動する時、コードをネットワークポート上で実行することができるように、生産ネットワークポート304において、ホスト機械302上に存在する。PXEアクセスもまた、承認されている再起動のタイプに依存して、有効化または無効化され得る。例えば、再起動は、顧客が開始する再起動に対して、ホスト上のローカルイメージから可能であり得るが、PXEアクセスは、上流では無効化され得る。スイッチ306が、ホスト機械302をプロビジョニングシステムに接続するように構成される時、PXEは、デバイスをプロビジョニングシステムに接続し、機械を、例えば、RAM(ランダムアクセスメモリ)ディスクまたは記憶装置の他のブロックで起動することができ、これは、新しい顧客イメージのファームウェアフラッシングまたはプロビジョニングといった制御動作を有効にする。一実施形態における、特殊ドライバを有するRAMディスクは、そうでなければ、特定の機械上で起動することができない場合がある、信頼されない、または不明なイメージを起動および/または実行するために使用することができる。このように、プロビジョニングイメージは、ネットワーク上でPXEへ受信することができ、これは、プロビジョニングコードまたはファームウェアフラッシングコードを含有する。一度プロビジョニングが完了すると、承認された顧客ネットワーク328は、スイッチ306を介して、デバイス302と相互作用することができる。プロビジョニングおよび制御システムは、その経路の自動切り替えが、例えば、プロビジョニング事象および外部調整に基づくことができるため、ヒトが関与することなく、リアルタイムでスイッチを制御することができる。調整は、クラウドマネージャデータベースおよびシステム330、またはある行為を実施するように、プロビジョニングシステム(複数を含む)326、コンソールネットワーク316、およびラック構成要素に命令することができる、本明細書の他の個所で述べられるような、他のかかる制御プレーンまたは制御システムといった、外部システムによって、提供および/または管理することができる。クラウドマネージャ330は、リソース管理の種々の態様を実施するように、一実施形態においては、中央データベースと協働する、1つ以上のワークフローシステムを含むことができる。
異なる物理的サーバが、異なる時間に、顧客をホストするために使用され得る、クラウドコンピューティング環境といった環境において、経時的に変化する可能性があるリソース分配への依存を回避するように、ユーザまたは顧客ネットワークに対する、あるレベルの抽象を提供することが望ましい可能性がある。顧客ネットワークルータおよび顧客ネットワークファイアウォールといった、仮想ネットワーク機器提示もまた、オーバーレイネットワーキング技術を使用して、達成することができる。例えば、複数のコンピューティングノード間の顧客の仮想ローカルネットワークまたは他の仮想ネットワークは、複数のコンピューティングノードを分離する、1つ以上の中間物理的ネットワーク上で、オーバーレイネットワークを創出することによって、少なくとも一部の実施形態において、提供することができる。オーバーレイネットワークは、例えば、通信をカプセル化すること、および1つ以上の中間物理的ネットワークのネットワーキングプロトコルのために使用される、より大きな物理的ネットワークアドレス空間において、仮想ネットワークのための仮想ネットワークアドレス情報を埋め込むことによって、種々の実施形態において、種々の方法において実装することができる。
これは、顧客が、顧客ネットワークにおいてリソースをアドレスするための標準化されたアドレス空間を利用することを可能にする。標準化されたアドレス空間を利用することによって、顧客は、サブストレートネットワークが物理アドレス空間を制限することなく、共通のベースアドレス、サブネットワーク等を使用することができる、「仮想」またはオーバーレイネットワークを創出することができる。
仮想化を使用して、顧客ネットワークの一部であるとして、ユーザに対して表示され、機能するが、別個またはリモートクラウド、ネットワーク等において、実際のサーバまたは他の物理的リソースにマッピングされる、いくつかの仮想機械インスタンスを生成することができる。述べられるように、標準化されたアドレス空間の使用は、物理的サブストレートアドレスと、顧客アドレス空間のために使用される仮想オーバーレイアドレスとの間のマッピングの構築および維持を必要とし得る。一部の既存の手法において、ホストデバイス上で実行する中央処理装置は、顧客から受信される要求を、適切なリソースに方向付けることができるように、仮想および物理アドレスのマッピングを制御することができる。これは、例えば、データパケットカプセル化および脱カプセル化の形態を採ることができ、物理アドレスおよび/またはヘッダ情報は、パケットを、顧客ネットワーク上の送信元によって、仮想アドレスへアドレスすることができるが、クラウドまたはリモートネットワークインフラにある時、物理的ヘッダ情報を追加することによって、適切な物理アドレスへ適切にルーティングすることができるように、仮想アドレスおよび/またはヘッダ情報とともに、種々の時間に、「共存する」ことができる。
例えば、図4は、一実施形態に従い、仮想クラウド環境がホストされる、物理的サブストレートネットワーク内でルーティングされるために、顧客または「オーバーレイ」ネットワークから受信されるパケット400が、カプセル化される、実施例を例解する。本実施例において、受信された顧客パケット400は、仮想アドレス402(ここでは「IPv」と示される、顧客オーバーレイネットワークに関連する「仮想IPアドレス」等)、プロトコルヘッダ404(ここでは「TCPo」と示される、インターネットプロトコル群において見出されるような元の伝送制御プロトコルヘッダ等)、およびデータまたは「ペイロード」部分406という、3つの主要部分を含む。仮想IPアドレスは、顧客またはオーバーレイネットワークにのみ関連するアドレスとすることができる。意図される送信先ホストにパケットを適切にルーティングするために、このパケットは、サブストレートネットワークもしくはクラウド、または他のかかるリソース群内で、パケットをルーティングすることができる、「外部」データ構造またはフレームを含むように、カプセル化することができる。本実施例において、カプセル化プロセスは、「サブストレート」パケットまたはデータグラム410を生成するように示され、これは、元の顧客パケットのIPv、TCPo、およびペイロードを含むが、ここでは、物理的または「実」アドレス412(クラウドのサブストレートネットワーク内のIPアドレスもしくは「IPR」等)、ならびに制御ヘッダ414(パケットを処理および/もしくはルーティングするように、制御プレーンによって有用なプロトコルヘッダ等)を含む、そこに追加される追加の「ヘッダ」情報を有する。顧客ルーティング情報(例えば、402によって具現化される)は、顧客のオーバーレイネットワークにのみ意味があり、クラウドホストリソースが接続される物理的ネットワーキングインフラには意味がないため、この「実」情報のうちのいずれも追加しなければ、ルータ、およびクラウドインフラをホストする他のかかる構成要素は、一般的に、適切な送信先(複数を含む)にパケットを適切にルーティングすることができないであろう。一部の実施形態において、クラウド内のデバイスへ受信されているいずれの顧客パケットも、クラウド内で使用されるべきこの物理的ルーティング情報を含むように、カプセル化することができる。クラウド内でパケットを受信する第1のデバイスは、クラウドの「エッジ」上にあると見なすことができるため、これらのデバイスは、本明細書において「エッジ」デバイスと称される。「エッジ」デバイスは、本明細書において使用される際、クラウドの外側から情報のパケットを受信することが可能な、ならびに/またはクラウドの内側から情報のパケットを伝送することが可能な、ハードウェアおよび/もしくはソフトウェアにおける任意のデバイスを指すことができる。カプセル化プロセスは、一部の実施形態において、任意の適切なエッジデバイスにおいて行われ得る一方、他の実施形態において、エッジデバイスは、カプセル化構成要素、またはパケットをカプセル化もしくは脱カプセル化することが可能な他のデバイスに、パケットをルーティングすることができる。理解されるべきであるように、パケットが顧客ネットワークに伝送し戻されるか、またはそうでなければ、クラウドの外側に伝送される時、「脱カプセル化」プロセスを実行することができ、IPR412および制御ヘッダ414が除去され、パケットは、顧客ネットワークに対する仮想アドレス空間情報を使用して、ルーティングすることができる。簡略化の目的上、カプセル化のプロセスは、種々の実施形態に関して述べられるが、脱カプセル化プロセスはまた、種々の実施形態に従って、かかる構成要素およびプロセスを使用して、実施することができるということが理解されるべきである。
ある従来の手法は、ホストデバイスおよびサーバといったハードウェア上で、あるレベルのカプセル化を実施する。これらの手法において、中央プロセッサは、ネットワークポート、ネットワークインターフェースカード(NIC)、または同様のデバイスへ受信されるパケットをルーティングするために、カプセル化手順を実施することができる。カプセル化プロセスは、一般的に、ユーザには露出されない。一部の実施形態において、NICのためのドライバは、NICを介して、顧客ネットワークへの、またはそれからのパケットをルーティングする前に、プロセッサが、物理的サブストレートパケットを仮想オーバーレイパケットにマッピングする(逆も同様)ように、マッピング機構または分散マッピングサービスにアクセスすることができるように、プロセッサによって直接アクセス可能であろう。一部の場合において、マッピング情報は、集中型のサービスから、クラウドにわたって、各適切なノードに分散させることができる。
しかしながら、述べられるように、リソースプロバイダは、ホスト機械といったハードウェアリソースへの実質的に完全なネイティブアクセス、または「ベアメタル」アクセスを、ユーザまたは顧客に提供する能力を欲する場合がある。例えば、マッピングが、ホスト機械のCPU上で実行するアプリケーションによって管理される場合、そのマッピングは、潜在的に、ホスト機械上で実行する、ユーザまたはゲストオペレーティングシステム(OS)によって、アクセスすることができる。かかるアクセスは、潜在的に、マッピングサービスを損ない得、ゲストオペレーティングシステムが、パケットをリダイレクトする、パケットを拒絶する、またはそうでなければ、クラウドネットワークにおけるパケットの処理に影響を及ぼすことを可能にし得る。さらに、かかる機能性は、パケットを、クラウドの外側の意図されない場所へ送信することができるように、損なわれる可能性がある。他の潜在的な問題には、ホストが、異なるホストまたは場所から発信するように見えるパケットを送信する、「パケットスプーフィング」が含まれる。これは、しばしば、どこから敵対攻撃が来ているかを難読化するために使用され、また、標準的なネットワークプロトコルの一部である、確認パケットが、伝送等を開始していないホストに送信される、「ACKベース」のサービス妨害(Denial of Service:DoS)攻撃の基本でもあり得る。種々の他の潜在的な問題が、ゲストOSまたはCPUが、潜在的に、マッピングおよび/またはカプセル化機能性へのアクセスを有する時に生じる。
したがって、種々の実施形態に従うシステムおよび方法は、プロビジョニングされたホスト機械または操作の他のかかる潜在的な送信元上の顧客、ゲストOS、CPUに露出されない構成要素を使用して、カプセル化、脱カプセル化、およびステートフルなファイアウォール動作といった動作を実施しつつ、種々のユーザによる、リソースへの実質的な「ベアメタル」アクセスを提供することができる。図5は、種々の実施形態に従う、パケット処理および他の安全なネットワーキング機能を実施するために使用することができる、構成500の実施例を例解する。本実施例において、パケットは、例えば、パケットが、物理的相互接続伝送のためにフレーム化される(例えば、イーサネットフレーム化)直前に、ここではネットワークカードレベルにおいて、顧客アクセス可能なホストリソースの「上流」でカプセル化される。本実施例において、オフロードデバイス506は、クラウドマネージャ504およびマッピングサービス502といった構成要素と通信することができる、外部ポート508を有するということを見ることができる。外部ポート508は、これらの構成要素が、ホスト機械516上のCPU514、またはホスト機械上でプロビジョニングされる任意のゲストイメージ518もしくはゲストOSから独立して、オフロードデバイスと通信することを可能にすることができる。かかる手法を使用して、クラウドへ、またはそれから伝送されるいずれのパケットも、マッピングが、ユーザにアクセス可能ではないか、またはユーザによって修正可能ではないように、ゲストアクセス可能な部分から独立して処理することができる。本実施例において、オフロードデバイスは、メモリ510と、少なくとも基本的なマッピング、カプセル化、脱カプセル化、および/または同様のかかる機能を実施することが可能な処理デバイス512とを有することができる。これは、概して、本明細書において「オフロードデバイスベースの」カプセル化と称されるが、他の周辺デバイスまたはハードウェア構成要素が、同様の機能性を実施することができるということ、および機能性は、カプセル化に限定されず、脱カプセル化、ファイアウォール等といった他の機能も含むことができるということが理解されるべきである。オフロードデバイスは、ユーザまたはゲストオペレーティングシステムに露出されない、ホスト機械内の埋め込みシステムとして、機能することができる。ユーザが、オフロードデバイスの機能性のうちの少なくとも一部へのネイティブアクセスを欲する可能性がある場合、オフロードデバイスは、一部の機能性のみにアクセスすることができるように、ゲストOSに対してマッピングされる、あるメモリ部分のみを有することができる。一部の実施形態において、これは、ゲストOSが、オフロードデバイスの部分を発見および/または利用することができるが、カプセル化といった安全な行為に対して利用される部分にはアクセスすることができない、仮想オフロードデバイスイメージの形態を採ることができる。
オフロードデバイスベースのカプセル化機能性は、ホスト単位で、あるいは、少なくとも、パケットを受信および/もしくは伝送することが可能な、ならびに/またはそれにプロビジョニングされる顧客イメージを有することが可能な、それらのホスト機械に対して、提供することができる。かかる場合において、クラウドマネージャ504、または同様の構成要素もしくはシステムは、種々のホストおよび/またはノードへのマッピング情報、ならびにかかるプロセスに対して有用な他のかかる態様および構成情報の分散を管理することができる。かかる場合において、クラウドマネージャは、構成情報、ファームウェア、またはカプセル化および同様のかかる行為を実施するために有用な他の情報を更新するように、外部ポート508を介して、オフロードデバイス506と通信することができる。外部チャネルを介して構成情報を更新するためのプロセスは、参照することによって、本明細書に組み込まれる、2009年9月4日出願の同時係属の米国特許出願第12/554,690号[代理人整理番号第026014−010700US号]において開示される。かかる手法を使用して、オフロードデバイスのためのファームウェアおよび/または構成情報は、所望の機能性を実施するように、ならびにマッピングサービス502、または必要とされる他の適切な構成要素(複数を含む)と通信するように、更新することができる。構成は、例えば、大きいペイロードを送信する、またはそうでなければオフロードデバイスの機能性を調節するように、クラウドマネージャおよび/またはマッピングシステム(複数を含む)によって管理することができるように、定期的に更新することができる。
一部の実施形態において、カプセル化および同様のプロセスは、ホスト機械516のオフロードデバイス506および/またはネットワークポート520への、およびそれらからのメッセージをルーティングするように構成される、スマートスイッチ520といった、ユーザに露出されない、他の構成要素において実行することができる。かかるスイッチは、パケットのカプセル化といった動作を実施するように動作可能なプロセッサ522を含むことができ、それにより、スイッチは、パケットを処理し、それを物理的および/または仮想アドレス空間における適切なアドレスへルーティングすることができる。かかる場合において、ホスト機械は、(アドレス空間の観点から)クラウド、または信頼される環境の外側にあると見なされ得、それにより、スイッチは、エッジデバイスとして機能し、ホスト機械(およびクライアントネットワーク)の仮想アドレス空間から、クラウドにおけるリソースの物理アドレス空間へ受信されるパケットを修正することができる。種々の実施形態の範囲内のルータまたは専用エッジデバイスといった、種々の他の構成要素も使用することができる。
多くの従来のシステムにおける制限の1つは、物理的伝送経路または「ワイヤ」が、1.5KBまたは9KBパケットといった、比較的小さい情報のパケットのみを可能にすることができるということである。より小さいパケットの使用は、厳密には、物理的考慮ではなく、歴史的およびプロトコル定義の理由にも起因する。例えば、ほとんどまたは全てのリンクが切り替わり、伝送速度が高い、現代のネットワークにおいて、この制限は、衝突を耐えられないほど増加させることなく、数桁増加され得る。オフロードデバイスといった物理的ネットワークインターフェースが、1.5KBもしくは9KBのパケットを伝送または受信することができるのみである場合でさえ、少なくとも一部の実施形態において、より大きいパケットを、DOM−UからDOM−0ネットワークスタックへ、およびオフロードデバイス上へ伝送し、かつオフロードデバイスに、より大きいパケットを複数の1.5KBもしくは9KBのパケットにセグメント化させることが望ましい。多くの商品オフロードデバイスは、この要件に対処するように、セグメント化オフロードといった高度な機能性をサポートする。セグメント化オフロード能力を有するオフロードデバイスは、比較的大きいパケットを受信および/またはバッファするように、ならびにそれらのより大きなパケットを、1.5KB、9KB、もしくは他のかかるサイズ制限に準拠する、より小さいパケットもしくはイーサネットフレームにセグメント化またはフレーム化するように、構成することができる。これらのパケットを受信するデバイスは、複数のより小さいパケットに基づいて、より大きなパケットを再組み立てするように構成することができる。
多くのオフロードデバイスは、高速ネットワーキングを支援することができる、TCPセグメント化オフロードといった、高度な特性を提供する。種々の実施形態に従うシステムおよび方法は、顧客が、顧客アドレス空間とプロバイダネットワークアドレス空間との間に位置するホストデバイスへのアクセスを有するといった、「仮想」ネットワーキングを提供するように、かかる特性を活用することができる。典型的に、セグメント化オフロード機能性は、TCPといった公知のレベル4(「L4」)プロトコルのみで作用する。パケットが、図4に関して前項において説明されるもののようにカプセル化される時、L4プロトコルは、TCP以外の何かに変更される。このため、オフロードデバイス上のセグメント化オフロード特性は、かかるカプセル化されたパケットで作用することができない。物理的ハードウェア(「レベル1」)と、そのハードウェア上で実行されるアプリケーション(「レベル7」)との間の層を説明するために当該技術分野において使用されるように、レベル4は、「プロトコル」レベルを指し、インターネットプロトコルの場合、伝送制御プロトコル(TCP)およびユーザデータグラムプロトコル(UDP)といったプロトコルを指すことができる。受信サイドのTCPセグメント処理は、TCPセグメントペイロードが、完全に顧客データ(または他のかかるデータ)であると仮定する。したがって、メタデータの追加は、受信サイドが、カプセル化/脱カプセル化メタデータを有するパケットペイロードを破損することにつながるため、伝送サイド上では、カプセル化関連のメタデータは、元のL4ヘッダを保持するために、L4ペイロードへ追加することができない。
既存のカプセル化および/またはオーバーレイネットワーク実装に伴う別の潜在的な問題は、ヘッダが、しばしば、ルーティングおよび負荷均衡の目的で、従来のハードウェアデバイスによって利用される、物理的ポート情報を含まないということである。
種々の実施形態は、偽装の、または一部の場合において、元のポート番号を有する偽装TCPヘッダを利用することができ、ヘッダが、確立されたプロトコル規則(例えば、TCPオプション)に従って拡張され、カプセル化/脱カプセル化情報は、プロトコル拡張において渡される。例えば、「偽装」TCPヘッダは、任意の適切なTCP関連の情報に加えて、任意の慣例に応じたポート情報を含むことができる。多くの従来のハードウェアデバイスは、少なくとも部分的に、ヘッダにおいて指定されるポートに基づいて、負荷分散決定を下すため、この偽装ポート情報を含むことによって、従来のルータおよび他のかかるデバイスは、改善された負荷分散を得ることができる。ルータまたはオフロードデバイスは、例えば、IPアドレスおよびTCP情報を見ることができ、かつパケットを標準的なパケットとして処理することができる。かかる手法はまた、主に、従来のハードウェアデバイスおよびネットワークを使用するソフトウェアにおいて実装することができるため、有利であり得る。
レベル4ペイロード(上で述べられるように、ネットワークスタックにおいて)を変更しない、プロトコルもまた、使用することができる。ユーザから受信される元のパケットは、仮想IPアドレス(ネットワークスタックにおけるレベル3)、および元のTCPヘッダ(レベル4)とともに、ペイロード(ここでは、レベル4ペイロード)を含むことができる。先で述べられるカプセル化手法を使用して、制御ホストは、物理的または安全なネットワークにおいて、パケット(もしくはフレーム)をルーティングする上で使用するために、IPRといった実アドレス、偽装TCPヘッダ、TCPF(もしくは、例えば、UDPF)を取り付けることができる。カプセル化後のパケットに関して、元の仮想IPアドレス、TCP(もしくはUDP等)、およびペイロード情報は、ここで、効果的に、レベル4ペイロードを形成し、IPRは、レベル3アドレスを形成し、TCPFは、レベル4プロトコルヘッダを形成する。パケットは、元のまたは偽装ポート番号を有するため、かかる形式はまた、先で言及されるルータECMPハッシング問題といった問題を解決することができる。しかしながら、NICは、ここでレベル4ペイロード内に含有される情報を適切に解釈することができないため、従来のNICまたは同様のデバイスは、カプセル化されたフレームに従って、64Kまたは同様のパケットをどのように適切に分割するかが分からない。また、述べられるように、レベル4ペイロードは、IPVおよびTCPO情報を含むことによって、変更されている。
代わりに、種々の実施形態は、カプセル化されたパケットを処理するように、わずかに修正されたプロトコル形式を活用することができる。従来のプロトコルは、TCPヘッダの終端に余分な空間を提供し、これは、典型的に、「TCPオプション」または「TCPアドオン」と称されるものを可能にする。これらのTCPオプションは、追加の特性を含むように、TCPプロトコルが拡張されることを可能にする。一部の実施形態において、TCPパケットは、効果的に、追加の情報をTCPオプションとして宣言しながら、約24バイト拡張することができる。理解されるべきであるように、パケットは、異なる実施形態および/または実装において、異なる量、拡張することができ、24バイトの拡張は、一例に過ぎない。このため、偽装TCPヘッダは、元のTCP情報に加え、制御ヘッダ情報を含むことができる。仮想IPアドレスに関する情報もまた、このTCPオプション空間に含むことができる。このため、ペイロードまたはデータ部分が変更しないように、ペイロードのカプセル化および修正の間、実ヘッダを追加する代わりに、IPVおよびTCPO情報を、偽装TCPのTCPオプションセクションに含むことができる。
仮想化された環境に関して、パケット情報を管理するための例示的なプロセスにおいて、仮想アドレス情報を含むパケットが受信される。ホストデバイス、またはユーザが実質的に完全にアクセスを有する他の機械へ受信される場合、パケットは、ユーザが、ルーティングおよび他のかかる処理を修正することができないように、ユーザが制御可能なハードウェアの上流にある1つ以上のデバイスまたは構成要素へ方向付けられる。ゲストからDOM−0へといった、構成要素間で伝送されるパケットは、一部の実施形態において、64KBまでのサイズとなり得、このため、セグメント化を必要とし得る。パケットに対するマッピング情報は、例えば、仮想アドレス情報に対応する物理アドレス情報を判断するように、マッピングサービスにコンタクトを取ることによって、判断することができる。アドレス情報は、受信されたメッセージ、例えば、ヘッダ(IPRセクション等)に追加することができ、ここで、アドレス情報は、パケットが方向付けられるべき物理アドレスに対応する。仮想アドレス情報は、パケットを依然としてルーティングする、セグメント化する、および別様に商品ハードウェアによって処理することができるように、ペイロードを修正することなく、パケットに対して、TCPヘッダといったプロトコルヘッダに追加することができる。パケットは、TCPセグメント化オフロード機能性を使用してパケットをセグメント化し、かつ結果としてのパケットをワイヤへ、および最終送信先へ伝送することができる、オフロードデバイスへ伝送される。明らかであるはずであるように、同様の機能性は、物理アドレス空間から受信されるパケットを処理するために使用することができ、マッピング情報は、パケットに対して判断され、仮想アドレス情報は、パケットに追加される。仮想マッピング情報が、ポートを指定しない場合、例えば、負荷均衡化または同様の機能性を可能にするように、パケットが仮想送信先への途中で処理されることを可能にする、「偽装」ポートを使用することができる。
仮想化された環境に関して、パケット情報を管理するための同様のプロセスの実施例において、イーサネットフレームは、物理的ネットワークインターフェース(例えば、NIC)へ受信され、ここで、フレームは、物理アドレス情報を含む。IPRおよびTCPFといった情報を有するセグメントは、一部の実施形態において、1つ以上のより大きなセグメントを生成するように、合体させることができ、これは、性能を改善することができる。パケット形式は、全てのTCP形式規則に従っており、かつTCPペイロードは、顧客パケットのペイロードと全く同じであるため、これは、受信サイド合体(Receive Side Coalescing)をサポートする商品NICによって行うこともできる。オフロードデバイス(または他のかかるデバイス)は、ユーザが、ルーティングおよび他のかかる処理を修正することができないように、ユーザが制御可能なハードウェアの上流にある。仮想アドレス情報は、例えば、ヘッダおよびフッタフレーム化情報を除去した後に、ペイロードに対して、TCPヘッダといったプロトコルヘッダから抽出することができる。仮想アドレス情報は、受信されたイーサネットフレームから抽出される、データパケットに対するヘッダを組み立てるために使用することができる。次いで、パケットは、例えば、仮想アドレス空間内の送信先へパケットを伝送することによって、処理することができる。明らかであるはずであるように、同様の機能性は、仮想アドレス空間から受信されるイーサネットフレームを処理するために使用することができ、仮想アドレス情報は、パケットに対するヘッダから抽出される。
しかしながら、受信される各パケットが1.5Kであり、24バイトの情報がこれらのパケットの各々に追加される場合、ここで、パケットは、各々が、1.5Kの伝送制限を超え、各々が、2つのパケットに分割されることを必要とし、これは、望ましくない量のオーバーヘッドおよび追加のトラフィックにつながる可能性があるため、単純にTCPヘッダを拡張することは、一部の実施形態において、望ましくない場合がある。このため、少なくとも一部の実施形態において、オーバーヘッドを著しく増加させないながらも、この追加の情報を利用することが、望ましい可能性がある。
種々の実施形態は、IPVおよびTCPO情報といった情報が、セグメント化時には、各パケットに対して必要とされないが、セグメント結合化時に判断され得るという事実を活用する。このため、一手法は、種々の実施形態において、IPVおよびTCPO情報等に関する追加の情報(一実施例において、約24バイト)を採り、一実施形態においては、約1〜5つの情報のインスタンスである、コード化された情報(一実施例において、約120バイト)を作成することであるが、例えば、ハッシング技術に依存し得るように、他の長さのコード化された情報も使用することができる。コード化された情報は、ハッシングまたは同様の機構を使用して再構築することができるため、元の情報は、セグメント化されたパケットの1つ以上のインスタンスから取得され得る、ハッシュ化されたメタデータの少なくとも24バイトから再構築することができる。このため、例えば、各パケットセグメントに24バイトを追加する代わりに、追加の120バイト程度を、適切な数のピースに分割することができ、例えば、データがセグメント化される境界において、ペイロードに沿って、戦略的に位置付けることができる。例えば、オフロードデバイスまたは同様のデバイスは、データが、ある場所(追加の50バイトを含む)において、サイズに基づいて、自動的にセグメント化されるということを知っている。これらのセグメント化場所が分かっているため、オフロードデバイスは、1.5Kパケットの少なくとも5つ(または適切なサイズの任意の他の適切な数)が、その中に記憶されるIPVおよびTCPOに対する情報を有するが、各パケットは、全ての10バイトの追加の情報は含まないように、追加の情報のインスタンスを、これらのセグメントラインで(またはそうでなければ異なるセグメント内に)挿入することができる。
パケットが受信される時、セグメント結合化プロセスを、従来のシステムと同様に行うことができる。1.5Kのセグメントが、64Kのペイロードに組み立てられる時、またはセグメント結合化プロセス中、情報の一部分は、IPVおよびTCPO情報等を再構築するために使用することができる。例えば、ハッシングプロセスを使用する、および種々のパケット間で情報を分散することの利点は、1.5Kのパケットの一部が損失した場合でさえも、情報の一部分を有する少なくとも2つのセグメントが受信される限り、IPVおよびTCPO情報を再構築することができるということである。ペイロード全体は、再構築することができない可能性があるが、少なくともヘッダ情報は再構築することができる。さらに、受信デバイスは、ヘッダ情報を再構築することができるため、単純に、受信されなかったそれらの1.5Kのセグメント(例えば、イーサネットフレーム)を要求することができ、したがって、ペイロード全体の再送を要求する必要はない。かかる手法は、性能における大きい変動をもたらし得る、大きいパケットの再送の必要性がしばしば存在しないため、はるかに低いジッタ分散を有することができる。例えば、ビデオトラフィックの場合、データ損失が著しくない限り、損失したトラフィックは、無視することができ、このため、少なくとも一部の実施形態において、要求される必要がない。これは、部分的なセグメントを無事に受信することができるという利点である。
仮想化された環境において、パケットを処理するための例示的なプロセスにおいて、パケットは、顧客アドレス空間から受信され、これは、仮想アドレス情報を含む。述べられるように、ユーザから受信される最初のパケットは、IPVおよびTCPO情報を伴う64Kのパケットであり得る。パケットは、顧客がパーティションしたデバイスのユーザには少なくとも部分的にアクセス不可能である、制御ホストまたは別のかかる安全な構成要素へ受信されるか、または方向付けることができる。仮想アドレス情報は、例えば、上で述べられるように、マッピングサービスにコンタクトを取ることによって、安全な構成要素を使用して、実アドレスに翻訳することができる。所望される場合、TCPヘッダ(または他のプロトコルヘッダ)を更新することができるが、IPVおよびTCPO情報といった追加の情報を、代わりに、データに挿入することができる。IPVおよびTCPO情報をデータに追加する時、この「仮想化」情報をハッシュすることができるか、または別様に、複数の部分に分割することができる。既に判断されていない場合、安全なデバイスは、伝送経路に対するセグメント化制限を発見することができ、ユーザペイロードのセグメントに対する境界を判断することができる。仮想化情報の一部分は、ペイロードの中央パケット内のセグメント化境界に隣接して配置することができるか、またはそれに対して位置付けることができる。次いで、「新しい」パケットまたはフレームは、パケットを、1.5Kのパケットといった判断されたサイズの一組のパケットに自動的にセグメント化することができる、例えば、オフロードデバイスまたは他のかかる安全なデバイスに渡すことができ、セグメントの数は、全体的なパケットのサイズに少なくとも部分的に依存する。IPおよびTCPヘッダは、オフロードデバイスまたは他のかかるデバイスのセグメント化オフロードプロセスを使用して、サイズの全体的な変更を補うように、潜在的に一部の小さい変更を伴って、各パケットに関して複製することができる。次いで、パケットを、送信先に伝送することができる。
同様のプロセスを、仮想化された環境に対するパケットを処理するために使用することができ、一組のイーサネットフレームが受信され、イーサネットフレームのうちの少なくとも一部は、ハッシュされているか、または別様に複数の部分に分割されている「仮想化」情報を含む。仮想化情報は、関連付けられるペイロードにおいて、仮想化情報の一部分を含む、各フレームの下部のセグメントから抽出することができる。仮想化情報(例えば、ヘッダデータ)は、仮想化情報を含む十分な数のフレームが受信される限り、再組み立てされ、受信されたパケットは、可能な程度にセグメント結合することができる。全てのフレームが受信されるわけではないが、ヘッダデータを再組み立てすることができた場合、欠落したセグメントのみに対する要求を送信することができる。
パケットの少なくとも大部分が、最終的に、送信先、または送信先への経路に沿ったデバイスで受信される時、デバイスは、完全な64Kまたは他のパケットでない場合、これらのパケットを少なくとも1つのより大きなセグメントへのセグメント結合または再組み立てを試行することができる。ペイロードにおいて追加のヘッダ情報を有する、2つのパケット(または必要とされるパケットの数が特定のハッシング技術によって判断される場合、セグメント化の間に、元々生成されたものよりも少ない数のパケット)が受信される限り、少なくとも一部の実施形態において、これらのパケットは、ヘッダデータを再構築するため、およびパケットをセグメント結合するために使用することができ、実アドレスおよびプロトコル情報を、仮想またはクライアントネットワークに関する情報と置換し、それにより、より大きい組み立てられたセグメントを、クライアントまたは他の送信先に渡すことができる。一部の実施形態において、セグメント結合化は、オフロードデバイスまたは同様のデバイス上で行うことができる一方、他の実施形態において、セグメント結合化は、受信デバイス上のゲストオペレーティングシステム等を使用して行うことができる。さらに、上のプロセスの種々のステップは、任意の適切な順序で、または並行して、実施することができ、かつより少ない、追加の、または代替的なステップが、種々の実施形態の範囲内において可能である。
仮想化を使用して、顧客ネットワークの一部であるとして、ユーザに対して表示され、機能するが、別個またはリモートのクラウド、ネットワーク等において、実際のサーバまたは他の物理的リソースにマッピングされる、いくつかの仮想機械インスタンスを生成することができる。述べられるように、標準化されたアドレス空間の使用は、物理的サブストレートアドレスと、顧客アドレス空間のために使用される仮想オーバーレイアドレスとの間のマッピングの構築および維持を必要とし得る。一部の既存の手法において、ホストデバイス上で実行する中央処理装置は、顧客から受信される要求を、適切なリソースに方向付けることができるように、仮想および物理アドレスのマッピングを制御することができる。これは、例えば、データパケットカプセル化および脱カプセル化の形態を採ることができ、物理アドレスおよび/またはヘッダ情報は、パケットを、顧客ネットワーク上の送信元によって、仮想アドレスへアドレスすることができるが、適切な物理アドレスへ適切にルーティングすることができるように、仮想アドレスおよび/またはヘッダ情報とともに、種々の時間に、「共存」することができる。
フレームワークは、従来のまたは他のネットワーキング構成要素が、多様な異なる標準的な、および独自のプロトコルといった複数のプロトコルをサポートすることを可能にすることができる、商品NICデバイスといった、これらの構成要素によって実装することができる。次いで、これらの商品デバイスは、顧客固有のパケット形式から独立して、強化された性能、およびこれらのデバイスの従来のプロトコルに対して使用される他の利点を提供することができる。例えば、NICベンダは、NICが、いかなるカスタム化または特別なハードウェアに対する必要性も伴わずに、任意の準拠したプロトコルを用いて顧客によって使用されることを可能にする、フレームワークを実装することができる。
一実施例において、ネットワーク環境におけるオフロードデバイスは、TCPセグメントを処理することができる。顧客ネットワークは、オフロードデバイスは、例えば、約8Kまたは9Kのサイズ(ネットワーク構成および他のかかる問題に依存して)のネットワークパケットを伝送することができるのみである場合があるため、典型的に、オフロードデバイスからネットワークへ渡すことができないサイズ(例えば、64K)のパケットを利用する場合がある。上で述べられるように、より大きなパケットが、オフロードデバイスにおいて、適切なサイズ(例えば、1.5Kまたは9K等)の複数のイーサネットフレームにセグメント化されることを可能にする技術が存在する。例えば、TCPセグメント化オフロード(TCP Segmentation Offload:TSO)および受信サイド合体(Receive Side Coalescing:RSC)は、ホストが、より大きいTCPセグメント(例えば、64Kのサイズ)に対処することを可能にすることによって、ネットワークスループット性能を増加させるように、それぞれ、進出および進入エンドポイント上で使用することができる。TSOは、ネットワーク上での伝送のために、TCPパケットを適切なサイズのセグメントにセグメント化するための技術であり、RSCは、これらのセグメントが、ネットワークの他方のサイドで再組み立てされることを可能にする。しかしながら、一般的に、TSOおよびRSCといった技術は、図4(b)に例解される追加のヘッダ情報といった独自のプロトコル情報を伴って、カプセル化されるパケットに対してサポートされていない。例えば、独自の形式を使用してカプセル化されるパケットは、典型的に、TCPパケットよりも大きく、オフロードデバイスが、これらのカプセル化されたパケットを認識しないように、予想されるTCPヘッダ情報を有しない。
しかしながら、適切なフレームワークを実装することによって、オフロードデバイスまたは他の適切なネットワーク構成要素は、カプセル化されたパケットを、構成要素がTCPパケットとして理解することができる何かにマッピングするための能力および仕様を有することができる。例えば、一度、オフロードデバイスが、パケットをTCPパケットとして認識すると、オフロードデバイスは、パケットをセグメント化し、適切なヘッダを追加する、および/またはオフロードデバイスが、典型的に、従来のTCPパケットに対して行うであろう他のことのいずれかを行うことができる。多様な異なるプロトコルのうちのいずれかでカプセル化されるパケットに関してさえも、TSOおよびRSCは、有意な改善(例えば、最大80%の性能増強)、ならびに他の十分に確立された利点を提供することができる。さらに、フレームワークを実装することによって、オフロードデバイスは、異なるプロトコルとともに使用することができるだけでなく、顧客が、顧客の既存のハードウェアを購入、アップグレード、または修正することを必要とせずに、プロトコルをアップグレードまたは変更することも可能にすることができる。
不明瞭なフィールドは、GREまたは他のかかるプロトコルといった、顧客ネットワークの特定の形式またはプロトコルによって利用されるいかなる情報も含むように、カプセル化されたパケットとともに使用することができる。少なくとも一部の実施形態における、不明瞭なフィールドは、TCPもしくはUDPベースのヘッダ、または他のかかるプロトコルヘッダである。一実施例において、不明瞭なヘッダは、不明瞭なフィールドにおいて、指定されたオフセットに、セグメントまたはパケットの特定の形式を示すまたは識別する、第1の組の情報を有する。例えば、情報は、特定の形式に対応する値を含む、2バイトフィールドであり得る。ネットワークハードウェアは、第1の組の情報の値から、パケットの適切な形式を判断するために、第1のオフセット値および対応する形式のマッピングからの値を含有するか、それへのアクセスを有することができる。
本実施例において、不明瞭なフィールドはまた、不明瞭なフィールドにおいて、指定された第2のオフセットに、情報の第2のフィールドを含む。この第2のフィールドは、2バイトといった適切な長さであり得、セグメント結合化に有用であり得るような、フロー識別子、またはトラフィックの特定のフローに対する識別子を指定する値を含むことができる。一部の実施形態において、このフィールドは、特定の形式パケット上でTSOまたはRSC動作を実施する時、一般的な5タプルとともに、一意的なTCPフロー(またはUDPフローといった他のフロー)を識別することができる。
これらの実施例は、例えば、ヘッダが、パケットが属する仮想ネットワーク、パケットが発信される仮想機械、および/またはパケットが向かっている仮想機械といった情報を有する、特定のプロトコルに対する環境に対応することができる。この情報は、共通のTCPストリーム内のパケット間で変化しない。例えば、仮想化されたネットワーク環境においては、2つの異なる仮想ネットワークに属する、同じ物理的ホスト上に、2つの異なる仮想機械が存在する可能性があるため、スロットID、または仮想機械識別子は、接続情報のために使用することができる。それらの仮想機械は、全く同じIPアドレスを有する可能性があり、かつ潜在的に、偶然同じポートおよびIPアドレスを有する誰かと通信する可能性がある。TCPの観点から、5タプルは、全く同じであり得る。送信元IPおよび送信先IP、送信元ポートおよび標的ポート等といった他の情報もまた、全く同じであり得る。このため、TCPの観点から、接続は、同じ接続として考えられるが、実際には、2つの異なるプライベートネットワークである可能性がある。スロットIDの使用は、これらの状況を一意的に分離することができる。他のプロトコルに関して、明らかであるはずであるように、仮想機械識別子以外の値を使用することができる。
一実施例において、カプセル化されたパケットは、オフロードデバイスへ受信される。オフロードデバイスは、フレームワークの仕様を使用して、パケットがカプセル化され、従来のTCPまたはUDPパケットとは異なって処理される必要があるということを識別するように、パケットを分析することができる。一実施例において、カプセル化されたパケットは、内部および外部IPヘッダを含む。カプセル化されたパケットはまた、不明瞭なフィールド(ペイロードの一部として表示され得る)を有し、これは、プロトコル固有の情報に対して使用することができる。不明瞭なフィールドの長さ、およびその中に含有される情報は、実施形態間で変化し得る。カプセル化されているとしてパケットを識別するために、外部IPヘッダは、事前構成されたプロトコル情報を含有することができる。さらに、パケットは、不明瞭なフィールド内に少なくとも1つの2バイトフィールドを含有することができる(しかしながら、他のサイズおよび場所も、他の実施形態の範囲内において使用することができる)。2バイトフィールドは、不明瞭なフィールドの開始から事前構成された距離であり得、2バイトフィールドの値もまた、事前構成され得る。外部IPヘッダ内のプロトコル情報、および不明瞭なフィールドの2バイトフィールド内の形式情報の組み合わせは、オフロードデバイスまたは別のネットワーク構成要素が、パケットがカプセル化されること、ならびにカプセル化の形式を認識することを可能にすることができる。オフロードデバイスは、本来、不明瞭なヘッダ内の他の情報を見ないため、不明瞭なヘッダは、オフロードデバイスによるパケットの処理に影響を及ぼすことなく、任意の特定のプロトコルに固有の情報を含むことができる。不明瞭なヘッダ内の2バイトは、パケットの特定の形式を識別することができ、これは、パケットを処理するための規則または方針を判断することを支援することができる。外部IPヘッダおよび不明瞭なフィールド内のこの情報に基づいて、オフロードデバイスは、従来の手法を使用してパケットを処理することができるかどうか、またはパケットがカプセル化されたパケットであるかどうか、およびフレームワークによって指定される特別な規則に従って処理されるべきかどうかを判断するように、各受信されたパケットを分析することができる。
例えば、TSOプロセスの間、進出(例えば、発信)TCPセグメントのセグメント化は、内部IPヘッダにおいて開始する、TCPセグメントデータ上で、標準的なアルゴリズムを使用して実施することができる。大きいカプセル化されたパケットは、セグメントがネットワーク上で伝送されることを可能にするサイズのいくつかのパケットに、セグメント化される。フレームワークがステートレストンネリングとも協働するために、不明瞭なフィールドは、得られたセグメント化されたTCP/IPパケットの各々に、逐語的にコピーされ、内部および外部IPヘッダ間に配置される。外部IPヘッダは、各得られたパケットにコピーされ、「長さ」情報への変更といった適切な調節は、内部IPヘッダに適用される同じロジックを使用して行うことができる。さらに、IPヘッダに対するチェックサムとともに、IPヘッダの一部である、IP IDを生成することができる。
同様に、RSCプロセスの間、特別なプロトコル形式情報を有するパケットまたはセグメントのTCPフローは、TCPポート、内部IPアドレス、内部IPプロトコルフィールド、および内部L4ポート(例えば、TCPポートまたはUDPポート)の一般的な5タプル、ならびに不明瞭なフィールドの開始から事前構成されたオフセットにおける追加の2バイトによって、定義される。特別な形式パケットのTCPフローは、一般的なパケットのフローと重複しないということが理解されるべきである。さらに、「パケット」といった用語は、全体を通して、解説の簡略化の目的で使用されるが、他の場所またはインスタンスにおいて、プロセスは、より一般的にセグメントまたはフレームと称されるオブジェクトを含み、単一のオブジェクトに対する共通の名称は、本明細書において述べられるプロセスにおける種々の点において、これらと他の用語との間で変化する場合があるということが理解されるべきである。
RSCは、内部IPヘッダで開始するTCPパケットデータ上で、従来のアルゴリズムを使用して実施される。関連TCPパケットを合体させる時、第1のTCPパケットからの不明瞭なフィールドは、内部IPヘッダと外部IPヘッダとの間の得られたTCPセグメントへコピーすることができる。得られたTCPセグメントの外部IPヘッダは、内部IPヘッダが合体されるのと同じように合体することができる。RSCに対して不適格であることを進入パケットに強制する、IPフラグ上の制限(例えば、「Don’t fragment」または「More bit」)が存在する場合、制限は、内部および外部IPヘッダの両方において、IPフラグに適用され得る。
RSCは、パケットが受信されている各接続に対するハッシュバケット(または他のキューもしくは一時的な記憶場所)を維持することができる。TCPパケットが受信される時、次いで、受信デバイスは、IPおよびTCP情報といった情報、ならびに外部TCPヘッダ内のシーケンス番号ビットを使用して、パケットが属する接続を判断することができ、かつ適切なハッシュバケットに対するパケットをキューに入れることができる。既にパケットが存在するバケットに関して、ネットワーク構成要素は、完全なパケットが合体されるまで、セグメント化されたパケットのマージを試行することができる。サイズがある閾値に到達する、またはパケットが、特定の長さもしくは範囲の時間、キューに入れられる時、合体されたパケットをオペレーティングシステム上で送信するといった、従来の基準を適用することができる。
しかしながら、少なくとも一部の実施形態において、接続の概念は、標準的なTCPパケット処理のための接続とは異なる。上で言及される従来の5タプルの代わりに、接続は、不明瞭なフィールドの2バイトにおいて識別される新しい接続情報とともに、5タプルの標準的なTCP接続情報を含む、6タプルに基づいて判断される。一度、ネットワーク構成要素が、パケットが特別な規則を使用して処理されるべきであるということを把握すると、構成要素は、接続情報を把握するために5タプルの代わりに6タプルを使用し、次いで、従来のパケットと本質的に同じであるRSCプロセスを実行して、パケットの合体、シーケンス番号のチェック等を行う。
加えて、RSCはまた、多くの場合、一部の実施形態における最初に受信されたパケット等の1つを除いて、合体されるパケットの全ての不明瞭なビットを捨てる必要がある。一部の実施形態において、RSCは、不明瞭なフィールドが適合しない時には実施することができないため、他方のパケットからの不明瞭なフィールドが、少なくともそれらのパケットを別様に処理することができるまで、破棄されない。不明瞭なビットの1つのコピーが受信および記憶された(例えば、少なくとも一時的に記憶されるか、またはキャッシュされた)後、不明瞭なフィールドの記憶されたコピーと適合する、合体されるべき全ての他のパケットの不明瞭なビットは、オフロードデバイスによって破棄することができる。さらに、パケットの全長は、マージの間に変化しているため、オフロードデバイスは、外部IPおよび内部IPヘッダの両方に対する、チェックサム、IPヘッダフラグ、または他のかかる情報への適切な調節を行わなければならない。不明瞭なフィールド、および他の個所において、バイト数および他の態様もまた、変化する可能性がある。識別のために使用される情報の2バイト(またはnバイト)とは別に、不明瞭なビットの残りは、特定のTCPストリーム内の全てのパケットに対するものと全く同じであることが予想される。1つのプロトコルの実施例において、不明瞭な情報は、特定のネットワーク識別子と対応する可能性がある。仮想機械識別子またはスロットIDといった他の情報も存在し得、これは、TCPストリーム内の各パケットに対するものと同じである。特に、nバイトは、特定の仮想機械と対応するとしてパケットを識別することができる。
多くの実施形態において、フレームワークは、特定の事前構成された値に依存する。例えば、上で述べられるように、フレームワークは、不明瞭なフィールドの事前構成された長さ、ならびに受信されたパケットに対する特定のまたは特別な形式を識別するIPプロトコル値に依存し得る。一部の実施形態における、不明瞭なフィールドの長さは、パケットの特別な形式に対するヘッダの長さと対応する。IPプロトコル値は、特定のプロトコルに対する任意の適切な識別子である可能性がある。フレームワークは、形式を識別する、不明瞭なフィールドにおけるnバイトフィールドのオフセットが、事前構成されるということを予想することができる。一部の実施形態において、これは、特定のポート値と対応し得る。
不明瞭なフィールドの特定の事前構成された値は、あるプロトコルに対して変化し得る。例えば、GREサポートに対する不明瞭なフィールドの長さは、一実施形態において、16バイトであり得、特定のパケットまたはセグメント形式を識別するIPプロトコル値は、47といった値に設定される。一意的なフローを識別するオフセット値は、「キー」フィールドの一部を指す、例えば10といった値、または、他のかかる値に設定され得る。
例示的なプロトコルの場合、不明瞭なフィールドの長さは、20といった値でもって、プロトコル固有のヘッダの長さと適合する場合がある。特定のプロトコルのパケットまたはセグメントを識別するIPプロトコル値は、例えば、17といった値でもって、UDPに対するIANAプロトコル番号に設定され得る。特定の形式のパケットまたはセグメントを識別する、不明瞭なフィールドにおけるオフセット値は、値2を有する、UDP送信先ポートといった、使用される特定のUDPポートに少なくとも部分的に依存し得る。TSOまたはRSC実施する時、一意的なフローを識別する、フィールドの値は、一意的なTCPフローを識別するように、一般的な接続5タプルとともに、送信元スロットおよび標的スロットIDを指定することができる。同様の手法は、種々の実施形態の範囲内で、他のプロトコルに対する値を判断するために使用することができるということが理解されるべきである。
上で言及されるように、クラウドコンピューティングプラットフォームといった環境の一目標は、各顧客に、ネットワークインフラの一部分が、その顧客専用であるという錯覚を提供することであり得る。この錯覚を提供するために、プラットフォームは、低ジッタ、低待ち時間、および高スループットネットワーク性能を含み得るといった、あるレベルの性能を提供することが必要である。ジッタは、常に、概して低くあるべきであるが、所与の実装に対して、低待ち時間および高スループットの定義は、物理的ネットワーク機器および製品設計といった要因に依存し、インスタンス間で変動する。錯覚はまた、他の顧客の選好に起因するアドレス制限を伴わずに、顧客が、カスタム化されたレベル2(L2)またはレベル3(L3)ネットワークトポロジーを定義することを可能にすることによって、部分的に提供することができる。Seattle, WashingtonのAmazon.com, Inc.によって提供される仮想私的クラウド(VPC)環境といったある環境において、カスタム化可能なL2またはL3のルーティング可能なネットワークのオプションは、IPアドレストンネリングの洗練されたソフトウェア実装を介して、大部分は達成される。しかしながら、これらのソフトウェア実装のうちの少なくとも一部において、仮想化された環境において、低ジッタ、低待ち時間、および高スループットネットワーキング性能を維持するのは困難である可能性がある。現在のハードウェア傾向に、より多くのコア、RAM、およびホスト単位の仮想機械が継続し、ネットワーキングサブシステムにますます負荷を課すにつれて、問題 は、さらに悪化し得る。エンドツーエンドソフトウェアスタックを最適化することによって、利得を得ることができるが、少なくとも一部の環境において、ネットワークリソースの仮想化におけるハードウェア支援を提供することが有益であり得る。
上で概説される目標のうちの少なくとも一部を満たすために、種々のオフロードデバイスといったハードウェアは、種々の特性を含む必要があり得る。本明細書において使用される際、「ハードウェアベースの」処理は、概して、ハードウェアデバイスがその処理のうちの少なくとも一部を実施する、任意の処理を指し、処理構成要素は、それ自体を、物理的デバイス(例えば、NIC)として提示するが、実際には、ハードウェアおよび/またはソフトウェアとして実装されてもよい。一部の実施形態において、ハードウェアベースの処理は、システムの構成要素には、少なくとも1つのハードウェア構成要素であるように見える、汎用オフロードデバイスまたは埋め込みシステムを通じて提供されてもよい。例として、それ自体をSR−IOVデバイスとして提示する汎用オフロードデバイスを使用することができる。これらの特性の考察は、提唱される進出および進入経路の高レベルの概要、続いて、種々の実施形態に従って実装することができる個々の段階に関する詳細を示すことによって提供される。例えば、図6は、かかる仮想パケットの例示的な形式600を例解する。図7は、少なくとも一実施形態に従って、仮想化されたデータセンタにおける顧客のかかる顧客パケットとともに使用することができる、例示的なオフロードハードウェア進出プロセス700の高レベルの概要を例解する。進出プロセスの一部として、顧客仮想機械に割り当てられるSR−IOV仮想機能(VF)は、顧客の仮想ネットワークに向かう進出パケットを受信する702。この初期段階において、パケットヘッダ600の内部構成要素608、610、612が存在する一方で、外部構成要素602、604、606、および614は、存在しない。1つ以上の一般チェックは、進出パケットに適用することができる704。これらのチェックは、例えば、L2および/またはL3送信元アンチスプーフィング、ならびに全ての非IPおよびブロードキャストパケット(即ち、サービスDHCP、ARP等への)に対するトラッピングを含むことができる。オフロードデバイスは、一般的な場合は、単一の標的を指定するIPV4「/32」サブネットである、サブネットマスクを有するL2送信先およびL3送信先に基づき得るように、事前投入された規則表においてルックアップを実施することができる706。転送の規則タイプでヒットするある規則を想定すると、規則はまた、オフロードデバイスが発信パケットに付加するトンネルヘッダに対して、システムメモリ内のポインタを指定することができる。この点において、パケットはまた、初期外部構成要素602、604、606を含むことができる。オフロードデバイスは、以下でさらに詳細に述べられる、1つ以上のメトリック更新を実施することができる708。
少なくとも部分的に規則適合(または規則適合の欠如)に基づいて、オフロードデバイスは、取るべき適切な行為を判断することができる710。行為は、例えば、信頼されるルートドメインへのトラップ712、パケットのドロップ714、またはカプセル化および/もしくはマングリングを伴うパケットの転送716を含むことができる。オフロードデバイスが、信頼されるドメインへのパケットのトラップ712を決定する場合、ドライバコールバックは、信頼されるドメインが、パケットのさらなるソフトウェアベースの処理を実施することを可能にすることができる。オフロードデバイスが、パケットのドロップ714を決定する場合、さらなる処理は行われない(少なくとも一部の実施形態において)。オフロードデバイスが、代わりに、パケットの転送716を決定する場合、パケットを物理的ネットワーク上へ解放することができる前に、さらなる処理が必要とされ得る。本実施例において、オフロードデバイスは、例えば、さらに詳細に以下で説明されるように、パケット上でスロットリングおよびQoS行為718を行う。オフロードデバイスはまた、オフロードエンジンに送給される最終パケットを構築および/またはマングリング720することができる。外部パケットヘッダ構成要素602、604、606は、パケットに付加することができる。これらは、先の規則適合に基づくパケットバイトとともに、スキャッターおよび/またはギャザーDMAを介して、取り出されている可能性がある。次いで、オフロードデバイスは、該当する場合、TSOを含む、オフロード(複数を含む)を実施720することができる。パケットヘッダフィールドは、必要な場合、更新することができ、以下でより詳細に述べられるように、内部および外部IP長さ、内部および外部TCPチェックサム(即ち、IPプロトコルがTCPである場合)、内部L2 MAC送信元および送信先アドレス、ならびに内部L3 IP TTLを含むが、必ずしもこれらに限定されない。
図8は、少なくとも一実施形態に従って使用することができる、仮想化されたデータセンタにおける顧客パケットに対する、例示的なオフロードデバイスハードウェアベースの進入プロセス800の同様の高レベルの概要を例解する。この例示的なプロセス800において、パケットは、オフロードデバイス物理的機能上で受信802される。オフロードデバイスは、以下でさらに詳細に述べられるように、その後の規則処理に対して構築される規則ルックアップキーを構築804することができる。次いで、オフロードデバイスは、導出されたルックアップキーに基づき、事前投入された規則表において、ルックアップを実施806することができる。オフロードデバイスは、必要な場合、種々のメトリック更新808を実施し、少なくとも部分的に規則適合(または規則適合の欠如)に基づいて、取るべき適切な行為を判断810することができる。最初の行為において、オフロードデバイスは、信頼されるルートドメインへのパケットのトラップ812を決定することができる。この場合、ドライバコールバックは、信頼されるドメインが、パケットのさらなるソフトウェアベースの処理を実施することを可能にすることができる。別の可能な行為において、オフロードデバイスは、パケットのドロップ814を決定することができるため、そのパケットのさらなる処理は行われない。別の可能な行為において、オフロードデバイスは、例えば、カプセル化および/またはマングリングを伴って、内部VFへのパケットの転送816を決定することができる。VF(VM)IDは、転送規則において指定することができる。オフロードデバイスは、パケットから外部カプセル化ヘッダ602、604、606をストリップ818することができる。内部マングリングは、全てのかかるマングリングが先に進出において行われたため、本実施例において、必要とされない。1つ以上のパケットまたはパケットデータ部分の再順序付け、分割、またはそうでなければ修正といった、種々の他のパケット修正も実施することができる。この段階で、パケットは、ゲストVFを介して、ゲストVMに配信820することができる。
述べられるように、かかる手法は、パケットのハードウェアベースの、規則ベースのパケットマングリングおよびカプセル化を提供することができる。かかる手法は、複数の(および恐らく重複する)顧客仮想ネットワークが、統一されたL3ルーティング可能な物理的サブストレート上にオーバーレイされることを可能にする。共通の規則表を、進出および進入パケット経路の両方に対して使用することができ、少なくとも一部の実施形態において、規則表は、ソフトウェア機構を介して、信頼されるルートドメインによって投入される。
以下は、種々の実施形態に従って、使用することができる、例示的な規則表実装のサイズおよび性能に関するガイドラインを提供する。例示的な規則表は、ホスト上で実行される仮想機械あたり約1,000の規則エントリ(進入と進出との間で共有される)を有することができる。少なくとも一部の実施形態において、可能な最も大きい規則表サイズを利用することが望ましい可能性があるが、少なくとも一部の場合において、増加した表サイズの素価は、オフロードデバイスにおける増加したRAM要件となるため、デバイスRAMによって課される規則表サイズにおける制限がある。ホスト上のVMの数が増加するにつれて、規則の数も適宜変化し得る。例えば、少なくとも一実施形態において、128のVMおよび128の対応するSR−IOV VFが存在する場合、128,000の規則エントリが存在するであろうが、32,000または16,000といった数も可能であり得る。規則エントリは、少なくとも一部の実施形態において、信頼されるルートドメインによって定義されるように、VF間で分割可能であるべきである。例えば、1つのVFは、10の規則エントリを有し得る一方で、別のVFは、規則エントリの可能な総数のうち2,000を有する。規則表更新の性能もまた、パケット処理パイプラインに過剰なストールを引き起こさないように、十分に高速であるべきである、一部の実施形態において、規則表は、正常な動作中、約5秒程度ごとにその全体として修正される場合がある。
例示的な進出規則表は、多様な異なるフィールドを有することができる。一実施例において、規則表は、内部L2送信先MAC(適合標的)フィールドを有する。全ての進出規則は、内部L2 MACアドレスにおいて適合され得る。これは、顧客の仮想ネットワークが、所望される場合、L2のみであること(およびL3対応ではないRoCEのようなプロトコルをサポートすること)を可能にする。表はまた、サブネットマスク(適合標的)フィールドを伴う、オプションの内部IPV4/IPV6送信先を有することができる。進出規則は、任意に、標的IPアドレス/サブネットにおいて適合され得る。サブネット規則の使用は、所望される場合、複数の規則が崩壊することを可能にする。オプションの内部L2 MAC送信元/送信先マングリング置換フィールドもまた、使用することができる。任意のL3トポロジーをサポートするために、「ファントムルータ」をサポートするように、内部送信先および送信元MACアドレスの両方を交換する能力をサポートすることができる。VMは、例えば、それが、サブネットA上にあり、パケットをサブネットBに送信使用としていると考える場合がある。このため、パケットは、以下のような、ゲストVMによって構築されるようなL2ヘッダを有し得る。
L2 MAC送信元アドレス:ホスト1(サブネットA)VFオフロードデバイスのMACアドレス
L2 MAC送信先アドレス:サブネットAゲートウェイのMACアドレス
進出時には、少なくとも一部の実施形態において、以下の実施例のように見えるように、内部L2ヘッダを動的にマングリングすることができる(それにより、パケットが標的上で脱カプセル化される時、内部L2ヘッダは、2つの仮想機械間に実ルータ(複数を含む)が存在した場合に予期されるもののように見える)ことが望ましい可能性がある。
L2 MAC送信元アドレス:サブネットBゲートウェイのMACアドレス
L2 MAC送信先アドレス:ホスト2(サブネットB)VFオフロードデバイスのMACアドレス
オプションの内部IP TTLデクリメントフィールドもまた、使用することができる。例えば、「ファントムルータ」をサポートするために、内部IP TTL(該当する場合)を任意に自動デクリメントする能力が必要とされ得る。TTLがゼロに到達する場合、パケットは、信頼されるルートパーティションへトラップされるべきである。
表はまた、システムRAMにおけるカプセル化ブロブに対するポインタといったフィールドを有することができる。ブロブの表は、信頼されるルートパーティションによって所有されるメモリに記憶することができる。これらのメモリアドレスは、例えば、機械固有のDMA機構に依存し得るような、信頼されるルートパーティションのホスト物理アドレスまたはゲスト物理アドレスであり得る。表はまた、メトリックのためのフィールド、および規則行為のための少なくとも1つのフィールドといった、追加のフィールドも含むことができる。上で述べられるように、規則行為は、例えば、信頼されるルートパーティションへのトラップ、パケットのドロップ、またはカプセル化/マングリング、および転送を指定することができる。
例示的な進入規則表は、種々のフィールドも有することができる。例えば、適合キー(適合標的)フィールドは、進入規則適合のために使用することができ、これは、システムのより複雑な態様のうちの1つであり得る。特定のカプセル化形式を必要とするハードウェアを有しないために、ハードウェアにおいて合理的に取得可能であるものの中でできる限り一般的であるスキームを利用することができる。図9は、一実施形態に従って、使用することができる、進入適合キー作成の例示的な実装を示す。オフロードデバイスは、いくつかのシステム定義されたバイト範囲および/またはバイト範囲コレータ904を利用することができ、これは、着信パケット902からのバイト範囲を照合するように、システム初期化時に、信頼されるルートパーティションによって、プログラムすることができる。これらのパケットは、一時的なバイトバッファ906、または他の適切な場所へと照合することができる。少なくとも一実施形態において、パケットの開始から256以下のバイトの0〜128バイトの4つのバイト範囲は、十分であり得、全てのバイト範囲は、ともに、合計で128超のバイトにはならない。次いで、さらなるシステム全体のビットマスク908(信頼されるルートパーティションによってプログラムされる)を、バイトバッファに適用して、どのバイトが規則表における適合に使用されるかを判断することができる。次いで、最終進入適合キー910を、結果として生成することができ、キーは、進入規則表において適切な規則をルックアップするために使用することができる。
他のフィールドは、進入規則表とともに使用することもできる。例えば、転送すべきVM/VF IDを明示的に指定することができる、VM/VF IDフィールドを使用することができ、規則行為は、VM/VFへの転送を含む。他のフィールドは、上で述べられる進出規則表と同様の、例えば、メトリックフィールド、および規則行為フィールドを含むことができる。メトリックは、信頼されるルートパーティションによる後の取り出しのために、ハードウェアによって収集することができる。進入/進出規則ごとに必要とされ得るメトリックの例としては、行為が行われる(ドロップされる、転送される等)バイト数、および行為が行われる(ドロップされる、転送される等)パケット数が挙げられる。各メトリックフィールドは、信頼されるルートパーティションによって読み取り可能かつ消去可能であるべきである。フィールドのサイズは、例えば、ハードウェアベンダの自由裁量により得、信頼されるルートパーティションからの割り込み駆動型の収集方法を想定することができる。
少なくとも一部の実施形態において、少なくとも2つの大まかなタイプの可能なスロットリングまたはサービスの質(QoS)が存在する。第1のタイプは、本明細書において「ハードキャップ」タイプのスロットリングと称され、各スロットリングされたエンティティは、システムにおける他のスロットリングされたエンティティの使用にかかわらず、特定の量でキャップされる。第2のタイプは、本明細書において「バースト可能なキャップ」タイプと称され、スロットリングされたエンティティが、システムにおいて利用可能な余剰容量があるかどうかに依存して、それらのキャップ上でバーストすることが可能とされる。例示的な実施形態において、SR−IOV仮想機能上で50Mb/秒間隔(または一部の実施形態において、10〜25Mb/秒間隔)といった、ハードキャップを配置する能力が必要とされ得る。少なくとも一部の実施形態において、異なるトラフィックを異なる割合でスロットリングすることができるように、進出規則あたり少なくとも1つのスロットリングクラスを、および異なるトラフィックを優先化することができるように、進出規則あたり1つのQoSクラスを、ハードウェアにおいて利用する。少なくとも一部の実施形態において、利用可能および所望される場合、未使用のシステム容量を、消費することができるように、1つ以上の構成可能な、バースト可能な、規則あたりのスロットリングクラスを提供することもまた、望ましい可能性がある。
少なくとも一部の実施形態において、パケットにおける種々のチェックを提供することが望ましい可能性がある。例えば、一部の実施形態において、全ての進出パケットは、VFに割り当てられた正確なL2 MACアドレスに対してチェックされなければならない。少なくとも一部の実施形態において、進出パケットがL3 IPである場合、送信元IPアドレスもまた、チェックされなければならない。正確なL2 MACおよび/またはL3 IPアドレスを有しないパケットは、少なくとも一部の実施形態において、ドロップされるべきである。DHCP、ARP、IPブロードキャスト、およびマルチキャスト等を含む、信頼されるルートパーティションへトラップされるように、全てのL2および/またはL3ブロードキャストトラフィックを構成する能力もまた存在し得る。さらに、信頼されるルートパーティションは、少なくとも一部の実施形態において、進入パケットを仮想機能パケットキューに注入する能力を有する。これらのパケットは、通常のマングリング/カプセル化システムを回避することができる。
少なくとも一部の実施形態において、オフロードデバイスハードウェアは、SR−IOV仮想機能におけるカプセル化/マングリングを行いつつ、少なくとも1つの標準的な組のオフロードおよびハードウェア強化をサポートする。これらは、例えば、種々のチェックサムオフロード、マルチキュー能力、および割り込み合体を含む、TCPセグメント化オフロード(TSO)を含むことができる。その組はまた、RDMAサポート(例えば、RoCEまたはiWARP)を含むことができる。例えば、L2のみのRDMAプロトコルが使用される場合でさえも、パケットが、L3ラッパの内側でカプセル化されるという事実は、アプリケーションレベルプロトコルが、下部の物理的ネットワークサブストレートから不可知であり得るということを意味する。
SR−IOVの使用は、下部ハードウェアが、もはや抽象化されていないという点において、仮想化の利益を無効にし得る。高度な機能性をユーザに提供しつつ、同じレベルの柔軟性を保つために、ハードウェアベンダは、VMMからゲストVMにドライバコードを動的に注入する手法を提供することができる。かかる手法は、ゲストVM内の単一の抽象ドライバが、共通のインターフェースを介して任意のハードウェアで実行することを可能にし、このため、ソフトウェアにおいて完全にエミュレートされるハードウェアデバイス、またはハードウェアにおいて主に実装されているもののいずれかをラップすることができる。
上で列記されるものに加えて、種々の他の規則もまた、実装することができる。例えば、進出パケットに関して、許容可能な送信先MACアドレス、および各規則の「適合」部分を形成する送信先IPサブネットのリストが存在し得る。規則は、送信先MACアドレスおよび送信先IPサブネットを有することができるか、または規則は、全てのIPアドレスを受け入れることができる場合、送信先MACアドレスのみを有することができる。各規則は、規則の一部として、「N」バイトの不明瞭なヘッダ、送信元MACアドレス、および標的MACアドレスを有することができる。規則が適合する時、「N」バイトの不明瞭なヘッダは、元のL2ヘッダの前に挿入することができ、L2ヘッダ内のMACアドレスは、事前指定された値と置換することができる。新しい外部L2およびL3ヘッダ(例えば、MACおよびIP)は、規則表からの外部送信元IPアドレス、外部送信先IPアドレス、外部送信先MAC、および外部送信元MACとともに、不明瞭なフィールドの前に挿入することができる。任意に、不明瞭なヘッダは、L2およびL3ヘッダを含むことができ、オフロードデバイスは、すぐに、ID、長さ、チェックサム、およびフラグといったフィールドに記入することができる。一部の実施形態において、内部送信元および送信先IPアドレスもまた、例えば、NAT、エニーキャスト等の将来の仮想化を可能にするように、置換可能である。
処理および管理の少なくとも一部は、Xen Dom−0といった信頼されるホストプラットフォームにおいて実行するように動作可能な、ソフトウェア管理インターフェースによって実施することができる。かかるインターフェースは、スロットリング、セキュリティグループ、およびパートナ構成要素を含み得るような、テナントごとのネットワーク仕様をリアルタイムでロードするように、分散サービスと通信することができる。インターフェースは、例えば、テナントごとの(SR−IOV)仕様を実行するように、オフロード構成要素に命令することができる。これらのコマンドは、仕様が変化する際に、リアルタイムで処理することができる。インターフェースはまた、ハードウェアまたは他のオフロード構成要素が、任意の所与の時間に、規則全体を同時に保持することができない場合、オフロード構成要素ベースの規則の拡張された管理を実施することができる。これらは、例えば、ソフトウェアトラップまたは他のかかるプロセスを介して、使用されることがより少ない規則のサブセットを処理しつつ、最新の規則、または頻繁に利用される規則のサブセットをローディングするといった、技術を含むことができる。インターフェースは、信頼されるホストプラットフォームまたは仮想テナントに対するトラフィックといった、異なるタイプのトラフィック間で区別することができ、かつ適宜配信することができる。
少なくとも一部の実施形態において、アドレス解決プロトコル(ARP)パケットおよびマルチキャストパケットといった、特別な処理を必要とするパケットもまた、Dom−0内のソフトウェア管理構成要素によって管理することができる。DNS、セキュリティインターフェース、およびウェブサーバインターフェースといった、他の高度な機能性もまた、ソフトウェア管理インターフェースによって処理することができる。セキュリティインターフェースに関して、インスタンスは、ネットワーク接続を得る前に、安全なログインを実施することができる。ウェブサーバインターフェースは、例えば、メタデータサービスまたは他のかかるアプリケーションに対するインターフェースであり得る。
種々の実施形態は、以下の付記を考慮して説明することができる。
付記1. マルチテナント環境において、データパケットを処理するためのフレームワークであって、
少なくとも1つのプロセッサと、
プロセッサによって実行される時、フレームワークが、
1つ以上のテナントごとのネットワーク仕様をロードするように、1つ以上の分散サービスと通信することと、
ロードされたテナントごとのネットワーク仕様を実行するように、少なくとも1つのオフロードデバイスに命令することと、
少なくとも1つのオフロードデバイスが、一組の規則の全てを同時に記憶することができない時、少なくとも1つのオフロードデバイスに対する一組の規則を管理することと、
複数のトラフィックタイプの各々に対する適切な送信先に、データパケットを配信することと、を可能にする、命令を含む、メモリと、を備える、フレームワーク。
付記2. フレームワークは、信頼されるホストドメインにおいて実行するように動作可能なソフトウェア管理インターフェースを提供する、付記1に記載のフレームワーク。
付記3. ソフトウェア管理インターフェースは、特別な処理を必要とするパケットを管理するようにさらに動作可能である、付記2に記載のフレームワーク。
付記4. 特別な処理を必要とするパケットは、マルチキャストパケット、ブロードキャストパケット、およびアドレス解決プロトコル(ARP)パケットを含む、付記3に記載のフレームワーク。
付記5. ソフトウェア管理インターフェースは、ドメイン名サービス(DNS)、セキュリティインターフェーシング、およびウェブサーバインターフェーシングのうちの少なくとも1つを含む機能性を管理するようにさらに動作可能である、付記2に記載のフレームワーク。
付記6. ソフトウェア管理インターフェースは、オフロードデバイスによって収集されることが必要なネットワーク統計、および維持されるべき統計を構成するように動作可能である、付記2に記載のフレームワーク。
付記7. テナントごとのネットワーク仕様は、データパケットのスロットリング、セキュリティグループの動作、およびパートナ構成要素間の通信のうちの少なくとも1つに対する仕様を含む、付記1に記載のフレームワーク。
付記8. テナントごとのネットワーク仕様は、SR−IOVネットワーク仕様である、付記1に記載のフレームワーク。
付記9. テナントごとのネットワーク仕様は、仕様が変化する際、リアルタイムで処理される、付記1に記載のフレームワーク。
付記10. 少なくとも1つのオフロードデバイスに対する一組の規則の管理は、オフロードデバイスにおいて、規則の第1のサブセットをロードする一方で、ソフトウェアストラッピングを使用して、規則の第2のサブセットを処理することを含む、付記1に記載のフレームワーク。
付記11. 規則の第1のサブセットは、規則の第2のサブセットよりもしばしば利用される、付記10に記載のフレームワーク。 付記12. テナントごとの仕様は、ハードウェアベンダが、複数のプロトコルに関する特定の情報を入手することなく、それらの複数のプロトコルをサポートすることを可能にする、付記1に記載のフレームワーク。
付記13. トラフィックタイプは、信頼されるホストプラットフォームに対するトラフィック、および仮想テナントに対するトラフィックのうちの少なくとも1つを含む、付記1に記載のフレームワーク。
付記14. オフロードデバイスであって、
プロセッサと、
プロセッサによって実行される時、オフロードデバイスが、
ハードウェアデバイスとしてオフロードデバイスを露出することと、
オフロードハードウェアデバイスと関連付けられる物理的機能に対して受信されるユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、データパケットの内部および外部ヘッダをストリップすることと、任意のパケット修正を実施することと、ユーザデータパケットを内部仮想機能へ転送することと、を含み、内部仮想機能は、ユーザデータパケットをゲスト仮想機械へ配信するように動作可能である、実施することと、を可能にする、命令を記憶するメモリと、を備える、オフロードデバイス。
付記15. 処理は、少なくとも1つの外部カプセル化ヘッダをユーザデータパケットから除去することを含む、付記14に記載のオフロードデバイス。
付記16. オフロードデバイスは、ネットワークインターフェースカード(NIC)である、付記14に記載のオフロードデバイス。
付記17. オフロードデバイスは、複数のプロトコルに関する特定の情報を入手することなく、それらの複数のプロトコルをサポートするように動作可能である、付記14に記載のオフロードデバイス。
付記18. マルチテナント環境において、データパケットを処理するための方法であって、
1つ以上のテナントごとのネットワーク仕様をロードするように、1つ以上の分散サービスと通信することと、
ロードされたテナントごとのネットワーク仕様を実行するように、少なくとも1つのオフロードデバイスに命令することと、
少なくとも1つのオフロードデバイスが、一組の規則の全てを同時に記憶することができない時、少なくとも1つのオフロードデバイスに対する一組の規則を管理することと、
複数のトラフィックタイプの各々に対する適切な送信先に、データパケットを配信することと、を含む、方法。
付記19. 信頼されるホストドメインにおいて実行するように動作可能なソフトウェア管理インターフェースを露出することと、をさらに含む、付記18に記載の方法。
付記20. ソフトウェア管理インターフェースは、ドメイン名サービス(DNS)、セキュリティインターフェーシング、およびウェブサーバインターフェーシングのうちの少なくとも1つを含む機能性を管理するようにさらに動作可能である、付記19に記載の方法。
付記21. オフロードデバイスは、SR−IOVネットワーク仕様に従って動作する、付記19に記載の方法。
付記22. 電子環境において、データパケットを処理するためのコンピュータ実装方法であって、
実行可能な命令とともに構成される1つ以上のコンピュータシステムの制御下で、
ユーザに対する仮想ネットワークと関連付けられる仮想機能に対するユーザデータパケットを受信することと、
ユーザデータパケットを処理するための少なくとも1つの規則に対して、規則表においてルックアップを実施することと、
規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいてユーザデータパケットのソフトウェアベースの処理を実施することと、
規則表からのドロップ規則の判断に応答して、ユーザデータパケットのさらなる処理を実施しないことと、
規則表からの転送規則の判断に応答して、オフロードデバイスを使用して、ユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、外部ヘッダをユーザデータパケットに追加することと、ユーザデータパケットを物理的ネットワーク上へ送信することと、を含み、外部ヘッダは、少なくとも1つの不明瞭なフィールドを含み、かつプロトコル固有の情報を含む、実施することと、を含む、コンピュータ実装方法。
付記23. ルックアップを実施する前に、ユーザデータパケットに対して、少なくとも1つの一般チェックを実施することをさらに含む、付記22に記載のコンピュータ実装方法。
付記24. 少なくとも1つの一般チェックは、少なくとも1つのタイプのパケットに対するレベル2(L2)またはレベル3(L3)アンチスプーフィング、またはトラッピングのうちの少なくとも1つを含む、付記23に記載のコンピュータ実装方法。
付記25. ルックアップは、オフロードデバイスによって実施される、付記22に記載のコンピュータ実装方法。
付記26. オフロードデバイスは、シングルルートI/O仮想化(SR−IOV)プロトコルに基づく、仮想化されたオーバーレイネットワークを提供する、付記25に記載のコンピュータ実装方法。
付記27. ルックアップを実施する前に、ユーザデータパケットにおいて、少なくとも1つのメトリック更新を実施することをさらに含む、付記22に記載のコンピュータ実装方法。
付記28. オフロードデバイスを使用する処理は、ユーザデータパケットのスロットリング、またはサービスの質行為の実施のうちの少なくとも1つをさらに含む、付記22に記載のコンピュータ実装方法。
付記29. ユーザデータパケットを物理的ネットワークに送信することは、セグメント化オフロードプロセスの一部として実施される、付記22に記載のコンピュータ実装方法。
付記30. オフロードデバイスを使用する処理は、ユーザデータパケットのヘッダフィールドを更新することをさらに含み、ヘッダフィールドは、内部および外部パケットの長さ、ならびに内部および外部チェックサム、送信元および送信先アドレス、ならびに有効時間(TTL)値のうちの少なくとも1つを含む、付記22に記載のコンピュータ実装方法。
付記31. オフロードデバイスを使用する処理は、少なくとも部分的に送信元仮想機械に基づいて、各進出パケットにおいて、パケット送信元チェックを実施することを含む、付記22に記載のコンピュータ実装方法。
付記32. ソフトウェアベースの処理は、Dom−0制御ソフトウェアによる処理を含む、付記22に記載のコンピュータ実装方法。
付記33. 処理は、ルックアップキーのパラメータの変更を通じて、いかなる適切なプロトコルもサポートすることができるように、一般形式を利用する、付記22に記載のコンピュータ実装方法。
付記34. 適切なプロトコルを、ステートレストンネリングプロトコルにマップすることができる、付記33に記載のコンピュータ実装方法。
付記35. 電子環境において、データパケットを処理するためのコンピュータ実装方法であって、
実行可能な命令とともに構成される1つ以上のコンピュータシステムの制御下で、
オフロードデバイスと関連付けられる物理的機能に対するユーザデータパケットを受信することと、
オフロードデバイスを使用して、ユーザデータパケットに対するルックアップキーを構築することと、
ルックアップキーを使用してユーザデータパケットを処理するための少なくとも1つの規則に対して、規則表においてルックアップを実施することと、
規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいてユーザデータパケットのソフトウェアベースの処理を実施することと、
規則表からのドロップ規則の判断に応答して、ユーザデータパケットのさらなる処理を実施しないことと、
規則表からの転送規則の判断に応答して、オフロードデバイスを使用して、ユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、内部および外部ヘッダをストリップすることと、任意のパケット修正を実施することと、ユーザデータパケットを内部仮想機能へ転送することとを含み、内部仮想機能は、ユーザデータパケットをゲスト仮想機械へ配信するように動作可能である、実施することと、を含む、コンピュータ実装方法。
付記36. オフロードデバイスを使用する処理は、少なくとも1つの外部カプセル化ヘッダをユーザデータパケットから除去することを含む、付記35に記載のコンピュータ実装方法。
付記37. 内部仮想機能は、転送規則によって識別される、付記35に記載のコンピュータ実装方法。
付記38. オフロードデバイスを使用する処理は、事前定義されたオフセットにおいて、事前定義されたプロトコルの形式を使用してカプセル化されているとして、ユーザデータパケットを識別するように動作可能である、付記35に記載のコンピュータ実装方法。
付記39. ユーザデータパケットがカプセル化されない時、ソフトウェアベースの処理を使用して、ユーザデータパケットを処理することをさらに含む、付記35に記載のコンピュータ実装方法。
付記40. オフロードデバイスは、ネットワークインターフェースカード(NIC)である、付記35に記載のコンピュータ実装方法。
付記41. ユーザデータパケット内の既定のオフセットにおける不明瞭なビット内の固定長フィールドを使用して、ユーザデータパケットに対応する仮想機械を判断することをさらに含む、付記35に記載のコンピュータ実装方法。
付記42. 各物理的機能は、一組の進入規則を有し、各規則は、少なくとも部分的に、カプセル化された進入パケットの不明瞭なビットと適合されることが可能である、一組の不明瞭なビットから成る、付記35に記載のコンピュータ実装方法。
付記43. 他のトラフィックは、規則表からの通過規則の判断に応答して、処理を伴わずに通過される、付記35に記載のコンピュータ実装方法。
付記44. 顧客がカプセル化したトラフィックおよび制御トラフィックは、規則表からの通過規則の判断から独立してトラップされる、付記35に記載のコンピュータ実装方法。
付記45. 電子環境において、データパケットを処理するためのシステムであって、
プロセッサと、
プロセッサによって実行される時、プロセッサに、
ユーザに対する仮想ネットワークと関連付けられる仮想機能に対するユーザデータパケットを受信することと、
ユーザデータパケットを処理するための少なくとも1つの規則に対して、規則表においてルックアップを実施することと、
規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいてユーザデータパケットのソフトウェアベースの処理を実施することと、
規則表からのドロップ規則の判断に応答して、ユーザデータパケットのさらなる処理を実施しないことと、
規則表からの転送規則の判断に応答して、オフロードデバイスを使用して、ユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、外部ヘッダをユーザデータパケットに追加することと、ユーザデータパケットを物理的ネットワーク上へ送信することと、を含み、外部ヘッダは、少なくとも1つの不明瞭なフィールドを含み、かつプロトコル固有の情報を含む、実施することと、を行わせる、命令を含むメモリデバイスと、を備える、システム。
付記46. ルックアップを実施するように動作可能な、少なくとも1つのオフロードデバイスをさらに備える、付記46に記載のシステム。
付記47. オフロードデバイスは、シングルルートI/O仮想化(SR−IOV)プロトコルに基づく、仮想化されたオーバーレイネットワークを提供する、付記46に記載のシステム。
付記48. 電子環境において、データパケットを処理するためのシステムであって、
プロセッサと、
プロセッサによって実行される時、プロセッサに、
オフロードデバイスと関連付けられる物理的機能に対するユーザデータパケットを受信することと、
オフロードデバイスを使用して、ユーザデータパケットに対するルックアップキーを構築することと、
ルックアップキーを使用してユーザデータパケットを処理するための少なくとも1つの規則に対して、規則表においてルックアップを実施することと、
規則表からのトラップ規則の判断に応答して、信頼されるドメインにおいてユーザデータパケットのソフトウェアベースの処理を実施することと、
規則表からのドロップ規則の判断に応答して、ユーザデータパケットのさらなる処理を実施しないことと、
規則表からの転送規則の判断に応答して、オフロードデバイスを使用して、ユーザデータパケットの処理の少なくとも一部分を実施することであって、処理は、少なくとも、内部および外部ヘッダをストリップすることと、任意のパケット修正を実施することと、ユーザデータパケットを内部仮想機能へ転送することとを含み、内部仮想機能は、ユーザデータパケットをゲスト仮想機械へ配信するように動作可能である、実施することと、を行わせる、命令を含むメモリデバイスと、を備える、システム。
付記49. オフロードデバイスを使用する処理は、少なくとも1つの外部カプセル化ヘッダをユーザデータパケットから除去することを含む、付記48に記載のシステム。
付記50. オフロードデバイスは、ネットワークインターフェースカード(NIC)である、付記48に記載のシステム。
上で述べられるように、種々の実施形態は、一部の場合において、いくつかのアプリケーションのうちのいずれかを動作させるために使用することができる、1つ以上のユーザコンピュータ、コンピューティングデバイス、または処理デバイスを含むことができる、多種多様な動作環境において実装することができる。ユーザまたはクライアントデバイスは、標準的なオペレーティングシステムを実行するデスクトップまたはラップトップコンピュータといった、いくつかの汎用パーソナルコンピュータ、ならびにモバイルソフトウェアを実行し、いくつかのネットワーキングおよびメッセージングプロトコルをサポートすることが可能である、セルラ、無線、およびハンドヘルドデバイスのうちのいずれかを含むことができる。かかるシステムはまた、多様な商業的に利用可能なオペレーティングシステム、ならびに開発およびデータベース管理といった目的のための他の既知のアプリケーションを実行する、いくつかのワークステーションを含むことができる。これらのデバイスはまた、ネットワークを介して通信することが可能なダミー端末、シンクライアント、ゲームシステム、および他のデバイスといった他の電子デバイスを含むことができる。
種々の態様もまた、サービス指向アーキテクチャの一部であってもよいように、少なくとも1つのサービスまたはウェブサービスの一部として実装することができる。ウェブサービスといったサービスは、拡張可能マークアップ言語(XML)形式のメッセージを使用し、SOAP(「シンプルオブジェクトアクセスプロトコル」から派生)等の適切なプロトコルを使用して交換する等によって、任意の適切なタイプのメッセージングを使用して通信することができる。かかるサービスによって提供または実行されるプロセスは、ウェブサービス記述言語(WSDL)といった任意の適切な言語で書くことができる。WSDLといった言語を使用することは、種々のSOAPフレームワークにおけるクライアントサイドコードの自動生成といった機能性を可能にする。
ほとんどの実施形態は、TCP/IP、OSI、FTP、UPnP、NFS、CIFS、およびAppleTalkといった多様な商業的に利用可能なプロトコルのうちのいずれかを使用する通信をサポートするために、当業者が熟知しているであろう、少なくとも1つのネットワークを利用する。ネットワークは、例えば、ローカルエリアネットワーク、ワイドエリアネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、およびこれらの組み合わせであり得る。
ウェブサーバを利用する実施形態において、ウェブサーバは、HTTPサーバ、FTPサーバ、CGIサーバ、データサーバ、Javaサーバ、およびビジネスアプリケーションサーバを含む、多様なサーバまたは中間層アプリケーションのうちのいずれかを稼動することができる。サーバはまた、Java(登録商標)、C、C#またはC++等の任意のプログラム言語、あるいはPerl、Python、またはTCL等の任意のスクリプト言語、ならびにこれらの組み合わせで作成された1つ以上のスクリプトまたはプログラムとして実装されてもよい、1つ以上のウェブアプリケーションを実行することによって等、ユーザデバイスからのリクエストに応答して、プログラムまたはスクリプトを実行することが可能であってもよい。サーバはまた、これらに限定されないが、Oracle(登録商標)、Microsoft(登録商標)、Sybase(登録商標)、およびIBM(登録商標)から市販されているデータベースサーバを含んでもよい。
環境は、上で述べられるように、多様なデータストアならびに他のメモリおよび記憶媒体を含むことができる。これらは、コンピュータのうちの1つ以上にローカルの(および/もしくは内部に常駐)、あるいはネットワーク全体のコンピュータのうちのいずれかまたは全てからリモートの記憶媒体等、多様な場所に常駐することができる。特定の組の実施形態において、情報は、当業者が熟知するストレージエリアネットワーク(「SAN」)の中に常駐してもよい。同様に、コンピュータ、サーバ、または他のネットワークデバイスに帰属する機能を実施するための必要ないずれのファイルも、必要に応じて、ローカルおよび/またはリモートに記憶されてもよい。システムがコンピュータデバイスを含む場合、各かかるデバイスは、バスを介して電気的に連結されてもよいハードウェア要素を含むことができ、要素としては、例えば、少なくとも1つの中央処理装置(CPU)、少なくとも1つの入力デバイス(例えば、マウス、キーボード、コントローラ、タッチ画面、またはキーパッド)、および少なくとも1つの出力デバイス(例えば、表示デバイス、プリンタ、またはスピーカ)が挙げられる。かかるシステムはまた、ランダムアクセスメモリ(以下「RAM」)、または読み取り専用メモリ(以下「ROM」)、ならびに取り外し可能媒体デバイス、メモリカード、フラッシュカード等のディスクドライブ、光学式記憶装置、およびソリッドステート記憶装置などの1つ以上の記憶装置も含んでもよい。
かかるデバイスはまた、上で説明されるように、コンピュータが読み取り可能な記憶媒体リーダ、通信デバイス(例えば、モデム、ネットワークカード(無線または有線)、赤外線通信デバイス等)、およびワーキングメモリを含むことができる。コンピュータが読み取り可能な記憶媒体リーダは、コンピュータが読み取り可能な情報を一時的におよび/またはより永続的に含有、記憶、伝送、および取り出すためのリモート、ローカル、固定、および/または取り外し可能な記憶デバイス、ならびに記憶媒体を代表する、コンピュータが読み取り可能な記憶媒体と接続、またはそれを受容するように構成することができる。システムおよび種々のデバイスはまた、典型的に、オペレーティングシステム、およびクライアントアプリケーションまたはウェブブラウザといったアプリケーションプログラムを含む、少なくとも1つのワーキングメモリデバイス内に位置する、いくつかのソフトウェアアプリケーション、モジュール、サービス、または他の要素を含む。代替的な実施形態は、上で説明されるものからの数多くの変形を有し得るということが理解されるべきである。例えば、カスタム化されたハードウェアが使用される場合があり、かつ/または特定の要素が、ハードウェア、ソフトウェア(アプレットといったポータブルソフトウェアを含む)、またはこれらの両方において実装される場合がある。さらに、ネットワーク入力/出力デバイスといった、他のコンピューティングデバイスへの接続が採用されてもよい。
コードまたはコードの一部分を含有するための記憶媒体およびコンピュータが読み取り可能な媒体としては、所望の情報を記憶するために使用することができ、かつシステムデバイスによってアクセスすることができる、RAM、ROM、EEPROM、フラッシュメモリもしくは他のメモリ技術、CD−ROM、デジタル多用途ディスク(DVD)もしくは他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または任意の他の媒体を含む、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または他のデータといった、情報の記憶および/もしくは伝送のための任意の方法または技術において実装される、揮発性および非揮発性、取り外し可能および非取り外し可能な媒体等であるが、これらに限定されない、記憶媒体および通信媒体を含む、当該技術分野において既知または使用される、任意の適切な媒体を挙げることができる。本明細書において提供される開示および教示に基づいて、当業者は、種々の実施形態を実装するための他の方式および/または方法を理解するであろう。
したがって、明細書および図面は、制限の意味ではなく、例解の意味で解釈されるべきである。しかしながら、請求項に記載の本発明の広義の精神および範囲から逸脱することなく、そこに多様な修正および変更が行われてもよいことは自明である。