Топология сети и подключение для решения Azure VMware

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

Эта статья основана на нескольких принципах архитектуры целевых зон корпоративного масштаба Cloud Adoption Framework и рекомендациях по управлению топологией сети и подключением в масштабе. Эти рекомендации по проектированию посадочных зон Azure можно использовать для особо важных платформ решения Azure VMware. К областям проектирования относятся:

Общие рекомендации и рекомендации по проектированию

В следующих разделах приведены общие рекомендации по проектированию и топологии сети решения Azure VMware и подключения.

Концентратор-шлейф vs. топология сети виртуальной WAN

Если у вас нет подключения ExpressRoute из локальной среды в Azure и вы вместо этого используете VPN S2S, вы можете использовать виртуальную глобальную сеть для транзитного подключения между локальным VPN и Решением Azure VMware ExpressRoute. Если вы используете звездообразную топологию, вам потребуется Сервер маршрутизации Azure. Дополнительные сведения см. в статье о поддержке Сервера маршрутов Azure для ExpressRoute и VPN Azure.

Частные облака и кластеры

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

  • Все кластеры используют одинаковые параметры подключения, включая Интернет, ExpressRoute, HCX, общедоступный IP-адрес и ExpressRoute Global Reach. Рабочие нагрузки приложений также могут совместно использовать некоторые основные параметры сети, такие как сегменты сети, протокол конфигурации динамического узла (DHCP) и параметры системы доменных имен (DNS).

  • Заранее разработайте частные облака и кластеры перед развертыванием. Количество частных облаков, которые требуются, напрямую влияет на требования к сети. Для каждого частного облака требуется собственное адресное пространство /22 для управления частным облаком и сегмента IP-адресов для рабочих нагрузок виртуальных машин. Рекомендуется заранее определить эти адресные пространства.

  • Обсудите с группами VMware и сетевыми группами, как сегментировать и распространять частные облака, кластеры и сетевые сегменты для рабочих нагрузок. Спланируйте хорошо и избегайте использования IP-адресов.

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

Дополнительные сведения об управлении IP-адресами для рабочих нагрузок виртуальных машин см. в разделе "Определение сегмента IP-адресов для рабочих нагрузок виртуальных машин".

DNS и DHCP

Для DHCP используйте службу DHCP, встроенную в центр обработки данных NSX-T, или используйте локальный DHCP-сервер в частном облаке. Не перенаправляйте трафик DHCP через глобальную сеть обратно в локальные сети.

Для DNS в зависимости от используемого сценария и требований у вас есть несколько вариантов:

  • Только для среды решения Azure VMware можно развернуть новую инфраструктуру DNS в частном облаке решения Azure VMware.
  • Для решения Azure VMware, подключенного к локальной среде, можно использовать существующую инфраструктуру DNS. При необходимости разверните форвардеры DNS для расширения в виртуальную сеть Azure или, предпочтительно, в решение Azure VMware Solution. Дополнительные сведения см. в разделе "Добавление службы пересылки DNS".
  • Для Azure VMware Solution, подключенного и к локальной, и к облачной среде и службам Azure, вы можете использовать существующие DNS-серверы или DNS-перенаправители в виртуальной сети хаба, если они доступны. Вы также можете расширить существующую локальную инфраструктуру DNS в виртуальной сети Концентратора Azure. Дополнительные сведения см. на схеме зон развертывания корпоративного масштаба.

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

Интернет

Параметры выхода для настройки Интернета, а также фильтрации и инспекции трафика:

  • Виртуальная сеть Azure, NVA и сервер маршрутизации Azure с помощью доступа к Интернету.
  • Локальный маршрут по умолчанию с помощью локального доступа к Интернету.
  • Виртуальный WAN-концентратор, защищенный с помощью брандмауэра Azure или NVA, использующий доступ в Интернет через Azure.

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

  • Шлюз приложений Azure с уровнем 7 OSI, терминацией Secure Sockets Layer (SSL) и веб-аппликационным фаерволом.
  • DNAT и балансировщик нагрузки из локальной сети.
  • Виртуальная сеть Azure, NVA и сервер маршрутизации Azure в различных сценариях.
  • Защищенный концентратор Virtual WAN с брандмауэром Azure, поддерживающим L4 и DNAT.
  • Защищенный концентратор виртуальной глобальной сети с NVA в различных сценариях.

ExpressRoute

Развертывание частного облака в решении Azure VMware автоматически создает один бесплатный канал ExpressRoute 10 Гбит/с. Этот канал подключает решение Azure VMware к D-MSEE.

Рассмотрите возможность развертывания решения Azure VMware в парных регионах Azure рядом с центрами обработки данных. Ознакомьтесь с этой статьей по рекомендациям по топологиям сети с двумя регионами для решения Azure VMware.

Global Reach

  • Global Reach — это необходимая надстройка ExpressRoute для решения Azure VMware для взаимодействия с локальными центрами обработки данных, виртуальной сетью Azure и виртуальной глобальной сетью. Альтернативой является проектирование сетевого подключения с помощью сервера маршрутизации Azure.

  • Канал Azure VMware Solution ExpressRoute можно соединять с другими каналами ExpressRoute через Global Reach бесплатно.

  • Вы можете использовать Global Reach для пиринга каналов ExpressRoute через ISP и для каналов ExpressRoute Direct.

  • Global Reach не поддерживается для локальных каналов ExpressRoute. Для ExpressRoute Local передача данных из решения VMware в Azure в локальные центры обработки данных осуществляется через сторонние сетевые виртуальные устройства (NVAs) в виртуальной сети Azure.

  • Global Reach недоступна во всех расположениях.

Пропускная способность

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

Безопасность сети

Безопасность сети включает проверку трафика и зеркальное отображение портов.

East-West проверка трафика в SDDC использует NSX-T Центра обработки данных или NVA для проверки трафика в виртуальной сети Azure в разных регионах.

North-South проверка трафика проверяет двунаправленный поток трафика между решением Azure VMware и центрами обработки данных. Проверка трафика "Север-Юг" может использовать:

  • Сторонний брандмауэр NVA и сервер маршрутизации Azure через сеть Azure Internet.
  • Локальный маршрут по умолчанию через локальный Интернет.
  • Брандмауэр Azure и виртуальная WAN в сети Azure
  • NSX-T Центр обработки данных в составе SDDC через интернет-соединение решения Azure VMware.
  • Сторонний брандмауэр NVA в решении Azure VMware в SDDC через Интернет решения Azure VMware

Требования к портам и протоколам

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

Доступ к управлению решениями Azure VMware

  • Рекомендуется использовать узел Бастиона Azure в виртуальной сети Azure для доступа к среде решения Azure VMware во время развертывания.

  • После установки маршрутизации в локальную среду сеть управления решениями Azure VMware не учитывает 0.0.0.0/0 маршруты из локальных сетей, поэтому вам нужно объявить более конкретные маршруты для локальных сетей.

Непрерывность бизнес-процессов, аварийное восстановление (BCDR) и миграция

  • В миграциях VMware HCX шлюз по умолчанию остается локальным. Дополнительные сведения см. в статье "Развертывание и настройка VMware HCX".

  • Миграции VMware HCX могут использовать расширение HCX L2. Для миграций, требующих расширения уровня 2, также требуется ExpressRoute. S2S VPN поддерживается при условии, что выполнены минимальные требования к сетевой подложке. Максимальный размер единицы передачи (MTU) должен составлять 1350, чтобы вместить расходы на HCX. Дополнительные сведения о проектировании расширений уровня 2 см. в разделе «Коммутация уровня 2 в режиме управления» (VMware.com).

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

  • Last updated on