docker儲存驅動有:1、AUFS,是檔案級的儲存驅動;2、Overlay,是一種Union FS;3、Device mapper,是對映框架機制;4、Btrfs,也是檔案級儲存驅動;5、ZFS,一種全新的檔案系統。
本文操作環境:Windows7系統、Docker 20.10.11版本、Dell G3電腦。
docker儲存驅動有哪些?Docker的五種儲存驅動原理及其應用場景
一、原理說明
Docker最開始採用AUFS作為檔案系統,也得益於AUFS分層的概念,實現了多個Container可以共用同一個image。但由於AUFS未併入Linux核心,且只支援Ubuntu,考慮到相容性問題,在Docker 0.7版本中引入了儲存驅動, 目前,Docker支援AUFS、Btrfs、Device mapper、OverlayFS、ZFS五種儲存驅動。就如Docker官網上說的,沒有單一的驅動適合所有的應用場景,要根據不同的場景選擇合適的儲存驅動,才能有效的提高Docker的效能。如何選擇適合的儲存驅動,要先了解儲存驅動原理才能更好的判斷,本文介紹一下Docker五種儲存驅動原理詳解及應用場景及IO效能測試的對比。在講原理前,先講一下寫時複製和寫時分配兩個技術。
1、寫時複製(CoW)
所有驅動都用到的技術——寫時複製(CoW)。CoW就是copy-on-write,表示只在需要寫時才去複製,這個是針對已有檔案的修改場景。比如基於一個image啟動多個Container,如果為每個Container都去分配一個image一樣的檔案系統,那麼將會佔用大量的磁碟空間。而CoW技術可以讓所有的容器共用image的檔案系統,所有資料都從image中讀取,只有當要對檔案進行寫操作時,才從image裡把要寫的檔案複製到自己的檔案系統進行修改。所以無論有多少個容器共用同一個image,所做的寫操作都是對從image中複製到自己的檔案系統中的複本上進行,並不會修改image的原始檔,且多個容器操作同一個檔案,會在每個容器的檔案系統裡生成一個複本,每個容器修改的都是自己的複本,相互隔離,相互不影響。使用CoW可以有效的提高磁碟的利用率。
2、用時分配(allocate-on-demand)
用時分配是用在原本沒有這個檔案的場景,只有在要新寫入一個檔案時才分配空間,這樣可以提高儲存資源的利用率。比如啟動一個容器,並不會為這個容器預分配一些磁碟空間,而是當有新檔案寫入時,才按需分配新空間。
二、五種儲存驅動基本原理
1、AUFS
AUFS(AnotherUnionFS)是一種Union FS,是檔案級的儲存驅動。AUFS能透明覆蓋一或多個現有檔案系統的層狀檔案系統,把多層合併成檔案系統的單層表示。簡單來說就是支援將不同目錄掛載到同一個虛擬檔案系統下的檔案系統。這種檔案系統可以一層一層地疊加修改檔案。無論底下有多少層都是唯讀的,只有最上層的檔案系統是可寫的。當需要修改一個檔案時,AUFS建立該檔案的一個副本,使用CoW將檔案從唯讀層複製到可寫層進行修改,結果也儲存在可寫層。在Docker中,底下的唯讀層就是image,可寫層就是Container。結構如下圖所示:
2、Overlay
Overlay是Linux核心3.18後支援的,也是一種Union FS,和AUFS的多層不同的是Overlay只有兩層:一個upper檔案系統和一個lower檔案系統,分別代表Docker的映象層和容器層。當需要修改一個檔案時,使用CoW將檔案從唯讀的lower複製到可寫的upper進行修改,結果也儲存在upper層。在Docker中,底下的唯讀層就是image,可寫層就是Container。結構如下圖所示:
3、Device mapper
Device mapper是Linux核心2.6.9後支援的,提供的一種從邏輯裝置到物理裝置的對映框架機制,在該機制下,使用者可以很方便的根據自己的需要制定實現儲存資源的管理策略。前面講的AUFS和OverlayFS都是檔案級儲存,而Device mapper是塊級儲存,所有的操作都是直接對塊進行操作,而不是檔案。Device mapper驅動會先在塊裝置上建立一個資源池,然後在資源池上建立一個帶有檔案系統的基本裝置,所有映象都是這個基本裝置的快照,而容器則是映象的快照。所以在容器裡看到檔案系統是資源池上基本裝置的檔案系統的快照,並不有為容器分配空間。當要寫入一個新檔案時,在容器的映象內為其分配新的塊並寫入資料,這個叫用時分配。當要修改已有檔案時,再使用CoW為容器快照分配塊空間,將要修改的資料複製到在容器快照中新的塊裡再進行修改。Device mapper 驅動預設會建立一個100G的檔案包含映象和容器。每一個容器被限制在10G大小的卷內,可以自己設定調整。結構如下圖所示:
4、Btrfs
Btrfs被稱為下一代寫時複製檔案系統,併入Linux核心,也是檔案級儲存驅動,但可以像Device mapper一直接操作底層裝置。Btrfs把檔案系統的一部分設定為一個完整的子檔案系統,稱之為subvolume 。採用 subvolume,一個大的檔案系統可以被劃分為多個子檔案系統,這些子檔案系統共用底層的裝置空間,在需要磁碟空間時便從底層裝置中分配,類似應用程式呼叫 malloc()分配記憶體一樣。為了靈活利用裝置空間,Btrfs 將磁碟空間劃分為多個chunk 。每個chunk可以使用不同的磁碟空間分配策略。比如某些chunk只存放metadata,某些chunk只存放資料。這種模型有很多優點,比如Btrfs支援動態新增裝置。使用者在系統中增加新的磁碟之後,可以使用Btrfs的命令將該裝置新增到檔案系統中。Btrfs把一個大的檔案系統當成一個資源池,設定成多個完整的子檔案系統,還可以往資源池裡加新的子檔案系統,而基礎映象則是子檔案系統的快照,每個子映象和容器都有自己的快照,這些快照則都是subvolume的快照。
當寫入一個新檔案時,在容器的快照裡為其分配一個新的資料塊,檔案寫在這個空間裡,這個叫用時分配。而當要修改已有檔案時,使用CoW複製分配一個新的原始資料和快照,在這個新分配的空間變更資料,變結束再更新相關的資料結構指向新子檔案系統和快照,原來的原始資料和快照沒有指標指向,被覆蓋。
5、ZFS
ZFS 檔案系統是一個革命性的全新的檔案系統,它從根本上改變了檔案系統的管理方式,ZFS 完全拋棄了「卷管理」,不再建立虛擬的卷,而是把所有裝置集中到一個儲存池中來進行管理,用「儲存池」的概念來管理物理儲存空間。過去,檔案系統都是構建在物理裝置之上的。為了管理這些物理裝置,併為資料提供冗餘,「卷管理」的概念提供了一個單裝置的映像。而ZFS建立在虛擬的,被稱為「zpools」的儲存池之上。每個儲存池由若干虛擬裝置(virtual devices,vdevs)組成。這些虛擬裝置可以是原始磁碟,也可能是一個RAID1映象裝置,或是非標準RAID等級的多磁碟組。於是zpool上的檔案系統可以使用這些虛擬裝置的總儲存容量。
下面看一下在Docker裡ZFS的使用。首先從zpool裡分配一個ZFS檔案系統給映象的基礎層,而其他映象層則是這個ZFS檔案系統快照的克隆,快照是唯讀的,而克隆是可寫的,當容器啟動時則在映象的最頂層生成一個可寫層。如下圖所示:
當要寫一個新檔案時,使用按需分配,一個新的資料快從zpool裡生成,新的資料寫入這個塊,而這個新空間存於容器(ZFS的克隆)裡。當要修改一個已存在的檔案時,使用寫時複製,分配一個新空間並把原始資料複製到新空間完成修改。
三、儲存驅動對比及適應場景
1、AUFS VS Overlay
AUFS和Overlay都是聯合檔案系統,但AUFS有多層,而Overlay只有兩層,所以在做寫時複製操作時,如果檔案比較大且存在比較低的層,則AUSF可能會慢一些。而且Overlay併入了linux kernel mainline,AUFS沒有,所以可能會比AUFS快。但Overlay還太年輕,要謹慎在生產使用。而AUFS做為docker的第一個儲存驅動,已經有很長的歷史,比較的穩定,且在大量的生產中實踐過,有較強的社群支援。目前開源的DC/OS指定使用Overlay。
2、Overlay VS Device mapper
Overlay是檔案級儲存,Device mapper是塊級儲存,當檔案特別大而修改的內容很小,Overlay不管修改的內容大小都會複製整個檔案,對大檔案進行修改顯示要比小檔案要消耗更多的時間,而塊級無論是大檔案還是小檔案都只複製需要修改的塊,並不是整個檔案,在這種場景下,顯然device mapper要快一些。因為塊級的是直接存取邏輯盤,適合IO密集的場景。而對於程式內部複雜,大並行但少IO的場景,Overlay的效能相對要強一些。
3、Device mapper VS Btrfs Driver VS ZFS
Device mapper和Btrfs都是直接對塊操作,都不支援共用儲存,表示當有多個容器讀同一個檔案時,需要生活多個複本,所以這種儲存驅動不適合在高密度容器的PaaS平臺上使用。而且在很多容器啟停的情況下可能會導致磁碟溢位,造成主機不能工作。Device mapper不建議在生產使用,Btrfs在docker build可以很高效。
ZFS最初是為擁有大量記憶體的Salaris伺服器設計的,所以在使用時對記憶體會有影響,適合記憶體大的環境。ZFS的COW使碎片化問題更加嚴重,對於順序寫生成的大檔案,如果以後隨機的對其中的一部分進行了更改,那麼這個檔案在硬碟上的實體地址就變得不再連續,未來的順序讀會變得效能比較差。ZFS支援多個容器共用一個快取塊,適合PaaS和高密度的使用者場景。
推薦學習:《》
以上就是docker儲存驅動有哪些的詳細內容,更多請關注TW511.COM其它相關文章!