An OpenStack cloud upgrade can be a challenging task for administrators as they manage numerous considerations:
- How do I upgrade each service’s components while mitigating user impact?
- Can I skip one or more OpenStack releases during my upgrade, or must I upgrade to every single release between my current implementation and the latest community release?
- Which control plane services are implemented in the OpenStack deployment and need to be upgraded?
- How does each OpenStack service’s high availability configuration alter my upgrade process?
- What is my change control window and will any required service outages remain within required service level agreements (SLA)?
At each OpenStack Summit, there are multiple sessions that discuss these topics, and the Austin Summit was no exception with VMware participating in an upgrade experts’ panel.
The following video contains a replay of the OpenStack Expert Panel that we participated in:
Improved Upgrade Experience with VMware Integrated OpenStack
Fortunately, VIO customers have an automated upgrade process that benefits from the following unique aspects of our architecture:
- The OpenStack control plane is 100% decoupled from the underlying infrastructure. See Figure 1.
- The OpenStack control plane is upgraded with a “blue-green” strategy. See Figure 2.
- Each OpenStack community release is evaluated to determine which one is included in our distribution. If we happen to skip a release (ex: VIO 1.0 was Icehouse, and VIO 2.0 was Kilo) we have an automated upgrade process to handle the complexity of moving to the newer release.
OpenStack Control Plane Decoupled from the Infrastructure
The OpenStack control plane services run within virtual machines instead of running bare metal on the hypervisor hosts. This implementation methodology allows us to independently upgrade the OpenStack services and infrastructure services. For example, it is possible to upgrade VMware vSphere versions without the OpenStack cloud services being affected, and it is possible to upgrade the OpenStack cloud services without affecting existing workloads.
OpenStack Blue-Green Upgrade
We have discussed our upgrade process in-depth here and here. However, to quickly recap, we migrate to a newer OpenStack release by deploying an updated control plane in parallel to your existing cloud. When the updated control plane is ready, we migrate the OpenStack databases from the existing cloud to new cloud control plane.
The original cloud is powered down, and the only user impact is that new workloads cannot be provisioned during the database migration. Otherwise, existing workloads continue to run seamlessly. Administrators are free to retain the original control plane if there is a desire to rollback to the previous release.
This represents a significant time savings for OpenStack upgrades from industry-reported time periods (i.e. weeks) down to hours or even less.