Расширение возможностей аварийного восстановления виртуальных машин Azure с помощью Azure Site Recovery и Terraform

Azure предоставляет комплексные решения для резервного копирования и аварийного восстановления, которые просты в использовании, безопасны, масштабируемы и недороги. Их также можно легко интегрировать с существующими локальными системами защиты данных.

В этой статье мы рассмотрим практическую демонстрацию реализации аварийного восстановления виртуальной машины с использованием репликации виртуальной машины Azure Site Recovery через Terraform. Такой подход обеспечивает непрерывность работы ваших бизнес-приложений и рабочих нагрузок во время непредвиденных сбоев, обеспечивая простую репликацию ваших виртуальных машин из одного места в другое.

Восстановление сайта Azure

Site Recovery помогает обеспечить непрерывность бизнеса, поддерживая работу бизнес-приложений и рабочих нагрузок во время сбоев. Site Recovery реплицирует рабочие нагрузки, выполняемые на физических и виртуальных машинах (ВМ), с основного сайта на дополнительный. Когда на вашем основном сайте происходит сбой, вы переключаетесь на дополнительный сайт и получаете доступ к приложениям оттуда. После того как основное расположение снова заработает, вы можете вернуться к нему.

Вариант использования и архитектура

Наш вариант использования — репликация виртуальной машины с помощью Site Recovery, поэтому в случае сбоя мы можем выполнить отработку отказа на дополнительную виртуальную машину, которая будет доступна с использованием того же полного доменного имени и общедоступного IP-адреса, что и первая. Вторую виртуальную машину следует реплицировать в другой регион.

Архитектура реализации аварийного восстановления виртуальных машин Azure с использованием Azure Site Recovery и Terraform включает несколько ключевых компонентов и шагов:

1. Виртуальные машины (ВМ): это основные рабочие нагрузки, которые необходимо защитить и реплицировать во вторичное расположение. Виртуальные машины работают в инфраструктуре Azure и являются основными компонентами системы.

2. Терраформировать: Terraform используется в качестве инфраструктуры и инструмента кода для предоставления ресурсов Azure и управления ими. Он обеспечивает декларативный подход для определения желаемого состояния инфраструктуры и обеспечивает простоту репликации и управления ресурсами.

3. Восстановление сайта Azure (ASR): ASR — это служба Microsoft, которая организует и автоматизирует процесс аварийного восстановления виртуальных машин Azure. Он обеспечивает непрерывность бизнеса за счет репликации виртуальных машин из основного региона Azure в дополнительный регион.

4. Хранилище восстановления: Recovery Vault — это центральный компонент ASR, в котором хранятся параметры конфигурации для репликации, переключения при сбое и восстановления. Он действует как центр управления процессом аварийного восстановления.

5. Первичные и вторичные регионы: Архитектура включает как минимум два региона Azure: основной регион, где находятся исходные виртуальные машины, и дополнительный регион, где будут храниться реплицированные виртуальные машины.

6. Политика репликации: политика репликации определяет правила репликации, в том числе частоту синхронизации данных между основной и вторичной виртуальными машинами.

7. Сетевая инфраструктура: виртуальные сети и подсети настраиваются как в основном, так и в дополнительном регионе, чтобы облегчить связь между виртуальными машинами и обеспечить бесперебойную работу процесса репликации.

8. Управляемые диски: ОС и диски данных виртуальной машины реплицируются в учетную запись хранения дополнительного региона. Управляемые диски обеспечивают высокую доступность и надежность хранения данных.

9. Тестирование отказоустойчивости: Прежде чем произойдет сбой, важно выполнить тестирование отработки отказа, чтобы убедиться, что процесс репликации работает должным образом и что приложения могут успешно работать в дополнительном регионе.

10. Аварийное переключение и восстановление после отказа: в случае сбоя выполняется операция аварийного переключения для переключения приложений с основных виртуальных машин на реплицированные виртуальные машины в дополнительном регионе. После восстановления основного региона можно выполнить операцию восстановления, чтобы вернуться к исходным настройкам.

Таким образом, архитектура использует инфраструктуру Terraform в качестве возможностей кода для настройки необходимых ресурсов Azure, включая виртуальные машины, учетные записи хранения, виртуальные сети и подсети. Azure Site Recovery организует процессы репликации, отработки отказа и восстановления после сбоев, чтобы обеспечить непрерывность бизнеса и аварийное восстановление виртуальных машин Azure. Четко определенный рабочий процесс и автоматизация, обеспечиваемые этими службами, обеспечивают отказоустойчивое и надежное решение для аварийного восстановления виртуальных машин Azure.

Преимущество использования Site Recovery в том, что вторая виртуальная машина не работает, поэтому мы платим не за вычислительные ресурсы, а только за хранилище и трафик в дополнительный регион.

Пример реализации

Перед началом у вас уже должны быть развернуты виртуальная сеть и подсеть.

Прежде всего мы развернем нашу виртуальную машину с общедоступным 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"
}

После развертывания виртуальной машины мы развернем Recovery Vault для использования службы 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"
}

Затем мы развернем ткань восстановления и контейнер защиты.

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
}

Определим политику репликации

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
}

Мы сопоставим исходный контейнер с целевым.

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
}

Теперь мы развернем виртуальную сеть и подсеть, в которых будем реплицировать или основную виртуальную машину, еще одну для проверки отработки отказа и промежуточную учетную запись хранения для репликации данных.

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"
  }
}

Наконец, мы развернем нашу реплицированную виртуальную машину.

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
    
  }
}

После развертывания ресурсов мы можем проверить их в Azure Portal Recovery Vault и выполнить тестовую отработку отказа:

И вуаля! Ваша виртуальная машина реплицируется во второй регион и сохранит то же полное доменное имя и общедоступный IP-адрес в случае сбоя в регионе при выполнении отработки отказа вручную, которую можно автоматизировать с помощью Azure Monitor и учетной записи автоматизации.

Заключение

В заключение, настройка аварийного восстановления виртуальных машин Azure с помощью Azure Site Recovery и Terraform помогает предприятиям защитить свою важную работу и обеспечить бесперебойную работу. Используя простой способ управления ресурсами Terraform и функции автоматического аварийного восстановления Azure Site Recovery, компании могут легко реплицировать виртуальные машины в другое место.

Такой подход гарантирует, что даже если что-то пойдет не так или возникнет проблема, приложения и данные будут в безопасности. В случае аварии процесс аварийного переключения позволяет предприятиям переключиться на реплицированные виртуальные машины в другом регионе, сводя к минимуму время простоя и потерю данных.

Сочетание Azure Site Recovery и Terraform делает настройку аварийного восстановления экономичной и простой в управлении. Компании могут сосредоточиться на стратегических задачах, а не тратить время на восстановление вручную.

Благодаря этому решению компании могут быть хорошо подготовлены к неожиданным сбоям, обеспечивая бесперебойную работу своих сервисов и защищая важные данные. Внедрение аварийного восстановления виртуальных машин Azure с помощью Azure Site Recovery и Terraform — разумный выбор для обеспечения непрерывности бизнеса и спокойствия.