过去五年，我的所有软件开发工作都是在虚拟机（VM）中完成的。我的每个项目都有一台专属的 VM，这让我免受依赖冲突和 TCP 端口冲突的困扰。

三年前，我更进一步，搭建了自己的 homelab(家庭实验室) 服务器来托管我所有的 VM。这是一笔非常划算的投资，它加快了许多开发任务的速度，也提升了可靠性。

在过去的几个月里，我开始触及我这台 VM 服务器的性能极限。我的项目变得越来越吃资源，而我第一次装机时犯下的错误也开始反噬我。于是我决定为 2020 年打造一台全新的家庭实验室 VM 服务器。

我不关心背景故事；直接给我看你的配置！

如果你对这个项目的“为什么”不感兴趣，可以直接跳到配置清单。

为什么要搭建一整台 VM 服务器？

起初，我用 VirtualBox 在 Windows 桌面机上运行 VM。这在一开始没什么问题，但重启成了一件极其麻烦的事。

Windows Update 强制重启、安装软件后需要主动重启，再加上偶尔的操作系统崩溃，我每个月都得把整套开发 VM 重启三到五次。

一台专属的 VM 服务器让我免去了绝大部分重启。VM 宿主机上只运行最少的软件，因此崩溃和强制重启都很少发生。

为什么不使用云计算？

云服务器可以起到同样的作用，还能省去维护自己硬件的麻烦（和乐趣！），但价格高得离谱。与我这台 homelab 服务器资源相当的 AWS EC2 实例每年要花费 6000 多美元：

我可以通过按需开关云实例来大幅降低成本，但这会给我的工作流程带来摩擦。使用本地 VM 服务器，我可以让 10 到 20 台 VM 随时待命，而不必为精细管控成本操心。

吸取过去的教训

我 2017 年的那套配置一直用得不错，但经过三年的使用，我发现了几个亟需改进的关键问题。

1. 存储放在本地

我的 Synology NAS 有 10.9 TB 的存储容量。有这么大的网络存储空间，我心想：“何必在服务器上放超过启动宿主系统所需最低限度的磁盘空间呢？”

事实证明这是个愚蠢的主意。

首先，把 VM 放在网络存储上运行，会形成对磁盘服务器的严格依赖。Synology 每隔几个月就发布一次系统升级，而它们的补丁总是需要重启。由于我的 VM 运行在 Synology 的存储之上，每次应用 Synology 的更新之前，我都得关闭整个 VM 机群。这和我当年在 Windows 桌面机上运行 VM 时遇到的重启问题一模一样。

其次，通过网络进行随机磁盘访问非常慢。第一次装机时，我的开发工作大多是后端 Python 和 Go 应用，它们没有明显的磁盘 I/O。从那以后，我扩展到了前端 Web 开发。现代 Web 框架都使用 Node.js，所以每个项目的依赖树里都有 1 万到 20 万个随机分布的 JavaScript 文件。Node.js 构建涉及大量的随机磁盘访问，这对网络存储来说是最糟糕的场景。

2. 选择更好的 VM 管理软件

为第一台服务器挑选 VM 管理软件时，我评估了两个选项：Kimchi 和 VMWare ESXi。VMWare 精致和成熟得多，但 Kimchi 以其草根气质和开源属性打动了我。

我装上它之后没多久，Kimchi 的开发就停止了。

随着时间推移，Kimchi 的缺陷越来越明显。我经常需要多次点击 VM 的“clone”或“shutdown”按钮它才肯配合。还有一些令人抓狂的 UI bug，按钮会在我点击前消失或移位。

3. 为远程管理做好规划

如果你读完上面一段心想：“Kimchi 只是个软件而已。Michael 为什么非得装一台全新的服务器，就为了换个 VM 管理器？”那是因为我没能预见到远程管理的重要性。

我的 VM 服务器就是一台放在办公室角落的 PC，没有连接显示器或键盘。在 99% 的时间里这没问题，因为我可以通过 SSH 登录或使用 Web 界面。但在剩下 1% 的时间里——服务器无法启动，或者我想安装新的宿主操作系统时——那就痛苦极了。我得把服务器拖到桌边，拔下桌面机的键盘和显示器，修好需要修的东西，再把办公室里的一切恢复原状。

对于下一次装机，我想要一个从机器一通电就能提供物理级访问的虚拟控制台。我考虑过类似 Dell 的 iDRAC 或 HP 的 iLO 这样的方案。

选择配件

CPU

我第一台 VM 服务器的 CPU 是 Ryzen 7 1700。它有 8 核 16 线程，是当时最热门的新 CPU。但当我在 /r/homelab——reddit 的 homelab 子社区——上炫耀我的配置时，他们嘲笑我是个不入流的业余玩家，因为我用了消费级配件。酷孩子们都用企业级设备。

我下定决心再也不让 /r/homelab 嘲笑我，于是踏入了企业级服务器硬件的世界。我甚至玩起了高端的，选择搭建一台带两颗物理 CPU 的系统。

为了让每一美元买到最好的性能，我把搜索范围限定在四到八年前发布的二手 CPU 上。对于每个候选型号，我都在 PassMark 上查了跑分，然后去 eBay 查看该型号二手 CPU 的近期成交价。

性价比最高的似乎是 Intel Xeon E5 v3 系列，尤其是 2600 型号。我最终选定了 E5-2680 v3。它的平均跑分为 15,618，eBay 二手价约 130 美元。

作为参照，我上一套配置的 Ryzen 7 跑分为 14,611。所以用双 E5-2680，我的算力比旧服务器翻了一倍还多。

主板

双 CPU 系统的缺点是它限制了我对主板的选择。支持双 Intel 2011-v3 CPU 的主板屈指可数，价格从 300 美元到 850 美元不等，远超我原本打算在主板上花的钱。

我选了 SuperMicro MBD-X10DAL-I-O，320 美元的价格比同类主板便宜，但仍然是我上一块主板的五倍价钱。

内存

服务器内存方面，可供参考的选购信息似乎少得多。消费级硬件有大量网站发布各种内存条的评测和跑分，但服务器内存我没见到类似的东西。

我选了 Crucial CT4K16G4RFD4213 64 GB (4 x 16 GB)，因为我信任这个品牌。我选 64 GB 是因为我上一套配置是 32 GB，而我的一些工作流程已接近这个上限，所以我想内存翻倍应该够我再用几年了。

存储

我喜欢 M.2 SSD，它体积小、性能出色，还能不用接线就整齐地藏在主板上。可惜的是，MBD-X10DAL 不支持 M.2 接口。

于是我还是用了传统的老式 SATA。我买了一块 1 TB Samsung 860 EVO。我通常给每台 VM 分配 40 GB 空间，所以 1 TB 绰绰有余。以后需要升级时，随时可以再买硬盘。

电源

挑选电源（PSU）没什么意思，所以我再次主要按信任的品牌来选，即 Corsair CX550M 550W 80 Plus Bronze。

我所有配件的功耗加起来是 400 W，所以 450 W 就够了。但 550 W 版只贵 10 美元，多花 100 W 的余量，这个价钱看起来挺划算。

对我来说唯一重要的其他特性是半模组线材。上次装机我犯了个错误，用了非模组线材，这意味着 PSU 的所有线缆都永久连着。我的服务器内部几乎没什么配件，多余的电源线造成了杂乱。用半模组线材，我可以通过拆掉 PSU 上不用的线缆来保持整洁。

风扇

双 CPU 配置让散热成了一个意料之外的难题。MBD-X10DAL 的两个 CPU 插槽之间空间不多，所以我仔细寻找足够薄、能并排放下的风扇。一对 Cooler Master Hyper 212 符合要求。

机箱

我的服务器不起眼地放在办公室角落，所以我不想要带透明侧板或炫彩灯光的机箱。

Fractal Design Meshify C Black 评价很好，看起来是一款简洁安静的机箱。

显卡

对于无头服务器来说，显卡无关紧要。但初次安装系统和偶尔调试时我还是需要看到屏幕，所以我选了 MSI GeForce GT 710 这个便宜又省心的选项。

远程管理

我调研了远程管理方案，它们的价格让我震惊。起初我想用 Dell iDRAC，但它的远程控制台需要一个 300 美元的企业版许可证，而且会把我的配置限制在 Dell 配件上。我也看过 KVM over IP(基于网络的 KVM) 方案，但那些更贵，从 600 美元到 1000 美元不等。

为了实现远程管理，我采取了一个不寻常的做法：用 Raspberry Pi 自己做一个 KVM over IP 设备。我给它起名叫 TinyPilot。

TinyPilot 捕获 HDMI 输出，并转发来自浏览器的键盘和鼠标输入。它提供的效果等同于物理连接真实的键盘、鼠标和显示器。软件是开源的，我也提供成品版本供购买。

我的 2020 服务器配置

VM 管理：Proxmox

我用 Proxmox VE 来管理我的 VM。

上次装机被 Kimchi 坑过之后，我不太愿意再尝试另一个免费方案。Proxmox 已经存在 12 年了，所以我觉得它是个足够稳妥的选择。在界面方面，它比 Kimchi 强一大截，但在精致度上仍落后于 ESXi。

我最欣赏 Proxmox 的地方是它的可脚本化能力。我经常做的一件事是从模板创建新 VM，然后用 Ansible 安装额外的软件。用 ESXi 时，我想不出不靠每次在 Web UI 里手动点按钮来完成这个操作的办法。而 Proxmox 的命令行工具足够强大，我可以用脚本把它简化到只需执行 ./create-vm whatgotdone-dev，我的脚本就会创建一台全新的 What Got Done 开发 VM。

我最大的抱怨是 Proxmox 不够直观。我一开始甚至不知道怎么安装它，直到找到了 Craft Computing 的安装教程。但一旦你摸清了门路，它就很好用了。

基准测试

在淘汰旧 VM 服务器之前，我对我常用的工作流程做了一些简单的基准测试，以衡量性能提升。

我的旧 VM 大多运行在网络存储上，因为本地 SSD 只装得下几台 VM。在下面的基准测试中，我比较了三种不同场景下的性能：

• 2017 服务器（NAS）：我放在网络存储上的典型 VM
• 2017 服务器（SSD）：少数放在本地存储上的 VM
• 2020 服务器：所有 VM 都运行在本地 SSD 上，所以不存在 NAS 与 SSD 之分

配置一台新 VM

我做的第一个基准测试是配置新 VM。我有一个标准的 Ubuntu 18.04 VM 模板，几乎所有 VM 都基于它。每次需要新 VM 时，我都会运行一个执行以下步骤的 shell 脚本：

1. 从基础模板克隆 VM。
2. 启动 VM。
3. 把主机名从 ubuntu 改成该 VM 的名字。
4. 重启 VM 以使新主机名生效。
5. 用 apt update && apt upgrade 更新到最新软件。

我的新服务器让这个工作流程大幅提速。克隆 VM 从旧服务器上的 15 分钟缩短到新服务器上的不到 4 分钟。

如果跳过软件包升级步骤，提速就没那么惊艳了。新服务器仍然碾压 NAS 存储上的表现，从 8 分钟降到不到 2 分半。但 SSD 对 SSD 时，它比我的上一台服务器慢。克隆 VM 很可能受磁盘性能制约，而我旧的 M.2 SSD 比新的 SATA SSD 更快。

启动一台 VM

从 VM 通电到看到登录提示符，需要多长时间？

我的旧 VM 需要 48 秒启动。旧系统上少数 SSD 上的 VM 稍好一些，32 秒显示登录提示符。我的新服务器把两者都甩在身后，只需 18 秒就能启动一台 VM。

运行 What Got Done 端到端测试

我的每周日志应用 What Got Done 有一套对其功能进行端到端测试的自动化测试。这是我最复杂的工作流程之一——它涉及编译 Go 后端、编译 Vue 前端、构建一系列 Docker 容器，以及自动化 Chrome 来测试我的应用。这也是把旧 VM 资源耗尽的工作流程之一，所以我预期会有显著提升。

出人意料的是，两台服务器之间没有显著的性能差异。冷启动（下载所有 Docker 基础镜像）时，新服务器比旧的慢 2%。当 Docker 基础镜像已在本地时，我的新服务器胜过旧的，但只快 6%。看来瓶颈主要在磁盘和浏览器交互上，所以新服务器没带来太大差别。

构建 Is It Keto

我的一个常见工作流程是构建 Is It Keto，一个面向生酮饮食者的资源网站。我用 Gridsome——一个面向 Vue 的静态网站生成器——来生成这个网站。

我原本预期这里会有显著提速，所以当构建反而变慢时我很惊讶。在我的旧服务器上，这个构建似乎主要是 CPU 密集型的，但在新服务器上把 CPU 资源翻倍却毫无作用。我的下一个猜测是它受磁盘制约，于是试着把文件移到 RAMdisk 上，但构建速度依然没变。

我的推测是：这个工作流程是 CPU 密集型的，但并行化做得不好。我的旧服务器核心数更少，但每个核心更快。如果构建只限于五六个线程，它就无法利用新服务器的 48 个核心。

训练一个新的 Zestful 模型

Zestful 是我的基于机器学习的食谱配料解析 API。每隔几个月，我会用新数据训练它。这是我最吃 CPU 的工作流程，所以我很想知道新系统能把它跑成什么样。

终于有一个能让我 48 个 CPU 核心大显身手的场景了！新服务器完胜旧服务器，训练模型用时不到一半。可惜的是，这个工作流程我一年只跑几次。

反思

用消费级硬件并不丢人

即使 /r/homelab 可能永远不会尊重我，下一次装机我还是打算回归消费级硬件。

在我看来，服务器配件最大的优势是它们与服务器软件的兼容性更好。2017 年的时候，我不得不禁用 CPU 的多线程才能装上 ESXi，导致性能大打折扣。但那是 Linux 内核的限制，后来的更新修复了它。

服务器硬件之所以卖高价，是因为它更可靠。对于面向用户的服务，这一特性很重要，但在开发服务器上就没那么重要了。开发服务器偶尔崩溃或发生位翻转，不该毁了你一天的心情。

考虑双 CPU 的全部成本

这是我第一次搭建双 CPU 电脑。这是一次有趣的经历，但我觉得并不值得这么折腾。

根据我的基准测试，CPU 在我的工作流程中很少成为瓶颈。最有说服力的证据是 Proxmox 的 CPU 使用率曲线图。过去几个月里，我从未把 CPU 负载推到 11% 以上，所以我严重超额配置了。

双 CPU 的要求大幅推高了主板成本，也限制了我的选择。支持双 Intel 2011-v3 CPU 的主板寥寥无几，所以在其他主板功能方面我没什么可挑的。

远程管理带来灵活性

在用 TinyPilot 管理我的服务器之前，我没有意识到自己有多抗拒改动。更改任何 BIOS 或网络设置，都有可能让我接下来几个小时的生活耗在搬机器、重新连接外设来调试修复问题上。正因如此，我从来都不想动那些设置。

拥有一个虚拟控制台给了我失败的自由，也让我更愿意尝试不同的操作系统。安装和学习一个新操作系统总归是件费劲的事，但知道不用把机器搬来搬去，让我对此开放得多。如果我没做 TinyPilot，我可能会一直守着 ESXi 觉得“够用了”，而不去尝试 Proxmox。

一年之后

有读者问我，回顾这套配置有没有想改的地方，所以我想分享一篇更新——这台服务器已经用了有一年多了。

CPU——太多了

双 E5-2680 v3 我确实买过头了。

一年使用中，我从未达到过 100% 的 CPU 使用率，超过 50% 容量的次数也屈指可数，所以只装一颗 CPU 对我来说完全够用。

SSD——不够

我的 1 TB Samsung SSD 快满了，所以我刚又买了一块 2 TB Samsung 870 Evo，SSD 总容量达到 3 TB。机箱里还有充足的空间放更多 SSD。

默认情况下，我给每台 VM 分配 40 GB 磁盘，这有时会不够用。用 Docker 干活时，容器镜像很快就会吃掉磁盘空间。每隔几周，我就发现 VM 的磁盘满了，得运行 docker system prune --all，所以额外的磁盘空间能让我免受这些打扰。

内存——稍微少了点

64 GB 内存基本够用，但有几次我不得不关掉一些 VM 来腾出更多内存。我不想在管理工作资源上打断工作流程，所以又订购了 64 GB 同款内存条。

Proxmox——依然很好

作为 VM 管理器，我依然喜欢 Proxmox。我购买了一个许可证，不确定它是否增加了我会用到的新功能，但我很乐意支持这个项目。

烦人的是，许可证按 CPU 数量计价，所以除了买太多 CPU 的懊悔之外，我还得为 Proxmox 付双倍的钱。

配件清单（截至 2021-12-05）

* 在初次装机一年后购买。