特開 2024-109623 高性能コンピューティング環境において異種および非対称のデュアルレールファブリック構成をサポートするためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024109623

(43)【公開日】2024-08-14

(54)【発明の名称】高性能コンピューティング環境において異種および非対称のデュアルレールファブリック構成をサポートするためのシステムおよび方法

(51)【国際特許分類】

   H04L 47/10 20220101AFI20240806BHJP

   H04L 45/24 20220101ALI20240806BHJP

【ＦＩ】

H04L47/10

H04L45/24

【審査請求】有

【請求項の数】15

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2024074366

(22)【出願日】2024-05-01

(62)【分割の表示】P 2021541636の分割

【原出願日】2020-01-28

(31)【優先権主張番号】16/261,362

(32)【優先日】2019-01-29

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/267,072

(32)【優先日】2019-02-04

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/547,329

(32)【優先日】2019-08-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/547,332

(32)【優先日】2019-08-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】16/547,335

(32)【優先日】2019-08-21

(33)【優先権主張国・地域又は機関】US

(71)【出願人】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ヨンセン，ビョルン・ダグ

(72)【発明者】

【氏名】ホドバ，プレドラグ

(72)【発明者】

【氏名】ホレン，リネ

(72)【発明者】

【氏名】ヒェムスランド，クルト

(57)【要約】      （修正有）

【課題】高性能コンピューティング環境において異種および非対称のデュアルレールファブリック構成をサポートするためのシステムおよび方法を提供する。
【解決手段】システム２０００は、１つまたは複数のマイクロプロセッサを各々が含む１つまたは複数のコンピュータと、少なくとも１つのデュアルポートアダプタ２００６～２０１３を含む、コンピュータにおけるホスト２００５、２０１０と、スイッチ２０２０～２０２３を含むプライベートファブリック２０４０と、クラウドファブリック２０３０を含むパブリックファブリックとを含む。ホストは、作業負荷をプロビジョニングする。プロビジョニングされた作業負荷に配置ポリシーを割り当て、プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックを、配置ポリシーに従って、プライベートファブリックおよびパブリックファブリックのうちの１つまたは複数に割り当てる。
【選択図】図２０

【特許請求の範囲】

【請求項1】

高性能コンピューティング環境において異種および非対称なデュアルレール構成をサポートするためのシステムであって、
１つまたは複数のマイクロプロセッサを含むコンピュータと、
複数のホストとを備え、前記複数のホストの各々はデュアルポートアダプタを含み、前記システムはさらに、
プライベートファブリックを含む第１のレールを備え、前記プライベートファブリックは、２つ以上のラックに配置された複数のスイッチを含み、前記２つ以上のラックの各々は、前記複数のスイッチのセットを含み、前記システムはさらに、
パブリックファブリックを含む第２のレールを含み、前記パブリックファブリックはクラウドファブリックを含み、前記システムはさらに、
分散型作業負荷配置オーケストレータを備え、
前記複数のホストのうちのあるホストは、前記あるホストの前記デュアルポートアダプタの第１のポートを介して前記第１のレールに接続され、
前記複数のホストのうちの前記あるホストは、前記あるホストの前記デュアルポートアダプタの第２のポートを介して前記第２のレールに接続され、
前記複数のホストのうちの前記あるホストにおいて作業負荷がプロビジョニングされ、
配置ポリシーが、前記プロビジョニングされた作業負荷に割り当てられ、
前記分散型作業負荷配置オーケストレータは、前記プロビジョニングされた作業負荷に割り当てらた前記配置ポリシーを利用して、前記プロビジョニングされた作業負荷のネットワークトラフィックを、前記配置ポリシーに従って、前記プライベートファブリックを含む前記第１のレールおよび前記パブリックファブリックを含む前記第２のレールのうちの１つまたは複数に割り当てる、システム。

【請求項2】

前記プライベートファブリックは２つ以上のレールを提供し、前記２つ以上のレールは、前記プライベートファブリック内で前記プロビジョニングされた作業負荷のために冗長接続性を提供する、請求項１に記載のシステム。

【請求項3】

前記プロビジョニングされた作業負荷に割り当てられた前記配置ポリシーは、高優先順位の配置ポリシーである、請求項２に記載のシステム。

【請求項4】

前記プロビジョニングされた作業負荷の前記ネットワークトラフィックは、前記プライベートファブリック内で厳密に割り当てられる、請求項３に記載のシステム。

【請求項5】

前記パブリックファブリックは２つ以上のレールを提供し、前記２つ以上のレールは、前記パブリックファブリック内で前記プロビジョニングされた作業負荷のために冗長接続性を提供する、請求項１に記載のシステム。

【請求項6】

前記プロビジョニングされた作業負荷に割り当てられた前記配置ポリシーは、低優先順位の配置ポリシーである、請求項５に記載のシステム。

【請求項7】

前記プロビジョニングされた作業負荷のネットワークトラフィックは、前記パブリックファブリック内および前記プライベートファブリック内に割り当てられる、請求項６に記載のシステム。

【請求項8】

高性能コンピューティング環境において冗長独立ネットワークをサポートするための方法であって、
１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、
複数のホストを提供することを含み、前記複数のホストの各々はデュアルポートアダプ
タを含み、前記方法はさらに、前記１つまたは複数のマイクロプロセッサを含む前記コンピュータにおいて、
プライベートファブリックを含む第１のレールを提供することを含み、前記プライベートファブリックは、２つ以上のラックに配置された複数のスイッチを含み、前記２つ以上のラックの各々は、前記複数のスイッチのセットを含み、前記方法はさらに、前記１つまたは複数のマイクロプロセッサを含む前記コンピュータにおいて、
パブリックファブリックを含む第２のレールを提供することを含み、前記パブリックファブリックはクラウドファブリックを含み、前記方法はさらに、前記１つまたは複数のマイクロプロセッサを含む前記コンピュータにおいて、
分散型作業負荷配置オーケストレータを提供することを含み、前記方法はさらに、
前記複数のホストのうちのあるホストを、前記あるホストの前記デュアルポートアダプタの第１のポートを介して前記第１のレールに接続することと、
前記複数のホストのうちの前記あるホストを、前記あるホストの前記デュアルポートアダプタの第２のポートを介して前記第２のレールに接続することと、
前記複数のホストのうちの前記あるホストにおいて作業負荷をプロビジョニングすることと、
前記プロビジョニングされた作業負荷に配置ポリシーを割り当てることと、
前記プロビジョニングされた作業負荷に割り当てらた前記配置ポリシーに基づいて、前記分散型作業負荷配置オーケストレータが、前記プロビジョニングされた作業負荷のネットワークトラフィックを、前記配置ポリシーに従って、前記プライベートファブリックを含む前記第１のレールおよび前記パブリックファブリックを含む前記第２のレールのうちの１つまたは複数に割り当てることとを含む、方法。

【請求項9】

前記プライベートファブリックは２つ以上のレールを提供し、前記２つ以上のレールは、前記プロビジョニングされた作業負荷のために冗長接続性を提供する、請求項８に記載の方法。

【請求項10】

前記プロビジョニングされた作業負荷に割り当てられた前記配置ポリシーは、高優先順位の配置ポリシーである、請求項９に記載の方法。

【請求項11】

前記プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックは、前記プライベートファブリック内で厳密にプロビジョニングされる、請求項１０に記載の方法。

【請求項12】

前記パブリックファブリックは２つ以上のレールを提供し、前記２つ以上のレールは、前記プロビジョニングされた作業負荷のために冗長接続性を提供する、請求項８～１１のいずれか１項に記載の方法。

【請求項13】

前記プロビジョニングされた作業負荷に割り当てられた前記配置ポリシーは、低優先順位の配置ポリシーである、請求項１２に記載の方法。

【請求項14】

前記プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックは、前記パブリックファブリック内で割り当てられる、請求項１３に記載の方法。

【請求項15】

高性能コンピューティング環境において異種および非対称なデュアルレール構成をサポートするための命令を担持するコンピュータ読取可能媒体であって、前記命令は、コンピュータによって読取られ実行されると、前記コンピュータにステップを実行させ、前記ステップは、
１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、
複数のホストを提供することを含み、前記複数のホストの各々はデュアルポートアダプ
タを含み、前記ステップはさらに、前記１つまたは複数のマイクロプロセッサを含む前記コンピュータにおいて、
プライベートファブリックを含む第１のレールを提供することを含み、前記プライベートファブリックは、２つ以上のラックに配置された複数のスイッチを含み、前記２つ以上のラックの各々は、前記複数のスイッチのセットを含み、前記ステップはさらに、前記１つまたは複数のマイクロプロセッサを含む前記コンピュータにおいて、
パブリックファブリックを含む第２のレールを提供することを含み、前記パブリックファブリックはクラウドファブリックを含み、前記ステップはさらに、前記１つまたは複数のマイクロプロセッサを含む前記コンピュータにおいて、
分散型作業負荷配置オーケストレータを提供することを含み、前記ステップはさらに、
前記複数のホストのうちのあるホストを、前記あるホストの前記デュアルポートアダプタの第１のポートを介して前記第１のレールに接続することと、
前記複数のホストのうちの前記あるホストを、前記あるホストの前記デュアルポートアダプタの第２のポートを介して前記第２のレールに接続することと、
前記複数のホストのうちの前記あるホストにおいて作業負荷をプロビジョニングすることと、
前記プロビジョニングされた作業負荷に配置ポリシーを割り当てることと、
前記プロビジョニングされた作業負荷に割り当てらた前記配置ポリシーに基づいて、前記分散型作業負荷配置オーケストレータが、前記プロビジョニングされた作業負荷のネットワークトラフィックを、前記配置ポリシーに従って、前記プライベートファブリックを含む前記第１のレールおよび前記パブリックファブリックを含む前記第２のレールのうちの１つまたは複数に割り当てることとを含む、コンピュータ読取可能媒体。

【請求項16】

前記プライベートファブリックは２つ以上のレールを提供し、前記２つ以上のレールは、前記プロビジョニングされた作業負荷のために冗長接続性を提供する、請求項１５に記載のコンピュータ読取可能媒体。

【請求項17】

前記プロビジョニングされた作業負荷に割り当てられた前記配置ポリシーは、高優先順位の配置ポリシーである、請求項９に記載のコンピュータ読取可能媒体。

【請求項18】

前記プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックは、前記プライベートファブリック内で厳密にプロビジョニングされる、請求項１０に記載のコンピュータ読取可能媒体。

【請求項19】

前記パブリックファブリックは２つ以上のレールを提供し、前記２つ以上のレールは、前記プロビジョニングされた作業負荷のために冗長接続性を提供する、請求項１５～１８のいずれか１項に記載のコンピュータ読取可能媒体。

【請求項20】

前記プロビジョニングされた作業負荷に割り当てられた前記配置ポリシーは、低優先順位の配置ポリシーであり、
前記プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックは、前記パブリックファブリック内で割り当てられる、請求項１９に記載のコンピュータ読取可能媒体。

【発明の詳細な説明】

【技術分野】

【0001】

著作権表示
本特許文献の開示の一部には、著作権保護の対象となるものが含まれている。著作権保有者は、この特許文献または特許開示の、それが特許商標庁の特許ファイルまたは記録に現れているとおりの、何人による複写複製にも異議を唱えないが、それ以外の場合にはすべての著作権をどのようなものであろうと所有する。

【0002】

優先権主張
本出願は、２０１９年８月２１日に出願された出願番号第１６／５４７，３２９号の「SYSTEM AND METHOD FOR SUPPORTING HETEROGENEOUS AND ASYMMETRIC DUAL RAIL FABRIC CONFIGURATIONS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT（高性能コンピューティ
ング環境において異種および非対称のデュアルレールファブリック構成をサポートするためのシステムおよび方法）」と題される米国特許出願に対する優先権の利益を主張し、本出願はまた、２０１９年２月４日に出願された出願番号第１６／２６７，０７２号の「SYSTEM AND METHOD FOR USING INFINIBAND ROUTING ALGORITHMS FOR ETHERNET FABRICS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT（高性能コンピューティング環境でイーサネットファブリックにインフィニバンドルーティングアルゴリズムを用いるためのシステムおよび方法）」と題される米国特許出願に対する優先権の利益を主張し、本出願はまた、２０１９年１月２９日に出願された出願番号第１６／２６１，３６２号の「SYSTEM AND METHOD FOR A MULTICAST SEND DUPLICATION INSTEAD OF REPLICATION IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT（高性能コンピューティング環境における複製の代わりのマ
ルチキャスト送信複製のためのシステムおよび方法）」と題される米国特許出願に対する優先権の利益を主張し、本出願はまた、２０１９年８月２１日に出願された出願番号第１６／５４７，３３２号の「SYSTEM AND METHOD FOR ON-DEMAND UNICAST FORWARDING IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT（高性能コンピューティング環境におけるオンデマンドユニキャスト転送のシステムおよび方法）」と題される米国特許出願に対する優先権の利益を主張し、本出願はまた、２０１９年８月２１日に出願された出願番号第１６／５４７，３３５号の「SYSTEM AND METHOD FOR A SINGLE LOGICAL IP SUBNET ACROSS MULTIPLE INDEPENDENT LAYER 2 (L2) SUBNETS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT（高性能コンピューティング環境における複数の独立したレイヤ２（Ｌ２）サブネッ
トにわたる単一の論理ＩＰサブネットのためのシステムおよび方法）」と題される米国特許出願に対する優先権の利益を主張し、それらのそれぞれの全体をここに引用により援用する。

【0003】

本出願は以下の出願に関連し、それらの各々はそれらの全体が引用により援用される：２０１７年８月３１日に提出された米国仮特許出願第６２／５５２，８１８号；２０１８年６月１日に提出された米国仮特許出願第６２／６７９，４６５号；２０１８年８月２８日に提出された米国特許出願第１６／１１５、１３８号；２０１８年６月１日に提出された米国仮特許出願第６２／６７９，４６９号；２０１８年６月１日に提出された米国仮特許出願第６２／６７９，４７８号；および２０１８年６月１日に提出された米国仮特許出願第６２／６７９，４９１号。

【背景技術】

【0004】

背景
より大きなクラウドコンピューティングアーキテクチャが導入されるにつれ、従来のネットワークおよびストレージに関連する性能ならびに管理ボトルネックが重大な問題とな
ってきた。クラウドコンピューティングファブリックの基礎として、インフィニバンド（ＩＢ）およびＲｏＣＥ（RDMA(リモートダイレクトメモリアクセス) over Converged Ethernet（登録商標））技術のような高性能相互接続を用いることに対する関心が高まっている。これは、本教示の実施形態が対処することが意図される一般的な領域である。

【発明の概要】

【課題を解決するための手段】

【0005】

概要：
高性能コンピューティング環境において異種および非対称のデュアルレールファブリック構成をサポートするためのシステムおよび方法。ある方法は、１つまたは複数のマイクロプロセッサを各々が含む１つまたは複数のコンピュータにおいて、複数のホストを含み、複数のホストの各々は少なくとも１つのデュアルポートアダプタを含み、さらに、２つ以上のスイッチを含むプライベートファブリックと、クラウドファブリックを含むパブリックファブリックとを含むことを提供し得る。複数のホストのうちのあるホストにおいて、作業負荷をプロビジョニングすることができる。プロビジョニングされた作業負荷に配置ポリシーを割り当てることができる。次いで、プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックを、配置ポリシーに従って、プライベートファブリックおよびパブリックファブリックのうちの１つまたは複数に割り当てることができる。

【0006】

高性能コンピューティング環境において複数の独立したレイヤ２サブネットにわたって単一の論理ＩＰサブネットをサポートするためのシステムおよび方法。ある方法は、１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、論理デバイスを提供することができ、上記論理デバイスは、レイヤ３アドレスによってアドレス指定され、上記論理デバイスは、複数のネットワークアダプタを含み、上記ネットワークアダプタの各々は、物理ポートを含み、上記方法はさらに、１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、複数のスイッチを提供することができる。本方法は、複数のスイッチを複数の別個のレイヤ２サブネットに配置することができる。本方法は、論理デバイスにおいてマッピングテーブルを提供することができる。

【0007】

本発明の特定の態様は、独立請求項に記載されており、さまざまな任意選択の実施形態が従属請求項に記載される。

【図面の簡単な説明】

【0008】

【図1】一実施形態に従うインフィニバンド環境の一例を示す図である。

【図2】一実施形態に従う分割されたクラスタ環境の一例を示す図である。

【図3】一実施形態に従うネットワーク環境におけるツリートポロジーの一例を示す図である。

【図4】一実施形態に従う例示的な共有ポートアーキテクチャを示す図である。

【図5】一実施形態に従う例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。

【図6】一実施形態に従う例示的なｖＰｏｒｔアーキテクチャを示す図である。

【図7】一実施形態に従うＬＩＤが予めポピュレートされている例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。

【図8】一実施形態に従う動的ＬＩＤ割当てがなされた例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。

【図9】一実施形態に従う、ｖＳｗｉｔｃｈに動的ＬＩＤ割当てがなされかつＬＩＤが予めポピュレートされている、例示的なｖＳｗｉｔｃｈアーキテクチャを示す図である。

【図10】一実施形態に従う例示的なマルチサブネットインフィニバンドファブリックを示す図である。

【図11】一実施形態に従う、高性能コンピューティング環境における２つのサブネット間の相互接続を示す図である。

【図12】一実施形態に従う、高性能コンピューティング環境におけるデュアルポート仮想ルータ構成を介した２つのサブネット間の相互接続を示す図である。

【図13】一実施形態に従う、高性能コンピューティング環境においてデュアルポート仮想ルータをサポートする方法のフローチャートを示す図である。

【図14】一実施形態による、高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムを示す。

【図15】一実施形態による、高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムを示す。

【図16】一実施形態による、高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムを示す。

【図17】一実施形態による、高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムを示す。

【図18】高性能コンピューティング環境における冗長独立ネットワークのための方法のフローチャートである。

【図19】一実施形態による、高性能コンピューティング環境における正しい接続性のためにレール番号関連付けをサポートするためのシステムを示す。

【図20】一実施形態による、異種および非対称のデュアルレールファブリック構成をサポートするためのシステムを示す。

【図21】一実施形態による、異種および非対称のデュアルレールファブリック構成をサポートするためのシステムを示す。

【図22】一実施形態による、異種および非対称のデュアルレールファブリック構成をサポートするためのシステムを示す。

【図23】異種および非対称のデュアルレールファブリック構成をサポートするためのシステム内で、プロビジョニングされた作業負荷またはプロビジョニングされている作業負荷に対して配置ポリシーを決定するための方法のフローチャートである。

【図24】一実施形態による、プロビジョニングされた作業負荷またはプロビジョニングされている作業負荷に対してファブリックタイプの選択を決定するための方法のフローチャートである。

【図25】一実施形態による、異種および非対称のデュアルレールファブリック構成をサポートするための方法のフローチャートである。

【図26】一実施形態による、高性能コンピューティング環境における複製の代わりのマルチキャスト送信複製のためのシステムを示す。

【図27】高性能コンピューティング環境における複製の代わりのマルチキャスト送信複製のための方法のフローチャートである。

【図28】一実施形態によるリンクアグリゲーション（ＬＡＧ）をサポートするためのシステムを示す。

【図29】一実施形態による、マルチシャーシリンクアグリゲーション（ＭＬＡＧ）をサポートするためのシステムを示す。

【図30】一実施形態による、高性能コンピューティング環境において複数の独立したレイヤ２サブネットにわたって単一の論理ＩＰサブネットをサポートするためのシステムを示す。

【図31】一実施形態による、高性能コンピューティング環境において複数の独立したレイヤ２サブネットにわたって単一の論理ＩＰサブネットをサポートするための方法のフローチャートである。

【発明を実施するための形態】

【0009】

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

【0010】

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

【0011】

一実施形態によると、高性能コンピューティング環境において異種および非対称のデュアルレールファブリック構成をサポートするためのシステムおよび方法が本明細書で説明される。

【0012】

一実施形態によれば、高性能コンピューティング環境において複数の独立したレイヤ２サブネットにわたって単一の論理ＩＰサブネットをサポートするシステムおよび方法が本明細書で説明される。

【0013】

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

【0014】

いくつかの他の実施形態では、以下の説明は、ＲｏＣＥ（RDMA(リモートダイレクトメ
モリアクセス) over Converged Ethernet）を用いる。RDMA over Converged Ethernet（
ＲｏＣＥ）は、イーサネット（登録商標）ネットワーク上でＲＤＭＡの効率的なデータ転送を可能にして、ハードウェアＲＤＭＡエンジン実現を伴うトランスポートオフロードおよび優れた性能を可能にする標準プロトコルである。ＲｏＣＥは、InfiniBand Trade Association （ＩＢＴＡ）規格で規定されている標準プロトコルである。ＲｏＣＥは、ＵＤ
Ｐ（ユーザデータグラムプロトコル）カプセル化を利用して、それがレイヤ３ネットワークを越えることができるようにする。ＲＤＭＡは、インフィニバンド相互接続技術によってネイティブに用いられる鍵となる能力である。インフィニバンドおよびイーサネットＲｏＣＥは両方とも、共通のユーザＡＰＩを共有するが、異なる物理層およびリンク層を有する。

【0015】

一実施形態によれば、本明細書のさまざまな部分は、さまざまな実現例を説明する際にインフィニバンドファブリックへの言及を含むが、当業者は、本明細書で説明されるさまざまな実施形態がＲｏＣＥファブリックにおいても実現され得ることを容易に理解するであろう。

【0016】

今の時代（たとえばエクサスケール（exascale）時代）のクラウドの要求を満たすためには、仮想マシンが、リモートダイレクトメモリアクセス（Remote Direct Memory Acces
s：ＲＤＭＡ）等の低オーバーヘッドのネットワーク通信パラダイムを利用できることが
望ましい。ＲＤＭＡはＯＳスタックをバイパスしハードウェアと直接通信するため、シングルルートＩ／Ｏ仮想化（ＳＲ－ＩＯＶ）ネットワークアダプタのようなパス・スルー技術を使用することができる。一実施形態に従うと、仮想スイッチ（ｖＳｗｉｔｃｈ）ＳＲ－ＩＯＶアーキテクチャを、高性能無損失相互接続ネットワークに適用することができる。ネットワーク再構成時間はライブマイグレーションを現実的な選択肢にするために重要なので、ネットワークアーキテクチャに加えて、スケーラブルでありトポロジーに依存しない動的再構成機構を提供することができる。

【0017】

一実施形態に従い、さらに、ｖＳｗｉｔｃｈを使用する仮想化環境に対するルーティングストラテジーを提供することができ、ネットワークトポロジー（たとえばファットツリートポロジー）に対する効率的なルーティングアルゴリズムを提供することができる。動的再構成機構をさらに調整することにより、ファットツリーに課されるオーバーヘッドを最小にすることができる。

【0018】

本教示の一実施形態に従うと、仮想化は、クラウドコンピューティングにおける効率的なリソースの利用および柔軟なリソースの割当てにとって有益になり得る。ライブマイグレーションは、アプリケーションにとってトランスペアレントになるように物理サーバ間で仮想マシン（ＶＭ）を移動させることでリソースの利用を最適化することを可能にする。このように、仮想化は、ライブマイグレーションにより、コンソリデーション、リソースのオンデマンドプロビジョニング、および柔軟性を可能にする。

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

一実施形態に従うと、少なくとも１つのデバイス（たとえばスイッチ、ノード等）を、ファブリックマネージャ（図示せず）に対応付けることができる。ファブリックマネージャを使用して、たとえば、サブネット間ファブリックトポロジーを発見し、ファブリックプロファイル（たとえば仮想マシンファブリックプロファイル）を作成し、仮想マシンファブリックプロファイルを構築するための基礎を形成する仮想マシン関連データベースオブジェクトを構築することができる。加えて、ファブリックマネージャは、どのサブネットがどのルータポートを介しどのパーティション番号を用いて通信することを許可されるかについて、法的なサブネット間接続性を規定することができる。

【0097】

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

【0098】

仮想デュアルポートルータ
一実施形態に従うと、デュアルポートルータアブストラクション（dual port router abstraction）は、ＧＲＨ（グローバルルートヘッダ（global route header））からＬＲ
Ｈ（ローカルルートヘッダ（local route header））への変換を、通常のＬＲＨベースのスイッチングの実行に加えて行なう機能を有するスイッチハードウェア実装に基づいてサブネット間ルータ機能を規定することを可能にする簡単な方法を提供することができる。

【0099】

一実施形態に従うと、仮想デュアルポートルータは、対応するスイッチポートの外部で論理的に接続することができる。この仮想デュアルポートルータは、サブネットマネージャ等の標準管理エンティティに対しインフィニバンド規格に準拠したビューを提供することができる。

【0100】

一実施形態に従うと、デュアルポートルータモデルは、異なるサブネットを、各サブネットがサブネットへの進入（ingress）経路におけるパケット転送とアドレスマッピング
とを完全に制御し、かつ、間違って接続されたサブネットのうちいずれのサブネット内のルーティングおよび論理的接続にも影響を与えないように、接続できることを、示している。

【0101】

一実施形態に従うと、間違って接続されたファブリックを含む状況において、仮想デュアルポートルータアブストラクションを使用することにより、サブネットマネージャおよびＩＢ診断ソフトウェア等の管理エンティティが、遠隔サブネットへの意図しない物理的接続の存在下で、正しく作用するようにすることもできる。

【0102】

図１１は、一実施形態に従う、高性能コンピューティング環境における２つのサブネット間の相互接続を示す。仮想デュアルポートルータを用いて構成する前に、サブネットＡ
１１０１内のスイッチ１１２０を、スイッチ１１２０のスイッチポート１１２１を通し、物理接続１１１０を介して、サブネットＢ １１０２内のスイッチ１１３０に、スイッチ１１３０のスイッチポート１１３１を通して接続することができる。このような実施形態において、スイッチポート１１２１および１１３１の各々は、スイッチポートとしてもルータポートとしても機能することができる。

【0103】

一実施形態に従うと、この構成の問題は、インフィニバンドサブネット内のサブネットマネージャ等の管理エンティティが、スイッチポートでもありルータポートでもある物理ポートを区別できないことである。このような状況において、ＳＭは、スイッチポートを、このスイッチポートに接続されたルータポートを有するものとして扱うことができる。しかしながら、スイッチポートがたとえば物理リンクを介して別のサブネットマネージャを有する別のサブネットに接続されている場合、サブネットマネージャはディスカバリメッセージを物理リンクに送ることができる。しかしながら、このようなディスカバリメッセージは他方のサブネットでは許可されない。

【0104】

図１２は、一実施形態に従う、高性能コンピューティング環境におけるデュアルポート仮想ルータ構成を介した２つのサブネット間の相互接続を示す。

【0105】

一実施形態に従うと、構成後に、デュアルポート仮想ルータ構成を、サブネットマネージャの責任であるサブネットの端部を示す適切なエンドノードが、サブネットマネージャにわかるように、提供することができる。

【0106】

一実施形態に従うと、サブネットＡ １２０１内のスイッチ１２２０におけるスイッチポートは、仮想リンク１２２３を介して仮想ルータ１２１０内のルータポート１２１１に接続（すなわち論理的に接続）することができる。仮想ルータ１２１０（たとえばデュア
ルポート仮想ルータ）は、実施形態ではスイッチ１２２０の外部にあるものとして示されているが、論理的にはスイッチ１２２０の中に含めることができ、第２のルータポートであるルータポートＩＩ １２１２も含み得る。一実施形態に従うと、２つの端部を有し得る物理リンク１２０３は、サブネットＡ １２０１を、サブネットＢ １２０２に、物理リンクの第１の端部を介し、物理リンクの第２の端部を介し、ルータポートＩＩ １２１２を介し、サブネットＢ １２０２内の仮想ルータ１２３０に含まれるルータポートＩＩ
１２３２を介して、接続することができる。仮想ルータ１２３０はさらに、仮想リンク１２３３を介してスイッチ１２４０上のスイッチポート１２４１に接続（すなわち論理的に接続）することができるルータポート１２３１を含み得る。

【0107】

一実施形態に従うと、サブネットＡ上のサブネットマネージャ（図示せず）は、仮想ルータ１２１０上のルータポート１２１１を、当該サブネットマネージャが制御するサブネットの終点として検出することができる。デュアルポート仮想ルータアブストラクションは、サブネットＡ上のサブネットマネージャが、サブネットＡを通常のやり方で（たとえばインフィニバンド規格に規定されているように）扱うことを可能にする。サブネット管理エージェント（subnet management agent）レベルにおいて、デュアルポート仮想ルー
タアブストラクションを提供して通常のスイッチポートがＳＭにわかるようにし、その後、ＳＭＡレベルにおいて、当該アブストラクションを提供してこのスイッチポートに接続されている別のポートが存在しこのポートがデュアルポート仮想ルータ上のルータポートとなるようにすることができる。ローカルＳＭでは、従来のファブリックトポロジーを引続き使用することができ（このトポロジーにおいてＳＭはポートを標準スイッチポートとみなす）、したがって、ＳＭはルータポートをエンドポートとみなす。物理的接続は、２つの異なるサブネット内のルータポートとしても構成されている２つのスイッチポート間で行なうことができる。

【0108】

一実施形態に従うと、デュアルポート仮想ルータは、物理リンクが間違って同じサブネット内の他のいずれかのスイッチポートに接続される、または、別のサブネットへの接続を提供することを意図していないスイッチポートに接続される可能性があるという問題を、解決することもできる。したがって、本明細書に記載の方法およびシステムは、サブネットの外側にあるものも表現する。

【0109】

一実施形態に従うと、サブネットＡ等のサブネット内のローカルＳＭは、スイッチポートを確定し、次に、このスイッチポートに接続されているルータポート（たとえば仮想リンク１２２３を介してスイッチポート１２２１に接続されているルータポート１２１１）を確定する。ＳＭは、ルータポート１２１１を、当該ＳＭが管理するサブネットの端部とみなすので、ＳＭはディスカバリおよび／または管理メッセージをこのポイントよりも遠くに（たとえばルータポートＩＩ １２１２に）送ることができない。

【0110】

一実施形態に従うと、上記デュアルポート仮想ルータは、当該デュアルポート仮想ルータが属するサブネット内の管理エンティティ（たとえばＳＭまたはＳＭＡ）によってデュアルポート仮想ルータアブストラクションが完全に管理されるという利点を提供する。管理をローカル側のみにすることにより、システムは外部の独立した管理エンティティを提供する必要がない。すなわち、サブネット間接続の各側は自身のデュアルポート仮想ルータを構成する役割を担う。

【0111】

一実施形態に従うと、遠隔の宛先（すなわちローカルサブネットの外部）に向けられたＳＭＰ等のパケットが、上記デュアルポート仮想ルータを介して構成されていないローカルターゲットポートに到着した場合、ローカルポートは、自身はルータポートではないことを示すメッセージを返すことができる。

【0112】

本教示の多数の特徴は、ハードウェア、ソフトウェア、ファームウェア、またはこれらを組合わせたものにおいて、これを用いて、またはこれに支援されて、実施することができる。したがって、本教示の特徴は、処理システム（たとえば１つ以上のプロセッサを含む）を用いて実現し得る。

【0113】

図１３は、一実施形態に従う、高性能コンピューティング環境においてデュアルポート仮想ルータをサポートする方法を示す。ステップ１３１０において、１つ以上のマイクロプロセッサを含む１つ以上コンピュータに、この方法は第１のサブネットを設けることができる。第１のサブネットは複数のスイッチを含み、複数のスイッチは少なくともリーフスイッチを含み、複数のスイッチの各々は複数のスイッチポートを含む。第１のサブネットはさらに、各々が少なくとも１つのホストチャネルアダプタポートを含む複数のホストチャネルアダプタと、各々が複数のホストチャネルアダプタのうちの少なくとも１つのホストチャネルアダプタに対応付けられている複数のエンドノードと、サブネットマネージャとを含み、サブネットマネージャは、複数のスイッチおよび複数のホストチャネルアダプタの一方において実行される。

【0114】

ステップ１３２０において、この方法は、複数のスイッチのうちの１つのスイッチ上の複数のスイッチポートのうちの１つのスイッチポートを、ルータポートとして構成することができる。

【0115】

スイッチ１３３０において、この方法は、ルータポートとして構成したスイッチポートを仮想ルータに論理的に接続することができ、この仮想ルータは少なくとも２つの仮想ルータポートを含む。

【0116】

冗長な全独立および半独立ネットワーク
一実施形態によれば、ミッションクリティカルなシステムは、システムに対して規定された期待される応答時間および全体的な性能制約の範囲内で、正しく動作し、常に、関連するサービスを正しいデータとともに正しいクライアントに提供するべきである。

【0117】

一実施形態によれば、コンピュータの分散クラスタとして実現されるシステムの場合、これはまた、クラスタ内のコンピュータの必要なセット間の通信が常に動作可能でなければならないことを暗示する。

【0118】

一実施形態によれば、ネットワーク通信システムが動作可能であることの望ましい前提は、正しいコンポーネントおよびコネクタが正しいケーブルを介して接続されているという点でホストアダプタおよびスイッチのようなコンポーネント間のすべての物理的接続性が正しいこと、ならびに関与するすべてのコンポーネントが正しい態様で構成されることである。

【0119】

しかしながら、１つの実施形態によれば、ハードウェアコンポーネントが故障し、オペレータがミスをする可能性があるため、通信は、通常の場合、１つの障害点にのみ依存しない必要がある。１つのコンポーネントおよび通信経路を介した通信を妨げる障害またはミスが生じる場合、これを検出し、即座に、または少なくともその動作可能でない通信経路がシステム動作または応答時間に何らかの重大な影響を及ぼしてしまう前に、通信を代替の冗長通信経路に引き継がせることが最も重要である。

【0120】

また、一実施形態によれば、仮に第２の障害が起こった場合に一部またはすべての現在の通信を脆弱なままにしておく障害が存在するときはいつでも、関連する修復動作ができるだけ早く生じ得ること、および／または追加のバックアップ策を用いてサービスの全損失を防止し得ることが重要である。

【0121】

一実施形態によれば、別の態様は、システムおよびアプリケーションソフトウェアがエラーを免れることは非常に希であり、また、システムの特徴を経時的に向上させる必要性がしばしばあるので、いかなる停止も引き起こさずにシステム内のさまざまなソフトウェアコンポーネントをアップグレードすることが可能であることが重要である。分散型クラスタシステムでは、これは、典型的には、冗長コンポーネントが厳格な順序でアップグレードされ、システムが必要なコンポーネントのセットおよび必要な通信で常に完全に動作可能である「ローリングアップグレード」モデルを意味する。

【0122】

また、一実施形態によれば、システムの能力を向上し、および／または容量を拡張するために、追加のＨＷコンポーネント、および／または既存のＨＷコンポーネントをより能力の高いＨＷコンポーネントと交換することに関して、物理的変更が必要となり得る。その場合、そのようなアップグレードはまた、システムにおける新たなソフトウェアおよび／またはファームウェアも意味し得る。

【0123】

しかしながら、新たなソフトウェアおよびファームウェアのバージョンならびに新たなＨＷのバージョンは、新たなまたは早期の未検出のエラーを導入するリスク、およびクラスタ内の同じノード上または異なるノード間の異なるソフトウェア／ファームウェアコンポーネント間の相互運用性問題のリスクを導入する。したがって、理想的な場合においては、システムを動作させる能力は、単一のタイプのソフトウェアのみがシステム全体にわたって用いられていること、および１つのソフトウェアバージョンから別のソフトウェアバージョンへのアップグレードの成功に依存すべきではない。これを達成するために、１つのアプローチは、要求されるサービスが、２セットの異なるタイプのハードウェアコンポーネントによって、異なるセットのソフトウェアおよびファームウェアで、冗長な態様で実現され得ること、ならびに異なるセットの冗長コンポーネントのセットの間に依存関係がまったく存在しないこと、または最小で極めてよく定義され、制御された依存関係が存在することを保証することである。

【0124】

一実施形態によれば、そのようなシステムの一例は、異なるコンピュータタイプによって実現され、異なるソフトウェアを用いる、地理的に別個のシステムの使用であるが、バックアップデータは、それらのシステム間で、ニュートラルなフォーマットを用いて、いずれのシステムに対しても最小の依存性で、転送されることができる。これの、より厳格でないバージョンは、プライマリサイトおよびバックアップサイトが同じ種類の機器を用いているが、同時にはアップグレードされないことである。したがって、通常、バックアップサイトは、プライマリサイトにおいてバージョンＮ＋１に関して十分な信頼が確立されるまで、バージョンＮを使用し続ける。

【0125】

一実施形態によれば、別のアプローチは、並列に動作する同じ機能の、いくつかの独立した実現例を有することである。このアプローチは、クリティカルコンポーネントの複数のバージョンが互いに異なるチームによって互いに独立して開発された空間ミッションにおいて用いられてきた。クラスタ通信インフラストラクチャに適用されるこのアプローチの、より極端でないバージョンは、異なるベンダからのギア（ＨＷおよびＳＷ／ＦＷ）によって各々が実現される２つの独立したネットワークを有することであるが、コンピュータの対間の通信は、２つのネットワークインフラストラクチャ間でフェイルオーバーし得る。ネットワーク冗長性のためのこのアプローチは、その場合、このレベルでも同様の種類の独立性および冗長性を提供するために、異なる種類のコンピュータおよびホストソフトウェアがクラスタ内で用いられるかどうかに直交して適用され得る。

【0126】

一実施形態によれば、依然として、実用的な観点から、コストおよび複雑性もまた、ミッションクリティカルな、高可用性システムを設計する場合でも、重要な因子である。し
たがって、異なる展開は、関連するシステム展開のための予算およびリスクシナリオに適合させるために、異なるレベルの冗長性および異なるレベルの複数のインフラストラクチャタイプ（すなわち、２つ以上の場合）を用いることができる。

【0127】

一実施形態によれば、完全に冗長なプライベートファブリックは、管理および輻輳問題／バグの伝播、ならびに単一のサブネットとして実現される場合のリンク障害および一方の冗長部分から他方の冗長部分への再構成によって引き起こされる「外乱」を依然として受ける。

【0128】

一実施形態によれば、２つ（以上）の完全独立または半独立のファブリックを提供するために、ホストは、ホストの対が、各々、異なる独立したファブリックへの単一の接続を失った場合に、接続性の損失を防止するために、各ファブリックへの冗長接続性を含むことができる。

【0129】

一実施形態によれば、課題は、２つのファブリックの間に、各ファブリックの通常の管理とは無関係であって、他のオプションが存在しない場合にデータ通信に用いられる冗長接続性を提供することである。

【0130】

図１４は、一実施形態による、高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムを示す。

【0131】

一実施形態によれば、レールＡ １４０１およびレールＢ １４２１のような２つ以上のレールを設けることができる。図示されないが、各独立レールは、１つまたは複数の相互接続されたスイッチ、ならびにＭＣプロキシ１４０２およびＭＣプロキシ１４２２などのマルチキャストプロキシ（ＭＣプロキシ）を含むことができる。さらに、各レールは、ＨＡＰＳ１４０３およびＨＡＰＳ１４２３などの高可用性パスサービス（ＨＡＰＳ）を含むことができる。レールは、ホスト１ １４３０～ホストＮ １４４０などの、いくつかのホストに接続され得る。図示されていないが、各ホストは、１つまたは複数のホストチャネルアダプタを介してレールに接続された１つまたは複数のエンドノードを含むことができる。さらに、エンドノードは、仮想化された環境に関して上述したように、（例えば、仮想スイッチ、仮想ポート、または上述のもしくは本質的に同様の他の同様のアーキテクチャを利用して、）１つまたは複数の仮想マシンを含むことができる。一実施形態によれば、各ホストは、ＭＰ選択１４３１およびＭＰ選択１４４１などのマルチパス選択コンポーネントを含むことができる。

【0132】

一実施形態によれば、用語「レール」は、２つ以上の独立したファブリック／サブネットおよびホストからの冗長接続性／リンクの両方を識別するよう用いられ得る。各レールは、エンドノード間において、冗長な、分離した、ポイントからポイントへの（ユニキャスト用）トラフィック、またはポイントから複数ポイントへの（マルチキャスト）トラフィックを提供することができる。

【0133】

一実施形態によれば、レールＡおよびレールＢは、１つまたは複数のレール間リンク（ＩＲＬ）を介して接続することができる。

【0134】

ある実施形態によれば、用語「ＩＲＬ」（レール間リンク（Inter Rail Link））は、
スイッチ間リンク（ＩＳＬ（Inter Switch Link））に類似していると考えることができ
る。しかしながら、ＩＲＬは、いずれのレールの一部でもないことによって、制限された態様で用いられ得る。

【0135】

一実施形態によれば、「ＭＣプロキシ」という用語は、マルチキャストプロキシを指す
ことができる。ＭＣプロキシは、選択されたマルチキャストパケットを一方のレールから他方のレールに転送する高可用性コンポーネントを含むことができる（例えば、ＡＲＰ（アドレス解決プロトコル）要求）。

【0136】

一実施形態によれば、「ＨＡＰＳ」という用語は、ＨＡ（高可用性）パスサービスを指すことができる。ＨＡＰＳは、１つのレールのコンテキスト内で動作するが、ＩＲＬを介したユニキャストデータトラフィック転送が、２つのホストが通信するのに必要とされる／要求されるときにはいつでもをそれを可能にするために他のレール内のピアと通信する高可用性コンポーネントを含むことができる。

【0137】

一実施形態によれば、用語「ＭＰ選択」は、異なるピアホストへの異なる接続のためにどのレールを用いるかを選択するホストベースのＨＡ／マルチパス論理を指すことができる。

【0138】

一実施形態によれば、単一のラックトポロジにおいて、ラック内の２つのリーフスイッチは、２つのレールを表すことができる（すなわち、２つのレールがハードウェアによって分離される最小トポロジ）。リーフスイッチの間には少なくとも２つのＩＲＬが存在し得る。インフィニバンドトポロジの場合、各リーフスイッチは、各それぞれのレールに対するマスタサブネットマネージャである埋め込まれたサブネットマネージャを有する単一のサブネットとすることができる。

【0139】

一実施形態によれば、マルチラックトポロジにおいて、各ラック内の２つのリーフスイッチは、２つのレールを表すことができる。単一のラック内の各リーフスイッチは、異なるレールを表す。各ラック内の少なくとも１つのスパインスイッチ。スパインのセットは、２つのグループ、すなわち各レールに１つ、に分割される。単一のスパインが任意のレールにおいてＳＰＯＦ（単一障害点）であることを避けるために、デュアルおよび３ラック構成の特別な取扱いがあり得る。１つのレール内のリーフスイッチは、同じレール内のすべてのスパインに接続される（が、他のレールには接続されない）。Ｍ＞１の場合、ＩＲＬは各レールからの２つ以上のスパインの対の間にある。インフィニバンドトポロジの場合、冗長ＳＭを提供し、各レール内において２つ以上のスイッチ（または場合によっては専用のホスト）上に位置させることができる。

【0140】

一実施形態によれば、単一ラックトポロジおよびマルチラックトポロジの両方において、ファットツリールーティングは、レール間リンクを無視することができる。インフィニバンドトポロジの場合、異なるレールは、異なるＭ＿Ｋｅｙ（管理キー）を用いて構成され、ＩＲＬにわたるサブネットマネージャ対話／干渉がないことを保証する。

【0141】

一実施形態によれば、「ＨＡパスサービス」（ＨＡＰＳ）は、各サブネット内において完全なＨＣＡノードおよびポートポピュレーションを追跡することができる。（これはまた、複数のＨＣＡ構成を伴うホストを処理するためのシステムイメージＧＵＩＤも含み得る）。

【0142】

一実施形態によれば、ＨＡＰＳは、ＳＡまたは特別なプロトコルからＧＩＤサービス中／ＧＩＤサービス外イベント通知を用いることができる。ＨＡＰＳがホストベースのサービス（ＭＣプロキシインスタンスと同一場所に位置してもよい）として実現される場合、ノードポピュレーションを追跡するためにデフォルトで特別なプロトコルは必要とされないが、ＨＡＰＳは、関連するＨＣＡポートがメンバーとなり得るパーティションによって制限される範囲を有することになる。

【0143】

一実施形態によれば、マスタＳＭと同一場所に位置するＨＡＰＳ実現例は、ＳＭとのよ
り直接的な対話を有することができ、特定のパーティションのみを表すことに限定されないであろう。

【0144】

一実施形態によれば、ＨＡＰＳは、各Ｌ２サブネットにおいて「クロスリンク」ポートを有するスイッチを追跡し続けることができ、正しい接続性を保証することができる。これは、「サブネット間マネージャ」がピアルータポート間の正しい接続性を保証し得る方法と同様である。

【0145】

一実施形態によれば、ＨＡＰＳは、クロスリンクを介したユニキャスト転送を必要とする「リモートＬＩＤ」のためにユニキャストＬＩＤ転送を確立することができる。これは、原則として、関連するＬ２サブネットにおいてマスタＳＭから「独立して」行われ得る。その要件は、ＳＭが命令され得ることであろう（特定のＬＩＤを用いるが、それでも、各スイッチに対して、別の構成パラメータに基づく「LinearFDBTop」値を設定する構成ポリシー）。このようにして、各Ｌ２サブネットのマスタＳＭは重複しないＬＩＤ範囲で動作するであろうが、各Ｌ２サブネットのスイッチは、それでも、ユニキャストパケットを他の（冗長）Ｌ２サブネットに属する範囲においてＤＬＩＤ値とともに転送できるであろう。

【0146】

一実施形態によれば、ＬＩＤ範囲境界が線形転送テーブル（Linear Forwarding Table
）（ＬＦＴ）ブロック境界上に整列される限り、ＨＡＰＳがＬＦＴブロックを更新して、ユニキャスト交差接続性をローカルサブネット内のマスタＳＭとは独立して（およびそれと同時に）管理することが可能である。実際の更新は、ＳＭＰ動作を介して直接、またはスイッチ上の特別なエージェントを介して実行されてもよい。

【0147】

一実施形態によれば、ある代替スキームは、ＨＡＰＳが、ローカルＳＭに要求して、関連するクロスリンクポートを、このクロスリンクポートを介したリモート接続性のために現在要求されるすべてのリモートＬＩＤを表すべく考慮するようにすることである。（これはルータポートの処理と同様であるが、ルータポートは通常のサブネット発見／初期化プロセスの間に処理される単一のＬＩＤを必要とするだけである一方、これは完全に新たなＳＭ動作であろう。）
本実施形態では、ローカルマスタＳＭ／ＳＡは、関連のＤＬＩＤを反映するリモートポートＧＩＤのためのパスレコードを与えられ得る（どのようにして「サブネット間マネージャ」がルータベースのコンテキストにおいてローカルマスタＳＭにリモートポートのためのパスレコードを提供するかと類似する）。ルータポートなしでは、ＳＡは、供給された情報に基づいてパスレコードを参照することができるが、クロスリンクポートはローカルサブネットにおける「ローカル宛先」であると理解することができる。

【0148】

一実施形態によれば、このユニキャストクロスリンク処理が、パスレコードクエリを必要としないスキームと組み合わせられる場合、（例えば、２０１７年１月２６日に提出された出願番号第１５，４１６，８９９号の「SYSTEM AND METHOD FOR SUPPORTING NODE ROLE ATTRIBUTES IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT（高性能コンピューティ
ング環境でノード役割属性をサポートするためのシステムおよび方法）」と題される米国特許出願、および「Filtering Redundant Packets in Computer Network Equipments（コンピュータネットワーク機器における冗長パケットのフィルタリング）」と題される米国特許第７，９９１，００６号を参照されたく、それらの全体をここに引用により援用する）、ローカルＳＭ／ＳＡは、リモートポートＧＵＩＤへの経路についてまったく知る必要がない。

【0149】

図１５は、一実施形態による、高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムを示す。

【0150】

一実施形態によれば、この図は、高性能コンピューティング環境において冗長独立ネットワークをサポートするための単一のラック実現例を示す。

【0151】

一実施形態によれば、単一のラックトポロジ内で、ラックは、２つ以上のリーフスイッチ１５１２～１３を含むことができる。ラックは、追加的におよび任意選択的に、ある数の他のスイッチ１５１１を含むことができる。これらの追加のスイッチは、２つのリーフスイッチが単一のラックトポロジのための最小のベース構成であるため、任意選択である。

【0152】

一実施形態によれば、２つのリーフスイッチがスイッチ間リンク（ＩＳＬ）またはレール内リンク（ＩＲＬ）のセットによって相互接続される単一のラックトポロジ内では、各リーフスイッチを別個のレールに割り当てることによって、リーフスイッチ区分を通じて、２つ以上のレールを規定することができる。

【0153】

一実施形態によれば、リーフスイッチ区分がない場合、一般に、パケットバッファ割り当ておよびスイッチＨＷリソース編成に対するスイッチハードウェア固有の制約に依存して、どのポート番号がＩＳＬのために用いられ得るかについての制約があり得る。

【0154】

一実施形態によれば、このような状況では、各リーフスイッチ１５１２および１５１３は、ＩＳＬはＩＲＬを表す別個のレールを表す。インフィニバンドファブリックの特定の場合では、各リーフスイッチは、マスタサブネットマネージャである埋め込まれたサブネットマネージャを有する単一のサブネットを表す。

【0155】

一実施形態によれば、各リーフスイッチ上のポートが、各リーフスイッチ内に２つのレールを提供するように区分される状況では、各リーフスイッチにおけるポートの総数は、２つのパーティションに分割され、各パーティションは、独立または半独立のレールを表す。ＲｏＣＥファブリックパーティション内では、やはり、ＩＳＬのためにどのポート番号を使用できるかに関して制限があり得る。（デフォルトでは、同じポートのセットが、区分されたリーフスイッチの場合および区分されていないリーフスイッチの場合の両方において、ＩＳＬに用いられることになる。）
一実施形態によれば、ＲｏＣＥファブリックとより小さい（例えば、４分の１ラック）構成におけるプライベートファブリックベースのシステムからのクライアントネットワークへのアクセスとの両方を実現するために必要とされるスイッチの数を低減するために、リーフスイッチは、区分され（例えば、リーフスイッチ上のポート）、プライベートＲｏＣＥファブリックを、プライベートＲｏＣＥファブリックを表す１つの物理的パーティション（すなわち、物理ポート／コネクタのセット）と、クライアントネットワークへのアクセスを表す別の重複しないパーティション（例えば、オンプレミスのデータセンターネットワーク）とに実現するために用いられ得る。したがって、そのような物理的に区分された各スイッチは、プライベートＲｏＣＥファブリック専用のポートのセットのみがＲｏＣＥファブリック内で接続性を表すことができる（そして逆もまた同様である）、２つの重複しないポートのセットを有することができる。

【0156】

図１６は、一実施形態による、高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムを示す。

【0157】

一実施形態によれば、マルチラックトポロジでは、Ｘ個のラックが存在することができ、各ラックは、少なくともあるリーフスイッチを含むある数のスイッチを含む。図示の実施形態では、システム１６００は、ラック１ １６１０、ラック２ １６２０、ラックＸ－１ １６３０、およびラックＸ １６４０を含むＸ個のラックを含む。各ラックは、複
数のスイッチを含み、ラック１はリーフスイッチ１６１２～１３およびスパインスイッチ１６１１を含み、ラック２はリーフスイッチ１６２２～２３およびスパインスイッチ１６２１を含み、ラックＸ－１はリーフスイッチ１６３２～３３およびスパインスイッチ１６３１を含み、ラックＸはリーフスイッチ１６４２～４３およびスパインスイッチ１６４１を含む。各スパインスイッチは、図に示されるように、２つのレール間リンクにも接続される。

【0158】

一実施形態によれば、マルチラックトポロジにおいて、各ラックは少なくとも２つのリーフスイッチを含み、それらのリーフスイッチは別個のレールに属する。図中、各スイッチが属するレールは、各スイッチに示される「１」または「２」のいずれかで示される。同様に、マルチラックトポロジでは、各ラックに少なくとも１つのスパインスイッチがある。スパインスイッチのセットは、レールごとに１つずつ、２つのグループに分割される。１つのレール内のリーフスイッチは、同じレールのすべてのスパインスイッチに接続されるが、異なるレールのスパインスイッチには接続されない。各レールからのスパインスイッチの２つ以上の対の間には１より多いＭ個のＩＲＬが存在し得る。インフィニバンドトポロジにおいて、冗長サブネットマネージャは、各レール内の２つ以上のスイッチ（または専用ホスト）上にある。

【0159】

一実施形態によれば、各ラック内の各リーフスイッチは、ファブリック内のすべてのスパインスイッチの間に分散されるアップリンクのセットを有する。概して、パケットバッファ割り当ておよびスイッチＨＷリソース編成に対するスイッチＨＷ固有の制約に依存して、アップリンクのためにどのポート番号を使用できるかについての制約があり得る。各スパインスイッチは、ファブリック内のすべてのリーフスイッチの間に分散されるある数のダウンリンクを有する。

【0160】

一実施形態によれば、スパインスイッチがダウンリンク接続性を提供するよう想定されるだけである限り、異なるポート間で特性に差がある必要はない。しかしながら、特定の構成において、すべてのスパインポートが利用（接続）されるわけではない場合があるので、ダウンリンクに使用できるポート番号を制限する理由が依然として存在する。

【0161】

一実施形態によれば、マルチラック構成の場合、典型的には、区分されたリーフスイッチの使用はない。一方、上述のように、単一ラック構成は、区分されたリーフスイッチを用いてもよく、用いなくてもよい。したがって、単一ラック構成の場合のファブリック定義は、用いられるリーフスイッチ構成が区分されているか否かに関する情報も含み得る。しかしながら、既存の単一ラック構成を拡張することに基づいて作成される、より小さいマルチラック構成は、１つまたは複数のラック内で、区分されたリーフスイッチを用いることもできる。

【0162】

一実施形態によれば、単一ラックトポロジおよびマルチラックトポロジの両方が、２つの異なる実施形態、すなわち、完全独立レールおよび半独立レールをサポートすることができる。

【0163】

一実施形態によれば、完全に独立したレールトポロジの場合、各レールは、独立したスイッチのセットからなり、異なるレールに属するスイッチポート間に接続性は存在しない。これの典型的な使用事例は、サーバ当たり２つ以上のデュアルポートアダプタを有する。

【0164】

一実施形態によれば、そのような場合、各サーバ（例えば、ホスト）は、各レールへの冗長接続性を有することができる。したがって、任意のサーバについて単一のアダプタまたは単一のアダプタポートに関して障害点が１つもないことは、対応するサーバが、任意
の個々のファブリックレール上でデータトラフィックを送信および受信できないことにつながり得る。

【0165】

一実施形態によれば、２つのサーバが両方とも少なくとも１つの共通レールへの接続性を有するわけではない場合、サーバの対（または、ＶＭの任意の対－サーバの対の各々に１つずつ）は、クラスタノード間のファブリックベースの通信が必要とされる場合に同じ論理クラスタに属することはできない。

【0166】

一実施形態によれば、各サーバ内のアダプタの非重複サブセットがレールの非重複セットに接続される（すなわち、レールの非重複セットのうちの２つ以上に接続するポートを有するアダプタが存在しない）場合、異なるレールは、通信プロトコルならびにスイッチファームウェア、ファブリック管理ソフトウェア、アダプタファームウェアおよびアダプタドライバソフトウェアの両方を含むソフトウェアおよびファームウェアバージョンに関しても独立している。

【0167】

一実施形態によれば、本明細書に記載されるシステムおよび方法は、半独立レールをさらにサポートすることができる。

【0168】

一実施形態によれば、半独立レールトポロジにおいて、各レールは、独立したスイッチのセットからなり、異なるレールに属するスイッチポート間に通常の場合にデータトラフィックに用いられる接続性はない。しかしながら、異なるレールにおけるスイッチ間には、同じレールへの動作可能な接続性を双方が有するわけではないために他の態様では通信することができないであろうサーバの対間に接続性を提供するために用いられるよう、「休眠中の」物理的接続性が存在し得る。そのような接続は、ＩＲＬによって、または他の手段によって実現され得る。

【0169】

一実施形態によれば、この構成の典型的な使用例は、各アダプタポートが異なるレールにおいてあるリーフスイッチに接続される単一のデュアルポートアダプタだけを典型的に有する場合である。この場合、任意のサーバに対する任意の単一のポート／リンク障害は、それが、対応するファブリックレール上でデータトラフィックを送信または受信することができないことを意味する。

【0170】

一実施形態によれば、２つのサーバが両方とも少なくとも１つの共通レールへの接続性を有するわけではない場合、異なるレール内のスイッチ間の「休眠」接続性の一部を利用して、この特定のサーバの対間の接続性を再確立し得るか、または代替的にそのサーバの対（または、ＶＭの任意の対－サーバの対の各々に１つずつ）は、クラスタノード間のファブリックベースの通信が必要とされる場合に同じ論理クラスタに属することはできない。

【0171】

図１７は、一実施形態による、高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムを示す。

【0172】

より具体的には、この図は、ＩＲＬゲートウェイを有するデュアルレールトポロジを示す。

【0173】

一実施形態によれば、レールＡ１７０１およびレールＢ１７２１などの２つ以上のレールを設けることができる。図示されないが、各独立レールは、１つまたは複数の相互接続されたスイッチ、ならびにＭＣプロキシ１７０２およびＭＣプロキシ１７２２などのマルチキャストプロキシ（ＭＣプロキシ）を含むことができる。さらに、各レールは、ＨＡＰＳ１７０３およびＨＡＰＳ１７２３などの高可用性パスサービス（ＨＡＰＳ）を含むこと
ができる。レールは、ホスト１ １７３０～ホストＮ １７４０などの、いくつかのホストに接続され得る。図示されていないが、各ホストは、１つまたは複数のホストチャネルアダプタを介してレールに接続された１つまたは複数のエンドノードを含むことができる。さらに、エンドノードは、仮想化された環境に関して上述したように、（例えば、仮想スイッチ、仮想ポート、または上述のもしくは本質的に同様の他の同様のアーキテクチャを利用して、）１つまたは複数の仮想マシンを含むことができる。一実施形態によれば、各ホストは、ＭＰ選択１７３１およびＭＰ選択１７４１などのマルチパス選択コンポーネントを含むことができる。

【0174】

一実施形態によれば、レール間リンク１７０５～１７０８に対する接続性を切り換えるための直接切換の代わりに、いくつかのゲートウェイインスタンス１７５０および１７５２を設けることができ、各ゲートウェイインスタンスはパケット処理エンジン１７５１および１７５３を提供する。

【0175】

一実施形態によれば、パケット処理エンジン（ＰＰＳ）は、ゲートウェイノードなどの、トポロジ内のノードに設けることができる。

【0176】

一実施形態によれば、冗長ファブリック間の独立性のレベルを増加させるために、制御およびデータトラフィックの両方のための直接的なスイッチ－スイッチリンクの代わりに、デュアルポート高性能パケット処理エンジン（ＰＰＳ）を用いることができる。

【0177】

一実施形態によれば、これらの種類のパケット処理エンジンは、追加の複数の目的のためにスケーラブルな態様で用いることができる。これらのＰＰＳは、異なるシステムインスタンスの間にファイアウォールを提供するために用いることができる。ＰＰＳは、異なるプライベートファブリックを接続するようクラウド／データセンタネットワークへのゲートウェイを提供するために用いることができる。ＰＰＳは、ＩＢベースのプライベートファブリックとＥｎｅｔ（イーサネット）ベースのプライベートファブリックとの間にゲートウェイを提供するために用いることができる。ＰＰＳは、プライベートファブリックとクライアントネットワークとの間にゲートウェイを提供するために用いることができる。

【0178】

一実施形態によれば、システムおよび方法は、物理的および論理的接続性を追跡することができる。これは、接続されたエンドポートのリーフスイッチ監視およびスイッチ間接続性を利用することによって達成することができる。さらに、システムおよび方法は、すべての関連するエンドノードおよびポートに関するすべての関連する接続性ならびに電源ＯＮ情報をすべての関連するピアノードに配信するために階層的クエリおよび報告スキームを利用することができる。そのような報告は、ローカルリーフスイッチへの完全な接続性を有するが中間ファブリックにおける接続性は制限されるノードおよびポートも含み得る。

【0179】

さらに、システムおよび方法は、電源が入っているアダプタ／ＮＩＣファームウェア／ドライバを利用することができ、－経路再バランス化およびフェイルオーバーを容易にすることに加えて、追加のピア－ピアチェックの必要性を低減／回避するために、（リンク障害に加えて）ノード電源ＯＦＦを検出し報告するよう、スキームをチェックすることができる。

【0180】

一実施形態によれば、システムおよび方法は、マルチキャスト、アドレス解決、および経路選択をサポートすることができる。ＡＲＰのようなべき等マルチキャスト動作は、複数のレール上で並行して行うことができる。マルチキャストのための「少なくとも１回」セマンティクスを保証するために、選択的複製が許可されるか、またはマルチキャストト
ラフィックは、受信側が単一のＭＣメッセージを１回だけ処理することを可能にする拡張プロトコルを用いることができる。同じノードへの複数の同時アドレス解決要求は、異なるレール上の複数のインターフェイスによって応答されることができ、次いで、要求側は、さらなる通信のために使用すべきレールを選択することができる。

【0181】

図１８は、一実施形態による、高性能コンピューティング環境における冗長独立ネットワークのための方法のフローチャートである。

【0182】

ステップ１８１０において、本方法は、１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、１つまたは複数のスイッチと、１つまたは複数のラックとを提供することができ、１つまたは複数のラックの各々は、１つまたは複数のスイッチのセットを含み、１つまたは複数のスイッチの各セットは、少なくともリーフスイッチを含み、さらに、複数のホストチャネルアダプタを提供することができ、複数のホストチャネルアダプタのうちの少なくとも１つはファームウェアおよびプロセッサを含み、さらに、複数のホストを提供することができる。

【0183】

ステップ１８２０において、本方法は、２つ以上のレールをプロビジョニングすることができ、２つ以上のレールは、複数のホスト間に冗長接続性を提供する。

【0184】

ステップ１８３０において、本方法は、複数のホスト間のデータトラフィックを、２つ以上のレールのうちのあるレールに分離することができる。

【0185】

一実施形態によれば、高可用性クラスタネットワーク／ファブリックを実現するとき、冗長性は、ファブリックの１つの領域における問題がファブリックの他の冗長領域に伝播するリスクを最小化する態様で実現されることが重要である。

【0186】

一実施形態によれば、また、ファブリック内で回復またはフェイルオーバーアクションが必要とされるとき、そのようなアクションが、著しい性能または順方向進行（forward progress）問題を引き起こし得る負荷を、制御面またはデータ面インフラストラクチャのいずれにも課さないことが重要である。

【0187】

一実施形態によれば、システムサイズをスケーリングし、レガシー高可用性ホスト通信ランタイムシステムと互換性があるようにするために、各ホストは、ファブリックへの冗長インターフェイス接続性を有することができ、そのような冗長インターフェイスの各々は、冗長ファブリック内の任意の他のインターフェイスに到達することができる。特に、これは、２つのホストが各々１つのインターフェイスと問題を有する場合、それらは依然として残りの動作可能なインターフェイスを用いて通信することができるはずであることを示唆する。したがって、インターフェイス冗長性は、各個々のホストに適用されることができ、どのインターフェイスが他のホスト上で利用可能であるかにまったく依存しない。

【0188】

一実施形態によれば、ホストインターフェイスまたはスイッチが故障するたびに、関連する通信を開始するためにどのインターフェイスが用いられるかに依存せずに、そのような通信を再確立することが可能である。このことは、ネットワークレベル冗長性が、ネットワークの一方に注入されるパケットが他方のネットワークに転送されることができない２つの完全に独立したネットワークに基づき得ないことを暗示する。したがって、冗長ネットワーキングコンポーネント間の独立性を最大にしながらレガシーＨＡ通信方式をサポートするために、「半独立レール」モデルを用いることができる。

【0189】

「半独立」ＨＡファブリックに対する目標：
一実施形態によれば、各冗長ホストインターフェイスは、ＨＡファブリックにおいて、独立したＬ２サブネット（別名「レール」）に接続するべきである。

【0190】

一実施形態によれば、２つのＬ２サブネットにまたがる単一のブロードキャストドメインが存在することができ、それは、単一のインターフェイスからのＡＲＰ要求が、他のすべての動作可能なホストインターフェイスに、各そのようなインターフェイスがどのＬ２サブネットに直接接続されるかとは無関係に、到達することを可能にする。

【0191】

一実施形態によれば、ホスト間のデータトラフィック（例えば、ＲＤＭＡ）は、Ｌ２サブネットのうちの少なくとも１つがホストの各々について少なくとも１つの接続された動作可能なインターフェイスを有する限り、Ｌ２サブネット間で交差すべきではない。

【0192】

一実施形態によれば、通信する必要がある任意の対のホストが、両方とも、単一のＬ２サブネット上においてインターフェイス間でデータトラフィックを確立することができるというわけではないときはいつでも、Ｌ２サブネット間の経路が、関連するホスト間において必要なデータトラフィックのために確立されるべきである。

【0193】

一実施形態によれば、各ホスト上のホストスタックは、各ホスト上のデフォルト判断が異なる「レール」を含む場合であっても、特定の他のホストとの通信のためにどのインターフェイスを用いるかを容易に判断することができる。

【0194】

一実施形態によれば、インフィニバンドの場合、ホストがＬ２サブネット境界を横切るＳＡ要求を開始することは可能であるべきではない。

【0195】

一実施形態によれば、ホストが一方のＬ２サブネットから他方のＬ２サブネットへ拡散する輻輳を引き起こすことは可能であるべきではない。

【0196】

インフィニバンドファブリックの具体的な実現例：
ＨＡパスサービス（ＨＡＰＳ）
一実施形態によれば、「ＨＡパスサービス」（ＨＡＰＳ）は、各サブネット内において完全なＨＣＡノードおよびポートポピュレーションを追跡することができる。（これはまた、複数のＨＣＡ構成を伴うホストを処理するためのシステムイメージＧＵＩＤを含み得る）。

【0197】

一実施形態によれば、ＨＡＰＳは、ＳＡまたは特別なプロトコルからＧＩＤサービス中／ＧＩＤサービス外イベント通知を用いることができる。ＨＡＰＳがホストベースのサービス（ＭＣプロキシインスタンスと同一場所に位置してもよい）として実現される場合、ノードポピュレーションを追跡するためにデフォルトで特別なプロトコルは必要とされないが、ＨＡＰＳは、関連するＨＣＡポートがメンバーとなり得るパーティションによって制限される範囲を有する。

【0198】

一実施形態によれば、マスタＳＭと同一場所に位置するＨＡＰＳ実現例は、ＳＭとのより直接的な対話を有することができ、特定のパーティションのみを表すことに限定されないであろう。

【0199】

一実施形態によれば、ＨＡＰＳは、各Ｌ２サブネットにおいて「クロスリンク」ポートを有するスイッチを追跡し続けることができ、正しい接続性を保証することができる。これは、「サブネット間マネージャ」がピアルータポート間の正しい接続性を保証し得る方法と同様である。

【0200】

一実施形態によれば、ＨＡＰＳは、クロスリンクを介したユニキャスト転送を必要とする「リモートＬＩＤ」のためにユニキャストＬＩＤ転送を確立することができる。これは、原則として、関連するＬ２サブネットにおけるマスタＳＭから「独立して」行われ得る。その要件は、ＳＭが命令され得ることであろう（特定のＬＩＤを用いるが、それでも、各スイッチに対して、別の設定パラメータに基づく「LinearFDBTop」値を設定する設定ポリシー）。このようにして、各Ｌ２サブネットのマスタＳＭは重複しないＬＩＤ範囲で動作するであろうが、各Ｌ２サブネットのスイッチは、それでも、ユニキャストパケットを他の（冗長）Ｌ２サブネットに属する範囲においてＤＬＩＤ値とともに転送できるであろう。

【0201】

一実施形態によれば、ＬＩＤ範囲境界が線形転送テーブル（Linear Forwarding Table
）（ＬＦＴ）ブロック境界上に整列される限り、ＨＡＰＳがＬＦＴブロックを更新して、ユニキャスト交差接続性をローカルサブネット内のマスタＳＭとは独立して（およびそれと同時に）管理することが可能である。実際の更新は、ＳＭＰ動作を介して直接、またはスイッチ上の特別なエージェントを介して実行されてもよい。

【0202】

一実施形態によれば、代替スキームは、ＨＡＰＳが、ローカルＳＭに要求して、関連するクロスリンクポートを、このクロスリンクポートを介したリモート接続性のために現在要求されるすべてのリモートＬＩＤを表すべく考慮するようにすることである。（これはルータポートの処理と同様であるが、ルータポートは通常のサブネット発見／初期化プロセスの間に処理される単一のＬＩＤを必要とするだけである一方、これは完全に新たなＳＭ動作であろう。）
本実施形態では、ローカルマスタＳＭ／ＳＡは、関連のＤＬＩＤを反映するリモートポートＧＩＤのためのパスレコードを与えられ得る（どのようにして「サブネット間マネージャ」がルータベースのコンテキストにおいてローカルマスタＳＭにリモートポートのためのパスレコードを提供するかと類似する）。ルータポートなしでは、ＳＡは、供給された情報に基づいてパスレコードを参照することができるが、クロスリンクポートはローカルサブネットにおける「ローカル宛先」であると理解することができる。

【0203】

一実施形態によれば、このユニキャストクロスリンク処理が、パスレコードクエリを必要としないスキームと組み合わせられる場合、ローカルＳＭ／ＳＡは、リモートポートＧＵＩＤへの経路についてまったく知る必要はない。

【0204】

「クロスリンク」ポートの識別および処理
一実施形態によれば、デフォルトでは、冗長インフィニバンドＬ２サブネットは、任意のクロスリンク接続性が提供される前、および／またはいずれかのＬ２サブネットにおいて任意のＳＭがアクティブとなる前に、非重複Ｍ＿Ｋｅｙ範囲で設定され得る。このようにして、各冗長サブネット内のＳＭは、近隣の冗長サブネットに接続するローカルサブネット内のスイッチポートを超えて何かを発見または構成しようとはしないであろう。

【0205】

一実施形態によれば、既存の動作可能な単一のサブネットベースのシステムは、通常の動作の著しい中断なしにデュアルＬ２サブネット構成に変換することができることは期待されない。したがって、この種の再設定は、システムサービスが動作可能であることが期待されない保守ウィンドウにおいて行われることが期待される。

【0206】

一実施形態によれば、ベンダ固有ＳＭＡ属性を用いて、スイッチの明示的な構成を特定の冗長Ｌ２サブネットに属するものとして可能にするプロトコルを確立すること、およびどのスイッチポート番号がピア冗長Ｌ２サブネットへのクロスリンク接続性を表すことが想定されるかも可能である。

【0207】

一実施形態によれば、ベンダ固有ＳＭＡ属性の使用は、「サブネット間マネージャ」が仮想ルータポートを処理する方法と同様であろう。しかしながら、この文脈ではルータポートもポート仮想化も存在しないので、実現例はまったく異なることになる。

【0208】

一実施形態によれば、詳細な構成情報、および場合によってはノード記述サブストリングへの依存に基づいて、特別なベンダ固有ＳＭＡ属性を使用せずにクロスリンクポートを識別し、取り扱うことが可能であるが、これはより複雑であり、構成エラーにもより多く晒されるであろう。

【0209】

イーサネット（プライベート）ファブリックの具体的な実現態様：
一実施形態によれば、相互接続ファブリック内の冗長性は、１つの冗長部分における障害／問題が他の部分に伝播しないことをできる限り確実にすべきである。最終的に、これは、物理的および論理的に独立したインフラストラクチャを意味する。しかしながら、これの代価は、各ノードが、各そのような独立したファブリックへの冗長な接続性を有し得るか、またはそうでなければ、単一リンク問題を各々有する２つ以上のサーバ間の接続性を回復する能力が大幅に低減されることである。各個々のサブネットについて管理または障害封じ込めに影響を及ぼすことなく、２つの独立したサブネットの間にイーサネットリンク接続を提供するための新たな方法を利用することによって、両方の目標に同時に対処することが可能である。

【0210】

一実施形態によれば、イーサネットプライベートファブリックは、スパニングツリーおよびリンクアグリゲーション変形の組合せを伴う従来のイーサネットユニキャスト転送スキームを用いて実現され得るか、または単一のＩＢサブネット内のＩＢパケットの転送が実現されるのと同じ態様で個々のユニキャスト宛先アドレスの明示的な転送を用いて実現され得る。

【0211】

一実施形態によれば、個々のユニキャストアドレスを明示的に転送する場合、ハイレベルスキームは以下のとおりである：
一実施形態によれば、スイッチとポートとの間およびスイッチポートとエンドポートとの間のポート－ポート接続性に関しての完全なトポロジが、関連するスイッチのセットから収集される。（最適化は、最初の完全な発見の後にトポロジデルタを収集することのみを含み得る。）
一実施形態によれば、トポロジ情報は、対応するインフィニバンドファブリックに用いられる同じルーティングロジック（別名ルーティングエンジン）によって処理され得るフォーマットに変換される。

【0212】

一実施形態によれば、ルーティングエンジンは、（ＩＢファブリックの場合と同様の他の関連する最適化および分散化基準と同様に）物理エンドポートが通信することを許可される（例えばＶＬＡＮ）ポリシーとともにトポロジを用い、トポロジにおいて各スイッチインスタンスについてエンドポートアドレスをポートにマッピングするタプルのリストを生成する。

【0213】

一実施形態によれば、結果として生じる（デルタ）転送エントリリストは、スイッチ（すなわち、更新を必要とするもの）に配信される。

【0214】

一実施形態によれば、マルチキャストは、いずれの場合にも、エンドポートメンバシップ処理およびＭＣパケットの転送の両方に対して、レガシーイーサネット方式を用いて実現され得る。

【0215】

マルチキャストプロキシサービス
一実施形態によれば、インフィニバンドの場合と同じ／同様の考慮事項が適用される。プロキシとされたＭＣパケット内のＬ２ソースアドレスが、対応するＡＲＰ要求「送信側ハードウェアアドレス」と同じでない場合、ＡＲＰ要求は破棄され得るか、またはユニキャストＡＲＰ応答の生成は正しくないＬ２宛先アドレスをもたらし得る。インフィニバンドの場合のように、特別なホストスタック処理への依存を避けるために、最良の方策は、プロキシが、プロキシとされたＭＣパケットを、他のＬ２サブネットにおいて元の送信側に対応するソースＬ２アドレスで送信することができることである。

【0216】

ＨＡパスサービス（ＨＡＰＳ）
一実施形態によれば、「ＨＡパスサービス」－ＨＡＰＳは、各サブネットにおいて完全なエンドポートポピュレーションを追跡することができる。

【0217】

一実施形態によれば、同じＮＩＣまたは同じホストに属するポートは、２つのサブネット間において相関させることができる。

【0218】

一実施形態によれば、ＩＢの場合のように、関連するユニキャストトラフィックが２つのサブネット間においてクロスリンクを介して転送される場合にのみホストの対が通信できる状況を識別することができる。

【0219】

一実施形態によれば、明示的なエンドポートアドレス転送がユニキャストトラフィックに用いられる場合、処理はＩＢの場合と非常に類似することになる。しかしながら、レガシーイーサネットユニキャスト転送の場合、および一般的な場合、これは、ユニキャストトラフィックに対してプロキシ型ゲートウェイ機能も必要とする可能性がある。

【0220】

一実施形態によれば、イーサネットファブリック内のユニキャスト転送はＭＡＣに基づくので、さまざまなＬ２サブネットに用いられるＭＡＣ範囲に制限はない。－唯一の制約は、各ホストポートが、関連するサイト／ドメイン内で少なくとも一意のＭＡＣを有するべきであることである。プライベートファブリックの場合、関連するドメインは、２つの冗長Ｌ２サブネットである。

【0221】

一実施形態によれば、スイッチがＬ２および／またはＬ３アドレスのいずれかに基づいて転送を実行することができる場合、Ｌ２ ＭＡＣの代わりにＬ３（ＩＰ）アドレスに基づいて転送を用いることも可能である。

【0222】

「クロスリンク」ポートの識別および処理
一実施形態によれば、個々のスイッチが、各スイッチからの近隣接続性情報と組み合わされた異なる「レール」に属するように構成されることに基づいて、同じレール／サブネット（ファットツリー）トポロジに属するスイッチ－スイッチ接続性および意図された（または偶発的な...）クロスリンク接続性の両方を識別することが可能である。

【0223】

一実施形態によれば、クロスリンク接続性は、その場合、ユニキャスト接続性またはマルチキャスト接続性のいずれの通常転送についても決して考慮されないことになるが、意図された交差接続性は、明示的なエンドポートアドレス転送の場合においてレール間経路のバックアップに用いられることになる。上で指摘したように、レガシーイーサネットユニキャスト転送スキームが用いられる場合のクロスリンクの使用は、一般に、異なるレール間のマルチキャスト転送およびユニキャスト転送の両方に対してプロキシ／ゲートウェイ機能を必要とするであろう。

【0224】

一実施形態によれば、ＲｏＣＥベースのＲＤＭＡトラフィックのためにイーサネットスイッチおよびＮＩＣを構成するとき、関連するリンクは、通常、利用可能なパケット受信
バッファ容量がある閾値を下回るときはいつでも、ダウンストリームスイッチまたはＮＩＣポートがアップストリーム送信スイッチまたはＮＩＣポートに対して「フレーム停止」を生成する「無損失」モードで設定される。次いで、送信ポートは、ダウンストリームポートがある閾値を超えるバッファ容量を再び有するまで、関連する優先度（もしあれば）でより多くのパケットを送信することを停止する（一時停止する）。

【0225】

一実施形態によれば、パケットフロー制御がネットワーク全体にわたるバックプレッシャにつながり得る他のネットワーキング技術と同様に、無損失ＲｏＣＥファブリックトポロジは、デッドロックのない態様でルーティングされなければならない。また、順方向進行を互いとは独立して有するとされるフローは、異なる優先度を用いる必要がある。

【0226】

一実施形態によれば、デュアルレールトポロジの場合、単一のレールの内部トポロジのみがデッドロックがないことに関して考慮されなければならないことを保証することは理にかなっている。クロスリンクを「損失がある」（すなわち、ダウンストリームスイッチポートはフレーム一時停止を送信しない）として構成することにより、クロスリンクによって接続されたレールにおいてトポロジを考慮することなく、各レールにおいてデッドロックのないトポロジのルーティングを提供することができる。代わりに、クロスリンクポートは、デッドロックのないルーティングの観点からローカルレール内のエンドポートと見なされ、したがって、デッドロックにつながり得るサイクル依存性の一部ではあり得ない。

【0227】

一実施形態によれば、無損失クロスリンク構成はまた、一方のレールにおける輻輳が他方のレールに拡散しないことを意味する。したがって、冗長レール間の独立性に関する重要な要件がそれによって満たされる。

【0228】

レール番号関連付け
一実施形態によれば、プライベートインフィニバンドまたはＲｏＣＥ物理ファブリック構成（本明細書で用いられる場合、「ファブリック」または「プライベートファブリック」という用語は、プライベートインフィニバンドまたはＲｏＣＥベースのファブリックを指すことがある）は、特定の数のラックに関して定義され、各ラックは関連付けられたスイッチのセットを伴い、各そのような関連付けられたスイッチは特定の役割（リーフまたはスパイン）を有する。

【0229】

一実施形態によれば、より小さな（例えば、４分の１ラック）構成におけるプライベートファブリックベースのシステムからのクライアントネットワークへのアクセスと同様に、あるスキームは、プライベートファブリックを実現するために用いられるリーフスイッチを、プライベートファブリックを表す１つの物理パーティション（すなわち、物理ポート／コネクタのセット）と、クライアントネットワーク（例えば、オンプレミスのデータセンタネットワーク）へのアクセスを表す別の非重複パーティションとに「区分する」ことである。したがって、そのような物理的に区分された各スイッチは、プライベートファブリック専用のポートのセットのみがプライベートファブリック内で接続性を表すことができる（そして逆もまた同様である）、２つの重複しないポートのセットを有することになる。

【0230】

一実施形態によれば、マルチラック構成の場合、典型的には、区分されたリーフスイッチの使用はない。一方、上述のように、単一ラック構成は、区分されたリーフスイッチを用いてもよく、用いなくてもよい。したがって、単一ラック構成の場合のファブリック定義は、用いられるリーフスイッチ構成が区分されているか否かに関する情報も含むことになる。しかしながら、既存の単一ラック構成を拡張することに基づいて作成される、より小さいマルチラック構成は、１つまたは複数のラック内で、区分されたリーフスイッチを
用いることもできる。

【0231】

一実施形態によれば、２つ以上の独立したネットワークまたは「ファブリックレール」または単に「レール」を有するファブリック構成をサポートするために、各スイッチもレール番号に関連付けられることになる。したがって、そのような「レール」の各々は、他のレールから独立している、接続性およびトラフィックパターンを伴う１つまたは複数のスイッチのトポロジを表すことになる。（すなわち、１つのレール内のスイッチと別のレール内の別のスイッチとの間には、通常の場合にデータトラフィックに用いられるリンクは存在しない。）
一実施形態によれば、プライベートファブリック定義は、以下のハイレベルな特徴を容易にする：
●すべての定義されたスイッチの存在および可用性は、実行時に自動的にチェックされることができ、例外は直ちに報告されることができる。
●各スイッチ（およびローカルスイッチポート）の構成は、完全なファブリック内におけるその役割および接続性に従って自動的に定義および検証されることができる。
●完全なファブリックの物理的接続性は、システムのタイプごとに予め定義された規則に従って検証することができる。
●ファブリック内のスイッチ間の正しくない接続性および／または劣化した接続性（すなわち、ケーブルの誤配置および／または十分な数のリンクの欠如）は、自動的に検出および報告されることができ、その一方で、（例えば、潜在的なパケット転送ループまたはデッドロックを防止するために、）正しくない接続性を防ぐことにより、追加の否定的な効果がデータトラフィックに用いられないことを保証する。

【0232】

〇特別なケースは、高い誤り率のためにリンクが無効化されているシナリオである。
●プライベートファブリック内の定義されたスイッチと、定義されたファブリック内において予期されていないデバイスを表す別のスイッチまたは他のネットワークデバイスとの間の任意の接続性を報告し、ファブリックの動作に影響を与えないようにすることができる。

【0233】

一実施形態によれば、上で概説した基本的なファブリック定義は、スイッチトポロジに焦点を当て、ファブリックの一部であるとされる（またはその一部であり得る）サーバの数および／またはタイプに関連しない。したがって、デフォルトでは、さまざまなファブリック構成タイプが表す最大数内の任意の数の物理サーバがファブリック内に存在し得る。また、このようなサーバは、基本的なファブリック定義に影響を及ぼすことなく動的に追加および削除することができる。しかしながら、そのようなプライベートファブリックベースのシステムは、物理サーバが毎日追加されるか、取り除かれるか、または交換されるという意味において非常に動的であるというシナリオはほとんどない。－物理的構成は、典型的には、何週間および何ヶ月にもわたって同じままであることが予期される。

【0234】

一実施形態によれば、サーバ構成がかなりの期間にわたって安定したままであることが期待されることに基づいて、ファブリック定義は、システム内および／または各ラック内に存在するサーバの予期される数およびタイプを定義するパラメータで任意選択肢的に拡張され得る。

【0235】

一実施形態によれば、この拡張されたファブリック定義は、以下の追加のハイレベルな特徴を容易にする：
●すべての定義されたサーバの（プライベートファブリックへの接続性に関する）存在および可用性は、実行時に自動的にチェックされることができ、例外は直ちに報告されることができる。
●現在定義されているファブリック構成において期待されないサーバ（タイプおよび／ま
たは数）の（プライベートファブリックへの接続性に関する）存在は、直ちに検出および報告されることができる。
●追加のポリシーは、予想外のサーバタイプまたは過剰数がデータトラフィックに対して受け入れられるべきか否かを決定することができるが、デフォルトは「報告および受け入れ」であろう。
●区分されたリーフスイッチを有する単一ラック構成の場合、サーバとプライベートファブリックとの間において観察される接続性を、対応するサーバとクライアントネットワークとの間において観察される接続性と相関付けることができる（すなわち、クライアントネットワークへのサーバの接続に関してポリシーが存在する限り）。

【0236】

〇クライアントネットワークに接続されているがプライベートファブリックには接続されていない任意のサーバを識別することができる（また、クライアントネットワーク接続性を有することが想定されるサーバについても逆である）。

【0237】

〇ローカルラック内のサーバとクライアントネットワークとの間の接続性に加えて、クライアントネットワークスイッチパーティションに関するアップリンク接続性を監視することも可能である。

【0238】

サポートされるファブリックトポロジ：
一実施形態によれば、「単一レール」システムの場合、サポートされるトポロジは、２つの主要なクラスに分割され得る：
●スイッチ間リンク（ＩＳＬ）のセットによって相互接続される２つのリーフスイッチを有する単一ラックトポロジ：
〇リーフスイッチ区分がない場合では：
◆概して、パケットバッファ割り当ておよびスイッチＨＷリソース編成に対するスイッチＨＷ固有の制約に依存して、ＩＳＬのためにどのポート番号を使用できるかについての制約があり得る。

【0239】

〇リーフスイッチ区分を伴うと：
◆スイッチポートの合計セットは、２つのパーティションに分割される。

【0240】

◆ＲｏＣＥファブリックパーティション内では、ここでも、ＩＳＬのためにどのポート番号を使用できるかに関して制限があり得る。（デフォルトでは、同じポートのセットが、区分されたリーフスイッチの場合および区分されていないリーフスイッチの場合の両方において、ＩＳＬに用いられる。）
◆クライアントネットワークパーティションの場合、どのポートがローカルサーバ接続性のために用いられ、どのポートがアップリンクのために用いられるかについて制限またはデフォルトがあることもあり得る。
●各ラックが少なくとも２つのリーフスイッチを有し、２つ以上のスパインスイッチが独立したラックに配置されているマルチラックトポロジ（最大Ｎラック）。

【0241】

〇各ラック内の各リーフスイッチは、ファブリック内のすべてのスパインスイッチの間に分散されるアップリンクのセットを有する。

【0242】

◆概して、パケットバッファ割り当ておよびスイッチＨＷリソース編成に対するスイッチＨＷ固有の制約に依存して、アップリンクのためにどのポート番号を使用できるかについての制約があり得る。

【0243】

〇各スパインスイッチは、ファブリック内のすべてのリーフスイッチの間に分散されるある数のダウンリンクを有する。

【0244】

◆スパインスイッチがダウンリンク接続性を提供するよう想定されるだけである限り、異なるポート間で特性に差があるとはされない。しかしながら、特定の構成において、すべてのスパインポートが利用（接続）されるわけではない場合があるので、ダウンリンクに使用できるポート番号を制限する理由が依然として存在する。

【0245】

一実施形態によれば、マルチレールトポロジの場合、各個々のファブリックレールは、上で概説したように、単一ラックまたはマルチラックトポロジのいずれかに対応することができる。しかしながら、各ラック内では、異なるリーフスイッチは異なるレールに属することができ、スパインスイッチの全セットを定義されたレール間で分割することができる。冗長性のレベルおよび各レール内のバイセクション帯域幅を増加させるために、マルチレール構成におけるすべてのレールにわたるスイッチの総数は、対応する単一レール構成におけるものより高くなり得る。

【0246】

一実施形態によれば、ファブリックレール独立性に関して２つの主なモデル、すなわち完全に独立したレールおよび半独立のレールがある。
●完全に独立したレール：
〇各レールは、独立したスイッチのセットからなり、異なるレールに属するスイッチポート間に接続性は存在しない。

【0247】

〇これの典型的な使用事例は、サーバ当たり２つ以上のデュアルポートアダプタを有する。

【0248】

◆この場合、各サーバは、各レールへの冗長接続性を有することができる。したがって、任意のサーバについて単一のアダプタまたは単一のアダプタポートに関して障害点が１つもないことは、対応するサーバが、任意のファブリックレール上でデータトラフィックを送信および受信できないことにつながり得る。

【0249】

〇２つのサーバが両方とも少なくとも１つの共通レールへの接続性を有するわけではない場合、サーバの対（または、ＶＭの任意の対－サーバの対の各々に１つずつ）は、クラスタノード間のファブリックベースの通信が必要とされる同じ論理クラスタに属することはできない。

【0250】

〇各サーバ内のアダプタの非重複サブセットがレールの非重複セットに接続される（すなわち、レールの非重複セットのうちの２つ以上に接続するポートを有するアダプタが存在しない）場合、異なるレールはまた、通信プロトコルならびにスイッチファームウェア、ファブリック管理ソフトウェア、アダプタファームウェアおよびアダプタドライバソフトウェアの両方を含むソフトウェアおよびファームウェアバージョンに関しても独立している。
●半独立レール：
〇各レールは、独立したスイッチのセットからなり、異なるレールに属するスイッチポートの間には、通常の場合にデータトラフィックに用いられる接続性はない。しかしながら、異なるレールにおけるスイッチ間には、同じレールへの動作可能な接続性を双方が有するわけではないために他の態様では通信することができないであろうサーバの対間に接続性を提供するために用いられるよう、「休眠中の」物理的接続性が存在し得る。

【0251】

〇この構成の典型的な使用例は、各アダプタポートが、典型的には、異なるレールにおいてあるリーフスイッチに接続される単一のデュアルポートアダプタだけを有する場合である。

【0252】

◆この場合、任意のサーバに対する任意の単一のポート／リンク障害は、それが、対応するファブリックレール上でデータトラフィックを送信または受信することができないことを意味する。

【0253】

〇２つのサーバが両方とも少なくとも１つの共通レールへの接続性を有するわけではない場合、異なるレール内のスイッチ間の「休眠」接続性の一部を利用して、この特定のサーバの対間の接続性を再確立し得るか、またはそのサーバの対（または、ＶＭの任意の対－サーバの対の各々に１つずつ）は、クラスタノード間のファブリックベースの通信が必要とされる同じ論理クラスタに属することはできない。

【0254】

一実施形態によれば、各スイッチは、それが属するファブリックの種類ならびにそのファブリックにおけるそれ自体の役割およびレール関連付けに関する持続的な知識を有することができる。

【0255】

一実施形態によれば、各スイッチは、定義されたファブリック内における他のすべてのスイッチのアイデンティティ、役割、およびレール関連付けに関する持続的な知識を有することができる。

【0256】

一実施形態によれば、各スイッチは、それのファブリック関連構成情報を、エクスポートされたＬＬＤＰタイプ情報を介して、直接接続されたピアポートに反映することができる。

【0257】

一実施形態によれば、単一ラックファブリック内の各リーフスイッチは、他のリーフスイッチに対する必要なＩＳＬ接続性（もしあれば）に関する事前知識を有することができる。

【0258】

一実施形態によれば、単一ラックファブリック内の各区分されたリーフスイッチは、どのポートがどのパーティションに属するかを追跡し、そのパーティションタイプを、エクスポートされたＬＬＤＰタイプ情報の一部として反映することができる。

【0259】

一実施形態によれば、マルチラックファブリック内の各リーフスイッチは、そのファブリック内のスパインスイッチに対する必要なアップリンク接続性に関する事前知識を有することができる。

【0260】

一実施形態によれば、マルチラックファブリック内の各スパインスイッチは、そのファブリック内のリーフスイッチに対する必要なダウンリンク接続性に関する事前知識を有することができる。

【0261】

一実施形態によれば、各スイッチは、各動作可能なスイッチポートの近隣接続性を、そのポートを通じてデータトラフィックを有効化することなく、決定することができる。

【0262】

一実施形態によれば、各スイッチは、発見された近隣接続性がそのスイッチの正当な接続性を表すかどうか、およびそうである場合、ローカルポートをどのように構成すべきかを、動的に決定することができる。

【0263】

一実施形態によれば、各スイッチは、関連する正当な接続性についての事前規則に従ってスイッチポートを動的に構成することができ、また、そのポートを通るデータトラフィックを可能にする前に、この構成を関連するピアポートと同期させることができる。

【0264】

一実施形態によれば、各スイッチは、その物理的近隣接続性をファブリック内の他のす
べてのスイッチと動的に共有することができる。

【0265】

一実施形態によれば、各スイッチは、管理ネットワーク上において任意の他の定義されたスイッチと通信するその能力を監視することができる。

【0266】

一実施形態によれば、各スイッチは、それが通信することができる他のスイッチのリストをファブリック内の他のすべてのスイッチと動的に共有することができる。

【0267】

一実施形態によれば、各スイッチは、物理的接続性の変化を、正当、不正確、または劣化に関するそのような接続性のステータスとならんで、および管理ネットワーク上においてファブリック内の他のスイッチと通信する能力の変化を反映するログ情報を、提供すべきである。

【0268】

一実施形態によれば、ファブリックレベルでは、スイッチの対／セット間の管理接続性の欠如、およびファブリックの残りの部分からの特定のスイッチに対する到達可能性の完全な損失を含む、ファブリックレベル接続性の問題に関する調整されたロギングおよびイベント報告があるべきである。

【0269】

一実施形態によれば、特定のスイッチとのファブリックレベル接触の予想外の（すなわち、予想されるリブート期間より長い間の）損失のような重要な事象は、自動サービス要求（ＡＳＲ）としてサポートされるべきである。

【0270】

一実施形態によれば、リーフスイッチは、ファブリックにおける予想され必要とされるサーバの存在および接続性に関するポリシー（もしあれば）に従って物理的サーバ接続性を監視することができる。

【0271】

一実施形態によれば、区分されたリーフスイッチは、ファブリックにおける予想され必要とされるサーバの存在に関するポリシー（もしあれば）に従って、サーバへのクライアントネットワーク接続性を監視することができなければならない。

【0272】

一実施形態によれば、マルチレールファブリック構成の場合、各スイッチは、すべての通常の接続性が同じレールに属するスイッチ間にあることを保証することができる。

【0273】

一実施形態によれば、半独立マルチレールファブリック構成の場合、異なるレール内のスイッチ間の任意の物理的接続性は、必要なレール間接続性に従うと検証されなければならず、この接続性は、その場合、通常の場合のデータトラフィックのために用いられるべきではない。

【0274】

異なるスイッチ役割およびトポロジに対するファブリック接続性チェック：
一実施形態によれば、各個々のスイッチは、それがその役割およびそれが属するファブリック構成／トポロジのタイプに従って正しい接続性を有することを検証することができる：
●単一ラックの単一レール構成における区分されたリーフスイッチ：
〇スイッチパーティション内に、ＩＳＬを表す少なくともＮ１－１個のポートが存在するべきである。

【0275】

◆どのポート番号をＩＳＬとして使用できるかに関する制約がある場合には、ＩＳＬを表すすべてのポートは、関連するポートのセット内になければならない。

【0276】

◆最大でＮ１－２個のＩＳＬが存在するべきである。
〇スイッチパーティション内には、ホストアダプタポートに接続する、多くてＮ２個のポートが存在し得る。

【0277】

〇各ＩＳＬは、区分された、リーフスイッチ役割を有する、単一のリモートスイッチに接続しなければならず、ピアポートはＩＳＬとして構成され、リモートスイッチは同じ単一のファブリックインスタンスに属する。
●単一ラックの単一レール構成における（区分されていない）リーフスイッチ：
〇ＩＳＬを表す少なくともＮ３－１個のポートが存在するべきである。

【0278】

◆どのポート番号をＩＳＬとして使用できるかに関する制約がある場合には、ＩＳＬを表すすべてのポートは、関連するポートのセット内になければならない。

【0279】

●最大でＮ３－２個のＩＳＬが存在するべきである。
◆ホストアダプタポートに接続する最大Ｎ４個のポートが存在し得る。

【0280】

◆各ＩＳＬは、区分されていない、リーフスイッチ役割を有する、単一のリモートスイッチに接続しなければならず、ピアポートはＩＳＬとして構成され、リモートスイッチは同じ単一のファブリックインスタンスに属する。
●マルチラックの単一レール構成におけるリーフスイッチ：
〇アップリンクを表す少なくともＮ５－１個のポートが存在するべきである。

【0281】

◆どのポート番号をアップリンクとして使用できるかに関する制約がある場合には、アップリンクを表すすべてのポートは、関連するポートのセット内になければならない。

【0282】

◆最大でＮ５－２個のアップリンクが存在するべきである。
〇ホストアダプタポートに接続する最大Ｎ６個のポートが存在し得る。

【0283】

〇、各アップリンクは、スパインスイッチ役割を有し同じ単一のファブリックインスタンスに属するスイッチに接続しなければならない
〇ファブリックインスタンスに対して定義される各スパインスイッチに対するチアップリンク接続性がなければならない。

【0284】

〇アップリンクのセットは、ファブリックインスタンスに対して定義されるすべてのスパインスイッチ間で均等に分割されなければならない。
●マルチラックの単一レール構成におけるスパインスイッチ：
〇すべての接続されたポートは、同じファブリックインスタンスの一部であるように定義されたリーフスイッチへのダウンリンクを表すべきである。

【0285】

◆どのポート番号をダウンリンクとして使用できるかに関する制約がある場合には、ダウンリンクを表すすべてのポートは、関連するポートのセット内になければならない。

【0286】

〇ホストポートに接続するポートはあるべきではない。
〇ファブリックインスタンスのために定義された各リーフスイッチを接続する少なくとも１つのダウンリンクが存在し得る。

【0287】

〇ダウンリンクのセットは、ファブリックインスタンスのために定義されるすべてのリーフスイッチ間で均等に分割されなければならない。

【0288】

一実施形態によれば、マルチレールファブリック構成の場合、接続性規則は、上述の単一レール構成の場合と同じであるが、追加の規則では、そのような接続性はすべて同じレ
ールに属さなければならない。したがって、わずか２つのリーフスイッチを有する単一ラックの場合、要件は、ＩＳＬがまったく接続されるべきではないこと（完全に独立したレール）、またはそのようなＩＳＬが「休眠状態の接続性」（半独立レール）を表すべきであることであり得る。

【0289】

一実施形態によれば、サーバ接続性に関して、接続性チェックは、定義された単一レールポリシーまたはマルチレールポリシーに従って個々のサーバがファブリックへの冗長接続性を有することを保証することができる。

【0290】

一実施形態によれば、上述の規則に準拠しない接続性は、記録され、報告され、データトラフィックに対して有効化されないことになる。

【0291】

一実施形態によれば、欠失した接続性が記録および報告され、関与するスイッチ（またはサーバ）は、劣化した（または不完全な）接続性を有すると見なされる。

【0292】

一実施形態によれば、有効な接続性は、単一または複数のファブリックレール内の関連するトポロジに対する定義された構成およびルーティング／転送ポリシーに従ってファブリック内のデータトラフィックを実現するよう用いられる。

【0293】

実現例：
一実施形態によれば、物理ファブリック接続制御実現例は、以下のコンポーネントを有する：
●スイッチベースのローカルリンク監視（ＬＬＭ）デーモンは、ローカルリンク状態、リモート接続性（もしあれば）ならびにローカルトラフィックおよびエラーカウンタを追跡する。
●スイッチベースの物理接続性制御（ＰＣＣ）デーモンは、ＬＬＭからローカルインバンドファブリック接続性情報を受信し、これに基づいて、ローカル接続性が（全体的なファブリック構成におけるその役割に対して）このスイッチインスタンスに関して要件に従うかどうか、およびそうである場合、関連するスイッチポートにどのようなハイレベル構成タイプを適用するかを決定する。
●ハードウェア（ＨＷ）構成デーモン（ＨＷＣＤ）は、スイッチおよび有効化されたリモート接続性を有する各接続されたポートについてＰＣＣによって提供されるハイレベル構成タイプに従って（スイッチＨＷプラットフォーム固有インターフェイスを用いて）スイッチおよびスイッチポートを構成する。
●ファブリック可用性および同期デーモン（ＦＡＳ）は、ファブリック内のすべての定義されたスイッチ間でファブリック構成情報および関連付けられるポリシーを同期させる。ＦＡＳはまた、ファブリック内のすべての定義されたスイッチについて管理ネットワーク上の到達可能性を追跡し、および各スイッチ上のＰＣＣインスタンス間の情報の分布を調整する。

【0294】

一実施形態によれば、ローカルスイッチについて現在定義されている持続的なファブリック構成情報および役割情報に基づいて、ＰＣＣは、ＬＬＭから受信される近隣接続性情報を、構成および役割情報ならびに事前接続性規則によって定義される予想される接続性と相関させることによって、現在のローカル接続性を常に評価する。

【0295】

一実施形態によれば、デフォルトですべての最近トレーニングされたリンクは、データトラフィックが有効化されないことになるので、関連する規則に準拠しない任意の接続性は、この状態で残されることになる。しかしながら、接続性が関連する規則に従うときはいつでも、ＰＣＣは、決定された正当なリンクタイプ（すなわち、ホストリンク、ＩＳＬ、アップリンクまたはダウンリンク）に従ってポートを構成および有効化するようにＨＷ
ＣＤに命令する。

【0296】

一実施形態によれば、新たにトレーニングされたリンクがＰＣＣによって評価されると、関連する接続性情報は、ＦＡＳを介してファブリック内の他のすべてのスイッチ上の他のすべてのＰＣＣに配信される。

【0297】

一実施形態によれば、ファブリック内のすべてのスイッチ上のＦＡＳは、他のすべてのスイッチが管理ネットワーク上で到達可能であるかどうかを常に監視し、現在のマスタＦＡＳに現在の状態を報告することになる。

【0298】

一実施形態によれば、マスタＦＡＳと同一場所に位置するＰＣＣは、任意の時点において、そのフェローＰＣＣインスタンスおよびＦＡＳの両方からインバンドおよび管理ネットワーク接続性の完全なセットを評価する。この評価に基づいて、および接続性または到達可能性の欠如に対する定義されたタイムアウト期間に基づいて、マスタＰＣＣは、アラームイベントおよび関連するＡＳＲを生成することになる。

【0299】

図１９は、一実施形態による、高性能コンピューティング環境において正しい接続性のためにレール番号関連付けをサポートするためのシステムを示す。

【0300】

一実施形態によれば、システム１９００において、ラック１ １９１０、ラック２ １９２０、ラック３ １９３０、およびラック４ １９４０を含むある数のラックがサポートされる。ラックの各々は、ある数のスイッチ、リーフスイッチ（すなわち、ＨＣＡ（図示せず）に直接接続されるスイッチ）およびある数のスパインスイッチ（リーフスイッチではない各スイッチ）の両方をサポートすることができる。これらは、リーフスイッチ１９１２－１３、１９２２－２３、１９３２－３３、および１９４２－４３、ならびにスパインスイッチ１９１１，１９２１，１９３１，および１９４１を含む。

【0301】

一実施形態によれば、システム１９００は、各レールが異なるファブリックを表すマルチレールトポロジである。図１９に示されるシステムでは、２つの独立したレール、すなわちレール１およびレール２（図に示される）がある。

【0302】

一実施形態によれば、２つ以上の独立したネットワークまたは「ファブリックレール」または単に「レール」を有するファブリック構成をサポートするために、各スイッチも、レール番号（例えば、示されるように１および２）に関連付けられる。各々のこのような「レール」は、他のレールからは独立している、接続性およびトラフィックパターンを有する１つまたは複数のスイッチのトポロジを表す（すなわち、一方のレール内のスイッチと他方のレール内の別のスイッチとの間には、通常の場合にデータトラフィックに用いられるデータリンクは存在しない。）（しかしながら、管理トラフィックのためにレール間リンクが存在し得る）。

【0303】

一実施形態によれば、示されるレールは完全に独立したレールであり、各レールは独立したスイッチのセットからなり、異なるレールに属するスイッチポート間には接続性はない。これの典型的な使用事例は、サーバ当たり２つ以上のデュアルポートアダプタを有する。この場合、各サーバ（図示せず）は、各レールへの冗長接続性を有することができる。したがって、任意のサーバについて単一のアダプタまたは単一のアダプタポートに関して障害点が１つもないことは、対応するサーバが、任意のファブリックレール上でデータトラフィックを送信および受信できないことにつながり得る。

【0304】

一実施形態によれば、２つのサーバが両方とも少なくとも１つの共通レールへの接続性を有するわけではない場合、サーバの対（または、ＶＭの任意の対－サーバの対の各々に
１つずつ）は、クラスタノード間のファブリックベースの通信が必要とされる場合に同じ論理クラスタに属することはできない。

【0305】

一実施形態によれば、各サーバ内のアダプタの非重複サブセットがレールの非重複セットに接続される（すなわち、レールの非重複セットのうちの２つ以上に接続するポートを有するアダプタが存在しない）場合、異なるレールは、通信プロトコルならびにスイッチファームウェア、ファブリック管理ソフトウェア、アダプタファームウェアおよびアダプタドライバソフトウェアの両方を含むソフトウェアおよびファームウェアバージョンに関しても独立している。

【0306】

異種かつ非対称のデュアルレイ構成
一実施形態によれば、さまざまなタイプの高性能コンピューティング（ＨＰＣ）に関連する通信のために、ならびに高性能高可用性データベースおよび他のデータサービスのためにプライベートＲＤＭＡファブリックを用いるシステムは、多くの場合、たとえば、クライアントアクセスまたは－インターネット全体上のリソースを含む－システム外部のリソースへのアクセスに用いられる異なるネットワークへの接続性を有することもできる。

【0307】

一実施形態によれば、例えば、そのようなシステムの特別なケースは、クラウド全体がグローバルクラウドネットワークを介して接続された数十万のサーバ（すなわち、数百から数千のサーバラック）を含み得るクラウドベースのシステムである。クラウド全体内では、サーバが、ＲｏＣＥ、インフィニバンド、または高性能ＲＤＭＡの他の実現例のいずれかに基づく高性能ＲＤＭＡファブリックによっても相互接続される、より小さいアイランドまたはＰＯＤ（point of delivery）（例えば、近接する８～３２個のサーバラック
のセット）が存在し得る。一実施形態によれば、ＰＯＤは、ネットワークサービスを配信するために一緒に動作するネットワーク、計算、ストレージ、およびアプリケーションコンポーネントのモジュールを意味し得る。ＰＯＤは、例えば、ある数のラック、サーバ、スイッチ、ネットワーク、およびインフラストラクチャを含むことができる。ＰＯＤは、ロール・インされ、接続され、直ぐにアップされ、走るように設計することができる。ＰＯＤは、例えば、完全なデータセンタを含むことができ、またはより大きなインストールにおける粒状の拡張単位を表すこともできる。

【0308】

一実施形態によれば、伝統的に、グローバルクラウドネットワークの性能は、高性能の専用ＲＤＭＡファブリックを介して達成され得るものよりも劣っている。これは、部分的には、クラウドネットワークにおける基本リンク速度が、専用のＲＤＭＡファブリックにおいて提供されるものよりも遅くなり得ることに起因するが（例えば２５Ｇｂ／ｓ対１００Ｇｂ／ｓ）、特に、クラウドネットワーク内のアクセス制御およびファイアウォール規則実施のための厳しい規則が、各個々のネットワークパケットの状態フルファイアウォール処理を伴うスキームを暗示し、各ノードに対する全体的なパケットレートがより低くなることおよび通信ノード間のメッセージ待ち時間を著しく増大させることにもよる。しかしながら、「従来技術の」リンク速度が増加し、オンチップ論理機能の統合レベルがすべての新たなハードウェア世代において増加するにつれて、典型的には専用のプライベートＲＤＭＡファブリックを介した通信に依存していた作業負荷が、クラウドネットワークをＲＤＭＡベースの通信のために「妥当な」性能で利用することもできる可能性がますます高くなる。

【0309】

一実施形態によれば、そのようなネットワークの別の態様は、効果的に通信することができるノードの数、および特定の分散型作業負荷に対する柔軟なノードをどのように割り当てることができるか、に関するスケーラビリティである。グローバルクラウドネットワークでの重要な利点は、任意のノードが任意の他のノードと通信することを可能にし、したがって、究極的なノード割り当て柔軟性を提供することである。しかしながら、そのよ
うなグローバル接続性はまた、スイッチホップの数に関して長い距離を示唆し、これは、通常の場合にメッセージ待ち時間を増大させ、また、ネットワーク内の異なるフロー間の輻輳による性能の低下のリスクも増大させ得る。したがって、メッセージ待ち時間および独立した作業負荷間の輻輳のリスクを低減するために、分散された作業負荷のためのノード割り当てアルゴリズムは、通常、ネットワークの隣接部分（すなわち、スイッチホップの数に関して隣接する）においてノードを割り当てることを試みることができる。

【0310】

しかしながら、一実施形態によれば、単一のチップ上のロジックの集積レベルがますます増大している結果、現在、非ブロッキングのフルクロスバーによって相互接続される１００個以上の１００Ｇｂ／ｓポートを単一のスイッチチップとして設けることができる。したがって、完全に非ブロッキングのファットツリートポロジにおいて、３つのスイッチホップだけの距離内で通信することができるノードの数は、数千のオーダーである。結果として、クラウド内における非常に大きなＰＯＤが構築され得、クラウドネットワークおよびＰＯＤ内のすべてのサーバ間におけるプライベートＲＤＭＡファブリック接続性があり、任意のそのようなサーバ間の最大距離はちょうど３つのスイッチホップである。

【0311】

一実施形態によれば、クラウドネットワークインフラストラクチャは、高性能ＲＤＭＡ通信を用いる作業負荷にも利用可能となり得るが、プライベートの専用ＲＤＭＡファブリックは、依然として非トリビアルな性能利点を有し得る可能性がある。したがって、クラウド内の個々のＰＯＤ内でのプライベートＲＤＭＡファブリックの使用は、クラウドネットワークに加えて、補助的な、より高性能な通信インフラストラクチャを提供することができ、これは多くの作業負荷にとって意味をなし得る。

【0312】

一実施形態によれば、サーバがクラウドネットワークおよびプライベートＲＤＭＡファブリックの両方によって接続されるＰＯＤは、原則的には「完全に独立したデュアルレール」構成の一例として見なすことができ、クラウドネットワークおよびプライベートＲＤＭＡファブリックは、各々、単一のレール、または潜在的には半独立もしくはさらには完全に独立したデュアルレール構成のいずれかを表し得る。しかしながら、各サーバが、デュアルリーフスイッチおよび共有されるスパインスイッチインフラストラクチャを有する単一の切り換えられるネットワークインフラストラクチャに接続するデュアルポートを有する、従来の高可用性構成は、典型的なシナリオであり得る。さらに、コスト制約ならびにそのような各レール内にさらに冗長なサーバ接続性を提供するためのスイッチおよびケーブルの数に関する複雑さのために、そのような各レールは、非冗長方式で実現されることも可能であり、サーバは、クラウドネットワークに接続する１つのアダプタおよび単一ポートと、プライベートＲＤＭＡファブリックに接続する別のアダプタおよび単一ポートとを有する。

【0313】

一実施形態によると、クラウドネットワークおよびプライベートＲＤＭＡファブリックは、異種および非対称のデュアルレール構成を表す：それらは両方ともＰＯＤ内のすべてのサーバへの完全な接続性（すなわち、非劣化の場合）を表し、それらは両方とも、ＰＯＤ内のサーバの任意の対の間において、関連するＲＤＭＡベースの通信を実現することができるが、最良の場合の通信性能は２つのレール間で同一でない場合がある。典型的な場合では、プライベートＲＤＭＡファブリックは、最良の（期待される）性能を提供し得、したがって、ＰＯＤ内のＲＤＭＡベースの通信の一次的な選択となることになる。

【0314】

しかしながら、一実施形態によると、クラウドネットワークは、例えば、以下の潜在的なシナリオにおいてもＲＤＭＡベースの通信のために選択され得る：ａ）ＲＤＭＡベースの通信を必要とするノードの対がプライベートＲＤＭＡファブリック上で通信できない場合；ｂ）異なるＰＯＤに属するノード間でＲＤＭＡベースの通信が要求される場合；ｃ）プライベートＲＤＭＡファブリック上の現在の関連のある負荷が（十分に）高く、クラウ
ドネットワーク上の現在の関連のある負荷が（十分に）低く、単一のＰＯＤ内のノードの対間の有効な通信性能は、プライベートＲＤＭＡファブリック上よりもクラウドネットワーク上の方がよい場合；またはｄ）関連する作業負荷に対するＳＬＡ（サービスレベルアグリーメント）が、プライベートＲＤＭＡファブリックによって提供されるプレミアム通信サービスの使用が要求または許可されないことを示す場合。

【0315】

一実施形態によれば、非対称デュアルレールシステムの実現例は、さまざまな管理モジュールを含む。これらは、例えば、分散型作業負荷配置オーケストレータ（ＤＷＰＯ）、ならびに接続およびレール選択マネージャ（ＣＲＳＭ）を含むことができる。ＤＷＰＯは、典型的には、全体的なクラウド作業負荷管理インフラストラクチャの一部であり、分散された作業負荷内の個々の論理ノードをクラウド／データセンタ内の物理ノードに割り当てることを担う。論理ノードは、物理ノードＯＳ内のコンテナ、物理ノード上でハイパーバイザによって制御される仮想マシン、または物理ノード上のベアメタルＯＳ／システムイメージとして実現され得る。

【0316】

一実施形態によれば、ＤＷＰＯは、作業負荷に関連付けられる配置ポリシー情報を用いて、単一のＰＯＤ内の配置が必要とされる（または望まれる）かどうか、およびそうである場合、作業負荷内の論理ノードのさまざまな対の間にどの種類の隣接性が必要とされる（または望まれる）かを判断することができる。隣接性パラメータおよび要件は、待ち時間目標ならびに予想されるトラフィックパターンおよび容量を含み得る。

【0317】

一実施形態によれば、作業負荷に対する配置ポリシー情報を既存の作業負荷に関連付けられる現在の利用レベルおよびＳＬＡと相関させることに基づいて、ＤＷＰＯは、オーケストレイトされている作業負荷に対して厳しいＳＬＡによる最良の努力または配置のいずれかを決定することができる。場合によっては、これは、既存の作業負荷が再編成されることを示唆することができる。新たな作業負荷の配置および既存の作業負荷の潜在的な再編成は、利用可能なリソースおよび関連するＳＬＡ要件に応じて、単一のＰＯＤまたは複数のＰＯＤおよびプライベートＲＤＭＡファブリックを伴うかもしくは伴わないＰＯＤを含み得る。

【0318】

一実施形態によれば、ＣＲＳＭは、クラウド作業負荷管理インフラストラクチャ全体の一体化した部分である１つの集中型コンポーネントと、すべての論理ノードにおいて通信ランタイムシステムと統合された別のコンポーネントとを有する。

【0319】

一実施形態によれば、集中型であり得るＣＲＳＭは、一次レール選択に関する分散された作業負荷内のさまざまな論理ノードに対する接続ポリシー、および各論理ノード通信することになっているピア論理ノードに対する接続パラメータポリシーを判断するために、ＤＷＰＯと協働することができる。最も簡単な場合、このポリシーは、デフォルトパラメータを用いることができ、好ましいレール（すなわち、典型的には、存在する場合には、プライベートＲＤＭＡファブリック）を、それが関連するピアノードについて接続性を提供する限り、用いることができる。より複雑なシナリオでは、論理ノード対の個々またはグループは、各方向について明示的なレール選択ポリシーおよび接続パラメータポリシーを有し得る。

【0320】

一実施形態によれば、各論理ノードＣＲＳＭインスタンスは、関連するピアノードとともに関連のある接続を確立し、維持するために、中央ＣＲＳＭからのポリシー情報を用いることになる。ノードローカルＣＲＳＭインスタンスはまた、現在利用可能な接続性および関連するレール上の負荷に従って、ならびに作業負荷全体および関連する個々のピアノードとの通信に関して存在するＳＬＡ制約に従って、個々のピアノードのための接続セットアップを適応させることができる。

【0321】

図２０は、一実施形態による、異種および非対称のデュアルレールファブリック構成をサポートするためのシステムを示す。

【0322】

一実施形態によれば、システム２０００内で、ホストノード１ ２００５およびホストノード２ ２０１０などのいくつかのホストノードをサポートすることができる。ホストノードの各々は、ホストノード１上のデュアルポートアダプタ２００６，２００７，および２００８、ならびにホストノード２上のデュアルポートアダプタ２０１１，２０１２，および２０１３など、いくつかのデュアルポートアダプタ（たとえば、デュアルポートネットワークアダプタ）を含むことができる。各デュアルポートアダプタは、２つのポートを提供することができ、それによって、ホストノードは、プライベートファブリック２０４０およびパブリッククラウドなどのクラウドファブリック２０３０などの１つまたは複数のネットワークに接続され得る。示されるように、プライベートファブリック２０４０は、例えば、２セットの重複するスイッチ、スイッチ１ ２０２０およびスイッチ２ ２０２１、ならびにスイッチ３ ２０２２およびスイッチ４ ２０２３を含み、このようなスイッチの対は、プライベートファブリック内の完全に独立したレールを表す。

【0323】

一実施形態によれば、ホストノードの各々は、複数のデュアルポートアダプタを含むことができる。例えば、図示の実施形態では、各ホストノードは、３つのデュアルポートアダプタをサポートする。これらの３つのデュアルポートアダプタのうち、各ホストノード上のデュアルポートアダプタのうちの２つをプライベートファブリック２０４０に接続することができ、１つのアダプタをクラウドファブリック２０３０に接続するよう残すことができる。このようにして、各ホストノードは、プライベートファブリックを介して、２つの完全に独立したレール（すなわち、スイッチ１およびスイッチ２、ならびにスイッチ３およびスイッチ４であり、重複するスイッチの各対は、完全に独立したレールを表す）と接続されることができ、クラウドファブリックを介しても接続されることができる。

【0324】

必要であれば、この図面の修正されたバージョンを、複数回（例えば、以下の「中」および「小」）複製して、プライベートファブリック自体が半独立および完全独立の両方であり得ること、およびホスト接続性が、１つのポートがクラウドに接続され１つのポートがプライベートファブリックに接続される単一のアダプタから、異なるアダプタがプライベートファブリック内において異なる完全に独立したレールを接続し、複数のアダプタがクラウドを接続する複数のデュアルポートアダプタまで、変動し得ることを示し得る。

【0325】

一実施形態によれば、ネットワーク内のトラフィックフローのタイプに応じて、任意の所与のパケットがプライベートファブリックを利用するべきであるという判断を行うことができる。プライベートファブリック内には、２つの完全に独立したレールが設けられ、各レールは、ホストノードにおいて別個のデュアルポートアダプタに接続され得る。いくつかの実施形態では、プライベートファブリックは、クラウドファブリックよりも高く、より安全な性能を提供するが、一般に、より少ないリソースを有し、したがって、プライベートファブリック内のフローをより高価にする。

【0326】

一実施形態によれば、プライベートファブリックは完全に制御され、冗長である。他方、クラウドファブリックの性質のため、それは一般に、完全には制御されないと考えられているが、冗長接続性を提供することができる。一実施形態によれば、少なくとも２つのファブリック（プライベートおよびパブリック）を有することは、各ホスト内の２つのアダプタがプライベートファブリック内の２つのレールへの完全に冗長な接続性を表し、第３のアダプタがパブリッククラウド内においてなんらかの（潜在的に冗長な）接続性を提供する、非対称スキームを提供する。クラウドへの冗長接続性を有することによって、これは、ホスト間のトラフィックフローに対する代替オプションを提供する。

【0327】

一実施形態によれば、作業負荷（たとえば、たとえば、図２０に示す２つのホストノード上に実現され、ＶＭが互いに通信することができるように展開および構成された複数の仮想マシンを含む）は、図２０に示す環境内で展開されることができる。所与の作業負荷に対して、ポリシーは、展開された作業負荷に関連付けることができる（例えば、「ゴールドカード」作業負荷ポリシーは、そのような作業負荷のパケットがハイレベルのプライベートＲＤＭＡファブリックを利用するべきであることを指示し、または、例えば、「エコノミー」作業負荷ポリシーは、そのような作業負荷のパケットが利用可能な帯域幅ならどれでも（例えば、利用可能であればプライベートを、そうでなければパブリッククラウド）を利用することを指示する）。したがって、これらの異なる作業負荷ポリシーは、どのタイプの接続性がシステム内の任意の所与の作業負荷に用いられるべきかを決定する際に考慮に入れることができる。例えば、第１の作業負荷が高い「ゴールドカード」作業負荷ポリシーを含む場合、その作業負荷内のパケットは、プライベートファブリック内で厳密に割り当てられ、プロビジョニングされる可能性があるだろう。代替的に、別の作業負荷がより低い「エコノミー」作業負荷ポリシーを含む場合、そのような作業負荷に関連付けられるパケットは、プライベートファブリックの利用を試み得るが、接続のためにパブリッククラウドを利用することもあり得る。

【0328】

図２１は、一実施形態による、異種および非対称のデュアルレールファブリック構成をサポートするためのシステムを示す。

【0329】

一実施形態によれば、システム２１００内で、ホストノード１ ２１０５およびホストノード２ ２１１０などのいくつかのホストノードをサポートすることができる。ホストノードの各々は、ホストノード１上のデュアルポートアダプタ２１０６および２１０８、ならびにホストノード２上のデュアルポートアダプタ２１１１および２１１３など、いくつかのデュアルポートアダプタ（たとえば、デュアルポートネットワークアダプタ）を含むことができる。各デュアルポートアダプタは、２つのポートを提供することができ、それによって、ホストノードは、プライベートファブリック２１４０およびパブリッククラウドなどのクラウドファブリック２１３０などの１つまたは複数のネットワークに接続され得る。図示されるように、プライベートファブリック２１４０は、例えば、重複するスイッチのセット、スイッチ１ ２１２０およびスイッチ２ ２１２１を含み、各スイッチは、プライベートファブリック２１４０内の半独立レールを表す。

【0330】

一実施形態によれば、ホストノードの各々は、複数のデュアルポートアダプタを含むことができる。例えば、図示の実施形態では、各ホストノードは、２つのデュアルポートアダプタをサポートする。これらの２つのデュアルポートアダプタのうち、各ホストノード上のデュアルポートアダプタの一方をプライベートファブリック２１４０に接続することができ、他方のアダプタをクラウドファブリック２１３０に接続されるよう残すことができる。このようにして、各ホストノードは、プライベートファブリックを介して、２つの半独立レール（すなわち、スイッチ１およびスイッチ２）と接続されることができ、クラウドファブリックを介しても接続されることができる。

【0331】

図２２は、一実施形態による異種および非対称のデュアルレールファブリック構成をサポートするためのシステムを示す。

【0332】

一実施形態によれば、システム２２００内で、ホストノード１ ２２０５およびホストノード２ ２２１０などのいくつかのホストノードをサポートすることができる。ホストノードの各々は、ホストノード１上のデュアルポートアダプタ２２０６およびホストノード２上のデュアルポートアダプタ２２１１のようなある数のデュアルポートアダプタ（例えば、デュアルポートネットワークアダプタ）を含むことができる。各デュアルポートア
ダプタは、２つのポートを提供することができ、それによって、ホストノードは、プライベートファブリック２２４０およびパブリッククラウドなどのクラウドファブリック２２３０などの１つまたは複数のネットワークに接続され得る。図示されるように、プライベートファブリック２２４０は、例えば、スイッチ２２２０を含み、このスイッチは、プライベートファブリック２２４０内の単一のレールを表す。

【0333】

一実施形態によれば、ホストノードの各々は、複数のデュアルポートアダプタを含むことができる。例えば、図示の実施形態では、各ホストノードは、１つのデュアルポートアダプタをサポートする。このデュアルポートアダプタ内で、１つのポートは、プライベートファブリックに接続され、１つのレールを表し、他方のポートは、クラウドファブリックを介して接続され、別のレールを表すことができる。

【0334】

図２３は、異種および非対称のデュアルレールファブリック構成をサポートするためのシステム内で、プロビジョニングされた作業負荷またはプロビジョニングされている作業負荷に対して配置ポリシーを決定するための方法のフローチャートである。一実施形態によれば、作業負荷は、ある数のホストを含むことができ、ホストは、ある数の物理ホストおよび／またはある数の仮想マシンを含むことができる。

【0335】

一実施形態によれば、ステップ２３００において、プロビジョニングされた作業負荷（既にプロビジョニングされている作業負荷、またはプロビジョニングされつつある作業負荷）を提供することができる。

【0336】

一実施形態によれば、ステップ２３１０において、作業負荷を検査して、プロビジョニングされた作業負荷に関連付けられる配置ポリシーを決定することができる。

【0337】

一実施形態によれば、ステップ２３１５において、本方法は、作業負荷の配置ポリシーが単一のＰＯＤ内において厳密な接続性を指定するかどうかを判断することができる。

【0338】

一実施形態によれば、ステップ２３２０において、配置ポリシーが単一のＰＯＤ内において厳密な配置を指示する場合、その単一のポッド内の計算ノードを、プロビジョニングされた作業負荷に割り当てることができる。

【0339】

一実施形態によると、ステップ２３２５０において、配置ポリシーが単一のＰＯＤ内において厳密な配置を指示しない場合、計算ノードをＰＯＤ考慮なしに作業負荷に割り当てることができる。

【0340】

図２４は、一実施形態による、プロビジョニングされた作業負荷またはプロビジョニングされつつある作業負荷内における特定の通信のためにファブリックタイプの選択を決定するための方法のフローチャートである。

【0341】

ステップ２４００では、一実施形態に従って、本方法は、条件のセットのいずれかが満たされているかどうかを判断することができ、条件のセットは：１）作業負荷はプライベートファブリックの使用が禁止されるか？；２）ピア（すなわち、ターゲット）ノードは異なるＰＯＤに属するか？；３）ピアノードは現在プライベートファブリック上またはそれを介して利用可能でないか？；４）プライベートファブリック上の現在の負荷は設定閾値より高く、クラウドファブリック上の負荷は別の設定閾値より低いか？を含む。

【0342】

一実施形態によれば、２４１０において、本方法は、ステップ２４００の条件のいずれかが真であるかどうかを判断することができる。

【0343】

一実施形態によれば、ステップ２４００の条件のうちの１つまたは複数が真である場合、本方法は、ステップ２４２０において、クラウドファブリックを介してターゲットノード（ピアノード）への通信をセットアップすることができる。

【0344】

一実施形態によれば、ステップ２４００の条件のいずれも真でなければ、本方法は、ステップ２４３０において、プライベートファブリックを介してターゲットノード（ピアノード）への通信をセットアップすることができる。

【0345】

図２５は、一実施形態による、異種および非対称のデュアルレールファブリック構成をサポートするための方法のフローチャートである。

【0346】

ステップ２５１０において、本方法は、１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、複数のホストを提供し得、複数のホストの各々は少なくとも１つのデュアルポートアダプタを含み、さらに、２つ以上のスイッチを含むプライベートファブリックと、クラウドファブリックを含むパブリックファブリックとを提供し得る。

【0347】

ステップ２５２０において、本方法は、複数のホストのうちのあるホストにおいて作業負荷をプロビジョニングすることができる。

【0348】

ステップ２５３０において、本方法は、プロビジョニングされた作業負荷に配置ポリシーを割り当てることができる。

【0349】

ステップ２５４０において、本方法は、プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックを、配置ポリシーに従って、プライベートファブリックおよびパブリックファブリックのうちの１つまたは複数に割り当てることができる。

【0350】

したがって、一観点から、高性能コンピューティング環境において異種かつ非対称のデュアルレールファブリック構成をサポートするためのシステムおよび方法が説明されてきた。ある方法は、１つまたは複数のマイクロプロセッサを各々が含む１つまたは複数のコンピュータにおいて、複数のホストを含み、複数のホストの各々は少なくとも１つのデュアルポートアダプタを含み、さらに、２つ以上のスイッチを含むプライベートファブリックと、クラウドファブリックを含むパブリックファブリックとを含むことを提供し得る。複数のホストのうちのあるホストにおいて、作業負荷をプロビジョニングすることができる。プロビジョニングされた作業負荷に配置ポリシーを割り当てることができる。次いで、プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックを、配置ポリシーに従って、プライベートファブリックおよびパブリックファブリックのうちの１つまたは複数に割り当てることができる。

【0351】

マルチキャスト送信複製
一実施形態によれば、電気通信システムにおいて、高可用性の問題は、何十年もの間、重要な問題であり、「キャリアグレードシステム」の概念は、サービスが回復される前のフェイルオーバー時間が非常に低いシステムを示唆している。そのようなシステムにおいて用いられる技術の１つは、２つのコピーが受信された場合であっても１つの論理パケットのみがネットワークスタックの上方に転送されるように受信側が着信トラフィックをフィルタリングすることを可能にするプロトコル拡張に基づいて、二重の独立ネットワーク上ですべてのネットワークトラフィックを複製することである。非常に高帯域幅の無損失相互接続ファブリックの文脈においては、そのような複製は、一般的な場合では、ファブリックにおけるネットワーク帯域幅および関与するサーバにおけるＩＯ帯域幅の両方の過度の使用のため、実用的ではない。しかしながら、マルチキャストトラフィックのためにこのような技術を選択的に用いることによって、独立したサブネット間の明示的なマルチ
キャスト複製の必要性を大幅に低減すること、または個々のマルチキャストメッセージがネットワーク内で失われているためにタイムアウト状況に遭遇することが考えられ得る。重要な点は、これが、単一のマルチキャストメッセージが各潜在的な受信側によって「最大で１回」受信されるという重要なセマンティクスを保ちながら達成され得ることである。

【0352】

一実施形態によれば、マルチキャストメッセージの送信側は、マルチキャスト送信動作を分類するが、それは、受信ノードが送信されているマルチキャストメッセージの単一のコピーよりも多くを処理すべきである場合にマルチキャストメッセージが否定的効果がないべき等動作を表すかどうかに基づいて行われる。この場合、２つ以上の独立したマルチキャストメッセージが、１つまたは複数のローカルインターフェイスを介して送信され、１つまたは複数の個々のマルチキャストアドレスをターゲットとすることができる。しかしながら、メッセージがべき等動作を表していない場合、同じメッセージの複数のコピーは、メッセージが、独自の方法で特定の論理メッセージインスタンスを識別するカプセル化ヘッダを有するネットワークパケットにカプセル化される限りにおいてしか、送信可能でない。カプセル化ヘッダ中の識別子は、送信側に固有の単調増加数を表し、その結果、受信側は、同じ識別番号を有するその後受信されたメッセージが、より高いレベルのプロトコルスタックおよび／または任意の受信アプリケーションに転送されないことを保証することができる。

【0353】

一実施形態によれば、このスキームの一態様は、マルチキャストベースの要求およびユニキャストベースの応答を用いるアプリケーションレベルプロトコルの場合において、応答側が、要求側を複数のコピーで混乱させるリスクなしに、複数のコピーを並列に送信することを可能にするために、同じカプセル化スキームをユニキャスト応答にも用いることができることである。代替的に、応答側は、単一の通常のユニキャスト応答だけを送信することができ、その場合、カプセル化ヘッダ内に新たなインスタンス番号を有する新たなマルチキャスト要求を送信することは、要求側次第である。この場合、クライアント／アプリケーション層における再試行による重複メッセージに留意することは、クライアント／アプリケーション固有プロトコル次第である。

【0354】

一実施形態によれば、べき等であるか否かのいずれかとして分類されないマルチキャストトラフィックの場合、デフォルトポリシーは、カプセル化スキームを用いることであり得る（すなわち、デフォルトの論理ネットワークインターフェイスは、この機能をデフォルトで提供する）。この場合、代替物を意識し、正しい分類を行うことができるクライアント／アプリケーションについて、異なる論理インターフェイスを提供することができる。

【0355】

一実施形態によれば、代替的に、デフォルトインターフェイスはレガシー機能を提供し得、カプセル化されたトラフィックは、その場合、特別な論理インターフェイスを介してこの機能を明示的に要求するクライアント／アプリケーションにのみ提供されるであろう。

【0356】

実現例：
一実施形態によれば、送信側ノードは、関連するノードが起動するたびに増分され永続的に格納される永続的な「システムイメージ生成番号」を有することができる。加えて、各送信側ノードは、カプセル化および複製を表す、論理インターフェイスを介して送信されるすべてのメッセージについて増分される「現在のメッセージシーケンス番号」を有することになる。すなわち、現在のメッセージシーケンス番号は、複製メッセージのセットの各複製メッセージについて同じである。カプセル化ヘッダ内のメッセージ識別は、その場合、「システムイメージ生成番号」と「現在のメッセージシーケンス番号」との組み合
わせ（連結）である。次いで、受信ノードは、（両方とも複製である）同じメッセージの少なくとも２つのコピーを受信すると、後に到着したメッセージを無視し、それを廃棄することができる。

【0357】

一実施形態によれば、ある実施形態では、複製されたメッセージに対して、何個の複製が用いられているかとは無関係に、ただ１つのシーケンス番号が生成される。しかしながら、メッセージが送られたレール番号を符号化するために、いくつかのビット（例えば、１ビットだけ）を残すことによって、これを拡張することが可能である。これは、トラフィックを評価する際に何らかの値を有することができ、また、２つのレール間のレール間リンクの潜在的な使用に関するより多くの情報を容易にする。しかしながら、受信アプリケーションに複数のバージョンが配信されるのを防ぐために、受信側は、同じメッセージの２つ（またはそれ以上）の複製バージョンを複製として認識する必要がある。

【0358】

一実施形態によれば、送信側ノードは、マルチキャストメッセージを複製し、送信側ノードがアクセスを有する２つ以上の独立または半独立レールの各々上でマルチキャストメッセージの各コピーを送信することができる。

【0359】

一実施形態によれば、関連する送信側ノードについて、永続的な「システムイメージ生成番号」が失われた場合、すべての可能な受信側が通知され、関連する送信側ノードについての任意の予想される現在の識別番号をリセットすることができることを保証するために、特別な手順が実行される。高可用性クラスタ構成の文脈において、「システムイメージ生成番号」の取扱いは、典型的には、あるノードを論理クラスタ内に含めるための手順の一部であり得る。したがって、あるノードがクラスタに含まれない限り、他のノードは、どのような入来受信マルチキャストパケットも、それがどの「システムイメージ生成番号」に関連付けられているかとは無関係にそのノードから受け入れることはないことになる。クラスタメンバシップ処理プロトコルは、さまざまな理由で、特に、（例えば、何らかの理由でクラッシュしたか、またはリブート中であるため）もはやノードが通信され得ない場合、そのノードをクラスタから除外すると判断することができる。この場合、クラスタメンバシップ判定は、残りのクラスタメンバに伝えられることができ、マルチキャスト通信を含む、除外されたノードとの通信が直ちに停止されることを示唆することができる。除外されたノードがリブートするたびに、または任意の理由でクラスタに（再）結合しようとするたびに、それは、その「システムイメージ生成番号」を、関連するクラスタメンバシップ結合プロトコルの一部として、交渉することができる。このようにして、それは、それの現在の次世代番号を、それを永続的ストレージから取得したことに基づいて提示することができ、または新たな世代番号がそれに対してローカルに容易に利用可能でない場合にはクラスタメンバシップ制御システムから新たな世代番号を得ることができる。いずれの場合においても、クラスタメンバシップ制御システムは、競合する世代番号が使用できないことを保証することができる。

【0360】

一実施形態によれば、各受信側は、各送信側に対して動的状態情報を維持することができ、送信側ノードのＩＤは現在期待されるメッセージ識別子と一緒に保持される。より高い数を表すカプセル化ヘッダを有する到着メッセージは受け入れられ、転送されることになり、一方、既に受信された識別子（すなわち、現在期待されている値よりも低い値）を有するメッセージは破棄されることになる。

【0361】

一実施形態によれば、カプセル化および複製されたメッセージを表すパケットを標準ネットワークトラフィックからより容易に分離するために、プロトコルは、基本パケット層において（例えば、データリンク層において特別なパケット／プロトコルタイプフィールドを用いて）代替プロトコル識別子を用いることができる。代替的に、専用マルチキャストアドレスのセットを、この複製プロトコルを実現する目的で割り当て、次いで、元のマ
ルチキャストアドレスをカプセル化ヘッダに含まれるように伝えることができる。

【0362】

図２６は、一実施形態による、高性能コンピューティング環境における複製の代わりのマルチキャスト送信複製のためのシステムを示す。特に、この図は、そのような実現例を１つのレール上に示し、他のレールは図示されていない。

【0363】

一実施形態によれば、システム２６００は、スパインスイッチ２６１１，２６２１，２６３１，および２６４１、ならびにリーフスイッチ２６１２－１３、２６２２－２３、２６３２－３３、および２６４２－４３などの、いくつかのスイッチを含むことができる。これらのスイッチは、ある数のノード２６５０～２６５３を相互接続することができる。

【0364】

一実施形態によれば、送信側ノード２６５０は、ノードが起動する度に増分され永続的に格納される永続的な「システムイメージ生成番号」２６５４を含むことができる。さらに、送信側ノード２６５０は、カプセル化および複製を表す、論理インターフェイスを介して送信されるマルチキャストメッセージのセットごとに増分される「現在のメッセージシーケンス番号」２６５５を含むことができる。マルチキャストアドレス（例えばＭＧＩＤ）に送信およびアドレス指定されるマルチキャストパケット２６５５は、「システムイメージ生成番号」と「現在のメッセージシーケンス番号」との組み合わせを表すカプセル化ヘッダを含むことができる。

【0365】

一実施形態によれば、各受信側は、送信側ノード２６５０について動的状態情報を維持することができ、送信側ノードのＩＤは現在期待されるメッセージ識別子とともに保持される。より高い数を表すカプセル化ヘッダを有する到着メッセージは、（新たなメッセージを表すので、）受け入れられ、転送されることになり、一方、既に受信された識別子、または予想されるメッセージ識別子より低い値を有するメッセージは、カプセル化ヘッダが既に受信されたメッセージを表すので破棄されることになる。

【0366】

図２７は、高性能コンピューティング環境における複製の代わりのマルチキャスト送信複製のための方法のフローチャートである。

【0367】

一実施形態によれば、ステップ２７１０において、ある方法は、複数のスイッチ、複数のホストを提供することができ、複数のホストは、複数のスイッチを介して相互接続され、複数のホストのうちのあるホストは、マルチキャスト送信側ノードを含み、送信側ノードは、システムイメージ生成モジュールおよびカレントメッセージシーケンスモジュールを含む。

【0368】

一実施形態によれば、ステップ２７２０において、本方法は、複数のスイッチを２つのレールに編成することができ、２つ以上のレールは、複数のホスト間に冗長接続性を提供する。

【0369】

一実施形態によれば、ステップ２７３０において、ある方法は、マルチキャスト送信側ノードによって、マルチキャストアドレスにアドレス指定された２つの複製マルチキャストパケットを送信することができ、２つ以上の複製マルチキャストパケットの各々は、２つのレールの異なるレール上で送信される。受信ノードは、同じマルチキャストパケットの２つのバージョンを受信することができるが、カプセル化ヘッダを扱うレイヤより上の通信スタック／クライアントには１つだけを配信することができる。

【0370】

一実施形態によれば、ステップ２７４０において、本方法は、複数のホストのうちのあるホストが２つ以上の複製マルチキャストパケットのうちの２つ以上を受信すると、通信スタックに配信する前に、２つ以上の受信されたマルチキャストパケットのうちの最初の
ものを除くすべてをドロップすることができる。

【0371】

複数の独立レイヤ２（Ｌ２）サブネットにわたる単一の論理ＩＰサブネット
一実施形態によれば、システムおよび方法は、複数のエンドポートが同じＩＰアドレスを同時に表現することを可能にすることによって、物理的に独立したＬ２サブネットにわたって仮想の単一のＩＰサブネットを提供することができる。

【0372】

一実施形態によれば、高可用性ネットワークインターフェイスモデルは、リンクアグリゲーション（ＬＡＧ）に基づくものである。このモデルでは、ホストスタックは単一の論理ポートを見て、基礎となるドライバソフトウェアならびにアダプタおよびスイッチファームウェアは、利用可能なリンク間で異なるフローが負荷分散され、障害のあるリンクに現在マッピングされているフローが残りの動作可能リンクに引き継がれることを確実にする。マルチシャーシＬＡＧ（ＭＬＡＧ）をサポートするスイッチを導入することにより、このＨＡモデルは、複数のスイッチにわたって適用することができ、１つの障害点もまったくないことを示唆する。しかしながら、このモデルは、冗長スイッチ／ネットワーク間の厳しい統合も示唆し、したがって独立ネットワークの目標に違反する。代替モデルは、ＬＡＧプロトコルをまったく使用せず、代わりに、ホスト側インターフェイスが複数のローカルネットワークポートを介して単一のＩＰアドレスを実現できるようにすることである。このようにして、発信トラフィックは、関連する論理グループ内の任意のポートを用いることができ、特定の宛先ＩＰアドレスに対する着信トラフィックは、グループ内の任意のポート上で受け入れられることになる。関与するネットワークが完全に独立している場合、ホスト側動作は、メッセージを再試行するために異なるソースポート（別名、異なるレール）を選択しなければならない場合がある。

【0373】

一実施形態によれば、汎用ホストスタックに提示されるインターフェイスモデルは、依然として、ＬＡＧ／ＭＬＡＧの場合と同じであり得る（すなわち、単一のソースＩＰアドレスを有する単一のローカルネットワークポートがある）。

【0374】

一実施形態によれば、次いで、単一のローカルＩＰ（Ｌ３）アドレスが、各ローカルエンドポートのハードウェアアドレスに関連付けられる。

【0375】

一実施形態によれば、インターフェイスドライバは、個々のローカルエンドポートが同じＬ２サブネットに接続されているかまたは独立したＬ２サブネットに接続されているかを追跡し、それに応じて発信ＡＲＰ（アドレス解決プロトコル）要求および着信ＡＲＰ要求の両方に対処することができる。発信ＡＲＰ要求の場合、インターフェイスドライバは、各ローカルポートを介して１つのマルチキャスト要求を送信することができる。着信ＡＲＰ要求の場合、インターフェイスドライバは、要求が到着したローカルポートを介して単一のユニキャストＡＲＰ応答を送信することになる。ネットワーク上で送出されるＡＲＰ応答のハードウェアアドレスは、常に、対応するローカルエンドポートのハードウェアアドレスとなる。

【0376】

一実施形態によれば、リモートＩＰアドレスとともにローカルホストスタックに提供されるハードウェアアドレスは、ローカルインターフェイスドライバが、ローカルエンドポートのうちの１つまたは複数を介してリモートＩＰアドレスに用いられる「実」ＨＷアドレスをルックアップするために用いることができる、特別な値である。

【0377】

一実施形態によれば、リモートＩＰアドレスに用いるローカルエンドポートおよびリモートハードウェアアドレスは、最適な可用性および最適な負荷分散の両方を達成するためにローカルインターフェイスドライバが経時的に動的に調整できる動的エンティティである。

【0378】

図２８は、一実施形態によるリンクアグリゲーション（ＬＡＧ）をサポートするためのシステムを示す。

【0379】

一実施形態によれば、パケット１ ２８０１などのネットワークパケットは、論理デバイス１ ２８１０（たとえば、リンクアグリゲーションデバイス）などの論理デバイスに向けられ得る。論理デバイスを通過する前に、パケットは、ローカルソースＩＰアドレス（ＳＩＰ１）、宛先ＩＰアドレス（ＤＩＰ１）、および宛先ＭＡＣ（メディアアクセス制御）アドレス（ＤＭＡＣ１）を含むかまたは（例えば、パケットヘッダにおいて）それらに関連付けられることができる。

【0380】

一実施形態によれば、論理デバイスは、たとえば、レイヤ３アドレスを含むことができる、ＩＰアドレス、ＩＰ１など、それ自体のアドレスに関連付けることができる。

【0381】

一実施形態によれば、論理デバイスは、１つまたは複数の物理ネットワークアダプタデバイス（図示せず）をさらに含むことができ、物理ネットワークアダプタの各々は、１つまたは複数の物理ポート（ＡＰ１、ＡＰ２．．．ＡＰｎ）を有することができ、各物理ポートは、それ自体のＭＡＣ（Ｌ２）アドレス（図示せず）を有してもよいが、論理デバイス２８１０の単一のＩＰアドレス（ＩＰ１）を有してもよい。

【0382】

一実施形態によれば、パケット２ ２８０２は、論理デバイスを通過した後、例えばヘッダ内に、宛先ＭＡＣアドレス（ＤＭＡＣ２）に加えて、ローカルソースＩＰアドレス（ＳＩＰ２）および宛先ＩＰアドレス（ＤＩＰ２）を含むことができる。実施形態では、ＬＡＧ状況では、これらのアドレスは、論理デバイスを通過する前のパケットと同じであり得、すなわち、ＳＩＰ１はＳＩＰ２と同じであり、ＤＩＰ１はＤＩＰ２と同じであり、ＤＭＡＣ１はＤＭＡＣ２と同じである。

【0383】

一実施形態によれば、論理デバイスは、例えば、負荷分散に基づいて、スイッチ１ ２８２０上のポート（例えばＳＰ１－１～ＳＰ１－６）のうちのそれの宛先ポートにパケット２を送出するレール／ポートを決定する。

【0384】

図２９は、一実施形態による、マルチシャーシリンクアグリゲーション（ＭＬＡＧ）をサポートするためのシステムを示す。

【0385】

一実施形態によれば、パケット１ ２９０１などのネットワークパケットは、論理デバイス１ ２９１０（たとえば、リンクアグリゲーションデバイス）などの論理デバイスに向けられ得る。論理デバイスを通過する前に、パケットは、ローカルソースＩＰアドレス（ＳＩＰ１）、宛先ＩＰアドレス（ＤＩＰ１）、および宛先ＭＡＣ（メディアアクセス制御）アドレス（ＤＭＡＣ１）を含むかまたは（例えばパケットヘッダにおいて）それらに関連付けられることができる。

【0386】

一実施形態によれば、論理デバイスは、レイヤ３アドレスを含むことができるＩＰアドレス、ＩＰ１などのそれ自体のアドレスに関連付けることができる。

【0387】

一実施形態によれば、論理デバイスは、１つまたは複数の物理ネットワークアダプタデバイス（図示せず）をさらに含むことができ、物理ネットワークアダプタの各々は、１つまたは複数の物理ポート（ＡＰ１、ＡＰ２．．．ＡＰｎ）を各々有し、物理ポートは各々、それ自体のＭＡＣ（Ｌ２）アドレス（図示せず）を有してもよいが、論理デバイス２９１０の単一のＩＰアドレス（ＩＰ１）を共有してもよい。

【0388】

一実施形態によれば、パケット２ ２９０２は、論理デバイスを通過した後、例えば、ヘッダにおいて、宛先ＭＡＣアドレス（ＤＭＡＣ２）に加えて、ローカルソースＩＰアドレス（ＳＩＰ２）および宛先ＩＰアドレス（ＤＩＰ２）を含むことができる。実施形態では、ＬＡＧ状況では、これらのアドレスは、論理デバイスを通過する前のパケットと同じであり得、すなわち、ＳＩＰ１はＳＩＰ２と同じであり、ＤＩＰ１はＤＩＰ２と同じであり、ＤＭＡＣ１はＤＭＡＣ２と同じである。

【0389】

一実施形態によれば、論理デバイスは、例えば、負荷分散に基づいて、スイッチ１ ２９２０上のポート（例えばＳＰ１－１～ＳＰ１－６）またはスイッチ２ ２９３０上のポート（例えばＳＰ２－１～ＳＰ２－６）のうちのそれの宛先ポートにパケット２を送出するレール／ポートを決定する。

【0390】

一実施形態によれば、ＭＬＡＧシナリオでは、スイッチ、スイッチ１およびスイッチ２は、スイッチの間に１つまたは複数の制御リンクをさらに含むことができる。制御リンクのため、複数のスイッチは、単一のエンティティとして現れるが、それでも、１つのみのスイッチが設けられるＬＡＧ実施形態よりも、冗長性を高める。

【0391】

図３０は、一実施形態による、高性能コンピューティング環境において複数の独立したレイヤ２サブネットにわたって単一の論理ＩＰサブネットをサポートするためのシステムを示す。

【0392】

一実施形態によれば、パケット１ ３００１などのネットワークパケットは、論理デバイス１ ３０１０（たとえば、リンクアグリゲーションデバイス）などの論理デバイスに向けられ得る。論理デバイスを通過する前に、パケットは、ローカルソースＩＰアドレス（ＳＩＰ１）、宛先ＩＰアドレス（ＤＩＰ１）、および宛先ＭＡＣ（メディアアクセス制御）アドレス（ＤＭＡＣ１）を含むかまたは（例えばパケットヘッダにおいて）それらに関連付けられることができる。

【0393】

一実施形態によれば、論理デバイスは、たとえば、レイヤ３アドレスを含むことができる、ＩＰアドレス、ＩＰ１など、それ自体のアドレスに関連付けることができる。

【0394】

一実施形態によれば、論理デバイスは、１つまたは複数の物理ネットワークアダプタデバイス（図示せず）をさらに含むことができ、物理ネットワークアダプタの各々は、１つまたは複数の物理ポート（ＡＰ１、ＡＰ２．．．ＡＰｎ）を各々有し、それらは、各々がそれら自体のＭＡＣ（Ｌ２）アドレス（図示せず）を有してもよく、各々が、それら自体のネットワーク固有ＩＰアドレス（図示せず）およびレール番号関連付け（図示せず）を有してもよい。

【0395】

一実施形態によれば、パケット２ ３００２は、論理デバイスを通過した後、例えば、ヘッダにおいて、宛先ＭＡＣアドレス（ＤＭＡＣ２）に加えて、ローカルソースＩＰアドレス（ＳＩＰ２）および宛先ＩＰアドレス（ＤＩＰ２）を含むことができる。

【0396】

一実施形態によれば、マッピング関数３０１１に基づいて、宛先ＩＰ（ＤＩＰ２）および宛先ＭＡＣアドレス（ＤＭＡＣ２）は、マッピング関数内の入力宛先ＩＰ（ＤＩＰ１）および入力宛先ＭＡＣアドレス（ＤＭＡＣ１）のルックアップに基づいて、新たなアドレスを含むことができる。ソースＩＰアドレスは同じままであり得、すなわち、ＳＩＰ１はＳＩＰ２と同じであり得る。

【0397】

一実施形態によれば、次いで、マッピング関数に基づいて、単一のレイヤ３アドレス（論理デバイスのＩＰ１）から、ＭＬＡＧシナリオとして見ることができるスイッチ１ ３
０２０およびスイッチ２ ３０３０によって表されるサブネット、ならびにＬＡＧシナリオとして見ることができるスイッチ３ ３０４０など、複数のレイヤ２サブネットにパケットをルーティングすることができる。

【0398】

一実施形態によれば、ＭＬＡＧシナリオでは、スイッチ、スイッチ１およびスイッチ２は、スイッチの間に１つまたは複数の制御リンクをさらに含むことができる。制御リンクのため、複数のスイッチは、単一のエンティティとして現れるが、それでも、１つのみのスイッチが設けられるＬＡＧ実施形態よりも、冗長性を高める。

【0399】

一実施形態によれば、示されるシステムは、１つはＭＬＡＧを介し、もう１つはＬＡＧを介する、２つのＬ２サブネットをサポートするＬ３アドレスを有する単一の論理デバイスを示すが、当業者は、単一の論理デバイスがｎ個のＭＬＡＧサブネットおよびｍ個のＬＡＧサブネットなどの複数のＬ２サブネットをサポートし、ｎとｍの和は２より大きい、異なる多様なシナリオを容易に理解するであろう。

【0400】

一実施形態によれば、論理デバイスは、例えば、負荷分散に基づいて、スイッチ１ ３０２０上のポート（例えばＳＰ１－１～ＳＰ１－６）またはスイッチ２ ２３００上のポート（例えばＳＰ２－１～ＳＰ２－６）のうちのそれの宛先ポートにパケット２を送出するレール／ポートを決定する。

【0401】

一実施形態によれば、図３０に記載されるようなシステムは、発信マッピング機能をサポートすることができる。そのような状況では、システムおよび方法は、論理宛先ＭＡＣに基づいて宛先記述をルックアップすることができる。次いで、システムおよび方法は、宛先記述から現在の物理デバイスおよびポートならびにリモート物理ＩＰおよび物理ＭＡＣを取得することができる。次いで、パケットヘッダは、パケットが送信される前にローカルおよびリモート物理アドレスで更新されることができる。

【0402】

一実施形態によれば、図３０に記載されるようなシステムは、入来するマッピング機能をサポートすることができる。そのような状況では、方法およびシステムは、着信パケットが受信される物理デバイスおよびポートに関連付けられる論理デバイス記述をルックアップすることができる。次いで、方法およびシステムは、受信物理ポートのための正しい物理宛先アドレスがパケットヘッダに含まれることを検証することができる。次いで、パケットヘッダは、パケットがホストスタックにおいてジェネリックＩＰレベルに転送される前に、ローカルデバイスの論理ＩＰＰを反映するように更新されることができる。

【0403】

一実施形態によれば、図３０に記載されるようなシステムは、発信ＡＲＰ（アドレス解決プロトコル）要求をサポートすることができる。そのような状況では、システムおよび方法は、論理デバイスに関連付けられた各物理ポートに対してＡＲＰ要求マルチキャストパケットを生成することができる。そして、各ＡＲＰ要求マルチキャストパケットにおける対応する物理ポートの関連するソースアドレスを埋めることができる。次いで、システムおよび方法は、対応する物理ポートから各ＡＲＰ要求マルチキャストパケットを送信することができる。

【0404】

一実施形態によれば、図３０に記載されるようなシステムは、着信ＡＲＰ（アドレス解決プロトコル）要求をサポートすることができる。システムおよび方法は、物理ポート上の着信ＡＲＰ要求の要求されたＩＰが、物理ポートが関連付けられる論理デバイスの論理ＩＰと対応することを検証することができる。次いで、システムおよび方法は、ＡＲＰ要求が受信された物理ポート上でＡＲＰ応答を送信することができ、ＡＲＰ応答は、論理デバイスＩＰアドレスを送信側ＩＰアドレスとして反映し、送信側ハードウェアアドレスは、物理ポートＭＡＣアドレスおよび物理ポートＩＰアドレスの両方を含む。

【0405】

一実施形態によれば、図３０に記載されるようなシステムは、着信ＡＲＰ（アドレス解決プロトコル）応答をサポートすることができる。システムおよび方法は、ターゲットＩＰおよびＨＷアドレスが受信物理ポート物理ＩＰおよび物理ＭＡＣアドレスに対応することを検証することができる。システムおよび方法は、ＡＲＰ応答の送信側ハードウェアアドレスから物理ＩＰアドレスおよびＭＡＣアドレスを記録し、それらをＡＲＰ応答において送信側ＩＰアドレスによって識別される宛先論理ＩＰアドレスと関連付けることができる。次いで、システムおよび方法は、論理宛先ＩＰアドレスの、関連する物理ポートならびに宛先物理ＩＰアドレスおよびＭＡＣアドレスへのマッピングを表すよう、論理ＭＡＣアドレスを生成することができる。ＡＲＰテーブルは、論理ＩＰアドレスおよび関連する論理ＭＡＣアドレスで更新することができる。

【0406】

図３１は、一実施形態による、高性能コンピューティング環境において複数の独立したレイヤ２サブネットにわたって単一の論理ＩＰサブネットをサポートするための方法のフローチャートである。

【0407】

ステップ３１１０において、本方法は、１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、論理デバイスを提供することができ、論理デバイスは、レイヤ３アドレスによってアドレス指定され、論理デバイスは、複数のネットワークアダプタを含み、ネットワークアダプタの各々は物理ポートを含み、本方法はさらに、複数のスイッチを提供することができる。

【0408】

ステップ３１２０において、本方法は、複数のスイッチを複数の別個のレイヤ２サブネットに配置することができる。

【0409】

ステップ３１３０において、本方法は、論理デバイスにおいてマッピングテーブルを提供することができる。

【0410】

したがって、一観点から、高性能コンピューティング環境において複数の独立したレイヤ２サブネットにわたって単一の論理ＩＰサブネットをサポートするためのシステムおよび方法が記載された。ある方法は、１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、論理デバイスを提供することができ、論理デバイスは、レイヤ３アドレスによってアドレス指定され、論理デバイスは、複数のネットワークアダプタを含み、ネットワークアダプタの各々は、物理ポートを含み、方法はさらに、複数のスイッチを提供することができる。本方法は、複数のスイッチを複数の別個のレイヤ２サブネットに配置することができる。本方法は、論理デバイスにおいてマッピングテーブルを提供することができる。

【0411】

本発明の様々な実施形態を説明してきたが、上記実施形態が限定ではなく例示として提示されていることが理解されるべきである。上記実施形態は、教示される技術の原理およびそれらの実際の適用例を説明するために選択され記載されたものである。上記実施形態は、新たな特徴および／もしくは改善された特徴を提供することによって、ならびに／または、リソース利用の低減、容量の増加、効率の向上および待ち時間の低下などの利点を提供することによって、システムおよび方法の性能を向上させるためにここに教示される技術が利用されているシステムおよび方法を例示している。

【0412】

いくつかの実施形態においては、本教示の特徴は、全体的または部分的に、プロセッサ、メモリなどの記憶媒体、および他のコンピュータと通信するためのネットワークカードを含むコンピュータにおいて実現される。いくつかの実施形態においては、本教示の特徴は、コンピュータの１つ以上のクラスタがローカルエリアネットワーク（Local Area Net
work：ＬＡＮ）、スイッチファブリックネットワーク（例えば、インフィニバンド）、またはワイドエリアネットワーク（Wide Area Network：ＷＡＮ）などのネットワークによ
って接続されている分散コンピューティング環境において実現される。分散コンピューティング環境は、一箇所において全てのコンピュータを有していてもよく、または、ＷＡＮによって接続されているさまざまな遠隔地理位置においてコンピュータのクラスタを有していてもよい。

【0413】

いくつかの実施形態においては、本教示の特徴は、全体的または部分的に、ウェブ技術を用いたセルフサービスの調整された態様でユーザに送達される共有型で融通性のあるリソースに基づいて、クラウド・コンピューティング・システムの一部またはサービスとしてクラウドにおいて実現される。（米国標準技術局（National Institute of Standards and Technology）よって定義される）クラウドの５つの特徴がある。すなわち、オン・デマンドのセルフサービス、広域ネットワークアクセス、リソースプール化、高速伸縮性、およびメジャードサービスである。クラウド展開モデルは、パブリック、プライベートおよびハイブリッドを含む。クラウドサービスモデルは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）、データベース・アズ・ア・サービス（Database as a Service：ＤＢａａＳ）およびインフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）を含む。本明細書で使用するとき、クラウドは、セルフサービスの調整された態様で、共有される融通性のあるリソースをユーザに対して配信する、ハードウェア技術とソフトウェア技術とネットワーク技術とウェブ技術とを組合せたものである。特に指定がなければ、クラウドは、本明細書で使用するとき、パブリッククラウド、プライベートクラウドおよびハイブリッドクラウドの実施形態を包含しており、全てのクラウド展開モデルは、クラウドＳａａＳ、クラウドＤＢａａＳ、クラウドＰａａＳおよびクラウドＩａａＳを含むもののこれらに限定されない。

【0414】

いくつかの実施形態においては、本教示の特徴が、ハードウェア、ソフトウェア、ファームウェアまたはそれらの組合せを用いて、またはそれらの組合せの助けを借りて実現される。いくつかの実施形態においては、本教示の特徴は、ここに教示される方策の１つ以上の機能を実行するように構成されたかまたはプログラムされたプロセッサを用いて実現される。プロセッサは、いくつかの実施形態においては、シングルプロセッサもしくはマルチチッププロセッサ、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、システム・オン・ア・チップ（system on a chip：ＳＯＣ）、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）、フィールドプログラマブルゲ
ートアレイ（field programmable gate array：ＦＰＧＡ）もしくは他のプログラマブル
ロジックデバイス、ステートマシン、離散的なゲートもしくはトランジスタ論理、離散的なハードウェアコンポーネント、または、本明細書に記載される機能を実行するように設計されたそれらのいずれかの組合せである。いくつかの実現例においては、本教示の特徴が、特定の機能に特化した回路類によって実現され得る。他の実現例においては、これらの特徴は、例えば、コンピュータ可読記憶媒体上に格納された命令を用いて特定の機能を実行するように構成されたプロセッサにおいて実現され得る。

【0415】

いくつかの実施形態においては、本教示の特徴は、処理システムおよび／またはネットワーキングシステムのハードウェアを制御するために、かつ、プロセッサおよび／またはネットワークがここに教示される方策の特徴を利用する他のシステムと対話することを可能にするために、ソフトウェアおよび／またはファームウェアに組込まれている。このようなソフトウェアまたはファームウェアは、アプリケーションコード、デバイスドライバ、オペレーティングシステム、仮想マシン、ハイパーバイザ、アプリケーションプログラミングインターフェイス、プログラミング言語、および実行環境／コンテナを含み得るがこれらに限定されない。適切なソフトウェアコーディングは、ソフトウェア技術に精通し
た当業者にとって明らかになるように、熟練したプログラマであれば本開示の教示に基づいて容易に準備することができる。

【0416】

いくつかの実施形態においては、本教示は、命令が格納された記憶媒体またはコンピュータ可読媒体であるコンピュータプログラムプロダクトを含む。これらの命令を用いて、ここに教示される方策の処理または機能のいずれかを実行するように、コンピュータなどのシステムをプログラムするか、または他の方法で構成することができる。記憶媒体またはコンピュータ可読媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および磁気光ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気または光カード、ナノシステム（分子メモリＩＣを含む）、ならびに、命令および／またはデータを格納するのに適した任意のタイプの媒体または装置、を含み得るが、これらには限定されない。特定の実施形態においては、記憶媒体は、非一時的な記憶媒体または非一時的なコンピュータ可読媒体である。いくつかの実施形態では、コンピュータ可読媒体は、送信信号または搬送波などの一時的な媒体を含む。そのような一時的な媒体は、単一のコンピュータシステムのコンポーネント間の送信の一部として生じてもよく、および／または複数のコンピュータシステム間の送信の一部として生じてもよい。

【0417】

上述の記載は、網羅的となるように意図されたものではなく、または、開示通りの形態に限定するように意図されたものではない。また、本教示の実施形態を特定の一連のトランザクションおよびステップを用いて説明したが、範囲が上述の一連のトランザクションおよびステップに限定されないことは、当業者にとって明らかであろう。さらに、本教示の実施形態をハードウェアとソフトウェアとの特定の組合せを用いて説明したが、ハードウェアとソフトウェアとの他の組合せが範囲内にあることも認識すべきである。さらに、さまざまな実施形態で本教示の特徴の特定の組合せを記載したが、一実施形態の特徴が別の実施形態に組込まれ得るというように、これらの特徴の異なる組合せが本開示の範囲内にあることは当業者にとって明らかであることを理解すべきである。さらに、特許請求される主題の精神および範囲から逸脱することなく、形態、詳細、実施および用途のさまざまな追加、削減、削除、変形および他の変更がなされ得ることも、当業者にとっては明らかであろう。より広い本発明の精神および範囲を添付の特許請求の範囲およびその均等物によって規定することを意図している。

【0418】

本開示の態様は、以下の番号付き条項で説明される：
１．高性能コンピューティング環境において異種および非対称なデュアルレール構成をサポートするためのシステムであって、
１つまたは複数のマイクロプロセッサを含むコンピュータと、
複数のホストとを備え、上記複数のホストの各々はデュアルポートアダプタを含み、上記システムはさらに、
プライベートファブリックを含む第１のレールを備え、上記プライベートファブリックは、２つ以上のラックに配置された複数のスイッチを含み、上記２つ以上のラックの各々は、上記複数のスイッチのセットを含み、上記システムはさらに、
パブリックファブリックを含む第２のレールを備え、上記パブリックファブリックはクラウドファブリックを含み、上記システムはさらに、
分散型作業負荷配置オーケストレータを備え、
上記複数のホストのうちのあるホストは、上記あるホストの上記デュアルポートアダプタの第１のポートを介して上記第１のレールに接続され、
上記複数のホストのうちの上記あるホストは、上記あるホストの上記デュアルポートアダプタの第２のポートを介して上記第２のレールに接続され、
上記複数のホストのうちの上記あるホストにおいて作業負荷がプロビジョニングされ、
配置ポリシーが、上記プロビジョニングされた作業負荷に割り当てられ、
上記分散型作業負荷配置オーケストレータは、上記プロビジョニングされた作業負荷に割り当てらた上記配置ポリシーを利用して、上記プロビジョニングされた作業負荷のネットワークトラフィックを、上記配置ポリシーに従って、上記プライベートファブリックを含む上記第１のレールおよび上記パブリックファブリックを含む上記第２のレールのうちの１つまたは複数に割り当てる、システム。

【0419】

２．条項１のシステムであって、
上記プライベートファブリックは２つ以上のレールを提供し、上記２つ以上のレールは、上記プライベートファブリック内で上記プロビジョニングされた作業負荷のために冗長接続性を提供する。

【0420】

３．条項２のシステムであって、
上記プロビジョニングされた作業負荷に割り当てられた上記配置ポリシーは、高優先順位の配置ポリシーである。

【0421】

４．条項３のシステムであって、
上記プロビジョニングされた作業負荷の上記ネットワークトラフィックは、上記プライベートファブリック内で厳密に割り当てられる。

【0422】

５．先行する条項のいずれか１つのシステムであって、
上記パブリックファブリックは２つ以上のレールを提供し、上記２つ以上のレールは、上記パブリックファブリック内で上記プロビジョニングされた作業負荷のために冗長接続性を提供する。

【0423】

６．条項５のシステムであって、
上記プロビジョニングされた作業負荷に割り当てられた上記配置ポリシーは、低優先順位の配置ポリシーである。

【0424】

７．条項６のシステムであって、
上記プロビジョニングされた作業負荷のネットワークトラフィックは、上記パブリックファブリック内および上記プライベートファブリック内に割り当てられる。

【0425】

８．高性能コンピューティング環境において冗長独立ネットワークをサポートするための方法であって、
１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、
複数のホストを提供することを含み、上記複数のホストの各々はデュアルポートアダプタを含み、上記方法はさらに、上記１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、
プライベートファブリックを含む第１のレールを提供することを含み、上記プライベートファブリックは、２つ以上のラックに配置された複数のスイッチを含み、上記２つ以上のラックの各々は、上記複数のスイッチのセットを含み、上記方法はさらに、上記１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、
パブリックファブリックを含む第２のレールを提供することを含み、上記パブリックファブリックはクラウドファブリックを含み、上記方法はさらに、上記１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、
分散型作業負荷配置オーケストレータを提供することを含み、上記方法はさらに、
上記複数のホストのうちのあるホストを、上記あるホストの上記デュアルポートアダプタの第１のポートを介して上記第１のレールに接続することと、
上記複数のホストのうちの上記あるホストを、上記あるホストの上記デュアルポートアダプタの第２のポートを介して上記第２のレールに接続することと、
上記複数のホストのうちの上記あるホストにおいて作業負荷をプロビジョニングすることと、
上記プロビジョニングされた作業負荷に配置ポリシーを割り当てることと、
上記プロビジョニングされた作業負荷に割り当てらた上記配置ポリシーに基づいて、上記分散型作業負荷配置オーケストレータが、上記プロビジョニングされた作業負荷のネットワークトラフィックを、上記配置ポリシーに従って、上記プライベートファブリックを含む上記第１のレールおよび上記パブリックファブリックを含む上記第２のレールのうちの１つまたは複数に割り当てることとを含む。

【0426】

９．条項８の方法であって、
上記プライベートファブリックは２つ以上のレールを提供し、上記２つ以上のレールは、上記プロビジョニングされた作業負荷のために冗長接続性を提供する。

【0427】

１０．条項９の方法であって、
上記プロビジョニングされた作業負荷に割り当てられた上記配置ポリシーは、高優先順位の配置ポリシーである。

【0428】

１１．条項１０の方法であって、
上記プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックは、上記プライベートファブリック内で厳密にプロビジョニングされる。

【0429】

１２．条項８～１１のいずれか１つの方法であって、
上記パブリックファブリックは２つ以上のレールを提供し、上記２つ以上のレールは、上記プロビジョニングされた作業負荷のために冗長接続性を提供する。

【0430】

１３．条項１２の方法であって、
上記プロビジョニングされた作業負荷に割り当てられた上記配置ポリシーは、低優先順位の配置ポリシーである。

【0431】

１４．条項１３の方法であって、
上記プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックは、上記パブリックファブリック内で割り当てられる。

【0432】

１５．高性能コンピューティング環境において異種および非対称なデュアルレール構成をサポートするための命令を担持するコンピュータ読取可能媒体であって、上記命令は、コンピュータによって読取られ実行されると、上記コンピュータにステップを実行させ、上記ステップは、
１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、
複数のホストを提供することを含み、上記複数のホストの各々はデュアルポートアダプタを含み、上記ステップはさらに、上記１つまたは複数のマイクロプロセッサを含む上記コンピュータにおいて、
プライベートファブリックを含む第１のレールを提供することを含み、上記プライベートファブリックは、２つ以上のラックに配置された複数のスイッチを含み、上記２つ以上のラックの各々は、上記複数のスイッチのセットを含み、上記ステップはさらに、上記１つまたは複数のマイクロプロセッサを含む上記コンピュータにおいて、
パブリックファブリックを含む第２のレールを提供することを含み、上記パブリックファブリックはクラウドファブリックを含み、上記ステップはさらに、上記１つまたは複数のマイクロプロセッサを含む上記コンピュータにおいて、
分散型作業負荷配置オーケストレータを提供することを含み、上記ステップはさらに、
上記複数のホストのうちのあるホストを、上記あるホストの上記デュアルポートアダプ
タの第１のポートを介して上記第１のレールに接続することと、
上記複数のホストのうちの上記あるホストを、上記あるホストの上記デュアルポートアダプタの第２のポートを介して上記第２のレールに接続することと、
上記複数のホストのうちの上記あるホストにおいて作業負荷をプロビジョニングすることと、
上記プロビジョニングされた作業負荷に配置ポリシーを割り当てることと、
上記プロビジョニングされた作業負荷に割り当てらた上記配置ポリシーに基づいて、上記分散型作業負荷配置オーケストレータが、上記プロビジョニングされた作業負荷のネットワークトラフィックを、上記配置ポリシーに従って、上記プライベートファブリックを含む上記第１のレールおよび上記パブリックファブリックを含む上記第２のレールのうちの１つまたは複数に割り当てることとを含む。

【0433】

１６．条項１５のコンピュータ読取可能媒体であって、
上記プライベートファブリックは２つ以上のレールを提供し、上記２つ以上のレールは、上記プロビジョニングされた作業負荷のために冗長接続性を提供する。

【0434】

１７．条項９のコンピュータ読取可能媒体であって、
上記プロビジョニングされた作業負荷に割り当てられた上記配置ポリシーは、高優先順位の配置ポリシーである。

【0435】

１８．条項１０のコンピュータ読取可能媒体であって、
上記プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックは、上記プライベートファブリック内で厳密にプロビジョニングされる。

【0436】

１９．条項１５～１８のいずれか１つのコンピュータ読取可能媒体であって、
上記パブリックファブリックは２つ以上のレールを提供し、上記２つ以上のレールは、上記プロビジョニングされた作業負荷のために冗長接続性を提供する。

【0437】

２０．条項１９のコンピュータ読取可能媒体であって、
上記プロビジョニングされた作業負荷に割り当てられた上記配置ポリシーは、低優先順位の配置ポリシーであり、
上記プロビジョニングされた作業負荷のピアノード間のネットワークトラフィックは、上記パブリックファブリック内で割り当てられる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【手続補正書】

【提出日】2024-05-21

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

高性能コンピューティング環境において冗長独立ネットワークをサポートするためのシステムであって、
１つまたは複数のマイクロプロセッサを含むコンピュータと、
前記コンピュータにおける複数のホストとを備え、
前記複数のホストのうちのあるホストは、第１のホストポートによってプライベートネットワークファブリックに接続され、前記あるホストはさらに、第２のホストポートを介してパブリッククラウドネットワークに接続され、前記プライベートネットワークファブリックおよび前記パブリッククラウドネットワークはリソースを共有せず、
前記複数のホストのうちのあるホストにおいて作業負荷がプロビジョニングされ、
前記作業負荷は、前記プライベートネットワークファブリックおよび前記パブリッククラウドネットワークのうちの１つに割り当てられる、システム。

【請求項2】

前記プライベートネットワークファブリックは、独立して、前記複数のホスト間に、完全な接続性を提供する、請求項１に記載のシステム。

【請求項3】

前記パブリッククラウドネットワークは、独立して、前記複数のホスト間に、完全な接続性を提供する、請求項２に記載のシステム。

【請求項4】

前記作業負荷の前記プライベートネットワークファブリックおよび前記パブリッククラウドネットワークのうちの１つへの前記割り当ては、前記作業負荷に関連付けられるサービスレベルアグリーメントに基づく、請求項３に記載のシステム。

【請求項5】

前記プライベートネットワークファブリックは、複数のスイッチを含む、請求項４に記載のシステム。

【請求項6】

前記作業負荷に関連付けられる前記サービスレベルアグリーメントに基づいて、前記複数のホスト間で前記作業負荷に関連付けられる通信が前記パブリッククラウドネットワーク内で生ずる、請求項５に記載のシステム。

【請求項7】

前記作業負荷に関連付けられる前記サービスレベルアグリーメントに基づいて、前記複数のホスト間で前記作業負荷に関連付けられる通信が前記プライベートネットワークファブリック内で生ずる、請求項５に記載のシステム。

【請求項8】

高性能コンピューティング環境において冗長独立ネットワークをサポートするための方法であって、
１つまたは複数のマイクロプロセッサを含むコンピュータにおいて、複数のホストを提供することを含み、
前記複数のホストのうちのあるホストは、第１のホストポートによってプライベートネットワークファブリックに接続され、前記あるホストはさらに、第２のホストポートを介してパブリッククラウドネットワークに接続され、前記プライベートネットワークファブリックおよび前記パブリッククラウドネットワークはリソースを共有せず、
前記複数のホストのうちのあるホストにおいて作業負荷がプロビジョニングされ、
前記作業負荷は、前記プライベートネットワークファブリックおよび前記パブリッククラウドネットワークのうちの１つに割り当てられる、方法。

【請求項9】

前記プライベートネットワークファブリックは、独立して、前記複数のホスト間に、完全な接続性を提供する、請求項８に記載の方法。

【請求項10】

前記パブリッククラウドネットワークは、独立して、前記複数のホスト間に、完全な接続性を提供する、請求項９に記載の方法。

【請求項11】

前記作業負荷の前記プライベートネットワークファブリックおよび前記パブリッククラウドネットワークのうちの１つへの前記割り当ては、前記作業負荷に関連付けられるサービスレベルアグリーメントに基づく、請求項１０に記載の方法。

【請求項12】

前記プライベートネットワークファブリックは、複数のスイッチを含む、請求項１１に記載の方法。

【請求項13】

前記作業負荷に関連付けられる前記サービスレベルアグリーメントに基づいて、前記複数のホスト間で前記作業負荷に関連付けられる通信が前記パブリッククラウドネットワーク内で生ずる、請求項１２に記載の方法。

【請求項14】

前記作業負荷に関連付けられる前記サービスレベルアグリーメントに基づいて、前記複数のホスト間で前記作業負荷に関連付けられる通信が前記プライベートネットワークファブリック内で生ずる、請求項１３に記載の方法。

【請求項15】

１つまたは複数のマイクロプロセッサによって実行されると、前記１つまたは複数のマイクロプロセッサに請求項８～１４のいずれか１項に記載の方法を実行させる、コンピュータプログラム。

【外国語明細書】