In an event of an actual disaster or for testing purposes, Druva DraaS Failover feature aims to recover virtual machines in the AWS account based on the configuration and failover settings specified in the DR plan.
- First, an administrator triggers the failover from the Management Console and Druva Cloud instructs the Druva AWS proxy to initiate the failover.
- The EBS snapshot is used to create an EBS volume. The Druva AWS proxy creates an EC2 instance in your AWS account. You can choose the EC2 instance type from the Management Console when you configure the VM for DR. The EBS volume gets attached to the EC2 instance.
- Once the process has completed, EC2 instance is restarted and is ready to support its workload. The same process is repeated for all protected VMs.
- The last step is to update the DNS servers to redirect the traffic to the IP addresses of the new EC2 servers.
Phoenix provides advanced orchestration capabilities allowing to decide on the failover sequence, creating dependencies between EC2s and adding scripts for execution during EC2 boot. An example of dependency would be an e-commerce Web server storing data in the database. It wouldn’t make sense to start Web EC2 before the database is available. See, About recovery workflow.
Types of failover
Druva allows you to configure virtual machines for disaster recovery failover in the two modes, Production and Test, respectively. You can configure virtual machines for failover with the settings specific to Failover Recovery and Failover Testing. Depending upon the type selected, you can use the corresponding settings to launch the EC2 instance.
Ensure that the failover prerequisite checks are cleared successfully. See, DRaaS failover prerequisite checks.
|Failover Recovery||The Production Failover option is used to recover protected virtual machines to AWS in the event of an actual disaster. Production Failover ensures that the virtual environment is failed over successfully with minimal downtime during the disaster.|
|Failover Testing||The Failover Testing option is used to test that the virtual machines are recovered at the recovery site as expected. This operation creates virtual machines based on the preconfigured virtual machine failover settings specified in the DR plan.|
Druva recommends running the Failover Testing in a virtual environment periodically to demonstrate the failover setup and identify any possible issues that can occur in the event of an actual disaster.
For more information about configuring the failover settings for virtual machines, see Manage disaster recovery failover.
DRaaS failover considerations
Review the following points before triggering a failover of virtual machines.
- You can launch an AWS instance for a virtual machine associated with the DR plan, only if the following exists for the virtual machine:
- An AMI, if you have deployed the Druva AWS proxy version 4.7.6 or earlier. Or,
- A DR copy, if you have deployed Druva AWS proxy version 4.8.0 or later.
- To configure virtual machines for failover, ensure that you deploy the Druva AWS proxy with version 4.8.0 or later.
- For Production and Test Failover setups, you should separately configure failover settings. You can configure failover settings at DR plan-level and individual virtual machine-level. Depending upon the type selected for failover, the instance is launched using the corresponding settings.
- To create a failover request, you must have at least one Druva AWS proxy, which is deployed in the region of your DR plan and registered with Druva.
- For an optimized DR failover performance, choose an appropriate failover EC2 instance whose resources are equivalent to the source virtual machine if you are selecting the instance type manually. You must select t2.medium or larger instance types. t2.micro, and t2.small instance types are unsupported for DR failover. For example, if the source virtual machine has 8 vCPUs and 32 GB RAM, select an m5.2xlarge instance type for failover. You can use the View Recommendations feature to view instance type recommendations per VM. Druva recommends instance types on the basis of CPU, memory, AWS region, and operating system version of the VMs selected in the DR plan. You can also use the Auto Assign feature to let Druva automatically assign instance types to the selected VMs.
- After you initiate failover for virtual machines, you can check the status of the launched EC2 instances on the Jobs page and the Failover Instances tab.
- By default, AWS allows 20 EC2 instances per region. To increase the limit of running instances (more than 20) running at the same time in one region, you must get approval from Amazon. You can increase the instance limit for a specific region. Therefore, you must specify the region where you want to increase your instance limit. To request an increase in your limit, contact Amazon.
- The subnet settings configured for failover for each virtual machine should have reachability to AWS services, such as SQS and S3.
- The security group should be chosen appropriately if SSH or RDP is required.
- All instances launched in the public subnet must have public IP addresses and instances launched in the private subnet must not have public IP addresses.
- The elastic public IP addresses should be chosen based on the available elastic IP addresses in the AWS account.
- The static private IP addresses should be chosen appropriately based on the subnet’s CIDR block.
- IAM role attached to the Druva AWS proxy must have the same policies as that are available on the Management Console.
- The on-boot script in the recovery workflow should not contain commands to reboot the EC2 instances.
- DR failover does not support multiple NICs. Failover Instance will have only one NIC with Public-IP and Private-IP as configured in failover settings of the DR plan.
- Failover for Windows 2008 non R2 will work only with t2 instance type.
- Failover will launch EC2 Instance of BIOS firmware irrespective of the VM's firmware. If the VM's firmware is UEFI, then Failover EC2 Instance with BIOS firmware will be launched by performing appropriate modifications on the disks.