Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il gateway delle applicazioni di Azure monitora l'integrità di tutti i server nel pool backend e arresta automaticamente l'invio del traffico a qualsiasi server considerato non funzionale. Le sonde continuano a monitorare un server malfunzionante e il gateway avvia nuovamente il routing del traffico verso di esso non appena le sonde lo rilevano come funzionante correttamente.
Il probe predefinito usa il numero di porta dell'impostazione back-end associata e altre configurazioni predefinite. È possibile usare probe personalizzati per configurarli a modo tuo.
Comportamento delle sonde
Indirizzo IP di origine
L'indirizzo IP di origine dei probe dipende dal tipo di server back-end:
- Se il server nel pool back-end è un endpoint pubblico, l'indirizzo di origine corrisponderà all'indirizzo IP pubblico front-end del gateway applicazione.
- Se il server nel pool back-end è un endpoint privato, l'indirizzo IP di origine deriverà dallo spazio degli indirizzi della subnet del gateway applicazione.
Operazioni della sonda
Un gateway avvia i probe immediatamente dopo aver configurato una regola associandola a un'impostazione del back-end e a un pool del back-end (e al listener, naturalmente). L'illustrazione mostra che il gateway effettua un controllo indipendente di tutti i server del pool di back-end. Le richieste in ingresso che iniziano ad arrivare vengono inviate solo ai server integri. Un server back-end è contrassegnato come non integro per impostazione predefinita fino a quando non viene ricevuta una risposta corretta dal probe.
I probe necessari sono determinati in base alla combinazione unica del server back-end e dell'impostazione back-end. Si consideri ad esempio un gateway con un singolo pool back-end con due server e due impostazioni back-end, ognuna con numeri di porta diversi. Quando queste impostazioni backend distinte sono associate allo stesso pool di backend utilizzando le rispettive regole, il gateway crea sonde per ogni server e per la combinazione delle impostazioni backend. È possibile visualizzare questa opzione nella pagina Integrità del back-end.
Inoltre, tutte le istanze del gateway dell'applicazione eseguono il probe dei server back-end indipendentemente l'una dall'altra.
Intervalli di probe
La stessa configurazione sonda si applica a ogni istanza del gateway applicativo. Ad esempio, se un gateway applicazione ha due istanze e l'intervallo del probe è impostato su 20 secondi, le istanze invieranno il probe di integrità ogni 20 secondi.
Quando il probe rileva una risposta non riuscita, il contatore per la "Soglia di non funzionamento" si attiva e contrassegna il server come non funzionante se il conteggio di errori consecutivi corrisponde alla soglia configurata. Di conseguenza, se si imposta questa soglia di non integrità su 2, il probe successivo rileverà per primo questo errore. Il gateway applicativo contrassegnerà quindi il server come non funzionante dopo 2 sonde non riuscite consecutive [Primo rilevamento 20 secondi + (2 sonde consecutive non riuscite * 20 secondi)].
Nota
Il report dell'integrità del backend viene aggiornato in base all'intervallo di aggiornamento del probe corrispondente e non dipende dalla richiesta dell'utente.
Probe di integrità predefinito
Un gateway applicazione configura automaticamente un probe di integrità predefinito quando non si configura nessuna configurazione di probe personalizzato. Il comportamento di monitoraggio funziona effettuando una richiesta HTTP GET agli indirizzi IP o al nome di dominio completo configurato nel pool back-end. Per le sonde predefinite, se le impostazioni HTTP del back-end sono configurate per HTTPS, la sonda utilizza HTTPS per testare l'integrità dei server back-end.
Ad esempio, si configura il gateway applicazione per usare i server back-end A, B e C per ricevere il traffico di rete HTTP sulla porta 80. Il monitoraggio dell'integrità predefinito testa i tre server ogni 30 secondi per una risposta HTTP valida con un timeout di 30 secondi per ogni richiesta. Una risposta HTTP integra ha un codice di stato compreso tra 200 e 399. In questo caso, l'intestazione HTTP GET Host per il probe di integrità viene visualizzata come http://127.0.0.1/, a meno che non sia configurato un nome host nelle Impostazioni back-end.
Se la verifica del probe predefinito non riesce per il server A, il gateway applicazione interrompe l'inoltro delle richieste a questo server. Il probe predefinito continua tuttavia a controllare il server A ogni 30 secondi. Quando il server A risponde correttamente a una richiesta di una sonda di integrità predefinita, l'application gateway riprende a inoltrare le richieste al server.
Impostazioni predefinite della sonda di integrità
| Proprietà probe | Valore | Descrizione |
|---|---|---|
| URL probe | <protocollo>://127.0.0.1:<porta>/ | Il protocollo e la porta vengono ereditati dalle impostazioni back-end a cui è associato il probe. L'host predefinito è 127.0.0.1, a meno che non ne sia specificato uno nelle impostazioni back-end associate. |
| Intervallo | 30 | Il tempo di attesa in secondi prima di inviare il probe di integrità successivo. |
| Timeout | 30 | Il tempo in secondi che un gateway applicazione trascorre in attesa di una risposta del probe prima di contrassegnare il probe come non integro. Se un probe viene restituito come integro, il back-end corrispondente viene subito contrassegnato anch'esso come tale. |
| Soglia non salutare | 3 | Determina quanti probe inviare in caso di errore del probe di integrità normale. Nello SKU v1, queste sonde di integrità aggiuntive vengono inviate in rapida successione per determinare rapidamente l'integrità del back-end, senza attendere l'intervallo di sondaggio. Per la versione 2 dello SKU, le sonde di integrità attendono l'intervallo. Il server back-end viene contrassegnato come inattivo dopo che il numero di errori di probe consecutivi ha raggiunto una soglia non integra. |
Il probe predefinito esamina solo <protocollo>://127.0.0.1:<porta> per determinare lo stato di integrità. Se si deve configurare la sonda di integrità per passare a un URL personalizzato o modificare altre impostazioni, è necessario usare sonde personalizzate. Per altre informazioni sui probe HTTPS, vedere Panoramica della terminazione TLS e di TLS end-to-end con il gateway applicazione.
Probe di integrità personalizzato
I probe personalizzati consentono un controllo più granulare sul monitoraggio dello stato di salute. Quando si usano sonde personalizzate, è possibile configurare un nome host personalizzato, un percorso URL, un intervallo delle sonde e il numero di risposte non riuscite da accettare prima di contrassegnare l'istanza del pool back-end come non funzionante, eccetera.
Le impostazioni della sonda di salute personalizzata
La tabella seguente fornisce le definizioni delle proprietà di una sonda di integrità personalizzata.
| Proprietà probe | Descrizione |
|---|---|
| Name | Nome della sonda. Questo nome viene usato per identificare e fare riferimento al probe nelle impostazioni HTTP back-end. |
| Protocollo | Protocollo utilizzato per inviare la sonda. Deve corrispondere al protocollo definito nelle impostazioni HTTP back-end a cui è associato |
| Host | Nome host a cui inviare la sonda. Nello SKU v1 questo valore viene usato solo per l'intestazione host della richiesta del probe. Nello SKU v2 viene usato sia come intestazione host che come SNI |
| Percorso | Percorso relativo della sonda. Un percorso valido inizia con "/". |
| Porta | Se definita, viene usata come porta di destinazione. In caso contrario, usa la stessa porta delle impostazioni HTTP a cui è associata. Questa proprietà è disponibile solo nello SKU v2 |
| Intervallo | Intervallo di sonda in secondi. Il valore corrisponde all'intervallo di tempo tra due probe consecutivi |
| Timeout | Timeout del probe in secondi. Se non viene ricevuta una risposta valida entro questo periodo di timeout, la sonda viene contrassegnata come non riuscita |
| Soglia inadatta | Numero di tentativi di probe. Il server back-end viene contrassegnato come inattivo dopo che il numero di errori di sonda consecutivi ha raggiunto la soglia di criticità. |
| MinServers | Numero minimo di server sempre contrassegnati come integri. Il valore predefinito è 0, il che significa che i risultati della sonda di integrità determinano lo stato di integrità di tutti i server backend. Se impostato su un valore maggiore di 0, il numero specificato di server viene sempre contrassegnato come integro indipendentemente dai risultati del probe. Questa proprietà è configurabile solo tramite PowerShell, l'interfaccia della riga di comando di Azure o i modelli arm (non disponibili nel portale di Azure). |
Avviso
Usare il parametro MinServers con cautela. Quando MinServers è impostato su un valore maggiore di 0, Application Gateway contrassegna sempre il numero minimo di server back-end come in stato di integrità, anche se le sonde di integrità stanno fallendo. Ciò può causare l'invio di traffico a server non integri, causando potenzialmente errori del gateway non valido 502 o altri problemi di connettività per i client. Configurare MinServers solo se sono presenti requisiti di disponibilità specifici e se si comprendono le implicazioni del sovrascrivere i risultati della sonda di integrità.
Criteri di corrispondenza dei probe
Per impostazione predefinita, una risposta HTTP(S) con codice di stato compreso tra 200 e 399 viene considerata integra. Le sonde di controllo dello stato personalizzate supportano anche due criteri di corrispondenza. I criteri di abbinamento possono essere utilizzati facoltativamente per modificare l'interpretazione predefinita di ciò che costituisce una risposta adeguata.
I criteri di corrispondenza sono i seguenti:
- Corrispondenza del codice di stato della risposta HTTP: il criterio adottato da un probe per accettare il codice di risposta o l'intervallo di codici di risposta HTTP specificato dall'utente. Sono supportati singoli codici di stato della risposta, delimitati da virgole, o un intervallo di codici di stato.
- Corrispondenza del corpo della risposta HTTP: il criterio adottato dal probe in base al quale viene esaminato il corpo della risposta HTTP e viene stabilita una corrispondenza con una stringa specificata dall'utente. La corrispondenza verifica solo la presenza della stringa specificata dall'utente nel corpo della risposta e non è una corrispondenza completa basata su espressione regolare. La corrispondenza specificata deve essere di 4090 caratteri o meno.
I criteri di corrispondenza possono essere specificati tramite il cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.
Ad esempio:
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
I criteri di corrispondenza possono essere collegati alla configurazione del sondaggio utilizzando in PowerShell un operatore -Match.
Alcuni casi d'uso per sonde personalizzate
- Se un server back-end consente l'accesso solo agli utenti autenticati, i probe del gateway applicazione riceveranno un codice di risposta 403 anziché 200. Poiché i client (utenti) sono obbligati ad autenticarsi per accedere al traffico live, puoi configurare il traffico di prova per accettare 403 come risposta attesa.
- Quando un server back-end dispone di un certificato wildcard (*.contoso.com) installato per gestire diversi sotto-domini, è possibile usare un probe personalizzato con un nome host specifico (obbligatorio per SNI) accettato per stabilire con successo un probe TLS e segnalare tale server come integro. Con "override hostname" nell'impostazione back-end impostata su NO, i diversi nomi host in ingresso (sottodomini) verranno passati così come sono al back-end.
Considerazioni sui gruppi di sicurezza di rete
Il controllo granulare sulla subnet del gateway applicazione tramite regole NSG è ora possibile in anteprima pubblica. Per informazioni dettagliate, vedere questo articolo.
Con la funzionalità corrente esistono alcune restrizioni:
È necessario consentire il traffico Internet in ingresso sulle porte TCP 65503-65534 per lo SKU del gateway applicazione v1 e sulle porte TCP 65200-65535 per lo SKU v2 con la subnet di destinazione impostata su Qualsiasi e l'origine impostata sul tag di servizio GatewayManager. Questo intervallo di porte è necessario per la comunicazione di infrastruttura di Azure.
Non è possibile neanche bloccare la connettività Internet in uscita ed è necessario autorizzare il traffico in ingresso proveniente dal tag AzureLoadBalancer.
Per ulteriori informazioni, vedere Panoramica della configurazione del gateway delle applicazioni.
Passaggi successivi
Dopo aver acquisito familiarità con il monitoraggio dell'integrità del gateway applicazione, è possibile configurare un probe di integrità personalizzato nel portale di Azure oppure un probe di integrità personalizzato usando PowerShell e il modello di distribuzione Azure Resource Manager.