Freigeben über

Beheben von Problemen mit Ressourcenintegrität und eingehender Verfügbarkeit

  • Artikel

In diesem Artikel werden die Schritte zum Untersuchen von Problemen beschrieben, die sich auf die Verfügbarkeit der Front-End-IP-Adresse und Back-End-Ressourcen Ihrer Load Balancer-Instanz auswirken.

Der Resource Health Check (RHC) für den Load Balancer wird verwendet, um die Integrität Ihres Load Balancers zu ermitteln. Er analysiert die Datenpfadverfügbarkeits-Metrik über ein Intervall von 2 Minuten, um zu bestimmen, ob die Lastenausgleichs-Endpunkte, die Kombinationen aus Front-End-IP-Adressen und Front-End-Ports mit Lastenausgleichsregeln verfügbar sind.

Hinweis: RHC wird für den Basic SKU Load Balancer nicht unterstützt

In der folgenden Tabelle wird die zum Ermitteln des Integritätszustands des Load Balancers verwendete RHC-Logik beschrieben.

Ressourcenintegritätsstatus BESCHREIBUNG
Verfügbar Ihre Load Balancer Standard-Ressource ist fehlerfrei und verfügbar.
Heruntergestuft Für die Load Balancer Standard-Instanz liegen plattform- oder benutzerseitig initiierte Ereignisse vor, die sich auf die Leistung auswirken. Die Metrik für die Datenpfadverfügbarkeit hat mindestens zwei Minuten lang weniger als 90 %, aber mehr als 25 % Integrität gemeldet. Es werden mittlere bis schwerwiegende Leistungsbeeinträchtigungen auftreten.
Nicht verfügbar Ihre standardmäßige Lastenausgleichsressource ist nicht fehlerfrei. Die Metrik für die Datenpfadverfügbarkeit hat mindestens zwei Minuten lang einen Integritätswert von weniger als 25 % gemeldet. Es werden deutliche Leistungsbeeinträchtigungen auftreten oder eine mangelnde Verfügbarkeit der eingehenden Konnektivität. Möglicherweise liegen Benutzer- oder Plattformereignisse vor, die eine Nichtverfügbarkeit verursachen.
Unbekannt Der Integritätsstatus Ihrer Lastenausgleichs-Standardressource wurde noch nicht aktualisiert oder hat in den letzten 10 Minuten keine Informationen zur Datenpfadverfügbarkeit empfangen. Dieser Zustand ist vorübergehend. Der korrekte Status wird angegeben, sobald Daten empfangen werden.

Informationen zu den verwendeten Metriken

Für die Schritte dieses Artikels werden die beiden Metriken Datenpfadverfügbarkeit und Integritätsteststatus verwendet. Um die richtigen Rückschlüsse zu ziehen, sollten Sie mit diesen beiden Metriken vertraut sein.

Datenpfadverfügbarkeit

Die Metrik „Datenpfadverfügbarkeit“ wird von einem TCP-Ping alle 25 Sekunden an allen Front-End-Ports generiert, für die Lastenausgleichregeln und NAT-Regeln für eingehenden Datenverkehr konfiguriert sind. Dieser TCP-Ping wird an alle fehlerfreien (als verfügbar getesteten) Back-End-Instanzen weitergeleitet. Wenn der Dienst eine Antwort auf den Ping empfängt, wird der Vorgang als erfolgreich eingestuft, und für die Summe der Metrik erfolgt eine einmalige Iteration. Wenn keine Antwort empfangen wird, erfolgt keine Iteration. Die Anzahl dieser Metrik ist 1/100 der Gesamtzahl an TCP-Pings pro Testzeitraum. Folglich soll der Durchschnitt betrachtet werden. Dabei wird der Durchschnitt der Summe/Anzahl für den Zeitraum angezeigt. Bei Betrachtung der für den Durchschnitt aggregierten Metrik „Datenpfadverfügbarkeit“ erhalten wir also eine prozentuale Erfolgsquote für TCP-Pings an die IP-Adress-/Port-Kombination Ihres Front-Ends für jede Ihrer Lastenausgleichs- und NAT-Regeln für eingehenden Datenverkehr.

Integritätsteststatus

Die Metrik „Integritätsteststatus“ wird von einem Ping des Protokolls generiert, das im Integritätstest definiert ist. Dieser Ping wird an jede Instanz im Back-End-Pool sowie an dem im Integritätstest definierten Port gesendet. Bei HTTP- und HTTPS-Tests ist für ein erfolgreiches Ping eine HTTP 200 OK-Antwort erforderlich, bei TCP-Tests wird jede Antwort als erfolgreicher Vorgang eingestuft. Die aufeinanderfolgenden Erfolge oder Fehler jedes Tests bestimmen die Integrität der Back-End-Instanz und ob der zugewiesene Back-End-Pool Datenverkehr empfangen kann. Vergleichbar mit der Datenpfadverfügbarkeit wird die Durchschnittsaggregation verwendet, die Auskunft über den prozentualen Anteil an erfolgreichen Pings während des Testintervalls gibt. Dieser Wert des Integritätsteststatus zeigt die Back-End-Integrität isoliert von Ihrem Lastenausgleichsmodul an, indem Ihre Back-End-Instanzen getestet werden, ohne Datenverkehr durch das Front-End zu senden.

Wichtig

Das Zeitfenster für die Ermittlung des Integritätsteststatus beträgt eine Minute. Dadurch kann es bei einem ansonsten konstanten Wert zu geringfügigen Schwankungen kommen. Wenn z. B. zwei Back-End-Instanzen vorhanden sind (eine als verfügbar und eine als nicht verfügbar getestete), erfasst der Integritätstestdienst möglicherweise 7 Proben für den fehlerfreie Instanz und 6 für die fehlerhafte Instanz. Dadurch wird ein zuvor konstanter Wert von 50 für ein einminütiges Intervall als 46,15 angezeigt.

Diagnose bei beeinträchtigten und nicht verfügbaren Lastenausgleichsmodulen

Wie im Artikel zur Ressourcenintegrität beschrieben, ist ein herabgestufter Lastenausgleich einer, der zwischen 25 % und 90 % Datenpfadverfügbarkeit zeigt. Ein nicht verfügbarer Lastenausgleich ist einer mit weniger als 25 % Datenverfügbarkeit über einen Zeitraum von zwei Minuten. Anhand dieser Schritte können auch Fehler untersucht werden, die in Ihren konfigurierten Warnungen zum Integritätsteststatus oder zur Datenpfadverfügbarkeit angezeigt werden. Wir betrachten ein Beispiel, in dem beim Überprüfen der Ressourcenintegrität ermittelt wurde, dass das Lastenausgleichsmodul nicht verfügbar ist und eine Datenpfadverfügbarkeit von 0 % aufweist – der Dienst ist also nicht verfügbar.

Zunächst rufen wir die Detailansicht der Metriken auf der Seite mit den Erkenntnissen für unser Lastenausgleichsmodul im Azure-Portal auf. Diese Ansicht erreichen Sie über die Seite „Ressourcen“ des Lastenausgleichs oder über den Link in der Nachricht zur Ressourcenintegrität. Anschließend navigieren wir zur Registerkarte mit der Front-End- und Back-End-Verfügbarkeit. Dort überprüfen wir ein dreißigminütiges Zeitfenster innerhalb des Zeitraums, in dem der beeinträchtigte oder nicht verfügbare Zustand eingetreten ist. Wenn die Datenpfadverfügbarkeit bei 0 % liegt, wissen wir, dass aufgrund eines Problems Datenverkehr für alle unsere Lastenausgleichsregeln und NAT-Regeln für eingehenden Datenverkehr verhindert wird. Außerdem lässt sich die Dauer dieser Beeinträchtigung erkennen.

Als Nächstes müssen wir anhand der Integritätsteststatus-Metrik ermitteln, ob der Datenpfad nicht verfügbar ist, weil keine fehlerfreien Back-End-Instanzen für den Datenverkehr verfügbar sind. Wenn mindestens eine fehlerfreie Back-End-Instanz für alle unsere Lastenausgleichsregeln und Regeln für eingehenden Datenverkehr vorhanden ist, wissen wir, dass die Nichtverfügbarkeit der Datenpfade nicht auf unsere Konfiguration zurückzuführen ist. Dieses Szenario weist auf ein Problem mit der Azure-Plattform hin. Im seltenen Fall eines Plattformproblems, wird eine automatisierte Warnung an unser Team gesendet, um alle Plattformprobleme schnell zu beheben.

Diagnose bei Integritätstestfehlern

Angenommen, wir überprüfen den Integritätsteststatus und finden heraus, dass alle Instanzen als fehlerhaft angezeigt werden. Da kein Datenverkehr übermittelt werden kann, ist dieser Status also der Grund dafür, dass der Datenpfad nicht verfügbar ist. In diesem Fall sollten Sie mithilfe der folgenden Checkliste gängige Konfigurationsfehler ausschließen:

  • Überprüfen Sie die CPU-Auslastung Ihrer Ressourcen, um zu ermitteln, ob sie unter hoher Last stehen.
  • Überprüfen Sie bei Verwendung eines HTTP- oder HTTPS-Tests, ob die Anwendung fehlerfrei ausgeführt wird und reagiert.
    • Überprüfen Sie, ob die Anwendung funktioniert, indem Sie über die private IP-Adresse oder die öffentliche IP-Adresse auf Instanzebene, die Ihrer Back-End-Instanz zugeordnet ist, direkt auf die Anwendungen zu greifen.
  • Überprüfen Sie die Netzwerksicherheitsgruppen, die auf Ihre Back-End-Ressourcen angewendet werden. Stellen Sie sicher, dass keine Regeln mit höherer Priorität als AllowAzureLoadBalancerInBound konfiguriert sind, die den Integritätstest blockieren.
    • Sie können dies auf dem Blatt „Netzwerkeinstellungen“ Ihrer Back-End-VMs oder VIrtual Machine Scale Sets überprüfen.
    • Wenn dieses NSG-Problem vorliegt, verschieben Sie die vorhandene Zulassungsregel, oder erstellen Sie eine neue Regel mit hoher Priorität, um Azure Load Balancer-Datenverkehr zuzulassen.
  • Überprüfen Sie Ihr Betriebssystem. Stellen Sie sicher, dass Ihre VMs am Testport lauschen, und überprüfen Sie die zugehörigen Firewallregeln des Betriebssystems, um sicherzustellen, dass der Testdatenverkehr von der IP-Adresse 168.63.129.16 nicht blockiert wird.
    • Sie können Überwachungsports überprüfen, indem Sie netstat -a über eine Windows-Eingabeaufforderung oder netstat -l an einem Linux-Terminal ausführen.
  • Stellen Sie sicher, dass Sie das richtige Protokoll verwenden. Beispielsweise führt ein Test per HTTP, ob ein Port auf eine Nicht-HTTP-Anwendung lauscht, zu einem Fehler.
  • Azure Firewall sollte nicht im Back-End-Pool von Lastenausgleichsmodulen platziert werden. Um Azure Firewall in ihren Lastenausgleich zu integrieren, lesen Sie den Artikel Integrieren von Azure Firewall mit Azure Load Balancer Standard.

Wenn Sie diese Checkliste durchgearbeitet haben und weiterhin Integritätstestfehler auftreten, kann ein seltenes Plattformproblem vorliegen, das den Testdienst für Ihre Instanzen beeinträchtigt. In diesem Fall wird eine automatisierte Warnung an unser Team gesendet, um jegliche Plattformprobleme schnellstmöglich zu behandeln.

Nächste Schritte