Overview of Upgrading to Red Hat Enterprise Linux OpenStack Platform 5
1. Overview
2. Architecture
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
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.
|
-
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_driverin/etc/nova/nova.confas 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
-
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
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/










