Рекомендации по работе с сетью для облачных развертываний 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 или Azure Resource Manager доступна только для кластеров с 1, 2 или 3 узлами. Для кластеров с 4 или более узлами требуется физический коммутатор для сетевого трафика хранилища.
Требования к горизонтальному масштабированию	Если вы планируете масштабировать кластер с помощью оркестратора, необходимо использовать физический коммутатор для сетевого трафика хранилища.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Network 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-адресов подряд. Эти адреса используются для IP-адреса кластера, виртуальной машины Azure Resource Bridge и его компонентов.

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

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

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

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

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

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

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

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

Set-NetAdapter -Name "NIC1" -VlanID 44

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

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

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

Примечание

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

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

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

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

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

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

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

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

2. Настройка виртуального сетевого адаптера управления с использованием обязательного соглашения об именовании network 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 "8"

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

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

Примечание

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

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

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

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

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

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

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

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

• Виртуальные машины инфраструктуры и службы, такие как мост ресурсов Arc и сетевой контроллер, продолжают использовать статические 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 и переменные среды), которым требуется одинаковая конфигурация прокси-сервера для обеспечения доступа всех компонентов ОС к Интернету. Та же конфигурация прокси-сервера, используемая для узлов, автоматически переносится на виртуальную машину Resource Bridge Arc и AKS, обеспечивая доступ к Интернету во время развертывания.

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

#	Оценка
1	Настройка прокси-сервера должна быть завершена перед регистрацией узлов в Azure Arc.
2	Для переменных среды WinINET, WinHTTP и переменных среды должна применяться та же конфигурация прокси-сервера.
3	Средство проверки среды гарантирует согласованность конфигурации прокси-сервера во всех компонентах прокси-сервера.
4	Настройка прокси-сервера виртуальной машины Resource Bridge Arc и 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 требуются все три типа трафика. Развертывание в облаке использует Network ATC для настройки сетевых адаптеров для соответствующих типов трафика, поэтому важно использовать поддерживаемые сетевые адаптеры.

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

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

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

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

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

• Сведения о развертывании Azure Stack HCI версии 23H2.