Beheben von Problemen mit Azure Load Balancer

  • Artikel

Dieser Artikel enthält Informationen zur Problembehandlung für allgemeine Fragen zu Azure Load Balancer (Basic und Standard). Weitere Informationen zu Load Balancer Standard finden Sie in der Übersicht über Azure Load Balancer Standard.

Wenn die Konnektivität eines Lastenausgleichs nicht verfügbar ist, sind die häufigsten Symptome:

  • VMs (Virtual Machines) hinter dem Lastenausgleich antworten nicht auf Integritätstests.
  • VMs hinter dem Lastenausgleich antworten nicht auf Datenverkehr am konfigurierten Port.

Wenn die externen Clients für die Back-End-VMs den Lastenausgleich durchlaufen, wird die IP-Adresse der Clients für die Kommunikation verwendet. Stellen Sie sicher, dass die IP-Adresse der Clients zur Zulassungsliste der Netzwerksicherheitsgruppe (NSG) hinzugefügt wird.

Problem: Keine ausgehende Verbindung von dem internen Standardlastenausgleich

Überprüfung und Lösung

Der Interne Standardlastenausgleich (ILBs) verfügt über Standardsicherheitsfeatures. Basic-ILBs erlauben eine Verbindung mit dem Internet über eine verborgene öffentliche IP-Adresse namens Standard-IP-Adresse für den ausgehenden Zugriff. Es wird nicht empfohlen, eine Verbindung über standardmäßige ausgehende Zugriffs-IPs für Produktionsworkloads herzustellen, da die IP-Adresse nicht statisch ist oder über Netzwerksicherheitsgruppen in Ihrem Besitz gesperrt ist.

Wenn Sie kürzlich von einer Basic ILB zu einer Standard ILB gewechselt sind und ausgehende Verbindungen mit dem Internet von Ihren VMs benötigen, können Sie Azure NAT Gateway in Ihrem Subnetz konfigurieren. Wir empfehlen NAT Gateway für alle ausgehenden Zugriffe in Produktionsszenarien.

Keine eingehende Konnektivität mit dem externen Standardlastenausgleich

Ursache

Der Standardlastenausgleich sowie öffentliche Standard-IP-Adressen sind für eingehende Verbindungen geschlossen, sofern sie nicht durch Netzwerksicherheitsgruppen geöffnet werden. Sie verwenden NSGs, um den zulässigen Datenverkehr explizit zuzulassen. Sie müssen Ihre NSGs so konfigurieren, dass der zulässige Datenverkehr explizit zulässig ist. Wenn Sie über keine NSG für ein Subnetz oder für eine NIC (Network Interface Card) Ihrer VM-Ressource verfügen, ist diese Ressource für Datenverkehr nicht erreichbar.

Lösung

Um den eingehenden Datenverkehr zuzulassen, fügen Sie dem Subnetz oder der Schnittstelle für Ihre virtuelle Ressource eine Netzwerksicherheitsgruppe hinzu.

Problem: Der Back-End-Port für die vorhandene Lastenausgleichsregel eines Lastenausgleichs, der eine VM-Skalierungsgruppe im Back-End-Pool bereitgestellt hat, kann nicht geändert werden

Ursache

Wenn ein Lastenausgleichsmodul mit einer VM-Skalierungsgruppe konfiguriert ist, können Sie den Back-End-Port einer Lastenausgleichsregel nicht ändern, während sie einem Integritätstest zugeordnet ist.

Lösung

Um den Port zu ändern, können Sie die Integritätssonde entfernen. Aktualisieren Sie die VM-Skalierungsgruppe, aktualisieren Sie den Port und konfigurieren Sie dann den Integritätstest erneut.

Problem: Geringer Datenverkehr wird noch über den Lastenausgleich geleitet, nachdem die VMs aus dem Back-End-Pool entfernt wurden

Ursache

Aus dem Back-End-Pool entfernte VMs sollten keinen Datenverkehr mehr empfangen. Die geringe Menge an Netzwerkdatenverkehr könnte im Zusammenhang mit Speicher, DNS (Domain Name System) und anderen Funktionen in Azure stehen.

Lösung

Um dies zu überprüfen, können Sie eine Netzwerküberwachung durchführen. Die Eigenschaften der einzelnen Speicherkonten enthalten den vollqualifizierten Domänennamen (FQDN) für Ihr Blob-Speicherkonto. Auf einer VM innerhalb Ihres Azure-Abonnements können Sie nslookup ausführen, um die Azure-IP-Adresse zu ermitteln, die diesem Speicherkonto zugewiesen ist.

Problem: Load Balancer in fehlerhaftem Zustand

Lösung

  1. Wechseln Sie zum Azure Resource Explorer und identifizieren Sie die Ressource in diesem Zustand.
  2. Aktualisieren Sie die Umschaltfläche in der oberen rechten Ecke auf Lese-/Schreibzugriff.
  3. Wählen Sie für die Ressource im fehlerhaften Zustand Bearbeiten aus.
  4. Wählen Sie PUT und dann GET aus, um sicherzustellen, dass der Bereitstellungszustand auf Erfolgreich geändert wurde.

Sie können dann mit anderen Aktionen fortfahren, weil die Ressource nicht mehr fehlerhaft ist.

Netzwerkaufzeichnungen für Supporttickets

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

Wenn Sie ein Supportticket eröffnen möchten, sammeln Sie Netzwerkaufzeichnungen für eine schnellere Lösung. Wählen Sie eine einzelne Back-End-VM für die Durchführung der folgenden Tests aus:

  • Verwenden Sie ps ping auf einer der Back-End-VMs im VNet, um die Reaktion des Testports zu testen (Beispiel: ps ping 10.0.0.4:3389), und zeichnen Sie die Ergebnisse auf.
  • Wenn Sie bei diesen Pingtests keine Antwort empfangen, führen Sie beim Ausführen von „PsPing“ eine gleichzeitige Netsh-Ablaufverfolgung auf der Back-End-VM und der VNet-Test-VM aus. Beenden Sie dann die Netsh-Ablaufverfolgung.