Cette page explique comment Memorystore pour Redis Cluster effectue la maintenance des clusters. 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 Redis Cluster. Ces recommandations s'appliquent aux clusters hautement disponibles et aux clusters sans instances répliquées. Toutefois, nous recommandons vivement la configuration à haute disponibilité pour tous les cas d'utilisation en production.
Memorystore pour 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 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 Redis pour améliorer les caractéristiques de sécurité, de performances et de fiabilité des clusters au-delà de ce que Redis fournit.
Memorystore pour Redis Cluster ne met pas automatiquement à jour les clusters pour chaque version de maintenance. Pour déterminer le meilleur moment pour planifier une maintenance complète, Google Cloud évalue régulièrement les mises à jour disponibles. Si vous avez besoin d'une version de maintenance spécifique plus tôt, vous pouvez utiliser la maintenance en libre-service après qu'une mise à jour est disponible. Pour en savoir plus sur les versions de maintenance, y compris les numéros et les détails des versions de maintenance, consultez les changelogs de maintenance de Memorystore pour Redis Cluster.
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 de cluster Redis OSS conformément aux instructions de la section Bonnes pratiques concernant les clients Redis pour vous assurer que les opérations de maintenance planifiées n'ont pas d'impact sur votre 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 le scaling horizontal ou vertical, ou 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 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 est configuré correctement afin d'é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 Points de terminaison de cluster.
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é.
Stratégie de déploiement progressif
Les déploiements de maintenance de Memorystore pour Redis Cluster sont effectués 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 l'impact et établir une stabilité fiable. 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 à l'ensemble du parc de clusters Memorystore à l'échelle du service. De plus, les temps de préparation sont intégrés au cluster dans les zones d'une région (plusieurs domaines d'erreur) afin de réduire l'impact, le cas échéant.
Pour votre cluster configuré pour la haute disponibilité, au maximum un domaine d'erreur/une zone est mis à jour à un moment donné pour s'assurer qu'un segment de cluster, 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, 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 segments. 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 "créer avant de détruire"
Un cluster Redis 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 Redis principal ou répliqué existant dans un segment :
- Memorystore pour Redis Cluster ajoute d'abord une instance répliquée entièrement nouvelle avec la dernière mise à jour logicielle au segment. Memorystore crée un nœud entièrement nouveau, 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 inattendu du démarrage.
- 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é.
- Ensuite, Memorystore supprime l'instance répliquée qui utilise l'ancienne version du logiciel.
- Le processus est répété pour chaque nœud du cluster.
La stratégie de création avant destruction permet de conserver la capacité provisionnée du cluster, 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 for Redis Cluster 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 Redis
La première étape du mécanisme de création avant destruction consiste à ajouter un nœud d'instance répliquée 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 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 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 pendant la réplication.
Vous pouvez tirer le meilleur parti de l'architecture de scaling horizontal du cluster en provisionnant un plus grand nombre de segments pour réduire la taille de l'espace de clés au sein d'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 : Basculement principal coordonné
Si le nœud Redis à mettre à jour est un nœud principal, Memorystore exécute d'abord un basculement coordonné vers le nœud d'instance répliquée nouvellement ajouté, puis procède à la suppression du nœud. Lors du basculement coordonné, le client et les nœuds Redis travaillent 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 entièrement synchronisée 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 une instance répliquée, débloque les requêtes existantes et les redirige vers le nœud principal nouvellement élu à l'aide du protocole de cluster Redis 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 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 prennent généralement quelques dizaines de millisecondes. Toutefois, la taille totale de votre cluster peut augmenter la latence de basculement. C'est également le cas des données en cours de transfert en attente d'être vidées vers 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 du nouveau nœud principal.
Étape 3 : Supprimez l'instance répliquée Redis
La dernière étape du mécanisme de création avant destruction consiste à supprimer le nœud d'instance répliquée de l'ancienne version du logiciel. Une suppression brutale de nœud 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 de manière progressive afin de 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. La topologie oublie également l'instance répliquée qui sera supprimée avant sa suppression.
Le nœud d'instance répliquée exécutant l'ancienne version du logiciel est conservé 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. Cela permet au client du cluster d'actualiser la topologie du cluster 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, ce qui déclenche une actualisation de la topologie du cluster sur le client du cluster afin qu'il soit informé de la modification de l'instance répliquée. Les nouvelles actualisations de la topologie du cluster ne voient pas le nœud d'instance répliquée qui sera supprimé.
Paramètres de maintenance
Avec Memorystore, vous pouvez personnaliser les planifications de maintenance pour les adapter aux 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 permettent les options de configuration suivantes :
- Jour de la semaine. Désigne le jour où la maintenance a lieu.
- Heure de début. Heure de début de la maintenance.
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 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 mettra à jour votre cluster dans l'un des intervalles de temps suivants, en fonction du fuseau horaire de votre cluster :
Période de la semaine (du lundi au vendredi) De 22h à 6h
Fenêtre du week-end Du vendredi, à 22h au lundi, à 6h
Exemple de maintenance
En tant que développeur responsable d'un service de panier d'achat pour un site marchand, vous devez superviser un environnement de production qui inclut un cluster. Pour garantir des performances optimales pendant la maintenance, vous souhaitez la planifier lorsque le cluster enregistre 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. 1h.
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 serait "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]".
Une fois la maintenance terminée, une notification de fin est envoyée. Le titre de l'e-mail est "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 serait "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Vous devez activer les notifications de maintenance pour les recevoir. Pour vous inscrire aux notifications de maintenance, procédez comme suit :
Pour recevoir les notifications de maintenance de Memorystore, assurez-vous d'avoir suivi ces étapes au moins une semaine avant la mise à jour de maintenance planifiée pour votre cluster. Si vous ne le faites pas, Memorystore pour Redis Cluster n'aura pas suffisamment de temps pour vous informer de la maintenance à venir.
Memorystore pour 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 pouvons pas envoyer 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 une maintenance planifiée, consultez Trouver une maintenance planifiée.
Replanifier la maintenance
Si 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 l'intervalle de maintenance actuel, vous pouvez reporter l'intervalle de maintenance à quelques jours après le lancement.
Vous pouvez reprogrammer la maintenance dans les 14 jours suivant l'heure initialement prévue. Dans le cadre de la reprogrammation de 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 cluster.
- Jour et heure personnalisés : choisissez n'importe quelle heure dans les 14 jours suivant l'heure de maintenance initialement planifiée.
Les restrictions suivantes s'appliquent lors de la reprogrammation de la maintenance :
- S'il reste moins d'une heure avant l'heure de maintenance actuellement planifiée, vous ne pouvez pas replanifier la maintenance.
- Une fois la reprogrammation 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 calendrier mis à jour.
Pour savoir comment reprogrammer une maintenance, consultez Reprogrammer une maintenance.
Questions fréquentes
Cette section contient les questions fréquentes sur la maintenance de Memorystore pour Redis Cluster.
Comment savoir quand une maintenance est programmée pour votre cluster ?
Pour savoir quand la 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 paramètre maintenanceSchedule apparaît dans la réponse.
Quand Memorystore for Redis Cluster 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 Redis Cluster vous en informe par e-mail au moins une semaine avant un événement de maintenance.
Combien de temps pouvez-vous reporter la maintenance ?
Après avoir planifié la maintenance de votre cluster, vous pouvez lancer la mise à jour immédiatement ou la reporter de deux semaines maximum par rapport à la date et à 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 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 cluster enregistre un trafic minimal (par exemple, le dimanche à minuit).
- Activer 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 en savoir plus, consultez Maintenance planifiée.
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 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 de 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 la mise à jour de maintenance immédiatement.
Les mises à jour de maintenance se terminent-elles toujours pendant 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 pendant l'intervalle, mais ce n'est pas toujours le cas.
Pouvez-vous désactiver la maintenance ou planifier la maintenance sur certains clusters en premier ?
Vous ne pouvez pas désactiver la maintenance ni contrôler l'ordre de maintenance de vos clusters. 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 cluster.