• 데이터 유형
  • Git 저장소
  • 블롭
  • 데이터베이스
• 복제/확인에 대한 제한
  • 기능 플래그 뒤에 있는 복제된 데이터 유형
    • 복제를 활성화 또는 비활성화하기(일부 데이터 유형에 대해)

지원되는 지리 데이터 유형

지리 데이터 유형은 하나 이상의 GitLab 기능에서 필요로 하는 특정 데이터 클래스로, 관련 정보를 저장하기 위해 필요합니다.

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

데이터 유형

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

• Git 저장소
• Blob
• 데이터베이스

각 기능 또는 구성 요소를 복제하는 대응하는 데이터 유형, 복제 및 확인 방법은 아래 목록에서 확인하세요:

• (1): 레디스 복제는 레디스 센티넬을 사용한 HA의 일부로 사용될 수 있습니다. 이는 Geo 사이트간에는 사용되지 않습니다.
• (2): 객체 저장소 복제는 Geo 또는 객체 저장소 제공업체/장치의 네이티브 복제 기능에 의해 수행될 수 있습니다.
• (3): 객체 저장소 검증은 기능 플래그 geo_object_storage_verification을 통해 제공되며, 16.4에서 도입되었으며 기본적으로 활성화됩니다. 이는 파일 크기의 체크섬을 사용하여 파일을 확인합니다.

Git 저장소

GitLab 인스턴스는 하나 이상의 저장소 샤드를 가질 수 있습니다. 각 샤드에는 로컬로 저장된 Git 저장소에 대한 액세스 및 작업을 허용하는 Gitaly 인스턴스가 있습니다. 이는 다음과 같은 머신에서 실행할 수 있습니다.

• 단일 디스크를 가진 경우
• 여러 디스크가 하나의 마운트 지점으로 마운트된 경우(예: RAID 배열과 같이)
• LVM을 사용하는 경우

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

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

Gitaly gRPC API는 동기화를 위해 세 가지 방법으로 통신합니다.

• 일반적인 Git clone/fetch를 사용하여 Geo 사이트 간에 동기화(특별한 인증으로)
• 저장소 스냅숏을 사용하여(첫 번째 방법이 실패하거나 저장소가 손상된 경우)
• Admin Area에서 수동으로 트리거(위 두 가지 방법을 결합)

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

• 프로젝트 저장소: 소스 코드가 저장되는 곳
• 위키 저장소: 위키 콘텐츠가 저장되는 곳
• 디자인 저장소: 디자인 자산이 색인된 곳(실제 자산은 LFS에 저장됩니다)

모든 저장소는 동일한 샤드에 있으며 위키와 디자인 저장소의 경우 -wiki 및 -design 접미어로 동일한 기본 이름을 공유합니다.

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

블롭

GitLab은 파일 및 블롭(예: 이슈 첨부 파일 또는 LFS 객체)을 다음 위치 중 하나에 저장합니다.

• 특정 위치에 있는 파일 시스템
• 객체 스토리지 솔루션. 객체 스토리지 솔루션으로는 다음과 같은 것들이 있습니다.
  • Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반 솔루션
  • MinIO와 같이 사용자가 호스팅하는 솔루션
  • 객체 스토리지 호환 API를 노출하는 스토리지 애플라이언스

객체 스토리지 대신 파일 시스템 저장소를 사용할 때에는 더 많은 노드를 사용할 때 GitLab을 실행하기 위해 네트워크 마운트된 파일 시스템을 사용합니다.

복제 및 확인과 관련하여:

• 내부 API 요청을 사용하여 파일과 블롭을 전송합니다.
• 객체 스토리지를 사용할 경우 다음과 같이 할 수 있습니다.
  • 클라우드 제공업체 복제 기능을 사용합니다.
  • GitLab이 대신 복제할 수 있습니다.

데이터베이스

GitLab은 다양한 사용 사례를 위해 여러 데이터베이스에 저장된 데이터에 의존합니다. 웹 인터페이스에서 사용자 생성 콘텐츠 및 권한, 자격 증명, 코멘트 등과 같은 PostgreSQL은 단일 진실의 점입니다.

또한, PostgreSQL은 HTML로 렌더링된 마크다운과 캐시된 병합 요청 차이와 같은 캐시된 데이터를 보유할 수 있습니다. 이를 객체 스토리지로 오프로드할 수도 있습니다.

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

Redis는 캐시 저장소로 사용되며 백그라운드 작업 시스템의 지속적인 데이터를 보유하기 위해 사용됩니다. 두 사용 사례 모두 동일한 Geo 사이트에 독점적인 데이터를 보유하고 있기 때문에 보조 사이트 간에는 복제하지 않습니다.

Elasticsearch는 고급 검색을 위한 선택적 데이터베이스입니다. 소스 코드 수준 및 이슈, 병합 요청, 토론과 같은 사용자 생성 콘텐츠의 검색을 개선할 수 있습니다. Elasticsearch는 Geo에서 지원되지 않습니다.

복제/확인에 대한 제한

다음 표는 보조 사이트에서 GitLab 기능과 해당 복제 및 확인 상태를 나열합니다.

이러한 누락된 항목을 구현하기 위한 진행 상황을 다음 에픽/이슈에서 확인하실 수 있습니다.

• Geo: 자체 서비스 Geo 복제 프레임워크 개선
• Geo: 기존 블롭을 프레임워크로 이동

기능 플래그 뒤에 있는 복제된 데이터 유형

일부 데이터 유형의 복제는 그에 해당하는 기능 플래그 뒤에 있습니다.

• 그들은 기본적으로 활성화된 기능 플래그 뒤에 배포되었습니다.
• GitLab.com에서 활성화되었습니다.
• 프로젝트별로 활성화 또는 비활성화할 수 없습니다.
• 운영 환경에서 권장됩니다.
• GitLab 자체 관리 인스턴스의 경우 GitLab 관리자는 그들을 비활성화할 수 있습니다.

복제를 활성화 또는 비활성화하기(일부 데이터 유형에 대해)

일부 데이터 유형의 복제는 기본적으로 활성화된 기능 플래그 뒤에 배포되었습니다. GitLab 레일스 콘솔에 액세스할 수 있는 GitLab 관리자는 인스턴스에 대해 이를 비활성화할 수 있습니다. 각 데이터 유형의 기능 플래그 이름을 표의 주석 열에서 찾을 수 있습니다.

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

Feature.disable(:geo_package_file_replication)

패키지 파일 복제를 활성화하려면:

Feature.enable(:geo_package_file_replication)

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