V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
mushokumunou
V2EX  ›  问与答

glusterfs+zfs 存海量小文件,是不是选错方案了?

  •  
  •   mushokumunou · 2021-01-23 08:54:15 +08:00 · 2408 次点击
    这是一个创建于 1398 天前的主题,其中的信息可能已经有所发展或是发生改变。

    iops 性能很差,是不是选错方案了? 本来想优化下的,搜了不少关于小文件+gluster 和 zfs 的关键字,发现小文件不适合。 遂对选型产生了质疑。

    一开始只是想简单的组个软 raid,集个群做存储后端而已。 没太在意应用场景。感觉方向错了。。。。

    文件基本在 256k,最大 1m,用于 ipfs 存储。

    8 条回复    2021-01-23 20:04:35 +08:00
    catror
        1
    catror  
       2021-01-23 09:55:48 +08:00 via Android
    glusterfs 确实不太适合,可以试试 ceph
    isnullstring
        2
    isnullstring  
       2021-01-23 10:52:16 +08:00
    同问,我现在用 ZFS,还没上集群,就已经开始有点点慢
    siknet
        3
    siknet  
       2021-01-23 11:35:32 +08:00 via Android
    借问一下,WIN10 下有什么性能强于 ntfs 且易于读写的文件系统吗?
    ohao
        4
    ohao  
       2021-01-23 11:43:27 +08:00 via iPhone
    这个要看使用场景
    是密集型读 还是密集型写 还是均衡读写
    还有数据增长速度

    确定了在做个各种文件系统的性能对比

    如果在 200T 内
    一般的 sata + hw raid 6+ ssd cached 架构绰绰有余
    一组 3 台 200T 上下的 满足大部分使用场景需求了
    对应调整下 raid 的读写缓存策略
    文件系统使用 xfs,小文件存储 块那个设置小点节省空间
    ferock
        5
    ferock  
       2021-01-23 12:09:17 +08:00 via iPhone
    zfs 性能不行
    ferock
        6
    ferock  
       2021-01-23 12:09:38 +08:00 via iPhone
    小文件场景
    siknet
        7
    siknet  
       2021-01-23 12:30:34 +08:00 via Android
    @ohao 单个项目 500-1000G,6 台机器同时读写,将近 100 万个文件,现在是放在 PM981 2T 里面跑,之前临时放在机械盘里面跑,感觉慢了一倍都不止。。。。
    mushokumunou
        8
    mushokumunou  
    OP
       2021-01-23 20:04:35 +08:00
    @ohao 均衡读写
    主要是小文件,看见 zfs 是动态调整 inode 的,感觉无限用不完,就上了 zfs,还有快照,send/receive 比 rsync 舒服多了。等 ubuntu 支持 zfs2.0 了,就更爽了。汗,就是冲动。
    glusterfs 纯粹图个简单易上手,没想太多。而且初期两个存储机集群下,做个分布卷,效率还是很高的。后期不够也不用损毁数据,直接分布+复制可以改型,光看优点了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   993 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 19:50 · PVG 03:50 · LAX 11:50 · JFK 14:50
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.