JuiceFS Office Hours 近期问题回顾(2021 年 9 月及 10 月)

高昌健 2021.11.17

什么是 JuiceFS Office Hours?

JuiceFS Office Hours 是每周三 17:00-18:00 的线上交流活动,主要目的是通过每周一次线上交流的形式,介绍和演示 JuiceFS 的新特性、解答用户疑问、了解使用场景及相关技术交流等。

要怎么参加 JuiceFS Office Hours?

请在每周三 17:00 左右点击这个链接:https://meeting.tencent.com/dm/nVMnpAWkaFgu

哪里能看到历史收集的问题和回答?

历史收集的问题和回答会定期更新到 JuiceFS 官方博客,请订阅官方博客了解最新动态。

能详细介绍一下 JuiceFS CSI Driver 0.10.0 以后的新架构和新特性吗?

JuiceFS CSI Driver 自 0.10.0 开始对架构设计做了比较大的升级,主要改动是将原本运行在 CSI Node 容器中的 JuiceFS 挂载进程独立出来,用单独的 pod 来运行。这次架构升级的主要目的一方面是增强系统的稳定性和可观测性,另一方面是提供平滑升级 CSI Driver 的能力。有关 0.10 全新架构的解读可以查看官方博客

0.10.0 发布以后发现了一些比较关键的 bug,因此又陆续发布了多个 bug 修复版本。此外在近期发布的 0.10.5 中还新增了对 ReadOnlyMany 的支持,可以支持只读模式挂载。

func (s *sliceReader) run() 在这个函数实现中大量的 lock 和 unlock 逻辑能加上注释或者有专门的文章讲解一下吗?

这块逻辑的确比较复杂,后续我们计划用专门的文章进行代码讲解(不仅限于这一个函数)。

如果负责 mount 的 pod 异常挂掉,会影响到业务吗?影响范围?解决方案?

会,会影响到挂掉的 node 上使用该 PV 的所有 pod。解决方案只能删除 pod,重建 pod。

JuiceFS CSI Driver 如何平滑升级?

如果只升级 JuiceFS CSI Driver,已经存在的 PV 不会受到影响,还可以继续使用旧版本的 JuiceFS 客户端,新的 PV 会使用新版本的 JuiceFS 客户端;如果需要升级 JuiceFS 客户端,必须删除所有 pod 及 PV,重新创建 PV 和 pod。

Redis 作为元数据引擎是如何保证数据持久化的?

关于 Redis 如何保证数据持久化在「Redis 最佳实践」文档中有详细描述。简单讲 Redis 默认是通过 1 秒落盘一次 AOF 以及定期 dump RDB 来实现,因此极端情况可能会丢失最近 1 秒的数据。但是 Redis 支持把 AOF 落盘频率改成每次写入时同步持久化,不过这个配置更改会对写入性能有一定负面影响。

如果你想了解不同 Redis AOF 配置的性能对比,请参考「元数据引擎性能对比测试」文档。

JuiceFS 客户端是否有文件数据块的缓存(类似 page cache)?如果有大小是可配置的吗?

有,且缓存大小可配置。关于 JuiceFS 客户端缓存功能的详细介绍请参考「缓存管理」文档。

如果想要测试 JuiceFS 商业版元数据引擎的高可用,请问有什么测试建议?

JuiceFS 商业版元数据引擎是 Juicedata 团队基于 Raft 自研的分布式存储引擎,在默认 3 节点的集群配置下,允许任意 1 个节点宕机。因此如果要测试高可用可以通过随机宕机 1 个节点,并观察集群状态、自动恢复周期、对应用的影响等指标。

有考虑过实现数据存储服务,而不是使用 S3 作为后端存储?实现难点是什么?

暂时没有计划实现一个独立的数据存储服务,对象存储作为公有云上的一个标准基础设施应用已经非常广泛,暂时没有必要重复造轮子。

JuiceFS 有 Slack 的 workspace 么?现在的社区主要有哪些的 channel?

JuiceFS 有官方的 Slack workspace,可以点击这里加入。在 JuiceFS 的 GitHub 首页以及 JuiceFS 官网也都有加入 Slack 的入口。

目前 Slack 频道交流以英文为主,也有一个专门针对中文用户的 #chinese-users 频道。

CSI node driver 升级不影响 mount pod,如果 mount pod 升级的话,是否应用 pod 需要停止访问?这方面有哪些优化思路?

是的,如果要升级 mount pod 必须将当前节点所有使用对应 PV 的 pod 停掉。

一种优化思路是把 container 里 volumeMountsmountPropagation 设置成 Bidirectional ,这样如果 mount pod 挂了,只要能重建挂载点 pod,上层的业务 pod 就不受影响。但是这个方法有一个很大的限制,业务 pod 必须设置 Privileged 为 true,相当于获得了 root 权限。

另一种优化思路是当 mount pod 退出时,保存 FUSE 层的一些状态,这样当 mount pod 重建以后再恢复之前的状态。这个方案相对复杂,目前还没有成熟的参考对象。

2021.11.17 更新:JuiceFS CSI Driver v0.10.7 已经支持第一种方案,详情请参考文档

JuiceFS + S3/Ceph 的模式在大数据场景下,与原生的 HDFS 相比,性能如何?

在基于 TPC-DS 的评测中,当有缓存的情况下,JuiceFS 可以做到与 HDFS 性能相当。同时 JuiceFS 也能提供和 HDFS 类似的数据本地性(data locality)特性,确保缓存数据的命中率。

JuiceFS FUSE 接口和 native 接口的性能差异有 benchmark 吗?

暂时没有做过这类测试。从经验上来说,FUSE 接口的性能开销在整体读写链路上的耗时占比比较小,对象存储会首先成为瓶颈。

测试 warmup(版本 0.17.0)时发现一个现象,当 warmup 指定为目录时耗时较少,而通过脚本遍历目录中的文件依次执行 warmup 时,耗时会明显变多。请问可能是什么原因造成的?以及有没有办法加快 warmup 的速度?

warmup 的参数为目录时的实现是将需要预热的目录发送给 JuiceFS 挂载点,JuiceFS 挂载点会遍历整个目录再并行预热缓存(并行度可通过 --threads 选项控制,默认为 50)。而自行遍历目录,每次执行 warmup 时只指定单个文件就没法并行处理,自然效率会降低不少。

建议运行 warmup 时直接指定需要预热的目录,或者如果不想整个预热目录里的所有文件也可以通过 --file 选项指定需要预热的文件列表(一行一个文件路径)。预热的并行度可通过 --threads 选项控制。默认预热是前台执行,即 warmup 命令会等待全部文件预热完成才会返回,如果不想等待可加上 --background 选项。

更新容量后,mount 点数据未更新是什么原因?

通过 juicefs format --capacity 更新容量以后立即执行 df 不一定能马上看到更新后的值,需要等待最多 1 分钟时间才会生效。有兴趣的同学可查看相关代码