InfoGrab DocsInfoGrab Docs

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

요약

Disaster Recovery (Geo) 프로모션 런북입니다. 이 런북은 하나의 보조 사이트를 가진 단일 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 이 가이드를 따르면 다음과 같은 결과를 얻을 수 있습니다:

Disaster Recovery (Geo) 프로모션 런북#

  - 
  Tier: Premium, Ultimate

- Offering: GitLab Self-Managed#

  Status: Experiment

Disaster Recovery (Geo) 프로모션 런북입니다.

이 런북은 [실험](/19.2/policy/development_stages_support/#experiment) 기능입니다. 완전한 프로덕션 준비 문서는

재해 복구 문서를 참조하세요.

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

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

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

기본 사이트:

  • GitLab 노드

보조 사이트:

  • GitLab 노드

이 가이드를 따르면 다음과 같은 결과를 얻을 수 있습니다:

  • 오프라인 상태의 기본 사이트.

  • 새 기본 사이트로 프로모션된 보조 사이트.

다루지 않는 내용:

  • 이전 기본 사이트를 보조 사이트로 다시 추가하는 방법.

  • 새 보조 사이트 추가 방법.

준비#

다음 단계를 수행하기 전에, 보조 사이트를 프로모션할 수 있는 `root` 액세스 권한이 있는지 확인하세요.

Geo 복제본을 프로모션하고 장애 조치를 수행하는 자동화된 방법은 없습니다.

보조 사이트에서 관리자 영역 > Geo 대시보드로 이동하여 상태를 검토하세요. 복제된 오브젝트(녹색으로 표시됨)가 100%에 가까워야 하며, 오류(빨간색으로 표시됨)가 없어야 합니다. 아직 복제되지 않은 오브젝트(회색으로 표시됨)의 비율이 크다면, 사이트가 완료할 수 있도록 더 많은 시간을 주는 것을 고려하세요.

[

](/19.2/administration/geo/disaster_recovery/img/geo_dashboard_v14_0.png)

복제에 실패하는 오브젝트가 있다면, 유지 보수 창을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후에는 복제에 실패한 항목이 손실됩니다.

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

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

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

읽기 전용 모드가 구현될 때까지, 기본 사이트에서 업데이트가 수동으로 발생하지 않도록 방지해야 합니다. 유지 보수 창 동안 보조 사이트는 기본 사이트에 대한 읽기 전용 액세스 권한이 필요합니다:

예정된 시간에, 클라우드 제공업체 또는 사이트의 방화벽을 사용하여, 귀하의 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

이 시점부터 사용자는 기본 사이트에서 데이터를 보거나 변경할 수 없습니다. 보조 사이트에 로그인할 수도 없습니다. 그러나 기존 세션은 유지 보수 기간의 나머지 동안 작동해야 하므로, 공개 데이터는 전체적으로 접근 가능합니다.

다른 IP를 통해 브라우저에서 방문하여 기본 사이트가 HTTP 트래픽에 차단되었는지 확인하세요. 서버가 연결을 거부해야 합니다.

SSH 원격 URL로 기존 Git 리포지터리를 가져오려는 시도를 통해 기본 사이트가 SSH를 통한 Git 트래픽에 차단되었는지 확인하세요. 서버가 연결을 거부해야 합니다.

기본 사이트에서:

오른쪽 상단 모서리에서 관리자를 선택하세요.

  • 왼쪽 사이드바에서 모니터링 > 백그라운드 jobs를 선택하세요.

  • Sidekiq 대시보드에서 Cron을 선택하세요.

  • Disable All을 선택하여 Geo가 아닌 주기적 백그라운드 jobs를 비활성화하세요.

  • geo_sidekiq_cron_config_worker cron job에 대해 Enable을 선택하세요. 이 job은 계획된 장애 조치가 성공적으로 완료되는 데 필수적인 여러 다른 cron jobs를 다시 활성화합니다.

모든 데이터 복제 및 검증을 완료하세요:

모든 데이터가 자동으로 복제되지는 않습니다.

제외되는 항목에 대해 자세히 알아보세요.

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

기본 사이트에서:

오른쪽 상단 모서리에서 관리자를 선택하세요.

왼쪽 사이드바에서 모니터링 > 백그라운드 jobs를 선택하세요.

Sidekiq 대시보드에서 Queues를 선택하고, 이름에 geo가 포함된 큐를 제외한 모든 큐가 0으로 떨어질 때까지 기다리세요. 이러한 큐에는 사용자가 제출한 작업이 포함되어 있으므로, 완료되기 전에 장애 조치하면 해당 작업이 손실됩니다.

왼쪽 사이드바에서 Geo > 사이트를 선택하고, 장애 조치하려는 보조 사이트에서 다음 조건이 충족될 때까지 기다리세요:

모든 복제 미터가 100% 복제됨, 0% 오류에 도달해야 합니다.

  • 모든 검증 미터가 100% 검증됨, 0% 오류에 도달해야 합니다.

  • 데이터베이스 복제 지연이 0 ms여야 합니다.

  • Geo 로그 커서가 최신 상태(0 이벤트 뒤처짐)여야 합니다.

보조 사이트에서:

오른쪽 상단 모서리에서 관리자를 선택하세요.

  • 왼쪽 사이드바에서 모니터링 > 백그라운드 jobs를 선택하세요.

  • Sidekiq 대시보드에서 Queues를 선택하고, 모든 geo 큐가 대기 중 0, 실행 중 0 jobs로 떨어질 때까지 기다리세요.

  • 무결성 검사를 실행하여 파일 스토리지의 CI 아티팩트, LFS 오브젝트, 업로드의 무결성을 확인하세요.

이 시점에서 보조 사이트는 기본 사이트가 가진 모든 것의 최신 사본을 포함하고 있으므로, 장애 조치 시 아무것도 손실되지 않습니다.

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

기본 사이트가 오프라인 상태가 되면, 보조 사이트에 복제되지 않은

데이터가 기본 사이트에 저장되어 있을 수 있습니다. 계속 진행하면 이 데이터는 손실된 것으로 처리해야 합니다.

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

장애 조치를 수행할 때, 두 개의 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 스플릿 브레인(split-brain) 상황을 피하고 싶습니다. 따라서 장애 조치를 준비하려면 기본 사이트를 비활성화해야 합니다:

기본 사이트에 SSH 액세스 권한이 있는 경우, GitLab을 중지하고 비활성화하세요:

sudo gitlab-ctl stop

서버가 예기치 않게 재부팅될 경우 GitLab이 다시 시작되지 않도록 방지하세요:

sudo systemctl disable gitlab-runsvdir

CentOS 6 이하에서는 머신이 재부팅될 경우 GitLab이 시작되지 않도록 방지하는 것이 어렵습니다 (이슈 3058 참조). sudo yum remove gitlab-ee로 GitLab 패키지를 완전히 제거하는 것이 가장 안전할 수 있습니다.

  • Ubuntu 14.04 LTS와 같은 이전 버전의 Ubuntu 또는 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 오류가 발생하면, 문제 해결 조언을 읽어보세요.

보조 사이트를 프로모션하려면:

보조 사이트에 SSH로 접속하여 다음 명령 중 하나를 실행하세요:

보조 사이트를 기본 사이트로 프로모션하려면:

sudo gitlab-ctl geo promote

추가 확인 없이 보조 사이트를 기본 사이트로 프로모션하려면:

sudo gitlab-ctl geo promote --force

이전에 보조 사이트에 사용했던 URL을 사용하여 새로 프로모션된 기본 사이트에 연결할 수 있는지 확인하세요.

성공하면 보조 사이트가 기본 사이트로 프로모션된 것입니다.

다음 단계#

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

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

GitLab v19.2
원문 보기
요약

Disaster Recovery (Geo) 프로모션 런북입니다. 이 런북은 하나의 보조 사이트를 가진 단일 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 이 가이드를 따르면 다음과 같은 결과를 얻을 수 있습니다:

Disaster Recovery (Geo) 프로모션 런북#

  - 
  Tier: Premium, Ultimate

- Offering: GitLab Self-Managed#

  Status: Experiment

Disaster Recovery (Geo) 프로모션 런북입니다.

이 런북은 [실험](/19.2/policy/development_stages_support/#experiment) 기능입니다. 완전한 프로덕션 준비 문서는

재해 복구 문서를 참조하세요.

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

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

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

기본 사이트:

  • GitLab 노드

보조 사이트:

  • GitLab 노드

이 가이드를 따르면 다음과 같은 결과를 얻을 수 있습니다:

  • 오프라인 상태의 기본 사이트.

  • 새 기본 사이트로 프로모션된 보조 사이트.

다루지 않는 내용:

  • 이전 기본 사이트를 보조 사이트로 다시 추가하는 방법.

  • 새 보조 사이트 추가 방법.

준비#

다음 단계를 수행하기 전에, 보조 사이트를 프로모션할 수 있는 `root` 액세스 권한이 있는지 확인하세요.

Geo 복제본을 프로모션하고 장애 조치를 수행하는 자동화된 방법은 없습니다.

보조 사이트에서 관리자 영역 > Geo 대시보드로 이동하여 상태를 검토하세요. 복제된 오브젝트(녹색으로 표시됨)가 100%에 가까워야 하며, 오류(빨간색으로 표시됨)가 없어야 합니다. 아직 복제되지 않은 오브젝트(회색으로 표시됨)의 비율이 크다면, 사이트가 완료할 수 있도록 더 많은 시간을 주는 것을 고려하세요.

[

](/19.2/administration/geo/disaster_recovery/img/geo_dashboard_v14_0.png)

복제에 실패하는 오브젝트가 있다면, 유지 보수 창을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후에는 복제에 실패한 항목이 손실됩니다.

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

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

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

읽기 전용 모드가 구현될 때까지, 기본 사이트에서 업데이트가 수동으로 발생하지 않도록 방지해야 합니다. 유지 보수 창 동안 보조 사이트는 기본 사이트에 대한 읽기 전용 액세스 권한이 필요합니다:

예정된 시간에, 클라우드 제공업체 또는 사이트의 방화벽을 사용하여, 귀하의 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

이 시점부터 사용자는 기본 사이트에서 데이터를 보거나 변경할 수 없습니다. 보조 사이트에 로그인할 수도 없습니다. 그러나 기존 세션은 유지 보수 기간의 나머지 동안 작동해야 하므로, 공개 데이터는 전체적으로 접근 가능합니다.

다른 IP를 통해 브라우저에서 방문하여 기본 사이트가 HTTP 트래픽에 차단되었는지 확인하세요. 서버가 연결을 거부해야 합니다.

SSH 원격 URL로 기존 Git 리포지터리를 가져오려는 시도를 통해 기본 사이트가 SSH를 통한 Git 트래픽에 차단되었는지 확인하세요. 서버가 연결을 거부해야 합니다.

기본 사이트에서:

오른쪽 상단 모서리에서 관리자를 선택하세요.

  • 왼쪽 사이드바에서 모니터링 > 백그라운드 jobs를 선택하세요.

  • Sidekiq 대시보드에서 Cron을 선택하세요.

  • Disable All을 선택하여 Geo가 아닌 주기적 백그라운드 jobs를 비활성화하세요.

  • geo_sidekiq_cron_config_worker cron job에 대해 Enable을 선택하세요. 이 job은 계획된 장애 조치가 성공적으로 완료되는 데 필수적인 여러 다른 cron jobs를 다시 활성화합니다.

모든 데이터 복제 및 검증을 완료하세요:

모든 데이터가 자동으로 복제되지는 않습니다.

제외되는 항목에 대해 자세히 알아보세요.

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

기본 사이트에서:

오른쪽 상단 모서리에서 관리자를 선택하세요.

왼쪽 사이드바에서 모니터링 > 백그라운드 jobs를 선택하세요.

Sidekiq 대시보드에서 Queues를 선택하고, 이름에 geo가 포함된 큐를 제외한 모든 큐가 0으로 떨어질 때까지 기다리세요. 이러한 큐에는 사용자가 제출한 작업이 포함되어 있으므로, 완료되기 전에 장애 조치하면 해당 작업이 손실됩니다.

왼쪽 사이드바에서 Geo > 사이트를 선택하고, 장애 조치하려는 보조 사이트에서 다음 조건이 충족될 때까지 기다리세요:

모든 복제 미터가 100% 복제됨, 0% 오류에 도달해야 합니다.

  • 모든 검증 미터가 100% 검증됨, 0% 오류에 도달해야 합니다.

  • 데이터베이스 복제 지연이 0 ms여야 합니다.

  • Geo 로그 커서가 최신 상태(0 이벤트 뒤처짐)여야 합니다.

보조 사이트에서:

오른쪽 상단 모서리에서 관리자를 선택하세요.

  • 왼쪽 사이드바에서 모니터링 > 백그라운드 jobs를 선택하세요.

  • Sidekiq 대시보드에서 Queues를 선택하고, 모든 geo 큐가 대기 중 0, 실행 중 0 jobs로 떨어질 때까지 기다리세요.

  • 무결성 검사를 실행하여 파일 스토리지의 CI 아티팩트, LFS 오브젝트, 업로드의 무결성을 확인하세요.

이 시점에서 보조 사이트는 기본 사이트가 가진 모든 것의 최신 사본을 포함하고 있으므로, 장애 조치 시 아무것도 손실되지 않습니다.

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

기본 사이트가 오프라인 상태가 되면, 보조 사이트에 복제되지 않은

데이터가 기본 사이트에 저장되어 있을 수 있습니다. 계속 진행하면 이 데이터는 손실된 것으로 처리해야 합니다.

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

장애 조치를 수행할 때, 두 개의 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 스플릿 브레인(split-brain) 상황을 피하고 싶습니다. 따라서 장애 조치를 준비하려면 기본 사이트를 비활성화해야 합니다:

기본 사이트에 SSH 액세스 권한이 있는 경우, GitLab을 중지하고 비활성화하세요:

sudo gitlab-ctl stop

서버가 예기치 않게 재부팅될 경우 GitLab이 다시 시작되지 않도록 방지하세요:

sudo systemctl disable gitlab-runsvdir

CentOS 6 이하에서는 머신이 재부팅될 경우 GitLab이 시작되지 않도록 방지하는 것이 어렵습니다 (이슈 3058 참조). sudo yum remove gitlab-ee로 GitLab 패키지를 완전히 제거하는 것이 가장 안전할 수 있습니다.

  • Ubuntu 14.04 LTS와 같은 이전 버전의 Ubuntu 또는 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 오류가 발생하면, 문제 해결 조언을 읽어보세요.

보조 사이트를 프로모션하려면:

보조 사이트에 SSH로 접속하여 다음 명령 중 하나를 실행하세요:

보조 사이트를 기본 사이트로 프로모션하려면:

sudo gitlab-ctl geo promote

추가 확인 없이 보조 사이트를 기본 사이트로 프로모션하려면:

sudo gitlab-ctl geo promote --force

이전에 보조 사이트에 사용했던 URL을 사용하여 새로 프로모션된 기본 사이트에 연결할 수 있는지 확인하세요.

성공하면 보조 사이트가 기본 사이트로 프로모션된 것입니다.

다음 단계#

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