JP6067880B2

JP6067880B2 - 最長プレフィックス・マッチング・スイッチによるスケーラブル記憶システム

Info

Publication number: JP6067880B2
Application number: JP2015549979A
Authority: JP
Inventors: グアンユ・シ; ジアンミン・ウ; ビュン・チェ
Original assignee: ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date: 2012-12-31
Filing date: 2013-12-31
Publication date: 2017-01-25
Anticipated expiration: 2033-12-31
Also published as: US9172743B2; CN105027527B; US20140188981A1; WO2014101884A1; EP2936776A4; CN105027527A; EP2936776A1; AU2013369728A1; AU2013369728B2; AU2013369728A8; EP2936776B1; JP2016506679A; WO2014101884A9

Description

ネットワークまたは分散記憶システムは、増大する要求を満たすために大容量かつ高速なアクセスを伴うデータ・リポジトリをクライアントに提供するのに有用である。多数の分散記憶システムは、２種類のノード、即ち、サーバ（例えば、従来型のコンピュータ）とスイッチ（例えばＥｔｈｅｒｎｅｔ（登録商標）またはＩｎｆｉｎｉＢａｎｄ）から成る。スイッチは、サーバに対する透過な通信チャネルを実現する。分散ファイル・システム（ＤＦＳ）は、大容量および高速アクセスを提供するために複数のバックエンドの記憶サーバにに跨ってもよく、単一のサーバのように見えることによって統一なインタフェースをクライアントに提供する。クライアントは、ポータブル・オペレーティング・システム・インタフェース（ＰＯＳＩＸ）ファイル・システム・ネーミング・フォーマットまたはバイナリ・フラット・フォーマットの何れかを用いてファイル・コンテンツに名前を付けることができる。

記憶システムが、ファイル名を理解しどのサーバが当該ファイルを記憶しているかを判定するための１つまたは複数のコンポーネントを有してもよい。即ち、記憶システムは、ファイル名を当該ファイルが存在するサーバのアイデンティティまたは位置にマップする１つまたは複数のコンポーネントを有してもよい。典型的なネットワーク・アタッチト・システム（ＮＡＳ）またはＤＦＳでは、当該マッピングを１つまたは複数のメタデータ・サーバにより実装してもよい。当該システムに格納された各ファイルは当該メタデータ・サーバ（複数可）内にエントリを有するべきである。大部分のキー値記憶システムに対して、シングルホップまたはマルチホップの分散ハッシュ・テーブル（ＤＨＴ）を使用してもよい。各記憶サーバはルーティング・テーブルを維持しなければならないかもしれず、これが、計算量が記憶サーバの数とファイルの数に基づく原因となる。当該システムが拡大するとき、拡張可能性に対する主な課題には、メタデータ・サーバまたはＤＨＴノード内のルーティング・テーブルを維持することがある。したがって、データ記憶のための集中的なメタデータ・サーバまたはインデクサへの依存を克服するためのスケーラブルな分散記憶システムを構築する必要がある。また、記憶域の要求の増大のため、増大した拡張可能性を有する記憶システムが必要である。

１実施形態では本発明はスイッチにより実施される方法を含む。当該方法は、ファイルに対する要求をクライアントから受信するステップであって、当該ファイルは分散記憶システムに配置されているステップと、当該ファイルのディレクトリを当該要求から抽出するステップと、当該ディレクトリの最長プレフィックス・マッチング（ＬＰＭ）を転送情報ベース（ＦＩＢ）に対して実施してポートを識別するステップであって、当該ＦＩＢはディレクトリを当該スイッチのポートと関連付けるステップと、クライアント要求を、当該ファイルを含むサーバに当該識別されたポートを介して転送するステップであって、サーバは当該分散記憶システム内の複数のサーバの１つであるステップとを含む。

別の実施形態では、本発明は、ファイルに対する要求をクライアントから取得し、当該ファイルのディレクトリを当該要求から抽出し、当該ディレクトリのＬＰＭをＦＩＢに対して実施してポートを識別するように構成されたプロセッサであって、当該ファイルは分散記憶システムに配置されており、当該ＦＩＢはディレクトリを当該スイッチのポートと関連付けるプロセッサと、当該ＬＰＭモジュールに接続され、当該識別されたポートを介してクライアント要求を当該ファイルを含むサーバに転送するように構成された送信器であって、サーバは当該分散記憶システム内の複数のサーバの１つである送信器とを備えたスイッチを備える。

さらに別の実施形態では本発明は、ユーザ・ダイアグラム・プロトコル（ＵＤＰ）要求をクライアントから受信するステップであって、当該ＵＤＰ要求は要求されたファイルと当該ファイルのディレクトリを含むステップと、当該ディレクトリのＬＰＭをインデックス・テーブルに対して実施してポートを決定するステップと、クライアントと当該ポートを関連付けるフロー・テーブルにエントリを生成するステップとを含む方法を含む。

さらに別の実施形態では、本発明は、分散記憶システムにおけるサーバ内の方法を含む。サーバはディレクトリ・ツリーの一部を格納し、当該方法は、負荷を測定するステップと、当該負荷が閾値より大きいと判定するステップと、最近傍のサーバを当該ディレクトリ・ツリーの一部の第１の部分の受信者として選択するステップと、当該第１の部分を当該最近傍のサーバに転送するステップと、メッセージを最近傍の最長プレフィックス・マッチング（ＬＰＭ）スイッチに送信して当該第１の部分が送信されたことを示すステップとを含む。

これらおよび他の機能は、添付の図面と特許請求の範囲と関連して以下の詳細な説明からより明らかに理解される。

本発明をより十分に理解するために、添付図面と詳細な説明と関連して以下の簡単な説明を参照する。図面では、同じ参照番号は同じ部分を表す。

ＰＯＳＩＸファイル・システム・ツリーにおけるプレフィックス・ベースのサーバ割当ての１実施形態の図である。バイナリ０−１フラット名キー値記憶ファイル・システム・ツリーの１実施形態の図である。ＬＰＭスイッチ・ベースの記憶システムの１実施形態の図である。ＬＰＭスイッチを介して記憶サーバからコンテンツを取り出すための方法の１実施形態の図である。クライアント、ＬＰＭスイッチ、およびサーバの間のシグナリングの１実施形態を示すプロトコル図である。ＬＰＭ方法の１実施形態の流れ図である。ＬＰＭスイッチの１実施形態の略図である。フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）チップで実装されたＬＰＭスイッチの１実施形態の略図である。汎用コンピュータシステムで実装されたＬＰＭスイッチの１実施形態の略図である。負荷分散方法の１実施形態の流れ図である。サーバの１実施形態の略図である。

最初に、以下では１つまたは複数の実施形態の例示的な実装を提供するが、開示したシステムおよび／または方法を、現在公知であるかまたは現存するかに関わらず、任意数の技術を用いて実装してもよいことは理解される。本発明は、本明細書で例示し説明する例示的な設計と実装を含めて、以下で例示する例示的な実装、図面、および技術には決して限定されず、添付の特許請求の範囲内においてその均等物の完全な範囲に沿って修正してもよい。

本明細書では、最長プレフィックス・マッチング（ＬＰＭ）スイッチを用いてファイルまたはコンテンツ名を記憶装置にマップすることによって、拡張可能性を高め、分散記憶システムのコストを削減するためのシステム、方法、および装置を開示する。ＬＰＭスイッチが、ディレクトリ・パスおよびファイル名の最長プレフィックス・マッチングに基づいてルーティングまたはスイッチングを行ってもよい。当該マッチングを、多数の分散ハッシュ・テーブル（ＤＨＴ）の実装で使用されるように、ＰＯＳＩＸファイル・システム・ネーミング記法（例えば、任意の近代オペレーティング・システムにおけるディレクトリ−サブディレクトリ−ファイル構造）および／またはバイナリ０−１フラット・ネーミング記法で利用してもよい。ＬＰＭスイッチを、従来型の媒体アクセス制御（ＭＡＣ）またはインターネット・プロトコル（ＩＰ）プレフィックス・ベースのルーティング／スイッチングに加えて使用してもよい。プレフィックス集約を利用して、転送テーブルのサイズを削減し空間を節約してもよい。さらに、負荷分散機構は、プレフィックス集約を保ちつつ、複数のサーバ間にデータを拡散することで、過負荷のサーバを軽減してもよい。ＬＰＭスイッチの利用により、従来型の分散記憶アーキテクチャと比較してインデックス・サーバの必要性を排除してもよい。

図１は、ＰＯＳＩＸファイル・システム・ツリー１００におけるプレフィックス・ベースのディレクトリ・グルーピングの１実施形態を示す。ファイル・システム１００が、これらのディレクトリ内に複数のディレクトリ、サブディレクトリ、およびファイルを備えてもよい。ディレクトリ・グルーピング１１０、１２０、１３０の各々を異なる記憶サーバに割り当ててもよい。任意数のサーバをファイル記憶システムで使用してもよい。記憶サーバが、ネットワークによりアクセス可能でデータを格納するためのメモリ装置を有する任意の装置であってもよい。記憶サーバが、階層ファイル・システム内の１つまたは複数のサブディレクトリを担当してもよい。例えば、第１のサーバがパス／ｕｓｒ／ｓｔｏｎｅ／下のファイルおよびサブディレクトリの全てを管理してもよく、第２のサーバがパス／ｕｓｒ／Ｍｉｃｈａｅｌ／下のファイルおよびサブディレクトリの全てを管理してもよく、第３のサーバがパス／ｂｉｎ／下のファイルおよびサブディレクトリの全てを管理してもよい。当該実装により、第１のレベルのプレフィックス集約機構を可能としてもよい。当該機構において、／ｕｓｒ／ｓｔｏｎｅ／のようなプレフィックスが同一の名前のパス下のファイルおよびサブディレクトリを表してもよい。

代替的な実施形態では、記憶サーバが或る範囲のＤＨＴネーミング空間を管理してもよく、当該空間においてバイナリ０−１フラット・ネーミング記法を使用してもよい。図２は、バイナリ０−１フラット名キー値記憶ファイル・システム・ツリー２００内のプレフィックス・ベースのディレクトリ・グルーピングの１実施形態を示す。ファイル・システム２００が、これらのディレクトリ内に複数のディレクトリ、サブディレクトリ、およびファイルを含んでもよい。異なるディレクトリ・グルーピング２１０、２２０、２３０の各々が或る範囲のＤＨＴネーミング空間を管理してもよい。０−１フラット名空間をプレフィックスにより表してもよい。例えば、「０１０００１」が範囲［０１０００１００００、０１００１０００００］を表してもよい。さらなる例として、第１のサーバがホスト範囲００下のファイルおよびサブディレクトリの全てを管理してもよく、第２のサーバがホスト範囲０１下のファイルおよびサブディレクトリの全てを管理してもよく、第３のサーバがホスト範囲１下のファイルおよびサブディレクトリの全てを管理してもよい。

図１および図２の両方のファイル・システム・ツリーにより、ルーティング／スイッチング機能はサーバと対応するプレフィックスとの間のマッピングを知るだけでよくなる。したがって、当該システムの計算量をＯ（Ｎ_ｓｖｒ）に削減することができる。Ｎ_ｓｖｒはサーバの数である。典型的なパーソナル・コンピュータ・ベースのサーバは無数のファイルおよびオブジェクトを簡単に管理することができる。結果として、Ｎ_ｓｖｒは８乃至１０の規模でＮ_ｆ（ファイルの数）より小さいかもしれない。ブロック／セクタの数が図２の実施形態におけるキーとして実装される場合、当該キー値記憶部が従来型のストレージ・アクセス・ネットワーク（ＳＡＮ）として動作してもよい。

記憶サーバをそれに応じて割り当てると（例えば、図１のようなサーバ割当て）、サーバはそれが担当するプレフィックスを当該スイッチに通知してもよい。当該スイッチは通常、それが接続された第１のホップ・スイッチであってもよい。当該第１のホップ・スイッチが直接、当該メッセージを他のスイッチに転送してもよい。別の実施形態では、当該スイッチが、図２のバイナリ０−１フラット名ファイル・システムにおけるもののような集約をさらに実施してもよい。例えば、「００」のサーバと「０１」のサーバがたまたま同一のスイッチに接続されているかもしれない。この場合、当該スイッチが、「００」および「０１」を２つのルーティング・エントリとして発行するのではなく、集約されたプレフィックス「０」を他のスイッチに発行すると決定してもよい。

スイッチ内のＬＰＭモジュールが、従来型のＭＡＣまたはＩＰプレフィックス・ベースのルーティング／スイッチングに加えて、最長プレフィックス・マッチングに基づくルーティング／スイッチングを実行してもよい。例えば、クライアントが幾つかのコンテンツを要求してもよく、当該名前をＰＯＳＩＸファイル名またはバイナリ０−１フラット名であるかどうかに応じて、転送情報ベース（ＦＩＢ）でチェックしてもよい。ＦＩＢが、受信されたパケットを転送すべき宛先を決定するために転送テーブルを使用してもよい。当該最長プレフィックス・マッチング原理を使用して、出力ポートを発見してもよい。次いでＬＰＭスイッチがクライアント要求を正しいサーバに転送してもよい。長いプレフィックスのマッチにより、記憶システム・ネットワーク内の適切なサーバを発見する精度を高めることができる。

図３は、ＬＰＭスイッチ・ベースの記憶システム３００の１実施形態を示す。システム３００が、図３に示すようにネットワーク３２５で接続された複数のクライアント３１０、スイッチ１（ＳＷ１）３２０、スイッチ２（ＳＷ２）３２２、および複数のサーバ３３０を備えてもよい。２つのスイッチ３２０および３２２、３つのクライアント３１０、および３つのサーバ３３０のみが例示の目的のために示されているが、任意数の各コンポーネントをＬＰＭスイッチ・ベースのシステムで使用してもよい。ＬＰＭスイッチを、新たなコンポーネントとしてまたは既存のＥｔｈｅｒｎｅｔ（登録商標）スイッチもしくはＩＰルータを補完することによって構築してもよい。ネットワーク３２５が、ファイル・システム固有のＬＰＭシステムでありうる１つまたは複数のスイッチ（例えば、３２０、３２２）を備えてもよい。システム３００内の番号１乃至４がスイッチ３２０、３２２の入力／出力ポートを示してもよい。ポートが、入力機能と出力機能の両方を有してもよく、状況に応じて本明細書では入力ポートまたは出力ポートと称してもよい。クライアント３１０が、リモートのデータ記憶のニーズを有する装置上のアプリケーションであってもよい。当該装置が、例えば、デスクトップ・コンピュータ、タブレット、ラップトップ、またはスマート・フォンであってもよい。サーバ３３０が、ファイル・システム・ツリーの１つまたは複数のサブディレクトリをホストしてもよい。１つのサーバが、ルート・ディレクトリをホストしてもよい。表１は、サーバ３３０が異なるホスティングディレクトリに割り当てられるプレフィックス・ツリー割当ての１例を示す。

プレフィックスツリー割当てに従い、（例えば図３のスイッチ３２０、３２２のような）例示的なＬＰＭスイッチ上のＦＩＢを表２および３のように編成してもよい。表２および３はそれぞれ図３のＬＰＭスイッチ１３２０およびＬＰＭスイッチ２３２２に対応する。これらの転送テーブルから、ＬＰＭスイッチは、当該ファイルのプレフィックスに応じて、どの出力ポートにフレームを転送すべきかを知ることができる。

例えば、クライアント３１０はパス「／ｈｏｍｅ／ｄｆｓ／＊＊／＊＊／．」下の幾つかのファイルを求める要求をＳＷ１３２０に送信してもよく、ＳＷ１３２０は表２の転送情報に基づいて出力ポート４を選択してもよい。ポート４は当該表の中の他のプレフィックスと比べて、最長のプレフィックスを当該要求「／ｈｏｍｅ／ｄｆｓ／」と共有するので、ポート４を選択してもよい。当該転送に基づいて、当該要求は、ターゲット宛先（例えば、Ｓｖｒ＿Ｃ３３０）により近い１つのホップを取得することができる。次に、ＳＷ２３２２は、転送された要求をその入力ポート３を通じて受信してもよい。ＳＷ２３２２は、同一のＬＰＭ機構を使用して受信された要求を出力ポート４に転送してもよい。出力ポート４はターゲット宛先Ｓｖｒ＿Ｃ３３０に接続する。ターゲット・サーバはこの時点で当該要求に組込みのクライアント３１０のＭＡＣ／ＩＰアドレスで応答してもよい。サーバは、クライアントとの従来型の伝送制御プロトコル（ＴＣＰ）接続のような新たな接続を構築してもよい。クライアントおよびサーバの間で転送されるさらなるパケットが、この同一のセッション中にＬＰＭルックアップに関らなくてもよい。なぜならば、出力ポートの宛先が既に発見されているからである。

別の実施形態では、記憶システム３００が、ファイル記憶システムの実施形態に加えてキー値オブジェクト記憶を指してもよい。表４は、ＤＨＴキー値記憶シナリオに対するプレフィックスツリー割当てを表す。当該シナリオでは、サーバ３３０を異なるホスティング範囲に割り当ててもよい。表５および６は、それぞれ、ＬＰＭスイッチ１３２０およびＬＰＭスイッチ２３２２に対するＦＩＢを示す。ＳＷ１３２０が追加のプレフィックス集約を実施してもよい。当該集約が、表６から分かるようにＳＷ２３２２内のＦＩＢを簡略化してもよい。キー値オブジェクト記憶に対するＬＰＭ機構がファイル・システム記憶と同様に機能してもよい。

図４は、コンテンツを記憶サーバからＬＰＭスイッチを介して取り出すための方法３４０の１実施形態である。方法３４０を、ＬＰＭスイッチ３２０のようなＬＰＭスイッチで実施してもよい。ブロック３４５で、サーバ通知を受信してもよい。サーバ通知が、サーバが担当するディレクトリおよびサブディレクトリを含んでもよい。サーバ通知をＬＰＭスイッチ上のポートを介して受信してもよい。ブロック３５０で、様々なディレクトリ／サブディレクトリのプレフィックスをＦＩＢのようなメモリに記録してもよい。ブロック３４５および３５０を、完全なディレクトリ情報が取得されるまで複数のサーバの各々に対して実施してもよい。幾つかのサーバ通知を、ＬＰＭスイッチに直接取り付けられたサーバから直接受信してもよく、幾つかのサーバ通知を、他のＬＰＭスイッチを介してサーバから受信してもよい。ＦＩＢを構築した後、コンテンツに対するクライアント要求を受信してもよい。ブロック３５５で、クライアント要求を受信する。クライアント要求が、ファイル名および当該ファイル名に対応するディレクトリ情報を含むメッセージであってもよい。ブロック３６０で、当該ファイル名のフルパス情報を抽出する。ブロック３６５で、当該フルパス情報をＦＩＢと比較することによりＬＰＭを実施する。当該ＬＰＭの結果、クライアント要求がそれを通じて転送されるポート番号が生成される。ブロック３７０で、クライアント要求を、当該識別されたポート番号を介して送信してもよい。最後に、ブロック３７５で、当該要求されたファイルを、担当するサーバから受信し、要求側のクライアントに転送してもよい。当該要求されたファイルを、１つのデータパケットまたは複数のデータパケットを介して通信してもよい。

図５は、クライアント４０２、ＬＰＭスイッチ４０４、およびサーバ４０６の間のシグナリングの１実施形態を示すプロトコル図４００である。特に、プロトコル図４００は、スイッチを通じてデータをサーバから取得するためのユーザ要求に続くコンポーネント間の通信を示す。複数のかかるコンポーネントをネットワーク内で相互接続してもよい。図４００のコンポーネントをシステム３００のような記憶システムで実装してもよく、クライアント３１０、スイッチ３２０、３２２、およびサーバ３３０のようなコンポーネントを使用してもよい。データを、クライアント４０２、ＬＰＭスイッチ４０４、サーバ４０６の間のペイロードにおいて開放型システム相互接続（ＯＳＩ）レイヤ４プロトコル・データ単位（ＰＤＵ）で送信してもよい。当該ＯＳＩレイヤ４ＰＤＵがユーザ・ダイアグラム・プロトコル（ＵＤＰ）パケットまたは伝送制御プロトコル（ＴＣＰ）パケットであってもよい。

ＬＰＭスイッチでの送信中に、図４００のイベント・シーケンスを４１０で開始し、サーバ４０６の初期登録を行ってもよい。サーバ情報を含むＵＤＰパケットをＬＰＭスイッチ４０４により受信してもよい。その内容が、ペイロード内に配置されたディレクトリ・パスおよびファイル名を含んでもよいがこれらに限られない。ペイロード内のコンテンツは約２５６バイトであってもよい。

当該ＵＤＰパケットのペイロードから、インデックス・テーブル内のエントリを生成してもよい。当該エントリには、各ファイルに対応するインデックス（ＩＤＸ）、ポート番号、ＭＡＣ、ＩＰ、およびＴＣＰアドレスが含まれる。当該インデックスを識別子として使用してもよく、当該ポート番号が特定のサーバに配置されたポートを指してもよい。例えば、サーバＡ３３０に５個のファイルがある場合、当該ＩＤＸ値が当該ファイルごとに０から４の値であってもよい。同様に、当該ファイルの全てが同一のサーバ（例えば、サーバＡ３３０）の同一のポート番号（例えば、ポート２）に配置されている場合、当該ポート番号が当該ファイルの全てに対して２であってもよい。当該ＭＡＣ、ＩＰ、およびＴＣＰアドレスをパケット編集およびＯＳＩレイヤ４転送のためにインポートしてもよい。

表７は、特定のファイルに対するサーバ情報を含むインデックス・テーブルの例を示す。当該表の中の値は、ファイル要求から取得したインデックス、ポート、およびＭＡＣアドレスを例示する役割を果たす。

インデックス・テーブルの追加に続いて、セグメント・テーブル内のエントリをＵＤＰパケットのペイロードから生成してもよい。表８は、図示した値を有するかかるセグメント・テーブルの１例を示す。この表が、対応するＭＡＣアドレスに沿ってＬＰＭスイッチ側のポート番号を提供してもよい。ＳＷ−ＭＡＣが、スイッチ側に対するＭＡＣアドレスを表してもよく、Ｔ−ＭＡＣは最終宛先のターゲットのＭＡＣアドレスを表す。当該宛先がサーバまたはクライアントであってもよい。

さらに、ＬＰＭスイッチ４０４がサーバ登録中に文字列および／またはポート・ルックアップ・メモリをプロビジョニングしてもよい。当該文字列および／またはポート・ルックアップ・メモリのプロビジョニングがＢｌｏｏｍフィルタとともにハッシング・アルゴリズムを使用して、コンテンツ・データを変換し、当該ファイル名およびポート情報のサイズを削減してもよい。当該ハッシュ関数およびＢｌｏｏｍフィルタを使用して、文字列およびポート・ルックアップ情報を格納するときのメモリ空間の探索を削減してもよい。ｈａｓｈ（１）またはｈａｓｈ（１０）関数のような様々なハッシング・アルゴリズムを使用してもよい。１実施形態では、ハッシングによりペイロード・コンテンツのバイト数を２５６バイトから３バイトに減らしてもよい。

サーバ登録が完了した後、クライアントが、２つのパケット、即ち、ＵＤＰ要求およびＴＣＰ要求を内部的に生成する要求を発行してもよい。ＵＤＰ要求を４２０でクライアント４０２からＬＰＭスイッチ４０４に送信してもよい。当該ＵＤＰ要求が、ＬＰＭスイッチが既に登録したコンテンツ情報の一部（例えば、パスおよびファイル名）を運搬してもよい。（表７のような）インデックス・テーブル内のサーバ情報にＬＰＭスイッチによりアクセスして当該ＵＤＰ要求の宛先を決定してもよい。（インデックスとディレクトリの表を用いて）ＬＰＭを実施して、インデックス・テーブル内のインデックスを決定してもよい。宛先／出力ポートを、インデックス・テーブル内のインデックスに関連付けられたポートを検索することによって決定してもよい。宛先／出力ポートが決定されると、ＬＰＭスイッチはエントリをフロー・テーブルに作成することができる。当該エントリは、クライアントからサーバ（ＣＡＭ−ＣＳ）へのコンテンツ関連のメモリに関する情報を含んでもよい。同様に、ＬＰＭスイッチが、サーバからクライアントへのコンテンツ関連のメモリ（ＣＡＭ−ＳＣ）に関する別のエントリを別のフロー・テーブルに作成してもよい。

表９および１０はそれぞれ、ＣＡＭ−ＣＳおよびＣＡＭ−ＳＣに対するかかるフロー・テーブルの例を示す。ＳＭＡＣ、ＳＩＰ、およびＳＴＣＰにおける「Ｓ」はソースに対する具体的なアドレスを表し、ＤＭＡＣ、ＤＩＰ、およびＤＴＣＰにおける「Ｄ」は宛先に対応するアドレスを表す。デュアル・ポートのランダム・アクセス・メモリ（ＲＡＭ）値が、それぞれ、表９および１０における対応するサーバに対するインデックスとクライアントに対するポートを示してもよい。

１実施形態では、当該フロー・テーブルが一定数のビットと一定数のエントリを格納してもよい。例えば、１００ｘ３２のＣＡＭ−ＣＳフロー・テーブルが、夫々１００ビットである３２個のエントリを有するテーブルを示してもよく、一方、２００ｘ３２のＣＡＭ−ＳＣテーブルが、夫々２００ビットである３２個のエントリを有するテーブルを示してもよい。

表９および１０のフロー・テーブルは、上の表２、３、５、および６に示すＦＩＢと同様なＦＩＢの１例であってもよい。さらに、表９および１０のフロー・テーブルを、クライアントからサーバへのフローおよびその逆のフローに対するエントリを含む、１つの双方向フロー・テーブルに結合してもよい。

ＵＤＰ要求が送信された少し後（例えば、当該ＵＤＰ要求後数秒以内に）、ＴＣＰ要求を４３０でクライアント４０２から送信してもよい。ＬＰＭスイッチ４０４がＴＣＰパケットを受信し、ＯＳＩレイヤ４スイッチングを実施してもよい。例えば、当該スイッチが、当該ＵＤＰ要求から生成された対応するフロー・テーブルをチェックして、最長プレフィックス・マッチングを用いて当該パケットの宛先を決定してもよい。ターゲット・サーバ情報（例えば、出力ポート）を、表９のもののようなクライアント・サーバフロー・テーブル内のエントリに基づいて取得してもよい。ＬＰＭスイッチ４０４が、必要ならば当該ＴＣＰ要求を編集して、続いて取り出した情報に従って当該パケットをサーバ４０６に転送してもよい。

クライアント４０２のＴＣＰ要求を受信した後、サーバ４０６が、４４０で、当該要求された１つまたは複数のファイルを運搬する１つまたは複数のＴＣＰパケットの送信を介して応答してもよい。サーバ応答をＬＰＭスイッチ４０４に送信してもよい。ＬＰＭスイッチ４０４は、サーバ・クライアント・フロー・テーブル（例えば、表１０）をチェックして、コマンドまたは要求を発行した適切なクライアントに当該パケット（複数可）を転送してもよい。１実施形態では、ＬＰＭスイッチ４０４が、上述のようにサーバのＴＣＰ応答に対するＯＳＩレイヤ４スイッチングを行ってもよい。

図６は、最長プレフィックス・マッチング方法の１実施形態の流れ図５００である。流れ図５００のステップを、少なくとも１つのクライアントおよびサーバのような少なくとも１つのネットワーク記憶装置を有するデータ記憶システムで実装してもよく、一方で、当該システムを少なくとも１つのスイッチと相互接続してもよい。例えば、流れ図５００のブロックを、複数のクライアント３１０、複数のスイッチ３２０、３２２、および複数のサーバ３３０を備えたシステム３００のような記憶システム内のＬＰＭスイッチで実施してもよい。流れ図５００はブロック５１０で開始し、ＬＰＭスイッチ（例えば、図３のＬＰＭスイッチ３２０、３２２）が初期ＵＤＰパケットをサーバから受信してもよい。ブロック５２０で、ＬＰＭスイッチが、サーバ情報を当該ＵＤＰパケットから取得し、当該情報をインデックスおよびセグメント・テーブル内のエントリに登録してもよい。インデックス・テーブルおよびセグメント・テーブルを、将来のＴＣＰ要求の宛先に関するポート番号、ＩＤＸ値、ＭＡＣ、ＩＰ、およびＴＣＰアドレスで更新してもよい。次に、ブロック５３０で、ＬＰＭスイッチが文字列／ポート・ルックアップ・メモリを提供してもよい。ハッシュ関数および／またはＢｌｏｏｍフィルタを使用してバイト数を削減し、メモリ内の空間を節約してもよい。

サーバ登録の後、当該方法はブロック５４０で継続し、ＬＰＭスイッチはクライアントからの要求をＵＤＰパケットの形で受信してもよい。当該要求が、要求されたファイルと、当該ファイルに対するディレクトリまたはパス名を含んでもよい。ブロック５５０で、ＬＰＭスイッチが続いてフロー・エントリを対応するＦＩＢまたはフロー・テーブルに生成してもよい。１つのフロー・エントリが、パケットをクライアントからサーバに転送するための出力ポートに関する位置を含んでもよい。別のフロー・エントリを、クライアントに転送するためのパケットをサーバから受信する際に入力ポートが利用するために作成してもよい。これらのエントリを、表９および１０のようなＣＡＭ−ＣＳおよびＣＡＭ−ＳＣフロー・テーブルに作成してもよい。さらに、別々のＦＩＢテーブルのエントリを１つのテーブルに結合して、クライアントからサーバへおよびサーバからクライアントへのパケットの双方向のフローを可能としてもよい。

次に、ブロック５６０で、ＬＰＭスイッチがＴＣＰパケットをクライアントから受信してもよい。ブロック５７０で、ＬＰＭスイッチがフロー・テーブルを使用してパケット用の出力ポートを決定してもよい。ＬＰＭスイッチが次いで、ブロック５８０の受信パケットを、識別した出力ポートを介してターゲット・サーバに転送してもよい。当該方法は、ＬＰＭスイッチがブロック５９０でサーバのＴＣＰ応答を受信しクライアントに送信することで終了する。当該ＴＣＰ応答が、クライアントにより要求されたファイルを備えてもよい。ＬＰＭスイッチが、フロー・テーブル内のフロー・エントリに基づいて、どのクライアントに当該パケットを転送するかを判定してもよい。

クライアントの要求が適切な記憶サーバに到着するために、スイッチが、プレフィックスと出力ポートの間のマッピングを知る必要があってもよい。次いで、最長プレフィックス・マッチングを、クライアント要求およびＦＩＢの間のスイッチを用いて実行してもよい。ＬＰＭスイッチが、取出す必要があるファイルのディレクトリ名と当該ＦＩＢのエントリの間の最長プレフィックス・マッチングを実施してもよい。当該最長プレフィックス・マッチング自体を、任意の従来型の最長プレフィックス・マッチングアルゴリズムを用いて実施してもよい。本明細書で説明するように、Ｂｌｏｏｍフィルタおよびハッシュ関数を使用して、最長プレフィックス・マッチングを実装してもよい。ＬＰＭスイッチが、２つの新たなＦＩＢ、即ち、ＰＯＳＩＸファイル・システム内の＜ディレクトリ／サブディレクトリのプレフィックス、次の出力ポート＞およびバイナリ０−１フラット名キー値記憶ファイル・システム内の＜０−１の列から成るプレフィックス、次の出力ポート＞のうち少なくとも１つを実装してもよい。クライアントが要求を行うと、当該名前が、ＰＯＳＩＸファイル・システム内のファイルに対するパス、または、キー値記憶内のオブジェクトに対するバイナリ０−１フラット名であってもよい。ＬＰＭスイッチが当該要求を取得し、それに応じてＦＩＢをチェックし、どのエントリが最長プレフィックスを当該要求と共有するかを決定してもよい。次いで、当該要求を適切な出力ポートに転送してもよい。別の実施形態では、ＬＰＭスイッチングを、同様にＤＨＴキー値記憶に対して実装してもよい。

さらなる例として、ＬＰＭスイッチが要求取得モジュールおよび最長プレフィックス・マッチング・モジュールを備えてもよい。当該要求取得モジュールが、クライアントの要求およびサーバの通知または応答を処理してもよい。要求を行う前に、クライアントがどのサーバと連絡すればよいか知らないかもしれない。要求を、ＬＰＭスイッチにより所望の宛先で認識できる仮想アドレスに送信してもよい。当該要求をＬＰＭスイッチにより認識し解釈できる限り、要求を送信するための他の方法を実装してもよい。クライアントが、特定の要求に関して連絡すべきサーバの正確な位置を知らないかもしれない。しかし、ＬＰＭスイッチは、要求ごとにクライアントを適切なサーバに接続するインテリジェンスを有することができる。これにより、クライアント側は、分散システムをローカル・システムとみなすことができる。なぜならば、サーバ・クラスタの分散特性を、相互接続されたＬＰＭスイッチのネットワークにより隠蔽できるからである。組込みの名前でクライアント要求を受信した後、当該モジュールは、コンテンツ名を抽出し、対応するＦＩＢでＬＰＭを開始してもよい。別の実施形態では、ＬＰＭスイッチの要求取得モジュールは、サーバ応答のためにサーバをクライアントに接続してもよい。クライアント要求をどの出力ポートに転送するかに関するフロー・エントリがＦＩＢ内に作成されたとき、追加のフロー・エントリをサーバからクライアントへの応答に対して生成してもよい。サーバ通知に関して、当該スイッチが、プレフィックスと、当該通知がそこからＦＩＢに入るポートとを記録してもよい。

本発明で説明した機能／方法の少なくとも一部をネットワーク要素で実装してもよい。例えば、本発明の機能／方法を、ハードウェア、ファームウェア、および／またはハードウェアで実行するようにインストールされたソフトウェアを用いて実装してもよい。当該ネットワーク要素が、ネットワーク、例えば、スイッチ、ルータ、ブリッジ、サーバ、クライアント等を通じてデータを伝送する任意の装置であってもよい。図７は、ＬＰＭスイッチ６００の１実施形態を示す。ＬＰＭスイッチ６００が、ネットワークを通じてデータを伝送し処理する任意のネットワーク要素であってもよい。例えば、ＬＰＭスイッチ６００は、上述の最長プレフィックス・マッチング機構を実装するコンテンツ・ルータまたは任意の装置またはスイッチであってもよい。ＬＰＭスイッチ６００を、上述の記憶サーバ割当て、プレフィックス集約、および最長プレフィックス・マッチングの戦略を実装またはサポートするように構成してもよい。

ＬＰＭスイッチ６００が、送受信器（Ｔｘ／Ｒｘ）６１２に接続された１つまたは複数のポートまたは面６１０を備えてもよい。送受信器６１２が送信器および受信器を備えてもよい。送受信器６１２を、フレームを送信し、かつ／または、フレームを他のノードから受信するためのポート６１０に接続してもよい。１つの送受信器６１２を、メッセージをサーバから受信しサーバに送信するための分散記憶システム内のサーバに接続してもよい。例えば、１つの送受信器６１２を、ブロック３４５、３７０、および／または５１０を実施し、ブロック３７５で説明したようにコンテンツを転送し、かつ／または、図５に示すようにサーバ４０６との通信を実施するように構成してもよい。第２の送受信器６１２を、メッセージをクライアントから受信しクライアントに送信するために当該クライアントに接続してもよい。例えば、第２の送受信器６１２を、ブロック３５５を実施するか、または、図５に示すようにクライアント４０２との通信を実施するように構成してもよい。

プロセッサ６２５を、送受信器６１２に接続して、フレームを処理し、かつ／または、フレームを送信すべきノードを決定してもよい。プロセッサ６２５が、要求取得モジュール６２７、ＬＰＭモジュール６２８、およびメモリ・モジュール６２２を有する１つまたは複数のマルチ・コアプロセッサを備えてもよい。要求取得モジュール６２７が、クライアントおよび／またはサーバからの要求の認識および取得のような、ＬＰＭスイッチの上述の性質を実装してもよい。要求または応答を送信するために、モジュール６２７が、サーバをクライアントに接続するかまたはその逆を行ってもよい。ＬＰＭモジュール６２８が、メモリ・モジュール６２２を利用しつつ最長プレフィックス・マッチングに基づいてルーティング／スイッチングを行ってもよい。メモリ・モジュール６２２は、データ記憶、バッファ等として機能してもよい。プロセッサ６２５を、中央演算装置（ＣＰＵ）チップ、コア（例えば、マルチ・コアプロセッサ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特殊用途向け集積回路（ＡＳＩＣ）、および／またはデジタル信号プロセッサ（ＤＳＰ）のうち１つまたは複数として実装してもよい。ポート６１０は、電気的および／または光学的な送信および／または受信のコンポーネントを含んでもよい。ＬＰＭスイッチ６００が、ルーティング判定を行うルーティング・コンポーネントであってもよい。

メモリ・モジュール６２２が、キャッシュ、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、または二次記憶、またはそれらの任意の組合せのような、データを格納するための任意の装置であってもよい。二次記憶は一般に、１つまたは複数のディスク・ドライブまたはテープ・ドライブを備え、データの不揮発性記憶に使用され、ＲＡＭが全ての動作データを保持するのに十分に大きくない場合にはオーバフロー・データ記憶装置として使用される。二次記憶を使用して、実行のために選択するときにＲＡＭにロードされるプログラムを記憶してもよい。ＲＯＭは、プログラム実行中に読み出される命令およびおそらくはデータを格納するために使用される。ＲＯＭは、二次記憶の大メモリ容量に対して一般に小さいメモリ容量を有する不揮発性メモリ装置である。ＲＡＭは、揮発性データを格納し、おそらくは命令を記憶するために使用される。ＲＯＭとＲＡＭの両方へのアクセスは一般に二次記憶に対するものよりも高速であり、キャッシュへのアクセスは一般に任意のおよび他の種類のメモリより高速である。マッピング情報を、メモリ・モジュール６２２の転送情報ベース（ＦＩＢ）６２４で維持してもよい。ＦＩＢ６２４を、ＬＰＭ方法におけるセグメント、インデックス、文字列および／またはポート・ルックアップ・メモリ、およびフロー・テーブル（例えば、図６）のようなサーバ情報を格納するために使用してもよい。

実行可能命令をプログラムしかつ／またはＬＰＭスイッチ６００にロードすることによって、プロセッサ６２５およびメモリ６２２の少なくとも１つが変更され、部分的にＬＰＭスイッチ６００が特定のマシンまたは装置、例えば、本明細書で教示した新規な機能を有するマルチ・コア転送アーキテクチャに変換されることは理解される。実行可能ソフトウェアをコンピュータにロードすることで実装できる機能を公知な設計規則によりハードウェア実装に変換できることは、電気工学やソフトウェア工学にとって基本的である。ソフトウェアで実装することとハードウェアで実装することとの間の決定は一般に、ソフトウェア領域からハードウェア領域への変換に関与する任意の問題ではなく、設計の安定性と生成されるユニットの数の考慮に依存する。一般に、頻繁な変更を依然として受ける設計は、ソフトウェアで実装されるのが好ましいかもしれない。なぜならば、ハードウェア実装を再検討するのはソフトウェア設計を再検討するよりも高価であるからである。一般に、大量生産に適した設計はハードウェア、例えば、ＡＳＩＣで実装されるのが好ましいかもしれない。なぜならば、大量生産では、ハードウェア実装がソフトウェア実装より高価でないかもしれないからである。しばしば、設計がソフトウェア形式で開発され試験され、後に、公知な設計規則により、ソフトウェアの命令を組み込んだ特殊用途向け集積回路における均等なハードウェア実装に変換されるかもしれない。同様に、新たなＡＳＩＣにより制御されるマシンは特定のマシンまたは装置であるので、同様に、プログラムされかつ／または実行可能命令をロードしたコンピュータも特定のマシンまたは装置とみなしてもよい。

図８は、ＸＩＬＩＮＸＶＩＲＴＥＸ−５ＦＰＧＡのようなフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）チップで実装されたＬＰＭスイッチ７００の１実施形態のブロック図を示す。チップ７００が、先入れ先出し（ＦＩＦＯ）入力７０２、パケット・アナライザ７０４、ＬＰＭ文字列／ポート・ルックアップ・ブロック７０６、Ｌ４スイッチング・ブロック７１２、およびＦＩＦＯ出力７１４を備えてもよい。送信中に、ＦＰＧＡチップ７００がパケットを入力７０２で受信してもよく、各パケットのコンテンツをパケット・アナライザ７０４によりアクセスしてもよい。ＬＰＭ文字列／ポート・ルックアップ・ブロック７０６が、図５で説明したように、プレフィックス・マッチング方法をパケット・コンテンツに対して実施してもよい。ファイルごとのＭＡＣ、ＩＰ、およびＴＣＰアドレスおよびポート番号を対応する表で文書化してもよい。ＬＰＭ文字列／ポート・ルックアップ・ブロック７０６がさらに、ルール・テーブル７０８およびフロー・テーブル７１０を備えてもよい。ルール・テーブル７０８を使用して、フロー・テーブルに対するソース情報を抽出してもよく、当該フロー・テーブルが、クライアント・サーバおよびサーバ・クライアントのフローに関するエントリを含んでもよい。Ｌ４スイッチング・ブロック７１２が、フロー検索、パケット編集、ＬＰＭスイッチにより受信されたものの転送を行ってもよい。次いで、当該パケットを、ＦＩＦＯ出力７１４を介してその宛先に送信してもよい。１実施形態では、ＬＰＭスイッチ７００をＮｅｔＦＰＧＡカード上に実装してもよい。

図９は、汎用コンピュータシステムで実装されたＬＰＭスイッチ８００の１実施形態の略図である。システム８００が、中央演算装置（ＣＰＵ）８０２、ネットワーク・インタフェース・コントローラ（ＮＩＣ）８０４、グラフィック処理ユニット（ＧＰＵ）８０６、ＧＰＵランダム・アクセス・メモリ（ＲＡＭ）８０８、メインＲＡＭ８１０、およびローカル・バス８１６を備えてもよい。メインＲＡＭ８１０がさらにメイン・メモリ・バッファ（ｍｂｕｆ）８１２およびＧＰＵメモリ・バッファ（ｇｂｕｆ）８１４を備えてもよい。メイン・バッファ８１２をＣＰＵ・ベースの処理に使用してもよく、ＧＰＵメモリ・バッファ８１４をＧＰＵ・ベースの処理に使用してもよい。ＣＰＵ８０２がＩＮＴＥＬコア（Ｉコア）８１８を備えてもよい。

さらに、ＬＰＭスイッチ（例えば、スイッチ３２０、３２２）を、アクセス制御リスト（ＡＣＬ）、ポリシ・ベース・ルーティング（ＰＢＲ）、およびＯｐｅｎＦｌｏｗセットアップで実装してもよい。これらの構成に関して、サーバが、従来型のＥｔｈｅｒｎｅｔ（登録商標）スイッチをそのままに保ちつつ、ＰＯＳＩＸファイル・システム名および／またはＤＨＴフラット名に対して追加のＬＰＭを実施してもよい。クライアント（例えば、クライアント３１０）が、要求を仮想の特定アドレス（例えば、ＩＰ、ＭＡＣ、またはＶＬＡＮＩＤ）に送信してもよい。次いで、当該スイッチが要求されたパケットを特定し、当該ＬＰＭサーバ（例えば、サーバ３３０）に転送できてもよい。

サーバの過負荷を防止するため、負荷分散機構を、システム３００のようなＬＰＭスイッチ・ベースのシステムで実装してもよい。作業負荷は動的に変化しうるので、プレフィックス集約を保ちつつ、データを複数のサーバの間で拡散してもよい。ノードが潜在的な過負荷に遭遇した場合、ノードは一部のサブディレクトリまたは部分範囲を他のサーバにオフロードまたは移動させてもよい。このマイグレーションが完了すると、新たなサーバがその新たな通知を発行してもよい。当該潜在的に過負荷のサーバは、「距離」の優先度に基づいてオフロード・サーバの候補を選択する。当該距離は、候補とそれ自体の間のホップ数を指す。例えば、サーバＡ３３０が、その作業負荷の一部を別のサーバにオフロードしたいかもしれない。サーバＡ３００は先ず、そのコンテンツの一部を、サーバＢとサーバＣの両方が適格でありオフロードに利用可能であるとしても、サーバＣでなくサーバＢに移動してもよい。負荷分散におけるサーバＡのサーバＢに対する優先は主に、サーバ間の減少した距離およびより少ないホップ数に起因するものである。

このホップ・ベースのマイグレーション優先機構により、ＬＰＭスイッチにより行われた潜在的なプレフィックス集約によりＦＩＢの安定性を高めることができる。上述の例では、どれだけ多くのサーバＡのサブディレクトリまたは部分範囲がサーバＢに移動されても、ＳＷ１のＦＩＢを除いて任意のＦＩＢを更新する必要がなくともよい。したがって、リップルを更新するＦＩＢを局所領域に制限してもよい。この時点で、ＦＩＢの計算量をＯ（Ｎ_ｓｗ）に軽減することができる。Ｎ_ｓｗはスイッチの数である。幾つかの適用では、Ｎ_ｓｗがＮ_ｓｖｒのほほ１５分の１であってもよい。このマイグレーションの間、オリジナル・サーバが依然として要求をその担当するディレクトリまたは範囲に送信してもよい。このマイグレーションの後、サーバが、どのサーバに暫くオフロードするかの記録を保持してもよい。ＦＩＢが適時に更新されなかった場合には、サーバが、移動されたファイルに対する要求を受信してもよい。この場合、サーバが当該要求を新たなホストに転送してもよく、当該ホストで、着目するファイルを取り出してもよい。

図１０は、記憶システム３００のような記憶システム内の負荷分散方法８５０の１実施形態の流れ図である。方法９００をサーバ３３０のようなサーバで実装してもよい。ブロック８５５で登録メッセージまたは通知が送信される。当該登録メッセージが、サーバが担当する分散記憶システム内のディレクトリの指示を提供してもよい。当該登録メッセージが、前述したもの、例えば、ブロック５１０またはブロック３４５に関して説明したものであってもよい。ブロック８６０でサーバの負荷を測定してもよい。当該負荷が、例えば、所定の時間間隔でのメモリ要求数またはサーバに接続された線で消費された帯域幅の測定値であってもよい。ブロック８６５で、当該負荷が所定の閾値を超えるかどうかを判定する。当該負荷が当該閾値を超えない場合、ブロック８６０を後の時点で繰り返してもよい。当該負荷が閾値を超える場合、当該方法はブロック８７０に進み、方法８５０を実行するサーバの１ホップ以内でサーバが選択される。当該負荷が閾値を超える場合、これは、サーバが担当するファイルの一部を別のサーバに転送すべきという指示である。次にブロック８７５で、ディレクトリ・ツリーの一部を選択されたサーバに移動して、方法８５０を実行するサーバの負荷を削減する。また、ブロック８７５で、メッセージを最近傍のＬＰＭスイッチに送信して、当該ディレクトリ・ツリーの一部の転送に基づいてそのＦＩＢテーブルを更新するようにＬＰＭスイッチに指示する。

図１１はサーバ９００の１実施形態の略図である。サーバ９００は、二次記憶９０４、読取り専用メモリ（ＲＯＭ）９０６、ランダム・アクセス・メモリ（ＲＡＭ）９０８を含むメモリ装置と通信するプロセッサ９０２（ＣＰＵと称してもよい）と、送受信器９１２とを備える。プロセッサ９０２を、１つまたは複数のＣＰＵチップ、コア（例えば、マルチ・コアプロセッサ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特殊用途向け集積回路（ＡＳＩＣ）、および／もしくはデジタル信号プロセッサ（ＤＳＰ）として実装してもよく、かつ／または、１つまたは複数のＡＳＩＣの一部であってもよい。プロセッサ９０２が、負荷分散機構におけるサーバ割当ておよびプレフィックス集約を実装してもよく、または、これらを実施するように構成してもよい。

二次記憶９０４は一般に、１つまたは複数のディスク・ドライブまたはテープ・ドライブから構成され、データの不揮発性記憶に使用され、ＲＡＭ９０８が全ての動作データを保持するのに十分に大きくない場合にはオーバフロー・データ記憶装置として使用される。二次記憶９０４を使用して、実行のために選択するときにＲＡＭ９０８にロードされるプログラムを記憶してもよい。ＲＯＭ９０６は、プログラム実行中に読み出される命令およびおそらくはデータを格納するために使用される。ＲＯＭ９０６は、二次記憶９０４の大メモリ容量に対して一般に小さいメモリ容量を有する不揮発性メモリ装置である。ＲＡＭ９０８は揮発性データを格納し、おそらくは命令を記憶するために使用される。ＲＯＭ９０６およびＲＡＭ９０８の両方に対するアクセスは一般に二次記憶９０４に対するものよりも高速である。ＲＡＭ９０８および二次記憶９０４を結合して、図１および２で説明したようなディレクトリ構造にファイルを格納してもよい。サーバ９００が、図３のサーバ３３０の機能および／または方法８５０を実装してもよい。

送受信器９１２が、サーバ９００の出力および／または入力装置の役割を果たしてもよく、送受信器９１２がさらに送信器、受信器、またはそれらの組合せを備えてもよい。送受信器９１２が、モデム、モデム・バンク、Ｅｔｈｅｒｎｅｔ（登録商標）カード、ユニバーサル・シリアル・バス（ＵＳＢ）インタフェース・カード、シリアル・インタフェース、トークン・リング・カード、ファイバ分散データ・インタフェース（ＦＤＤＩ）カード、無線ローカル・エリア・ネットワーク（ＷＬＡＮ）カード、符号分割多重アクセス（ＣＤＭＡ）、グローバル移動体通信ステム（ＧＳＭ（登録商標））、ロングターム・エボリューション（ＬＴＥ）、ワールドワイド・インターオペラビリティ・フォー・マイクロウェーブ・アクセス（ＷｉＭＡＸ）、および／または他のエア・インタフェース・プロトコル無線送受信器カードのような無線送受信器カード、および他の周知なネットワーク装置の形態をとってもよい。送受信器９１２により、プロセッサ９０２がインターネットおよび／または１つまたは複数のイントラネットおよび／または１つまたは複数のＬＰＭスイッチと通信できてもよい。実行可能命令をプログラムしかつ／またはサーバ９００にロードすることによって、プロセッサ９０２、ＲＯＭ９０６、およびＲＡＭ９０８の少なくとも１つが変更され、部分的にサーバ９００が本明細書で教示した新規な機能を有する負荷分散サーバのような特定のマシンまたは装置に変換されることは理解される。

少なくとも１つの実施形態が開示され、当業者が行う当該実施形態（複数可）および／または当該実施形態（複数可）の機能の変形、組合せ、および／または修正は本開示の範囲内にある。当該実施形態（複数可）の機能を結合、統合、および／または省略したことから生ずる代替的な実施形態も本開示の範囲内にある。数値的な範囲または限定を明示的に述べたが、かかる明示的な範囲または限定が、明示的に述べた範囲または限定に入る同様な規模の反復的な範囲または限定を含むと理解してもよい（例えば、約１から約１０とは２、３、４等を含み、０．１０より大きいとは０．１１、０．１２、０．１３等を含む）。例えば、下限がＲ_ｌで上限がＲ_ｕである数値範囲が開示される場合は常に、当該範囲に入る任意の数が具体的に開示される。特に、当該範囲内の以下の数が具体的に開示される。即ち、Ｒ＝Ｒ_ｌ＋ｋ＊（Ｒ_ｕ−Ｒ_ｌ）である。ｋは１パーセントの増分で１パーセントから１００パーセントまで変動する変数である。即ち、ｋは１パーセント、２パーセント、３パーセント、４パーセント、５パーセント、・・・、５０パーセント、５１パーセント、５２パーセント、・・・、９５パーセント、９６パーセント、９７パーセント、９８パーセント、９９パーセント、または１００パーセントである。さらに、上で定義した２つのＲ個の数で定義された任意の数値範囲も具体的に開示されている。「約」という用語の使用は、特に断らない限り、それに続く数値の＋／−１０％を意味する。請求項の任意の要素に関する「場合によっては」という用語は、当該要素が必要であること、または、当該要素が必要でないことを意味し、両方の代替物が当該請求項の範囲内にある。備える、含む、および有するといった広い用語の使用は、〜から構成される、〜から本質的に構成される、および〜から実質的に成るといった狭い用語に対するサポートを提供すると理解してもよい。したがって、保護範囲は、上述の説明により制限されないが、添付の諸請求項により定義され、その範囲は、諸請求項の発明特定事項の全ての均等物を含む。夫々および全ての請求項は、さらなる開示として本明細書に組み込まれ、諸請求項は本発明の実施形態（複数可）である。本開示における文献の議論は、それが先行技術、特に、公開日が本願の優先日より後の任意の文献であると認めるものではない。本明細書で引用した全ての特許、特許出願、および刊行物の開示は、それらが本明細書を補完する、例示的な、手続き的な、または他の詳細を提供する範囲において、引用により取り込まれる。

幾つかの実施形態を本発明で提供したが、開示したシステムと方法を、本発明の趣旨または範囲から逸脱しない他の多数の具体的な形態で具体化してもよいことは理解される。本明細書の例は、例示的であり限定的なものではないと考えるべきであり、本発明は本明細書で与えた詳細に限定されない。例えば、様々な要素またはコンポーネントを組み合せるかもしくは別のシステムに統合してもよく、または、特定の機能を省略するかまたは実装しなくともよい。

さらに、様々な実施形態において別個または別々に説明し例示した技術、システム、サブシステム、および方法を、本発明の範囲から逸脱することなく組み合わせるかまたは他のシステム、モジュール、技術、もしくは方法と統合してもよい。互いに接続または直接接続または通信するとして図示または説明された他の項目を、電気的、機械的、またはそれ以外に関わらず、何らかのインタフェース、装置、または中間構成要素を通じて間接的に接続するかまたは通信させてもよい。変更、置換え、または代替の他の例は当業者により確認でき、本発明で開示した趣旨と範囲から逸脱せずに行うことができる。

４０２クライアント
４０４ＬＰＭスイッチ
４０６サーバ
６００ＬＰＭスイッチ
６１０ポート
６２２メモリ
６２５プロセッサ
６２７要求取得モジュール
６２８ＬＰＭモジュール
７００ＬＰＭスイッチ
７０２入力ＦＩＦＯ
７０４パケット分析器
７０６ＬＰＭ文字列／ポート検索
７０８ルール・テーブル
７１０フロー・テーブル
７１２Ｌ４スイッチング
７１４出力ＦＩＦＯ
８１０メインＲＡＭ
８１６ローカル・バス
９０２プロセッサ
９０４二次記憶
９１２送受信器

Claims

スイッチにより実施される方法であって、
複数のサーバ通知を分散記憶システム内の複数のサーバから前記スイッチ内の複数のポートを介して受信するステップであって、前記サーバ通知は記憶のために各サーバに割り当てられたディレクトリのプレフィックスを含む、ステップと、
転送情報ベース（ＦＩＢ）を前記サーバ通知から構築するステップであって、前記ＦＩＢは前記ポートに対応する前記ディレクトリのプレフィックスを示す、ステップと、
ファイルに対する要求をクライアントから受信するステップであって、前記ファイルは分散記憶システムに配置されているステップと、
要求された前記ファイルのディレクトリを前記要求から抽出するステップと、
要求された前記ディレクトリの最長プレフィックス・マッチング（ＬＰＭ）を前記ＦＩＢに対して実施して、前記要求されたディレクトリに対応するポートを識別するステップであって、ハッシュ関数が前記ディレクトリのプレフィックスの各々をバイナリ・シーケンスに関連付けるために使用され、前記ＦＩＢは前記ディレクトリのプレフィックスを前記ポートに前記ハッシュ関数を介して関連付け、ＬＰＭを実施するステップは、前記ハッシュ関数を用いて前記要求されたディレクトリをハッシュして要求されたバイナリ・シーケンス値を生成するステップを含む、ステップと、
前記要求されたバイナリ・シーケンス値のＬＰＭを前記ＦＩＢに対して実施して前記要求されたディレクトリに対応するポートを識別し、前記クライアントの要求を、前記ファイルを含むサーバに前記識別されたポートを介して転送し、前記クライアントの要求に応答して、前記ファイルを前記サーバから前記識別されたポートを介して受信し、前記ファイルを前記クライアントに転送するステップと、
を含む、方法。
スイッチであって、
サーバ通知を分散記憶システム内のファイルを含むサーバから受信するように構成されたポートであって、前記サーバ通知は記憶のために前記サーバに割り当てられたディレクトリのプレフィックスを含む、ポートと、
前記サーバ通知を受信する前記ポートに対応する前記サーバに割り当てられた前記ディレクトリのプレフィックスを示す転送情報ベース（ＦＩＢ）を含む、メモリと、
前記サーバ通知から前記ＦＩＢにデータ投入し、
前記ファイルに対する要求をクライアントから取得し、
前記ファイルの要求されたディレクトリを前記要求から抽出し、
前記要求されたディレクトリの最長プレフィックス・マッチング（ＬＰＭ）を前記ＦＩＢに対して実施して、前記ファイルを含む前記サーバに対応するポートを識別する、
ように構成されたプロセッサであって、ハッシュ関数が前記ディレクトリのプレフィックスの各々をバイナリ・シーケンスに関連付けるために使用され、前記ＦＩＢは前記ディレクトリのプレフィックスを前記ポートに前記ハッシュ関数を介して関連付け、ＬＰＭを実施することは、前記ハッシュ関数を用いて前記要求されたディレクトリをハッシュして要求されたバイナリ・シーケンス値を生成することと、前記要求されたバイナリ・シーケンス値のＬＰＭを前記ＦＩＢに対して実施して前記要求されたディレクトリに対応するポートを識別することを含む、プロセッサと、
前記プロセッサに接続され、前記クライアントの要求を、前記ファイルを含むサーバに前記識別されたポートを介して転送するように構成された送信器と、
前記クライアントの要求に応答して、前記ファイルを前記サーバから前記識別されたポートを介して受信するように構成された受信器と、
前記ファイルを前記クライアントに転送するように構成された第２の送信器と、
を備えた、スイッチ。
複数のユーザ・ダイアグラム・プロトコル（ＵＤＰ）登録メッセージを分散記憶システム内の複数のサーバからスイッチ内の複数のポートを介して受信するステップであって、各ＵＤＰ登録メッセージは、前記サーバが担当する少なくとも１つのディレクトリを含む、ステップと、
ポートと、対応するディレクトリに対する対応する担当サーバとを関連付けるインデックス・テーブルを生成するステップと、
ＵＤＰ要求をクライアントから受信するステップであって、前記ＵＤＰ要求は要求されたファイルと前記ファイルのディレクトリに関する情報を含むステップと、
前記ファイルのディレクトリの最長プレフィックス・マッチング（ＬＰＭ）を前記インデックス・テーブルに対して実施して、前記要求されたファイルに対する前記担当サーバに対応するポートを決定するステップであって、ハッシュ関数が前記ディレクトリのプレフィックスをバイナリ・シーケンスに関連付けるために使用され、前記インデックス・テーブルは、前記ディレクトリのプレフィックスを前記ポートに前記ハッシュ関数を介して関連付け、ＬＰＭを実施するステップは、前記ハッシュ関数を用いて前記ディレクトリをハッシュして、要求されたバイナリ・シーケンス値を生成するステップと、前記要求されたバイナリ・シーケンス値のＬＰＭを前記インデックス・テーブルに対して実施して前記ディレクトリに対応するポートを識別するステップとを含む、ステップと、
前記クライアントと、前記担当サーバに対応するポートとを関連付けるフロー・テーブルにエントリを生成するステップと、
第２のクライアント要求に応答して、前記要求されたファイルの少なくとも一部を前記担当サーバから前記識別されたポートを介して受信するステップと、
前記要求されたファイルの一部を前記クライアントに転送するステップと、
を含む、方法。
伝送制御プロトコル（ＴＣＰ）要求を前記クライアントから受信するステップと、
前記ＴＣＰ要求を受信したことに応答して前記ポートを前記フロー・テーブルから検索するステップと、
前記ＴＣＰ要求をサーバに前記ポートを介して転送するステップであって、前記サーバは分散記憶システム内の複数のサーバの１つであり、前記サーバは前記要求されたファイルを格納するステップと、
をさらに含む、請求項３に記載の方法。
ＴＣＰ応答を前記サーバから受信するステップであって、前記ＴＣＰ応答は前記要求されたファイルの少なくとも一部を含むステップと、
前記ＴＣＰ応答を前記クライアントに転送するステップと、
をさらに含む、請求項４に記載の方法。
ユーザ・ダイアグラム・プロトコル（ＵＤＰ）登録メッセージを前記サーバから前記ポートを介して受信するステップであって、前記登録メッセージは前記サーバが担当する少なくとも１つのディレクトリを含むステップと、
前記ポートを前記少なくとも１つのディレクトリに関連付ける前記インデックス・テーブルに少なくとも１つのエントリを生成するステップと、
をさらに含む、請求項３または４に記載の方法。
ＵＤＰ登録メッセージを前記複数のサーバ内の残りのサーバの各々から受信するステップであって、前記ＵＤＰ登録メッセージの各々は対応するサーバが担当するディレクトリを含むステップと、
前記インデックス・テーブルの残りを前記ＵＤＰ登録メッセージから生成するステップと、
をさらに含む、請求項６に記載の方法。
前記インデックス・テーブルの残りを生成するステップは、ハッシュ関数を用いて前記ディレクトリをハッシュして各ディレクトリに対応するバイナリ文字列を生成し、前記バイナリ文字列を前記インデックス・テーブルに格納するステップを含む、請求項７に記載の方法。
分散記憶システムにおけるサーバ内の方法であって、前記サーバはディレクトリ・ツリーの一部を格納し、前記方法は、
負荷を測定するステップと、
前記負荷が閾値より大きいと判定するステップと、
最近傍のサーバを前記ディレクトリ・ツリーの前記一部の第１の部分の受信者として選択するステップと、
前記第１の部分を前記最近傍のサーバに転送するステップと、
前記第１の部分が送信されたことを示すメッセージを最近傍の最長プレフィックス・マッチング（ＬＰＭ）スイッチに送信するステップと、
を含む、方法。
前記負荷は或る期間におけるファイルに対する要求の数であり、前記負荷を測定するステップは、前記期間における要求の数を計数するステップを含む、請求項９に記載の方法。
前記分散記憶システムは複数のサーバを含み、前記ディレクトリ・ツリーは前記複数のサーバで分散され、前記サーバは前記複数のサーバ内にある、請求項９または１０に記載の方法。
前記サーバが前記ディレクトリ・ツリーの前記一部を格納することを示す登録メッセージを前記最近傍のＬＰＭスイッチに送信するステップをさらに含む、請求項１１に記載の方法。
ユーザ・ダイアグラム・プロトコル（ＵＤＰ）登録メッセージを分散記憶システム内の複数のサーバからスイッチ内の複数のポートを介して受信し、
ＵＤＰ要求をクライアントから受信する
ように構成された送受信器であって、前記ＵＤＰ登録メッセージは、前記サーバが担当する少なくとも１つのディレクトリを含み、前記ＵＤＰ要求は要求されたファイルと前記要求されたファイルのディレクトリに関する情報を含む１つまたは複数の送受信器と、
前記送受信器に接続され、
前記ポートと、前記ディレクトリに対する対応する担当サーバとを関連付けるインデックス・テーブルを前記ＵＤＰ登録メッセージに基づいて生成し、
前記要求されたディレクトリの最長プレフィックス・マッチング（ＬＰＭ）を前記インデックス・テーブルに対して実施して、前記担当サーバに対応するポートを決定し、
前記クライアントと前記担当サーバに対応する前記ポートとを関連付けるフロー・テーブルにエントリを生成する、
ように構成されたプロセッサであって、ハッシュ関数が前記要求されたディレクトリのプレフィックスをバイナリ・シーケンスに関連付けるために使用され、前記インデックス・テーブルは、前記要求されたディレクトリのプレフィックスを前記ポートに前記ハッシュ関数を介して関連付け、ＬＰＭを実施することは、前記ハッシュ関数を用いて前記要求されたディレクトリをハッシュして、要求されたバイナリ・シーケンス値を生成することと、前記要求されたバイナリ・シーケンス値のＬＰＭを前記インデックス・テーブルに対して実施して前記要求されたディレクトリに対応するポートを識別するステップこととを含む、プロセッサと、
を備え、
前記送受信器はさらに、第２のクライアント要求に応答して、前記要求されたファイルの少なくとも一部を前記担当サーバから前記対応するポートを介して受信し、前記要求されたファイルの一部を前記クライアントに転送するように構成される、
装置。
前記送受信器はさらに、伝送制御プロトコル（ＴＣＰ）要求を前記クライアントから受信するように構成され、前記プロセッサはさらに、前記ＴＣＰ要求を受信したことに応答して前記ポートを前記フロー・テーブルから検索するように構成され、前記装置は、前記ＴＣＰ要求をサーバに前記ポートを介して転送するように構成された第２の送受信器をさらに備え、前記サーバは分散記憶システム内の複数のサーバの１つである、請求項１３に記載の装置。
前記第２の送受信器はさらに、ＴＣＰ応答を前記サーバから受信するように構成され、前記ＴＣＰ応答は前記要求されたファイルの少なくとも一部を含み、前記送受信器はさらに、前記ＴＣＰ応答を前記クライアントに転送するように構成された、請求項１４に記載の装置。
前記第２の送受信器はさらに、ユーザ・ダイアグラム・プロトコル（ＵＤＰ）登録メッセージを前記サーバから前記ポートを介して受信するように構成され、前記登録メッセージは前記サーバが担当する少なくとも１つのディレクトリを含み、前記プロセッサはさらに、前記ポートを前記少なくとも１つのディレクトリに関連付ける前記インデックス・テーブルに少なくとも１つのエントリを生成するように構成された、請求項１４に記載の装置。