InfoGrab Docs

GitLab Dedicated 재해 복구

요약

GitLab Dedicated는 기본 지역이 사용 불가능해질 경우 인스턴스를 복원하기 위한 자동 재해 복구를 제공합니다. 보조 지역이 구성되지 않은 경우, 복구는 백업 복원으로 제한됩니다. GitLab Dedicated는 다음과 같은 복구 목표로 재해 복구를 제공합니다:

GitLab Dedicated는 기본 지역이 사용 불가능해질 경우 인스턴스를 복원하기 위한 자동 재해 복구를 제공합니다. 전체 복구 목표를 충족하려면:

보조 지역이 구성되지 않은 경우, 복구는 백업 복원으로 제한됩니다.

복구 목표#

GitLab Dedicated는 다음과 같은 복구 목표로 재해 복구를 제공합니다:

  • 복구 시간 목표(RTO): 서비스가 8시간 이내에 보조 지역으로 복원됩니다.
  • 복구 시점 목표(RPO): 데이터 손실은 재해 발생 시점과 마지막 백업 시점에 따라 최근 4시간의 변경 사항으로 제한됩니다.

Geo 복제#

인스턴스를 생성할 때 환경의 기본 지역과 보조 지역을 선택합니다. Geo는 다음을 포함하여 두 지역 간에 데이터를 지속적으로 복제합니다:

  • 데이터베이스 콘텐츠
  • 저장소 스토리지
  • 오브젝트 스토리지

자동 백업#

GitLab은 스냅샷을 생성하여 4시간마다(하루 6회) 모든 GitLab Dedicated 데이터 저장소(데이터베이스 및 Git 저장소 포함)의 자동 백업을 수행합니다.

백업은 테스트되고, 30일간 보존되며, 선택한 보조 지역에 저장됩니다. 또한 추가 보호를 위해 AWS에 의해 지리적으로 복제됩니다.

데이터베이스 백업:

  • 특정 시점 복구를 위해 기본 지역에서 연속 로그 기반 백업을 사용합니다.
  • 거의 실시간 복사본을 제공하기 위해 보조 지역으로 스트림 복제를 수행합니다.

오브젝트 스토리지 백업은 백업 보호를 제공하기 위해 지리적 복제 및 버전 관리를 사용합니다.

4시간 백업 빈도는 복구 시점 목표(RPO)를 지원하여 최대 4시간의 데이터 손실을 보장합니다.

재해 적용 범위#

재해 복구는 다음 시나리오에 대해 보장된 복구 목표를 제공합니다:

  • 부분적인 지역 장애(예: 가용성 영역 장애)
  • 기본 지역의 완전한 중단

다음 시나리오는 보장된 복구 목표 없이 최선의 노력을 기준으로 처리됩니다:

  • 기본 지역과 보조 지역 모두 손실
  • 글로벌 인터넷 장애
  • 데이터 손상 문제

서비스 제한 사항#

재해 복구에는 다음과 같은 서비스 제한 사항이 있습니다:

  • 고급 검색 인덱스는 지속적으로 복제되지 않습니다. 페일오버 후 보조 지역이 승격될 때 이 인덱스가 재구축됩니다. 재구축 중에는 기본 검색이 사용 가능합니다.
  • ClickHouse Cloud는 기본 지역에서만 프로비저닝됩니다. 기본 지역이 완전히 다운된 경우 이 서비스가 필요한 기능은 사용할 수 없을 수 있습니다.
  • 프로덕션 미리보기 환경에는 보조 인스턴스가 없습니다.
  • 호스팅된 러너는 기본 지역에서만 지원되며 보조 인스턴스에서 재구축할 수 없습니다.
  • 일부 지역은 AWS 서비스 제약으로 인해 제한된 기능 가용성을 갖습니다. 자세한 내용은 지원되는 지역을 참조하십시오. 이러한 기능 제한은 재해 복구 기능이나 RTO 및 RPO 목표에 영향을 미치지 않습니다.

GitLab은 다음을 제공하지 않습니다:

  • 페일오버 이벤트의 프로그래밍 방식 모니터링
  • 고객이 시작하는 재해 복구 테스트

페일오버 프로세스#

완전한 지역 장애 또는 신속하게 복구할 수 없는 중요 구성 요소 장애로 인해 인스턴스가 사용 불가능해지면 GitLab Dedicated 팀은:

  1. 모니터링 시스템으로부터 알림을 받습니다.
  2. 페일오버가 필요한지 조사합니다.
  3. 페일오버가 필요한 경우:
    1. 페일오버가 진행 중임을 알립니다.
    2. 보조 지역을 기본으로 승격합니다.
    3. 새로 승격된 지역을 가리키도록 <customer>.gitlab-dedicated.com의 DNS 레코드를 업데이트합니다.
    4. 페일오버가 완료되면 알립니다.

PrivateLink를 사용하는 경우 보조 지역의 PrivateLink 엔드포인트를 대상으로 내부 네트워킹 구성을 업데이트해야 합니다. 다운타임을 최소화하려면 재해가 발생하기 전에 보조 지역에 동등한 PrivateLink 엔드포인트를 구성하십시오.

페일오버 프로세스는 일반적으로 90분 이내에 완료됩니다. 프로세스 전반에 걸쳐 GitLab은 다음 중 하나 이상을 통해 소통합니다:

  • Switchboard의 운영 연락처 정보
  • Slack
  • 지원 티켓

GitLab은 복구 프로세스 전반에 걸쳐 팀과 조율하기 위해 임시 Slack 채널과 Zoom 브리지를 개설할 수 있습니다.

관련 주제#

GitLab Dedicated 재해 복구

Tier: Ultimate
Offering: GitLab Dedicated
원문 보기
요약

GitLab Dedicated는 기본 지역이 사용 불가능해질 경우 인스턴스를 복원하기 위한 자동 재해 복구를 제공합니다. 보조 지역이 구성되지 않은 경우, 복구는 백업 복원으로 제한됩니다. GitLab Dedicated는 다음과 같은 복구 목표로 재해 복구를 제공합니다:

GitLab Dedicated는 기본 지역이 사용 불가능해질 경우 인스턴스를 복원하기 위한 자동 재해 복구를 제공합니다. 전체 복구 목표를 충족하려면:

보조 지역이 구성되지 않은 경우, 복구는 백업 복원으로 제한됩니다.

복구 목표#

GitLab Dedicated는 다음과 같은 복구 목표로 재해 복구를 제공합니다:

  • 복구 시간 목표(RTO): 서비스가 8시간 이내에 보조 지역으로 복원됩니다.
  • 복구 시점 목표(RPO): 데이터 손실은 재해 발생 시점과 마지막 백업 시점에 따라 최근 4시간의 변경 사항으로 제한됩니다.

Geo 복제#

인스턴스를 생성할 때 환경의 기본 지역과 보조 지역을 선택합니다. Geo는 다음을 포함하여 두 지역 간에 데이터를 지속적으로 복제합니다:

  • 데이터베이스 콘텐츠
  • 저장소 스토리지
  • 오브젝트 스토리지

자동 백업#

GitLab은 스냅샷을 생성하여 4시간마다(하루 6회) 모든 GitLab Dedicated 데이터 저장소(데이터베이스 및 Git 저장소 포함)의 자동 백업을 수행합니다.

백업은 테스트되고, 30일간 보존되며, 선택한 보조 지역에 저장됩니다. 또한 추가 보호를 위해 AWS에 의해 지리적으로 복제됩니다.

데이터베이스 백업:

  • 특정 시점 복구를 위해 기본 지역에서 연속 로그 기반 백업을 사용합니다.
  • 거의 실시간 복사본을 제공하기 위해 보조 지역으로 스트림 복제를 수행합니다.

오브젝트 스토리지 백업은 백업 보호를 제공하기 위해 지리적 복제 및 버전 관리를 사용합니다.

4시간 백업 빈도는 복구 시점 목표(RPO)를 지원하여 최대 4시간의 데이터 손실을 보장합니다.

재해 적용 범위#

재해 복구는 다음 시나리오에 대해 보장된 복구 목표를 제공합니다:

  • 부분적인 지역 장애(예: 가용성 영역 장애)
  • 기본 지역의 완전한 중단

다음 시나리오는 보장된 복구 목표 없이 최선의 노력을 기준으로 처리됩니다:

  • 기본 지역과 보조 지역 모두 손실
  • 글로벌 인터넷 장애
  • 데이터 손상 문제

서비스 제한 사항#

재해 복구에는 다음과 같은 서비스 제한 사항이 있습니다:

  • 고급 검색 인덱스는 지속적으로 복제되지 않습니다. 페일오버 후 보조 지역이 승격될 때 이 인덱스가 재구축됩니다. 재구축 중에는 기본 검색이 사용 가능합니다.
  • ClickHouse Cloud는 기본 지역에서만 프로비저닝됩니다. 기본 지역이 완전히 다운된 경우 이 서비스가 필요한 기능은 사용할 수 없을 수 있습니다.
  • 프로덕션 미리보기 환경에는 보조 인스턴스가 없습니다.
  • 호스팅된 러너는 기본 지역에서만 지원되며 보조 인스턴스에서 재구축할 수 없습니다.
  • 일부 지역은 AWS 서비스 제약으로 인해 제한된 기능 가용성을 갖습니다. 자세한 내용은 지원되는 지역을 참조하십시오. 이러한 기능 제한은 재해 복구 기능이나 RTO 및 RPO 목표에 영향을 미치지 않습니다.

GitLab은 다음을 제공하지 않습니다:

  • 페일오버 이벤트의 프로그래밍 방식 모니터링
  • 고객이 시작하는 재해 복구 테스트

페일오버 프로세스#

완전한 지역 장애 또는 신속하게 복구할 수 없는 중요 구성 요소 장애로 인해 인스턴스가 사용 불가능해지면 GitLab Dedicated 팀은:

  1. 모니터링 시스템으로부터 알림을 받습니다.
  2. 페일오버가 필요한지 조사합니다.
  3. 페일오버가 필요한 경우:
    1. 페일오버가 진행 중임을 알립니다.
    2. 보조 지역을 기본으로 승격합니다.
    3. 새로 승격된 지역을 가리키도록 <customer>.gitlab-dedicated.com의 DNS 레코드를 업데이트합니다.
    4. 페일오버가 완료되면 알립니다.

PrivateLink를 사용하는 경우 보조 지역의 PrivateLink 엔드포인트를 대상으로 내부 네트워킹 구성을 업데이트해야 합니다. 다운타임을 최소화하려면 재해가 발생하기 전에 보조 지역에 동등한 PrivateLink 엔드포인트를 구성하십시오.

페일오버 프로세스는 일반적으로 90분 이내에 완료됩니다. 프로세스 전반에 걸쳐 GitLab은 다음 중 하나 이상을 통해 소통합니다:

  • Switchboard의 운영 연락처 정보
  • Slack
  • 지원 티켓

GitLab은 복구 프로세스 전반에 걸쳐 팀과 조율하기 위해 임시 Slack 채널과 Zoom 브리지를 개설할 수 있습니다.

관련 주제#