Minimiser les temps d'arrêt ElastiCache Multi-AZ en utilisant 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 s'il Multi-AZ est activé, le temps d'arrêt est minimisé. 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 DNS (Domain Name Service) 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 Multi-AZ l'activer à l'aide de la console de ElastiCache gestion AWS CLI, de ou de l' ElastiCache API.

L'activation ElastiCache Multi-AZ sur votre cluster Valkey ou Redis OSS (dans l'API et la CLI, groupe de réplication) améliore votre tolérance aux pannes. Cela est particulièrement vrai dans les cas où le cluster read/write principal de votre cluster devient inaccessible ou tombe en panne pour une raison quelconque. Multi-AZ n'est pris en charge que sur les clusters Valkey et Redis OSS comportant plus d'un nœud par partition.

Activant Multi-AZ

Vous pouvez l'activer Multi-AZ lorsque vous créez ou modifiez un cluster (API ou CLI, groupe de réplication) à l'aide de la ElastiCache console ou de l' ElastiCacheAPI. AWS CLI

Vous Multi-AZ ne pouvez l'activer que sur des clusters Valkey ou Redis OSS (mode cluster désactivé) disposant d'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 Multi-AZ (console)

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

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

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

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

Activation Multi-AZ sur un cluster existant (console)

Pour plus d'informations sur ce processus, consultez Modification d'un cluster En utilisant le ElastiCache AWS Management Console.

Activation Multi-AZ (AWS CLI)

L'exemple de code suivant utilise le AWS CLI Multi-AZ pour activer le groupe de réplicationredis12.

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 résultat JSON de cette commande devrait ressembler à cet exemple.

{
    "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 Multi-AZ (ElastiCache API)

L'exemple de code suivant utilise l' ElastiCache API Multi-AZ pour activer le groupe de réplicationredis12.

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 ces rubriques dans la référence de l'API ElastiCache  :

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

Avant l'introduction Multi-AZ, la ElastiCache détection et le remplacement des nœuds défaillants d'un cluster en recréant et en reprovisionnant le nœud défaillant. Si vous l'activez Multi-AZ, un nœud principal défaillant bascule vers la réplique avec le moins de retard 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 cette option Multi-AZ est activée, 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, procédez ElastiCache Multi-AZ comme suit :

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 ElastiCache Multi-AZ échoue, procédez comme suit :

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 AWS CLI, du et de l' 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 Multi-AZ activé à l'aide de cette AWS CLI opérationtest-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 de l'API ElastiCache

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

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'opération ElastiCache DescribeEvents API.

Pour plus d’informations, consultez les ressources suivantes :

Limitations relatives à Multi-AZ

Tenez compte des limites suivantes pour Multi-AZ :