Create a ClusterPair
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.
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>).
-
When creating multiple ClusterPairs, use only one external object store (
BackupLocation). -
If you configured the
portworx-apiservice to be accessible externally through ingresses or routes, specify the following two additional command options while creating the ClusterPair:--dest-ep string: Endpoint of theportworx-apiservice in the destination cluster.--src-ep string: Endpoint of theportworx-apiservice 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.
Automatic bucket creation:
In AWS, using the --bucket option in the storkctl create clusterpair command will automatically create two buckets named after the cluster UUIDs:
- First bucket: used to replicate resources from the source to the destination cluster.
- Second bucket: used for replication in the opposite direction.
Unidirectional clusterpair command for AWS S3 with bucket creation:
storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--src-kube-file <source-kubeconfig-file> \
--dest-kube-file <destination-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 \
--bucket <source-cluster-bucket>
Using the --use-existing-objectstorelocation option:
The --use-existing-objectstorelocation option is used to specify that existing object store locations should be used instead of creating new ones. This is particularly useful when you already have object store locations configured and wish to reuse them.
Following is the unidirectional clusterpair command with existing object store location for AWS S3:
storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--src-kube-file <source-kubeconfig-file> \
--dest-kube-file <destination-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 \
--use-existing-objectstorelocation
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.
Automatic bucket creation is not supported in Microsoft Azure. You need to manually create the buckets and provide the names using the --bucket option.
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.
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.
Bidirectional clusterpair command for AWS S3 with bucket creation:
storkctl create clusterpair migration-cluster-pair \
--namespace <migrationnamespace> \
--src-kube-file <source-kubeconfig-file> \
--dest-kube-file <destination-kubeconfig-file> \
--mode async-dr \
--bucket source-cluster-bucket
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?
kubectl describe clusterpair <your-clusterpair-name> -n <migrationnamespace>