One of the most important features of a disaster recovery tool is failover readiness. Administrators ensure this by watching out for health signals from the product. Some also choose to set up their own monitoring solutions to track readiness. End to end testing is conducted using disaster recovery (DR) drills every three to six months. Azure Site Recovery offers this capability for replicated items and customers rely heavily on test failovers or planned failovers to ensure that the applications work as expected. With Azure Site Recovery, customers are encouraged to use non-production network for test failover so that IP addresses and networking components are available in the target production network in case of an actual disaster. Even with non-production network, the drill should be the exact replica of the actual failover.
Until now, it has been close to being the replica. The networking configurations for test failover did not entirely match the failover settings. Choice of subnet, network security group, internal load balancer, and public IP address per network interfacing controller (NIC) could not be made. This means that customer had to ensure a particular alphabetical naming convention of subnets in test failover network to ensure the replicated items are failed over as intended. This requirement conflicted with the organizations that enforce naming conventions for Azure resources. Also in case you wished to attach networking components, it was only possible manually post test failover operation. Further, if a customer tests the failover of an entire application via recovery plan, the Azure virtual network selection was applied to all the virtual machines irrespective of the application tier.
Test failover settings for networking resources
DR administrators of Azure Site Recovery now have a highly configurable setup for such operational activities. The network settings required for test failover are available for every replicated item. These settings are optional. If you skip it, old behavior will be applied where you can select the Azure virtual network at the time of triggering test failover.
You can go to Compute and Network blade and choose a test failover network. You can further update all the networking settings for each NIC. Only those settings can be updated that were configured on source at the time of enabling replication. The settings only allow you to choose a networking resource which is already created in the target location. Azure Site Recovery does not replicate the changes on networking resources at source. Read the full guidance on networking customization in Azure Site Recovery documentation.
At the time of initiating test failover via replicated item blade, you will no longer see the dropdown to choose Azure virtual network if the settings are pre-configured. If you initiate test failover via recovery plan, you will still see the dropdown to choose Vnet. However, the Vnet will be applied only to those machines that do not have settings pre-configured.
These settings are only available for Azure machines that are protected by Azure Site Recovery. Test failover settings for VMware and physical machines will be available in a couple of milestones.
Azure natively provides you the high availability and reliability for your mission-critical workloads, and you can choose to improve your protection and meet compliance requirements using the disaster recovery provided by Azure Site Recovery. Getting started with Azure Site Recovery is easy, check out pricing information, and sign up for a free Microsoft Azure trial. You can also visit the Azure Site Recovery forum on MSDN for additional information and to engage with other customers.
Related links and additional content
- Set up disaster recovery for Azure virtual machines
- Customize networking for test failovers
- Learn more about disaster recovery drills
Leave a Reply