Skip to main content
Druva Documentation

About disaster recovery failover

Phoenix Editions: File:/cross.pngBusiness         File:/tick.png Enterprise     File:/tick.pngElite
(Purchase Separately)

Overview

In an event of an actual disaster or for testing purposes, Phoenix DRaaS Failover feature aims to recover virtual machines in the AWS account based on the configuration and failover settings specified in the DR plan.

DR_failover.jpg

  1. First, an administrator triggers the failover from the Phoenix Management Console and Phoenix Cloud instructs the Phoenix AWS proxy to initiate the failover.
  2. The EBS snapshot is used to create an EBS volume. The Phoenix AWS proxy creates an EC2 instance in your AWS account. You can choose the EC2 instance type from the Phoenix Management Console when you configure the VM for DR. The EBS volume gets attached to the EC2 instance.
  3. 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. 
  4. 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

Phoenix 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 type Description
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 Phoenix AWS Proxy version 4.7.6 or earlier. Or,
    • A DR copy, if you have deployed Phoenix AWS Proxy version 4.8.0 or later.
  • To configure virtual machines for failover, ensure that you deploy the Phoenix 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 Phoenix AWS proxy, which is deployed in the region of your DR plan and registered with Phoenix.  
  • 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 Phoenix AWS proxy must have the same policies as that are available on the Phoenix Management Console.
  • The on-boot script in the recovery workflow should not contain commands to reboot the EC2 instances.

Failover Limitations

  • 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.
  • The Asia Pacific (Hong Kong) region does not support the following instances for failover: t2, c4, m4, g2, g3, and i2.  A failover job triggered for any of these EC2 instances in the HongKong region will fail. Select instance type d2 and i3 instance families for HongKong region while configuring the DR failover setting.
  •  The Paris region supports only the following instances for failover: t2, t3, m5ad, m5d, m5, c5, g4dn, r5ad, r5a, r5, r4, d2, i3. A failover job triggered for any other EC2 instances in the Paris region will fail. Select instance type m4,i2,c4,g2, g3 instance families for the Paris region while configuring the DR failover setting.