Рекомендации по сети для облачных развертываний 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Даже если намерение управления объявлено без намерения вычислений, Network ATC создает виртуальный коммутатор Switch Embedded Teaming (SET), чтобы обеспечить высокий уровень доступности в сети управления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#	Condition
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 или любой другой виртуальной машины инфраструктуры, необходимой во время развертывания. Невозможно задать идентификатор виртуальной локальной сети управления во время облачного развертывания из портал 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 $true

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

После создания виртуального коммутатора и связанного сетевого адаптера управления убедитесь, что имя сетевого адаптера соответствует стандартам именования Network ATC.

В частности, имя виртуального сетевого адаптера, используемого для трафика управления, должно использовать следующие соглашения:

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

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

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string “vEthernet” to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

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-адреса узла.

Логика проверки сети, используемая во время облачного развертывания, завершится ошибкой, если она обнаруживает несколько физических сетевых интерфейсов, имеющих шлюз по умолчанию в конфигурации. Если вам нужно использовать DHCP для назначений IP-адресов узла, необходимо предварительно создать виртуальный коммутатор SET (коммутатор встроенной команды) и адаптер виртуальной сети управления, как описано выше, поэтому только адаптер виртуальной сети управления получает IP-адрес с DHCP-сервера.

Рекомендации по 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, описаны в параметрах сети кластера. Рекомендуется использовать значения по умолчанию. При этом при необходимости можно переопределить следующие параметры с помощью портал Azure или шаблонов Resource Manager:

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

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

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

Следующие шаги

• О развертывании Azure Stack HCI версии 23H2.