技術解讀:Dragonfly 基於 P2P 的智慧映象加速系統 | 龍蜥技術
編者按:上世紀末期,基於 C/S 模式的思想,人們發展了 HTTP 、 FTP 等應用層協議。然而 C/S 模式的弊端很明顯:伺服器的負載過大,下載速率過慢。基於上述背景,有人結合 P2P 網路與負載均衡的思想,提出 P2P 下載模式。本文整理自 龍蜥大講堂第 40 期,精彩分享影片回放已上傳至龍蜥官網(首頁-動態-影片),歡迎檢視!
背景
網路下載
提起網路下載領域,你應該首先會想到基於 TCP/IP 協議簇的 C/S 模式。這種模式希望每一個客戶機都與伺服器建立 TCP 連線,伺服器輪詢監聽 TCP 連線並依次響應,如下圖:
上世紀末期,基於 C/S 模式的思想,人們發展了 HTTP 、 FTP 等應用層協議。然而 C/S 模式的弊端很明顯:伺服器的負載過大,下載速率過慢。隨著網際網路規模的增大以及客戶對於下載資料大小,下載速率等需求的上升,這些弊端被不斷放大。
P2P 下載原理
基於上述背景,有人結合 P2P 網路與負載均衡的思想,提出 P2P 下載模式。這種模式不再把所有的下載壓力丟給伺服器,伺服器只負責傳遞檔案後設資料,真正的檔案下載連線建立在客戶機與客戶機之間。同時一個檔案可以被分片為多個塊,同一個檔案中不同的塊可以在不同的客戶機之上下載,使得下載檔案在 P2P 網路中動態流通,大幅提升了下載效率,如下圖:
去中心化的 P2P 下載基於 DHT 技術,它採用分散式全網方式來進行資訊的儲存和檢索。所有資訊均以雜湊表條目形式加以儲存,這些條目被分散地儲存在各個節點上,從而以全網方式構成一張巨大的分散式雜湊表。在此基礎上做到對單伺服器的去中心化,雜湊表負責對負載的分攤,將全網負載均攤到多個機器之上。
Dragonfly 簡介及架構概述
Dragonfly 是一款基於 P2P 的智慧映象和檔案分發工具。它旨在提高大規模檔案傳輸的效率和速率,最大限度地利用網路頻寬。在應用分發、快取分發、日誌分發和映象分發等領域被大規模使用。
原理
Dragonfly 結合 C/S 架構與 P2P 架構的優點。它提供面向客戶的 C/S 架構下載模式。同時它也提供面向伺服器叢集的 P2P 回源模式,與傳統 P2P 不同的是,對等網路建立在 Scheduler 內部,目標是最大化 P2P 內部下載效率,如下圖:
架構簡介
Dragonfly 面向映象分發和檔案分發,結合 P2P 網路和伺服器叢集的思想,向使用者提供穩定的、高效的下載服務。Dragonfly 希望在伺服器內部構建 P2P 網路,將伺服器的不同主機節點分為 Manager、Scheduler、Seed Peer 以及 Peer 四個角色,分別提供不同的功能。
其中 Manager 提供總體配置功能,拉取其他角色的配置並相互通訊。Scheduler 提供下載排程功能,其排程結果直接影響下載速率。Seed Peer 負責回源下載,從外部網路中拉取所需的映象或檔案。Peer 作為 C/S 架構中的伺服器,透過多種協議向客戶提供下載功能。架構圖如下:
其中,Seed Peer 支援使用多種協議從外部網路中回源下載,同時也支援當作叢集當中一個 Peer 使用。Peer 提供基於多種協議的下載服務,也提供為映象倉庫或其他下載任務的代理服務。
元件詳解
Manager
Manager 在多 P2P 叢集部署的時候扮演管理者的角色,提供前端控制檯方便使用者進行視覺化操作 P2P 叢集。其主要提供動態配置管理、維護叢集穩定性以及維護多套 P2P 叢集的關聯關係等功能。對於維護叢集整體穩定性 Manager 和各個服務保持 Keepalive 保證能夠在例項異常情況下將異常例項進行剔除。動態配置管理可以在 Manager 上面操作各個元件的控制單元,比如控制 Peer 和 Seed Peer 的負載數,Scheduler 排程 Parent 的個數等。Manager 也可以維護多套 P2P 叢集關聯關係,一個 Scheduler Cluster、一個 Seed Peer Cluster 和若干個 Peer 組成一個完整的 P2P 叢集,當然不同 P2P 叢集可以是網路隔離的。正常情況下采用一個機房一套 P2P 叢集,統一由一個 Manager 管理多個 P2P 叢集。
Scheduler
Scheduler 主要工作就是為當前下載節點尋找最優父節點並觸發 Seed Peer 進行回源下載。在適當時候讓 Peer 進行回源下載。Scheduler 在啟動時,先向 Manager 註冊,註冊成功後初始化動態配置客戶端,並從 Manager 拉取動態配置,接下來啟動 Scheduler 自身所需的服務。
Scheduler 的核心就是選取一組最優 Parent 節點供當前下載 Peer 進行下載。Scheduler 面向 Task,一次 Task 就是一次完整的下載任務,在 Scheduler 中儲存 Task 資訊和相應 P2P 下載網路的 DAG。排程過程是首先過濾異常 Parent 節點,根據多維度進行過濾,比如判斷該 Peer 是否是 BadNode,判斷邏輯為假設每個節點的響應時長都遵循正態分佈,若一個節點目前的響應時長處於 6σ 範圍之外,那麼認為該節點是 BadNode,剔除該節點。再根據歷史下載特徵值對剩餘待定 Parent 節點進行打分,返回一組分數最高的 Parent 提供給當前 Peer 進行下載。
Seed Peer 和 Peer
Seed Peer 和 Peer 有很多相似之處。他們都是基於 Dfdaemon,不同的是 Seed Peer 採用 Seed Peer 模式,支援主動觸發回源下載。Peer 採用 Peer 模式,作為 C/S 架構中的伺服器向使用者提供下載功能,支援被 Scheduler 被動觸發回源下載。這表明 Peer 和 Seed Peer 的關係不是固定的,一個 Peer 可以透過回源使自己成為 Seed Peer,Seed Peer 也可以改動執行狀態變為 Peer,Scheduler 會動態地對相應 DAG 進行改動。另外 Seed Peer 和 Peer 都需要參與排程下載過程當中,Scheduler 可能會選取 Seed Peer 或者 Peer 作為父節點向其他 Peer 提供下載功能。
Dfstore 和 Dfcache
Dfcache 是 dragonfly 的快取客戶端,它與 dfdaemon 通訊並對 P2P 網路中的檔案進行操作,其中 P2P 網路充當快取系統。可以在 Scheduler 中儲存相應 Task 和 DAG。
Dfstore 是 dragonfly 儲存客戶端. 其可以依賴不同型別的物件儲存服務作為 Backend,提供穩定的儲存方案,現在支援 S3 和 OSS 。Dfstore 依賴 Backend 物件儲存服務結合 P2P 本身的加速特點。可做到快寫快讀,並且能夠節省回源以及跨機房流量,減少源站壓力。
優勢
穩定性
Dragonfly 會自動隔離異常節點來提高下載穩定性,Dragonfly 中各個元件透過 Keepalive 與 Manager 進行聯絡,Manager 能夠保證返回給 Peer 的 Scheduler 地址和返回給 Scheduler 的 Seed Peer 地址都是可用的。不可用的 Scheduler 和 Seed Peer 不會被 Manager 推給需要進行下載任務的 Peer 或 Scheduler,從而達到隔離異常節點的目的,這也是例項維度的異常隔離,如下圖:
另外 Dragonfly 在排程時以 Task 為單位,也確保了整個排程過程的穩定性。在收到一個新的 Task 排程請求之後,Scheduler 觸發 Seed Peer 進行回源下載;在收到一個已有 Task 的排程請求之後,Scheduler 排程最優 Parent Peer 集合返回給 Peer。這個邏輯確保了無論 Task 是否下載過,Dragonfly 都可以對其進行處理。此外在 Scheduler 排程過程中,對響應時長過慢的 Peer ,認為目前是異常節點,將不會作為 Parent Peer 被返還。這也是 Task 維度的異常隔離。
高效性
Dragonfly 採用 P2P 進行服務端內部的回源,P2P 下載本身即分攤負載,將每個服務端節點的負載降到最低,有以下幾個細節保證了 Dragonfly 下載的高效性:
-
Scheduler 透過為每個可能的 Parent 打分,返回給 Peer 目前區域性最優的 Parent 集合,Peer 基於此集合做下載。
-
下載過程基於 Task,每個 Task 將待下載檔案分為多個 Piece,Peer 拿到了最優的 Parent 之後,向此集合廣播每個 Piece 的下載請求,集合中的 Parent 收到該請求後返回給 Peer 對應 Piece 的元資訊,Peer 將第一個收到的 Piece 元資訊所對應的 Parent Peer 作為該 Piece 的實際下載源。該做法考慮到 Scheduler 返回可用 Parent 到觸發下載這段時間內可能的變化,同時對不同的 Piece,允許 Peer 向不同的下載源獲取資料。
-
Dfdaemon 分為 Seed Peer 模式和 Peer 模式,允許 Seed Peer 和 Peer 進行切換,可以根據實際需求改變作為 Seed Peer 和 Peer 的機器數目,動態調整更適應實際情況。
簡單易用
Dragonfly 提供 Helm Charts、Docker Compose、Docker Image 以及二進位制的多種部署方式。使用者可以快速一鍵部署進行一次簡單 POC,並且也可以基於 Helm Charts 進行大規模生產部署。當然 Dragonfly 各個服務都有完善的 Metrics 也提供現成的 Granafa 模版,方便使用者觀察 P2P 的流量走勢。
Dragonfly 作為 CNCF 在映象加速領域標準解決方案,結合 Dragonfly 子專案 Nydus 進行按需載入可以最大限度提升映象下載速度,未來我們也會繼續努力建設映象加速領域的生態鏈。感謝所有參與到社群建設的同學,希望有更多對映象加速領域或 P2P 感興趣的同學加入(文末掃描二維碼或搜尋釘釘群號:44701621進群進行交流)到我們的社群當中。
關於影片回放和課件獲取
【影片回放】:影片回訪已上傳至龍蜥官網: 檢視。
【PPT課件獲取】:關注微信公眾號(OpenAnolis),回覆“龍蜥課件”即可獲取。有任何疑問請隨時諮詢龍蜥助手—小龍(微信:openanolis_assis)。
相關連結可移步龍蜥公眾號(OpenAnolis龍蜥)2022年9月5日相同推送檢視。
—— 完 ——
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70004278/viewspace-2913769/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 螞蟻安全科技 Nydus 與 Dragonfly 映象加速實踐 | 龍蜥技術Go
- 技術門檻高?來看 Intel 機密計算技術在龍蜥社群的實踐 | 龍蜥技術Intel
- 虛擬化解決方案 virtio 的技術趨勢與 DPU 實踐解讀 | 龍蜥技術
- 深入解讀基礎軟體雲原生面臨的挑戰 | 龍蜥技術
- 基於 Coolbpf 的應用可觀測實踐 | 龍蜥技術
- Dragonfly 基於 P2P 的檔案和映象分發系統Go
- 萬里資料庫加入龍蜥社群,打造基於“龍蜥+GreatSQL”的開源技術底座資料庫SQL
- 龍蜥利器:系統運維工具 SysAK的雲上應用效能診斷 | 龍蜥技術運維
- 深入解讀雲場景下的網路抖動 | 龍蜥技術
- 技術解讀倚天 ECS 例項——Arm 晶片的 Python-AI 算力最佳化 | 龍蜥技術晶片PythonAI
- 一文解讀機密容器的崛起和發展 | 龍蜥技術
- 技術解讀:現代化工具鏈在大規模 C++ 專案中的運用 | 龍蜥技術C++
- 效能提升 57% ,SMC-R 透明加速 TCP 實戰解析 | 龍蜥技術TCP
- 開源生態與AI晶片的碰撞&Dragonfly基於P2P的映象加速系統 | 第 39-40 期AI晶片Go
- 載入速度提升 15%,關於 Python 啟動加速探索與實踐的解析 | 龍蜥技術Python
- 跨語言程式設計的探索 | 龍蜥技術程式設計
- 助力Koordinator雲原生單機混部,龍蜥混部技術提升CPU利用率達60%|龍蜥技術
- 浪潮儲存基於智慧運維技術,加速儲存自治運維
- eBPF 雙子座:天使 or 惡魔?| 龍蜥技術eBPF
- 智慧運維:基於 BIM 技術的視覺化管理系統運維視覺化
- 基於機器學習的糾錯系統技術 - 智慧文字糾錯 API機器學習API
- 適用場景全新升級!擴充套件 Dragonfly2 作為分散式快取系統架構 | 龍蜥技術套件Go分散式快取架構
- 基於雲技術的域名解析系統研究:傳統解析技術的侷限性
- 從編譯到可執行,eBPF 加速容器網路的原理分析 | 龍蜥技術編譯eBPF
- 技術分享 | 基於windows作業系統的錦行蜜罐新節點技術Windows作業系統
- 系列解讀 SMC-R (二):融合 TCP 與 RDMA 的 SMC-R 通訊 | 龍蜥技術TCP
- 使用P2P直播加速技術,IPTV直播系統可以節省多少頻寬?
- Cube 技術解讀 | Cube 小程式技術詳解
- Cube 技術解讀 | Cube 卡片技術棧詳解
- 利器解讀!Linux 核心調測中最最讓開發者頭疼的 bug 有解了|龍蜥技術Linux
- 阿里巴巴開源容器映象加速技術阿里
- 直播回顧:隱私計算的關鍵技術以及行業應用技巧 | 龍蜥技術行業
- 技術文件:基於 Python 的影像處理系統Python
- 軟體調優方法有哪些?看看飛騰技術專家怎麼說 | 龍蜥技術
- 基於雲技術的域名解析系統研究:雲解析技術的應用(國科雲)
- 龍蜥開源核心追蹤利器 Surftrace:協議包解析效率提升 10 倍! | 龍蜥技術協議
- 龍蜥開源Plugsched:首次實現 Linux kernel 排程器熱升級 | 龍蜥技術Linux
- SysOM 案例解析:消失的記憶體都去哪了 !| 龍蜥技術記憶體