Поделиться через

Требования к физической сети для локальной сети Azure

  • Статья

Область применения: Azure Local 2311.2 и более поздних версий

В этой статье рассматриваются вопросы и требования к физической сети (fabric) для локальной среды Azure, особенно для сетевых коммутаторов.

Примечание.

Требования для будущих локальных версий Azure могут измениться.

Сетевые коммутаторы для локальной среды Azure

Microsoft тестирует Azure Local в соответствии со стандартами и протоколами, определёнными в разделе «Требования к сетевому коммутатору» ниже. Хотя корпорация Майкрософт не сертифицирует сетевые коммутаторы, мы работаем с поставщиками, чтобы определить устройства, поддерживающие локальные требования Azure.

Внимание

Хотя другие сетевые коммутаторы, использующие технологии и протоколы, не перечисленные здесь, могут работать, корпорация Майкрософт не может гарантировать, что они будут работать с локальной службой Azure и могут оказаться не в состоянии помочь в устранении неполадок, возникающих.

При покупке сетевых коммутаторов обратитесь к поставщику коммутаторов и убедитесь, что устройства соответствуют локальным требованиям Azure для указанных типов ролей. Следующие поставщики (в алфавитном порядке) подтвердили, что их коммутаторы поддерживают локальные требования Azure:

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

Внимание

Мы обновляем эти списки по мере того, как нам сообщают о изменениях поставщики сетевых коммутаторов.

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

Требования к сетевому коммутатору

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

Примечание.

Сетевые адаптеры, используемые для вычислений, хранилища и трафика управления, требуют Ethernet. Дополнительные сведения см. в разделе "Требования к сети узла".

Ниже приведены обязательные стандарты и спецификации IEEE:

Требования к ролям для версии 23H2

Требование Управление Хранилище Compute (Standard) Вычисления (SDN)
Виртуальная локальная сеть ✓ ✓ ✓ ✓
Управление приоритетным потоком ✓
Улучшенный выбор передачи ✓
Идентификатор VLAN порта LLDP ✓
LLDP VLAN Имя ✓ ✓ ✓
Агрегация каналов LLDP ✓ ✓ ✓ ✓
Конфигурация LLDP ETS ✓
Рекомендация LLDP ETS ✓
Конфигурация LLDP PFC ✓
Максимальный размер кадра LLDP ✓ ✓ ✓ ✓
Максимальная единица передачи ✓
Протокол граничного шлюза (BGP) ✓
Агент ретрансляции DHCP ✓

Примечание.

Для гостевой RDMA требуются как вычислительные ресурсы (стандартные), так и хранилище данных.

Стандартный: IEEE 802.1Q

Коммутаторы Ethernet должны соответствовать спецификации IEEE 802.1Q, определяющей виртуальные ЛС. Виртуальные локальные сети требуются для нескольких аспектов Локальной среды Azure и требуются во всех сценариях.

Стандарт: IEEE 802.1Qbb

Коммутаторы Ethernet, используемые для трафика локального хранилища Azure, должны соответствовать спецификации IEEE 802.1Qbb, которая определяет управление потоками приоритета (PFC). PFC требуется, когда используется Data Center Bridging (DCB). Так как DCB можно использовать в сценариях RoCE и iWARP RDMA, 802.1Qbb требуется во всех сценариях. Требуется как минимум три приоритета класса службы (CoS) без понижения возможностей коммутатора или скоростей портов. По крайней мере один из этих классов трафика должен обеспечить безпотерьную связь.

Стандарт: IEEE 802.1Qaz

Коммутаторы Ethernet, используемые для трафика локального хранилища Azure, должны соответствовать спецификации IEEE 802.1Qaz, определяющей расширенный выбор передачи (ETS). Использование ETS требуется там, где используется DCB. Так как DCB можно использовать в сценариях RoCE и iWARP RDMA, 802.1Qaz требуется во всех сценариях.

Требуется как минимум три приоритета CoS без понижения возможностей коммутатора или скорости порта. Кроме того, если устройство разрешает определять тарифы QoS входящего трафика, рекомендуется не настраивать тарифы входящего трафика или настраивать их точно так же, как и тарифы исходящего трафика (ETS).

Примечание.

Hyper-converged infrastructure has a high reliance on East-West Layer-2 communication within the same rack and therefore requires ETS. Корпорация Майкрософт не проверяет локальную службу Azure с помощью точки кода для разных служб (DSCP).

Стандарт: IEEE 802.1AB

Коммутаторы Ethernet должны соответствовать спецификации IEEE 802.1AB, определяющей протокол обнаружения уровней ссылок (LLDP). LLDP требуется для локальной службы Azure и позволяет устранять неполадки конфигураций физической сети.

Configuration of the LLDP Type-Length-Values (TLVs) must be dynamically enabled. Коммутаторы не должны требовать дополнительной конфигурации за пределами включения определенного TLV. Например, включение 802.1 Subtype 3 должно автоматически объявлять все VLAN (виртуальные локальные сети), доступные на портах коммутатора.

Custom TLV requirements

LLDP позволяет организациям определять и кодировать свои собственные пользовательские TLV. Они называются организационно-специфическими TLV. All Organizationally Specific TLVs start with an LLDP TLV Type value of 127. В таблице ниже показано, какие подтипы TLV типа 127 требуются для конкретной организации.

Организация Подтип TLV
IEEE 802.1 Идентификатор VLAN порта (подтип = 1)
IEEE 802.1 Имя виртуальной локальной сети (подтип = 3)
Не менее 10 виртуальных локальных сетей (VLAN)
IEEE 802.1 Link Aggregation (Subtype = 7)
IEEE 802.1 Конфигурация ETS (подтип = 9)
IEEE 802.1 Рекомендация ETS (подтип = A)
IEEE 802.1 Конфигурация PFC (подтип = B)
IEEE 802.3 Максимальный размер кадра (подтип = 4)

Максимальная единица передачи

Максимальная единица передачи (MTU) — это самый большой кадр размера или пакет, который можно передать по каналу данных. Диапазон от 1514 до 9174 необходим для инкапсуляции SDN.

Протокол граничного шлюза (BGP)

Коммутаторы Ethernet, используемые для трафика вычислений Azure Local SDN, должны поддерживать протокол BGP. BGP — это стандартный протокол маршрутизации, используемый для обмена данными о маршрутизации и доступности между двумя или более сетями. Маршруты автоматически добавляются в таблицу маршрутов всех подсетей с включенным распространением BGP. Это необходимо для включения рабочих нагрузок клиента с SDN и динамическим пирингом. RFC 4271: протокол 4 пограничного шлюза

Агент ретрансляции DHCP

Коммутаторы Ethernet, используемые для трафика локального управления Azure, должны поддерживать агент ретрансляции DHCP. Агент ретрансляции DHCP — это любой узел TCP/IP, который используется для пересылки запросов и ответов между DHCP-сервером и клиентом, когда сервер присутствует в другой сети. Это необходимо для служб загрузки PXE. RFC 3046: DHCPv4 или RFC 6148: DHCPv4

Сетевой трафик и архитектура

Этот раздел преимущественно предназначен для администраторов сети.

Azure Local может функционировать в различных архитектурах центра обработки данных, включая 2-уровневую (Spine-Leaf) и 3-уровневую (Core-Aggregation-Access). В этом разделе описаны более основные понятия топологии "Позвоночник-Лист", которая обычно используется с рабочими нагрузками в гиперконвергентной инфраструктуре, например Azure Local.

Модели сети

Сетевой трафик можно классифицировать по его направлению. Традиционные среды сети хранения (SAN) в значительной степени характеризуются вертикальным (North-South) потоком данных, где трафик поступает с вычислительного уровня на уровень хранения через границу третьего уровня (IP). Гиперконвергентная инфраструктура является более сильно восточно-западной, где существенная часть трафика остается в пределах границы уровня 2 (VLAN).

Внимание

Нам требуется, чтобы все локальные компьютеры Azure на сайте физически находятся в одной стойке и подключены к одному и тому же коммутатору верхнего уровня (ToR).

Примечание.

Функции растянутого кластера доступны только в локальной версии Azure версии 22H2.

Трафик "Север-Юг" для локальной сети Azure

Трафик "Север-Юг" имеет следующие характеристики:

  • Traffic flows out of a ToR switch to the spine or in from the spine to a ToR switch.
  • Трафик покидает физическую стойку или пересекает границу уровня 3 (IP).
  • Includes management (PowerShell, Windows Admin Center), compute (VM), and inter-site stretched cluster traffic.
  • Использует коммутатор Ethernet для подключения к физической сети.

Трафик Восток-Запад для локальной сети Azure

Трафик "Восток-Запад" имеет следующие характеристики:

  • Трафик остается внутри коммутаторов ToR и границы уровня 2 (VLAN).
  • Включает трафик хранилища или трафик динамической миграции между узлами в одной системе и (если используется растянутый кластер) на одном сайте.
  • Может использоваться коммутатор Ethernet (с коммутатором) или прямая связь (без коммутатора), как описано в следующих двух разделах.

Использование коммутаторов

Для трафика "Север-Юг" требуется использование коммутаторов. Помимо использования коммутатора Ethernet, поддерживающего необходимые протоколы для локальной среды Azure, наиболее важным аспектом является правильный размер сетевой структуры.

Важно понимать, какую неблокирующую коммутационную пропускную способность могут поддерживать ваши коммутаторы Ethernet, и стремиться к минимизации (или, желательно, полному исключению) перегрузки сети.

Common congestion points and oversubscription, such as the Multi-Chassis Link Aggregation Group used for path redundancy, can be eliminated through proper use of subnets and VLANs. Также см. сведения о требованиях к сети узла.

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

Using switchless

Azure Local поддерживает подключения без переключателей (прямое подключение) для трафика Восток-Запад для любых размеров систем, если каждый узел в системе имеет резервное подключение к каждому другому узлу в системе. This is called a "full-mesh" connection.

Схема, показывающая полносвязное подключение без коммутаторов

Пара интерфейсов Subnet VLAN
Mgmt host vNIC Специфический для клиента Специфический для клиента
SMB01 192.168.71.x/24 711
SMB02 192.168.72.x/24 712
SMB03 192.168.73.x/24 713

Примечание.

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

Преимущества подключений без переключателей

  • Для трафика "Восток-Запад" не требуется покупка коммутатора. Для трафика "Север-Юг" требуется переключатель. Это может привести к снижению капитальных расходов (CAPEX), но зависит от количества узлов в системе.
  • Так как нет коммутатора, конфигурация ограничена узлом, что может снизить потенциальное количество необходимых шагов конфигурации. Это значение уменьшается по мере увеличения размера системы.

Недостатки соединений без переключателей

  • Для схем адресации IP-адресов и подсетей требуется больше планирования.
  • Предоставляет доступ только к локальному хранилищу. Трафик управления, трафик виртуальной машины и другой трафик, требующий доступа "Север-Юг", не может использовать эти адаптеры.
  • По мере роста числа узлов в системе стоимость сетевых адаптеров может превышать затраты на использование сетевых коммутаторов.
  • Не масштабируется далеко за рамки трехузловых систем. Дополнительные узлы влекут за собой необходимость дополнительных кабелей и настройки, которые могут превзойти сложность использования коммутатора.
  • Расширение системы является сложным, требуя изменения конфигурации оборудования и программного обеспечения.

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