docker的devicemapper存储驱动

古城微笑少年丶 2022-07-13 13:43 202阅读 0赞

最近在官网上看了下[devicemapper的说明文档][devicemapper]，这里简要总结一下。

# 1 诞生的背景 #

期初docker是运行在Debian和Ubuntu系统上的，使用的是AUFS方式的存储。后来很多企业希望在Redhat系linux上运行docker，并决定基于现有的Device Mapper技术开发一个新的存储方案，这就是devicemapper。

# 2 镜像的分层和共享 #

Device Mapper技术不是按照文件级别（file level），而是按块级别（block level）工作的，所以devicemapper也属于块级存储方案，有着thin provisioning和copy-on-write的特点。

*  thin provisioning  
    这个不知道该怎么翻译，网上叫自动精简配置的比较多（与此相对的传统的存储配置模型被称为厚存储配置FP），简单的说就是在需要的时候分配所需的最小空间（与此相对，传统的存储空间的分配都是超过目前的需求的，从而导致的一个问题就是存储利用率低下）。
 *  copy-on-write  
    简单的理解就是，在内容发生变化的时候才进行内容复制。

## devicemapper存储方式下的镜像 ##

使用devicemapper存储生成镜像大致按照下面的流程：  
首先，devicemapper驱动从块设备创建一个小的存储池（a thin pool）  
然后，创建一个带有文件系统，如extfs等，的基础设备（base device）  
之后，每个新的镜像（或镜像层）都是base device的一个快照（snapshot）

## devicemapper存储方式下的容器 ##

devicemapper存储方式下，容器层都是从镜像生成的快照，快照里存储着所有对容器的更新。当数据被写入容器的时候，devicemapper按需从池中分配空间。

下面是官方文档中的一个说明图：  
![这里写图片描述][SouthEast]  
从上图可以看出，每个镜像层都是它下面一层的快照。每个镜像的最下面一层的镜像则是池中base device的快照。需要注意的是，base device属于Device Mapper的一部分，并不是docker的镜像层。

# 3 devicemapper下的读写 #

## 关于读 ##

官网上读操作的说明图如下：  
![这里写图片描述][SouthEast 1]  
1）应用请求读取容器中的0x44f块区  
因为容器是镜像的一个简单快照，并没有数据只有一个指针，指向镜像层存储数据的地方。  
2）存储驱动根据指针，到镜像快照的a005e镜像层寻找0xf33块区  
3）devicemapper从镜像快照拷贝0xf33的内容到容器的内存中  
4）存储驱动最后将数据返回给请求的应用

## 关于写 ##

当对容器中的大文件做一个小的改动的时候，devicemapper不会复制这整个文件，而是只拷贝被修改的块区。每个块区的大小为64KB。

*  写新数据的情况  
    例如，写56KB大小的新数据到一个容器：  
    1）应用发出一个要写56KB的新数据到容器的请求  
    2）根据按需分配，将分配一个新的64KB的块区给容器的快照  
    如果写操作的数据大于64KB的话，将分配多个块区  
    3）之后，数据将被写入到新分配的块区中
 *  覆写已有的数据  
    每当容器第一次更新已有的数据时：  
    1）应用发出一个修改容器中数据的请求  
    2）copy-on-write操作将定位到需要更新的块区  
    3）然后分配新的空块区给容器快照，并复制数据到新分配的块区  
    4）接着，在有复制数据的新块区中进行数据修改  
    容器中的应用对发生的allocate-on-demand操作和copy-on-write操作是无感的

# 4 关于devicemapper的配置 #

Redhat系的linux发行版都采用devicemapper作为docker的默认存储驱动。目前，Debian，Ubuntu和Arch Linux也支持devicemapper。

devicemapper默认使用的是loop-lvm模式，这个模式使用sparse files来创建供镜像和容器快照使用的thin pool。然而，生产环境不要使用loop-lvm模式，官方建议使用direct-lvm模式。direct-lvm模式使用块设备（block devices）来创建thin pool。

假设/dev/mapper/docker-thinpool是已建好的lvm的逻辑卷，可以配置docker daemon的运行选项如下：

--storage-driver=devicemapper --storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool --storage-opt=dm.use_deferred_removal=true --storage-opt=dm.use_deferred_deletion=true

官方说设置dm.use\_deferred\_removal=true和dm.use\_deferred\_deletion=true选项可以防止unintentionally leaking mount points（没太明白什么意思，总之配了比不配好吧）。

## devicemapper在主机上的结构 ##

使用lsblk命令可以查看设备文件和devicemapper在设备文件上创建的pool：  
![这里写图片描述][SouthEast 2]  
对应上面接口的层次图如下：  
![这里写图片描述][SouthEast 3]  
可以看出，名为Docker-202:1-1032-pool的pool横跨在data和metadata设备之上。pool的命名规则为：

> Docker-主设备号:二级设备号-inode号-pool

docker 1.10和以后的版本，在/var/lib/docker目录下不在采用镜像层ID来关联目录名了，有另外两个比较重要的目录：  
/var/lib/docker/devicemapper/mnt 包含镜像和容器层的挂载目录；  
/var/lib/docker/devicemapper/metadata 目录包含每个镜像层和容器快照的json格式的文件。

另外，当数据的逻辑卷要满的时候，可以给pool进行扩容，具体操作看官网。

# 5 关于devicemapper的性能 #

## allocate-on-demand的性能影响 ##

每当应用有新数据要写入容器时，都要从pool中去定位空的块区并映射给容器。因为所有块区都是64KB的，小于64KB的数据也会分配一个块区；大于64B的数据则会分配多个块区。所以，特别是当发生很多小的写操作时，就会比较影响容器的性能。

## copy-on-write的性能影响 ##

每当容器第一次更新已有的数据时，devicemapper存储驱动都要执行copy-on-write操作。这个操作是从镜像快照复制数据到容器快照，这对容器性能还是有比较明显的性能影响的。当容器发生很多小64KB的写操作时，devicemapper的性能会比AUFS要差。

## 其它方面 ##

1）所使用的mode  
默认情况下，devicemapper使用的是loop-lvm模式，这种模式使用的是sparse files，性能比较低。生产环境建议使用direct-lvm模式，这种模式存储驱动直接写数据到块设备。  
2）使用高速存储  
如果希望更好的性能，可以将Data file和Metadata file放到SSD这样的高速存储上。  
3）内存使用  
devicemapper并不是一个有效使用内存的存储驱动。当一个容器运行n个时，它的文件也会被拷贝n份到内存中，这对docker宿主机的内存使用会造成明显影响。因此，devicemapper存储驱动可能并不是PaaS和其它高密度使用型的最好选择。

对于写操作较大的，可以采用挂载data volumes。使用data volumes可以绕过存储驱动，从而不受thin provisioning和copy-on-write产生的负责影响。

[devicemapper]: https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
[SouthEast]: /images/20220713/90c2df5eb763445da9c2f346bf840cc9.png
[SouthEast 1]: /images/20220713/da449fabb38e45cc8cf75f9e24ccf59b.png
[SouthEast 2]: /images/20220713/21f773ab7d77406e83752bcb24abe485.png
[SouthEast 3]: /images/20220713/3777c2e826d24e76bdcc8bca041afcb5.png