Freigeben über

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

  • Artikel

Dieser Artikel kann Ihnen helfen, Probleme zu untersuchen, die sich auf die Verfügbarkeit der Front-End-IP-Adresse und Back-End-Ressourcen Ihres Lastenausgleichs auswirken.

Sie können das Feature Ressourcenintegrität für Azure Load Balancer verwenden, um den Zustand Ihres Lastenausgleichs zu ermitteln. Es analysiert die Metrik der Datenpfadverfügbarkeit, um zu bestimmen, ob die Endpunkte des Lastenausgleichs, die Kombination aus Front-End-IP-Adresse und Front-End-Port mit Lastenausgleichsregeln, verfügbar sind.

Hinweis

Basic Load Balancer unterstützt das Feature der Ressourcenintegrität nicht.

In der folgenden Tabelle wird die zum Ermitteln des Integritätszustands des Lastenausgleichs verwendete Logik beschrieben.

Ressourcenintegritätsstatus BESCHREIBUNG
Verfügbar Ihre Lastenausgleichsressource ist fehlerfrei und verfügbar.
Beeinträchtigt Für Ihren Lastenausgleich 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. Möglicherweise kommt es zu einer moderaten bis schwerwiegenden Leistungsbeeinträchtigung.
Nicht verfügbar Ihre Lastenausgleichsressource ist nicht fehlerfrei. Die Metrik für die Datenpfadverfügbarkeit hat mindestens zwei Minuten lang einen Integritätswert von weniger als 25 % gemeldet. Möglicherweise kommt es zu einer erheblichen Leistungsbeeinträchtigung oder zu einer mangelnden Verfügbarkeit für eingehende Verbindungen. Benutzer- oder Plattformereignisse verursachen möglicherweise eine Nichtverfügbarkeit.
Unbekannt Der Integritätsstatus Ihrer Lastenausgleichsressource wurde noch nicht aktualisiert oder hat in den letzten 10 Minuten keine Informationen zur Datenpfadverfügbarkeit empfangen. Dieser Zustand kann vorübergehend sein, oder Ihr Lastenausgleich unterstützt möglicherweise das Feature für die Ressourcenintegrität nicht.

Überwachen der Verfügbarkeit des Lastenausgleichs

Die beiden Metriken, die Azure Load Balancer zum Überprüfen der Ressourcenintegrität verwendet, sind Datenpfadverfügbarkeit und Integritätsteststatus. Es ist wichtig, ihre Bedeutung zu verstehen, um korrekte Erkenntnisse abzuleiten.

Data Path Availability (Verfügbarkeit des Datenpfads)

Ein TCP-Ping generiert die Datenpfadverfügbarkeitsmetrik alle 25 Sekunden auf allen Front-End-Ports, auf denen Sie Lastenausgleichsregeln konfiguriert haben. Dieser TCP-Ping wird an alle fehlerfreien (als verfügbar getesteten) Back-End-Instanzen weitergeleitet. Die Metrik ist eine aggregierte prozentuale Erfolgsrate von TCP-Pings für jede Front-End-IP:Port-Kombination für jede Ihrer Lastenausgleichsregeln über einen Beispielzeitraum.

Health Probe Status (Status des Integritätstests)

Ein Ping des Protokolls, das im Integritätstest definiert ist, generiert die Metrik „Integritätsteststatus“. Dieser Ping wird an jede Instanz im Back-End-Pool sowie an dem im Integritätstest definierten Port gesendet. Für HTTP- und HTTPS-Tests erfordert ein erfolgreicher Ping eine HTTP 200 OK-Antwort. Bei TCP-Tests wird jede Antwort als erfolgreich betrachtet.

Azure Load Balancer bestimmt den Integritätsstatus jeder Back-End-Instanz, wenn der Test die Anzahl aufeinanderfolgender Erfolge oder Fehler erreicht, die Sie als Schwellenwerteigenschaft des Tests konfiguriert haben. Der Integritätsstatus jeder Back-End-Instanz bestimmt, ob die Back-End-Instanz Datenverkehr empfangen darf.

Ähnlich wie die Metrik „Datenpfadverfügbarkeit“ aggregiert die Metrik „Integritätsteststatus“ die durchschnittlichen erfolgreichen und Gesamtpings während des Samplingintervalls. Der Wert des Integritätsteststatus zeigt die Back-End-Integrität isoliert von Ihrem Lastenausgleichsmodul an, indem Ihre Back-End-Instanzen getestet werden, ohne Datenverkehr über das Front-End zu senden.

Wichtig

Das Zeitfenster für die Ermittlung des Integritätsteststatus beträgt eine Minute. Dieses Sampling kann es bei einem ansonsten konstanten Wert zu geringfügigen Schwankungen kommen.

Betrachten Sie z. B. aktive/passive Szenarien, in denen zwei Back-End-Instanzen vorhanden sind, eine aktiv (probed up) und eine passiv (probed down). Der Integritätsprüfdienst erfasst möglicherweise sieben Samples für fehlerfreie Instanzen und sechs für fehlerhafte Instanzen. Diese Situation führt dazu, dass ein zuvor konstanter Wert von 50 für ein einminütiges Intervall als 46,15 angezeigt wird.

Diagnose bei beeinträchtigten und nicht verfügbaren Lastenausgleichsmodulen

Wie in diesem Artikel zur Ressourcenintegrität beschrieben, zeigt ein herabgestufter Lastenausgleich zwischen 25 % und 90 % als Datenpfadverfügbarkeit an. Ein nicht verfügbarer Lastenausgleich ist einer mit weniger als 25 % Datenpfadverfügbarkeit über einen Zeitraum von zwei Minuten.

Sie können die gleichen Schritte verwenden, um Fehler zu untersuchen, die in Ihren konfigurierten Warnungen zum Integritätsteststatus oder zur Datenpfadverfügbarkeit angezeigt werden. In den folgenden Schritten erfahren Sie, was Sie tun müssen, wenn Sie den Ressourcenstatus überprüfen und feststellen, dass ihr Lastenausgleich mit einem Datenpfadverfügbarkeitswert von 0 % nicht verfügbar ist. Ihr Dienst ist nicht verfügbar.

  1. Wechseln Sie im Azure-Portal zur detaillierten Metrikansicht der Seite für die Einblicke in Ihren Lastenausgleich. Diese Ansicht erreichen Sie über die Seite „Ressourcen“ des Lastenausgleichs oder über den Link in der Nachricht zur Ressourcenintegrität.

  2. Gehen Sie 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 der Datenpfadverfügbarkeitswert 0 % ist, wissen Sie, dass etwas den Datenverkehr für alle Ihre Lastenausgleichsregeln verhindert. Sie können auch sehen, wie lange dieses Problem angehalten hat.

  3. Überprüfen Sie die Metrik Integritätsteststatus, um zu ermitteln, ob Ihr Datenpfad nicht verfügbar ist, da sie keine fehlerfreien Back-End-Instanzen haben, um den Datenverkehr zu bedienen. Wenn Sie mindestens eine fehlerfreie Back-End-Instanz für alle Ihre Lastenausgleichs- und eingehenden Regeln haben, wissen Sie, dass Ihre Konfiguration nicht dazu führt, dass Ihre Datenpfade nicht verfügbar sind. Dieses Szenario weist auf ein Problem mit der Azure-Plattform hin. Obwohl Plattformprobleme selten sind, lösen sie eine automatisierte Warnung an unser Team aus, um eine schnelle Lösung zu erhalten.

Diagnose bei Integritätstestfehlern

Wenn die Metrik „Integritätsteststatus“ anzeigt, dass Ihre Back-End-Instanzen nicht fehlerfrei sind, empfehlen wir, die folgende Checkliste zu verwenden, um häufige Konfigurationsfehler auszuschließen:

  • Überprüfen Sie die CPU-Auslastung Ihrer Ressourcen, um zu ermitteln, ob sie unter hoher Last stehen.

    Sie können es überprüfen, indem Sie die CPU-Metrik zur Prozentangabe der Ressource auf der Seite Metriken anzeigen. Weitere Informationen finden Sie unter Problembehandlung bei hoher CPU-Auslastung bei virtuellen Azure-Windows-Computern.

  • Überprüfen Sie, wenn sie HTTP- oder HTTPS-Tests verwenden, ob die Anwendung fehlerfrei ausgeführt wird und reagiert.

    Überprüfen Sie, ob Ihre 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 (NSGs), die auf Ihre Back-End-Ressourcen angewendet werden. Stellen Sie sicher, dass keine Regeln, die den Integritätstest blockieren, eine höhere Priorität haben als AllowAzureLoadBalancerInBound.

    Sie können diese Aufgabe in den „Netzwerkeinstellungen“ Ihrer Back-End-VMs oder VM-Skalierungsgruppen überprüfen. Wenn dieses NSG-Problem vorliegt, verschieben Sie die vorhandene Allow-Regel, oder erstellen Sie eine neue Regel mit hoher Priorität, um Datenverkehr des Azure Load Balancer zuzulassen.

  • Überprüfen Sie Ihr Betriebssystem. Stellen Sie sicher, dass Ihre virtuellen Computer auf dem Testport lauschen. Überprüfen Sie außerdem die Betriebssystemfirewallregeln für die virtuellen Computer, um sicherzustellen, dass sie den Testdatenverkehr nicht blockieren, der von der IP-Adresse 168.63.129.16 stammt.

    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. Ein Test, der HTTP verwendet, um einen Port zu testen, der auf eine Nicht-HTTP-Anwendung lauscht, schlägt beispielsweise fehl.

  • Platzieren Sie die Azure Firewall nicht im Back-End-Pool von Lastenausgleichsmodulen. Weitere Informationen zur Einrichtung finden Sie unter Integrieren von Azure Firewall mit Azure Load Balancer Standard.

Zugehöriger Inhalt