AI 基盤に適したネットワークづくりとは？ ～RoCEv2をサポートするロスレスイーサネット検証～

生成AIや自動運転、音声操作といったAI活用の話題が大変盛り上がっています。皆さんも業務の中で、AI活用に対する対応を求められる機会も増えてきたのではないでしょうか？　この急速なAIの普及に伴い、AI 学習/推論では大量かつや高速なデータ転送が求められ、サーバー間を接続するネットワークにも高性能化が要求されています。しかし、一般的なイーサネットではこれらの要求に十分に応えることができません。このような背景の中で、RoCEv2（RDMA over Converged Ethernet version2）が注目を浴びています。

RoCEv2は、ロスレスなイーサネット上でRDMAを実現し、高速なデータ転送や低レイテンシーを可能にします。そのため、大規模なデータ処理や高速なデータ通信が求められるAIタスクにおいて、RoCEv2は有効な解決策となります。

RoCEv2はRDMA over Converged Ethernet version2の略語です。まず理解を深めるために「RDMA」という言葉から説明します。

RDMAとは

RDMA（Remote Direct Memory Access）は、通信する機器同士がデータをやり取りする際に、CPUを介さずに直接リモートサーバーのメモリにアクセスする技術です。

通常のデータ転送ではデータがまずメモリに格納され、次にCPUがそのデータを処理し、NICから送信するという手順を経ます。一方、RDMAを使用するとこの一連の手順からCPU処理を省略することができるため、データ転送におけるCPUのオーバーヘッドを大幅に削減することができます。その結果、低遅延、高速化を実現することができます。

RDMAは、高性能なデータ転送が求められるさまざまなシーン(大規模なデータセンター内でのサーバー間通信やストレージアクセス、高性能コンピューティングなど)で既に利用されていますが、特に最近ではAI処理を行うGPUノード間の高速通信に活用されています。

RDMAの弱点を補うロスレスネットワーク

RDMAは、通信中にパケットロスが発生すると性能が急激に低下するという弱点があります。この弱点を補うためにInfiniBandをはじめとするロスレスな専用のネットワークインフラがこれまでRDMAに用いられてきましたが、利用シーンが限られるため多くのネットワークエンジニアにとってあまり馴染みがありません。一方、イーサネットは広く普及しているため、馴染みのあるイーサネット上でRDMAを実現できるのであれば、ネットワークエンジニアにとってそれは非常に有益な選択肢となります。

RoCEv2のフレームフォーマット

RoCEにはv1とv2の2つのバージョンが存在します。

RoCEv1ではInfiniBandパケットをイーサネットヘッダーでカプセル化しているため、イーサネット上でのRDMAトラフィックのやり取りが可能になりましたが、同一セグメントのみでしかやり取りすることができませんでした。

RoCEv2ではInfiniBandパケットをUDPヘッダーでカプセル化しているため、IPベースでルーティング可能です。そのため別セグメント間でもRDMAトラフィックをやり取りすることが可能となりました。

画像引用：https://enterprise-support.nvidia.com/s/article/roce-v2-considerations#jive_content_id_What_is_the_RoCE_V2_packet_format

上図のとおり、Infinibandプロトコル（IB)をイーサネットでカプセル化することでRDMAをイーサネットで運べるようしたのがRoCEの仕組みとなりますが、RDMAの性能を維持するために必要なロスレスネットワークをイーサネットで提供するにはどうすればよいのでしょうか。

その答えがRoCEv2のCE部分、すなわちConverged Ethernetの中に隠されています。

Converged Ethernetが提供する輻輳通知機能

Converged Ethernetという言葉にピンとこない方も多いと思いますが、Converged Ethernetとは複数のネットワークトラフィックを1つのイーサネットネットワークで収容することができる技術であり、FCoE（Fibre Channel over Ethernet）で採用されたことで注目されました。

FCoEは結果としてあまり流行りませんでしたが、RDMAをイーサネットに乗せるRoCEの登場によりConverged Ethernetは再び脚光を浴びている状況です。

RoCEv2では、Converged Ethernetの枠組みを利用し、輻輳が発生した際にパケットのロスを防ぐための仕組みとして、ECN（Explicit Congestion Notification）とPFC（Priority-based Flow Control）という機能を使います。

それではConverged Ethernetの中身であるECNやPFCの概要をそれぞれ見ていきましょう。

ECN

ECN（Explicit Congestion Notification）は、通信における輻輳（congestion）を管理するための重要な仕組みです。通常、スイッチやルーターなどのネットワーク機器は、通過するパケットを処理するために一時的に情報を保存するバッファを持っています。しかし、トラフィックが集中し、このバッファがあふれてしまうとパケットが破棄されてしまいます。

そこで、ECNではバッファが溢れそうになったときに、通過するパケットに特別なマークを付けて送り出します。このマークは、パケットが通過する途中の経路で輻輳が発生していることを示すものです。受信側はこのマークを受け取ることで、途中経路の輻輳発生を知ることができます。

そして、受信側はCNP(Congestion Notification Packet)という制御パケットを送ることで送信側に輻輳が発生していることを伝えます。送信側はCNPを受信している間は送信量を抑制する動きをとることでネットワークの輻輳状態を解消することができます。つまり、ECNではネットワーク機器、送信側(Client)と受信側(Server)の3者が連携して輻輳回避を行います。

PFC

PFC（Priority Flow Control）は、イーサネットの基本的な機能であるフローコントロールの改良版です。フローコントロールでは、バッファがあふれそうになったらPauseフレームを出して送信側に送信を一時停止してもらいますが、従来型のフローコントロールではすべての通信に対してPauseフレームを返すため、優先度関係なく通信を止めてしまいます。

PFCはこの問題を解決するため、優先度を考慮できるように設計されています。輻輳時に破棄（Drop）されては困る通信には明示的にPauseフレームを送り、送信側にストップをかけますが、優先度が低く破棄されてもかまわない通信にはPauseを送りません。これにより、重要な通信のパケットロスを防ぎ、ネットワーク全体のパフォーマンスが向上します。

ECNとPFCの動作はいずれも単純に輻輳通知を行うことになります。しかし、重要なのは、この輻輳通知を受け取ったRoCEv2クライアントとサーバがそれを理解し、協調してRoCEv2クライアントからの送信を一時停止することです。これによって、ネットワークでのパケットロスを防止することができます。

RoCEv2をサポートするロスレスイーサネット検証

弊社は複数ベンダーのネットワーク機器を取り扱っておりますので、A社、B社、C社、D社のそれぞれの機器にECN/PFCを設定し、そこにRoCEv2トラフィックを流してみました。今回はその概要をご紹介します。

上図のようにデータセンタースイッチを2台並べ、4台のClientからそれぞれ25GbpsでRoCEv2とhttpトラフィックを印加し、RoCEv2 Server接続ポート(25G)にトラフィックを集中させることで輻輳状態を意図的に作ります。

今回の検証では実際に複数台のRoCEv2端末を用意するのではなく、信頼性の高い業界標準トラフィックテスターであるキーサイトの「Data Center Storage 100GE Test Load Module」(※1)を利用し、疑似的にRoCEv2 ClientとServerを用意しました。

ClientはRoCEv2トラフィックに対してあらかじめCos値(今回は3)をつけて流します。

スイッチ側でECNやPFCを有効にしない状態ではServer接続ポートでバッファが溢れてしまいRoCEv2、http共にパケットドロップが発生します。下記showコマンドではqueue1にhttp、queue3にRoCEv2が入っており、それぞれでDropが発生していることが確認できます。

次に、サーバ接続ポートでECNを有効にします。ECNはQoSと連携することで指定したqueueに入ったパケットに対してenableにできます。

すると、queue3に入ったRoCEv2トラフィックのDropはきれいに無くなりました。

RoCEv2 Client側ではCNPパケットを受信していることが確認できました。

次に、PFCを有効にして同様の試験を実施しました。

結果としてはECNと同様にRoCEv2トラフィックのドロップは発生せず、Client側ではポーズフレームを受信していることを確認できました。

最後に、ECNとPFCを両方設定したパターンを試してみました。

結果は、RoCEv2トラフィックのドロップは発生せず、Client側ではCNPの受信を確認しました。ポーズフレームはカウントアップしませんでしたが、稀に受信することがありました。一般的にECNとPFCは併用することがベストプラクティスとされており、併用時においてはPFCよりもECNの動作が優先されます。今回の検証でも期待通りの結果となりました。

まとめ

AIの進化と普及に伴い、AI用のクラスタがこれから急速に増えていくことは容易に想像できます。この動向は、AIに適したネットワークの重要性を一層高めています。イーサネットの高速化（現在の400Gから800G、さらには1.6Tへと進化していく）と、RoCEv2のイーサネットベースという特性（多くのエンジニアにとって親しみやすい技術であり、既存のネットワークインフラとの互換性もある）を考えると、RoCEv2はAIクラスタのネットワークにおける重要な役割を果たすことが期待できます。

今回はRoCEv2のConverged Ethernet部分に焦点を当て、ロスレスイーサネットについての仕組みと動作についてのご紹介でした。

謝辞

※1

今回の検証を行うに当たり、「Data Center Storage 100GE Test Load Module」の貸出しや技術的サポートを頂きましたキーサイト・テクノロジー株式会社に感謝申し上げます。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

お問い合わせはこちら