• 다중 노드 구성의 Geo 계획된 장애 조치
  • 준비
  • 보조 사이트 프로모션
  • 다음 단계

재해 복구(Geo) 프로모션 실행 매뉴얼

재해 복구(Geo) 프로모션 실행 매뉴얼.

다중 노드 구성의 Geo 계획된 장애 조치

이 실행 매뉴얼은 하나의 세컨더리가 있는 다중 노드 Geo 사이트의 계획된 장애 조치를 안내합니다.

다음 40 RPS / 2,000 사용자 참조 아키텍처가 가정됩니다:

로드 밸런서 노드와 선택적 NFS 서버는 명확성을 위해 생략되었습니다.

이 가이드는 다음과 같은 결과를 가져옵니다:

1. 오프라인 상태의 주.
2. 새로운 주가 된 승격된 세컨더리.

다루지 않는 내용:

1. 이전 주를 세컨더리로 다시 추가하기.
2. 새로운 세컨더리 추가하기.

준비

세컨더리 사이트에서:

1. 왼쪽 사이드바에서 아래로 스크롤하여 Admin를 선택합니다.

2. Geo > Sites를 선택하여 상태를 확인합니다.
   복제된 객체(초록색으로 표시)는 100%에 가까워야 하며,
   실패가 없어야 합니다(빨간색으로 표시됨).
   많은 비율의 객체가 복제되지 않으면(회색으로 표시됨), 사이트가 완료되는 데 더 많은 시간을 주어야 합니다.

   

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

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

유지 관리 창은 Geo 복제 및 검증이 완료될 때까지 끝나지 않습니다.
가능한 한 짧게 유지 관리 창을 유지하려면 활동 중에 이러한 프로세스가 100%에 가깝도록 해야 합니다.

세컨더리 사이트가 여전히 주 사이트에서 데이터를 복제하고 있다면,
불필요한 데이터 손실을 방지하기 위해 다음 단계를 따르세요:

1. 주 사이트에서 유지 관리 모드를 활성화하고,
   모든 백그라운드 작업을 중지합니다.

2. 모든 데이터를 복제하고 검증을 완료합니다:

   모든 데이터가 자동으로 복제되지는 않습니다.
   제외되는 사항에 대해 더 읽어보세요.
   1. 수동으로 복제 중인
      Geo에 의해 관리되지 않는 데이터가 있는 경우,
      지금 최종 복제 프로세스를 트리거하십시오.
   2. 주 사이트에서:
      1. 왼쪽 사이드바에서 아래로 스크롤하여 Admin을 선택합니다.
      2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
      3. Sidekiq 대시보드에서 큐를 선택하고,
         geo라는 이름이 없는 모든 큐가 0으로 떨어질 때까지 기다립니다.
         이러한 큐에는 사용자에 의해 제출된 작업이 포함되어 있으며,
         완료되기 전에 장애 조치를 수행하면 작업이 손실됩니다.

      4. 왼쪽 사이드바에서 Geo > Sites를 선택하고,
         세컨더리 사이트가 다음 조건을 만족할 때까지 기다립니다:

         • 모든 복제 미터가 100% 복제됨, 0% 실패.
         • 모든 검증 미터가 100% 검증됨, 0% 실패.
         • 데이터베이스 복제 지연은 0ms입니다.
         • Geo 로그 커서가 최신 상태입니다(이벤트가 0개 뒤처짐).
   3. 세컨더리 사이트에서:
      1. 왼쪽 사이드바에서 아래로 스크롤하여 Admin을 선택합니다.
      2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
      3. Sidekiq 대시보드에서 큐를 선택하고,
         모든 geo 큐가 대기 0개 및 실행 중인 작업 0개로 떨어질 때까지 기다립니다.
      4. 무결성 검사 실행을 통해 CI 아티팩트, LFS 객체 및 파일 저장소의 업로드 무결성을 검증합니다.

   이 시점에서 세컨더리 사이트는 주 사이트에 있는 모든 것의 최신 복사본을 포함하므로
   장애 조치 시 손실되는 데이터가 없습니다.

3. 마지막 단계에서, 주 사이트를 영구적으로 비활성화해야 합니다.

   주 사이트가 오프라인 상태가 되면, 그곳에 복제되지 않은 데이터가
   주 사이트에 저장되어 있을 수 있습니다.
   이 데이터는 진행할 경우 손실된 것으로 간주해야 합니다.
   주 도메인 DNS 레코드를 업데이트할 계획이 있다면,
   전파 속도를 높이기 위해 지금 TTL을 낮추는 것이 좋습니다.

   장애 조치를 수행할 때, 두 개의 다른 GitLab 인스턴스에서 작성을 방지하기 위해
   스플릿 브레인 상황을 피하려고 합니다.
   따라서 장애 조치를 준비하기 위해 주 사이트를 비활성화해야 합니다:

   • 주 사이트에 대한 SSH 액세스가 있는 경우, GitLab을 중지하고 비활성화합니다:

     sudo gitlab-ctl stop
     

     서버가 예기치 않게 재부팅되는 경우 GitLab이 다시 시작되는 것을 방지합니다:

     sudo systemctl disable gitlab-runsvdir
     

     (CentOS 전용) CentOS 6 또는 이전 버전에서는
     기계가 재부팅될 때 GitLab이 시작되지 않도록 하는 것이 어렵습니다
     (자세한 내용은 문제 3058 참조).
     가장 안전한 방법은 GitLab 패키지를 완전히 제거하는 것입니다
     sudo yum remove gitlab-ee를 사용하여.
     (Ubuntu 14.04 LTS) 이전 버전의 Ubuntu를 사용 중이거나
     Upstart init 시스템에 기반한 다른 배포판을 사용하는 경우,
     기계가 root로 재부팅될 때 GitLab이 시작되는 것을 방지할 수 있습니다
     initctl stop gitlab-runsvvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configuration를 사용하여.

   • 주 사이트에 대한 SSH 액세스가 없는 경우, 기계를 오프라인 상태로 만들고
     재부팅을 방지해야 합니다. 이를 수행하는 방법은 여러 가지가 있으므로
     단일 권장 사항을 피합니다. 다음을 수행해야 할 수 있습니다:

     • 로드 밸런서를 재구성하십시오.
     • DNS 레코드를 변경합니다 (예: 주 DNS 레코드를 세컨더리 사이트로
       포인팅하여 주 사이트의 사용을 중지합니다).
     • 가상 서버를 중지하십시오.
     • 방화벽을 통해 트래픽을 차단하십시오.
     • 주 사이트의 오브젝트 스토리지 권한을 취소하십시오.
     • 물리적으로 기계를 분리하십시오.

보조 사이트 프로모션

1. 보조 사이트의 모든 Sidekiq, PostgreSQL, Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:

   • 보조 사이트를 주 사이트로 프로모션하려면:

     sudo gitlab-ctl geo promote
     

   • 추가적인 확인 없이 보조 사이트를 주 사이트로 프로모션하려면:

     sudo gitlab-ctl geo promote --force
     

2. 보조 사이트의 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:

   • 보조 사이트를 주 사이트로 프로모션하려면:

     sudo gitlab-ctl geo promote
     

   • 추가적인 확인 없이 보조 사이트를 주 사이트로 프로모션하려면:

     sudo gitlab-ctl geo promote --force
     

3. 새롭게 프로모션된 주 사이트에 이전에 보조 사이트에 사용했던 URL을 사용하여 연결할 수 있는지 확인합니다.

4. 성공하면, 보조 사이트가 이제 주 사이트로 프로모션되었습니다.

다음 단계

지리적 중복성을 가능한 빠르게 회복하기 위해, 새 보조 사이트를 추가해야 합니다. 이를 위해 이전 주 사이트를 새 보조 사이트로 다시 추가하고 온라인으로 복원할 수 있습니다.