JP2019505104A

JP2019505104A - 高性能コンピューティング環境においてファブリックレベルグループメンバーシップをサブネットレベルパーティションメンバーシップに関連付けるためのシステムおよび方法

Info

Publication number: JP2019505104A
Application number: JP2018510731A
Authority: JP
Inventors: ヨンセン，ビョルン・ダグ; ホゥ，ハーラル; ホレン，リネ
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 2016-01-27
Filing date: 2017-01-27
Publication date: 2019-02-21
Anticipated expiration: 2037-01-27
Also published as: US11128524B2; EP3408740A1; US20210234765A1; CN107852342A; US20170214766A1; EP3408969B1; US10440152B2; EP3408740B1; US20190297170A1; JP2019509529A; JP6920281B2; US20170214736A1; WO2017132570A1; US10771324B2; US20200127890A1; US20170214570A1; US20170214767A1; US11252023B2; CN107852342B; US11805008B2

Abstract

高性能コンピューティング環境においてファブリックレベルグループメンバーシップをサブネットレベルパーティションメンバーシップに関連付けるためのシステムおよび方法。ある例示的な実施形態は、ネットワーク環境のファブリックレベルでリソースドメインに対応付けられた、ネットワーク環境のサブネットにおける管理パーティションを提供することができる。管理パーティションは、ファブリックレベルデータベースに格納されるＰ＿Ｋｅｙによって規定することができる。各ファブリックリソースは、ファブリックレベルデータベースに格納される識別子によって特定される。ファブリックリソースがリソースドメインにメンバとして追加されると、Ｐ＿Ｋｅｙとファブリックリソースの識別子との間の関係が作成され、この関係は、リソースを管理パーティションのメンバとして規定する。この関係に基づいてアクセス権を与えることができる。

Description

著作権に関する注意
本特許文献の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、この特許文献または特許開示の何者かによる複製が、特許商標庁の特許ファイルまたは記録にある限り、それに対して異議を唱えないが、そうでなければ、いかなる場合もすべての著作権を留保する。

発明の分野
本発明は、概してコンピュータシステムに関し、具体的にはサブネットレベル管理スキームとファブリックレベル管理スキームとの間の対応関係をサポートすることに関する。

背景
導入されるクラウドコンピューティングアーキテクチャがより大規模になるのに応じて、従来のネットワークおよびストレージに関する性能および管理の障害が深刻な問題になってきている。クラウドコンピューティングファブリックのための基礎としてインフィニバンド^ＴＭ（InfiniBand：ＩＢ）技術などの高性能な無損失相互接続を用いることへの関心がますます高まってきている。これは、本発明の実施形態が対応するように意図された一般領域である。

概要
本明細書に記載されているのは、高性能コンピューティング環境においてファブリックレベルグループメンバーシップをサブネットレベルパーティションメンバーシップに関連付けるためのシステムおよび方法である。ある例示的な実施形態は、ネットワーク環境のファブリックレベルのリソースドメインに対応付けられた、ネットワーク環境のサブネットにおける管理パーティションを提供することができる。管理パーティションは、ファブリックレベルデータベースに格納されるＰ＿Ｋｅｙによって規定することができる。各ファブリックリソースは、ファブリックレベルデータベースに格納される識別子によって特定される。ファブリックリソースがリソースドメインにメンバとして追加されると、Ｐ＿Ｋｅｙとファブリックリソースの識別子との間の関係が生成され、この関係は、リソースを管理パーティションのメンバとして規定する。この関係に基づいてアクセス権を与えることができる。

一実施形態に従うインフィニバンド^ＴＭ環境の一例を示す図である。一実施形態に従う分割されたクラスタ環境の一例を示す図である。一実施形態に従うネットワーク環境におけるツリートポロジーの一例を示す図である。一実施形態に従う例示的な共有ポートアーキテクチャを示す図である。一実施形態に従う例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。一実施形態に従う例示的なｖＰｏｒｔアーキテクチャを示す図である。一実施形態に従うＬＩＤが予めポピュレートされている例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。一実施形態に従う動的ＬＩＤ割当てがなされた例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。一実施形態に従うｖＳｗｉｔｃｈに動的ＬＩＤ割当てがなされかつＬＩＤが予めポピュレートされている例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。一実施形態に従う例示的なマルチサブネットインフィニバンド^ＴＭファブリックを示す図である。一実施形態に従うリソースドメインの階層構造を示す図である。一実施形態に従う管理パーティションおよびデータパーティション双方を有する例示的なネットワークファブリックを示す図である。一実施形態に従う管理パーティション対応付け情報を格納するための例示的なデータストアを示す図である。一実施形態に従うデータパーティションへのメンバーシップを動的に要求して受けるエンドポートを示す例示的なフローチャートを示す図である。一実施形態に従うパーティションへのメンバーシップを動的に割当てるためのフローチャートを示す図である。一実施形態に従うパーティションへのメンバーシップを動的に割当てるためのフローチャートを示す図である。一実施形態に従うＨＣＡおよびｖＨＣＡを管理パーティションのメンバとして有する例示的なネットワークファブリックを示す図である。一実施形態に従うリソースドメインおよび管理パーティション双方を有する例示的なネットワークファブリックを示す図である。一実施形態に従うリソースドメインメンバーシップを管理パーティションメンバーシップに関連付けるためのフローチャートを示す図である。一実施形態に従うファブリックレベルデータベースを用いてリソースグループメンバーシップを管理パーティションメンバーシップに関連付ける方法の詳細なフローチャートを示す図である。一実施形態に従うスイッチ接続性に基づく管理パーティションのメンバとしてのホストチャネルアダプタを示す図である。一実施形態に従うスイッチ接続性に基づいて管理パーティションメンバーシップをホストチャネルアダプタに割当てるためのフローチャートを示す図である。一実施形態に従うスイッチ接続性に基づいて管理パーティションメンバーシップをホストチャネルアダプタに割当てるための詳細なフローチャートを示す図である。

詳細な説明
本発明は、同様の参照番号が同様の要素を指している添付図面の図において、限定のためではなく例示のために説明されている。なお、この開示における「ある」または「１つの」または「いくつかの」実施形態への参照は必ずしも同じ実施形態に対するものではなく、そのような参照は少なくとも１つを意味する。特定の実現例が説明されるが、これらの特定の実現例が例示的な目的のためにのみ提供されることが理解される。当業者であれば、他の構成要素および構成が、この発明の範囲および精神から逸脱することなく使用され得ることを認識するであろう。

図面および詳細な説明全体にわたって同様の要素を示すために、共通の参照番号が使用され得る。したがって、ある図で使用される参照番号は、要素が別のところで説明される場合、そのような図に特有の詳細な説明において参照される場合もあり、または参照されない場合もある。

本明細書に記載されているのは、高性能コンピューティング環境において、ファブリックレベルグループメンバーシップをサブネットレベルパーティションメンバーシップに関連付けるためのシステムおよび方法である。

この発明の以下の説明は、高性能ネットワークの一例として、インフィニバンド^ＴＭ（ＩＢ）ネットワークを使用する。以下の説明全体にわたり、インフィニバンド^ＴＭの仕様（インフィニバンド仕様、ＩＢ仕様、またはレガシーＩＢ仕様など、さまざまな呼ばれ方がある）を引用することがある。このような引用は、２０１５年３月に発表され、http://www.inifinibandta.orgから入手可能な、本明細書にその全体を引用により援用するInfiniBand Trade Association Architecture Specification, Volume 1, Version 1.3を引用することであると理解される。他のタイプの高性能ネットワークが何ら限定されることなく使用され得ることが、当業者には明らかであるだろう。以下の説明ではまた、ファブリックトポロジーの一例としてファットツリートポロジーを使用する。他のタイプのファブリックトポロジーが何ら限定されることなく使用され得ることが当業者には明らかであるだろう。

インフィニバンド ^ＴＭ
インフィニバンド^ＴＭ（ＩＢ）は、インフィニバンド^ＴＭ・トレード・アソシエーション（InfiniBand^TM Trade Association）によって開発されたオープン標準無損失ネットワーク技術である。この技術は、特に高性能コンピューティング（high-performance computing：ＨＰＣ）アプリケーションおよびデータセンタを対象とする、高スループットおよび少ない待ち時間の通信を提供するシリアルポイントツーポイント全二重相互接続（serial point-to-point full-duplex interconnect）に基づいている。

インフィニバンド^ＴＭ・アーキテクチャ（InfiniBand Architecture：ＩＢＡ）は、２層トポロジー分割をサポートする。低層では、ＩＢネットワークはサブネットと呼ばれ、１つのサブネットは、スイッチおよびポイントツーポイントリンクを使用して相互接続される一組のホストを含み得る。より高いレベルでは、１つのＩＢファブリックは、ルータを使用して相互接続され得る１つ以上のサブネットを構成する。

１つのサブネット内で、ホストは、スイッチおよびポイントツーポイントリンクを使用して接続され得る。加えて、サブネットにおける指定されたデバイス上に存在する、１つのマスター管理エンティティ、すなわちサブネットマネージャ（subnet manager：ＳＭ）があり得る。サブネットマネージャは、ＩＢサブネットを構成し、起動し、維持する役割を果たす。加えて、サブネットマネージャ（ＳＭ）は、ＩＢファブリックにおいてルーティングテーブル計算を行なう役割を果たし得る。ここで、たとえば、ＩＢネットワークのルーティングは、ローカルサブネットにおけるすべての送信元と宛先とのペア間の適正な負荷バランシングを目標とする。

サブネット管理インターフェイスを通して、サブネットマネージャは、サブネット管理パケット（subnet management packet：ＳＭＰ）と呼ばれる制御パケットを、サブネット管理エージェント（subnet management agent：ＳＭＡ）と交換する。サブネット管理エージェントは、すべてのＩＢサブネットデバイス上に存在する。ＳＭＰを使用することにより、サブネットマネージャは、ファブリックを発見し、エンドノードおよびスイッチを構成し、ＳＭＡから通知を受信することができる。

一実施形態に従うと、ＩＢネットワークにおけるサブネット内のルーティングは、スイッチに格納されたリニアフォワーディングテーブル（linear forwarding table：ＬＦＴ）に基づき得る。ＬＦＴは、使用中のルーティングメカニズムに従って、ＳＭによって計算される。サブネットでは、エンドノード上のホストチャネルアダプタ（Host Channel Adapter：ＨＣＡ）ポートおよびスイッチが、ローカル識別子（ＬＩＤ）を使用してアドレス指定される。ＬＦＴにおける各エントリは、宛先ＬＩＤ（destination LID：ＤＬＩＤ）と出力ポートとからなる。テーブルにおけるＬＩＤごとに１つのエントリのみがサポートされる。パケットがあるスイッチに到着すると、その出力ポートは、そのスイッチのフォワーディングテーブルにおいてＤＬＩＤを検索することによって判断される。所与の送信元−宛先ペア（ＬＩＤペア）間のネットワークにおいてパケットは同じ経路を通るため、ルーティングは決定論的である。

一般に、マスタサブネットマネージャを除く他のすべてのサブネットマネージャは、耐故障性のために待機モードで作動する。しかしながら、マスタサブネットマネージャが故障した状況では、待機中のサブネットマネージャによって、新しいマスタサブネットマネージャが取り決められる。マスタサブネットマネージャはまた、サブネットの周期的なスイープ（sweep）を行なってあらゆるトポロジー変化を検出し、それに応じてネットワークを再構成する。

さらに、サブネット内のホストおよびスイッチは、ローカル識別子（ＬＩＤ）を用いてアドレス指定され得るとともに、単一のサブネットは４９１５１個のユニキャストＬＩＤに制限され得る。サブネット内で有効なローカルアドレスであるＬＩＤの他に、各ＩＢデバイスは、６４ビットのグローバル一意識別子（global unique identifier：ＧＵＩＤ）を有し得る。ＧＵＩＤは、ＩＢレイヤー３（Ｌ３）アドレスであるグローバル識別子（global identifier：ＧＩＤ）を形成するために使用され得る。

ＳＭは、ネットワーク初期化時間に、ルーティングテーブル（すなわち、サブネット内のノードの各ペア間の接続／ルート）を計算し得る。さらに、トポロジーが変化するたびに、ルーティングテーブルは、接続性および最適性能を確実にするために更新され得る。通常動作中、ＳＭは、トポロジー変化をチェックするためにネットワークの周期的なライトスイープ（light sweep）を実行し得る。ライトスイープ中に変化が発見された場合、または、ネットワーク変化を信号で伝えるメッセージ（トラップ）をＳＭが受信した場合、ＳＭは、発見された変化に従ってネットワークを再構成し得る。

たとえば、ＳＭは、リンクがダウンした場合、デバイスが追加された場合、またはリンクが除去された場合など、ネットワークトポロジーが変化する場合に、ネットワークを再構成し得る。再構成ステップは、ネットワーク初期化中に行なわれるステップを含み得る。さらに、再構成は、ネットワーク変化が生じたサブネットに制限されるローカルスコープを有し得る。また、ルータを用いる大規模ファブリックのセグメント化は、再構成スコープを制限し得る。

一実施形態に従ったインフィニバンド^ＴＭ環境１００の一例を示す図１に、インフィニバンド^ＴＭファブリックの一例を示す。図１に示す例では、ノードＡ１０１〜Ｅ１０５は、インフィニバンド^ＴＭファブリック１２０を使用して、それぞれのホストチャネルアダプタ１１１〜１１５を介して通信する。一実施形態に従うと、さまざまなノード（たとえばノードＡ１０１〜Ｅ１０５）はさまざまな物理デバイスによって表わすことができる。一実施形態に従うと、さまざまなノード（たとえばノードＡ１０１〜Ｅ１０５）は仮想マシンなどのさまざまな仮想デバイスによって表わすことができる。

インフィニバンド ^ＴＭにおけるデータパーティション
一実施形態に従うと、ＩＢネットワークは、ネットワークファブリックを共有するシステムの論理グループを分離するためのセキュリティメカニズムとしてのパーティショニングをサポートし得る。ファブリックにおけるノード上の各ＨＣＡポートは、１つ以上のパーティションのメンバである可能性がある。一実施形態に従うと、本開示は、ＩＢサブネット内に規定することができる２種類のパーティションとして、データパーティション（以下の段落でより詳細に説明する）と管理パーティション（本開示において後に詳細に説明する）とを提供する。

データパーティションメンバーシップは、ＳＭの一部であり得る集中型パーティションマネージャによって管理される。ＳＭは、各ポートに関するデータパーティションメンバーシップ情報を、１６ビットのパーティションキー（partition key：Ｐ＿Ｋｅｙ）のテーブルとして構成することができる。ＳＭはまた、これらのポートを介してデータトラフィックを送信または受信するエンドノードに関連付けられたＰ＿Ｋｅｙ情報を含むデータパーティション実施テーブルを用いて、スイッチポートおよびルータポートを構成することができる。加えて、一般的な場合には、スイッチポートのデータパーティションメンバーシップは、（リンクに向かう）出口方向に向かってポートを介してルーティングされたＬＩＤに間接的に関連付けられたすべてのメンバーシップの集合を表わし得る。

一実施形態に従うと、データパーティションはポートの論理グループであり、あるグループのメンバは同じ論理グループの他のメンバとしか通信できない。ホストチャネルアダプタ（ＨＣＡ）およびスイッチにおいて、データパーティションメンバーシップ情報を用いてパケットをフィルタリングすることにより、分離を実施することができる。無効なパーティショニング情報を有するパケットは、当該パケットが入口ポートに達すると直ちにドロップすることができる。パーティショニングされたＩＢシステムにおいて、データパーティションを用いることにより、テナントクラスタを作成できる。データパーティションを適所で実施すると、ノードは異なるテナントクラスタに属する他のノードと通信することができない。このようにして、欠陥があるまたは悪意があるテナントノードが存在していても、システムのセキュリティを保証することができる。

一実施形態に従うと、ノード間の通信のために、マネージメントキューペア（ＱＰ０およびＱＰ１）を除き、キューペア（Queue Pair：ＱＰ）およびエンドツーエンドコンテキスト（End-to-End context：ＥＥＣ）を特定のデータパーティションに割当てることができる。次に、Ｐ＿Ｋｅｙ情報を、送信されたすべてのＩＢトランスポートパケットに追加することができる。パケットがＨＣＡポートまたはスイッチに到着すると、そのＰ＿Ｋｅｙ値を、ＳＭによって構成されたテーブルに対して確認することができる。無効のＰ＿Ｋｅｙ値が見つかった場合、そのパケットは直ちに廃棄される。このようにして、通信は、データパーティションを共有するポート間でのみ許可される。

一実施形態に従い、データがパーティショニングされたクラスタ環境の一例を示す図２に、ＩＢパーティションの一例が示される。図２に示す例では、ノードＡ１０１〜Ｅ１０５は、インフィニバンド^ＴＭファブリック１２０を使用して、それぞれのホストチャネルアダプタ１１１〜１１５を介して通信する。ノードＡ〜Ｅは、データパーティション、すなわち、データパーティション１１３０、データパーティション２１４０、およびデータパーティション３１５０に配置されている。データパーティション１はノードＡ１０１とノードＤ１０４とを含む。データパーティション２はノードＡ１０１とノードＢ１０２とノードＣ１０３とを含む。データパーティション３はノードＣ１０３とノードＥ１０５とを含む。データパーティションのこの配置により、ノードＤ１０４およびノードＥ１０５は、１つのデータパーティションを共有していないので、通信することができない。一方、たとえばノードＡ１０１およびノードＣ１０３は、どちらもデータパーティション２１４０のメンバなので、通信することができる。

インフィニバンド ^ＴＭにおける仮想マシン
過去１０年の間に、ハードウェア仮想化サポートによってＣＰＵオーバーヘッドが実質的に排除され、メモリ管理ユニットを仮想化することによってメモリオーバーヘッドが著しく削減され、高速ＳＡＮストレージまたは分散型ネットワークファイルシステムの利用によってストレージオーバーヘッドが削減され、シングルルートＩ／Ｏ仮想化（Single Root Input/Output Virtualization：ＳＲ−ＩＯＶ）のようなデバイス・パススルー技術を使用することによってネットワークＩ／Ｏオーバーヘッドが削減されてきたことに応じて、仮想化された高性能コンピューティング（High Performance Computing：ＨＰＣ）環境の将来見通しが大幅に改善されてきた。現在では、クラウドが、高性能相互接続ソリューションを用いて仮想ＨＰＣ（virtual HPC：ｖＨＰＣ）クラスタに対応し、必要な性能を提供することができる。

しかしながら、インフィニバンド^ＴＭ（ＩＢ）などの無損失ネットワークと連結されたとき、仮想マシン（ＶＭ）のライブマイグレーションなどのいくつかのクラウド機能は、これらのソリューションにおいて用いられる複雑なアドレス指定およびルーティングスキームのせいで、依然として問題となる。ＩＢは、高帯域および低レイテンシを提供する相互接続ネットワーク技術であり、このため、ＨＰＣおよび他の通信集約型の作業負荷に非常によく適している。

ＩＢデバイスをＶＭに接続するための従来のアプローチは直接割当てされたＳＲ−ＩＯＶを利用することによるものである。しかしながら、ＳＲ−ＩＯＶを用いてＩＢホストチャネルアダプタ（ＨＣＡ）に割当てられたＶＭのライブマイグレーションを実現することは難易度の高いものであることが判明した。各々のＩＢが接続されているノードは、３つの異なるアドレス（すなわちＬＩＤ、ＧＵＩＤおよびＧＩＤ）を有する。ライブマイグレーションが発生すると、これらのアドレスのうち１つ以上が変化する。マイグレーション中のＶＭ（VM-in-migration）と通信する他のノードは接続性を失う可能性がある。これが発生すると、ＩＢサブネットマネージャ（Subnet Manager：ＳＭ）にサブネット管理（Subnet Administration：ＳＡ）経路記録クエリを送信することによって、再接続すべき仮想マシンの新しいアドレスを突きとめることにより、失われた接続を回復させるように試みることができる。

ＩＢは３つの異なるタイプのアドレスを用いる。第１のタイプのアドレスは１６ビットのローカル識別子（ＬＩＤ）である。少なくとも１つの固有のＬＩＤは、ＳＭによって各々のＨＣＡポートおよび各々のスイッチに割当てられる。ＬＩＤはサブネット内のトラフィックをルーティングために用いられる。ＬＩＤが１６ビット長であるので、６５５３６個の固有のアドレス組合せを構成することができ、そのうち４９１５１個（０×０００１−０×ＢＦＦＦ）だけをユニキャストアドレスとして用いることができる。結果として、入手可能なユニキャストアドレスの数は、ＩＢサブネットの最大サイズを定義することとなる。第２のタイプのアドレスは、製造業者によって各々のデバイス（たとえば、ＨＣＡおよびスイッチ）ならびに各々のＨＣＡポートに割当てられた６４ビットのグローバル一意識別子（ＧＵＩＤ）である。ＳＭは、ＨＣＡポートに追加のサブネット固有ＧＵＩＤを割当ててもよく、これは、ＳＲ−ＩＯＶが用いられる場合に有用となる。第３のタイプのアドレスは１２８ビットのグローバル識別子（ＧＩＤ）である。ＧＩＤは有効なＩＰｖ６ユニキャストアドレスであり、少なくとも１つが各々のＨＣＡポートに割当てられている。ＧＩＤは、ファブリックアドミニストレータによって割当てられたグローバルに固有の６４ビットプレフィックスと各々のＨＣＡポートのＧＵＩＤアドレスとを組合わせることによって形成される。

ファットツリー（Fat Tree：ＦＴｒｅｅ）トポロジーおよびルーティング
一実施形態に従うと、ＩＢベースのＨＰＣシステムのいくつかは、ファットツリートポロジーを採用して、ファットツリーが提供する有用な特性を利用する。これらの特性は、各送信元宛先ペア間の複数経路の利用可能性に起因する、フルバイセクション帯域幅および固有の耐故障性を含む。ファットツリーの背後にある初期の概念は、ツリーがトポロジーのルート（root）に近づくにつれて、より利用可能な帯域幅を用いて、ノード間のより太いリンクを採用することであった。より太いリンクは、上位レベルのスイッチにおける輻輳を回避するのに役立てることができ、バイセクション帯域幅が維持される。

図３は、一実施形態に従った、ネットワーク環境におけるツリートポロジーの例を示す。図３に示すように、ネットワークファブリック２００において、１つ以上のエンドノード２０１〜２０４が接続され得る。ネットワークファブリック２００は、複数のリーフスイッチ２１１〜２１４と複数のスパインスイッチまたはルート（root）スイッチ２３１〜２３４とを含むファットツリートポロジーに基づき得る。加えて、ネットワークファブリック２００は、スイッチ２２１〜２２４などの１つ以上の中間スイッチを含み得る。

また、図３に示すように、エンドノード２０１〜２０４の各々は、マルチホームノード、すなわち、複数のポートを介してネットワークファブリック２００のうち２つ以上の部分に接続される単一のノードであり得る。たとえば、ノード２０１はポートＨ１およびＨ２を含み、ノード２０２はポートＨ３およびＨ４を含み、ノード２０３はポートＨ５およびＨ６を含み、ノード２０４はポートＨ７およびＨ８を含み得る。

加えて、各スイッチは複数のスイッチポートを有し得る。たとえば、ルートスイッチ２３１はスイッチポート１〜２を有し、ルートスイッチ２３２はスイッチポート３〜４を有し、ルートスイッチ２３３はスイッチポート５〜６を有し、ルートスイッチ２３４はスイッチポート７〜８を有し得る。

一実施形態に従うと、ファットツリールーティングメカニズムは、ＩＢベースのファットツリートポロジーに関して最も人気のあるルーティングアルゴリズムのうちの１つである。ファットツリールーティングメカニズムはまた、ＯＦＥＤ（Open Fabric Enterprise Distribution：ＩＢベースのアプリケーションを構築しデプロイするための標準ソフトウェアスタック）サブネットマネージャ、すなわちＯｐｅｎＳＭにおいて実現される。

ファットツリールーティングメカニズムの目的は、ネットワークファブリックにおけるリンクにわたって最短経路ルートを均一に広げるＬＦＴを生成することである。このメカニズムは、索引付け順序でファブリックを横断し、エンドノードの目標ＬＩＤ、ひいては対応するルートを各スイッチポートに割当てる。同じリーフスイッチに接続されたエンドノードについては、索引付け順序は、エンドノードが接続されるスイッチポートに依存し得る（すなわち、ポートナンバリングシーケンス）。各ポートについては、メカニズムはポート使用カウンタを維持することができ、新しいルートが追加されるたびに、ポート使用カウンタを使用して使用頻度が最小のポートを選択することができる。

一実施形態に従うと、パーティショニングされたサブネットでは、共通のデータパーティションのメンバではないノードは通信することを許可されない。実際には、これは、ファットツリールーティングアルゴリズムによって割当てられたルートのうちのいくつかがユーザトラフィックのために使用されないことを意味する。ファットツリールーティングメカニズムが、それらのルートについてのＬＦＴを、他の機能的経路と同じやり方で生成する場合、問題が生じる。この動作は、リンク上でバランシングを劣化させるおそれがある。なぜなら、ノードが索引付けの順序でルーティングされているからである。データパーティションに気づかずにルーティングが行なわれるため、ファットツリーでルーティングされたサブネットにより、概して、データパーティション間の分離が不良なものとなる。

一実施形態に従うと、ファットツリーは、利用可能なネットワークリソースでスケーリングすることができる階層ネットワークトポロジーである。さらに、ファットツリーは、さまざまなレベルの階層に配置された商品スイッチを用いて容易に構築される。さらに、ｋ−ａｒｙ−ｎ−ｔｒｅｅ、拡張された一般化ファットツリー（Extended Generalized Fat-Tree：ＸＧＦＴ）、パラレルポート一般化ファットツリー（Parallel Ports Generalized Fat-Tree：ＰＧＦＴ）およびリアルライフファットツリー（Real Life Fat-Tree：ＲＬＦＴ）を含むファットツリーのさまざまな変形例が、一般に利用可能である。

また、ｋ−ａｒｙ−ｎ−ｔｒｅｅは、ｎレベルのファットツリーであって、ｋ^ｎエンドノードと、ｎ・ｋ^ｎ−１スイッチとを備え、各々が２ｋポートを備えている。各々のスイッチは、ツリーにおいて上下方向に同数の接続を有している。ＸＧＦＴファットツリーは、スイッチのための異なる数の上下方向の接続と、ツリーにおける各レベルでの異なる数の接続とをともに可能にすることによって、ｋ−ａｒｙ−ｎ−ｔｒｅｅを拡張させる。ＰＧＦＴ定義はさらに、ＸＧＦＴトポロジーを拡張して、スイッチ間の複数の接続を可能にする。多種多様なトポロジーはＸＧＦＴおよびＰＧＦＴを用いて定義することができる。しかしながら、実用化するために、現代のＨＰＣクラスタにおいて一般に見出されるファットツリーを定義するために、ＰＧＦＴの制限バージョンであるＲＬＦＴが導入されている。ＲＬＦＴは、ファットツリーにおけるすべてのレベルに同じポートカウントスイッチを用いている。

入出力（Ｉ／Ｏ）仮想化
一実施形態に従うと、Ｉ／Ｏ仮想化（I/O Virtualization：ＩＯＶ）は、基礎をなす物理リソースに仮想マシン（ＶＭ）がアクセスすることを可能にすることによって、Ｉ／Ｏを利用可能にすることができる。ストレージトラフィックとサーバ間通信とを組合わせると、シングルサーバのＩ／Ｏリソースにとって抗し難い高い負荷が課され、結果として、データの待機中に、バックログが発生し、プロセッサがアイドル状態になる可能性がある。Ｉ／Ｏ要求の数が増えるにつれて、ＩＯＶにより利用可能性をもたらすことができ、最新のＣＰＵ仮想化において見られる性能レベルに匹敵するように、（仮想化された）Ｉ／Ｏリソースの性能、スケーラビリティおよび融通性を向上させることができる。

一実施形態に従うと、Ｉ／Ｏリソースの共有を可能にして、ＶＭからリソースへのアクセスが保護されることを可能にし得るようなＩＯＶが所望される。ＩＯＶは、ＶＭにエクスポーズされる論理装置を、その物理的な実装から分離する。現在、エミュレーション、準仮想化、直接的な割当て（direct assignment：ＤＡ）、およびシングルルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）などのさまざまなタイプのＩＯＶ技術が存在し得る。

一実施形態に従うと、あるタイプのＩＯＶ技術としてソフトウェアエミュレーションがある。ソフトウェアエミュレーションは分離されたフロントエンド／バックエンド・ソフトウェアアーキテクチャを可能にし得る。フロントエンドはＶＭに配置されたデバイスドライバであり得、Ｉ／Ｏアクセスをもたらすためにハイパーバイザによって実現されるバックエンドと通信し得る。物理デバイス共有比率は高く、ＶＭのライブマイグレーションはネットワークダウンタイムのわずか数ミリ秒で実現可能である。しかしながら、ソフトウェアエミュレーションはさらなる不所望な計算上のオーバーヘッドをもたらしてしまう。

一実施形態に従うと、別のタイプのＩＯＶ技術として直接的なデバイスの割当てがある。直接的なデバイスの割当てでは、Ｉ／ＯデバイスをＶＭに連結する必要があるが、デバイスはＶＭ間では共有されない。直接的な割当てまたはデバイス・パススルーは、最小限のオーバーヘッドでほぼ固有の性能を提供する。物理デバイスはハイパーバイザをバイパスし、直接、ＶＭに取付けられている。しかしながら、このような直接的なデバイスの割当ての欠点は、仮想マシン間で共有がなされないため、１枚の物理ネットワークカードが１つのＶＭと連結されるといったように、スケーラビリティが制限されてしまうことである。

一実施形態に従うと、シングルルートＩＯＶ（Single Root IOV：ＳＲ−ＩＯＶ）は、ハードウェア仮想化によって、物理装置がその同じ装置の複数の独立した軽量のインスタンスとして現われることを可能にし得る。これらのインスタンスは、パススルー装置としてＶＭに割当てることができ、仮想機能（Virtual Function：ＶＦ）としてアクセスすることができる。ハイパーバイザは、（１つのデバイスごとに）固有の、十分な機能を有する物理機能（Physical Function：ＰＦ）によってデバイスにアクセスする。ＳＲ−ＩＯＶは、純粋に直接的に割当てする際のスケーラビリティの問題を軽減する。しかしながら、ＳＲ−ＩＯＶによって提示される問題は、それがＶＭマイグレーションを損なう可能性があることである。これらのＩＯＶ技術の中でも、ＳＲ−ＩＯＶは、ほぼ固有の性能を維持しながらも、複数のＶＭから単一の物理デバイスに直接アクセスすることを可能にする手段を用いてＰＣＩＥｘｐｒｅｓｓ（ＰＣＩｅ）規格を拡張することができる。これにより、ＳＲ−ＩＯＶは優れた性能およびスケーラビリティを提供することができる。

ＳＲ−ＩＯＶは、ＰＣＩｅデバイスが、各々のゲストに１つの仮想デバイスを割当てることによって複数のゲスト間で共有することができる複数の仮想デバイスをエクスポーズすることを可能にする。各々のＳＲ−ＩＯＶデバイスは、少なくとも１つの物理機能（ＰＦ）と、１つ以上の関連付けられた仮想機能（ＶＦ）とを有する。ＰＦは、仮想マシンモニタ（virtual machine monitor：ＶＭＭ）またはハイパーバイザによって制御される通常のＰＣＩｅ機能であるのに対して、ＶＦは軽量のＰＣＩｅ機能である。各々のＶＦはそれ自体のベースアドレス（base address：ＢＡＲ）を有しており、固有のリクエスタＩＤが割当てられている。固有のリクエスタＩＤは、Ｉ／Ｏメモリ管理ユニット（I/O memory management unit：ＩＯＭＭＵ）がさまざまなＶＦへの／からのトラフィックストリームを区別することを可能にする。ＩＯＭＭＵはまた、メモリを適用して、ＰＦとＶＦとの間の変換を中断する。

しかし、残念ながら、直接的デバイス割当て技術は、仮想マシンのトランスペアレントなライブマイグレーションがデータセンタ最適化のために所望されるような状況においては、クラウドプロバイダにとって障壁となる。ライブマイグレーションの本質は、ＶＭのメモリ内容がリモートハイパーバイザにコピーされるという点である。さらに、ＶＭがソースハイパーバイザにおいて中断され、ＶＭの動作が宛先において再開される。ソフトウェアエミュレーション方法を用いる場合、ネットワークインターフェイスは、それらの内部状態がメモリに記憶され、さらにコピーされるように仮想的である。このため、ダウンタイムは数ミリ秒にまで減らされ得る。

しかしながら、ＳＲ−ＩＯＶなどの直接的デバイス割当て技術が用いられる場合、マイグレーションはより困難になる。このような状況においては、ネットワークインターフェイスの内部状態全体は、それがハードウェアに結び付けられているのでコピーすることができない。代わりに、ＶＭに割当てられたＳＲ−ＩＯＶＶＦが分離され、ライブマイグレーションが実行されることとなり、新しいＶＦが宛先において付与されることとなる。インフィニバンド^ＴＭおよびＳＲ−ＩＯＶの場合、このプロセスがダウンタイムを数秒のオーダでもたらす可能性がある。さらに、ＳＲ−ＩＯＶ共有型ポートモデルにおいては、ＶＭのアドレスがマイグレーション後に変化することとなり、これにより、ＳＭにオーバーヘッドが追加され、基礎をなすネットワークファブリックの性能に対して悪影響が及ぼされることとなる。

インフィニバンド ^ＴＭＳＲ−ＩＯＶアーキテクチャ−共有ポート
さまざまなタイプのＳＲ−ＩＯＶモデル（たとえば共有ポートモデル、仮想スイッチモデルおよび仮想ポートモデル）があり得る。

図４は、一実施形態に従った例示的な共有ポートアーキテクチャを示す。図に示されるように、ホスト３００（たとえばホストチャネルアダプタ）はハイパーバイザ３１０と対話し得る。ハイパーバイザ３１０は、さまざまな仮想機能３３０、３４０および３５０をいくつかの仮想マシンに割当て得る。同様に、物理機能はハイパーバイザ３１０によって処理することができる。

一実施形態に従うと、図４に示されるような共有ポートアーキテクチャを用いる場合、ホスト（たとえばＨＣＡ）は、物理機能３２０と仮想機能３３０、３５０、３５０との間において単一の共有ＬＩＤおよび共有キュー対（Queue Pair：ＱＰ）のスペースがあるネットワークにおいて単一のポートとして現われる。しかしながら、各々の機能（すなわち、物理機能および仮想機能）はそれら自体のＧＩＤを有し得る。

図４に示されるように、一実施形態に従うと、さまざまなＧＩＤを仮想機能および物理機能に割当てることができ、特別のキュー対であるＱＰ０およびＱＰ１（すなわちインフィニバンド^ＴＭ管理パケットのために用いられる専用のキュー対）が物理機能によって所有される。これらのＱＰはＶＦにも同様にエクスポーズされるが、ＶＦはＱＰ０を使用することが許可されておらず（ＶＦからＱＰ０に向かって入来するすべてのＳＭＰが廃棄され）、ＱＰ１は、ＰＦが所有する実際のＱＰ１のプロキシとして機能し得る。

一実施形態に従うと、共有ポートアーキテクチャは、（仮想機能に割当てられることによってネットワークに付随する）ＶＭの数によって制限されることのない高度にスケーラブルなデータセンタを可能にし得る。なぜなら、ネットワークにおける物理的なマシンおよびスイッチによってＬＩＤスペースが消費されるだけであるからである。

しかしながら、共有ポートアーキテクチャの欠点は、トランスペアレントなライブマイグレーションを提供することができない点であり、これにより、フレキシブルなＶＭ配置についての可能性が妨害されてしまう。各々のＬＩＤが特定のハイパーバイザに関連付けられており、かつハイパーバイザ上に常駐するすべてのＶＭ間で共有されているので、マイグレートしているＶＭ（すなわち、宛先ハイパーバイザにマイグレートする仮想マシン）は、そのＬＩＤを宛先ハイパーバイザのＬＩＤに変更させなければならない。さらに、ＱＰ０アクセスが制限された結果、サブネットマネージャはＶＭの内部で実行させることができなくなる。

インフィニバンド ^ＴＭＳＲ−ＩＯＶアーキテクチャモデル−仮想スイッチ（ｖＳｗｉｔｃｈ）
図５は、一実施形態に従った例示的なｖＳｗｉｔｃｈアーキテクチャを示す。図に示されるように、ホスト４００（たとえばホストチャネルアダプタ）はハイパーバイザ４１０と対話することができ、当該ハイパーバイザ４１０は、さまざまな仮想機能４３０、４４０および４５０をいくつかの仮想マシンに割当てることができる。同様に、物理機能はハイパーバイザ４１０によって処理することができる。仮想スイッチ４１５もハイパーバイザ４０１によって処理することができる。

一実施形態に従うと、ｖＳｗｉｔｃｈアーキテクチャにおいては、各々の仮想機能４３０、４４０、４５０は完全な仮想ホストチャネルアダプタ（virtual Host Channel Adapter：ｖＨＣＡ）であり、これは、ハードウェアにおいて、ＶＦに割当てられたＶＭに、ＩＢアドレス一式（たとえばＧＩＤ、ＧＵＩＤ、ＬＩＤ）および専用のＱＰスペースが割当てられていることを意味する。残りのネットワークおよびＳＭについては、ＨＣＡ４００は、仮想スイッチ４１５を介して追加のノードが接続されているスイッチのように見えている。ハイパーバイザ４１０はＰＦ４２０を用いることができ、（仮想機能に付与された）ＶＭはＶＦを用いる。

一実施形態に従うと、ｖＳｗｉｔｃｈアーキテクチャは、トランスペアレントな仮想化を提供する。しかしながら、各々の仮想機能には固有のＬＩＤが割当てられているので、利用可能な数のＬＩＤが速やかに消費される。同様に、多くのＬＩＤアドレスが（すなわち、各々の物理機能および各々の仮想機能ごとに１つずつ）使用されている場合、より多くの通信経路をＳＭによって演算しなければならず、それらのＬＦＴを更新するために、より多くのサブネット管理パケット（ＳＭＰ）をスイッチに送信しなければならない。たとえば、通信経路の演算は大規模ネットワークにおいては数分かかる可能性がある。ＬＩＤスペースが４９１５１個のユニキャストＬＩＤに制限されており、（ＶＦを介する）各々のＶＭとして、物理ノードおよびスイッチがＬＩＤを１つずつ占有するので、ネットワークにおける物理ノードおよびスイッチの数によってアクティブなＶＭの数が制限されてしまい、逆の場合も同様に制限される。

インフィニバンド ^ＴＭＳＲ−ＩＯＶアーキテクチャモデル−仮想ポート（ｖＰｏｒｔ）
図６は、一実施形態に従った例示的なｖＰｏｒｔの概念を示す。図に示されるように、ホスト３００（たとえばホストチャネルアダプタ）は、さまざまな仮想機能３３０、３４０および３５０をいくつかの仮想マシンに割当てることができるハイパーバイザ４１０と対話することができる。同様に、物理機能はハイパーバイザ３１０によって処理することができる。

一実施形態に従うと、ベンダーに実装の自由を与えるためにｖＰｏｒｔ概念は緩やかに定義されており（たとえば、当該定義では、実装がＳＲＩＯＶ専用とすべきであるとは規定されていない）、ｖＰｏｒｔの目的は、ＶＭがサブネットにおいて処理される方法を標準化することである。ｖＰｏｒｔ概念であれば、空間ドメインおよび性能ドメインの両方においてよりスケーラブルであり得る、ＳＲ−ＩＯＶ共有のポートのようなアーキテクチャおよびｖＳｗｉｔｃｈのようなアーキテクチャの両方、または、これらのアーキテクチャの組合せが規定され得る。また、ｖＰｏｒｔはオプションのＬＩＤをサポートするとともに、共有のポートとは異なり、ＳＭは、ｖＰｏｒｔが専用のＬＩＤを用いていなくても、サブネットにおいて利用可能なすべてのｖＰｏｒｔを認識する。

インフィニバンド ^ＴＭＳＲ−ＩＯＶアーキテクチャモデル−ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈ
一実施形態に従うと、本開示は、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。

図７は、一実施形態に従った、ＬＩＤが予めポピュレートされた例示的なｖＳｗｉｔｃｈアーキテクチャを示す。図に示されるように、いくつかのスイッチ５０１〜５０４は、ネットワーク切替環境６００（たとえばＩＢサブネット）内においてインフィニバンド^ＴＭファブリックなどのファブリックのメンバ間で通信を確立することができる。ファブリックはホストチャネルアダプタ５１０、５２０、５３０などのいくつかのハードウェアデバイスを含み得る。さらに、ホストチャネルアダプタ５１０、５２０および５３０は、それぞれ、ハイパーバイザ５１１、５２１および５３１と対話することができる。各々のハイパーバイザは、さらに、ホストチャネルアダプタと共に、いくつかの仮想機能５１４、５１５、５１６、５２４、５２５、５２６、５３４、５３５および５３６と対話し、設定し、いくつかの仮想マシンに割当てることができる。たとえば、仮想マシン１５５０はハイパーバイザ５１１によって仮想機能１５１４に割当てることができる。ハイパーバイザ５１１は、加えて、仮想マシン２５５１を仮想機能２５１５に割当て、仮想マシン３５５２を仮想機能３５１６に割当てることができる。ハイパーバイザ５３１は、さらに、仮想マシン４５５３を仮想機能１５３４に割当てることができる。ハイパーバイザは、ホストチャネルアダプタの各々の上で十分な機能を有する物理機能５１３、５２３および５３３を介してホストチャネルアダプタにアクセスすることができる。

一実施形態に従うと、スイッチ５０１〜５０４の各々はいくつかのポート（図示せず）を含み得る。いくつかのポートは、ネットワーク切替環境６００内においてトラフィックを方向付けるためにリニアフォワーディングテーブルを設定するのに用いられる。

一実施形態に従うと、仮想スイッチ５１２、５２２および５３２は、それぞれのハイパーバイザ５１１、５２１、５３１によって処理することができる。このようなｖＳｗｉｔｃｈアーキテクチャにおいては、各々の仮想機能は完全な仮想ホストチャネルアダプタ（ｖＨＣＡ）であり、これは、ハードウェアにおいて、ＶＦに割当てられたＶＭに、ＩＢアドレス一式（たとえばＧＩＤ、ＧＵＩＤ、ＬＩＤ）および専用のＱＰスペースが割当てられていることを意味する。残りのネットワークおよびＳＭ（図示せず）については、ＨＣＡ５１０、５２０および５３０は、仮想スイッチを介して追加のノードが接続されているスイッチのように見えている。

一実施形態に従うと、本開示は、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。図７を参照すると、ＬＩＤは、さまざまな物理機能５１３、５２３および５３３に、さらには、仮想機能５１４〜５１６、５２４〜５２６、５３４〜５３６（その時点でアクティブな仮想マシンに関連付けられていない仮想機能であっても）にも、予めポピュレートされている。たとえば、物理機能５１３はＬＩＤ１が予めポピュレートされており、仮想機能１５３４はＬＩＤ１０が予めポピュレートされている。ネットワークがブートされているとき、ＬＩＤはＳＲ−ＩＯＶｖＳｗｉｔｃｈ対応のサブネットにおいて予めポピュレートされている。ＶＦのすべてがネットワークにおけるＶＭによって占有されていない場合であっても、ポピュレートされたＶＦには、図７に示されるようにＬＩＤが割当てられている。

一実施形態に従うと、多くの同様の物理的なホストチャネルアダプタが２つ以上のポートを有することができ（冗長性のために２つのポートが共用となっている）、仮想ＨＣＡも２つのポートで表わされ、１つまたは２つ以上の仮想スイッチを介して外部ＩＢサブネットに接続され得る。

一実施形態に従うと、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャにおいては、各々のハイパーバイザは、それ自体のための１つのＬＩＤをＰＦを介して消費し、各々の追加のＶＦごとに１つ以上のＬＩＤを消費することができる。ＩＢサブネットにおけるすべてのハイパーバイザにおいて利用可能なすべてのＶＦを合計すると、サブネットにおいて実行することが可能なＶＭの最大量が得られる。たとえば、サブネット内の１ハイパーバイザごとに１６個の仮想機能を備えたＩＢサブネットにおいては、各々のハイパーバイザは、サブネットにおいて１７個のＬＩＤ（１６個の仮想機能ごとに１つのＬＩＤと、物理機能のために１つのＬＩＤ）を消費する。このようなＩＢサブネットにおいては、単一のサブネットについて理論上のハイパーバイザ限度は利用可能なユニキャストＬＩＤの数によって規定されており、（４９１５１個の利用可能なＬＩＤをハイパーバイザごとに１７個のＬＩＤで割って得られる）２８９１であり、ＶＭの総数（すなわち限度）は（ハイパーバイザごとに２８９１個のハイパーバイザに１６のＶＦを掛けて得られる）４６２５６である（実質的には、ＩＢサブネットにおける各々のスイッチ、ルータまたは専用のＳＭノードが同様にＬＩＤを消費するので、これらの数はより小さくなる）。なお、ｖＳｗｉｔｃｈが、ＬＩＤをＰＦと共有することができるので、付加的なＬＩＤを占有する必要がないことに留意されたい。

一実施形態に従うと、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャにおいては、ネットワークが一旦ブートされると、すべてのＬＩＤについて通信経路が計算される。新しいＶＭを始動させる必要がある場合、システムは、サブネットにおいて新しいＬＩＤを追加する必要はない。それ以外の場合、経路の再計算を含め、ネットワークを完全に再構成させ得る動作は、最も時間を消費する要素となる。代わりに、ＶＭのための利用可能なポートはハイパーバイザのうちの１つに位置し（すなわち利用可能な仮想機能）、仮想マシンは利用可能な仮想機能に付与されている。

一実施形態に従うと、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャはまた、同じハイパーバイザによってホストされているさまざまなＶＭに達するために、さまざまな経路を計算して用いる能力を可能にする。本質的には、これは、ＬＩＤを連続的にすることを必要とするＬＭＣの制約によって拘束されることなく、１つの物理的なマシンに向かう代替的な経路を設けるために、このようなサブネットおよびネットワークがＬＩＤマスク制御ライク（LID-Mask-Control-like：ＬＭＣライク）な特徴を用いることを可能にする。ＶＭをマイグレートしてその関連するＬＩＤを宛先に送達する必要がある場合、不連続なＬＩＤを自由に使用できることは特に有用となる。

一実施形態に従うと、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈアーキテクチャについての上述の利点と共に、いくつかの検討事項を考慮に入れることができる。たとえば、ネットワークがブートされているときに、ＳＲ−ＩＯＶｖＳｗｉｔｃｈ対応のサブネットにおいてＬＩＤが予めポピュレートされているので、（たとえば起動時の）最初の経路演算はＬＩＤが予めポピュレートされていなかった場合よりも時間が長くかかる可能性がある。

インフィニバンド ^ＴＭＳＲ−ＩＯＶアーキテクチャモデル−動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈ
一実施形態に従うと、本開示は、動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。

図８は、一実施形態に従った、動的ＬＩＤ割当てがなされた例示的なｖＳｗｉｔｃｈアーキテクチャを示す。図に示されるように、いくつかのスイッチ５０１〜５０４は、ネットワーク切替環境７００（たとえばＩＢサブネット）内においてインフィニバンド^ＴＭファブリックなどのファブリックのメンバ間で通信を確立することができる。ファブリックは、ホストチャネルアダプタ５１０、５２０、５３０などのいくつかのハードウェアデバイスを含み得る。ホストチャネルアダプタ５１０、５２０および５３０は、さらに、ハイパーバイザ５１１、５２１および５３１とそれぞれ対話することができる。各々のハイパーバイザは、さらに、ホストチャネルアダプタと共に、いくつかの仮想機能５１４、５１５、５１６、５２４、５２５、５２６、５３４、５３５および５３６と対話し、設定し、いくつかの仮想マシンに割当てることができる。たとえば、仮想マシン１５５０はハイパーバイザ５１１によって仮想機能１５１４に割当てることができる。ハイパーバイザ５１１は、加えて、仮想マシン２５５１を仮想機能２５１５に割当て、仮想マシン３５５２を仮想機能３５１６に割当てることができる。ハイパーバイザ５３１はさらに、仮想マシン４５５３を仮想機能１５３４に割当てることができる。ハイパーバイザは、ホストチャネルアダプタの各々の上において十分な機能を有する物理機能５１３、５２３および５３３を介してホストチャネルアダプタにアクセスすることができる。

一実施形態に従うと、スイッチ５０１〜５０４の各々はいくつかのポート（図示せず）を含み得る。いくつかのポートは、ネットワーク切替環境７００内においてトラフィックを方向付けるためにリニアフォワーディングテーブルを設定するのに用いられる。

一実施形態に従うと、仮想スイッチ５１２、５２２および５３２は、それぞれのハイパーバイザ５１１、５２１および５３１によって処理することができる。このようなｖＳｗｉｔｃｈアーキテクチャにおいては、各々の仮想機能は完全な仮想ホストチャネルアダプタ（ｖＨＣＡ）であり、これは、ハードウェアにおいて、ＶＦに割当てられたＶＭに、ＩＢアドレス一式（たとえばＧＩＤ、ＧＵＩＤ、ＬＩＤ）および専用のＱＰスペースが割当てられていることを意味する。残りのネットワークおよびＳＭ（図示せず）については、ＨＣＡ５１０、５２０および５３０は、仮想スイッチを介して、追加のノードが接続されているスイッチのように見えている。

一実施形態に従うと、本開示は、動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。図８を参照すると、ＬＩＤには、さまざまな物理機能５１３、５２３および５３３が動的に割当てられており、物理機能５１３がＬＩＤ１を受取り、物理機能５２３がＬＩＤ２を受取り、物理機能５３３がＬＩＤ３を受取る。アクティブな仮想マシンに関連付けられたそれらの仮想機能はまた、動的に割当てられたＬＩＤを受取ることもできる。たとえば、仮想マシン１５５０がアクティブであり、仮想機能１５１４に関連付けられているので、仮想機能５１４にはＬＩＤ５が割当てられ得る。同様に、仮想機能２５１５、仮想機能３５１６および仮想機能１５３４は、各々、アクティブな仮想機能に関連付けられている。このため、これらの仮想機能にＬＩＤが割当てられ、ＬＩＤ７が仮想機能２５１５に割当てられ、ＬＩＤ１１が仮想機能３５１６に割当てられ、ＬＩＤ９が仮想機能１５３４に割当てられている。ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈとは異なり、アクティブな仮想マシンにその時点で関連付けられていない仮想機能はＬＩＤの割当てを受けない。

一実施形態に従うと、動的ＬＩＤ割当てがなされていれば、最初の経路演算を実質的に減らすことができる。ネットワークが初めてブートしており、ＶＭが存在していない場合、比較的少数のＬＩＤを最初の経路計算およびＬＦＴ分配のために用いることができる。

一実施形態に従うと、動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈを利用するシステムにおいて新しいＶＭが作成される場合、どのハイパーバイザ上で新しく追加されたＶＭをブートすべきであるかを決定するために、自由なＶＭスロットが発見され、固有の未使用のユニキャストＬＩＤも同様に発見される。しかしながら、新しく追加されたＬＩＤを処理するためのスイッチのＬＦＴおよびネットワークに既知の経路が存在しない。新しく追加されたＶＭを処理するために新しいセットの経路を演算することは、いくつかのＶＭが毎分ごとにブートされ得る動的な環境においては望ましくない。大規模なＩＢサブネットにおいては、新しい１セットのルートの演算には数分かかる可能性があり、この手順は、新しいＶＭがブートされるたびに繰返されなければならないだろう。

有利には、一実施形態に従うと、ハイパーバイザにおけるすべてのＶＦがＰＦと同じアップリンクを共有しているので、新しいセットのルートを演算する必要はない。ネットワークにおけるすべての物理スイッチのＬＦＴを繰返し、（ＶＭが作成されている）ハイパーバイザのＰＦに属するＬＩＤエントリから新しく追加されたＬＩＤにフォワーディングポートをコピーし、かつ、特定のスイッチの対応するＬＦＴブロックを更新するために単一のＳＭＰを送信するだけでよい。これにより、当該システムおよび方法では、新しいセットのルートを演算する必要がなくなる。

一実施形態に従うと、動的ＬＩＤ割当てアーキテクチャを備えたｖＳｗｉｔｃｈにおいて割当てられたＬＩＤは連続的である必要はない。各々のハイパーバイザ上のＶＭ上で割当てられたＬＩＤをＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈと動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈとで比較すると、動的ＬＩＤ割当てアーキテクチャにおいて割当てられたＬＩＤが不連続であり、そこに予めポピュレートされたＬＩＤが本質的に連続的であることが分かるだろう。さらに、ｖＳｗｉｔｃｈ動的ＬＩＤ割当てアーキテクチャにおいては、新しいＶＭが作成されると、次に利用可能なＬＩＤが、ＶＭの生存期間の間中ずっと用いられる。逆に、ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈにおいては、各々のＶＭは、対応するＶＦに既に割当てられているＬＩＤを引継ぎ、ライブマイグレーションのないネットワークにおいては、所与のＶＦに連続的に付与されたＶＭが同じＬＩＤを得る。

一実施形態に従うと、動的ＬＩＤ割当てアーキテクチャを備えたｖＳｗｉｔｃｈは、いくらかの追加のネットワークおよびランタイムＳＭオーバーヘッドを犠牲にして、予めポピュレートされたＬＩＤアーキテクチャモデルを備えたｖＳｗｉｔｃｈの欠点を解決することができる。ＶＭが作成されるたびに、作成されたＶＭに関連付けられた、新しく追加されたＬＩＤで、サブネットにおける物理スイッチのＬＦＴが更新される。この動作のために、１スイッチごとに１つのサブネット管理パケット（ＳＭＰ）が送信される必要がある。各々のＶＭがそのホストハイパーバイザと同じ経路を用いているので、ＬＭＣのような機能も利用できなくなる。しかしながら、すべてのハイパーバイザに存在するＶＦの合計に対する制限はなく、ＶＦの数は、ユニキャストＬＩＤの限度を上回る可能性もある。このような場合、当然、アクティブなＶＭ上でＶＦのすべてが必ずしも同時に付与されることが可能になるわけではなく、より多くの予備のハイパーバイザおよびＶＦを備えることにより、ユニキャストＬＩＤ限度付近で動作する際に、断片化されたネットワークの障害を回復および最適化させるための融通性が追加される。

インフィニバンド ^ＴＭＳＲ−ＩＯＶアーキテクチャモデル−動的ＬＩＤ割当てがなされかつＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈ
図９は、一実施形態に従った、動的ＬＩＤ割当てがなされてＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈを備えた例示的なｖＳｗｉｔｃｈアーキテクチャを示す。図に示されるように、いくつかのスイッチ５０１〜５０４は、ネットワーク切替環境８００（たとえばＩＢサブネット）内においてインフィニバンド^ＴＭファブリックなどのファブリックのメンバ間で通信を確立することができる。ファブリックはホストチャネルアダプタ５１０、５２０、５３０などのいくつかのハードウェアデバイスを含み得る。ホストチャネルアダプタ５１０、５２０および５３０は、それぞれ、さらに、ハイパーバイザ５１１、５２１および５３１と対話することができる。各々のハイパーバイザは、さらに、ホストチャネルアダプタと共に、いくつかの仮想機能５１４、５１５、５１６、５２４、５２５、５２６、５３４、５３５および５３６と対話し、設定し、いくつかの仮想マシンに割当てることができる。たとえば、仮想マシン１５５０は、ハイパーバイザ５１１によって仮想機能１５１４に割当てることができる。ハイパーバイザ５１１は、加えて、仮想マシン２５５１を仮想機能２５１５に割当てることができる。ハイパーバイザ５２１は、仮想マシン３５５２を仮想機能３５２６に割当てることができる。ハイパーバイザ５３１は、さらに、仮想マシン４５５３を仮想機能２５３５に割当てることができる。ハイパーバイザは、ホストチャネルアダプタの各々の上において十分な機能を有する物理機能５１３、５２３および５３３を介してホストチャネルアダプタにアクセスすることができる。

一実施形態に従うと、スイッチ５０１〜５０４の各々はいくつかのポート（図示せず）を含み得る。これらいくつかのポートは、ネットワーク切替環境８００内においてトラフィックを方向付けるためにリニアフォワーディングテーブルを設定するのに用いられる。

一実施形態に従うと、仮想スイッチ５１２、５２２および５３２は、それぞれのハイパーバイザ５１１、５２１、５３１によって処理することができる。このようなｖＳｗｉｔｃｈアーキテクチャにおいては、各々の仮想機能は、完全な仮想ホストチャネルアダプタ（ｖＨＣＡ）であり、これは、ハードウェアにおいて、ＶＦに割当てられたＶＭに、ＩＢアドレス一式（たとえばＧＩＤ、ＧＵＩＤ、ＬＩＤ）および専用のＱＰスペースが割当てられていることを意味する。残りのネットワークおよびＳＭ（図示せず）については、ＨＣＡ５１０、５２０および５３０は、仮想スイッチを介して、追加のノードが接続されているスイッチのように見えている。

一実施形態に従うと、本開示は、動的ＬＩＤ割当てがなされＬＩＤが予めポピュレートされたハイブリッドｖＳｗｉｔｃｈアーキテクチャを提供するためのシステムおよび方法を提供する。図９を参照すると、ハイパーバイザ５１１には、予めポピュレートされたＬＩＤアーキテクチャを備えたｖＳｗｉｔｃｈが配置され得るとともに、ハイパーバイザ５２１には、ＬＩＤが予めポピュレートされて動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈが配置され得る。ハイパーバイザ５３１には、動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈが配置され得る。このため、物理機能５１３および仮想機能５１４〜５１６には、それらのＬＩＤが予めポピュレートされている（すなわち、アクティブな仮想マシンに付与されていない仮想機能であってもＬＩＤが割当てられている）。物理機能５２３および仮想機能１５２４にはそれらのＬＩＤが予めポピュレートされ得るとともに、仮想機能２５２５および仮想機能３５２６にはそれらのＬＩＤが動的に割当てられている（すなわち、仮想機能２５２５は動的ＬＩＤ割当てのために利用可能であり、仮想機能３５２６は、仮想マシン３５５２が付与されているので、１１というＬＩＤが動的に割当てられている）。最後に、ハイパーバイザ３５３１に関連付けられた機能（物理機能および仮想機能）にはそれらのＬＩＤを動的に割当てることができる。これにより、結果として、仮想機能１５３４および仮想機能３５３６が動的ＬＩＤ割当てのために利用可能となるとともに、仮想機能２５３５には、仮想マシン４５５３が付与されているので、９というＬＩＤが動的に割当てられている。

ＬＩＤが予めポピュレートされたｖＳｗｉｔｃｈおよび動的ＬＩＤ割当てがなされたｖＳｗｉｔｃｈがともに（いずれかの所与のハイパーバイザ内で独立して、または組合わされて）利用されている、図８に示されるような一実施形態に従うと、ホストチャネルアダプタごとの予めポピュレートされたＬＩＤの数はファブリックアドミニストレータによって定義することができ、（ホストチャネルアダプタごとに）０＜＝予めポピュレートされたＶＦ＜＝総ＶＦの範囲内になり得る。動的ＬＩＤ割当てのために利用可能なＶＦは、（ホストチャネルアダプタごとに）ＶＦの総数から予めポピュレートされたＶＦの数を減じることによって見出すことができる。

インフィニバンド ^ＴＭ −サブネット間通信
一実施形態に従うと、１つのサブネット内にインフィニバンド^ＴＭファブリックを提供することに加え、本開示の実施形態は、２つ以上のサブネットにまたがるインフィニバンド^ＴＭファブリックを提供することもできる。

図１０は、一実施形態に従う例示的なマルチサブネットインフィニバンド^ＴＭファブリックを示す。この図に示されるように、サブネットＡ１０００の内部の多数のスイッチ１００１〜１００４は、サブネットＡ１０００（たとえばＩＢサブネット）内におけるインフィニバンド^ＴＭファブリックなどのファブリックのメンバ間の通信を提供することができる。このファブリックは、たとえばチャネルアダプタ１０１０などの多数のハードウェアデバイスを含み得る。ホストチャネルアダプタ１０１０は、ハイパーバイザ１０１１と対話することができる。ハイパーバイザは、対話の相手であるホストチャネルアダプタとともに、多数の仮想機能１０１４をセットアップすることができる。加えて、ハイパーバイザは、仮想マシンを仮想機能各々に割当てることができる。たとえば、仮想マシン１１０１５は仮想機能１１０１４に割当てられる。ハイパーバイザは、その対応付けられたホストチャネルアダプタに、各ホストチャネルアダプタ上の物理機能１０１３などの十分な機能を有する物理機能を通して、アクセスすることができる。

さらに図１０を参照して、一実施形態に従うと、多数のスイッチ１０２１〜１０２４は、サブネットＢ１０４０（たとえばＩＢサブネット）内におけるインフィニバンド^ＴＭファブリックなどのファブリックのメンバ間の通信を提供することができる。このファブリックは、たとえばホストチャネルアダプタ１０３０などの多数のハードウェアデバイスを含み得る。ホストチャネルアダプタ１０３０は、ハイパーバイザ１０３１と対話することができる。ハイパーバイザは、対話の相手であるホストチャネルアダプタとともに、多数の仮想機能１０３４をセットアップすることができる。加えて、ハイパーバイザは、仮想マシンを仮想機能各々に割当てることができる。たとえば、仮想マシン２１０３５は仮想機能２１０３４に割当てられる。ハイパーバイザは、その対応付けられたホストチャネルアダプタに、各ホストチャネルアダプタ上の物理機能１０３３などの十分な機能を有する物理機能を通して、アクセスすることができる。なお、各サブネット（すなわちサブネットＡおよびサブネットＢ）内に示されているホストチャネルアダプタは１つだけであるが、各サブネット内に複数のホストチャネルアダプタおよびそれらに対応するコンポーネントが含まれていてもよいことが、理解されるはずである。

一実施形態に従うと、各ホストチャネルアダプタはさらに、仮想スイッチ１０１２および仮想スイッチ１０３２などの仮想スイッチに対応付けられていてもよく、上記のように各ＨＣＡは異なるアーキテクチャモデルでセットアップされてもよい。図１０のサブネットはどちらもＬＩＤが予めポピュレートされているｖＳｗｉｔｃｈのアーキテクチャモデルを使用するものとして示されているが、これは、このようなサブネット構成すべてが同様のアーキテクチャモデルに従う必要があることを示唆しようとしているのではない。

一実施形態に従うと、各サブネット内の少なくとも１つのスイッチがルータに対応付けられていてもよい。たとえば、サブネットＡ１０００内のスイッチ１００２はルータ１００５に対応付けられ、サブネットＢ１０４０内のスイッチ１０２１はルータ１００６に対応付けられている。

一実施形態に従うと、サブネットＡ内の仮想マシン１などの発信ソースにおけるトラッフィックを、サブネットＢ内の仮想マシン２などの異なるサブネットを宛先としてそれに向ける場合、トラフィックは、サブネットＡ内のルータ、すなわち、ルータ１００５に向ければよく、そうすると、ルータ１００５はこのトラッフィックをルータ１００６とのリンクを介してサブネットＢに送ることができる。

ファブリックマネージャ
上述のように、インフィニバンド^ＴＭファブリックなどのネットワークファブリックは、ファブリックの各サブネット内の相互接続されたルータを用いることで、複数のサブネットにまたがることができる。一実施形態に従うと、ファブリックマネージャ（図示せず）はホスト上で実現することができる。このホストは、ネットワークファブリックのメンバであり、ファブリック内で使用されることにより、ファブリックの一部である物理リソースおよび論理リソース双方を管理することができる。たとえば、特に、ファブリックリソースを発見すること、物理サーバ間の接続性を制御すること、リアルタイムのネットワーク統計を収集して観察すること、災害復旧（disaster recovery）、およびサービス品質（quality of service：ＱｏＳ）設定を設定することなどの管理タスクを、ユーザは、ファブリックマネージャを通して実行することができる。一実施形態に従うと、ファブリックマネージャは、ファブリック内に規定されたすべてのサブネットにまたがっていてもよい。すなわち、ファブリックマネージャは、リソースがどのサブネットのメンバであるかに関係なく、ファブリックのメンバであるかまたは少なくともファブリックに対応付けられている物理リソースおよび論理リソースを管理することができる。

一実施形態に従うと、ファブリックマネージャはグラフィカルユーザインターフェイス（graphical user interface：ＧＵＩ）を含み得る。ユーザは、ＧＵＩを通して管理機能を実行することができる。ファブリックマネージャＧＵＩは、ユーザがファブリックリソースをモニタリングし制御することを可能にする可視化ツールを取入れてもよい。たとえば、一実施形態において、ユーザは、ファブリック全体のサーバについて、サーバ接続、構成設定およびパフォーマンス統計を、ファブリックインターフェイスを通して見ることができる。ファブリックマネージャＧＵＩを通してモニタリングおよび／または管理することができるファブリック機能のその他の例は、サブネット間ファブリックトポロジーを発見すること、これらのトポロジーの視覚表現を見ること、ファブリックプロファイル（たとえば仮想マシンファブリックプロファイル）を作成すること、および、ファブリックマネージャデータベースを構築し管理することを含む。ファブリックマネージャデータベースは、ネットワークファブリックが必要としネットワークファブリックに関連する、ファブリックプロファイル、メタデータ、構成設定、およびその他のデータを格納することができる。一実施形態に従うと、ファブリックマネージャデータベースはファブリックレベルデータベースである。

加えて、ファブリックマネージャは、どのサブネットがどのルータポートを介してどのパーティション番号を用いて通信することを許可されるかについて、法的なサブネット間接続性を規定することができる。一実施形態に従うと、ファブリックマネージャは、集中型ファブリック管理ユーティリティである。上に挙げた例は限定を意図しているのではない。

一実施形態に従うと、ファブリックマネージャの機能の一部はユーザによって開始されることができ、その他の機能はユーザから引き離されてもよくまたは自動化されてもよい（たとえば、機能の一部は、起動に応じてまたはその他所定のイベント時に、ファブリックマネージャによって実行されてもよい）。

管理イベントの例示的な実施形態において、ユーザは、ファブリックマネージャインターフェイスで、ネットワークファブリックデバイス向けの構成変更を開始してもよい。構成変更要求を受けた後に、ファブリックマネージャは、この構成変更要求が適切に実行されることを保証してもよい。たとえば、ファブリックマネージャは、要求をデバイスに伝え構成変更がデバイスの構成に書込まれることを保証してもよい。一実施形態において、物理デバイスは、構成変更が無事に終了したことをファブリックマネージャに伝える。一実施形態に従うと、それに応じて、ファブリックマネージャはインターフェイスを更新し、要求が実行されたことを視覚的に確認できるようにしてもよい。さらに、ファブリックマネージャは、たとえば災害復旧のためまたはそれ以外の目的のために、デバイスの構成をファブリックマネージャデータベースに永続化（persist）してもよい。

一実施形態に従うと、ファブリックマネージャは、ＧＵＩのいくつかの、すべての、またはより多くの機能を含む、コマンドラインインターフェイスなどのその他のインターフェイスを有し得る。

ファブリックレベルリソースドメイン
上述のように、ファブリックマネージャは、ユーザがファブリックマネージャのインターフェイスを用いてネットワークファブリック全体にわたって管理タスクを実行できるようにする。一実施形態に従うと、ファブリックマネージャのその他の機能は、階層的なロール（role）ベースのアクセス制御を容易にすることである。一実施形態において、ロールベースのアクセス制御は、ファブリックレベルリソースドメインを通して実現される。

一実施形態に従うと、ロールベースのアクセス制御は、ファブリックユーザという概念に基づく。人間であるアドミニストレータからのアクセスおよび外部管理アプリケーションからのアクセスはいずれも、ファブリックインフラストラクチャまたはファブリックリソースのすべてまたはサブセットに対する法的処理を定める認証されたコンテキストを表わすことができる。たとえば、ユーザは、ファブリックにおいて、ユーザプロファイルによって表わすことができる。すなわち、ファブリック内において、ユーザを、そのユーザのプロファイルを作成し属性をこのプロファイルに割当てることによって定義することができる。ユーザプロファイルには、ユーザ名属性およびパスワード属性を割当てることができ、ユーザ名は、ファブリック内で固有であるため、ユーザを一意に特定する。さらに、ユーザプロファイルは、ファブリック内のさまざまなリソースに特定のアクセスレベルを割当てる、ファブリック内に規定された特定の役割に、対応付けられてもよい。一実施形態に従うと、ユーザプロファイルのセットアップは、ファブリックマネージャインターフェイスを通して実現することができる。ユーザプロファイルのすべてまたは一部を、ファブリックマネージャデータベースに格納することができる。加えて、一実施形態において、ファブリックマネージャは、マイクロソフト（登録商標）のアクティブディレクトリまたはＬＤＡＰディレクトリなどの周知のユーザディレクトリと一体化してもよく、または、たとえば遠隔認証のためのＲＡＤＩＵＳネットワーキングプロトコルと一体化してもよい。

一実施形態に従うと、ファブリックマネージャは、ファブリックレベルリソースドメイン（本明細書では「リソースドメイン」または簡単に「ドメイン」と呼ぶ）を通して自身が発見したファブリックリソースを管理することができる。リソースドメインは、ファブリックレベルで規定されたファブリックリソースの論理的なグルーピングである。ファブリックリソースは、物理リソースおよび論理リソース双方を含む。リソースの例の一部は、特に、ファブリックデバイス（ＨＣＡ、物理ノード、およびスイッチなど）、ファブリックプロファイル（仮想マシンファブリックプロファイル、およびユーザプロファイルなど）、仮想マシン、クラウド、および入出力モジュールを含む。

一実施形態に従うと、ファブリックマネージャによって発見され管理されるすべてのファブリックリソースは、デフォルトでファブリック内に存在する（すなわちセットアップまたは構成する必要がない）デフォルトドメイン内にあり、これらのファブリックリソースには、ファブリックマネージャインターフェイスを通してアクセスすることができる。デフォルトドメインは、最高レベルのドメインである、すなわち、その他すべてのリソースドメインに対する親（parent）ドメインであり、その他すべてのリソースドメインはデフォルトドメイン内に存在する。デフォルトドメインはファブリックレベルアドミニストレータに対応付けられる。ファブリックレベルアドミニストレータもデフォルトで存在し、デフォルトでデフォルトドメイン内の管理上の権利を有するように構成される。

一実施形態に従うと、リソースドメインは、階層形式のリソース管理を表わす。たとえば、デフォルトドメインを構成し管理するプロセスは、ファブリックレベルアドミニストレータしか利用できない。しかしながら、子（child）ドメインは、ファブリックレベルアドミニストレータが、デフォルトドメイン内に作成することができる。たとえば、ファブリックレベルアドミニストレータは、子ドメインを作成することができ、ドメインリソースを子ドメインに追加することができる。加えて、ファブリックレベルアドミニストレータは、ドメインレベルの「ドメイン管理」ユーザを作成することができ、ドメイン管理ユーザを子ドメインに追加する（すなわち対応付ける）ことができる。ドメイン管理ユーザをリソースドメインのメンバにすることにより、ドメイン管理ユーザが、子ドメインとそれに含まれるファブリックリソースのサブセットとを管理できるようにする。一実施形態に従うと、ドメイン管理ユーザは、子メインの外部にあるリソース（すなわちこのドメイン管理が対応付けられているレベルと同様のまたはそれよりも高いレベルのリソース）を管理することはできない。しかしながら、ドメイン管理は、リソースドメインの子ドメインとして作成されたリソースドメインに含まれているリソースを管理することができる。一実施形態に従うと、ファブリックマネージャは、リソースドメインの境界が厳密に守られることを保証するセキュリティを提供する役割を担う。

図１１は、リソースドメインの階層構造を示す。図示のように、デフォルトドメイン１１０２がネットワークファブリック１１００内に存在する。ファブリックレベルアドミニストレータ１１１０は、ファブリックレベルリソース１１１２、１１２４、および１１３４の管理のためのアクセス権を有する。ファブリックレベルアドミニストレータ１１１０はまた、新たなリソースドメインをデフォルトドメイン１１０２内に作成し管理することができる。リソースドメイン１１２０および１１３０と、対応するドメインレベルドメイン管理ユーザ１１２２および１１３２とは、ファブリックレベルアドミニストレータ１１１０によって作成されたものである。ドメイン管理ユーザ１１２２は、（ファブリックレベルアドミニストレータ１１１０によりリソースドメイン１１２０に割当てられた）ファブリックリソース１１２４を管理するためのアクセス権を有するが、（より高いレベルの）ファブリックリソース１１１２または（同様のレベルの）ドメインリソース１１３４を管理するためのアクセス権は有しない。同様に、ドメイン管理ユーザ１１３２は、（ファブリックレベルアドミニストレータ１１１０によりリソースドメイン１１３０に割当てられた）ファブリックリソース１１３４を管理するためのアクセス権を有するが、（より高いレベルの）ファブリックリソース１１１２または（同様のレベルの）ドメインリソース１１２４を管理するためのアクセス権は有しない。

管理パーティション
一実施形態に従うと、リソースドメインは、アドミニストレーションまたは（本明細書における呼称である）「管理」パーティションにより、サブネットレベルで表わすことができる。管理パーティションは、サブネットレベルでアクセス権をサブネットリソースに与えるグループメンバーシップを表わす。一実施形態に従うと、管理パーティションのメンバは、管理パーティションに対応付けられているいずれのサブネットリソースへのアクセス権も有するという点において、特権があると考えられる。ファブリックマネージャレベルにおいて、管理パーティションは、リソースドメインと対応するドメイン管理ユーザとに対応付けられる。このようにして、マルチテナント環境においてユーザとロールの分離をサブネットレベルで保証することができる。さらに、特定のリソースドメインに対応付けられている管理パーティションのメンバであるリソースがリソースドメインのメンバにもなるように、リソースドメインメンバーシップを管理パーティションメンバーシップに対応付けることができる。

一実施形態に従うと、管理パーティションは、サブネットレベルにおいて、データパーティションの規定と同じやり方で規定することができるが、作成されたパーティションが管理パーティションであることを示す追加の属性を伴う。（先に詳述した）データパーティションと同様、管理パーティションは、一実施形態に従い、アドミニストレータにより、ファブリックマネージャインターフェイスを通して作成することができる。一実施形態において、ファブリックマネージャは、パーティションの作成中、「管理パーティション」フラグを任意のパラメータとしてサポートすることができる。作成したアドミニストレータによって選択される場合、ファブリックマネージャは、新たに作成されたパーティションが管理パーティションであることを示す追加の属性を含みかつファブリックマネージャおよびローカルマスタサブネットマネージャによって管理パーティションとして扱われるであろう。

一実施形態に従うと、ファブリックマネージャは、作成されたリソースドメインごとに対応する管理パーティションを自動的に作成し、自動的に作成したパーティションを対応するリソースドメインに対応付けるように構成されてもよい。このような実施形態において、ファブリックレベルリソースがリソースドメインに追加されると、ファブリックマネージャはまた、これらを、自動的に作成されリソースドメインに対応付けられた管理パーティションに対応付ける。このように、リソースドメインに追加されたリソースは、アドミニストレータ（たとえばファブリックレベルアドミニストレータまたはドメイン管理）によるさらに他の動作を伴うことなく、リソースドメインに追加されると互いにサブネットレベルアクセス権を有することになる。

加えて、一実施形態に従うと、ネットワークのサブネット全体は、トップレベルドメイン（たとえばデフォルトドメイン）を有するドメイン階層における特別なリソースドメインを表わすことができる。たとえば、ドメイン階層において、デフォルトドメインがトップレベルドメインを表わす場合、ネットワークファブリックの各サブネットは、ファブリックマネージャにより、デフォルトドメインの子ドメインとして認識されることができる。サブネット全体をトップレベルドメインの子ドメインとして認識することを、ファブリックマネージャのデフォルト挙動として構成してもよく、または、これらデフォルトドメインがアドミニストレータによって手作業で定められてもよい。ここでも、ユーザとロールを分離し、ドメイン境界を守り、サブネットレベルにおけるリソースの対応付けを実施するために、サブネットリソースドメイン全体に対応する管理パーティションを規定することができる。一実施形態に従うと、サブネット内に規定され当該サブネット内の各リソース（メンバであるかまたは管理パーティションに対応付けられている）を含む管理パーティションは、「ドメイングローバル」管理パーティションと名付けることができる。なぜなら、この構成の中で、サブネット内のすべてのリソースはその他すべてのリソースへのアクセス権を有するからである。

一実施形態に従うと、管理パーティションは、ドメイン管理にとってトランスペアレントであってもよい。上述のように、ドメイングローバル管理パーティションは、ファブリックマネージャレベルでリソースドメインに対して自動的に作成することができ、その後、このドメインの範囲に割当てられたまたはこのドメインの範囲内に作成されたすべてのリソースを対応する管理パーティションに自動的に対応付けることができる。しかしながら、別の実施形態において、ドメイン管理は、関連するリソースドメイン内に種々の管理パーティションを明示的に作成することができ、その後、当該ドメイン内のリソースを、リソースドメインに対してデフォルトで作成された管理パーティションの代わりに明示的に作成された管理パーティションに対応付けることができる。

一実施形態に従うと、ファブリックマネージャは、共有管理パーティションおよびプライベート管理パーティション双方の作成をサポートできる。デフォルトドメイン内のファブリックレベルアドミニストレータによって作成された管理パーティションは、個々のリソースドメインが利用できるようにすることができる共有パーティションであってもよい。ドメイン管理がメンバであるドメインによって作成された管理パーティションは、そのコンテキストに管理パーティションが作成されている特定のリソースドメインのみに対応付けられ当該特定のリソースドメインのみが利用できるプライベートパーティションであってもよい。

一実施形態に従うと、ＨＣＡおよびｖＨＣＡのエンドポートは、データパーティションのメンバであってもよいのと同じく、管理パーティションのメンバであってもよい。しかしながら、一実施形態に従うと、管理パーティションはその他のサブネットリソースに対応付けることができるという点で、管理パーティションはデータパーティションと区別される。たとえば、データパーティションは管理パーティションに対応付けることができる。さらに、一実施形態に従うと、管理パーティションを子または親としての別の管理パーティションに対応付けることにより、これらの管理パーティションは階層的概念となり、対応付けられているリソースドメインの階層に対応させることができる。

技術的な問題として、従来の専門用語では、ＨＣＡ（およびｖＨＣＡ）のエンドポートをパーティションの「メンバ」と呼ぶことができ、一実施形態に従うと、その他のリソースは管理パーティション「に対応付ける」ことができる。以下、これら２つの概念の技術的相違点について説明する。しかしながら、便宜上かつ読み易さのために、本文献では、管理パーティションについて、「メンバ」および「〜に対応付ける」という表現を区別なく使用する場合がある。これらの表現が区別なく使用されていても、それとは関係なく、管理パーティションへのエンドポート／ＨＣＡのメンバーシップと、管理パーティションに対応付けられたリソースとの間の技術的相違が読み手によって一貫して適用されることを意図していることが理解されるはずである。

一実施形態に従うと、管理パーティションは、データパーティションの規定と同じく、Ｐ＿Ｋｅｙによって規定される。しかしながら、エンドポートは、自身がメンバであるデータパーティションを認識しているものの、エンドポートは自身がメンバであるのがどの管理パーティションなのかを認識している必要はない。よって、一実施形態において、管理パーティションを規定するＰ＿Ｋｅｙは、メンバのエンドポートのＰ＿Ｋｅｙテーブルに入力されない。このように、管理パーティションがＩＢパケットトラッフィック用に使用されなければ、管理パーティションの作成が、限りあるリソースであるＰ＿Ｋｅｙテーブルエントリを無駄に使うことはない。しかしながら、別の実施形態において、管理パーティションは管理パーティションとしてもデータパーティションとしても機能する場合がある。このような実施形態において、管理パーティションのメンバであるエンドポートのＰ＿Ｋｅｙテーブルすべてが、それぞれのＰ＿Ｋｅｙテーブルの管理パーティションのＰ＿Ｋｅｙエントリを有することができる。一実施形態に従うと、データパーティションは、管理パーティションではない何らかのパーティションであると定義してもよい。

管理パーティションをデータパーティションに対応付ける
一実施形態に従うと、データパーティションは１つ以上の管理パーティションに対応付けることができる。たとえば、Ｐ＿Ｋｅｙ値によって規定されるデータパーティションは、自身の固有のＰ＿Ｋｅｙ値によって規定される管理パーティションに対応付けることができる。加えて、このデータパーティションは、別の固有のＰ＿Ｋｅｙ値によって規定される第２の管理パーティションに対応付けることができる。一実施形態に従うと、データパーティションを特定の管理パーティションに対応付けることにより、当該特定の管理パーティションのメンバであるエンドポートの最大メンバーシップレベルを規定することができる。

上述の通り、管理パーティションは、サブネットリソースにアクセス権を与えるグループメンバーシップを表わす。一実施形態に従うと、管理パーティションのどのエンドポートメンバも、当該管理パーティションへのエンドポートのメンバーシップのみに基づいて、同じ管理パーティションに対応付けられているいずれのサブネットリソースへのアクセス権も有する。したがって、管理パーティションのメンバであるエンドポートはいずれも、同じ管理パーティションに対応付けられているいずれのデータパーティションへのアクセス権も有する。なお、これは、メンバエンドポートが、対応付けられたデータパーティションのメンバであることを必ずしも意味しておらず、対応付けられたデータパーティションへのアクセス権を有しそれ故にこのデータパーティションのメンバであり得ることを意味している。

このような手法により、アドミニストレータが、たとえばデータパーティションへのアクセス権を、エンドポートに、データパーティションのＰ＿ＫｅｙをこのエンドポートのＰ＿Ｋｅｙテーブルに手作業で含めることによって与える必要は、なくなる。一実施形態において、エンドポートがサブネット内で初期化されると、マスタサブネットマネージャは、管理パーティションの規定（たとえばＰ＿Ｋｅｙ）を保持するとともに規定された管理パーティションへのメンバーシップを規定しかつ規定された管理パーティションとの対応付けを規定する関係を保持するデータストア（たとえば以下で説明する管理パーティションレジストリ）にクエリすることによって、このエンドポートがメンバであるのはどの管理パーティションかを判断することができる。次に、サブネットマネージャはさらに、エンドポートがメンバである管理パーティションに対応付けられているデータパーティションがあるか否かを確かめるためにチェックすることができる。ＳＭが、１）エンドポートが管理パーティションのメンバであること、および、２）当該管理パーティションがデータパーティションに対応付けられていることを見出した場合、ＳＭは、対応付けられているデータパーティションのＰ＿ＫｅｙをエンドポートのＰ＿Ｋｅｙテーブルに自動的に置くことにより、データパーティションへアクセス権をエンドポートの自動的に与える。このように、管理パーティションは、アドミニストレータによる手作業のパーティションマッピングと比較して、より簡単でよりスケーラブルな解決策を表わす。

図１２は、管理パーティションおよびデータパーティション双方を有する例示的なネットワークファブリックを示す。図１２に示されるように、管理パーティション１２３０、１２４０、および１２５０がファブリック内において規定されている。ノードＡ１２０１〜Ｅ１２０５が、それぞれのＨＣＡ１２１１〜１２１５によってファブリックに物理的に接続されている。加えて、各ＨＣＡは、少なくとも１つの管理パーティションのメンバである。ＨＣＡ１２１１およびＨＣＡ１２１４は、管理パーティション１２３０のメンバである。ＨＣＡ１２１１はまた、ＨＣＡ１２１２および１２１３とともに管理パーティション１２４０のメンバである。ＨＣＡ１２１３はさらに、ＨＣＡ１２１５とともに管理パーティション１２５０のメンバである。

さらに図１２を参照して、一実施形態に従うと、データパーティション１２３２、１２４２、および１２５２がファブリック内に規定されている。データパーティション１２３２は管理パーティション１２３０に対応付けられ、データパーティション１２４２は管理パーティション１２４０に対応付けられ、データパーティション１２５２は管理パーティション１２５０に対応付けられている。一実施形態に従うと、ＨＣＡ１２１１およびＨＣＡ１２１４は、管理パーティション１２３０へのそれぞれのメンバーシップに基づく、データパーティション１２３２へのメンバーシップへのアクセス権を有する。同様に、ＨＣＡ１２１１〜１２１３は、管理パーティション１２４０へのそれぞれのメンバーシップに基づく、データパーティション１２４２へのメンバーシップへのアクセス権を有する。加えて、ＨＣＡ１２１３および１２１５は、管理パーティション１２５０へのそれぞれのメンバーシップに基づく、データパーティション１２５２へのメンバーシップへのアクセス権を有する。

一実施形態に従うと、サブネットマネージャ（たとえばマスタサブネットマネージャ）は、１）サブネット内のどのエンドポートが当該サブネット内で規定されているどの管理パーティションのメンバであるか、および、２）サブネット内で規定されているどのデータパーティションがサブネット内で規定されているどの管理パーティションに対応付けられているかを規定する、格納されているデータに、アクセスすることができる。このような情報にアクセスすることにより、ＳＭは、エンドポートからの、データパーティションへのメンバーシップの動的要求に、応えることができる。データパーティションへのエンドポートのメンバーシップを、エンドポートが（ＨＣＡを通して）動的に要求しＳＭが動的に付与する（または拒否する）機能により、アドミニストレータが、手作業でデータパーティションのＰ＿ＫｅｙをエンドポートのＰ＿Ｋｅｙテーブルに含めることによってデータパーティションへのアクセス権をエンドポートに明示的に与える必要が、なくなる。結果として管理上のオーバーヘッドが大幅に減じられる。

上述のように、ＳＭは、規定された管理パーティションからデータパーティションへの対応付けと、管理パーティションへのエンドポートのメンバーシップを規定する情報とに、アクセスすることができる（この情報を本明細書ではまとめて「管理パーティション対応付け情報」と呼ぶことがある）。一実施形態に従うと、管理パーティション対応付け情報は、管理パーティション対応付け情報にＳＭがアクセスし易いように、規定し永続化することができる。たとえば、先に述べたように、管理パーティションおよびデータパーティションは、サブネットレベルにおいてＰ＿Ｋｅｙによって表わすことができる。サブネットにおいてＰ＿Ｋｅｙによって規定された所与の管理パーティションに対し、サブネットにおいてこれもＰ＿Ｋｅｙによって規定された１つ以上のデータパーティションそれぞれを当該所与のパーティションにマッピングする１つ以上の関係が存在し得る。この（管理パーティション）Ｐ＿Ｋｅｙと（データパーティション）Ｐ＿Ｋｅｙとの関係は、所与の管理パーティションに対するデータパーティションの対応付けを規定することができ、この関係は管理パーティション対応付け情報の１要素として含まれる。

上述のように、管理パーティション対応付け情報はまた、管理パーティションへのエンドポートのメンバーシップを規定する情報を含み得る。一実施形態に従うと、先に述べたように、エンドポートはサブネットレベルにおいてＧＵＩＤによって表わされる（または、エンドポートがｖＨＣＡのエンドポートであればｖＧＵＩＤによって表わされる。しかしながら、一実施形態に従うと、ＧＵＩＤのフォーマットとｖＧＵＩＤのフォーマットは同一の場合があるのでＳＭにとっては同じように見える可能性がある）。したがって、一実施形態に従うと、管理パーティションへのエンドポートのメンバーシップは、サブネットレベルにおいて、ＧＵＩＤと管理パーティションＰ＿Ｋｅｙとの関係を通して、規定することができる。

加えて、一実施形態に従うと、管理パーティションとデータパーティションとの対応付けを規定する管理パーティション対応付け情報と、サブネット内の管理パーティションへのエンドポートのメンバーシップとは、格納されている情報にＳＭがアクセスできるようにする何らかの適切なフォーマットで格納されてもよい。たとえば、ある例示的な実施形態において、Ｐ＿Ｋｅｙは、関係の規定にデリミタを使用するフラットファイルにおいて互いにマッピングすることができる。別の実施形態において、Ｐ＿Ｋｅｙは、階層ＸＭＬフォーマットのような半構造化フォーマットで互いにマッピングすることができる。さらに他の例示的な実施形態において、Ｐ＿Ｋｅｙは、リレーショナルデータベースなどの完全構造化フォーマットを用いて互いにマッピングすることができる。ＳＭが情報にアクセスできるように管理パーティション対応付け情報を格納する適切な方法は多数あり上記例が限定を意図していないことを、当業者は理解するであろう。

図１３は、一実施形態に従う、管理パーティション対応付け情報を格納するための例示的なデータストア１３００を示す。データストア１３００はリレーショナルデータベース図におけるテーブルとして示されているが、その理由は、このような図は、関連するコンポーネント間の関係を示すからである。しかしながら、図１３は、管理パーティション対応付け情報間の関係を説明することを意図しているのであって、限定することを意図している訳ではない。上述のように、何らかの適切なデータ構造は本発明の実施形態を提供することができる。実際、ある例示的な実施形態は、ファブリックにおいていくつかの異なるフォーマットで複製された管理パーティション対応付け情報を含み得る。この場合の各フォーマットはファブリック内の異なる主目的に適しかつその目的を満足させる。

図１３に示されるように、管理パーティションテーブル１３１２は、サブネット内の管理パーティションを規定する少なくとも１つの管理パーティションＰ＿Ｋｅｙ１３０２を含み得る。データパーティションテーブル１３１６は、当該サブネット内のデータパーティションを規定する少なくとも１つのデータパーティションＰ＿Ｋｅｙ１３１４を含み得る。ＧＵＩＤテーブル１３０８は、当該サブネット内のエンドポートを表わす少なくとも１つのＧＵＩＤ１３２０を含み得る。示されているエンドポートは、当該サブネット内のノードのＨＣＡ（またはｖＨＣＡ）のエンドポートであってもよい。たとえば、ＧＵＩＤテーブル１３０８は、各ＧＵＩＤを特定のＨＣＡに対応付けるＨＣＡインスタンスＩＤ１３２２を含み得る。ＨＣＡインスタンスＩＤ１３２２は、対応付けられた特定のＨＣＡの固有のＩＤであってもよい。

引き続き図１３を参照して、管理パーティション＿データパーティションマッピングテーブル１３２４は、関係１３５２および関係１３５４によって作成される。管理パーティション＿データパーティションマッピングテーブル１３２４により、ＳＭ（図示せず）は、どの管理パーティションＰ＿Ｋｅｙ１３０２がどのデータパーティションＰ＿Ｋｅｙ１３１４に対応付けられているかを示すデータにアクセスできる。たとえば、サブネットマネージャは、特定の管理パーティションＰ＿Ｋｅｙ１３０２に対応付けられている各データパーティションＰ＿Ｋｅｙ１３１４を返すようデータストア１３００にクエリすることができる。同様に、ＳＭは、特定のデータパーティションＰ＿Ｋｅｙ１３１４が対応付けられている各管理パーティションＰ＿Ｋｅｙ１３０２を求めてデータストア１３００にクエリすることができる。

図１３をさらに参照して、管理パーティション＿ＧＵＩＤマッピングテーブル１３１８は、関係１３５６および関係１３５８を用いて作成されている。管理パーティション＿ＧＵＩＤマッピングテーブル１３１８により、ＳＭ（図示せず）は、どの管理パーティションＰ＿Ｋｅｙ１３０２がどのＧＵＩＤ１３２０に対応付けられているかを示すデータにアクセスできる。ＧＵＩＤはサブネットにおけるＨＣＡのエンドポートを表わすことができるので、ＳＭは、この情報を用いることにより、所与のエンドポートが所与の管理パーティションのメンバであるか否かを判断することができる。たとえば、サブネットマネージャは、特定のＧＵＩＤ１３２０に関連する各管理パーティションＰ＿Ｋｅｙ１３０４（すなわち所与のＧＵＩＤがどの管理パーティションの「メンバ」であるか）を返すよう、データストア１３００にクエリすることができる。

一実施形態に従うと、管理パーティション対応付け情報は、これまでに開示したものと比較して、より多くの、より少ない、または異なるデータを含み得る。加えて、管理パーティション対応付け情報は、ファブリックを通したさまざまな動作を簡単にするために、その他の情報に関連付けることができる。

上述のように、管理パーティション対応付け情報は、管理パーティション対応付け情報にＳＭがアクセスできるようしかつ格納されている関係からメンバおよび対応付けをＳＭが判断できるようにする何らかのフォーマットで、格納することができる。たとえば、一実施形態に従うと、管理パーティション対応付け情報はファブリックデータベースに格納することができる。管理パーティション対応付け情報を保持するテーブルは、ファブリックデータベースのサブセットであってもよく、図１３に示されていない他のテーブルとの関係を含み得る。別の実施形態に従うと、管理パーティション対応付け情報は、ＳＭ上の常駐メモリに（たとえばパーティション構成ファイルに）格納することができる。さらに他の実施形態に従うと、管理パーティション対応付け情報データストアは、ＳＭの揮発性ランダムアクセスメモリ（ＲＡＭ）内のキャッシュに保持される記録であってもよい。管理パーティション対応付け情報データストアをＲＡＭにおいて保持することには、高速ルックアップ時間、ひいてはＳＭおよびファブリックインフラストラクチャに課されるオーバーヘッドが少ないという利点がある。ＳＭの起動時に、ＳＭは、たとえばファブリックデータベースまたはパーティション構成ファイルからＲＡＭに管理パーティション対応付け情報を読込むことができる。いかなる更新も、永続化のために、ファブリックデータベースかパーティション構成ファイルのいずれかに書戻すことができる。さらに、ファブリックデータベースまたはパーティション構成ファイルは、災害復旧のためにバックアップしておいてもよい。

図１４は、一実施形態に従う、データパーティションへのメンバーシップを動的に要求して受けるエンドポートを示す例示的なフローチャートである。

ステップ１４０２において、図１２および図１３をさらに参照すると、エンドポート１２１４は、データパーティション１２３２へのメンバーシップを求めて、その対応付けられたＧＵＩＤ１３２０を含む要求をサブネットマネージャ１２０２に送る。

ステップ１４０４において、ＳＭ１２０２は、この要求を受け、ＧＵＩＤ１３２０がメンバである各管理パーティションのＰ＿Ｋｅｙ１３０２を求めてデータストア１３００にクエリする。

ステップ１４０６において、ＳＭ１２０２は、エンドポート１２１４のＧＵＩＤ１３２０がメンバである管理パーティションのＰ＿Ｋｅｙ１３０２のリストを、データストア１３００から受ける。

ステップ１４０８において、ＳＭ１２０２は、データストア１３００から返されたリストに基づいて、ＧＵＩＤ１３２０がいずれかの管理パーティションのメンバであるか否か判断する。このリストが空（またはヌル）である場合、すなわちエンドポート１２１４がいずれかの管理パーティションのメンバではない場合、このプロセスは最後のステップ１４１０に進む。なぜなら、エンドポート１２１４は、管理パーティションへのメンバーシップにより得られるいずれかのデータパーティションへの本来のアクセス権を有していないからである。しかしながら、このリストが少なくとも１つのエントリを有する場合、プロセスはステップ１４１２に進む。

ステップ１４１２において、ＳＭ１２０２は、ステップ１４０６において返されたいずれかの管理パーティションＰ＿Ｋｅｙに対応付けられたデータパーティションＰ＿Ｋｅｙのリストを求めてデータストア１３００にクエリする。

ステップ１４１４において、ＳＭ１２０２は、ステップ１４０６で返されたいずれかの管理パーティションＰ＿Ｋｅｙに対応付けられたデータパーティションＰ＿Ｋｅｙのリストを受ける。

ステップ１４１６において、ＳＭは、データパーティション１２３２−ステップ１４０２でエンドポート１２１４がメンバーシップを要求したデータパーティション−が、返されたリストに含まれているか否かを判断する。データパーティション１２３２のＰ＿Ｋｅｙがこのリストに含まれていなければ、プロセスはステップ１４１８に進んで終了するが、データパーティション１２３２を表わすＰ＿Ｋｅｙがリストに含まれていれば、プロセスはステップ１４２０に進む。

ステップ１４２０において、サブセットマネージャは、データパーティション１２３２を表わす返されたＰ＿Ｋｅｙを、エンドポート１２１４のＰ＿Ｋｅｙテーブルに格納することにより、エンドポート１２１４をデータパーティション１２３２のメンバにする。そしてこのプロセスは終了する。

図１４は、ステップ１４０４および１４１２においてＳＭがデータストアに対して２つの要求を行なうことを示している。しかしながら、これは、エンドポートが１）いずれかの管理パーティションのメンバであるか否かを判断し、そうであれば、２）エンドポートがメンバである管理パーティションが、それに対応付けられている要求されたデータパーティションを有するか否かを判断するために、サブネットマネージャが使用し得る情報を、説明することを意図している。ＳＭからデータストアに対するこの情報の要求はデータストアの１つのクエリまたはデータストアの複数のクエリで行ない得ること、および、図１４はこの点において限定を意図している訳ではないことが、理解されるはずである。

一実施形態に従うと、データパーティションも管理パーティションも識別名によって表わすことができる。再び１３を参照すると、データパーティション識別名１３０６および管理パーティション識別名１３０４は、管理パーティション対応付け情報に含めることができる。管理パーティションまたはデータパーティションいずれかのＰ＿Ｋｅｙにマッピングされている識別名を含めることにより、ＨＣＡはこの識別名を用いてデータパーティションのセットアップを要求できる。ホストスタック／ＨＣＡによるパーティションのハンドリングのベースになる識別名をＨＣＡが使用できるようにすることの主な利点は、サブネットレベルで管理パーティションまたはデータパーティションを表わしパーティションの識別名にマッピングされるＰ＿Ｋｅｙ値を、実行時に割当てることができる点、および／または異なるシステム構成において変更できる点にある。

たとえば、一実施形態に従うと、ファブリックホストを初期化してもよく、初期化プロセスの一部として、ＨＣＡはデータパーティションへのメンバーシップを求める要求を、当該パーティションのＳＭに送ってもよい。メンバーシップを求める要求は、物理エンドポートまたはＨＣＡに対応付けられた仮想エンドポート（ｖＨＣＡ）に対するものであってもよい。初期化を促す構成は、データパーティションのＰ＿Ｋｅｙではなく、ＨＣＡがメンバーシップを要求する対象であるデータパーティションの識別名を特定してもよい。この場合、データパーティションを表わす実際のＰ＿Ｋｅｙがサブネットにおいてまだ生成されていない可能性がある（たとえば、要求が出された時点においてデータパーティションＰ＿Ｋｅｙ１３１４フィールドが空であるまたはヌルである可能性がある）。ＳＭは、要求があったときにＰ＿Ｋｅｙを生成し、管理パーティション対応付け情報を生成したＰ＿Ｋｅｙでポピュレートすることができる。加えて、パーティションを表わすＰ＿Ｋｅｙは、ホストレベルで再構成しなくても、動的に変更することができる。たとえば、ファブリックレベルのサブネットマージまたはファブリックのその他の侵入型再構成の場合であって既存のＰ＿Ｋｅｙ値を変更する必要があり得る場合（たとえば複製を避けるために）、ＳＭは、新たなＰ＿Ｋｅｙ値を管理パーティション対応付け情報に割当てるだけでよいであろう。次に、これらの新たなＰ＿Ｋｅｙを、管理パーティション対応付け情報データのクエリを通して更新Ｐ＿Ｋｅｙをどのホストが受けるべきか判断することにより、ホストにプッシュすることができる。

一実施形態に従うと、データパーティションを特定するために使用する識別名は、ファブリック全体にわたって固有である必要はなく、サブネット全体にわたって固有である必要もない。識別名は、所与のＨＣＡがメンバであるすべての管理パーティションからなる組に対して固有であれば十分である、すなわち、識別名は、ＨＣＡまたはエンドポートがメンバであるすべての管理パーティションに対応付けられているデータパーティションの組の中の１つのデータパーティションに対応付けられているだけでよい。このようにして、異なる管理パーティションのメンバである同様に構成されたノード（すなわち同じパーティション識別名を用いてデータパーティションメンバーシップを要求するように構成されたノード）は、データパーティションへのメンバーシップを、同一の明確に規定された識別名を用いて要求し得るが、実際のデータパーティションＰ＿Ｋｅｙ値へのマッピングは、管理パーティションおよび識別名双方の関数として規定されるであろう。よって、個々のノードは、メンバーシップを要求する対象がどのデータパーティションの識別名であるかという点において、同一の基本構成を有し得るが、各エンドノードまたはＨＣＡの管理パーティション対応付けにより、これらの名前が実際にマッピングされるのがどのデータパーティションであるかが、決まるであろう。

図１５Ａおよび図１５Ｂは、一実施形態に従うパーティションへのメンバーシップを動的に割当てるためのフローチャートを示す図である。

ステップ１５１２において、ネットワークファブリックのサブネット内で動作するように構成されたサブネットマネージャがサブネット内に与えられ、サブネットは複数のノードを含み、複数のノードは少なくとも１つのスイッチと複数のエンドノードとを含み、サブネットマネージャは複数のノードのうちの１つの上で実行される。

ステップ１５１４において、データストアがファブリック内に与えられ、このデータストアはサブネットマネージャからアクセス可能である。

ステップ１５１６において、データストアは、第１のパーティションを特定する第１のＰ＿Ｋｅｙと第２のパーティションを特定する第２のＰ＿Ｋｅｙとサブネット固有エンドポート識別子とを保持するように構成される。

ステップ１５１８において、データストアはさらに、第１のＰ＿Ｋｅｙと第２のＰ＿Ｋｅｙとの間の第１の関係と、第１のＰ＿Ｋｅｙとサブネット固有エンドポート識別子との間の第２の関係とを維持するように構成される。

ステップ１５２０において、サブネットマネージャは、複数のエンドノードのうちの要求を出したエンドノードのホストチャネルアダプタ（ＨＣＡ）から、要求を出したノードのＨＣＡのエンドポートの、第２のパーティションへのメンバーシップを求める要求を受け、この要求は、第２のパーティションの識別子と、サブネット固有エンドポート識別子とを含み、ＨＣＡのエンドポートは、サブネット固有エンドポート識別子により、サブネットにおいて一意に特定される。

ステップ１５２２において、サブネットマネージャは、サブネット固有エンドポート識別子に関連するＰ＿Ｋｅｙの第１のリストをデータストアに要求する。

ステップ１５２４において、サブネットマネージャは、第１のＰ＿Ｋｅｙをデータストアから受ける。

ステップ１５２６において、サブネットマネージャは、第１のＰ＿Ｋｅｙに関連するＰ＿Ｋｅｙの第２のリストをデータストアに要求する。

ステップ１５２８において、サブネットマネージャは、第２のＰ＿Ｋｅｙをデータストアから受ける。

ステップ１５３０において、サブネットマネージャは、ＨＣＡのエンドポートのＰ＿Ｋｅｙテーブルを第２のＰ＿Ｋｅｙでポピュレートする。

管理パーティションをＨＣＡに対応付ける
一実施形態に従うと、管理パーティションは、物理ＨＣＡの仮想機能をｖＨＣＡに登録できるか否かを判断するために使用することもできる。一実施形態に従うと、ｖＨＣＡは、特定の仮想マシン（ＶＭ）のために計画され構成されたホストチャネルアダプタを表わす。ｖＨＣＡはＶＭとともにマイグレートするのに対し、ＶＦは物理アダプタとともに留まっているという点において、ｖＨＣＡは仮想機能（ＶＦ）と異なる。しかしながら、上述のように、物理ＨＣＡもｖＨＣＡも（また、より低いレベルでは、これらの（ｖ）ＨＣＡのエンドポートも）管理パーティションのメンバになり得る。よって、一実施形態に従うと、管理パーティションへのメンバーシップを、ＳＭが使用することにより、物理ＨＣＡからの要求である、この要求を出している物理ＨＣＡの仮想機能をｖＨＣＡに登録することを求める要求が許可可能か否かを、判断することができる。

図１６は、一実施形態に従う、ＨＣＡおよびｖＨＣＡを管理パーティションのメンバとして有する例示的なネットワークファブリックを示す。図１６に示されるように、サブネット１６０２はネットワークファブリック１６００の一部である。ＨＣＡ１６１０、１６２４、１６３２、および１６４４は、サブネット１６０２内でそれぞれのエンドポートを通してネットワークファブリック１６００に物理的に接続されている物理ＨＣＡを表わす。ＨＣＡ１６１０は、物理機能（ＰＦ）１６１２と仮想機能（ＶＦ）１６１４および１６１６とに対応付けられている。ＨＣＡ１６２４は、ＰＦ１６２６とＶＦ１６２８および１６２９とに対応付けられている。ＨＣＡ１６３２は、ＰＦ１６３４とＶＦ１６３６および１６３８とに対応付けられている。ＨＣＡ１６４４は、ＰＦ１６４６とＶＦ１６４８および１６４９とに対応付けられている。さらに、ｖＨＣＡ１６２０は、ＶＦ１６１４が登録され仮想マシン（ＶＭ）１６１８に対応付けられたものとして示されている（すなわち、ＶＭ１６１８は、ネットワークファブリック１６００へのアクセス権を、ｖＨＣＡ１６２０を通して取得し、最終的には物理ＨＣＡ１６１０を通して取得する）。ｖＨＣＡ１６４０は、ＶＦ１６３７が登録されＶＭ１６３８に対応付けられている。

引き続き図１６を参照して、図示の通り、ＨＣＡ１６１０および１６２４ならびにｖＨＣＡ１６２０は、管理パーティション１６５０のメンバである。加えて、ＨＣＡ１６３２および１６４４ならびにｖＨＣＡ１６４０は、管理パーティション１６６０のメンバである。結果として、ＨＣＡ１６１０および１６２４ならびにｖＨＣＡ１６２０は各々管理パーティション１６５０のメンバであるため、ｖＨＣＡ１６２０に、ＨＣＡ１６１０のＶＦ１６１４もしくは１６１６を、またはＨＣＡ１６２４のＶＦ１６２８もしくは１６２９を正式に登録することができる。同様に、ＨＣＡ１６３２および１６２４ならびにｖＨＣＡ１６４０が各々管理パーティション１６６０のメンバであるため、ｖＨＣＡ１６４０に、ＨＣＡ１６３０のＶＦ１６３６もしくは１６３８を、またはＨＣＡ１６４４のＶＦ１６４８もしくは１６４９を、正式に登録することができる。

上述のように、ファブリックレベルのファブリックデータベースは、ファブリックおよびファブリックリソースに関連する情報を保持し、ファブリックマネージャによって管理される。一実施形態に従うと、ファブリックデータベースは、ファブリックリソースのインベントリーの「完全な知識」を有することができる（すなわち、ネットワークファブリックの一部であるすべてのリソースは、少なくともファブリックデータベースに保持されている記録によって表わされる）。さらに、ファブリック内の各リソースに対応付けられたアクセス権およびネームスペースは、ファブリックデータベースに格納されても、ファブリックデータベースに含まれる情報および関係から導出することも、可能である。

たとえば、一実施形態に従うと、管理パーティションへのメンバーシップおよび／または管理パーティションに対するリソースの対応付けに関する情報は、ファブリックデータベースに格納できる。この情報を保持するテーブルと、これらのテーブルをまとめてリンクする関係とは、ファブリックデータベースのサブセットであってもよく、管理パーティションレジストリと呼ぶことができる。一実施形態に従うと、管理パーティションレジストリは、管理パーティショングループリソースを集めたものである。たとえば、管理パーティションレジストリ内の管理パーティショングループは、特定の管理パーティションのＨＣＡメンバ（ｖＨＣＡを含む）と、対応付けられたリソースとを集めたものであってもよく、このグループは、当該特定の管理パーティションを規定するＰ＿Ｋｅｙによってルックアップされる。加えて、管理パーティショングループのメンバおよび対応付けられたリソースを、メンバＨＣＡもしくはｖＨＣＡそれぞれに対するＧＵＩＤもしくはｖＧＵＩＤなどのキー、または、対応付けられたデータパーティションに対するＰ＿Ｋｅｙを用いて、レジストリ内でルックアップすることができる。管理パーティションのＰ＿Ｋｅｙと、メンバまたは対応付けられたリソースの固有識別子との間の関係はそれぞれ、管理パーティションへのメンバーシップまたは対応付けを規定し、管理パーティションレジストリによって維持され、より高いレベルではファブリックデータベースによって維持される。

一実施形態に従うと、管理パーティションレジストリのすべてまたは一部は、記録としてＳＭのキャッシュに保持されていてもよい。たとえば、特定のサブネットのリソースに対応する管理パーティションレジストリの記録を、当該特定のサブネットのサブネットマネージャ（たとえばマスタサブネットマネージャ）の常駐メモリのキャッシュに複製することができる。管理パーティションレジストリの記録は、（たとえばＳＭがブートするときは）ＳＭによってファブリックデータベースから取出され（すなわちコピーされ）てもよく、または、ファブリックデータベースに永続化される前にキャッシュに置かれてもよい。キャッシュは、揮発性または不揮発性メモリであってもよい。いつレジストリ記録がキャッシュに置かれるかには関係なく、管理パーティションレジストリのキャッシュされたコピーと、ファブリックレベルデータベースで発見された管理パーティションレジストリのコピーとの間には、同期が成立し得る。

クエリを受けるたびに管理パーティション情報を永続化状態から（すなわちファブリックデータベースから）取出すのではなく、ＳＭ上の高速キャッシュ内の管理パーティションレジストリのうちのすべてまたはサブネット関連部分を保持することにより、管理パーティション情報のルックアップがＳＭに課すオーバーヘッドは最小になる。これは特に、サブネットリソース間でアクセス権が自動的に割当てられるときのサブネット初期化中において重要である。

一実施形態に従うと、論理名または識別子は、リソースドメイン内のリソースに割当てることができる（たとえばファブリックレベルまたはドメインレベルの管理ユーザによって）。これらの論理名は、リソースドメインにとってプライベートなものであってもよい。ファブリックマネージャは、ファブリックデータベースを通して、ファブリック内で使用される固有の識別子（たとえばｖＧＵＩＤおよびＰ＿Ｋｅｙ）をファブリック内のリソースに与えられた論理または識別名にマッピングする関係を作成することができる。

たとえば、一実施形態に従うと、ファブリックデータベースは、リソースの記録、およびリソースのドメインメンバーシップおよび／または管理パーティションメンバーシップを格納することができる。論理名は、ファブリックマネージャによってリソースが発見されると、リソースに割当てることができる。これらの名称は、ファブリックデータベース内のファブリックリソースの固有識別子にリンクさせることができる。加えて、ファブリックマネージャは、ファブリックマネージャデータベース内の関係を通して、リソースドメインおよび管理パーティションへの各リソースのメンバーシップを追跡することができる。これらの記録および関係を用いて、ファブリックマネージャは、全く異なるリソースドメインおよび管理パーティションにおける同様の論理名を可能にする。一実施形態に従うと、論理ドメイン名スキームは、特定のドメインリソースがメンバである１つまたは複数のリソースドメインの階層を反映することができる。このような実施形態において、論理リソース名は、リソースがメンバである最高レベルのリソースドメインに固有であってもよい。

一実施形態に従うと、ファブリックにおけるリソースの識別子は、この識別子が何であるかに関わらず、管理パーティションの範囲内で固有であってもよい。そうすると、リソース名を、対応する管理パーティションでプレフィックスすることにより、グローバルな固有性（すなわちファブリックレベルで）を得ることができる。

図１７は、一実施形態に従う、リソースドメインおよび管理ドメイン双方を有する例示的なネットワークファブリックを示す。図１７に示されるように、ファブリックマネージャ１７０２はネットワークファブリック１７００上で実行している。一実施形態に従うと、ファブリックマネージャ１７０２は、ネットワークファブリック１７００のノード（図示せず）から実行することができる。ファブリックマネージャ１７０２は、ファブリックレベルアドミニストレータ１７０４によって管理され、ファブリックマネージャデータベース１７１４を含む。管理パーティションレジストリ１７１６は、論理名テーブル１７１８と同様、ファブリックマネージャデータベース１７１４の一部である。

引き続き図１７を参照すると、サブネット１７２０がネットワークファブリック１７００内に規定されている。サブネットマネージャ１７２２は、サブネット１７２０に対応付けられており、一実施形態に従うと、ネットワークファブリック１７００における動作のためにサブネット１７２０が必要とするセマンティックランタイム動作を実行する。サブネット１７２０が必要とするセットアップおよび管理タスクは、ファブリックレベルアドミニストレータ１７０４およびファブリックマネージャ１７０２によって実行されてもよい。

ノード１７４４、１７５４、１７７４および１７８４は、サブネット１７２０の一部である。ＨＣＡ１７４６は、ノード１７４４に対応付けられ、ＰＦ１７４８とＶＦ１７５０および１７５２とを含む。同様に、ＨＣＡ１７５６は、ノード１７５４に対応付けられ、ＰＦ１７５８とＶＦ１７６０および１７６２とを含む。ＨＣＡ１７７６は、ノード１７７４に対応付けられ、ＰＦ１７７８とＶＦ１７８０および１７８２とを含む。さらに、ＨＣＡ１７８６は、ノード１７８４に対応付けられ、ＰＦ１７８８とＶＦ１７９０および１７９２とを含む。ＶＭ１７４０はノード１７４４上で実行しており、ＶＭ１７７０はノード１７７４上で実行している。ｖＨＣＡ１７４２は、ＶＭ１７４０のために計画および構成されており、ＶＭ１７４０に対応付けられ、ＨＣＡ１７４６の仮想機能１７５２が登録されている。ｖＨＣＡ１７７２は、ＶＭ１７７０のために計画および構成されており、ＶＭ１７７０に対応付けられ、ＨＣＡ１７７６の仮想機能１７８２が登録されている。

一実施形態に従うと、ＨＣＡ１７４６、１７５６、１７７６、および１７８６はドメインリソースとみなされ、各々の記録はファブリックマネージャデータベース１７１４に格納される。この記録は、ファブリック内のＨＣＡリソースを特定するために使用されるＧＵＩＤなどの識別子を含み得る。さらに、ｖＨＣＡ１７４２および１７７２も、ドメインリソースとみなされ、各々の記録はファブリックマネージャデータベース１７１４に格納される。この記録は、ｖＨＣＡを特定するために使用されるＧＵＩＤなどの識別子を含み得る。

さらに図１７を参照すると、一実施形態に従い、リソースドメイン１７１０およびリソースドメイン１７１２がファブリックマネージャ１７０２内に作成されている。一実施形態に従うと、ファブリックレベルアドミニストレータ１７０４は、リソースドメイン１７１０およびリソースドメイン１７１２を作成する役割を担う。加えて、ドメイン管理１７０６は、リソースドメイン１７１０に対応付けられたドメインレベルアドミニストレータである。同様に、ドメイン管理１７０８は、リソースドメイン１７１２に対応付けられたドメインレベルアドミニストレータである。一実施形態に従うと、ファブリックレベルアドミニストレータ１７０４は、リソースドメインの階層性に従う、それぞれのリソースドメインの管理として、ドメイン管理１７０６および１７０８を作成することができる。

一実施形態に従うと、管理パーティション１７２４および管理パーティション１７２６は、サブネット１７２０内に規定されている。管理パーティション１７２４はリソースドメイン１７１０に対応付けられ、管理パーティション１７２６はリソースドメイン１７１２に対応付けられている。

図１７に示されるように、ｖＨＣＡ１７４２とＨＣＡ１７４６および１７５６とは、リソースドメイン１７１０のメンバである。一実施形態に従うと、管理パーティション１７２４はリソースドメイン１７１０に対応付けられているので、ｖＨＣＡ１７４２とＨＣＡ１７４６および１７５６とが、リソースドメイン１７１０のメンバとして追加されると、これらは管理パーティション１７２４のメンバにもなり、管理パーティション１７２４を規定するＰ＿ＫｅｙとＨＣＡ１７４６、１７５６およびｖＨＣＡ１７４２の識別子との間の関係が、管理パーティションレジストリ１７１６内に作成される。一実施形態に従うと、この関係は、ＨＣＡ１７４６、１７５６およびｖＨＣＡ１７４２を、管理パーティション１７２４のメンバとして定義する。

同様に、ｖＨＣＡ１７７２とＨＣＡ１７７６および１７８６とは、リソースドメイン１７１２のメンバである。一実施形態に従うと、管理パーティション１７２６はリソースドメイン１７１０に対応付けられているので、ｖＨＣＡ１７７２とＨＣＡ１７６６および１７８６とが、リソースドメイン１７１２のメンバとして追加されると、これらは管理パーティション１７２６のメンバにもなり、管理パーティション１７２６を規定するＰ＿Ｋｅｙと、ＨＣＡ１７７６、１７８６およびｖＨＣＡ１７７２の識別子との間の関係が、管理パーティションレジストリ１７１６内に生成される。一実施形態に従うと、この関係は、ＨＣＡ１７７６、１７８６およびｖＨＣＡ１７７２を、管理パーティション１７２６のメンバとして定義する。

上述のように、一実施形態に従うと、ＶＭ１７４０（ｖＨＣＡ１７４２を含む）、ノード１７４４（ＨＣＡ１７４６を含む）およびノード１７５４（ＨＣＡ１７５６を含む）は、リソースドメイン１７１０のメンバである。本発明の一実施形態において、ファブリックレベルアドミニストレータ１７０４は、ノード１７４４およびノード１７５４をリソースドメイン１７１０に追加する役割を担う。たとえば、ファブリックレベルアドミニストレータ１７０４は、ファブリックマネージャ１７０２のインターフェイスを通して、ノード１７４４および１７５４をリソースドメイン１７１０に追加することができる。ファブリックレベルアドミニストレータ１７０４がノード１７４４および１７５４をリソースドメイン１７１０に追加すると、ドメイン管理１７０６はノード１７４４および１７５４に対して管理タスクを実行することができる。しかしながら、リソースドメインの階層スキームに従うと、ドメイン管理１７０６は、ノード１７４４および１７５４に対して、これらがリソースドメイン１７１０に追加される前に（すなわちこれらがより高いレベルのデフォルトドメイン（図示せず）のメンバである間）、管理タスクを実行することはできない。さらに、一実施形態に従うと、ドメイン管理１７０８は、ノード１７４４および１７５４に対して管理タスクを実行できない。なぜなら、ノード１７４４および１７５４は、ドメイン管理１７０８が対応付けられていないパラレルレベルのリソースドメインのメンバであるからである。

引き続き図１７を参照すると、一実施形態に従い、管理パーティション１７２４および１７２６がサブネット１７２０内に規定されている。リソースドメインの階層スキームに従い、一実施形態では、管理パーティション１７２４および１７２６はファブリックレベルアドミニストレータ１７０４によって規定されたものである。別の実施形態では、ドメイン管理１７０６が管理パーティション１７２４を規定し、ドメイン管理１７０８が管理パーティション１７２６を規定している。一実施形態に従うと、管理パーティション１７２４はリソースドメイン１７１０に対応付けられ、管理パーティション１７２６はリソースドメイン１７１２に対応付けられる。上述のように、一実施形態に従うと、管理パーティション１７２４および１７２６はそれぞれ、サブネットレベルにおいてリソースドメイン１７１０および１７１２を表わす。それぞれのリソースドメインに対応付けられることに加えて、管理パーティション１７２４および１７２６は、それぞれドメイン管理１７０６および１７０８（すなわち、管理パーティション各々が対応付けられているリソースドメインの対応する管理ユーザ）に対応付けられる。上述のように、一実施形態に従うと、管理パーティションとドメインレベル管理との間のこの対応付けによって、サブネットレベルにおけるマルチテナント環境内のユーザとロールの分離を保証することができる。

一実施形態に従い、データパーティション１７２８および１７３０がサブネット１７２０内に規定されている。リソースドメインの階層スキームに従い、一実施形態では、データパーティション１７２８および１７３０がファブリックレベルアドミニストレータ１７０４によって規定されている。別の実施形態では、ドメイン管理１７０６がデータパーティション１７２８を規定し、ドメイン管理１７０８がデータパーティション１７３０を規定している。図１７に示されるように、データパーティション１７２８は管理パーティション１７２４に対応付けられ、データパーティション１７３０は管理パーティション１７２６に対応付けられている。加えて、先に説明し図１７に示しているように、ＨＣＡ１７４６、１７５６およびｖＨＣＡ１７４２は、管理パーティション１７２４のメンバである。結果として、一実施形態に従うと、ＨＣＡ１７４６、１７５６およびｖＨＣＡ１７４２は、データパーティション１７２８が対応付けられている管理パーティション（すなわち管理パーティション１７２４）のメンバであるため、データパーティション１７２８へのアクセス許可を有する。

一実施形態に従い、データパーティション１７２８が管理パーティション１７２４に対応付けられると、データパーティション１７２８の識別子（たとえばデータパーティション１７２８のＰ＿Ｋｅｙ）と、管理パーティション１７２４のＰ＿Ｋｅｙとの間の関係が、管理パーティションレジストリ１７１６内に作成される。この関係は、データパーティション１７２８を、管理パーティション１７２４に対応付けられているものとして定義する。同様に、データパーティション１７３０が管理パーティション１７２６に対応付けられると、データパーティション１７３０の識別子（たとえばデータパーティション１７３０のＰ＿Ｋｅｙ）と管理パーティション１７２６のＰ＿Ｋｅｙとの間の関係が管理パーティションレジストリ１７１６内に作成される。この関係は、データパーティション１７３０を、管理パーティション１７２６に対応付けられているものとして定義する。

一実施形態に従うと、データパーティション１７２８に加わることを求める要求をＨＣＡ１７４６および１７５６またはｖＨＣＡ１７４２から受けた場合、ＳＭ１７２２は、管理パーティションレジストリ１７１６をチェックし、ＨＣＡ１７４６および１７５６ならびにｖＨＣＡ１７４２が管理パーティション１７２４のメンバであることと、データパーティション１７２８が管理パーティション１７２４に対応付けられていることとを見出すことができる。そうすると、ＳＭ１７２２は、ＨＣＡ１７４６および１７５６ならびにｖＨＣＡ１７４２が管理パーティション１７２４のメンバでありデータパーティション１７２８が管理パーティション１７２４に対応付けられていることに基づいて、ＨＣＡ１７４６および１７５６ならびにｖＨＣＡ１７４２が、データパーティション１７２８のメンバになることを許可することができる。ＨＣＡ１７４６および１７５６ならびにｖＨＣＡ１７４２をデータパーティション１７２８に加わらせるのに、ファブリックレベルアドミニストレータ１７０４またはドメインレベルアドミニストレータ１７０６からのマッピングは不要であろう。

加えて、ｖＨＣＡ１７４２には、ＨＣＡ１７４６のＶＦ１７５２もしくは１７５０を、または、ＨＣＡ１７５６のＶＦ１７６２もしくは１７６０を登録することができる。なぜなら、ＨＣＡ１７４６および１７５６ならびにｖＨＣＡ１７４２は、管理パーティション１７２４のメンバであるからである（ｖＨＣＡ１７４２はＶＦ１７５２が登録されたものとして示されている）。ここでもまた、ＳＭ１７２２は、管理パーティションレジストリ１７１６をチェックしてＨＣＡ１７４６および１７５６ならびにｖＨＣＡ１７４２が管理パーティション１７２４のメンバであることを見出すことができる。ＨＣＡ１７４６および１７５６ならびにｖＨＣＡ１７４２が管理パーティション１７２４のメンバであることを発見すると、ＳＭ１７２２は、いかなるファブリックユーザからも介入されることなく、ｖＨＣＡ１７４２に、ＶＦ１７５２、１７５０、１７６２、および１７６０のうちのいずれかを登録することができる。

図１８は、一実施形態に従うリソースドメインメンバーシップを管理パーティションメンバーシップに関連付けるためのフローチャートである。

ステップ１８１０において、リソースドメインがネットワークファブリック内に作成される。

ステップ１８２０において、管理パーティションがネットワークファブリックのサブネット内に作成される。

ステップ１８３０において、リソースドメインは管理パーティションに対応付けられる。

ステップ１８４０において、ファブリックリソースがリソースドメインのメンバとしてリソースドメインに加えられ、ファブリックマネージャは、リソースドメインのすべてのメンバを管理パーティションのメンバにもなるようにすることによって、リソースドメインのリソースメンバーシップを、管理パーティションへのメンバーシップに関連付ける。

図１９は、一実施形態に従う、ファブリックレベルデータベースを用いてリソースグループメンバーシップを管理パーティションメンバーシップに関連付ける方法の詳細なフローチャートである。

ステップ１９１０において、リソースドメインがネットワークのファブリックレベルで作成され、このリソースドメインはファブリックリソースの論理的なグルーピングである。

ステップ１９２０において、ネットワークのサブネット内に管理パーティションが作成される。管理パーティションは第１のＰ＿Ｋｅｙによって規定され、第１のＰ＿Ｋｅｙはサブネット全体にわたって固有である。

ステップ１９３０において、ファブリックレベルデータベースが与えられ、第１のＰ＿Ｋｅｙはファブリックレベルデータベースに格納される。

ステップ１９４０において、リソースドメインは管理パーティションに対応付けられる。

ステップ１９５０において、第１のファブリックリソースがリソースドメインに追加される。第１のファブリックリソースは第１の識別子によって特定される。第１の識別子はファブリックレベルデータベースに格納される。第１のファブリックリソースをリソースドメインに追加することにより、ファブリックレベルデータベースにおいて、第１の識別子と、管理パーティションを規定するＰ＿Ｋｅｙとの間の、第１の関係が作成される。第１の関係は、第１のファブリックリソースを、管理パーティションのメンバとして規定する。

ステップ１９６０において、第２のファブリックリソースがリソースドメインに追加される。第２のファブリックリソースは、第２の識別子によって特定される。第２の識別子はファブリックレベルデータベースに格納される。第２のファブリックリソースをリソースドメインに追加することにより、ファブリックレベルデータベースにおいて、第２の識別子と、管理パーティションを規定するＰ＿Ｋｅｙとの間の、第２の関係が作成される。第２の関係は、第２のファブリックリソースを、管理パーティションのメンバとして規定する。

ステップ１９７０において、第１のドメインリソースおよび第２のドメインリソースは管理パーティションのメンバであると判断される。

ステップ１９８０において、第１のドメインリソースおよび第２のドメインリソースは管理パーティションのメンバであるので、アクセス権が付与される。

スイッチ接続性によって規定される管理パーティションへのメンバーシップ
概略を先に述べたように、管理パーティションは、管理パーティションのメンバであるホストチャネルアダプタ（物理または仮想のいずれか）を有するホストの組によって使用されることができるサブネットリソースのグルーピングを表す。管理パーティションは、サブネットリソースへのアクセス権を付与する予め定められた関係にある管理パーティションメンバをグルーピングするので、アドミニストレータは、アクセスが必要なときまたはその前に、個々のホスト（すなわち個々のホストチャネルアダプタまたはそのエンドポスト）にアクセス権を付与する必要はない。むしろ、メンバの、リソースにアクセスする能力が、管理パーティションへのメンバーシップによって認識され、このようなアクセスを許可するための適切なステップは自動化できる（たとえば、管理パーティションのメンバであるＨＣＡのＰ＿Ｋｅｙテーブルに、管理パーティションに対応付けられたデータパーティションのＰ＿Ｋｅｙを追加する）。

一実施形態に従うと、ＨＣＡを管理パーティションのメンバとして追加することはまた、ＨＣＡが接続される物理スイッチに基づいて自動化することもできる。スイッチ接続性に基づいたホストメンバーシップは、特定のシステム構成において利点を有する。たとえば、特定の高性能コンピューティングシステムは、「エンジニアド・システム（engineered systems）」（ＥＳ）としてプロビジョニングすることができる。このようなエンジニアド・システムは、特定のコンピューティング機能を得るために配置された複数のコンポーネントを含み得る。これらのコンポーネントは、互いに連携して動作することにより特定の機能を得るように設計されたより大きなシステムの部品であり、ＥＳに含まれるホストはこれもＥＳに含まれるリソースへのアクセス権を有するはずであると、間違いなく想定することができる。そうするとさらに、ドメイングローバル管理パーティション（すなわち、すべてのサブネットリソースが対応付けられており各ＨＣＡはメンバである管理パーティションであり、各リソースはサブネット内の他のリソース各々に対するアクセス権を有する）が望ましいと想定することができる。

エンジニアド・システムインスタンスは、リーフスイッチの１つ以上の対に接続されたいくつかの物理サーバを有する１つ以上のラックとして設計されることが多いので、一実施形態に従うと、ＥＳにおいてデプロイされるＨＣＡのドメイングローバル管理パーティションメンバーシップのプロビジョニングは、ＥＸのリーフスイッチによって定めることができる。特定のリーフスイッチが特定の管理パーティションを表す（または特定の管理パーティションに対応付けられる）と定義すると、リーフスイッチに直接接続されているすべてのＨＣＡを、リーフスイッチによって表される管理パーティションに自動的に対応付けることができる。このように、ＥＳにおいて実装された各ＨＣＡは、ＥＳ内の各スイッチが同じ関連管理パーティション情報に対応付けられるものとして構成されている限り、スイッチ接続性に基づいて、ドメイングローバル管理パーティションに含めることができる。

一実施形態に従うと、リーフスイッチの構成情報は、対応付けられた管理パーティションを定めることができる。たとえば、スイッチは、その値が対応付けられた管理パーティションを規定する１つ以上の構成変数を有し得る。これらの構成変数は、対応付けられた管理パーティションの論理名および／または対応付けられた管理パーティションのＰ＿Ｋｅｙなどの値を、保持することができる。これらの構成変数（すなわち構成プロパティ）は、スイッチが交換されたときにバックアップおよびリストアできるより大きなスイッチ構成の一部として（たとえば、ホスト名、ＩＰアドレス、および動作に必要なその他の設定とともに）含めることができる。

図２０は、一実施形態に従う、スイッチ接続性に基づく管理パーティションのメンバとしてのホストチャネルアダプタを示す。図２０は、エンジニアド・システム（ＥＳ）を単一のラック２０００として描いている。ＥＳラック２０００は、ＨＣＡ２００２〜２００５と、リーフスイッチ２０１０および２０２０とを含む。ＨＣＡ２００２および２００３はリーフスイッチ２０１０に接続され、ＨＣＡ２００４および２００５はリーフスイッチ２０２０に接続される。リーフスイッチ２０１０および２０２０はＩＢファブリック２０６２に接続する。ＥＳラック２０００が一部を占める（図示せず）ＩＢサブネットのためのＳＭは、スイッチ２０１０もしくは２０２０上で、または、サブネット内の別のノード上で、実行することができる。

リーフスイッチ２０１０はスイッチ構成（ｃｏｎｆｉｇ）２０１２を含み、スイッチ２０２０はスイッチ構成（ｃｏｎｆｉｇ）２０２２を含む。スイッチ構成２０１２および２０２２はいずれも、構成プロパティを保持することができ、かつ、バックアップおよびリストアされることができる。スイッチ構成２０１２および２０２２は、それぞれのスイッチ構成に保持されているプロパティを通して、スイッチ２０１０および２０２０を管理パーティション２０５０に対応付けることができる。リーフスイッチ２０１０またはリーフスイッチ２０２０いずれかに物理的に接続されているので、ＨＣＡ２００２〜２００５は、ＩＢファブリック２０６２のファブリックデータベース（図示せず）の管理パーティションレジストリ（これも図示せず）に、管理パーティション２０５０のメンバとして、自動的に記録される。

一実施形態に従うと、リーフスイッチのプロパティがデフォルト管理パーティションメンバーシップを規定しているとき、ＳＭは、特定の管理パーティション（たとえば管理パーティション２０５０）に対応付けられているスイッチを発見する、またはそのスイッチを通知されることができる。たとえば、スイッチ２０１０および２０２０は、読取り可能なＳＭＡ属性としてスイッチに対応付けられているデフォルト（たとえばドメイングローバル）管理パーティションがあるか否かを特定する構成プロパティをエクスポーズすることができる。次に、ＳＭは、このプロパティをサブネットのスイープで読取ることができる。これに代えて、スイッチのＳＭＡがトラップメッセージとしてこのプロパティをＳＭに送ってもよい。また、ＳＭは、リーフスイッチに直接接続されたのはどのＨＣＡかを発見するまたはその通知を受けることができる。スイッチが対応付けられている管理パーティションを特定するプロパティと、スイッチに直接接続されているＨＣＡのリストとをＳＭが取得すると、ＳＭは、接続されているＨＣＡとスイッチが対応付けられた管理パーティションとの間の必要な対応付けと、管理パーティションメンバーシップ情報の管理パーティションレジストリへの転送とを行なう役割を担うことができる。

一実施形態に従うと、スイッチ接続性に基づく管理パーティションへのメンバーシップは、パーティションが規定されるときを除いて、リーフスイッチに対応付けられている管理パーティションに対するＰ＿Ｋｅｙを指定することを不要にすることにより、管理上のオーバーヘッドを減じることができる。加えて、メンバＨＣＡに対するＧＵＩＤは、管理パーティションが作成された時点でまたは新たなＨＣＡがシステムに追加された時点で指定する必要はなく、管理パーティションのメンバとして、ＳＭが動的に発見して追加することができる。

たとえば、管理パーティションは、管理パーティションレジストリ内のＰ＿Ｋｅｙおよび論理名で規定することができる。サブネットが初期化されると、ＳＭは、パーティションの論理名を、このパーティションに対応付けられているスイッチから取得するとともに、このスイッチに直接接続されているＨＣＡのリストを受ける。ＨＣＡのリストは、スイッチに直接接続されている各ＨＣＡに対応するＧＵＩＤのリストの形態であってもよい。ＳＭは、ＧＵＩＤのリストとパーティションの論理名とを、管理パーティションレジストリに転送することができ、管理パーティションの論理名は、管理パーティションのＰ＿Ｋｅｙを発見するためのルックアップパラメータとして使用できる。一実施形態に従うと、次に、管理パーティションレジストリを、転送されたリスト内の各ＧＵＩＤを発見した管理パーティションのＰ＿Ｋｅｙに関連付けることによって更新することにより、対応する各ＨＣＡを管理パーティションのメンバにすることができる。

上記シナリオでは、管理パーティションレジストリにおいて管理パーティションのＰ＿Ｋｅｙをその論理名を使用することによってルックアップできるので、スイッチは、管理パーティションの論理名を用いて構成するだけでよい。スイッチが故障した場合は、故障したスイッチを交換し、スイッチ構成を交換スイッチにリストアすることにより、管理上のオーバーヘッドを最小にすることができる。

一実施形態に従うと、管理パーティションレジストリが、スイッチに直接接続されているＨＣＡのＧＵＩＤを用いて更新されると、管理パーティションレジストリに対し、（たとえばＳＭによって）自動的にクエリすることにより、管理パーティションに対応付けられているデータパーティションを取出すことができる。クエリは、管理パーティションに対応付けられているデータパーティションのＰ＿Ｋｅｙを返すことができ、これらのＰ＿Ｋｅｙを、管理パーティションに対応付けられているスイッチに直接接続された各ＨＣＡのＰ＿Ｋｅｙテーブルにロードすることができる。このようにして、データパーティションへのアクセスを、管理上の手間は最小にして、計画しプロビジョニングすることができる。

図２１は、一実施形態に従うスイッチ接続性に基づいて管理パーティションメンバーシップをホストチャネルアダプタに割当てるためのフローチャートである。

ステップ２１１０において、管理パーティションが作成される。
ステップ２１２０において、管理パーティションはスイッチに対応付けられる。

ステップ２１３０において、どのＨＣＡがスイッチに直接接続されているかを判断する。

ステップ２１４０において、スイッチに直接接続されていると判断された各ＨＣＡを、当該スイッチに対応付けられている管理パーティションのメンバにする。

図２２は、一実施形態に従うスイッチ接続性に基づいて管理パーティションへのメンバ−シップをホストチャネルアダプタに割当てるための詳細なフローチャートである。

ステップ２２１０において、ネットワークファブリックのサブネットで使用する管理パーティションが作成される。この管理パーティションは、サブネット内で固有であるＰ＿Ｋｅｙによって規定される。Ｐ＿Ｋｅｙは、サブネットからアクセス可能な管理パーティションレジストリに格納される。

ステップ２２２０において、サブネット内のノードから実行するサブネットマネージャが与えられる。

ステップ２２３０において、サブネットスイッチが管理パーティションに対応付けられたという情報が、サブネットマネージャによって取得される。

ステップ２２４０において、サブネットマネージャは識別子（ＩＤ）のリストを受ける。各識別子は、サブネットスイッチに直接接続されているホストチャネルアダプタに対応する。

ステップ２２５０において、リストからのＩＤ各々が、管理パーティションレジストリに追加される。

ステップ２２６０において、追加されたＩＤ各々とＰ＿Ｋｅｙとの間の関係が、管理パーティションレジストリで作成される。

一実施形態に従うと、パーティションへのメンバーシップを動的に割当てる方法は、ネットワークファブリックのサブネット内で動作するように構成されたサブネットマネージャを与えることを含み、サブネットは複数のノードを含み、複数のノードは少なくとも１つのスイッチと複数のエンドノードとを含み、サブネットマネージャは複数のノードのうちの１つのノード上で実行する。この方法はまた、データストアをファブリック内に与えることを含む。データストアはサブネットマネージャからアクセス可能である。この方法はまた、データストアを、第１のパーティションを特定する第１のパーティションキー（Ｐ＿Ｋｅｙ）と、第２のパーティションを特定する第２のＰ＿Ｋｅｙと、サブネット固有のエンドポート識別子とを保持するように構成することと、データストアをさらに、第１のＰ＿Ｋｅｙと第２のＰ＿Ｋｅｙとの間の第１の関係と、第１のＰ＿Ｋｅｙとサブネット固有のエンドポート識別子との間の第２の関係とを維持するように構成することと、サブネットマネージャが、複数のエンドノードのうちの要求を出したエンドノードのホストチャネルアダプタ（ＨＣＡ）から、第２のパーティションへの、要求を出したノードのＨＣＡのエンドポートのメンバーシップを求める要求を受けることとを含み、この要求は、第２のパーティションの識別子と、サブネット固有のエンドポート識別子とを含み、ＨＣＡのエンドポートは、サブネット固有のエンドポート識別子によってサブネット内で一意に識別される。この方法はまた、サブネットマネージャが、データストアに、サブネット固有のエンドポート識別子に関連付けられたＰ＿Ｋｅｙの第１のリストを要求することと、サブネットマネージャがデータストアから第１のＰ＿Ｋｅｙを受けることと、サブネットマネージャが、データストアに、第１のＰ＿Ｋｅｙに関連付けられたＰ＿Ｋｅｙの第２のリストを要求することと、サブネットマネージャがデータストアから第２のＰ＿Ｋｅｙを受けることと、サブネットマネージャが、ＨＣＡのエンドポートのＰ＿Ｋｅｙテーブルを、第２のＰ＿Ｋｅｙでポピュレートすることとを含む。

一実施形態に従うと、上記方法において、第１のパーティションは、サブネット内の管理パーティションとして第１のパーティションを特定する属性に対応付けられる。

一実施形態に従うと、上記方法において、第２のパーティションの識別子は、第２のパーティションを特定する第２のＰ＿Ｋｅｙである。

一実施形態に従うと、上記方法はさらに、第２のパーティションの識別名を保持するようにデータストアを構成することと、第２のパーティションの識別名と第２のパーティションを特定する第２のＰ＿Ｋｅｙとの間の第３の関係を維持するようにデータストアを構成することとを含む。

一実施形態に従うと、上記方法において、第２のパーティションの識別子は第２のパーティションの識別名である。

一実施形態に従うと、上記方法は、サブネットマネージャが、第２のパーティションを特定する第２のＰ＿Ｋｅｙに関連付けられた第２のパーティションの識別名を、データストアに要求することと、サブネットマネージャが第２のパーティションの識別名をデータストアから受けることとを含む。

一実施形態に従うと、上記方法において、データストアは、サブネットマネージャのランダムアクセスメモリに保持されている記録を含む。

一実施形態に従うと、パーティションへのメンバーシップを動的に割当てるためのシステムは、ネットワークファブリックのサブネット内で動作するように構成されたサブネットマネージャを備え、サブネットは複数のノードを含み、複数のノードは少なくとも１つのスイッチと複数のエンドノードとを含み、サブネットマネージャは複数のノードのうちの１つのノード上で実行する。このシステムはまた、ファブリック内のデータストアを備え、データストアはサブネットマネージャからアクセス可能であり、データストアは、第１のパーティションを特定する第１のパーティションキー（Ｐ＿Ｋｅｙ）と、第２のパーティションを特定する第２のＰ＿Ｋｅｙと、サブネット固有のエンドポート識別子とを保持するように構成されるとともに、第１のＰ＿Ｋｅｙと第２のＰ＿Ｋｅｙとの間の第１の関係と、第１のＰ＿Ｋｅｙとサブネット固有のエンドポート識別子との間の第２の関係とを維持するように構成される。サブネットマネージャは、複数のエンドノードのうちの要求を出したエンドノードのホストチャネルアダプタ（ＨＣＡ）から、第２のパーティションへの、要求を出したノードのＨＣＡのエンドポートのメンバーシップを求める要求を受けるように構成され、要求は、第２のパーティションの識別子と、サブネット固有のエンドポート識別子とを含む。ＨＣＡのエンドポートは、サブネット固有のエンドポート識別子によってサブネット内で一意に特定される。サブネットマネージャはまた、サブネット固有のエンドポート識別子に関連付けられたＰ＿Ｋｅｙの第１のリストをデータストアに要求し、第１のＰ＿Ｋｅｙをデータストアから受け、第１のＰ＿Ｋｅｙに関連付けられたＰ＿Ｋｅｙの第２のリストをデータストアに要求し、データストアから第２のＰ＿Ｋｅｙを受け、ＨＣＡのエンドポートのＰ＿Ｋｅｙテーブルを第２のＰ＿Ｋｅｙでポピュレートするように、構成される。

一実施形態に従うと、上記システムにおいて、第１のパーティションは、サブネット内の管理パーティションとして第１のパーティションを特定する属性に対応付けられる。

一実施形態に従うと、上記システムにおいて、第２のパーティションの識別子は、第２のパーティションを特定する第２のＰ＿Ｋｅｙである。

一実施形態に従うと、上記システムにおいて、データストアはさらに、第２のパーティションの識別名を保持するように、かつ、第２のパーティションの識別名と第２のパーティションを特定する第２のＰ＿Ｋｅｙとの間の第３の関係を維持するように構成される。

一実施形態に従うと、上記システムにおいて、第２のパーティションの識別子は第２のパーティションの識別名である。

一実施形態に従うと、上記システムにおいて、サブネットマネージャはさらに、第２のパーティションを特定する第２のＰ＿Ｋｅｙに関連付けられた第２のパーティションの識別名をデータストアに要求するように、かつ、第２のパーティションの識別名をデータストアから受けるように構成される。

一実施形態に従うと、上記システムにおいて、データストアは、サブネットマネージャのメモリに保持されている記録を含む。

一実施形態に従うと、非一時的なコンピュータ読取可能記憶媒体は、パーティションへのメンバーシップを動的に割当てるために格納された命令を含み、当該命令は、１つ以上のコンピュータによって読出されて実行されると、当該１つ以上のコンピュータに以下のステップを実行させる。これらのステップは、ネットワークファブリックのサブネット内で動作するように構成されたサブネットマネージャを与えるステップを含み、サブネットは複数のノードを含み、複数のノードは少なくとも１つのスイッチと複数のエンドノードとを含み、サブネットマネージャは複数のノードのうちの１つのノード上で実行する。上記ステップはまた、データストアをファブリック内に与えるステップを含み、データストアはサブネットマネージャからアクセス可能である。上記ステップはまた、データストアを、第１のパーティションを特定する第１のパーティションキー（Ｐ＿Ｋｅｙ）と、第２のパーティションを特定する第２のＰ＿Ｋｅｙと、サブネット固有のエンドポート識別子とを保持するように構成するステップと、データストアをさらに、第１のＰ＿Ｋｅｙと第２のＰ＿Ｋｅｙとの間の第１の関係と、第１のＰ＿Ｋｅｙとサブネット固有のエンドポート識別子との間の第２の関係とを維持するように構成するステップと、サブネットマネージャが、複数のエンドノードのうちの要求を出したエンドノードのホストチャネルアダプタ（ＨＣＡ）から、第２のパーティションへの、要求を出したノードのＨＣＡのエンドポートのメンバーシップを求める要求を受けるステップとを含み、この要求は、第２のパーティションの識別子と、サブネット固有のエンドポート識別子とを含む。ＨＣＡのエンドポートは、サブネット固有のエンドポート識別子によってサブネット内で一意に識別される。上記ステップはまた、サブネットマネージャが、データストアに、サブネット固有のエンドポート識別子に関連付けられたＰ＿Ｋｅｙの第１のリストを要求するステップと、サブネットマネージャがデータストアから第１のＰ＿Ｋｅｙを受けるステップと、サブネットマネージャが、データストアに、第１のＰ＿Ｋｅｙに関連付けられたＰ＿Ｋｅｙの第２のリストを要求するステップと、サブネットマネージャがデータストアから第２のＰ＿Ｋｅｙを受けるステップと、サブネットマネージャが、ＨＣＡのエンドポートのＰ＿Ｋｅｙテーブルを、第２のＰ＿Ｋｅｙでポピュレートするステップとを含む。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、第１のパーティションは、サブネット内の管理パーティションとして第１のパーティションを特定する属性に対応付けられる。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、第２のパーティションの識別子は、第２のパーティションを特定する第２のＰ＿Ｋｅｙである。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、上記ステップはさらに、第２のパーティションの識別名を保持するようにデータストアを構成するステップと、第２のパーティションの識別名と第２のパーティションを特定する第２のＰ＿Ｋｅｙとの間の第３の関係を維持するようにデータストアを構成するステップとを含む。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、第２のパーティションの識別子は第２のパーティションの識別名である。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、上記ステップはさらに、サブネットマネージャが、第２のパーティションを特定する第２のＰ＿Ｋｅｙに関連付けられた第２のパーティションの識別名を、データストアに要求するステップと、サブネットマネージャが第２のパーティションの識別名をデータストアから受けるステップとを含む。

一実施形態に従うと、上記コンピュータプログラムは、コンピュータシステムによって実行されると、当該コンピュータシステムに上記方法を実行させる、機械読取可能なフォーマットのプログラム命令を含む。

一実施形態に従うと、上記コンピュータプログラムプロダクトは、非一時的な機械読取可能データ記憶媒体に格納された上記コンピュータプログラムを含む。

一実施形態に従うと、スイッチ接続性に基づいて管理パーティションメンバーシップを割当てる方法は、ネットワークファブリックのサブネット内で使用する管理パーティションを作成することを含み、管理パーティションはサブネット内で固有のＰ＿Ｋｅｙによって規定され、Ｐ＿Ｋｅｙは、サブネットからアクセス可能な管理パーティションレジストリに格納される。上記方法はまた、サブネット内のノードから実行するサブネットマネージャを与えることと、サブネットマネージャが、サブネットスイッチから、当該サブネットスイッチは管理パーティションに対応付けられているという情報を取得することと、サブネットマネージャが識別子（ＩＤ）のリストを受けることとを含み、各ＩＤは、サブネットスイッチに直接接続されているホストチャネルアダプタに対応する。上記方法はまた、リストのＩＤ各々を管理パーティションレジストリに加えることと、管理パーティションレジストリ内に、加えられたＩＤ各々とＰ＿Ｋｅｙとの間の関係を作成することとを含む。

一実施形態に従うと、上記方法において、サブネットマネージャが取得する情報は、サブネットスイッチが対応付けられている管理パーティションのＰ＿Ｋｅｙを含む。

一実施形態に従うと、上記方法はさらに、管理パーティションの論理名を管理パーティションレジストリに格納することと、管理パーティションレジストリ内に、管理パーティションの論理名とＰ＿Ｋｅｙとの間の関係を作成することとを含み、サブネットマネージャが取得する情報は、管理パーティションの論理名を含む。

一実施形態に従うと、上記方法はさらに、サブネットマネージャが、管理パーティションの論理名を、管理パーティションレジストリのクエリにおけるパラメータとして使用することを含み、クエリは、管理パーティションの論理名とＰ＿Ｋｅｙとの間の関係に基づいてＰ＿Ｋｅｙを返す。

一実施形態に従うと、上記方法において、上記情報はサブネットスイッチの構成プロパティに保持され、構成プロパティはサブネットマネージャに対してエクスポーズされる。

一実施形態に従うと、上記方法において、構成プロパティは、スイッチのサブネット管理エージェント属性であり、サブネットマネージャが情報を取得することは、サブネットマネージャがサブネットスイッチのサブネット管理エージェント属性を読取ることを含む。

一実施形態に従うと、上記方法はさらに、サブネットスイッチを与えることを含む。
一実施形態に従うと、スイッチ接続性に基づいて管理パーティションメンバーシップを割当てるためのシステムは、ネットワークファブリックのサブネット内で使用する管理パーティションを含み、管理パーティションは、サブネット内で固有のＰ＿Ｋｅｙによって規定され、Ｐ＿Ｋｅｙは、サブネットからアクセス可能な管理パーティションレジストリに格納される。上記システムはまた、サブネット内のノードから実行するサブネットマネージャを含む。サブネットマネージャは、サブネットスイッチから、当該サブネットスイッチは管理パーティションに対応付けられているという情報を取得し、識別子（ＩＤ）のリストを受けるように動作し、各ＩＤは、サブネットスイッチに直接接続されているホストチャネルアダプタに対応する。サブネットマネージャはまた、受けたリストのＩＤ各々を管理パーティションレジストリに加え、管理パーティションレジストリ内に、加えたＩＤ各々とＰ＿Ｋｅｙとの間の関係を生成させるように動作する。

一実施形態に従うと、上記システムにおいて、サブネットマネージャが取得する情報は、サブネットスイッチが対応付けられている管理パーティションのＰ＿Ｋｅｙを含む。

一実施形態に従うと、上記システムにおいて、管理パーティションの論理名が管理パーティションレジストリに格納され、管理パーティションレジストリ内に、管理パーティションの論理名とＰ＿Ｋｅｙとの間の関係が生成されて維持され、サブネットマネージャが取得する情報は、管理パーティションの論理名を含む。

一実施形態に従うと、上記システムにおいて、サブネットマネージャはさらに、管理パーティションの論理名を、管理パーティションレジストリのクエリにおけるパラメータとして使用するように動作し、クエリは、管理パーティションの論理名とＰ＿Ｋｅｙとの間の関係に基づいてＰ＿Ｋｅｙを返す。

一実施形態に従うと、上記システムにおいて、上記情報はサブネットスイッチの構成プロパティに保持され、構成プロパティはサブネットマネージャに対してエクスポーズされる。

一実施形態に従うと、上記システムにおいて、構成プロパティは、スイッチのサブネット管理エージェント属性であり、サブネットマネージャが情報を取得することは、サブネットマネージャがサブネットスイッチのサブネット管理エージェント属性を読取ることを含む。

一実施形態に従うと、上記システムはさらにサブネットスイッチを含む。
一実施形態に従うと、非一時的なコンピュータ読取可能記憶媒体は、スイッチ接続性に基づいて管理パーティションメンバーシップを割当てるために格納された命令を含み、当該命令は、１つ以上のコンピュータによって読出されて実行されると、当該１つ以上のコンピュータに以下のステップを実行させる。これらのステップは、ネットワークファブリックのサブネット内で使用する管理パーティションを作成するステップを含み、管理パーティションはサブネット内で固有のＰ＿Ｋｅｙによって規定され、Ｐ＿Ｋｅｙは、サブネットからアクセス可能な管理パーティションレジストリに格納される。上記ステップはまた、サブネット内のノードから実行するサブネットマネージャを与えるステップと、サブネットマネージャが、サブネットスイッチから、当該サブネットスイッチは管理パーティションに対応付けられているという情報を取得するステップと、サブネットマネージャが識別子（ＩＤ）のリストを受けるステップとを含み、各ＩＤは、サブネットスイッチに直接接続されているホストチャネルアダプタに対応する。上記ステップはまた、リストのＩＤ各々を管理パーティションレジストリに加えるステップと、管理パーティションレジストリ内に、加えられたＩＤ各々とＰ＿Ｋｅｙとの間の関係を作成するステップとを含む。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、サブネットマネージャが取得する情報は、サブネットスイッチが対応付けられている管理パーティションのＰ＿Ｋｅｙを含む。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、上記ステップはさらに、管理パーティションの論理名を管理パーティションレジストリに格納するステップと、管理パーティションレジストリ内に、管理パーティションの論理名とＰ＿Ｋｅｙとの間の関係を作成するステップとを含み、サブネットマネージャが取得する情報は、管理パーティションの論理名を含む。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、上記ステップはさらに、サブネットマネージャが、管理パーティションの論理名を、管理パーティションレジストリのクエリにおけるパラメータとして使用するステップを含み、クエリは、管理パーティションの論理名とＰ＿Ｋｅｙとの間の関係に基づいてＰ＿Ｋｅｙを返す。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、上記情報はサブネットスイッチの構成プロパティに保持され、構成プロパティはサブネットマネージャに対してエクスポーズされる。

一実施形態に従うと、上記非一時的なコンピュータ読取可能記憶媒体において、構成プロパティは、スイッチのサブネット管理エージェント属性であり、サブネットマネージャが情報を取得するステップは、サブネットマネージャがサブネットスイッチのサブネット管理エージェント属性を読取るステップを含む。

一実施形態に従うと、コンピュータプログラムは、コンピュータシステムによって実行されると、当該コンピュータシステムに上記方法を実行させる、機械読取可能なフォーマットのプログラム命令を含む。

一実施形態に従うと、コンピュータプログラムプロダクトは、非一時的な機械読取可能データ記憶媒体に格納された上記コンピュータプログラムを含む。

この発明の特徴は、ここに提示された特徴のうちのいずれかを行なうように処理システムをプログラミングするために使用可能な命令を格納した記憶媒体またはコンピュータ読取可能媒体であるコンピュータプログラムプロダクトにおいて、それを使用して、またはその助けを借りて実現され得る。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ装置、磁気カードもしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに好適な任意のタイプの媒体もしくは装置を含み得るものの、それらに限定されない。

この発明の特徴は、機械読取可能媒体のうちのいずれかに格納された状態で、処理システムのハードウェアを制御するために、および処理システムがこの発明の結果を利用する他の機構とやり取りすることを可能にするために、ソフトウェアおよび／またはファームウェアに取込まれ得る。そのようなソフトウェアまたはファームウェアは、アプリケーションコード、装置ドライバ、オペレーティングシステム、および実行環境／コンテナを含み得るものの、それらに限定されない。

この発明の特徴はまた、たとえば、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）などのハードウェアコンポーネントを使用して、ハードウェアにおいて実現されてもよい。ここに説明された機能を行なうようにハードウェアステートマシンを実現することは、関連技術の当業者には明らかであろう。

加えて、この発明は、この開示の教示に従ってプログラミングされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用または特殊デジタルコンピュータ、コンピューティング装置、マシン、またはマイクロプロセッサを使用して都合よく実現され得る。ソフトウェア技術の当業者には明らかであるように、この開示の教示に基づいて、適切なソフトウェアコーディングが、熟練したプログラマによって容易に準備され得る。

この発明のさまざまな実施形態が上述されてきたが、それらは限定のためではなく例示のために提示されたことが理解されるべきである。この発明の精神および範囲から逸脱することなく、形状および詳細のさまざまな変更を行なうことができることは、関連技術の当業者には明らかであろう。

この発明は、特定された機能およびそれらの関係の実行を示す機能的構築ブロックの助けを借りて上述されてきた。説明の便宜上、これらの機能的構築ブロックの境界は、この明細書中ではしばしば任意に規定されてきた。特定された機能およびそれらの関係が適切に実行される限り、代替的な境界を規定することができる。このため、そのようないかなる代替的な境界も、この発明の範囲および精神に含まれる。

この発明の前述の説明は、例示および説明のために提供されてきた。それは、網羅的であるよう、またはこの発明を開示された形態そのものに限定するよう意図されてはいない。この発明の幅および範囲は、上述の例示的な実施形態のいずれによっても限定されるべきでない。多くの変更および変形が、当業者には明らかになるだろう。これらの変更および変形は、開示された特徴の関連するあらゆる組合せを含む。実施形態は、この発明の原理およびその実用的応用を最良に説明するために選択され説明されたものであり、それにより、考えられる特定の使用に適したさまざまな実施形態についての、およびさまざまな変更例を有するこの発明を、当業者が理解できるようにする。この発明の範囲は、請求項およびそれらの同等例によって定義されるよう意図されている。

Claims

ネットワークファブリック内でファブリックレベルグループメンバーシップをサブネットレベルグループメンバーシップに関連付ける方法であって、
ネットワークのファブリックレベルでリソースドメインを作成するステップを含み、前記リソースドメインは、ファブリックリソースの論理的なグルーピングであり、
前記リソースドメインをメモリに格納するステップと、
前記ネットワークファブリックのサブネットに管理パーティションを作成するステップとを含み、前記管理パーティションは第１のＰ＿Ｋｅｙによって規定され、前記第１のＰ＿Ｋｅｙは前記サブネット全体にわたって固有であり、
前記第１のＰ＿Ｋｅｙを前記メモリに格納するステップと、
前記リソースドメインを前記管理パーティションに対応付けるステップと、
第１のファブリックリソースを前記リソースドメインに追加するステップとを含み、前記第１のファブリックリソースは第１の識別子によって特定され、前記第１の識別子は前記メモリに格納され、
前記第１の識別子と前記管理パーティションを規定する前記第１のＰ＿Ｋｅｙとの間の第１の関係を前記メモリ内に作成するステップを含み、前記第１の関係は、前記第１のファブリックリソースを前記管理パーティションのメンバとして規定し、
第２のファブリックリソースを前記リソースドメインに追加するステップを含み、前記第２のファブリックリソースは第２の識別子によって特定され、前記第２の識別子は前記メモリに格納され、
前記第２の識別子と前記管理パーティションを規定する前記第１のＰ＿Ｋｅｙとの間の第２の関係を前記メモリ内に作成するステップを含み、前記第２の関係は、前記第２のファブリックリソースを前記管理パーティションのメンバとして規定し、
第１のドメインリソースおよび第２のドメインリソースは前記管理パーティションのメンバであると判断するステップと、
前記第１のドメインリソースおよび前記第２のドメインリソースは前記管理パーティションのメンバであるという判断に基づいて、前記第１のドメインリソースが前記第２のドメインリソースにアクセスする権利を与えるステップとを含む、方法。
ドメインレベルユーザを前記リソースドメインに対応付けるステップをさらに含み、前記ドメインレベルユーザを前記リソースドメインに対応付けることにより、前記ドメインレベルユーザに、前記第１のファブリックリソースおよび前記第２のファブリックリソースを管理する許可を与える、請求項１に記載の方法。
前記リソースドメインに子リソースドメインを追加するステップと、
前記子リソースドメインに第３のファブリックリソースを追加するステップとをさらに含み、前記第３のファブリックリソースは第３の識別子によって特定され、前記第３の識別子は前記メモリに格納され、
前記第３の識別子と前記管理パーティションを規定する前記第１のＰ＿Ｋｅｙとの間の第３の関係を前記メモリ内に作成するステップをさらに含み、前記第３の関係は、前記第３のファブリックリソースを前記管理パーティションのメンバとして規定する、請求項１または２に記載の方法。
前記ネットワークファブリックの前記サブネットに第２の管理パーティションを作成するステップをさらに含み、前記第２の管理パーティションは第２のＰ＿Ｋｅｙによって規定され、前記第２のＰ＿Ｋｅｙは前記サブネット全体にわたって固有であり、
前記第２のＰ＿Ｋｅｙを前記メモリに格納するステップと、
前記子リソースドメインを前記第２の管理パーティションに対応付けるステップと、
前記第３の識別子と前記第２の管理パーティションを規定する前記第２のＰ＿Ｋｅｙとの間の第４の関係を前記メモリ内に作成するステップとをさらに含み、前記第４の関係は、前記第３のファブリックリソースを前記第２の管理パーティションのメンバとして規定する、請求項３に記載の方法。
第１の論理名を前記第１のファブリックリソースに割当てるステップと、
前記第１の論理名を前記メモリに格納するステップと、
前記第１の論理名と前記第１の識別子との間の関係を前記メモリ内に作成するステップとをさらに含み、前記関係は、前記メモリにおいて、前記第１の論理名および前記第１の識別子をリンクする、請求項１〜４のいずれか一項に記載の方法。
第２の論理名を前記第２のファブリックリソースに割当てるステップと、
前記メモリにおける前記第１の論理名をルックアップするステップと、
前記第２の論理名が前記第１の論理名と異なる場合にのみ、前記第２の論理名を前記メモリに格納するステップとをさらに含む、請求項５に記載の方法。
前記ネットワークファブリックの前記サブネットにデータパーティションを作成するステップと、
前記データパーティションを前記第１の管理パーティションに対応付けるステップと、
前記データパーティションのメンバになることを求める要求を、前記第１のファブリックリソースから受けるステップと、
前記データパーティションが前記管理パーティションに対応付けられていることに基づいて、前記第１のファブリックリソースを前記データパーティションのメンバにするステップとをさらに含む、請求項１に記載の方法。
ネットワークファブリック内でファブリックレベルグループメンバーシップをサブネットレベルグループメンバーシップに関連付けるシステムであって、前記システムは、
プロセッサを含むノードと、
前記ノードにアクセス可能なメモリと、
リソースドメインとを含み、前記リソースドメインは、ファブリックリソースの論理的なグルーピングであり、前記メモリに格納され、前記システムはさらに、
前記メモリに格納されている第１のＰ＿Ｋｅｙを含み、前記Ｐ＿Ｋｅｙは管理パーティションを規定し、前記第１のＰ＿Ｋｅｙは前記サブネット全体にわたって固有であり、
前記ノードは、
前記リソースドメインを前記第１のＰ＿Ｋｅｙに対応付けるように動作し、
第１のファブリックリソースを前記リソースドメインに追加するように動作し、前記第１のファブリックリソースは第１の識別子によって特定され、前記第１の識別子は前記メモリに格納され、前記ノードは、
前記第１の識別子と前記管理パーティションを規定する前記第１のＰ＿Ｋｅｙとの間の第１の関係を前記メモリ内に作成するように動作し、前記第１の関係は、前記第１のファブリックリソースを前記管理パーティションのメンバとして規定し、前記ノードは、
第２のファブリックリソースを前記リソースドメインに追加するように動作し、前記第２のファブリックリソースは第２の識別子によって特定され、前記第２の識別子は前記メモリに格納され、前記ノードは、
前記第２の識別子と前記管理パーティションを規定する前記第１のＰ＿Ｋｅｙとの間の第２の関係を前記メモリ内に作成するように動作し、前記第２の関係は、前記第２のファブリックリソースを前記管理パーティションのメンバとして規定し、前記ノードは、
第１のドメインリソースおよび第２のドメインリソースは前記管理パーティションのメンバであると判断するように動作し、
前記第１のドメインリソースおよび前記第２のドメインリソースは前記管理パーティションのメンバであるという判断に基づいて、前記第１のドメインリソースが前記第２のドメインリソースにアクセスする権利を与えるように動作する、システム。
前記ファブリック全体にわたって固有である論理名が前記管理パーティションに割当てられ、前記サブネット全体にわたって固有である論理名が前記第１のファブリックリソースに割当てられ、前記第１のファブリックリソースに割当てられる前記論理名は、前記管理パーティションに割当てられる前記論理名でプレフィックスされることにより、前記ファブリック全体にわたって固有である前記第１のファブリックリソースの論理名を作成する、請求項８に記載のシステム。
ファブリックマネージャをさらに含み、前記ファブリックマネージャはユーザインターフェイスを含み、ユーザは、前記ファブリックマネージャの前記ユーザインターフェイスを通して、前記リソースドメインを少なくとも部分的に管理する、請求項８または９に記載のシステム。
前記管理パーティションはユーザにとってトランスペアレントであり、前記第１のＰ＿Ｋｅｙは、前記リソースドメインが作成されるときに前記ファブリックマネージャによって自動的に作成されて前記メモリに格納される、請求項１０に記載のシステム。
前記第１のＰ＿Ｋｅｙは、前記ユーザの明示的なプロンプトに応じて生成されて前記メモリに格納される、請求項８〜１０のいずれか一項に記載のシステム。
前記第１のファブリックリソースはホストチャネルアダプタ（ＨＣＡ）であり、前記第２のドメインリソースは仮想ホストチャネルアダプタ（ｖＨＣＡ）である、請求項８〜１２のいずれか一項に記載の方法。
前記メモリはリレーショナルデータベースを含み、前記第１のＰ＿Ｋｅｙ、前記第１の識別子、前記第１の関係、前記第２の識別子、および前記第２の関係は、前記リレーショナルデータベースに格納される、請求項８に記載の方法。
ネットワークファブリック内でファブリックレベルグループメンバーシップをサブネットレベルグループメンバーシップに関連付けるための命令が格納された非一時的なコンピュータ読取可能記憶媒体であって、前記命令は、１つ以上のコンピュータによって読出されて実行されると、前記１つ以上のコンピュータにステップを実行させ、前記ステップは、
ネットワークのファブリックレベルでリソースドメインを作成するステップを含み、前記リソースドメインは、ファブリックリソースの論理的なグルーピングであり、
前記リソースドメインをメモリに格納するステップと、
前記ネットワークファブリックのサブネットに管理パーティションを作成するステップとを含み、前記管理パーティションは第１のＰ＿Ｋｅｙによって規定され、前記第１のＰ＿Ｋｅｙは前記サブネット全体にわたって固有であり、
前記第１のＰ＿Ｋｅｙを前記メモリに格納するステップと、
前記リソースドメインを前記管理パーティションに対応付けるステップと、
第１のファブリックリソースを前記リソースドメインに追加するステップとを含み、前記第１のファブリックリソースは第１の識別子によって特定され、前記第１の識別子は前記メモリに格納され、
前記第１の識別子と前記管理パーティションを規定する前記第１のＰ＿Ｋｅｙとの間の第１の関係を前記メモリ内に作成するステップを含み、前記第１の関係は、前記第１のファブリックリソースを前記管理パーティションのメンバとして規定し、
第２のファブリックリソースを前記リソースドメインに追加するステップを含み、前記第２のファブリックリソースは第２の識別子によって特定され、前記第２の識別子は前記メモリに格納され、
前記第２の識別子と前記管理パーティションを規定する前記第１のＰ＿Ｋｅｙとの間の第２の関係を前記メモリ内に作成するステップを含み、前記第２の関係は、前記第２のファブリックリソースを前記管理パーティションのメンバとして規定し、
第１のドメインリソースおよび第２のドメインリソースは前記管理パーティションのメンバであると判断するステップと、
前記第１のドメインリソースおよび前記第２のドメインリソースは前記管理パーティションのメンバであるという判断に基づいて、前記第１のドメインリソースが前記第２のドメインリソースにアクセスする権利を与えるステップとを含む、非一時的なコンピュータ読取可能記憶媒体。
前記ステップはさらに、
ドメインレベルユーザを前記リソースドメインに対応付けるステップを含み、前記ドメインレベルユーザを前記リソースドメインに対応付けることにより、前記ドメインレベルユーザに、前記第１のファブリックリソースおよび前記第２のファブリックリソースを管理する許可を与える、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。
前記ステップはさらに、
前記リソースドメインに子リソースドメインを追加するステップと、
前記子リソースドメインに第３のファブリックリソースを追加するステップとを含み、前記第３のファブリックリソースは第３の識別子によって特定され、前記第３の識別子は前記メモリに格納され、前記ステップはさらに、
前記第３の識別子と前記管理パーティションを規定する前記第１のＰ＿Ｋｅｙとの間の第３の関係を前記メモリ内に作成するステップを含み、前記第３の関係は、前記第３のファブリックリソースを前記管理パーティションのメンバとして規定する、請求項１５または１６に記載の非一時的なコンピュータ読取可能記憶媒体。
前記ステップはさらに、
前記ネットワークファブリックの前記サブネットに第２の管理パーティションを作成するステップを含み、前記第２の管理パーティションは第２のＰ＿Ｋｅｙによって規定され、前記第２のＰ＿Ｋｅｙは前記サブネット全体にわたって固有であり、前記ステップはさらに、
前記第２のＰ＿Ｋｅｙを前記メモリに格納するステップと、
前記子リソースドメインを前記第２の管理パーティションに対応付けるステップと、
前記第３の識別子と前記第２の管理パーティションを規定する前記第２のＰ＿Ｋｅｙとの間の第４の関係を前記メモリ内に作成するステップとを含み、前記第４の関係は、前記第３のファブリックリソースを前記第２の管理パーティションのメンバとして規定する、請求項１７に記載の非一時的なコンピュータ読取可能記憶媒体。
前記ステップはさらに、
第１の論理名を前記第１のファブリックリソースに割当てるステップと、
前記第１の論理名を前記メモリに格納するステップと、
前記第１の論理名と前記第１の識別子との間の関係を前記メモリ内に作成するステップとを含み、前記関係は、前記メモリにおいて、前記第１の論理名および前記第１の識別子をリンクする、請求項１５〜１８のいずれか一項に記載の非一時的なコンピュータ読取可能記憶媒体。
前記ステップはさらに、
第２の論理名を前記第２のファブリックリソースに割当てるステップと、
前記メモリにおける前記第１の論理名をルックアップするステップと、
前記第２の論理名が前記第１の論理名と異なる場合にのみ、前記第２の論理名を前記メモリに格納するステップとを含む、請求項１９に記載の非一時的なコンピュータ読取可能記憶媒体。
コンピュータシステムによって実行されると前記コンピュータシステムに請求項１〜７のいずれか一項に記載の方法を実行させる機械読取可能なフォーマットのプログラム命令を含むコンピュータプログラム。
非一時的な機械読取可能データ記憶媒体に格納された請求項２１に記載の前記コンピュータプログラムを含むコンピュータプログラムプロダクト。