devicemapper介绍
Device Mapper是Linux系统中基于内核的高级卷管理技术框架。Docker的devicemapper存储驱动就是基于该框架的精简置备和快照功能来实现镜像和容器的管理。
注:Device Mapper是Linux的一种技术框架,而devicemapper是Docker Engine基于Device Mapper提供的一种存储驱动。
早期的Docker运行在Ubuntu和Debian Linux上并使用AUFS作为后端存储。Docker流行之后,越来越多的的公司希望在Red Hat Enterprise Linux这类企业级的操作系统上面运行Docker,但可惜的是RHEL的内核并不支持AUFS。
这个时候红帽公司出手了,决定和Docker公司合作去开发一种基于Device Mapper技术的后端存储,也就是现在的devicemapper。
devicemapper驱动将每一个Docker镜像和容器存储在它自身的具有精简置备(thin-provisioned)、写时拷贝(copy-on-write)和快照功能(snapshotting)的虚拟设备上。由于Device Mapper技术是在块(block)层面而非文件层面,所以Docker Engine的devicemapper存储驱动使用的是块设备来存储数据而非文件系统。
devicemapper的模式
devicemapper是RHEL下Docker Engine的默认存储驱动,它有两种配置模式:loop-lvm和direct-lvm。
loop-lvm是默认的模式,它使用OS层面离散的文件来构建精简池(thin pool)。该模式主要是设计出来让Docker能够简单的被”开箱即用(out-of-the-box)”而无需额外的配置。但如果是在生产环境的部署Docker,官方明文不推荐使用该模式。我们使用docker info命令可以看到以下警告:
WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `–storage-opt dm.thinpooldev` or use `–storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
direct-lvm是Docker推荐的生产环境的推荐模式,他使用块设备来构建精简池来存放镜像和容器的数据。
前段时间有篇很不错的微信文章是关于老司机填devicemapper坑的血泪史,仔细研读之后发现老司机使用的是loop-lvm模式,那个坑有可能由此引起,最终老司机使用overlayfs的存储驱动解决了问题。
注:Linux内核在3.18以上才能支持overlayfs,但RHEL 7.2的内核版本为3.10,所以原生并不支持。但是的确有人在RHEL7.2上成功应用了overlayfs驱动,个人猜测可能是手动在内核里面加载了overlay的模块。
精简池介绍
精简资源调配是什么?
精简资源调配用于LVM以在精简池中创建虚拟磁盘。我们假定我服务器上有15GB的存储容量,而我已经有2个客户各自占去了5GB存储空间。你是第三个客户,你也请求5GB的存储空间。在以前,我们会提供整个5GB的空间(富卷)。然而,你可能只使用5GB中的2GB,其它3GB以后再去填满它。
而在精简资源调配中我们所做的是,在其中一个大卷组中定义一个精简池,再在精简池中定义一个精简卷。这样,不管你写入什么文件,它都会保存进去,而你的存储空间看上去就是5GB。然而,这所有5GB空间不会全部铺满整个硬盘。对其它客户也进行同样的操作,就像我说的,那儿已经有两个客户,你是第三个客户。
那么,让我们想想,我到底为客户分配了总计多少GB的空间呢?所有15GB的空间已经全部分配完了,如果现在有某个人来问我是否能提供5GB空间,我还可以分配给他么?答案是“可以”。在精简资源调配中,我可以为第四位客户分配5GB空间,即使我已经把那15GB的空间分配完了。
警告:从那15GB空间中,如果我们对资源调配超过15GB了,那就是过度资源调配了。
它是怎么工作的?我们又是怎样为客户提供存储空间的?
我已经提供给你5GB空间,但是你可能只用了2GB,而其它3GB还空闲着。在富资源调配中,我们不能这么做,因为它一开始就分配了整个空间。
在精简资源调配中,如果我为你定义了5GB空间,它就不会在定义卷时就将整个磁盘空间全部分配,它会根据你的数据写入而增长,希望你看懂了!跟你一样,其它客户也不会使用全部卷,所以还是有机会为一个新客户分配5GB空间的,这称之为过度资源调配。
但是,必须对各个卷的增长情况进行监控,否则结局会是个灾难。在过度资源调配完成后,如果所有4个客户都尽量写入数据到磁盘,你将碰到问题了。因为这个动作会填满15GB的存储空间,甚至溢出,从而导致这些卷下线。
配置device-lvm
当前服务器为centos7系统,磁盘分配如下
[root@node05 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
cl 1 3 0 wz--n- 556.75g 4.00m
[root@node05 ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 475.37g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 31.38g
从home盘抽出115g给docker用
lvreduce -L 360g /dev/cl/home
[root@node05 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
cl 1 3 0 wz--n- 556.75g 115.37g
(扩展用lvextend,删除用lvremove)
创建LV并转换成精简卷
lvcreate -n thinpool cl -L 90g
lvcreate -n thinpoolmeta cl -L 10g
lvconvert -y --zero n -c 512K --thinpool cl/thinpool --poolmetadata cl/thinpoolmeta
疑问?
[root@node05 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
cl 1 4 0 wz--n- 556.75g 5.37g
剩了5g空间,加上分配的thinpool 90+10=100g,还有10g左右的空间谁占用了?这个坑如果把握不好,lvconvert的时候会出现提示空间不够insufficient free space
修改配置文件,占用超过80%时自动扩展20%
vi /etc/lvm/profile/cl-thinpool.profile
activation {
thin_pool_autoextend_threshold=80
thin_pool_autoextend_percent=20
}
lvchange –metadataprofile cl-thinpool cl/thinpool
查看是否监视
[root@node05 ~]# lvs -o+seg_monitor
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Monitor
home cl -wi-ao---- 360.00g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 31.38g
thinpool cl twi-a-t--- 90.00g 0.00 0.01 monitored
安装docker
yum install docker -y
创建/etc/sysconfig/docker-storage,内容如下
DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/cl-thinpool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true"
启动docker
systemctl daemon-reload
systemctl start docker
到此结束
官网device-lvm配置
https://docs.docker.com/v1.12/engine/userguide/storagedriver/device-mapper-driver/