Panoramica del monitoraggio dell'integrità del gateway applicazione
gateway applicazione di Azure per impostazione predefinita monitora l'integrità di tutte le risorse nel pool back-end e rimuove automaticamente qualsiasi risorsa considerata non integra dal pool. gateway applicazione continua a monitorare le istanze non integre e le aggiunge nuovamente al pool back-end integro una volta che diventano disponibili e rispondono ai probe di integrità. Per impostazione predefinita, il gateway applicazione invia i probe di integrità con la stessa porta definita nelle impostazioni HTTP back-end. È possibile configurare una porta personalizzata per i probe usando un probe di integrità personalizzato.
L'indirizzo IP di origine usato gateway applicazione per i probe di integrità dipenderà dal pool back-end:
- Se l'indirizzo del server nel pool back-end è un endpoint pubblico, l'indirizzo di origine corrisponde all'indirizzo IP pubblico front-end del gateway applicazione.
- Se l'indirizzo del server nel pool back-end è un endpoint privato, l'indirizzo IP di origine deriva dallo spazio di indirizzi IP privato della subnet del gateway applicazione.
Oltre al monitoraggio del probe di integrità predefinito, è anche possibile personalizzare il probe di integrità in base ai requisiti dell'applicazione. In questo articolo vengono illustrati i probe di integrità predefiniti e personalizzati.
Nota
È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.
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 l'uso dei server back-end A, B e C per ricevere il traffico di rete HTTP sulla porta 80. Il monitoraggio dell'integrità predefinito esegue un test dei tre server ogni 30 secondi per verificare la presenza 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à sarà simile a http://127.0.0.1/.
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 del probe di integrità predefinito
| Proprietà probe | valore | Descrizione |
|---|---|---|
| URL probe | <protocol>://127.0.0.1:<port>/ | Il protocollo e la porta vengono ereditati dalle impostazioni HTTP del back-end a cui è associato il probe |
| Interval | 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 lo SKU v2, i probe di integrità attendono l'intervallo. Il server back-end viene contrassegnato come inattivo dopo che il numero di errori del probe consecutivo raggiunge la soglia non integra. |
Il probe predefinito esamina solo <il protocollo>://127.0.0.1:<port> 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 gateway applicazione.
Intervalli probe
Tutte le istanze del gateway applicazione eseguono il probe del back-end in modo indipendente. La stessa configurazione di probe si applica a ogni istanza del gateway applicazione. Ad esempio, se la configurazione del probe consiste nell'inviare probe di integrità ogni 30 secondi e se il gateway applicazione dispone di due istanze, entrambe le istanze invieranno il probe di integrità ogni 30 secondi.
Se sono presenti più listener, ogni listener esegue il probe nel back-end in modo indipendente. Ad esempio, se sono presenti due listener che puntano allo stesso pool back-end su due porte diverse, ossia configurate da due impostazioni http di back-end, ogni listener eseguirà il probe dello stesso back-end in modo indipendente. In questo caso, esistono due probe da ogni istanza del gateway applicazione per i due listener. Se sono presenti due istanze del gateway applicazione in questo scenario, la macchina virtuale back-end vedrà quattro probe per l'intervallo di probe configurato.
Probe di integrità personalizzato
I probe personalizzati consentono di avere 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 |
|---|---|
| Nome | 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 verrà usato solo per l'intestazione host della richiesta del probe. Nello SKU v2 verrà usato sia come intestazione host che come SNI |
| Path | Percorso relativo del probe. Un percorso valido inizia con "/". |
| Porta | Se definita, viene usata come porta di destinazione. In caso contrario, viene usata la stessa porta delle impostazioni HTTP a cui è associato il probe. Questa proprietà è disponibile solo nello SKU v2 |
| Interval | 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 è contrassegnato come inattivo dopo che il numero di errori del probe consecutivo raggiunge la 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 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"
Una volta specificati, i criteri di corrispondenza possono essere associati alla configurazione del probe tramite un parametro -Match in PowerShell.
Considerazioni sui gruppi di sicurezza di rete
È 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.