Руководство по VMware HCX Mobility Optimized Networking (MON)
Примечание.
VMware HCX Mobility Optimized Networking официально поддерживается VMware и Решение Azure VMware из HCX версии 4.1.0.
Внимание
Прежде чем включить HCX MON, ознакомьтесь со следующими ограничениями и неподдерживаемыми конфигурациями:
Неподдерживаемые исходные конфигурации для HCX NE
Ограничения для любого развертывания HCX, включая MON
HCX Mobility Optimized Networking (MON) VMware HCX не поддерживается при использовании стороннего шлюза. Он может использоваться только с шлюзом T1 напрямую, подключенным к шлюзу T0 без виртуальной сети (модуль) (NVA). Вы можете сделать эту функцию конфигурации, но мы не поддерживаем ее.
HCX Mobility Optimized Networking (MON) — это необязательная функция для включения при использовании сетевых расширений HCX (NE). MON обеспечивает оптимальную маршрутизацию трафика в определенных сценариях, чтобы предотвратить тромдонирование сети между локальными и облачными ресурсами в расширенных сетях.
Так как MON — это корпоративная возможность функции NE, убедитесь, что вы включили VMware HCX Enterprise через портал Azure.
На протяжении всего цикла миграции MON оптимизирует мобильность приложений для следующих компонентов:
Оптимизация для обмена данными виртуальной машины с виртуальной машиной L2 при использовании растянутой сети
Оптимизация и предотвращение асимметричных потоков трафика между локальными, Решение Azure VMware и Azure
В этой статье описаны варианты использования Решение Azure VMware для MON.
Оптимизация потоков трафика через стандартные и растянутые сегменты на стороне частного облака
В этом сценарии виртуальная машина 1 переносится в облако с помощью NE, что обеспечивает оптимальную задержку виртуальной машины к виртуальной машине. В результате виртуальная машина 1 нуждается в низкой задержке к VM3 в локальном Решение Azure VMware сегменте. Мы переносим шлюз VM1 из локальной среды в Решение Azure VMware (облако), чтобы обеспечить оптимальный путь для трафика (синяя линия). Если шлюз остается локальной (красной линией), наблюдается эффект тромонирования и более высокая задержка.
Примечание.
Если включить MON без переноса шлюза виртуальных машин на сторону облака, он не гарантирует оптимальный путь для потока трафика. Она также не позволяет оценивать маршруты политики.
Оптимизация и предотвращение асимметричных потоков трафика
В этом сценарии предполагается, что виртуальная машина из локальной среды переносится в Решение Azure VMware и участвует в потоках трафика L2 и L3 обратно в локальную среду для доступа к службам. Мы также предполагаем, что некоторые виртуальные машины из Azure (в Решение Azure VMware подключенной виртуальной сети) могут перейти к Решение Azure VMware частному облаку.
Внимание
Основной момент заключается в том, чтобы тщательно планировать и избегать асимметричных потоков трафика.
По умолчанию и без использования MON виртуальная машина в Решение Azure VMware в растянутой сети без MON может взаимодействовать с локальной средой с помощью предпочтительного пути ExpressRoute. В зависимости от вариантов использования клиентов следует оценить, как виртуальная машина на Решение Azure VMware растянутом сегменте, включенном с помощью MON, должна проходить обратно в локальную среду либо через расширение сети, либо шлюз T0 через ExpressRoute, сохраняя симметричный поток трафика.
При выборе пути NE, например, маршруты политики MON должны специально обращаться к подсети на локальной стороне; в противном случае используется маршрут по умолчанию 0.0.0.0/0. Маршруты политики можно найти в сегменте NE, выбрав дополнительно.
По умолчанию все IP-адреса RFC 1918 включены в определение маршрутов политики MON.
Это приводит к тому, что весь исходящий трафик RFC 1918 туннелируется через путь NE и весь интернет и общедоступный трафик направляется в шлюз T0.
Маршруты политики оцениваются только в том случае, если шлюз виртуальных машин переносится в облако. Эффект этой конфигурации заключается в том, что все соответствующие подсети для назначения получают туннелированные через ne (модуль). Если они не совпадают, они направляются через шлюз T0.
Примечание.
Особое внимание для использования MON в Решение Azure VMware заключается в том, чтобы предоставить маршруты /32, объявленные через BGP своим одноранговым узлам; это включает в себя локальную среду и Azure через подключение ExpressRoute. Например, виртуальная машина в Azure узнает путь к Решение Azure VMware виртуальной машине в сегменте с поддержкой Решение Azure VMware MON. После отправки возвращаемого трафика обратно в шлюз T0, как ожидалось, если возвращаемая подсеть является совпадением RFC 1918, трафик перенаправляется через NE вместо T0. Затем исходящий трафик через ExpressRoute обратно в Azure на локальной стороне. Это может привести к путанице для брандмауэров с отслеживанием состояния в середине и асимметричном поведении маршрутизации. Кроме того, рекомендуется определить, как виртуальные машины в сегментах NE MON потребуются для доступа к Интернету через шлюз T0 в Решение Azure VMware или только через NE обратно в локальную среду. Как правило, все маршруты политики по умолчанию должны быть удалены, чтобы избежать асимметричного трафика. Включите маршруты политики только в том случае, если сетевая инфраструктура настроена таким образом, чтобы учитывать и предотвращать асимметричный трафик.
Маршруты политики MON можно удалить без определенных. Это приводит к тому, что весь исходящий трафик направляется в шлюз T0.
Маршруты политики MON можно обновить с помощью маршрута по умолчанию (0.0.0.0/0/0). Это приводит к тому, что весь исходящий трафик туннелируется через путь NE.
Как описано на приведенных выше схемах, важно сопоставить маршрут политики с каждой требуемой подсетью. В противном случае трафик направляется через T0 и не туннелируется через NE.
Дополнительные сведения о маршрутах политики см. в статье "Маршруты политики оптимизации мобильности".