【论文笔记】基于容器访问模式的Docker缓存策略研究

蓝色小靴子

已于 2023-03-01 09:54:42 修改

阅读量183

点赞数

分类专栏： docker 文章标签： docker 容器运维

于 2023-02-28 21:48:44 首次发布

本文链接：https://blog.csdn.net/weixin_44380117/article/details/129255339

版权

docker 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

参考自：张晨,邓玉辉.基于镜像层关联的Docker注册表缓存预取策略[J].计算机科学与探索,2021,15(02):249-260.

研究意义

虽然 Registry 的松耦合架构解决了日益增长的请求数量和镜像数量的问题，但现有工作表明[8] ，在从此类大型公共 Registry 中拉取镜像到客户端的延迟占容器总启动时间的 76% 。因此，如何减少从远端拉取镜像的延迟开销成为目前研究加速容器启动的重点。

一、用户拉取镜像的请求流程

以 IBM Cloud Container Registry 的架构为例

用户输入 docker pull 指令，Docker Client 解析完请求后发送 HTTP 给 Docker Server，Docker Daemon 根据请求请求方法类型选择对应 Handler，该 Handler 在结合请求路由创建名为“pull”的 job，进而向注册表服务器发出方法名为 GET 的 http 请求： https://<registry URL>/v2/<username>/<repository name>/manifests/<image tag>。
若注册表服务器中存在 manifest，则将 manifest 发给 Docker Daemon，否则返回 404错误代码。
Docker Daemon 解析 manifest，并查询本地存储，得出缺失镜像层，并发出方法名为HEAD 的 http 请求：https://<registry URL>/v2/<username>/<repository name>/blobs/<digest>。
注册表服务器根据请求信息检索对象存储服务器中是否存在对应镜像层。
若该镜像层存在，则对象存储服务器返回 200 给注册表服务器。
进而注册服务器给用户返回 200。
用户通过 Docker Daemon 发出方法名为 GET 的 http 请求： https://<registry URL>/v2/<username>/<repository name>/blobs/<digest>。
注册表服务器给用户返回一个重定向 url。
通过新 url 找到存放镜像层的实际存储服务器.
镜像层被取回客户端进行校验，所有镜像层被拉取完成时合并成镜像。

其中 username 是用户名，repository name 是镜像仓库名，v2 是注册表应用程序的版本，digest 是镜像层的 256SHA 值。

二、内存去冗余的镜像缓存策略 L-Cache

1.拉取延迟计算方法分析

根据实际的docker镜像请求流程，确定如下拉取延迟公式

$T_{layer} = T_{req} + T_{net} + T_{disk}$

即一个镜像层的拉取延迟 = 非拉取镜像的网络请求传输和跳跃产生的延迟开销 + 镜像通过网络传输产生的延迟开销 + 从对象存储服务器中将镜像层从硬盘传入内存产生的延迟开销

具体计算方式如下：

$T_{req} = \alpha \sum_{k\in http}^{}S_{k} + \alpha S_{manifest}$

$T_{req}$ 是除拉取镜像请求之外其他请求在三个组件中传输和跳跃产生的延迟开销。公式包含两个部分：一般请求在网络中传输的延迟开销和镜像元文件在网络中传输的延迟开销， $\alpha$ 是广域网中下载速度的倒数， $S_{manifest}$ 是镜像元文件的数据大小， $S_{k}$ 是普通请求的数据大小， $k\in http$ 表示在完整的请求流程中除了拉取镜像层请求的其他所有请求。

$T_{net} = \alpha S_{layer}$

$T_{net}$ 是镜像层在对象存储服务器中通过网络端口传输到用户本机的延迟开销，等于单个镜像层数据大小除以广域网中下载速度。 $\alpha$ 是广域网中下载速度的倒数， $S_{layer}$ 是镜像层的数据大小。

$T_{disk} = \beta S_{layer}$
$T_{disk}$ 是对象存储服务器接收到用户拉取镜像层的请求后，将数据从硬盘读入内存所需的时间开销，等于镜像层数据大小除以服务器硬盘的读速度。 $\beta$ 是服务器硬盘的读速度的倒数， $S_{layer}$ 是镜像层的数据大小。

由上得出：

$T_{layer} = \alpha (\sum_{k\in http}^{}S_{k} + S_{manifest} + S_{layer})+\beta S_{layer}$

由于磁盘提取速度比网络传输速度快得多，所以优化网络传输阶段 $\sum_{k\in http}^{}S_{k} + S_{manifest} + S_{layer}$ 能够获得较好的延迟减少

镜像层和镜像元数据的大小无法改变，只能通过减少发送请求数量，通过分析拉取镜像的完成请求流程，我们提出将部分热点镜像缓存至注册表服务器的内存中，例如包含系统文件、依赖库、常用中间件的镜像层即为热点镜像层，当请求命中缓存时即可拉取镜像，节省了后续请求的延迟开销，尤其对于镜像层数据较小的请求流中，降低延迟的效果更加明显。同时，由于磁盘 I/O 的限制，镜像层数据从磁盘拷贝到内存需要的时间也开销不容忽视，于是我们对注册表服务器和对象存储服务器的内存镜像层数据去冗余，提高存储资源利用率，使请求尽可能命中缓存，从而隐藏了磁盘 I/O 的延迟开销。

2.观察分析镜像特点

（1）镜像层与镜像元数据的大小

大部分镜像层体积都很小，其中 1K~10K 的镜像数量最多，并且小于 1M 的约占 65%，小于 10MB 的约占 80%。虽然超过 1G 的巨型镜像层不足 5%，但拉取该类镜像的时间开销非常巨大，缓存方案不予考虑这类镜像。——尽可能缓存较小的镜像层，提高缓存的镜像数量从而减少磁盘 I/O的延迟开销，最终节省用户拉取镜像的延迟。

（2）镜像流行度

所有注册表中最流行的 layer 都占据较高的比重，这证明了在不同工作负载中总是有热点镜像，结合上一小节中得出 65%的镜像层小于 1M——将小的热点镜像层缓存在注册表服务器内存的方案具有良好的可行性。

（3）注册表服务器的资源情况

发现第 3 类服务器架构是最接近实际生产中所使用的注册表服务器。如图 3.6 所示，此类
服务器在长期处理业务时内存使用率在 31.51%~39.11%的范围内，平均内存使用率为34.28%，同时其他服务器的平均内存使用率不会超过 50%。——现在 Docker Registry 架构中，负载均衡器智能地调节不同注册表服务器上的负载数量，同时注册表服务器在运行中有较为充裕的存储资源。

3.L-cache缓存策略设计

当用户发送拉取镜像层的请求到达注册表时，L-Cache 策略会首先依据该镜像层的 digest 核查

注册表服务器内存，如果镜像层存在则请求命中，注册表服务器将镜像层返回给用户，从而避免了原生处理流程中的后续请求转发，针对体积较小的镜像层，请求转发延迟的代价越大，缓存命中的节省效果越明显。但在注册表服务器的缓存未命中时，L-Cache 策略向后端重新发出拉取请求，将所需镜像层缓存在注册表服务器内存中，并使用 LRU 进行替换操作。

内存去冗余：

注册表服务器从后端存储服务器中拉取的镜像层数据，此镜像也必定缓存在对象存储服务器内存。

L-Cache 策略识别注册表服务器和后端存储服务器内存中的镜像层 digest ，通过去冗余操作整理后端存储服务器内存，并将注册表服务器内存替换出的热点镜像存储在后端存储服务器内存中，弥补去冗余操作后的存储空间，避免用户拉取这些热度暂时减退的镜像层时，从磁盘拷贝该镜像层至内存的延迟开销，提高资源利用率。

总结：L-cache即在registry端和后端存储端都建立预取缓存，优先去registry内存中找，找不到去后端存储内存中找，只要在这两个地方找到都算缓存命中。缓存未命中的话再去后端存储的硬盘中提取。内存去冗余意思就让registry和后端存储的内存中不要存相同的层，如果registry内存中有了就将后端存储内存中的相同层删掉。

L-cache这一研究点主要是通过在Registry端和后端存储端建立预取缓存存储热度较高的层，当命中时直接提供层给客户端，减少了一次网络请求跳转的时间开销（仅当registry端预取缓存命中时）和从后端存储磁盘中提取层的时间开销。

实验结果

L-cache（带内存去冗余功能）和R-cache（不带内存去冗余功能）的缓存命中率随缓存大小变化对比图

L-cache中registry端预取缓存和后端存储端预取缓存随缓存大小变化对比图

延迟节省率计算方法为 $R_{saving} = \frac{T_{object}-T_{registry}}{T_{object}}$

其中 $T_{registry}$ 为使用 L-cache 或 R-Cache 策略时从注册表服务器中拉取镜像的延迟， $T_{object}$ 为使用传统的拉取流程所获得镜像的延迟开销

L-Cache 方案比 Docker 原生镜像拉取延迟减少了 7.7%~19.9%,这为加快容器启动提供了一个新的研究方向。但该方案的不足在于注册表服务器内存的缓存命中率较低，下一章提出新的预取策略以进一步优化缓存命中率，降低拉取镜像的延迟开销。

三、基于关联度的镜像层预取策略 LCPA

图 4.3 中请求的多次跳跃很大程度决定了延迟的下限，特别当后端存储服务器处于高负载时，性能下降会极大地影响拉取镜像的效率。LCPA 策略将一部分镜像存入注册表内存中，合理利用注册表的空闲资源以减轻后端存储服务器的负载。同时，拉取请求处理模块判断请求命中注册表缓存并返回镜像层，相比传统的请求流程减少了一半的请求跳跃次数，极大减少了高延迟。