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

계획된 장애 조치 대비 재해 복구

재해 복구의 주요 사용 사례는 예상치 못한 장애 발생 시 비즈니스 연속성을 보장하는 것이지만, 길게 이어지는 다운타임 없이 지역 간 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에서 Object Storage를 보조 사이트에 대한 복제를 GitLab이 관리할 수 있도록 하는 기능을 선택적으로 사용할 수 있습니다. 자세한 내용은 객체 저장소 복제를 참조하세요.

각 보조 사이트의 구성 검토

데이터베이스 설정은 보조 사이트로 자동으로 복제되지만, /etc/gitlab/gitlab.rb 파일은 수동으로 설정해야 하며 사이트마다 다릅니다. 주 사이트에서 Mattermost, OAuth 또는 LDAP 통합과 같은 기능이 활성화되어 있지만 보조 사이트에서는 그렇지 않은 경우, 계획된 장애 조치 중에 해당 기능이 손실됩니다.

보조 사이트 및 주 사이트의 /etc/gitlab/gitlab.rb 파일을 검토하고, 계획된 장애 조치를 예약하기 전에 보조 사이트가 주 사이트가 지원하는 모든 기능을 지원하는지 확인하세요.

시스템 체크 실행

다음을 primary 및 secondary 사이트에서 실행하십시오:

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

파일에 차이가 있는 경우, 필요에 따라 secondary 사이트에 수동으로 GitLab 비밀값을 복제하고 SSH 호스트 키를 복제하십시오.

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

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

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

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

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

secondary 사이트에서:

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

2. Geo > 사이트를 선택합니다. 복제된 객체(녹색으로 표시)가 100%에 가깝고 실패가 없어야 합니다(빨간색으로 표시). 복제되지 않은 객체의 비율이 크다면(회색으로 표시), 사이트에 더 많은 시간을 부여하는 것을 고려하십시오.

   

만일 복제에 실패하는 객체가 있다면, 유지보수 창을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 이후, 복제에 실패한 모든 것이 손실됩니다.

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

복제 실패의 일반적인 원인은 데이터가 primary 사이트에 누락된 것입니다. 이러한 실패는 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거함으로써 해결할 수 있습니다.

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

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

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

primary 사이트에서:

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

러너 장애 조치

현재 secondary에 연결된 러너가 있으면 장애 조치 중에 이러한 러너를 처리하는 방법을 참조하십시오.

primary 사이트의 업데이트 방지

보조 사이트에 모든 데이터가 복제되기 위해 primary 사이트에서 업데이트(쓰기 요청)를 비활성화해야 합니다:

1. primary 사이트에서 유지보수 모드를 활성화합니다.
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. primary 사이트에서:
   1. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
   3. Sidekiq 대시보드에서 대기열을 선택하고, geo가 이름에 포함되지 않은 큐가 모두 0이 될 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 포함되어 있으며, 완료되기 전에 장애 조치를 진행하면 작업이 손실됩니다.

   4. 왼쪽 사이드바에서 Geo > 사이트를 선택하고, 계획된 장애 조치를 진행 중인 secondary 사이트에 대해 다음 조건이 적합한지 확인합니다:

      • 모든 복제 미터가 100% 복제, 실패 0%에 도달합니다.
      • 모든 검증 미터가 100% 확인, 실패 0%에 도달합니다.
      • 데이터베이스 복제 지연이 0 ms입니다.
      • Geo 로그 커서가 최신 상태(이벤트 지연 0개)입니다.
3. secondary 사이트에서:
   1. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
   3. Sidekiq 대시보드에서 대기열을 선택하고, 모든 geo 큐가 0으로 줄어들고 실행 중인 작업이 없을 때까지 기다립니다.
   4. 무결성 검사를 실행하여 CI 아티팩트, LFS 객체 및 파일 저장소에 있는 업로드의 무결성을 확인합니다.

이 시점에서 secondary 사이트는 primary 사이트의 모든 것을 최신 상태로 포함하므로 장애 조치 시에 손실된 것이 없음을 의미합니다.

secondary 사이트를 홍보하세요

복제가 완료된 후, secondary 사이트를 primary 사이트로 홍보하세요. 이 과정은 secondary 사이트에서 잠시 서비스 중단이 발생할 수 있으며, 사용자는 다시 로그인해야 할 수도 있습니다. 제대로 된 단계를 따른다면, 이전의 기존 primary Geo 사이트는 여전히 비활성화되어 있고 사용자 트래픽은 새롭게 홍보된 사이트로 이동해야 합니다.

홍보가 완료되면 유지 보수 창이 종료되고 새로운 primary 사이트가 이전 사이트와 다른 경로로 진행됩니다. 이 시점에서 문제가 발생하면, 이전 primary 사이트로의 복귀 가능하지만, 임시로 새 primary에 업로드된 데이터 손실 가능성이 높습니다.

failover가 완료되면 브로드캐스트 메시지를 제거하는 것을 잊지 마세요.

마지막으로 이전 사이트를 secondary로 다시 되살리세요.