V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
strahe
V2EX  ›  服务器

有没有一种 SSD 和 HDD 的混合文件系统方案?

  •  
  •   strahe · 2020-01-20 19:04:19 +08:00 · 7456 次点击
    这是一个创建于 1547 天前的主题,其中的信息可能已经有所发展或是发生改变。

    现在有个需求如下:

    需要设计一个一个存储系统, 一开始数据是空的, 需要大量写入数据, 写入需求远大于读取.数据可能是 PB 级的(总数据量, 单节点不需要这么大).

    迫于成本, 不可能全部使用 SSD, 但系统非常在意写入性能. 有没有一种可能性(或者现成的技术方案), 将 SSD 和 HDD 组合为混合文件系统, 写入先写到 SSD, 文件系统底层再移动到 HDD.应用无感知?

    比如一台 2U, 12 盘位的服务器, 插入 2SSD+10HDD.写入性能可以接近 SSD, 读取性能接近 HDD 即可.

    22 条回复    2020-01-22 13:00:16 +08:00
    Remember
        1
    Remember  
       2020-01-20 19:08:48 +08:00
    zfs 啊, 加 ssd 做 L2ARC 缓存就好,就是内存需求很大.
    secondwtq
        2
    secondwtq  
       2020-01-20 19:10:08 +08:00
    你写太快把 SSD 挤满了不还是没办法 ...
    stiekel
        3
    stiekel  
       2020-01-20 19:10:33 +08:00
    OS X 有个 Fusion Drive。Linux 甚至都不需要 SSD,直接 RAM + HDD https://www.anandtech.com/show/3963/zfs-building-testing-and-benchmarking/2
    secondwtq
        4
    secondwtq  
       2020-01-20 19:11:31 +08:00
    @Remember 写入的话应该是加 SLOG 吧
    strahe
        5
    strahe  
    OP
       2020-01-20 19:14:20 +08:00
    @Remember
    @stiekel

    多谢, 我看看
    strahe
        6
    strahe  
    OP
       2020-01-20 19:14:47 +08:00
    @secondwtq 能把多个 hdd 性能占满就满足了.
    Sylv
        7
    Sylv  
       2020-01-20 19:15:30 +08:00 via iPhone
    bcache 了解一下。
    strahe
        8
    strahe  
    OP
       2020-01-20 19:21:27 +08:00
    @Sylv 多谢, 我了解下.
    gstqc
        9
    gstqc  
       2020-01-20 19:31:55 +08:00 via Android
    如果持续写入速度大于 HDD 速度之和,写满缓存后,最终还是在等待 HDD 写入
    murmur
        10
    murmur  
       2020-01-20 19:35:34 +08:00
    有的,现在的 NAS 都是支持 ssd 缓存的,看翼王的视频就知道了
    还有 iMac 这种一万多的电脑还在用机械硬盘
    shoaly
        11
    shoaly  
       2020-01-20 19:36:10 +08:00
    @gstqc 实际情况是 峰值写入速度会超过 hdd 的读写速度, 但是峰谷 又跑不满 hdd , 所以有一个缓存作为 hdd 的前置倒是有用
    xenme
        12
    xenme  
       2020-01-20 20:03:41 +08:00 via iPhone
    看需求峰值多大和需要多大缓存。
    小的 raid 卡自带的 cache (内存)就能顶住

    这个基本得你的数据非常具体才能推荐具体多少。
    专业卖存储的还分一堆型号,cache 级别也不同,场景也不一样
    tigerstudent
        13
    tigerstudent  
       2020-01-20 20:30:32 +08:00 via Android
    现在 SSD 降价了,这个方案的价值没那么大了
    mcfog
        14
    mcfog  
       2020-01-20 20:39:54 +08:00 via Android
    RocksDB
    also24
        15
    also24  
       2020-01-20 20:52:11 +08:00
    @Remember #1
    L2ARC 是读缓存,不是写缓存啊。

    @secondwtq #4
    ZIL/SLOG 更大的作用似乎是降低写入延迟和保证数据的安全性。
    我看到的一个说法是,每 5 秒钟数据就会被刷新写入到最终位置,确实如此的话,似乎对 『连续写入』的帮助不大。

    > OpenZFS aggregates your writes into “transaction groups” which are flushed to their final location periodically (every 5 seconds in FreeNAS & TrueNAS).
    > 来源: https://www.ixsystems.com/blog/o-slog-not-slog-best-configure-zfs-intent-log/
    locoz
        16
    locoz  
       2020-01-20 21:03:55 +08:00 via Android
    unraid ?
    also24
        17
    also24  
       2020-01-20 21:22:08 +08:00
    个人蛮推荐 Windows Server 分层存储的:

    是存储池带的功能,企业级,如果使用 Win 系,可以考虑下
    https://docs.microsoft.com/zh-cn/windows-server/storage/storage-spaces/understand-the-cache
    strahe
        18
    strahe  
    OP
       2020-01-20 22:04:21 +08:00
    @also24 谢谢, 应用原因,可以确定不用 win.
    strahe
        19
    strahe  
    OP
       2020-01-20 22:05:03 +08:00
    @xenme
    @also24 我应用场景主要是持续大文件写入.
    also24
        20
    also24  
       2020-01-20 22:07:04 +08:00
    @strahe #18
    那就考虑 bcache / LVM cache / dm-cache 吧

    不过说实话,PB 级别的话,应该要考虑直接 CEPH 了吧,CEPH 是支持分层缓存的:
    http://docs.ceph.org.cn/rados/operations/cache-tiering/
    julyclyde
        21
    julyclyde  
       2020-01-21 17:40:38 +08:00
    这东西还没成熟就已经失去意义了
    现在流行纯 SSD
    fqzz
        22
    fqzz  
       2020-01-22 13:00:16 +08:00
    “写入性能可以接近 SSD, 读取性能接近 HDD 即可”
    各种缓存方案都有很可能退化,读写都是 hdd 的速度,或者更差。尤其大量持续写,严重依赖缓存大小。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5486 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 09:15 · PVG 17:15 · LAX 02:15 · JFK 05:15
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.