博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
overlayfs存储驱动的使用以及技术探究
阅读量:6089 次
发布时间:2019-06-20

本文共 6593 字,大约阅读时间需要 21 分钟。

hot3.png

overlayfs存储驱动的使用以及技术探究

1.overlayfs 基本概念

一种联合文件系统,设计简单,速度更快。overlayfs在linux主机上只有两层,一个目录在下层,用来保存镜像(docker),另外一个目录在上层,用来存储容器信息。在overlayfs中,底层的目录叫做lowerdir,顶层的目录称之为upperdir,对外提供统一的文件系统为merged。 当需要修改一个文件时,使用CoW将文件从只读的Lower复制到可写的Upper进行修改,结果也保存在Upper层。在Docker中,底下的只读层就是image,可写层就是Container。

输入图片说明

可以看到镜像层和容器层可以保存相同的文件,容器层的文件会覆盖镜像层的文件

  • 在overlayfs中每个镜像层都会在/var/lib/docker/overlay有对应的目录,使用硬链接与底层数据进行关联。

2. 优势劣势

  • 1.OverlayFS支持页缓存共享,多个容器访问同一个文件能共享一个页缓存,以此提高内存使用
  • 2.OverlayFS消耗inode,随着镜像和容器增加,inode会遇到瓶颈。Overlay2能解决这个问题。在Overlay下,为了解决inode问题,可以考虑将/var/lib/docker挂在单独的文件系统上,或者增加系统inode设置。

3. overlay中的读写

3.1 在容器中读取文件

  • (1)目标文件不在容器层内,overlay会从镜像层读取文件,此时,对容器性能的影响很小。

  • (2)目标文件在容器层内,overlay直接从容器层读取。

  • (3)目标文件在容器层和镜像层同时存在,overlay读入容器层中的文件,此时容器层的文件会覆盖镜像层的文件。

3.2 在容器中修改文件

在容器中第一次修改文件,此时文件不在容器层中。overlay会把文件从镜像层复制到容器层,所有该文件中的修改都保存在容器层中。

注意:overlay工作文件系统层(devicemapper工作再块层面),因此复制文件会复制整个文件,因此在频繁读写会很消耗资源

  • (1)只是在第一次修改文件时,需要把文件从镜像层复制到容器层,后续操作都是在容器层中完成。

  • (2)overlayfs只有两层,lowerdir和upperdir,因此在很深的目录树中,搜索文件会相对比较快

3.3 在容器中删除文件和目录

在容器中删除文件时,overlay存储驱动在容器层中新建一个without文件,该文件用语隐藏镜像层中的目标文件。在容器层删除目录时,overlay存储驱动在容器层新建一个opaque目录,该目录用于隐藏镜像层中的目标目录。 需要明白的一点是,任何存储驱动都不会删除底层image中的目标文件和目录的。

3.4 overlayfs的原理测试

overlayfs挂载后系统文件的page cache是全部共享的。

# mkdir low upper work# lslow  upper  work# echo 'abs' > low/11.txt# echo 'xuxuebiao' > upper/22.txt# mkdir merged# mount -t overlay overlay -olowerdir=./low,upperdir=./upper,workdir=./work ./merged# lslow  merged  upper  work# cd merged/# ls11.txt  22.txt# lltotal 8-rw-r--r--. 1 root root  4 Mar 27 18:57 11.txt-rw-r--r--. 1 root root 10 Mar 27 18:58 22.txt# tree.├── low│   └── 11.txt├── merged│   ├── 11.txt│   └── 22.txt├── upper│   └── 22.txt└── work    └── work5 directories, 4 files可以看到,merged目录中时low和upper目录联合的结果分别修改文件:# cat 11.txtabs# cat 22.txtxuxuebiao# vim 11.txt# cat 11.txtHello ,overlayfs!# cat ../low/11.txtabs# cat ../upper/11.txt   11.txt~  22.txt# cat ../upper/11.txtHello ,overlayfs!# cat ../upper/11.txt~cat: ../upper/11.txt~: No such device or address# cat ../upper/11.txt11.txt   11.txt~# cat ../upper/11.txt~cat: ../upper/11.txt~: No such device or address可以看到low目录下的文件没有变化,但是upper里面的文件内容已经改变,并且有了一个11.txt~文件# ls -i ../upper/11.txt 11.txt143902921 11.txt  143902921 ../upper/11.txt可以看到upper和merged目录中的两个文件11.txt的inode其实是一致的,其实是硬链接# ls -i ../low/11.txt 11.txt143902921 11.txt  143902918 ../low/11.txtmerged目录文件和low目录文件对比删除文件测试:# rm 11.txtrm: remove regular file ‘11.txt’? y# lsls: cannot access 11.txt: No such file or directoryls: cannot access 11.txt~: No such file or directory11.txt  11.txt~  22.txt# cat ../upper/11.txt~cat: ../upper/11.txt~: No such device or address# ls -l ../upper/11.txtc---------. 1 root root 0, 0 Mar 27 19:08 ../upper/11.txt删除文件后发现文件无法访问,底层变成了一个大小为0,且没有任何人有权限的一个空文件。overlayfs用这种删除标记的方式标识文件被删除,(如果upper中没有该文件的话,则底层low中的同名文件又恢复出来显示了,因此需要有这个空文件来标识删除,并且覆盖底层的文件)

4.overlayfs在docker中的使用

首先,overlayfs是在高版本的内核上才支持的存储驱动,因此不管使用的官方内核,还是自己patch的内核,首先需要检查overlayfs是否被加载

并且同样重要的是,对于aufs和overlay的实现,用来读取或执行共享库的共享内存也在所有运行的容器之间共享,大大的减少了通用库如’libc’的内存占用。这是一个分层策略的巨大优势,同时也是Docker的graphdriver是引擎中相当重要的一部分的原因之一。graphdriver的功能作用。

  • 1.检查overlay是否被加载
查看overlay是否被加载$ lsmod | grep overlay查看内核是否支持overlay模块$ modinfo overlayfs加载内核模块$ modprobe overlayfs
  • 2.docker启动参数修改
检测overlayfs释放被识别,成功启动后修改参数到默认的配置文件中$ docker daemon(dockerd) -s overlay(--storage-driver=overlay) 修改配置文件$ cat /etc/sysconfig/docker.confDOCKER_OPTS="--storage-driver=overlay"模拟配置:other_args="-s overlay --graph=/export/lib/docker -H unix:///var/run/docker.sock --bip 10.0.0.1/24 -H 0.0.0.0:5256  --api-enable-cors=true"
  • 3.检验overlayfs是否成功启动
$ sudo /etc/init.d/docker restart成功启动,查看存储信息:$ sudo docker infoContainers: 11Images: 5Server Version: 1.9.1Storage Driver: overlay Backing Filesystem: extfsExecution Driver: native-0.2Logging Driver: json-fileKernel Version: 2.6.32-431.el6.x86_64Operating System: 
CPUs: 32Total Memory: 126 GiBName: -----ID: 2IER:NO5S:4NKX:ULDJ:THGQ:GBNR:NIN6:SCXG:SMFX:PG72:JAQF:GRZW可用看到相关存储驱动是overlay,文件系统是extfs
  • 4.overlay在docker上面的使用

默认docker会将容器以及镜像相关的文件存储在/var/lib/docker/overlay目录下

sh-4.1# docker  imagesREPOSITORY                        TAG                 IMAGE ID            CREATED             VIRTUAL SIZEcentos6.8-sshd   latest              42c75e16533e        12 weeks ago        402 MBsh-4.1# pwd  (这里我们是配置了存储路径)/export/lib/docker/overlaysh-4.1# ll -ttotal 28drwx------ 4 root root 4096 Mar 31 10:37 8ab8690b0769d07cc0b546112cfc40068d99298ed7e1857272c98a522cede527drwx------ 4 root root 4096 Mar 31 10:37 8ab8690b0769d07cc0b546112cfc40068d99298ed7e1857272c98a522cede527-initdrwx------ 3 root root 4096 Mar 31 10:35 42c75e16533e2ef46ffd22a21318d354b3f3e520709230e9848ebaca8f1f514edrwx------ 3 root root 4096 Mar 31 10:35 b46ba152cc17054229bc0099e7fda8b34958d518ce687c0d378b4832c4d8c91edrwx------ 3 root root 4096 Mar 31 10:35 9016bb11dc9b4a3ee23fbef484cf5b3c9b80491e87d67092febec45759baeb4fdrwx------ 3 root root 4096 Mar 31 10:35 ea80c789cb2b3bcc1d12b9b3226c8482a06f28e94a4a49f8e201b5e9cdbdf0ccdrwx------ 3 root root 4096 Mar 31 10:35 e444e2175366cd3507bc9278d9a68a7b7ca5759b364bfe960fc12a87f219e847可用看到我们现在有一个image,id为42c75e16533e,overlay会把该镜像的所有父镜像存储到本地(image的分层缓存),该image共5层。sh-4.1# docker  inspect 42c75e16533e | grep b46ba152cc1    "Parent": "b46ba152cc17054229bc0099e7fda8b34958d518ce687c0d378b4832c4d8c91e",sh-4.1# docker  inspect b46ba152cc1 | grep 9016bb11dc9b4a    "Parent": "9016bb11dc9b4a3ee23fbef484cf5b3c9b80491e87d67092febec45759baeb4f",sh-4.1# docker  inspect 9016bb11dc9b4a | grep ea80c789cb2    "Parent": "ea80c789cb2b3bcc1d12b9b3226c8482a06f28e94a4a49f8e201b5e9cdbdf0cc",sh-4.1# docker  inspect ea80c789cb2 | grep e444e2175366cd35    "Parent": "e444e2175366cd3507bc9278d9a68a7b7ca5759b364bfe960fc12a87f219e847",sh-4.1# docker  inspect e444e2175366cd35 | grep Parent    "Parent": "",sh-4.1#由下面示例可以看到容器id 8ab8690b07,实际上是使用image 42c75e16533e 启动起来的一个container,并给出了container 的LowerDir:`/export/lib/docker/overlay/42c75e16533e2ef46ffd22a21318d354b3f3e520709230e9848ebaca8f1f514e/root`sh-4.1# docker inspect 8ab8690b07 | grep Parent        "CgroupParent": "",sh-4.1# docker inspect 8ab8690b07 | grep 42c75e1653    "Image": "42c75e16533e2ef46ffd22a21318d354b3f3e520709230e9848ebaca8f1f514e",            "LowerDir": "/export/lib/docker/overlay/42c75e16533e2ef46ffd22a21318d354b3f3e520709230e9848ebaca8f1f514e/root",        "Image": "42c75e16533e",sh-4.1#查看容器内部的存储结构:sh-4.1# ls 8ab8690b0769d07cc0b546112cfc40068d99298ed7e1857272c98a522cede527/lower-id  merged/   upper/容器的存储里面默认会存放三个文件,lower-id纪录的是image的id,也就是上面提到的LowerDir,其次存在merged和upper目录,分别为容器层,和容器最终看到的merged层。overlayfs中的lower,upper,merged三者的关系看文首。

转载于:https://my.oschina.net/xxbAndy/blog/884019

你可能感兴趣的文章
.NET[C#]中NullReferenceException(未将对象引用到实例)是什么问题?如何修复处理?...
查看>>
边缘控制平面Ambassador全解读
查看>>
Windows Phone 7 利用计时器DispatcherTimer创建时钟
查看>>
程序员最喜爱的12个Android应用开发框架二(转)
查看>>
vim学习与理解
查看>>
DIRECTSHOW在VS2005中PVOID64问题和配置问题
查看>>
MapReduce的模式,算法以及用例
查看>>
《Advanced Linux Programming》读书笔记(1)
查看>>
zabbix agent item
查看>>
一步一步学习SignalR进行实时通信_7_非代理
查看>>
字符设备与块设备的区别
查看>>
为什么我弃用GNOME转向KDE(2)
查看>>
Redis学习记录初篇
查看>>
爬虫案例若干-爬取CSDN博文,糗事百科段子以及淘宝的图片
查看>>
Web实时通信技术
查看>>
第三章 计算机及服务器硬件组成结合企业运维场景 总结
查看>>
IntelliJ IDEA解决Tomcal启动报错
查看>>
默认虚拟主机设置
查看>>
php中的短标签 太坑人了
查看>>
[译] 可维护的 ETL:使管道更容易支持和扩展的技巧
查看>>