Gitaly Cluster (Praefect)

Gitaly Cluster (Praefect)를 사용하여 Git 스토리지의 내결함성 및 확장성을 높이는 방법을 설명합니다.

- Tier: Free, Premium, Ultimate - Offering: GitLab Self-Managed GitLab에서 Git 스토리지는 Gitaly 서비스를 통해 제공되며, GitLab 운영에 필수적입니다. 사용자, 리포지터리, 활동이 증가함에 따라 Gitaly를 적절히 확장하는 것이 중요합니다: 리소스 고갈로 인해 Git, Gitaly, GitLab 애플리케이션 성능이 저하되기 전에 Git에 사용 가능한 CPU와 메모리 리소스를 늘립니다. 스토리지 한도에 도달하여 쓰기 작업이 실패하기 전에 사용 가능한 스토리지를 늘립니다. 서비스 저하로 인해 프로덕션에 변경 사항을 배포할 수 없게 되는 경우 Git을 미션 크리티컬로 간주하여 단일 장애 지점을 제거하고 내결함성을 개선합니다. Gitaly는 클러스터 구성으로 실행하여 다음을 달성할 수 있습니다: Gitaly 서비스 확장. 내결함성 향상. 이 구성에서는 모든 Git 리포지터리를 클러스터의 여러 Gitaly 노드에 저장할 수 있습니다. Gitaly Cluster (Praefect)를 사용하면 다음과 같은 방법으로 내결함성이 향상됩니다: 웜 스탠바이 Gitaly 노드에 쓰기 작업을 복제합니다. Gitaly 노드 오류를 감지합니다. 사용 가능한 Gitaly 노드로 Git 요청을 자동으로 라우팅합니다. Gitaly Cluster (Praefect)에 대한 기술 지원은 GitLab Premium 및 Ultimate 고객으로 제한됩니다. 다음은 Gitaly Cluster (Praefect)가 제공하는 가상 스토리지인 storage-1 에 액세스하도록 설정된 GitLab을 보여줍니다: [ ](/19.1/administration/gitaly/praefect/img/cluster_example_v13_3.png) 이 예시에서: 리포지터리는 storage-1 이라는 가상 스토리지에 저장됩니다. 세 개의 Gitaly 노드가 storage-1 액세스를 제공합니다: gitaly-1 , gitaly-2 , gitaly-3 . 세 개의 Gitaly 노드가 세 개의 별도 해시 스토리지 위치에 데이터를 공유합니다. 복제 인수 는 3 입니다. 각 리포지터리의 복사본 3개가 유지됩니다. 단일 노드 장애를 가정한 Gitaly Cluster (Praefect)의 가용성 목표는 다음과 같습니다: 복구 시점 목표(RPO): 1분 미만. 쓰기는 비동기적으로 복제됩니다. 새로 승격된 기본 노드로 복제되지 않은 쓰기는 손실됩니다. 장애가 발생한 노드에서 진행 중이던 읽기 작업은 종료됩니다. 강력한 일관성 은 일부 상황에서 손실을 방지합니다. 복구 시간 목표(RTO): 10초 미만. 각 Praefect 노드가 매초 실행하는 상태 확인으로 중단을 감지합니다. 페일오버는 각 Praefect 노드에서 연속으로 10번의 상태 확인이 실패해야 합니다. RPO 및 RTO 개선 사항은 에픽 8903 에서 제안되고 있습니다. 전체 클러스터 장애가 발생하면 재해 복구 계획을 실행해야 합니다. 이는 앞서 설명한 RPO 및 RTO에 영향을 줄