世界上最低效的数据中心：构建指南

构建目标

本网站上的每篇指南都旨在教您正确完成一项任务：按顺序执行命令，了解正确结果的表现，并明确列出可能的故障模式。本指南不同。今天，我们完全假设性地设计一座由资金、电力和自大共同打造的最低效数据中心。

我们需要一个指标，因此借用行业自己的指标：PUE，即电能使用效率，指整个设施的总功耗除以实际输送到计算设备的功耗。超大规模数据中心的 PUE 通常约为 1.1：几乎每一瓦电都在执行有用工作。合格的企业机房可以达到 1.5。我们的目标是 4.0 或更高，这意味着计算设备每消耗 1 瓦，就有另外 3 瓦白白损耗。我们会经常提到这个数字，就像严肃的指南经常提到备份一样。

选址：热量才是重点

冷却是真正数据中心最大的单项开销，因此我们的方案要在热力学最擅长的地方与之对抗。理想位置是阁楼。朝南。最好安装一扇天窗，让阳光直接照到服务器上，使设备同时接收自身产生的废热和太阳热量，形成电费与恒星之间的合作。

冬季通过打开窗户来冷却。真正的数据中心确实会使用室外空气，这种技术称为自然冷却，并经过工程设计、过滤和湿度控制。我们会通过一扇同时放进雨水、花粉以及每季度至少一只迷路鸟的窗户，意外使用这项技术。

如需达到真正的艺术效果，可安装一台空调，然后将电暖器放在距离空调温控器两英尺的位置，并将其设定温度调高到比空调目标温度高两度。现在，两台设备会永久持续运行，始终保持完美分歧。电力公司会在圣诞节给您寄一张卡片。

一台服务器，规模庞大，人人珍爱

冗余会削弱投入程度。我们的数据中心里恰好只有一台服务器，而且规模极大，因为一台配备 512 GB RAM 的机器让人觉得这才是基础设施，而四台小机器只会让人觉得像一张待办事项清单。

这台服务器有一个名字。不是主机名，而是一个名字。通常叫 Gandalf 或 Odin。你不能停用 Odin。Odin 已经连续运行五年：

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

这个数字值得自豪，因此你会把它截图并发布出去。而任何看到这张截图的攻击者也会觉得它很 impressive：连续运行 1,847 天，意味着有 1,847 天的内核漏洞无人修补。无论如何都不能重启，因为重启会暴露出哪些服务是在 2021 年手动启动的，以及哪些服务从未写入 systemd unit。没人记得具体有哪些。如今，这台服务器已经成为组织架构中的承重部分。

存储：速度，以及其他丢失数据的方法

磁盘配置为 RAID 0，以获得更高性能。数字 0 表示允许发生故障的磁盘数量。为达到最大效果，应将阵列条带化到来源不同的存储设备上：两块合格的 SSD、一块老化的机械硬盘，以及一根会议上拿到的 USB 闪存盘。该阵列的可靠性与那根会议闪存盘完全相同，这正是设计目标。

备份由同一阵列上的目录 backup_final_v2_REAL 负责，其中包含旧命名方案的 tarball。异地备份则由一张写着“设置异地备份”的便签代替；当您把它带回家并贴在笔记本电脑盖上时，从技术上说，它确实存放在异地。

正确结果应类似于：df 报告使用率为 97%，并制定计划在下个迭代中处理该问题。

网络：一条贯穿所有环节的链路

DNS 服务器运行在服务器本机上。因此服务器宕机时，用于查明宕机原因的 DNS 记录也会随之无法使用。这称为集中化。

防火墙曾在 2021 年被临时禁用，以调试某个问题。调试已经结束，但防火墙没有重新启用。路由器上的每个端口都被转发到服务器，据称“以后可以节省时间”；路由器的管理面板还可从 WAN 侧访问，并使用出厂密码，以便远程管理。您可以访问，其他人也可以。

服务器最近运行温度异常偏高，即使按阁楼环境的标准也是如此；而 top 显示，最繁忙的进程名为 xmrig。我们认为这是正在使用的监控工具。我们没有安装它。端口被转发后不久，它自行出现了；我们将此视为整个环境运行良好的迹象。它全天候监控。

电力通过一串家用电源排插供给服务器。这些排插串联后的总长度超过了走到断路器面板的距离。从某种意义上说，这很高效，因为您会经常前往断路器面板。

通过复杂性实现冗余

我们拒绝了真正需要冗余的地方，却在不需要的地方增加了冗余。公司主页只有一个静态 HTML 文件，却由一个十二节点 Kubernetes 集群提供服务。这实现了工程师所说的简历驱动型架构：页面加载速度与 nginx 直接提供服务时一样，都是四十毫秒，但现在它可能以需要顾问介入的方式发生故障。

为实现隔离，集群本身运行在 嵌套在虚拟机中的虚拟机里的虚拟机 中。每一层都增加了一层安全性，就像 turducken 的每一层都增加一种禽类。联系表单由九个微服务组成。其中两个从未被调用过。还有一个对系统正常运行不可或缺，但没人知道是哪一个。

将供暖作为服务

现代服务器将电力转化为计算能力和热量，而我们的目标是最大化后者。一个不带 GPU 的媒体服务器是经典方案：使用 CPU 转码单路 4K 视频流会占满 16 个核心，并使一间小卧室变暖，相当于一台还能播放电影的电暖器。更进取的运维人员会进一步在 CPU 上运行大型语言模型，打造一台带 API 的700亿参数电暖器；其生成 token 的速率，最好按季节来衡量。

监控系统监控自身

可观测性很重要，因此我们在同一台服务器上部署自托管的正常运行时间监控系统，并由它监控这台服务器。Odin 宕机后，监控系统也会随之停止。巧妙之处在于：不会触发任何告警。没有告警，就没有事件。没有事件，就意味着按监控结果计算的可用性达到完美。月度报告从未如此漂亮。

为完整起见，告警邮件通过同样运行在 Odin 上的邮件服务器中继。因此，整个告警链路完全自包含，就像蛇吃自己的尾巴一样，始终处于“吃饱”状态。

令人不适的部分

下面是我一直拖着不愿写的一节。这里没有任何虚构。那台被视为不可替代的爱机、与备份位于同一卷上的 RAID 0、“暂时”禁用的防火墙、只提供一个页面的 Kubernetes 集群、监控自身的监控系统，这些情况我在生产环境中全都见过。有些还是今年见到的。其中一两个，我在早期工作时还亲手搭建过。

真正的效率很乏味。因此，它在当下的争论中往往输掉，却能在十年后证明自己：PUE 低到你根本不会想到它，因为已经有人完成了工程设计。机器按工作负载配置，而不是按所有者的自我定位配置。在故障发生前就评估爆炸半径。通过按计划恢复来测试备份，并设置日历提醒，不依赖英雄式操作。冗余也应当平淡无奇：两个廉价设备始终胜过一个卓越设备。我被呼叫处理过的每一种故障都证明了这一点。

而你能运行的最高效数据中心，就是不运行数据中心。VPS 将电力、制冷、冗余和凌晨 3 点发生的硬件故障交给那些能够大规模、按流程、乏味地处理这些问题的人。这是基础设施能获得的最高评价。它则把真正有趣的部分留给你，也就是在其上运行自己的服务，并且运行在一台你承受得起损失的机器上；你进行实验时，应该只使用这种机器。

FAQ

我真的应该做这些吗？

不应该。本指南的每个章节都是有据可查的反模式，并且足以耗尽许多个周末。如果您当前的设置与其中两个以上章节相似，请按本 FAQ 给出的顺序直接跳到最后一个问题，因为这个顺序就是故障分诊顺序。

实际上，什么样的 PUE 算好？

超大规模数据中心的 PUE 通常约为 1.1，运维良好的企业机房可达到 1.4 到 1.6，而没有冷却设备、还要用空间加热器取暖的储物间，PUE 确实可能超过 3。在家庭环境中，您无法有意义地与 1.1 竞争。这也从经济角度说明了，为什么应从有能力提供高效计算资源的一方租用计算资源。

用服务器为建筑供暖是真实可行的吗？

可以，但前提是正确实施。多个国家的区域供热项目会通过热交换器回收数据中心余热，并按照设计方案，在工程和合同的支持下，将热量输送到住宅。上文的讽刺点不在于服务器热量不能为房间供暖，而在于意外地这样做，并把这个意外称为一种策略。

我的服务器已经是这种情况了。我首先该做什么？

今晚先备份，并将备份保存到服务器之外的位置，然后执行一次测试恢复。未经测试的备份只是传闻。第二，在计划好的维护窗口中安装补丁并重启，不要再回避重启。这样您可以在观察过程中发现哪些部分会出问题。第三，拆分单点故障：将 DNS 和监控移出这台服务器。其他事项可以等到比较从容的一周再处理；这三项不能等。