Problembehandlung für Azure Load Balancer-Antworten auf Back-End-Datenverkehr

Artikel
02/23/2024

Diese Seite enthält Informationen zur Problembehandlung für Fragen zu Azure Load Balancer.

Datenverkehr wird ungleichmäßig auf VMs hinter einem Lastenausgleichsmodul verteilt

Wenn Sie vermuten, dass Mitglieder des Back-End-Pools Datenverkehr empfangen, könnte dies folgende Ursachen haben. Azure Load Balancer verteilt den Datenverkehr basierend auf Verbindungen. Achten Sie darauf, die Verteilung des Datenverkehrs pro Verbindung und nicht pro Paket zu überprüfen. Überprüfen Sie dies auf der Registerkarte Flow Distribution in Ihrem vorkonfigurierten Load Balancer Insights Dashboard.

Azure Load Balancer unterstützt keinen echten Roundrobin-Lastausgleich, sondern einen hashbasierten Verteilungsmodus.

Ursache 1: Sie haben Session-Persistenz konfiguriert

Die Verwendung des Quell-Persistenzverteilungsmodus kann eine ungleichmäßige Verteilung des Datenverkehrs verursachen. Wenn diese Verteilung nicht erwünscht ist, aktualisieren Sie die Sitzungspersistenz auf Keine, damit der Datenverkehr auf alle fehlerfreien Instanzen im Back-End-Pool verteilt wird. Erfahren Sie mehr über die Verteilungsmodi für Azure Load Balancer.

Ursache 2: Sie haben einen Proxy konfiguriert

Clients, die hinter Proxys ausgeführt werden, können aus Sicht des Lastenausgleichs als eine einzige Clientanwendung betrachtet werden.

VMs hinter einem Lastenausgleichsmodul antworten nicht auf Datenverkehr am konfigurierten Datenport

Wenn eine VM im Back-End-Pool als fehlerfrei aufgeführt ist und auf die Integritätstests antwortet, aber dennoch nicht am Lastenausgleich teilnimmt oder nicht auf den Datenverkehr antwortet, kann dies folgende Gründe haben:

Eine VM im Back-End-Pool für den Lastenausgleich lauscht nicht am Datenport.
Eine Netzwerksicherheitsgruppe blockiert den Port auf der VM im Back-End-Pool für den Lastenausgleich.
Der Zugriff auf das Lastenausgleichsmodul erfolgt über dieselbe VM und NIC.
Der Zugriff auf das Front-End für den Internetlastenausgleich erfolgt über die teilnehmende VM im Back-End-Pool für den Lastenausgleich.

Ursache 1: Eine VM im Back-End-Pool für den Lastenausgleich lauscht nicht am Datenport

Wenn eine VM nicht auf den Datenverkehr antwortet, kann dies daran liegen, dass der Zielport auf der beteiligten VM nicht geöffnet ist oder die VM nicht an diesem Port lauscht.

Überprüfung und Lösung

Melden Sie sich bei der Back-End-VM an.
Öffnen Sie eine Eingabeaufforderung, und überprüfen Sie durch Ausführung des folgenden Befehls, ob eine Anwendung am Datenport lauscht:
```
netstat -an 
```
Wenn der Port nicht mit dem Status LISTENING aufgeführt ist, konfigurieren Sie den richtigen Listenerport.
Wenn der Port als LISTENING markiert ist, überprüfen Sie die Zielanwendung an diesem Port auf mögliche Probleme.

Ursache 2: Eine Netzwerksicherheitsgruppe blockiert den Port auf der VM im Back-End-Pool für den Lastenausgleich

Wenn eine oder mehrere im Subnetz oder auf der VM konfigurierte Netzwerksicherheitsgruppen die Quell-IP oder den Port blockieren, kann die VM nicht antworten.

Beim öffentlichen Load Balancer wird für die Kommunikation zwischen den Clients und den Back-End-VMs des Load Balancers die IP-Adresse der Internetclients verwendet. Stellen Sie sicher, dass die IP-Adressen der Clients in der Netzwerksicherheitsgruppe der Back-End-VMs zulässig sind.

Listen Sie die Netzwerksicherheitsgruppen auf, die auf der Back-End-VM konfiguriert sind. Weitere Informationen finden Sie unter Verwalten von Netzwerksicherheitsgruppen.
Überprüfen Sie Folgendes anhand der Liste von Netzwerksicherheitsgruppen:
- Der eingehende oder ausgehende Datenverkehr am Datenport ist gestört.
- Eine Regel Alle verweigern für Netzwerksicherheitsgruppen der NIC der VM oder des Subnetzes weist eine höhere Priorität als die Standardregel auf, die Load Balancer-Tests und -Datenverkehr zulässt (Netzwerksicherheitsgruppen müssen die Load Balancer-IP-Adresse 168.63.129.16 [Testport] zulassen).
Wenn eine der Regeln den Datenverkehr blockiert, entfernen und konfigurieren Sie diese Regeln, um den Datenverkehr zuzulassen.
Testen Sie, ob die VM jetzt auf Integritätstests antwortet.

Ursache 3: Der Zugriff auf das interne Lastenausgleichsmodul erfolgt über dieselbe VM und Netzwerkschnittstelle.

Wenn die auf der Back-End-VM eines internen Lastenausgleichsmoduls gehostete Anwendung versucht, auf eine andere Anwendung zuzugreifen, die auf derselben Back-End-VM gehostet wird und dieselbe Netzwerkschnittstelle verwendet, ist dies ein nicht unterstütztes Szenario, und es kommt zu einem Fehler.

Auflösung

Sie können dieses Problem mit einer der folgenden Methoden beheben:

Konfigurieren Sie separate Back-End-Pool-VMs für jede Anwendung.
Konfigurieren Sie die Anwendung in VMs mit zwei NICs, damit jede Anwendung eine eigene Netzwerkschnittstelle und IP-Adresse verwendet.

Ursache 4: Der Zugriff auf das Front-End für den Internetlastenausgleich erfolgt über die teilnehmende VM im Back-End-Pool für den Lastenausgleich

Wenn ein interner Lastenausgleich innerhalb eines virtuellen Netzwerks konfiguriert wird und eine der teilnehmenden Back-End-VMs versucht, auf das Front-End des internen Lastenausgleichs zuzugreifen, treten möglicherweise Fehler auf, wenn der Flow der Ausgangs-VM zugeordnet wird. Dieses Szenario wird nicht unterstützt.

Auflösung

Es gibt mehrere Möglichkeiten, die Blockierung für dieses Szenario aufzuheben, darunter beispielsweise durch die Verwendung eines Proxys. Evaluieren Sie Application Gateway oder andere Proxys von Drittanbietern (z. B. nginx oder haproxy). Weitere Informationen zu Application Gateway finden Sie unter Übersicht über Application Gateway.

Details

Interne Lastenausgleichsmodule führen für ausgehende Verbindungen keine Übersetzung für das Front-End eines internen Lastenausgleichsmoduls durch, da sich beide im privaten IP-Adressraum befinden. Über öffentliche Lastenausgleichsmodule werden ausgehende Verbindungen von privaten IP-Adressen im virtuellen Netzwerk mit öffentlichen IP-Adressen bereitgestellt. Bei internen Lastenausgleichsmodulen wird mit diesem Ansatz die potenzielle SNAT-Portüberlastung in einem eindeutigen internen IP-Adressraum vermieden, für den die Übersetzung nicht erforderlich ist.

Hierbei ergibt sich die folgende Nebenwirkung: Wenn ein von einem virtuellen Computer ausgehender Flow in den Back-End-Pool versucht, einen Flow zum Front-End der internen Load Balancer-Instanz im Pool auszuführen und sich selbst zugewiesen ist, stimmen die beiden Verzweigungen des Flows nicht überein. Aufgrund dieser fehlenden Übereinstimmung tritt für den Flow ein Fehler auf. Der Flow ist erfolgreich, wenn er nicht dem virtuellen Computer im Back-End-Pool zugeordnet ist, die den Flow zum Front-End erstellt hat.

Wenn der Flow sich selbst zugeordnet ist, geht der ausgehende Flow zum Front-End scheinbar vom virtuellen Computer und der zugehörige eingehende Flow scheinbar vom virtuellen Computer an sich selbst aus. Aus Sicht des Gastbetriebssystems stimmen die eingehenden und ausgehenden Bestandteile desselben Flows innerhalb des virtuellen Computers nicht überein. Der TCP-Stack erkennt nicht, dass es sich bei diesen Hälften um Teile desselben Flows handelt. Die Quelle und das Ziel stimmen nicht überein. Wenn der Flow keinem anderen virtuellen Computer im Back-End-Pool zugeordnet ist, stimmen die Teile des Flows überein, und der virtuelle Computer kann auf den Flow antworten.

Das Symptom für dieses Szenario sind zeitweilige Verbindungstimeouts, die auftreten, wenn der Flow zu demselben Back-End zurückkehrt, vom dem er ursprünglich stammt. Zu den häufig genutzten Problemumgehungen gehören das Einfügen einer Proxyebene hinter dem internen Lastenausgleichsmodul und das Verwenden von DSR-Stilregeln (Direct Server Return). Weitere Informationen finden Sie unter Mehrere Front-Ends für Azure Load Balancer.

Sie können ein internes Lastenausgleichsmodul mit einem beliebigen Proxy eines Drittanbieters kombinieren oder die interne Application Gateway-Instanz für Proxyszenarien mit HTTP/HTTPS verwenden. Es ist zwar möglich, zum Beheben dieses Problems ein öffentliches Lastenausgleichsmodul zu nutzen, aber das sich ergebende Szenario ist anfällig für eine zu hohe SNAT-Auslastung. Nutzen Sie diesen zweiten Ansatz nur, wenn eine sorgfältige Verwaltung durchgeführt werden kann.

Nächste Schritte

Sollte sich das Problem mit den oben genannten Schritten nicht beheben lassen, erstellen Sie ein Supportticket.

Freigeben über