适用场景全新升级!扩展 Dragonfly2 作为分布式缓存系统架构 | 龙蜥技术

简介: 对于不存在的一个远端源地址,Dragonfly无法分发数据应该怎么办?

640.png

文/龙蜥社区开发者

Dragonfly2 简介

Dragonfly 作为龙蜥社区的镜像加速标准解决方案,是一款基于 P2P 的智能镜像和文件分发工具。它旨在提高大规模文件传输的效率和速率,最大限度地利用网络带宽。在应用分发、缓存分发、日志分发和镜像分发等领域被大规模使用。


现阶段 Dragonfly 基于 Dragonfly1.x 演进而来,在保持 Dragonfly1.x 原有核心能力的基础上,Dragonfly 在系统架构设计、产品能力、使用场景等几大方向上进行了全面升级。


Dragonfly 架构主要分为三部分 Manager、Scheduler、Seed Peer 以及 Peer 各司其职组成 P2P 下载网络,Dfdaemon 可以作为 Seed Peer 和 Peer。详细内容可以参考架构文档(链接见文末),下面是各模块功能:

  • Manager:维护各 P2P 集群的关联关系、动态配置管理、用户态以及权限管理等功能。也包含了前端控制台,方便用户进行可视化操作集群。
  • Scheduler:为下载节点选择最优下载父节点。异常情况控制 Dfdaemon 回源。
  • Seed Peer:Dfdaemon 开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点。
  • Peer:通过 Dfdaemon 部署,基于 C/S 架构提供 dfget 命令行下载工具,以及 dfget daemon 运行守护进程,提供任务下载能力。

 

640 (49).png

更多详细信息可以参考 Dragonfly 官网(链接见文末)

问题背景

虽然 Dragonfly 的定位是一个基于 P2P 的文件分发系统,但是分发的文件必须是能够从网络上下载的文件,无论是 rpm 包还是容器镜像内容,最终都是有一个地址源的,用户可以通过 dfget 命令向 dfdaemon 发起下载请求,然后 Dragonfly P2P 系统负责下载,如果数据不在其他 Peer 上,那么 Peer 或者 SeedPeer 自己会回源,直接从源下载数据,然后返回给用户。


但是有些场景我们需要分发的数据是某个节点上生成的,不存在一个远端的源地址,这个时候 Dragonfly 就无法分发这种数据了。所以我们希望 Dragonfly 能够增加对这种场景的支持,其实相当于把 Dragonfly 当作了一个分布式的基于 P2P 的缓存和任意数据分发系统。

扩展 Dragonfly2

所以我们设想中的 Dragonfly 缓存系统架构是这样的:

640 (50).png

  • 每个计算节点上(比如神龙)部署一个 dfdaemon,作为一个 peer 加入 P2P 网络。
  • 接受来自本节点的请求
  • 为其他 peer 提供上传服务
  • 每个 peer 只负责管理自己本地的 cache 数据,不负责回源,回源由业务进程负责
  • 每个集群可以部署一个到多个基于 ECS 的 scheduler 节点。
  • 记录文件 P2P 网络的文件信息
  • 下载调度
  • 多 scheduler 节点解决单点故障问题
  • 每个 cache 系统中的文件都会通过 ringhash 映射到某个 scheduler 上
  • 一个或者多个 Manager 作为集群管理者。
  • 负责向 scheduler 和 peer 节点发送动态配置
  • 收集 metrics 等信息


接口设计

dfdaemon 接口

原来的 daemon 接口:

pkg/rpc/dfdaemon/dfdaemon.proto
// Daemon Client RPC Service
service Daemon{
  // Trigger client to download file
  rpc Download(DownRequest) returns(stream DownResult);
  // Get piece tasks from other peers
  rpc GetPieceTasks(base.PieceTaskRequest)returns(base.PiecePacket);
  // Check daemon health
  rpc CheckHealth(google.protobuf.Empty)returns(google.protobuf.Empty);
}

新增  4 个接口:

service Daemon { 
// Check if given task exists in P2P cache system
rpc StatTask(StatTaskRequest) returns(google.protobuf.Empty);
// Import the given file into P2P cache system
rpc ImportTask(ImportTaskRequest) returns(google.protobuf.Empty);
// Export or download file from P2P cache system
rpc ExportTask(ExportTaskRequest) returns(google.protobuf.Empty);
// Delete file from P2P cache system
rpc DeleteTask(DeleteTaskRequest) returns(google.protobuf.Empty);
}

scheduler 接口

原来的 scheduler 接口:

// Scheduler System RPC Service
service Scheduler{
// RegisterPeerTask registers a peer into one task.
rpc RegisterPeerTask(PeerTaskRequest)returns(RegisterResult);
// ReportPieceResult reports piece results and receives peer packets.
// when migrating to another scheduler,
// it will send the last piece result to the new scheduler.
rpc ReportPieceResult(stream PieceResult)returns(stream PeerPacket);
// ReportPeerResult reports downloading result for the peer task.
rpc ReportPeerResult(PeerResult)returns(google.protobuf.Empty);
// LeaveTask makes the peer leaving from scheduling overlay for the task.
rpc LeaveTask(PeerTarget)returns(google.protobuf.Empty);
}

 

新增 2 个接口,下载复用之前的 RegisterPeerTask()接口,删除复用之前的LeaveTask() 接口:

// Scheduler System RPC Service
service Scheduler{
// Checks if any peer has the given task
rpc StatTask(StatTaskRequest)returns(Task);
// A peer announces that it has the announced task to other peers
rpc AnnounceTask(AnnounceTaskRequest) returns(google.protobuf.Empty);
}

接口请求时序图

StatTask

640 (51).png

ImportTask

640 (52).png

ExportTask

640 (53).png

DeleteTask

640 (54).png

代码实现

目前代码已经合并,可以在 Dragonfly v2.0.3 版本中使用。

upstream PR:

https://github.com/dragonflyoss/Dragonfly2/pull/1227


使用方法

除了增加新的接口之外,我们还增加了一个叫 dfcache 的命令,用于测试,使用方法如下:

- add a file into cache system
dfcache import --cid sha256:xxxxxx --tag testtag /path/to/file
- check if a file exists in cache system
dfcache stat --cid testid --local # only check local cache
dfcache stat --cid testid # check other peers as well
- export/download a file from cache system
dfcache export --cid testid -O /path/to/output
- delete a file from cache system, both local cache and P2P network
dfcache delete -i testid -t testtag

测试及效果

测试方法

通过新增的 dfcache 命令,在一个节点上向 P2P cache 系统中添加不同大小的文件,然后在另外一个节点上针对这个文件做查询、下载、删除等操作。例如:

# dd if=/dev/urandom of=testfile bs=1M count =1024
# dfcache stat -i testid # 检查一个不存在的文件
# dfcache import -i testid testfile
# on another node
# dfcache stat -i testid
# dfcache export -i testid testfile.export

测试效果

两台 ecs,网络走 vpc,带宽 3.45 Gbits/s (约 440MiB/s):

640 (55).png

下载的 ecs 磁盘带宽 180MiB/s 左右:

640 (56).png

640 (57).png

相关阅读链接:

1、Dragonfly1.x 链接地址:

https://github.com/dragonflyoss/Dragonfly

2、Dragonfly 架构文档:

https://d7y.io/zh/docs/concepts/terminology/architecture/

3、Dragonfly 官网链接:

https://d7y.io/

4、龙蜥云原生SIG地址链接:

https://openanolis.cn/sig/cloud-native

—— 完 ——


加入龙蜥社群


加入微信群:添加社区助理-龙蜥社区小龙(微信:openanolis_assis),备注【龙蜥】与你同在;加入钉钉群:扫描下方钉钉群二维码。

640 (5).png

相关文章
|
7天前
|
运维 持续交付 API
从零构建微服务架构:一次深度技术探索之旅####
【10月更文挑战第28天】 本文记录了作者在从零开始构建微服务架构过程中的深刻技术感悟,通过实战案例详细剖析了微服务设计、开发、部署及运维中的关键要点与挑战。文章首先概述了微服务架构的核心理念及其对企业IT架构转型的重要性,随后深入探讨了服务拆分策略、API网关选型、服务间通信协议选择、容器化部署(Docker+Kubernetes)、以及持续集成/持续部署(CI/CD)流程的设计与优化。最后,分享了在高并发场景下的性能调优经验与故障排查心得,旨在为读者提供一套可借鉴的微服务架构实施路径。 ####
41 3
|
2天前
|
Kubernetes Cloud Native 云计算
云原生技术深度解析:重塑企业IT架构的未来####
本文深入探讨了云原生技术的核心理念、关键技术组件及其对企业IT架构转型的深远影响。通过剖析Kubernetes、微服务、容器化等核心技术,本文揭示了云原生如何提升应用的灵活性、可扩展性和可维护性,助力企业在数字化转型中保持领先地位。 ####
|
3天前
|
存储 分布式计算 分布式数据库
风险数据集市整体架构及技术实现
【11月更文挑战第11天】在当今大数据时代,风险数据集市作为金融机构的核心基础设施之一,扮演着至关重要的角色。它不仅为银行、保险等金融机构提供了全面、准确的风险数据支持,还帮助这些机构实现了风险管理的精细化和智能化。本文将深入探讨一种基于大数据Lambda架构设计的风险数据集市整体架构,并详细介绍其底层实现原理及实现方式。
15 3
|
6天前
|
机器学习/深度学习 人工智能 自然语言处理
医疗行业的语音识别技术解析:AI多模态能力平台的应用与架构
AI多模态能力平台通过语音识别技术,实现实时转录医患对话,自动生成结构化数据,提高医疗效率。平台具备强大的环境降噪、语音分离及自然语言处理能力,支持与医院系统无缝集成,广泛应用于门诊记录、多学科会诊和急诊场景,显著提升工作效率和数据准确性。
|
8天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
1月前
|
缓存 监控 API
探索微服务架构中的API网关模式
【10月更文挑战第5天】随着微服务架构的兴起,企业纷纷采用这一模式构建复杂应用。在这种架构下,应用被拆分成若干小型、独立的服务,每个服务围绕特定业务功能构建并通过HTTP协议协作。随着服务数量增加,统一管理这些服务间的交互变得至关重要。API网关作为微服务架构的关键组件,承担起路由请求、聚合数据、处理认证与授权等功能。本文通过一个在线零售平台的具体案例,探讨API网关的优势及其实现细节,展示其在简化客户端集成、提升安全性和性能方面的关键作用。
70 2
|
5天前
|
监控 安全 应用服务中间件
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;
|
7天前
|
缓存 监控 API
探索微服务架构中的API网关模式
随着微服务架构的兴起,API网关成为管理和服务间交互的关键组件。本文通过在线零售公司的案例,探讨了API网关在路由管理、认证授权、限流缓存、日志监控和协议转换等方面的优势,并详细介绍了使用Kong实现API网关的具体步骤。
24 3
|
8天前
|
运维 NoSQL Java
后端架构演进:微服务架构的优缺点与实战案例分析
【10月更文挑战第28天】本文探讨了微服务架构与单体架构的优缺点,并通过实战案例分析了微服务架构在实际应用中的表现。微服务架构具有高内聚、低耦合、独立部署等优势,但也面临分布式系统的复杂性和较高的运维成本。通过某电商平台的实际案例,展示了微服务架构在提升系统性能和团队协作效率方面的显著效果,同时也指出了其带来的挑战。
43 4
|
7天前
|
存储 缓存 监控
探索微服务架构中的API网关模式
探索微服务架构中的API网关模式
22 2
下一篇
无影云桌面