Интеграция ExpressRoute со службой аварийного восстановления виртуальной машины Azure

  • Статья

В этой статье описывается, как интегрировать Azure ExpressRoute с Azure Site Recovery при настройке аварийного восстановления виртуальных машин Azure в дополнительный регион Azure.

Site Recovery позволяет выполнять аварийное восстановление виртуальных машин Azure с помощью репликации данных виртуальных машин Azure в Azure.

  • Если виртуальные машины Azure используют управляемые диски Azure, данные виртуальных машин реплика с реплика управляемым диском в дополнительном регионе.
  • Если виртуальные машины Azure не используют управляемые диски, то данные виртуальных машин реплицируются в учетную запись хранения Azure.
  • Конечные точки репликации являются общедоступными, но трафик репликации виртуальных машин Azure не проходит через Интернет.

ExpressRoute позволяет перенести локальные сети в облако Microsoft Azure по частному подключению, которое обеспечивается поставщиком услуг подключения. Если у вас настроен канал ExpressRoute, он интегрируется с Site Recovery следующим образом.

  • Во время репликации между регионами Azure. Трафик репликации для аварийного восстановления виртуальных машин Azure передается в пределах Azure, и подключение ExpressRoute не требуется или не используется для репликации. Однако если вы подключаетесь с локального сайта к виртуальным машинам Azure на основном сайте Azure, при настройке аварийного восстановления для этих виртуальных машин Azure возникает множество проблем.
  • Отработка отказа между регионами Azure. При возникновении сбоев выполняется отработка отказа виртуальных машин Azure из основного региона в дополнительный регион Azure. После отработки отказа в дополнительный регион необходимо выполнить много действий, чтобы получить доступ к виртуальным машинам Azure в дополнительном регионе с помощью ExpressRoute.

Подготовка к работе

Прежде чем начать, ознакомьтесь со следующими понятиями:

Общие рекомендации

Чтобы обеспечить эффективное целевое время восстановления (RTO) для аварийного восстановления при настройке Site Recovery для интеграции с ExpressRoute, рекомендуется сделать следующее.

  • Подготовьте сетевые компоненты перед отработкой отказа в дополнительный регион:
    • При включении репликации для виртуальных машин Azure служба Site Recovery может автоматически развертывать сетевые ресурсы, например сети, подсети и шлюзы, в целевом регионе Azure на основе параметров исходной сети.
    • Site Recovery не может автоматически настраивать сетевые ресурсы, например шлюзы виртуальной сети.
    • Мы рекомендуем подготовить эти дополнительные сетевые ресурсы перед выполнением отработки отказа. Это развертывание может вызвать небольшой простой, что может повлиять на общее время восстановления, если вы не учли его при планировании развертывания.
  • Выполните регулярные детализации аварийного восстановления:
    • Проверка отработки позволяет проверить стратегию репликации без потери данных и простоя и не влияет на рабочую среду. Это позволяет избежать проблем конфигурации, возникающих в последнюю минуту, которые могут отрицательно отразиться на значении RTO.
    • При выполнении тестовой отработки отказа мы рекомендуем использовать отдельную сеть виртуальных машин Azure, а не сеть по умолчанию, настроенную для репликации.
  • Используйте разные диапазоны IP-адресов, если используется отдельный канал ExpressRoute.
    • Мы рекомендуем использовать разные диапазоны IP-адресов для целевой виртуальной сети. Это позволяет избежать проблем при установлении подключений во время региональных сбоев.
    • Если нет возможности использовать отдельный диапазон адресов, обязательно используйте для тестовой отработки отказа для аварийного восстановления отдельную тестовую сеть с другими IP-адресами. Невозможно подключить две виртуальные сети с перекрывающимися диапазона IP-адресов к одному каналу ExpressRoute.

Репликация виртуальных машин в Azure с помощью ExpressRoute

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

  1. Включите репликацию для каждой виртуальной машины Azure.
  2. При необходимости разрешить Site Recovery настроить сеть:
    • При настройке и включении репликации Site Recovery настраивает, подсети и подсети шлюза в целевом регионе Azure в соответствии с инфраструктурой в исходном регионе. Site Recovery также сопоставляет исходную и целевую виртуальные сети.
    • Если вы не хотите, чтобы служба Site Recovery выполняла это автоматически, создайте сетевые ресурсы на целевой стороне перед включением репликации.
  3. Создайте другие сетевые элементы:
    • Site Recovery не создает таблицы маршрутов, шлюзы виртуальной сети, подключения шлюза виртуальной сети, пиринг виртуальных сетей или другие сетевые ресурсы и подключения в дополнительном регионе.
    • Перед запуском отработки отказа из основного региона необходимо создать эти дополнительные сетевые элементы в дополнительном регионе.
    • Чтобы настроить и подключить эти сетевые ресурсы, можно использовать планы восстановления и сценарии автоматизации.
  4. Если у вас есть виртуальная сеть (модуль) (NVA), развернутая для управления потоком сетевого трафика:
    • Для репликации виртуальных машин Azure платформа Azure по умолчанию использует системный маршрут 0.0.0.0/0.
    • В развертывании с виртуальным сетевым модулем обычно определяется маршрут по умолчанию (0.0.0.0/0), который передает на виртуальный сетевой модуль весь направленный в Интернет исходящий трафик. Маршрут по умолчанию используется в том случае, если не удалось найти иную конфигурацию маршрута.
    • Если это так, NVA может быть перегружен, если весь трафик реплика передачи через NVA.
    • Это ограничение действует и для маршрутов по умолчанию, которые направляют весь трафик виртуальных машин Azure к локальным развертываниям.
    • В этом случае рекомендуется создать конечную точку сетевой службы в виртуальной сети службы Microsoft.Storage, чтобы трафик репликации не покидал границ Azure.

Пример репликации

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

On-premises-to-Azure with ExpressRoute before failover

  • Регион. Приложения развертываются в регионе Azure "Восточная Азия".
  • Периферийные виртуальные сети. Приложения развертываются в двух периферийных виртуальных сетями:
    • исходная сеть vNet1: 10.1.0.0/24;
    • исходная сеть vNet2: 10.2.0.0/24.
    • Каждая периферийная виртуальная сеть подключена к центральной виртуальной сети.
  • Центральная виртуальная сеть. Исходная центральная виртуальная сеть: 10.10.10.0/24.
    • Эта центральная виртуальная сеть выступает в роли привратника.
    • Весь обмен данными между подсетями происходит через нее.
      • Подсети центральной виртуальной сети. Центральная виртуальная сеть содержит две подсети:
      • подсеть NVA: 10.10.10.0/25. Эта подсеть содержит виртуальный сетевой модуль (10.10.10.10).
      • Подсеть шлюза: 10.10.10.128/25. Эта подсеть содержит шлюз ExpressRoute, подключенный к каналу ExpressRoute, по которому данные передаются на локальный сайт через домен маршрутизации с частным пирингом.
  • Локальный центр обработки данных имеет подключение к каналу ExpressRoute через ребра партнера в Гонконге Специальный Администратор истативный регион.
  • Управление всей маршрутизацией осуществляется с помощью таблиц маршрутов Azure (UDR).
  • Весь исходящий трафик, передаваемый между виртуальными сетями или в локальный центр обработки данных, направляется через виртуальный сетевой модуль.

Параметры пиринга между центральной и периферийными сетями

Из периферийной сети в центральную

Направление Параметр Штат
Из периферийной сети в центральную Allow virtual network address (Разрешить адрес виртуальной сети) Включен
Из периферийной сети в центральную Разрешить перенаправленный трафик Включен
Из периферийной сети в центральную Разрешить транзит шлюзов Выключено
Из периферийной сети в центральную Использовать удаленные шлюзы Включен

Spoke to hub peering configuration

Из центральной сети в периферийную

Направление Параметр Штат
Из центральной сети в периферийную Allow virtual network address (Разрешить адрес виртуальной сети) Включен
Из центральной сети в периферийную Разрешить перенаправленный трафик Включен
Из центральной сети в периферийную Разрешить транзит шлюзов Включен
Из центральной сети в периферийную Использовать удаленные шлюзы Выключено

Hub to spoke peering configuration

Примеры действий

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

  1. Вы включаете репликацию для виртуальной машины.
  2. Site Recovery создает реплика виртуальные сети, подсети и подсети шлюза в целевом регионе.
  3. Служба Site Recovery сопоставит исходные сети и реплицируемые целевые сети, которые она создает.
  4. Вы вручную создаете таблицы маршрутов, шлюзы виртуальной сети, подключения через шлюз виртуальной сети, пиринг виртуальной сети и любые другие сетевые ресурсы или подключения.

Отработка отказа виртуальных машин в Azure с помощью ExpressRoute

После отработки отказа виртуальных машин Azure в целевой регион Azure с помощью Site Recovery они будут доступны с помощью частного пиринга ExpressRoute.

  • Требуется подключить ExpressRoute к целевой виртуальной сети с помощью нового подключения. Существующее подключение ExpressRoute не перенастраивается автоматически.
  • Способ настройки подключения ExpressRoute к целевой виртуальной сети зависит от топологии ExpressRoute.

Доступ по двум каналам

Два канала с двумя расположениями пиринга

Эта конфигурация помогает защитить каналы ExpressRoute от региональной аварии. Если произойдет авария в основном расположении пиринга, подключения смогут функционировать из другого расположения.

  • Канал, подключенный к рабочей среде, обычно является основным. Дополнительный канал обычно имеет меньшую пропускную способность, которую можно увеличить в случае аварии.
  • После отработки отказа можно установить подключения из дополнительного канала ExpressRoute к целевой виртуальной сети. Кроме того, можно заранее настроить и подготовить подключения на случай аварии, чтобы уменьшить общее время восстановления.
  • Если подключения к основной и целевой виртуальным сетям существуют одновременно, обязательно настройте локальную маршрутизацию таким образом, чтобы дополнительный канал и подключение использовались только после отработки отказа.
  • После отработки отказа исходная и целевая виртуальные сети могут получить новые IP-адреса или использовать прежние. В обоих вариантах есть возможность установить дополнительные подключения до отработки отказа.

Два канала с одним расположением пиринга

Эта конфигурация помогает защититься от сбоя основного канала ExpressRoute, но не в случае аварии единственного расположения пиринга ExpressRoute, которая влияет на оба канала.

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

Доступ с помощью одного канала

В этой конфигурации имеется только один канал ExpressRoute. Хотя канал имеет избыточное подключение в случае падения, один канал маршрута не обеспечит устойчивость, если пиринговая область исчезнет. Обратите внимание на следующие условия.

  • Если целевой регион Azure не находится в том же расположении, что и исходный регион, необходимо включить ExpressRoute Premium, если вы используете один канал ExpressRoute. Узнайте больше о расположениях ExpressRoute и ценах на ExpressRoute.
  • Невозможно одновременно подключить к каналу исходную и целевую виртуальные сети, если в целевом регионе используется такой же диапазон IP-адресов. В этом сценарии:
    • Разорвите подключение на стороне источника, а затем создайте подключение на стороне цели. Такую логику переключения можно реализовать в сценариях плана восстановления Site Recovery. Обратите внимание, что:
      • Если региональный сбой приведет к недоступности основного региона, операция отключения завершится неудачей. Это может повлиять на создание подключения к целевому региону.
      • Если подключение к целевому региону будет создано, а после этого восстановится подключение к основному региону, попытка одновременного подключения к двум одинаковым диапазонами адресов может привести к потере пакетов.
      • Чтобы избежать этого, немедленно завершите основное подключение.
      • Когда для виртуальных машин будет восстановлено размещение в основной регион, можно будет возобновить основное подключение, но только после отключения дополнительного подключения.
  • Если в целевой виртуальной сети используется другое адресное пространство, можно одновременно подключаться к исходным и целевым виртуальным сетям из одного канала ExpressRoute.

Пример отработки отказа

В примере мы используем следующую топологию.

  • Два канала ExpressRoute в двух разных расположениях пиринга.
  • Сохранение частных IP-адресов для виртуальных машин Azure после отработки отказа.
  • Целевой регион Azure для восстановления — "Юго-Восточная Азия".
  • Дополнительный канал ExpressRoute подключается через партнерский пограничный сервер в Сингапуре.

Простая топология, которая использует один канал ExpressRoute и сохраняет IP-адрес после отработки отказа, описана в этой статье.

Примеры действий

Чтобы автоматизировать восстановление в этом примере, нужно сделать следующее.

  1. Следуйте инструкциям по настройке репликации.

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

    a. Создайте шлюз Azure ExpressRoute в центральной виртуальной сети в целевом регионе. Он необходим для подключения центральной виртуальной сети в целевом регионе к каналу ExpressRoute.

    b. Создайте подключение центральной виртуальной сети в целевом регионе к целевому каналу ExpressRoute.

    c. Настройте пиринг виртуальных сетей между виртуальной сетью концентратора и периферийными виртуальными сетями в целевом регионе. Свойства пиринга в целевом регионе совпадают с свойствами исходного региона.

    d. Настройте определяемые пользователем маршруты в виртуальной сети концентратора и в обоих периферийных виртуальных сетях.

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

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

После восстановления

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

On-premises-to-Azure with ExpressRoute after Failover

Следующие шаги

Узнайте больше об использовании планов восстановления для автоматизации отработки отказа.