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 pour Valkey. Ces recommandations s'appliquent aux instances hautement disponibles et aux instances sans instances répliquées. Toutefois, pour tous les cas d'utilisation en production, nous vous recommandons vivement d'utiliser la configuration à haute disponibilité.
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 les temps d'arrêt.
La maintenance se divise généralement en plusieurs 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é d'une instance. Cela va au-delà de ce que propose OSS Valkey.
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 instructions de la section Bonnes pratiques concernant les clients Valkey pour vous assurer que les opérations de maintenance planifiées n'ont pas d'impact sur l'application cliente. Nos configurations client recommandées peuvent éviter les réinitialisations de connexion grâce à des actualisations périodiques de la topologie intégrée 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'augmentation ou la diminution de la capacité, ou la modification du nombre d'instances répliquées) tout en exécutant une charge de travail représentative sur les nœuds principaux et les instances répliquées, 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écouverte de nouveaux nœuds et la capacité de suppression des nœuds existants. Les tests permettent de s'assurer que le client tiers est configuré correctement afin d'éviter tout impact négatif sur votre application.
Instances avec le mode cluster désactivé
Pendant la maintenance, les instances avec le mode cluster désactivé subissent un basculement, ce qui réinitialise leurs connexions. Ce basculement dure généralement 15 secondes. Pour reconnecter vos applications clientes à l'instance après le basculement, nous vous recommandons de créer un mécanisme de nouvelle tentative avec un intervalle exponentiel entre les tentatives. Après avoir reçu un e-mail vous informant d'une maintenance à venir, vous pouvez exécuter une simulation de maintenance sur une instance hors production pour tester l'impact de la maintenance sur l'instance. Pour en savoir plus, consultez Exécuter une simulation de maintenance sur une instance.
Nous vous recommandons également de maintenir la métrique /instance/memory/maximum_utilization à 50% ou moins au début de la maintenance planifiée. Les conseils pour cette métrique font référence à un seuil de 80% pour la gestion de la mémoire. Toutefois, nous vous recommandons de viser un ratio de 50% ou moins pendant la maintenance. Pour en savoir plus sur la métrique, consultez Métriques Cloud Monitoring.
Pour garantir ce ratio, vous pouvez procéder de l'une des manières suivantes :
- Planifiez la maintenance lorsque le trafic de l'instance est faible.
- Augmentez temporairement la taille de votre instance pendant l'intervalle de maintenance.
Maintenance planifiée
Memorystore pour Valkey utilise une stratégie de déploiement progressif et de cycle de vie "créer avant de détruire" pour éviter tout temps d'arrêt pendant les maintenances programmées de Memorystore sur vos instances Valkey. Memorystore pour Valkey permet d'effectuer des opérations de maintenance sans temps d'arrêt en utilisant les fonctionnalités de redirection des requêtes du protocole d'instance Valkey OSS avec les mécanismes Memorystore suivants :
- Un basculement coordonné sans perte de données.
- Une suppression progressive 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 Private Service Connect de l'instance, qui ne sont pas affectés par la maintenance. Pour en savoir plus sur ces points de terminaison, consultez 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 d'événements non planifiés tels que des défaillances matérielles, consultez Comportement du client lors d'un basculement non planifié.
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
Memorystore pour Valkey effectue des déploiements avec un champ d'application qui augmente progressivement, et à un rythme qui permet de détecter les défaillances suffisamment tôt pour atténuer tout impact et établir une confiance en termes de stabilité. Les temps de cuisson (le temps pendant lequel 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 dans l'ensemble du parc d'instances Memorystore à l'échelle du service. De plus, les temps de bake sont intégrés aux instances dans les zones d'une région (plusieurs domaines de défaillance) afin de réduire l'impact, le cas échéant.
Pour votre instance configurée pour la haute disponibilité, Memorystore pour Valkey met à jour au maximum un domaine d'erreur ou une zone à la fois pour s'assurer qu'un segment d'instance, y compris l'instance principale et les instances répliquées, dispose d'une haute disponibilité tout au long de la mise à jour. De plus, Memorystore pour Valkey ne met à jour que quelques nœuds à la fois. Les mises à jour utilisent un mécanisme de cycle de vie "créer avant de détruire" pour maximiser la stabilité d'une instance. Cette stratégie offre le plus d'avantages lors de la mise à jour d'une instance avec de nombreux segments. En n'appliquant les mises à jour qu'à une petite partie de l'espace de clés utilisateur global à tout moment, vous maximisez la disponibilité des données.
Stratégie de cycle de vie "créer avant de détruire"
Une instance Valkey comporte plusieurs segments. Chaque segment comporte un nœud principal et zéro ou plusieurs nœuds d'instance répliquée. Memorystore utilise le processus suivant pour mettre à jour tout nœud Valkey principal ou répliqué existant dans un segment :
- Memorystore pour Valkey ajoute une nouvelle instance répliquée avec la dernière mise à jour logicielle au segment. Memorystore crée un nœud au lieu de mettre à jour un nœud existant, afin de s'assurer que votre capacité provisionnée est conservée en cas d'échec de démarrage inattendu.
- Si un nœud du segment à mettre à jour est un nœud principal, il est d'abord converti en instance répliquée avant d'être supprimé à l'aide d'un basculement coordonné.
- Memorystore supprime l'instance répliquée qui utilise l'ancienne version du logiciel.
- Memorystore répète ce processus 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, par rapport à un déploiement progressif classique qui effectue une mise à jour sur place, mais entraîne une interruption de la disponibilité (et parfois une perte de données) pour l'application cliente. Pour les segments sans instances répliquées, 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 une instance répliquée
La première étape du mécanisme de création avant destruction consiste à ajouter un nœud d'instance répliquée avec la dernière version du logiciel en utilisant le mécanisme de synchronisation complète d'OSS Valkey pour copier les données du nœud principal vers le nœud d'instance répliquée. Pour ce faire, un processus enfant est dupliqué et la réplication sans disque est utilisée pour amorcer l'instance répliquée. Memorystore pour Valkey est compatible avec la réplication sans disque. À moins que vous n'activiez la persistance, Memorystore pour Valkey n'utilise pas de disques pendant la réplication.
Vous pouvez tirer le meilleur parti de l'architecture de scaling horizontal de l'instance en provisionnant un plus grand nombre de segments pour réduire la taille de l'espace de clés dans un nœud. Le fait de disposer d'un ensemble de données plus petit par nœud permet de réduire l'impact de la latence de duplication d'une opération de synchronisation complète. Elle accélère également la copie des données entre les nœuds.
Étape 2 : Exécutez un basculement principal coordonné
Si le nœud Valkey à mettre à jour est un nœud principal, Memorystore exécute un basculement coordonné vers le nœud d'instance répliquée nouvellement ajouté. Ensuite, Memorystore supprime le 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 l'instance dupliquée existante est synchronisée à 100% avec le nœud principal.
- L'instance répliquée termine le processus d'élection pour assumer le rôle principal.
- L'ancien nœud principal, désormais un nœud d'instance répliquée, débloque les requêtes existantes et les redirige vers le nouveau nœud principal à l'aide du protocole d'instance Valkey OSS. Toutes les nouvelles requêtes envoyées au nœud d'instance répliquée précédent 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 n'a plus besoin de redirections.
Les basculements coordonnés prennent généralement quelques dizaines de millisecondes. Toutefois, les données en cours de transfert en attente d'être vidées dans les instances répliquées et la taille totale de votre instance peuvent augmenter la latence du basculement. La taille de l'instance peut affecter la convergence entre les nœuds principaux, ce qui affecte la prise de décision concernant l'élection du nouveau nœud principal.
Étape 3 : Supprimez l'instance répliquée
La dernière étape du mécanisme de création avant destruction consiste à supprimer le nœud d'instance répliquée sur l'ancienne version du logiciel. La suppression de nœuds a un impact sur les applications clientes, car Memorystore pour Valkey supprime vos clients. Étant donné que l'actualisation de la topologie ne s'applique pas aux instances en mode cluster désactivé, nous vous recommandons d'utiliser un mécanisme de nouvelle tentative avec intervalle exponentiel entre les tentatives pour reconnecter votre application aux nouveaux points de terminaison d'instance répliquée une fois qu'ils sont disponibles.
Pour les instances en mode cluster activé, Memorystore pour Valkey a conçu la suppression d'une instance répliquée Valkey de manière progressive pour permettre aux applications clientes d'actualiser leur topologie avant de subir un arrêt brutal du nœud. La topologie est personnalisée pour permettre aux clients de découvrir la nouvelle instance répliquée, mais aussi d'oublier celle à supprimer à l'avance.
Memorystore pour Valkey conserve le nœud d'instance répliquée exécutant l'ancienne version du logiciel pendant une certaine période de drainage, 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. Ce processus permet au client tiers d'actualiser la topologie du nœud et de découvrir les nouveaux points de terminaison d'instance répliquée. Si le client tente d'atteindre un nœud supprimé après la période de drainage, la tentative échoue. Cet échec déclenche une actualisation de la topologie des nœuds sur le client de connexion afin qu'il soit informé du changement d'instance répliquée. Les nouvelles actualisations de la topologie des nœuds ne voient pas le nœud d'instance répliquée à supprimer.
Paramètres de maintenance
Memorystore pour Valkey vous permet de personnaliser les calendriers de maintenance en fonction des besoins de votre application et de minimiser les perturbations. Pour personnaliser un calendrier de maintenance, configurez un intervalle de maintenance pour votre instance.
Vous définissez des intervalles de maintenance pour chaque instance Memorystore pour Valkey et vous disposez des options de configuration suivantes :
- Jour de la semaine : jour où la maintenance a lieu.
- Heure de début : heure à laquelle la maintenance commence
L'intervalle de maintenance dure une heure. Dans certains cas, la maintenance peut dépasser l'intervalle que vous avez sélectionné.
Après avoir configuré un intervalle de maintenance pour une instance, Memorystore pour Valkey planifie la maintenance automatique à l'avenir en fonction des préférences que vous avez définies pour les intervalles de maintenance.
Intervalles de maintenance par défaut
Si vous ne définissez pas d'intervalle de maintenance, Memorystore pour Valkey met à jour votre instance dans l'un des intervalles suivants, en fonction du fuseau horaire de votre instance :
- Période de la semaine (du lundi au vendredi) : de 22h à 6h
- Période du week-end : du vendredi, à 22h au lundi, à 6h
Exemple de maintenance
En tant que développeur gérant un service de panier d'achat chez un marchand, vous supervisez un environnement de production qui inclut une instance Memorystore pour Valkey. Pour garantir des performances optimales pendant la maintenance, vous la planifiez lorsque l'instance enregistre un trafic minimal. Cela se produit généralement vers minuit le dimanche.
Dans ce cas, définissez l'intervalle de maintenance de votre instance de production sur le jour et l'heure suivants :
- Jour de la semaine : dimanche
- Heure de début : 1h00
Notifications de maintenance à venir
Pour vous assurer de rester informé des événements de maintenance sur votre instance, configurez des notifications par e-mail concernant la maintenance à venir au moins une semaine avant la planification des opérations de maintenance. Ces notifications ont pour objet "Upcoming
maintenance for your Cloud Memorystore instance [your-instance-name]".
Memorystore pour Valkey envoie également une notification lorsque la maintenance commence pour votre instance. L'objet de l'e-mail est "Maintenance
is undergoing for your Cloud Memorystore instance [your-instance-name]".
Une fois la maintenance terminée, Memorystore pour Valkey envoie une notification de fin. L'objet de l'e-mail est "Completed Maintenance
for your Cloud Memorystore instance [your-instance-name]".
Si Memorystore pour Valkey reprogramme la maintenance, vous recevez un e-mail vous informant de l'annulation de la maintenance. L'objet de cet e-mail est "Canceled maintenance for your Cloud Memorystore instance [your-instance-name]".
Pour recevoir des notifications de maintenance, vous devez les activer. Pour vous inscrire aux notifications de maintenance, procédez comme suit :
Pour recevoir les notifications de maintenance de Memorystore pour Valkey, suivez ces étapes au moins une semaine avant la mise à jour de maintenance planifiée pour votre instance. Sinon, Memorystore pour Valkey ne dispose pas de suffisamment de temps pour vous informer de la maintenance à venir.
Memorystore pour Valkey envoie des notifications à l'adresse e-mail associée à votre compte Google. Vous ne pouvez pas configurer d'alias d'adresse e-mail personnalisé (par exemple, un alias d'adresse e-mail d'équipe). De plus, nous ne pouvons pas envoyer de notifications à une autre adresse e-mail.
En vous abonnant aux notifications de maintenance, vous recevez des alertes pour toutes les instances Memorystore pour Valkey dont la maintenance est planifiée dans un projet Google Cloud . Vous recevez une notification distincte pour chaque instance.
Pour en savoir plus sur la recherche d'une maintenance planifiée, consultez Rechercher une maintenance planifiée.
Reprogrammer la maintenance
Cette section explique comment reprogrammer une maintenance. Par exemple, si un nouveau service doit être lancé pendant l'intervalle de maintenance actuel, vous pouvez reporter l'intervalle de maintenance à quelques jours après le lancement.
Vous pouvez replanifier la maintenance dans les 14 jours suivant l'heure planifiée initialement. Pour reprogrammer la maintenance, choisissez l'une des options suivantes :
- Mettre à jour maintenant : au lieu d'attendre l'intervalle de maintenance programmé, vous pouvez appliquer immédiatement les mises à jour à votre instance.
- Jour et heure personnalisés : choisissez n'importe quelle heure dans les 14 jours suivant l'heure de maintenance initialement planifiée.
Lorsque vous reprogrammez une maintenance, les restrictions suivantes s'appliquent :
- S'il reste moins d'une heure avant l'heure de maintenance actuellement planifiée, vous ne pouvez pas replanifier la maintenance.
- Une fois que vous avez reprogrammé la maintenance, Memorystore pour Valkey vous envoie une notification par e-mail confirmant l'annulation de la maintenance précédente. De plus, vous recevez une nouvelle notification de maintenance avec la planification mise à jour.
Pour en savoir plus sur la reprogrammation de la maintenance, consultez Reprogrammer la maintenance.
Questions fréquentes
Cette section contient les questions fréquentes sur la maintenance de Memorystore pour Valkey.
Comment savoir quand une opération de maintenance est planifiée pour votre instance ?
Pour savoir quand la maintenance est planifiée pour votre instance, nous vous recommandons de vous abonner aux notifications et de configurer un intervalle de maintenance. Vous pouvez également vérifier manuellement votre instance pour voir si le paramètre maintenanceSchedule apparaît dans la réponse.
Quand Memorystore pour Valkey vous informe-t-il d'une maintenance à venir ?
Si vous vous abonnez aux notifications de maintenance et définissez un intervalle de maintenance, Memorystore pour Valkey vous envoie une notification par e-mail au moins une semaine avant un événement de maintenance.
Combien de temps pouvez-vous différer la maintenance ?
Après avoir planifié la maintenance de votre instance, vous pouvez soit démarrer la mise à jour de votre instance immédiatement, soit la reporter de deux semaines maximum à compter de la date et de l'heure de maintenance initialement prévues.
Par exemple, si vous planifiez une maintenance pour le 11 octobre à 23h15, vous pouvez la reporter au 25 octobre à 23h15. Si vous ne prenez aucune mesure, la maintenance s'exécute à la date et à l'heure planifiées.
Pour en savoir plus, consultez Reprogrammer la maintenance.
Quelles bonnes pratiques permettent de garantir une expérience de mise à jour de maintenance fluide ?
Pour garantir une expérience de mise à jour de maintenance fluide, nous vous recommandons de procéder comme suit :
- Suivez les instructions pour configurer votre application cliente.
- Définissez votre intervalle de maintenance sur un jour et une heure où votre instance enregistre un trafic minimal (par exemple, le dimanche à minuit).
- Activer les notifications de maintenance Par conséquent, Memorystore pour Valkey vous informe par e-mail au moins sept jours avant la planification d'une mise à jour de maintenance pour votre instance.
- Si vous n'avez pas d'heure à faible impact ou sans impact pour l'utilisation de votre application, utilisez la valeur par défaut du service pour les déploiements progressifs. Cette valeur par défaut contient les bonnes pratiques pour les mises à jour de maintenance. Pour plus d'informations, consultez Maintenance transparente.
Dans quels cas vous recommandons-nous d'appliquer immédiatement une mise à jour de maintenance ?
Vous pouvez appliquer immédiatement une mise à jour de maintenance sur une instance de test pour voir l'impact de la mise à jour sur votre application. Vous pouvez observer l'impact de cette mise à jour. En cas de problème avec la mise à jour, vous pouvez différer la maintenance sur vos instances de production jusqu'à ce que vous résolviez les problèmes.
Si le jour et l'heure actuels conviennent à votre instance et que vous prévoyez une charge élevée sur votre instance à l'avenir, vous pouvez exécuter la mise à jour de maintenance immédiatement.
Les mises à jour de maintenance se terminent-elles toujours pendant l'intervalle de maintenance ?
Memorystore pour Valkey lance une mise à jour de maintenance dans l'intervalle de maintenance que vous spécifiez. Memorystore pour Valkey effectue généralement la mise à jour dans l'intervalle, mais ce n'est pas toujours le cas.
Pouvez-vous désactiver la maintenance ou planifier la maintenance sur certaines instances en premier ?
Vous ne pouvez pas désactiver la maintenance ni contrôler l'ordre de maintenance de vos instances. Toutefois, après avoir reçu la notification de maintenance initiale, vous pouvez reprogrammer la maintenance pour la reporter de deux semaines maximum.
Étapes suivantes
- Consultez les autorisations dont vous avez besoin pour gérer les intervalles de maintenance de votre instance.