Metodi di routing del traffico verso l’origine

Si applica a: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (classico)

Importante

Frontdoor di Azure (classico) verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, è importante migrare i tuoi profili Frontdoor di Azure (classico) al livello Frontdoor di Azure Standard o Premium entro marzo 2027. Per ulteriori informazioni, vedere il ritiro di Frontdoor di Azure (classic).

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'originefa 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 equamente o in base ai coefficienti di ponderazione specificati. Il traffico viene distribuito in base ai valori di peso se le latenze dell'origine si trovano all'interno dell'intervallo di sensibilità 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, l'Endpoint name viene chiamato Frontend host nel classico Front Door di Azure.

Tutte le configurazioni di Front Door includono il monitoraggio dello stato del back-end e il failover globale automatizzato. Per ulteriori informazioni, vedere Monitoraggio del backend Front Door. 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 di regole Front Door, è possibile configurare regole per sovrascrivere le configurazioni di routing nei livelli Standard e Premium di Frontdoor di Azure o sovrascrivere il pool back-end su Frontdoor di Azure (versione classica) per una richiesta. Il gruppo di origine o il pool back-end configurato dal motore delle regole annulla il 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 attive e integre (200 OK) in base alla sonda 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 alla sonda di integrità): Selezionare le origini all'interno dell'intervallo di latenza consentito dall'ambiente Front Door in cui è arrivata la richiesta. Questo intervallo si basa sull'impostazione di sensibilità alla 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 si abilita l'affinità di sessione, la prima richiesta in una sessione segue il flusso illustrato in precedenza. Le richieste successive passano 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 Latency è l'impostazione predefinita per le configurazioni di Front Door 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 sensibilità alla 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 ulteriori informazioni, vedere l'architettura di routing di Frontdoor di Azure.

Routing del traffico basato sulla priorità

Per garantire un'elevata disponibilità, implementare i servizi di backup affinché possano subentrare in caso di guasto del servizio primario. Questa configurazione è nota come distribuzione Attiva/Standby o Attiva/Passiva. Il metodo di routing del traffico Priority in Frontdoor di Azure aiuta a implementare questo modello di failover.

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. Le sonde di integrità monitorano la disponibilità delle origini in base allo stato configurato e all'integrità.

Configurazione della priorità per le origini

Ogni origine nel gruppo di origine Frontdoor di Azure ha una proprietà Priority, che è possibile impostare 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 ponderato del traffico

Nota

Per i clienti con RPS molto basso (richieste al secondo), a causa della natura del modo in cui sono distribuiti POP e computer AFD, Frontdoor di Azure non può garantire che i pesi configurati siano rigorosamente seguiti e che il bilanciamento del carico possa apparire asimmetrico.

Il metodo di routing del traffico ponderato distribuisce 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 1.000, 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 si imposta la sensibilità di latenza 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. Bilanciare i pesi per preferire nuove origini, aumentando gradualmente la loro quota di traffico fino a quando gestiscono la maggior parte del traffico, quindi disabilitare e rimuovere le origini meno preferite.
• Cloud bursting per capacità aggiuntiva: espandere le implementazioni on-premise nel cloud aggiungendo o abilitando più origini di traffico 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.

Front Door di Azure utilizza l'affinità di sessione basata su cookie, dove vengono utilizzati cookie gestiti con SHA256 dell'URL di origine come identificatore. Questo metodo indirizza il traffico successivo da una sessione utente alla stessa origine.

È possibile abilitare l'affinità di sessione a livello di gruppo di origine in Frontdoor di Azure livelli Standard e Premium e a livello di host front-end in Frontdoor di Azure (versione classica) per ogni dominio o sottodominio configurato. Quando si abilita questa funzionalità, Frontdoor di Azure aggiunge cookie denominati ASLBSA e ASLBSACORS alla sessione dell'utente. Questi cookie consentono di identificare utenti diversi anche se condividono lo stesso indirizzo IP, che consente 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

Il cookie di sessione del browser mantiene l'affinità di sessione a livello di dominio. I sottodomini di un dominio wildcard possono condividere l'affinità di sessione purché il browser dell'utente invii richieste per la stessa origine delle risorse.

I proxy pubblici potrebbero interferire con l'affinità di sessione perché per stabilire una sessione è necessario che Frontdoor aggiunga un cookie di affinità di sessione alla risposta. Questa azione 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 viene stabilita se l'origine invia una risposta memorizzabile nella cache. Se la sessione è già stata stabilita, la memorizzazione nella cache della risposta non è importante.

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

• La risposta include l'intestazione Cache-Control con no-store.
• 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.