RoCEv2アップデート
RoCEv2 IBTA標準化完了(2014年9月16日)
以前、当ブログでも紹介したRoCEv2(Ethernet上で動作するRDMA規格のIPルーティングできる新しい規格)が、先週2014年9月16日、InfiniBand関連規格団体であるIBTA(InfiniBand Trade Association)での標準化が完了した。
Press Release: IBTA - InfiniBand Trade Association
InfiniBand Trade Association Releases Updated Specification for Remote Direct Memory Access over Converged Ethernet (RoCE)
New specification enables RoCE routing capabilities for the evolving enterprise data center and hyperscale networking infrastructure
RoCEv2標準化完了 プレゼンテーション動画（英語）
従来のRoCE(RoCEv1)とRoCEv2の違い
下記比較表の通り、RoCEv1に比べ、RoCEv2はIPルーティングに対応し、サブネットを越えてRDMA通信ができるようになった。
出典：Industry Ratifies RoCEv2 for Improved Hyperscale Computing
パケットフレームとしては、下記のようにRoCE(RoCEv1)にはIPヘッダやUDPヘッダが無く、InfiniBandのL2ヘッダをEthernetヘッダ(MAC)に変えただけだったが、
InfiniBandフレームとRoCEv1フレームとの対応
RoCEv2では、下図のようにIPヘッダ(L3ヘッダ)及びUDPヘッダ(L4ヘッダ)を備えている。中間にRoCE(IP Based)というものがあるが、これはRoCEv1.25なども呼ばれ(出典：Mellanox WinOF4.80 User Manual)、UDPヘッダがないものである。UDPヘッダは、L3でのルーティングにおいてマルチパス通信(ECMP: Equal Cost Multi Path等)を行う場合、L4のポート番号でのハッシュによるロードバランスが必要とされるため、UDPヘッダがある方が都合のよい場合がある。標準化されたのはUDPヘッダのあるRoCEv2である。
RoCEv2パケットを見てみる
観察環境：
NIC:Mellanox ConnectX-3Pro (40GbE)
OS:RHEL 6.5
Driver : MLNX OFED 2.3-1.0.1
実行アプリケーション: ib_send_bw (MLNX OFEDインストールで一緒にインストールされるRDMA性能測定ツール。詳細は後述の性能測定例にて。)
RoCEv1 - 設定 特になし（ドライバデフォルトで動作）
RoCEv1パケットの構成：
- Ethernet Type=0x8915(RoCE) : 後続のフィールドがIB GRH(Global Route Header)ヘッダであることを示している
- IPヘッダはない(=IPルーティングはできない)
RoCEv2 - 下記設定を実施
/etc/modprobe.d/mlx4.conf (無ければ作成)に、下記を追記する。
options mlx4_core roce_mode=2
追記後、ドライバのリスタートを実行する。
/etc/init.d/openibd restart
デフォルトでは、UDPポート番号は1021となる。変更する必要がある場合、/etc/modprobe.d/mlx4.confに、
options mlx4_core roce_mode=2 rr_proto=23456
などとする。
RoCEv2パケットの構成：
- Ethernet Type=0x0800 : IPv4
- IPヘッダがある（本例ではIPv4、IPv6にも対応している）
- UDPヘッダがある（本例ではDst portはデフォルトの1021、Src portは送信側アプリケーションによって様々に変わる=ECMPのマルチパス負荷分散が可能）
RoCEv2性能測定例
測定環境（環境の都合により、上述のパケットキャプチャ時とは別環境)：
NIC:Mellanox ConnectX-3Pro (40GbE)
OS:Ubuntu14.04LT
Driver : MLNX OFED 2.3-1.0.1
実行アプリケーション: ib_send_bw（使用方法は下図の実行例参照（"ib_send_bw -h"でヘルプ表示））
接続構成: Mellanox 40GbEスイッチ経由接続（本例ではロスレス設定等は無し）
結果：約37Gbps程度の性能を確認（RoCEv1でも実施、ほぼ同等性能）
RoCEv2ユーザー事例
当ブログでも以前紹介したが、Microsoft Azureのクラウドデータセンターで採用していると発表されている。
下記のRoCEv2標準化完了に関するニュースでもMicrosoft Azureに関するコメントが記載されている。
“RoCEv2 allows us to better scale our cloud deployment in a manner that is compatible with our evolving software defined networking infrastructure and growing virtualization demands, while achieving significant performance and efficiency benefits from RDMA,” said Albert Greenberg, partner development manager for Azure Networking at Microsoft. “Utilizing 40 Gigabit Ethernet solutions with RoCEv2 support is a key factor in enabling Microsoft Azure to efficiently, reliably and cost-effectively process the massive amounts of data required to support our customers’ wide range of workloads.”
補足：RoCEv1/RoCEv2通信でのスイッチの要件
RoCEは、中間バッファを排除したアプリケーションメモリ間のダイレクトなRDMA通信を行うため、送信相手が確実に受け取れる前提で送信するプロトコル（ロスレス通信プロトコル）である。
一方、回線上のビットエラー等による一定レベルのパケットロスは、NICハードウェアで再送されるため、ここでの「ロスレス」とは、完全にパケットロスでなければならないという意味ではない。ロスレスとは、送信速度が受信速度を上回らない通信速度を自動的に保つ仕組みである。受信側が受信処理が間に合わない場合、送信側に「ちょっと待て」とか、「ちょっと送信速度を落として」と伝え、送信側は受信側からのフィードバックを踏まえて送信できればよい。
受信速度を上回る通信レートで送信する場合、受信が追いつかないことを意味し、追いつかない分は受信側で破棄（パケットロス）となる。送信性能と受信性能が釣り合っている環境の場合、ロスレスプロトコルが動いていなくても、結果的にロスレスとなることになる。
余談として、Ethernetスイッチのポートバッファが話題となることがある。スイッチのポートバッファは、受信側が間に合わない場合にもポートバッファ分だけ貯めておける仕組みだが、10Gbpsや40Gbpsといった高速な通信速度で通信する場合、ポートバッファで保留できる時間は非常に限定的であり、広帯域ネットワークでの本質的な解決策とはならないため、ロスレスプロトコルの導入が望ましい。
MellanoxコミュニティサイトでのRoCE関連まとめ記事紹介
（ポイントを補足を含めて日本語にて追記）
RoCE v2 Considerations | Mellanox Interconnect Community
What are the network requirements for RoCE?
Both layer 2 and layer 3 RoCE share the requirement to configure the network for lossless operation. In fact, it does not mean that the network needs to be absolutely lossless. Some level of packet loss is acceptable. (for example as a result of bit errors that may occur at the physical layer). This is permissible as the transport protocol embedded within RoCE includes reliable services with built-in retransmission mechanisms. These reliability mechanisms are implemented in hardware and detect lost packets and retransmit without support required from software. An underlying lossless Ethernet network is required for RoCE traffic only in order to avoid systematic packet drops resulting from resource contention within network switches and adapters.
RoCEネットワークの要件とは？
- RoCEの要件は、L2やL3(RoCEv2の場合)でのロスレス実現である
- ビットエラー等による一定レベルのパケットロスはハードウェアで再送され、許容される
- ネットワークスイッチやアダプタのリソース（処理能力やバッファサイズ）による構造的なパケットドロップは回避すべき（いわゆるロスレス）
How do I achieve lossless Ethernet L2 network?
At the link level, it can be achieved by using flow control. Flow control is achieved by either enabling global pause across the network, or by the use of priority flow control (PFC). PFC is a link level protocol that allows a receiver to assert flow control telling the transmitter to pause sending traffic for a specified priority. PFC supports flow control on individual priorities as specified in the class of service field of the 802.1Q VLAN tag. Thus it is possible for a single link to carry both lossless traffic to support RoCE and other best effort traffic on a lower priority class of service.
ロスレスなL2 Ethernetネットワークはどのように実現するか？
- リンク層では、フローコントロールによって実現可能
- フローコントロールには２種類ある
- １）Global puaseによる通信全体のPause（送信抑制）
- ２）PFC(Priority Flow Control)による特定PriorityのフローのみのPause
- PFCでは、802.1Q VLAN tagフィールドのCOSビットで指定されたPriority単位でPauseを実行し、同一リンクに複数の性質のフロー（ロスを許容するTCP/IP通信等）が混在する場合には有効
参考資料
HowTo Run RoCE over L2 Enabled with PFC | Mellanox Interconnect Community
If I run RoCE v2, should I use PFC or global pause for lossless L2 subnet?
In a converged environment lossy traffic share the same physical link with lossless RoCE traffic. Typically separate dedicated buffering and queue resources are allocated within switches and routers for the lossless and best-effort traffic classes that effectively isolates these flows from one another. Although global pause configuration is easier and might work nicely in a lab condition, it is recommended to use PFC in operational network in order to be able to differentiate between different flows. otherwise, In case of congestion, important lossy traffic, such as control protocols may be affected. Therefore, RoCE should run on a VLAN with priority enabled with PFC, while the control protocols (lossy) will run without flow control enabled on different priority.
RoCEv2を動作させる場合、PFCやGlobal pauseのどちらを使ったらよいか？
- コンバージド環境（複数の用途の通信が広帯域ネットワークに統合された環境）では、Lossyなトラフィック（ロスを許容する通信）とLosslessなトラフィック（ロスレス通信）が混在
- ロスレス通信のみをPauseさせ、Lossyなトラフィック（例えばハートビート等）は許容するPFCの使用が望ましい
- （筆者注）ストレージ専用ネットワークのようにRoCEのみを使う場合はGlobal pauseでも問題ないと思われる
How do I preserve lossless characteristics on L3 network (between L2 subnets)?
Operating RoCE at layer 3 requires that the lossless characteristic of the network are preserved across L3 routers that connect layer 2 subnets. The intervening layer 3 routers should be configured to transport layer 2 PFC lossless priorities across the layer 3 router between Ethernet interfaces on the respective subnets. This can typically be accomplished through standard router configuration mechanisms mapping the received layer 2 class of service to the corresponding layer 3 Differentiated Serviced Code Point (DSCP) QoS setting.
L3ネットワークの場合、L2サブネット間でのロスレス性はどのように保持するか？
- L3でのRoCE(RoCEv2)では、L3ルーター経由でのロスレスを実現する必要がある
- L2 PFCでロスレス設定されたPriorityをL3ルーターは送信先L2サブネットへ伝播させる必要がある
- 典型的にはL2のCOSをL3のDSCP QoSにマッピングする仕組みで実現する
参考資料
What happens when I use multi-path routing (ECMP) on L3 networks?
Rather than being constrained by layer 2 link-breaking protocols such as spanning tree algorithm, layer 3 networks can implement forwarding algorithms that take much better advantage of available network connectivity. Advanced data center networks can utilize multi-path routing mechanisms for load balancing and improved utilization. One commonly used protocol to achieve these goals is Equal Cost Multiple Path (ECMP). For each received packet the L3 Routers make a forwarding decision based on not just the destination IP address but also on other fields within the packet. In cases where there are many possible paths to a given endpoint ECMP allows different flows to select different paths and thus to leverage the available connectivity. The path selection for a given packet is based on the destination IP address and a hashed value of other packet fields. Note that while different flows can exploit different paths, the values used to select the output port for forwarding is deterministic such that packet ordering for a given flow is preserved.
L3ネットワークでのECMPについては？
- 先進的なデータセンタネットワークでは、L3でのECMPマルチパス活用でのネットワークが構成され、負荷分散と可用性を実現している
- ECMPでは、L3ルーターでの送信先は、送信先IPアドレスだけでなく、パケットの他のフィールド値でのハッシュ計算で決定され
- １つのフローではパケット順序が保たれるようなフィールド値と計算方法が用いられる（（筆者注）例えば、UDPポート番号）
