 |
iBugOneV2EX 第 318309 号会员，加入于 2018-05-24 14:35:53 +08:00今日活跃度排名 30 |
iBugOne 最近回复了
16 小时 4 分钟前 回复了 eric107008 创建的主题 › NAS › 6+2 盘位的 NAS 放在办公室如何规划存储和应用？ |
作为一位将楼主提到的方案和技术全部摸过的普通 V2EX 用户，我的看法是：
> 不要纠结太多，不要有“一定要把这个那个的性能和带宽都跑满”的想法，否则因为木桶效应的存在，你总是会陷入不断升级每个部件的循环中（直到所有部件的性能都严重过剩）。
[关于连续读写性能] 由于所有数据最终都是存储在 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 上把（自认为能折腾的）都折腾过了，建议以个人熟悉的软件栈为主。
[结论] 整体性能够用就好，点到为止，不要盲目追求极限。
[最后] 以上全部思考来自我自己搭建和管理服务器的亲身经历。
[最后的最后] 打了这么多字，给点个“感谢”送点铜币吧（暴露了，其实我是来骗铜币的）。祝楼主和其他 V 友春节愉快，阖家欢洛！
[参考资料]
[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 均是我写的，或者我参与编写/校对的）
> 不要纠结太多，不要有“一定要把这个那个的性能和带宽都跑满”的想法，否则因为木桶效应的存在，你总是会陷入不断升级每个部件的循环中（直到所有部件的性能都严重过剩）。
[关于连续读写性能] 由于所有数据最终都是存储在 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 上把（自认为能折腾的）都折腾过了，建议以个人熟悉的软件栈为主。
[结论] 整体性能够用就好，点到为止，不要盲目追求极限。
[最后] 以上全部思考来自我自己搭建和管理服务器的亲身经历。
[最后的最后] 打了这么多字，给点个“感谢”送点铜币吧（暴露了，其实我是来骗铜币的）。祝楼主和其他 V 友春节愉快，阖家欢洛！
[参考资料]
[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 均是我写的，或者我参与编写/校对的）
2 天前 回复了 kleos 创建的主题 › 信息安全 › 来自 ipv6 only 的神秘问题，收到无法解析地址的流量 |
有没有可能，你只需要 tcpdump -n 就可以看到 ptr.default 的真实 IP 了，少绕一大个弯呢🐶
8 天前 回复了 shadoworld 创建的主题 › 宽带症候群 › 光猫改桥接后改 ip 地址，脑抽改成 192.168.5.255 |
秘密：把电脑的地址改成 192.168.5.1/22 ，注意掩码长度必须是 22 （或者更小，比如 21 ，但没必要）。
这里需要假设你的猫能够正常访问 192.168.5.1 ，否则只能重置它。本操作的关键在于 22 的子网掩码，默认 24 的子网掩码会让操作系统把 5.0 和 5.255 当做网络地址和广播地址（从而不能正常访问），但当你把掩码缩短到 22 之后，网络地址和广播地址就变成了 4.0 和 7.255 ，这时候 5.255 这样的地址就变成了单播地址，可以正常访问了。
对于 Linux：除了上述方法之外，也可以正常设置 192.168.5.1/24 ，然后 [ip route delete broadcast 192.168.5.255 table local] 强制删掉 kernel 自动创建的广播路由规则，效果同上。
这里需要假设你的猫能够正常访问 192.168.5.1 ，否则只能重置它。本操作的关键在于 22 的子网掩码，默认 24 的子网掩码会让操作系统把 5.0 和 5.255 当做网络地址和广播地址（从而不能正常访问），但当你把掩码缩短到 22 之后，网络地址和广播地址就变成了 4.0 和 7.255 ，这时候 5.255 这样的地址就变成了单播地址，可以正常访问了。
对于 Linux：除了上述方法之外，也可以正常设置 192.168.5.1/24 ，然后 [ip route delete broadcast 192.168.5.255 table local] 强制删掉 kernel 自动创建的广播路由规则，效果同上。
29 天前 回复了 MRlaopeng 创建的主题 › 问与答 › 使用 zfs 存储池也能对数据库存储的数据进行字节存储? |
不用想了，zfs 没这么离谱的功能，能按 recordsize/volblocksize 进行块级别的去重就不错了
70 天前 回复了 clid 创建的主题 › Linux › 中科大源 wget 报错 |
遇到类似问题建议首先通过我们的 GitHub issue 区反馈：< https://github.com/ustclug/discussions >，在其他地方发贴我们是无法及时看到的，但 GitHub issue 是有通知的。
由于 PCDN 猖獗，各大高校镜像站都是恶意流量（大量刷下载）的受害者，因此各家都有一些风控规则，下次遇到的时候可以先尝试 1 楼的方案。
由于 PCDN 猖獗，各大高校镜像站都是恶意流量（大量刷下载）的受害者，因此各家都有一些风控规则，下次遇到的时候可以先尝试 1 楼的方案。
121 天前 回复了 revival83 创建的主题 › 游戏 › 我又来求游戏啦，求推荐个手游或者页游，画面可爱点不氪金能一直长玩儿的 |
摩尔庄园
152 天前 回复了 zictos 创建的主题 › Android › root 过或类原生的安卓系统最近还能使用美团或美团外卖 app 吗？ |
9 月 2 号下午开始不行了，联系客服能恢复一会，但还是没法进入订单结算页面，也没法查看历史订单，正在考虑找个旧版美团 app 试试
188 天前 回复了 Tarlor 创建的主题 › 分享发现 › 应对 CC 攻击的最佳实践：使用 CDN 和自动化 IP 封禁 |
一股浓浓的 GPT 味道，前后又是重复的车轱辘话，基本没有有效的信息量，还是 1 楼评价得最言简意赅
216 天前 回复了 NightFlame 创建的主题 › 宽带症候群 › 如果度过家里两个月没宽带(Wi-Fi)的时间。 |
@MegrezZhu 肌肉记忆：键盘输入 ruh ，第一个选项一般就是“如何”；但是如果不小心打成了 rug ，第一个选项就是“如果”
Select Language