Что такое SDN Multisite?
Область применения: Локальная версия Azure, версия 23H2
Область применения: Windows Server 2025
В этой статье представлен обзор мультисайтов SDN, включая преимущества и текущие ограничения. Его можно использовать в качестве руководства для разработки топологии сети и плана аварийного восстановления.
SdN Multisite позволяет расширить возможности традиционных SDN, развернутых в разных физических расположениях. Мультисайт SDN обеспечивает собственное подключение уровня 2 и уровня 3 в разных физических расположениях для виртуализированных рабочих нагрузок. В этой статье все ссылки на сайты означают физические расположения.
Сведения об управлении несколькими сайтами SDN см. в статье "Управление несколькими сайтами SDN для локальной среды Azure".
Сведения об управлении несколькими сайтами SDN см. в статье "Управление несколькими сайтами SDN для локальной среды Azure".
Льготы
Ниже приведены преимущества использования sdN Multisite:
- Унифицированная система управления политиками. С помощью общих виртуальных сетей и конфигураций политик вы можете управлять и настраивать многосайтовые сети с любого сайта.
- Простая миграция рабочей нагрузки. Просто переносить рабочие нагрузки на физические сайты без необходимости перенастройки IP-адресов или предварительной миграции групп безопасности сети (NSG).
- Автоматическая доступность новых виртуальных машин. Получите автоматическую доступность только что созданных виртуальных машин в виртуальных сетях, а также автоматическое управление любыми связанными группами безопасности сети в физических расположениях.
Ограничения
В настоящее время функция SDN Multisite имеет несколько ограничений:
- Поддерживается только между двумя сайтами.
- Сайты должны быть подключены через частную сеть, так как поддержка шифрования сайтов, подключенных через Интернет, не предоставляется.
- Внутренняя балансировка нагрузки не поддерживается между сайтами.
Пиринг с несколькими сайтами
Для нескольких сайтов требуется пиринг между сайтами, которые инициируются как пиринг между виртуальными сетями. Подключение автоматически инициируется на обоих сайтах через Центр администрирования Windows. После установки подключения пиринг становится успешным. Инструкции по установке пиринга см. в разделе "Установка пиринга".
Для нескольких сайтов требуется пиринг между сайтами, которые инициируются как пиринг между виртуальными сетями. Подключение автоматически инициируется на обоих сайтах через Центр администрирования Windows. После установления подключения пиринг становится успешным. Инструкции по установке пиринга см. в разделе "Установка пиринга".
В следующих разделах описаны роли каждого сайта в многосайтовой среде, а также способы обработки и синхронизации ресурсов между сайтами.
Основные и вторичные роли сайта
В среде SDN с несколькими сайтами один сайт назначается в качестве основного и другого в качестве дополнительного. Основной сайт обрабатывает синхронизацию ресурсов. Во время многосайтового пиринга основной сайт автоматически выбирается, который можно изменить позже с помощью Центра администрирования Windows.
Обработка ресурсов
Если первичный сайт недоступен, глобальные ресурсы и ресурсы, требующие глобальной проверки или глобального распределения адресов клиентов (ЦС), не могут быть обновлены через дополнительный сайт. Однако другие локальные ресурсы можно обновить с помощью дополнительного сайта.
Примеры ресурсов, необходимых для глобальной проверки, включают:
- Пулы MAC.
- Логический пул сети или IP-адресов.
Примеры глобальных выделений ЦС:
- Внутренняя балансировка нагрузки для виртуальной подсети. В настоящее время это не поддерживается через Multisite.
- Подключения шлюза для виртуальной подсети.
Если дополнительный сайт недоступен, ресурсы можно обновить с помощью первичного сайта. Однако вторичный сайт может иметь устаревшие ресурсы до восстановления подключения. После восстановления подключения синхронизация возобновляется.
Если основной сайт исчез, можно назначить дополнительный сайт новым первичным сайтом для выполнения обновлений групп безопасности сети и виртуальных сетей. Однако все ожидающие синхронизации данных со старого первичного сайта будут потеряны. Чтобы устранить эту проблему, примените те же изменения на новом первичном сайте после того, как старый первичный сайт снова подключен к сети. Однако это также может привести к глобальным конфликтам распределения ЦС.
Синхронизация ресурсов
При включении sdN Multisite не все ресурсы каждого сайта синхронизируются на всех сайтах. Ниже приведены списки ресурсов, синхронизированных и которые остаются несинхронизированными.
Синхронизированные ресурсы
Эти ресурсы синхронизируются на всех сайтах после установки пиринга. Эти ресурсы можно обновить с любого сайта, будь то первичный или вторичный. Однако первичный сайт отвечает за то, что эти ресурсы применяются и синхронизируются между сайтами. Руководство и инструкции по управлению этими ресурсами остаются такими же, как и в среде SDN с одним сайтом.
- Виртуальные сети. Инструкции по управлению виртуальными сетями см. в разделе "Управление виртуальными сетями клиента". Обратите внимание, что логические сети не синхронизируются между сайтами. Однако если виртуальные сети ссылались на логическую сеть, то логическая сеть с одинаковым именем должна существовать на обоих сайтах.
- Группы безопасности сети (NSG). Инструкции по настройке группы безопасности сети в Windows Admin Center и PowerShell см. в статье "Настройка групп безопасности сети" с помощью Центра администрирования Windows и настройка групп безопасности сети с помощью PowerShell.
- Определяемые пользователем маршруты. Инструкции по использованию определяемой пользователем маршрутизации см. в разделе "Использование сетевых виртуальных устройств в виртуальной сети".
Синхронизированные ресурсы
Эти ресурсы синхронизируются на всех сайтах после установки пиринга. Эти ресурсы можно обновить с любого сайта, будь то первичный или вторичный. Однако первичный сайт отвечает за то, что эти ресурсы применяются и синхронизируются между сайтами. Руководство и инструкции по управлению этими ресурсами остаются такими же, как и в среде SDN с одним сайтом.
- Виртуальные сети. Инструкции по управлению виртуальными сетями см. в разделе "Управление виртуальными сетями клиента". Обратите внимание, что логические сети не синхронизируются между сайтами. Однако если виртуальные сети ссылались на логическую сеть, то логическая сеть с одинаковым именем должна существовать на обоих сайтах.
- Группы безопасности сети (NSG). Инструкции по настройке группы безопасности сети в Windows Admin Center и PowerShell см. в статье "Настройка групп безопасности сети" с помощью Центра администрирования Windows и настройка групп безопасности сети с помощью PowerShell.
- Определяемые пользователем маршруты. Инструкции по использованию определяемой пользователем маршрутизации см. в разделе "Использование сетевых виртуальных устройств в виртуальной сети".
Несинхронизированные ресурсы
Эти ресурсы не синхронизируются после установки пиринга:
- Политики балансировки нагрузки.
- Виртуальные IP-адреса (IP-адреса).
- Политики шлюза.
- Логические сети. Хотя логические сети не синхронизированы между сайтами, пулы IP-адресов проверяются на перекрытие и не допускаются.
Эти политики создаются на локальном сайте и, если вы хотите, чтобы те же политики на другом сайте были созданы вручную. Если внутренние виртуальные машины для политик балансировки нагрузки находятся на одном сайте, подключение через SLB будет работать нормально без дополнительной настройки. Но если вы ожидаете, что серверные виртуальные машины будут перемещаться с одного сайта на другой, по умолчанию подключение работает только в том случае, если на локальном сайте есть виртуальные машины серверной части. Если все внутренние виртуальные машины перемещаются на другой сайт, подключение по этой виртуальной машине завершается сбоем.
Поток трафика на востоке и общий доступ к подсети
Мультисайт позволяет виртуальным машинам на разных сайтах с SDN, развернутыми для обмена данными по одной подсети, не настраивать подключения шлюза SDN. Это упрощает топологию сети и сокращает потребность в дополнительных виртуальных машинах и подсетях. Путь к данным между виртуальными машинами на разных сайтах зависит от базовой физической инфраструктуры.
В следующих сценариях сравнивается настройка обмена данными между двумя физическими сайтами в традиционной настройке SDN и многосайтовой настройке SDN.
Обмен данными между виртуальными машинами без многосайтового подключения SDN
В традиционной настройке с SDN, развернутой на двух физических сайтах, необходимо установить подключение шлюза L3 или GRE для взаимодействия между сайтами. Кроме того, необходимо предоставить дополнительные подсети для приложений. Например, если каждый сайт размещает интерфейсные приложения, вы выделяете отдельные диапазоны подсети, такие как 10.1/16 и 10.6/16. Кроме того, при настройке подключения к шлюзу необходимо также выделить дополнительные виртуальные машины для виртуальных машин шлюза и управлять ими после этого.
Обмен данными между виртуальными машинами с помощью SDN Multisite
С помощью SDN Multisite в двух физических расположениях можно использовать собственное подключение уровня 2 для взаимодействия между сайтами. Это позволяет иметь один диапазон подсети для приложений, охватывающих оба расположения, устраняя необходимость настройки подключения шлюза SDN. Например, как показано на следующей схеме, интерфейсные приложения в обоих расположениях могут использовать одну подсеть, например 10.1/16, вместо поддержки двух отдельных. С помощью этой установки поток данных из одной виртуальной машины в другую исключительно зависит от базовой физической инфраструктуры, избегая необходимости пройти другую виртуальную машину шлюза SDN.
Подсистемы балансировки нагрузки программного обеспечения и их ограничения
В настоящее время подсистемы балансировки нагрузки программного обеспечения — это локальные ресурсы для каждого физического сайта. Это означает, что политики и конфигурации балансировки нагрузки не синхронизируются между сайтами через Multisite. Помните об этом при переносе виртуальных машин из одного расположения в другое в настройке sdN Multisite.
Балансировка нагрузки в multisite SDN: пример сценария
В следующих разделах объясняется балансировка нагрузки в Multisite с помощью примера сценария, демонстрирующего как без, так и при переносе виртуальных машин рабочей нагрузки. Предположим, что у вас есть два локальных экземпляра Azure с включенной поддержкой SDN Multisite, каждая из которых имеет собственную инфраструктуру SDN, развернутую и настроенную. В этом сценарии клиент хочет связаться с VM1 с IP-адресом 10.0.0.5 и ВИРТУАЛЬНЫм IP-адресом 11.0.0.5.
Балансировка нагрузки в sdN Multisite без переноса виртуальных машин рабочей нагрузки
Если миграция виртуальных машин между расположениями не выполняется, пакеты данных перенаправляются как обычно, аналогично традиционной настройке SDN. Следующая анимация иллюстрирует путь к данным с клиентского компьютера на виртуальную машину vm1 через SLB MUX1 в кластере 2.
Балансировка нагрузки в sdN Multisite с переносом виртуальных машин рабочей нагрузки
Если вы решите перенести одну виртуальную машину или все виртуальные машины за виртуальным ip-адресом на другой сайт, может возникнуть ситуация, когда виртуальная машина, которую вы пытаетесь достичь, становится недоступной по виртуальному ip-адресу в зависимости от его расположения. Это происходит, так как ресурсы подсистемы балансировки нагрузки являются локальными для каждого локального экземпляра Azure. При перемещении виртуальных машин рабочей нагрузки конфигурации в многомерных модулях не являются глобальными, оставляя другой сайт не в курсе миграций. Следующая анимация иллюстрировала миграцию виртуальных машин из кластера 2 в кластер 1 и сбой пути пакета данных после миграции.
Чтобы обойти это ограничение, можно использовать внешнюю подсистему балансировки нагрузки, которая проверяет доступность внутренних виртуальных машин на каждом сайте и маршрутизирует трафик соответствующим образом. См. статью "Использование внешней подсистемы балансировки нагрузки" в Мультисайтах с переносом виртуальных машин рабочей нагрузки.
Использование внешней подсистемы балансировки нагрузки в Multisite с переносом виртуальных машин рабочей нагрузки
Вы можете включить внешнюю подсистему балансировки нагрузки, чтобы проверить наличие внутренних виртуальных машин за подсистемой балансировки нагрузки на одном из сайтов. Если за подсистемой балансировки нагрузки нет внутренних виртуальных машин, виртуальный IP-адрес для многомерного модуля не объявляется до внешней подсистемы балансировки нагрузки, а любая проба работоспособности отправлена сбоем. Эта внешняя подсистема балансировки нагрузки обеспечивает подключение к рабочим нагрузкам, даже если виртуальные машины перемещаются с одного сайта на другой.
Однако если развертывание внешней подсистемы балансировки нагрузки невозможно, используйте решение балансировки нагрузки программного обеспечения, как описано в статье "Балансировка нагрузки в SDN Multisite без миграции виртуальных машин рабочей нагрузки, пока у вас нет виртуальных машин, перенесенных на рабочую нагрузку".
Шлюзы и их ограничения
Мультисайт SDN не синхронизирует локальные ресурсы, такие как подключения шлюза между сайтами. Каждый сайт имеет собственные виртуальные машины шлюза и подключения шлюза. При создании или переносе виртуальной машины рабочей нагрузки на сайт она получает конфигурацию локального шлюза, например маршруты шлюза. При создании подключения шлюза для определенной виртуальной сети на одном сайте виртуальные машины из этого сайта теряют подключение шлюза при миграции на другой сайт. Чтобы виртуальные машины сохраняли подключение шлюза при миграции, необходимо настроить отдельное подключение шлюза для той же виртуальной сети на другом сайте.