RDMA over Commodity Ethernet at Scale – 論文解説

前回の記事では RDMAの概要 RDMAという技術について簡単に紹介しましたが、今回はMicrosoftが2016年のSIGCOMMで発表した、データセンターにおけるRDMAの大規模運用に関する論文について 大規模な汎用イーサネットにおけるRDMA 簡単な解説（ガイド）をしていきたいと思います。

概要

過去1年半にわたり、Microsoftの信頼性が高く低遅延が要求されるサービスをサポートするために、汎用イーサネット上のRDMA（RoCEv2）を使用してきました。本論文では、その過程で直面した課題と、それらを解決するために考案した手法について説明します。

基本的にこの記事では、Microsoftが過去1年半にわたって自社のインフラでRDMAを運用する中で直面した課題と、その解決策について紹介しています。

RoCEv2をVLANを超えて拡張するために、大規模なデプロイメントを確実にするためのDSCPベースの優先度フロー制御（PFC）メカニズムを設計しました。

RoCEv2の拡張性を高めるため、Microsoftは大規模なデプロイに対応するDSCPベースのPFCを設計しました。

PFCに起因するデッドロック（実際に発生しました！）、RDMAトランスポートのライブロック、およびNICのPFCポーズフレームストームの問題といった安全上の課題に対処しました。また、RDMAが期待通りに動作することを確認するための監視・管理システムも構築しました。

論文内では、PFCによって生じた問題とMicrosoftによる解決策が紹介されており、同時に監視システムについても設計されています。

我々の経験から、大規模なRoCEv2運用の安全性と拡張性の問題はすべて解決可能であり、RDMAはデータセンター内通信においてTCPに代わり、低遅延、低CPUオーバーヘッド、および高スループットを実現できることが示されました。

Microsoftの経験は、RoCEv2で発生する拡張性と安全性の問題が解決可能であることを証明しており、データセンター内においてTCPに代わる低遅延、低CPU使用率、高帯域な転送方式になり得ることを示しています。

はじめに

近年のネットワークサービスやクラウドの普及に伴い、データセンターのネットワークにはさらなる高速化と低遅延が求められています。現在もTCP/IPがデータセンター内ネットワークの主要な転送方式ですが、現在の需要を支えるにはTCP/IPでは不十分であるという兆候が増えています。主な理由は2つあります。

1. 高いCPU使用率
2. カーネルとパケットドロップによる高遅延

この論文は、Microsoftが大規模なRoCEv2をデプロイする際に直面した課題とその解決策をまとめたもので、以下の内容を含んでいます。

• Layer-3 (IP) でスケールするための DSCP ベースの PFC
• RDMA トランスポートのライブロック
• PFCデッドロック
• NIC PFC ポーズフレームストーム
• スローレシーバー現象

DSCPベースのPFC

従来のPFCの手法は、VLANタグ内のPCP（Priority Code Point）を通じてPFCをサポートしていましたが、データセンターでは主に2つの理由により、レイヤー2のVLANを使用することができません。

1. サーバーはPXEでデプロイされており、PXEブート時にNICにVLAN設定がないため、VLANタグ付きのパケットを受信できません。
2. スイッチはLayer-2ブリッジングではなくLayer-3フォワーディングを使用しており、Layer-3ネットワークは拡張性、セキュリティに優れ、監視も容易です。

基本的にPFCポーズフレームにはVLANタグが含まれていないため、VLANを使用する目的は単にパケットの優先順位情報を保持するためだけです。IPヘッダーのDSCPも同様の機能を持っているため、Microsoftは上述の2つの問題を解決するために、DSCPに基づくPFCの仕様を開発しました。

セキュリティ上の課題

RDMAトランスポート・ライブロック

RDMAは設計上、ネットワーク全体で輻輳（congestion）によるパケットロスが発生しないことを前提としています。RoCEv2ではPFCを使用してこの条件を満たしていますが、FCSエラーやハードウェア・ソフトウェアのバグによるパケットドロップは依然として発生します。Microsoftは、このような状況が発生した際のパフォーマンスへの影響を最小限に抑えることを目指しています。

しかし、実際のテストでは、非常に低いパケットドロップ率であってもRDMAアプリケーションが完全に動作しなくなることがありました。その原因は、NICが使用する再送アルゴリズムが「go-back-0」であるためです。つまり、同一メッセージ内で1つでもパケットドロップが発生すると、最初から再送が開始されるからです。

しかし、NICでTCPのような複雑すぎるSACKメカニズムを実装することは不可能です。そこで、MicrosoftはNICベンダーと協力して「go-back-N」アルゴリズムを実装しました。これも最初のドロップパケットから再送を開始するものですが、ライブロック（livelock）が発生する可能性を大幅に低減しました。

PFCデッドロック

PFCデッドロックは、基本的にMACアドレステーブルとARPテーブルが一致しない状況で発生します。このとき、スイッチはフラッディング（flooding）によって新しいMACアドレスを学習しようとしますが、PFCが有効で、かつ特定の受信者がパケットを受信できない状況では、ネットワーク全体がデッドロックに陥る可能性があります。ここでは簡単に説明しますが、論文ではより詳細なシナリオが解説されています。

受信側に異常が発生してパケットを受信できなくなると、スイッチはすべてのポートにパケットをフラッディングします。これにより他のポートで輻輳が発生し、PFCポーズフレームの送信が開始されます。このポーズフレームがデータセンターのリーフ・スパイン（leaf-spine）ネットワーク内を伝播し続け、ネットワーク全体のデッドロックを引き起こします。

Microsoftの解決策は、MACアドレステーブルとARPテーブルが一致しない場合、ロスレスネットワーク（lossless network）において対応するMACアドレスがないパケットを直接ドロップし、フラッディングを試行しないことです。これにより、他のポートのバッファ枯渇を防ぎ、PFCデッドロックの誘発を回避します。

NIC PFCポーズフレーム・ストーム

Microsoftは、NICが異常状態でPFCポーズフレームを送信し続ける可能性があることを観察しました。最悪の場合、以下のような状況を引き起こします。

1. 異常なNICがTORスイッチにポーズフレームを送信し続ける
2. TORスイッチが、リーフへのアップリンクを含むすべてのトラフィックを停止する
3. リーフもすべてのスパインのトラフィックを停止する
4. スパインが他のすべてのリーフのトラフィックを停止する
5. 他のリーフがすべてのTORのトラフィックを停止する
6. TORがすべてのサーバーのトラフィックを停止する

この問題の解決策は比較的単純です。Microsoftは2つのウォッチドッグ（watch dog）を設計しました。1つはサーバー側、もう1つはスイッチ側です。サーバー側では、ウォッチドッグがNICによるポーズフレームの継続的な送信を検知すると、NICからの送信を停止させます。スイッチ側でも同様に、各ポートを監視するウォッチドッグがあり、特定のポートがポーズフレームを受信し続けている場合、そのポートのロスレスモードを一時停止し、ポーズフレームストーム（pause frame storm）が収まった一定時間後に再有効化します。

スローレシーバー現象

NICの設計では、データ構造の大部分をメインメモリに配置し、NIC上にはごくわずかなキャッシュのみを保持します。そして、MTT（Memory Translation Table）を介して物理アドレスと仮想アドレスの対応を保存します。デフォルトのMTTページサイズが小さすぎると、キャッシュミスが発生しやすくなり、速度が低下してバッファがPFCしきい値（threshold）を超えて満たされます。その結果、NICは大量のPFCポーズフレームを送信することになります。

解決策は単純明快です。ページサイズを大きくすることで、キャッシュミスの確率を下げます。

本番環境におけるRDMA

このセクションでは、Microsoftが本番環境（production）でどのようにRDMAを使用しているかを紹介します。これには、構成管理（configuration management）と監視のデプロイ方法、およびPFCポーズフレームの数とレイテンシ（latency）を監視するために開発されたツールが含まれます。

このセクションの最後では、RDMAのパフォーマンス・テストをいくつか実施しており、RDMAがレイテンシとスループット（throughput）の両面でTCPと比較して大幅に向上していることがわかります。しかし、最後にRDMAが「高スループット」と「低レイテンシ」を同時に提供できる万能薬ではないことも言及されています。

経験

最後の章では、主にMicrosoftが実際の環境に導入した後に直面した問題とその解決策について解説しています。また、RoCEv2という技術に対する彼らの見解や疑問点についても述べており、最後にInfiniBandやiWARPといった他のRDMA技術に関する関連研究の考察も提供しています。

結論

この論文では、データセンターにおけるMicrosoftのRDMA技術の実装と、遭遇した問題の解決策を紹介しています。最後に「今後の課題（future works）」として、データセンター間の低遅延ネットワーク、異なるアーキテクチャにおけるデッドロックの解決策、高帯域幅と低遅延を同時に実現する方法など、今後継続して検討すべき課題を提案しています。

感想

筆者は、この論文は非常に一読の価値があると考えています。RDMA技術がネットワーク内でどのように転送されるかを理解できるだけでなく、Microsoftのトラブルシューティングにおける全般的な経験や手法は、インフラの設計や構築に携わるエンジニアにとって非常に参考になるはずです。

---

著作権表示：このブログのすべての記事は、以下のライセンスのもとで提供されています。 CC BY-NC-SA 4.0 （別途記載がある場合を除く）