Skip to content

Commit 90230ce

Browse files
jab-rhjab-rh
authored
Merge pull request #93098 from rohennes/TELCODOCS-1874
TELCODOCS-1874: Adding hub cluster RDS - Tech Preview
2 parents 5f547b2 + c159114 commit 90230ce

33 files changed

+1284
-0
lines changed

‎_topic_maps/_topic_map.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3366,6 +3366,8 @@ Topics:
33663366
File: telco-core-rds
33673367
- Name: Telco RAN DU reference design specifications
33683368
File: telco-ran-du-rds
3369+
- Name: Telco hub reference design specifications
3370+
File: telco-hub-rds
33693371
- Name: Comparing cluster configurations
33703372
Dir: cluster-compare
33713373
Distros: openshift-origin,openshift-enterprise

‎images/telco-hub-cluster-rds-architecture.png

89.3 KB
Loading

‎images/telco-hub-cluster-reference-design-components.png

172 KB
Loading

‎modules/telco-hub-acm-observability.adoc

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
:_mod-docs-content-type: REFERENCE
2+
[id="telco-hub-acm-observability_{context}"]
3+
= {rh-rhacm} Observability
4+
5+
Cluster Observability is provided by the multicluster engine and {rh-rhacm-first}.
6+
7+
* Observability storage needs several `PV` resources and an S3 compatible bucket storage for long term retention of the metrics.
8+
* Storage requirements calculation is complex and dependent on the specific workloads and characteristics of managed clusters.
9+
Requirements for `PV` resources and the S3 bucket depend on many aspects including data retention, the number of managed clusters, managed cluster workloads, and so on.
10+
* Estimate the required storage for observability by using the observability sizing calculator in the {rh-rhacm} capacity planning repository.
11+
See the Red Hat Knowledgebase article link:https://access.redhat.com/articles/7103886[Calculating storage need for MultiClusterHub Observability on telco environments] for an explanation of using the calculator to estimate observability storage requirements.
12+
The below table uses inputs derived from the telco RAN DU RDS and the hub cluster RDS as representative values.
13+
14+
[NOTE]
15+
====
16+
The following numbers are estimated.
17+
Tune the values for more accurate results.
18+
Add an engineering margin, for example +20%, to the results to account for potential estimation inaccuracies.
19+
====
20+
21+
.Cluster requirements
22+
[cols="42%,42%,16%",options="header"]
23+
|====
24+
|Capacity planner input
25+
|Data source
26+
|Example value
27+
28+
|Number of control plane nodes
29+
|Hub cluster RDS (scale) and telco RAN DU RDS (topology)
30+
|3500
31+
32+
|Number of additional worker nodes
33+
|Hub cluster RDS (scale) and telco RAN DU RDS (topology)
34+
|0
35+
36+
|Days for storage of data
37+
|Hub cluster RDS
38+
|15
39+
40+
|Total number of pods per cluster
41+
|Telco RAN DU RDS
42+
|120
43+
44+
|Number of namespaces (excluding {product-title})
45+
|Telco RAN DU RDS
46+
|4
47+
48+
|Number of metric samples per hour
49+
|Default value
50+
|12
51+
52+
|Number of hours of retention in receiver persistent volume (PV)
53+
|Default value
54+
|24
55+
|====
56+
57+
With these input values, the sizing calculator as described in the Red Hat Knowledgebase article link:https://access.redhat.com/articles/7103886[Calculating storage need for MultiClusterHub Observability on telco environments] indicates the following storage needs:
58+
59+
.Storage requirements
60+
[options="header"]
61+
|====
62+
2+|`alertmanager` PV 2+|`thanos receive` PV 2+|`thanos compact` PV
63+
64+
|*Per replica* |*Total* |*Per replica* |*Total* 2+|*Total*
65+
66+
|10 GiB |30 GiB |10 GiB |30 GiB 2+|100 GiB
67+
|====
68+
69+
.Storage requirements
70+
[options="header"]
71+
|====
72+
2+|`thanos rule` PV 2+|`thanos store` PV 2+|Object bucket^[1]^
73+
74+
|*Per replica* |*Total* |*Per replica* |*Total* |*Per day* |*Total*
75+
76+
|30 GiB |90 GiB |100 GiB |300 GiB |15 GiB |101 GiB
77+
|====
78+
[1] For the object bucket, it is assumed that downsampling is disabled, so that only raw data is calculated for storage requirements.

‎modules/telco-hub-acmMCH-yaml.adoc

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
[id="telco-hub-acmMCH-yaml"]
2+
.acmMCH.yaml
3+
[source,yaml]
4+
----
5+
link:https://raw.githubusercontent.com/openshift-kni/telco-reference/release-4.19/telco-hub/configuration/reference-crs/required/acm/acmMCH.yaml[role=include]
6+
----
7+

‎modules/telco-hub-architecture-overview.adoc

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
:_mod-docs-content-type: CONCEPT
2+
[id="telco-hub-architecture-overview_{context}"]
3+
= Hub cluster architecture overview
4+
5+
6+
Use the features and components running on the management hub cluster to manage many other clusters in a hub-and-spoke topology.
7+
The hub cluster provides a highly available and centralized interface for managing the configuration, lifecycle, and observability of the fleet of deployed clusters.
8+
9+
[NOTE]
10+
====
11+
All management hub functionality can be deployed on a dedicated {product-title} cluster or as applications that are co-resident on an existing cluster.
12+
====
13+
14+
Managed cluster lifecycle::
15+
Using a combination of Day 2 Operators, the hub cluster provides the necessary infrastructure to deploy and configure the fleet of clusters by using a GitOps methodology.
16+
Over the lifetime of the deployed clusters, further management of upgrades, scaling the number of clusters, node replacement, and other lifecycle management functions can be declaratively defined and rolled out.
17+
You can control the timing and progression of the rollout across the fleet.
18+
19+
Monitoring::
20+
+
21+
--
22+
The hub cluster provides monitoring and status reporting for the managed clusters through the Observability pillar of the {rh-rhacm-full} Operator.
23+
This includes aggregated metrics, alerts, and compliance monitoring through the Governance policy framework.
24+
--
25+
26+
The telco management hub reference design specifications (RDS) and the associated reference custom resources (CRs) describe the telco engineering and QE validated method for deploying, configuring and managing the lifecycle of telco managed cluster infrastructure.
27+
The reference configuration includes the installation and configuration of the hub cluster components on top of {product-title}.
28+
29+
30+
.Hub cluster reference design components
31+
image::telco-hub-cluster-reference-design-components.png[]
32+
33+
.Hub cluster reference design architecture
34+
image::telco-hub-cluster-rds-architecture.png[]
35+

‎modules/telco-hub-assisted-service.adoc

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
:_mod-docs-content-type: REFERENCE
2+
[id="telco-hub-assisted-service_{context}"]
3+
= Assisted Service
4+
5+
The Assisted Service is deployed with the multicluster engine and {rh-rhacm-first}.
6+
7+
.Assisted Service storage requirements
8+
[cols="1,2", options="header"]
9+
|====
10+
|Persistent volume resource
11+
|Size (GB)
12+
13+
|`imageStorage`
14+
|50
15+
16+
|`filesystemStorage`
17+
|700
18+
19+
|`dataBaseStorage`
20+
|20
21+
|====

‎modules/telco-hub-cluster-topology.adoc

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
:_mod-docs-content-type: REFERENCE
2+
[id="telco-hub-cluster-topology_{context}"]
3+
= Cluster topology
4+
5+
In production environments, the {product-title} hub cluster must be highly available to maintain high availability of the management functions.
6+
7+
Limits and requirements::
8+
Use a highly available cluster topology for the hub cluster, for example:
9+
* Compact (3 nodes combined control plane and compute nodes)
10+
* Standard (3 control plane nodes + N compute nodes)
11+
12+
Engineering considerations::
13+
* In non-production environments, a {sno} cluster can be used for limited hub cluster functionality.
14+
* Certain capabilities, for example {rh-storage-first}, are not supported on {sno}.
15+
In this configuration, some hub cluster features might not be available.
16+
* The number of optional compute nodes can vary depending on the scale of the specific use case.
17+
* Compute nodes can be added later as required.

‎modules/telco-hub-engineering-considerations.adoc

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
:_mod-docs-content-type: REFERENCE
2+
[id="telco-hub-engineering-considerations_{context}"]
3+
= Hub cluster engineering considerations
4+
5+
The follwing sections describe the engineering considerations for hub cluster resource scaling targets and utilization.

‎modules/telco-hub-git-repository.adoc

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
:_mod-docs-content-type: CONCEPT
2+
[id="telco-hub-git-repository_{context}"]
3+
= Git repository
4+
5+
The telco management hub cluster supports a GitOps-driven methodology for installing and managing the configuration of OpenShift clusters for various telco applications.
6+
This methodology requires an accessible Git repository that serves as the authoritative source of truth for cluster definitions and configuration artifacts.
7+
8+
Red Hat does not offer a commercially supported Git server.
9+
An existing Git server provided in the production environment can be used.
10+
Gitea and Gogs are examples of self-hosted Git servers that you can use.
11+
12+
The Git repository is typically provided in the production network external to the hub cluster.
13+
In a large-scale deployment, multiple hub clusters can use the same Git repository for maintaining the definitions of managed clusters. Using this approach, you can easily review the state of the complete network.
14+
As the source of truth for cluster definitions, the Git repository should be highly available and recoverable in disaster scenarios.
15+
16+
[NOTE]
17+
====
18+
For disaster recovery and multi-hub considerations, run the Git repository separately from the hub cluster.
19+
====
20+
21+
Limits and requirements::
22+
* A Git repository is required to support the {ztp} functions of the hub cluster, including installation, configuration, and lifecycle management of the managed clusters.
23+
* The Git repository must be accessible from the management cluster.
24+
25+
Engineering considerations::
26+
* The Git repository is used by the GitOps Operator to ensure continuous deployment and a single source of truth for the applied configuration.
27+

0 commit comments

Comments
 (0)