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à.
# Scelta delle dimensioni dei nodi
La dimensione del nodo selezionata per il ElastiCache cluster influisce sui costi, sulle prestazioni e sulla tolleranza agli errori.
## Dimensione del nodo (Valkey e Redis OSS)
Per informazioni sui vantaggi dei processori Graviton, vedere [Processore AWS Graviton](https://aws.amazon.com/pm/ec2-graviton/).
Rispondere alle seguenti domande può aiutarvi a determinare il tipo di nodo minimo necessario per l'implementazione di Valkey o Redis OSS:
+ Si prevedono carichi di lavoro legati al velocità di trasmissione effettiva con più connessioni client?
Se questo è il caso e stai utilizzando Redis OSS versione 5.0.6 o successiva, puoi ottenere velocità e latenza migliori con le nostre I/O funzionalità avanzate, ove disponibili, CPUs utilizzate per scaricare le connessioni client, per conto del motore Redis OSS. Se utilizzi Redis OSS versione 7.0.4 o successiva, oltre ai I/O, you will get additional acceleration with enhanced I/O multiplexing, where each dedicated network IO thread pipelines commands from multiple clients into the Redis OSS engine, taking advantage of Redis OSS' ability to efficiently process commands in batches. In ElastiCache for Redis OSS v7.1 and above, we extended the enhanced I/O threads functionality to also handle the presentation layer logic. By presentation layer, what we mean is that Enhanced I/O thread avanzati ora non solo leggono l'input del client, ma analizzano anche l'input nel formato di comando binario Redis OSS, che viene quindi inoltrato al thread principale per l'esecuzione, garantendo un aumento delle prestazioni. Per ulteriori dettagli, consulta il [post del blog](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/) e la pagina delle [versioni supportate](VersionManagement.md#supported-engine-versions).
+ Si dispone di carichi di lavoro che accedono regolarmente a una piccola percentuale dei dati?
Se questo è il caso e utilizzi la versione 6.2 o successiva del motore Redis OSS, puoi sfruttare il tiering dei dati scegliendo il tipo di nodo r6gd. Con il tiering di dati, i dati utilizzati meno di recente vengono archiviati su SSD. Quando vengono recuperati, è previsto un piccolo costo di latenza, bilanciato dai risparmi sui costi. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
Per ulteriori informazioni, consulta [Tipi di nodi supportati](CacheNodes.SupportedTypes.md).
+ Di quanta memoria in totale necessiti per i tuoi dati?
Per ottenere una stima generale, prendere la dimensione degli elementi che si desidera memorizzare nella cache. Moltiplicare questa dimensione per il numero degli elementi da conservare nella cache contemporaneamente. Per ottenere una stima veritiera delle dimensioni degli elementi, serializza gli elementi della cache e contane i caratteri. Poi dividi questo numero per il numero delle partizioni nel cluster.
Per ulteriori informazioni, consulta [Tipi di nodi supportati](CacheNodes.SupportedTypes.md).
+ Quale versione di Redis OSS stai utilizzando?
Le versioni di Redis OSS precedenti alla 2.8.22 richiedono di riservare più memoria per il failover, le istantanee, la sincronizzazione e la promozione di una replica alle operazioni principali. Occorre infatti disporre di una quantità di memoria sufficiente per tutte le operazioni di scrittura necessarie, affinché il processo vada a buon fine.
Redis OSS versione 2.8.22 e successive utilizzano un processo di salvataggio senza forkless che richiede meno memoria disponibile rispetto al processo precedente.
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Modalità di implementazione di sincronizzazione e backup](Replication.Redis.Versions.md)
+ [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md)
+ Quant'è consistente il carico di lavoro in scrittura della tua applicazione?
Le applicazioni caratterizzate da elevata attività di scrittura possono richiedere molta più memoria disponibile, non occupata dai dati, per acquisire snapshot o per il failover. Ogni volta che viene svolto il processo `BGSAVE`, è necessario disporre di memoria sufficiente che non viene utilizzata dai dati per contenere tutte le scritture che avvengono durante il processo `BGSAVE` Esempi sono quando si esegue uno snapshot, quando si sincronizza un cluster primario con una replica in un cluster e quando si abilita la caratteristica AOF (Append-only File). Un altro è la promozione di una replica al ruolo di nodo primario (se la funzione Multi-AZ è abilitata). Il caso peggiore è quando tutti i tuoi dati vengono riscritti durante il processo. In questo caso, è necessaria una dimensione di istanza di nodo con il doppio della memoria necessaria per i soli dati.
Per informazioni più dettagliate, consulta [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md).
+ L'implementazione sarà un cluster Valkey o Redis OSS autonomo (modalità cluster disabilitata) oppure un cluster Valkey o Redis OSS (modalità cluster abilitata) con più shard?
**Cluster Valkey o Redis OSS (modalità cluster disabilitata)**
Se stai implementando un cluster Valkey o Redis OSS (modalità cluster disabilitata), il tipo di nodo deve essere in grado di ospitare tutti i tuoi dati più l'overhead necessario, come descritto nel bullet precedente.
Si supponga, ad esempio, di stimare che la dimensione totale di tutti gli articoli sia di 12 GB. In questo caso, puoi usare un `cache.m3.xlarge` nodo con 13,3 GB di memoria o un `cache.r3.large` con 13,5 GB di memoria. Tuttavia, potrebbe occorrere più memoria per le operazioni di `BGSAVE`. Se l'applicazione è pesante da scrivere, raddoppiare i requisiti di memoria fino ad almeno 24 GB. Quindi, usa un `cache.m3.2xlarge` con 27,9 GB di memoria o`cache.r3.xlarge` con 30,5 GB di memoria.
**Valkey o Redis OSS (modalità cluster abilitata) con più shard**
Se stai implementando un cluster Valkey o Redis OSS (modalità cluster abilitata) con più shard, il tipo di nodo deve essere in grado di contenere byte di dati. `bytes-for-data-and-overhead / number-of-shards`
Se, ad esempio, stimi in 12 GB la dimensione totale di tutti gli elementi e disponi di due partizioni. In questo caso, puoi usare un nodo `cache.m3.large` con 6,05 GB di memoria (12 GB/2). Tuttavia, potrebbe occorrere più memoria per le operazioni di `BGSAVE`. Se l'applicazione è pesante da scrivere, raddoppiare i requisiti di memoria fino ad almeno 12 GB per partizioni. Quindi, usa un `cache.m3.xlarge` con 13,3 GB di memoria o `cache.r3.large` con 13,5 GB di memoria.
+ Stai usando Local Zones?
[Le Local Zones](Local_zones.md) ti consentono di collocare risorse come un ElastiCache cluster in più posizioni vicine ai tuoi utenti. Tuttavia, quando si sceglie la dimensione del nodo, tenere presente che le dimensioni dei nodi disponibili sono limitate alle seguenti al momento, indipendentemente dai requisiti di capacità:
+ Generazione attuale:
**Tipi di nodi M5:** `cache.m5.large`, `cache.m5.xlarge`, `cache.m5.2xlarge`, `cache.m5.4xlarge`, `cache.m5.12xlarge`, `cache.m5.24xlarge`
**Tipi di nodi R5:** `cache.r5.large`, `cache.r5.xlarge`, `cache.r5.2xlarge`, `cache.r5.4xlarge`, `cache.r5.12xlarge`, `cache.r5.24xlarge`
**Tipi di nodo T3:** `cache.t3.micro`, `cache.t3.small`, `cache.t3.medium`
Mentre il cluster è in esecuzione, è possibile monitorare l'utilizzo della memoria, l'utilizzo del processore, gli accessi alla cache e le metriche relative agli errori di cache pubblicati su. CloudWatch È possibile notare che il cluster non ha la frequenza di accessi desiderata o che le chiavi vengono espulse troppo spesso. In questi casi, puoi scegliere una dimensione di nodi diversa con specifiche di memoria e CPU maggiori.
Quando monitorate l'utilizzo della CPU, ricordate che Valkey e Redis OSS sono a thread singolo. Pertanto, moltiplica l'utilizzo della CPU segnalato per il numero di core CPU per ottenere l'effettivo utilizzo. Ad esempio, una CPU a quattro core che riporta un tasso di utilizzo del 20% è in realtà l'OSS Redis a un core in esecuzione con un utilizzo dell'80%.
## Dimensione del nodo (Memcached)
I cluster Memcached possono contenere uno o più nodi, tra i quali ripartire i propri dati. Per questo motivo, le esigenze di memoria del cluster e la memoria di un nodo sono correlate, ma non corrispondenti. La necessaria capacità di memoria del cluster può contare su pochi nodi grandi o molti nodi piccoli. Inoltre, in base alle mutevoli esigenze, è possibile aggiungere nodi al cluster o rimuoverli in qualunque momento, pagando solo ciò che occorre.
La capacità di memoria totale del cluster viene calcolata moltiplicando il numero di nodi nel cluster per la capacità di RAM di ciascun nodo, al netto del carico operativo del sistema. La capacità di un nodo dipende dalla sua tipologia.
```
cluster_capacity = number_of_nodes * (node_capacity - system_overhead)
```
Il numero dei suoi nodi è un fattore determinante per la disponibilità di un cluster che esegue Memcached. Il fallimento di un solo nodo può influire sulla disponibilità dell'applicazione e sul carico sul database back-end. In tal caso, ElastiCache predispone un nodo sostitutivo per un nodo guasto e questo viene ripopolato. Per ridurre questo potenziale impatto sulla disponibilità, basta distribuire la memoria e la capacità di calcolo su più nodi a capacità ridotta, anziché su meno nodi ad ampia capacità.
Se, ad esempio, occorrono 35 GB di memoria cache, è possibile impostare una qualsiasi delle seguenti configurazioni:
+ 11 nodi `cache.t2.medium`, ciascuno con 3,22 GB di memoria e 2 thread = 35,42 GB e 22 thread.
+ 6 nodi `cache.m4.large`, ciascuno con 6,42 GB di memoria e 2 thread = 38,52 GB e 12 thread.
+ 3 nodi `cache.r4.large`, ciascuno con 12,3 GB di memoria e 2 thread = 36,90 GB e 6 thread.
+ 3 nodi `cache.m4.xlarge`, ciascuno con 14,28 GB di memoria e 4 thread = 42,84 GB e 12 thread.
**Opzioni disponibili per i nodi a confronto**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/CacheNodes.SelectSize.html)
Ognuna di queste opzioni offre una disponibilità di memoria simile, ma capacità e costi di elaborazione diversi. Per confrontare i costi delle tue opzioni specifiche, consulta la pagina [ ElastiCache dei prezzi di Amazon](https://aws.amazon.com/elasticache/pricing/).
Nel caso dei cluster che eseguono Memcached, parte della memoria disponibile su ciascun nodo viene utilizzata per la gestione della connessione. Per ulteriori informazioni, consulta [Sovraccarico delle connessioni Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead)
L'utilizzo di più nodi richiede la distribuzione delle chiavi tra gli stessi. Ogni nodo dispone del proprio endpoint. Per una gestione semplificata degli endpoint, puoi utilizzare ElastiCache la funzionalità Auto Discovery, che consente ai programmi client di identificare automaticamente tutti i nodi di un cluster. Per ulteriori informazioni, consulta [Identifica automaticamente i nodi del cluster (Memcached)](AutoDiscovery.md).
In alcuni casi, è possibile non essere sicuri di quanta capacità è necessaria. In caso affermativo, per i test consigliamo di iniziare con un `cache.m5.large` nodo. Quindi monitora l'utilizzo della memoria, l'utilizzo della CPU e la frequenza di accesso alla cache con le ElastiCache metriche pubblicate su Amazon. CloudWatch Per ulteriori informazioni sulle CloudWatch metriche per ElastiCache, consulta. [Monitoraggio dell'utilizzo con CloudWatch Metrics](CacheMetrics.md) Per carichi di lavoro di produzione particolarmente consistenti, i nodi R5 garantiscono le prestazioni e il valore di costo della RAM migliori.
Se il cluster non garantisce l'hit rate desiderato, basta aggiungere più nodi, aumentando così la memoria totale in esso disponibile.
Se il cluster risulta vincolato dalla CPU ma, comunque, con un hit rate sufficiente, prova a configurare un nuovo cluster con un tipo di nodo che garantisca maggiore potenza di calcolo.