Docker 存儲(chǔ)選型這些年我們遇到的坑

-19-Docker存儲(chǔ)選型，這些年我們遇到的坑隨著Docker容器技術(shù)的不斷進(jìn)展和業(yè)內(nèi)對Docker的使用不斷深化，大家已經(jīng)不再滿意于對Docker的基本使用。把玩Docker多年的老司機(jī)應(yīng)當(dāng)或多或少都會(huì)遇到過一些Docker存儲(chǔ)方面的問題，比如由于宿主機(jī)文件系統(tǒng)和Docker存儲(chǔ)類型不兼容引起的問題，或者使用AUFS消失文件復(fù)制慢等問題，存儲(chǔ)問題每次遇到都要心里一緊。

隨著Docker容器技術(shù)的不斷進(jìn)展和業(yè)內(nèi)對Docker的使用不斷深化，大家已經(jīng)不再滿意于對Docker的基本使用。把玩Docker多年的老司機(jī)應(yīng)當(dāng)或多或少都會(huì)遇到過一些Docker存儲(chǔ)方面的問題，比如由于宿主機(jī)文件系統(tǒng)和Docker存儲(chǔ)類型不兼容引起的問題，或者使用AUFS消失文件復(fù)制慢等問題，存儲(chǔ)問題每次遇到都要心里一緊。

Docker存儲(chǔ)類的問題在排查上往往比較簡單，有過Docker存儲(chǔ)類問題排查閱歷的同學(xué)應(yīng)當(dāng)都有體會(huì)。每當(dāng)遇到此類的問題筆都有一股想找Docker公司理論的沖動(dòng)，不是說好的'buildoncerunanywhere'嗎？

筆者自己所在的團(tuán)隊(duì)也曾數(shù)次遇到關(guān)于Docker存儲(chǔ)的問題，每次團(tuán)隊(duì)內(nèi)的成員基本都是避之不及，生怕會(huì)由自己處理(怕掉坑里)。為此筆者特地理了一下Docker存儲(chǔ)類的問題的簡單點(diǎn)，發(fā)覺這里面很大一部分其實(shí)是由于問題處理人員對Docker的存儲(chǔ)類型、存儲(chǔ)原理不了解造成的，為此我們特地整理了一份Docker選型方面的避坑指南，供大家參考，盼望可以關(guān)心到大家。

Docker存儲(chǔ)概述

我們知道，每個(gè)Docker容器里面都有一個(gè)自己的文件系統(tǒng)，Docker在運(yùn)行容器時(shí)需要進(jìn)行文件系統(tǒng)的創(chuàng)建，這樣rootfs才能進(jìn)行掛載。

Bootfs也稱引導(dǎo)文件系統(tǒng)，位于Docker鏡像和Docker容器的最底層。bootfs中主要包含兩個(gè)部分：bootloader和kernel，bootloader用于引導(dǎo)加載內(nèi)核，當(dāng)內(nèi)核加載到內(nèi)存中后bootfs的使命就完成了，接下來bootfs會(huì)被卸載掉。rootfs中包含了一些linux中標(biāo)準(zhǔn)的名目和文件，包括：/dev/設(shè)備文件名目、/proc/進(jìn)程信息名目、/bin/二進(jìn)制文件名目、/etc/配置文件名目等。

眾所周知，Docker存儲(chǔ)的核心是鏡像的分層機(jī)制，鏡像分層的一大好處是鏡像之間可以進(jìn)行繼承，也正是由于這個(gè)特性我們可以借助基鏡像定制化的構(gòu)建我們需要的應(yīng)用鏡像。

Docker官方在版本1.10時(shí)引入一個(gè)新的可尋址的存儲(chǔ)模型，了解過Docker存儲(chǔ)這方面的同學(xué)應(yīng)當(dāng)知道在Docker1.10之前Docker鏡像的管理是使用的隨機(jī)的UUID管理，Docker1.10之后已經(jīng)使用平安內(nèi)容hash取代了隨機(jī)UUID進(jìn)行鏡像的管理。同時(shí)，考慮到已經(jīng)有許多用戶在使用UUID的鏡像管理方式，Docker官方特地針對這個(gè)改動(dòng)供應(yīng)了遷移工具，關(guān)心大家將已經(jīng)存在的鏡像遷移到新的模型之上。

我們知道，一個(gè)有眾多版本的鏡像的全部鏡像占據(jù)的空間可能比單個(gè)版本的鏡像占用的空間多不了多少(比如一個(gè)nginx鏡像有500MB，依據(jù)配置的不同我們保存了10個(gè)版本，10個(gè)版本占用的空間一般和一個(gè)nginx鏡像占用的空間接近，遠(yuǎn)低于10個(gè)鏡像空間的總和)。多個(gè)版本占用的空間之所以沒有明顯增加是由于Docker容器、鏡像可以共享底層的基礎(chǔ)文件系統(tǒng)層，雖然鏡像的個(gè)數(shù)許多，但是他們占據(jù)的共享鏡像層在磁盤中只存在一份，每個(gè)容器只需要在自己的最上層加上一個(gè)自己獨(dú)有的可讀可寫層就可以正常使用了，由于這種存儲(chǔ)機(jī)制的存在大大提高了Docker鏡像存儲(chǔ)的效率。這種模式的主要機(jī)制就是分層模型將不同的名目掛載到了同一個(gè)虛擬文件系統(tǒng)之上，通過下面這個(gè)圖可以很好的理解這種模式。

上文中我們提到docker的鏡像是分層的，但我們沒有說這部分的功能詳細(xì)是由哪一部分實(shí)現(xiàn)的。其實(shí)不僅分層鏡像，包括每個(gè)Docker容器的可讀寫層都是由Docker的存儲(chǔ)方式負(fù)責(zé)管理的。

接觸容器比較早的同學(xué)可能還記得，Docker在最初的時(shí)候只能在支持AUFS的文件系統(tǒng)的操作系統(tǒng)上運(yùn)行，而當(dāng)時(shí)在眾多操作系統(tǒng)中Ubuntu已經(jīng)領(lǐng)先供應(yīng)了對AUFS的支持，因此最開頭玩Docker的同學(xué)使用的linux發(fā)行版都是Ubuntu系列的發(fā)行版。

但是由于AUFS未能加入Linux內(nèi)核，成為linux發(fā)行版的標(biāo)配，因此為了尋求兼容性和擴(kuò)展性，Docker在內(nèi)部通過graphdriver這樣一種機(jī)制以一種可以擴(kuò)展的方式實(shí)現(xiàn)了對不同文件的系統(tǒng)的兼容(實(shí)際使用中可能發(fā)覺有些版本還是會(huì)存在一些兼容性的問題)。

Docker目前支持的驅(qū)動(dòng)類型包括：AUFS、Devicemapper、Btrfs、OverlayFS和ZFS(較新)，這些驅(qū)動(dòng)存在一個(gè)共同點(diǎn)，那就是都使用了寫時(shí)復(fù)制技術(shù)。下面我們逐個(gè)看下這種存儲(chǔ)驅(qū)動(dòng)的特性以及在使用中可能會(huì)遇到的問題。

AUFS存儲(chǔ)驅(qū)動(dòng)

1.UnionFileSystem

UnionFS(UnionFileSystem簡稱)是一種為Linux、FreeBSD等操作系統(tǒng)而設(shè)計(jì)的，可以把其他文件系統(tǒng)聯(lián)合到一個(gè)掛載點(diǎn)的文件系統(tǒng)服務(wù)。

簡潔說來聯(lián)合文件系統(tǒng)就是將不同的名目掛載到同一個(gè)虛擬機(jī)文件系統(tǒng)下的文件系統(tǒng)。這種文件系統(tǒng)的一大特點(diǎn)就是可以一層層的疊加修改文件，除了最上面的一層之外無論底下有多少層都是只讀的，只有最上層的文件系統(tǒng)是可以寫的。

UnionFS使用分支(branch)對不同文件系統(tǒng)的文件(包含名目)進(jìn)行掩蓋，從而最終形成一個(gè)單一的文件系統(tǒng)，也就是我們直接操縱的文件系統(tǒng)。UnionFS使用的這些分支要么是只讀的，要么是讀寫的，分支的這種特性打算了當(dāng)我們對虛擬后的聯(lián)合文件系統(tǒng)中寫入數(shù)據(jù)的時(shí)候，數(shù)據(jù)被寫到了一個(gè)新的文件中。這樣看來我們好像可以操作這個(gè)虛擬文件系統(tǒng)中的任何的文件，但其實(shí)我們并未轉(zhuǎn)變原來的文件，導(dǎo)致這種狀況消失的緣由是UnionFS使用了寫時(shí)復(fù)制(copy-on-write)這樣一種資源管理技術(shù)。

寫時(shí)復(fù)制也稱隱式共享(此名稱可能較少見)，寫時(shí)復(fù)制是一種可以對可修改資源實(shí)現(xiàn)高效復(fù)制的資源管理技術(shù)。它的核心的設(shè)計(jì)思想是，假如一個(gè)數(shù)據(jù)資源是重復(fù)的，沒有做過任何的修改，這個(gè)時(shí)候不需要?jiǎng)?chuàng)建新的資源，而是讓新舊實(shí)例都去共享這僅有一份的資源。當(dāng)需要對資源進(jìn)行數(shù)據(jù)的增加或者修改的時(shí)候才會(huì)進(jìn)行新資源的創(chuàng)建。從上面的寫時(shí)復(fù)制的原理中我們即可看出，通過這種資源共享的方式我們可以省掉對未修改資源的復(fù)制，從而為我們帶來效率的提升。

2.AUFS

AUFS全稱為AdvancedMulti-LayeredUnificationFilesystem，是一種聯(lián)合文件系統(tǒng)，是一種文件級的存儲(chǔ)驅(qū)動(dòng)，出于對牢靠性和性能的考慮，AUFS對UnionFS1.x進(jìn)行了整個(gè)的重寫，并且在重寫過程中還引入了一些新的功能特性，比如對于可寫的分支添加了負(fù)載均衡的功能。不僅僅是AUFS借鑒UnionFS，UnionFS也會(huì)去借鑒AUFS，比如UnionFS2.x中借鑒了AUFS的一些實(shí)現(xiàn)。

有些同學(xué)可能會(huì)問，存儲(chǔ)驅(qū)動(dòng)類型這么多，為什么Docker最開頭選擇AUFS作為自己的存儲(chǔ)驅(qū)動(dòng)？筆者個(gè)人認(rèn)為是由于AUFS具備的以下幾個(gè)優(yōu)勢：快速啟動(dòng)容器、高效利用存儲(chǔ)、高效利用內(nèi)存。

當(dāng)我們需要對一個(gè)文件進(jìn)行修改時(shí)，AUFS會(huì)為目的文件創(chuàng)建一個(gè)文件副本，詳細(xì)是從包含該文件的只讀層使用寫時(shí)復(fù)制技術(shù)將文件復(fù)制到最上面的可寫層。需要留意的是，當(dāng)我們修改完文件之后修改后的文件是保存在最上層的可寫層的，下面的只讀層的文件并未被修改。

3.Docker對AUFS的使用

在Docker體系中，我們熟知的最上層的讀寫層就是容器，除最上層之外的下面的那些層就是鏡像。

4.AUFS避坑

了解AUFS存儲(chǔ)驅(qū)動(dòng)的優(yōu)勢和劣勢可以關(guān)心我們更好的對存儲(chǔ)驅(qū)動(dòng)進(jìn)行選型，同時(shí)也可在很大程度上關(guān)心我們排查AUFS存儲(chǔ)驅(qū)動(dòng)方面相關(guān)的問題。

好，我們先看下AUFS作為Docker存儲(chǔ)驅(qū)動(dòng)的優(yōu)勢，以便選擇更合適的使用場景：

(1)得益于AUFS高效的名目掛載機(jī)制，Docker可以很快的創(chuàng)建容器。AUFS的讀寫效率很高，和直接在Docker容器所在宿主機(jī)上的讀寫接近。和虛擬服務(wù)器相比，AUFS讀寫性能優(yōu)于KVM，包括挨次讀寫和隨機(jī)讀寫兩個(gè)方面。除此磁盤的高效使用之外，Docker的AUFS存儲(chǔ)驅(qū)動(dòng)也可以對內(nèi)存進(jìn)行特別高效的使用。

(2)相比一些消失較晚的Docker存儲(chǔ)驅(qū)動(dòng)，DockerAUFS存儲(chǔ)驅(qū)動(dòng)性能相對比較穩(wěn)定，并且AUFS目前已經(jīng)有許多的生產(chǎn)部署實(shí)踐，另外AUFS在社區(qū)生態(tài)方面也得到大量的支持。

下面我們再看下AUFS作為Docker存儲(chǔ)驅(qū)動(dòng)存在的坑：

(1)AUFS是Docker第一個(gè)支持的存儲(chǔ)驅(qū)動(dòng)，但AUFS目前仍未加入linux系統(tǒng)的內(nèi)核主線，比如RedHat系列(包括CentOS)目前還無法直接使用AUFS。

(2)AUFS目前不支持重命名的系統(tǒng)調(diào)用，這個(gè)會(huì)導(dǎo)致我們在執(zhí)行拷貝和解除連接時(shí)失敗。

(3)我們知道AUFS文件系統(tǒng)中每個(gè)源名目都會(huì)對應(yīng)一個(gè)分支文件的掛載過程其實(shí)就是對不同分支的一個(gè)聯(lián)合操作，當(dāng)消失相同內(nèi)容的不同分支時(shí)會(huì)進(jìn)行上下層的掩蓋。但是當(dāng)我們寫入大文件的時(shí)候，比如大的存儲(chǔ)日志信息的文件或者存儲(chǔ)數(shù)據(jù)庫數(shù)據(jù)庫的文件，動(dòng)態(tài)掛載多個(gè)路徑的存在會(huì)使分支越來越多，進(jìn)而會(huì)導(dǎo)致文件查找的性能越來越差，尤其是當(dāng)文件存在于較低的層時(shí)，問題會(huì)更加嚴(yán)峻。

小結(jié)：AUFS存儲(chǔ)驅(qū)動(dòng)建議在大并發(fā)但少I/O的場景下進(jìn)行使用。

Devicemapper

1.DeviceMapper原理

部署Docker環(huán)境的時(shí)候一般都會(huì)要求Linux內(nèi)核版本最低為3.10，好像Docker運(yùn)行需要的存儲(chǔ)驅(qū)動(dòng)是從linux內(nèi)核3.10這個(gè)版本才進(jìn)行引入的，但實(shí)際早在linux內(nèi)核版本2.6的時(shí)候DeviceMapper就已經(jīng)被引入。

DeviceMapper作為內(nèi)核的一部分主要供應(yīng)了規(guī)律卷管理和通用設(shè)備映射的功能，為了實(shí)現(xiàn)系統(tǒng)中的塊設(shè)備管理供應(yīng)了一個(gè)高度模塊化的內(nèi)核的架構(gòu)。

在深化了解DeviceMapper之前我們需要先了解下DeviceMapper中三個(gè)比較重要的概念：MappedDevice、MappingTable和TargetDevice。

MappedDevice并不是一個(gè)實(shí)際的設(shè)備，并沒有實(shí)際的物理硬件和它一一對應(yīng)，相反MappedDevice是一個(gè)規(guī)律上的抽象設(shè)備，簡潔說來，可以將其理解成為內(nèi)核向外供應(yīng)的規(guī)律設(shè)備。MappedDevice通過另一個(gè)對象MappingTable和TargetDevice建立映射關(guān)系。

MappingTable中包含MappedDevice規(guī)律的起始地址、地址范圍以及TargetDevice代表的物理設(shè)備的地址偏移量和Target的類型信息，需要留意的是地址和偏移量單位為扇區(qū)，即512字節(jié)。

TargetDevice簡潔說來就是MappedDevice這個(gè)規(guī)律設(shè)備所映射到的一個(gè)物理設(shè)備。

DeviceMapper是塊級別的存儲(chǔ)驅(qū)動(dòng)，全部的操作都是對存儲(chǔ)塊進(jìn)行直接的操作，這方面和上文中講的AUFS不同(AUFS是文件級的存儲(chǔ)，全部的操作都是對文件進(jìn)行直接的操作)。

在使用DeviceMapper時(shí)，DeviceMapper會(huì)先在塊設(shè)備上創(chuàng)建一個(gè)資源池，然后接下來會(huì)在新建的資源池上添加一個(gè)沒有文件系統(tǒng)的基本設(shè)備，我們?nèi)康娜萜麋R像都是這個(gè)設(shè)備的快照，我們的Docker容器是鏡像的快照。因此我們在Docker容器中看到的文件系統(tǒng)系統(tǒng)其實(shí)是DeviceMapper資源池上基本設(shè)備上的文件系統(tǒng)的快照，實(shí)際上并沒有為我們的Docker容器進(jìn)行空間的安排。

理解DeviceMapper的工作機(jī)制，還需要明白用時(shí)安排。用時(shí)安排是指，當(dāng)我們需要寫入一個(gè)文件時(shí)，我們需要為新文件安排新的存儲(chǔ)塊并，安排好存儲(chǔ)塊后才能進(jìn)行數(shù)據(jù)的寫入。

當(dāng)我們需要去修改容器中已經(jīng)存在的文件時(shí)，這個(gè)時(shí)候DeviceMapper借助寫時(shí)復(fù)制技術(shù)為容器安排存儲(chǔ)塊空間，然后DeviceMapper將需要修改的數(shù)據(jù)拷貝到容器快照中前面新建的塊里面，之后才會(huì)對文件中的數(shù)據(jù)進(jìn)行修改。

值得一提的是，DeviceMapper存儲(chǔ)驅(qū)動(dòng)默認(rèn)會(huì)創(chuàng)建一個(gè)100GB文件，包含Docker容器和Docker鏡像，需要留意的默認(rèn)狀況下每個(gè)容器的大小都被限制在10GB的卷以內(nèi)，但可以進(jìn)行自定義的設(shè)置，詳細(xì)結(jié)構(gòu)如下圖：

另外Docker存儲(chǔ)驅(qū)動(dòng)的信息可以通過命令dockerinfo或者dmsetupls進(jìn)行查看：

[root@localhost~]#dockerinfo

Containers:11

Running:0

Paused:0

Stopped:11

Images:6

ServerVersion:1.10.3

StorageDriver:devicemapper

PoolName:docker-8:3-404820673-pool

PoolBlocksize:65.54kB

BaseDeviceSize:10.74GB

BackingFilesystem:xfs

Datafile:/dev/loop0

Metadatafile:/dev/loop1

DataSpaceUsed:12.51GB

DataSpaceTotal:107.4GB

DataSpaceAvailable:82.06GB

MetadataSpaceUsed:10.18MB

MetadataSpaceTotal:2.147GB

MetadataSpaceAvailable:2.137GB

UdevSyncSupported:true

DeferredRemovalEnabled:false

DeferredDeletionEnabled:false

DeferredDeletedDeviceCount:0

Dataloopfile:/var/lib/docker/devicemapper/devicemapper/data

WARNING:Usageofloopbackdevicesisstronglydiscouragedforproductionuse.Eitheruse`storage-optdm.thinpooldev`oruse`storage-optdm.no_warn_on_loop_devices=true`tosuppressthiswarning.

Metadataloopfile:/var/lib/docker/devicemapper/devicemapper/metadata

LibraryVersion:1.02.107-RHEL7(2022-06-09)

ExecutionDriver:native-0.2

LoggingDriver:journald

Plugins:

Volume:local

Network:nullhostbridge

KernelVersion:3.10.0-327.36.1.el7.x86_64

OperatingSystem:CentOSLinux7(Core)

OSType:linux

Architecture:x86_64

NumberofDockerHooks:2

CPUs:4

TotalMemory:1.781GiB

Name:localhost.localdomain

ID:V7HM:XRBY:P6ZU:SGWK:J52L:VYOY:UK6L:TR45:YJRC:SZBS:DQRF:CFP5

WARNING:bridge-nf-call-iptablesisdisabled

WARNING:bridge-nf-call-ip6tablesisdisabled

Registries:docker.io(secure)

[root@localhost~]#dmsetupls

docker-8:3-404820673-pool(253:0)

2.DeviceMapper避坑

(1)DeviceMapper優(yōu)勢

DeviceMapper的寫時(shí)復(fù)制機(jī)制的最小操作單元為64KB，塊級無論是大文件還是小文件都只需要復(fù)制需要修改的塊，并不復(fù)制整個(gè)文件，相比aufs存儲(chǔ)驅(qū)動(dòng)和overlay存儲(chǔ)驅(qū)動(dòng)的整個(gè)文件復(fù)制DeviceMapper的效率更高。

相比上文中我們說過的AUFS存儲(chǔ)驅(qū)動(dòng)，DeviceMapper在文件系統(tǒng)兼容性方面較好，另外DeviceMapper存儲(chǔ)驅(qū)動(dòng)只需要一個(gè)文件進(jìn)行存儲(chǔ)，基本不會(huì)占用文件系統(tǒng)的inode。

(2)DeviceMapper避坑

在內(nèi)存使用方面，以DeviceMapper作為存儲(chǔ)驅(qū)動(dòng)時(shí)，啟動(dòng)多少個(gè)容器就需要復(fù)制多少份文件到內(nèi)存中，由于DeviceMapper不支持共享存儲(chǔ)，當(dāng)有多個(gè)容器需要讀同一個(gè)文件的內(nèi)容時(shí)，需要生成多個(gè)該文件的副本，在較多的容器進(jìn)行啟動(dòng)、停止的時(shí)候可能會(huì)消失磁盤溢出的狀況。因此假如是容器密度高的業(yè)務(wù)場景下盡量不要部署到單臺(tái)主機(jī)上。

每個(gè)容器每次在寫數(shù)據(jù)時(shí)都需要占用一個(gè)新的塊，由于每個(gè)存儲(chǔ)塊都需要借助存儲(chǔ)池進(jìn)行安排，且寫的文件比較稀疏，盡管DeviceMapper的I/O利用率很高，但由于額外增加了VFS開銷導(dǎo)致性能不好。在選擇存儲(chǔ)類型時(shí)需要著重留意下這一點(diǎn)，劇烈建議依據(jù)自己的業(yè)務(wù)場景進(jìn)行壓測后再進(jìn)行選擇。

在實(shí)際使用中，假如我們?yōu)槊總€(gè)容器都進(jìn)行塊設(shè)備的安排，當(dāng)啟動(dòng)多個(gè)容器時(shí)數(shù)據(jù)會(huì)從磁盤被多次加載到內(nèi)存中，因此在這種場景下時(shí)內(nèi)存消耗較大，在選型時(shí)需要留意。

當(dāng)選用的宿主機(jī)為RHEL系列(包含CentOS)時(shí)，需要留意DeviceMapper是RHEL系列下的默認(rèn)的存儲(chǔ)驅(qū)動(dòng)，配置方式分為兩種模式：loop-lvm和direct-lvm。其中l(wèi)oop-lvm是默認(rèn)的模式，loop-lvm使用操作系統(tǒng)的層面的離散文件來構(gòu)建精簡池。一般狀況下生產(chǎn)環(huán)境推舉使用direct-lvm模式，不建議使用默認(rèn)的loop-lvm模式，經(jīng)實(shí)際測試loop-lvm的性能很難達(dá)到生產(chǎn)環(huán)境的要求

小結(jié)：DeviceMapper存儲(chǔ)驅(qū)動(dòng)更適合在I/O密集的場景下進(jìn)行使用。

OverlayFS文件系統(tǒng)

1.Overlay原理

Overlay存儲(chǔ)驅(qū)動(dòng)的設(shè)計(jì)和AUFS特別相像，也是一種聯(lián)合文件系統(tǒng)，同時(shí)也是一種文件級別的存儲(chǔ)驅(qū)動(dòng)，但和AUFS不同的是Overlay只有兩層(一個(gè)是upperdir，另一個(gè)是lowerdir，從二者的名字也可看出，upperdir代表的是我們的容器層，lowerdir層代表的是我們的鏡像層)，而AUFS有多層。相比AUFSOverlay存儲(chǔ)驅(qū)動(dòng)進(jìn)入linux較晚(Linux內(nèi)核3.18之后才進(jìn)行支持)。

當(dāng)需要對文件進(jìn)行修改時(shí)，需要借助寫時(shí)復(fù)制從只讀的lowerdir層復(fù)制到可讀寫的upperdir層，然后再在upperdir層中對文件進(jìn)行修改，修改完成后的文件最終也是保存在組上面的upper層中。

2.Ovrelay避坑

在說Overlay使用之前我們先看下它的優(yōu)點(diǎn)，看下它適合的業(yè)務(wù)場景都有哪些。

(1)從性能上來看，Overlay存儲(chǔ)驅(qū)動(dòng)要比DeviceMapper更好，速度更快。在某些狀況下Overlay的速度也比Btrfs存儲(chǔ)驅(qū)動(dòng)快。由于Overlay只有兩層，AUFS有多層，因此Overlay在速度上也比AUFS要快，削減操作延時(shí)。

(2)Overlay支持頁緩存的共享，這樣在多個(gè)容器在訪問同一個(gè)文件時(shí)可以共享一個(gè)頁緩存，從而提高內(nèi)存使用效率。

下面我們再看下Overlay在使用時(shí)需要留意的問題，留意避坑。

(1)Overlay存儲(chǔ)驅(qū)動(dòng)消失較晚，目前生產(chǎn)環(huán)境部署的閱歷相對較少，實(shí)際使用中需要解決的問題可能較多。

(2)由于Overlay存儲(chǔ)驅(qū)動(dòng)是文件級的，因此在對文件進(jìn)行第一次的操作時(shí)需要將目標(biāo)文件拷貝至最上面的讀寫層。

(3)和其他的存儲(chǔ)驅(qū)動(dòng)相比，Overlay消耗inode較多(我們有個(gè)容器云曾經(jīng)消失過此種狀況)，尤其是當(dāng)我們環(huán)境中鏡像和容器較多時(shí)可能會(huì)觸發(fā)這個(gè)問題。為了解決這個(gè)問題，一般的建議方式是將名目/var/lib/docker直接掛到某個(gè)單獨(dú)的文件系統(tǒng)中，這樣在肯定程度上可以削減其他的文件對inode的占用。

上面提到的解決方式只是最常用的一種，除了這種方式，我們還有其他的解決方式，如Overlay版本更換為Overlay2，Overlay2中已經(jīng)解決了這個(gè)問題，在我們不再具體描述。

(4)除了上面說到的這些問題，Overlay還存在POSIX的標(biāo)準(zhǔn)問題。Overlay的部分操作目前還不符合POSIX的標(biāo)準(zhǔn)。

(5)最終需要留意的是Overlay不支持rename系統(tǒng)調(diào)用，因此假如涉及到'copy'、'unlink'的操作會(huì)消失失敗的狀況。

小結(jié)：Overlay存儲(chǔ)適合大并發(fā)但少I/O的場景。

Btrfs文件系統(tǒng)

1.Btrfs原理

Btrfs文件系統(tǒng)也稱B-tree文件系統(tǒng)或者B-treeFS，Btrfs是一種支持寫入復(fù)制的文件系統(tǒng)，由著名公司Oracle進(jìn)行研發(fā)，第一個(gè)穩(wěn)定版本于2022年進(jìn)行發(fā)布。Btrfs文件系統(tǒng)的目標(biāo)是取代linux中的ext3文件系統(tǒng)。

Btrfs被許多人稱為下一代的寫時(shí)復(fù)制文件系統(tǒng)，和Overlay相像也是基于文件級別的存儲(chǔ)，目前Btrfs已經(jīng)并入linux內(nèi)核。

和前面我們講到的DeviceMapper類似，Btrfs可以對底層的設(shè)備進(jìn)行直接的操作。

Btrfs中有兩個(gè)重要的概念：subvolumes和snapshots，Btrfs利用subvolumes和snapshots管理Docker鏡像和Docker容器的分層。

Subvolumes是指Btrfs文件系統(tǒng)的一部安排置，或者也可稱為Btrfs文件系統(tǒng)的子文件系統(tǒng)，借助subvlolumes我們可以將一個(gè)大的文件系統(tǒng)劃分成若干個(gè)子文件系統(tǒng)，這些子文件系統(tǒng)共享底層的設(shè)備空間，在需要磁盤空間時(shí)便從底層設(shè)備中進(jìn)行獵取，整個(gè)過程類似malloc()安排內(nèi)存空間的過程。我們在使用Btrfs文件系統(tǒng)時(shí)，通常為了比較便利的使用設(shè)備的空間，Btrfs會(huì)將磁盤空間劃分成多個(gè)塊，需要留意的是劃分的這些塊的空間安排策略可以是不同的，比如，實(shí)際使用中我們可能會(huì)將一部分的塊用來存儲(chǔ)元數(shù)據(jù)，將另一部分的塊用來存儲(chǔ)我們實(shí)際的業(yè)務(wù)數(shù)據(jù)。

Snapshots是subvolumes的一個(gè)實(shí)時(shí)讀寫拷貝，其安排單位稱為塊，一般每個(gè)塊的大小為1GB。

Btrfs文件系統(tǒng)將一個(gè)文件系統(tǒng)當(dāng)成一個(gè)資源池來進(jìn)行看待，這個(gè)資源池中會(huì)有多個(gè)子文件系統(tǒng)，我們可以動(dòng)態(tài)的往資源池中進(jìn)行子文件系統(tǒng)的添加。

2.Btrfs避坑

先看下Btrfs的優(yōu)勢和適合的業(yè)務(wù)場景。

相比我們常常使用的ext4文件系統(tǒng)，Btrfs文件系統(tǒng)在許多方面都做了改進(jìn)，比如大家熟知的支持子卷、支持快照，除了這些功能，Btrfs文件系統(tǒng)還內(nèi)置了壓縮和RAID的支持等功能。

相比傳統(tǒng)的文件系統(tǒng)，雖然Btrfs引入了許多特別棒的特性，但它存在的問題也同樣的突出。

(1)Btrfs文件系統(tǒng)未引入頁緩存共享的機(jī)制，這就導(dǎo)致Btrfs文件系統(tǒng)不適合在容器密度比較高的場景下進(jìn)行使用。由于沒有頁緩存共享，多個(gè)容器在訪問相同的文件時(shí)需要對文件緩存多次。

(2)Btrfs文件系統(tǒng)中使用的smallwrite功能導(dǎo)致整個(gè)文件系統(tǒng)存在性能瓶頸。

(3)Btrfs文件系統(tǒng)寫數(shù)據(jù)的方式是journalin