Chapter 1. Red Hat OpenStack Services on OpenShift overview
Red Hat OpenStack Services on OpenShift (RHOSO) provides the foundation to build a private or public Infrastructure-as-a-Service (IaaS) cloud on top of Red Hat Enterprise Linux. It is a scalable, potentially fault-tolerant platform for the development of cloud-enabled workloads. For more information about how to increase the resiliency of RHOSO, see Understanding the Taint/Toleration based pod eviction process.
The RHOSO control plane is hosted and managed as a workload on a Red Hat OpenShift Container Platform (RHOCP) cluster. The RHOSO data plane consists of external Red Hat Enterprise Linux (RHEL) nodes that host RHOSO workloads. The RHEL nodes are managed on the data plane with an automation execution environment. The data plane nodes can be Compute nodes, Storage nodes, Networker nodes, or other types of nodes.
The RHOSO IaaS cloud is implemented by a collection of interacting services that control its computing, storage, and networking resources. You can manage the cloud with a web-based interface to control, provision, and automate RHOSO resources. Additionally, an extensive API controls the RHOSO infrastructure and this API is also available to end users of the cloud.
RHOSO only supports RHOCP master and worker nodes with processors based on a 64-bit x86 hardware architecture.
1.1. RHOSO service Operators Copy linkLink copied to clipboard!
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.
You use the Red Hat OpenShift Container Platform (RHOCP) OperatorHub to obtain and create the OpenStack Operator.
The OpenStack Operator (openstack-operator
) installs and deploys all the service Operators detailed in the Service Operators table, and is the interface that you use to manage those Operators. For more information about the functionality of each service, see the service-specific documentation on the Red Hat OpenStack Services on OpenShift 18.0 documentation portal.
For information about mapping RHOSO versions to OpenStack Operators and OpenStackVersion Custom Resources (CRs), see the Red Hat knowledge base article at https://access.redhat.com/articles/7125383.
Service | Operator | Default | Description |
---|---|---|---|
Bare Metal Provisioning (ironic) |
| Disabled | Supports physical machines for a variety of hardware vendors with hardware-specific drivers. Bare Metal Provisioning integrates with the Compute service to provision physical machines in the same way that virtual machines are provisioned, and provides a solution for the bare-metal-to-trusted-project use case. |
| Enabled | Used by the OpenStack Operator during the bare-metal node provisioning process. | |
Block Storage (cinder) |
| Enabled | Provides and manages persistent block storage volumes for virtual machine instances. |
Compute (nova) |
| Enabled |
Provides management of the provisioning of compute resources, such as Virtual Machines, through the |
Dashboard (horizon) |
| Disabled | Provides a browser-based GUI dashboard for creating and managing cloud resources and user access. The Dashboard service provides Project, Admin, and Settings dashboards by default. You can configure the dashboard to interface with other products such as billing, monitoring, and additional management tools. |
DNS (designate) |
| Disabled | Provides DNS as a service that manages DNS records, names, and zones in the cloud. The DNS service provides a REST API, and is integrated with the RHOSO Networking service (neutron) to automatically create records for virtual machine instances, network ports, and floating IPs. User management is available from integration with the Identity service (keystone). |
Identity (keystone) |
| Enabled | Provides user authentication in the cloud and authorizatin the cloud ion to all RHOSO services and for managing users, projects, and roles. Supports multiple authentication mechanisms, including username and password credentials, token-based systems, and AWS-style log-ins. |
Image (glance) |
| Enabled | Registry service for storing resources such as virtual machine images and volume snapshots. Cloud users can add new images or take a snapshot of an existing instance for immediate storage. You can use the snapshots for backup or as templates for new instances. |
Key Management (barbican) |
| Enabled | Provides secure storage, provisioning and management of secrets such as passwords, encryption keys, and X.509 Certificates. This includes keying material such as Symmetric Keys, Asymmetric Keys, Certificates, and raw binary data. |
Load balancing (octavia) |
| Disabled | Provides load balancing as a service for the cloud that supports multiple provider drivers. The reference provider driver is amphora, which is an open-source, scalable, and highly available load balancing provider. It accomplishes its delivery of load balancing services by managing a fleet of virtual machines, collectively known as amphorae, which it creates on demand. |
MariaDB |
| Enabled | Provides methods to deploy and manage MariaDB Galera clusters. |
Memcached |
| Enabled | Provides methods for managing infrastructure. |
Networking (neutron) |
| Enabled | Provides Networking-as-a-Service (NaaS) through software-defined networking (SDN) in virtual compute environments. Handles the creation and management of a virtual networking infrastructure in the cloud, which includes networks, subnets, and routers. |
Object Storage (swift) |
| Enabled | Provides efficient and durable storage of large amounts of data, including static entities such as videos, images, email messages, files, or instance images. Objects are stored as binaries on the underlying file system with metadata stored in the extended attributes of each file. |
OVN |
| Enabled | Provides methods to deploy and manage OVNs. |
Orchestration (heat) |
| Disabled | Template-based orchestration engine that supports automatic creation of resource stacks. Provides templates to create and manage cloud resources such as storage, networking, instances, or applications. You can use the templates to create stacks, which are collections of resources. |
Placement (placement) |
| Enabled | Provides methods to install and manage an OpenStack Placement installation. |
RabbitMQ |
| Enabled | Provides methods to deploy and manage RabbitMQ clusters. |
Shared File Systems (manila) |
| Disabled | Provisions shared file systems that can be used by multiple virtual machine instances, bare-metal nodes, or containers. |
Telemetry (ceilometer, prometheus) |
| Enabled | Provides user-level usage data for RHOSO clouds. You can use the data for customer billing, system monitoring, or alerts. Telemetry can collect data from notifications sent by existing RHOSO components such as Compute usage events, or by polling RHOSO infrastructure resources such as libvirt. |
1.2. Features of a RHOSO environment Copy linkLink copied to clipboard!
The basic architecture of a Red Hat OpenStack Services on OpenShift (RHOSO) environment includes the following features:
- Container-native application delivery
- RHOSO is delivered by using a container-native approach that spans the Red Hat OpenShift Container Platform (RHOCP) and RHEL platforms to deliver a container-native RHOSO deployment.
- RHOCP-hosted services
- RHOCP hosts infrastructure services and RHOSO controller services by using RHOCP Operators to provide lifecycle management.
- Ansible-managed RHEL-hosted services
- RHOSO workloads run on RHEL nodes that are managed by the OpenStack Operator. The OpenStack Operator runs Ansible jobs to configure the RHEL data plane nodes, such as the Compute nodes. RHOCP manages provisioning, DNS, and configuration management.
- Installer-provisioned infrastructure
- The RHOSO installer enables installer-provisioned infrastructure that uses RHOSO bare-metal machine management to provision the Compute nodes for the RHOSO cloud.
- User-provisioned infrastructure
- If you have your own machine ingest and provisioning workflow, you can use the RHOSO pre-provisioned model to add your pre-provisioned hardware into your RHOSO environment, while receiving the benefits of a container-native workflow.
- Hosted RHOSO client
-
RHOSO provides a host
openstackclient
pod that is preconfigured with administrator access to the deployed RHOSO environment.
1.3. RHOSO 18.0 known limitations Copy linkLink copied to clipboard!
The following list details the limitations of Red Hat OpenStack Services on OpenShift (RHOSO). Known limitations are features that are not supported in RHOSO.
Block Storage service (cinder):
- Cinder replication.
- LVM driver.
- NFS versions earlier than 4.
Compute service (nova):
- Off-path Network Backends are not supported in RHOSO 18.0. For more information, see Integration With Off-path Network Backends.
- Customizing policies are not supported. If you require custom policies, contact Red Hat for a support exception.
The following packages are not supported in RHOSO:
-
nova-serialproxy
-
nova-spicehtml5proxy
-
-
File injection of personality files to inject user data into virtual machine instances. As a workaround, users can pass data to their instances by using the
--user-data
option to run a script during instance boot, or set instance metadata by using the--property
option when launching an instance. For more information, see Creating a customized instance. - Persistent memory for instances (vPMEM). You can create persistent memory namespaces only on Compute nodes that have NVDIMM hardware. Red Hat has removed support for persistent memory from RHOSP 17.0 and later in response to the announcement by the Intel Corporation on July 28, 2022 that they are discontinuing investment in their Intel® Optane™ business. For more information, see Intel® Optane™ Business Update: What Does This Mean for Warranty and Support.
- QEMU emulation of non-native architectures.
- LVM is not supported as an image back end.
-
The
ploop
image format is not supported. - NFS versions earlier than 4.
Image service (glance):
- RHOSO supports only one architecture, x86_64. There is no valid use case that requires this to be set for an RHOSO cloud, so all hosts will be x86_64.
- NFS versions earlier than 4.
Shared File Systems service (manila):
- NFS versions earlier than 4.1 for CephFS-NFS back ends. Linux clients must use NFSv4.1 or later. NFSv3 is available for clients that do not yet support NFSv4.1, such as Microsoft Windows, but recovery is not expected for NFSv3 clients when a CephFS-NFS service fails over. Simultaneous access from Windows and Linux clients is not supported.
1.4. Supported topologies for a RHOSO environment Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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