Planning your deployment

The Red Hat OpenStack Services on OpenShift (RHOSO) IaaS services are implemented as a collection of Operators running on a Red Hat OpenShift Container Platform (RHOCP) cluster. These Operators manage the compute, storage, networking, and other services for your RHOSO cloud.

The OpenStack Operator (openstack-operator) installs all the service Operators detailed in the Services table, and is the interface that you use to manage those Operators. The OpenStack Operator also installs and manages the following Operators:

For more information on the functionality of each service, see the service-specific documentation on the Red Hat OpenStack Services on OpenShift 18.0 documentation portal.

The basic architecture of a Red Hat OpenStack Services on OpenShift (RHOSO) environment includes the following features:

The following list details the limitations of Red Hat OpenStack Services on OpenShift (RHOSO). Known limitations are features that are not supported in RHOSO.

Compute service (nova):

Image service (glance):

Block Storage service (cinder):

If you require support for any of these features, contact the Red Hat Customer Experience and Engagement team to discuss a support exception, if applicable, or other options.

Red Hat OpenStack Services on OpenShift (RHOSO) supports a compact control plane topology and a dedicated nodes control plane topology.

In a compact topology, the RHOSO control plane and the Red Hat OpenShift Container Platform (RHOCP) control plane share the same physical nodes.

In a dedicated nodes topology, the RHOCP control plane runs on one set of physical nodes and the RHOSO control plane runs on another set of physical nodes.

1.4.1. Compact topology

The compact RHOSO topology is the default, and consists of the following components:

OpenShift compact cluster

A Red Hat OpenShift cluster that hosts both the RHOSO and the RHOCP control planes.

The RHOSO control plane consists of the OpenStack controller services pods that consist of services such as the Compute service (nova), the Networking service (neutron), and so on.

The OpenShift control plane hosts the pods that run the following services required for RHOCP: OpenShift services, Kubernetes services, networking components, Cluster Version Operator, and etcd.

For more information, see Introduction to OpenShift Container Platform in the RHOCP Architecture guide

RHOSO data plane

The RHOSO data plane consists of OpenStack Compute nodes. Nodes dedicated to storage are optional.

Figure 1.1. Compact RHOSO topology

1.4.2. Dedicated nodes topology

The dedicated nodes RHOSO topology differs from the compact topology in that there is a separate node cluster for the RHOSO control plane and a separate node cluster for the OpenShift control plane.

Figure 1.2. Dedicated nodes RHOSO topology

To create a RHOSO cloud with a RHOCP hosted control plane, you must complete the following tasks:

You perform the control plane installation tasks and all data plane creation tasks on a workstation that has access to the RHOCP cluster.

The OpenStack Operator includes a set of custom resource definitions (CRDs) that you can use to create and manage RHOSP resources.

The minimum requirements for the Red Hat OpenShift Container Platform (RHOCP) cluster that hosts your Red Hat OpenStack Services on OpenShift (RHOSO) control plane are as follows:

You can use pre-provisioned nodes or unprovisioned bare-metal nodes to create the data plane. The minimum requirements for data plane nodes are as follows:

Compute nodes are responsible for running virtual machine instances after they are launched. Compute nodes require bare metal systems that support hardware virtualization. Compute nodes must also have enough memory and disk space to support the requirements of the virtual machine instances that they host.

For more information about planning for Compute node memory configuration, see Configuring the Compute service for instance creation.

The method used to install the RHOCP cluster determines the availability of the Cluster Baremetal Operator (CBO) and the ability to create a provisioning network. A provisioning network is required for network booting.

Provisioning bare-metal nodes on the data plane is supported with the Red Hat OpenShift Container Platform (RHOCP) Cluster Baremetal Operator (CBO). The CBO deploys the components required to provision bare-metal nodes within the RHOCP cluster, including the Bare Metal Operator (BMO) and Ironic containers.

The BMO manages the available hosts on clusters and performs the following operations:

For more information about the Bare Metal Operator and how to configure a BareMetalHost CR, see Bare metal configuration in the RHOCP Postinstallation configuration guide.

The following physical data center networks are typically implemented for a Red Hat OpenStack Services on OpenShift (RHOSO) deployment:

For more information, see Default Red Hat OpenStack Services on OpenShift networks in the Deploying Red Hat OpenStack Services on OpenShift guide.

You must plan how your deployment hosts specific types of network traffic in isolation. This includes planning IP ranges, subnets, and virtual IPs, and configuring your NIC layout.

The Red Hat OpenStack Services on OpenShift (RHOSO) control plane services run as a Red Hat OpenShift Container Platform (RHOCP) workload. On the control plane, you use the NMState Operator to connect the worker nodes to the required isolated networks. You create a NetworkAttachmentDefinition (nad) custom resource (CR) for each isolated network to attach service pods to the isolated networks, where needed. You use the MetalLB Operator to expose internal service endpoints on the isolated networks. By default, the public service endpoints are exposed as RHOCP routes.

You must also create an L2Advertisement resource to define how the VIPs are announced, and an IpAddressPool resource to configure which IPs can be used as VIPs. In layer 2 mode, one node assumes the responsibility of advertising a service to the local network.

For more information, see Preparing RHOCP for RHOSO network isolation in the Deploying Red Hat OpenStack Services on OpenShift guide.

To create the data plane network, you define a NetConfig custom resource (CR) and specify all the subnets for the data plane networks. You must define at least one control plane network for your data plane. You can also define VLAN networks to create network isolation for composable networks, such as InternalAPI, Storage, and External. Each network definition must include the IP address assignment.

For more information, see Creating the data plane network in the Deploying Red Hat OpenStack Services on OpenShift guide.

A compact RHOSO deployment requires at least two NICs on each RHOSO control plane worker node.

One NIC on each worker node serves OpenShift. It provides connection between OpenShift components in the OpenShift cluster network.

The other NIC serves OpenStack. It connects the OpenStack services running on the worker nodes to the isolated networks on the RHOSO data plane.

For more information, see Storage networks in this guide.

Network functions virtualization (NFV) is a software-based solution that helps communication service providers (CSPs) to move beyond the traditional, proprietary hardware to achieve greater efficiency and agility and to reduce operational costs.

Using NFV in a Red Hat OpenStack Services on OpenShift (RHOSO) environment allows for IT and network convergence by providing a virtualized infrastructure that uses the standard virtualization technologies to virtualize network functions (VNFs) that run on hardware devices such as switches, routers, and storage. An NFV environment takes advantage of Data Plane Development Kit (DPDK) and Single Root I/O Virtualization (SR-IOV) technologies to improve packet processing speeds.

If you choose an NFV deployment, you must use Deploying a Network Functions Virtualization environment as your deployment guide instead of Deploying Red Hat OpenStack Services on OpenShift.

Before you install the Red Hat OpenStack Services on OpenShift (RHOSO) control plane, you must modify iscsi.conf to remove MD5 and SHA1. The iSCSId configuration for the control plane is not handled by RHOSO operators, so you must complete this step on the Red Hat OpenShift Container Platform (RHOCP) cluster.

You can check the FIPS status of RHOCP or deployed worker nodes.

For more information about installing Red Hat OpenShift Cluster Platform in FIPS mode, see Support for FIPS cryptography in the RHOCP Installing guide.

RHOSO supports the following storage and networking features:

RHOSO supports the following storage services.

To manage the consumption of system resources by projects, you can configure quotas for the Block Storage service (cinder) and the Shared File Systems service (manila). You can override the default quotas so that individual projects have different consumption limits.

RHOSO supports a number of storage technologies that can act separately or in combination to provide the storage solution for your deployment.

Two default storage-related networks are configured during the RHOSO installation: the Storage and Storage Management networks. These isolated networks follow best practices for network connectivity between storage components and the deployments.

The Storage network is used for data storage access and retrieval.

The Storage Management network is used by RHOSO services to have access to specific interfaces in the storage solution that allows access to the management consoles. For example, Red Hat Ceph Storage uses the Storage Management network in a hyperconverged infrastructure (HCI) environment as the cluster_network to replicate data.

The following table lists the properties of the default storage-related networks.

Your storage solution may require additional network configurations. These defaults provide a basis for building a full deployment.

All Block Storage services with back ends (cinder-volume and cinder-backup) require access to all the storage networks, which may not include the storage management network depending on the back end. Block Storage services with back ends require access only to their storage management network. In most deployments there’s a single management network, but if there are multiple storage management networks, each service-back end pair only needs access to their respective management network.

You must install host bus adapters (HBAs) on all OCP worker nodes in any deployment that uses the Block Storage service and a Fibre Channel (FC) back end.

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderVolumes:
        iscsi:
          networkAttachments:
          - storage
          - storageMgmt

In general, a clustered storage solution provides greater back end scalability and resiliency. For example, when you use Red Hat Ceph Storage as a Block Storage (cinder) back end, you can scale storage capacity and redundancy by adding more Ceph Object Storage Daemon (OSD) nodes. Block Storage, Object Storage (swift), and Shared File Systems Storage (manila) services support Red Hat Ceph Storage as a back end.

The Block Storage service can use multiple storage solutions as discrete back ends. At the service level, you can scale capacity by adding more back ends.

By default, the Object Storage service consumes space by allocating persistent volumes in the OpenShift underlying infrastructure. It can be configured to use a file system on dedicated storage nodes, and it can use as much space as is available. The Object Storage service supports the XFS and ext4 file systems, and you can scale both file systems to consume as much underlying block storage as is available. You can also scale capacity by adding more storage devices to the storage node.

The Shared File Systems service provisions file shares from designated storage pools that are managed by Red Hat Ceph Storage or other back-end storage systems. You can scale this shared storage by increasing the size or number of storage pools available to the service or by adding more back-end storage systems to the deployment. Each back-end storage system is integrated with a dedicated service to interact with and manage the storage system.

Volumes are consumed only through instances. Users can extend, create snapshots of volumes and use the snapshots to clone or restore a volume to a previous state.

You can use the Block Storage service (cinder) to create volume types, which aggregate volume settings. You can associate volume types with encryption and Quality of Service (QoS) specifications to provide different levels of performance for your cloud users. Your cloud users can specify the volume type they require when creating new volumes. For example, volumes that use higher performance QoS specifications could provide your users with more IOPS, or your users could assign lighter workloads to volumes that use lower performance QoS specifications to conserve resources. Shares can be consumed simultaneously by one or more instances, bare metal nodes or containers. The Shared File Systems service (manila) also supports share resize, snapshots and cloning, and administrators can create share types to aggregate settings.

Users can access objects in a container by using the Object Storage service (swift) API, and administrators can make objects accessible to instances and services in the cloud. This accessibility makes objects ideal as repositories for services; for example, you can store Image service (glance) images in containers that are managed by the Object Storage service.

The Block Storage service provides data security through the Key Manager service (barbican). The Block Storage service uses a one-to-one, key to volume mapping with the key managed by the Key Manager service. The encryption type is defined when configuring the volume type.

Security can also be improved at the backend level by encrypting control and/or data traffic, for example with Red Hat Ceph Storage, this can be achieved by enabling messengerv2 secure mode. This way, network traffic amongst Ceph services as well as from OpenStack compute nodes are encrypted.

You configure object and container security at the service and node level. The Object Storage service (swift) provides no native encryption for containers and objects. However, with the Key Manager service enabled, the Object Storage service can transparently encrypt and decrypt your stored (at-rest) objects. At-rest encryption is distinct from in-transit encryption in that it refers to the objects being encrypted while being stored on disk.

The Shared File Systems service (manila) can secure shares through access restriction, whether by instance IP, user or group, or TLS certificate. Some Shared File Systems service deployments can feature separate share servers to manage the relationship between share networks and shares. Some share servers support, or even require, additional network security. For example, a CIFS share server requires the deployment of an LDAP, Active Directory, or Kerberos authentication service.

Some backends also support encrypting the data AT REST. This enables extra security by encrypting the backend disks themselves, preventing physical security threats such as theft or unwiped recycled disks.

For more information about configuring security options for the Block Storage service, Object Storage service, and Shared File Systems service, see Configuring security services.

If you deploy the optional Block Storage backup service, then the Block Storage service (cinder) provides volume backup and restoration for basic disaster recovery of user storage. You can use backups to protect volume contents. The Block Storage service also supports snapshots. In addition to cloning, you can use snapshots to restore a volume to a previous state.

If your environment includes multiple back ends, you can also migrate volumes between these back ends. This is useful if you need to take a back end offline for maintenance. Backups are typically stored in a storage back end separate from their source volumes to help protect the data. This is not possible with snapshots because snapshots are dependent on their source volumes.

The Block Storage service also supports the creation of consistency groups to group volumes together for simultaneous snapshot creation. This provides a greater level of data consistency across multiple volumes.

The Object Storage service (swift) provides no built-in backup features. You must perform all backups at the file system or node level. However, the Object Storage service features robust redundancy and fault tolerance. Even the most basic deployment of the Object Storage service replicates objects multiple times. You can use failover features like device mapper multipathing (DM Multipath) to enhance redundancy.

The Shared File Systems service (manila) provides no built-in backup features for shares, but you can create snapshots for cloning and restoration.

You can manage your RHOSO configuration using the RHOSO Dashboard (horizon) or the RHOSO command line interface (CLI). You can perform most procedures using either method but some advanced procedures can only be completed using the CLI.

You can manage your storage solution configuration using the dedicated management interface provided by the storage vendor.

The Image and Object Storage services can be configured to allocate space in the Red Hat OpenShift backing storage. In this scenario, the Red Hat OpenShift storage sizing should be estimated based on the expected use of these services.

...
default:
  storage:
    external: true
...
...
extraMounts:
- extraVol:
  - extraVolType: NFS
    mounts:
    - mountPath: /var/lib/glance/os_glance_staging_store
      name: nfs
    volumes:
    - name: nfs
      nfs:
        path: <nfs_export_path>
        server: <nfs_ip_address>

...
default:
  replicas: 3
  storage:
    storageRequest: 10G
...