2019-09-30 21:07:59 +05:30
|
|
|
# Geo with Object storage **(PREMIUM ONLY)**
|
2019-07-31 22:56:46 +05:30
|
|
|
|
2019-12-21 20:55:43 +05:30
|
|
|
Geo can be used in combination with Object Storage (AWS S3, or other compatible object storage).
|
2019-07-31 22:56:46 +05:30
|
|
|
|
2019-12-21 20:55:43 +05:30
|
|
|
Currently, **secondary** nodes can use either:
|
2019-07-31 22:56:46 +05:30
|
|
|
|
2019-12-21 20:55:43 +05:30
|
|
|
- The same storage bucket as the **primary** node.
|
|
|
|
|
- A replicated storage bucket.
|
2019-07-31 22:56:46 +05:30
|
|
|
|
2019-12-21 20:55:43 +05:30
|
|
|
To have:
|
|
|
|
|
|
|
|
|
|
- GitLab manage replication, follow [Enabling GitLab replication](#enabling-gitlab-managed-object-storage-replication).
|
|
|
|
|
- Third-party services manage replication, follow [Third-party replication services](#third-party-replication-services).
|
|
|
|
|
|
|
|
|
|
## Enabling GitLab managed object storage replication
|
|
|
|
|
|
|
|
|
|
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/10586) in GitLab 12.4.
|
|
|
|
|
|
|
|
|
|
CAUTION: **Caution:**
|
|
|
|
|
This is a [**beta** feature](https://about.gitlab.com/handbook/product/#beta) and is not ready yet for production use at any scale.
|
|
|
|
|
|
|
|
|
|
**Secondary** nodes can replicate files stored on the **primary** node regardless of
|
|
|
|
|
whether they are stored on the local filesystem or in object storage.
|
|
|
|
|
|
|
|
|
|
To enable GitLab replication, you must:
|
|
|
|
|
|
|
|
|
|
1. Go to **Admin Area > Geo**.
|
|
|
|
|
1. Press **Edit** on the **secondary** node.
|
|
|
|
|
1. Enable the **Allow this secondary node to replicate content on Object Storage**
|
|
|
|
|
checkbox.
|
2019-07-31 22:56:46 +05:30
|
|
|
|
|
|
|
|
For LFS, follow the documentation to
|
2019-12-26 22:10:19 +05:30
|
|
|
[set up LFS object storage](../../lfs/lfs_administration.md#storing-lfs-objects-in-remote-object-storage).
|
2019-07-31 22:56:46 +05:30
|
|
|
|
|
|
|
|
For CI job artifacts, there is similar documentation to configure
|
|
|
|
|
[jobs artifact object storage](../../job_artifacts.md#using-object-storage)
|
|
|
|
|
|
|
|
|
|
For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage-core-only)
|
|
|
|
|
|
2019-12-21 20:55:43 +05:30
|
|
|
If you want to migrate the **primary** node's files to object storage, you can
|
|
|
|
|
configure the **secondary** in a few ways:
|
|
|
|
|
|
|
|
|
|
- Use the exact same object storage.
|
|
|
|
|
- Use a separate object store but leverage your object storage solution's built-in
|
|
|
|
|
replication.
|
|
|
|
|
- Use a separate object store and enable the **Allow this secondary node to replicate
|
|
|
|
|
content on Object Storage** setting.
|
|
|
|
|
|
|
|
|
|
GitLab does not currently support the case where both:
|
|
|
|
|
|
|
|
|
|
- The **primary** node uses local storage.
|
|
|
|
|
- A **secondary** node uses object storage.
|
2019-07-31 22:56:46 +05:30
|
|
|
|
2019-12-21 20:55:43 +05:30
|
|
|
## Third-party replication services
|
2019-07-31 22:56:46 +05:30
|
|
|
|
|
|
|
|
When using Amazon S3, you can use
|
|
|
|
|
[CRR](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to
|
|
|
|
|
have automatic replication between the bucket used by the **primary** node and
|
|
|
|
|
the bucket used by **secondary** nodes.
|
|
|
|
|
|
|
|
|
|
If you are using Google Cloud Storage, consider using
|
|
|
|
|
[Multi-Regional Storage](https://cloud.google.com/storage/docs/storage-classes#multi-regional).
|
2019-09-30 21:07:59 +05:30
|
|
|
Or you can use the [Storage Transfer Service](https://cloud.google.com/storage-transfer/docs/),
|
2019-07-31 22:56:46 +05:30
|
|
|
although this only supports daily synchronization.
|
|
|
|
|
|
|
|
|
|
For manual synchronization, or scheduled by `cron`, please have a look at:
|
|
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
- [`s3cmd sync`](https://s3tools.org/s3cmd-sync)
|
2019-07-31 22:56:46 +05:30
|
|
|
- [`gsutil rsync`](https://cloud.google.com/storage/docs/gsutil/commands/rsync)
|
