단일 보조 구성에서 보조 Geo 사이트를 프로모션하는 방법
다중 보조 구성에서 보조 Geo 복제 승격
- 단계 1. 새로운 주 사이트를 구성하여 하나 이상의 보조 사이트를 제공하기
- 단계 2. 복제 프로세스를 시작합니다
GitLab Helm 차트에서 보조 Geo 클러스터 승격
문제 해결

재해 복구 (Geo)

Tier: Premium, Ultimate Offering: Self-managed

Geo는 데이터베이스, Git 리포지터리 및 기타 몇 가지 에셋을 복제하지만 일부 제한 사항이 있습니다.

다중 보조 구성은 모든 미승격 보조 서버의 완전한 재동기화와 재구성을 필요로 하며, 다운타임을 발생시킵니다.

단일 보조 구성에서 보조 Geo 사이트를 프로모션하는 방법

현재 자동화된 방법으로 Geo 레플리카를 프로모션하고 장애 조치를 하는 기능은 제공하지 않지만, 해당 머신에 root 액세스 권한이 있다면 매뉴얼으로 수행할 수 있습니다.

이 프로세스는 보조 Geo 사이트를 주 서비스 사이트로 프로모션합니다. 지리적인 중복성을 최대한 빨리 되찾으려면, 이 지침을 따른 후에 즉시 새로운 보조 사이트를 추가해야 합니다.

단계 1. 복제가 가능한 경우 복제 완료를 허용

보조 사이트가 여전히 주 사이트에서 데이터를 복제 중이라면, 불필요한 데이터 손실을 피하기 위해 가능한 한 계획된 장애 조치 문서를 준수하세요.

단계 2. 주 사이트 영구적으로 비활성화

주 사이트가 오프라인 상태가 되면, 주 사이트에 저장된 데이터 중 보조 사이트로 복제되지 않은 데이터가 있을 수 있습니다. 이 경우 진행한다면 해당 데이터를 손실된 것으로 취급해야 합니다.

주 사이트에 장애가 발생하면, GitLab의 두 곳에서 쓰기가 발생하여 복구 작업이 복잡해질 수 있는 스플릿 브레인 상황을 피하기 위해 최대한 노력해야 합니다. 따라서 장애 조치를 준비하기 위해 반드시 주 사이트를 비활성화해야 합니다.

SSH 액세스가 있는 경우:
1. GitLab을 중지하고 비활성화하기 위해 주 사이트에 SSH로 로그인:
```
sudo gitlab-ctl stop
```
2. 서버가 예기치 않게 다시 부팅되더라도 GitLab이 다시 시작되지 않도록 방지:
```
sudo systemctl disable gitlab-runsvdir
```
주 사이트에 SSH 액세스 권한이 없는 경우, 서버를 오프라인 상태로 전환하고 가능한 모든 수단으로 부팅을 방지하십시오. 다음을 수행해야 할 수 있습니다:
- 로드 밸런서 다시 구성.
- DNS 레코드 변경 (예: 주 DNS 레코드를 보조 사이트로 지정하여 주 사이트의 사용을 중지).
- 가상 서버 중지.
- 방화벽을 통한 트래픽 차단.
- 주 사이트에서 객체 리포지터리 권한 취소.
- 물리적으로 기계를 연결 해제.
주 도메인 DNS 레코드 업데이트를 계획 중이라면, DNS 변경이 신속하게 전파되도록 낮은 TTL을 유지하는 것이 좋습니다.

단계 3. 보조 사이트 프로모션

보조를 프로모션하는 경우 다음 사항을 확인하세요:

보조 사이트가 일시 중지된 경우, 프로모션은 마지막으로 알려진 상태로의 포인트 인 타임 복구를 수행합니다. 보조가 일시 중지된 동안 주 서비스에서 생성된 데이터는 손실됩니다.
이 시점에 새로운 보조를 추가해서는 안됩니다. 새로운 보조를 추가하려면 보조를 주로 프로모션하는 전체 프로세스를 완료한 후에 수행하세요.
이 프로세스 중에 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류 메시지가 발생하면, 자세한 내용은 문제 해결 팁을 참조하세요.
새로 프로모션된 사이트의 주 도메인 DNS 레코드를 가리키세요. 그렇지 않으면, 러너는 새로 프로모션된 사이트와 다시 등록해야 하며, 모든 Git 원격, 즐겨찾기 및 외부 통합을 업데이트해야 합니다.

단일 노드에서 실행되는 보조 사이트 프로모션

보조 사이트에 SSH로 로그인하여 다음을 실행:
- 보조 사이트를 주 서비스로 프로모션:
```
sudo gitlab-ctl geo promote
```
- 보조 사이트를 어떠한 추가 확인 없이 주 서비스로 프로모션:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용했던 URL을 사용하여 새로 프로모션된 주 사이트에 연결할 수 있는지 확인하세요.
성공하면, 보조 사이트는 이제 주 사이트로 프로모션되었습니다.

외부 PostgreSQL 데이터베이스를 사용하여 secondary 사이트를 홍보

gitlab-ctl geo promote 명령은 외부 PostgreSQL 데이터베이스와 함께 사용할 수 있습니다. 이 경우, 먼저 secondary 사이트와 연결된 복제 데이터베이스를 매뉴얼으로 홍보해야 합니다.

secondary 사이트와 관련된 복제 데이터베이스를 홍보합니다. 이렇게 함으로써 데이터베이스를 읽기/쓰기로 설정합니다. 데이터베이스가 호스팅되는 위치에 따라 지침이 다양합니다:

Amazon RDS
Azure PostgreSQL
Google Cloud SQL
다른 외부 PostgreSQL 데이터베이스의 경우, 다음 스크립트를 secondary 사이트에 저장하고, 예를 들어 /tmp/geo_promote.sh처럼 연결 매개변수를 환경에 맞게 수정합니다. 그런 다음 복제를 홍보하기 위해 실행합니다:

#!/bin/bash
   
PG_SUPERUSER=postgres
   
# 데이터베이스 pg_ctl 이진 파일에 대한 경로입니다. PostgreSQL 설치와 일치하도록 이 경로를 조정해야 할 수도 있습니다.
PG_CTL_BINARY=/usr/lib/postgresql/10/bin/pg_ctl
   
# PostgreSQL 데이터 디렉터리에 대한 경로입니다. PostgreSQL 설치와 일치하도록 이 경로를 조정해야 할 수도 있습니다. 또한 PostgreSQL에서 `SHOW data_directory;`를 실행하여 데이터 디렉터리를 찾을 수도 있습니다.
PG_DATA_DIRECTORY=/etc/postgresql/10/main
   
# PostgreSQL 데이터베이스를 홍보하고 읽기/쓰기 작업을 허용합니다.
sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote

secondary 사이트의 각 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH를 하고 다음 명령 중 하나를 실행합니다:
- secondary 사이트를 프라이머리로 홍보하려면:
```
sudo gitlab-ctl geo promote
```
- secondary 사이트를 프라이머리로 홍보하고 추가 확인 없이:
```
sudo gitlab-ctl geo promote --force
```
secondary 사이트의 각 Rails 노드에 SSH를 하고 다음 몹록 중 하나를 실행합니다:
- secondary 사이트를 프라이머리로 홍보하려면:
```
sudo gitlab-ctl geo promote
```
- secondary 사이트를 프라이머리로 홍보하고 추가 확인 없이:
```
sudo gitlab-ctl geo promote --force
```
이전에 secondary 사이트에 사용한 URL을 사용하여 새로 홍보된 primary 사이트에 연결할 수 있는지 확인합니다.
성공적으로 연결되면, secondary 사이트가 이제 primary 사이트로 홍보되었습니다.

단계 4. (선택 사항) 프라이머리 도메인 DNS 레코드 업데이트

프라이머리 도메인의 DNS 레코드를 secondary 사이트를 가리키도록 업데이트합니다. 이렇게 하면 프라이머리 도메인에 대한 모든 참조를 업데이트할 필요가 없어집니다. 예를 들어 Git 리모트 및 API URL을 변경할 필요가 없어집니다.

secondary 사이트에 SSH를하고 root로 로그인합니다:
```
sudo -i
```
프라이머리 도메인의 DNS 레코드를 업데이트합니다. 프라이머리 도메인의 DNS 레코드를 secondary 사이트를 가리키도록 업데이트한 후, /etc/gitlab/gitlab.rb를 편집하여 새 URL을 반영합니다:
```
# 기존 external_url 구성을 변경합니다.
external_url 'https://<new_external_url>'
```
external_url을 변경하더라도 이전의 secondary URL을 통한 액세스를 방지하지 않습니다. 외부 DNS 레코드가 여전히 유지되는 한 이전 secondary URL을 통한 액세스가 가능합니다.
secondary의 SSL 인증서를 업데이트합니다:
- Let’s Encrypt 통합을 사용하는 경우, 인증서는 자동으로 업데이트됩니다.
- 매뉴얼으로 설치한 경우(매뉴얼으로 HTTPS 설정하기), secondary의 인증서를 primary에서 secondary로 복사합니다. primary에 액세스할 수 없는 경우 새 인증서를 발급하고, primary 및 secondary URL이 subject alternative names에 포함되어 있는지 확인합니다. 다음과 같이 확인할 수 있습니다:
```
/opt/gitlab/embedded/bin/openssl x509 -noout -dates -subject -issuer \
    -nameopt multiline -ext subjectAltName -in /etc/gitlab/ssl/new-gitlab.new-example.com.crt
```
변경 사항이 적용되도록 secondary 사이트를 다시 구성합니다:
```
gitlab-ctl reconfigure
```
새로 홍보된 primary 사이트 URL을 업데이트하려면 아래 명령을 실행합니다:
```
gitlab-rake geo:update_primary_node_url
```
이 명령은 /etc/gitlab/gitlab.rb에 정의된 변경된 external_url 구성을 사용합니다.
GitLab 12.0에서 12.7까지는 primary 사이트의 이름을 데이터베이스에서 업데이트해야 할 수 있습니다. 이 버그는 GitLab 12.8에서 수정되었습니다.
이를 확인하려면 /etc/gitlab/gitlab.rb 파일에서 gitlab_rails["geo_node_name"] 설정을 찾아야 합니다. 주석 처리되었으면 # 또는 찾을 수 없으면 데이터베이스에서 primary 사이트의 이름을 업데이트해야 합니다. 다음과 같이 검색할 수 있습니다:
```
grep "geo_node_name" /etc/gitlab/gitlab.rb
```
데이터베이스에서 primary 사이트의 이름을 업데이트하려면:
```
gitlab-rails runner 'Gitlab::Geo.primary_node.update!(name: GeoNode.current_node_name)'
```
변경사항이 적용되도록 새로 홍보된 primary를 사용하여 연결할 수 있는지 확인합니다. 프라이머리 도메인의 DNS 레코드를 업데이트했다면, 이러한 변경 사항이 이전 DNS 레코드 TTL에 따라 아직 전파되지 않을 수 있습니다.

단계 5. (선택 사항) primary 사이트에서 secondary Geo 사이트 추가

위의 프로세스를 사용하여 secondary 사이트를 primary 사이트로 홍보하면 새 primary 사이트에서 Geo가 사용되지 않습니다.

새로운 secondary 사이트를 온라인으로 가져오려면 Geo 설정 지침을 따르세요.

단계 6. 이전 보조의 추적 데이터범의 제거

모든 보조에는 이전 주에서 모든 항목의 동기화 상태를 저장하는 데 사용되는 특수 추적 데이터베이스가 있습니다. 보조가 이미 승격되었기 때문에 해당 추적 데이터베이스의 데이터는 더 이상 필요하지 않습니다.

다음 명령을 사용하여 데이터를 삭제할 수 있습니다.

sudo rm -rf /var/opt/gitlab/geo-postgresql

gitlab.rb에 활성화된 geo_secondary[] 구성 옵션이 있는 경우 해당 옵션을 주석 처리하거나 제거하고, 변경 사항이 적용되려면 GitLab을 재구성하십시오.

다중 보조 구성에서 보조 Geo 복제 승격

다수의 보조 사이트가 있는 경우 하나를 승격해야하는 경우, 당사는 단일 보조 구성에서 보조 Geo 사이트를 승격하는 것을 권장하며 그 후에 두 가지 추가 단계가 필요합니다.

단계 1. 새로운 주 사이트를 구성하여 하나 이상의 보조 사이트를 제공하기

새로운 주 사이트로 SSH로 로그인합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb를 편집합니다.

## Geo Primary 역할을 활성화합니다(아직 활성화하지 않은 경우)
roles ['geo_primary_role']
   
##
# **주** 및 **보조** IP에서의 PostgreSQL 클라이언트 인증을 허용합니다. 이 IP는 예를 들어 CIDR 형식의 공개 또는 VPC 주소일 수 있습니다. ['198.51.100.1/32', '198.51.100.2/32']와 같이 지정합니다.
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']
   
# 각 보조 사이트마다 자체 슬롯이 필요하므로 보조 사이트 수를 지정합니다.
# postgresql['max_replication_slots'] = 1 # 1보다 많은 Geo 보조 노드가 있다면 해당 수로 설정합니다.
   
##
## 자동 데이터베이스 마이그레이션을 일시적으로 비활성화합니다
## (PostgreSQL이 재시작되고 개인 주소에서 수신 대기할 때까지)
##
gitlab_rails['auto_migrate'] = false

(이러한 설정에 대한 자세한 내용은 기본 서버 구성을 참조하십시오)

파일을 저장하고 데이터베이스 수신 대기 변경 및 복제 슬롯 변경이 적용되도록 GitLab을 재구성합니다.
```
gitlab-ctl reconfigure
```
변경 사항이 적용되도록 PostgreSQL을 다시 시작합니다.
```
gitlab-ctl restart postgresql
```
PostgreSQL이 다시 시작되고 개인 주소에서 수신 대기하기 때문에 마이그레이션을 다시 활성화합니다.
/etc/gitlab/gitlab.rb를 편집하고 설정을 true로 변경합니다.
```
gitlab_rails['auto_migrate'] = true
```
파일을 저장하고 GitLab을 다시 구성합니다.
```
gitlab-ctl reconfigure
```

단계 2. 복제 프로세스를 시작합니다

이제 각 보조 사이트가 새 주 사이트의 변경 사항을 수신 대기하도록 만들어야 합니다. 이를 위해 복제 프로세스를 시작해야하지만 이번에는 또 다른 주 사이트를 위해 재작성됩니다.

GitLab Helm 차트에서 보조 Geo 클러스터 승격

클라우드 네이티브 Geo 배포를 업데이트할 때, 보조 Kubernetes 클러스터 외부에있는 노드를 업데이트하는 프로세스는 클라우드 네이티브가 아닌 방법과 다르지 않습니다. 따라서 더 많은 정보를 위해서는 단일 보조 구성에서 보조 Geo 사이트를 승격으로 이동할 수 있습니다.

다음 섹션에서는 gitlab 네임스페이스를 사용하고 있다고 가정합니다. 클러스터를 설정할 때 다른 네임스페이스를 사용한 경우 --namespace gitlab를 자신의 네임스페이스로 교체해야합니다.

단계 1. 주 클러스터를 영구적으로 비활성화합니다.

주 사이트가 오프라인 상태가 되면 주 사이트에 저장된 데이터가 보조 사이트로 복제되지 않은 데이터가 있을 수 있습니다. 이 경우 해당 데이터는 손실된 것으로 간주해야 합니다.

주 사이트에 장애가 발생하면, 보조 사이트에서 쓰기 작업이 두 개의 다른 GitLab 인스턴스에서 발생하는 분리 된 상황을 피하기 위해 최대한 노력해야 합니다. 따라서 장애 조치를 준비하려면 주 사이트를 비활성화해야합니다.

주 Kubernetes 클러스터에 액세스 할 수있는 경우, GitLab webservice 및 Sidekiq 포드를 비활성화하십시오.

kubectl --namespace gitlab scale deploy gitlab-geo-webservice-default --replicas=0
kubectl --namespace gitlab scale deploy gitlab-geo-sidekiq-all-in-1-v1 --replicas=0

주 Kubernetes 클러스터에 액세스 할 수 없는 경우 클러스터를 오프라인 상태로 전환하고 자체 재가동 방법을 통해 다시 온라인 상태로 전환되지 않도록합니다. 다음과 같은 작업을 수행해야 할 수 있습니다.
- 로드 밸런서 재구성.
- DNS 레코드 변경 (주 DNS 레코드를 보조 사이트를 사용하여 사용을 중지하도록 함).
- 가상 서버 중지.
- 방화벽을 통한 트래픽 차단.
- 주 사이트의 오브젝트 스토리지 권한 해지.
- 물리적으로 기계를 연결 해제.

단계 2. 클러스터 외부의 모든 보조 사이트 노드를 승격합니다.

보조 사이트가 일시 중지된 경우, 이는 지정된 시점 복구를 수행하여 마지막으로 알려진 상태로 복구합니다. 보조가 일시 중지된 동안 주에서 작성된 데이터가 손실됩니다.

리눅스 패키지를 사용하는 보조 Kubernetes 클러스터 외부의 각 노드(예: PostgreSQL 또는 Gitaly)를위한 각 노드에 SSH로 연결하고 다음 명령 중 하나를 실행합니다.
- 보조 쿠버네티스 클러스터 외부의 보조 사이트 노드를 주로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 보조 쿠버네티스 클러스터 외부의 보조 사이트 노드를 추가 확인 없이 주로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```

toolbox 패드를 찾습니다.

kubectl --namespace gitlab get pods -lapp=toolbox

보조 사이트를 승격합니다.
```
kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_secondary_as_primary
```
환경 변수를 제공하여 작업의 동작을 수정할 수 있습니다. 가능한 환경 변수는 다음과 같습니다:

이름 기본 값 설명

ENABLE_SILENT_MODE false (GitLab 16.4 이상) 승격 전에 Silent Mode를 활성화합니다.

이름	기본 값	설명
`ENABLE_SILENT_MODE`	`false`	(GitLab 16.4 이상) 승격 전에 Silent Mode를 활성화합니다.

단계 3. 보조 클러스터 홍보

기존 클러스터 구성을 업데이트합니다.
Helm을 사용하여 기존 구성을 검색할 수 있습니다.
```
helm --namespace gitlab get values gitlab-geo > gitlab.yaml
```
기존 구성에는 다음과 유사한 Geo 섹션이 포함되어 있어야 합니다.
```
geo:
   enabled: true
   role: secondary
   nodeName: secondary.example.com
   psql:
      host: geo-2.db.example.com
      port: 5431
      password:
         secret: geo
         key: geo-postgresql-password
```
보조 클러스터를 주 클러스터로 홍보하려면 role: secondary를 role: primary로 업데이트합니다.
클러스터가 주 사이트로 남아 있는 경우 전체 psql 섹션을 제거할 수 있습니다. 이는 추적 데이터베이스를 참조하며 클러스터가 주 사이트로 작동하는 동안 무시됩니다.
새 구성으로 클러스터를 업데이트합니다.
```
helm upgrade --install --version <현재 차트 버전> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
```
이전에 보조로 사용했던 URL을 사용하여 새로 홍보된 주 클러스터에 연결할 수 있는지 확인합니다.
성공! 보조 클러스터가 이제 주 클러스터로 홍보되었습니다.

문제 해결

이 섹션은 다른 위치로 이동되었습니다.

재해 복구 (Geo)

단일 보조 구성에서 보조 Geo 사이트를 프로모션하는 방법

단계 1. 복제가 가능한 경우 복제 완료를 허용

단계 2. 주 사이트 영구적으로 비활성화

단계 3. 보조 사이트 프로모션

단일 노드에서 실행되는 보조 사이트 프로모션

외부 PostgreSQL 데이터베이스를 사용하여 secondary 사이트를 홍보

단계 4. (선택 사항) 프라이머리 도메인 DNS 레코드 업데이트

단계 5. (선택 사항) primary 사이트에서 secondary Geo 사이트 추가

단계 6. 이전 보조의 추적 데이터범의 제거

다중 보조 구성에서 보조 Geo 복제 승격

단계 1. 새로운 주 사이트를 구성하여 하나 이상의 보조 사이트를 제공하기

단계 2. 복제 프로세스를 시작합니다

GitLab Helm 차트에서 보조 Geo 클러스터 승격

단계 1. 주 클러스터를 영구적으로 비활성화합니다.

단계 2. 클러스터 외부의 모든 보조 사이트 노드를 승격합니다.

단계 3. 보조 클러스터 홍보

문제 해결

도움말

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

도움받기