summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDrew Blessing <drew@gitlab.com>2017-05-17 14:43:48 -0500
committerDrew Blessing <drew@gitlab.com>2017-05-17 15:07:38 -0500
commitcd996c5c9c801f91fad7047f2b34909cf9d5ff8d (patch)
treeea53d8f9a2a81dfa1f692397b3863ae833a699e3
parentacb72a8e6053fd8ffe197c294f6e86f3792a4f66 (diff)
downloadgitlab-ce-cd996c5c9c801f91fad7047f2b34909cf9d5ff8d.tar.gz
Replace EFS section in AWS guide
-rw-r--r--doc/administration/high_availability/nfs.md8
-rw-r--r--doc/university/high-availability/aws/README.md22
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)
***