Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
Chapter 1. Introduction
This document provides a workflow to help upgrade your Red Hat OpenStack Platform environment to the latest long life version.
1.1. Before you begin
Note the following:
- If you originally deployed your Red Hat OpenStack Platform environment with version 7 or 8, be aware that there is an issue with an older version of the XFS file system that might cause problems with your upgrade path and deployment of containerized services. For more information about the issue and how to resolve it, see the article "XFS ftype=0 prevents upgrading to a version of OpenStack Director with containers".
- If your deployment includes Red Hat Ceph Storage (RHCS) nodes, the number of placement groups (PGs) for each Ceph object storage daemon (OSD) must not exceed 250 by default. Upgrading Ceph nodes with more PGs per OSD results in a warning state and might fail the upgrade process. You can increase the number of PGs per OSD before you start the upgrade process. For more information about diagnosing and troubleshooting this issue, see the article OpenStack FFU from 10 to 13 times out because Ceph PGs allocated in one or more OSDs is higher than 250.
-
Locate all ports where
prevent_arp_spoofingis set to False. Ensure that for those ports that port security is disabled. As part of the upgrade theprevent_arp_spoofingoption is removed, and that capability is controlled by port security. - Apply any firmware updates to your hardware before performing the upgrade.
- If you manually changed your deployed overcloud, including the application password, you must update the director deployment templates with these changes to avoid a failed upgrade. If you have questions, contact Red Hat Technical Support.
1.2. Fast forward upgrades
Red Hat OpenStack Platform provides a fast forward upgrade feature. This feature provides an upgrade path through multiple versions of the overcloud. The goal is to provide users an opportunity to remain on certain OpenStack versions that are considered long life versions and upgrade when the next long life version is available.
This guide provides a fast forward upgrade path through the following versions:
| Old Version | New Version |
|---|---|
| Red Hat OpenStack Platform 10 | Red Hat OpenStack Platform 13 |
1.3. High level workflow
The following table provides an outline of the steps required for the fast forward upgrade process, and estimates for the duration and impact of each of the upgrade process steps.
The durations in this table are minimal estimates based on internal testing and might not apply to all productions environments. To accurately gauge the upgrade duration for each task, perform these procedures in a test environment with hardware similar to your production environment.
Table 1.1. Fast forward upgrade process steps outline and impact
| Step | Description | Duration |
|---|---|---|
| Preparing your environment | Perform a backup of the databases and configuration for the undercloud node and overcloud Controller nodes. Update to the latest minor release and reboot. Validate the environment. | The duration for this step might vary depending on the size of your deployment. |
| Upgrading the undercloud | Upgrade to each sequential version of the undercloud from OpenStack Platform 10 to OpenStack Platform 13. | The estimated duration for upgrading the undercloud is approximately 60 mins, with undercloud downtime during the upgrade. The overcloud remains functional during the undercloud upgrade step. |
| Obtaining container images | Create an environment file containing the locations of container images for various OpenStack services. | The estimated duration for configuring the container image source is approximately 10 mins. |
| Preparing the overcloud | Perform relevant steps to transition your overcloud configuration files to OpenStack Platform 13. | The estimated duration for preparing the overcloud for upgrade is approximately 20 mins. |
| Performing the fast forward upgrade | Upgrade the overcloud plan with the latest set of OpenStack Platform director templates. Run package and database upgrades through each sequential version so that the database schema is ready for the upgrade to OpenStack Platform 13. | The estimated duration for the overcloud upgrade run is approximately 30 mins, with overcloud service downtime during the upgrade. You cannot perform OpenStack operations during the outage. |
| Upgrading your Controller nodes | Upgrade all Controller nodes simultaneously to OpenStack Platform 13. | The estimated duration for the Controller nodes upgrade is approximately 50 mins. You can expect short overcloud service downtime during the Controller nodes upgrade. |
| Upgrading your Compute nodes | Test the upgrade on selected Compute nodes. If the test succeeds, upgrade all Compute nodes. | The estimated duration for the Compute nodes upgrade is approximately 25 mins per node. There is no expected downtime to workloads during the Compute nodes upgrade. |
| Upgrading your Ceph Storage nodes | Upgrade all Ceph Storage nodes. This includes an upgrade to the containerized version of Red Hat Ceph Storage 3. | The estimated duration for the Ceph Storage nodes upgrade is approximately 25 mins per node. There is no expected downtime during the Ceph Storage nodes upgrade. |
| Finalize the upgrade | Run the convergence command to refresh your overcloud stack. | The estimated duration for the overcloud converge run is at least 1 hour, however, it can take longer depending on your environment. |
1.4. Checking Ceph cluster status before an upgrade
Before you upgrade your environment, you must verify that the Ceph cluster is active and functioning as expected.
Procedure
-
Log in to the node that is running the
ceph-monservice. This node is usually a Controller node or a standalone Ceph Monitor node. View the status of the Ceph cluster:
$ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"
-
Confirm that the health status of the cluster is
HEALTH_OKand that all of the Object Storage Daemons (OSD) are active.
