Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Das Azure Application Gateway überwacht den Zustand aller Server im Backend-Pool und stellt den Datenverkehr zu jedem Server ein, den es als nicht gesund erachtet. Die Sonden überwachen weiterhin einen solchen fehlerhaften Server, und das Gateway leitet den Datenverkehr wieder zu ihm, sobald die Sonden ihn als funktionsfähig erkennen.
Der Standardprüfer verwendet die Portnummer aus der zugehörigen Backend-Einstellung und anderen voreingestellten Konfigurationen. Sie können benutzerdefinierte Sonden verwenden, um sie nach Ihren Wünschen zu konfigurieren.
Sondenverhalten
Quell-IP-Adresse
Die Quell-IP-Adresse der Probes hängt vom Backend-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.
Prüfvorgänge
Ein Gateway beginnt mit dem Senden von Probes, sobald Sie eine Regel konfiguriert haben, indem Sie sie mit einer Backend-Einstellung und einem Backend-Pool (und natürlich dem Listener) verknüpfen. Die Abbildung zeigt, dass das Gateway unabhängig alle Back-End-Poolservern testet. Die eingehenden Anforderungen, die eingehen, 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 Sonden werden basierend auf der eindeutigen Kombination aus Backend-Server und Backend-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 Seite zur Überprüfung der Back-End-Integrität anzeigen lassen.
Darüber hinaus untersuchen alle Instanzen des Anwendungsgateways die Back-End-Server unabhängig voneinander.
Probeintervalle
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 die Prüfsonde eine fehlgeschlagene Antwort erkennt, wird der Zähler für "Unhealthy threshold" aktiviert und kennzeichnet den Server als nicht gesund, wenn die aufeinanderfolgende Fehleranzahl mit dem konfigurierten Schwellenwert übereinstimmt. Wenn Sie also diesen Wert für „Fehlerschwellenwert“ auf 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 Backend-Gesundheitsbericht wird entsprechend dem Aktualisierungsintervall der jeweiligen Prüfung aktualisiert und hängt nicht von der Anforderung des Benutzers ab.
Standardmäßige Gesundheitsprü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 Standardabfragen wird HTTPS verwendet, um die Integrität der Back-End-Server zu testen, wenn die HTTP-Einstellungen der Back-End-Server 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 wird der HTTP GET-Hostheader für die Integritätssonde als http://127.0.0.1/angezeigt, es sei denn, ein Hostname ist in den Back-End-Einstellungen konfiguriert.
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 Standardsonde überprüft weiterhin alle 30 Sekunden Server A. Wenn Server A erfolgreich auf eine Anforderung einer standardmäßigen Gesundheitsprüfung antwortet, beginnt das Application-Gateway, die Anforderungen wieder an den Server weiterzuleiten.
Standardeinstellungen für Gesundheitsüberprüfungen
| Überprüfungseigenschaft | Wert | Beschreibung |
|---|---|---|
| Überprüfungs-URL | <Protokoll>://127.0.0.1:<Port>/ | Das Protokoll und der Port werden von den Backend-Einstellungen geerbt, denen die Probe zugeordnet ist. Der Standardhost ist 127.0.0.1, es sei denn, einer ist in den zugehörigen Back-End-Einstellungen angegeben. |
| 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. |
| Ungesunder 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. Bei der 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 hat. |
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 Tests verwenden. Weitere Informationen zu HTTPS-Tests finden Sie unter Übersicht über TLS-Beendigung und End-to-End-TLS mit Application Gateway.
Benutzerdefinierte Gesundheitsüberprüfung
Benutzerdefinierte Sonden ermöglichen Ihnen eine präzisere Kontrolle über die Gesundheitsüberwachung. 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 benutzerdefinierte Integritätstests
Die folgende Tabelle enthält Definitionen der Eigenschaften eines benutzerdefinierten Integritätstests.
| Überprüfungseigenschaft | Beschreibung |
|---|---|
| Name | Name der Sonde. Dieser Name wird verwendet, um den Test zu identifizieren und in den Back-End-HTTP-Einstellungen darauf zu verweisen. |
| Protokoll | Das Protokoll, das zum Senden der Probe verwendet wurde. 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 für das Senden der Probe. 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. |
| Pfad | Relativer Pfad der Messsonde. 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 | Timeout des Tests in Sekunden. Der Test wird als fehlerhaft markiert, wenn innerhalb des Zeitraums für den Timeout keine gültige Antwort empfangen wird. |
| Ungesunder 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 hat. |
| MinServers | Minimale Anzahl von Servern, die immer als fehlerfrei gekennzeichnet sind. Der Standardwert ist 0, was bedeutet, dass die Ergebnisse der Integritätsprüfung den Integritätsstatus aller Back-End-Server bestimmen. Bei Festlegung auf einen Wert größer als 0 wird die angegebene Anzahl von Servern unabhängig von den Testergebnissen immer als fehlerfrei gekennzeichnet. Diese Eigenschaft kann nur über PowerShell-, Azure CLI- oder ARM-Vorlagen konfiguriert werden (nicht im Azure-Portal verfügbar). |
Warnung
Verwenden Sie den MinServers-Parameter mit Vorsicht. Wenn MinServers auf einen Wert festgelegt ist, der größer als 0 ist, kennzeichnet Das Anwendungsgateway immer die Mindestanzahl von Back-End-Servern als fehlerfrei, auch wenn ihre Integritätsüberprüfungen fehlschlagen. Dies kann dazu führen, dass Datenverkehr an fehlerhafte Server gesendet wird, was möglicherweise den Fehler „502 Bad Gateway“ oder andere Verbindungsprobleme für Clients verursacht. Konfigurieren Sie MinServers nur, wenn Sie bestimmte Verfügbarkeitsanforderungen haben und die Auswirkungen der Außerkraftsetzung von Integritätstestergebnissen verstehen.
Probenabgleich
Standardmäßig gilt eine HTTP(S)-Antwort mit einem Statuscode zwischen 200 und 399 als fehlerfrei. Benutzerdefinierte Gesundheitsprüfungen unterstützen außerdem zwei Abgleichkriterien. Übereinstimmungskriterien können verwendet werden, um gegebenenfalls die Standardinterpretation einer zufriedenstellenden 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 darf nicht mehr als 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 Sonden
- 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 für den Live-Verkehr authentifizieren müssen, können Sie den Probeverkehr 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
Differenzierte Kontrolle ü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.