Merge branch 'DarwinJS-update-aws-implementation-patterns' into 'master'

Repurpose Gitaly SRE Subpage to GitLab AWS SRE Subpage

See merge request gitlab-org/gitlab!69250

doc/install/aws/gitaly_on_aws.md → doc/install/aws/gitlab_sre_for_aws.md

 ---
-type: reference, concepts
 stage: Enablement
 group: Alliances
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+description: Doing SRE for GitLab instances and runners on AWS.
+type: index
 ---
 
-# Gitaly SRE Considerations
+# GitLab Site Reliability Engineering for AWS
+
+## Known issues list
+
+Known issues are gathered from within GitLab and from customer reported issues. Customers successfully implement GitLab with a variety of "as a Service" components that GitLab has not specifically been designed for, nor has ongoing testing for. While GitLab does take partner technologies very seriously, the highlighting of known issues here is a convenience for implementers and it does not imply that GitLab has targeted compatibility with, nor carries any type of guarantee of running on the partner technology where the issues occur. Please consult individual issues to understand GitLabs stance and plans on any given known issue.
+
+See the [GitLab AWS known issues list](https://gitlab.com/gitlab-com/alliances/aws/public-tracker/-/issues?label_name%5B%5D=AWS+Known+Issue) for a complete list.
+
+## Gitaly SRE considerations
 
 Gitaly and Gitaly Cluster have been engineered by GitLab to overcome fundamental challenges with horizontal scaling of the open source Git binaries. Here is indepth technical reading on the topic:
 
-## Why Gitaly was built
+### Why Gitaly was built
 
 Below are some links to better understand why Gitaly was built:
 
@@ -18,17 +28,17 @@ Below are some links to better understand why Gitaly was built:
 - [Affects on horizontal compute architecture](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#affects-on-horizontal-compute-architecture)
 - [Evidence to back building a new horizontal layer to scale Git](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#evidence-to-back-building-a-new-horizontal-layer-to-scale-git)
 
-## Gitaly and Praefect elections
+### Gitaly and Praefect elections
 
 As part of Gitaly cluster consistency, Praefect nodes will occasionally need to vote on what data copy is the most accurate. This requires an uneven number of Praefect nodes to avoid stalemates. This means that for HA, Gitaly and Praefect require a minimum of three nodes.
 
-## Gitaly performance monitoring
+### Gitaly performance monitoring
 
 Complete performance metrics should be collected for Gitaly instances for identification of bottlenecks, as they could have to do with disk IO, network IO or memory.
 
 Gitaly must be implemented on instance compute.
 
-## Gitaly EBS volume sizing guidelines
+### Gitaly EBS volume sizing guidelines
 
 Gitaly storage is expected to be local (not NFS of any type including EFS).
 Gitaly servers also need disk space for building and caching Git pack files.
@@ -40,10 +50,10 @@ Background:
 - Use Amazon Linux 2 to ensure the best disk and memory optimizations (for example, ENA network adapters and drivers).
 - If GitLab backup scripts are used, they need a temporary space location large enough to hold 2 times the current size of the Git File system. If that will be done on Gitaly servers, separate volumes should be used. 
 
-## Gitaly HA in EKS quick start
+### Gitaly HA in EKS quick start
 
-The AWS EKS quick start for GitLab Cloud Native implements Gitaly as a multi-zone, self-healing infrastructure. It has specific code for reestablishing a Gitaly node when one fails, including AZ failure.
+The [AWS GitLab Cloud Native Hybrid on EKS Quick Start](gitlab_hybrid_on_aws.md#available-infrastructure-as-code-for-gitlab-cloud-native-hybrid) for GitLab Cloud Native implements Gitaly as a multi-zone, self-healing infrastructure. It has specific code for reestablishing a Gitaly node when one fails, including AZ failure.
 
-## Gitaly long term management
+### Gitaly long term management
 
 Gitaly node disk sizes will need to be monitored and increased to accommodate Git repository growth and Gitaly temporary and caching storage needs. The storage configuration on all nodes should be kept identical.

doc/install/aws/index.md

@@ -23,14 +23,18 @@ Implementation patterns are built on the foundational information and testing do
 
 [Omnibus GitLab on AWS EC2 (HA)](manual_install_aws.md) - instructions for installing GitLab on EC2 instances. Manual instructions from which you may build out a GitLab instance or create your own Infrastructure as Code (IaC).
 
-### Gitaly SRE considerations for AWS
+### GitLab Site Reliability Engineering (SRE) for AWS
 
-[Gitaly SRE Considerations for AWS](gitaly_on_aws.md) - important information for implementing and managing GitLab Gitaly on AWS.
+[GitLab SRE Considerations for AWS](gitlab_sre_for_aws.md) - important information and known issues for planning, implementing, upgrading and long term management of GitLab instances and runners on AWS.
 
 ### EKS cluster provisioning best practices
 
 [EKS Cluster Provisioning Patterns](eks_clusters_aws.md) - considerations for setting up EKS cluster for runners and for integrating.
 
+### Scaling HA GitLab Runner on AWS EC2 ASG
+
+The following repository is self-contained in regard to enabling this pattern: [GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/). The [feature list for this implementation pattern](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/-/blob/main/FEATURES.md) is good to review to understand the complete value it can deliver.
+
 ## Additional details on implementation patterns
 
 GitLab implementation patterns build upon [GitLab Reference Architectures](../../administration/reference_architectures/index.md) in the following ways.