The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Section | Group | Maturity | Last updated |
|---|---|---|---|
| Enablement | Geo | Complete | 2023-03-28 |
Thanks for visiting this category strategy page for GitLab Geo Replication. This page belongs to the Geo group.
Geo-replication improves the GitLab experience for geographically distributed teams.
Pulling a large Git repository can take a long time for locations geographically remote from the main GitLab instance.
Geo-replication provides an easily configurable, replica Geo site, which can be deployed in additional regions and seamlessly accelerates the GitLab experience for nearby users. This is achieved by replicating the entire GitLab data set to the replica site in a coordinated, verifiable and coherent manner. User requests are directed to the Geo site that is closest in proximity to the user using location aware URL. Intelligent proxying techniques transparently guarantee users have access to the most recent data.
Geo replicates 100% of core GitLab data types and verifies 91% of replicated data.
Geo-replication is also the foundational technology underpinning GitLab's Disaster Recovery solution
Please reach out to Sampath Ranasinghe, Product Manager for the Geo group (Email) if you'd like to provide feedback or ask any questions related to this product category.
This strategy is a work in progress, and everyone can contribute. Please comment and contribute to the linked issues and epics on this page. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
As companies increasingly shift towards remote or hybrid work environments, GitLab becomes a central place for collaboration and the DevOps Platform for many customers. GitLab should offer the same great experience to users, regardless of their location.
Geo-replication will provide horizontal scaling and improved user experience for geographically distributed teams. We envision customers being able to easily spin up new Geo sites in new locations to improve the GitLab experience for their remote users. These sites can be tailored to the requirements of the team. End users interact with GitLab via a single URL and can accomplish all of their tasks without having to worry about the underpinning Geo architecture.
Geo sites will accelerate both users and CI runners, allowing loads to be distributed across the Geo sites rather than focused on a single primary site.
Systems administrators will be able to see the utilization of their secondary sites and understand their return on investment for these sites by seeing the number of read requests served, the number of CI jobs run, and the volume of data served by a secondary site. It will be possible to see the improvement in the user experience delivered by these sites such as speed of access to data, load on the primary sites, and number of unique individual users served.
As GitLab evolves, new features are developed and new data types will be created. Geo self-service framework is now mature, and all data types will be managed through this framework. The self-service framework makes it easy for these new data types to be added and empowers developers outside the Geo team to add new data types.
For more information on how we use personas and roles at GitLab, please click here.
To save bandwidth and resources, a systems administrator may want to selectively enable and disable Geo-replication for certain types of data. Currently, this is not possible unless a data type is released behind a feature flag, and this is not the case for all data types. We want to provide administrators with an easy way to enable or disable replication by data type in the Geo Administrator UI.
Configuring and managing a multi-node Geo site requires logging in to multiple nodes to perform specific steps in the correct order.
It would make administrators' jobs a lot easier if operations could be orchestrated from a single point of entry into the site and the appropriate operations performed on the sites. This will lower the technical barrier for adoption of Geo-replication.
GitLab Environment Toolkit(GET) is a good place to start and already has a lot of functionality. This is likely where we will start. It also has the ability to manage multiple sites.
It is currently possible for systems administrators to get a basic overview of the Geo status using the Geo Web UI. However, administrators would like easier access to more in-depth Geo metrics such as the time it takes to mirror a commit. We want to define and implement key metrics that allow administrators to better monitor their Geo installations and publish the metrics to a pre-configured Grafana dashboard.
For Geo-replication only a subset of data may need to be replicated but Geo sites require spinning up the entire GitLab stack, less may be sufficient. Additionally, systems administrators can select a subset via selective sync, but they may be wrong.
We are investigating an advanced caching mode with the following properties:
Geo should verify all replicated data types. We are currently verifying 91% of all replicated data types. To achieve 100% verification we plan to add support for Group Wikis and Design Repositories.
Geo now supports native object storage replication and we plan to add object storage verification.
Geo performs complex operations by scheduling tasks in the background to replicate data to the secondary sites. Geo will improve the observability of these operations for the systems administrators such that they can monitor tasks that are currently running, tasks scheduled to run in the future and tasks that have failed. For tasks that have failed, Geo will surface information in the UI that will assist in troubleshooting the root cause of the failure. Improved observability will also enhance the experience for systems administrators who are setting up their secondary site for the first time, providing immediate feedback on whether the setup was successful and replication processes are successfully underway. Failed replication can hinder the availability and reliability of a secondary site. Further, it can negatively impact the chances of successful recovery in disaster recovery scenarios resulting in the loss of data.
Today Geo accelerates access to several data types including projects, wikis, and LFS objects by serving read requests from the secondary site closest to the user accessing the data. Geo replicates many other data types. Users can benefit from accelerating more data types with two key benefits:
We will initially focus on the high-impact data types that will deliver the most value to our customers by identifying data types that are large in size and most frequently accessed such as container registries and CI job and pipeline artifacts. As part of this effort, Geo will collect statistics on data types that are proxied to the primary from the secondary sites. This will allow us to make more informed decisions as to which data types to accelerate in the future. This will open up more use cases for Geo-replication and help drive adoption.
Today Geo accelerates users by serving read requests from the secondary site, in future Geo should also accelerate CI jobs by enabling CI runners to use specific Geo secondary sites. This will allow the CI runners to fetch data directly from the closest secondary site reducing the load on the primary site. Writes will continue to be proxied back to the primary to maintain consistency.
Setting up Geo is highly manual and cumbersome, especially in high-availability configurations. Simplifying the installation and configuration of Geo for single and multi-node sites will remove a pain point for systems administrators and help drive adoption.
We are currently not planning on moving away from PostgreSQL as a backend database in favor of e.g CockroachDB or Google Spanner. This has implications for writable Geo site Geo, but for now, we will continue to support PostgreSQL.
Geo secondary sites are read-only. Customer feedback has indicated a desire for additional active active git replication. With the availability of Gitaly Cluster we may start investigating writable Geo sites at some point in FY23.
Geo will remain an asynchronous solution with loose time constraints for replications and verification.
This category is currently at the Complete maturity level, and our next maturity
target is Lovable (see our definitions of maturity
levels.
You can track the work that will move the category to Lovable in
this epic.
The top competitors for Geo-replication are
| Feature | GitHub | AzureDevOps | Bitbucket Smart Mirroring | GitLab |
|---|---|---|---|---|
| Mirror repositories | ✅ | ✅ | ✅ | ✅ |
| Active-active replication | ✅ | N/A | ❌ | ❌ |
| Selective sync | N/A | N/A | ✅ | ⚠️ |
| UI configuration | ❌ | ✅ | N/A | ⚠️ |
| Kubernetes support | ❌ | ❌ | ❌ | ⚠️ |
| Mirror docker registries | ❌ | N/A | ❌ | ✅ |
| LFS and file upload support | ✅ | N/A | ✅ | ✅ |
| Automatic DNS | ✅ | ✅ | ❌ | ⚠️ |
| GUI Dashboard | ✅ | ✅ | N/A | ✅ |
| Request proxying | ✅ | N/A | N/A | ⚠️ |
✅ Fully available ⚠️ Partially available ❌ Not available N/A No information available