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

Область применения: гиперконвергентные развертывания локальной среды Azure

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

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

Проектирование сети хоста для экземпляра Azure Local требует принятия более 10 взаимосвязанных решений — о режиме подключения, архитектуре, физической топологии, размере кластера, подключении к хранилищу, портах сетевых адаптеров, профилях сетевого трафика, IP-адресации, VLAN, резервном копировании, исходящей связи и программно-определяемой сети. Структурированная платформа помогает:

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

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

Платформа проектирования сети — это последовательность 11 решений для вашего Azure Local экземпляра. Сначала вы определяете режим подключения, а затем выбираете архитектуру, которая направляет проектирование по гиперконвергентному (HCI) или дезагрегированному (DA) пути. Каждое последующее решение документирует оба варианта и завершается списком проектных соображений:

1. Определение режима подключения
2. Определение архитектуры
3. Определение топологии кластера
4. Определение размера кластера
5. Определение подключения к хранилищу
6. Определение портов и конфигурации сетевого адаптера
7. Определение намерений сетевого трафика
8. Определение IP-адресов управления и сети инфраструктуры
9. Определение сети резервного копирования
10. Определение исходящего подключения
11. Определение программно-определяемой сети (SDN)

Решение 1. Определение режима подключения

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

• Подключенные: узлы и службы инфраструктуры достигают Azure через Интернет напрямую, через корпоративный прокси-сервер или через шлюз Azure Arc или через частный путь, использующий ExpressRoute или VPN типа "сеть — сеть". Этот режим является наиболее распространенным и требуется для стандартного облачного развертывания. Вы планируете детали исходящего подключения в решении 10.
• Изолированная среда (air-gapped): для суверенных, регулируемых или изолированных сред Azure Local в отключенном режиме предоставляет локальную конечную точку Autonomous Cloud вместо публичных конечных точек Azure. При изолированном развертывании используется локальная плоскость управления Azure Arc, развернутая в выделенном кластере управления из 3 узлов.

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

Решение 2. Определение архитектуры

Архитектурное решение направляет проектирование по одному из двух путей. Он определяет архитектуру хранилища, размер кластера и намерения сети, доступные для вас в остальной части этой статьи.

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

Каждое решение в этой платформе документирует обе архитектуры параллельно, с отдельными разделами гиперконвергентных (HCI) и разделенных (DA). Следуйте инструкциям по проектированию архитектуры, выбранной здесь.

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

Решение 3. Определение топологии кластера

Решение топологии кластера определяет физический макет узлов и коммутаторов. Доступные параметры зависят от архитектуры, выбранной в решении 2.

Стандартная физическая фигура для обеих архитектур — это одна стойка с парой коммутаторов верхнего уровня (ToR):

• Пара коммутаторов ToR, настроенная с использованием многокорпусной агрегации каналов (MLAG), с поддержкой до 16 узлов в одной стойке.
• Один коммутатор для контроллера управления материнской платой (BMC) для внеполосного управления над коммутаторами ToR.
• Исходящие подключения к существующему коммутатору ядра, маршрутизатору или брандмауэру.

Гиперконвергентная инфраструктура (HCI)

Гиперконвергентный кластер использует одну стойку или схему размещения с учетом стоек:

• Одна стойка: все узлы и пара коммутаторов ToR находятся в одной стойке, поддерживая до 16 узлов. В коммутируемых схемах весь трафик узла — управляющий, вычислительный и трафик хранения данных — проходит через одну и ту же пару коммутаторов.

• С учетом стоек (две зоны): Кластер с учетом стоек распределяет гиперконвергентное развертывание между двумя помещениями или зонами доступности:

  • Чётное количество узлов, до 8 узлов, распределённых между двумя помещениями и назначенных двум зонам доступности кластера.
  • Для репликации S2D между серверными комнатами требуется задержка менее 1 мс.
  • Трафик хранилища RDMA остается на уровне ToR и никогда не проходит по позвоночнику.

  Для кластеров с учетом стоечной топологии доступны четыре варианта аплинка:

  Опция	Topology	Примечания.
  1. Ссылки на выделенное хранилище	2 ToR в каждом номере (всего 4)	TOR1↔TOR3 в VLAN 711, TOR2↔TOR4 на VLAN 712.
  2. Агрегированные ссылки на хранилище	2 ToR в каждом номере (всего 4)	СХД использует LAG/vPC между комнатами; возможны дополнительный сетевой переход и задержка RDMA по сравнению с вариантом 1.
  3. Подключение узлов для каждой комнаты	1 ToR за комнату (2 итого)	Обе сети хранения используют один и тот же ToR в каждой комнате; объединённый межкомнатный канал связи.
  4. Связность узлов между комнатами	1 ToR за комнату (2 итого)	Каждый сервер подключен к коммутаторам ToR в обеих комнатах; это снижает зависимость между коммутаторами ToR, но увеличивает объём кабельной разводки.

Дезагрегированное (DA)

Разделенный кластер может охватывать 1 до 8 стоек:

• Одна стойка: пары HSRP из двух коммутаторов достаточно для поддержки до 16 узлов. Сети кластера работают через выделенные сетевые порты и не управляются Network ATC.
• Несколько стоек: если узлов больше 16, распределите кластер между не более чем 8 стойками, соединёнными по топологии leaf-spine (Clos): каждая стойка оснащена двумя вычислительными leaf-коммутаторами, а над стойками расположены два spine-коммутатора и два service leaf-коммутатора. Каждая стойка содержит до 16 узлов, а кластер масштабируется до не более 64 узлов. Поддерживается только SDN на основе структуры; Microsoft SDN не поддерживается.

Дополнительные сведения об архитектуре сети leaf-spine, потоке трафика и о том, как выбрать эталонный шаблон для разукрупнённых развертываний, см. в разделах Обзор эталонных шаблонов сети для разукрупнённых развертываний и Выбор эталонного шаблона сети для разукрупнённых развертываний.

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

Решение 4. Определение размера кластера

Чтобы определить размер экземпляра Azure Local, используйте инструмент подбора конфигурации Azure Local или средство подбора конфигурации сообщества, включенное в Odin for Azure Local, где можно задать профиль, например количество виртуальных машин (VM), их размер и типы рабочих нагрузок для этих виртуальных машин, такие как Виртуальный рабочий стол Azure, SQL Server или AKS.

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

Гиперконвергентная инфраструктура (HCI)

Гиперконвергентный кластер поддерживает от 1 до 16 узлов. Количество узлов определяет параметры подключения к хранилищу в решении 5.

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

Дезагрегированное (DA)

Дезагрегированный кластер позволяет независимо масштабировать вычислительные ресурсы и ресурсы хранения в пределах от 1 до 8 стоек, поддерживая до 16 узлов на стойку и максимум 64 узла в кластере. Емкость хранилища не зависит от количества узлов, так как хранилище предоставляется внешним SAN, а не локальными дисками.

Поддерживаемые конфигурации развертывания

Сочетание числа узлов и варианта хранилища определяет, поддерживается ли конфигурация развертывания и требуются ли для неё шаблоны Resource Manager:

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

Решение 5. Определение подключения к хранилищу

Как описано в требованиях к физической сети, параметры подключения к хранилищу зависят от архитектуры, выбранной в решении 2. Если вы не переопределите их с помощью шаблонов Resource Manager, все шаблоны Локальные дисковые пространства (S2D) используют следующие значения по умолчанию хранилища ATC сети:

Гиперконвергентная инфраструктура (HCI)

Гиперконвергированные развертывания используют Локальные дисковые пространства с одним из двух типов подключения к хранилищу:

• Коммутируемое хранилище: Используйте физический сетевой коммутатор для передачи трафика хранилища. Коммутируемое хранилище поддерживает от 1 до 16 узлов и горизонтальное масштабирование.
• Хранилище без коммутатора: напрямую соедините узлы друг с другом кроссовыми сетевыми или оптоволоконными кабелями для трафика системы хранения. Хранилище без переключения поддерживается только для кластеров с 1 до 4 узлов (жесткое ограничение верхнего предела) и не поддерживает горизонтальное масштабирование.

Преимущества и недостатки вариантов с коммутатором и без коммутатора описаны в статье, ссылка на которую приведена выше.

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

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

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

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

Для хранилища без переключения число подсетей хранилища увеличивается с числом узлов, так как каждый узел нуждается в прямом подключении к каждому другому узлу. Число подсетей хранилища равно N × (N – 1), где N — это число узлов:

Дополнительные сведения об определении пользовательских IP-адресов хранилища см. в разделе "Пользовательские IP-адреса для хранилища".

Гибридное хранилище (S2D и внешний SAN)

Azure Local поддерживает подключение внешней сети SAN к гиперконвергированному кластеру, чтобы хранилище с поддержкой SAN работало параллельно с встроенным Локальные дисковые пространства (S2D). Внешняя SAN всегда подключается в рамках операции после развертывания (на второй день): сначала развертывается стандартный гиперконвергентный кластер с S2D, а затем к нему подключается SAN. Вы не можете с самого начала развернуть гибридную конфигурацию, поэтому заранее спланируйте инфраструктуру SAN и адаптеры, даже если подключать их будете уже после запуска кластера. Это позволяет выбирать тома S2D или внешние тома SAN для каждой рабочей нагрузки для виртуальных машин, кластеров AKS и Виртуальный рабочий стол Azure (AVD). Несколько томов SAN представляются как общие тома кластера (CSV), отформатированные в NTFS, и каждый CSV отображается как путь к папке, который вы сопоставляете с путем к хранилищу виртуальных машин. Общедоступны две интеграции:

• Массивы SAN Fibre Channel (FC): каждый узел подключается к SAN через две фабрики Fibre Channel (Fabric A и Fabric B) для обеспечения отказоустойчивости с помощью адаптеров главной шины (HBA) на каждом хосте. Тома, поддерживаемые SAN, обнаруживаются как CSV NTFS и совместно используются между узлами, а вычислительные ресурсы и хранилище масштабируются независимо.
• SAN на базе IP (Ethernet): каждый узел подключается к массиву через сеть хранения Ethernet — с помощью стандартного инициатора iSCSI или клиента хранения, предоставляемого поставщиком, — и монтирует удалённые блочные тома в кластер, используя многопутевой ввод-вывод через резервированные фабрики. Тома представлены как общие тома кластера (CSV) NTFS и совместно используются всеми узлами, а вычислительные ресурсы и хранилище масштабируются независимо друг от друга. Эти решения обычно используют выделенные подсети для хранилища, джамбо-кадры и агрегацию/объединение сетевых интерфейсов. Являются ли эти подсети хранилища маршрутизируемыми, зависит от архитектуры вашей сети хранения: в одних развертываниях хосты подключаются напрямую к выделенным коммутаторам хранения в изолированных немаршрутизируемых подсетях, тогда как в других трафик хранения маршрутизируется из сети центра обработки данных. Поддерживаемое количество узлов, пределы масштабирования и точное значение MTU для jumbo-кадров зависят от поставщика хранилища и валидации Azure Local.

С точки зрения проектирования сети:

• Сеть хранения S2D остается без изменений по сравнению с исходным развертыванием с коммутаторами или без них.
• Для подключения SAN используются отдельные коммутационные фабрики и адаптеры (FC HBA или сетевые адаптеры для SAN на основе IP), и оно не управляется Network ATC. Запланируйте выделенные порты для подключения к SAN, а для IP-блочного хранилища — выделенные подсети хранилища с jumbo-кадрами (с маршрутизацией или без маршрутизации, в зависимости от архитектуры вашей сети хранения).
• Кластеры с поддержкой стоек не поддерживаются внешним хранилищем SAN для гиперконвергентных развертываний.

Дополнительные сведения см. в разделе External storage support for Azure Local.

Дезагрегированное (DA)

Если вы используете внешнюю SAN — Fiber Channel или SAN на базе IP (например, iSCSI или PowerFlex SDC), — ни Локальные дисковые пространства, ни профиль RDMA для хранилища не управляются Network ATC. В обоих случаях:

• Управление и вычислительный трафик настраиваются с помощью сетевого ATC с помощью виртуального коммутатора Switch Embedded Teaming (SET).
• Сети кластера — общий том кластера (CSV) и трафик динамической миграции через SMB Multichannel— выполняются на автономных сетевых портах, которые не управляются сетевыми ATC. Спланируйте выделенные VLAN и подсети для этих сетей. Виртуальные сети кластера по умолчанию: 1711 и 1712.
• Настройте качество обслуживания Ethernet (QoS) для сетей кластера. Решение 6 описывает рекомендуемый класс схемы приоритета службы (CoS) и распределения пропускной способности.

Структура хранилища отличается от типа SAN:

• Fiber Channel (FC): система хранения данных полностью работает в инфраструктуре FC, отдельно от сети Ethernet. Не требуется ни QoS хранилища в сети Ethernet, ни управление приоритетным потоком (PFC), ни Ethernet без потерь — весь трафик кластера передаётся по TCP через SMB Multichannel.
• SAN на базе IP: доступ к системе хранения осуществляется через выделенные адаптеры Ethernet для подключения к SAN на базе IP. Он заменяет Локальные дисковые пространства и отказывается от RDMA, а поскольку весь трафик (IP-трафик SAN, CSV, динамическая миграция и heartbeat кластера) передаётся по TCP, Ethernet без потерь и PFC не требуются. Убедитесь, что модель массива SAN поддерживается перед развертыванием.

Развертывания iSCSI соответствуют проверенной схеме, выбранной в решении 6.

• Выделенный путь: 6 портов: выделенные порты используются для путей iSCSI A и B отдельно от сетей кластера. Этот шаблон поддерживает дополнительную сеть резервного копирования внутри гостевой ОС, которую можно добавить после развертывания как резервный виртуальный сетевой адаптер (vNIC) хоста для ролей управления и вычислений. Он не использует выделенный адаптер резервного копирования.

Дополнительные сведения о подключении внешней сети SAN, включая конфигурацию на стороне узла и на стороне массива для Fibre Channel и iSCSI, см. в статье "Подключение внешнего массива хранилища к Azure Local и поддержке внешнего хранилища для Azure Local".

Статические маршруты узла iSCSI

Для развертываний iSCSI только интерфейс управления имеет шлюз по умолчанию. Интерфейсы кластера и iSCSI имеют IP-адреса без шлюза по умолчанию. Чтобы получить доступ к целевым устройствам iSCSI, расположенным через один или несколько переходов уровня 3, настройте на каждом хосте постоянный статический маршрут /32 для IP-адреса каждого целевого устройства iSCSI, указав в качестве следующего узла шлюз leaf-коммутатора (виртуальный интерфейс коммутатора) в VLAN iSCSI и привязав маршрут к адаптеру хранилища. Статические маршруты принудительно направляют трафик iSCSI через адаптер хранилища и предотвращают его попадание в сеть управления. В конфигурации многопатокового ввода-вывода (MPIO) каждый путь iSCSI должен иметь собственный статический маршрут к тем же целевым объектам по соответствующей виртуальной локальной сети. Если массив предоставляет множество целевых IP-адресов в одной подсети, можно направлять всю целевую подсеть через соответствующий шлюз путей вместо добавления одного маршрута на целевой объект. Вы настраиваете инициатор iSCSI, статические маршруты и MPIO во время установки операционной системы.

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

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

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

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

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

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

Решение 6. Определение портов и конфигурации сетевого адаптера

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

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

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

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

• VLANы хранилища: Установите это значение на требуемые VLANы для хранилища.
• Пакеты Jumbo: определяет размер пакетов jumbo. Рекомендуется использовать максимальную единицу передачи (MTU) 9216 байт для трафика хранилища RDMA. Настройте тот же MTU на физических коммутаторах. Для внешних сетей хранения SAN (гибридных или дезагрегированных) требуемое значение MTU для jumbo-кадров зависит от поставщика системы хранения и может отличаться от значения MTU для S2D — например, 9216 байт для сетей хранения с RDMA и значение, указанное поставщиком (например, 9014 байт), для сетей блочного хранения на базе IP. Используйте значение MTU, указанное вашим поставщиком системы хранения, и настройте одинаковое значение на всем пути между узлами и коммутаторами.
• Network Direct: задайте для этого параметра значение false, если вы хотите отключить RDMA для сетевых адаптеров.
• Сетевая прямая технология: установите это значение на RoCEv2 или iWarp.
• Приоритеты трафика для центра обработки данных (DCB): задайте приоритеты, соответствующие вашим требованиям. Мы настоятельно рекомендуем использовать значения DCB по умолчанию, так как они проверяются Microsoft и клиентами.

Гиперконвергентная инфраструктура (HCI)

В гиперконвергентных развертываниях используется 2, 4, 6 или 8 портов сетевого адаптера на каждом узле в зависимости от того, как вы группируете трафик в интенты в Решении 7. Скорость каждого порта и возможность RDMA должны соответствовать трафику, который он несет:

• 2 порта: одна политика «Группировать весь трафик». SET объединяет первые два физических адаптера (например, pNIC01 и pNIC02). Все типы трафика используют одни и те же порты. Требуется не менее 10 Гбит/с; рекомендуется 25 GbE или выше.
• 4 порта: намерение управления и вычислений в Port1 и Port2 (SET) плюс выделенное намерение хранилища в Port3 и Port4. Назначение хранилища не использует SET; вместо этого оно использует SMB Multichannel для отказоустойчивости и агрегации пропускной способности.
• 6 портов: отдельные назначения: управления (Port1 и Port2, SET), вычислений (Port3 и Port4, SET) и хранилища (Port5 и Port6, SMB Multichannel).
• 8 портов: добавьте второе назначение для вычислений или резервного копирования на оставшихся портах для дополнительного разделения трафика.

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

Дезагрегированное (DA)

В разугрегированных развертываниях используется макет порта Ethernet, который зависит от типа SAN. Определите структуру по количеству сетевых портов и роли каждого порта, а не по форм-фактору физического адаптера. Во всех случаях два сетевых порта используются для профиля Management and compute (команда SET, управляемая Network ATC), а отдельная пара сетевых портов используется для сетей кластера — пульса кластера, Cluster Shared Volume (CSV) и Live Migration по SMB Multichannel — в виде отдельных портов, не управляемых Network ATC. Как эти порты распределяются между физическими адаптерами — это выбор OEM-производителя: эти порты могут обеспечиваться одним многопортовым адаптером (например, четырёхпортовым адаптером OCP), двумя отдельными адаптерами (например, встроенным адаптером OCP и дополнительным адаптером) или двумя встроенными адаптерами. Виртуальные сети кластера по умолчанию: 1711 и 1712. Каждый отдельный порт кластера и хранилища использует один VLAN, поэтому вы можете настроить этот VLAN как VLAN доступа (native) на порту ToR и оставить интерфейс хоста нетегированным — см. раздел QoS для кластера и хранилища. Сведения о полной схеме коммутаторов, кабельных соединений и расположения портов для каждого типа SAN см. в эталонных схемах разукрупнённой сети.

Fibre Channel (FC)

В развертываниях FC используется 4-портовая или 6-портовая схема портов Ethernet на каждом узле. Каждый сервер также использует двухпортовые адаптеры главной шины FC (HBA) (порт A к коммутатору FC A, порт B к коммутатору FC B) для подключения к SAN отдельно от сетевых портов Ethernet:

• 4 порта: управление и вычисление сетевых портов 1 и 2 (SET) и кластерных сетей на автономных сетевых портах 3 и 4.
• 6 портов (гостевая резервная копия): идентичны макету 4-порта, а также намерение вычислений гостевой резервной копии сетевых портов 5 и 6 (SET) для гостевого трафика резервного копирования. Дополнительные сведения см. в решении 9.

iSCSI

Развертывания iSCSI используют этот проверенный шаблон. Адаптеры хранилища должны иметь по крайней мере 10 ГбE (25 ГбE или выше для рабочих нагрузок с высокой пропускной способностью):

• Выделенный 6-порт: два сетевых порта для управления и вычислений (SET), два автономных сетевых порта для сетей кластера (VLAN 1711 и 1712) и два дополнительных автономных сетевых порта для выделенного сетевого пути ISCSI A (VLAN 300) и пути B (VLAN 400). Этот шаблон поддерживает необязательную сеть резервного копирования, как описано в решении 9.

Кластер и хранилище QoS

Весь разделенный трафик хранилища и кластера выполняется по протоколу TCP: SMB Multichannel для сетей кластера (CSV, Live Migration и heartbeat) и iSCSI по протоколу TCP для хранения. TCP управляет перегрузкой и восстанавливается после потерь пакетов с помощью собственных механизмов повторной передачи и управления перегрузкой, поэтому такая архитектура не требует ни Ethernet без потерь, ни управления трафиком на стороне хоста. Не настраивайте следующие параметры в кластерах и портах хранилища:

• Управление потоком на основе приоритета (PFC) или очереди без потерь. PFC обеспечивает передачу без потерь для RDMA/RoCE, что не используется в дезагрегированных развертываниях. В TCP-структуре PFC добавляет операционный риск — приостановка распространения, блокировка головы линии и потоки жертв без преимуществ.
• Технология Data Center Bridging (DCB) на стороне узла или Enhanced Transmission Selection (ETS). ETS хоста и класс обслуживания 802.1p (CoS) — это механизмы канального уровня (уровня 2), действующие на каждом переходе. Они влияют только на связь между узлами, и их гарантии пропускной способности не расширяются по структуре.

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

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

Jumbo-кадры по-прежнему оправданы и не зависят от принятого выше решения относительно QoS, поскольку через порты кластера передаются CSV и Live Migration по SMB — объёмные передачи данных, которым выгодно использование меньшего числа более крупных пакетов. Вы не настраиваете их вручную: Azure Local применяет MTU jumbo-frame, указанный на портале Azure или шаблоне ARM во время развертывания на адаптерах узлов, поэтому на узлах не требуется выполнять команды адаптера. Необходимо настроить тот же MTU на портах физического коммутатора самостоятельно, так как Azure Local не настраивает коммутаторы— обычное связывание — MTU 9000 на узле и 9216 на коммутаторе.

Поскольку QoS на хосте отсутствует, портам автономного кластера и хранилища не требуется сохранять приоритет 802.1p, и каждый из этих портов поддерживает только один VLAN. Таким образом, вы можете настроить эту VLAN как VLAN доступа (native) на порту ToR и оставить интерфейс хоста нетегированным — на хостах тегирование VLAN не требуется:

• Сети кластеров: задайте для виртуальных сетей кластера два порта кластера (например, 1711 и 1712).
• iSCSI, 6-портовая конфигурация с выделенным путем: назначьте два выделенных порта iSCSI соответствующим VLAN хранилища (например, 300 и 400).

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

Требования к физическому коммутатору

Для переключенных (гиперконвергентных) и разъединенных развертываний физические коммутаторы верхнего уровня (ToR) должны поддерживать следующие возможности для надежного переноса трафика кластера:

• Управление потоком с приоритетом (PFC) для трафика RDMA без потерь (IEEE 802.1Qbb).
• Расширенный выбор передачи (ETS) для распределения пропускной способности между классами трафика (IEEE 802.1Qaz).
• Джамбо-кадры с MTU не менее 9216 байт.
• Явное уведомление о перегрузке (ECN) для развертываний RoCEv2.
• Агрегирование каналов между несколькими шасси (MLAG) для отказоустойчивых пар ToR.

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

Решение 7. Определение намерений сетевого трафика

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

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

Гиперконвергентная инфраструктура (HCI)

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

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

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

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

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

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

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

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

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

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

• Этот параметр требует физического коммутатора для трафика хранилища, так как те же порты используются для вычислительного трафика, для которого требуется связь между севером и югом. Если требуется конфигурация без переключателей, вы не можете использовать этот тип интента. Портал Azure автоматически отфильтровывает этот параметр при выборе конфигурации без переключения для подключения к хранилищу.
• Для этого параметра требуется физический коммутатор для RDMA.
• Рекомендуется использовать по крайней мере два порта сетевого адаптера для обеспечения высокого уровня доступности.
• Рекомендуется использовать сетевой интерфейс с пропускной способностью не менее 10 Гбит/с для поддержки трафика RDMA в вычислительных и хранилищных системах.
• Даже если намерение управления объявлено без намерения вычислений, Network ATC создает виртуальный коммутатор Switch Embedded Teaming (SET), чтобы обеспечить высокий уровень доступности в сети управления.

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

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

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

Дезагрегированное (DA)

Для дезагрегированных развертываний доступ к массиву хранения осуществляется через Fibre Channel или iSCSI, поэтому намерение RDMA для хранилища отсутствует. Используйте следующее:

• Намерение для управления и вычислений, настроенное через Network ATC с использованием виртуального коммутатора SET.
• Сети кластеров (пульс кластера, CSV и динамическая миграция через SMB Multichannel), которые выполняются на автономных сетевых портах за пределами Сети ATC, как описано в решении 5.
• Для iSCSI каналы iSCSI представляют собой отдельные порты, которыми Network ATC не управляет. Они предназначены для 6-портовой схемы.
• Необязательное назначение Гостевое резервное копирование при использовании конфигурации с 6 портами (FC) или конфигурации с 6 портами и выделенным путём (iSCSI), как описано в решении 9.

Поддерживаемые группировки намерений

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

Ниже приведены краткие рекомендации по принятию решения о намерениях сетевого трафика:

Решение 8. Определение IP-адресов управления и сети инфраструктуры

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

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

Зарезервированные диапазоны IP-адресов, которых следует избегать

При развертывании Azure Local платформа резервирует два внутренних CIDR Kubernetes —10.96.0.0/12 для служб Kubernetes и 10.244.0.0/16 для сети pod. Плоскость управления Azure Resource Bridge (ARB) работает на этой внутренней платформе Kubernetes, а все кластеры Azure Kubernetes Service (AKS), которые вы разворачиваете, используют те же диапазоны адресов. Если любая Azure Local конфигурация перекрывает эти диапазоны, развертывание может завершиться ошибкой или проблемами с подключением, которые сложно устранить.

Поскольку 10.96.0.0/12 — это внутренняя сеть службы Kubernetes платформы, ни один IP-адрес инфраструктуры Azure Local, а также ни одна из основных служб инфраструктуры, к которым кластер должен иметь доступ, например DNS и прокси-сервер, не могут находиться в этой сети. С узлов и виртуальных машин инфраструктуры любой трафик, отправленный в адрес, 10.96.0.0/12 обрабатывается внутренне и никогда не достигает реального назначения. Спланируйте следующее, чтобы все они сидели на улице 10.96.0.0/12:

• IP-адреса узлов кластера и IP-адрес кластера.
• Виртуальная машина Azure Resource Bridge и другие IP-адреса виртуальных машин инфраструктуры, а также пул IP-адресов управления, из которого они выделяются.
• DNS-серверы и прокси-сервер, которые использует инфраструктура.

Диапазон 10.244.0.0/16 pod подпадает под то же ограничение: любой IP-адрес инфраструктуры, IP-адрес узла или логическая сеть, размещённые в этом диапазоне, будут конфликтовать с сетью pod.

При развертывании AKS на Azure Local одни и те же зарезервированные диапазоны добавляют еще два требования для рабочих нагрузок AKS:

• Логическая сеть AKS не может перекрывать зарезервированные диапазоны. Логическая сеть (LNET), в которую вы развертываете кластеры AKS, не должна пересекаться с 10.96.0.0/12 (службами Kubernetes) или 10.244.0.0/16 (подами).
• AKS не может достичь частных конечных точек внутри 10.96.0.0/12. Любая частная конечная точка, от которой зависят рабочие нагрузки AKS, например Реестр контейнеров Azure (ACR), Azure Key Vault или конечные точки служба хранилища Azure, не должна иметь IP-адрес в пределах 10.96.0.0/12. Из виртуальной машины уровня управления AKS или рабочего узла этот диапазон является внутренней сетью службы Kubernetes, поэтому трафик к любому адресу в нем обрабатывается внутренне и никогда не достигает реальной конечной точки. Если в этой среде уже размещены закрытые конечные точки или другие службы, к которым AKS должен иметь доступ в этом пространстве, перенесите их за его пределы перед развертыванием AKS.

Служба и CIDR pod в настоящее время не могут быть изменены, поэтому запланируйте сеть, чтобы избежать этих диапазонов, а не ожидать их перемещения. Помимо инфраструктуры Azure Local, конечных точек, к которым она должна обращаться, и AKS, эти диапазоны не резервируют и не ограничивают остальное адресное пространство вашего центра обработки данных — важно лишь, чтобы с ними не пересекались адреса служб, к которым подключается сам кластер. Полные требования к планированию адресов AKS, включая развертывания с несколькими стойками, см. в разделе "Планирование IP-адресов" для AKS на Azure Local.

Зарезервированные диапазоны, которых следует избегать

Следующие диапазоны IP-адресов зарезервированы внутренне платформой Kubernetes (используется как мостом ресурсов Arc, так и AKS) и не должны использоваться для любого компонента инфраструктуры Azure Local:

Что необходимо проверить перед развертыванием

Убедитесь, что ни один из следующих IP-адресов локальной инфраструктуры Azure не попадает в зарезервированные диапазоны выше:

Безопасные диапазоны IP-адресов для использования

Ниже приведены примеры часто используемых диапазонов частных IP-адресов, которые не будут конфликтуть:

Справочные материалы по IP-планированию

• Требования к планированию IP-адресов для AKS
• Назначенные диапазоны IP-адресов для моста ресурсов Arc

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

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

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

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

Во время развертывания средство проверки окружения проверяет ICMP-связность с адресов пула IP-адресов управления к шлюзу по умолчанию для пула IP-адресов управления. Убедитесь, что шлюз по умолчанию разрешает трафик ICMP из подсети управления Azure Local.

Ниже приведены краткие рекомендации по пулу IP-адресов управления:

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

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

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

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

Set-NetAdapter -Name "NIC1" -VlanID 44

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

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

Идентификатор 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
   

   Примечание.

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

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)"
   

   Примечание.

   Во время проверки развертывания все vSwitch на узлах должны иметь соответствующие vNIC. Если существуют vSwitches, но отсутствуют соответствующие vNICs, операция завершается с ошибкой, указанной ниже.

   "Не удалось завершить операцию. 200: на узлах присутствуют виртуальные переключатели, но отсутствуют vNIC, этот сценарий не поддерживается.

   Убедитесь, что имена адаптеров совпадают между выходными данными Get-NetAdapter и Get-VMNetworkAdapter -ManagementOS. Если они не соответствуют, переименуйте сетевые адаптеры перед повторным развертыванием.

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-адресов узла и кластера

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

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

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

DNS-серверы, используемые для локальной службы Azure, должны быть внешними и операционными перед развертыванием. Не поддерживается запуск всех настроенных DNS-серверов в качестве виртуальных машин в одном экземпляре Azure Local, который зависит от них. Так как узлы кластера, мост ресурсов Azure и AKS нуждаются в разрешении имен во время загрузки и перед запуском виртуальных машин рабочей нагрузки, по крайней мере один из настроенных DNS-серверов должен выполняться за пределами экземпляра Azure Local. Кластер, который полностью зависит от DNS-виртуальных машин, размещённых в нём самом, не может разрешать имена во время полного отключения, перезапуска или восстановления, когда эти виртуальные машины ещё недоступны. Если вы запускаете DNS как виртуальные машины в кластере для локального разрешения, сохраните по крайней мере один независимый внешний DNS-сервер в настроенном списке.

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

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

Решение 9. Определение сети резервного копирования

Определите, требуется ли развертывание выделенной сети резервного копирования для трафика резервного копирования гостевой (виртуальной машины). Это решение относится как к гиперконвергентным, так и к дезагрегированным архитектурам.

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

Гиперконвергентная инфраструктура (HCI)

Для гиперконвергированных развертываний добавьте выделенную сеть резервного копирования в качестве второй цели вычислений, используя модель целей Custom configuration, описанную в Decision 7. Назначьте два дополнительных порта сетевого адаптера намерению резервного копирования для обеспечения высокой доступности.

Дезагрегированное (DA)

Поддержка сети резервного копирования зависит от типа SAN и макета адаптера, выбранного в решении 6.

• Fiber Channel: используйте схему с 6 портами, которая добавляет назначение вычислений гостевого резервного копирования на сетевых портах 5 и 6 (SET) в дополнение к назначениям управления и вычислений, а также сетям кластера.
• iSCSI 6-порт (выделенный путь): поддерживает необязательную сеть резервного копирования. При включении резервного копирования порты управления и вычислений (сетевые порты 1 и 2) объединяются в SET-коммутатор, управляемый NetworkATC, который размещает виртуальный сетевой адаптер управления узла и передаёт VLAN резервного копирования клиента в транковом режиме. Выделенный кластер и порты iSCSI (сетевые порты 3, 4, 5 и 6) не затронуты. Клиент вручную создаст на узле vNIC гостевой резервной копии поверх виртуального коммутатора, управляемого Network ATC.

Сведения о справочных шаблонах Fiber Channel с резервной сетью и без резервной сети см. в дезагрегированном шаблоне Fiber Channel с резервной сетью и дезагрегированном шаблоне Fiber Channel без резервной сети.

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

Решение 10. Определение исходящего подключения

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

Для сред, изолированных от сети, используйте режим отключенных операций Azure Local, который предоставляет локальную конечную точку Autonomous Cloud вместо общедоступных конечных точек Azure. Дополнительные сведения см. в решении 1.

шлюз Azure Arc

Шлюз Azure Arc сокращает количество общедоступных конечных точек, необходимых для развертывания и работы Azure Local с более чем 100 до менее 30. Развертывание с поддержкой Arc Gateway основано на четырех компонентах:

• Агент Arc: выполняется на каждом узле и подключает его к плоскости управления Azure Arc.
• Arc-прокси: локальная служба прямого прокси, которая является частью агентской службы Arc и запускается на каждом узле. Если шлюз Arc включен в Azure Local, прокси-сервер Arc перенаправляет поддерживаемый трафик HTTPS через туннель шлюза Arc. Узлы обращаются к собственному прокси Arc локально на localhost:40343, а виртуальная машина Azure Resource Bridge, а также виртуальные машины плоскости управления и рабочие виртуальные машины AKS обращаются к нему через IP-адрес кластера по порту 40343.
• IP-адрес кластера: это единый сервер переадресации, используемый Azure Resource Bridge и AKS. IP-адрес кластера перемещается между узлами для обеспечения высокой доступности, поэтому перенаправляемый HTTPS-трафик виртуальных машин Azure Resource Bridge и AKS всегда проходит через прокси-сервер Arc на том узле, которому в данный момент назначен IP-адрес кластера. При устранении неполадок с этим трафиком анализируйте журналы прокси-сервера Arc на узле, который в настоящее время владеет IP-адресом кластера, а не на других узлах.
• Ресурс шлюза Arc: управляемая Azure точка входа, адресованная как <gatewayId>.gw.arc.azure.com.

Если шлюз Arc включен, каждый компонент направляет исходящий трафик через конкретный прокси-сервер. HTTPS-трафик ОС узла использует локальный прокси-сервер Arc узла (http://localhost:40343), а виртуальная машина Azure Resource Bridge, а также виртуальные машины плоскости управления и рабочих узлов AKS используют IP-адрес кластера через порт 40343. Azure Local виртуальные машины с поддержкой Arc используют собственный выделенный прокси-сервер Arc. В каждом случае прокси-сервер Arc перенаправит только поддерживаемые конечные точки HTTPS, управляемые Microsoft, через туннель шлюза Arc.

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

Дополнительные сведения о том, как работает шлюз Arc и как создать ресурс шлюза, см. в разделе "Сведения о шлюзе Azure Arc" для Azure Local. Сведения о регистрации компьютеров через шлюз см. в статье "Регистрация Azure Local компьютеров с Azure Arc с помощью шлюза Arc". Подробное описание каждого потока исходящего трафика (ОС узла, Azure Resource Bridge, AKS и виртуальные машины Azure Local) со схемами см. в статье Arc gateway outbound connectivity deep dive.

Перед регистрацией узлов выполните следующие предварительные требования:

• Создайте ресурс шлюза Arc в подписке, в которой вы планируете развернуть Azure Local.
• Откройте брандмауэр для конечных точек шлюза Arc и отключите проверку SSL на них.
• Если вы используете корпоративный прокси-сервер, добавьте необходимые подсети, имена узлов, имя кластера и полное доменное имя частной конечной точки в список обхода прокси-сервера перед регистрацией Arc.

Даже при использовании шлюза Arc примерно 23 полных доменных имен остаются в брандмауэре периметра или списке разрешений прокси-сервера, в том числе:

• Два загрузочных полных доменных имени и шесть полных доменных имен для регистрации Arc.
• Конечная точка шлюза Arc (<gatewayId>.gw.arc.azure.com).
• Конечные точки списка отзыва сертификатов (CRL) должны использоваться только по HTTP, так как шлюз Arc поддерживает только HTTPS.
• Azure Key Vault (vault.azure.net) и учетной записи хранения-свидетеля (blob.core.windows.net) для развертывания.

Полный список текущих конечных точек см. в разделе "Требования к брандмауэру".

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

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

Прокси-сервер, скорее всего, необходим для доступа к Интернету из локальной инфраструктуры. С Azure Local 2506 вы больше не настраиваете прокси-сервер узла вручную. Вместо этого вы предоставляете корпоративный прокси-сервер и список обхода прокси-сервера один раз во время регистрации Arc, а скрипт регистрации Arc автоматически настраивает прокси-сервер во всех трех компонентах операционной системы — WinINET, WinHTTP и переменных среды на каждом узле. Вы можете предоставить сведения о прокси-сервере с помощью скрипта регистрации Arc или интерактивно с помощью приложения Configurator. Дополнительные сведения см. в разделе "Настройка параметров прокси-сервера".

Та же конфигурация прокси-сервера автоматически переносится на виртуальную машину Arc Resource Bridge и AKS во время развертывания, поэтому эти компоненты имеют доступ к Интернету без дополнительных действий вручную. При использовании шлюза Arc скрипт регистрации устанавливает прокси-сервер HTTPS узла на локальный прокси-сервер Arc (http://localhost:40343) и направляет HTTP-трафик к корпоративному прокси-серверу, а также добавляет необходимые внутренние конечные точки в список обхода каждого компонента автоматически.

Поддерживаются только не прошедшие проверку подлинности прокси-серверы. Файлы автоматической настройки прокси-сервера (PAC) и конечные точки прокси-сервера, использующие .local домен (например,), http://proxy.contoso.localне поддерживаются.

При определении списка обхода прокси-сервера следуйте этим правилам форматирования, чтобы внутренний трафик правильно прошел прокси-сервер:

• Включите, как минимум, IP-адрес каждого Azure Local компьютера, IP-адреса кластера и IP-адреса сети инфраструктуры. Arc Resource Bridge, AKS и будущие службы инфраструктуры используют эти IP-адреса. Кроме того, можно обойти всю подсеть инфраструктуры.
• Включите имя NetBIOS каждого компьютера и кластера.
• Для внутренних доменов можно использовать доменное имя с подстановочным знаком звездочки (*), например *.contoso.com. Для подсетей используйте нотацию подстановочных знаков, например 192.168.1.*.
• Разделяйте записи запятыми. Нотация CIDR для обхода подсетей не поддерживается.

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

Частный путь

Частный маршрут — топология 5 в предыдущей таблице. Он сохраняет весь исходящий трафик Azure Local в частном подключении путем объединения шлюза Azure Arc с явным прокси-сервером Брандмауэр Azure, поэтому узлы достигают Azure через Azure ExpressRoute или VPN типа "сеть — сеть" вместо общедоступного Интернета. Выберите эту топологию, если политика регулирования или безопасности запрещает исходящий трафик через общедоступный Интернет.

Чтобы использовать частный путь, экземпляр Azure Local должен запускать программное обеспечение версии 2608 или более поздней. Выпуски до версии 2608 не поддерживают архитектуру частного пути.

Перед развертыванием планируйте следующие компоненты:

• виртуальная сеть Azure с по крайней мере одной подсетью рабочей нагрузки и подсетью с именем AzureFirewallSubnet, размером /26 или больше.
• Брандмауэр Azure уровня "Стандартный" или "Премиум". Функция явного прокси-сервера недоступна на уровне "Базовый". Включите явный прокси-сервер в политике брандмауэра и запишите частный IP-адрес брандмауэра, который становится конечной точкой прокси-сервера для HTTP и HTTPS.
• ресурс шлюза Azure Arc в той же подписке, где вы регистрируете компьютеры Azure Local.
• Azure ExpressRoute или VPN типа "сеть — сеть" из локальной среды в виртуальную сеть с настроенной маршрутизацией, чтобы каждый компьютер смог добраться до частного IP-адреса Брандмауэр Azure до начала регистрации Arc.

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

Частный путь также имеет следующие ограничения поддержки:

• Явный прокси Брандмауэр Azure используется в качестве прямого прокси-сервера. Azure Local не поддерживает проверку TLS на необходимых конечных точках.
• Не удается применить сертификаты TLS к явному прокси-серверу Брандмауэр Azure.
• Microsoft не проверяет и не поддерживает любые варианты архитектуры частного пути, отличной от описанной в документации.

Сведения об архитектуре, потоках трафика для каждого сценария и схемах см. в статье "Что такое сеть частного пути для Azure Local? Инструкции по развертыванию см. в разделе "Регистрация Azure Local с помощью шлюза Azure Arc и частного пути".

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

Приватные конечные точки

Вы можете использовать частные конечные точки Приватный канал Azure, чтобы направлять трафик к поддерживаемым службам Azure PaaS по частному сетевому маршруту через Azure ExpressRoute или VPN-подключение типа "сеть — сеть". Частные конечные точки поддерживаются во всех пяти исходящих топологиях для таких служб, как служба хранилища Azure (BLOB-объект), Azure SQL, Azure Key Vault, Реестр контейнеров Azure (ACR) и Azure Site Recovery. Дополнительные сведения о поддерживаемых сценариях и конфигурации для каждого из них см. в разделе О частных конечных точках Azure в Azure Local.

При планировании частных конечных точек следуйте этим правилам:

• Избегайте пересечения с зарезервированными диапазонами: IP-адреса частных конечных точек не должны попадать в 10.244.0.0/16 (модули AKS) или 10.96.0.0/12 (службы Kubernetes). Перекрывающаяся конечная точка рассматривается как внутренний трафик кластера и никогда не выходит за пределы виртуальной сети. Например, конечная точка на 10.244.1.4 завершается сбоем, а 10.245.0.5 маршрутизируется корректно.
• Оставляйте критически важные службы общедоступными во время развертывания: оставляйте общедоступный доступ к Azure Key Vault и учетной записи хранения свидетеля включенным до завершения развертывания, а затем ограничьте доступ к ним только частными сетями.
• Добавьте частные конечные точки в список обхода: при использовании корпоративного прокси-сервера добавьте полное доменное имя частной конечной точки в список обхода прокси-сервера во время регистрации Arc. Для рабочих нагрузок AKS добавьте их в список исключений для переменных среды после регистрации в Arc.
• Не используйте подстановочные знаки: записи с подстановочными знаками, такие как *.azurecr.io, не поддерживаются в списке исключений. Добавьте точные FQDN реестров перед развертыванием, так как они используются Azure Resource Bridge и AKS для скачивания образов.
• Маршрутизация частных конечных точек за пределами шлюза Arc: частные конечные точки не направляются через шлюз Arc. Для таких служб, как Azure Site Recovery, отключите проверку SSL на корпоративном прокси-сервере или, предпочтительно, добавьте конечную точку в список обхода прокси-сервера.

В следующей таблице приведены рекомендации по частной конечной точке для каждой службы:

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

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

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

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

Решение 11. Определение программно-определяемой сети (SDN)

Программно-определяемая сеть (SDN) — это дополнительный уровень сети рабочей нагрузки, который применяется после настройки сети узла (решения 1–10). В Azure Local SDN активируется с помощью Azure Arc и ограничена двумя возможностями: логическими сетями SDN (LNET), которые предоставляют программно определяемые сегменты сети для ваших рабочих нагрузок и реализуются на основе VLAN в физической сети, а также микросегментацией с помощью групп безопасности сети (NSG). Определите, требуется ли программируемая сетевая сегментация рабочих нагрузок и распределенная политика безопасности, и убедитесь, что архитектура поддерживает нужную модель SDN.

Гиперконвергентная инфраструктура (HCI)

Гиперконвергированные развертывания поддерживают Microsoft SDN с поддержкой Azure Arc для 1–16 узлов:

• Плоскость управления SDN предоставляет только LNETs и NSGs. При включении активируется расширение виртуальной фильтрации Azure на виртуальном коммутаторе рабочей нагрузки.
• LNET реализуются с помощью VLAN в фабрике, поэтому для каждой логической сети настройте соответствующие VLAN и разрешите их прохождение на транковых портах коммутаторов ToR.
• Сетевой контроллер выполняется как набор служб кластера в экземпляре Azure Local, а не как отдельные виртуальные машины инфраструктуры.

SDN поддерживается только для следующих шаблонов намерений Network ATC из Decision 7:

Дезагрегированное (DA)

В разугрегированных развертываниях не используется сетевой контроллер SDN Microsoft. Логические сети SDN разворачиваются во внешней сети leaf-spine с использованием оверлея VXLAN EVPN в соответствии с многостоечной топологией, описанной в Решении 3:

• Создайте структуру VRF и наложение для переноса необходимых логических сетей.
• Логические сети AKS нуждаются в доступности уровня 3 к логической сети управления.
• Одностоечные дезагрегированные кластеры, которым не требуется SDN при масштабировании, могут использовать более простую топологию с двумя коммутаторами.

Дополнительные сведения о проектировании оверлейной сети VRF и VXLAN в архитектуре leaf-spine см. в документе Обзор эталонных сетевых шаблонов для дезагрегированных развертываний.

Ниже приведены краткие рекомендации по решению SDN:

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

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