Risolvere i problemi relativi alle prestazioni di rete

Sommario

Azure offre un modo stabile e rapido per connettere la rete locale a Azure. I clienti di tutte le dimensioni usano metodi come VPN da sito a sito ed ExpressRoute per gestire le proprie attività in Azure. Ma cosa accade quando le prestazioni non soddisfano le aspettative o l'esperienza precedente? Questo articolo ti aiuta a standardizzare il modo in cui testi il tuo ambiente specifico e ne definisci una configurazione di base.

Si apprenderà come testare in modo semplice e coerente la latenza e larghezza di banda di rete tra due host. Si ricevono anche consigli su come esaminare la rete Azure per isolare i punti di problema. Lo script e gli strumenti di PowerShell illustrati richiedono due host nella rete (alla fine del collegamento sottoposto a test). Un host deve essere un Windows Server o desktop e l'altro host può essere Windows o Linux.

Componenti di rete

Prima di approfondire la risoluzione dei problemi, verranno illustrati alcuni termini e componenti comuni. Questa discussione assicura che si stia pensando a ogni componente nella catena end-to-end che abilita la connettività in Azure.

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

• La rete di Azure (nuvola blu)
• Internet o WAN (cloud verde)
• Rete aziendale ("nuvola 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 le route statiche, le route predefinite e le impostazioni del sistema operativo inviino e ricevano il traffico nel modo previsto. Inoltre, ogni SKU di macchina virtuale ha una restrizione della larghezza di banda. Se si usa uno SKU di macchina virtuale di dimensioni inferiori, il traffico è limitato dalla larghezza di banda disponibile per la scheda di interfaccia di rete. Usare un DS5v2 per i test per garantire una larghezza di banda adeguata nella macchina virtuale.

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

• Gruppo di sicurezza di rete NIC : potrebbero essere presenti gruppi di sicurezza di rete specifici applicati a livello di scheda di interfaccia di rete. Assicurarsi che il set di regole dell'NSG sia adeguato al traffico che si sta cercando di far 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 della rete virtuale - La NIC è assegnata a una subnet specifica. Assicurarsi di conoscere quale e le regole associate a tale subnet.

• NSG di subnet - Proprio come per la NIC, puoi applicare gli NSG anche a livello di subnet. Assicurarsi che il set di regole NSG sia appropriato per il traffico che si sta tentando di far passare. Per il traffico in ingresso alla NIC, si applica prima il gruppo di sicurezza della subnet, poi quello della NIC. Quando il traffico esce dalla macchina virtuale, si applica prima l'NSG della scheda di rete, quindi l'NSG della subnet.

• UDR della subnet - Le route definite dall'utente possono indirizzare il traffico verso un hop intermedio, ad esempio un firewall o un bilanciatore del carico. Assicurati di sapere se è presente un UDR (route definita dall'utente) per il traffico. In tal caso, comprendi dove va e cosa fa l'hop successivo al tuo traffico. Ad esempio, un firewall potrebbe passare traffico e negare altro traffico tra gli stessi due host.

• Subnet del gateway / gruppo di sicurezza di rete / route definite dall'utente - 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.

• Gateway di rete virtuale (ExpressRoute): una volta abilitato il peering (ExpressRoute) o la VPN, non sono presenti molte impostazioni che possono influire su come o se il traffico viene instradato. Se si dispone di un gateway di rete virtuale connesso a più circuiti ExpressRoute o tunnel VPN, 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.

• Filtroroute (non visualizzato): è necessario un filtro di route quando si usa Microsoft peering 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 rete WAN aziendale o Internet. In questi collegamenti entrano in gioco numerosi hop, dispositivi e aziende, il che può rendere difficile identificare e risolvere i problemi. Prima di poter analizzare gli hop, è necessario escludere sia Azure che le reti della tua azienda.

Nel diagramma precedente, all'estrema sinistra è la rete aziendale. A seconda delle dimensioni dell'azienda, questo dominio di routing può essere costituito da alcuni dispositivi di rete tra l'utente e la rete WAN o più livelli di dispositivi in una rete campus o 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 problematico tra i tre. È quindi possibile concentrarsi sulla risoluzione dei problemi su tale ambiente specifico.

Tools

È possibile analizzare e isolare la maggior parte dei problemi di rete usando strumenti di base come ping e traceroute. È raro che sia necessario approfondire l'analisi dei pacchetti usando strumenti come Wireshark.

Per facilitare la risoluzione dei problemi, è stato sviluppato Azure Connectivity Toolkit (AzureCT) per inserire alcuni di questi strumenti in un pacchetto semplice. 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 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.

È possibile usare un modulo di PowerShell (AzureCT) che esegue il wrapping di questi strumenti e metodi.

AzureCT - Toolkit di connettività di Azure

Il modulo AzureCT PowerShell include due componenti: Availability Testing e Performance Testing. Questo articolo è incentrato sul test delle prestazioni, in particolare sui due comandi Link Performance di questo modulo PowerShell.

Per usare questo toolkit per i test delle prestazioni, seguire questi tre passaggi di base:

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 del firewall Windows 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. Assicurarsi che l'host remoto sia in ascolto su 3389 (RDP per Windows) o 22 (SSH per Linux) e 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.

   Quando il computer remoto è pronto, aprire PowerShell nel 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 al seguente:

   

   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.

Risolvere i problemi di prestazioni

Se i risultati del test delle prestazioni non sono quello 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.

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. Parti dal margine 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 presupposto 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. 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 è comune concentrarsi sulla rete e sui livelli 1-3 (livelli fisici, dati e rete), 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 Azure può risultare complesso se non si è certi del punto in cui si trova il bordo del cloud. Con ExpressRoute, la rete perimetrale è un componente di rete denominato Microsoft Enterprise Edge (MSEE). Il MSEE è il primo punto di contatto nella rete Microsoft e l'ultimo hop quando la 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 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.

Se due reti virtuali sono connesse al circuito same ExpressRoute, è possibile eseguire test per isolare il problema in Azure.

Piano di test

1. Eseguire il test 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 tramite la rete Microsoft fino a MSEE e torna a Azure. Se il test produce risultati di latenza e larghezza di banda accettabili, è possibile contrassegnare la rete Azure come valida.

3. Se Azure viene 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. Trova endpoint come server e PC client che possono percorrere il percorso di test.

Il problema è isolato, ora cosa?

Più si isola il problema, più velocemente è possibile trovare una soluzione. In alcuni casi, si raggiunge un punto in cui non è possibile proseguire con la risoluzione dei problemi. Ad esempio, potrebbe accadere che il collegamento del tuo provider di servizi faccia dei passaggi attraverso l'Europa quando ti aspetti 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. Potrebbero voler verificare i risultati in base al principio di attendibilità, ma verificare.

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

Riferimenti

Aspettative di latenza e larghezza di banda

Ad esempio, si imposta un ExpressRoute a Seattle, Washington, USA. La tabella seguente illustra la latenza e la larghezza di banda che si osservano durante il test in diverse posizioni Azure, insieme alle distanze stimate.

Configurazione dei test:

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

• Circuito ExpressRoute Premium da 10 Gbps con peering privato abilitato.

• Una rete virtuale 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 installata.

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

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Il flusso di dati per ogni test proviene dal server locale (client iPerf a Seattle) alla macchina virtuale Azure (server iPerf nell'area 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 su 16 flussi TCP con una dimensione della finestra di 1 MB.

Risultati della latenza e della larghezza di banda

* La latenza per il Brasile è un esempio in cui il percorso in fibra ottica differisce significativamente dalla distanza in linea retta. La latenza prevista è di circa 160 ms, ma in realtà è di 189 ms a causa della route fiber più lunga.

Passaggi successivi

• Scarica Azure Connectivity Toolkit
• Seguire le istruzioni per test delle prestazioni del collegamento