caution
이런 Runbook은 실험입니다. 완전하고 프로덕션에 준비된 문서를 보려면 재해 복구 문서를 참조하세요.

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

Tier: Premium, Ultimate Offering: Self-managed

멀티 노드 구성을 위한 Geo 예정된 장애 조치

구성 요소 구성
PostgreSQL 리눅스 패키지에서 관리됨
Geo 사이트 멀티 노드
Secondaries 1개

이 runbook은 보조 1개의 멀티 노드 Geo 사이트의 예정된 장애 조치를 안내합니다. 다음 2000 사용자 참조 아키텍처를 가정합니다.

graph TD subgraph main[Geo 배포] subgraph Primary[Primary 사이트, 멀티 노드] Node_1[Rails 노드 1] Node_2[Rails 노드 2] Node_3[PostgreSQL 노드] Node_4[Gitaly 노드] Node_5[Redis 노드] Node_6[모니터링 노드] end subgraph Secondary[Secondary 사이트, 멀티 노드] Node_7[Rails 노드 1] Node_8[Rails 노드 2] Node_9[PostgreSQL 노드] Node_10[Gitaly 노드] Node_11[Redis 노드] Node_12[모니터링 노드] end end

로드 밸런서 노드와 선택적 NFS 서버는 명확성을 위해 생략되었습니다.

이 안내서는 다음과 같은 결과를 낳습니다.

  1. 오프라인 프라이머리.
  2. 프로모트된 세컨더리는 이제 새로운 프라이머리입니다.

다루지 않는 내용:

  1. 이전 프라이머리를 세컨더리로 다시 추가하는 것.
  2. 새로운 세컨더리를 추가하는 것.

준비

note
위의 단계 중 어느 것이든 따르기 전에, 세컨더리를 프로모트하기 위해 root 액세스가 있는지 확인하세요. 왜냐하면 Geo 레플리카를 프로모트하고 장애 조치를 수행할 수 있는 자동화된 방법이 제공되지 않기 때문입니다.

세컨더리 사이트에서:

  1. 왼쪽 사이드바에서 아래쪽을 선택하여 Admin Area를 선택합니다.
  2. Geo > Sites를 선택하여 상태를 확인합니다. 복제된 객체(녹색으로 표시됨)는 100%에 가까워야 하고, 실패 사항(빨간색으로 표시됨)이나 복제가 실패하면 안 됩니다(회색으로 표시됨). 많은 비율의 객체가 복제되지 않으면(회색으로 표시됨), 사이트가 완료될 수 있도록 더 많은 시간을 고려해야 합니다.

    Replication status

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

실패한 객체와 실패 원인을 검토하려면 Geo 상태 API를 사용할 수 있습니다. 복제 실패의 흔한 원인은 데이터가 프라이머리 사이트에 없는 것입니다 - 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거하여 이러한 실패를 해결할 수 있습니다.

유지 보수 창이 완전히 마무리될 때까지 Geo 복제 및 확인이 완전히 완료되지 않습니다. 창을 가능한 짧게 유지하려면 이러한 프로세스가 활성 사용 중에 가까이 100%에 가까워야 합니다.

세컨더리 사이트가 여전히 프라이머리 사이트에서 데이터를 복제하고 있다면, 불필요한 데이터 손실을 피하기 위해 다음 단계를 따릅니다:

  1. 프라이머리 사이트에서 유지 보수 모드를 활성화하고, 백그라운드 작업을 중지해야 합니다.
  2. 모든 데이터를 복제하고 확인합니다:

    caution
    모든 데이터가 자동으로 복제되지 않습니다. 제외되는 사항에 대해 자세히 읽으세요.
    1. Geo에서 관리되지 않는 데이터를 수동으로 복제하고 있다면, 최종 복제 프로세스를 트리거하세요.
    2. 프라이머리 사이트에서:
      1. 왼쪽 사이드바에서 아래쪽을 선택하여 Admin Area를 선택합니다.
      2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
      3. Sidekiq 대시보드에서 대기열(Queues)를 선택하고, geo가 이름에 들어간 대기열을 제외하고 나머지 대기열이 모두 0이 될 때까지 기다립니다. 이러한 대기열에는 사용자가 제출한 작업이 포함되어 있으며, 이것이 완료되기 전에 장애 조치를 하면 작업이 손실됩니다.
      4. 왼쪽 사이드바에서 Geo > Sites를 선택하고, 다음 조건이 세컨더리 사이트에 대해 참이 되도록 기다립니다:

        • 모든 복제 미터가 100% 복제, 0% 실패에 이른다.
        • 모든 확인 미터가 100% 확인, 0% 실패에 이른다.
        • 데이터베이스 복제 랙이 0밀리초이다.
        • Geo 로그 커서가 최신 상태(이벤트 0개 미만)이다.
    3. 세컨더리 사이트에서:
      1. 왼쪽 사이드바에서 아래쪽을 선택하여 Admin Area를 선택합니다.
      2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
      3. Sidekiq 대시보드에서 대기열(Queues)를 선택하고, geo 대기열이 0과 0으로 되도록 기다립니다.
      4. 무결성 확인을 실행하려면 Raketasks/check.md을(를) 참조하여 CI artifact, LFS object 및 파일 저장소의 무결성을 확인합니다.

    이 시점에서 세컨더리 사이트에는 프라이머리 사이트에 있는 모든 것의 최신 복사본이 포함되어 있으므로 장애 조치를 하면 데이터가 손실되지 않습니다.

  3. 이 마지막 단계에서 프라이머리 사이트를 영구적으로 비활성화해야 합니다.

    caution
    프라이머리 사이트가 오프라인 상태가 되면 프라이머리 사이트에 저장된 데이터 중 세컨더리 사이트에 복제되지 않은 데이터가 있을 수 있습니다. 이러한 데이터는 진실로 간주해야 합니다.
    note
    프라이머리 도메인 DNS 레코드를 업데이트할 계획이 있다면 이제 TTL을 낮추어 전파 속도를 높일 수 있습니다.

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

    • 프라이머리 사이트에 SSH 액세스가 있다면 GitLab을 중지하고 비활성화하세요:

      sudo gitlab-ctl stop
      

      서버가 예기치 않게 재부팅되면 GitLab이 다시 시작되지 않게 하세요:

      sudo systemctl disable gitlab-runsvdir
      
      note
      (CentOS 전용) CentOS 6 또는 이전 버전에서는 서버가 재부팅될 때 GitLab을 시작하지 않는 것이 어려울 수 있습니다(자세한 내용은 issue 3058을 참조하세요). sudo yum remove gitlab-ee를 사용하여 GitLab 패키지를 완전히 제거하는 것이 가장 안전할 수 있습니다.
      note
      (Ubuntu 14.04 LTS 전용) 또는 Upstart init 시스템을 기반으로 하는 이전 버전의 Ubuntu나 해당하는 다른 배포판을 사용하고 있다면 다음으로부터 GitLab이 재부팅될 때까지 서버에서 root로 실행하여 GitLab이 시작되지 않도록 만들 수 있습니다. initctl stop gitlab-runsvvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configuration.
    • 프라이머리 사이트에 SSH 액세스가 없다면, 해당 머신을 오프라인 상태로 전환하고 재부팅되지 않도록 만들어야 합니다. 이를 수행하는 여러 가지 방법이 있지만, 하나의 추천은 피합니다. 다음을 수행할 수 있을 것입니다:

      • 로드 밸런서를 재구성합니다.
      • DNS 레코드를 변경합니다(예: 프라이머리 DNS 레코드를 세컨더리 사이트를 가리키도록 지정하여 프라이머리 사이트 사용을 중지합니다).
      • 가상 서버를 중지합니다.
      • 방화벽을 통해 트래픽을 차단합니다.
      • 프라이머리 사이트의 객체 스토리지 권한을 취소합니다.
      • 머신을 물리적으로 연결을 해제합니다.

보조 사이트를 실행 중인 GitLab 14.5 및 그 이후로 승격하기

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

GitLab 14.4 및 14.5 이전으로 실행 중인 보조 사이트 승격하기

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

참고: 새로운 보조를 이 시점에 추가해서는 안 됩니다. 새로운 보조를 추가하려면 보조로 승격하는 전체 과정을 완료한 후에 이 작업을 수행하세요.

경고: 이 과정 중에 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류가 발생하는 경우 문제 해결 방법을 확인하세요.

gitlab-ctl promote-to-primary-node 명령어는 여러 서버와 함께 사용할 수 없으므로, 단일 기계의 보조에서만 변경을 수행할 수 있습니다. 대신 수동으로 수행해야 합니다.

경고: GitLab 13.2 및 13.3에서 보조가 정지된 상태에서 보조 사이트를 로 승격하려고 하면 실패합니다. 로 승격하기 전에 복제를 일시 중지하지 마세요. 사이트가 정지된 경우, 승격 전에 반드시 다시 시작해야 합니다. 이 문제는 GitLab 13.4부터 해결되었습니다.

경고: 보조 사이트가 일시 중지된 상태에서는 마지막으로 알려진 상태로의 시점 복구를 수행합니다. 보조가 일시 중지된 동안 주에서 생성된 데이터는 손실됩니다.

  1. 보조의 PostgreSQL 노드에 SSH하여 PostgreSQL을 별도로 승격합니다:

    sudo gitlab-ctl promote-db
    
  2. 보조의 각 머신의 /etc/gitlab/gitlab.rb 파일을 편집하여 geo_secondary_role을 활성화한 줄을 제거하여 새로운 상태를 반영합니다.

    ## 11.5 버전 이전의 설명서에 따르면, 역할을 활성화합니다. 이 줄을 제거하세요.
    geo_secondary_role['enable'] = true
    
    ## 11.5 이후 버전의 설명서에 따르면, 역할을 활성화합니다. 이 줄을 제거하세요.
    roles ['geo_secondary_role']
    

    이러한 변경을 수행한 후 GitLab을 재구성하여 변경 내용을 적용합니다.

  3. 보조로 승격합니다. 단일 Rails 노드 서버에 SSH하여 다음을 실행합니다.

    sudo gitlab-rake geo:set_secondary_as_primary
    
  4. 이전에 보조에 사용한 URL을 사용하여 새로 승격된 에 연결할 수 있는지 확인합니다.

  5. 성공입니다! 보조가 이제 로 승격되었습니다.

추가 단계

지리적으로 다양한 시스템을 가능한 빨리 회복하기 위해, 보조 사이트를 추가해야 합니다. 이를 위해 이전 를 새로운 보조로 다시 추가하고 온라인 상태로 되돌려야합니다.