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 Firebase. Ces recommandations s'appliquent aux instances hautement disponibles et aux instances sans réplication. Toutefois, pour tous les cas d'utilisation en production, nous vous recommandons vivement d'utiliser la configuration de 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 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é d'une instance. Cela va au-delà de ce que 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 le client Valkey 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, ou 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 un déploiement progressif et une stratégie de cycle de vie de création avant destruction pour éviter tout impact de la maintenance planifiée de Memorystore sur vos instances Valkey. Memorystore pour Valkey assure une maintenance sans temps d'arrêt en utilisant les fonctionnalités de redirection de requêtes du protocole d'instance OSS Valkey avec les mécanismes Memorystore suivants:
- Un 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 aucun 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 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
Memorystore pour Valkey effectue des déploiements avec une portée progressivement croissante 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 (temps pendant lequel la mise à jour est appliquée et surveillée avant d'être considérée comme un succès et de passer à l'étape suivante) sont intégrés à la flotte d'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é, Memorystore for Valkey ne met à jour qu'un seul domaine de panne ou zone à la fois pour s'assurer qu'un segment d'instance, y compris les réplicas principaux et secondaires, bénéficie 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 de création avant destruction pour maximiser la stabilité d'une instance. Cette stratégie offre les plus grands avantages lors de la mise à jour d'une instance avec de nombreux fragments. Appliquer uniquement les mises à jour à une petite partie de l'espace de clés utilisateur global à tout moment maximise 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 un nouveau réplica avec la dernière mise à jour logicielle au fragment. Memorystore crée un nœud 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 segment à mettre à jour est un nœud principal, il est d'abord converti en instance dupliquée avant d'être supprimé à l'aide d'un basculement coordonné.
- Memorystore supprime le réplica qui utilise le logiciel précédent.
- Pour chaque nœud de l'instance, Memorystore répète ce processus.
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éplication, 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
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: Exécutez un basculement principal coordonné
Si le nœud Valkey à mettre à jour est un nœud principal, Memorystore effectue un basculement coordonné vers le nœud dupliqué nouvellement ajouté. Memorystore supprime ensuite 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 le réplica existant est synchronisé à 100% 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 nœud de réplication, 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 à 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 prennent généralement 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 un impact sur la prise de décision concernant l'élection du nouveau nœud principal.
Étape 3: Supprimez le réplica
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 pour 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. Cela déclenche 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.
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. Vous disposez des options de configuration suivantes:
- Jour de la semaine: jour où la maintenance est effectuée
- Heure de début: heure à laquelle la maintenance commence
L'intervalle de maintenance dure une heure. Dans certains cas, la maintenance peut s'étendre au-delà de la période que vous sélectionnez.
Une fois que vous avez 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 définissez pour les intervalles de maintenance.
Intervalles de maintenance par défaut
Si vous ne définissez pas d'intervalle de maintenance, Memorystore for Firebase met à jour votre instance dans l'une des périodes suivantes, 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 chargé de gérer 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, planifiez-la 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: 1h
Notifications de maintenance à venir
Pour vous tenir 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. L'objet de ces notifications est "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 Redis 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 des 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 n'aura pas suffisamment de temps pour vous informer de la prochaine maintenance.
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 n'acceptons pas l'envoi 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 pour lesquelles une maintenance est planifiée dans un projet Google Cloud. Vous recevez une notification distincte pour chaque instance.
Pour savoir comment rechercher une maintenance planifiée, consultez Rechercher une maintenance planifiée.
Reprogrammer la maintenance
Cette section explique comment reprogrammer une maintenance. Par exemple, si le lancement d'un nouveau service est prévu pendant votre intervalle de maintenance actuel, vous pouvez repousser l'intervalle de maintenance jusqu'à quelques jours après le lancement.
Vous pouvez reprogrammer la maintenance dans les 14 jours suivant l'heure initialement prévue. 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 une heure dans un délai de deux semaines à compter de 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 programmée, vous ne pouvez pas reprogrammer la maintenance.
- Une fois la maintenance reprogrammée, Memorystore for Firebase vous envoie une notification par e-mail confirmant l'annulation de la maintenance précédente. De plus, vous recevrez une nouvelle notification de maintenance avec le nouveau calendrier.
Pour en savoir plus sur la reprogrammation de la maintenance, consultez la section Reprogrammer la maintenance.
Questions fréquentes
Cette section contient des questions fréquentes sur la maintenance de Memorystore pour Valkey.
Comment savoir quand une opération de maintenance est planifiée sur votre instance ?
Pour savoir quand une opération de maintenance est planifiée sur 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 des prochaines opérations de maintenance ?
Si vous vous abonnez aux notifications de maintenance et que vous définissez un intervalle de maintenance, Memorystore pour Valkey vous en informe par e-mail au moins une semaine avant un événement de maintenance.
Pendant combien de temps pouvez-vous reporter la maintenance ?
Une fois la maintenance planifiée pour votre instance, vous pouvez démarrer la mise à jour immédiatement ou la différer de deux semaines au maximum par rapport à la date et l'heure de maintenance initialement planifiées.
Par exemple, si vous planifiez une maintenance pour le 11 octobre à 23h15, vous pouvez la reporter jusqu'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 la section Reprogrammer la maintenance.
Quelles bonnes pratiques permettent de mettre à jour la maintenance planifiée de manière fluide ?
Pour garantir une expérience optimale de la mise à jour de maintenance, nous vous recommandons de procéder comme suit:
- Suivez les instructions pour configurer votre application cliente.
- Définir votre fenêtre de maintenance à un jour et une heure où votre instance enregistre un trafic minimal (par exemple, le dimanche à minuit).
- Activez la réception des notifications de maintenance. Par conséquent, Memorystore for Firebase vous avertit 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 le déploiement progressif par défaut du service. Cette valeur par défaut contient les bonnes pratiques pour les mises à jour de maintenance. Pour plus d'informations, consultez Maintenance transparente.
Quand pouvez-vous appliquer la maintenance immédiatement ?
Vous pouvez appliquer immédiatement une mise à jour de maintenance sur une instance de test pour voir son impact 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 de vos instances de production jusqu'à ce que vous ayez résolu le problème.
Si le jour et l'heure actuels conviennent à votre instance et que vous prévoyez une charge élevée à l'avenir, vous pouvez exécuter la mise à jour de maintenance immédiatement.
Les mises à jour de maintenance sont-elles toujours effectuées dans 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 termine généralement la mise à jour dans l'intervalle, mais ce n'est pas toujours le cas.
Pouvez-vous désactiver la maintenance ou la planifier sur certaines instances dans un premier temps ?
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 replanifier la maintenance pour différer son exécution jusqu'à deux semaines.
Étape suivante
- Consultez les autorisations requises pour gérer les intervalles de maintenance de votre instance.