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

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

Tier: Premium, Ultimate Offering: Self-managed
Status: Experiment

재해 복구(Geo) 프로모션 런북입니다.

이 런북은 실험입니다. 완전한 프로덕션 준비 문서는 재해 복구 문서를 참조하세요.

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

구성요소	구성
PostgreSQL	Linux 패키지로 관리
Geo 사이트	단일 노드
세컨더리	하나

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

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

이 가이드를 따르면 다음 결과가 발생합니다:

오프라인이 된 프라이머리.
이제 새로운 프라이머리가 된 프로모트된 세컨더리.

다음은 다루지 않습니다:

이전 프라이머리를 세컨더리로 다시 추가하기.
새로운 세컨더리 추가하기.

준비

이 단계들을 따르기 전에, 세컨더리를 프로모트할 수 있도록 root 접근 권한이 있는지 확인하세요. Geo 복제본을 프로모트하고 장애 조치를 수행하는 자동화된 방법이 제공되지 않기 때문입니다.

세컨더리 사이트에서, 관리 영역 > Geo 대시보드로 이동하여 상태를 검토합니다. 복제된 객체(녹색으로 표시)는 거의 100%에 가깝고 실패가 없어야 합니다(빨간색으로 표시). 만약 대량의 객체가 아직 복제되지 않았다면(회색으로 표시) 사이트가 완료될 때까지 더 많은 시간을 주는 것을 고려하세요.

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

복제 실패의 일반적인 원인은 프라이머리 사이트에 데이터가 누락되어 있는 것입니다 - 이러한 실패는 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거하여 해결할 수 있습니다.

유지 보수 창은 Geo 복제 및 검증이 완전히 완료될 때까지 종료되지 않습니다. 활성 사용 중에는 이러한 프로세스가 가능한 100%에 가까워야 유지 보수 창을 짧게 유지할 수 있습니다.

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

읽기 전용 모드가 구현될 때까지 수동으로 프라이머리 사이트에서 업데이트가 발생하지 않도록 해야 합니다. 유지 보수 창 동안 세컨더리 사이트는 여전히 프라이머리 사이트에 대한 읽기 전용 접근이 필요합니다:
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 트래픽 차단되었는지 확인하기 위해 다른 IP를 통해 브라우저에서 방문해보세요. 서버는 연결을 거부해야 합니다.
3. 프라이머리 사이트가 Git over SSH 트래픽 차단되었는지 확인하기 위해 SSH 원격 URL로 기존 Git 리포지토리를 풀어보세요. 서버는 연결을 거부해야 합니다.
4. 프라이머리 사이트에서:
  1. 왼쪽 사이드바에서 하단의 관리를 선택합니다.
  2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
  3. Sidekiq 대시보드에서 크론을 선택합니다.
  4. Disable All을 선택하여 Geo와 관련없는 주기적인 백그라운드 작업을 비활성화합니다.
  5. geo_sidekiq_cron_config_worker 크론 작업을 위해 Enable을 선택합니다.
    이 작업은 계획된 장애 조치가 성공적으로 완료되기 위해 필수적인 여러 다른 크론 작업을 재활성화합니다.
모든 데이터의 복제 및 검증을 완료합니다:

모든 데이터가 자동으로 복제되지는 않습니다. 제외된 내용에 대해 더 읽어보세요.
1. Geo에 의해 관리되지 않는 모든 데이터의 복제를 수동으로 수행하고, 지금 마지막 복제 프로세스를 시작합니다.
2. 프라이머리 사이트에서:
  1. 왼쪽 사이드바에서 하단의 관리를 선택합니다.
  2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
  3. Sidekiq 대시보드에서 큐를 선택하고, geo가 포함되지 않은 모든 큐가 0으로 떨어질 때까지 기다립니다.
    이 큐에는 사용자가 제출한 작업이 포함되어 있습니다; 완료되기 전에 장애 조치를 수행하면 작업이 손실됩니다.
  4. 왼쪽 사이드바에서 Geo > 사이트를 선택하고, 실패 조치할 세컨더리 사이트에 대해 다음 조건이 충족될 때까지 기다립니다:
    - 모든 복제 측정기가 100% 복제됨, 0% 실패.
    - 모든 검증 측정기가 100% 검증됨, 0% 실패.
    - 데이터베이스 복제 지연이 0 ms.
    - Geo 로그 커서가 최신 상태(0 이벤트 전달됨).
3. 세컨더리 사이트에서:
  1. 왼쪽 사이드바에서 하단의 관리를 선택합니다.
  2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
  3. Sidekiq 대시보드에서 큐를 선택하고, 모든 geo 큐가 0 대기 및 0 실행 작업이 될 때까지 기다립니다.
  4. 무결성 검사 실행을 통해 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을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인하세요.

성공하면, 보조 사이트가 이제 기본 사이트로 승격되었습니다.

다음 단계

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

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

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

준비

보조 사이트 승격

다음 단계

도움말

기능 사용 가능성과 제품 평가판

도움받기