Page d'aide sur la maintenance gérée et les mises à jour de service d'Amazon ElastiCache

Q : Que sont les mises à jour de service dans Amazon ElastiCache ?

Les mises à jour de service sont une fonctionnalité d'Amazon ElastiCache qui vous permet d'appliquer certaines mises à jour de service à votre discrétion. Les types de mises à jour sont les suivants : correctifs de sécurité ou mises à jour logicielles mineures. Ces mises à jour renforcent la sécurité et la fiabilité tout en améliorant les performances opérationnelles de vos clusters.

Ces mises à jour de service vous offrent la possibilité de contrôler le moment d'exécution d'une mise à jour (par exemple, vous pouvez retarder l'application des mises à jour de service lorsqu'un événement opérationnel important nécessite une disponibilité 24 h/24 et 7 j/7 des clusters ElastiCache).

Pour plus de détails sur chaque mise à jour de service, consultez la valeur de l'attribut « Description de la mise à jour ». 

Q : Comment suis-je informé qu'une mise à jour de service ElastiCache est disponible ?

Lorsque les mises à jour de service applicables à vos clusters Memcached ou Redis deviennent disponibles, nous vous en informons via plusieurs canaux, notamment la console Amazon ElastiCache, par e-mail et via Amazon Simple Notification Service (SNS), AWS Personal Health Dashboard et Amazon CloudWatch Events.

Q : Quelles sont les différences entre les mises à jour appliquées dans le créneau de maintenance et les mises à jour de service ?

Les mises à jour disponibles par le biais de notre maintenance gérée continue sont distinctes de celles proposées par les mises à jour de service. Les mises à jour appliquées au moyen de la maintenance gérée continue sont directement programmées dans vos créneaux de maintenance, sans intervention de votre part. Les mises à jour de service sont planifiées et vous permettent de contrôler le moment auquel vous souhaitez les appliquer avec l'attribut « Recommended Apply By Date (Date limite d'application recommandée) ». Si elles ne sont pas encore appliquées au moment voulu, ElastiCache peut planifier ces mises à jour dans votre créneau de maintenance.

Q : Comment puis-je déterminer si je dois appliquer la mise à jour de service disponible ?

Si votre cluster Redis ElastiCache est géré dans le cadre d'un programme de conformité HIPAA, PCI ou FedRAMP, vous devez appliquer les mises à jour de service selon l'attribut « Recommended Apply By Date (Date limite d'application recommandée) ». Pour obtenir plus d'informations, consultez la section Mises à jour de sécurité en libre-service pour la conformité.

Pour les autres clusters, nous vous recommandons d'appliquer les mises à jour de service selon votre cadence opérationnelle. Même si vous ne parvenez pas à appliquer une mise à jour de service avant la date mentionnée par l'attribut « Recommended Apply By Date (Date limite d'application recommandée) », vous pouvez le faire jusqu'à la date indiquée par l'attribut «Update Expiration Date (Date d'expiration de la mise à jour) ». Toutefois, la date d'expiration peut changer à tout moment en fonction de la disponibilité des nouvelles mises à jour.

Q : Quel est l'impact de l'application d'une mise à jour de service aux clusters ElastiCache pour Redis ? Vais-je perdre des données ou la connectivité à mes clusters ?

Lorsque vous ou Amazon ElastiCache appliquez une mise à jour de service à un ou plusieurs clusters Redis, la mise à jour s'applique à un seul nœud à la fois dans chaque partition jusqu'à ce que tous les clusters sélectionnés soient mis à jour. Les nœuds en cours de mise à jour enregistrent quelques secondes de temps d'arrêt tandis que le reste des clusters Redis continuent d'acheminer le trafic.

• Aucune modification n'est apportée à la configuration du cluster.
• Vous constaterez néanmoins un retard dans vos métriques CloudWatch, mais celui-ci sera rattrapé dès que possible.

Les mises à jour de service s'appliquent de la même façon que les « Mises à jour de maintenance gérée continue », tout au long du processus de remplacement des nœuds. Veuillez consulter les questions suivantes de la section Mises à jour de maintenance gérée continue de cette page pour en savoir plus sur l'application de la mise à jour et sur la préparation de votre application en vue de minimiser l'impact.

• Q : Quel impact a un remplacement de nœud sur mon application ?
  
• Quelles bonnes pratiques dois-je suivre pour assurer le bon déroulement du remplacement et limiter la perte de données ?
• Quelles bonnes pratiques de configuration client dois-je suivre pour minimiser l'interruption de l'application pendant la maintenance ?
  

Q : Y a-t-il un temps d'arrêt associé à l'application de la mise à jour à ElastiCache pour les clusters Memcached ?

Oui, le nœud est remplacé par un nouveau nœud vide. Le contenu du cache disparaît et tout est réinitialisé.

Q : Puis-je désactiver les mises à jour de service ?

Vous pouvez déterminer si vous pouvez refuser une mise à jour de service en vérifiant la valeur de l'attribut « Auto-Update after Due Date (Mise à jour automatique après la date prévue) ». Si la valeur de l'attribut « Auto-Update after Due Date (Mise à jour automatique après la date d'échéance) » d'une mise à jour de service est « non », cette mise à jour de service peut être désactivée. Toutefois, si la valeur de l'attribut « Auto-Update after Due Date (Mise à jour automatique après la date prévue) » d'une mise à jour de service est « oui » et que la date mentionnée par l'attribut « Recommended Apply By Date (Date limite d'application recommandée) » est passée, ElastiCache planifie automatiquement la mise à jour de service pour tous les clusters restants pendant le prochain créneau de maintenance. Cette mise à jour automatique du service sera planifiée avant la « date d'expiration de la mise à jour » et vous recevrez une notification une semaine avant la mise à jour avec l'heure prévue. Nous vous recommandons vivement d'appliquer les mises à jour de sécurité, même si vous pouvez les désactiver.  Si vous choisissez d'appliquer la mise à jour de service aux clusters restants avant le créneau de maintenance, ElastiCache ne réapplique pas la mise à jour de service pendant le créneau de maintenance.

Q : Pourquoi les mises à jour de service ne peuvent-elles pas être directement appliquées par ElastiCache au cours des créneaux de maintenance ?

Les mises à jour de service vous permettent de choisir le moment de leur application. Dans le cas des clusters qui ne sont pas gérés en fonction de programmes de conformité pris en charge par ElastiCache, il est possible de ne pas appliquer ces mises à jour ou de les appliquer selon une fréquence réduite au fil de l'année. Pour cela, la valeur de l'attribut « Auto-Update after Due Date (Mise à jour automatique après la date prévue) » d'une mise à jour de service doit être « non ». Pour obtenir plus d'informations, consultez la rubrique « Puis-je désactiver les mises à jour de service ? ».

Q : Puis-je utiliser les mises à jour de service pour désactiver la maintenance de service d’Amazon ElastiCache et appliquer les mises à jour disponibles moi-même ?

Non, les mises à jour de service ne sont pas compatibles avec les mises à jour de maintenance gérée continue appliquées directement par Amazon ElastiCache pendant les créneaux de maintenance de vos clusters.

Q : Où se trouve la liste de tous les attributs de mise à jour de service ?

Une liste complète des attributs et leurs descriptions est disponible dans la section Application des mises à jour en libre-service.

Q : Toutes les mises à jour de service appliquent-elles la même chronologie ?

Pour vous aider à déterminer le moment d'application des mises à jour de service disponibles, vous pouvez vous reporter à l'attribut de mise à jour de service « Severity (Gravité) » qui comporte les valeurs suivantes (par ordre de priorité) :

1. critical (critique) : application immédiate recommandée (sous 14 jours ou moins)
2. important : application recommandée dès que votre flux opérationnel le permet (sous 30 jours ou moins)
3. medium (moyen) : application recommandée sous 60 jours ou moins
4. low (faible) : application recommandée sous 90 jours ou moins

Pour obtenir plus de détails, reportez-vous à la section publique Application des mises à jour.

Q : Selon quelle fréquence les mises à jour de service sont-elles publiées ?

Le calendrier des versions dépend de l'importance des mises à jour de service.

Q : En quoi consiste l'attribut « Service Update SLA Met (SLA de mise à jour du service respecté) » ?

Cet attribut indique si votre cluster a été mis à jour avant la date mentionnée par l'attribut « Recommended Apply By Date (Date limite d'application recommandée) ». Si une mise à jour de service est appliquée après la date indiquée par l'attribut « Recommended Apply By Date (Date limite d'application recommandée) », l'attribut « Service Update SLA Met (SLA de mise à jour du service respecté) » est associé à la valeur « non ».

Ces informations sont pertinentes pour les clusters Amazon ElastiCache Redis gérés selon les programmes de conformité HIPAA, PCI et FedRAMP. Pour obtenir plus d'informations, consultez la section Mises à jour de sécurité en libre-service pour la conformité.

Q : Si je laisse passer une ou plusieurs mises à jour de service, pourrai-je les appliquer plus tard ?

Oui. Sauf indication contraire par l'attribut « Description » de la mise à jour du service, les mises à jour de service sont toujours cumulatives : si vous ne les appliquez pas avant la date mentionnée par l'attribut « Update Expiration Date (Date d'expiration de la mise à jour) », elles seront incluses lors de la prochaine mise à jour de service. Les mises à jour de service de type « sécurité » entrent dans cette catégorie cumulative.

Q : Puis-je choisir d'appliquer une mise à jour de service à des nœuds particuliers dans un cluster ElastiCache ?

Non, les mises à jour de service sont appliquées au niveau du cluster. Si vous annulez une mise à jour en cours d'exécution, certains nœuds d'un cluster peuvent être mis à jour et d'autres non. Dans ce cas, le cluster continue à apparaître dans la liste des clusters auxquels appliquer la mise à jour de service. Le cluster continue de fonctionner normalement.

Q : Pourquoi l'état de mise à jour d'un ou plusieurs nœuds de mes clusters ElastiCache est-il passé de « non appliqué » à « terminé » même si je n'ai pas appliqué la mise à jour de service ?

Il existe deux cas où cela peut se produire :

(a) Si vous avez laissé passer une mise à jour de service facultative et que l'état de la mise à jour est désormais « expiré ». Par conséquent, les clusters gérés dans le cadre de programmes de conformité doivent toujours appliquer toutes les mises à jour de service.
(b) Si vos nœuds sont remplacés pour toute autre raison, comme un événement de maintenance planifié ou un basculement de nœud, Amazon ElastiCache fournit de nouveaux nœuds avec les dernières mises à jour de service incluses.

Dans les deux cas, le cluster continue de fonctionner normalement.

Q : Que faire si des nœuds auxquels je veux appliquer des mises à jour de service ont expiré ? Dois-je attendre la prochaine mise à jour de service ?

Les nouveaux nœuds contiennent toutes les mises à jour de service applicables, vous pouvez donc remplacer manuellement les nœuds existants qui n'ont pas été mis à jour pour obtenir les mises à jour les plus récentes.

Q : Les mises à jour de service sont-elles spécifiques au moteur ?

Oui. Une mise à jour de service peut être applicable uniquement à Redis, uniquement à Memcached ou à Redis et Memcached. Vous pouvez rechercher les attributs de mise à jour de service « Moteur » et « Version du moteur » pour déterminer la portée de chaque mise à jour.

Q : Puis-je modifier la fenêtre de mise à jour de service planifiée ? Qu'advient-il à ma mise à jour planifiée si je modifie la fenêtre de maintenance ?

Oui, vous pouvez différer la mise à jour de service en modifiant la fenêtre de maintenance. La mise à jour planifiée s'applique au cluster uniquement si la date planifiée correspond à la fenêtre de maintenance du cluster. Une fois que vous modifiez la fenêtre de maintenance et que la date planifiée est dépassée, la mise à jour de service est à nouveau programmée sur la fenêtre nouvellement spécifiée dans les semaines suivantes. Vous recevrez une novelle notification une semaine avant la nouvelle date.

Chez AWS, la sécurité est une responsabilité partagée. Nous vous recommandons fortement d'appliquer la mise à jour au plus tôt.

Q : Pourquoi ai-je reçu des notifications pour plusieurs mises à jour concernant le même cluster ? Dois-je toutes les appliquer ?

Votre cluster peut faire partie de différentes mises à jour de service. La plupart des mises à jour ne nécessitent pas que vous les appliquiez séparément. L'application d'une mise à jour à votre cluster marque les autres mises à jour comme terminées, le cas échéant. Vous pouvez souhaiter appliquer séparément plusieurs mises à jour au même cluster si le statut ne change pas automatiquement pour « Terminé ».

Q : Comment s'effectue la planification et l'application des mises jour après la « Date limite d'application recommandée » ?

ElastiCache planifie la mise à jour de service sur le reste des clusters après la « Date limite d'application recommandée » si la valeur de l'attribut « Mise à jour automatique après la date limite » est « Oui ». La mise à jour sera à nouveau planifiée dans la fenêtre de maintenance du cluster. Vous recevrez une nouvelle notification avec une semaine d'avance avec la date programmée avant que les mises à jour soient appliquées.

La mise à jour de service planifiée s'applique aux clusters de la même manière que les « Mises de jour de maintenance gérée continue ». Consultez la section suivante pour plus d'informations sur l'application de la mise à jour, la modification de la mise à jour planifiée et la préparation de votre application pour une mise à jour planifiée visant à atténuer l'impact.

Q : Qu'advient-il si la mise à jour de service ne peut pas être appliquée à l'ensemble du cluster au cours d'une seule fenêtre de maintenance ?

Pour maintenir la stabilité du cluster, ElastiCache applique les mises à jour uniquement à un nœud à la fois dans chaque partition. Si la mise à jour de service ne peut pas être appliquée à l'ensemble du cluster pendant une seule fenêtre de maintenance, sa poursuite sera programmée au cours des fenêtres suivantes. Vous recevrez de nouvelles notifications concernant la prochaine date planifiée afin de vous préparer en conséquence.

Q : Puis-je restaurer la mise à jour de service ?

Le client ne peut pas restaurer la mise à jour de service une fois qu'elle a démarré. En cas de problème après l'application d'une mise à jour de service, veuillez contacter l'équipe AWS Support.

Q : En quoi consiste les mises à jour de maintenance gérée continue ?

Ces mises à jour sont obligatoires et directement appliquées dans vos créneaux de maintenance, sans intervention de votre part. Ces mises à jour sont distinctes de celles proposées par les mises à jour de service.

Q : Combien de temps prend un remplacement de nœud ?

Un remplacement ne nécessite généralement que quelques secondes. L'opération peut prendre plus de temps selon les configurations des instances et les modèles de trafic. Par exemple, un nœud principal Redis peut manquer de mémoire et avoir un trafic en écriture important. Lorsqu'un réplica vide se synchronise à partir d'un nœud principal, ce dernier peut manquer de mémoire pour réaliser à la fois les opérations d'écriture et la synchronisation du réplica. Le cas échéant, le nœud principal déconnecte le réplica et redémarre le processus de synchronisation. La synchronisation d'un réplica peut nécessiter plusieurs essais. Il est également possible que la synchronisation ne puisse pas se produire si le trafic en écriture reste élevé.

Les nœuds Memcached n'ont pas besoin d'être synchronisés, de sorte que leur remplacement s'effectue plus rapidement, quelle que soit la taille des nœuds.

Q : Quel impact a un remplacement de nœud sur mon application ?

Pour les nœuds Redis, le processus de remplacement met tout en œuvre pour conserver vos données existantes et nécessite, pour ce faire, l'option de réplication Redis. Pour les clusters Redis à nœud unique, ElastiCache déploie dynamiquement un réplica, réplique les données, puis bascule vers ces dernières. Pour les groupes de réplication comprenant plusieurs nœuds, ElastiCache remplace les réplicas existants et synchronise les données du réplica principal vers les nouveaux réplicas. Si la fonction Multi-AZ avec basculement automatique est activée, le remplacement du nœud principal déclenche un basculement vers un réplica en lecture. Pour les configurations de clusters Redis pouvant utiliser les clients Redis Cluster et les configurations non-Redis avec basculement automatique activé, les remplacements planifiés de nœuds se font pendant que les clusters servent des requêtes d’écriture entrantes. Si la fonction Multi-AZ est désactivée, ElastiCache remplace le réplica principal, puis synchronise les données depuis un réplica en lecture. Le nœud principal est indisponible sur cette période, ce qui provoque une interruption en écriture plus longue.

Pour les nœuds Memcached, le processus de remplacement met en place un nouveau nœud vide et met fin au nœud actuel. Le nouveau nœud sera indisponible pendant une courte période lors de la transition. Une fois la transition terminée, les performances de votre application peuvent se dégrader lorsque le nouveau nœud vide est complété avec les données mises en cache.

Q : Quelles bonnes pratiques dois-je suivre pour assurer le bon déroulement du remplacement et limiter la perte de données ?

Pour les nœuds Redis, le processus de remplacement met tout en œuvre pour conserver vos données existantes et nécessite, pour ce faire, l'option de réplication Redis. Nous essayons de remplacer progressivement les nœuds d'un même cluster afin d'en assurer la stabilité. Vous pouvez mettre en service les réplicas principal et en lecture dans différentes zones de disponibilité. Dans ce cas, lorsqu'un nœud est remplacé, les données sont synchronisées depuis un nœud pair d'une autre zone de disponibilité. Nous vous recommandons également de mettre à niveau la version de votre moteur Redis vers la version 5.0.6 ou plus, car ces versions ont une plus grande stabilité et permettent que vos serveurs puissent continuer de servir les requêtes en écriture lors d'activités d'application de correctifs, et ce lorsque le basculement automatique est activé pour ces serveurs. Pour finir, si votre configuration inclut uniquement un réplica primaire et un seul réplica par partition, nous vous recommandons d'ajouter des réplicas supplémentaires avant l'application de correctifs. Cela permet de prévenir la baisse de la disponibilité et d'autres risques pendant l'application de correctifs. Avec les clusters Redis à nœud unique, nous vous recommandons d'avoir une quantité de mémoire suffisante pour Redis, comme indiqué ici. Pour les groupes de réplication Redis à plusieurs nœuds, nous vous recommandons également de planifier le remplacement à une période où le trafic entrant en écriture est faible.

Pour les nœuds Memcached, planifiez la maintenance à une période où le trafic entrant en écriture est faible. Testez le basculement de votre application et utilisez le client « intelligent » d'ElastiCache fourni. La perte des données est inévitable, car Memcached stocke les données essentiellement en mémoire.

Q : Quelles bonnes pratiques de configuration client dois-je suivre pour minimiser l’interruption de l’application pendant la maintenance ?

Pour Redis, le mode de configuration Cluster dispose de la meilleure disponibilité pendant les opérations planifiées ou non. Il est toujours recommandé d’utiliser un client prenant en charge le mode Cluster qui se connecte au point de terminaison de découverte de clusters. Pour le mode Cluster désactivé, il est recommandé de toujours utiliser le point de terminaison recommandé pour toutes les opérations d’écriture. Les points de terminaison individuels de nœud des nœuds de réplica peuvent être utilisés pour toutes les opérations de lecture. Si le basculement automatique est activé dans le cluster, le nœud principal peut changer. L'application doit alors confirmer le rôle du nœud et mettre tous les points de terminaison de lecture à jour afin que vous ne provoquiez pas de charge majeure sur le nœud principal. Si le basculement automatique est désactivé, le rôle du nœud ne change pas. Toutefois, le temps d'arrêt des opérations planifiées ou non est plus important par rapport aux clusters pour lesquels le basculement automatique est activé. Évitez de rediriger les requêtes de lecture vers des réplicas en lecture seule. Si vous configurez votre client pour qu'il redirige les requêtes de lecture vers des réplicas en lecture seule, veillez à disposer de deux réplicas en lecture afin d'éviter toute interruption de lecture pendant la maintenance.

Q : Comment puis-je gérer seul les remplacements de nœuds ?

Nous vous recommandons d'autoriser ElastiCache à gérer les remplacements de nœuds pour vous pendant le créneau de maintenance planifié. Vous pouvez choisir un créneau dans la fenêtre de maintenance hebdomadaire lorsque vous créez un cluster ElastiCache. Pour déplacer votre créneau de maintenance au moment qui vous convient le mieux, vous pouvez utiliser l'API ModifyCacheCluster ou cliquer sur « Modify » dans ElastiCache Management Console.

Si vous choisissez de gérer le remplacement vous-même, vous pouvez effectuer diverses actions selon votre configuration de cluster et votre cas d'utilisation :

• Modifier le créneau de maintenance.
• Relancer votre instance Redis à l'aide du processus Sauvegarde et restauration.
• Si l'option « Mode cluster désactivé » est configurée pour votre cluster Redis :

o Remplacer un réplica en lecture (mode cluster désactivé) – procédure qui permet de remplacer manuellement un réplica en lecture dans un groupe de réplication Redis.
o Remplacer le nœud primaire (mode cluster désactivé) – procédure qui permet de remplacer manuellement le nœud primaire dans un groupe de réplication Redis.
o Remplacer un nœud autonome (mode cluster désactivé) – deux procédures différentes qui permettent de remplacer un nœud Redis autonome.

• Si l'option « Mode cluster activé » est configurée pour votre cluster Redis :

o Remplacer un nœud dans un cluster avec une ou plusieurs partitions – vous pouvez soit utiliser la fonction de sauvegarde et restauration, soit procéder à une montée en puissance suivie d'une mise à l'échelle horizontale pour remplacer les nœuds.

Pour obtenir plus d'informations sur toutes ces options, consultez la page Mesures que vous pouvez prendre lorsque le remplacement d'un nœud est planifié.

Avec Memcached, il suffit de supprimer et de recréer les clusters. Après le remplacement, votre instance ne doit plus être associée à un événement planifié.

Q : Comment être informé des prochains remplacements planifiés ?

Pour recevoir des notifications, vous pouvez configurer des notifications Amazon SNS pour les événements importants tels que les remplacements planifiés. Vous pouvez faire cela via la console ElastiCache Management, sous la section Events (Événements), ou en utilisant l'API describe-events pour déterminer l'événement ElastiCache:NodeReplacementScheduled à venir.

Pour configurer les notifications SNS, utilisez les informations disponibles ici.

Q : Est-il possible de modifier la fenêtre de maintenance planifiée ?

Oui, vous pouvez modifier la fenêtre de maintenance de votre cluster. Pour modifier votre fenêtre de maintenance au moment qui vous convient le mieux, vous pouvez utiliser l'API (ModifyCacheCluster ou ModifyReplicationGroup) ou cliquer sur « Modify » dans ElastiCache Management Console.

Une fois votre fenêtre de maitnenance modifiée, le service ElastiCache planifiera la maintenance de votre nœud pendant la nouvelle fenêtre spécifiée. Consultez des exemples sur la façon dont les modifications prennent effet ci-dessous.

Par exemple,

Imaginons que nous sommes le jeudi 9 novembre à 15 h 00 et que la prochaine fenêtre de maintenance soit le vendredi 10 novembre à 17 h 00. Voici 3 scénarios et leurs résultats :

• Vous modifiez votre créneau de maintenance pour le vendredi à 16 h 00 (après la date en cours et avant le prochain créneau de maintenance prévu). Le nœud sera remplacé le vendredi 10 novembre à 16 h 00.
• Vous modifiez votre créneau de maintenance pour le samedi à 16 h 00 (après la date en cours et après le prochain créneau de maintenance prévu). Le nœud sera remplacé le samedi 11 novembre à 16 h 00.
• Vous modifiez votre créneau de maintenance pour le mercredi à 16 h 00 (plus tôt dans la semaine que la date en cours). Le nœud sera remplacé le mercredi 15 novembre à 16 h 00.

Q : À quoi servent ces remplacements de nœuds ?

Ces remplacements sont nécessaires à l'application des mises à jour logicielles obligatoires sur votre hôte sous-jacent. Les mises à jour renforcent la sécurité et la fiabilité tout en améliorant les performances opérationnelles.

Q : Ces remplacements ont-ils un impact simultané sur les nœuds situés dans différentes zones de disponibilité ?

Il se peut que nous remplacions plusieurs nœuds pour un même cluster, suivant la configuration de ce nœud, tout en maintenant la stabilité du cluster. Pour les clusters partagés Redis, nous essayons de ne pas remplacer plusieurs nœuds d'un même fragment en même temps. De plus, nous tentons de ne pas remplacer la majorité des nœuds principaux du cluster sur tous les fragments.
Pour les clusters non fragmentés, nous essaierons d'échelonner au mieux les remplacements de nœuds sur la fenêtre de maintenance pour assurer la stabilité continue du cluster.

Q : Les nœuds dans différents clusters et différentes régions seront-ils remplacés simultanément ?

Oui, il se peut que ces nœuds soient remplacés en même temps si leur créneau de maintenance est identique.