Cette page explique comment l'architecture de Memorystore pour Redis Cluster prend en charge et assure la haute disponibilité. Elle décrit également les configurations recommandées qui contribuent à améliorer les performances et la stabilité des instances.
Pour en savoir plus sur les considérations spécifiques à la région, consultez la page Zones géographiques et régions.
Haute disponibilité
Memorystore pour Redis Cluster repose sur une architecture à disponibilité élevée dans laquelle vos clients accèdent directement aux VM Memorystore pour Redis Cluster gérées. Pour ce faire, ils se connectent à des adresses réseau de fragment individuelles , comme décrit dans Se connecter à une instance Memorystore pour Redis Cluster.
La connexion directe aux fragments présente les avantages suivants :
La connexion directe évite tout point de défaillance unique, car chaque fragment est conçu pour échouer indépendamment. Par exemple, si le trafic de plusieurs clients surcharge un emplacement (fragment d'espace de clés), la défaillance du fragment limite l'impact au fragment responsable de la diffusion de l'emplacement.
La connexion directe évite les sauts intermédiaires, ce qui minimise le délai aller-retour (latence du client) entre votre client et la VM Redis.
Configurations recommandées
Nous vous recommandons de créer des instances multizones à disponibilité élevée plutôt que des instances à zone unique, car elles offrent une meilleure fiabilité. Toutefois, si vous choisissez de provisionner une instance sans instances dupliquées, nous vous recommandons de choisir une instance à zone unique. Pour en savoir plus, consultez Quand utiliser un cluster à zone unique.
Pour activer la haute disponibilité de votre instance, vous devez provisionner au moins un nœud d'instance dupliquée pour chaque fragment. Vous pouvez le faire lors de la création de l'instance ou vous pouvez mettre à l'échelle le nombre d'instances dupliquées pour qu'il soit d'au moins une instance dupliquée par fragment. Les instances dupliquées assurent le basculement automatique lors de la maintenance planifiée et en cas de défaillance inattendue du fragment.
Vous devez configurer votre client conformément aux consignes de Bonnes pratiques pour les clients Redis. L'utilisation des bonnes pratiques recommandées permet à votre client OSS Redis de gérer automatiquement et correctement le rôle (basculements automatiques) et les modifications d'attribution d'emplacement (remplacement de nœud, effectuer un scaling horizontal/à la baisse du consommateur) pour votre cluster sans aucun temps d'arrêt.
Instances dupliquées
Une instance Memorystore pour Redis Cluster à disponibilité élevée est une ressource régionale. Cela signifie que les VM principales et dupliquées des fragments sont réparties sur plusieurs zones pour se prémunir contre une panne zonale. Memorystore pour Redis Cluster est compatible avec les instances comportant entre 0 et 5 instances dupliquées par nœud.
Vous pouvez utiliser des instances dupliquées pour augmenter le débit en lecture en mettant à l'échelle les lectures.
Pour ce faire, vous devez utiliser la commande READONLY afin d'établir une connexion permettant à votre client de lire à partir d'instances dupliquées. Pour en savoir plus sur la lecture
à partir d'instances dupliquées, consultez Mettre à l'échelle avec Redis Cluster.
Forme du cluster avec 0 instance dupliquée par nœud
Forme du cluster avec 1 instance dupliquée par nœud
Forme du cluster avec plusieurs instances dupliquées par nœud
Basculement automatique
Des basculements automatiques au sein d'un fragment peuvent se produire en raison d'une maintenance ou d'une défaillance inattendue du nœud principal. Lors d'un basculement, une instance dupliquée est promue en tant qu'instance principale. Vous pouvez configurer explicitement des instances dupliquées. Le service peut également provisionner temporairement des instances dupliquées supplémentaires lors de la maintenance interne pour éviter tout temps d'arrêt.
Les basculements automatiques empêchent la perte de données lors des mises à jour de maintenance. Pour en savoir plus sur le comportement de basculement automatique lors de la maintenance, consultez Comportement de basculement automatique lors de la maintenance.
Durée du basculement et de la réparation des nœuds
Les basculements automatiques peuvent prendre plusieurs dizaines de secondes pour les événements imprévus, tels qu'un plantage du processus du nœud principal ou une défaillance matérielle. Pendant ce temps, le système détecte la défaillance et choisit une instance dupliquée comme nouvelle instance principale.
La réparation des nœuds peut prendre plusieurs minutes pour que le service remplace le nœud défaillant. Cela s'applique à tous les nœuds principaux et d'instance dupliquée. Pour les instances qui ne sont pas disponibilité élevée (aucune instance dupliquée provisionnée), la réparation d'un nœud principal défaillant prend également plusieurs minutes.
Comportement du client lors d'un basculement imprévu
Les connexions client sont susceptibles d'être réinitialisées en fonction de la nature de la défaillance. Après la récupération automatique, les connexions doivent être retentées avec un intervalle exponentiel entre les tentatives pour éviter de surcharger les nœuds principaux et d'instance dupliquée.
Les clients qui utilisent des instances dupliquées pour le débit en lecture doivent se préparer à une dégradation temporaire de la capacité jusqu'à ce que le nœud défaillant soit automatiquement remplacé.
Écritures perdues
Lors d'un basculement résultant d'une défaillance inattendue, les écritures confirmées peuvent être perdues en raison de la nature asynchrone du protocole de réplication de Redis.
Les applications clientes peuvent tirer parti de la commande Redis WAIT pour améliorer la sécurité des données réelles. Il s'agit d'une approche au mieux qui présente des compromis, comme expliqué dans la documentation de la commande Redis WAIT.
Impact d'une panne de zone unique sur l'espace de clés
Cette section décrit l'impact d'une panne de zone unique sur une instance Memorystore pour Redis Cluster.
Instances multizones
Instances à haute disponibilité : en cas de panne dans une zone, l'ensemble de l'espace de clés est disponible en lecture et en écriture, mais comme certaines instances dupliquées avec accès en lecture ne sont pas disponibles, la capacité de lecture est réduite. Nous vous recommandons vivement de surprovisionner la capacité du cluster afin que l'instance dispose d'une capacité de lecture suffisante, dans le cas rare d'une panne de zone unique. Une fois la panne terminée, les instances dupliquées de la zone affectée sont restaurées et la capacité de lecture du cluster revient à sa valeur configurée. Pour en savoir plus, consultez Modèles d'applications évolutives et fiables.
Instances sans haute disponibilité (aucune instance dupliquée) : en cas de panne dans une zone, la partie de l'espace de clés provisionnée dans la zone affectée subit un vidage des données et n'est pas disponible en écriture ni en lecture pendant la durée de la panne. Une fois la panne terminée, les instances principales de la zone affectée sont restaurées et la capacité du cluster revient à sa valeur configurée.
Instances à zone unique
- Instances à haute disponibilité et sans haute disponibilité : si la zone dans laquelle l'instance est provisionnée est en panne, le cluster n'est pas disponible et les données sont vidées. Si une autre zone est en panne, le cluster continue de traiter les requêtes de lecture et d'écriture. Une fois la panne terminée, la capacité configurée du cluster est restaurée.
Bonnes pratiques
Cette section décrit les bonnes pratiques pour la haute disponibilité et les instances dupliquées.
Ajouter une instance dupliquée
L'ajout d'une instance dupliquée nécessite un instantané RDB. Les instantanés RDB utilisent un fork de processus et un mécanisme de copie sur écriture pour prendre un instantané des données de nœud. En fonction du modèle d'écriture dans les nœuds, la mémoire utilisée des nœuds augmente à mesure que les pages touchées par les écritures sont copiées. L'espace mémoire utilisé peut atteindre le double de la taille des données dans le nœud.
Pour vous assurer que les nœuds disposent de suffisamment de mémoire pour effectuer l'instantané, conservez ou
définissez maxmemory à 80% de
la capacité du nœud afin que 20% soient réservés aux frais généraux. Cette surcharge de mémoire, en plus de la surveillance des instantanés, vous aide à gérer votre charge de travail pour que les instantanés soient réussis. De plus, lorsque vous ajoutez des instances dupliquées, réduisez autant que possible le trafic en écriture. Pour en savoir plus, consultez Surveiller un cluster avec une charge d'écriture élevée.