Cette page explique comment l'architecture de Memorystore pour Valkey fournit et prend en charge la haute disponibilité. Cette page explique également comment améliorer les performances et la stabilité des instances grâce aux configurations de haute disponibilité que nous recommandons.
Haute disponibilité
Memorystore pour Valkey repose sur une architecture à disponibilité élevée dans laquelle vos clients accèdent directement aux nœuds Memorystore pour Valkey gérés. Pour ce faire, vos clients se connectent à des points de terminaison individuels, comme décrit dans Se connecter à une instance Memorystore pour Valkey.
La connexion directe aux segments offre les avantages suivants :
La connexion directe évite les sauts intermédiaires, ce qui minimise le délai aller-retour (latence du client) entre votre client et le nœud Memorystore pour Valkey.
En mode cluster activé, la connexion directe évite tout point de défaillance unique, car chaque segment 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 de la partition limite l'impact à la partition responsable de la diffusion de l'emplacement.
Configurations recommandées
Nous vous recommandons de créer des instances multizones à disponibilité élevée plutôt que des instances monozones, car elles offrent une meilleure fiabilité. Toutefois, si vous choisissez de provisionner une instance sans instances répliquées, nous vous recommandons de choisir une instance monozone. Pour en savoir plus, consultez Quand utiliser une instance monozone.
Pour activer la haute disponibilité pour votre instance, vous devez provisionner au moins une instance répliquée pour chaque segment. Vous pouvez le faire lors de la création de l'instance ou ajuster le nombre d'instances répliquées à au moins une instance répliquée par segment. Les instances répliquées fournissent un basculement automatique pendant la maintenance planifiée et en cas de défaillance inattendue d'un segment.
Nous vous recommandons de configurer votre client conformément aux instructions de la section Bonnes pratiques concernant les clients. L'utilisation des bonnes pratiques recommandées permet à votre client de gérer automatiquement les éléments suivants pour votre instance, sans temps d'arrêt :
- Le rôle (basculements automatiques)
- Le point de terminaison (remplacement de nœud)
- Modifications de l'attribution d'emplacements liées au mode Cluster activé (effectuer un scaling horizontal et vertical des consommateurs)
Instances répliquées
Une instance Memorystore pour Valkey à disponibilité élevée est une ressource régionale. Memorystore pour Valkey distribue les VM principales et répliquées des segments sur plusieurs zones pour se protéger contre une panne zonale. Memorystore pour Valkey accepte les instances comportant de 0 à 5 instances répliquées par segment.
Vous pouvez utiliser des instances répliquées pour augmenter le débit de lecture au détriment de l'obsolescence potentielle des données.
- Mode cluster activé : utilisez la commande
READONLYpour établir une connexion permettant à votre client de lire à partir d'instances répliquées. - Mode cluster désactivé : connectez-vous au point de terminaison du lecteur pour vous connecter à l'un des instances répliquées disponibles.
Exemples d'instances avec le mode cluster activé
Les schémas suivants illustrent des exemples d'instances en mode cluster activé :
Exemple d'instance avec trois segments et zéro instance répliquée par segment
Exemple d'instance avec trois segments et une instance répliquée par segment
Exemple d'instance avec trois segments et plusieurs instances répliquées par segment
Exemples d'instances avec le mode cluster désactivé
Le diagramme suivant illustre un exemple d'instances en mode cluster désactivé :
Exemple d'instance avec plusieurs instances répliquées
Impact d'un basculement sur votre application
Lorsque Memorystore pour Valkey promeut une instance répliquée en instance principale, il supprime les connexions existantes au point de terminaison principal de l'instance. Lors des réparations automatisées et des événements de maintenance, l'instance est indisponible pendant 30 secondes en moyenne.
Une fois l'instance disponible, Memorystore pour Valkey utilise la même chaîne de connexion ou adresse IP pour rediriger automatiquement votre application vers la nouvelle instance principale. Vous n'avez pas besoin de mettre à jour votre application.
Lors d'un basculement, s'il existe des connexions au point de terminaison de lecture, Memorystore pour Valkey supprime les connexions à l'instance répliquée qu'il promeut en tant qu'instance principale. Toutefois, Memorystore pour Valkey ne supprime pas les connexions aux autres instances répliquées. Une fois le basculement terminé et la nouvelle instance répliquée disponible, Memorystore pour Valkey redirige les connexions vers la nouvelle instance répliquée.
Basculement automatique
Les basculements automatiques au sein d'un segment peuvent se produire en raison d'une maintenance ou d'une défaillance inattendue du nœud principal. Lors d'un basculement, une instance répliquée est promue en tant qu'instance principale. Vous pouvez configurer les instances répliquées de manière explicite. Le service peut également provisionner temporairement des instances répliquées supplémentaires lors de la maintenance interne pour éviter tout temps d'arrêt.
Les basculements automatiques évitent la perte de données lors des mises à jour de maintenance. Pour en savoir plus sur le comportement du basculement automatique pendant la maintenance, consultez Comportement du basculement automatique pendant 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 non planifiés, 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 élit une instance répliquée comme nouvelle instance principale.
La réparation d'un nœud peut prendre quelques minutes, le temps que le service remplace le nœud défaillant. C'est le cas pour tous les nœuds principaux et répliqués. Pour les instances qui ne sont pas disponibilité élevée (aucune instance répliquée provisionnée), la réparation d'un nœud principal défaillant prend également quelques minutes.
Comportement du client lors d'un basculement non planifié
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, vous pouvez réessayer vos connexions avec un intervalle exponentiel entre les tentatives pour éviter de surcharger les nœuds principaux et répliqués.
Les clients qui utilisent des instances dupliquées pour le débit de lecture peuvent subir 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 Valkey.
Les applications clientes peuvent exploiter la commande Valkey WAIT pour améliorer la sécurité des données réelles.
Impact d'une panne de zone unique sur l'espace de clés
Cette section décrit l'impact d'une panne d'une seule zone sur une instance Memorystore pour Valkey.
Instances multizones
Instances à haute disponibilité : si une zone subit une panne, l'espace de clés entier est disponible pour les lectures et les écritures, 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 d'une seule zone. Une fois l'indisponibilité terminée, les instances répliquées de la zone concerné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 non-HA (sans instances répliquées) : si une zone subit une panne, la partie de l'espace de clés provisionnée dans la zone concernée subit un vidage des données et n'est pas disponible pour les écritures ou les lectures pendant la durée de la panne. Une fois la panne terminée, les instances principales de la zone concernée sont restaurées et la capacité du cluster revient à sa valeur configurée.
Instances à zone unique
- Instances avec et sans haute disponibilité : si la zone dans laquelle l'instance est provisionnée subit une panne, le cluster n'est pas disponible et les données sont vidées. Si une autre zone subit une panne, le cluster continue de diffuser les requêtes de lecture et d'écriture.
Bonnes pratiques
Cette section décrit les bonnes pratiques concernant la haute disponibilité et les instances répliquées.
Ajouter une instance répliquée
L'ajout d'une instance répliqué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 du nœud. Selon le modèle d'écriture sur les nœuds, la mémoire utilisée des nœuds augmente à mesure que les pages concernées par les écritures sont copiées. L'espace mémoire utilisé peut être jusqu'à deux fois supérieur à la taille des données du nœud.
Pour vous assurer que les nœuds disposent de suffisamment de mémoire pour effectuer l'instantané, conservez ou définissez maxmemory sur 80% de la capacité du nœud, de sorte 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 réussir vos instantanés. De plus, lorsque vous ajoutez des instances répliquées, réduisez autant que possible le trafic d'écriture. Pour en savoir plus, consultez Surveiller l'utilisation de la mémoire pour une instance.