Configure a reverse migration schedule
In case of a disaster, where one of your Kubernetes clusters is down and inaccessible, you can failover the applications running on it to an operational Kubernetes cluster. After your original source cluster is accessible again, you can failback your application to it. However, if the destination cluster has been running applications for some time, it is possible that the state of your application on the destination cluster differs from your source cluster. This is because new resources are created, or the data in stateful applications has changed on your destination cluster.
Portworx, Inc. recommends reverse syncing your source and destination clusters before failing back your applications, so that you have the most up-to-date applications on your original source cluster. This means creating a ClusterPair from your destination to source cluster, then creating a migration schedule to migrate resources from your destination to the source cluster using that ClusterPair. As both of your clusters are accessible, follow the instructions on this page to configure a reverse migration schedule.
Generate a reverse ClusterPair
Generate a reverse ClusterPair on your source cluster. Run the following command on the source cluster by specifying the
<your-clusterpair-name>
and<migrationnamespace>
to create a ClusterPair and save the resulting spec to a file namedreverse-clusterpair.yaml
:<you-remote-cluster>
: is the name of the Kubernetes object that will be created on the destination cluster representing the pair relationship.<migrationnamespace>
: is the name of the Kubernetes namespace on the destination cluster that you want to migrate to the source cluster.
storkctl generate clusterpair -n <migrationnamespace> <your-clusterpair-name> -o yaml > reverse-clusterpair.yaml
Remove the
options
section from thereverse-clusterpair.yaml
file:options:
<insert_storage_options_here>: ""Copy the
reverse-clusterpair.yaml
file to your destination cluster and apply it using the following command:kubectl create -f reverse-clusterpair.yaml
Check the status of the pairing on the destination cluster:
storkctl get clusterpair -n <migrationnamespace>
NAME STORAGE-STATUS SCHEDULER-STATUS CREATED
<your-clusterpair-name> NotProvided Ready 30 Nov 22 22:59 UTCOn a successful pairing you will see the scheduler status as
Ready
and storage status asNotProvided
.
Configure a reverse migration schedule
Create a schedule policy on your destination cluster using the instructions in the Create a schedule policy section.
Copy and paste the following spec into a file called
reverse-migrationschedule.yaml
on your destination cluster:apiVersion: stork.libopenstorage.org/v1alpha1
kind: MigrationSchedule
metadata:
name: reversemigrationschedule
namespace: <migrationnamespace>
spec:
template:
spec:
clusterPair: <your-clusterpair-name>
includeResources: true
startApplications: false
includeVolumes: false
namespaces:
- <migrationnamespace>
schedulePolicyName: <your-schedule-policy>
suspend: truenoteAs the
suspend
parameter is set totrue
, this migration schedule will not be active.Apply your
reverse-migrationschedule.yaml
on your destination cluster:kubectl apply -f reverse-migrationschedule.yaml
This migration schedule will be in suspended state, and you will need to activate it before failing back your application.