Merge branch 'docs-add-2k-page-changes' into 'master'

Docs: Incorporate 2K page changes

See merge request gitlab-org/gitlab!37950

doc/administration/reference_architectures/1k_users.md

+---
+stage: Enablement
+group: Distribution
+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/#designated-technical-writers
+---
+
 # Reference architecture: up to 1,000 users
 
-This page describes GitLab reference architecture for up to 1,000 users.
-For a full list of reference architectures, see
+This page describes GitLab reference architecture for up to 1,000 users. For a
+full list of reference architectures, see
 [Available reference architectures](index.md#available-reference-architectures).
 
-> - **Supported users (approximate):** 1,000
-> - **High Availability:** False
-
-| Users       | Configuration([8](#footnotes))     | GCP            | AWS                 | Azure                  |
-|-------------|------------------------------------|----------------|---------------------|------------------------|
-| up to 500   | 4 vCPU, 3.6GB Memory               | `n1-highcpu-4` | `c5.xlarge`         | F4s v2                 |
-| up to 1000  | 8 vCPU, 7.2GB Memory               | `n1-highcpu-8` | `c5.2xlarge`        | F8s v2                 |
-
-In addition to the above, we recommend having at least
-2GB of swap on your server, even if you currently have
-enough available RAM. Having swap will help reduce the chance of errors occurring
-if your available memory changes. We also recommend
-configuring the kernel's swappiness setting
-to a low value like `10` to make the most of your RAM while still having the swap
-available when needed.
+If you need to serve up to 1,000 users and you don't have strict availability
+requirements, a single-node solution with
+[frequent backups](index.md#automated-backups-core-only) is appropriate for
+many organizations .
 
-For situations where you need to serve up to 1,000 users, a single-node
-solution with [frequent backups](index.md#automated-backups-core-only) is appropriate
-for many organizations. With automatic backup of the GitLab repositories,
-configuration, and the database, if you don't have strict availability
-requirements, this is the ideal solution.
+> - **Supported users (approximate):** 1,000
+> - **High Availability:** No
+
+| Users        | Configuration           | GCP            | AWS             | Azure          |
+|--------------|-------------------------|----------------|-----------------|----------------|
+| Up to 500    | 4 vCPU, 3.6GB memory    | n1-highcpu-4   | c5.xlarge       | F4s v2         |
+| Up to 1,000  | 8 vCPU, 7.2GB memory    | n1-highcpu-8   | c5.2xlarge      | F8s v2         |
+
+The Google Cloud Platform (GCP) architectures were built and tested using the
+[Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
+CPU platform. On different hardware you may find that adjustments, either lower
+or higher, are required for your CPU or node counts. For more information, see
+our [Sysbench](https://github.com/akopytov/sysbench)-based
+[CPU benchmark](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks).
+
+In addition to the stated configurations, we recommend having at least 2GB of
+swap on your server, even if you currently have enough available memory. Having
+swap will help reduce the chance of errors occurring if your available memory
+changes. We also recommend configuring the kernel's swappiness setting to a
+lower value (such as `10`) to make the most of your memory, while still having
+the swap available when needed.
 
 ## Setup instructions
 
-- For this default reference architecture, use the standard [installation instructions](../../install/README.md) to install GitLab.
+For this default reference architecture, to install GitLab use the standard
+[installation instructions](../../install/README.md).
 
 NOTE: **Note:**
 You can also optionally configure GitLab to use an
 [external PostgreSQL service](../postgresql/external.md) or an
 [external object storage service](../high_availability/object_storage.md) for
 added performance and reliability at a reduced complexity cost.
-
-## Footnotes
-
-1. In our architectures we run each GitLab Rails node using the Puma webserver
-   and have its number of workers set to 90% of available CPUs along with four threads. For
-   nodes that are running Rails with other components the worker value should be reduced
-   accordingly where we've found 50% achieves a good balance but this is dependent
-   on workload.
-
-1. Gitaly node requirements are dependent on customer data, specifically the number of
-   projects and their sizes. We recommend two nodes as an absolute minimum for HA environments
-   and at least four nodes should be used when supporting 50,000 or more users.
-   We also recommend that each Gitaly node should store no more than 5TB of data
-   and have the number of [`gitaly-ruby` workers](../gitaly/index.md#gitaly-ruby)
-   set to 20% of available CPUs. Additional nodes should be considered in conjunction
-   with a review of expected data size and spread based on the recommendations above.
-
-1. Recommended Redis setup differs depending on the size of the architecture.
-   For smaller architectures (less than 3,000 users) a single instance should suffice.
-   For medium sized installs (3,000 - 5,000) we suggest one Redis cluster for all
-   classes and that Redis Sentinel is hosted alongside Consul.
-   For larger architectures (10,000 users or more) we suggest running a separate
-   [Redis Cluster](../redis/replication_and_failover.md#running-multiple-redis-clusters) for the Cache class
-   and another for the Queues and Shared State classes respectively. We also recommend
-   that you run the Redis Sentinel clusters separately for each Redis Cluster.
-
-1. For data objects such as LFS, Uploads, Artifacts, etc. We recommend an [Object Storage service](../object_storage.md)
-   over NFS where possible, due to better performance and availability.
-
-1. NFS can be used as an alternative for both repository data (replacing Gitaly) and
-   object storage but this isn't typically recommended for performance reasons. Note however it is required for
-   [GitLab Pages](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/196).
-
-1. Our architectures have been tested and validated with [HAProxy](https://www.haproxy.org/)
-   as the load balancer. Although other load balancers with similar feature sets
-   could also be used, those load balancers have not been validated.
-
-1. We strongly recommend that any Gitaly or NFS nodes be set up with SSD disks over
-   HDD with a throughput of at least 8,000 IOPS for read operations and 2,000 IOPS for write
-   as these components have heavy I/O. These IOPS values are recommended only as a starter
-   as with time they may be adjusted higher or lower depending on the scale of your
-   environment's workload. If you're running the environment on a Cloud provider
-   you may need to refer to their documentation on how configure IOPS correctly.
-
-1. The architectures were built and tested with the [Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
-   CPU platform on GCP. On different hardware you may find that adjustments, either lower
-   or higher, are required for your CPU or Node counts accordingly. For more information, a
-   [Sysbench](https://github.com/akopytov/sysbench) benchmark of the CPU can be found
-   [here](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks).