需求分析与我的使用场景

早期使用习惯：

大概从高中开始我就用群晖的东西来管理我的个人文件，设备先后从 Gen8 黑群晖 —— DS 216j —— 之前的 Gen10 Plus 黑群晖
在这个时间段中，主要用途为： 群晖搭配 Download Station 下载东西
使用 Samba 作为分享给 Windows/电视盒子 的协议

现在的需求：

面向局域网内容器共享硬盘空间
足够快的媒体搜索，可方便的让我在不手动归类的情况下找到我想要的文件
提供面向对象存储的 API
稳定，可以接受复杂的首次部署但要简单的升级和日常维护
无明显的直接经济支出或者可以一次付款终身使用

• High Hardware cost and Low Software cost

系统架构

硬件

Hpe Microserver Gen10 Plus

• Intel E2146
• 16G non-Reg ECC UDIMM x 2
• Intel P3700
• WD 4T x 2
• Toshiba 8T x 2

硬件选型思考

首先这台机器放在我家客厅，我一个月大多数时候都在学校并且每次回家需要来回 4H 的通勤时长，以至于在这种情况下 IPMI 是硬需求。
虽然收一个 1U/2U 带 IPMI 的平台的确不错，不过噪音和体积在客厅就显得完全不合适了，而 Gen10p 摆电视柜下面刚刚好。

在使用过程中我还出现过升级固件导致平台下线不得不让我家人手动触发物理硬件开关的情况，不过总的来说。大部分日常运维操作（作死折腾），都可以依靠 IPMI 进行救援。

优点：真的好看，从外观到 ILO6，又小巧又能干的感觉，外置电源还可以很容易的藏在角落里。<del>是带尾巴的黑长直贫乳魅魔</del>
缺陷：Microserver Gen10 Plus 最大的缺陷就是那可怜的内存和 PCI 扩展性，而且单 PCI 物理插槽在 HPE 的 BIOS 里只支持 x8x8 的 Bifurcation，直接导致了大部分的纯物理 PCI Split Card 都无法正常工作（包括我之前认为理论可能的使用 x4x4x4x4 Nvme split card 并只插 0 和 3 的方案，实际上在我的机器上仍然只有 Nvme 0 会被识别） 好在我并没有那么高的扩展要求，插个 P3700 就当没有 PCI 槽了。至于万兆，我觉得有那需求都不会考虑这种带有严格体积的四盘位存储机。

软件选型思考：

我选择了 TrueNas 作为新的文件服务操作系统，
首先不会继续考虑群晖了，事实上我之前一直使用 DSM 作为文件管理系统是因为手上有一台白裙可以服务降级，但 DSM6.2 以后的大面积翻车和常年停滞的黑裙安全性更新让我不再想继续选择
Ceph，我承认它足够的先进和分布式，但单机条件下，组件越多，单点故障率也的也越高
Unraid，不想考虑和群晖一样的破解方案了，以及在群聊的时候谈到这玩意的文件系统安全性也是灵车级别...

软件 ESXi 7.0

• 原版 OpenWrt 19.07
  • 通过 ShellClash 进行分流代理可以解决我的联网需求，使用过 lede/koolshare 的魔改版，但是感觉添加的功能对我必要性不大
• RHEL 8
  • 使用开发者计划领到的免费授权，安装 Podman 跑大部分的服务，推荐使用 podman-compose 这个工具直接用现成的 docker-compose.yml 完成很多现有应用的部署，并 generate 为 systemd services 进行自启动
• TrueNas 11.2
• 若干其他的测试折腾环境

文件迁移

迁移的过程中使用原来的 DS216j 作为数据拷贝的源机器

我准备了另外的硬盘并在 TrueNas 完成初始化并配置好 pool，这里直接创建 stripe data vdev 即可，如果数据大且十分重要，建议至少两块硬盘 MIRROR 来作为拷贝的中继

如果在群晖端执行 rsync 建议安装这个 synocli[https://synocommunity.com/package/synocli-net] 套件并全程使用 screen 执行以避免操作中断

我的命令以在 DS216j 上面执行 rsync 为演示

rsync -aHAXxv  --delete --progress -e ssh -T -o Compression=no -x [source_dir] [dest_host:dest_dir]

如果文件量比较大，建议拷贝前先在 TrueNas 的 Service 中打开 RSync 服务，并添加你拷贝的目标路径为 RSync Module

随后执行

rsync -aHAXxv  --delete --progress  [source_dir] [dest_host://module/dest_dir]

在我的测试工况下，1Gbps NIC 通过 ssh 协议拷贝峰值速度约为 22MBps，通过 rsync tcp 的峰值速度为 55MBps

随后拔下群晖的硬盘，插上并建立存储池，重复直到所有数据转移完成

工具的替代和使用习惯改变

File Station 替代品

我先后试用了 NextCloud，Firebrowser
更早之前还有可道云，Cloudreve，或者一些面板自带的文件管理等
最终还是拿 FileBrowser 做 Web 端的文件浏览
缺点： MKV 没有字幕

Moments & Photo Station 替代品

这里我选择了 PhotoView 这个开源的方案，效果如下

它支持 PWA，在移动设备上也能获得相对可以的体验

缺点：
残废且占用极高 CPU 的人脸识别
只能读不能写，照片备份还需要 NextCloud 或者其他的客户端协同完成

Download Station 替代

我用 RHEL 8 跑起了 Qbitorrent Enhanced-Nox 用来订阅 RSS 下载的动漫，
PT 站我不是很常用，只是偶尔下一些不太好找的电影会去 MT，单独开了个 Transmission 用来挂 PT 的种子

对象文件存储

TrueNAS 官方 Plugin 里面有 Minio，直接安排（

服务暴露

我使用这个 https://nginxproxymanager.com/ 在一个高位端口转发我内网的大多数交互式 Web 服务
它同时支持图形化配置 Basic Auth 和简单的权限组 虽然在相当一段长的时间里我都沉溺于手写和折腾各种 Nginx 的 Configure trick
但是大多数时候手动配置只会给自己的维护添堵，尤其是想添加一个域名或者改一个转发接口就得连回去拷配置再调试 <del>Web 它不香吗</del>

而且证书的存放也是头疼的一件事，感觉找个容器把这些全关进去反倒能提高安全性和稳定性

感想和我踩的一些坑

• Truenas 的内存占用真的非常恐怖，得益于 ZFS，这玩意甚至在我转移数据的时候吃满了分配的 16G 内存用作 ZFS cache 。
• 我在转移下载盘的时候错误的开启了 ZFS 的 dedup，这个操作导致磁盘的拷贝 I/O 直接掉回了百兆时代。
• 我第一次给它分了 80G SSD 做系统空间，并期望它能利用好剩余的 SSD 分区用作 cache，
• 理想很丰满，实际上这也是我对 Truenas 的误解。
• 在查阅了很多博文后我了解到对于 ZFS 而言内存容量的影响远大于所谓的 SSD cache，
• 因为这样，我重装了一下，并分配了 8G 的系统盘和 40G 的应用插件盘。
• 以及 TrueNas 虽然表面上具备完善的 UI，但具体到文件管理，直接 SSH 进去一把梭反而是最方便的。
• ACL 很容易把头搞炸但是配置成功了以后使用相当舒服，安定感十足的 BSD 。
• NFS 在多终端同时挂载的工况下经常会出现一个文件 touch 提示存在而 cat/ls 却不存在的闹鬼情况
• 推荐使用 WebDAV 作为内网挂载的协议（而且这玩意实际拷贝速度比 NFS 高好多）

部分参考文档：
https://gist.github.com/KartikTalwar/4393116
https://github.com/awesome-selfhosted/awesome-selfhosted
https://www.reddit.com/r/freenas/comments/c1k337/to_cache_or_not_to_cache_that_is_the_question/

Writting by Morxi , Thanks for reading