Cette page explique comment Memorystore pour Redis Cluster effectue la maintenance sur les instances. 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 pour Redis Cluster. Ces recommandations s'appliquent à la fois aux clusters à haute disponibilité et aux clusters sans instances répliquées. Toutefois, nous vous recommandons vivement la configuration à haute disponibilité pour tous les cas d'utilisation en production.
Memorystore pour Redis Cluster 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 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 deux 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 la base de données : la maintenance peut inclure une mise à jour Redis pour améliorer la sécurité, les performances et la fiabilité de l'instance au-delà de ce que fournit OSS Redis.
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 consignes des 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 l'effectuer un scaling vertical ou horizontal, les modifications du nombre d'instances répliquées) tout en exécutant une charge de travail représentative sur les nœuds principaux et répliqué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 capacité de suppression des nœuds existants. Les tests permettent de s'assurer que le client de cluster OSS Redis est correctement configuré pour éviter tout impact négatif sur votre application.
Maintenance planifiée
Memorystore pour 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 de cluster OSS Redis conjointement 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 pour 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 du parc de clusters Memorystore à l'échelle du service. De plus, les temps de cuisson sont intégrés au sein du 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 répliquées, est hautement disponible 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 est la plus avantageuse 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 répliqués. Memorystore utilise le processus suivant pour mettre à jour un nœud Redis principal ou répliqué existant dans un fragment :
- Memorystore pour Redis Cluster ajoute d'abord une instance répliqué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, afin de 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 répliquée avant d'être supprimé à l'aide d'un basculement coordonné.
- Ensuite, Memorystore supprime l'instance répliqué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 entraîne une interruption de la disponibilité (et parfois une perte de données) pour l'application cliente. Pour les fragments sans instances répliquées, Memorystore pour Redis Cluster provisionne toujours d'abord une nouvelle instance répliquée, coordonne le basculement et remplace enfin le nœud principal existant du fragment.
Étape 1 : Ajouter une instance répliquée Redis
La première étape du mécanisme "créer avant de détruire" consiste à ajouter un nœud répliqué 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 répliqué. 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 Redis Cluster est compatible avec la réplication sans disque. Sauf si vous activez la persistance, Memorystore pour 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 répliqué 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 répliquée existante est synchronisée à 100% avec l'instance principale.
- L'instance répliquée termine le processus d'élection pour prendre 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 la nouvelle instance principale élue à l'aide du protocole de cluster OSS Redis. Toutes les nouvelles requêtes envoyées au nœud répliqué 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 doivent 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 qui doivent être vidées dans les instances répliqué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 concernant l'élection de la nouvelle instance principale.
Étape 3 : Supprimer l'instance répliquée Redis
La dernière étape du mécanisme "créer avant de détruire" consiste à supprimer le nœud répliqué 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 pour Redis Cluster a conçu la suppression d'une instance répliqué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 de découvrir la nouvelle instance répliquée. La topologie oublie également l'instance répliquée qui sera supprimée avant sa suppression.
Le nœud répliqué 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. Il permet au client de cluster OSS Redis d'actualiser la topologie du cluster et de découvrir les nouveaux points de terminaison répliqués. 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 de cluster afin qu'il soit informé du changement d'instance répliquée. Les nouvelles actualisations de la topologie du cluster ne voient pas le nœud répliqué 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 interruptions. 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 est effectuée.
- 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 pour 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 met à 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 gérant un service de panier d'achat chez un détaillant, vous êtes responsable de la supervision d'un environnement de production qui inclut une instance Memorystore pour Redis 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 AM
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 inscrire aux notifications de maintenance, procédez comme suit :
Pour recevoir des notifications de maintenance de Memorystore, assurez-vous d'avoir effectué les étapes ci-dessus au moins une semaine avant la mise à jour de maintenance planifiée pour votre instance. Dans le cas contraire, le système n'aura pas suffisamment de temps pour vous informer de la maintenance à venir.
Les notifications seront envoyées à l'adresse e-mail associée à votre compte Google. Il n'est pas possible de configurer un alias d'adresse e-mail personnalisé (par exemple, un alias d'adresse e-mail d'équipe). Pour le moment, nous ne sommes pas en mesure d'envoyer des notifications à une autre adresse e-mail.
En vous abonnant aux notifications de maintenance, vous recevrez des alertes pour tous les clusters Memorystore dont la maintenance est planifiée dans un projet spécifié. Si vous êtes abonné, vous recevrez 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 :
- Si la maintenance actuellement planifiée doit avoir lieu dans moins d'une heure, vous ne pouvez pas la replanifier.
- Une fois la replanification effectuée, 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 pour Redis Cluster.
Comment savoir quand une opération de maintenance est planifiée sur votre cluster ?
Pour savoir quand une opération de maintenance est planifiée sur 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 pour 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 pour 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 de deux semaines au maximum par rapport à la date et à 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 pour 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 comment la mise à jour affecte 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 pour Redis Cluster démarre une mise à jour de maintenance dans l'intervalle de maintenance que vous spécifiez. Memorystore pour 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 de deux semaines au maximum.
Étape suivante
- Consultez les autorisations dont vous avez besoin pour gérer les intervalles de maintenance de votre cluster.