Comment suivre les bonnes pratiques en matière de basculement et de restauration pour les clusters ElastiCache pour Valkey ou ElastiCache for Redis OSS conçus par mes soins ?

Brève description

Les événements de basculement et de restauration sont des éléments essentiels d'Amazon ElastiCache qui permettent à ElastiCache d'être résilient. Toutefois, lorsque des événements de basculement et de restauration se produisent, ils peuvent affecter les performances et la disponibilité de votre application.

Il est recommandé de réduire les problèmes liés aux événements de basculement et de restauration qui affectent votre cluster en effectuant les actions suivantes :

• Examiner vos événements.
• Chercher à comprendre la cause des événements.
• Se préparer en vue des événements.
• Configurer les notifications d'événement.

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.

Examiner vos événements

ElastiCache journalise divers événements liés à votre cluster, à vos groupes de sécurité et à vos groupes de paramètres.

Les événements incluent, sans toutefois s'y limiter, la création et la suppression de ressources, les opérations de mise à l’échelle, les basculements, les redémarrages de nœuds et la création d'instantanés. Pour mieux comprendre et analyser les événements de votre cluster ElastiCache, examinez vos événements ElastiCache.

Exemples d'événements de basculement dans les journaux d'événements ElastiCache :

December 5, 2024, 10:12:20 Finished recovery for cache nodes 0001
December 5, 2024, 10:10:48 Recovering cache nodes 0001
December 5, 2024, 10:05:45 Recovering cache nodes 0001
December 5, 2024, 10:04:24 Failover from master node <node name> to replica node <node name> completed

Exemples d'événements de restauration dans les journaux d'événements ElastiCache :

2022-10-05 19:20 Finished recovery for cache nodes 0001
2022-10-05 19:18 Recovering cache nodes 0001
2022-10-05 19:14 Recovering cache nodes 0001

Remarque : Amazon ElastiCache for Memcached ne prend pas en charge le basculement, mais des messages similaires peuvent apparaître dans les journaux d'événements pour un événement de restauration.

Comprendre la cause de l'événement

Lors d'un événement de basculement, ElastiCache remplace un nœud primaire non disponible par un nœud de réplication. ElastiCache remplace également les nœuds primaires pour les actions demandées par les utilisateurs ou les événements planifiés. Pour plus d'informations, consultez la section FAQ sur Amazon ElastiCache.

Exemples d'événements :

• Pour tester la fonctionnalité de basculement
• Pour effectuer une maintenance planifiée
• Pour résoudre des problèmes liés à la zone de disponibilité

Si un nœud de réplication rencontre des problèmes de disponibilité, ElastiCache remplace le réplica par un nouveau nœud de réplication.

Remarque : Ce remplacement ne déclenche pas d'événement de basculement.

Lorsqu'ElastiCache tente de restaurer le cluster dans ces situations, ElastiCache journalise ces événements de restauration.

Remarque : Pour déterminer si un nœud est primaire ou non, utilisez la métrique Amazon CloudWatch IsMaster. Pour plus d'informations, consultez la section Métriques pour Valkey et Redis OSS.

Évènements de basculement et de restauration non planifiés

Dans ElastiCache, un basculement non planifié se produit lorsque le nœud primaire tombe en panne de manière inattendue et invite le service à promouvoir un nœud de réplication au rôle principal. De même, si un nœud de réplication doit être remplacé, ElastiCache provisionne automatiquement un nouveau nœud de réplication en cas de défaillance d'un réplica. Les deux processus minimisent la durée d’indisponiblité et garantissent une haute disponibilité. Les causes courantes de basculement et de remplacement non planifiés sont les suivantes :

• Pour les problèmes sous-jacents liés à l'hôte ElastiCache, tels qu'une panne matérielle, des problèmes réseau ou une défaillance de la zone de disponibilité, ElastiCache effectue une restauration. Pour l'infrastructure AWS, dans les rares cas d’une défaillance, les processus automatisés permettent une haute disponibilité du cluster.
• Pour les charges de travail ímportantes, Amazon ElastiCache for Redis OSS et Amazon ElastiCache pour Valkey utilisent un seul thread. De ce fait, les commandes de longue durée peuvent bloquer d'autres opérations. Une charge de travail excessive dans le cluster peut entraîner une utilisation excessive et un épuisement des ressources, et engendrer le basculement et la restauration. Par exemple, des commandes complexes, des scripts Lua inefficaces et des opérations massives basées sur des clés peuvent surcharger le cluster et dégrader les performances.

Remarque : Lorsqu'un réplica principal échoue en raison d'une interruption temporaire de la zone de disponibilité, ElastiCache lance le nouveau réplica une fois la zone de disponibilité rétablie.

Événements de basculement et de restauration planifiés

Des événements de basculement et de restauration planifiés peuvent survenir pour des opérations de maintenance planifiée ou initiées par l'utilisateur.

Dans le cadre de la maintenance planifiée, AWS met régulièrement à niveau la flotte ElastiCache afin de renforcer la sécurité, la fiabilité et les performances opérationnelles des clusters ElastiCache. Les événements de maintenance planifiés, tels que les remplacements de nœuds et les mises à jour de service dans le cadre d'une maintenance gérée continue, peuvent déclencher des événements de basculement et de restauration. Pour en savoir plus, consultez la Page d’aide sur la maintenance gérée et les mises à jour de service d’Amazon ElastiCache.

Pour les opérations initiées par l'utilisateur, l’utilisateur lance TestFailover via l’API TestFailover, la commande test-failover de l’interface de ligne de commande AWS ou la console ElastiCache. Pour promouvoir un réplica en lecture vers un cluster primaire désactivé en mode cluster, lancez une opération de promotion. Pour plus d'informations, consultez la section Promotion d'un réplica en lecture vers un cluster primaire pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé).

Remarque : Dans certaines conditions, par exemple lors d'événements opérationnels de grande envergure, AWS peut bloquer cette API. Si AWS bloque l'API, le message suivant s'affiche dans vos journaux d'événements : « Test Failover API called for node group 0001. » (API de test du basculement appelée pour le groupe de nœuds 0001.)

Se préparer en vue des événements

Pour les événements de basculement planifiés, tels que la maintenance ou les mises à jour de service, ElastiCache remplace les nœuds lorsque le cluster traite les demandes d'écriture entrantes. Pour atténuer les problèmes, suivez les bonnes pratiques pour les événements de basculement planifiés. Pour en savoir plus, consultez la Page d’aide sur la maintenance gérée et les mises à jour de service d’Amazon ElastiCache.

En cas d'événements de basculement non planifiés, le basculement ElastiCache se produit automatiquement lorsque vous activez le mode Multi-AZ pour votre cluster.

Remarque : Si un basculement se produit sur un réplica lorsque vous écrivez sur un nœud qui utilise le point de terminaison du réplica, il est possible que le nœud ne soit pas disponible. Une fois que vous avez remplacé le réplica, le nœud devient disponible pour les demandes de lecture.

Pour réduire les problèmes lors d'événements planifiés et non planifiés, suivez les bonnes pratiques en matière de connectivité et de configuration.

Configurer les notifications d'événements

Pour réagir rapidement aux événements et à leurs causes, configurez ElastiCache pour envoyer des notifications en cas de basculement ou de restauration dans un cluster. Pour plus d'informations, consultez la section Gestion des notifications ElastiCache Amazon Simple Notification Service (Amazon SNS).

Lorsque vous configurez ElastiCache afin d’utiliser Amazon SNS pour les notifications, vous recevez des notifications similaires aux exemples suivants :

Exemples d'événements de restauration :

Recovery reason : Recovery completed for node as ElastiCache monitoring detected a
 network reachability failure on the node, ElastiCache:CacheNodeReplaceComplete : <node>

Recovery reason : Recovery completed for node as ElastiCache monitoring detected
 software issues on the node, ElastiCache:CacheNodeReplaceComplete : <node>

Recovery reason : Recovery completed for node as ElastiCache monitoring detected
 unresponsive engine on the node, ElastiCache:CacheNodeReplaceComplete : <node>

Recovery reason : Recovery completed for node as ElastiCache monitoring detected
busy and unresponsive engine on the node, ElastiCache:CacheNodeReplaceComplete : <node>

Exemples d'événements de basculement :

Failover reason : Failover completed for node as ElastiCache monitoring detected a
network reachability failure on the node, ElastiCache:FailoverComplete : <node>

Failover reason : Failover completed for node as ElastiCache monitoring
detected software issues on the node, ElastiCache:FailoverComplete : <node>

Failover reason : Failover completed for node as ElastiCache monitoring
detected unresponsive engine on the node, ElastiCache:FailoverComplete : <node>

Failover reason : Failover completed for node as ElastiCache monitoring detected busy
 and unresponsive engine on the node, ElastiCache:FailoverComplete : <node>

Remarque : ElastiCache for Memcached ne prend pas en charge les messages améliorés pour les événements de restauration.

Informations connexes

Surveillance des bonnes pratiques avec Amazon ElastiCache for Redis à l’aide d’Amazon CloudWatch

Comment résoudre les problèmes de latence élevée dans ElastiCache for Redis ?

Comment puis-je résoudre les problèmes d’utilisation élevée du processeur dans le cluster ElastiCache for Redis conçu par mes soins ?