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

Область применения: Azure Stack HCI, версии 20H2, 21H2 и 22H2

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

Примечание

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

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

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

Важно!

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

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

Vendor 10 GbE 25 ГбE 100 Гбит/с 400 GbE
Arista Networks

Требуется версия EOS 4.26.2F или более поздней.
Серия 7050X3, серия 7060X, серия 7260X3, серия 7280R,7280R3 Серия 7050X3, серия 7060X, серия 7260X3, серия 7280R,7280R3 Серия 7050X3, серия 7060X, серия 7260X3, серия 7060X4, серия 7280R, серия 7280R3 Серия 7050X3, серия 7060X4, серия 7280R3
Dell Серия S41xx Серия S52xx Серия S52xx
Juniper Networks

Требуется выпуск junos Software Service версии 20.2R3-S2 или более поздней
Серия QFX5110, QFX5120, QFX5200 Серия QFX5120, QFX5200 Серия QFX5120, QFX5200, серия QFX5210, QFX5220 Серия QFX5130, QFX5220
Lenovo G8272, NE1032 NE2572 NE10032
NVIDIA

Требуется Cumulus Linux версии 5.1 или более поздней
SN2000, SN3000SN4000 SN2000, SN3000SN4000 SN2000, SN3000SN4000 SN4000

Важно!

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

Примечание

Гиперконвергентная инфраструктура имеет высокую зависимость от East-West связи уровня 2 в одной стойке и, следовательно, требует ETS. Корпорация Майкрософт не тестирует Azure Stack HCI с помощью кодовой точки разных служб (DSCP).

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

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

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

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

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

Важно!

Более поздние версии ОС могут определять дополнительные требования к TLV

Требуемая версия План Подтип TLV
20H2 и более поздних версий IEEE 802.1 Имя виртуальной локальной сети (подтип = 3)
20H2 и более поздних версий IEEE 802.3 Максимальный размер кадра (подтип = 4)

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

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

Модели сети

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

Важно!

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

North-South трафик для Azure Stack HCI

North-South трафик имеет следующие характеристики:

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

East-West трафик для Azure Stack HCI

East-West трафик имеет следующие характеристики:

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

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

North-South трафик требует использования коммутаторов. Помимо использования коммутатора Ethernet, который поддерживает необходимые протоколы для Azure Stack HCI, наиболее важным аспектом является правильный размер сетевой структуры.

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

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

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

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

Azure Stack HCI поддерживает бессерверные (прямые) подключения для 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

Примечание

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

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

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

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

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

Дальнейшие действия