Skip to main content
Version: 3.2

Synchronous disaster recovery in Tanzu

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:

Detailed Aynsc setup

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.

caution
  • 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. 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 only on Tanzu Kubernetes Grid Service (TKGS) with vSphere cloud drive configurations.
  • 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.

Perform the following steps to set up synchronous DR:

Last updated on