【Docker】浅谈Docker之AUFS、BTRFS、ZFS、Container、分层的概念-Toy模板网

这篇具有很好参考价值的文章主要介绍了【Docker】浅谈Docker之AUFS、BTRFS、ZFS、Container、分层的概念。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

作者简介： 辭七七，目前大一，正在学习C/C++，Java，Python等
作者主页： 七七的个人主页
文章收录专栏： 七七的闲谈
欢迎大家点赞 👍 收藏 ⭐ 加关注哦！💖💖

【Docker】浅谈Docker之AUFS、BTRFS、ZFS、Container、分层的概念

Docker对container的使用基本是建立在LXC基础之上的，然而LXC存在的问题是难以移动 - 难以通过标准化的模板制作、重建、复制和移动 container。
在以VM为基础的虚拟化手段中，有image和snapshot可以用于VM的复制、重建以及移动的功能。想要通过container来实现快速的大规模部署和更新, 这些功能不可或缺。
Docker 正是利用AUFS来实现对container的快速更新 - 在docker0.7中引入了storage driver, 支持AUFS, VFS, device mapper, 也为BTRFS以及ZFS引入提供了可能。

1. AUFS介绍

AUFS (AnotherUnionFS) 是一种 Union FS, 简单来说就是支持将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)的文件系统, 更进一步地, AUFS支持为每一个成员目录(AKA branch)设定’readonly’, ‘readwrite’ 和 ‘whiteout-able’ 权限, 同时AUFS里有一个类似

2. BTRFS

BTRFS（通常念成Butter FS），由Oracle于2007年宣布并进行中的COW(copy-on-write式)文件系统。目标是取代Linuxext3文件系统，改善ext3的限制，特别是单一文件大小的限制，总文件系统大小限制以及加入文件校验和特性。加入ext3/4未支持的一些功能，例如可写的磁盘快照(snapshots)，以及支持递归的快照(snapshots of snapshots)，内建磁盘阵列（RAID）支持，支持子卷(Subvolumes)的概念，允许在线调整文件系统大小。

2.1 系统介绍

Btrfs宣称专注在“容错、修复与易于管理”。
Btrfs已在2010年7月推出的openSUSE11.3中得到了应用.
Btrfs也已在2010年10月推出的ubuntu10.10中得到了应用.
2011年6月8日，在Fedora工程指导委员会会议上，委员会决定Fedora 16将以Btrfs作为默认文件系统.
2011年8月9日， Fedora撤回了决定，Btrfs不再作为Fedora 16默认文件系统，原因是时间不充足，无法达到改变默认文件系统所要满足的基本要求。
2011年10月5日，Fedora 16测试版发布，BTRFS 将做为其默认文件系统。
2011年11月8日，Fedora 16正式版发布，默认文件系统依然采用ext4，并未采用预计的Btrfs文件系统。
2020年8月24日，Btrfs将取代ext4作为Fedora 33中的默认文件系统。

2.2 特性

首先是扩展性 (scalability) 相关的特性，btrfs 最重要的设计目标是应对大型机器对文件系统的扩展性要求。 Extent，B-Tree 和动态 inode 创建等特性保证了 btrfs 在大型机器上仍有卓越的表现，其整体性能而不会随着系统容量的增加而降低。
其次是数据一致性 (data integrity) 相关的特性。系统面临不可预料的硬件故障，Btrfs 采用 COW 事务技术来保证文件系统的一致性。 btrfs 还支持 checksum，避免了 silent corrupt 的出现。而传统文件系统则无法做到这一点。
第三是和多设备管理相关的特性。 Btrfs 支持创建快照 (snapshot)，和克隆 (clone) 。 btrfs 还能够方便的管理多个物理设备，使得传统的卷管理软件变得多余。
最后是其他难以归类的特性。这些特性都是比较先进的技术，能够显著提高文件系统的时间 / 空间性能，包括延迟分配，小文件的存储优化，目录索引等。

2.3 优化支持

SSD 是固态存储 Solid State Disk 的简称。在过去的几十年中，CPU/RAM 等器件的发展始终遵循着摩尔定律，但硬盘 HDD 的读写速率却始终没有飞跃式的发展。磁盘 IO 始终是系统性能的瓶颈。
SSD 采用 flash memory 技术，内部没有磁盘磁头等机械装置，读写速率大幅度提升。 flash memory 有一些不同于 HDD 的特性。 flash 在写数据之前必须先执行擦除操作；其次，flash 对擦除操作的次数有一定的限制，在技术水平下，对同一个数据单元最多能进行约 10 万次擦除操作，因此，为了延长 flash 的寿命，应该将写操作平均到整个 flash 上。
SSD 在硬件内部的微代码中实现了 wear leveling 等分布写操作的技术，因此系统无须再使用特殊的 MTD 驱动和 FTL 层。虽然 SSD 在硬件层面做了很多努力，但毕竟还是有限。文件系统针对 SSD 的特性做优化不仅能提高 SSD 的使用寿命，而且能提高读写性能。 Btrfs 是少数专门对 SSD 进行优化的文件系统。 btrfs 用户可以使用 mount 参数打开对 SSD 的特殊优化处理。
Btrfs 的 COW 技术从根本上避免了对同一个物理单元的反复写操作。如果用户打开了 SSD 优化选项，btrfs 将在底层的块空间分配策略上进行优化：将多次磁盘空间分配请求聚合成一个大小为 2M 的连续的块。大块连续地址的 IO 能够让固化在 SSD 内部的微代码更好的进行读写优化，从而提高 IO 性能。

3. ZFS

ZFS文件系统的英文名称为Zettabyte File System,也叫动态文件系统（Dynamic File System）,是第一个128位文件系统。最初是由Sun公司为Solaris 10操作系统开发的文件系统。作为OpenSolaris开源计划的一部分，ZFS于2005年11月发布，被Sun称为是终极文件系统，经历了 10 年的活跃开发。而最新的开发将全面开放，并重新命名为 OpenZFS

3.1 历史

ZFS的设计与开发由Sun公司的Jeff Bonwick所领导的一支团队完成。最早宣布于2004年9月14日，于2005年10月31日并入了Solaris开发的主干源代码。并在2005年11月16日作为OpenSolaris build 27的一部分发布。Sun在OpenSolaris社区开张1年后的2006年六月，将ZFS集成进了Solaris 10 6/06版本更新。
ZFS的命名来源发想于"ZettabyteFile System"的首字母缩写。但 ZFS 本身并不具备任何的缩写意涵，只是作者想阐述做为一个具备高扩充容量文件系统且还有支持许多延伸功能的一个产品。

3.2 文件介绍

ZFS是一款128bit文件系统，总容量是现有64bit文件系统的1.84x10^{19倍，其支持的单个存储卷容量达到16EiB（2}64byte，即 16x1024x1024TB）；一个zpool存储池可以拥有2^{64个卷，总容量最大256ZiB（2}78byte）；整个系统又可以拥有2^64个存储池。可以说在相当长的未来时间内，ZFS几乎不太可能出现存储空间不足的问题。另外，它还拥有自优化，自动校验数据完整性，存储池/卷系统易管理等诸多优点。较ext3系统有较大运行速率，提高大约30%-40%。
ZFS是基于存储池的，与典型的映射物理存储设备的传统文件系统不同，ZFS所有在存储池中的文件系统都可以使用存储池的资源。

3.3 什么是ZFS

ZFS 文件系统是一个革命性的全新的文件系统，它从根本上改变了文件系统的管理方式，这个文件系统的特色和其带来的好处至今没有其他文件系统可以与之媲美，ZFS 被设计成强大的、可升级并易于管理的。
ZFS 用“存储池”的概念来管理物理存储空间。过去，文件系统都是构建在物理设备之上的。为了管理这些物理设备，并为数据提供冗余，“卷管理”的概念提供了一个单设备的映像。但是这种设计增加了复杂性，同时根本没法使文件系统向更高层次发展，因为文件系统不能跨越数据的物理位置。
ZFS 完全抛弃了“卷管理”，不再创建虚拟的卷，而是把所有设备集中到一个存储池中来进行管理！“存储池”描述了存储的物理特征（设备的布局，数据的冗余等等），并扮演一个能够创建文件系统的专门存储空间。从此，文件系统不再局限于单独的物理设备，而且文件系统还允许物理设备把他们自带的那些文件系统共享到这个“池”中。你也不再需要预先规划好文件系统的大小，因为文件系统可以在“池”的空间内自动的增大。当增加新的存贮介质时，所有“池”中的所有文件系统能立即使用新增的空间，而不需要额外的操作。在很多情况下，存储池扮演了一个虚拟内存。
ZFS使用一种写时拷贝事务模型技术。所有文件系统中的块指针都包括256位的能在读时被重新校验的关于目标块的校验和。含有活动数据的块从来不被覆盖；而是分配一个新块，并把修改过的数据写在新块上。所有与该块相关的元数据块都被重新读、分配和重写。为了减少该过程的开销，多次读写更新被归纳为一个事件组，并且在必要的时候使用日志来同步写操作。
利用写时拷贝使ZFS的快照和事物功能的实现变得更简单和自然，快照功能更灵活。缺点是，COW使碎片化问题更加严重，对于顺序写生成的大文件，如果以后随机的对其中的一部分进行了更改，那么这个文件在硬盘上的物理地址就变得不再连续，未来的顺序读会变得性能比较差。

4. 分层的概念

对 readonly 权限的branch可以逻辑上进行修改(增量地, 不影响readonly部分的)。通常 Union FS有两个用途, 一方面可以实现不借助 LVM， RAID 将多个disk和挂在到一个目录下, 另一个更常用的就是将一个readonly的branch和一个writeable的branch联合在一起，Live CD正是基于此可以允许在 OS image 不变的基础上允许用户在其上进行一些写操作。Docker在AUFS上构建的container image也正是如此，接下来从启动container中的linux为例介绍docker在AUFS特性的运用。

典型的Linux启动到运行需要两个FS - bootfs + rootfs (从功能角度而非文件系统角度)
bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引导加载kernel, 当boot成功后 kernel 被加载到内存中后 bootfs就被umount了.
rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev, /proc, /bin, /etc 等标准目录和文件。
由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs 如下：
典型的Linux在启动后，首先将 rootfs 置为 readonly, 进行一系列检查, 然后将其切换为 “readwrite” 供用户使用。在docker中，起初也是将 rootfs 以readonly方式加载并检查，然而接下来利用 union mount 的将一个 readwrite 文件系统挂载在 readonly 的rootfs之上，并且允许再次将下层的 file system设定为readonly 并且向上叠加, 这样一组readonly和一个writeable的结构构成一个container的运行目录, 每一个被称作一个Layer。如下：
得益于AUFS的特性, 每一个对readonly层文件/目录的修改都只会存在于上层的writeable层中。这样由于不存在竞争, 多个container可以共享readonly的layer。
所以docker将readonly的层称作 “image” - 对于container而言整个rootfs都是read-write的，但事实上所有的修改都写入最上层的writeable层中,
image不保存用户状态，可以用于模板、重建和复制。
上层的image依赖下层的image，因此docker中把下层的image称作父image，没有父image的image称作base image

5. docker概念上的Container

想要从一个image启动一个container，docker会先加载其父image直到base image，用户的进程运行在writeable的layer中。所有parent image中的数据信息以及ID、网络和lxc管理的资源限制等具体container的配置，构成一个docker概念上的container。

由此可见，采用AUFS作为docker的container的文件系统，能够提供如下好处：

节省存储空间 - 多个container可以共享base image存储
快速部署 - 如果要部署多个container，base image可以避免多次拷贝
内存更省 - 因为多个container共享base image, 以及OS的disk缓存机制，多个container中的进程命中缓存内容的几率大大增加
升级更方便 - 相比于 copy-on-write 类型的FS，base-image也是可以挂载为可writeable的，可以通过更新base image而一次性更新其之上的container
允许在不更改base-image的同时修改其目录中的文件 - 所有写操作都发生在最上层的writeable层中，这样可以大大增加base image能共享的文件内容。

以上5条 1-3 条可以通过 copy-on-write 的FS实现, 4可以利用其他的union mount方式实现, 5只有AUFS实现的很好。这也是为什么Docker一开始就建立在AUFS之上。
由于AUFS并不会进入linux主干 (According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount.),
同时要求kernel版本3.0以上(docker推荐3.8及以上)，因此在RedHat工程师的帮助下在docker0.7版本中实现了driver机制, AUFS只是其中的一个driver, 在RHEL中采用的则是Device Mapper的方式实现的container文件系统。