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

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

Tier: Premium, Ultimate Offering: Self-Managed형

단일 노드 구성에 대한 Geo 계획된 장애 조치

컴포넌트 구성
PostgreSQL 리눅스 패키지에서 관리됨
Geo 사이트 단일 노드
두 번째 사이트 하나

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

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

이 안내서에서 다음이 결과로 나타납니다:

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

다루지 않는 항목:

  1. 기존 주 사이트를 다시 보조 사이트로 추가
  2. 새로운 보조 사이트 추가

준비

note
위 스텝 중 어느 것이든 따를 때, 자동으로 Geo 패러디그마를 승격시키고 장애 조치를 수행할 방법이 없기 때문에 보조를 승격시키기 위해 루트 액세스가 있는지 확인하세요.

보조 사이트에서 관리자 영역 > Geo 대시보드로 이동하여 상태를 확인하세요. 복제된 개체(녹색으로 표시됨)가 100%에 가까워야 하고 실패한 사항(빨간색으로 표시됨)이 있어서는 안 됩니다. 아직 복제되지 않은 개체의 비율이 크다면(회색으로 표시됨), 사이트에 더 많은 시간을 주는 것을 고려하세요.

복제 상태

복제되지 않은 개체가 있는 경우, 유지 보수 창을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후에 복제되지 않은 것은 손실됩니다.

현재 노드에서 발생한 프로젝트 동기화 또는 검증 실패를 확인하려면 Geo 상태 API를 사용할 수 있습니다. 복제 실패의 일반적인 원인은 주 사이트에서 데이터가 누락되는 것입니다 - 이러한 실패는 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거함으로써 해결할 수 있습니다.

유지 보수 창은 Geo 복제 및 검증이 완료될 때까지 종료되지 않습니다. 창을 최소화하기 위해 이 프로세스가 사용 중에 가급적 100%에 가까워야 합니다.

보조 사이트에서 주 사이트에서 데이터를 아직 복제 중이라면, 불필요한 데이터 손실을 피하기 위해 다음 단계를 따르세요:

  1. 읽기 전용 모드까지 실행되기 전에 업데이트를 매뉴얼으로 주에서 막아야 합니다. 유지 보수 기간 동안 보조 사이트는 주 사이트에 대해 읽기 전용 액세스를 여전히 필요로 합니다.

    1. 예약된 시간에 클라우드 제공 업체 또는 사이트 방화벽을 사용하여 주 사이트에서/로의 모든 HTTP, HTTPS 및 SSH 트래픽을 블록하십시오. 이때 IP 및 보조 사이트의 IP를 제외하십시오.

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

      sudo iptables -A INPUT -p tcp -s <보조_사이트_IP> --destination-port 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -s <당신의_IP> --destination-port 22 -j ACCEPT
sudo iptables -A INPUT --destination-port 22 -j REJECT
      
sudo iptables -A INPUT -p tcp -s <보조_사이트_IP> --destination-port 80 -j ACCEPT
sudo iptables -A INPUT -p tcp -s <당신의_IP> --destination-port 80 -j ACCEPT
sudo iptables -A INPUT --tcp-dport 80 -j REJECT
      
sudo iptables -A INPUT -p tcp -s <보조_사이트_IP> --destination-port 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s <당신의_IP> --destination-port 443 -j ACCEPT
sudo iptables -A INPUT --tcp-dport 443 -j REJECT

      이 시점에서 사용자는 주 사이트에서 데이터를 볼 수 없거나 변경할 수 없습니다. 또한 보조 사이트에 로그인할 수 없습니다. 그러나 기존 세션은 유지되어야 하며, 따라서 공용 데이터는 계속해서 접근이 가능해야 합니다.

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

    3. 주 사이트가 SSH 트래픽에 차단되었는지 확인합니다. 기존의 Git 리포지터리에서 SSH 원격 URL을 사용하여 풀을 시도합니다. 서버가 연결을 거부해야 합니다.

    4. 주 사이트에서:

      1. 왼쪽 사이드바에서 하단에서 관리자 영역을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background Jobs를 선택합니다.
      3. Sidekiq 대시보드에서 Cron을 선택합니다.
      4. 모든 비-Geo 주기적 백그라운드 작업 비활성화를 선택하여 비-Geo 주기적 백그라운드 작업을 비활성화합니다. 이 작업은 계획된 장애 조치가 성공적으로 완료될 수 있도록 핵심이 되는 여러 다른 cron 작업을 다시 활성화합니다.

  2. 모든 데이터를 복제하고 확인하세요:

    caution
    모든 데이터가 자동으로 복제되는 것은 아닙니다. 제외된 것에 대해 자세히 읽으세요.
    1. 매뉴얼으로 복제하려는 Geo에서 관리되지 않는 데이터가 있다면 최종 복제 프로세스를 시작하세요.
    2. 주 사이트에서:
      1. 왼쪽 사이드바에서 하단에서 관리자 영역을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background Jobs를 선택합니다.
      3. Sidekiq 대시보드에서 Queues를 선택하고 geo라는 이름을 가진 것을 제외한 모든 큐가 0이 될 때까지 기다립니다. 이러한 큐는 사용자가 제출한 작업을 포함하며, 이 작업이 완료되기 전에 실패하게 되면 작업은 손실됩니다.

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

        • 모든 복제 미터가 100% 복제되었고, 0% 실패되었습니다.
        • 모든 검증 미터가 100% 검증되었고, 0% 실패되었습니다.
        • 데이터베이스 복제 랙이 0밀리초입니다.
        • Geo 로그 커서가 최신 상태(이벤트가 0개 남음)입니다.
    3. 보조 사이트에서:
      1. 왼쪽 사이드바에서 하단에서 관리자 영역을 선택합니다.
      2. 왼쪽 사이드바에서 Monitoring > Background Jobs를 선택합니다.
      3. Sidekiq 대시보드에서 Queues를 선택하고 geo 큐가 0이 될 때까지 기다립니다.
      4. 무결성 검사를 실행하여 파일 리포지터리의 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이 머신이 다시 부팅되면 시작되지 않는 쉽게한 방법이 없습니다(문제 3058 참조). 안전을 위해 sudo yum remove gitlab-ee로 GitLab 패키지를 완전히 제거하는 것이 좋습니다.
      note
      (Ubuntu 14.04 LTS 전용) 또는 다른 Upstart init 시스템 기반의 여타 배포판을 사용 중이라면 root로서 initctl stop gitlab-runsvvdir && 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을 사용하여 새로 홍보된 주요 사이트에 연결할 수 있는지 확인합니다.

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

다음 단계

지리적 중복성을 빠르게 되찾기 위해 새로운 보조 사이트를 추가해야 합니다. 이를 위해 이전 주요를 새로운 보조로 다시 추가하고 온라인으로 되돌려야 합니다.