Haute disponibilité et réplications

Cette page explique comment l'architecture 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 nœuds Memorystore pour Valkey gérés. Pour ce faire, vos clients se connectent à des points de terminaison individuels, comme décrit dans la section Se connecter à une instance Memorystore pour Valkey.

La connexion directe à un ou plusieurs shards offre les avantages suivants:

  • La connexion directe évite les sauts intermédiaires, ce qui réduit le délai aller-retour (latence client) entre votre client et le nœud Valkey.

  • Lorsque le mode cluster est 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 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.

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 segment. Vous pouvez le faire lors de la création de l'instance ou ajuster le nombre de réplicas à au moins une instance répliquée 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 pourra gérer automatiquement et sans temps d'arrêt les éléments suivants de votre instance:

  • Le rôle (basculements automatiques)

  • Point de terminaison (remplacement de nœud)

  • Modifications de l'attribution d'emplacements liées au mode cluster activé (mise à l'échelle et réduction de l'échelle des consommateurs)

Instances dupliquées

Une instance Memorystore pour Valkey hautement disponible est une ressource régionale. Cela signifie que Memorystore pour Valkey distribue les nœuds principaux et les nœuds de réplication des fragments sur plusieurs zones pour se protéger contre une panne zonale. 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, mais au prix d'une obsolescence potentielle des données.

  • Mode cluster activé:utilisez la commande READONLY pour établir une connexion permettant à votre client de lire à partir des réplicas.
  • Mode cluster désactivé:connectez-vous au point de terminaison de lecteur pour vous connecter à l'une des instances dupliquées disponibles.

Formes d'instance avec mode de cluster activé

Les diagrammes suivants illustrent les formes des instances en mode cluster activé:

Avec trois segments et zéro réplication par nœud

Instance Memorystore pour Valkey avec mode cluster activé, sans réplication et dont les nœuds sont répartis de manière égale sur trois zones.

Avec trois segments et une instance dupliquée par nœud

Instance Memorystore pour Valkey avec mode cluster activé, avec un réplica par nœud et des nœuds répartis uniformément sur trois zones.

Avec trois segments et deux réplications par nœud

Instance Memorystore pour Valkey avec mode cluster activé, avec deux réplications par nœud et des nœuds répartis uniformément sur trois zones.

Formes des instances avec le mode cluster désactivé

Les diagrammes suivants illustrent les formes des instances en mode cluster désactivé:

Avec deux réplicas

Instance Memorystore pour Valkey en mode cluster désactivé avec deux réplicas et des nœuds répartis uniformément sur trois zones.

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 à haute disponibilité (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.