// Module included in the following assemblies:
//
// * scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.adoc]

:_mod-docs-content-type: REFERENCE
[id="ztp-gitops-ztp-max-spoke-clusters_{context}"]
= Recommended hub cluster specifications and managed cluster limits for {ztp}

[role="_abstract"]
With {ztp-first}, you can manage thousands of clusters in geographically dispersed regions and networks.
The Red Hat Performance and Scale lab successfully created and managed 3500 virtual {sno} clusters with a reduced DU profile from a single {rh-rhacm-first} hub cluster in a lab environment.

In real-world situations, the scaling limits for the number of clusters that you can manage will vary depending on various factors affecting the hub cluster.
For example:

Hub cluster resources::
Available hub cluster host resources (CPU, memory, storage) are an important factor in determining how many clusters the hub cluster can manage.
The more resources allocated to the hub cluster, the more managed clusters it can accommodate.

Hub cluster storage::
The hub cluster host storage IOPS rating and whether the hub cluster hosts use NVMe storage can affect hub cluster performance and the number of clusters it can manage.

Network bandwidth and latency::
Slow or high-latency network connections between the hub cluster and managed clusters can impact how the hub cluster manages multiple clusters.

Managed cluster size and complexity::
The size and complexity of the managed clusters also affects the capacity of the hub cluster.
Larger managed clusters with more nodes, namespaces, and resources require additional processing and management resources.
Similarly, clusters with complex configurations such as the RAN DU profile or diverse workloads can require more resources from the hub cluster.

Number of managed policies::
The number of policies managed by the hub cluster scaled over the number of managed clusters bound to those policies is an important factor that determines how many clusters can be managed.

Monitoring and management workloads::
{rh-rhacm} continuously monitors and manages the managed clusters.
The number and complexity of monitoring and management workloads running on the hub cluster can affect its capacity.
Intensive monitoring or frequent reconciliation operations can require additional resources, potentially limiting the number of manageable clusters.

{rh-rhacm} version and configuration::
Different versions of {rh-rhacm} can have varying performance characteristics and resource requirements.
Additionally, the configuration settings of {rh-rhacm}, such as the number of concurrent reconciliations or the frequency of health checks, can affect the managed cluster capacity of the hub cluster.

Use the following representative configuration and network specifications to develop your own Hub cluster and network specifications.

[IMPORTANT]
====
The following guidelines are based on internal lab benchmark testing only and do not represent complete bare-metal host specifications.
====

.Representative three-node hub cluster machine specifications
[cols=2*, width="90%", options="header"]
|====
|Requirement
|Description

|Server hardware
|3 x Dell PowerEdge R650 rack servers

|NVMe hard disks
a|* 50 GB disk for `/var/lib/etcd`
* 2.9 TB disk for `/var/lib/containers`

|SSD hard disks
a|* 1 SSD split into 15 200GB thin-provisioned logical volumes provisioned as `PV` CRs
* 1 SSD serving as an extra large `PV` resource

|Number of applied DU profile policies
|5
|====

[IMPORTANT]
====
The following network specifications are representative of a typical real-world RAN network and were applied to the scale lab environment during testing.
====

.Simulated lab environment network specifications
[cols=2*, width="90%", options="header"]
|====
|Specification
|Description

|Round-trip time (RTT) latency
|50 ms

|Packet loss
|0.02% packet loss

|Network bandwidth limit
|20 Mbps
|====
