自建NAS方案选型-基建篇
前言
上一篇讲了在 2022 年底到 2023 年初一台性能还不错并且兼顾了兼容性的 NAS 硬件选型思路，算下来价格并不便宜，但是从兼容性和零件可替换性上还是不错的。本篇更多的是关心整体系统基建而非应用层软件。如果对 Linux 不够熟悉，直接无脑 Windows Server 什么都不用折腾。
系统
方案列举
系统方面可选的有：
- 黑群晖：NAS 永远绕不过去群晖系统的，各种套件非常方便，NAS 系统体验上一般分为两种：群晖和其他。
- Unraid：优点是没有常规 RAID，可以无痛后续添加和升级硬盘，而且通过增加 1 块校验盘能够做到类似 RAID5 的安全性，每次读写使用单块硬盘。系统收费，无限制版 129 美元（但国区另外有优惠）。
- TrueNAS SCALE：TrueNAS CORE 的 Linux 内核版本，使用 ZFS 系统可以做到比较高的数据安全性。
- openmediavault：基于 Debain 的 NAS 系统，甚至可以直接在 Debain 上安装，优点是纯粹，缺点也是功能比较简单。
- Windows Server：虽然很多人不喜欢 Windows，但是毕竟久经考验而且大部分很熟悉，图形化操作很友好，缺点是一些 NAS 常用的软件不支持 Windows（例如 SeaFile）。
- Debain 或者 Ubuntu Server 或者其他常见发行版：最简单的 Linux，不过有时 Less is more。
- Proxmox VE：虚拟机平台常用底层系统，基于 Debain，跟 OMV 一样可以直接在 Debian 上安装。
方案选型
首先是 Windows Server，优点非常多，特别是对硬件兼容性处于变态级，吊打其他所有。比如后面所说的 Debian 就因为对 12 代 CPU 的核显支持不太好折腾了很久。一度想选择 Windows，但是一些软件只有 Liunx 版本也是个大问题，虽然能用 WSL2 来装，可是 SeaFile 这种读写磁盘的软件不适合 WSL2 跨系统的 磁盘 IO 性能很差的方案。可能什么时候微软能解决这个问题，就是我的 NAS 系统最终选择了。
回到 *nix 的圈子，首先排除 OVM，本来我更熟悉 Debain 并且希望有一个 WebUI 可以简单控制，OVM 非常符合，但经过试用 OVM，遇到了好多小 bug，最致命的是甚至没有做什么折腾，WebUI 就频繁出现 503 错误，我无法接受 NAS 运行在这样不稳定的环境中，其他系统还能让我取舍两难，OMV 的不稳定让我避之不及。
对于 TrueNAS，可能爱的人会非常爱，但是不太适合我的使用环境，原因是扩展硬盘不太方便（我有一批大大小小曾经陪伴了 10 来年的硬盘），内存占用比较高（每 1TB 硬盘需要 1GB 内存），在我看来更适合企业服务器环境，统一的硬盘容量，带 ECC 的大内存等等。
然后是黑群晖，黑的就是黑的，再怎么洗白也是黑的，群晖的系统只会对自家硬件完美兼容，其他硬件特别是新硬件和偏门硬件就随缘了，更适合放到 VM 中去使用群晖的生态软件而非当宿主机。
Unraid 是非常好用的系统，简单易用而且正如名字一样，不需要 RAID 就能获得类似 RAID5 的安全性，不过它同样因此有个缺点是一旦开了校验整体写入性能下降，可以通过添加 SSD 作为缓存盘提升速度。算是进入了最终的决赛圈，在决赛圈被 RAID 选型给淘汰了。
并不排斥直接使用最简单的 Debain 构建我的 NAS 底层，不过因为 Debian 的软件源和内核比较老旧，stable 版本对 UHD 7x0 的兼容性不太好。WebUI 可以安装轻量化： Cockpit，这个面板在 RHEL 系下功能比较强大，Debian 下面功能比较简单，不过如果只是监控系统状态还是没问题的。本来是打算把 testing 版本放进决赛圈的，但是此时有个更好的选择：PVE。
最终选择
PVE 基于 Debian，官方已经支持了 LTS 的 Linux Kernel 6.1，有比较健全的 WebUI 可以完成大部分的系统监控和操作，文档、教程和社区也很活跃。这一切都很符合我对 NAS 系统的期待之外还有个额外之喜：可以比较方便的使用 LXC，可以用来隔离一些环境，折腾出问题还能不影响其他功能。
LXC 算是 VM 和 Docker 的中间选择，比 VM 轻量性能好还能不独占硬件，使用起来也更灵活，比如磁盘的管理；比 Docker 方便能真的当作一个操作系统来用，而不是只能 pull 别人打包好的某个固定软件，很适合多个软件的联动。
小孩子才做选择，成年人当然是全都要，Docker、LXC、VM 都几乎开箱即用（PVE 基于 Debian，可以跟 Debian 一样使用 Docker），根据不同需求供君任选也是我喜欢 PVE 的一点。
存储
RAID 选型
RAID 可以分为硬 RAID 和软 RAID，硬 RAID 需要硬件支持，一般是服务器使用，价格高购买不方便，价格低的咸鱼二手货一旦出了问题没办法买到相同的 RAID 卡数据就全没了，所以不考虑硬 RAID。
常见的软 RAID 分为 RAID[0-6]，由操作系统或者文件系统或者第三方软件提供。但是常见大部分情况下对磁盘的要求是大小相同，这对渐进式升级 NAS 容易造成一些资金困难和硬盘浪费。而且读取单个文件时全部硬盘运行，NAS 硬盘噪声比较大，所以不太友好。Unraid 和 SnapRAID 对磁盘升级和噪音都比较友好，所以我更偏好这两种方案。 具体各种软 RAID 方案特性对比可以参见 SnapRAID 给出的 对比
相比 Unraid 会因为实时校验而降低性能，我更喜欢 SnapRAID 这种方式，它通过定时任务来进行校验写入，不会影响实时读写。当然非实时有利有弊，如果在写入数据之后还没来得及校验这个盘就挂了，那新写入的数据是无法恢复的，而且对大量小文件的 diff 性能也没那么好，所以比较适合写入频率比较低、文件比较大的场景，恰好家庭娱乐存储就正好适合。
另外其实 SnapRAID 可以配合 RAID1 或者 ZFS 对重要数据做更进一步的冗余，不过对于我来说没太大必要，我的重要数据会定期备份到 OSS 和 OneDrive 上。
因此我选 SnapRAID 的原因总结：
- 不影响实时读写性能。
- 单盘读写不会太吵。
- 抗灾能力强，一旦有硬盘坏掉，不影响其他硬盘的数据，而且可以通过增加校验盘个数获得远超 RAID6 的抗灾能力。
- 不依赖特定系统，软件级实现保证了任意操作系统任意文件系统都可以使用，而且随意抽出一块硬盘可以放到其他环境中正常读写已有数据。
- 配置灵活，可以随时添加或者删除任意大小的数据盘和校验盘，而且不会影响硬盘上的数据。
- 校验盘非常灵活宽松，校验盘大小只需要比数据盘中最大的受保护空间大，而非跟完整数据盘对比。比如一块 10TB 的数据盘上只有 2TB 的数据被加入 SnapRAID，那么校验盘大于 2TB 即可，而且剩余的空间可以挪做他用，随便放任何数据。哪怕后期被保护的数据超过的校验盘大小，只需要把校验数据文件拷贝到更大的硬盘中即可无缝替换。
- 读远大于写可以容忍非实时性。
存储池
我的媒体仓库是多块硬盘合并而成的，自己手动关注磁盘剩余空间和调整下载位置，然后在 PT 下载等环节也要加入多个磁盘目录使用实在过于难受，因此需要选择一个存储池。好在存储池没有那么多需要选择的，直接无脑使用 mergerfs，当然它也给出了类似方案的 对比。mergerfs 的效果如下所示：
1A + B = C
2/disk1 /disk2 /merged
3| | |
4+-- /dir1 +-- /dir1 +-- /dir1
5| | | | | |
6| +-- file1 | +-- file2 | +-- file1
7| | +-- file3 | +-- file2
8+-- /dir2 | | +-- file3
9| | +-- /dir3 |
10| +-- file4 | +-- /dir2
11| +-- file5 | |
12+-- file6 | +-- file4
13 |
14 +-- /dir3
15 | |
16 | +-- file5
17 |
18 +-- file6
值得注意的是写入策略的选择，官方推荐使用 mfs(most free space)，优先选择剩余可用空间最多的磁盘，这个会让你的所有硬盘都剩下的空间差不多，读写比较均衡，坏处是同一个文件夹的内容可能会被分散到多个硬盘。现在默认的策略是 epmfs(existing path, most free space)，这种策略会优先找到目标文件夹所在盘，并把所有的后续同文件夹内容写入该盘，即文件夹中第一个文件决定了后续文件放到哪个盘，好处是相同路径的文件大部分会在同一个物理硬盘上，坏处是可能会先填满一个硬盘再填其他的。
比如把 5000 张照片 Copy 进 5 个硬盘组成的存储池，mfs 最后可能每个硬盘上各有 1000 张照片， epmfs 最后可能只有第一个硬盘上存在 5000 张照片，其他硬盘为空，直到第一个硬盘写满了，才会把后续的照片写入其他盘。具体选什么策略就见仁见智了，我选择 mfs，希望负载均衡能延长一些硬盘寿命。
SSD 缓存
其实大量的读写一般发生在系统安装盘和 PT 下载盘，系统安装盘本来也不大，直接使用 SSD 足矣，PT 下载盘可以通过配置 BT 客户端先下载到 SSD 上，下载完成自动移回 HDD。如果还有 HDD 小文件随机读写的场景可以通过 bcache 来加速，不过 bcache 需要先把作为缓存盘的 SSD 清空和被缓存的 HDD 数据清空，不适合我这种硬盘上已经存在大量数据的使用，而且对顺序大文件读写加速效果也一般。
其他
常用软件清单
- Portainer：可视化管理 Docker，虽然比较喜欢 CLI 的方式管理，但是有个可视化的面板可以偶尔查看状态还是比较舒适的。
- mergerfs：将多个盘合并成一个更大的储存池，这样就不用纠结分类哪个盘放什么了。
- SnapRAID：文件级 RAID 比较简单方便，对硬盘扩容也比较友好，非实时性只能说有利有弊了。
- File Browser：简单文件管理用 File Browser 足够了。
- Seafile：复杂的文件同步有 Seafile、 FileRun和 Nextcloud。Nextcloud 功能超多但是性能在国内外论坛都差评，所以直接排除。FileRun 兼容 Nextcloud API，性能要好不少，免费版 10 个账户限制，不过没有自己的客户端。综合考虑选择了 Seafile，免费版 3 个账户限制，用户量比较大而且口碑一直不错，有自己的客户端，用 C 语言开发性能没得说，而且有同步盘。
- Emby：媒体管理无非是 Emby、 Jellyfin、 Plex和一些小众方案。都比较成熟了，哪个合眼缘和需求随便选，我支持开源的 Jellyfin，但是它没 Xbox 客户端并且 2023 年 3 月实测 Android TV 客户端有些视频播放没有声音，换成 Emby 和 Plex 可以正常播放，只能说还得需要时间沉淀。
- Tailscale：没有公网 IPv4，只能用 DDNS 打通 IPv6，但是公司网络只支持 IPv4，而且 IPv6 的城际路由这两年稍微有所改善但是还是堪忧，所以还是得选择一个内网穿透方案。之前比较火的是 ZeroTier，依赖官方中继服务器，自建 Planet 客户端支持一般。Tailscale 算是后起之秀，客户端是开源的，现在服务端也有人做了对应实现： headscale。
- qBittorrent：同样受欢迎的是 Transmission，BT&PT 下载的两大金刚，qBittorrent 管理路径更方便，Transmission 据说内存占用更低。记得用这两个的无头版本：qBittorrent-nox 和 transmission-daemon。常见的操作是用一个 qBittorrent 下载，用一个 Transmission 保种，这样可以做到下载管理方便，保种占用又很低。不在意保种内存的前提下本来可以用一个 qBittorrent 下载和保种，但是 qBittorrent 设置 SSD 暂存盘后辅种强制校验失败，怀疑新种子目标路径是用作缓存的 SSD，导致读取不到 HDD 里已经下载的数据，所以需要另一个软件保种。
- kopia：用来做增量备份，同样有竞争力的是 restic，kopia 有着完善的 GUI 和 WebUI，比较方便使用，如果为了足够高的安全，可以 kopia 和 restic 同时使用，占用两倍空间来防止一个软件出错导致数据无法恢复。
HTPC
另外研究了一下做 HTPC 的方案，如果用裸机直接当 HTPC 最简单，跟正常的电脑看视频没区别。如果选择虚拟化方案的话，可以利用 12100 支持 SR-IOV，一个显卡可以虚拟出 7 个半虚拟化显卡实例，每个都能直通给虚拟机单独使用。直通一个实例给虚拟机来媒体服务器重编码，再给另一个虚拟机直通一个实例做 HTPC 进行解码。不过需要加一个支持 DisplayLink 的 USB 显卡复制画面到显示器（最近因为 M1 芯片的 MBP 只能驱动一台 4K 显示器，所以这个方案又火了起来），或者用一个咸鱼亮机卡直通给 HTPC 虚拟机来输出（其实从价格和性能上这个更合适，但是占用 PCI-E 槽位）。这么看下来过于复杂了，还是老老实实用来当媒体服务器吧。
WiFi
有张闲置的无线网卡，正好想把 NAS 扔远一点防止噪音，等硬件准备就绪发现 PVE 并不推荐使用 WiFi，深入下去用 NAT 的方式也很复杂，所以暂时放弃了，也许等有必要的时候还会回归更熟悉的 Windows。