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

계획된 장애 복구를 위한 재해 복구

재해 복구의 주요 사용 사례는 예기치 않은 중단 사태가 발생할 경우 비즈니스 지속성을 보장하는 것입니다. 그러나 계획된 장애 조치와 함께 사용하여 GitLab 인스턴스를 지역 간에 연장된 다운타임 없이 마이그레이션할 수 있습니다.

Geo 사이트 간의 복제가 비동기식으로 이루어지기 때문에, 계획된 장애 조치를 위해서는 주 사이트에 대한 업데이트가 차단되는 유지 관리 시간이 필요합니다. 이 시간의 길이는 복제 용량에 따라 결정됩니다. 보조 사이트가 주 사이트와 완전히 동기화되면 데이터 손실 없이 장애 조치를 수행할 수 있습니다.

이 문서는 귀하가 이미 완전히 구성되고 작동하는 Geo 설정을 가지고 있다고 가정합니다. 이 문서와 Disaster Recovery 장애 조치 문서를 모두 읽은 후 진행하십시오. 계획된 장애 조치는 중요한 작업이며, 잘못 수행될 경우 데이터 손실의 위험이 높습니다. 필요한 단계를 수행하는 데 편안함을 느끼고 이를 정확하게 수행할 수 있는 높은 신뢰도를 가질 때까지 절차를 리허설하는 것을 고려하십시오.

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

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. 주 사이트에서 생성된 백업 tarball을 보조 사이트의 /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. 왼쪽 사이드바에서 맨 아래의 Admin을 선택합니다.

2. Geo > Sites를 선택합니다. 복제된 객체(녹색으로 표시)는 100%에 가까워야 하며, 실패(빨간색으로 표시)가 없어야 합니다.

   아직 복제되지 않은 큰 수의 객체(회색으로 표시)가 있다면, 사이트가 완료할 수 있는 더 많은 시간을 주는 것을 고려하세요.

   

복제 실패가 있는 객체가 있다면, 유지 관리 윈도우를 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후, 복제에 실패한 것들은 손실됩니다.

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

복제 데이터의 무결성 확인

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

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

주 사이트에서:

1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.

2. Messages를 선택합니다.

3. 유지 보수 창에 대한 사용자 알림 메시지를 추가합니다.

   Geo > Sites에서 동기화 완료하는 데 걸리는 시간을 확인할 수 있습니다.

4. Add broadcast message를 선택합니다.

러너 페일오버

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

러너를 등록하는 데 사용된 토큰은 주 인스턴스 또는 보조 인스턴스에서 작동해야 합니다. 페일오버 후 연결 문제를 경험하고 있다면, 비밀 키가 보조 구성 동안 복사되지 않았을 수 있습니다. 그러나 러너 토큰을 재설정할 수 있지만 비밀 키가 동기화되지 않으면 러너와 관련 없는 다른 문제를 경험할 수 있습니다.

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

• 우리의 위치 인식 URL를 사용하는 경우, 오래된 주(primary)가 DNS 구성에서 제거된 후, 러너는 자동으로 가장 가까운 인스턴스에 연결해야 합니다.

• 별도의 URL를 사용하는 경우, 현재 주(primary)에 연결된 모든 러너는 승격된 후 새 주(primary)에 연결하도록 업데이트해야 합니다.

• 현재 보조 인스턴스에 연결된 러너가 있는 경우, 페일오버 중에 처리 방법을 확인하세요.

주 사이트에 대한 업데이트 방지

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

1. 주 사이트에서 유지 보수 모드를 활성화합니다.

2. 왼쪽 사이드바 하단에서 Admin을 선택합니다.

3. 모니터링 > 백그라운드 작업을 선택합니다.

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

5. Disable All을 선택하여 비-Geo 주기적 백그라운드 작업을 비활성화합니다.

6. 다음 크론 작업에 대해 Enable을 선택합니다:

   • geo_metrics_update_worker
   • geo_prune_event_log_worker
   • geo_verification_cron_worker
   • repository_check_worker

   이는 계획된 페일오버가 성공적으로 완료되기 위해 필수적인 여러 크론 작업을 다시 활성화합니다.

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

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

2. 주 사이트에서:

   1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.

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

   3. Sidekiq 대시보드에서 Queues를 선택하고 geo라는 이름을 제외한 모든 큐가 0으로 떨어질 때까지 기다립니다.

      이러한 큐에는 사용자가 제출한 작업이 포함되어 있으며, 완료되기 전에 페일오버하면 작업이 손실됩니다.

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

      • 모든 복제 미터가 100% 복제되고, 실패율이 0%입니다.
      • 모든 검증 미터가 100% 검증되고, 실패율이 0%입니다.
      • 데이터베이스 복제 대기시간이 0ms입니다.
      • Geo 로그 커서가 최신 상태입니다(0 이벤트 지연).

3. 보조 사이트에서:

   1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.

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

   3. Sidekiq 대시보드에서 Queues를 선택하고 모든 geo 큐가 대기 상태 0 및 실행 중인 작업 0이 될 때까지 기다립니다.

   4. 무결성 검사를 실행하여 CI 아티팩트, LFS 객체 및 파일 저장소의 업로드 무결성을 검증합니다.

이 시점에서 귀하의 보조 사이트는 주 사이트가 가지고 있는 모든 것의 최신 복사본을 포함하므로, 페일오버 시 손실된 것은 없습니다.

2차 사이트 승격

복제가 완료된 후, 2차 사이트를 1차 사이트로 승격하세요. 이 과정은 2차 사이트에서 잠깐의 중단을 발생시키며, 사용자는 다시 로그인해야 할 수도 있습니다. 단계를 올바르게 따르면, 이전의 1차 Geo 사이트는 여전히 비활성화되어 있어야 하며 사용자 트래픽은 새로 승격된 사이트로 이동해야 합니다.

승격이 완료되면 유지 관리 창이 종료되고, 새로운 1차 사이트가 이전의 사이트와 분기하기 시작합니다. 이 시점에서 문제가 발생하면, 이전 1차 사이트로 되돌릴 수 있습니다, 그러나 그 과정에서 새 1차 사이트에 업로드된 데이터가 손실될 가능성이 높습니다.

Failover가 완료된 후 방송 메시지를 제거하는 것을 잊지 마세요.

마지막으로, 이전 사이트를 2차 사이트로 복원할 수 있습니다.