Требования к сети узла для Azure Stack HCI
Область применения: Azure Stack HCI, версии 23H2 и 22H2
В этом разделе рассматриваются вопросы и требования к сети для Azure Stack HCI. Сведения об архитектуре центра обработки данных и физических подключениях между серверами см. в разделе "Требования к физической сети".
Сведения о том, как упростить сеть узлов с помощью Сетевого ATC, см. в разделе "Упрощение сети узлов" с помощью Сетевого ATC.
Типы сетевого трафика
Сетевой трафик Azure Stack HCI можно классифицировать по своей целевой цели:
- Трафик управления: трафик из локального кластера или извне. Например, трафик реплики хранилища или трафик, используемый администратором для управления кластером, таким как удаленный рабочий стол, Центр администрирования Windows, Active Directory и т. д.
- Вычислительный трафик: трафик, исходящий из виртуальной машины или предназначенный для нее.
- Трафик хранилища: трафик с помощью блока сообщений сервера (SMB), например Локальные дисковые пространства или динамической миграции на основе SMB. Этот трафик является трафиком уровня 2 и не является маршрутизируемым.
Внимание
Реплика хранилища использует трафик SMB, отличный от RDMA. Это и направление движения (Север-Юг) делает его тесно согласованным с трафиком управления, перечисленным выше, как и в традиционном файловом ресурсе.
Выбор сетевого адаптера
Сетевые адаптеры квалифицированы типами сетевого трафика (см. выше), с которыми они поддерживаются. При просмотре каталога Windows Server сертификация Windows Server 2022 теперь указывает одну или несколько следующих ролей. Прежде чем приобрести сервер для Azure Stack HCI, необходимо иметь по крайней мере один адаптер, который подходит для управления, вычислений и хранения, так как все три типа трафика необходимы в Azure Stack HCI. Затем можно использовать Сетевой ATC для настройки адаптеров для соответствующих типов трафика.
Дополнительные сведения об этой квалификации сетевого адаптера на основе ролей см. в этой ссылке.
Внимание
Использование адаптера за пределами его квалифицированного типа трафика не поддерживается.
| Уровень | Роль управления | Роль вычислений | Роль хранилища |
|---|---|---|---|
| Различие на основе ролей | Управление | Вычисление уровня "Стандартный" | Хранилище уровня "Стандартный" |
| Максимальная награда | Н/Д | Вычисление класса Premium | Хранилище класса Premium |
Примечание.
Наивысшая квалификация для любого адаптера в нашей экосистеме будет содержать квалификацию "Управление", "Вычислительные ресурсы" и "Премиум хранилища".
Требования к драйверу
Драйверы папки "Входящие" не поддерживаются для использования с Azure Stack HCI. Чтобы определить, использует ли адаптер драйвер папки "Входящие", выполните следующий командлет. Адаптер использует драйвер папки "Входящие", если свойство DriverProvider является корпорацией Майкрософт.
Get-NetAdapter -Name <AdapterName> | Select *Driver*
Общие сведения о возможностях сетевого адаптера ключей
Важные возможности сетевого адаптера, используемые Azure Stack HCI, включают:
- Динамическая виртуальная машина с несколькими очередами (динамический VMMQ или d.VMMQ)
- Удаленный доступ к памяти (RDMA)
- Гостевая RDMA
- Switch Embedded Teaming (SET)
Динамический VMMQ
Все сетевые адаптеры с квалификацией вычислений (Премиум) поддерживают Динамический VMMQ. Для динамического VMMQ требуется использование встроенной команды switch Embedded.
Применимые типы трафика: вычисления
Необходимые сертификаты: вычисления (премиум)
Dynamic VMMQ — это интеллектуальная, приемная технология. Он основывается на своих предшественниках очереди виртуальных машин (VMQ), масштабирования на стороне виртуального приема (vRSS) и VMMQ, чтобы обеспечить три основных улучшения:
- Оптимизирует эффективность узла с помощью меньшего количества ядер ЦП.
- Автоматическая настройка обработки сетевого трафика на ядра ЦП, что позволяет виртуальным машинам соответствовать ожидаемой пропускной способности и поддерживать ожидаемую пропускную способность.
- Позволяет "всплеску" рабочих нагрузок получать ожидаемый объем трафика.
Дополнительные сведения о Dynamic 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 | No | Да |
| Intel | Да | Да (некоторые модели) |
| Marvell (Qlogic) | Да | Да |
| Nvidia | No | Да |
Дополнительные сведения о развертывании RDMA для узла настоятельно рекомендуется использовать Сетевой ATC. Сведения о развертывании вручную см. в репозитории SDN GitHub.
iWARP
iWARP использует протокол TCP и может быть дополнительно улучшен с помощью управления потоками на основе приоритета (PFC) и расширенной службы передачи (ETS).
Используйте iWARP, если:
- У вас нет опыта управления сетями RDMA.
- Вы не управляете или неудобно управляете коммутаторами верхнего уровня (ToR).
- После развертывания вы не будете управлять решением.
- У вас уже есть развертывания, использующие iWARP.
- Вы не уверены, какой вариант выбрать.
RoCE
RoCE использует протокол пользовательской диаграммы данных (UDP) и требует PFC и ETS для обеспечения надежности.
Используйте RoCE, если:
- У вас уже есть развертывания с помощью RoCE в центре обработки данных.
- Вы комфортно управляете требованиями к сети DCB.
Гостевая RDMA
Гостевая RDMA позволяет рабочим нагрузкам SMB для виртуальных машин получить те же преимущества использования RDMA на узлах.
Применимые типы трафика: гостевой хранилище
Необходимые сертификаты: вычисления (премиум)
Основными преимуществами использования гостевой RDMA являются:
- Разгрузка ЦП в сетевую карту для обработки сетевого трафика.
- Крайне низкая задержка.
- Высокая пропускная способность.
Дополнительные сведения см. в репозитории SDN GitHub.
Switch Embedded Teaming (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 сетевой ATC автоматически обнаружит и сообщит вам, являются ли выбранные адаптеры асимметричными. Самый простой способ вручную определить, являются ли адаптеры симметричными, если скорость и описание интерфейса совпадают. Они могут отклоняться только в числовых значениях, перечисленных в описании. Используйте командлет, чтобы убедиться, Get-NetAdapterAdvancedProperty что в конфигурации перечислены те же значения свойств.
См. следующую таблицу для примера описаний интерфейса, различающихся только по числовым значениям (#):
| Имя. | Описание интерфейса | Скорость связи |
|---|---|---|
| NIC1 | Сетевой адаптер #1 | 25 Гбит/с |
| NIC2 | Сетевой адаптер #2 | 25 Гбит/с |
| NIC3 | Сетевой адаптер #3 | 25 Гбит/с |
| NIC4 | Сетевой адаптер #4 | 25 Гбит/с |
Примечание.
SET поддерживает только независимую от коммутатора конфигурацию с помощью алгоритмов балансировки нагрузки динамических портов или Hyper-V. Для лучшей производительности рекомендуется использовать порт Hyper-V во всех сетевых адаптерах, которые работают со скоростью 10 Гбит/с или выше. Сетевой ATC делает все необходимые конфигурации для SET.
Рекомендации по трафику RDMA
При реализации DCB необходимо убедиться, что конфигурация PFC и ETS реализована правильно по каждому сетевому порту, включая сетевые коммутаторы. DCB требуется для RoCE и необязательно для iWARP.
Дополнительные сведения о развертывании RDMA скачайте документ из репозитория SDN GitHub.
Для реализации Azure Stack HCI на основе RoCE требуется настройка трех классов трафика PFC, включая класс трафика по умолчанию в структуре и всех узлах.
Класс трафика кластера
Этот класс трафика гарантирует, что для пульса кластера достаточно пропускной способности:
- Обязательный: да
- С поддержкой PFC: Нет
- Рекомендуемый приоритет трафика: приоритет 7
- Рекомендуемое резервирование пропускной способности:
- 10 ГбE или более низкие сети RDMA = 2 процента
- 25 ГбE или более высокие сети RDMA = 1 процент
Класс трафика RDMA
Этот класс трафика обеспечивает достаточную пропускную способность, зарезервированную для обмена данными RDMA без потери с помощью SMB Direct:
- Обязательный: да
- С поддержкой PFC: Да
- Рекомендуемый приоритет трафика: приоритет 3 или 4
- Рекомендуемое резервирование пропускной способности: 50 процентов
Класс трафика по умолчанию
Этот класс трафика содержит весь другой трафик, не определенный в кластере или классах трафика RDMA, включая трафик виртуальной машины и трафик управления:
- Обязательный: по умолчанию (конфигурация на узле не требуется)
- Элемент управления потоком (PFC): нет
- Рекомендуемый класс трафика: по умолчанию (приоритет 0)
- Рекомендуемое резервирование пропускной способности: по умолчанию (конфигурация узла не требуется)
Модели трафика хранилища
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), в то время как сетевые адаптеры перечислены в битах в секунду (в секунду). Используйте следующий командлет, чтобы задать ограничение пропускной способности 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 выглядит следующим образом:
Требования к растянутом кластеру
Внимание
Функции растянутого кластера доступны только в Azure Stack HCI версии 22H2.
Растянутые кластеры имеют следующие требования и характеристики:
RDMA ограничен одним сайтом и не поддерживается в разных сайтах или подсетях.
Серверы на одном сайте должны находиться в одной стойке и границе уровня 2.
Взаимодействие узла между сайтами должно пересекать границу уровня 3; Топологии растянутого слоя 2 не поддерживаются.
Достаточно пропускной способности для запуска рабочих нагрузок на другом сайте. В случае отработки отказа альтернативный сайт потребуется запустить весь трафик. Рекомендуется подготавливать сайты на 50 процентов своей доступной сетевой емкости. Однако это не обязательно, если вы можете терпеть более низкую производительность во время отработки отказа.
Адаптеры, используемые для обмена данными между сайтами:
Может быть физическим или виртуальным (виртуальным сетевым адаптером узла). Если адаптеры являются виртуальными, необходимо подготовить одну виртуальную сетевую карту в собственной подсети и виртуальной локальной сети на физический сетевой адаптер.
Должен находиться в собственной подсети и виртуальной локальной сети, которая может направляться между сайтами.
RDMA необходимо отключить с помощью командлета
Disable-NetAdapterRDMA. Рекомендуется явно требовать, чтобы реплика хранилища использовала определенные интерфейсы с помощью командлетаSet-SRNetworkConstraint.Должны соответствовать любым дополнительным требованиям для реплики хранилища.
Пример растянутого кластера
В следующем примере показана конфигурация растянутого кластера. Чтобы убедиться, что определенный виртуальный сетевой адаптер сопоставлен с определенным физическим адаптером, используйте командлет Set-VMNetworkAdapterTeammapping .
Ниже приведены сведения о примере растянутой конфигурации кластера.
Примечание.
Ваша точную конфигурацию, включая имена сетевых адаптеров, IP-адреса и виртуальные локальные сети, может отличаться от того, что показано. Это используется только в качестве эталонной конфигурации, которая может быть адаптирована к вашей среде.
SiteA — локальная репликация, включенная RDMA, не routable между сайтами
| имя узла | Имя виртуальной сетевой карты | Физическая сетевая карта (сопоставленная) | Виртуальная ЛС | 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, не routable между сайтами
| имя узла | Имя виртуальной сетевой карты | Физическая сетевая карта (сопоставленная) | Виртуальная ЛС | 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, routable между сайтами
| имя узла | Имя виртуальной сетевой карты | Физическая сетевая карта (сопоставленная) | IP-адрес и подсеть | Область трафика |
|---|---|---|---|---|
| NodeA1 | Stretch1 | pNIC01 | 173.0.0.1/8 | Перекрестная перекрестная routable |
| NodeA2 | Stretch1 | pNIC01 | 173.0.0.2/8 | Перекрестная перекрестная routable |
| NodeA1 | Stretch2 | pNIC02 | 174.0.0.1/8 | Перекрестная перекрестная routable |
| NodeA2 | Stretch2 | pNIC02 | 174.0.0.2/8 | Перекрестная перекрестная routable |
SiteB — растянутая репликация, отключенная RDMA, routable между сайтами
| имя узла | Имя виртуальной сетевой карты | Физическая сетевая карта (сопоставленная) | IP-адрес и подсеть | Область трафика |
|---|---|---|---|---|
| NodeB1 | Stretch1 | pNIC01 | 175.0.0.1/8 | Перекрестная перекрестная routable |
| NodeB2 | Stretch1 | pNIC01 | 175.0.0.2/8 | Перекрестная перекрестная routable |
| NodeB1 | Stretch2 | pNIC02 | 176.0.0.1/8 | Перекрестная перекрестная routable |
| NodeB2 | Stretch2 | pNIC02 | 176.0.0.2/8 | Перекрестная перекрестная routable |
Следующие шаги
- Сведения о сетевом коммутаторе и требованиях к физической сети. См. сведения о требованиях к физической сети.
- Узнайте, как упростить сеть узлов с помощью Сетевого ATC. См. статью "Упрощение сети" с помощью Сетевого ATC.
- Кисть на основе базовых принципов отказоустойчивой кластеризации.
- См. статью "Развертывание с помощью портал Azure".
- См. раздел "Развертывание с помощью шаблона Azure Resource Manager".
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по