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

NAS 存储的安全+便捷+成本的最优平衡思路探讨,及单盘位最高容量疑问

  •  
  •   sicifus · 107 天前 · 3236 次点击
    这是一个创建于 107 天前的主题,其中的信息可能已经有所发展或是发生改变。

    先给 V 站大佬们汇报一下所谓"最优平衡"的思路,纯粹从个人的"穷+我全都要"的立场出发。若不合理还望指正并轻拍。要点如下:

    安全+便捷角度

    1 )不用 RAID5 ,大容量单盘失效后重建失败概率过高(Ref1),不展开。

    进一步地,不用任何奇偶校验的 RAID (包含群晖的 SHR ),避免重建伤盘。(阵列的核心诉求是保证实时性,而不是数据安全性)

    2 )通用数据采用不同存储池下的 1+1 备份实现。工具拟用文件级备份的 Snapraid ,可以实时同步,也可以定期冷备。

    (题外话:核心数据额外有 3 地 4 中心机制,即工作机、公司服务器、云、NAS (待增),保证安全性和实时性)。

    引入成本角度后

    3 )无需一次性配满磁盘,而是根据数据增量分步按需配置,第一次采购 2 块磁盘(假设为 14T )组 1+1 ,之后每隔若干年采购 1 块容量翻倍的磁盘,并基于 Mergerfs 实现存储池的平滑扩容。步骤略见下图: 存储池扩容

    4 )更进一步地,计算、存储分离(解耦):算力的提升&降本的速度明显快于存储,因此不想采用一体式 NAS 的方式,更倾向于小主机( Homelab/算力)+磁盘柜的方式。

    小结一下以上思路,即

    1 ) Mergerfs+Snapraid+磁盘逐步翻倍扩容策略,优点:

    • 低成本(对标 raid5 )
    • 数据 1+1 备份(对标 raid5 )
    • 文件级备份,无重建失败 or 伤盘概率(对标 raid/shr 等校验恢复机制)
    • 可用 ext4 ,读写性能和稳定性更优(对标 shr 等 btrfs 文件系统)

    2 )算存分离,优点:低成本、高性能等。

    疑问

    要实现图示的存储逐步翻倍扩容,就要确保磁盘柜(或者一体化 NAS 机)的单盘位可识别容量要>50~60T 。 但好像目前市面上的产品宣传口径都是跟着主流 HDD 的最大容量走的(一般是 16T-20T 左右)。

    我的疑问是,撇开厂家的宣传策略不谈,从技术上看,

    磁盘柜/一体式 NAS 的最大单盘容量的受限条件实际是什么?是主板?是 XX 接口的类型?是总线的带宽?还是系统里的默认设置?

    或,有没有简易+便宜地提升可识别单盘容量的方法?

    谢谢大家~~

    63 条回复    2024-01-16 20:56:36 +08:00
    mantouboji
        1
    mantouboji  
       107 天前   ❤️ 1
    单个硬盘的容量越大,里面的盘片和磁头数就多,电机负载重,长期看来可靠性堪虞。还是以 4T 8T 容量的多个驱动器组建 RAID5 为上策,用多盘位的笼子和大容量的电源,可靠性和可用性都容易保证,rebuild 事件也能控制在一天之内。
    sicifus
        2
    sicifus  
    OP
       107 天前
    @mantouboji #1 多谢回复。
    容量-可靠性反比的建议我会再重新思考下。
    不过 raid 仍然不打算组建,风险收益比太低了。
    Evovil
        3
    Evovil  
       107 天前   ❤️ 1
    撇开技术,时间和精力也是很重要的资源。 最优平衡是:把钱花到自己能承担的且不受影响的最高,以换取时间和精力的平衡性。
    如果是我:
    1. 服务器+企业级硬盘( SAS )+raid10
    2. 买 NAS ,一体式 nas 的最大优势是省钱省时间省精力。
    3. 存算分离,纯 nas 为啥要存算分离? 普通 nas+docker 可以满足较多低敏感业务,如果是要高性能可靠性的计算存储分离: 买存储服务器+HBA/SAN
    4. 建议提升单盘容量的方法: 一步到位买大点。

    数据无价,这个有两方面的解读:
    1. 当你数据丢失后你发现,数据也没有那么重要
    2. 当你数据丢失后,你发现数据太 tm 重要了

    如果是 2 ,该花的钱还是得花,要不然企业花冤大头的钱买 SAS 干啥?
    geniussoft
        4
    geniussoft  
       107 天前 via iPhone   ❤️ 2
    完全就是看别人纸上谈兵太多,各种不合理:

    1. 你实测过重建么? URE 纯粹纸上谈兵,实际很离谱。而且,即使不幸发生 URE ,一般顶多一个文件有静默损坏罢了(群晖的话,还会告诉你哪个文件坏了)。

    2. 性能的问题,你要那么多性能做什么,难道在 NAS 上炼丹么……一般跑满万兆就可以。

    3. 不做条带 RAID ,速度难以提高,日后很可能要难受。

    4. 硬盘柜是很多人的理想选择,很不幸,市面上的产品基本都很烂。实际上真正的伤盘,基本都是硬盘柜干的。

    5. 群晖中高端型号一般支持的单个 Volume 为 108T (你可以使用多个 volume ),企业级型号也有支持 200T 和 1PB 的。
    eraserking
        5
    eraserking  
       107 天前
    URE 的事情就瞎扯。还 4 块盘 4T 重建失败机率超五成,一听就是完全脑补。
    sicifus
        6
    sicifus  
    OP
       107 天前
    @Evovil #3
    感谢回复。我逐条回应一下:
    0."时间和精力也是很重要的资源……把钱花到自己能承担的且不受影响的最高",对我来说就是存储堆上 1+1 ,不考虑重建的等待恢复时间成本。
    1."服务器+企业级硬盘",我开宗明义说了穷,而且企业级硬盘的噪声没法接受(家里面积太小,说白了还是穷);"raid10",相比 1+1 备份的优势在哪里?
    3."纯 nas 为啥要存算分离",先说这条,没说玩纯 nas ,打算把算力设备作为 homelab 来着。
    2."一体式 nas 的最大优势是省钱省时间省精力",然而并不是。本来就有搭建 homelab ( aio )折腾的需求,这种情况下一体式 NAS 相比下感觉没什么优势。
    4."一步到位买大点",就是想要买大点来着,不是没找到符合单盘位 50-60T 容量的产品么。
    sicifus
        7
    sicifus  
    OP
       107 天前
    @geniussoft #4
    诉求是个性化的需求,可能是没有通用合理性。
    虽然语气有点生硬,仍然感谢了。
    Hopetree
        8
    Hopetree  
       107 天前   ❤️ 1
    我看了好多 NAS 的讨论,我自己有个结论就是重要数据(丢失很严重的)不要放到自己的 NAS ,网盘更可靠,而自己的 NAS 更多是放一些拿取方便,丢失也不至于伤筋动骨的数据。就像我自己就是这样玩的,我重要数据是分开放的,比如代码这种,自动同步到 icloud ,每月保底的 6 元。然后其他大文件(不常用)放百度云或者阿里云,然后一些备份,媒体文件放到自己的 NAS
    totoro625
        9
    totoro625  
       107 天前   ❤️ 1
    我选择的是 4 块 HC550 16T RAIDZ2 ,因为只能塞得下 4 块机械硬盘,详见: /t/979429
    不喜欢小主机或者成品 NAS ,手上两个小主机感觉都不是很好,早些年沉迷 ITX 主机,现在回想起来并不美好,我用这些年花的冤枉钱组了一套 NAS ,感觉不如二手商用服务器 R730
    我给自己定下的原则是,只买品牌顶级配件,宁可不买也不买小厂硬件,不碰 USB 外接硬盘

    从备份恢复数据的过程太痛苦,对于非计算机专业的维护人员而言,省时间省精力很重要,于是想提高可用性,首先考虑到 RAID5/RAIDZ1 都不放心,因为我的单盘容量太大了,于是只能考虑 RAID6/RAIDZ2 ,由于我很爱做快照,备份数据,相较于 ext4 ,更想尝试一下 ZFS

    对于 SnapRAID ,我更多的是用它来校验本地冷数据,防止损坏,而不是备份数据,实际体验上(有限的 Linux 和长期的 Windows )感觉时间较长,只有单份数据,没有分块,单文件较大对于备份/存储都比较麻烦,作为备份软件是不合格的。但是 scrub 功能是很值得表扬的。
    我同时使用 SnapRAID 和 Restic ,感觉 Restic 更适合用于备份热数据,SnapRAID 更适合校验已有冷数据是否损坏(也有可能是我配置不当)

    我的核心数据 200G ,大概 8 份,即工作机 3 份( 1 本体,2 定时),云 2 份( 1 实时 1 定时),NAS3 份( 3 机 2 地 1 实时 2 定时),经历过几次丢失数据,我认为备份永远只是备份,当你去找备份的时候,就已经不是原来的系统了
    totoro625
        10
    totoro625  
       107 天前
    @Hopetree #8 从论坛内多个案例来看,iCloud 不算很可靠的网盘
    ccxuy
        11
    ccxuy  
       107 天前   ❤️ 1
    我的需求跟 LZ 可以说是一模一样,小主机用 SSD 感觉还不错,外接 8 盘位硬盘柜也接了,但是不敢插满长期跑,只是偶尔开。真正 7x24 小时开的有几个成品威联通绿联 NAS ,猫盘,intel NUC 这些,目前都稳定运行 2-5 年了。
    sicifus
        12
    sicifus  
    OP
       107 天前
    为避免争议,还是追加解释几条:
    1 )用一体式 NAS 、还是算存分离模式?
    首先标题里的"NAS 存储",即可指一体式 NAS 的存储仓,也可指算存分离模式下的硬盘柜。
    我自己并没有排他性的结论,只是目前倾向于采用算存分离,所以写在思路的最后一条里。
    后者的优点在主贴里已经写过了,但其缺点由#4 的 V 友提了一下,目前产品力很差。不过这个缺点不是"算存分离"理念本身的缺点,而是硬盘柜达不到可用性造成的缺憾。
    基于此,这一阶段的结论自然可调整为选购一体式 NAS 。只不过若干年计算需求提升了,再入手新的小主机,变相实现算存分离。

    2 )为什么不想用 RAID/群晖
    贴 ref1 不是想引战的,只是顺便一句我的担心来由。
    raid 5 重建失败、毁盘的案例用相关关键字搜一下其实很容易搜得到。当然你可以说这是"沉默的大多数"现象,实际概率远远小于网上的说法,
    但我想强调的是,按照**风险=风险概率 x 风险后果**的公式,由于风险后果的严重性(包含了数据不可恢复的可能后果,也包含了可恢复数据的找寻/重下时间成本、或 raid 重建的等待历时的时间成本等等),我仍然倾向于用 basic 1+1 的同步/备份方式做数据保护。
    至于 RAID/群晖的其他缺点,在小结里也提了一下。

    3 )最后还是想要聚焦一下疑问点,即 NAS 的最大单盘容量的受限条件实际是什么?目前好像没看到对应的解释。
    MoonLin
        13
    MoonLin  
       107 天前   ❤️ 1
    1.关于存算分离:
    你需求的实际上是算力的持续升级,然后用解耦的方式,第一反应是小主机+硬盘柜,但是这种方式本身并不美好,无论是硬盘柜本身还是和小主机的连接,都引入了更多变量,而这些变量并不能忽视,甚至是导致数据不安全的致命因素。
    那么回归需求:算力持续升级,你自己组装一个 NAS 无非换一下主板和 CPU ,其他外设几乎平移即可,不也可以“无痛”做到算力持续升级吗?(升级价格的疼痛要比小主机小很多)
    2.关于 RAID ,我也是用的 Mergerfs+Snapraid ,原因是它足够灵活,可以让我随意更换硬盘配置,但是 Snapraid 一个痛点是不能实时同步,你是怎么来处理的?另外你都是在对比 raid5 ,可是 1:1 实时备份应该是 raid1 做的,为什么不对比 raid1 呢?
    3. NAS 的最大单盘容量的受限条件是硬盘技术,目前还没出现能超过 Ext4 上限 1EB 的单盘。
    @sicifus
    ltkun
        14
    ltkun  
       107 天前 via Android   ❤️ 1
    一个 zfs 可以解决所有问题
    sicifus
        15
    sicifus  
    OP
       107 天前
    @totoro625 #10
    感谢回复。
    我主贴里有写,针对重要数据有额外的备份/同步机制,加入 NAS 后能做到 3 地 4 中心,目前也是做到了 2 地 3 中心。
    普通数据打算做 NAS 存储下的 1+1 的单地备份。
    sicifus
        16
    sicifus  
    OP
       107 天前
    @totoro625 #9 感谢回复。
    "买品牌顶级配件"的理念我是能理解的,甚至一定程度上我也是认可的。不过我是想投入到购买"存储盘位"上,不管这个盘位的形式是一体化 NAS 、硬盘柜还是自组机上,因为长远来看,盘位形态的稳定性是最宝贵、最不折腾的;而算力方面,当下的重金投入过一两年就被摩尔定律折旧掉("速朽")了。

    对 ZFS 没怎么研究,主要是感觉个人用户好像也用不上太多 COW 、CDP 等企业级特性,而且读写性能好像类似 btrfs ,不及 ext4 。高价值数据我用 3 地 4 中心机制,一般数据用 1+1 备份感觉就差不多够用了。同时万一紧急情况下,Windows 读取 ext4 下文件也更便捷一些。

    关于冷备/热备,我高数据用多中心机制做热备,一般数据冷备即可。你提到的的"SnapRAID 更适合校验已有冷数据是否损坏",能够扩展开来详细讲讲碰到问题?谢谢~
    sicifus
        17
    sicifus  
    OP
       107 天前
    @ccxuy #11 感谢回复。
    的确我看到硬盘柜的评价好像都不高,不行的话只能跳开这个需求了。
    sicifus
        18
    sicifus  
    OP
       107 天前
    @MoonLin #13 感谢回复,尤其是你针对我的疑问进行了解答,特别感激。

    1.1 "自组 NAS"的确是一个方法,主贴里没有写一个是想要降低"折腾"的程度,把主要精力放到后面 homelab/aio/pve/lxc/docker 应用上面去;
    另外还有一个私心没有说,是想着以后老人那边谁的电脑坏了,我能很方便地拆下现有小主机给他们顶上(满足简单网页+炒股即可,连视频需求都没有),自己再无缝衔接一个新主机(说白了还是省钱……)

    1.2 当然现在看到 n 位 V 友都强烈不建议用独立硬盘柜,那么我要重新思考这一部分的需求了。多谢大家规劝、提醒。

    2. 我用 Snapraid 就是打算当成普通数据的定期冷备机制来用,重要数据用多中心同步机制来保障安全。

    3. 你的意思是不是这样——群晖也好、其他品牌 NAS 也好、硬盘柜也好,在产品介绍里写的支持的单盘最高容量,实际是因为市面上的主流 HDD 的最高容量就这么大?实际如果过个几年买得到几百 TB 的硬盘,插上去也能识别的?
    sicifus
        19
    sicifus  
    OP
       107 天前
    @sicifus #18 漏回了了一点
    "为什么不对比 raid1 呢",
    其实我做了比较了,写在小结的第 3 条,只是没点 raid1 的名而已,而是囊括 raid1/5/6/10/shr 。
    为啥其他点主要和 raid5 对比?
    因为我这个思路天然有 raid1 的优点,即①数据 1+1 冗余,②可延迟采购磁盘从而降低单字节存储成本;
    又规避了 raid1 的缺点,即第 3 、第 4 盘位扩盘后的 raid 重组的麻烦和风险(因为是数据复刻备份,数据+校验字节的条带化存储)
    sicifus
        20
    sicifus  
    OP
       107 天前
    @首页 #19
    换句话说,这个思路是天然抢占了 raid1 的生态位并优于 raid1 ,
    因此在主贴重点讨论与其他形态 raid 技术的优缺点比较。
    sicifus
        21
    sicifus  
    OP
       107 天前
    @首页 #19 最后一句修改为"因为是数据复刻备份,而非数据+校验字节的条带化存储"
    mantouboji
        22
    mantouboji  
       107 天前
    @geniussoft

    偶自己实测:四个 4T 硬盘组成的 RAID5 ,更换一块硬盘后 rebuild 需要 22 个小时。
    geniussoft
        23
    geniussoft  
       107 天前 via iPhone
    @mantouboji
    首先,22 小时,还好。

    其次,raid 重建速度取决于系统的负载和性能,如果系统本身空载(家用条件)而性能足够( ds1821+),10Tx8 的 Raid5/6 单盘重建,也就 10 多个小时,亲测。
    aru
        24
    aru  
       107 天前
    Mergerfs 性能很少,2 个 nvme 盘用 mergerfs 合并后速度不到单个盘一半
    sicifus
        25
    sicifus  
    OP
       107 天前 via Android
    @aru 会不会哪里没设置好?我看到的说法 mergerfs 的性能基本上就取决于单盘的读写性能么
    aru
        26
    aru  
       107 天前
    @sicifus
    如果你的机器有 2 个现成的 nvme 硬盘,可以自己实测一下大文件写入和读取
    HXHL
        27
    HXHL  
       107 天前
    别用 Mergerfs ,坑多
    standin000
        28
    standin000  
       107 天前
    snapraid 不能备份群晖系统,这是个坑
    lightionight
        29
    lightionight  
       106 天前
    @ltkun 哈哈 freebsd + zfs 一把梭🤣
    Ariver
        30
    Ariver  
       106 天前
    假设一下你的某个硬盘的数据丢失之后,你是否可以接受。
    在这个原则下来设计你的 nas 就好了。
    有的人可以接受,那你就朝着容量的方向建,硬盘加加加
    不能接受,那就备份,raid 也是一种备份方案。
    xiaoyuesanshui
        31
    xiaoyuesanshui  
       106 天前
    LVM?
    loginv2
        32
    loginv2  
       106 天前
    snapraid
    sunnysab
        33
    sunnysab  
       106 天前
    @lightionight 我就是!底层跑个 PVE ,把 SATA 控制器分配给 FreeBSD 跑 zfs 了,日常维护靠命令。上面装了 nginx 、samba 。
    sicifus
        34
    sicifus  
    OP
       106 天前
    @Ariver #30
    事实上是,"我全都要"。
    主贴的图已经画了,采用存储池 1+1 备份,因此不光可以接受某个硬盘数据丢失,还可以接受这个存储池下任意 n 块硬盘数据丢失。
    sicifus
        35
    sicifus  
    OP
       106 天前
    @HXHL #27 感谢回复,
    能稍微扩展说一下吗?或者给几个关键词我自己去搜一下,
    谢谢~
    ButcherHu
        36
    ButcherHu  
       106 天前   ❤️ 1
    URE 的问题众说纷纭,但是 Mergerfs 的 io 真的不行,理论就是单盘读写性能,而且实际小文件的话会慢的多,我没有具体测,但是之前用的时候跟 raidz2 对比很明显。

    对于你说的最大单盘容量的受限条件,我感觉还是硬盘厂商的制造成本和商业策略的考量,毕竟单盘最大容量是有限制的。

    但是硬盘扩容对我来说不是什么问题,每次备份的硬盘数量翻倍就好。至于"最优平衡",我觉得分期就好。
    libook
        37
    libook  
       106 天前   ❤️ 1
    用过很多年的 MergerFS+SnapRAID 方案,分享几个坑。

    1. SnapRAID 进行奇偶校验同步的时候要求文件不能正在被写入,所以只适用于冷数据。
    2. SnapRAID 的原理是每块盘上的数据块进行奇偶校验,所以在 1 块校验盘的情况下,当一块盘坏了的时候,想要恢复数据,就要确保其他盘上的数据仍然是上一次奇偶校验同步的版本,但如果在上一次奇偶校验同步之后其他盘的数据发生了变化,那么这些变化的数据块就无法恢复了(可能仍然可以恢复其他未变化的数据块的数据)。也就是说发生多盘修改文件的情况下,被修改的这些文件可能就会随着硬盘损坏而丢失了。需要对硬盘组的使用方式进行规划,比如每两次校验同步之间确保只在一块硬盘上修改数据,需要在其他盘上修改数据之前先进行奇偶校验同步。
    3. MergerFS 是基于 FUSE ,所以要关注 FUSE 本身的短板,以及你目前系统上的 FUSE 是否存在 bug 。
    4. 我遇到过两段时间 MergerFS 频繁挂掉的情况,MergerFS 的挂载点会提示 input/output error ,需要重启或重新挂载才能解决。跟 MergerFS 开发者交流过,很难 debug 定位到问题。根据我的观察是当打开状态的文件数量超过 3000 之后就很容易挂掉,不知道是我硬盘 IOPS 跟不上,还是 FUSE 有 Bug 。

    建议数据分冷热;假设你的热数据是小部分,那么可以热数据用 RAID-1 等镜像方案;冷数据用 MergerFS+SnapRAID 备份方案,如你画的图写满一块硬盘再写下一块。

    单盘容量限制理论上是文件系统方面的限制,不过现代文件系统基本都很难达到这种限制。如果厂商对单盘容量进行了限制,可能是因为对设备系统进行测试后认为系统在单盘大于某个容量后会导致产品使用体验下降,又或是显著加大了售后服务的难度。

    不过话说回来我并不推荐用超大容量的硬盘,一旦硬盘故障了,恢复数据需要很长的时间,如果采用奇偶校验备份的方式,在超长时间的恢复过程中会有较大概率再坏盘,导致奇偶校验失效。

    如果主板有 PCIe x8/x16 槽可以考虑 HBA 卡+硬盘笼,我用了浪潮服务器上拆下来的 HBA 卡和 12 盘位硬盘笼,很便宜。

    P.S. 我在后来评估认为 SnapRAID 不是很符合我个人的需求,转而去使用实时奇偶校验的 unRAID 方案了,当然 unRAID 也有它自己的短板。
    HXHL
        38
    HXHL  
       106 天前   ❤️ 1
    @sicifus 我公司就是做 nas 系统的,叫 CasaOS ,由[mergerfs]( https://github.com/IceWhaleTech/CasaOS/issues?q=is%3Aissue+mergerfs+ )导致的 issue 有不少😪。当然我这里不是说 mergerfs 不好,我们还是挺喜欢 mergerfs ,但是有时会有一些奇怪的问题。
    sicifus
        39
    sicifus  
    OP
       106 天前
    @HXHL #38 感谢!学到新知
    sicifus
        40
    sicifus  
    OP
       106 天前
    @ButcherHu #36 感谢回复!
    Mergerfs 的实际体验是我特别想知道的,感谢提醒避坑~
    sicifus
        41
    sicifus  
    OP
       106 天前
    @libook #37 非常感谢~
    的确是打算把 SnapRAID 作为温/冷数据定期备份来使用的,而且不打算跨存储池去操作数据。具体的思路是:
    1 )重要数据(热数据)基于云+端的同步( 3 中心),确保数据多份拷贝和一致性。数据操作时不传 NAS/服务器。
    2 )重要数据定期(每周 1~2 次)同步一次到 NAS+公司服务器上,仅用于规避中招勒索软件的时间成本(云端虽有版本管理功能,但一个个恢复起来时间太长)。其中在 NAS 侧,仅存到存储池 1 内。
    3 )其他数据(主要是照片、影视、书籍等),日常的增添删改都只在存储池 1 内操作。
    4 )存储池 1 内的温/冷数据定期(每周 1 次)通过 Snapraid 同步到存储池 2 中。除了 snapraid 同步、校验,及 s.m.a.r.t.扫描维护之外,其余时间原则上存储池 2 的硬盘休眠(省点电费,#doge )。

    关于 HBA 卡和 12 盘位硬盘笼的信息我再去学习下,感谢~
    关于 unRaid ,主要是看了 youtube 上一些 up 主的吐槽(譬如这个 https://www.youtube.com/@ZhangDaqi/search?query=unraid ),感觉好像槽点有点多、学习成本不低,所以也没特别关注了。
    libook
        42
    libook  
       106 天前   ❤️ 1
    @sicifus #41
    建议第 2 项加快照,可以保留最近几次备份的快照,避免数据损坏后自动进行了备份。

    unRAID 对我来说是,确定自己的需求场景可以使用 MergerFS+SnapRAID 满足的情况下,的一个更可靠的替代方案。目前用了两个多月,明显感觉 unRAID 比之前我自己在 Debian 上搭建的 MergerFS+SnapRAID 更稳定耐艹,我上次换了硬盘笼之后已经稳定运行 20 天了。
    sicifus
        43
    sicifus  
    OP
       106 天前
    @sicifus #40
    我又思考了一下,mergerfs 在下文件 io 表现不佳,会不会是因为小文件实际跨磁盘操作了?
    我把主贴的图示改了一下,如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘,会不会好一点?存储池 2 仅作为冷备使用。
    sicifus
        44
    sicifus  
    OP
       106 天前
    @ButcherHu #36 我又思考了一下,mergerfs 在下文件 io 表现不佳,会不会是因为小文件实际跨磁盘操作了?
    我把主贴的图示改了一下,如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘,会不会好一点?存储池 2 仅作为冷备使用。
    sicifus
        45
    sicifus  
    OP
       106 天前
    @libook #42 好的谢谢,我再学习一下
    sicifus
        46
    sicifus  
    OP
       106 天前
    @ltkun #14
    按照这篇文章( https://wzyboy.im/post/1186.html )的说法,zfs 同样有「 data lock-in 」的缺点,对磁盘容量扩展的友好性明显没有 mergerfs 高。
    sicifus
        47
    sicifus  
    OP
       106 天前
    @aru #26 你好,我把主贴的图示改了一下,如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘,io 性能会不会好一点?存储池 2 仅作为冷备使用。
    sicifus
        48
    sicifus  
    OP
       106 天前
    @ButcherHu #36 另外,分期应不是"最优平衡",「延迟采购 x 分期」明显优于「仅分期」
    msg7086
        49
    msg7086  
       106 天前   ❤️ 1
    关于 URE 的问题,有几点要提的。
    一是 URE 是上限值而不是典型值。比如一块硬盘参数标称 URE 是 1E-14 ,并不是说每读取 1E14 比特就会遇到一个坏点。这里的这个 URE 是最大值。比如我随便拿了一份 WD Red Pro 的参数表,上面写的是:
    Non-recoverable errors per bits read
    <1 in 10^15
    注意这个小于号,实际生产环境中的 URE 其实是远远小于 1E-15 的,标称 1E-15 只是上限值,不是典型值。

    二是 URE 通常是发生在磁盘长期不读取的时候。我们知道磁盘本身会随着岁月的流逝而逐渐丢失数据。在读写磁盘数据的时候,如果 ECC 检测到磁盘上有数据错误,就会重写扇区刷新数据。如果你有一些文件放置在那三五年不去读写,有可能三五年过去就有可能有数据会损坏。但如果你每隔两个月刮一次盘,每隔三年把盘清零重写一次,URE 发生的概率会大大降低。

    光这两点就已经显著偏离你贴的关于 URE 的数据点了。

    然后是单盘容量限制。单盘容量其实没有限制,最多就是操作系统估计限制门槛,要你加钱换更贵的产品。现在一般购买的 NAS 你插一块单盘 100TB 的盘进去也应该能正常使用才对。

    最后是说说 NAS 的思路。你如果想做磁盘柜,磁盘柜输出一般是 RAID/HBA 卡,一般为了省事肯定直接插满然后做一个大 ZFS RAIDZ2/3 完事(或者硬 RAID ),不考虑扩容,不考虑花里胡哨,你就把他当成一块巨大的硬盘,开机就用,用到报废,拆了卖废品为止。
    如果你想折腾,又想省钱,自己买个多盘位的塔式机箱自己建。
    如果你家里地方够大,没有噪音问题,那直接一个 12 盘或者 24 盘的超微解决问题,一站式方案,E5v4 ,插满 DDR4 REG ECC ,自带背板,一块 HBA 连上,剩下的还能搞搞 40G 网卡什么的,装个 Proxmox ,想怎么玩就怎么玩。

    我以前给公司装 NAS ,2U 的机器 12 盘 4T 直接组一个大 RAIDZ2 ,随便别人怎么用。
    我自己家里的 NAS ,2U 的机器 12 盘 16T ,全部单盘,不做任何 RAID 。
    另外一台 NAS ,2U 的机器,塞硬盘做备份。
    单盘是最没负担的,想买就买,想换就换,主硬盘坏了直接把备份盘填上就行,也不用纠结什么重建。
    sicifus
        50
    sicifus  
    OP
       106 天前
    @msg7086 #49 感谢回复!
    1 )关于 URE 或相关的重建恢复问题,我除了关注理论计算值外,另外也比较关注网友实际碰到的情况。毕竟如果只考虑理论风险的话,由 n 个数学大佬们加持的 LTCM 长期资本管理对冲基金应该直到现在还获得好好的。

    目前我看到的网上可见案例里,一旦重建恢复,民用级 raid 导致的第二块磁盘故障的案例不少,结合风险=风险等级*风险概率的公式,在我的承受范围下属于不可接受的风险。

    2 )诉求是想省钱、且不折腾、且低风险。所以整体方案要考虑 a)容量可扩展,b)扩展可平滑,c)1+1 存储池
    msg7086
        51
    msg7086  
       106 天前
    重建时第二块硬盘故障这个你得带着点盐去看。比如说平日有没有每月(或者每两三个月)刮数据,这个对结果的影响很大的。你说的重建时第二块硬盘故障,我敢说至少有九成的情况是第二块盘早就已经有数据损坏了,只是在重建的时候发现了这些损坏而已。真正的第二块盘原本是完好的状态,在重建过程中开始损坏的,其实很少很少的。
    我前面也已经说过了,一个文件不读不写,硬盘就不知道他的好坏,所以可能一个文件半年前已经坏了,而你半年后重建阵列的时候才发现。这个不是 URE 或者 RAID 的问题,纯粹就是自己没有搞清楚,没做好。
    这个错之前 LTT 老莱也犯过 https://www.bilibili.com/video/BV1844y1W74r/ 05:55 前后有解释为什么会出问题(以及如何避免这类问题)。

    至于既要省钱又要低风险又要不折腾……有这么好的事情一定要跟我说说(
    sicifus
        52
    sicifus  
    OP
       106 天前
    @msg7086 #51
    按照你提供的视频里的说法( 05:33 起),成品 NAS 都是有自动化的定期数据清理机制的,而开了这个机制后就能监控到磁盘损坏,而不必等到重建时才发现。他们之所以数据丢失的原因就是因为自搭的 CentOS 上没有开启定期清理,nothing more ,没有提到需要"刮数据"。以上是我看完后的理解,若有错误请指正。

    关于既要又要还要,不是一个绝对的概念,而是和对标对象的 PK 下的相对胜出。主贴里的小结部分提到了,这里再扩展开说一下:

    1 )省钱:主要对标 raid5 、raid1 、群晖。
    raid5 的“不省钱”体现在需至少 [一次性] 采购 3 块同容量磁盘( 67%容量利用率)、更普遍做法 [一次性] 采购 4 块( 75%容量利用率)。此外,4 盘同时运转更耗电。
    raid1 的“不省钱”体现在空间利用率只有 50%上,但由于初期磁盘可只买 2 块,数据量上去后再按需追加,实际有效容量的成本是接近乃至持平 raid5 的。(当然要看自己的数据增速,增速越快、磁盘二次采购期越近,raid1 越劣势)。
    群晖的额外“不省钱”体现在盘位费贵、系统要在每块磁盘都要复制一份等等。

    我的思路是保留 raid1 按需扩容的优点,同时避免它必须每次买 2 块的缺点,二次、三次购买都是采购容量翻倍的单块磁盘,通过延长分批采购的时间吃到技术进步&成本下降的红利。同时,磁盘越少电费约省。此外,无需捆绑于群晖。

    2 )不折腾:在容量扩容的硬需求下,主要对标条带化 raid (包含 shr 、zfs 等),以及传统 basic 1+1 模式。
    raid/zfs 的一个“折腾”主要体现在条带化存储导致的「 data lock-in 」,在磁盘扩容时必须经历数据导出 -> 磁盘清空 -> 重新导入数据的过程。
    此外,磁盘替换时(坏道,或 shr 场景下的磁盘替换增容),raid 重建过程中 CPU 和 IO 性能会狂跌,要忍受大几十小时的不可用时间。
    basic 1+1 模式的“折腾”主要体现在磁盘>=3 时,文件管理的不便。

    我的思路是放弃条带化存储( raid 的缺点、basic 1+1 的优点),技术方案是 snapraid 。同时采用存储池( basic 1+1 的缺点、raid 的优点),技术方案是 mergerfs 。
    针对有些楼内说的多盘 mergerfs 下 io 性能不佳的问题,采用主存储池单块磁盘、日常 io 操作,备存储池多块磁盘合并、只做冷备的方式来解决。

    3 )低风险:对标条带化 raid 。
    条带化 raid 的“风险”场景:重建时的损盘(争议很大,但至少 ≥ basic 吧? basic 重建只需复制、无需校验/擦写)
    raid5 的额外“风险”场景:多盘同时坏块。

    我的思路:同第二条,弃条带化,采用文件级 raid ,叠加 1+1 备份。即便多盘出现坏块,也只损伤特定文件,不涉及跨盘的条带校验值,也不影响其他文件的随意增查删改复制等操作。

    不知上述解释能否略微澄清一些你的疑惑?
    ericFork
        53
    ericFork  
       105 天前
    企业盘吵其实是个刻板印象,东芝 MG08/MG09 实测都相当安静,你可以去找找它们的运行录音视频
    standin000
        54
    standin000  
       105 天前
    @libook 请教下,如果全上 m.2 接口的 ssd ,是不是对硬盘笼的电源要求就低,也不用解 HBA 卡了。
    msg7086
        55
    msg7086  
       104 天前
    @sicifus 不是定期清理,是定期 scrubbing ,也就是我说的定期刮数据。
    msg7086
        56
    msg7086  
       104 天前
    另外你的「省钱不折腾低风险」在我看来是相当「不省钱折腾高风险」的方案。
    如你所说盘位成本很高,当你第 3 块盘是前两块盘的两倍容量的时候,就意味着你有两个盘位的容量只有一半。
    放到今天来说,就相当于你之前买了两块 6T ,现在加了一块 12T ,那你 6T 还是用小容量占坑,等于还是亏了。
    如果是第三次扩容,那就相当于里面放了两块 3T ,一块 6T ,一块 12T ,更亏了。
    条带存储在磁盘扩容时必须导出再导入,这个没错,但是你配置 snapraid+mergerfs 就算是不折腾了吗。snapraid 和 mergerfs 的坑都踩过一遍了吗?这两个方案用的人可是远远比 zfs 和 RAID 少的。
    风险,使用多个软件去解决单个问题,每个软件都是 point of failure 。你自己写 snapraid 配置文件,万一写错,就可能出问题。包括上面#37 说的,万一文件变了,文件对应的块的保护就会失效。在你不知不觉的时候你的数据可能就会掉保护而你自己可能都不知道。你告诉我这是低风险吗。

    所以我的结论就是,没有方案能做到既要省钱又要低风险又要不折腾,要是有这么好的事情,企业早就用了。那企业在用什么呢?企业在用 zfs 。
    msg7086
        57
    msg7086  
       104 天前
    更大的企业在用类似 ceph 之类的方案,或者 glusterfs 这样的分布式存储,很成熟的方案。前者可以拿来跑高可用虚拟机,Proxmox 在用的,超融合架构,还有像 vSan 这样的产品。后者主要是文件存储,可以动态增减硬盘和服务器扩容。如果你能承受 1+1 备份的话,说不定可以考虑 glusterfs 。
    不过我还是觉得普通家用就是最简单的配置最好,单盘单分区,放满了换块盘放,备份就是盘对盘互拷,升级硬盘就是插上硬盘,复制数据,拔掉旧盘。
    libook
        58
    libook  
       104 天前 via Android   ❤️ 1
    @standin000 两个问题。
    首先一般说的 HBA 卡实际上是 SAS 控制器,就是负责将 PCIe 协议转成 SAS 协议。而 M.2 接口通常是 PCIe 协议或 SATA 协议,如果是 PCIe 协议就是直接连接 PCIe 接口(可能需要 PCIe 拆分卡),如果是 SA 协议就是连接 SATA 控制器;也就是说一般不需要 HBA 卡,因为协议不一样。

    硬盘的功耗跟接口关系不大,得实际看硬盘产品的官方手册里的额定功率,SSD 用高速主控和大容量闪存阵列也可以很吃电。常见企业级 M.2 产品功率在 4W-15W ,家用级机械硬盘功率在 5W-14W ;企业级机械硬盘以希捷银河 x18 为例,满载在 9W 左右。HBA 卡不同信号功率也不一样,在 6W 到 26W 。机械硬盘可以通过停转休眠来显著降低功耗,SSD 也有的型号具有断电休眠技术,具体看产品手册是不是有这些节能特性。

    题外话,M.2 产品目前相对来说比较贵,如果决定用全闪方案,可以看看 U.2 口(通常也是 PCIe 协议)的产品,可能可以便宜,性能一样。
    sicifus
        59
    sicifus  
    OP
       104 天前
    @msg7086 #56
    "放到今天来说,就相当于你之前买了两块 6T ,现在加了一块 12T ,那你 6T 还是用小容量占坑,等于还是亏了。如果是第三次扩容,那就相当于里面放了两块 3T ,一块 6T ,一块 12T ,更亏了。"
    ————————————————
    我觉得这段话里大概有三个问题:
    1 )扩容应该算边际成本的,在现有 2*6T 的情况下,方案①:只需额外采购 1 块 12T 、且充分利用原有 2*6T 、且构成了 1+1 容量完全均等(主 12T ,备 2*6T )的主备存储池,和方案②:采购 3 块 12T ,替换下原有的 2*6T 又没有合适的用途,明显是方案①的成本更优。
    2 )第三次扩容你的方法写错了,不是 2*3T+1*6T+1*12T ,而是 2*6T+1*12T=24T 组成新的备用池,再采购 1 块 24T 组成主用池。保护
    3 )至于“盘位成本很高”,我是寻求一条保护即有盘位投资+磁盘投资的同时、兼顾容量可扩展性的道路。
    说白了现有一般的容量扩容思路有三种,
    第 1 种是盘位扩容法,即容量用满时,新采购一个 NAS (或硬盘柜),缺点是最贵,即同时增加盘位投资和磁盘投资,同时亦存在文件跨盘管理的问题。
    第 2 种是磁盘扩容法,即容量用满时,新采购 n 块磁盘,缺点是次贵,一般需要采购 2 块( raid1 )及以上( raid5 ),且数据迁移的难度不低,风险有较大争议。
    第 3 种是 shr 扩容法,即可按单盘位分批容量升级。这是成本相对最理想的情况。
    我的改进思路是基于 shr 的可扩展+性价比的基础上,一方面建议采用(n+n)+2n+4n 的分布扩容法,性价比(磁盘延迟采购)和数据安全性( 100%备份)最平衡,其次对于普通用户来说可以降低对条带化存储的迷信,开阔一下思路。

    就像你说在 56#和 57#提到的企业级的方式,其中 zfs 我并不想否定其价值和意义,就像普通 raid 是有其价值和意义一样。我只是说从 basic 1+1 往上走,如果关注重点是性价比、磁盘扩容便捷性、数据备份性,而不是 NAS 高可用性等特性的话,其实有其他更便捷、性价比更高的 [民用级] 存储扩容和管理思路的,不需要直接跳到的条带化存储思路上去。


    57#的“单盘单分区,放满了换块盘放,备份就是盘对盘互拷”的思路,其实的确是民用级最简便的扩容方案,唯一的一个问题是跨盘文件管理的不便,因此需要在这个基础上引入一下 mergerfs 做存储池。
    standin000
        60
    standin000  
       104 天前
    @libook 谢谢答疑,电源是我看机械硬盘笼经常有人说电源问题导致硬盘坏,我想 ssd 功耗低,硬盘笼是不是对电源要求没那么高。硬盘笼看上去都是 sata, sas 等协议,如果用 usb3.0 或者 4.0 协议问题大吗?
    libook
        61
    libook  
       104 天前 via Android   ❤️ 1
    @standin000 想要避免断电故障加个 ups 就行了。
    断电除了硬件伤害可能还有数据伤害,比如某些阵列在断电后会导致硬盘数据不一致。又或者是内存缓存数据没来得及写入硬盘断电导致丢失。

    USB 也是有额定带宽,带宽够的话应该也是可以的,只不过使用 USB 的方案实际上是 USB 外接一个 SATA 、SAS 、NVMe 控制器,通常有额外成本,如果你机器上本来就有这些控制器,而且接口有富裕,就没必要额外用 USB 的。
    standin000
        62
    standin000  
       103 天前
    @libook 不完全是断电故障,是便宜电源不稳定导致硬盘受损,总的来说还是经费有限,没有买 ups
    ccxuy
        63
    ccxuy  
       102 天前
    @sicifus 我认为独立硬盘柜偶尔用还是可以的,作为冷存储使用。长期用要选大功率电源,可靠做工和连线的产品,但是这类产品我发现价格跟 NAS 有的一拼。。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2858 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 14:52 · PVG 22:52 · LAX 07:52 · JFK 10:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.