Minimiser les temps d'arrêt ElastiCache en utilisant le multi-AZ avec Valkey et Redis OSS

Dans un certain nombre de cas ElastiCache , Valkey et Redis OSS peuvent avoir besoin de remplacer un nœud principal ; il s'agit notamment de certains types de maintenance planifiée et de l'éventualité peu probable d'une défaillance d'un nœud principal ou d'une zone de disponibilité.

Ce remplacement entraîne un certain temps d'arrêt pour le cluster, mais si Multi-AZ est activé, le temps d'arrêt est réduit. Le rôle du nœud primaire bascule automatiquement sur l'un des réplicas en lecture. Il n'est pas nécessaire de créer et de provisionner un nouveau nœud principal, car il ElastiCache gérera cela de manière transparente. Ce basculement et la promotion d'un réplica vous permettent de recommencer à écrire dans le nouveau nœud principal dès que la promotion est terminée.

ElastiCache propage également le nom du Domain Name Service (DNS) de la réplique promue. De cette façon, si votre application écrit dans le point de terminaison principal, aucun changement du point de terminaison ne sera nécessaire dans le cadre de votre application. Si vous lisez à partir de points de terminaison individuels, veillez à modifier le point de terminaison de lecture du réplica promu en principal en point de terminaison du nouveau réplica.

Dans le cas de remplacements de nœuds planifiés, initiés en raison de mises à jour de maintenance ou de mises à jour en libre service, soyez conscient des points suivants :

Vous pouvez activer le mode Multi-AZ à l'aide de la console de ElastiCache gestion AWS CLI, du ou du ElastiCache API.

L'activation de ElastiCache Multi-AZ sur votre OSS cluster Valkey ou Redis (dans le groupe de réplication API etCLI) améliore votre tolérance aux pannes. C'est surtout le cas lorsque le cluster principal en lecture/écriture de votre cluster devient inaccessible ou fait l'objet d'une défaillance pour quelque raison que ce soit. Le multi-AZ n'est pris en charge que sur les OSS clusters Valkey et Redis comportant plus d'un nœud par partition.

Activation du multi-AZ

Vous pouvez activer le mode multi-AZ lorsque vous créez ou modifiez un cluster (APIou CLI un groupe de réplication) à l'aide de la ElastiCache console ou du ElastiCacheAPI. AWS CLI

Vous pouvez activer le mode multi-AZ uniquement sur les clusters Valkey ou Redis OSS (mode cluster désactivé) qui ont au moins une réplique en lecture disponible. Les clusters sans réplica en lecture n'offrent pas une haute disponibilité ni la tolérance aux pannes. Pour plus d'informations sur la création d'un cluster avec réplication, consultez Création d'un groupe de réplication Valkey ou Redis OSS. Pour plus d'informations sur l'ajout d'un réplica à un cluster avec réplication, consultez Ajouter une réplique de lecture pour Valkey ou Redis OSS (mode cluster désactivé).

Activation du multi-AZ (console)

Vous pouvez activer le Multi-AZ à l'aide de la ElastiCache console lorsque vous créez un nouveau cluster Valkey ou Redis ou en modifiant un OSS cluster existant par réplication.

Le multi-AZ est activé par défaut sur les clusters Valkey ou Redis OSS (mode cluster activé).

Activation du mode multi-AZ lors de la création d'un cluster à l'aide de la console ElastiCache

Pour plus d'informations sur ce processus, consultez Création d'un cluster Valkey (mode cluster désactivé) (console). Assurez-vous d'avoir un ou plusieurs réplicas et activez Multi-AZ.

Activation du multi-AZ sur un cluster existant (console)

Pour plus d'informations sur ce processus, consultez Modification d'un cluster À l'aide du ElastiCache AWS Management Console.

Activation de Multi-AZ (AWS CLI)

L'exemple de code suivant utilise le AWS CLI pour activer le mode multi-AZ pour le groupe redis12 de réplication.

Pour Linux, macOS ou Unix :

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

Pour Windows :

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

Le JSON résultat de cette commande devrait ressembler à ce qui suit.

{
    "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": {}
    }
}

Pour plus d'informations, consultez ces rubriques dans la Référence des commandes de l'AWS CLI  :

Activation de Multi-AZ (ElastiCache API)

L'exemple de code suivant utilise le ElastiCache API pour activer le mode multi-AZ pour le groupe redis12 de réplication.

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>

Pour plus d'informations, consultez les rubriques suivantes dans la ElastiCache APIréférence :

Scénarios de défaillance avec réponses multi-AZ

Avant l'introduction du Multi-AZ, les nœuds défaillants d'un cluster étaient ElastiCache détectés et remplacés en recréant et en reprovisionnant le nœud défaillant. Si vous activez Multi-AZ, un cluster principal défaillant bascule vers le réplica ayant le moindre décalage de réplication. Le réplica sélectionné est automatiquement promu au rang de principal, ce qui est beaucoup plus rapide que de créer et de remettre en service un nouveau nœud principal. Ce processus dure généralement quelques secondes pendant lesquelles vous ne pouvez pas écrire sur le cluster.

Lorsque le mode Multi-AZ est activé, il surveille ElastiCache en permanence l'état du nœud principal. En cas de défaillance du nœud principal, l'une des actions suivantes est effectuée selon le type de la défaillance.

Scénarios d'échec lorsque seul le nœud primaire échoue

Si seul le nœud principal échoue, le réplica en lecture ayant le moindre décalage de réplication est promu au rang de principal. Un réplica en lecture de remplacement est ensuite créé et provisionné dans la même zone de disponibilité que le principal défaillant.

Lorsque seul le nœud principal tombe en panne, ElastiCache Multi-AZ effectue les opérations suivantes :

Lorsque le nouveau réplica est disponible, vous devez être conscient des effets suivants :

Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes :

Scénarios de défaillance en cas de défaillance du nœud primaire et de certains réplicas en lecture

Lorsque le nœud principal et au moins un réplica en lecture sont défaillants, le réplica disponible avec le moindre décalage de réplication est promu cluster principal. De nouveaux réplicas en lecture sont également créés et mis en service dans les mêmes zones de disponibilité que les nœuds défaillants et le réplica promu cluster principal.

Lorsque le nœud principal et certaines répliques de lecture échouent, ElastiCache Multi-AZ effectue les opérations suivantes :

Vous devez apporter les modifications suivantes à votre application, une fois que les nouveaux nœuds sont disponibles :

Scénarios d'échec lorsque l'ensemble du cluster tombe en panne

En cas de défaillance générale, tous les nœuds sont recréés et mis en service dans les mêmes zones de disponibilité que les nœuds initiaux.

Dans ce scénario, toutes les données du cluster sont perdues en raison de la défaillance au niveau de chaque nœud du cluster. Cela se produit rarement.

Lorsque l'ensemble du cluster échoue, ElastiCache Multi-AZ effectue les opérations suivantes :

Comme chacun des nœuds de remplacement a le même point de terminaison que le nœud qu'il remplace, il n'est pas nécessaire de modifier le point de terminaison de votre application.

Pour plus d'informations sur la recherche des points de terminaison d'un groupe de réplication, consultez les rubriques suivantes :

Nous vous recommandons de créer le nœud principal et les réplicas dans différentes zones de disponibilité pour augmenter votre niveau de tolérance aux pannes.

Test du basculement automatique

Après avoir activé le basculement automatique, vous pouvez le tester à l'aide de la ElastiCache console, du AWS CLI, et du ElastiCache API.

Lors du test, tenez compte des points suivants :

Test du basculement automatique à l'aide du AWS Management Console

Utilisez la procédure suivante pour tester le basculement automatique avec la console.

Test du basculement automatique à l'aide du AWS CLI

Vous pouvez tester le basculement automatique sur n'importe quel cluster compatible Multi-AZ à l' AWS CLI aide de cette opération. test-failover

L'exemple suivant utilise le AWS CLI pour tester le basculement automatique sur le groupe redis00-0003 de nœuds du cluster Valkey ou Redis OSS (mode cluster activé). 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

Le résultat de la commande précédente doit ressembler à ce qui suit.

{
    "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": {}
    }
}

Pour suivre la progression de votre basculement, utilisez l' AWS CLI describe-eventsopération.

Pour plus d'informations, veuillez consulter les ressources suivantes :

Test du basculement automatique à l'aide du ElastiCache API

Vous pouvez tester le basculement automatique sur n'importe quel cluster activé avec Multi-AZ à l' ElastiCache APIaide de cette opération. TestFailover

L'exemple suivant teste le basculement automatique sur le groupe de nœuds redis00-0003 dans le groupe de réplication (sur la 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>

Pour suivre la progression de votre basculement, utilisez l' ElastiCache DescribeEventsAPIopération.

Pour plus d’informations, consultez les ressources suivantes :

Limitations relatives à la technologie Multi-AZ

Tenez compte des limites suivantes pour le Multi-AZ :