導讀 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 會全面跑滿整個內部網絡。

區對 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 才能成為一個如此出色的產品。

原文來自:http://www.yunweipai.com/archives/18870.html

本文地址:http://www.ouxnnm.live/gitlab-persist-clouds.html編輯員:郭建鵬,審核員:逄增寶

本文原創地址:http://www.ouxnnm.live/gitlab-persist-clouds.html編輯:roc_guo,審核員:暫無