6+2 盘位的 NAS 放在办公室如何规划存储和应用？

去年因为做了个数据量比较大的项目，外加各种模型权重、数据集越来越多，患上了存储空间焦虑症。年底的时候回国扛了一台绿联的 DXP6800Pro ，外加 6 个西数 16T 二手企业盘和 2 个 2T 的致钛 Ti600 的 SSD 到办公室，现在不焦虑存储空间了，但有点纠结怎么用好这个 NAS 。网上搜索+问了问 ChatGPT ，并没有在方案设计上找到什么有建设性的答案。

目前的状态 刷了 Debian12 ，6 个 HDD 用 ZFS 组了个 RaidZ2 ，两个 SSD 做镜像后现在是 ZFS 的 LOG 。本意是想加速一下写入，但似乎并没有起到太大的作用。我自己还搞了个万兆交换机，配合手动配置 IP ，让电脑和 NAS 之间通过万兆局域网连接，平时会通过一个跑在 podman 里的 samba 挂载到(Windows 和 Linux 都有)电脑上。Samba 开了个共享账号给周围的同事用，自己有一个单独的 Samba 账号。本来还搭了个 Aria2 ，但因为 podman 容器里挂载目录的权限问题比 docker 要复杂一些，所以还没跑通。

总结来说，现在的 NAS 用起来有以下几个痛点

1. 读写性能跑不满自己搭的万兆局域网，最多跑满 HDD 的顺序读写，SSD 似乎没有起到什么作用
2. 所有的东西塞在一个大存储池里，偶尔手动把数据复制到用于备份的另一台机器上
3. 一旦有点大规模的（特别是随机的）读写，企业盘炒豆子的声音会引起一些同事的抗议

鄙人的核心诉求大概如下（重要性从高到低）

1. 不能丢数据
2. 尽可能充分利用现有硬件，提升性能和存储空间利用率
3. 减少维护时的心智和体力负担
4. 作为隐私焦虑症患者，希望尽可能保障隐私和安全性(例如在一些应用/软件选择上使用了开源方案而非商业方案）。但考虑到 3 ，可以选一些“退而求其次”的选择，比如 debian 换成 ubuntu ，podman 换成 docker
5. 降低金钱的成本

如果可以，我希望达到这样一个效果

1. 日常通过局域网将 NAS 挂载到电脑上时，可以实现万兆局域网的速度+SSD 的随机读写性能。这意味着我在我的电脑上跑模型训练之类的工作的时候，（如果数据集很幸运地在缓存里）可以从 NAS 加载数据集
2. 所有的数据在一个合理的时间内可以落盘到 RAID1 的 HDD 上，并可以实现定时备份。 2.5 如果可以的话，我希望大部分的 HDD 读写可以发生在一个可控的时间段内（比如下班之后），这样 HDD 的炒豆子声不至于影响别人
3. 如果哪个硬盘坏了，我能有个办法及时知道，然后找一块好盘换进去就能继续用
4. 可以在 NAS 上跑个类似 aria2 的服务，实现离线下载。有时还想 git clone 一些比较大的仓库（比如 hugging face 上的模型权重），也希望可以让 NAS 代劳

为了达到这样一个效果，我调研到了下面几个结论

1. 万兆+随机读写的需求本质上是需要让 SSD 充当读写缓存（读+写缓存，而不是类似 ZFS 的 L2ARC 的主要加速读取操作的缓存）。并且由于 SSD 充当了写缓存，实际上在写操作的缓存策略上是 WriteBack ，即先写到 SSD 上，然后再异步地写入 HDD
2. 目前比较方便且成熟的存储管理方案有两个，一个是 LVM ，一个是 ZFS ，其中 LVM 可以通过配置 LVMCache 的 cachepool 或 cachevol 实现 writeback 缓存
3. ZFS 的 ARC 和 L2ARC 主要加速读取操作，将 log 放在 SSD 上可以加速同步写操作，但在一些情况下（例如大量随机读写，来自网络连接的异步读写）作用有限，最后还是用 HDD 硬扛。
4. ZFS 具有一些我非常喜欢的 LVM 不具备的功能，比如透明压缩，数据去重等，如果可以的话，利用好这些功能可以提升存储空间利用率。但 ZFS 似乎并不支持类似 LVMCache 的 writeback
5. 很多人不推荐 writeback 缓存策略是因为 SSD 的寿命有限,如果 SSD 损坏并且 SSD 上有数据没有写回 HDD ，会导致缓存的数据丢失。但我这儿有两块 SSD ，如果做 mirror 或 raid1 的话可以减小这种情况发生的概率
6. 我知道 Raid 不是备份，但备份到云的成本过于高昂，所以目前的办法是同机器上不同硬盘互相备份。换言之我可以在同一个机器上组超过 2 套 Raid ，然后这两套 Raid 互为备份。此外，我也有定时把数据全量备份到另外的硬盘/机器上的习惯。

基于以上结论和一些来自 ChatGPT 的建议，我得到了目前以下几个关于存储规划的方案

1. LVM + LVMCache(writeback) + LVM Raid1： 这个方案是全 LVM 方案，看起来在存储规划的角度基本满足我上面提到的想法；
2. 4 个 HDD 组 RaidZ2 + (2xHDD+2xSSD)组 LVM + LVMCache(writeback)： 这个方案兼顾了 LVM 的 writeback 缓存功能和 ZFS 的一些能力，将热数据放在 LVM 中提升性能，把备份和冷数据放在 ZFS 中，提高存储空间利用率和安全性；
3. SSD 单独组成存储池（无论使用 ZFS 还是 LVM ），纯享 SSD 的读写性能，定时将 SSD 中的数据备份到 HDD ，一些对读写（特别是随机读写）性能要求不高的工作可以直接落盘到 HDD 上；

在应用规划上，目前的 Samba 方案暂时没有找到合适的替代；考虑过利用 Nextcloud 实现 WebDav ，但其本身的性能实在堪忧，所以暂时没有用上。

其他一些补充和 Q&A

1. 为什么不用 PVE 而是选择了 debian/ubuntu 作为裸机操作系统？ 办公室的网络环境有点复杂，使用 PVE 的话难以配置 NAS 连接到办公室的网络。而且考虑到目前的应用需求，似乎 podman 可以满足需求，而不是使用虚拟机。
2. 办公室的网络环境是怎样的？ 总结起来包括以下几个事实：
   • 对于连接到公司网络来说，需要额外的图形化界面认证+安装公司的 CA 证书才能连接到公司内网，否则可以连接到外网，但公司内网的设备无法连接到 NAS
   • 我自己搞了个 5x2.5G 电口+2xSPF+的交换机，两个光口配置了个 VLAN 分别连接了 NAS 网卡 1 和电脑网卡 1 ，两台设备手动配置 IP 实现互相访问； 5 个电口则配置了另一个 VLAN ，一个电口用于上行连接公司网络（公司的是千兆网口），电口一个给了 NAS 网卡 2 ，一个给了电脑网卡 2 ，其他电口连接各种其他想要以 2.5G 局域网连接 NAS 的同事们。至于更远的同事们，只能委屈他们走公司内网连接到这个 NAS 了
3. 为什么不是公司来折腾这些东西？ 因为公司太烂，且没钱

目前的问题

1. 考虑到以上提到的“想要的”和“需要的”，我是不是需要更换存储规划方案？如果更换，选哪一个，为什么？或者，有没有更好的其他方案？
2. 在软件应用的选择上，是否有其他的方案和推荐？
3. 其他的 使用小妙招/建议/评价？

在此感谢社区内的诸位，祝大家春节愉快，阖家欢洛！

作为一位将楼主提到的方案和技术全部摸过的普通 FSHEX 用户，我的看法是： > 不要纠结太多，不要有“一定要把这个那个的性能和带宽都跑满”的想法，否则因为木桶效应的存在，你总是会陷入不断升级每个部件的循环中（直到所有部件的性能都严重过剩）。 [关于连续读写性能] 由于所有数据最终都是存储在 HDD 阵列上的，尤其是大量连续读写的数据，因此 HDD 阵列的性能决定了“任意资料”（尤其是冷资料）的读取性能。如果你真的想跑满万兆网络，请增加 HDD 到至少 8 块（假设你使用 RAID-Z2 ，此时有 6 块数据盘，按单盘 200 MB/s 的速度估计，可以达到 1200 MB/s ）。 [关于随机读写性能] 请扔掉 SSD ，你不需要把它利用起来，否则只会起反作用。给你的 NAS 加更多的内存用于 ZFS ARC 。 根据 USTC 镜像站的数据 [1]，对于冷热分明的数据，ZFS ARC 能够提供足够好的命中率，而 L2ARC 仅有不到 1/3 的命中率。结合“ARC 命中率足够高”这一点，根据 Amdahl 定律，考虑到 L2ARC 还会占用 ARC 来维护它自己的 metadata ，盲目使用 L2ARC 并不能带来更好的性能，不如节约下来 SSD 的寿命做点别的，哪怕只是用作系统盘（ rootfs ）。 对于冷数据，我不认为任何文件系统能够处理好这种情况，除非你上全闪（显然钱包不会很开心），没有必要也不应该考虑冷数据随机读取的性能，而 ZFS 由于它的日志式设计，可以将随机写 buffer 起来转换成顺序写 [6]，因此你也没有必要使用 SLOG [7][8]（ NAS 应该不会有 O_SYNC 写入吧）或者考虑任何形式的 SSD 作写缓存的用法。 [关于 ZFS] 对于 NAS 这种场景，你需要适当调节 ZFS 的参数，具体可以参考链接 [1]（镜像站就是一个巨大号的 NAS ，该文章所提及的大部分参数在这里同样适用），减少碎片率和 HDD 的 I/O 次数，以及增加分配给 ARC 的内存量（没错，这个建议归根结底还是“加内存”）。 [关于 LVM] 建议扔了不要用，你已经在用 ZFS 了，没有任何必要使用 LVM 和 LVMCache 。LVMCache 的性能很差（见 [1] 的截图）并且算法很原始 [1]；而 ZFS 的 ARC 是一个非常先进的、自动调节的算法 [2]（只是需要更多内存）。同时 LVMCache 有各种大大小小的坑，尤其是 writeback 模式下 [3]，甚至还会把 GRUB 搞糊涂 [4]，我们为此花费了不少精力去调查研究，并且自己 patch 代码 [4] 解决或者只是绕过这些问题。相信你没有抖 M 到这个程度（ 且不说 ZFS 无论如何不应该跑在其他形式的 RAID 或缓存机制上 [5]，有了 ZFS ，你也没有任何必要再在上面套一层 LVMCache （同理，这也会让你失去 ZFS 的一大半高级特性和性能优化）。 [其他] 「如果哪个硬盘坏了，我能有个办法及时知道」→ 你需要的是基于硬盘 SMART 信息的报警功能，请自行调研 smartd （ apt install smartmontools ）的报警功能。 「很多人不推荐 writeback 缓存策略是因为」→ 见上，我有另一批完全不同的理由不推荐 LVMCache 。 [关于更换方案] 个人推荐你换掉那个小的、CPU 性能差、内存容量少的定制 NAS 主机，而是重新搭一个台式机，可以用更好的 CPU （ 7950X / 9950X + X870 / X870E 等，甚至选用带 IPMI 的主板，不过预算可能压不住），配更好的电源和更好的机箱（便宜：半岛铁盒 F20 ；结实牢固、设计合理：分型工艺 Define 7 XL ），这些看似周边的部件反而是一个更可靠的 NAS 的基础。 软件方面我没有任何想法，自己在 Ubuntu 上把（自认为能折腾的）都折腾过了，建议以个人熟悉的软件栈为主。 [结论] 整体性能够用就好，点到为止，不要盲目追求极限。 [最后] 以上全部思考来自我自己搭建和管理服务器的亲身经历。 [最后的最后] 打了这么多字，给点个“感谢”送点铜币吧（暴露了，其实我是来骗铜币的）。祝楼主和其他F友春节愉快，阖家欢洛！ [参考资料] [1]: https://lug.ustc.edu.cn/planet/2024/12/ustc-mirrors-zfs-rebuild/#mirrors4 [2]: https://www.usenix.org/conference/fast-03/arc-self-tuning-low-overhead-replacement-cache [3]: https://docs.ustclug.org/services/mirrors/4/volumes-old/#ssd [4]: https://github.com/taoky/grub/commit/85b260baec91aa4f7db85d7592f6be92d549a0ae [5]: https://serverfault.com/q/545252/450575 [6]: https://ibug.io/p/62 （我的博客） [7]: https://superuser.com/q/1428707/688600 [8]: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html （注：以上链接中 1, 3, 6 均是我写的，或者我参与编写/校对的）

@iBugOne 昨天还在拜读 [201.ustclug]( https://201.ustclug.org) 中关于 ZFS 和 LVM 相关文章，在这儿遇见 iBug 本尊有种教科书里的人物跑到了现实中的既视感，非常亦可赛艇 [鞠躬] 我确实深入考虑了你说的全 HDD ZFS 方案，也研读过 UTSC 镜像站相关的许多内容（如前面提到的 201 ）。目前来说仍然在进行思想斗争主要是这台 NAS 的使用场景与镜像站有着较大不同。我看到镜像站相关的很多文章讨论的是“读取的时候尽可能减小存储设备负担”的问题，因为镜像站的使用场景似乎是“少量且确定的写”（镜像站通常会有计划地进行同步）+“大量且随机的读”（没人知道哪个 PCDN 什么时候开始刷流），这时候 ZFS 针对读操作的优化就显得非常有用。同时，镜像站使用的是内存更大，CPU 性能更强的专业服务器硬件，有充足的内存资源支持 ZFS 的 ARC 缓存。在镜像站的使用场景下，ARC 的作用被非常充分地发挥了出来。相比之下，这台 NAS 面向的场景是日常工作过程中的数据存储。通常的使用场景是，为了某个明天打算跑训练的模型，把某个数据集下载下来，稍微做一些预处理，训练的时候写个 data loader 从 NAS 上读取数据。其通常会面对的是支持大量耗时且高 IO 的数据处理过程中工作站上的 SSD 装不下那么多数据的问题。 从这个角度来说，最理想的情况是，某种我不知道的东西可以“预约”SSD ，同时让 NAS 自己异步地在 SSD 和 HDD 之间 migration 。比如我即将要跑个数据处理，大量的中间数据和结果会通过网络写到 NAS 的 SSD 上，然后 NAS 自己在后台吭哧吭哧把这些数据慢慢挪到 HDD 里的同时，我处理完数据要跑模型训练的时候可以继续用 SSD 上处理好的数据集。等到我用完了这些数据，这些数据还会在 HDD 上好好呆着当作收藏(bushi)，或是下次用的时候再或是慢慢从 HDD 读取或是“预约”一下挪到 SSD 上。倒不是因为 ZFS 或 LVM 好还是不好，而是纯粹地这台 NAS 它既是一个用于存储冷数据的 NAS ，又是半个工作站的外置硬盘。 不过显然这有些既要又要了。所以 ZFS 依然是我非常认真考虑的选择。

这 nas 的主要负载到底是随机读+随机写，还是顺序读？ #2 里面说的训练数据的存储和访问应该是顺序读为主？ 这种情况如果不用全闪，应该尽可能增加盘的数量以提升整个 nas 的吞吐量。 而#2 里面这句话“这台 NAS 它既是一个用于存储冷数据的 NAS ，又是半个工作站的外置硬盘”，就比较有意思了。 这种情况感觉就应该上全闪方案，两种工作复合通杀。