재해 복구(Geo) 프로모션 런북
Status: Experiment
재해 복구(Geo) 프로모션 런북입니다.
단일 노드 구성에 대한 Geo 계획된 장애 조치
구성요소 | 구성 |
---|---|
PostgreSQL | Linux 패키지로 관리 |
Geo 사이트 | 단일 노드 |
세컨더리 | 하나 |
이 런북은 하나의 세컨더리를 가진 단일 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 다음과 같은 일반 아키텍처가 가정됩니다:
이 가이드를 따르면 다음 결과가 발생합니다:
- 오프라인이 된 프라이머리.
- 이제 새로운 프라이머리가 된 프로모트된 세컨더리.
다음은 다루지 않습니다:
- 이전 프라이머리를 세컨더리로 다시 추가하기.
- 새로운 세컨더리 추가하기.
준비
root
접근 권한이 있는지 확인하세요. Geo 복제본을 프로모트하고 장애 조치를 수행하는 자동화된 방법이 제공되지 않기 때문입니다.세컨더리 사이트에서, 관리 영역 > Geo 대시보드로 이동하여 상태를 검토합니다. 복제된 객체(녹색으로 표시)는 거의 100%에 가깝고 실패가 없어야 합니다(빨간색으로 표시). 만약 대량의 객체가 아직 복제되지 않았다면(회색으로 표시) 사이트가 완료될 때까지 더 많은 시간을 주는 것을 고려하세요.
복제에 실패하는 객체가 있는 경우, 유지 보수 창을 예약하기 전에 이 문제를 조사해야 합니다. 계획된 장애 조치 후, 복제에 실패한 내용은 손실됩니다.
복제 실패의 일반적인 원인은 프라이머리 사이트에 데이터가 누락되어 있는 것입니다 - 이러한 실패는 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거하여 해결할 수 있습니다.
유지 보수 창은 Geo 복제 및 검증이 완전히 완료될 때까지 종료되지 않습니다. 활성 사용 중에는 이러한 프로세스가 가능한 100%에 가까워야 유지 보수 창을 짧게 유지할 수 있습니다.
세컨더리 사이트가 여전히 프라이머리 사이트에서 데이터를 복제하고 있는 경우, 불필요한 데이터 손실을 피하기 위해 다음 단계를 따르세요:
-
읽기 전용 모드가 구현될 때까지 수동으로 프라이머리 사이트에서 업데이트가 발생하지 않도록 해야 합니다. 유지 보수 창 동안 세컨더리 사이트는 여전히 프라이머리 사이트에 대한 읽기 전용 접근이 필요합니다:
-
예약된 시간에, 클라우드 제공자나 사이트의 방화벽을 사용하여 프라이머리 사이트와의 모든 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
이 시점부터, 사용자는 프라이머리 사이트에서 데이터를 보거나 변경할 수 없습니다. 또한, 세컨더리 사이트에 로그인할 수 없습니다. 그러나 기존 세션은 유지 보수 기간 동안 작동해야 하므로, 공개 데이터는 계속 액세스 가능합니다.
-
프라이머리 사이트가 HTTP 트래픽 차단되었는지 확인하기 위해 다른 IP를 통해 브라우저에서 방문해보세요. 서버는 연결을 거부해야 합니다.
-
프라이머리 사이트가 Git over SSH 트래픽 차단되었는지 확인하기 위해 SSH 원격 URL로 기존 Git 리포지토리를 풀어보세요. 서버는 연결을 거부해야 합니다.
-
프라이머리 사이트에서:
- 왼쪽 사이드바에서 하단의 관리를 선택합니다.
- 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
- Sidekiq 대시보드에서 크론을 선택합니다.
-
Disable All
을 선택하여 Geo와 관련없는 주기적인 백그라운드 작업을 비활성화합니다. -
geo_sidekiq_cron_config_worker
크론 작업을 위해Enable
을 선택합니다.
이 작업은 계획된 장애 조치가 성공적으로 완료되기 위해 필수적인 여러 다른 크론 작업을 재활성화합니다.
-
-
모든 데이터의 복제 및 검증을 완료합니다:
모든 데이터가 자동으로 복제되지는 않습니다. 제외된 내용에 대해 더 읽어보세요.- Geo에 의해 관리되지 않는 모든 데이터의 복제를 수동으로 수행하고, 지금 마지막 복제 프로세스를 시작합니다.
-
프라이머리 사이트에서:
- 왼쪽 사이드바에서 하단의 관리를 선택합니다.
- 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
- Sidekiq 대시보드에서 큐를 선택하고,
geo
가 포함되지 않은 모든 큐가 0으로 떨어질 때까지 기다립니다.
이 큐에는 사용자가 제출한 작업이 포함되어 있습니다; 완료되기 전에 장애 조치를 수행하면 작업이 손실됩니다. -
왼쪽 사이드바에서 Geo > 사이트를 선택하고, 실패 조치할 세컨더리 사이트에 대해 다음 조건이 충족될 때까지 기다립니다:
- 모든 복제 측정기가 100% 복제됨, 0% 실패.
- 모든 검증 측정기가 100% 검증됨, 0% 실패.
- 데이터베이스 복제 지연이 0 ms.
- Geo 로그 커서가 최신 상태(0 이벤트 전달됨).
-
세컨더리 사이트에서:
- 왼쪽 사이드바에서 하단의 관리를 선택합니다.
- 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
- Sidekiq 대시보드에서 큐를 선택하고, 모든
geo
큐가 0 대기 및 0 실행 작업이 될 때까지 기다립니다. - 무결성 검사 실행을 통해 CI 아티팩트, LFS 객체 및 파일 저장소의 업로드 무결성을 확인합니다.
이 시점에서, 귀하의 세컨더리 사이트는 프라이머리 사이트가 가진 모든 내용의 최신 복사본을 포함하고 있으며, 장애 조치 시 손실되는 내용이 없습니다.
-
마지막 단계에서는 프라이머리 사이트를 영구적으로 비활성화해야 합니다.
프라이머리 사이트가 오프라인이 될 때, 프라이머리 사이트에 복제되지 않은 데이터가 있을 수 있습니다. 이 데이터는 진행할 경우 손실된 것으로 간주되어야 합니다.프라이머리 도메인 DNS 레코드를 업데이트할 계획이라면, 전파 속도를 높이기 위해 지금 TTL을 낮추는 것이 좋습니다.장애 조치를 수행할 때, 두 개의 서로 다른 GitLab 인스턴스에서 쓰기가 발생하는 스플릿 브레인 상황을 피해야 합니다. 따라서 장애 조치를 준비하기 위해 프라이머리 사이트를 비활성화해야 합니다:
-
프라이머리 사이트에 SSH 접근이 있는 경우, GitLab을 중지하고 비활성화합니다:
sudo gitlab-ctl stop
서버가 예기치 않게 재부팅될 경우 GitLab이 다시 시작되지 않도록 합니다:
sudo systemctl disable gitlab-runsvdir
(CentOS 전용) CentOS 6 이하의 경우, 머신이 재부팅될 경우 GitLab이 시작되는 것을 방지하는 쉬운 방법이 없습니다 (see issue 3058).
가장 안전한 방법은sudo yum remove gitlab-ee
를 사용하여 GitLab 패키지를 완전히 제거하는 것입니다.(Ubuntu 14.04 LTS) 이전 버전의 Ubuntu 또는 Upstart init 시스템을 기반으로 하는 다른 배포판을 사용 중인 경우, 원하지 않는 경우 GitLab이 시작되는 것을 방지할 수 있습니다root
로
initctl stop gitlab-runsvvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configuration
. -
프라이머리 사이트에 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을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인하세요.
성공하면, 보조 사이트가 이제 기본 사이트로 승격되었습니다.
다음 단계
지리적 중복성을 가능한 한 빨리 회복하기 위해, 새로운 보조 사이트를 추가하세요. 이를 위해, 이전 기본을 새로운 보조로 다시 추가하고 온라인 상태로 복원할 수 있습니다.