The OpenStack data plane includes the servers that host end-user data applications. More specifically, these hosts include compute, storage, and gateway nodes. Depending on the update requirements, you can apply any kind of the update depths while updating the data plane.
To update the data plane of your OpenStack deployment:
Update the gateway nodes depending on your use case:
Caution
Skip this step if your MCP OpenStack deployment includes the OpenContrail component because such configuration does not contain gateway nodes.
If non-HA routers are present in the cloud:
Migrate the non-HA routers from the target nodes using the Neutron service and the following commands in particular:
l3-agent-router-add
l3-agent-router-remove
router-list-on-l3-agent
Log in to the Jenkins web UI.
Run the Deploy - upgrade OVS gateway pipeline for the gateway nodes which you have migrated the workloads from.
Note
Run the pipeline in the interactive mode to get the detailed description of the pipeline flow through the stages.
Note
Since all resources have already been migrated from the
nodes, we recommend performing the full upgrade including
OS_UPGRADE
and OS_DIST_UPGRADE
.
Migrate the non-HA routers back and rerun the Deploy - upgrade OVS gateway pipeline for the rest of the gateway nodes.
If non-HA routers are not present in the cloud:
Log in to the Jenkins web UI.
Run the Deploy - upgrade OVS gateway pipeline for all gateway nodes specifying TARGET_SERVERS=’gtw*’.
Note
Run the pipeline in the interactive mode to get the detailed description of the pipeline flow through the stages.
Verify that the gateway components are reconnected to the control plane.
Caution
Skip this step if your MCP OpenStack deployment includes the OpenContrail component because such configuration does not contain gateway nodes.
Update the OpenStack compute nodes.
Estimate and minimize the risks and address the limitations of the live migration.
The limitations of the live migration technology include:
Warning
Before proceeding with the live migration in a production environment, assess these risks thoroughly.
The CPU of a source compute node must have a feature set that is a subset of a feature set of the target compute CPU. Therefore, the migration should be performed between the compute nodes with identical CPUs with, preferably, identical microcode versions.
During the live migration, the entire memory state of a VM must be
copied to another server. In the first place, the memory pages that
are being changed at a slower rate are copied. After, the system
copies the most active
memory pages. If the number of pages
that are being written to is big, the migration process will never
finish. High-memory, high-load Windows virtual machines are known to
have this particular issue.
During the live migration, a very short downtime (1-2 seconds max) occurs. The reason for the downtime is that when the memory is copied, the execution context (vCPU state) has to be copied as well, and the execution itself must be switched to a new virtual machine. In addition to a short downtime, this causes a short clock lag on the migrated virtual machine. Therefore, if the migrated machine is hosting a part of a clustered service or system, the downtime and resulting time lag may have an adverse impact on the whole system.
The QEMU version installed on the source and target hosts should be the same and later than 2.5.
Perform the live migration of workloads.
Log in to the Jenkins web UI.
Run the Deploy - upgrade computes pipeline to update the OpenStack compute nodes which you have migrated the workloads from. It is essential that you update the compute nodes by small batches.
Caution
The impact of the update process should be calculated for each compute node during the planning stage as this step may take a significant amount of time.
Note
Run the pipeline in the interactive mode to get the detailed description of the pipeline flow through the stages.
Migrate the workloads back and rerun the Deploy - upgrade computes pipeline for the rest of the compute nodes.
Verify that the compute nodes are reconnected to the control plane.
Proceed to Perform the post-update activities.