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

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

Tier: 프리미엄, 얼티메이트 Offering: Self-Managed Status: Experiment

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

경고: 이 런북은 실험입니다. 완전하고 실전에 준비된 문서를 보려면 재해 복구 설명서를 참조하세요.

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

구성요소	구성
PostgreSQL	리눅스 패키지에서 관리됨
Geo 사이트	단일 노드
Secondary	하나

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

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

이 안내서는 다음 결과를 초래합니다:

오프라인 주 사이트.
새 주 사이트가 된 승격된 보조사이트.

다루지 않는 사항:

이전 주를 다시 보조로 추가하는 것.
새로운 보조 추가.

준비 작업

참고: 위의 단계를 따르기 전에, 자동으로 Geo 복제본을 승격하고 장애 조치를 수행할 방법이 제공되지 않으므로, 보조에 root 액세스가 있는지 확인하세요.

보조 사이트에서 Admin 영역 > Geo 대시보드로 이동하여 상태를 검토하세요. 복제된 개체(초록색으로 표시됨)는 거의 100%에 가까워야 하며, 실패 사항(빨간색으로 표시됨)은 없어야 합니다. 아직 복제되지 않은 개체의 비율이 많은 경우(회색으로 표시됨), 사이트가 완료되는 데 더 많은 시간이 필요한지 고려하세요.

복제되지 않는 모든 데이터의 경우 유지 보수 기간이 종료되지 않습니다. 가능한 한 기간을 짧게 유지하려면 이러한 프로세스가 적극적으로 사용되는 동안 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 트래픽에 차단되었는지 브라우저로 확인하여 확인하세요.
3. SSH 트래픽에 대한 주 사이트가 차단되었는지 확인하기 위해 SSH 원격 URL을 가진 기존 Git 저장소에서 pull을 시도하여 확인하세요. 서버는 연결을 거부해야 합니다.
4. 주 사이트에서:
  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
  3. Sidekiq 대시보드에서 Cron을 선택합니다.
  4. geo_sidekiq_cron_config_worker cron 작업의 중요하지 않은 백그라운드 작업을 끄기 위해 모두 비활성화를 선택합니다. 이 작업은 계획된 장애 조치가 성공적으로 완료되는 데 필수적인 여러 다른 cron 작업을 다시 활성화합니다.
모든 데이터의 복제와 확인을 완료합니다:
경고: 모든 데이터가 자동으로 복제되지는 않습니다. 더 많은 정보는 제외되는 항목을 읽어보세요.
1. 수동으로 복제 중인 Geo에서 관리되지 않는 데이터가 있는 경우, 최종 복제 프로세스를 트리거하세요.
2. 주 사이트에서:
  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 Admin을 선택하세요.
  2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택하세요.
  3. Sidekiq 대시보드에서 Queues를 선택하고 모든 큐가 이름에 geo가 없는 것을 제외한 모든 큐가 0이 될 때까지 기다립니다. 이러한 큐는 사용자가 제출한 작업을 포함하며, 이러한 작업이 완료되기 전에 장애 조치를 수행하면 작업이 손실될 수 있습니다.
  4. 왼쪽 사이드바에서 Geo > Sites를 선택하고 다음 조건이 완전히 충족될 때까지 보조 사이트에 대한 다음 조건을 충족할 때까지 기다리세요:
    - 모든 복제 미터가 100% 복제됨, 0% 실패.
    - 모든 확인 미터가 100% 확인됨, 0% 실패.
    - 데이터베이스 복제 지연이 0 ms입니다.
    - Geo 로그 커서가 최신 상태임 (0 이벤트가 뒤에 있음).
3. 보조 사이트에서:
  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 Admin을 선택하여 1 1
  2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
  3. Sidekiq 대시보드에서 Queues를 선택하고 모든 geo 큐가 0으로 큐에 들어간 기록과 실행 중인 작업이 없을 때까지 기다립니다.
  4. 무결성 확인을 실행하여 CI 아티팩트, LFS 객체 및 파일 저장소의 무결성을 검증하세요.
이 시점에서 보조 사이트에는 주 사이트에 있는 모든 것의 최신 복사본이 포함되어 있으므로 장애 조치 중에 데이터가 손실되지 않습니다.
마지막 단계에서는 주 사이트를 영구적으로 비활성화해야 합니다.
경고: 주 사이트가 오프라인 상태가 되면 주 사이트에 저장된 복제되지 않은 데이터가 있을 수 있습니다. 이 데이터는 손실될 수 있으므로 이에 대비해야 합니다.
참고: 주 도메인 DNS 레코드를 업데이트할 계획이 있다면 트랜잭션 정리(TTL)를 지금 낮추어 전파 속도를 높이는 것이 좋습니다.
장애 조치를 수행할 때는 두 개의 GitLab 인스턴스에서 쓰기가 발생할 수 있는 스플릿 브레인 상황을 피하고자 합니다. 따라서 장애 조치를 준비하기 위해 주 사이트를 비활성화해야 합니다:
- 주 사이트에 SSH 액세스 권한이 있는 경우, GitLab을 중지하고 비활성화하세요:
```
sudo gitlab-ctl stop
```
  서버가 예상치 못한 재부팅이 발생하더라도 GitLab이 다시 시작되지 않도록 방지하세요:
```
sudo systemctl disable gitlab-runsvdir
```
  참고: (CentOS 전용) CentOS 6 이하에서는 기계가 재부팅될 때 GitLab이 시작되지 않은 경우에 대한 쉬운 해결책이 없으며(해당 이슈 3058 참조), sudo yum remove gitlab-ee를 사용하여 GitLab 패키지를 완전히 제거하는 것이 가장 안전할 수 있습니다.
  참고: (Ubuntu 14.04 LTS 전용) 오래된 버전의 우분투나 Upstart 초기화 시스템을 기반으로 하는 다른 배포판을 사용하는 경우 root로서 기계가 재부팅될 때 GitLab이 시작되는 것을 방지할 수 있습니다. 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 계획된 장애 조치

준비 작업

보조 사이트 홍보

다음 단계

도움말

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

도움받기