// Module included in the following assemblies:
//
// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc

:_mod-docs-content-type: REFERENCE
[id="telco-ran-engineering-considerations-for-the-ran-du-use-model_{context}"]
= Engineering considerations for the RAN DU use model

[role="_abstract"]
The RAN DU use model configures an {product-title} cluster running on commodity hardware for hosting RAN distributed unit (DU) workloads.
Model and system level considerations are described below.
Specific limits, requirements and engineering considerations for individual components are detailed in later sections.

[NOTE]
====
For details of the telco RAN DU RDS KPI test results, see the link:https://access.redhat.com/articles/7143490[telco RAN DU {product-version} reference design specification KPI test results].
This information is only available to customers and partners.
====

Cluster topology::
+
--
The recommended topology for RAN DU workloads is {sno}.
DU workloads may be run on other cluster topologies such as 3-node compact cluster, high availability (3 control plane + n worker nodes), or SNO+1 as needed.
Multiple SNO clusters, or a highly-available 3-node compact cluster, are recommended over the SNO+1 topology.

Under the standard cluster topology case (3+n), a mixed architecture cluster is allowed only if:

* All control plane nodes are x86_64.
* All worker nodes are aarch64.

Remote worker node (RWN) cluster topologies are not recommended or included under this reference design specification.
For workloads with high service level agreement requirements such as RAN DU the following drawbacks exclude RWN from consideration:

* No support for Image Based Upgrades and the benefits offered by that feature, such as faster upgrades and rollback capability.
* Updates to Day 2 operators affect all RWNs simultaneously without the ability to perform a rolling update.
* Loss of the control plane (disaster scenario) would have a significantly higher impact on overall service availability due to the greater number of sites served by that control plane.
* Loss of network connectivity between the RWN and the control plane for a period exceeding the monitoring grace period and toleration timeouts might result in pod eviction and lead to a service outage.
* No support for container image pre-caching.
* Additional complexities in workload affinities.

--

Supported cluster topologies for RAN DU::
+
.Supported cluster topologies for RAN DU
[cols="1,2,3,4,5,6", options="header"]
|===
|Architecture
|SNO
|SNO+1
|3-node 
|Standard 
|RWN

|x86_64
|Yes
|Yes
|Yes
|Yes
|No

|aarch64
|Yes
|No
|No
|No
|No

|mixed
|N/A
|No
|No
|Yes 
|No

|===
+
* The standard mixed-architecture topology uses `x86_64` control plane nodes and `AArch64` worker nodes.

Workloads::
. DU workloads are described in xref:../scalability_and_performance/telco-ran-du-rds.adoc#telco-ran-du-application-workloads_telco-ran-du[Telco RAN DU application workloads].
. DU worker nodes are Intel 3rd Generation Xeon (Ice Lake) 2.20 GHz or newer with host firmware tuned for maximum performance.

Resources::
The maximum number of running pods in the system, inclusive of application workload and {product-title} pods, is 160.

Resource utilization::
+
--
{product-title} resource utilization varies depending on many factors such as the following application workload characteristics:

* Pod count
* Type and frequency of probes
* Messaging rates on the primary or secondary CNI with kernel networking
* API access rate
* Logging rates
* Storage IOPS

Resource utilization is measured for clusters configured as follows:

. The cluster is a single host with {sno} installed.
. The cluster runs the representative application workload described in "Reference application workload characteristics".
. The cluster is managed under the constraints detailed in "Hub cluster management characteristics".
. Components noted as "optional" in the use model configuration are not included.

[NOTE]
====
Configuration outside the scope of the RAN DU RDS that do not meet these criteria requires additional analysis to determine the impact on resource utilization and ability to meet KPI targets.
You might need to allocate additional cluster resources to meet these requirements.
====
--

Reference application workload characteristics::
. Uses 75 pods across 5 namespaces with 4 containers per pod for the vRAN application including its management and control functions
. Creates 30 `ConfigMap` CRs and 30 `Secret` CRs for each namespace
+
[NOTE]
====
The RDS validates mutable `ConfigMap` CRs. However, use immutable `ConfigMap` CRs where possible. Immutable resources significantly reduce the load on the API server by eliminating resource watches. A high volume of `ConfigMap` CRs, up to the validated 30 for vDU, might increase node recovery time during reboots, as volume mount points are recreated. The maximum size for each `ConfigMap` CR is limited to 1 MB.
====
. Uses no exec probes
. Uses a secondary network
+
[NOTE]
====
You can extract CPU load can from the platform metrics.
For example:
[source,terminal]
----
$ query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
----
====
. Application logs are not collected by the platform log collector.
. Aggregate traffic on the primary CNI is up to 30 Mbps and up to 5 Gbps on the secondary network

Hub cluster management characteristics::
+
--
{rh-rhacm}  is the recommended cluster management solution and is configured to these limits:

. Use a maximum of 10 {rh-rhacm} configuration policies, comprising 5 Red{nbsp}Hat provided policies and up to 5 custom configuration policies with a compliant evaluation interval of not less than 10 minutes.
. Use a minimal number (up to 10) of managed cluster templates in cluster policies.
Use hub-side templating.
. Disable {rh-rhacm} addons with the exception of the `policyController` and configure observability with the default configuration.

The following table describes resource utilization under reference application load.

.Resource utilization under reference application load
[cols="1,2,3", width="90%", options="header"]
|====
|Metric
|Limits
|Notes

|OpenShift platform CPU usage
|Less than 4000mc – 2 cores (4HT)
|Platform CPU is pinned to reserved cores, including both hyper-threads of each reserved core.
The system is engineered to 3 CPUs (3000mc) at steady-state to allow for periodic system tasks and spikes.

|OpenShift Platform memory
|Less than 16G
|

|====
--

Disconnected environment::
+
--
RAN DU clusters are typically deployed in disconnected environments without direct access to the internet.
All container images needed to install, configure, and operate the cluster must be available in a disconnected registry.

In {product-title} {product-version} and later, pulling OpenShift images from a disconnected mirror registry requires copying the image signatures into that registry during the mirroring process.
The `oc adm mirror` command does not mirror signatures and must not be used.
Instead, use the `oc mirror` plugin v2 to ensure signatures are properly mirrored.
--
