What is Red Hat OpenStack Services on OpenShift

Estimated reading time: 10 minutes.

Objective

Describe the Red Hat OpenStack product and how it relates to the OpenStack open source project.

Pending review.

What is OpenStack

OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed and provisioned through APIs with common authentication mechanisms.

Beyond standard infrastructure-as-a-service functionality, additional components provide orchestration, fault management and service management amongst other services to ensure high availability of user applications.

The core of OpenStack is managing a cluster of compute servers which run applications packaged as virtual machines. Beyond traditional hypervisors, OpenStack provides standard APIs to manage virtual storage and virtual networking with features comparable to a physical data center infrastructure.

The OpenStack community provides a number of user-facing services. Some of them provide the essential infrastructucture-as-a-service (IaaS) functionality for managing applications as virtual machines (VMs) and also higher-level abstractions such as load balancer and autoscalers. It also provides a number of internal infrastructure services, such as different ways of installing, managing, and scaling the OpenStack user-facing services.

Red Hat OpenStack Services on OpenShift is an opinionated distribution of OpenStack, built and supported by Red Hat. It is the latest incarnation of the Red Hat OpenStack Platform and marks a major shift on the internal architecture of Red Hat OpenStack.

Red Hat® OpenStack® Platform is a cloud computing platform that virtualizes resources from industry-standard hardware, organizes those resources into clouds, and manages them so that users can access what they need—when they need it.

That is, Red Hat OpenStack Services on OpenShift is a platform for building and managing private clouds which runs application workloads as VMs.

Let’s be honest: not all components available in the upstream OpenStack project are available with Red Hat OpenStack Services on OpenShift. Not all services and deployment methods from the community are supported by Red Hat as part of its OpenStack product. But "less is more" because Red Hat provides a stable, pre-integrated, secure, and certified set of components. Red Hat also works with a large ecosystem of partners that provide software and hardware which are certified for Red Hat OpenStack.

Beyond that, Red Hat is commited to fixing bugs and addressing security vulnerabilities, while keeping backward compatibility within a product release stream, which you cannot expect from upstream OpenStack.

On the other side, OpenStack alone is not sufficient to create a private cloud: you have to include and integrate additional components such as an hypervisor, a host operating system, and infrastructure to manage the deployment and high-availability of OpenStack services themselves, such as a clustering middleware.

s1 rhoso lecture fig 1

To provide a complete private cloud platform, Red Hat OpenStack on OpenShift includes the following fully supported components:

s1 rhoso lecture fig 2

You could install community OpenStack on any Linux operating system distribution and use different hypervisors. You could use operating-system tools such as pacemaker and podman to manage OpenStack services themselves, and choose different software-defiend networking layers. But you would be responsible for integrating, patching, and adressing any compatibility issues between those components and OpenStack services. By using Red Hat OpenStack Services on OpenShift, you offload all that work to Red Hat.

The final component of an OpenStack private cloud is storage. There are a number of certified storage products for OpenStack and Red Hat offers Red Hat Ceph Storage as a reliable, scalable, and high-performance software-defined storage product.

Red Hat Ceph Storage can provide storage services using standard server hardware or it can augument the capabilities of existing storage arrays. A single Red Hat Ceph cluster can provide file, block, and object storage services for multiple Red Hat OpenStack and Red Hat OpenShift clusters.

Structure of an OpenStack Cluster

An OpenStack cluster is composed of two parts:

  1. A control plane which runs the user-facing and internal infrastructure services of OpenStack.

  2. A data plane which runs the application workloads as VMs.

s1 rhoso lecture fig 3

You add compute power to an OpenStack cluster by adding physical servers, running RHEL, as compute nodes to the data plane. The more compute nodes, more application VMs your cluster can host.

To ensure the performance and reliability of the control plane, and by extension the performance and reliability of the whole cluster, you reserve three or more physical servers to running only OpenStack services. A large OpenStack cluster may require more servers dedicated to the control plane and can partition the control plane into multiple cells, each dedicated to manage a subset of the data plane.

With previous releases of Red Hat OpenStack, you could use different approaches to deploy and scale the the control plane, such as clustered RHEL servers with pacemaker, a Red Hat Virtualization hypervisor cluster, or an OpenStack cluster known as the undercloud, using what was known as the OpenStack on OpenStack architecture or TripleO. None of these options is available with the current Red Hat OpenStack Services on OpenShift product: you must run an OpenStack the control plane as containers on an Red Hat OpenShift cluster.

Microservices developers realized a while ago that containers and Kubernetes are the best way to manage applications composed of multiple services. Even developers targeting public clouds, such as AWS and Azure, nowadays prefer running Kubernetes on those clouds. OpenStack is such a kind of application, and it just makes sense to use Red Hat OpenShift, which is an enterprise application platform based on Kubernetes, to manage all services of an OpenStack control plane.

Other Ways of Running VMs with OpenShift

If OpenStack is essentially a way of running and managing application workloads as VMs, and Red Hat OpenStack runs on OpenShift, why not run and manage application workloads as VMs directly on OpenShift, using OpenShift Virtualization or OpenShift Sandboxed Containers? The following table provides a quick comparision between the three technologies currently available for managing application VMs using OpenShift:

Product / Feature OpenShift Virtualization OpenShift Sandboxed Containers OpenStack Services on OpenShift

Hypervisor technology

KVM + QEMU + libvirt

KVM + QEMU + libvirt

KVM + QEMU + libvirt

Application packaging

VM image (qcow2)

Container image (OCI)

VM image (qcow2)

Application VM management APIs

Kubervirt APIs + Kubernetes APIs

Kubernetes APIs

OpenStack APIs

Compute nodes

RH CoreOS (OpenShift)

RH CoreOS (OpenShift)

RHEL (OpenStack)

Block and File Storage

Kubernetes PVCs

Kubernetes PVCs

OpenStack Cinder and Manila

Virtual Networking

Kuberentes pod/service network + Multus secondary networks

Kuberentes pod/service network + Multus secondary networks

OpenStack Neutron tenant and provider networks, routers, etc

The main difference between these three technologies is where your VMs run: inside OpenShift, using compute nodes from the OpenShift cluster; or outside of OpenShift, using RHEL servers as compute nodes. And the consequence of running VMs inside OpenShift is requiring those VMs to use Kubernetes storage and networking capabilities, which are currently not as rich as OpenStack.

If you have existing development and operational processes based on OpenStack APIs, switching that to Kubernetes APIs is a major change. That change would be required to use either OpenShift Virtualizaiton or OpenShift Sandboxed Containers.

On the other side, organizations which already have containerized applications want to adopt GitOps practices and use other capabilities enabled by Kubernetes. For them, switching from a traditional hypervisor to OpenShift Virtualization makes sense.

Red Hat OpenStack Services on OpenShift enables using Kubernetes-based tools for managing applications in OpenStack too: the same OpenShift cluster which runs an OpenStack control plane (or a different OpenShift cluster, if you prefer) can run OpenShift Pipelines, OpenShift GitOps, and other OpenShift applications which can manage OpenStack applications by invoking OpenStack APis. It’s the best of both the OpenStack and the Kubernetes worlds.

The same way OpenShift improves the management of OpenStack clusters, it can improve the management of other infrastructure to support your operations and development teams. For example, you can use OpenShift to run Ansible Automation Platform to manage the applications inside your OpenStack VMs and also your physical data center infrastructure which runs OpenShift, OpenStack and other platforms. All your IT infrastructure services could be managed by OpenShift, while retaining compatibility with application workloads and processes that are designed around OpenStack APIs and which require the richer OpenStack compute, storage, and network management APIs.

Of course, if an organization prefers running Ansible, Jenkins, Bugzilla, Zabbix, and other tools as VMs on OpenStack, it is indeed a good idea. Those organizations can also consider running OpenShift itself on OpenStack VMs for their containerized applications. This was already supported by earlier incarnations of Red Hat OpenStack Platform, and it is still supported with Red Hat OpenStack Services on OpenShift. Running OpenShift clusters as VMs on OpenShift Virtualization is also a valid design choice. A discussion about running OpenShift clusters on VMs or on physical machines is beyond the scope of this OpenStack course. As you see, there are multiple paths to modernize an IT infrastructure to support containers alongside VMs.