Cette page explique comment l'architecture de cluster de Memorystore pour Firebase prend en charge et fournit la haute disponibilité (HA). Cette page explique également les configurations recommandées qui contribuent à améliorer les performances et la stabilité des instances.
Haute disponibilité
Memorystore for Valkey repose sur une architecture à disponibilité élevée dans laquelle vos clients accèdent directement aux VM gérées Memorystore pour Valkey. Pour ce faire, vos clients se connectent à des adresses réseau de shard individuelles, comme décrit dans la section Se connecter à une instance Memorystore pour Valkey.
La connexion directe aux shards présente les avantages suivants :
La connexion directe permet d'éviter les points de défaillance uniques, car chaque segment est conçu pour échouer indépendamment. Par exemple, si le trafic provenant de plusieurs clients surcharge un emplacement (bloc d'espace de clés), l'échec de la segmentation limite l'impact au segment responsable de la diffusion de l'emplacement.
La connexion directe évite les sauts intermédiaires, ce qui réduit le délai aller-retour (latence du client) entre votre client et la VM Valkey.
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 plus grande fiabilité. Toutefois, si vous choisissez de provisionner une instance sans instance répliquée, nous vous recommandons de choisir une instance à zone unique. Pour en savoir plus, consultez Choisir une instance à zone unique si votre instance n'utilise pas de réplicas.
Pour activer la haute disponibilité pour votre instance, vous devez provisionner au moins un nœud de réplication pour chaque fragment. Vous pouvez le faire lors de la création de l'instance ou ajuster le nombre de réplicas à au moins un réplica par segment. Les instances répliquées offrent un basculement automatique lors d'une maintenance planifiée et d'une défaillance de segment inattendue.
Vous devez configurer votre client conformément aux bonnes pratiques pour les clients. En suivant les bonnes pratiques recommandées, votre client peut gérer automatiquement et de manière élégante le rôle (défaillances automatiques) et les modifications d'attribution d'emplacements (remplacement de nœud, mise à l'échelle des consommateurs) pour votre instance, sans temps d'arrêt.
Instances dupliquées
Une instance Memorystore pour Valkey hautement disponible est une ressource régionale. Cela signifie que les VM principales et les réplicas des fragments sont répartis sur plusieurs zones pour éviter les pannes de zone. Memorystore pour Valkey est compatible avec les instances comportant 0, 1 ou 2 instances dupliquées par nœud.
Vous pouvez utiliser des instances répliquées pour augmenter le débit en lecture en effectuant un scaling des lectures.
Pour ce faire, vous devez utiliser la commande READONLY pour établir une connexion permettant à votre client de lire à partir des réplicas.
Forme d'instance avec 0 instance répliquée par nœud
Forme d'instance avec 1 instance répliquée par nœud
Forme d'instance avec deux instances dupliquées par nœud
Basculement automatique
Des transferts automatiques de défaillance dans un segment peuvent se produire en raison de maintenances 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 des réplicas de manière explicite. Le service peut également provisionner temporairement des réplicas 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 la section 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 quelques dizaines de secondes pour des é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 élit un réplica comme nouvelle instance principale.
La réparation du nœud peut prendre plusieurs minutes, le temps que le service remplace le nœud défaillant. Cela est vrai pour tous les nœuds principal et d'instance répliquée. Pour les instances à disponibilité faible (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 selon la nature de l'échec. Après la récupération automatique, les connexions doivent être réessayées avec un intervalle exponentiel entre les tentatives pour éviter de surcharger les nœuds principaux et les nœuds répliques.
Les clients qui utilisent des réplicas pour le débit de lecture doivent être prêts à faire face à 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 seront perdues en raison de la nature asynchrone du protocole de réplication de Valkey.
Les applications clientes peuvent exploiter la commande WAIT de Valkey pour améliorer la sécurité des données dans le monde réel.