• 멀티 노드 구성을 위한 Geo 계획된 장애 조치
  • 준비 작업
  • secondary 사이트 프로모션
  • 다음 단계

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

멀티 노드 구성을 위한 Geo 계획된 장애 조치

이 실행북은 하나의 보조가 있는 멀티 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 다음의 40 RPS / 2,000 사용자 기준 아키텍처를 가정합니다.

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

이 안내서는 다음과 같은 결과를 가져옵니다:

1. 오프라인 주 사이트.
2. 이제 새로운 주 사이트인 승격된 보조.

다루지 않는 사항:

1. 이전 주를 다시 보조로 추가하는 것.
2. 새로운 보조 추가하는 것.

준비 작업

보조 사이트에서:

1. 왼쪽 사이드바에서 아래쪽에서 관리 영역을 선택하세요.

2. Geo > 사이트를 선택하여 상태를 확인합니다. 복제된 객체(녹색으로 표시됨)는 거의 100%에 가까워야 하고, 실패가 없어야 합니다(빨간색으로 표시됨). 대다수의 객체가 복제되지 않은 경우(회색으로 표시됨), 사이트가 완료될 때까지 시간을 더 주는 것을 고려하세요.

   

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

   현재 노드에서 복제에 실패한 객체와 실패 원인을 검토하기 위해 Geo 상태 API를 사용할 수 있습니다. 복제 실패의 일반적인 원인은 주 사이트에서 누락된 데이터입니다. 이러한 실패는 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거함으로써 해결할 수 있습니다.

   유지 보수 창은 Geo 복제 및 확인이 완전히 완료될 때까지 종료되지 않습니다. 창을 가능한 한 짧게 유지하기 위해 이러한 프로세스가 사용 중에 100%에 가까워지는 것을 보장해야 합니다.

   보조 사이트가 주 사이트로부터 여전히 데이터를 복제하는 경우, 불필요한 데이터 손실을 피하기 위해 다음 단계를 따르세요:

   1. 주 사이트에 유지 보수 모드를 활성화하고 모든 백그라운드 작업을 중지하는 등의 작업을 수행하세요.

   2. 모든 데이터의 복제 및 확인을 마칩니다:

      모든 데이터가 자동으로 복제되는 것은 아닙니다. 제외되는 내용에 대해 자세히 읽어보세요.
      1. Geo가 관리하지 않는 데이터를 매뉴얼으로 복제하고 있다면, 최종 복제 프로세스를 시작하세요.
      2. 주 사이트에서:
         1. 왼쪽 사이드바에서 아래쪽에서 관리 영역을 선택하세요.
         2. 왼쪽 사이드바에서 Monitoring > 백그라운드 작업을 선택하세요.
         3. Sidekiq 대시보드에서 Queues를 선택하고, geo가 포함된 대기열 이외에는 모두 0이 될 때까지 기다리세요. 이러한 대기열은 사용자가 제출한 작업을 포함하며, 완료되기 전에 장애 조치를 수행하면 작업이 손실됩니다.

         4. 왼쪽 사이드바에서 Geo > 사이트를 선택하고, 이동할 보조 사이트에 대해 다음 조건이 충족되도록 기다리세요:

            • 모든 복제 미터가 100% 복제, 0% 실패에 도달합니다.
            • 모든 확인 미터가 100% 확인, 0% 실패에 도달합니다.
            • 데이터베이스 복제 래그가 0 ms입니다.
            • Geo 로그 커서가 최신 상태(이벤트 0개 미만)라면.
      3. 보조 사이트에서:
         1. 왼쪽 사이드바에서 아래쪽에서 관리 영역을 선택하세요.
         2. 왼쪽 사이드바에서 Monitoring > 백그라운드 작업을 선택하세요.
         3. Sidekiq 대시보드에서 Queues를 선택하고, 모든 geo 대기열이 0개의 대기 및 실행 중인 작업을 가질 때까지 기다리세요.
         4. 무결성 검사를 실행하여 CI artifacts, LFS objects, 및 파일 리포지터리에 대한 무결성을 확인하기 위해 integrity check를 실행합니다.

   이 시점에서 보조 사이트에는 주 사이트의 최신 사본이 포함되어 있으므로 장애 조치 시 아무것도 손실되지 않습니다.

3. 이 마지막 단계에서는 주 사이트를 영구적으로 사용하지 못하도록 설정해야 합니다.

   주 사이트가 오프라인 상태가 되면, 주 사이트에 저장된 데이터가 보조 사이트로 복제되지 않은 경우가 있습니다. 이 경우 진행하면 데이터는 손실되어야 합니다.
   주 도메인 DNS 레코드를 업데이트할 계획이라면, 지금 TTL을 낮출 수 있습니다.

   장애 조치를 수행할 때, 두 개의 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 스플릿 브레인 상황을 피하려면, 주 사이트를 사용하지 못하도록 설정해야 합니다:

   • 주 사이트에 SSH 액세스가 있는 경우, GitLab을 중지 및 사용하지 못하도록 설정하세요:

     sudo gitlab-ctl stop
     

     서버가 예상치 못하게 다시 부팅되면 GitLab이 다시 시작되지 않도록 방지하세요:

     sudo systemctl disable gitlab-runsvdir
     

     (CentOS 전용) CentOS 6 이하 버전에서는 프로그램이 재부팅되지 않도록 하는 것이 어려울 수 있습니다(issue 3058 참조). sudo yum remove gitlab-ee를 사용하여 GitLab 패키지를 완전히 제거하는 것이 가장 안전할 수 있습니다.
     (Ubuntu 14.04 LTS 전용) 이전 버전의 Ubuntu 또는 Upstart init 시스템에 기반한 기타 배포판을 사용하면 root로 initctl stop gitlab-runsvvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configuration와 같이 하면 기계가 재부팅될 때 GitLab을 시작하지 못하도록 설정할 수 있습니다.

   • 주 사이트에 SSH 액세스권이 없는 경우, 해당 기계를 오프라인 상태로 전환하고 재부팅이 되지 않도록 설정하세요. 이를 수행하는 여러 가지 방법이 있으므로 특정 권장사항은 없습니다. 다음과 같은 여러 방법을 사용할 수 있습니다.

     • 로드 밸런서 재구성
     • DNS 레코드 변경(예: 주 DNS 레코드를 보조 사이트를 가리키게 변경하여 주 사이트를 사용하지 않게 함)
     • 가상 서버 중지
     • 방화벽을 통한 트래픽 차단
     • 주 사이트에서 오브젝트 스토리지 권한 취소
     • 기계의 물리적 연결 끊기

secondary 사이트 프로모션

1. secondary 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH를 하고 다음 명령 중 하나를 실행합니다:

   • secondary 사이트를 기본 사이트로 프로모션:

     sudo gitlab-ctl geo promote
     

   • secondary 사이트를 기본 사이트로 추가 확인 없이 프로모션:

     sudo gitlab-ctl geo promote --force
     

2. secondary 사이트의 각 Rails 노드에 SSH를 하고 다음 명령 중 하나를 실행합니다:

   • secondary 사이트를 기본 사이트로 프로모션:

     sudo gitlab-ctl geo promote
     

   • secondary 사이트를 기본 사이트로 추가 확인 없이 프로모션:

     sudo gitlab-ctl geo promote --force
     

3. 이전에 secondary 사이트에 사용했던 URL로 새로 프로모션된 primary 사이트에 연결할 수 있는지 확인합니다.

4. 성공적으로 연결되면 secondary 사이트가 이제 primary 사이트로 프로모션이 완료됩니다.

다음 단계

지리적 재복구를 최대한 빨리 수행하기 위해 새로운 secondary 사이트를 추가해야 합니다. 이를 위해 이전 primary를 새로운 secondary로 다시 추가하고 온라인으로 돌려야 합니다. 여기를 클릭하여 자세히 알아보세요.