Интеграция 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.

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

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

• каналы ExpressRoute;
• домены маршрутизации ExpressRoute;
• расположения ExpressRoute;
• архитектура репликации виртуальных машин Azure;
• Настройка репликации для виртуальных машин Azure.
• Как выполнить отработку отказа виртуальных машин Azure.

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

Чтобы обеспечить эффективное целевое время восстановления (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.

• Регион. Приложения развертываются в регионе 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 (Разрешить адрес виртуальной сети)	Включен
Из периферийной сети в центральную	Разрешить перенаправленный трафик	Включен
Из периферийной сети в центральную	Разрешить транзит шлюзов	Выключено
Из периферийной сети в центральную	Использовать удаленные шлюзы	Включен

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

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

Примеры шагов

В нашем примере при включении репликации для виртуальных машин 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-адреса отличаются, необходимо соответствующим образом скорректировать определяемые пользователем маршруты.

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

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

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

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

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