Panoramica dei probe di integrità del gateway applicazione
Il gateway applicazione di Azure monitora l'integrità di tutti i server nel pool back-end e arresta automaticamente l'invio del traffico a qualsiasi server considerato non integro. I probe continuano a monitorare un server non integro e il gateway avvia nuovamente il routing del traffico a tale server non appena i probe lo rilevano come integri.
Il probe predefinito usa il numero di porta dell'impostazione back-end associata e altre configurazioni predefinite. È possibile usare probe personalizzati per configurarli in modo personalizzato.
Comportamento dei probe
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 sarà l'indirizzo IP pubblico front-end del gateway applicazione.
- Se il server nel pool back-end è un endpoint privato, l'indirizzo IP di origine proviene dallo spazio indirizzi della subnet del gateway applicazione.
Operazioni probe
Un gateway avvia la generazione di probe immediatamente dopo aver configurato una regola associandola a un'impostazione back-end e a un pool back-end (e il listener, naturalmente). La figura mostra che il gateway esegue il probe indipendente di tutti i server del pool 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 probe corretta.
I probe necessari vengono determinati in base alla combinazione univoca 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 back-end distinte sono associate allo stesso pool back-end che usa le rispettive regole, il gateway crea probe per ogni server e la combinazione dell'impostazione back-end. È possibile visualizzare questa opzione nella pagina Integrità back-end.
Inoltre, tutte le istanze del gateway applicazione eseguono il probe dei server back-end indipendentemente l'una dall'altra.
Intervalli di probe
La stessa configurazione probe si applica a ogni istanza del gateway applicazione. Ad esempio, se un gateway applicazione ha due istanze e l'intervallo di probe è impostato su 20 secondi, entrambe le istanze invieranno il probe di integrità ogni 20 secondi.
Quando il probe rileva una risposta non riuscita, il contatore per "Soglia non integra" viene disattivato e contrassegna il server come non integro se il numero di errori consecutivi corrisponde alla soglia configurata. Di conseguenza, se si imposta questa soglia non integra su 2, il probe successivo rileverà prima di tutto questo errore. Il gateway applicazione contrassegnerà quindi il server come non integro dopo 2 probe non riusciti consecutivi [Primo rilevamento 20 sec + (2 probe consecutivi non riusciti * 20 sec)].
Nota
Il report sull'integrità back-end 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 i probe predefiniti, se le impostazioni HTTP del back-end vengono configurate per HTTPS, il probe usa 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 integra 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, la richiesta HTTP GET per il probe di integrità è simile a http://127.0.0.1/. Vedere anche Codici di risposta HTTP nel gateway applicazione.
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 un probe di integrità predefinito, il gateway applicazione avvia nuovamente l'inoltro delle richieste al server.
Impostazioni predefinite del probe di integrità
| Proprietà probe | Valore | Descrizione |
|---|---|---|
| URL probe | <protocol>://127.0.0.1:<porta>/ | Il protocollo e la porta vengono ereditati dalle impostazioni HTTP del back-end a cui è associato il probe |
| 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 integra | 3 | Determina quanti probe inviare in caso di errore del probe di integrità normale. Nello SKU v1 questi probe di integrità aggiuntivi vengono inviati in rapida successione per determinare rapidamente l'integrità del back-end e non attendono l'intervallo di probe. Per SKU versione 2, i probe 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 il probe di integrità per passare a un URL personalizzato o modificare altre impostazioni, è necessario usare probe personalizzati. 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 dell'integrità. Quando si usano probe personalizzati, è possibile configurare un nome host personalizzato, un percorso URL, un intervallo di probe e il numero di risposte non riuscite da accettare prima di contrassegnare l'istanza del pool back-end come non integra e così via.
Impostazioni del probe di integrità personalizzato
La tabella seguente fornisce le definizioni delle proprietà di un probe di integrità personalizzato.
| Proprietà probe | Descrizione |
|---|---|
| Name | Nome del probe. Questo nome viene usato per identificare e fare riferimento al probe nelle impostazioni HTTP back-end. |
| Protocollo | Protocollo usato per inviare il probe. Deve corrispondere al protocollo definito nelle impostazioni HTTP back-end a cui è associato |
| Host | Nome host con cui inviare il probe. 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 del probe. 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 probe 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, il probe viene contrassegnato come non riuscito |
| Soglia non integra | Numero di tentativi di probe. Il server back-end viene contrassegnato come inattivo dopo che il numero di errori di probe consecutivi ha raggiunto una soglia non integra |
Criteri di corrispondenza dei probe
Per impostazione predefinita, una risposta HTTP(S) con codice di stato compreso tra 200 e 399 viene considerata integra. I probe di integrità personalizzati supportano anche due criteri di corrispondenza. Questi criteri possono essere usati per modificare l'interpretazione predefinita di ciò che costituisce una risposta integra.
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 almeno 4090 caratteri.
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 probe usando un operatore -Match in PowerShell.
Alcuni casi d'uso per probe personalizzati
- 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 associati per autenticarsi per il traffico live, è possibile configurare il traffico probe per accettare 403 come risposta prevista.
- Quando un server back-end dispone di un certificato con caratteri jolly (*.contoso.com) installato per gestire domini secondari diversi, è possibile usare un probe personalizzato con un nome host specifico (obbligatorio per SNI) accettato per stabilire un probe TLS riuscito 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 della subnet del gateway applicazione tramite regole del gruppo di sicurezza di rete è 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 altre informazioni, vedere Panoramica della configurazione del gateway applicazione.
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.