Asynchronous disaster recovery in OCP GCP

In asynchronous disaster recovery setup, you can replicate OCP applications and their data between two OCP clusters. Here, a separate Portworx Enterprise cluster runs under each OCP cluster.

The following diagram shows an asynchronous DR setup involving two clusters that are geographically apart:

• Application data and supported resources are asynchronously replicated from a source to a destination cluster, which means there is a delay between data changes occurring on the source cluster and their replication to the destination cluster.
• Incremental changes from OCP applications and Portworx data are continuously sent to the destination cluster.
• In case the source cluster becomes unavailable, you can activate the applications in the destination cluster.

important

Cluster-wide operators are not migrated as part of a DR migration if they are not installed in the same namespace as the applications you want to migrate (for example, in OpenShift, the operator installation defaults to the openshift-operators namespace). As a result, after migration, you will not be able to scale up or down your applications on the destination cluster using storkctl.

Perform the following steps to set up asynchronous DR:

📄 Prerequisites

Prerequisites for Async DR migration.

📄 Prepare your Portworx cluster

Prepare your Portworx cluster for asynchronous DR.

📄 Generate and apply a cluster pair spec

How to pair your clusters.

📄 Schedule a migration

How to set up asynchronous schedules.

📄 Failover an application

How to failover an application from one OCP cluster to another.

📄 Failback an application

Find out how to failback an application from the backup OCP cluster to the original one.