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 varios clústeres que reúnen los requisitos de estas actualizaciones, recibirá notificaciones por correo electrónico, SNS, Personal Health Dashboard (PHD) y eventos de Amazon CloudWatch cuando se seleccionan 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. Es absolutamente recomendable aplicar las actualizaciones del tipo security-update lo antes posible para asegurarse de que su MemoryDB esté siempre actualizado con los parches de seguridad actuales.
En las siguientes secciones se describen detalladamente las opciones.
Información general de las actualizaciones de mantenimiento y servicio gestionados 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:
Mantenimiento gestionado continuo.
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 periódica y directamente 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 excluirlos. Recomendamos encarecidamente evitar cualquier actividad crítica o importante durante estos períodos de mantenimiento establecidos. Además, tenga en cuenta que las actualizaciones críticas no se pueden omitir para garantizar la seguridad y el rendimiento óptimo del sistema.
Las actualizaciones de servicio le ofrecen la flexibilidad necesaria para aplicarlas por su cuenta. Están programadas y podemos transferirlas al período de mantenimiento para que las apliquemos una vez transcurrida su fecha de vencimiento.
Puede gestionar las actualizaciones aplicándolas tan pronto como sea posible o sustituyendo los nodos, ya que las actualizaciones se aplican automáticamente al sustituirlas. 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
Actualizaciones de los servicios de MemoryDB le permiten aplicar determinadas actualizaciones del 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.
El valor 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 varios clústeres que reúnen los requisitos de estas actualizaciones, recibirá notificaciones por correo electrónico, el Amazon SNS, elAWS Health Dashboard y eventos de Amazon CloudWatch cuando se seleccionan 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. Es absolutamente recomendable aplicar las actualizaciones del tipo security-update lo antes posible para asegurarse de que su MemoryDB esté siempre actualizado 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, se marcarán las demás actualizaciones 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 del 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 actualicen 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á un retraso en las métricas de CloudWatch 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 MemoryDB de un solo nodo, MemoryDB genera una réplica de forma dinámica, restaura los datos de 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, la sustitución 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.
¿Cuáles son las mejores prácticas que debo seguir para una experiencia de sustitución fluida y minimizar la pérdida de datos? - En MemoryDB, los datos son muy duraderos y no se espera que se pierdan 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 réplicas principales y de lectura en distintas zonas de disponibilidad habilitando Multi-AZ. En este caso, cuando se reemplaza un nodo, la función 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 a partir de sus componentes de durabilidad. Si su configuración incluye solo una réplica principal y una única 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 la sustitución 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. Los puntos de conexión de los nodos de réplica individuales se pueden 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 la función del nodo y actualizar todos los puntos de conexión de lectura para asegurarse de que no se está produciendo una carga importante en el nodo 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 del clúster de Redis/Valkey y que las solicitudes se pueden redirigir correctamente entre los nodos. Se recomienda implementar estrategias de interrupción y reintento para evitar sobrecargar los nodos de MemoryDB durante las actividades de mantenimiento y reemplazo.
Reprogramación: puede aplazar la actualización del 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 cambie el período de mantenimiento y haya pasado la fecha programada, la actualización del servicio se reprogramará para el período recién especificado en las semanas siguientes. Recibirá una nueva notificación una semana antes de que se alcance la nueva fecha.
La seguridad en AWS es una responsabilidad compartida. Le recomendamos encarecidamente que aplique la actualización lo antes posible.
Exclusión de las actualizaciones del servicio: para determinar si puede optar por no recibir una actualización del servicio, compruebe el valor del atributo “Fecha de inicio de la actualización automática”. Si se establece el valor del atributo “Fecha de inicio de la actualización automática” de una actualización de servicio, MemoryDB programará la actualización del servicio en los clústeres restantes para el próximo período de mantenimiento y no será posible excluirla. Sin embargo, si aplica la actualización del servicio a los clústeres restantes antes del período de mantenimiento, MemoryDB no volverá a aplicar la actualización del 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 del servicio durante los períodos de mantenimiento? - Tenga en cuenta que el objetivo de las actualizaciones del servicio es darle flexibilidad a la hora de 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 una frecuencia reducida durante todo el año. Sin embargo, se recomienda aplicar las actualizaciones para seguir cumpliendo con las normativas. Esto solo es cierto cuando el valor del atributo “Fecha de inicio de la actualización automática” de una actualización de servicio no está presente. 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 del servicio? - Las actualizaciones que se aplican mediante un mantenimiento gestionado continuo se programan directamente en sus períodos de mantenimiento sin que sea necesario que realice ninguna acción por su parte. Las actualizaciones del servicio están programadas y le permiten decidir cuándo desea solicitarlas 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 continuo del mantenimiento y tiempo de inactividad
¿Cuánto tiempo se tarde en sustituir un nodo? - Por lo general, la sustitución se completa en 30 minutos. La sustitución puede tardar más en algunas instancias, en las configuraciones y los 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 la sustitución de nodos. Consulte la sección anterior sobre el impacto y el tiempo de inactividad de las actualizaciones del servicio para obtener más información.
¿Cómo gestiono las sustituciones 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 usted mismo, puedes tomar varias medidas en función de su caso de uso.
Sustituya un nodo del clúster por una o más particiones: puede utilizar la copia de seguridad o el escalado horizontal para sustituir 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 un horario más conveniente, puede usar la API UpdateCluster, el comando update-cluster de la CLI 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 de estos clústeres esté configurado de manera que sea el mismo.
¿Cómo puedo informarme de las próximas sustituciones programadas? - Debería recibir una notificación de estado en el panel de estado de AWS. También puede encontrar el estado de las diferentes actualizaciones de servicios con la API DescribeServiceUpdates. Tenga en cuenta que nos esforzamos al máximo por notificar a los clientes de forma proactiva las posibles sustituciones. Sin embargo, en casos excepcionales, como fallos impredecibles, es posible que se produzcan sustituciones 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é realiza estas sustituciones de nodos? - Estas sustituciones son necesarias para aplicar las actualizaciones de software obligatorias al host subyacente. Estas actualizaciones ayudan a reforzar nuestra seguridad, la fiabilidad y el rendimiento operativo.
¿Estas sustituciones afectan al mismo tiempo a los nodos que se encuentran en varias zonas de disponibilidad y a los clústeres de distintas regiones? - Las sustituciones se pueden ejecutar en varias zonas o regiones de disponibilidad en paralelo, según el período de mantenimiento de los clústeres.