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

Область применения: Azure Local 2311.2 и более поздних версий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Set-NetAdapter -Name "NIC1" -VlanID 44

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

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

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

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

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

Локальные развертывания Azure зависят от Network ATC для создания и настройки виртуальных коммутаторов и адаптеров виртуальной сети с целью управления, вычислений и работы с хранилищем. По умолчанию, когда сетевая ATC создаёт виртуальный коммутатор для заданного использования, используется определённое имя виртуального коммутатора.

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

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

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

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

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

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

Пользовательские IP-адреса для хранилища

По умолчанию сетевая ATC автоматически назначает IP-адреса и VLAN для сетевого хранилища из следующей таблицы:

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

• enableStorageAutoIP: Этот параметр, если не указан, по умолчанию принимает значение true. Чтобы включить пользовательские IP-адреса хранилища во время развертывания, этот параметр должен иметь значение false.
• storageAdapterIPInfo: Этот параметр имеет зависимость с параметром enableStorageAutoIP и всегда требуется, если для параметра автоматического IP-адреса хранилища задано значение false. В параметре storageAdapterIPInfo в шаблоне ARM также потребуется указать параметры ipv4Address и subnetMask для каждого узла и сетевого адаптера с собственными IP-адресами и маской подсети.
• vlanId: Как описано выше в таблице, этот параметр будет использовать сети ATC по умолчанию, если их не нужно изменять. Однако если эти виртуальные локальные сети по умолчанию не работают в сети, вы можете указать собственные идентификаторы виртуальной локальной сети для каждой из сетей хранения.

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

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

Для локальной инстанции Azure у вас есть два варианта назначения 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-адресам:

Рекомендации по DNS-серверу

Для локальных развертываний Azure на основе Active Directory требуется DNS-сервер, который может разрешать локальный домен и общедоступные конечные точки Интернета. В рамках развертывания необходимо определить те же DNS-серверы для диапазона IP-адресов инфраструктуры, который настроен на узлах. Виртуальная машина уровня управления Azure Resource Bridge и контрольная плоскость AKS будут использовать те же DNS-серверы для разрешения имен. После завершения развертывания не поддерживается изменение IP-адресов DNS-серверов и невозможно обновить адреса в стеке локальной платформы Azure.

DNS-серверы, используемые для локальной службы Azure, должны быть внешними и операционными перед развертыванием. Они не поддерживаются как локальные виртуальные машины Azure.

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

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сведения о локальном развертывании Azure.