Skip to main content
Version: 3.3

Prerequisites for Asynchronous Disaster Recovery

The prerequisites provided in this section ensure a stable foundation for data replication and failover when you enable asynchronous disaster recovery between the source and destination clusters. Review them carefully to prevent configuration issues during deployment.

Make sure you meet the following prerequisites in addition to the System Requirements:

  • An active Portworx Enterprise Disaster Recovery (DR) license.

  • Your environment must meet the following network requirements:

    • All worker nodes in the source and destination clusters must be able to access the Kubernetes API endpoints (for example, ports 6443 and 443).
    • For a Kubernetes based distribution, the source and destination clusters must be able to access ports in the 9001–9020 range to enable communication between Portworx worker nodes.
      For an OpenShift based distribution, the source and destination clusters must be able to access ports in the 17001–17020 range to enable communication between Portworx worker nodes.

    For more information on the list of required ports for your environment, see Network Requirements.

  • AWS S3, Google Cloud Object Storage, Azure Blob Storage or any other S3 compatible Storage to be used as the Object Store.

  • A maximum of one StorageClass object is configured as the default. Having multiple default StorageClasses causes PVC migrations to fail.

  • Depending on your cloud provider (EKS, GKE, AAD enabled AKS, or OKE) ensure to enable secure, automated migration of applications and volumes between clusters using Stork.

  • A separate Portworx cluster with the same version is installed on both the source and destination clusters.

  • The latest version of storkctl is installed on the source and destination clusters. You can download the latest version from the currently running Stork container.
    For more information, see Prepare your Portworx Cluster.

  • For an OpenShift based distribution, an ApplicationRegistration custom resource (CR) is created to enable successful migration of supported applications. For more information, see ApplicationRegistrations.
    Important: For certain Kubernetes applications, an ApplicationRegistration custom resource (CR) is created before initiating migration.