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

Présentation

Nous mettons régulièrement à niveau notre flotte d’instances Amazon ElastiCache en leur appliquant des correctifs et des mises à jour, et ce, sans qu’un redémarrage soit nécessaire. Nous procédons de l'une des deux façons suivantes :

(a) maintenance gérée continue, et (b) mises à jour de service. Cette maintenance et ces mises à jour de service sont nécessaires à l'application des mises à niveau, lesquelles renforcent la sécurité et la fiabilité, tout en améliorant les performances opérationnelles.

La maintenance gérée continue a lieu de temps en temps et directement dans vos créneaux de maintenance, sans intervention de votre part.
À l'inverse, vous pouvez appliquer vous-même les mises à jour de service. Elles sont planifiées et peuvent être incluses dans le créneau de maintenance afin de nous permettre de les appliquer après leur date d'échéance.

Vous pouvez gérer ces mises à jour vous-même, à tout moment, en amont de l'opération de maintenance programmée. Lorsque vous gérez vous-même une mise à jour, votre instance reçoit la mise à jour du système d'exploitation lorsque vous relancez le nœud et votre créneau de maintenance programmé est annulé.

Sujets de la page

Mises à jour de service
23
Mises à jour de maintenance gérée continue
11

Mises à jour de service

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 ».

Lorsque les mises à jour de service applicables à vos clusters 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.

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 « 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.

Si votre cluster 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 « Date limite d’application recommandée ». Pour obtenir plus d’informations, consultez la section Self-Service Security Updates for Compliance.

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 « Date limite d’application recommandée », vous pouvez le faire jusqu’à la date indiquée par l’attribut « Date d’expiration de la mise à jour ». Toutefois, la « Date d’expiration de la mise à jour » peut changer à tout moment en fonction de la disponibilité des nouvelles mises à jour.

Lorsque vous ou Amazon ElastiCache appliquez une mise à jour de service à un ou plusieurs clusters, 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 du cluster continue 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 ?

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

Vous pouvez déterminer si vous pouvez refuser une mise à jour de service en vérifiant la valeur de l’attribut « Mise à jour automatique après la date d’échéance ». Si la valeur de l’attribut « 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 « Mise à jour automatique après la date d’échéance » d’une mise à jour de service est « oui » et que la date mentionnée par l’attribut « Date limite d’application recommandée » est passée, ElastiCache planifie automatiquement la mise à jour de service pour tous les clusters restants pendant la prochaine fenêtre 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.

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 « Mise à jour automatique après la date d’échéance » 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 ? ».

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.

Une liste complète des attributs et leurs descriptions est disponible dans la section Applying the Self-Service Updates.

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 « Gravité » qui comporte les valeurs suivantes (par ordre de priorité) :

1. 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. moyen : application recommandée sous 60 jours ou moins
4. faible : application recommandée sous 90 jours ou moins

Pour obtenir plus de détails, reportez-vous à la section publique Applying Updates.

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

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

Ces informations sont pertinentes pour les clusters Amazon ElastiCache gérés selon les programmes de conformité HIPAA, PCI et FedRAMP. Pour obtenir plus d’informations, consultez la section Self-Service Security Updates for Compliance.

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 « 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.

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.

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.

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.

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

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.

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é ».

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 d’échéance » 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.

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.

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.

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.

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, des nœuds primaires Redis OSS peuvent manquer de mémoire et avoir un trafic en écriture important. Lorsqu’un réplica vide se synchronise à partir d’un nœud primaire, 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.

Pour les nœuds Redis OSS, le processus de remplacement met tout en œuvre pour retenir vos données existantes et nécessite une réplication réussie. Pour les clusters à 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 primaire déclenche un basculement vers un réplica en lecture. Pour les configurations de clusters pouvant utiliser les clients clusters et les configurations non clusters avec basculement automatique activé, les remplacements planifiés de nœuds se font pendant que le cluster sert 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.

Pour les nœuds Redis OSS, le processus de remplacement met tout en œuvre pour retenir vos données existantes et nécessite une réplication réussie. 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 OSS vers la version 5.0.6 ou plus, car ces versions ont une plus grande stabilité et permettent que vos clusters 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 à nœud unique, nous vous recommandons d’avoir une quantité de mémoire suffisante pour Redis OSS, comme indiqué ici. Pour les groupes de réplication à 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 de données est inévitable, car Memcached stocke les données essentiellement en mémoire.

Pour Redis OSS, la configuration en mode cluster dispose de la meilleure disponibilité pendant les opérations gérées ou non gérées. 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 primaire 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.

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 cas d’utilisation :

• Modifier la fenêtre de maintenance.
• Relancer votre instance à l’aide du processus Sauvegarde et restauration.
• Si l’option « Mode cluster désactivé » est configurée pour votre cluster

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.
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.
o Remplacer un nœud autonome (mode cluster désactivé) : deux procédures différentes qui permettent de remplacer un nœud autonome.

• Si l’option « Mode cluster activé » est configurée pour votre cluster

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 Actions You Can Take When a Node is Scheduled for Replacement.

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é.

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.

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.

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.

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 partitionnés, nous essayons de ne pas remplacer plusieurs nœuds d’une même partition 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.

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