Übersicht der Application Gateway-Integritätstests
Das Azure Application Gateway überwacht den Status aller Server im Back-End-Pool und beendet automatisch das Senden des Datenverkehrs an jeden Server, den für es als nicht integer gilt. Die Tests überwachen weiterhin einen solchen fehlerhaften Server, und das Gateway leitet an ihn den Datenverkehr wieder weiter, sobald die Tests ihn als fehlerfrei erkennen.
Der Standardtest verwendet die Portnummer aus der zugehörigen Back-End-Einstellung und anderen voreingestellten Konfigurationen. Sie können benutzerdefinierte Test verwenden, um sie auf Ihre Weise zu konfigurieren.
Testverhalten
Quell-IP-Adresse
Die Quelle-IP-Adresse des Tests hängt vom Back-End-Servertyp ab:
- Wenn die Server im Back-End-Pool ein öffentlicher Endpunkt ist, ist die Quelladresse die öffentliche IP-Adresse Ihres Application Gateway-Front-Ends.
- Wenn der Server im Back-End-Pool ein privater Endpunkt ist, wird die Quell-IP-Adresse aus dem Adressbereich Ihres Application Gateway-Subnetzes stammen.
Testvorgänge
Ein Gateway startet das Auslösen des Tests unmittelbar nach der Konfiguration einer Regel, indem er einer Back-End-Einstellung und einem Back-End-Pool (und natürlich dem Listener) zugeordnet wird. Die Abbildung zeigt, dass das Gateway unabhängig alle Back-End-Poolservern testet. Die eingehenden Anforderungen, die mit der Ankunft beginnen, werden nur an die fehlerfreien Server gesendet. Ein Back-End-Server ist standardmäßig als fehlerhaft gekennzeichnet, bis eine erfolgreiche Testantwort empfangen ist.
Die erforderlichen Tests werden basierend auf der eindeutigen Kombination der Back-End-Server- und Back-End-Einstellung bestimmt. Ziehen Sie z. B. ein Gateway mit einem einzelnen Back-End-Pool mit zwei Servern und zwei Back-End-Einstellungen in Betracht, wobei sie unterschiedliche Portnummern haben. Wenn diese eindeutigen Back-End-Einstellungen demselben Back-End-Pool mit ihren jeweiligen Regeln zugeordnet sind, erstellt das Gateway Tests für jeden Server und die Kombination der Back-End-Einstellung. Sie können dies auf der Back-End-Integritätsseiteanzeigen lassen.
Darüber hinaus untersuchen alle Instanzen des Anwendungsgateways die Back-End-Server unabhängig voneinander.
Testintervalle
Für jede Instanz Ihres Application Gateways gilt die gleiche Testkonfiguration. Wenn beispielsweise ein Anwendungsgateway zwei Instanzen aufweist und das Testintervall auf 20 Sekunden festgelegt ist, senden beide Instanzen den Integritätstest alle 20 Sekunden.
Sobald der Test eine fehlgeschlagene Antwort erkennt, wird der Indikator für "Unhealthy threshold" deaktiviert und kennzeichnet den Server als fehlerhaft, wenn die aufeinanderfolgende Fehleranzahl mit dem konfigurierten Schwellenwert übereinstimmt. Wenn Sie also diesen "Unhealthy Threshold" als 2 festlegen, erkennt der nachfolgende Test zunächst diesen Fehler. Das Anwendungsgateway markiert den Server dann nach 2 aufeinander folgenden fehlgeschlagenen Test als fehlerhaft [Erste Erkennung 20 Sek. + (2 aufeinander folgende fehlgeschlagene Tests * 20 Sek.)].
Hinweis
Der Back-End-Integritätsbericht wird basierend auf dem Aktualisierungsintervall des jeweiligen Tests aktualisiert und hängt nicht von der Anforderung des Benutzers ab.
Standardmäßige Integritätsüberprüfung
Ein Anwendungsgateway konfiguriert automatisch eine standardmäßige Integritätsüberprüfung, wenn Sie keine benutzerdefinierte Überprüfungskonfiguration einrichten. Das Verhalten der Überwachung funktioniert durch Ausgeben einer HTTP GET-Anforderung an die für den Back-End-Pool konfigurierten IP-Adressen oder vollqualifizierten Domänennamen. Bei Standardtests wird HTTPS für den Integritätstest der Back-Ends verwendet, wenn die HTTP-Einstellungen des Back-Ends für HTTPS konfiguriert sind.
Beispiel: Sie konfigurieren Ihr Application Gateway für die Verwendung der Back-End-Server A, B und C zum Empfang von HTTP-Netzwerkdatenverkehr an Port 80. Die standardmäßige Integritätsüberwachung testet die drei Server alle 30 Sekunden auf eine fehlerfreie HTTP-Antwort, wobei jede Anforderung einen Timeout von 30 Sekunden besitzt. Eine fehlerfreie HTTP-Antwort weist einen Statuscode zwischen 200 und 399 auf. In diesem Fall sieht die HTTP GET-Anforderung für den Integritätstest wie http://127.0.0.1/ aus. Siehe auch HTTP-Antwortcodes im Application Gateway
Wenn die Standardüberprüfung für Server A zu einem Fehler führt, beendet Application Gateway die Weiterleitung von Anforderungen an diesen Server. Die Standardüberprüfung führt weiterhin alle 30 Sekunden eine Überprüfung für Server A aus. Wenn Server A erfolgreich auf eine Anforderung eines Standardintegritätstests antwortet, werden die Anforderungen von Application Gateway wieder an den Server weitergeleitet.
Einstellungen für die standardmäßige Integritätsüberprüfung
| Überprüfungseigenschaft | Wert | Beschreibung |
|---|---|---|
| Überprüfungs-URL | <Protokoll>://127.0.0.1:<Port>/ | Das Protokoll und der Port werden von den Back-End-HTTP-Einstellungen geerbt, denen der Test zugeordnet ist. |
| Intervall | 30 | Wartezeitraum in Sekunden, bevor der nächste Integritätstest gesendet wird. |
| Zeitüberschreitung | 30 | Gibt in Sekunden an, wie lange das Anwendungsgateway auf eine Testantwort wartet, bevor der Test als fehlerhaft gekennzeichnet wird. Wenn ein Test als fehlerfrei zurückgegeben wird, wird das entsprechende Back-End sofort als fehlerfrei gekennzeichnet. |
| Fehlerhafter Schwellenwert | 3 | Steuert, wie viele Tests gesendet werden sollen, falls beim regulären Integritätstest ein Fehler auftritt. In der v1-SKU werden diese zusätzlichen Integritätstests in kurzen Abständen gesendet, um die Back-End-Integrität schnell zu ermitteln und nicht auf das Testintervall zu warten. Für v2-SKU warten die Integritätstests auf das Intervall. Der Back-End-Server wird als ausgefallen markiert, nachdem die Anzahl der aufeinanderfolgenden fehlerhaften Tests den Fehlerschwellenwert erreicht. |
Der Standardtest untersucht nur <Protokoll>://127.0.0.1:<Port>, um den Integritätsstatus zu bestimmen. Wenn Sie die Integritätsüberprüfung für eine benutzerdefinierte URL konfigurieren oder andere Einstellungen ändern möchten, müssen Sie benutzerdefinierte Überprüfungen verwenden. Weitere Informationen zu HTTPS-Tests finden Sie unter Übersicht über TLS-Beendigung und End-to-End-TLS mit Application Gateway.
Benutzerdefinierte Integritätsüberprüfung
Benutzerdefinierte Überprüfungen ermöglichen Ihnen eine präzisere Kontrolle über die Überwachung des Systemzustands. Bei Verwendung von benutzerdefinierten Überprüfungen können Sie u. a. einen benutzerdefinierten Hostnamen, den URL-Pfad, das Testintervall und die Anzahl fehlerhafter Antworten konfigurieren, die akzeptiert werden, bevor die Back-End-Pool-Instanz als fehlerhaft gekennzeichnet wird.
Einstellungen für die benutzerdefinierte Integritätsüberprüfung
Die folgende Tabelle enthält Definitionen der Eigenschaften eines benutzerdefinierten Integritätstests.
| Überprüfungseigenschaft | Beschreibung |
|---|---|
| Name | Name der Überprüfung. Dieser Name wird verwendet, um den Test zu identifizieren und in den Back-End-HTTP-Einstellungen darauf zu verweisen. |
| Protokoll | Das zum Senden der Überprüfung verwendete Protokoll. Dieses muss mit dem Protokoll identisch sein, das in den HTTP-Einstellungen für das Back-End definiert ist, dem es zugeordnet ist |
| Host | Der Hostname, unter dem der Test gesendet wird. In der v1-SKU wird dieser Wert nur für den Hostheader der Testanforderung verwendet. In der v2-SKU wird er sowohl als Hostheader als auch als SNI verwendet. |
| `Path` | Relativer Pfad der Überprüfung. Ein gültiger Pfad beginnt mit „/“. |
| Port | Wenn dieser definiert ist, wird er als Zielport verwendet. Andernfalls wird der in den zugeordneten HTTP-Einstellungen angegebene Port verwendet. Diese Eigenschaft ist nur in der v2-SKU verfügbar. |
| Intervall | Überprüfungsintervall in Sekunden Dieser Wert ist das Zeitintervall zwischen zwei aufeinander folgenden Tests. |
| Zeitüberschreitung | Zeitüberschreitung der Überprüfung in Sekunden. Der Test wird als fehlerhaft markiert, wenn innerhalb des Zeitraums für den Timeout keine gültige Antwort empfangen wird. |
| Fehlerhafter Schwellenwert | Anzahl der Wiederholungsversuche der Überprüfung Der Back-End-Server wird als ausgefallen markiert, nachdem die Anzahl der aufeinanderfolgenden fehlerhaften Tests den Fehlerschwellenwert erreicht. |
Testabgleich
Standardmäßig gilt eine HTTP(S)-Antwort mit einem Statuscode zwischen 200 und 399 als fehlerfrei. Benutzerdefinierte Integritätstests unterstützen außerdem zwei Abgleichskriterien. Abgleichskriterien können verwendet werden, um optional die Standardinterpretation einer fehlerfreien Antwort zu ändern.
Abgleichskriterien:
- Abgleich des Statuscodes der HTTP-Antwort: Testabgleichskriterium zum Akzeptieren der vom Benutzer angegebenen HTTP-Antwortcodes oder -Antwortcodebereiche. Einzelne kommagetrennte Antwortstatuscodes und ein Bereich von Statuscodes werden unterstützt.
- Abgleich des HTTP-Antworttexts: Testabgleichskriterium, das den HTTP-Antworttext heranzieht und ihn mit einer vom Benutzer angegebenen Zeichenfolge abgleicht. Beim Abgleich wird lediglich auf das Vorhandensein der vom Benutzer angegebenen Zeichenfolge im Antworttext geachtet. Es findet kein Abgleich mit einem vollständigen regulären Ausdruck statt. Die angegebene Übereinstimmung muss maximal 4090 Zeichen lang sein.
Abgleichskriterien können mithilfe des Cmdlets New-AzApplicationGatewayProbeHealthResponseMatch angegeben werden.
Beispiel:
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Übereinstimmungskriterien können an die Testkonfiguration mithilfe eines -Match Operators in PowerShell angefügt werden.
Einige Anwendungsfälle für benutzerdefinierte Tests
- Wenn ein Back-End-Server nur authentifizierten Benutzern den Zugriff gewährt, erhalten die Anwendungsgateway-Probes anstelle von 200 einen 403 Antwortcode. Da die Clients (Benutzer) sich selbst für den Live-authentifizieren müssen, können Sie den Testverkehr so konfigurieren, dass er 403 als erwartete Antwort akzeptiert.
- Wenn ein Back-End-Server ein Wildcardzertifikat (*.contoso.com) installiert hat, um verschiedene Unterdomänen zu bedienen, können Sie einen benutzerdefinierten Test mit einem bestimmten Hostnamen (erforderlich für SNI) verwenden, der akzeptiert wird, um einen erfolgreichen TLS-Test einzurichten und diesen Server als fehlerfrei zu melden. Wenn "Hostname außer Kraft setzen" in der Back-End-Einstellung auf "NO" gesetzt ist, werden die verschiedenen eingehenden Hostnamen (Subdomänen) unverändert an das Back-End übergeben.
NSG-Aspekte
Feinkornkontrolle über das Application Gateway-Subnetz über NSG-Regeln ist in der öffentlichen Vorschau möglich. Weitere Informationen finden Sie hier.
Mit der aktuellen Funktionalität gibt es einige Einschränkungen:
Sie müssen eingehenden Internetdatenverkehr über die TCP-Ports 65503–65534 (für die Application Gateway v1-SKU) und über die TCP-Ports 65200–65535 (für die v2-SKU) mit dem Zielsubnetz Beliebig und der Quelle GatewayManager-Diensttag zulassen. Dieser Portbereich ist für die Kommunikation mit der Azure-Infrastruktur erforderlich.
Außerdem kann die Internetkonnektivität in ausgehender Richtung nicht blockiert werden, und eingehender Datenverkehr vom AzureLoadBalancer-Tag muss zugelassen werden.
Weitere Informationen finden Sie unter Application Gateway-Konfiguration: Übersicht.
Nächste Schritte
Nachdem Sie sich mit der Systemüberwachung von Application Gateway vertraut gemacht haben, können Sie einen benutzerdefinierten Integritätstest im Azure-Portal oder einen benutzerdefinierten Integritätstest mit PowerShell und dem Azure Resource Manager-Bereitstellungsmodell konfigurieren.