- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
随着大模型流行,GPU 算力资源正变得日益稀缺,传统的“算力跟着存储跑”的策略需要转变为“存储跟着算力跑”。为了确保数据一致性和管理的便捷性,企业通常在特定地区的公有云上选择对象存储作为所有模型数据的集中存储点。当进行计算任务调度时,往往需要人工介入,手动进行数据拷贝和迁移方法不仅成本高昂,还存在管理和维护的复杂性,包括权限控制等问题都极为棘手.
JuiceFS 企业版的 “镜像文件系统” 功能允许用户从一个地区自动复制元数据到多个地区,形成一对多的复制模式。在多云架构下,该功能在确保数据一致性的同时,大幅降低人工运维的工作量.
最新的 JuiceFS 企业版 5.1 中, 镜像文件系统除了支持读取,还新增了可直接写入的功能。本文将探讨镜像文件系统的读写实现原理.
让我们设想这样一个场景,某用户的文件系统部署在北京,但北京地区的 GPU 资源供给不足,而该用户在上海还有可用的 GPU 资源。这时用户想在上海运行模型训练任务,有两个简单的方案:
综上所述,这两个简单的方案都无法令人满意。为此 JuiceFS 企业版提供了镜像文件系统功能。它允许用户为已有文件系统创建一个或多个完整的镜像,这些镜像会自动从源端同步元数据,这样在镜像区域的客户端可以就近访问文件系统,来得到高性能的体验。由于可以只镜像元数据,并且同步过程是自动的,因此相较于之前提到的方案二而言,镜像文件系统在成本与运维复杂性上都有明显的优势.
JuiceFS 企业版的架构与社区版相似,都包括客户端、对象存储以及元数据引擎。区别在于社区版的元数据引擎通常采用第三方数据库如 Redis、TiKV、MySQL 等,而企业版则配备了自研的高性能元数据服务,其中的元数据引擎由一个或多个 Raft 组组成,其架构图如下:
得益于元数据与数据分离的架构设计,用户在创建镜像文件系统时可以独立选择是否镜像元数据和是否镜像数据。两者皆配置镜像的架构如下:
此时,镜像的元数据服务其实跟源端的元数据服务同属一个 Raft 组,只是它们的角色是 learner。在源端发生元数据更新时,服务会自动推送变更日志到镜像端,并在镜像服务中进行回放。这样,镜像文件系统的存在并不会影响源端文件系统的性能表现,只是镜像的元数据版本会略落后一点点.
数据的镜像也是采用异步复制的方式,由指定配置的节点进行自动同步。不同的是,对镜像区域的客户端而言,它仅访问本区域的元数据,但是可以同时访问两个区域的对象存储。实际读取数据时,客户端优先从本区域读取;如果查找不到所需的对象,再尝试从源端区域读取.
一般而言,数据本身的体量较大,再拷贝一份的成本也比较高,因此另一种更推荐的方式是仅镜像元数据,并且在镜像区域构建一套分布式缓存组来提升读取数据的速度,示意如下:
JuiceFS 镜像文件系统推荐使用方法:两区域共用同一个对象存储,镜像区域搭建分布式缓存组来提升性能 。
这种使用方式尤其适合模型训练等可以提前准备数据集的场景。用户在执行训练任务前,先通过 juicefs warmup 命令将所需数据对象拉取到镜像区域的缓存组中,接下来的训练就能在镜像区域内完成,且性能与在源端(假设也配置了类似的分布式缓存组)基本一致.
在之前的版本中,镜像客户端默认为只读模式,因为镜像元数据本身只支持读取,所有的修改操作必须在源端执行。然而,随着用户需求的增加,我们注意到一些新的使用情况,例如在数据训练过程中产生的临时数据。用户希望避免维护两个不同的文件系统,并期望镜像端也能支持少量写操作.
为了满足这些需求,我们在 5.1 版本中引入了 “可写镜像文件系统” 功能。在设计这项功能时,我们主要考虑三个方面:首先是系统的稳定性,这是必须保证的;其次是两端数据的一致性;最后是写入的性能。 最初,我们探索的一种直接方案是允许元数据镜像也能处理写操作。然而,在开发中我们发现,当需要将两端的元数据更新进行合并时,会面临非常复杂的细节处理和一致性问题。因此我们还是维持 “仅源端元数据可写” 的设计。为了处理镜像客户端的写请求,有两个可选的方案:
方案一:客户端将写请求发送至镜像的元数据服务,然后由其转发到源端。源端接收到请求后开始执行操作,并在完成后将元数据同步回镜像端,并最终返回。这个方法的优点是客户端操作简单,只需发送请求并等待响应。然而,这样会使元数据服务的实现变得复杂,因为需要管理请求的转发和元数据的同步。此外,由于链路较长,任何环节的错误都可能导致请求处理出错.
方案二:客户端不仅连接镜像的元数据服务,还直接连接源端的元数据服务。客户端内部进行读写分离,读请求仍然发送至镜像端,但将写请求发送至源端。这种方法虽然使客户端的处理逻辑复杂化,但简化了元数据服务的实现,让它们仅需做很小的适配改动即可。对整个系统而言,这样的做法稳定性也更高.
考虑到服务的简洁性和可靠性,我们最终选择了方案二,具体如下图所示。相较于原来的架构而言,这个方案主要多了一条镜像客户端发送写请求到源端元数据服务的流程.
以下将以创建一个新文件(create 请求)为例对此流程进行详细的介绍。假设源端和镜像端的元数据服务分别是 A 和 B,镜像客户端为 C,请求的完成大致分为 5 步:
C 在第 4 步确认镜像版本已经达到 v1,或者第 5 步收到 wait OK 后返回给上层应用。无论哪种情况,都表示 B 已经包含了本次 create 的修改,因此后续 C 在读取时,就能访问到最新的元数据。另外,由于步骤 2 和 3 几乎是同时发生的,所以大部分情况下 wait 消息都能被立即处理并返回.
镜像客户端的读操作也有类似的检查版本的机制。具体而言,C 在发送读请求前,会先比较其缓存中源端服务和镜像端服务的元数据版本号;如果源端的版本号更新,则会先发送 wait 消息给 B,等到其版本也更新上来后再处理原来的读请求。遗憾的是,C 缓存的源端版本号并不一定是最新的(比如其长时间未发送过写请求的情况),也就是说该机制只是尽可能地让 C 能读到较新的数据,但并不保证其一定是最新的(可能会有小于 1 秒的滞后,与原有的只读镜像相同).
最后,我们通过一个稍复杂些的读写混合的例子,来简要说明使用 JuiceFS 镜像文件系统给用户带来的直接收益.
需求是客户端 C 希望在 /d1/d2/d3/d4 目录下创建一个新文件 newf。按照文件系统的设计,C 需要逐级查找路径上的每一个目录和文件,并在确认文件不存在后再发送创建请求。现假设 C 到 A 和 B 的网络延迟分别是 30ms 和 1ms,C 尚未建立元数据缓存,并且忽略 A 和 B 的请求处理时间.
使用镜像文件系统的情况:C 的读请求都由 B 处理,只有最后的创建文件请求需要发往 A。总耗时大概需要 1 * 2 * 6(mirror lookup) + 30 * 2(source create) + 1 * 2(mirror wait) = 74ms.
没有使用镜像文件系统的情况:如果直接在镜像区域挂载源文件系统,C 的每个请求都需要跟 A 交互,那么总耗时就需要 30 * 2 * 6(source lookup) + 30 * 2(source create) = 420ms,是前者的 5 倍还多.
在 AI 研究中,由于 GPU 资源的成本极高,多云架构已成为众多企业的标配。通过使用 JuiceFS 镜像文件系统,用户可创建一个或多个完整的文件系统镜像,这些镜像会自动从源端同步元数据,使得镜像区域的客户端能够就近访问文件,从而提供高性能并减少运维工作量.
在最新的 JuiceFS 5.1 版本中,我们对镜像文件系统进行了重要的优化,新增了允许写入的功能,使得企业能够在任何数据中心通过统一的命名空间访问数据。同时在保证数据一致性的前提下,享受就近缓存的加速效果。希望通过这篇文章分享的实现思路与尝试,为用户提供一些见解与启发.
最后此篇关于详解JuiceFS在多云架构下的数据同步与一致性的文章就讲到这里了,如果你想了解更多关于详解JuiceFS在多云架构下的数据同步与一致性的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
是否可以简化在裸机上运行的这条链: 具有随时间变化的副本数的 StatefulSet 服务 使用 proxy-next-upstream: "error http_502 timeout invali
很难说出这里要问什么。这个问题模棱两可、含糊不清、不完整、过于宽泛或夸夸其谈,无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开,visit the help center . 关闭 1
我需要为应用程序制定架构。它专为销售产品而设计。 系统每天将接受大约 30-40k 的新产品。它将导致在表 product 中创建新记录。 系统应保留价格历史记录。用户应该能够看到产品 A 的价格在去
我需要一些帮助来理解 PHP 的内部工作原理。 还记得,在过去,我们曾经写过 TSR(Terminate and stay resident)例程(pre-windows 时代)吗?一旦该程序被执行,
1.Nginx 基础架构 nginx 启动后以 daemon 形式在后台运行,后台进程包含一个 master 进程和多个 worker 进程。如下图所示: master与
本文深入探讨了Kubernetes(K8s)的关键方面,包括其架构、容器编排、网络与存储管理、安全与合规、高可用性、灾难恢复以及监控与日志系统。 关注【TechLeadCloud】,
我知道 CNN 的工作原理,包括每一层的用途(Dropout、Pooling 等)。但是,在为新数据集设计 CNN 时,我不知道要使用多少个 Conv-Relu-Pool 层,在最终获得输出之前我应该
在基于 REST 的架构中,资源和方法之间有什么区别。有吗? 最佳答案 资源是您的应用程序定义的东西;它们与物体非常相似。方法是 HTTP 动词之一,例如 GET、POST、PUT、DELETE。它们
我想用 oneOf仅在 xyType 的值上不同的模式属性(property)。我想要其中两个:一个是 xyType设置为 "1"第二个在哪里xyType是 任何其他值 .这可以使用 json 模式完
寻求 PHP 架构师的建议! 我对 PHP 不是很熟悉,但已经接管了一个用该语言编写的大型分析包的维护工作。该架构旨在将报告的数据读取到大型键/值数组中,这些数组通过各种解析模块传递,以提取每个模块已
这些存在吗? 多年来,我一直是大型强类型面向对象语言(Java 和 C#)的奴隶,并且是 Martin Fowler 及其同类的信徒。 Javascript,由于它的松散类型和函数性质,似乎不适合我习
我已经阅读了 Manning 的 Big Data Lambda Architecture ( http://www.manning.com/marz/BD_meap_ch01.pdf ),但仍然无法
在过去的几年里,我做了相当多的 iOS 开发,所以我非常熟悉 iOS 架构和应用程序设计(一切都是一个 ViewController,您可以将其推送、弹出或粘贴到选项卡栏中)。我最近开始探索正确的 M
我有以下应用程序,我在其中循环一些数据并显示它。 {{thing.title}} {{thing.description}}
昨天我和我的伙伴讨论了我正在开发的这个电子购物网站的架构。请注意,我为此使用 ASP.NET。他非常惊讶地发现我没有将添加到购物车的项目保留在 ArrayList 或其他通用列表中,而是使用 LINQ
我正在使用在 tridion 蓝图层次结构中处于较低位置的出版物。从蓝图中较高级别的出版物继承的一些内容和模式不适合我的出版物,并且永远不会被我的出版物使用。 我将跟进添加这些项目的内部团队,并尝试说
我目前已经在 Cassandra 中设计了一个架构,但我想知道是否有更好的方法来做事情。基本上,问题在于大多数(如果不是全部)读取都是动态的。我构建了一个分段系统作为应用程序服务,读取动态自定义查询(
我正在按照 documentation 中给出的 icingaweb UI v 2.0 布局执行在服务器上设置 icinga 的步骤。 。我成功进入设置页面,该页面要求您输入 token ,然后按照步
我必须保存来自不同社交媒体的用户的不同个人资料。例如用户可能有 1 个 Facebook 和 2 个 Twitter 个人资料。如果我保存每个配置文件它作为新文档插入不同的集合中,例如 faceboo
我的团队使用 Puppet 架构,该架构目前可在多个环境(流浪者、暂存、生产)中容纳单个应用程序。 我们现在想要扩展此设置的范围以支持其他应用程序。他们中的许多人将使用我们已经定义的现有模块的子集,而
我是一名优秀的程序员,十分优秀!