論文解説記事です。
Microsoftから、SIGCOMM 2016で発表された論文です。
データセンター内のトラフィックが増大するとともに、検索などの用途で低遅延なネットワークの必要性が増大し、従来のTCP/IPでは遅延およびCPU負荷の面で要求に応えられなくなってきていました。これの解決手段として、DC内ネットワークにはInfinibandが使われていたのですが、依然としてDC間の通信には信頼性の担保されたTCP/IPが必要な状況で、Infinibandに頼っていた広帯域低遅延通信もEthernetの上で実現できればインフラコストを大幅に抑えられるという目論見の元、RoCE(RDMA over Converged Ethernet) v2が策定されました。
しかし、TCP/IPと異なり、RDMAはネットワーク自体がロスレスであることを前提としており、経由するスイッチなどが全てロスレス対応していなければなりません。RoCEv2は、このロスレス対応のためにPFC (Priority-based Flow Control)を使って、バッファオーバーフローを起こす前にPAUSEフレームを使って送信側をストップさせます。
RoCEv2によるロスレスネットワークは、ホスト同士の直結や1ホップ程度であれば上手くいく事は分かっていましたが、マルチホップがあり、レガシーなTCP/IPとの混在もあり、数万台のサーバーがつながるデータセンタートラフィックで実際にスケールするのか、という点について当初は懐疑的な見方も多く、うまくスケールしないという報告もありました。
Microsoftはリアルなデータセンター環境を想定して多くの実験を行っており、それまでに提案された様々なアルゴリズムを試した結果、コモディティなイーサネットを使ってリアルなDCネットワークでスケールしたと、この論文を通じて公表しています。
また論文中で、ロスレスイーサネットにおいて、単純な仕様準拠や運用では発生してしまうhead-of-the line blockingや、Dead lock, Live lock, victim flowなどの不具合について、丁寧に原因と対策が記述されており、非常に参考になります。
以下、大事なエッセンスをいくつか抜き出します。
DSCP-based PFC
VLANベースのPFCは、VLANタグ中の優先度を利用してPFCによる制御を行うのですが、これには二つの問題があったとの事。一つは、VLANタグを有効にするためにスイッチを access mode ではなく trunk mode で利用する必要があるのですが、この場合、PXE (Preboot eXecution Environment) を利用してサーバーOSをインストール・更新した時に、PXEブート中がNICのVLANコンフィグレーションを持たないため、VLANタグ付きのパケットがどうしてもうまく転送できなかったそうです。もう一つは、MicrosoftはClos Networkにおいて、全てL2のVLANによるブリッジではなく、L3のIPフォワーディングで構築していたようで、PFCの優先度ビットのためだけにVLANタグを付与したくなかったようです。
これらの解決策として、IPヘッダ中のDSCPフィールドを利用し、8グループのうちlossy, losslessの2種類の優先度制御を行ったそうです。NICやスイッチはこの変更に柔軟に対応できたとあります。
RDMA transport livelock
RDMAはロスレスネットワークを前提としており、当時のNICのRoCEv2では、パケットがロスした時に転送データの最初のパケットから送信し直す go-back-0 方式が使われていました。PFCが正常に動作したとしても、FCSやソフトバグなどによりロスする可能性はゼロではなく、わずかなロス率でもパフォーマンスを大幅に落としたり、転送が完了しないケースがあります。この解決策として、NICベンダーと協力してgo-back-N 方式に修正しました。
PFC Deadlock
Closのようなネットワークでは、循環したバッファ依存性が存在しないので、デッドロックは起きないと思っていました。しかし、稀にデッドロックが起きることが分かりました。
その原因はARPテーブルとMACテーブルの更新頻度の大きな違いでした。つまりホストがダウンした時に、寿命の長いARPテーブルのエントリはあるMACを示しているのだが、スイッチのMACテーブルには既に存在せず、ポートに繋がっていないMACアドレス宛のパケットが到着した時にスイッチがそれを全ポートにフラッディングすることでした。
下図でそれを説明しており、S3サーバーがダウンした時、S3宛ての紫パケットがT1スイッチ内でフラッドされます。この時、輻輳が発生していたS5サーバー宛てのパスの黒パケットの滞留によりPAUSEフレームがp3からp1へ送られます。このPAUSEフレームがp1->p0->p2->S1と戻って行き、同時にS2サーバーがダウンしていると、ここでまたT0スイッチによるフラッドが発生してPAUSEフレームがp1->p3->->p0->p1->S4というように戻って行きます。これによってPAUSEフレームのループが出来てしまい、デッドロックが起きるというわけです。
解決策の候補はいくつかありましたが、不完全なARPに紐づくロスレスパケットをドロップさせることで解決します。これは、ブロードキャストやマルチキャストパケットをロスレスのクラスに置くべきでない事を示唆しています。
NIC PFC pause frame storm
一つのNICから送出されたPAUSEフレームが、ネットワーク全体の転送をブロックしてしまう事が何度か観測されました。根本原因はNICのバグによるものですが、このバグが発生しても他のネットワークに影響を及ぼさないための対策を入れています。
一つは、NICにウォッチドッグの機能を入れて、受信キューが詰まってPAUSEフレームが送出される時にこれを無効化する機能をNICのマイクロコントローラで実装します。もう一つは、スイッチサイドのウォッチドッグで、サーバー側のegressポートのキューが流れなくなり、PUASEフレームをNICから受け取った場合には、スイッチはロスレスモードを破棄して、パケットをドロップ出来るようにします。一度ロッシーモードになった後は、デフォルト200msecの間PAUSEフレームが出なくなった時に、ロスレスモードに復帰します。
RDMA Performance
RDMAとTCPの遅延の評価を行っています。いずれもDC内のトラフィックで、実験ではトラフィック全体の半分をRDMA, 半分をTCPとして実験を行っています。
ネットワークは、システム全体のボトルネックではないが、複数のサーバーから一つのサーバーに流入するバーストがあり、パケットドロップを引き起こす原因となっています。
遅延比較は下図にようになり、99パーセンタイルの遅延は、RDMAが90usで、TCPは700usと、大きな差が出ています。この遅延の差は、カーネルスタックのオーバーヘッドと、インキャストのパケットドロップによるものです。
締めくくりに、Microsoftは、今回の実験で、現実世界のスケーラビリティと安全性のチャレンジを全て解決したとまとめた上で、問題提起として、本当にロスレスネットワークが必要か？またInfinibandともTCPとも違った新しいトランスポートプロトコルを期待すると記述しています。
このようにMicrosoftは、DC内でのロスレスイーサネットの多くの知見を積み、独自の技術も発展させています。その事が、現在のUltra Ethernet Consortiumの標準化や、MicrosoftによるNICの開発判断などに繋がっているものと思われます。
貞末多聞
Reference
Guo, Chuanxiong, et al. “RDMA over commodity ethernet at scale.” Proceedings of the 2016 ACM SIGCOMM Conference. 2016.
