Telco RAN DU 4.17 reference design components

You can now configure host firmware settings for managed clusters that you deploy with GitOps ZTP.

Hyperthreading must be enabled

Tune all settings for maximum performance.

All settings are expected to be for maximum performance unless tuned for power savings.

You can tune host firmware for power savings at the expense of performance as required.

Enable secure boot. With secure boot enabled, only signed kernel modules are loaded by the kernel. Out-of-tree drivers are not supported.

No reference design updates in this release

Select reserved and isolated cores and ensure that you allocate at least 4 hyperthreads (equivalent to 2 cores) on Intel 3rd Generation Xeon (Ice Lake) 2.20 GHz CPUs or better with firmware tuned for maximum performance.

Set the reserved cpuset to include both hyperthread siblings for each included core. Unreserved cores are available as allocatable CPU for scheduling workloads. Ensure that hyperthread siblings are not split across reserved and isolated cores.

Configure reserved and isolated CPUs to include all threads in all cores based on what you have set as reserved and isolated CPUs.

Set core 0 of each NUMA node to be included in the reserved CPU set.

Set the huge page size to 1G.

You should use the RT kernel to meet performance requirements. However, you can use the non-RT kernel with a corresponding impact to cluster performance if required.

The number of huge pages that you configure depends on the application workload requirements. Variation in this parameter is expected and allowed.

Variation is expected in the configuration of reserved and isolated CPU sets based on selected hardware and additional components in use on the system. Variation must still meet the specified limits.

Hardware without IRQ affinity support impacts isolated CPUs. To ensure that pods with guaranteed whole CPU QoS have full use of the allocated CPU, all hardware in the server must support IRQ affinity. For more information, see "Finding the effective IRQ affinity setting for a node".

A new version two of the Precision Time Protocol (PTP) fast event REST API is available. Consumer applications can now subscribe directly to the events REST API in the PTP events producer sidecar. The PTP fast event REST API v2 is compliant with the O-RAN O-Cloud Notification API Specification for Event Consumers 3.0. You can change the API version by setting the ptpEventConfig.apiVersion field in the PtpOperatorConfig resource.

As an ordinary clock (OC) synced to a grandmaster clock or boundary clock (T-BC).

As a grandmaster clock (T-GM) synced from GPS with support for single or dual card E810 NICs.

As dual boundary clocks (one per NIC) with support for E810 NICs.

As a T-BC with a highly available (HA) system clock when there are multiple time sources on different NICs.

Optional: as a boundary clock for radio units (RUs).

Limited to two boundary clocks for dual NIC and HA.

Limited to two card E810 configurations for T-GM.

Configurations are provided for ordinary clock, boundary clock, boundary clock with highly available system clock, and grandmaster clock.

PTP fast event notifications uses ConfigMap CRs to store PTP event subscriptions.

The PTP events REST API v2 does not have a global subscription for all lower hierarchy resources contained in the resource path. You subscribe consumer applications to the various available event types separately.

No reference design updates in this release

Use OpenShift Container Platform supported devices

SR-IOV and IOMMU enablement in BIOS: The SR-IOV Network Operator will automatically enable IOMMU on the kernel command line.

SR-IOV VFs do not receive link state updates from the PF. If link down detection is needed you must configure this at the protocol level.

NICs which do not support firmware updates using Secure Boot or kernel lockdown must be pre-configured with sufficient virtual functions (VFs) to support the number of VFs required by the application workload.

SR-IOV interfaces with the vfio driver type are typically used to enable additional secondary networks for applications that require high throughput or low latency.

Customer variation on the configuration and number of SriovNetwork and SriovNetworkNodePolicy custom resources (CRs) is expected.

IOMMU kernel command line settings are applied with a MachineConfig CR at install time. This ensures that the SriovOperator CR does not cause a reboot of the node when adding them.

SR-IOV support for draining nodes in parallel is not applicable in a single-node OpenShift cluster.

If you exclude the SriovOperatorConfig CR from your deployment, the CR will not be created automatically.

In scenarios where you pin or restrict workloads to specific nodes, the SR-IOV parallel node drain feature will not result in the rescheduling of pods. In these scenarios, the SR-IOV Operator disables the parallel node drain functionality.

Cluster Logging Operator 6.0 is new in this release. Update your existing implementation to adapt to the new version of the API.

Handling logs beyond the infrastructure and audit logs, for example, from the application workload requires additional CPU and network bandwidth based on additional logging rate.

As of OpenShift Container Platform 4.14, Vector is the reference log collector.

No reference design updates in this release

Starting with FEC Operator v2.7.0:

The SRIOV-FEC Operator uses CPU cores from the isolated CPU set.

You can validate FEC readiness as part of the pre-checks for application deployment, for example, by extending the validation policy.

No reference design updates in this release

The Lifecycle Agent is not applicable in multi-node clusters or single-node OpenShift clusters with an additional worker.

Requires a persistent volume that you create when installing the cluster. See "Configuring a shared container directory between ostree stateroots when using GitOps ZTP" for partition requirements.

No reference design updates in this release

Create backing storage for PV CRs before creating the PV. This can be a partition, a local volume, LVM volume, or full disk.

Refer to the device listing in LocalVolume CRs by the hardware path used to access each device to ensure correct allocation of disks and partitions. Logical names (for example, /dev/sda) are not guaranteed to be consistent across node reboots.

No reference design updates in this release

In single-node OpenShift clusters, persistent storage must be provided by either LVM Storage or local storage, not both.

Volume snapshots are excluded from the reference configuration.

LVM Storage can be used as the local storage implementation for the RAN DU use case. When LVM Storage is used as the storage solution, it replaces the Local Storage Operator, and the CPU required is assigned to the management partition as platform overhead. The reference configuration must include one of these storage solutions but not both.

Ensure that sufficient disks or partitions are available for storage requirements.

No reference design updates in this release

Namespace and Pod CRs must be annotated to allow the pod to be applied to the management partition

Pods with CPU limits cannot be allocated to the partition. This is because mutation can change the pod QoS.

For more information about the minimum number of CPUs that can be allocated to the management partition, see Node Tuning Operator.

Workload Partitioning pins all management pods to reserved cores. A sufficient number of cores must be allocated to the reserved set to account for operating system, management pods, and expected spikes in CPU use that occur when the workload starts, the node reboots, or other system events happen.

No reference design updates in this release

Cluster capabilities are not available for installer-provisioned installation methods.

You must apply all platform tuning configurations. The following table lists the required platform tuning configurations:

In OpenShift Container Platform 4.16 and later, clusters do not automatically revert to cgroups v1 when a PerformanceProfile CR is applied. If workloads running on the cluster require cgroups v1, you need to configure the cluster to use cgroups v1.

No reference design updates in this release

The CRI-O wipe disable MachineConfig assumes that images on disk are static other than during scheduled maintenance in defined maintenance windows. To ensure the images are static, do not set the pod imagePullPolicy field to Always.