Riduzione al minimo dei tempi di inattività ElastiCache utilizzando Multi-AZ con Valkey e Redis OSS

Esistono diversi casi in cui ElastiCache con Valkey e Redis OSS potrebbe essere necessario sostituire un nodo primario, tra cui alcuni tipi di manutenzione pianificata e l'improbabile eventualità di un guasto del nodo primario o della zona di disponibilità.

Questa sostituzione comporta alcuni tempi di inattività per il cluster, ma se la funzione Multi-AZ è abilitata, il tempo di inattività viene ridotto al minimo. Il ruolo del nodo primario eseguirà automaticamente il failover su una delle repliche di lettura. Non è necessario creare ed effettuare il provisioning di un nuovo nodo primario, in quanto ElastiCache gestirà la situazione in modo trasparente. Questo failover e la promozione delle repliche garantiscono la possibilità di ricominciare a scrivere nel nuovo nodo primario non appena la promozione è terminata.

ElastiCache propaga anche il nome Domain Name Service (DNS) della replica promossa. Questo perché se l'applicazione scrive nell'endpoint primario, allora non è richiesta alcuna modifica dell'endpoint nell'applicazione. Tuttavia, poiché la lettura viene eseguita da singoli endpoint, occorre assicurarsi di modificare l'endpoint di lettura della replica promossa al nodo primario nel nuovo endpoint della replica.

In caso di sostituzioni dei nodi pianificati, iniziati a causa di aggiornamenti di manutenzione o aggiornamenti self-service, fare attenzione a quanto segue:

È possibile abilitare Multi-AZ utilizzando la console di gestione, o il ElastiCache . AWS CLI ElastiCache API

L'abilitazione di ElastiCache Multi-AZ sul OSS cluster Valkey o Redis (nel gruppo di replica API e CLI nel gruppo di replica) migliora la tolleranza agli errori. Questo vale in particolare nei casi in cui il cluster principale di lettura/scrittura del cluster diventa irraggiungibile o si guasta per qualche motivo. Multi-AZ è supportato solo sui OSS cluster Valkey e Redis con più di un nodo in ogni shard.

Abilitazione della funzione Multi-AZ

È possibile abilitare Multi-AZ quando si crea o si modifica un cluster (APIo CLI un gruppo di replica) utilizzando la console o il. ElastiCache AWS CLI ElastiCache API

È possibile abilitare Multi-AZ solo su cluster Valkey o Redis OSS (modalità cluster disabilitata) che dispongono di almeno una replica di lettura disponibile. I cluster senza repliche di lettura non forniscono alta disponibilità o tolleranza ai guasti. Per informazioni sulla creazione di un cluster con replica, consulta Creazione di un gruppo di replica Valkey o Redis OSS. Per informazioni sull'aggiunta di una replica di lettura a un cluster con replica, consulta Aggiungere una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata).

Abilitazione del Multi-AZ (console)

È possibile abilitare Multi-AZ utilizzando la ElastiCache console quando si crea un nuovo cluster Valkey o Redis o modificando un OSS cluster esistente con la replica.

Multi-AZ è abilitato per impostazione predefinita sui cluster Valkey o OSS Redis (modalità cluster abilitata).

Abilitazione di Multi-AZ durante la creazione di un cluster utilizzando la console ElastiCache

Per ulteriori informazioni su questo processo, consulta Creazione di un cluster Valkey (modalità cluster disabilitata) (console). Assicurati di disporre di una o più repliche e di abilitare la funzione Multi-AZ.

Abilitazione della funzione Multi-AZ in un cluster esistente (console)

Per ulteriori informazioni su questo processo, consulta Usando il ElastiCache AWS Management Console nella sezione relativa alla modifica di un cluster.

Abilitazione di Multi-AZ (AWS CLI)

Il seguente esempio di codice utilizza AWS CLI per abilitare Multi-AZ per il gruppo di replica. redis12

Per Linux, macOS o Unix:

aws elasticache modify-replication-group \
    --replication-group-id redis12 \
    --automatic-failover-enabled \
    --multi-az-enabled \
    --apply-immediately

Per Windows:

aws elasticache modify-replication-group ^
    --replication-group-id redis12 ^
    --automatic-failover-enabled ^
    --multi-az-enabled ^
    --apply-immediately

L'JSONoutput di questo comando dovrebbe essere simile al seguente.

{
    "ReplicationGroup": {
        "Status": "modifying", 
        "Description": "One shard, two nodes", 
        "NodeGroups": [
            {
                "Status": "modifying", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-002"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ReplicationGroupId": "redis12", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabling", 
        "MultiAZ": "enabled", 
        "SnapshotWindow": "07:00-08:00", 
        "SnapshottingClusterId": "redis12-002", 
        "MemberClusters": [
            "redis12-001", 
            "redis12-002"
        ], 
        "PendingModifiedValues": {}
    }
}

Per ulteriori informazioni, consulta questi argomenti nel Riferimento ai comandi AWS CLI :

Abilitazione di Multi-AZ (ElastiCache API)

Il seguente esempio di codice utilizza ElastiCache API per abilitare Multi-AZ per il gruppo di replica. redis12

https://elasticache.us-west-2.amazonaws.com/
    ?Action=ModifyReplicationGroup
    &ApplyImmediately=true
    &AutoFailover=true
    &MultiAZEnabled=true
    &ReplicationGroupId=redis12
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Per ulteriori informazioni, consulta questi argomenti nella Guida di riferimento: ElastiCache API

Risposte per scenari di errore relativi alla funzione Multi-AZ

Prima dell'introduzione di Multi-AZ, ElastiCache rilevava e sostituiva i nodi guasti di un cluster ricreando e rifornendo il nodo guasto. Abilitando la funzione Multi-AZ, un nodo primario non riuscito esegue il failover nella replica con il ritardo di replica minimo. La replica selezionata viene promossa automaticamente al nodo primario. Questa è un'operazione molto più rapida rispetto alla creazione e al provisioning di un nuovo nodo primario. Questo processo richiede in genere pochi secondi prima che sia possibile scrivere nuovamente nel cluster.

Quando Multi-AZ è abilitato, monitora ElastiCache continuamente lo stato del nodo primario. Se il nodo primario non riesce, viene eseguita una delle seguenti operazioni a seconda del tipo di errore.

Scenari di errore quando solo il nodo primario non riesce

Se il nodo primario non riesce, la replica di lettura con il tempo di replica minimo viene promossa al cluster primario. Viene quindi creata una replica di lettura sostitutiva e viene eseguito il provisioning nella stessa zona di disponibilità del nodo primario non riuscito.

Quando si verifica un errore solo nel nodo primario, ElastiCache Multi-AZ esegue le seguenti operazioni:

Dopo che la nuova replica è disponibile, tieni presente questi effetti:

Per informazioni sull'individuazione degli endpoint di un cluster, consulta i seguenti argomenti:

Scenari di errore quando il nodo primario e alcune repliche di lettura non riescono

Se il nodo primario e almeno una replica di lettura non riescono, la replica disponibile con il ritardo di replica minimo viene promossa al cluster primario. Nuove repliche di lettura vengono inoltre create e sottoposte a provisioning nelle stesse zone di disponibilità dei nodi non riusciti e della replica che è stata promossa al nodo primario.

Quando il nodo primario e alcune repliche di lettura falliscono, ElastiCache Multi-AZ esegue le seguenti operazioni:

Dopo che i nuovi nodi sono disponibili, occorre apportare le seguenti modifiche all'applicazione:

Scenari di fallimento quando l'intero cluster non riesce

In caso di errore generale, tutti i nodi vengono ricreati e sottoposti a provisioning nelle stesse zone di disponibilità dei nodi originali.

In questo scenario, tutti i dati nel cluster vengono persi a causa del guasto di ogni nodo nel cluster. Questa eventualità è rara.

In caso di guasto dell'intero cluster, ElastiCache Multi-AZ esegue le seguenti operazioni:

Poiché ciascuno dei nodi sostitutivi ha lo stesso endpoint del nodo che sta sostituendo, non occorre apportare modifiche all'endpoint nell'applicazione.

Per informazioni sull'individuazione degli endpoint di un gruppo di replica, consulta i seguenti argomenti:

Ti consigliamo di creare il nodo primario e le repliche di lettura in zone di disponibilità diverse per aumentare il livello di tolleranza ai guasti.

Test del failover automatico

Dopo aver abilitato il failover automatico, è possibile testarlo utilizzando la ElastiCache console AWS CLI, il e il. ElastiCache API

Durante il test, tieni presente quanto segue:

Test del failover automatico utilizzando AWS Management Console

Utilizza la procedura seguente per testare il failover automatico con la console.

Test del failover automatico utilizzando AWS CLI

È possibile testare il failover automatico su qualsiasi cluster dotato di Multi-AZ utilizzando l' AWS CLI operazione. test-failover

L'esempio seguente lo utilizza AWS CLI per testare il failover automatico sul gruppo di nodi redis00-0003 nel cluster Valkey o Redis OSS (modalità cluster abilitata). redis00

aws elasticache test-failover \
   --replication-group-id redis00 \
   --node-group-id redis00-0003

aws elasticache test-failover ^
   --replication-group-id redis00 ^
   --node-group-id redis00-0003

L'aspetto dell'output del comando precedente è simile al seguente.

{
    "ReplicationGroup": {
        "Status": "available", 
        "Description": "1 shard, 3 nodes (1 + 2 replicas)", 
        "NodeGroups": [
            {
                "Status": "available", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2c", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-002"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-003"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ClusterEnabled": false, 
        "ReplicationGroupId": "redis1x3", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabled", 
        "MultiAZ": "enabled",
        "SnapshotWindow": "11:30-12:30", 
        "SnapshottingClusterId": "redis1x3-002", 
        "MemberClusters": [
            "redis1x3-001", 
            "redis1x3-002", 
            "redis1x3-003"
        ], 
        "CacheNodeType": "cache.m3.medium", 
        "DataTiering": "disabled",
        "PendingModifiedValues": {}
    }
}

Per tenere traccia dell'avanzamento del failover, utilizza l'operazione. AWS CLI describe-events

Per ulteriori informazioni, consulta gli argomenti seguenti:

Test del failover automatico utilizzando ElastiCache API

È possibile testare il failover automatico su qualsiasi cluster abilitato con Multi-AZ utilizzando l' ElastiCache APIoperazione. TestFailover

L'esempio seguente esegue il test del failover automatico sul gruppo di nodi redis00-0003 nel gruppo di replica (sulla console, cluster) redis00.

https://elasticache.us-west-2.amazonaws.com/
    ?Action=TestFailover
    &NodeGroupId=redis00-0003
    &ReplicationGroupId=redis00
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Per tenere traccia dell'avanzamento del failover, utilizzate l' ElastiCache DescribeEventsAPIoperazione.

Per ulteriori informazioni, consulta gli argomenti seguenti:

Limitazioni su Multi-AZ

Tieni presente le seguenti limitazioni per Multi-AZ: