Gitlab堅持用雲的原因

2016 年底我們曾說自己要停用雲服務，轉為使用裸機硬體，並分享了我們有關硬體的提議。2016 年 12 月，在接到數百條提供建議和提醒的評論與郵件後，Sid 和他的團隊決定繼續在雲中執行 GitLab.com。

本文總結了社群成員發給我們的一些支援和反饋，文末我們還總結了通過雲環境讓 GitLab.com 變的更加快速可靠的計劃。我們的決策依據並非僅基於下文列出的原因，不過其中一些有趣的資訊還是有必要總結並共享給大家。

我在 Koding 就職時，曾做過類似的事情，從 AWS 遷移為裸機硬體執行。成本變化非常驚人。使用 AWS 時每月 20 萬美元的成本被縮減至大約 2 萬美元。因此很長時間以來我一直在堅持說，一旦達到某一程度的規模，AWS 將不再是最合理的選擇。Geraint – GitLab blog: Going bare metal

過去十幾年來，我們在紐約市託管了 140 臺左右的伺服器，託管成本與日俱增，並且我們簽署的合約不夠靈活，無法按照需求隨時增添機櫃。此時我們基本上只能取消之前的合約，簽署新的合約，支付升級費用，支付機櫃的安裝等費用…… 終於等到某一天，我們已經無力承擔每月 1.4 萬美元的託管費用，因此決定將所有伺服器從紐約市遷移至愛沙尼亞首都塔林，我們在那裡自行構建了一個專用的小型資料中心。藉此我們的託管費用降低了 10 倍。

成本不僅僅體現在硬體的擁有和更新方面，還體現在伴隨硬體的方方面面。

成本不僅僅體現在硬體的擁有和更新方面，還體現在伴隨硬體的方方面面。網路的設計，效能調優，以及一切東西的除錯。突然你就會開始遇到容量不足的問題，你可能並沒有已經準備好，隨時可以投入使用的 100 臺備用伺服器，或者無法在 2 分鐘裡將這些伺服器順利投入使用，這時你打算怎麼辦？自動縮放？

相比雲服務或邏輯硬體部署之爭，應用程式的架構其實更重要。遇到這種問題後，簡單直接地丟擲更多裸機硬體，這樣的做法比使用雲例項更簡單，也更具成本效益。因此在某些情況下，裸機硬體比雲服務更適合。

轉為使用自己專用的硬體，無疑有助於改善效能，縮短偶發的停機時間，並大幅降低成本。就算考慮到僱傭更多工程師的成本，相比使用雲服務，改為使用裸機硬體後的前 24 個月，通常也可以實現 40%-50% 的成本節約。如果硬體的生命週期是 36-48 個月，那麼 24 個月後還能節約更多成本。

我覺得他們可能低估了 GitLab 長期執行的成本。當他們意識到必須僱傭一個一年 365 天，一天 24 小時隨時待命，在故障後 30 分鐘內抵達資料中心的人；當他們意識到必須準備多少備用的硬體裝置……

雲服務供應商最大的責任是保障客戶內容的安全性、永續性、可用性，以及效能（優先順序逐級遞減）。大傢伙嚴重低估了要實現前三點所涉及的複雜性。

Google 內部很少有團隊使用專用的物理機。而真正這樣做的團隊無論在基礎架構的規模和團隊的規模方面都是極為龐大的。我並不是說就必須只能用雲服務，我反覆重申的一點是：至少你需要確定自己真的需要這樣做。

推行自有系統的公司無須使用共享的資源，而且可以結合自己的獨特需求對整個系統進行有針對性的優化。

然而作為雲供應商，需要通過共享的資源為一群客戶提供服務。推行自有系統的公司無須使用這種共享的資源，而且可以結合自己的獨特需求對整個系統進行有針對性的優化。

我認為，面對硬體故障的彈性和恢復能力，以及遷移和多資料中心高可用性將成為最關鍵的問題。從雲服務切換至裸機硬體部署，確實能獲得更高效能和更簡化的系統，但面對網路中斷和硬體故障，可考慮的選擇變少了。

似乎他們一開始並非面向雲服務設計的，現在開始承受後果了。相比自有資料中心，選擇雲服務需要作出不同的取捨，也會遇到不同的效能問題。如果打算這樣做，其實也挺好。藉此可以獲得一套更穩定的軟體環境。但如果對資料中心的各種特徵採取想當然的態度，遲早還會遇到別的問題。

對於 GitLab.com 來說，在大規模環境裡“吃自己的狗食”是種很合理的做法。

對於 GitLab.com 來說，在大規模環境裡“吃自己的狗食”是種很合理的做法。這樣的話，如果他們自己的客戶在自己的本地部署環境中遇到效能問題，他們就沒法簡單地說：GitLab.com 使用了和你們完全不同的架構，所以你們只能自己想辦法解決了。客戶往往希望 GitLab.com 本身的系統能夠和標準產品儘可能一致。

他們因為效能的元怒因從雲服務轉為使用裸機硬體，而他們自己也在使用很多眾所周知非常緩慢並且糟糕的軟體。如果是我本人打算作出如此重大的改動，肯定會先對整個棧進行優化。構建自己的硬體設施無法直接獲得業務價值，並且整個過程極易出錯（切身經驗和感受）。

別亂折騰儲存了。 32 臺檔案伺服器總容量才 96TB？網路 Re:ceph 也是類似的情況。你的故障域在哪裡？為了確保這一切正常運轉需要指派的全職員工會產生多少成本？

我覺得切換到這種硬體後，IOPS 指標肯定會大幅下降。你們基本上是在一個 CephFS 群集中用了大約 60 個 7200 RPM 轉速的硬碟。自己算算吧，如果假設每塊硬碟可實現 100 個讀取和 100 個寫入的 IOPS 操作，寫入方面還會產生 3 倍的複製操作（外加日誌寫入），舉例你們的目標肯定差得很遠。

我不禁猜測 GitLab 的工作負載大部分都是隨機的，對於大容量硬碟這會造成一個問題。SSD 是個不錯的選擇，但在這樣一種 2-3 層的設計中，我只看到他們使用了 8TB 容量的硬碟，每一層都使用了 8TB 的硬碟。我也不太確定，為單塊 8TB 容量硬碟組成的 24TB 儲存使用一塊 SSD 作為快取能起到多大的效果。

如果追求效能，別使用 8TB 容量的硬碟。根據我的經驗，容量超過 5TB 的硬碟響應時間都不怎麼理想。我沒有很具體的資料，但我分別用單塊 5TB 和單塊 2TB 的硬碟組建過 10 盤 RAID6 陣列，2TB 硬碟的陣列響應速度明顯更快。

就提幾個簡單的意見。我曾遇到過約 300TB 的 Ceph 儲存不可用的情況。絕對不要用 8TB 硬碟。為什麼要使用這麼臃腫的東西？老實說這樣做有什麼好處嗎？你們需要的是更多數量的硬碟，對處理器核心和記憶體的要求反而沒有那麼高。按照目前的配置，每個機架單元能實現多大的容量？

別亂折騰網路了。 在你們那種超級微型的軟體定義網路中，你們具備運營相同或類似工作負載的經驗嗎？當你凌晨兩點給 CEO 打電話時，他會接嗎？

我絕不會用 10GBase-T，因為這是為桌面使用設計的。我建議最好能用 25G SFP28（AOC-MH25G-m2S2TM），不過 10G SFP+（AOC-MTG-i4S）也行。交換機的速度和型別必須與網路卡匹配（你們連線到的 SFP+ 交換機跟你們提議使用的 10GBase-T 網路卡並不相容）。

雖然沒見到有人提過，但你們的網路策略有何規劃？是否要執行 IPv4/IPv6 雙棧？僅 IPv4？僅內部 IPv6 同時對外使用 NAT64？希望 IPv6 能在你們的網路棧中佔據一席之地。重量級選手都還沒用 IPv6，讓人有些難過。

別掉進將 VLAN 擴充套件得到處都是這樣的陷阱中。你們絕對會需要在不同路由器之間路由（而非交換）。

“是否要為 Ceph 流量提供專用網路？”當然，如果你希望重建的過程中整個 Ceph 群集能繼續保持可用狀態的話。在任何型別的重建操作中，Ceph 會全面跑滿整個內部網路。

我領導的技術運維團隊曾將我們的基礎架構從公有云（約 400 個例項）遷移至私有云（約 55 臺物理伺服器），並最終遷移至 Kubernetes（6 臺物理伺服器）。我們其實混合執行了 Kubernetes 和 OpenStack，應用和服務放在 Kubernetes 上，所有資料儲存放在 OpenStack 上。我也對 Ceph 進行了全面的測試，雖然更靈活，但對於資料庫這種用例，將無法達到近似於裸機硬體本地磁碟的 I/O 效能。對於儲存，我覺得越簡單越好。我主要使用經過實踐檢驗的標準檔案系統（ext4 和 ZFS）執行 Linux 作業系統，在軟體層實現冗餘。

我們以前通過裸機硬體執行 Ceph 和 Gluster 時獲得的體驗非常糟糕。我覺得，本質上來說，這也意味著分散式檔案系統在成熟度（以及技術難度）上還不如雲服務那麼完善。

需要明確的是，沒有任何一種架構可以讓你避免執行 CephFS 群集。CephFS 很酷，但目前來說還存在單點故障的可能，並且還有很多需要注意的問題。如果能消除 CephFS 建立的抽象層，讓應用直接處理某種型別的分散式儲存系統任務，效能和穩定性都會大幅提升。

面對有關 Ceph 的炒作，請淡定。Ceph 的優勢在於冗餘和吞吐量，而非 IOPS，Rados IOPS 指標很差。就算在使用 120 塊 SSD 組建的 OSD 群集上，我們也無法獲得超過 60k 隨機讀寫 IOPS 的指標。

如果你在使用 CephFS，而其他所有人都希望使用其他雲端儲存解決方案，這等於在你和你的使用者之間造成了分裂，併為在雲端儲存的縮放方面具備相應工具和經驗的競爭對手製造了可乘之機，他們會趁機搶走你的使用者。

你們的核心能力在於程式碼，而非基礎架構，因此自己團隊和組織內部自行努力構建這一切新能力，最終將產生無法預測的成本。雲和自行部署環境的總體擁有成本分析，並不是簡單地對比託管、硬體，以及設施成本。

你們的核心能力在於程式碼，而非基礎架構。

轉為使用裸機硬體的另一個問題是，你們會失去技術支援。雲供應商有完整的團隊、網路、系統、資料中心等，並且隨時聽候你的調遣，這些服務也已經包含在你支付的費用中。你確定自己能像雲供應商那樣自行進行相同水平的網路和系統問題除錯嗎？這可是個辛苦活。

我覺得你們低估了自行運營一套基礎架構需要的人數。你需要懂得配置網路裝置的人，懂得在資料中心更換故障的網路卡和硬碟的人，擅長管理供應商關係的人，以及知道怎樣進行容量規劃的人。

為何將自己牢牢綁在 Intel 伺服器上？CPU 和記憶體之間的最大頻寬僅為 68GB/s，對於高速資料處理這簡直太恐怖了。IBM 的 POWER8 系統有伺服器能提供 230GB/s 的 CPU 至記憶體頻寬，甚至還有高達 320GB/s 的產品……

…… POWER8 的 CPU 使用了與 Intel 不同的架構：PPC64，因此可能需要重新編譯某些軟體，或者為一些只支援 x86_64 的工作負載保留一些 Intel 系統。

我只自己組裝過臺式電腦，頂上的評論與我組裝臺式電腦的帖子裡的評論情況極為相似。挺不錯的，我相信隨著研究越來越深入，肯定會得出越來越不同的結論，但我本人對組裝伺服器實在沒什麼經驗，但是看到上面也有人提到了能耗和冷卻問題，不知道為啥我竟然覺得挺安心的！

我們希望能智慧地縮放，並且能開發出偉大的軟體；我們並不想轉型成專注於基礎架構的公司。因此最終我們決定繼續擁抱雲服務，藉此解決 GitLab.com 在規模方面遇到的挑戰，對於這個決定我們同樣感到激動，因為只要我們能解決了這個問題，也就等於解決了全球各地在自己的本地環境中使用 GitLab 的企業所面臨的問題。

有關規模的大部分問題主要源自 Git 是一種讀取密集型工作負載：從下方的 Git 讀 / 寫效能圖表中可以看到，大概每 300 個讀取操作才會產生 10 個寫入操作。我們曾試圖通過雲服務中執行的 CephFS 解決這個問題，但這樣的做法違背了我們針對每個問題使用最簡單，最乏味解決方案的價值觀。

平均 300 個讀取只產生了 10 個寫入

• 我們將所有儲存分散到多個 NFS Shard 並從技術棧中取消了 CephFS。
• 我們建立了 Gitaly，這樣在橫向擴充套件過程中可以不再依賴 NFS，並能通過快取加快 Git 訪問速度。

Gitaly 將充當整個技術棧中所有 Git 訪問的單一介面。通過使用 Gitaly，可以通過網路傳輸 gitrpc 並對磁碟進行本地訪問，藉此避免所有磁碟訪問都要通過網路進行。這樣還有助於改善我們對 Git 資源用量的監視，藉此有助於作出更好的決策，不過目前我們尚處在抽樣過程中。

在此我們想感謝社群、客戶、團隊，以及董事會的不懈支援，正因為你們，GitLab 才能成為一個如此出色的產品。