未加星标

DCOS Docker存储方式研究选型

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二04 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

本文的目的

Docker原生提供了多种存储驱动,用户需要做的是结合自己的场景选用其中之一。没有一种存储驱动是适合所有场景的。本文先简单介绍如下几种存储驱动:AUFS、DeviceMapper、Btrfs、overlayFs、ZFS,之后说明PPTV在构建DCOS的选型过程。

如何指定存储驱动

用户决定使用哪款驱动,要在Docker守护进程启动时指定,当然指定的驱动必须被底层操作系统支持。如更换存储驱动,需重启守护进程。指定存储驱动的方法可参考Docker官网,操作简单方便。各存储驱动都封装了统一接口供守护进程调用,一旦完成初始化,存储驱动的差异对守护进程来说是透明的。

Copy On Write技术

想要有效的使用存储驱动,需要了解Docker如何存储镜像以及容器如何使用镜像。Docker镜像含有启动Docker容器所需的文件系统结构及其内容。在传统的linux操作系统内核启动时,首先挂载一个只读的rootfs,当系统检测其完整性后,再将其切换为读写模式。而在Docker架构中,当Docker daemon为Docker容器挂载rootfs时,沿用了Linux内核启动时的方法,即将rootfs设为只读模式,在挂载完毕之后,在已有的只读rootfs上再挂载一个读写层。这样。可读写层处于Docker容器文件系统的最顶层,其下可能挂载多个只读层,只有在Docker容器运行过程中文件系统发生变化时,才会把文件拷贝到读写层再修改,这样的技术被称为写时复制(Copy On Write)。存储驱动提供了接口支持镜像分层与写时复制机制。

AUFS

Docker团队最开始在dotCloud内部便使用AUFS来运行容器,因此AUFS有最长的历史,也就拥有较为丰富的运维经验。AUFS层层堆叠多个文件系统层,然后每一层都对外公开一个单独的挂载点供访问。它每一次的查找总是先从最顶层开始,当某个文件需要作读写操作时该文件将会被复制到最顶层,因此在性能方面的瓶颈主要在于需要写入大文件的场景。不过AUFS存储驱动最主要的问题还是AUFS文件系统本身没有被纳入主流的Linux内核版本。


DCOS Docker存储方式研究选型

图1 AUFS镜像层容器层

DeviceMapper

DeviceMapper使用预分配技术来实现镜像分层,DeviceMapper的写时复制技术是基于块级别的,不同于AUFS基于文件级别。当Docker守护进程启动时,会创建预分配机制所必须的两个块设备:用作存储池的数据设备和维护元数据的设备,守护进程在预分配的存储池上创建一个基础设备,所有新的镜像层都是基础设备的一个快照,基础设备的大小默认为10GB,可以在守护进程启动时通过dm.basesize参数来修改这一配置。DeviceMapper有两种模式,默认为loop模式,生产环境建议使用direct-lvm模式,原因为loop模式是基于两个稀疏文件创建虚拟的块设备的,影响性能。


DCOS Docker存储方式研究选型

图2 DeviceMapper镜像层容器层

Btrfs

Btrfs以块为单位存储数据,一个块就是一段原始存储。Docker利用Btrfs的子卷特性,每一个新创建的容器都会被分配一个新的Btrfs子卷,如果存在父镜像层,那么它会以父镜像层子卷的一个快照的形式创建。


DCOS Docker存储方式研究选型

图3 Btrfs镜像层容器层

OverlayFs

OverlayFs是一个联合文件系统,与AUFS的做法有些类似,由于合并目录,overlayFs在查找效率方面作了不小的改进,不同于AUFS镜像层越多则查找时间越长。基于overlayFs技术有两种存储驱动:overlay与overlay2,根据官方文档,overlay要求内核版本3.18以上,overlay2要求内核版本4.0以上。但是我们经过尝试,可以在3.10内核使用overlay。


DCOS Docker存储方式研究选型

图4 overlay镜像层容器层

ZFS

ZFS是Sun公司(现在的Oracle)发明的并在CDDL条款下开源。而由于CDDL与GPL开源条款的不兼容,ZFS无法并入Linux内核主线。不过ZFS On Linux(ZoL)项目提供了一个可以单独安装的内核模块和用户空间工具。除非你在ZoL项目上已经有大量的实践经验,现阶段并不推荐在生产环境中使用zfs作为Docker的存储驱动。

如下图所示,镜像的最底层(base layer)是一个ZFS文件系统。每一个镜像子层都是一个基于下层ZFS快照的ZFS克隆实体。一个容器的文件系统是一个ZFS克隆,下层是从镜像层创建的快照。所有数据实体都从zpool分配空间。


DCOS Docker存储方式研究选型

图5 ZFS镜像层容器层

我们的现状

在过去的一段时间,我们使用loop模式的DeviceMapper作为存储驱动,是Docker默认的,在使用过程中遇到一些问题。

[[email protected] Deploy]# docker stop

b977235038bce3176279bdd27cf84b12755eff0ed08d6a11b09e5e8e97480f78

b977235038bce3176279bdd27cf84b12755eff0ed08d6a11b09e5e8e97480f78

[[email protected] Deploy]# docker rm

b977235038bce3176279bdd27cf84b12755eff0ed08d6a11b09e5e8e97480f78

Error response from daemon: Driver devicemapperfailed to remove root filesystem

b977235038bce3176279bdd27cf84b12755eff0ed08d6a11b09e5e8e97480f78

: Device is Busy

如上面所示问题,不只一次出现,目前都没有完全解决,最终只能用重启Docker的方法,如果在生产环境中遇到这样的问题,应该是大家不希望看到的。

我们分析产生该问题的原因还是在于loop模式的的devicemapper所用的数据设备和元数据设备都只是绑定到回环设备上的稀疏文件,如不做特别的配置,这些文件大小一般看上去是100GB(如下图所示loop0)和2GB(如下图所示loop1),由于使用预分配机制,在实际写入数据之前,并不会真正占用100GB和2GB的磁盘空间。这样的机制让我们想到两个问题:1、稀疏文件性能不太好,且文件本身可能会损坏;2、由于预分配机制,待需要占用的时候,如果实际磁盘空间已经没有那么多了,就会发生异常。

[[email protected]]#lsblk
NAME MAJ:MINRM SIZE RO TYPE MOUNTPOINT
fd0 8:0 0 4k 0 disk
sda1
sda2
loop0 7:0 0 100G 0 loop
loop1 7:1 0 2G 0 loop

接下来如何选择

用户可根据自己的实际需要,考虑以下几个方面:容器密度、文件大小、是否IO密集等,以及自己在使用方面的喜好,来选择一种。

由于AUFS没有并入linux内核主线,overlay没有完全支持POSIX标准,ZFS也存在兼容性问题。鉴于DeviceMapper(loop模式)之前遇到种种问题,所以我们计划在Btrfs与DeviceMapper(direct-lvm模式)两者中选一种,下面对他们进行一些IO性能的测试,之后在现有环境中部分部署Btrfs,部分部署DeviceMapper,对稳定性进行比较。

大家对于打算使用的存储驱动,可以关注官方网站的bug列表,也是一个可参考的因素。

IO性能测试

使用IOzone测试工具,该工具参数多样,可灵活使用,测试各种读写,我们结合自己的场景,主要测试读的速度,主要关注文件大小在几百kKB到几MB之间的数据,仅比较Btrfs与DeviceMapper。

测试环境

宿主机配置如下:


DCOS Docker存储方式研究选型

测试1

Read(读测试),文件大小为4k到128k,以record 4k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图6 测试1

测试2

Read(读测试),文件大小为128k到8192k,以record 4k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图7 测试2

测试3

Read(读测试),文件大小为256k到16384k,以record 256k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图8 测试3

测试4

Reread(对刚读过的文件重读),文件大小为4k到128k,以record 4k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图9 测试4

测试5

Reread(对刚读过的文件重读),文件大小为128k到8192k,以record 4k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图10 测试5

测试6

Reread(对刚读过的文件重读),文件大小为256k到16384k,以record 256k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图11 测试6

测试7

Random read(随机读),文件大小为4k到128k,以record 4k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图12 测试7

测试8

Random read(随机读),文件大小为128k到8192k,以record 4k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图13 测试8

测试9

Random read(随机读),文件大小为256k到16384k,以record 256k来传输,测试结果如下图所示:

红色为Btrfs,蓝色为DeviceMapper;

横坐标为文件大小,单位为kBytes,纵坐标为传输速度,单位为kBytes/s;


DCOS Docker存储方式研究选型

图14 测试9

小结

对于我们目前打算用docker上线的pp云等服务,主要关注从几百KB到几MB大小的文件,只需考虑读,写的操作是采用挂载卷的方式,不会直接写在容器里。在读的方面,devicemapper比Btrfs性能略好。在稳定性方面的比较,由于线下的试验并不能完全模仿线上的场景,初步打算上线时一部分容器运行在devicemapper存储驱动的环境下,一部分容器运行在Btrfs存储驱动的环境下,进行观察、比较。

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

主题: DockerLinuxLinux内核开源UFAU数据性能测试2G
分页:12
转载请注明
本文标题:DCOS Docker存储方式研究选型
本站链接:http://www.codesec.net/view/481781.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(24)