4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

高性能コンピューティングにおけるRoCE技術:洞察と応用

Last updated at Posted at 2024-02-07

FSコミュニティで原文を読む

HPCネットワークの進化とRoCEの出現

高性能コンピューティング(HPC)システムの初期時代には、Myrinet、Quadrics、InfiniBandなどの専用のネットワーキングソリューションが一般的にEthernetよりも選ばれていました。これらのカスタムネットワークは、Ethernetソリューションの制約に効果的に対処し、高い帯域幅、低遅延、改善された混雑制御、独自の機能を提供しました。2010年、IBTA(InfiniBand Trade Association)はRoCE(RDMA over Converged Ethernet)プロトコル技術の標準を導入し、2014年にはRoCEv2プロトコル技術の標準がリリースされ、帯域幅が大幅に向上しました。Ethernetの性能の顕著な向上により、従来のEthernetと互換性のある高性能ネットワークソリューションへの関心が高まっています。このシフトにより、HPCクラスターのトップ500におけるEthernetの使用率の減少傾向が逆転し、Ethernetはランキングで優れた位置を維持することが可能になりました。

MyrinetとQuadricsはシーンから姿を消しましたが、InfiniBandは高性能ネットワークにおいて重要な役割を果たし続けています。さらに、Cray、Tianhe、Tofulseriesネットワークによる独自のネットワーク シリーズも重要な役割を果たしています。

RoCE

RoCEプロトコルの紹介

RoCEプロトコルは、イーサネット上でのリモート・ダイレクト・メモリ・アクセス(RDMA)を容易にするクラスターネットワーク通信プロトコルとして機能します。このプロトコルは、パケットの送受信タスクをネットワークカードに転送するため、TCP/IPプロトコルのカーネルモードへのシステムの入る必要がなくなります。その結果、コピー、カプセル化、デカプセル化に関連するオーバーヘッドが削減され、イーサネット通信の遅延が大幅に低減されます。さらに、通信中のCPUリソースの利用を最小限に抑え、ネットワークの混雑を緩和し、帯域幅の効率的な利用を向上させます。

RoCEプロトコルには、RoCE v1とRoCE v2の2つのバージョンがあります。RoCE v1はリンク層プロトコルとして動作し、通信する双方のパーティが同じレイヤー2ネットワーク内にあることが必要です。一方、RoCE v2はネットワーク層プロトコルとして機能し、RoCE v2プロトコルパケットをレイヤー3でルーティングすることができ、優れたスケーラビリティを提供します。

RoCE V1プロトコル

RoCEプロトコルは、InfiniBand(IB)のインタフェース、トランスポート層、ネットワーク層を保持しながら、IBのリンク層と物理層をEthernetのリンク層とネットワーク層で置き換えます。RoCEデータパケットのリンク層データフレームでは、IEEEによって0x8915と指定されたEthertypeフィールドの値が使用され、これによりRoCEデータパケットであることが明確に識別されます。ただし、RoCEプロトコルはEthernetのネットワーク層を採用していないため、RoCEデータパケットにはIPフィールドが存在しません。その結果、ネットワーク層でのルーティングはRoCEデータパケットには不可行であり、レイヤー2ネットワーク内でのルーティングに制限されています。

RoCE

RoCE V2プロトコル

RoCE v2プロトコルは、RoCEプロトコルの基盤を活かしつつ、大幅な機能強化を導入しています。RoCE v2は、イーサネット・ネットワーク層とUDPプロトコルを使用したトランスポート層を組み込むことで、RoCEプロトコルが利用するInfiniBand(IB)ネットワーク層を変換します。RoCE v2は、イーサネット・ネットワーク層のIPデータグラム内のDSCP(Differentiated Services Code Point)およびECN(Explicit Congestion Notification)フィールドを活用して、輻輳制御を実装します。これにより、RoCE v2プロトコルパケットはルーティングを経ることができ、優れたスケーラビリティが確保されます。RoCE v2は元のRoCEプロトコルを完全に置き換えるため、通常、RoCEプロトコルという言及はRoCE v2プロトコルを指し、RoCEの第一世代と明示的に指定されていない限り、RoCE v2を意味します。

ロスレスネットワークとRoCE輻輳制御メカニズム

RoCEプロトコルベースのネットワークでは、RoCEトラフィックのシームレスな送信を確保することが重要です。RDMA通信中には、データパケットが損失なく正しい順序で宛先に到達することが不可欠です。パケットの損失や順序の乱れが発生した場合、ゴーバックNの再送信が必要となり、予想される後続のデータパケットはキャッシュに格納されてはなりません。

RoCEプロトコルでは、2つの段階からなる輻輳制御メカニズムを実装しています。まず、DCQCN(Datacenter Quantized Congestion Notification)を活用した初期段階での徐々の遅延制御が行われます。その後、PFC(Priority Flow Control)を利用した送信一時停止段階が続きます。これらは厳密には輻輳制御戦略とトラフィック制御戦略として分類されますが、一般的には輻輳制御の2つの段階と見なされています。

ネットワーク内での複数対1の通信の場合、輻輳が発生しやすく、スイッチのポート上の保留送信バッファメッセージの総サイズが急速に増加することがよく見られます。制御されていない状況では、バッファの飽和が起こり、パケットの損失が発生する可能性があります。したがって、初期段階では、スイッチがポートの保留送信バッファメッセージの合計サイズが特定の閾値に達したことを検出すると、RoCEデータパケットのIPレイヤーのECNフィールドをマークします。受信者はこのパケットを受け取ると、スイッチによってマークされたECNフィールドを観察し、送信元に対して輻輳通知パケット(CNP)を送信し、送信速度の低下を促します。

重要なことは、ECNフィールドの閾値に到達した場合、すべてのパケットがマークされるわけではないということです。このプロセスでは、KminとKmaxという2つのパラメータが役割を果たします。輻輳キューの長さがKmin未満の場合、マーキングは行われません。キューの長さがKminからKmaxの範囲にある場合、キューの長さが長くなるにつれてマーキングの確率が増加します。キューの長さがKmaxを超えると、すべてのパケットがマークされます。受信者は、受信したECNマーキングのあるパケットごとにCNP(Congestion Notification Packet)パケットを送信するのではなく、一定の時間間隔でCNPパケットを送信します。このアプローチにより、送信者は受信したCNPパケットの数に基づいて送信速度を調整することができます。CNPパケットの送信率を監視することで、送信者はネットワークの輻輳状態を把握し、送信速度を適切に調整することができます。

RoCE

ネットワークの輻輳が悪化し、スイッチが特定のポートの保留送信キューのキュー長がより高い閾値に達した場合、スイッチはメッセージの上流送信元に対してPause Flow Control(PFC)フレームを送信します。この動作により、スイッチ内の輻輳が緩和されるまでデータの送信が一時停止します。輻輳が解消されると、スイッチはPFC制御フレームを上流に送信して送信の再開を示します。PFCフロー制御は、異なるトラフィックチャネルでの一時停止をサポートし、各チャネルの帯域幅比率を全体の帯域幅に対して調整することができます。この設定により、一つのチャネルでのトラフィック送信を一時停止することができ、他のチャネルでのデータ送信には影響を与えません。

ROCE & Soft-RoCE

高性能イーサネットカードの領域では、RoCEプロトコルを採用している製品が多数存在しますが、一部のカードではサポートが提供されていない場合もあります。このギャップに対応するために、IBIV、Mellanoxなどの協力者による共同の取り組みにより、オープンソースのSoft-RoCEプロジェクトが生まれました。このイニシアチブは、RoCEプロトコルがサポートされていないノードに対応し、RoCE対応のカードを備えたノードとの通信にSoft-RoCEを活用することを可能にします(図で示されています)。これにより、前者の性能は向上しないかもしれませんが、後者は自身の性能能力を十分に活用することができます。特にデータセンターなどのシナリオでは、RoCE対応のイーサネットカードを搭載した高I/Oストレージサーバーに戦略的なアップグレードを行うことで、全体的な性能と拡張性を大幅に向上させることができます。さらに、RoCEとSoft-RoCEの組み合わせは、段階的なクラスターのアップグレードの要求にも適応し、同時の全面的なアップグレードの必要性を排除します。

RoCE

HPC環境でのRoCEの実装における課題

HPCネットワークの基本要件

FSによって示された通り、HPCネットワークは2つの基本的な前提条件に依存しています:①低レイテンシと②急速に進化するトラフィックパターンにおける低レイテンシを維持する能力です。

①低レイテンシに関しては、RoCEはこの問題に対処するために特別に設計されています。先の議論でも述べたように、RoCEはネットワーク操作を効率的にネットワークカードにオフロードすることで、低レイテンシとCPU利用率の削減を実現します。

②急速に変化するトラフィックパターンにおいて低レイテンシを維持するためには、主な焦点は輻輳制御に移ります。高度にダイナミックなHPCトラフィックパターンの複雑さは、RoCEにとって課題となり、この点で最適なパフォーマンスが得られないことがあります。

 

ROCEの低レイテンシー

従来のTCP/IPネットワークとは異なり、InfiniBandとRoCEv2の両方はカーネルプロトコルスタックを回避し、レイテンシ性能の大幅な向上をもたらします。実証テストでは、カーネルプロトコルスタックをバイパスすることで、アプリケーションレイヤー内でのエンドツーエンドのレイテンシを、同じクラスター内で50マイクロ秒(TCP/IP)から5マイクロ秒(RoCE)または2マイクロ秒(InfiniBand)にまで短縮できることが実証されています。

RoCE

RoCEパケット構造

RoCEを使用して1バイトのデータを送信する場合、この1バイトのデータパケットをカプセル化するための追加コストは以下の通りです:

イーサネットリンク層: 14バイトのMACヘッダー + 4バイトのCRC

イーサネットIP層: 20バイト

イーサネットUDP層: 8バイト

IBトランスポート層: 12バイトのベーストランスポートヘッダー(BTH)

合計: 58バイト

IBを使用して1バイトのデータを送信する場合、この1バイトのデータパケットをカプセル化するための追加コストは以下の通りです:

IBリンク層: 8バイトのローカルルーティングヘッダー(LHR)+ 6バイトのCRC

IBネットワーク層: 0バイト(レイヤー2ネットワークのみが存在する場合、リンク層のリンク次ヘッダ(LNH)フィールドは、パケットにネットワーク層が存在しないことを示すことができます。)

IBトランスポート層: 12バイトのベーストランスポートヘッダー(BTH)

合計: 26バイト

もしカスタマイズされたネットワークの場合、パケットの構造はさらに簡素化することが可能です。例えば、天河-1Aのミニパケット(MP)ヘッダーは8バイトで構成されています。

このことから、イーサネットの重い基礎構造がRoCEをHPCに適用する際の障害の1つであることがわかります。

データセンターのイーサネットスイッチには、多くの場合、SDN、Qosなど、その他の多くの機能が必要となるため、実装には追加コストが必要になります。

これらのイーサネット機能について、イーサネットとRoCEはこれらの機能と互換性がありますか? これらの機能はRoCEのパフォーマンスに影響しますか?

RoCEの輻輳制御における課題

RoCEプロトコルの両方の側面における輻輳制御メカニズムは、動的トラフィック パターンにおける低遅延の維持を妨げる可能性がある特定の課題を引き起こします。

優先フロー制御(PFC)は、パケットの過剰な受信を防ぐためにポーズ制御フレームに依存していますが、この方法はパケットの損失のリスクがあります。クレジットベースの方法とは異なり、PFCはバッファの利用率が低くなりがちであり、特にバッファが制限されたスイッチでは低レイテンシと関連しています。逆に、クレジットベースのアプローチはより正確なバッファ管理を提供します。

RoCEにおけるデータセンター量子化過負荷通知(DCQCN)は、InfiniBandの過負荷制御に似た方式で、過負荷情報を宛先に伝え、それを送信元に戻してレート制限を行います。RoCEは減速と加速の戦略に固定された一連の公式に従いますが、InfiniBandではカスタマイズ可能な戦略を使用できるため、より柔軟性があります。デフォルトの設定が一般的に使用されますが、カスタマイズオプションがあることが望ましいです。特に、参照された論文のテストでは、最大でN=50マイクロ秒ごとに1つの過負荷通知パケット(CNP)を生成することが行われましたが、この値をさらに減らすことの可否は不確定です。InfiniBandでは、CCTI_Timerを1.024マイクロ秒まで低く設定することができますが、このように小さな値を実装することの実用性は未定です。

理想的なアプローチは、過負荷ポイントから直接過負荷情報をソースに戻す、つまりフォワード通知として知られる手法です。Ethernetの制約は仕様に基づいて理解されていますが、InfiniBandがこのアプローチを採用しない理由には疑問が生じます。

HPCにおけるRoCEアプリケーション: スリングショットとパフォーマンステスト

最新のアメリカのスーパーコンピュータは、イノベーティブなスリングショットネットワークを採用しており、これはイーサネットの強化版です。従来のイーサネットと互換性のあるRosettaスイッチを利用して、このネットワークは特定のRoCEの制約に対処しています。ネットワークカードやRosettaスイッチなどの専用デバイスをサポートするリンクの両端がある場合、強化された機能が活用されます。これらの機能には、IPパケットフレームサイズを32バイトに最小化すること、隣接するスイッチとのキュー占有情報の共有、改良された過負荷制御の実装などが含まれます。平均スイッチレイテンシは350nsで、高性能Ethernetスイッチと比較して類似していますが、InfiniBand(IB)や一部の専用のスーパーコンピュータスイッチ、前世代のCray XCスーパーコンピュータスイッチなどが達成する低レイテンシには及びません。

実際の応用において、スリングショットネットワークは称賛される性能を発揮しています。特筆すべきは、「An In-Depth Analysis of the Slingshot Interconnect」という論文が、主に以前のCrayスーパーコンピュータの前世代と比較されている点ですが、InfiniBandとの直接的な比較は行われていません。

さらに、CESMとGROMACSのアプリケーションは、低レイテンシの25Gイーサネットと高帯域幅の100Gイーサネットの両方を使用してテストされました。両者の間で帯域幅に4倍の差があるにもかかわらず、結果は比較的な性能について貴重な洞察を提供しています。 [图片]

RoCE

RoCE

結論

FSは、熟練した技術チームと多様なアプリケーションシナリオでの豊富な経験を持ち、顧客からの信頼と好評を得てきました。しかし、FSは市場の要求やユーザーのプロジェクト実装の経験に基づいて、高性能コンピューティング(HPC)へのRoCEの適用における課題を認識しています:

  • イーサネットスイッチは、IBスイッチや一部のHPCカスタムネットワークスイッチと比較して、より高いレイテンシがあります。

  • RoCEのフロー制御と過負荷制御の戦略には改善の余地があります。

  • イーサネット スイッチのコストは依然として比較的高いです。

急速に進化するAIデータセンター・ネットワークの文脈において、適切なソリューションの選択は非常に重要です。高いネットワークパフォーマンスを要求するAIアプリケーションに対しては、従来のTCP/IPプロトコルでは十分ではありません。特にInfiniBandとRoCEという形態のRDMA技術は、非常に優れたネットワークソリューションとして注目されています。InfiniBandは、ハイパフォーマンスコンピューティングや大規模なGPUクラスターといった領域で優れたパフォーマンスを示しています。一方、イーサネットを基にしたRDMA技術であるRoCEは、展開の柔軟性が向上しています。

高性能かつ効率的なAIデータセンターネットワークを求める企業にとっては、特定の要件やアプリケーションシナリオに合わせた適切なネットワークソリューションの選択は重要なステップとなります。FSは、NVIDIA® InfiniBandスイッチ100G/200G/400G/800G InfiniBandトランシーバー、NVIDIA® InfiniBandアダプタなどの製品を提供しており、ネットワーク、データセンター、通信クライアント向けの通信および高速ネットワークシステムソリューションの専門プロバイダーとして位置づけられています。

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?