GitLab 的高可用性

什么是高可用性?

高可用性是一個被設計用來確保在一段預定時間內保持預定水平的運行性能. 衡量 HA 的通用方式是使用正常運行時間的概念, 用來測量服務能運行多長時間.

GitLab 提供了一個對大多數組織而言常常很重要的功能: 它能使人們能進行及時的代碼協作. 任何停機時間都是短暫而有計劃的. 幸運的是，GitLab 提供了一個穩定的設置，即使實在一個沒有特別措施的服務器上也能應用. 而由于分布式的天然特性，即使GitLab不能使用，git使用者也仍然能夠提交代碼. 不過，GitLab的一些特性，比如問題追蹤和持續集成在GitLab崩潰的時候還是不能用的.

一定要記住高可用性的解決方案帶來了一個成本/復雜性和正常運行時間之間的權衡。越長的運行時間意味著解決方案越復雜。并且解決方案越復雜，就帶來了更多安裝和維護的工作。高可用性不是免費的，每一個高可用性的方案都要在投資和回報之間權衡。

高可用性對你來說

兩個你要經常問自己的問題：

1. 對于代碼可用性我有什么特殊需求?

2. 我們的團隊能夠處理什么級別的復雜度?

高可用性的方案范圍涵蓋了從廉價的簡單備份到昂貴的master-master配置。 不幸的是，在高可用性這方面還沒有辦法將復雜度的提升和成本的提升分開來。

我們建議你深入的對HA的優勢及其成本進行一下對比分析. 大多數選擇GitLab高可用性方案的組織，都是因為它沒有那些直接產生收入的面向主要客戶的基礎設施那么復雜.  重要的是總是應該選擇你已經嘗試過并定期測試過的那些東西 . 糟糕的HA方案造成的宕機時間比它所解決的要多得多. 例如  DRBD 用戶指南 描述到 : “通過配置自動恢復策略，你可以高效的配置出自動的數據丟失故障!”.  從一個簡單方案逐漸過渡到更加復雜的方案比其它的方式更加符合成本效益. 因此，我們建議你從最簡單的方案開始，逐步選擇最適合你的方案.

成熟度等級

1. 文件和數據庫的備份

自動的對GitLab的資源庫、配置和數據庫進行備份是可能的。你可以使用 GitLab備份任務 來 對備份進行管理: 用 `rake gitlab:backup:create` 創建備份，并用 `rake gitlab:backup:restore` 來進行恢復. 萬一服務器不可用了，備份就可以用來恢復GitLab的安裝. 此方案適用于那些擁有一臺物理服務器的團隊. 我們建議你將備份存儲到一個外部的服務器. 同時我們還建議你將備份任務進行自動化，并對備份過程進行監控.    

2. 從快照進行恢復

可以創建一個工作服務器的快照. 快照是服務器上所有文件的一個副本. 萬一宕機了，就可以手動恢復到最近的可用快照. 如果有第二個位置可用，就有可能自動還原成快照，不需要人來操心.

一般都會用虛擬機來實現; 有許多方案都提供了快照功能. 不過也有肯能使用 XFS 文件系統來實現快照.

從快照恢復比從上面提到的備份恢復要快. 如果使用后者，你就一般要重新安裝GitLab，手動重置所有的定制配置，只有在這些操作之后才能執行 `rake gitlab:backup:restore` 進行操作. 從快照恢復就可以跳過這些額外的人工步驟.

如果你使用快照來將GitLab服務器恢復到另一臺機器上，你應該考慮到IP地址沖突的問題。為了確保每個人都能快速使用新服務器，最常用的是升級 DNS網關。這樣，由于服務器的替換，新機器必須使用新的IP地址，或者，快照應該使用同樣的OpenSSH服務驗證。否則，通過SSH登錄到 GitLab客戶端的用戶會看到“WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED”，因為服務器驗證和GitLab的IP地址不匹配。

這種IP地址不匹配的問題可以使用浮動的IP來解決，浮動IP可以在路由器中進行故障轉移。但是這種方法必須得到路由設備和網絡的支持。如果新地址在一個二級網絡環境，那么，每個地址都需要在同一個網絡，使用同一個核心路由。

使用快照做恢復最適合單臺虛擬服務器。

3. 多應用服務器

將應用服務器, 文件系統和數據庫分開也是可行的. 如果條件允許, 你可以利用負載平衡器, 給多任務應用服務器分配任務.  這樣做的好處是, 當其中一個應用服務器崩潰, 工作流程(workflow )不會因此中斷.  但會因為服務器數量減少, 速度變慢.

配置如下圖所示        

由于本方案需要用到文件共享系統(NFS), 所以, 必須使用 GitLab 6.0 或以上版本, 只有這些版本才將 satellite 放在共享磁盤上. 此外, 你應該將文件存儲和數據庫分開放到不同的服務器上. 而且, 文件存儲和數據庫應該使用各自的恢復協議(如: 快照, 備份).

4. 單個輔助服務器

如果你的方案, 只計劃使用兩臺服務器, 我們建議你把其中一臺設為輔助服務器(Slave Server). 在 這種配置下,  每臺機器都有相同的 GitLab 資源庫, 配置, 和數據庫. 輔助服務器的作用是備份主服務器的文件. 你可以通過分布式復制塊設備(Distributed Replicated Block Device,  DRBD), 確保主服務器上的所有數據, 都及時復制到輔助服務器上.

若要手動故障轉移(Manual failover),  只要掛載(mounting )輔助服務器上的文件存儲器(file storage)就可以. 此時, 輔助服務器會變成主服務器. 注意, 要將故障服務器(unavailable server) 關閉或脫離網絡.  以免它又重新上線, 成為主服務器.

不管主服務器和輔助服務器, 是放在同一個機房, 還是分隔兩地, 這種方式都行得通.

5. 文件存儲和DBMS從服務器

不可能把多個應用服務器的解決方案放在一個從服務器上. 在這種情況下，你需要另外的多個無狀態應用服務器和一個文件存儲，以及DBMS從服務器。

在這種解決方案中， 用戶仍然會通過負載均衡應用服務器連接， 但是文件存儲和DBMS會被從一個數據中心或另一個位置拷貝到一個或多個從服務器中。 分布式復制塊設備（Distributed Replicated Block Device） (DRBD) 可以被用來從主文件存儲和DBMS服務器中傳遞數據到從服務器中。

在GitLab的應用服務器上只有很少的狀態，因此我們不推薦有從應用服務器單邊的文件存儲和DBMS。使用負載均衡的結果有同樣的效果，但是更簡 單。自動化備災可以實現定制化STONITH（Shoot The Other Node In The Head）的網絡管理。準備為傳輸到新的網絡地址，需要保持應用服務器的狀態。 PostgreSQL.在這個解決方案中你可能需要通過一個數據庫特殊協議替換DRBD去同步數據庫，在這篇文檔中你可以找到關于 MySQL 和 PostgreSQL 的相關選項。

6. 集群的/主節點-主節點（master-master） 文件存儲和 DBMS

集群一直是眾所周知的分布式解決方案。GitLab的目的解決一個主節點/主節點解決方案(性能)下降這一類的問題。集群解決方案比主-從解決方案更難安裝和維護。 但是他們可以給故障提供更多的彈性，并且給予你超越單一文件存儲或dbms服務器的能力。

集群模式在這兩種模式（同步和異步）中更有效。一個同步的集群配置需要廣播每一個變更到每一臺服務器，這是一個耗時的處理。 這是同步解決方案中的一個基本缺點， 當這些服務器在地理上接近時，這個方案是可行的。 否則對于終端用戶來說系統就會變得非常慢。

如果以異步的方式通信會大大提高處理速度。但是這樣又可能導致服務器之間的數據不兼容，比如可能會創建兩個擁有相同用戶名的賬戶。GitLab沒有解決這種問題的方法，因此使用異步通信機制對于GitLab來講是行不通的。

文件存儲的HA方案可以選擇使用各種分布式文件系統, 比如GFS2, VMFS 和 Ceph。另外還可以選擇使用一個水平擴展設備，比如IBM的NASA或者EMC Isilon。而DBMS也有諸多選擇：Oracle的MySQL Cluster和PostgreSQL’s clustering solutions。

在不久的將來GitLab可能會開始使用libgit2-backends來存儲數據庫中的Git倉庫。這樣的話一個集群數據庫就能存儲GitLab應用的所有狀態。這使得建立一個集群系統變得很容易。可惜的是libgit2以及它的ruby依賴庫Rugged目前還不能提供GitLab所需要的所有功能。

盡管集群或master/master配置支持暫時還不是GitLab未來計劃的一部分，但也有好消息。不同公司對于HA的需求導致了各種更加簡單和廉價的解決方案。例如:

• 如果你需要寫HA和快速恢復功能，前面任何HA設置都能做到。

• 如果你需要本地克隆大倉庫，可以使用一個針對GitHub的第三方鏡像解決方案，gitlab-mirrors

• 如果你僅僅只需要在不同的地點push到多個GitLab服務器上去，可以使用git remotes。

• 如果你需要讓工作在地球上各個洲的人都能有快速的用戶體驗，可以使用本地git客戶端、命令行、Tower等等。

請與我們聯系

在 GitLab.com 我們很重視提供一個高可用（High Availabily）的安裝（設置）。我們提供在這里的信息僅僅是一個粗略的向導，旨在幫助你感受硬件， 軟件和處理不同的高可用（HA）安裝（設 置）。當涉及到你的具體情況， 我們最好評估它的上下文環境。 我們強烈建議你在設置前與我們聯系。支持HA可以標準訂閱。 如果你有任何問題請發郵件 給我們。