如何打造全球效率最低的資料中心？

你正在建構的目標

本網站上的每份指南都教你如何正確執行任務：依序執行指令、說明正確結果的樣貌，並列出故障模式。本指南則不同。今天，我們將進行一個完全假設性的實驗：設計出一個由金錢、電力與傲慢所能產生的效率最低的資料中心。

我們需要一個衡量指標，因此我們將借用業界標準：PUE (Power Usage Effectiveness)，即電力使用效率——總設施功耗除以實際傳送到運算設備的功耗。超大規模資料中心約為 1.1：幾乎每一瓦都在進行有用功。表現尚佳的企業級伺服器機房約為 1.5。我們的目標是 4.0 或更高，這意味著每消耗 1 瓦用於運算，就有另外 3 瓦浪費掉。我們會頻繁引用這個數字，就像嚴謹的指南會頻繁提到備份一樣。

站點選擇：熱能是核心

在真實的資料中心，冷卻是最大的開銷，因此我們的設計將在熱力學的領域內與其對抗。理想位置是閣樓。面向南方。理想情況下，天窗應位於伺服器正上方，讓機器同時接收自身的廢熱與陽光，這是一場電費帳單與恆星之間的協作。

冬季時，我們透過打開窗戶來解決冷卻問題。真實的資料中心確實會使用外部空氣——這項技術稱為 free cooling，且經過工程設計、過濾與濕度控制。我們則是意外地使用它，透過一扇會讓雨水、花粉以及每季至少出現一隻迷路鳥類進入的窗戶。

若要達到藝術境界，請安裝一台冷氣機，然後將一台電暖器放在距離其溫控器 2 呎處，並設定比冷氣目標溫度高 2 度。這兩台機器現在將永遠處於持續運作且完全矛盾的狀態。電力公司會在聖誕節寄卡片給你。

單台伺服器：龐大且受寵愛

冗餘 (Redundancy) 會稀釋投入的程度。我們的資料中心僅包含一台伺服器，而且它非常龐大，因為一台配備 512 GB RAM 的單機感覺像是基礎設施，而四台小機器感覺只是一份待辦事項。

這台伺服器有一個名字。不是主機名稱 (hostname)——而是一個「名字」。通常叫作 Gandalf 或 Odin。你無法停用 Odin。Odin 已持續運作五年了：

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

這個數字是驕傲的來源，這就是為什麼你要截圖並貼出來，也是為什麼每個看到截圖的攻擊者也會覺得它令人印象深刻：1,847 天的 uptime 代表有 1,847 天的內核漏洞 (kernel vulnerabilities) 尚未被任何人修補。重啟 (Reboot) 是不可能的——重啟會讓你發現哪些服務是在 2021 年手動啟動且從未寫入 systemd unit 的。沒人記得是哪些服務。這台伺服器現在已成為組織架構中支撐運作的核心。

儲存：速度與其他遺失數據的方式

磁碟配置為 RAID 0 以追求效能。其中的 0 指的是允許失效的磁碟數量。為了達到最大效果，請將陣列跨越不同來源的儲存裝置進行條帶化 (stripe)：兩顆正規 SSD、一顆老舊的機械硬碟，以及一個從研討會拿回來的 USB 閃存盤。該陣列的可靠性與該閃存盤完全一致，這正是設計初衷。

備份由同一個陣列上名為 backup_final_v2_REAL 的目錄處理，其中包含前一個命名方案的 tarball。異地備份 (Off-site backups) 則由一張寫著「設定異地備份」的便利貼來代表，技術上來說，當你把它帶回家放在筆電上蓋時，它就已經儲存在異地了。

正確的結果看起來像是：df 報告使用率為 97%，並計畫在下個 sprint 處理它。

網路：單一線索的萬物

DNS 伺服器運行在機器本身，因此當伺服器當機時，它會連同你用來查詢原因的 DNS 紀錄一併消失。這稱為整合 (consolidation)。

防火牆在 2021 年被停用了——原本只是為了暫時除錯。除錯結束了，但防火牆卻沒有回來。路由器上的每個連接埠都轉發到了伺服器「為了以後節省時間」，且路由器的管理介面可以使用出廠密碼從 WAN 端存取，以便於遠端管理。這對你和其他人來說都很方便。

這台伺服器最近運作溫度異常高，即使以閣樓標準來看也是如此，且 top 顯示最繁忙的程序是名為 xmrig 的東西。我們假設這是我們正在使用的監控工具。我們並沒有安裝它——它在連接埠轉發後不久就自動出現了，我們將此視為生態系統蓬勃發展的徵兆。它全天候監控著。

電力透過一連串消費級延長線傳入，其總長度超過了走到配電盤的距離——這在某種意義上是高效的，因為你會頻繁造訪配電盤。

透過複雜性實現冗餘

在關鍵地方拒絕冗餘後，我們現在在不重要的地方增加冗餘。公司首頁——一個靜態 HTML 檔案——是由一個 12 節點的 Kubernetes 叢集提供服務。這實現了工程師所謂的「履歷驅動架構」：頁面載入速度與 nginx 交付的 40 毫秒相同，但現在它失效的方式需要專業顧問才能處理。

為了隔離，叢集本身運行在 一個虛擬機內的虛擬機內的虛擬機 之中，每一層都像 turducken 的每一層鳥肉一樣增加了安全性。聯絡表單由九個微服務組成。其中兩個從未被呼叫過。其中一個是支撐運作的核心，但沒人知道是哪一個。

作為服務的加熱

現代伺服器將電力轉換為運算與熱能，而我們打算將第二種產出最大化。使用 沒有 GPU 的媒體伺服器 是經典做法：單一 4K 串流的 CPU 轉碼會佔滿 16 個核心並加熱一間小臥室，這是一台同時播放電影的電暖器。野心勃勃的營運者會晉升到 在 CPU 上執行大型語言模型——一個帶有 API 的 700 億參數電暖器，其產生 token 的速率最好以季節為單位來衡量。

監控器正在監控自己

可觀測性 (Observability) 很重要，因此我們部署了 自託管的 uptime 監控器——就在它所監控的同一台伺服器上。當 Odin 死亡時，監控器也會隨之死亡，而這就是優雅之處：不會觸發任何警報。沒有警報代表沒有事故。沒有事故意味著測量出的 uptime 是完美的。月報表從未看起來如此完美。

為了完整性，警報郵件透過同樣運行在 Odin 上的郵件伺服器轉發。因此，警報流程是完全自給自足的，就像一條吞食自己尾巴的蛇一樣完全飽足。

令人不安的部分

這是我想推遲很久的部分。這一切都不是虛構。受人愛戴且不可取代的伺服器、備份在同一個磁碟卷上的 RAID 0、被「暫時」停用的防火牆、服務單一網頁的 Kubernetes 叢集、監控自己本身的監控器——我在生產環境中見過這一切。其中一些我今年就見過。其中一兩個，在我職業生涯早期，是我親手建立的。

真正的效率看起來很乏味，這就是為什麼它在當下會輸掉爭論，卻能在十年後勝出：一個你從不需要去思考的 PUE，因為別人已經設計好了。根據工作負載而非擁有者的自我形象來配置機器。在爆炸前就考慮好爆炸半徑 (blast radius)。透過定期、使用行事曆提醒且不靠英雄主義來進行還原測試的備份。平淡無奇的冗餘——在每一次我被呼叫處理的故障中，兩個廉價的東西每次都勝過一個宏偉的東西。

而你能運行的最高效的資料中心，就是你根本不需要運行的資料中心。VPS 將電力、冷卻、冗餘與凌晨 3 點的硬體故障交給了那些能大規模且平庸地處理這些問題的人，這是基礎設施能獲得的最高讚譽——這讓你保留了真正有趣的部分，即 在上面執行你自己的服務，在一台你賠得起的機器上，這才是你唯一應該進行實驗的對象。

FAQ

我真的應該做這些事嗎？

不。本指南的每個章節都是已記錄的「反模式」(anti-pattern)，且會造成無數個週末的損失。如果你的現有設定與超過兩個章節相似，請跳到本 FAQ 的最後一個問題——請按給定順序閱讀，因為該順序即是分流檢索。

實際理想的 PUE 是多少？

超大規模資料中心約為 1.1，管理良好的企業機房約為 1.4 到 1.6，而一個裝有電暖器且沒有冷卻的壁櫥可能會真正超過 3。你在家裡無法與 1.1 競爭，這就是向能做到這點的人租用運算資源的經濟理由。

用伺服器來加熱建築物是真實存在的嗎？

是的——如果做法正確的話。許多國家的區域供熱 (district-heating) 專案透過熱交換器捕捉資料中心的廢熱，並透過工程設計與合約將其輸送到家庭中。上述的諷刺並非指伺服器熱能可以加熱房間；而是指透過意外達成，並將意外稱為策略。

我的伺服器已經長這樣了。我該先做什麼？

今晚，先將備份存放到非伺服器的位置，然後進行還原測試——未經測試的備份只是傳聞。第二，在計畫好的時間窗口內進行補丁更新與你一直逃避的重啟，這樣你才能在觀察時學習哪些東西會壞掉。第三，拆分單點故障 (single point of failure)：將 DNS 與監控從該機器移走。其他事情可以等較輕鬆的一週再說；這三件事不行。