객체 스토리지와 Geo

Tier: Premium, Ultimate Offering: Self-managed

객체 스토리지에 저장된 파일의 검증은 도입되었습니다 GitLab 16.4에서 geo_object_storage_verification이라는 플래그와 함께 기본적으로 활성화됩니다.

Geo는 객체 스토리지(AWS S3 또는 기타 호환 가능한 객체 스토리지)와 함께 사용할 수 있습니다.

Secondary 사이트는 다음 중 하나를 사용할 수 있습니다:

  • Primary 사이트와 동일한 스토리지 버킷.
  • 복제된 스토리지 버킷.
  • Primary가 로컬 스토리지를 사용하는 경우 로컬 스토리지.

파일에 대한 스토리지 방법(로컬 또는 객체 스토리지)은 데이터베이스에 기록되며, 데이터베이스는 Primary Geo 사이트에서 Secondary Geo 사이트로 복제됩니다.

업로드된 객체에 접근할 때, 우리는 데이터베이스에서 그 스토리지 방법(로컬 또는 객체 스토리지)을 가져오므로, Secondary Geo 사이트는 Primary Geo 사이트의 스토리지 방법과 일치해야 합니다.

따라서 Primary Geo 사이트가 객체 스토리를 사용하는 경우, Secondary Geo 사이트도 객체 스토리를 사용해야 합니다.

다음을 위해:

GitLab 관리 복제와 제3자 복제의 비교에 대해서는 객체 스토리지 복제 테스트를 참조하세요.

GitLab과 함께 객체 스토리지를 사용하는 방법에 대해 더 읽어보세요.

GitLab 관리 객체 스토리지 복제 활성화

Secondary 사이트는 로컬 파일 시스템에 저장되든 객체 스토리지에 저장되든 관계없이 Primary 사이트에 저장된 파일을 복제할 수 있습니다.

GitLab 복제를 활성화하려면:

  1. 왼쪽 사이드바에서 하단에 있는 Admin을 선택합니다.
  2. Geo > Nodes를 선택합니다.
  3. Secondary 사이트에서 Edit을 선택합니다.
  4. Synchronization Settings 섹션에서 Allow this secondary node to replicate content on Object Storage
    체크박스를 찾아 활성화합니다.

LFS의 경우, LFS 객체 스토리지 설정 문서를 따르세요.

CI 작업 아티팩트의 경우, 작업 아티팩트 객체 스토리지 구성에 대한 유사한 문서가 있습니다.

사용자 업로드의 경우, 업로드 객체 스토리지 구성에 대한 유사한 문서가 있습니다.

Primary 사이트의 파일을 객체 스토리지로 마이그레이션하려는 경우 Secondary를 몇 가지 방법으로 구성할 수 있습니다:

  • 정확히 동일한 객체 스토리지 사용.
  • 별도의 객체 저장소를 사용하지만 객체 스토리지 솔루션의 내장 복제를 활용.
  • 별도의 객체 저장소를 사용하고 Allow this secondary node to replicate content on Object Storage 설정을 활성화.

GitLab은 다음 두 가지 경우를 지원하지 않습니다:

  • Primary 사이트가 로컬 스토리지를 사용하는 경우.
  • Secondary 사이트가 객체 스토리지를 사용하는 경우.

제3자 복제 서비스

Amazon S3를 사용하는 경우, Cross-Region Replication (CRR)을 사용하여 Primary 사이트에서 사용되는 버킷과 Secondary 사이트에서 사용되는 버킷 간에 자동 복제를 수행할 수 있습니다.

Google Cloud Storage를 사용하는 경우, Multi-Regional Storage 사용을 고려하세요. 또는 Storage Transfer Service를 사용할 수 있지만, 이는 하루에 한 번만 동기화를 지원합니다.

수동 동기화 또는 cron에 의해 예약된 스케줄링은 다음을 참조하세요: