Skip to main content
Version: 3.4

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.

This topic explains how to install a stretched Portworx cluster and achieve synchronous disaster recovery (DR). It demonstrates how to failover and failback applications between two clusters.

To deploy synchronous DR (also known as Metro DR) setup, you must install a single stretched Portworx cluster across two clusters. A single Portworx cluster spans across an on-premise environment with a maximum latency of 10 ms.

important
  • Cluster-wide operators are not migrated as part of a DR migration if they are 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 using storkctl.
  • Synchronous DR is supported on the following platforms with vSphere cloud drive configurations:
    • Tanzu Kubernetes Grid Service (TKGS)
    • Vanilla Kubernetes
    • OpenShift deployed on vSphere or Bare Metal
  • Synchronous DR is supported for Kubevirt VMs with PX RWX Block Volumes on the following platforms:
    • OpenShift Container Platform
  • Synchronous DR is supported with local drive on the following platforms:
    • OpenShift on Bare Metal
  • In a Synchronous DR setup:
    • The maximum supported replication factor is 2.
    • The sharedv4 service volumes are not supported in the Portworx cluster.
note

Synchronous DR is not supported on KubeVirt VMs with Sharedv4 service volumes.

The following diagram shows a synchronous DR setup involving two clusters in the same metropolitan area network:

Detailed Sync setup

Perform the following steps to set up synchronous DR: