Perché la mia istanza Amazon EC2 supera i limiti di rete quando l'utilizzo medio è basso?

Ultimo aggiornamento: 04/08/2022

Perché la mia istanza Amazon Elastic Compute Cloud (Amazon EC2) supera i limiti di rete quando l'utilizzo medio è basso?

Breve descrizione

Puoi interrogare i parametri delle prestazioni di rete in tempo reale su istanze che supportano una rete avanzata tramite Elastic Network Adapter (ENA). Questi parametri forniscono il numero cumulativo dei pacchetti messi in coda o eliminati su ciascuna interfaccia di rete dall'ultima reimpostazione del driver. Di seguito sono riportate alcuni dei parametri ENA:

  • bw_in_allowance_exceeded: il numero di pacchetti messi in coda o eliminati perché la larghezza di banda aggregata in entrata ha superato il valore massimo per l'istanza.
  • bw_out_allowance_exceeded: il numero di pacchetti messi in coda o eliminati perché la larghezza di banda aggregata in uscita ha superato il valore massimo per l'istanza.
  • pps_allowance_exceeded: il numero di pacchetti messi in coda o eliminati perché i pacchetti bidirezionali al secondo (PPS) hanno superato il valore massimo per l'istanza.

Le specifiche delle prestazioni di rete variano a seconda del tipo di istanza. Per visualizzare le specifiche, consulta la sezione Istanze di generazione corrente. In alcuni casi, è possibile che si verifichino accodamenti o eliminazioni anche se i valori di larghezza di banda media o PPS visualizzati in Amazon CloudWatch sono bassi. Ad esempio, i parametri NetworkIn, NetworkOut, NetworkPacketsIn o NetworkPacketsOut in CloudWatch potrebbero mostrare valori che non suggeriscono il raggiungimento di un limite.

Risoluzione

I microburst sono la causa più comune dei sintomi precedenti. I microburst sono brevi picchi della domanda seguiti da periodi di attività bassa o nulla. Queste raffiche durano pochi secondi, millisecondi o anche microsecondi. Nel caso dei microburst, i parametri di CloudWatch elencati nella sezione precedente non sono sufficientemente dettagliati da rifletterli.

Come vengono calcolate le medie

I parametri EC2 in CloudWatch elencati nella sezione precedente vengono campionati ogni minuto. Tali parametri acquisiscono i byte totali o i pacchetti trasferiti in quel periodo. Questi campioni vengono quindi aggregati e pubblicati su CloudWatch in periodi di 5 minuti. Ogni statistica del periodo restituisce un valore di esempio diverso:

  • Sum è la somma di tutti i valori campione.
  • SampleCount è il numero di campioni aggregati (in questo caso, 5).
  • Minimum è il valore di esempio con il numero di byte/pacchetti più basso.
  • Average è il valore medio del campione, calcolato dividendo Sum per SampleCount.
  • Maximum è il valore di esempio con il numero di byte/pacchetti più alto.

La velocità di trasmissione effettiva o il PPS possono essere calcolati in due modi:

  • Dividi Sum per Period (ad esempio, 300 secondi), per una media semplice di 5 minuti.
  • Dividi Maximum per 60 secondi, per una media al minuto con l'attività più alta.

In che modo i microburst si riflettono nei parametri di CloudWatch

Di seguito è riportato un esempio di microburst e di come si riflette in CloudWatch:

  • L'istanza ha una larghezza di banda della rete di 10 Gbps (1,25 GB/s).
  • In un dato campione (60 secondi), un trasferimento dati in uscita di 20 GB consuma tutta la larghezza di banda disponibile, causando l'aumento di bw_out_allowance_exceeded. Il trasferimento viene completato in circa 20 secondi e non vengono inviati ulteriori dati in seguito.
  • L'istanza rimane inattiva per i restanti 4 campioni (240 secondi).

In questo esempio, il throughput medio in un periodo di 5 minuti è molto inferiore a quello durante il microburst:

SUM(NetworkOut) / PERIOD = ((20 GB * 1 sample) + (0 GB * 4 samples)) / 300 seconds = ~0.066 GB/s * 8 bits = ~0.533 Gbps

Anche se si calcola il throughput in base al campione più elevato, la media non riflette ancora la quantità di throughput:

MAXIMUM(NetworkOut) / 60 = 20 GB / 60 seconds = ~0.333 GB/s * 8 bits = ~2.667 Gbps

Monitoraggio dei microburst

Per misurare il throughput e i PPS a un livello più dettagliato, utilizza gli strumenti del sistema operativo (SO) per monitorare le statistiche di rete. Monitora le statistiche di rete più frequentemente durante i periodi di modellazione o attività elevata.

Di seguito sono riportati esempi di strumenti in base al sistema operativo:

Linux

  • sar
  • nload
  • iftop
  • iptraf-ng

Windows

  • Performance Monitor

L'agente CloudWatch può essere utilizzato sia su Linux che su Windows per pubblicare questi parametri di rete a livello di sistema operativo su CloudWatch come parametri personalizzati. Tali parametri possono essere pubblicati a intervalli di appena 1 secondo. Tieni presente che i parametri ad alta risoluzione (quelli con un intervallo inferiore a 60 secondi) comportano addebiti più elevati. Per ulteriori informazioni sui prezzi di CloudWatch, consulta la sezione Prezzi di Amazon CloudWatch.

È consigliabile monitorare i parametri delle prestazioni di rete forniti da ENA. Per visualizzare i parametri, la versione del driver deve essere maggiore di o pari a 2.2.10 (Linux) e 2.2.2 (Windows). Per ulteriori informazioni, consulta le pagine relative a Linux e Windows.

CloudWatch Agent può anche pubblicare parametri ENA. Per istruzioni sulla pubblicazione di parametri ENA per Linux, consulta la sezione Raccolta di parametri delle prestazioni di rete. Per Windows, i parametri ENA sono disponibili in Performance Monitor e CloudWatch Agent può essere configurato in modo da pubblicare qualsiasi parametro disponibile.

Prevenire i microburst

Per evitare microburst, il traffico deve essere stimolato verso i mittenti in modo che non superi una velocità di trasmissione effettiva massima o un determinato tasso di pacchetti. Questo rende difficile evitare i microburst. La stimolazione del traffico verso i mittenti di solito richiede modifiche a livello di applicazione. A seconda di come viene implementata questa modifica, potrebbe essere necessario che il supporto del sistema operativo per la stimolazione del traffico sia disponibile e attivato presso il mittente. Ciò potrebbe non essere sempre possibile o pratico. Il microbursting può verificarsi anche a causa di un numero troppo elevato di connessioni che inviano pacchetti in un breve periodo. Quando ciò accade, la stimolazione dei singoli mittenti non aiuta.

Per questi motivi, è consigliabile monitorare i parametri ENA. Se i limiti vengono raggiunti spesso o se esistono prove che la modellazione del traffico ha un impatto sulle applicazioni, procedi come segue:

  • Aumenta: passa a un'istanza di dimensioni maggiori. Le istanze più grandi hanno generalmente quote più elevate. Le istanze ottimizzate per la rete (le istanze con una "n", ad esempio come in C5n) hanno quote più elevate rispetto alle rispettive controparti non ottimizzate per la rete.
  • Aumenta orizzontalmente: distribuisci il traffico su più istanze in modo da ridurre il traffico e i conflitti sulle singole istanze.

Su Linux, oltre alle opzioni precedenti, esistono potenziali opzioni di mitigazione per gli utenti avanzati: Puoi implementare queste opzioni singolarmente o in combinazione. È consigliabile eseguire il benchmark delle mitigazioni in un ambiente di test per verificare che riducano o eliminino la modellazione del traffico senza influire negativamente sul carico di lavoro.

  • SO_MAX_PACING_RATE: quest'opzione socket può essere passata da un'applicazione alla chiamata di sistema setsockopt per specificare una velocità di stimolazione massima (byte al secondo). Il kernel Linux quindi sposta il traffico da quel socket in modo che non superi il limite. Questa opzione richiede quanto segue:
  • Discipline di accodamento (qdisc): i qdisc sono responsabili della programmazione dei pacchetti e della modellazione opzionale. Alcuni qdisc, come fq, contribuiscono a ridurre le raffiche di traffico dai singoli flussi. Per ulteriori informazioni, consulta la pagina del manuale Traffic Control (TC).
  • Code di trasmissione superficiale (Tx): in alcuni scenari, le code Tx superficiali aiutano a ridurre la modellazione dei PPS. Ciò è possibile in due modi:
    • Byte Queue Limits (BQL): il BQL limita dinamicamente la quantità di byte in-flight sulle code Tx. Il BQL è attivato per impostazione predefinita sulle versioni dei driver ENA fornite con il kernel Linux (quelle che terminano con una "K"). Per le versioni dei driver ENA da GitHub (quelle che terminano con una "g"), il BQL è disponibile a partire dalla v2.6.1g ed è disattivato per impostazione predefinita. Puoi attivare il BQL utilizzando il parametro del modulo ENA enable_bql.
    • Lunghezza della coda Tx ridotta: riduce la lunghezza della coda Tx dal suo valore predefinito di 1.024 pacchetti a una quantità inferiore (minimo 256). Puoi modificare questa lunghezza utilizzando ethtool.