CN115277419B - 一种无服务计算中加速网络启动方法 - Google Patents
一种无服务计算中加速网络启动方法 Download PDFInfo
- Publication number
- CN115277419B CN115277419B CN202210947340.XA CN202210947340A CN115277419B CN 115277419 B CN115277419 B CN 115277419B CN 202210947340 A CN202210947340 A CN 202210947340A CN 115277419 B CN115277419 B CN 115277419B
- Authority
- CN
- China
- Prior art keywords
- network
- partfast
- veth
- container
- containers
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 35
- 238000004364 calculation method Methods 0.000 title claims abstract description 9
- 230000001133 acceleration Effects 0.000 title description 2
- 238000012545 processing Methods 0.000 claims description 14
- 238000004891 communication Methods 0.000 claims description 12
- 230000000977 initiatory effect Effects 0.000 claims description 10
- 238000003780 insertion Methods 0.000 claims description 2
- 230000037431 insertion Effects 0.000 claims description 2
- 230000006870 function Effects 0.000 description 16
- 238000002955 isolation Methods 0.000 description 9
- 230000008569 process Effects 0.000 description 8
- 238000002474 experimental method Methods 0.000 description 7
- 239000002245 particle Substances 0.000 description 7
- 238000012360 testing method Methods 0.000 description 6
- 230000002776 aggregation Effects 0.000 description 5
- 238000004220 aggregation Methods 0.000 description 5
- 239000003638 chemical reducing agent Substances 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 230000006855 networking Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000004080 punching Methods 0.000 description 3
- 238000005538 encapsulation Methods 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 241000029811 Equus burchellii quagga Species 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012432 intermediate storage Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- -1 overlay Network Substances 0.000 description 1
- 239000000843 powder Substances 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一种无服务计算中加速网络启动方法及系统，包括以下步骤：1）整合网络命名空间，针对一组容器创建一个PartFast网络命名空间；2）VTEP网络命名空间中创建一对VETH设备，其中一个VETH设备放入PartFast网路命名空间、另一个本地的VETH设备和VTEP的VXLAN以及网桥接口拴住，然后启动本地VETH和客户VETH接口；3）针对PartFast网络命名空间，设置IP和MAC；4）在本地VETH和客户VETH接口之间建立一个连接；本发明通过在VTEP netns中创建一对VETH设备，减少了一次虚拟网卡移动次数。此外，本发明引入了提前创建网络以及暂停容器池的管理，减少了容器重复创建的开销。
Description
技术领域
本发明涉及一种无服务计算中加速网络启动方法。
背景技术
在云计算的场景中，无服务计算提供了高级的计算抽象。从用户的角度来看，它简化了应用的开发，因为提供商管理了大部分资源包括网络，系统，运行坏境以及库。这使得用户只要把精力集中于应用程序的代码上。尽管提供商初始化设计无服务平台是为了支持web和API服务，用户可以在在几秒内启动几千个并行函数，这巨大增加了云计算资源的弹性；但是一些新增长的短期函数的出现导致了突增并行工作的出现。突增并行的工作被描述带有高扇出的并行任务，而这包含了几千个无服务函数，全都部署在单个用户。Fouladi等人所做的工作就是使用几千个轻量级的线程对视频进行处理。这份研究展示了如何应用几千个轻量级线程到视频编码，减少编码时间比如将一个工业编码器从149分钟减少到2.6分钟。Ao等人所做的工作Sprocket，他们的研究应用了类似的模型去开发基于云的突增并行的系统，针对端到端的视频处理流水线，而这个在视频处理的工作在性能上是Spark的4倍。相比于传统的无服务使用案例，包含几千个并发函数的单个任务拥有独立的框架要求，目前的无服务平台并不能有效支持这个要求。
启用overlays的技术就是VXLAN协议。VXLAN是一个封装协议，而这个协议从一个容器组中包装包并带有唯一的标识符（VNIs），而这个标识符在没有隔离的情况下允许通信。以这种方式连接的设备会构成一个overlay网络。一个overlay网络包含两个有区别的部分，控制平面和数据平面。控制平面就是一个网络中的服务，它会跨过多个用户来管理overlay网络。这些连接会在每个主机中数据平面所初试化。并不像控制平面，数据平面的存在仅仅只有无服务应用。它对应基于VNI, IP, 和MAC地址，转发数据到相应的容器。
VXLAN的数据平面要求每台主机都拥有VXLAN Tunnel Endpoint (VTEP)， VTEP对应的VXLAN的终端和封装。当使用VXLAN将一个包从一个容器发送到另一个容器，在主机上的VTEP封装来自容器发来的原始以太网帧，在现有的基础上增加VXLAN头部。反过来封装的包从主机发出去带有外部的IP和MAC头；当另一个容器接收到包的时候，在接收端VTEP会查看VNI以及内部的MAC地址，并且传递payload给合适的容器。
overlay网络也要求一个控制平面去管理VTEP路由信息。控制平面保持了主机VTEPs, VNIs, 和容器MAC地址的映射。当在一台主机上的一个容器发送数据给另一台主机的容器，VTEP封装包带有VNI，并且局部检查是否有这个路由信息存在。如果不存在的话，控制平面就会被查询，并且然后这个包使用新的路由来路由。控制平面的实现是多种多样的，带着一些虚拟路由器，gossip协议，BGP，以及KV stores。
然而，针对突增并行的应用，网络层的无服务平台是特别低效的。这些应用使用几百个并发的无服务函数去完成复杂的任务，以及在无服务平台上原生的点对点的网络功能也必须协调通过中间存储。当无服务函数在处理到来的一个请求的时候，它所花的时间一般由三部分组成：容器启动，网络启动，应用程序运行。然而网络启动在整个过程却占了80%左右的时间。因此对于网络启动的处理是提高Serverless平台服务质量的一个关键因素，缩减网络启动时间可以有效地提高函数调用速度和性能。
发明内容
本发明要解决的技术问题是克服现有技术的不足，提供一种无服务计算中加速网络启动方法，从而减少网络启动时间。
为解决上述技术问题，本发明提出的技术方案为：
一种无服务计算中加速网络启动方法，其特征在于：包括以下步骤：
1）整合网络命名空间，针对一组容器创建一个PartFast网络命名空间，PartFast网络命名空间的创建是针对每个用户所创建的网络命名空间；
2）VTEP网络命名空间中创建一对VETH设备，其中一个VETH设备放入PartFast网路命名空间、另一个本地的VETH设备和VTEP的VXLAN以及网桥接口拴住，然后启动本地VETH和客户VETH接口；
3）针对PartFast网络命名空间，设置IP和MAC，针对同一个用户的后续请求，直接在PartFast网络命名空间中的VETH设备绑定一个新的IP；
4）在本地VETH和客户VETH接口之间建立一个连接，来进行相应的数据通信。
上述的无服务计算中加速网络启动方法，优选的，所述步骤3）中的设置IP包括以下步骤：
A）根据用户的请求接收量，基于具体的IP范围和容器的数量去创建IP池；其中MAC地址分配通过随机函数的方式，并且一个MAC可以对应多个IP地址；
B）IP池中IP的数量大于用户的请求接收量，将IP池中的IP附属到对应用户的VETH设备上；其中一个IP就对应一个容器。
上述的无服务计算中加速网络启动方法，优选的，在PartFast网络命名空间中，创建的VETH设备可以绑定多个IP。
上述的无服务计算中加速网络启动方法，优选的，所述相同用户之间的容器是没有隔离的，但是不同用户容器之间是相互隔离的。
上述的无服务计算中加速网络启动方法，优选的，用户的请求使用PartFast分配的IP地址；PartFast插入通过重写libc的绑定调用确保IP地址参数匹配分配给容器的IP地址。
上述的无服务计算中加速网络启动方法，优选的，所述PartFast分配IP的容器能够相互通信，访问三方或者主机网络的服务。
上述的无服务计算中加速网络启动方法，优选的，所述VTEP 网络命名空间中的VETH设备移动到共享的PartFast网络命名空间中。
上述的无服务计算中加速网络启动方法，优选的，所述容器的创建包括以下步骤：
a)构建暂停容器池，在网络创建之后，带着初始化容器相关操作，一个暂停容器被创建，并且放入到池中；在暂停容器池中有多个暂停容器；
b)针对用户的应用请求调取暂停容器池中的暂停容器；
c）用户的应用完成相应的请求处理后，调取的暂停容器初始化后，返回暂停容器池。
与现有技术相比，本发明的优点在于：本发明通过在VTEP 中创建一对VETH设备,减少了一次虚拟网卡移动次数。虚拟网卡在不同的网络命名空间中移动是比较耗时的。此外，为了减少容器重复创建的开销。本发明引入了提前创建网络以及暂停容器池的管理。因此，本发明在一定程度上降低网络启动延迟。
附图说明
图1是本发明同一个用户第一个请求创建容器的过程。
图2是本发明当同时有大量请求来到本系统的处理流程。
图3是本发明当有多个用户同时发起大量请求的原理图。
图4是本发明中不同无服务网络选项中功能和问题的比较。
图5是本发明多节点的聚合应用程序性能对比图，其中所花时间包括启动一组容器，连接到overlay网络，以及协调多对一的聚合任务。
图6容器一般的生命周期。
图7拥有暂停容器下的容器生命周期---旁路耗时的网络创建。
图8暂停容器池管理者的不同阶段。
实施方式
为了便于理解本发明，下文将结合较佳的实施例对本发明作更全面、细致地描述，但本发明的保护范围并不限于以下具体的实施例。
除非另有定义，下文中所使用的所有专业术语与本领域技术人员通常理解的含义相同。本文中所使用的专业术语只是为了描述具体实施例的目的，并不是旨在限制本发明的保护范围。
本发明提供一种无服务计算中加速网络启动方法，包括以下步骤：
1）整合命名空间，针对一组容器创建一个新的PartFast网络命名空间，PartFast网络命名空间的创建是针对每个用户的；
2）VTEP网络命名空间中创建一对VETH设备，其中一个VETH设备放入PartFast网路命名空间、另一个本地的VETH设备和VTEP的VXLAN以及网桥接口拴住；
在本发明中，如果主机的命名空间可以被使用，就不需要额外共享的PartFast网络命名空间了；那么在VTEP网络命名空间中创建一对VETH设备，其中一个VETH设备放入客户（PartFast）网路命名空间、另一个本地的VETH设备和VTEP的VXLAN以及网桥接口拴住；
3）针对用户（PartFast）网络命名空间，设置IP和MAC，针对同一个用户的后续请求，直接在客户（PartFast）网络命名空间中的VETH设备绑定一个新的IP；在客户（PartFast）命名空间中，创建的VETH设备添加多个IP到这个VETH接口上。
步骤3）中的设置IP包括以下步骤：
A )根据用户的请求接收量，基于具体的IP范围和容器的数量去创建IP池；其中MAC地址分配通过随机函数的方式，并且一个MAC可以对应多个IP地址；
B) IP池中IP的数量大于用户的请求接收量，将IP池中的IP附属到对应用户的VETH设备上；其中一个IP就对应一个容器；
4）在本地VETH和客户VETH接口之间建立一个连接，来进行相应的数据通信；
构建overlay网络实现各个用户容器之间的通信，即将多个用户容器的虚拟IP地址和宿主机网络地址隔离开，构建用户数据平面和控制平面实现网络资源的隔离。在本发明中，容器之间设置有隔离，其中同个用户的容器之间是没有隔离的，不同用户的容器之间是有隔离的。
此外，为了减少容器重复创建的开销。本发明引入了Network Pre-creation（提前创建网络）和Pool Management（池的管理）。它包括提前创建网络，以至于时间花在网络创建从启动的关键路径上移除。我们也开发了池的管理者针对暂停的容器，并且管理它的生命周期。
提前创建网络
在网络创建之后，带着初始化停止，一个暂停容器被提前创建。我们解法操作了一池的管理系统---暂停容器池管理者（pause container pool manager，简称PCPM）。PCPM创建了暂停容器（pause container，简称PC）并且把它们放入池中。当这些容器准备结束时，PCs被分离，并且放回池中。图6描述了容器一般的生命周期。现在，这个耗时的网络创建被简单的步骤替换，即池中取出暂停容器。当暂停容器结束后，暂停容器被简单的分离和初始化，并且被放回暂停容器池重复使用。如图7所示，图7拥有暂停容器下的容器生命周期---旁路耗时的网络创建。暂停容器是可以被任意的应用容器所使用。因此，一个暂停容器可以被Python函数使用一次，并且随后也可以被Node.js的函数再次使用。此外，除了网络ID，暂停容器是无状态的，它每个都需要几千字节。在之前的附加和新的一个之间，暂停容器不会成为任意信息的导管。
池的管理
正如重新计数，PCPM管理了一池的暂停容器；在三个关键的阶段，它这样做。第一阶段就是建立阶段，再次期间，框架被搭建以及初始化。图8（a）展示基于框架普通容器的搭建阶段。这个模块对应到启动容器，以及执行请求涉及到Invoker。正如显示在图8（a），在这个创建阶段，大量的暂停容器被启动。Invoker知道暂停容器是通过PCPM。
图8（b）展示了第二个阶段，称为执行阶段。在这个阶段，Invoker会查询池管理者，并且获取一个请求（比如：在图8（b）中的处理请求1）。使用这个请求，Invoker会从空闲池移除一定数量的暂停容器，这些暂停容器会被添加到相应用户的PartFast的网络命名空间。图8（c）描述的是第三个阶段，称之为完成阶段，当一个应用完成相应客户的大量的请求处理后。相应的容器的又回到池中。它是有利的保持大量的暂停容器在池中，面对用户突然传来的大量的请求，可以及时拓展。并且这是合理的，给与它们小的内存空间。
在传统的overlay网络中，将会在VETH设备和容器之间有一个一对一的映射。这个映射是有必要的，因为每个容器居住在它自己的隔离环境中。我们分发了每个容器的网络隔离，附属一对VETH到这个控制平面和数据平面。多个IP和MAC被添加到PartFast网络命名空间的VETH接口。从控制平面来看，所有附属到VXLAN接口的IP地址被路由。
实验显示，在VETH接口和IP地址之间新的一对多的映射改善了时间性能一个数量级，因为在满足突增并行的任务中，只有一次命名空间的跨越。同时，在本发明中整合VETH也改善了时间性能，当创建100个容器的时间比之前缩短了了17倍，创建1000个容器的时间比之前缩短了213倍。
在本发明中，启动100网络命名空间的绝对时间是534ms；其中534ms来自于两部分，创建一个根网络命名空间以及添加到overlay网络。根的网络命名空间的启动作为一个Docker容器，仅仅只带有回环接口（—net=none），这个花了平均300ms。剩余的234ms是用来创建VETH接口的时间，将它添加到控制平面的网络命名空间中，并且添加IP地址。
在本发明中，系统性的将PartFast的每个耗时的O(N) 每个容器的调用替换成O(1) 每个任务的调用。容器网络的创建涉及到几个内核锁，而这可以有效的序列化网络的创建。当尝试创建几百个无服务实例以及针对协调单个任务的相应的网络端点时，这个时候时间会大大的加长。
PartFast被整合到存在的overlay网络中，带有尽可能小的改变。正如之前所描述的，overlay网络包括控制平面和数据平面。伴随着设计当控制平面发生改变，它们所有都依赖于相似的数据平面实现，正如显示在图1。
突增并行的应用拥有这个属性，逻辑计算单元就是批量的无服务计算实例，它们的工作朝向单个目标。作为一个结果，当每个容器受利于标准的隔离保证时（进程，文件系统等等），在实例间网络接口并不要求严格的隔离。PartFast一直驱使在主机和其他用户间严格的网络隔离。
在本发明中，图2描述了PartFast的架构。每个结点每个用户单个命名空间和VETH设备被创建。多个二类IP被附加到VETH设备，创建了临时的每个任务IP池。overlay驱使这些IP被路由通过它自己的策略和机制。容器可以添加到可访问的IP，并且在结点内部或者结点间的容器之间传输数据。当任务完成，PartFast会移除它的命名空间和IP池。
图3展示的是整合VETH例子在多用户中的情况。每个客户都有它自己的PartFast的命名空间并且带有一个MAC，MAC和VTEP是共享的。单个VETH接口可以拥有几千个二类IP地址，然而对应的这些容器共享PartFast命名空间。针对如何连接这个系统，应用拥有几个不同的选项。
隔离和应用接口
针对在一个应用中的容器，整合多个容器的VETH设备和命名空间到一个命名空间中的一个虚拟设备可能有副作用。分离的命名空间隔离网络资源并且提供安全的隔离。如果一个容器被影响，在不同命名空间中的其他容器是不受影响的。因为PartFast整合了网络命名空间，它不能提供相同的安全隔离粒度。然而，因为PartFast仅仅只整合相同用户/应用的网络命名空间，并且不同的用户被网络命名空间分离，我们认为这个权衡是可接受的针对应用模式，而这个模式包含多个无服务计算（ServerLess）实例工作在一起作为相同应用的部分。
从概念上讲，针对不同的容器应用请求不同的IP地址，并且PartFast分配这些IP是为了避开冲突。然而，如果在容器中的应用不遵循这个分配，针对相同应用的不同容器可能会相互影响，通过尝试绑定相同的IP地址/端口对。这个可能无意中发生的场景是当一个应用运行多个容器在相同的主机并且通过PartFast共享一个VETH设备。如果它们尝试用INADDR_ANY绑定到相同端口，一个端口冲突可能会发生。因此，应用需要使用这些分配了的IP地址给它们去避开这种冲突。并不是依赖应用去使用正确的IP地址，PartFast可以插入通过重写libc的绑定调用（通过一个LD_PRELOAD的机制）去确保IP地址参数匹配分配给容器的IP地址。如果应用不使用这种动态链接的libc，或者直接调用这种绑定的系统调用，Linux Seccomp就会提供一种去迫使IP地址的分配。Seccomp的过滤模式允许具体化参数针对某个系统调用是可接受的，在这个案例中，分配的IP作为参数被绑定。
在本发明中无服务计算中加速网络启动方法，本发明中提供了PartFast，它优化了在突增并行的无服务环境中的网络启动。在一个常量的启动时间中，PartFast提供了临时的动态生成的IP池。并不是使用内存密集型的缓存技术，PartFast创建一组网络端点是首先通过从其他的用户命名空间分离出网络创建，然后优化网络端点的创建通过减少序列化的端点，批量调用，并且当维持每个函数IP时绑定VETH设备。在这种方式中，PartFast可以加速网络命名空间的创建，并不会影响应用程序的功能和普遍性。PartFast解决这些挑战是通过三个设计原则：
将框架匹配到应用程序中：突增并行的应用程序调用几百到几千个无服务实例去完成单个复杂的任务。因为每个无服务任务被认为是无状态的独立函数，相应的框架不能被优化是由于应用程序突增的本质。PartFast部署技术去加强网络框架，并不用妥协普遍性，可编程性，或者网络的多功能性。
普遍Socket接口：在本发明中拥有由PartFast分配IP的容器必须能够相互通信，并不需要具体的IPC协议，系统或者存储。访问三方或者主机网络的服务也必须是可能的。容器必须能使用POSIX socket调用去和其他容器通信。
可移植性：PartFast制作了部署系统的最小假设。将PartFast移植到额外的overlay系统是直接的，因为针对网络的提供大部分overlay都依赖默认的Docker运行环境。当整合的时候，PartFast对吞吐率并没有负面影响。
然而目前的无服务网络分别具有不同的功能和问题。现有无服务网络分别有NATHole Punching，Kubernetes Pods，Docker Host Networking，Overlay Network，Particle以及本发明的PartFast。然而，其中NAT Hole Punching，Kubernetes Pods，OverlayNetwork，Particle，PartFast具有隔离性。其中Docker Host Networking，Particle，PartFast具有低延迟。其中Docker Host Networking，Overlay Network，Particle，PartFast具有IP地址解析的功能。它们的连接类型分别为：NAT Hole Punching为点到点，Kubernetes Pods为端口多路复用，Docker Host Networking，Overlay Network，Particle以及PartFast是直连IP。具体内容如图4所示。
实施例
本实施例中，首先评估了PartFast的启动性能针对两种通信模式：aggregation和shuffle。接下来我们评估了PartFast的性能在真实世界的突增并行的应用上（Sprocket）。然后，我们看一看PartFast的性能在多用户的设置中如何。
在本实施例中，我们使用AWS EC2 C5.4xlarge的实例，每个都有24个虚拟CPU，32GB内存，以及10Gb/s 的网络带宽。所有的实例都在相同的虚拟私有云中，并且针对稳定的网络性能来放置组。这个实例运行Ubuntu 18.04.2 LTS使用的是Linux 5.0.0的内核带有默认配置。我们使用iproute2的版本是5.2.0，Quagga的路由版本是1.0.0，并且Docker的版本是19.03.1-ce。
默认我们并发启动容器带有最优的线程数。我们确定最优的数字是通过尝试不同值并且选择最大吞吐率的这个数字。由于突增并行benchmark需求的本质，我们让应用它们本身决定线程的数量并且运行应用在96个核的C5.24xlarge的机器上，带有192GB内存以及25Gb/s的带宽。
无服务的通信模式
我们评估PartFast的性能在应用级别通过测试它的时间去完成数据aggregation以及shuffle任务。因为我们集中在容器的启动和网络的初始化时间上而不是数据的传输速率上，我们发送短的合成的消息在数据aggregation和shuffle任务中。因此，它在针对数据aggregation和shuffle的任务可以多快被完成提供了一个上界。通过这次测试完成，所有的容器被启动，并且通信路径被建立。这个实验被表现在多个结点上，并且评估PartFast对比存在的系统运行相同的任务。我们使用Linux Overlay带有EVPN，Weave，以及DockerSwarm Overlay作为比较的点。这些系统中每一个使用了默认的overlay配置并没有额外的参数。
这个Aggregation测试了一个多对一的通信模式，在其中很多容器发送一个短的TCP消息给一个接收的容器。一旦创建，发送的容器尝试建立一个TCP连接到接收的容器直到成功。图5展示了PartFast的完成时间相比于存在的系统。我们运行100个容器在每个EC2的主机上，并且我们变化主机的数量从1到16，因此，容器的数量从100到1600。
跨过多个结点的PartFast的性能达到7秒。在时间方面，启动100个Docker容器在每个结点花5-6秒，并且启动PartFast花500ms。剩下的时间就是花在使得TCP连接到接收器，并且等待接收器发回一个时间戳信息。一旦启动Docker容器的开销被包括，来自于微基准测试的17倍改善被减少到2-3倍的改善。
当增加结点数量的时候，大部分系统的性能保持常量，然而当使用超过4个结点Docker Swarm Overlay会线性增加。Docker Overlay是一个特征富有的控制平面实现，它维持了全局集群的状态使用RAFT。在突增并行应用的上下文中，很多这些特征（比如：负载均衡和冗余）是很少有用的在每台容器的上下文中。然而，它们需要被实现在每个容器组的粒度中。在组内，每个容器组实现它自己的冗余协议，并且每个组需要被负载均衡。
Shuffle是一种普遍的通信模式针对数据分析工作。在实验中，我们同时启动相同数量的发送和接收容器。在快速启动后，发送方尝试建立TCP连接到所有的接收方。当建立后，发送方传输短的TCP消息到所有的接收方。我们使用两个结点，每个结点带有100个容器，总共发送10000条消息。
通过在实验中使用不同的overlay系统，发送shuffle消息。我们的结果显示在overlays带有PartFast（PartFast+Linux Overlay and PartFast+Weave）的shuffle应用优于存在的系统。（标准的Weave被省略，因为应用突增的本质引发了多个IP冲突在控制平面，这会巨大增加shuffle的时间。）使用PartFast，几乎所有的发送发和接收方都能建立TCP连接，并且交换消息在7-8秒内，然而在Docker Overlay和Linux Overlay，这个时间达到27-30秒以及20-22秒。这些结果也和在图5中的一致。在两个应用中，执行时间被网络搭建所主导。
突增并行的视频处理
我们评估PartFast的性能在真实世界的突增并行的应用上，Sprocket视频处理流水线。Sprocket是个无服务系统，它会将视频作为输入，并且首先将它解码成帧。这些帧是针对各种各样的变换，比如：对象检测，面部识别，或者灰度拓展。在这个变换完成后，帧最终被重新编码。我们导出Sprocket的运行环境在本地运行，并且改变它的通信模块去和Docker Swarm Overlay, Linux Overlay和Particle+Linux Overlay工作。
每个阶段（解码，转换，编码）被处理在不同的结点，并且在每个阶段使用100个容器。输入视频包含100个1秒的视频块，它被输入到第一波同时启动的100个容器。一旦每个视频块已经完成一个阶段，它会唤醒下行流的服务去开始一个新的容器，并且通过overlay网络拉取数据。这个进程被重复直到视频块已经通过三个阶段。实验中展示了Sprocket流水线中每个块的处理时间线。在每个流水线阶段之前，容器必须启动并且连接到overlay网络，以至于数据可以发送给下行流的机器。伴随着Docker Swarm和Linux Overlay，启动时间主导了整体的处理时间。尽管在第一阶段每个块被同时开始，但是网络会引发序列化影响，而这阻止了系统被真实突增并行。一到后面的阶段，容器按需求启动，比如：一旦块完成处理，它就会开始下一个阶段没有障碍。这个自由会引发随后的阶段花相对少的时间，因为在机器上有减少的竞争。
PartFast减少了启动的瓶颈，以至于所有的容器被启动在2秒内。因此，Sprocket流水线使用PartFast快于使用Docker Swarm 3倍，使用PartFast快于使用Linux Overlay2.4倍。在PartFast流水线的解码和过滤阶段之间的增加的数据传输时间是因为在容器启动序列化的减少增加了并发数据传输的数量。这个改变转移这个瓶颈到网络，临时性的拥塞了网络并且减慢了传输步骤；换句话说，PartFast加速了网络启动到这个点，在这里网络吞吐率变成了瓶颈。这个影响并没有表明在过滤和编码阶段之间，因为解码，过滤阶段的处理会有效的扩散数据的传输。当使用Docker Swarm和Linux Overlay，容器启动会更慢，阶段之间扩散数据传输，并且阻止系统充分利用网络。
通过三次运行，总结在每个阶段所花时间的百分比。PartFast花大部分时间在做数据处理，然而其他的overlay网络花大部分时间在启动阶段。PartFast更高比例时间在数据传输是减少整体执行时间以及以上讨论浸润网络的结果。
针对一个用户支付无服务突增并行的服务，PartFast启用一个任务的成本去反映平均被做的工作而不是框架和搭建时间。
突增并行的排序
我们评估了PartFast的性能在map-reduce的排序流水线上。Map-reduce排序拥有一个多对多shuffle通信模式，这不同于Sprocket。在相同数量的mapper和reducer容器被启动后，mapper发送不同范围的数据值给不同的reducer，这会等待直到所有的mapper去启动运行的快速排序完成。所有的mapper被调度到一个结点上，并且所有的reducer被调度另一个结点上。每个mapper处理64MB的数据，并且每个reducer处理相同的数量。我们比较了Docker Swarm, Linux Overlay以及带有变化数量mapper和reducer的PartFast的整个运行时间。
实验中展示了突增并行排序的性能在Docker Swarm Overlay, Linux Overlay和Particle+Linux上，使用50x50，以及100x100的容器通过两个结点。PartFast拥有最短时间在两个案例中。这些结果表明PartFast的更短容器网络搭建时间拥有一个直接改善应用的性能。
多用户
实验中展示了PartFast的性能，运行在多结点的多用户相比于运行在多节点的单用户。每台机器整个容器数量是相同的，并且我们会按比例改变用户以及每个用户线程的数量。比如，当一个用户使用机器时，它会使用所有的10个线程。当2个用户使用机器时，每个使用5个线程。如果有5个用户的话，每个使用2个线程。当拥有更多的用户是来自于锁的竞争，小开销以及共同定位的瓶颈是在Docker和应用。像其他的overlay，在网络创建期间PartFast会持有一把锁，为了创建PartFast的命名空间，它必须不能共享主机网络命名空间。
吞吐率
为了验证PartFast不会影响网络的数据路径，我们运行单个测试，它会创建在两台EC2的主机上200个容器的overlay。每台主机运行100个容器。我们运行iPerf3去测试在不同主机上两个随机选择容器的网络吞吐率。当比较Linux Overlay是否有PartFast，我们发现对吞吐率并没有影响。这个结果证实了我们的期望，PartFast并不会改变通常的数据路径，而数据路径对应的就是包的传输。
Claims (8)
1.一种无服务计算中加速网络启动方法，其特征在于：包括以下步骤：
1）整合网络命名空间，针对一组容器创建一个PartFast网络命名空间，PartFast网络命名空间的创建是针对每个用户所创建的网络命名空间；
2）VTEP网络命名空间中创建一对VETH设备，其中一个VETH设备放入PartFast网路命名空间、另一个本地的VETH设备和VTEP的VXLAN以及网桥接口拴住，然后启动本地VETH和客户VETH接口；
3）针对PartFast网络命名空间，设置IP和MAC，针对同一个用户的后续请求，直接在PartFast网络命名空间中的VETH设备绑定一个新的IP；
4）在本地VETH和客户VETH接口之间建立一个连接，来进行相应的数据通信。
2.根据权利要求1所述的无服务计算中加速网络启动方法，其特征在于：所述步骤3）中的设置IP包括以下步骤：
A)根据用户的请求接收量，基于具体的IP范围和容器的数量去创建IP池；其中MAC地址分配通过随机函数的方式，并且一个MAC可以对应多个IP地址；
B) IP池中IP的数量大于用户的请求接收量，将IP池中的IP附属到对应用户的VETH设备上；其中一个IP就对应一个容器。
3.根据权利要求1所述的无服务计算中加速网络启动方法，其特征在于：在PartFast网络命名空间中，创建的VETH设备可以绑定多个IP。
4.根据权利要求1所述的无服务计算中加速网络启动方法，其特征在于：相同用户之间的容器是没有隔离的，但是不同用户容器之间是相互隔离的。
5.根据权利要求1所述的无服务计算中加速网络启动方法，其特征在于：用户的请求使用PartFast分配的IP地址；PartFast插入通过重写libc的绑定调用确保IP地址参数匹配分配给容器的IP地址。
6.根据权利要求5所述的无服务计算中加速网络启动方法，其特征在于：所述PartFast分配IP的容器能够相互通信，访问三方或者主机网络的服务。
7.根据权利要求1所述的无服务计算中加速网络启动方法，其特征在于：所述VTEP网络命名空间中的VETH设备移动到共享的PartFast网络命名空间中。
8.根据权利要求1所述的无服务计算中加速网络启动方法，其特征在于：所述容器的创建包括以下步骤：
a)构建暂停容器池，在网络创建之后，带着初始化容器相关操作，一个暂停容器被创建，并且放入到池中；在暂停容器池中有多个暂停容器；
b)针对用户的应用请求调取暂停容器池中的暂停容器；
c)用户的应用完成相应的请求处理后，调取的暂停容器初始化后，返回暂停容器池。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210947340.XA CN115277419B (zh) | 2022-08-09 | 2022-08-09 | 一种无服务计算中加速网络启动方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210947340.XA CN115277419B (zh) | 2022-08-09 | 2022-08-09 | 一种无服务计算中加速网络启动方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115277419A CN115277419A (zh) | 2022-11-01 |
| CN115277419B true CN115277419B (zh) | 2024-01-26 |
Family
ID=83748341
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210947340.XA Active CN115277419B (zh) | 2022-08-09 | 2022-08-09 | 一种无服务计算中加速网络启动方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115277419B (zh) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106326226A (zh) * | 2015-06-16 | 2017-01-11 | 苏宁云商集团股份有限公司 | 一种公有云上启动数据库服务的方法及系统 |
| WO2017067178A1 (zh) * | 2015-10-23 | 2017-04-27 | 华为技术有限公司 | VxLAN中的路径探测方法，控制器和网络设备 |
| WO2018095138A1 (zh) * | 2016-11-25 | 2018-05-31 | 华为技术有限公司 | 容器的部署方法、服务间的通信方法及相关装置 |
| CN110837408A (zh) * | 2019-09-16 | 2020-02-25 | 中国科学院软件研究所 | 一种基于资源缓存的高性能无服务器计算方法及系统 |
| US10645020B1 (en) * | 2017-01-30 | 2020-05-05 | Amazon Technologies, Inc. | Virtual networking for compute instances |
| CN112817693A (zh) * | 2021-01-28 | 2021-05-18 | 浪潮云信息技术股份公司 | 一种用于函数计算服务的安全容器系统 |
| CN113703867A (zh) * | 2021-08-26 | 2021-11-26 | 哈尔滨工业大学 | 一种无服务计算中加速启动方法及系统 |
| CN113961307A (zh) * | 2021-10-19 | 2022-01-21 | 杭州默安科技有限公司 | 一种容器无感的攻击者ip和命令执行回显方法和系统 |
| WO2022110775A1 (zh) * | 2020-11-26 | 2022-06-02 | 华为技术有限公司 | 一种无服务容器启动方法及相关设备 |
| CN114640554A (zh) * | 2022-02-15 | 2022-06-17 | 阿里云计算有限公司 | 多租户通信隔离方法和混合组网方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10778646B2 (en) * | 2018-05-07 | 2020-09-15 | Cisco Technology, Inc. | Globally deployable context aware VPN headends in scale through namespaces |
-
2022
- 2022-08-09 CN CN202210947340.XA patent/CN115277419B/zh active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106326226A (zh) * | 2015-06-16 | 2017-01-11 | 苏宁云商集团股份有限公司 | 一种公有云上启动数据库服务的方法及系统 |
| WO2017067178A1 (zh) * | 2015-10-23 | 2017-04-27 | 华为技术有限公司 | VxLAN中的路径探测方法，控制器和网络设备 |
| WO2018095138A1 (zh) * | 2016-11-25 | 2018-05-31 | 华为技术有限公司 | 容器的部署方法、服务间的通信方法及相关装置 |
| CN108111470A (zh) * | 2016-11-25 | 2018-06-01 | 华为技术有限公司 | 容器的部署方法、服务间的通信方法及相关装置 |
| US10645020B1 (en) * | 2017-01-30 | 2020-05-05 | Amazon Technologies, Inc. | Virtual networking for compute instances |
| CN110837408A (zh) * | 2019-09-16 | 2020-02-25 | 中国科学院软件研究所 | 一种基于资源缓存的高性能无服务器计算方法及系统 |
| WO2022110775A1 (zh) * | 2020-11-26 | 2022-06-02 | 华为技术有限公司 | 一种无服务容器启动方法及相关设备 |
| CN112817693A (zh) * | 2021-01-28 | 2021-05-18 | 浪潮云信息技术股份公司 | 一种用于函数计算服务的安全容器系统 |
| CN113703867A (zh) * | 2021-08-26 | 2021-11-26 | 哈尔滨工业大学 | 一种无服务计算中加速启动方法及系统 |
| CN113961307A (zh) * | 2021-10-19 | 2022-01-21 | 杭州默安科技有限公司 | 一种容器无感的攻击者ip和命令执行回显方法和系统 |
| CN114640554A (zh) * | 2022-02-15 | 2022-06-17 | 阿里云计算有限公司 | 多租户通信隔离方法和混合组网方法 |
Non-Patent Citations (4)
| Title |
|---|
| On the performance impact of virtual link types to 5G networking;Wen-Ping Lai等;2017 Asia-Pacific Signal and information processing association annual summit and conference;全文 * |
| 一种面向多租户的Linux容器集群组网方法;朱瑜坚;马俊明;安博;曹东刚;;计算机科学(09);全文 * |
| 容器内恶意进程应用层阻断生成研究.电脑知识与技术.2021,全文. * |
| 浅谈跨主机容器间网络方案;武凌峰;杨磊;龙文君;;电脑知识与技术(15);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115277419A (zh) | 2022-11-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110892380B (zh) | 用于流处理的数据处理单元 | |
| US10866846B2 (en) | Application interaction method, apparatus, and system, and physical machine | |
| US20230239269A1 (en) | Networking as a Service | |
| WO2019195003A1 (en) | Virtual rdma switching for containerized applications | |
| CN110677277B (zh) | 数据处理方法、装置、服务器和计算机可读存储介质 | |
| CN112631788B (zh) | 数据传输方法及数据传输服务器 | |
| Katsikas et al. | Metron: High-performance NFV service chaining even in the presence of blackboxes | |
| KR100854262B1 (ko) | 인터프로세서 통신 프로토콜 | |
| WO2024164711A1 (zh) | 一种网络通信方法和装置 | |
| Perino et al. | A programmable data plane for heterogeneous NFV platforms | |
| Steinert et al. | Hardware and software components towards the integration of network-attached accelerators into data centers | |
| CN115277419B (zh) | 一种无服务计算中加速网络启动方法 | |
| Lai et al. | Ultra-low latency nfv services using dpdk | |
| US20030202522A1 (en) | System for concurrent distributed processing in multiple finite state machines | |
| CN115834660A (zh) | 一种非阻塞rdma连接建立方法及装置 | |
| CN114553980B (zh) | 一种控制流与数据流解耦的消息服务方法 | |
| Rosa et al. | INSANE: A Unified Middleware for QoS-aware Network Acceleration in Edge Cloud Computing | |
| EP4302191A1 (en) | Job target aliasing in disaggregated computing systems | |
| Bhonagiri et al. | Constraint based network communications in a virtual environment of a proprietary hardware | |
| Iordache-Sica et al. | Seamless Hardware-Accelerated Kubernetes Networking | |
| CN118041704B (zh) | Kubernetes容器访问方法、装置、计算设备及存储介质 | |
| CN115174687B (zh) | 服务调用方法、装置、电子设备及存储介质 | |
| Teivo | Evaluation of low latency communication methods in a Kubernetes cluster | |
| US20240179085A1 (en) | Methods, systems and computer readable media for emulating physical layer impairments in a cloud computing environment | |
| CN112099769B (zh) | 一种具有统一数据传输接口的软件化雷达装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |