粒子无服务器网络的短暂端点

160Particle：无服务器网络的临时终端点0Shelby ThomasUC圣地亚哥分校shelbyt@ucsd.edu0Lixiang AoUC圣地亚哥分校liao@eng.ucsd.edu0Geoffrey M. VoelkerUC圣地亚哥分校voelker@cs.ucsd.edu0George PorterUC圣地亚哥分校gmporter@cs.ucsd.edu0摘要0突发并行无服务器应用程序调用数千个短期分布式函数来完成复杂的作业，例如数据分析、视频编码或编译。虽然这些任务在几秒钟内执行，但启动和配置它们所依赖的虚拟网络是一个主要的瓶颈，可能占据总启动时间的84%。本文对三种流行的覆盖网络，Docker Swarm、Weave和LinuxOverlay，在这个“网络冷启动”问题的规模进行了表征。我们关注包括启动一组容器的时间和它们之间的互联在内的端到端启动时间。我们的主要观察是，现有的覆盖网络方法在短生命周期的无服务器环境中扩展性差。基于我们的发现，我们开发了一个针对多节点无服务器覆盖网络的网络堆栈Particle，它在不牺牲多租户、通用性或吞吐量的前提下优化了网络创建。当将Particle集成到一个无服务器突发并行视频处理流水线中时，与现有的覆盖网络相比，Particle可以将应用程序运行时间提高2.4-3倍。0CCS概念0• 计算机系统组织 → 云计算。0关键词0无服务器，网络，突发并行，lambda0SoCC ’20，2020年10月19日至21日，虚拟活动，美国©2020版权归所有者/作者所有。ACM ISBN978-1-4503-8137-6/20/10.https://doi.org/10.1145/3419111.34212750ACM参考格式：Shelby Thomas, Lixiang Ao, Geoffrey M.Voelker和George Porter. 2020. Particle: Ephemeral Endpointsfor Serverless Networking. 在ACM云计算研讨会（SoCC'20）上，2020年10月19日至21日，虚拟活动，美国。ACM，纽约，纽约，美国，14页。https://doi.org/10.1145/3419111.342127501 引言0无服务器计算在云计算领域提供了一种高级计算抽象[18]。从用户的角度来看，它简化了应用程序的部署，因为提供商管理着更大部分的资源，包括网络、操作系统、运行时和库，使用户能够专注于应用程序代码。虽然最初提供商设计无服务器平台来支持Web和API服务，但现在用户可以在几秒钟内启动数千个并行的“函数”，大大增加了云计算资源的弹性。这些短生命周期函数的不断增长已经成为“突发并行”作业的出现。突发并行作业被定义为具有非常高的分支扇出的并行任务，由单个用户部署的数千个无服务器函数组成。Fouladi等人[11]展示了如何将这种方法应用于视频编码，将行业级编码器的编码时间从149分钟减少到2.6分钟。Ao等人[4]应用了类似的模型，为端到端视频处理流水线开发了一个基于云的突发并行系统，其性能比Spark在视频处理作业上提高了4倍。与传统的无服务器用例相比，由数百个并发函数组成的单个作业具有独特的基础设施需求，当前的无服务器平台不支持这些需求的高效处理。特别是，支撑无服务器平台的网络层对于突发并行应用程序来说尤其低效。这些应用程序使用数百个并发的无服务器函数来完成复杂的任务，并且在无服务器平台上缺乏本地点对点网络功能的情况下，必须通过中间存储进行协调[4,10,11,20]。迄今为止，这种解决方法已被广泛使用，但是它是临时的、应用程序特定的，需要额外的基础设施服务，并且使用户代码复杂化。这些缺点阻碍了有效支持更广泛范围的通用突发并行数据分析的发展，例如MapReduce类应用程序中的“shuffle”阶段[8,28]、典型科学计算应用程序中的消息传递[12]以及数据流系统中的通信图的顶点遍历[15,24,30]。尽管当前主要的云提供商都没有针对突发并行优化的网络功能，但启用这种点对点网络已经成为工业界[31]和学术界[18]越来越感兴趣的领域。已经提出了两种解决方法，即NAT打洞和覆盖网络，但这两种方法都具有多样性和性能方面的缺点，如本文后续部分所述。为了证明这一点，考虑一个使用Pywren[17,29]运行时构建的应用程序，如图1所示。在这个实验中，100个容器同时启动，每个容器在发送完成通知给领导节点之前执行基本计算。对于所有三种传统方法，启动100个容器大约需要4.8秒。这个网络开销比应用程序运行时间长4倍，占总无服务器启动时间的66-84%；实际上，网络启动开销甚至可能超过实际的应用程序执行时间。对于突发并行应用程序，快速启动时间至关重要，就像传统应用程序从快速线程创建中受益一样。在本文中，我们对现有的无服务器网络方法进行了表征，并提出了一个优化的网络堆栈Particle，以减少为突发并行无服务器作业设置网络时的网络开销。Particle的关键见解是，支持突发并行作业的网络不需要在用户的容器之间提供隔离，只需要在不同用户的容器之间提供隔离。这种权衡类似于线程比进程更高效的创建方式，这是由于线程隔离保证的差异导致的。我们展示了Particle可以支持多种不同的无服务器框架。总结起来，本文的贡献有：0本作品采用知识共享署名国际4.0许可证。5101520170SoCC ’20，2020年10月19日至21日，虚拟活动，美国Shelby Thomas，Lixiang Ao，Geoffrey M. Voelker和George Porter0但这是临时的、应用程序特定的，需要额外的基础设施服务，并且使用户代码复杂化。这些缺点阻碍了有效支持更广泛范围的通用突发并行数据分析的发展，例如MapReduce类应用程序中的“shuffle”阶段[8,28]、典型科学计算应用程序中的消息传递[12]以及数据流系统中的通信图的顶点遍历[15,24,30]。尽管当前主要的云提供商都没有针对突发并行优化的网络功能，但启用这种点对点网络已经成为工业界[31]和学术界[18]越来越感兴趣的领域。已经提出了两种解决方法，即NAT打洞和覆盖网络，但这两种方法都具有多样性和性能方面的缺点，如本文后续部分所述。为了证明这一点，考虑一个使用Pywren[17,29]运行时构建的应用程序，如图1所示。在这个实验中，100个容器同时启动，每个容器在发送完成通知给领导节点之前执行基本计算。对于所有三种传统方法，启动100个容器大约需要4.8秒。这个网络开销比应用程序运行时间长4倍，占总无服务器启动时间的66-84%；实际上，网络启动开销甚至可能超过实际的应用程序执行时间。对于突发并行应用程序，快速启动时间至关重要，就像传统应用程序从快速线程创建中受益一样。在本文中，我们对现有的无服务器网络方法进行了表征，并提出了一个优化的网络堆栈Particle，以减少为突发并行无服务器作业设置网络时的网络开销。Particle的关键见解是，支持突发并行作业的网络不需要在用户的容器之间提供隔离，只需要在不同用户的容器之间提供隔离。这种权衡类似于线程比进程更高效的创建方式，这是由于线程隔离保证的差异导致的。我们展示了Particle可以支持多种不同的无服务器框架。总结起来，本文的贡献有：0•评估无服务器突发并行网络的挑战，重点关注网络启动问题。 • 评估三种不同的设计来克服网络启动问题。 •提出了一个最终的设计Particle，实现了网络的恒定时间创建和启动。我们通过微基准测试、无服务器模式、突发并行应用程序、多租户设置进行Particle的评估，并验证对网络吞吐量没有不利影响。0Particle的源代码可在以下网址找到：https://github.com/shelbyt/socc20particle。0具有EVPN的Linux覆盖网络0DockerSwarm覆盖网络0Weave覆盖网络0Particle0图1：将100个虚拟实例连接到覆盖网络所需的时间。网络启动时间占总启动时间的83%。与DockerSwarm相比，Particle将网络设置减少32倍，将端到端启动时间缩短3.5倍。02 背景和动机0对于无服务器系统，很多工作都集中在容器启动时间上，而与函数间通信的网络角色无关。随着无服务器从独立的单个函数发展为协调的突发并行应用程序，快速、灵活和可扩展的网络创建变得越来越关键，以满足这种应用程序类别的突发性特点。基于VXLAN的覆盖网络（例如Weave、LinuxOverlay和DockerSwarm）旨在满足现代数据中心网络的多样性和可扩展性要求，但它们的实现是为支持数十个严格隔离的长期连接而量身定制的，而不是数千个短期运行的连接。我们描述了覆盖网络的底层机制，以及在应用程序级别和内核级别对每个覆盖网络创建的基准测试。我们的主要发现是，覆盖数据平面与容器的交互方式引入了许多基于VXLAN的覆盖网络的严重延迟问题，而当互连数百个无服务器函数时，这个问题会加剧。幸运的是，这种瓶颈提供了以便携和通用方式解决问题的机会。容器化是无服务器平台中最常见的隔离机制，被GoogleFunction、IBM OpenWhisk和AzureFunctions使用。因此，我们将本文的重点放在容器作为执行平台上。101 / 115.74404 / 415.661616 / 1615.9910010.0240038.901600119.79180Particle：无服务器网络的临时端点 SoCC ’20，2020年10月19日至21日，美国虚拟活动0总连接数/节点连接时间（秒）0表1：扩展节点数：在保持每个节点的连接数不变的情况下，增加节点数时，端到端的启动时间保持相对稳定。02.1 覆盖数据和控制平面0实现覆盖网络的基础技术是VXLAN协议。VXLAN是一种封装协议，用唯一标识符（VNIs）将容器组的数据包进行封装，以实现通信而不损害隔离。以这种方式连接的设备形成覆盖网络。覆盖网络由两个不同的部分组成，即控制平面和数据平面。控制平面是一种网络服务，用于管理跨多个租户的覆盖网络。这些连接由每个主机内的数据平面发起。与控制平面不同，数据平面仅在无服务器应用程序存在时存在。它负责根据VNI、IP和MAC地址将数据转发到正确的容器。VXLAN数据平面要求每个主机都有一个VXLAN隧道终端点（VTEP），负责VXLAN终止和封装。当一个容器使用VXLAN将数据包发送到另一个容器时，主机上的VTEP使用VXLAN头将容器的原始以太网帧进行封装。随后，封装的数据包带有外部IP和MAC头从主机发送出去。当另一个容器接收到该数据包时，接收方的VTEP查看VNI和内部MAC地址，并将有效载荷传递给相应的容器。覆盖网络还需要一个控制平面来管理VTEP路由信息。控制平面保持主机VTEP、VNIs和容器MAC地址的映射。当一个主机上的容器将数据发送到另一个主机上的容器时，VTEP使用VNI对数据包进行封装，并在本地检查路由信息是否存在。如果不存在，则对控制平面进行探测，然后使用新路由进行路由。控制平面的实现多种多样，有些使用虚拟路由器[33]，有些使用Gossip协议[9]，有些使用BGP[6]，还有些使用KV存储[7，9]。将这两个网络平面联系在一起的粘合剂是网络命名空间。Linux网络命名空间机制在内核中创建了新的逻辑网络堆栈，每个堆栈都有自己的网络设备、邻居表和路由表、/proc/net目录和其他网络堆栈状态。通过调用unshare来创建网络命名空间0总连接数命名空间设置时间（秒）0表2：扩展每个节点的连接数：与表1相比，增加单个节点上的连接数/命名空间规模的效果较差。0或者根据实现情况使用带有CLONE_NEWNET标志的clone。在覆盖网络的上下文中，虚拟以太网设备（VETH）用作连接命名空间的端点，并且可以配置具有MAC和IP地址。与数据平面相关的开销是设置命名空间的函数，而与控制平面相关的开销是设置路由的函数。为了了解这两者对应用程序造成的负担大小，我们对两者进行了可扩展性分析。02.2 性能瓶颈0我们的目标是了解超级覆盖网络的性能瓶颈，而不受任何特定覆盖方法的限制。为此，我们在可能的情况下避免使用专有软件进行这些微基准测试，并使用本机Linux命令构建我们的覆盖网络来管理数据和控制平面。为了确立我们对系统开销的理解，我们进行了一项小型微基准测试。该实验在亚马逊AWS上运行，使用带有Ubuntu18.04的c5.4xlarge机器和Linux内核5.0.0-1004。我们使用基于BGP的Quagga EVPN[5]作为虚拟路由器，使用Linux本地iproute2 v5.2.0[14]来管理Docker容器和命名空间，创建了一个完全功能的覆盖网络。0扩展节点数量：我们首先确定向现有覆盖网络添加更多节点是否会减慢控制平面的速度。为了回答这个问题，我们首先启动了一个包含100个容器的集群，并在每个节点上创建了一个将容器相互连接的覆盖网络。我们变化节点的数量，并记录添加新路由的时间。表1总结了我们的观察结果，显示启动一个Docker容器、启动数据平面、连接到控制平面并向给定的接收节点发送数据所需的时间。为了增加基于BGP的控制平面的负载，我们增加节点的数量（从而增加连接到控制平面的端点数）。每个主机上的容器数量保持不变，但需要连接的容器数量线性增加，直到网络化了1600个容器。额外的连接是VTEP之间的连接。要点：在16个节点上，控制平面对性能的影响可以忽略不计，并且在误差范围内。190SoCC ’20，2020年10月19日至21日，美国虚拟活动 Shelby Thomas，Lixiang Ao，Geoffrey M. Voelker和George Porter0�0vxl420主机0主机netns VTEP netns容器netns0br420vxl420主机0主机netns VTEP netns0veth-l veth-g0veth-l0veth-l0多个容器0为容器创建一个新的网络命名空间0br420vxl420主机0主机netns VTEP netns0br420veth-lveth-g0vxl420主机0主机netns0br420veth-l0veth-g0vxl420br420vxl420主机0主机netns0br420veth-g0vxl420主机0br420veth-g0�0�  �0�0veth-g veth-l0veth-l veth-l0容器netns0容器netns容器netns VTEP netns VTEP netns0VTEP netns容器netns容器netns VTEP netns0创建Guest和本地VETH0将Guest VETH移入容器 将Local VETH移入VTEP0�0将Local连接到VXLAN VNI 启动两个VETH接口 将IP和MAC附加到Guest0重复为其他容器执行相同步骤0图2：为覆盖数据平面创建一个新的网络接口涉及一系列的操作，每个新容器都要重复这些操作。我们将网络命名空间称为“netns”。最初，只存在与控制平面通信的VTEP。BR是桥接接口，VXL是连接到桥接器的VXLAN接口。0观察到了这个尺度。我们将展示，对于数据平面来说，这种结果并不成立。0增加单个节点上的连接数：接下来，我们对向覆盖网络添加容器的数据平面性能和可扩展性的影响进行了描述。我们在一个节点上创建一个单独的覆盖网络，并将其连接到控制平面，然后改变向该覆盖网络添加的网络命名空间的数量。我们的分析重点是网络命名空间本身的开销，而不是容器创建时间。0步骤 时间（秒） 总百分比0S1 0.10 0.92% S2 0.10 0.92% S35.18 47.71% S4 4.77 43.95% S50.49 4.45% S6 0.22 2.03%0表3：100个网络命名空间的覆盖数据平面中图2中的步骤的细分。大部分时间花在在名称空间之间移动VETH设备上（步骤S3和S4）。0表2显示，总体时间随着连接到覆盖层的命名空间数量的增加而线性增加（与我们观察到的控制平面不同）。请注意，我们仅显示实例化网络数据平面所需的时间。我们通过改变连接到该覆盖网络的命名空间数量来衡量可伸缩性。我们观察到大部分时间花在内核中。要点：表1显示100个容器在一个节点上的启动时间为15.74秒。表2显示大部分时间用于将命名空间进行网络连接，超过总启动时间的60%。随着网络命名空间的增加，设置开销也随之增加。这种不具备可伸缩性的问题是无服务器爆发式部署的一个主要瓶颈。02.3网络命名空间的作用0图2说明了将新网络命名空间添加到覆盖网络中所涉及的步骤。这个过程对于使用基于VXLAN的覆盖网络的所有覆盖网络软件来说是相似的。首先，主机实例化VTEP的控制平面命名空间和主机的标准网络命名空间。首先，我们创建一个新的客户网络命名空间。接下来，在主机命名空间中创建一对VETH设备。从主机命名空间中，我们将这些VETH设备放入控制平面和客户命名空间的网络命名空间中。然后，我们将本地VETH与VTEP的VXLAN和桥接接口连接起来，并启动本地和客户接口。最后，我们通过为客户网络命名空间设置IP和MAC来建立与VTEP的连接。此时，客户端已连接到覆盖网络，并且所有数据将通过相应的VNI进行传输。这些步骤对于覆盖网络中的每个新客户端重复进行。我们使用eBPF[22]对图2中的步骤进行细分，并报告将100个网络命名空间连接到覆盖层所需的相对时间和绝对时间。表3对执行时间进行了细分，跨越了200粒子：无服务器网络的临时终端SoCC '20，2020年10月19日至21日，虚拟活动，美国0无服务器网络隔离低时延可寻址的IP地址L3解决方案连接类型0NAT洞穿 � � � �� 点对点Kubernetes Pods � - � � 端口多路复用和卷Docker主机网络 � � � � 直接IP覆盖网络 � � � � 直接IP粒子 � � � � 直接IP0表4：不同无服务器网络选项的功能和挑战的比较：无服务器网络解决方案必须适用于爆炸性低时延的多租户环境。无服务器系统还必须能够与第3层连接性一起工作，并为直接函数间通信提供每个函数IP[32]。目前的覆盖网络具有适用于无服务器环境的适当的控制平面机制，但网络启动延迟较高。0图2显示了添加新网络命名空间到覆盖网络的步骤。大部分时间都花在S3和S4两个步骤上，其他步骤所花时间微不足道。在图2中，大多数步骤要么配置一个VETH设备，要么创建一个新的VETH设备，只有S3和S4在进行名称空间交叉并移动网络接口VETH。将本地VETH设备从主机网络命名空间移动到控制平面网络命名空间，并将客户VETH设备从主机网络命名空间移动到客户网络命名空间。移动VETH设备本质上是昂贵的，因为dev_change_net_namespace内核例程执行长时间任务，以确保在持有rtnetlink信号量的同时安全地移动VETH设备。启动移动后，内核首先通知所有设备通知链表VETH正在被注销。接下来，它从主机命名空间中删除VETH设备句柄并刷新旧配置。最后，它更新VETH数据结构以指向新的命名空间，并通知命名空间和通知链表该设备已经启动。就可伸缩性而言，当向覆盖层添加更多客户时，这六个步骤都会重复进行，每个容器重复进行三个不同的unshare调用和两个命名空间移动。这种开销导致表2中时间的线性增加。爆炸式并行覆盖网络的设计需要解决可伸缩性和性能挑战。02.4现有方法的挑战0表4比较了不同无服务器网络选项的功能和挑战。任何无服务器网络方法都必须适用于爆炸性低时延的多租户环境，并对网络和应用层做出最少的假设。此外，根据之前的工作[13，31，32]，无服务器系统还必须能够与第3层连接性一起工作，因为承载λ函数的节点并不总是第2层相邻的。0覆盖网络很有吸引力，因为它们满足大部分要求，但当前的实现存在重大的性能开销。容器编排器（如Kubernetes）使用Pod将容器整合到单个命名空间下，每个Pod具有一个可路由的IP，因为“一容器一Pod”是常用的设计模式[25]。由于每个Pod启动容器、网络命名空间和暂停容器，这种方法可能具有较高的启动延迟。如果我们每个Pod使用数百个容器来避免这种开销，每个容器都需要通过应用程序管理的端口多路复用或在Pod中创建卷来进行通信。从开发人员的角度来看，修改应用程序以具有端口多路复用逻辑并管理与应用程序逻辑相关的每个Pod数据库会产生显着的工程成本。其他替代方案也存在重大限制。使用Docker主机网络基本上不是多租户解决方案，而NAT洞穿需要创建多个点对点连接对，其中没有一个是可寻址的IP。根据我们对现有方法的评估，我们设计了Particle来满足现有的无服务器要求，并专注于能够快速生成和互连数千个临时网络终端的能力。03粒子设计0我们提出了Particle，一种在爆发式并行无服务器环境中优化网络启动的网络架构。Particle提供了一个动态生成的短暂IP池，几乎具有恒定的启动时间。Particle通过将网络创建与其他用户命名空间分离，并通过消除序列化点、批处理调用和合并VETH设备来优化网络终端的创建，同时保持每个函数的IP，来创建网络终端。通过这种方式，Particle可以加速网络命名空间的创建，而不对应用程序的功能或通用性产生任何不利影响。Particle210SoCC '20，2020年10月19日至21日，虚拟活动，美国谢尔比∙托马斯，利翔∙奥，杰弗里∙M.沃尔克，乔治∙波特0通过三个设计原则解决了第2.4节中的挑战：0将基础设施与应用程序匹配：爆发并行应用程序调用数百到数千个无服务器实例来完成一个复杂的任务。目前的底层基础设施并不针对这种应用程序类别的爆发性特性进行优化，因为每个无服务器任务都被视为无状态的独立函数。Particle采用技术来合并网络基础设施，而不会影响通用性、可编程性或网络多功能性。0通用套接字接口：由Particle分配IP的容器必须能够相互通信，而不需要任何专门的IPC协议、系统或存储。还必须能够访问第三方或网络托管的服务。容器必须能够使用POSIX套接字调用来相互通信（§3.1）。0可移植性：Particle对其部署的系统做出最少的假设。将Particle移植到其他覆盖层系统非常简单，因为大多数覆盖层都依赖于默认的Docker运行时进行网络配置。集成后，Particle对吞吐量没有负面影响。03.1 设计空间探索0在本节中，我们探讨了优化网络启动的三种不同方法：（1）命名空间合并，（2）批处理和（3）虚拟接口合并。我们希望通过对比这些设计在网络创建时间上的微基准测试（图3），并使用LinuxOverlay数据平面作为基准（系统配置详见第5节），来了解每种优化的权衡。0设计1：命名空间合并根据我们在§2.3中的发现，网络命名空间本身是高启动延迟的一个因素。解决这个问题的一种方法是采用许多容器编排器（如Kubernetes [25]和Amazon Elastic Containers[3]）在一个网络命名空间和IP下合并相关服务时所做的方式。这些服务执行命名空间合并以简化管理平面，但我们可以将传统的“一个容器对应一个Pod”模型扩展为“一个Pod对应多个容器”，作为性能优化。这种优化在突发并行环境中是天然的，因为许多无服务器实例作为单个任务的一部分一起工作。我们通过为一组容器创建一个新的根网络命名空间来探索这种设计，但每个容器维护其他类型隔离的内核命名空间（mnt、pid、ipc、user、cgroup）。这样，命名空间也可以为每个租户创建，而各个容器在操作时无需更改对环境的假设。每个容器都附加到Particle0100个端点01000个端点00.53±0.0400.55±0.010图3：连接100个和1000个并发网络命名空间到覆盖层所需的时间。虽然基线和其他优化随着更多端点的增加呈线性增长，但VETH合并使得Particle的启动时间在扩展时保持接近恒定。0根命名空间，并继承其iptables和路由配置，而无需创建自己的网络命名空间。由于我们希望每个容器都有一个可寻址和可路由的IP地址（§2.4），我们为根命名空间中的每个容器创建一个VETH接口，该接口具有一个IP地址和MAC地址。图3中的微基准测试结果显示，在启动1000个端点时，这种“共享命名空间”设计具有适度的性能优势，但对于100个端点几乎没有性能影响：仅靠共享命名空间无法解决表3中显示的根本问题。在创建新容器时，覆盖层控制器必须为每个新容器创建一个VETH对，并执行VETH移动。使用共享命名空间时，唯一的区别是VETH不是移动到单独的网络命名空间，而是移到共享网络命名空间。如果可以使用主机命名空间而不是额外的共享命名空间，则可以进一步优化。这样做可以减少命名空间的数量和220粒子：无服务器网络的临时端点 SoCC’20，2020年10月19-21日，虚拟活动，美国0减少一个VETH移动：主机命名空间创建一个VETH对，并将本地端口移入VTEP。这种优化的权衡是，它不能与多租户设置匹配，因为主机接口不具备隔离性。0设计2：批处理和IP池共享命名空间合并的一个主要缺点是，虽然它利用了突发并行任务可以在单个根网络命名空间中合并的事实，但网络命名空间本身的设置仍然是迭代完成的。执行命名空间合并的优点是降低了在突发并行环境中管理许多命名空间的复杂性。在下一个设计中，我们进一步推动了这些思想，对网络命名空间内的VETH创建进行了批处理优化。通过批处理，当接收到突发并行请求时，系统根据指定的IP范围和容器数量创建一个IP池。系统不需等待容器创建完成，而是立即创建所有必需的用于数据平面的虚拟接口，并将其附加到根网络命名空间。完成后，系统进入覆盖层的控制平面命名空间，并批量设置相应的VETH设备并将其附加到VXLAN端口。批处理的一个重要好处是它减少了上下文切换和unshare调用的次数。然而，仅实现批处理仍会导致 �(�)命名空间交叉和VETH移动。对于相同的基准测试，图3显示，与具有100个容器的标准LinuxOverlay相比，批处理提供了22%的改进，并且在具有1000个容器时提高到42%。尽管批处理改善了LinuxOverlay和简单共享命名空间的性能，但系统仍然在命名空间内执行许多 �(�) 操作，尽管是批处理的。例如，仍然创建了 �个不同的VETH设备、MAC地址和IP地址。0最终设计：虚拟接口合并前两个设计开发了管理平面——根命名空间，并得出了批处理并行组的网络、VETH和IP批量创建可提高性能的结论。然而，这两个设计并未显著减少系统必须创建的VETH设备总数。表3显示，无论是批处理还是命名空间合并，每个创建的VETH设备都会产生开销。此外，对于每个创建的容器，仍然会创建 �(�) 个VETH设备和 �(�)个VETH接口移动到其他命名空间。前两个设计改善了性能，但没有解决这个最后一个问题。作为最终的设计要素，我们专注于使VETH设备的创建成为一个恒定时间操作，而不是线性操作。为此，我们在根命名空间内创建一个单独的VETH设备，并将多个IP地址附加到此根VETH接口上。0调用了批处理并行作业0Particle命名空间在多个节点上进行配置。每个节点每个作业一个命名空间。0每个节点创建一个VETH设备。可以一次性将多个IP地址附加到此设备上。0创建的容器继承来自Particle命名空间的VETH和IP池。它们立即开始使用可用的IP地址在彼此和其他节点之间传输数据。0调用（200，λ，2）0节点 10节点 0 节点10粒子网络命名空间0VETH0节点 0 节点 10节点 00粒子网络命名空间0粒子网络命名空间0IP IP0图4：附加容器的Particle命名空间。单个应用程序的多个容器之间仅共享网络命名空间。每个Particle命名空间都有自己的MAC地址，该地址提供给VTEP进行路由。多个租户具有不同的Particle命名空间。0在传统的覆盖网络中，VETH设备对和容器一对一映射。这种映射只是因为每个容器都存在于其自己的隔离环境中才是必需的。我们取消了每个容器的网络隔离，将一个VETH对附加到控制面和数据面。然后，多个IP地址和MAC地址附加到根命名空间的单个根VETH接口上。从控制面的角度来看，附加到VXLAN接口的所有IP地址都会进行路由。图3显示了这种新的VETH接口与IP地址之间的一对多映射改进了性能，因为只需要一个命名空间交叉来执行一个批并行作业。当创建100个容器时，VETH合并将性能提高了17倍，当创建1000个容器时，性能提高了213倍。启动100个网络命名空间所需的绝对时间为534毫秒，启动1000个网络命名空间所需的绝对时间为553毫秒。534毫秒来自两个部分，创建一个新的根网络命名空间并附加覆盖。根命名空间作为一个只有回环接口（—net=none）的Docker容器开始，平均需要300毫秒。剩下的234毫秒是创建根VETH接口的时间，将其附加到控制面网络命名空间，并添加IP地址。从高层次来看，Particle通过将昂贵的O(N)“每个容器”调用替换为O(1)“每个作业”调用来提高性能。基于10.0.0.1010.0.0.10230SoCC ’20，2020年10月19日-21日，虚拟活动，美国Shelby Thomas，Lixiang Ao，Geoffrey M. Voelker和George Porter0vxl310veth-l 0 veth-g084:1a:00:00:00:1c 10.0.0.110Particle 客户1 netns Particle 客户0 netns084:1a:00:00:00:1b010.0.0.11 br40vxl420veth-l 10Particle：多租户0veth-guest 00主机0图5：使用Particle的多租户：每个应用程序都有自己的Particle命名空间，以保持与其他租户和主机的网络隔离。控制平面负责为其他租户提供额外的VXLAN接口来提供额外的VNIs。以这种方式设计覆盖网络还允许每个客户端在没有限制的情况下使用任何IP地址。0根据我们在§2.3中的发现，创建一个容器网络涉及到多个内核锁，这些锁有效地串行化了网络的创建过程。当试图创建数百个无服务器实例和相应的网络端点来协调一个单一作业时，这种开销会加剧。Particle的设计是为了能够以最小的改动集成到现有的覆盖网络中。如§2.2所述，覆盖网络由控制面和数据面组成。尽管控制面在设计上各不相同，但所有控制面都依赖于类似的数据面实现，如图2所示。批并行应用具有逻辑计算单元是一批无服务器实例共同努力实现单一目标的特性。因此，尽管每个容器都从标准的隔离保证（进程、文件系统等）中受益，但网络接口对实例之间并不要求严格的隔离。然而，Particle仍然会严格隔离主机和其他租户的网络。图4说明了Particle的架构。每个租户每个节点创建一个单独的命名空间和VETH设备。然后，多个次要IP地址附加到VETH设备上，创建一个临时的作业IP池。覆盖网络通过其自己的策略和机制使这些IP可路由。容器可以附加到可用的IP地址，并在容器之间（节点内和节点间）传输数据。作业完成后，Particle移除其命名空间和IP地址。图5展示了在多租户环境中的VETH合并示例。每个客户都有自己的Particle命名空间，其MAC地址与VTEP共享。单个VETH接口可以为共享Particle（根）命名空间的任何容器托管数千个次要IP地址。应用程序可以通过多种不同的方式与此系统进行交互。03.2 隔离和应用程序接口0将多个容器的VETH设备和命名空间合并成一个命名空间中的一个虚拟设备可能对应用程序中的容器产生副作用。独立的命名空间隔离了网络资源并提供了安全性。0隔离。如果一个容器被攻击，不同命名空间中的其他容器不会受到影响。由于Particle合并了网络命名空间，它无法提供相同粒度的安全隔离。然而，由于Particle仅合并同一租户/应用程序的命名空间，不同租户始终通过独立的命名空间进行隔离，我们认为这种权衡对于由多个无服务器实例共同工作的应用程序模式是可以接受的。从概念上讲，应用程序为不同的容器请求不同的IP地址，Particle分配这些IP地址以避免冲突。然而，如果容器中的应用程序不遵守分配，同一应用程序的不同容器可以通过尝试绑定到相同的IP地址/端口对相互干扰。在同一主机上运行多个容器并通过Particle共享VETH设备时，这种情况可能会无意中发生。如果它们尝试使用INADDR_ANY绑定到相同的端口，可能会发生端口冲突。因此，应用程序需要使用分配给它们的IP地址来避免此类冲突。Particle可以通过覆盖libc的bind调用（通过LD_PRELOAD机制）来确保IP地址参数与分配给容器的IP地址匹配，从而进行干预。如果应用程序不使用动态链接的libc，或直接调用bind系统调用，Linux Seccomp[16]提供了一种强制执行IP地址分配的机制。Seccomp的过滤模式允许指定某些系统调用的可接受参数，例如，bind系统调用的参数可以是分配的IP地址。04 实施0Particle使用C语言实现，并集成到Linux中的iproute2工具中。Particle不是设计用于直接使用，而是作为覆盖系统中存在的核心模块。因此，Particle对所使用的控制平面的类型没有任何假设。0102030400.00.20.40.60.81.0240Particle：无服务器网络的临时终端 SoCC ’20，2020年10月19日-21日，虚拟活动，美国0100/1 200/2 400/4 800/8 容器/节点0时间（秒）0Docker Swarm覆盖Weave覆盖 Linux覆盖Particle+WeaveParticle+Linux0图6：多节点聚合应用程序：启动一组容器、连接到覆盖网络并协调一项全对一聚合作业所需的总时间。当增加更多节点时，Particle对覆盖网络控制平面没有不良影响。0将Particle移植到现有的覆盖网络需要在控制面和数据面上进行适配。对于数据面来说，现在的覆盖系统在为单个容器提供网络命名空间时不需要创建网络命名空间。此外，它们必须创建一个额外的容器，该容器被传递到Particle中用于组命名空间。对于使用键值存储的覆盖系统，需要一个控制平面适配器将IP地址作为一次性操作传递到数据库中。在我们的评估中，我们将Particle的模块集成到Linux覆盖和Weave覆盖系统中。在这两种情况下，这些覆盖系统传递VTEP的命名空间，并且必须创建一个没有初始网络的新容器。指向此网络命名空间的指针也传递给了Particle。此时，Particle同时拥有控制面网络命名空间（VTEP）和数据面网络命名空间的句柄。根据请求的容器数量，Particle使用相同数量的IP地址初始化共享命名空间。然后，上下文切换回现有的覆盖系统，根据Particle的MAC地址向控制平面的其他成员广告路由。05 评估0我们首先评估Particle在两种通信模式（聚合和洗牌[18]）的启动性能。接下来，我们评估Particle在一个现实世界的突发并行应用Sprocket上的性能。最后，我们看一下Particle在多租户环境中的性能。在我们的实验中，我们使用AWS EC2C5.4xlarge实例，每个实例有24个虚拟CPU，32 GB内存和10Gb/s网络带宽。所有实例都在同一个虚拟私有云中。00 5 10 15 20 25 30 时间（秒）0CDF0Particle+LinuxParticle+Weave0Linux OverlayDocker Swarm0图7：多节点洗牌应用程序：洗牌应用程序中发送的消息的CDF。两个节点上的100个发送方和接收方交换了10,000个消息。使用Particle的覆盖网络减少了启动时间，因此应用程序代码几乎立即开始运行。0（VPC）和分组以获得稳定的网络性能。实例使用Ubuntu18.0