Freigeben über

Azure Load Balancer-Integritätstests

  • Artikel

Ein Azure Load Balancer-Integritätstest ist ein Feature, das den Integritätsstatus Ihrer Anwendungsinstanzen erkennt. Ere sendet eine Anforderung an die Instanzen, um zu überprüfen, ob sie verfügbar sind und auf Anforderungen reagieren. Die Integritätssonde kann so konfiguriert werden, dass unterschiedliche Protokolle wie TCP, HTTP oder HTTPS verwendet werden. Es ist ein wichtiges Feature, da es Ihnen hilft, Anwendungsfehler zu erkennen, Last zu verwalten und Ausfallzeiten zu planen.

Azure Load Balancer-Regeln erfordern einen Integritätstest, um den Endpunktstatus zu erkennen. Die Konfiguration des Integritätstests und der Testantworten bestimmt, welche Backend-Pool-Instanzen neue Verbindungen empfangen. Verwenden Sie Integritätstests, um den Ausfall einer Anwendung zu erkennen. Generieren Sie eine benutzerdefinierte Antwort auf einen Integritätstest. Verwenden Sie den Integritätstest zur Flusssteuerung, um die Last oder geplante Downtimes zu verwalten. Wenn ein Integritätstest fehlschlägt, beendet der Load Balancer das Senden neuer Verbindungen an die entsprechende fehlerhafte Instanz. Ausgehende Verbindungen sind nicht betroffen, nur eingehende.

Test-Protokolle

Integritätstests unterstützen mehrere Protokolle. Die Verfügbarkeit eines bestimmten Integritätstestprotokolls hängt von der Load Balancer-SKU ab. Darüber hinaus variiert das Verhalten des Diensts je nach Load Balancer-SKU. Die Tabelle zeigt dies:

Standard-SKU Basic-SKU
Testprotokoll TCP, HTTP, HTTPS TCP, HTTP
Verhalten bei Tests mit Fehlern Alle Tests mit Fehlern, alle TCP-Flows werden fortgesetzt. Alle Tests mit Fehlern, alle TCP-Flows laufen ab.

Integritätstesteigenschaften

Integritätstests verfügen über die folgenden Eigenschaften:

Name der Integritätstesteigenschaft Details
Name Name des Integritätstests. Dies ist ein Name, den Sie für Ihren Integritätstest definieren können
Protocol Protokoll des Integritätstests. Dies ist der Protokolltyp, den Sie für den Integritätstest nutzen möchten. Optionen sind: TCP, HTTP, HTTPS
Port Port des Integritätstests. Der Zielport, den der Integritätstest verwenden soll, wenn er eine Verbindung mit dem virtuellen Computer herstellt, um dessen Integrität zu überprüfen
Intervall (Sekunden) Intervall des Integritätstests. Die Zeitspanne (in Sekunden) zwischen zwei aufeinanderfolgenden Integritätstestversuchen auf dem virtuellen Computer
Verwendet von Die Liste der Lastenausgleichsregeln, die diesen spezifischen Integritätstest verwenden. Mindestens eine Regel sollte den Integritätstest verwenden, damit sie wirksam ist

Testkonfiguration

Die Integritätstestkonfiguration umfasst folgende Elemente:

Konfiguration des Integritätstests Details
Protocol Protokoll des Integritätstests. Dies ist der Protokolltyp, den Sie für den Integritätstest nutzen möchten. Verfügbare Optionen sind: TCP, HTTP, HTTPS
Port Port des Integritätstests. Der Zielport, den der Integritätstest verwenden soll, wenn er eine Verbindung mit dem virtuellen Computer herstellt, um den Integritätsstatus des virtuellen Computers zu überprüfen. Sie müssen sicherstellen, dass der virtuelle Computer auch an diesem Port lauscht (d. h. der Port ist geöffnet).
Intervall Intervall des Integritätstests. Die Zeitspanne (in Sekunden) zwischen aufeinanderfolgenden Integritätstestversuchen für die VM

Testprotokoll

Das vom Integritätstest verwendete Protokoll kann für eine der folgenden Optionen konfiguriert werden: TCP, HTTP, HTTPS.

Szenario TCP-Test HTTP-/HTTPS-Test
Übersicht TCP-Tests leiten eine Verbindung über einen offenen Drei-Wege-TCP-Handshake mit dem definierten Port ein. TCP-Tests beenden eine Verbindung mit einem Vier-Wege-TCP-Schließen-Handshake. HTTP und HTTP geben eine HTTP GET mit dem angegebenen Pfad aus. Diese beiden Tests unterstützen für HTTP GET relative Pfade. HTTPS-Tests sind mit HTTP-Tests identisch, weisen jedoch zusätzlich Transport Layer Security (TLS) auf. HTTP/HTTPS-Tests eignen sich zum Implementieren Ihrer eigenen Logik, um Instanzen aus dem Lastenausgleich zu entfernen, wenn der Testport auch der Listener für den Dienst ist.
Verhalten bei Testfehlern Ein TCP-Test schlägt fehl, wenn: 1. Der TCP-Listener für die Instanz reagiert innerhalb des Zeitlimits gar nicht. Wann der Test als nicht ausgeführt markiert wird, hängt von der konfigurierten Anzahl unbeantworteter Testanforderungen aufgrund eines Timeouts vor dem Markieren des Tests als nicht ausgeführt ab. 2. Der Test empfängt ein TCP-Reset von der Instanz. Ein HTTP/HTTPS-Test schlägt fehl, wenn: 1. Der Testendpunkt gibt einen anderen HTTP-Antwortcode als 200 zurück (z.B. 403, 404 oder 500). 2. Der HTTP-Testendpunkt reagiert während des kleineren Zeitraums des Testintervalls und eines Zeitlimits von 30 Sekunden gar nicht. Möglicherweise bleiben mehrere Testanforderungen unbeantwortet, bevor der Test als nicht ausgeführt markiert wird und die Summe aller Timeoutintervalle erreicht wurde. 3. Der Testendpunkt schließt die Verbindung über ein TCP-Reset.
Verhalten bei erfolgreichen Tests TCP-Integritätstests werden in den folgenden Fällen als fehlerfrei eingestuft und markieren den Back-End-Endpunkt als fehlerfrei, wenn: 1. Der Integritätstest ist nach dem Starten der VM erfolgreich. 2. Jeder Back-End-Endpunkt, der einen fehlerfreien Zustand erreicht hat, ist berechtigt, neue Streams zu empfangen. Der Integritätstest kennzeichnet die Instanz als online, wenn diese innerhalb des Zeitlimits mit dem HTTP-Statuscode 200 antwortet. HTTP/HTTPS-Integritätstests werden in den folgenden Fällen als fehlerfrei eingestuft und markieren den Back-End-Endpunkt als fehlerfrei, wenn: 1. Der Integritätstest ist nach dem Starten der VM erfolgreich. 2. Jeder Back-End-Endpunkt, der einen fehlerfreien Zustand erreicht hat, ist berechtigt, neue Streams zu empfangen.

Hinweis

Der HTTPS-Test erfordert die Verwendung von Zertifikaten mit einem minimalen Signaturhash von SHA256 in der gesamten Kette.

Verhalten bei Tests mit Fehlern

Szenario TCP-Verbindungen UDP-Datagramme
Einzelne Instanz testet als „ausgefallen“ Neue TCP-Verbindungen mit dem verbleibenden fehlerfreien Backend-Endpunkt werden erfolgreich hergestellt. Die eingerichteten TCP-Verbindungen mit diesem Back-End-Endpunkt werden fortgesetzt. Vorhandene UDP-Flows werden auf eine andere fehlerfreie Instanz im Back-End-Pool verschoben.
Alle Instanzen testen als „ausgefallen“ Es werden keine neuen Flows an den Back-End-Pool gesendet. Load Balancer Standard lässt die Fortsetzung etablierter TCP-Flows zu, wenn ein Backend-Pool über mehr als eine Backend-Instanz verfügt. Load Balancer Basic beendet alle vorhandenen TCP-Flows an den Backend-Pool. Alle vorhandenen UDP-Flows werden beendet.

Intervall und Timeout für Integritätstests

Der Intervallwert bestimmt, wie häufig der Integritätstest eine Überprüfung auf eine Antwort von Ihren Backend-Pool-Instanzen durchführt. Wenn der Integritätstest fehlschlägt, werden Ihre Backend-Pool-Instanzen sofort als „Fehlerhaft“ gekennzeichnet. Wenn der Integritätstest beim nächsten fehlerfreien Test als „ausgeführt“ zurückgegeben wird, markiert Azure Load Balancer Ihre Back-End-Poolinstanzen als fehlerfrei. Der Integritätstest überprüft den konfigurierten Port des Integritätstests standardmäßig alle 5 Sekunden im Azure-Portal. Dieser Wert kann jedoch auch explizit auf einen anderen Wert gesetzt werden.

Um sicherzustellen, dass rechtzeitig eine Antwort empfangen wird, gelten für HTTP/S-Integritätstests integrierte Timeouts. Im Folgenden finden Sie die Timeoutdauer für TCP- und HTTP/S-Tests:

  • Timeoutdauer des TCP-Tests: N/V (Tests schlagen fehl, sobald die konfigurierte Intervalldauer des Tests abgelaufen ist und der nächste Test gesendet wurde)
  • Timeoutdauer des TCP-Tests: 30 Sekunden

Wenn das konfigurierte Intervall für HTTP/S-Tests länger als der oben genannte Timeoutzeitraum ist, treten für den Integritätstest ein Timeout und ein Fehler auf, wenn während des Timeoutzeitraums keine Antwort empfangen wird. Wenn beispielsweise ein HTTP-Integritätstest mit einem Testintervall von 120 Sekunden (alle 2 Minuten) konfiguriert ist und innerhalb der ersten 30 Sekunden keine Testantwort empfangen wird, hat der Test seinen Timeoutzeitraum erreicht und schlägt fehl. Wenn das konfigurierte Intervall kürzer ist als die obige Timeout-Periode, schlägt die Integritätsprüfung fehl, wenn vor Ablauf der konfigurierten Intervall-Periode keine Antwort empfangen wird, und die nächste Prüfung wird sofort gesendet.

Entwurfsleitfäden

  • Beim Entwerfen des Integritätsmodells für Ihre Anwendung sollten Sie einen Port eines Back-End-Endpunkts testen, der die Integrität dieser Instanz und des Anwendungsdiensts widerspiegelt. Der Anwendungsport und der Testport müssen nicht identisch sein. In einigen Szenarien kann es wünschenswert sein, dass sich der Testport von dem Port unterscheidet, den Ihre Anwendung verwendet. Im Allgemeinen wird jedoch empfohlen, dass es sich dabei um denselben Port handelt.

  • Es kann für Ihre Anwendung nützlich sein, eine Integritätstestantwort zu erzeugen und dem Lastenausgleich zu signalisieren, ob Ihre Instanz neue Verbindungen erhalten sollte. Sie können die Testantwort manipulieren, um die Bereitstellung neuer Verbindungen für eine Instanz zu drosseln, indem Sie den Integritätstest fehlschlagen lassen. Sie können sich auf die Wartung Ihrer Anwendung vorbereiten und das Entladen von Verbindungen mit Ihrer Anwendung einleiten. TCP-Flows können bei einem Signal vom Typ Test mit Fehlern immer fortgesetzt werden, bis das Leerlauf-Timeout erreicht oder die Verbindung in einem Load Balancer Standard geschlossen wird.

  • Generieren Sie für eine UDP-Anwendung mit Lastenausgleich ein benutzerdefiniertes Integritätstestsignal vom Back-End-Endpunkt. Verwenden Sie entweder TCP, HTTP oder HTTPS für den Integritätstest, der dem jeweiligen Listener entspricht.

  • Lastenausgleichsregel für Hochverfügbarkeitsports mit Load Balancer Standard. Für alle Ports wird ein Lastenausgleich ausgeführt, und eine einzelne Integritätstestantwort muss den Status der gesamten Instanz widerspiegeln.

  • Übersetzen Sie einen Integritätstest nicht bzw. leiten Sie einen Integritätstest nicht per Proxy über die Instanz, die den Integritätstest empfängt, an eine andere Instanz in Ihrem virtuellen Netzwerk weiter. Diese Konfiguration kann zu Fehlern in Ihrem Szenario führen. Ein Beispiel: Verschiedene Appliances von Drittanbietern werden im Back-End-Pool eines Lastausgleichs bereitgestellt, um Skalierbarkeit und Redundanz für die Appliances zu gewährleisten. Der Integritätstest ist so konfiguriert, dass er einen Port testet, den die Drittanbieterappliances per Proxy an andere VMs hinter der Appliance weiterleitet oder in diese übersetzt. Wenn Sie denselben Port testen, den Sie verwenden, um Anforderungen zu übersetzen oder per Proxy an andere virtuelle Computer hinter der Appliance weiterzuleiten, wird die Appliance durch jede Testantwort von einem einzelnen virtuellen Computer hinter der Appliance als ausgefallen markiert. Diese Konfiguration kann zu einem kaskadierenden Fehler der Anwendung führen. Der Trigger kann ein zeitweiliger Testfehler sein, der dazu führt, dass der Load Balancer die Instanz der Appliance als ausgefallen markiert. Hierdurch kann Ihre Anwendung deaktiviert werden. Testen Sie stattdessen die Integrität der Anwendung selbst. Die Auswahl des Tests zum Bestimmen des Integritätssignals ist ein wichtiger Aspekt in Szenarien mit virtuellen Netzwerkgeräten (Network Virtual Appliances, NVA). Erkundigen Sie sich bei Ihrem Anwendungsanbieter nach dem geeigneten Integritätssignal für solche Szenarien.

  • Wenn Sie mehrere Schnittstellen für die VM konfiguriert haben, müssen Sie sicherstellen, dass auf den Test über die Schnittstelle geantwortet wird, über die er empfangen wurde. Möglicherweise müssen Sie diese Adresse auf der VM oder für jede Schnittstelle einzeln mittels Übersetzung der Quellnetzwerkadresse übersetzen.

  • Beachten Sie, dass eine Testdefinition nicht zwingend erforderlich ist oder überprüft wird, wenn Sie Azure PowerShell, Azure CLI, Vorlagen oder API verwenden. Validierungstests werden nur bei Verwendung des Azure-Portals durchgeführt.

  • Wenn das Ergebnis des Integritätstests schwankt, wartet der Lastenausgleich länger, bevor der Back-End-Endpunkt erneut in den fehlerfreien Zustand versetzt wird. Diese zusätzliche Wartezeit schützt den Benutzer und die Infrastruktur und ist eine bewusste Richtlinie.

  • Stellen Sie sicher, dass Ihre VM-Instanzen ausgeführt werden. Für jede ausgeführte Instanz im Back-End-Pool überprüft die Integritätsprüfung auf Verfügbarkeit. Wenn eine Instanz beendet wird, wird sie erst wieder getestet, nachdem sie neu gestartet wurde.

  • Konfigurieren Sie Ihr virtuelles Netzwerk nicht mit dem für Microsoft reservierten IP-Adressbereich, der die Adresse 168.63.129.16 enthält. Diese Konfiguration verursacht einen Konflikt mit der IP-Adresse des Integritätstests und kann dazu führen, dass Ihr Szenario fehlschlägt.

  • Um das Fehlschlagen eines Integritätstests zu testen oder eine einzelne Instanz als ausgefallen zu markieren, verwenden Sie eine Netzwerksicherheitsgruppe, um den Integritätstest explizit zu blockieren. Erstellen Sie eine NSG-Regel zum Blockieren des Zielports oder der Quell-IP-Adresse, um einen fehlerhaften Test zu simulieren.

  • Im Gegensatz zu Lastenausgleichsregeln benötigen eingehende NAT-Regeln keine an sie angefügte Integritätsprüfung.

  • Es wird nicht empfohlen, die Azure Load Balancer-Integritätsprüfungs-IP oder den Port mit NSG-Regeln zu blockieren. Dies ist ein nicht unterstütztes Szenario und kann dazu führen, dass die NSG-Regeln verzögert wirksam werden, was dazu führt, dass die Integritätssonden die Verfügbarkeit Ihrer Back-End-Instanzen ungenau darstellen.

Überwachung

Load Balancer Standard-Instanzen zeigen den Status des Integritätstests pro Endpunkt und Back-End-Endpunkt über Azure Monitor an. Andere Azure-Dienste oder Anwendungen von Partnern können diese Metriken nutzen. Azure Monitor-Protokolle werden für Basic-Load Balancer nicht unterstützt.

Quell-IP-Adresse von Tests

Damit der Azure Load Balancer-Integritätstest Ihre Instanz markieren kann, müssen Sie die IP-Adresse 168.63.129.16 in allen Azure-Netzwerksicherheitsgruppen und lokalen Firewallrichtlinien zulassen. Das Diensttag AzureLoadBalancer identifiziert diese IP-Quelladresse in Ihren Netzwerksicherheitsgruppen und lässt Datenverkehr von Integritätstests standardmäßig zu. Weitere Informationen über diese IP-Adresse finden Sie hier.

Wenn Sie die IP-Quelladresse des Tests in Ihren Firewall-Richtlinien nicht zulassen, tritt ein Fehler beim Integritätstest auf, da Ihre Instanz nicht erreicht werden kann. Daraufhin kennzeichnet der Azure Load Balancer Ihre Instanz als ausgefallen, da beim Integritätstest ein Fehler aufgetreten ist. Diese Fehlkonfiguration kann dazu führen, dass Ihr Szenario mit Lastenausgleich fehlschlägt. Bei allen IPv4-Lastenausgleichs-Integritätstests lautet die Quell-IP-Adresse 168.63.129.16. IPv6-Tests verwenden eine verbindungslokale Adresse (fe80::1234:5678:9abc) als Quelle. Für einen Azure Load Balancer mit dualem Stapel müssen Sie eine Netzwerksicherheitsgruppe konfigurieren, damit der IPv6-Integritätstest funktioniert.

Begrenzungen

  • HTTPS-Tests bieten keine Unterstützung für die gegenseitige Authentifizierung mit einem Clientzertifikat.

  • HTTP-Tests bieten keine Unterstützung für die Verwendung von Hostnamen zum Testen von Back-End-Dateien

  • Das Aktivieren von TCP-Zeitstempeln kann Drosselungs- oder andere Leistungsprobleme verursachen, was dann bei Integritätstests zu Zeitüberschreitungen führen kann.

  • Der Integritätstest eines Basic-SKU Load Balancer wird nicht mit einer VM-Skalierungsgruppe unterstützt.

  • HTTP-Tests bieten aufgrund von Sicherheitsbedenken keine Unterstützung für das Testen der folgenden Ports: 19, 21, 25, 70, 110, 119, 143, 220, 993.

Nächste Schritte