Domande frequenti (FAQ) su Gestione traffico

Fondamenti di Gestione traffico

Quale indirizzo IP viene usato da Gestione traffico?

Come spiegato nella sezione Funzionamento di Gestione traffico, Gestione traffico funziona a livello di Domain Name System (DNS). Invia le risposte DNS per indirizzare i client all'endpoint di servizio appropriato. I client si connettono quindi all'endpoint di servizio in modo diretto, senza passare per Gestione traffico.

Gestione traffico non prevede quindi un endpoint o indirizzo IP per la connessione dei client. Se si intende avere un indirizzo IP statico per un servizio, è necessario configurarlo nel servizio, non in Gestione traffico.

Quali tipi di traffico è possibile indirizzare tramite Gestione traffico?

Come spiegato in Funzionamento di Gestione traffico, un endpoint di Gestione traffico può essere qualsiasi servizio con connessione Internet all'interno o all'esterno di Azure. Di conseguenza, Gestione traffico può indirizzare il traffico che ha origine da Internet pubblico a un set di endpoint anch'esso con connessione Internet. In caso di endpoint all'interno di una rete privata, ad esempio una versione interna di Azure Load Balancer, o se gli utenti effettuano richieste DNS da queste reti interne, non è possibile usare Gestione traffico per instradare il traffico.

Gestione traffico supporta sessioni "permanenti"?

Come spiegato nella sezione Modalità di funzionamento di Gestione traffico, Gestione traffico funziona a livello di DNS. Usa le risposte DNS per indirizzare i client all'endpoint di servizio appropriato. I client si connettono all'endpoint di servizio in modo diretto, senza passare per Gestione traffico. Gestione traffico non visualizza quindi il traffico HTTP tra il client e il server.

Inoltre l'indirizzo IP di origine della query DNS ricevuta da Gestione traffico appartiene al servizio DNS ricorsivo e non al client. Il servizio Gestione traffico non può quindi tracciare client singoli e non può implementare sessioni "permanenti". Questa limitazione è comune a tutti i sistemi di gestione del traffico basati su DNS e non è specifica di Gestione traffico.

Quando si usa Gestione traffico, viene visualizzato un errore HTTP. Perché?

Come spiegato nella sezione Modalità di funzionamento di Gestione traffico, Gestione traffico funziona a livello di DNS. Usa le risposte DNS per indirizzare i client all'endpoint di servizio appropriato. I client si connettono quindi all'endpoint di servizio in modo diretto, senza passare per Gestione traffico. Gestione traffico non vede il traffico HTTP tra client e server. Ogni errore HTTP visualizzato proviene quindi dall'applicazione. Per la connessione del client all'applicazione, è necessario che siano stati completati tutti i passaggi di risoluzione DNS. È inclusa qualsiasi interazione di Gestione traffico con il flusso del traffico dell'applicazione.

Eventuali verifiche più approfondite dovranno quindi concentrarsi sull'applicazione.

L'intestazione host HTTP inviata dal browser del client è l'origine dei problemi più comune. Assicurarsi che l'applicazione sia configurata per accettare l'intestazione host corretta per il nome di dominio in uso. Per gli endpoint che usano il Servizio app di Azure, vedere Configurazione di un nome di dominio personalizzato per un'app Web nel servizio app di Azure con Gestione traffico.

Come è possibile risolvere un problema 500 (errore interno del server) quando si usa Gestione traffico?

Se il client o l'applicazione riceve un errore HTTP 500 durante l'uso di Gestione traffico, questo può essere causato da una query DNS non aggiornata. Per risolvere il problema, cancellare la cache DNS e consentire al client di emettere una nuova query DNS.

Quando un endpoint servizio non risponde, i client e le applicazioni che usano tale endpoint non vengono reimpostati finché non viene aggiornata la cache DNS. La durata della cache è determinata dalla "Durata" (TTL) del record DNS. Per altre informazioni, vedere Gestione traffico e cache DNS.

Vedere anche le domande frequenti correlate seguenti in questo articolo:

• Cos'è la durata TTL del DNS e che impatto ha sugli utenti?
• Come impostare una durata TTL maggiore o minore per le risposte di Gestione traffico?
• Come si può verificare il volume delle query destinate al profilo personale?

Qual è l'impatto sulle prestazioni dell'uso di Gestione traffico?

Come spiegato nella sezione Modalità di funzionamento di Gestione traffico, Gestione traffico funziona a livello di DNS. Dal momento che i client si connettono direttamente agli endpoint di servizio, dopo che è stata stabilita la connessione non si verifica alcun impatto sulle prestazioni quando si usa Gestione traffico.

Poiché Gestione traffico si integra con le applicazioni a livello di DNS, richiede l'inserimento di una ricerca DNS aggiuntiva nella catena di risoluzione DN. L'impatto di Gestione traffico sul tempo di risoluzione DNS è minimo. Gestione traffico usa una rete globale di server dei nomi e reti Anycast per garantire che le query DNS vengano sempre indirizzate al server dei nomi più vicino disponibile. Inoltre, la memorizzazione nella cache delle risposte DNS significa che la latenza DNS aggiuntiva associata all'uso di Gestione traffico si applica solo a una frazione di sessioni.

Il metodo Prestazioni instrada il traffico all'endpoint disponibile più vicino. Il risultato della rete è che l'impatto sulle prestazioni complessive associate a questo metodo dovrebbe essere minimo. Un aumento della latenza DNS deve essere compensato da minore latenza di rete all'endpoint.

Quali protocolli di applicazione possono essere usati con Gestione traffico?

Come spiegato nella sezione Modalità di funzionamento di Gestione traffico, Gestione traffico funziona a livello di DNS. Dopo il completamento della ricerca DNS, i client si connettono all'endpoint dell'applicazione direttamente, non tramite Gestione traffico. La connessione può pertanto usare qualsiasi protocollo dell'applicazione. Se come protocollo di monitoraggio si seleziona TCP, i controlli dell'integrità dell'endpoint eseguiti da Gestione traffico non richiedono l'uso dei protocolli dell'applicazione. Se si sceglie di verificare l'integrità usando un protocollo dell'applicazione, l'endpoint deve poter rispondere alle richieste HTTP o HTTPS GET.

È possibile usare Gestione traffico con un nome di dominio di tipo "naked"?

Sì. Per informazioni su come creare un record alias per la radice del nome di dominio e fare riferimento a un profilo di Gestione traffico di Azure, vedere Configurare un record alias per supportare i nomi di dominio della radice con Gestione traffico.

Gestione traffico tiene conto dell'indirizzo della subnet client quando si gestiscono query DNS?

Sì. Oltre all'indirizzo IP di origine della query DNS (in genere l'indirizzo IP del risolutore Domain Name Server), Gestione traffico considera anche l'indirizzo della subnet client se è incluso nella query DNS inviata dal risolutore Domain Name Server che effettua la richiesta per conto dell'utente finale. Questi indirizzi IP vengono usati per ottimizzare metodi di routing geografici, delle prestazioni e della subnet. In particolare RFC 7871 – Client Subnet in DNS Queries (RFC 7871 - Subnet client nelle query DNS) indica un meccanismo di estensione per DNS (EDNS0) che può trasferire l'indirizzo della subnet client dai risolutori che lo supportano.

Cos'è la durata TTL del DNS e che impatto ha sugli utenti?

Quando una query DNS viene ricevuta da Gestione traffico, nella risposta viene impostato un valore chiamato Durata (TTL). Questo valore, espresso in secondi, indica ai resolver DNS a valle il tempo di memorizzazione della risposta nella cache. Sebbene non è garantito che i risolutori DNS memorizzino il risultato nella cache, la memorizzazione consente loro di rispondere a ogni successiva query usando la cache, invece di inoltrare la query ai server DNS di Gestione traffico. Di seguito è illustrato l'impatto sulle risposte:

• Una durata TTL maggiore riduce il numero di query che raggiunge i server DNS di Gestione traffico; ciò contribuisce a ridurre i costi per il cliente, poiché il numero di query gestite incide sulla fatturazione.
• Una durata TTL maggiore può potenzialmente ridurre il tempo necessario per eseguire una ricerca DNS.
• Una durata TTL maggiore implica anche che i dati non riflettono le informazioni di integrità più recenti ottenute da Gestione traffico tramite gli agenti che eseguono il sondaggio.

Come impostare una durata TTL maggiore o minore per le risposte di Gestione traffico?

A livello di singolo profilo, è possibile impostare una durata TTL del DNS minima di 0 secondi e massima di 2.147.483.647 secondi, ovvero l'intervallo massimo conforme a RFC-1035. Una durata TTL pari a 0 indica che i risolutori Domain Name Server a valle non memorizzano nella cache le risposte alle query e che tutte le query vengono ricevute dai server DNS di Gestione traffico per essere risolte.

Come si può verificare il volume delle query destinate al profilo personale?

Una delle metriche fornite da Gestione traffico è costituita dal numero di query cui un profilo risponde. È possibile ottenere queste informazioni tramite un'aggregazione a livello di profilo oppure è possibile suddividerle ulteriormente per visualizzare il volume di query in cui sono stati restituiti endpoint specifici. È anche possibile configurare avvisi per l'invio di notifiche se il volume di risposte delle query soddisfa le condizioni impostate. Per altri dettagli, vedere Traffic Manager metrics and alerts (Metriche e avvisi di Gestione traffico).

Quando si elimina un profilo di Gestione traffico, quanto tempo deve passare prima che il nome del profilo sia disponibile per il riutilizzo?

Quando si elimina un profilo di Gestione traffico, il nome di dominio associato viene riservato per un periodo di tempo. Gli altri profili di Gestione traffico nello stesso tenant possono riutilizzare immediatamente il nome. Tuttavia, un tenant di Azure diverso non può usare lo stesso nome del profilo fino alla scadenza della prenotazione. Questa funzionalità consente di mantenere l'autorità sugli spazi dei nomi distribuiti, eliminando le preoccupazioni che il nome potrebbe essere assunto da un altro tenant.

Ad esempio, se il nome del profilo di Gestione traffico è label1, label1.trafficmanager.net è riservato al tenant anche se si elimina il profilo. Sono riservati anche spazi dei nomi figlio, ad esempio xyz.label1 o 123.abc.label1. Alla scadenza della prenotazione, il nome viene reso disponibile per altri tenant. Il nome associato a un profilo disabilitato è riservato per un periodo illimitato. Per domande sulla durata della prenotazione di un nome, contattare il rappresentante dell'account.

Quale versione di TLS è richiesta da Gestione traffico?

Sebbene l'implementazione delle versioni precedenti di TLS da parte di Microsoft non sia nota per essere vulnerabile, TLS 1.2 e versioni successive offrono una sicurezza migliorata, grazie a funzionalità come Perfect Forward Secrecy e suite di crittografia più avanzate. Per migliorare la sicurezza e fornire la crittografia ottimale per i dati, Traffic Manger richiede interazioni con i servizi da proteggere con Transport Layer Security (TLS) 1.2 o versioni successive prima del 28 febbraio 2025. Il supporto di Gestione traffico per TLS 1.0 e 1.1 terminerà in questa data. Questa data potrebbe essere diversa dalla data di ritiro tls 1.0 e TLS 1.1 a livello di Azure.

Azione consigliata

Per evitare interruzioni del servizio, le risorse che interagiscono con Gestione traffico devono usare TLS 1.2 o versione successiva.

• Se le risorse usano già in modo esclusivo TLS 1.2 o versione successiva, non è necessario eseguire ulteriori azioni.
• Se le risorse hanno ancora una dipendenza da TLS 1.0 o 1.1, eseguirne la transizione a TLS 1.2 o versione successiva entro il 28 febbraio 2025.

Per informazioni sulla migrazione da TLS 1.0 e 1.1 a TLS 1.2, vedere Risoluzione del problema di TLS 1.0.

Metodi geografico di routing del traffico di Gestione traffico

Quali sono alcuni casi di uso in cui il routing geografico è utile?

Il tipo di routing Geografico può essere usato in qualsiasi scenario in cui un cliente di Azure abbia bisogno di distinguere gli utenti in base alle aree geografiche. Ad esempio, tramite il metodo di routing del traffico Geografico è possibile offrire agli utenti di una determinata area un'esperienza utente diversa rispetto a quelli di altre aree. Un altro esempio è la necessità di garantire la conformità con requisiti dei dati locali che richiedono di servire gli utenti di una determinata area solo con gli endpoint di tale area.

Come si decide se è consigliabile usare il metodo di routing relativo alle prestazioni o geografico?

La differenza essenziale tra questi due metodi di routing molto diffusi consiste nel fatto che nel metodo di routing relativo alle prestazioni l'obiettivo principale consiste nell'inviare traffico all'endpoint che può fornire la latenza più bassa al chiamante, mentre nel routing geografico l'obiettivo principale consiste nell'imporre un recinto geografico per i chiamanti, in modo che sia possibile indirizzarli deliberatamente a un endpoint specifico. La sovrapposizione si verifica perché è presente una correlazione tra vicinanza geografica e latenza più bassa, benché ciò non sia sempre vero. È possibile che sia presente un endpoint in un'area geografica diversa che può offrire un'esperienza di latenza migliore per il chiamante e in tale caso il routing relativo alle prestazioni invia l'utente a tale endpoint, ma il routing geografico lo invia sempre all'endpoint mappato per la rispettiva area geografica. Per chiarire meglio, si prenda in considerazione l'esempio seguente. Con il routing geografico è possibile creare mapping non comuni, ad esempio inviando tutto il traffico proveniente dall'Asia a endpoint nell'area Stati Uniti e tutto il traffico proveniente dagli Stati Uniti a endpoint in Asia. In tale caso, il routing geografico esegue deliberatamente esattamente le operazioni configurate e l'ottimizzazione delle prestazioni non viene presa in considerazione.

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

La gerarchia di paese/area geografica utilizzata da Gestione traffico è reperibile qui. La pagina viene aggiornata con ogni modifica apportata, ma è possibile recuperare le stesse informazioni anche a livello programmatico usando l'API REST di Gestione traffico di Azure.

In che modo Gestione traffico determina da dove un utente sta eseguendo una query?

Gestione traffico esamina l'indirizzo IP di origine della query (probabilmente un sistema di risoluzione DNS locale che esegue la query per conto dell'utente) e usa un indirizzo IP interno per eseguire il mapping delle aree al fine di determinare la posizione. Questa mappa viene aggiornata regolarmente per tenere conto delle modifiche di Internet.

È garantito che in ogni caso Gestione traffico determini correttamente l'esatta posizione geografica dell'utente?

No, Gestione traffico non può garantire che l'area geografica che si deduce dall'indirizzo IP di origine di una query DNS corrisponda sempre alla posizione dell'utente, per i motivi seguenti:

• In primo luogo, come indicato nella domanda precedente, l'indirizzo IP di origine visualizzato è quello di un risolutore Domain Name Server che esegue la ricerca per conto dell'utente. La posizione geografica del resolver DNS è un proxy valido per la posizione geografica dell'utente ma può anche essere diversa, a seconda della superficie del servizio resolver DNS e dello specifico servizio resolver DNS che un cliente sceglie di usare. Ad esempio, un cliente che si trova in Malaysia può specificare nelle impostazioni del dispositivo l'uso di un servizio risolutore Domain Name Server il cui server DNS a Singapore potrebbe essere scelto per gestire le risoluzioni di query per l'utente o il dispositivo specifico. In questo caso, Gestione traffico può visualizzare solo l'indirizzo IP del risolutore corrispondente alla località Singapore. Vedere anche le domande frequenti precedenti, disponibili in questa pagina, relative al supporto dell'indirizzo della subnet client.

• In secondo luogo, Gestione traffico usa una mappa interna per tradurre l'indirizzo IP nell'area geografica. Anche se questa mappa viene convalidata e aggiornata in modo continuativo per aumentarne la precisione e tenere conto della natura in costante evoluzione di Internet, è comunque possibile che le informazioni contenute non rappresentino esattamente la posizione geografica di tutti gli indirizzi IP.

Un endpoint deve trovarsi fisicamente nella stessa area di quello con cui è configurato per il routing geografico?

No, il percorso dell'endpoint non impone alcuna restrizione in merito alle aree a cui può essere mappato. Ad esempio è possibile che tutti gli utenti dell'India siano indirizzati a un endpoint dell'area Stati Uniti centrali di Azure.

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

Sì, se il metodo di routing di un profilo non è geografico è possibile usare l'API REST di Gestione traffico di Azure per assegnare aree geografiche agli endpoint del profilo. Per i profili con un tipo di routing non geografico, questa configurazione viene ignorata. Se si cambia un profilo di questo tipo nel tipo a routing geografico in un secondo momento, Gestione traffico userà quei mapping.

Perché si riceve un errore quando si tenta di cambiare il metodo di routing di un profilo esistente in geografico?

Deve esserci almeno un'area mappata per tutti gli endpoint in un profilo con routing geografico. Per convertire un profilo esistente al tipo di routing geografico è innanzitutto necessario associare aree geografiche a tutti gli endpoint tramite l'API REST di Gestione traffico di Azure prima di cambiare il tipo di routing in geografico. Se si usa il portale, eliminare innanzitutto gli endpoint, cambiare il metodo di routing del profilo in geografico e quindi aggiungere gli endpoint con i relativi mapping di area geografica.

Perché è decisamente consigliato che i clienti creino profili nidificati anziché endpoint in un profilo con il routing geografico abilitato?

Un'area può essere assegnata a un solo endpoint all'interno di un profilo se usa il tipo di routing geografico. Se tale endpoint non è un tipo annidato con un profilo figlio collegato, nel caso l'endpoint perdesse l'integrità, Gestione traffico continua a inviare traffico a esso in quanto l'alternativa di non inviare alcun traffico non è migliore. Gestione traffico non esegue il failover su un altro endpoint, anche quando l'area assegnata è "padre" dell'area assegnata all'endpoint non integro. Se, ad esempio, un endpoint che include l'area Spagna viene danneggiato, non si esegue il failover su un altro endpoint a cui è assegnata l'area Europa. Lo scopo di tutto questo è garantire che Gestione traffico rispetti i confini geografici che un cliente ha stabilito nel proprio profilo. Per ottenere il vantaggio del failover su un altro endpoint quando un endpoint perde la sua integrità, è consigliabile assegnare le aree geografiche a profili annidati con più endpoint all'interno invece di singoli endpoint. In questo modo se un endpoint nel profilo figlio annidato non funziona, il traffico può eseguire il failover su un altro endpoint all'interno dello stesso profilo figlio annidato.

Ci sono restrizioni sulla versione API che supporta questo tipo di routing?

Sì, solo l'API versione 2017-03-01 e versioni successive supportano il routing di tipo geografico. Le versioni precedenti dell'API non possono essere usate per creare profili con routing di tipo Geografico o assegnare aree geografiche agli endpoint. Se viene usata una versione precedente dell'API per recuperare i profili da una sottoscrizione di Azure, non vengono restituiti profili con routing di tipo Geografico. Inoltre, quando si usano versioni precedenti dell'API, tutti i profili restituiti che hanno endpoint con un'area geografica assegnata non mostrano l'area geografica assegnata.

Metodo di routing del traffico Subnet di Gestione traffico

Quali sono alcuni casi di uso in cui il routing della subnet è utile?

Il routing della subnet consente di differenziare l'esperienza per gruppi specifici di utenti identificati dall'IP di origine del relativo indirizzo IP delle richieste DNS. Un esempio è la visualizzazione di un contenuto diverso se gli utenti si connettono a un sito Web dalla sede centrale dell'azienda. Un altro esempio può essere limitare gli utenti di alcuni ISP in modo che accedano solo agli endpoint che supportano solo le connessioni IPv4 se la qualità delle prestazioni di tali ISP si riduce quando si usa IPv6.

Un altro motivo per usare il metodo di routing Subnet è la combinazione con altri profili in un set di profili annidati. Ad esempio, se si vuole usare il metodo di routing Geografico per creare un recinto virtuale per gli utenti, ma per un ISP specifico si vuole usare un metodo di routing diverso, è possibile avere un profilo con metodo di routing Subnet come profilo padre ed eseguire l'override di tale ISP in modo da usare un profilo figlio specifico e usare il profilo Geografico standard per tutti gli altri.

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

I dispositivi degli utenti finali usano in genere un risolutore Domain Name Server per eseguire la ricerca DNS per loro conto. L'indirizzo IP in uscita di questi resolver è quello visualizzato da Gestione traffico come indirizzo IP di origine. Inoltre, il metodo di routing Subnet verifica anche se esistono informazioni ECS (Extended Client Subnet) EDNS0 passate con la richiesta. Se le informazioni ECS sono presenti, quello è l'indirizzo usato per determinare il routing. In assenza di informazioni ECS, l'indirizzo IP di origine della query viene usato a scopo di routing.

Come si possono specificare gli indirizzi IP quando si usa il routing Subnet?

Gli indirizzi IP da associare a un endpoint possono essere specificati in due modi. Prima di tutto, è possibile usare la notazione decimale puntata in ottetti con indirizzi di inizio e fine per specificare l'intervallo (ad esempio, 1.2.3.4-5.6.7.8 o 3.4.5.6-3.4.5.6). In secondo luogo, è possibile usare la notazione CIDR per specificare l'intervallo (ad esempio, 1.2.3.0/24). È possibile specificare più intervalli e usare entrambi i tipi di notazione in un intervallo impostato. Si applicano alcune restrizioni.

• Poiché ogni indirizzo IP deve essere mappato solo a un singolo endpoint non è possibile sovrapporre gli intervalli di indirizzi
• L'indirizzo iniziale non può superare l'indirizzo finale
• Per la notazione CIDR, l'indirizzo IP prima di "/" deve essere l'indirizzo dell'intervallo. Ad esempio, 1.2.3.0/24 è valido, ma 1.2.3.4.4/24 NON lo è

Come si può specificare un endpoint di fallback quando si usa il routing Subnet?

In un profilo con il routing di tipo Subnet, se si usa un endpoint senza subnet mappate, qualsiasi richiesta che non corrisponde ad altri endpoint è indirizzata qui. Si consiglia vivamente di avere tale endpoint di fallback nel proprio profilo poiché Gestione traffico restituisce una risposta NXDOMAIN se arriva una richiesta e non viene mappata ad alcun endpoint o se viene mappata a un endpoint ma tale endpoint non è integro.

Cosa accade se un endpoint è disabilitato in un profilo con routing Subnet?

In un profilo con routing Subnet, se è presente un endpoint ma è disabilitato, Gestione traffico si comporta come se tale endpoint e i relativi mapping della subnet non esistessero. Se si riceve una query corrispondente al mapping dell'indirizzo IP e l'endpoint è disabilitato, Gestione traffico restituisce un endpoint di fallback (uno senza mapping). In alternativa, se questo endpoint non è presente, viene restituita una risposta NXDOMAIN.

Metodo di routing del traffico Multivalore di Gestione traffico

Quali sono alcuni casi di uso in cui il routing multivalore è utile?

Il routing multivalore restituisce più endpoint integri in risposta a una singola query. Il vantaggio principale di questo approccio è che, se un endpoint non è integro, il client ha più possibilità di ripetere il tentativo senza effettuare un'altra chiamata DNS, che potrebbe restituire lo stesso valore da una cache upstream. Questo vale per le applicazioni sensibili in termini di disponibilità in cui è opportuno ridurre al minimo il tempo di inattività. Un altro uso del metodo di routing multivalore è se un endpoint è "dual-homed" in entrambi gli indirizzi IPv4 e IPv6 e si vuole assegnare al chiamante le due opzioni tra cui scegliere quando avvia una connessione all'endpoint.

Quanti endpoint vengono restituiti quando si usa il routing multivalore?

È possibile specificare il numero massimo di endpoint da restituire perché il routing multivalore restituisca un numero di endpoint non superiore a quelli integri quando viene ricevuta una query. Il valore massimo possibile per questa configurazione è 10.

Si riceve lo stesso set di endpoint quando si usa il routing multivalore?

Non è possibile garantire che in ogni query venga restituito lo stesso set di endpoint. Questo dipende anche dal fatto che alcuni degli endpoint potrebbero non essere più integri e per questo non verranno inclusi nella risposta

Misurazioni utente reale

Quali sono i vantaggi offerti dall'utilizzo di Misurazioni utente reale?

Quando si usa il metodo di routing basato sulle prestazioni, Gestione traffico seleziona l'area di Azure migliore a cui l'utente finale può connettersi, controllando l'IP di origine e la subnet client EDNS (se passata) e confrontandoli con l'intelligence di latenza di rete gestita dal servizio. La funzionalità Misurazioni utente reale migliora questo scenario facendo in modo che le esperienze della base di utenti finali contribuiscano a questa tabella di latenza e assicurando che la tabella includa adeguatamente le reti degli utenti finali da cui gli utenti finali si connettono ad Azure. In questo modo, si ottiene una maggiore precisione nel routing degli utenti finali.

È possibile usare Misurazioni utente reale con aree non di Azure?

La funzionalità Misurazioni utente finale misura e riporta solo la latenza per raggiungere le aree di Azure. Se si usa il routing basato sulle prestazioni con endpoint ospitati in aree non di Azure, è comunque possibile beneficiare di questa funzionalità facendo in modo che le informazioni di latenza aumentata sull'area di Azure rappresentativa precedentemente selezionata vengano associate a questi endpoint.

Quale metodo di routing trae vantaggio dalla funzionalità Misurazioni utente reale?

Le informazioni aggiuntive ottenute tramite Misurazioni utente reale sono applicabili solo ai profili che usano il metodo di routing basato sulle prestazioni. Il collegamento delle misurazioni utente reale è disponibile da tutti i profili quando viene visualizzato tramite il portale di Azure.

È necessario abilitare Misurazioni utente reale per ogni profilo separatamente?

No, basta abilitare la funzionalità una sola volta per ogni sottoscrizione e tutte le informazioni di latenza misurate e riportate diventano disponibili per tutti i profili.

Come si disattiva Misurazioni utente reale in una sottoscrizione?

È possibile interrompere gli addebiti dei costi relativi a Misurazioni utente reale quando si smette di raccogliere e restituire le misure di latenza dall'applicazione client. Quando il codice JavaScript di misurazione è integrato in pagine Web, ad esempio, è possibile arrestare la funzionalità rimuovendo il codice JavaScript o disattivando la chiamata durante il rendering della pagina.

È inoltre possibile disattivare Misurazioni utente reale eliminando la chiave. Dopo aver eliminato la chiave, tutte le misurazioni inviate a Gestione traffico con tale chiave vengono rimosse.

È possibile usare Misurazioni utente reale con applicazioni client diverse dalle pagine Web?

Sì, Misurazioni utente reale è progettata per inserire i dati raccolti tramite tipi diversi di client utente finale. Queste domande frequenti vengono aggiornate man mano che vengono supportati nuovi tipi di applicazioni client.

Quante misurazioni vengono effettuate ogni volta che viene eseguito il rendering di una pagina Web con Misurazioni utente reale abilitata?

Quando Misurazioni utente reale viene usata con il codice JavaScript di misurazione specificato, ogni rendering di pagina restituisce sei misurazioni. Queste misurazioni vengono quindi riportate al servizio Gestione traffico. L'addebito per questa funzionalità avviene in base al numero di misurazioni indicate al servizio Gestione traffico. Se, ad esempio, l'utente esce dalla pagina Web durante le misurazioni ma prima che queste siano riportate al servizio,tali misurazioni non vengono considerate per la fatturazione.

È presente un ritardo prima dell'esecuzione dello script di Misurazioni utente reale nella pagina Web?

No, non vi sono ritardi programmati prima che lo script venga richiamato.

È possibile usare misurazioni utente reale solo con le aree di Azure che si intende misurare?

No, ogni volta che viene chiamato, lo script di Misurazioni utente reale misura un set di sei aree di Azure determinato dal servizio. Questo set cambia tra una chiamata e l'altra e, quando si verificano tante chiamate, la copertura delle misurazioni spazia tra aree di Azure diverse.

È possibile limitare il numero di misurazioni effettuate a un numero specifico?

Il codice JavaScript di misurazione è integrato nella pagina Web, pertanto si ha il controllo completo su quando iniziare e arrestare l'uso del servizio. Il set di aree viene restituito fino a quando il servizio Gestione traffico riceve una richiesta di misurazione di un elenco di aree di Azure.

È possibile visualizzare le misurazioni effettuate dall'applicazione client nell'ambito di Misurazioni utente reale?

Poiché la logica di misurazione viene eseguita dall'applicazione client, si ha il controllo completo di ciò che accade, inclusa la visualizzazione delle misurazioni di latenza. Gestione traffico non mostra una vista aggregata delle misurazioni ricevute nella chiave collegata alla sottoscrizione in uso.

È possibile modificare lo script di misurazione di Gestione traffico?

È possibile controllare ciò che è integrato nella pagina Web, ma è fortemente sconsigliato modificare lo script di misurazione per garantire che misuri e riporti le latenze correttamente.

Gli altri utenti sono in grado di vedere la chiave di un utente che viene usata con Misurazioni utente reale?

Quando si incorpora lo script di misurazione in una pagina Web, gli altri utenti possono visualizzare lo script e la chiave di Misurazioni utente reale. È tuttavia importante sapere che questa chiave è diversa dall'ID sottoscrizione e viene generata da Gestione traffico per essere usata solo a questo scopo. Il fatto che altri utenti conoscano la chiave di Misurazioni utente reale di un utente non compromette la sicurezza dell'account di Azure che la usa.

È possibile che altri utenti usino la chiave di Misurazioni utente reale di un utente senza autorizzazione?

Benché altri utenti possano usare la chiave dell'utente per inviare informazioni errate ad Azure, la presenza di alcune misurazioni errate non influisce sul routing, in quanto viene preso in considerazione insieme a tutte le altre misurazioni ricevute. Se è necessario modificare le chiavi, è possibile rigenerare la chiave e a quel punto la chiave precedente viene eliminata.

È necessario inserire il codice JavaScript di misurazione in tutte le pagine Web?

Il servizio Misurazioni utente reale diventa più prezioso man mano che il numero delle misurazioni aumenta. Spetta comunque all'utente valutare se è necessario inserirle in tutte le pagine Web o solo in alcune. Si consiglia di iniziare inserendolo nella pagina più visitata, dove si presume che gli utenti vi rimangano per almeno cinque secondi.

Gestione traffico è in grado di identificare le informazioni sugli utenti finali se si usa Misurazioni utente reale?

Quando si usa il codice JavaScript di misurazione fornito, Gestione traffico può vedere l'indirizzo IP del client dell'utente finale e l'indirizzo IP di origine del risolutore Domain Name Server locale usati. Gestione traffico usa l'indirizzo IP del client solo dopo averlo troncato per non consentire l'identificazione dell'utente finale specifico che ha inviato le misurazioni.

La pagina Web che misura con Misurazioni utente reale deve usare Gestione traffico per il routing?

No, non deve necessariamente usare Gestione traffico. Il lato routing di Gestione traffico opera separatamente dal lato Misurazioni utente reale e, sebbene sia molto utile usarli entrambi nella stessa proprietà Web, non è obbligatorio.

È necessario ospitare un qualsiasi servizio nelle aree di Azure da usare con Misurazioni utente reale?

No, non è necessario ospitare alcun componente lato server in Azure perché Misurazioni utente reale funzioni. L'immagine a pixel singolo scaricata dal codice JavaScript di misurazione e il servizio che lo esegue in aree di Azure diverse sono ospitati e gestiti da Azure.

L'utilizzo della larghezza di banda di Azure aumenta quando si usa Misurazioni utente reale?

Come indicato nella risposta precedente, i componenti lato server di Misurazioni utente reale sono di proprietà e gestiti da Azure. Questo significa che l'uso di Misurazioni utente reale non determina un aumento dell'utilizzo della larghezza di banda. Non è incluso alcun utilizzo della larghezza di banda al di fuori di quanto viene addebitato da Azure. La larghezza di banda usata per scaricare solo un'immagine a pixel singolo viene limitata alla misurazione della latenza a un'area di Azure.

Visualizzazione traffico

A cosa serve Visualizzazione traffico?

Visualizzazione traffico è una funzionalità di Gestione traffico che consente di comprendere a fondo gli utenti e le relative esperienze. Usa le query che riceve da Gestione traffico e le tabelle di intelligence di latenza di rete che il servizio gestisce per offrire le informazioni seguenti:

• Le aree in cui si trovano gli utenti che si connettono agli endpoint in Azure.
• Il volume di utenti che si connettono da tali aree.
• Le aree di Azure a cui vengono instradati.
• L'esperienza di latenza degli utenti che indirizza a queste aree di Azure.

Queste informazioni sono disponibili all'utente tramite la sovrapposizione della mappa geografica e viste tabulari nel portale. Sono inoltre disponibili come dati non elaborati da scaricare.

Quali sono i vantaggi dell'utilizzo di Visualizzazione traffico?

Visualizzazione traffico offre una visione complessiva del traffico ricevuto dai profili di Gestione traffico. Può essere usata, in particolare, per comprendere da dove si connette la base utente e, non meno importante, qual è l'esperienza di latenza media. È quindi possibile usare queste informazioni per individuare le aree su cui è necessario concentrarsi, ad esempio, espandendo il footprint di Azure a un'area che può gestire gli utenti con una latenza più bassa. Un'altra informazione che è possibile derivare dall'uso di Visualizzazione traffico riguarda la visualizzazione di modelli di traffico verso aree diverse. Questa informazione può aiutare a prendere decisioni in merito all'aumento o alla diminuzione dell'inventario in quelle aree.

In che modo Visualizzazione traffico differisce dalle metriche di Gestione traffico disponibili tramite Monitoraggio di Azure?

Monitoraggio di Azure aiuta a comprendere, a livello di aggregazione, il traffico ricevuto dal proprio profilo e dai relativi endpoint. Il servizio consente di tenere traccia dello stato di integrità degli endpoint tramite l'esposizione dei risultati del controllo di integrità. Quando occorre andare oltre questi dati e studiare l'esperienza dei propri utenti finali che si connettono ad Azure a livello di area, Visualizzazione traffico è lo strumento giusto.

Visualizzazione traffico usa le informazioni della subnet client EDNS?

Le query DNS gestite da Gestione traffico di Azure considerano le informazioni ECS per aumentare la precisione del routing. Ma durante la creazione del set di dati che mostra da dove gli utenti eseguono la connessione, Visualizzazione traffico usa solo l'indirizzo IP del resolver DNS.

Quanti giorni di dati usa Visualizzazione traffico?

Visualizzazione traffico genera il proprio output elaborando i dati dei sette giorni che precedono quello prima del giorno in cui l'utente visualizza l'output. Si tratta di una finestra mobile e a ogni visita vengono usati i dati più recenti.

In che modo Visualizzazione traffico gestisce gli endpoint esterni?

Quando si usano endpoint esterni ospitati all'esterno di aree di Azure in un profilo di Gestione traffico, è possibile scegliere che venga eseguito il mapping a un'area di Azure che è un proxy per le relative caratteristiche di latenza (che è in effetti necessario se si usa il metodo di routing basato sulle prestazioni). Con questo mapping dell'area di Azure vengono usate le metriche di latenza di quell'area di Azure per generare l'output di Visualizzazione traffico. Se non viene specificata alcuna area di Azure, le informazioni sulla latenza saranno vuote nei dati per quegli endpoint esterni.

È necessario abilitare Visualizzazione traffico per ogni profilo della sottoscrizione?

Durante il periodo di anteprima, Visualizzazione traffico è stato abilitato a livello di sottoscrizione. Tra i miglioramenti che sono stati apportati prima della disponibilità generale, è ora possibile abilitare Visualizzazione traffico a livello di profilo, consentendo un'abilitazione più granulare di questa funzionalità. Per impostazione predefinita, Visualizzazione traffico è disabilitato per un profilo.

Come si disabilita Visualizzazione traffico?

È possibile disabilitare Visualizzazione traffico per qualsiasi profilo con il portale o le API REST.

Come funziona la fatturazione di Visualizzazione traffico?

La determinazione dei prezzi di Visualizzazione traffico è basata sul numero di punti dati usati per creare l'output. L'unico tipo di dati supportato al momento sono le query che vengono ricevute dal proprio profilo. Viene addebitata inoltre solo l'elaborazione eseguita quando Visualizzazione traffico è abilitata. Ciò significa che, se si abilita Visualizzazione traffico per un periodo di tempo specifico in un mese e la si disabilita in altri periodi, vengono considerati per la fatturazione solo i punti dati elaborati mentre la funzionalità era abilitata.

Endpoint di Gestione traffico

È possibile usare Gestione traffico con endpoint di più sottoscrizioni?

L'uso di endpoint di più sottoscrizioni non è possibile con App Web di Azure. Per le app Web di Azure è necessario che ogni nome di dominio personalizzato usato con app Web venga usato solo all'interno di una singola sottoscrizione. Non è possibile usare App Web da più sottoscrizioni con lo stesso nome di dominio.

Per altri tipi di endpoint, è possibile utilizzare Gestione traffico con gli endpoint da più di una sottoscrizione. In Resource Manager è possibile aggiungere endpoint di qualsiasi sottoscrizione a Gestione traffico, purché la persona che configura il profilo di Gestione traffico abbia accesso in lettura all'endpoint. Queste autorizzazioni possono essere concesse tramite il ruolo Controllo degli accessi in base al ruolo di Azure. Gli endpoint di altre sottoscrizioni possono essere aggiunti usando Azure PowerShell o l'interfaccia della riga di comando di Azure.

È possibile usare Gestione traffico con slot di "staging" del servizio cloud?

Sì. Gli slot di "staging" del servizio cloud possono essere configurati come endpoint esterni in Gestione traffico. I controlli di integrità vengono fatturati in base alla tariffa degli endpoint di Azure.

Gestione traffico supporta endpoint IPv6?

Attualmente Gestione traffico non fornisce server dei nomi indirizzabili tramite IPv6. Tuttavia, Gestione traffico può comunque essere usato dai client IPv6 che si connettono agli endpoint IPv6 se il server DNS ricorsivo del client supporta IPv4. Un client non invia richieste DNS direttamente a Gestione traffico. ma usa un servizio DNS ricorsivo. Un client solo IPv6 invia richieste al servizio DNS ricorsivo tramite IPv6. Il servizio ricorsivo deve quindi poter contattare i server dei nomi di Gestione traffico tramite IPv4. Gestione traffico risponde con il nome DNS o l'indirizzo IP dell'endpoint.

È possibile usare Gestione traffico con più app Web nella stessa area?

In genere, Gestione traffico viene usato per indirizzare il traffico ad applicazioni distribuite in aree diverse. Tuttavia, può anche essere usato in un'applicazione che abbia più distribuzioni nella stessa area. Gli endpoint di Azure di Gestione traffico non permettono l'aggiunta di più endpoint di App Web della stessa area di Azure allo stesso profilo di Gestione traffico.

Qual è la procedura per spostare gli endpoint di Azure del profilo di Gestione traffico in un gruppo di risorse o in una sottoscrizione diversi?

Per tenere traccia degli endpoint di Azure associati a un profilo di Gestione traffico vengono usati i relativi ID di risorsa. Quando una risorsa di Azure usata come endpoint (ad esempio, indirizzo IP pubblico, servizio cloud classico, app Web o un altro profilo di Gestione traffico usato con annidamento) viene spostata in un gruppo di risorse o in una sottoscrizione diversi, il relativo ID di risorsa cambia. In questo scenario, è attualmente necessario aggiornare il profilo di Gestione traffico eliminando e riaggiungendo gli endpoint al profilo.

Per altre informazioni, vedere Come spostare un endpoint.

Gestione traffico di Azure supporta i meccanismi di estensione IPv6 per DNS (ECS)?

Gestione traffico di Azure supporta gli indirizzi IPv6 con meccanismi di estensione per DNS (ECS). Ciò significa che quando una query DNS include informazioni ECS, Gestione traffico di Azure può usare l'indirizzo IP di origine all'interno di ECS per prendere decisioni di routing intelligenti.

Il supporto per ECS IPv6 offre diversi vantaggi:

• Localizzazione migliorata: considerando l'indirizzo IPv6 in ECS, Gestione traffico può instradare gli utenti all'endpoint più vicino o più appropriato, migliorando l'esperienza utente con una latenza ridotta.
• Controllo del traffico avanzato: ECS IPv6 consente di prendere decisioni di routing del traffico più granulari, consentendo una migliore gestione del traffico e della distribuzione globali.

Quando si usa ECS IPv6, è importante assicurarsi che gli endpoint siano configurati correttamente per gestire il traffico IPv6. Verificare anche che l'infrastruttura DNS, inclusi i risolutori ricorsivi, sia in grado di gestire le informazioni ECS con indirizzi IPv6.

Monitoraggio degli endpoint di Gestione traffico

Gestione traffico è resiliente rispetto agli errori di area di Azure?

Gestione traffico è un componente fondamentale del recapito di applicazioni a disponibilità elevata in Azure. Per assicurare una disponibilità elevata, Gestione traffico deve garantire un livello estremamente elevato di disponibilità, nonché la resilienza rispetto agli errori di area.

Per impostazione predefinita, i componenti di Gestione traffico resistono sono resilienti agli errori di qualsiasi area di Azure a livello globale. Questa resilienza si applica a tutti i componenti di Gestione traffico: server dei nomi DNS, API, livello di archiviazione e servizio di monitoraggio degli endpoint.

Nel caso improbabile in cui si verifichi l'interruzione di un'intera area di Azure, Gestione traffico deve continuare a funzionare normalmente. Per le applicazioni distribuite in più aree di Azure Gestione traffico consente di indirizzare il traffico alle istanze disponibili delle applicazioni.

In che modo la scelta della posizione del gruppo di risorse si ripercuote su Gestione traffico?

Gestione traffico è un singolo servizio globale. Non funziona a livello di area. La scelta della posizione del gruppo di risorse non è rilevante per i profili di Gestione traffico distribuiti in quel gruppo di risorse.

Azure Resource Manager richiede che tutti i gruppi di risorse specifichino una posizione che determina il percorso predefinito delle risorse distribuite nel gruppo di risorse in questione. Quando si crea un profilo di Gestione traffico, questo viene creato in un gruppo di risorse. Tutti i profili di Gestione traffico usano globale come posizione, ignorando l'impostazione predefinita del gruppo di risorse.

Come si determina lo stato di integrità corrente di ogni endpoint?

Lo stato di monitoraggio corrente di ogni endpoint viene visualizzato nel portale di Azure, insieme al profilo complessivo. Queste informazioni sono anche disponibili con l'API REST di Gestione traffico, i cmdlet PowerShell e l'interfaccia della riga di comando multipiattaforma di Azure.

È anche possibile usare Monitoraggio di Azure per monitorare l'integrità degli endpoint e vedere una rappresentazione visiva dei risultati. Per altre informazioni su Monitoraggio di Azure, vedere la documentazione del Monitoraggio di Azure.

È possibile monitorare gli endpoint HTTPS?

Sì. Gestione traffico supporta il probing su HTTPS. Definire HTTPS come protocollo nella configurazione del monitoraggio.

Gestione traffico non prevede alcuna convalida di certificati, tra cui:

• I certificati sul lato server non vengono convalidati
• I certificati sul lato server SNI non vengono convalidati
• I certificati client non sono supportati

Si usa un indirizzo IP o un nome DNS quando si aggiunge un endpoint?

Gestione traffico supporta l'aggiunta di endpoint usando tre modi per farvi riferimento:

• Come nome DNS
• Come indirizzo IPv4
• Come indirizzo IPv6

Se l'endpoint viene aggiunto come indirizzo IPv4 o IPv6, la risposta della query è di tipo record A o AAAA, rispettivamente. Se l'endpoint è stato aggiunto come nome DNS, la risposta alla query è il tipo di record CNAME. L'aggiunta di endpoint come indirizzo IPv4 o IPv6 è consentita solo se l'endpoint è di tipo Esterno.

Tutti i metodi di routing e le impostazioni di monitoraggio sono supportati dai tre tipi di indirizzamento endpoint.

Quali tipi di indirizzi IP è possibile usare quando si aggiunge un endpoint?

Gestione traffico consente di usare gli indirizzi IPv4 o IPv6 per specificare gli endpoint. Esistono alcune restrizioni elencate di seguito:

• Gli indirizzi che corrispondono a spazi di indirizzi IP privati riservati non sono consentiti. Questi indirizzi includono quelli chiamati in RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 e RFC 5771.
• L'indirizzo IP non deve contenere numeri di porta ( è possibile specificare le porte da usare nelle impostazioni di configurazione del profilo).
• Nessun endpoint nello stesso profilo può avere lo stesso indirizzo IP di destinazione.

È possibile usare tipi di indirizzamento diversi per gli endpoint all'interno di un singolo profilo?

No. Gestione traffico non consente di combinare tipi di indirizzamento degli endpoint all'interno di un profilo, ad eccezione del caso di un profilo con tipo di routing MultiValore in cui è possibile combinare tipi di indirizzamento IPv4 e IPv6.

Cosa accade quando il tipo di record di una query in ingresso è diverso dal tipo di record associato al tipo di indirizzamento degli endpoint?

Quando si riceve una query per un profilo, Gestione traffico per prima cosa individua l'endpoint che deve essere restituito in base al metodo di routing specificato e allo stato di integrità degli endpoint. Quindi esamina il tipo di record richiesto nella query in ingresso e il tipo di record associato all'endpoint prima di restituire una risposta in base alla tabella che segue.

Per i profili con metodo di routing diverso da Multivalore:

Richiesta query in ingresso	Tipo di endpoint	Risposta specificata
QUALSIASI	A / AAAA / CNAME	Endpoint di destinazione
Un	A / CNAME	Endpoint di destinazione
Un	AAAA	NODATA
AAAA	AAAA / CNAME	Endpoint di destinazione
AAAA	Un	NODATA
CNAME	CNAME	Endpoint di destinazione
CNAME	A / AAAA	NODATA

Per i profili con metodo di routing impostato su Multivalore:

Richiesta query in ingresso	Tipo di endpoint	Risposta specificata
QUALSIASI	Combinazione di A e AAAA	Endpoint di destinazione
Un	Combinazione di A e AAAA	Solo endpoint di destinazione di tipo A
AAAA	Combinazione di A e AAAA	Solo endpoint di destinazione di tipo AAAA
CNAME	Combinazione di A e AAAA	NODATA

È possibile usare un profilo con endpoint con indirizzi IPv4 o IPv6 in un profilo annidato?

Sì, è possibile con l'eccezione che un profilo di tipo Multivalore non può essere un profilo padre in un profilo annidato impostato.

L'endpoint dell'applicazione Web è stato interrotto nel profilo di Gestione traffico, ma non si riceve traffico neanche dopo il riavvio. Come si risolve questo problema?

Quando un endpoint dell'applicazione Web di Azure viene interrotto, Gestione traffico non ne verifica più l'integrità e riavvia i controlli di integrità solo quando rileva che l'endpoint è stato riavviato. Per evitare questo ritardo, disabilitare e riabilitare l'endpoint nel profilo di Gestione traffico dopo aver riavviato l'endpoint.

È possibile usare Gestione traffico anche se l'applicazione non supporta HTTP o HTTPS?

Sì. Specificando TCP come protocollo di monitoraggio, Gestione traffico può avviare una connessione TCP e attendere una risposta dall'endpoint. Se l'endpoint risponde alla richiesta di connessione chiedendo di stabilire la connessione entro il periodo di timeout, l'endpoint viene contrassegnato come integro.

Quali sono le risposte specifiche richieste dall'endpoint quando si usa il monitoraggio TCP?

Se si usa il monitoraggio TCP, Gestione traffico avvia un handshake TCP a tre vie, inviando una richiesta SYN all'endpoint sulla porta specificata. Quindi attende la risposta SYN-ACK dall'endpoint per il periodo di tempo specificato nelle impostazioni di timeout.

• Se viene ricevuta una risposta SYN-ACK entro il periodo di timeout specificato nelle impostazioni di monitoraggio, tale endpoint viene considerato integro. Una risposta FIN o FIN-ACK è la risposta prevista da Gestione traffico quando termina regolarmente un socket.
• Se viene ricevuta una risposta SYN-ACK dopo il timeout specificato, Gestione traffico risponde con RST per reimpostare la connessione.

Con quale velocità Gestione traffico sposta gli utenti da un endpoint considerato non integro?

Per controllare il comportamento del profilo di Gestione traffico in caso di failover sono disponibili le impostazioni seguenti:

• È possibile specificare una maggiore frequenza di sondaggio degli endpoint da parte di Gestione traffico impostando l'intervallo di sondaggio su 10 secondi. Ciò assicura che un eventuale endpoint non integro venga rilevato il prima possibile.
• È possibile specificare il tempo di attesa prima della scadenza di una richiesta di controllo di integrità. Il valore di timeout minimo è 5 sec.
• È possibile specificare il numero di errori che può verificarsi prima che l'endpoint sia contrassegnato come non integro. Se il valore specificato è pari a 0, l'endpoint viene contrassegnato come non integro al primo controllo di integrità non riuscito. Usando questo valore minimo, tuttavia, gli endpoint possono risultare esclusi dalla rotazione in caso di problemi temporanei che si verificano al momento dell'esecuzione del sondaggio.
• È possibile impostare la durata TTL della risposta DNS su un valore pari a 0. In questo modo i risolutori Domain Name Server non possono memorizzare la risposta nella cache e ogni nuova query ottiene una risposta che include le informazioni sull'integrità più aggiornate disponibili in Gestione traffico.

Con queste impostazioni Gestione traffico può segnalare i failover entro 10 secondi dal rilevamento della mancata integrità dell'endpoint ed eseguire una query DNS in base al profilo corrispondente.

Come specificare diverse impostazioni di monitoraggio per i diversi endpoint in un profilo?

Le impostazioni di monitoraggio di Gestione traffico sono configurate a livello di profilo. Se è necessario usare un'impostazione di monitoraggio diversa per un unico endpoint, è consigliabile configurare tale endpoint come profilo annidato, con impostazioni di monitoraggio diverse da quelle del profilo padre.

Come si assegnano le intestazioni HTTP ai controlli di integrità di Gestione traffico per gli endpoint?

Gestione traffico consente di specificare intestazioni personalizzate nei controlli di integrità HTTP(S) avviati per gli endpoint. Per specificare un'intestazione personalizzata, è possibile eseguire questa operazione a livello di profilo (applicabile a tutti gli endpoint) o a livello di endpoint. Se un'intestazione viene definita su entrambi i livelli, quella specificata a livello di endpoint sostituisce quella a livello di profilo. Un caso d'uso comune è specificare intestazioni host in modo che le richieste di Gestione traffico possano essere instradate correttamente a un endpoint ospitato in un ambiente multi-tenant. Un altro caso d'uso è identificare le richieste di Gestione traffico dai log delle richieste HTTP(S) di un endpoint

Quali intestazione host viene usata per i controlli di integrità degli endpoint?

Se non viene specificata alcuna impostazione di intestazione host personalizzata, l'intestazione host usata da Gestione traffico è il nome DNS della destinazione dell'endpoint configurata nel profilo, se disponibile.

Quali sono gli indirizzi IP da cui si originano i controlli di integrità?

Vedere questo articolo per informazioni su come recuperare gli elenchi di indirizzi IP da cui possono provenire i controlli di integrità di Gestione traffico. È possibile usare l'API REST, l'interfaccia della riga di comando di Azure o Azure PowerShell per recuperare l'elenco più recente. Verificare gli indirizzi IP elencati per assicurarsi che le connessioni in ingresso da questi indirizzi IP siano consentite agli endpoint per controllarne lo stato di integrità.

Esempio di uso di Azure PowerShell:

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

Qual è il numero di controlli di integrità previsto per un endpoint da parte di Gestione traffico?

Il numero di controlli di integrità eseguiti da Gestione traffico sull'endpoint dipende dagli elementi seguenti:

• Il valore impostato per l'intervallo di monitoraggio; un intervallo inferiore indica un maggior numero di richieste che raggiungono l'endpoint in un determinato periodo di tempo.
• Il numero di posizioni da cui hanno origine i controlli di integrità; gli indirizzi IP da cui possono avere origine tali controlli sono elencati nella domanda precedente.

Come si possono ricevere notifiche se uno degli endpoint risulta inattivo?

Una delle metriche fornite da Gestione traffico è costituita dallo stato di integrità degli endpoint in un profilo. È possibile visualizzare questo scenario come aggregazione di tutti gli endpoint all'interno di un profilo, ad esempio il 75% degli endpoint è integro, oppure a livello di singolo endpoint. Le metriche di Gestione traffico vengono esposte tramite Monitoraggio di Azure ed è possibile usare le rispettive funzionalità di creazione di avvisi per ottenere notifiche in caso di modifica dello stato di integrità dell'endpoint. Per altri dettagli, vedere Metriche e avvisi di Gestione traffico.

Profili annidati di Gestione traffico

Come si configurano i profili nidificati?

I profili annidati di Gestione traffico possono essere configurati usando Azure Resource Manager, le API REST di Azure classico, i cmdlet di Azure PowerShell e i comandi multipiattaforma dell'interfaccia della riga di comando di Azure. Sono supportati anche tramite il nuovo portale di Azure.

Quanti livelli di nidificazione supporta Gestione traffico?

È possibile nidificare i profili fino a 10 livelli. I "cicli" non sono consentiti.

È possibile combinare altri tipi di endpoint con profili figlio nidificati nello stesso profilo di Gestione traffico?

Sì. Non esistono restrizioni sulla modalità di combinazione di tipi diversi di endpoint all'interno di un profilo.

Come viene applicato il modello di fatturazione per i profili nidificati?

L'uso di profili annidati non ha alcun impatto negativo sui prezzi.

La fatturazione di Gestione traffico include due componenti: i controlli dell'integrità degli endpoint e milioni di query DNS.

• Controlli dell'integrità degli endpoint: non è previsto alcun addebito per un profilo figlio configurato come endpoint in un profilo padre. Il monitoraggio degli endpoint nel profilo figlio viene fatturato nel modo consueto.
• Query DNS: ogni query viene conteggiata una sola volta. Una query in un profilo padre che restituisce un endpoint da un profilo figlio viene conteggiata solo per il profilo padre.

Per informazioni dettagliate, vedere la pagina Gestione traffico Prezzi.

I profili nidificati influiscono sulle prestazioni?

No, quando si usano i profili annidati non si verifica alcun impatto sulle prestazioni.

I server dei nomi di Gestione traffico attraversano internamente la gerarchia dei profili durante l'elaborazione di ogni query DNS, in modo che una query DNS inviata a un profilo padre possa ricevere una risposta DNS con un endpoint da un profilo figlio. Viene usato un singolo record CNAME, indipendentemente dal fatto che si usi un profilo singolo o profili annidati. Non è necessario creare un record CNAME per ogni profilo della gerarchia.

In che modo Gestione traffico calcola l'integrità di un endpoint annidato in un profilo padre?

Il profilo padre non esegue i controlli di integrità direttamente sul profilo figlio. L'integrità degli endpoint del profilo figlio viene usata invece per calcolare l'integrità complessiva del profilo figlio Queste informazioni vengono propagate alla gerarchia del profilo annidato per determinare l'integrità dell'endpoint annidato. Il profilo padre usa quindi questa integrità complessiva per determinare se indirizzare il traffico al profilo figlio.

La tabella seguente descrive il comportamento dei controlli dell'integrità di Gestione traffico per un endpoint annidato.

Stato di monitoraggio del profilo figlio	Stato di monitoraggio dell'endpoint padre	Note
Disabilitati. Il profilo figlio è stato disabilitato.	Arrestato	Lo stato dell'endpoint padre è Stopped, non Disabled. Lo Disabled stato è riservato per indicare che l'endpoint è stato disabilitato nel profilo padre.
Degradato. Almeno un endpoint del profilo figlio è in Degraded uno stato.	Online: il numero di Online endpoint nel profilo figlio è almeno il valore di MinChildEndpoints. CheckEndpoint: il numero di Online endpoint più CheckingEndpoint nel profilo figlio è almeno il valore di MinChildEndpoints. Danneggiato: in caso contrario.	Il traffico viene instradato a un endpoint di stato CheckingEndpoint. Se MinChildEndpoints è impostato su un valore troppo elevato, l'endpoint viene sempre danneggiato.
Online. Almeno un endpoint del profilo figlio è uno Online stato. Nessun endpoint è nello Degraded stato .	vedere la descrizione di riportata in precedenza.
CheckingEndpoints. Almeno un endpoint del profilo figlio è CheckingEndpoint. Nessun endpoint è Online o Degraded	Come sopra.
Inattivo. Tutti gli endpoint del profilo figlio sono Disabled o Stoppedoppure questo profilo non ha endpoint.	Arrestato

Perché non è possibile aggiungere gli endpoint di supporto "Extended" di Servizi cloud di Azure al profilo di Gestione traffico?

Per aggiungere endpoint "Extended" del cloud di Azure a un profilo di Gestione traffico, il gruppo di risorse deve essere compatibile con l'API di Gestione dei servizi di Azure. I profili che si trovano nel gruppo di risorse precedente devono rispettare gli standard API ASM, che impediscono l'inclusione di endpoint dell'IP pubblico o endpoint di una sottoscrizione diversa rispetto a quella del profilo. Per risolvere questo problema, è consigliabile spostare il profilo di Gestione traffico e le risorse associate in un nuovo gruppo di risorse compatibile con l'API ASM.

Passaggi successivi:

• Altre informazioni sul monitoraggio degli endpoint e sul failover automaticodi Gestione traffico.
• Altre informazioni sui metodi di routingdi Gestione traffico.