Streamlining Red Hat OpenStack Platform Upgrades
Here in this blog, we are going to learn the streamlining Red Hat Openstack Platform Upgrades.
Introduction
Upgrading an OpenStack environment can be a challenging and time-consuming operation for operators when speaking of large-scale deployments. In Red Hat OpenStack Platform 17.1, we included a mixed-mode RHEL upgrade to enhance users’ experiences and guarantee a smooth upgrading procedure.
This method tackles a problem that operators frequently run into: not having enough time to finish upgrades during the scheduled maintenance window. Operators can now effectively upgrade OpenStack content during the scheduled maintenance window while upgrading the OS at a later time thanks to the separation of the OpenStack environment upgrade from the OS upgrade.
We delve into the specifics of Red Hat’s strategy in this blog and emphasize the advantages it offers OpenStack operators.
Let’s examine the new upgrade procedure using the following example:
The following elements are included in the example below:
- a director node for the Red Hat OpenStack Platform running RHEL 8.4 and version 16.2
- 3 controller nodes for the Red Hat OpenStack Platform running RHEL 8.4 and version 16.2
- 3 compute nodes for the Red Hat OpenStack Platform running RHEL 8.4 and version 16.2
- 3 Ceph storage nodes running RHEL 8 and Red Hat Ceph Storage 4
The initial step is to update everything on the Red Hat OpenStack Platform to version 17.1. The first node to be upgraded is always the Red Hat OpenStack Platform director:
The following phase involves upgrading Ceph storage nodes from Red Hat Ceph Storage 4 to Red Hat Ceph Storage 5:
All Overcloud nodes, including Red Hat OpenStack Platform controllers and computes, will then receive an upgrade to Red Hat OpenStack Platform version 17.1.
Access to public-facing APIs should be restricted as we switch between three releases of OpenStack since requests might not succeed:
The complete Red Hat OpenStack Platform cluster will be running version 17.1 after this step.
It’s time to concentrate on RHEL 9 system upgrades for all of our systems.
The Red Hat OpenStack Platform director, like in the prior procedure, is the first node to be upgraded to RHEL 9.2. Leapp is used by the undercloud upgrading procedure to update RHEL from version 8.4 to version 9.2. The node must then be restarted:
The following upgrade targets are Red Hat OpenStack Platform controllers, with each controller’s upgrade and reboot being orchestrated in serial by the OpenStack overcloud process:
Similar to Red Hat OpenStack Platform controller nodes, upgrading RHEL in Ceph storage nodes involves:
Finally, an operator could agree to live migrate the virtual machine handling the workloads to another Red Hat OpenStack Platform compute node when upgrading Red Hat OpenStack Platform compute nodes. To avoid a workload outage when the RHEL system is rebooted, VM1 operating on Red Hat OpenStack Platform Compute 1 is live transferred to the Red Hat OpenStack Platform Compute 2 node in the example below.
It is now secure to carry out the OpenStack overcloud upgrading process as depicted in the following diagram because Red Hat OpenStack Platform Compute 1 is not currently hosting any workloads:
The workload can now be live transferred from Red Hat OpenStack Platform Compute 2 to the original Red Hat OpenStack Platform Compute 1 as the Red Hat OpenStack Platform Compute 1 upgrade is now finished:
The Red Hat OpenStack Platform compute node in the example below was upgraded alone, but the OpenStack upgrade procedure also permits upgrading Red Hat OpenStack Platform compute nodes in groups.
As shown in the diagram below, where the Red Hat OpenStack Platform Compute node 2 RHEL system upgrade has been deferred to a later stage, we can run Red Hat OpenStack Platform 17.1 compute nodes on RHEL 8.4 and RHEL 9.2 concurrently thanks to the multi-version support for RHEL introduced in Red Hat OpenStack Platform 17.1.
Conclusion
The time constraints that operators frequently experience during maintenance windows are addressed by decoupling the Red Hat OpenStack Platform environment update from the operating system upgrade. With this innovative method, administrators can postpone the OS upgrade till a more suitable time while finishing up OpenStack content upgrades during the planned window.
Our method helps operators to raise the stability and dependability of their OpenStack settings through enhanced time management, less downtime, and increased operational efficiency. With this innovative solution, you can upgrade your Red Hat OpenStack Platform infrastructure with confidence and realize the full potential of your cloud.
