JP7085565B2 - 分離されたネットワークスタックにわたるインテリジェントなスレッド管理 - Google Patents

Description

Ｌｉｎｕｘ（登録商標）オペレーティングシステム（ＯＳ）のようなオペレーティングシステムは、リソースを分離するためのメカニズムを提供する。こうしたメカニズムの例としては、ｊａｉｌ、ゾーン、及びコンテナが挙げられる。これらの分離メカニズムの各々の構成要素は、名前空間である。Ｌｉｎｕｘ（登録商標）ＯＳは、マウント、プロセス識別子、ネットワークスタック、ユーザーのような名前空間を提供する。各名前空間は、異なるブランチのノードが互いに分離された階層と見なされることがある。その結果、種々の名前空間にわたる可視性が妨げられる。分離のもう一つの構成要素は、コントロールグループである。コントロールグループによれば、階層構造を用いたリソースの計測や制限が可能となる。コントロールグループの例としては、プロセッサーコントロールグループ、メモリーコントロールグループ、及びブロック入出力コントロールグループが挙げられる。名前空間とコントロールグループとを合わせたものが、コンテナの構成要素である。

仮想ローカルエリアネットワーク（ＶＬＡＮ）によれば、種々のリモートコンピューティングシステムは、共通のローカルエリアネットワーク上にあるかのように通信することができる。したがって、セキュアでないネットワークを介して通信が行われる場合であっても、ネットワークセキュリティ対策により、種々のリモートコンピューティングシステム間でセキュアな通信が行われることが保証される。インターネットスモールコンピュータシステムインターフェース（ｉＳＣＳＩ）をＶＬＡＮと組み合わせて使用すれば、ストレージシステム上の種々のボリュームにセキュアな形でアクセスすることができる。ｉＳＣＳＩによれば、データのボリュームがストレージシステムのどこに記憶されているかを抽出することができる。接続を行うために、デバイスは、特定のボリュームの探索要求をｉＳＣＳＩターゲットに対して発行する。この探索要求に応答し、ｉＳＣＳＩターゲットは、そのボリュームの場所を判定し、そのボリュームの場所のインターネットプロトコル（ＩＰ）アドレスを提供する。その結果、エンドユーザーは、データにアクセスする前に、そのデータが実際に配置されている場所を知る必要なく、データのボリュームにアクセスすることができる。このプロセスは、ｉＳＣＳＩリダイレクトと呼ばれる。

本開示の態様は、添付の図面を参照することにより、よりよく理解され得る。
ｉＳＣＳＩリダイレクトをサポートするストレージシステムを示す図である。 複数のＶＬＡＮを用いてｉＳＣＳＩリダイレクションをサポートするストレージシステムを示す図である。 複数のＶＬＡＮを用いてｉＳＣＳＩリダイレクションをサポートする別のストレージシステムを示す図である。 複数のＶＬＡＮを用いてセキュアな形でｉＳＣＳＩリダイレクションをサポートする方法を示すフロー図である。 ネットワーク名前空間内の複数のネットワークスタックインスタンスにわたってスレッドを管理する例示的アプリケーションインスタンスを示す概念図である。 分離されたネットワークスタックインスタンスの受信データを処理する仕事をスレッドにインテリジェントに割り当てるための例示的動作を示すフロー図である。 分離されたネットワークスタックインスタンスからの送信用データを処理する仕事をスレッドにインテリジェントに割り当てるための例示的動作を示すフロー図である。 トラフィック分離を維持するためのスレッドマネージャーを有する例示的コンピューターシステムを示す図である。

説明
以下の説明には、本開示の種々の態様を具現化するシステム、方法、技術、及びプログラムフローの例が含まれる。しかしながら、本開示は、これらの具体的詳細なしに実施されてもよいものと理解される。例えば、本開示は、トラフィック分離のための仮想ローカルエリアネットワーク（ＶＬＡＮ）技術と併せて、そのトラフィック分離を継続するために、共有ノードの分離されたネットワークスタックインスタンスにわたるスレッドのインテリジェントな管理にも言及する。本開示の種々の態様によれば、他の技術を使用して、種々のテナント／顧客間におけるトラフィックを分離し、その分離を共有ノード上で維持することができる。他の技術の例としては、仮想プライベートネットワーク（ＶＰＮ）やトンネリング技術が挙げられる。他の例では、説明を分かりにくくしないために、周知の命令インスタンス、プロトコル、構造、及び技術については、詳細に示されない。

概要
異なる顧客又はテナントのデータトラフィックを、互いに分離された状態で、共有ノードにおいて効率的に処理することができる。アプリケーションの複数のインスタンスのためのコンテナを作成したり、複数のネットワークスタックの各々についてスレッドを生成したりする代わりに、アプリケーションインスタンスは、互いに分離された複数のネットワークスタックインスタンスを作成し、分離されたネットワークスタックインスタンスにわたってスレッドをインテリジェントに管理することができる。分離されたネットワークスタックインスタンスにわたってスレッドをインテリジェントに管理するために、各スレッドは、そのスレッドが現在割り当てられているネットワーク名前空間を識別するデータを保持する。この情報を用いることで、アプリケーションは、データトラフィックを処理するネットワークスタックインスタンスのネットワーク名前空間に既に存在しているスレッドをインテリジェントに使用し、スレッドを名前空間に割り当てるシステムコールのパフォーマンスへの影響を回避することができる。

ＶＬＡＮストレージシステム
図１は、ｉＳＣＳＩリダイレクトをサポートするストレージシステム１０４を示している。ストレージシステム１０４は、ノード１０８、１１０、及び１１２を含む。各ノードは、１以上のデータボリュームに関する情報を含む場合がある。例えば、ノード３ １１２は、ボリューム３に関連するデータを含む。このデータは、そのボリュームに記憶されたデータの場所に関する情報を含む場合がある。ボリュームのデータは、異なるノードにわたって記憶される場合がある。一実施形態において、ボリュームのデータは、ストレージシステム１０４の全ノードにわたってランダムに記憶される。複数の異なるクライアントが、ストレージシステムにアクセスすることができる。これらのクライアントは、互いに独立している場合がある。したがって、各クライアントに関連するデータは、他のクライアントからはアクセス不能にされる。クライアントデータを互いに分離したままにする１つの方法は、各クライアントについて個別の仮想インターネットプロトコル（ＶＩＰ）アドレスを使用することである。この実施形態では、各ＶＩＰが、ノードのクラスターに対して使用される。種々のクライアントクラスターで使用されるノードは、重複する可能性があるが、異なるＶＩＰを使用しているため、データは分離された常態に維持される。例えば、ＶＩＰ １０６を使用してクラスターにアクセスするクライアントを別のＶＩＰ（図１には示されていない）を用いて認証することは、できないであろう。したがって、クライアントは、そのクライアントに関連するクラスター上のボリュームにのみアクセスすることができる。

ｉＳＣＳＩを使用して、各ボリュームにアクセスすることができる。エンドユーザーは、コンピューティングデバイス１０２を使用して、エンドユーザーに関連するボリュームにアクセスすることができる。例えば、クライアント１０２は、ボリューム３にアクセスすることができる。これを行うためには、クライアントは、ストレージシステム１０４に関連するＩＰアドレス１０６を知っていなければならない。この目的のために、仮想ＩＰアドレス（ＶＩＰ）が使用される。このＩＰアドレスが仮想的であると見なされるのは、このＶＩＰを宛先とするデータを受信する物理デバイスが、変わるからである。クライアント１０２のようなｉＳＣＳＩイニシエータは、最初に、エンドポイントとしてのＶＩＰアドレス１０６に接続する。ｉＳＣＳＩ機能をサポートするために、ＶＩＰアドレス１０６は、複数のクライアントからのすべての初期ｉＳＣＳＩ要求を処理する責任を有する。このアドレスの実際の物理的宛先である実際のノード又は他のコンピューティングシステムは、変更することができる。例えば、ホスティングコンピューティングデバイスを変更することにより、ｉＳＣＳＩ機能を処理する負荷のバランスを取ることができる。重要なのは、如何なる時点においても、単一のノードのみが、ＶＩＰを有することである。ＶＩＰで受信されたデータを処理するノードは何れも、入ってくるｉＳＣＳＩ要求に備えて、ＶＩＰの既知のポート（例えば、３２６０）をリッスンする。

種々のノードがＶＩＰのエンドポイントとして機能できるようにすることで、現在ＶＩＰを有しているノードがクラッシュした場合、別のノードがＶＩＰになることができる。顧客の観点からは、ＶＩＰは、常に利用可能であり、顧客は、どのノードがＶＩＰとして機能しているかを、知っている必要はない。このように、ＶＩＰは、クライアント１０２がｉＳＣＳＩストレージに接続するために使用するアドレスである。

ＶＩＰの１つの機能は、クライアントを、要求されたボリュームを記憶しているノードに導くことである。これによって、現在ＶＩＰとして機能しているノードとは異なるノードに、ボリュームを置くことが可能となる。例えば、図１は、ボリューム３へのアクセスを要求するクライアント１０２を示している。最初に、クライアント１０２は、ＶＩＰに向けて要求を送信する（１５０）。図１では、ノード１０８がＶＩＰとして機能しているため、この要求は、ノード１０８によって処理される。ノード１は、どのノードが、ボリューム３に対するＩ／Ｏ要求を処理するかを判定する。例えば、データベースは、ボリューム名からノード名又はＩＰアドレスへのマッピング（対応付け）を記憶している場合がある。この例では、ノード１１２が、ボリューム３に対するＩ／Ｏ要求を処理する。したがって、ノード１０８は、ノード１１２のＩＰアドレス（例えば１９２．１６８．１３３．９３）及びボリューム３に対するｉＳＣＳＩコマンドを受け入れるポートを含むリダイレクト応答を、クライアント１０２に送信する（１５２）。これを受信すると、クライアント１０２は、ノード１１２に対して新しいログインを直接実施する（１５４）。

このリダイレクトには、２つの異なるタイプのプロセスが含まれる。第１のタイプのプロセスは、ＶＩＰプロセスである。第２のタイプのプロセスは、特定のネットワークで発生するｉＳＣＳＩコマンドをリッスンするプロセスである。図１では、各ノードが、ｉＳＣＳＩリスニングプロセスとして機能する１つのプロセスを有している。各プロセスは、そのノードが有するボリュームにアクセスするためのｉＳＣＳＩコマンドをリッスンする。特定のボリュームが現在のノード上に保有されていない場合、現在のノードは、ｉＳＣＳＩイニシエーターを正しいノードにリダイレクトすることができる。これは、ｉＳＣＳＩイニシエーターを正しいノードにリダイレクトするＶＩＰプロセスとは異なる。むしろ、各ｉＳＣＳＩリスニングプロセスは、あるノードから別のノードへ移動するボリュームを考慮して、ｉＳＣＳＩイニシエーターをリダイレクトすることができる。このように、２つのタイプのプロセスの１つの主な違いは、各ｉＳＣＳＩリスニングプロセスは、すべてのクライアントが最初に通信するリダイレクタプロセスであることを意図していない点である。ＶＩＰプロセスは、すべてのクライアントが、特定のボリュームにアクセスしようとするときに最初に接続するプロセスである。

ｉＳＣＳＩリダイレクトは、ＶＬＡＮと組み合わせて使用することができる。図２は、複数のＶＬＡＮを用いてｉＳＣＳＩリダイレクトをサポートするストレージシステム１０４を示している。具体的には、ストレージシステム１０４は、３つの異なるｉＳＣＳＩエンドポイント、すなわち、ＶＬＡＮ１、クラスター、及びＶＬＡＮ２を含む。クライアント１０２は、ＶＩＰ１０６を使用して、そのクライアントのクラスター上の種々のボリュームにアクセスすることができる。これは、図１で説明したようにして達成される。図１とは対照的に、図２は、２つのＶＬＡＮを含む。各ＶＬＡＮは、そのＶＬＡＮに固有の専用ＶＬＡＮ ＩＰアドレスを有する専用ＶＬＡＮネットワークインターフェースが、すべてのノード上に構成されていることを必要とする。各ＶＬＡＮについて異なるネットワークインターフェースを有することにより、異なるネットワークからのパケットを、互いに分離することが可能となる。あるＶＬＡＮについて入ってくるトラフィックや出て行くトラフィックはすべて、そのＶＬＡＮに関連する専用インターフェース及びＩＰアドレスを介して送受信されなければならない。また、ＶＬＡＮトラフィックは、非ＶＬＡＮトラフィックや、別のＶＬＡＮ上のトラフィックを見ることができない。このＶＬＡＮデータの分離を確保するために、図２では、２つのＶＩＰが追加されている。１つは、ＶＬＡＮ１ ２０６用であり、もう１つは、ＶＬＡＮ２ ２０８用である。したがって、ＶＬＡＮ１クライアント２０２は、ＶＩＰ２０６を使用して、自分のクラスターにアクセスすることができる。同様に、ＶＬＡＮ２クライアント２０４は、ＶＩＰ ２０８を使用して、自分のクラスターにアクセスすることができる。

ＶＩＰ２０６及び２０８の追加の他に、各ノードは、各ＶＬＡＮ用のｉＳＣＳＩリスニングプロセスをさらに含む。ＶＩＰプロセスは、各ＶＬＡＮ用にも使用される場合がある。図２において、プロセスＰ１、Ｐ３、及びＰ４は、ノードのクラスター用のｉＳＣＳＩリスニングプロセスである。プロセスＰ５、Ｐ８、及びＰ１１は、ＶＬＡＮ１用のｉＳＣＳＩリスニングプロセスであり、Ｐ７、Ｐ１０、及びＰ１２は、ＶＬＡＮ２用のｉＳＣＳＩリスニングプロセスである。ノード２１０上のＰ２、ノード２１０上のＰ６、及びノード２１２上のＰ９は、それぞれ、クラスター、ＶＬＡＮ１、及びＶＬＡＮ２用のＶＩＰプロセスである。

図２に示したアプローチでは、異なるＶＬＡＮからのトラフィックを、異なるプロセスを使用して分離している。そのため、新たなＶＬＡＮを追加すると、各ノード上で動作するプロセスの数は、増加することになる。ＶＬＡＮの数が少ないときは、これによって問題が発生することはない。しかしながら、サポートされるＶＬＡＮが多数（例えば、１００又は１０００）になると、システムリソースに、大きな負担がかかり始まる。多数のプロセスは、競合の問題、並びに膨大なメモリオーバーヘッドを引き起こすことがある。また、各プロセスが、余分なスレッド及びソケットを必要とする。さらに、ＶＬＡＮの追加や削除も、問題となる。多数のノードを有するストレージシステムでは、各ノードにプロセスを追加する必要がある。そのため、ＶＬＡＮの動的追加を実施することはできない。例えば、各ノード上にプロセスをアトミック（微小サイズ）に作成しようとすると、競合状態がよく発生する。さらに、ＩＰアドレスを割り当てる方法も、問題になる。

図３は、一実施形態による、複数のＶＬＡＮを用いてｉＳＣＳＩリダイレクトをサポートするストレージシステムを示している。図３では、各ノード上に、単一のワイルドカードプロセスが存在する。このプロセスは、何れかのＶＬＡＮ又はクラスターに対してＶＩＰプロセスとして動作し、かつ、すべてのクラスター及びＶＬＡＮに対してｉＳＣＳＩリスニングプロセスとして動作する。これを実現するために、マシンのすべてのインターフェースにバインドされたＩＰアドレスを使用する。例えば、ＩＰＡＤＤＲ＿ＡＮＹ ＩＰアドレス（例えば、０．０．０．０又は：：）を使用することができる。このように、１つのプロセスは、マシンのすべてのネットワークインターフェースにわたって、特定のポート（例えば、３２６０）をリッスンする。種々の実施形態において、ｉＳＣＳＩトラフィックは、異なるＩＰアドレスを使用してＶＬＡＮを区別するが、同じポートを使用する。異なるポートを使用する場合、すべてのポートの各々について１つのプロセスが必要である。ＩＰＡＤＤＲ＿ＡＮＹ ＩＰアドレスは、プロセスがリッスンすることができるワイルドカードアドレスとして機能し、これによってプロセスは、マシンの特定ポート上の何れかのインターフェースを宛先とするすべてのパケットを受信することになる。ただし、物理インターフェースと仮想インターフェースは、依然として分離されている。あるノードに入ってきたトラフィックは、依然として、それ自体のインターフェース上に留まっている。カーネル内の最終層でのみ、すべての入ってきたトラフィックが、ＩＰＡＤＤＲ＿ＡＮＹにバインドされた前記１つのポートをリッスンしている１つのプロセスに集約される。したがって、異なるＶＬＡＮ間でデータを分離するというＶＬＡＮ要件が達成される。

このように、ＩＰＡＤＤＲ＿ＡＮＹアドレスを使用すると、ノードごとに、単一のプロセスを実行することが可能となる。この１つのプロセスが、すべてのクラスター及びＶＬＡＮトラフィックを処理する。また、ｉＳＣＳＩリスニングプロセスをＶＩＰプロセスと結合することができる。そのため、ストレージシステムでサポートされるＶＬＡＮの数に関係なく、各ノードは、単一のプロセスのみを有する。この１つのプロセスが、すべての非ＶＬＡＮパケットも処理する。なお、各ＶＬＡＮ及びクラスターは、固有のＩＰアドレスを有しており、固有のＩＰアドレスは、外部クライアントによるＶＬＡＮ又はクラスター上の種々のボリュームへのアクセスに使用される。

上記のように、図３に示したアプローチによれば、ＶＬＡＮトラフィックが、適当に分離された状態に保たれる。したがって、ＶＬＡＮのセキュリティが維持される。顧客のｉＳＣＳＩデータが、フィルタリングされていない多目的のワイルドカードインターフェース及びポートを通過することはない。ワイルドカードインターフェースは、種々のＶＬＡＮに関連するデータを受信することができるため、ワイルドカードプロセスは、ｉＳＣＳＩ要求及びデータを適当に処理する方法を判定しなければならない。データベースを使用して、パケットを適当にルーティングするために使用されるデータを記憶してもよい。データベースは、ストレージシステムにおける各ボリューム及びノードに関するデータを含む場合がある。ワイルドカードプロセスのリダイレクタ部分は、この情報を使用して、どのノードがそのボリュームを有しているかを探索することができる。次に、そのノードのすべてのＩＰアドレスを判定することができる。

図１の例を繰り返すと、クライアントは、ボリューム３にログインすることができる。ＶＬＡＮ１クライアントから、ボリューム３にアクセスするために、探索要求が送信される。クライアントは、パケットをＶＬＡＮ１のＩＰアドレス１０．１０．５．２００に送信する。ノード１がＶＬＡＮ１のＶＩＰである場合、探索要求は、ノード１で実行されている１つのワイルドカードプロセスによって処理される。ボリューム３は、ノード３にある。ただし、ノード３は、３つのＩＰアドレスでアドレス指定可能であるため、どのようなＩＰアドレスを返すべきかが、問題となる。３つのＩＰアドレスとは、すなわち、クラスター用の１９２．１６８．１３３．９３、ＶＬＡＮ１用の１０．１０．５．３、及びＶＬＡＮ２用の１０．１０．６．３である。以前は、各インターフェースについて１つのプロセスがあった。そのため、返すべきアドレスは、分かっている場合があった。なぜなら、各ＶＬＡＮについて、例えば３つのＩＰアドレスの各々について、１つのプロセスしかなかったからである。今度は、単一のプロセスが実行されているため、返すべき正しいＩＰアドレスを判定しなければならない。

返すべき正しいＩＰアドレスを判定するために、パケットが到着したローカルエンドポイントを判定することができる。例えば、ｇｅｔｓｏｃｋｎａｍｅ（）メソッドの呼び出しを行うことができる。上記の例では、トラフィックがＶＬＡＮ１のＶＩＰで受信されたため、１０．１０．５．２００が返される場合がある。この情報を使用して、ＶＬＡＮの名前を、データベースから判定することができる。さらに、ボリューム３がノード３にあることも、判定することができる。次に、このＶＬＡＮの名前を使用して、ＶＬＡＮ１に関連するノード３上のＩＰアドレス、すなわち、１０．１０．５．３を判定することができる。これが、クライアントに返されるアドレスである。クライアントは、その後、１０．１０．５．３に直接接続することにより、ボリューム３にアクセスすることができる。

クライアントがボリューム３のデータにアクセスするときに、ワイルドカードプロセスは、Ｉ／Ｏ要求を処理する。これらの要求はｉＳＣＳＩ探索要求ではないため、ワイルドカードプロセスに対応するｉＳＣＳＩリスナーが、そのＩ／Ｏ要求を処理する。ワイルドカードプロセスのこの部分は、クライアントがノード３への接続に使用したＩＰアドレスを判定する。この情報を使用して、ワイルドカードプロセスは、クライアントがＶＬＡＮに接続できることを、確認することができる。

種々の実施形態によれば、ＶＬＡＮをサポートするために必要なプロセスの削減に加えて、ＶＬＡＮをアトミック（微小サイズ）に構成することが可能となる。ＶＬＡＮをクラスターに追加するために、ＩＰアドレスの１以上のブロックを、クライアントデバイスから受信する。例えば、ＶＬＡＮセットアッププロセスは、ＩＰアドレスのブロックを受信することができる。さらに、新しいＶＬＡＮの名前、及びそのＶＬＡＮに必要となるＶＩＰを、受信することができる。これらのＩＰアドレスは、各ノードに１つのＩＰアドレスを割り当てるために使用される。新しいＶＬＡＮに関連する各ＩＰアドレスは、現在のところ、クラスターにおいて使用することができない。ＶＬＡＮを作成できるようにするために、ＩＰアドレスのブロックにおいて現在使用されているＩＰアドレスは、すべてフィルタリングされ、若しくは使用中であるものとしてマーキングされる。その後、未使用のＩＰアドレスの数を、判定することができる。未使用のＩＰアドレスの数がクラスター内のノードの数よりも少ない場合、ＶＬＡＮを作成することはできない。この事例では、ＶＬＡＮを作成するためにＩＰアドレスの別のブロックが必要であることを示すメッセージを、クライアントデバイスに返すことができる。ＩＰアドレスの数がクラスター内のノードの数以上である場合、ＶＬＡＮの作成を続けることができる。

アトミック機能をサポートするデータベースは、ＶＬＡＮをアトミック（微小サイズ）に作成するために使用される。各ノードに割り当てられたＩＰアドレス、及びノードの識別子は、データベースに記憶される。これにより、クラスター内の各ノードについて、このＶＬＡＮ用のＩＰアドレスを判定することができる。このアトミック機能によれば、ＶＬＡＮの追加と同時にノードがクラスターに追加された場合でも、そのＶＬＡＮを、その新しいノードを用いて正常に作成することができる。ＶＬＡＮが正常に追加される前に新しいノードが追加されたために、ＶＬＡＮが最初に正常にインストールされなかった場合、新しいＶＬＡＮの追加を再試行してもよい。この事例では、新しいノードが追加されていないか、既存のノードが削除されているか、あるいは、１つのＩＰアドレスの使用が重複している場合に限り、新しいＶＬＡＮの追加は成功する。ＶＬＡＮがデータベースに追加された後、各ノード用にネットワークインターフェースを作成し、適当なポートにバインドすることができる。さらに、ＶＬＡＮのＶＩＰは、初期ノードにバインドされ、新しいＶＬＡＮ上でｉＳＣＳＩ探索要求をリッスンする。

この構成のもう１つの利点は、多数の異なるクライアントが、ストレージシステムを使用することができる点である。単一のクライアントは、それ自体が複数の顧客を有することがある。ただし、クライアントは、各顧客のデータが他の顧客から分離され、セキュアであることを確保する必要がある場合がある。これは、各顧客に独自のＶＬＡＮを提供することにより、達成することができる。上記のように、あるＶＬＡＮ内のデータを、すべての他のＶＬＡＮのデータから区別することができる。

セキュアモードＶＬＡＮ
例えば図３を参照して実施され、上で説明されたＶＬＡＮシステムでは、各ノード又はボリュームにおいてワイルドカードアドレスが使用されるため、リスニングノードは、ＶＬＡＮ１クライアント２０２、クライアント１０２、及び／又はＶＬＡＮ２クライアント２０４から、データ（又はボリューム）の探索要求を受信する可能性がある。上で説明したように、探索要求を受信したノードはさらに、要求の結果を返すために、ｇｅｔｓｏｃｋｎａｍｅ（）メソッドの呼び出しを使用して正しいＩＰアドレスを判定する。その後、クライアントから要求されたデータ／ボリュームのアドレスをクライアントに返すことにより、クライアントを適当なノードにリダイレクトし、そのデータにアクセスするためにｉＳＣＳＩ要求を開始する。ｉＳＣＳＩプロシージャは、クライアントがアクセスできないデータ／ボリュームにクライアントがアクセスすることを、防止することができる。ただし、ノードは、複数のクライアントから探索要求を受信し、返すことができるため、探索要求の応答は、特定のクライアントによるアクセスが許可されていないデータ／ボリュームを参照する可能性がある。つまり、図３のノードは、種々のクライアントからの種々の要求をリッスンする単一のプロセスを使用して動作しているため、これらのノードが、単一クライアントについての探索要求に応答してデータ／ボリュームの場所を判定することに限定されることはない。要求に応答してクライアントをリダイレクトした後であっても、クライアントは、ｉＳＣＳＩプロシージャによって、自分のものではないデータにアクセスできない場合がある。換言すれば、クライアントは、自分達がアクセスを許可されていないデータ／ボリュームが存在すること、並びにそのようなデータの場所を知ることができる場合がある。

図４は、例示的実施形態による、複数のＶＬＡＮを用いてセキュアな形でｉＳＣＳＩリダイレクトをサポートする方法４００のフロー図を示している。代替実施形態では、もっと少ない、追加の、及び／又は異なるステップが実施されてもよい。また、フロー図の使用は、実施されるステップの順序に関して制限的であることを意図していない。

動作４０２では、データ／ボリュームの探索要求が、クライアントから発信される。一例として、探索要求は、図３に示され、図３を参照して説明されたように、ＶＬＡＮ１クライアント２０２から発信される場合がある。図１、図２、及び図３に示され、それらを参照して上で説明された手順と同様に、探索要求は、例えば図３のノード３１４のような第３のノードにあるデータ／ボリュームに対するものである場合がある。ただし、例えば図３のノード３１０のような別のノードが、ＶＬＡＮ１クライアント２０２のＶＩＰであってもよい。したがって、ＶＬＡＮ１クライアント２０２からの探索要求は、動作４０４で、ノード３１０上のワイルドカードプロセスによって処理されることになる。

動作４０４では、図３を参照して上で説明したように、ＶＩＰは、要求の結果を返すために、正しいＩＰアドレスを判定することができる。この例では、ノード３１０は、探索要求がＶＬＡＮ１クライアント２０２から発信されたことを判定し、要求の対象であるボリューム／データが記憶されている場所を判定した後、ノード３１４上の要求されたデータ／ボリュームの場所を、ＶＬＡＮ１クライアント２０２に送り返す。この判定は、動作４０６で行われる。

ただし、要求されたデータ／ボリュームの場所をクライアントに返す前に（及び、その後クライアントを第３のノードにリダイレクトし、ｉＳＣＳＩプロシージャを開始することにより、第３のノードからデータ／ボリュームを読み出す前に）、動作４０８において、第１のノード３１０は、その探索要求をクライアント固有のボリュームリスト４１０と照合する。クライアント固有のボリュームリスト４１０は、ＶＬＡＮ１クライアント２０２がアクセスできるすべてのボリュームのインデックス又はデータベースである。一部のボリュームは、ＶＬＡＮ１クライアント２０２に専用であってもよく、他のボリュームは、ＶＬＡＮ１クライアント２０２及び他のクライアントからアクセス可能であってもよい。さらに他のボリュームは、他のクライアントからはアクセス可能であるが、ＶＬＡＮ１クライアント２０２からはアクセスできない場合がある。この事例では、そのようなボリュームは、ＶＬＡＮ１クライアント２０２についてのクライアント固有のボリュームリスト４１０には現れない場合がある。代替実施形態では、クライアント固有のボリュームリストは、探索要求が行われたときに照合される複数のクライアント固有のボリュームリストを含む場合がある。例えば、あるクライアントが異なるデータ／ボリュームへのアクセスを許可する異なるグループ／セキュリティドメインの一部である場合、そのクライアントは、実質的に、複数の固有のボリュームリストを有する場合がある。実際には、探索要求を許可する際に、システムは、それらのボリュームリストを結合して一回だけ照合を実行し、あるいは、各ボリュームリストを同様に順番に調べることにより、特定のデータ／ボリュームの位置情報（ボリュームＩＤ）を要求することをクライアントに許可すべきか否かを判定することができる。実施形態によっては、システムは、クライアント固有のボリュームリスト（単数又は複数）全体を調べなくてもよい。例えば、システムがクライアント固有のボリュームリスト（複数可）上で一致するものを見つけた場合、そのボリュームリスト（複数可）の残りを調べる必要はない。このような方法によれば、システムのリソースを温存することができる。

図４は、ウェブボリュームリスト４１２も示している。クライアント固有のボリュームリスト４１０は、ＶＬＡＮ１クライアント２０２に割り当てられ、すなわち、ＶＬＡＮ１クライアント２０２からアクセス可能なボリュームＩＤを示しているのに対し、ウェブボリュームリストは、ストレージシステム（例えば、図１～図３のストレージシステム１０４）に存在するすべてのボリュームＩＤを示している。したがって、ストレージシステムに何かを記憶しているすべてのボリュームＩＤが、ボリュームがどのノードに記憶されているか、及びボリュームに何個のノードがあるかとは関係なく、Ｗｅｂボリュームリストに示されている。ボリュームＩＤは、特定の物理的記憶場所を指し示している。したがって、何が記憶されていたとしても、特定の場所をボリュームＩＤで示すことができる。クライアント固有のボリュームリスト４１０上にあるボリュームＩＤはすべて、Ｗｅｂボリュームリスト４１２（例えば、１、２、３、４、１１）上に現れる。ウェブボリュームリスト４１２は、ＶＬＡＮ１クライアント２０２には割り当てられておらず、ＶＬＡＮ１クライアント２０２からはアクセスすることができない、クライアント固有のボリュームリスト４１０上にはないボリュームＩＤ（例えば、６、７、８、９、１０）を、さらに含む。ただし、これらのボリュームＩＤは、Ｗｅｂボリュームリスト４１２にあるため、少なくとも１つの他のクライアント及び／又はＶＬＡＮからはアクセス可能である。同様に、ウェブボリュームリスト４１２とクライアント固有のボリュームリスト４１０との両方に現れるボリュームＩＤは、他のクライアント／ＶＬＡＮボリュームリスト上にある場合があり、したがって、それらの他のクライアント／ＶＬＡＮからアクセス可能である場合がある。このような状況は、複数のクライアントが同じ（等しい）ボリュームを記憶している場合に発生することがある。したがって、ストレージシステムにとっては、データの１つのインスタンスのみを記憶する方が効率的である。ストレージシステムにおいてデータ／ボリュームを記憶することができる他のボリュームＩＤは、空である場合があり、現在のところ、データ（例えば、５）を含まない場合がある。そのようなボリュームＩＤは、以前はデータを記憶していた可能性があるが、特定のボリュームＩＤにあるデータにリンクされたクライアントがないと判断された後、ガベージコレクタープロセスによって削除された可能性がある。例えば、探索要求がボリュームＩＤ５にあるデータの要求を含む場合、システムは、エラーメッセージを返してもよいし、そのボリュームＩＤに新しいデータを動的に記憶／作成してもよいし、あるいは、要求されたデータが実際にどこか他の場所に記憶されている（別のボリュームＩＤにある）か否かを判定するプロセスを実行してもよい。

上述のように、動作４０６でクライアントが判定された場合、動作４０８で、ノードは、探索要求において要求されたデータ／ボリュームが、クライアント固有のボリュームリスト４１０上にあるか否かを判定する。データ／ボリュームがクライアント固有のボリュームリスト４１０上にあるか否かの判定は、動作４１４でクライアントがデータ／ボリュームの実際の場所にリダイレクトされる前に行われる。動作４０８を動作４１４よりも前に行うことで、クライアントが許可されていないボリュームに関する情報や、クライアントが許可されていないボリューム位置へのリダイレクトに関する情報が、そのクライアントに送信されないことを保証する。

さらに、動作４１４で、クライアントは、本明細書に開示されたようなノードからの情報によってリダイレクトされ、探索要求において要求されたデータ／ボリュームを読み出し、及び／又はアクセスすることができる。例えば、動作４１４は、第３のノード３１４からデータをアクセスし、及び読み出すためのｉＳＣＳＩプロセスを開始することができる。このようなプロセスは、図１に示したプロセスと同様であってもよく、上述のように、ノード３１０（動作４０８における検証後）は、アクセスが要求されたボリュームに対するｉＳＣＳＩコマンドを受け入れるノード３１４のポートのＩＰアドレスを含むリダイレクト応答を、ＶＬＡＮ１クライアント２０２に送信する。このリダイレクト応答は、例えば、図１に１５２で示されている。これを受け取ると、ＶＬＡＮ１クライアント２０２は、ノード３１４への新しいログインを直接実施することができる。この直接ログインは、例えば、図１に１５４で示されている。

本明細書に開示されたシステム及び方法は、ストレージシステムに柔軟性とセキュリティを提供する。例えば、複数のクライアントについてのＶＬＡＮを一つにグループ化することで、ボリュームを、異なるＶＬＡＮから見えるようにすることができる。例えば、単一エンティティの一部であるクライアントのグループ／セキュリティドメインは、同じボリュームのすべてにアクセスすることができる。別の例では、クライアントのグループ／セキュリティドメインのサブセットが、同じボリュームのすべてにアクセスすることができる。その結果、複数のグループ化されたクライアントが、本明細書に開示されるようなストレージシステムにアクセスするときに、共通のＶＬＡＮを使用することができる。これにより、各クライアントデバイスについて個別の多数のＶＬＡＮを必要とすることなく、クライアントのグループが、ストレージシステムをセキュアに使用することが可能となる。

さらに、クライアントのグループ化を利用することにより、より少ない数のクライアント固有のボリュームリストを維持し、及び使用することができる。これは、共通のＶＬＡＮを使用するようにクライアントをグループ化するか否かに関係なく行うことができる。この例では、複数のグループ化されたクライアントは、それらのクライアントから発信された探索要求を、同じクライアント固有のボリュームリストと照合する場合がある。そのため、このリストは、より正確には、クライアントグループ固有のボリュームリスト若しくはセキュリティドメイン固有のボリュームリストとして特徴付けられる場合がある。複数のクライアントについて１つのボリュームリストを使用することにより、ストレージシステムは、所与の数のクライアントに対してより少ない数のボリュームリスト（各クライアントについて１つのボリュームリストを有する場合に比べて少ない数）を記憶し、及び維持することができる。これらのグループ化実施形態では、探索要求が行われる前に、クライアントをグループ化しなければならない（共通のＶＬＡＮにより、及び／又は、複数のＶＬＡＮを共通のボリュームリストに関連付けることにより）。これによって、探索要求が行われた後、システムが探索リストを、要求されたデータ／ボリューム及びそれらの各々の場所に関する情報をクライアントに送信すべきか否かを示す適当なボリュームリストと照合することが、保証される。

本明細書に記載されたシステム及び方法によれば、データが実際にアクセスされるｉＳＣＳＩ層ではなく、システムのネットワーク層のためのセキュリティ／認証も定義される。これによって、ストレージシステムにデータを記憶するクライアントのためのセキュリティ及び保護に関するさらに別の層が追加される。

ノードは、クライアントがアクセスを許可されていないデータ／ボリュームに関する情報をクライアントに提供するような形でノードがクライアントからの要求に応えることを、防止することができる。この手続は、異なるクライアントが一部の共通ボリュームにアクセスできる場合であっても、使用することができる。共通ボリュームは、一部の共通データを共有するクライアントのグループ又はセキュリティドメインにとって、特に有用である。

分離されたネットワークスタックにわたる限られたスレッドのインテリジェントな管理
前述のように、アプリケーションを、異なるネットワーク名前空間にわたってスレッドを管理するようにプログラムすることで、共有ノードによって処理される異なるＶＬＡＮのトラフィックの分離を維持することができる。スレッドを管理するために、アプリケーションインスタンスは、ＶＬＡＮとネットワーク名前空間との間の関連付けを維持し、スレッドによってスレッドレベルのストレージの形で（例えば、スレッドのスタック／メモリ空間内に変数の形で）維持されたコンテキスト情報を読み出す。本明細書の説明では、ネットワーク名前空間を作成し、ネットワーク名前空間にわたってスレッドを管理するアプリケーションインスタンスのこの機能を、「コンテナ化動作」と呼ぶ。これは、リソースをアプリケーションの複数のインスタンスで消費する代わりに、複製、すなわちクローニングを、ネットワークスタックに制限するからである。

「ノード」という用語は、クライアント要求を処理するプロセスの集合を指して使用され、ホストハードウェア（コンピューター、ブレード、マシン、アプライアンスなど）を含んでもよいし、含まなくてもよい。例えば、ストレージノードは、クライアントからのストレージ要求に対処するように協調及び／又は協働するプロセスの集合である。あるノードのためのプロセスの集合は、アプリケーションインスタンスの１以上のプロセスを含む。

「ネットワークスタックインスタンス」という用語は、ネットワーク名前空間に割り当てられた、又はネットワーク名前空間内にある、ネットワーク関連リソースの集合を指して使用される。こうしたリソースの例としては、インターフェース、アドレス空間、及びルーティングテーブルなどが挙げられる。ネットワーク名前空間が作成されると、オペレーティングシステムは、そのネットワーク名前空間のためにデフォルトネットワークスタック（例えば、デフォルトの仮想インターフェースやＩＰアドレス空間など）をインスタンス化することができる。さらに別のリソースを、ネットワーク名前空間に割り当ててもよい。

図５は、ネットワーク名前空間内の複数のネットワークスタックインスタンスにわたってスレッドを管理する例示的アプリケーションインスタンスの概念図である。ホスト５０１は、オペレーティングシステム５０３及びアプリケーションインスタンス５１１を有している。図５では、アプリケーションインスタンス５１１は、複数のネットワーク名前空間５１５、５１７、５１９を既に作成している。各ネットワーク名前空間は、ネットワークスタックのインスタンスを含む。さらに、アプリケーションインスタンス５１１は、それらのネットワーク名前空間に、ソケット及びＶＬＡＮを既に割り当てている。

ソケットを割り当てるために、アプリケーションインスタンス５１１は、システムコールを実施することにより、ネットワーク名前空間の各々のアドレス空間に基づくソケットアドレスを有するソケットを作成した。例えば、アプリケーションインスタンス５１１は、ソケット、並びに、ネットワーク名前空間５１５に含まれるネットワークスタックのアドレス空間内のネットワークアドレスの指示を作成するための、オペレーティングシステム５０３への要求を用いて、ソケット５４１を作成した。アプリケーションインスタンス５１１はさらに、そのソケットをそのネットワーク名前空間に割り当てるためのコマンドを呼び出した。

ソケット作成後のある時点で、アプリケーションインスタンス５１１は、イベント監視サービス５１４を呼び出す（例えば、ｅｐｏｌｌ（）システムコマンドを呼び出す）。アプリケーションインスタンス５１１は、ソケット識別子のリストをイベント監視サービス５１４に渡すことができる。ｅｐｏｌｌ（）呼び出しに関連して、アプリケーションインスタンス５１１は、１以上のコマンドを実行することにより、監視のために、ソケット５４１、５４３、５４５の一組のファイル記述子を登録することができる。実施形態によっては、分離されたネットワークスタックインスタンスの各々の中でソケット又はバッファを可視化する、サポートオペレーティングシステムの他のサービス又はシステムコールを使用してもよい。

ＶＬＡＮを割り当てるために、アプリケーションインスタンスは、ネットワーク名前空間の各々の中で、各ＶＬＡＮをＶＬＡＮタグによってインターフェースｉｆ０にリンクした。図５は、ネットワークスタックインスタンスのいくつかの例示的要素を、ネットワーク名前空間へのＶＬＡＮの割り当てとともに示している。ネットワーク名前空間５１５は、ルーティングテーブル５２１、ソケット５４１、及び、インターフェースｉｆ０にリンクされたＶＬＡＮ１００の表現を含む。ネットワーク名前空間５１７は、ルーティングテーブル５２３、ソケット５４３、及び、インターフェースｉｆ０にリンクされたＶＬＡＮ１０１の表現を含む。ネットワーク名前空間５１９は、ルーティングテーブル５２５、ソケット５４５、及び、インターフェースｉｆ０にリンクされたＶＬＡＮ ｎの表現を含む。インターフェースｉｆ０は、ホスト５０１の物理インターフェースに対応する。異なるＶＬＡＮをインターフェースｉｆ０にリンクすることにより、インターフェースｉｆ０は、異なるインターフェースに論理的に分割される。各ＶＬＡＮが、論理的に異なるネットワーク又はサブネットワークを表しているからである。したがって、図５は、オペレーティングシステム５０３（例えば、オペレーティングシステムのネットワーク名前空間）内に表されたインターフェースｉｆ０、及び、異なるネットワーク名前空間５１５、５１７、５１９におけるインターフェースｉｆ０と異なるＶＬＡＮタグとの結合を示している。

アプリケーションインスタンス５１１は、アプリケーションインスタンス５１１に提出されたコマンドに応答して、及び／又は設定ファイルに基づいて、ネットワーク名前空間の作成、及びネットワーク名前空間へのリソースの割り当てを実施することができる。例えば、設定ファイルは、作成するネットワーク名前空間の数、ネットワーク名前空間の名前、及びネットワーク名前空間へのリソースの割り当てを指定することができる。アプリケーションインスタンス５１１は、動作開始時に、この設定を読み出すことにより、数百の名前空間を作成し、設定することができる。その結果、互いに分離された数百のネットワークスタックがインスタンス化される。これにより、分離されたデータトラフィックを大規模にセキュアに処理するための十分なネットワークスタックを有するアプリケーションの効率的起動が可能となる（例えば、１秒あたり数百万の入出力動作（ＩＯＰＳ））。

多数のネットワークスタックは、大規模なトラフィックを分離することができるが、ホスト５０１のリソースを使い果たすことなく、ネットワークスタックの各々にスレッドを割り当てることはできない。大規模なトラフィックを処理しながらリソース消費のバランスをとるために、オペレーティングシステム５０３は、スレッドプール５１３をアプリケーションインスタンス５１１に割り当てる。スレッドプール５１３は、トラフィックからの負荷に適応するように調整される場合がある。調整とは無関係に、スレッドプール５１３のスレッドの数は、ネットワーク名前空間の数よりも少なくなる場合があり、コンテキストの切り替えが行われる場合がある。数百のネットワーク名前空間のために数百のスレッドを維持することは、リソースを使い果たす可能性があるが、あらゆるネットワークトランザクションについて、オペレーティングシステムへのシステムコールを行い、スレッドをネットワーク名前空間ごとに切り替えることも、大規模なトラフィックを処理する場合、コストがかかることになる。したがって、アプリケーションインスタンス５１１は、スレッドプール５１３からネットワーク名前空間５１５、５１７、５１９へのスレッドの切り替えをインテリジェントに管理することにより、オペレーティングシステム５０３へのシステムコールを回避する。アプリケーションインスタンス５１１によって管理される各スレッドは、スレッドローカルストレージ内に、そのスレッドが存在するネットワーク名前空間（すなわち、そのスレッドが実行されているネットワーク名前空間（アクティブ状態の場合）、又はそのスレッドが実行されていたネットワーク名前空間（待機状態の場合））を保持している。この情報から、アプリケーションインスタンス５１１は、スレッドをネットワーク名前空間に割り当てるためのコールを使用することなく、何時ネットワーク処理の仕事をスレッドに割り当てることができるかを、判定することができる。

図５は、一連の文字Ａ、Ｂ、Ｃを使用して、３つの一般的ステージを示している。これらのステージの各々は、特定の動作ではなく、一組の動作を表している。

ステージＡは、ホスト５０１のインターフェースｉｆ０でのデータトラフィック５０５の受信を表している。データトラフィック５０５は、異なるＶＬＡＮからのトラフィックで構成されている。ステージＢは、トラフィックユニット内のＶＬＡＮタグ及びソケットアドレスにしたがって、適当なソケットに書き込まれてるトラフィックを表している。ＶＬＡＮ１００のトラフィックの場合、インターフェースｉｆ０のデバイスドライバは、ネットワーク名前空間５１５内に含まれるソケット５４１にデータを書き込む。デバイスドライバは、ＶＬＡＮ１０１のデータをネットワーク名前空間５１７内に含まれるソケット５４３に書き込み、ＶＬＡＮｎのデータをネットワーク名前空間５１９内に含まれるソケット５４５に書き込む。ステージＣは、スレッドプール５１３からネットワーク名前空間５１５、５１７、５１９にスレッドをインテリジェントに割り当てる種々の動作を実施することにより種々のＶＬＡＮのトラフィック５０５を処理する、アプリケーションインスタンスを表している。この例では、スレッド５２９が、ネットワーク名前空間５１９に最後に割り当てられた。ネットワーク名前空間５１５、５１７には、スレッドが割り当てられていない。ネットワーク名前空間５１７と５１９との間の省略記号は、実用性を得るために、多数のネットワーク名前空間のうちのほんのいくつかのみが、描かれていることを示している。アプリケーションインスタンス５１１は、ネットワーク名前空間又はヌル値を示している、各スレッドのスレッドローカルストレージ内の変数を読み出す。アプリケーションインスタンス５１１は、スレッド５２９がネットワーク名前空間５１９に既に割り当てられていることを判定した場合、ソケット５４５のデータを処理する仕事をスレッド５２９に割り当てる。例えば、アプリケーションインスタンス５１１は、ネットワーク通信プロトコル処理コードへの参照及びソケット５４５のソケット識別子を含む引数を用いてスレッド５２９を起動（ウェイクアップ）する関数を呼び出す。アプリケーションインスタンス５１１は、ネットワーク名前空間５１５にスレッドが割り当てられていないことを判定する。アプリケーションインスタンス５１１は、システムコールを行い、スレッドプール５１３からアイドルスレッド５２７をネットワーク名前空間５１５に割り当て、スレッド５２７を起動し、ソケット５４１のデータを処理する仕事をスレッド５２７に割り当てる。アプリケーションインスタンス５１１は、ネットワーク名前空間５１７のソケット５４３のデータに対して同じことを行ってもよく（すなわち、スレッドプール５１３からスレッドを割り当て、スレッドに仕事を割り当てる）、あるいは、スレッドプール５１３にまだ何も割り当てられていない場合、別のネットワーク名前空間からのアイドルスレッドと入れ替えてもよい。

図５の例では、ネットワークスタックインスタンスを分離するためのネットワーク名前空間に言及しているが、実施形態によっては、他の分離メカニズム（例えば、Ｌｉｎｕｘコンテナ又はＬＸＣなど）を使用してもよい。実施形態に関係なく、ネットワークスタックインスタンスは、互いに分離され、アプリケーションインスタンスによって管理される。さらに、図５では、ホストデバイス、すなわち、ＯＳ、アプリケーションインスタンス、及びネットワークスタックインスタンスを有するホストマシンに言及している。ただし、ホストは、仮想ホストであってもよい。図６～図７は、図５で使用された用語よりも一般的な用語を使用して、分離されたネットワークスタックインスタンスにわたってトラフィックを処理するための例示的動作を示すフロー図である。

図６は、分離されたネットワークスタックインスタンスの受信データを処理する仕事をスレッドにインテリジェントに割り当てるための例示的動作を示すフロー図である。図６では、これらの動作を実施するアプリケーションインスタンスにも言及している。

ブロック６０１で、アプリケーションインスタンスは、ネットワーク処理のためにソケットにおいてデータの受信を検出する。アプリケーションインスタンスは、種々のネットワークスタックインスタンスに関する大局的視点を有するバックグラウンドプロセス又はバックグラウンドサービスからの通知に基づいて、このデータの受信を検出する。アプリケーションインスタンスは、監視のために、そのソケットを他のソケットとともに、前もって登録している。監視には、例えば、複数のソケットにわたってコールバックや反復処理を使用してもよい。

ブロック６０３で、アプリケーションインスタンスは、そのソケットに対応するネットワークスタックインスタンスを識別する。アプリケーションインスタンスが受信した通知により、ソケットは識別される。アプリケーションインスタンスは、ソケット識別子を用いてソケット構造を読み出すことにより、そのアプリケーションインスタンスが割り当てられたネットワークスタックインスタンスを判定する。このネットワークスタックインスタンスは、ソケットの作成時に配置されたものである。ソケット構造は、ネットワークスタックインスタンスを分離する論理カプセル化の識別子（例えば、名前空間識別子、コンテナ識別子など）により、ネットワークスタックインスタンスを識別することができる。

ブロック６０５で、アプリケーションインスタンスは、識別されたネットワークスタックインスタンスに既にスレッドがあるか否かを判定する。ソケットと同様に、アプリケーションインスタンスは、アプリケーションインスタンスに割り当てられたスレッドのスレッドローカルストレージにアクセスすることができる。アプリケーションインスタンスは、そのソケット構造において識別されたネットワークスタックインスタンスとの一致が見付かるか、あるいは、スレッドネットワークスタック割り当て変数の探索が完了するまで、各スレッドのスレッドローカルストレージ内のネットワークスタック割り当て変数を読み出すことができる。別の例示的実施形態として、アプリケーションインスタンスは、自分自身に対するスレッドの割り当てを追跡することができる。アプリケーションインスタンスは、システムコールを実施することにより、スレッドを割り当てるからである。アプリケーションインスタンスは、ネットワークスタックインスタンス識別子に対するスレッド識別子の割り当てのリストを維持してもよく、そのリストを調べることにより、ソケット構造において識別されたネットワークスタックインスタンスにソケットが既に割り当てられているか否かを、判定することができる。識別されたネットワークスタックインスタンスに既にスレッドが割り当てられてはいない場合、プロセスは、ブロック６０７へと進む。そうでなければ、プロセスは、ブロック６０９へと進む。

ブロック６０７で、アプリケーションインスタンスは、識別されたネットワークスタックインスタンスに非アクティブなスレッドを割り当てる。アプリケーションインスタンスは、システムコールを実施する（すなわち、ＯＳの機能又はＯＳツールの機能を呼び出す）ことにより、非アクティブなスレッドを識別されたネットワークスタックインスタンスに割り当てる。プロセスは、ブロック６０９へと続く。

ブロック６０９で、アプリケーションインスタンスは、スレッドに、受信データを処理する仕事を割り当てる。スレッドが汎用スレッドである場合、アプリケーションインスタンスは、識別されたソケットの入力ストリームへのポインター、及びネットワークプロトコル処理プログラムコードへの参照を渡す関数を呼び出すことができる。スレッドのコードには、ネットワークプロトコル処理コードが既に組み込まれている場合がある。この場合、アプリケーションインスタンスは、入力ストリームポインターを渡す。場合によっては、アプリケーションインスタンスは、独立したファンクションコールを実施することにより、非アクティブなスレッドを起動する場合がある。

図７は、分離されたネットワークスタックインスタンスからの送信用データを処理する仕事をスレッドにインテリジェントに割り当てるための例示的動作を示すフロー図である。図７では、動作を実施するアプリケーションインスタンスにも言及している。

ブロック７０１で、アプリケーションインスタンスは、送信するデータ、及びそのデータのソケットアドレスを判定する。アプリケーションインスタンスは、特定のＶＬＡＮのための特定のボリュームを指定する読み出し要求を処理している場合がある。そのボリュームに対応するストレージデバイスからデータを取得し、ネットワーク通信プロトコルに関係しない他の処理（例えば、暗号化）を実施した後、アプリケーションインスタンスは、その読み出し要求から、主張されたソケット識別子を読み出す。例えば、ソケット識別子は、ネットワークスタックインスタンスの出力から生成されたストレージコマンドとともに送られてくる場合がある。ソケット識別子は、ホストシステムのソケットを一意に識別する内部識別子であり、ソケットアドレスとは異なる。

ブロック７０３で、アプリケーションインスタンスは、取得したデータを、そのソケット識別子に対応するソケットに書き込む。その結果、アプリケーションインスタンスは、監視プロセス／サービスから、そのソケットで行うべき作業の通知を、ソケット構造内のネットワークスタックインスタンスの識別情報とともに、受信する。

ブロック７０５で、アプリケーションインスタンスは、識別されたネットワークスタックインスタンスに既にスレッドがあるか否かを判定する。アプリケーションインスタンスは、アプリケーションインスタンスに割り当てられたスレッドのスレッドローカルストレージにアクセスすることができる。アプリケーションインスタンスは、そのソケット構造において識別されたネットワークスタックインスタンスとの一致が見付かるか、あるいは、スレッドネットワークスタック割り当て変数の探索が完了するまで、各スレッドのスレッドローカルストレージ内のネットワークスタック割り当て変数を読み出すことができる。別の例示的実施形態として、アプリケーションインスタンスは、自分自身に対するスレッドの割り当てを追跡することができる。アプリケーションインスタンスは、システムコールを実施することにより、スレッドを割り当てるからである。アプリケーションインスタンスは、ネットワークスタックインスタンス識別子に対するスレッド識別子の割り当てのリストを維持してもよく、そのリストを調べることにより、ソケット構造において識別されたネットワークスタックインスタンスにスレッドが既に割り当てられているか否かを、判定することができる。識別されたネットワークスタックインスタンスに既にスレッドが割り当てられてはいない場合、プロセスは、ブロック７０７へと進む。そうでなければ、プロセスは、ブロック７０９へと進む。

ブロック７０７で、アプリケーションインスタンスは、識別されたネットワークスタックインスタンスに、非アクティブなスレッドを割り当てる。アプリケーションインスタンスは、システムコールを実施する（すなわち、ＯＳの機能又はＯＳツールの機能を呼び出す）ことにより、非アクティブなスレッドを識別されたネットワークスタックインスタンスに割り当てる。プロセスは、ブロック７０９へと続く。

ブロック７０９で、アプリケーションインスタンスは、送信用データを処理する仕事をスレッドに割り当てる。場合によっては、アプリケーションインスタンスは、独立したファンクションコールを実施することにより、非アクティブなスレッドを起動する場合がある。

単なる一例として、コンテナ化動作は、システム１０４や古いクライアント及び新しいクライアントに大きな変更を加える必要なく、図３のストレージシステム１０４にさらに別のクライアントを統合することに役立つことがある。例えば、新しいクライアントは、現在ローカルに記憶されたストレージシステムを使用している場合がある。新しいクライアントは、クラウドや、インターネットベースのストレージシステムに統合されることが、望ましい場合がある。ストレージシステム１０４が既にクラウドに基づいている場合、古いローカルシステムのルーティングプロセス、ＩＰアドレス、及び通信の一部は、そのクラウドで既に使用中の古いクライアントのものに類似する場合がある。ストレージを管理するＯＳやアプリケーションを複製することなく、新しいクライアントをストレージシステム１０４に統合するために、新しいクライアントを、本明細書に開示したコンテナ化動作方法を使用して、統合することができる。このようにすると、新しいクライアントと古いクライアントとの両方が、同じアドレス及びポート（例えば、３２６０）を使用して、ストレージシステム１０４との間で送受信を行うことができる。ただし、本明細書に開示したシステム及び方法を使用すると、異なるＶＬＡＮを使用するクライアントに関連するトラフィックを、コンテナ化動作を使用して、分離することができる。換言すれば、複数のクライアントが同じストレージシステム１０４を同じ形で使用している場合であっても、あるＶＬＡＮに関連するトラフィックを、他のＶＬＡＮに関連するクライアントから見ることはできない。また、これによってストレージシステム１０４は、より多くのクライアントに対して、より効率的にサービスを提供することが可能となる。なぜなら、ストレージシステムは、ネットワークスタックをインスタンス化する際に、各ネットワークスタックに対して自分自身のインスタンスを書き換える必要がなくなるからである。そのような方法は、大きなメモリ占有領域を使用する場合があり、また、非常に大きな分散システムを大規模に（すなわち、多数のクライアントと共に）動作させる必要がある場合がある。クライアントのトラフィックは、異なるコンテナに（そしてその後、異なる独立したソケット又はネットワークスタックに）分離される。システムをこのように構成することで、多数の異なるクライアントが、同じストレージシステム５０２を使用することができる。ストレージシステム５０２は、共通のノード／ボリューム、オペレーティングシステム（ＯＳ）、及びアプリケーション（例えば、ｉＳＣＳＩ要求に応答し、ｉＳＣＳＩ要求を満足させるためのもの）を含むことができる。システムの共通の側面を利用することで、使用されるシステムリソース全体を、削減又は合理化することができる。ただし、ストレージシステムとクライアントとの間の通信が、他のクライアントのトラフィックから分離されるため、クライアントが、セキュリティやプライバシーを犠牲にすることはない。

本明細書に開示されたシステム及び方法のユーザは、１以上のクライアントに関連する場合がある。これらのクライアントは、１以上のＶＬＡＮに関連する場合がある。ＶＬＡＮに基づいて動作をコンテナ化することにより、ユーザーは、自分のクライアントに対して複数のＶＬＡＮを設定することにより、自分のクライアントのトラフィックを互いに分離することができる。例えば、あるユーザー組織内の異なるタイプのアカウントは、異なる情報に対して異なるレベルのアクセス権を有する場合がある。そのため、そうした個々のアカウントのクライアントトラフィックを異なるＶＬＡＮを用いて分離し、コンテナー化された動作を使用して、それらのアカウントのトラフィックが互いに分離されるようにすることが望ましい場合がある。さらに、本明細書に開示されたシステム及び方法の他のユーザーは、異なる、さらに別のＶＬＡＮに関連する場合がある。したがって、異なるユーザのトラフィックも、本明細書に開示されたシステム及び方法を使用して、分離されることになる。実施形態によっては、システムは、複数のＶＬＡＮを特定のスペース又はコンテナに関連付ける場合がある。このようにして、通信監視モジュール５０４は、ある動作が、あるコンテナに関連するＶＬＡＮの何れか１つに関連している場合、その動作がそのコンテナに関連しているものと、判定することができる。

図３は、ｉＳＣＳＩ要求（例えば、３２６０）用に指定されたポートを通して３つのクライアント（例えば、２０２、１０２、２０４）のすべてから来るすべての要求をリッスンするすべてのノード（例えば、３１０、３１２、３１４）を示している。この機能は、上で説明したように、各ノード上で実行されるプロセスの数を最小限に抑えることに役立つ。また、この機能によれば、図３を参照して説明したように、各ノード上のあらゆる場所について個別のリスニングプロセスを実行する必要なしに、システム全体を、より効率的に機能させることができる。したがって、図５を参照して上で説明した方法及びシステムによれば、異なるクライアントが、ストレージシステムの同じポート（例えば、３２６０）を用いて通信することが可能となり、そのトラフィックが、互いに可視化されることはない。換言すれば、本明細書に開示されたシステム及び方法によれば、システムは、トラフィックを、異なるＶＬＡＮに関連する異なるコンテナ又は異なる名前空間に分離することが可能となる。このトラフィックは、クライアントに別のポートを指し示す必要もなければ、ストレージシステムを管理するソフトウェアアプリケーションの異なるインスタンスを作成する必要もなく、適当に分離されることができる。換言すれば、アプリケーションのネットワークコンポーネント動作のコンテナ化は、複製され、コンテナ化されることがあるが、ｉＳＣＳＩ要求の処理などの処理を実行しているアプリケーション全体が、複製され、又はコンテナ化されることはない。このようにして、各クライアント及び／又はＶＬＡＮは、同じポート（３２６０など）を指し示す続けることがあるが、そのポートを通過するトラフィックは依然として、各クライアントのＶＬＡＮにしたがって、異なるコンテナに分離されたままとなる。上述のように、これが有用となるのは、クライアントのストレージが、クラウドに移動される場合である。もし、異なるＶＬＡＮ用のストレージが、前もって物理的に分離されていた場合、トラフィックもまた、分離されている（たとえ異なるＶＬＡＮを有する異なるクライアントによって使用されるポートが、３２６０のような類似の名前を有していたとしても）。ただし、クラウドネットワーク及び／又はクライアントが再構成されない限り、すべてのデータをクラウドに移動すると、異なるＶＬＡＮを有する異なるクライアントは、要求／トラフィックを、同じ宛先ポートに送信する可能性がある。ネットワークコンポーネント（ポート）をＶＬＡＮにしたがってコンテナ化することにより、ストレージシステムにおいて、クライアント側及びデータ管理側を変更する必要がなくなる。代わりに、本明細書に開示されたようなコンテナ化ネットワーク動作を実施することにより、クライアント及びストレージシステムの構成を同じに保ちながら、異なるＶＬＡＮにしたがってトラフィックを分離することが可能となる。もう１つの利点は、ｉＳＣＳＩのような特定のプロトコルでは、使用する特定のポート（例えば、３２６０ポート）が指定されることである。種々のＶＬＡＮ上のクライアントは、自分達のトラフィックを互いに公開することなく、特定のポートを指し示し続けることができる。これにより、プロトコル標準を引き続き使用する機会が得られ、クライアント間でトラフィックを分離するために、プロトコル標準を再定義する必要がなくなる。

マシン読み取り可能媒体上に具現化されたプログラムコードは、限定はしないが、無線、有線、光ファイバケーブル、ＲＦなど、又はこれらの適当な組み合わせを含む、任意の適当な媒体を使用して送信される場合がある。機械に対して特定の形で動作するように命令することができるプログラムコード／命令が、マシン読み取り可能媒体に記憶されてもよく、それによって、マシン読み取り可能媒体に記憶された命令は、機械に、フロー図及び／又はブロック図の種々のブロック（単数又は複数）に示された機能／動作を実施する種々の命令を含む製品を、生成させてもよい。

図８は、トラフィック分離を維持するためのスレッドマネージャーを有する例示的コンピューターシステムを示している。コンピュータシステム又はホストは、プロセッサ８０１を含む。コンピュータシステムは、メモリ８０７を含む。メモリ８０７は、システムであってもよいし、あるいは、上で既に説明したマシン読み取り可能媒体の種々の実現可能形態のうちの何れか１つ又は複数であってもよい。コンピュータシステムは、ネットワークインターフェース８０５をさらに含む。コンピュータシステムは、スレッドマネージャ８１１をさらに含む。スレッドマネージャ８１１は、アプリケーションに組み込まれてもよいし、あるいは、複数の分離されたネットワークスタックを作成し、管理するアプリケーションによって使用されてもよい。アプリケーションは、複数の分離されたネットワークスタックを使用して、コンピューターシステムで受信された分離されたトラフィックの分離状態を維持する。各ネットワークスタックは、異なる論理ネットワーク若しくはサブネットワーク、又はそのグループに対応することがある。スレッドマネージャ８１１は、既存のスレッド割り当てを考慮して分離されたネットワークスタックにスレッドを割り当てることにより、ネットワークスタックへのスレッドの切り替え／割り当てのための、基礎となるオペレーティングシステムへの呼び出しのコストを回避する。前述の機能のうちの何れか１つは、ハードウェアで及び／又はプロセッサ８０１上で、部分的に（又は完全に）実施されてもよい。例えば、こうした機能は、特定用途向け集積回路を用いて実施されてもよいし、プロセッサ８０１において論理回路の形で実施されてもよく、あるいは、周辺機器又はカード上でコプロセッサ等の形で実施されてもよい。また、実現形態によっては、図８に示されていない少数の、又は追加のコンポーネント（例えば、ビデオカード、オーディオカード、追加のネットワークインターフェース、周辺機器など）を含む場合がある。プロセッサ８０１及びネットワークインターフェース８０５は、バス８０３に結合されている。メモリ８０７は、バス８０３に結合されるものとして例示されているが、プロセッサユニット８０１に結合されてもよい。本システムは、一組のストレージデバイス８１５をさらに含む。ストレージデバイス８１５としては、固体ストレージデバイス、ディスクストレージデバイス、及び、異なるタイプのストレージデバイスの混合などが挙げられる。ストレージデバイス８１５は、ネットワークインターフェースではないインターフェースを介して本システムに接続されてもよいし、あるいは、ネットワークインターフェース８０５を介して接続されてもよい。

Claims (15)

1. 複数のソケットのうちの第１のソケットにおいてネットワーク処理のためにデータを検出し、
   前記第１のソケットに対応する複数の分離されたネットワークスタックインスタンスのうちの第１の分離されたネットワークスタックインスタンスを識別し、前記複数のネットワークスタックインスタンスが、アプリケーションインスタンスによって作成されたものであり、
   複数のスレッドのうちの１つが、前記第１の分離されたネットワークスタックインスタンスに既に割り当てられているか否かを判定し、前記複数のスレッドが、前記アプリケーションインスタンスに割り当てられており、
   前記複数のスレッドのうちの第１のスレッドが、前記第１の分離されたネットワークスタックインスタンスに割り当てられているという判定に基づいて、前記第１の分離されたネットワークスタックインスタンスにしたがってデータを処理する仕事を前記第１のスレッドに割り当て、
   前記第１の分離されたネットワークスタックインスタンスにスレッドが割り当てられていないという判定に基づいて、システムコールを実施することにより、前記複数のスレッドのうちの１つを前記第１の分離されたネットワークスタックインスタンスに割り当てること、
   を含み、
   前記第１のソケットにおいてネットワーク処理のためにデータを検出することは、オペレーティングシステムの監視サービスから、前記第１のソケットにデータが書き込まれたという通知を受信すること、を含む、
   方法。
2. 複数のソケットのうちの第１のソケットにおいてネットワーク処理のためにデータを検出し、
   前記第１のソケットに対応する複数の分離されたネットワークスタックインスタンスのうちの第１の分離されたネットワークスタックインスタンスを識別し、前記複数のネットワークスタックインスタンスが、アプリケーションインスタンスによって作成されたものであり、
   複数のスレッドのうちの１つが、前記第１の分離されたネットワークスタックインスタンスに既に割り当てられているか否かを判定し、前記複数のスレッドが、前記アプリケーションインスタンスに割り当てられており、
   前記複数のスレッドのうちの第１のスレッドが、前記第１の分離されたネットワークスタックインスタンスに割り当てられているという判定に基づいて、前記第１の分離されたネットワークスタックインスタンスにしたがってデータを処理する仕事を前記第１のスレッドに割り当て、
   前記第１の分離されたネットワークスタックインスタンスにスレッドが割り当てられていないという判定に基づいて、システムコールを実施することにより、前記複数のスレッドのうちの１つを前記第１の分離されたネットワークスタックインスタンスに割り当てること、
   を含み、
   前記第１のソケットにおいてネットワーク処理のためにデータを検出することは、前記複数のソケットをオペレーティングシステムの監視サービスに登録させること、を含む、
   方法。
3. 前記第１の分離されたネットワークスタックインスタンスを識別することは、前記第１のソケットのソケット構造にアクセスすることにより、前記第１の分離されたネットワークスタックインスタンスを識別する変数を読み出すことを含む、請求項１または２に記載の方法。
4. 前記変数は、前記第１の分離されたネットワークインスタンスを前記複数の分離されたネットワークインスタンスのうちの他のものから分離する論理カプセル化の識別子を用いて、前記第１の分離されたネットワークインスタンスを識別する、請求項３に記載の方法。
5. 前記複数のソケットを前記監視サービスに登録することをさらに含む、請求項１に記載の方法。
6. 前記複数のスレッドのうちの１つが、前記第１の分離されたネットワークスタックインスタンスに既に割り当てられているか否かを判定することは、前記複数のスレッドのスレッドローカルストレージにアクセスすることにより、前記スレッドローカルストレージ内の変数が前記第１の分離されたネットワークスタックインスタンスを識別するか否かを判定することを含む、請求項１または２に記載の方法。
7. 前記第１の分離されたネットワークスタックインスタンスを識別することは、前記第１のソケットに関連する論理ネットワーク識別子を判定することを含み、
   前記第１の分離されたネットワークスタックインスタンスを識別することは、前記第１の分離されたネットワークスタックインスタンスが、前記論理ネットワーク識別子にも関連していることを判定することを含む、請求項１または２に記載の方法。
8. 共有ノード上でデータトラフィックの分離を維持するためのプログラムコードを含む１以上の非一時的マシン読み取り可能媒体であって、前記プログラムコードは、
   アプリケーションインスタンスのために複数のネットワークスタックコンテナを作成し、
   複数のソケットの各々を、前記複数のネットワークスタックコンテナの異なる１つに割り当て、前記複数のソケットの各々が、異なる論理ネットワーク又はサブネットワークに対応しており、
   前記複数のソケットのうちのネットワーク処理のためのデータを有するソケットの識別に基づいて、
   前記複数のネットワークスタックコンテナのうちのどれが前記識別されたソケットをカプセル化するかを識別し、
   前記アプリケーションインスタンスに割り当てられた複数のスレッドのうちのあるスレッドが、前記識別されたネットワークスタックコンテナに割り当てられているか否かを判定し、
   前記複数のスレッドのうちのあるスレッドが、前記識別されたネットワークスタックコンテナに割り当てられているという判定に基づいて、前記識別されたネットワークスタックコンテナ内のデータを処理する仕事を前記スレッドに割り当て、
   前記複数のスレッドのうちのあるスレッドが、前記識別されたネットワークスタックコンテナに割り当てられていないという判定に基づいて、前記複数のスレッドのうちのあるスレッドの前記識別されたネットワークスタックコンテナへの割り当てを要求し、割り当て後に、前記識別されたネットワークスタックコンテナ内のデータを処理する仕事を前記スレッドに割り当て、さらに、
   前記複数のソケットを、アプリケーションインスタンスをサポートするオペレーティングシステムの監視サービスに登録する、
   ものである、１以上の非一時的マシン読み取り可能媒体。
9. 前記複数のスレッドのうちのあるスレッドの前記識別されたネットワークスタックコンナへの割り当てを要求するための前記プログラムコードは、前記ネットワークスタックコンテナを識別する引数を用いてシステムコールを実施するプログラムコードを含む、請求項８に記載の１以上の非一時的マシン読み取り可能媒体。
10. 前記監視サービスは、アプリケーションインスタンスへのソケットを、前記ソケットについてデータが検出されたときに識別する、請求項８に記載の１以上の非一時的マシン読み取り可能媒体。
11. 前記複数のネットワークスタックコンテナのうちのどれが前記識別されたソケットをカプセル化するかを識別するための前記プログラムコードは、前記複数のソケットのソケット構造にアクセスすることにより、対応するネットワークスタックコンテナの識別子を読み出すためのプログラムコードを含む、請求項８に記載の１以上の非一時的マシン読み取り可能媒体。
12. 前記アプリケーションインスタンスに割り当てられた複数のスレッドのうちのあるスレッドが、前記識別されたネットワークスタックコンテナに割り当てられているか否かを判定するための前記プログラムコードは、前記複数のスレッドのうちのスレッドローカルストレージにアクセスすることにより、前記ネットワークスタックコンテナの識別子を読み出すためのプログラムコードを含む、請求項８に記載の１以上の非一時的マシン読み取り可能媒体。
13. プロセッサと、請求項１乃至７の何れか一項に記載の方法を装置に実施させるために、前記プロセッサによって実行可能なプログラム命令を含むマシン読み取り可能媒体とを含む、装置。
14. 前記マシン読み取り可能媒体は、前記アプリケーションインスタンスのためのアプリケーションプログラム命令をさらに含み、前記アプリケーションインスタンスのための前記アプリケーションプログラム命令は、前記プログラム命令を含む、請求項１３に記載の装置。
15. 前記マシン読み取り可能媒体は、前記分離されたネットワークスタックインスタンスを作成するために前記プロセッサによって実行可能なプログラム命令をさらに含む、請求項１３に記載の装置。
    

Images