Best practice Limitazioni Prezzi Monitoraggio Utilizzo del tiering di dati Ripristino di dati da backup su cluster con tiering di dati abilitato

Suddivisione dei dati su più livelli in ElastiCache

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

Nei ElastiCache cluster con suddivisione dei dati su più livelli, ElastiCache monitora l'ultimo orario di accesso di ogni elemento archiviato. Quando la memoria disponibile (DRAM) è completamente consumata, ElastiCache utilizza un algoritmo utilizzato meno di recente (LRU) per spostare automaticamente gli elementi a cui si accede meno frequentemente dalla memoria a. SSD Quando successivamente SSD si accede ai dati su, 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.

Si noti che quando si utilizza il tiering dei dati, le chiavi stesse rimangono sempre in memoria, mentre LRU regolano il posizionamento dei valori nella memoria rispetto al 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 da 500 byte, puoi aspettarti in media 300 microsecondi di latenza aggiuntivi per le richieste ai dati archiviati rispetto alle richieste ai dati in memoria. SSD

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 supportati in. OSS ElastiCache Non è necessaria alcuna modifica lato client per utilizzare questa caratteristica.

Argomenti

Best practice
Limitazioni
Prezzi
Monitoraggio
Utilizzo del tiering di dati
Ripristino di dati da backup su cluster con tiering di dati abilitato

Best practice

È preferibile seguire le best practice seguenti:

Il data tiering è ideale per i carichi di lavoro che accedono regolarmente fino al 20% del set di dati complessivo e per le applicazioni che possono tollerare una latenza aggiuntiva durante l'accesso ai dati su. SSD
Quando si utilizza la SSD capacità disponibile su nodi a più livelli di dati, è consigliabile che la dimensione del valore sia maggiore della dimensione della chiave. Quando gli elementi vengono spostati tra DRAM eSSD, le chiavi rimarranno sempre in memoria e solo i valori vengono spostati nel 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 versione 7.0.7 e successive. OSS 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 versione 7.0.7 e successive. OSS Per ulteriori informazioni, consulta Modalità di implementazione di sincronizzazione e backup.
Gli elementi di dimensioni superiori a 128 MiB non vengono spostati in. SSD

Prezzi

I nodi R6gd hanno una capacità totale (memoria+SSD) 4,8 volte superiore e possono aiutarti a ottenere risparmi di oltre il 60% quando funzionano al massimo utilizzo rispetto ai nodi R6g (solo memoria). Per ulteriori ElastiCache informazioni, consulta la pagina dei prezzi.

Monitoraggio

ElastiCache offre metriche progettate specificamente per monitorare i cluster di prestazioni che utilizzano il tiering dei dati. Per monitorare il rapporto tra gli articoli DRAM rispetto aSSD, 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 OSS cluster Valkey o Redis che utilizzano il tiering dei dati, consulta. Metriche per Valkey e Redis OSS

Utilizzo del tiering di dati

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.

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 ().AWS CLI ElastiCache API Quando si crea un cluster utilizzando tipi di nodo nella famiglia r6gd, il tiering di dati è abilitato.

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

Accedi a AWS Management Console e apri la ElastiCache console all'indirizzo https://console.aws.amazon.com/elasticache/.
Nel riquadro di navigazione, scegliere Backups (Backup).
Nell'elenco dei backup, scegli la casella a sinistra del nome di backup da cui desideri eseguire il ripristino.
Scegli Restore (Ripristina).
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. Numero di shard: scegli il numero di shard che desideri 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. Scegli un VPC: scegli il tipo VPC in cui creare questo cluster.
10. Gruppo di parametri: scegli un gruppo di parametri che riservi memoria sufficiente per l'OSSoverhead di Valkey o Redis per il tipo di nodo selezionato.
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.

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
    }
}

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

DNSnomi e IP sottostante

Preparazione di un cluster in ElastiCache