Risoluzione dei problemi di prestazioni di rete

Panoramica

Azure offre un modo stabile e rapido per connettere la rete locale ad Azure. I metodi come VPN da sito a sito ed ExpressRoute vengono usati correttamente dai clienti di tutte le dimensioni per gestire le proprie attività in Azure. Ma cosa accade quando le prestazioni non soddisfano le aspettative o l'esperienza precedente? 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. Si riceveranno anche 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). Un host deve essere Windows Server o Desktop e l'altro può essere 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)

Esaminando il diagramma da destra a sinistra, si esaminerà brevemente ogni componente:

• 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 presenti gruppi di sicurezza di rete specifici applicati a livello di scheda di interfaccia di rete. Verificare che il set di regole dei gruppi di sicurezza di rete sia appropriato per il traffico da 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.

• Subnet di rete virtuale: la scheda di interfaccia di rete viene assegnata a una subnet specifica. Assicurarsi di conoscere quale e le regole associate a tale subnet.

• Gruppo di sicurezza di rete della subnet: analogamente alla scheda di interfaccia di rete, i gruppi di sicurezza di rete possono essere applicati anche a livello di 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, il gruppo di sicurezza di rete della subnet si applica prima, quindi il gruppo di sicurezza di rete della scheda di interfaccia di rete. Quando il traffico viene in uscita dalla macchina virtuale, viene applicato prima il gruppo di sicurezza di rete della scheda di interfaccia di rete, quindi 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 è piuttosto 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 semplicemente "installati" copiando i file in una directory nell'host.

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

AzureCT: Azure Connectivity Toolkit

Il modulo AzureCT PowerShell include due componenti: test di disponibilità e test delle prestazioni. Questo documento è incentrato sul test delle prestazioni, in particolare sui due comandi di prestazioni dei collegamenti in questo modulo di PowerShell.

Ecco i tre passaggi di base per usare questo toolkit per i test delle prestazioni:

1. Installare il modulo di PowerShell

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

   Questo comando scarica e installa il modulo PowerShell in locale.

2. Installare le applicazioni di supporto

   Install-LinkPerformance
   

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

3. Eseguire il test delle prestazioni

   Innanzitutto, nell'host remoto installare ed eseguire iPerf in modalità server. Verificare 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 per configurare iPerf e le regole del firewall necessarie.

   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 di carico e latenza simultanei per stimare la capacità e la latenza della larghezza di banda del collegamento di rete.

4. Esaminare l'output del test

   Il formato di output di PowerShell è simile a questo:

   

   I risultati dettagliati di tutti i test iPerf e PSPing vengono salvati in singoli file di testo nella directory degli strumenti di AzureCT all'indirizzo C:\ACTTools.

Risoluzione dei problemi

Se i risultati del test delle prestazioni non sono come previsto, seguire un approccio sistematico per identificare il problema. Dato il numero di componenti nel percorso, un processo dettagliato è più efficace rispetto al test casuale.

Nota

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

1. Sfidare i presupposti

   Assicurati che le tue aspettative siano ragionevoli. Ad esempio, con un circuito ExpressRoute da 1 Gbps e 100 ms di latenza, si prevede che l'intero traffico di 1 Gbps non sia realistico a causa delle caratteristiche delle prestazioni di TCP su collegamenti a latenza elevata. Per altre informazioni sui presupposti sulle prestazioni, vedere la sezione Riferimenti.

2. Iniziare al perimetro della rete

   Iniziare con i bordi tra domini di routing e provare a isolare il problema in un singolo dominio di routing principale. Evitare di incolpare la "scatola nera" nel percorso senza indagini approfondite, in quanto questo può ritardare la risoluzione.

3. Creare un diagramma

   Disegnare un diagramma dell'area in questione per lavorare in modo metodico e isolare il problema. Pianificare i punti di test e aggiornare la mappa quando si cancellano le aree o si scava più in profondità.

4. Dividere e conquistare

   Segmentare la rete e restringere il problema. Identificare dove funziona e dove non funziona e continuare a spostare i punti di test per isolare il componente che causa l'offesa.

5. Prendere in considerazione tutti i livelli OSI

   Anche se l'attenzione sulla rete e sui livelli 1-3 (livelli fisici, dati e rete) è comune, tenere presente che i problemi possono verificarsi anche al livello 7 (livello applicazione). Tenere una mente aperta e verificare tutti i presupposti.

Risoluzione avanzata dei problemi di ExpressRoute

L'isolamento dei componenti di Azure può risultare complesso se non si è certi della posizione perimetrale del cloud. Con ExpressRoute, la rete perimetrale è un componente di rete denominato Microsoft Enterprise Edge (MSEE). MSEE è il primo punto di contatto nella rete microsoft e l'ultimo hop quando lo lascia. Quando si crea una connessione tra il gateway di rete virtuale e il circuito ExpressRoute, ci si connette a MSEE. Il riconoscimento di MSEE come primo o ultimo hop è fondamentale per isolare un problema di rete di Azure. Conoscere la direzione del traffico consente di determinare se il problema si trova in Azure o in un altro downstream nella rete WAN o aziendale.

Nota

MSEE non si trova nel cloud di Azure. ExpressRoute si trova al perimetro della rete Microsoft, non in realtà in Azure. Dopo la connessione con ExpressRoute a un MSEE, si è connessi alla rete Microsoft, consentendo l'accesso ai servizi cloud come 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 test per isolare il problema in Azure.

Piano di test

1. Eseguire il test di Get-LinkPerformance tra VM1 e VM2. Questo test fornisce informazioni dettagliate sul fatto che il problema sia locale. Se il 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 il test produce risultati di latenza e larghezza di banda accettabili, è possibile contrassegnare la rete di Azure come valida.

3. Se Azure è escluso, eseguire test simili nella rete aziendale. Se questi test sono validi, collaborare con il provider di servizi o l'ISP per diagnosticare la connessione WAN. Ad esempio, eseguire test tra due succursali o tra la scrivania e un server del data center. Trovare endpoint come server e PC client che possono esercitare il percorso di test.

Importante

Per ogni test, contrassegnare l'ora del giorno e registrare i risultati in una posizione comune. Ogni esecuzione di test deve avere un output identico per il confronto coerente dei dati. La coerenza tra più test è il motivo principale per l'uso di AzureCT per la risoluzione dei problemi. La chiave sta ottenendo un output coerente di test e dati ogni volta. Registrare il tempo e avere dati coerenti è particolarmente utile se il problema è sporadico. Essere diligenti con la raccolta dei dati in anticipo per evitare ore di ripetere 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, è possibile che venga visualizzato il collegamento tra i provider di servizi che accetta hop in Europa quando si prevede che rimanga in Asia. A questo punto, contattare un utente per ottenere assistenza in base al dominio di routing a cui è stato isolato il problema. Restringerlo a un componente specifico è 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.

Per i problemi della rete WAN, condividere i risultati dei test con il provider di servizi o l'ISP per aiutarli a lavorare ed evitare attività ridondanti. Possono voler verificare i risultati in base al principio di attendibilità, ma verificare.

Per i problemi di Azure, dopo aver isolato il problema nel modo più dettagliato possibile, vedere la documentazione di rete di Azure e, se necessario, aprire un ticket di supporto.

Riferimenti

Aspettative in termini di latenza e larghezza di banda

Suggerimento

La distanza geografica tra endpoint è il fattore più grande di latenza. Anche se la latenza delle apparecchiature (componenti fisici e virtuali, numero di hop e così via) svolge anche un ruolo, la distanza della corsa in fibra, non la distanza lineare, è il collaboratore principale. Questa distanza è difficile da misurare in modo accurato, quindi spesso si usa una calcolatrice della distanza della città per una stima approssimativa.

Ad esempio, è stata configurata un'istanza di ExpressRoute a Seattle, Washington, USA. La tabella seguente illustra la latenza e la larghezza di banda osservate durante il test in diverse posizioni di Azure, insieme alle distanze stimate.

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.

• Circuito ExpressRoute Premium da 10 Gbps 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 usando l'immagine di Azure predefinita con AzureCT installato.

• Tutti i test hanno usato 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
  

• Il flusso di dati per ogni test è stato dal server locale (client iPerf a Seattle) alla macchina virtuale di Azure (server iPerf nell'area di Azure elencata).

• La colonna "Latency" mostra i dati del test no load (test di latenza TCP senza iPerf in esecuzione).

• La colonna "Larghezza di banda massima" mostra i dati del test di carico del flusso TCP 16 con dimensioni 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, mentre questi valori sono in genere coerenti nel tempo, le condizioni all'interno di Azure o la rete del provider di servizi possono cambiare, influenzando la latenza e la larghezza di banda. In genere, queste modifiche non comportano differenze significative.

Percorso ExpressRoute	Area di Azure	Distanza stimata (km)	Latenza	1 Larghezza di banda sessione	Larghezza di banda massima
Seattle	West US 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 esempio in cui la distanza di esecuzione della fibra differisce significativamente dalla distanza lineare. La latenza prevista sarebbe di circa 160 ms, ma in realtà è di 189 ms a causa della route fiber più lunga.

Nota

Questi numeri sono stati testati usando AzureCT basato su iPerf in Windows tramite PowerShell. iPerf non rispetta le opzioni TCP di Windows predefinite per Il fattore di ridimensionamento e usa un numero di maiusc inferiore per le dimensioni della finestra TCP. Ottimizzando i comandi iPerf con l'opzione -w e una dimensione maggiore della finestra TCP, è possibile ottenere una velocità effettiva migliore. L'esecuzione di iPerf in modalità multithread da più computer può anche aiutare a raggiungere il massimo livello di prestazioni dei collegamenti. Per ottenere i migliori risultati di iPerf in Windows, usare "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Controllare i criteri dell'organizzazione prima di apportare modifiche.

Passaggi successivi

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