摘要：負責(zé)承載操作系統(tǒng)的分布式文件系統(tǒng)只需要使用必要的文件，而且事實上只需要下載并在本地緩存這部分必要數(shù)據(jù)。而第二項原則在于元數(shù)據(jù)即與文件存在相關(guān)的信息，而非文件內(nèi)容被優(yōu)先對待。這套鏡像隨后可進行任意分發(fā)，并被用于啟動該項任務(wù)。

隨著Docker技術(shù)的日漸火熱，一些容器相關(guān)的問題也浮出水面。本文就容器數(shù)量激增后造成的分發(fā)效率低下問題進行了探討，并提出了一種新的解決方法。發(fā)現(xiàn)問題，解決問題，正是IT技術(shù)不斷進步的真諦，小數(shù)深以為然。

容器技術(shù)令應(yīng)用程序的配置與部署工作效率極大提高，但在不同IT運維領(lǐng)域的具體提升效果卻又不盡相同。舉例來說，其在利用數(shù)據(jù)中心存儲與網(wǎng)絡(luò)容量進行容器鏡像的大規(guī)模分發(fā)時往往表現(xiàn)得比較不盡如人意。

這確實有點反直覺：容器技術(shù)一直以高效的服務(wù)運行能力與相較于虛擬機的可觀資源節(jié)約水平為人們所稱道，為什么也會存在效率低下問題？答案出在Docker鏡像的存儲與下載方式上。從傳統(tǒng)角度講，存儲在庫中的每套鏡像都必須擁有與其各層相關(guān)的全部文件，這意味著對任意主機設(shè)備上的Docker鏡像進行更新，我們就需要從該庫中下載完整的鏡像。

在面對小型Web應(yīng)用中的少量容器時，這種機制似乎構(gòu)不成什么大問題。然而我們可以設(shè)想一旦容器系統(tǒng)數(shù)量增長至數(shù)百、數(shù)千乃至數(shù)百萬之巨時，那么庫的體積就會隨著容器系統(tǒng)的增加而不斷攀升，而每一次更新所需要下載的數(shù)據(jù)量也會越來越大。與此同時，獲取Docker鏡像的下載流量也將提升至數(shù)GB，這顯然是我們所無法接受的。

像Twitter這樣的企業(yè)無疑運行有大量容器系統(tǒng)，自然也經(jīng)歷過上述困擾。這種狀況會隨著更多企業(yè)采用容器技術(shù)而變得愈發(fā)普遍，并導(dǎo)致大型容器庫的規(guī)模不斷向外擴展。

我們認為解決容器臃腫難題的可行方案之一正是名為CernVM文件系統(tǒng)（簡稱CernVM-FS）的技術(shù)成果。其由CERN(歐洲核子研究中心)開發(fā)而成，同時囊括了來自世界各地的高能物理學(xué)領(lǐng)域、特別是費米實驗室的辛勤貢獻。

CernVM-FS的作用在于幫助科學(xué)家分發(fā)每年開發(fā)出的高達2TB的軟件數(shù)據(jù)——其中一部分軟件甚至每周都需要面向數(shù)十萬臺計算機進行多次分發(fā)與上傳。CernVM-FS采用一整套獨特的索引、重復(fù)數(shù)據(jù)刪除、緩存與地理分布機制，旨在最大程度降低與每次下載相關(guān)的組件數(shù)量，同時盡可能加快必要的下載數(shù)據(jù)量。

Mesosphere與CERN目前正在探索如何將CernVM-FS同Apache Mesos加以結(jié)合，從而了解其在容器下載工作中的實際效果以及我們在大型容器環(huán)境下的處理效率。

CernVM-FS的基本構(gòu)想誕生于2008年，當時CERN的研究人員與現(xiàn)在的人們一樣因為底層硬件虛擬化的需求而開始審視容器技術(shù)，即尋求新的應(yīng)用程序部署機制。相較于創(chuàng)建鏡像或者軟件包，他們想到使用一套全局分布式文件系統(tǒng)幫助科學(xué)家們將自己的軟件一次性安裝在一臺Web服務(wù)器上，而后立足世界任意位置對其進行訪問。

作為一套分布式文件系統(tǒng)，其首要原則就是在任意時間段之內(nèi)，全部可用文件都只有一小部分接受實際訪問。舉例來說，要運行一臺Web服務(wù)器，大家只需要使用操作系統(tǒng)（例如glibc與OpenSSL）中的一部分庫。負責(zé)承載操作系統(tǒng)的分布式文件系統(tǒng)只需要使用必要的文件，而且事實上CVMFS只需要下載并在本地緩存這部分必要數(shù)據(jù)。當時研究人員們選擇了HTTP作為下載協(xié)議，從而接入其它可用Web緩存基礎(chǔ)設(shè)施（例如Akamai、CloudFront、Squid以及NGINX代理服務(wù)器等等）。

而第二項原則在于元數(shù)據(jù)（即與文件存在相關(guān)的信息，而非文件內(nèi)容）被優(yōu)先對待。一般來講，文件系統(tǒng)所承載的軟件會受到“l(fā)ibssl.so是否存在于lib32當中？抑或是存在于/lib64目錄當中？還是存在于/usr/lib32當中？”這類請求所困擾。在處理這些請求時，通用型分布式文件系統(tǒng)往往表現(xiàn)得很差。CernVM-FS則將全部元數(shù)據(jù)保存在SQlite文件當中，并將其作為常規(guī)文件進行下載與緩存。在這種情況下，數(shù)百萬計的元數(shù)據(jù)請求就能夠以本地方式進行解析，使得CernVM-FS在速度表現(xiàn)上幾乎與本地POSIX文件系統(tǒng)保持一致。

第三項原則在于，軟件只能夠在發(fā)布點處進行修改——其他一切客戶都只能在高可用性水平下實現(xiàn)只讀操作。多數(shù)此前存在的文件系統(tǒng)在設(shè)計中都無法處理CAP定理提到的權(quán)衡難題，因為這類系統(tǒng)會假定客戶的目標始終是讀取最新的可用數(shù)據(jù)版本。在這種情況下，軟件必須在應(yīng)用或者容器運行的同時保持即時性，這意味著運行過程中該文件系統(tǒng)必須交付單一快照。

有鑒于此，CERN決定使用內(nèi)容可尋址存儲與梅克爾樹狀結(jié)構(gòu)。與git類似，各文件會在內(nèi)部根據(jù)其（惟一的）加密內(nèi)容散列進行命名。存在于不同目錄內(nèi)的同一文件的多套副本（例如不同Ubuntu鏡像當中的“l(fā)s”實體）會被合并為單一文件。SQlite文件目錄取決于其中文件的內(nèi)容散列值。如此一來，其root散列值（一個160位整數(shù)）將最終確定整套文件系統(tǒng)快照。要關(guān)閉信任鏈，系統(tǒng)會提供一個經(jīng)過加密的root散列值，每個客戶端則對接收到的數(shù)據(jù)的每一位進行驗證，從而確保其來自預(yù)期來源且未被篡改。

如今，CernVM-FS負責(zé)為分布在全球各地的約十萬臺計算機交付來自大型強子對撞機實驗軟件的數(shù)百萬個文件與目錄。

Mesos通過所謂“容器化器（containerizer）”利用多種實現(xiàn)手段提供任務(wù)容器化能力。容器化器負責(zé)對運行當中的各個任務(wù)加以隔離，同時限定各個任務(wù)可以使用的資源量（例如CPU、內(nèi)存、磁盤以及網(wǎng)絡(luò)）。Mesos容器化器的作用可以通過所謂“隔離器（isolator）”輕松得到擴展，后者可被視為一種執(zhí)行特定任務(wù)的插件（舉例來說，在容器當中啟動外部分卷）。

最后但同樣重要的是，容器化器還能夠為任務(wù)提供一套運行時環(huán)境。它允許用戶將全部關(guān)聯(lián)性同任務(wù)本體一道預(yù)打包至文件系統(tǒng)鏡像當中。這套鏡像隨后可進行任意分發(fā)，并被用于啟動該項任務(wù)。

Mesos目前已經(jīng)擁有多種類型的容器化器。其默認選項為Mesos容器化器——這款工具采用Linux命名空間與cgropus以實現(xiàn)任務(wù)隔離同資源使用量控制，同時配合一整套隔離器實現(xiàn)外部功能交付。另外還有一套Docker容器化器，其利用Docker工具以提取鏡像并啟動Docker容器。

Mesos容器化器目前已通過擴展實現(xiàn)了多種鏡像格式的支持能力，其中包括Docker與AppC，旨在建立一套“統(tǒng)一容器化器”。這套方案令新鏡像格式的支持變得非常輕松：利用統(tǒng)一容器化器，我們只需要為新的鏡像格式構(gòu)建一款所謂“配置器（provisioner）”，并復(fù)用全部現(xiàn)有隔離代碼即可。舉例來說，Mesos用戶可以繼續(xù)使用Docker鏡像，但全部提取、隔離與其它任務(wù)都通過Mesos而非Docker工具實現(xiàn)。

內(nèi)容可尋址存儲的介入、出色的安全水平以及久經(jīng)考驗的擴展能力使得CernVM-FS成為一款極具吸引力的容器鏡像分發(fā)處理工具。為了測試其實際效果，我們創(chuàng)建了一套新的CernVM-FS庫，并將其添加到一套Ubuntu安裝軟件包當中。在此之后，我們立足于CVMFS構(gòu)建了一款Mesos容器鏡像配置器。相較于直接下載完整鏡像，它能夠利用CernVM-FS客戶端以本地方式遠程啟動鏡像root目錄。該配置器可將CernVM-FS庫名稱作為輸入數(shù)據(jù)（其在內(nèi)部被映射至該CernVM-FS服務(wù)器的URL）以及充當容器鏡像root所必需的庫內(nèi)路徑。

如此一來，我們就能夠立足于同一CernVM-FS庫實現(xiàn)多種容器鏡像的發(fā)布。從本質(zhì)上講，CernVM-FS庫的作用等同于一套安全且可擴展的容器鏡像注冊表。

從容器化器的角度來看，一切其實絲毫未受影響。它仍然負責(zé)處理包含有鏡像目錄樹的本地目錄，并利用一切必要元素實現(xiàn)容器啟動。不過這種作法的最大優(yōu)勢在于CernVM-FS擁有經(jīng)過細化調(diào)整的重復(fù)數(shù)據(jù)刪除功能（在配合Docker的情況下，基于文件或者塊而非層），這意味著我們現(xiàn)在能夠在無需下載完整鏡像的前提下啟動容器。一旦容器啟動完成，CernVM-FS會下載必要的文件以進行任務(wù)處理。

在我們的測試當中，我們啟動了一套Ubuntu容器，而后在shell當中運行了一條命令。在傳統(tǒng)場景當中，我們需要下載完整的Ubuntu鏡像，其體積約為300 MB。然而，當我們使用CernVM-FS配置器時，我們只需要下載該任務(wù)所必需的文件——具體為不足6MB。

由于CernVM-FS采用內(nèi)容可尋址存儲，因此我們不需要重復(fù)下載同樣的文件。所以，如果我們進一步啟動其它容器（例如一套CentOS鏡像）并運行不同的命令，那么我們只需要下載新命令所需要的文件，并復(fù)用此前已經(jīng)在Ubuntu鏡像中下載過的全部通用關(guān)聯(lián)性（例如Bash或者libc.so）。在這種模式下，容器層的概念已經(jīng)不復(fù)存在，重復(fù)數(shù)據(jù)刪除將立足于更為細化的層面進行。

我們還計劃添加對該配置器的支持以利用對應(yīng)的檢驗機制啟動任意CernVM-FS目錄。這將幫助開發(fā)人員更為輕松地在處理容器鏡像時實現(xiàn)快速迭代，并使得運維人員便捷地在不同容器鏡像版本間來回切換。

CERN與Mesosphere的技術(shù)團隊對于將CernVM-FS與Apache Mesos集成充滿期待，這也意味著IT行業(yè)將更為廣泛地采納應(yīng)用程序容器技術(shù)。如果各企業(yè)與機構(gòu)希望從根本層面改善應(yīng)用程序構(gòu)建、代碼部署以及數(shù)據(jù)中心運行的實現(xiàn)方式，則必須要立足于高于當前實際規(guī)模的水平上進行容器的啟動、關(guān)閉、更新以及管理。CernVM-FS與Mesos之間的緊密集成將能夠成為一種可行途徑，幫助各類用戶解決容器采納道路上的存儲容量及網(wǎng)絡(luò)帶寬瓶頸。

作為一項新興的技術(shù)，關(guān)于Docker的坑很多，需要我們共同來填滿。大家如果有相關(guān)的疑問和困惑，也歡迎留言和小數(shù)進行討論。

原文鏈接：https://mesosphere.com/blog/2016/03/08/cernvmfs-mesos-containers/