Gitaly Cluster (Praefect)

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

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