论文笔记：No Provisioned Concurrency: Fast RDMA-codesigned Remote Fork for Serverless Computing 下

论文笔记：No Provisioned Concurrency: Fast RDMA-codesigned Remote Fork for Serverless Computing 下

6 Bringing MITOSIS to Serverless Computing

本节介绍如何将MITOSIS应用于FN[120]——一个流行的开源无服务器平台。尽管我们关注FN，但我们相信我们的方法也可以应用于其他无服务器平台（例如OpenWhisk[119]），因为它们遵循类似的系统架构（见图11）。

FN基本信息
图11显示了FN的概述。它处理的函数请求要么是单个函数的调用，要么是无服务器工作流的执行（例如，见图2）。专门的协调员负责安排这些请求的执行。功能代码必须打包到容器中，并上传到平台管理的Docker注册表[34]。

为了处理单个函数的调用，协调器将请求定向到从服务器池中选择的调用方。收到请求后，调用程序生成一个带有缓存的容器，以加速启动以执行函数。注意，FN使用功能开发工具包（FDK）隐藏了请求到用户功能的映射（例如，图3（a）中的12–16）：即，用户只需要提供功能的代码，而不需要将请求分派到功能的代码。由于这种抽象，我们可以扩展FDK以添加fork功能。为了执行工作流，协调器将首先将工作流分解为单个函数调用（每个工作流图节点一个），然后根据依赖关系调度它们。特别是，协调器只会在所有上游函数（fetchPortfolioData和fetchMarketData）完成后执行下游函数（例如，图2中的defrunAuditRule）。

要执行工作流，协调器将首先将工作流分解为单个函数调用（每个工作流图节点一个），然后根据依赖关系调度它们。特别是，协调器只会在所有上游函数（fetchPortfolioData和fetchMarketData）完成后执行下游函数（例如，图2中的defrunAuditRule）。

6.1 Fork-aware 无服务器平台

意识到MITOSIS，该平台可以利用已经通过fork_prepare（本文中称为种子）做好准备的父母来加速功能启动和状态转移。此外，它还负责回收种子。根据用例，我们进一步将种子分为两类。
1） 对于用于促进功能启动的种子，回收频率较低。因此，我们将它们命名为long lived种子，并使用粗粒度回收方案（§6.2）。
2）对于用于状态转移的种子，它们只在无服务器工作流的生命周期中生存。我们将它们命名为short lived种子，并使用基于细粒度叉树的机制来释放它们（§6.3）。

用MITOSIS加速FN的步骤如下：
（1） 扩展FN协调器，以便在必要时向调用方发送准备/恢复请求，以分叉容器；（2）插入FDK，使其能够识别来自协调器的新（分叉）请求（例如，图3（b）中的第12-16行）。由于对FDK的扩展是微不足道的，因此我们将重点描述对协调器的扩展
分叉感知协调器。对于单个函数调用，协调器首先查找一个可用的（长期的）种子。种子的位置存储在种子库中。如果有一个种子可用，它会向调用者发送一个fork恢复请求。否则，我们将回退到普通函数启动机制。
在工作流执行过程中，协调器根据状态转移关系动态创建短期。具体来说，如果调用程序在工作流中执行上游函数，它将告诉调用程序调用fork_prepare。准备好的结果在函数的回复中附带。然后，协调器可以使用fork_resume启动下游函数，这些函数透明地继承上游函数的预具体化结果。
注意，一个函数可能有多个上游函数（例如，运行图2中的AuditRule）。对于这种情况，我们要求用户通过注释工作流图或融合上游函数来指定要分叉的函数。

6.2长期种子管理

部署
我们将长寿命种子部署为缓存的容器，因为它们自然地将函数的工作集加载到内存中。如果调用程序决定缓存容器，它将调用fork_prepare来生成种子。注意，我们还必须调整FN的缓存策略，使其能够识别分叉。例如，如果FN遇到冷启动，它总是缓存容器，考虑到MITOSIS，这是不必要的，因为分叉可以更有效地加速创业。因此，我们只在整个平台上缓存第一个面向coldstart的容器。此外，我们还检测容器是否是多跳容器，即从长寿命种子分叉。我们不缓存这样的容器，因为它们是短期种子。

种子库
为了查找种子信息，我们在协调器处记录函数名与对应种子的RDMA地址、handle_id和key（后两者由fork_prepare返回）之间的映射。我们还记录种子部署的时间，这是防止协调器从接近过期的缓存实例分叉所必需的。种子存储可以与协调器位于同一位置，也可以实现为分布式密钥值存储

复垦 Reclamation.
与缓存类似，长寿命种子通过超时回收。与缓存不同，种子可以有更长的存活时间（例如，10分钟比1分钟），因为它们消耗的内存数量级更少。如果种子对于分叉函数的生存时间不够长，协调员可以更新种子。
与缓存类似，长寿命种子通过超时回收。与缓存不同，种子可以有更长的存活时间（例如，10分钟比1分钟），因为它们消耗的内存数量级更少。如果种子对于分叉函数的生存时间不够长，协调员可以更新种子。

6.3叉树和短命种子管理

叉树粒度和结构
每个无服务器工作流都有一个专用的分叉树，由执行它的协调器存储和维护。树中的上层节点对应于工作流中的上游功能（父级），而下层节点代表下游功能（子级）。每个节点都对容器ID和位置进行编码，这足以让协调器回收相应的种子

叉树构造和破坏
叉树的构造很简单：在协调器从一个短命种子中叉出一个新的子节点后，它会将该种子添加到树中。当树中的所有函数都完成时，MITOSIS将回收除根节点之外的所有节点：根节点可以是长寿命种子，MITOIS不会回收它。

容错
叉树应该是容错的，以防止悬挂种子导致的内存泄漏。使用常见的复制协议（例如Paxos[74]）复制树可以容忍失败，但在工作流执行过程中增加了不小的开销。观察到无服务器功能具有最大生存期（例如，AWS Lambda[3]中的15分钟），我们使用了一种简单的基于超时的机制来容忍失败。具体地说，如果短命种子超出函数允许的最大运行时间，则调用程序将定期垃圾收集短命种子。

6.4限制

首先，fork仍然需要一个长寿的种子来快速引导其他人。如果没有可用的种子，我们可以利用现有的优化coldstart的方法（例如FaasNET[116]）来首先启动一个。第二，fork只启用只读状态传输。然而，对于无服务器工作流这一主要功能组合方法来说，这已经足够了。最后，fork不能在多个上游函数之间传递状态。因此，对于这种情况，MITOSIS必须将这些上游功能整合为一个或回退到消息传递（参见图3中的组合）。我们通过进一步引入远程合并原语来补充远程分叉

7 评估

实验设置。我们在具有24台机器的本地集群上进行所有实验。每台机器都有两个12核Intel Xeon E5-2650 v4处理器和128GB的DRAM。16台机器通过两个100 Gbps ConnectX-4 MCX455A InfiniBand RNIC连接到两个Mellanox SB7890 100Gbps交换机。我们使用它们作为调用程序来执行无服务器函数。没有RDMA的节点保留为协调员。比较目标。MITOSIS及其基线的评估设置如下所示。注意，我们将我们的通用精益集装箱（§5.2）应用于所有系统，以隐藏集容器化成本。

先略过评估部分……

9 相关工作

优化无服务器计算
MITOSIS继续优化无服务器计算的研究路线，包括但不限于加速功能启动[93，17，103，37，114，99，116]，状态转移[107，69，95，71，17，85]，有状态无服务器功能[125，63]，事务[83]，提高成本效率[127，42，98，76，96，40，38]，以及其他[106，126，65，36，64，15，111，84，123，129]。这些工作中的大多数与有丝分裂症正交。然而，我们相信他们也可以从我们的工作中受益。特别是，我们建议使用远程分叉抽象来同时加速功能启动和状态转移，这对所有无服务器应用程序都至关重要。对于我们最相关的作品，我们也在§2中对它们进行了广泛的比较。
尽管在某些情况下，Linux fork的实现可能不是最佳的[122，24，128]，但已经证明它适合于无服务器功能[17，37]。因此，我们仍然选择泛化fork抽象来加速跨机器运行的函数。

检查点和恢复（C/R）
长期以来，操作系统对C/R进行了研究[39，82]。例如，KeyKOS[51]、EROS[102]、Aurora[113]和其他[52、72、7、130、115、21、26、48]。Aurora[113]利用C/R实现高效的单级存储，它引入了包括系统阴影在内的技术，以实现高效的增量检查点。
MITOSIS通过OS-RDMA协同设计消除了远程分叉上下文中的检查点。VAS-CARIU[115]还注意到文件系统引入的C/R开销。它利用多个独立地址空间（MVAS）[50]在单个计算机上绕过文件系统以实现C/R。我们进一步使用内核空间RDMA来构建全局分布式地址空间，并将快速C/R扩展到分布式设置。

远程分叉（迁移）
除了将C/R用于远程分叉[105，32]之外，MITOSIS还受到了虚拟机分叉（SnowFlock[73]）和迁移[18，29，45，56，55，91，81]等工作的启发。
例如，MITOSIS容器描述符的灵感来自SnowFlock中使用的VM描述符，它只捕获用于在远程端实例化子容器的关键元数据。我们进一步考虑了采用RDMA和无服务器计算时的机遇和挑战。因此，我们相信我们的技术可以使不使用RDMA的现有作品受益。

**基于RDMA的 远程寻呼remote paging 和RDMA 组播 multicast **
在现代操作系统中，通过RDMA从远程主机读取页面并不是一项新技术[19，46，16，86，101]。例如，Infiniswap[46]利用RDMA构建用于内存分解的快速交换设备。远程区域[16]提出了一种类似于远程文件的抽象，以简化使用RDMA暴露应用程序的内存。MITOSIS通过使用RDMA以“写时复制”的方式读取远程页面，进一步构建了高效的远程分叉。
MITOSIS展示了一种基于拉的RDMA多播通信模式，例如，在负载峰值期间，多个孩子从同一父母的内存中拉取。文献中对基于推送的RDMA多播进行了广泛研究[25，61，62]。例如，RDMC[25]提出了一种二项式流水线协议，其中发送方可以使用RDMA将数据有效地推送到一组节点。我们相信MITOSIS可以进一步受益于基于拉式RDMA多播的研究。