Abstract

在過去一年半的時間，我們已經使用RoCEv2來支援一些微軟高可靠性、延遲敏感的服務。本篇論文講述了在此過程中遇到的挑戰以及解決方案。為了把RoCEv2擴充套件到VLAN之外，我們設計了一個基於DSCP的優先順序流量控制機制（PFC）來確保大規模部署。我們已經解決了很多安全挑戰，比如PFC-減少死鎖、RDMA傳輸livelock以及NIC PFC暫停幀風暴問題。我們也建立了監控和管理系統來確保RDMA按照預期的方式工作執行。我們的經驗表明，大規模執行RoCEv2的安全和可擴充套件問題都可以被解決，RDMA可以代替TCP進行內部資料中心通訊，並且可以實現低延遲、低CPU開銷、高吞吐量。

傳統TCP/IP仍然佔據主導地位，但是不能滿足新一代DC工作負載的需求，有兩個原因：傳統TCP/IP的CPU負載太高，傳統TCP/IP延遲太高。

1.  Introduction

隨著線上服務和雲端計算的快速發展，大規模資料中心（DC）被建立在世界各處。連線DC中的伺服器需要高速、可擴充套件的資料中心網路。DCN的建立需要商用交換機和網絡卡。最先進的DCN必須支援DC中任何兩個伺服器之間Gb/s或更高的吞吐量。

在當今資料中心網路中，TCP/IP仍然是主導的傳輸/網路協議棧，但是傳統TCP/IP協議棧並不能滿足新一代DC工作負載的需求，有兩個原因：

1） OS核心中的資料包操作帶來的CPU開銷仍然很高，儘管做了很多硬體和軟體上的優化，比如解除安裝校驗和、LSO、RSS和適度中斷。在我們資料中心中的測量結果顯示，用8個TCP連線以40Gb/s傳送chew up6% 聚合CPU時間，才一個32核Intel Xeon E5-2690 Windows 2012R2 伺服器。使用8個TCP連線到達40Gb/s需要12%聚合的CPU時間，現代的資料中心是無法忍受這種高CPU開銷的。

2） 許多當代DC應用，比如Search，對網路延遲都是高度靈敏的。TCP不能提供需要的低延遲，即使平均流量負載是適當的，有兩個原因。第一，核心軟體產生的延遲有幾十毫秒；第二，由於網路擁塞，會有資料丟包現象出現，儘管很少，但並沒有在我們的資料中心中消失，這時因為資料中心固有的突發性。TCP通過超時或者快速重傳來恢復正常，而這兩種情況中，都有很大的延遲。

本篇論文總結了部署RcCEv2和RDMA以解決以上提出的在微軟資料中心的問題的經驗，RDMA是一種在不中斷CPU操作的前提下可以訪問遠端系統的方法，RDMA廣泛應用於高效能運算中，以Infiniband為架構，RoCEv2支援RDMA實現在乙太網上，而不是Infiniband。

和TCP不同，RDMA需要一個無損網路，也就是說，交換機中的緩衝區溢位不能引發資料包丟失，RoCEv2使用PFC來實現無損網路。

我們注意到，VLAN標籤被典型用於鑑別混合RDMA/TCP部署中的支援PFC的流量。我們將討論，這種解決方案不會出現在我們的環境中。因此。我們提出了基於PFC的DSCP（Differentiated Services Code Point）概念，把RDMA從二層VLAN擴充套件到三層IP。

我們的RDMA部署已經順利運行了一年半，支援了微軟的一些高可靠、延遲敏感的線上服務。經驗表明，通過改進RoCEv2的設計、解決不同的安全問題、建立需要的管理和監控功能，我們可以使用商用乙太網，把RDMA安全地部署在大規模資料中心中。

2.  Background

我們的資料中心網路是一個基於乙太網的多層Clos網路。20-40個伺服器連線到一個top-of-rack（ToR，頂層機架）交換機，數十個ToR連線到葉子交換機層。葉子交換機反過來連線到數十到上百個Spine交換機層上。大多數鏈路是40Gb/s，我們計劃在不久的將來更新到50GbE和100GbE，所有的交換機都是使用IP路由。

伺服器和使用大約2米的銅電纜連線到ToR交換機，ToR交換機和葉子交換機之間有10-20米的距離，leaf和spine交換機之間有200-300米。三層交換機將數以萬計的伺服器連線到一個數據中心，本篇論文中，我們的關注點是同一個spine交換機層下的若干伺服器之間的支援RDMA。

RoCEv2：部署RoCEv2是基於技術和經濟的兩個原因。RoCEv2在一個Ethernet/IPv4/UDP資料包中解封裝一個RDMA傳輸包，使得RoCEv2和我們執行緒的網路基礎設施相相容，基於ECMP的多路徑路由需要UDP頭部，目的UDP埠通常設定為4791，源UDP埠對每個QP是隨機選擇的。中間交換機使用標準的五元組雜湊。因此，屬於同一個QP的流量有相同的路徑，而不同QP中的流量可以有不同的路徑（甚至在同一對通訊終端之間）。

PFC和buffer預留：RoCEv2使用PFC來防止緩衝區溢位。PFC標準指定了8個優先順序種類，來減少head-of-line阻塞問題。但是，在我們的網路中，RDMA只能使用8箇中的兩個優先順序。原因如下：

PFC是一個在兩個乙太網節點之間的逐跳協議。傳送者的egress port把資料傳送到接收者的ingress port，傳送埠把資料包放到最多8個佇列中進行排隊，每個佇列對應一個優先順序，接收埠把資料包快取到對應的接收佇列中。在我們網路中使用的共享緩衝區的交換機中，一個接收佇列被作為一個counter簡單地實現，所有的資料包共享一個通用的buffer池。

一旦接收佇列的長度達到了一定閾值（XOFF），交換機會發送PFC暫停幀到對應的上流egress queue。在egress佇列接收到暫停幀的時候，就會停止傳送資料包。暫停幀中包含了需要暫停的優先順序佇列和暫停時間。一旦接收佇列的長度小於另一個閾值（XON），交換機會發送一個0持續時間的暫停幀給egress queue來恢復傳輸。XOFF的值必須能夠保證沒有buffer overflow，XON來保證沒有緩衝區buffer underflow。（overflow表示緩衝區已滿，不能再寫入了，underflow表示緩衝區空的，不能讀取資料）。

暫停幀到達上游egree port會消耗一定時間，交換機反應也需要一定時間，所以在這段時間內，上游流量埠會繼續傳送資料包，所以ingress port必須給每個優先順序預留出緩衝區空間來儲存“gray period”收到的資料包，這個預留的buffer叫做headroom，其大小取決於MTU、egress port的PFC反應時間，以及最重要的，傳送者和接收者之間的傳播時延。

傳播時延取決於傳送者和接收者之間的距離。在我們的網路環境中，二者的距離最大是300米。ToR和leaf交換機有shallow buffers（9MB或者12MB），我們只能給兩個無損的流量類別預留充足的headroom，即使交換機支援8個流量類別。一個無損類別進行實時流量，另一個無損類別進行批量資料傳輸。

Need for congestion control：PFC是逐跳工作的，源和目的伺服器之間可能有多跳，如果有持續的網路擁塞，PFC暫停幀會從阻塞點傳播並返回到源，這就會導致諸如unfairness和victim flow的問題。

為了減少這些額外的問題，包括QCN、DCQCN和TIMELY在內的基於流量的擁塞控制機制應運而生。我們選擇使用DCQCN，本質是利用ECN進行擁塞警告，之所以選擇DCQCN，是因為它能直接對中間交換機的佇列長度進行響應，並且所有的交換機都支援ECN。小的佇列長度減少了PFC的產生和傳播機率。儘管DCQCN幫助減少了PFC暫停幀的數量，但是是PFC在保護資料包不被丟棄。PFC提出了一些安全問題，正的本論文的重點內容，第4部分會進行討論。我們相信，從本論文學到的經驗教訓同樣適用於使用TIMELY的網路。

Coexistence of RDMA and TCP：本論文中，RDMA是為intra-DC通訊設計的，而intra-DC和延遲應用仍然需要TCP，TCP使用一個不同的流量類（無損），不同的流量類別將TCP和RDMA的流量隔離開來。