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

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

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

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

Примечание.

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

Сетевые коммутаторы для Azure Local

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

Внимание

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

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

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

Внимание

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

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

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

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

Примечание.

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

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

Требования к роли 24H2

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

Примечание.

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

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

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

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

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

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

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

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

Примечание.

Гиперконвергентная инфраструктура сильно зависит от коммуникации уровня 2 типа "Восток-Запад" внутри одной стойки и, следовательно, требует ETS. Корпорация Майкрософт не тестирует Azure Local с помощью различаемой точки кода служб (DSCP).

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

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

Настройка значений типа LLDP (TLVs) должна быть включена в динамическом режиме. Коммутаторы не должны требовать дополнительной конфигурации за пределами включения определенного TLV. Например, включение 802.1 Subtype 3 должно автоматически объявлять все VLAN (виртуальные локальные сети), доступные на портах коммутатора.

Настраиваемые требования к TLV

LLDP позволяет организациям определять и кодировать свои собственные пользовательские TLV. Эти кастомные TLV называются организационно специфичными TLV. Все организационно-специфические TLV начинаются со значения типа TLV, равного 127. В следующей таблице показано, какие подтипы TLV типа 127 требуются для конкретной организации.

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

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

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

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

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

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

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

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

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

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

Модели сети

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

Внимание

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

Примечание.

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

Север-Юг трафик для Azure Local

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

  • Трафик выходит из коммутатора ToR к магистральному коммутатору или поступает из магистрального коммутатора к коммутатору ToR.
  • Трафик покидает физическую стойку или пересекает границу уровня 3 (IP).
  • Включает управление (PowerShell, Windows Admin Center), вычислительные ресурсы (виртуальная машина) и трафик растянутого кластера между сайтами.
  • Использует коммутатор Ethernet для подключения к физической сети.

Восточно-западный трафик для Azure Local

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

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

Политика качества обслуживания для Azure Local

Чтобы обеспечить согласованную приоритетность трафика в Azure Local развертываниях, политики качества обслуживания должны соответствовать конфигурациям узлов, которые управляют трафиком хранилища в поддерживаемой структуре коммутаторов. Эта политика применяется как к средам ROCEv2, так и iWARP и требуется для переключенных конфигураций Azure Local. Конфигурации без переключателей, которые не проводят трафик данных хранения через коммутатор, не требуют этой политики.

Дополнительные сведения см. в разделе Azure Local — политика качества обслуживания.

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

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

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

Распространенные точки перегрузки и чрезмерное использование, такие как Multi-Chassis Link Aggregation Group, используемая для избыточности пути, могут быть устранены путем надлежащего использования подсетей и виртуальных локальных сетей (VLAN). Дополнительные сведения см. в разделе "Требования к сети узла".

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

Использование без переключателей

Azure Local поддерживает подключения без коммутаторов (прямые) для трафика East-West для всех размеров системы, если каждый узел в системе имеет резервное соединение с каждым узлом в системе. Эта конфигурация называется подключением с полной сеткой.

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

Пара интерфейсов Подсеть Виртуальная локальная сеть
VNIC узла Mgmt Специфический для клиента Специфический для клиента
SMB01 192.168.71.x/24 711
SMB02 192.168.72.x/24 712
SMB03 192.168.73.x/24 713

Примечание.

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

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

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

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

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

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

  • Last updated on