경고: 이런 방식의 런북은 실험입니다. 완전하고 운영 준비가된 문서를 보려면 재해 복구 문서를 참조하세요.

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

Tier: Premium, Ultimate Offering: Self-managed

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

구성 요소 구성
PostgreSQL Linux 패키지로 관리됨
Geo 사이트 단일 노드
보조 노드 1개

이 런북은 한 개의 보조 노드를 가진 단일 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 다음과 같은 일반적인 구축을 전제로 합니다:

graph TD subgraph main[Geo 배포] subgraph Primary[주 서버] Node_1[(GitLab 노드)] end subgraph Secondary1[보조 서버] Node_2[(GitLab 노드)] end end

이 안내는 다음과 같은 결과를 초래합니다:

  1. 주 서버가 오프라인 상태가 됩니다.
  2. 프로모션된 보조 서버가 새로운 주 서버가 됩니다.

다루지 않는 내용:

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

준비

주의: 이러한 단계 중 하나를 따르기 전에, Geo 복제본을 프로모션하고 장애 조치를 수행하는 자동화된 방법이 제공되지 않으므로, 보조root 액세스가 있는지 확인하세요.

보조 사이트에서 관리자 영역 > Geo 대시보드로 이동하여 상태를 확인하세요. 복제된 개체(녹색으로 표시됨)는 거의 100%에 가까워야 하며, 실패한 사항(빨간색으로 표시됨)이 없어야 합니다. 아직 복제되지 않은 개체의 비율(회색으로 표시됨)이 크다면 사이트가 완료될 때까지 시간을 할애하는 것이 좋습니다.

Replication status

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

현재 노드에서 실패한 객체 및 실패 이유에 대해 확인하려면 Geo 상태 API를 사용할 수 있습니다. 복제 실패의 일반적인 원인은 데이터가 사이트에 없는 경우입니다. 빈번한 이 실패를 복원하기 위해 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 삭제할 수 있습니다.

유지 보수 창이 사용 중일 때까지 Geo 복제와 확인이 완전히 끝나지 않습니다. 창을 가능한 짧게 유지하기 위해 이러한 프로세스가 적극적으로 사용 중일 때 100%에 가까워야 합니다.

보조 사이트가 아직 사이트에서 데이터를 복제 중이라면 다음 단계를 수행하여 불필요한 데이터 손실을 피하세요:

  1. 읽기 전용 모드가 구현될 때까지, 수동으로 에서 업데이트를 방지해야 합니다. 유지 보수 창 동안 보조 사이트는 여전히 사이트에 대한 읽기 전용 액세스가 필요합니다.

    1. 예정된 시간에 클라우드 제공업체 또는 사이트의 방화벽을 사용하여 사이트 간의 모든 HTTP, HTTPS 및 SSH 트래픽을 차단하세요. 이때 당신의 IP 및 보조 사이트의 IP를 제외하십시오.

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

      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. 사이트가 HTTP 트래픽에 대해 차단되어 있는지 브라우저에서 확인합니다. 서버가 연결을 거부해야 합니다.

    3. 사이트가 SSH 트래픽에 대해 차단되었는지 확인하기 위해 기존의 SSH 원격 URL을 통해 기존의 Git 저장소를 가져와 보세요. 서버가 연결을 거부해야 합니다.

    4. 사이트에서:

      1. 왼쪽 사이드바에서 하단에 있는 관리자 영역을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background Jobs를 선택합니다.
      3. Sidekiq 대시보드에서 Cron을 선택합니다.
      4. Disable All을 선택하여 Geo 계획된 장애 조치가 성공적으로 완료되기 위해 필수적인 여러 cron 작업을 비활성화합니다.
  2. 모든 데이터를 복제 및 확인 완료:

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

    1. Geo에서 관리되지 않는 데이터를 수동으로 복제하고 있다면 마지막 복제 프로세스를 트리거하세요.
    2. 사이트에서:
      1. 왼쪽 사이드바에서 하단에 있는 관리자 영역을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background Jobs를 선택합니다.
      3. Sidekiq 대시보드에서 Queues를 선택하고, geo라는 이름을 가진 모든 큐가 0이 될 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 포함되어 있으며, 이 작업이 완료되기 전에 장애 조치를 수행하면 작업이 손실됩니다.
      4. 왼쪽 사이드바에서 Geo > Sites를 선택하고, 장애 조치를 수행하려는 보조 사이트에 대해 다음 조건이 충족될 때까지 기다립니다:

        • 모든 복제 미터가 100% 복제되었고, 0% 실패되었습니다.
        • 모든 확인 미터가 100% 확인되었고, 0% 실패되었습니다.
        • 데이터베이스 복제 지연이 0밀리초입니다.
        • Geo 로그 커서가 최신 상태(이벤트가 뒤쳐져있지 않음)입니다.
    3. 보조 사이트에서:
      1. 왼쪽 사이드바에서 하단에 있는 관리자 영역을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background Jobs를 선택합니다.
      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을 시작하지 않는 쉬운 방법이 없습니다(이슈 3058 참조). sudo yum remove gitlab-ee를 사용하여 GitLab 패키지를 완전히 제거하는 것이 가장 안전합니다.

      참고: (Ubuntu 14.04 LTS 전용) 오래된 버전의 Ubuntu 또는 Upstart init 시스템을 기반으로 한 다른 배포판을 사용 중인 경우 root서버 부팅 시 GitLab을 시작하지 않도록 설정할 수 있습니다.

보조 사이트 홍보

보조 사이트를 홍보할 때 다음 사항을 주의하세요:

  • 새로운 보조를 현재 추가하지 마세요. 새로운 보조를 추가하려면, 보조주요로 홍보하는 전체 프로세스를 완료한 후에 추가하세요.
  • 이 과정 중에 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류가 발생하면 문제 해결 팁을 참조하세요.

GitLab 14.5 이후에 실행 중인 보조 사이트를 홍보하려면:

  1. 보조 사이트에 SSH를 연결하고 다음 명령어 중 하나를 실행하세요:

    • 보조 사이트를 주요로 홍보하려면:

      sudo gitlab-ctl geo promote
      
    • 추가 확인 없이 보조 사이트를 주요로 홍보하려면:

      sudo gitlab-ctl geo promote --force
      
  2. 이전에 보조 사이트에 사용한 URL을 사용하여 새롭게 홍보된 주요 사이트에 연결할 수 있는지 확인하세요.

    성공하면 보조 사이트가 이제 주요 사이트로 홍보되었습니다.

GitLab 14.4 이전에 실행 중인 보조 사이트를 홍보하려면:

경고: gitlab-ctl promote-to-primary-nodegitlab-ctl promoted-db 명령어는 GitLab 14.5 이후에서는 사용되지 않으며, GitLab 15.0에서 제거되었습니다. 대신 gitlab-ctl geo promote를 사용하세요.

  1. 보조 사이트에 SSH를 연결하고 root로 로그인하세요:

    sudo -i
    
  2. /etc/gitlab/gitlab.rb 파일을 편집하여 새로운 주요 역할을 반영하도록 합니다. geo_secondary_role을 활성화하는 하는 모든 행을 삭제하세요:

    ## 이전 11.5 버전 미만의 문서에서는 다음과 같이 역할을 활성화했습니다. 이 줄을 삭제하세요.
    geo_secondary_role['enable'] = true
    
    ## 11.5 이상의 문서에서는 다음과 같이 역할을 활성화했습니다. 이 줄을 삭제하세요.
    roles ['geo_secondary_role']
    
  3. 다음 명령어를 실행하여 출발 전 검사(preflight checks)를 나열하고 예정된 장애 조치(failover)를 계획하기 전에 복제 및 확인이 완료되었는지 자동으로 확인하세요:

    주의: GitLab 13.7 이전 버전에서 복제할 항목이 없는 데이터 유형이 있는 경우, 실제로 복제가 최신이라도 이 명령어는 ERROR - Replication is not up-to-date를 보고합니다. 이 버그는 GitLab 13.8에서 수정되었습니다.

    gitlab-ctl promotion-preflight-checks
    
  4. 보조를 홍보하세요:

    주의: GitLab 13.7 이전 버전에서 복제할 항목이 없는 데이터 유형이 있는 경우, 실제로 복제가 최신이라도 복제 및 확인 출력이 완료되었다고 나타나면 --skip-preflight-checks를 추가하여 명령어를 완료할 수 있습니다. 이 버그는 GitLab 13.8에서 수정되었습니다.

    gitlab-ctl promote-to-primary-node
    

    이미 출발 전 검사를 실행했거나 실행하고 싶지 않은 경우, 이를 건너뛸 수 있습니다:

    gitlab-ctl promote-to-primary-node --skip-preflight-check
    

    출발 전 검사에서 실패해도 보조 사이트를 주요로 홍보할 수 있습니다:

    sudo gitlab-ctl promote-to-primary-node --force
    
  5. 이전에 보조 사이트에 사용한 URL을 사용하여 새롭게 홍보된 주요 사이트에 연결할 수 있는지 확인하세요.

    성공하면 보조 사이트가 이제 주요 사이트로 홍보되었습니다.

다음 단계

지리적 장애 허용을 빨리 되찾기 위해 새로운 보조 사이트를 추가해야 합니다. 이를 위해 이전의 주요를 새로운 보조로 추가하고 온라인으로 가져와야 합니다.