Der DLR und das ESG benötigen für die Bereitstellung von L2-Weiterleitungsdiensten für dvPortgroups (sowohl VXLAN- als auch VLAN-basiert) den DVS für eine funktionierende End-to-End-Konnektivität.
Dies bedeutet, dass L2 für Weiterleitungsdienste, die mit dem DLR und dem ESG verbunden sind, konfiguriert und betriebsbereit sein müssen. Während des NSX-Installationsvorgangs werden diese Dienste durch die „Hostvorbereitung“ und die „Vorbereitung des logischen Netzwerks“ bereitgestellt.
Für das Anlegen von Transportzonen für Multi-Cluster-DVS-Konfigurationen müssen alle Cluster in dem ausgewählten DVS in der Transportzone enthalten sein. Dadurch wird sichergestellt, dass der DLR auf allen Clustern verfügbar ist, in denen auch DVS-dvPortgroups vorhanden sind.
Die DLR-Instanz wurde korrekt erstellt, wenn eine Transportzone an der DVS-Begrenzung ausgerichtet ist.
Wenn eine Transportzone nicht an der DVS-Begrenzung ausgerichtet ist, werden der Geltungsbereich der logischen Switches (5001, 5002 und 5003) und die DLR-Instanzen, mit denen diese logischen Switches verbunden sind, getrennt. VMs im Cluster „Comp A“ haben dann keinen Zugriff auf die DLR-LIFs.
Im oben dargestellten Diagramm erstreckt sich der DVS „Compute_DVS“ über die beiden Cluster „Comp A“ und „Comp B“. Die „Globale Transportzone“ enthält sowohl „Comp A“ als auch „Comp B“.
Dies führt zu einer korrekten Ausrichtung zwischen dem Geltungsbereich der logischen Switches (5001, 5002 und 5003) und der DLR-Instanz, die auf allen Hosts in allen Clustern erstellt wurde, in denen diese logischen Switches vorhanden sind.
Wenden wir uns nun einem alternatives Szenario zu, in dem die Konfiguration der Transportzone den Cluster „Comp A“ nicht beinhaltet:
In diesem Fall haben die VMs, die auf Cluster „Comp A“ ausgeführt werden, einen kompletten Zugriff auf alle logischen Switches. Dies ist darauf zurückzuführen, dass die logischen Switches von den dvPortgoups auf Hosts repräsentiert werden und die dvPortgoups ein DVS-weites Konstrukt sind. In unserer Beispielumgebung erstreckt sich „Compute_DVS“ sowohl über „Comp A“ als auch „Comp B“.
Die DLR-Instanzen sind jedoch streng am Geltungsbereich der Transportzone ausgerichtet. Das bedeutet, dass auf den Hosts in „Comp A“ keine DLR-Instanzen erstellt werden.
Im Ergebnis kann die VM „web1“ die VMs „web2“ und „LB“ erreichen, da sie sich auf demselben logischen Switch befinden. Die VMs „app1“ und „db1“ sind dagegen nicht in der Lage, mit anderen zu kommunizieren.
Der DLR benötigt einen funktionsfähigen Controller-Cluster, das ESG hingegen nicht. Stellen Sie sicher, dass der Controller-Cluster eingerichtet und verfügbar ist, ehe Sie eine DLR-Konfiguration erstellen oder ändern.
Wenn der DLR mit VLAN-dvPortgroups verbunden werden soll, stellen Sie sicher, dass die ESXi-Hosts mit konfiguriertem DLR sich gegenseitig auf UDP/6999 erreichen können, damit der DLR-VLAN-basierte ARP-Proxy funktioniert.
- Eine bestimmte DLR-Instanz kann nicht mit logischen Switches verbunden werden, die sich in verschiedenen Transportzonen befinden. Dadurch wird sichergestellt, dass alle logischen Switches und DLR-Instanzen ausgerichtet sind.
- Der DLR kann nicht mit VLAN-gestützten Portgruppen verbunden werden, wenn dieser mit logischen Switches verbunden ist, die sich über mehr als einen DVS erstrecken. Damit wird wie zuvor die korrekte Ausrichtung der DLR-Instanzen auf die logischen Switches und dvPortgroups für alle Hosts sichergestellt.
- Bei der Auswahl der Position der DLR-Kontroll-VM sollten Sie diese nicht auf demselben Host platzieren, auf dem sich bereits ein oder mehrere ihrer Upstream-ESGs befinden. Dazu verwenden Sie DRS-Anti-Affinitätsregeln, wenn sie sich in demselben Cluster befinden. Dadurch lassen sich die Auswirkungen von Hostfehlern bei DLR-Weiterleitungen verringern.
- OSPF darf nur auf einem einzelnen Uplink aktiviert sein (kann aber mehrere Nachbarschaften unterstützen). BGP hingegen darf auf mehreren Uplink-Schnittstellen aktiviert sein, sofern dies notwendig ist.
