首頁  >  文章  >  運維  >  docker儲存驅動程式有哪些

docker儲存驅動程式有哪些

藏色散人
藏色散人原創
2022-01-12 14:20:548144瀏覽

docker儲存驅動程式有:1、AUFS,是檔案層級的儲存驅動程式;2、Overlay,是一種Union FS;3、Device mapper,是映射框架機制;4、Btrfs,也是檔案級存儲驅動;5、ZFS,一種全新的檔案系統。

docker儲存驅動程式有哪些

本文操作環境: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教學

以上是docker儲存驅動程式有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn