• 모든 데이터가 자동으로 복제되지는 않음
  • 컨테이너 레지스트리
• 사전 점검
  • DNS TTL
  • 오브젝트 리포지터리
  • 각 2부 사이트의 구성 검토
  • 시스템 검사 실행
  • 노드 간 보안 세부 정보 및 SSH 호스트 키 일치 여부 확인
  • 올바른 인증서가 HTTPS에 설치되어 있는지 확인
  • Geo 복제가 최신인지 확인
  • 복제된 데이터의 무결성 검사
  • 예정된 유지 관리 작업 알림 사용자입니다
  • 러너 장애 조치
• 기본 사이트에서 업데이트 방지
• 모든 데이터의 복제 및 검사 완료
• 보조 사이트를 승격

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

재해 복구의 주요 사용 사례는 계획되지 않은 장애가 발생했을 때 비즈니스 연속성을 보장하는 것이지만, 연장된 다운타임 없이 지역간에 GitLab 인스턴스를 마이그레이션하기 위해 계획된 장애 조치와 함께 사용할 수 있습니다.

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

이 문서는 이미 완전히 구성된 작동 중인 Geo 설정이 있다고 가정합니다. 진행하기 전에 이 문서와 재해 복구 장애 조치 문서를 완전히 읽어보세요. 계획된 장애 조치는 주요 작업이며, 잘못 수행하면 데이터 손실 위험이 높습니다. 필요한 단계에 익숙해지고 정확하게 수행할 수 있는 높은 수준의 확신이 생길 때까지 절차를 반복 연습하는 것이 좋습니다.

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

Geo가 지원하지 않는 어떤 GitLab 기능을 사용 중이면 2부 사이트가 해당 기능과 관련된 모든 데이터의 최신 사본을 보유하도록 별도로 조치해야 합니다. 이로 인해 필요한 예정 유지 보수 기간이 상당히 길어질 수 있습니다.

파일에 저장된 데이터를 최대한 짧게 유지하는 일반 전략은 rsync를 사용하여 데이터를 전송하는 것입니다. 유지 관리 창 앞에 초기 rsync를 수행할 수 있으며, 후속 rsync(유지 관리 창 내의 최종 전송포함)은 주 사이트와 2부 사이트 간의 변경 사항 만 전송합니다.

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

컨테이너 레지스트리

기본적으로, 컨테이너 레지스트리는 자동으로 2부 사이트에 복제되지 않으며, 이를 매뉴얼으로 구성해야 합니다. 두 번째 사이트를 위한 컨테이너 레지스트리를 참조하세요.

현재 주 사이트에서 컨테이너 레지스트리에 로컬 리포지터리를 사용 중이라면, 해당 컨테이너 레지스트리 개체를 장애 조치할 2부 사이트로 rsync할 수 있습니다:

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

또는 주 사이트의 컨테이너 레지스트리를 백업하고 이를 장애 조치할 2부 사이트에 복원할 수 있습니다:

1. 주 사이트에서 레지스트리만 백업하고 백업에서 특정 디렉터리 제외하세요:

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

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

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

사전 점검

다음 명령을 실행하여 계획된 장애 조치를 예약하기 전에 사전 점검 디렉터리을 나열하고 복제 및 확인이 완료되었는지 자동으로 확인하여 과정이 원활하게 진행되도록하세요:

gitlab-ctl promotion-preflight-checks

각 단계는 아래에서 자세히 설명합니다.

DNS TTL

기본 도메인 DNS 레코드를 업데이트할 계획이라면, 빠른 DNS 변경 전파를 보장하기 위해 TTL을 낮게 유지할 수 있습니다.

오브젝트 리포지터리

대규모 GitLab 설치 또는 다운타임을 용인할 수 없는 경우, 계획된 장애 조치를 예약하기 전에 객체 리포지터리로 마이그레이션을 고려해보세요. 이러면 유지 보수 창의 길이와 부실하게 실행된 계획된 장애 조치로 인한 데이터 손실 위험 모두 줄어듭니다.

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

각 2부 사이트의 구성 검토

데이터베이스 설정은 2부 사이트로 자동으로 복제되지만 /etc/gitlab/gitlab.rb 파일은 매뉴얼으로 설정해야 하며, 사이트에 따라 차이가 있습니다. 주 사이트에서 Mattermost, OAuth 또는 LDAP 통합과 같은 기능을 활성화했지만 2부 사이트에서는 비활성화된 경우 장애 조치 중에 해당 기능이 손실됩니다.

양쪽 사이트 모두의 /etc/gitlab/gitlab.rb 파일을 검토하고 계획된 장애 조치를 예약하기 전에 2부 사이트가 주 사이트와 동일한 모든 것을 지원하는지 확인하세요.

시스템 검사 실행

주 사이트 및 2부 사이트에서 다음을 실행하세요:

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 호스트 키 복제를 필요에 따라 2부 사이트에 복제합니다.

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

주 사이트와 주 사이트에서 사용 중인 외부 사이트가 공용 CA에서 발급한 인증서를 사용하는 경우, 이 단계는 안전하게 건너뛸 수 있습니다.

주 사이트가 인바운드 연결을 안전하게 하기 위해 사용자 정의 또는 자체 서명 TLS 인증서를 사용하거나 주 사이트가 사용 중인 외부 서비스가 사용자 정의 또는 자체 서명 인증서를 사용하는 경우, 2부 사이트에도 올바른 인증서를 설치해야 합니다. 2부 사이트에서 사용자 정의 인증서 사용 지침을 따르세요.

Geo 복제가 최신인지 확인

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

2부 사이트에서:

1. 왼쪽 사이드바에서 가장 아래쪽에 위치한 Admin Area를 선택합니다.

2. Geo > Sites를 선택합니다. 복제된 객체(초록색으로 표시)가 100%에 가까운 지 확인하고 실패 사항(빨간색으로 표시)이 없는지 확인하세요. 복제되지 않은 객체(회색으로 표시)의 비율이 높으면 사이트에 더 많은 시간을 할당하는 것을 고려하세요.

   

어떤 객체가 복제되지 않고 있다면, 이는 유지 보수 창을 예약하기 전에 조사되어야 합니다. 계획된 장애 조치 후에 복제에 실패한 모든 항목은 손실됩니다.

실패한 객체 및 실패 원인을 검토하려면 Geo 상태 API를 사용하세요.

복제 실패의 일반적인 원인은 주 사이트에서 데이터가 누락된 것입니다. 이러한 실패를 해결하려면 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거하세요.

복제된 데이터의 무결성 검사

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

예정된 유지 관리 작업 알림 사용자입니다

기본 사이트에서:

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

러너 장애 조치

인스턴스 URL 구성에 따라 장애 조치 후 러너 플릿을 100% 유지하는 추가 단계가 있을 수 있습니다.

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

러너가 GitLab 인스턴스에 연결할 수 없는 경우 일정 기간 동안(기본 1시간) 연결을 시도하지 않습니다. 이를 피하고 싶은 경우 러너는 GitLab 인스턴스에 연결 가능할 때까지 종료되어야 합니다. check_interval 문서와 unhealthy_requests_limit, unhealthy_interval 구성 옵션을 참조하세요.

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

기본 사이트에서 업데이트 방지

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

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. 왼쪽 사이드바에서 Monitoring > Background Jobs을 선택합니다.
   3. Sidekiq 대시보드에서 Queues를 선택하고, geo라는 이름을 가진 큐를 제외한 모든 큐가 0이 될 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 포함되어 있으며, 완료되기 전에 장애 조치를 하면 작업이 손실됩니다.

   4. 왼쪽 사이드바에서 Geo > Sites을 선택하고, 장애 조치할 보조 사이트가 다음 조건을 충족할 때까지 기다립니다:

      • 모든 복제 미터가 100% 복제, 0% 실패에 도달했을 때
      • 모든 검증 미터가 100% 검증, 0% 실패에 도달했을 때
      • 데이터베이스 복제 지연이 0ms 일 때
      • Geo 로그 커서가 최신 상태(0개의 이벤트 뒤)일 때
3. 보조 사이트에서:
   1. 왼쪽 사이드바에서 맨 아래에서 관리자 영역을 선택합니다.
   2. 왼쪽 사이드바에서 Monitoring > Background Jobs을 선택합니다.
   3. Sidekiq 대시보드에서 Queues를 선택하고, 모든 geo 큐가 0으로 줄어들고 실행 중인 작업이 없을 때까지 기다립니다.
   4. CI artifact, LFS object 및 파일 스토리지의 무결성을 확인하려면 무결성 검사를 실행하세요.

이 시점에서 보조 사이트에는 기본 사이트에 있는 모든 콘텐츠의 최신 복사본이 포함되어 있으므로 장애 조치 중에 데이터가 손실되지 않았음을 의미합니다.

보조 사이트를 승격

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

승격이 완료되면 유지 관리 창이 종료되고 새 기본 사이트는 이전 사이트와 달라집니다. 이 시점에서 문제가 발생하면 새로운 기본에 업로드된 데이터가 손실될 수 있지만 이전 기본 사이트로 fallback하는 것은 가능하지만 그동안 새 기본에 업로드된 모든 데이터가 손실될 가능성이 높습니다.

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

마지막으로 이전 사이트를 다시 보조로 변경하는 것이 가능합니다.