Probe di integrità

  • Articolo

Importante

Frontdoor di Azure (versione classica) verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, è importante eseguire la migrazione dei profili frontdoor di Azure (versione classica) al livello Frontdoor di Azure Standard o Premium entro marzo 2027. Per altre informazioni, vedere Ritiro di Frontdoor di Azure (versione classica).

Nota

Un'origine e un gruppo di origine in questo articolo si riferiscono al back-end e al pool back-end di una configurazione di Frontdoor di Azure (versione classica).

Per determinare l'integrità e la prossimità di ogni origine per un determinato ambiente Frontdoor di Azure, ogni profilo frontdoor invia periodicamente una richiesta HTTP/HTTPS sintetica a tutte le origini configurate. Frontdoor usa quindi le risposte del probe di integrità per determinare l'origine migliore a cui instradare le richieste client.

Avviso

Poiché ogni posizione perimetrale di Frontdoor di Azure invia probe di integrità alle origini, il volume del probe di integrità per le origini può essere piuttosto elevato. Il numero di probe dipende dalla posizione del traffico del cliente e dalla frequenza del probe di integrità. Se le posizioni perimetrali di Frontdoor di Azure non ricevono traffico reale dagli utenti finali, la frequenza del probe di integrità dalla posizione perimetrale viene ridotta rispetto alla frequenza configurata. Se è presente traffico verso tutte le posizioni perimetrali di Frontdoor di Azure, il volume del probe di integrità può essere elevato a seconda della frequenza dei probe di integrità.

Esempio per stimare approssimativamente il volume del probe di integrità al minuto in un'origine quando si usa la frequenza probe predefinita di 30 secondi. Il volume del probe in ogni origine è uguale al numero di posizioni perimetrali volte due richieste al minuto. Le richieste di probe saranno inferiori se non è presente traffico inviato a tutte le posizioni perimetrali. Per un elenco delle posizioni perimetrali, vedere Località perimetrali per area.

Protocolli supportati

Frontdoor di Azure supporta l'invio di probe su protocolli HTTP o HTTPS. Questi probe vengono inviati sulle stesse porte TCP configurate per il routing delle richieste client e non possono essere sottoposti a override. I probe HTTP/HTTPS di Frontdoor vengono inviati con l'intestazione impostata con User-Agent il valore : Edge Health Probe.

Metodi HTTP supportati per i probe di integrità

Frontdoor di Azure supporta i metodi HTTP seguenti per l'invio dei probe di integrità:

  1. GET: il metodo GET indica il recupero delle informazioni (sotto forma di entità) identificate dall'URI Request.
  2. HEAD: il metodo HEAD è identico a GET, ad eccezione del fatto che il server NON DEVE restituire un corpo del messaggio nella risposta. Per i nuovi profili frontdoor, per impostazione predefinita, il metodo probe viene impostato come HEAD.

Suggerimento

Per ridurre il carico e i costi alle origini, Frontdoor consiglia di usare le richieste HEAD per i probe di integrità.

Risposte del probe di integrità

Risposte Descrizione
Determinazione dell'integrità Un codice di stato 200 OK indica che l'origine è integra. Qualsiasi altro codice di stato è considerato un errore. Se per qualsiasi motivo non viene ricevuta una risposta HTTP valida per un probe, il probe viene conteggiato come errore.
Misurazione della latenza La latenza è l'ora di tempo in tempo reale misurato dal momento immediatamente prima che la richiesta probe venga inviata al momento in cui Frontdoor riceve l'ultimo byte della risposta. Frontdoor usa una nuova connessione TCP per ogni richiesta. La misurazione non è distorta verso le origini con connessioni calde esistenti.

Come Frontdoor determina l'integrità dell'origine

Frontdoor di Azure usa un processo in tre passaggi per tutti gli algoritmi per determinare l'integrità.

  1. Escludere le origini disabilitate.

  2. Escludere origini con errori di probe di integrità:

    • Questa selezione viene eseguita osservando le ultime n risposte del probe di integrità. Se almeno x sono integri, l'origine viene considerata integra.

    • n viene configurato modificando la proprietà SampleSize nelle impostazioni di bilanciamento del carico.

    • x viene configurato modificando la proprietà SuccessfulSamplesRequired nelle impostazioni di bilanciamento del carico.

  3. Per i set di origini integre in un gruppo di origine, Frontdoor misura e mantiene la latenza per ogni origine.

Nota

Se un singolo endpoint è membro di più gruppi di origine, Frontdoor ottimizza il numero di probe di integrità inviati all'origine per ridurre il carico sull'origine. Le richieste di probe di integrità verranno inviate in base all'intervallo di campionamento configurato più basso. L'integrità dell'endpoint in tutti i gruppi di origine verrà determinata dalle risposte degli stessi probe di integrità.

Errore di completamento del probe di integrità

Se i probe di integrità hanno esito negativo per ogni origine in un gruppo di origine, Frontdoor considera tutte le origini non integre e instrada il traffico in una distribuzione round robin tra tutte.

Quando un'origine torna a uno stato integro, Frontdoor riprende l'algoritmo di bilanciamento del carico normale.

Disabilitazione dei probe di integrità

Se si ha una singola origine nel gruppo di origine, è possibile scegliere di disabilitare i probe di integrità per ridurre il carico nell'applicazione. Se sono presenti più origini nel gruppo di origine e più di una di esse sono in stato abilitato, non è possibile disabilitare i probe di integrità.

Passaggi successivi

  • Informazioni su come creare un profilo frontdoor di Azure.
  • Informazioni sull'architettura di routing di Frontdoor.