Domande frequenti (FAQ) su Gestione traffico

  • Articolo

Fondamenti di Gestione traffico

Quale indirizzo IP viene usato da Gestione traffico?

Come illustrato in Funzionamento di Gestione traffico, Gestione traffico funziona a livello dns (Domain Name System). 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.

Pertanto, Gestione traffico non fornisce un endpoint o un indirizzo IP a cui i client si connettono. Se si vuole un indirizzo IP statico per il 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. Se si hanno endpoint che si trovano all'interno di una rete privata (ad esempio, una versione interna di Azure Load Balancer) o si hanno utenti che effettuano richieste DNS da tali 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. Pertanto, Gestione traffico non visualizza 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. Pertanto, Gestione traffico non ha modo di tenere traccia dei singoli client e non può implementare sessioni "permanenti". Questa limitazione è comune a tutti i sistemi di gestione del traffico basati su DNS e non è specifica per 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 visualizza 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 eseguire una nuova query DNS.

Quando un endpoint di 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 dal tempo di esecuzione (TTL) del record DNS. Per altre informazioni, vedere Gestione traffico e la cache DNS.

Vedere anche le domande frequenti correlate seguenti in questo articolo:

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. Poiché i client si connettono direttamente agli endpoint di servizio, non si verifica alcun impatto sulle prestazioni quando si usa Gestione traffico una volta stabilita la connessione.

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 "naked"?

Sì. Per informazioni su come creare un record alias per il vertice del nome di dominio per fare riferimento a un profilo di Gestione traffico di Azure, vedere Configurare un record alias per supportare i nomi di dominio apex 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 resolver DNS), Gestione traffico considera anche l'indirizzo della subnet client se è incluso nella query DNS inviata dal resolver DNS che effettua la richiesta per conto dell'utente finale. Questi indirizzi IP vengono usati per ottimizzare metodi di routing geografici, prestazioni e subnet. In particolare, RFC 7871 - Subnet client nelle query DNS fornisce un meccanismo di estensione per DNS (EDNS0) può passare l'indirizzo della subnet client dai resolver 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 i resolver DNS non siano garantiti di memorizzare nella cache questo risultato, la memorizzazione nella cache consente loro di rispondere a qualsiasi query successiva dalla cache invece di passare a Gestione traffico server DNS. 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) superiore indica anche che i dati non riflettono le informazioni sull'integrità più recenti ottenute Gestione traffico tramite i relativi agenti di probe.

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 resolver DNS downstream non memorizzano nella cache le risposte alle query e tutte le query devono raggiungere i server DNS Gestione traffico per la risoluzione.

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, qual è la quantità di tempo 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. Altri profili Gestione traffico nello stesso tenant possono riutilizzare immediatamente il nome. Tuttavia, un tenant di Azure diverso non è in grado di 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 Gestione traffico è label1, label1.trafficmanager.net è riservato per il 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 ad 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.

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é esiste una correlazione tra la prossimità geografica e la latenza inferiore, anche se questo non è sempre vero. Potrebbe esserci un endpoint in un'area geografica diversa che può offrire un'esperienza di latenza migliore per il chiamante e in tal caso il routing delle prestazioni invia l'utente a tale endpoint, ma il routing geografico li invia sempre all'endpoint mappato per l'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 tal caso, il routing geografico esegue intenzionalmente esattamente ciò che è stato configurato per eseguire e l'ottimizzazione delle prestazioni non è una considerazione.

Nota

È possibile che in alcuni scenari siano necessarie sia prestazioni ottimali che funzionalità di routing geografico. Per questi scenari è consigliabile usare i profili annidati. È ad esempio possibile configurare un profilo padre con il routing geografico, in cui tutto il traffico proveniente dall'America del Nord viene inviato a un profilo annidato con endpoint negli Stati Uniti e viene usato il routing relativo alle prestazioni per inviare tale traffico all'endpoint migliore entro tale set.

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

La gerarchia di paese/area geografica utilizzata da Gestione traffico è reperibile qui. Anche se questa pagina viene aggiornata con eventuali modifiche, è anche possibile recuperare le stesse informazioni a livello di codice usando l'API REST 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 deducibile dall'indirizzo IP di origine di una query DNS corrisponda sempre alla posizione dell'utente a causa dei motivi seguenti:

  • Prima di tutto, come descritto nelle domande frequenti precedenti, l'INDIRIZZO IP di origine visualizzato è quello di un resolver DNS 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 Malesia potrebbe specificare nelle impostazioni del dispositivo usa un servizio resolver DNS il cui server DNS a Singapore potrebbe essere selezionato per gestire le risoluzioni di query per tale utente/dispositivo. In tal caso, Gestione traffico può visualizzare solo l'INDIRIZZO IP del resolver che corrisponde alla posizione di 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 regolarmente per aumentarne l'accuratezza e tenere conto della natura in evoluzione di Internet, c'è ancora la possibilità che le nostre informazioni non siano una rappresentazione esatta della posizione geografica di tutti gli indirizzi IP.

È necessario che un endpoint si trovi fisicamente nella stessa area di quella 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 non configurato per eseguire il routing geografico?

Sì, se il metodo di routing di un profilo non è geografico, è possibile usare l'API REST Gestione traffico di Azure per assegnare aree geografiche agli endpoint in tale profilo. Per i profili di 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.

Un'area può essere assegnata a un solo endpoint all'interno di un profilo se usa il metodo di routing geografico. Se l'endpoint non è un tipo annidato con un profilo figlio collegato, se l'endpoint non funziona, Gestione traffico continua a inviare traffico a esso, perché l'alternativa di non inviare traffico non è migliore. Gestione traffico non esegue il failover a un altro endpoint, anche quando l'area assegnata è "padre" dell'area assegnata all'endpoint che non è integro( ad esempio, se un endpoint con area Spagna non è integro, non viene eseguito il failover a un altro endpoint con l'area Europa assegnata. 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 a un altro endpoint quando un endpoint non è integro, è consigliabile assegnare aree geografiche a profili annidati con più endpoint al suo interno anziché a singoli endpoint. In questo modo, se un endpoint nel profilo figlio annidato ha esito negativo, il traffico può eseguire il failover a 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 di tipo di routing 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 viene restituito alcun profilo di tipo di routing geografico. Inoltre, quando si usano le versioni precedenti dell'API, qualsiasi profilo restituito con endpoint con un'assegnazione di area geografica non ha l'assegnazione dell'area geografica.

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 potrebbe limitare gli utenti da determinati ISP ad accedere solo agli endpoint che supportano solo le connessioni IPv4 se tali ISP hanno prestazioni secondarie quando viene usato 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 resolver DNS 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 cerca anche di verificare se sono presenti 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.

  • Non è possibile sovrapporre intervalli di indirizzi perché ogni indirizzo IP deve essere mappato a un solo endpoint
  • L'indirizzo iniziale non può essere più dell'indirizzo finale
  • Per la notazione CIDR, l'indirizzo IP prima di '/' deve essere l'indirizzo di rete di tale intervallo (ad esempio, 1.2.3.0/24 è valido ma 1.2.3.4.4/24 non è valido)

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

In un profilo con routing subnet, se è presente un endpoint senza subnet mappate, tutte le richieste che non corrispondono ad altri endpoint vengono indirizzate qui. È consigliabile disporre di un endpoint di fallback di questo tipo nel profilo perché Gestione traffico restituisce una risposta NXDOMAIN se viene ricevuta una richiesta e non viene mappata ad alcun endpoint o se è 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 si dispone di un endpoint con questa opzione disabilitata, Gestione traffico si comporta come se l'endpoint e i mapping delle subnet non esiste. Se viene ricevuta una query corrispondente al relativo mapping degli indirizzi IP e l'endpoint è disabilitato, Gestione traffico restituisce un endpoint di fallback (uno senza mapping) o se tale endpoint non è presente, restituisce 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. Ciò è applicabile alle applicazioni sensibili alla disponibilità che vogliono ridurre al minimo il tempo di inattività. Un altro uso per il metodo di routing multivalore è se un endpoint è "dual-homed" sia per gli indirizzi IPv4 che per IPv6 e si vuole assegnare al chiamante entrambe le opzioni da 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 e multivalore restituisce non più di quello di molti endpoint 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 lo stesso set di endpoint venga restituito in ogni query. Ciò è influenzato anche dal fatto che alcuni degli endpoint potrebbero non essere integri a quel punto che 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. Misurazioni utente reale migliora questa funzionalità per la base degli utenti finali grazie all'esperienza di questa tabella di latenza oltre a garantire che questa tabella si estende adeguatamente sulle 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 gli endpoint ospitati in aree non di Azure, è comunque possibile trarre vantaggio da questa funzionalità grazie a informazioni a una maggiore latenza sull'area di Azure rappresentativa selezionata per essere associata a questo 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ì, Le misurazioni utente reale sono progettate per inserire i dati raccolti tramite diversi tipi di client dell'utente finale. Queste domande frequenti vengono aggiornate quando 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. Questa funzionalità viene addebitata in base al numero di misurazioni segnalate al servizio Gestione traffico. Ad esempio, se l'utente si allontana dalla pagina Web mentre vengono prese le misurazioni, ma prima che sia stato segnalato, tali misurazioni non vengono considerate a scopo di fatturazione.

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

No, non c'è alcun ritardo programmato 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 richiamato, lo script Misurazioni utente reale misura un set di sei aree di Azure come 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?

La misura JavaScript è incorporata all'interno della pagina Web e si è in controllo completo su quando avviare e interrompere l'uso. Se il servizio di Gestione traffico riceve una richiesta di misurazione di un elenco di aree di Azure, viene restituito un set di aree.

È 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 della latenza. Gestione traffico non segnala una visualizzazione aggregata delle misurazioni ricevute nella chiave collegata alla sottoscrizione.

È possibile modificare lo script di misurazione di Gestione traffico?

Anche se si è sotto il controllo di ciò che è incorporato nella pagina Web, è consigliabile apportare modifiche allo script di misurazione per assicurarsi che misure e segnala correttamente le latenze.

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, è possibile che altri utenti visualizzino lo script e la chiave RUM (Real User Measurements). È tuttavia importante sapere che questa chiave è diversa dall'ID sottoscrizione e viene generata da Gestione traffico da usare solo per questo scopo. Conoscere la chiave RUM non comprometterà la sicurezza dell'account Azure.

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

Anche se è possibile che altri utenti usino la chiave per inviare informazioni errate ad Azure, alcune misurazioni errate non cambieranno il routing perché vengono prese in considerazione insieme a tutte le altre misurazioni ricevute. Se è necessario modificare le chiavi, è possibile rigenerare la chiave in corrispondenza del quale la chiave precedente viene rimossa.

È 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. Detto questo, è la tua decisione per decidere se è necessario inserirla in tutte le pagine Web o selezionare alcuni. 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 viene usata la misura specificata JavaScript, Gestione traffico ha visibilità sull'indirizzo IP client dell'utente finale e sull'indirizzo IP di origine del sistema di risoluzione DNS locale usato. 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 è necessario usare Gestione traffico. Il lato di routing di Gestione traffico opera separatamente dalla parte Misura utente reale e, anche se è una buona idea avere entrambi nella stessa proprietà Web, non è necessario che siano.

È 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 per il funzionamento delle misurazioni utente reale. 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. Ciò significa che l'utilizzo della larghezza di banda di Azure non aumenterà perché si usano misurazioni utente reale. Questo non include alcun utilizzo della larghezza di banda al di fuori degli addebiti di 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:

  • 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 instradate.
  • L'esperienza di latenza degli utenti instradamento 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 consiste nel vedere i modelli di traffico verso aree diverse, che a loro volta consentono di prendere decisioni sull'aumento o la riduzione dell'invento in tali 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 è necessario andare oltre questi e comprendere l'esperienza dell'utente finale che si connette ad Azure a livello di area, è possibile usare Visualizzazione traffico per ottenere questo risultato.

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 crea l'output elaborando i dati dai sette giorni precedenti il giorno prima della visualizzazione da parte dell'utente. Si tratta di una finestra mobile e i dati più recenti vengono usati ogni volta che si visita.

In che modo Visualizzazione traffico gestisce gli endpoint esterni?

Quando si usano endpoint esterni ospitati all'esterno delle aree di Azure in un profilo di Gestione traffico, è possibile scegliere di eseguire il mapping a un'area di Azure, ovvero un proxy per le relative caratteristiche di latenza (questo è effettivamente necessario se si usa il metodo di routing delle prestazioni). Se ha questo mapping di aree di Azure, le metriche di latenza dell'area di Azure vengono usate durante la creazione dell'output di Visualizzazione traffico. Se non viene specificata alcuna area di Azure, le informazioni sulla latenza sono vuote nei dati per tali 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, la visualizzazione traffico è disabilitata per un profilo.

Nota

Se Visualizzazione traffico è stato abilitato a livello di sottoscrizione durante il periodo di anteprima, è ora necessario abilitarlo nuovamente per ogni profilo in tale sottoscrizione.

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. Inoltre, l'elaborazione eseguita è stata fatturata solo quando è abilitata la visualizzazione traffico. 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 da più sottoscrizioni non è possibile con Azure App Web. 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 usare Gestione traffico con endpoint di più sottoscrizioni. 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 usando il 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?

Gestione traffico attualmente non fornisce server dei nomi indirizzabili 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 effettua una richiesta 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 essere in grado di contattare i server dei nomi Gestione traffico usando 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 Gestione traffico non consentono l'aggiunta di più endpoint dell'app Web dalla stessa area di Azure allo stesso profilo di Gestione traffico.

Ricerca per categorie spostare gli endpoint di Azure del profilo di Gestione traffico in un gruppo di risorse o 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 in modo annidato) viene spostata in un gruppo di risorse o una sottoscrizione diversa, l'ID risorsa cambia. In questo scenario, è attualmente necessario aggiornare il profilo di Gestione traffico eliminando e riaggiungendo gli endpoint al profilo.

Per altre informazioni, vedere Per spostare un endpoint.

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 è regionale. 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, 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 può fornire alcuna convalida del certificato, tra cui:

  • I certificati lato server non vengono convalidati
  • I certificati 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 degli endpoint usando tre modi per farvi riferimento: come nome DNS, come indirizzo IPv4 e come indirizzo IPv6. Se l'endpoint viene aggiunto come indirizzo IPv4 o IPv6, la risposta della query è rispettivamente di tipo record A o AAAA. Se l'endpoint è stato aggiunto come nome DNS, la risposta della query è di tipo 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. Di seguito sono elencate alcune restrizioni:

  • Gli indirizzi che corrispondono agli spazi di indirizzi IP privati riservati non sono consentiti. Questi indirizzi includono quelli indicati nelle specifiche RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 e RFC 5771
  • L'indirizzo non deve contenere numeri di porta (è possibile specificare le porte da usare nelle impostazioni di configurazione del profilo)
  • Due endpoint nello stesso profilo non possono 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ì, ad eccezione del fatto che un profilo di tipo MultiValue non può essere un profilo padre in un set di profili annidato.

È stato arrestato un endpoint dell'applicazione Web nel profilo di Gestione traffico, ma non si riceve traffico nemmeno dopo il riavvio. Come si risolve questo problema?

Quando un endpoint dell'applicazione Web di Azure viene arrestato Gestione traffico interrompe il controllo dell'integrità e riavvia i controlli di integrità solo dopo aver rilevato 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 dispone del supporto per 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. Attende quindi una risposta SYN-ACK dall'endpoint per un 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. Fin o FIN-ACK è la risposta prevista dal Gestione traffico quando termina regolarmente un socket.
  • Se viene ricevuta una risposta SYN-ACK dopo il timeout specificato, Gestione traffico risponde con un 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 per quanto tempo attendere prima del timeout di una richiesta di controllo integrità (il valore minimo di timeout è 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 resolver DNS non possono memorizzare nella cache la risposta e ogni nuova query ottiene una risposta che incorpora le informazioni di integrità più aggiornate del 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 è definita a entrambi i livelli, quella specificata a livello di endpoint esegue l'override del livello 1 del profilo. Un caso d'uso comune è specificare le intestazioni host in modo che Gestione traffico richieste vengano indirizzate correttamente a un endpoint ospitato in un ambiente multi-tenant. Un altro caso d'uso consiste nell'identificare le richieste 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à Gestione traffico. È possibile usare l'API REST, l'interfaccia della riga di comando di Azure o Azure PowerShell per recuperare l'elenco più recente. Esaminare 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

Nota

Gli indirizzi IP pubblici possono cambiare senza preavviso. Assicurarsi di recuperare le informazioni più recenti usando l'API individuazione tag del servizio o il file JSON scaricabile.

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. Gestione traffico metriche vengono esposte tramite Monitoraggio di Azure ed è possibile usare le relative funzionalità di avviso per ricevere notifiche quando si verifica una modifica dello stato di integrità dell'endpoint. Per altre informazioni, vedere Gestione traffico metriche e avvisi.

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 la nuova portale di Azure.

Quanti livelli di nidificazione supporta Gestione traffico?

È possibile nidificare i profili fino a 10 livelli. 'Loops' 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?

Non c'è alcun impatto negativo sui prezzi dell'uso di profili annidati.

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

  • Controlli di integrità degli endpoint: non è previsto alcun addebito per un profilo figlio quando è 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, non si verifica alcun impatto sulle prestazioni quando si usano profili annidati.

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 singolo profilo o profili annidati. Non è necessario creare un record CNAME per ogni profilo nella 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 stato Disabilitato è riservato per indicare che l'endpoint è stato disabilitato nel profilo padre.
Danneggiato. Almeno uno degli endpoint del profilo figlio è nello stato Danneggiato. Online: il numero di endpoint Online nel profilo figlio è pari almeno al valore di MinChildEndpoints.
CheckingEndpoint: il numero di endpoint Online e CheckingEndpoint nel profilo figlio è pari almeno al valore di MinChildEndpoints.
Danneggiato: negli altri casi.		 Il traffico viene indirizzato a un endpoint con stato CheckingEndpoint. Se il valore di MinChildEndpoints è troppo elevato, l'endpoint risulta sempre danneggiato.
Online. Almeno uno degli endpoint del profilo figlio è nello stato Online. Nessun endpoint è nello stato Danneggiato. vedere la descrizione di riportata in precedenza.
CheckingEndpoints. Almeno uno degli endpoint del profilo figlio è nello stato CheckingEndpoint. Nessun endpoint è nello stato Online o Danneggiato. Come sopra.
Inattivo. Tutti gli endpoint del profilo figlio sono nello stato Disabilitato o Arrestato oppure si tratta di un profilo senza endpoint. Arrestato

Importante

Quando si gestiscono i profili figlio in un profilo padre in Gestione traffico di Azure, è possibile che si verifichi un problema se si disabilitano simultaneamente e si abilitano due profili figlio. Se queste azioni si verificano contemporaneamente, potrebbe verificarsi un breve periodo quando entrambi gli endpoint sono disabilitati, con conseguente attivazione dello stato compromesso del profilo padre.

Per evitare questo problema, prestare attenzione quando si apportano modifiche simultanee ai profili figlio. Valutare la possibilità di sfalsare queste azioni leggermente per evitare interruzioni impreviste alla configurazione di gestione del traffico.

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

Per aggiungere endpoint estesi cloud di Azure a un profilo di Gestione traffico, il gruppo di risorse deve avere compatibilità 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 o endpoint di indirizzi IP pubblici da 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: