단일 보조 구성에서 보조 Geo 사이트를 프로모션하는 방법
다중 secondary 구성에서 secondary Geo 레플리카 승급
- 단계 1. 새로운 primary 사이트가 하나 이상의 secondary 사이트를 제공할 수 있도록 준비
- 단계 2. 복제 프로세스 시작
GitLab Helm 차트에서 secondary Geo 클러스터 승급
문제 해결

재해 복구 (Geo)

Tier: Premium, Ultimate Offering: Self-Managed

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

다중 보조 설정은 모든 비홍보된 보조 및 재구성 및 구성을 완전히 다시 동기화해야 하며 다운타임을 발생시킵니다.

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

현재 우리는 Geo 레플리카를 프로모션하고 장애 조치(failover)를 자동화하는 방법을 제공하지 않지만, 머신에 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을 유지하는 것이 좋습니다.

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

보조 프로모션 시 다음 사항을 참고하세요.

보조 사이트가 일시 중지된 경우 프로모션을 실행하면 알려진 마지막 상태로 시점 복구를 수행합니다. 보조가 일시 중지된 동안 주에서 생성된 데이터는 손실됩니다.
이 시점에 새로운 보조를 추가해서는 안됩니다. 새로운 보조를 추가하려면 보조를 주로 프로모션한 프로세스를 완료한 후에 진행하세요.
이 프로세스 중에 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류 메시지가 발생하면 문제 해결 팁을 참조하세요.
별도의 URL을 사용하는 경우, 주 도메인 DNS를 새로 프로모션된 사이트에 지정해야 합니다. 그렇지 않으면 러너를 다시 등록해야 하며, 모든 Git 리모트, 북마크 및 외부 통합을 업데이트해야 합니다.
위치 인식 공용 URL을 사용하는 경우, 이전 주가 DNS 항목에서 제거된 후 러너가 자동으로 새로운 주로 연결해야 합니다.
이전 주에 연결된 러너가 다시 나타나지 않을 것으로 예상된다면 제거해야 합니다.
- UI를 통해:
  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
  2. CI/CD > 러너를 선택하고 제거합니다.
- 러너 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 데이터베이스의 경우, 예를 들어 다음 스크립트를 /tmp/geo_promote.sh과 같이 저장하고 연결 매개변수를 환경에 맞게 수정 한 다음 레플리카를 프로모션하기 위해 실행합니다.

#!/bin/bash
     
PG_SUPERUSER=postgres
     
# 여기에 pg_ctl 바이너리의 경로를 입력하십시오. PostgreSQL 설치와 경로가 다를 수 있으므로 경로를 조정해야 할 수 있습니다. 또는 PostgreSQL에서 `SHOW data_directory;`를 실행하여 데이터 디렉터리를 찾을 수 있습니다.
PG_CTL_BINARY=/usr/lib/postgresql/10/bin/pg_ctl
     
# 여기에 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
```
보조 사이트의 각 레일스 노드로 SSH하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 주 사이트로 프로모션하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 주 사이트로 프로모션하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용한 URL을 사용하여 새로 프로모션된 주 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트는 이제 주 사이트로 프로모션됩니다.

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

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

Secondary 사이트로 SSH로 로그인합니다.
```
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 레코드가 여전히 존재하여야 합니다.
Secondary의 SSL 인증서를 업데이트합니다.
- Let’s Encrypt 통합을 사용하는 경우 인증서는 자동으로 업데이트됩니다.
- 매뉴얼으로 설정한 경우, secondary의 인증서를 primary에서 secondary로 복사합니다. primary에 액세스할 수 없는 경우, 새 인증서를 발급하고 이중 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 구성을 사용합니다.
새로 기본으로 올라간 primary에 연결 가능한지 확인합니다. 기본 도메인의 DNS 레코드를 업데이트했다면, DNS 레코드의 TTL에 따라 변경사항이 아직 반영되지 않을 수 있습니다.

단계 5. (선택사항) Secondary Geo 사이트를 승급된 Primary 사이트에 추가

위의 프로세스를 통해 secondary 사이트를 primary 사이트로 승급시켜도 새 primary 사이트에서는 아직 Geo가 활성화되어 있지 않습니다.

새 secondary 사이트를 온라인 상태로 전환하려면 Geo 설정 지침을 따르세요.

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

모든 secondary에는 primary에서 모든 항목의 동기화 상태를 저장하는 특수 추적 데이터베이스가 있습니다. secondary가 이미 승급되었기 때문에 추적 데이터베이스의 데이터는 더 이상 필요하지 않습니다.

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

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

gitlab.rb에서 활성화된 geo_secondary[] 구성 옵션이 있다면 주석 처리하거나 제거한 다음 GitLab을 다시 구성하여 변경사항이 적용되도록 합니다.

다중 secondary 구성에서 secondary Geo 레플리카 승급

여러 개의 secondary 사이트가 있는 경우 그 중 하나를 승급해야 하는 경우, 우리는 단일 secondary 구성에서 secondary Geo 사이트 승급를 따르는 것을 권장합니다. 그리고 그 뒤에 추가 단계가 2개 더 필요합니다.

단계 1. 새로운 primary 사이트가 하나 이상의 secondary 사이트를 제공할 수 있도록 준비

새 primary 사이트로 SSH로 로그인합니다.
```
sudo -i
```

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

## Geo Primary 역할을 활성화합니다. (아직 활성화하지 않았다면)
roles ['geo_primary_role']
   
##
# PostgreSQL 클라이언트 인증을 primary 및 secondary IP에서 허용합니다. 이 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']
   
# 모든 secondary 사이트가 자체 슬롯을 가져야 하므로, secondary 노드가 여러 개인 경우 각각의 secondary 사이트 수를 설정합니다
# postgresql['max_replication_slots'] = 1 # 두 개 이상의 Geo secondary 노드가 있는 경우 해당 수만큼 설정하세요
   
##
## 자동 데이터베이스 마이그레이션을 임시적으로 비활성화합니다
## (PostgreSQL이 재시작되고 개인 주소에서 청취하는 것이 확실해질 때까지)
##
gitlab_rails['auto_migrate'] = false

(이 설정에 대한 자세한 내용은 primary 서버 구성를 읽어보세요)

파일을 저장하고 데이터베이스 리슨 변경 및 복제 슬롯 변경이 적용되도록 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. 복제 프로세스 시작

이제 각 secondary 사이트가 새 primary 사이트에서의 변경 사항을 듣도록 설정해야 합니다. 이를 위해 복제 프로세스를 시작해야 합니다. 이전의 모든 복제 설정은 덮어쓰입니다.

GitLab Helm 차트에서 secondary Geo 클러스터 승급

클라우드 네이티브 Geo 배포를 업데이트할 때, 보조 Kubernetes 클러스터 외부의 모든 노드를 업데이트하는 프로세스는 비클라우드 네이티브 방식과 다르지 않습니다. 따라서 더 자세한 정보는 항상 단일 secondary 구성에서 secondary Geo 사이트 승급을 참고하실 수 있습니다.

아래 섹션은 ‘gitlab’ 네임스페이스를 사용한다고 가정합니다. 클러스터 설정 시 다른 네임스페이스를 사용한 경우, --namespace gitlab를 사용된 네임스페이스로 바꿔주셔야 합니다.

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

primary 사이트가 오프라인이되면 secondary 사이트에 아직 동기화되지 않은 데이터가 저장될 수 있습니다. 이 경우 그 데이터를 손실로 처리해야 합니다.

primary 사이트에서 장애가 발생하는 경우, 두 개의 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 스플릿 브레인 상황을 피하기 위해 모든 가능한 조치를 취해야 합니다. 따라서 장애 조치를 위해 primary 사이트를 비활성화해야 합니다:

primary Kubernetes 클러스터에 액세스할 수 있는 경우, GitLab webservice 및 Sidekiq pod를 비활성화합니다.

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

primary Kubernetes 클러스터에 액세스할 수 없는 경우, 클러스터를 오프라인으로 전환하고 다시 온라인으로 돌아오지 못하게 막아야 합니다. 다음과 같은 조치를 취해야 할 수 있습니다:
- 로드 밸런서 재구성
- DNS 레코드 변경 (예: primary DNS 레코드를 secondary 사이트를 가리키도록 변경하여 primary 사이트의 사용을 중지)
- 가상 서버 중지
- 방화벽을 통한 트래픽 차단
- primary 사이트에서 객체 리포지터리 권한 취소
- 물리적으로 컴퓨터를 연결 해제

단계 2. 클러스터 외부의 모든 secondary 사이트 노드 홍보

만약 보조 사이트가 일시 중지되었을 경우, 이것은 지난 알려진 상태로의 시점 복구를 수행합니다. 보조 사이트가 중지된 동안 주 사이트에서 생성된 데이터는 손실됩니다.

리눅스 패키지를 사용하여 secondary 쿠버네티스 클러스터 외부의 각 노드(예: PostgreSQL 또는 Gitaly)에 대해 노드에 SSH를하고 다음 명령어 중 하나를 실행하세요:
- secondary 사이트 노드를 쿠버네티스 클러스터 외부에서 주 사이트로 홍보하려면:
```
sudo gitlab-ctl geo promote
```
- secondary 사이트 노드를 쿠버네티스 클러스터 외부에서 별다른 확인 없이 주 사이트로 홍보하려면:
```
sudo gitlab-ctl geo promote --force
```

toolbox pod을 찾으세요:

kubectl --namespace gitlab get pods -lapp=toolbox

secondary를 홍보하세요:
```
kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_secondary_as_primary
```
환경 변수를 제공하여 작업의 동작을 수정할 수 있습니다. 사용 가능한 변수는 다음과 같습니다:

이름 기본값 설명

ENABLE_SILENT_MODE false true로 설정하면 홍보(버전 GitLab 16.4 이상) 전에 Silent 모드가 활성화됩니다

이름	기본값	설명
`ENABLE_SILENT_MODE`	`false`	`true`로 설정하면 홍보(버전 GitLab 16.4 이상) 전에 Silent 모드가 활성화됩니다

단계 3. secondary 클러스터 홍보

기존 클러스터 구성을 업데이트하세요.
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
```
secondary 클러스터를 주 클러스터로 홍보하려면 role: secondary를 role: primary로 업데이트하세요.
클러스터가 주 사이트로 유지되는 경우 psql 섹션 전체를 제거할 수 있습니다. 이는 추적 데이터베이스를 가리키며 주 사이트로 작동하는 동안 무시됩니다.
새 구성으로 클러스터를 업데이트하세요:
```
helm upgrade --install --version <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
```
이전에 secondary로 사용했던 URL을 사용하여 새로 홍보된 주 클러스터에 연결할 수 있는지 확인하세요.
성공! secondary가 이제 주로 홍보되었습니다.

문제 해결

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

재해 복구 (Geo)

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

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

단계 2. 주 사이트 영구적으로 사용 중지

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

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

여러 노드에서 실행 중인 보조 사이트 프로모션

Patroni 스탠바이 클러스터에서 실행 중인 보조 사이트 프로모션

외부 PostgreSQL 데이터베이스에서 실행 중인 보조 사이트 프로모션

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

단계 5. (선택사항) Secondary Geo 사이트를 승급된 Primary 사이트에 추가

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

다중 secondary 구성에서 secondary Geo 레플리카 승급

단계 1. 새로운 primary 사이트가 하나 이상의 secondary 사이트를 제공할 수 있도록 준비

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

GitLab Helm 차트에서 secondary Geo 클러스터 승급

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

단계 2. 클러스터 외부의 모든 secondary 사이트 노드 홍보

단계 3. secondary 클러스터 홍보

문제 해결

도움말

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

도움받기