Suddivisione dei dati su più livelli in ElastiCache

ElastiCache per i cluster Valkey o Redis OSS che comprendono un gruppo di replica e utilizzano un tipo di nodo della famiglia r6gd, i dati vengono suddivisi su più livelli tra la memoria e lo storage SSD locale (unità a stato solido). Il data tiering offre una nuova opzione in termini di rapporto prezzo/prestazioni per i carichi di lavoro Valkey o Redis OSS utilizzando unità a stato solido () a basso costo in ogni nodo del cluster oltre all'archiviazione dei dati in memoria. SSDs È ideale per carichi di lavoro che accedono regolarmente fino al 20% del set di dati complessivo e per applicazioni che possono tollerare una latenza aggiuntiva quando si accede ai dati su SSD.

Nei ElastiCache cluster con suddivisione dei dati su più livelli, monitora l'ultimo orario di accesso di ogni elemento archiviato. ElastiCache Quando la memoria disponibile (DRAM) è completamente consumata, ElastiCache utilizza un algoritmo utilizzato più di recente (LRU) per spostare automaticamente gli elementi a cui si accede meno frequentemente dalla memoria all'SSD. Quando successivamente si accede ai dati sull'SSD, li riporta ElastiCache automaticamente e in modo asincrono in memoria prima di elaborare la richiesta. Se si dispone di un carico di lavoro che accede regolarmente a un sottoinsieme di dati, il tiering di dati è un modo ottimale per dimensionare la capacità a costi contenuti.

Tieni presente che quando utilizzi il tiering dei dati, le chiavi rimangono sempre in memoria, mentre posizionamento dei valori sulla memoria viene gestito da LRU e non dal disco. In generale, è preferibile che le dimensioni delle chiavi siano inferiori a quelle dei valori quando utilizzi il tiering dei dati.

Il tiering dei dati è progettato per avere un impatto minimo sulle prestazioni dei carichi di lavoro delle applicazioni. Ad esempio, supponendo valori String di 500 byte, è possibile prevedere in media ulteriori 300 microsecondi di latenza per le richieste ai dati archiviati su SSD rispetto alle richieste ai dati in memoria.

Con le dimensioni più grandi dei nodi di tiering di dati (cache.r6gd.16xlarge), è possibile archiviare fino a 1 petabyte in un singolo cluster a 500 nodi (500 TB quando si utilizza 1 replica di lettura). Il tiering dei dati è compatibile con tutti i comandi e le strutture dati Valkey o Redis OSS supportati in. ElastiCache Non è necessaria alcuna modifica lato client per utilizzare questa caratteristica.

Best practice

È preferibile seguire le best practice seguenti:

• Il tiering dei dati è ideale per carichi di lavoro che accedono regolarmente fino al 20% del set di dati complessivo e per applicazioni che possono tollerare una latenza supplementare durante l’accesso ai dati su SSD.

• Quando utilizzi la capacità SSD disponibile su nodi con tiering di dati, è ti consigliamo una dimensione del valore superiore a quella della chiave. Quando gli elementi vengono spostati tra DRAM e SSD, le chiavi rimarranno sempre in memoria e solo i valori verranno spostati al livello SSD.

Limitazioni

Il livello di dati presenta le seguenti limitazioni:

• È possibile utilizzare il tiering di dati solo su cluster che fanno parte di un gruppo di replica.

• Il tipo di nodo utilizzato deve appartenere alla famiglia r6gd, disponibile nelle regioni seguenti: us-east-2, us-east-1, us-west-2, us-west-1, eu-west-1, eu-central-1, eu-north-1, eu-west-3, ap-northeast-1, ap-southeast-1, ap-southeast-2, ap-south-1, ca-central-1 e sa-east-1.

• È necessario utilizzare un motore Valkey 7.2 o successivo oppure Redis OSS 6.2 o successivo.

• Non è possibile ripristinare un backup di un cluster r6gd in un altro cluster a meno che non utilizzi anche r6gd.

• Non è possibile esportare un backup su Amazon S3 per cluster con tiering di dati.

• La migrazione online non è supportata per i cluster in esecuzione sul tipo di nodo r6gd.

• Il dimensionamento non è supportato da dati un cluster di tiering di dati (ad esempio, un cluster che utilizza un tipo di nodo r6gd) a un cluster che non utilizza il tiering di dati (ad esempio, un cluster che utilizza un tipo di nodo r6g). Per ulteriori informazioni, consulta Ridimensionamento ElastiCache.

• La scalabilità automatica è supportata sui cluster che utilizzano la suddivisione in più livelli dei dati per Valkey versione 7.2 e successive e Redis OSS versione 7.0.7 e successive. Per ulteriori informazioni, consulta Auto Scaling dei cluster Valkey e Redis OSS

• Il tiering di dati supporta solo policy maxmemory volatile-lru, allkeys-lru, volatile-lfu, allkeys-lfu e noeviction.

• Il salvataggio senza forkless è supportato per Valkey versione 7.2 e successive e Redis OSS versione 7.0.7 e successive. Per ulteriori informazioni, consulta Modalità di implementazione di sincronizzazione e backup.

• Gli elementi più grandi di 128 MiB non vengono spostati su SSD.

Prezzi

I nodi R6gd hanno una capacità totale 4,8 volte superiore (memoria + SSD) e possono contribuire a un risparmio di oltre il 60% quando si esegue al massimo utilizzo rispetto ai nodi R6g (solo memoria). Per ulteriori informazioni, consulta Prezzi di ElastiCache .

Monitoraggio

ElastiCache offre metriche progettate specificamente per monitorare i cluster di prestazioni che utilizzano il tiering dei dati. Per monitorare il rapporto tra gli elementi in DRAM e quelli SSD, puoi utilizzare la CurrItems metrica di Metrics for Valkey e Redis OSS. Puoi calcolare la percentuale come: (CurrItems con Dimension: Tier = Memory * 100)/(CurrItems senza filtro dimensionale).

Se la politica di sfratto configurata lo consente, ElastiCache inizierà a sfrattare gli articoli quando la percentuale di elementi in memoria scende al di sotto del 5%. Sui nodi configurati con nessuna politica di espulsione, le operazioni di scrittura riceveranno un errore di esaurimento della memoria.

Si consiglia comunque di prendere in considerazione la scalabilità orizzontale per i cluster abilitati alla modalità cluster o la scalabilità verticale per i cluster disabilitati in modalità cluster quando la percentuale di elementi in memoria scende al di sotto del 5%. Per ulteriori informazioni sulla scalabilità, vedere. Scalabilità dei cluster in Valkey o Redis OSS (modalità cluster abilitata) Per ulteriori informazioni sulle metriche per i cluster Valkey o Redis OSS che utilizzano il tiering dei dati, consulta. Metriche per Valkey e Redis OSS

Utilizzo del tiering di dati

Utilizzo della suddivisione in più livelli dei dati utilizzando il AWS Management Console

Quando si crea un cluster come parte di un gruppo di replica, il tiering di dati viene utilizzato selezionando un tipo di nodo dalla famiglia r6gd, ad esempio cache.r6gd.xlarge. La selezione di quel tipo di nodo abilita automaticamente il tiering di dati.

Per ulteriori informazioni sulla creazione di cluster, consulta Creazione di un cluster per Valkey o Redis OSS.

Abilitazione della suddivisione dei dati su più livelli utilizzando il AWS CLI

Quando si crea un gruppo di replica utilizzando il AWS CLI, si utilizza il tiering dei dati selezionando un tipo di nodo dalla famiglia r6gd, ad esempio cache.r6gd.xlarge e impostando il parametro. --data-tiering-enabled

Non è possibile disattivare il tiering di dati quando si seleziona un tipo di nodo dalla famiglia r6gd. Se si imposta il parametro --no-data-tiering-enabled, l'operazione avrà esito negativo.

Per Linux, macOS o Unix:

aws elasticache create-replication-group \
   --replication-group-id redis-dt-cluster \
   --replication-group-description "Redis OSS cluster with data tiering" \
   --num-node-groups 1 \
   --replicas-per-node-group 1 \
   --cache-node-type cache.r6gd.xlarge \
   --engine redis \   
   --cache-subnet-group-name default \
   --automatic-failover-enabled \
   --data-tiering-enabled

Per Windows:

aws elasticache create-replication-group ^
   --replication-group-id redis-dt-cluster ^
   --replication-group-description "Redis OSS cluster with data tiering" ^
   --num-node-groups 1 ^
   --replicas-per-node-group 1 ^
   --cache-node-type cache.r6gd.xlarge ^
   --engine redis ^   
   --cache-subnet-group-name default ^
   --automatic-failover-enabled ^
   --data-tiering-enabled

Dopo aver eseguito questa operazione, verrà visualizzata una risposta simile alla seguente:

{
    "ReplicationGroup": {
        "ReplicationGroupId": "redis-dt-cluster",
        "Description": "Redis OSS cluster with data tiering",
        "Status": "creating",           
        "PendingModifiedValues": {},
        "MemberClusters": [
            "redis-dt-cluster"
        ],
        "AutomaticFailover": "enabled",
        "DataTiering": "enabled",
        "SnapshotRetentionLimit": 0,
        "SnapshotWindow": "06:00-07:00",
        "ClusterEnabled": false,
        "CacheNodeType": "cache.r6gd.xlarge",       
        "TransitEncryptionEnabled": false,
        "AtRestEncryptionEnabled": false
    }
}

Ripristino di dati da backup su cluster con tiering di dati abilitato

È possibile ripristinare un backup in un nuovo cluster con il tiering dei dati abilitato utilizzando (Console), () o (API).AWS CLI ElastiCache Quando si crea un cluster utilizzando tipi di nodo nella famiglia r6gd, il tiering di dati è abilitato.

Ripristino di dati da backup su cluster con tiering di dati abilitato (console)

Per ripristinare un backup su un nuovo cluster con tiering di dati abilitato (console)

1. Accedi a AWS Management Console e apri la ElastiCache console all'indirizzo https://console.aws.amazon.com/elasticache/.

2. Nel riquadro di navigazione, scegliere Backups (Backup).

3. Nell'elenco dei backup, scegli la casella a sinistra del nome di backup da cui desideri eseguire il ripristino.

4. Scegli Restore (Ripristina).

5. Completare la finestra di dialogo Restore Cluster (Ripristina cluster). Assicurarsi di completare tutti i campi Obbligatori e gli eventuali altri che si desidera modificare rispetto alle impostazioni predefinite.

   1. Cluster ID (ID cluster) : Obbligatorio. Il nome del nuovo cluster.

   2. Modalità cluster abilitata (scalabilità orizzontale): scegli questa opzione per un cluster Valkey o Redis OSS (modalità cluster abilitata).

   3. Tipo di nodo – Specificare cache.r6gd.xlarge o qualsiasi altro tipo di nodo della famiglia r6gd.

   4. Number of Shards (Numero di partizioni) - Scegliere il numero di partizioni desiderato nel nuovo cluster (API/CLI: gruppi di nodi).

   5. Replicas per Shard (Repliche per partizioni) - Scegliere il numero di nodi di replica di lettura desiderato in ognle partizioni.

   6. Slots and keyspaces (Slot e keyspaces) - Scegliere la modalità di distribuzione delle chiavi tra le partizioni. Se si sceglie di specificare le distribuzioni chiave, completare la tabella specificando gli intervalli chiave per ognle partizioni.

   7. Availability zone(s) (Zone di disponibilità) - Specificare la modalità di selezione delle zone di disponibilità del cluster.

   8. Porta: modifica solo se il nuovo cluster deve utilizzare una porta diversa.

   9. Choose a VPC (scegliere un VPC) : Scegliere il VPC in cui creare questo cluster.

   10. Gruppo di parametri: scegli un gruppo di parametri che riservi memoria sufficiente per l'overhead di Valkey o Redis OSS per il tipo di nodo selezionato.

6. Dopo aver selezionato tutte le impostazioni desiderate, scegli Crea.

Per ulteriori informazioni sulla creazione di cluster, consulta Creazione di un cluster per Valkey o Redis OSS.

Ripristino di dati da backup su cluster con tiering di dati abilitato (AWS CLI)

Quando si crea un gruppo di replica utilizzando AWS CLI, per impostazione predefinita viene utilizzato il tiering dei dati su più livelli selezionando un tipo di nodo dalla famiglia r6gd, ad esempio cache.r6gd.xlarge e impostando il parametro. --data-tiering-enabled

Non è possibile disattivare il tiering di dati quando si seleziona un tipo di nodo dalla famiglia r6gd. Se si imposta il parametro --no-data-tiering-enabled, l'operazione avrà esito negativo.

Per Linux, macOS o Unix:

aws elasticache create-replication-group \
   --replication-group-id redis-dt-cluster \
   --replication-group-description "Redis OSS cluster with data tiering" \
   --num-node-groups 1 \
   --replicas-per-node-group 1 \
   --cache-node-type cache.r6gd.xlarge \
   --engine redis \   
   --cache-subnet-group-name default \
   --automatic-failover-enabled \
   --data-tiering-enabled \
   --snapshot-name my-snapshot

Per Linux, macOS o Unix:

aws elasticache create-replication-group ^
   --replication-group-id redis-dt-cluster ^
   --replication-group-description "Redis OSS cluster with data tiering" ^
   --num-node-groups 1 ^
   --replicas-per-node-group 1 ^
   --cache-node-type cache.r6gd.xlarge ^
   --engine redis ^   
   --cache-subnet-group-name default ^
   --automatic-failover-enabled ^
   --data-tiering-enabled ^
   --snapshot-name my-snapshot

Dopo aver eseguito questa operazione, verrà visualizzata una risposta simile alla seguente:

{
    "ReplicationGroup": {
        "ReplicationGroupId": "redis-dt-cluster",
        "Description": "Redis OSS cluster with data tiering",
        "Status": "creating",           
        "PendingModifiedValues": {},
        "MemberClusters": [
            "redis-dt-cluster"
        ],
        "AutomaticFailover": "enabled",
        "DataTiering": "enabled",
        "SnapshotRetentionLimit": 0,
        "SnapshotWindow": "06:00-07:00",
        "ClusterEnabled": false,
        "CacheNodeType": "cache.r6gd.xlarge",        
        "TransitEncryptionEnabled": false,
        "AtRestEncryptionEnabled": false
    }
}