NAS 基础设施：从裸机到八台虚拟机

整个升级的地基。旧 NAS 五年服役攒下的账——CPU 撑不住、内存加不动、系统盘悬在 USB 上、所有服务挤在一个系统里互相缠绕——这次全部在基础设施层一次性解决。本文记录从"为什么选虚拟化"到八台虚拟机落位的完整决策与实施，以及三条用故障换来的纪律。

背景：旧平台撑不住了

旧 NAS 是 2021 年装配的 J3455 平台，五年下来每一层都到了极限：四核四线程的低功耗 CPU 跑着"宿主系统 + 存储虚拟机 + 应用虚拟机"三层，服务一忙全家都卡；DDR3L 12GB 内存开两个虚拟机就见底；SATA 接口用尽原生加转接的全部七个；系统盘挂在一个 USB SATA 盘上，五年里始终是心里的一根刺。更深层的问题是架构：所有服务共享一个故障域，升任何组件都要掂量全局，动一发牵全身。

目的

新平台要达到四条：性能余量足够跑全部现有服务加未来扩展；服务之间故障隔离——博客挂不影响家人相册，存储维护不停应用；系统盘可靠性质变（USB → 双 SSD 镜像）；整机可维护——任何一台"虚拟的服务器"可以单独备份、回滚、重建。

方案选择：为什么是 PVE 而不是继续裸机 Docker

两条路线摆在一起过：

• 裸机 + Docker：简单直接，但回到了老路——所有服务一个故障域，Docker 网络和系统配置互相缠绕，正是旧平台五年攒下的乱象源头
• Proxmox VE 虚拟化：多一层抽象的开销，换来按职责切虚拟机的能力——存储归存储、应用归应用、网关归网关，每台独立快照/备份/重建

判断依据回到目的：要的是故障隔离和可维护，虚拟化的开销（约 5% 性能 + 内存预分配）对 8 核 16 线程的新平台完全可接受。选 PVE。硬件上 CPU 选 9700X（性能够、发热低）、双 1TB SATA SSD 组 ZFS mirror 做虚拟化层存储（校验和 + 镜像双保险，对虚拟机磁盘这种"坏了就灾难"的数据比普通 RAID 更合适）、六块机械盘暂不动等整体搬迁。

实施：装机、破案、落位

装机与破案。 PVE 9.2 安装本身一次成，但点亮后三天崩了四次。排查走了弯路：先怀疑主板换了一块，无效；最后逐槽轮换内存定位——内存颗粒与这代平台不兼容，换品牌后彻底稳定。这次破案确立的排查优先级：新平台连续异常，先怀疑内存兼容性，比换主板便宜得多。

八台虚拟机落位。 按职责切分，VMID 与内网地址尾号一致（“110 就是点 110”）：

VM	职责	定位
存储层	OMV	全部文件服务的家
应用层	博客全家桶	十七个容器的宿主
网关层	nginx + WireGuard	全家公网唯一入口
观测层	Kuma + Prometheus + Grafana	出事第一个知道的
家庭层	网盘 + 相册	家人用的
开发层	开发机	远程直达
支撑层	图形排障	按需启动
模板	云镜像	克隆即用

三条用故障换来的纪律，都是踩过才写进流程的：

1. 虚拟机 CPU 显式指定指令集档位——默认档缺现代指令，新版 MongoDB 一启动就崩；更深的教训是模板是隐性继承源，改模板等于改未来所有克隆
2. 数据盘配 discard——不开的话虚拟机内的空间释放无法穿透，老平台四百 GB"虚胖"系统盘就是这么来的
3. 备份要验真——收官核查发现备份任务从未真正自动跑过（调度器曾挂死，“任务已建"掩盖了"从未执行”）；宁可承认没备份，不要假装有备份

结果：对照目的验收

• 性能余量：全部服务迁入后资源占用远低于容量，且出现瓶颈时可在线扩（应用机一次 OOM 后内存在线翻倍，分钟级）
• 故障隔离：后续迁移中应用虚拟机反复重建配置，家人服务零感知——隔离真实生效
• 系统盘质变：ZFS mirror + 校验和，定期 scrub 有主动体检
• 可维护：八台虚拟机全部纳入统一快照策略，配置全部进仓

四条目的全部落地。基础设施层做完的最大感受：后面所有迁移和折腾都变成了"虚拟机里的事"——炸了重建、小了扩容、闲了关机，物理机退回它该在的位置：稳定跑着，别的不管。

尾声

老平台教会我"一台机器能跑多少东西"，新平台教会我"跑坏了怎么救"——后一种能力，才是这次地基工程真正买到的东西。

文章链接：
https://www.zywvvd.com/notes/environment/nas/nas-infra/nas-infra/