Metodi di routing del traffico all'origine

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).

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

Nota

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

I quattro metodi di routing del traffico sono:

• Latenza: il routing basato sulla latenza garantisce che le richieste vengano inviate alle origini di latenza più basse accettabili all'interno di un intervallo di riservatezza. In altre parole, le richieste vengono inviate al set di origini più vicino rispetto alla latenza di rete.

• Priorità: una priorità può essere impostata su origini quando si vuole configurare un'origine primaria per il servizio di tutto il traffico. L'origine secondaria può essere un backup nel caso in cui l'origine primaria non sia più disponibile.

• Ponderato: un valore ponderato può essere assegnato alle origini quando si vuole distribuire il traffico in un set di origini in modo uniforme o in base ai coefficienti di peso. Il traffico viene distribuito dal valore di peso se le latenze delle origini si trovano all'interno dell'intervallo di sensibilità di latenza accettabile nel gruppo di origine.

• Affinità di sessione: è possibile configurare l'affinità di sessione per gli host front-end o i domini per garantire che le richieste provenienti dallo stesso utente finale vengano inviate alla stessa origine.

Nota

Il nome dell'endpoint nel livello Frontdoor di Azure Standard e Premium è denominato host front-end in Frontdoor di Azure (versione classica).

Tutte le configurazioni di Frontdoor hanno il monitoraggio dell'integrità back-end e il failover globale istantaneo automatico. Per altre informazioni, vedere Monitoraggio back-end di Frontdoor. Frontdoor di Azure può essere usato con un singolo metodo di routing. A seconda delle esigenze dell'applicazione, è possibile combinare più metodi di routing per creare una topologia di routing ottimale.

Nota

Quando si usa il motore regole di Frontdoor, è possibile configurare una regola per eseguire l'override delle configurazioni di route nel livello Frontdoor di Azure Standard e Premium oppure 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 sostituisce il processo di routing descritto in questo articolo.

Flusso decisionale complessivo

Il diagramma seguente illustra il flusso decisionale complessivo:

I passaggi decisionali sono:

1. Origini disponibili: selezionare tutte le origini abilitate e restituite integre (200 OK) per il probe di integrità.
   • Esempio: si supponga che ci siano sei origini A, B, C, D, E e F, e tra di esse C non integro e E è disabilitato. L'elenco delle origini disponibili è A, B, D e F.
2. Priorità: vengono selezionate le origini con priorità più alta tra quelle disponibili.
   • Esempio: si supponga che l'origine A, B e D abbiano priorità 1 e l'origine F abbia la priorità 2. Le origini selezionate sono quindi 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. Questo segnale si basa sull'impostazione di riservatezza della latenza nel gruppo di origine e sulla latenza delle origini più vicine.
   • Esempio: si supponga che Frontdoor abbia misurato la latenza dall'ambiente in cui la richiesta è arrivata all'origine A a 15 ms, mentre la latenza per B è di 30 ms e D è distante 60 ms. Se la sensibilità alla latenza del gruppo di origine è impostata su 30 ms, il pool di latenza più basso è costituito da origini A e B, perché D è oltre 30 ms di distanza dall'origine più vicina che è A.
4. Pesi: infine, Frontdoor di Azure esegue il round robin del traffico tra il gruppo di origini selezionato finale nel rapporto dei pesi 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 3/10 alle origini A e 7/10 all'origine B.

Se l'affinità di sessione è abilitata, la prima richiesta in una sessione segue il flusso elencato 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 due o più posizioni in tutto il mondo può migliorare la velocità di risposta delle applicazioni instradando il traffico verso la destinazione più vicina agli utenti finali. La latenza è il metodo di routing del traffico predefinito per la configurazione di Frontdoor. Questo metodo di routing inoltra le richieste dagli utenti finali all'origine più vicina dietro Frontdoor di Azure. Questo meccanismo di routing combinato con l'architettura anycast di Frontdoor di Azure garantisce che ogni utente finale ottenga le migliori prestazioni in base alla propria posizione.

L'origine "più vicina" non è necessariamente più vicina come misurata dalla distanza geografica. Frontdoor di Azure determina invece l'origine più vicina misurando la latenza di rete. Altre informazioni sull'architettura di routing di Frontdoor di Azure.

Ogni ambiente Frontdoor misura separatamente la latenza di origine. Ciò significa che utenti diversi in posizioni diverse vengono indirizzati all'origine con le migliori prestazioni per tale ambiente.

Nota

Per impostazione predefinita, la proprietà di riservatezza della latenza è impostata su 0 ms. Con questa impostazione, la richiesta viene sempre inoltrata alle origini e ai pesi disponibili più veloci sull'origine non hanno effetto a meno che due origini non abbiano la stessa latenza di rete.

Routing del traffico basato sulla priorità

Spesso un'organizzazione vuole fornire disponibilità elevata per i propri servizi distribuendo più di un servizio di backup nel caso in cui quello primario sia inattivo. In tutto il settore, questo tipo di topologia è noto anche come distribuzione attiva/standby o attiva/passiva. Il metodo di routing del traffico Priority consente di implementare facilmente questo modello di failover.

L'istanza predefinita di Frontdoor di Azure contiene un elenco di priorità uguale alle origini. Per impostazione predefinita, Frontdoor di Azure invia il traffico solo alle origini con priorità più alta (valore più basso con priorità) come set primario di origini. Se le origini principali non sono disponibili, Frontdoor di Azure instrada il traffico al set secondario di origini (secondo valore più basso per priorità). Se le origini primarie e secondarie non sono disponibili, il traffico passa al terzo e così via. La disponibilità dell'origine si basa sullo stato configurato e sullo stato di integrità dell'origine in corso determinato dai probe di integrità.

Configurazione della priorità per le origini

Ogni origine nel gruppo di origine della configurazione di Frontdoor di Azure ha una proprietà denominata Priority, che può essere un numero compreso tra 1 e 5. Con Frontdoor di Azure è possibile configurare la priorità di origine in modo esplicito usando questa proprietà per ogni origine. Questa proprietà accetta un valore compreso tra 1 e 5, Minore è il valore maggiore della priorità. Le origini possono condividere gli stessi valori di priorità.

Metodo di routing del traffico Ponderato

Il metodo di routing del traffico ponderato consente di distribuire il traffico in modo uniforme o di usare un peso predefinito.

Nel metodo di routing del traffico ponderato si assegna un peso a ogni origine nella configurazione frontdoor di Azure del gruppo di origine. Il peso è un numero intero compreso tra 1 e 1000. Questo parametro usa un peso predefinito pari a 50.

Con l'elenco delle origini disponibili con una sensibilità di latenza accettabile, il traffico viene distribuito con un meccanismo round robin usando il rapporto dei pesi specificati. Se la sensibilità alla latenza viene impostata su 0 millisecondi, questa proprietà non ha effetto a meno che non ci siano due origini con la stessa latenza di rete.

Il metodo "Ponderato" abilita alcuni scenari utili:

• Aggiornamento graduale dell'applicazione: fornisce una percentuale di traffico da instradare a una nuova origine e aumentare gradualmente il traffico nel tempo per portarlo alla pari con altre origini.
• Migrazione dell'applicazione ad Azure: creare un gruppo di origine con origini sia di Azure che esterne. Regolare il peso delle origini per preferire le nuove origini. È possibile impostare gradualmente questa impostazione a partire dalla disabilitazione delle nuove origini, quindi assegnando loro i pesi più bassi, aumentandolo lentamente ai livelli in cui prendono la maggior parte del traffico. Disabilitare infine le origini meno preferite e rimuoverle dal gruppo.
• Espansione del cloud per capacità aggiuntiva: espandere rapidamente una distribuzione locale nel cloud posizionandola dietro Frontdoor. Quando è necessaria capacità aggiuntiva nel cloud, è possibile aggiungere o abilitare altre origini e specificare la parte del traffico verso ogni origine.

Affinità di sessione

Per impostazione predefinita, senza affinità di sessione, Frontdoor di Azure inoltra le richieste provenienti dallo stesso client a origini diverse. Alcune applicazioni con stato o in determinati scenari quando si esegono richieste dallo stesso utente preferiscono la stessa origine per elaborare la richiesta iniziale. La funzionalità di affinità di sessione basata su cookie è utile quando si vuole mantenere una sessione utente nella stessa origine. Quando si usano cookie gestiti con SHA256 dell'URL di origine come identificatore nel cookie, Frontdoor di Azure può indirizzare il traffico da una sessione utente alla stessa origine per l'elaborazione.

L'affinità di sessione può essere abilitata a livello di gruppo di origine nel livello Frontdoor di Azure Standard e Premium e nel livello host front-end in Frontdoor di Azure (versione classica) per ognuno dei domini configurati (o sottodomini). Dopo l'abilitazione, Frontdoor di Azure aggiunge un cookie alla sessione dell'utente. I cookie sono denominati ASLBSA e ASLBSACORS. L'affinità di sessione basata su cookie consente a Frontdoor di identificare utenti diversi anche se dietro lo stesso indirizzo IP, che a sua volta consente una distribuzione più uniforme del traffico tra origini diverse.

La durata del cookie corrisponde a quella della sessione utente, perché Frontdoor attualmente supporta solo i cookie di sessione.

Nota

Indipendentemente dalla posizione in cui è configurata, l'affinità di sessione viene memorizzata 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é lo stesso browser utenti 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 nella risposta, operazione che non può essere eseguita se la risposta è memorizzabile nella cache, in quanto potrebbe compromettere i cookie di altri client che richiedono la stessa risorsa. Per proteggersi da questo problema, l'affinità di sessione non verrà stabilita se l'origine invia una risposta memorizzabile nella cache quando si tenta di eseguire questa operazione. Se la sessione è già stata stabilita, non importa se la risposta dell'origine è memorizzabile nella cache.

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

• La risposta deve includere l'intestazione Cache-Control di no-store.
• Se la risposta contiene un'intestazione Authorization , non deve essere scaduta.
• La risposta è un codice di stato HTTP 302.

Passaggi successivi

• Informazioni su come creare una frontdoor di Azure.
• Informazioni sul funzionamento di Frontdoor di Azure.