まず言いたのはオンライン検索、ショッピング、ライブ配信などインターネットにおける多くのオンラインサービスに対して、高頻度のユーザーリクエストに超高速で応答する必要があり、データーセンター内いずれかの処理過程で発生する遅延は、エンドユーザーのアクセス体験に大きな影響を与えるため、トラフィック、口コミ、アクティブユーザーなどにも影響を及ぼします。
また、機械学習やAIなどの技術が進んでいる中でコンピューティングパワーへの需要は幾何級数的に高まっています。 複雑化するニューラルネットワークやディープラーニングモデルに対応するため、データーセンターには多数の分散コンピューティングクラスターが存在することになりますが、多数の並列プログラムの通信遅延は、コンピューティングプロセス全体の効率に大きな影響を及ぼします。
また、データーセンターにおける爆発的な増加したデータの保存と読み取り効率化に対応するため、イーサネットコンバージドネットワークを利用した分散ストレージの普及が進んでいます。 しかし、ストレージネットワークのデータストリームはエレファントフローが主流であるため、輻輳によるパケットロスが発生するとエレファントフローを再送することになり、効率が下がるだけでなく、輻輳も増加します。
つまり、フロントエンドのユーザー体験とバックエンドの応用効率という観点から、今のところデーターセンターネットワークへの需要は遅延が低ければ低いほどよく、効率的であればあるほどよいということです。
データーセンター内のネットワーク遅延を減らし、処理効率を向上させるため、RDMA技術は、ユーザーモードのアプリケーションがCPUから複数のメモリコピーを必要とせず直接読み書きまたリモートメモリに書き込みことができカーネルをバイパスしてNICに直接データを書き込むことで、高いスループットと超低遅延、低いCPUオーバーヘッドを実現するために生まれました。
現在、イーサネットに使われるRDMAプロトコルは RoCEv2 でコネクションレス型の UDP プロトコルになります。UDP プロトコルはコネクション型の TCP プロトコルに比べて高速で CPU リソースを消費しませんが、TCP プロトコルのようにスライドウィンドウや確認応答などの信頼性の高い伝送を実現する仕組みはなく、一度パケットが失われると上位のアプリケーションによる確認と再送に頼るため RDMA の伝送効率が大きく損なわれることになります。
そこで、RDMAの性能を引き出し、データーセンターにおける大規模分散システムのネットワーク性能のボトルネックを打破するためには、パケットロスのないRDMAのロスレスネットワーク環境の構築が必至であり、パケットロスなしを実現できる鍵はネットワークの混雑を解決することにあります。
なぜ輻輳が発生しますか？
輻輳発生の原因はさまざまですが、データーセンターにおけるより3つの一般的な且つ重要な原因を説明いたします。
１、 コンバージェンス比(収斂比)
データーセンターのネットワーク・アーキテクチャを設計する場合、コストと収益の両面から非対称な帯域設計、つまりアップリンクとダウンリンクの帯域が異なる設計を採用することがほとんどです。 スイッチのコンバージェンス比は、単純に入力帯域の合計を出力帯域の合計で割った値です。 Ruijie RG-S6220-48XS6QXS-H 10 Gigabit を例にすると、サーバー入力に使えるダウンリンクの帯域は 48*10G=480G, アップリンクの出力帯域は 6*40G=240G, 設備全体のコンバージェンス比は 2:1です。25GのRG-S6510-48VS8CQにスイッチは、ダウンリンクでサーバーの入力に使える帯域は48*25G=1200G、アップリンクで出力に使える帯域は8*100G=800Gで、設備のコンバージェンス比1.5：1となっています。 1200G、上流出力に利用できる帯域は8*100G=800Gで、マシン全体の収束率は1.5:1です。
つまり、ダウンリンク先のサーバーが送信するアップリンクのパケットレートの合計が、アップリンクの総帯域幅を上回った場合に、アップリンクポートで輻輳が発生するのです。
2、ECMP
現在のデーターセンターネットワークの多くはFabricアーキテクチャを採用しており、ECMPを用いて複数の等価な負荷分散リンクを構築しています。転送するリンクの選択は摂動係数を設定してHASHすることで簡単にできますが、選択したリンク自体が混雑しているかどうかは考慮されません。ECMPは輻輳を考慮したメカニズムを持たず、単にフローを異なるリンクに分散して転送するため、すでに輻輳しているリンクの輻輳を増加させる可能性が高いです。
3、TCP Incast
TCPインキャストは、データーセンターのクラウド化、特にHadoop、MapReduce、HDFSなどのScale-Outとして実装された分散ストレージやコンピューティング応用におけるよく発生するMany-to-One通信パターンです。
例えば、Parent Serverがノード群（サーバークラスタやストレージクラスタ）にリクエストを出すと、クラスタ内のすべてのノードが同時にリクエストを受信してほぼ同時に応答し、多くのノードが同時に1台の設備（Parent Server）にTCPデータストリームを送り、「マイクロバーストフロー」が発生することでParent Serverへのスイッチ上の送信ポートがキャッシュ不足となり、輻輳が発生します。
▲TCP Incastトラフィックモデル
前述したように、RDMAはTCPとは異なり、ロスレスネットワークを必要とします。 通常のマイクロバーストトラフィックでは、スイッチのBufferがバーストパッケトをバッファにキューイングして待機する役割を果たしますが、スイッチのBuffer容量を増やすのは非常に高価なので、限界があり、バッファがキューイングするパッケトが多くなりすぎると、パケットロスが発生してしまうのです。
エンドツーエンドのロスレス転送を実現し、スイッチのバッファオーバーフローによるパケットロスを回避するためには、フローコントロールなど他のメカニズムを導入し、リンク上のフローを制御してスイッチBufferへの負担を軽減することでパケットロスを回避することができます。
PFCによるフロー制御の実装方法
IEEE 802.1Qbb (Priority-based Flow Control)、略してPFCは、IEEEデーターセンターブリッジ（Data Center Bridge）のプロトコルファミリーの技術で、フロー制御の拡張版です。
PFCの話をする前に、IEEE 802.3X（フロー制御）のフロー制御の仕組みを見てみましょう。受信したパッケトを処理する能力がない場合、パケットを落とさないように受信側はメパケットの送信側にパケットの送信を一時的に停止するよう通知する必要があります。
下図のように、ポートG0/1、G0/2が1Gbpsで転送している場合、ポートF0/1に輻輳が発生することになります。 パケットの損失を防ぐため、ポートG0/1、G0/2でフローコントロール機能を有効にしてください。
▲ポートで輻輳発生するフロー
・スイッチBはF0/1でパッケト転送の輻輳が発生すると、ポートバッファにパケットをキューイングします。 輻輳がある閾値を超えると、ポートG0/2からG0/1にPAUSEフレームを送信して、G0/1にパケット送信を一時的に停止するように通知します。
・G0/1はPAUSEフレームを受信し、G0/2へのパケット送信を一時的に停止します。 一時停止の期間に関する情報は、PAUSEフレームによって運ばれます。 スイッチAはこのタイムアウトの範囲内，またはTimeoutが0のコントロールフレームを受信するまで待機し，送信を再開します。
IEEE 802.3Xプロトコルには、一度リンクが停止すると送信側はそれ以上パケットを送信できないという欠点があります。 停止が一部の優先度の低いデータストリームによって引き起こされた場合、そのリンク上の他の優先度の高いデータストリームも一緒に停止するので、実際には損失が上回ります。
下図のパッケト解析に示すように、PFCは基本的なフロー制御IEEE 802.3Xを拡張し、1つのイーサネットリンク上に8本の仮想チャネルを作成し、それぞれの仮想チャネルに適切な優先度を割り当て、そのうちのどれかを個別に中断、再開させ、他の仮想チャネルからのトラフィックは中断せずに通過させることを可能にするものです。
▲PFCプロトコルパケット構造解析
PFC プロトコルは、フロー制御の粒度を物理ポートから8本の仮想チャネルに絞り込みますが、それぞれSmart NIC ハードウェアの 8 列送信キューに対応します（これらのキューはトラフィッククラス、TC0、 TC1..TC7 と名付けられています）異なるRDMAのカプセル化プロトコルがマッピングも違います。
• RoCEv1：
このプロトコルは、RDMAデータセグメントをイーサネットヘッダーとともにイーサネットデータセグメントにカプセル化したもので、レイヤ2パケットとなります。 分類するためには、VLAN（IEEE 802.1q）ヘッダーにあるPCP（Priority Code Point）フィールド3Bitsを用いてのみ優先度の値を設定することが可能です。
▲レイヤ 2 イーサネット フレームの VLAN ヘッダー構造
• RoCEv2:
このプロトコルは、最初に RDMA データ セグメントを UDP データ セグメントにカプセル化し、UDP ヘッダーを追加し、IP ヘッダーを追加し、最後にイーサネットヘッダーを追加し３レイヤのデーターパッケージです。イーサネット VLAN の PCP フィールドを使用できるしIP ヘッダーの DSCP フィールドも使用できます。
▲レイヤ 3 IP パケットのヘッダー構造
簡単に言うと、レイヤ 2 ネットワークの場合、PFC は VLAN の PCP ビットを使用してデータ ストリームを区別します. レイヤ 3 ネットワークの場合、PFC は PCP または DSCP のいずれかを使用できるため、異なるデータストリームに対して独立したフロー制御を実行することができます。 現在のデーターセンターは 3 レーヤネットワークを採用しているため、DSCP を使用すると PCP よりも多くの利点があります。
PFC デッドロック
PFC は、異なる優先度を異なるキューにマッピングすることで、キューベースのフロー制御を実装できますが、PFC デッドロックの問題などの新しい問題も引き起こします。
PFC デッドロックとは、マイクロループなどにより複数のスイッチが同時に輻輳した場合に、それぞれのポートのバッファ消費量がしきい値を超え、互いのリソースの解放を待ち、永続的なすべてのスイッチでのデータ フローのブロック ネットワーク状態です。
通常では、スイッチのポートが輻輳し、XOFF水平タブを超えると、データが入る方向 (つまり、ダウンストリーム) が PAUSE フレームのバック プレッシャを送信し、アップストリーム デバイスはその後データの送信を停止します。ローカル ポートの場合、PAUSE フレームを受信します。 このようなレベルごとのバック プレッシャは、ネットワーク ターミナル サーバーが PAUSE フレームで指定された一時停止時間内にデータの送信を一時停止するまで実行されません。これにより、輻輳によるネットワーク ノードによるパケット損失が解消されます。
ただし、リンク障害やデバイス障害などの特殊なケースでは、BGP ルートの再コンバージェンス中に短いループが発生し、循環バッファ依存関係が発生することがあります。 下図のように、4 台のスイッチがすべて XOFF水平タブに到達すると、すべてのスイッチが同時に反対側に PAUSE フレームを送信します.このとき、トポロジ内のすべてのスイッチは停止状態になります.バック プレッシャによりPFC の影響により、ネットワーク全体またはネットワークの一部はスループットがゼロになります。
▲デッドロックイメージ図
ループのないネットワークで短いループが形成された場合でも、デッドロックが発生する可能性があります。 一時的なループは修復後すぐに解消されますが、それによって引き起こされるデッドロックは一時的なものではなく、サーバーが再起動してトラフィックが中断されても、デッドロックは自動的に回復されません。
デッドロック状態を解消するためには、データーセンター内でループが発生しないようにする必要がある一方で、ネットワーク機器のデッドロック検知機能によって実現することができます。 Ruijie RG-S6510-48VS8CQ のデッドロック検出機能は、デッドロック状態が発生してから一定時間内に、受信した PFC フレームが無視され、同時にバッファ内のパケットが転送または破棄されることを検出できます (デフォルトは転送) .
たとえば、タイマーの監視時間を 10 回チェックし、そのたびに PFC Pause フレームが 10ms 以内に受信されるかどうかをチェックするように設定できます。 10回受信するとデッドロックが発生したことを意味し、バッファ内のパケットに対してデフォルトの動作を行い、その後100msを回復時間として設定し、検出を再開します。 コマンドは次のとおりです。
priority-flow-control deadlock cos-value 5 detect 10 recover 100 //10 回の検出、100ms recover
RDMA ロスレスネットワークでは、PFC フロー制御メカニズムを使用して、スイッチポートバッファがオーバーフローする前にピアトラフィックを一時停止し、パケット損失の発生を防ぎます。しかし、効率が悪い1段の反圧が必要なため、より効率的なエンド・ツー・エンドのフロー制御が求められています。
ECN によるエンドツーエンドの輻輳制御
現在の RoCE 輻輳制御は、ECN (Explicit Congestion Notification) に依存して動作します。 もともと RFC 3168 で定義されていたネットワークデバイスは、輻輳が検出されたときに IP ヘッダーに輻輳インジケーターを埋め込み、TCP ヘッダーに輻輳確認応答を埋め込むことによって輻輳を実装します。
RoCEv2 標準では、RoCEv2 Congestion Management (RCM) が定義されています。 ECN が有効になった後、RoCEv2 トラフィックが輻輳していることをネットワーク デバイスが検出すると、データ パケットの IP ヘッダーの ECN フィールドがマークされます。
▲IPヘッダのECNフィールド構造
この輻輳インジケータは、宛先エンドノードによってBTH（Base Transport Header、IB データ セグメントに存在する）内のFECN輻輳指標マーカーに従って、意解釈されます。 つまり、ECNでマークされたパケットが本来の目的地に到着すると、輻輳通知が送信元ノードにフィードバックされ、送信元ノードは問題のあるキューペア（QP）に対してネットワークパケットのレート制限を行い、輻輳通知を応答します。
▲ECNプロセスイメージ図
① 送信側が送信する IP パケットタグは ECN (10) に対応します。
② スイッチがキューの輻輳の場合にパケットを受信すると、ECN フィールドを 11 に変更して送信し、ネットワーク内の他のスイッチはそれを透過的に送信します。
③ 受信側は ECN が 11 パケットを受信し、輻輳していることを確認し、パケットを正常に処理します。
④ 受信側は輻輳通知を生成し、ms レベルごとに CNP (Congestion Notification Packets) パッケトを送信します. ECN フィールドは 01 であり、これはパケットがネットワークによって破棄されないことを要求します.受信側は、単一の CNP を、ECN によって同じ QP としてマークされた複数のデータ パケットに送信できます (フォーマット仕様については、次の図を参照してください)。
⑤ CNPパケットを受信した後、スイッチはパケットを正常に転送します。
⑥ 送信側は、ECN が 01 でマークされた CNP パケッ分析トを受信した後、対応するフロー (ECN が有効な QP に対応) にレート制限アルゴリズムを適用します。
RoCEv2のCNPパッケト形式
▲CNPパッケト構造
CNPは輻輳制御パケットとして、遅延とパケット損失も発生する可能性があることに注意してください。送信側から受信側までのすべてのデバイスとリンクには一定の遅延があり、最終的に送信側がCPN受信時間を増やす同時に, スイッチポートの輻輳は徐々に増加します. 送信側が時間内に減速できない場合,パケット損失が発生する可能性があります.輻輳通知フィールドのサイズが大きすぎないようにすることをお勧めします。これは、送信者が ECN 制御パケット交換ループの過剰な数のホップのために時間内に減速できず、輻輳が発生するのを防ぐためです。
まとめ
RDMA ネットワークは、ネットワークに PFC および ECN 機能を配置することにより、ロスレス保証を実現します。 PFC技術により、リンクの RDMA 専用キューのフローを制御し、スイッチの入力ポート（Ingress port）が混雑している場合にアップストリーム デバイスのフローをバックプレッシャすることができます。 ECN 技術を使用して、エンドツーエンドの輻輳制御を実装できます. スイッチの出力ポート（Egress port）が輻輳すると、ECN はデータパケットをマークし、トラフィックの送信側は送信レートを下げます.
ネットワークの高性能転送を実現するという観点から、一般的にはECNとPFCの間のバッファラインを調整することで、ECNをPFCよりも速くトリガーすること、つまりネットワークは依然としてフルスピードでデータを転送し続け、サーバーよりパケットレートを下げることを推奨しています。 それでも解決しない場合は、アップストリームスイッチがPFC経由のパケット送信を停止することで、ネットワーク全体のスループット性能は低下しますが、パケットロスを発生しません。
RDMAをデーターセンターネットワークに適用するためには、転送時のロスレスを解決する上で、高度なメンテナンス保守も必要があります。これにより遅延やパケットロスに敏感なネットワーク環境に対応することができます。 MMUの高度な管理技術とINTのネットワークビジュアル技術については、以前の記事をご参照してください。
