技术解读:Dragonfly 基于 P2P 的智能镜像加速系统 | 龙蜥技术
编者按:上世纪末期,基于 C/S 模式的思想,人们发展了 HTTP 、 FTP 等应用层协议。然而 C/S 模式的弊端很明显:服务器的负载过大,下载速率过慢。基于上述背景,有人结合 P2P 网络与负载均衡的思想,提出 P2P 下载模式。本文整理自龙蜥大讲堂第 40 期,精彩分享视频回放已上传至龙蜥官网(首页-动态-视频),欢迎查看!
背景
网络下载
提起网络下载领域,你应该首先会想到基于 TCP/IP 协议簇的 C/S 模式。这种模式希望每一个客户机都与服务器建立 TCP 连接,服务器轮询监听 TCP 连接并依次响应,如下图:
P2P 下载原理
基于上述背景,有人结合 P2P 网络与负载均衡的思想,提出 P2P 下载模式。这种模式不再把所有的下载压力丢给服务器,服务器只负责传递文件元数据,真正的文件下载连接建立在客户机与客户机之间。同时一个文件可以被分片为多个块,同一个文件中不同的块可以在不同的客户机之上下载,使得下载文件在 P2P 网络中动态流通,大幅提升了下载效率,如下图:
Dragonfly 简介及架构概述
Dragonfly 是一款基于 P2P 的智能镜像和文件分发工具。它旨在提高大规模文件传输的效率和速率,最大限度地利用网络带宽。在应用分发、缓存分发、日志分发和镜像分发等领域被大规模使用。
原理
Dragonfly 结合 C/S 架构与 P2P 架构的优点。它提供面向客户的 C/S 架构下载模式。同时它也提供面向服务器集群的 P2P 回源模式,与传统 P2P 不同的是,对等网络建立在 Scheduler 内部,目标是最大化 P2P 内部下载效率,如下图:
架构简介
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 自身所需的服务。
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。
稳定性
Dragonfly 会自动隔离异常节点来提高下载稳定性,Dragonfly 中各个组件通过 Keepalive 与 Manager 进行联系,Manager 能够保证返回给 Peer 的 Scheduler 地址和返回给 Scheduler 的 Seed Peer 地址都是可用的。不可用的 Scheduler 和 Seed Peer 不会被 Manager 推给需要进行下载任务的 Peer 或 Scheduler,从而达到隔离异常节点的目的,这也是实例维度的异常隔离,如下图:
高效性
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进群交流)到我们的社区当中。
关于视频回放和课件获取
龙蜥云原生SIG地址链接:
https://openanolis.cn/sig/cloud-native项目地址:
https://github.com/dragonflyoss/Dragonfly2官网:
https://d7y.io/Slack:
https://cloud-native.slack.com/messages/dragonfly/Twitter:
https://twitter.com/dragonfly_ossDeveloper Group Email:
dragonfly-developers@googlegroups.com
—— 完 ——
加入微信群:添加社区助理-龙蜥社区小龙(微信:openanolis_assis),备注【龙蜥】与你同在;加入钉钉群:扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区(OpenAnolis)交流,共同推进龙蜥社区的发展,一起打造一个活跃的、健康的开源操作系统生态!
2.技术门槛高?来看 Intel 机密计算技术在龙蜥社区的实践
3.性能提升1倍,成本直降50%!基于龙蜥指令加速的下一代云原生网关
5.龙蜥社区正式成立 RISC-V ARCH SIG!平头哥、中科院软件所 PLCT 实验室等联合共建