Before you deploy a new or add an existing recovery SDDC, it is important to understand how it functions and its limitations.

VMware Live Cyber Recovery leverages the VMware Cloud on AWS Software Defined Data Center ("SDDC") as a disaster recovery site, which you can use if disaster strikes (or for testing) and you have to fail over your protected vCenter to the cloud.

Purchasing VMware Live Cyber Recovery Recovery SDDCs

VMware Live Cyber Recovery uses the recovery SDDC for disaster recovery and ransomware recovery operations.

Recovery SDDCs leverage VMware Cloud on AWS hosts to enable ransomware and disaster recovery environments.

You can pay for recovery SDDC host usage on VMware Cloud on AWS in the following ways:
  • You can add hosts for just-in-time for ransomware and disaster recovery test and failover. Price is charged per month, payable in arrears.
  • Work with your sales representative to retroactively purchase existing VMware Cloud on AWS SKUs to cover host usage, in multiples of 30 days, within 48 hours after the end of usage.
  • If you are an AWS Resell customer, you can follow the same process but you must have a commercial relationship with Broadcom, which you can establish by purchasing any VMware by Broadcom subscription. A VMware by Broadcom subscription is required to perform disaster and ransomware recovery operations.

  • For always-on pilot light hosts on a recovery SDDC, you can purchase 1-year subscriptions of VMware Cloud on AWS hosts.
  • For planned disaster recovery tests, you can purchase a 90 day subscription in advance with monthly pricing.

Contact your sales VMware by Broadcom sales representative for more information.

Create Firewall Rule for Public IP Addresses Accessing vCenter

As a general best practice, create a firewall rule for all Public IP addresses (or IP address ranges) that require access to the vCenter on your recovery SDDC. For more information, see Create Firewall Rule for Public IP Addresses Accessing vCenter.

Recovery SDDC Default Firewall Rules

Do not change the recovery SDDC default firewall rules. Changing the default firewall rules could interrupt access from the SDDC to the cloud file system or Orchestrator components. By default, when your recovery SDDC is deployed its network will contain a set of pre-configured firewall rules which begin with the "CloudDR-SystemRule-" prefix.

Do not delete these firewall rules. recovery SDDC firewall rules with this prefix cannot be edited or deleted in the VMware Live Cyber Recovery UI, but these rules can be edited and deleted in the VMware Cloud on AWS console. So, do not change or delete any of these SDDC firewall rules.

Other Firewall Rules on the Recovery SDDC

When you create or attach a recovery SDDC, firewall rules are created that facilitate failover and failback operations, as well as data movement during failover and failback. Some of the rules are used for the Carbon Black Cloud Workload appliance used for the ransomware recovery. Do not delete or modify these rules:
Table 1. Allow firewall rules created for the Recovery SDDC
Source Destination Firewall Rule

Cloud file system

CloudDR-Proxy VM

Allow

CloudDR-Proxy VM

Cloud file system

Allow

CloudDR-Proxy VM

vCenter Server

Allow

Recovery SDDC Datastore

Prior to July 2024, when you deployed a recovery SDDC, the system automatically created an NFS datastore on the SDDC named 'ds01'.

This NFS datastore exposes VM backups from the cloud file system to the recovery SDDC to facilitate disaster recovery, so never use it as general-purpose storage. Do not use the vSphere Client, vSphere APIs, or any other means to create and power on VMs directly on this NFS datastore, except through VMware Live Cyber Recovery.

Starting in July 2024, this datastore will use the name of the cloud file system it is associated with. For example, if you attach a cloud file system to a recovery SDDC and name it 'prod-recovery' then the corresponding datastore on the recovery SDDC will also be named 'prod-recovery'.

Recovery SDDC and Cluster Names

Cluster names are given automatically when you create a cluster, you cannot provide a custom name for clusters you add to your recovery SDDC.

Clusters added to a recovery SDDC follow this naming pattern: 'Cluster-<x>-<y>'. For example, the first cluster for your first SDDC is named: Cluster-1-1. If you add another cluster to the same SDDC, the new cluster name is 'Cluster-1-2', and so on.

If you tear down the first SDDC, the cluster names in any recovery plan change and appear with an asterisk (*) for the SDDC name, such as 'Cluster-*-1' and Cluster-*-2. When the second SDDC is deployed, the UI displays the proper cluster names in the recovery plans with the incremented SDDC name.

This same behavior applies to cluster names in plan compliance reports. If the SDDC is currently deployed, then the cluster names appear with the correct name in the report, such as 'Cluster-1-2'. If the SDDC is deleted at the time the report runs, then the cluster name uses the asterisk, such as 'Cluster-*-2'.

Your AWS Account and the Recovery SDDC

When you deploy a recovery SDDC, you connect it to an AWS account belonging to you (also called the 'customer AWS account').

Before you can deploy a new recovery SDDC, your AWS account must be linked to your VMware Cloud Organization. The purpose of this account is to provide a network connection from customer AWS services to your VMware Cloud on AWS SDDCs. For more information, see Deploy an SDDC from the VMC Console and AWS Account Linking.

Your AWS account must also have a subnet created in your AWS Virtual Private Cloud (VPC) in the same AWS region and availability zone where you deployed a cloud file system. As a best practice, create a subnet in every AWS Availability Zone (AZ) you want to use before you deploy a cloud file system and recovery SDDC. The size of the subnet must be /26. For more information, see Work with VPCs and subnets.

For the full list of VMware Cloud on AWS networking requirements for the customer AWS account, see Deploying and Managing a Software Defined Data Center.

Recovery SDDC Deployment Restrictions

Before you deploy a recovery SDDC, there are several restrictions you need to know.
  • When you create or add a recovery SDDC, a new /26 subnet is created. This subnet is connected to the Compute Gateway and is separate from the management subnet used by the recovery SDDC. You can either connect to the /26 range or you can enter a new subnet.
  • Any subnets you choose for the recovery SDDC cannot overlap with the SDDC management subnet, or if you have a policy-based VPN configured on an existing SDDC, the remote network cannot overlap with the /26 subnet. Other subnets must not overlap with the AWS VPC CIDR for the AWS account that is linked to your VMware Cloud Organization.
  • Each recovery SDDC you deploy (after the first deployment) must have a cloud file system site associated with it. For more information, see deploy a cloud file system.
  • You can remove hosts from the recovery SDDC if the number of hosts in your SDDC cluster remains above the 2-host minimum. You cannot scale down a 2-host Recovery SDDC. Ensure that you have sufficient capacity in your cluster to hold the workload VMs that will be evacuated from the hosts that you remove.
  • Two host (I3 type) recovery SDDC deployments are not supported with SDDC version 1.15.
  • Do not change the user credentials for the NSX Cloud Admin account.

Maintaining recovery SDDC Settings

Once you have deployed your recovery SDDC, do not change any of the following settings or configurations in the VMware Live Cyber Recovery UI: 
  • Do not rename your recovery SDDC once you have deployed it. Once you name and deploy your Recovery SDDC, do not change its name.
  • Do not block VMware Live Cyber Recovery component IP addresses. If you have enabled an authentication policy for your Organization, to either block or allow specific IP addresses, make sure that you do not accidentally block or disallow the Orchestrator and cloud file system IP addresses. To find these IP addresses, see Service Public IP Addresses.