Create a ClusterPair for synchronous DR in Tanzu

Summary and Key concepts

Summary

This article provides steps to set up a bidirectional ClusterPair between two clusters for synchronous disaster recovery (DR) using Portworx. The ClusterPair establishes a trust relationship that enables resource migration and failover/failback processes between clusters. The guide explains the importance of creating ClusterPair objects to establish communication, and it recommends using service accounts to avoid token expiration errors during migration. It also includes commands for creating and verifying a ClusterPair, ensuring that both clusters are configured with the same Stork version and authentication setup.

Kubernetes Concepts

• Namespaces: Used here to designate a namespace (e.g., kube-system or <migrationnamespace>) for managing resources involved in migration across clusters.

Portworx Concepts

• Stork: A scheduler for data migration and disaster recovery management in Kubernetes, essential for creating bidirectional ClusterPairs for DR.

• Service Accounts: Recommended for setting up migrations to avoid token expiration errors; this article provides links for creating kubeconfig files with service accounts.

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.

​

important

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.

note

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.

note

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?

If you see an error, you can get more information by running the following command:

kubectl describe clusterpair <your-clusterpair-name> -n <migrationnamespace>