Le DLR et la passerelle ESG reposent sur le DVS pour fournir des services de transfert L2 pour des dvPortgroup (basés sur VXLAN et VLAN) afin que la connectivité de bout en bout fonctionne.
Cela signifie que les services de transfert L2 qui sont connectés au DLR ou à la passerelle ESG doivent être configurés et opérationnels. Dans le processus d'installation de NSX, ces services sont fournis par « Préparation de l'hôte » et « Préparation du réseau logique ».
Lorsque vous créez des zones de transport dans des configurations VDS avec plusieurs clusters, vérifiez que tous les clusters du DVS sélectionné sont inclus sous la zone de transport. Cela permet de s'assurer que le DLR est disponible sur tous les clusters dans lesquels des dvPortgroup du DVS sont disponibles.
Lorsqu'une zone de transport est alignée avec la limite du DVS, l'instance du DLR est créée correctement.
Lorsqu'une zone de transport n'est pas alignée sur la limite du DVS, l'étendue des commutateurs logiques (5001, 5002 et 5003) et des instances du DLR auxquels ces commutateurs logiques sont connectés se retrouve disjointe, ce qui a pour conséquence d'interrompre l'accès des VM du cluster Comp A aux LIF du DLR.
Dans le schéma ci-dessus, le DVS « Compute_DVS » couvre deux clusters, « Comp A » et « Comp B ». « Global-Transport-Zone » inclut « Comp A » et « Comp B ».
Cela se traduit par l'alignement correct entre l'étendue des commutateurs logiques (5001, 5002 et 5003) et l'instance du DLR créée sur tous les hôtes dans tous les clusters sur lesquels ces commutateurs logiques sont présents.
Maintenant, voyons une autre situation, où la zone de transport n'était pas configurée pour inclure le cluster « Comp A » :
Dans ce cas, les VM exécutées sur le cluster « Comp A » disposent d'un accès complet à tous les commutateurs logiques. Cela s'explique par le fait que les commutateurs logiques sont représentés par des dvPortgoup sur les hôtes, et les dvProtgroup sont une construction au niveau du DVS. Dans notre exemple d'environnement, « Compute_DVS » couvre à la fois « Comp A » et « Comp B ».
Toutefois, les instances du DLR sont créées en alignement strict avec l'étendue de la zone de transport, ce qui signifie qu'aucune instance du DLR ne sera créée sur les hôtes dans « Comp A ».
Par conséquent, la VM « web1 » pourra atteindre les VM « web2 » et « LB », car elles se trouvent sur le même commutateur logique, mais les VM « app1 » et « db1 » ne pourront communiquer avec rien.
Le DLR repose sur le cluster de contrôleurs pour fonctionner, ce qui n'est pas le cas de la passerelle ESG. Avant de créer ou de modifier la configuration d'un DLR, vérifiez que le cluster de contrôleurs est actif et disponible.
Si le DLR doit être connecté à des dvPortgroup de VLAN, vérifiez que les hôtes ESXi avec le DLR configuré peuvent s'atteindre sur UDP/6999 pour que le proxy ARP basé sur VLAN du DLR fonctionne.
- Une instance du DLR donnée ne peut pas être connectée aux commutateurs logiques se trouvant dans des zones de transport distinctes. Cela permet de s'assurer que tous les commutateurs logiques et les instances du DLR sont alignés.
- Le DLR ne peut pas être connecté à des groupes de ports reposant sur VLAN, si ce DLR est connecté à des commutateurs logiques s'étendant sur plusieurs DVS. Comme ci-dessus, cela permet d'assurer un alignement correct des instances du DLR avec les commutateurs logiques et les dvPortgroup sur les hôtes.
- Lorsque vous sélectionnez le placement d'une VM de contrôle du DLR, évitez de la placer sur le même hôte qu'une ou plusieurs de ses passerelles ESG en amont à l'aide de règles d'anti-affinité du DRS si elles se trouvent sur le même cluster. Cela permet de réduire l'impact de l'échec de l'hôte sur le transfert du DLR.
- OSPF ne peut être activé que sur une seule liaison montante (mais il prend en charge plusieurs contiguïtés). BGP, d'un autre côté, peut être activé sur plusieurs interfaces de liaison montante, où cela est nécessaire.
