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.
What is OpenStack
OpenStack is a cloud operating system that controls large pools of computing, storage, and networking resources throughout a data center, 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 the high availability of user applications.
The core of OpenStack is managing a cluster of compute servers that 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 infrastructure-as-a-service (IaaS) functionality for managing applications as virtual machines (VMs) and also higher-level abstractions such as load balancers 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 in 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 that 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 that are certified for Red Hat OpenStack.
Beyond that, Red Hat is committed 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 a hypervisor, a host operating system, and infrastructure to manage the deployment and high availability of OpenStack services themselves, such as a clustering middleware.
To provide a complete private cloud platform, Red Hat OpenStack on OpenShift includes the following fully supported components:
-
The Red Hat Enterprise Linux (RHEL) operating system.
-
The KVM hypervisor with the QEMU emulation layer and the libvirt management API, are all included with RHEL.
-
The Red Hat OpenShift application platform and its container-optimized operating system Red Hat Enterprise Linux CoreOS (RHCOS).
-
The Open Virtual Network (OVN) software-defined network layer.
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-defined networking layers. But you would be responsible for integrating, patching, and addressing 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 augment 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:
-
A control plane that runs the user-facing and internal infrastructure services of OpenStack.
-
A data plane that runs the application workloads as VMs.
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, the 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 run 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 managing a subset of the data plane.
With previous releases of Red Hat OpenStack, you could use different approaches to deploy and scale 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 a 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 comparison 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. 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 Virtualization or OpenShift Sandboxed Containers.
On the other side, organizations that 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.
In 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 the 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 the 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.