目錄
Abstract
廣播模式在雲計算和數據中心設置中很常見。 Spark等應用程序和基礎架構工具經常移動大型對象，更新複製文件到多個節點，或者將新版本的程序推送到計算節點。 某些應用程序直接使用複製，例如，以提高容錯性或實現並行性。 爲了實現Paxos、區塊鏈和其他庫通常使用手工構建的可靠廣播爲單元。然而，操作系統仍然專注於TCP等點對點通信解決方案。 我們的系統RDMC（RDMA Multicast）提供從RDMA單播構建的可靠多播功能。 我們討論了設計選擇，提出了RDMC對延遲和慢速網絡鏈路的魯棒性的理論分析，並報告了評估RDMC對Mellanox RDMA的實驗。
1.Introduction
數據中心負載主要由數據複製延遲造成，通常是從源節點到兩個或更多目的地。 到2011年，像Cosmos（微軟），GFS（谷歌）和HDFS（Hadoop）這樣的分佈式文件系統每天處理許多PB的寫入（數百Gb / s）[6]，而今天的吞吐量肯定要高得多。 許多文件被複制到多個存儲服務器[8]。 此過程的延遲決定了最終用戶應用程序的整體寫入性能。 在Facebook中，Hadoop Trace顯示，對於MapReduce的作業Job，Reduce階段之間的數據傳輸佔總運行時間的33％[4]。 谷歌的Borg的任務啓動延遲中位數約爲25秒（大約80％專門用於軟件包安裝），在某些Cell中每分鐘開始執行的任務超過10,000個[22]。 在某些情況下，複製VM映像和輸入文件比計算需要更多的時間[19]。
儘管快速複製很重要，但缺乏有效的通用解決方案。 如今，雲中間件系統通常會以一次製作一個副本的方式將新數據推送到節點上去。 內容共享通常通過中間緩存或一個key-value層來處理，這可以很好地擴展，但會引入額外的延遲和複製。 在像Hadoop這樣的並行平臺中，調度程序通常可以預期一組任務將讀取同一文件，但除非數據恰好在本地緩存，否則它將在每個任務打開並訪問該文件時進行點對點移動。 通過將這種交互識別爲共同模式的實例，雲系統可以顯着提高效率。 這樣做可以恢復當前因無關傳輸和不需要的複製而丟失的網絡帶寬和CPU時間。 對於時間關鍵的用途，這樣的原語會減少陳舊性。
我們的RDMA多播協議RDMC解決了這個問題，提供了更高的速度和更低的資源利用率。 RDMC實例化成本低廉，並提供類似於N個並排TCP鏈路的可靠性語義，每個接收器一個。 該協議對於中斷也很穩健並且提供了公平的帶寬劃分，因爲我們使用實驗證明RDMC暴露於調度延遲，鏈路擁塞和重疊交付模式。
RDMC還可以擴展以提供更強大的語義。在其他地方報道的工作中，我們描述了Derecho [9]：一個新的開源軟件庫，分佈在RDMC上，支持原子組播以及經典的持久Paxos。 爲了獲得這些屬性，Derecho引入了一個小延遲，在此期間接收者緩衝消息和交換狀態信息。 當已知RDMC消息已到達所有目的地時，這時候數據發送完成。 不會出現帶寬損失，增加的延遲非常小。
本文件的貢獻如下：
•我們詳細描述了RDMC，展示瞭如何將廣播傳輸映射到RDMA單播操作的有效模式。
•我們對系統進行了廣泛的評估。
•我們表明RDMC對調度和網絡延遲具有魯棒性，並討論了在極少發生傳輸失敗的情況下恢復的選項。
•我們認爲，由於RDMC生成確定性塊傳輸模式，因此它爲將可靠多播直接卸載到NIC上提供了一個墊腳石。
2. Background On RDMA
RDMA（遠程直接存儲器訪問）是零拷貝通信標準。 它已在Infiniband上使用多年，但現在也在標準數據中心以太網上運行穩健。
RDMA是一種用戶空間網絡解決方案，可通過queue pair訪問：這是一種無鎖的數據結構共享user code 和 網絡控制器（NIC），包括髮送隊列和接收隊列。 RDMA支持多種操作模式。 RDMC。 RDMC使用可靠的雙邊RDMA操作，其行爲與TCP類似。使用此模式，發送方和接收方將其各自的隊列對綁定在一起，從而創建由NIC端點完全實現的會話。通過將Memory Region發佈到發送隊列來發出發送，並且進程通過將Memory Region發佈到接收隊列來指示其準備接收。然後，發送方NIC將傳輸數據，等待硬件級別的確認。在指定的超時後，NIC重試;在指定次數的重試之後，它會中斷連接並報告失敗（如下所述，除非接收器準備就緒，否則RDMC不會開始發送，因此連接斷開表示網絡或端點出現故障）。一旦發送了發送和匹配的接收，數據將直接從發送方的內存複製到接收方的指定位置，並且可以硬件和硬件支持的全速率複製。RDMA 通過一個完成隊列報告結果。不需要端到端軟件重發或確認：硬件提供正確的數據（按FIFO順序）並報告成功或連接中斷。
如果進程P和Q希望建立雙向RDMA連接，則它們必須首先交換密鑰形式（RDMA缺少相當於TCP偵聽操作，並且沒有硬件層3次握手）。 RDMC可以支持多個重疊sessions，並且可以根據需要創建它們，因此可以在沒有警告的情況下生成交換密鑰。 爲了最大限度地減少延遲，RDMC創建了一整套N * N TCP連接設置和故障報告，如下所述。
RDMA提供了幾種附加模式：one-side RDMA READ和WRITE（Q授權P直接訪問某些存儲區域），數據內聯，不可靠的點對點數據報和不可靠的組播。 這些功能適用於小型傳輸，並且由於RDMC專注於大型傳輸，我們沒有發現它們有用，但有一個例外：當每個接受者準備接受傳入傳輸時，它會進行單向寫入以告知發送方 ，只有在準備完畢後纔開始發送。
RDMA NIC可編程性的演變。人們對可編程網絡設備越來越感興趣。 對於RDMA NIC，這可能會引入新的請求排序選項。
現如今的RDMA網卡保證兩種方式：（1）在單個發送或接收隊列中排隊的請求將按FIFO順序執行（2）只有在傳入傳輸完成後纔會發生接收完成。 Mellanox的CORE-Direct [14]功能提出了第三種請求排序形式：可以將RDMA發送入隊，該RDMA發送將等待先前請求完成，以及完成其他一些RDMA發送或接收， 甚至可能在不同的隊列對上。 在節點Q需要將從P接收的數據重新存儲到另一個節點R的情況下，這避免了Q處的軟件延遲在接收完成之後發出中繼操作。 我們相信CORE-Direct只是最終廣泛的新RDMA NIC可編程功能之一。
RDMC旨在預測這一趨勢，儘管硬件功能尚未完全成熟，因此對潛力的嚴格評估將需要額外的工作。 RDMC可以預先計算數據流圖，描述每個廣播發送開始時的完整數據移動模式。 因此，複製組的成員可以在傳輸開始時發佈數據流圖，並通過跨節點發送/接收依賴關聯。 然後硬件將在沒有進一步幫助的情況下執行整個傳輸。 卸載將消除對任何軟件操作的需要，但會產生一個有趣的調度難題：如果操作一旦可能就執行，則可能出現優先級反轉，從而將緊急操作延遲一個實際上具有大量調度鬆弛的操作。 隨着這些新硬件功能的成熟，我們希望能夠探索這些問題。
3. High level RDMC summary
我們使用上述雙邊RDMA操作實現了RDMC。 基本要求是創建RDMA廣播模式，以有效地執行所需的廣播。 在下面的討論中，術語消息指的是傳輸的整個最終用戶對象：它可能是幾百兆字節甚至幾千兆字節。 小消息作爲單個塊發送，而大消息作爲一系列塊發送：這允許中繼模式，其中接收器同時用作發送器。 中繼的好處是它允許充分利用接收器NIC的傳入和傳出帶寬。 相比之下，使用單個大型廣播傳輸發送對象的協議是有限的：任何給定節點一次只能在一個方向上使用其NIC。
這產生了一個框架，其操作如下：
- 對於每個RDMC傳輸，發送方和接收方首先創建多路綁定的覆蓋網格：RDMC Group。 這種情況發生在帶外，使用TCP作爲引導捆綁協議。 RDMC是輕量級的，可以支持大量重疊組，但爲了最大限度地減少引導延遲，執行重複傳輸的應用程序應該在可行時重用組。
- 每次傳輸都是作爲一系列可靠的單播RDMA傳輸進行的，沒有重傳。 RDMC在開始時計算髮送和接收的序列，並將它們排隊以儘可能異步地運行。 如前所述，最終將整個序列卸載到可編程NIC是可行的。
- 在接收端，RDMC通知用戶應用程序傳入消息，並且它必須發佈一個接收字節的正確大小的緩衝區
- 在發送方按發送順序發送完成。 傳入的消息保證不會被破壞，並且按照發送者的順序到達，不會被破壞。
- 如果一個NIC中有多個活動傳輸，則RDMA會公平地分配帶寬。 RDMC擴展了這一屬性，爲重疊Group提供了公平性。
- 如果RDMA連接失敗，則非崩潰的端點將從其NIC中瞭解該事件。 RDMC轉發這些通知，以便所有倖存者最終了解該事件。 然後，應用程序可以通過關閉舊的RDMC會話並啓動新的RDMC會話來進行自我修復。
4. System Design
4.1 External API
圖1顯示了RDMC接口，省略了塊大小等配置參數。 發送和銷燬組功能是不言自明的。 所有組成員同時調用create_group 函數（具有相同的成員信息）; 我們使用前面提到的帶外TCP連接來啓動此步驟。 create group有兩個回調函數，用於通知應用程序事件。 當新的傳輸開始時，接收者觸發incoming消息回調，並且還用於獲取將消息寫入的Memory Region。 由於內存註冊成本很高，因此我們會在啓動之前，在任何通信活動發生之前執行此步驟。
一旦消息發送/接收在本地完成並且可以重用相關的Memory Region，則觸發消息完成回調。請注意，這可能發生在其他接受者完成消息之前，或者甚至在其他接收器發生故障之後。
在Group內，只允許一個節點（“root”）發送數據。 但是，應用程序可以自由創建具有相同成員資格但不同發件人的多個Group。 請注意，Group Member身份在創建後是靜態的：要更改Group的成員身份或root，應用程序應銷燬該組並創建一個新組。
4.2 Architectural Details
RDMC作爲用戶空間庫運行。 圖2顯示了其體系結構的概述。
Initialization. 當應用程序首次啓動時，其成員必須初始化RDMC。 此時，RDMC創建前面提到的TCP連接網格，註冊內存，創建單個RDMA完成隊列，並準備其他內部數據結構。 稍後，在運行時，所有RDMC會話共享一個完成隊列和線程，從而減少開銷。 爲避免在沒有I / O發生時輪詢，完成線程在每次完成事件後輪詢50 ms，然後切換到中斷驅動的完成模式。 它會在下一個事件中切換回輪詢。
Data Transfer. 雖然我們將主要關注二項式流水線算法，但RDMC實際上實現了幾種數據傳輸算法，這使得可以進行直接的並排比較。 要在RDMC中使用，發送算法必須保留髮送順序，將消息發送映射到塊傳輸的確定序列。
當發送方發起傳輸時，我們的第一步是告訴接收方傳入消息的大小，因爲任何一個RDMC組都可以傳輸各種大小的消息。 在這裏，我們利用RDMA功能，允許數據包攜帶整數“immediate”值。 消息中的每個塊都將以立即值發送，指示其所屬消息的總大小。 因此，當建立RDMC Group時，接受者發出一個receive請求用於初始化已知block塊的大小。 當此塊到達時，immediate Vaule允許我們確定完整的傳輸大小，並且（如果需要）爲整個消息分配空間。 如果將發送更多塊，接受者可以根據需要發佈其他異步Receive 請求，並行地將第一個塊複製到接收區域的開頭。 然後，在傳輸結束時，爲下一條消息的第一個塊發佈新的Receive 請求。
發送方和每個接收方將調度視爲一系列異步步驟。 在每個步驟中，每個參與者要麼空閒，要麼做一些發送塊和接收塊的組合。 最有效的計劃是雙向的：它們最大化節點發送一個塊的程度，同時接收一些其他塊。 給定異步步驟編號，可以精確地確定這些塊將是哪些塊。 因此，當每個接收器爲下一個塊發佈內存時，它可以精確地確定將到達哪個塊並選擇正確的偏移到接收Memory Region中。 類似地，在每個步驟中，發送者知道接下來要發送哪個塊以及向誰發送。 我們的設計通常避免任何形式的帶外信令或其他協議消息，但有一個例外：爲了防止塊過早發送，每個節點將等待從目標接收準備好的塊消息，以便它知道目標準備就緒。 通過確保發送方永遠不會啓動，直到接收方準備就緒，我們避免了代價高昂的退避/重傳延遲，並消除了連接可能因爲某個接收方有一個調度延遲並且沒有及時發佈內存而導致斷開的風險。 我們還大幅減少任何一個廣播所使用的NIC資源量：如果併發活動的接收緩衝區數超過NIC緩存容量，則今天的NIC表現出性能下降。 RDMC每組只有一些少數的receiveers，並且由於我們預計不會有大量併發活躍Group，因此避免了這種形式的資源耗盡。
4.3 Protocol
鑑於這種高級設計，最明顯和最重要的問題是用於從一系列點對點單播構建多播的算法。 RDMC實現多種算法; 我們將按照提高效率的順序對它們進行描述。
Sequential Send. 順序模式在今天的數據中心很常見，對於小消息來說是一個很好的選擇。 它實現了從發送者一個接一個地將整個消息傳遞給每個接收者的簡單解決方案。 由於單個RDMA傳輸的帶寬幾乎是線速，因此該模式實際上與同時運行N個獨立的點對點傳輸相同。
請注意，對於順序發送，在創建B位消息的N個副本時，發送方的NIC將產生N * B位的IO負載。 副本將接收B位，但不發送。 對於大量消息，這會導致NIC資源使用不佳：100Gbps NIC可能會發送和接收100Gbps的數據。 因此，順序發送會在發送方處創建熱點。
Chain Send. 該算法實現了一個bucket-brigade，類似於[21]中描述的鏈複製方案。 在將消息分成塊之後，該隊中的每個內部接收器在接收它們時都會轉發塊。 中繼器使用它們的完全雙向帶寬，但是它們越往下走，它們在第一次阻塞之前就處於空閒狀態的時間越長，因此最壞情況下的延遲很高。
Binomial Tree. 對於大型對象，如果發送者發送完整的消息，則接收者可以獲得更好的性能，接收者一旦獲得它就會中繼每個消息，如圖3（左）所示。箭頭上的標籤表示異步時間步長。這裏，發送方0通過向接收方1發送一些消息開始。然後並行，0發送到2而1發送到3，然後在最後一步0發送到4,1發送到5,2發送到6和3發送由此產生的發送模式追溯到二叉樹，因此延遲將優於順序發送，但是在內部傳輸完成之前，內部傳輸無法啓動。對於小規模的轉移，這是不可避免的，但請記住，RDMC的目標是轉移通常非常大的情況。理想情況下，我們希望通過將大型傳輸分成一系列較小的塊並對塊傳輸進行流水線操作來提高鏈路利用率，同時通過利用二叉樹路由模式最大限度地減少延遲。
Binomial Pipeline. 通過將Chain Send與二叉樹結合起來，我們可以實現這兩個目標，這是Ganesan和Seshadri首先做出的觀察[7]。該算法通過創建維度d的虛擬超立方體疊加來工作，其中d個不同的塊將被同時中繼（圖3，中間，其中塊由紅色，綠色和藍色表示）。每個節點重複執行一次發送操作和一次接收操作，直到最後一步它們全部同時接收到它們的最後一個塊（如果節點數不是2的冪，則最終收據分佈在兩個異步上腳步）。 Ganesan和Seshadri的原創作品是理論性的，並通過模擬驗證。此外，他們假設網絡是同步的。我們將他們的方法擴展到完全異步設置，其中一個節點正在等待一個節點發送一個塊。我們還解除了發送和接收步驟的耦合，以便只有在未收到相關塊的情況下，發送步驟纔會掛起。結果算法非常有效，因爲它可以快速達到其滿載傳輸模式，確保節點在發送和接收塊的同時花費儘可能多的時間。
Hybrid Algorithms. 當前的數據中心隱藏了網絡拓撲，以防止可能會破壞更廣泛的管理目標的應用程序行爲。但是，假設有人正在爲數據中心範圍的使用構建基礎結構服務，並且可以使用這種形式的信息。許多數據中心在逐個機架的基礎上具有完全的二分帶寬，但使用某種形式的超額訂購機架式（TOR）交換機來連接不同的機架。當二項式流水線多播在這樣的設置中運行時，大部分傳輸操作都會穿過TOR交換機（這是因爲如果我們使用隨機節點對構建覆蓋，許多鏈路將連接位於不同機架中的節點） 。相反，假設我們使用二項式管道的兩個獨立實例，一個在TOR層，另一個在機架內。通過這樣做，我們可以爲每個機架領導者提供一條消息的副本，以創建更高負載的突發，但是高效並且實現最低可能的延遲和傾斜。然後我們重複在機架內的傳播，並再次最大化帶寬，同時最小化延遲和歪斜。
4.6 Insights from Using RDMA
我們現在有多年的RDMC在各種設置方面的經驗，並在我們自己的Derecho平臺中使用它。 這些活動產生了一些見解。
Recovery From Failure. 如前所述，RDMC Group的行爲很像從發送方到每個接收方的一組並排TCP連接。 雖然當單個RDMA連接報告問題時會感覺到故障，但我們的中繼故障信息的策略會迅速收斂到中斷的RDMC Group停止新傳輸的狀態，並且所有幸存的端點都知道故障。 此時，某些接受者可能已成功接收並傳遞其他接受者尚未完成接收的消息。
爲了理解由此產生的恢復挑戰，我們可以詢問發送方在第一次得知其RDMC Group失敗時“知道”了什麼。 正如TCP發送方沒有得知TCP窗口中的數據已被接收和處理，除非引入某種形式的端到端確認，RDMC發送方信任RDMC完成其工作。 如果一個組用於一系列傳輸，則發送方將缺乏關於最近傳輸的消息的狀態的確定性（RDMC不提供端到端狀態報告機制）。 另一方面，如果出現問題，所有RDMC集團成員都會感受到中斷。 此外，關閉（銷燬）RDMC組時將始終報告故障。 因此，如果Group關閉操作成功，則發送方（以及所有接收方）可以確信每個RDMC消息到達每個目的地。
對於介紹中列出的大多數目的，此保證就足夠了。 例如，如果多播文件傳輸完成且關閉成功，則文件已成功傳遞給完整的接收者，沒有重複，遺漏或損壞。 相反，如果轉移失敗，每個接收者都會得知這一點，文件傳輸工具可以簡單地重試倖存成員內的轉移。 如果該工具正在傳輸一長串文件並且重新發送它們的成本是一個問題，它可以實現端到端狀態檢查以確定哪些不需要重新發送。
尋求更強保證的系統也可以利用RDMC。 例如，Derecho使用單邊RDMA Write實現了複製狀態表來擴充RDMC [9]。 收到RDMC消息後，Derecho會暫時緩衝它。 只有在每個接收者都有一個消息副本之後纔會發送，接收者通過監視狀態表來發現。 當故障中斷RDMC組時，將使用類似形式的分佈式狀態跟蹤。 在這裏，Derecho使用基於領導者的清理機制（再次基於單邊RDMA WRITE協議）從所有生存節點收集狀態，分析結果，然後告訴參與者哪些緩衝消息要傳遞，哪些 放棄。 通過一系列此類擴展，Derecho能夠提供全套Paxos保證，但它仍然可以通過RDMC傳輸所有消息。
Small Message. RDMC針對批量數據移動進行了優化。 這裏報道的工作只關注大型消息案例。 Derecho包括一個小消息協議，它使用單側RDMA寫入一組循環有界緩衝區，每個接收器一個，並將該方法的性能與RDMC的性能進行比較。 總之，與RDMC相比，優化的小消息協議可以獲得高達5倍的加速，前提是該組足夠小（最多約16個成員）並且消息足夠小（不超過10KB）。 對於較大的組或較大的消息，以及可以批量處理的長串消息，二項式管道占主導地位。
Memory Management. RDMC提供靈活的內存管理。 在此處報告的實驗中，我們預先註冊將與RDMA NIC一起使用的內存區域，但在第一個塊出現時爲每個新消息分配內存。 因此，接收器在關鍵路徑上執行對malloc的調用。 在可以提前計劃的應用程序中，可以通過在一系列傳輸開始之前執行內存分配來實現更好的性能。
5. Experiments
5.1 Step
我們在幾個配備有不同內存和NIC硬件的集羣上進行了實驗。
Fractus Fractus是一個由16個支持RDMA的節點組成的集羣，運行Ubuntu 16.04，每個節點配備4x QDR Mellanox NIC和94 GB DDR3內存。 所有節點都連接到100 Gb / s Mellanox IB交換機和100 Gb / s Mellanox RoCE交換機，並且具有相互之間的單跳路徑。
Sierra. 勞倫斯利弗莫爾國家實驗室的Sierra集羣由1,944個節點組成，其中1,856個節點被指定爲批量計算節點。 每個都配備兩個6核Intel Xeon EP X5660處理器和24GB內存。 它們通過Infiniband結構連接，該結構被構造爲兩階段，聯合，雙向，胖樹。 NIC是4x QDR QLogic適配器，每個適配器以40 Gb / s的線速運行。 Sierra集羣運行TOSS 2.2，這是Red Hat Linux的修改版本。
Stampede-1. U. Texas Stampede-1集羣包含6400個C8220計算節點和56 Gb / s FDR Mellanox NIC。 與Sierra一樣，它是批量安排的，幾乎無法控制節點位置。 我們測量的單播速度高達40 Gb / s。
Apt Cluster. EmuLab Apt集羣包含總共192個節點，分爲兩類：128個節點具有單個Xeon E5-2450處理器和16 GB RAM，而64個節點具有兩個Xeon E5-2650v2處理器和64 GB RAM。 它們都有一個FDR Mellanox CX3 NIC，能夠達到56 Gb / s。
有趣的是，Apt有一個明顯超額訂購的TOR網絡，當負載較重時，每個鏈路降級到大約16 Gb / s。 這使我們能夠在一些網絡鏈路比其他網絡鏈路慢得多的情況下查看RDMC的行爲。 雖然這種情況似乎非常適合採取下一步並嘗試混合協議，但事實證明這是不切實際的：Apt像Sierra一樣是批量調度的，無法控制節點佈局，我們無法動態發現網絡拓撲。
我們的實驗包括緊密複製當今雲平臺中的RDMA部署的案例。 例如，Microsoft Azure通過Infiniband提供RDMA作爲其Azure Compute HPC框架的一部分，許多供應商在他們自己的基礎設施工具中使用RDMA，無論是在Infiniband還是在RoCE上。 然而，暴露RoCE的大規模終端用戶測試平臺尚不可用：運營商顯然擔心大量使用RoCE會觸發數據中心範圍的不穩定性。 我們希望DC-QCN的推出能夠讓運營商放心，然後運營商會看到允許其用戶訪問RoCE的明顯好處。
在我們的所有實驗中，發送方生成包含隨機數據的消息，並且我們測量從發送提交到庫的時間到所有客戶端都獲得指示多播已完成的上行調用的時間。 發送的最大消息具有在傳輸視頻的應用程序中或在將大圖像推送到數據分析環境中的計算節點時可能出現的大小。 選擇較小的消息大小以匹配複製照片或XML編碼消息等任務。 帶寬計算爲發送的消息數，乘以每個消息的大小除以花費的總時間（無論接收器的數量）。 RDMC不管道消息，因此多播的延遲只是消息大小除以其帶寬。
5.2 Results
圖4比較了所考慮的不同算法的相對性能。 爲了比較，它還顯示了MVAPICH的高度優化的MPI Bcast（）方法的吞吐量，MVAPICH是一個在Infiniband網絡上實現MPI標準的高性能計算庫（我們使用單獨的基準測試套件測量）。 隨着節點數量的增加，順序發送和二叉樹都表現不佳。 同時，鏈發送與二項式管道競爭，除了小型轉移到大量節點，其中二項式提前。 MVAPICH介於兩者之間，與二項式管道一樣，從1.03倍到3倍。 在本文的其餘部分，我們主要關注二項式管道，因爲它在一系列設置中具有強大的性能，但我們注意到鏈式發送由於其簡單性通常很有用。
5.2.1 Microbenchmarks
在表1中，我們分析了在Stampede上進行單個256 MB傳輸（1 MB塊）和組大小爲4（意味着1個發送器和3個接收器）的時間。 所有值均以微秒爲單位，並且在距離根最遠的節點上進行測量。 因此，遠程設置和遠程塊傳輸反映了根要發送和第一個接收器進行中繼所花費的時間總和。 大約99％的總時間花費在遠程塊傳輸或塊傳輸狀態（其中網絡被充分利用）中，這意味着來自RDMC的開銷僅佔傳輸所花費時間的大約1％。
圖5檢查了相同的發送，但顯示了轉發器（其時間在表中報告）和根發送方的每個傳輸步驟的時間使用情況。 在消息傳輸結束時，我們看到兩個已檢測節點上的等待時間異常長。 事實證明，這證明了RDMC如何容易受到各個節點延遲的影響。 在這種情況下，繼電器上大約100μs的延遲（可能是由操作系統選擇不合時宜的時間來阻止我們的過程）迫使發送方在發現其下一個區塊的目標不是時，推遲到下一步驟。 準備好了。 CORE-Direct功能可以減輕這種影響。
在圖6中，我們檢查了塊大小對一系列消息大小的帶寬的影響。 請注意，增加塊大小最初會提高性能，但會達到峯值。 由於存在兩個相互競爭的因素，因此實際上可以預期這一結果。 每個塊傳輸都涉及一定的延遲，因此增加塊大小實際上會增加信息在鏈路上移動的速率（隨着塊大小的增大，收益遞減）。 但是，與二項式流水線算法相關的開銷與傳輸單個塊所花費的時間量成正比。 當消息中沒有足夠的塊使所有節點有效地爲傳輸做出貢獻時，還會產生額外的開銷。
最後，圖7測量了使用二項式管道每秒傳遞的1字節消息的數量，同樣在Fractus上。 但請注意，二項式管道（以及整個RDMC）並不是真正意圖作爲高速事件通知解決方案：我們是否主要關注以儘可能高的速度傳遞非常小的消息，以及 儘可能低的延遲，我們可以探索的其他算法在大多數條件下都優於RDMC的這種配置。 因此，RDMC的1字節行爲作爲理解開銷的方式比其實際性能更有意義。
5.2.2 Scalability
圖8比較了Sierra上的二項式管道與順序發送的可擴展性（趨勢很明顯，Sierra是一個昂貴的系統，因此我們推斷了512節點的順序發送數據點）。 雖然序列發送量在接收器數量上呈線性變化，但二項式管道在線性上進行縮放，這在創建大量大型對象副本時會產生巨大的差異。 這個圖表帶來了令人驚訝的見解：使用RDMC，複製幾乎是免費的：無論是製作127,255還是511副本，所需的總時間幾乎相同。
雖然我們沒有單獨繪製傳輸結束時間，但二項式管道傳輸幾乎同時完成：這最大限度地減少了時間偏差，這在並行計算設置中很重要，因爲許多此類系統運行爲一系列鬆散同步的步驟，最終以 某種形式的shuffle或all-to-all數據交換。 Skew可以讓整個系統空閒等待一個節點完成。 相反，順序發送的線性劣化也與高偏斜相關。 這凸顯了當今大多數雲計算框架中使用的技術的非常差的性能：不僅複製副本複製緩慢，而且它還會中斷需要等待轉移到所有完成的計算，或者應該運行的計算 鬆散同步的階段。
接下來，我們開始研究RDMC在應用程序中的行爲，這些應用程序向重疊組發出大量併發多播。 我們從Microsoft的Cosmos系統的數據複製層獲取了一個跟蹤樣本，這是Bing平臺使用的數據倉庫。 Cosmos目前在TCP / IP網絡上運行，不使用RDMA或多播。 跟蹤有數百萬個3節點寫入，隨機目標節點和對象大小從數百個字節到數百MB不等（中位數爲12MB，平均值爲29 MB）。 許多轉移都有重疊的目標羣體。
爲了模擬Cosmos工作負載的多播使用，我們指定了一個Fractus節點來生成流量，並指定了15個節點來託管副本。系統通過生成填充有隨機內容的對象來操作，這些對象具有與跟蹤中看到的相同的大小，然後通過隨機選擇一個可能的3節點分組作爲目標來複制它們（事先創建了所需的455個RDMC組，以便這樣做將離開關鍵路徑）。圖9顯示了3種不同發送算法的延遲分佈。請注意，二項式管道的速度是二項式樹的兩倍，速度是順序發送速度的三倍。使用二項式管道運行時的平均吞吐量大約爲93 Gb / s的複製數據，相當於每天大約1 PB。我們幾乎達到了Fractus的完全二分能力，並沒有在併發重疊傳輸之間產生干擾的跡象。 RDMC數據模式對此工作負載非常高效：任何網絡鏈路上都不會發生冗餘數據傳輸。
第二個實驗以更加受控的方式查看具有固定多播消息大小的組重疊。在圖10中，我們構造了由X軸標籤給出的大小的組。這些集合具有相同的成員（例如，8節點的情況總是具有相同的8個成員），但是不同的發送者。在每個尺寸，我們進行3次實驗，改變發送者的數量。 （1）在對應於實線的實驗中，所有成員都是發送者（因此我們有8個完全重疊的組，每個組具有相同的成員，但是不同的發送者）。 （2）用虛線表示，重疊組的數量是一半大小：成員的一半是發送者。 （3）最後，虛線顯示跨越所有成員但具有單個發送者的單個組的性能。所有發件人都以最大速率運行，發送指定大小的消息。然後我們通過測量將給定大小的消息傳送到所有重疊組的時間，併除以消息大小乘以組的數量（即發送的總字節數）來計算帶寬。
同樣，我們看到測試系統的全部資源得到了有效利用。在Fractus上，具有100Gbps的完全二分能力，我們的峯值速率（在併發發送器的模式中看到）非常接近極限，至少對於較大的消息大小。在Apt上，具有超額認購的TOR，對於這種通信模式，二分帶寬接近16Gbps，並且我們的圖也這樣做，至少對於較大的組（其產生足夠的負載以使TOR開關飽和）。
5.3 Future Work：RDMC On TCP
當Ganesan和Seshadri首次探索多播覆蓋拓撲時，他們表示擔心即使是單個滯後節點也可能導致級聯延遲，影響每個參與者並限制可擴展性[7]。這使他們將工作重點放在專用的，同步的HPC設置上，證明假設節點將以鎖步方式運行而不會出現調度延遲或鏈路擁塞。
但是，今天的RDMA在多租戶環境中運行。即使是超級計算機也會承載大量工作，因此存在鏈路擁塞的風險。標準以太網設置中的RDMA使用類似TCP的擁塞控制（DCQCN或TIMELY）。然而，我們並未看到業績大規模崩潰。我們的鬆弛分析提出了一個可能的解釋：雙向管道生成塊傳輸計劃，其中有延遲節點有機會趕上。隨着我們擴大規模，各種延遲確實會發生。然而，這種鬆弛顯然可以彌補，減少經濟放緩。
該觀察結果具有一個有趣的實際結果：它表明RDMC可能比高速數據中心TCP（沒有RDMA），甚至可能在WAN網絡中工作得更好。在仍在進行的工作中，我們正在通過OpenFabrics接口聯盟（OFI）[16]將RDMC移植到通過LibFabrics訪問RDMA。 LibFabrics是一個成熟的解決方案，用作HPC計算的消息傳遞接口（MPI）庫的最低層。該軟件包使用宏擴展方法，直接映射到RDMA以及其他硬件加速器，甚至是標準TCP。端口完成後，我們計劃在各種TCP設置中仔細研究RDMC的行爲。
6.Related Work
複製是一個豐富的軟件庫和系統領域。 我們已經提到了可靠的廣播，主要是爲了強調RDMC旨在複製數據，但並不打算提供相關的強組語義和廣播原子性。 Paxos是最著名的狀態機複製（共識）技術。 此類系統的示例包括經典的Paxos協議本身，我們的Derecho庫，libPaxos，Zookeeper的ZAB層，Corfu中的日誌機制，DARE和APU [1,9,10,12,13,18，24。 Derecho表明RDMC在Paxos解決方案中很有用，但在這樣做時還需要額外的機制：RDMC的語義比Paxos弱。
我們不是第一個詢問如何在操作系統中利用RDMA的人。 早期的RDMA概念本身可以追溯到Von Eicken和Vogels [23]的經典論文，該論文引入了零拷貝選項並重新編程了一個網絡接口以展示其優勢。 VIA，隨後出現了虛擬接口架構; 其“Verbs”API擴展了UNet的想法，以支持Infiniband，Myrinet，QLogic和其他供應商的硬件。 RDMC使用的Verbs API是廣泛標準的，但其他選項包括RDMA的QLogic PSM子集，Intel的Omni-Path Fabric解決方案，套接字級別的產品，如Chelsio WD-UDP [3]嵌入等。
儘管產品數量衆多，但似乎有理由斷言迄今爲止最大的成功是與Infiniband RDMA的MPI平臺集成，後者已成爲HPC通信的支柱。 MPI本身實際上提供了類似於本文所述的廣播原語，但MPI強加的編程模型有許多限制，使其不適合RDMC所針對的應用：（1）發送模式是事先知道的 因此，接收器可以在啓動之前預測任何廣播的確切大小和Root，（2）通過檢查點處理容錯，以及（3）作業中的一組進程必須在該作業的持續時間內保持固定。 即便如此，RDMC仍然比MPI的流行MVAPICH實施性能大幅提升。
廣播在CPU內核之間也很重要，而Smelt庫[11]提供了一種解決這一挑戰的新方法。 他們的解決方案並不直接適用於我們的設置，因爲它們處理的微小消息不需要增加被分解成塊的複雜性，但是自動推斷合理發送模式的想法很有趣。
雖然我們的重點是大量數據移動，但這裏的核心論點可能最接近於最近的操作系統論文，如FaRM [5]，Arrakis [17]和IX [2]。 在這些工作中，操作系統越來越多地被視爲控制平面，RDMA網絡被視爲數據平面的帶外技術，在最小的中斷時效果最佳。 採用這種觀點，可以將RDMC視爲非常適合帶外部署的通用數據平面解決方案。 最近使用RDMA優化數據庫的一個例子是Crail [20]。
7． Conclusion
我們的論文介紹了RDMC：一種新的可靠的內存到內存複製工具，通過RDMA單播實現。 RDMC可以作爲免費的開源庫下載，並且應該直接用於O / S服務，這些服務目前一個接一個地移動對象，或者通過多個並行TCP鏈接移動對象。 該協議還可以用作具有更強語義的更高級庫的組件。
與最廣泛使用的通用選項相比，RDMC性能非常高，並且協議可擴展到大量副本。 即使只需要3個副本，RDMC也會帶來好處。 事實上覆制相對於創建一個副本而言非常便宜：一個可以有4個或8個副本，價格幾乎與1相同，並且只需要幾倍的時間來製作數百個副本。另外，RDMC對各種延遲都很穩健：數據丟失和複製的正常網絡問題由RDMA處理，而RDMC的逐塊發送模式和接收器 - 接收器中繼補償偶爾的調度和網絡延遲。 RDMC代碼庫可作爲Dere- cho平臺（https://GitHub.com/Derecho-Project）的一部分下載。