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 diversi metodi di routing del traffico per determinare la modalità di distribuzione del traffico HTTP/HTTPS tra origini diverse. Quando le richieste dell’utente raggiungono le posizioni sull’edge di Frontdoor, viene applicato il metodo di routing configurato per garantire che le richieste vengano inoltrate alla risorsa di back-end migliore.

Nota

In questo articolo, con origine e gruppo di origine si intende il back-end e il 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 assicura che le richieste vengano inviate all’origine con la latenza più bassa accettabile all'interno di un intervallo di sensibilità. 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: è possibile assegnare valori ponderati alle varie origini quando si vuole distribuire il traffico tra un set di origini, in modo uniforme o in base a 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 o i domini front-end per garantire che le richieste dello stesso utente finale vengano inviate alla stessa origine.

Nota

Nome dell'endpoint nel livello Frontdoor di Azure Standard e Premium viene chiamato 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 immediato automatizzato. Per altre informazioni, vedere Monitoraggio del back-end 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 Frontdoor, è possibile configurare una regola per ignorare le configurazioni di route nel livello 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 sostituisce il processo di routing descritto in questo articolo.

Flusso decisionale generale

Il diagramma seguente illustra il flusso di lavoro complessivo:

I passaggi decisionali sono:

1. Origini disponibili: selezionare tutte le origini abilitate e restituite come integre (200 OK) per il probe di integrità.
   • Esempio: supponiamo che siano presenti sei origini A, B, C, D, E e F, tra le quali C non è integro ed E è disabilitato. L'elenco delle origini disponibili è A, B, D e F.
2. Priorità: vengono quindi selezionate le origini prioritarie 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 nell'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 eseguirà il round robin del traffico tra il gruppo selezionato finale di origini nel rapporto di 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 velocità di risposta di molte applicazioni può essere migliorata distribuendo le origini in due o più posizioni a livello globale e indirizzando il traffico alla posizione 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, in combinazione con l'architettura Anycast di Frontdoor di Azure, questo approccio assicura che ognuno degli utenti finali ottenga le migliori prestazioni in base alla posizione.

L’origine più vicina non è necessariamente la più vicina in termini di distanza geografica. Frontdoor di Azure determina invece l’origine più vicina misurando la latenza di rete. 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à

Un'organizzazione vuole spesso offrire una disponibilità elevata per i propri servizi dotandosi di uno o più servizi di backup in caso di inattività del servizio primario. A livello di settore, questo tipo di topologia è anche denominata distribuzione attiva/standby o attiva/passiva. Il metodo di routing del traffico Priorità permette di implementare facilmente questo modello di failover.

Il sistema Frontdoor di Azure predefinito contiene un elenco con uguale priorità delle origini. Per impostazione predefinita, Frontdoor di Azure invia il traffico solo alle origini con la massima priorità (il valore più basso nella priorità), ovvero il set primario di origini. Se le origini primarie non sono disponibili, Frontdoor di Azure instrada il traffico al set secondario di origini (il secondo valore più basso per la priorità). Se le origini primarie e secondarie non sono disponibili, il traffico viene indirizzato al terzo e così via. La disponibilità dell’origine si basa sullo stato configurato (abilitato o disabilitato) e lo stato di integrità dell’origine, determinato continuamente tramite i probe di integrità.

Configurazione della priorità per le origini

Ogni origine nel gruppo di origini della configurazione di Frontdoor di Azure include una proprietà denominata Priorità, che può essere un numero compreso tra 1 e 5. Con il servizio Frontdoor di Azure, è possibile configurare la priorità dell’origine in modo esplicito usando questa proprietà per ogni origine. Questa proprietà accetta un valore compreso tra 1 e 5, Più è basso il numero, maggiore sarà la priorità. Le origini non possono avere lo stesso valore di priorità.

Metodo di routing del traffico Ponderato

Il metodo di routing del traffico Ponderato consente di distribuire il traffico tra tutti gli endpoint in modo uniforme o con un peso predefinito.

Nel metodo di routing del traffico ponderato viene assegnato un peso a ogni origine nella configurazione di Frontdoor di Azure del gruppo di origini. 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 che hanno una sensibilità di latenza accettabile, il traffico viene distribuito con un meccanismo round robin nel rapporto dei pesi specificati. Se la sensibilità di latenza è impostata su 0 millisecondi, questa proprietà non avrà effetto a meno che non siano disponibili 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 indirizzare a una nuova origine, quindi incrementare gradualmente il traffico nel tempo per portarlo al livello degli altri back-end.
• Migrazione dell'applicazione in Azure: creare un gruppo di origini con origini di Azure ed esterne. Regolare il peso delle origini in modo da preferire quelle nuove. È possibile applicare questa configurazione gradualmente, iniziando con le nuove origini disabilitate, quindi assegnando loro i pesi più bassi e aumentandoli lentamente fino ai livelli di massimo traffico. È infine possibile disabilitare le origini con preferenza inferiore e rimuoverli dal gruppo.
• Espansione del cloud per capacità aggiuntiva: espandere rapidamente una distribuzione locale nel cloud posizionandola dietro Frontdoor. In caso di necessità di capacità aggiuntiva nel cloud, si possono aggiungere o abilitare più origini e si può specificare la quantità di traffico da indirizzare a ogni origini.

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 eseguono richieste dallo stesso utente preferiscono la stessa origine per elaborare la richiesta iniziale. La funzionalità affinità di sessione basata su cookie è utile quando si vuole mantenere una sessione utente nella stessa origine, come situazioni in cui i clienti eseguono l’autenticazione verso l’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). Una volta abilitato, 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 i diversi utenti, anche se usano lo stesso indirizzo IP, permettendo una distribuzione più uniforme del traffico tra origini differenti.

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 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 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 questa situazione, 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 dall’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 nessun archivio.
• 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 un profilo Frontdoor di Azure.
• Informazioni sul funzionamento di Frontdoor di Azure.