RDMA over Commodity Ethernet at Scale – 導讀

在上一篇文章 RDMA Overview 中簡單了介紹了一下 RDMA 這個技術，這次將為 Microsoft 在 2016 年 SIGCOMM 發表關於他們資料中心大規模應用 RDMA 所撰寫的論文 RDMA over Commodity Ethernet at Scale 做簡單的導讀。

Table of Contents

Abstract

Over the past one and half years, we have been using RDMA over commodity Ethernet (RoCEv2) to support some of Microsoft’s highly-reliable, latency-sensitive services. This paper describes the challenges we encountered during the process and the solutions we devised to address them

基本上這篇文章介紹了 Microsoft 在過去一年半在自己的 Infrastructe 使用 RDMA 遇到的挑戰跟解決辦法。

In order to scale RoCEv2 beyond VLAN,we have designed a DSCP-based priority flow-control(PFC) mechanism to ensure large-scale deployment

為了讓 RoCEv2 能夠更好的擴展，Microsoft 設計了 DSCP-based PFC 來因應大規模部屬。

We have addressed the safety challenges brought by PFC-induced deadlock (yes, it happened!), RDMA transport livelock, and the NIC PFC pause frame storm problem. We have also built the monitoring and management systems to make sure RDMA works as expected.

裡面介紹了一些因為 PFC 遭遇的問題，以及 Microsoft 的解決方式，並且同時設計了一套監控系統。

Our experiences show that the safety and scalability issues of running RoCEv2 at scale can all be addressed, and RDMA can replace TCP for intra data center communications and achieve low latency, low CPU overhead,and high throughput.

Microsoft 的經驗證明了 RoCEv2 所遇到的擴展性跟安全性問題可以被解決，並且可以取代 TCP 成為資料中心內低延遲，低 CPU 使用率，高頻寬的傳輸方式。

Introduction

在近年來網路服務跟雲端的盛起之下，資料中心網路需要越來越高速跟低延遲的網路。TCP/IP 仍然是目前資料中心內網路的主要傳輸方式，但是越來越多跡象顯示 TCP/IP 已經不足以負荷目前的需求。主要有兩大原因：

高 CPU 使用率
kernel 跟 packet drop 所造成的高延遲

這篇論文總結了 Microsoft 在部屬大規模 RoCEv2 所遇到的挑戰跟其解決方法，包含了以下幾點內容：

DSCP-based PFC to scale in layer-3 (IP)
RDMA transport live-lock
PFC Deadlock
NIC PFC pause frame storm
Slow-receiver symptom

DSCP-based PFC

傳統 PFC 做法是透過 VLAN tag 中的 PCP (Priority Code Point) 來支援 PFC，但在資料中心中因為兩個主要原因而造成無法使用 Layer-2 的 VLAN。

伺服器為 PXE 部屬，PXE boot 時 NIC 並未帶 VLAN 的設定，會無法接收帶 VLAN tag 的 packet。
Switch 使用的是 Layer-3 forwarding 而不是 Layer-2 bridging，layer-3 網路有更佳的擴展性，安全性並且更容易監控。

基本上 PFC pause frame 並不帶任何 VLAN tag，所以使用 VLAN 的目的單純只是為了攜帶封包優先權的資料。而在 IP header 中 DSCP 也有同樣的功能，所以 Microsoft 就開發了一個基於 DSCP 進行 PFC 的規範，以解決上述遇到的兩個問題。

安全性挑戰

RDMA Transport Livelock

RDMA 在設計的時候基本上是假設整個網路是不會因為 congestion 所造成 packet lost 的。在 RoCEv2 中使用是 PFC 達到這個條件，但仍然會有其他如 FCS error 或是硬體軟體中的 bug 會造成掉包。Microsoft 希望在這種狀況發生的時候所造成的效能影響達到最低

但在實際測試中，就算非常低的掉包機率仍然會造成 RDMA Application 完全無法運作，原因在於 NIC 所使用的重傳演算法為 go-back-0 也就是在同一個 message 中只要發生了任何一個 packet drop 就會從頭開始重新傳輸。

不過在 NIC 中無法實現像 TCP 過於複雜的 SACK 機制，於是 Microsoft 跟 NIC 廠商合作實現了 go-back-N 的演算法，也是從第一個掉包的封包開始重傳，大大的減少了 livelock 發生的可能性。

PFC Deadlock

PFC Deadlock 基本上會發生在 MAC Address Table 跟 ARP Table 不 match 的狀況下。此時 switch 就會透過 flooding 的方式嘗試來學習新的 MAC Address，但是在 PFC 開啟並且某一台接收者無法接收封包的狀況下，可能會造成整個網路 deadlock。在這裡簡單說明，而論文中有比較詳細的情境解釋。

當一台接收者發生異常沒有辦法接收封包，switch 會將封包 flood 到每一個 port 上，可能造成其他 port congestion 並且開始寄送 PFC pause frame，而這個 pause frame 會一直在資料中心的 leaf-spine 網路中傳遞並且造成整個網路 deadlock。

Microsoft 的解決方法是當 MAC Address Table 跟 ARP Table 不 match 的狀況下，lossless network 沒有對應 MAC Address 的封包就直接 drop 掉，而不嘗試 flooding，因而不會造成其他 port buffer 耗盡進而引發 PFC deadlock。

NIC PFC Pause Frame Storm

Microsoft 觀察到 NIC 可能在異常狀態下會持續的送 PFC pause frame，而在最慘烈的情況下，會造成以下狀況：

有異常的 NIC 持續送 pause frame 至 TOR switch
TOR switch 因而暫停所有的 traffic 包含 leaf 的 uplink
Leaf 也暫停所有 Spine 的 traffic
Spine 暫停所有其他 Leaf 的 traffic
其他 Leaf 暫停所有 TOR 的 traffic
TOR 暫停所有伺服器的 traffic

這個問題解決方法相對簡單，Microsoft 設計了兩個 watch dog，一個在伺服器端，一個在 switch 端。在伺服器端，當 watch dog 偵測到 NIC 持續的送出 pause frame，將會阻止 NIC 送出 pause frame。在 switch 端，同樣也有個 watch dog 監控每個 port，當某個 port 持續收到 pause frame，將會暫停這個 port 的 lossless mode 並且在 pause frame storm 消失一段時間後重新啟用。

Slow-receiver symptom

NIC 在設計時會將其大部分的資料結構放在主記憶體裡，並且只在 NIC 上留很少的 cache 並且透過 MTT (Memory translation table) 來儲存 physical 跟 virtual address 的對應。而預設的 MTT page size 大小太小造成容易 cache miss 而降低速度造成 buffer 填滿超過 PFC threshold，最後 NIC 將會送出大量的 PFC pause frame。

解決方法簡單易懂：增加 page size 造成 cache miss 機率降低。

RDMA in Production

這個部分介紹了 Microsoft 如何在 production 環境中使用 RDMA。其中包含了如何部屬進行 configuration management 跟監控，以及其開發用來進行監控 PFC pause frame 的數量和 latency 的工具。

此部分的最後一節做了一些 RDMA 的效能測試，可以發現 RDMA 在 latency 和 throughput 上相比 TCP 有非常大的進步。但是最後也提到 RDMA 不是能夠同時提供高 throughput 跟 low latency 的萬能藥。

Experiences

最後的章節主要在講解 Microsoft 實際在環境上線後遇到的問題以及其解決方式，並述說了他們對 RoCEv2 這個技術的看法以及疑問點，最後也提供了了一些探討其他 RDMA 技術如 Infiniband 跟 iWARP 的相關研究。

Conclusion

這篇論文介紹了 Microsoft 在資料中心 RDMA 技術的實作以及遭遇問題的解決方法。最後在 future works 也提出了一些未來可以持續探討的議題，如資料中心間的低延遲網路，不同架構中 deadlock 解決方法和如何同時提供高頻寬跟低延遲。

感想

筆者認為此片論文非常值得一讀，除了能夠了解 RDMA 技術如何在網路中傳輸，Microsoft 在整個 troubleshooting 的經驗與方式值得設計跟佈署 Infrastructure 工程師學習

RDMA over Commodity Ethernet at Scale – 論文導讀