Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Cloud Disaster Recovery Best Practices
Executive summary Architecture
Architecture
Pre-deployment planning Deployment and post-deployment Protection to the cloud Recovery Failback Uninstall REST API Limitations Maintenance and troubleshooting Technical support and resources

Architecture

Home > Data Protection > PowerProtect Data Manager > White Papers > Cloud Disaster Recovery Best Practices > Architecture

Architecture

  • AWS

    The components on AWS are automatically created using the AWS CloudFormation service. There are two stacks that deploy everything: CDRS-DeployStack which also creates the stack that creates the RDS cluster.

    AWS components:

    • VPC with public and private subnets, Internet gateway
    • RDS Cluster to store persistent data (db.t3.small), deployed in the private subnet
    • Cloud DR Server – CDRS – main cloud component (m5.large), deployed in the public subnet
    • Manages the cloud activities
    • Provides HTML 5 user interface
    • On-premises components are connected to the CDRS
    • Only the CDRS communicates with the RDS
    • Cloud DR targets – configuration of one or more S3 buckets
    • Restore service – (c4.8xlarge) Instance that manages data conversion during recovery and failback activities: in a recovery, the Restore service converts data chunks that are stored on cloud targets into VMDK files (this conversion process is called rehydration), and in a failback, the Restore service converts EBS volumes that are attached to EC2 instances into data files (dehydration) and stores them on cloud targets.

    Each Restore service instance handles a single recovery or failback activity at a time in order to minimize its running time and save AWS compute costs. If there is no need for additional recovery or failback activities after the Restore service is done converting – it will be automatically terminated by an auto scaling group, that is also responsible for launching new Restore service instances for new recovery and failback activities.

    The CDRS and the Restore Service instances communicate through SQS queues. All these components, including the autoscaling groups are created by CloudFormation when the first recovery is triggered, per region. The restore service uses a public IP address and the CloudFormation stack creates an internet gateway that the Restore service uses to communicate with the other AWS services.

    When working with RecoverPoint for VMs, there is an additional functionality to the Restore Service instance for snapshot consolidation. Review the RecoverPoint for Virtual Machines – Replication to AWS whitepaper for more information.

    • Retention service – (m4.large) Starting release 19.8 of Cloud DR (either CDRA or PowerProtect Data Manager deployment), the retention process runs externally on a Retention Service instance, while in previous releases it runs on the CDRS.

    Azure

    Azure components:

    • Resource Group includes the CDRS and the MySQL DB
    • MySQL DB to store persistent data (General Purpose, 2 vCores, 50 GB)
    • Cloud DR Server – CDRS (Standard DS2 v2 (2 vcpus, 7 GiB memory))
    • Cloud DR targets – configuration of one or more Storage Accounts
    • Restore service – Standard D16s v3 (16 vcpus, 64 GiB memory)
      Created in a dedicated Resource Group, contains a storage account that has queues to support the CDRS and the Restore Service VMs communication.
      Each recovered VM will be created in a new different Resource Group.
    • Retention service - Standard A1 v2 (1 vcpus, 2 GiB memory)