作者：Sean Packham

譯者：大愚若智

Gitlab.com曾計劃從雲服務轉為使用裸機硬體環境，這一決定收到了數百條建議和評論。經過多方考慮，他們決定繼續使用雲服務執行自己的平臺，並決定通過本文將一些有趣的反饋和評論分享給大家。

先從成本這個話題開始吧

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

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

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

相比雲服務或邏輯硬體部署之爭，應用程式的架構其實更重要。遇到這種問題後，簡單直接地丟擲更多裸機硬體，這樣的做法比使用雲實例更簡單，也更具成本效益。因此在某些情況下，裸機硬體比雲服務更適合。mohctp – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13162964

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

我覺得他們可能低估了GitLab長期執行的成本。當他們意識到必須僱傭一個一年365天，一天24小時隨時待命，在故障後30分鐘內抵達資料中心的人；當他們意識到必須準備多少備用的硬體裝置……manacit – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13154057

效能問題該怎麼辦？

雲服務供應商最大的責任是保障客戶內容的安全性、永續性、可用性，以及效能（優先順序逐級遞減）。大傢伙嚴重低估了要實現前三點所涉及的複雜性。mritun – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13155809)

Google內部很少有團隊使用專用的物理機。而真正這樣做的團隊無論在基礎架構的規模和團隊的規模方面都是極為龐大的。我並不是說就必須只能用雲服務，我反覆重申的一點是：至少你需要確定自己真的需要這樣做。boulos – Hacker News: Going bare metal(https://news.ycombinator.com/item?id=12941210)

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

然而作為雲供應商，需要通過共享的資源為一群客戶提供服務。推行自有系統的公司無須使用這種共享的資源，而且可以結合自己的獨特需求對整個系統進行有針對性的優化。taneq – Hacker News: Going bare metal(https://news.ycombinator.com/item?id=12940925)

我認為，面對硬體故障的彈性和恢復能力，以及遷移和多資料中心高可用性將成為最關鍵的問題。從雲服務切換至裸機硬體部署，確實能獲得更高效能和更簡化的系統，但面對網路中斷和硬體故障，可考慮的選擇變少了。wpostma – the GitLab blog: Going bare metal(https://about.gitlab.com/2016/11/10/why-choose-bare-metal/#comment-3001348957)

由於似乎一開始並非面向雲服務設計的，現在開始承受後果了。相比自有資料中心，選擇雲服務需要作出不同的取捨，也會遇到不同的效能問題。如果打算這樣做，其實也挺好。藉此可以獲得一套更穩定的軟體環境。但如果對資料中心的各種特徵採取想當然的態度，遲早還會遇到別的問題。wandernotlost – Hacker News: Going bare metal(https://news.ycombinator.com/item?id=12940082)

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

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

他們因為效能的原因考慮從雲服務轉為使用裸機硬體，但是另一方面而他們自己也在使用很多非常緩慢並且糟糕的軟體。如果打算作出如此重大的改動，務必首先對整個棧進行優化。構建自己的硬體設施無法直接獲得業務價值，並且整個過程極易出錯（切身經驗和感受）。StreamBright – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153866)

針對儲存提議給出的建議

別亂折騰儲存了。 32臺文件伺服器總容量才96TB？網路Re:ceph也是類似的情況。你的故障域在哪裡？為了確保這一切正常運轉需要指派的全職員工會產生多少成本？*Spooky23 – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153860) – Spooky23確實警告過我們“我就是個脾氣古怪的老傢伙”。

有網友提到切換到這種硬體後，IOPS指標肯定會大幅下降。你們基本上是在一個CephFS群集中用了大約60個7200 RPM轉速的硬碟。自己算算吧，如果假設每塊硬碟可實現100個讀取和100個寫入的IOPS操作，寫入方面還會產生3倍的複製操作（外加日誌寫入），舉例你們的目標肯定差得很遠。Nicholas – the GitLab blog: Proposed server purchase(https://about.gitlab.com/2016/12/11/proposed-server-purchase-for-gitlab-com/#comment-3047537669)

有網友猜測GitLab的工作負載大部分都是隨機的，對於大容量硬碟這會造成一個問題。SSD是個不錯的選擇，但在這樣一種2-3層的設計中，只看到他們使用了8TB容量的硬碟，每一層都使用了8TB的硬碟。我也不太確定，為單塊8TB容量硬碟組成的24TB儲存使用一塊SSD作為快取能起到多大的效果。lykron – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153333)

以及我們選擇使用8TB硬碟的決定

如果追求效能，別使用8TB容量的硬碟。根據我的經驗，容量超過5TB的硬碟響應時間都不怎麼理想。我沒有很具體的資料，但我分別用單塊5TB和單塊2TB的硬碟組建過10盤RAID6陣列，2TB硬碟的陣列響應速度明顯更快。lykron – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153196)

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

有關網路提議的反饋

別亂折騰網路了。 在你們那種超級微型的軟體定義網路中，你們具備運營相同或類似工作負載的經驗嗎？當你凌晨兩點給CEO打電話時，他會接嗎？*Spooky23 – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153860)

我絕不會用10GBase-T，因為這是為桌面使用設計的。我建議最好能用25G SFP28（AOC-MH25G-m2S2TM），不過10G SFP+（AOC-MTG-i4S）也行。交換機的速度和型別必須與網絡卡匹配（你們連線到的SFP+交換機跟你們提議使用的10GBase-T網絡卡並不相容）。wmf – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153678)

雖然沒見到有人提過，但你們的網路策略有何規劃？是否要執行IPv4/IPv6雙棧？僅IPv4？僅內部IPv6同時對外使用NAT64？希望IPv6能在你們的網路棧中佔據一席之地。重量級選手都還沒用IPv6，讓人有些難過。tomschlick – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153922)

別掉進將VLAN擴充套件得到處都是這樣的陷阱中。你們絕對會需要在不同路由器之間路由（而非交換）。“是否要為Ceph流量提供專用網路？”當然，如果你希望重建的過程中整個Ceph群集能繼續保持可用狀態的話。在任何型別的重建操作中，Ceph會全面跑滿整個內部網路。devicenull – Hacker News: Proposed server purchase

社群對Ceph的看法如何？

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

我們以前通過裸機硬體執行Ceph和Gluster時獲得的體驗非常糟糕。我覺得，本質上來說，這也意味著分散式檔案系統在成熟度（以及技術難度）上還不如雲服務那麼完善。codinghorror – Hacker News: Going bare metal(https://news.ycombinator.com/item?id=12940042)

需要明確的是，沒有任何一種架構可以讓你避免執行CephFS群集。CephFS很酷，但目前來說還存在單點故障的可能，並且還有很多需要注意的問題。如果能消除CephFS建立的抽象層，讓應用直接處理某種型別的分散式儲存系統任務，效能和穩定性都會大幅提升。Nicholas – GitLab blog: Proposed server purchase(https://about.gitlab.com/2016/12/11/proposed-server-purchase-for-gitlab-com/#comment-3047478761)

面對有關Ceph的炒作，請淡定 – late2part

面對有關Ceph的炒作，請淡定。Ceph的優勢在於冗餘和吞吐量，而非IOPS，Rados IOPS指標很差。就算在使用120塊SSD組建的OSD群集上，我們也無法獲得超過60k隨機讀寫IOPS的指標。late2part – GitLab blog: Proposed server purchase(https://news.ycombinator.com/item?id=13154620)

如果你在使用CephFS，而其他所有人都希望使用其他雲端儲存解決方案，這等於在你和你的使用者之間造成了分裂，併為在雲端儲存的縮放方面具備相應工具和經驗的競爭對手製造了可乘之機，他們會趁機搶走你的使用者。Rapzid – Hacker News: Going bare metal(https://news.ycombinator.com/item?id=12946174)

轉為使用裸機硬體會對GitLab團隊產生哪些影響？

你們的核心能力在於程式碼，而非基礎架構，因此自己團隊和組織內部自行努力構建這一切新能力，最終將產生無法預測的成本。雲和自行部署環境的總體擁有成本分析，並不是簡單地對比託管、硬體，以及設施成本。ninjakeyboard – Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153779)

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

轉為使用裸機硬體的另一個問題是，你們會失去技術支援。雲供應商有完整的團隊、網路、系統、資料中心等，並且隨時聽候你的調遣，這些服務也已經包含在你支付的費用中。你確定自己能像雲供應商那樣自行進行相同水平的網路和系統問題除錯嗎？這可是個辛苦活。l1x – GitLab blog: Proposed server purchase(https://about.gitlab.com/2016/12/11/proposed-server-purchase-for-gitlab-com/#comment-3047353138)

我覺得你們低估了自行運營一套基礎架構需要的人數。你需要懂得配置網路裝置的人，懂得在資料中心更換故障的網絡卡和硬碟的人，擅長管理供應商關係的人，以及知道怎樣進行容量規劃的人。thebyrd-on Hacker News: Proposed server purchase(https://news.ycombinator.com/item?id=13153644)

咱們還是聯手拋棄x86吧

為何將自己牢牢綁在Intel伺服器上？ – MBH

為何將自己牢牢綁在Intel伺服器上？CPU和記憶體之間的最大頻寬僅為68GB/s，對於高速資料處理這簡直太恐怖了。IBM的POWER8系統有伺服器能提供230GB/s的CPU至記憶體頻寬，甚至還有高達320GB/s的產品………… POWER8的CPU使用了與Intel不同的架構：PPC64，因此可能需要重新編譯某些軟體，或者為一些只支援x86_64的工作負載保留一些Intel系統。MBH – GitLab blog: Proposed server purchase(https://about.gitlab.com/2016/12/11/proposed-server-purchase-for-gitlab-com/#comment-3053432409)

我們都有自己的看法

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

我們打算後退一步選擇一種乏味的解決方案

我們希望能智慧地縮放，並且能開發出偉大的軟體；我們並不想轉型成專注於基礎架構的公司。

因此最終我們決定繼續擁抱雲服務，藉此解決GitLab.com在規模方面遇到的挑戰，對於這個決定我們同樣感到激動，因為只要我們能解決了這個問題，也就等於解決了全球各地在自己的本地環境中使用GitLab的企業所面臨的問題。

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

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

如何迴歸根本問題？

1. 我們建立了Gitaly，這樣在橫向擴充套件過程中可以不再依賴NFS，並能通過快取加快Git訪問速度。

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

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

文章來自微信公眾號：高效開發運維