Ulteriori passaggi per la risoluzione dei problemi - Amazon ElastiCache (RedisOSS)
Gruppi di sicurezzaListe di controllo accessi (ACL) di reteTabelle di instradamentoRisoluzione DNSIdentificazione dei problemi con la diagnostica lato serverConvalida della connettività di reteLimiti relativi alla reteUtilizzo CPUConnessioni terminate dal lato serverRisoluzione dei problemi lato client per istanze Amazon EC2Dissezione del tempo necessario per completare una singola richiesta

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Ulteriori passaggi per la risoluzione dei problemi

I seguenti elementi devono essere verificati durante la risoluzione dei problemi di connettività persistenti con ElastiCache:

Gruppi di sicurezza

I gruppi di sicurezza sono firewall virtuali che proteggono il ElastiCache client (istanza EC2, AWS Lambda funzione, contenitore Amazon ECS, ecc.) e la cache. ElastiCache I gruppi di sicurezza sono dotati di stato, il che significa che dopo che il traffico in entrata o in uscita è consentito, le risposte per tale traffico verranno automaticamente autorizzate nel contesto di tale gruppo di sicurezza specifico.

La funzionalità con stato richiede che il gruppo di sicurezza monitori tutte le connessioni autorizzate ed esiste un limite per le connessioni monitorate. Se il limite viene raggiunto, le nuove connessioni avranno esito negativo. Consulta la sezione dedicata alla risoluzione dei problemi per sapere se i limiti sono stati raggiunti dal client o dal lato. ElastiCache

È possibile assegnare contemporaneamente un singolo gruppo di sicurezza al client e al ElastiCache cluster o singoli gruppi di sicurezza per ciascuno.

In entrambi i casi, è necessario consentire il traffico TCP in uscita sulla ElastiCache porta dall'origine e il traffico in entrata sulla stessa porta verso. ElastiCache La porta predefinita è 11211 per Memcached e 6379 per Redis OSS. Per impostazione predefinita, i gruppi di sicurezza autorizzano tutto il traffico in uscita. In questo caso, è necessaria solo la regola in entrata nel gruppo di sicurezza di destinazione.

Per ulteriori informazioni, consulta Modelli di accesso per l'accesso a un ElastiCache cluster in un Amazon VPC.

Liste di controllo accessi (ACL) di rete

Liste di controllo accessi di rete (ACL) sono regole senza stato. Il traffico deve essere consentito in entrambe le direzioni (in entrata e in uscita) per avere esito positivo. Le ACL di rete vengono assegnate alle sottoreti, non a risorse specifiche. È possibile assegnare lo stesso ACL ElastiCache e la stessa risorsa client, specialmente se si trovano nella stessa sottorete.

Per impostazione predefinita, le ACL di rete consentono tutti i traffici. Tuttavia, è possibile personalizzarle per negare o consentire il traffico. Inoltre, la valutazione delle regole delle ACL è sequenziale, ossia la regola con il numero più basso corrispondente al traffico consentirà o negherà tale traffico. La configurazione minima per consentire il traffico Redis OSS è:

ACL di rete lato client:

  • Regole in entrata:

  • Numero della regola: preferibilmente inferiore a qualsiasi regola di diniego;

  • Tipo: Regola TCP personalizzata;

  • Protocollo: TCP

  • Intervallo porte: 1024-65535

  • Fonte: 0.0.0.0/0 (o crea regole individuali per le sottoreti del cluster) ElastiCache

  • Consenti/Nega: Consenti

  • Regole in uscita:

  • Numero della regola: preferibilmente inferiore a qualsiasi regola di diniego;

  • Tipo: Regola TCP personalizzata;

  • Protocollo: TCP

  • Intervallo porte: 6379

  • Fonte: 0.0.0.0/0 (o le sottoreti del cluster. ElastiCache Tieni presente che l'utilizzo di IP specifici può creare problemi in caso di failover o scalabilità del cluster)

  • Consenti/Nega: Consenti

ElastiCache ACL di rete:

  • Regole in entrata:

  • Numero della regola: preferibilmente inferiore a qualsiasi regola di diniego;

  • Tipo: Regola TCP personalizzata;

  • Protocollo: TCP

  • Intervallo porte: 6379

  • Fonte: 0.0.0.0/0 (o crea regole individuali per le sottoreti del cluster) ElastiCache

  • Consenti/Nega: Consenti

  • Regole in uscita:

  • Numero della regola: preferibilmente inferiore a qualsiasi regola di diniego;

  • Tipo: Regola TCP personalizzata;

  • Protocollo: TCP

  • Intervallo porte: 1024-65535

  • Fonte: 0.0.0.0/0 (o le sottoreti del cluster. ElastiCache Tieni presente che l'utilizzo di IP specifici può creare problemi in caso di failover o scalabilità del cluster)

  • Consenti/Nega: Consenti

Per ulteriori informazioni, consultare ACL di rete.

Tabelle di instradamento

Analogamente alle ACL di rete, ogni sottorete può avere tabelle di routing diverse. Se i client e il ElastiCache cluster si trovano in sottoreti diverse, assicurati che le tabelle di routing consentano loro di raggiungersi.

Gli ambienti più complessi, che coinvolgono più routing dinamici di VPC, o firewall di rete, possono risultare difficili da risolvere. Consultare Convalida della connettività di rete per verificare che le impostazioni di rete siano appropriate.

Risoluzione DNS

ElastiCache fornisce gli endpoint del servizio in base ai nomi DNS. Gli endpoint disponibili sono Configuration, Primary, Reader eNode. Per maggiori informazioni, consultare Trovare gli endpoint di connessione.

In caso di failover o di modifica del cluster, l'indirizzo associato al nome dell'endpoint potrebbe cambiare e verrà aggiornato automaticamente.

Le impostazioni DNS personalizzate (ad esempio, che non utilizzano il servizio DNS VPC) potrebbero non essere a conoscenza dei ElastiCache nomi DNS forniti. Assicurati che il tuo sistema sia in grado di risolvere correttamente gli ElastiCache endpoint utilizzando strumenti di sistema come dig (come mostrato di seguito) o. nslookup

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4

È inoltre possibile forzare la risoluzione dei nomi tramite il servizio del DNS VPC:

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4

Identificazione dei problemi con la diagnostica lato server

CloudWatch le metriche e le informazioni sul tempo di funzionamento del ElastiCache motore sono fonti o informazioni comuni per identificare potenziali fonti di problemi di connessione. Una buona analisi inizia comunemente con i seguenti elementi:

  • Utilizzo della CPU: Redis OSS è un'applicazione multithread. Tuttavia, l'esecuzione di ogni comando avviene in un singolo thread (principale). Per questo motivo, ElastiCache fornisce le metriche e. CPUUtilization EngineCPUUtilization EngineCPUUtilizationfornisce l'utilizzo della CPU dedicato al processo Redis OSS e CPUUtilization l'utilizzo su tutte le vCPU. I nodi con più di una vCPU di solito hanno valori diversi per CPUUtilization e EngineCPUUtilization, il secondo è comunemente più alto. Un elevato EngineCPUUtilization può essere causato da un numero elevato di richieste o operazioni complesse che richiedono una notevole quantità di tempo di CPU per il completamento. È possibile identificare entrambi con i seguenti elementi:

    • Numero elevato di richieste: verifica la presenza di aumenti su altri parametri che corrispondono al modello EngineCPUUtilization. I parametri utili sono:

      • CacheHits e CacheMisses: il numero di richieste corrette o richieste che non hanno trovato un elemento valido nella cache. Se il rapporto tra perdite e successi è elevato, l'applicazione sta sprecando tempo e risorse con richieste infruttuose.

      • SetTypeCmds e GetTypeCmds: questi parametri correlati con EngineCPUUtilization possono aiutare a capire se il carico è significativamente più alto per le richieste di scrittura, misurato da SetTypeCmds, o letture, misurate da GetTypeCmds. Se il carico è prevalentemente di lettura, l'utilizzo di più repliche di lettura può bilanciare le richieste su più nodi e risparmiare il primario per le scritture. Nei cluster disattivati in modalità cluster, è possibile utilizzare le repliche di lettura creando una configurazione di connessione aggiuntiva nell'applicazione utilizzando l'endpoint di lettura. ElastiCache Per maggiori informazioni, consultare Trovare gli endpoint di connessione. Le operazioni di lettura devono essere inviate a questa connessione aggiuntiva. Le operazioni di scrittura verranno eseguite attraverso l'endpoint primario regolare. In modalità cluster abilitata, è consigliabile utilizzare una libreria che supporti le repliche di lettura in modalità nativa. Con i flag giusti, la libreria sarà in grado di scoprire automaticamente la topologia del cluster, i nodi di replica, abilitare le operazioni di lettura tramite il comando READONLY Redis OSS e inviare le richieste di lettura alle repliche.

    • Elevato numero di connessioni:

      • CurrConnections e NewConnections: CurrConnection è il numero di connessioni stabilite al momento della raccolta dei datapoint, mentre NewConnections mostra quante connessioni sono state create nel periodo.

        La creazione e la gestione delle connessioni implica un notevole overhead della CPU. Inoltre, l'handshake a tre vie TCP richiesto per creare nuove connessioni influirà negativamente sui tempi di risposta complessivi.

        Un ElastiCache nodo con migliaia di dati NewConnections al minuto indica che una connessione viene creata e utilizzata con pochi comandi, il che non è ottimale. Mantenere le connessioni stabilite e riutilizzarle per nuove operazioni è una best practice. Ciò è possibile quando l'applicazione client supporta e implementa correttamente il pool di connessioni o le connessioni persistenti. Con il pool di connessioni, il numero di currConnections non ha grandi variazioni, e le NewConnections dovrebbero essere il più basso possibile. Redis OSS offre prestazioni ottimali con un numero limitato di CurrConnections. Mantenere currConnection nell'ordine di decine o centinaia riduce al minimo l'utilizzo di risorse per supportare singole connessioni come buffer client e cicli CPU per servire la connessione.

    • Velocità effettiva di rete

      • Determina la larghezza di banda: ElastiCache i nodi hanno una larghezza di banda di rete proporzionale alla dimensione del nodo. Poiché le applicazioni hanno caratteristiche diverse, i risultati possono variare in base al carico di lavoro. Ad esempio, le applicazioni con un elevato tasso di richieste di piccole dimensioni tendono a influire di più sull'utilizzo della CPU rispetto alla velocità effettiva di rete, mentre le chiavi più grandi causeranno un maggiore utilizzo della rete. Per questo motivo, è consigliabile testare i nodi con il carico di lavoro effettivo per una migliore comprensione dei limiti.

        La simulazione del carico dall'applicazione fornirebbe risultati più accurati. Tuttavia, gli strumenti relativi al valore di riferimento possono dare una buona idea dei limiti.

      • Nei casi in cui le richieste sono prevalentemente letture, l'utilizzo delle repliche per le operazioni di lettura riduce il carico sul nodo primario. Se il caso d'uso è prevalentemente scritture, l'uso di molte repliche amplificerà l'utilizzo della rete. Per ogni byte scritto nel nodo primario, N byte verranno inviati alle repliche, essendo N il numero di repliche. La migliore pratica per i carichi di lavoro ad alta intensità di scrittura consiste nell'utilizzare ElastiCache (Redis OSS) con la modalità cluster abilitata, in modo che le scritture possano essere bilanciate su più shard o scalare fino a un tipo di nodo con maggiori funzionalità di rete.

      • I CloudWatchmetrics NetworkBytesIn e NetworkBytesOut forniscono rispettivamente la quantità di dati in entrata o in uscita dal nodo. ReplicationBytesè il traffico dedicato alla replica dei dati.

      Per ulteriori informazioni, consulta Limiti relativi alla rete.

    • Comandi complessi: i comandi Redis OSS vengono serviti su un singolo thread, il che significa che le richieste vengono servite in sequenza. Un singolo comando lento può influire su altre richieste e connessioni, culminando in time-out. L'uso di comandi che agiscono su più valori, chiavi o tipi di dati deve essere fatto con attenzione. Le connessioni possono essere bloccate o terminate a seconda del numero di parametri o delle dimensioni dei valori di input o output.

      Un esempio famigerato è il comando KEYS. Esso spazza l'intero keyspace alla ricerca di un dato modello e blocca l'esecuzione di altri comandi durante la sua esecuzione. Redis OSS utilizza la notazione «Big O» per descrivere la complessità dei comandi.

      Il comando delle chiavi ha complessità di tempo O(N), dove N è il numero di chiavi presenti nel database. Pertanto, maggiore è il numero di chiavi, più lento sarà il comando. KEYS può causare problemi in diversi modi: se non viene utilizzato alcun modello di ricerca, il comando restituirà tutti i nomi delle chiavi disponibili. Nei database con migliaia o milioni di elementi, verrà creato un output enorme e inonderà i buffer di rete.

      Se viene utilizzato un modello di ricerca, solo le chiavi corrispondenti al modello torneranno al client. Tuttavia, il motore continua a spazzare l'intero keyspace alla sua ricerca e il tempo necessario per completare il comando sarà lo stesso.

      Un'alternativa per KEYS è il comando SCAN. Si ripete sul keyspace e limita le iterazioni in un numero specifico di elementi, evitando blocchi prolungati sul motore.

      La scansione ha il parametro COUNT, utilizzato per impostare la dimensione dei blocchi di iterazione. Il valore di default è 10 (10 elementi per iterazione).

      A seconda del numero di elementi nel database, piccoli blocci di valori COUNT richiedono più iterazioni per completare una scansione completa e valori più grandi manterranno il motore occupato più a lungo ad ogni iterazione. Mentre piccoli valori di conteggio renderanno SCAN più lento su database di grandi dimensioni, valori più grandi possono causare gli stessi problemi menzionati per KEYS.

      Ad esempio, l'esecuzione del comando SCAN con valore di conteggio di 10 richiederà 100.000 ripetizioni su un database con 1 milione di chiavi. Se il Round Trip Time medio della rete è di 0,5 millisecondi, verranno spesi circa 50.000 millisecondi (50 secondi) per trasferire le richieste.

      D'altra parte, se il valore di conteggio fosse 100.000, sarebbe necessaria una singola iterazione e solo 0,5 ms sarebbero spesi per trasferirla. Tuttavia, il motore sarebbe completamente bloccato per altre operazioni fino a quando il comando non termina di spazzare tutto il keyspace.

      Oltre a KEYS, molti altri comandi sono potenzialmente dannosi se non utilizzati correttamente. Per visualizzare un elenco di tutti i comandi e la rispettiva complessità temporale, andare all’indirizzo https://redis.io/commands.

      Esempi di potenziali problemi:

      • Script Lua: Redis OSS fornisce un interprete Lua integrato, che consente l'esecuzione di script sul lato server. Gli script Lua su Redis OSS vengono eseguiti a livello di motore e sono atomici per definizione, il che significa che nessun altro comando o script potrà essere eseguito mentre uno script è in esecuzione. Gli script Lua offrono la possibilità di eseguire più comandi, algoritmi decisionali, analisi dei dati e altro direttamente sul motore Redis OSS. Mentre l'atomicità degli script e la possibilità di scaricare l'applicazione sono allettanti, gli script devono essere utilizzati con cura e per piccole operazioni. Attivo ElastiCache, il tempo di esecuzione degli script Lua è limitato a 5 secondi. Gli script che non sono stati scritti nel keyspacei verranno terminati automaticamente dopo un periodo di 5 secondi. Per evitare il danneggiamento dei dati e le incongruenze, il nodo eseguirà il failover se l'esecuzione dello script non è stata completata in 5 secondi e durante l'esecuzione non è stata eseguita alcuna scrittura. Le transazioni sono l'alternativa per garantire la coerenza di più modifiche chiave correlate in Redis OSS. Una transazione consente l'esecuzione di un blocco di comandi, osservando le chiavi esistenti per le modifiche. Se una delle chiavi osservate cambia prima del completamento della transazione, tutte le modifiche vengono scartate.

      • Eliminazione di massa di elementi: il comando DEL accetta più parametri, che sono i nomi di chiave da eliminare. Le operazioni di eliminazione sono sincrone e richiedono un tempo significativo della CPU se l'elenco dei parametri è grande, o contiene un elenco grande, un set ordinato o un hash (strutture di dati che contengono più sottovoci). In altre parole, anche la cancellazione di una singola chiave può richiedere tempo significativo se ha molti elementi. L'alternativa DEL èUNLINK, che è un comando asincrono disponibile a partire da Redis OSS 4. UNLINKdeve essere preferito rispetto a quando possibile. DEL A partire da ElastiCache (Redis OSS) 6x, il lazyfree-lazy-user-del parametro fa sì che il DEL comando si comporti come UNLINK quando è abilitato. Per ulteriori informazioni, consulta Modifiche ai parametri di Redis OSS 6.0.

      • Comandi che agiscono su più chiavi: DEL è stato menzionato prima come comando che accetta più argomenti e il suo tempo di esecuzione sarà direttamente proporzionale a quello. Tuttavia, Redis OSS fornisce molti altri comandi che funzionano in modo simile. Ad esempio, MSET e MGET consentono l'inserimento o il recupero di più chiavi di stringa contemporaneamente. Il loro utilizzo può essere utile per ridurre la latenza di rete intrinseca a più comandi SET o GET individuali. Tuttavia, un ampio elenco di parametri influenzerà l'utilizzo della CPU.

        Sebbene l'utilizzo della CPU da solo non sia la causa di problemi di connettività, dedicare troppo tempo all'elaborazione di uno o pochi comandi su più chiavi può causare l’utilizzo fuori limite di altre richieste e aumentare l'utilizzo complessivo della CPU.

        Il numero di chiavi e le loro dimensioni influenzeranno la complessità del comando e, di conseguenza, il tempo di completamento.

        Altri esempi di comandi che possono agire su più chiavi: HMGET, HMSET, MSETNX, PFCOUNT, PFMERGE, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SUNION, SUNIONSTORE, TOUCH, ZDIFF, ZDIFFSTORE, ZINTER o ZINTERSTORE.

      • Comandi che agiscono su più tipi di dati: Redis OSS fornisce anche comandi che agiscono su una o più chiavi, indipendentemente dal tipo di dati. ElastiCache (Redis OSS) fornisce la metrica KeyBasedCmds per monitorare tali comandi. Questo parametro somma l'esecuzione dei seguenti comandi nel periodo selezionato:

        • Complessità O(N):

          • KEYS

        • O(1)

          • EXISTS

          • OBJECT

          • PTTL

          • RANDOMKEY

          • TTL

          • TYPE

          • EXPIRE

          • EXPIREAT

          • MOVE

          • PERSIST

          • PEXPIRE

          • PEXPIREAT

          • UNLINK (O(N) per recuperare memoria. Tuttavia il processo di recupero della memoria avviene in un thread separato e non blocca il motore

        • Tempi di complessità differenti a seconda del tipo di dati:

          • DEL

          • DUMP

          • RENAME è considerato un comando con complessità O(1), ma esegue DEL internamente. Il tempo di esecuzione varia a seconda delle dimensioni della chiave rinominata.

          • RENAMENX

          • RESTORE

          • SORT

        • Big hash: Hash è un tipo di dati che consente una singola chiave con più sottoelementi chiave-valore. Ogni hash può archiviare 4.294.967.295 elementi e le operazioni su hash di grandi dimensioni possono diventare costose. Analogamente a KEYS, gli hash hanno il comando HKEYS con complessità temporale O(N), dove N è il numero di elementi nell'hash.HSCAN deve essere preferito a HKEYS per evitare comandi di lunga durata. HDEL, HGETALL, HMGET, HMSET e HVALS sono comandi che dovrebbero essere usati con cautela su hash di grandi dimensioni.

      • Altre strutture Big Data: oltre agli hash, altre strutture di dati possono richiedere un uso intensivo della CPU. Insiemi, elenchi, insiemi ordinati e hyperloglog possono anche richiedere molto tempo per essere manipolati a seconda delle dimensioni e dei comandi utilizzati. Per ulteriori informazioni su tali comandi, consultare https://redis.io/commands.

Convalida della connettività di rete

Dopo aver esaminato le configurazioni di rete relative alla risoluzione del DNS, ai gruppi di sicurezza, alle ACL di rete e alle tabelle di routing, la connettività può essere convalidata con VPC Reachability Analyzer e gli strumenti di sistema.

Reachability Analyzer verificherà la connettività di rete e confermerà se tutti i requisiti e le autorizzazioni sono soddisfatti. Per i test seguenti è necessario l'ENI ID (Elastic Network Interface Identification) di uno dei ElastiCache nodi disponibili nel tuo VPC. È possibile trovarlo eseguendo le seguenti operazioni:

  1. Andare su https://console.aws.amazon.com/ec2/v2/home?#NIC:

  2. Filtra l'elenco delle interfacce in base al nome del ElastiCache cluster o all'indirizzo IP ottenuto dalle convalide DNS precedenti.

  3. Annotare o comunque salvare l'ID ENI. Se vengono visualizzate più interfacce, rivedi la descrizione per confermare che appartengano al ElastiCache cluster corretto e scegline una.

  4. Passare alla fase successiva.

  5. Create un percorso di analisi su https://console.aws.amazon.com/vpc/home? # ReachabilityAnalyzer e scegliete le seguenti opzioni:

    • Tipo di fonte: scegli l'istanza se il tuo ElastiCache client funziona su un'istanza Amazon EC2 o un'interfaccia di rete se utilizza un altro servizio, come AWS Fargate Amazon ECS con rete awsvpc AWS Lambda, ecc.) e il rispettivo ID di risorsa (istanza EC2 o ID ENI);

    • Tipo di destinazione: Scegliere Interfaccia di rete e selezionare il ENI di ElastiCachedall'elenco.

    • Porta di destinazione: specifica 6379 per ElastiCache (Redis OSS) o 11211 per (Memcached). ElastiCache Queste sono le porte definite con la configurazione di default e questo esempio presuppone che non vengano modificate.

    • Protocollo: TCP

Creare il percorso di analisi e attendere alcuni minuti per il risultato. Se lo stato non è raggiungibile, aprire i dettagli dell'analisi ed esaminare Esplora analisi per i dettagli in cui le richieste sono state bloccate.

Se i test di raggiungibilità sono stati superati, procedere alla verifica a livello di sistema operativo.

Per convalidare la connettività TCP sulla porta di ElastiCache servizio: su Amazon Linux, Nping è disponibile nel pacchetto nmap e può testare la connettività TCP sulla ElastiCache porta, oltre a fornire il tempo di andata e ritorno della rete per stabilire la connessione. Usalo per convalidare la connettività di rete e la latenza corrente verso il cluster, come illustrato di seguito: ElastiCache 

$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )

Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds

Per impostazione predefinita, nping invia 5 sonde con un ritardo di 1 secondo tra di loro. È possibile utilizzare l'opzione “-c” per aumentare il numero di sonde e “--delay” per cambiare il tempo di invio di un nuovo test.

Se i test con nping falliscono e i test del VPC Reachability Analyzer passano, chiedere all'amministratore di sistema di esaminare le possibili regole firewall basate su host, regole di routing asimmetriche o qualsiasi altra possibile restrizione a livello di sistema operativo.

Sulla ElastiCache console, controlla se Encryption in-transit è abilitata nei dettagli del cluster ElastiCache . Se la crittografia in transito è abilitata, verificare se la sessione della TLS può essere stabilita con il seguente comando:

openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379

Un output esteso è previsto se la connessione e la negoziazione relativa alla TLS hanno esito positivo. Controllare il codice restituito disponibile nell'ultima riga, il valore deve essere 0 (ok). Se openssl restituisce qualcosa di diverso, controllare il motivo dell'errore su https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS.

Se tutti i test dell'infrastruttura e del sistema operativo sono stati superati ma l'applicazione non riesce ancora a connettersi ElastiCache, verifica se le configurazioni dell'applicazione sono conformi alle impostazioni. ElastiCache Gli errori più comuni sono:

  • L'applicazione non supporta la modalità ElastiCache cluster e la modalità cluster ElastiCache è abilitata;

  • L'applicazione non supporta TLS/SSL e ElastiCache ha la crittografia in transito abilitata;

  • L'applicazione supporta TLS/SSL ma non dispone dei flag di configurazione corretti o delle certification authority attendibili;

Limiti relativi alla rete

  • Numero massimo di connessioni: ci sono limiti rigidi per le connessioni simultanee. Ogni ElastiCache nodo consente fino a 65.000 connessioni simultanee su tutti i client. Questo limite può essere monitorato tramite le CurrConnections metriche su. CloudWatch Tuttavia, i client hanno anche i loro limiti per le connessioni in uscita. Su Linux, controllare l'intervallo di porte effimere consentito con il comando:

    # sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

    Nell'esempio precedente, saranno consentite 28231 connessioni dalla stessa origine, allo stesso IP (ElastiCache nodo) e porta di destinazione. Il comando seguente mostra quante connessioni esistono per un ElastiCache nodo specifico (IP 1.2.3.4):

    ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

    Se il numero è troppo alto, il sistema potrebbe sovraccaricarsi tentando di elaborare le richieste di connessione. Si consiglia di prendere in considerazione l'implementazione di tecniche come il pool di connessioni o connessioni persistenti per gestire meglio le connessioni. Ogniqualvolta è possibile, configurare il pool di connessioni per limitare il numero massimo di connessioni ad alcune centinaia. Inoltre, la logica di back-off per gestire i timeout o altre eccezioni relative alla connessione sono consigliabili per evitare interruzioni di connessione in caso di problemi.

  • Limiti del traffico di rete: controllate le seguenti CloudWatch metriche per Redis OSS per identificare i possibili limiti di rete che vengono raggiunti sul nodo: ElastiCache

    • NetworkBandwidthInAllowanceExceeded / NetworkBandwidthOutAllowanceExceeded: pacchetti di rete sagomati perché la velocità effettiva ha superato il limite di larghezza di banda aggregata.

      È importante notare che ogni byte scritto nel nodo primario verrà replicato in N repliche, dove N è il numero di repliche. I cluster con tipi di nodi piccoli, repliche multiple e richieste di scrittura ad alta intensità potrebbero non essere in grado di gestire il backlog di replica. In questi casi, è best practice dimensionare verso l'alto (cambiare il tipo di nodo), aumentare orizzontalmente (aggiungere partizioni in cluster in modalità cluster abilitata), ridurre il numero di repliche o ridurre al minimo il numero di scritture.

    • NetworkConntrackAllowanceExceeded: pacchetti sagomati perché è stato superato il numero massimo di connessioni monitorate in tutti i gruppi di sicurezza assegnati al nodo. Le nuove connessioni probabilmente non avranno esito positivo durante questo periodo.

    • NetworkPackets PerSecondAllowanceExceeded: Numero massimo di pacchetti al secondo superato. I carichi di lavoro basati su un elevato tasso di richieste molto piccole possono raggiungere questo limite prima della larghezza di banda massima.

    I parametri sopra riportati sono il modo ideale per confermare che i nodi raggiungono i loro limiti di rete. Tuttavia, i limiti sono identificabili anche dai plateau sui parametri di rete.

    Se i plateau vengono osservati per periodi prolungati, saranno probabilmente seguiti da ritardo di replica, aumento dei byte utilizzati per la cache, calo della memoria liberabile, elevato swap e utilizzo della CPU. Le istanze Amazon EC2 hanno anche limiti di rete che possono essere monitorati attraverso Parametri di driver ENA. Le istanze Linux con supporto di rete avanzato e driver ENA 2.2.10 o versioni successive possono esaminare i contatori del limite con il comando:

    # ethtool -S eth0 | grep "allowance_exceeded"

Utilizzo CPU

La metrica di utilizzo della CPU è il punto di partenza dell'indagine e i seguenti elementi possono aiutare a restringere i possibili problemi secondari: ElastiCache

  • Redis OSS SlowLogs: la configurazione ElastiCache predefinita mantiene gli ultimi 128 comandi che hanno richiesto più di 10 millisecondi per essere completati. La cronologia dei comandi lenti viene mantenuta durante il tempo di esecuzione del motore e andrà persa in caso di guasto o riavvio. Se l'elenco raggiunge 128 voci, i vecchi eventi verranno rimossi per fare spazio a quelli nuovi. La dimensione dell'elenco degli eventi lenti e il tempo di esecuzione considerato lento può essere modificato tramite i parametri slowlog-max-len e slowlog-log-slower-than in un gruppo di parametri personalizzati. L'elenco dei slow logs può essere recuperato eseguendo SLOWLOG GET 128 sul motore, in cui 128 sono gli ultimi 128 comandi lenti segnalati. Ogni voce ha i campi riportati di seguito:

    1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

    L'evento di cui sopra è avvenuto il 26 dicembre, alle 19:26:07 UTC, ha impiegato 4,8 secondi (4,823 ms) per essere completato ed è stato causato dal comando KEYS richiesto dal client 1.2.3.4.

    Su Linux, la marcatura oraria può essere convertita con la data del comando:

    $ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

    Con Python:

    >>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

    Oppure su Windows con: PowerShell

    PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

    Molti comandi lenti in un breve periodo di tempo (stesso minuto o meno) sono motivo di preoccupazione. Esaminare la natura dei comandi e come possono essere ottimizzati (vedere esempi precedenti). Se i comandi con complessità temporale O(1) vengono segnalati frequentemente, controllare gli altri fattori relativamente a un utilizzo elevato della CPU come menzionato in precedenza.

  • Metriche di latenza: ElastiCache (Redis OSS) fornisce CloudWatch metriche per monitorare la latenza media per diverse classi di comandi. Il datapoint viene calcolato dividendo il numero totale di esecuzioni di comandi nella categoria per il tempo totale di esecuzione nel periodo. È importante comprendere che i risultati dei parametri di latenza sono un aggregato di più comandi. Un singolo comando può causare risultati imprevisti, come i timeout, senza un impatto significativo sui parametri. In questi casi, gli eventi di slow log sarebbero una fonte di informazioni più accurata. L'elenco seguente contiene i parametri di latenza disponibili e i rispettivi comandi che le riguardano.

    • EvalBasedCmdsLatency: relativo ai comandi Lua Script,,; eval evalsha

    • GeoSpatialBasedCmdsLatency: geodist, geohash, geopos, georadius, georadiusbymember, geoadd;

    • GetTypeCmdsLatency: comandi di lettura, indipendentemente dal tipo di dati;

    • HashBasedCmdsLatency: hexists, hget, hgetall, hkeys, hlen, hmget, hvals, hstrlen, hdel, hincrby, hincrbyfloat, hmset, hset, hsetnx;

    • HyperLogLogBasedCmdsLatency: pfselftest, pfcount, pfdebug, pfadd, pfmerge;

    • KeyBasedCmdsLatency: Comandi che possono agire su diversi tipi di dati: dump existskeys,object,pttl,,randomkey,ttl,type,del,expire,expireat,move,persist,pexpire,pexpireat,rename,renamenx,restoreK,sort,unlink;

    • ListBasedCmdsLatency: lindex, len, range, blpop, brpop, brpoplpush, linsert, lpop, push, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx;

    • PubSubBasedCmdsLatency: psubscribe, publish, pubsub, annulla sottoscrizione, sottoscrizione, annullamento dell'iscrizione;

    • SetBasedCmdsLatency: scard, sdiff, sinter, sismember, smembers, srandmember, sunion, sadd, sdiffstore, sinterstore, smove, spop, srem, sunionstore;

    • SetTypeCmdsLatency: scrivere comandi, indipendentemente dal tipo di dati;

    • SortedSetBasedCmdsLatency: zcard, zcount, zrange, zrangebyscore, zrank, zrevrange, zrevrangebyscore, zrevrank, zscore, zrangebylex, zrevrangebylex, zlexcount, zadd. zincrby, zinterstore, zrem, zremrangebyrank, zremrangebyscore, zunionstore, zremrangebylex, zpopmax, zpopmin, bzpopmin, bzpopmax;

    • StringBasedCmdsLatency: bitcount, get, getbit, getrange, mget, strlen, substr, bitpos, append, bitop, bitfield, decr, decrby, getset, incr, incrby, incrbyfloat, mset, msetnx, psetex, set, setbit, setex, setnx, setrange;

    • StreamBasedCmdsLatency: xrange, xrevrange, xlen, xread, xpending, xinfo, xadd, xgroup, readgroup, xack, xclaim, xdel, xtrim, xsetid;

  • Comandi di runtime Redis OSS:

    • info commandstats: fornisce un elenco di comandi eseguiti dall'avvio del motore Redis OSS, il numero cumulativo di esecuzioni, il tempo totale di esecuzione e il tempo medio di esecuzione per comando;

    • client list: fornisce un elenco di client attualmente connessi e informazioni rilevanti come l'utilizzo dei buffer, l'ultimo comando eseguito, ecc.;

  • Backup e replica: le versioni ElastiCache (Redis OSS) precedenti alla 2.8.22 utilizzano un processo biforcato per creare backup ed elaborare sincronizzazioni complete con le repliche. Questo metodo può incorrere in un sovraccarico di memoria significativo per casi d'uso intensivi di scrittura.

    A partire da ElastiCache Redis OSS 2.8.22, è stato introdotto un metodo di backup e replica senza forkless. AWS Il nuovo metodo potrebbe ritardare le scritture al fine di evitare errori. Entrambi i metodi possono causare periodi di maggiore utilizzo della CPU, portare a tempi di risposta più elevati e di conseguenza portare a timeout client durante la loro esecuzione. Controllare sempre se gli errori del client si verificano durante la finestra di backup o il parametro SaveInProgressera 1 nel periodo. Si consiglia di pianificare la finestra di backup per periodi di basso utilizzo per ridurre al minimo la possibilità di problemi con i client o errori di backup.

Connessioni terminate dal lato server

La configurazione predefinita ElastiCache (Redis OSS) mantiene le connessioni client stabilite a tempo indeterminato. Tuttavia, in alcuni casi la terminazione della connessione potrebbe essere auspicabile. Esempio:

  • I bug nell'applicazione client possono causare connessioni da dimenticare e mantenere stabilite con uno stato di inattività. Questo è chiamato “perdita di connessione” e la conseguenza è un costante aumento del numero di connessioni stabilite osservate sul parametro CurrConnections. Questo comportamento può comportare una saturazione del client o del lato. ElastiCache Quando una correzione immediata non è possibile dal lato client, alcuni amministratori impostano un valore di «timeout» nel proprio ElastiCache gruppo di parametri. Il timeout è il tempo in secondi consentito per la persistenza delle connessioni inattive. Se il client non invia alcuna richiesta entro il periodo indicato, il motore Redis OSS interromperà la connessione non appena la connessione raggiunge il valore di timeout. Piccoli valori di timeout possono causare disconnessioni non necessarie e i client dovranno gestirle correttamente e riconnettersi, causando ritardi.

  • La memoria utilizzata per memorizzare le chiavi è condivisa con i buffer client. I client lenti con richieste o risposte di grandi dimensioni possono richiedere una quantità significativa di memoria per gestire i buffer. Le configurazioni predefinite ElastiCache (Redis OSS) non limitano la dimensione dei normali buffer di output del client. Se il limite maxmemory è raggiunto, il motore tenterà di espellere gli elementi per soddisfare l'utilizzo del buffer. In condizioni di memoria estremamente bassa, ElastiCache (Redis OSS) potrebbe scegliere di disconnettere i client che consumano grandi buffer di output dei client per liberare memoria e mantenere lo stato del cluster.

    È possibile limitare la dimensione dei buffer client con configurazioni personalizzate e i client che raggiungono il limite verranno disconnessi. Tuttavia, i client dovrebbero essere in grado di gestire disconnessioni impreviste. I parametri per gestire le dimensioni dei buffer per i client regolari sono i seguenti:

    • client-query-buffer-limit: dimensione massima di una singola richiesta di input;

    • client-output-buffer-limit-normal-soft-limit: Limite flessibile per le connessioni client. La connessione verrà interrotta se rimane al di sopra del limite libero per più del tempo in secondi definito su client-output-buffer-limit normal-soft-seconds o se raggiunge il limite rigido;

    • client-output-buffer-limit-normal-soft-seconds: Tempo consentito per le connessioni che superano il client-output-buffer-limit -; normal-soft-limit

    • client-output-buffer-limit-normal-hard-limit: Una connessione che raggiunge questo limite verrà immediatamente interrotta.

    Oltre ai buffer client normali, le seguenti opzioni controllano il buffer per i nodi di replica e i client Pub/Sub (Publish/Subscribe):

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-replica-soft-seconds;

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-pubsub-soft-limit;

    • client-output-buffer-limit-pubsub-soft-seconds;

    • client-output-buffer-limit-pubsub-hard-limit;

Risoluzione dei problemi lato client per istanze Amazon EC2

Il carico e la reattività sul lato client possono influire anche sulle richieste di. ElastiCache I limiti dell'istanza EC2 e del sistema operativo devono essere attentamente esaminati durante la risoluzione dei problemi di connettività intermittente o timeout. Alcuni punti chiave da osservare:

  • CPU:

    • Utilizzo della CPU dell'istanza EC2: assicurarsi che la CPU non sia stata saturata o vicina al 100 percento. L'analisi storica può essere effettuata tramite CloudWatch, tuttavia, tieni presente che la granularità dei punti dati è di 1 minuto (con il monitoraggio dettagliato abilitato) o di 5 minuti;

    • Se si utilizza istanze EC2 burstable, assicurarsi che il loro saldo di credito della CPU non sia stato esaurito. Queste informazioni sono disponibili sulla metrica. CPUCreditBalance CloudWatch

    • Brevi periodi di utilizzo elevato della CPU possono causare timeout senza che ciò comporti un utilizzo al 100%. CloudWatch Tali casi richiedono un monitoraggio in tempo reale con strumenti del sistema operativo come top, ps e mpstat.

  • Rete

    • Verificare se la velocità effettiva di rete è inferiore ai valori accettabili in base alle capacità dell'istanza. Per ulteriori informazioni consultare Tipi di istanza Amazon EC2

    • Sulle istanze con ena Driver di rete avanzato, controllare le Statistiche ENAper i timeout o i limiti superati. Le seguenti statistiche sono utili per verificare la saturazione dei limiti di rete:

      • bw_in_allowance_exceeded / bw_out_allowance_exceeded: numero di pacchetti sagomati a causa di una eccessiva velocità effettiva in entrata o in uscita;

      • conntrack_allowance_exceeded: numero di pacchetti eliminati a causa dei Limiti di monitoraggio delle connessioni dei gruppi di sicurezza. Le nuove connessioni avranno esito negativo quando questo limite è saturo;

      • linklocal_allowance_exceeded: numero di pacchetti eliminati a causa di richieste eccessive per l'istanza di meta-dati, NTP tramite DNS VPC. Il limite è di 1024 pacchetti al secondo per tutti i servizi;

      • pps_allowance_exceeded: numero di pacchetti eliminati a causa di un rapporto eccessivo di pacchetti al secondo. Il limite PPS può essere raggiunto quando il traffico di rete è costituito da migliaia o milioni di richieste molto piccole al secondo. ElastiCache il traffico può essere ottimizzato per utilizzare meglio i pacchetti di rete tramite pipeline o comandi che eseguono più operazioni contemporaneamente, ad esempio. MGET GET

Dissezione del tempo necessario per completare una singola richiesta

  • In rete: Tcpdump and Wireshark (tshark sulla riga di comando) sono strumenti utili per capire quanto tempo ha impiegato la richiesta per percorrere la rete, avviare il ElastiCache motore e ottenere un ritorno. L'esempio seguente evidenzia una singola richiesta creata con il seguente comando: 

    $ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

    In parallelo al comando di cui sopra, tcpdump era in esecuzione ed è stato restituito:

    $ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

    Dall'output di cui sopra possiamo confermare che l'handshake a tre vie TCP è stato completato in 222 microsecondi (918091 - 917869) e che il comando ping è stato inviato e restituito in 173 microsecondi (918295 - 918122).

    Ci sono voluti 438 microsecondi (918307 - 917869) dalla richiesta alla chiusura della connessione. Tali risultati confermerebbero che i tempi di risposta della rete e del motore sono buoni e l'indagine può concentrarsi su altri componenti.

  • Nel sistema operativo: Strace può aiutare a identificare le lacune temporali a livello di sistema operativo. L'analisi delle applicazioni effettive sarebbe molto più ampia e sono consigliati profiler di applicazioni specializzati o debugger. L'esempio seguente mostra solo se i componenti del sistema operativo di base funzionano come previsto, in caso contrario potrebbero essere necessarie ulteriori indagini. Usando lo stesso PING comando Redis OSS con strace otteniamo:

    $ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

    Nell'esempio precedente, il comando ha impiegato poco più di 54 millisecondi per essere completato (752110 - 697712 = 54398 microsecondi).

    Una quantità significativa di tempo, circa 20 ms, è stata impiegata per istanziare nc ed effettuare la risoluzione dei nomi (da 697712 a 717890), dopodiché sono stati necessari 2 ms per creare il socket TCP (da 745659 a 747858) e 0,4 ms (da 747858 a 748330) per inviare e ricevere la risposta per la richiesta.