Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Azure Traffic Manager spiegato: bilanciamento del carico DNS, 6 metodi di routing e failover automatico (Doppiaggio IA)

Transcript

Azure Traffic Manager spiegato: bilanciamento del carico DNS, 6 metodi di routing e failover automatico (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Siete pronti per 10 giorni di Microsoft 365, Copilot EA,
0:04
Speaker 2: Azure per le persone che stanno plasmando il futuro del lavoro? Eh.
0:08
Speaker 2: Questo gennaio, M365 con ritorne e puntiamo ancora più in alto?
0:12
Speaker 2: Unitevi a noi per sessioni dal vivo, demo concrete e
0:15
Speaker 2: conoscenze pratiche condivise da MVP ed esperti del settore da
0:17
Speaker 2: tutto il mondo. Niente slide generiche, niente gergo infinito. Affronteremo
0:22
Speaker 2: le sfide reali. Copilot Studio, agenti IAA Fabric, Sicurezza, Governance
0:27
Speaker 2: e Automazione. Che siate professionisti IT, sviluppatori o leader aziendali,
0:32
Speaker 2: ci sono sessioni pensate apposta per voi. Con 10 giorni
0:36
Speaker 2: interi potrete esplorare diverse tecnologie e connettervi con una community globale.
0:40
Speaker 2: Seguite le dirette e portate intuizioni pratiche nella vostra organizzazione.
0:45
Speaker 2: Gennaio 2027, 10 giorni, un'unica community Microsoft. Le registrazioni sono
0:50
Speaker 2: ora aperte. Andate su m365con. net e assicuratevi il vostro posto
0:55
Speaker 2: oggi stesso. Il sito m365con. net... Iscrivetevi ora su m365con. net e
1:03
Speaker 2: ci vedremo dal vivo a gennaio. Benvenuti a un altro
1:06
Speaker 2: episodio di Microsoft Knowledge Nuggets. Sono il vostro conduttore Emil Coppi.
1:09
Speaker 2: L'argomento di oggi è Azure Traffic Manager. Immaginate di aver
1:12
Speaker 2: creato un'app web che persone di tutto il mondo vogliono utilizzare.
1:15
Speaker 2: Utenti a Tokyo, Londra, San Paolo, tutti cercano di raggiungere
1:17
Speaker 2: la vostra app contemporaneamente. Ma ecco il problema. Ognuno di
1:21
Speaker 2: questi utenti si collega a un server in una singola regione,
1:23
Speaker 2: diciamo in Virginia... L'utente a Tokyo attende oltre 200 millisecondi
1:27
Speaker 2: per richiesta e quella a San Paolo ha un'esperienza ancora peggiore?
1:29
Speaker 2: Ha un'esperienza. Se quel data center in Virginia dovesse guastarsi
1:33
Speaker 2: per un'interruzione di corrente, un taglio di rete o qualcosa
1:35
Speaker 2: di imprevisto, l'intera app va offline. Ogni utente ovunque si
1:38
Speaker 2: trovi è un singolo punto di guasto o problema. Quindi
1:40
Speaker 2: cosa succederebbe se poteste indirizzare automaticamente ogni utente verso il
1:43
Speaker 2: server più vicino e veloce e sano? Cosa succederebbe se
1:45
Speaker 2: un utente a Tokyo fosse servito da un data center
1:47
Speaker 2: in Giappone? Un utente a Londra e dall'Irlanda e se
1:50
Speaker 2: una regione andasse giù e il traffico si spostasse altrove
1:52
Speaker 2: senza che voi dobbiate fare nulla? È esattamente ciò che
1:55
Speaker 2: fa Agile Traffic Manager e lo fa a livello DNS,
1:57
Speaker 2: che significa che è più semplice di quanto pensiate. Alla
2:00
Speaker 2: fine di questo episodio capirete cos'è davvero Traffic Manager, come
2:03
Speaker 2: funzionano i suoi sei metodi di routing e quando usare
2:05
Speaker 2: ciascuno di essi. Prendete il vostro caffè. Perché il routing
2:09
Speaker 2: del traffico globale è importante? Analizziamo le dettagli. Molti sentono
2:12
Speaker 2: parlare di bilanciamento del carico e pensano a un singolo
2:14
Speaker 2: server che distribuisce il traffico su alcune macchine all'interno di
2:16
Speaker 2: un solo dataset. Questo è Azure Road Balancer e funziona
2:19
Speaker 2: benissimo per una singola regione. Ma cosa succede quando i
2:21
Speaker 2: vostri utenti sono sparsi tra i continenti? Un utente in
2:23
Speaker 2: Giappone che acceda a un server in Virginia non otterrà
2:26
Speaker 2: mai una risposta rapida. La fisica di internet semplicemente non
2:29
Speaker 2: lo permette. La luce viaggia a una velocità fissa e
2:32
Speaker 2: ogni passaggio di rete aggiunge ritardo. Non puoi risolverlo con
2:36
Speaker 2: un codice migliore o un servizio più veloce. Punto che
2:38
Speaker 2: le app land perdono utenti. Un secondo di ritardo riduce
2:40
Speaker 2: le conversioni del 7% e un'interruzione regionale. Non rallenta solo
2:44
Speaker 2: le cose e manda offline l'intera app. I tuoi utenti
2:47
Speaker 2: non possono raggiungerti, i ricavi si fermano e la tua
2:49
Speaker 2: reputazione ne risente. Vent'anni fa il vecchio approccio consisteva nel
2:52
Speaker 2: costruire server in ogni regione e indirizzare manualmente gli utenti
2:55
Speaker 2: verso quello giusto. Aggiornavi il record DNS a mano, gestivi
2:59
Speaker 2: i fogli di calcolo su chi andava dove e pregavi
3:01
Speaker 2: di non commettere errori durante un failover. Quell'approccio è impraticabile
3:04
Speaker 2: e fragile perché non è scalabile e si rompe sotto pressione.
3:08
Speaker 2: Il nuovo approccio è un unico gestore del traffico basato
3:10
Speaker 2: su DNS che sceglie il migliore endpoint per utente, per richiesta.
3:13
Speaker 2: Non richiede aggiornamenti manuali nei fragili fogli di calcolo. Invece
3:17
Speaker 2: controlla dove si trova l'utente, verifica quali endpoint sono sani
3:19
Speaker 2: e restituisce quello migliore. Immaginalo come un sistema globale di
3:23
Speaker 2: controllo del traffico aereo in cui ogni data center è
3:25
Speaker 2: un aeroporto e Traffic Manager è la torre di controllo
3:27
Speaker 2: che dirige ogni utente al server disponibile più vicino. È
3:30
Speaker 2: qui che entra in gioco Traffic Manager. Quindi parliamo di
3:32
Speaker 2: cosa sia effettivamente e di cosa sia realmente Traffic Manager.
3:35
Speaker 2: Ecco la definizione più semplice. Traffic Manager è un bilanciatore
3:38
Speaker 2: di carico basato su DNS che opera su scala globale.
3:40
Speaker 2: Immaginalo come una reception intelligente all'ingresso di un edificio per
3:43
Speaker 2: ufficio mondiale. Quando entri l'addetto alla reception non gestisce le
3:46
Speaker 2: tue telefonate né sbriga le tue pratiche. Ti indica semplicemente
3:49
Speaker 2: il piano giusto. Questo è tutto ciò che fa Traffic Manager.
3:52
Speaker 2: Indirizza gli utenti verso il server giusto. Ecco la distinzione fondamentale.
3:55
Speaker 2: Traffic Manager non vede mai il tuo traffico effettivo, non
3:58
Speaker 2: fa da proxy le richieste, non ispeziona i pacchetti né
4:00
Speaker 2: memorizza i contenuti. Quando un utente digita il tuo nome
4:03
Speaker 2: di dominio nel suo browser, viene inviato una query DNS.
4:05
Speaker 2: Traffic Manager risponde a quella query con l'indirizzo IP del
4:08
Speaker 2: miglior endpoint, quello più vicino, quello più sano, quello che
4:11
Speaker 2: hai configurato come priorità. Quindi l'utente si connette direttamente a
4:14
Speaker 2: quell'endpoint e Traffic Manager si toglie completamente di mezzo. Ciò
4:18
Speaker 2: significa che aggiunge zero latenza al percorso del traffico, perché
4:21
Speaker 2: non essendo nel mezzo del flusso di dati non può
4:22
Speaker 2: rallentare le cose. Funziona anche con qualsiasi endpoint esposto su internet,
4:26
Speaker 2: servizi Azure, server in un altro cloud e persino con
4:29
Speaker 2: il tuo data center locale. Finché l'endpoint ha un indirizzo
4:32
Speaker 2: più pubblico o un nome di dominio, Traffic Manager può
4:34
Speaker 2: indirizzarvi il traffico. E poiché è un servizio globale, resiliente
4:37
Speaker 2: ai guasti regionali, Se un'intera regione Azure va offline, Traffic
4:41
Speaker 2: Manager continua a funzionare e in strada gli utenti verso
4:43
Speaker 2: endpoint sanno altrove. Quindi come fa Traffic Manager a sapere
4:46
Speaker 2: quali endpoint sono sano? Li sonda ogni 30 secondi per
4:49
Speaker 2: impostazione predefinita, inviando una richiesta HTTP o HTTPS a un
4:52
Speaker 2: percorso specifico su ogni endpoint. Se l'endpoint risponde con un
4:55
Speaker 2: codice di stato 200 entro il timeout è considerato sano.
4:59
Speaker 2: Se non risponde per diverse volte di fila, Traffic Manager
5:01
Speaker 2: lo marca come degradato e smette di inviarvi gli utenti.
5:04
Speaker 2: Quando l'endpoint si riprende, Traffic Manager lo rileva e lo
5:07
Speaker 2: reinserisce nella rotazione e Questo monitoraggio dello stato è ciò
5:10
Speaker 2: che rende possibile il failover automatico. Ora vediamo i diversi
5:13
Speaker 2: modi in cui Traffic Manager decide a quale endpoint inviare
5:16
Speaker 2: gli utenti. È qui che entra in gioco il metodo
5:18
Speaker 2: di routing. Routing con priorità, disaster recovery reso semplice. Il
5:23
Speaker 2: routing con priorità è il metodo più semplice da comprendere.
5:25
Speaker 2: Si classificano gli endpoint da uno a quanti se ne
5:27
Speaker 2: hanno a disposizione. Tutto qui. Tutto il traffico viene inviato
5:30
Speaker 2: alla priorità 1. Se quell'endpoint fallisce, il traffico passa alla
5:32
Speaker 2: priorità 2, poi alla 3 e così via lungo l'elenco.
5:34
Speaker 2: È una configurazione di tipo attivo passivo. L'endpoint gestisce tutto,
5:37
Speaker 2: gli altri restano in attesa. Ecco un esempio reale. Supponiamo
5:42
Speaker 2: che i server primari siano in East US e che
5:43
Speaker 2: abbiate un backup in West Europe. Impostate East US come
5:47
Speaker 2: priorità 1, West Europe come priorità 2. In condizioni normali,
5:50
Speaker 2: ogni utente va verso East US. Ma quando East US
5:53
Speaker 2: ha un'interruzione, magari un blackout o un problema di rete,
5:55
Speaker 2: Traffic Manager lo rileva in pochi secondi. Smette di inviare
5:58
Speaker 2: nuovi utenti a East US e inizia a reindirizzarli verso
6:00
Speaker 2: West Europe. La vostra app resta online e gli utenti
6:03
Speaker 2: potrebbero nemmeno accoggersi di noi. Ora c'è un dettaglio importante
6:06
Speaker 2: da considerare. Gli utenti esistenti mantengono la loro condizione attuale.
6:09
Speaker 2: Il routing basato su DNS influisce solo sulle nuove ricerche
6:11
Speaker 2: di app. Quindi se qualcuno ha già caricato la vostra
6:13
Speaker 2: app e ha una sessione attiva, continuerà ad accedere all'endpoint
6:15
Speaker 2: originale finché non termina o la cache DNS scade. Ecco
6:18
Speaker 2: perché consiglio di impostare un TTL NS basso da 30
6:21
Speaker 2: a 60 secondi in intervalli. Un TTL basso significa che
6:24
Speaker 2: i risolveri DNS controllano gli aggiornamenti più frequentemente. Di conseguenza,
6:27
Speaker 2: quando Traffic Manager cambia endpoint, la modifica si propaga più velocemente.
6:30
Speaker 2: Un errore comune che molti commettono è dimenticare di testare
6:32
Speaker 2: il failover. Si imposta il routing con priorità, si distribuisce
6:35
Speaker 2: la regione di backup e poi si dà per scontato
6:36
Speaker 2: che funziona. via il punto in alto la vostra regione
6:38
Speaker 2: di backup deve essere in grado di gestire l'intero carico
6:41
Speaker 2: se il tuo sistema primario gestisce un milione di utenti
6:43
Speaker 2: al giorno e il backup ne gestisce solo 100.000 quest'ultimo
6:45
Speaker 2: potrebbe crollare quando tutto quel traffico si sposterà improvvisamente su
6:49
Speaker 2: di esso testa il tuo failover simula davvero un'interruzione e
6:53
Speaker 2: osserva cosa succede la priorità serve a mantenere attiva la
6:57
Speaker 2: tua app durante i guasti ma come renderla veloce per tutti?
7:00
Speaker 2: routing basato sulle prestazioni la velocità sopra ogni cosa il
7:03
Speaker 2: routing basato sulle prestazioni funziona diversamente dal routing a priori
7:06
Speaker 2: Invece di dire usa sempre prima questo endpoint, dice invia
7:09
Speaker 2: ogni utente all'endpoint che gli offre la connessione più veloce.
7:12
Speaker 2: Così un utente a Tokyo viene indirizzato a un server
7:14
Speaker 2: in gioco, un utente a Londra viene indirizzato in Irlanda,
7:16
Speaker 2: un utente a San Paolo viene indirizzato in Brasile. Ogni
7:19
Speaker 2: utente ottiene l'esperienza più veloce possibile ovunque si trovi. Come
7:22
Speaker 2: fa Traffic Manager a sapere quale endpoint è il più veloce?
7:25
Speaker 2: Usa una tabella di latenza Internet. Immaginava come una mappa
7:28
Speaker 2: che Azure mantiene aggiornata. Traccia l'effettiva latenza di rete tra
7:31
Speaker 2: diverse parti del mondo e ogni regione Azure. Quando arriva
7:35
Speaker 2: una query DNS, Traffic Manager controlla dove si trova il
7:38
Speaker 2: resolver DNS dell'utente, consulta la tabella di latenza e restituisce
7:42
Speaker 2: l'endpoint con la latenza minore. Ora ecco qualcosa che può sorprenderti.
7:46
Speaker 2: Non si basa sulla distanza fisica. Un utente in India
7:49
Speaker 2: potrebbe avere una latenza inferiore verso gli Stati Uniti orientali
7:51
Speaker 2: rispetto al sud- est asiatico a seconda di come i cavi
7:53
Speaker 2: sottomarini instradano il traffico in quel momento. La tabella di
7:57
Speaker 2: latenza cattura le condizioni reali della rete, non solo la
7:59
Speaker 2: distanza in linea retta. Quindi l'endpoint più vicino non è
8:02
Speaker 2: sempre quello geograficamente più prossimo. Il routing basato sulle prestazioni,
8:06
Speaker 2: perfetto per app globali dove l'esperienza utente dipende dalla velocità,
8:10
Speaker 2: siti e- commerce, streaming video, strumenti di collaborazione in tempo reale,
8:13
Speaker 2: tutto ciò in cui una risposta lenta significa un utente perso.
8:15
Speaker 2: Ma c'è un limite. Non considera quanto carico ogni endpoint
8:18
Speaker 2: stia già gestendo. Se la tua regione Stati Uniti Orientali
8:21
Speaker 2: gira al 95% e quella Europa Occidentale al 20%, il
8:24
Speaker 2: routing basato sulle prestazioni potrebbe comunque inviare nuovi utenti agli
8:26
Speaker 2: Stati Uniti Orientali perché la latenza è più bassa per loro.
8:28
Speaker 2: Non è a conoscenza del carico sui tuoi server. Quindi
8:30
Speaker 2: solitamente combini il routing basato sulle prestazioni con altri bilanciatori
8:33
Speaker 2: di carico all'interno di ogni regione come Azure Load Balancer
8:36
Speaker 2: o Application Gateway per gestire la distribuzione del traffico tra
8:38
Speaker 2: i tuoi server una volta che l'utente è arrivato nella
8:40
Speaker 2: regione giusta. Il routing basato sulle prestazioni ottimizza la velocità.
8:44
Speaker 2: Ma cosa succede se devi controllare quanto traffico riceve ogni endpoint?
8:48
Speaker 2: Routing ponderato e geografico, controllo e conformità. Quindi il routing
8:51
Speaker 2: basato sulle prestazioni riguarda la velocità. Ma cosa succede se
8:54
Speaker 2: vuoi controllare esattamente quanto traffico riceve ogni endpoint? Vuoi indirizzare
8:57
Speaker 2: gli utenti in base alla loro posizione nel mondo? È
8:59
Speaker 2: qui che entra in gioco il routing ponderato e quello geografico.
9:02
Speaker 2: Iniziamo con il routing ponderato. È esattamente quello che sembra.
9:05
Speaker 2: Assegni un peso ogni endpoint, un numero compreso tra 1
9:08
Speaker 2: e 1000. Traffic Manager distribuisce quindi il traffico proporzionalmente in
9:12
Speaker 2: base a tali pesi. Quindi se hai l'endpoint A con
9:14
Speaker 2: peso 80 e l'endpoint B con peso 20, circa l'80%
9:18
Speaker 2: di utenti viene inviato ad A e il 20% a B,
9:21
Speaker 2: calcoli semplici. Ora, perché dovresti farlo? Pensa a un rilascio Canary.
9:25
Speaker 2: Hai creato una nuova versione della tua app e vuoi
9:27
Speaker 2: testarla con utenti reali prima di distribuirla a tutti. Imposti
9:30
Speaker 2: un secondo endpoint con la nuova versione, gli assegni un
9:32
Speaker 2: peso di 5 e dai al tuo endpoint di produzione
9:35
Speaker 2: attuale un peso di 95. Il 5% dei tuoi utenti
9:38
Speaker 2: accede alla nuova versione. Controlli eventuali errori, monitori le prestazioni e,
9:41
Speaker 2: se tutto va bene, aumenti lentamente il peso sulla nuova versione,
9:44
Speaker 2: a livello del 20% la prossima settimana, poi al 50%,
9:46
Speaker 2: poi al 100%. Se qualcosa va storto, riporti il peso
9:48
Speaker 2: a zero e il problema viene contenuto. Niente distribuzioni massicce,
9:51
Speaker 2: niente ripristini di una versione difettosa davanti a tutti gli utenti.
9:54
Speaker 2: Lo stesso principio si applica ai test B. Vuoi vedere
9:56
Speaker 2: se una nuova funzionalità migliora coinvolgimento? Invia metà degli utenti
9:59
Speaker 2: alla versione A e metà alla versione B usando pesi uguali.
10:02
Speaker 2: Confronta i risultati. Oppure stai migrando gli utenti da una
10:04
Speaker 2: regione all'altra. Sposta gradualmente il peso dalla vecchia regione a
10:07
Speaker 2: quella nuova, nel corso di alcune settimane. C'è però qualcosa
10:10
Speaker 2: di importante da capire. Il routine ponderato non è un round- robin.
10:13
Speaker 2: Non alterna tra gli endpoint una richiesta alla volta e
10:16
Speaker 2: una distribuzione statistica. Su un gran numero di richieste il
10:19
Speaker 2: traffico si divide secondo i tuoi pesi. Tuttavia, un singolo
10:22
Speaker 2: utente che effettua più richieste potrebbe continuare ad accedere allo
10:24
Speaker 2: stesso endpoint perché il suo resolver DNS memorizza il risultato.
10:28
Speaker 2: Quindi non pensalo come un bilanciamento del calcolo. Consideralo come
10:30
Speaker 2: il controllo della proporzione complessiva di traffico nel tema. Ora
10:33
Speaker 2: parliamo del routing geografico. Questo indirizza gli utenti in base
10:36
Speaker 2: al luogo di origine della loro query DNS, paese, continente
10:39
Speaker 2: o una regione specifica. Quindi un utente in Germania viene
10:42
Speaker 2: indirizzato al tuo endpoint a Francoforte. Un utente in Brasile
10:44
Speaker 2: viene indirizzato al tuo endpoint a San Paolo. Questo è
10:47
Speaker 2: il livello di granularità. Perché dovresti usarlo? La sovranità dei
10:50
Speaker 2: dati è un aspetto importante. Le normative dell'Unione Europea potrebbero
10:52
Speaker 2: richiedere che i dati degli utenti rimangano in Europa. Il
10:54
Speaker 2: routing geografico consente di imporlo a livello DNS. Un utente
10:57
Speaker 2: dalla Francia risolve il tuo dominio e il traffic manager
11:00
Speaker 2: restituisce l'indirizzo IP del tuo endpoint europeo. I loro dati
11:03
Speaker 2: non lasciano mai il continente. Lo stesso vale per i
11:05
Speaker 2: contenuti localizzati. Se vuoi che gli utenti in Giappone vedano
11:07
Speaker 2: una versione in lingua giapponese del tuo sito, il routing
11:09
Speaker 2: geografico li invia all'endpoint che serve quel contenuto. C'è una
11:12
Speaker 2: regola fondamentale che devi conoscere. Ogni regione geografica deve essere
11:15
Speaker 2: associata a un solo endpoint. Non puoi dividere un singolo
11:18
Speaker 2: paese tra due endpoint. Quindi, se hai utenti in Germania
11:21
Speaker 2: e vuoi che il 50% vada a Francoforte e il
11:23
Speaker 2: 50% a Berlino, non puoi farlo solo con il routing geografico.
11:26
Speaker 2: Dovresti invece utilizzare un profilo nidificato. I profili nidificati sono
11:29
Speaker 2: esattamente come suggeriscono. Inserisci un profilo traffic manager nell'altro. Quindi,
11:33
Speaker 2: a livello superiore, usi il routing geografico per inviare gli
11:35
Speaker 2: utenti europei a un profilo, quelli nordamericani a un altro,
11:38
Speaker 2: e così via. Poi, all'interno di ciascuno di quei profili,
11:40
Speaker 2: usi il routing ponderato per suddividere il traffico tra gli
11:42
Speaker 2: endpoint all'interno di quella regione. Geografico in alto per la
11:45
Speaker 2: conformità apponderata all'interno per il controllo. È una combinazione potente.
11:49
Speaker 2: Altri due metodi di routing gestiscono scenari più specifici. Vediamoli.
11:53
Speaker 2: Routing multivalore per subnet per un controllo più granulare. Il
11:56
Speaker 2: routing multivalore è un trucco semplice e molto. Invece di
11:59
Speaker 2: restituire un solo endpoint nella risposta DNS, il Traffic Manager
12:02
Speaker 2: rimanda indietro più indirizzi IP integri contemporaneamente. Il tuo browser
12:06
Speaker 2: o app sceglie il primo della lista distribuendo il carico
12:08
Speaker 2: senza che il Traffic Manager debba decidere per ogni richiesta.
12:11
Speaker 2: Ma c'è una clausola. Il multivalore funziona solo con endpoint
12:14
Speaker 2: IPv4 e IPv6, quindi non puoi usarlo con servizi app,
12:18
Speaker 2: servizi cloud o qualsiasi endpoint che utilizzi un nome di
12:20
Speaker 2: dominio invece di un indirizzo IP. È esclusivamente per endpoint
12:23
Speaker 2: basati su IP. Tuttavia, quando li hai, rende il sistema
12:26
Speaker 2: più resiliente perché se un IP fallisce, client può provarne
12:28
Speaker 2: un altro dalla lista senza eseguire una nuova ricerca DNS.
12:31
Speaker 2: Ciò significa un failover più rapido al lato client. Il
12:34
Speaker 2: routing per subnet è ancora più di nicchio, ma potente
12:36
Speaker 2: quando serve. Indirizza gli utenti in base alla subnet IP
12:39
Speaker 2: di origine da cui proviene la loro query DNS. Quindi
12:41
Speaker 2: puoi mappare l'intervallo IP dell'ufficio della tua azienda su un
12:43
Speaker 2: endpoint di staging mentre tutti gli altri ottengono la versione
12:46
Speaker 2: di produzione. Oppure puoi instradare gli utenti da una specifica
12:48
Speaker 2: subnet VPN a un backend dedicato per i test. Immagina
12:52
Speaker 2: uno scenario di test interno in cui il tuo team
12:54
Speaker 2: di sviluppo lavora dall'ufficio. Le loro query DNS provengono dall'intervallo
12:58
Speaker 2: IP aziendale e tu mappi quell'intervallo su un ambiente di
13:01
Speaker 2: staging dove possono testare l'ultima build. Tutti gli altri su
13:04
Speaker 2: internet ottengono la versione di produzione. Nessun URL speciale, nessuna
13:07
Speaker 2: configurazione VPN, solo routing trasparente basato sulla provenienza della richiesta.
13:11
Speaker 2: Entrambe questi metodi sono nicchia. La maggior parte delle versioni
13:13
Speaker 2: utilizzerà priorità prestazioni pesato o geografico per la gestione del
13:16
Speaker 2: traffico principale. Tuttavia, multivalore e subnet sono disponibili quando servono
13:20
Speaker 2: e risolvono problemi che gli altri metodi non possono gestire.
13:22
Speaker 2: Monitoraggio dello stato e failover in pratica. Tutti questi metodi
13:25
Speaker 2: di routing dipendono da una cosa, sapere quali endpoint sono
13:27
Speaker 2: effettivamente sali. Inviare traffico a un server non funzionante non
13:30
Speaker 2: aiuta nessuno. Quindi parliamo di come funziona il monitoraggio dello
13:33
Speaker 2: stato in pratica. Traffic Manager invia una sonda di stato
13:36
Speaker 2: a ogni endpoint ogni 30 secondi per impostazione predefinita e
13:39
Speaker 2: tale sonda è una richiesta HTTP o HTTPS verso un
13:41
Speaker 2: percorso specifico sul tuo endpoint. Si aspetta una risposta con
13:44
Speaker 2: un codice di stato tra 200 e 299 entro un
13:47
Speaker 2: certo periodo di timeout. Se l'endpoint risponde correttamente è considerato san.
13:51
Speaker 2: In caso contrario Traffic Manager riprova. Dopo un numero configurabile
13:54
Speaker 2: di fallimenti di default 3, Traffic Manager contrassegna l'endpoint come
13:58
Speaker 2: degradato e lo esclude dal routing finché non supera di
14:00
Speaker 2: nuovo i controlli di stato. È possibile configurare l'intervallo di
14:03
Speaker 2: sondaggio al timeout. Sonde più frequenti significano febbraio. Se imposti
14:06
Speaker 2: l'intervallo a 10 secondi invece di 30, Traffic Manager rileva
14:09
Speaker 2: i guasti prima e reindirizza il traffico più velocemente. Tuttavia,
14:13
Speaker 2: sonde più veloci caricano maggiormente i tuoi endpoint, poiché ogni
14:15
Speaker 2: sonda è una richiesta che il server deve gestire. Quindi
14:18
Speaker 2: se hai mediai endpoint e sondaggi ogni 10 secondi, le
14:20
Speaker 2: richieste si accumulano. È necessario bilanciare la velocità rispetto al sovraccarico.
14:24
Speaker 2: Il vero impatto di una corretta configurazione dei controlli di
14:27
Speaker 2: stato sta nella differenza tra un failover fluido e un
14:29
Speaker 2: falso allarme che interrompe il routing. Se la sonda è
14:32
Speaker 2: troppo sensibile, potresti contrassegnare un endpoint come degradato quando in
14:35
Speaker 2: realtà è a posto. Un picco temporaneo di latenza, un
14:38
Speaker 2: breve problema di rete, una query lenta al database, tutto
14:41
Speaker 2: ciò potrebbe innescare un falso positivo. Quando Traffic Manager smette
14:44
Speaker 2: di inviare utenti a quell'endpoint, hai appena creato un'interruzione che
14:47
Speaker 2: non era necessaria. Ecco un errore comune. Molti impostano il
14:50
Speaker 2: percorso di sondaggio alla radice dell'applicazione solo con uno slash.
14:53
Speaker 2: Può andare bene per un controllo base, ma non è
14:55
Speaker 2: l'ideale poiché la pagina principale potrebbe caricarsi lentamente se renderizza
14:59
Speaker 2: l'intera pagina con query al database, immagini e javascript. Un
15:03
Speaker 2: approccio migliore è creare un endpoint dedicato per il controllo
15:05
Speaker 2: dello stato, qualcosa di leggero. Un endpoint semplice che restituisca
15:07
Speaker 2: rapidamente un codice di stato 200 e un codice di
15:09
Speaker 2: stato 200 confermando che l'applicazione è in funzione. Nessuna query
15:12
Speaker 2: al database, nessuna elaborazione pesante, solo un battito cardinale. In
15:15
Speaker 2: questo modo le tue sonde sono veloci, affidabili e meno
15:17
Speaker 2: soggette a falsi allarmi. Concludo spiegando quando usare davvero Traffic
15:21
Speaker 2: Manager rispetto ad altre opzioni Conclusione e guida decisionale. Ecco
15:26
Speaker 2: un rapido ripido. Traffic Manager è un gestore di traffico
15:28
Speaker 2: globale basato su DNS con 6 metodi di routing. Non
15:31
Speaker 2: gestisce direttamente il tuo traffico. Indirizza solo gli utenti verso
15:34
Speaker 2: la destinazione corretta in base al metodo scelto. Il routing
15:37
Speaker 2: con priorità serve per il disastro. Mantiene l'app attiva anche
15:40
Speaker 2: se un'intera regione va offline. Il routing basato sulle prestazioni
15:43
Speaker 2: punta tutto sulla velocità. Invia ogni utente al endpoint con
15:46
Speaker 2: la latenza più bassa. Il routing ponderato permette rilasci controllati
15:50
Speaker 2: come canary release o A- B testing. Il routing geografico gestisce
15:54
Speaker 2: la conformità. Mantieni i dati nella regione corretta in base
15:57
Speaker 2: alla posizione dei tuoi utenti. Multivalore serve per una semplice
16:00
Speaker 2: distribuzione IP su più indirizzi. E routing per subnet in strada,
16:04
Speaker 2: in base all'IP sorgente della query DNS. Ora parliamo di
16:07
Speaker 2: dove si inserisce Traffic Manager in un'architettura reale.