단일 보조 구성에서 보조 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. 기본 사이트에 SSH로 접속하여 GitLab을 중지하고 비활성화합니다:
```
sudo gitlab-ctl stop
```
2. 서버가 예기치 않게 재부팅될 경우 GitLab이 다시 시작되지 않도록 방지합니다:
```
sudo systemctl disable gitlab-runsvdir
```
기본 사이트에 SSH 접근 권한이 없는 경우, 머신을 오프라인 상태로 만들고 재부팅을 방지하기 위해 사용할 수 있는 모든 수단을 동원해야 합니다.
다음을 수행해야 할 수 있습니다:
- 로드 밸런서를 재구성합니다.
- DNS 레코드를 변경합니다(예: 기본 DNS 레코드를 보조 사이트로 포인팅하여 기본 사이트의 사용을 중지합니다).
- 가상 서버를 중지합니다.
- 방화벽을 통해 트래픽을 차단합니다.
- 기본 사이트에서 객체 저장소 권한을 철회합니다.
- 머신을 물리적으로 분리합니다.
기본 도메인 DNS 레코드 업데이트를 계획하고 있다면, DNS 변경 사항의 빠른 전파를 보장하기 위해 낮은 TTL을 유지하는 것이 좋습니다.

기본 사이트의 /etc/gitlab/gitlab.rb 파일은 이 과정에서 보조 사이트에 자동으로 복사되지 않습니다.
기본의 /etc/gitlab/gitlab.rb 파일을 백업하여 나중에 보조 사이트에서 필요한 값을 복원할 수 있도록 하십시오.

단계 3. 보조 사이트 승격

보조 사이트를 승격할 때 다음 사항에 유의하십시오:

보조 사이트가 일시 중지된 경우, 승격은 마지막으로 알려진 상태로의 시점 복구를 수행합니다.
보조가 일시 중지된 동안 기본에서 생성된 데이터는 손실됩니다.
이 시점에서 새로운 보조를 추가해서는 안 됩니다. 새로운 보조를 추가하려면, 보조를 기본으로 승격하는 전체 프로세스를 완료한 후에 하십시오.
이 과정에서 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류 메시지가 발생하는 경우, 자세한 내용은 장애 조치 문제 해결 조언을 참조하십시오.
별도의 URL을 사용하는 경우, 기본 도메인 DNS를 새로 승격된 사이트로 포인팅해야 합니다. 그렇지 않으면, 러너는 새로 승격된 사이트에 다시 등록해야 하며, 모든 Git 원격, 즐겨찾기 및 외부 통합을 업데이트해야 합니다.
위치 인식 DNS를 사용하고 있다면, 이전 기본이 DNS 항목에서 제거될 때 러너가 자동으로 새 기본에 연결되어야 합니다.
이전 기본에 연결된 러너가 돌아올 것으로 예상하지 않는 경우, 이를 제거해야 합니다:
- UI를 통해:
  1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.
  2. CI/CD > Runners를 선택하고 제거합니다.
- Runners API를 사용하여.

단일 노드에서 실행 중인 보조 사이트 승격

보조 사이트에 SSH로 접속하여 다음을 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면, 보조 사이트가 이제 기본 사이트로 승격됩니다.

여러 노드가 있는 보조 사이트 승격

보조 사이트에 있는 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트의 노드를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트에 있는 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면, 보조 사이트가 이제 기본 사이트로 승격됩니다.

Patroni 대기 클러스터를 사용한 보조 사이트 승격

보조 사이트에 있는 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트에 있는 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면, 보조 사이트가 이제 기본 사이트로 승격됩니다.

외부 PostgreSQL 데이터베이스가 있는 보조 사이트 승격

gitlab-ctl geo promote 명령은 외부 PostgreSQL 데이터베이스와 함께 사용할 수 있습니다.

이 경우, 먼저 보조 사이트와 연관된 복제 데이터베이스를 수동으로 승격해야 합니다:

보조 사이트와 연관된 복제 데이터베이스를 승격합니다. 이 작업은 데이터베이스를 읽기-쓰기 설정으로 변경합니다. 데이터베이스가 호스팅되는 위치에 따라 지침이 다릅니다:

Amazon RDS
Azure PostgreSQL
Google Cloud SQL

다른 외부 PostgreSQL 데이터베이스의 경우, 다음 스크립트를 보조 사이트에 저장하고, 연결 매개변수를 환경에 맞게 수정한 후 실행하여 복제를 승격합니다:

#!/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

보조 사이트에 있는 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트에 있는 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면, 보조 사이트가 이제 기본 사이트로 승격됩니다.

4단계. (선택 사항) 기본 도메인 DNS 레코드 업데이트

기본 도메인의 DNS 레코드를 업데이트하여 secondary 사이트를 가리키도록 설정합니다.

이렇게 하면 기본 도메인에 대한 모든 참조를 업데이트할 필요가 없으며,

예를 들어 Git 원격 및 API URL을 변경할 수 있습니다.

secondary 사이트에 SSH로 로그인한 후 root로 로그인합니다:
```
sudo -i
```
기본 도메인의 DNS 레코드를 업데이트합니다. 기본 도메인의 DNS 레코드를 secondary 사이트를 가리키도록 업데이트한 후, secondary 사이트의 /etc/gitlab/gitlab.rb를 편집하여 새로운 URL을 반영합니다:
```
# 기존 external_url 구성 변경
external_url 'https://<new_external_url>'
```
참고: external_url을 변경해도 이전 secondary URL을 통한 액세스는 차단되지 않으며,

secondary DNS 레코드가 여전히 intact하는 한 가능합니다.
secondary의 SSL 인증서를 업데이트합니다:
- Let’s Encrypt 통합을 사용하는 경우, 인증서는 자동으로 업데이트됩니다.
- 수동으로 설정한 경우 secondary의 인증서를 primary에서 복사합니다. primary에 접근할 수 없는 경우, 새 인증서를 발급하고,
  
  주제 대체 이름에 primary와 secondary URL이 모두 포함되었는지 확인합니다. 다음 명령어로 확인할 수 있습니다:
```
/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 구성을 사용합니다.
새로 승격된 primary의 URL로 연결할 수 있는지 확인합니다.

기본 도메인에 대한 DNS 레코드를 업데이트한 경우,

이러한 변경 사항은 이전 DNS 레코드 TTL에 따라 아직 전파되지 않았을 수 있습니다.

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

위의 프로세스를 사용하여 secondary 사이트를 primary 사이트로 승격해도

새로운 primary 사이트에서 Geo가 활성화되지 않습니다.

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

6단계. 이전 secondary의 추적 데이터베이스 제거

모든 secondary는 primary의 모든 항목 동기화 상태를 저장하는 데 사용되는 특별한 추적 데이터베이스를 가지고 있습니다.

secondary가 이미 승격되었기 때문에,

추적 데이터베이스의 데이터는 더 이상 필요하지 않습니다.

다음 명령어로 데이터를 제거할 수 있습니다:

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

gitlab.rb 파일에 geo_secondary[] 구성 옵션이 활성화되어 있는 경우,

주석 처리하거나 제거한 후, 변경 사항이 반영되도록 GitLab을 재구성하십시오.

다중 보조 구성에서 보조 Geo 복제본 프로모션

하나 이상의 보조 사이트가 있고 그 중 하나를 프로모션해야 하는 경우,

단일 보조 구성에서 보조 Geo 사이트 프로모션을 따르는 것을 권장하며, 이후에 추가 단계가 두 가지 더 필요합니다.

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

새로운 주 사이트에 SSH로 접속하고 root로 로그인합니다:
```
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 # 하나 이상의 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 인스턴스에서 쓰기가 발생할 수 있는 split-brain 상황을 피하기 위해 모든 노력을 기울여야 하며, 복구 작업이 복잡해질 수 있습니다. 따라서 장애 조치를 준비하기 위해서는 주 사이트를 비활성화해야 합니다:

주 Kubernetes 클러스터에 접근할 수 있는 경우, 연결하여 GitLab webservice 및 Sidekiq pods를 비활성화합니다:

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)에 대해 Linux 패키지를 사용하여 노드에 SSH로 접속하고 다음 명령어 중 하나를 실행합니다:
- Kubernetes 클러스터 외부의 보조 사이트 노드를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 Kubernetes 클러스터 외부의 보조 사이트 노드를 기본으로 승격하려면:
```
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`	`true`이면 승격 전에 Silent Mode를 활성화합니다 (GitLab 16.4 이상)

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 <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
```
이전에 보조를 위해 사용된 URL을 사용하여 새로 승격된 기본에 연결할 수 있는지 확인합니다.
성공! 보조가 이제 기본으로 승격되었습니다.

문제 해결

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

재해 복구(Geo)

단일 보조 구성에서 보조 Geo 사이트 승격

단계 1. 복제를 마치도록 허용

단계 2. 기본 사이트 영구 비활성화

단계 3. 보조 사이트 승격

단일 노드에서 실행 중인 보조 사이트 승격

여러 노드가 있는 보조 사이트 승격

Patroni 대기 클러스터를 사용한 보조 사이트 승격

외부 PostgreSQL 데이터베이스가 있는 보조 사이트 승격

4단계. (선택 사항) 기본 도메인 DNS 레코드 업데이트

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

6단계. 이전 secondary의 추적 데이터베이스 제거

다중 보조 구성에서 보조 Geo 복제본 프로모션

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

단계 2. 복제 프로세스 시작

GitLab Helm 차트에서 보조 Geo 클러스터 프로모션

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

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

3단계. 보조 클러스터 승격

문제 해결

도움말

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

도움받기