时间:2024-05-15 作者:剧中人
写在最前面
这是一篇单纯记录小剧此次家庭服务器改造的文章。
对 NAS、家庭服务器的很多理解个人色彩很浓,方案还没有足够长的时间去验证,因此对你的选择不具备指导意义。
希望你能在小剧这里找到一丝丝可以借鉴的思路,或者可以当做谈资的笑话。
自从春节前夕,小剧对家庭服务器做较大的改造后,近几个月又慢慢新增、更新了部分小玩意儿,简单回顾下这次改造的过程。
可能有些小伙伴会比较懵逼,服务器很容易理解,家庭服务器是什么鬼?
再或者玩过 NAS 的小伙伴会觉得,这不就是 NAS 么,有什么值得分享的?
确实,小剧搭建的家庭服务器和中年老男人口中的 NAS 看起来很像,甚至掰碎了来看零散的碎片都很相似,但在小剧眼中他们却是完全不同的概念。
NAS 的全称是 Network Attached Storage,中文对应的翻译是:网络附属存储。
字面理解就是:部署在网络上的存储设备。
这里的网络并不强调是广域网还是局域网。既然是存储设备,势必要用到各种存储介质,比如机械硬盘、固态硬盘等,以及可能还需要由这些介质组成各种阵列。
当然了,作为一台部署在网络上的存储设备,单纯依靠一根网线并不能实现文件的存与取,还需要借助于一些基于 SMB、WebDav、NFS 等协议实现的服务,来完成各设备间文件的共享。
以上就是我理解的 NAS 最核心、最原始的部分。
然而当你打开 B 站,或者在各个电商平台搜索 NAS。扑面而来的都是 4K 解码、远程下载、AI 相册、智能家居等一堆花里胡哨的东西。
其实这种情况可以理解,毕竟作为一款存储设备,在进入家用消费端的时候。势必要提升上手的易用性、增强单体设备的可扩展性。
在完成最基础的存储功能之上,支持 Docker 或者内置一些服务可以很好的提升产品的竞争力。
Web 开发出身的小剧,最乐于见到的就是可以自由拆分、组合的服务模型了。 作为定位在家庭场景下使用的服务器,最常见的需求就是照片备份、影音存储、文件备份。可能还会有些小伙伴喜欢折腾智能家居、私有化文档、小说阅读等小众服务。
所以家庭服务器可以是一台机器,也可以是多台机器。基于这些机器搭建起一套适合自己家用的各种服务。
“你看看,你看看,这不是跟上面的 NAS 一模一样么?”
小剧搭建的家庭服务器和中年老男人口中的 NAS 看起来很像,甚至掰碎了来看零散的碎片都很相似。
上面也提到了,这两者放在一起比较,确实很像。
小剧真正想表达的是,市面上对于 NAS 理解,已经远远脱离了 NAS 本身。当你在使用 NAS 设备提供的 Docker 搭建各种服务的时候,你在做的操作其实已经是服务的部署与维护,而非单纯的使用 NAS。
确实是这样,对于绝大多数家庭来说,成品 NAS 绝对是最好的选择。
借助于一个单体设备,满足家庭存储的绝大多数需求。简单、方便、不用折腾,出了问题还会有客服在线解答。
但是如果能把存储和服务分开理解,或者把存储作为服务的其中一部分来理解。对于选购什么样的设备有非常大的帮助。
为什么这么说呢 ?
因为 NAS 的核心功能是存储。硬盘位数、支持的最大容量、有没有高速缓存,这些配置能直接影响存储性能、存储安全性和存储容量上限。
作为锦上添花的各类服务,需要更大的内存,更高效的 CPU,甚至独立的 GPU 芯片、额外的网卡接口来做支撑。
存储方面各家计价方式几乎没有差别,而非核心的后者才是最让人苦恼的地方。比如多一块 GPU 芯片可能整体价格就会翻倍,而你一旦前期没有选配,后期想要实现一些如 AI 能力或者编解码就会效果大打折扣,甚至无法实现。
上面的分析就是从“存算分离”的架构思路去理解的。
【存】指的是大量消耗硬盘的数据存储服务。
【算】指的是以消耗 CPU、内存等其它计算资源为主的服务,如 AI 相册、智能家居之类。
存和算都是服务的一部分。借助于这个思路,结合市面上的成品,再审视下自己的需求,大概率就能选择到一款适合自己的方案。
好的方案不仅要考虑实际需要,还要结合个人财力。
小剧财力这一块没问题,只是实际需求中的预算不高而已(狗头🐶)。
小剧没有收藏癖,不是很热衷于保存大量的影视资源,基本上都是需要看什么就临时下载。
目前硬盘里保存的绝大多数都是和个人、家庭相关的文件。以相册、文档为主,总量也只有 720G 左右。
“因此存储虽然是小剧的核心诉求,但对容量要求并不高。”
在 2023 年,小剧曾经写过 《Mongo DB 服务挂起问题排查》,介绍了 Mongo DB 借助于 Docker 部署在了 2013 款 Mac mini 上。使用 frp 与公网服务器上的 NodeJS 服务通信。
因此希望新的服务器同样能够支持 Docker,这样十几年前的古董 Mac mini 就可以成功退役了。
你可能知道,小剧是个爱到处拍拍拍的人。小剧习惯于用【年 > 年月日-事件名 > 照片】这样三层目录结构来备份照片。这是小剧用了很多年的照片备份方案。从早些年的 U 盘备份,到后来的移动硬盘(机械)备份,再到网盘、NAS 阶段皆如此。
照片虽然总容量不大,但碎片化的文件特别难以管理。尤其是命名文件夹是件费脑子的事,在绝大多数没有明确主题的日子里产生的照片,总是被丢进类似于【二月】、【五月】这样的毫无特征的文件夹里。
更烦人的是很难分得清手机里,哪些照片已经备份了,需要一次次一张张的去核对,或者无脑上传一遍遍。
在古董 Mac mini 里浅尝过 PhotoView,对照片管理并没有太大帮助。研究过 PhotoPrism,功能看起来很强,但 UI 给我的感觉糙糙的。最终还是 Immich 惊艳到了我,功能强大且多端支持,UI 很精细,支持手机相册备份、重复照片检测、人脸识别、照片搜索等功能,有机会小剧单独介绍它。
但是 Immich 在我那古董 Mac mini上始终无法正常使用,希望新的服务器可以顺利运行 Immich。
很多小伙伴可能会被 NAS 商家宣传的各种 RIAD 模式所迷惑。花费了大量时间研究不同的阵列模式,以及对应的安全性。
不可否认,Raid 的设计很精妙,在兼顾数据安全和容量上可以找到很多不同的平衡点。
但即使用安全等级最高的 Raid1 模式,也只是在尽可能的增强单体设备的安全性。而通常情况下,多设备同步模式的系统安全更为可靠。
例如火灾、水淹、盗抢、意外跌落等情况发生时,单体设备的安全系数再高,也无法保证数据的安全性。
因此小剧希望新的方案依旧可以支持多设备同步,甚至云端同步。
这几个指标应该是家用和商用最大的区别。因为小剧家的户型并不大,并没有足够的空间容纳形如机架服务器、机箱服务器之类的服务器硬件。
另外当我们身处在家里时,有一半是夜深人静的睡眠时间。小剧并不希望嗡嗡嗡的散热风扇声,或者时不时的“炒豆子”声打扰家人的清梦。
可能很多小伙伴并没有意识到,一味的追求各种指标、配置,除了一次性的硬件购买成本外,7 * 24 小时运行所产生的功耗,也是一个非常大的成本。以 40W 功耗差、0.5 元每度电的成本来算,一年下来就要多花将近两百块(好像也不多)。
这也是一条让大家拼命掏空口袋的指标。各家厂商会在缓存、CPU、阵列模式、网卡上做速度提升,代价就是你得支付远超对应硬件的价格。
并且千兆、2.5G、万兆等网速的支持,还得依赖家庭网络环境,以及使用设备的网速上限。
小剧对此并没有太高要求,能跑满家里的千兆网就足够了。
这是小剧家庭服务器改造前的一部分,设备被安放在 Macbook 的纸盒子里,很简陋也很随意。
小剧使用 H3C M1 的小盒子做家庭主力存储三年了,就是上图中那个白色的小盒子。
在 《小剧的2021》 中【2.3、照片存储方案探索】部分曾经介绍过这个设备。容量只有 1T、易用性不太够,但贵在稳定,并且可靠性很高。
在小剧看来它是一款被新华三抛弃的家庭存储产品。APP 自小剧使用以来没有一次更新,发布至今也只有五个版本。
新华三虽然在产品线中抛弃了它,但好在 Web 服务一直在运行着。设备的初始化、远程访问等功能依旧能用。
它是一台单硬盘模式的 NAS,不支持安装第三方 APP,内置功能也很有限,甚至部分功能完全不可用。
这是前文提到的那个 2013 款 Mac mini,原谅小剧没有找到拍摄清晰的照片,并且原安装位置已被拆除,只能找出来这张主要拍倍思电源的照片凑个数。
Mac mini 被安置在书桌侧面,机器很老,配置很低。
但了解的朋友应该知道,这个版本的 Mac mini 内置了一块机械硬盘,同时主板上预留的接口支持加装一块 m2 的固态硬盘,这也是最后一代支持加装内置硬盘的 Mac mini。
可玩性还是有一点点的,吧~
前文提到的 Mongo DB 服务就是运行在这台 Mac mini 上的,早期使用的 PhotoView 同样也是运行在这里。
另外它内置的机械硬盘容量也是 1T,刚好用来备份 H3C m1 里的数据。
这次改造并没有添置太多的设备,只是根据前面提到的小剧对家庭服务器的理解,以及使用过一些设备,对设备做了增减。
这次改造持续了将近三个月,目前算是稳定下来了。细数一下小剧的购置清单,再加上已有的设备成本,其实并不比成品 NAS 花费低,
基于小体积、静音、低功耗的要求,小剧这次主力服务依旧采用的是 Mac mini。
只是淘汰了 2013 款的古董级 Mac mini,转而购入了一款 m1 版本的 Mac mini。
8 + 256 丐中丐的配置,日常办公使用可能略微有点性能不足,但作为一台 7 * 24 开机的家庭服务器足够了。
Mac mini 体积足够小,外形足够简洁漂亮,运行无噪音,这几点完全打在了小剧的爽点上。
根据苹果官方的 Mac mini 功耗和热输出 (BTU) 信息 显示,m1 版本的Mac mini 闲置功率为 6.8W,最大负载时为 39W,妥妥的省电小能手。
在主力服务器 Mac mini 上安装了 Docker Desktop,用来承载前文提到的 Mongo DB 数据库、Immich 等服务。
各种备份任务也是跑在这台主力服务器上。
还记得之前的主力存储不,是一台 H3C m1 的存储盒子。
这一次小剧把 H3C m1 降级为备份存储,每隔四小时备份一次主力存储的数据,并且开启了夜间休眠模式。
主力存储为购置的 USB4 移动硬盘盒 + 2T 的 m2 固态硬盘,连接到 Mac mini 上。
咦,你是不是发现一个神奇的爽点 ?
没错,改造后的主力存储和主力服务器合二为一了。
主力服务器之所以选择 m1 版本的 Mac mini,还有另一个原因,是它的雷雳接口支持 USB4 的移动硬盘盒。虽说是移动硬盘,但是直通 PCIE 接口。根据网上大佬的测试,读写速度是 Mac mini 内置硬盘的两倍(小剧未求证)。
局域网内的 SMB 协议文件共享,使用 MacOS 自带的文件共享功能实现; WebDav 的功能借助于 Alist 来完成。
可能你会反驳说:固态硬盘不适合做重要数据的主力存储。
这个观点我赞同,但它是相对的。
做好冷备份的前提下,哪怕固态硬盘彻底坏掉了,重新再买一个,恢复数据之后一切又能正常跑起来了。
在不关心寿命的前提下,固态硬盘的高速、小体积、无噪音、不惧跌落等特点全都是优点。
此前两年多经历过很多次断电,都没有遇到过问题。
这次很不幸,断电后 Mac mini 中的 Docker 数据全部丢失。
为了保障服务的稳定性,“斥巨资”购入了 UPS 来为主力服务器 Mac mini 保驾护航。
对小剧这次悲惨的经历感兴趣的话,可以阅读这篇记录。
这次家庭服务器版本改造开始时,是 2024 年春节前夕。
举国欢庆春节时,也是合肥最冷的时候,因此服务器改造初期并没有发现什么不妥。
合肥这座城市有个典型的特点,就是春秋季特别短。三月中旬一过,已然有了夏天的感觉。
这时原本温润的移动硬盘盒悄悄变成了发热的小火山。
其实并没有这么夸张,四五十度对于移动硬盘、m2 固态硬盘来说很清凉,可以不用关心它。一想到它在小剧家 7*24h 工作任劳任怨, 适当的降降温也算是对它辛苦劳作的补偿。
调研后有三个方案:
方案一最常见,也立竿见影,但整体效果一般,而且书房窗户朝西,在接下来的夏天应该很难扛下去。
方案二是我最近刚发现的,效果很惊人,甚至能达到滴水成冰的效果。代价是过高的耗电量,以及冷凝水的隐患。对于小剧这种低功耗家庭服务器的环境来说,显然不合适。
方案三效果比风扇好不了太多,但因为冷却液可以挪到相对温度更低的另一面,在接下来的夏天应该能扛的更久一点。因此就选择了液冷作为降温方案。
找了一圈,市面上并没有直接可用的液冷配件。经过筛选,购入了一款手机液冷套装,改造后加装到移动硬盘上。
小剧玩手机液冷散热
看了前面的介绍,相信你也能发现小剧家庭服务器非常零碎。各种设备以一种奇奇怪怪的姿势连接在一起。
想要保持好用、整洁,甚至还能让人说一句“好看”是很困难的。
空间建模
为此小剧测量了书柜开放格的整体尺寸,以及要部署的各个设备的尺寸,借助于 iPad 的建模软件做了方案预演。
最终在比较满意的四套方案中,选择了空间利用率最高的一个。
近期虽然对设备进行了增减,但整体布局并没有发生大的改变。
前面重点介绍了 Mac mini、移动硬盘盒,附带提到了 H3C m1、UPS、液冷散热这些设备。这里小剧简单介绍下另外几个小黑盒子。
交换机
这个没什么好介绍的, 单纯是为了拓展网口 + 设备互联而已。唯一值得说道的,应该就是插在上面的一根根,由小剧纯手工打造的网线了吧。
统一的颜色、定制的长度,让这个局促的小空间不至于那么杂乱。
蒲公英
这是一个成品的内网穿透盒子,只有一个功能。就是让小剧在外的时候,可以借助于它构建的虚拟专用网络(V*N)访问家庭内网。
免费账号只能设置三台设备使用,这个盒子自己需要占掉一个。也就是说真正可以给小剧自己和家人添加的设备只有两台。
玩客云盒子
图中在移动硬盘盒和 H3C m1 中间的一个小设备。可能有部分小伙伴知道,它可以挂机跑分挣钱。但小剧只是单纯把它当成一个 Armbain 的服务器,跑一些简单的内网 Web 服务。
另外背后的 USB 口用来给蒲公英供电。
神秘小盒子
这是一台 R2S 的小盒子,当作旁路由来用。绝大多数时候都是关机的状态,偶尔需要给 Docker 等服务加速的时候才会开一下。
轻度使用,可有可无。
回顾整篇记录,小剧反复提到过很多遍“单体设备”这个词。
翻阅全文后再看市面上对于 NAS 的理解,和小剧口中所谓的“家庭服务器”。最大的差别就是市面上的 NAS 热衷于用一个单体设备来实现完整的功能。
而小剧的家庭服务器方案更倾向于,在下单前先审视自己的需求,再逆向去找满足需求的设备。可以是单体设备,也可以是各种设备的组合。
不给自己生造需求,也不假设自己几乎用不到的峰值性能。随着自己的使用循序渐进,进行设备的更替,让属于自己的方案陪着自己去成长。