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

P: ¿Qué son las actualizaciones de servicio en Amazon ElastiCache?

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. 

P: ¿Cómo me entero cuando haya actualizaciones de servicio de ElastiCache disponibles?

Cuando las actualizaciones de servicio correspondientes a clústeres de Memcached y Redis se encuentren disponibles, se lo notificaremos por diferentes canales, como la consola de Amazon ElastiCache, correos electrónicos, Amazon Simple Notification Service (SNS), el panel personal de AWS Health y Eventos de Amazon CloudWatch.

P: ¿En qué se diferencian las actualizaciones del periodo de mantenimiento y las actualizaciones de servicio?

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 dan el control de realizar la solicitud en “Solicitud recomendada por fecha”. Si aún no se han aplicado, ElastiCache puede programar estas actualizaciones en su periodo de mantenimiento.

P: ¿Cómo determino si debo aplicar la actualización de servicio disponible?

Si su clúster de Redis 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 por su “Solicitud recomendada por fecha”. Para obtener más información, consulte Actualizaciones de seguridad de autoservicio para garantizar el cumplimiento.

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 por su “Solicitud recomendada por fecha”, 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.

P: ¿Cuál es el impacto de aplicar una actualización de servicio de ElastiCache para los clústeres de Redis? ¿Perderé datos de mis clústeres o conectividad a estos?

Cuando usted o Amazon ElastiCache aplican una actualización de servicio a uno o más clústeres de Redis, 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 de Redis 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?
  

P: ¿Hay tiempo de inactividad relacionado con la aplicación de la actualización de los clústeres de ElastiCache para Memcached?

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

P: ¿Puedo dejar de aplicar las actualizaciones de servicio?

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 periodo de mantenimiento. Esta actualización automática de servicio se programará antes de la “Fecha de vencimiento de actualización” y usted 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.

P: ¿Por qué ElastiCache no puede aplicar directamente las actualizaciones de servicio durante los periodos 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?

P: ¿Puedo usar las actualizaciones de servicio para dejar de aplicar el mantenimiento de servicio de Amazon ElastiCache y, en cambio, aplicar las actualizaciones disponibles por mi cuenta?

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.

P: ¿Dónde está la lista de todos los atributos de las actualizaciones de servicio?

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

P: ¿Todas las actualizaciones de servicio se aplican con la misma cronología ?

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.

P: ¿Con qué frecuencia se lanzan las actualizaciones de servicio?

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

P: ¿Qué es el atributo “Cumplimiento del SLA de actualización de servicio” ?

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

Esta información es relevante para los clústeres de Redis 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 el cumplimiento.

P: Si omito una o más actualizaciones de servicio, ¿podré aplicarlas más tarde?

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.

P: ¿Puedo elegir aplicar una actualización de servicio a nodos específicos en un clúster de ElastiCache?

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.

P: ¿Por qué el estado de la actualización de uno o más nodos en los clústeres de ElastiCache cambiaron de “no aplicada” a “completada” aun cuando no he aplicado la actualización de servicio?

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.

P: ¿Qué sucede si tengo nodos a los que quiero aplicarles actualizaciones de servicio vencidas? ¿Debo esperar a la próxima actualización de servicio?

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.

P: ¿Las actualizaciones de servicio son específicas de un motor?

Sí. Una actualización de servicio puede aplicarse solo a Redis, solo a Memcached o a Redis 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.

P: ¿Puedo modificar la actualización de servicio programada a un horario más apropiado? ¿Qué ocurre con la actualización programada si cambio el periodo de mantenimiento?

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.

P: ¿Por qué recibí notificaciones de varias actualizaciones para el mismo clúster? ¿Tengo que aplicarlas todas?

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.

P: ¿Cómo se programa y aplica la actualización del servicio después de la “Fecha recomendada de aplicación”?

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.

P: ¿Qué ocurre si la actualización de servicio no puede aplicarse a todo el clúster en un solo periodo de mantenimiento?

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.

P: ¿Puedo revertir la actualización del servicio?

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.

P: ¿Qué es una actualización 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.

P: ¿Cuánto tiempo requiere reemplazar un nodo?

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, los nodos principales de Redis podrían no tener suficiente memoria disponible y presentar 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.

P: ¿Qué impacto tiene el reemplazo de un nodo en mi aplicación?

En el caso de nodos de Redis, el proceso de reemplazo se diseñó para que intente conservar los datos existentes y requiere una replicación de Redis correcta. En el caso de los clústeres Redis 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 replicación conformados por varios nodos, ElastiCache reemplaza las réplicas existentes y sincroniza los datos desde las réplicas principales a las nuevas. Si Multi-AZ con compatibilidad con la conmutación por error automática está habilitado, reemplazar la réplica principal activa una conmutación por error a una réplica de lectura. En el caso de las configuraciones del clúster Redis configuradas para usar clientes de clúster Redis, y las configuraciones que no son de clúster con la conmutación por error habilitada, los reemplazos programados de nodo ahora se realizarán mientras el clúster atiende las solicitudes de escritura de entrada. Si Multi-AZ no está habilitado, 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é.

P: ¿Qué prácticas recomendadas debo seguir para que el reemplazo se realice sin problemas y se reduzca el nivel de pérdida de datos?

En el caso de nodos de Redis, el proceso de reemplazo se diseñó para que intente conservar los datos existentes y requiere una replicación de Redis 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 sincronizarán a partir de un nodo del mismo nivel en una zona de disponibilidad diferente. También recomendamos que actualice la versión de su motor Redis a 5.0.6 o más dado que esas versiones de motor han mejorado la estabilidad y permiten que sus clústeres sirvan continuamente solicitudes de escritura entrante durante las actividades de parche si tienen habilitada la conmutación por error automática. Por último, si su configuración incluye solo una réplica principal y única por participació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 Redis de nodos individuales, recomendamos que Redis disponga de memoria suficiente, tal y como se describe aquí. En el caso de grupos de replicación de Redis con varios nodos, también recomendamos programar el reemplazo de modo 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.

P: ¿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?

En el caso de Redis, la configuración del modo clúster tiene mejor disponibilidad durante las operaciones administradas o no administradas y siempre se recomienda utilizar un cliente soportado por el modo clúster que se conecta con el punto de enlace del clúster. En el caso del modo clúster 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.

P: ¿De qué manera puedo administrar los reemplazos de nodos por mi cuenta?

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 del reemplazo, puede llevar a cabo diversas acciones en función de su caso de uso y la configuración del clúster:

• Modificar el periodo de mantenimiento.
• Volver a lanzar su instancia de Redis con el proceso de copia de seguridad y restauración.
• Si la configuración de clúster de Redis 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 replicación de Redis.
o Reemplace el nodo principal (modo clúster desactivado): un procedimiento para reemplazar manualmente el nodo principal en un grupo de replicación de Redis.
o Reemplace un nodo independiente (modo clúster desactivado): dos procedimientos diferentes para reemplazar un nodo de Redis independiente.

• Si la configuración de clúster de Redis 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.

P: ¿Dónde puedo consultar el calendario de sustituciones programadas?

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

P: ¿Puedo modificar el mantenimiento programado a un horario más apropiado?

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 reemplazará 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 reemplazará 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 reemplazará el próximo miércoles 15 de noviembre a las 16:00 horas.

P: ¿Por qué realizan estos reemplazos de nodos?

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.

P: ¿Estos reemplazos afectan los nodos en varias zonas de disponibilidad al mismo tiempo?

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 fragmentados de Redis, intentamos no reemplazar varios nodos en el mismo fragmento 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.

P: ¿Es posible reemplazar al mismo tiempo nodos en diferentes clústeres ubicados en regiones distintas?

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