Página de ayuda de actualizaciones de servicio y mantenimiento administrado de Amazon ElastiCache

Información general

Actualizamos con frecuencia la flota de Amazon ElastiCache con parches y actualizaciones que se aplican a las instancias sin problemas. Hacemos esto de una de las dos maneras:

(a) el mantenimiento administrado continuo y (b) las actualizaciones de servicio. Estas actualizaciones de mantenimiento y de servicio son necesarias para aplicar mejoras que refuercen la seguridad, la confianza y el rendimiento operativo.

El mantenimiento administrado continuo ocurre de vez en cuando y directamente en los periodos de mantenimiento sin requerir acciones de su parte.
Las actualizaciones de servicio ofrecen la flexibilidad de aplicarlas por su cuenta. Están programadas y pueden pasarse al periodo de mantenimiento para aplicarlas después de la fecha de vencimiento.

Puede administrar las actualizaciones por su cuenta en cualquier momento antes del periodo de mantenimiento programado. Cuando administra una actualización por su cuenta, su instancia recibirá la actualización del sistema operativo cuando reinicie el nodo y su periodo de mantenimiento programado se cancelará.

Temas de la página

Actualizaciones de servicio
23
Actualizaciones de mantenimiento administrado continuo
11

Actualizaciones de servicio

Actualizaciones de servicio es una característica de Amazon ElastiCache que le permite aplicar, según lo considere, determinadas actualizaciones de servicio. Estas actualizaciones pueden ser de los siguientes tipos: parches de seguridad o actualizaciones menores de software. Estas actualizaciones ayudan a reforzar el nivel de seguridad, fiabilidad y rendimiento operativo de los clústeres.

El valor de estas actualizaciones de servicio es que puede controlar cuándo aplicarlas (p. ej., puede retrasar la aplicación de actualizaciones de servicio cuando haya un evento comercial importante que requiera que los clústeres de ElastiCache estén disponibles las 24 horas, los 7 días de la semana).

Para obtener detalles de cada actualización de servicio, consulte el valor del atributo “Descripción de actualización”.

Cuando haya actualizaciones disponibles del servicio correspondientes a los clústeres, se lo notificaremos por diferentes canales, como la consola de Amazon ElastiCache, el correo electrónico, Amazon Simple Notification Service (SNS), el panel de control personal de AWS Health y eventos de Amazon CloudWatch.

Las actualizaciones disponibles a través del mantenimiento administrado continuo son independientes de las ofrecidas por las actualizaciones de servicio. Las actualizaciones aplicadas a través del mantenimiento administrado continuo se programan directamente en los periodos de mantenimiento y no requieren ninguna acción de su parte. Las actualizaciones de servicio son programadas y le permiten elegir si desea aplicarlas antes de la “Fecha recomendada de aplicación”. Si aún no se han aplicado, ElastiCache puede programar estas actualizaciones en su periodo de mantenimiento.

Si el clúster de ElastiCache forma parte de un programa de cumplimiento de HIPAA, PCI o FedRAMP, a fin de mantener la conformidad, debe aplicar las actualizaciones de servicio antes de su “Fecha recomendada de aplicación”. Para obtener más información, consulte Actualizaciones de seguridad de autoservicio para garantizar la conformidad.

Para otros clústeres, le recomendamos que aplique actualizaciones de servicio según su cadencia empresarial. Si no puede aplicar una actualización de servicio antes de su “Fecha recomendada de aplicación”, podrá aplicarla hasta la “Fecha de vencimiento de actualización”. Sin embargo, la “Fecha de vencimiento de actualización” puede cambiar en cualquier momento en función de la disponibilidad de nuevas actualizaciones.

Cuando usted o Amazon ElastiCache aplican una actualización de servicio a uno o más clústeres, la actualización se aplica a no más de un nodo a la vez dentro de cada partición hasta que se actualizan todos los clústeres seleccionados. Los nodos que se actualicen experimentarán un tiempo de inactividad de pocos segundos, mientras que el resto del clúster seguirá sirviendo el tráfico.

  • No habrá cambios en la configuración del clúster.
  • Verá un retraso en las métricas de CloudWatch que se actualizan lo antes posible.

Las actualizaciones del servicio se aplican de la misma manera que las Actualizaciones de mantenimiento administrado continuo, mediante la sustitución de nodos. Consulte las siguientes preguntas en la sección Actualizaciones de mantenimiento administrado continuo de esta página para obtener detalles sobre cómo se aplica la actualización y cómo preparar su aplicación para minimizar el impacto.

  • ¿Qué impacto tiene el reemplazo de un nodo en mi aplicación?
  • ¿Qué prácticas recomendadas debo seguir para que el reemplazo se realice sin problemas y se reduzca el nivel de pérdida de datos?
  • ¿Cuál de las prácticas recomendadas de configuración del cliente debería seguir para minimizar la interrupción de la aplicación durante el mantenimiento?

Sí, el nodo se reemplaza con un nuevo nodo vacío. El contenido en caché ya no estará allí y comenzará desde cero.

Para determinar si puede dejar de recibir una actualización de servicio, compruebe el valor del atributo “Actualización automática después de la fecha de vencimiento”. Si el valor del atributo “Actualización automática después de la fecha de vencimiento” de una actualización de servicio es “no”, puede dejar de recibir esta actualización de servicio. Sin embargo, si el valor del atributo “Actualización automática después de la fecha de vencimiento” de la actualización de servicio es “sí” y la “Fecha de aplicación” recomendada ya ha pasado, ElastiCache programará automáticamente la actualización de servicio de los clústeres restantes durante el próximo período de mantenimiento. Esta actualización automática de servicio se programará antes de la “Fecha de vencimiento de actualización” y recibirá una notificación una semana antes de la actualización con la hora programada. Le recomendamos que aplique las actualizaciones de seguridad, incluso si puede optar por dejar de recibirlas.  Si elige aplicar la actualización de servicio a los clústeres restantes antes del periodo de mantenimiento, ElastiCache no volverá a aplicar la actualización de servicio durante el periodo de mantenimiento.

El objetivo de las actualizaciones de servicio es permitirle elegir el momento en que desea aplicarlas. Los clústeres que no participan en los programas de cumplimiento compatibles con ElastiCache pueden no aplicar estas actualizaciones o bien, aplicarlas con menor frecuencia durante todo el año. Esto es así solo cuando el valor del atributo “Actualización automática después de la fecha de vencimiento” de la actualización de servicio es “no”. Para obtener más información, consulte ¿Puedo dejar de aplicar las actualizaciones de servicio?

No, las actualizaciones de servicio son mutuamente exclusivas de las actualizaciones de mantenimiento administrado continuo aplicadas directamente por Amazon ElastiCache durante los periodos de mantenimiento de los clústeres.

La lista completa de atributos y sus descripciones se encuentra disponible en Cómo aplicar las actualizaciones de autoservicio.

Para ayudar a determinar qué tan pronto aplicar las actualizaciones de servicio disponibles, puede consultar el atributo de actualización de servicio “Gravedad” que tiene los siguientes valores (en orden de prioridad):

1. crítico: se recomienda aplicar inmediatamente (dentro de los 14 días o menos)
2. importante: se recomienda aplicar tan pronto como el proceso de negocio lo permita (dentro de los 30 días o menos)
3. intermedio: se recomienda aplicar dentro de los 60 días o menos
4. bajo: se recomienda aplicar dentro de los 90 días o menos

Para más información, consulte nuestra documentación pública: Cómo aplicar actualizaciones.

El cronograma de lanzamiento depende de la importancia de las actualizaciones de servicio.

Este atributo refleja si el clúster se actualizó antes de la “Fecha recomendada de aplicación”. Si se aplica una actualización de servicio después de la “Fecha recomendada de aplicación”, el atributo “Cumplimiento del SLA de actualización de servicio” se define en “no”.

Esta información es relevante para los clústeres de Amazon ElastiCache que participan en programas de cumplimiento HIPAA, PCI y FedRAMP. Para obtener más información, consulte Actualizaciones de seguridad de autoservicio para garantizar la conformidad.

Sí. Salvo que se indique lo contrario en el atributo “Descripción” de la actualización de servicio, las actualizaciones de servicio siempre se acumulan: si omite aplicarlas antes de la “Solicitud recomendada por fecha”, se incluirán en la próxima actualización de servicio. Las actualizaciones de servicio del tipo “seguridad” pertenecen a esta categoría acumulativa.

No, las actualizaciones de servicio se aplican a nivel de clúster. Si cancela una actualización en curso, es posible que algunos nodos del clúster se actualicen y otros no. En este caso, el clúster continuará mostrándose en la lista de clústeres a los que aplicar la actualización de servicio. El clúster continuará operando de manera habitual.

Cuando esto sucede, pueden darse dos casos:

(a) Si omitió aplicar la actualización de servicio que era opcional y ahora su estado es “vencida”. Por lo tanto, los clústeres que participan en programas de conformidad siempre deben aplicar todas las actualizaciones de servicio.
(b) Si el nodo se reemplaza por cualquier otro motivo, como un evento de mantenimiento planificado o una conmutación por error del nodo, Amazon ElastiCache aprovisionará nodos nuevos con las actualizaciones de servicio más recientes incluidas.

En ambos casos, el clúster continuará operando de manera habitual.

Los nodos nuevos contienen todas las actualizaciones de servicio pertinentes, de modo que podrá reemplazar manualmente los nodos existentes que no se actualizaron para recibir las últimas actualizaciones.

Sí. Una actualización de servicio puede aplicarse solo a Redis OSS, solo a Memcached o a Redis OSS y Memcached. Puede buscar los atributos “Motor” y “Versión del motor” de la actualización de servicio para determinar el alcance de cada actualización.

Sí, para aplazar la actualización del servicio, cambie el periodo de mantenimiento. La actualización programada solo se aplicará al clúster si la fecha programada coincide con el periodo de mantenimiento del clúster. Una vez que cambie el periodo de mantenimiento y la fecha programada haya pasado, la actualización del servicio se reprogramará en el nuevo periodo especificado en las siguientes semanas. Recibirá una nueva notificación una semana antes de que se cumpla la nueva fecha.

La seguridad en AWS es una responsabilidad compartida. Le recomendamos que aplique la actualización lo antes posible.

Su clúster puede formar parte de diferentes actualizaciones del servicio. No es necesario aplicar la mayoría de las actualizaciones por separado. La aplicación de una actualización a su clúster marcará las otras actualizaciones como completadas cuando corresponda. Es posible que tenga que aplicar varias actualizaciones al mismo clúster por separado si el estado no cambia a “completado” automáticamente.

ElastiCache programará la actualización del servicio en los clústeres restantes después de la “Fecha recomendada de aplicación” si el valor del atributo “Actualización automática después de la fecha límite” es “sí”. La actualización se programará en el periodo de mantenimiento del clúster y recibirá una nueva notificación con una semana de antelación con la fecha prevista antes de que se apliquen las actualizaciones.

La actualización de servicio programada se aplicará a los clústeres de la misma manera que las “Actualizaciones de mantenimiento administrado continuo”. Consulte la siguiente sección sobre los detalles de cómo se aplica la actualización, cómo cambiar la actualización programada y cómo preparar su aplicación para una actualización programada a fin de minimizar el impacto.

Para mantener la estabilidad del clúster, ElastiCache aplica las actualizaciones a un solo nodo a la vez dentro de cada partición. Si la actualización del servicio no puede aplicarse a todo el clúster en un solo periodo de mantenimiento, se programará para continuar en los siguientes. Recibirá nuevas notificaciones sobre la próxima fecha prevista y podrá prepararse al respecto.

El cliente no puede revertir la actualización del servicio una vez comenzada. Si encuentra un problema después de aplicar una actualización del servicio, póngase en contacto con el equipo de AWS Support.

Actualizaciones de mantenimiento administrado continuo

Estas actualizaciones son obligatorias y se aplican directamente en los periodos de mantenimiento y no requieren ninguna acción de su parte. Estas actualizaciones son separadas de las que ofrecen las actualizaciones de servicio.

Los reemplazos suelen completarse en pocos segundos. El reemplazo puede llevar más tiempo en determinadas configuraciones de instancias y patrones de tráfico. Por ejemplo, es posible que los nodos principales de Redis OSS no tengan suficiente memoria disponible y presenten un alto nivel de tráfico de escritura. Cuando una réplica vacía se sincroniza a partir del nodo principal, este podría quedarse sin capacidad de memoria intentando atender las escrituras entrantes y sincronizar la réplica. En dicho caso, el nodo principal desconecta la réplica y reinicia el proceso de sincronización. Es posible que sea necesario realizar varios intentos para que la réplica se sincronice correctamente. También es posible que la réplica jamás se sincronice si el nivel de tráfico de escritura entrante continúa siendo alto.

Los nodos de Memcached no necesitan sincronizarse, así que su reemplazo se realiza con más rapidez, independientemente del tamaño de los nodos.

En el caso de nodos de Redis OSS, el proceso de reemplazo está diseñado para que intente conservar los datos existentes y requiere una réplica correcta. En el caso de los clústeres de nodos individuales, ElastiCache realiza una réplica de forma dinámica y luego conmuta a ella por error. En el caso de grupos de réplica conformados por varios nodos, ElastiCache reemplaza las réplicas existentes y sincroniza los datos desde las réplicas principales a las nuevas. Si está habilitado el Multi-AZ con conmutación por error automática, reemplazar la réplica principal activa una conmutación por error a una réplica de lectura. En el caso de las configuraciones de clústeres establecidas para usar clientes de clúster, y las configuraciones que no son de clúster con la conmutación por error automática habilitada, los reemplazos programados de nodos se completan mientras el clúster atiende las solicitudes de escritura de entrada. Si no está habilitado el Multi-AZ, ElastiCache sustituye la réplica principal y luego sincroniza los datos desde una réplica de lectura. Durante este tiempo, el nodo primario no está disponible y esto causa una interrupción más prolongada de la escritura.

En el caso de los nodos de Memcached, el proceso de reemplazo aporta un nuevo nodo vacío y pone fin al nodo actual. El nuevo nodo no estará disponible durante un breve período de tiempo durante el cambio. Una vez que se haya realizado el cambio, la aplicación puede sufrir una disminución del desempeño mientras el nuevo nodo vacío se llena con los datos de la caché.

En el caso de nodos de Redis OSS, el proceso de reemplazo está diseñado para que intente conservar los datos existentes y requiere una réplica correcta. Intentamos reemplazar un número de nodos suficiente del mismo clúster por vez para conservar la estabilidad del clúster. Puede aprovisionar réplicas principales y de lectura en diferentes zonas de disponibilidad. En ese caso, cuando un nodo se reemplaza, los datos se sincronizan a partir de un nodo del mismo nivel en una zona de disponibilidad diferente. También recomendamos actualizar la versión de Redis OSS a 5.0.6 o más dado que esas versiones de motor han mejorado la estabilidad y permiten que los clústeres sirvan de manera continua solicitudes de escritura entrantes durante las actividades de parche si tienen habilitada la conmutación por error automática. Por último, si la configuración incluye solo una réplica principal y única por partición, recomendamos agregar réplicas adicionales antes de los parches. Esto evitará la disponibilidad y el riesgo reducidos durante el proceso de parches. En el caso de clústeres de nodos individuales, recomendamos que Redis OSS disponga de memoria suficiente, tal y como se describe aquí. En el caso de grupos de réplica con varios nodos, también recomendamos programar el reemplazo para que se realice en un período con poco tráfico de escritura entrante.

En el caso de los nodos de Memcached, programe el período de mantenimiento durante un momento con poco tráfico de escritura entrante, pruebe la aplicación para la conmutación por error y use el cliente “más inteligente” provisto por ElastiCache. No puede evitar la pérdida de datos ya que Memcached tiene datos exclusivamente en memoria.

En el caso de Redis OSS, la configuración del modo clúster tiene mejor disponibilidad durante las operaciones administradas o no administradas y siempre se recomienda utilizar un cliente compatible con el modo clúster que se conecta con el punto de enlace de descubrimiento del clúster. En el caso en que el modo clúster esté desactivado, se recomienda usar siempre el punto de enlace principal para todas las operaciones de escritura. Para todas las operaciones de lectura se pueden usar los puntos de enlace de nodo individuales de los nodos de réplica. Si la compatibilidad con la conmutación por error automática está habilitada en el clúster, el nodo principal podría cambiar; por lo tanto, la aplicación deberá confirmar el rol del nodo y actualizar todos los puntos de enlace de escritura para garantizar que no está ocasionando más carga en el nodo principal. Con la compatibilidad con la conmutación por error automática deshabilitada, el rol del nodo no cambiará; sin embargo, el tiempo de inactividad en las operaciones administradas o no administradas es mayor en comparación con los clústeres que tienen esta función habilitada. Evite dirigir solicitudes de lectura solo a réplicas de lectura. Si configura su cliente para enviar solicitudes de lectura solo a réplicas de lectura, asegúrese de tener por lo menos dos réplicas de lectura para evitar su interrupción durante el mantenimiento.

Recomendamos que permita a ElastiCache administrar los reemplazos de nodos por usted durante el período de mantenimiento programado. Puede especificar los horarios preferidos para los reemplazos a través del período de mantenimiento semanal cuando crea un clúster de ElastiCache. Para cambiar el período de mantenimiento a un horario más conveniente con posterioridad, puede utilizar la API ModifyCacheCluster o hacer clic en Modify (Modificar), en la consola de administración de ElastiCache.

Si decide ocuparse usted mismo de la administración de la sustitución, puede tomar varias acciones en función de su caso de uso y configuración de clúster:

• Modificar el período de mantenimiento.
• Volver a lanzar su instancia con el proceso de copia de seguridad y restauración.
• Si la configuración del clúster es Cluster Mode Disabled (modo clúster desactivado)

o Reemplace una réplica de lectura (modo clúster desactivado): un procedimiento para reemplazar manualmente una réplica de lectura en un grupo de réplica.
o Reemplace el nodo principal (modo clúster desactivado): un procedimiento para reemplazar manualmente el nodo principal en un grupo de réplica.
o Reemplace un nodo independiente (modo clúster desactivado): dos procedimientos diferentes para reemplazar un nodo independiente.

• Si la configuración del clúster es Cluster Mode Enabled (modo clúster activado)

o Reemplace un nodo en clúster con una o más particiones: puede usar una copia de seguridad o restauración, o bien ajustar la escala de manera horizontal y después vertical para reemplazar los nodos.

Si desea obtener más instrucciones acerca de todas estas opciones, consulte la página Acciones que puede implementar cuando un nodo está programado para el reemplazo.

Para Memcached, tan solo debe eliminar y volver a crear los clústeres. Tras la sustitución, la instancia ya no debería tener asociado un evento programado.

Si desea recibir notificaciones, puede configurar las notificaciones de Amazon SNS para eventos importantes, como un evento de reemplazo programado. Puede usar la sección Eventos de la consola de administración de ElastiCache o la API describe-events para buscar el siguiente evento ElastiCache:NodeReplacementScheduled.

Para configurar las notificaciones de SNS, use la información que se proporciona aquí.

Sí, puede cambiar el período de mantenimiento de su clúster. Para cambiar el período de mantenimiento a un horario más conveniente con posterioridad, puede utilizar la API (ModifyCacheCluster o ModifyReplicationGroup) o hacer clic en Modify (Modificar), en la consola de administración de ElastiCache.

Una vez implementada la modificación, el servicio ElastiCache programará el mantenimiento de su nodo durante el nuevo período especificado. Puede consultar a continuación ejemplos acerca de cómo se implementan los cambios.

Por ejemplo,

Supongamos que son las 15:00 horas del jueves 9 de noviembre y el siguiente período de mantenimiento es el viernes 10 de noviembre a las 17:00 horas. A continuación, se exponen tres casos con sus resultados:

• Cambia el periodo de mantenimiento a los viernes a las 16:00 horas (después de la fecha actual y antes del siguiente periodo de mantenimiento programado). El nodo se sustituirá el viernes 10 de noviembre a las 16:00 horas.
• Cambia el periodo de mantenimiento al sábado a las 16:00 horas (después de la fecha actual y después del siguiente periodo de mantenimiento programado). El nodo se sustituirá el sábado 11 de noviembre a las 16:00 horas.
• Cambia el periodo de mantenimiento al miércoles a las 16:00 horas (con anterioridad en la semana en relación con la fecha actual). El nodo se sustituirá el próximo miércoles 15 de noviembre a las 16:00 horas.

Las sustituciones son necesarias para aplicar en su host subyacente actualizaciones obligatorias de software. Estas actualizaciones refuerzan el nivel de seguridad, fiabilidad y desempeño operativo.

Es posible que sustituyamos varios nodos del mismo clúster en función de la configuración del clúster mientras conservamos la estabilidad de este último. Para clústeres particionados, intentamos no reemplazar varios nodos en la misma partición al mismo tiempo. Además, intentamos no sustituir la mayoría de los nodos principales en el clúster en todos los fragmentos.
En el caso de los clústeres no fragmentados, intentaremos escalonar los reemplazos de los nodos durante el período de mantenimiento en la máxima medida posible para continuar conservando la estabilidad del clúster.

Sí, es posible que estos nodos se reemplacen de manera simultánea si los períodos de mantenimiento de estos clústeres se configuran con los mismos valores.