Cette page explique comment Memorystore pour Valkey effectue la maintenance des instances. Il fournit également des informations et des recommandations de configuration dont vos applications clientes doivent tenir compte pour tirer parti Memorystore pour la conception de maintenance sans temps d'arrêt de Valkey. Ces recommandations s'appliquent aux instances hautement disponibles et aux instances sans réplication. Toutefois, nous vous recommandons vivement de configurer la haute disponibilité pour tous les cas d'utilisation en production.
Memorystore pour Valkey met régulièrement à jour les instances afin de 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 la sécurité, les performances et la fiabilité des instances au-delà de ce qu'OSS Valkey fournit.
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 intégrée sur les clients, l'impact de la synchronisation complète, la détection de nouveaux nœuds et la capacité existante de suppression des nœuds. 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 progressif et une stratégie de cycle de vie "créer avant destruction" pour éviter tout impact des temps d'arrêt 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 élégante des nœuds pour permettre aux clients de rattraper 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'à la maintenance planifiée. 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 d'intégration sont intégrés aux instances des différentes zones d'une même région (plusieurs domaines de défaillance) afin de réduire l'impact, le cas échéant.
Pour une instance configurée pour la haute disponibilité, un seul domaine de panne/zone est mis à jour à la fois pour s'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. L'application des mises à jour à une petite partie de l'espace de clés utilisateur global à un moment donné permet d'optimiser la disponibilité des données.
Stratégie de cycle de vie de création avant destruction
Une instance Valkey comporte plusieurs segments. 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 à la partition une toute nouvelle instance dupliquée avec la dernière mise à jour logicielle. 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é.
- Memorystore supprime ensuite l'instance répliquée 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 segments sans instance répliquée, Memorystore pour Valkey provisionne d'abord une nouvelle instance répliquée, coordonne le basculement, puis remplace le nœud principal existant du segment.
É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, dupliquez un processus enfant et utilisez la réplication sans disque pour amorcer l'instance répliquée.
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 exécute d'abord un basculement coordonné vers le nœud d'instance répliquée qui vient d'être 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 synchronisé à 100 % avec le nœud principal.
- L'instance répliquée termine le processus d'élection pour reprendre le rôle principal.
- Le nœud principal précédent, désormais une instance répliquée, débloque les requêtes existantes et les redirige vers le nœud principal nouvellement choisi à 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 plusieurs 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 affecte la prise de décision lors de l'élection du nouveau nœud principal.
Étape 3: Supprimez l'instance répliquée 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'une instance répliquée Valkey qui se déroule sans accroc afin de permettre aux applications clientes d'actualiser leur topologie avant l'arrêt d'un nœud dur. La topologie est personnalisée pour permettre aux clients d'en savoir plus sur la nouvelle instance répliquée, mais aussi d'oublier celle à supprimer à 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'accéder à un nœud supprimé après la période de drainage, la tentative échoue, ce qui déclenche l'actualisation de la topologie du nœud sur le client connecté afin qu'il soit informé de la modification apportée à l'instance répliquée. Les nouvelles actualisations de la topologie des nœuds ne montrent pas le nœud de réplication à supprimer.