大家好,這次分享的主題是Dragonfly項目的最新進展本次分享有兩位主獎人我是來自螞蟻集團的工程師也是Dragonfly的核心維護者氣文伯另一位主獎人是來自上海交通大學也是Dragonfly核心維護者張哲義長話短說,首先我們來介紹一下Dragonfly項目Dragonfly項目是一個開源的基於P2P的鏡像和文件分發系統它的目標是解決雲院生場景中的文件分發問題目前Dragonfly專注於簡單、高效、智能、安全四個方面首先簡單我們會定義良好的面向用戶的API對所有容器引擎都沒有侵入性高效、支持、CDN基於P2P文件分發節省企業貸款智能、主機、主機級限速主機檢測智能流量控制安全主要是快傳輸加密加密連接支持Dragonfly項目主要有兩個比較重要的里程碑在2018年11月15日貝森CF拖廣為孵化機項目在2021年9月9日經過一年的開發時間對Dragonfly 1.0版本整體重構、優化解決了很多性能平靜以及功能缺陷等問題最終發布了Dragonfly 2.0版本現階段Dragonfly 2.0版本核心維護者主要來自於阿里巴巴、螞蟻集團、字節跳動去哪兒、醫背、美圖以及上海交通大學的同學當然Dragonfly 2.0也要感謝社區同學比如英特爾同學幫助我們在初期階段進行大規模集群測試下面由張哲毅來介紹一下2.0版本與1.0版本的區別大家好接下來由我介紹1.0版本和2.0版本的區別因為本次介紹的主題是2.0版本因此對1.0版本就不進行詳細的介紹了只講一下在1.0版本中我們遇到的一些問題1.0版本的問題主要分為以下五個方面分別是架構方面、協議方面安全方面、分發模式方面和產品化能力方面在架構方面右邊是一張1.0版本的架構圖可以看到在下載時每一個DF client都需要和Supernode進行交互來下載Supernode既要進行P2P網絡中下載信息的追蹤和P2P下載的調度也要對整個集群回源下載的穩健進行緩存這導致我們的系統對於Supernode是高依賴和高偶和的而且Supernode無論是網絡傳輸、調度計算還是本地存儲上都承擔了比較大的壓力在分發業務量逐漸增加後DF 1.0版本就漸漸暴露出它在穩定性、效率和安全方面的一些問題然後在協議方面1.0版本傳輸協議十分單一只支持了HTTP傳輸協議也沒有對多種存儲類型比如HDFS、Maven等進行適配在安全性方面1.0版本的所有數據傳輸都是明文傳輸的這顯然在安全方面有些隱患然後是分發模式方面的問題1.0版本只有主動拉取的能力缺乏對主動推送、自動同步這些功能的支持最後是在產品化能力方面的問題1.0版本沒有提供完整的控制台功能這導致它缺少了文件分發任務管控數據試圖、多租戶、全線控制等等方面的一些能力以上就是1.0版本的主要缺陷接下來介紹一下2.0版本中對前面所講的1.0版本的缺陷的改進以及其他方面的補強首先是架構方面前面提到1.0版本有一個非常中心化的Supernode在2.0版本中我們捨棄了一個非常中心化的Supernode的設計將其拆分成了Scheduler和CDN兩個字系統分別承擔著原本Supernode在不同維度上的功能降低了系統之間的核性並且Scheduler和CDN都設計成了插件化的形式系統不再對這些比較中心化的組件有著強依賴提高了系統部署和使用的靈活性還有可用性在協議方面通過一個統一的回源下載試配層我們實現了對多種協議的支持現在不僅是HTTP協議也包括FTP, HDFS, Maven等然後介紹在效率方面的改進我們在2.0版本中使用了多線程IO技術內存硬射技術DMA技術等技術提高了IO性能又通過動態壓縮內存文件系統還有更加高效的PTP下載調度算法提高了文件分發的效率在安全方面我們引入了加密傳輸的模式以及基於帳戶的全線還有線速傳輸的能力提高了系統的安全性在分發模式方面相比1.0有了很大的擴展現在不只支持主動拉取還支持主動推送自動同步遠程複製自動預熱以及跨雲傳輸等方式的文件分發在產品化能力方面我們通過引入了一個Manager作為整個系統的控制台支持了包括文件上傳多種分發模式下的文件分發任務管理數據試圖還有全局管控的能力這些產品化能力最後在軟件生態方面首先我們的Client被設計的對第三方集成十分友好能夠通過它的Client Server模式還有Proxy模式很方便的將DragonFly的PTP傳輸能力集成到第三方軟件中我們還和Hover,Nidus等項目進行了串連提供了一套完整的鏡像分發加速解決方案正面我具體介紹下DragonFly 2.0整體架構主要分為四個模塊Manager,Scheduler,CDN以及Client端的DFGuide以及DFDmen首先Manager主要維護各P2P集群的關聯關係以及配置管理等功能也包含了前端控制台方便用戶進行可視化操作集群Scheduler主要功能為調度為帶下載節點選擇最優富節點CDN做回源下載緩存文件可以減少回源流量節省貸款CDN為P2P網絡中的原節點DFGuide為P2P下載命運行工具DFDmen為Proxy來代理流量走P2P網絡進行下載主要用作鏡像下載對ContainerD,CRIO等客戶端進行適配後面規劃當中我們也會提供其他語言SDK方便用戶集成下面我簡單描述下P2P網絡對文件的首次下載流程來闡述各個模塊的作用首先Dragonfly支持兩種下載方式通過DFGuide直接對文件進行下載和通過Proxy方式代理下載當然Proxy方式下載主要面向鏡像下載首先通過客戶端DFGuide或DFDmen攔截下載請求然後客戶端會去Scheduler註冊下載任務註冊成功Scheduler會去Manager拉取GuideScheduler集群關聯的可用CDN列表當然這個拉取過程其實是一個義部的然後Scheduler觸發CDN進行第一次活源下載然後Scheduler與DFDmen建立鏈接將CDN下載Piece原信息返回至DFDmen然後DFDmen從CDN下載Piece的具體內容所以P2P首次下載會比正常網絡下載稍微延遲一些但後續願意節點對該文件重複下載Scheduler都會選擇P2P網絡內最優富節點返回使用P2P網絡內流量貸款相對較快而且可以減少回言流量下面是對各個模塊功能進行詳細描述首先是Manager在多集群部署過程中Manager扮演的是集群管理者的角色要理解一個比較重要的關係就是Manager管理的是多個P2P網絡主要管理單元為Scheduler集群以及Scheduler實例CDN集群以及CDN實例一個Scheduler集群組成一個P2P網絡管理其關聯的P2P節點也就是PEERCDN集群與Scheduler集群為E比N的關係也就是在網絡允許的情況下一個CDN集群可以服務多個Scheduler集群也就是一個CDN集群可以服務多個P2P下載網絡當然Manager也負責下發一些集群單位的配置例如對CDN集群或Scheduler集群進行限流調整單節點下載負載數等Manager也包含對CDN、Scheduler節點的可用性的探測預熱以及用戶全線管理等其他功能上述功能可以在Manager前端控制台進行操作下面是Scheduler模塊其主要為代下載節點選擇最優富節點其存儲主要有三種原信息第一種是PEER它代表的是ModeHouse的一次下載第二種是House代表對應的下載單元Task代表一次下載任務調度過程中會對PEER組件數紫節點從負節點進行下載所以調度的重要工作就是對此節點選擇最優富節點選擇過程中我們會提取影響的下載的關鍵特徵例如節點的時間的網絡距離負載數等對節點進行打分然後每次PEER下載時選取分數最高的節點作為其負節點各特徵值具體打分權重則歸結為線性回歸問題基於機器學習算法通過歷史數據來得到最優權重配比進行打分當然調度算法中我們也提供插件形式集成可以根據用戶具體需求定制具體算法接下來介紹CDN模塊CDN是我們Dragonfly項目中用於緩存回源下載的文件的子系統在1.0版本中它是Supernode的一個組成部分在2.0中基於降低系統偶和性提高可用性和靈活性方面的考慮我們將它拆分了出來需要CDN的理由有以下幾點首先CDN能夠為整個集群提供文件緩存能力能極大的加速單個文件在第二次以及之後請求時的下載速度其次當許多PEER同時請求下載同一個文件時整個集群只會有一個CDN節點回源進行下載這能很大程度的緩解整個集群的網絡壓力最後擁有CDN這個組件就能夠支持文件的預熱下載也就是提前將即將被大規模分發的文件準備到集群中提高文件的分發效率Dragonfly 2.0版本的CDN通過一個統一的回源適配層實現了多元適配能力向右邊圖中上面一排就是通過這個統一的回源適配層支持的協議包括http,https,ftp,hdfs以及os等等提高了Dragonfly在各類不同場景下的可用性另外CDN通過一個抽象的存儲接口實現了對實際存儲方式的結偶它的存儲模式是插件化的右圖下邊一排就是Dragonfly當前集成的CDN存儲模式插件包括硬盤存儲模式還有內存與硬盤混合模式用戶也可以根據自己的應用場景靈活的實現自己相應的插件最後CDN作為一個主要用來存儲各類文件的子系統可能會面臨一些磁盤存儲空間上的問題我們採用了基於LRU算法的磁盤空間管理方案提高了在各種情況下CDN的可用性然後介紹DFDM這個組件DFDM被設計的非常易於集成它支持了Client Server模式Proxy模式常駐模式和非常駐模式等等模式這使得它擁有非常強大的靈活性如右圖的下邊通過Client Server模式就可以通過DFGet來使用DFDM的P2P下載能力而通過Proxy模式就可以將DFDM的P2P下載能力集成到Docker等軟件之中2.0版本的DFDM擁有非常高效的IO性它會在多任務下載時進行IO的調度它正能提高整體的IO性它還優化了生成臨時文件的方式以及教驗數據完整性的方式減少了文件讀寫的次數實現的方式後邊也會講到這也相當於提高了IO的效率另外DFDM不只擁有P2P下載的能力如右圖的上邊它也支持直接回源下載的方式因此它也通過了一個統一的適配存集成了多元適配能力最後DFDM擁有本地緩存能力這使得它能夠在P2P網絡中作為一個sealer加速其他P2的下載研究時本地的重複下載重用此前下載的數據而不再需要對外發起請求這裡是一個2.0版本和1.0版本的性能的對比我們使用了多種方式減少了CPU和內存資源的消耗首先我們使用了GRPC的雙向流的形式改寫了一些接口使得文件下載時不再需要不停的做一些重複的請求比如客戶端更新P2P網絡中可用的PL列表時通過GRPC的雙向流就不再需要反覆的去做一個請求就減少了網絡傳輸的壓力第二上傳文件使用了SendFileSplice的支持受益於Golang標準庫中的這個方法文件上傳過程在本地是領考背的第三下載文件和上傳文件一樣我們也使用了領考背的技術下載文件時文件不再需要在用戶空間和內核的PageCache之間進行傳輸減少了考背次數節約了時間可以看下面左邊的圖同樣是傳輸100MB的數據2.0版本無論是實際時間用戶態時間還是內核態時間都比1.0版本有了不小的提升第四如果使用Golang標準庫來進行文件的MD5碼教驗文件數據需要從內核空間拷貝到用戶空間但考慮到DragonFly在教驗數據時通常是能在PageCache中直接命中文件數據的因此我們使用了AFALG和內核加密的API能夠避免這個文件數據的拷貝減少了內核態和用戶態之間的一次切換可以看到下面右邊的圖同樣是教驗1000MB的數據2.0版本的用戶態時間縮減到了0這也證明了我們此前的觀點前面的PPT主要描述了系統整體架構和各個模塊的功能下面我們來具體動手一件部署一套DragonFly集群我這邊的部署基於看的模擬本地K8S環境通過用戶來一件部署DragonFly集群並代理ContainerD請求走P2P網絡來拉取鏡像大家可以看見我的本地的terminal這邊可以在給到App上面可以進入DragonFly的DragonFly這個項目裡面然後裡面會有ArtifactK的harv可以鏈接可以點進去也可以直接進來搜索DragonFly進入DragonFly的CharseHumanCharse裡面這邊主要是會有兩個比較簡單部署命令第一步就是去添加一個DragonFly的使用的repo咱們這邊先添加一下因為我之前已經添加過了所以因為添加過了所以說這邊顯示已存在不需要再次添加我們直接去Install集群就可以了命令也在這裡不要快好評價就可以了這邊Install之後然後它會顯示一線notice我們看著K9SDragonFly的部署情況我可以看到K8S命名空間所有的組件它破的命令情況我這邊HumanCharse裡面默認就加了MySQL跟Redis我這邊這兩個組件是manager所依賴的MySQL主要是做數據存儲的Redis主要是做catch和消息兌電因為會有比如說預熱這種意不任務所以說Redis做一個記錄存儲也做消息兌電也做一個catch這邊啟動流程主要是manager會等待Mescal跟Redis啟動成功之後Manager進行啟動Manager啟動成功之後然後CDN會後續進行啟動然後向Manager進行註冊然後發起K8Live請求跟Manager保持一個K8Live然後Manager也會存儲一下CDN的狀態同樣CDN啟動完成之後Scheduler也會緊接著啟動然後也會向Manager進行註冊並且跟Manager保持一個K8LiveManager去存儲一個CDN跟Scheduler一個實力的運行狀態這邊已經所有的組件已經啟動成功了首先線上不屬的話我這邊比較推薦就是使Mescal跟Redis外接比如使用一些公務運的一些存儲比如RDN的RDS之類而且Humuchars裡面也提供了相應的配置去External去配置一些ExternalMescal和Redis我們這邊來看一下Humuchars的Humuchars的那個配置默認配置Humuchars裡面的默認配置Humuchars裡面的默認配置在DFD們裡面DFD們裡面的Config已經配置了Proxy而且Proxy是攔截鏡像Layer的一個PASS的一個證則然後配置了回源的像倉庫是DockerHub的index.docker.io這邊相當於就是Humuchars的默認配置啟動之後其實已經Proxy已經配置攔截了你的鏡像請求你也可以看一下DFD們裡面的配置可以看一下這邊Proxy其實已經配置了對於鏡像進行攔截而且原站為index.docker.io這邊成功之後然後主要介紹一下幾個部署單元Manager這邊主要是用的DeploymentCDN跟Scheduler用的是Stateful SightDFD們主要用的Demon Sight因為DFD們是需要比如在K8S環境它需要在K8S各個Node的節點進行部署並且攔截它的譬如說它的ContainerD和CRIO的鏡像拿取了操作讓它去走P2P網絡這邊我們可以看一下我這邊的ContainerD的配置我這邊ContainerD的配置這邊看一下我們看的也ContainerD的配置這邊會在它的鏡像倉庫配置的是DFD們的代理端口比如說65001因為DFD們相當一個Demon Sight它起在一個Node裡面然後把它的65001端口暴露在了它的Node上面Node上面這時候65001端口就可以相對於是P2P網絡的代理入口這邊ContainerD配置了它將倉庫式代理入口所以說我們這邊ContainerD其實正常用戶使用的話相當於ContainerD需要配置一下它的代理地址然後重啟ContainerD就可以了這邊相對於已經配置好了配置好之後我們來下載一次鏡像這時候用ContainerD的迷你航工具相對於下載鏡像就已經走的是P2P網絡加速的流量面稍等一下因為第一次下載鏡像需要CDN去回源回源之後然後Pir再從CDN去下載相對來講比較慢一些我這邊已經顯示下載成功了當然除了首次下載之後第二次下載再任意Node去下載之後下載同樣的鏡像都是走的P2P網絡內的流量所以說相對來講第二次下載從第二次下載開始就比較快了我們這邊可以看見DMD們的它的日誌我們可以去過濾一下它的鏡像名這邊日誌裡面其實因為一次下載就一次Tasso用所以說我們可以拿到TassoID為EID去過濾一下日誌其實去看靠的日誌其實就可以了這邊可以看到一個一次P2P下載的完整的流程的日誌對這些LOG就代表著相當於是P2P下載走P2P網絡下載是成功的了這邊其實演示就結束了這邊其實對於部署的演示將來都比較簡單一些我們裝Fly的支持三種環境的部署有第一種是K8S這邊我們支持兩種方式有HumeChars的一種還有Cosmize這兩種方式去部署這些兩種方式部署文檔其實在我們的Gatab倉庫裡面其實都有的Docker的話其實可以去分鏡像去部署當然也可以通過DockerCompose對吧去本地拉起去我們一般做調適的時候會用DockerCompose當然還有一種情況就是在物理級環境下部署我們這邊也提供二斤這方式去部署最後歡迎大家使用DragFly 2.0作為SenseCF孵化項目我們的目標是把項目做到畢業成為鏡像下載傳輸層面的標準在未來可預期長徑P2B鏡像加載加速預熱等功能都是線上大規模集群不可或學的一環DragFly 2.0剛剛起航也希望更多的社區同學參與到DragFly項目建設當中下面是項目鏈接以及叮叮群歡迎感興趣同學掃馬進群當然一些建設性意見和建議也可以通過Gatab一秀的方式提給我們開發團隊我們今天演講結束了