Рекомендации по проектированию для частных облаков поколения 2 Решение Azure VMware

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

Ограничения

Следующие функции ограничены в течение этого времени. Эти ограничения будут отменены в будущем:

• Вы не можете удалить группу ресурсов, содержащую частное облако. Прежде чем удалять группу ресурсов, необходимо сначала удалить частное облако.
• Вы можете развернуть только одно частное облако в одной виртуальной сети Azure.
• Для каждой группы ресурсов можно создать только 1 частное облако. Несколько частных облаков в одной группе ресурсов не поддерживаются.
• Частное облако и виртуальная сеть для частного облака должны находиться в той же группе ресурсов.
• Вы не можете переместить частное облако из одной группы ресурсов в другую после создания частного облака.
• Вы не можете переместить частное облако из одного клиента в другой после создания частного облака.
• Если вам требуется ExpressRoute FastPath или Global виртуальная сеть Пиринг для частного облака AVS, создайте запрос в поддержку через портал Azure.
• Конечные точки службы не поддерживается прямая связь с рабочими нагрузками Решение Azure VMware.
• Private Endpoints при глобальном пиринге между регионами, подключенными к Решение Azure VMware, не поддерживается.
• Поддерживается использование vCloud Director с частными конечными точками. Однако директор vCloud с использованием общедоступных конечных точек не поддерживается.
• Растянутые кластеры vSAN не поддерживаются.
• Настройка общедоступного IP-адреса на уровне VMware NSX Microsoft Edge для доступа к Интернету не поддерживается. Какие параметры интернета поддерживаются в параметрах подключения к Интернету.
• Во время незапланированного обслуживания, например из-за сбоя оборудования хоста, на любом из первых четырех хостов в вашем программно-определяемом центре обработки данных (SDDC) возможно временное нарушение сетевой связности по направлению «север — юг» для некоторых рабочих нагрузок продолжительностью до 30 секунд. Подключение «север-юг» относится к трафику между рабочими нагрузками в среде AVS VMware и внешними конечными точками за периметром магистрали NSX-T уровня 0 (T0), такими как службы Azure или локальные среды. Это ограничение было удалено в определенных Azure регионах. Уточните в службе поддержки Azure, затрагивает ли это ограничение ваш регион.  
• Группы безопасности сети , связанные с виртуальной сетью узла частного облака, должны быть созданы в той же группе ресурсов, что и частное облако и ее виртуальная сеть.
• Ссылки между группами ресурсов и между подписками из виртуальных сетей клиента на виртуальную сеть Решение Azure VMware по умолчанию не поддерживаются. К ним относятся такие типы ресурсов, как определяемые пользователем маршруты (UDR), Планы защиты от атак DDoS и другие связанные сетевые ресурсы. Если виртуальная сеть клиента связана с одной из этих ссылок, расположенной в другой группе ресурсов или подписке, по сравнению с виртуальной сетью Решение Azure VMware, это может привести к сбоям в программировании сети, например, в распространении сегмента NSX. Чтобы избежать проблем, клиенты должны убедиться, что Решение Azure VMware виртуальная сеть не подключена к ресурсам в другой группе ресурсов или подписке. Прежде чем продолжить, удалите все такие подключения, такие как планы защиты от атак DDoS, из виртуальной сети.
  • Чтобы сохранить ссылку между группами ресурсов, создайте назначение роли в другой группе ресурсов или подписке и предоставьте приложению "AzS VIS Prod App" роль "AVS on Fleet VIS Role". Назначение роли позволит использовать эту ссылку, чтобы она корректно применялась к вашему частному облаку Решение Azure VMware.
• Частное облако 2-го поколения развертывания могут завершиться сбоем, если политики Azure строго устанавливают правила для групп сетевой безопасности или таблиц маршрутов (например, конкретные соглашения об именовании). Эти ограничения политики могут блокировать создание необходимых группы сетевой безопасности Решение Azure VMware и таблицы маршрутов во время развертывания. Перед развертыванием частного облака необходимо удалить эти политики из Решение Azure VMware виртуальной сети. После развертывания частного облака эти политики можно добавить обратно в частное облако Решение Azure VMware.
• Если вы используете Частная зона DNS для частного облака Решение Azure VMware 2-го поколения, использование Custom DNS в виртуальной сети, где развернуто частное облако Решение Azure VMware 2-го поколения, не поддерживается. Пользовательские DNS нарушают операции жизненного цикла, такие как масштабирование, обновление и исправление.
• Если вы удаляете свое частное облако и некоторые ресурсы, созданные Решение Azure VMware, не удаляются, можно повторить попытку удаления частного облака Решение Azure VMware с помощью Azure CLI.
• Решение Azure VMware 2-го поколения использует http-прокси для различения сетевого трафика клиента и управления. Некоторые конечные точки облачной службы VMware могут не соответствовать тем же сетевым путям или правилам прокси-сервера, что и общий трафик, управляемый vCenter. Ниже приведены примеры: scapi.vmware и apigw.vmware. Прокси-сервер VAMI управляет общим исходящим доступом к Интернету устройства vCenter Server (VCSA), но не всеми взаимодействиями с конечной точкой службы через этот прокси-сервер. Некоторые взаимодействия происходят непосредственно из браузера пользователя или из компонентов интеграции, которые вместо этого следуют параметрам прокси рабочей станции или инициируют подключения независимо. В результате трафик к конечным точкам облачной службы VMware может полностью обойти прокси-сервер VCSA.
• Миграции HCX RAV и массовые миграции в среде Gen 2 могут выполняться медленнее из-за задержек на этапах базовой и оперативной синхронизации. Клиенты должны планировать более длительные периоды миграции и планировать волны соответствующим образом. Для подходящих рабочих нагрузок vMotion предлагает более быстрый вариант с низкими накладными расходами, когда условия сервера и сети позволяют.
• Пиринг виртуального концентратора (виртуальная глобальная сеть): чтобы установить подключение пиринга между виртуальной сетью 2-го поколения и виртуальным концентратором (виртуальной глобальной сетью), виртуальный концентратор должен находиться в том же регионе, что и виртуальная сеть 2-го поколения. Если вам нужно настроить пиринг с виртуальным концентратором в другом регионе, необходимо создать обращение в службу поддержки через портал Azure.
• /32-адрес назначения маршрута из связанной через пиринг виртуальной сети (VNET): если вы анонсируете маршруты /32 из NSX (например, маршруты HCX MON или маршруты пересылки DNS) и вам требуется доступ к этому адресу назначения /32 из связанной через пиринг виртуальной сети, необходимо создать обращение в службу поддержки на портале Azure. Связность с узлом с префиксом /32 корректно работает из локальной сети VNET.
• Объявление подсети Peer Sync в VNET и ассоциация с таблицей маршрутов Azure (UDR) — Решение Azure VMware Gen 2 использует две внутренние архитектуры. Текущая архитектура синхронизирует как определенные подсети, так и более широкое адресное пространство Azure для маршрутов сегментов или подсетей NSX с пиринговыми виртуальными сетями Azure. В результате с текущей архитектурой 2-го поколения может потребоваться настроить таблицы маршрутов Azure (UDR) с более конкретными маршрутами подсети сегмента NSX, а не использовать общие маршруты адресного пространства для сегментов рабочей нагрузки Решение Azure VMware.
• Azure NAT шлюз не поддерживается для рабочих нагрузок второго поколения.
• Пиринг Azure Subnet не поддерживается с подсетями приватного облака второго поколения.

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

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

• Zerto DR (восстановление после катастрофы)

Делегированные подсети и группы безопасности сети для 2-го поколения

При развертывании частного облака Решение Azure VMware (AVS) 2-го поколения Azure автоматически создает несколько делегированных подсетей в виртуальной сети узла частного облака. Эти подсети используются для изоляции и защиты компонентов управления частного облака.

Клиенты могут управлять доступом к этим подсетям с помощью групп безопасности сети (NSG), которые отображаются на портале Azure или с помощью Azure CLI/PowerShell. Помимо групп безопасности сети, управляемых клиентом, AVS применяет дополнительные управляемые системой группы безопасности сети к критически важным интерфейсам управления. Эти управляемые системой группы безопасности сети не отображаются или редактируются клиентами и существуют, чтобы обеспечить безопасность частного облака по умолчанию.

В рамках состояния безопасности по умолчанию:

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

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

Рекомендации по маршрутизации и подсетям

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

Частное облако подключается к виртуальной сети Azure с помощью стандартных сетевых средств Azure. В Решение Azure VMware частные облака 2-го поколения требуется минимальный блок сетевых адресов CIDR /22 для подсетей. Эта сеть дополняет локальные сети, поэтому блок адресов не должен перекрываться с адресными блоками, используемыми в других виртуальных сетях в подписке и локальных сетях. Сети для управления, vMotion и репликации автоматически конфигурируются в этом блоке адресов как подсети внутри вашей виртуальной сети.

Избегайте использования следующей схемы IP-адресов, зарезервированной для использования VMware NSX:

• 169.254.0.0/24 — используется для внутренней транзитной сети
• 169.254.2.0/23 — используется для транзитной сети между различными VRF
• 100.64.0.0/16 — используется для внутреннего подключения шлюзов T1 и T0.
• 100.73.x.x— используется сетью управления Майкрософт

Пример CIDR-блока /22 10.31.0.0/22 делится на следующие подсети:

Программирование маршрутов NSX в виртуальной сети Azure

Маршруты NSX Gen-2 в Решение Azure VMware интегрируются в Azure посредством использования адресного пространства и их назначения в качестве вторичных IP-адресов в созданной системой подсети "avs-network-infra-gw", что обеспечивает беспрепятственное взаимодействие между Azure и клиентскими рабочими нагрузками AVS. Когда NSX Tier-0 объявляет маршрут в соответствии с пользовательскими настройками, например при создании сегментов, добавлении статических маршрутов или использовании виртуальных машин HCX MON, плоскость управления Решение Azure VMware проверяет, входит ли префикс маршрута в адресное пространство виртуальной сети. Если это не так, он создает адресное пространство и добавляет префикс маршрута в качестве вторичных IP-адресов в подсети avs-network-infra-gw. Для анонсируемых маршрутов Tier-0 /32, таких как маршруты HCX MON, вторичные IP-адреса не назначаются, однако плоскость данных внутренне настраивается так, чтобы обеспечить связность с адресатами /32 в Решение Azure VMware.

Наряду с обновлением адресного пространства и подсети для маршрутов NSX существует внутреннее программирование, которое следует учитывать клиентам, особенно в отношении поддерживаемого масштабирования при использовании маски нижней подсети. Дополнительные сведения об аспекте масштабируемости см. в статье Архитектура маршрутизации для Решение Azure VMware поколения 2

Особенности связывания таблицы маршрутов Azure (UDR)

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

Начальное частное облако 2-го поколения:

• Виртуальная сеть Azure (VNET) содержит две базовые подсети шлюза, одна из которых называется "avs-nsx-gw", и, в отличие от текущей архитектуры, не содержит подсети "avs-network-infra-gw".
• Все подсети сегмента AVS NSX программируются в подсети avs-nsx-gw в качестве дополнительного IPv4-адреса для подключения Azure к рабочим нагрузкам NSX.
• Таблицу маршрутов (UDR) или Azure NSG для трафика из AVS в Azure VNet и далее (например, в локальную инфраструктуру) необходимо применить к подсети "avs-nsx-gw".

Текущее частное облако 2-го поколения:

Обязательно запишите это изменение в поведении.

• В виртуальной сети Azure будут видны дополнительная подсеть с префиксом "avs-network-infra-gw" наряду с двумя базовыми подсетями шлюза с именем "avs-nsx-gw", как в исходной архитектуре.
• Все подсети сегмента AVS NSX теперь запрограммируются в этой подсети в качестве вторичного IPv4-адреса для подключения Azure к рабочим нагрузкам NSX. Это не изменяет сетевое подключение клиента.
• Пиринг VNET распространяет в связанную пирингом VNET как адресное пространство, так и подсети, в отличие от исходной архитектуры или собственной синхронизации VNET в Azure, где синхронизируется только адресное пространство.

Рекомендации по проектированию из-за изменений во внутренней архитектуре 2-го поколения

• Клиенты наблюдают дополнительные эффективные маршруты для подсетей AVS в одноранговой виртуальной сети из-за изменения поведения синхронизации одноранговых узлов виртуальной сети.
• Если клиент использует таблицу маршрутов Azure (UDR) для отправки трафика из локальной среды в AVS через брандмауэр или сетевое виртуальное устройство, он должен обновить UDR, чтобы использовать определенные маршруты подсети NSX, а не широкий диапазон адресов суперсети, используемый ранее. Это необходимо, чтобы трафик, предназначенный для AVS, не использовал более специфичные маршруты подсети VNET, обходя предусмотренный брандмауэр, из-за правила наиболее длинного совпадения префикса в маршрутизации Azure. В противном случае это может привести к асимметричной маршрутизации, что может привести к проблемам с подключением.
• Однако таблица маршрутов (UDR) или Azure NSG для трафика из AVS в Azure VNET и далее (например, в локальную инфраструктуру) по-прежнему будут применяться к подсетям "avs-nsx-gw", а не "avs-network-infra-gw". Клиенты не должны использовать таблицу маршрутов (UDR) в подсети avs-network-infra-gw, даже если подсети сегмента NSX настроены там как вторичные IP-адреса.

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

• Начните настройку учетной записи службы для Решение Azure VMware в качестве предварительного условия. Чтобы узнать, как, см. краткое руководство по Включению учетной записи службы Решение Azure VMware.

• Следуйте инструкциям по Создание частного облака Azure VMware 2-го поколения