> [!abstract] 概要(Abstract 全訳) > 過去 1 年半にわたり、我々は commodity Ethernet 上の RDMA(RoCEv2)を用いて、Microsoft の高信頼・低レイテンシ要求サービスの一部を支えてきた。本論文はその過程で遭遇した課題と、それに対処するために考案した解決策を記述する。RoCEv2 を VLAN の枠を超えて拡張するため、我々は大規模展開を確実にする DSCP ベースの優先度フロー制御(PFC)機構を設計した。PFC 起因のデッドロック(実際に発生した!)・RDMA トランスポートのライブロック・NIC の PFC ポーズフレームストーム問題という安全課題に対処した。RDMA が期待どおり動作することを保証するため、監視・管理システムも構築した。我々の経験は、大規模で RoCEv2 を運用する際の安全性・スケーラビリティの課題がすべて解決可能であり、データセンタ内通信において RDMA が TCP を置き換え、低レイテンシ・低 CPU オーバーヘッド・高スループットを達成できることを示している。 ## 論文情報 - タイトル: RDMA over Commodity Ethernet at Scale - 著者・所属: Chuanxiong Guo・Haitao Wu・Zhong Deng・Gaurav Soni・Jianxi Ye・Jitendra Padhye・Marina Lipshteyn(全員 [[Microsoft]]) - 媒体・発表年: ACM SIGCOMM 2016(2016-08-22〜26、Florianópolis, Brazil) - DOI: [10.1145/2934872.2934908](https://doi.org/10.1145/2934872.2934908) ## 概要 Chuanxiong Guo・Haitao Wu・Zhong Deng・Gaurav Soni・Jianxi Ye・Jitendra Padhye・Marina Lipshteyn(すべて [[Microsoft]])による SIGCOMM 2016 論文。Microsoft のデータセンタ全体への RoCEv2(RDMA over Converged Ethernet v2)大規模展開の実体験をまとめた、業界での RoCEv2 本番化の先駆的報告である。DSCP ベースの PFC 設計に加え、4 つの安全課題の発見と解決、専用の監視・管理システムの構築、5 段階の漸進的展開手順を報告し、本番環境での定量的な性能改善(レイテンシ・スループット・CPU 使用率)を実証した。 ## 問題設定 TCP/IP はデータセンタネットワーク(DCN)の主流プロトコルスタックだが、新世代の DC ワークロードの要求を満たせなくなりつつある。理由は 2 点。第一に、チェックサムオフロード・LSO・RSS・割り込みモデレーションなどのハードウェア/ソフトウェア最適化を施してもなお、OS カーネルでのパケット処理の CPU オーバーヘッドが高い。実測では、32 コアの Intel Xeon E5-2690(Windows 2012R2)サーバで 8 本の TCP コネクションを使い 40Gb/s で送信すると集計 CPU 時間の 6%、受信では 12% を消費する。第二に、Search など多くの DC アプリケーションはレイテンシに敏感だが、TCP は平均トラフィック負荷が中程度でも低レイテンシを提供できない。カーネルソフトウェアが数十ミリ秒に達しうるレイテンシを持ち込むことに加え、輻輳による稀ながら存在するパケットロスからの回復(タイムアウトや高速再送)がアプリケーションレイテンシを悪化させるためである。 本論文が対象とするデータセンタネットワークは、Ethernet ベースの多層 Clos ネットワークである。20〜40 台のサーバが ToR(Top-of-Rack)スイッチに接続し、数十台の ToR が Leaf スイッチ層に、Leaf スイッチが数十〜数百台の Spine スイッチ層に接続する。大半のリンクは 40Gb/s で、将来的に 50GbE・100GbE への更新を計画する。サーバ〜ToR は約 2m の銅線ケーブル、ToR〜Leaf は 10〜20m、Leaf〜Spine は 200〜300m の距離である。この 3 層構成で、単一データセンタ内に数万〜数十万台規模のサーバを接続できる。本論文は Spine スイッチ層配下(同一 Spine 層)のサーバ間の RDMA サポートに焦点を当てる。 **Figure 1: 本論文が対象とする Clos ネットワークトポロジ** ![[_attachments/rdma_sigcomm2016/fig01-clos-topology.png]] (Figure 1. Our goal is to support RDMA for intra data center (intra-DC) communications. ToR・Leaf・Spine の 3 層 Clos 構成と、ToR〜Leaf 間 10-20m、Leaf〜Spine 間 200-300m という距離、および Inter-DC ネットワークとの境界を示す。) RDMA(Remote Direct Memory Access)はリモートシステムの CPU 処理を中断せずにそのメモリへアクセスする技術であり、HPC 分野では InfiniBand を基盤として広く使われてきた。RoCEv2 は RDMA を InfiniBand ではなく Ethernet 上で実現する。RoCEv2 は RDMA トランスポートパケットを Ethernet/IPv4/UDP パケットにカプセル化するため、既存のネットワークインフラと互換性を持つ。UDP ヘッダは ECMP ベースのマルチパスルーティングのために必要で、宛先 UDP ポートは常に 4791 に固定され、送信元 UDP ポートはキューペア(QP)ごとにランダムに選ばれる。中間スイッチは標準的な 5-tuple ハッシュを使うため、同一 QP のトラフィックは同一経路をたどるが、同じ通信端点間でも異なる QP のトラフィックは異なる経路をたどりうる。 RDMA は TCP と異なりロスなしネットワークを前提とする。RoCEv2 はこれを PFC(Priority-based Flow Control)で実現するが、PFC には head-of-the-line ブロッキングやデッドロックの可能性といった既知の問題がある一方、本論文が本番展開で遭遇した RDMA トランスポートライブロック・NIC PFC ポーズフレームストーム・スローレシーバー症状は文献に報告されていなかった。デッドロック自体も、研究文献で議論される単純化された例とは根本原因が大きく異なっていた。 **Figure 2: PFC の動作機構** ![[_attachments/rdma_sigcomm2016/fig02-pfc-mechanism.png]] (Figure 2. How PFC works. Egress port の 8 キュー(p0〜p7)から Ingress port へデータパケットを送り、Ingress 側のキュー長が XOFF 閾値を超えると該当優先度に PFC pause frame を Egress 側へ送り返す仕組みを示す。) PFC はホップバイホップのプロトコルであり、送信元から宛先までに複数ホップが存在しうる。持続的な輻輳がある場合、PFC ポーズフレームは輻輳点から送信元へ向けて伝播し、不公平性や victim flow といった問題を引き起こしうる。この副次被害を軽減するため、QCN・DCQCN・TIMELY といったフローベースの輻輳制御が導入されており、本論文の環境では ECN による輻輳通知を用いる DCQCN を採用している。DCQCN は中間スイッチのキュー長に直接反応でき、使用する全スイッチが ECN をサポートするために選ばれた。DCQCN は PFC ポーズフレームの生成・伝播確率を減らすが、パケットドロップからパケットを守る最後の防衛線は依然として PFC であり、PFC が抱える安全課題が本論文の主要な焦点となる。また本論文において RDMA は DC 内通信向けに設計されており、DC 間通信やレガシーアプリケーションには従来どおり TCP を用いる(ロスなしでない別のトラフィッククラスで帯域を確保)。 ## 提案手法 ### DSCP-based PFC VLAN ベースの PFC は、パケット優先度を VLAN タグの PCP(Priority Code Point)値で運ぶ。VLAN タグは PCP と VID(VLAN ID)を分離できないため、PFC をサポートするにはサーバ側・スイッチ側の双方で VLAN を設定する必要があり、サーバ向きスイッチポートをトランクモード(VLAN タグ付きパケットに対応)にしなければならない。これが 2 つの深刻な問題を生んだ。 1. **PXE ブート不能**: OS プロビジョニング(PXE ブート)中の NIC は VLAN 設定を持たないため VLAN タグなしパケットしか送受信できないが、スイッチポートはトランクモードで VLAN タグ付きパケットしか通さない。この不整合により PXE ブートと OS プロビジョニングサービス間の通信が破綻した。スイッチにサーバの推定状態に応じてポート設定を変更させる、NIC に VLAN タグの有無を問わず全パケットを受理させるといった複数の「ハック」を試みたが、いずれも複雑で信頼性を欠き、非標準的だった。 2. **Layer-3 越境でのプライオリティ消失**: レイヤ 3 IP フォワーディングへ移行した結果(スケーラビリティ・管理性・監視性・安全性のため)、サブネット境界を越える際に VLAN の PCP 値を保持する標準的な方法が存在しない。 根本原因は、VLAN ベースの PFC がパケット優先度と VLAN ID を不必要に結合していることにある。PFC ポーズフレーム自体は VLAN タグを持たない。IP の世界にはパケット優先度を運ぶ標準的でより良い方法、すなわち IP ヘッダの DSCP(Differentiated Services Code Point)フィールドが存在する。 **Figure 3: PFC パケットフォーマットの比較** ![[_attachments/rdma_sigcomm2016/fig03a-vlan-based-pfc-format.png]] (Figure 3(a). VLAN-based PFC のパケットフォーマット。PFC pause frame(DMAC 01-80-C2-00-00-01・EtherType 88-08 の制御パケット)と、VLAN TAG 内の PCP フィールドで優先度を運ぶデータパケットを示す。) ![[_attachments/rdma_sigcomm2016/fig03b-dscp-based-pfc-format.png]] (Figure 3(b). DSCP-based PFC のパケットフォーマット。PFC pause frame の形式は (a) と同一のまま変更せず、データパケット側は VLAN TAG を持たず IP ヘッダの DSCP フィールドで優先度を運ぶ。) 解決策として **DSCP-based PFC** を設計した。データパケットの優先度情報を VLAN タグから IP ヘッダの DSCP フィールドへ移し、PFC ポーズフレーム自体(レイヤ 2 フレーム)は変更しない。この変更によりデータパケットは VLAN タグを不要とし、サーバ向きポートはトランクモードである必要がなくなるため PXE ブート問題は解消し、DSCP 値による優先度情報は IP ルーティングを跨いで正しく伝播する。DSCP-based PFC はレイヤ 2 に留まる必要がある設計(FCoE 等)には適用できないが、対象データセンタにレイヤ 2 ネットワークは存在しないため問題にならない。スイッチと NIC は内部的に 8 つの Priority Group(PG)を保持し、各 PG をロスレス/ロッシーに設定できる。あるロスレス PG の入力バッファ占有率が XOFF 閾値を超えると該当優先度のポーズフレームが生成される。実装では DSCP 値 i を PFC 優先度 i にそのまま対応づけている(many-to-one も可能な柔軟なマッピング)。このため我々の DSCP-based PFC 仕様は公開され、Arista Networks・Broadcom・Cisco・Dell・Intel・Juniper・Mellanox など主要ベンダーすべてに対応している。ToR・Leaf スイッチのバッファは浅い(9MB または 12MB)ため、8 つのトラフィッククラスのうち実際にヘッドルームを確保できるのは 2 クラスのみであり、リアルタイムトラフィック用とバルクデータ転送用にそれぞれ 1 クラスずつを割り当てている。 ### 4 つの安全課題 #### RDMA トランスポートライブロック RoCEv2 は損失なしネットワークを前提とするため、NIC の RDMA トランスポートはシンプルな **go-back-0** リトランスミッションを採用していた。2 台のサーバ A・B をスイッチ W 経由で接続し、A から B への RDMA SEND・WRITE、および B から A への RDMA READ の 3 実験を実施。スイッチを IP ID の下位バイトが 0xff のパケットをドロップするよう設定したところ(NIC が IP ID を逐次生成するため、ドロップ率は決定論的に 1/256 ≈ 0.4%)、この低いパケットロス率でもアプリケーションレベルの goodput がゼロになるライブロック状態を確認した。リンクはライン速度で完全に利用されているにもかかわらず、アプリケーションは一切進捗しない状態である。 根本原因は go-back-0 にある。4MB メッセージは 4000 パケットに分割され、先頭 256 パケットのうち必ず 1 つがドロップされる決定論的なパターンのもとで、B は NAK(i) を送り A は常にパケット 0 から再送を開始するため、いつまでも先頭パケットからやり直し続け進捗しない。TCP は best-effort ネットワークを前提に SACK のような高度な再送スキームを備えるが、RDMA はロスなしネットワークを前提に単純な go-back-0 を選んだためにこの問題が生じた。 **解決策**: go-back-0 を **go-back-N** に変更。最初のドロップパケットから再送を開始し、それ以前に受信済みのパケットは再送しない。go-back-N は RTT×C バイト(C はリンク容量)が 1 回のパケットドロップで無駄になりうる点で理想的ではないが、go-back-0 とほぼ同程度に単純でライブロックを回避できる。NIC ベンダーと協力して実装し、以来ライブロックを一件も観測していない。RDMA トランスポートは go-back-N を実装すべきであり go-back-0 を実装すべきでないと推奨する。 #### PFC デッドロック Clos ネットワークの up-down ルーティングは、送信元から宛先までのパケットが共通祖先まで登ってから下る構造を持つため循環バッファ依存が生じずデッドロックフリーだと信じられてきた。しかし、テストクラスタでのストレステスト中に実際に PFC デッドロックが発生した。 原因は **PFC と Ethernet パケットフラッディングの予期しない相互作用**である。ToR スイッチは宛先 IP パケットを転送する際、ARP テーブル(MAC アドレスを特定)と MAC アドレステーブル(物理ポートを特定)の 2 つを参照する。ARP テーブルのタイムアウトは 4 時間(ARP パケットによりスイッチ CPU が更新するためコスト高)、MAC アドレステーブルのタイムアウトは 5 分(ハードウェアが自動更新するためコスト低)と大きく異なる。この不一致により、ARP エントリは存在するが対応する MAC アドレステーブルエントリが存在しない「不完全 ARP」状態が生じうる。この状態宛てのパケットが届くと、スイッチは受信ポート以外の全ポートへパケットをフラッディングする(標準的な Ethernet の挙動)。 **Figure 4: PFC デッドロックの発生例** ![[_attachments/rdma_sigcomm2016/fig04-pfc-deadlock-example.png]] (Figure 4. An example to show that the interaction between Ethernet packet flooding and PFC pause frame propagation can cause deadlock. S1→S3(紫、経路 {T0,La,T1,S3})・S1→S5(黒、経路 {T0,La,T1,S5})・S4→S2(水色、経路 {T1,Lb,T0,S2})の 3 フローについて、S3・S2 が死んでいるためのフラッディングと、La・Lb・T0・T1 間の PFC ポーズフレーム循環(①〜④)がデッドロックを形成する過程を示す。) 論文の例では、S1 が S3(死亡)と S5 へ送る際に La・T1 間でフラッディングとキュー詰まりが発生し、T1→La→T0→S1 という逆方向のポーズフレーム連鎖が生じる。同時に S4 が S2(死亡)へ送るフラッディングが T1→Lb→T1 のポーズフレーム連鎖を作り、両者が合わさって La・Lb・T0・T1 の 4 スイッチ間で PFC ポーズフレームの循環ループが形成され、デッドロックが成立する。一度発生すると全サーバを再起動してもデッドロックは解消しない。これは既知の循環バッファ依存(cyclic buffer dependency)の一種だが、原因はスイッチのフラッディング挙動という「新しい」ものだった。 **解決策**: 不完全 ARP エントリに対応するロスレスパケットをドロップする(3 つの選択肢のうち最終的にオプション 3 を採用)。オプション 1(スイッチ CPU に処理を委譲)は CPU オーバーヘッド増大、オプション 2(ARP/MAC テーブルタイムアウトの整合)は ARP オーバーヘッド増大または障害検知の遅延というトレードオフを伴うため、循環バッファ依存を直接防ぐオプション 3 を選んだ。ここから得た教訓は、ブロードキャストとマルチキャストはロスレスネットワークにとって危険であり、ロスレスクラスに入れるべきではないというものである。 #### NIC PFC ポーズフレームストーム NIC の受信パイプラインにバグがあり、パイプラインが受信パケットの処理を停止すると受信バッファが満杯になり、NIC が常時ポーズフレームを送出し続ける現象(**NIC PFC ストーム**)が生じた。単一 NIC の故障が ToR→Leaf→Spine→全 ToR という連鎖でネットワーク全体を麻痺させうる。 **Figure 5: NIC PFC ストームの伝播** ![[_attachments/rdma_sigcomm2016/fig05-nic-pfc-storm-propagation.png]] (Figure 5. The PFC pause frame storm caused by the malfunctioning NIC of one single server (server 0). Podset 0 の server 0 の故障 NIC が発した継続的なポーズフレームが ToR→Leaf→両 Podset の Spine 層→全 Leaf→全 ToR→全サーバへと連鎖的に伝播する経路を赤矢印で示す。) **解決策**: 2 つのウォッチドッグ。 - **NIC 側ウォッチドッグ**: NIC のマイクロコントローラが受信パイプラインの停止を 100ms(デフォルト)以上検出すると、ポーズフレームの生成を無効化する。NIC がストームモードに入ると自力での復帰は期待できないため、NIC ウォッチドッグの目的はサーバ救済ではなくネットワーク全体への被害拡大の防止にある。NIC PFC ストームは典型的にはサーバ再起動で解消するため、データセンタ管理システムが再起動・再イメージ化などの修理を試みるが、修理には数十分を要する。NIC ウォッチドッグはこの修理が完了するまでの間、被害を数百ミリ秒に限定する。 - **ToR スイッチ側ウォッチドッグ**: サーバ向きポートが排出不能なパケットをキューし、同時に NIC から継続的なポーズフレームを受信している場合、スイッチは該当ポートのロスレスモードを無効化しロスレスパケットを破棄する。ポーズフレームの消失を 200ms(デフォルト)検出すると自動的にロスレスモードを再有効化する。 両ウォッチドッグは相補的であり、単体でも NIC PFC ストームを止められるが二重の保険として両方を実装した。NIC ウォッチドッグはポーズフレームの生成そのものを止めるため一度無効化すると再有効化しないのに対し、スイッチウォッチドッグはポーズフレーム消失時に自動で再有効化する点が異なる。両ウォッチドッグ導入後、本番で NIC PFC ストームを再発していない。両者を実装することを推奨する。 #### スローレシーバー症状 サーバ NIC は QPC(Queue Pair Context)・WQE(Work Queue Element)などのデータ構造をサーバのメインメモリに置き、NIC 内の小容量メモリをキャッシュとして使う。仮想メモリ〜物理メモリ変換を担う **MTT(Memory Translation Table)** はエントリ数 2K で、4KB ページサイズでは 8MB しかカバーできない。WQE の仮想アドレスが MTT にマップされていないとキャッシュミスが発生し、NIC はサーバのメインメモリへアクセスして新しいエントリを取得する必要があり、受信パイプラインが待たされる。MTT キャッシュミスが頻発すると受信パイプラインが遅延し、受信バッファ占有率が PFC 閾値を超えて NIC が不要なポーズフレームを生成し、ネットワークへ波及する。40GbE NIC は PCIe Gen3x8(64Gb/s 双方向)を使い NIC 帯域(40Gb/s)を上回るため、当初はスイッチ・サーバ間にボトルネックはないと想定していたが、実際には多くのサーバが毎秒数千のポーズフレームを生成しうることを観測した。 **緩和策**: (1) NIC 側でページサイズを 4KB から 2MB へ変更し MTT ミス頻度を減少。(2) スイッチ側で動的バッファ共有(dynamic buffer sharing)を有効化。静的バッファ確保に比べ、パラメータ α(共有バッファプールからの確保条件 α×UB > B_p,i を満たす場合に確保可能。UB は未割り当て共有バッファサイズ、B_p,i はポート p・トラフィッククラス i の確保済みバッファサイズ)を適切に設定することで、輻輳時のバッファ確保を統計的に増大させ PFC ポーズフレーム伝播を抑制しつつ帯域利用率を改善した。 ### 管理・監視システム **設定監視**: スイッチとサーバが期待どおりの設定で動作しているかを確認するサービスを構築。スイッチ側は PFC 設定(グローバルなバッファ確保・DSCP 値によるトラフィック分類・キューマッピング・帯域予約と、ポート単位の PFC 有効化)、サーバ側は RoCEv2・PFC・DCQCN・トラフィックの各設定(宛先トランスポートポートに基づく PFC 保護対象の指定)を対象とし、複数のスイッチ種類・ファームウェアバージョン・顧客ごとの異なる設定要件の複雑さを吸収する。 **PFC ポーズフレームとトラフィック監視**: スイッチとサーバが送受信したポーズフレーム数を監視し、サーバ側でポーズ間隔も監視する。ポーズ間隔はポーズフレーム数より輻輳の深刻度を正確に反映するが、スイッチ側では現時点で非対応のため、ASIC ベンダーに将来実装を要求した。RDMA トラフィック監視では、ポート・優先度ごとのパケット/バイト数、イングレスポート・イーグレスキューでのドロップ数を収集し、RDMA トラフィックは通常ドロップされないという前提のもと異常検知に利用する。 **RDMA Pingmesh**: 既存の TCP Pingmesh サービスの RDMA 版として実装。512 バイトのペイロードで各サーバに RDMA プローブを送り、ToR・Podset・データセンタの各粒度で RTT(または失敗時はエラーコード)を記録する能動レイテンシ計測システム。この測定結果から RDMA が正常に動作しているかを推定できる。この監視・管理システムは、設定・カウンタ・エンドツーエンドレイテンシに焦点を当てる実用的なアプローチであり、著者らは将来の 100G 以上のネットワークにも有効と見込む一方、高速化と NIC オフロードによりパケットレベル監視は今後の課題として残ると述べる。 ## 新規性 RoCEv2/PFC 自体の head-of-the-line ブロッキングやデッドロックの可能性は既知だったが、本論文が報告する RDMA トランスポートライブロック・NIC PFC ポーズフレームストーム・スローレシーバー症状は先行文献で報告されていなかった新規の障害モードである。デッドロックについても、遭遇した根本原因(ARP テーブルと MAC アドレステーブルのタイムアウト値の不一致に起因する Ethernet パケットフラッディングと PFC の相互作用)は、研究文献で議論される単純化されたトイ例とは大きく異なる。また、著者らの知る限り本論文発表時点で大規模な RoCEv2 展開の前例はなく、DSCP-based PFC による VLAN 依存からの脱却、4 つの安全課題の系統的な解決、専用監視・管理システムの構築、5 段階の漸進的展開プロセスを一体として提示した点が、Infiniband(専用ネットワーク)や iWarp(TCP/IP をオフロード)と異なり commodity Ethernet 上で RoCEv2 を大規模かつ安全に運用できることを初めて実証した貢献である。 ## 実験設定 - **ライブロック再現実験**: サーバ A・B をスイッチ W 経由で接続する小規模テストベッド。スイッチは IP ID 下位バイト 0xff のパケットをドロップするよう設定し、決定論的ドロップ率 1/256(0.4%)を再現。RDMA SEND・WRITE・READ の 3 パターンで検証。 - **本番レイテンシ比較**: 20K サーバ規模の本番データセンタ 1 拠点で、高信頼・低レイテンシのオンラインサービスにおいてトラフィックの半分を TCP、半分を RDMA として同時計測。RTT は Pingmesh により測定。ピークトラフィックはサーバあたり約 350Mb/s、集計 CPU 負荷は 20〜30%。 - **スループット実験**: データセンタがオンライン化後・顧客提供前(顧客トラフィックなし)の 3 層 Clos ネットワークで実施。2 つの Podset(各 4 Leaf・24 ToR・576 サーバ、ToR/Leaf のオーバーサブスクリプション比 6:1・3:2、Podset〜Spine 間集約帯域 2.56Tb/s)を使用。ToR-to-ToR でペアリングし、各 ToR から選んだ 8 台のサーバが対向 Podset の対応サーバへ 8 本の RDMA コネクションを確立(合計 3074 コネクション、128 本の Leaf-Spine リンクがボトルネック)、全コネクションが可能な限り高速にデータを送信。 - **レイテンシ・スループットのトレードオフ実験**: 2 層テストベッド(ToR 2 台、各 24 サーバ、各 ToR は 4 本のアップリンクで 4 台の Leaf スイッチに接続、オーバーサブスクリプション比 6:1、全リンク 40GbE)。各 ToR から 20 台のサーバを選びペアリングし、各サーバペアが 8 本の RDMA コネクションを確立。レイテンシは RDMA Pingmesh で測定。 ## 実験結果 ### レイテンシ削減 **Figure 6: TCP と RDMA のレイテンシ比較** ![[_attachments/rdma_sigcomm2016/fig06-tcp-rdma-latency-comparison.png]] (Figure 6. The comparison of the measured TCP and RDMA latencies for a latency-sensitive service. 2015-07-13〜07-23 頃の期間、RDMA の 99 パーセンタイル(薄青)・99.9 パーセンタイル(濃紺)レイテンシは概ね 100〜200µs 台で安定して推移する一方、TCP の 99 パーセンタイル(赤)は平常時 700µs 付近で推移しつつ、複数回 3000〜6600µs 級のスパイクを記録する。) 99 パーセンタイルレイテンシは RDMA **90µs** に対し TCP **700µs** で、TCP は数ミリ秒級のスパイクを記録した。RDMA の 99.9 パーセンタイルも約 200µs にとどまり、TCP の 99 パーセンタイルを下回った。ネットワーク自体はボトルネックではなく(容量は数 Gb/s)、多対一の incast トラフィックパターンによるバースト性があったにもかかわらず、この差はカーネルスタックオーバーヘッドの除去と(RDMA 側の)ゼロパケットロスによって達成された。 ### スループット **Figure 7: 3 層 Clos ネットワークにおけるスループット実験** ![[_attachments/rdma_sigcomm2016/fig07a-throughput-topology.png]] (Figure 7(a). The network topology. 各 Podset は 4 台の Leaf(L0〜L3)と 24 台の ToR(T0〜T23)から成り、Leaf は上位の 16 台の S サーバ群(S^A〜S^D、各 16 台)に接続する構成を示す。) ![[_attachments/rdma_sigcomm2016/fig07b-aggregate-throughput.png]] (Figure 7(b). The aggregate RDMA throughput in a three-layer Clos network(y 軸は frames/sec、フレームサイズ 1086 バイト)。2015-02-27 の実験開始直後にスループットが急上昇し、以降 3.0Tb/s 付近で安定して推移する。) 集計スループットは **3.0Tb/s** で、Podset〜Spine 間の全容量 5.12Tb/s に対し **60%** の利用率を達成した。実験を通じてパケットドロップはゼロで、各サーバの送受信は 8Gb/s、CPU 使用率は 0% に近かった。60% という上限は、ECMP を用いるマルチパスルーティングにおけるハッシュ衝突に起因するものであり、PFC や head-of-the-line ブロッキングは要因ではない(シミュレーションおよび PFC を使わない先行研究 [2] でも同様の利用率が報告されている)。 ### レイテンシとスループットのトレードオフ **Figure 8: RDMA レイテンシの立ち上がり** ![[_attachments/rdma_sigcomm2016/fig08-latency-throughput-tradeoff.png]] (Figure 8. The end-to-end RDMA latency jumped up as the experiment started and network throughput increased. 実験開始時刻(Experiment start time)を境に、RDMA の 99 パーセンタイル(暗赤)・99.9 パーセンタイル(緑)レイテンシがそれぞれ約 50µs→400µs、約 80µs→800µs へ跳躍する一方、TCP の 99 パーセンタイル(青、ほぼ横ばい)は変化しない。) 実験開始と同時に、RDMA のレイテンシは 99 パーセンタイルで 50µs から 400µs へ、99.9 パーセンタイルで 80µs から 800µs へ跳躍した。TCP と RDMA は異なるキューに割り当てられているため TCP の 99 パーセンタイルレイテンシ(500µs、Figure 6 の 700µs とは実サービス負荷の有無による差)はこの間変化していない。すなわちレイテンシの増加は、RDMA トラフィック自身が生む輻輳によるものである。この結果は、RDMA は OS カーネルバイパスとパケットドロップ排除により低レイテンシ・高スループットを実現するが、万能薬ではなくネットワークが輻輳しキューが蓄積すればレイテンシは増加しうることを示す。 ### 展開プロセス 5 段階の漸進的展開を実施した。 1. 数十台規模の小規模ラボネットワークで初期バグを排除。 2. 本番と同一の構成・管理体制のテストクラスタで RoCEv2 の成熟度を向上。 3. ToR レベルのみで本番投入。 4. Podset レベル(ToR + Leaf)で PFC を有効化。 5. Spine スイッチまで PFC を拡張。 RDMA トランスポートライブロックと大半のバグはラボテストで検出され、PFC デッドロックとスローレシーバー症状はテストクラスタで検出された。本番ネットワークに到達したのは NIC PFC ポーズフレームストームとごく少数のバグのみだった。テストクラスタと本番で同一の管理・監視システムを用いたことが、テストクラスタの管理品質向上と RoCEv2・監視系双方の事前検証の両面で有効に機能した。 ### インシデント事例 **Figure 9: NIC PFC ストームによるインシデント** ![[_attachments/rdma_sigcomm2016/fig09a-server-availability.png]] (Figure 9(a). Server availability reduction. H(healthy)・F(failing)・P(probation)の各状態を示す。2015-11-02 16 時台に H(緑)が急減し F(赤)が急増する様子を示す。) ![[_attachments/rdma_sigcomm2016/fig09b-pfc-pause-frames-nic-storm.png]] (Figure 9(b). The PFC pause frames received by the servers(5 分間隔)。同時刻に PFC pause frame 受信数が最大 68,000 件超まで急増する様子を示す。) 顧客のサービス可用性問題として顕在化した事例。多数のサーバが不可用状態になり(Figure 9(a))、同時に多くのサーバが継続的に大量の PFC ポーズフレームを受信していた(Figure 9(b))。原因は単一サーバに追跡され、そのサーバはデータパケットを一切送受信しない不応答状態(Failing)だった。パワーサイクル(電源再投入)後、サーバは復帰しポーズフレームは消失した。NIC PFC ストームの発生頻度は極めて低く(数十万台規模の本番環境で単桁件数)、それでも被害はポーズフレーム伝播により顧客サーバの半数を非健全状態に陥れるほど大きかった。両ウォッチドッグ導入後は NIC PFC ストームを経験していない。 **Figure 10: スイッチバッファ設定ミスによるインシデント** ![[_attachments/rdma_sigcomm2016/fig10a-latency-increase-buffer-misconfig.png]] (Figure 10(a). Services latency increase caused by the PFC pause frame propagation。2015-07-12(日)22 時台以降、複数サービスの 95 パーセンタイルレイテンシが軒並み跳ね上がる様子を示す(色ごとに異なるサービスを表す)。) ![[_attachments/rdma_sigcomm2016/fig10b-pfc-pause-frames-buffer-misconfig.png]] (Figure 10(b). The PFC pause frames received by the servers。同日 22〜23 時台に受信ポーズフレーム数が最大約 60,000 件/5 分まで急増する様子を示す。) 2015 年 7 月 12 日深夜、多くの低レイテンシサービスのレイテンシが急増するインシデントが発生した。同時に複数のサーバが大量の PFC ポーズフレーム(5 分間で最大 60,000 件)を受信していた。原因は 2 台の ToR スイッチにさかのぼり、要因は 2 つ。第一に、これら ToR がホストする「おしゃべりな」サーバが 1,000 台超のサーバへ同時にクエリを送り、応答の incast が輻輳を生んでいた。第二に、同一ベンダーの新型 ToR スイッチのダイナミックバッファ共有パラメータ α のデフォルト値が、既存機種の 1/16 から 1/64 に変更されていたため、輻輳時に確保されるバッファが大幅に小さくなり PFC ポーズフレームがより容易に発生していた。トラフィックパターンは変更できないため、α を 1/16 に戻すことで対処した。教訓は、PFC ポーズフレームは実際に伝播し本番環境に副次被害をもたらすこと、そのためポーズフレームの生成自体を(NIC PFC ストーム対策・スローレシーバー対策・動的バッファ共有・フローごとの DCQCN 輻輳制御によって)減らす必要があるということである。 ## 考察 3 年間の RoCEv2 設計・構築・展開を通じて得られた教訓は次の 4 点に整理される。 - **理論上正しい設計も本番では予期しない問題が起きる**: Clos トポロジの up-down ルーティングにより循環バッファ依存もデッドロックも存在しないと信じていたにもかかわらず PFC デッドロックに遭遇し、スローレシーバー症状や RDMA トランスポートライブロックも事前に予見できなかった。設計を検証し想定外の側面を方法論的に洗い出すには、入念に設計された実験・テストクラスタ・段階的な本番展開が必要である。 - **NIC がボトルネック**: RDMA/RoCEv2 のバグの大半は、PFC 実装が比較的単純でテスト済みなスイッチ側ではなく、RDMA verbs やトランスポートプロトコルという最も複雑な部分を実装し、かつサーバの DRAM をキャッシュ元とするリソース制約下にある NIC 側に由来していた。 - **管理・監視は最初から必須**: プロジェクト開始当初から RDMA/RoCEv2 の管理・監視をプロジェクトの不可欠な一部と位置づけ、顧客が RDMA を使い始めた時点で監視系はすでに本番運用されていた。この体制が Section 6.2・Section 4 で示したバグ・インシデントの検知・箇所特定・根本原因分析に不可欠だった。 - **ロスレスネットワークは低レイテンシを保証しない**: PFC によりロスレスネットワークを構築でき、実世界のスケーラビリティ・安全性の課題はすべて対処可能であることを示した一方、輻輳時にはキューが蓄積し PFC ポーズフレームが生成されうるため、ロスレス性それ自体は低レイテンシを保証しない。 将来展望として、著者らは PFC のホップバイホップ距離制限(300m、そのため Spine 層を跨ぐ DC 間通信には非対応)、ECMP の 60% 利用率上限に対する MPTCP やパーパケットルーティングに類する手法の RDMA への応用、Clos 以外のトポロジ(up-down ルーティングを持たない設計)でのデッドロック回避、そして FPGA など programmable hardware の進展を踏まえた「そもそもロスレスネットワークが RoCEv2 に必須か」という根本的な問いを今後の課題として挙げている。 ## 強み / 弱点・課題 **強み** - 数万台規模の本番データセンタで 1 年半以上安定稼働した、業界初と目される RoCEv2 大規模展開の体系的報告。 - RDMA トランスポートライブロック・NIC PFC ポーズフレームストーム・スローレシーバー症状という、先行文献で報告されていなかった 3 つの安全課題を発見し、いずれも具体的な解決策(go-back-N・二重ウォッチドッグ・ページサイズ変更+動的バッファ共有)とともに提示。 - PFC デッドロックについても、既知の toy example とは異なる本番特有の根本原因(ARP/MAC テーブルのタイムアウト値不一致)を特定。 - 本番環境での定量評価(レイテンシ 90µs 対 700µs、スループット 3.0Tb/s・60% 利用率・CPU 使用率ほぼ 0%)と、実際のインシデント事例(Figure 9・10)による裏付けを伴う。 **弱点・課題** - PFC のホップバイホップ距離制限(300m)により同一 Spine 層配下に限定され、DC 間通信には適用できない(著者ら自身が認める制約)。 - ECMP によるマルチパスルーティングのハッシュ衝突により、スループットの利用率上限が 60% にとどまる。 - 60000 pause frames/5min のような監視指標はあるが、ポーズ間隔(pause interval)監視は測定時点でスイッチ側が非対応であり、輻輳severityのより正確な把握は将来の ASIC 実装に依存する。 - 著者ら自身が「ロスレスネットワークが RoCEv2 に本当に必要か」を未解決の問いとして提起しており、PFC 依存という設計方針自体の是非は本論文の時点では検証されていない。 ## 関連 - 概念: [[RDMA]] / [[RDMAネットワーク監視]] - 組織: [[Microsoft]] - 人物: [[Chuanxiong Guo]] / [[Haitao Wu]] / [[Jitendra Padhye]] - 後継研究: [[@2023__NSDI__Empowering Azure Storage with RDMA]] / [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] - 対比: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]](PFC が RoCE の性能に必須ではないことを 2 年後に反証) ## 出典 - PDF: `.raw/papers/rdma_sigcomm2016.pdf` - DOI: 10.1145/2934872.2934908 - 会議: ACM SIGCOMM 2016, Florianópolis, Brazil, August 22-26, 2016