Empowering Disaster Recovery for Azure VMs with Azure Site Recovery and Terraform

Azure provides comprehensive backup and disaster recovery solutions that are easy to use, secure, scalable, and budget-friendly. They can also be seamlessly integrated with existing on-premises data protection setups.

 

In this article, we'll explore a practical demonstration of implementing Virtual Machine Disaster Recovery using Azure Site Recovery VM Replication through Terraform. This approach ensures the continuity of your business apps and workloads during unexpected outages, replicating your virtual machines from one location to another in a straightforward manner.

 

Azure Site Recovery

 

Site Recovery helps ensure business continuity by keeping business apps and workloads running during outages. Site Recovery replicates workloads running on physical and virtual machines (VMs) from a primary site to a secondary location. When an outage occurs at your primary site, you fail over to secondary location, and access apps from there. After the primary location is running again, you can fail back to it.

 

Use Case and architecture

 

Our use case is to replicate a VM using Site Recovery, so in case we have a failure, we can failover to a secondary VM that will be available using the same FQDN and Public IP as the first one. The second VM should be replicated to a different Region.

 

The architecture of implementing Azure VM Disaster Recovery using Azure Site Recovery and Terraform involves several key components and steps:

 

1. Virtual Machines (VMs): These are the primary workloads that need to be protected and replicated to a secondary location. The VMs run on Azure infrastructure and are the core components of the system.

2. Terraform: Terraform is used as the infrastructure as code tool to provision and manage Azure resources. It provides a declarative approach to define the desired state of the infrastructure and enables easy replication and management of resources.

3. Azure Site Recovery (ASR): ASR is a Microsoft service that orchestrates and automates the disaster recovery process for Azure VMs. It ensures business continuity by replicating VMs from a primary Azure region to a secondary region.

4. Recovery Vault: A Recovery Vault is a central component in ASR that holds the configuration settings for replication, failover, and recovery. It acts as a control center for managing the disaster recovery process.

5. Primary and Secondary Regions: The architecture involves at least two Azure regions: the primary region where the original VMs reside and the secondary region where the replicated VMs will be stored.

6. Replication Policy: A replication policy defines the rules for replication, including how often data should be synchronized between the primary and secondary VMs.

7. Network Infrastructure: Virtual Networks and Subnets are set up in both the primary and secondary regions to facilitate communication between VMs and ensure that the replication process works seamlessly.

8. Managed Disks: The VM's OS and data disks are replicated to the secondary region's Storage Account. Managed Disks provide high availability and reliability for data storage.

9. Failover Testing: Before a disaster occurs, it's essential to perform failover testing to ensure that the replication process works as expected and that applications can run successfully in the secondary region.

10. Failover and Failback: In the event of a disaster, a failover operation is executed to switch the applications from the primary VMs to the replicated VMs in the secondary region. After the primary region is restored, a failback operation can be performed to return to the original setup.

In summary, the architecture leverages Terraform's infrastructure as code capabilities to set up the necessary Azure resources, including VMs, Storage Accounts, Virtual Networks, and Subnets. Azure Site Recovery orchestrates the replication, failover, and failback processes to ensure business continuity and disaster recovery for Azure VMs. The well-defined workflow and automation provided by these services enable a resilient and reliable disaster recovery solution for Azure Virtual Machines.

 

The advantage of using Site Recovery is that the second VM is not running, so we do not pay for the computing resources but only for the storage and traffic to the secondary region.

 

Implementation example

 

Before starting you should already have a VNET and Subnet deployed.

 

First of all we will deploy our virtual machine with a public IP:

 

 

data "azurerm_subnet" "snet-backend" { depends_on = [var.subnets] name = var.vm.snet_name virtual_network_name = var.vm.vnet_name resource_group_name = var.resource_group } resource "azurerm_public_ip" "pip-vm-app" { name = "pip-app" location = var.location resource_group_name = var.resource_group allocation_method = "Static" idle_timeout_in_minutes = 30 domain_name_label = var.vm.fqdn tags = { environment = "test" } } resource "azurerm_network_interface" "main" { name = var.vm.nic_name location = var.location resource_group_name = var.resource_group ip_configuration { name = "testconfiguration1" subnet_id = data.azurerm_subnet.snet-backend.id private_ip_address_allocation = "Dynamic" public_ip_address_id = azurerm_public_ip.pip-vm-app.id } } resource "azurerm_virtual_machine" "main" { name = var.vm.name location = var.location resource_group_name = var.resource_group network_interface_ids = [azurerm_network_interface.main.id] vm_size = var.vm.size # Uncomment this line to delete the OS disk automatically when deleting the VM # delete_os_disk_on_termination = true # Uncomment this line to delete the data disks automatically when deleting the VM # delete_data_disks_on_termination = true storage_image_reference { publisher = var.vm.storage_image_reference.publisher offer = var.vm.storage_image_reference.offer sku = var.vm.storage_image_reference.sku version = var.vm.storage_image_reference.version } storage_os_disk { name = "disk-${var.vm.name}-os" caching = var.vm.storage_os_disk.caching create_option = var.vm.storage_os_disk.create_option managed_disk_type = var.vm.storage_os_disk.managed_disk_type } os_profile { computer_name = var.vm.os_profile.computer_name admin_username = var.vm.os_profile.admin_username admin_password = var.vm.os_profile.admin_password #custom_data = file(var.vm.os_profile.custom_data) } os_profile_linux_config { disable_password_authentication = false } boot_diagnostics { enabled = true storage_uri = "https://${var.storage_account.name}.blob.core.windows.net" } tags = var.tags } resource "azurerm_managed_disk" "disk-data-app" { name = "disk-${azurerm_virtual_machine.main.name}-data" location = var.location resource_group_name = var.resource_group storage_account_type = "StandardSSD_LRS" create_option = "Empty" disk_size_gb = var.vm.storage_data_disk.disk_size_gb } resource "azurerm_virtual_machine_data_disk_attachment" "example" { managed_disk_id = azurerm_managed_disk.disk-data-app.id virtual_machine_id = azurerm_virtual_machine.main.id lun = var.vm.storage_data_disk.lun caching = "ReadWrite" }

 

 

Once the VM is deployed we will deploy a Recovery Vault to use the service Site Recovery

 

 

data "azurerm_resource_group" "secondary" { name =var.resource_group_secondary } data "azurerm_resource_group" "primary" { name =var.resource_group } resource "azurerm_recovery_services_vault" "vault" { name = "rv-app-${var.region_secondary}-${var.environment}" location = var.location_secondary resource_group_name = data.azurerm_resource_group.secondary.name sku = "Standard" }

 

 

Then we will deploy a recovery fabric and a protection container

 

 

resource "azurerm_site_recovery_fabric" "primary" { name = "primary-fabric" resource_group_name = data.azurerm_resource_group.secondary.name recovery_vault_name = azurerm_recovery_services_vault.vault.name location = data.azurerm_resource_group.primary.location } resource "azurerm_site_recovery_fabric" "secondary" { name = "secondary-fabric" resource_group_name = data.azurerm_resource_group.secondary.name recovery_vault_name = azurerm_recovery_services_vault.vault.name location = var.location_secondary } resource "azurerm_site_recovery_protection_container" "primary" { name = "primary-protection-container" resource_group_name = data.azurerm_resource_group.secondary.name recovery_vault_name = azurerm_recovery_services_vault.vault.name recovery_fabric_name = azurerm_site_recovery_fabric.primary.name } resource "azurerm_site_recovery_protection_container" "secondary" { name = "secondary-protection-container" resource_group_name = data.azurerm_resource_group.secondary.name recovery_vault_name = azurerm_recovery_services_vault.vault.name recovery_fabric_name = azurerm_site_recovery_fabric.secondary.name }

 

 

We will define a replication policy

 

 

resource "azurerm_site_recovery_replication_policy" "policy" { name = "policy" resource_group_name = data.azurerm_resource_group.secondary.name recovery_vault_name = azurerm_recovery_services_vault.vault.name recovery_point_retention_in_minutes = 24 * 60 application_consistent_snapshot_frequency_in_minutes = 4 * 60 }

 

 

We will map the source container with the target

 

 

resource "azurerm_site_recovery_protection_container_mapping" "container-mapping" { name = "container-mapping" resource_group_name = data.azurerm_resource_group.secondary.name recovery_vault_name = azurerm_recovery_services_vault.vault.name recovery_fabric_name = azurerm_site_recovery_fabric.primary.name recovery_source_protection_container_name = azurerm_site_recovery_protection_container.primary.name recovery_target_protection_container_id = azurerm_site_recovery_protection_container.secondary.id recovery_replication_policy_id = azurerm_site_recovery_replication_policy.policy.id }

 

 

Now we will deploy a VNET and Subnet were we will replicate or main Virtual Machine, another one to test the failover and a staging storage account for data replication.

 

 

resource "random_string" "lower" { length = 4 upper = false lower = true number = true special = false } resource "azurerm_storage_account" "primary" { name = "prireccache${random_string.lower.result}" location = var.location resource_group_name = var.resource_group account_tier = "Standard" account_replication_type = "LRS" } resource "azurerm_virtual_network" "secondary" { name = "vnet-app" resource_group_name = data.azurerm_resource_group.secondary.name address_space = var.vnet.address_space location = var.location_secondary } resource "azurerm_subnet" "secondary" { name = "snet-backend" resource_group_name = data.azurerm_resource_group.secondary.name virtual_network_name = azurerm_virtual_network.secondary.name address_prefix = var.vnet.subnets[0].address_prefix } resource "azurerm_virtual_network" "test-failover" { name = "vnet-app-test-failover" resource_group_name = data.azurerm_resource_group.secondary.name address_space = [var.vnet.address_space_failover_test[0]] location = var.location_secondary } resource "azurerm_subnet" "test-failover" { name = var.vnet.subnets_failover_test[0].name resource_group_name = data.azurerm_resource_group.secondary.name virtual_network_name = azurerm_virtual_network.test-failover.name address_prefix = var.vnet.subnets_failover_test[0].address_prefix } resource "azurerm_network_interface" "vm" { name = "vm-nic" location = var.location_secondary resource_group_name = data.azurerm_resource_group.secondary.name ip_configuration { name = "nic-vm-app-01" subnet_id = azurerm_subnet.secondary.id private_ip_address_allocation = "Dynamic" } }

 

 

Finally we will deploy our replicated VM

 

 

resource "azurerm_site_recovery_replicated_vm" "vm-replication" { name = "vm-replication" resource_group_name = data.azurerm_resource_group.secondary.name recovery_vault_name = azurerm_recovery_services_vault.vault.name source_recovery_fabric_name = azurerm_site_recovery_fabric.primary.name source_vm_id = azurerm_virtual_machine.main.id recovery_replication_policy_id = azurerm_site_recovery_replication_policy.policy.id source_recovery_protection_container_name = azurerm_site_recovery_protection_container.primary.name target_resource_group_id = data.azurerm_resource_group.secondary.id target_recovery_fabric_id = azurerm_site_recovery_fabric.secondary.id target_recovery_protection_container_id = azurerm_site_recovery_protection_container.secondary.id managed_disk { disk_id = azurerm_virtual_machine.main.storage_os_disk[0].managed_disk_id staging_storage_account_id = azurerm_storage_account.primary.id target_resource_group_id = data.azurerm_resource_group.secondary.id target_disk_type = var.vm.storage_os_disk.managed_disk_type target_replica_disk_type = var.vm.storage_os_disk.managed_disk_type } managed_disk { disk_id = azurerm_managed_disk.disk-data-app.id staging_storage_account_id = azurerm_storage_account.primary.id target_resource_group_id = data.azurerm_resource_group.secondary.id target_disk_type = "StandardSSD_LRS" target_replica_disk_type = "StandardSSD_LRS" } target_network_id = azurerm_virtual_network.secondary.id network_interface { source_network_interface_id = azurerm_network_interface.main.id target_static_ip = azurerm_public_ip.pip-vm-app.id } }

 

 

Once we have deployed the resources, we can verify in the Azure Portal Recovery Vault and do a test failover:

 

And voila! Your VM is replicated to a second region and will keep the same FQDN and public IP in the case of a region outage when performing a manual failover, which can be automated using Azure Monitor and a Automation Account.

 

Conclusion

In conclusion, setting up Azure VM Disaster Recovery with Azure Site Recovery and Terraform helps businesses protect their important work and keep their operations running smoothly. By using Terraform's simple way to manage resources and Azure Site Recovery's automatic disaster recovery features, companies can easily replicate VMs to another location.

 

This approach ensures that even if something goes wrong or there's a problem, the applications and data are safe. When a disaster happens, the failover process lets businesses switch to the replicated VMs in a different region, minimizing downtime and data loss.

 

The combination of Azure Site Recovery and Terraform makes it cost-effective and easy to manage the disaster recovery setup. Businesses can focus on strategic tasks instead of spending time on manual recovery efforts.

 

With this solution, businesses can be well-prepared for unexpected disruptions, keeping their services up and running and protecting their important data. Implementing Azure VM Disaster Recovery with Azure Site Recovery and Terraform is a smart choice to ensure business continuity and peace of mind.