diff options
Diffstat (limited to 'doc/administration/gitaly/index.md')
| -rw-r--r-- | doc/administration/gitaly/index.md | 56 |
1 files changed, 20 insertions, 36 deletions
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 1b7e1f0f7c6..32b44552b1a 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -54,9 +54,8 @@ Before deploying Gitaly Cluster, review: If you have: -- Not yet migrated to Gitaly Cluster and want to continue using NFS, remain on the service you are using. NFS is - supported in 14.x releases but is [deprecated](../../update/deprecations.md#nfs-for-git-repository-storage). - Support for storing Git repository data on NFS is scheduled to end for all versions of GitLab on November 22, 2022. +- Not yet migrated to Gitaly Cluster and want to continue using NFS, remain on the service you are using. However, NFS + is [no longer supported](../../update/removals.md#nfs-as-git-repository-storage-is-no-longer-supported). - Not yet migrated to Gitaly Cluster but want to migrate away from NFS, you have two options: - A sharded Gitaly instance. - Gitaly Cluster. @@ -90,6 +89,23 @@ If you are unable to use either method, contact customer support for restoration Contact customer support for immediate help in restoration or recovery. +## Disk requirements + +Gitaly and Gitaly Cluster require fast local storage to perform effectively because they are heavy I/O-based processes. Therefore, +we strongly recommend that all Gitaly nodes use solid-state drives (SSDs). + +These SSDs should have a throughput of at least: + +- 8,000 input/output operations per second (IOPS) for read operations. +- 2,000 IOPS for write operations. + +These IOPS values are initial recommendations, and may be adjusted to greater or lesser values +depending on the scale of your environment's workload. If you’re running the environment on a +cloud provider, refer to their documentation about how to configure IOPS correctly. + +For repository data, only local storage is supported for Gitaly and Gitaly Cluster for performance and consistency reasons. +Alternatives such as [NFS](../nfs.md) or [cloud-based file systems](../nfs.md#avoid-using-cloud-based-file-systems) are not supported. + ## Directly accessing repositories GitLab doesn't advise directly accessing Gitaly repositories stored on disk with a Git client or any other tool, @@ -405,33 +421,6 @@ The leftover state is eventually cleaned up. Unlike Gitaly, Gitaly Cluster doesn't move the repositories in the storages but only virtually moves the repository by updating the relative path of the repository in the metadata store. -### Moving beyond NFS - -Engineering support for NFS for Git repositories is deprecated. Technical support is planned to be unavailable starting -November 22, 2022. See our [statement of support](https://about.gitlab.com/support/statement-of-support/#gitaly-and-nfs) -for more details. - -[Network File System (NFS)](https://en.wikipedia.org/wiki/Network_File_System) -is not well suited to Git workloads which are CPU and IOPS sensitive. -Specifically: - -- Git is sensitive to file system latency. Some operations require many - read operations. Operations that are fast on block storage can become an order of - magnitude slower. This significantly impacts GitLab application performance. -- NFS performance optimizations that prevent the performance gap between - block storage and NFS being even wider are vulnerable to race conditions. We have observed - [data inconsistencies](https://gitlab.com/gitlab-org/gitaly/-/issues/2589) - in production environments caused by simultaneous writes to different NFS - clients. Data corruption is not an acceptable risk. - -Gitaly Cluster is purpose built to provide reliable, high performance, fault -tolerant Git storage. - -Further reading: - -- Blog post: [The road to Gitaly v1.0 (aka, why GitLab doesn't require NFS for storing Git data anymore)](https://about.gitlab.com/blog/2018/09/12/the-road-to-gitaly-1-0/) -- Blog post: [How we spent two weeks hunting an NFS bug in the Linux kernel](https://about.gitlab.com/blog/2018/11/14/how-we-spent-two-weeks-hunting-an-nfs-bug/) - ### Components Gitaly Cluster consists of multiple components: @@ -672,7 +661,7 @@ To see if GitLab can access the repository file system directly, we use the foll - Gitaly ensures that the file system has a metadata file in its root with a UUID in it. - Gitaly reports this UUID to GitLab by using the `ServerInfo` RPC. -- GitLab Rails tries to read the metadata file directly. If it exists, and if the UUID's match, +- GitLab Rails tries to read the metadata file directly. If it exists, and if the UUIDs match, assume we have direct access. Direct Git access is: @@ -696,8 +685,3 @@ There are two facets to our efforts to remove direct Git access in GitLab: The second facet presents the only real solution. For this, we developed [Gitaly Cluster](#gitaly-cluster). - -## NFS deprecation notice - -Engineering support for NFS for Git repositories is deprecated. Technical support is planned to be -unavailable beginning November 22, 2022. For further information, see our [NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation) documentation. |