Что такое SDN Multisite?

В этой статье представлен обзор системы SDN Multisite, включая ее преимущества и текущие ограничения. Его можно использовать в качестве руководства для разработки топологии сети и плана аварийного восстановления.

SDN Multisite позволяет расширить возможности традиционных SDN, развернутых в различных географических местах. Мультисайт SDN обеспечивает естественную связь уровня L2 и уровня L3 между различными физическими расположениями для виртуализированных рабочих нагрузок. В этой статье все ссылки на сайты означают физические расположения.

Льготы

Ниже приведены преимущества использования sdN Multisite:

• Унифицированная система управления политиками. С помощью общих виртуальных сетей и конфигураций политик вы можете управлять и настраивать многосайтовые сети с любого сайта.
• Бесшовная миграция рабочей нагрузки. Беспрепятственно переносите рабочие нагрузки на физические сайты без необходимости перенастройки IP-адресов или существующих групп защиты сети (NSG).
• Автоматический доступ к новым виртуальным машинам. Получите автоматический доступ к новым виртуальным машинам (VM) в виртуальных сетях, а также автоматическое управление всеми связанными с ними группами безопасности сети во всех ваших физических расположениях.

Ограничения

В настоящее время функция SDN Multisite имеет несколько ограничений:

• Поддерживается только между двумя сайтами.
• Сайты должны быть подключены через частную сеть, так как поддержка шифрования сайтов, подключенных через Интернет, не предоставляется.
• Внутренняя балансировка нагрузки не поддерживается между сайтами.
• Развертывание и управление мультисайтами с помощью собственного SDN, также известного как сетевой контроллер в отказоустойчивом кластере, поддерживается только с помощью PowerShell.

Межсайтовый пиринг

В следующих разделах описаны роли каждого сайта в многосайтовой среде, а также способы обработки и синхронизации ресурсов между сайтами.

Основные и вторичные роли сайта

В среде SDN с несколькими сайтами один сайт назначается в качестве основного и другого в качестве дополнительного. Основной сайт обрабатывает синхронизацию ресурсов. Во время многосайтового пиринга основной сайт автоматически выбирается, который можно изменить позже с помощью Центра администрирования Windows.

Обработка ресурсов

• Если первичный сайт недоступен, глобальные ресурсы и ресурсы, требующие глобальной проверки или глобального распределения адресов клиентов (ЦС), не могут быть обновлены через дополнительный сайт. Однако другие локальные ресурсы можно обновить с помощью дополнительного сайта.

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

  • Пулы MAC.
  • Логический пул сети или IP-адресов.

  Примеры глобальных выделений ЦС:

  • Внутренняя балансировка нагрузки для виртуальной подсети. В настоящее время это не поддерживается через Multisite.
  • Соединения шлюза для виртуальной подсети.

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

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

Синхронизация ресурсов

При включении sdN Multisite не все ресурсы каждого сайта синхронизируются на всех сайтах. Ниже приведены списки ресурсов, синхронизированных и которые остаются несинхронизированными.

• Несинхронизированные ресурсы

  Эти ресурсы не синхронизируются после установления пиринга.

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

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

Восточно-западный поток трафика и совместное использование подсети

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

В следующих сценариях сравнивается настройка обмена данными между двумя физическими сайтами в традиционной настройке SDN и многосайтовой настройке SDN.

Связь между виртуальными машинами без SDN Multisite.

В традиционной настройке с SDN, развернутой на двух физических сайтах, необходимо установить подключение шлюза L3 или GRE для взаимодействия между сайтами. Кроме того, необходимо предоставить дополнительные подсети для приложений. Например, если каждый сайт размещает интерфейсные приложения, вы выделяете отдельные диапазоны подсети, такие как 10.1/16 и 10.6/16. Кроме того, при настройке подключения к шлюзу необходимо также выделить дополнительные виртуальные машины для виртуальных машин шлюза и управлять ими после этого.

Обмен данными между виртуальными машинами с помощью SDN Multisite

С помощью SDN Multisite в двух физических локациях можно использовать встроенное подключение уровня 2 для взаимодействия между площадками. Это позволяет иметь один диапазон подсети для приложений, охватывающих оба расположения, устраняя необходимость настройки подключения шлюза SDN. Например, как показано на следующей схеме, интерфейсные приложения в обоих расположениях могут использовать одну подсеть, например 10.1/16, вместо поддержки двух отдельных. С помощью этой установки поток данных из одной виртуальной машины в другую исключительно зависит от базовой физической инфраструктуры, избегая необходимости пройти другую виртуальную машину шлюза SDN.

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

В настоящее время подсистемы балансировки нагрузки программного обеспечения — это локальные ресурсы для каждого физического сайта. Это означает, что политики и конфигурации балансировки нагрузки не синхронизируются между сайтами через Multisite. Помните об этом при переносе виртуальных машин из одного расположения в другое в настройке sdN Multisite.

Балансировка нагрузки в многосайтовой SDN: пример сценария

В следующих разделах объясняется балансировка нагрузки в Multisite с помощью примера сценария, демонстрирующего как без, так и при переносе виртуальных машин рабочей нагрузки. Предположим, что у вас есть два локальных экземпляра Azure с включенной поддержкой SDN Multisite, каждая из которых имеет собственную инфраструктуру SDN, развернутую и настроенную. В этом сценарии клиент хочет достучаться до VM1 с IP-адресом 10.0.0.5 и VIP 11.0.0.5.

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

В SDN Multisite, если миграция виртуальных машин между расположениями не выполняется, пакеты данных передаются как обычно, аналогично традиционной настройке SDN. Следующая анимация иллюстрирует путь к данным с клиентского компьютера на виртуальную машину vm1 через SLB MUX1 в кластере 2.

Балансировка нагрузки в SDN Multisite с миграцией виртуальных машин с рабочей нагрузкой

Если вы решите перенести одну виртуальную машину или все виртуальные машины, находящиеся за VIP, на другой сайт, возможно, возникнет ситуация, когда виртуальная машина, которую вы пытаетесь достичь, становится недоступной по VIP в зависимости от её расположения. Это происходит, так как ресурсы подсистемы балансировки нагрузки являются локальными для каждого локального экземпляра Azure. При перемещении виртуальных машин рабочей нагрузки конфигурации в многомерных модулях не являются глобальными, оставляя другой сайт не в курсе миграций. Следующая анимация иллюстрировала миграцию виртуальных машин из кластера 2 в кластер 1 и сбой пути пакета данных после миграции.

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

Использование внешней подсистемы балансировки нагрузки в Multisite с переносом виртуальных машин рабочей нагрузки

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

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

Шлюзы и их ограничения

Мультисайт SDN не синхронизирует локальные ресурсы, такие как шлюзовые подключения на разных сайтах. Каждый сайт имеет собственные шлюзовые виртуальные машины и подключения шлюза. При создании или переносе рабочей виртуальной машины на сайт, она получает конфигурацию локального шлюза, например, маршруты шлюза. При создании подключения шлюза для определенной виртуальной сети на одном сайте виртуальные машины из этого сайта теряют подключение шлюза при миграции на другой сайт. Чтобы виртуальные машины сохраняли подключение шлюза при миграции, необходимо настроить отдельное подключение шлюза для той же виртуальной сети на другом сайте.

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