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.
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
| 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
When you deploy a recovery SDDC, the system automatically creates an NFS datastore named 'ds01'.
This NFS datastore is created exclusively to expose VM backups 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.
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
- 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.
- If you deploy a single-host recovery SDDC (also known as a ‘starter’ Recovery SDDC), it is deleted after 30 days and all data on the recovery SDDC is lost. For this reason a single host Recovery SDDC is only intended for testing purposes, not for use in production.
- You can scale-up a single host recovery SDDC into a three or more ‘multi-host’ recovery SDDCs and retain all your data. A multi-host recovery SDDC with three or more hosts is not time bound but is subject to recurring costs. A multi-host Recovery SDDC also provides data protection and production-level SLAs.
- 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
- 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.
