From 65382a9763c604799f34ef7e0b3839fc707ffdc4 Mon Sep 17 00:00:00 2001 From: Drew Blessing Date: Wed, 17 May 2017 10:04:07 -0500 Subject: Consolidate opening text from about.gitlab.com and add active/passive note Add opening text that was previously on https://about.gitlab.com/high-availability and add a note that active/passive is compatible but not supported. --- doc/administration/high_availability/README.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md index d5a5aef7ec0..4d3be0ab8f6 100644 --- a/doc/administration/high_availability/README.md +++ b/doc/administration/high_availability/README.md @@ -5,6 +5,20 @@ The solution you choose will be based on the level of scalability and availability you require. The easiest solutions are scalable, but not necessarily highly available. +GitLab provides a service that is usually essential to most organizations: it +enables people to collaborate on code in a timely fashion. Any downtime should +therefore be short and planned. Luckily, GitLab provides a solid setup even on +a single server without special measures. Due to the distributed nature +of Git, developers can still commit code locally even when GitLab is not +available. However, some GitLab features such as the issue tracker and +Continuous Integration are not available when GitLab is down. + +**Keep in mind that all Highly Available solutions come with a trade-off between +cost/complexity and uptime**. The more uptime you want, the more complex the +solution. And the more complex the solution, the more work is involved in +setting up and maintaining it. High availability is not free and every HA +solution should balance the costs against the benefits. + ## Architecture There are two kinds of setups: @@ -37,6 +51,10 @@ Block Device) to keep all data in sync. DRBD requires a low latency link to remain in sync. It is not advisable to attempt to run DRBD between data centers or in different cloud availability zones. +> **Note:** GitLab recommends against choosing this HA method because of the + complexity of managing DRBD and crafting automatic failover. This is + *compatible* with GitLab, but not officially *supported*. + Components/Servers Required: 2 servers/virtual machines (one active/one passive) ![Active/Passive HA Diagram](../img/high_availability/active-passive-diagram.png) -- cgit v1.2.3 From acb72a8e6053fd8ffe197c294f6e86f3792a4f66 Mon Sep 17 00:00:00 2001 From: Drew Blessing Date: Wed, 17 May 2017 10:16:01 -0500 Subject: Add warning about AWS EFS and performance --- doc/administration/high_availability/nfs.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index c5125dc6d5a..82bb5689d0a 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -7,6 +7,23 @@ supported natively in NFS version 4. NFSv3 also supports locking as long as Linux Kernel 2.6.5+ is used. We recommend using version 4 and do not specifically test NFSv3. +## AWS Elastic File System (EFS) not recommended + +Customers and users have reported that AWS EFS does not perform well for GitLab's +use-case. There are several issues that can cause problems. For these reasons +GitLab recommends against using EFS with GitLab. + +- EFS bases allowed IOPS on volume size. The larger the volume, the more IOPS + are allocated. For smaller volumes, users may experience decent performance + for a period of time due to 'Burst Credits'. Over a period of weeks to months + credits may run out and performance will bottom out. +- For larger volumes, allocated IOPS may not be the problem. Workloads where + many small files are written in a serialized manner are not well-suited for EFS. + EBS with an NFS server on top will perform much better. + +For more details on another person's experience with EFS, see +[Amazon's Elastic File System: Burst Credits]()https://www.rawkode.io/2017/04/amazons-elastic-file-system-burst-credits/ + ### Recommended options When you define your NFS exports, we recommend you also add the following -- cgit v1.2.3 From cd996c5c9c801f91fad7047f2b34909cf9d5ff8d Mon Sep 17 00:00:00 2001 From: Drew Blessing Date: Wed, 17 May 2017 14:43:48 -0500 Subject: Replace EFS section in AWS guide --- doc/administration/high_availability/nfs.md | 8 +++++--- doc/university/high-availability/aws/README.md | 22 ++++++++++++---------- 2 files changed, 17 insertions(+), 13 deletions(-) diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index 82bb5689d0a..d8e76d6ab94 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -7,11 +7,13 @@ supported natively in NFS version 4. NFSv3 also supports locking as long as Linux Kernel 2.6.5+ is used. We recommend using version 4 and do not specifically test NFSv3. -## AWS Elastic File System (EFS) not recommended +## AWS Elastic File System + +GitLab does not recommend using AWS Elastic File System (EFS). Customers and users have reported that AWS EFS does not perform well for GitLab's use-case. There are several issues that can cause problems. For these reasons -GitLab recommends against using EFS with GitLab. +GitLab does not recommend using EFS with GitLab. - EFS bases allowed IOPS on volume size. The larger the volume, the more IOPS are allocated. For smaller volumes, users may experience decent performance @@ -22,7 +24,7 @@ GitLab recommends against using EFS with GitLab. EBS with an NFS server on top will perform much better. For more details on another person's experience with EFS, see -[Amazon's Elastic File System: Burst Credits]()https://www.rawkode.io/2017/04/amazons-elastic-file-system-burst-credits/ +[Amazon's Elastic File System: Burst Credits](https://www.rawkode.io/2017/04/amazons-elastic-file-system-burst-credits/) ### Recommended options diff --git a/doc/university/high-availability/aws/README.md b/doc/university/high-availability/aws/README.md index 088f1cd7290..6b8f3cd3d1d 100644 --- a/doc/university/high-availability/aws/README.md +++ b/doc/university/high-availability/aws/README.md @@ -159,19 +159,21 @@ subnet and security group and *** -## Elastic File System +## Network File System -This new AWS offering allows us to create a file system accessible by
 -EC2 instances within a VPC. Choose our VPC and the subnets will be -
automatically configured assuming we don't need to set explicit IPs. -The
next section allows us to add tags and choose between General -Purpose or
Max I/O which is a good option when being accessed by a -large number of
EC2 instances. +GitLab requires a shared filesystem such as NFS. The file share(s) will be +mounted on all application servers. There are a variety of ways to build an +NFS server on AWS. -

![Elastic File System](img/elastic-file-system.png) +One option is to use a third-party AMI that offers NFS as a service. A [search +for 'NFS' in the AWS Marketplace](https://aws.amazon.com/marketplace/search/results?x=0&y=0&searchTerms=NFS&page=1&ref_=nav_search_box) +shows options such as NetApp, SoftNAS and others. -To actually mount and install the NFS client we'll use the User Data -section when adding our Launch Configuration. +Another option is to build a simple NFS server using a vanilla Linux server backed +by AWS Elastic Block Storage (EBS). + +> **Note:** GitLab does not recommend using AWS Elastic File System (EFS). See + details in [High Availability NFS documentation](../../../administration/high_availability/nfs.md#aws-elastic-file-system) *** -- cgit v1.2.3