Create a ClusterPair for asynchronous DR on GCP Anthos

In an asynchronous DR setup, it is essential to pair two clusters to enable the migration of data and 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 Kubernetes clusters, allowing migration of resources and volumes.

Creation of the ClusterPair object does not initiate the actual migration of resources and volumes 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.

Cluster pairings can be established in a unidirectional or bidirectional manner with Stork, allowing resources and data to migrate between two clusters in the specified direction. ​

• Unidirectional pairing: enables data and resource migrations in one direction between two clusters.
• Bidirectional pairing: enables data and resource migration in both directions between the two clusters. With bidirectional ClusterPair, you can configure clusters for seamless failover and failback from the beginning.

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

Use the storkctl create clusterpair command to create your unidirectional or bidirectional ClusterPair using the command options specific to your environment, as explained in the following sections. This command sets up a connection between a source cluster using the source config file (<source-kubeconfig-cluster>) and a destination cluster using the destination kubeconfig file (<destination-kubeconfig-cluster>). The pairing is created within the specified namespace (<migrationnamespace>). ​

note

• When creating multiple ClusterPairs, use only one external object store (BackupLocation).

• If you configured the portworx-api service to be accessible externally through ingresses or routes, specify the following two additional command options while creating the ClusterPair:

  • --dest-ep string: Endpoint of the portworx-api service in the destination cluster.
  • --src-ep string: Endpoint of the portworx-api service in the source cluster.

  If the above endpoints are not specified, the storage status of the ClusterPair will show as failed.

• 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.

Unidirectional ClusterPair

​ A unidirectional clusterpair establishes authentication from the source cluster to the destination cluster so resources and data can be migrated in one direction. ​ ​

Create a unidirectional ClusterPair for Amazon S3 or S3 compatible

​ Run the following command to create a unidirectional ClusterPair named migration-cluster-pair for cluster migration: ​

storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--dest-kube-file <destination-kubeconfig-file> \
--src-kube-file <source-kubeconfig-file> \
--provider s3 \
--s3-endpoint s3.amazonaws.com \
--s3-access-key <s3-access-key> \
--s3-secret-key <s3-secret-key> \
--s3-region <s3-region> \
--unidirectional

Portworx will use AWS S3 or S3 compatible blob storage for migrating volume data between the two clusters. The credentials specified in the above command are used for authenticating with the your cloud platform. The S3 bucket information is provided with the specified access key, secret key, and region (<s3-bucket-location>) to facilitate the data transfer between the two clusters. ​

Create a unidirectional ClusterPair for Microsoft Azure

​ Run the following command to create a unidirectional ClusterPair named migration-cluster-pair for cluster migration:

storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--dest-kube-file <destination-kubeconfig-file> \
--src-kube-file <source-kubeconfig-file> \
--provider azure \
--azure-account-name <azure-account-name> \
--azure-account-key <azure-account-key> \
--unidirectional

​ Portworx will use Azure blob storage for migrating volume data between the two clusters. The Azure credentials specified in the above command are used for authenticating with the Azure cloud platform. ​

Create a unidirectional ClusterPair for GCP

​Run the following command to create a unidirectional ClusterPair named migration-cluster-pair for cluster migration:

storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--dest-kube-file <destination-kubeconfig-file> \
--src-kube-file <source-kubeconfig-file> \
--provider google \
--google-project-id <gcp-project-ID> \
--google-json-key <gcp-json-auth-key> \
–-unidirectional

​ Portworx will use Google Cloud storage for migrating volume data between the two clusters. The Google Cloud credentials specified in the above command are used for authenticating with the GCP. ​

Verify the status of your unidirectional ClusterPair

​ The following command uses storkctl to retrieve information about the cluster pairs in the Kubernetes namespace <migrationnamespace>: ​

storkctl get clusterpair -n <migrationnamespace>

​ This command displays details such as the name and status of the existing cluster pairs within that specific namespace.

Source cluster details:

NAME                     STORAGE-STATUS  SCHEDULER-STATUS  CREATED
migration-cluster-pair   Ready           Ready             10 Mar 23 17:16 PST

​On a successful pairing, you should see the STORAGE-STATUS and SCHEDULER-STATUS as Ready.

Bidirectional ClusterPair

​ A bidirectional clusterpair establishes authentication from the source cluster to the destination cluster, and vice versa, so resources and data can be migrated in both directions.

​With bidirectional ClusterPair the trust relationship between the two clusters is established in both the directions. ​

Prerequisite

​ Ensure 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 an asynchronous DR ClusterPair.

​

Create a bidirectional ClusterPair for S3 or S3 compatible

​ Run the following command to create a bidirectional cluster pairing named migration-cluster-pair for cluster migration: ​

storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--dest-kube-file <destination-kubeconfig-file> \
--src-kube-file <source-kubeconfig-file> \
--provider s3 \
--s3-endpoint s3.amazonaws.com \
--s3-access-key <s3-bucket-access-key> \
--s3-secret-key <your-s3-bucket-access-key> \
--s3-region <s3-bucket-location> 

​ Portworx will use AWS S3 or S3 compatible blob storage for migrating volume data between the two clusters. The credentials specified in the above command are used for authenticating with the your cloud platform. The S3 bucket information is provided with the specified access key, secret key, and region (<s3-bucket-location>) to facilitate the data transfer between the two clusters. ​

Create a bidirectional ClusterPair for Microsoft Azure

Run the following command to create a bidirectional cluster pairing named migration-cluster-pair for cluster migration: ​

storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--dest-kube-file <destination-kubeconfig-file> \
--src-kube-file <source-kubeconfig-file> \
--provider azure \
--azure-account-name <azure-account-name> \
--azure-account-key <azure-account-key> 

​ The data migration is carried out using the Azure cloud platform, and the Azure storage account information is provided with the specified account name and account key for authentication and data transfer between the two clusters. ​

Create a bidirectional ClusterPair for GCP

Run the following command to create a bidirectional cluster pairing named migration-cluster-pair for cluster migration: ​

storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--dest-kube-file <destination-kubeconfig-file> \
--src-kube-file <source-kubeconfig-file> \
--namespace <migrationnamespace> \
--provider google \
--google-project-id <gcp-project-ID> \
--google-json-key <gcp-json-auth-key> 

​ The data migration is performed using the GCP, and the Google Cloud project is identified by the specified project ID (<gcp-project-ID>). Additionally, the JSON key (<gcp-json-auth-key>) is provided for authentication to access the required resources for the data transfer between the two clusters. ​

Verify the status of your bidirectional ClusterPair

​ The following command uses storkctl to retrieve information about the cluster pairs in the Kubernetes namespace <migrationnamespace>: ​

storkctl get clusterpair -n <migrationnamespace>

​ This command displays details such as the name and status of the existing cluster pairs within that specific namespace.

Source cluster details:

NAME                    STORAGE-STATUS  SCHEDULER-STATUS  CREATED
migration-cluster-pair  Ready           Ready            10 Mar 23 17:16 PST

Destination cluster details:

NAME                    STORAGE-STATUS  SCHEDULER-STATUS  CREATED
migration-cluster-pair  Ready           Ready             10 Mar 23 17:16 PST

On a successful pairing, you should see the STORAGE-STATUS and SCHEDULER-STATUS as Ready.

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>