分布式雾基础架构中的高效云应用部署

博士学位论文论文于2020年1月20日在RENNES发表并答辩研究单位：IRISA（UMR 6074）论文编号：答辩前的报告员：Paolo BELLAVISTA，博洛尼亚大学（意大利）教授Frédéric DESPREZ，Inria评审团组成：主席：Paolo BELLAVISTA，博洛尼亚大学（意大利）教授Lydia CHEN，代尔夫特理工大学（荷兰）副教授Gene Cooperman，东北大学教授（U7nis）Frédéric DESPREZ，InriaShadi IBRAHIM，InriaCédric TEDESCHI，雷恩大学讲师（HdR）1 Dir. 论文作者：GuillaumePIERRE，雷恩第一大学大学教授L’UNIVERSITE DE RENNES第601号博士学校数学与信息与通信科学与技术专业：计算机科学通过"阿里夫·艾哈迈德"分布式雾基础架构中的高效云应用部署一个知识分子我想向我的导师、教授们表达我最深切的感谢。感谢纪尧姆·皮埃尔爵士在整个研究过程中给予的大力支持、指导、监督和鼓励。他的动力、远见和动力深深地启发了我。他教会了我进行研究的方法。 尽可能清楚地呈现研究工作。在他的指导下工作是一种极大的特权和荣誉因此，我非常感谢美国东北大学的吉恩·库珀曼教授邀请我在他的监督下进行实习，并以他丰富的知识指导我。我还要感谢高级科学家Christine Morin，Inria，和研究科学家Shadi Ibrahim，Inria，接受成为我的CSID委员会成员。他们的大量评价、建议和鼓励性的评论帮助我改进和完成了研究报告。我衷心感谢论文评审团的所有成员对我的研究工作感兴趣，特别是意大利博洛尼亚大学的Paolo Bellavista教授和Inria的高级研究员Frédéric Desprez，感谢他们对论文的审查和宝贵的意见，他们帮助我改进了研究报告。我感谢我的同事和MYRIADS团队的前成员，他们总是支持我，增强我的信心。我还要感谢美国东北大学博士生Apoorve Mo- han在移居美国东北大学期间的支持，以及我在实习期间获得的技术支持。特别感谢我的妻子Firoza Choudhury，感谢她是力量的支柱，感谢她总是相信我，用爱和支持激励我，感谢我的家人和朋友，他们总是用他们无尽的爱和支持站在我身边。我的博士之旅。R总结5云计算架构由大量功能强大的服务器组成，这些服务器通过高速网络链路相互连接并连接到互联网的其余部分。通过有线网络，最终用户与最近的云数据中心之间的延迟在20 - 40毫秒范围内。在4G移动网络上最高可达150毫秒。虽然这种延迟对于许多应用程序来说是可以接受的，但它对于某些类型的应用程序（例如，延迟敏感的应用程序）来说会带来许多挑战，例如：增强现实的应用。这些应用程序需要端延迟端到端，包括处理和网络延迟，小于10-20毫秒。 此类应用的另一个示例是物联网数据分析。越来越多的物联网设备每天都在产生大量数据。收集到的数据通常会发送到云端进行进一步分析，这会消耗大量的全球互联网流量。应对这些挑战的一个可能的解决方案是在靠近最终用户的地方托管应用程序。因此，雾计算类型的基础设施通过在终端用户附近广泛分布大量节点来扩展云资源（计算、存储和网络）。因此，计算能力总是在用户附近可用。雾计算的计算体系结构由分散在诸如城市、地区甚至整个国家的地理区域中的大量计算节点组成，因此，雾资源通常被组织成大量的存在点（PoP），其中每个PoP由少量的弱机器组成一个用户-nal始终从最近的存在点访问应用程序，以保持最小的延迟。我们预计Fog应用程序将在不同的POP中重复部署：以保持应用程序之间的最小延迟。6在Fog中托管的应用程序及其最终用户可能需要注意频繁地从一个PoP移动人类的流动性绝不是随机的，尽管个人的旅行模式存在巨大差异，但它已被证明是可预测的。因此，旨在以超低延迟为单个用户提供服务的Fog应用程序（如便携式认知辅助）可以在用户经常访问的同一PoP（在家、工作等）中重复部署。在另一个示例中，诸如实时视频流分析之类的计算密集型应用可能需要在同一PoP中部署多个相同的实例，以便水平地扩展它们的处理能力。在这些情况下，应用程序部署过程不能被视为不影响最终用户体验质量的单个操作。相反，它是提供用户期望的服务的关键路径的组成部分。因此，应用程序部署缓慢是Fog基础架构中的一个难题。应用程序部署中的任何延迟都可能迫使用户等待应用程序完全部署并准备好为其用户提供服务。当用户从一个PoP切换到另一个PoP时，可能需要重新部署应用程序以保持低访问延迟并减少长距离网络流量。在这些情况下，应用程序部署中的任何延迟都可能中断正在运行的服务，从而导致性能下降。用户的体验质量（QDOE）。在这两种情况下，最短的应用程序部署时间对于向最终用户提供跨父级云服务至关重要。因此，本文旨在尽可能缩短Fog应用程序的部署时间我们研究了Docker容器在分布式Fog环境中部署缓慢的原因，并确定了三个可能的机会： 减少容器部署时间：（1）提高回收率-Docker缓存站点，减少了安装新映像的机会(2) 加快映像的安装操作;以及（3）加快创建容器后的启动过程。因此，我们提出了三种不同的解决方案来优化应用程序的整体部署时间。每个解决方案都旨在解决部署过程中的7贡献1：提高Docker缓存的成功率本论文的第一个贡献是通过减少在请求部署容器时必须安装新映像的可能性来缩短应用程序部署时间。每当Docker服务器发现本地缓存中没有所需的映像时，它们就会从远程注册表下载一个映像Docker将所有下载的图像存储在其本地缓存中，并且在明确请求之前从不删除它们。 但是，此方案不适用于Fog环境，因为Fog服务器的存储容量有限。因此，整个经常使用的映像的工作负载可能会超过服务器的总存储容量。另一个问题是，位于同一位置的节点的Docker缓存可能包含相同映像的冗余副本我们提供了一个新的Docker图像共享系统，它通过一个共享文件系统将来自共同定位的Fog服务器的缓存聚集在一起。 最终的结果是一个更大的Docker映像缓存，因此可以共享更多的映像，从而降低了部署容器时部署新映像的可能性。我们基于Docker注册表的实际跟踪对该系统进行的评估表明，共享Docker映像可以显著提高缓存命中率，从而降低缓存的成功率。容器部署时间在37%到78%之间，具体取决于方案。贡献2：改进了Docker映像的部署在位于同一位置的服务器之间共享Docker映像可提高Docker映像缓存的成功率，并降低在请求部署容器时需要安装映像的可能性。但是，当在POP中首次请求部署映像时，或者当缓存出现故障时，Docker仍然必须部署映像。Docker映像的部署可能非常慢，在资源有限的Fog节点（如Raspberry Pi纳米计算机）中可能需要几分钟。我们通过分析部署过程中Docker的资源消耗来调查部署速度慢的原因我们发现，这种缓慢在很大程度上是由于8Docker未充分利用可用的硬件资源：Docker首先同时下载然后，Docker启动一个压缩映像的循环，这是CPU密集型的。最后，图像的提取需要磁盘I/O资源。换句话说，很少或根本没有 在映像部署期间，不同硬件资源的使用之间存在重叠我们提出了三种优化方法来提高Docker-pi结合了所有这些解决方案，从而并行贡献3：避免容器的启动阶段创建容器后，Docker将通过启动应用程序的初始进程来启动启动阶段。当容器准备好接受最终用户的请求在Fog环境中，当同一容器映像在接入点的多个服务器上重复运行时，此阶段可能会产生重大影响。但是，容器的启动阶段在每次启动时都保持不变。因此，您可以在容器完成其启动阶段后保存我们提出了一个使用DMTCP部署容器的新概念，它允许从已启动容器的备份映像部署容器 该系统使用Ceph在同一PoP的多个Fog我们的评估表明，该技术提高了9容器启动阶段的持续时间最多为60倍，具体取决于容器类型。执行这一制度的额外费用11ABSTRACT云计算体系结构由大量功能强大的服务器组成，这些服务器相互连接，并通过高速网络链路连接到互联网的其余部分在有线网络上，典型终端用户和最接近的云数据中心之间的延迟在20-40毫秒范围内，在4G移动网络上高达150毫秒。虽然这种延迟对于许多应用来说是可以接受的，但它对某些类型的应用来说带来了许多挑战：例如，延迟敏感的应用，如增强现实游戏，需要端到端的延迟，包括10-20毫秒以下的网络和不断增长的物联网设备数量每天都在产生大量数据。所选数据通常会发送到核心云进行进一步分析。它消耗了大量的全球互联网流量。解决这些挑战的一个明显的解决方案是在终端用户附近托管应用程序。雾计算：通过在终端用户附近广泛分布大量计算节点来扩展云资源（计算、存储和网络）。因此，计算能力总是可用的--在用户的邪恶中是可用的。相比之下，雾计算体系结构由大量的计算节点组成，这些节点分散在诸如城市、地区甚至国家之类的地理区域中，以保持与大量用户的接近。因此，雾资源通常被组织成大量的存在点（PoP），其中每个PoP由少量的弱机器组成，如使用异构网络彼此连接并连接到因特网的其余部分的单板计算机。最终用户始终从最接近的POP访问应用程序，以保持最小的延迟。我们预计雾应用程序将在不同的POP中重复部署：为了保持雾中托管的应用程序与其最终用户之间的延迟最小，应用程序可能需要频繁地从一个POP漫游到另一个POP。人类的流动性远不是随机的，而且已经被证明是可预测的--个体旅行模式之间存在着巨大的差异。雾应用程序，如可穿戴认知辅助，喜欢服务于超低的12因此，延迟可能会在用户经常访问（家庭、工作等）的同一PoP中重复部署。在另一个示例中，诸如实时视频馈送分析之类的计算机密集型应用程序可能需要在同一PoP中部署多个相同的实例。以便横向扩展其处理能力。在这些情况下，应用程序部署过程不能被视为不影响最终用户体验质量的一次性操作。相反，它成为向其最终用户提供预期服务的关键路径的一缓慢的应用程序部署是雾状基础架构中一个具有挑战性的问题。应用程序部署中的任何延迟都可能迫使用户等待，直到应用程序已完全部署并准备好为用户提供服务。当用户从一个PoP移动到另一个PoP时，可能必须重新部署应用程序，以保持接近、低延迟并减少长距离流量。在这种情况下，应用程序部署中的任何延迟都可能中断已经运行的服务，导致用户体验质量（QDOE）下降在这两种情况下，最短的应用程序部署时间对于向最终用户提供无缝云服务至关重要因此，本文希望尽可能多地缩短雾应用程序的应用程序部署时间。我们研究了Docker容器在分布式雾基础设施中部署缓慢背后的原因，并确定了可能加快容器部署时间的三个机会：（1）提高Docker缓存的命中率，这降低了必须拉取新映像的机会;（2）加快映像拉取操作本身;以及（3）在容器启动后加快启动过程。我们提出了三种不同的解决方案来优化总体应用程序部署时间。每个解决方案都希望解决部署过程中的上述问题之一。改进Docker缓存命中率本文的第一个贡献是通过减少在容器部署请求时必须部署新映像的可能性来缩短应用程序部署时间。Docker服务器在本地缓存中发现所需映像丢失时，会从注册表下载映像。Docker将所有下载的图像存储在其本地缓存中，并且在明确请求之前不会删除它们。这在功能强大的服务器中是一个明智的策略，因为不需要相同的容器映像13在同一容器的未来部署中再次下载。但是，这种情况不适用于雾环境，因为雾服务器的存储容量有限。因此，工作映像集的增长可能会超过服务器的总存储容量。另一个问题是共定位节点的图像高速缓存可能包含相同图像的冗余副本。我们提出了一个新的Docker图像共享框架，它使用分布式文件系统聚合协同定位的雾服务器的图像缓存。最终结果是一个相当大的Docker映像缓存，可以共享更多映像，从而降低了根据容器部署请求部署新映像的可能性。我们使用真实世界的Docker注册表工作负载对所提出的框架进行的性能评估表明，共享Docker映像可以显著提高命中率，并根据具体情况将容器部署时间缩短37%至78%。贡献2：改进Docker映像部署在共址的服务器之间共享Docker映像可以提高Docker缓存命中率，并降低容器部署请求上拉取映像的可能性但是，Docker仍然需要在POP中或缓存未命中时首次请求映像时部署映像在资源受限的雾节点（如单板Raspberry Pi）中，Docker映像部署可能非常慢，仅需几分钟。我们通过分析映像部署上Docker的资源消耗来调查部署缓慢背后的原因。我们发现，这种缓慢的部署时间在很大程度上是由于Docker在部署过程中未充分利用可用的硬件资源：Docker首先同时下载不同的映像层，这是非常网络密集型的，然后是CPU密集型解压缩和磁盘密集型提取的循环。换句话说，在映像部署过程中，不同硬件资源的使用之间几乎没有重叠。我们提出了三种优化方法来提高Docker在映像部署过程中的资源利用率：（1）顺序下载映像层以优化层下载时间;（2）多线程解压缩以减少层的解压缩时间;以及（3）I/O流水线以在下载前几个字节后立即解压缩层。Docker-Pi结合了所有这些解决方案14并行使用三种硬件资源（网络、CPU和磁盘），从而将Raspberry Pis中的映像部署时间缩短25%至75%，具体取决于网络容量和映像大小贡献3：避免容器引导阶段创建容器后，Docker通过启动应用程序的启动过程来启动启动阶段。当容器准备好接受终止用户请求时，启动终止。当在POP的多个服务器中重复启动、创建和引导相同的容器映像时，此阶段可能会对雾环境产生重大影响。容器的引导阶段始终保持不变。因此，我们可以在完成启动阶段后保存容器的状态，然后在后续部署中从保存的状态重新启动容器我们提出了一种使用DMTCP进行部署的新容器部署设计 从引导检查点映像启动容器，然后跳过容器引导阶段。Ceph的设计使用分布式存储来存储容器环境和检查点映像，以便在雾服务器之间高效地共享它们。我们的评估表明，根据容器的类型，此技术可将容器启动阶段时间提高60倍拟议系统的检查点开销仍然合理。15C座桥中的T座1导言231.1捐款261.2与论文29相关的已发表论文1.3论文组织292背景312.1云计算312.1.1云计算体系结构312.1.2云计算的限制322.2解决云计算限制的332.2.1雾计算定义342.2.2雾计算体系结构352.2.3雾计算中的应用部署框架362.3码头工人382.3.1Docker体系结构392.3.2Docker图片402.4Docker容器内的应用程序部署453最先进技术493.1导言493.2加快Docker映像部署速度503.2.1服务器端接近503.2.2客户端方法523.3避免映像部署543.4加速创建容器553.5加速容器启动阶段563.6结论5716内容表4提高Docker缓存命中率594.1导言594.2缓存共享的潜在好处614.2.1模拟设置614.2.2缓存命中率分析634.3系统设计644.3.1分布式文件系统4.3.2共享Docker图片684.3.3内存元数据的一致性维护694.3.4防止竞争对手部署相同的映像704.3.5缓存替换724.4评估734.4.1微型基准734.4.2同时部署应用774.4.3宏观基准784.5结论805加速Docker映像部署835.1导言835.2了解Docker容器部署流程845.2.1实验设置845.2.2监视Docker容器部署过程865.2.3关键观察结果885.3优化容器部署流程905.3.1连续图像层下载905.3.2多线程层解压缩935.3.3I/O流水线965.3.4码头工人99号5.4第102章讨论5.4.1我们应该奉承所有的Docker图片吗？............................................1025.4.2Docker-pi是否也适用于功能强大的服务器？................................1035.5结论1046避免容器引导阶段1076.1导言107176.2最新技术水平.........................................................................................................1096.3设计问题1126.3.1DMTCP与Docker112的集成6.3.2共享容器环境1136.3.3分享检查站图片1136.4建议的容器部署设计1146.4.1DMTCP轻量级容器1156.4.2Ceph块设备1156.4.3使用检查点/重新启动的容器部署1196.5评估1216.5.1使用案例：Edge-Sharelatex1216.5.2检查点开销1226.5.3启动阶段时间1236.5.4Ceph集群内的通信1246.5.5与其他应用程序的干扰1266.6结论1277结论和未来工作1297.1结论1297.1.1贡献1：提高Docker缓存命中率1317.1.2贡献2：改进Docker映像部署1317.1.3贡献3：避免容器引导阶段1327.2未来的方向1337.2.1查找更好的缓存替换算法1337.2.2分布式文件系统中的1337.2.3预取Docker图像134参考书目134伊古雷斯的名单191.1 Docker应用程序部署262.1云计算体系结构322.2分布式雾计算体系结构352.3多个Docker容器在同一主机上运行（已调整）[91]。........................................................................................................................392.4Docker架构（改编自[93]）。...............................................................................392.5用于创建"流：1.0" Docker image 41的Dockerfile2.6"流的结构2.7Docker存储目录442.8共享相同底层的多个容器图像（改编自[87]。........................................................................................................................452.9Docker的流程图Docker拉取映像部署流程463.1 Docker容器部署优化4.1不同AZ的缓存命中率与共享缓存大小624.2Docker共享图像缓存体系结构644.3建议的码头工人拉动命令的流程图。................................................................714.4缓存未命中时的资源使用情况764.5缓存命中时的资源使用情况.................................................................................764.6同时部署容器的784.7共享与.工作负载下的非共享映像缓存4，000个容器部署4.8共享部署时间与作业下的非共享图像缓存4，000个容器部署的815.1"Mubuntu"容器的结构5.2使用Docker87标准的部署时间和资源使用情况205.3标准和顺序层拉取操作91