Risoluzione dei problemi di prestazioni di rete

Panoramica

Azure offre un modo stabile e rapido per connettere la rete locale ad Azure. Metodi come VPN da sito a sito ed ExpressRoute vengono usati correttamente dai clienti di piccole e grandi dimensioni per eseguire le attività di business in Azure. Ma cosa succede quando le prestazioni non sono all'altezza delle aspettative o delle esperienze passate? Questo articolo consente di standardizzare il modo in cui si testa e si fa riferimento all'ambiente specifico.

Si apprenderà come testare in modo semplice e coerente la latenza e larghezza di banda di rete tra due host. Vengono inoltre forniti alcuni consigli su come esaminare la rete di Azure per isolare i punti di problema. Lo script e gli strumenti PowerShell presentati richiedono due host sulla rete (su ciascuna estremità del collegamento sottoposto a test). Uno degli host deve avere Windows Server o Windows Desktop, l'altro può avere Windows o Linux.

Componenti di rete

Prima di approfondire la risoluzione dei problemi, esaminiamo alcuni componenti e termini comuni. Attraverso questa discussione verrà preso in esame ogni componente della catena end-to-end che fornisce connettività in Azure.

Al livello più alto, esistono tre principali domini di routing di rete:

• Rete di Azure (cloud blu)
• Internet o WAN (cloud verde)
• Rete aziendale (cloud arancione)

Diamo una breve occhiata a ciascun componente del diagramma, da destra a sinistra:

• Macchina virtuale: il server potrebbe avere più schede di interfaccia di rete. Verificare che tutte le route statiche, le route predefinite e le impostazioni del sistema operativo inviino e ricevano il traffico nel modo in cui si ritiene che sia. Inoltre, ogni SKU della macchina virtuale ha una limitazione della larghezza di banda. Se si usa uno SKU della macchina virtuale più piccolo, il traffico è limitato dalla larghezza di banda disponibile per la scheda di interfaccia di rete. È consigliabile usare un DS5v2 per il test per garantire una larghezza di banda adeguata nella macchina virtuale.

• NIC: assicurarsi di conoscere l'indirizzo IP privato assegnato alla scheda di interfaccia di rete.

• Gruppo di sicurezza di rete NIC: potrebbero essere applicati gruppi di sicurezza di rete specifici a livello di scheda di interfaccia di rete, assicurarsi che il set di regole del gruppo di sicurezza di rete sia appropriato per il traffico che si sta tentando di passare. Ad esempio, assicurarsi che le porte 5201 per iPerf, 3389 per RDP o 22 per SSH siano aperte per consentire il passaggio del traffico di test.

• VNet Subnet: la scheda di interfaccia di rete è assegnata a una subnet specifica. Assicurarsi di conoscere qual'è e quali sono le regole ad essa associate.

• Subnet NSG: proprio come la scheda di interfaccia di rete, anche i gruppi di sicurezza di rete possono essere applicati alla subnet. Verificare che il set di regole dei gruppi di sicurezza di rete sia appropriato per il traffico da passare. Per il traffico in ingresso alla scheda di interfaccia di rete, viene prima applicato il gruppo di sicurezza di rete della subnet, quindi il gruppo di sicurezza di rete della scheda di interfaccia di rete. Quando il traffico viene in uscita dalla macchina virtuale, il gruppo di sicurezza di rete della scheda di rete si applica prima di tutto, viene applicato il gruppo di sicurezza di rete subnet.

• Route definite dall'utente subnet: le route definite dall'utente possono indirizzare il traffico a un hop intermedio, ad esempio un firewall o un servizio di bilanciamento del carico. Assicurarsi di sapere se è presente una route definita dall'utente per il traffico. In tal caso, capire dove va e cosa farà l'hop successivo al traffico. Ad esempio, un firewall potrebbe passare traffico e negare altro traffico tra gli stessi due host.

• Subnet gateway / NSG / UDR: proprio come la subnet della macchina virtuale, la subnet del gateway può avere gruppi di sicurezza di rete e route definite dall'utente. Assicurarsi di sapere se sono lì e quali effetti hanno sul traffico.

• VNet Gateway (ExpressRoute): dopo aver abilitato la VPN o il peering (ExpressRoute) non vi sono molte impostazioni che possono influenzare il routing del traffico o l'esistenza di questo routing. Se si dispone di un gateway di rete virtuale connesso a più circuiti ExpressRoute o tunnel VPN, è necessario tenere presente le impostazioni relative al peso della connessione. Il peso della connessione influisce sulle preferenze di connessione e determina il percorso impiegato dal traffico.

• Filtro route (non visualizzato): è necessario un filtro di route quando si usa il peering Microsoft tramite ExpressRoute. Se non si ricevono route, verificare se il filtro di route è configurato e applicato correttamente al circuito.

A questo punto si è nella parte WAN del collegamento. Questo dominio di routing può essere il provider di servizi, la WAN aziendale o Internet. Esistono molti hop, dispositivi e aziende coinvolti in questi collegamenti, che potrebbero rendere difficile la risoluzione dei problemi. Prima di poter analizzare gli hop tra, è necessario escludere sia Azure che le reti aziendali.

Nel diagramma precedente all'estrema sinistra è collocata la rete aziendale dell'utente. A seconda delle dimensioni dell'azienda, questo dominio di routing può consolidare alcuni dispositivi di rete tra l'utente e la WAN o più livelli di dispositivi su una rete aziendale.

Data la complessità di questi tre diversi ambienti di rete di alto livello. Spesso è ottimale iniziare ai bordi e cercare di mostrare dove le prestazioni sono buone e dove si degrada. Questo approccio consente di identificare il dominio di routing dei problemi dei tre. È quindi possibile concentrarsi sulla risoluzione dei problemi su tale ambiente specifico.

Strumenti

La maggior parte dei problemi di rete può essere analizzata e isolata usando strumenti di base come ping e traceroute. È raro che sia necessario approfondire quanto un'analisi dei pacchetti usando strumenti come Wireshark.

Per facilitare la risoluzione dei problemi, Azure Connectivity Toolkit (AzureCT) è stato sviluppato per inserire alcuni di questi strumenti in un unico pacchetto. Per i test delle prestazioni, strumenti come iPerf e PSPing possono fornire informazioni sulla rete. iPerf è uno strumento comunemente usato per i test di prestazioni di base ed è abbastanza facile da usare. PSPing è uno strumento di test ping sviluppato da SysInternals. PSPing può eseguire ping ICMP e TCP per raggiungere un host remoto. Entrambi questi strumenti sono leggeri e vengono "installati" semplicemente copiando i file in una directory sull'host.

Questi strumenti e metodi vengono inseriti in un modulo di PowerShell (AzureCT) che è possibile installare e usare.

AzureCT: Azure Connectivity Toolkit

Il modulo PowerShell di AzureCT include due componenti: Availability Testing (Test della disponibilità) e Performance Testing (Test delle prestazioni). Poiché questo documento tratta solo il Performance Testing (Test delle prestazioni), occorre concentrarsi sui due comandi del Link Performance (Prestazioni dei collegamenti) inclusi in questo modulo PowerShell.

L'uso di questo kit di strumenti per il Performance Testing (Test delle prestazioni) include tre passaggi fondamentali.

1. Installazione del modulo PowerShell.

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   
   

   Questo comando scarica il modulo PowerShell e lo installa localmente.

2. Installare le applicazioni di supporto.

   Install-LinkPerformance
   

   Questo comando di AzureCT installa iPerf e PSPing in una nuova directory C:\ACTTools, apre anche le porte di Windows Firewall per consentire il traffico ICMP e porta 5201 (iPerf).

3. Eseguire il test delle prestazioni.

   Sull'host remoto, è necessario prima installare ed eseguire iPerf in modalità server. Verificare inoltre che l'host remoto sia in ascolto sulla porta 3389 (RDP per Windows) o 22 (SSH per Linux) e che consenta il traffico sulla porta 5201 per iPerf. Se l'host remoto è Windows, installare AzureCT ed eseguire il comando Install-LinkPerformance. Il comando configura iPerf e le regole del firewall necessarie per avviare iPerf in modalità server correttamente.

   Una volta che il computer remoto è pronto, aprire PowerShell sul computer locale e avviare il test:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Questo comando esegue una serie di test simultanei di carico e latenza per stimare la latenza e la capacità di larghezza di banda del collegamento di rete.

4. Esaminare l'output dei test.

   Il formato di output di PowerShell è simile a questo:

   

   I risultati dettagliati di tutti i test iPerf e PSPing si trovano in singoli file di testo nella directory degli strumenti di AzureCT in "C:\ACTTools".

Risoluzione dei problemi

Se il test delle prestazioni non fornisce risultati previsti, capire perché deve essere un processo progressivo dettagliato. Dato il numero di componenti nel percorso, un approccio sistematico fornisce un percorso più rapido per la risoluzione rispetto al passaggio. Grazie alla risoluzione dei problemi in modo sistematico, è possibile impedire l'esecuzione di test non necessari più volte.

Nota

Nello scenario qui illustrato è necessario risolvere un problema di prestazioni, non di connettività. Per isolare il problema di connettività alla rete di Azure, seguire l'articolo Verifica della connettività ExpressRotue.

Innanzitutto, occorre riconsiderare le proprie ipotesi. Le proprie aspettative sono ragionevoli? Ad esempio, se si dispone di un circuito ExpressRoute da 1 Gbps e di 100 ms di latenza. Non è ragionevole aspettarsi l'intero traffico da 1 Gbps in base alle caratteristiche delle prestazioni di TCP su collegamenti a latenza elevata. Vedere la sezione Riferimenti per altre informazioni sulle ipotesi relative alle prestazioni.

Successivamente, è consigliabile iniziare dai bordi tra domini di routing e provare a isolare il problema in un singolo dominio di routing principale. È possibile iniziare dalla rete aziendale, dalla rete WAN o dalla rete di Azure. Persone spesso incolpare la "scatola nera" nel percorso. Mentre si accusa la scatola nera è facile da fare, può ritardare significativamente la risoluzione. In particolare se il problema si trova in un'area in cui è possibile apportare modifiche per risolvere il problema. Assicurarsi di effettuare tutti i controlli necessari prima di contattare il provider di servizi o ISP.

Dopo aver identificato il dominio di routing principale che sembra contenere il problema, è necessario creare un diagramma dell'area in questione. Quando si disegna un diagramma, è possibile lavorare in modo metodico e isolare il problema. È possibile pianificare i punti di test e aggiornare la mappa man mano che ci si allontana dalle aree o si approfondiscono le analisi durante l'avanzamento del test.

Dopo aver creato un diagramma è possibile iniziare a suddividere la rete in segmenti e circoscrivere il problema. Stabilire dove funziona e dove no. Continuare a spostare i punti di test per isolare il componente incriminato.

Non dimenticare inoltre di esaminare gli altri livelli del modello OSI. È facile concentrarsi sulla rete e sui livelli 1-3 (livelli fisici, dati e rete), ma i problemi possono anche essere presenti nel livello 7, quello dell'applicazione. Mantenere la mente aperta e verificare le ipotesi.

Risoluzione avanzata dei problemi di ExpressRoute

Se non si conoscono i perimetri del cloud, l'isolamento dei componenti di Azure può essere difficile. Quando si usa ExpressRoute, il perimetro è un componente di rete denominato Microsoft Enterprise Edge (MSEE). Quando si usa ExpressRoute, M edizione Standard E è il primo punto di contatto nella rete Microsoft e l'ultimo hop quando si esce dalla rete Microsoft. Quando si crea un oggetto connessione tra il gateway di rete virtuale e il circuito ExpressRoute, si sta effettivamente creando una connessione a M edizione Standard E. Riconoscere M edizione Standard E come primo o ultimo hop a seconda della direzione in cui il traffico è fondamentale per isolare un problema di rete di Azure. Sapere quale direzione dimostra se il problema si trova in Azure o in un altro downstream nella rete WAN o nella rete aziendale.

Nota

Si noti che MSEE non si trova nel cloud di Azure. ExpressRoute si trova effettivamente ai margini della rete Microsoft, non proprio in Azure. Dopo aver stabilito la connessione con ExpressRoute a un M edizione Standard E, si è connessi alla rete Microsoft, da qui è possibile passare a qualsiasi servizio cloud, ad esempio Microsoft 365 (con peering Microsoft) o Azure (con peering privato e/o Microsoft).

Se due reti virtuali sono connesse allo stesso circuito ExpressRoute, è possibile eseguire una serie di test per isolare il problema in Azure.

Piano di test

1. Eseguire il test di Get-LinkPerformance tra VM1 e VM2. Questo test consente di comprendere se il problema è locale o meno. Se questo test produce risultati di latenza e larghezza di banda accettabili, è possibile contrassegnare la rete virtuale locale come valida.

2. Supponendo che il traffico di rete virtuale locale sia valido, eseguire il test Get-LinkPerformance tra VM1 e VM3. Questo test esegue la connessione attraverso la rete Microsoft fino a MSEE e di nuovo verso Azure. Se questo test produce risultati accettabili di latenza e larghezza di banda, è possibile contrassegnare la rete di Azure come corretta.

3. Se Azure è escluso, è possibile eseguire una sequenza simile di test nella rete aziendale. Se anche questi test hanno esito positivo, è giunto il momento di collaborare con il proprio provider di servizi o ISP per eseguire la diagnosi della connessione della rete WAN. Esempio: Eseguire il test tra due filiali, o tra il desktop e un server del data center. A seconda di ciò che si sta testando, trovare endpoint come server e PC client che possono esercitare tale percorso.

Importante

È fondamentale che per ogni test che si contrassegna l'ora del giorno in cui si esegue il test e si registrano i risultati in una posizione comune. Ciascuna esecuzione dei test deve avere un output identico, in modo da poter confrontare i dati risultanti dalle esecuzioni dei test e da non avere "buchi" nei dati. La coerenza tra più test è il motivo principale per cui viene usato AzureCT per la risoluzione dei problemi. La magia non è negli scenari di carico esatti eseguiti, ma il magic è il fatto che si ottiene un test coerente e l'output dei dati da ogni test e ogni test. Registrare l'ora e avere dati coerenti ogni volta è particolarmente utile se in seguito si scopre che il problema è sporadico. Essere diligenti con la raccolta dei dati in anticipo ed evitare ore di modificare gli stessi scenari.

Il problema è stato isolato, ora cosa si deve fare?

Più si isola il problema più velocemente è possibile trovare la soluzione. A volte si raggiunge un punto in cui non è possibile proseguire con la risoluzione dei problemi. Ad esempio, viene visualizzato il collegamento tra i provider di servizi che accetta hop in Europa, ma si prevede che il percorso rimanga tutto in Asia. A questo punto, dovresti contattare qualcuno per assistenza. Chi si chiede dipende dal dominio di routing a cui si isola il problema. Se è possibile restringerla a un componente specifico che sarebbe ancora meglio.

Per problemi di rete aziendale, il reparto IT interno o il provider di servizi può essere utile per la configurazione del dispositivo o la riparazione hardware.

Una procedura consigliata per la risoluzione dei problemi della rete WAN consiste nel condividere i risultati dei test con il provider di servizi o l'ISP, in quanto ciò può essere utile per il loro lavoro. I risultati del test possono anche evitare di eseguire di nuovo le stesse attività già eseguite. Tuttavia, potrebbero voler controllare i risultati stessi. Questo si basa sul principio di attendibilità, ma verificare.

Con Azure, una volta isolato il problema nel modo più preciso possibile, è necessario esaminare la Documentazione di Microsoft Azure e quindi, se ancora necessario, aprire un ticket di supporto.

Riferimenti

Aspettative in termini di latenza e larghezza di banda

Suggerimento

La latenza geografica (miglia o chilometri) tra gli endpoint che si stanno testando è di gran lunga il più importante componente della latenza. Sebbene esista la latenza delle apparecchiature (componenti fisici e virtuali, numero di hop, ecc.), la geografia si è dimostrata il più grande componente della latenza complessiva quando si tratta di connessioni WAN. È anche importante notare che la distanza è la distanza in fibra ottica, non in linea d'aria o su mappa stradale. Ottenere una distanza precisa è estremamente difficile. Di conseguenza, in genere si usa un calcolatore della distanza della città su Internet e si sa che questo metodo è una misura grossolanamente imprecisa, ma è sufficiente per impostare un'aspettativa generale.

Ad esempio, abbiamo un'installazione di ExpressRoute a Seattle, Washington negli Stati Uniti. La tabella seguente illustra la latenza e la larghezza di banda di cui è stato visto il test in varie posizioni di Azure. È stata stimata la distanza geografica tra ogni fine del test.

Configurazione di test:

• Un server fisico che esegue Windows Server 2016 con una scheda di interfaccia di rete da 10 Gbps, collegata a un circuito ExpressRoute.

• Un circuito ExpressRoute Premium da 10 Gbps nella posizione identificata con Peering privato abilitato.

• Una rete virtuale di Azure con un gateway UltraPerformance nell'area specificata.

• Una macchina virtuale DS5v2 che esegue Windows Server 2016 nella rete virtuale. La macchina virtuale non è stata aggiunta a un dominio, creata dall'immagine di Azure predefinita (nessuna ottimizzazione o personalizzazione) con AzureCT installato.

• Tutti i test usano il comando Get-LinkPerformance di AzureCT con un test di carico di 5 minuti per ognuna delle sei esecuzioni di test. Ad esempio:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Per ciascun test, il carico del flusso di dati variava dal server fisico locale (client iPerf in Seattle) alla macchina virtuale di Azure (server iPerf nella regione di Azure elencata).

• I dati della colonna "Latenza" provengono dal test senza carico (un test di latenza TCP senza iPerf in esecuzione).

• I dati della colonna "Massima larghezza di banda" provengono dal test di carico del flusso di 16 TCP con una dimensione della finestra di 1 Mb.

Risultati di latenza e larghezza di banda

Importante

Usare questi valori solo come riferimento generale. Molti fattori influiscono sulla latenza e, sebbene questi valori siano generalmente coerenti nel tempo, le condizioni all'interno di Azure o della rete dei provider di servizi possono inviare il traffico attraverso percorsi diversi in qualsiasi momento, il che può influire sulla latenza e sulla larghezza di banda. Generalmente, queste modifiche non determinano differenze significative.

ExpressRoute Ufficio	Azure Area	Stimato stimata (km)	Latenza	1 Sessione Larghezza di banda	Massimo Larghezza di banda
Seattle	Stati Uniti occidentali 2	191 km	5 ms	262,0 Mbit/sec	3,74 Gbit/sec
Seattle	Stati Uniti occidentali	1.094 km	18 ms	82,3 Mbit/sec	3,70 Gbit/sec
Seattle	Stati Uniti centrali	2.357 km	40 ms	38,8 Mbit/sec	2,55 Gbit/sec
Seattle	Stati Uniti centro-meridionali	2.877 km	51 ms	30,6 Mbit/sec	2,49 Gbit/sec
Seattle	Stati Uniti centro-settentrionali	2.792 km	55 ms	27,7 Mbit/sec	2,19 Gbit/sec
Seattle	Stati Uniti orientali 2	3.769 km	73 ms	21,3 Mbit/sec	1,79 Gbit/sec
Seattle	Stati Uniti orientali	3.699 km	74 ms	21,1 Mbit/sec	1,78 Gbit/sec
Seattle	Giappone orientale	7.705 km	106 ms	14,6 Mbit/sec	1,22 Gbit/sec
Seattle	Regno Unito meridionale	7.708 km	146 ms	10,6 Mbit/sec	896 Mbit/sec
Seattle	Europa occidentale	7.834 km	153 ms	10,2 Mbit/sec	761 Mbit/sec
Seattle	Australia orientale	12.484 km	165 ms	9,4 Mbit/sec	794 Mbit/sec
Seattle	Asia sud-orientale	12.989 km	170 ms	9,2 Mbit/sec	756 Mbit/sec
Seattle	Brasile meridionale *	10.930 km	189 ms	8,2 Mbit/sec	699 Mbit/sec
Seattle	India meridionale	12.918 km	202 ms	7,7 Mbit/sec	634 Mbit/sec

* La latenza in Brasile è un buon esempio in cui la distanza della linea retta differisce significativamente dalla distanza di corsa della fibra. La latenza prevista si trova nel quartiere di 160 ms, ma in realtà è di 189 ms. La differenza nella latenza sembra indicare un problema di rete da qualche parte. Ma la realtà è la linea in fibra non va in Brasile in una linea retta. Quindi ci si dovrebbe aspettare un extra 1.000 km di viaggio per arrivare in Brasile da Seattle.

Nota

Anche se questi numeri devono essere presi in considerazione, sono stati testati usando AzureCT, basato su IPERF in Windows tramite PowerShell. In questo scenario, IPERF non rispetta le opzioni TCP di Windows predefinite per Il fattore di ridimensionamento e usa un conteggio maiusc molto inferiore per le dimensioni della finestra TCP. I numeri rappresentati qui sono stati eseguiti usando i valori IPERF predefiniti e sono solo per riferimento generale. Ottimizzando i comandi IPERF con -w commutatore e una grande dimensione della finestra TCP, è possibile ottenere una velocità effettiva migliore su lunghe distanze, mostrando cifre di velocità effettiva significativamente migliori. Inoltre, per garantire che expressRoute usi la larghezza di banda completa, è consigliabile eseguire l'opzione IPERF in più thread contemporaneamente da più computer per garantire che la capacità di calcolo sia in grado di raggiungere le prestazioni massime del collegamento e non sia limitata dalla capacità di elaborazione di una singola macchina virtuale. Per ottenere i migliori risultati iperf in Windows, usare "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Controllare i criteri dell'organizzazione prima di apportare modifiche.

Passaggi successivi

• Scaricare Azure Connessione ivity Toolkit
• Seguire le istruzioni per il test delle prestazioni dei collegamenti