Metodi di routing di Gestione traffico

Gestione traffico di Azure supporta sei metodi di routing del traffico per determinare la modalità di instradamento del traffico di rete ai vari endpoint di servizio. Gestione traffico applica il metodo di routing del traffico associato a qualsiasi profilo a ogni query DNS ricevuta. Il metodo di routing del traffico determina l'endpoint restituito nella risposta DNS.

In Gestione traffico sono disponibili i metodi di routing del traffico seguenti:

• Priorità: selezionare Routing prioritario quando si vuole avere un endpoint di servizio primario per tutto il traffico. È possibile fornire più endpoint di backup nel caso in cui l'endpoint primario o uno degli endpoint di backup non sia disponibile.
• Ponderato: selezionare Routing ponderato quando si vuole distribuire il traffico tra un set di endpoint in base al peso. Impostare lo stesso peso per la distribuzione uniforme tra tutti gli endpoint.
• Prestazioni: selezionare Routing delle prestazioni quando si hanno endpoint in posizioni geografiche diverse e si vuole che gli utenti finali usino l'endpoint "più vicino" per la latenza di rete più bassa.
• Geografico: selezionare Routing geografico per indirizzare gli utenti a endpoint specifici (Azure, Esterno o Annidato) in base alla provenienza geografica delle query DNS. Con questo metodo di routing, consente di essere conformi a scenari come la sovranità dei dati, la localizzazione del contenuto e l'esperienza utente e la misurazione del traffico da aree diverse.
• Multivalore: selezionare Multivalore per i profili di Gestione traffico che possono avere come endpoint solo indirizzi IPv4/IPv6. Quando viene ricevuta una query per profili di questo tipo, vengono restituiti tutti gli endpoint integri.
• Subnet: selezionare Metodo di routing del traffico subnet per eseguire il mapping di set di intervalli di indirizzi IP dell'utente finale a un endpoint specifico. Al ricevimento di una richiesta, verrà restituito l'endpoint mappato per l'indirizzo IP di origine della richiesta. 

Tutti i profili di Gestione traffico prevedono il monitoraggio dell'integrità e il failover automatico degli endpoint. Per altre informazioni, vedere Informazioni sul monitoraggio di Gestione traffico. All'interno di un profilo di Gestione traffico è possibile configurare un solo metodo di routing del traffico alla volta. È possibile selezionare in qualsiasi momento un metodo di routing del traffico diverso per il profilo. Le modifiche verranno applicate entro un minuto senza tempi di inattività. È possibile combinare i metodi di routing del traffico usando i profili di Gestione traffico annidati. I profili di annidamento consentono configurazioni sofisticate di routing del traffico che soddisfano le esigenze di applicazioni più grandi e complesse. Per altre informazioni, vedere nested Traffic Manager profiles(Profili nidificati di Gestione traffico).

Metodo di routing del traffico Priorità

Spesso un'organizzazione vuole fornire affidabilità per i propri servizi. A tale scopo, distribuiscono uno o più servizi di backup in caso di arresto primario. Il metodo di routing del traffico "Priorità" consente ai clienti di Azure di implementare facilmente questo modello di failover.

Il profilo di Gestione traffico contiene un elenco di endpoint del servizio con diverse priorità. Per impostazione predefinita, tutto il traffico viene inviato all'endpoint primario (con priorità più elevata). Se l'endpoint primario non è disponibile, Gestione traffico indirizza il traffico verso il secondo endpoint. In una situazione in cui gli endpoint primari e secondari non sono disponibili, il traffico passa al terzo e così via. La disponibilità dell'endpoint si basa sullo stato configurato (abilitato o disabilitato) e sul monitoraggio degli endpoint in corso.

Configurazione degli endpoint

In Azure Resource Manager la priorità degli endpoint viene configurata in modo esplicito, definendo la proprietà "priority" di ogni endpoint. Questa proprietà accetta un valore compreso tra 1 e 1000, Un valore inferiore rappresenta una priorità più alta. Gli endpoint non possono condividere i valori di priorità. La proprietà è facoltativa e, se viene omessa, viene usata una priorità predefinita in base all'ordine degli endpoint.

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 endpoint come parte della configurazione del profilo di Gestione traffico. Ogni quantità è un numero intero compreso tra 1 e 1000. Il parametro è facoltativo. se omesso, viene usato il valore di peso predefinito "1". Maggiore è il peso, maggiore è la priorità.

Per ogni query DNS ricevuta, Gestione traffico sceglie casualmente un endpoint disponibile. La probabilità di scelta di un determinato endpoint dipende dalle quantità assegnate a tutti gli endpoint disponibili. L'uso dello stesso peso in tutti gli endpoint comporta una distribuzione uniforme del traffico. Se vengono usati pesi superiori o inferiori in specifici endpoint, questi verranno restituiti più o meno frequentemente nelle risposte DNS.

Il metodo "Ponderato" abilita alcuni scenari utili:

• Aggiornamento graduale dell'applicazione: data una percentuale di traffico da instradare a un nuovo endpoint e aumentare gradualmente il traffico nel tempo fino al 100%.
• Migrazione dell'applicazione in Azure: creare un profilo con endpoint di Azure ed esterni. Regolare il peso degli endpoint per preferire i nuovi endpoint.
• Bursting del cloud per una maggiore capacità: espandere rapidamente una distribuzione locale nel cloud inserendola dietro un profilo di Gestione traffico. In caso di necessità di capacità aggiuntiva nel cloud, si possono aggiungere o abilitare più endpoint e si può specificare la quantità di traffico da indirizzare a ogni endpoint.

È possibile configurare i pesi usando l'portale di Azure, Azure PowerShell, l'interfaccia della riga di comando o le API REST.

Un punto da ricordare è che le risposte DNS vengono memorizzate nella cache dai client. Vengono memorizzati nella cache anche dai server DNS ricorsivi usati dai client per risolvere i nomi DNS. Questa memorizzazione nella cache può avere un effetto sulle distribuzioni del traffico ponderate. Se il numero di client e di server DNS ricorsivi è elevato, la distribuzione del traffico funziona come previsto. Se invece il numero di client o di server DNS ricorsivi è limitato, la memorizzazione nella cache può modificare significativamente la distribuzione del traffico.

I casi d'uso comuni in cui può verificarsi questa situazione includono:

• Ambienti di sviluppo e test
• Comunicazioni tra applicazioni
• Applicazioni destinate a una base utenti ristretta che condivide un'infrastruttura DNS ricorsiva comune, ad esempio i dipendenti di un'organizzazione che si connettono tramite proxy.

Questi effetti della memorizzazione nella cache DNS non riguardano solo Gestione traffico di Azure, ma sono comuni a tutti i sistemi di routing del traffico basati su DNS. In alcuni casi, la cancellazione della cache DNS in modo esplicito può risolvere il problema. In caso contrario, potrebbe essere più appropriato un metodo alternativo di routing del traffico.

Metodo di routing del traffico Prestazioni

La distribuzione di endpoint in due o più posizioni in tutto il mondo può migliorare la velocità di risposta delle applicazioni. Con il metodo di routing del traffico "Prestazioni", è possibile instradare il traffico alla posizione più vicina.

L'endpoint "più vicino" non è necessariamente più vicino in base alla distanza geografica. Il metodo di routing del traffico "Prestazioni" determina invece l'endpoint più vicino in termini di latenza di rete. La tabella della latenza di Internet indica il tempo di round trip tra intervalli di indirizzi IP e ciascun data center di Azure.

Gestione traffico individua nella tabella la riga relativa all'indirizzo IP di origine della richiesta DNS in ingresso Gestione traffico quindi sceglie un endpoint disponibile nel data center di Azure con la latenza più bassa per l'intervallo di indirizzi IP. Quindi Gestione traffico restituisce l'endpoint nella risposta DNS.

Come illustrato in Come funziona Gestione traffico, Gestione traffico non riceve query DNS direttamente dai client. Le query DNS provengono invece dal servizio DNS ricorsivo che i client sono configurati per l'uso. Di conseguenza, l'indirizzo IP usato per determinare l'endpoint "più vicino" non è l'indirizzo IP del client, ma è l'indirizzo IP del servizio DNS ricorsivo. Questo indirizzo IP è un buon proxy per il client.

Per adeguarsi alle modifiche nella rete Internet globale e all'aggiunta di nuove aree di Azure, Gestione traffico aggiorna regolarmente la tabella della latenza di Internet usata. Tuttavia, le prestazioni dell'applicazione variano in base alle variazioni del carico in tempo reale registrate in Internet. Il routing del traffico delle prestazioni non monitora il carico in un determinato endpoint di servizio. Se un endpoint non è più disponibile, Gestione traffico non lo includerà nelle risposte alle query DNS.

Punti da notare:

• Se il profilo contiene più endpoint nella stessa area di Azure, il traffico indirizzato all'area in questione viene distribuito in modo uniforme tra gli endpoint disponibili nell'area. Se si preferisce una distribuzione del traffico diversa all'interno di un'area, usare i profili annidati di Gestione traffico.
• Se tutti gli endpoint abilitati nell'area di Azure più vicina sono danneggiati, Gestione traffico sposta il traffico sugli endpoint nella successiva area di Azure più vicina. Se si preferisce definire una sequenza di failover, usare i profili annidati di Gestione traffico.
• Quando si usa il metodo di routing del traffico "Prestazioni" con endpoint esterni o endpoint annidati, è necessario specificare la posizione di tali endpoint. Scegliere l'area di Azure più vicina alla distribuzione specifica. Si tratta delle posizioni supportate dalla tabella della latenza di Internet.
• L'algoritmo che sceglie l'endpoint è deterministico. Le query DNS ripetute dallo stesso client vengono indirizzate allo stesso endpoint. Quando viaggiano, i client solitamente usano server DNS ricorsivi diversi, e possono pertanto essere indirizzati a un endpoint differente. Il routing potrebbe inoltre risentire degli aggiornamenti della tabella della latenza di Internet. Ecco perché il metodo di routing del traffico Prestazioni non garantisce che un client venga sempre indirizzato allo stesso endpoint.
• Quando viene aggiornata la tabella della latenza di Internet, è possibile notare che alcuni client vengono indirizzati a un endpoint diverso. Questa modifica di routing è più precisa in base ai dati di latenza correnti. Questi aggiornamenti sono essenziali per garantire la precisione del routing del traffico Prestazioni man mano che Internet si evolve.

Metodo di routing del traffico Geografico

Gestione traffico profili possono essere configurati per l'uso del metodo di routing geografico in modo che gli utenti vengano indirizzati a endpoint specifici: Azure, Esterno o Annidato. La corrispondenza si basa sulla posizione geografica da cui proviene la query DNS. Con questo metodo di routing, consente di rispettare i requisiti di sovranità dei dati, la localizzazione del contenuto e l'esperienza utente e la misurazione del traffico da aree diverse. Quando un profilo è configurato per il routing geografico, ogni endpoint associato al profilo deve avere un set di aree geografiche assegnate. Un'area geografica può avere i seguenti livelli di granularità

• Mondo: qualsiasi area
• Raggruppamento di aree: ad esempio Africa, Medio Oriente, Australia/Pacifico e così via.
• Paese/area geografica: ad esempio Irlanda, Perù, Regione amministrativa speciale di Hong Kong e così via.
• Stato/Provincia: ad esempio Stati Uniti-California, Australia-Queensland, Canada-Alberta e così via. Si noti che questo livello di granularità è supportato solo per gli stati e/o le province di Australia, Canada e Stati Uniti.

Quando un'area o un set di aree viene assegnato a un endpoint, tutte le richieste provenienti da tali aree vengono instradate solo a tale endpoint. Gestione traffico usa l'indirizzo IP di origine della query DNS per determinare l'area da cui un utente esegue una query. Comunemente trovato come indirizzo IP del resolver DNS locale che effettua la query per l'utente.

Gestione traffico legge l'indirizzo IP di origine della query DNS e decide da quale area geografica proviene. Viene quindi verificato se è presente un endpoint con questa area geografica mappata. Questa ricerca inizia al livello di granularità più basso (prima in Stato/Provincia in cui è supportato, accanto al livello Paese/Area geografica) e va fino al livello più alto, ovvero World. La prima corrispondenza trovata usando questo attraversamento viene scelta come endpoint da restituire nella risposta della query. Quando una query corrisponde a un endpoint di tipo annidato, viene restituito un endpoint all'interno di tale profilo figlio, in base al relativo metodo di routing. I punti seguenti sono applicabili a questo comportamento:

• Un'area geografica può essere mappata a un solo endpoint in un profilo di Gestione traffico quando il tipo di routing è quello geografico. Questa restrizione garantisce che il routing degli utenti sia deterministico e che i clienti possano abilitare scenari che richiedono limiti geografici non ambigui.

• Se l'area geografica di un utente è elencata in due diversi mapping geografico degli endpoint, Gestione traffico seleziona l'endpoint con la granularità più bassa. Gestione traffico non considererà il routing delle richieste da tale area all'altro endpoint. Ad esempio, si consideri un profilo con il tipo di routing geografico e con due endpoint: Endpoint1 ed Endpoint2. L'Endpoint1 è configurato per ricevere il traffico dall'Irlanda e l'Endpoint2 è configurato per ricevere il traffico dall'Europa. Se una richiesta proviene dall'Irlanda, viene sempre instradata a Endpoint1.

• Poiché è possibile eseguire il mapping di un'area a un solo endpoint, Gestione traffico restituisce una risposta indipendentemente dal fatto che l'endpoint sia integro o meno.

  Importante

  È consigliabile che i clienti usino il metodo di routing geografico associato con endpoint di tipo nidificato e profili figlio contenenti almeno due endpoint ciascuno.

• Se viene trovata una corrispondenza di endpoint e l'endpoint è nello stato Arrestato, Gestione traffico restituisce una risposta NODATA. In questo caso, non vengono eseguite ulteriori ricerche più in alto nella gerarchia dell'area geografica. Questo comportamento è applicabile anche per i tipi di endpoint annidati quando il profilo figlio è nello stato Arrestato o Disabilitato.

• Se un endpoint si trova nello stato Disabilitato, non sarà incluso nel processo di ricerca di corrispondenza dell'area. Questo comportamento si applica anche per i tipi di endpoint annidati quando l'endpoint si trova nello stato Disabilitato.

• Se una query proviene da un'area geografica che non ha alcun mapping in quel profilo, Gestione traffico restituisce una risposta NODATA. Ecco perché è consigliabile usare il routing geografico con un endpoint. Idealmente di tipo Annidato con almeno due endpoint all'interno del profilo figlio, con l'area Geografica assegnata. Questa configurazione garantisce anche che tutti gli indirizzi IP non mappati a un'area vengano gestiti.

Come illustrato in Come funziona Gestione traffico, Gestione traffico non riceve query DNS direttamente dai client. Le query DNS provengono dal servizio DNS ricorsivo che i client sono configurati per l'uso. Ecco perché l'indirizzo IP usato per determinare l'area non è l'indirizzo IP del client, ma piuttosto l'indirizzo IP del servizio DNS ricorsivo. Questo indirizzo IP è un buon proxy per il client.

Domande frequenti

• Quali sono alcuni casi d'uso in cui il routing geografico è utile?

• Ricerca per categorie decidere se usare il metodo di routing Prestazioni o il metodo di routing geografico?

• Quali sono le aree supportate da Gestione traffico per il routing geografico?

• In che modo Gestione traffico determina da dove un utente esegue query?

• È garantito che Gestione traffico possa determinare correttamente la posizione geografica esatta dell'utente in ogni caso?

• È necessario che un endpoint si trovi fisicamente nella stessa area di quella con cui è configurato per il routing geografico?

• È possibile assegnare aree geografiche agli endpoint in un profilo non configurato per eseguire il routing geografico?

• Perché viene visualizzato un errore quando si tenta di modificare il metodo di routing di un profilo esistente in Geografico?

• Perché è consigliabile che i clienti creino profili annidati anziché endpoint in un profilo con routing geografico abilitato?

• Esistono restrizioni per la versione dell'API che supporta questo tipo di routing?

Metodo di routing del traffico Multivalore

Il metodo di routing del traffico Multivalore consente di ottenere più endpoint integri in un'unica risposta a una query DNS. Questa configurazione consente al chiamante di eseguire nuovi tentativi sul lato client con altri endpoint nel caso in cui un endpoint restituito non risponda. Questo modello può aumentare la disponibilità di un servizio e ridurre la latenza associata a una nuova query DNS per ottenere un endpoint integro. Il metodo di routing Multivalore funziona solo se tutti gli endpoint di tipo Esterno sono specificati come indirizzi IPv4 o IPv6. Quando si riceve una query per profili di questo tipo, tutti gli endpoint integri vengono restituiti e sono soggetti a un numero massimo di restituzioni configurabili.

Domande frequenti

• Quali sono alcuni casi d'uso in cui è utile il routing multivalore?

• Quanti endpoint vengono restituiti quando viene usato il routing multivalore?

• Si otterrà lo stesso set di endpoint quando viene usato il routing multivalore?

Metodo di routing del traffico Subnet

Il metodo di routing del traffico subnet consente di eseguire il mapping di un set di intervalli di indirizzi IP dell'utente finale a endpoint specifici in un profilo. Se Gestione traffico riceve una query DNS per tale profilo, esamina l'indirizzo IP di origine di tale richiesta. Determinerà quindi l'endpoint a cui è mappato e restituirà l'endpoint nella risposta alla query. Nella maggior parte dei casi, l'indirizzo IP di origine è il resolver DNS usato dal chiamante.

L'indirizzo IP di cui eseguire il mapping a un endpoint può essere specificato come intervalli CIDR (ad esempio, 1.2.3.0/24) o come intervallo di indirizzi (ad esempio, 1.2.3.4-5.6.7.8). Gli intervalli IP associati a un endpoint devono essere univoci all'interno di tale profilo. L'intervallo di indirizzi non può avere una sovrapposizione con il set di indirizzi IP di un endpoint diverso nello stesso profilo. Se si definisce un endpoint senza intervallo di indirizzi, funziona come fallback e accetta il traffico da tutte le subnet rimanenti. Se non è incluso alcun endpoint di fallback, Gestione traffico invia una risposta NODATA per tutti gli intervalli non definiti. È consigliabile definire un endpoint di fallback per assicurarsi che tutti gli intervalli IP possibili vengano specificati tra gli endpoint.

È possibile usare il metodo di routing Subnet per offrire un'esperienza diversa per gli utenti che si connettono da uno spazio di IP specifico. Ad esempio, è possibile inviare tutte le richieste dell'ufficio aziendale a un endpoint diverso. Questo metodo di routing è particolarmente utile se si sta provando a testare una versione interna solo dell'app. Un altro scenario può essere quello in cui si vuole offrire un'esperienza diversa agli utenti che si connettono da un ISP specifico, ad esempio per bloccare gli utenti di un determinato ISP.

Domande frequenti

• Quali sono alcuni casi d'uso in cui il routing della subnet è utile?

• In che modo Gestione traffico conosce l'indirizzo IP dell'utente finale?

• Come è possibile specificare gli indirizzi IP quando si usa il routing subnet?

• Come è possibile specificare un endpoint di fallback quando si usa il routing subnet?

• Cosa accade se un endpoint è disabilitato in un profilo del tipo di routing subnet?

Passaggi successivi

Informazioni su come sviluppare applicazioni a disponibilità elevata tramite Informazioni sul monitoraggio di Gestione traffico