рекомендации по проектированию сети Решение Azure VMware
Решение Azure VMware предлагает частную облачную среду VMware, к которой пользователи и приложения могут получить доступ из локальных сред и ресурсов Azure. Сетевые службы, такие как Azure ExpressRoute и vpn-подключения, обеспечивают подключение.
Перед настройкой среды Решение Azure VMware следует ознакомиться с несколькими рекомендациями по работе с сетями. В этой статье приведены решения для вариантов использования, которые могут возникнуть при использовании Решение Azure VMware для настройки сетей.
Решение Azure VMware совместимость с as-Path Prepend
Решение Azure VMware имеет рекомендации по использованию as-Path Prepend для избыточных конфигураций ExpressRoute. Если вы используете два или более путей ExpressRoute между локальной средой и Azure, рассмотрите следующее руководство по влиянию на трафик из Решение Azure VMware в направлении локального расположения через ExpressRoute GlobalReach.
Из-за асимметричной маршрутизации проблемы с подключением могут возникать, если Решение Azure VMware не наблюдает предпенд as-Path и поэтому использует маршрутизацию с равными затратами (ECMP) для отправки трафика в вашу среду по обоим каналам ExpressRoute. Это поведение может привести к проблемам с устройствами проверки брандмауэра с отслеживанием состояния, размещенными за существующими каналами ExpressRoute.
Необходимые компоненты
Для предварительной установки AS-Path рассмотрите следующие предварительные требования:
- Ключевой момент заключается в том, что необходимо заранее указать общедоступные номера ASN, чтобы повлиять на то, как Решение Azure VMware направляет трафик обратно в локальную среду. Если вы предустановили частный ASN, Решение Azure VMware будет игнорировать предустановку, а поведение ECMP, упоминание ранее. Даже если вы используете локальную локальную сеть BGP ASN, вы по-прежнему можете настроить локальные устройства для использования общедоступного ASN при подготовке исходящих маршрутов, чтобы обеспечить совместимость с Решение Azure VMware.
- Создайте путь трафика для частных ASN после того, как общедоступный ASN будет считаться Решение Azure VMware. Канал ExpressRoute Решение Azure VMware не удаляет частные ASN, существующие в пути после обработки общедоступного ASN.
- Оба канала подключены к Решение Azure VMware через Azure ExpressRoute Global Reach.
- Те же сетевые блоки объявляются из двух или более каналов.
- Вы хотите использовать as-Path Prepend для принудительного использования решения Azure VMware, чтобы предпочесть один канал для другого.
- Используйте 2-байтовые или 4-байтовые общедоступные номера ASN.
Виртуальные машины управления и маршруты по умолчанию из локальной среды
Внимание
Решение Azure VMware виртуальные машины управления не будут учитывать маршрут по умолчанию из локальной среды для RFC1918 назначения.
Если вы выполняете маршрутизацию обратно в локальные сети, используя только маршрут по умолчанию, объявленный в Azure, трафик с виртуальных машин vCenter Server и NSX Manager, используемых в направлении локальных назначений с частными IP-адресами, не будет следовать этому маршруту.
Чтобы получить доступ к vCenter Server и NSX Manager из локальной среды, предоставьте определенные маршруты, чтобы разрешить трафику возвращать путь к этим сетям. Например, объявляйте сводки RFC1918 (10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16).
Маршрут по умолчанию для Решение Azure VMware для проверки трафика в Интернете
Для некоторых развертываний требуется проверка всего исходящего трафика из Решение Azure VMware в Интернет. Хотя в Решение Azure VMware можно создать виртуальные сетевые виртуальные (модуль) (NVA), существуют случаи, когда эти (модуль) уже существуют в Azure и могут применяться для проверки интернет-трафика из Решение Azure VMware. В этом случае маршрут по умолчанию можно внедрить из NVA в Azure, чтобы привлечь трафик из Решение Azure VMware и проверить трафик до выхода в общедоступный Интернет.
На следующей схеме описывается базовая топология концентратора и периферийной сети, подключенная к Решение Azure VMware облаку и локальной сети через ExpressRoute. На схеме показано, как NVA в Azure создается маршрут по умолчанию (0.0.0.0/0). Сервер маршрутов Azure распространяет маршрут на Решение Azure VMware через ExpressRoute.
Внимание
Маршрут по умолчанию, объявляемый NVA, будет распространяться в локальную сеть. Необходимо добавить определяемые пользователем маршруты ,чтобы обеспечить передачу трафика из Решение Azure VMware через NVA.
Обмен данными между Решение Azure VMware и локальной сетью обычно происходит через ExpressRoute Global Reach, как описано в локальных средах одноранговых узлов для Решение Azure VMware.
Подключение тивность между Решение Azure VMware и локальной сетью
Существует два основных сценария подключения между Решение Azure VMware и локальной сетью через стороннее NVA:
- Организации должны отправлять трафик между Решение Azure VMware и локальной сетью через NVA (обычно брандмауэр).
- ExpressRoute Global Reach недоступен в определенном регионе для подключения каналов ExpressRoute Решение Azure VMware и локальной сети.
Существует два топологии, которые можно применить для удовлетворения всех требований для этих сценариев: суперсети и транзитной виртуальной сети.
Внимание
Предпочтительный вариант подключения Решение Azure VMware и локальных сред — это прямое подключение ExpressRoute Global Reach. Шаблоны, описанные в этой статье, добавляют сложность в среду.
Топология конструктора суперсети
Если оба канала ExpressRoute (в Решение Azure VMware и в локальную среду) завершаются в одном шлюзе ExpressRoute, можно предположить, что шлюз будет направлять пакеты между ними. Но шлюз ExpressRoute не предназначен для таких задач. Необходимо прикрепить трафик к NVA, который может маршрутизировать трафик.
Существует два требования для подключения сетевого трафика к NVA:
NVA должна объявлять суперсеть для Решение Azure VMware и локальных префиксов.
Можно использовать суперсеть, которая включает как Решение Azure VMware, так и локальные префиксы. Или можно использовать отдельные префиксы для Решение Azure VMware и локальной среды (всегда менее конкретных, чем фактические префиксы, объявленные через ExpressRoute). Помните, что все префиксы суперсети, объявленные в Route Server, распространяются как в Решение Azure VMware, так и в локальной среде.
Определяемые пользователем учетные адреса в подсети шлюза, которые точно соответствуют префиксам, объявленным из Решение Azure VMware и локальной сети, вызывают трафик прикрепления из подсети шлюза в NVA.
Эта топология приводит к высокой нагрузке на управление для крупных сетей, которые изменяются с течением времени. Рассмотрим следующие ограничения:
- В любое время, когда сегмент рабочей нагрузки создается в Решение Azure VMware, UDR может потребоваться добавить, чтобы обеспечить передачу трафика из Решение Azure VMware через NVA.
- Если локальная среда имеет большое количество маршрутов, которые изменяются, может потребоваться обновить конфигурацию протокола BGP и UDR в суперсети.
- Так как один шлюз ExpressRoute обрабатывает сетевой трафик в обоих направлениях, производительность может быть ограничена.
- Существует ограничение в Azure виртуальная сеть 400 определяемых пользователем пользователей.
На следующей схеме показано, как NVA должна объявлять префиксы, которые являются более универсальными (менее конкретными) и включают сети из локальной среды и Решение Azure VMware. Будьте осторожны с этим подходом. NVA может потенциально привлечь трафик, который он не должен, потому что он рекламирует более широкие диапазоны (например, всю 10.0.0.0/8 сеть).
Топология виртуальной сети транзитной виртуальной сети
Примечание.
Если префиксы рекламы, которые являются менее конкретными, невозможно из-за ранее описанных ограничений, можно реализовать альтернативный дизайн, использующий две отдельные виртуальные сети.
В этой топологии вместо распространения маршрутов, которые менее характерны для привлечения трафика к шлюзу ExpressRoute, два разных NVA в отдельных виртуальных сетях могут обмениваться маршрутами между собой. Виртуальные сети могут распространять эти маршруты на соответствующие каналы ExpressRoute через BGP и сервер маршрутизации Azure. Каждый NVA имеет полный контроль над тем, какие префиксы распространяются на каждый канал ExpressRoute.
На следующей схеме показано, как объявляется один 0.0.0.0/0 маршрут для Решение Azure VMware. Кроме того, показано, как отдельные Решение Azure VMware префиксы распространяются в локальную сеть.
Внимание
Протокол инкапсуляции, такой как VXLAN или IPsec, требуется между сетевыми сетями. Инкапсуляция необходима, так как сетевой адаптер NVA (сетевой адаптер) будет изучать маршруты с сервера маршрутов Azure с NVA в качестве следующего прыжка и создать цикл маршрутизации.
Существует альтернатива использованию наложения. Примените вторичные сетевые адаптеры в NVA, которые не изучают маршруты с сервера маршрутов Azure. Затем настройте UDR, чтобы Azure могли направлять трафик в удаленную среду через эти сетевые адаптеры. Дополнительные сведения см. в статье Корпоративная топология сети и подключение в Решении Azure VMware.
Для этой топологии требуется сложная начальная настройка. Затем топология работает должным образом с минимальными затратами на управление. К сложностям установки относятся:
- Существует дополнительная стоимость добавления другой транзитной виртуальной сети, включающей сервер маршрутизации Azure, шлюз ExpressRoute и другую NVA. NVAs также может потребоваться использовать большие размеры виртуальных машин для удовлетворения требований пропускной способности.
- Требуется туннелирование IPsec или VXLAN между двумя виртуальными сетями, что означает, что NVAs также находятся в пути данных. В зависимости от типа NVA, который вы используете, он может привести к пользовательской и сложной конфигурации для этих NVAs.
Следующие шаги
После изучения рекомендаций по проектированию сети для Решение Azure VMware рассмотрите следующие статьи: