Administración de las actualizaciones de servicio - Amazon MemoryDB

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Administración de las actualizaciones de servicio

Las actualizaciones del servicio MemoryDB se publican periódicamente. Si tiene uno o más clústeres aptos para esas actualizaciones de servicios, recibirá notificaciones por correo electrónico, SNS, el Personal Health Dashboard (PHD) y CloudWatch los eventos de Amazon cuando se publiquen las actualizaciones. Las actualizaciones se muestran también en la página Actualizaciones de servicio de la consola de MemoryDB. Mediante este panel, puede ver todas las actualizaciones de servicio y su estado para su flota MemoryDB.

Puede controlar cuándo se debe aplicar una actualización antes de que se inicie una actualización automática. Le recomendamos encarecidamente que aplique cualquier actualización del tipo de actualización de seguridad lo antes posible para garantizar que su MemoryDB esté siempre up-to-date con los parches de seguridad actuales.

En las siguientes secciones se describen detalladamente las opciones.

Información general sobre las actualizaciones de mantenimiento gestionado y servicio de Amazon MemoryDB

Solemos actualizar nuestra su flota MemoryDB con parches y actualizaciones que se aplican de forma transparente a las instancias. Lo hacemos de una de las dos formas siguientes:

  1. Mantenimiento gestionado continuo.

  2. Actualizaciones de servicio.

Estas actualizaciones de mantenimiento y servicio son necesarias para aplicar actualizaciones que refuerzan la seguridad, la fiabilidad y el rendimiento operativo.

El mantenimiento gestionado continuo se lleva a cabo de forma periódica y directa en sus períodos de mantenimiento, sin que sea necesaria ninguna acción por su parte. Es importante tener en cuenta que los períodos de mantenimiento son obligatorios para todos los clientes y no tendrá la opción de omitirlos. Recomendamos encarecidamente evitar cualquier actividad crítica o importante durante estos períodos de mantenimiento establecidos. Además, tenga en cuenta que para garantizar la seguridad y el rendimiento óptimo del sistema no se pueden omitir las actualizaciones críticas.

Las actualizaciones de servicio le ofrecen la flexibilidad necesaria para aplicarlas por su cuenta. Tienen un límite de tiempo y se pueden trasladar al período de mantenimiento para que las apliquemos una vez pasada su fecha de vencimiento.

Puede gestionar las actualizaciones aplicándolas tan pronto como le sea posible o reemplazando los nodos, ya que las actualizaciones se aplican automáticamente al reemplazarlos. No habrá actividad de actualización durante los períodos de mantenimiento entrantes si las actualizaciones se han aplicado a todos los nodos anteriores.

Actualizaciones de servicio

Las Actualizaciones de los servicios de MemoryDB le permiten aplicar determinadas actualizaciones de servicio según su criterio. Estas actualizaciones pueden ser de los siguientes tipos: parches de seguridad o actualizaciones de software menores. Estas actualizaciones ayudan a reforzar la seguridad, la fiabilidad y el rendimiento operativo de los clústeres.

La ventaja de estas actualizaciones de servicio es que puede controlar cuándo aplicarlas (por ejemplo, puede retrasar la aplicación de las actualizaciones de servicio cuando se produzca un evento empresarial importante que requiera la disponibilidad de los clústeres de MemoryDB las 24 horas del día, los 7 días de la semana).

Si tiene uno o más clústeres aptos para esas actualizaciones de servicio, recibirá notificaciones por correo electrónico, Amazon SNS, AWS Health Dashboard y CloudWatch eventos de Amazon Events cuando se publiquen las actualizaciones. Las actualizaciones se muestran también en la página Actualizaciones de servicio de la consola de MemoryDB. Mediante este panel, puede ver todas las actualizaciones de servicio y su estado para su flota MemoryDB.

Puede controlar cuándo se debe aplicar una actualización antes de que se inicie una actualización automática. Le recomendamos encarecidamente que aplique cualquier actualización del tipo de actualización de seguridad lo antes posible para garantizar que su MemoryDB esté siempre up-to-date con los parches de seguridad actuales.

Su clúster puede formar parte de diferentes actualizaciones de servicio. La mayoría de las actualizaciones no requieren que las aplique por separado. Al aplicar una actualización a su clúster, las demás actualizaciones se marcarán como completadas cuando proceda. Es posible que tenga que aplicar varias actualizaciones al mismo clúster por separado si el estado no cambia automáticamente a “completado”.

Impacto de las actualizaciones de servicio y tiempo de inactividad

Cuando usted o Amazon MemoryDB aplican una actualización de servicio a uno o más clústeres de MemoryDB, la actualización no se aplica a 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 estén actualizando experimentarán un tiempo de inactividad de unos segundos, mientras que el resto del clúster seguirá sirviendo al tráfico.

  • No habrá cambios en la configuración del clúster.

  • Verás un retraso en tus CloudWatch métricas que se ponen al día lo antes posible.

¿Cómo afecta el reemplazo de un nodo a mi aplicación? - En el caso de los nodos de MemoryDB, el proceso de reemplazo está diseñado para garantizar la durabilidad y la disponibilidad. En el caso de los clústeres de MemoryDB de un solo nodo, MemoryDB genera una réplica de forma dinámica, restaura los datos desde nuestros componentes de durabilidad y, a continuación, realiza la conmutación por error. En el caso de los grupos de replicación que constan de varios nodos, MemoryDB reemplaza las réplicas existentes y sincroniza los datos de nuestros componentes de durabilidad con las nuevas réplicas. MemoryDB solo es multi-AZ cuando hay más de un nodo, por lo que, en este escenario, el reemplazo del principal desencadena una conmutación por error a una réplica de lectura. Las sustituciones planificadas de nodos se completan mientras el clúster atiende solicitudes de escritura entrantes. Si solo hay un nodo, MemoryDB reemplaza al principal y, a continuación, sincroniza los datos de nuestros componentes de durabilidad. El nodo principal no está disponible durante este tiempo, lo que provoca una interrupción de escritura más prolongada.

¿Qué prácticas recomendadas debo seguir para asegurar una experiencia de reemplazo fluida y minimizar la pérdida de datos? - En MemoryDB, los datos son muy duraderos y no se esperan pérdidas de datos ni siquiera en implementaciones de un solo nodo. Sin embargo, se recomienda implementar estrategias multi-AZ y de copia de seguridad para minimizar las posibilidades de pérdida en el improbable caso de que se produzca un fallo. Para que la experiencia de reemplazo sea fluida, intentamos reemplazar solo los nodos necesarios del mismo clúster en cada operación para mantener la estabilidad del clúster. Puede aprovisionar el principal y réplicas de lectura en distintas zonas de disponibilidad habilitando Multi-AZ. En este caso, cuando se reemplaza un nodo, el rol principal realizará la conmutación por error a una réplica de la partición. Esta partición ahora servirá al tráfico y los datos se restaurarán desde sus componentes de durabilidad. Si su configuración incluye solo un principal y una única réplica por partición, le recomendamos añadir réplicas adicionales antes de aplicar los parches. Esto evitará que se reduzca la disponibilidad durante el proceso de aplicación de parches. Recomendamos programar el reemplazo durante un período con poco tráfico de escritura entrante.

¿Qué prácticas recomendadas de configuración de clientes debo seguir para minimizar la interrupción de las aplicaciones durante el mantenimiento? - En MemoryDB, la configuración en modo clúster siempre está habilitada, lo que proporciona la mejor disponibilidad durante las operaciones gestionadas o no gestionadas. Cada punto de conexión de los nodos de réplica se puede utilizar para todas las operaciones de lectura. En MemoryDB, la conmutación por error automática siempre está habilitada en el clúster, lo que significa que el nodo principal puede cambiar. Por lo tanto, la aplicación debe confirmar el rol del nodo y actualizar todos los puntos de conexión de lectura para garantizar que no se produzca una carga excesiva en el principal. Del mismo modo, evite sobrecargar las réplicas con solicitudes de lectura durante los períodos de mantenimiento. Una forma de conseguirlo es asegurarse de tener al menos dos réplicas de lectura para evitar cualquier interrupción de la lectura durante el mantenimiento.

Es importante probar las aplicaciones cliente para confirmar que cumplen con el protocolo Redis/Valkey Cluster y que las solicitudes se pueden redirigir correctamente entre los nodos. Se recomienda implementar estrategias de retroceso y reintento para evitar sobrecargar los nodos de MemoryDB durante las actividades de mantenimiento y reemplazo.

Reprogramación: puede aplazar la actualización de servicio cambiando el período de mantenimiento. La actualización programada solo se aplicará al clúster si la fecha programada coincide con el período de mantenimiento del clúster. Una vez que se haya cambiado el período de mantenimiento y haya pasado la fecha programada, la actualización de servicio se reprogramará según el nuevo período especificado en las semanas siguientes. Recibirá una nueva notificación una semana antes de la nueva fecha.

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

Omisión de las actualizaciones de servicio: para saber si puede omitir una actualización de servicio, consulte el valor del atributo “Fecha de inicio de la actualización automática”. Si el atributo “Fecha de inicio de la actualización automática” de una actualización de servicio tiene un valor configurado, MemoryDB programará la actualización de servicio en los clústeres restantes para el próximo período de mantenimiento y no será posible omitirla. Sin embargo, si aplica la actualización de servicio a los clústeres restantes antes del período de mantenimiento, MemoryDB no volverá a aplicar la actualización de servicio durante el período de mantenimiento. Para obtener más información, consulte Aplicación de las actualizaciones de servicio.

¿Por qué MemoryDB no puede aplicar directamente las actualizaciones de servicio durante los períodos de mantenimiento? - Tenga en cuenta que el objetivo de las actualizaciones de servicio es darle flexibilidad para decidir cuándo aplicarlas. Los clústeres que no participan en los programas de conformidad compatibles con MemoryDB pueden optar por no aplicar estas actualizaciones o aplicarlas con menos frecuencia a lo largo del año. Sin embargo, se recomienda aplicar las actualizaciones para mantener la conformidad con las normativas. Esto solo es aplicable si el atributo “Fecha de inicio de la actualización automática” de una actualización de servicio no tiene ningún valor configurado. Para obtener más información, consulte Validación de la conformidad en MemoryDB.

¿En qué se diferencian las actualizaciones que se aplican en el período de mantenimiento y las actualizaciones de servicio? - Las actualizaciones que se aplican mediante el mantenimiento gestionado continuo se programan directamente en sus períodos de mantenimiento sin que sea necesaria ninguna acción por su parte. Las actualizaciones de servicio tienen un límite de tiempo y le permiten decidir cuándo aplicarlas antes de la “Fecha de inicio de la actualización automática”. Si para entonces aún no se han aplicado, MemoryDB puede programar estas actualizaciones en su período de mantenimiento.

Actualizaciones de mantenimiento gestionado continuo

Estas actualizaciones son obligatorias y se aplican directamente en sus períodos de mantenimiento sin que sea necesario que realice ninguna acción. Estas actualizaciones son independientes de las que ofrecen las actualizaciones de servicio.

Impacto del mantenimiento continuo y tiempo de inactividad

¿Cuánto tiempo se tarda en reemplazar un nodo? - Por lo general, el reemplazo se completa en 30 minutos. El reemplazo puede tardar más con determinadas configuraciones de instancias y patrones de tráfico.

¿Cómo afecta el reemplazo de un nodo a mi aplicación? - Las actualizaciones de mantenimiento gestionado continuo se aplican de la misma manera que las “actualizaciones de servicio”, mediante el reemplazo de nodos. Consulte la sección anterior sobre el impacto de las actualizaciones de servicio y el tiempo de inactividad para obtener más información.

¿Cómo gestiono los reemplazos de nodos por mi cuenta? - Puede optar por administrar personalmente estas sustituciones en cualquier momento antes del período programado para la sustitución de nodos. Si decide gestionar el reemplazo por su cuenta, puede tomar varias medidas en función de su caso de uso.

  • Reemplace un nodo del clúster por una o más particiones: puede utilizar una copia de seguridad y restauración o un escalado horizontal seguido de una reducción horizontal para reemplazar los nodos.

  • Cambie el período de mantenimiento: también puede cambiar el período de mantenimiento del clúster. Para cambiar el período de mantenimiento a otro más conveniente más adelante, puede usar la UpdateCluster API, la CLI de actualización del clúster o hacer clic en Modificar en la consola de administración de MemoryDB. Una vez que cambie el período de mantenimiento, MemoryDB programará el mantenimiento del nodo durante el nuevo período especificado.

    Para ver cómo funciona, supongamos que hoy 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 muestran 3 escenarios:

    • Cambia el período de mantenimiento a los viernes a las 16:00 horas (después de la fecha actual y antes del siguiente período de mantenimiento programado). El nodo se sustituirá el viernes 10 de noviembre a las 16:00 horas.

    • Cambia el período de mantenimiento al sábado a las 16:00 horas (después de la fecha actual y después del siguiente período de mantenimiento programado). El nodo se sustituirá el sábado 11 de noviembre a las 16:00 horas.

    • Cambia el período de mantenimiento al miércoles a las 16:00 horas (un día anterior de la misma semana que la fecha actual). El nodo se sustituirá el próximo miércoles 15 de noviembre a las 16:00 horas.

    Para obtener más información, consulte Administración del mantenimiento.

    Tenga en cuenta que los nodos de distintos clústeres de distintas regiones se pueden reemplazar al mismo tiempo, siempre que el período de mantenimiento configurado de estos clústeres sea el mismo.

¿Cómo puedo informarme de los próximos reemplazos programados? - Debería recibir una notificación de salud en el panel de salud. AWS También puedes encontrar el estado de las diferentes actualizaciones de los servicios con la DescribeServiceUpdates API. Tenga en cuenta que nos esforzamos al máximo por notificar de forma proactiva a los clientes sobre los reemplazos previsibles. Sin embargo, en casos excepcionales, como fallos impredecibles, es posible que se produzcan reemplazos sin previo aviso.

¿Puedo cambiar el mantenimiento programado a un momento más adecuado? - Sí, puede aplazar el mantenimiento programado a un momento más adecuado cambiando el período de mantenimiento.

¿Por qué ocurren estos reemplazos de nodos? - Estos reemplazos son necesarios para aplicar las actualizaciones de software obligatorias al host subyacente. Estas actualizaciones ayudan a reforzar nuestra seguridad, la fiabilidad y el rendimiento operativo.

¿Estos reemplazos afectan al mismo tiempo a los nodos que se encuentran en varias zonas de disponibilidad y a los clústeres de distintas regiones? - Los reemplazos se pueden ejecutar en paralelo en varias zonas de disponibilidad o regiones, según el período de mantenimiento de los clústeres.