Ottimizzazione delle prestazioni TCP/IP per le macchine virtuali di Azure

Questo articolo illustra le tecniche comuni di ottimizzazione delle prestazioni TCP/IP e alcuni aspetti da considerare quando vengono usati per le macchine virtuali in esecuzione in Azure. Fornirà una panoramica di base delle tecniche e esaminerà come possono essere ottimizzate.

Tecniche comuni di ottimizzazione TCP/IP

MTU, frammentazione e offload di invio di grandi dimensioni

MTU

L'unità di trasmissione massima (MTU) è il frame di dimensioni maggiori (pacchetto), specificato in byte, che può essere inviato tramite un'interfaccia di rete. L'MTU è un'impostazione configurabile. L'MTU predefinito usato nelle VM di Azure e l'impostazione predefinita nella maggior parte dei dispositivi di rete a livello globale è di 1.500 byte.

Frammentazione

La frammentazione si verifica quando viene inviato un pacchetto che supera l'MTU di un'interfaccia di rete. Lo stack TCP/IP suddividerà il pacchetto in parti più piccole (frammenti) conformi all'MTU dell'interfaccia. La frammentazione si verifica a livello IP ed è indipendente dal protocollo sottostante ,ad esempio TCP. Quando un pacchetto da 2.000 byte viene inviato tramite un'interfaccia di rete con un MTU di 1.500, il pacchetto verrà suddiviso in un pacchetto da 1.500 byte e un pacchetto da 500 byte.

I dispositivi di rete nel percorso tra un'origine e una destinazione possono eliminare pacchetti che superano l'MTU o frammentare il pacchetto in parti più piccole.

Bit Don't Fragment in un pacchetto IP

Il bit Don't Fragment (DF) è un flag nell'intestazione del protocollo IP. Il bit DF indica che i dispositivi di rete nel percorso tra il mittente e il ricevitore non devono frammentare il pacchetto. Questo bit può essere impostato per molti motivi. Per un esempio, vedere la sezione "Individuazione MTU percorso" di questo articolo. Quando un dispositivo di rete riceve un pacchetto con il set di bit Don't Fragment e tale pacchetto supera l'interfaccia del dispositivo MTU, il comportamento standard è per il dispositivo per eliminare il pacchetto. Il dispositivo invia un messaggio ICMP Fragmentation Needed all'origine originale del pacchetto.

Implicazioni sulle prestazioni della frammentazione

La frammentazione può avere implicazioni negative sulle prestazioni. Uno dei motivi principali dell'effetto sulle prestazioni è l'impatto della CPU/memoria della frammentazione e del riassemblaggio dei pacchetti. Quando un dispositivo di rete deve frammentare un pacchetto, deve allocare risorse CPU/memoria per eseguire la frammentazione.

La stessa cosa accade quando il pacchetto viene riassemblato. Il dispositivo di rete deve archiviare tutti i frammenti fino a quando non vengono ricevuti in modo che possa riassemblarli nel pacchetto originale.

Azure e frammentazione

I pacchetti frammentati in Azure non vengono elaborati dalla rete accelerata. Quando una macchina virtuale riceve un pacchetto frammentato, verrà elaborata tramite il percorso non accelerato. Ciò significa che i pacchetti frammentati non otterranno i vantaggi della rete accelerata (minore latenza, jitter ridotto e pacchetti più elevati al secondo). Per questo motivo, è consigliabile evitare la frammentazione, se possibile.

Per impostazione predefinita, Azure rimuoverà i frammenti di ordine, ovvero i pacchetti frammentati che non arrivano alla macchina virtuale nell'ordine in cui sono stati trasmessi dall'endpoint di origine. Ciò può verificarsi quando i pacchetti vengono trasmessi tramite Internet o altri WAN di grandi dimensioni. Il riordinamento dei frammenti non in ordine può essere abilitato in alcuni casi. Se un'applicazione richiede questa operazione, aprire un caso di supporto.

Ottimizzare l'MTU

Non è consigliabile che i clienti aumentino la MTU nelle schede di interfaccia di rete delle macchine virtuali. Se la macchina virtuale deve comunicare con le destinazioni che non si trovano nel Rete virtuale con un set di MTU simile, la frammentazione probabilmente si verificherà riducendo le prestazioni.

Offload di invio di grandi dimensioni

LSO (Large Send Offload) può migliorare le prestazioni di rete eseguendo l'offload della segmentazione dei pacchetti nella scheda Ethernet. Quando LSO è abilitato, lo stack TCP/IP crea un pacchetto TCP di grandi dimensioni e lo invia alla scheda Ethernet per la segmentazione prima di inoltrarla. Il vantaggio di LSO è che può liberare la CPU dalla segmentazione dei pacchetti in dimensioni conformi all'MTU e l'offload dell'elaborazione nell'interfaccia Ethernet in cui viene eseguita nell'hardware. Per altre informazioni sui vantaggi di LSO, vedere Supporto di offload di invio di grandi dimensioni.

Quando LSO è abilitato, i clienti di Azure potrebbero visualizzare dimensioni di frame di grandi dimensioni quando eseguono acquisizioni di pacchetti. Queste dimensioni di frame di grandi dimensioni potrebbero portare alcuni clienti a pensare che si verifichi la frammentazione o che venga usata una MTU di grandi dimensioni quando non lo è. Con LSO, la scheda Ethernet può annunciare una dimensione massima del segmento maggiore (MSS) allo stack TCP/IP per creare un pacchetto TCP più grande. L'intero frame non segmentato viene quindi inoltrato alla scheda Ethernet e sarà visibile in un'acquisizione di pacchetti eseguita nella macchina virtuale. Ma il pacchetto verrà suddiviso in molti fotogrammi più piccoli dalla scheda Ethernet, in base alla MTU della scheda Ethernet.

Ridimensionamento della finestra MSS TCP e PMTUD

Dimensioni massime del segmento TCP

La dimensione massima del segmento TCP (MSS) è un'impostazione che limita le dimensioni dei segmenti TCP, evitando così la frammentazione dei pacchetti TCP. I sistemi operativi usano in genere questa formula per impostare MSS:

MSS = MTU - (IP header size + TCP header size)

L'intestazione IP e l'intestazione TCP sono 20 byte ciascuno o 40 byte totali. Quindi, un'interfaccia con un MTU di 1.500 avrà un MSS pari a 1.460. Ma mss è configurabile.

Questa impostazione viene accettata nell'handshake a tre vie TCP quando viene configurata una sessione TCP tra un'origine e una destinazione. Entrambi i lati inviano un valore MSS e il valore inferiore dei due viene usato per la connessione TCP.

Tenere presente che le MTU dell'origine e della destinazione non sono gli unici fattori che determinano il valore MSS. I dispositivi di rete intermedi, ad esempio i gateway VPN, tra cui Azure Gateway VPN, possono regolare L'MTU indipendentemente dall'origine e dalla destinazione per garantire prestazioni di rete ottimali.

Individuazione dell'unità massima di trasmissione del percorso

MSS viene negoziato, ma potrebbe non indicare il servizio gestito effettivo che può essere usato. Questo perché altri dispositivi di rete nel percorso tra l'origine e la destinazione potrebbero avere un valore MTU inferiore rispetto all'origine e alla destinazione. In questo caso, il dispositivo il cui MTU è minore del pacchetto rilascia il pacchetto. Il dispositivo invierà un messaggio ICMP Fragmentation Needed (Type 3, Code 4) che contiene la relativa MTU. Questo messaggio ICMP consente all'host di origine di ridurre il percorso MTU in modo appropriato. Il processo è denominato Individuazione MTU percorso (PMTUD).

Il processo PMTUD non è efficiente e influisce sulle prestazioni di rete. Quando i pacchetti vengono inviati che superano l'MTU di un percorso di rete, i pacchetti devono essere ritrasmessi con un mss inferiore. Se il mittente non riceve il messaggio ICMP Frammentazione necessaria, forse a causa di un firewall di rete nel percorso (comunemente definito blackhole PMTUD), il mittente non sa che deve abbassare il servizio MSS e ritrasmetterà continuamente il pacchetto. Questo è il motivo per cui non è consigliabile aumentare l'MTU della macchina virtuale di Azure.

VPN e MTU

Se si usano macchine virtuali che eseguono incapsulamento (ad esempio VPN IPsec), esistono alcune considerazioni aggiuntive relative alle dimensioni dei pacchetti e all'MTU. Le VPN aggiungono altre intestazioni ai pacchetti, aumentando le dimensioni del pacchetto e richiede un MSS più piccolo.

Per Azure, è consigliabile impostare il blocco TCP MSS su 1.350 byte e l'interfaccia del tunnel MTU su 1.400. Per altre informazioni, vedere la pagina dei dispositivi VPN e dei parametri IPSec/IKE.

Latenza, tempo di round trip e ridimensionamento delle finestre TCP

Latenza e tempo di round trip

La latenza di rete è governata dalla velocità della luce su una rete in fibra ottica. La velocità effettiva della rete TCP è gestita in modo efficace anche dal tempo di round trip (RTT) tra due dispositivi di rete.

Questa tabella mostra la distanza di linea retta tra due posizioni. Nelle reti, la distanza è in genere più lunga della distanza lineare. Ecco una semplice formula per calcolare il valore RTT minimo in base alla velocità della luce:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

È possibile usare 200 per la velocità di propagazione. Questa è la distanza, in chilometri, che la luce viaggia in 1 millisecondo.

Prendiamo New York a San Francisco come esempio. La distanza di linea retta è di 4.148 km. Collegando tale valore all'equazione, si ottiene quanto segue:

Minimum RTT = 2 * (4,148 / 200)

L'output dell'equazione è espresso in millisecondi.

Se si desidera ottenere le migliori prestazioni di rete, l'opzione logica consiste nel selezionare le destinazioni con la distanza più breve tra di esse. È anche necessario progettare la rete virtuale per ottimizzare il percorso del traffico e ridurre la latenza. Per altre informazioni, vedere la sezione "Considerazioni sulla progettazione della rete" di questo articolo.

Effetti sulla latenza e sul tempo di round trip su TCP

Il tempo di round trip ha un effetto diretto sulla velocità effettiva TCP massima. Nel protocollo TCP le dimensioni della finestra sono la quantità massima di traffico che può essere inviata tramite una connessione TCP prima che il mittente debba ricevere l'acknowledgement dal ricevitore. Se TCP MSS è impostato su 1.460 e le dimensioni della finestra TCP sono impostate su 65.535, il mittente può inviare 45 pacchetti prima di dover ricevere l'acknowledgement dal ricevitore. Se il mittente non riceve l'acknowledgement, ritrasmetterà i dati. La formula è:

TCP window size / TCP MSS = packets sent

In questo esempio, 65.535 / 1.460 viene arrotondato fino a 45.

Questo stato di "attesa di riconoscimento", un meccanismo per garantire un recapito affidabile dei dati, è ciò che fa sì che RTT influisca sulla velocità effettiva TCP. Più a lungo il mittente attende l'acknowledgement, più tempo è necessario attendere prima di inviare altri dati.

Ecco la formula per calcolare la velocità effettiva massima di una singola connessione TCP:

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

Questa tabella mostra la velocità effettiva massima di megabyte al secondo di una singola connessione TCP. Per la leggibilità, i megabyte vengono usati per l'unità di misura.

Se i pacchetti vengono persi, la velocità effettiva massima di una connessione TCP verrà ridotta mentre il mittente ritrasmette i dati già inviati.

Ridimensionamento delle finestre TCP

Il ridimensionamento delle finestre TCP è una tecnica che aumenta dinamicamente le dimensioni della finestra TCP per consentire l'invio di più dati prima che venga richiesto un acknowledgement. Nell'esempio precedente, 45 pacchetti verrebbero inviati prima che fosse necessario un acknowledgement. Se si aumenta il numero di pacchetti che è possibile inviare prima che sia necessario un acknowledgement, si riduce il numero di volte in cui un mittente è in attesa di acknowledgement, aumentando così la velocità effettiva massima TCP.

Questa tabella illustra le relazioni seguenti:

Ma il valore dell'intestazione TCP per le dimensioni della finestra TCP è di soli 2 byte, ovvero il valore massimo per una finestra di ricezione è 65.535. Per aumentare le dimensioni massime della finestra, è stato introdotto un fattore di scala della finestra TCP.

Il fattore di scala è anche un'impostazione che è possibile configurare in un sistema operativo. Ecco la formula per calcolare le dimensioni della finestra TCP usando i fattori di scala:

TCP window size = TCP window size in bytes * (2^scale factor)

Ecco il calcolo per un fattore di scala della finestra pari a 3 e una dimensione della finestra pari a 65.535:

65,535 * (2^3) = 524,280 bytes

Un fattore di scala pari a 14 determina una dimensione della finestra TCP pari a 14 (offset massimo consentito). Le dimensioni della finestra TCP saranno pari a 1.073.725.440 byte (8,5 gigabit).

Supporto per il ridimensionamento delle finestre TCP

Windows può impostare fattori di ridimensionamento diversi per tipi di connessione diversi. Le classi di connessioni includono data center, Internet e così via. Usare il Get-NetTCPConnection comando di PowerShell per visualizzare il tipo di connessione di ridimensionamento della finestra:

Get-NetTCPConnection

È possibile usare il Get-NetTCPSetting comando di PowerShell per visualizzare i valori di ogni classe:

Get-NetTCPSetting

È possibile impostare le dimensioni iniziali della finestra TCP e il fattore di ridimensionamento TCP in Windows usando il Set-NetTCPSetting comando PowerShell. Per altre informazioni, vedere Set-NetTCPSetting.

Set-NetTCPSetting

Queste sono le impostazioni TCP valide per AutoTuningLevel:

Queste impostazioni hanno maggiori probabilità di influire sulle prestazioni TCP, ma tenere presente che molti altri fattori in Internet, al di fuori del controllo di Azure, possono influire anche sulle prestazioni TCP.

Rete accelerata e ricezione del ridimensionamento laterale

Rete accelerata

Le funzioni di rete delle macchine virtuali hanno storicamente un utilizzo intensivo della CPU sia nella macchina virtuale guest che nell'hypervisor/host. Ogni pacchetto che transita attraverso l'host viene elaborato nel software dalla CPU host, incluse tutte le incapsulazioni e decapsulation della rete virtuale. Maggiore è quindi il traffico che attraversa l'host, maggiore è il carico della CPU. E se la CPU host è occupata con altre operazioni, ciò influirà anche sulla velocità effettiva e latenza di rete. Azure risolve questo problema con la rete accelerata.

La rete accelerata offre una latenza di rete ultralow coerente tramite l'hardware programmabile internamente di Azure e tecnologie come SR-IOV. La rete accelerata sposta gran parte dello stack di rete software-defined di Azure dalle CPU e nelle smartNIC basate su FPGA. Questa modifica consente alle applicazioni degli utenti finali di recuperare cicli di calcolo, che comportano un minor carico sulla VM, riducendo il jitter e l'incoerenza nella latenza. In altre parole, le prestazioni possono essere più deterministiche.

La rete accelerata migliora le prestazioni consentendo alla macchina virtuale guest di ignorare l'host e stabilire un percorso dati direttamente con smartNIC di un host. Ecco alcuni vantaggi della rete accelerata:

• Minore latenza o pacchetti più elevati al secondo (pps): la rimozione del commutatore virtuale dal percorso dati elimina il tempo speso per i pacchetti nell'host per l'elaborazione dei criteri e aumenta il numero di pacchetti che possono essere elaborati nella macchina virtuale.

• Jitter ridotto: l'elaborazione del commutatore virtuale dipende dalla quantità di criteri da applicare e dal carico di lavoro della CPU che esegue l'elaborazione. L'offload dell'applicazione dei criteri all'hardware rimuove tale variabilità recapitando pacchetti direttamente alla macchina virtuale, eliminando la comunicazione da host a macchina virtuale e tutti gli interrupt software e i commutatori di contesto.

• Utilizzo ridotto della CPU: ignorando il commutatore virtuale nell'host si ottiene un minore utilizzo della CPU per l'elaborazione del traffico di rete.

Per usare la rete accelerata, è necessario abilitarla in modo esplicito in ogni macchina virtuale applicabile. Per istruzioni, vedere Creare una macchina virtuale Linux con rete accelerata.

Ricevere il ridimensionamento laterale

Receive side scaling (RSS) è una tecnologia driver di rete che distribuisce la ricezione del traffico di rete in modo più efficiente distribuendo l'elaborazione di ricezione tra più CPU in un sistema multiprocessore. In termini semplici, RSS consente a un sistema di elaborare più traffico ricevuto perché usa tutte le CPU disponibili invece di una sola. Per una discussione più tecnica su RSS, vedere Introduzione alla ricezione del ridimensionamento laterale.

Per ottenere prestazioni ottimali quando la rete accelerata è abilitata in una macchina virtuale, è necessario abilitare RSS. RSS può anche offrire vantaggi sulle macchine virtuali che non usano la rete accelerata. Per una panoramica su come determinare se RSS è abilitato e come abilitarlo, vedere Ottimizzare la velocità effettiva di rete per le macchine virtuali di Azure.

TIME_WAIT TCP e TIME_WAIT assassinio

TCP TIME_WAIT è un'altra impostazione comune che influisce sulle prestazioni della rete e dell'applicazione. Nelle macchine virtuali occupate che aprono e chiudono molti socket, come client o come server (porta di origine: porta di origine e ip di destinazione: porta di destinazione), durante il normale funzionamento di TCP, un determinato socket può finire in uno stato TIME_WAIT per molto tempo. Lo stato TIME_WAIT consente di recapitare dati aggiuntivi su un socket prima di chiuderlo. Pertanto, gli stack TCP/IP impediscono in genere il riutilizzo di un socket eliminando automaticamente il pacchetto TCP SYN del client.

La quantità di tempo in cui un socket è in TIME_WAIT è configurabile. Può variare da 30 secondi a 240 secondi. I socket sono una risorsa limitata e il numero di socket che possono essere usati in un determinato momento è configurabile. Il numero di socket disponibili è in genere di circa 30.000. Se i socket disponibili vengono utilizzati o se i client e i server hanno impostazioni di TIME_WAIT non corrispondenti e una macchina virtuale tenta di riutilizzare un socket in uno stato TIME_WAIT, le nuove connessioni avranno esito negativo perché i pacchetti SYN TCP vengono eliminati automaticamente.

Il valore per l'intervallo di porte per i socket in uscita è in genere configurabile all'interno dello stack TCP/IP di un sistema operativo. Lo stesso vale per le impostazioni di TIME_WAIT TCP e il riutilizzo del socket. La modifica di questi numeri può potenzialmente migliorare la scalabilità. Tuttavia, a seconda della situazione, queste modifiche potrebbero causare problemi di interoperabilità. È consigliabile prestare attenzione se si modificano questi valori.

È possibile usare TIME_WAIT assassinio per risolvere questa limitazione del ridimensionamento. TIME_WAIT assassinio consente di riutilizzare un socket in determinate situazioni, ad esempio quando il numero di sequenza nel pacchetto IP della nuova connessione supera il numero di sequenza dell'ultimo pacchetto della connessione precedente. In questo caso, il sistema operativo consentirà di stabilire la nuova connessione (accetterà il nuovo SYN/ACK) e forzare la chiusura della connessione precedente in uno stato di TIME_WAIT. Questa funzionalità è supportata nelle macchine virtuali Windows in Azure. Per informazioni sul supporto in altre macchine virtuali, rivolgersi al fornitore del sistema operativo.

Per informazioni sulla configurazione delle impostazioni TIME_WAIT TCP e dell'intervallo di porte di origine, vedere Impostazioni che possono essere modificate per migliorare le prestazioni di rete.

Fattori di rete virtuale che possono influire sulle prestazioni

Velocità effettiva in uscita massima della macchina virtuale

Azure offre un'ampia gamma di dimensioni e tipi di macchine virtuali, ognuna con una combinazione diversa di funzionalità di prestazioni. Una di queste funzionalità è la velocità effettiva di rete (o la larghezza di banda), misurata in megabit al secondo (Mbps). Poiché le macchine virtuali sono ospitate in hardware condiviso, la capacità di rete deve essere condivisa equamente tra le macchine virtuali che usano lo stesso hardware. Le macchine virtuali di dimensioni maggiori vengono allocate più larghezza di banda rispetto alle macchine virtuali più piccole.

La larghezza di banda di rete allocata a ogni macchina virtuale è misurata sul traffico in uscita dalla macchina virtuale. Tutto il traffico di rete che esce dalla macchina virtuale viene conteggiato per il limite allocato, indipendentemente dalla destinazione. Ad esempio, se una macchina virtuale ha un limite di 1.000 Mbps, tale limite si applica se il traffico in uscita è destinato a un'altra macchina virtuale nella stessa rete virtuale o in uno all'esterno di Azure.

Il traffico in ingresso non viene misurato o limitato direttamente. Esistono tuttavia altri fattori, come i limiti di CPU e archiviazione, che possono influire sulla capacità di una macchina virtuale di elaborare i dati in ingresso.

La rete accelerata è progettata per migliorare le prestazioni di rete, tra cui latenza, velocità effettiva e utilizzo della CPU. La rete accelerata può migliorare la velocità effettiva di una macchina virtuale, ma può farlo solo fino alla larghezza di banda allocata della macchina virtuale.

Le macchine virtuali di Azure dispongono di almeno un'interfaccia di rete collegata. Potrebbero avere diversi. La larghezza di banda allocata a una macchina virtuale è la somma di tutto il traffico in uscita in tutte le interfacce di rete collegate al computer. In altre parole, la larghezza di banda viene allocata per ogni macchina virtuale, indipendentemente dal numero di interfacce di rete collegate al computer.

La velocità effettiva in uscita prevista e il numero di interfacce di rete supportate da ogni dimensione di macchina virtuale sono descritti in Dettaglio dimensioni per le macchine virtuali Windows in Azure. Per visualizzare la velocità effettiva massima, selezionare un tipo, ad esempio Per utilizzo generico, quindi trovare la sezione relativa alla serie di dimensioni nella pagina risultante , ad esempio "Serie Dv2". Per ogni serie è disponibile una tabella che fornisce le specifiche di rete nell'ultima colonna, denominata "Max NICs/Expected network bandwidth (Mbps).

Il limite di velocità effettiva si applica alla macchina virtuale. La velocità effettiva non è influenzata da questi fattori:

• Numero di interfacce di rete: il limite di larghezza di banda si applica alla somma di tutto il traffico in uscita dalla macchina virtuale.

• Rete accelerata: anche se questa funzionalità può essere utile per raggiungere il limite pubblicato, non modifica il limite.

• Destinazione del traffico: tutte le destinazioni contano per il limite in uscita.

• Protocollo: tutto il traffico in uscita su tutti i protocolli conta per il limite.

Per altre informazioni, vedere Larghezza di banda di rete delle macchine virtuali.

Considerazioni sulle prestazioni internet

Come descritto in questo articolo, i fattori su Internet e al di fuori del controllo di Azure possono influire sulle prestazioni di rete. Ecco alcuni di questi fattori:

• Latenza: il tempo di round trip tra due destinazioni può essere influenzato da problemi nelle reti intermedie, dal traffico che non accetta il percorso di distanza "più breve" e da percorsi di peering non ottimali.

• Perdita di pacchetti: la perdita di pacchetti può essere causata dalla congestione della rete, dai problemi di percorso fisico e dalla sottoperformazione dei dispositivi di rete.

• Dimensioni MTU/Frammentazione: la frammentazione lungo il percorso può causare ritardi nell'arrivo dei dati o nei pacchetti in arrivo fuori ordine, che possono influire sulla consegna dei pacchetti.

Traceroute è uno strumento valido per misurare le caratteristiche delle prestazioni di rete (ad esempio perdita di pacchetti e latenza) lungo ogni percorso di rete tra un dispositivo di origine e un dispositivo di destinazione.

Considerazioni sulla progettazione della rete

Oltre alle considerazioni descritte in precedenza in questo articolo, la topologia di una rete virtuale può influire sulle prestazioni della rete. Ad esempio, una progettazione hub-spoke che esegue il backhauling del traffico a livello globale verso una rete virtuale a hub singolo introdurrà la latenza di rete, che influirà sulle prestazioni complessive della rete.

Il numero di dispositivi di rete che il traffico di rete passa attraverso può influire anche sulla latenza complessiva. Ad esempio, in una progettazione hub-spoke, se il traffico passa attraverso un'appliance virtuale di rete spoke e un'appliance virtuale hub prima di passare a Internet, le appliance virtuali di rete possono introdurre latenza.

Aree di Azure, reti virtuali e latenza

Le aree di Azure sono costituite da più data center presenti all'interno di un'area geografica generale. Questi data center potrebbero non essere fisicamente accanto agli altri. In alcuni casi sono separati da un numero di chilometri. La rete virtuale è una sovrimpressione logica nella rete del data center fisico di Azure. Una rete virtuale non implica una topologia di rete specifica all'interno del data center.

Ad esempio, due macchine virtuali che si trovano nella stessa rete virtuale e subnet potrebbero trovarsi in rack, righe o persino data center diversi. Potrebbero essere separati da piedi di cavo in fibra ottica o da chilometri di cavo in fibra ottica. Questa variante potrebbe introdurre una latenza variabile (qualche millisecondo di differenza) tra macchine virtuali diverse.

La posizione geografica delle macchine virtuali e la potenziale latenza risultante tra due macchine virtuali può essere influenzata dalla configurazione dei set di disponibilità e zone di disponibilità. Tuttavia, la distanza tra i data center in un'area è specifica dell'area e principalmente influenzata dalla topologia del data center nell'area.

Esaurimento delle porte NAT di origine

Una distribuzione in Azure può comunicare con gli endpoint all'esterno di Azure sulla rete Internet pubblica e/o nello spazio IP pubblico. Quando un'istanza avvia una connessione in uscita, Azure esegue il mapping dinamico dell'indirizzo IP privato a un indirizzo IP pubblico. Dopo aver creato questo mapping, il traffico restituito per il flusso originato in uscita può raggiungere anche l'indirizzo IP privato in cui ha avuto origine il flusso.

Per ogni connessione in uscita, Azure Load Balancer deve gestire questo mapping per un certo periodo di tempo. Con la natura multi-tenant di Azure, la gestione di questo mapping per ogni flusso in uscita per ogni macchina virtuale può richiedere un uso intensivo delle risorse. Sono quindi previsti limiti impostati e basati sulla configurazione dell'Rete virtuale di Azure. In alternativa, per dire che più precisamente, una macchina virtuale di Azure può effettuare solo un determinato numero di connessioni in uscita in un determinato momento. Quando vengono raggiunti questi limiti, la macchina virtuale non sarà in grado di effettuare più connessioni in uscita.

Ma questo comportamento è configurabile. Per altre informazioni sull'esaurimento delle porte SNAT e SNAT, vedere questo articolo.

Misurare le prestazioni di rete in Azure

Il numero massimo di prestazioni in questo articolo è correlato alla latenza di rete/tempo di round trip (RTT) tra due macchine virtuali. Questa sezione fornisce alcuni suggerimenti su come testare latenza/RTT e come testare le prestazioni tcp e le prestazioni di rete delle macchine virtuali. È possibile ottimizzare e testare le prestazioni dei valori TCP/IP e di rete illustrati in precedenza usando le tecniche descritte in questa sezione. È possibile collegare i valori di latenza, MTU, MSS e dimensioni della finestra nei calcoli forniti in precedenza e confrontare i valori teorici massimi con i valori effettivi osservati durante i test.

Misurare il tempo di round trip e la perdita di pacchetti

Le prestazioni TCP si basano principalmente su RTT e perdita di pacchetti. L'utilità PING disponibile in Windows e Linux offre il modo più semplice per misurare la perdita di pacchetti e RTT. L'output di PING mostrerà la latenza minima/massima/media tra un'origine e una destinazione. Mostrerà anche la perdita di pacchetti. PING usa il protocollo ICMP per impostazione predefinita. È possibile usare PsPing per testare TCP RTT. Per altre informazioni, vedere PsPing.

Misurare la larghezza di banda effettiva di una macchina virtuale

Per misurare accuratamente la larghezza di banda delle macchine virtuali di Azure, seguire queste indicazioni.

Per altri dettagli sul test di altri scenari, vedere gli articoli seguenti:

• Risoluzione dei problemi relativi alle prestazioni di rete expressroute

• Come convalidare la velocità effettiva della VPN verso una rete virtuale

Rilevare comportamenti TCP inefficienti

Nelle acquisizioni di pacchetti, i clienti di Azure potrebbero visualizzare pacchetti TCP con flag TCP (SACK, DUP ACK, RETRANSMIT e FAST RETRANSMIT) che potrebbero indicare problemi di prestazioni di rete. Questi pacchetti indicano in modo specifico l'inefficienze di rete che derivano dalla perdita di pacchetti. Ma la perdita di pacchetti non è necessariamente causata da problemi di prestazioni di Azure. I problemi di prestazioni possono essere il risultato di problemi dell'applicazione, problemi del sistema operativo o altri problemi che potrebbero non essere direttamente correlati alla piattaforma Azure.

Tenere inoltre presente che alcuni ACL duplicati e ritrasmissione sono normali in una rete. I protocolli TCP sono stati creati per essere affidabili. L'evidenza di questi pacchetti TCP in un'acquisizione di pacchetti non indica necessariamente un problema di rete sistemico, a meno che non siano eccessivi.

Tuttavia, questi tipi di pacchetti indicano che la velocità effettiva TCP non raggiunge le prestazioni massime, per motivi illustrati in altre sezioni di questo articolo.

Passaggi successivi

Dopo aver appreso le informazioni sull'ottimizzazione delle prestazioni TCP/IP per le macchine virtuali di Azure, è possibile leggere altre considerazioni sulla pianificazione delle reti virtuali o altre informazioni sulla connessione e la configurazione di reti virtuali.