Overview of Upgrading to Red Hat Enterprise Linux OpenStack Platform 5
Updated -
1. Overview
This document provides an overview of the process for upgrading to Red Hat Enterprise Linux OpenStack Platform 5 from Red Hat Enterprise Linux OpenStack Platform 4.
Red Hat only supports upgrades to Red Hat Enterprise Linux OpenStack Platform 5 on Red Hat Enterprise Linux 6.5. In addition, Red Hat recommends three different methods to support this upgrade path, each of which are described better in Section 3, “Upgrade Methods Comparison”. Each of these methods have corresponding documentation, all of which follow the architectural naming convention laid out in Section 2, “Architecture”.
Alternatively, you can also perform a parallel cloud migration, as described briefly in Section 4, “Parallel Cloud Migration”. While this is not technically an upgrade procedure, it may be worth considering if any of the recommended upgrade methods are too invasive or unfit for a production environment.
2. Architecture
The following diagram provides a high-level overview of the OpenStack architecture.
Each OpenStack service has a code name, which is reflected in the names of configuration files and command-line utility programs. For example, the Identity service has a configuration file called
keystone.conf
.
Table 1. Services
Service | Code Name | Description | |
---|---|---|---|
![]() |
Dashboard | Horizon |
A web-based dashboard for managing OpenStack services.
|
![]() |
Identity | Keystone | A centralized Identity service that provides authentication and authorization for other services, and manages users, tenants, and roles. |
![]() |
OpenStack Networking | Neutron | A networking service that provides connectivity between the interfaces of other OpenStack services. |
![]() |
Block Storage | Cinder | A service that manages persistent block storage volumes for virtual machines. |
![]() |
Compute | Nova | A service that manages and provisions virtual machines running on hypervisor nodes. |
![]() |
Image | Glance | A registry service for storing resources such as virtual machine images and Cinder snapshots. |
![]() |
Object Storage | Swift | A service providing object storage which allows users to store and retrieve files (arbitrary data). |
![]() |
Telemetry
|
Ceilometer | A service providing measurements of cloud resources. |
![]() |
Orchestration
|
Heat | A service providing a template-based orchestration engine, which supports the automatic creation of resource stacks. |
Each OpenStack service is comprised of a collection of Linux services, MariaDB databases, or other components, which together provide a functional group. For example, the glance-api
and glance-registry
Linux services, together with a MariaDB database, implement the Image service.
3. Upgrade Methods Comparison
Red Hat recommends three methods for upgrading to Red Hat Enterprise Linux OpenStack Platform 5. The following table provides a brief description of each.
Table 2. Upgrade Methods
Method | Description | Pros | Cons |
---|---|---|---|
All at Once |
In this method, you take down all of the OpenStack services at the same time, do the upgrade, then bring all services back up after the upgrade process is complete.
For more information, see https://access.redhat.com/articles/1168953.
|
This upgrade process is simple. Because everything is down, no orchestration is required. Although services will be down, VM workloads can be kept running if there are no requirements to move from one version of Red Hat Enterprise Linux to another (that is, from v6.4 to v6.5).
|
All of your services will be unavailable at the same time. In a large environment, the upgrade can result in a potentially extensive downtime while you wait for database-schema upgrades to complete. Downtime can be mitigated by proper dry-runs of your upgrade procedure on a test environment as well as scheduling a specific downtime window for the upgrade.
|
Service by Service |
This method allows you to upgrade one service at a time.
For more information, see https://access.redhat.com/articles/1168993.
|
Rather than a single large service outage, this method allows you to stage outages to specific services. For example, you can run the Identity service at the Red Hat Enterprise Linux OpenStack Platform 5 release while Compute runs at the older release.
You can schedule potentially longer upgrades (such as the Compute service upgrade in a large environment) separately from upgrades that take less time.
|
You will still have an interruption to your Nova APIs and Compute nodes.
|
Service by Service with Live Compute Upgrade |
This method is a variation of the service-by-service upgrade, with a change in how the Compute service is upgraded. With this method, you can take advantage of Red Hat Enterprise Linux OpenStack Platform 5 features that allow to run olders compute nodes in parallel with upgraded compute nodes.
For more information, see https://access.redhat.com/articles/1169003.
|
This method minimizes interruptions to your Compute service, with only a few minutes for the smaller services, and a longer migration interval for the workloads moving to newly-upgraded Compute hosts. Existing workloads can run indefinitely, and you do not need to wait for a database migration.
|
Additional hardware resources may be required to bring up the Red Hat Enterprise Linux OpenStack Platform 5 Compute nodes.
|
For all methods:
-
Ensure you have subscribed to the correct channels for this release on all hosts.
-
The upgrade will involve some service interruptions.
-
Running instances will not be affected by the upgrade process unless you either reboot a Compute node or explicitly shut down an instance.
-
To upgrade OpenStack Networking, you will need to set the correct
libvirt_vif_driver
in/etc/nova/nova.conf
as the old hybrid driver is now deprecated. To do so, run the following on your Compute API host:#
openstack-config --set /etc/nova/nova.conf \
DEFAULT libvirt_vif_driver nova.virt.libvirt.vif.LibvirtGenericVIFDriver
Warning
Red Hat does not support:
-
Upgrading any Beta release of Red Hat Enterprise Linux OpenStack Platform to any supported release (for example, 3 or 4).
-
Upgrading Compute Networking (nova-networking) to OpenStack Networking (neutron) in Red Hat Enterprise Linux OpenStack Platform 5. The only supported networking upgrade is between versions of OpenStack Networking (neutron) from Red Hat Enterprise Linux OpenStack Platform version 4 to version 5 .
4. Parallel Cloud Migration
As an alternative to upgrading, you can also deploy a completely separate Red Hat Enterprise Linux OpenStack Platform 5 environment, and slowly migrate resources over from the old environment to the new one. This might be excessive for a lot of users, but it is something that may be considered as the least-intrusive alternative to the other options.
Because this method is based on a new installation, no upgrade instructions are included. For installation procedures, refer to the Deploying OpenStack: Learning Environments (Manual Set Up) (manual installation for instructional purposes), Deploying OpenStack: Proof-of-Concept Environments (PackStack) (PackStack procedures for an all-in-one installation), or Deploying OpenStack: Enterprise Environments (Red Hat Enterprise Linux OpenStack Platform Installer) guides. These guides are available from:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/
Comments