• 모든 데이터가 자동으로 복제되는 것은 아닙니다
  • 컨테이너 레지스트리
• 사전 점검
  • DNS TTL
  • 객체 리포지터리
  • 각 보조 사이트의 구성 검토
  • 시스템 검사 실행
  • 노드 간의 정확한 비밀 및 SSH 호스트 키가 일치하는지 확인
  • 올바른 인증서가 HTTPS에 설치되어 있는지 확인
  • Geo 복제가 최신 상태인지 확인
  • 복제된 데이터의 무결성 확인
  • 예정된 유지 보수 알림 사용자 알리기
  • 러너 장애 조치
• 기본 사이트의 업데이트 방지
• 모든 데이터의 복제 및 검증 완료
• 보조 사이트를 기본 사이트로 승격

예정된 장애 조치(Failover)를 위한 재해 복구

재해 복구의 주요 사용 사례는 뜻밖의 중지 사태가 발생한 경우 비즈니스 연속성을 보장하는 것이지만, GitLab 인스턴스를 지역 간에 지연 시간이 긴 다운타임 없이 마이그레이션하기 위해 예정된 장애 조치와 함께 사용할 수 있습니다.

Geo 사이트 간 복제가 비동기적이기 때문에 예정된 장애 조치에는 주 사이트의 업데이트가 차단되는 유지 보수 창이 필요합니다. 이 창의 길이는 복제 용량에 의해 결정됩니다 - 보조 사이트가 주 사이트와 완전히 동기화되면 데이터 손실 없이 장애 조치가 발생할 수 있습니다.

이 문서는 이미 완전히 구성되고 작동 중인 Geo 설정이 있다고 가정합니다. 계속 진행하기 전에 본 문서와 재해 복구 장애 조치 설명서를 완전히 읽으십시오. 예정된 장애 조치는 주요한 작업이며, 잘못 수행할 경우 데이터 손실의 위험이 높습니다. 필요한 단계를 정확히 수행할 수 있는 높은 신뢰도를 갖기 위해 절차를 연습하는 것을 고려하십시오.

모든 데이터가 자동으로 복제되는 것은 아닙니다

Geo가 지원하지 않는 GitLab 기능을 사용 중이라면 해당 기능과 관련된 모든 데이터의 최신 사본이 보조 사이트에 있는지 확인하기 위해 별도의 준비를 해야 합니다. 이는 필요한 예정된 유지 보수 기간을 크게 연장할 수 있습니다.

파일에 저장된 데이터의 경우, 이 기간을 최소화하는 일반적인 전략은 rsync를 사용하여 데이터를 전송하는 것입니다. 유지 보수 창 전에 초기 rsync를 수행할 수 있으며, 이후의 rsync (유지 보수 창 내에서 최종 전송을 포함)은 주 사이트와 보조 사이트 사이의 변경 사항만 전송합니다.

rsync를 효과적으로 사용하는 Git 리포지터리 중심의 전략은 리포지터리 이동 설명서에서 찾을 수 있으며, 이러한 전략은 다른 기반 파일 데이터와 함께 사용할 수 있습니다.

컨테이너 레지스트리

기본적으로, 컨테이너 레지스트리는 자동으로 보조 사이트로 복제되지 않으며, 이를 매뉴얼으로 구성해야 합니다. 보조 사이트를 위한 컨테이너 레지스트리를 참조하십시오.

현재 주 사이트에서 컨테이너 레지스트리에 로컬 리포지터리를 사용하고 있다면, 해당 리포지터리의 객체를 장애 조치할 예정인 보조 사이트로 rsync할 수 있습니다.

# 보조 사이트에서 실행
rsync --archive --perms --delete root@<geo-primary>:/var/opt/gitlab/gitlab-rails/shared/registry/. /var/opt/gitlab/gitlab-rails/shared/registry

또는 주 사이트에서 컨테이너 레지스트리를 백업하고 해당 백업을 장애 조치할 예정인 보조 사이트로 복원할 수 있습니다.

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

   # /var/opt/gitlab/backups 폴더에 백업 생성
   sudo gitlab-backup create SKIP=db,uploads,builds,artifacts,lfs,terraform_state,pages,repositories,packages
   

2. 주 사이트에서 생성된 백업 타볼을 보조 사이트의 /var/opt/gitlab/backups 폴더로 복사합니다.

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

사전 점검

이 명령을 실행하여 예정된 장애 조치가 원활하게 진행되도록 하기 전에 완전한 사전 점검 디렉터리을 작성하고 복제 및 확인이 완료되었는지 자동으로 확인하십시오.

gitlab-ctl promotion-preflight-checks

각 단계는 아래에서 자세히 설명되어 있습니다.

DNS TTL

기본 도메인 DNS 레코드를 업데이트할 계획이라면, DNS 변경 사항이 빠르게 전파되도록 TTL을 낮게 유지하는 것이 좋습니다.

객체 리포지터리

대규모 GitLab 설치의 경우 또는 다운 타임을 감당할 수 없는 경우, 예정된 장애 조치를 할 전에 객체 리포지터리로의 마이그레이션을 고려하십시오. 이렇게 하면 유지 보수 창의 길이뿐만 아니라 잘못된 예정된 장애 조치로 인한 데이터 손실의 위험도 줄어듭니다.

GitLab 15.1에서는 보조 사이트에서 객체 리포지터리의 복제를 GitLab에게 선택적으로 허용할 수 있습니다. 자세한 내용은 객체 리포지터리 복제를 참조하십시오.

각 보조 사이트의 구성 검토

데이터베이스 설정은 보조 사이트로 자동으로 복제되지만, /etc/gitlab/gitlab.rb 파일은 매뉴얼으로 설정해야 하며 사이트마다 다릅니다. 기본 사이트에서 사용 중인 Mattermost, OAuth 또는 LDAP 통합 등의 기능이 보조 사이트에서 사용 중이지 않다면, 장애 조치하면서 이러한 정보가 손실됩니다.

양쪽 사이트의 /etc/gitlab/gitlab.rb 파일을 검토하고 예정된 장애 조치를 하기 전에 보조 사이트가 기본 사이트와 동일하게 모든 것을 지원하는지 확인하십시오.

시스템 검사 실행

주 사이트와 보조 사이트 모두에서 다음을 실행하십시오.

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

둘 중 하나에서 실패한 경우, 예정된 장애 조치를 하기 전에 이를 해결해야 합니다.

노드 간의 정확한 비밀 및 SSH 호스트 키가 일치하는지 확인

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

sudo sha256sum /etc/ssh/ssh_host* /etc/gitlab/gitlab-secrets.json

파일에 차이가 있다면, 보조 사이트에 GitLab 비밀 매뉴얼 복제 및 SSH 호스트 키 복제를 해야 합니다.

올바른 인증서가 HTTPS에 설치되어 있는지 확인

주 사이트와 주 사이트가 사용하는 외부 사이트가 모두 공개 CA로부터 발급된 인증서를 사용하는 경우, 이 단계는 건너 뛰어도 됩니다.

주 사이트가 수신 연결을 안전하게 하기 위해 사용자 지정 또는 자체 서명된 TLS 인증서를 사용하거나 주 사이트가 사용하는 외부 서비스가 사용자 지정 또는 자체 서명된 인증서인 경우, 보조 사이트에도 올바른 인증서가 설치되어 있어야 합니다. 보조 사이트에서 사용자 지정 인증서 사용 지침을 따르십시오.

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

유지 보수 창은 Geo 복제 및 검증이 완전히 완료될 때까지 종료되지 않습니다. 창을 가능한 짧게 유지하기 위해 활성 사용 중에 이러한 프로세스가 가능한 100% 가까이라는 것을 확인해야 합니다.

보조 사이트에서:

1. 왼쪽 사이드바에서 맨 아래에서 관리 영역 선택합니다.

2. Geo > 사이트를 선택합니다. 복제된 객체(녹색으로 표시)가 100%에 가까워야 하며, 실패가 없어야 합니다(빨간색으로 표시). 대부분의 객체가 아직 복제되지 않은 경우(회색으로 표시), 사이트에 더 많은 시간을 주는 것을 고려해보세요.

   

복제할 객체가 실패하는 경우, 유지 보수 창을 예약하기 전에 조사해야 합니다. 계획된 장애 조치 이후, 복제에 실패한 모든 항목은 소실됩니다.

실패한 객체를 검토하고 실패 사유를 확인하려면 Geo 상태 API를 사용할 수 있습니다.

복제 실패의 일반적인 원인은 데이터가 기본 사이트에 없는 경우입니다. 이러한 실패는 데이터를 백업에서 복원하거나 없는 데이터에 대한 참조를 제거하여 해결할 수 있습니다.

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

본 내용이 다른 위치로 이동되었습니다.

예정된 유지 보수 알림 사용자 알리기

기본 사이트에서:

1. 왼쪽 사이드바에서 맨 아래에서 관리 영역 선택합니다.
2. 메시지를 선택합니다.
3. 유지 보수 창에 대해 사용자에게 알리는 메시지를 추가합니다. Geo > 사이트에서 동기화를 완료하는 데 필요한 시간을 추정할 수 있습니다.
4. 방송 메시지 추가를 선택합니다.

러너 장애 조치

현재 보조에 연결된 러너가 있는 경우 장애 조치하는 방법을 참조하십시오.

기본 사이트의 업데이트 방지

모든 데이터가 보조 사이트로 복제되도록하려면(쓰기 요청) 업데이트를 비활성화해야합니다:

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%입니다.
      • 데이터베이스 복제 랙이 0밀리초입니다.
      • Geo 로그 커서가 최신 상태입니다(이벤트 지연 0개).
3. 보조 사이트에서:
   1. 왼쪽 사이드바에서 맨 아래에서 관리 영역 선택합니다.
   2. 왼쪽 사이드바에서 모니터링 > 배경 작업을 선택합니다.
   3. Sidekiq 대시보드에서 대기열을 선택하고 모든 geo 대기열이 0으로 줄어들고 실행 중인 작업이 없을 때까지 기다립니다.
   4. CI 아티팩트, LFS 객체 및 파일 리포지터리의 무결성을 확인하기 위해 무결성 확인을 실행합니다.

이 시점에서 보조 사이트에는 기본 사이트가 가진 모든 것의 최신 사본이 포함되어 있으므로 장애 조치 시 아무 것도 손실되지 않습니다.

보조 사이트를 기본 사이트로 승격

복제가 완료되면 보조 사이트를 기본 사이트로 승격합니다. 이 프로세스는 보조 사이트에 잠시 중단을 유발하며 사용자는 다시 로그인해야 할 수 있습니다. 절차를 올바르게 따르면 이전의 기본 Geo 사이트는 여전히 비활성화되어 있어 사용자 트래픽은 새로운 승격된 사이트로 이동해야 합니다.

승격이 완료되면 유지 보수 창이 종료되며 새 기본 사이트는 이전 사이트와 다르게 시작하게됩니다. 이 시점에서 문제가 발생하면 이전의 기본 사이트로 반환하는 것은 가능하지만, 그 동안 새 기본에 업로드된 모든 데이터가 손실될 가능성이 높습니다.

장애 조치가 완료되면 방송 메시지를 제거하는 것을 잊지 마십시오.

마지막으로, 이전 사이트를 다시 보조로 되돌리십시오.