Chapter 3. Infrastructure and system requirements

• An operational, pre-provisioned 3-node bare metal RHOCP cluster, version 4.18.

  Note

  If you are using a multi-node RHOCP cluster with dedicated control plane and worker nodes, you must have 3 dedicated RHOCP control plane nodes and 3 dedicated worker nodes for high availability.

• Each worker node in the cluster must have the following resources:

  • 64 GB RAM
  • 16 CPU cores

  • 120GB NVMe or SSD for the root disk plus 250 GB storage (NVMe or SSD is strongly recommended)

    Note

    The images, volumes and root disks for the virtual machine instances running on the deployed environment are hosted on dedicated external storage nodes. However, the service logs, databases, and metadata are stored in a RHOCP Persistent Volume Claim (PVC). A minimum of 150 GB is required for testing.

  • 2 physical NICs for basic control

    Note

    In a 6-node cluster with 3 controllers and 3 workers, only the worker nodes require 2 physical NICs.

  • (Optional) Additional dedicated NICs for OVN external gateways on the control plane. These are required if you plan to place OVN gateways on the control plane.
  • The RHEL system timezone and the date and time of the system firmware (UEFI/BIOS) clock for each cluster node must be UTC.
• Each control plane node in the cluster must have the resources specified in Minimum resource requirements for cluster installation in the RHOCP Installing on any platform guide.

• Persistent Volume Claim (PVC) storage on the cluster:

  • 150 GB persistent volume (PV) pool for service logs, databases, file import conversion, and metadata.

    Note
    • You must plan the size of the PV pool that you require for your RHOSO pods based on your RHOSO workload. For example, the Image service image conversion PVC should be large enough to host the largest image and that image after it is converted, as well as any other concurrent conversions. You must make similar considerations for the storage requirements if your RHOSO deployment uses the Object Storage service (swift).
    • The PV pool is required for the Image service, however the actual images are stored on the Image service back end, such as Red Hat Ceph Storage or SAN.
  • 5 GB of the available PVs must be backed by local SSDs for control plane services such as the Galera, OVN, and RabbitMQ databases.

• If you are using virtual media boot to provision bare-metal data plane nodes and the nodes are not connected to a provisioning network or to the RHOCP machine network, you must configure a route for the Baseboard Management Controller (BMC) and the node to reach the RHOCP machine network. The machine network is the network used by RHOCP cluster nodes to communicate with each other.
• Synchronize all nodes in your RHOCP cluster with one or more Network Time Protocol (NTP) servers. Clock synchronization between RHOCP nodes and data plane nodes ensures accurate timing across your cloud environment for reliable services, workloads, and timestamps.

• The following ports must be open between cluster nodes:

  Expand

  Port	Description
  67,68	When using a provisioning network, cluster nodes access the dnsmasq DHCP server over their provisioning network interfaces using ports 67 and 68.
  69	When using a provisioning network, cluster nodes communicate with the TFTP server on port 69 using their provisioning network interfaces. The TFTP server runs on the bootstrap VM. The bootstrap VM runs on the provisioner node.
  80	When not using the image caching option or when using virtual media, the provisioner node must have port 80 open on the baremetal machine network interface to stream the Red Hat Enterprise Linux CoreOS (RHCOS) image from the provisioner node to the cluster nodes.
  123	The cluster nodes must access the NTP server on port 123 using the baremetal machine network.
  5050	The Ironic Inspector API runs on the control plane nodes and listens on port 5050. The Inspector API is responsible for hardware introspection, which collects information about the hardware characteristics of the bare-metal nodes.
  5051	Port 5050 uses port 5051 as a proxy.
  6180	When deploying with virtual media and not using TLS, the provisioner node and the control plane nodes must have port 6180 open on the baremetal machine network interface so that the baseboard management controller (BMC) of the worker nodes can access the RHCOS image. Starting with OpenShift Container Platform 4.13, the default HTTP port is 6180.
  6183	When deploying with virtual media and using TLS, the provisioner node and the control plane nodes must have port 6183 open on the baremetal machine network interface so that the BMC of the worker nodes can access the RHCOS image.
  6190-6220	The OpenStackProvisionServer custom resource (CR) is required to install RHEL. If there is a firewall between your RHOCP machine network and the RHOSO control plane, you must open ports 6190-6220. The OpenStackProvisionServer CR is automatically created by default during the installation and deployment of your Red Hat OpenStack on OpenShift (RHOSO) environment and it uses the port range 6190-6220. You can create a custom OpenStackProvisionServer CR to limit the ports that are opened.
  6385	The Ironic API server runs initially on the bootstrap VM and later on the control plane nodes and listens on port 6385. The Ironic API allows clients to interact with Ironic for bare-metal node provisioning and management, including operations such as enrolling new nodes, managing their power state, deploying images, and cleaning the hardware.
  6388	Port 6385 uses port 6388 as a proxy.
  8080	When using image caching without TLS, port 8080 must be open on the provisioner node and accessible by the BMC interfaces of the cluster nodes.
  8083	When using the image caching option with TLS, port 8083 must be open on the provisioner node and accessible by the BMC interfaces of the cluster nodes.
  9999	By default, the Ironic Python Agent (IPA) listens on TCP port 9999 for API calls from the Ironic conductor service. Communication between the bare-metal node where IPA is running and the Ironic conductor service uses this port.

  Show more

• Some network architectures may require the following networking capabilities:

  • A dedicated NIC on RHOCP worker nodes for RHOSO isolated networks.
  • Port switches with VLANs for the required isolated networks.

  Consult with your RHOCP and network administrators about whether these are requirements in your deployment. For information on the required isolated networks, see Default Red Hat OpenStack Platform networks in the Deploying Red Hat OpenStack Services on OpenShift guide.

• The RHOCP environment supports Multus CNI.

• The following Operators are installed on the RHOCP cluster:

  • The Kubernetes NMState Operator. This Operator must be started by creating an nmstate instance. For information, see Installing the Kubernetes NMState Operator in the RHOCP Networking guide.

  • The MetalLB Operator. This Operator must be started by creating a metallb instance. For information, see Starting MetalLB on your cluster in the RHOCP Networking guide.

    Note

    When you start MetalLB with the MetalLB Operator, the Operator starts an instance of a speaker pod on each node in the cluster. When using an extended architecture such as 3 RHOCP masters and 3 RHOCP workers, if your RHOCP masters do not have access to the ctlplane and internalapi networks, you must limit the speaker pods to the RHOCP worker nodes. For more information about speaker pods, see Limit speaker pods to specific nodes.

  • The cert-manager Operator. For information, see cert-manager Operator for Red Hat OpenShift in the RHOCP Security and compliance guide.
  • The Cluster Observability Operator. For information, see Installing the Cluster Observability Operator.
• The Cluster Baremetal Operator (CBO) is configured for provisioning. The CBO deploys the Bare Metal Operator (BMO) component, which is required to provision bare-metal nodes as part of the data plane deployment process. For more information on planning for bare-metal provisioning, see Planning provisioning for bare-metal data plane nodes.

• The following tools are installed on the cluster workstation:

  • The oc command line tool.
  • The podman command line tool.
• The RHOCP storage back end is configured.

• The RHOCP storage class is defined, and has access to persistent volumes of type ReadWriteOnce.

  Note

  If you use Logical Volume Manager (LVM) storage, which only provides local volumes, in the event of a node failure the attached volume is not mounted on a new node because it is already assigned to the failed node. This prevents the SNR Operator from automatically rescheduling pods with LVMS PVCs. Therefore, if you use LVMs for storage, you must detach volumes after non-graceful node shutdown. For more information, see Detach volumes after non-graceful node shutdown.

Additional resources

• Configuring the install-config.yaml file
• Network configuration parameters
• Storage
• Post-installation storage configuration
• Installing the MetalLB Operator
• Kubernetes NMState