재해 복구(Geo) 승격 런북.

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

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

기본 사이트(다중 노드):

• Rails 노드 1
• Rails 노드 2
• PostgreSQL 노드
• Gitaly 노드
• Redis 노드
• 모니터링 노드

보조 사이트:

• Rails 노드 1
• Rails 노드 2
• PostgreSQL 노드
• Gitaly 노드
• Redis 노드
• 모니터링 노드

이 가이드의 결과:

1. 오프라인 기본 사이트.
2. 이제 새 기본 사이트가 된 승격된 보조 사이트.

다루지 않는 사항:

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

준비#

보조 사이트에서:

1. 오른쪽 상단 모서리에서 Admin을 선택합니다.

2. 왼쪽 사이드바에서 Geo > Sites를 선택하여 상태를 확인합니다. 복제된 객체(녹색으로 표시)는 100%에 가까워야 하며 실패(빨간색으로 표시)가 없어야 합니다. 많은 비율의 객체가 복제되지 않은 경우(회색으로 표시), 사이트에 더 많은 시간을 주는 것을 고려하세요.

   

복제에 실패하는 객체가 있는 경우, 유지 보수 기간을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후 복제에 실패한 항목은 손실됩니다.

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

유지 보수 기간은 Geo 복제 및 검증이 완전히 완료될 때까지 종료되지 않습니다. 기간을 최대한 짧게 유지하려면 활성 사용 중에 이러한 프로세스를 가능한 100%에 가깝게 유지해야 합니다.

보조 사이트가 여전히 기본 사이트에서 데이터를 복제하고 있는 경우, 불필요한 데이터 손실을 방지하기 위해 다음 단계를 따르세요:

1. 기본 사이트에서 유지 보수 모드를 활성화하고 백그라운드 작업을 중지합니다.

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

   [!warning] 모든 데이터가 자동으로 복제되지는 않습니다. 제외되는 항목에 대해 자세히 읽어보세요.

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

   2. 기본 사이트에서:

      1. 오른쪽 상단 모서리에서 Admin을 선택합니다.

      2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.

      3. Sidekiq 대시보드에서 Queues를 선택하고 이름에 geo가 있는 것을 제외한 모든 큐가 0으로 떨어질 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 포함되어 있으며 완료되기 전에 장애 조치를 수행하면 작업이 손실됩니다.

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

         • 모든 복제 미터가 100% 복제됨, 0% 실패에 도달합니다.
         • 모든 검증 미터가 100% 검증됨, 0% 실패에 도달합니다.
         • 데이터베이스 복제 지연이 0ms입니다.
         • Geo 로그 커서가 최신 상태입니다(0 이벤트 뒤처짐).

   3. 보조 사이트에서:

      1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
      3. Sidekiq 대시보드에서 Queues를 선택하고 모든 geo 큐가 0 대기 및 0 실행 중인 작업으로 떨어질 때까지 기다립니다.
      4. 무결성 검사 실행으로 파일 스토리지의 CI 아티팩트, LFS 객체, 업로드의 무결성을 확인합니다.

   이 시점에서 보조 사이트는 기본 사이트의 모든 것의 최신 복사본을 포함합니다. 이는 장애 조치 시 아무것도 손실되지 않음을 의미합니다.

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

   [!warning] 기본 사이트가 오프라인 상태가 되면 보조 사이트에 복제되지 않은 기본 사이트에 저장된 데이터가 있을 수 있습니다. 진행하면 이 데이터는 손실된 것으로 처리되어야 합니다.

   기본 도메인 DNS 레코드를 업데이트할 계획이라면 전파 속도를 높이기 위해 지금 TTL을 낮추는 것이 좋습니다.

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

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

     sudo gitlab-ctl stop
     

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

     sudo systemctl disable gitlab-runsvdir
     

     [!note]

     • CentOS 6 이하에서는 기계가 재부팅될 경우 GitLab이 시작되는 것을 방지하는 것이 어렵습니다(이슈 3058 참조). sudo yum remove gitlab-ee로 GitLab 패키지를 완전히 제거하는 것이 가장 안전할 수 있습니다.
     • 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 레코드를 보조 사이트로 지정하여 기본 사이트 사용을 중지합니다).
     • 가상 서버를 중지합니다.
     • 방화벽을 통해 트래픽을 차단합니다.
     • 기본 사이트에서 객체 스토리지 권한을 취소합니다.
     • 기계를 물리적으로 분리합니다.

보조 사이트 승격#

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. 성공하면 보조 사이트가 이제 기본 사이트로 승격됩니다.

다음 단계#

지리적 중복성을 최대한 빨리 회복하려면 새 보조 사이트를 추가해야 합니다. 이를 위해 이전 기본을 새 보조로 다시 추가하고 온라인 상태로 만들 수 있습니다.