재해 복구의 주요 사용 사례는 계획되지 않은 중단 시 비즈니스 연속성을 보장하는 것이지만, 장기 다운타임 없이 GitLab 인스턴스를 리전 간에 마이그레이션하기 위한 계획된 페일오버와 함께 사용할 수 있습니다.

Geo 사이트 간의 복제는 비동기적이므로 계획된 페일오버에는 기본 사이트에 대한 업데이트가 차단되는 유지 관리 창이 필요합니다. 이 창의 길이는 보조 사이트를 기본 사이트와 완전히 동기화하는 데 걸리는 시간에 따라 다릅니다. 동기화가 완료되면 데이터 손실 없이 페일오버가 수행될 수 있습니다.

이 문서는 이미 완전히 구성된 작동 중인 Geo 설정이 있다고 가정합니다. 진행하기 전에 이 문서와 재해 복구 페일오버 문서를 완전히 읽으세요. 계획된 페일오버는 주요 작업이며 잘못 수행하면 데이터 손실 위험이 높습니다. 필요한 단계에 충분히 익숙해지고 정확하게 수행할 수 있다는 높은 확신이 생길 때까지 절차를 연습하세요.

페일오버 권장 사항#

이러한 권장 사항을 따르면 원활한 페일오버 프로세스를 보장하고 데이터 손실 또는 장기 다운타임의 위험을 줄일 수 있습니다.

동기화 및 검증 오류 해결#

사전 점검 중에 실패 또는 대기 중 항목이 있는 경우(수동 검증 또는 gitlab-ctl promotion-preflight-checks 실행 시), 다음 중 하나가 될 때까지 페일오버가 차단됩니다:

• 해결됨: 성공적으로 동기화됨(필요한 경우 보조에 수동 복사).
• 허용 가능한 것으로 문서화됨: 다음과 같은 명확한 근거 포함:
  • 이러한 특정 오류에 대해 수동 체크섬 비교가 통과됨.
  • 저장소가 더 이상 사용되지 않으며 제외할 수 있음.
  • 항목이 비중요 항목으로 식별되어 페일오버 후에 복사할 수 있음.

동기화 및 검증 오류 진단에 대한 도움은 Geo 동기화 및 검증 오류 문제 해결을 참조하세요.

데이터 무결성 해결 계획#

Geo 복제를 처음 설정한 후 일반적으로 발생하는 데이터 무결성 문제를 해결하기 위해 페일오버 완료 전 4-6주를 허용합니다. 여기에는 고아 데이터베이스 레코드 또는 일치하지 않는 파일 참조가 포함될 수 있습니다. 지침은 일반 Geo 오류 문제 해결을 참조하세요.

유지 관리 창 중에 어려운 결정을 피하기 위해 동기화 문제를 일찍 해결하기 시작하세요:

1. 4-6주 전: 미해결 동기화 문제를 식별하고 해결 시작.
2. 1주 전: 남은 모든 동기화 문제의 해결 또는 문서화 목표.
3. 1-2일 전: 새로운 오류 해결.
4. 몇 시간 전: 새로운 오류 마지막 확인.

성공을 보장하기 위해: 미해결 동기화 오류로 인해 페일오버를 중단할 시기에 대한 명확한 기준을 만드세요.

Geo 환경에서 백업 타이밍 테스트#

미리 백업 절차를 테스트하고 다음 전략을 고려하세요:

• 기본 사이트에서 직접 백업을 수행합니다. 이는 성능에 영향을 줄 수 있습니다.
• 백업 중 복제에서 격리할 수 있는 전용 읽기 복제본을 사용합니다.
• 낮은 활동 기간에 백업을 예약합니다.

포괄적인 폴백 절차 준비#

다음을 포함하여 원래 기본 사이트로 되돌리는 특정 단계를 문서화합니다:

• 페일오버를 중단할 시기에 대한 결정 기준.
• DNS 복원 절차.
• 원래 기본 사이트를 다시 활성화하는 프로세스. 강등된 기본 사이트를 다시 온라인 상태로 가져오기를 참조하세요.
• 사용자 통보 계획.

스테이징 환경에서 페일오버 런북 개발#

성공을 보장하기 위해 이 고도로 수동적인 작업을 전체적으로 연습하고 문서화하세요:

1. 프로덕션과 유사한 환경이 없는 경우 프로비저닝합니다.
2. 스모크 테스트. 예를 들어 그룹, 프로젝트, 러너 추가, git push 사용, 이슈에 이미지 추가.
3. 보조 사이트로 페일오버.
4. 스모크 테스트 실행. 문제 확인.
5. 이러한 단계 중에 수행된 모든 작업, 행위자, 예상 결과, 리소스 링크를 기록합니다.
6. 런북 및 스크립트를 개선하기 위해 필요에 따라 반복합니다.

모든 데이터가 자동으로 복제되지는 않음#

Geo가 지원하지 않는 GitLab 기능을 사용하는 경우 해당 기능과 관련된 데이터의 최신 복사본이 보조 사이트에 있는지 확인하기 위해 별도의 조치를 취해야 합니다. 이는 유지 관리 기간을 크게 연장할 수 있습니다. Geo에서 지원하는 기능 목록은 복제된 데이터 유형 표를 참조하세요.

파일에 저장된 데이터에 대해 이 기간을 최대한 짧게 유지하는 일반적인 전략은 rsync를 사용하여 데이터를 전송하는 것입니다. 초기 rsync는 유지 관리 창 전에 수행할 수 있습니다. 이후 유지 관리 창 내의 최종 전송을 포함한 rsync 절차는 기본 사이트와 보조 사이트 간의 변경 사항만 전송합니다.

rsync를 효과적으로 사용하기 위한 Git 저장소 중심 전략은 저장소 이동을 참조하세요. 이러한 전략은 다른 파일 기반 데이터와 함께 사용하도록 조정할 수 있습니다.

컨테이너 레지스트리#

기본적으로 컨테이너 레지스트리는 보조 사이트에 자동으로 복제되지 않습니다. 수동으로 구성해야 합니다. 자세한 내용은 보조 사이트의 컨테이너 레지스트리를 참조하세요.

컨테이너 레지스트리에 현재 기본 사이트의 로컬 스토리지를 사용하는 경우 페일오버할 보조 사이트로 컨테이너 레지스트리 오브젝트를 rsync할 수 있습니다:

# Run from the secondary site
rsync --archive --perms --delete root@<geo-primary>:/var/opt/gitlab/gitlab-rails/shared/registry/. /var/opt/gitlab/gitlab-rails/shared/registry

또는 기본 사이트에서 컨테이너 레지스트리를 백업하고 보조 사이트에 복원합니다:

1. 기본 사이트에서 레지스트리만 백업하고 백업에서 특정 디렉토리를 제외합니다:

   # Create a backup in the /var/opt/gitlab/backups folder
   sudo gitlab-backup create SKIP=db,uploads,builds,artifacts,lfs,terraform_state,pages,repositories,packages
   

2. 기본 사이트에서 생성된 백업 tarball을 보조 사이트의 /var/opt/gitlab/backups 폴더에 복사합니다.

3. 보조 사이트에서 GitLab 복원 문서에 따라 레지스트리를 복원합니다.

고급 검색 데이터 복구#

고급 검색은 Elasticsearch 또는 OpenSearch로 구동됩니다. 고급 검색 데이터는 보조 사이트에 자동으로 복제되지 않습니다.

새로 승격된 기본 사이트에서 고급 검색 데이터를 복구하려면:

사전 점검#

계획된 페일오버를 예약하기 전에 이러한 사전 점검을 확인하여 프로세스가 원활하게 진행되도록 합니다. 각 단계는 아래에서 더 자세히 설명합니다.

실제 페일오버 프로세스 중에 기본 사이트가 다운된 후 보조 사이트를 승격하기 전에 다음 명령을 실행하여 최종 검증 점검을 수행합니다:

gitlab-ctl promotion-preflight-checks

gitlab-ctl promotion-preflight-checks 명령은 페일오버 프로세스의 일부이며 기본 사이트가 다운되어야 합니다. 기본 사이트가 여전히 실행 중인 동안 사전 유지 관리 검증 도구로 사용할 수 없습니다. 이 명령을 실행하면 기본 사이트가 다운되어 있는지 묻는 프롬프트가 표시됩니다. 아니오라고 답하면 ERROR: primary node must be down 오류가 표시됩니다.

기본 사이트가 여전히 작동 중인 동안 사전 유지 관리 검증을 위해서는 아래의 수동 점검을 사용하세요.

DNS TTL#

기본 도메인 DNS 레코드 업데이트를 계획하는 경우 DNS 변경의 빠른 전파를 위해 낮은 TTL(time-to-live)을 설정하는 것을 고려하세요.

오브젝트 스토리지#

GitLab 설치 규모가 크거나 다운타임을 허용할 수 없는 경우 계획된 페일오버를 예약하기 전에 오브젝트 스토리지로 마이그레이션하는 것을 고려하세요. 이렇게 하면 유지 관리 창의 길이와 잘못 실행된 계획된 페일오버로 인한 데이터 손실 위험이 모두 줄어듭니다.

보조 사이트에 대한 오브젝트 스토리지 복제를 GitLab이 관리하도록 하려면 오브젝트 스토리지 복제를 참조하세요.

각 보조 사이트의 구성 검토#

데이터베이스 설정은 보조 사이트에 자동으로 복제됩니다. 그러나 /etc/gitlab/gitlab.rb 파일은 수동으로 설정해야 하며 사이트 간에 다릅니다. Mattermost, OAuth 또는 LDAP 통합과 같은 기능이 기본 사이트에서 활성화되어 있지만 보조 사이트에서는 활성화되지 않은 경우 페일오버 중에 손실됩니다.

두 사이트의 /etc/gitlab/gitlab.rb 파일을 검토하세요. 계획된 페일오버를 예약하기 전에 보조 사이트가 기본 사이트가 수행하는 모든 것을 지원하는지 확인하세요. GitLab Geo 역할이 올바르게 구성되어 있는지 확인하세요.

시스템 점검 실행#

기본 및 보조 사이트 모두에서 다음을 실행합니다:

gitlab-rake gitlab:check
gitlab-rake gitlab:geo:check

어느 사이트에서든 오류가 보고되면 계획된 페일오버를 예약하기 전에 해결하세요.

노드 간에 시크릿 및 SSH 호스트 키가 일치하는지 확인#

SSH 호스트 키와 /etc/gitlab/gitlab-secrets.json 파일은 모든 노드에서 동일해야 합니다. 모든 노드에서 다음을 실행하고 출력을 비교하여 확인합니다:

sudo sha256sum /etc/ssh/sshhost /etc/gitlab/gitlab-secrets.json

파일이 다른 경우 필요에 따라 GitLab 시크릿을 수동으로 복제하고 SSH 호스트 키를 복제하여 보조 사이트로 전송합니다.

HTTPS를 위한 올바른 인증서 설치 확인#

기본 사이트와 기본 사이트에서 액세스하는 모든 외부 사이트가 공개 CA 발급 인증서를 사용하는 경우 이 단계를 안전하게 건너뛸 수 있습니다.

다음 중 하나의 경우 보조 사이트에 올바른 인증서를 설치해야 합니다:

• 기본 사이트가 인바운드 연결을 보호하기 위해 사용자 정의 또는 자체 서명 TLS 인증서를 사용합니다.
• 기본 사이트가 사용자 정의 또는 자체 서명 인증서를 사용하는 외부 서비스에 연결합니다.

자세한 내용은 사용자 정의 인증서 사용을 참조하세요.

Geo 복제가 최신 상태인지 확인#

유지 관리 창은 Geo 복제 및 검증이 완전히 완료될 때까지 종료되지 않습니다. 창을 최대한 짧게 유지하려면 활성 사용 중에 이러한 프로세스가 100%에 가깝도록 해야 합니다.

보조 사이트에서:

1. 오른쪽 상단에서 관리자를 선택합니다.

2. 왼쪽 사이드바에서 Geo > 사이트를 선택합니다. 복제된 오브젝트(녹색으로 표시)가 100%에 가깝고 오류(빨간색으로 표시)가 없어야 합니다. 아직 복제되지 않은 오브젝트(회색으로 표시) 비율이 크면 사이트에 더 많은 시간을 줍니다:

   

오브젝트 복제에 실패하면 유지 관리 창을 예약하기 전에 조사하세요. 복제에 실패한 오브젝트는 계획된 페일오버 후에 손실됩니다.

복제 오류의 일반적인 원인은 기본 사이트에서 데이터가 누락된 것입니다. 이러한 오류를 해결하려면 다음 중 하나를 수행합니다:

• 백업에서 데이터를 복원합니다.
• 누락된 데이터에 대한 참조를 제거합니다.

복제된 데이터의 무결성 확인#

페일오버를 진행하기 전에 검증이 완료되었는지 확인하세요. 검증에 실패한 손상된 데이터는 페일오버 중에 손실될 수 있습니다.

자세한 내용은 자동 백그라운드 검증을 참조하세요.

예약된 유지 관리에 대해 사용자에게 알림#

기본 사이트에서:

1. 오른쪽 상단에서 관리자를 선택합니다.
2. 왼쪽 사이드바에서 메시지를 선택합니다.
3. 유지 관리 창에 대해 사용자에게 알리는 메시지를 추가합니다. 동기화를 완료하는 데 필요한 시간을 추정하려면 Geo > 사이트로 이동합니다.
4. 브로드캐스트 메시지 추가를 선택합니다.

페일오버 중 러너 연결#

인스턴스 URL 구성 방법에 따라 페일오버 후 러너 플릿을 100%로 유지하기 위한 추가 단계가 있을 수 있습니다.

러너를 등록하는 데 사용되는 토큰은 기본 또는 보조 인스턴스에서 작동해야 합니다. 페일오버 후 연결 문제가 발생하면 보조 구성 중에 시크릿이 복사되지 않았을 수 있습니다. 러너 토큰을 재설정할 수 있지만, 시크릿이 동기화되지 않으면 러너와 관련 없는 다른 문제가 발생할 수 있습니다.

러너가 GitLab 인스턴스에 반복적으로 연결할 수 없는 경우 일정 기간 동안 연결 시도를 중단합니다. 기본적으로 이 기간은 1시간입니다. 이를 방지하려면 GitLab 인스턴스에 도달할 수 있을 때까지 러너를 종료하세요. check_interval 문서 및 구성 옵션 unhealthy_requests_limit 및 unhealthy_interval을 참조하세요.

• 위치 인식 URL을 사용하는 경우: 이전 기본 사이트가 DNS 구성에서 제거되면 러너가 자동으로 다음으로 가까운 인스턴스에 연결합니다.
• 별도의 URL을 사용하는 경우: 현재 기본 사이트에 연결된 러너는 승격되면 새 기본 사이트에 연결하도록 업데이트해야 합니다.
• 현재 보조 사이트에 연결된 러너가 있는 경우: 페일오버 중 보조 러너를 처리하는 방법을 참조하세요.

OpenBao 사전 요건#

GitLab Helm 차트와 함께 OpenBao가 설치된 경우, 기본 클러스터에 여전히 액세스할 수 있는 동안 이 점검들을 완료하세요.

보조 사이트에 언실 시크릿이 있는지 확인#

gitlab-openbao-unseal Kubernetes 시크릿이 보조 클러스터에 존재해야 합니다. 다음을 실행하여 존재 여부를 확인합니다:

kubectl --namespace gitlab get secret gitlab-openbao-unseal

시크릿이 없는 경우 진행하기 전에 기본 사이트에서 복사하세요. 자세한 내용은 시크릿 백업을 참조하세요.

OpenBao 데이터베이스 복제 검증#

보조 OpenBao 데이터베이스는 openbao 스키마를 포함한 기본 PostgreSQL의 읽기 복제본입니다. 계획된 페일오버 전에 복제가 최신 상태이고 보조 데이터가 기본 사이트와 일치하는지 확인합니다.

기본 데이터베이스를 이미 사용할 수 없는 경우 보조 사이트에는 마지막으로 복제된 트랜잭션까지의 데이터가 포함됩니다. 마지막 복제 이후 기본 사이트에 쓰여진 시크릿은 손실됩니다.

기본 사이트에 대한 업데이트 방지#

모든 데이터가 보조 사이트에 복제되도록 하려면 기본 사이트에서 업데이트(쓰기 요청)를 비활성화하여 보조 사이트가 따라잡을 시간을 줍니다:

1. 기본 사이트에서 유지 관리 모드를 활성화합니다.

2. 오른쪽 상단에서 관리자를 선택합니다.

3. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.

4. Sidekiq 대시보드에서 Cron을 선택합니다.

5. 모두 비활성화를 선택하여 Geo가 아닌 주기적 백그라운드 작업을 비활성화합니다.

6. 다음 cron 작업에 대해 활성화를 선택합니다:

   • geo_metrics_update_worker
   • geo_prune_event_log_worker
   • geo_verification_cron_worker
   • repository_check_worker

   이러한 cron 작업을 다시 활성화하는 것은 계획된 페일오버가 성공적으로 완료되는 데 필수적입니다.

모든 데이터 복제 및 검증 완료#

1. Geo에서 관리하지 않는 데이터를 수동으로 복제하는 경우 지금 최종 복제 프로세스를 트리거합니다.

2. 기본 사이트에서:

   1. 오른쪽 상단에서 관리자를 선택합니다.

   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.

   3. Sidekiq 대시보드에서 큐를 선택합니다. 이름에 geo가 있는 큐를 제외한 모든 큐가 0으로 떨어질 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 포함됩니다. 큐가 비기 전에 페일오버하면 작업이 손실됩니다.

   4. 왼쪽 사이드바에서 Geo > 사이트를 선택합니다. 페일오버할 보조 사이트에 대해 다음 조건이 충족될 때까지 기다립니다:

      • 모든 복제 미터가 100% 복제됨, 0% 오류에 도달.
      • 모든 검증 미터가 100% 검증됨, 0% 오류에 도달.
      • 데이터베이스 복제 지연이 0ms.
      • Geo 로그 커서가 최신 상태(0 이벤트 뒤처짐).

3. 보조 사이트에서:

   1. 오른쪽 상단에서 관리자를 선택합니다.
   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
   3. Sidekiq 대시보드에서 큐를 선택합니다. 모든 geo 큐가 0 대기 및 0 실행 중인 작업으로 떨어질 때까지 기다립니다.
   4. 무결성 검사를 실행하여 파일 스토리지의 CI 아티팩트, LFS 오브젝트 및 업로드의 무결성을 확인합니다.

이 시점에서 보조 사이트에는 기본 사이트의 모든 것이 최신 복사본으로 포함되어 있으며 페일오버 시 데이터 손실이 없습니다.

보조 사이트 승격#

복제가 완료되면 보조 사이트를 기본 사이트로 승격합니다. 이 프로세스는 보조 사이트에서 잠시 중단을 초래하며 사용자는 다시 로그인해야 할 수 있습니다. 단계를 올바르게 따르면 이전 기본 Geo 사이트가 비활성화되고 사용자 트래픽이 새로 승격된 사이트로 흐릅니다.

승격이 완료되면 유지 관리 창이 종료되고 새 기본 사이트가 이전 사이트에서 분기되기 시작합니다.

페일오버가 완료된 후 브로드캐스트 메시지를 제거하는 것을 잊지 마세요.

모든 것이 예상대로 작동하면 이전 사이트를 보조 사이트로 복구할 수 있습니다.

이전 기본으로 폴백#

새로 승격된 기본 사이트에 문제가 있으면 이전 사이트로 폴백이 가능하지만, 새 기본 사이트에서 이루어진 모든 변경 사항은 손실됩니다.