摘要

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

1、簡(jiǎn)介

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

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

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

2、相關(guān)工作

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

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

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

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

3、架構(gòu)

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

A概述

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

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

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

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

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

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

發(fā)送一個(gè)只涉及小數(shù)據(jù)的調(diào)用使用了 III-B 中定義的意外/預(yù)期消息傳遞。 然而，在更高的層次上，向服務(wù)器發(fā)送函數(shù)調(diào)用具體意味著客戶端必須知道如何在開始發(fā)送信息之前對(duì)輸入?yún)?shù)進(jìn)行編碼，并且在收到服務(wù)器的響應(yīng)后知道如何解碼輸出參數(shù)。 在服務(wù)器端，服務(wù)器還必須知道在收到 RPC 請(qǐng)求時(shí)要執(zhí)行什么，以及如何對(duì)輸入和輸出參數(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)的同時(shí)完成其他工作

其中一個(gè)要點(diǎn)是能夠支持一組可以以通用方式發(fā)送到服務(wù)器的函數(shù)調(diào)用，從而避免一組硬編碼例程的限制。通用框架如圖 2 所示。在初始化階段， 客戶端和服務(wù)器通過(guò)使用映射到每個(gè)操作的唯一 ID 的唯一函數(shù)名稱注冊(cè)編碼和解碼函數(shù)，由客戶端和服務(wù)器共享。 服務(wù)器還注冊(cè)了在通過(guò)函數(shù)調(diào)用接收到操作 ID 時(shí)需要執(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ù)超過(guò)意外消息的大小，客戶端將需要在單獨(dú)的消息中傳輸元數(shù)據(jù)，從而透明地使用批量數(shù)據(jù) III-D 中描述的接口，用于向服務(wù)器公開額外的元數(shù)據(jù)

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

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

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

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

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

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

IV.評(píng)估

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

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

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

RPC 客戶端代碼的簡(jiǎn)化版本如下所示

#define BULK_NX 16
#define BULK_NY 128

int 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 */
[...]
}

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

#define PIPELINE_BUFFER_SIZE 256
#define PIPELINE_SIZE 4

int 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 */
[...]
}

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

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

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

C. 性能評(píng)估

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

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

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

在本文中，我們介紹了Mercury框架。 Mercury專門設(shè)計(jì)用于在高性能計(jì)算環(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ù)千個(gè)客戶。 我們通過(guò)實(shí)施遠(yuǎn)程寫入功能（包括大型數(shù)據(jù)參數(shù)的管道）來(lái)證明框架的力量。 我們隨后在兩個(gè)不同的 HPC 系統(tǒng)上評(píng)估了我們的實(shí)施，展示了單客戶端性能和多客戶端可擴(kuò)展性。

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

致謝，本文介紹的工作得到了 Exascale FastForward 項(xiàng)目的支持，LLNS 分包合同號(hào)。 B599860，由美國(guó)能源部科學(xué)辦公室高級(jí)科學(xué)計(jì)算機(jī)研究辦公室根據(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)載自微信公眾號(hào)「云原生云」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系云原生云公眾號(hào)。