Cette page explique comment Memorystore for Redis Cluster effectue la maintenance sur les clusters. Elle fournit également des informations et des recommandations de configuration dont vos applications clientes doivent tenir compte pour profiter de la conception de maintenance sans temps d'arrêt de Memorystore for Redis Cluster. Ces recommandations s'appliquent à la fois aux clusters à haute disponibilité et aux clusters sans instances dupliquées. Toutefois, nous vous recommandons vivement d'utiliser la configuration à haute disponibilité pour tous les cas d'utilisation en production.
Memorystore for Redis Cluster met régulièrement à jour les clusters pour s'assurer que le service est fiable, performant, sécurisé et à jour. Ces mises à jour sont appelées maintenance. 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 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 nouvelles failles de sécurité identifiées dans le système d'exploitation. Une fois détectées, nous appliquons un correctif au système d'exploitation pour vous protéger des nouveaux risques.
- Correctifs de la base de données : la maintenance peut inclure une mise à jour de Redis pour améliorer les caractéristiques de sécurité, de performances et de fiabilité des clusters au-delà de ce que Redis fournit.
Configurer votre application cliente
Pour configurer votre application cliente afin d'obtenir les meilleures performances et la meilleure disponibilité possibles pendant la maintenance, procédez comme suit :
- Utilisez et configurez votre client de cluster OSS Redis conformément aux bonnes pratiques concernant les clients Redis pour vous assurer qu'aucune maintenance planifiée n'a d'incidence sur votre application cliente. Nos configurations de client recommandées peuvent éviter les réinitialisations de connexion grâce à des actualisations de la topologie en ligne périodiques 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 le scaling à la hausse ou à la baisse, les modifications du nombre d'instances dupliquées) tout en exécutant une charge de travail représentative sur les nœuds principaux et dupliqués, 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 s'assurer que le client est correctement configuré pour éviter tout impact négatif sur votre application.
Maintenance planifiée
Memorystore for Redis Cluster 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. La maintenance sans temps d'arrêt est obtenue en utilisant les fonctionnalités de redirection des requêtes du protocole Redis avec les mécanismes Memorystore suivants :
- Basculement coordonné sans perte de données.
- Suppression progressive des nœuds pour permettre aux clients de rattraper les mises à jour de la topologie du cluster sans impact sur la disponibilité.
- Les points de terminaison Private Service Connect du cluster ne sont pas affectés par la maintenance. Pour en savoir plus sur ces points de terminaison, consultez la section Points de terminaison du cluster.
Le comportement du service décrit dans les sections suivantes s'applique uniquement à 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.
Stratégie de déploiement progressif
Les déploiements de maintenance de Memorystore for Redis Cluster sont effectués avec une portée de plus en plus large et à un rythme qui permet de détecter les défaillances suffisamment tôt pour atténuer l'impact et établir une confiance en la stabilité. Les temps de cuisson (période pendant laquelle 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 de la flotte de clusters Memorystore à l'échelle du service. De plus, les temps de cuisson sont intégrés au cluster dans les zones d'une région (plusieurs domaines de défaillance) afin de réduire la portée de l'impact, le cas échéant.
Pour votre cluster configuré pour la haute disponibilité, au maximum un domaine de défaillance/zone est mis à jour à un moment donné pour s'assurer qu'un fragment de cluster, y compris les instances principales et dupliquées, est à haute disponibilité tout au long de la mise à jour. De plus, seuls quelques nœuds Redis sont mis à jour à un moment donné. Les mises à jour utilisent un mécanisme de cycle de vie "créer avant de détruire" pour maximiser la stabilité du cluster. Cette stratégie offre le plus d'avantages lors de la mise à jour d'un cluster comportant de nombreux fragments. L'application des mises à jour à une petite partie de l'espace de clés utilisateur global à un moment donné maximise la disponibilité des données.
Stratégie de cycle de vie "créer avant de détruire"
Un cluster Redis comporte plusieurs fragments. Chaque fragment comporte un nœud principal et zéro ou plusieurs nœuds dupliqués. Memorystore utilise le processus suivant pour mettre à jour un nœud Redis principal ou dupliqué existant dans un fragment :
- Memorystore for Redis Cluster ajoute d'abord une instance dupliquée entièrement nouvelle 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 la capacité provisionnée est conservée en cas d'échec inattendu du bootstrap.
- Si un nœud du fragment à 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é.
- Ensuite, Memorystore supprime l'instance dupliquée qui utilise l'ancien logiciel.
- Le processus est répété pour chaque nœud du cluster.
La stratégie "créer avant de détruire" permet de conserver la capacité provisionnée du cluster, par rapport à un déploiement progressif typique qui met à jour sur place, mais qui entraîne une interruption de la disponibilité (et parfois une perte de données) pour l'application cliente. Pour les fragments sans instances dupliquées, Memorystore for Redis Cluster provisionne toujours d'abord une nouvelle instance dupliquée, coordonne le basculement et remplace enfin le nœud principal existant du fragment.
Étape 1 : Ajouter une instance dupliquée Redis
La première étape du mécanisme "créer avant de détruire" consiste à ajouter un nœud dupliqué avec le dernier logiciel à l'aide du mécanisme OSS Redis de synchronisation complète pour copier les données du nœud principal vers le nœud dupliqué. Pour ce faire, un processus enfant est dupliqué et la réplication sans disque est utilisée pour amorcer l'instance dupliquée. Memorystore for Redis Cluster est compatible avec la réplication sans disque. Sauf si vous activez la persistance, Memorystore for Redis Cluster n'utilise pas de disques lors de la réplication.
Vous pouvez tirer le meilleur parti de l'architecture de scaling horizontal du cluster en provisionnant un plus grand nombre de fragments pour 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 duplication d'une opération de synchronisation complète. Il accélère également la copie des données entre les nœuds.
Étape 2 : Basculement coordonné de l'instance principale
Si le nœud Redis à mettre à jour est un nœud principal, Memorystore exécute 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 Redis fonctionnent ensemble 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 l'instance principale.
- L'instance dupliquée termine le processus d'élection pour prendre le rôle principal.
- Le nœud principal précédent, désormais une instance dupliquée, débloque les requêtes existantes et les redirige vers la nouvelle instance principale à l'aide du protocole de cluster OSS Redis. Toutes les nouvelles requêtes envoyées au nœud dupliqué précédent continuent d'être redirigées vers le nouveau nœud principal.
- Votre client compatible avec Redis Cluster 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 quelques dizaines de millisecondes. Toutefois, la taille totale de votre cluster peut augmenter la latence de basculement. Il en va de même pour les données en cours de transfert en attente d'être vidées dans les instances dupliquées. La taille du cluster peut affecter la convergence entre les nœuds principaux, ce qui a une incidence sur la prise de décision lors de l'élection de la nouvelle instance principale.
Étape 3 : Supprimer l'instance dupliquée Redis
La dernière étape du mécanisme "créer avant de détruire" consiste à supprimer le nœud dupliqué sur l'ancien logiciel. Une suppression abrupte des nœuds aurait un impact sur les applications clientes, car les clients mettent en cache les informations sur les points de terminaison et la topologie du cluster. Memorystore for Redis Cluster a conçu la suppression d'une instance dupliquée Redis pour qu'elle soit progressive afin de permettre aux applications clientes d'actualiser leur topologie avant de subir un arrêt brutal des nœuds. La topologie est personnalisée pour permettre aux clients d'en savoir plus sur la nouvelle instance dupliquée. La topologie oublie également l'instance dupliquée qui sera supprimée avant sa suppression.
Le nœud dupliqué exécutant l'ancien logiciel est conservé pendant une certaine période de vidange, 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 fragment. Cela permet au client du cluster d'actualiser la topologie du cluster et d'en savoir plus sur les nouveaux points de terminaison de l'instance dupliquée. Si le client tente d'atteindre un nœud supprimé après la période de vidange, la tentative échoue, ce qui déclenche à son tour une actualisation de la topologie du cluster sur le client du cluster afin qu'il soit informé de la modification de l'instance dupliquée. Les nouvelles actualisations de la topologie du cluster ne voient pas le nœud dupliqué qui sera supprimé.
Paramètres de maintenance
Avec Memorystore, vous pouvez personnaliser les programmes de maintenance en fonction des besoins de votre application et minimiser les perturbations. Pour ce faire, configurez un intervalle de maintenance pour votre cluster.
Les intervalles de maintenance sont définis par cluster Memorystore et autorisent les options de configuration suivantes :
- Jour de la semaine : désigne le jour où la maintenance a lieu.
- Heure de début : heure à laquelle la maintenance commence.
La durée de l'intervalle de maintenance est d'une heure. Notez que, dans certains cas, la maintenance peut dépasser l'intervalle que vous avez sélectionné.
Une fois que vous avez configuré un intervalle de maintenance pour un cluster, Memorystore for Redis Cluster planifie automatiquement la maintenance à 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 mettra à jour votre cluster dans l'un des intervalles suivants en fonction du fuseau horaire de votre cluster :
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
Exemple de maintenance
En tant que développeur responsable d'un service de panier d'achat chez un détaillant, vous êtes chargé de superviser un environnement de production qui inclut un cluster. Pour garantir des performances optimales pendant la maintenance, vous prévoyez de la planifier lorsque le cluster connaît un trafic minimal, ce qui se produit généralement vers minuit le dimanche.
Dans ce cas, vous pouvez définir l'intervalle de maintenance de votre cluster de production sur :
- Jour de la semaine : dimanche.
- Heure de début : 1 h.
Notifications de maintenance à venir
Pour vous assurer de rester informé des événements de maintenance sur votre cluster, vous pouvez configurer des notifications par e-mail concernant la maintenance à venir au moins une semaine avant sa planification. Ces notifications auront pour objet "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".
Une notification est également envoyée lorsque la maintenance commence pour votre cluster. L'objet de l'e-mail sera le suivant : "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]".
Une fois la maintenance terminée, une notification de fin est envoyée. L'objet de l'e-mail est le suivant : "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]".
Si Memorystore reprogramme la maintenance, vous recevez un e-mail vous informant de l'annulation de la maintenance. L'objet de cet e-mail
sera le suivant : "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Vous devez activer ces notifications de maintenance. Pour vous abonner aux notifications de maintenance, procédez comme suit :
Pour recevoir des notifications de maintenance de Memorystore, assurez-vous d'avoir effectué ces étapes au moins une semaine avant la mise à jour de maintenance planifiée pour votre cluster. Si vous ne le faites pas, Memorystore for Redis Cluster n'aura pas suffisamment de temps pour vous informer de la maintenance à venir.
Memorystore for Redis Cluster 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). Pour le moment, nous ne prenons pas en charge l'envoi de notifications à une autre adresse e-mail.
En vous abonnant aux notifications de maintenance, vous recevez des alertes pour tous les clusters Memorystore dont la maintenance est planifiée dans un projet spécifié. Si vous êtes abonné, vous recevez une notification distincte pour chaque cluster.
Pour savoir comment trouver la maintenance planifiée, consultez la section Rechercher la maintenance planifiée.
Replanifier la maintenance
Dans le cas où des intervalles de maintenance sont configurés pour votre cluster, cette section fournit des instructions sur la façon de replanifier la maintenance. Par exemple, si un nouveau service doit être lancé pendant votre intervalle de maintenance actuel, vous pouvez reporter l'intervalle de maintenance de quelques jours après le lancement.
Vous pouvez replanifier la maintenance dans les 14 jours suivant l'heure initialement prévue. Lorsque vous replanifiez la maintenance, choisissez l'une des options suivantes :
- Mettre à jour maintenant : au lieu d'attendre l'intervalle de maintenance planifié, vous pouvez appliquer immédiatement les mises à jour à votre cluster.
- Jour et heure personnalisés : choisissez n'importe quelle heure dans les 14 jours suivant l' heure de maintenance initialement prévue.
Lorsque vous replanifiez la maintenance, les restrictions suivantes s'appliquent :
- S'il reste moins d'une heure avant l'heure de maintenance actuellement prévue, vous ne pouvez pas replanifier la maintenance.
- Une fois la replanification réussie, un e-mail est envoyé pour confirmer l'annulation de la maintenance précédente, et une nouvelle notification de maintenance à venir est envoyée avec le programme mis à jour.
Pour obtenir des instructions sur la replanification de la maintenance, consultez la section Replanifier la maintenance.
Questions fréquentes
Cette section contient des questions fréquentes sur la maintenance de Memorystore for Redis Cluster.
Comment savoir quand une opération de maintenance est planifiée pour votre cluster ?
Pour savoir quand une opération de maintenance est planifiée pour votre cluster, nous vous recommandons de vous abonner aux notifications et de configurer un intervalle de maintenance. Vous pouvez également
vérifier manuellement votre cluster pour voir si le
maintenanceSchedule paramètre apparaît dans la réponse.
Quand Memorystore for Redis Cluster vous informe-t-il de la maintenance à venir ?
Si vous vous abonnez aux notifications de maintenance et que vous définissez un intervalle de maintenance, Memorystore for Redis Cluster vous avertit par e-mail au moins une semaine avant un événement de maintenance.
Pendant combien de temps pouvez-vous reporter la maintenance ?
Une fois que vous avez planifié la maintenance de votre cluster, vous pouvez démarrer immédiatement la mise à jour de votre cluster ou la différer jusqu'à deux semaines à compter de la date et de l'heure de maintenance initialement prévues.
Par exemple, si vous planifiez une maintenance le 11 octobre à 23h15, vous pouvez la reporter jusqu'au 25 octobre à 23h15. Si vous ne faites rien, la maintenance s'exécute à la date et à l'heure prévues.
Pour en savoir plus, consultez la section Replanifier la maintenance.
Quelles bonnes pratiques permettent de mettre à jour la maintenance de manière fluide ?
Pour mettre à jour la maintenance de manière 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 cluster connaît un trafic minimal (par exemple, le dimanche à minuit).
- Activez les notifications de maintenance. Par conséquent, Memorystore for Redis Cluster vous avertit par e-mail au moins sept jours avant la planification d'une mise à jour de maintenance pour votre cluster.
- 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.
Quand vous recommandons-nous d'appliquer immédiatement une mise à jour de maintenance ?
Vous pouvez appliquer immédiatement une mise à jour de maintenance sur un cluster 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 sur vos clusters de production jusqu'à ce que vous résolviez les problèmes.
Si le jour et l'heure actuels conviennent à votre cluster et que vous prévoyez une charge élevée sur votre cluster à l'avenir, vous pouvez exécuter immédiatement la mise à jour de maintenance.
Les mises à jour de maintenance sont-elles toujours effectuées dans l'intervalle de maintenance ?
Memorystore for Redis Cluster démarre une mise à jour de maintenance dans l'intervalle de maintenance que vous spécifiez. Memorystore for Redis Cluster 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 la planifier sur certains clusters dans un premier temps ?
Vous ne pouvez pas désactiver la maintenance ni contrôler l'ordre de maintenance de vos clusters. Toutefois, une fois que vous avez reçu la notification de maintenance initiale, vous pouvez replanifier la maintenance pour la différer jusqu'à deux semaines.
Étape suivante
- Consultez les autorisations dont vous avez besoin pour gérer les intervalles de maintenance de votre cluster.