docker配置devicemapper存储驱动

#查看当前使用的存储驱动,默认为overlay
docker info | grep -i storage

#停止docker
systemctl stop docker
#移除原存储配置文件
rm /etc/sysconfig/docker-storage #使用vdb磁盘创建pv
pvcreate /dev/vdb #使用vdb磁盘创建dockercg
vgcreate dockervg /dev/vdb #配置docker pool为dockervg
cat <<EOF > /etc/sysconfig/docker-storage-setup
VG=dockervg
EOF #配置存储
docker-storage-setup #重启docker
systemctl restart docker

devicemapper存储驱动下镜像的存储

docker数据存储的目录为/var/lib/docker,可以通过docker info | grep -i "Docker Root Dir" 查看

以下通过构建一个镜像来观察镜像的存储方式,Dockerfile如下

#创建测试目录
mkdir -p /tmp/docker-test && cd /tmp/docker-test #创建Dockerfile和测试文件
echo <<EOF > Dockerfile
FROM docker.io/resouer/guestbook:v1 (该镜像已存在节点)
COPY 1 /tmp/1.txt
COPY 2 /tmp/2.txt
COPY 3 /tmp/3.txt
EOF
echo 111 > 1
echo 222 > 2
echo 333 > 3 #构建镜像前/var/lib/docker/devicemapper两个目录文件数量如下

#构建镜像

docker build -t docker-test01 . --no-cache

#构建镜像后/var/lib/docker/devicemapper两个目录文件数量如下

#通过ls -lrt在metadate目录查看最新生成的文件,如图新增了3个文件与Dockerfile中的3个COPY层对应

#每层分别有一个device_id,如下图

使用device_id创建dm设备并挂载到文件系统

如上,每个镜像层都会对应一个device_id

#查看docker为其管理的容器所创建的dm设备
dmsetup ls
dmsetup table
其中dmsetup table输出结果的格式如下
logical_start_sector num_sectors target_type target_args
开始扇区 扇区数 设备类型 设备参数 如docker-253:1-1447237-b4b4ee02b3171ce0d9c9c39012b87dfe69c72fee4ab2a004bf03983ea00b612c: 0 20971520 thin 252:2 141 docker-253:1-1447237-b4b4ee02b3171ce0d9c9c39012b87dfe69c72fee4ab2a004bf03983ea00b612c为在/dm设备名称
0为起始扇区
20971520 为扇区数,一个扇区大小为512kb,总共为10g
thin为{未知,dm设备所使用的存储块按需分配?}
252:2为dockervg-docker--pool的dm编号,可通过dmsetup ls查看
141为device_id #为每个镜像层依次创建dm设备
dmsetup create myimage-dm1 --table "0 20971520 thin 252:2 186"
dmsetup create myimage-dm2 --table "0 20971520 thin 252:2 189"
dmsetup create myimage-dm3 --table "0 20971520 thin 252:2 192"
#查看/dev/mapper目录,发现新增了3个链接文件,链接到不同dm设备

#创建测试挂载点,并挂载dm设备

mkdir -p /tmp/mp1

mkdir -p /tmp/mp2

mkdir -p /tmp/mp3

mount /dev/dm-19 /tmp/mp1/

查看/tmp/mp1中的rootfs/tmp目录,如下,tmp目录只有一个1.txt文件,与Dockerfile中的第一个COPY层吻合

继续通过mount /dev/dm-20 /tmp/mp2/  mount /dev/dm-21 /tmp/mp3/挂载第二层和第三层,均报Filesystem has duplicate UUID 040571c8-2123-4c9b-ab15-a77f69626835 - can't mount,如下

#卸载dm-19,再挂载dm-20,可以看到tmp目录下对应Dockerfile中的第一个COPY和第二个COPY的内容

umount /dev/dm-19 && mount /dev/dm-20 /tmp/mp2

#再次dm-20,再挂载dm-21,可以发现tmp目录是对应的全部的三个测试文件

以上说明,镜像的每一个层是根据Dockerfile中的顺序依次叠加的

应用

每个镜像层是上一个镜像层的一个快照,容器层则是顶层镜像的快照,每一个容器也会对应一个DeviceId。当容器死掉之后,docker会默认移除这个容器对应的dm设备,那么这个死掉的容器的rootfs就没有挂载到文件系统上,可以通过docker inspect {containerId} | grep -i deviceid获取到DeviceId之后,使用上文提到的方法创建dm设备并挂载到文件系统,这样就可以取出死掉的容器中的内容。

参考:

https://www.cnblogs.com/xuxinkun/p/10643840.html

https://blog.csdn.net/felix_yujing/article/details/54344251

摘抄至上述链接:

关于读
官网上读操作的说明图如下:

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操作是无感的

关于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存储驱动下镜像的存储的更多相关文章

  1. Docker存储驱动之Btrfs简介

    简介 Btrfs是下一代的copy-on-write文件系统,它支持很多高级特性,使其更加适合Docker.Btrfs合并在内核主线中,并且它的on-disk-format也逐渐稳定了.不过,它的很多 ...

  2. Docker的OverlayFS存储驱动

    OverlayFS存储驱动 OverlayFS是一个现代的Union Filesystem,类似于AUFS,但速度更快,实现更简单.Docker为OverlayFS提供了两个存储驱动程序:overla ...

  3. Docker存储驱动之ZFS简介

    ZFS是下一代的文件系统,支持了很多存储高级特性,如卷管理.快照.和校验.压缩和重复删除技术.拷贝等. ZFS由Sun公司创建,现属于Oracle,ZFS是开源的,并基于CDDL license.因为 ...

  4. 有容云-【原理】Docker存储驱动之AUFS

    编者按:今天聊一聊Docker的Image(镜像)与Container(容器)的存储以及存储驱动之AUFS.   Docker存储驱动简介 Docker内置多种存储驱动,每种存储驱动都是基于Linux ...

  5. Docker镜像文件存储结构

    docker相关文件存放在:/var/lib/docker目录下 镜像的存储结构主要分两部分,一是镜像ID之间的关联,一是镜像ID与镜像名称之间的关联,前者的结构体叫Graph,后者叫TagStore ...

  6. Docker存储驱动之OverlayFS简介

    简介 OverlayFS是一种和AUFS很类似的文件系统,与AUFS相比,OverlayFS有以下特性: 1) 更简单地设计: 2) 从3.18开始,就进入了Linux内核主线: 3) 可能更快一些. ...

  7. Docker存储驱动之Device Mapper简介

    Device Mapper是一个基于kernel的框架,它增强了很多Linux上的高级卷管理技术.Docker的devicemapper驱动在镜像和容器管理上,利用了该框架的超配和快照功能.为了区别, ...

  8. Docker存储驱动之总览

    简介 本文会介绍Docker存储驱动的特性,别列出现在已经支持的存储驱动,最后,会介绍如果选型适合你的存储驱动. 可插拔的存储驱动架构 Docker的存储驱动架构是可插拔的,可以让你很方便的将适合你环 ...

  9. 聊一聊docker存储驱动

    目录 镜像的分层特性 容器读写层的工作原理 写时复制 用时配置 Docker存储驱动 AUFS OverlayFS Devicemapper 常用存储驱动对比 AUFS VS OverlayFS Ov ...

随机推荐

  1. 学习了解Shiro框架

    有关Shiro安全框架 实现权限的几种方式 1)通过表来实现 2)shiro框架 3)Spring Security框架 shiro有哪些主要功能 1.授权 访问控制的过程,即确定谁有权访问 2.身份 ...

  2. vue表单和组件使用

    表单: <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title ...

  3. 一个漂亮的js表单验证页面+验证码

    一个漂亮的js表单验证页面 见图知其意, 主要特性 带密码安全系数的判断 其他的就没有啥啦 嘿嘿嘿 当然,其代码也在Github上 我也准备了一套可以直接Ctrl + v; Ctrl + c 运行的代 ...

  4. C#开发命令执行驱动程序 之 读入命令行参数

    /// <summary> /// 在cmd窗体内执行如下: /// OrderDriverApp.exe Order Driver App /// 返回: /// The args ar ...

  5. Shiro框架 - 【shiro基础知识】

     转载:https://segmentfault.com/a/1190000013875092#articleHeader27  读完需要 63 分钟   前言 本文主要讲解的知识点有以下: 权限管理 ...

  6. Docker在Linux上 基本使用

    简介 Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任 ...

  7. API 接口开发规范

    整体规范建议采用RESTful 方式来实施. 协议 API与用户的通信协议,总是使用HTTPs协议,确保交互数据的传输安全. 域名 应该尽量将API部署在专用域名之下.https://api.exam ...

  8. Java 并发编程(四):如何保证对象的线程安全性

    01.前言 先让我吐一句肺腑之言吧,不说出来会憋出内伤的.<Java 并发编程实战>这本书太特么枯燥了,尽管它被奉为并发编程当中的经典之作,但我还是忍不住.因为第四章"对象的组合 ...

  9. linux IMX6 汇编点亮一个LED灯

    驱动Linux引脚与驱动STM32其实是一样的,都是在操作寄存器,在相应的寄存器上附上相应的值即可驱动. IMX6U手册上有各个管脚的命名,跟STM32不同,IOMUXC_SW_MUC_CTL_PAD ...

  10. API 网关知识看这篇就足够了!

    本文已经收录自 JavaGuide (60k+ Star[Java学习+面试指南] 一份涵盖大部分Java程序员所需要掌握的核心知识.) 本文授权转载自:https://github.com/java ...