Create a ClusterPair
While setting up synchronous DR, you must define a trust object called a ClusterPair between the two clusters. Portworx requires this object to establish communication channels between the two clusters.
The ClusterPair object pairs the Portworx storage driver as well as the two Kubernetes clusters, allowing resources to be migrated in the synchronous DR.
Creation of a ClusterPair will not initiate resource migration between the two clusters. Cluster pairing simply creates a trust relationship between the two clusters and sets the direction in which resources will potentially get migrated.
To initiate a data migration between the two clusters, you will need to create a Migration object which will be covered in upcoming sections.
Stork allows you to pair two clusters in the following two ways:
- Unidirectional pairing: enables data and resource migration in a single direction between the two clusters.
- Bidirectional pairing: enables data and resource migration in both the directions between the two clusters. With bidirectional ClusterPair, you can configure clusters for seamless failover and failback right from the start.
Unidirectional ClusterPair
Unidirectional ClusterPair establishes a logical connection between two clusters, enabling data to migrate in one direction. When you apply updates to the source cluster, they are replicated or synchronized on the destination cluster.
Create a unidirectional ClusterPair
The following command uses storkctl to create a cluster pairing named migration-cluster-pair for cluster migration:
storkctl create clusterpair migration-cluster-pair \
--src-kube-file <source-Kubernetes-cluster> \
--dest-kube-file <destination-Kubernetes-cluster> \
--mode sync-dr \
--namespace <migrationnamespace> \
--unidirectional
This command sets up a data replication connection between a source Kubernetes cluster (specified in <source-Kubernetes-cluster>) and a destination Kubernetes cluster (specified in <destination-Kubernetes-cluster>). The data replication mode used is sync-dr (synchronous disaster recovery). The pairing is created within the specified namespace (<namespace>). Additionally, the --unidirectional flag ensures that changes made in the source cluster are replicated to the destination cluster, but changes on the destination cluster are not sent back to the source cluster.
In all the cluster pairing commands, you can use -u as the alteranative flag for --unidirectional.
Verify the status of your unidirectional ClusterPair
The following command uses storkctl to retrieve information about the cluster pairs in the Kubernetes namespace kube-system:
storkctl get clusterpair migration-cluster-pair -n kube-system
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 NotProvided Ready 14 Jun 23 18:24 UTC
Bidirectional ClusterPair
A bidirectional ClusterPair establishes a logical connection between two clusters to synchronize or replicate data bidirectionally, allowing resources and data to potentially migrate in both the directions. With bidirectional ClusterPair the trust relationship between the two clusters is established in both the directions.
Prerequisite
For the storkctl create command (used to create bidirectional ClusterPairs) to function correctly, ensure the same Stork version 23.7.0 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
The following command creates a cluster pairing named migration-cluster-pair for cluster migration:
storkctl create clusterpair migration-cluster-pair \
--src-kube-file <source-Kubernetes-cluster> \
--namespace <migrationnamespace> \
--dest-kube-file <destination-Kubernetes-cluster> \
--mode sync-dr \
This command establishes a data replication connection between a source Kubernetes cluster (specified in <source-Kubernetes-cluster>) and a destination Kubernetes cluster (specified in <destination-Kubernetes-cluster>). This means that data changes made on the source cluster will be synchronously replicated to the destination cluster to ensure disaster recovery readiness.
Verify the status of your bidirectional ClusterPair
The following command uses storkctl to retrieve information about the cluster pairs in the Kubernetes namespace kube-system:
storkctl get clusterpair migration-cluster-pair -n kube-system
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 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