• 단일 보조구성에서 보조 Geo 사이트 프로모션하기
  • 단계 1. 복제가 완료될 때까지 복제 허용
  • 단계 2. 주 사이트를 영구적으로 비활성화
  • 단계 3. 보조 사이트 프로모션
    • 단일 노드에서 실행 중인 보조 사이트 프로모션
    • 다중 노드를 가진 보조 사이트 프로모션
    • Patroni 스탠바이 클러스터를 사용하여 보조 사이트를 홍보하는 방법
    • 외부 PostgreSQL 데이터베이스를 사용하여 보조 사이트를 홍보하는 방법
  • 단계 4. (선택 사항) 기본 도메인 DNS 레코드 업데이트
  • 단계 5. (선택 사항) 보조 Geo 사이트를 프로모션된 주 사이트에 추가
  • 단계 6. 이전 보조의 추적 데이터베이스 제거
• 다중 보조 구성에서 보조 Geo 복제 프로모션
  • 단계 1. 새로운 주 사이트를 하나 이상의 보조 사이트로 제공할 수 있도록 준비
  • 단계 2. 복제 프로세스 시작
• GitLab Helm 차트에서 보조 Geo 클러스터 프로모션
  • 단계 1. 주 클러스터 영구적으로 비활성화
  • 단계 2. 클러스터 외부의 모든 secondary 사이트 노드를 홍보합니다
  • 단계 3. secondary 클러스터를 홍보합니다
• 문제 해결

재해 복구(Geo)

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 오류 메시지가 발생하면, 자세한 내용은 다음 문제 해결 안내를 참조하세요.
• 주 도메인 DNS를 새로 프로모션된 사이트로 지정. 그렇지 않으면, 러너는 새로 프로모션된 사이트에 다시 등록해야 하며, 모든 Git 원격, 북마크 및 외부 통합을 업데이트해야 합니다.

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

1. 보조 사이트에 SSH하여 다음을 실행:

   • 보조 사이트를 주 사이트로 프로모션:

     sudo gitlab-ctl geo promote
     

   • 보조 사이트를 주 사이트로 프로모션 확인을 건너뛰고:

     sudo gitlab-ctl geo promote --force
     

2. 이전에 보조 사이트에 사용한 URL을 사용하여 새로 프로모션된 주 사이트에 연결할 수 있는지 확인합니다.
3. 성공하면 보조 사이트가 이제 주 사이트로 프로모션되었습니다.

다중 노드를 가진 보조 사이트 프로모션

1. 보조 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH하여 다음 명령 중 하나를 실행합니다:

   • 보조 사이트의 노드를 주 사이트로 프로모션:

     sudo gitlab-ctl geo promote
     

   • 보조 사이트를 주 사이트로 프로모션 확인을 건너뛰고:

     sudo gitlab-ctl geo promote --force
     

2. 보조 사이트의 각 Rails 노드에 SSH하여 다음 명령 중 하나를 실행합니다:

   • 보조 사이트를 주 사이트로 프로모션:

     sudo gitlab-ctl geo promote
     

   • 보조 사이트를 주 사이트로 프로모션 확인을 건너뛰고:

     sudo gitlab-ctl geo promote --force
     

3. 이전에 보조 사이트에 사용한 URL을 사용하여 새로 프로모션된 주 사이트에 연결할 수 있는지 확인합니다.
4. 성공하면 보조 사이트가 이제 주 사이트로 프로모션되었습니다.

Patroni 스탠바이 클러스터를 사용하여 보조 사이트를 홍보하는 방법

1. 보조 사이트의 각 Sidekiq, PostgreSQL, 및 Gitaly 노드에 SSH를 하고 다음 명령어 중 하나를 실행합니다.

   • 보조 사이트를 기본으로 홍보하려면:

     sudo gitlab-ctl geo promote
     

   • 더 이상의 확인 없이 보조 사이트를 기본으로 홍보하려면:

     sudo gitlab-ctl geo promote --force
     

2. 보조 사이트의 각 Rails 노드에 SSH를 하고 다음 명령어 중 하나를 실행합니다.

   • 보조 사이트를 기본으로 홍보하려면:

     sudo gitlab-ctl geo promote
     

   • 더 이상의 확인 없이 보조 사이트를 기본으로 홍보하려면:

     sudo gitlab-ctl geo promote --force
     

3. 이전에 보조 사이트를 위해 사용한 URL을 사용하여 새로 홍보된 기본 사이트에 연결할 수 있는지 확인하세요.
4. 성공적으로 연결되면 보조 사이트는 이제 기본 사이트로 홍보되었습니다.

외부 PostgreSQL 데이터베이스를 사용하여 보조 사이트를 홍보하는 방법

gitlab-ctl geo promote 명령은 외부 PostgreSQL 데이터베이스와 함께 사용할 수 있습니다. 이 경우, 먼저 보조 사이트와 관련된 레플리카 데이터베이스를 수동으로 홍보해야 합니다.

1. 보조 사이트와 관련된 레플리카 데이터베이스를 홍보합니다. 이렇게 하면 데이터베이스가 읽기-쓰기로 설정됩니다. 데이터베이스가 호스팅되는 위치에 따라 지침이 달라집니다:
   • Amazon RDS
   • Azure PostgreSQL
   • Google Cloud SQL

   • 기타 외부 PostgreSQL 데이터베이스의 경우, 예를 들어 /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
     

2. 보조 사이트의 각 Sidekiq, PostgreSQL, 및 Gitaly 노드에 SSH를 하고 다음 명령어 중 하나를 실행합니다.

   • 보조 사이트를 기본으로 홍보하려면:

     sudo gitlab-ctl geo promote
     

   • 더 이상의 확인 없이 보조 사이트를 기본으로 홍보하려면:

     sudo gitlab-ctl geo promote --force
     

3. 보조 사이트의 각 Rails 노드에 SSH를 하고 다음 명령어 중 하나를 실행합니다.

   • 보조 사이트를 기본으로 홍보하려면:

     sudo gitlab-ctl geo promote
     

   • 더 이상의 확인 없이 보조 사이트를 기본으로 홍보하려면:

     sudo gitlab-ctl geo promote --force
     

4. 이전에 보조 사이트를 위해 사용한 URL을 사용하여 새로 홍보된 기본 사이트에 연결할 수 있는지 확인하세요.
5. 성공적으로 연결되면 보조 사이트는 이제 기본 사이트로 홍보되었습니다.

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

기본 도메인의 DNS 레코드를 보조 사이트를 가리키도록 업데이트합니다. 이렇게 하면 기본 도메인과 관련된 모든 참조를 업데이트할 필요가 없어집니다. 예를 들어 Git 리모트 및 API URL을 변경하는 것입니다.

1. 보조 사이트에 SSH로 로그인합니다.

   sudo -i
   

2. 기본 도메인의 DNS 레코드를 업데이트합니다. 기본 도메인의 DNS 레코드를 보조 사이트를 가리키도록 업데이트한 후, 보조 사이트의 /etc/gitlab/gitlab.rb를 수정하여 새 URL을 반영합니다.

   # 기존의 external_url 구성을 변경합니다.
   external_url 'https://<new_external_url>'
   

   참고: external_url을 변경해도, 기존의 보조 URL을 통한 접근이 여전히 유지됩니다. 단, 이는 보조 DNS 레코드가 그대로 유지될 경우입니다.

3. 보조의 SSL 인증서를 업데이트합니다.

   • Let’s Encrypt 통합을 사용하는 경우, 인증서는 자동으로 업데이트됩니다.

   • 수동으로 설정한 경우, 보조의 인증서를 기본에서 보조로 복사합니다. 기본에 액세스 권한이 없는 경우, 새 인증서를 발급하고 기본 및 보조 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
     

4. 변경 사항이 적용되도록 보조 사이트를 다시 구성합니다.

   gitlab-ctl reconfigure
   

5. 새로 홍보된 기본 사이트 URL을 업데이트하기 위해 아래 명령어를 실행합니다.

   gitlab-rake geo:update_primary_node_url
   

   이 명령은 /etc/gitlab/gitlab.rb에 정의된 변경된 external_url 구성을 사용합니다.

6. GitLab 12.0부터 12.7까지는 데이터베이스에서 기본 사이트의 이름을 업데이트해야 할 수 있습니다. 이 버그는 GitLab 12.8에서 수정되었습니다.

   이를 확인하려면, /etc/gitlab/gitlab.rb 파일에서 gitlab_rails["geo_node_name"] 설정을 찾아보세요. 만약 주석 처리되었거나 전혀 찾을 수 없다면, 데이터베이스에서 기본 사이트의 이름을 업데이트해야 합니다. 다음과 같이 찾을 수 있습니다:

   grep "geo_node_name" /etc/gitlab/gitlab.rb
   

   데이터베이스에서 기본 사이트의 이름을 업데이트하려면:

   gitlab-rails runner 'Gitlab::Geo.primary_node.update!(name: GeoNode.current_node_name)'
   

7. 변경된 기본으로 연결할 수 있는지 확인합니다. 기본 도메인의 DNS 레코드를 업데이트한 경우, 변경 사항이 이전의 DNS 레코드 TTL에 따라 아직 전파되지 않을 수 있습니다.

단계 5. (선택 사항) 보조 Geo 사이트를 프로모션된 주 사이트에 추가

위의 프로세스를 사용하여 보조 사이트를 주 사이트로 프로모션하는 것은 새로운 주 사이트에서 Geo를 활성화하지 않습니다.

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

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

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

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

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

gitlab.rb 파일에서 geo_secondary[] 구성 옵션을 활성화했다면 주석 처리하거나 제거하고, 그 변경 사항이 적용되도록 GitLab을 재구성하세요.

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

여러 개의 보조 사이트가 있고 그 중 하나를 프로모션해야 하는 경우, 단일 보조 구성에서 보조 Geo 사이트를 프로모션한 후 두 가지 추가 단계가 필요합니다.

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

1. 새로운 주 사이트에 SSH로 로그인하세요.

   sudo -i
   

2. /etc/gitlab/gitlab.rb 파일을 편집하세요.

   ## Geo Primary 역할을 활성화합니다 (아직 활성화하지 않았다면)
   roles ['geo_primary_role']
   
   ##
   # 주 사이트 및 보조 사이트 IP에서 PostgreSQL 클라이언트 인증을 허용합니다. 이 IP는
   # 예를 들어 ['198.51.100.1/32', '198.51.100.2/32']와 같은 CIDR 형식의 공개 또는 VPC 주소일 수 있습니다.
   ##
   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
   

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

3. 파일을 저장하고 데이터베이스 수신 대기 변경 및 복제 슬롯 변경이 적용되도록 GitLab을 다시 구성하세요.

   gitlab-ctl reconfigure
   

   변경 사항이 적용되도록 PostgreSQL을 다시 시작하세요.

   gitlab-ctl restart postgresql
   

4. 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. 클러스터 외부의 모든 secondary 사이트 노드를 홍보합니다

경고: 만약 secondary 사이트가 일시 중지되었다면, 이 작업은 마지막으로 알려진 상태로의 시점 복구를 수행합니다. secondary가 중지된 동안 primary에서 생성된 데이터는 손실됩니다.

1. Kubernetes 클러스터 외부의 각 노드(예: PostgreSQL 또는 Gitaly)에 대해 Linux 패키지를 사용하여 노드에 SSH를 하고 다음 명령어 중 하나를 실행합니다:

   • Kubernetes 클러스터 외부의 secondary 사이트 노드를 primary로 홍보:

     sudo gitlab-ctl geo promote
     

   • 어떠한 추가 확인도 없이 Kubernetes 클러스터 외부의 secondary 사이트 노드를 primary로 홍보:

     sudo gitlab-ctl geo promote --force
     

2. toolbox pod를 찾습니다:

   kubectl --namespace gitlab get pods -lapp=toolbox
   

3. secondary를 홍보합니다:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_secondary_as_primary
   

   환경 변수를 제공하여 작업의 동작을 수정할 수 있습니다. 사용 가능한 변수는 다음과 같습니다:

   Name	Default value	Description
   ENABLE_SILENT_MODE	false	true로 설정하면 홍보 이전에 Silent Mode을 활성화합니다 (GitLab 16.4 이상)

단계 3. secondary 클러스터를 홍보합니다

1. 기존 클러스터 구성을 업데이트합니다.

   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 클러스터를 primary 클러스터로 홍보하려면 role: secondary를 role: primary로 업데이트합니다.

   클러스터가 primary 사이트로 유지되는 경우 psql 섹션 전체를 제거할 수 있습니다. 이는 추적 데이터베이스를 참조하며 primary 사이트로 작동 중일 때 무시됩니다.

   다음 명령어로 새 구성으로 클러스터를 업데이트합니다:

   helm upgrade --install --version <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
   

2. 이전에 secondary로 사용된 URL로 새로 홍보된 primary에 연결할 수 있는지 확인합니다.

3. 성공입니다! secondary가 이제 primary로 홍보되었습니다.

문제 해결

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