Reference architectures · Gitlab 中文文檔

# Reference architectures > 原文：[https://docs.gitlab.com/ee/administration/reference_architectures/](https://docs.gitlab.com/ee/administration/reference_architectures/) * [Available reference architectures](#available-reference-architectures) * [Availability Components](#availability-components) * [Automated backups](#automated-backups-core-only) * [Traffic load balancer](#traffic-load-balancer-starter-only) * [Zero downtime updates](#zero-downtime-updates-starter-only) * [Automated database failover](#automated-database-failover-premium-only) * [Instance level replication with GitLab Geo](#instance-level-replication-with-gitlab-geo-premium-only) * [Configure GitLab to scale](#configure-gitlab-to-scale) * [Configuring select components with Cloud Native Helm](#configuring-select-components-with-cloud-native-helm) * [Footnotes](#footnotes) # Reference architectures[](#reference-architectures "Permalink") 您可以在單個服務器上設置 GitLab 或擴展它以服務許多用戶. 本頁詳細介紹了由 GitLab 的質量和支持團隊構建和驗證的推薦參考架構. 下面的圖表表示每個體系結構層及其可處理的用戶數量. 隨著用戶數量的增長，建議您相應地調整 GitLab. [![Reference Architectures](https://img.kancloud.cn/76/14/7614aed6e90670d53373ab919c1a64cb_893x540.png)](img/reference-architectures.png) 這些參考架構的測試是使用[GitLab 的 Performance Tool](https://gitlab.com/gitlab-org/quality/performance)在特定的編碼工作負載下進行的，用于測試的吞吐量是根據樣本客戶數據計算得出的. 選擇適合您規模的參考架構后，請參考將[GitLab 配置為可縮放](#configure-gitlab-to-scale)以查看所涉及的組件以及如何配置它們. 每 1000 個用戶使用以下每秒請求數（RPS）測試每種端點類型： * API：20 RPS * 網絡：2 RPS * 轉到：2 RPS 對于用戶數少于 2,000 的 GitLab 實例，建議您通過在單個計算機上[安裝 GitLab](../../install/README.html)來使用[默認設置](#automated-backups-core-only) ，以最大程度地減少維護和資源成本. 如果您的組織有 2000 多名用戶，則建議將 GitLab 的組件擴展到多個機器節點. 機器節點按組件分組. 這些節點的增加提高了您的 GitLab 實例的性能和可伸縮性. 擴展 GitLab 時，需要考慮以下幾個因素： * 多個應用程序節點來處理前端流量. * 前面添加了一個負載均衡器，以在應用程序節點之間分配流量. * 應用程序節點連接到共享文件服務器以及后端的 PostgreSQL 和 Redis 服務. **注意：**根據您的工作流程，以下建議的參考體系結構可能需要進行相應的調整. 您的工作負載受以下因素影響，這些因素包括用戶的活躍程度，使用的自動化程度，鏡像和存儲庫/更改大小. 此外，顯示的內存值由[GCP 機器類型提供](https://cloud.google.com/compute/docs/machine-types) . 對于不同的云供應商，請嘗試選擇最匹配所提供架構的選項. ## Available reference architectures[](#available-reference-architectures "Permalink") 提供以下參考體系結構： * [Up to 1,000 users](1k_users.html) * [Up to 2,000 users](2k_users.html) * [Up to 3,000 users](3k_users.html) * [Up to 5,000 users](5k_users.html) * [Up to 10,000 users](10k_users.html) * [Up to 25,000 users](25k_users.html) * [Up to 50,000 users](50k_users.html) ## Availability Components[](#availability-components "Permalink") GitLab 隨附以下組件供您使用，從最小到最復雜列出： 1. [Automated backups](#automated-backups-core-only) 2. [Traffic load balancer](#traffic-load-balancer-starter-only) 3. [Zero downtime updates](#zero-downtime-updates-starter-only) 4. [Automated database failover](#automated-database-failover-premium-only) 5. [Instance level replication with GitLab Geo](#instance-level-replication-with-gitlab-geo-premium-only) 在實現這些組件時，請從單個服務器開始，然后再進行備份. 僅在完成第一臺服務器后，才可以繼續執行下一個. 此外，不為 GitLab 實施額外的服務器并不一定意味著您將有更多的停機時間. 根據您的需求和經驗水平，單個服務器可以為用戶帶來更多實際的正常運行時間. ### Automated backups[](#automated-backups-core-only "Permalink") > * 復雜程度： **低** > * 必需的領域知識：PostgreSQL，GitLab 配置，Git > * 支持的級別： [GitLab Core，Starter，Premium 和 Ultimate](https://about.gitlab.com/pricing/) 該解決方案適用于具有默認 GitLab 安裝的許多團隊. 通過自動備份 GitLab 存儲庫，配置和數據庫，如果您沒有嚴格的要求，這可能是最佳的解決方案. [自動備份](../../raketasks/backup_restore.html#configuring-cron-to-make-daily-backups)的設置最簡單. 這提供了預定時間表的時間點恢復. ### Traffic load balancer[](#traffic-load-balancer-starter-only "Permalink") > * 復雜程度： **中** > * 必需的領域知識：HAProxy，共享存儲，分布式系統 > * 支持的級別： [GitLab Starter，Premium 和 Ultimate](https://about.gitlab.com/pricing/) 這需要使用添加的[負載平衡器](../high_availability/load_balancer.html)將 GitLab 分離為多個應用程序節點. 負載平衡器將在 GitLab 應用程序節點之間分配流量. 同時，每個應用程序節點都連接到后端的共享文件服務器和數據庫系統. 這樣，如果其中一臺應用程序服務器發生故障，則工作流不會中斷. 建議使用[HAProxy](https://www.haproxy.org/)作為負載平衡器. 與默認安裝相比，有了此添加的組件，您具有許多優點： * 增加用戶數量. * 啟用零停機時間升級. * 提高可用性. ### Zero downtime updates[](#zero-downtime-updates-starter-only "Permalink") > * 復雜程度： **中** > * 必需的領域知識：PostgreSQL，HAProxy，共享存儲，分布式系統 > * 支持的級別： [GitLab Starter，Premium 和 Ultimate](https://about.gitlab.com/pricing/) GitLab 支持[零停機時間更新](https://docs.gitlab.com/omnibus/update/) . 盡管您可以使用單個 GitLab 節點執行零停機時間更新，但是建議將 GitLab 分為幾個應用程序節點. 只要每個組件中的至少一個在線且能夠處理實例的使用負載，您的團隊的生產力就不會在更新期間被打斷. ### Automated database failover[](#automated-database-failover-premium-only "Permalink") > * 復雜程度： **高** > * 必需的領域知識：PgBouncer，Repmgr 或 Patroni，共享存儲，分布式系統 > * 支持的級別： [GitLab Premium 和 Ultimate](https://about.gitlab.com/pricing/) 通過為數據庫系統添加自動故障轉移，可以通過其他數據庫節點來提高正常運行時間. 這將使用群集管理和故障轉移策略擴展默認數據庫. [建議將 PgBouncer 與 Repmgr 或 Patroni 結合使用](../postgresql/replication_and_failover.html) . ### Instance level replication with GitLab Geo[](#instance-level-replication-with-gitlab-geo-premium-only "Permalink") > * 復雜程度： **很高** > * 必需的域知識：存儲復制 > * 支持的級別： [GitLab Premium 和 Ultimate](https://about.gitlab.com/pricing/) [GitLab Geo](../geo/replication/index.html)允許您將 GitLab 實例復制到其他地理位置，作為只讀的完全可操作實例，如果發生災難，也可以升級它. ## Configure GitLab to scale[](#configure-gitlab-to-scale "Permalink") **Note:** From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0, support for NFS for Git repositories is scheduled to be removed. Upgrade to [Gitaly Cluster](../gitaly/praefect.html) as soon as possible. 以下組件是您需要配置以擴展 GitLab 的組件. 如果您選擇的[參考體系結構](#reference-architectures)要求它們，則按照通常配置它們的順序列出它們. 它們大多數捆綁在 GitLab deb / rpm 軟件包（稱為 Omnibus GitLab）中，但是根據您的系統架構，您可能需要其中未包含的某些組件. 如果需要，應在設置 GitLab 提供的組件之前對其進行配置. 配置說明列中提供了有關如何為您的組織選擇正確的解決方案的建議. | Component | Description | 配置說明 | 與 Omnibus GitLab 捆綁在一起 | | --- | --- | --- | --- | | 負載均衡器（ [6](#footnotes) ） | 處理負載平衡，通常在您有多個 GitLab 應用程序服務節點時 | [Load balancer configuration](../high_availability/load_balancer.html) ([6](#footnotes)) | No | | 對象存儲服務（ [4](#footnotes) ） | 推薦的共享數據對象存儲 | [Object Storage configuration](../object_storage.html) | No | | NFS（ [5](#footnotes) ）（ [7](#footnotes) ） | 共享磁盤存儲服務. 可以用作備用對象存儲. GitLab 頁面必需 | [NFS configuration](../high_availability/nfs.html) | No | | [Consul](../../development/architecture.html#consul) ([3](#footnotes)) | Service discovery and health checks/failover | [Consul configuration](../high_availability/consul.html) | Yes | | [PostgreSQL](../../development/architecture.html#postgresql) | Database | [PostgreSQL configuration](https://docs.gitlab.com/omnibus/settings/database.html) | Yes | | [PgBouncer](../../development/architecture.html#pgbouncer) | 數據庫連接池 | [PgBouncer configuration](../high_availability/pgbouncer.html#running-pgbouncer-as-part-of-a-non-ha-gitlab-installation) | Yes | | Repmgr | PostgreSQL 集群管理和故障轉移 | [PostgreSQL and Repmgr configuration](../postgresql/replication_and_failover.html) | Yes | | Patroni | 替代的 PostgreSQL 集群管理和故障轉移 | [PostgreSQL and Patroni configuration](../postgresql/replication_and_failover.html#patroni) | Yes | | [Redis](../../development/architecture.html#redis) ([3](#footnotes)) | 鍵/值存儲，用于快速查找和緩存數據 | [Redis configuration](../high_availability/redis.html) | Yes | | Redis 前哨 | Redis | [Redis Sentinel configuration](../high_availability/redis.html) | Yes | | [吉塔利](../../development/architecture.html#gitaly) （ [2](#footnotes) ）（ [7](#footnotes) ） | 提供對 Git 存儲庫的訪問 | [Gitaly configuration](../gitaly/index.html#run-gitaly-on-its-own-server) | Yes | | [Sidekiq](../../development/architecture.html#sidekiq) | 異步/后臺作業 | [Sidekiq configuration](../high_availability/sidekiq.html) | Yes | | [GitLab application services](../../development/architecture.html#unicorn)([1](#footnotes)) | Puma / Unicorn，Workhorse，GitLab Shell-服務于前端請求（UI，API，基于 HTTP / SSH 的 Git） | [GitLab app scaling configuration](../high_availability/gitlab.html) | Yes | | [Prometheus](../../development/architecture.html#prometheus) and [Grafana](../../development/architecture.html#grafana) | GitLab 環境監控 | [Monitoring node for scaling](../high_availability/monitoring_node.html) | Yes | ### Configuring select components with Cloud Native Helm[](#configuring-select-components-with-cloud-native-helm "Permalink") 我們還提供[Helm 圖表](https://docs.gitlab.com/charts/)作為 GitLab 的 Cloud Native 安裝方法. 對于參考體系結構，如果需要，可以以這種方式設置選擇組件. 對于此類設置，我們支持在[高級配置](https://docs.gitlab.com/charts/)中使用圖表，在這些[高級配置中](https://docs.gitlab.com/charts/) ，有狀態后端組件（例如數據庫或 Gitaly）可通過 Omnibus 或信譽良好的第三方服務在外部運行. 請注意，我們目前不支持通過 Helm *大規模*運行有狀態組件. 設計這些環境時，應[參考](#available-reference-architectures)上面的相應[參考體系結構](#available-reference-architectures)以獲取有關大小調整的指導. 通過 Helm 運行的組件將按類似比例縮放到其 Omnibus 規格，僅轉換為 Kubernetes 資源. 例如，如果您要設置一個 50k 的安裝，并且 Rails 節點在 Helm 中運行，那么應該為 Kubernetes 集群提供與 Omnibus 相同數量的資源，并且將 Rails 節點分解為多個較小的 Pod 跨集群. ## Footnotes[](#footnotes "Permalink") 1. 在我們的體系結構中，我們使用 Puma Web 服務器運行每個 GitLab Rails 節點，并將其工作程序數量設置為 90％的可用 CPU 以及四個線程. 對于運行帶有其他組件的 Rails 的節點，應該相應地降低 worker 的值，我們發現 50％達到了很好的平衡，但這取決于工作量. 2. Gitaly 節點的要求取決于客戶數據，特別是項目數量及其規模. 我們建議每個 Gitaly 節點應存儲不超過 5TB 的數據，并且將[`gitaly-ruby`工作者](../gitaly/index.html#gitaly-ruby)的數量設置為可用 CPU 的 20％. 根據以上建議，應結合其他節點并結合對預期數據大小和分布的審查. 3. 推薦的 Redis 設置因架構的大小而異. 對于較小的體系結構（少于 3000 個用戶），一個實例就足夠了. 對于中型安裝（3,000-5,000），我們建議為所有課程使用一個 Redis 集群，并且 Redis Sentinel 與 Consul 一起托管. 對于較大的體系結構（10,000 個或更多用戶），我們建議分別為 Cache 類和隊列和 Shared State 類運行一個單獨的[Redis 群集](../redis/replication_and_failover.html#running-multiple-redis-clusters) . 我們還建議您為每個 Redis 群集分別運行 Redis Sentinel 群集. 4. 對于 LFS，Uploads，Artifacts 等數據對象.由于性能更好，我們建議盡可能在 NFS 上使用[對象存儲服務](../object_storage.html) . 5. NFS 可以用作對象存儲的替代方法，但是出于性能考慮，通常不建議使用 NFS. 請注意，但是[GitLab Pages](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/196)是必需的. 6. 我們的架構已通過[HAProxy](https://www.haproxy.org/)作為負載均衡器進行了測試和驗證. 盡管也可以使用具有類似功能集的其他負載均衡器，但這些負載均衡器尚未經過驗證. 7. 我們強烈建議為任何 Gitaly 或 NFS 節點設置 HDD 之上的 SSD 磁盤，其讀操作的吞吐量至少為 8000 IOPS，寫操作的吞吐量至少為 2,000 IOPS，因為這些組件的 I / O 繁重. 這些 IOPS 值僅建議作為啟動器使用，因為隨著時間的推移，它們可能會根據環境工作負載的規模而調整得更高或更低. 如果您正在 Cloud provider 上運行環境，則可能需要參考其文檔以了解如何正確配置 IOPS. 8. 這些架構是使用 GCP 上的[Intel Xeon E5 v3（Haswell）](https://cloud.google.com/compute/docs/cpu-platforms) CPU 平臺構建和測試的. 在不同的硬件上，您可能會發現需要對 CPU 或節點數進行相應的調整，無論是較低還是較高. 有關更多信息，請在[此處](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks)找到 CPU 的[Sysbench](https://github.com/akopytov/sysbench)基準.