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

단일 노드 구성의 Geo 계획된 장애 조치#

이 런북은 보조 사이트가 하나인 단일 노드 Geo 사이트의 계획된 장애 조치 과정을 안내합니다. 다음과 같은 일반적인 아키텍처를 가정합니다.

기본 사이트:

• GitLab 노드

보조 사이트:

• GitLab 노드

이 안내의 결과는 다음과 같습니다.

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

다루지 않는 내용은 다음과 같습니다.

1. 기존 기본 사이트를 보조 사이트로 다시 추가하는 방법.
2. 새 보조 사이트를 추가하는 방법.

준비#

보조 사이트에서 Admin area > Geo 대시보드로 이동해 상태를 확인합니다. 복제된 오브젝트(녹색 표시)는 100% 에 가까워야 하며, 실패(빨간색 표시)가 없어야 합니다. 아직 복제되지 않은 오브젝트(회색 표시)의 비중이 크다면 사이트에 시간을 더 주는 편이 좋습니다.

복제에 실패하는 오브젝트가 있다면 유지 관리 시간을 잡기 전에 원인을 조사해야 합니다. 계획된 장애 조치 이후에는 복제되지 않은 데이터가 모두 유실됩니다.

복제 실패의 흔한 원인은 기본 사이트에 데이터가 없는 경우입니다. 이런 실패는 백업에서 데이터를 복원하거나, 없는 데이터에 대한 참조를 제거해 해결할 수 있습니다.

Geo 복제와 검증이 완전히 끝날 때까지 유지 관리 시간은 끝나지 않습니다. 유지 관리 시간을 최대한 짧게 유지하려면 평상시 운영 중에도 이 과정이 100% 에 가깝게 유지되도록 관리합니다.

보조 사이트가 아직 기본 사이트에서 데이터를 복제 중이라면, 불필요한 데이터 유실을 막기 위해 다음 단계를 따릅니다.

1. 읽기 전용 모드가 구현되기 전까지는 기본 사이트에 대한 업데이트를 수동으로 차단해야 합니다. 유지 관리 시간 동안에도 보조 사이트는 기본 사이트에 대한 읽기 전용 액세스가 필요합니다.

   1. 예정된 시각에 클라우드 공급자나 사이트 방화벽을 사용해, 본인 IP와 보조 사이트 IP를 제외한 모든 HTTP, HTTPS, SSH 트래픽을 기본 사이트와 주고받지 못하도록 차단합니다.

      예를 들어 기본 사이트에서 다음 명령을 실행할 수 있습니다.

      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 22 -j ACCEPT
      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
      sudo iptables -A INPUT --destination-port 22 -j REJECT
      
      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 80 -j ACCEPT
      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT
      sudo iptables -A INPUT --tcp-dport 80 -j REJECT
      
      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 443 -j ACCEPT
      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT
      sudo iptables -A INPUT --tcp-dport 443 -j REJECT
      

      이 시점부터 사용자는 기본 사이트에서 데이터를 보거나 변경할 수 없습니다. 보조 사이트에 로그인할 수도 없습니다. 다만 기존 세션은 남은 유지 관리 기간 동안 동작해야 하므로, 공개 데이터는 그동안에도 접근할 수 있습니다.

   2. 다른 IP에서 브라우저로 접속해 기본 사이트의 HTTP 트래픽이 차단되었는지 확인합니다. 서버가 연결을 거부해야 합니다.

   3. SSH 원격 URL로 기존 Git 리포지터리를 가져와 보며 기본 사이트의 SSH 기반 Git 트래픽이 차단되었는지 확인합니다. 서버가 연결을 거부해야 합니다.

   4. 기본 사이트에서 다음을 수행합니다.

      1. 오른쪽 상단에서 Admin을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
      3. Sidekiq 대시보드에서 Cron을 선택합니다.
      4. Disable All을 선택해 Geo 이외의 주기적 백그라운드 job을 비활성화합니다.
      5. geo_sidekiq_cron_config_worker cron job에 대해 Enable을 선택합니다. 이 job은 계획된 장애 조치를 성공적으로 완료하는 데 필수인 여러 cron job을 다시 활성화합니다.

2. 모든 데이터의 복제와 검증을 완료합니다.

   [!warning] 모든 데이터가 자동으로 복제되지는 않습니다. 자세한 내용은 제외 대상을 참고합니다.

   1. Geo가 관리하지 않는 데이터를 직접 복제하고 있다면, 지금 마지막 복제 과정을 실행합니다.

   2. 기본 사이트에서 다음을 수행합니다.

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

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

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

      4. 왼쪽 사이드바에서 Geo > Sites를 선택하고, 장애 조치 대상 보조 사이트가 다음 조건을 모두 충족할 때까지 기다립니다.

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

   3. 보조 사이트에서 다음을 수행합니다.

      1. 오른쪽 상단에서 Admin을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
      3. Sidekiq 대시보드에서 Queues를 선택하고, 모든 geo 큐의 대기 job과 실행 job 이 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 패키지를 완전히 제거하는 편이 가장 안전합니다.
     • Ubuntu 14.04 LTS처럼 오래된 버전이나 Upstart init 시스템 기반의 다른 배포판을 사용한다면, root로 initctl stop gitlab-runsvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configuration 를 실행해 머신 재부팅 시 GitLab 이 시작되지 않도록 할 수 있습니다.

   • 기본 사이트에 SSH로 접속할 수 없다면 머신을 오프라인으로 만들고 재부팅되지 않도록 합니다. 방법이 여러 가지이므로 하나만 권장하지는 않습니다. 다음과 같은 조치가 필요할 수 있습니다.

     • 로드 밸런서를 재구성합니다.
     • DNS 레코드를 변경합니다(예: 기본 사이트 사용을 중단하도록 기본 DNS 레코드가 보조 사이트를 가리키게 합니다).
     • 가상 서버를 중지합니다.
     • 방화벽으로 트래픽을 차단합니다.
     • 기본 사이트의 오브젝트 스토리지 권한을 회수합니다.
     • 머신을 물리적으로 분리합니다.

보조 사이트 승격#

보조 사이트를 승격할 때는 다음을 유의합니다.

• 이 시점에 새 보조 사이트를 추가하지 않습니다. 새 보조 사이트를 추가하려면 보조 사이트를 기본 사이트로 승격하는 전체 과정을 마친 뒤에 진행합니다.
• 이 과정에서 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류가 발생하면 문제 해결 안내를 참고합니다.

보조 사이트를 승격하려면 다음 단계를 따릅니다.

1. 보조 사이트에 SSH로 접속해 다음 명령 중 하나를 실행합니다.

   • 보조 사이트를 기본 사이트로 승격하려면 다음을 실행합니다.

     sudo gitlab-ctl geo promote
     

   • 추가 확인 없이 보조 사이트를 기본 사이트로 승격하려면 다음을 실행합니다.

     sudo gitlab-ctl geo promote --force
     

2. 이전에 보조 사이트에 사용하던 URL로 새로 승격된 기본 사이트에 접속할 수 있는지 확인합니다.

   접속에 성공하면 보조 사이트가 기본 사이트로 승격된 것입니다.

다음 단계#

지리적 이중화를 최대한 빨리 회복하려면 새 보조 사이트를 추가합니다. 이때 기존 기본 사이트를 새 보조 사이트로 다시 추가해 온라인 상태로 되돌릴 수 있습니다.