Metodi di routing del traffico verso l’origine

Importante

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

Frontdoor di Azure supporta quattro metodi di routing del traffico per gestire la distribuzione del traffico HTTP/HTTPS tra origini diverse. Quando le richieste degli utenti raggiungono le posizioni perimetrali di Frontdoor, il metodo di routing configurato garantisce che le richieste vengano inoltrate alla risorsa back-end migliore.

Nota

In questo articolo un'origine fa riferimento al back-end e un gruppo di origine fa riferimento al pool back-end nella configurazione di Frontdoor di Azure (versione classica).

I quattro metodi di routing del traffico sono:

• Latenza: instrada le richieste alle origini con la latenza più bassa all'interno di un intervallo di riservatezza accettabile, assicurando che le richieste vengano inviate alle origini più vicine in termini di latenza di rete.

• Priorità: consente di impostare una priorità per le origini, designando un'origine primaria per gestire tutto il traffico e un'origine secondaria come backup se il database primario non è più disponibile.

• Ponderato: assegna un peso a ogni origine per distribuire il traffico in modo uniforme o in base ai coefficienti di peso specificati. Il traffico viene distribuito in base ai valori di peso se le latenze delle origini si trovano all'interno dell'intervallo di riservatezza accettabile.

• Affinità di sessione: assicura che le richieste dello stesso utente finale vengano inviate alla stessa origine configurando l'affinità di sessione per gli host o i domini front-end.

Nota

Nei livelli Frontdoor di Azure Standard e Premium, il nome dell'endpoint viene definito host front-end in Frontdoor di Azure (versione classica).

Tutte le configurazioni di Frontdoor includono il monitoraggio dell'integrità back-end e il failover globale automatizzato. Per altre informazioni, vedere Monitoraggio del back-end Frontdoor Frontdoor di Azure può usare un singolo metodo di routing o combinare più metodi per creare una topologia di routing ottimale in base alle esigenze dell'applicazione.

Nota

Usando il motore regole di Frontdoor, è possibile configurare regole per eseguire l'override delle configurazioni di route nei livelli Frontdoor di Azure Standard e Premium o eseguire l'override del pool back-end in Frontdoor di Azure (versione classica) per una richiesta. Il gruppo di origine o il pool back-end impostato dal motore regole eseguirà l'override del processo di routing descritto in questo articolo.

Flusso decisionale generale

Il diagramma seguente illustra il flusso decisionale complessivo:

I passaggi decisionali sono:

1. Origini disponibili: selezionare tutte le origini abilitate e integre (200 OK) in base al probe di integrità.
   • Esempio: se sono presenti sei origini A, B, C, D, E e F e C è non integro e E è disabilitato, le origini disponibili sono A, B, D e F.
2. Priorità: selezionare le origini con priorità superiore da quelle disponibili.
   • Esempio: se le origini A, B e D hanno priorità 1 e l'origine F ha priorità 2, le origini selezionate sono A, B e D.
3. Segnale di latenza (in base al probe di integrità): selezionare le origini all'interno dell'intervallo di latenza consentito dall'ambiente Frontdoor in cui è arrivata la richiesta. Si basa sull'impostazione di riservatezza della latenza del gruppo di origine e sulla latenza delle origini più vicine.
   • Esempio: se la latenza all'origine A è 15 ms, fino a B è 30 ms e a D è 60 ms e la sensibilità alla latenza è impostata su 30 ms, le origini selezionate sono A e B, perché D supera l'intervallo di 30 ms.
4. Pesi: distribuire il traffico tra le origini selezionate finali in base ai rapporti di peso specificati.
   • Esempio: se l'origine A ha un peso pari a 3 e l'origine B ha un peso pari a 7, il traffico viene distribuito da 3/10 a A e da 7/10 a B.

Se l'affinità di sessione è abilitata, la prima richiesta in una sessione segue il flusso illustrato in precedenza. Le richieste successive vengono inviate all'origine selezionata nella prima richiesta.

Routing del traffico in base alla latenza più bassa

La distribuzione di origini in più posizioni globali può migliorare la velocità di risposta dell'applicazione instradando il traffico all'origine "più vicino" agli utenti finali. Il metodo di routing latenza è l'impostazione predefinita per le configurazioni di Frontdoor di Azure. Questo metodo indirizza le richieste degli utenti all'origine con la latenza di rete più bassa, anziché la posizione geografica più vicina, garantendo prestazioni ottimali.

L'architettura anycast di Frontdoor di Azure, combinata con il metodo di routing di latenza, garantisce che ogni utente esperienze le migliori prestazioni in base alla propria posizione. Ogni ambiente Frontdoor misura in modo indipendente la latenza rispetto alle origini, ovvero gli utenti in posizioni diverse vengono indirizzati all'origine che offre le migliori prestazioni per il proprio ambiente specifico.

Nota

Per impostazione predefinita, la proprietà di riservatezza della latenza è impostata su 0 ms. Con questa impostazione, le richieste vengono sempre inoltrate alle origini disponibili più veloci. I pesi sulle origini hanno effetto solo se due origini hanno la stessa latenza di rete.

Per altre informazioni, vedere Architettura di routing di Frontdoor di Azure.

Routing del traffico basato sulla priorità

Per garantire la disponibilità elevata, le organizzazioni spesso distribuiscono i servizi di backup per assumere il controllo in caso di errore del servizio primario. Questa configurazione è nota come distribuzione attiva/standby o attiva/passiva. Il metodo di routing del traffico Priority in Frontdoor di Azure consente di implementare questo modello di failover in modo efficace.

Per impostazione predefinita, Frontdoor di Azure instrada il traffico alle origini con la priorità più alta (valore di priorità più basso). Se queste origini primarie diventano non disponibili, instrada il traffico alle origini secondarie (successivo valore di priorità più basso). Questo processo continua con origini terziarie se le origini primarie e secondarie non sono disponibili. I probe di integrità monitorano la disponibilità delle origini in base allo stato e all'integrità configurati.

Configurazione della priorità per le origini

Ogni origine nel gruppo di origine di Frontdoor di Azure ha una proprietà Priority , che può essere impostata su un valore compreso tra 1 e 5. I valori inferiori indicano una priorità più alta. Più origini possono condividere lo stesso valore di priorità.

Metodo di routing del traffico Ponderato

Il metodo di routing del traffico ponderato consente di distribuire il traffico in base a pesi predefiniti.

In questo metodo si assegna un peso a ogni origine nel gruppo di origine di Frontdoor di Azure. Il peso è un numero intero compreso tra 1 e 1000, con un valore predefinito pari a 50.

Il traffico viene distribuito tra le origini disponibili usando un meccanismo round robin basato sui rapporti di peso specificati, a condizione che le origini soddisfino la sensibilità di latenza accettabile. Se la sensibilità alla latenza è impostata su 0 millisecondi, i pesi diventano effettivi solo se due origini hanno la stessa latenza di rete.

Il metodo ponderato supporta diversi scenari:

• Aggiornamento graduale dell'applicazione: instradare una percentuale di traffico a una nuova origine e aumentarlo gradualmente nel tempo.
• Migrazione dell'applicazione in Azure: creare un gruppo di origini con origini di Azure ed esterne. Regolare i pesi per preferire nuove origini, aumentando gradualmente la condivisione del traffico fino a quando non gestiscono la maggior parte del traffico, quindi disabilitano e rimuovono origini meno preferite.
• Bursting del cloud per capacità aggiuntiva: espandere le distribuzioni locali nel cloud aggiungendo o abilitando più origini e specificando la distribuzione del traffico.

Affinità di sessione

Per impostazione predefinita, Frontdoor di Azure inoltra le richieste dallo stesso client a origini diverse. Tuttavia, l'affinità di sessione è utile per applicazioni o scenari con stato in cui le richieste successive dello stesso utente devono essere elaborate dalla stessa origine. Questa funzionalità garantisce che la stessa origine gestisca la sessione di un utente, utile per scenari come l'autenticazione client.

Frontdoor di Azure usa l'affinità di sessione basata su cookie, in cui vengono usati i cookie gestiti con SHA256 dell'URL di origine. In questo modo si indirizza il traffico successivo da una sessione utente alla stessa origine.

L'affinità di sessione può essere abilitata a livello di gruppo di origine nei livelli Frontdoor di Azure Standard e Premium e a livello di host front-end in Frontdoor di Azure (versione classica) per ogni dominio o sottodominio configurato. Dopo l'abilitazione, Frontdoor di Azure aggiunge i cookie denominati ASLBSA e ASLBSACORS alla sessione dell'utente. Questi cookie consentono di identificare utenti diversi anche se condividono lo stesso indirizzo IP, consentendo una distribuzione più uniforme del traffico tra le origini.

La durata del cookie corrisponde alla sessione dell'utente, perché Frontdoor supporta attualmente solo i cookie di sessione.

Nota

L'affinità di sessione viene mantenuta tramite il cookie di sessione del browser a livello di dominio. I sottodomini nello stesso dominio con caratteri jolly possono condividere l'affinità di sessione purché il browser dell'utente invii richieste per la stessa risorsa di origine.

I proxy pubblici possono interferire con l'affinità di sessione perché per stabilire una sessione è necessario che Frontdoor aggiunga un cookie di affinità di sessione alla risposta. Questa operazione non può essere eseguita se la risposta è memorizzabile nella cache, perché interrompe i cookie per altri client che richiedono la stessa risorsa. Per evitare questo problema, l'affinità di sessione non verrà stabilita se l'origine invia una risposta memorizzabile nella cache. Se la sessione è già stata stabilita, la cache della risposta non è importante.

L'affinità di sessione verrà stabilita nelle circostanze seguenti oltre gli scenari standard non memorizzabili nella cache:

• La risposta include l'intestazione Cache-Control senza archivio.
• La risposta contiene un'intestazione valida Authorization .
• La risposta è un codice di stato HTTP 302.

Passaggi successivi

• Informazioni su come creare un profilo Frontdoor di Azure.
• Informazioni sul funzionamento di Frontdoor di Azure.