16→×Particle：无服务器网络的短暂端点摘要谢尔比·托马斯加州大学圣地亚哥shelbyt@ucsd.edu杰弗里·M Voelker加州大学圣地亚哥voelker@cs.ucsd.edu敖丽香加州大学圣地亚哥liao@eng.ucsd.edu乔治·波特加州大学圣地亚哥gmporter@cs.ucsd.eduACM参考格式：突发并行无服务器应用程序调用数千个短期分布式函数来完成复杂的工作，如数据分析、视频编码或编译。 虽然这些任务在几秒钟内执行，但启动和配置它们所依赖的虚拟网络是一个主要的瓶颈，可能会占用总启动时间的84%。 在本 文 中，我 们 描 述 了三 种流 行 的覆 盖 网 络 （ DockerSwarm，Weave和Linux Overlay）中网络冷启动问题的严重程度。我们专注于端到端启动时间，包括启动一组容器以及将它们互连的时间我们的主要观察结果是，现有的无服务器网络覆盖方法在短期无服务器环境中的 基于我们的研究结果，我们开发了Particle，这是一个针对多节点无服务器覆盖网络的网络堆栈，它优化了网络创建，而不会牺牲多租户，通用性或吞吐量。当集成到无服务器突发并行视频处理管道中时，Particle将应用程序运行时间提高了现有覆盖的2.4-3倍。CCS概念• 计算机系统组织云计算。关键词无服务器，网络，突发并行，lambda本作品采用知识共享署名国际4.0许可协议进行许可。SoCC©2020版权归所有者/作者所有。ACM ISBN978-1-4503-8137-6/20/10。https://doi.org/10.1145/3419111.3421275放 大 图 片 作 者 ： Michael M.Voelker 和 George Porter 。 2020.Particle：Ephemeral Endpoints for Serverless Networking. 在ACM云计算研讨会（SoCC '20），2020年10月19日至21日，虚拟活动 ， 美 国 。 ACM ， 纽 约 州 纽 约 市 ， 美 国 ， 14 页 。https://doi.org/10.1145/3419111.34212751介绍无服务器计算在云计算领域提供了一个高级计算抽象[18]。从用户的角度来看，它简化了应用程序部署，因为提供商管理了更大部分的资源，包括网络，操作系统，运行时和库，允许用户专注于他们的应用程序代码。 虽然提供商最初设计的无服务器平台支持Web和API服务，但用户现在可以在几秒钟内启动数千个并行“功能”，大大提高了云计算资源的弹性。这些短期功能的一个日益增长的新用途是“突发并行”作业的出现突发并行作业的特点是具有非常高扇出的并行任务，由数千个无服务器功能组成，所有功能都由单个用户部署。Fouladi等人 [11]展示了如何将这种方法应用于视频编码，将工业级编码器的编码时间从149分钟减少到2.6分钟。Ao等人[4]应用类似的模型为端到端视频处理管道开发了一个基于云的突发并行系统，该系统在视频处理作业上的性能优于Spark。与传统的无服务器用例相比，由数千个并发功能组成的单个作业具有独特的基础设施要求，当前的无服务器平台无法有效支持。特别是，支持服务器的网络层较少的平台对于突发并行应用尤其低效。这些应用程序使用数百个并发的无服务器功能来完成复杂的任务，并且代替无服务器平台上的本地对等网络功能，必须通过中间存储进行协调[4，10，11，20]。到目前为止，这种解决方法已被广泛使用SoCC放大图片作者：Michael M.Voelker和George Porter17而是ad-hoc的、特定于应用的、需要附加的基础结构服务并且使用户代码复杂化。这些缺点是有效支持更广泛的一般突发并行数据分析的障碍，例如MapReduce类应用程序中的“洗牌”阶段[8，28]，典型科学计算应用程序中的消息传递[ 12 ]，以及并行系统通信图中的顶点遍历[15，24，30]。虽然目前没有一个主要的云提供商具有突发并行优化的网络功能，但实现这种对等网络在工业界[31]和学术界[18]中的兴趣越来越大。 已经提出了两种解决方法，即NAT穿孔和覆盖网络，但两者都具有通用性和性能缺陷，正如我们在本文后面描述的那样。为了演示这一点，考虑使用Pywren [17，29]运行时构建的应用程序，如图1所示。 在这个实验中，100个容器同时启动，每个容器在完成时向领导节点发送确认之前执行基本计算。对于所有三种常规方法，启动100个容器需要大约4.8秒。这个网络开销是应用程序运行时间的4倍，或者说是整个无服务器启动时间的66 -84%;实际上，网络启动开销甚至可能超过实际的应用程序执行。对于突发并行应用程序，快速启动时间是至关重要的，这与传统应用程序从快速线程创建中受益的方式大致相同。在本文中，我们描述现有的网络方法并提出了一个优化的网络堆栈，第三篇，以减少网络开销时，建立网络的突发并行无服务器作业。 Particle的关键见解是，支持突发并行作业的网络不需要在用户的容器之间提供隔离，只需要在不同用户的容器之间提供隔离。 这种权衡类似于为什么线程比进程更有效地创建，因为线程间隔离保证的差异。我们证明了Particle可以支持许多不同的无服务器框架。总之，本文的贡献是：评估无服务器突发并行网络的挑战，重点是网络启动问题。评估三种不同的设计，以克服网络启动问题。最后一个设计，粒子，使恒定时间网络创建和启动.我们使用微基准测试、无服务器模式、突发并行应用程序、多租户设置对Particle进行了评估，并验证了对网络吞吐量没有任何不利影响。粒 子 的 源 代 码 可 在 以 下 URL 获 得 ：https://github.com/shelbyt/socc20particle。20151050图1：将100个虚拟化实例连接到覆盖网络所需的时间。网络启动时间占总启动时间的83%。与Docker SwarmParticle相比，网络设置减少了32倍，端到端启动时间减少了3.5倍。2背景和动机在无服务器系统上的许多努力都集中在容器启动时间上，与网络在功能间通信中的作用 随着无服务器从独立的单一功能发展到协调的突发并行应用，快速、多功能和可扩展的网络创建对于满足这类应用的突发性质变得越来越重要。基于VXLAN的覆盖网络（如Weave、LinuxOverlay和Docker Swarm）旨在满足现代数据中心网络的多功能性和可扩展性要求，但它们的实现是专门为支持数十个严格隔离的长期运行连接而设计的，而不是数千个短期运行连接。我们描述了如何覆盖网络架构的基础机制，今天和基准的每一块覆盖网络创建在应用程序级和内核级。 我们的主要发现是，覆盖数据平面与容器交互的方式为许多基于VXLAN的覆盖带来了严重的延迟问题-当互连数百个无服务器功能时，这个问题会加剧。幸运的是，这样的瓶颈提供了以可移植的和通用的方式解决问题的机会。容器化是无服务器平台中最常见的隔离机制，被GoogleFunction 、 IBM OpenWhisk 和 Azure Functions 使 用 因此，本文的其余部分将重点放在容器作为执行平台上。应用程序运行网络启动容器启动时间（秒）···Particle：无服务器网络的短暂端点SoCC18总连接/节点连接时间（s）101/1 15.74404/4 15.6615.99表1：按比例放大节点：当增加节点数量同时保持每个节点的连接数量恒定时，端到端启动时间2.1叠加数据和控制平面实现覆盖的底层技术是VXLAN协议。VXLAN是一种封装协议，它使用唯一标识符（VNI）包装来自容器组的数据包，允许在不影响隔离的情况下进行通信。以这种方式连接的设备然后形成覆盖网络。覆盖网络由两个不同的部分组成：控制平面和数据平面。 控制平面是存在以管理跨多个租户的覆盖网络的网络内服务。这些连接由每个主机内的数据平面发起与控制平面不同，数据平面只存在于无服务器应用程序中。它负责根据VNI、IP和MAC地址将数据转发到正确的容器。VXLAN数据平面要求每台主机都有一个VXLAN隧道端点（VTEP），负责VXLAN的终结和封装。当使用VXLAN将数据包从一个容器发送到另一个容器时，主机上的VTEP将来自容器的原始以太网帧封装为VXLAN报头。封装后的数据包又与外部IP和MAC报头一起从主机发送出去。 当另一个容器接收到分组时，接收方侧的VTEP查看VNI和内部MAC地址，并将有效载荷传递到适当的容器。覆盖网络还需要控制平面来管理VTEP路由信息。控制平面保持主机VTEP、VNI和容器MAC地址的映射。当一台主机上的容器向另一台主机上的容器发送数据时，VTEP会使用VNI封装数据包，并在本地检查路由信息是否存在。如果没有，则探测控制平面，然后使用新路由来路由数据包控制平面的实现是多种多样的，其中一些使用虚拟路由器[33]、gossip协议[9]、BGP [6]和KV存储[7，9]。将这两个网络平面粘合在一起的粘合剂是网络名称空间。 Linux网络命名空间机制在内核中创建新的逻辑网络堆栈 ， 每 个 堆 栈 都 有 自 己 的网 络 设 备 、 邻 居 和 路 由 表 、/proc/net目录和其他网络堆栈状态。通过调用unshare创建网络命名空间总连接启动空间设置时间（s）10010.0240038.901600119.79表2：按比例增加每个节点的连接：与表1相反，增加单个节点上的连接/名称空间的数量的比例很差。或根据实现使用CLONE_NEWNET标志进行克隆 在覆盖的上下文中，虚拟以太网设备（VETH）用作端点，然后将命名空间连接在一起，并且可以配置为具有MAC和IP地址。关于数据平面的开销是建立命名空间的函数，而控制平面中的开销是建立路由的函数。 为了了解哪一个会给应用程序带来更大的负担，我们对两者都进行了可伸缩性分析。2.2性能瓶颈我们的目标是了解覆盖性能的瓶颈，而不被捆绑到任何特定的覆盖方法。 为此，我们尽可能避免使用专有软件进行这些微基准测试，并使用原生Linux命令来管理数据和控制平面。为了加深我们对系统开销的理解，我们进行了一个小型的微基准测试。这个实验在Amazon AWS上运行，使用的是运行在Linux内核5.0.0-1004上的Ubuntu 18.04的c5.4xlarge机器。我们使用基于BGP的Quagga EVPN [5]作为虚拟路由器和Linux原生iproute2v5.2.0 [14]来管理Docker容器和命名空间，创建了一个功能齐全的扩展节点数：我们首先确定向现有覆盖网络添加更多节点是否会降低控制平面的速度。为了回答这个问题，我们首先启动了一个包含100个容器的集群，并创建了一个覆盖网络，将每个节点上的容器相互 我们改变节点的数量，并记录何时添加新路由。表1总结了我们的观察结果，显示了启动Docker容器、初始化数据平面、连接到控制平面以及将数据发送到给定接收器节点所需的时间。 为了增加基于BGP的控制平面上的负载，我们扩展了节点（以及连接到控制平面的端点）的数量。每个主机的容器数量保持不变，但需要连接的数量线性增加，直到1600个容器联网。额外的连接是VTEP之间的连接要点：在16个节点上，控制平面对性能的影响可以忽略不计，并且在以下误差范围内：SoCC放大图片作者：Michael M.Voelker和George Porter1910.0.0.1000：00：00：00：00主机❶主机网络VTEP网络集装箱网主机❷主机网络VTEP网络集装箱网主机❸主机网络VTEP网络容器网络veth-gVeth-1主机❹主机网络VTEP网络容器网络veth-g主机❺主机网络VTEP网络容器网络veth-g主机❻主机网络VTEP网络容器网络步骤 时间（秒） 合计百分比br42vxl42veth-gbr42Veth-1vxl42为容器创建新的网络br42vxl42创建访客和本地VETHVeth-1br42vxl42表3：图2中用于100个网络命名空间的覆盖数据平面大部分时间花在名称空间之间移动VETH设备上（步骤S3和S4）.将访客VETH移动到容器中将本地VETH移动到VTEPVeth-1br42vxl42Veth-1veth-gbr42IPMACvxl42表2显示，总时间随着附加到覆盖层的名称空间的数量而线性增加（与我们在控制平面上观察到的情况请注意，我们只显示了实例化网络数据平面的时间我们通过改变连接到这个覆盖网络的名称空间的数量来测量可扩展性。我们观察到将本地连接到VXLAN VNI桥接两个VETH接口将IP和MAC连接到来宾大部分时间都花在了内核上。要点：表1显示了端到端启动需要15.74秒，一个节点上有100个容器 表2显示，大部分时间用于将名称空间联网，占端到端启动时间的60%以上。随着网络名称空间数量的增加，设置代价也会增加 这种可扩展性的缺乏是无服务器上突发并行部署的主要瓶颈。2.3网络空间的作用对其他容器重复上述步骤图2：为覆盖数据空间创建一个新的网络接口涉及到一系列操作，这些操作将在每个新容器中重复进行。我们将网络命名空间称为“netns”。最初，仅存在与控制平面通信的VTEP。BR是网桥接口，VXL是连接到网桥的VXLAN接口。这一观察尺度。我们将证明，这种结果不是数据平面的情况。增加单个节点上的连接：接下来，我们将描述向覆盖网络添加容器对数据平面性能和可扩展性的影响。 我们在一个节点上创建一个单一的覆盖网络，并将其连接到控制平面，改变添加到该覆盖的网络名称空间的数量。我们将重点分析网络名称空间本身的开销，而不是容器创建时间。图2说明了向覆盖网络添加新的网络名称空间所涉及的步骤此过程类似于使用基于VXLAN的覆盖的所有覆盖网络软件。最初，主机实例化VTEP的控制平面命名空间和主机的标准网络命名空间。首先，我们创建一个新的访客网络命名空间。接下来，我们在主机名称空间中创建一对VETH设备从主机名称空间，我们将这些VETH设备放入控制平面的网络名称空间和访客名称空间。然后，我们将本地VETH与VTEP的VXLAN和网桥接口绑定，并打开本地和客户接口。最后，我们通过为访客网络命名空间设置IP和MAC来建立到VTEP的连接此时，客户机连接到覆盖，所有数据将通过适当的VNI传输。 对于覆盖网络中的每个新访客重复这些步骤。我们进一步细分数据平面创建的仪器-使用eBPF [22]执行图2中的步骤，并报告将100个网络名称空间连接到覆盖的相对和绝对时间表3将执行时间分解为主机多个容器容器0容器1容器2主机网络VTEP网络S10.100.92%S20.100.92%S35.1847.71%S44.77百分之四十三点九五S50.494.45%S60.222.03%veth-g10.0.0.1000：00：00：00：00Veth-1Veth-1veth-g10.0.0.112019 - 01 - 18 00：00：00Veth-1veth-g10.0.0.1200：00：00：00：00br42vxl42Particle：无服务器网络的短暂端点SoCC20无服务器网络分离低延迟IP可寻址L3溶液连接类型NAT冲孔✓✗✗✓✗Point-to-pointKubernetes Pod✓-✗✗端口多路复用和卷Docker主机网络✗✓✓✓直接IP覆盖网络✓✗✓✓直接IP颗粒✓✓✓✓直接IP表4：不同无服务器网络选项的功能和挑战比较：无服务器网络解决方案必须适用于突发性低延迟多租户环境。无服务器系统还必须能够使用第3层连接，并为直接功能间通信提供每个功能的IP [32]。 当今的覆盖网络具有适用于无服务器环境的控制平面机制，但具有较高的网络启动延迟。步骤如图2所示。大部分时间花在S3和S4两个步骤上，其他步骤的时间可以忽略不计。虽然图2中的大多数其他步骤要么配置VETH设备，要么创建一个新的VETH设备，但只有S3和S4执行命名空间交叉并移动网络接口VETH。本地VETH设备从主机网络命名空间移动到控制平面网络命名空间中，并且访客VETH从主机网络命名空间移动到访客网络命名空间中。移 动 VETH 设 备 的 成 本 本 来 就 很 高 ， 因 为dev_change_net_namespace内核例程执行一个长时间运行的任务，以确保在保持rtnetlink信号量的同时安全地移动 当移动被启动时，内核首先通知通知器链上的所有设备VETH正在被注销。接下来，它从主机名称空间中删除VETH设备句柄并刷新旧的配置。最后，它更新VETH数据结构以指向新的名称空间，并通知名称空间和通知程序链设备处于活动状态。在可伸缩性方面，当更多的访客被添加到覆盖时，这六个步骤中的每一个都被重复，导致三个不同的unshare调用和每个容器两个命名空间移动。在表2中，该开销说明了时间的线性增加。突发并行覆盖网络的设计需要解决可扩展性和性能挑战。2.4现有方法的挑战表4比较了不同无服务器网络选项的功能和挑战。 任何无服务器网络方法都必须适用于突发的低延迟多租户环境，并对网络和应用程序层做出最少的假设。此外，基于以前的工作[13，31，32]，无服务器系统也必须能够使用第3层连接，因为托管lambda函数的节点并不总是与第2层相邻。覆盖网络是有吸引力的，因为他们满足大多数的要求，但目 前 的 实 现 有 显 着 的 性 能 开 销 。 容 器 编 排 （ 如Kubernetes）使用pod将容器整合到单个命名空间下，每个pod有一个可路由的IP，因为通常使用的设计模式是“one-container-per-pod”[ 25 ]。这种方法潜在地具有更高的启动延迟，因为每个pod启动一个容器、一个网络名称空间和一个暂停容器。如果我们在每个pod中使用数百个容器来避免这种开销，那么每个容器将需要通过应用程序管理的端口多路复用进行通信，或者在pod中创建一个卷以供容器共享。从开发人员的角度来看，将应用程序更改为具有端口多路复用逻辑并使用相关的应用程序逻辑管理每个pod数据库会导致显著的工程成本。其他替代方案也有很大的局限性。使用Docker主机网络基本上不是多租户解决方案，NAT打孔需要创建多个点对点连接对，其中没有一个是IP可寻址的。基于我们对现有方法的评估，我们设计了Particle来满足现有的无服务器需求，并专注于快速生成和互连数千个临时网络端点的能力。3粒子设计我们提出了Particle，这是一种网络架构，可以优化突发并行无服务器环境中的网络启动。Particle在几乎恒定的启动时间提供了一个短暂的动态生成的IP池。Particle不使用内存密集型缓存技术，而是通过首先将网络创建与其他用户命名空间分离来创建网络端点组，然后通过消除串行化点、重复调用和合并VETH设备来优化网络端点的创建，同时维护每个功能的IP。 通过这种方式，Particle可以加速网络命名空间的创建，而不会对应用程序的功能或通用性产生任何不利影响。颗粒SoCC放大图片作者：Michael M.Voelker和George Porter21通过三个设计原则解决了§2.4中的挑战将基础设施与应用程序相匹配：突发并行应用程序调用数百到数千个无服务器实例来完成单个复杂作业。 今天的底层基础架构并没有针对这种应用程序类的突发特性进行优化，因为每个无服务器任务都被视为无状态的独立功能。Particle采用技术来整合网络基础设施，而不影响通用性，可编程性或网络通用性。通用套接字接口：由Particle分配IP的容器必须能够相互通信，而不需要任何专门的IPC协议，系统或存储。第三方或网络托管服务也必须是可能的。 容器必须能够使用POSIX套接字调用来相互通信（第3.1节）。可移植性：Particle对部署它的系统做了最少的假设。将Particle移植到其他覆盖系统是很简单的，因为大多数覆盖依 赖 于 默 认 的 Docker 运 行 时 进 行 网 络 配 置 。 集 成 后 ，Particle对吞吐量没有不利影响。3.1设计空间探索在本节中，我们将探索优化网络启动的三种不同方法：（1）命名空间整合，（2）虚拟化，以及（3）虚拟接口整合。我们试图了解每个优化中的权衡，以告知我们最终的粒子设计。 在图3中，我们使用关注网络创建时间的微基准测试来比较设计，并使用Linux Overlay数据平面作为基线（系统配置细节见第5节）。设计1：空间整合根据我们在第2.3节中的发现，网络名称空间本身是导致高启动延迟的一个因素。 解决这个问题的一种方法是 采 用 许 多 容 器 编 排 （如 Kubernetes [25] 和Amazon Elastic Containers [3]）在一个网络命名空间和IP下共同定位相关服务时所做的事情。 这些服务执行命名空间合并以简化管理平面，但是我们可以将传统的“每个pod一个容器”模型扩展为“每个pod多个容器”作为性能优化。 这种优化非常适合突发并行环境，在这种环境中，许多无服务器实例作为单个任务的一部分一起工作。我们通过创建一个新的根网络来探索这种设计命名空间，但每个容器都维护单独的内核命名空间（mnt、pid、ipc、user、cgroup），用于其他类型的隔离。 通过这种方式，还可以为每个租户创建名称空间，而单个容器的操作无需更改关于环境的假设。每个容器都连接到粒子100个终点.040.53±01000个终点0.55±0.01图3：将100个和1000个并发网络命名空间连接到覆盖的时间。虽然基线和其他优化随着端点的增加而线性增加，但VETH合并允许Particle根命名空间，并继承其所有iptables和路由配置，而无需创建网络命名空间本身。由于我们希望每个容器都有一个可寻址和可路由的IP地址（第2.4节），因此我们为命名空间内的每个容器创建一个VETH接口，并提供IP和MAC地址。图3中的微基准测试结果表明，这种“共享名称空间”设计在启动1000个端点时具有适度的性能优势，但对于100个端点几乎没有性能影响：单独使用共享名称空间并不能解决表3中所示的根本问题。 当创建新容器时，覆盖控制器必须为每个新容器创建VETH对并执行VETH移动。 对于共享命名空间，唯一的区别是，VETH不是移动到每个容器的单独网络命名空间中，而是移动到共享网络命名空间中。如果可以使用主机名称空间而不是其他共享名称空间，则可以进一步优化。这样做可以减少名称空间的数量，Particle：无服务器网络的短暂端点SoCC22（）下一页（）下一页（）下一页（）下一页××它减少了一次VETH移动：主机名称空间创建VETH对，并且仅将本地端移动到VTEP中。 代价是这种优化不匹配多租户设置，因为没有主机接口的隔离。设计2：批处理和IP池共享命名空间合并的一个主要缺点是，尽管它利用了突发并行任务可以在单个根网络命名空间内合并的事实，但设置网络命名空间本身仍然是迭代执行的。 执行名称空间合并的优点是它降低了在突发并行环境中管理多个名称空间的复杂性。在下一个设计中，我们通过对网络名称空间内的VETH创建执行一个优化来进一步推进使用IP地址分配，当接收到突发并行请求，系统会根据指定的IP范围和容器数量创建IP池而不是等到容器被创建，invoke（200，λ，2）突发并行作业被调用在多个节点上提供粒子存储空间。每个作业每个节点一个命名空间。为每个节点创建一个VETH设备。多个IP地址批量连接到此设备。创建容器并从粒子命名空间继承VETH和IP池。它们立即开始使用可用的IP在彼此和其他节点之间传输数据。立即创建数据平面并将其附加到根网络命名空间。一旦完成，系统然后进入覆盖的控制平面命名空间，并设置相应的VETH设备，并将它们批量附接到VXLAN端口。共享的一个关键好处是它减少了上下文切换和非共享调用的数量。但是，单独实现VETH仍然会导致名称空间交叉和VETH移动。对于相同的基准测试，图3显示，与具有100个容器的标准Linux Overlay相比，Linux Overlay提供了22%的改进，并且在具有1000 个容器的情况下提高到42%。 尽管LinuxOverlay和一个简单的共享命名空间提高了性能，但系统仍然在命名空间内执行许多操作，尽管是批处理。例如， 仍在创建不同的VETH设备、MAC地址和IP地址。最终设计：虚拟接口整合前两个设计开发了一个管理平面、根命名空间，以及为突发并行组批量创建网络、VETH和IP以提高性能的见解。不幸的是，这些设计都没有显著减少系统必须创建的VETH设备的总数。表3显示，不管VETH和名称空间整合如何，创建的每个VETH设备都会产生开销。此外，对于创建的每个容器，仍然会创建VETH设备，并且VETH接口会跨名称空间移动。前两个设计提高了性能，但没有解决最后一个问题。作为最后的设计元素，我们专注于使VETH设备创建一个恒定的时间操作，而不是线性的。为此，我们在根名称空间内创建一个VETH设备，并将多个IP附加到这个根VETH接口。图4：一个带有容器的Particle命名空间. 只有网络命名空间在单个应用程序的容器之间共享每个Particle命名空间都有自己的MAC地址，该地址提供给VTEP用于路由。多个租户具有不同的Particle命名空间。在传统的覆盖网络中，在VETH设备对和容器之间存在一对一的映射这种映射ping是必要的，因为每个容器都驻留在自己的隔离环境中. 我们免除了每个容器的网络隔离，将一个VETH对连接到控制平面和数据平面。然后，多个IP和MAC被附加到根名称空间 从控制平面的角度来看，连接到VXLAN接口的所有IP地址都被路由。图3显示，VETH接口和IP地址之间的这种新的一对多映射将性能提高了一个数量级，因为一个突发并行作业只需要一个名称空间交叉VETH整合在创建100个容器时将性能提高了17倍，在创建1000个容器时将性能提高了213倍启动100个网络命名空间的绝对时间为534 ms，启动1000个网络命名空间的绝对时间为553 ms。534 ms来自两个部分，创建一个新的根网络名称- pace和附加覆盖。根命名空间开始为一个Docker容器，只有一个接口（-net=none），平均需要300毫秒。剩余的234 ms是创建根VETH接口、将其附加到控制平面网络命名空间以及添加IP地址的时间在一个高水平的粒子系统地取代昂贵的时间复杂度为O（1），所以我们可以用O（基于IPVethIP没有P粒子网络NVamETspHace节点1节点0节点1节点0粒子网络空间article网络空间节点0de 1SoCC放大图片作者：Michael M.Voelker和George Porter23主机粒子：多租户访客0容器0访客0容器110.0.0.10韦思客110.0.0.1100：00：00：客人1集装箱0客人1集装箱1粒子访客0 netnsVTEP网络粒子访客1 netnsvxl42vxl31br42br31veth-11veth-10veth-guest02019 - 01 - 18 00：00：0010.0.0.1010.0.0.11图5：使用Particle的多租户：每个应用程序都有自己的Particle名称空间，以维护与其他租户和主机的网络隔离控制平面负责以附加VXLAN接口的形式为附加租户提供附加VNI以这种方式设计覆盖层还允许每个访客不受限制地使用他们想要的任何IP地址。根据我们在§2.3中的发现，容器网络的创建涉及到几个内核锁，它们有效地序列化了网络创建。 当试图创建数百个无服务器实例和相应的网络端点来协调单个作业时，这种开销会加剧。Particle旨在以最小的变化集成到现有的覆盖网络中。 如§2.2所述，覆盖网络由控制平面和数据平面组成. 虽然控制平面在设计中有所不同，但所有设计都依赖于类似的数据平面实现，如图2所示。突发并行应用程序具有这样的属性，即逻辑计算单元是一批为单个目标工作的无服务器实例。因此，虽然每个容器都受益于标准隔离保证（进程、文件系统等），网络接口不需要实例之间的严格然而，Particle仍然强制执行与主机和其他租户的严格网络隔离。图4展示了Particle的架构。每个租户每个节点创建一个名称空间和VETH设备然后，多个辅助IP连接到VETH设备，创建临时的每个作业IP池。覆盖层使这些IP能够通过其自己的策略和机制进行路由。然后，容器可以连接到可用的IP，并在节点内和节点间的容器之间传输数据。作业完成后，Particle将删除其命名空间和IP。图5显示了多租户设置中的VETH整合示例。 每个客户机都有自己的粒子名称-与VTEP共享的MAC同步。 单个VETH接口可以为共享Particle（根）命名空间的任何容器托管数千个辅助IP地址。 应用程序有几个不同的选择如何与这个系统接口。3.2隔离和应用接口将多个容器的VETH设备和命名空间合并到一个命名空间中的一个虚拟设备中可能会对应用程序中的容器产生副作用。单独的命名空间隔离网络资源并提供安全性隔离如果一个容器被破坏，不同命名空间中的其他容器不会受到 由于Particle合并了网络名称空间，因此它无法提供相同粒度的安全隔离。然而，由于Particle只合并同一租户/应用程序的命名空间，并且不同的租户总是由单独的命名空间隔离，因此我们认为这种折衷对于由多个无服务器实例组成的应用程序模式是可以接受的，这些实例作为同一应用程序的一部分一起工作。从概念上讲，应用程序会为不同的容器请求不同的IP地址，而Particle会分配这些IP以避免冲突。但是，如果容器中的应用程序不遵守分配，则同一应用程序的不同容器可能会通过尝试绑定到相同的IP地址/端口对而相互干扰 一种可能无意中发生这种情况的情况是，应用程序在同一主机上运行多个容器，并通过Particle共享VETH设备。如果它们尝试使用INADDR_ANY绑定到同一个端口，则可能会发生端口冲突因此，应用程序需要使用分配给它们的IP地址来避免此类冲突。Particle不依赖于应用程序来使用正确的IP地址，而是可以通过覆盖libc的bind调用（通过LD_PRELOAD机制）来确保IP地址参数与签名到容器的IP地址相匹配。如果应 用 程 序 不 使 用 动 态 链 接 的 libc ， 或 者 直 接 调 用bindsyscall，Linux Seccomp [16]提供了一种强制分配IP地址的机制Seccomp4执行Particle是用C语言实现的，并集成到Linux原生的iproute2工具Particle并不是设计用来直接使用的，而是一个存在于叠加系统中的核心模块因此，“粒子”不会对正在使用的控制平面类型做出任何假设。Particle：无服务器网络的短暂端点SoCC24Docker SwarmOverlay WeaveOverlayLinux覆盖粒子+编织粒子+Linux粒子+Linux粒子+编织Linux OverlayDocker Swarm401.0300.80.6200.4100.20100/1200/2400/4800/80.00 5 10 15 20 25 30容器/节点时间（秒）图6：多节点聚合应用程序：启动一组容器、连接到覆盖层以及协调所有对一聚合作业的总时间。Par-article没有负面影响的叠加控制平面作为更多的节点被添加。将Particle移植到现有的覆盖网络需要在控制和数据平面侧使用适配器对于数据平面，现在覆盖系统在提供单个容器时不需要创建网络命名空间。此外，它们必须为组名称空间创建一个传递到Particle的附加容器 对于使用键值存储的覆盖系统，需要控制平面适配器将IP作为一次性操作传递到数据库中。在我们的评估中，我们将Particle 在这两种情况下，这些覆盖都传入VTEP的命名空间，并且必须创建一个没有初始网络的新容器。指向此网络命名空间的指针也传递到Particle中。在这一点上，粒子具有控制平面网络命名空间（VTEP）和数据平面网络命名空间的句柄。根据有多少容器被请求，粒子初始化共享名称空间与相同数量的IP。 上下文被切换回现有的覆盖系统，该覆盖系统基于粒子MAC地址将路由切换到控制平面的其他成员。5评价我们首先评估粒子的启动性能的两个通信模式：聚合和洗牌[ 18 ]。 接下来，我们评估粒子的性能在现实世界的突发并行应用程序，链轮。最后，我们来看看Particle在多租户环境中的性能。在我们的实验中，我们使用AWS EC2C5.4xlarge实例，每个实例具有24个vCPU，32 GB内存和10 Gb/s网络带宽。所有实例都在同一个虚拟私有云中图7：多节点Shuffle应用程序：shuffle应用程序中发送的消息的CDF。两个节点上的100个发送者和接收者交换10，000条消息。覆盖使用粒子减少启动时间，使appli-阳离子代码几乎立即启动。（VPC）和放置组，以稳定网络性能。这些实例使用Linux5.0.0内核和默认配置运行Ubuntu 18.04.2 LTS我们使用iproute 2版本5.2.0、Quagga路由器版本1.0.0和Docker版本19.03.1-ce。默认情况下，我们使用最佳数量的线程并发启动容器。 我们通过尝试不同的值并选择具有最大吞吐量的值来确定最佳数量。 由于突发并行基准测试的要求很高，我们让应用程序自己确定线程数，并在96核C5.24x大型机器上运行应用程序，这些机器具有192 GB内存和25 Gb/s带宽。5.1无服务器通信模式我们通过测量完成数据聚合和洗牌作业的时间来评估Particle在应用程序级别的性能。 因为我们关注的是容器启动和网络初始化时间，而不是数据传输速率，所以我们在数据聚合和洗牌作业中发送简短的合成消息。因此，它提供了数据聚合和洗牌作业完成速度的上限。 在测试完成时，所有容器都已启动，所有通信路径都已建立。此实验在多个节点上执行，并针对运行相同作业的现有系统评估Particle。我们使用Linux Overlay与EVPN，Weave和Docker SwarmOverlay作为比较点。这些系统中的每一个都使用默认的覆盖配置，而不使用其他参数。时间CDFSoCC放大图片作者：Michael M.Voelker和George Porter25××图8：视频处理管道的时间轴：比较运行Sprocket视频处理管道的Docker Swarm、Linux Overlay和Particle纵轴上的点表示单个视频块的处理步骤（解码、过滤和编码），按完成时间排序���Particle消除了容器启动的瓶颈，运行速度分别比Docker Swarm和Linux Overlay快3倍和2.4倍聚合来 聚合基准测试了一种全对一的通信模式，在这种模式下，许多容器向一个接收方容器发送一条短TCP消息。创建后，发送容器尝试建立到数据Data接收容器直到成功。图6显示了粒子颗粒17.77% 10.92% 71.31%与现有系统相比 我们跑100每个EC2主机上的容器，我们将主机的数量从1到16变化，因此容器的总数从100到1600。在多个节点上，Particle 在这段时间内，在每个节点上启动100个Docker容器需要5 -6秒，启动Particle需要500毫秒。其余的时间用于建立TCP连接到接收方，并等待接收方发回时间戳消息。一旦包括启动Docker容器的开销，微基准测试的17改进将减少到2虽然大多数系统的性能在增加节点数量时保持不变，但Docker Swarm Overlay在使用超过四个节点时会超线性地增加。Docker Overlay是一个功能丰富的控制平面实现，使用RAFT [26]维护全局集群状态。在突发并行应用程序的上下文中，这些功能中的许多功能（如负载平衡和冗余）在每个容器的上下文中不太有用。相反，它们需要在每个容器组的粒度上实现。每个容器组都在组内实现自己的冗余协议[4]，并且每个组都需要负载平衡。洗牌。Shuffle是数据分析工作负载的常见通信模式[27]。在这个实验中，我们同时启动了相同数量的shuffle发送器和接收器容器发射后，立即保持表5：视频管道细分：三个网络中不同操作所花费的总运行时间的百分比.我们取三次运行的平均值。
我的内容管理
展开
