Migrating your applications to OpenShift 4

If you’re looking for a path to upgrade your Red Hat OpenShift 3.7+ cluster to OpenShift 4.2, you’re in luck. The Migration Toolkit for Containers was built to migrate stateful and stateless applications from a source cluster to a destination cluster.

The initial intent of this tool is to address the OCP 3.7+ to OCP 4.2+ upgrade scenarios. That said, as requested by many Openshift users, it will also be possible to use this tool to migrate applications between OCP4 clusters.

This tool is based on two popular open source projects: Velero and Restic.

https://github.com/vmware-tanzu/velero

https://restic.net/

High-Level Architecture

Velero is installed on both your source and destination cluster, and object storage is used to store your backup information before getting restored on your target cluster. The OpenShift Container Platform Migration API orchestrates your migration from a central location. This API includes an easy to use user-interface and is usually installed on your target cluster by an operator.

Migrating Persistent Volumes

The migration of your PVs was a major focus for us in building this migration tool. Migration Toolkit for Containers 1.0 offers two different mechanisms to migrate your data: MOVE or COPY.

 1. Move the Persistent Volume

Moving PVs requires shared storage between your source and destination cluster (ex: NFS). This is the fastest option and offers minimal downtime as the data is not copied, but only re-attached to the destination cluster. 

 2. Copy the Persistent Volume

This is a two-step approach which can support all storage backends (default option). Your data is first copied on your replication repository and then restored on your target cluster. Your migration can be first "stage" to copy most of the data without any impact to your source cluster. Then, your can "migrate" which will only copy files that have been changed since your last staging, reducing the downtime significantly before the final cut-over.

The Migration Web UI

Your migrations can be fully executed from a simple web UI. The configuration steps are simple: 

•  Add both your source and destination clusters by providing your endpoint and credentials.
• Add an object storage repository by also providing the end point and your credentials.
• Finally, create a migration plan listing all of the projects (namespaces) that you would like to migrate.

Things to Know

 1. Cluster scoped resources

Cluster scoped resources are currently not migrated by this tool as they are not part of your namespace. Only resources inside your namespace are migrated. Our CPMA tool can help you find those resources and configure them to your new targeted cluster before executing your migration.

 2. Moving traffic to your new cluster

Once your migration is completed, your traffic must be redirected to your new cluster. The most common way to do this would be to either update your DNS entry or change your load balancer configuration. Using a load balancer in a multi-cluster configuration is a great way to reduce your downtime. If you are currently only using one cluster, this might be a good opportunity to look at the advantages of running a fully redundant cluster architecture.

 3. Cluster Admin Requirement

In Migration Toolkit for Containers 1.0, you will need cluster admin privileges to perform a migration. This is something we hope to improve in the near future to allow app owners to migrate their own applications without such privilege.

To get started, check out the documentation on the Cluster Application Migration Operator from the embedded OperatorHub in Red Hat OpenShift.