Сохранение IP-адресов во время отработки отказа

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

Рекомендуем, чтобы во время отработки отказа IP-адреса в целевом регионе оставались идентичными адресам в исходном регионе:

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

В этой статье представлены примеры сохранения IP-адресов в более сложных сценариях. Примеры:

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

Ресурсы в Azure: полная отработка отказа

Компания А запускает все свои приложения в Azure.

До отработки отказа

Примечание.

Теперь можно выполнить репликацию между двумя регионами Azure по всему миру. Клиенты больше не ограничены в выборе места репликации на своем континенте.

Ниже представлена архитектура до отработки отказа.

• У компании А есть идентичные сети и подсети в исходном и целевом регионах Azure.
• Чтобы сократить целевое время восстановления (RTO), компания использует узлы реплики для Always On в SQL Server, контроллеров домена и т. д. Эти узлы реплики находятся в другой виртуальной сети в целевом регионе, поэтому они могут устанавливать соединение VPN типа "сеть — сеть" между исходным и целевым регионами. Это невозможно, если в исходном и целевом регионах используется один и тот же диапазон IP-адресов.
• Перед отработой отказа сетевая архитектура выглядит следующим образом:
  • Основной регион — Восточная Азия Azure
    • В Восточной Азии находится виртуальная сеть (Исходная виртуальная сеть) с диапазоном адресов 10.1.0.0/16.
    • Восточная Азия имеет рабочие нагрузки, разделенные на три подсети в виртуальной сети:
      • Подсеть 1: 10.1.1.0/24
      • Подсеть 2: 10.1.2.0/24
      • Подсеть 3: 10.1.3.0/24
  • Дополнительный (целевой) регион — Юго-Восточная Азия Azure
    • В Юго-Восточной Азии есть виртуальная сеть восстановления (Виртуальная сеть восстановления), идентичная исходной виртуальной сети.
    • В Юго-Восточной Азии есть дополнительная виртуальная сеть (Виртуальная сеть Azure) с диапазоном адресов 10.2.0.0/16.
    • Виртуальная сеть Azure содержит подсеть (Подсеть 4) с диапазоном адресов 10.2.4.0/24.
    • Узлы реплик для Always On в SQL Server, контроллера домена и других компонентов находятся в подсети 4.
  • Исходная виртуальная сеть и виртуальная сеть Azure соединены с помощью VPN-подключения типа "сеть — сеть".
  • Виртуальная сеть для аварийного восстановления не соединена с виртуальной сетью.
  • Компания A назначает и проверяет целевые IP-адреса реплицированных элементов. Целевой IP-адрес аналогичен исходному IP-адресу каждой виртуальной машины.

После отработки отказа

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

• Подготовив целевые IP-адреса до отработки отказа, компания А может организовать отработку отказа и автоматически установить соединения между виртуальной сетью восстановления и виртуальной сетью Azure после отработки отказа. Это показано на приведенной ниже схеме.
• В зависимости от требований приложения, подключения между двумя сетями (виртуальной сетью восстановления и виртуальной сетью Azure) в целевом регионе могут быть установлены до, во время (в качестве промежуточного шага) или после отработки отказа.

  • Компания может использовать планы восстановления, чтобы указать, когда будут устанавливаться подключения.

  • Соединять виртуальные сети можно с помощью пирингового подключения или VPN типа "сеть — сеть".

    • При пиринге виртуальных сетей не используется VPN-шлюз и применяются другие ограничения.
    • Цены на пиринг виртуальных сетей рассчитываются не так, как цены на VPN-шлюз "виртуальная сеть — виртуальная сеть". Для отработки отказа мы обычно рекомендуем использовать тот же способ соединения, что и в целевых сетях (в том числе тип подключения), чтобы свести к минимуму количество непредсказуемых сетевых инцидентов.

    

Ресурсы Azure: отработка отказа изолированных приложений

Вам может потребоваться выполнить отработку отказа на уровне приложения. Например, можно выполнить отработку отказа определенного приложения или уровня приложений, расположенного в выделенной подсети.

• В данном случае, несмотря на то что вы можете сохранить IP-адреса, обычно это не рекомендуется, так как повышается риск несогласованности подключений. Кроме того, будут потеряны подключения между подсетями в пределах одной виртуальной сети Azure.
• Лучший способ отработки отказа на уровне подсети — использовать другие целевые IP-адреса для отработки отказа (если вам нужно подключение к другим подсетям в исходной виртуальной сети) или изолировать каждое приложение в собственной выделенной виртуальной сети в исходном регионе. С помощью последнего подхода можно установить соединение между сетями в исходном регионе и эмулировать такое же поведение при переходе в целевой регион.

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

До отработки отказа

Перед отработкой отказа используется следующая архитектура:

• Виртуальные сети приложений размещаются в основном регионе Azure "Восточная Азия":

  • Виртуальные машины App1 находятся в виртуальной сети 1: 10.1.0.0/16.
  • Виртуальные машины App2 находятся в виртуальной сети 2: 10.2.0.0/16.
  • Исходная виртуальная сеть 1 содержит две подсети.
  • Исходная виртуальная сеть 2 содержит две подсети.

• Дополнительный (целевой) регион Azure — "Юго-Восточная Азия" — содержит виртуальные сети восстановления (виртуальная сеть восстановления 1 и виртуальная сеть восстановления 2), идентичные исходной виртуальной сети 1 и исходной виртуальной сети 2. - Виртуальная сеть восстановления 1 и виртуальная сеть восстановления 2 содержат по две подсети, соответствующие подсетям в исходной виртуальной сети 1 и исходной виртуальной сети 2. В Юго-Восточной Азии имеется дополнительная виртуальная сеть (виртуальная сеть Azure VNet) с диапазоном адресов 10.3.0.0/16. - Виртуальная сеть Azure содержит подсеть (Подсеть 4) с диапазоном адресов 10.3.4.0/24. - Узлы реплик для Always On в SQL Server, контроллера домена и других компонентов находятся в подсети 4.

• Существует ряд VPN-подключений типа "сеть — сеть":

  • исходная виртуальная сеть 1 и виртуальная сеть Azure;
  • исходная виртуальная сеть 2 и виртуальная сеть Azure;
  • исходная виртуальная сеть 1 и исходная виртуальная сеть 2 соединены при помощи VPN типа "сеть — сеть".

• Виртуальная сеть восстановления 1 и виртуальная сеть восстановления 2 не подключены к другим виртуальным сетям.

• Компания А настраивает VPN-шлюзы в виртуальной сети восстановления 1 и виртуальной сети восстановления 2, чтобы снизить RTO.

• Чтобы сократить целевое время восстановления, VPN-шлюзы настраиваются в сетях Recovery VNet1 и Recovery VNet2 до отработки отказа.

  

После отработки отказа

В случае сбоя или проблемы, затрагивающей одно приложение (в нашем примере оно находится в **исходной виртуальной сети 2), компания А может восстановить это приложение описанным ниже способом.

• Закройте VPN-подключения между исходной виртуальной сетью 1 и исходной виртуальной сетью 2, а также между исходной виртуальной сетью 2 и виртуальной сетью Azure.
• Установите VPN-подключения между исходной виртуальной сетью 1 и виртуальной сетью восстановления 2, а также между виртуальной сетью восстановления 2 и виртуальной сетью Azure.
• Выполните отработку отказа виртуальных машин из исходной виртуальной сети 2 в виртуальную сеть восстановления 2.

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

Гибридные ресурсы: полная отработка отказа

В этом сценарии компания Б представляет собой гибридное предприятие, часть инфраструктуры которого работает в Azure, а остальная часть — в локальной среде.

До отработки отказа

Ниже показана архитектура сети перед выполнением отработки отказа.

• Виртуальные сети приложений размещаются в регионе Azure "Восточная Азия".
• В Восточной Азии находится виртуальная сеть (Исходная виртуальная сеть) с диапазоном адресов 10.1.0.0/16.
  • Восточная Азия имеет рабочие нагрузки, разделенные по трем подсетям в исходной виртуальной сети:
    • Подсеть 1: 10.1.1.0/24
    • Подсеть 2: 10.1.2.0/24
    • Подсеть 3: 10.1.3.0/24 с использованием виртуальной сети Azure с диапазоном адресов 10.1.0.0/16. Это исходная виртуальная сеть.
• Дополнительный (целевой) регион — Это Юго-Восточная Азия Azure:
  • В Юго-Восточной Азии есть виртуальная сеть восстановления (Виртуальная сеть восстановления), идентичная исходной виртуальной сети.
• Виртуальные машины в Азиатско-Тихоокеанском регионе подключаются к локальному центру обработки данных через Azure ExpressRoute или соединение VPN типа "сеть — сеть".
• Чтобы сократить RTO, компания Б подготавливает шлюзы в Recovery VNet в регионе Azure "Юго-Восточная Азия" до отработки отказа.
• Компания Б назначает и проверяет целевые IP-адреса реплицированных виртуальных машин. Целевой IP-адрес совпадает с исходным IP-адресом каждой виртуальной машины.

После отработки отказа

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

• Подготовив целевые IP-адреса до отработки отказа, компания Б может организовать отработку отказа и автоматически установить соединения между виртуальной сетью восстановления и виртуальной сетью Azure после отработки отказа.
• В зависимости от требований приложения, подключения между двумя сетями (виртуальной сетью восстановления и виртуальной сетью Azure) в целевом регионе могут быть установлены до, во время (в качестве промежуточного шага) или после отработки отказа. Компания может использовать планы восстановления, чтобы указать, когда будут устанавливаться подключения.
• Исходное соединение между регионом Azure "Восточная Азия" и локальным центром обработки данных должно быть отключено, прежде чем устанавливать связь между регионом Azure ''Юго-Восточная Азия'' и локальным центром обработки данных.
• Локальная маршрутизация перенастраивается, чтобы указать на целевой регион и шлюз после отработки отказа.

Гибридные ресурсы: отработка отказа изолированных приложений

Компания Б не может выполнять отработку отказа изолированных приложений на уровне подсети. Это связано с тем, что диапазоны адресов в исходной и восстановленной виртуальных сетях совпадают, а подключение между источником и локальной средой активно.

• Для обеспечения устойчивости приложений компания Б должна будет поместить каждое приложение в собственную выделенную виртуальную сеть Azure.
• Когда каждое приложение будет находиться в отдельной виртуальной сети, компания Б может выполнять отработку отказа и направлять исходные подключения в целевой регион.

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

Узнайте о планах восстановления.