需求

早期使用习惯:

大概从高中开始我就用群晖的东西来管理我的个人文件,设备先后从 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,又小巧又能干的感觉,外置电源还可以很容易的藏在角落里。是带尾巴的黑长直贫乳魅魔
缺陷: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端的文件浏览
2323.png
缺点:
MKV没有字幕

Moments & Photo Station 替代品

这里我选择了 PhotoView 这个开源的方案,效果如下
20222-42-54.png

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

2021-4-27 254.png

缺点:
残废且占用极高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
但是大多数时候手动配置只会给自己的维护添堵,尤其是想添加一个域名或者改一个转发接口就得连回去拷配置再调试 Web它不香吗

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

感想和我踩的一些坑

  • 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

评论和交流请移步
https://v2ex.com/t/773722

标签: none

发表新评论