Cette page explique comment Memorystore pour Valkey effectue la maintenance des instances. Il fournit également des informations et des recommandations de configuration que vos applications clientes doivent connaître pour profiter de la conception de maintenance sans temps d'arrêt de Memorystore for Firebase. Ces recommandations s'appliquent aux instances hautement disponibles et aux instances sans réplication. Toutefois, nous vous recommandons vivement la configuration haute disponibilité pour tous les cas d'utilisation de production.
Memorystore pour Valkey met régulièrement à jour les instances pour s'assurer que le service est fiable, performant, sécurisé et à jour. Ces mises à jour sont appelées maintenances. La maintenance est entièrement gérée par le service et est conçue pour n'avoir aucun impact sur le temps d'arrêt.
La maintenance se divise généralement en trois catégories:
- Fonctionnalités de Memorystore Pour lancer certaines fonctionnalités, Memorystore nécessite une mise à jour de maintenance.
- Correctifs du système d'exploitation Nous surveillons en permanence les dernières failles de sécurité détectées dans le système d'exploitation. Lorsque des failles sont découvertes, nous appliquons des correctifs au système d'exploitation pour vous protéger contre de nouveaux risques.
- Correctifs de base de données. La maintenance peut inclure une mise à jour de Valkey pour améliorer les caractéristiques de sécurité, de performances et de fiabilité des instances au-delà de ce que propose Valkey OSS.
Configurer votre application cliente
Pour configurer votre application cliente afin d'optimiser les performances et la disponibilité pendant la maintenance, procédez comme suit:
- Utilisez et configurez votre client tiers conformément aux bonnes pratiques concernant les clients pour vous assurer que toute maintenance planifiée n'a pas d'impact sur l'application cliente. Les configurations client recommandées peuvent éviter les réinitialisations de connexion grâce à des actualisations périodiques de la topologie en ligne et à des rotations de connexion en arrière-plan.
- Testez votre application cliente avec une série d'opérations de mise à jour (telles que l'ajustement de l'échelle, la modification du nombre de réplicas) tout en exécutant une charge de travail représentative sur les nœuds principaux et les réplicas, et en surveillant l'impact sur le client. Ces mises à jour testent la logique d'actualisation de la topologie en ligne sur les clients, l'impact de la synchronisation complète, la découverte de nouveaux nœuds et la possibilité de supprimer des nœuds existants. Les tests permettent de vérifier que le client tiers est correctement configuré pour éviter tout impact négatif sur votre application.
Maintenance planifiée
Memorystore pour Valkey s'appuie sur une stratégie de déploiement graduel et de cycle de vie "créer avant de détruire" pour éviter tout impact de la maintenance planifiée de Memorystore sur vos instances Valkey. La maintenance sans temps d'arrêt est obtenue en utilisant les fonctionnalités de redirection des requêtes du protocole de cluster OSS Valkey en conjonction avec les mécanismes Memorystore suivants:
- Basculement coordonné sans perte de données
- Suppression de nœuds de manière élégante pour permettre aux clients de se mettre à jour avec les mises à jour de la topologie des nœuds sans impact sur la disponibilité
- Les points de terminaison PSC de l'instance ne sont pas affectés par la maintenance. Pour en savoir plus sur les points de terminaison PSC, consultez la section Points de terminaison d'instance.
Le comportement du service décrit dans les sections suivantes ne s'applique qu'aux opérations de maintenance planifiées. Pour en savoir plus sur l'impact des événements imprévus tels que les défaillances matérielles, consultez la section Comportement du client lors d'un basculement imprévu.
Intervalles de maintenance par défaut
Par défaut, Memorystore met à jour votre instance dans les fenêtres suivantes en fonction du fuseau horaire de votre instance:
Période de la semaine (du lundi au vendredi) : de 22 h à 6 h
Période du week-end : du vendredi, à 22 h au lundi, à 6 h
Stratégie de déploiement progressif
Les déploiements Memorystore pour Valkey sont effectués avec une portée progressivement croissante et à un rythme qui permet de détecter les défaillances suffisamment tôt pour atténuer leur impact et établir une confiance en termes de stabilité. Les temps de cuisson (durant lesquels la mise à jour est appliquée et surveillée avant d'être considérée comme réussie et de passer à l'étape suivante) sont intégrés à l'ensemble des instances Memorystore à l'échelle du service. De plus, les temps de cuisson sont intégrés aux instances dans les zones d'une région (plusieurs domaines de défaillance) afin de réduire l'étendue de l'impact, le cas échéant.
Pour votre instance configurée pour la haute disponibilité, un seul domaine de panne/zone est mis à jour à la fois pour vous assurer qu'un segment d'instance, y compris l'instance principale et les instances dupliquées, bénéficie de la haute disponibilité tout au long de la mise à jour. De plus, seuls quelques nœuds Valkey sont mis à jour à un moment donné. Les mises à jour utilisent un mécanisme de cycle de vie de création avant destruction pour maximiser la stabilité des instances. Cette stratégie offre les meilleurs avantages lorsque vous mettez à jour une instance avec de nombreux fragments. En appliquant les mises à jour à une petite partie de l'espace de clés utilisateur global à un moment donné, vous maximisez la disponibilité des données.
Stratégie de cycle de vie "Créer avant de détruire"
Une instance Valkey comporte plusieurs fragments. Chaque fragment comporte un nœud principal et un ou plusieurs nœuds d'instances dupliquées. Memorystore utilise le processus suivant pour mettre à jour tout nœud de clé-valeur principal ou répliqué existant dans un segment:
- Memorystore pour Valkey ajoute d'abord un réplica complètement nouveau avec la dernière mise à jour logicielle au fragment. Memorystore crée un nœud entièrement nouveau au lieu de mettre à jour un nœud existant pour s'assurer que votre capacité provisionnée est conservée en cas de défaillance de démarrage inattendue.
- Si un nœud du shard à mettre à jour est un nœud principal, il est d'abord converti en réplica avant d'être supprimé à l'aide d'un basculement coordonné.
- Ensuite, Memorystore supprime le réplica qui utilise le logiciel précédent.
- Le processus est répété pour chaque nœud de l'instance.
La stratégie de création avant destruction permet de conserver la capacité provisionnée de l'instance, contrairement à un déploiement par vagues typique qui est mis à jour sur place, mais entraîne une interruption de disponibilité (et parfois une perte de données) pour l'application cliente. Pour les shards sans réplicas, Memorystore pour Valkey provisionne toujours d'abord un nouveau réplica, coordonne le basculement et remplace enfin le nœud principal existant du shard.
Étape 1: Ajouter un réplica Valkey
La première étape du mécanisme de création avant destruction consiste à ajouter un nœud de réplication avec le dernier logiciel à l'aide du mécanisme de Valkey OSS de synchronisation complète pour copier les données de l'instance principale vers le nœud de réplication. Pour ce faire, un processus enfant est créé et la réplication sans disque est utilisée pour amorcer le réplica.
Pour tirer le meilleur parti de l'architecture d'échelle horizontale de l'instance, provisionnez un plus grand nombre de fragments afin de réduire la taille de l'espace de clés dans un nœud. Un ensemble de données plus petit par nœud permet de réduire l'impact de la latence de fourche sur une opération de synchronisation complète. Il accélère également la copie des données entre les nœuds.
Étape 2: Basculement principal coordonné
Si le nœud Valkey à mettre à jour est un nœud principal, Memorystore effectue d'abord un basculement coordonné vers le nœud dupliqué nouvellement ajouté, puis procède à la suppression du nœud. Lors du basculement coordonné, le client et les nœuds Valkey collaborent et utilisent les stratégies suivantes pour éviter les temps d'arrêt de l'application:
- Les requêtes client entrantes sont temporairement bloquées sur le nœud principal, ce qui permet de s'assurer que le réplica existant est 100% synchronisé avec le nœud principal.
- Le réplicat termine le processus d'élection pour prendre le rôle de principal.
- L'ancien nœud principal, qui est désormais un réplica, débloque les requêtes existantes et les redirige vers le nouveau nœud principal élu à l'aide du protocole de cluster OSS Valkey. Toutes les nouvelles requêtes envoyées à l'ancien nœud d'instance répliquée continuent d'être redirigées vers le nouveau nœud principal.
- Votre client compatible avec Valkey actualise sa topologie en mémoire. Il apprend l'adresse du nouveau point de terminaison principal et ne nécessite plus de redirections.
Les basculements coordonnés devraient généralement prendre des dizaines de millisecondes. Toutefois, les données en cours de transfert en attente d'être effacées dans les réplicas et la taille totale de votre instance peuvent augmenter la latence de basculement. La taille de l'instance peut affecter la convergence entre les nœuds principaux, ce qui a une incidence sur la prise de décision concernant l'élection du nouveau nœud principal.
Étape 3: Supprimer la réplication de Valkey
La dernière étape du mécanisme de création avant destruction consiste à supprimer le nœud de réplication sur le logiciel précédent. Une suppression soudaine de nœud aurait un impact sur les applications clientes, car elles mettent en cache les informations sur le point de terminaison et la topologie de l'instance. Memorystore pour Valkey a conçu la suppression d'un réplica Valkey de manière élégante afin de permettre aux applications clientes d'actualiser leur topologie avant de subir un arrêt de nœud dur. La topologie est personnalisée pour permettre aux clients de découvrir le nouveau réplica, mais aussi d'oublier celui qui doit être supprimé à l'avance.
Le nœud de réplication exécutant le logiciel précédent est conservé pendant une certaine période de vidage, généralement de l'ordre de quelques minutes, au cours de laquelle il commence à rediriger les requêtes de lecture entrantes vers le nœud principal de son segment. Il permet au client tiers d'actualiser la topologie des nœuds et d'en savoir plus sur les nouveaux points de terminaison des réplicas. Si le client tente d'atteindre un nœud supprimé après la période de vidage, la tentative échoue, ce qui déclenche à son tour une actualisation de la topologie des nœuds sur le client qui se connecte afin qu'il soit informé du changement de réplica. Les nouvelles actualisations de la topologie des nœuds ne montrent pas le nœud de réplication à supprimer.