咨询 NAS 的硬盘组合问题, ZFS、MergerFS+SnapRaid、普通 Raid

2019-10-11 10:20:23 +08:00
 sidkang
目前的配置如下 i5-8500 2*DDR4-16G 2*32G SLC-U 盘 2*500G-860evo 1*250G-SSD 3*8T-HDD
目前机箱可以容纳 4*3.5,2*3.5,剩余如果加 SSD 的话可以通过双面胶大法解决,主板上有 8SATA 口,1M.2,1PCI-Ex16,目前仅使用了 6SATA 口
未来会逐步提升配置,SSD 应该会根据需要慢慢加,3.5HDD 最多也只能加一个盘了,然后就只能替换更大容量的

目前初步的软件配置,Host 通过双 SLCU 盘组 Raid1/RaidZ-mirror 安装 Proxmox ; 2 个 SSD 组 raid1 或 RaidZ-mirror,主要用于放 vm 以及从系统盘移出来可能需要频繁读写的 Cache 和日志目录; 3 个 HDD 组 RaidZ/(MergerFS+SnapRaid)/普通 Raid,需要存储的资料主要是一些媒体资料,这些改动不会太频繁,还有一些是工作用材料,这一部分主要是零碎文件,但是数量很多,也会经常做变动

目前有些犹豫不确定的有这么几个点:
1、HDD 方面,因为还是有一些变动多一些的文件,所以倾向于用 ZFS 或者 Raid 的方式,Snapraid+MergerFS 的特性使得无法及时对写入的数据进行保护(不太适用于频繁改动的文件);
2、SSD 方面,因为容量比较小,所以即便使用 ZFS 升级也还算方便,直接把数据拷贝出来即可,我的疑问是想说,对于 SSD 来说,组普通 Raid 和 ZFS 的性能方面差距有多大呢?,主要想提升 4k 随机方面的性能,如果差不多的情况下我可能倾向于使用普通 Raid
3、针对于组合 Raid,大家是推荐直接在 Proxmox 上设置并管理 ZFS 及磁盘空间,还是推荐通过 VM 直通 SATA controller 的方式来管理好呢?
提前感谢各位,这些问题实在疑问了很久
10107 次点击
所在节点    Linux
45 条回复
lucifer9
2019-10-13 17:10:22 +08:00
没 ECC 内存的话,zfs 其实也没好太多
smilzman
2019-10-14 10:53:41 +08:00
@sidkang 谢谢哈,看了一下 SnapRAID 数据独立和非实时还不错的,不过现在已经够用了,懒得去折腾=。=
SaltyLeo
2019-10-30 10:43:02 +08:00
ZFS 的自恢复真的很赞,前段时间把内核搞坏了,重新覆盖安装新的系统,ZFS 自动挂载了,数据一点都没丢。
sidkang
2019-10-30 15:37:01 +08:00
@SaltyLeo 不错,我已经把 zpool 建好用起来了,找时间再好好研究一下= =
sidkang
2019-10-30 15:39:17 +08:00
@lucifer9 ECC 的争论好像挺多的,不过目前看下来主流的讲法还是“ECC 其实不是 ZFS 特殊,而是任何系统用 ECC 内存都更推荐”,我买的主板也是支持纯 ECC 的,不过纯 ECC 有点难买,打算以后方便的时候再搞
xivisi
2019-11-01 14:04:59 +08:00
我用的 gentoo + 用的 zfs 文件系统
raphael
2019-12-19 20:16:15 +08:00
@sidkang 我最近也在研究,我是 8sata 位主板,准备放 6 个 sata HDD 12T 的做存储,剩下两个放 SATA 的 SSD,然后一个 M.2,U 盘放 PVE 引导。PVE 虚拟出 Freenas 管理存储,软路由加上其他虚拟机跑一些应用。然后正在考虑应用层是用 iSCSI 内网万兆给白裙实现还是在 PVE 下面直接开个虚拟机跑个其他好用的系统实现。目前存储这看你的意思是直接 sata controller 给 freenas 比较好,而不是直通每块硬盘?那 SSD 也是吗?两块 SSD 可以作为 freenas 的缓存吧?然后 M.2 跑应用?这样是不是好点
sidkang
2019-12-19 23:40:52 +08:00
@raphael 我目前是直接由 pve 管理所有的硬盘,2U 盘做启动盘,2SSD 组一个 pool,4HDD 组一个 raidZ1pool ;如果是用 freenas 的话,确实建议直接直通控制器,这样 freenas 才可以读取到磁盘实际信息,这样的话 SSD 自然也就转给 freenas 了,ssd 可以做缓存,M.2 的意义不会特别的大,其实 SATASSD 已经足够快了。如果是为了用 zfs 的话,我建议就直接 pve 管理好了,管理也方便,不用特意拿 freenas vm 来管理。
另外,ssd 作为 zfs 缓存的话,建议仔细读读文档和资料,需要琢磨一下,不然可能反而会降低性能
raphael
2019-12-20 15:19:03 +08:00
@sidkang 好的,pve 管理硬盘的话,即使用 ZFS,是不是 freenas 的一些高级功能就用不了了? M.2 的 SSD 主要是想跑一些其他虚拟机的时候加快速度,还有就是万兆的话可能用得到
chronos
2020-01-06 23:13:29 +08:00
@raphael 如果想扩容的时候省点钱,可以考虑一下让 zfs 跑在 lvm 上,每个硬盘弄一个 thin lv,然后通过 zfs 组成 raidz,记得给 lvm.conf 中配置 thin_check_options = [ "-q", "--clear-needs-check-flag", "--skip-mappings" ] ,否则开机检查要好久。因为 zol 0.8.1 增加了 trim,所以开启 zpool set autotrim=on data 后删除文件就会 trim,利用这个可以在需要扩容时删除所有快照,再新建 thin lv 和新的 raidz,再将文件用 rsync 移动过去。

用这种方法可以一次加一块容量相同的硬盘,缺点是必须删除快照。
ungrown
2020-07-13 11:24:53 +08:00
@lucifer9 #21
任何文件系统没了 ECC 都不安全。
内存有错的情况下,文件数据的损坏仅仅是时间+概率的问题——早晚的事。
至于选择 ZFS 的原因:性能、快照、压缩、冗余、自维护性……这些就够了,本来也没指望非 ECC 的内存能实现什么额外的数据纠错。
justaname
2022-11-30 02:49:40 +08:00
@ungrown 大部分文件系统并没有像 ZFS 一样对内存有大量读取写入,对 ECC 的依赖当然不一样。假设内存反转的概率是一定的,那写入 1T 和 50G 出错的概率能一样吗?
ungrown
2022-12-02 16:45:47 +08:00
@justaname #32
所有强调 zfs 必须或者最好用 ecc 的论调,都是以讹传讹,该观点的始作俑者和一众信徒(不加引号)们都在这个问题上犯了“半桶水想太多但又想得不够多”的错误,其中相当一部分人很难说他们不是借这个观点来进行误导、威吓、党同伐异、赛博宗教迫害。
反驳这一论调的经典文章: https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data
结论:ecc 有用,但是没必要。没有 ecc 的场景下,zfs 并不会比别的文件系统造成更多损失,相反,zfs 还会避免、修复更多损失,因为其他文件系统没这个能力,是的,这个能力本来也跟内存是不是 ecc 没有关系。如果你感到困惑,上面那条链接可以给你解惑。

以后记得看到某种观点之后,搜搜它的反面,反面不一定是对的,但是兼听则明偏信则暗。
justaname
2022-12-11 22:41:14 +08:00
@ungrown 这篇文章我看过,Google 搜索 ZFS non ECC 第三个就是,而另外几个则是反对这个观点的。另外几乎所有支持 ZFS 的平台在 ZFS 的要求都会额外注明 ECC 内存的重要性并强烈建议部署 ZFS 的主机使用 ECC 内存,比如 TrueNAS ,Proxmox ,其中 Proxmox 支持 LVM ,ZFS ,BTRFS 等多种块存储方式,但只有 ZFS 是额外标注仅建议在使用 ECC 内存的情况下部署,同时 ZFS 也是唯一官方强烈建议采用 ECC 内存的文件系统。我不知道 ZFS 官方,Proxmox 官方,TrueNAS 是不是都属于你说的半桶水想太多和宗教迫害。
最后你依然没有回答我一个很浅显的疑问,在内存都可能出错的情况下,对内存重度依赖同时有大量内存读写操作的 ZFS 能在可靠性上跟别的不吃内存的传统文件系统一致吗?既然都有可能出错,0.01%的出错率和 1%的出错率没有差别这种论证显然并不令人满意
ungrown
2022-12-12 03:20:56 +08:00
@justaname #34 假传圣旨的卑鄙小人!
PVE 官方资料里在 zfs 页面提到了 ecc ,只提到一次,上下文用的词语是 recommend ,除此之外没有哪怕一个地方提及非 ecc 的危害也没有反对使用 ecc 。这叫“强烈”建议?这强烈是你自己加的吧喂!
oracle zfs 、openzfs 、truenas 官方资料中则干脆连 ecc 这个词都搜不到了,唯一把 ecc 奉为圭臬当山歌唱的就是 truenas 论坛里面,你是不是被他们托梦看的“资料”啊?

来,时间充裕,我不跟你玩什么简明扼要的论证,我就是要朝你这种焦虑贩子输出情绪和贬斥。
如果我给的那篇文章链接你真的仔细看了,那下面这段内容你应该已经读过,但是谁知道呢,说不定你嘴上说你读过,其实你可能一个字没看,或者边看边忘呢。

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

这是 2014 年 Matthew Ahrens 在论坛上的回帖 https://arstechnica.com/civis/threads/ars-walkthrough-using-the-zfs-next-gen-filesystem-on-linux.1235679/page-4#post-26303271
Matthew Ahrens 何许人也?乃 sun 公司当初创造 zfs 的核心人员之一,现今的 Delphix 公司 zfs 开发团队的领导。
他上面说的这段哈啥意思呢?开头他说:zfs 没有什么特别的地方,使它比其他文件系统更加需要、更加依赖 ecc 内存。结尾他说:你实在担心你那宝贝数据出问题,不管是利益休戚相关还是心理作用,你担心,你就上 ecc ,不管你用的啥文件系统,你担心就该上 ecc ,那如果有了 ecc 还嫌不够呢,你还可以加一个 zfs 作为额外的保险。那么是 ecc 的存在才使得 zfs 能够可靠运作吗,不是;是 ecc 让 zfs 变得更好了吗,不是;是什么呢,是 zfs 使 ecc 变得更好了,原因无他,zfs 牛逼,zfs 屌大,zfs 无论在任何内存哪怕是坏内存上都能通过自己的系统将错误减到最小,杀爆在座各位的其他文件系统。
因为 zfs 本身相当于加了一层校验,校验不通过它是不会往盘上回写覆盖数据的。在 zfs 面前,其他的文件系统就是小瘪三。
你有 ecc ,恭喜,你还用了 zfs ,好,双倍校验,双倍恭喜。
你没 ecc ,但你的内存没坏,没事放心用,哦你用 zfs 啊,那更没事了。
你没 ecc ,而且你的内存已经有问题了,跑 memtest 报错那种,呵呵,祝你好运……等下,你用的是 zfs 啊,诶,问题不大,但是还是赶紧换根条子吧,又不贵,非要拼人品赌运气吗?
你没 ecc ,而且内存有问题,而且文件系统还不是 zfs ,emmm ,回去过得开心点吧,想吃啥想玩啥的尽量满足吧,不会太久了。
就你那心心念念的 1%还是 0.01%,你还在乎那几个小数点呢?内存条要是真有这么大的错误率,早蓝屏、内核崩溃了,这么高的错误率,跑 memtest 还不得第一轮就列表格?
但是不用担心,如果你真的有一条这样的内存条,zfs 依然会尽全力避免数据损坏,毕竟除非智子干扰,否则内存里面不会错得那么“巧”,zfs 的块校验就能发现错误,发现了错误就好办了,别往回写不就行了么,你以为 zfs 是跟你一样的脑残呢?
再说,这么宝贝的数据,vdev 肯定有冗余吧,哪有正经人玩存储不戴头盔,啊不是,不设冗余的?
那是我了,我就是这种不正经的人,单硬盘 zpool ,无冗余,无 ecc ,这都快 8 年过去了,要不我再维持现状多跑几年,说不定到时候我哭了,你可以来笑我?

就你这种桶底湿,还学别人半桶水那样晃呢?人家半桶水虽然傻逼但他能晃出响来,你呢?
justaname
2022-12-12 07:46:56 +08:00
@ungrown 你翻来覆去说的这些东西只是在论证 1%和 0.01%没差别,然而实际上对大部分“普通用户”来说,这就是“有区别”。事实上你,以及你引用的那篇“经典论文”,依然没有回答我一个最开始的提问,在内存错误率一定的情况下,一个重度依赖 RAM 的文件系统是怎么做到跟不重度读写 RAM 的文件系统一个出错率的。PVE 在且仅在 ZFS 的页面提到过这个“recommendation”,意思是只有使用 ZFS 的用户才会在意数据安全?

你一个单盘 zpool 我都不知道这个经历有什么好特意炫耀的,无冗余说明根本不是重要数据,bit rot 也根本无所谓。我在一块 memtest 有问题,经常蓝屏的 Windows 上运行了几个月 NTFS 上的 RAID 没有任何(我发现的)数据损坏,是不是说明 NTFS 是最好的文件系统?

Matthew Ahrens 何许人也?乃 sun 公司当初创造 zfs 的核心人员之一,现今的 Delphix 公司 zfs 开发团队的领导。我不知道你引用一个 ZFS 利益相关的核心人员做了一通哲学论述是想说明什么?

另外不用回复了,讨论一个文件系统的利弊也能冒出来这么激情四射的宗教式攻击,然后到处旁征博引就是没有实际针对问题的回答。
ungrown
2022-12-12 09:36:17 +08:00
@justaname #36 fnmdp 1%和 0.01%没差别!
我说的是没差别吗,我说的是这点差别没有意义。
往小了说,1%和 0.01%这种错误率都属于很大的错误率了,这种内存条不换掉属于害人害己。
往大了说,zfs 自带的错误校验和防损机制是不依赖 ecc 的,用普通内存,zfs 依然能发挥它的错误校验功能,内存中的错误不会被回写到介质上。

你又要用 zfs ,又嫌 zfs 核心开发人员提供的结论是利益相关的,你就想听社区里面人云亦云以讹传讹三人成虎贩卖恐慌的 ecc 神教是吧?
是你们把自己臆想出来的东西奉为宝典,软硬兼施,规劝、胁迫别人跟你们一样搞,而且看到质疑和反对的声音就攻击,你们这才是血统纯正的宗教迫害,怎么还有脸来倒打一耙!?

ntfs 本来就是很好的文件系统,要不然为什么这么多人在用?
然而你这个例子恰恰证明了 ecc 本来就不是特别重要,哪怕是 ntfs 这种没有校验功能的文件系统。
zfs 这种校验功能完善的文件系统就更不怕内存翻转了,zfs 不会把内存中错误的块当成正确的提供给用户读取,zfs 不会把内存中错误的块回写到介质上,但是 ntfs 会。
zfs+普通内存 ≈ 其他文件系统+ecc 内存 = 单一校验。
zfs+ecc 内存 = 双倍校验。

你们但凡稍微了解过 zfs 的块校验和错误管理,都不会被一个内存翻转吓到半死。
sidkang
2022-12-12 09:52:48 +08:00
@ungrown https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html

Hardware Requirements

- ECC memory. This isn’t really a requirement, but it’s highly recommended.

Do I have to use ECC memory for ZFS?

- Using ECC memory for OpenZFS is strongly recommended for enterprise environments where the strongest data integrity guarantees are required. Without ECC memory rare random bit flips caused by cosmic rays or by faulty memory can go undetected. If this were to occur OpenZFS (or any other filesystem) will write the damaged data to disk and be unable to automatically detect the corruption.

- Unfortunately, ECC memory is not always supported by consumer grade hardware. And even when it is, ECC memory will be more expensive. For home users the additional safety brought by ECC memory might not justify the cost. It’s up to you to determine what level of protection your data requires.

麻烦不要激动,你说的和我印象也不太一样,我就随便找了下你说的“oracle zfs 、openzfs 、truenas 官方资料中则干脆连 ecc 这个词都搜不到了,唯一把 ecc 奉为圭臬当山歌唱的就是 truenas 论坛里面,你是不是被他们托梦看的“资料”啊?”中的 openzfs 的资料,ecc 依旧还是很醒目。

总之就是 highly recommended but not required 。
ungrown
2022-12-12 09:55:45 +08:00
@sidkang #38
是呀,不必要啊
知道啥是必要的吗,跑 memtest 不出错的内存
ungrown
2022-12-12 10:00:56 +08:00
@sidkang #38 我直接帮你把重点画出来吧,省得还等你下条回复

is strongly recommended for "enterprise environments"
where the "strongest data integrity guarantees" are required

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/608123

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX