Gitaly 클러스터(Praefect)

Gitaly 클러스터(Praefect)에 대해 설명합니다.

Git 스토리지는 GitLab의 Gitaly 서비스를 통해 제공되며 GitLab 운영에 필수적입니다. 사용자, 저장소, 활동 수가 증가함에 따라 다음을 통해 Gitaly를 적절히 확장하는 것이 중요합니다: 리소스 고갈로 Git, Gitaly, GitLab 애플리케이션 성능이 저하되기 전에 Git에서 사용 가능한 CPU 및 메모리 리소스를 늘립니다. 스토리지 한도에 도달하여 쓰기 작업이 실패하기 전에 사용 가능한 스토리지를 늘립니다. 단일 장애 지점을 제거하여 내결함성을 향상시킵니다. 서비스 저하가 프로덕션에 대한 변경 배포를 방해할 경우 Git은 미션 크리티컬로 간주해야 합니다. Gitaly는 클러스터 구성으로 실행하여 다음을 달성할 수 있습니다: Gitaly 서비스 확장. 내결함성 향상. 이 구성에서 모든 Git 저장소는 클러스터의 여러 Gitaly 노드에 저장될 수 있습니다. Gitaly 클러스터(Praefect)를 사용하면 다음을 통해 내결함성이 향상됩니다: 대기 Gitaly 노드에 쓰기 작업 복제. Gitaly 노드 장애 감지. 사용 가능한 Gitaly 노드로 Git 요청 자동 라우팅. Note Gitaly 클러스터(Praefect)에 대한 기술 지원은 GitLab Premium 및 Ultimate 고객으로 제한됩니다. 다음은 Gitaly 클러스터(Praefect)에서 제공하는 가상 스토리지인 storage-1 에 액세스하도록 설정된 GitLab을 보여줍니다: 이 예시에서: 저장소는 storage-1 이라는 가상 스토리지에 저장됩니다. 세 개의 Gitaly 노드가 storage-1 액세스를 제공합니다: gitaly-1 , gitaly-2 , gitaly-3 . 세 개의 Gitaly 노드는 세 개의 개별 해시 스토리지 위치에서 데이터를 공유합니다. 복제 계수 는 3 입니다. 각 저장소의 복사본이 세 개 유지됩니다. 단일 노드 장애를 가정한 Gitaly 클러스터(Praefect)의 가용성 목표는: 복구 시점 목표(RPO): 1분 미만. 쓰기는 비동기적으로 복제됩니다. 새로 승격된 프라이머리에 복제되지 않은 쓰기는 손실됩니다. 실패한 노드에서 진행 중이던 읽기 작업은 종료됩니다. 강한 일관성 은 일부 상황에서 손실을 방지합니다. 복구 시간 목표(RTO): 10초 미만. 중단은 각 Praefect 노드가 매초 실행하는 상태 확인에 의해 감지됩니다. 페일오버는 각 Praefect 노드에서 연속적으로 10번 실패한 상태 확인이 필요합니다. RPO 및 RTO 개선 사항은 에픽 8903 에서 제안됩니다. Warning 완전한 클러스터 장애가 발생하면 재해 복구 계획을 실행해야 합니다. 이는 앞서 설명한 RPO 및 RTO에 영향을 미칠 수 있습니다. Gitaly 클러스터(Praefect) 배포 전에 # Gitaly 클러스터(Praefect)는 내결함성의 이점을 제공하지만 추가적인 설정 및 관리 복잡성이 따릅니다. Gitaly 클러스터(Praefect)를 배포하기 전에 다음을 참조하십시오: 기존 알려진 문제 . 스냅샷 백업 및 복구 . 구성 지침