Create a ClusterPair for synchronous DR in Tanzu
In a synchronous DR setup, it is essential to pair two clusters to enable the migration of resources. To facilitate this process, you need to establish trust objects, known as ClusterPair objects, between the two clusters. Portworx requires these objects to establish a communication channel between the two clusters.
The ClusterPair objects pair the two clusters, allowing migration of resources.
Creation of the ClusterPair object does not initiate the actual migration of resources between the clusters. It establishes the foundation for a trust-based relationship between the clusters. Using this ClusterPair object, you can create a migration schedule that initiate the data migration between the two paired clusters.
With Stork, you can establish bidirectional cluster pairing, which will enable resource migration in both directions across the two clusters. This also facilitates smooth application failover and failback processes.
The default admin namespace is kube-system. In all examples, <migrationnamespace> is considered the admin namespace responsible for migrating all namespaces from your source cluster to the destination cluster. Alternatively, you can specify a non-admin namespace, but note that only that specific namespace will be migrated. To learn how to set up an admin namespace, refer to the Set up a Cluster Admin namespace for Migration page.
Pair your clusters
You can create either unidirectional or bidirectional ClusterPairs. In Synchronous DR setup where there is a single stretched cluster, it is recommended to generate the bidirectional ClusterPair objects. The bidirectional ClusterPair establishes a trusted relationship between the two clusters in both directions, enabling seamless migration of resources and data in both directions.
If you set up migrations and migration schedules using user accounts, you will encounter token expiration-related errors. To avoid these errors, Portworx by Pure Storage. recommends setting up migrations and migration schedules using service accounts. For service accounts, you need to create a kubeconfig file by following the steps here and use the same file when creating a ClusterPair.
Prerequisite
The same Stork version 23.7.0 or newer is installed on both the source and destination clusters.
If you are using a Stork version prior to 23.7.0, then you can follow this procedure to generate a synchronous DR ClusterPair.
Create a bidirectional ClusterPair
Run the following command from the system where storkctl is installed. It creates a cluster pairing named migration-cluster-pair on both source and destination clusters:
storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--src-kube-file <source-kubeconfig-file> \
--dest-kube-file <destination-kubeconfig-file> \
--mode sync-dr
This command establishes authentication in both directions between each cluster.
Verify the status of your bidirectional ClusterPair
Run the following command to retrieve information about the cluster pairs in the cluster namespace <migrationnamespace>:
storkctl get clusterpair migration-cluster-pair -n <migrationnamespace>
Source cluster details:
NAME STORAGE-STATUS SCHEDULER-STATUS CREATED
migration-cluster-pair NotProvided Ready 14 Jun 23 18:24 UTC
Destination cluster details:
NAME STORAGE-STATUS SCHEDULER-STATUS CREATED
migration-cluster-pair NotProvided Ready 14 Jun 23 18:24 UTC
On a successful pairing you will see the scheduler status as Ready. Since there is only one Portworx cluster spanning both clusters, there is no need to pair Storage, thus the storage status will be NotProvided.
Encountered an error?
kubectl describe clusterpair <your-clusterpair-name> -n <migrationnamespace>