用P2P方法快速分發Docker鏡像


在部署較大的容器應用集群時,把應用鏡像發布到所有節點常常需要大量時間。我們VMware的研發團隊測試了P2P的方法,能夠較好地解決大規模鏡像分發的問題,為運維實踐提供了很好的指引。

概述

在使用Docker運行容器化應用時,宿主機通常先要從Registry服務(如Docker Hub)下載相應的鏡像(image)。這種鏡像機制在開發環境中使用還是很有效的,團隊成員之間可以很方便地共享同樣的鏡像。在實際的生產環境中,從效率和安全角度,往往會部署私有的Registry服務,專供產線機器集群使用。當大量主機需要同時從Registry下載鏡像運行容器應用時(比如發布新版本,打補釘等情形),Registry 服務往往會成為鏡像分發的瓶頸,應用鏡像需要較長時間才能傳送到所有主機上,使得應用發布的周期大大延長。不少用戶采取了預先下載鏡像的方法,讓各節點事先分批獲取鏡像,然后在預定時刻統一啟動應用。這種辦法在一定程度上緩解了問題,但實質上並沒有解決Registry分發的瓶頸。

為了解決這個問題,我們着手設計實現了一種利用Bit Torrent協議來加速鏡像分發的系統(Decentralized Image Distribution,DID),其主要思路是允許在不同的host之間共享鏡像,形成分布式的P2P下載網絡,提高網絡吞吐量。通過測試,我們驗證了該系統在集群節點數目較多、鏡像較大的情況下具有較大的性能優勢。

架構

圖片描述

圖1 DID系統架構


管理界面Admin Console 
管理員可以通過Admin Console定義下發鏡像的任務(如集群的大小、機器的IP地址、鏡像URL等),並且可實時了解任務的完成情況。

控制器 
控制器是DID系統的核心組件,控制鏡像分發的整個過程。當接收到來自Admin Console的鏡像分發任務之后,控制器完成鏡像的准備工作,並將具體的鏡像下載任務下發給各個節點的客戶端代理。

客戶端代理 
客戶端代理部署在集群的每個節點中,配合控制器的調度,完成整個鏡像的分發過程。代理接收來自控制器的鏡像下載任務,調用BT客戶端下載鏡像,並最終將鏡像導入到Docker daemon中。

BT客戶端 
部署在集群節點的BT客戶端和部署在控制器中的BT客戶端以及Tracker共同組成了一個完整的P2P文件傳輸系統。在整個鏡像的分發過程中,它們利用BT協議完成鏡像下載。

BT Tracker 
Tracker是BT系統的一部分,它存儲了BT客戶端下載過程中所需要的元數據信息,並協助各個BT客戶端完成整個通信過程。

鏡像分發原理 
當用戶通過Admin Console向DID系統提交一個鏡像分發任務(Job)之后,控制器會進行以下處理:

❶ 通過本地的Docker Daemon REST API從Registry下載鏡像到本地鏡像倉庫; 
❷ 調用Docker Daemon API從鏡像倉庫導出(export)鏡像文件(鏡像tar文件); 
❸ 從鏡像tar文件中抽取出組成鏡像的所有layer並進行壓縮; 
❹ 為每一個壓縮后的layer制作BT種子文件; 
❺ 啟動BT客戶端載入所有壓縮后的layer和相應的種子文件,此時控制器所在節點的BT客戶端將成為一個Seeder; 
❻ 向各個客戶端代理發送該鏡像的下載任務。任務說明中包含了組成該鏡像的所有layer的ID和其對應的種子文件的URL。

在客戶端代理接收到來自控制器的鏡像下載任務后會進行以下處理:

❶ 針對該鏡像的每一個layer,通過調用檢查其在本地是否已存在,把不存在的layer ID加入到待下載列表中; 
❷ 對下載列表中的layer,下載對應的種子文件,並啟動BT客戶端完成layer文件的下載; 
❸ 通過Docker daemon的API將下載完成的layer文件導入到Docker daemon中; 
❹ 重復步驟2和步驟3直到所有待下載layer全部被導入到Docker daemon中。注:每個layer的下載過程是並發執行的。

由於Docker的鏡像是按照layer存儲的,不同的鏡像可共享layer,這種機制不僅減少了對存儲的消耗,而且下載鏡像時只需要下載缺少的layer即可,從而也就減少了鏡像的下載時間。在上述DID的鏡像分發過程中,我們將鏡像拆分為多個layer利用BT協議進行傳輸。另外,由於BT協議原本是為因特網上的文件分發而設計的,有部分設計並不適用於局域網鏡像集中分發的場景。比如,在BT下載過程中,每個客戶端都會維護一個參與下載該文件的peer列表,默認情況下每隔1800秒BT客戶端才會與Tracker進行一次通信來更新。在DID的設計中將這一時間修改為了1秒,以便各個節點的BT客戶端可更快地獲取其他peer的信息。

實驗環境及結果

由於測試環境的限制,我們搭建了一個由10台物理機組成,每台物理機上又部署了10台虛擬機的實驗環境來模擬擁有100個節點的集群場景。10台物理機連接在1Gbps的以太網交換機上。每台虛擬機都配置了2個vCPU、4GB內存和一塊500GB的硬盤。

第一組實驗用來比較在節點數目一定(如100個節點)的集群中,不同鏡像大小對下載過程的影響。實驗結果如圖2所示,圖中縱軸的Propagation Time是從整個集群開始下載鏡像到所有節點將鏡像導入所用的時間:

圖片描述

圖2 Docker、DID鏡像分發時間對比

從測試結果可以看出兩點規律。一是Docker和DID的下載時間都隨着鏡像的增大而增大,但是DID的增長斜率較小。而且隨着鏡像的增大,DID的優勢表現得越來越明顯,例如,在鏡像超過500MB后,DID所需的時間不到Docker的一半。二是存在這樣的一個平衡點,當鏡像小於該值時,Docker的下載速度會更快,這是由於Docker的直接下載方式在此時並未造成太多的網絡擁堵。另外在用BT協議下載的過程中,BT客戶端同Tracker之間以及客戶端之間需要不斷的進行通信,本身控制流量也有一定程度的消耗。上圖中,當鏡像增大到130MB以上時,BT協議帶來的額外開銷可以通過網絡的節省來彌補,因而總體性能提升。

既然兩種方式各有利弊,我們做了第二組實驗來研究Docker和DID之間性能的平衡點。當Docker和DID在同一個集群中分發相同鏡像所消耗的時間相等時,此時的集群節點數和鏡像大小即稱為一個平衡點。實驗結果如圖3所示:

圖片描述

圖3 Docker和DID的平衡點

從實驗結果中可以看出,隨着集群節點數目的不斷增大,達到平衡點所需要的鏡像大小是在不斷降低的。也就是說DID在集群節點數目較大、鏡像較大的場景中性能優勢最為明顯。

我們所設計和實現的DID鏡像發布機制,利用了BT協議完成鏡像的分發過程,相對於Docker自身的下載方式而言,在大負荷的場景下具有較為明顯的優勢。原生的BT協議並不完全適應於鏡像分發的使用場景,DID已經對其進行了部分優化。但是,我們相信可以調整的地方還有很多,優化之后性能應該還會有一定程度的提高。

關於鏡像P2P的傳輸是個熱門話題,目前這方面的測試數據很少。我們的測試結果可作為今后研發類似系統的基礎。例如,在我們團隊已經開源的企業級Registry項目Harbor中,不僅提供了完整的用戶權限控制(RBAC)和友好的用戶管理界面,還計划使用P2P的傳輸方式來增強鏡像發布效率,為生產環境中快速發布容器應用提供有力的支持。歡迎大家關注和使用Harbor開源Registry項目:

https://github.com/vmware/harbor



注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com