摘要:負責承載操作系統的分布式文件系統只需要使用必要的文件,而且事實上只需要下載并在本地緩存這部分必要數據。而第二項原則在于元數據即與文件存在相關的信息,而非文件內容被優先對待。這套鏡像隨后可進行任意分發,并被用于啟動該項任務。
隨著Docker技術的日漸火熱,一些容器相關的問題也浮出水面。本文就容器數量激增后造成的分發效率低下問題進行了探討,并提出了一種新的解決方法。發現問題,解決問題,正是IT技術不斷進步的真諦,小數深以為然。
容器技術令應用程序的配置與部署工作效率極大提高,但在不同IT運維領域的具體提升效果卻又不盡相同。舉例來說,其在利用數據中心存儲與網絡容量進行容器鏡像的大規模分發時往往表現得比較不盡如人意。
這確實有點反直覺:容器技術一直以高效的服務運行能力與相較于虛擬機的可觀資源節約水平為人們所稱道,為什么也會存在效率低下問題?答案出在Docker鏡像的存儲與下載方式上。從傳統角度講,存儲在庫中的每套鏡像都必須擁有與其各層相關的全部文件,這意味著對任意主機設備上的Docker鏡像進行更新,我們就需要從該庫中下載完整的鏡像。
在面對小型Web應用中的少量容器時,這種機制似乎構不成什么大問題。然而我們可以設想一旦容器系統數量增長至數百、數千乃至數百萬之巨時,那么庫的體積就會隨著容器系統的增加而不斷攀升,而每一次更新所需要下載的數據量也會越來越大。與此同時,獲取Docker鏡像的下載流量也將提升至數GB,這顯然是我們所無法接受的。
像Twitter這樣的企業無疑運行有大量容器系統,自然也經歷過上述困擾。這種狀況會隨著更多企業采用容器技術而變得愈發普遍,并導致大型容器庫的規模不斷向外擴展。
我們認為解決容器臃腫難題的可行方案之一正是名為CernVM文件系統(簡稱CernVM-FS)的技術成果。其由CERN(歐洲核子研究中心)開發而成,同時囊括了來自世界各地的高能物理學領域、特別是費米實驗室的辛勤貢獻。
CernVM-FS的作用在于幫助科學家分發每年開發出的高達2TB的軟件數據——其中一部分軟件甚至每周都需要面向數十萬臺計算機進行多次分發與上傳。CernVM-FS采用一整套獨特的索引、重復數據刪除、緩存與地理分布機制,旨在最大程度降低與每次下載相關的組件數量,同時盡可能加快必要的下載數據量。
Mesosphere與CERN目前正在探索如何將CernVM-FS同Apache Mesos加以結合,從而了解其在容器下載工作中的實際效果以及我們在大型容器環境下的處理效率。
CernVM-FS工作原理深度解析CernVM-FS的基本構想誕生于2008年,當時CERN的研究人員與現在的人們一樣因為底層硬件虛擬化的需求而開始審視容器技術,即尋求新的應用程序部署機制。相較于創建鏡像或者軟件包,他們想到使用一套全局分布式文件系統幫助科學家們將自己的軟件一次性安裝在一臺Web服務器上,而后立足世界任意位置對其進行訪問。
作為一套分布式文件系統,其首要原則就是在任意時間段之內,全部可用文件都只有一小部分接受實際訪問。舉例來說,要運行一臺Web服務器,大家只需要使用操作系統(例如glibc與OpenSSL)中的一部分庫。負責承載操作系統的分布式文件系統只需要使用必要的文件,而且事實上CVMFS只需要下載并在本地緩存這部分必要數據。當時研究人員們選擇了HTTP作為下載協議,從而接入其它可用Web緩存基礎設施(例如Akamai、CloudFront、Squid以及NGINX代理服務器等等)。
而第二項原則在于元數據(即與文件存在相關的信息,而非文件內容)被優先對待。一般來講,文件系統所承載的軟件會受到“libssl.so是否存在于lib32當中?抑或是存在于/lib64目錄當中?還是存在于/usr/lib32當中?”這類請求所困擾。在處理這些請求時,通用型分布式文件系統往往表現得很差。CernVM-FS則將全部元數據保存在SQlite文件當中,并將其作為常規文件進行下載與緩存。在這種情況下,數百萬計的元數據請求就能夠以本地方式進行解析,使得CernVM-FS在速度表現上幾乎與本地POSIX文件系統保持一致。
第三項原則在于,軟件只能夠在發布點處進行修改——其他一切客戶都只能在高可用性水平下實現只讀操作。多數此前存在的文件系統在設計中都無法處理CAP定理提到的權衡難題,因為這類系統會假定客戶的目標始終是讀取最新的可用數據版本。在這種情況下,軟件必須在應用或者容器運行的同時保持即時性,這意味著運行過程中該文件系統必須交付單一快照。
有鑒于此,CERN決定使用內容可尋址存儲與梅克爾樹狀結構。與git類似,各文件會在內部根據其(惟一的)加密內容散列進行命名。存在于不同目錄內的同一文件的多套副本(例如不同Ubuntu鏡像當中的“ls”實體)會被合并為單一文件。SQlite文件目錄取決于其中文件的內容散列值。如此一來,其root散列值(一個160位整數)將最終確定整套文件系統快照。要關閉信任鏈,系統會提供一個經過加密的root散列值,每個客戶端則對接收到的數據的每一位進行驗證,從而確保其來自預期來源且未被篡改。
如今,CernVM-FS負責為分布在全球各地的約十萬臺計算機交付來自大型強子對撞機實驗軟件的數百萬個文件與目錄。
Mesos中的容器化器Mesos通過所謂“容器化器(containerizer)”利用多種實現手段提供任務容器化能力。容器化器負責對運行當中的各個任務加以隔離,同時限定各個任務可以使用的資源量(例如CPU、內存、磁盤以及網絡)。Mesos容器化器的作用可以通過所謂“隔離器(isolator)”輕松得到擴展,后者可被視為一種執行特定任務的插件(舉例來說,在容器當中啟動外部分卷)。
最后但同樣重要的是,容器化器還能夠為任務提供一套運行時環境。它允許用戶將全部關聯性同任務本體一道預打包至文件系統鏡像當中。這套鏡像隨后可進行任意分發,并被用于啟動該項任務。
Mesos目前已經擁有多種類型的容器化器。其默認選項為Mesos容器化器——這款工具采用Linux命名空間與cgropus以實現任務隔離同資源使用量控制,同時配合一整套隔離器實現外部功能交付。另外還有一套Docker容器化器,其利用Docker工具以提取鏡像并啟動Docker容器。
Mesos容器化器目前已通過擴展實現了多種鏡像格式的支持能力,其中包括Docker與AppC,旨在建立一套“統一容器化器”。這套方案令新鏡像格式的支持變得非常輕松:利用統一容器化器,我們只需要為新的鏡像格式構建一款所謂“配置器(provisioner)”,并復用全部現有隔離代碼即可。舉例來說,Mesos用戶可以繼續使用Docker鏡像,但全部提取、隔離與其它任務都通過Mesos而非Docker工具實現。
集成CernVM-FS與Mesos以實現容器鏡像分發內容可尋址存儲的介入、出色的安全水平以及久經考驗的擴展能力使得CernVM-FS成為一款極具吸引力的容器鏡像分發處理工具。為了測試其實際效果,我們創建了一套新的CernVM-FS庫,并將其添加到一套Ubuntu安裝軟件包當中。在此之后,我們立足于CVMFS構建了一款Mesos容器鏡像配置器。相較于直接下載完整鏡像,它能夠利用CernVM-FS客戶端以本地方式遠程啟動鏡像root目錄。該配置器可將CernVM-FS庫名稱作為輸入數據(其在內部被映射至該CernVM-FS服務器的URL)以及充當容器鏡像root所必需的庫內路徑。
如此一來,我們就能夠立足于同一CernVM-FS庫實現多種容器鏡像的發布。從本質上講,CernVM-FS庫的作用等同于一套安全且可擴展的容器鏡像注冊表。
從容器化器的角度來看,一切其實絲毫未受影響。它仍然負責處理包含有鏡像目錄樹的本地目錄,并利用一切必要元素實現容器啟動。不過這種作法的最大優勢在于CernVM-FS擁有經過細化調整的重復數據刪除功能(在配合Docker的情況下,基于文件或者塊而非層),這意味著我們現在能夠在無需下載完整鏡像的前提下啟動容器。一旦容器啟動完成,CernVM-FS會下載必要的文件以進行任務處理。
在我們的測試當中,我們啟動了一套Ubuntu容器,而后在shell當中運行了一條命令。在傳統場景當中,我們需要下載完整的Ubuntu鏡像,其體積約為300 MB。然而,當我們使用CernVM-FS配置器時,我們只需要下載該任務所必需的文件——具體為不足6MB。
由于CernVM-FS采用內容可尋址存儲,因此我們不需要重復下載同樣的文件。所以,如果我們進一步啟動其它容器(例如一套CentOS鏡像)并運行不同的命令,那么我們只需要下載新命令所需要的文件,并復用此前已經在Ubuntu鏡像中下載過的全部通用關聯性(例如Bash或者libc.so)。在這種模式下,容器層的概念已經不復存在,重復數據刪除將立足于更為細化的層面進行。
我們還計劃添加對該配置器的支持以利用對應的檢驗機制啟動任意CernVM-FS目錄。這將幫助開發人員更為輕松地在處理容器鏡像時實現快速迭代,并使得運維人員便捷地在不同容器鏡像版本間來回切換。
配合容器普及的浪潮CERN與Mesosphere的技術團隊對于將CernVM-FS與Apache Mesos集成充滿期待,這也意味著IT行業將更為廣泛地采納應用程序容器技術。如果各企業與機構希望從根本層面改善應用程序構建、代碼部署以及數據中心運行的實現方式,則必須要立足于高于當前實際規模的水平上進行容器的啟動、關閉、更新以及管理。CernVM-FS與Mesos之間的緊密集成將能夠成為一種可行途徑,幫助各類用戶解決容器采納道路上的存儲容量及網絡帶寬瓶頸。
作為一項新興的技術,關于Docker的坑很多,需要我們共同來填滿。大家如果有相關的疑問和困惑,也歡迎留言和小數進行討論。
原文鏈接:https://mesosphere.com/blog/2016/03/08/cernvmfs-mesos-containers/
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/26557.html
摘要:阿里云容器服務已經發布了基于容器集群的開源區塊鏈解決方案,利用容器技術可以在分鐘之內部署完成一個生產級別安全高可用的區塊鏈應用運行環境,幫助企業可以加速業務創新。對節點,阿里云服務會自動開啟相應調度能力。 摘要: 阿里云ECS彈性裸金屬服務器(神龍)已經與其容器服務全面兼容,用戶可以選擇在彈性裸金屬服務器上直接運行容器、管控Kubernetes/Docker容器集群,如此將會獲得非常出...
摘要:由于某些原因,在國內構建第三方鏡像是一件考驗耐心的事情。國內有不少的鏡像源,比如中科大阿里云。以中科大的鏡像源為例,可以這樣指定鏡像源通常作為一個服務由系統在開機時啟動,所以我們需要把上面的指令加到服務的配置中。 由于某些原因,在國內構建第三方docker鏡像是一件考驗耐心的事情。在神奇的國度生活,自然也要用神奇的生活方式。跟解決其他同類問題一樣,解決這個問題常用兩種方法,一曰換源,二...
摘要:新一代也有輕量的特性,介紹谷歌的輕量特性,應用要具有彈性要分布發布,再一個容錯性強易于維護,也要對計算資源故障進行容錯。 5月18日,第八屆中國云計算大會在北京國家會議中心召開。作為領先的云計算創新技術實踐者,數人云CEO王璞博士應邀出席并在全體大會上進行主題為中美容器之融合與變革的分享,以下是演講實錄: 容器VS虛擬化 showImg(https://segmentfault.com...
摘要:這相當于在原始安裝程序中調整文件。警告我并沒有告訴這件事,因為這可能會嚇到他或任何其他專家。在創建應用商店條目的過程中,還有兩個問題需要解決變量需要設置為確切值,這樣用戶就可以通過它連接到該實例。 Harbor Registry是VMware公司的Docker鏡像管理產品。相較于其他鏡像倉庫,Harbor提供身份管理功能,安全性更高,支持單個主機上的多個registry,這些功能正是很...
摘要:八年時間,阿里集團實現了內部容器化鏡像化,經歷了幾代演進。容器技術在阿里的演進過程伴隨著阿里技術架構本身的演進。 八年時間,阿里集團實現了 100%內部容器化鏡像化,經歷了幾代演進。本文將從最初的架構開始,向大家介紹下阿里內部的容器化演化過程。 PouchContainer 現在服務于阿里巴巴集團和螞蟻金服集團的絕大部分 BU, 包括交易&中間件,B2B/CBU/ICBU,搜索廣告數據...
閱讀 2078·2021-10-08 10:21
閱讀 2471·2021-09-29 09:34
閱讀 3494·2021-09-22 15:51
閱讀 4926·2021-09-22 15:46
閱讀 2314·2021-08-09 13:42
閱讀 3434·2019-08-30 15:52
閱讀 2723·2019-08-29 17:13
閱讀 1555·2019-08-29 11:30