Cette page explique comment Memorystore pour Redis Cluster effectue la maintenance des instances. Il 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 aux clusters haute disponibilité et aux clusters sans réplicas. Toutefois, nous recommandons vivement la configuration à haute disponibilité pour tous les cas d'utilisation en production.
Memorystore Cluster pour Redis 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 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 instances au-delà de ce que fournit OSS Redis.
Configurer votre application cliente
Pour configurer votre application cliente afin d'optimiser ses performances et sa disponibilité pendant la maintenance, procédez comme suit :
- Utilisez et configurez votre client de cluster OSS Redis en suivant les conseils de la section Bonnes pratiques concernant les clients Redis pour vous assurer que toute maintenance planifiée n'a 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 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 la réduction ou l'augmentation de la capacité, les modifications du nombre de réplicas) tout en exécutant une charge de travail représentative sur les nœuds principaux et de réplica, 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 de cluster Redis OSS est correctement configuré pour éviter tout impact négatif sur votre application.
Maintenance planifiée
Memorystore for Redis Cluster utilise une stratégie de cycle de vie de déploiement progressif et de création avant destruction pour éviter tout impact sur le temps d'arrêt causé par la maintenance. La maintenance sans temps d'arrêt est possible grâce aux fonctionnalités de redirection des requêtes du protocole de cluster OSS Redis, combinées aux mécanismes Memorystore suivants :
- Basculement coordonné sans perte de données.
- Suppression concertée 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 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 Comportement du client lors d'un basculement imprévu.
Stratégie de déploiement progressif
Les déploiements de maintenance Memorystore pour Redis Cluster sont effectués avec une portée de plus en plus grande, à 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 (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 à l'ensemble du parc 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 l'étendue de l'impact, le cas échéant.
Pour votre cluster configuré pour la haute disponibilité, au maximum un domaine de défaillance/une zone est mis à jour à un moment donné pour s'assurer qu'un shard de cluster, y compris l'instance principale et les répliques, bénéficie 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 est la plus avantageuse lorsque vous mettez à jour un cluster comportant de nombreux shards. 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 "create-before-destroy"
Un cluster Redis comporte plusieurs partitions. Chaque partition comporte un nœud principal et zéro ou plusieurs nœuds répliqués. Memorystore utilise le processus suivant pour mettre à jour tout nœud Redis principal ou répliqué existant dans un shard :
- Memorystore for Redis Cluster ajoute d'abord un tout nouveau réplica avec la dernière mise à jour logicielle au shard. Memorystore crée un tout nouveau nœud au lieu de mettre à jour un nœud existant. Cela permet de s'assurer que la capacité provisionnée est conservée en cas d'échec inattendu de l'amorçage.
- Si un nœud du shard à mettre à jour est un nœud principal, il est d'abord converti en réplica avant d'être supprimé à l'aide d'un basculement coordonné.
- Ensuite, Memorystore supprime le réplica 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, contrairement à un déploiement continu classique qui effectue des mises à jour sur place, mais entraîne une indisponibilité (et parfois une perte de données) pour l'application cliente. Pour les partitions sans réplicas, Memorystore for Redis Cluster provisionne toujours d'abord un nouveau réplica, coordonne le basculement et remplace enfin le nœud principal existant de la partition.
Étape 1 : Ajouter un réplica Redis
La première étape du mécanisme de création avant destruction consiste à ajouter un nœud de réplique avec le logiciel le plus récent à l'aide du mécanisme Redis OSS de synchronisation complète pour copier les données du nœud principal vers le nœud de réplique. Pour ce faire, il crée un processus enfant et utilise la réplication sans disque pour amorcer la réplique.
Pour tirer le meilleur parti de l'architecture à scaling horizontal du cluster, provisionnez un nombre plus élevé de partitions afin de réduire la taille de l'espace de clés dans un nœud. Le fait d'avoir un ensemble de données plus petit par nœud permet de réduire l'impact de la latence de fork 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é du serveur principal
Si le nœud Redis à mettre à jour est un nœud principal, Memorystore exécute d'abord un basculement coordonné vers le nœud de réplica 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 la réplique existante est synchronisée à 100 % avec le nœud principal.
- L'instance répliquée termine le processus d'élection pour prendre le rôle principal.
- L'ancien nœud principal, qui est désormais une réplique, débloque les requêtes existantes et les redirige vers le nouveau nœud principal à l'aide du protocole de cluster OSS Redis. Toutes les nouvelles requêtes envoyées à l'ancien nœud de réplique 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 n'a plus besoin 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 du basculement. Il en va de même pour les données en cours de transfert qui doivent être vidées dans les répliques. 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 le réplica Redis
La dernière étape du mécanisme de création avant destruction consiste à supprimer le nœud de réplica sur l'ancien logiciel. La suppression abrupte d'un nœud aurait un impact sur les applications clientes, car elles 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'un réplica 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 le nouveau réplica. La topologie oublie également la réplique qui sera supprimée avant qu'elle ne le soit.
Le nœud de réplique exécutant l'ancienne version du logiciel est conservé pendant une certaine période de vidange, généralement de quelques minutes, au cours de laquelle il commence à rediriger les requêtes de lecture entrantes vers le nœud principal de son shard. Il permet au client du cluster Redis OSS d'actualiser la topologie du cluster et d'en savoir plus sur les nouveaux points de terminaison des répliques. Si le client tente d'accéder à un nœud supprimé après la période de vidange, la tentative échoue, ce qui déclenche une actualisation de la topologie du cluster sur le client du cluster afin qu'il prenne connaissance du changement de réplica. Les nouvelles actualisations de la topologie du cluster ne voient pas le nœud de réplique qui sera supprimé.
Paramètres de maintenance
Memorystore vous permet de personnaliser les plannings de maintenance pour les adapter aux 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 permettent les options de configuration suivantes :
- Jour de la semaine. Indique 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 qu'un intervalle de maintenance est configuré pour une instance de cluster, les futures opérations de maintenance automatiques sont planifiées en fonction des préférences 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 22h à 6h
Période 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 chez un marchand, vous devez superviser un environnement de production qui inclut une instance de cluster Memorystore pour Redis. Pour garantir des performances optimales pendant la maintenance, vous devez la planifier lorsque le trafic du cluster est 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. le dimanche.
- Heure de début. 1h du matin.
Notifications de maintenance à venir
Pour être 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 de votre cluster commence. L'objet de l'e-mail sera "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 "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]".
Si Memorystore reprogramme une 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 ces notifications de maintenance pour les recevoir. Pour vous abonner 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. Si vous ne le faites pas, le système n'aura pas assez 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 pouvons pas envoyer de 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 recevez une notification distincte pour chaque cluster.
Pour savoir comment trouver la maintenance planifiée, consultez Trouver la maintenance planifiée.
Replanifier la maintenance
Si des intervalles de maintenance sont configurés pour votre cluster, cette section fournit des consignes sur la façon de reprogrammer la maintenance. Par exemple, si un nouveau service doit être lancé pendant votre intervalle de maintenance actuel, vous pouvez le reporter à quelques jours après le lancement.
Vous pouvez reprogrammer la maintenance autant de fois que vous le souhaitez dans les deux semaines suivant l'heure initialement prévue. Vous pouvez choisir l'une des options suivantes lorsque vous reprogrammez un rendez-vous :
- Mettre à jour Au lieu d'attendre l'intervalle de maintenance programmé, vous pouvez appliquer immédiatement les mises à jour à votre cluster.
- Jour et heure personnalisés : Cette option vous permet de choisir une heure précise dans les deux semaines suivant l'heure de maintenance initialement programmée.
Les restrictions suivantes s'appliquent lorsque vous reprogrammez une maintenance :
- S'il reste moins d'une heure avant l'heure de maintenance actuellement prévue, vous ne pouvez pas la reprogrammer.
- Si la reprogrammation réussit, un e-mail est envoyé pour confirmer l'annulation de la maintenance précédente. Une nouvelle notification de maintenance à venir est envoyée avec le calendrier mis à jour.
Pour obtenir des instructions sur la reprogrammation de la maintenance, consultez Reprogrammer une maintenance.
Questions fréquentes
Voici quelques questions fréquentes à propos de la règle de maintenance de Memorystore pour Redis Cluster :
Comment savoir quand une opération de maintenance est planifiée pour mon cluster ?
Nous vous recommandons de vous abonner aux notifications et de configurer un intervalle de maintenance pour savoir quand une opération de maintenance est planifiée sur votre instance. Vous pouvez également effectuer une vérification manuelle à l'aide de la méthode Find Scheduled Maintenance pour voir si le champ maintenance_schedule est défini dans la réponse.
Quand serai-je informé des prochaines opérations de maintenance ?
Si vous êtes abonné aux notifications de maintenance et que vous avez défini un intervalle de maintenance, vous êtes averti par e-mail au moins une semaine avant un événement de maintenance.
Pendant combien de temps puis-je reporter la maintenance ?
Une fois la maintenance planifiée sur votre cluster, vous pouvez démarrer la mise à jour immédiatement ou la différer de deux semaines au maximum par rapport à l'heure de maintenance initialement planifiée. Par exemple, si la maintenance est programmée le 11 octobre à 23h15, vous pouvez la reporter jusqu'au 25 octobre à 23h15. Les opérations de maintenance seront appliquées à l'heure planifiée si aucune mesure n'est prise.
Pour en savoir plus, consultez la section Replanifier la maintenance.
Quelles bonnes pratiques dois-je suivre pour mettre à jour la maintenance planifiée de manière fluide ?
Nous vous recommandons d'effectuer les actions suivantes pour mettre à jour la maintenance de manière fluide :
- Suivez les instructions pour configurer votre application cliente.
- Vous devez définir votre intervalle de maintenance sur une heure qui garantit que la maintenance n'est pas appliquée aux heures de pointe d'utilisation de Redis.
- Vous devez activer les notifications de maintenance pour être averti par e-mail au moins sept jours avant la planification de la mise à jour de la maintenance de votre instance.
- Si vous n'avez pas d'heure à faible impact ou sans impact pour l'utilisation de votre application, nous vous recommandons d'utiliser la valeur par défaut du service pour les déploiements progressifs, qui intègre les bonnes pratiques. Pour en savoir plus, consultez Maintenance transparente.
Quand dois-je appliquer la maintenance immédiatement ?
Vous pouvez appliquer immédiatement une mise à jour de maintenance sur un cluster de test pour voir son impact sur votre application. Cela vous permet d'observer l'impact de celle-ci et de différer la maintenance sur les clusters de production si nécessaire ou autorisé.
Vous pouvez également planifier immédiatement la maintenance si l'heure actuelle convient à votre cluster et si vous prévoyez une charge élevée sur votre cluster à l'avenir.
Les mises à jour de maintenance sont-elles toujours effectuées dans l'intervalle de maintenance ?
Une mise à jour commence dans l'intervalle de maintenance que vous spécifiez. La mise à jour s'effectue généralement dans l'intervalle, mais cela n'est pas garanti.
Puis-je désactiver la maintenance ou la planifier sur certains clusters dans un premier temps ?
Non, 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.
Étapes suivantes
- Consultez les autorisations requises pour gérer les intervalles de maintenance de votre cluster Redis.