JP6541768B2 - 高性能コンピューティング（ｈｐｃ：ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ｃｏｍｐｕｔｉｎｇ）環境において効率的なロードバランシングをサポートするためのシステムおよび方法 - Google Patents

高性能コンピューティング（ｈｐｃ：ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ｃｏｍｐｕｔｉｎｇ）環境において効率的なロードバランシングをサポートするためのシステムおよび方法 Download PDF

Info

Publication number
JP6541768B2
JP6541768B2 JP2017501199A JP2017501199A JP6541768B2 JP 6541768 B2 JP6541768 B2 JP 6541768B2 JP 2017501199 A JP2017501199 A JP 2017501199A JP 2017501199 A JP2017501199 A JP 2017501199A JP 6541768 B2 JP6541768 B2 JP 6541768B2
Authority
JP
Japan
Prior art keywords
downlink
weight
port
accumulated
ports
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017501199A
Other languages
English (en)
Other versions
JP2017525279A (ja
JP2017525279A5 (ja
Inventor
ザヒド，フェロツ
グラン，アーンスト・ガンナー
ボグダンスキー，バルトシュ
ヨンセン，ビョルン・ダグ
Original Assignee
オラクル・インターナショナル・コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by オラクル・インターナショナル・コーポレイション filed Critical オラクル・インターナショナル・コーポレイション
Publication of JP2017525279A publication Critical patent/JP2017525279A/ja
Publication of JP2017525279A5 publication Critical patent/JP2017525279A5/ja
Application granted granted Critical
Publication of JP6541768B2 publication Critical patent/JP6541768B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/48—Routing tree calculation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

著作権表示
この特許文書の開示の一部は、著作権の保護下にある内容を含む。著作権所有者は、特許商標庁の特許ファイルまたはレコードに現れるので、誰でも当該特許文書または特許開示を複製することについて異議はないが、そうでなければ如何なる場合でもすべての著作権を留保する。
発明の分野
本発明は、一般にコンピュータシステムに関し、特にネットワーク環境に関する。
背景
ファットツリートポロジー（fat-tree topology）は、高性能コンピューティング（ＨＰＣ：high performance computing）クラスタと、インフィニバンド（ＩＢ：InfiniBand）（登録商標）技術に基づくクラスタとに使用される。たとえば、ファットツリートポロジーは、天河二号（Tianhe-2）のような最も速いスーパーコンピュータにおいて使用される。さらに、ファットツリーＩＢシステムは、Ｓｔａｍｐｅｄｅ、ＴＧＣＣ ＣｕｒｉｅおよびＳｕｐｅｒＭＵＣのような大きなインストレーションを含む。
これらは、本発明の実施形態が対応することを意図する一般的な領域である。
概要
ネットワーク環境においてツリートポロジーで配される複数のスイッチおよび複数のエンドノードの間で効率的なロードバランシングをサポートするためのシステムおよび方法が本願明細書において記載される。上記システムおよび方法は、ツリートポロジーにおいて１つ以上のリーフスイッチ上に存在する複数のエンドノードを分類し得、複数のエンドノードは受信重みの減少する順に分類される。上記システムおよび方法は、受信重みの減少する順に複数のエンドノードをルーティングし得、ルーティングすることは、少なくとも１つの下りポートおよび少なくとも１つの上りポートを選択することを含む。上記システムおよび方法は、ルーティングされたエンドノードの受信重みだけ、各選択された下りポート上の蓄積された下り重みを増加し得る。最後に、上記システムおよび方法は、ルーティングされたエンドノードの受信重みだけ、各選択された上りポート上の蓄積された上り重みを増加し得る。
実施形態において、本願明細書において記載されるシステムおよび方法は、複数のスイッチおよび複数のエンドノードが、高性能コンピューティング（ＨＰＣ）クラスタにおける使用のためのファットツリートポロジーにあることを可能にする。さらに、実施形態において、１つ以上のリーフスイッチ上の複数のエンドノードについての受信重みがシステムによって受信され得る。
実施形態において、少なくとも１つの下りポートの方法およびシステムによって実行される選択は、複数の下りポートを比較して、最も蓄積されていない下り重みを有する下りポートを選択することを含み得る。
実施形態において、上記方法およびシステムによって実行される、少なくとも１つの下りポートの選択は、複数の下りポートを比較して、最も蓄積されていない上り重みを有する下りポートを選択することを含む。
実施形態において、上記方法およびシステムによって実行される、少なくとも１つの下りポートの選択は、複数の下りポートを比較して、最も小さなグローバル一意識別子を有する下りポートを選択することを含む。
実施形態において、上記方法およびシステムによって実行される、少なくとも１つの下りポートの選択は、複数の下りポートを比較して、最も蓄積されていない下り重みを有する下りポートを選択することを含む。２つ以上の下りポートが最も蓄積されていない下り重みを有する場合、上記方法およびシステムはさらに、最も蓄積されていない下り重みを有する２つ以上の下りポートを比較して、最も蓄積されていない下り重みを有する２つ以上の下りポートから、最も蓄積されていない上り重みを有する下りポートを選択し得る。２つ以上の下りポートが最も蓄積されていない下り重みおよび最も蓄積されていない上り重みを有する場合、上記方法およびシステムは、最も蓄積されていない下り重みおよび最も蓄積されていない上り重みを有する２つ以上の下りポートを比較して、最も蓄積されていない下り重みおよび最も蓄積されていない上り重みを有する２つ以上の下りポートから、最も小さなグローバル一意識別子を有する下りポートを選択し得る。
本発明の実施形態が実施され得るネットワーク環境におけるファットツリールーティングのブロック図である。 本発明の実施形態が実施され得るネットワーク環境におけるファットツリールーティングのブロック図である。 本発明の実施形態が実施され得るネットワーク環境におけるファットツリールーティングのブロック図である。 本発明の実施形態に従った、ネットワーク環境内の例示的なポート選択を示すブロック図である。 本発明の実施形態に従った、ネットワーク環境内の例示的なポート選択を示すブロック図である。 本発明の実施形態に従った、ネットワーク環境内の例示的なポート選択を示すブロック図である。 本発明の実施形態に従った、ネットワーク環境内の例示的なポート選択を示すブロック図である。 本発明の実施形態に従った、ネットワーク環境内の例示的なポート選択を示すブロック図である。 本発明の実施形態に従った、ネットワーク環境内の例示的なポート選択を示すブロック図である。 本発明の実施形態に従った、ネットワーク環境におけるツリートポロジーにおいて配される複数のスイッチおよび複数のエンドノードの間の効率的なロードバランシングをサポートするための方法を示すフローチャートである。
詳細な説明
以下の詳細な説明では、本発明は、添付の図面において限定目的ではなく例示目的として示される。なお、この開示における「ある」、「１つ」または「いくつか」の実施形態への参照は、必ずしも同じ実施形態に対してなされるものではなく、このような参照は、少なくとも１つの実施形態を意味する。特定の実現例が論じられるが、当該特定の実現例は例示的な目的のみに提供されるということが理解される。当業者は、本発明の範囲および精神から逸脱することがなければ、他の構成要素および構成が使用されてもよいということを認識するであろう。
共通の参照番号は、図および詳細な説明の全体にわたって同様の要素を示すために使用される。したがって、図において使用される参照番号は、当該要素が別のところに記載される場合、そのような図に固有の詳細な説明において参照される場合もあり、または、参照されない場合もある。
本発明の以下の記載は、高性能ネットワークについての例として、インフィニバンド（ＩＢ）ネットワークを使用する。他のタイプの高性能ネットワークが限定なしで使用され得るということは、当業者には明らかであろう。以下の記載はさらに、ファブリックトポロジーについての例として、ファットツリートポロジーを使用する。他のタイプのファブリックトポロジーが限定なしで使用され得るということは、当業者には明らかであろう。
インフィニバンド
インフィニバンド（ＩＢ）は、インフィニバンドトレードアソシエーション（InfiniBand Trade Association）によって開発されたオープンで標準的なロスレスネットワーク技術である。当該技術は、特にＨＰＣアプリケーションおよびデータセンターに対して適応される、高スループットおよび低レイテンシーの通信を提供するシリアルポイントツーポイント全二重相互接続（serial point-to-point full-duplex interconnect）に基づく。
インフィニバンドアーキテクチャ（ＩＢＡ： InfiniBand Architecture）は、２レイヤートポロジー分割（two-layer topological division）をサポートする。低いレイヤーでは、ＩＢネットワークはサブネットと称される。サブネットは、スイッチおよびポイントツーポイントリンクを使用して相互接続されるホストのセットを含み得る。より高いレベルでは、ＩＢファブリックは、ルータを使用して相互接続され得る１つ以上のサブネットを構成する。
サブネット内では、ホストはスイッチおよびポイントツーポイントリンクを使用して接続される。さらに、サブネットにおける指定されたサブネットデバイス上に存在する１つのマスター管理エンティティ、すなわちサブネットマネージャ（ＳＭ： subnet manager）、が存在する。サブネットマネージャは、ＩＢサブネットを構成、アクティベート、および、維持することを担う。さらに、サブネットマネージャ（ＳＭ）は、ＩＢファブリックにおいてルーティングテーブル演算を実行することを担い得る。ここで、たとえば、ＩＢネットワークのルーティングは、ローカルサブネットにおけるすべての送信元および宛先ペアの間の適正なロードバランシングを目的とする。
サブネット管理インターフェイスを通じて、サブネットマネージャは、サブネット管理パケット（ＳＭＰ： subnet management packet）と称される制御パケットをサブネット管理エージェント（ＳＭＡ： subnet management agent）と交換する。サブネット管理エージェントは、各ＩＢサブネットデバイス上に存在する。ＳＭＰを使用することによって、サブネットマネージャは、ファブリックを発見し、エンドノードおよびスイッチを構成し、ＳＭＡから通知を受信することができる。
一般に、マスターサブネットマネージャを除く他のすべてのサブネットマネージャは、フォールトトレランスのためにスタンバイモードで動作する。しかしながら、マスターサブネットマネージャに障害が起きた状況においては、当該スタンバイサブネットマネージャによって、新しいマスターサブネットマネージャが取り決められる。マスターサブネットマネージャはさらに、サブネットの周期的な掃引を実行し、任意のトポロジーの変化を検出し、これにより、ネットワークを再構成する。
さらに、サブネット内のホストおよびスイッチは、ローカル識別子（ＬＩＤ： local identifier）を使用してアドレス指定され得、単一のサブネットは４９１５１個のＬＩＤに制限され得る。サブネット内に有効なローカルアドレスであるＬＩＤに加えて、各ＩＢデバイスは、その不揮発性メモリに書き込まれる６４ビットのグローバル一意識別子（ＧＵＩＤ： global unique identifier）を有し得る。ＧＵＩＤは、ＩＢレイヤー３（Ｌ３）アドレスであるグローバル識別子（ＧＩＤ）を形成するために使用され得る。ＧＩＤは、ＩＰｖ６のような１２８ビットのアドレスを形成するよう、６４ビットのＧＵＩＤを６４ビットのサブネット識別子（ＩＤ）に連結することにより作成され得る。たとえば、異なるポートＧＵＩＤが、ＩＢファブリックに接続されたポートに割り当てられ得る。
ＳＭは、ネットワーク初期化時において、ルーティングテーブル（すなわちツリー内のノードの各対間の接続／ルート）を計算し得る。さらに、トポロジーが変化するたびに、ルーティングテーブルは、最適な性能を保証するために更新され得る。通常動作の間、ＳＭは、トポロジー変化をチェックするためにネットワークの周期的な光掃引（light sweep）を実行し得る。変化が光掃引の間に発見された場合、または、ネットワーク変化を信号送信するメッセージ（トラップ）がＳＭによって受信された場合、ＳＭは、発見された変化に従ってネットワークを再構成し得る。
たとえば、ＳＭは、リンクがダウンする場合、デバイスが追加される場合、または、リンクが除去される場合といったようなネットワークトポロジーが変化する場合に、ネットワークを再構成し得る。再構成ステップは、ネットワーク初期化の間に実行されるステップを含み得る。さらに、再構成は、ネットワーク変化が発生したサブネットに制限されるローカルスコープを有し得る。さらに、ルータを有する大きなファブリックのセグメント化は、再構成スコープを制限し得る。
ファットツリールーティング
ファットツリートポロジーは、汎用ネットワークトポロジーのスケーラブルなクラスである。ファットツリートポロジーの背後にある初期のアイデアは、リーフスイッチに存在するエンドノードを有するスイッチの階層的マルチルートツリー構造（layered, multi-rooted tree structure）としてネットワークトポロジーを構成することであった。ファットツリーのルートに向かってより太く（fat）なるリンクの使用によって、完全な２分割帯域幅が維持され得、輻輳が潜在的に回避される。これにより、任意の利用可能な帯域幅を使用する利点がさらに提供され得る。
ファットツリートポロジーは、たとえばＨＰＣ環境内において、高性能相互接続をサポートのためにさまざまな利点を提供し得る。これらの利点は、無デッドロック性、固有のフォールトトレランス、および、完全な２分割帯域幅を含み得る。無デッドロック性は、ツリー構造の使用により、デッドロックの回避のための特別な考慮なしで、ファットツリーをルーティングすることが可能になることを表す。固有のフォールトトレランスは、個々の送信元宛先ペア間の複数のパスの存在によりネットワーク障害の効率的な取り扱いを可能にすることに起因する。完全な２分割帯域幅は、ネットワークが、ネットワークの２つの半分同士の間のフルスピードの通信を維持することを可能にする。
ファットツリールーティングアルゴリズムは、ネットワークファブリックにおいてリンクにわたる最短パスルートを均一に広げるリニアフォワーディングテーブル（ＬＦＴ： linear forwarding table）を生成することを目的とし得る。当該アルゴリズムは、インデキシング順にファブリックをトラバースし得、エンドノードのターゲットＬＩＤ、したがって対応するルート、を各スイッチポートに割り当て得る。
さらに、ファットツリールーティングアルゴリズムは、存在するファットツリートポロジーの効率的な使用をサポートするために使用され得る。以下のアルゴリズム１は、例示的なファットツリールーティングアルゴリズムである。
上に示されるように、ルーティング関数であるroute_to_cns()は、リーフスイッチのアレイにわたって反復し得る（１〜７行目）。各選択されたリーフスイッチについて、ルーティング関数は、たとえばポートナンバリングシーケンスにおいて選択されたリーフスイッチに接続される各エンドノードポートをルーティングし得る（２〜６行目）。
さらに、特定のＬＩＤに関連付けられるエンドノードポートをルーティングする場合、ルーティング関数は、下りパス（down-going path）をルーティングするよう、ネットワークトポロジーにおいて１レベル上り得、各スイッチポートをルーティングする場合、ルーティング関数は、上りパス（upgoing path）をルーティングするよう下り得る。このプロセスは、ルートスイッチレベルに到達するまで繰り返され得る。その後、すべてのノードに向かうパスは、ルーティングされ得、ファブリックにおけるすべてのスイッチのリニアフォワーディングテーブル（ＬＦＴ： linear forwarding table）に挿入され得る。
たとえば、route_downgoing_by_going_up()関数（５行目）は、パスをバランスするとともにroute_upgoing_by going_down()関数を呼び出し得る再帰関数であり得る。route_upgoing_by going_down()関数は、route_downgoing_by_going_up()関数が呼び出されたスイッチを通って宛先へ向かうファットツリーにおける上りパスをルーティングする。
route_to_cns()関数に関連付けられるいくつかの潜在的な障害が存在する場合がある。第１に、route_to_cns()関数は忘却型（oblivious）であり、どのエンドノードにエンドポートが属するのかについて如何なる考慮もなくエンドポートをルーティングする。第２に、route_to_cns()関数は、ルーティングのための物理的なポート番号に依存する。
図１は、本開示の実施形態が実施され得るネットワーク環境におけるファットツリールーティングの図を示す。図１に示されるように、１つ以上のエンドノード１０１〜１０４は、ネットワークファブリック１００において接続され得る。ネットワークファブリック１００は、複数のリーフスイッチ１１１〜１１４および複数のスパインスイッチ（spine switch）またはルートスイッチ１３１〜１３４を含むファットツリートポロジーに基づき得る。さらに、ネットワークファブリック１００は、スイッチ１２１〜１２４のような１つ以上の中間スイッチを含み得る。
さらに図１に示されるように、エンドノード１０１〜１０４の各々はマルチホームノード（multi-homed node）であり得る、すなわち、複数のポートを通じてネットワークファブリック１００の２つ以上の部分に接続される単一のノードであり得る。たとえば、ノード１０１はポートＨ１およびＨ２を含み得、ノード１０２はポートＨ３およびＨ４を含み得、ノード１０３はポートＨ５およびＨ６を含み得、ノード１０４はポートＨ７およびＨ８を含み得る。
さらに、各スイッチは複数のスイッチポートを有し得る。たとえば、ルートスイッチ１３１はスイッチポート１〜２を有し得、ルートスイッチ１３２はスイッチポート３〜４を有し得、ルートスイッチ１３３はスイッチポート５〜６を有し得、ルートスイッチ１３４はスイッチポート７〜８を有し得る。
図２は、本開示の実施形態が実施され得るネットワーク環境２００におけるファットツリールーティングの図を示す。図２は、ｋｎ個のエンドノードと、各々２ｋ個のポートを有するｎ×ｋｎ−１個のスイッチとを有するｎレベルのファットツリーであるｋ−ａｒｙ−ｎツリーを示す。より具体的には、図２は、４−ａｒｙ−２ツリーを示しており、すなわち、ファットツリートポロジーは、２つのレベルと、１６個のエンドノード（２０１〜２１６）と、８個のスイッチ（４個のリーフスイッチ２２０〜２２３および４個のルートスイッチ２２５〜２２８）とを有し、各スイッチは８つのポートを有する。
レガシーファットツリールーティングアルゴリズム（本願明細書においてさまざまな態様でＦＴｒｅｅと称される）は、ネットワークファブリックにおいてリンクにわたる最短パスルートを均一に広げるＬＦＴを生成することを目的とする。当該アルゴリズムは一般に、インデキシング順にファブリックをトラバースし、エンドノードのターゲットＬＩＤ、したがって対応するルート、を各スイッチポートに割り当てる。同じリーフスイッチに接続されたエンドノードについて、インデキシング順は、エンドノードが接続されるスイッチポートに依存する（ポートナンバリングシーケンス）。各ポートについて、アルゴリズムは、ポート使用カウンタを維持し得るとともに、（１つを超えるオプションが利用可能な場合）ルートが追加されるごとに、ポート使用カウンタを用いて、最も用いられていないポートを選択する。同じ２つのスイッチを接続する複数のポートが存在する場合、そのようなポートはポート群を形成する。その場合、最もロードが少ないポート群のうち最も用いられていないポートが、新しいルートに追加するよう選択される。
一般に、ＬＩＤへのポートの割り当ては、リーフスイッチからスタートして、２つのステージで再帰的に実行される。第１のステージにおいて、アルゴリズムは各エンドノードから下方にトラバースし、ツリールートへと上方に向かい、ＬＩＤに下りポートを割り当てる。下りポートがセットされた後、アルゴリズムは、ツリーを下ることによって、すべての接続された下りスイッチ上のＬＩＤに上りポートを割り当てる。次いで、プロセスは、ツリーの次のレベルに上るように移動することにより再帰的に繰り返される。
ファットツリートポロジーについてのレガシールーティングメカニズム（すなわちＦＴｒｅｅアルゴリズム）に関連付けられる２つの欠点が存在する。
第１に、ファットツリートポロジーについて標準的なアルゴリズムによって使用されるロードバランシング技術は、ノードのトラフィック特性のいずれも考慮することなく、トポロジーにおけるリンクにわたってロードをバランシングしようと試みる。換言すると、レガシーファットツリーアルゴリズムは、ネットワークにおけるすべてのノードについて同じ重みを想定する。しかしながら、ＨＰＣクラスタにおいて、異なるノードが、自身のトラフィックプロファイルを決定する事前に割り当てられた役割をしばしば有する。たとえば、ストレージノードまたはＩ／Ｏゲートウェイは、他のノードより多くのトラフィックを消費しやすい。したがって、これらの高トラフィックノードに向かうルートは、より混雑しやすく、当該ネットワークにおいて優先順位を必要とする。あるノードのトラフィックのニーズを考慮に入れずにルーティングがなされると、いくつかのリンクが超過する（oversubscribed）一方、他のリンクが十分に利用されないため、ネットワークスループットが準最適になり得る。
第２に、ファットツリートポロジーについてのレガシーアルゴリズムは、性能が予測不可能になり得るので、望ましくない。この予測不可能な性能は、アルゴリズムがインデキシング順に従ってリンクにルートを割り当てるため、生じる。しかしながら、インデキシング順は、構成可能ではなく、エンドノードが接続されるリーフスイッチのポート番号に依存する。このため、同じ態様で接続されたファットツリーシステムが、異なった予測不可能な性能を示し得る。例として、２レベルのファットツリーにおいて、異なるリーフスイッチにおける２つのエンドノードが同じインデックス位置を共有する場合、それらの２つのノードに向かうトラフィックは同じルートスイッチを通ってルーティングされる。結果として、これらの２つのノードに向かうが他のリーフスイッチにおけるエンドノードから生じるすべてのトラフィックは、代替的なルートスイッチを通るいくつかにより少ないロードのパスが存在し得ても、単一のルートスイッチに接続された上りリンクの共通セットに対するアクセスについて競合することになる。
レガシーファットツリールーティングアルゴリズムに関する問題をよりよく示すためには、図２における例のルーティングを考慮することが有用である。図２において、ノード２０１、２０６、２１０および２１３は、４つの受信ノード、すなわち合計のネットワークトラフィックの大きな部分を受信するのが分かっているノード、を表わすためにシェードがつけられている。４つのリーフスイッチ２２０〜２２３の各々は、４つのルートスイッチ２２５〜２２８に接続される。ノードは左から右にインデキシング順にある（すなわち、ノード２０１のインデキシング順は１であり、ノード２０６のインデキシング順は２であり、ノード２１０のインデキシング順は２であり、ノード２１３のインデキシング順は１である）と仮定すると、これは、ノード２０６および２１３は同じインデキシング順（すなわち１）を共有し、ノード２０６および２１０は同様に同じインデキシング順（すなわち２）を共有するということを意味する。この結果、ファットツリールーティングアルゴリズムは、２個の最も左側のルートスイッチ２２５および２２６のみを使用して、これらの４つのエンドノードに向かうトラフィックをルーティングする。これにより、図２において破線によって示される上り方向において、４つのリンクが潜在的に超過となる。破線は、受信ノードａおよびｂに向かう上りフローが、リンク上にて帯域幅が競合することになるということを示すために、図２において「上り｛ａ，ｂ｝」とラベル付けされる。
例として、受信ノード２０１および２１３に向かうトラフィックフロー同士間の干渉を回避するためにトポロジーにおいて利用可能な十分なリンクが存在しても、レガシーファットツリーアルゴリズムはそれでも、ノード２０６および２１０への当該２つの独立したフローに、最も左側のリーフスイッチ２２０からの同じ上りリンクを共有させる。
ｋ−ａｒｙ−ｎツリーについてのインデックス衝突確率
上で論じたように、ネットワークにおいて、システム内の大部分のトラフィックを占めるノードである受信ノードがそれぞれのリーフスイッチにおいてインデックス位置を共有すると、ＦＴｒｅｅの性能は低下し得る。たとえば図２において、受信ノード２０１および受信ノード２１３はインデックス位置１を共有し、受信ノード２０６および受信ノード２１０はインデックス位置２を共有する。このため、ロードバランシングに関してＦＴｒｅｅの実行可能性を評価するために、（受信ノードが異なるリーフスイッチにおいて同じインデックス位置を共有する場合の）そのようなインデックス衝突の確率を決定することは重要である。
ｋ−ａｒｙ−ｎ−ツリーがｋｎ個のエンドノードと、各々が２ｋ個のポートを有するｎ×ｋｎ−１個のスイッチとを有するｎレベルのツリーであることを思い起こす。エンドノードで完全にポピュレートされた（populated）ツリーと、レベルｌ＝ｎとを仮定すると、以下のとおりである。
・各エンドノードはｎタプル｛０，１，…，ｋ−１｝ｎによって表され、各スイッチは順序ペア＜ｓ，ｌ＞で表される。ここで、
でありレベル
である。
・リーフスイッチは、＜ｌ０，ｌ１，…．，ｌｎ−２，ｎ−１＞であるレベルｎ−１のスイッチとして定義され、レベルｎでのエンドノードｃ０，ｃ１，…，ｃｎ−１に対するエッジを有する。
各リーフスイッチにおいてｋ個のエンドノードのうち、ネットワークにおいてより高い割合のトラフィック受信を各々が有するｙ個のノード（たとえば受信ノード）が存在する状況において、リーフスイッチにおける任意のインデックス位置ｉにおいて受信ノードが発見される確率は、
によって与えられる。
ファットツリーがＮ＝ｋｎ−１個のリーフスイッチを有するので、受信ノードがそれらの対応するスイッチにおいて同じインデックス位置を共有する確率を求めるために２項分布が使用され得る。任意のインデックス位置ｉにおいてちょうどｒ個の受信ノードを求める確率は、ｐｉという確率とともに、
によって与えられる。
位置ｉにおいて少なくともｘ個のインデックス衝突を得る確率を計算するために、ここで以下のように示されるように、すべての対応する確率の合計が取られる。
なお、各リーフスイッチにおいてＲ個の接続されたエンドノードを有するファットツリーについて、Ｒ個の位置のうちのいずれかにおけるインデックス衝突、すなわち
によりネットワーク競合が増加し得る。
加重ファットツリールーティングアルゴリズム
本開示の実施形態に従うと、上記のＦＴｒｅｅの欠陥を克服するために、加重ファットツリールーティングアルゴリズム（weighted fat-tree routing algorithm）（さまざまな態様で全体においてｗＦａｔＴｒｅｅと称される）が使用される。ｗＦａｔＴｒｅｅ内において、各エンドノードは新しいパラメータであるreceive_weightが割り当てられ、当該receive_weightは、システム内におけるルートを計算する際に分かっているトラフィック特性または学習されたトラフィック特性を考慮するよう用いられ得る。
実施形態において、各エンドノードについてのreceive_weightパラメータの値は、ルーティングテーブルを計算する際に、受信ノードへのフローの優先度を反映する。例として、範囲［１，１００］において、構成がエンドノードに重みを割り当て得る。各ノードは、ノードがネットワークにおいてどれだけ多くのトラフィックを受信するのかが分かっているかに依存して、重みを受信する。この例において、エンドノードには、１のreceive_weightが割り当てられ得る。これは、トラフィックをほとんど受信しないノード（トラフィック生成ノード）を表わす。さらに、リンクキャパシティの近傍におけるトラフィックを受信するエンドノードは、１００のreceive_weightが割り当てられ得る。そのような状況において、１と１００との間のreceive_weightの値は、ノードがネットワークにおいて受信するトラフィックの割合を表わす。
別の実施形態において、ノードは、５００のreceive_weightを受信し得、ネットワークにおける他のすべてのノードには１のreceive_weightが与えられる。これは、５００のreceive_weightを有するエンドノードは臨界ノードであるということと、臨界ノードに向かって流れるトラフィックが優先されるべきであるということを示す。
実施形態において、ｗＦａｔＴｒｅｅルーティングアルゴリズム（以下にアルゴリズム２において示される）は、３段階で再帰的に動作する。この実施形態において、すべてのルートが後方向に計算される。すなわち、宛先ノードからスタートし、逆方向に作用する。以下のアルゴリズム２は、例示的なｗＦａｔＴｒｅｅルーティングアルゴリズムである。
実施形態において、例示的なアルゴリズム２の第１の段階の間、各リーフスイッチにおけるエンドノードは、減少するreceive_weightsに従って分類される（３行目）（なお、アルゴリズム２において、receive_weightは「rcv_weight」と略記されている）。上述したように、receive_weightsは、アドミニストレータによって供給されるか、または、計算され得る。このトピックのさらに別の議論は以下に与えられる。
実施形態において、例示的なアルゴリズム２の第２の段階の間に、ｗＦａｔＴｒｅｅは、各エンドノード（たとえば宛先ノードまたはルートの宛先）から上方にツリーをトラバースし、次のレベルにおいて、選択されたスイッチにおける現在ノードに下りポートを割り当てる（ROUTEDOWGOINGBYASC；例示的なアルゴリズム２の６行目）。下りポートが選択されると、アルゴリズムは、対応するポートについて蓄積された下り重みを、ルーティングされたエンドノードのreceive_weightだけ増加する（１４行目）。これは、新しい加重ルートが対応するポートに追加されたことを示す。
実施形態において、下りポートがセットされた後、例示的なアルゴリズム２の第３の段階において、アルゴリズムは、ツリーを下降する（ROUTEUPGOIGNBYDESC）ことによって、すべての接続された下りスイッチ上のエンドノードに向かうルートについて上りポートを割り当てる（とともに、ルーティングされたエンドノードのreceive_weightを追加することによってポートについて対応する上り重みを更新する）。次いで、当該３段階のプロセス全体は、ツリーにおいて次のレベルに上るように移動することにより繰り返される（１６行目）。
実施形態において、ｗＦａｔＴｒｅｅアルゴリズムであるアルゴリズムが、各ルート計算について最もロードが少ないポートを選択する。選択基準は、まず下り重みに基づく。２つのポートが等しい下り重みを有する状況において、最も小さい上り重みを有するポートが選択される。さらに、下りおよび上り重みの両方が等しい状況において、アルゴリズムは、プロセスを決定的に保つために、最も小さいＧＵＩＤを有するポートを選択する。以下の例示的なアルゴリズム３は、ｗＦａｔＴｒｅｅが各ルート計算について最もロードが少ないポートをどのように選択するかを示す。
実施形態において、ｗＦａｔＴｒｅｅは、いくつかの態様でレガシーＦＴｒｅｅルーティングアルゴリズムを改善する。第１に、リーフスイッチにおける各ノードがインデキシングされるネットワークにおけるノードのインデキシングに上述したように基づくＦＴｒｅｅと異なり、ｗＦａｔＴｒｅｅは受信重みが減少する順にノードをルーティングする。これは、たとえば受信ノード（たとえばシステム内のトラフィックの大部分を有するノード）であるノードが最初にルーティングされることを可能にする。さらに、スイッチにおける下りポートがエンドノードに割り当てられる状況において、ｗＦａｔＴｒｅｅは、当該ノードに関連付けられる他のローカルリンク上の上り重みを更新する。これは、上りリンクが潜在的にそのノードに向かってトラフィックを搬送するので、上り重みがリンクを選択する場合に考慮されることを可能にする。最後に、最も使用されていない下りポートが選択されている状況において、下り重みをチェックした後、ｗＦａｔＴｒｅｅは、さらに最も競合しなかったポートを選択するために割り当てられる上り重みをチェックする。これは、下り方向においてルーティングされるリンクの数をチェックするのみであるレガシーＦＴｒｅｅに対して、ロードバランシングの向上という利点を提供する。下りリンクの数が同じであるということが分かると、レガシーＦＴｒｅｅは、ルーティングを決定するようインデキシング順に戻る。
ここで図３を参照して、図３は、本開示の実施形態が実施され得るネットワーク環境におけるファットツリールーティングを示す。ネットワーク環境３００は、ｋｎ個のエンドノードと、各々２ｋ個のポートを有するｎ×ｋｎ−１個のスイッチとを有するｎレベルのファットツリーであるｋ−ａｒｙ−ｎツリーとして示される。図２と同様に、強調表示されたノード３０１、３０６、３１０および３１３はたとえば合計のネットワークトラフィックの大部分を搬送するので、これらのノードは受信ノードとして指定される。図３に示される実施形態において、ｗＦａｔＴｒｅｅルーティングアルゴリズムが使用される。ｗＦａｔＴｒｅｅルーティングアルゴリズムの結果、ネットワーク環境は、ルートを計算する際に、各ノードのreceive_weightを考慮する。
実施形態において、図３に示されるように、受信ノード３０１へと流れる上りトラフィック、すなわち、塗りつぶされた矢印が示す方向を有する破線によって表わされている上りトラフィックは、完全にルートスイッチ３２５を通る。次いで、塗りつぶされた矢印を有する実線によって表わされる、受信ノード３０１への下りルートは、ルートスイッチ３２５からリーフスイッチ３２０を通って流れる。同様に、受信ノード３１３に向かう上りトラフィック、すなわち、空の矢印が示す方向を有する破線によって表わされている上りトラフィックは、リーフスイッチ３２３へと下方にルーティングされる前に、完全にルートスイッチ３２８を通過する。実施形態において、受信ノード３０６および３１０に流れるトラフィックについて、同様のトラフィックパターンが存在する。
図３において使用されたｗＦａｔＴｒｅｅルーティングアルゴリズムは、ネットワーク環境３００内の利用可能なリンク上に向上した分散を示す。これは、レガシーＦＴｒｅｅを使用するネットワークに対して、ネットワークにおける性能の向上を可能にする。
実施形態において、スイッチにおける下りポートが、あるエンドノードに向かうルートについて選択されると、エンドノードに向かう、スイッチへのすべての入力トラフィックが、選択されたポートを通ってルーティングされる。特に、すべてのリンクが全二重である場合、スイッチに接続されたすべての他の上りリンクが、上り方向において、当該エンドノードに向かうトラフィックを潜在的に搬送している。選択されたポートの下り重みをセットした後、ｗＦａｔＴｒｅｅは、すべての利用可能な上りリンクを、ルーティングされたノードのreceive_weightでマークする。同じ下りロードを有する複数の下りポートが利用可能な状況において、ルートについて次の下り部分を選択すると、最も小さい上り重みを有するポートが選択される。下り重みおよび上り重みの両方に選択を基づかせることによって、ネットワークにおけるリンクがエンドノードのreceive_weightsに従ってバランシングされることが保証される。
図４は、実施形態に従ったネットワーク環境内の例示的なポート選択を示す。図４に示されるネットワーク環境は、リーフスイッチ４２０および４２１と、ルートスイッチ４２５および４２６と、エンドノード４０１および４０２とを含む。図４〜図９の議論の全体にわたって、当該ネットワーク環境はｗＦａｔＴｒｅｅアルゴリズムを利用しているということと、エンドノード４０１およびエンドノード４０２の両方が、それらのそれぞれのリーフスイッチにおいて同じインデキシング位置と、同じ１００の受信重み（すなわち、エンドノード４０１およびエンドノード４０２の両方についてreceive_weight=100）とを有するということとが想定される。
図５は、実施形態に従ったネットワーク環境内の例示的なポート選択を示す。図５に示されたネットワーク環境は、リーフスイッチ４２０および４２１と、ルートスイッチ４２５および４２６と、エンドノード４０１および４０２とを含む。図５は、エンドノード４０１に向かうルートを計算する際に、同じ下り重みを有するリンク４５０および４５１である２つの上流ポートが、２つの異なるルートスイッチ４２５および４２６上で利用可能であるということを示す。示された実施形態において、示される上り方向に重みはまだなく、さらに、下り方向に重みはまだない。したがって、リンク４５０上の重みは、上り＝０，下り＝０である。同様に、リンク４５１上の重みは、上り＝０，下り＝０である。
図６は、実施形態に従ったネットワーク環境内の例示的なポート選択を示す。図６に示されるネットワーク環境は、リーフスイッチ４２０および４２１と、ルートスイッチ４２５および４２６と、エンドノード４０１および４０２とを含む。図６に示されるように、下り方向または上り方向に重みがまだ存在しなかったので、最も左側のルートスイッチ上のポート４２５が、より小さなＧＵＩＤを搬送する際に、選択される。このため、リンク４５０はこのように、下り方向にエンドノード４０１のreceive_weightを搬送する。したがって、リンク４５０上の重みは、上り＝０，下り＝１００である。さらに、リンク４５２は、上り方向にエンドノード４０１のreceive_weightを搬送する。したがって、リンク４５２上の重みは、上り＝１００，下り＝０である。
図７は、実施形態に従ったネットワーク環境内における例示的なポート選択を示す。図７に示されるネットワーク環境は、リーフスイッチ４２０および４２１と、ルートスイッチ４２５および４２６と、エンドノード４０１および４０２とを含む。図５と同様である図７に示されるように、エンドノード４０２へのルートが計算されている。図５に示されるように、同じ下り重みを有する２つの上流ポートが存在する。両方のリンク４５２および４５３は、等しい下り重み、すなわち０、を有する。しかしながら、リンク４５２は１００の上り重みを有し、リンク４５３は０の上り重みを有する。これは、４５３の上り重みは４５２の上り重みより小さいということを意味する。上で論じたように、２つのリンクが同じ下り重みを有する場合、１つのリンクが別のリンクより大きな上向方重みを有していれば、アルゴリズムは、下方にルーティングするために、より小さな上り重みを有するポートを選択する。
図８は、実施形態に従ったネットワーク環境内の例示的なポート選択を示す。図８に示されるネットワーク環境は、リーフスイッチ４２０および４２１と、ルートスイッチ４２５および４２６と、エンドノード４０１および４０２とを含む。図８に示されるように、リンク４５２（図７参照）上の上り重みがリンク４５３上の上り重みより大きかったので、リンク４５３がノード４０２へと下方に搬送するために選択される。結果として、リンク４５３はこのように、下り方向にエンドノード４０２のreceive_weightを搬送する。したがって、リンク４５３上の重みは、上り＝０，下り＝１００である。さらに、上で論じたように、リンク４５１は、上り方向にエンドノード４０２のreceive_weightを搬送する。したがって、リンク４５１上の重みは、上り＝１００，下り＝０である。
図９は、実施形態に従ったネットワーク環境内の例示的なポート選択を示す。図９に示されるネットワーク環境は、リーフスイッチ４２０および４２１と、ルートスイッチ４２５および４２６と、エンドノード４０１および４０２とを含む。図９は、すべてのリンク重みが更新された後の最終ルーティングを示す。なお、特に、２つの受信ノードがそれぞれのリーフスイッチにおいて同じインデキシング位置を共有していても、エンドノード４０１および４０２へのルートは、トポロジーにおける利用可能なリンクを利用して良好にバランシングされる。
図１０は、フローチャートを介して、ネットワーク環境におけるツリートポロジーにおいて配される複数のスイッチおよび複数のエンドノードの間の効率的なロードバランシングをサポートするための例示的な方法１０００を示す。ステップ１００１では、例示的な方法１０００は、複数のエンドノードの分類から始まる。当該複数のエンドノードは、複数のスイッチの１つ以上の上に存在し、複数のエンドノードは、受信重みの減少する順に分類される。実施形態において、エンドノードの受信重みは１と１００との間の値または別の好適な範囲の値であり得る。より大きな値の受信重みは、より小さな受信重みを有するノードに対して、ネットワークにおけるトラフィックの割合的により大きなシェアを有するそれぞれのノードを示す。
ステップ１００２では、例示的な方法１０００は、受信重みの減少する順で複数のエンドノードをルーティングすることを継続する。ルーティングは、少なくとも１つの下りポートおよび少なくとも１つの上りポートを選択することを含む。減少する順にルーティングすることによって、ネットワークが、より高ボリュームのトラフィックを受信するエンドノードへのトラフィックを優先するとともにポート衝突の可能性を減少させることが可能になる。いくつかの実施形態において、当該選択は、それぞれの受信重みに基づく。
ステップ１００３では、例示的な方法１０００は、ルーティングされたエンドノードの受信重みによって、各選択された下りポート上の蓄積された下り重みを増加させることに進み得る。
ステップ１００４では、例示的な方法１０００は、ルーティングされたエンドノードの受信重みによって、各選択された上りポート上の蓄積された上り重みを増加させることに進み得る。
receive_weightsの計算
実施形態において、ノードに関する管理情報が利用可能でない場合、より特定的には、ノードのreceive_weightsが供給されないまたはそうでなければ利用可能ではない場合、receive_weightsが計算され得る。ＯＦＥＤ（OpenFabrics Enterprise Distribution）を利用する実施形態において、ibdatacountsと称されるユーティリティがデータカウンタを読み出すために提供される。ネットワークをセットアップし、各ノードに等しいreceive_weightsを与えた後、新しい重みが所定の時間期間の後に計算または学習され得る。
実施形態において、Ｂが、ある時間期間にわたって測定されたすべてのノードについての受信帯域幅のセットである場合、各ノードについての重みは、以下の例示的な方程式において与えられるように、線形変換を使用することによって、範囲［ａ，ｂ］に割り当てられ得る。
実施形態において、ひとたび重みの新しいセットがデータカウンタから取得されると、ネットワークは、最適化されたルーティングテーブルにより再構成され得る。しかしながら、実施形態において、最適化されるべきルーティングテーブルを再構成する利点と、それに対するそのような再構成が必要とするダウンタイムとをバランシングするバランシングテストが実行され得る。実施形態におけるルーティングテーブルの再構成は、トポロジー変化のような外部ファクタによって再構成が引き起こされるような時間まで、延期され得る。
一実施形態において、ミドルウェアマシン環境におけるツリートポロジーで配される複数のスイッチおよび複数のエンドノードの間で効率的なロードバランシングをサポートするためのシステムを提供され得る。上記システムは、複数のスイッチおよび複数のエンドノードと通信するサブネット管理インターフェイスと、サブネット管理インターフェイスに結合されるとともに、複数のエンドノードを分類するように構成されるサブネットマネージャとを含み、複数のエンドノードは複数のスイッチのうちの１つ以上の上に存在し、複数のエンドノードは受信重みの減少する順に分類され、複数のエンドノードは受信重みの減少する順にルーティング（rout）され、上記ルーティングは、少なくとも１つの下りポートおよび少なくとも１つの上りポートを選択することを含み、ルーティングされたエンドノードの受信重みだけ、各選択された下りポート上の蓄積された下り重みを増加し、ルーティングされたエンドノードの受信重みだけ、各選択された上りポート上の蓄積された上り重みを増加する。
サブネットマネージャは、サブネット管理インターフェイスと組み合わせて、上記のいずれかのファットツリールーティングアルゴリズムまたはファットツリールーティングアルゴリズムのステップの１つ以上を実現し得るということが当業者には明白である。上記のサブネット管理インターフェイスおよびサブネットマネージャのようなユニット／モジュールの特定の動作プロセスについて、同じ概念を共有する関連する方法の実施形態において、対応するステップに参照がなされ得、当該参照はさらに、関連するユニット／モジュールの開示と見なされるということが当業者には明白である。したがって、特定の動作プロセスのうちのいくつかは、説明の便宜上および簡潔性のために、繰り返しまたは詳細に記載されない。サブネット管理インターフェイス、サブネットマネージャおよび／またはシステムのようなユニット、装置およびデバイスは、公知または将来開発されるソフトウェア、ハードウェア、ならびに／または、そのようなソフトウェアおよびハードウェアの組み合わせの形態で実現され得るということが理解されるべきである。
一実施形態において、複数のスイッチおよび複数のエンドノードは、高性能コンピューティング（ＨＰＣ）クラスタで使用されるファットツリートポロジーに構成される。
一実施形態において、サブネットマネージャはさらに、ネットワークにおける１つ以上のリーフスイッチ上の複数のエンドノードの各々のために、受信重みを受信するように構成され得る。
一実施形態において、少なくとも１つの下りポートを選択することは、複数の下りポートを比較して、最も蓄積されていない下り重みを有する下りポートを選択することを含む。
一実施形態において、少なくとも１つの下りポートを選択することは、複数の下りポートを比較して、最も蓄積されていない上り重みを有する下りポートを選択することを含む。
一実施形態において、少なくとも１つの下りポートを選択することは、複数の下りポートを比較して、最も小さなグローバル一意識別子を有する下りポートを選択することとを含む。
上記ステップのうちの少なくともいくつかは、ＤＳＰ、ＦＰＧＡ、ＡＳＩＣなどを含むがこれらに限定されないさまざまなハードウェアによっても実現され得るということは、当業者にとって明白である。たとえば、上記実施形態のうちのいくつかにおける「オペレーション」は、ＣＰＵにおいて実行される命令によって、または、「オペレーション」の機能を実現するＤＳＰ、ＦＰＧＡ、ＡＳＩＣのような特別のプロセッサによって、実現され得る。
当業者が理解するように、ブロック図によって表わされる関数は、ソフトウェアおよび／またはハードウェアによって実行され得る。さまざまな関数は、イベントドリブン、インタラプトドリブンなどといった特定の処理ストラテジーに依存して、図において示された以外の順番またはシーケンスで順に実行される。同様に、明示的に示されていないが、１つ以上のステップまたは関数は繰り返し実行されてもよい。同様に、さまざまな関数は、特定の実現例に依存して省略され得る。当業者に公知のさまざまな関数は、明示的に説明または記載されていない場合があるが、示されたブロックまたはモジュールによって暗示される。一実施形態において、示された関数は、システムの動作を制御するために、コンピュータ読取可能記憶媒体に格納されたソフトウェア、命令またはコードによって実現されるとともにマイクロプロセッサベースのコントローラによって実行される制御ロジックによって主に実行される。磁気テープドライブに関して一般に説明および記載されたが、当業者は、さまざまな関数はさまざまな他のタイプの周辺記憶デバイスに適用可能であり得るということを認識するであろう。
本発明は、１つ以上のプロセッサ、メモリ、および／または本開示の教示に従ってプログラムされたコンピュータ読取可能な記録媒体を含む１つ以上の従来の汎用または専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを用いて簡便に実施され得る。ソフトウェア技術の当業者には明らかであるように、適切なソフトウェアコーディングは、熟練したプログラマによって本開示の教示に基づき容易に用意され得る。
いくつかの実施形態では、本発明は、本発明の処理のいずれかを実行するようコンピュータをプログラムするのに用いられ得る命令を格納した一時的でない記憶媒体またはコンピュータ読取可能媒体であるコンピュータプログラムプロダクトを含む。当該記憶媒体は、フロッピーディスク（登録商標）、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ素子、磁気または光学カード、ナノシステム（分子メモリＩＣを含む）、または命令および／またはデータを格納するのに好適な任意のタイプの媒体もしくは装置を含み得るが、これらに限定されない。
本発明の上記の記載は、例示および説明目的で与えられている。網羅的であることまたは開示されたそのものの形態に本発明を限定することを意図したものではない。当業者にとっては、多くの修正例および変形例が明確であろう。上記の実施形態は、本発明の原理およびその実際的な適用を最もよく説明するために選択および記載されたものであり、これにより他の当業者が、特定の使用に好適なさまざまな修正例を考慮して、さまざまな実施形態について本発明を理解するのが可能になる。本発明の範囲は、添付の特許請求の範囲およびそれらの均等物によって定義されることが意図される。

Claims (15)

  1. ネットワーク環境において、複数のレベルを含むツリートポロジーで配される複数のスイッチおよび複数のエンドノードの間で効率的なロードバランシングをサポートするための方法であって、
    前記複数のスイッチのうちの１つ以上の上に存在する前記複数のエンドノードを分類することを含み、前記複数のエンドノードは受信重みの減少する順に分類され、前記方法はさらに、
    前記受信重みの減少する順に前記複数のエンドノードをルーティングすることを含み、前記複数のエンドノードのうちの対象エンドノードに対して前記ルーティングすることは、前記対象エンドノードに向かうルートについて少なくとも１つの下りポートおよび少なくとも１つの上りポートを選択することを含み、前記下りポートは、前記複数のレベルのうちの１つのレベルのスイッチから前記複数のレベルのうちの１レベルだけ下のレベルのスイッチへの下り方向のポートであり、前記上りポートは、前記複数のレベルのうちの１つのレベルのスイッチから前記複数のレベルのうちの１レベルだけ上のレベルのスイッチへの上り方向のポートであり、前記方法はさらに、
    前記対象エンドノードの受信重みだけ、各選択された下りポート上の蓄積された下り重みを増加することと、
    前記対象エンドノードの受信重みだけ、各選択された上りポート上の蓄積された上り重みを増加することとを含む、方法。
  2. 前記少なくとも１つの上りポートを選択することは、複数の上りポートを比較して、最も蓄積されていない上り重みを有する前記上りポートを選択することを含む、請求項１に記載の方法。
  3. 前記複数のエンドノードの各々についての前記受信重みを受信することをさらに含む、請求項１または２に記載の方法。
  4. 前記複数のエンドノードの各々についての前記受信重みは、アドミニストレータからの入力から受信される、請求項１〜３のいずれか１項に記載の方法。
  5. ネットワークにおける１つ以上のリーフスイッチ上の前記複数のエンドノードの各々についての前記受信重みは入力から受信され、前記入力は、それぞれ前記複数のエンドノードの各々上の監視されるトラフィックに関係付けられる、請求項１〜４のいずれか１項に記載の方法。
  6. 前記少なくとも１つの下りポートを選択することは、複数の下りポートを比較して、最も蓄積されていない下り重みを有する前記下りポートを選択することを含む、請求項１〜５のいずれか１項に記載の方法。
  7. 前記少なくとも１つの下りポートを選択することは、最も蓄積されていない下り重みを有する２つ以上の下りポートに応答して、前記最も蓄積されていない下り重みを有する前記２つ以上の下りポートを比較して、前記最も蓄積されていない下り重みを有する前記２つ以上の下りポートから、最も蓄積されていない上り重みを有する前記下りポートを選択することを含む、請求項６に記載の方法。
  8. 前記少なくとも１つの下りポートを選択することは、
    複数の下りポートを比較して、最も蓄積されていない下り重みを有する前記下りポートを選択することと、
    最も蓄積されていない下り重みを有する２つ以上の下りポートに応答して、最も蓄積されていない下り重みを有する前記２つ以上の下りポートを比較して、前記最も蓄積されていない下り重みを有する前記２つ以上の下りポートから、最も蓄積されていない上り重みを有する前記下りポートを選択することと、
    前記最も蓄積されていない下り重みおよび前記最も蓄積されていない上り重みを有する前記２つ以上の下りポートに応答して、前記最も蓄積されていない下り重みおよび前記最も蓄積されていない上り重みを有する前記２つ以上の下りポートを比較して、前記最も蓄積されていない下り重みおよび前記最も蓄積されていない上り重みを有する前記２つ以上の下りポートから、最も小さなグローバル一意識別子を有する前記下りポートを選択することとを含む、請求項１〜５のいずれか１項に記載の方法。
  9. ネットワーク環境において、複数のレベルを含むツリートポロジーで配される複数のスイッチおよび複数のエンドノードの間で効率的なロードバランシングをサポートするためのシステムであって、
    １つ以上のマイクロプロセッサと、
    前記１つ以上のマイクロプロセッサ上で実行されるプロセッサとを含み、
    前記プロセッサは、
    前記複数のスイッチのうちの１つ以上の上に存在する前記複数のエンドノードを分類することを含むステップを実行するよう動作し、前記複数のエンドノードは受信重みの減少する順に分類され、前記プロセッサはさらに、
    前記受信重みの減少する順に前記複数のエンドノードをルーティングすることを含むステップを実行するよう動作し、前記複数のエンドノードのうちの対象エンドノードに対して前記ルーティングすることは、前記対象エンドノードに向かうルートについて少なくとも１つの下りポートおよび少なくとも１つの上りポートを選択することを含み、前記下りポートは、前記複数のレベルのうちの１つのレベルのスイッチから前記複数のレベルのうちの１レベルだけ下のレベルのスイッチへの下り方向のポートであり、前記上りポートは、前記複数のレベルのうちの１つのレベルのスイッチから前記複数のレベルのうちの１レベルだけ上のレベルのスイッチへの上り方向のポートであり、前記プロセッサはさらに、
    前記対象エンドノードの受信重みだけ、各選択された下りポート上の蓄積された下り重みを増加することと、
    前記対象エンドノードの受信重みだけ、各選択された上りポート上の蓄積された上り重みを増加することとを含むステップを実行するよう動作する、システム。
  10. 前記複数のスイッチおよび前記複数のエンドノードは、高性能コンピューティング（ＨＰＣ）クラスタにおける使用のためにファットツリートポロジーに配される、請求項９に記載のシステム。
  11. 前記プロセッサは、前記複数のエンドノードの各々について前記受信重みを受信するように動作する、請求項９または１０のいずれか１項に記載のシステム。
  12. 前記少なくとも１つの下りポートを選択することは、複数の下りポートを比較して、最も蓄積されていない下り重みを有する前記下りポートを選択することを含む、請求項９〜１１のいずれか１項に記載のシステム。
  13. 前記少なくとも１つの下りポートを選択することは、最も蓄積されていない下り重みを有する２つ以上の下りポートに応答して、前記最も蓄積されていない下り重みを有する前記２つ以上の下りポートを比較して、前記最も蓄積されていない下り重みを有する前記２つ以上の下りポートから、最も蓄積されていない上り重みを有する前記下りポートを選択することを含む、請求項１２に記載のシステム。
  14. 前記少なくとも１つの下りポートを選択することは、
    複数の下りポートを比較して、最も蓄積されていない下り重みを有する前記下りポートを選択することと、
    最も蓄積されていない下り重みを有する２つ以上の下りポートに応答して、前記最も蓄積されていない下り重みを有する前記２つ以上の下りポートを比較して、前記最も蓄積されていない下り重みを有する前記２つ以上の下りポートから、最も蓄積されていない上り重みを有する前記下りポートを選択することと、
    前記最も蓄積されていない下り重みおよび前記最も蓄積されていない上り重みを有する前記２つ以上の下りポートに応答して、前記最も蓄積されていない下り重みおよび前記最も蓄積されていない上り重みを有する前記２つ以上の下りポートを比較して、前記最も蓄積されていない下り重みおよび前記最も蓄積されていない上り重みを有する前記２つ以上の下りポートから、最も小さなグローバル一意識別子を有する前記下りポートを選択することとを含む、請求項９〜１１のいずれか１項に記載のシステム。
  15. マシン読取可能な形態の命令を含むコンピュータプログラムであって、前記命令は、コンピュータシステムによって実行されると、請求項１〜８のいずれか１項に記載の方法を前記コンピュータシステムに行なわせる、コンピュータプログラム。
JP2017501199A 2014-07-11 2015-07-09 高性能コンピューティング（ｈｐｃ：ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ｃｏｍｐｕｔｉｎｇ）環境において効率的なロードバランシングをサポートするためのシステムおよび方法 Active JP6541768B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201462023321P 2014-07-11 2014-07-11
US62/023,321 2014-07-11
US201462049466P 2014-09-12 2014-09-12
US62/049,466 2014-09-12
US14/792,070 2015-07-06
US14/792,070 US9876737B2 (en) 2014-07-11 2015-07-06 System and method for supporting efficient load-balancing in a high performance computing (HPC) environment
PCT/US2015/039767 WO2016007760A2 (en) 2014-07-11 2015-07-09 System and method for supporting efficient load-balancing in a high performance computing (hpc) environment

Publications (3)

Publication Number Publication Date
JP2017525279A JP2017525279A (ja) 2017-08-31
JP2017525279A5 JP2017525279A5 (ja) 2018-03-15
JP6541768B2 true JP6541768B2 (ja) 2019-07-10

Family

ID=53776955

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017501199A Active JP6541768B2 (ja) 2014-07-11 2015-07-09 高性能コンピューティング（ｈｐｃ：ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ｃｏｍｐｕｔｉｎｇ）環境において効率的なロードバランシングをサポートするためのシステムおよび方法

Country Status (6)

Country Link
US (6) US9876737B2 (ja)
EP (1) EP3167574B1 (ja)
JP (1) JP6541768B2 (ja)
KR (1) KR102397876B1 (ja)
CN (2) CN106489255B (ja)
WO (1) WO2016007760A2 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9876737B2 (en) * 2014-07-11 2018-01-23 Oracle International Corporation System and method for supporting efficient load-balancing in a high performance computing (HPC) environment
US10374926B2 (en) * 2016-01-28 2019-08-06 Oracle International Corporation System and method for monitoring logical network traffic flows using a ternary content addressable memory in a high performance computing environment
CN107770061B (zh) * 2016-08-16 2020-12-01 华为技术有限公司 转发报文的方法及转发设备
CN108604199B (zh) * 2016-08-23 2022-08-23 甲骨文国际公司 计算环境中支持快速混合重新配置的系统和方法、介质
JP6874565B2 (ja) * 2017-06-27 2021-05-19 富士通株式会社 情報処理システム、情報処理方法及び情報処理装置
JP6911619B2 (ja) * 2017-08-02 2021-07-28 富士通株式会社 情報処理システム及び情報処理方法
US10425324B2 (en) * 2017-08-17 2019-09-24 Fabriscale Technologies AS Method of computing balanced routing paths in fat-trees
FR3072236B1 (fr) * 2017-10-10 2020-11-27 Bull Sas Dispositif et procede d'acquisition de valeurs de compteurs associes a une tache de calcul
CN110233860B (zh) * 2018-03-05 2021-12-24 杭州萤石软件有限公司 一种负载均衡方法、装置和系统
CN108718338B (zh) * 2018-05-23 2021-06-15 深圳市茁壮网络股份有限公司 一种节点确定方法及装置
CN111224727B (zh) * 2020-04-24 2020-07-31 成都坤恒顺维科技股份有限公司 一种基于信道仿真仪的自适应拓扑结构的实现方法
US20220321479A1 (en) * 2021-04-02 2022-10-06 Microsoft Technology Licensing, Llc Anycast routing technique for a content delivery network
CN117061423B (zh) * 2023-10-09 2024-01-23 苏州元脑智能科技有限公司 一种胖树网络的多机路由方法、装置、系统及存储介质

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5138615A (en) * 1989-06-22 1992-08-11 Digital Equipment Corporation Reconfiguration system and method for high-speed mesh connected local area network
US6847614B2 (en) * 1998-04-20 2005-01-25 Broadcom Corporation Apparatus and method for unilateral topology discovery in network management
US7009968B2 (en) * 2000-06-09 2006-03-07 Broadcom Corporation Gigabit switch supporting improved layer 3 switching
KR100428767B1 (ko) * 2002-01-11 2004-04-28 삼성전자주식회사 트래픽 정보를 이용한 가입자 라우팅 설정 방법 및 이를위한 기록매체
US7804832B2 (en) * 2006-02-13 2010-09-28 Cisco Technology, Inc. Method and system for simplified network wide traffic and/or flow monitoring in a data network
US7761629B2 (en) * 2007-06-04 2010-07-20 International Business Machines Corporation Method for using host and storage controller port information to configure paths between a host and storage controller
EP2374250B1 (en) * 2009-01-19 2014-10-29 Hewlett-Packard Development Company, L.P. Load balancing
US8358597B2 (en) * 2009-10-01 2013-01-22 Hei Tao Fung Method for building scalable Ethernet switch network and huge Ethernet switch
FR2960732B1 (fr) * 2010-06-01 2012-06-29 Bull Sas Procede de routage pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procede
US9210071B2 (en) * 2010-08-16 2015-12-08 Telefonaktiebolaget L M Ericsson (Publ) Automated traffic engineering for fat tree networks
CN102164081B (zh) * 2011-03-31 2014-09-03 华为技术有限公司 一种胖树拓扑的路由计算方法、节点设备和通信系统
US9014201B2 (en) * 2011-11-09 2015-04-21 Oracle International Corporation System and method for providing deadlock free routing between switches in a fat-tree topology
US9325619B2 (en) 2011-11-15 2016-04-26 Oracle International Corporation System and method for using virtual lanes to alleviate congestion in a fat-tree topology
US8879396B2 (en) * 2011-11-15 2014-11-04 Oracle International Corporation System and method for using dynamic allocation of virtual lanes to alleviate congestion in a fat-tree topology
US9461915B1 (en) * 2012-01-26 2016-10-04 Google Inc. System and method for reducing consumption of hardware resources using weighted cost multi-path flow distribution
US9379971B2 (en) * 2012-05-11 2016-06-28 Simula Inovation AS Method and apparatus for determining paths between source/destination pairs
DE112012006604T5 (de) 2012-06-29 2015-05-07 Intel Corporation Energiesparverfahren für das Netzwerk-Routing-Protokoll für Netzwerkelemente
JP6056245B2 (ja) 2012-07-30 2017-01-11 セイコーエプソン株式会社 時計用文字板、及び太陽電池付電子時計
US9559919B2 (en) * 2013-03-07 2017-01-31 Brocade Communications Systems, Inc. Display of port transmit and receive parameters sorted by higher of transmit or receive value
CN103560967B (zh) * 2013-10-17 2016-06-01 电子科技大学 一种业务需求感知的虚拟数据中心映射方法
JP6303613B2 (ja) * 2014-03-05 2018-04-04 富士通株式会社 経路データ生成装置、経路データ生成方法及び経路データ生成プログラム
US9876737B2 (en) * 2014-07-11 2018-01-23 Oracle International Corporation System and method for supporting efficient load-balancing in a high performance computing (HPC) environment

Also Published As

Publication number Publication date
EP3167574A2 (en) 2017-05-17
US20220014484A1 (en) 2022-01-13
US20190327186A1 (en) 2019-10-24
EP3167574B1 (en) 2019-05-15
US10374979B2 (en) 2019-08-06
US9876737B2 (en) 2018-01-23
JP2017525279A (ja) 2017-08-31
US11411890B2 (en) 2022-08-09
CN110474848B (zh) 2023-04-07
CN106489255A (zh) 2017-03-08
CN106489255B (zh) 2019-11-01
US20220368652A1 (en) 2022-11-17
US20160014049A1 (en) 2016-01-14
CN110474848A (zh) 2019-11-19
US20230353507A1 (en) 2023-11-02
WO2016007760A2 (en) 2016-01-14
US11159452B2 (en) 2021-10-26
WO2016007760A3 (en) 2016-03-03
US11716293B2 (en) 2023-08-01
KR102397876B1 (ko) 2022-05-13
KR20170029595A (ko) 2017-03-15
US20180123981A1 (en) 2018-05-03

Similar Documents

Publication Publication Date Title
JP6541768B2 (ja) 高性能コンピューティング（ｈｐｃ：ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ｃｏｍｐｕｔｉｎｇ）環境において効率的なロードバランシングをサポートするためのシステムおよび方法
CN107113233B (zh) 用于支持多租户集群环境中的分区感知路由的系统和方法
US11677667B2 (en) System and method for efficient network isolation and load balancing in a multi-tenant cluster environment
CN108400922B (zh) 虚拟局域网络配置系统与方法及其计算机可读存储介质

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180205

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180205

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190123

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190129

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190418

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190514

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190611

R150 Certificate of patent or registration of utility model

Ref document number: 6541768

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250