Perché la mia istanza Amazon EC2 supera i limiti di rete se il mio utilizzo medio è basso?

Breve descrizione

Le metriche delle prestazioni di rete ENA (Elastic Network Adaptor) bw_in_allowance_exceeded, bw_out_allowance_exceeded o pps_allowance_exceeded potrebbero aumentare anche quando l'utilizzo medio è basso. La causa più comune del problema sono i brevi picchi di domanda di risorse di rete, detti microburst. I microburst in genere durano solamente qualche secondo, millisecondo o addirittura microsecondo. Le metriche di Amazon CloudWatch non sono sufficientemente granulari per rispecchiarli. Ad esempio, puoi utilizzare in CloudWatch le metriche dell’istanza NetworkIn e NetworkOut per calcolare il throughput medio al secondo. Tuttavia, le velocità calcolate potrebbero essere inferiori alla larghezza di banda dell'istanza disponibile per il tipo di istanza a causa dei microburst.

Un aumento delle metriche bw_in_allowance_exceeded e bw_out_allowance_exceeded si verifica anche su istanze più piccole con una ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html#available-instance-bandwidth)larghezza di banda "fino a"[, ad esempio "fino a 10 gigabit al secondo (Gbps)". Le istanze più piccole utilizzano i crediti I/O di rete per superare la larghezza di banda di base per un tempo limitato. Una volta esauriti i crediti, il traffico si allinea alla larghezza di banda di base e le metriche aumentano. Poiché il picco dell'istanza avviene nelle migliori condizioni possibili, le metriche potrebbero aumentare anche quando l'istanza dispone ancora di crediti I/O.

Un aumento della metrica pps_allowance_exceeded si verifica anche quando modelli di traffico non ottimali causano perdite di pacchetti a velocità PPS inferiori. Routing asimmetrico, driver obsoleti, pacchetti piccoli, frammenti e tracciamento delle connessioni influiscono sulle prestazioni PPS di un carico di lavoro.

Risoluzione

Calcolo medio

CloudWatch esegue il campionamento delle metriche di Amazon EC2 ogni 60 secondi per acquisire il totale dei byte o dei pacchetti trasferiti in 1 minuto. Amazon EC2 aggrega i campioni e li pubblica su CloudWatch in periodi di 5 minuti. Ogni statistica del periodo mostra un valore diverso.

Quando utilizzi il monitoraggio dettagliato, CloudWatch pubblica le metriche NetworkIn e NetworkOut senza aggregazione in periodi di 1 minuto. I valori per Sum, Minimum, Average e Maximum sono gli stessi, mentre il valore per SampleCount è 1. CloudWatch aggrega e pubblica sempre le metriche NetworkPacketsIn e NetworkPacketsOut in periodi di 5 minuti.

Utilizza i seguenti metodi per calcolare il throughput medio in byte al secondo (Bps) o PPS di un periodo:

• Per una media semplice del periodo di tempo specificato, dividi Sum per Period o per la differenza di timestamp tra i valori (DIFF_TIME).
• Per una media del minuto con l'attività più alta, dividi Maximum per 60 secondi.

Per convertire i Bps in Gbps, dividi i risultati del calcolo per 1.000.000.000 di byte e moltiplicali per 8 bit.

Microburst nelle metriche di CloudWatch

L'esempio seguente mostra come appare un microburst in CloudWatch. L'istanza ha una larghezza di banda della rete consentita di 10 Gbps e utilizza il monitoraggio di base.

In un campione di 60 secondi, un trasferimento dati in uscita di circa 24 GB utilizza tutta la larghezza di banda disponibile. Il trasferimento dei dati aumenta il valore bw_out_allowance_exceeded e viene completato in circa 20 secondi con una velocità media di 9,6 Gbps. Amazon EC2 non invia altri dati e l'istanza rimane inattiva per i restanti 4 campioni di 240 secondi.

Il throughput medio in Gbps in un periodo di 5 minuti è molto inferiore a quello registrato durante il microburst:

Formula: AVERAGE_Gbps = SUM(NetworkOut) / PERIOD(NetworkOut) / 1.000.000.000 byte * 8 bit

SUM(NetworkOut) = (~24 GB * 1 campione) + (~0 GB * 4 campioni) = ~24 GB

PERIOD(NetworkOut) = 300 secondi (5 minuti)

AVERAGE_Gbps = ~24 / 300 / 1.000.000.000 * 8 = ~0,64 Gbps

Anche quando calcoli il throughput medio in base al campione più elevato, la quantità non riflette ancora il throughput registrato durante il microburst:

Formula: AVERAGE_Gbps = MAXIMUM(NetworkOut) / 60 secondi / 1.000.000.000 byte / 8 bit

MAXIMUM(NetworkOut) = ~24 GB

AVERAGE_Gbps = ~24 GB / 60 / 1.000.000.000 * 8 = ~3,2 Gbps

Quando sono disponibili dati ad alta risoluzione, puoi ottenere medie più accurate. Quando raccogli le metriche sull'utilizzo della rete del sistema operativo a intervalli di 1 secondo, il throughput medio raggiunge per un breve lasso di tempo circa 9,6 Gbps.

Monitora i microburst

Puoi utilizzare l'agente CloudWatch su Linux e Windows per pubblicare metriche di rete a livello di sistema operativo su CloudWatch a intervalli massimi di 1 secondo. L'agente può anche pubblicare le metriche delle prestazioni di rete ENA.

Nota: le metriche ad alta risoluzione hanno prezzi più elevati.

Per monitorare le statistiche di rete a intervalli massimi di 1 secondo, puoi anche utilizzare gli strumenti del sistema operativo. Per le istanze Windows, utilizza Monitor prestazioni. Per Linux, utilizza sar, nload, iftop, iptraf-ng o netqtop.

Per identificare chiaramente i microburst, esegui un'acquisizione dei pacchetti del sistema operativo, quindi utilizza Wireshark per tracciare un grafico I/O a intervalli di 1 millisecondo. Per ulteriori informazioni, consulta Download Wireshark (Scarica Wireshark) e 8.8. The "I/O Graphs" window (8.8. La finestra "Grafici I/O") sul sito web Wireshark.

Questo metodo ha i seguenti limiti:

• Le quote di rete consentite sono approssimativamente proporzionali a livello di microsecondi. Ad esempio, un tipo di istanza con prestazioni di larghezza di banda di 10 Gbps può inviare e ricevere circa 10 megabit (Mb) in 1 millisecondo.
• Le acquisizioni di pacchetti causano un carico aggiuntivo del sistema e possono ridurre il throughput complessivo e le velocità PPS.
• Le acquisizioni di pacchetti potrebbero non includere tutti i pacchetti a causa delle perdite dovute a un buffer completo.
• I timestamp non indicano con precisione quando una rete ha inviato i pacchetti o quando l'ENA li ha ricevuti.
• I grafici I/O potrebbero mostrare una minore attività per il traffico in entrata poiché Amazon EC2 controlla e ottimizza il traffico che supera la sua quota (traffic shaping) prima che raggiunga l'istanza.

Code e perdite di pacchetti

Quando la rete mette in coda un pacchetto, la latenza risultante viene misurata in millisecondi. Le connessioni TCP possono scalare il throughput superando le quote di un tipo di istanza EC2. Di conseguenza, alcune code di pacchetti sono prevedibili anche se utilizzi l'algoritmo BBR (Bottleneck Bandwidth and Round-trip propagation time) o altri algoritmi di controllo della congestione che utilizzano come segnale la latenza. Quando una rete perde un pacchetto, il TCP ritrasmette automaticamente i segmenti persi. Sia le code sia le perdite di pacchetti possono comportare una latenza maggiore e un throughput inferiore. Tuttavia, non è possibile visualizzare le azioni di ripristino. In genere, vengono visualizzati errori solamente quando l'applicazione utilizza timeout bassi o quando la rete perde tanti pacchetti da chiudere forzatamente la connessione.

Le metriche delle prestazioni di rete ENA non fanno distinzione tra pacchetti in coda e pacchetti persi. Per misurare la latenza TCP a livello di connessione su Linux, utilizza i comandi ss o tcprtt. Per misurare le ritrasmissioni TCP, utilizza i comandi ss o tcpretrans per le statistiche a livello di connessione e nstat per le statistiche a livello di sistema. Per scaricare gli strumenti tcprtt e tcpretrans che fanno parte della BPF Compiler Collection (BCC), consulta bcc sul sito web GitHub. Puoi anche utilizzare le acquisizioni di pacchetti per misurare la latenza e le ritrasmissioni.

Nota: i pacchetti persi dalla rete a causa del superamento delle quote dell'istanza non vengono visualizzati nei contatori delle perdite per ip o ifconfig.

Evita i microburst

Innanzitutto, confronta le metriche delle prestazioni di rete ENA rispetto agli indicatori chiave di prestazione (KPI) dell'applicazione per determinare l'effetto delle code o delle perdite di pacchetti.

Se i KPI sono inferiori a una soglia richiesta o se ricevi errori nel log dell'applicazione, intraprendi le seguenti azioni per ridurre le code e le perdite di pacchetti:

• Aumenta verticalmente: aumenta la dimensione dell'istanza a un'istanza con una quota di rete consentita più elevata. I tipi di istanza con una "n", come C7gn, hanno quote di rete consentite più elevate.
• Aumenta orizzontalmente: distribuisci il traffico su più istanze per ridurre il traffico e i conflitti nelle singole istanze.

Per le operazioni basate su Linux, puoi anche implementare le seguenti strategie per evitare i microburst. È consigliabile testare le strategie in un ambiente di prova per verificare che riducano il traffic shaping senza effetti negativi sul carico di lavoro.

Nota: le seguenti strategie sono valide solo per il traffico in uscita.

SO_MAX_PACING_RATE

Utilizza l'opzione socket SO_MAX_PACING_RATE per specificare un tasso di andamento massimo in Bps per una connessione. Il kernel Linux introduce quindi ritardi tra i pacchetti provenienti dal socket in modo che il throughput non superi la quota specificata.

Per utilizzare questo metodo, devi implementare le seguenti modifiche:

• Modifiche al codice dell'applicazione.
• Supporto del kernel. Per ulteriori informazioni, consulta net: introduce SO_MAX_PACING_RATE (rete: introduzione di SO_MAX_PACING_RATE) sul sito web GitHub.
• Disciplina di accodamento Fair Queue (FQ) o supporto del kernel per l'andamento a livello TCP (solo per TCP).

Per ulteriori informazioni, consulta getsockopt(2) - Linux manual page (getsockopt(2) - Pagina del manuale di Linux) e tc-fq(8) - Linux manual page (tc-fq(8) - Pagina del manuale di Linux) sul sito web man7. Inoltre, consulta tcp: internal implementation for pacing (tcp: implementazione interna per l'andamento) sul sito web GitHub.

qdiscs

Per pianificare i pacchetti, Linux utilizza la configurazione predefinita di una disciplina di accodamento pfifo_fast per ogni coda ENA. Utilizza la qdisc fq per ridurre i picchi di traffico dovuti a un singolo flusso e regolarne il throughput. Oppure utilizza fq_codel e cake per fornire funzionalità di gestione attiva delle code (AQM) che riducono la congestione della rete e migliorano la latenza. Per ulteriori informazioni, consultatc(8) - Linux manual page (tc(8) - Pagina del manuale di Linux) sul sito web man7.

Per TCP, attiva l'ECN (Explicit Congestion Notification) su client e server. Quindi combina l'ECN con una qdisc in grado di eseguire la marcatura ECN CE (Congestion Experienced). La marcatura CE fa sì che il sistema operativo riduca il throughput di una connessione per ridurre la latenza e le perdite di pacchetti causate dal superamento di una quota dell'istanza. Per utilizzare questa soluzione, devi configurare la qdisc con una soglia CE bassa in base al tempo di andata e ritorno (RTT) medio delle connessioni. È consigliabile utilizzare questa soluzione solo quando il valore RTT medio tra le connessioni non varia molto. Ad esempio, l'istanza gestisce il traffico solo in una zona di disponibilità.

A causa di problemi di prestazioni, non è consigliabile configurare il traffic shaping della larghezza di banda aggregato a livello di istanza.

Code di trasmissione (Tx) corte

Utilizza code Tx corte per ridurre il traffic shaping PPS. I limiti di byte della coda (BQL) limitano dinamicamente il numero di byte in transito nelle code Tx. Per attivare BQL, aggiungi ena.enable_bql=1 alla riga di comando del kernel in GRUB.

Nota: devi disporre del driver ENA versione 2.6.1g o superiore per utilizzare questa soluzione. BQL è già attivato sui driver ENA con versioni del kernel Linux che terminano con K.

Per ulteriori informazioni, consulta bql: Byte Queue Limits (bql: limiti di byte della coda) sul sito web LWN.net.

Quando utilizzi ENA Express, devi disattivare BQL per massimizzare la larghezza di banda.

Puoi anche usare ethtool per ridurre la lunghezza della coda Tx rispetto al valore predefinito di 1.024 pacchetti. Per ulteriori informazioni, consulta ethtool(8) - Linux manual page (ethtool(8) - Pagina del manuale di Linux) sul sito web man7.

Informazioni correlate

Larghezza di banda della rete delle istanze Amazon EC2