Synchronous Disaster Recovery
Summary and Key concepts
Summaryβ
This article outlines the setup of a Portworx Synchronous Disaster Recovery (DR), also known as Metro DR, which enables a stretched Portworx cluster across two clusters within a metropolitan area network (MAN) with a maximum 10 ms latency. The document covers the deployment process, focusing on creating a single Portworx cluster that spans two locations. Key considerations and limitations are highlighted, such as maximum replication factor, unsupported volumes, and the lack of support for KubeVirt VMs. Additionally, it mentions that cluster-wide operators must reside in the same namespace as the migrated applications to avoid scaling limitations.
Kubernetes Conceptsβ
- Operators: Kubernetes controllers that help manage applications; here, operators must be in the same namespace as the applications to be migrated to ensure DR functions as expected.
Portworx Conceptsβ
-
Replication Factor: Defines the number of replicas for each volume. The replication factor in Synchronous DR setups is limited to
2
for this stretched configuration. -
sharedv4 Service Volumes: A Portworx feature for shared file systems; however, sharedv4 volumes are not supported within a Synchronous DR setup.
-
KubeVirt: A virtual machine management add-on for Kubernetes, not supported in Portworxβs Synchronous DR setup due to performance and compatibility constraints.
To deploy Synchronous DR (also known as Metro DR) setup, you need to install a single stretched Portworx cluster across two clusters. A single Portworx clusters spans across an on-premise environment with a maximum latency of 10 ms.
The following diagram shows a synchronous DR setup involving two clusters in the same metropolitan area network:
This document explains how to install a stretched Portworx cluster and achieve synchronous DR. It will demonstrate how to failover and failback applications between two clusters.
- Cluster-wide operators are not migrated as part of a DR migration if it is not installed in the same namespace as the applications you want to migrate (for example, in OpenShift, the operator installation defaults to the
openshift-operators
namespace). As a result, after migration, you will not be able to scale up or down your applications on the destination cluster usingstorkctl
. - Synchronous DR is supported only on the following platforms with vSphere cloud drive configurations.
- Tanzu Kubernetes Grid Service (TKGS)
- Vanilla Kubernetes
- Openshift deployed on vSphere
- In a Synchronous DR setup,
- The maximum supported replication factor is
2
. - The sharedv4 service volumes are not supported in the Portworx cluster.
- KubeVirt VMs are not supported.
- The maximum supported replication factor is
Perform the following steps to set up synchronous DR:
π Prerequisites
Prerequisites for Synchronous DR migration.
π Prepare your cluster
Find out how to install a single stretched Portworx cluster across multiple Kubernetes clusters.
π Setup a witness node
Find out how to install a witness node.
π Generate and apply a cluster pair spec
Find out how to pair your clusters.
π Schedule a migration
Find out how to synchronize your clusters by scheduling periodic migrations between them.
π Failover an application
Find out how to failover an application from one Kubernetes cluster to another.
π Failback an application
Find out how to failback an application from the backup Kubernetes cluster to the original one.