• 다중 노드 구성을 위한 Geo 계획된 장애 조치
  • 준비
  • 보조 사이트 홍보
  • 다음 단계

재해 복구 (Geo) 프로모션 런북

재해 복구 (Geo) 프로모션 런북.

경고: 이 런북은 실험입니다. 완전하고 프로덕션에 준비된 문서를 보려면 다음을 참조하십시오. 재해 복구 문서.

다중 노드 구성을 위한 Geo 계획된 장애 조치

이 런북은 보조가 하나 있는 다중 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 다음의 40 RPS / 2,000 사용자 참조 아키텍처가 가정됩니다:

로드 밸런서 노드와 선택 사항인 NFS 서버는 명확히 하기 위해 생략되었습니다.

이 안내서는 다음을 포함합니다:

1. 오프라인 기본 사이트
2. 이제 새 기본이 된 프로모션된 보조

다루지 않는 내용:

1. 이전 기본을 보조로 다시 추가하는 것
2. 새로운 보조 추가

준비

참고: 이러한 단계 중 어떤 것이든 따르기 전에, 보조(secondary)를 프로모션하려면 root 액세스가 있는지 확인하십시오. 왜냐하면 Geo 복제본을 프로모션하고 장애 조치를 수행하는 자동화된 방법이 제공되지 않았기 때문입니다.

보조 사이트에서:

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

2. 상태를 보려면 Geo > 사이트를 선택합니다. 복제된 객체(녹색으로 표시됨)는 100%에 가까워야 하고, 실패한 항목(빨간색으로 표시됨)이 없어야 합니다. 만약 객체의 많은 비율이 복제되지 않았다면(회색으로 표시됨), 사이트가 완료되기까지의 시간을 더 주는 것을 고려하십시오.

   

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

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

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

   보조 사이트가 여전히 기본 사이트에서 데이터를 복제 중이라면, 불필요한 데이터 손실을 피하려면 다음 단계를 따르십시오:

   1. 기본 사이트에서 유지보수 모드를 활성화하고, 모든 백그라운드 작업을 중지했는지 확인합니다.
   2. 모든 데이터를 성공적으로 복제 및 확인:

   경고: 모든 데이터가 자동으로 복제되는 것은 아닙니다. 자동으로 복제되지 않는 것에 대해 자세히 알아보세요.

   1. 수동으로 복제 중인 경우 Geo에서 관리되지 않는 데이터를 트리거하여 최종 복제 프로세스를 시작하십시오.

   2. 기본 사이트에서:

      1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
      2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
      3. Sidekiq 대시보드에서 대기열(Queues)을 선택하고, geo라는 이름을 가진 대기열을 제외한 모든 대기열이 0이 되길 기다립니다. 이러한 대기열에는 사용자가 제출한 작업이 포함되어 있으며, 완료되기 전에 장애 조치가 발생하면 작업이 손실됩니다.
      4. 왼쪽 사이드바에서 Geo > 사이트를 선택하고, 장애 조치하려는 보조 사이트에 대해 다음 조건이 참이 될 때까지 기다립니다:
         • 모든 복제 미터가 100% 복제되고, 0% 실패.
         • 모든 검증 미터가 100% 확인되고, 0% 실패.
         • 데이터베이스 복제 지연이 0ms.
         • Geo 로그 커서가 최신 상태 (이벤트가 0개 뒤쳐지지 않음).
   3. 보조 사이트에서:
      1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
      2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
      3. Sidekiq 대시보드에서 대기열(Queues)을 선택하고, geo 대기열이 0으로 줄어들고 실행 중인 작업이 없도록 기다립니다.
      4. 무결성 확인을 실행하여 CI 아티팩트, LFS 객체, 및 파일 저장소에 업로드의 무결성을 검증합니다.

   이 시점에서 보조 사이트는 기본 사이트에서 가지고 있는 모든 것의 최신 사본을 포함하고 있으므로 장애 조치하는 동안 아무것도 손실되지 않습니다.

3. 최종 단계에서는 기본 사이트를 영구적으로 비활성화해야 합니다.

   경고: 기본 사이트가 오프라인되면, 기본 사이트에 저장된 데이터 중 보조 사이트로 복제되지 않은 데이터가 있을 수 있습니다. 이 경우, 진행한다면 이 데이터는 손실되었다고 간주해야 합니다.

   참고: 기본 도메인 DNS 레코드 업데이트를 계획하면 이제 TTL을 낮출 것을 권장할 수 있습니다.

   장애 조치를 수행할 때 우리는 두 가지 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 분리된 브레인 상황을 피하려고 합니다. 따라서, 장애 조치를 준비하기 위해 기본 사이트를 비활성화해야 합니다:

   • 기본 사이트에 SSH 액세스가 있다면 GitLab을 중지하고 비활성화합니다:

     sudo gitlab-ctl stop
     

     서버가 예기치 않게 다시 부팅될 경우 GitLab이 다시 시작되지 않도록 방지합니다:

     sudo systemctl disable gitlab-runsvdir
     

     참고: (CentOS 전용) CentOS 6 또는 이전 버전에서는 서버가 다시 부팅되었을 때 GitLab이 시작되는 것을 예방하는 것이 어려울 수 있습니다(참조: issue 3058). sudo yum remove gitlab-ee를 사용하여 GitLab 패키지를 완전히 제거하는 것이 안전할 수 있습니다.

     참고: (Ubuntu 14.04 LTS) 구 버전의 Ubuntu나 Upstart 초기화 시스템을 기반으로 한 다른 배포판을 사용 중이라면, 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. 성공하면, 보조 사이트가 이제 기본 사이트로 홍보되었습니다.

다음 단계

지리적 재해 복구를 빠르게 수행하기 위해 새로운 보조 사이트를 추가해야 합니다. 그렇게 하려면 이전 기본을 새로운 보조로 다시 추가하고 온라인으로 돌려야 합니다.