关于云存储:JuiceFS-v10-beta3-发布支持-etcdAmazon-MemoryDBRedis-Cluster

83次阅读

共计 3371 个字符,预计需要花费 9 分钟才能阅读完成。

JuiceFS v1.0 beta3 在元数据引擎方面持续加强,新增 etcd 反对小于 200 万文件的应用场景,相比 Redis 能够提供更好的可用性和安全性。同时反对了 Amazon MemoryDB for Redis 和 Redis Cluster。至此,JuiceFS 反对的元数据引擎有:

  1. Redis:包含单机、Sentinel 和 Cluster 模式,适宜小于 1 亿文件,同时谋求高性能的场景。基于 AOF 的异步复制有大量数据失落的危险,Amazon MemoryDB for Redis 应用同步数据复制,数据安全性更高;
  2. 关系型数据库:包含 MySQL、MariaDB、PostgreSQL,适宜数据安全要求高,性能要求不高的场景;
  3. TiKV:适宜海量文件(1 亿以上),对性能与数据安全都有高要求的场景,但运维门槛比后面的计划高;
  4. etcd:适宜小于 200 万文件并且可用性与数据安全要求高的场景;
  5. 嵌入式数据库:包含 BadgerDB 和 SQLite,适宜不须要多机拜访的场景应用。

除了元数据引擎的降级,JuiceFS S3 网关也提供了多租户、权限设置等高级性能,同时反对了非 UTF-8 编码的文件名。

本次更新共有 22 位社区贡献者 参加奉献了 超过 240 次提交,感激每一位的付出,也欢送正在读文章的你参加到 JuiceFS 社区中来。

上面,来为你解读一下 JuiceFS v1.0 beta3 的具体变动。

新增 etcd 元数据引擎

etcd 是一个数据牢靠的分布式 KV 存储系统,在 Kubernetes 中宽泛应用,etcd 的数据批改会同步写到磁盘上,保障数据安全,通过 Raft 共识算法实现数据复制和故障切换,实现高可用。相比应用异步落盘和异步复制的 Redis 有更好的数据安全性和可用性。

但 etcd 可能撑持的数据规模比拟无限,从理论测试来看,小于 200 万文件时,是个不错的抉择。

应用办法与其余引擎相似,协定头为 etcd://,例如:

# 创立文件系统
$ juicefs format etcd://localhost:2379/myjfs jfs-etcd
# 挂载文件系统
$ juicefs mount -d etcd://localhost:2379/myjfs /mnt/jfs

对于 etcd 的性能体现,请查看《元数据引擎性能测试文档》。

反对 Redis Cluster 和 Amazon MemoryDB for Redis

因为 JuiceFS 依赖数据库事务保证数据强一致性,而 Redis Cluster 采纳分片机制将数据扩散在不同的分片上,但不反对跨分区的事务,导致不能应用 Redis Cluster 作为 JuiceFS 的元数据引擎。

v1.0 beta3 通过应用固定前缀的形式让所有的数据都调配到繁多的 Redis 分区中,从而保障了 Redis 事务性能不受影响。这个办法不能充沛享受 Redis 集群的数据分片能力,但能够取得数据复制和选举方面的便当(相似于哨兵模式)。另外,这种前缀形式相似于单机模式的多库性能,有有限的扩大能力,实用于有很多小规模文件系统的场景。

AWS 最新公布的 MemoryDB for Redis 只提供集群模式,相比 ElastiCache 或者本人保护的 Redis,它的同步数据复制提供了更高的数据安全保障(但写入提早更高),实用于对数据的安全性要求十分高,写少读多的场景。因为所有元数据都会集中在单个分片中,举荐应用一个分区加一份复制的部署模式(相似于主从模式),后续通过更换为更大内存的节点形式来扩容。

碎片提早清理性能

JuiceFS 在读写文件时,如果该文件的数据碎片过多,就会主动触发碎片合并流程,将碎片聚合成大段数据并清理掉旧的碎片。

然而,在元数据迁徙、故障复原等场景中,用户可能须要应用旧版本的元数据备份,此时如果数据碎片已被清理,就会导致相干文件读取失败。

另外,当 Redis 失落大量元数据时,也可能因为局部文件应用了曾经被清理的碎片而损坏。

为了解决上述问题,在 v1.0 beta3 中退出了 碎片提早清理性能,对于开启了回收站的文件系统,碎片会被提早删除,超过设定的回收站工夫后才被主动清理,也能够用 gc 命令手动清理。

加强 Sync 命令

v1.0 beta3 进一步调整了 Sync 命令的性能,使其在用法上与大家熟知的 rsync 工具尽量保持一致,缩小上手老本。

调整了用于过滤文件列表的 --include--exclude 的用法,跟 rsync 保持一致,容许指定多个过滤规定,依据它们在命令行中的程序和 Bash 通配符进行匹配,简直能够实现任意汇合的文件筛选须要,更具体的用法请参照 rsync 的文档。

Sync 命令默认会拷贝符号链接的指标文件,能够通过 --links 参数调整为拷贝符号链接自身。

另外,还加了一个 --limit 参数用于限度操作的文件个数,当设置为 1 时示意不进行递归遍历。

S3 网关性能降级

JuiceFS 的 S3 网关是基于 MinIO 的晚期版本实现的,并且裁剪了一些非必要的性能。新版本的 MinIO 改用了 AGPL 协定,不能被 JuiceFS 间接降级应用。

当初采取了反向集成的策略,在反对网关性能的最新版 MinIO 上集成 JuiceFS v1.0 beta3,整体基于 AGPL 协定开源,这样能够应用新版本的 MinIO 提供的多租户、权限设置等更多高级性能,详情请参考 S3 网关文档。

JuiceFS 依然内置了根底版的 S3 网关性能,而更残缺的版本请应用这个反向集成的版本,代码请见。

其它新性能

  1. 反对 TLS 加密连贯 TiKV 元数据引擎。
  2. 创立文件系统时,能够通过 --hash-prefix 选项为数据写入对象存储时增加哈希前缀。很多对象存储有基于前缀的 QPS 限度或者零碎瓶颈,通过该个性能够绕过这类限度以取得更好的性能。留神,已有数据写入的旧文件系统无奈更改此选项。
  3. 挂载文件系统时,能够通过 --heartbeat 选项设置客户端的心跳距离,这在一些关注故障切换工夫的场景下能发挥作用。留神,默认的心跳过期工夫已由 60s 调整为 12s。
  4. 数据存储减少 Oracle Object Storage 反对。
  5. Java SDK 反对上报监控指标到 Graphite 或者兼容的零碎。
  6. SQL 引擎反对非 UTF-8 编码的文件名,已有的文件系统须要降级客户端后再批改数据库的表构造。

其它变动

  1. 在新建文件系统时,会主动在数据存储中写入一个记录了 UUID 的占位对象,防止其余文件系统重复使用雷同的数据存储造成混同。
  2. juicefs dump 命令会自动隐藏对象存储的 secret key 避免透露敏感信息。
  3. 改用加密模式存储对象存储拜访密钥,减小安全隐患;已有的文件系统可通过 juicefs config META-URL --encrypt-secret 命令调整加密模式。留神,批改后旧版客户端将无奈挂载。
  4. 调整元数据默认备份机制,当文件数多于一百万时,须要用户显式指定备份周期。
  5. 在 Linux 下应用非 root 用户挂载时,将默认的缓存和日志目录改为此用户的家目录,防止因权限有余而失败。
  6. 改良了往 Redis 和 SQL 数据库导入大型目录(超过一百万文件)的能力。
  7. 为关系型数据库所有表构造减少主键,晋升日志复制性能,详情参考。

降级倡议

请在降级新版前留神评估以下几个变动:

会话治理格局调整

自 v1.0 beta3 开始,会话治理应用了新的格局,旧版本客户端通过 juicefs status 或者 juicefs destroy 无奈看到 v1.0 beta3 的会话,新版客户端能够看到所有会话。

SQL 表结构调整,反对非 UTF-8 编码文件名

为了更好地反对非 UTF-8 编码的文件名,在 JuiceFS v1.0 beta3 中批改了关系型数据库的表构造。

对于正在应用 MySQL、MariaDB、PostgreSQL 的用户,如果须要让已有的文件系统反对非 UTF-8 编码的文件名,须要手动批改表构造,详情请参考文档。

修复的 Bug

  1. 修复了元数据备份失败时可能导致局部内存未及时开释问题。
  2. 修复了应用 SQL 作为元数据引擎时,扫描函数返回后果可能不正确问题。
  3. 修复了应用 juicefs load 命令加载元数据时局部计数器可能统计不精确问题。
  4. 修复了对象存储开启多 buckets 时,扫描对象列表后果不正确问题。
  5. 修复了应用 Ceph RADOS 做对象存储时,对象数过多时扫描卡住问题。

具体的 Bug 修复列表请看 https://github.com/juicedata/…

快去下载体验吧,Juicedata/JuiceFS

正文完
 0