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

Статья
03/14/2024

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

В этом разделе рассматриваются рекомендации и требования к сети узла для Azure Stack HCI. Сведения об архитектуре центров обработки данных и физических подключениях между серверами см. в статье Требования к физической сети.

Сведения об упрощении сетей узлов с помощью Network ATC см. в статье Упрощение сетей узла с помощью Network ATC.

Типы сетевого трафика

Сетевой трафик Azure Stack HCI можно классифицировать по назначению:

Трафик управления: Трафик в локальный кластер или извне. Например, хранилище реплика трафик или трафик, используемый администратором для управления кластером, например удаленный рабочий стол, Windows Admin Center, Active Directory и т. д.
Вычислительный трафик: Трафик, исходящий или предназначенный для виртуальной машины.
Трафик хранилища: Трафик, использующий серверный блок сообщений (SMB), например Локальные дисковые пространства или динамическую миграцию на основе SMB. Этот трафик является трафиком уровня 2 и не маршрутизируется.

Важно!

Реплика хранилища использует трафик SMB, отличный от RDMA. Это и направление трафика (север-юг) делает его тесно согласующимся с трафиком "управления", перечисленным выше, как и в традиционной общей папке.

Выбор сетевого адаптера

Сетевые адаптеры соответствуют типам сетевого трафика (см. выше), с которыми они поддерживаются. При просмотре каталога Windows Server сертификация Windows Server 2022 теперь указывает на одну или несколько из следующих ролей. Прежде чем приобретать сервер для Azure Stack HCI, необходимо иметь по крайней мере один адаптер, который подходит для управления, вычислений и хранения, так как в Azure Stack HCI требуются все три типа трафика. Затем можно использовать Network ATC для настройки адаптеров для соответствующих типов трафика.

Дополнительные сведения об этой квалификации сетевого адаптера на основе ролей см. по этой ссылке.

Важно!

Использование адаптера за пределами его квалифицированного типа трафика не поддерживается.

Level	Роль управления	Роль вычислений	Роль хранилища
Различие на основе ролей	управление;	Вычисление уровня "Стандартный"	Хранилище уровня "Стандартный"
Максимальная награда	Неприменимо	Вычисление ценовой категории "Премиум"	Хранилище уровня "Премиум"

Примечание

Наивысшая квалификация для любого адаптера в нашей экосистеме будет содержать квалификации Management, Compute Premium и Storage Premium .

Требования к драйверу

Драйверы папки "Входящие" не поддерживаются для использования с Azure Stack HCI. Чтобы определить, использует ли адаптер драйвер для папки "Входящие", выполните следующий командлет. Адаптер использует драйвер папки "Входящие", если свойство DriverProvider имеет значение Майкрософт.

Get-NetAdapter -Name <AdapterName> | Select *Driver*

Обзор основных возможностей сетевого адаптера

Ниже перечислены важные возможности сетевого адаптера, используемые Azure Stack HCI.

Динамическая виртуальная машина с несколькими очередами (dynamic VMMQ или d.VMMQ)
Удаленный доступ к памяти (RDMA)
Гостевой RDMA
Switch Embedded Teaming (SET)

Динамический VMMQ

Все сетевые адаптеры с квалификацией вычислений (премиум) поддерживают dynamic VMMQ. Для динамического VMMQ требуется использовать объединение встроенных коммутаторов.

Применимые типы трафика: вычисление

Необходимые сертификаты: Вычисления (премиум)

Динамический VMMQ — это интеллектуальная технология на стороне приема. Он основан на своих предшественниках очереди виртуальных машин (VMQ), масштабирования на стороне виртуального получения (vRSS) и VMMQ, чтобы обеспечить три основных улучшения:

Оптимизирует эффективность работы узла за счет использования меньшего количества ядер ЦП.
Автоматическая настройка обработки сетевого трафика для ядер ЦП, что позволяет виртуальным машинам соответствовать ожидаемой пропускной способности и поддерживать их.
Позволяет "пиковые" рабочие нагрузки получать ожидаемый объем трафика.

Дополнительные сведения о динамическом VMMQ см. в записи блога Искусственные ускорения.

RDMA

RDMA — это разгрузка сетевого стека для сетевого адаптера. Это позволяет трафику хранилища SMB обходить операционную систему для обработки.

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

Применимые типы трафика: хранилище узла

Необходимые сертификаты: Хранилище (цен. категория "Стандартный")

Все адаптеры со службой хранилища (цен. категория "Стандартный") или хранилищем (премиум) поддерживают RDMA на стороне узла. Дополнительные сведения об использовании RDMA с гостевыми рабочими нагрузками см. в разделе "Гостевой RDMA" далее в этой статье.

Azure Stack HCI поддерживает RDMA с реализацией протокола RDMA для всего Интернета (iWARP) или протокола RDMA через конвергентный Ethernet (RoCE).

Важно!

Адаптеры RDMA работают только с другими адаптерами RDMA, которые реализуют тот же протокол RDMA (iWARP или RoCE).

Не все сетевые адаптеры от поставщиков поддерживают RDMA. В следующей таблице перечислены поставщики (в алфавитном порядке), которые предлагают сертифицированные адаптеры RDMA. Однако есть поставщики оборудования, не включенные в этот список, которые также поддерживают RDMA. Ознакомьтесь с каталогом Windows Server, чтобы найти адаптеры с квалификацией Хранилища (цен. категория "Стандартный") или Хранилище (премиум), которым требуется поддержка RDMA.

Примечание

InfiniBand (IB) не поддерживается в Azure Stack HCI.

Поставщик сетевой карты	iWARP;	RoCE.
Broadcom	Нет	Да
Intel	Да	Да (некоторые модели)
Marvell (Qlogic)	Да	Да
Nvidia	Нет	Да

Для получения дополнительных сведений о развертывании RDMA для узла настоятельно рекомендуется использовать Network ATC. Сведения о развертывании вручную см. в репозитории SDN GitHub.

iWARP;

iWARP использует протокол TCP и может быть дополнительно расширен с помощью управления потоками на основе приоритета (PFC) и расширенной службы передачи (ETS).

Используйте iWARP, если:

У вас нет опыта управления сетями RDMA.
Вы не управляете коммутаторами top-of-rack (ToR) или не управляете ими.
Вы не будете управлять решением после развертывания.
У вас уже есть развертывания, использующие iWARP.
Вы не знаете, какой вариант выбрать.

RoCE.

RoCE использует протокол UDP и требует PFC и ETS для обеспечения надежности.

Используйте RoCE, если:

У вас уже есть развертывания с RoCE в центре обработки данных.
Вам удобно управлять требованиями к сети DCB.

Гостевая RDMA

Гостевая RDMA позволяет рабочим нагрузкам SMB для виртуальных машин получить те же преимущества, что и использование RDMA на узлах.

Применимые типы трафика: Хранилище на основе гостя

Необходимые сертификаты: Вычисление (премиум)

Основные преимущества использования гостевой RDMA:

Разгрузка ЦП на сетевую карту для обработки сетевого трафика.
Чрезвычайно низкая задержка.
Высокая пропускная способность.

Для получения дополнительных сведений скачайте документ из репозитория SDN GitHub.

Объединение внедренных коммутаторов (SET)

SET — это программная технология совместной работы, которая была включена в операционную систему Windows Server с Windows Server 2016. SET — единственная технология объединения, поддерживаемая в Azure Stack HCI. SET хорошо работает с трафиком вычислений, хранилища и управления и поддерживается до восьми адаптеров в одной команде.

Применимые типы трафика: вычисления, хранилище и управление

Необходимые сертификаты: Вычисление (стандарт) или вычисление (премиум)

SET — единственная технология объединения, поддерживаемая в Azure Stack HCI. SET хорошо работает с трафиком вычислений, хранилища и управления.

Важно!

Azure Stack HCI не поддерживает объединение сетевых карт со старыми версиями балансировки нагрузки и отработки отказа (LBFO). Дополнительные сведения о LBFO в Azure Stack HCI см. в записи блога Об объединение в Azure Stack HCI.

SET важна для Azure Stack HCI, так как это единственная технология объединения, которая позволяет:

Объединение адаптеров RDMA (при необходимости).
Гостевая RDMA.
Динамический VMMQ.
Другие ключевые функции Azure Stack HCI (см. раздел Объединение в Azure Stack HCI).

SET требует использования симметричного (идентичного) адаптера. Симметричные сетевые адаптеры — это адаптеры со следующими одинаковыми параметрами:

марка (поставщик);
модель (версия);
скорость (пропускная способность).
настройка

В 22H2 network ATC автоматически обнаружит и сообщит вам, являются ли выбранные адаптеры асимметричными. Самый простой способ вручную определить, являются ли адаптеры симметричными, — точно ли совпадают скорости и описания интерфейса. Они могут отклоняться только по числу, указанному в описании. Используйте командлет , Get-NetAdapterAdvancedProperty чтобы убедиться, что сообщаемая конфигурация содержит одинаковые значения свойств.

В следующей таблице приведен пример описаний интерфейса, отклоняющихся только по числовым значениям (#):

Имя	Описание интерфейса	Скорость компоновки
NIC1	Сетевой адаптер No 1	25 Гбит/с
NIC2	Сетевой адаптер 2	25 Гбит/с
NIC3	Сетевой адаптер 3	25 Гбит/с
NIC4	Сетевой адаптер 4	25 Гбит/с

Примечание

SET поддерживает только конфигурацию, независимую от переключения, с помощью алгоритмов динамической балансировки нагрузки или балансировки нагрузки портов Hyper-V. Для лучшей производительности рекомендуется использовать порт Hyper-V во всех сетевых адаптерах, которые работают со скоростью 10 Гбит/с или выше. Network ATC создает все необходимые конфигурации для SET.

Модели трафика хранилища

SMB предоставляет множество преимуществ в качестве протокола хранилища для Azure Stack HCI, включая SMB Multichannel. В этой статье не рассматривается SMB Multichannel, но важно понимать, что трафик мультиплексируется по всем возможным ссылкам, которые может использовать SMB Multichannel.

Примечание

Мы рекомендуем использовать несколько подсетей и виртуальных локальных сетей для разделения трафика хранилища в Azure Stack HCI.

Рассмотрим следующий пример кластера с четырьмя узлами. Каждый сервер имеет два порта хранилища (левый и правый). Так как каждый адаптер находится в одной подсети и виртуальной локальной сети, SMB Multichannel распределяет подключения по всем доступным каналам. Таким образом, левый порт на первом сервере (192.168.1.1) установит подключение к порту слева на втором сервере (192.168.1.2). Правый порт на первом сервере (192.168.1.12) будет подключаться к правому порту на втором сервере. Аналогичные подключения устанавливаются для третьего и четвертого серверов.

Однако это создает ненужные подключения и вызывает перегрузку на межсоединительном канале (группа агрегирования связей с несколькими шасси или MC-LAG), которая подключает коммутаторы ToR (помеченные Xs). Рассмотрим схему ниже.

Рекомендуется использовать отдельные подсети и виртуальные локальные сети для каждого набора адаптеров. На следующей схеме правые порты теперь используют подсеть 192.168.2.x /24 и VLAN2. Это позволяет трафику на портах слева оставаться на TOR1, а трафик на правых портах — на TOR2.

Выделение пропускной способности трафика

В следующей таблице приведены примеры распределения пропускной способности для различных типов трафика с использованием распространенных скоростей адаптера в Azure Stack HCI. Обратите внимание, что это пример конвергентного решения, в котором все типы трафика (вычисления, хранилище и управление) выполняются через одни и те же физические адаптеры и объединяются с помощью SET.

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

Для этого примера сделаны следующие предположения:

В каждой команде есть два адаптера.
Трафик уровня шины хранилища (SBL), общего тома кластера (CSV) и Hyper-V (динамическая миграция).
- Используйте одни и те же физические адаптеры.
- Используйте SMB.
SMB получает 50-процентное распределение пропускной способности с помощью DCB.
- SBL/CSV является трафиком с наивысшим приоритетом и получает 70 процентов от резервирования пропускной способности SMB.
- Динамическая миграция (LM) ограничена с помощью командлета Set-SMBBandwidthLimit и получает 29 процентов оставшейся пропускной способности.
  - Если доступная пропускная способность для динамической миграции составляет >5 Гбит/с и сетевые адаптеры могут работать, используйте RDMA. Для этого используйте следующий командлет:
```
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
```
  - Если доступная пропускная способность для динамической миграции составляет < 5 Гбит/с, используйте сжатие, чтобы сократить время отключения. Для этого используйте следующий командлет:
```
Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
```
Если вы используете RDMA для трафика динамической миграции, убедитесь, что трафик динамической миграции не может использовать всю пропускную способность, выделенную для класса трафика RDMA, используя ограничение пропускной способности SMB. Будьте внимательны, так как этот командлет принимает запись в байтах в секунду (bps), тогда как сетевые адаптеры перечислены в битах в секунду (bps). Используйте следующий командлет, чтобы задать ограничение пропускной способности в 6 Гбит/с, например:
```
Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
```
Примечание

750 Мбит/с в этом примере соответствует 6 Гбит/с.

Ниже приведен пример таблицы распределения пропускной способности:

Скорость сетевого адаптера	Объединяемая пропускная способность	Резервирование пропускной способности SMB**	% SBL/CSV	Пропускная способность SBL/CSV	% динамической миграции	Максимальная пропускная способность динамической миграции	% пульса	Пропускная способность пульса
10 Гбит/с	20 Гбит/с	10 Гбит/с	70 %	7 Гбит/с	**	200 Мбит/с
25 Гбит/с	50 Гбит/с	25 Гбит/с	70 %	17,5 Гбит/с	29 %	7,25 Гбит/с	1 %	250 Мбит/с
40 Гбит/с	80 Гбит/с	40 Гбит/с	70 %	28 Гбит/с	29 %	11,6 Гбит/с	1 %	400 Мбит/с
50 Гбит/с	100 Гбит/с	50 Гбит/с	70 %	35 Гбит/с	29 %	14,5 Гбит/с	1 %	500 Мбит/с
100 Гбит/с	200 Гбит/с	100 Гбит/с	70 %	70 Гбит/с	29 %	29 Гбит/с	1 %	1 Гбит/с
200 Гбит/с	400 Гбит/с	200 Гбит/с	70 %	140 Гбит/с	29 %	58 Гбит/с	1 %	2 Гбит/с

* Используйте сжатие, а не RDMA, так как выделенная пропускная способность для трафика динамической миграции составляет <5 Гбит/с.

** 50 процентов является примером резервирования пропускной способности.

Растянутые кластеры

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

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

Растянутые кластеры имеют следующие требования и характеристики.

RDMA ограничен одним сайтом и не поддерживается в разных сайтах или подсетях.
Серверы на одном сайте должны находиться в одной стойке и на границе уровня 2.
Обмен данными между узлами должен пересекать границу уровня 3; Растянутые топологии уровня 2 не поддерживаются.
Достаточно пропускной способности для выполнения рабочих нагрузок на другом сайте. В случае отработки отказа альтернативный сайт должен будет выполнять весь трафик. Рекомендуется подготавливать сайты на уровне 50 процентов от доступной сетевой емкости. Однако это не является обязательным требованием, если во время отработки отказа вы можете допускать более низкую производительность.
Репликация между сайтами (трафик с севера и юга) может использовать те же физические сетевые адаптеры, что и локальное хранилище (трафик с востока и запада). Если вы используете одни и те же физические адаптеры, их необходимо объединить с SET. Адаптеры также должны иметь дополнительные виртуальные сетевые адаптеры, подготовленные для маршрутизации трафика между сайтами.
Адаптеры, используемые для обмена данными между сайтами:
- Может быть физическим или виртуальным (виртуальный сетевой адаптер узла). Если адаптеры являются виртуальными, необходимо подготовить одну виртуальную сетевую карту в собственной подсети и виртуальной локальной сети для каждого физического сетевого адаптера.
- Должны находиться в собственной подсети и виртуальной локальной сети, которые могут маршрутизировать между сайтами.
- RDMA необходимо отключить с помощью командлета Disable-NetAdapterRDMA . Рекомендуется явно требовать, чтобы реплика хранилища использовала определенные интерфейсы с помощью командлета Set-SRNetworkConstraint .
- Должен соответствовать любым дополнительным требованиям для реплики хранилища.

Пример растянутого кластера

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

Ниже приведены сведения для примера конфигурации растянутого кластера.

Примечание

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

SiteA — локальная репликация с поддержкой RDMA, не маршрутизируемая между сайтами

имя узла	Имя виртуальной сетевой карты	Физический сетевой адаптер (сопоставленный)	Виртуальная локальная сеть	IP-адрес и подсеть	Область трафика
NodeA1	vSMB01	pNIC01	711	192.168.1.1/24	Только локальный сайт
NodeA2	vSMB01	pNIC01	711	192.168.1.2/24	Только локальный сайт
NodeA1	vSMB02	pNIC02	712	192.168.2.1/24	Только локальный сайт
NodeA2	vSMB02	pNIC02	712	192.168.2.2/24	Только локальный сайт

SiteB — локальная репликация с поддержкой RDMA, не маршрутизируемая между сайтами

имя узла	Имя виртуальной сетевой карты	Физический сетевой адаптер (сопоставленный)	Виртуальная локальная сеть	IP-адрес и подсеть	Область трафика
NodeB1	vSMB01	pNIC01	711	192.168.1.1/24	Только локальный сайт
NodeB2	vSMB01	pNIC01	711	192.168.1.2/24	Только локальный сайт
NodeB1	vSMB02	pNIC02	712	192.168.2.1/24	Только локальный сайт
NodeB2	vSMB02	pNIC02	712	192.168.2.2/24	Только локальный сайт

SiteA — растянутая репликация, RDMA отключена, маршрутизируемая между сайтами

имя узла	Имя виртуальной сетевой карты	Физический сетевой адаптер (сопоставленный)	IP-адрес и подсеть	Область трафика
NodeA1	Stretch1	pNIC01	173.0.0.1/8	Перекрестная маршрутизируемая
NodeA2	Stretch1	pNIC01	173.0.0.2/8	Перекрестная маршрутизируемая
NodeA1	Stretch2	pNIC02	174.0.0.1/8	Перекрестная маршрутизируемая
NodeA2	Stretch2	pNIC02	174.0.0.2/8	Перекрестная маршрутизируемая

SiteB — растянутая репликация, RDMA отключена, маршрутизируемая между сайтами

имя узла	Имя виртуальной сетевой карты	Физический сетевой адаптер (сопоставленный)	IP-адрес и подсеть	Область трафика
NodeB1	Stretch1	pNIC01	175.0.0.1/8	Перекрестная маршрутизируемая
NodeB2	Stretch1	pNIC01	175.0.0.2/8	Перекрестная маршрутизируемая
NodeB1	Stretch2	pNIC02	176.0.0.1/8	Перекрестная маршрутизируемая
NodeB2	Stretch2	pNIC02	176.0.0.2/8	Перекрестная маршрутизируемая

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

Сведения о требованиях к сетевому коммутатору и физической сети. См. раздел Требования к физической сети.
Узнайте, как упростить сеть узла с помощью Network ATC. См . статью Упрощение сетей узлов с помощью Network ATC.
Освежите основы отработки отказа кластеризация сети.
См. статью Развертывание с помощью портал Azure.
См . статью Развертывание с помощью шаблона ARM.

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

Типы сетевого трафика

Выбор сетевого адаптера

Требования к драйверу

Обзор основных возможностей сетевого адаптера

Динамический VMMQ

RDMA

iWARP;

RoCE.

Гостевая RDMA

Объединение внедренных коммутаторов (SET)

Рекомендации по трафику RDMA

Класс трафика кластера

Класс трафика RDMA

Класс трафика по умолчанию

Модели трафика хранилища

Выделение пропускной способности трафика

Растянутые кластеры

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

Пример растянутого кластера

SiteA — локальная репликация с поддержкой RDMA, не маршрутизируемая между сайтами

SiteB — локальная репликация с поддержкой RDMA, не маршрутизируемая между сайтами

SiteA — растянутая репликация, RDMA отключена, маршрутизируемая между сайтами

SiteB — растянутая репликация, RDMA отключена, маршрутизируемая между сайтами

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

Обратная связь

Обратная связь

Дополнительные ресурсы