Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
В этой статье приводятся рекомендации по интеграции развертывания решения Azure VMware в существующую или новую архитектуру хаб и спицы на платформе Azure.
В сценарии с моделью 'звезда-лъч' предполагается гибридная облачная среда с рабочими нагрузками в:
- Использование встроенных служб Azure IaaS или PaaS
- Решение Azure VMware
- на локальных серверах vSphere.
Архитектура
Центральный узел — это виртуальная сеть Azure, которая выступает в качестве центральной точки подключения к локальной среде и частному облаку Решения Azure VMware. Периферийные узлы — это виртуальные сети, подключенные к центральному узлу для обеспечения взаимодействия между виртуальными сетями.
Трафик между локальным центром обработки данных, частным облаком Решения Azure VMware и центральным узлом передается через подключения Azure ExpressRoute. Периферийные виртуальные сети обычно содержат рабочие нагрузки на основе IaaS, но могут выполнять и службы PaaS, такие как Среда службы приложений, которые напрямую интегрированы с виртуальной сетью, или другие службы PaaS с поддержкой Приватного канала Azure.
Внимание
Для подключения к Решению Azure VMware можно использовать существующий шлюз ExpressRoute, если он не превышает ограничение в четыре канала ExpressRoute на виртуальную сеть. Но для доступа к Решению Azure VMware из локальной среды через ExpressRoute требуется служба ExpressRoute Global Reach, так как шлюз ExpressRoute не обеспечивает транзитивную маршрутизацию между подключенными каналами.
На схеме показан пример развертывания типа Hub and Spoke в Azure, подключенного к локальной среде и решению VMware для Azure через ExpressRoute Global Reach.
Архитектура состоит из следующих основных компонентов.
Локальный сайт: локальные центры обработки данных клиента, подключенные к Azure через подключение ExpressRoute.
Решение Azure VMware частное облако: Решение Azure VMware программно-определяемый центр обработки данных, сформированный одним или несколькими кластерами vSphere, каждый из которых содержит не более 16 узлов.
Шлюз ExpressRoute: обеспечивает связь между частным облаком решения Azure VMware, общими службами на виртуальной сети Hub и нагрузками, выполняющимися на Spoke виртуальных сетях через подключение ExpressRoute.
ExpressRoute Global Reach: обеспечивает подключения между локальной средой и частным облаком Решения Azure VMware. Подключения между Решением Azure VMware и структурой Azure осуществляются только через ExpressRoute Global Reach.
Соображения по поводу VPN S2S: Подключение к частному облаку Azure VMware Solution с помощью Azure S2S VPN поддерживается, если они соответствуют минимальным сетевым требованиям для VMware HCX.
Центральная виртуальная сеть: выступает в качестве центральной точки подключения к локальной сети и частному облаку Решения Azure VMware.
Спицевая виртуальная сеть
Спица IaaS: размещает рабочие нагрузки на основе IaaS Azure, включая наборы доступности виртуальных машин и масштабируемые наборы виртуальных машин, а также соответствующие сетевые компоненты.
Периферийная виртуальная сеть PaaS: В ней размещены службы Azure PaaS, использующие частную адресацию благодаря Private Endpoint и Private Link.
Брандмауэр Azure: выступает в качестве центрального элемента для сегментирования трафика между Spokes и Решением Azure VMware.
Шлюз приложений: предоставляет и защищает веб-приложения, которые выполняются на виртуальных машинах Azure IaaS, PaaS или Решения Azure VMware. Он интегрируется с другими службами, такими как Управление API.
Рекомендации по сетям и безопасности
Подключения ExpressRoute позволяют передавать трафик между локальной средой, Решением VMware Azure и структурой сети Azure. Для реализации этих подключений в решении Azure VMware используется ExpressRoute Global Reach.
Так как шлюз ExpressRoute не обеспечивает транзитную маршрутизацию между подключенными каналами, локальное подключение также должно использовать ExpressRoute Global Reach для обмена данными между локальной средой vSphere и Решением VMware Azure.
Поток трафика между локальной средой и Решением Azure VMware
Поток трафика из решения Azure VMware в виртуальную сеть концентратора
Дополнительные сведения о принципах организации сетей и подключений для Решения Azure VMware см. в документации по продукту "Решение Azure VMware.
Сегментация трафика
Брандмауэр Azure — это центральный элемент звездообразной топологии, развертываемый в центральной узловой виртуальной сети. Используйте Брандмауэр Azure или другое поддерживаемое Azure сетевое виртуальное устройство (NVA), чтобы установить правила для трафика и сегментировать обмен данными между разными спицами и рабочей нагрузкой решения Azure VMware.
Создайте таблицы маршрутизации для направления трафика в Брандмауэр Azure. Для Spoke виртуальных сетей создайте маршрут, который устанавливает маршрут по умолчанию к внутреннему интерфейсу Брандмауэра Azure. Таким образом, когда рабочей нагрузке в виртуальной сети необходимо подключиться к адресному пространству решения Azure VMware, брандмауэр может оценить его и применить соответствующее правило трафика, чтобы разрешить или отклонить его.
Внимание
Маршрут с префиксом адреса 0.0.0.0/0 для параметра GatewaySubnet не поддерживается.
Задайте маршруты для конкретных сетей в соответствующей таблице маршрутизации. Например, маршруты от периферийных рабочих нагрузок к префиксам IP-адресов для управления компонентами Решения Azure VMware и к его рабочим нагрузкам, и наоборот.
Второй уровень сегментации трафика с использованием групп безопасности сети в периферийных виртуальных сетях и центральной сети обеспечивает более детализированную политику управления трафиком.
Примечание.
Трафик из локальной среды в Решение VMware для Azure: трафик между локальными рабочими нагрузками (на основе vSphere или других платформ) передается посредством Global Reach, но он не проходит через Брандмауэр Azure в центральной виртуальной сети. В этом сценарии необходимо реализовать механизмы сегментации трафика, как в локальной среде, так и в Решении Azure VMware.
Шлюз приложений
Шлюзы приложений Azure версии 1 и версии 2 были протестированы с веб-приложениями, работающими на виртуальных машинах решения Azure VMware в качестве фонового пула. Шлюз приложений в настоящее время является единственным поддерживаемым методом предоставления веб-приложений, работающих на виртуальных машинах Azure VMware, в Интернете. Он также может безопасно предоставлять приложения внутренним пользователям.
Дополнительные сведения см. в статье, посвященной Решению Azure VMware, в разделе о шлюзе приложений.
Прыжковый сервер и Бастион Azure
Для доступа к среде решения Azure VMware используйте подключение через jump box, представляющее собой виртуальную машину на базе Windows 10 или Windows Server, развернутую в подсети общих служб в центральной виртуальной сети.
Внимание
Бастион Azure — это служба, рекомендуемая для подключения к переходному серверу для предотвращения доступа Решения Azure VMware к Интернету. Бастион Azure невозможно использовать для подключения к виртуальным машинам Решения Azure VMware, так как они не являются объектами IaaS Azure.
В целях безопасности рекомендуется развертывать службу Бастион Microsoft Azure в центральной виртуальной сети. Бастион Azure обеспечивает простой доступ по протоколам RDP и SSH к виртуальным машинам, развернутым в Azure, без подготовки общедоступных IP-адресов для этих ресурсов. После подготовки службы "Бастион Azure" вы сможете получить доступ к выбранной виртуальной машине на портале Azure. После установления подключения откроется новая вкладка, на которой будет отображен рабочий стол Jumpbox, с которого вы сможете получить доступ к плоскости управления частного облака Решения Azure VMware.
Внимание
Не предоставляйте общедоступный IP-адрес виртуальной машине Jumpbox и не предоставляйте доступ через Интернет к TCP-порту 3389.
Рекомендации по разрешению Azure DNS
Для разрешения Azure DNS можно использовать два варианта.
Можно использовать контроллеры домена, развернутые в центральной виртуальной сети (см. рекомендации по идентификации), в качестве серверов имен.
Можно развернуть и настроить частную зону Azure DNS.
Самый эффективный подход — объединить оба, чтобы обеспечить надежное разрешение имен для Решения Azure VMware, локальной среды и Azure.
Общая рекомендация по проектированию: используйте существующий DNS, интегрированный с Active Directory, как минимум на двух виртуальных машинах Azure в центральной виртуальной сети и настройте в виртуальных сетях ответвления использование этих серверов Azure DNS в настройках DNS.
Вы можете использовать Частную зону DNS Azure, которая связана с виртуальной сетью. DNS-серверы используются в качестве гибридных резолверов с условным перенаправлением в локальную среду или в Решение Azure VMware, где используется служба DNS в рамках инфраструктуры Частной зоны DNS Azure клиента.
Чтобы автоматически управлять жизненным циклом записей DNS для виртуальных машин, развернутых в периферийных виртуальных сетях, включите автоматическую регистрацию. Если этот параметр включен, то максимальное число частных зон DNS равно 1. Если этот параметр отключен, то максимальное число равно 1000.
Локальные серверы и серверы решения Azure VMware можно настроить с условными пересылателями для резолверов виртуальных машин в зоне частного DNS Azure.
Вопросы идентификации
Для реализации идентификации лучше всего развернуть по крайней мере один контроллер домена в центральной виртуальной сети. Используйте две подсети общих служб в распределённой по зонам конфигурации или набор обеспечения доступности виртуальных машин. Дополнительные сведения о расширении локального домена Active Directory (AD) в Azure см. в разделе Центр архитектуры Azure.
Кроме того, разверните еще один контроллер домена на стороне Решения VMware Azure, чтобы он работал в качестве источника удостоверений и адресов DNS в среде vSphere.
Рекомендуется интегрировать домен AD с идентификатором Microsoft Entra.