Guide Mobility Optimized Networking (MON) pour VMware HCX

  • Article

Remarque

VMware HCX Mobility Optimized Networking est officiellement pris en charge par VMware et Azure VMware Solution à partir de HCX version 4.1.0.

Important

Avant d’activer HCX MON, lisez ci-dessous les limitations et les configurations non prises en charge :

Configurations sources non prises en charge pour HCX NE

Limitations pour tout déploiement HCX, y compris MON

VMware HCX Mobility Optimized Networking (MON) n’est pas pris en charge avec l’utilisation d’une passerelle tierce. Elle peut uniquement être utilisée avec la passerelle T1 directement connectée à la passerelle T0 sans appliance virtuelle réseau (NVA). Vous pouvez peut-être effectuer cette fonction de configuration, mais nous ne la prenons pas en charge.

HCX Mobility Optimized Networking (MON) est une fonctionnalité optionnelle à activer lors de l’utilisation des extensions réseau HCX (NE). MON assure un routage optimal du trafic dans certains scénarios pour éviter l’effet tromboning du réseau entre les ressources locales et informatiques sur les réseaux étendus.

Comme MON est une fonctionnalité d’entreprise de la fonctionnalité NE, veillez à activer VMware HCX Enterprise via le Portail Azure.

Tout au long du cycle de migration, MON optimise la mobilité des applications pour :

  • Optimiser la communication L2 entre machines virtuelles (VM) lors de l’utilisation de réseaux étendus

  • Optimiser et prévenir les flux de trafic asymétriques entre l’environnement local, Azure VMware Solution et Azure

Dans cet article, découvrez les cas d’usage spécifiques à Azure VMware Solution pour MON.

Optimiser les flux de trafic entre les segments standard et étendus du côté du cloud privé

Dans ce scénario, VM1 est migré vers le cloud à l’aide des NE, ce qui offre une latence optimale entre machines virtuelles. Par conséquent, VM1 a besoin d’une faible latence pour VM3 sur le segment Azure VMware Solution local. Nous migrons la passerelle VM1 de l’environnement local vers Azure VMware Solution (cloud) pour garantir un chemin d’accès optimal pour le trafic (ligne bleue). Si la passerelle reste locale (ligne rouge), un effet de tromboning et une latence plus élevée sont observés.

Remarque

Lorsque vous activez MON sans migrer la passerelle de machine virtuelle vers le côté cloud, cela ne garantit pas un chemin d’accès optimal pour le flux de trafic. Cela ne permet pas non plus l’évaluation des itinéraires de stratégie.

Diagram showing the optimization for VM to VM L2 communication when using stretched networks.

Optimiser et éviter les flux de trafic asymétriques

Dans ce scénario, nous partons du principe qu’une machine virtuelle locale est migrée vers Azure VMware Solution et participe aux flux de trafic L2 et L3 vers local pour accéder aux services. Nous partons également du principe que certaines communications de machine virtuelle d’Azure (dans le réseau virtuel connecté à Azure VMware Solution) peuvent accéder au cloud privé Azure VMware Solution.

Important

Le point essentiel ici consiste à planifier et éviter les flux de trafic asymétriques avec soin.

Par défaut et sans utiliser MON, une machine virtuelle dans Azure VMware Solution sur un réseau étendu sans MON peut communiquer en retour à l’environnement local à l’aide du chemin d’accès ExpressRoute par défaut. En fonction des cas d’utilisation du client, vous devez évaluer la façon dont une machine virtuelle sur un segment étendu Azure VMware Solution activé avec MON doit passer en local, soit sur l’extension réseau, soit sur la passerelle T0 via ExpressRoute tout en conservant les flux de trafic symétriques.

Si vous choisissez le chemin d’accès NE par exemple, les itinéraires de stratégie MON doivent spécifiquement traiter le sous-réseau côté local ; sinon, l’itinéraire par défaut 0.0.0.0/0 est utilisé. Vous trouverez des itinéraires de stratégie sous le segment NE, en sélectionnant Avancé.

Par défaut, toutes les adresses IP RFC 1918 sont incluses dans la définition des itinéraires de stratégie MON.

Screenshot showing the egress traffic flow with default policy-based routes.

Cela entraîne l’acheminement du trafic de sortie RFC 1918 sur le chemin d’accès NE et tout le trafic Internet et public acheminé vers la passerelle T0.

Diagram showing the RFC 1918 egress and egress traffic flow.

Les itinéraires de stratégie sont évalués uniquement si la passerelle de machine virtuelle est migrée vers le cloud. Cette configuration fait que tous les sous-réseaux correspondants pour la destination sont acheminés par le biais de l’appliance NE. S’ils ne correspondent pas, ils sont routés via la passerelle T0.

Remarque

Pour utiliser MON dans Azure VMware Solution, il faut veiller à donner les itinéraires /32 sur BGP à ses homologues ; cela comprend l’environnement local et Azure sur la connexion ExpressRoute. Par exemple, une machine virtuelle dans Azure apprend le chemin d’accès à une machine virtuelle Azure VMware Solution sur un segment Azure VMware Solution avec MON activé. Une fois que le trafic de retour est renvoyé à la passerelle T0 comme prévu, si le sous-réseau de retour est une correspondance RFC 1918, le trafic est forcé sur le NE au lieu du T0. Ensuite, il sort sur ExpressRoute en retour vers Azure du côté local. Cela peut entraîner une confusion pour les pare-feu avec état dans le comportement de routage du milieu et asymétrique. Il est également judicieux de déterminer la façon dont les machines virtuelles sur les segments NE MON devront accéder à Internet, via la passerelle T0 dans Azure VMware Solution ou uniquement via le NE vers l’environnement local. En général, tous les itinéraires de stratégie par défaut doivent être supprimés pour éviter le trafic asymétrique. Activez uniquement les itinéraires de stratégie si l’infrastructure réseau telle qu’elle a été configurée de telle manière à prendre en compte et à empêcher le trafic asymétrique.

Les itinéraires de stratégie MON peuvent être supprimés sans aucune définition. Cela entraîne l’acheminement de tout le trafic de sortie vers la passerelle T0.

Screenshot showing the egress traffic flow with no policy-based routes.

Les itinéraires de stratégie MON peuvent être mis à jour avec un itinéraire par défaut (0.0.0.0/0). Cela entraîne le tunnel de tout le trafic de sortie sur le chemin d’accès NE.

Screenshot showing the egress traffic flow with a 0.0.0.0/0 policy-based route.

Comme indiqué dans les diagrammes ci-dessus, l’importance est de faire correspondre un itinéraire de stratégie à chaque sous-réseau requis. Sinon, le trafic est acheminé sur le T0 et n’est pas tunnelisé sur le NE.

Pour en savoir plus sur les itinéraires de stratégie, consultez Itinéraires de stratégie de Mobility Optimized Networking.