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

<a href="https://community.fs.com/jp/article/roce-technology-in-high-performance-computing.html">FSコミュニティで原文を読む</a>
<h2 class="tit_one community_blog_detail_tit_one">HPCネットワークの進化とRoCEの出現</h2>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">高性能コンピューティング（HPC）システムの初期時代には、Myrinet、Quadrics、InfiniBandなどの専用のネットワーキングソリューションが一般的にEthernetよりも選ばれていました。これらのカスタムネットワークは、Ethernetソリューションの制約に効果的に対処し、高い帯域幅、低遅延、改善された混雑制御、独自の機能を提供しました。2010年、IBTA（InfiniBand Trade Association）はRoCE（RDMA over Converged Ethernet）プロトコル技術の標準を導入し、2014年にはRoCEv2プロトコル技術の標準がリリースされ、帯域幅が大幅に向上しました。Ethernetの性能の顕著な向上により、従来のEthernetと互換性のある高性能ネットワークソリューションへの関心が高まっています。このシフトにより、HPCクラスターのトップ500におけるEthernetの使用率の減少傾向が逆転し、Ethernetはランキングで優れた位置を維持することが可能になりました。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">MyrinetとQuadricsはシーンから姿を消しましたが、InfiniBandは高性能ネットワークにおいて重要な役割を果たし続けています。さらに、Cray、Tianhe、Tofulseriesネットワークによる独自のネットワーク シリーズも重要な役割を果たしています。</p>
<p><img title="RoCE" src="https://media.fs.com/images/community/erp/sXEAR_roce-technology1QnH3e.jpg" alt="RoCE" width="100%" /></p>
<h2 class="tit_one community_blog_detail_tit_one">RoCEプロトコルの紹介</h2>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">RoCEプロトコルは、イーサネット上でのリモート・ダイレクト・メモリ・アクセス（RDMA）を容易にするクラスターネットワーク通信プロトコルとして機能します。このプロトコルは、パケットの送受信タスクをネットワークカードに転送するため、TCP/IPプロトコルのカーネルモードへのシステムの入る必要がなくなります。その結果、コピー、カプセル化、デカプセル化に関連するオーバーヘッドが削減され、イーサネット通信の遅延が大幅に低減されます。さらに、通信中のCPUリソースの利用を最小限に抑え、ネットワークの混雑を緩和し、帯域幅の効率的な利用を向上させます。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">RoCEプロトコルには、RoCE v1とRoCE v2の2つのバージョンがあります。RoCE v1はリンク層プロトコルとして動作し、通信する双方のパーティが同じレイヤー2ネットワーク内にあることが必要です。一方、RoCE v2はネットワーク層プロトコルとして機能し、RoCE v2プロトコルパケットをレイヤー3でルーティングすることができ、優れたスケーラビリティを提供します。</p>
<h3 class="new_community_detaile_section_h3 new_community_detaile_section_h3_1">RoCE V1プロトコル</h3>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">RoCEプロトコルは、InfiniBand（IB）のインタフェース、トランスポート層、ネットワーク層を保持しながら、IBのリンク層と物理層をEthernetのリンク層とネットワーク層で置き換えます。RoCEデータパケットのリンク層データフレームでは、IEEEによって0x8915と指定されたEthertypeフィールドの値が使用され、これによりRoCEデータパケットであることが明確に識別されます。ただし、RoCEプロトコルはEthernetのネットワーク層を採用していないため、RoCEデータパケットにはIPフィールドが存在しません。その結果、ネットワーク層でのルーティングはRoCEデータパケットには不可行であり、レイヤー2ネットワーク内でのルーティングに制限されています。</p>
<p><img title="RoCE" src="https://media.fs.com/images/community/erp/dX2dD_rocetechnology23fMSG.jpg" alt="RoCE" width="100%" /></p>
<h3 class="new_community_detaile_section_h3 new_community_detaile_section_h3_1">RoCE V2プロトコル</h3>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">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を意味します。</p>
<h2 class="tit_one community_blog_detail_tit_one">ロスレスネットワークとRoCE輻輳制御メカニズム</h2>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">RoCEプロトコルベースのネットワークでは、RoCEトラフィックのシームレスな送信を確保することが重要です。RDMA通信中には、データパケットが損失なく正しい順序で宛先に到達することが不可欠です。パケットの損失や順序の乱れが発生した場合、ゴーバックNの再送信が必要となり、予想される後続のデータパケットはキャッシュに格納されてはなりません。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">RoCEプロトコルでは、2つの段階からなる輻輳制御メカニズムを実装しています。まず、DCQCN（Datacenter Quantized Congestion Notification）を活用した初期段階での徐々の遅延制御が行われます。その後、PFC（Priority Flow Control）を利用した送信一時停止段階が続きます。これらは厳密には輻輳制御戦略とトラフィック制御戦略として分類されますが、一般的には輻輳制御の2つの段階と見なされています。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">ネットワーク内での複数対1の通信の場合、輻輳が発生しやすく、スイッチのポート上の保留送信バッファメッセージの総サイズが急速に増加することがよく見られます。制御されていない状況では、バッファの飽和が起こり、パケットの損失が発生する可能性があります。したがって、初期段階では、スイッチがポートの保留送信バッファメッセージの合計サイズが特定の閾値に達したことを検出すると、RoCEデータパケットのIPレイヤーのECNフィールドをマークします。受信者はこのパケットを受け取ると、スイッチによってマークされたECNフィールドを観察し、送信元に対して輻輳通知パケット（CNP）を送信し、送信速度の低下を促します。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">重要なことは、ECNフィールドの閾値に到達した場合、すべてのパケットがマークされるわけではないということです。このプロセスでは、KminとKmaxという2つのパラメータが役割を果たします。輻輳キューの長さがKmin未満の場合、マーキングは行われません。キューの長さがKminからKmaxの範囲にある場合、キューの長さが長くなるにつれてマーキングの確率が増加します。キューの長さがKmaxを超えると、すべてのパケットがマークされます。受信者は、受信したECNマーキングのあるパケットごとにCNP（Congestion Notification Packet）パケットを送信するのではなく、一定の時間間隔でCNPパケットを送信します。このアプローチにより、送信者は受信したCNPパケットの数に基づいて送信速度を調整することができます。CNPパケットの送信率を監視することで、送信者はネットワークの輻輳状態を把握し、送信速度を適切に調整することができます。</p>
<p><img title="RoCE" src="https://media.fs.com/images/community/erp/zjpPZ_rocetechnology3hHe2Q.jpg" alt="RoCE" width="100%" /></p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">ネットワークの輻輳が悪化し、スイッチが特定のポートの保留送信キューのキュー長がより高い閾値に達した場合、スイッチはメッセージの上流送信元に対してPause Flow Control（PFC）フレームを送信します。この動作により、スイッチ内の輻輳が緩和されるまでデータの送信が一時停止します。輻輳が解消されると、スイッチはPFC制御フレームを上流に送信して送信の再開を示します。PFCフロー制御は、異なるトラフィックチャネルでの一時停止をサポートし、各チャネルの帯域幅比率を全体の帯域幅に対して調整することができます。この設定により、一つのチャネルでのトラフィック送信を一時停止することができ、他のチャネルでのデータ送信には影響を与えません。</p>
<h2 class="tit_one community_blog_detail_tit_one">ROCE &amp; Soft-RoCE</h2>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">高性能イーサネットカードの領域では、RoCEプロトコルを採用している製品が多数存在しますが、一部のカードではサポートが提供されていない場合もあります。このギャップに対応するために、IBIV、Mellanoxなどの協力者による共同の取り組みにより、オープンソースのSoft-RoCEプロジェクトが生まれました。このイニシアチブは、RoCEプロトコルがサポートされていないノードに対応し、RoCE対応のカードを備えたノードとの通信にSoft-RoCEを活用することを可能にします（図で示されています）。これにより、前者の性能は向上しないかもしれませんが、後者は自身の性能能力を十分に活用することができます。特にデータセンターなどのシナリオでは、RoCE対応のイーサネットカードを搭載した高I/Oストレージサーバーに戦略的なアップグレードを行うことで、全体的な性能と拡張性を大幅に向上させることができます。さらに、RoCEとSoft-RoCEの組み合わせは、段階的なクラスターのアップグレードの要求にも適応し、同時の全面的なアップグレードの必要性を排除します。</p>
<p><img title="RoCE" src="https://media.fs.com/images/community/erp/cNhSC_rocetechnology4ShGCT.jpg" alt="RoCE" width="100%" /></p>
<h2 class="tit_one community_blog_detail_tit_one">HPC環境でのRoCEの実装における課題</h2>
<h3 class="new_community_detaile_section_h3 new_community_detaile_section_h3_1">HPCネットワークの基本要件</h3>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">FSによって示された通り、HPCネットワークは2つの基本的な前提条件に依存しています：①低レイテンシと②急速に進化するトラフィックパターンにおける低レイテンシを維持する能力です。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">①低レイテンシに関しては、RoCEはこの問題に対処するために特別に設計されています。先の議論でも述べたように、RoCEはネットワーク操作を効率的にネットワークカードにオフロードすることで、低レイテンシとCPU利用率の削減を実現します。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">②急速に変化するトラフィックパターンにおいて低レイテンシを維持するためには、主な焦点は輻輳制御に移ります。高度にダイナミックなHPCトラフィックパターンの複雑さは、RoCEにとって課題となり、この点で最適なパフォーマンスが得られないことがあります。</p>
<div data-page-id="KpqCdfklholP66x9KwCcTZthncf" data-docx-has-block-data="false"> </div>
<h3 class="heading-2 ace-line old-record-id-IppEdMvwCoy9K6xniptcFH0tn2P">ROCEの低レイテンシー</h3>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">従来のTCP/IPネットワークとは異なり、InfiniBandとRoCEv2の両方はカーネルプロトコルスタックを回避し、レイテンシ性能の大幅な向上をもたらします。実証テストでは、カーネルプロトコルスタックをバイパスすることで、アプリケーションレイヤー内でのエンドツーエンドのレイテンシを、同じクラスター内で50マイクロ秒（TCP/IP）から5マイクロ秒（RoCE）または2マイクロ秒（InfiniBand）にまで短縮できることが実証されています。</p>
<p><img title="RoCE" src="https://media.fs.com/images/community/erp/rfYEF_rocetechnology53Jkhk.jpg" alt="RoCE" width="100%" /></p>
<h3 class="new_community_detaile_section_h3 new_community_detaile_section_h3_1">RoCEパケット構造</h3>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">RoCEを使用して1バイトのデータを送信する場合、この1バイトのデータパケットをカプセル化するための追加コストは以下の通りです:</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">イーサネットリンク層: 14バイトのMACヘッダー + 4バイトのCRC</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">イーサネットIP層: 20バイト</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">イーサネットUDP層: 8バイト</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">IBトランスポート層: 12バイトのベーストランスポートヘッダー（BTH）</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">合計: 58バイト</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">IBを使用して1バイトのデータを送信する場合、この1バイトのデータパケットをカプセル化するための追加コストは以下の通りです:</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">IBリンク層: 8バイトのローカルルーティングヘッダー（LHR）+ 6バイトのCRC</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">IBネットワーク層: 0バイト（レイヤー2ネットワークのみが存在する場合、リンク層のリンク次ヘッダ（LNH）フィールドは、パケットにネットワーク層が存在しないことを示すことができます。）</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">IBトランスポート層: 12バイトのベーストランスポートヘッダー（BTH）</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">合計: 26バイト</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">もしカスタマイズされたネットワークの場合、パケットの構造はさらに簡素化することが可能です。例えば、天河-1Aのミニパケット（MP）ヘッダーは8バイトで構成されています。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">このことから、イーサネットの重い基礎構造がRoCEをHPCに適用する際の障害の1つであることがわかります。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">データセンターのイーサネットスイッチには、多くの場合、SDN、Qosなど、その他の多くの機能が必要となるため、実装には追加コストが必要になります。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">これらのイーサネット機能について、イーサネットとRoCEはこれらの機能と互換性がありますか? これらの機能はRoCEのパフォーマンスに影響しますか?</p>
<h2 class="tit_one community_blog_detail_tit_one">RoCEの輻輳制御における課題</h2>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">RoCEプロトコルの両方の側面における輻輳制御メカニズムは、動的トラフィック パターンにおける低遅延の維持を妨げる可能性がある特定の課題を引き起こします。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">優先フロー制御（PFC）は、パケットの過剰な受信を防ぐためにポーズ制御フレームに依存していますが、この方法はパケットの損失のリスクがあります。クレジットベースの方法とは異なり、PFCはバッファの利用率が低くなりがちであり、特にバッファが制限されたスイッチでは低レイテンシと関連しています。逆に、クレジットベースのアプローチはより正確なバッファ管理を提供します。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">RoCEにおけるデータセンター量子化過負荷通知（DCQCN）は、InfiniBandの過負荷制御に似た方式で、過負荷情報を宛先に伝え、それを送信元に戻してレート制限を行います。RoCEは減速と加速の戦略に固定された一連の公式に従いますが、InfiniBandではカスタマイズ可能な戦略を使用できるため、より柔軟性があります。デフォルトの設定が一般的に使用されますが、カスタマイズオプションがあることが望ましいです。特に、参照された論文のテストでは、最大でN=50マイクロ秒ごとに1つの過負荷通知パケット（CNP）を生成することが行われましたが、この値をさらに減らすことの可否は不確定です。InfiniBandでは、CCTI_Timerを1.024マイクロ秒まで低く設定することができますが、このように小さな値を実装することの実用性は未定です。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">理想的なアプローチは、過負荷ポイントから直接過負荷情報をソースに戻す、つまりフォワード通知として知られる手法です。Ethernetの制約は仕様に基づいて理解されていますが、InfiniBandがこのアプローチを採用しない理由には疑問が生じます。</p>
<h2 class="tit_one community_blog_detail_tit_one">HPCにおけるRoCEアプリケーション: スリングショットとパフォーマンステスト</h2>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">最新のアメリカのスーパーコンピュータは、イノベーティブなスリングショットネットワークを採用しており、これはイーサネットの強化版です。従来のイーサネットと互換性のあるRosettaスイッチを利用して、このネットワークは特定のRoCEの制約に対処しています。ネットワークカードやRosettaスイッチなどの専用デバイスをサポートするリンクの両端がある場合、強化された機能が活用されます。これらの機能には、IPパケットフレームサイズを32バイトに最小化すること、隣接するスイッチとのキュー占有情報の共有、改良された過負荷制御の実装などが含まれます。平均スイッチレイテンシは350nsで、高性能Ethernetスイッチと比較して類似していますが、InfiniBand（IB）や一部の専用のスーパーコンピュータスイッチ、前世代のCray XCスーパーコンピュータスイッチなどが達成する低レイテンシには及びません。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">実際の応用において、スリングショットネットワークは称賛される性能を発揮しています。特筆すべきは、「An In-Depth Analysis of the Slingshot Interconnect」という論文が、主に以前のCrayスーパーコンピュータの前世代と比較されている点ですが、InfiniBandとの直接的な比較は行われていません。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">さらに、CESMとGROMACSのアプリケーションは、低レイテンシの25Gイーサネットと高帯域幅の100Gイーサネットの両方を使用してテストされました。両者の間で帯域幅に4倍の差があるにもかかわらず、結果は比較的な性能について貴重な洞察を提供しています。 [图片]</p>
<p><img title="RoCE" src="https://media.fs.com/images/community/erp/aZEBR_rocetechnology6AZKFJ.jpg" alt="RoCE" width="100%" /></p>
<p><img title="RoCE" src="https://media.fs.com/images/community/erp/ZjByW_switchesai7iThPA.jpg" alt="RoCE" width="100%" /></p>
<h2 class="tit_one community_blog_detail_tit_one">結論</h2>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">FSは、熟練した技術チームと多様なアプリケーションシナリオでの豊富な経験を持ち、顧客からの信頼と好評を得てきました。しかし、FSは市場の要求やユーザーのプロジェクト実装の経験に基づいて、高性能コンピューティング（HPC）へのRoCEの適用における課題を認識しています:</p>
<ul class="new_community_blog_detail_ul">
<li><span class="new_community_blog_detail_ul_circle"></span>
<p>イーサネットスイッチは、IBスイッチや一部のHPCカスタムネットワークスイッチと比較して、より高いレイテンシがあります。</p>
</li>
<li><span class="new_community_blog_detail_ul_circle"></span>
<p>RoCEのフロー制御と過負荷制御の戦略には改善の余地があります。</p>
</li>
<li><span class="new_community_blog_detail_ul_circle"></span>
<p>イーサネット スイッチのコストは依然として比較的高いです。</p>
</li>
</ul>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">急速に進化するAIデータセンター・ネットワークの文脈において、適切なソリューションの選択は非常に重要です。高いネットワークパフォーマンスを要求するAIアプリケーションに対しては、従来のTCP/IPプロトコルでは十分ではありません。特にInfiniBandとRoCEという形態のRDMA技術は、非常に優れたネットワークソリューションとして注目されています。InfiniBandは、ハイパフォーマンスコンピューティングや大規模なGPUクラスターといった領域で優れたパフォーマンスを示しています。一方、イーサネットを基にしたRDMA技術であるRoCEは、展開の柔軟性が向上しています。</p>
<p class="blog_p padding_top_none community_blog_detail_p community_blog_detail_p1">高性能かつ効率的なAIデータセンターネットワークを求める企業にとっては、特定の要件やアプリケーションシナリオに合わせた適切なネットワークソリューションの選択は重要なステップとなります。FSは、<a href="https://www.fs.com/jp/c/nvidiar-infiniband-switches-4156" target="_blank" rel="noopener">NVIDIA® InfiniBandスイッチ</a>、<a href="https://www.fs.com/jp/c/infiniband-ethernet-2875" target="_blank" rel="noopener">100G/200G/400G/800G</a> InfiniBandトランシーバー、<a href="https://www.fs.com/jp/c/nvidiar-infiniband-adapters-4173" target="_blank" rel="noopener">NVIDIA® InfiniBandアダプタ</a>などの製品を提供しており、ネットワーク、データセンター、通信クライアント向けの通信および高速ネットワークシステムソリューションの専門プロバイダーとして位置づけられています。</p>