Рекомендации по сети для облачных развертываний Azure Stack HCI версии 23H2

Применимо к: Azure Stack HCI версии 23H2

В этой статье описывается, как спроектировать и спланировать системную сеть Azure Stack HCI версии 23H2 для развертывания в облаке. Прежде чем продолжить, ознакомьтесь с различными сетевыми шаблонами и доступными конфигурациями Azure Stack HCI .

Платформа проектирования сети

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

Шаг 1. Определение размера кластера

Чтобы определить размер системы Azure Stack HCI, используйте средство размера Azure Stack HCI, где можно определить свой профиль, например количество виртуальных машин, размер виртуальных машин и использование рабочей нагрузки виртуальных машин, таких как Виртуальный рабочий стол Azure, SQL Server или AKS.

Как описано в статье Требования к системным серверам Azure Stack HCI, максимальное количество серверов, поддерживаемых в системе Azure Stack HCI, составляет 16. После завершения планирования емкости рабочей нагрузки вы должны иметь хорошее представление о количестве узлов сервера, необходимых для выполнения рабочих нагрузок в вашей инфраструктуре.

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

• Если для рабочих нагрузок требуется три или меньше узлов: для подключения к хранилищу можно выбрать конфигурации без переключения или переключения.

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

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

Решение	Оценка
Размер кластера (количество узлов на кластер)	Без переключения конфигурация с помощью портал Azure или шаблонов ARM доступна только для кластеров с 1, 2 или 3 узлами. Для кластеров с 4 или более узлами требуется физический коммутатор для сетевого трафика хранилища.
Требования к горизонтальному масштабированию	Если вы планируете масштабировать кластер с помощью оркестратора, необходимо использовать физический коммутатор для сетевого трафика хранилища.

Шаг 2. Определение подключения к хранилищу кластера

Как описано в разделе Требования к физической сети, Azure Stack HCI поддерживает два типа подключения для сетевого трафика хранилища:

• Используйте физический сетевой коммутатор для обработки трафика.
• Напрямую подключите узлы между ними с помощью кроссоверных сетевых или оптоволоконных кабелей для трафика хранилища.

Преимущества и недостатки каждого варианта описаны в статье, связанной выше.

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

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

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

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

Ниже приведены сводные рекомендации по решению о подключении к хранилищу кластера.

Решение	Оценка
Нет переключателя для хранилища	Без переключения конфигурация с помощью портал Azure или развертывания шаблона ARM поддерживается только для кластеров с 1, 2 или 3 узлами. Бессерверные кластеры хранилища с 1 или 2 узлами можно развернуть с помощью шаблонов портал Azure или ARM. Коммутированные кластеры хранилища с 3 узлами можно развернуть только с помощью шаблонов ARM. Операции горизонтального увеличения масштаба не поддерживаются в бесключежных развертываниях. Любое изменение числа узлов после развертывания требует ручной настройки. При использовании бесключенной конфигурации хранилища требуется по крайней мере 2 сетевых намерения.
Сетевой коммутатор для хранилища	Если вы планируете масштабировать кластер с помощью оркестратора, необходимо использовать физический коммутатор для сетевого трафика хранилища. Эту архитектуру можно использовать с любым количеством узлов от 1 до 16. Хотя не применяется, вы можете использовать одно намерение для всех типов сетевого трафика (управление, вычисления и хранилище).

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

Шаг 3. Определение намерений сетевого трафика

Для Azure Stack HCI все развертывания используют network ATC для конфигурации сети узла. Сетевые намерения настраиваются автоматически при развертывании Azure Stack HCI с помощью портал Azure. Дополнительные сведения о намерениях сети и способах их устранения см. в статье Общие команды ATC сети.

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

Доступные варианты сетевых намерений рассматриваются в следующих разделах.

Сетевое намерение: группирование всего трафика

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

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

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

• Для поддержки трафика RDMA для хранилища требуются сетевые интерфейсы не менее 10 Гбит/с.

Сетевое намерение: управление группами и вычислительный трафик

Network ATC настраивает два намерения. Первое намерение включает в себя сетевой трафик управления и вычислений, а второе — только сетевой трафик хранилища. Каждое намерение должно иметь отдельный набор портов сетевого адаптера.

Этот параметр можно использовать как для переключения, так и для подключения к хранилищу без переключения, если:

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

• Физический коммутатор используется для RDMA, если вы используете сетевой коммутатор для хранения.

• Для поддержки трафика RDMA для хранилища требуются сетевые интерфейсы не менее 10 Гбит/с.

Сетевое намерение: группирование трафика вычислений и хранилища

Network ATC настраивает два намерения. Первое намерение включает сетевой трафик вычислений и хранения, а второе — только сетевой трафик управления. Каждое намерение должно использовать отдельный набор портов сетевого адаптера.

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

• Для этого параметра требуется физический коммутатор для RDMA.

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

• Для вычислительных ресурсов и хранилища для поддержки трафика RDMA рекомендуется использовать сетевые интерфейсы не менее 10 Гбит/с.

• Даже если намерение управления объявлено без намерения вычислений, ATC сети создает виртуальный коммутатор set для обеспечения высокой доступности сети управления.

Намерение сети: настраиваемая конфигурация

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

• Используйте этот параметр для переключения и без переключения подключения к хранилищу, если намерение хранилища отличается от других намерений.

• Используйте этот параметр, если требуется другое намерение вычислений или если требуется полностью разделить отдельные типы трафика через разные сетевые адаптеры.

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

• Для вычислительных ресурсов и хранилища для поддержки трафика RDMA рекомендуется использовать сетевые интерфейсы не менее 10 Гбит/с.

На следующей схеме перечислены варианты сетевых намерений, доступные для различных развертываний.

Шаг 4. Определение сетевого подключения управления

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

Следующие компоненты подсети инфраструктуры необходимо спланировать и определить перед началом развертывания, чтобы можно было спроецировать требования к маршрутизации, брандмауэру или подсети.

Драйверы сетевого адаптера

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

Пул IP-адресов управления

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

Чтобы обеспечить достаточное количество IP-адресов в диапазоне для текущих и будущих служб инфраструктуры, необходимо использовать диапазон не менее шести последовательных доступных IP-адресов. Эти адреса используются для IP-адреса кластера, виртуальной машины Azure Resource Bridge и ее компонентов.

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

При определении пула IP-адресов для подсети инфраструктуры во время развертывания должны выполняться следующие условия:

#	Условие
1	Диапазон IP-адресов должен использовать последовательные IP-адреса, и все IP-адреса должны быть доступны в этом диапазоне.
2	Диапазон IP-адресов не должен включать IP-адреса управления узлами кластера, но должен находиться в той же подсети, что и узлы.
3	Шлюз по умолчанию, определенный для пула IP-адресов управления, должен обеспечивать исходящее подключение к Интернету.
4	DNS-серверы должны обеспечивать разрешение имен с помощью Active Directory и Интернета.

Идентификатор виртуальной локальной сети управления

Рекомендуется, чтобы подсеть управления кластера Azure HCI использовала виртуальную локальную сеть по умолчанию, которая в большинстве случаев объявлена как виртуальная локальная сеть с идентификатором 0. Однако если требования к сети связаны с использованием определенной виртуальной локальной сети управления для сети инфраструктуры, ее необходимо настроить на физических сетевых адаптерах, которые планируется использовать для управления трафиком.

Если вы планируете использовать два физических сетевых адаптера для управления, необходимо настроить виртуальную локальную сеть на обоих адаптерах. Это необходимо сделать в рамках конфигурации начальной загрузки серверов и перед их регистрацией в Azure Arc, чтобы убедиться, что узлы успешно регистрируются с помощью этой виртуальной локальной сети.

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

В этом примере настраивается идентификатор 44 виртуальной локальной сети в физическом сетевом адаптере NIC1.

Set-NetAdapter -Name "NIC1" -VlanID 44

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

Идентификатор виртуальной локальной сети управления с виртуальным коммутатором

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

Примечание

Перед созданием виртуального коммутатора обязательно включите роль Hype-V. Дополнительные сведения см. в разделе Установка требуемой роли Windows.

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

1. Создание виртуального коммутатора с рекомендуемыми соглашениями об именовании

Развертывания Azure Stack HCI используют сетевой ATC для создания и настройки виртуальных коммутаторов и виртуальных сетевых адаптеров для управления, вычислений и хранения. По умолчанию, когда ATC сети создает виртуальный коммутатор для намерений, он использует определенное имя для виртуального коммутатора.

Хотя это и не обязательно, рекомендуется именовать виртуальные коммутаторы с тем же соглашением об именовании. Для виртуальных коммутаторов рекомендуется использовать следующее имя:

• Имя виртуального коммутатора: "ConvergedSwitch($IntentName)", где $IntentName может быть любой строкой. Эта строка должна соответствовать имени виртуального сетевого адаптера для управления, как описано в следующем шаге.

В следующем примере показано, как создать виртуальный коммутатор с помощью PowerShell, используя рекомендуемое соглашение об именовании с $IntentName описанием назначения виртуального коммутатора. Список имен сетевых адаптеров — это список физических сетевых адаптеров, которые вы планируете использовать для управления и вычисления сетевого трафика:

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $false

2. Настройка виртуального сетевого адаптера управления с использованием обязательного соглашения об именовании сетевых ATC для всех узлов

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

• Имя сетевого адаптера и виртуального сетевого адаптера: vManagement($intentname).
• Имя учитывает регистр.
• $Intentname Может быть любой строкой, но должен иметь то же имя, которое используется для виртуального коммутатора.

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

$IntentName = "MgmtCompute"
Add-VMNetworkAdapter -ManagementOS -SwitchName "ConvergedSwitch($IntentName)" -Name "vManagement($IntentName)"

#NetAdapter needs to be renamed because during creation, Hyper-V adds the string “vEthernet “ to the beginning of the name

Rename-NetAdapter -Name "vEthernet (vManagement($IntentName))" -NewName "vManagement($IntentName)"

3. Настройка идентификатора виртуальной локальной сети для управления виртуальным сетевым адаптером для всех узлов

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

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

В следующем примере показано, как настроить виртуальный сетевой адаптер управления для использования идентификатора виртуальной локальной сети 8 вместо значения по умолчанию.

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID

4. Ссылка на физические сетевые адаптеры для намерения управления во время развертывания

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

Примечание

Не выбирайте виртуальный сетевой адаптер для сетевого намерения.

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

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

#	Рекомендации
1	Идентификатор виртуальной локальной сети должен быть указан в физическом сетевом адаптере для управления перед регистрацией серверов в Azure Arc.
2	Перед регистрацией серверов в Azure Arc используйте определенные действия, если требуется виртуальный коммутатор.
3	Идентификатор виртуальной локальной сети управления переносится из конфигурации узла в виртуальные машины инфраструктуры во время развертывания.
4	Входной параметр идентификатора виртуальной локальной сети отсутствует для развертывания портал Azure или для развертывания шаблона ARM.

Назначение IP-адресов узла и кластера

Для системы Azure Stack HCI можно назначить IP-адреса для узлов сервера и ДЛЯ IP-адреса кластера.

• Поддерживаются как статические, так и dhcp-протоколы.

• Правильное назначение IP-адреса узла является ключевым фактором для управления жизненным циклом кластера. Прежде чем регистрировать узлы в Azure Arc, выберите между статическими параметрами и параметрами DHCP.

• Виртуальные машины инфраструктуры и службы, такие как Arc Resource Bridge и сетевой контроллер, продолжают использовать статические IP-адреса из пула IP-адресов управления. Это означает, что даже если вы решите использовать DHCP для назначения IP-адресов узлам и IP-адресам кластера, пул IP-адресов управления по-прежнему требуется.

В следующих разделах рассматриваются последствия каждого варианта.

Назначение статического IP-адреса

Если для узлов используются статические IP-адреса, пул IP-адресов управления используется для получения доступного IP-адреса и его автоматического назначения IP-адресу кластера во время развертывания.

Важно использовать IP-адреса управления для узлов, которые не входят в диапазон IP-адресов, определенный для пула IP-адресов управления. IP-адреса узла сервера должны находиться в одной подсети определенного диапазона IP-адресов.

Рекомендуется назначить только один IP-адрес управления для шлюза по умолчанию и для настроенных DNS-серверов для всех физических сетевых адаптеров узла. Это гарантирует, что IP-адрес не изменится после создания намерения сети управления. Это также гарантирует, что узлы сохраняют исходящие подключения во время развертывания, в том числе во время регистрации Azure Arc.

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

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

Назначение IP-адресов DHCP

Если IP-адреса узлов получены с DHCP-сервера, для IP-адреса кластера также используется динамический IP-адрес. Виртуальным машинам и службам инфраструктуры по-прежнему требуются статические IP-адреса. Это означает, что диапазон адресов пула IP-адресов управления должен быть исключен из ОБЛАСТЬ DHCP, используемого для узлов и IP-адреса кластера.

Например, если диапазон IP-адресов управления определен как от 192.168.1.20/24 до 192.168.1.30/24 для статических IP-адресов инфраструктуры, dhcp-область, определенный для подсети 192.168.1.0/24, должен иметь исключение, эквивалентное пулу IP-адресов управления, чтобы избежать конфликтов IP-адресов со службами инфраструктуры. Мы также рекомендуем использовать резервирования DHCP для IP-адресов узлов.

Процесс определения IP-адреса управления после создания намерения управления включает использование MAC-адреса первого физического сетевого адаптера, выбранного для намерения сети. Затем этот MAC-адрес назначается виртуальному сетевому адаптеру, созданному для целей управления. Это означает, что IP-адрес, который первый физический сетевой адаптер получает от DHCP-сервера, является тем же IP-адресом, который виртуальный сетевой адаптер использует в качестве IP-адреса управления. Поэтому важно создать резервирование DHCP для IP-адреса узла.

Рекомендации по IP-адресу узла кластера

Ниже приведены сводные рекомендации по IP-адресам.

#	Рекомендации
1	IP-адреса узла должны находиться в одной подсети определенного диапазона пула IP-адресов управления, независимо от того, статические или динамические адреса.
2	Пул IP-адресов управления не должен содержать IP-адреса узлов. Используйте исключения DHCP при использовании динамического назначения IP-адресов.
3	Используйте как можно больше резервирований DHCP для узлов.
4	DHCP-адреса поддерживаются только для IP-адресов узлов и IP-адресов кластера. Службы инфраструктуры используют статические IP-адреса из пула управления.
5	MAC-адрес первого физического сетевого адаптера назначается адаптеру виртуальной сети управления после создания намерения сети управления.

Требования к прокси

Для доступа к Интернету в локальной инфраструктуре, скорее всего, потребуется прокси-сервер. Azure Stack HCI поддерживает только конфигурации прокси-серверов без проверки подлинности. Учитывая, что для регистрации узлов в Azure Arc требуется доступ к Интернету, конфигурация прокси-сервера должна быть задана как часть конфигурации ОС перед регистрацией узлов сервера. Дополнительные сведения см. в разделе Настройка параметров прокси-сервера.

Ос Azure Stack HCI имеет три разные службы (WinInet, WinHTTP и переменные среды), для которых требуется одинаковая конфигурация прокси-сервера, чтобы все компоненты ОС могли получить доступ к Интернету. Та же конфигурация прокси-сервера, используемая для узлов, автоматически переносится на виртуальную машину Arc Resource Bridge и AKS, обеспечивая доступ к Интернету во время развертывания.

Ниже приведены сводные рекомендации по настройке прокси-сервера.

#	Оценка
1	Настройка прокси-сервера должна быть завершена перед регистрацией узлов в Azure Arc.
2	Та же конфигурация прокси-сервера должна применяться к переменным Среды WinINET, WinHTTP и .
3	Средство проверки среды гарантирует согласованность конфигурации прокси-сервера во всех компонентах прокси-сервера.
4	Настройка прокси-сервера виртуальной машины Arc Resource Bridge и AKS автоматически выполняется оркестратором во время развертывания.
5	Поддерживаются только прокси-серверы без проверки подлинности.

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

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

Настройка брандмауэра должна быть выполнена перед регистрацией узлов в Azure Arc. Вы можете использовать автономную версию средства проверки среды, чтобы убедиться, что брандмауэры не блокируют трафик, отправляемый на эти конечные точки. Дополнительные сведения см. в статье Проверка среды Azure Stack HCI для оценки готовности к развертыванию для Azure Stack HCI.

Ниже приведены сводные рекомендации по брандмауэру.

#	Оценка
1	Настройка брандмауэра должна быть выполнена перед регистрацией узлов в Azure Arc.
2	Для проверки конфигурации брандмауэра можно использовать средство проверки среды в автономном режиме.

Шаг 5. Определение конфигурации сетевого адаптера

Сетевые адаптеры квалифицируются по типу сетевого трафика (управление, вычисления и хранилище), с которыми они используются. При проверке каталога Windows Server сертификация Windows Server 2022 указывает, к какому сетевому трафику относятся адаптеры.

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

Значения по умолчанию, используемые atc network atc, описаны в разделе Параметры сети кластера. Рекомендуется использовать значения по умолчанию. При этом при необходимости можно переопределить следующие параметры с помощью портал Azure или шаблонов ARM:

• Виртуальные локальные сети хранилища. Задайте для этого значения необходимые виртуальные локальные сети для хранилища.
• Пакеты Jumbo: определяет размер пакетов jumbo.
• Прямая сеть. Задайте для этого значения значение false, если вы хотите отключить RDMA для сетевых адаптеров.
• Технология Network Direct. Задайте для этого значения значение RoCEv2 или iWarp.
• Управление приоритетами трафика для центров обработки данных (DCB): задайте приоритеты, соответствующие вашим требованиям. Мы настоятельно рекомендуем использовать значения DCB по умолчанию, так как они проверяются корпорацией Майкрософт и клиентами.

Ниже приведены сводные рекомендации по настройке сетевого адаптера.

#	Оценка
1	Используйте конфигурации по умолчанию как можно больше.
2	Физические коммутаторы должны быть настроены в соответствии с конфигурацией сетевого адаптера. См. статью Требования к физической сети для Azure Stack HCI.
3	Убедитесь, что сетевые адаптеры поддерживаются для Azure Stack HCI с помощью каталога Windows Server.
4	При принятии значений по умолчанию ATC сети автоматически настраивает IP-адреса сетевого адаптера хранилища и виртуальные локальные сети. Это называется автоматической IP-конфигурацией хранилища. В некоторых случаях автоматический IP-адрес хранилища не поддерживается, и необходимо объявить каждый IP-адрес сетевого адаптера хранилища с помощью шаблонов ARM.

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

• Сведения об Azure Stack HCI версии 23H2.