摘要

遠(yuǎn)程過程調(diào)用（RPC）是分布式服務(wù)廣泛使用的一種技術(shù)。 這種技術(shù)現(xiàn)在越來越多地用于高性能計算 (HPC) 的上下文中，它允許將例程的執(zhí)行委托給遠(yuǎn)程節(jié)點，這些節(jié)點可以留出并專用于特定任務(wù)。 然而，現(xiàn)有的 RPC 框架采用基于套接字的網(wǎng)絡(luò)接口（通常在 TCP/IP 之上），這不適合 HPC 系統(tǒng)，因為此 API 通常不能很好地映射到這些系統(tǒng)上使用的本機網(wǎng)絡(luò)傳輸，從而導(dǎo)致網(wǎng)絡(luò)性能較低。 此外，現(xiàn)有的 RPC 框架通常不支持處理大數(shù)據(jù)參數(shù)，例如在讀取或?qū)懭胝{(diào)用中發(fā)現(xiàn)的參數(shù)。我們在本文中提出了一個異步 RPC 接口，專門設(shè)計用于 HPC 系統(tǒng)，允許參數(shù)和執(zhí)行請求的異步傳輸和直接支持大數(shù)據(jù)參數(shù)。 該接口是通用的，允許傳送任何函數(shù)調(diào)用。 此外，網(wǎng)絡(luò)實現(xiàn)是抽象的，允許輕松移植到未來的系統(tǒng)并有效使用現(xiàn)有的本地傳輸機制

1、簡介

當(dāng)在異構(gòu)環(huán)境中工作時，工程師或科學(xué)家能夠分配應(yīng)用程序工作流程的各個步驟通常非常有用； 尤其是在高性能計算中，通常會看到嵌入不同類型資源和庫的系統(tǒng)或節(jié)點，這些資源和庫可以專用于特定任務(wù)，例如計算、存儲或分析和可視化。 遠(yuǎn)程過程調(diào)用 (RPC) [1] 是一種遵循客戶端/服務(wù)器模型并允許對遠(yuǎn)程資源透明地執(zhí)行本地調(diào)用的技術(shù)。 它包括將本地函數(shù)參數(shù)序列化到內(nèi)存緩沖區(qū)并將該緩沖區(qū)發(fā)送到遠(yuǎn)程目標(biāo)，遠(yuǎn)程目標(biāo)反過來反序列化參數(shù)并執(zhí)行相應(yīng)的函數(shù)調(diào)用。 實現(xiàn)該技術(shù)的庫可以在各種領(lǐng)域中找到，例如使用 Google Protocol Buffers [2] 或 Facebook Thrift [3] 的 Web 服務(wù)，或者使用 GridRPC [4] 的網(wǎng)格計算等領(lǐng)域。 RPC 也可以使用更面向?qū)ο蟮姆椒ê涂蚣軄韺崿F(xiàn)，例如 CORBA [5] 或 Java RMI [6]，其中抽象對象和方法可以分布在一系列節(jié)點或機器上。

(資料圖片)

但是，在 HPC 系統(tǒng)上使用這些標(biāo)準(zhǔn)和通用的 RPC 框架有兩個主要限制：1. 無法利用本地傳輸機制有效地傳輸數(shù)據(jù)，因為這些框架主要是在 TCP/IP 協(xié)議之上設(shè)計的； 2. 并且無法傳輸非常大量的數(shù)據(jù)，因為 RPC 接口施加的限制通常是兆字節(jié)(MB)的數(shù)量級。 此外，即使沒有強制限制，通常也不鼓勵通過 RPC 庫傳輸大量數(shù)據(jù)，主要是由于序列化和編碼帶來的開銷，導(dǎo)致數(shù)據(jù)在到達(dá)遠(yuǎn)程節(jié)點之前被多次復(fù)制。

本論文組織如下： 我們首先在第二部分討論相關(guān)工作，然后在第三部分討論構(gòu)建接口的網(wǎng)絡(luò)抽象層，以及為高效傳輸小型和大型數(shù)據(jù)而定義的架構(gòu)。 第 IV 節(jié)概述了 API 并展示了其支持使用流水線技術(shù)的優(yōu)勢。 然后我們描述了我們接口的網(wǎng)絡(luò)傳輸插件的開發(fā)以及性能評估結(jié)果。 第五節(jié)提出結(jié)論和未來的工作方向

2、相關(guān)工作

網(wǎng)絡(luò)文件系統(tǒng) (NFS) [7] 是使用 RPC 處理大量數(shù)據(jù)傳輸?shù)囊粋€很好的例子，因此非常接近在 HPC 系統(tǒng)上使用 RPC。 它利用 XDR [8] 序列化任意數(shù)據(jù)結(jié)構(gòu)并創(chuàng)建獨立于系統(tǒng)的描述，然后將生成的字節(jié)流發(fā)送到遠(yuǎn)程資源，遠(yuǎn)程資源可以反序列化并從中取回數(shù)據(jù)。 它還可以使用單獨的傳輸機制（在最新版本的 NFS 上）通過 RDMA 協(xié)議傳輸數(shù)據(jù)，在這種情況下，數(shù)據(jù)在 XDR 流之外進(jìn)行處理。 我們在本文中介紹的接口遵循類似的原則，但另外直接處理批量數(shù)據(jù)。 它還不限于使用 XDR 進(jìn)行數(shù)據(jù)編碼，這可能會影響性能，尤其是當(dāng)發(fā)送方和接收方共享一個公共系統(tǒng)架構(gòu)時。 通過提供網(wǎng)絡(luò)抽象層，我們定義的 RPC 接口使用戶能夠使用小消息或遠(yuǎn)程內(nèi)存訪問 (RMA) 類型的傳輸有效地發(fā)送小數(shù)據(jù)和大數(shù)據(jù)，這些傳輸完全支持最近 HPC 系統(tǒng)上存在的單邊語義。 此外，所有呈現(xiàn)的接口都是非阻塞的，因此允許異步操作模式，防止調(diào)用者等待一個操作執(zhí)行后再發(fā)出另一個操作

I/O 轉(zhuǎn)發(fā)可擴(kuò)展性層 (IOFSL) [9] 是另一個項目，本文介紹的部分工作基于該項目。 IOFSL 使用 RPC 專門轉(zhuǎn)發(fā) I/Ocalls。 它定義了一個名為 ZOIDFS 的 API，它在本地序列化函數(shù)參數(shù)并將它們發(fā)送到遠(yuǎn)程服務(wù)器，在那里它們可以依次映射到文件系統(tǒng)特定的 I/O 操作。 擴(kuò)展 IOFSL 中已經(jīng)存在的工作的主要動機之一是能夠不僅發(fā)送一組特定的調(diào)用（如通過 ZOIDFS API 定義的調(diào)用），而且能夠發(fā)送各種調(diào)用，這些調(diào)用可以動態(tài)和通用地定義。 同樣值得注意的是，IOFSL 建立在并行虛擬文件系統(tǒng) (PVFS) [11] 中使用的 BMI [10] 網(wǎng)絡(luò)傳輸層之上。它允許支持動態(tài)連接和容錯，還定義了兩種類型的消息傳遞， 意外和預(yù)期（在第 III-B 節(jié)中描述），可以啟用異步操作模式。 然而，BMI 在其設(shè)計中受到限制，因為它沒有直接公開顯式實現(xiàn)從客戶端內(nèi)存到服務(wù)器內(nèi)存的 RDMA 操作所需的 RMA 語義，這可能是一個問題和性能限制（使用 RMA 方法的主要優(yōu)點在第 III 節(jié)中描述 - B). 此外，雖然 BMI 不提供單邊操作，但它確實提供了一組相對較高級別的網(wǎng)絡(luò)操作。 這使得將 BMI 移植到新的網(wǎng)絡(luò)傳輸（例如 CrayGemini 互連 [12]）成為一項重要的工作，并且比它應(yīng)該更耗時，因為在我們的上下文中實現(xiàn) RPC 只需要 BMI 提供的功能的一個子集

另一個項目，桑迪亞國家實驗室的 NEtworkScalable 服務(wù)接口 (Nessie) [13] 系統(tǒng)提供了一個簡單的 RPC 機制，最初是為 LightweightFile Systems [14] 項目開發(fā)的。 它提供了一個異步RPC的解決方案，主要是為了重疊計算和I/O而設(shè)計的。 Nessie 的 RPC 接口直接依賴于 Sun XDR 解決方案，該解決方案主要設(shè)計用于異構(gòu)架構(gòu)之間的通信，即使實際上所有高性能計算系統(tǒng)都是同構(gòu)的。Nessie 提供了一種單獨的機制來處理批量數(shù)據(jù)傳輸，它可以使用 RDMA 從一個高效地傳輸數(shù)據(jù) 內(nèi)存到另一個，并支持多種網(wǎng)絡(luò)傳輸。 Nessie 客戶端使用 RPC 接口將控制消息推送到服務(wù)器。 此外，Nessie 公開了一個不同的、單方面的 API（類似于 Portals [15]），用戶可以使用它在客戶端和服務(wù)器之間推送或拉取數(shù)據(jù)。Mercury 不同，因為它的接口本身也支持 RDMA，可以透明地處理 通過自動生成代表遠(yuǎn)程大數(shù)據(jù)參數(shù)的抽象內(nèi)存句柄為用戶提供批量數(shù)據(jù)，這些句柄更易于操作，不需要用戶做任何額外的工作。如果需要，Mercury 還提供對數(shù)據(jù)傳輸?shù)募?xì)粒度控制（例如，實現(xiàn)流水線）。 此外，Mercury 提供了比 Nessie 更高級的接口，大大減少了實現(xiàn) RPC 功能所需的用戶代碼量

另一種類似的方法可以在 Decoupledand Asynchronous Remote Transfers (DART) [16] 項目中看到。雖然 DART 未定義為顯式 RPC 框架，但它允許使用客戶端/服務(wù)器模型從計算節(jié)點上運行的應(yīng)用程序傳輸大量數(shù)據(jù) HPC 系統(tǒng)到本地存儲或遠(yuǎn)程位置，以實現(xiàn)遠(yuǎn)程應(yīng)用程序監(jiān)控、數(shù)據(jù)分析、代碼耦合和數(shù)據(jù)歸檔。 DART 試圖滿足的關(guān)鍵要求包括最小化應(yīng)用程序的數(shù)據(jù)傳輸開銷、實現(xiàn)高吞吐量、低延遲數(shù)據(jù)傳輸以及防止數(shù)據(jù)丟失。 為了實現(xiàn)這些目標(biāo)，DART 的設(shè)計使得專用節(jié)點（即與應(yīng)用程序計算節(jié)點分離）使用 RDMA 從計算節(jié)點的內(nèi)存中異步提取數(shù)據(jù)。 通過這種方式，從應(yīng)用程序計算節(jié)點到專用節(jié)點的昂貴數(shù)據(jù) I/O 和流操作被卸載，并允許應(yīng)用程序在數(shù)據(jù)傳輸?shù)耐瑫r進(jìn)行。雖然使用 DART 是不透明的，因此需要用戶發(fā)送明確的請求，但有 在我們的網(wǎng)絡(luò)抽象層中集成此類框架并沒有固有限制，因此將其包裝在我們定義的 RPC 層中，從而允許用戶在其支持的平臺上使用 DART 傳輸數(shù)據(jù)。

3、架構(gòu)

如前一節(jié)所述，Mercury 的接口依賴于三個主要組件：網(wǎng)絡(luò)抽象層NA、能夠以通用方式處理調(diào)用的 RPC 接口和批量數(shù)據(jù)接口(Bulk)，它補充了 RPC 層，旨在輕松傳輸大量數(shù)據(jù) 通過抽象內(nèi)存段的數(shù)據(jù)量。 我們在本節(jié)中介紹了整體架構(gòu)及其每個組件。

A概述

RPC 接口遵循客戶端/服務(wù)器架構(gòu)。 如圖 1 中所述，發(fā)出遠(yuǎn)程調(diào)用會導(dǎo)致不同的步驟，具體取決于與調(diào)用關(guān)聯(lián)的數(shù)據(jù)的大小。 我們區(qū)分兩種類型的傳輸：包含典型函數(shù)參數(shù)的傳輸，通常很小，稱為元數(shù)據(jù)(metadata)，以及描述大量數(shù)據(jù)的函數(shù)參數(shù)的傳輸，稱為批量數(shù)據(jù)(bulk)。

通過接口發(fā)送的每個 RPC 調(diào)用都會導(dǎo)致函數(shù)參數(shù)的序列化 進(jìn)入內(nèi)存緩沖區(qū)（其大小通常限制為 1 KB，具體取決于互連），然后使用網(wǎng)絡(luò)抽象層接口將其發(fā)送到服務(wù)器。 關(guān)鍵要求之一是在傳輸?shù)娜魏坞A段限制內(nèi)存副本，尤其是在傳輸大量數(shù)據(jù)時。 因此，如果發(fā)送的數(shù)據(jù)很小，它會被序列化并使用小消息發(fā)送，否則將在同一條小消息中將要傳輸?shù)膬?nèi)存區(qū)域的描述發(fā)送到服務(wù)器，然后服務(wù)器可以開始拉取數(shù)據(jù)（如果數(shù)據(jù) 是遠(yuǎn)程調(diào)用的輸入）或推送數(shù)據(jù)（如果數(shù)據(jù)是遠(yuǎn)程調(diào)用的輸出）。 限制對服務(wù)器的初始 RPC 請求的大小也有助于可伸縮性，因為它避免了在大量客戶端同時訪問同一服務(wù)器的情況下不必要的服務(wù)器資源消耗。 根據(jù)所需的控制程度，所有這些步驟都可以由 Mercury 透明地處理或直接暴露給用戶

圖1, 架構(gòu)概述：每一方都使用一個RPC處理器來序列化和反序列化通過接口發(fā)送的參數(shù)。調(diào)用具有較小參數(shù)的函數(shù)導(dǎo)致使用網(wǎng)絡(luò)抽象層暴露的短消息機制，而包含大數(shù)據(jù)參數(shù)的函數(shù)額外使用RMA機制

B. 網(wǎng)絡(luò)抽象層

網(wǎng)絡(luò)抽象層的主要目的是顧名思義，抽象暴露給用戶的網(wǎng)絡(luò)協(xié)議，允許通過插件系統(tǒng)集成多種傳輸。 這種架構(gòu)強加的一個直接后果是提供一個輕量級的接口，為此只需要合理的努力來實現(xiàn)一個新的插件。 接口本身必須定義三種主要類型的數(shù)據(jù)傳輸機制：意外消息傳遞unexpect、預(yù)期消息傳遞expected和遠(yuǎn)程內(nèi)存訪問rma；以及在客戶端和服務(wù)器之間動態(tài)建立連接所需的額外設(shè)置（盡管動態(tài)連接可能并不總是可行，具體取決于底層 使用的網(wǎng)絡(luò)實現(xiàn)）。意外和預(yù)期的消息傳遞僅限于短消息的傳輸，并使用雙向方法。出于性能原因，最大消息大小由互連決定，可以小至幾千字節(jié)。 意外消息傳遞的概念用于其他通信協(xié)議，例如 BMI [10]。 通過網(wǎng)絡(luò)抽象層發(fā)送意外消息不需要在完成之前發(fā)布匹配的接收。 通過使用這種機制，客戶端不會被阻塞，并且服務(wù)器可以在每次發(fā)出意外接收時獲取已發(fā)布的新消息。 預(yù)期消息和意外消息之間的另一個區(qū)別是意外消息可以從任何遠(yuǎn)程源到達(dá)，而預(yù)期消息需要知道遠(yuǎn)程源。遠(yuǎn)程內(nèi)存訪問 (RMA) 接口允許訪問遠(yuǎn)程內(nèi)存塊（連續(xù)和非連續(xù)）。 在大多數(shù)單向接口和 RDMA 協(xié)議中，內(nèi)存必須先注冊到網(wǎng)絡(luò)接口控制器 (NIC) 才能使用。 在網(wǎng)絡(luò)抽象層中定義接口的目的是創(chuàng)建一級抽象并定義與大多數(shù) RMA 協(xié)議兼容的 API。 將內(nèi)存段注冊到 NIC 通常會導(dǎo)致創(chuàng)建該段的句柄，其中包含虛擬地址信息等。創(chuàng)建的本地句柄需要在遠(yuǎn)程節(jié)點可以開始放置或獲取操作之前傳達(dá)給遠(yuǎn)程節(jié)點。 網(wǎng)絡(luò)抽象負(fù)責(zé)確保這些內(nèi)存句柄可以序列化并通過網(wǎng)絡(luò)傳輸。交換句柄后，可以啟動非阻塞放置或獲取。 在大多數(shù)互連上，put 和 get 將映射到互連提供的特定 API 提供的 put 和 get 操作。 網(wǎng)絡(luò)抽象接口旨在允許在雙向發(fā)送和接收網(wǎng)絡(luò)協(xié)議（例如僅支持雙向消息傳遞方法的 TCP/IP）之上模擬單向傳輸。有了這個網(wǎng)絡(luò)抽象層，Mercury 可以很容易地成為 移植以支持新的互連。 網(wǎng)絡(luò)抽象提供的相對有限的功能（例如，沒有無限大小的雙向消息）確保接近本機性能

C. RPC 接口和元數(shù)據(jù)

發(fā)送一個只涉及小數(shù)據(jù)的調(diào)用使用了 III-B 中定義的意外/預(yù)期消息傳遞。 然而，在更高的層次上，向服務(wù)器發(fā)送函數(shù)調(diào)用具體意味著客戶端必須知道如何在開始發(fā)送信息之前對輸入?yún)?shù)進(jìn)行編碼，并且在收到服務(wù)器的響應(yīng)后知道如何解碼輸出參數(shù)。 在服務(wù)器端，服務(wù)器還必須知道在收到 RPC 請求時要執(zhí)行什么，以及如何對輸入和輸出參數(shù)進(jìn)行解碼和編碼。 描述函數(shù)調(diào)用和編碼/解碼參數(shù)的框架是我們接口操作的關(guān)鍵

圖 2：RPC 調(diào)用的異步執(zhí)行流程。 接收緩沖區(qū)是預(yù)先發(fā)布的，允許客戶端在遠(yuǎn)程執(zhí)行調(diào)用并發(fā)回響應(yīng)的同時完成其他工作

其中一個要點是能夠支持一組可以以通用方式發(fā)送到服務(wù)器的函數(shù)調(diào)用，從而避免一組硬編碼例程的限制。通用框架如圖 2 所示。在初始化階段， 客戶端和服務(wù)器通過使用映射到每個操作的唯一 ID 的唯一函數(shù)名稱注冊編碼和解碼函數(shù)，由客戶端和服務(wù)器共享。 服務(wù)器還注冊了在通過函數(shù)調(diào)用接收到操作 ID 時需要執(zhí)行的回調(diào)。 要發(fā)送不涉及批量數(shù)據(jù)傳輸?shù)暮瘮?shù)調(diào)用，客戶端將輸入?yún)?shù)與該操作 ID 一起編碼到緩沖區(qū)中，并使用非阻塞的非預(yù)期消息傳遞協(xié)議將其發(fā)送到服務(wù)器。 為了確保完全異步，用于從服務(wù)器接收響應(yīng)的內(nèi)存緩沖區(qū)也由客戶端預(yù)先發(fā)布。 出于效率和資源消耗的原因，這些消息的大小受到限制（通常為幾千字節(jié)）。但是，如果元數(shù)據(jù)超過意外消息的大小，客戶端將需要在單獨的消息中傳輸元數(shù)據(jù)，從而透明地使用批量數(shù)據(jù) III-D 中描述的接口，用于向服務(wù)器公開額外的元數(shù)據(jù)

當(dāng)服務(wù)器收到一個新的請求 ID 時，它會查找相應(yīng)的回調(diào)、解碼輸入?yún)?shù)、執(zhí)行函數(shù)調(diào)用、對輸出參數(shù)進(jìn)行編碼并開始將響應(yīng)發(fā)送回客戶端。 將響應(yīng)發(fā)送回客戶端也是非阻塞的，因此，在接收新的函數(shù)調(diào)用時，服務(wù)器還可以測試響應(yīng)請求列表以檢查它們是否完成，并在操作完成時釋放相應(yīng)的資源。 一旦客戶端知道已經(jīng)收到響應(yīng)（使用等待/測試調(diào)用）并且函數(shù)調(diào)用已經(jīng)遠(yuǎn)程完成，它就可以解碼輸出參數(shù)和用于傳輸?shù)拿赓M資源。有了這個機制，它 變得易于擴(kuò)展以處理大量數(shù)據(jù)

D. 大塊數(shù)據(jù)接口

除了前面的接口，一些函數(shù)調(diào)用可能需要傳輸更大量的數(shù)據(jù)。 對于這些函數(shù)調(diào)用，使用了批量數(shù)據(jù)接口，它建立在網(wǎng)絡(luò)抽象層中定義的遠(yuǎn)程內(nèi)存訪問協(xié)議之上。 只有 RPC 服務(wù)器啟動單向傳輸，以便它可以在控制數(shù)據(jù)流的同時保護(hù)其內(nèi)存免受并發(fā)訪問。

如圖 3 中所述，批量數(shù)據(jù)傳輸接口使用單向通信方法。 RPC 客戶端通過創(chuàng)建批量數(shù)據(jù)描述符（包含虛擬內(nèi)存地址信息、正在公開的內(nèi)存區(qū)域的大小以及可能取決于底層網(wǎng)絡(luò)實現(xiàn)的其他參數(shù)）向 RPC 服務(wù)器公開內(nèi)存區(qū)域。 然后可以將批量數(shù)據(jù)描述符序列化并與 RPC 請求參數(shù)一起發(fā)送到 RPC 服務(wù)器（使用 III-C 節(jié)中定義的 RPC 接口）。 當(dāng)服務(wù)器對輸入?yún)?shù)進(jìn)行解碼時，它反序列化批量數(shù)據(jù)描述符并獲取必須傳輸?shù)膬?nèi)存緩沖區(qū)的大小

在RPC請求消耗大數(shù)據(jù)參數(shù)的情況下，RPC服務(wù)器可能會分配需要接收的數(shù)據(jù)大小的緩沖區(qū)，通過創(chuàng)建批量數(shù)據(jù)塊描述符暴露其本地內(nèi)存區(qū)域并發(fā)起異步讀取/ 獲取對該內(nèi)存區(qū)域的操作。 RPC 服務(wù)器然后等待/測試操作的完成，并在數(shù)據(jù)完全接收后執(zhí)行調(diào)用（如果執(zhí)行調(diào)用支持它，則部分接收）。 然后將響應(yīng)（即調(diào)用的結(jié)果）發(fā)送回 RPC 客戶端并釋放內(nèi)存句柄

通過此過程傳輸數(shù)據(jù)對用戶來說是透明的，尤其是因為 RPC 接口還可以負(fù)責(zé)序列化/反序列化內(nèi)存句柄以及其他參數(shù)。 當(dāng)必須傳輸非連續(xù)的內(nèi)存段時，這一點尤為重要。 在這兩種情況下，內(nèi)存段都會自動注冊到 RPC 客戶端，并由創(chuàng)建的內(nèi)存句柄抽象出來。 然后內(nèi)存句柄與 RPC 函數(shù)的參數(shù)一起序列化，并使用非連續(xù)內(nèi)存區(qū)域傳輸大數(shù)據(jù)，因此導(dǎo)致與上述相同的過程。 請注意，在這種情況下，句柄可能是可變大小的，因為它可能包含更多信息，并且還取決于可以支持直接注冊內(nèi)存段的底層網(wǎng)絡(luò)實現(xiàn)

IV.評估

先前定義的體系結(jié)構(gòu)使通用 RPC 調(diào)用能夠與句柄一起傳送，這些句柄可以在需要批量數(shù)據(jù)傳輸時描述連續(xù)和非連續(xù)的內(nèi)存區(qū)域。 我們將在本節(jié)介紹如何利用此體系結(jié)構(gòu)來構(gòu)建可以輕松按需請求數(shù)據(jù)塊的流水線機制。 流水線批量數(shù)據(jù)傳輸流水線傳輸是一個典型的用例，當(dāng)人們想要重疊通信和執(zhí)行時。 在我們描述的架構(gòu)中，請求處理大量數(shù)據(jù)會導(dǎo)致從 RPC 客戶端向 RPC 服務(wù)器發(fā)送 RPC 請求以及批量數(shù)據(jù)傳輸。

A. 流水線批量數(shù)據(jù)傳輸

在一個常見的用例中，服務(wù)器可能會在執(zhí)行請求的調(diào)用之前等待接收到全部數(shù)據(jù)。 然而，通過流水線傳輸，實際上可以在數(shù)據(jù)傳輸時開始處理數(shù)據(jù)，避免為整個 RMA 傳輸支付延遲成本。 請注意，盡管我們在下面的示例中重點關(guān)注這一點，但如果 RPC 服務(wù)器沒有足夠的內(nèi)存來處理需要發(fā)送的所有數(shù)據(jù)，使用此技術(shù)也可能特別有用，在這種情況下，它還需要在處理時傳輸數(shù)據(jù)

RPC 客戶端代碼的簡化版本如下所示

#define BULK_NX 16#define BULK_NY 128int main(int argc, char *argv[]){hg_id_t rpc_id;write_in_t in_struct;write_out_t out_struct;hg_request_t rpc_request;int buf[BULK_NX][BULK_NY];hg_bulk_segment_t segments[BULK_NX];hg_bulk_t bulk_handle = HG_BULK_NULL;/* Initialize the interface */[...]/* Register RPC call */rpc_id = HG_REGISTER("write",write_in_t, write_out_t);/* Provide data layout information */for (i = 0; i < BULK_NX ; i++) {segments[i].address = buf[i];segments[i].size = BULK_NY * sizeof(int);}/* Create bulk handle with segment info */HG_Bulk_handle_create_segments(segments,BULK_NX, HG_BULK_READ_ONLY, &bulk_handle);/* Attach bulk handle to input parameters */[...]in_struct.bulk_handle = bulk_handle;/* Send RPC request */HG_Forward(server_addr, rpc_id,&in_struct, &out_struct, &rpc_request);/* Wait for RPC completion and response */HG_Wait(rpc_request, HG_MAX_IDLE_TIME,HG_STATUS_IGNORE);/* Get output parameters */[...]ret = out_struct.ret;/* Free bulk handle */HG_Bulk_handle_free(bulk_handle);/* Finalize the interface */[...]}

客戶初始化時，它會注冊RPC調(diào)用它想要發(fā)送。 因為此調(diào)用涉及非連續(xù)的批量數(shù)據(jù)轉(zhuǎn)換器，所以記憶段描述了創(chuàng)建和注冊的內(nèi)存區(qū)域。 由此產(chǎn)生的Bulk_handle Isthen與其他CallParameter一起傳遞給HG_Forward調(diào)用。 然后，可以在請求完成后等待響應(yīng)并免費的thebulk句柄（將來也會發(fā)送通知可能允許較早的散裝句柄，因此可以取消內(nèi)存的內(nèi)存）。管道上的機制發(fā)生在服務(wù)器上。 ，要照顧批量轉(zhuǎn)移。 管道本身具有HEREA固定管道尺寸和管道緩沖區(qū)大小。 RPC服務(wù)器代碼簡化了

#define PIPELINE_BUFFER_SIZE 256#define PIPELINE_SIZE 4int rpc_write(hg_handle_t handle){write_in_t in_struct;write_out_t out_struct;hg_bulk_t bulk_handle;hg_bulk_block_t bulk_block_handle;hg_bulk_request_t bulk_request[PIPELINE_SIZE];void *buf;size_t nbytes, nbytes_read = 0;size_t start_offset = 0;/* Get input parameters and bulk handle */HG_Handler_get_input(handle, &in_struct);[...]bulk_handle = in_struct.bulk_handle;/* Get size of data and allocate buffer */nbytes = HG_Bulk_handle_get_size(bulk_handle);buf = malloc(nbytes);/* Create block handle to read data */HG_Bulk_block_handle_create(buf, nbytes,HG_BULK_READWRITE, &bulk_block_handle);/* Initialize pipeline and start reads */for (p = 0; p < PIPELINE_SIZE; p++) {size_t offset = p * PIPELINE_BUFFER_SIZE;/* Start read of data chunk */HG_Bulk_read(client_addr, bulk_handle,offset, bulk_block_handle, offset,PIPELINE_BUFFER_SIZE, &bulk_request[p]);}while (nbytes_read != nbytes) {for (p = 0; p < PIPELINE_SIZE; p++) {size_t offset = start_offset +p * PIPELINE_BUFFER_SIZE;/* Wait for data chunk */HG_Bulk_wait(bulk_request[p],HG_MAX_IDLE_TIME, HG_STATUS_IGNORE);nbytes_read += PIPELINE_BUFFER_SIZE;/* Do work (write data chunk) */write(buf + offset, PIPELINE_BUFFER_SIZE);/* Start another read */offset += PIPELINE_BUFFER_SIZE * 51 PIPELINE_SIZE;if (offset < nbytes) {HG_Bulk_read(client_addr,bulk_handle, offset,bulk_block_handle, offset,PIPELINE_BUFFER_SIZE,&bulk_request[p]);} else {/* Start read with remaining piece */}}start_offset += PIPELINE_BUFFER_SIZE* PIPELINE_SIZE;}/* Free block handle */HG_Bulk_block_handle_free(bulk_block_handle);free(buf);/* Start sending response back */[...]out_struct.ret = ret;HG_Handler_start_output(handle, &out_struct);}int main(int argc, char *argv[]){/* Initialize the interface */[...]/* Register RPC call */HG_HANDLER_REGISTER("write", rpc_write,write_in_t, write_out_t);while (!finalized) {/* Process RPC requests (non-blocking) */HG_Handler_process(0, HG_STATUS_IGNORE);}/* Finalize the interface */[...]}

每個RPC服務(wù)器初始化后，都必須繞過HG_HANDLER_PROCESS調(diào)用，該調(diào)用將等待新的RPCRequests并執(zhí)行相應(yīng)的注冊回調(diào)（在同一線程或新線程中取決于用戶需求）。 必經(jīng)請求的請求，用于獲取要傳輸?shù)臄?shù)據(jù)的總尺寸的Bulk_handle參數(shù)可以分配適當(dāng)大小的緩沖區(qū)并啟動批量的DataTransfers。 在此示例中，管道尺寸設(shè)置為4，并且Pipeline緩沖區(qū)大小設(shè)置為256，這意味著啟動了4個256個字節(jié)的RmareQuests。 然后，可以等待第一個256個字節(jié)到達(dá)并進(jìn)行處理。 當(dāng)它處理時，其他零件可能會到達(dá)。 一旦一件被處理了一件，就開始了iSAT階段4的新的RMA轉(zhuǎn)移，并且可以等待下一個件，然后對其進(jìn)行處理。 請注意，雖然在客戶端上注冊的內(nèi)存區(qū)域是不合格的，但hg_bulk_read呼叫theserver將其顯示為連續(xù)區(qū)域，簡化了服務(wù)器代碼。 此外，可以給出邏輯偏移（相對于數(shù)據(jù)的開頭）單獨移動數(shù)據(jù)片，而大量數(shù)據(jù)接口將映射從連續(xù)邏輯偏移到非連接的客戶端內(nèi)存區(qū)域。我們繼續(xù)此過程，直到所有過程 數(shù)據(jù)已被讀取 /處理，響應(yīng)（即功能調(diào)用的結(jié)果）可以發(fā)送回。 同樣，我們僅通過調(diào)用HG_HANDLER_START_OUTPUT調(diào)用來開始發(fā)送響應(yīng)，并且僅通過調(diào)用HG_HANDLER_PROCESS來測試其完成，在這種情況下，與響應(yīng)相關(guān)的資源將受到影響。 請注意，所有函數(shù)都支持異步執(zhí)行，如果需要，可以在事件驅(qū)動的代碼中使用Mercury(HG)

B.網(wǎng)絡(luò)插件和測試環(huán)境

截至本文撰寫的日期已經(jīng)開發(fā)了兩個插件，以說明網(wǎng)絡(luò)抽象層的功能。 此時，尚未優(yōu)化插件的性能。 一個建立在BMI頂部[10]。 但是，AS我們已經(jīng)在第二節(jié)中指出的是，BMI并未有效利用已定義的網(wǎng)絡(luò)行動層和單方面的批量數(shù)據(jù)傳輸結(jié)構(gòu)。 另一個建立在MPI [17]的頂部，該[17]僅提供完整的RMA語義[18]最近的MPI3 [19]。 許多MPI實現(xiàn)，特別是已經(jīng)安裝的機器的Thosedelas，尚無ProvideAll MPI3功能。 由于尚未將BMI移植到室內(nèi)HPC系統(tǒng)，以說明功能和測量性能結(jié)果，因此我們僅考慮MPI插件本文。 該插件能夠在現(xiàn)有的HPCSystems上運行，僅限于MPI-2功能（例如Cray Systems），在兩面消息的頂部實現(xiàn)批量數(shù)據(jù)傳輸。在實踐中，這意味著對于每個批量數(shù)據(jù)傳輸， 需要將控制消息發(fā)送到theclient，以請求發(fā)送或接收數(shù)據(jù)。 然后，可以使用進(jìn)度線程輸入進(jìn)度功能來實現(xiàn)轉(zhuǎn)移的進(jìn)度。對于測試，我們使用兩個不同的HPC系統(tǒng)。 onis是一個Infiniband QDR 4X群集，帶有mvapich [20] 1.8.1，另一個是帶有Cray MPT的Cray Xe6 [21] 5.6.0

C. 性能評估

作為第一個實驗的性能評估，我們測量了為空函數(shù)（即，即將返回的函數(shù)）所花費的小時RPC調(diào)用（沒有任何批量數(shù)據(jù)傳輸）。 在Cray XE6機器上，測量了20個RPC調(diào)用的雜種時間，每個呼叫花費了23 μ。 但是，正如前面指出的那樣，大多數(shù)HPC系統(tǒng)都是均勻的，因此不需要XDR提供的數(shù)據(jù)可移植性。 禁用Xdrencoding（改為執(zhí)行簡單的存儲器副本）時，THETIME會降至20 μs。 這種不可忽略的改進(jìn)（15％）證明了針對HPC環(huán)境設(shè)計RPC框架的好處。第二個實驗包括測試以前在客戶端和一臺服務(wù)器之間解釋的批量數(shù)據(jù)傳輸?shù)墓艿兰夹g(shù)傳輸。 如表I所示，在cray xe6訪問轉(zhuǎn)移時，當(dāng)請求刀片已經(jīng)完成時，在進(jìn)行其他管道階段時，可以特別有效地效率，從而使我們獲得很高的帶寬。 但是，該系統(tǒng)上的高注入帶寬使得很難為小數(shù)據(jù)包（例如，由于單側(cè)功能的模擬，該系統(tǒng)的批量數(shù)據(jù)控制消息）很難獲得良好的性能），特別是當(dāng)數(shù)據(jù)流不連續(xù)的情況下

最后，我們評估了RPC Serverby的可伸縮性，在增加客戶端時數(shù)時評估了總數(shù)據(jù)吞吐量。 圖4和5分別顯示了AQDR Infiniband系統(tǒng)（使用MVAPICH）和CRAY XE6SYSTEM的結(jié)果。 在這兩種情況下，部分由于服務(wù)器sidebulk數(shù)據(jù)流控制機制，HG顯示出卓越的性能，并且吞吐量增加或剩余stableas，并發(fā)客戶的數(shù)量增加。 為了進(jìn)行比較，顯示了每個系統(tǒng)上的點消息帶寬。在Infiniband系統(tǒng)中，Mercury達(dá)到了最大網(wǎng)絡(luò)帶寬的70％。 考慮到HG時間代表了數(shù)據(jù)傳輸?shù)腞PC調(diào)用，這是一個很好的結(jié)果，與發(fā)送OSU基準(zhǔn)的Asingle消息的時間相比。 在Cray系統(tǒng)上，性能不佳（約占峰值的40％）。 我們期望這主要是由于該系統(tǒng)的較小信息性能，以及由單方面仿真引起的額外控制措施。 然而，低性能也可能是由系統(tǒng)限制引起的，考慮到 Nessie 的類似操作（讀?。22] 的性能顯示相同的低帶寬，即使它通過繞過 MPI 并使用真正的 RDMA interconnect 的原生 uGNI API

V.結(jié)論和未來的工作

在本文中，我們介紹了Mercury框架。 Mercury專門設(shè)計用于在高性能計算環(huán)境中提供RPC服務(wù)。 Mercury構(gòu)建了與當(dāng)代HPC網(wǎng)絡(luò)環(huán)境的功能相匹配的小型，易于移植的網(wǎng)絡(luò)抽象層。 與大多數(shù)其他RPC框架不同，Mercury為處理遠(yuǎn)程呼叫的大型數(shù)據(jù)參數(shù)提供了直接支持。 Mercury的網(wǎng)絡(luò)協(xié)議旨在擴(kuò)展到數(shù)千個客戶。 我們通過實施遠(yuǎn)程寫入功能（包括大型數(shù)據(jù)參數(shù)的管道）來證明框架的力量。 我們隨后在兩個不同的 HPC 系統(tǒng)上評估了我們的實施，展示了單客戶端性能和多客戶端可擴(kuò)展性。

在Mercury提供的高性能，便攜式，通用的RPC功能的可用性中，IOFSL可以通過替換內(nèi)部，硬codediofsl代碼來替換和現(xiàn)代化 通過水Mercury Call。 由于網(wǎng)絡(luò)抽象的層面頂部已經(jīng)構(gòu)建了HG的頂部，因此已經(jīng)使用BMI Fornetwork連接性支持IOFSL Continueto的現(xiàn)有部署，同時利用了Mercury的NetworkProtocol的改進(jìn)性可伸縮性和性能。 RPC呼叫。 取消對節(jié)點或網(wǎng)絡(luò)可能失敗的彈性非環(huán)境很重要。 未來的工作將包括對取消的支持。雖然 Mercury 已經(jīng)支持高效執(zhí)行 RPC 調(diào)用所需的所有功能，但可以進(jìn)一步減少每次調(diào)用所需的用戶代碼量。 Mercury 的未來版本將提供一組預(yù)處理器宏，通過自動生成盡可能多的樣板代碼來減少用戶的工作量, 網(wǎng)絡(luò)抽象層當(dāng)前具有用于BMI，MPI-2和MPI-3的插件。 但是，作為在客戶端/服務(wù)器上下文中使用的MPI RMA功能[23]，我們打算增加對Infiniband網(wǎng)絡(luò)的支持，以及Cray XT andibm BG/P和Q網(wǎng)絡(luò)

致謝，本文介紹的工作得到了 Exascale FastForward 項目的支持，LLNS 分包合同號。 B599860，由美國能源部科學(xué)辦公室高級科學(xué)計算機研究辦公室根據(jù)合同 DE-AC02-06CH11357 提供。

參考

論文鏈接: https://www.mcs.anl.gov/papers/P4082-0613_1.pdf。

[1] A. D. Birrell and B. J. Nelson, “Implementing Remote Procedure Calls,” ACM Trans. Comput. Syst., vol. 2, no. 1, pp. 39–59, Feb. 1984。

[2] Google Inc, “Protocol Buffers,” 2012. [Online]. Available: https://developers.google.com/protocol-buffers。

[3] M. Slee, A. Agarwal, and M. Kwiatkowski, “Thrift: Scalable CrossLanguage Services Implementation,” 2007。

[4] K. Seymour, H. Nakada, S. Matsuoka, J. Dongarra, C. Lee, and H. Casanova, “Overview of GridRPC: A Remote Procedure Call API for Grid Computing,” in Grid Computing—GRID 2002, ser. Lecture Notes in Computer Science, M. Parashar, Ed. Springer Berlin Heidelberg, 2002, vol. 2536, pp. 274–278。

[5] Object Management Group, “Common Object Request Broker Architecture (CORBA),” 2012. [Online]. Available: http://www.omg.org/ spec/CORBA。

[6] A. Wollrath, R. Riggs, and J. Waldo, “A Distributed Object Model for the JavaTMSystem,” in Proceedings of the 2nd conference on USENIX Conference on Object-Oriented Technologies (COOTS) - Volume 2, ser. COOTS’96. Berkeley, CA, USA: USENIX Association, 1996, pp.17–17。

[7] R. Sandberg, D. Golgberg, S. Kleiman, D. Walsh, and B. Lyon, “Innovations in internet working,” C. Partridge, Ed. Norwood, MA, USA: Artech House, Inc., 1988, ch. Design and Implementation of the Sun Network Filesystem, pp. 379–390。

[8] Sun Microsystems Inc, “RFC 1014—XDR: External Data Representation Standard,” 1987. [Online]. Available: http://tools.ietf.org/html/rfc1014。

[9] N. Ali, P. Carns, K. Iskra, D. Kimpe, S. Lang, R. Latham, R. Ross, L. Ward, and P. Sadayappan, “Scalable I/O forwarding framework for high-performance computing systems,” in IEEE International Conference on Cluster Computing and Workshops 2009, ser. CLUSTER ’09, 2009, pp. 1–10。

[10] P. Carns, I. Ligon, W., R. Ross, and P. Wyckoff, “BMI: a networkabstraction layer for parallel I/O,” in 19th IEEE International Parallel and Distributed Processing Symposium, 2005。

[11] P. H. Carns, W. B. Ligon, III, R. B. Ross, and R. Thakur, “PVFS: A Parallel File System for Linux Clusters,” in In Proceedings of the 4th Annual Linux Showcase and Conference. USENIX Association, 2000, pp. 317–327。

[12] R. Alverson, D. Roweth, and L. Kaplan, “The Gemini System Interconnect,” in IEEE 18th Annual Symposium on High-Performance Interconnects, ser. HOTI, 2010, pp. 83–87。

[13] J. Lofstead, R. Oldfield, T. Kordenbrock, and C. Reiss, “Extending Scalability of Collective IO Through Nessie and Staging,” in Proceedings of the Sixth Workshop on Parallel Data Storage, ser. PDSW ’11. New York, NY, USA: ACM, 2011, pp. 7–12。

[14] R. Oldfield, P. Widener, A. Maccabe, L. Ward, and T. Kordenbrock,“Efficient Data-Movement for Lightweight I/O,” in Cluster Computing,2006 IEEE International Conference on, 2006, pp. 1–9。

[15] R. Brightwell, T. Hudson, K. Pedretti, R. Riesen, and K. Underwood, “Implementation and Performance of Portals 3.3 on the Cray XT3,” in Cluster Computing, 2005. IEEE International, 2005, pp. 1–10。

[16] C. Docan, M. Parashar, and S. Klasky, “Enabling High-speed Asynchronous Data Extraction and Transfer Using DART,” Concurr. Comput. : Pract. Exper., vol. 22, no. 9, pp. 1181–1204, Jun. 2010。

[17] W. Gropp, E. Lusk, and R. Thakur, Using MPI-2: Advanced Features of the Message-Passing Interface. Cambridge, MA: MIT Press, 1999。

[18] W. Gropp and R. Thakur, “Revealing the Performance of MPI RMA Implementations,” in Recent Advances in Parallel Virtual Machine and Message Passing Interface, ser. Lecture Notes in Computer Science, F. Cappello, T. Herault, and J. Dongarra, Eds. Springer Berlin / Heidelberg, 2007, vol. 4757, pp. 272–280。

[19] “Message Passing Interface Forum,” September 2012, MPI-3: Extensions to the message-passing interface. [Online]. Available: http://www.mpi-forum.org/docs/docs.html。

[20] The Ohio State University, “MVAPICH: MPI over InfiniBand, 10GigE/iWARP and RoCE.” [Online]. Available: http://mvapich.cse. ohio-state.edu/index.shtml。

[21] H. Pritchard, I. Gorodetsky, and D. Buntinas, “A uGNI-Based MPICH2 Nemesis Network Module for the Cray XE,” in Recent Advances in the Message Passing Interface, ser. Lecture Notes in Computer Science, Y. Cotronis, A. Danalis, D. Nikolopoulos, and J. Dongarra, Eds. Springer Berlin / Heidelberg, 2011, vol. 6960, pp. 110–119。

[22] R. A. Oldfield, T. Kordenbrock, and J. Lofstead, “Developing integrated data services for cray systems with a gemini interconnect,” Sandia National Laboratories, Tech. Rep., 2012。

[23] J. A. Zounmevo, D. Kimpe, R. Ross, and A. Afsahi, “On the use of MPI in High-Performance Computing Services,” p. 6, 2013。

本文轉(zhuǎn)載自微信公眾號「云原生云」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系云原生云公眾號。

關(guān)鍵詞：