過去五年來，我所有的軟體開發工作都是在虛擬機（VM）上進行的。每個專案都有各自專屬的 VM，讓我不必煩惱相依性衝突和 TCP 連接埠衝突的問題。

三年前，我更進一步打造了自己的 Homelab(家用實驗室) 伺服器來代管我所有的 VM。這是一筆非常值得的投資，它加快了許多開發工作的速度，也提升了可靠性。

在過去幾個月裡，我開始感受到 VM 伺服器的效能瓶頸。我的專案變得越來越耗資源，而第一次組裝時犯下的錯誤也開始帶來麻煩。因此，我決定在 2020 年打造一台全新的 Homelab VM 伺服器。

我不在乎背景故事，直接給我看組裝成果！

如果你對這個專案的「為什麼」沒興趣，可以直接跳到組裝成果。

為什麼要打造一整台 VM 伺服器？

一開始，我是在 Windows 桌機上用 VirtualBox 來跑 VM。這樣用了一陣子還算可以，但重新開機變得非常麻煩。

不管是 Windows Update 強制重新開機、為了完成軟體安裝而主動重開機，還是偶爾的作業系統當機，我每個月都得把整套開發用的 VM 重新啟動三到五次。

一台專用的 VM 伺服器讓我省去了大部分重新開機的麻煩。VM 主機只執行最精簡的軟體，因此當機和強制重開機的情況很少發生。

為什麼不用雲端運算？

雲端伺服器也能達到同樣的功能，還能省去（有趣的！）自行維護硬體的麻煩，但成本高得讓人卻步。以與我的 Homelab 伺服器相近的 VM 資源來說，AWS EC2 執行個體每年要花超過 6,000 美元：

我當然可以透過按需開關雲端執行個體來大幅降低成本，但那會為我的工作流程帶來阻礙。有了本地的 VM 伺服器，我可以隨時讓 10 到 20 台 VM 保持可用、隨開即用，而不必擔心斤斤計較成本。

從過去的錯誤中學習

我 2017 年組的那台伺服器表現不錯，但在用了三年之後，我發現有幾個關鍵地方亟需改進。

1. 讓儲存空間留在本地

我的 Synology NAS 有 10.9 TB 的儲存容量。既然有這麼多網路儲存空間，我當時想：「何不在伺服器上只放剛好能啟動主機作業系統的最低限度磁碟空間就好？」

結果證明這是個蠢主意。

首先，在網路儲存空間上跑 VM，會讓 VM 完全依賴磁碟伺服器。Synology 每隔幾個月就會發布作業系統更新，而且每次修補程式都需要重新開機。由於我的 VM 都跑在 Synology 的儲存空間上，每次要套用 Synology 的更新前，我都得先關掉整批 VM。這跟我在 Windows 桌機上跑 VM 時遇到的重新開機問題如出一轍。

其次，透過網路進行隨機磁碟存取速度很慢。在我第一次組裝時，大部分開發工作是後端的 Python 和 Go 應用程式，並不會產生大量的磁碟 I/O。但後來我擴展到前端網頁開發。現代的網頁框架都使用 Node.js，因此每個專案的相依套件樹中都有 1 萬到 20 萬個零散的 JavaScript 檔案。Node.js 的建置過程涉及大量隨機磁碟存取，對網路儲存空間來說是最糟的情況。

2. 選擇更好的 VM 管理軟體

對於第一台伺服器，我評估了兩種 VM 管理方案：Kimchi 和 VMware ESXi。VMware 遠比 Kimchi 精緻、成熟，但 Kimchi 那種拚勁十足的開源精神吸引了我。

幾乎就在我安裝完之後，Kimchi 的開發就停擺了。

隨著時間推移，Kimchi 的缺點越來越明顯。我常常得對 VM 的「clone」或「shutdown」按鈕點好幾次，它才會有反應。還有一些令人抓狂的介面錯誤，按鈕會在我點擊前一刻突然消失或移位。

3. 為遠端管理做好規劃

如果你讀到這裡心想：「Kimchi 不過就是軟體而已。為什麼麥可（Michael）為了換一套不同的 VM 管理程式，就得重組一整台伺服器？」那是因為我當初沒預料到遠端管理的重要性。

我的 VM 伺服器其實就是一台放在辦公室角落、沒有接螢幕或鍵盤的 PC。99% 的時間這樣都沒問題，因為我可以透過 SSH 或網頁介面連線。但剩下 1% 的情況——像是伺服器無法開機，或我想安裝新的主機作業系統——就非常痛苦。我得把伺服器拖到桌邊，拔掉桌機的鍵盤和螢幕，修好需要修的地方，然後再把辦公室的一切恢復原狀。

對於下一台組裝，我想要一個虛擬主控台，能在機器一開機就提供如同實體接觸般的存取能力。我想到的是類似Dell 的 iDRAC或HP 的 iLO這類的方案。

挑選零組件

CPU

我第一台 VM 伺服器的 CPU 是Ryzen 7 1700。它有八核心、十六執行緒，在當時是最熱門的新款 CPU。但當我在/r/homelab（Reddit 上的 Homelab 子社群）上炫耀我的組裝時，他們嘲笑我是個用消費級零件的菜鳥，因為厲害的玩家都用企業級設備。

為了不再被 /r/homelab 嘲笑，我決定踏入企業級伺服器硬體的世界。我甚至還更講究地選擇組一台有兩顆實體 CPU 的系統。

為了讓每一分錢都發揮最大效能，我把搜尋範圍限縮在四到八年前發布的二手 CPU。對於每個候選型號，我都會在 PassMark 上查詢效能分數，然後在 eBay 上查看該型號二手的近期成交價。

最具成本效益的效能似乎落在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 的餘裕，似乎是個划算的價格。

對我來說另一個重要的特色是半模組化線材。在上一台組裝中，我犯了使用非模組化線材的錯誤，代表所有電源線都會永久固定在電源上。我的伺服器內部零件本來就很少，多餘的電源線只會造成雜亂。有了半模組化線材，我可以把不用的線材從電源上移除，讓內部保持整潔。

風扇

雙 CPU 的組裝讓散熱成了意料之外的挑戰。MBD-X10DAL 在兩個 CPU 插槽之間沒留下太多空間，所以我仔細尋找夠薄、能並排安裝的風扇。一對Cooler Master Hyper 212正好符合需求。

機殼

我的伺服器低調地放在辦公室角落，所以我不想要有透明側板或炫目燈光的機殼。

Fractal Design Meshify C Black評價不錯，看起來是個簡約、安靜的機殼。

顯示卡

對於無頭伺服器來說，顯示卡沒那麼重要。但在初次安裝和偶爾除錯時，還是需要它來顯示畫面，所以我選了MSI GeForce GT 710作為便宜又方便的選擇。

遠端管理

我研究了遠端管理解決方案，結果被它們的價格嚇了一跳。起初我想用 Dell iDRAC，但遠端主控台需要300 美元的企業授權，而且會限制我只能使用 Dell 的零組件。我也看了 KVM over IP 的解決方案，但那些更貴，價格從 600 到 1,000 美元不等。

為了實現遠端管理，我採取了一個不尋常的做法：用 Raspberry Pi 自製 KVM over IP 裝置。我把它叫做TinyPilot。

TinyPilot 會擷取 HDMI 輸出，並從瀏覽器轉送鍵盤和滑鼠輸入。它提供的存取體驗，就跟你實際接上鍵盤、滑鼠和螢幕一模一樣。這個軟體是開源的，我也有提供現成的成品供人購買。

我的 2020 年伺服器組裝

VM 管理：Proxmox

我使用Proxmox VE來管理我的 VM。

在上一台組裝被 Kimchi 雷過之後，我不太願意再嘗試另一個免費方案。Proxmox已經存在 12 年了，所以我覺得它是個相對安全的選擇。就介面而言，它比 Kimchi 好上一大截，但在精緻度上仍落後於 ESXi。

我最欣賞 Proxmox 的地方是它的可程式化能力。我常做的其中一項工作是從範本建立新的 VM，然後用Ansible安裝額外的軟體。在 ESXi 上，我找不到不用每次都在網頁介面上手動點擊按鈕就能完成這件事的方法。而 Proxmox 的CLI非常強大，讓我可以把流程寫成腳本，只要執行 ./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，但平行化程度很差。我的舊伺服器 CPU 核心較少，但每個核心更快。如果建置過程只限於五、六個執行緒，就無法發揮新伺服器 48 核心的優勢。

訓練新的 Zestful 模型

Zestful是我那套以機器學習為基礎、用於解析食譜食材的 API。每隔幾個月，我就會用新的資料來訓練它。這是我最耗 CPU 的工作流程，所以我很想看看新系統的表現如何。

終於有個能讓我的 48 核心大顯身手的案例了！新伺服器遠遠勝過舊的，訓練模型的時間縮短到不到一半。可惜，這是我一年只會跑幾次的工作流程。

心得反思

使用消費級硬體並不丟臉

儘管 /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 CPU 我絕對是用得太過頭了。

在一年的使用中，我從未達到 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——依然很棒

我依然很喜歡用 Proxmox 作為 VM 管理工具。我購買了授權，雖然不確定它是否有增加我會用到的新功能，但我很樂意支持這個專案。

令人困擾的是，授權是依 CPU 計價的，所以除了為買了過多 CPU 感到懊惱之外，我還得為 Proxmox 付兩倍的費用。

零件清單（截至 2021-12-05）

* 於原始組裝一年後購入。