查看精彩回放：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秒，接近于热启动本地普通镜像。
