Поделиться через

Рекомендации по проектированию сети решения 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 Solution не учитывает AS-Path Prepend и поэтому использует маршрутизацию с равнозначными маршрутами (ECMP) для отправки трафика в вашу среду по обоим контурам ExpressRoute. Это поведение может привести к проблемам с устройствами проверки состояния брандмауэра, размещенными за существующими каналами ExpressRoute.

Предпосылки

Для AS-Path Prepend рассмотрите следующие предварительные требования:

  • Ключевой момент заключается в том, что необходимо заранее приступить к подготовке номеров общедоступных автономных систем (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.
  • Те же сетевые блоки объявляются из двух или более каналов связи.
  • Вы хотите использовать метод Prepend в AS-Path, чтобы заставить решение Azure VMware предпочесть один канал другому.
  • Используйте 2-байтовые или 4-байтовые общедоступные номера ASN.

Зарезервированные частные ASN в решении Azure VMware

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

Зарезервированные ASN для подложной сети

Следующие ASN зарезервированы для внутренней инфраструктуры решения Azure VMware и должны избегаться клиентами:

  • ASN уровня 2: 65300 – 65340

  • ASN Уровня 1: 65200 – 65240

  • Транспортные ASNs (шлюзы T0): 64513 (NSX Edges), 64600 – 64940

  • ASNs управления: 65000 – 65412, 398656-398670, 400572-400581

Влияние использования зарезервированных ASN

Использование любого из ASN, перечисленных выше в вашей среде, может привести к сбоям сеансов BGP, конфликтам маршрутизации сети или сбоям служб. Убедитесь, что назначения 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 можно создать виртуальные сетевые устройства (NVAS), существуют случаи, когда эти устройства уже существуют в Azure и могут применяться для проверки интернет-трафика из решения Azure VMware. В этом случае маршрут по умолчанию можно внедрить из NVA в Azure, чтобы привлечь трафик из решения Azure VMware и проверить трафик, прежде чем он выходит в общедоступный Интернет.

На следующей схеме описана базовая топология концентратора и периферийной сети, подключенная к облаку решения Azure VMware, а также к локальной сети через ExpressRoute. На схеме показано, как NVA в Azure инициирует маршрут по умолчанию (0.0.0.0/0). Сервер маршрутов Azure распространяет маршрут в решение Azure VMware через ExpressRoute.

Схема решения Azure VMware с сервером маршрутов и маршрутом по умолчанию.

Это важно

Маршрут по умолчанию, объявляемый NVA, будет распространяться в локальную сеть. Необходимо добавить определяемые пользователем маршруты (UDR), чтобы обеспечить передачу трафика из решения Azure VMware через NVA.

Обмен данными между решением Azure VMware Solution и локальной сетью обычно происходит через ExpressRoute Global Reach, как описано в Подключение локальных сред к решению Azure VMware Solution.

Подключение между решением 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 Solution, так и в локальную среду.

  • Определяемые пользователем маршруты (UDR) в подсети шлюза, которые точно соответствуют префиксам, объявленным в решении Azure VMware Solution и локальных сетях, вызывают трафик без выхода из подсети от подсети шлюза к NVA.

Эта топология приводит к высокой нагрузке на управление для крупных сетей, которые изменяются с течением времени. Учитывайте эти ограничения:

  • В любое время, когда создается сегмент рабочей нагрузки в Azure VMware Solution, может потребоваться добавить UDR'ы, чтобы обеспечить проход трафика из Azure VMware Solution через NVA.
  • Если локальная среда имеет большое количество маршрутов, которые изменяются, может потребоваться обновить конфигурацию протокола BGP и UDR в суперсети.
  • Так как один шлюз ExpressRoute обрабатывает сетевой трафик в обоих направлениях, производительность может быть ограничена.
  • Существует ограничение в 400 пользовательских маршрутов (UDR) для виртуальной сети Azure.

На следующей схеме показано, как NVA должна объявлять префиксы, которые являются более универсальными (менее конкретными) и включают сети из локальной среды и решения Azure VMware. Будьте осторожны с этим подходом. NVA может привлечь трафик, который привлекать не следует, потому что он рекламирует более широкие диапазоны (например, всю 10.0.0.0/8 сеть).

Схема решения Azure VMware для локального взаимодействия с сервером маршрутизации в одном регионе.

Топология спиц в транзитной виртуальной сети

Примечание.

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

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

На следующей схеме показано, как анонсируется единый 0.0.0.0/0 маршрут в решении Azure VMware. Кроме того, показано, как отдельные префиксы решения Azure VMware распространяются в локальную сеть.

Схема решения Azure VMware для локальной связи с сервером маршрутизации в двух регионах.

Это важно

Протокол инкапсуляции, такой как VXLAN или IPsec, требуется между виртуальными сетевыми устройствами (NVA). Инкапсуляция необходима, так как сетевой адаптер NVA (NIC) будет изучать маршруты с сервера маршрутов Azure с NVA в качестве следующего узла и создать петлю маршрутизации.

Существует альтернатива использованию оверлея. Примените вторичные сетевые адаптеры в NVA, которые не изучают маршруты с сервера маршрутов Azure. Затем настройте UDR, чтобы Azure могли направлять трафик в удаленную среду через эти сетевые адаптеры. Дополнительные сведения см. в топологии и подключении корпоративной сети для решения Azure VMware.

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

  • Существует дополнительная стоимость добавления другой транзитной виртуальной сети, включающей сервер маршрутизации Azure, шлюз ExpressRoute и другую NVA. Может также потребоваться, чтобы NVA использовали большие размеры виртуальных машин для удовлетворения требований по пропускной способности.
  • Требуется туннелирование IPsec или VXLAN между двумя сетевыми виртуальными устройствами, что означает, что NVAs также находятся в том же пути данных. В зависимости от типа NVA, который вы используете, это может привести к настраиваемой и сложной конфигурации этих NVAs.

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

После изучения рекомендаций по проектированию сети для решения Azure VMware рассмотрите следующие статьи:

  • Last updated on