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 pour Valkey repose sur une architecture hautement disponible, dans laquelle vos clients accèdent directement aux VM Memorystore pour Valkey gérées. 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 offre 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 provenant de plusieurs clients surcharge un emplacement (fragment de l'espace de clés), la défaillance du segment limite l'impact au segment chargé de servir l'emplacement.
La connexion directe évite les sauts intermédiaires, ce qui réduit le délai aller-retour (latence client) entre votre client et la VM Valkey.
Configurations recommandées
Nous vous recommandons de créer des instances multizones à haute disponibilité plutôt que des instances à zone unique, car elles offrent une meilleure fiabilité. Toutefois, si vous choisissez de provisionner une instance sans réplicas, 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 réplicas assurent un basculement automatique lors de la maintenance planifiée et en cas de défaillance inattendue d'un segment.
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 fluide le rôle (basculements automatiques) et les modifications d'attribution d'emplacements (remplacement de nœud, agrandissement/rétrécissement de l'effectuer un scaling horizontal 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 avec 0, 1 ou 2 répliques par nœud.
Vous pouvez utiliser des réplicas pour augmenter le débit de lecture en échelonnant les lectures.
Pour ce faire, vous devez utiliser la commande READONLY afin d'établir une connexion qui permet à votre client de lire à partir des réplicas.
Forme d'instance avec 0 répliques par nœud
Forme d'instance avec une instance dupliqué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 dupliqué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 plusieurs dizaines de secondes en cas d'événements imprévus tels qu'un plantage de processus de 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. C'est le cas pour tous les nœuds principaux et d'instance dupliquée. Pour les instances qui ne sont pas disponibilité élevée (aucun réplica provisionné), la réparation d'un nœud principal défaillant prend également du temps, de l'ordre de 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 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 être 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.
Impact du dysfonctionnement d'une seule zone 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 est indisponible, l'ensemble de l'espace de clés est disponible pour les lectures et les écritures. Toutefois, comme certains réplicas de 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 en cas de panne d'une seule zone. Une fois la panne terminée, les réplicas de la zone concernée sont restaurés et la capacité de lecture du cluster retrouve sa valeur configurée. Pour en savoir plus, consultez la section Modèles d'applications évolutives et fiables.
Instances non haute disponibilité (sans réplication) : en cas de panne d'une zone, la partie de l'espace de clés provisionnée dans la zone concernée subit un vidage de données et n'est pas disponible pour les écritures ni les lectures pendant toute la durée de la panne. Une fois l'indisponibilité terminée, les principaux de la zone concernée sont restaurés et la capacité du cluster revient à sa valeur configurée.
Instances à zone unique
- Instances HA et non HA:en cas de panne dans la zone dans laquelle l'instance est provisionnée, le cluster est indisponible et les données sont effacées. Si une autre zone est indisponible, le cluster continue de diffuser les requêtes de lecture et d'écriture.