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

계획된 장애 조치용 재해 복구

재해 복구의 주요 사용 사례는 계획되지 않은 중단 사태가 발생한 경우 비즈니스 연속성을 보장하는 것이지만, 지연된 다운타임 없이 깃랩 인스턴스를 지역 간에 이관하기 위해 계획된 장애 조치와 함께 사용할 수 있습니다.

Geo 사이트 간의 복제가 비동기적이기 때문에 계획된 장애 조치에는 주 전체 사이트의 업데이트가 차단되는 유지 보수 창이 필요합니다. 이 창의 길이는 복제 용량에 따라 결정되며, 보조 사이트가 주 사이트와 완전히 동기화된 경우 데이터 손실 없이 장애 조치를 수행할 수 있습니다.

이 문서는 이미 완전히 구성되어 작동하는 Geo 설정이 있다고 가정합니다. 이 문서와 재해 복구 장애 조치 문서를 숙지한 후 계속 진행하십시오. 계획된 장애 조치는 중요한 조치이며, 잘못 수행할 경우 데이터 손실의 위험이 높습니다. 필요한 단계에 대해 자신 있고 고도의 확신을 가질 때까지 절차를 훈련해 보는 것을 고려하십시오.

모든 데이터가 자동으로 복제되지는 않습니다

Geo에서 지원되지 않는 GitLab 기능을 사용 중이라면 해당 기능과 관련된 모든 데이터의 최신 사본이 보조 사이트에 있는지 확인하는 별도의 조치를 취해야 합니다. 이는 필요한 예정 유지보수 기간을 크게 연장시킬 수 있습니다. Geo에서 지원되는 기능 목록은 복제된 데이터 유형 테이블에서 확인할 수 있습니다.

파일에 저장된 데이터에 대한 이 기간을 최소화하기위한 일반적인 전략은 데이터를 전송하기 위해 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 인증서를 사용하거나 주 사이트가 사용자 정의 또는 자체 서명된 인증서를 사용하여 외부 서비스에 연결하는 경우 보조 사이트에도 올바른 인증서를 설치해야 합니다. 사용자 정의 인증서 사용 지침을 따르십시오.

지오 복제가 최신 상태인지 확인하세요

유지 보수 창이 종료될 때까지 지오 복제 및 확인이 완전히 끝나지 않습니다. 창을 가능한 한 짧게 유지하려면 이러한 프로세스가 활성 사용 중에 가능한 한 100%에 가까워야 합니다.

보조 사이트에서:

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

2. 지오 > 사이트를 선택합니다. 복제된 객체(녹색으로 표시)는 100%에 가깝고, 실패한 것(빨간색으로 표시)이 없어야 합니다. 만약 객체의 많은 부분이 아직 복제되지 않았다면(회색으로 표시), 사이트에 더 많은 시간을 주는 것을 고려해 보세요.

   

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

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

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

이 콘텐츠가 다른 위치로 이동되었습니다.

예약 된 유지 보수 알림

기본 사이트에서:

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

러너 장애 조치

인스턴스 URL이 구성된 방식에 따라 장애 조치 후 러너 플리트를 100% 유지하는 추가 단계가 필요할 수 있습니다.

러너를 등록하는 데 사용된 토큰은 기본 또는 보조 인스턴스에서 작동해야 합니다. 장애 조치 후 연결에 문제가 있는 경우 보조 구성 중에 비밀이 복사되지 않았을 수 있습니다. 러너 토큰을 재설정할 수 있지만, 비밀이 동기화되지 않으면 러너와 관련 없는 다른 문제가 발생할 수 있음을 유의하세요.

러너가 GitLab 인스턴스에 반복적으로 연결하지 못할 경우 일정 시간(기본 1시간) 동안 연결을 시도하지 않습니다. 이를 피하려면 러너를 GitLab 인스턴스에 연결할 수 있을 때까지 중지해야 합니다. check_interval 문서 및 unhealthy_requests_limit 및 unhealthy_interval 구성 옵션을 참조하세요.

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

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

보조 사이트로 모든 데이터가 복제되었는지 확인하려면 기본 사이트에서 업데이트(쓰기 요청)를 비활성화해야 합니다:

1. 기본 사이트에서 유지 모드를 활성화합니다.
2. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
3. 모니터링 > 백그라운드 작업을 선택합니다.
4. Sidekiq 대시보드에서 Cron을 선택합니다.
5. 비-지오 주기적 백그라운드 작업을 비활성화하려면 모두 비활성화를 선택하세요.

6. 다음 cron 작업에 대해 활성화를 선택하세요:

   • geo_metrics_update_worker
   • geo_prune_event_log_worker
   • geo_verification_cron_worker
   • repository_check_worker

   이렇게 하면 계획된 장애 조치가 성공적으로 완료되는 데 필수적인 여러 cron 작업이 다시 활성화됩니다.

모든 데이터의 복제 및 확인 완료

1. 지오에서 관리되지 않는 데이터를 수동으로 복제 중인 경우 마지막 복제 프로세스를 시작합니다.
2. 기본 사이트에서:
   1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
   3. Sidekiq 대시보드에서 큐를 선택한 후 geo와 이름이 있는 큐를 제외한 모든 큐가 0이 될 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 들어 있으며, 완료되기 전에 장애 조치를 실행하면 작업이 손실됩니다.

   4. 왼쪽 사이드바에서 지오 > 사이트를 선택한 후 장애 조치할 보조 사이트에 대해 다음 조건이 충족될 때까지 기다립니다:

      • 모든 복제 미터가 100% 복제되었으며, 실패하지 않았습니다.
      • 모든 확인 미터가 100% 확인되었으며, 실패하지 않았습니다.
      • 데이터베이스 복제 지연이 0밀리초입니다.
      • 지오 로그 커서가 최신 상태 (이벤트 지연 없음)입니다.
3. 보조 사이트에서:
   1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
   3. Sidekiq 대시보드에서 큐를 선택한 후 ‘geo’ 큐가 0으로 줄어들고 있는지 확인합니다.
   4. 무결성 확인을 실행하여 CI artifact, LFS objects 및 파일 스토리지에 있는 업로드의 무결성을 확인합니다.

이 시점에서 보조 사이트에는 기본 사이트와 동일한 모든 것의 최신 사본이 포함되어 있으므로 장애 조치 중에 아무 것도 잃어버리지 않았습니다.

보조 사이트 승격

복제가 완료되면 보조 사이트를 기본 사이트로 승격합니다. 이 과정은 보조 사이트에서 잠시 중단되며 사용자는 다시 로그인해야 할 수 있습니다. 단계를 올바르게 따르면 이전 기본 지오 사이트는 여전히 비활성화되고 사용자 트래픽은 새로 승격된 사이트로 이동해야 합니다.

승격이 완료되면 유지 보수 창이 종료되고 새 기본 사이트는 이전 사이트와 달라집니다. 이 시점에서 문제가 발생하면 이전 기본 사이트로 되돌아가는 것이 가능하지만, 이 경우 새 기본에 업로드된 데이터가 손실될 가능성이 높습니다.

장애 조치가 완료되면 방송 메시지를 삭제하는 것을 잊지 마세요.

마지막으로 이전 사이트를 보조로 다시 사용할 수 있습니다.