• 데이터 유형
  • Git 저장소
  • Blob
  • 데이터베이스
• 복제된 데이터 유형
  • 기능 플래그 뒤의 복제된 데이터 유형
    • 복제를 활성화하거나 비활성화합니다(일부 데이터 유형에 대해)

지원되는 Geo 데이터 유형

Geo 데이터 유형은 하나 이상의 GitLab 기능에서 필요한 특정 데이터 클래스이며, 관련 정보를 저장하는 데 사용됩니다.

이러한 기능에서 생성된 데이터를 Geo로 복제하기 위해 여러 전략을 사용하여 액세스, 전송 및 검증합니다.

데이터 유형

세 가지 서로 다른 데이터 유형을 구분합니다:

• Git 리포지토리
• Blob
• 데이터베이스

복제하는 각 기능 또는 구성 요소, 해당 데이터 유형, 복제 및 검증 방법의 목록은 아래를 참조하세요:

각주:

1. Redis 복제는 Redis 감시를 사용하여 HA의 일부로 사용될 수 있습니다. Geo 사이트 간에는 사용되지 않습니다.

2. 오브젝트 스토리지 복제는 Geo 또는 오브젝트 스토리지 제공업체/장치의 기본 복제 기능에 의해 수행될 수 있습니다.

3. 오브젝트 스토리지 검증은 기능 플래그 geo_object_storage_verification에 의해 제어되며, 16.4에 도입됨이며 기본값으로 활성화됩니다. 파일 크기의 체크섬을 사용하여 파일을 검증합니다.

Git 저장소

GitLab 인스턴스는 하나 이상의 저장소 샤드를 가질 수 있습니다. 각 샤드는 로컬에 저장된 Git 저장소에 대한 접근 및 작업을 허용하는 Gitaly 인스턴스를 가지고 있습니다. 이는 다음과 같이 기계에서 실행될 수 있습니다:

• 단일 디스크.
• RAID 배열과 같이 단일 마운트 포인트로 마운트된 여러 디스크.
• LVM을 사용하여.

GitLab은 특별한 파일 시스템을 요구하지 않으며, 마운트된 스토리지 장치와 함께 작동할 수 있습니다. 그러나 원격 파일 시스템을 사용할 때 성능 제한 및 일관성 문제일 수 있습니다.

Geo는 Geo 보조 사이트에서 포크된 저장소의 중복 제거를 위해 Gitaly에서 가비지 수집을 트리거합니다.

Gitaly gRPC API는 통신을 담당하며, 세 가지 동기화 방법이 있습니다:

• 한 Geo 사이트에서 다른 Geo 사이트로 일반 Git clone/fetch 사용 (특별 인증 사용).
• 저장소 스냅샷 사용 (첫 번째 방법이 실패하거나 저장소가 손상되었을 때).
• Admin 영역에서 수동 트리거 (위에서 언급한 두 가지 조합).

각 프로젝트는 최대 3개의 서로 다른 저장소를 가질 수 있습니다:

• 소스 코드가 저장되는 프로젝트 저장소.
• 위키 내용이 저장되는 위키 저장소.
• 디자인 아티팩트가 인덱싱되는 디자인 저장소 (자산은 실제로 LFS에 있음).

모두 동일한 샤드에 위치하며 위키와 디자인 저장소의 경우 -wiki 및 -design 접미사로 같은 기본 이름을 공유합니다.

그 외에 스니펫 저장소가 있습니다. 이들은 프로젝트 또는 특정 사용자에 연결될 수 있습니다. 두 유형 모두 보조 사이트와 동기화됩니다.

Blob

GitLab은Issue 첨부파일이나 LFS 객체와 같은 파일과 blob을 다음 중 하나에 저장합니다:

• 특정 위치의 파일 시스템.
• Object Storage 솔루션. Object Storage 솔루션은 다음과 같을 수 있습니다:
  • Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반.
  • MinIO와 같이 호스팅되는 것.
  • Object Storage 호환 API를 노출하는 스토리지 장치.

Object Storage 대신 파일 시스템 저장소를 사용하는 경우 여러 노드를 사용하는 경우 GitLab을 실행하기 위해 네트워크 마운트 파일 시스템을 사용하십시오.

복제 및 검증에 관하여:

• 내부 API 요청을 사용하여 파일과 blob을 전송합니다.
• Object Storage를 사용할 경우 다음 중 하나를 선택할 수 있습니다:
  • 클라우드 제공자의 복제 기능을 사용.
  • GitLab이 귀하를 위해 복제하도록 할 수 있습니다.

데이터베이스

GitLab은 다양한 사용 사례를 위해 여러 데이터베이스에 저장된 데이터에 의존합니다. PostgreSQL은 사용자 생성 콘텐츠에 대한 단일 진실 지점입니다. 웹 인터페이스에서 문제 콘텐츠, 댓글 및 권한 및 자격 증명을 포함합니다.

PostgreSQL은 또한 HTML 렌더링된 Markdown 및 캐시된 병합 요청 차이에 대한 일부 수준의 캐시된 데이터를 보유할 수 있습니다. 이는 객체 저장소로 오프로드하도록 구성할 수도 있습니다.

우리는 PostgreSQL의 자체 복제 기능을 사용하여 주요 사이트에서 보조 사이트로 데이터를 복제합니다.

우리는 Redis를 캐시 저장소와 백그라운드 작업 시스템에 대한 영구 데이터를 보유하는 데 모두 사용합니다. 두 사용 사례 모두 동일한 Geo 사이트에 독점적인 데이터를 가지고 있기 때문에 사이트 간에 복제하지 않습니다.

Elasticsearch는 고급 검색을 위한 선택적 데이터베이스입니다. 이는 소스 코드 수준 및 문제, 병합 요청 및 논의에서 사용자 생성 콘텐츠 모두에서 검색을 개선할 수 있습니다.

Elasticsearch는 Geo에서 지원되지 않습니다.

복제된 데이터 유형

기능 플래그 뒤의 복제된 데이터 유형

일부 데이터 유형에 대한 복제는 해당 기능 플래그 뒤에 있습니다:

• 기능 플래그 뒤에 배포되고 기본적으로 활성화됩니다.
• GitLab.com에서 활성화됩니다.
• 프로젝트별로 활성화하거나 비활성화할 수 없습니다.
• 프로덕션 사용을 권장합니다.
• GitLab 자체 관리 인스턴스의 경우 GitLab 관리자는 비활성화할 수 있습니다.

복제를 활성화하거나 비활성화합니다(일부 데이터 유형에 대해)

일부 데이터 유형의 복제는 기본적으로 활성화된 기능 플래그 뒤에서 릴리스됩니다.
GitLab Rails 콘솔에 접근할 수 있는 GitLab 관리자는 인스턴스에 대해 이를 비활성화하도록 선택할 수 있습니다. 각 데이터 유형의 기능 플래그 이름은 아래 표의 노트 열에서 확인할 수 있습니다.

비활성화하려면, 예를 들어 패키지 파일 복제의 경우:

Feature.disable(:geo_package_file_replication)

활성화하려면, 예를 들어 패키지 파일 복제의 경우:

Feature.enable(:geo_package_file_replication)

경고:
이 목록에 없는 기능이나 Replicated 열에 No가 있는 기능은 secondary 사이트로 복제되지 않습니다.
해당 기능의 데이터를 수동으로 복제하지 않고 장애 조치를 수행하면 데이터가 손실됩니다.
Secondary 사이트에서 이러한 기능을 사용하거나 장애 조치를 성공적으로 수행하려면, 다른 방법을 사용하여 데이터를 복제해야 합니다.

각주:

1. 15.5에서 self-service framework로 마이그레이션됨. 상세 내용은 GitLab 이슈 #337436를 참조하세요.
2. 15.11에서 self-service framework로 마이그레이션됨. 기본적으로 활성화된 기능 플래그 geo_project_wiki_repository_replication이 뒤에 있으며, 상세 내용은 GitLab 이슈 #367925를 참조하세요.
3. 객체 스토리지에 저장된 파일의 검증은 GitLab 16.4에서 기능 플래그 geo_object_storage_verification와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.