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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
Replication Policy: A replication policy defines the rules for replication, including how often data should be synchronized between the primary and secondary VMs.
-
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.
-
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.
-
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.
-
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.
Microsoft
