查看精彩回放 https://developer.aliyun.com/live/246639
讲师
讲解 李慧霸 鲁七
演示 刘兰峥 南针
?
内容简要
一、DADI项目简介
二、容器 image 问题分析
三、DADI方案阐述
四、开源版本现状与未来计划
五、视频演示
?
?
一、DADI项目简介
DADI是Data Accelerator for Disaggregated Infrastructure的首字母缩写。这个项目关注的是存储和应用之间的加速层。
我们知道做云计算的都可以看作是Data Center as a Computer 传统的Computer是有Cache的,在 CPU和内存之间以及内存和磁盘之间都有Cache Cache在性能方面扮演了举足轻重的角色。
到了云计算场景 我们认为也还是需要Cache 所以DADI就是做应用和存储系统之间的加速层。但是在分布式环境 云计算场景下加速技术并不只有Cache 可能会有更多可能性 比如说像p2p传输等。
本次介绍的是 DADI 在容器快速部署场景的应用。
?
?
二、容器 image 问题分析
DADI image加速技术已经支持阿里所有自营业务的秒级扩容 是大促必备的产品 并且已经集成进入了公共云多项容器服务以及容器衍生品服务中。
同时我们还在顶级的学术会议USENIX ATC’20发表了文章 有兴趣的朋友们可以通过右上方的二维码进入论文的主页
https://www.usenix.org/conference/atc20/presentation/ li-huiba。
?
Background: Layered Image of Container
容器image都是需要先从registry下载并且解压解包 放到本地硬盘上之后才能使用。容器的image由多个层次组成 每一层包含相对于之前状态的变更集 也就是增加删除或者修改的文件 这些层合并起来成为一个image image是只读共享的 每个容器自身还包含一个可写的容器层 这个容器层也包含的是增加或者删除或者修改的文件 这些容器层之间都是私有的 互相不共享 所有的层次通常使用overlayfs进行合并 供容器内部使用。
?
Similar to Map Layers
这些容器的层其实和地图的图层或photoshop图层都非常相似。
?
?
The Problem
1.? 问题在于容器的部署或冷启动非常缓慢 我们需要事先下载和解压image 过程通常可以达到几十秒钟甚至几十分钟。
有研究指出 日志里只有平均6.4%的数据是真正使用到的 其余90%多的数据都是垃圾。这样一个模式其实让我们回退到了至少10年以前 那个时候虚拟机的镜像也是需要下载到各个宿主机然后再使用。
2.? 业内有很多解决这个问题的方法 比如说通过p2p的下载方式来加速下载过程 但这样是不够的。它只是解决了在大规模情况下的下载速度问题。
对于小规模情况 或者说对于容器 image的解压缩都是没有帮助的
3.也有一些工作试图精简image 但是精简工作其实并不能很通用 也并不能很自动 有不少的应用有动态的加载文件的需求 同时精简过的image也很难支持用户的一些临时性的操作需求。
?
Remote Image
当前image加速技术的主流方向是Remote Image image放在远程 可能在registry上或者别的什么地方 并不需要把它完整下载下来就可以直接开始使用。社区已经有一些方面的工作 比如说CRFS, Teleport, CernVM-FS等。对于大规模集群还需要配合p2p数据传输技术才能解决全部的问题。
然而如今image采用了tarball格式 这个格式不支持 remote image 因为它的设计是针对完整解压缩 不支持我们随机的seek到一个位置读取那个位置的数据 同时tarball格式很难支持高级功能 比如说扩展属性 跨层的数据引用等 所以最好还是重新设计一个新的文件格式。
?
Type of Image: Block!
摆在我们面前有两种选择 一个是基于文件系统的image 就像现代容器image 同时还有一种选择是用块设备作为image 就像虚拟机的image一直以来的样子。我们对这两种方式做了比较详细的比较 比较集中在三个方面 一个是复杂度 再一个是通用性 最后是安全性。
我们认为在这三个方面 基于块设备的image都有非常显著的优势 这个优势最根本上是源于块设备的image它比较简单但并不简陋。我们唯一需要做的是让块设备支持分层的特性 相比之下基于文件系统的image 在这些技术方面没有太多显著的优势 可能还会有一些不足。比如说性能会偏低 高级特性会比较缺失等。
?
三、DADI方案阐述
DADI Remote Image
基于这样的分析 我们义无反顾选择了基于块设备的image格式 第一个contribution是设计了基于块设备的分层镜像格式 我们把它称之为Overlay Block Device。它需要配合常规文件系统比如ext4一起使用给用户提供文件访问服务。
第二个contribution是设计了可支持随机访问的压缩文件格式叫ZFile 因为容器镜像普遍是压缩存储 我们不能在这方面留下短板。第三个contribution是我们设计了基于p2p的按需传输技术 以应对大规模和超大规模集群的需求。
?
DADI I/O Path
单机内的I/O路径如下 首先应用在容器中 读取文件的请求会传递到位于内核的常规文件系统当中 比如ext4 文件系统会把读请求转发给一个虚拟块设备 这个虚拟块设备使用的是TCMU框架实现 内核的虚拟块设备会把请求转发给用户态的服务进程OverlayBD。
OverlayBD会通过查询内存中的索引 把读请求分解为对具体layer的读取 如果被读取的layer已经下载到本地 那么就直接在本地文件系统上来读取layer。如果layer是新发布的 还没有下载到本地 那么就通过 rpc到远程去访问。
?
Overlay Block Device
在DADI image 格式当中 每一个layer就是一个被修改的数据块的集合 在这个层面上没有文件或者文件系统的概念 我们每个修改的粒度最小是512字节 和我们常规的块设备是一致的。同时OverlayBD会维护一个内存索引来实现快速的读取 索引具有变长和区间查询的特性 非常高效 它的原理可以用下图来表示。
在加载image的时候 我们可以一次性的把 image里所有layer的索引进行合并 合并后一次查询就能处理任意数量的layer 使得overlayBD的性能不随layer的增加而下降 只跟合并过后的索引记录数量有关。
?
Index Merge
我们统计了生产环境当中大量image的索引合并过后的元素数量 结果如下图所示 元素数量最多不超过4.5k, 换算到内存占用不超过100k 我们也测试了单核CPU下能够提供的处理能力 结果如图所示 每秒几百万次的QPS还是非常充足的。
ZFile
ZFile是支持随机读取的压缩文件格式 它的原理也很简单 把文件按照固定的数据块大小一块一块地进行压缩 每次读取的时候只解压缩需要的数据块 不需要的数据块不解压缩。同时ZFile格式并不是仅局限于DADI 它是非常通用的支持随机访问的文件格式。
?
?
Performance
Wordpress Startup with DADI
最后我们来看一下性能 我们最关注的是冷启动耗时 所以我们最先来测试这一项指标 我们选取了GitHub上的Wordpress镜像 Wordpress是一个非常流行的CMS系统 它号称支撑了整个外部世界1/3的网站 所以选用Wordpress具有一定代表性。
结果当中的第一列是普通格式的Wordpress镜像 我们测试环境当中的Image Pull和App Launch两个步骤的耗时 总计有10多秒钟。
第二列测试的是CRFS的相对早期的版本 它的耗时竟然比下载解压方式更慢一些。
第三列是模仿学术界的Slacker工作 就是把image解压缩之后放到NFS服务器上 然后从NFS服务器启动容器 它的耗时显著比下载解压的模式要更快一些 只有不到4秒钟时间。
最后两列是DADI方案的两种情况 一个是从Registry的下载数据 另一个是从共享的存储服务器下载数据 可以看出 DADI的效果要比其他方案好很多。
性能测试 我们分别用du和tar来对image进行扫描, du读取所有文件的元信息 而tar是读取所有文件的数据 他们分别侧重随机小块读和顺序大块读的两种不同的workload。
从I/O性能测试结果来看 DADI也具有显着的优势 特别是在使用云盘的场景下 因为DADI采用的压缩格式突破了云盘的带宽限制 所以取得了更好的效果。
?
四、开源版本现状与未来计划
Open Soure Edition
最后再介绍一下开源版本的状况 整个项目在GitHub上分成了两个repo 其中一个主要跟容器世界打交道实现了snapshotter 另一个就是overlaybd,这两项工作均可以通过右方的链接或者二维码进行访问。
目前开源的工作当中也包含了镜像格式转换工具 可以把已有的tgz格式转换成DADI格式 我们目前正在做并且近期还会开源的工作包括这么几项
1.bulidkit
2.基于trace的数据预取 可以进一步提高冷启动速度 尤其是高延迟、高带宽的场景中。
3.支持ext4之外的文件系统 有些linux发行版已经默认使用xfs 提供更多高级功能 性能也更好 支持多种文件系统有利于提高overlaybd的竞争力。
4.overlaybd 内核模块 image下载到本地后可以通过内核模块启动 这样I/O路径就不用经过用户态再次转发。
5. 可供应用使用的可写层。可以摆脱overlayfs的依赖 可以提高性能。
?
?
五、视频演示
演示从DADI Overlaybd格式远程镜像来启动容器的过程。
首先需要完整安装Overlaybd的运行环境。
Overlaybd有两个必须的依赖 一个是target_core_user 这是tcmu的内核模块。第二个依赖是containerd 而且必须是1.4以上的版本。Containerd在1.4版本后支持远程镜像拉取 在Image pull的时候 可以不下载全部镜像数据而只是注册镜像 早期的Containerd并没有这个特性。
Overlaybd有两个组件事先必须将它们运行起来 分别是overlaybd-snapshotter和overlaybd-tcmu组件。
首先启动Overlaybd snapshotter 可以直接作为二进制程序运行。
需要说明的是如果是首次使用 必须要修改Containerd的配置 把Overlaybd snapshotter作为一个plugin添加进去。
然后启动Overlaybd-tcmu组件 这是Overlaybd的Backing Store 也可以作为二进制来运行。启动之后 它后续日志将存放在var/log路径下 需要说明的是我们建议通过服务来管理这两个组件 这样即使出现意外也可以重新拉起 Overlaybd本身也支持故障恢复。
下面看一下本次测试的配置文件。
上方是Overlaybd-tcmu的配置文件 首先配置一个4GB大小的本地缓存 路径为opt/overlaybd/register_catch 远程镜像数据加载后会存放到本地缓存 这样再次请求相同数据时 可以直接从本地缓存获取 不需要再次通过网络拉取 测试前我们已经清空了本地缓存。
credentialFilePath是鉴权信息的存放路径 Overlaybd的鉴权文件需要单独配置。虽然在拉取镜像还在Containerd时已经传入了用户名密码 但是远程拉取的是另一条鉴权路径 跟Containerd是分开的。如果你的镜像是私有的 需要事先配置好鉴权文件。
download是后台下载的配置 我们这次测试将这个功能关闭 如果开启了这个功能 那么在镜像启动后 会在后台自动将镜像数据完整下载到本地。下载完成后 该镜像变成一个纯本地镜像 再次启动时 即使断网也不会受任何影响。
本次测试环境使用的是ACR企业版-ACREE 宿主机使用的是一台ECS 部署在杭州机房 它们之间的网络是公网。
本次测试使用的镜像是wordpress镜像 我们事先将一个已经转换为Overlaybd格式的wordpress存放到Registry中。
如上图所示 我们看一下测试的脚本。
测试脚本首先执行一个rpull指令拉取镜像。Ctr是Containerd的一个调试工具 它很多功能其实是没有的 例如Containerd支持远程镜像拉取所需要的这些标签 Ctr本身是没有的 所以我们在Ctr中扩展了一个新的指令rpull 它可以帮助我们将所需要的标签传进去。
对于普通镜像而言 rpull就是镜像的下载和解压。对OverlayBD镜像 rpull相当于注册一个镜像 并不会实际去下载镜像。然后我们启动一个容器 这里必须指明snapshotter使用的是Overlaybd snapshotter。它兼容Overlayfs 对于普通镜像而言 相当于通过Overlayfs启动 对于Overlaybd格式的镜像则进入远程拉取的逻辑。
下面看一下如何计时。
首先我们看80端口是否就绪 就绪以后检查wordpress的文件是否可以访问 如果访问得到 我们认为服务就绪 停止计时。
我们本次分为三个测试 第一个是普通镜像的冷启动测试 第二个是Overlaybd镜像的冷启动测试 第三个是Overlaybd的热启动测试 分别来看一下三个测试的启动时间。
?
1.普通的冷启动测试
镜像下载之后进行解压 我们看到总共的时间接近27秒。然后我们执行一下清理脚本 主要是清空刚才创建的容器和下载的镜像 并且清除Overlaybd。
?
2.OverlayBD镜像的冷启动测试
拉取耗时0.6秒 接着加载远程数据 总共用时13秒 速度提升了一倍。下面仍然进行清理 清理的也是镜像和刚才创建的容器以及系统缓存。但这里并没有清理Overlaybd的Cache 所以再次启动时 需要远程加载的数据将命中本地缓存。
3.OverlayBD的热启动测试
启动时间是2.3秒 接近于热启动本地普通镜像。
1．世界上最悲哀的事莫过于睡眠不足，尤其是在感冒的时候。 2．我是一个很有原则...
1．男女之间是真的可以有纯友谊的，只要一个打死不说一个装傻到底。 2．不要迷恋...
年味到底是什么?不同的时代，人们迎接春节的方式也在变换。 在70后的眼里，年味...
我们将创建以下三个Shell脚本来锁定和解锁多个帐户和查看账号状态。 创建锁定用...
1．我手机掉进厕所了怎么办？是屎在给我发信息吗？ 2．生活就像新闻联播，不是换...
作者 许力 阿里云原生多模数据库Lindorm与东软云科技推出联合解决方案 共建面向...
Knative 是基于 Kubernetes 的开源 Serverless 应用编排框架。阿里云 Knative 在...
?又到一年毕业季，即将开启（实习及正式）职场生涯的同学们会有不少疑惑。比如，...
新冠肺炎疫情的全球大流行不仅深刻影响了世界政治经济格局的发展演进，而且加速...
数据目录已成为企业数据管理策略的重要组成部分，但选择合适的数据目录并不是简...
