Docker存储驱动devicemapper介绍和配置

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的模块。

配置direct-lvm模式

停止Docker并备份

如果Docker服务已在运行且有需要保留的镜像和容器,停服务前把相关数据给备份。个人也强烈建议如果是在生产环境使用Docker的话,拿到host的第一时间就将direct-lvm模式给配置了。(当然也可以选择其他的storage driver)

查看当前devicemapper模式

[[email protected] ~]# docker info...Storage Driver: devicemapper

 Pool Name: docker-8:3-17702667-pool

 Pool Blocksize: 65.54 kB

 Base Device Size: 10.74 GB

 Backing Filesystem: xfs

 Data file: /dev/loop0

 Metadata file: /dev/loop1

 Data Space Used: 11.8 MB

 Data Space Total: 107.4 GB

 Data Space Available: 17.15 GB

 Metadata Space Used: 581.6 kB

 Metadata Space Total: 2.147 GB

 Metadata Space Available: 2.147 GB

 Udev Sync Supported: true Deferred Removal Enabled: false Deferred Deletion Enabled: false Deferred Deleted Device Count: 0 Data loop file: /var/lib/docker/devicemapper/devicemapper/data

 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata...

基于highlight的内容可以看到当前模式为loop-lvm

停止docker服务

[[email protected] ~]# systemctl stop docker
[[email protected] ~]# systemctl status docker?.docker.service - Docker Application Container Engine   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)   Active: inactive (dead) since Sat 2016-08-27 15:54:26 UTC; 1min 28s ago

     Docs: https://docs.docker.com  Process: 2176 ExecStart=/usr/bin/docker daemon -H fd:// (code=exited, status=0/SUCCESS) Main PID: 2176 (code=exited, status=0/SUCCESS

分配裸设备

本例以Nutanix的ABS功能来分配一块iSCSI盘到docker宿主机,推荐使用外部共享存储的设备但不局限于此种方式,可根据自己的环境决定。

创建一个Volume Group

添加50GB的盘

将Volume Group挂给docker宿主机

创建VG

查看设备

[[email protected] ~]# fdisk -l /dev/sdbDisk /dev/sdb: 53.7 GB, 53687091200 bytes, 104857600 sectorsUnits = sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

创建PV

[[email protected] ~]# pvcreate /dev/sdb  Physical volume "/dev/sdb" successfully created

创建VG

[[email protected] ~]# vgcreate docker /dev/sdb  Volume group "docker" successfully created

查看VG信息

[[email protected] ~]# vgdisplay docker  --- Volume group ---  VG Name               docker

  System ID            

  Format                lvm2

  Metadata Areas        1  Metadata Sequence No  1  VG Access             read/write

  VG Status             resizable

  MAX LV                0  Cur LV                0  Open LV               0  Max PV                0  Cur PV                1  Act PV                1  VG Size               50.00 GiB  PE Size               4.00 MiB  Total PE              12799  Alloc PE / Size       0 / 0  

  Free  PE / Size       12799 / 50.00 GiB  VG UUID               bXJkQH-qSJc-t5JT-f1GL-reTR-XBVf-ylCEFY

创建thinpool

创建pool

[[email protected] ~]# lvcreate --wipesignatures y -n thinpool docker -l 95%VG  Logical volume "thinpool" created.
[[email protected] ~]#  lvcreate --wipesignatures y -n thinpoolmeta docker -l 1%VG  Logical volume "thinpoolmeta" created.

数据LV大小为VG的95%,元数据LV大小为VG的1%,剩余的空间用来自动扩展。

将pool转换为thinpool

[[email protected] ~]# lvconvert -y --zero n -c 512K --thinpool docker/thinpool --poolmetadata docker/thinpoolmeta  WARNING: Converting logical volume docker/thinpool and docker/thinpoolmeta to pool‘s data and metadata volumes.

  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)

  Converted docker/thinpool to thin pool.

配置thinpool

配置池的自动扩展

[[email protected] ~]# vi /etc/lvm/profile/docker-thinpool.profileactivation {    thin_pool_autoextend_threshold=80    thin_pool_autoextend_percent=20}

应用配置变更

[[email protected] ~]# lvchange --metadataprofile docker-thinpool docker/thinpool  Logical volume "thinpool" changed.

状态监控检查

[[email protected] ~]# lvs -o+seg_monitor  LV       VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Monitor 

  thinpool docker twi-a-t--- 47.50g             0.00   0.02                             monitored

配置Docker

修改服务配置文件

[[email protected] ~]# vi /etc/systemd/system/docker.service--storage-driver=devicemapper --storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool --storage-opt dm.use_deferred_removal=true

ExecStart后加入storage相关配置参数,如果配置了$OPTIONS也可以在对应的EnvironmentFile中加入。

清除graphdriver

[[email protected] ~]# rm -rf /var/lib/docker/*

之前已提醒数据备份,因为在这里清除graphdriver会将image,Container和volume所有数据都删除。如果不删除,则会遇到以下的错误导致docker服务起不来

Error starting daemon: error initializing graphdriver: devmapper: Base Device UUID and Filesystem verification failed: devicemapper: Error running deviceCreate (ActivateDevice) dm_task_run failed

启动docker服务

[[email protected] ~]# systemctl daemon-reload[[email protected] ~]# systemctl start docker

检查devicemapper配置

[[email protected] ~]# docker info...Storage Driver: devicemapper

 Pool Name: docker-thinpool

 Pool Blocksize: 524.3 kB

 Base Device Size: 10.74 GB

 Backing Filesystem: xfs

 Data file: Metadata file: Data Space Used: 20.45 MB

 Data Space Total: 51 GB

 Data Space Available: 50.98 GB

 Metadata Space Used: 90.11 kB

 Metadata Space Total: 532.7 MB

 Metadata Space Available: 532.6 MB

 Thin Pool Minimum Free Space: 5.1 GB

 ...

基于highlight的内容可以看到当前模式为direct-lvm

测试

pull一个镜像看是否数据会写到thinpool里

[[email protected] ~]# lvs  LV       VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert  thinpool docker twi-a-t--- 47.50g             0.04   0.02           

          [[email protected] ~]# docker pull busyboxUsing default tag: latest

latest: Pulling from library/busybox8ddc19f16526: Pull completeDigest: sha256:a59906e33509d14c036c8678d687bd4eec81ed7c4b8ce907b888c607f6a1e0e6Status: Downloaded newer image for busybox:latest[[email protected] ~]# lvs  LV       VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert  thinpool docker twi-a-t--- 47.50g             0.08   0.02

可以看到Data%在pull一个busybox镜像后使用率由0.04变为0.08,说明direct-lvm配置成功且正常工作。

时间: 2024-12-16 05:50:58

Docker存储驱动devicemapper介绍和配置的相关文章

Docker存储驱动之Device Mapper简介

Device Mapper是一个基于kernel的框架,它增强了很多Linux上的高级卷管理技术.Docker的devicemapper驱动在镜像和容器管理上,利用了该框架的超配和快照功能.为了区别,本文使用Device Mapper指驱动中的框架,而devicemapper指Docker的存储驱动. 注意:商业支持的Docker Engine(CS-Engine)建议在RHEL和CentOS上使用devicemapper存储驱动. AUFS之外的另一种选择 Docker最初运行在Ubuntu和

Docker存储驱动之OverlayFS简介

简介 OverlayFS是一种和AUFS很类似的文件系统,与AUFS相比,OverlayFS有以下特性: 1) 更简单地设计: 2) 从3.18开始,就进入了Linux内核主线: 3) 可能更快一些. 因此,OverlayFS在Docker社区关注度提高很快,被很多人认为是AUFS的继承者.就像宣称的一样,OverlayFS还很年轻.所以,在生成环境使用它时,还是需要更加当心. Docker的overlay存储驱动利用了很多OverlayFS特性来构建和管理镜像与容器的磁盘结构. 自从Docke

聊一聊docker存储驱动

目录 镜像的分层特性 容器读写层的工作原理 写时复制 用时配置 Docker存储驱动 AUFS OverlayFS Devicemapper 常用存储驱动对比 AUFS VS OverlayFS OverlayFS VS Device mapper 镜像的分层特性 在说docker的文件系统之前,我们需要先想清楚一个问题.我们知道docker的启动是依赖于image,docker在启动之前,需要先拉取image,然后启动.多个容器可以使用同一个image启动.那么问题来了:这些个容器是共用一个i

Docker存储驱动之ZFS简介

ZFS是下一代的文件系统,支持了很多存储高级特性,如卷管理.快照.和校验.压缩和重复删除技术.拷贝等. ZFS由Sun公司创建,现属于Oracle,ZFS是开源的,并基于CDDL license.因为CDDL和GPL不兼容,ZFS不能加入Linux kernel主线.然而,ZFS On Linux(ZoL)项目提供kernel模块和用户空间程序,这些都可以单独的安装. ZFS on Linux(ZoL)是一项成熟的技术,但是,现在却不建议在产品中使用zfs存储驱动,当然,除非你对ZoL有着丰富的

Docker存储驱动之Btrfs简介

简介 Btrfs是下一代的copy-on-write文件系统,它支持很多高级特性,使其更加适合Docker.Btrfs合并在内核主线中,并且它的on-disk-format也逐渐稳定了.不过,它的很多特性还仍然处于开发中. Docker的btrfs存储驱动利用了很多Btrfs特性来管理镜像和容器.这些特性中最重要的就是thin provisioning(超配).copy-on-write和快照. Btrfs特性 Btrfs一直被认为是Linux文件系统的未来.在Linux内核主线的全力支持下,稳

docker存储驱动

http://www.sohu.com/a/101016494_116235 https://success.docker.com/article/compatibility-matrix Red Hat Enterprise Linux:4.x版本内核或更高版本 + Docker 17.06 版本或更高版本,建议使用 Overlay2. Red Hat Enterprise Linux:低版本内核或低版本的 Docker,建议使用 Device Mapper. Ubuntu Linux:4.x

Centos7 为Docker配置overlay存储驱动

前提: RHEL或CentOS 使用新的docker存储驱动(overlay or overlay2),需要升级系统内核版本到3.10.0-514以上版本.梳理步骤如下: 确认内核 3.10.0-514以上版本 uname -r 3.10.0-514.++++.x86_64 系统升级 sudo yum upgrade --assumeyes --tolerant sudo yum update --assumeyes 确认内核是否加载 overlay模块 lsmod | grep overlay

docker 存储驱之overlayFS

一.概述 docker镜像采用分层分层构建设计,每层称为"layer", layer存放在/data/docker/存储驱动/目录下面 这些存储驱动有,AUFS,OverlayFS等,可以通过docker info命令查看存储驱动,centos7.1+默认采用OverlayFS模式.二.OverlayFS介绍 OverlayFS是一种堆叠文件系统,建立在其他文件系统之上,并不参与磁盘底层划分,只是将底层文件系统目录"合并",实际是伪合并,只是呈现给用户好像一个文件系

docker 配置Btrfs和Device mapper存储驱动设置

运行环境: docker -v Docker version 1.12.1, build 23cf638 uname -a Linux ceph-6-29 3.10.0-327.28.3.el7.x86_64 #1 SMP Thu Aug 18 19:05:49 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux\ 一:docker 首次安装完成,默认存储设备为loop 回环设备,会创建一个100G的用于存储数据,和一个2G的用于存储元数据的稀疏文件,然后分别附加到回