En esta página se explica cómo realiza Memorystore for Redis Cluster el mantenimiento de las instancias. También proporciona información y recomendaciones de configuración que tus aplicaciones cliente deben tener en cuenta para aprovechar el diseño de mantenimiento sin tiempo de inactividad de Memorystore para Redis Cluster. Estas recomendaciones se aplican tanto a los clústeres de alta disponibilidad como a los que no tienen réplicas. Sin embargo, te recomendamos que uses la configuración de alta disponibilidad en todos los casos prácticos de producción.
Memorystore for Redis Cluster actualiza las instancias de forma periódica para asegurarse de que el servicio sea fiable, tenga un buen rendimiento, sea seguro y esté actualizado. Estas actualizaciones se denominan mantenimiento. El servicio gestiona el mantenimiento por completo y está diseñado para que no afecte al tiempo de inactividad.
El mantenimiento suele clasificarse en las siguientes categorías:
- Funciones de Memorystore. Para lanzar algunas funciones, Memorystore requiere una actualización de mantenimiento.
- Parches del sistema operativo. Monitorizamos continuamente las vulnerabilidades de seguridad recién identificadas en el sistema operativo. Cuando las detectamos, aplicamos parches al sistema operativo para protegerte de los nuevos riesgos.
- Parches de bases de datos. El mantenimiento puede incluir una actualización de Redis para mejorar las características de seguridad, rendimiento y fiabilidad de la instancia más allá de lo que ofrece Redis OSS.
Configurar la aplicación cliente
Para configurar su aplicación cliente de forma que tenga el mejor rendimiento y la mayor disponibilidad posibles durante el mantenimiento, siga estos pasos:
- Usa y configura tu cliente de clúster Redis de software libre siguiendo las directrices de las prácticas recomendadas para clientes de Redis para asegurarte de que el mantenimiento programado no afecte a tu aplicación cliente. Nuestras configuraciones de cliente recomendadas pueden evitar que se restablezcan las conexiones mediante actualizaciones periódicas de la topología insertada y rotaciones de conexiones en segundo plano.
- Prueba tu aplicación cliente con una serie de operaciones de actualización (como aumentar o reducir la escala, o cambiar el número de réplicas) mientras ejecutas una carga de trabajo representativa en los nodos primario y de réplica, y monitoriza el impacto en el cliente. Estas actualizaciones prueban la lógica de actualización de la topología insertada en los clientes, el impacto de la sincronización completa, el descubrimiento de nodos nuevos y la capacidad de eliminar nodos. Las pruebas ayudan a asegurarse de que el cliente del clúster de Redis de software libre esté configurado correctamente para evitar que tu aplicación se vea afectada negativamente.
Mantenimiento programado
Memorystore for Redis Cluster utiliza una estrategia de ciclo de vida de implementación gradual y de creación antes de la destrucción para evitar que el mantenimiento provoque periodos de inactividad. El mantenimiento sin tiempo de inactividad se consigue usando las funciones de redirección de solicitudes del protocolo de clúster de Redis OSS junto con los siguientes mecanismos de Memorystore:
- Conmutación por error coordinada sin pérdida de datos.
- Eliminación de nodos gradual para que los clientes puedan ponerse al día con las actualizaciones de la topología del clúster sin que se vea afectada la disponibilidad.
- El mantenimiento no afecta a los endpoints de Private Service Connect del clúster. Para obtener más información sobre estos endpoints, consulta el artículo Endpoints de clústeres.
El comportamiento del servicio que se describe en las siguientes secciones solo se aplica al mantenimiento programado. Para obtener información sobre el impacto de eventos imprevistos, como fallos de hardware, consulta Comportamiento del cliente durante una conmutación por error imprevista.
Estrategia de despliegue gradual
Las implementaciones de mantenimiento de Memorystore for Redis Cluster se realizan con un ámbito que aumenta progresivamente y a un ritmo que permite detectar los errores con la suficiente antelación para mitigar el impacto y generar confianza en la estabilidad. Los tiempos de cocción (el tiempo durante el cual se aplica y se monitoriza la actualización antes de considerarla correcta y continuar) se integran en toda la flota de clústeres de Memorystore a escala de servicio. Además, los tiempos de compilación se integran en el clúster de las zonas de una región (varios dominios de errores) para reducir el alcance del impacto, si lo hay.
En el caso de los clústeres configurados para alta disponibilidad, se actualiza como máximo un dominio de error o una zona en un momento dado para asegurarse de que un fragmento de clúster, incluidas las réplicas y la instancia principal, tenga alta disponibilidad durante la actualización. Además, solo se actualizan unos pocos nodos de Redis en un momento dado. Las actualizaciones usan un mecanismo de ciclo de vida de creación antes de destrucción para maximizar la estabilidad del clúster. Esta estrategia ofrece las mayores ventajas al actualizar un clúster con muchos fragmentos. Aplicar las actualizaciones solo a una pequeña parte del espacio de claves de usuario en un momento dado maximiza la disponibilidad de los datos.
Estrategia de ciclo de vida de creación antes de destrucción
Un clúster de Redis tiene varios fragmentos. Cada fragmento tiene un nodo principal y cero o más nodos de réplica. Memorystore sigue este proceso para actualizar cualquier nodo de Redis principal o de réplica de un fragmento:
- Memorystore for Redis Cluster primero añade una réplica completamente nueva con la actualización de software más reciente al fragmento. Memorystore crea un nodo completamente nuevo, en lugar de actualizar uno ya creado, para asegurarse de que la capacidad aprovisionada se conserve en caso de que se produzca un error inesperado en el arranque.
- Si un nodo de la partición que se va a actualizar es un nodo principal, primero se convierte en una réplica antes de eliminarse mediante una conmutación por error coordinada.
- A continuación, Memorystore elimina la réplica que usa el software anterior.
- El proceso se repite para cada nodo del clúster.
La estrategia de crear antes de destruir ayuda a conservar la capacidad aprovisionada del clúster, en comparación con una implementación continua típica que se actualiza in situ, pero provoca una interrupción de la disponibilidad (y, a veces, pérdida de datos) para la aplicación cliente. En el caso de las particiones sin réplicas, Memorystore for Redis Cluster sigue aprovisionando primero una réplica nueva, coordina la conmutación por error y, por último, sustituye el nodo principal de la partición.
Paso 1: Añade una réplica de Redis
El primer paso del mecanismo de creación antes de destruir consiste en añadir un nodo de réplica con el software más reciente mediante el mecanismo de sincronización completa de Redis OSS para copiar los datos del nodo principal al de réplica. Para ello, se bifurca un proceso secundario y se aprovecha la replicación sin disco para iniciar la réplica.
Para aprovechar al máximo la arquitectura de escalado horizontal del clúster, puedes aprovisionar un mayor número de fragmentos para reducir el tamaño del espacio de claves en un nodo. Tener un conjunto de datos más pequeño por nodo ayuda a reducir el impacto de la latencia de bifurcación de una operación de sincronización completa. También acelera la copia de datos entre los nodos.
Paso 2: Conmutación por error primaria coordinada
Si el nodo de Redis que se va a actualizar es un nodo principal, Memorystore primero ejecuta una conmutación por error coordinada al nodo de réplica recién añadido y, a continuación, procede a la eliminación del nodo. Durante la conmutación por error coordinada, el cliente y los nodos de Redis trabajan juntos y usan las siguientes estrategias para evitar que la aplicación se quede inactiva:
- Las solicitudes de clientes entrantes se bloquean temporalmente en el nodo principal, lo que proporciona un periodo para asegurarse de que la réplica esté sincronizada al 100% con el principal.
- La réplica completa el proceso de elección para asumir el rol principal.
- El nodo principal anterior, ahora una réplica, desbloquea las solicitudes actuales y las redirige al nodo principal recién elegido mediante el protocolo de clúster de Redis de OSS. Las nuevas solicitudes que se envíen al nodo de réplica anterior seguirán redirigiéndose al nuevo nodo principal.
- Tu cliente compatible con Redis Cluster actualiza su topología en memoria. Aprende la dirección del nuevo endpoint principal y ya no necesita redirecciones.
Las conmutaciones por error coordinadas suelen tardar decenas de milisegundos. Sin embargo, el tamaño total del clúster puede aumentar la latencia de conmutación por error. También pueden hacerlo los datos en tránsito pendientes de vaciarse en las réplicas. El tamaño del clúster puede afectar a la convergencia entre los nodos principales, lo que influye en la toma de decisiones sobre la elección del nuevo nodo principal.
Paso 3: Elimina la réplica de Redis
El último paso del mecanismo de creación antes de la destrucción consiste en eliminar el nodo de réplica del software anterior. Si se elimina un nodo de forma abrupta, las aplicaciones cliente se verían afectadas, ya que almacenan en caché la información del endpoint y la topología del clúster. Memorystore for Redis Cluster ha diseñado la eliminación de una réplica de Redis para que sea gradual y permita que las aplicaciones cliente actualicen su topología antes de que se cierre un nodo de forma brusca. La topología se personaliza para que los clientes puedan obtener información sobre la nueva réplica. La topología también olvida la réplica que se va a eliminar antes de que se elimine.
El nodo de réplica que ejecuta el software anterior se mantiene durante un periodo de purga determinado, normalmente de unos minutos, durante el cual empieza a redirigir las solicitudes de lectura entrantes al nodo principal de su partición. Permite que el cliente del clúster de Redis de software libre actualice la topología del clúster y obtenga información sobre los nuevos endpoints de réplica. Si el cliente intenta acceder a un nodo eliminado después del periodo de drenaje, el intento fallará, lo que a su vez activará una actualización de la topología del clúster en el cliente del clúster para que se entere del cambio de réplica. Las nuevas actualizaciones de la topología del clúster no ven el nodo de réplica que se va a eliminar.
Ajustes de mantenimiento
Con Memorystore, puedes personalizar las programaciones de mantenimiento para que se ajusten a las necesidades de tu aplicación y minimizar las interrupciones. Para ello, configura una ventana de mantenimiento para tu clúster.
Las ventanas de mantenimiento se definen por clúster de Memorystore y permiten las siguientes opciones de configuración:
- Día de la semana. Designa el día en el que se realiza el mantenimiento.
- Hora de inicio. La hora a la que empieza el mantenimiento.
La duración de la ventana de mantenimiento es de 1 hora. Ten en cuenta que, en algunos casos, el mantenimiento puede prolongarse más allá del periodo que hayas seleccionado.
Una vez que se haya configurado una ventana de mantenimiento para una instancia de clúster, el mantenimiento automático futuro se programará de acuerdo con las preferencias definidas para las ventanas de mantenimiento.
Ventanas de mantenimiento predeterminadas
Si no configuras una ventana de mantenimiento, Memorystore actualizará tu clúster en una de las siguientes ventanas de tiempo según la zona horaria del clúster:
Ventana de días laborables (de lunes a viernes). De 22:00 a 6:00
Ventana de fin de semana. Viernes, de 22:00 a lunes, 6:00
Ejemplo de mantenimiento
Como desarrollador que gestiona un servicio de carrito de la compra en un comercio, tienes la responsabilidad de supervisar un entorno de producción que incluya una instancia de Memorystore para Redis Cluster. Para asegurar un rendimiento óptimo durante el mantenimiento, quieres programarlo para cuando el clúster tenga el mínimo tráfico posible, lo que suele ocurrir alrededor de la medianoche de los domingos.
En este caso, puedes definir la ventana de mantenimiento de tu clúster de producción de la siguiente manera:
- Día de la semana. Domingo.
- Hora de inicio. 1:00.
Notificaciones de mantenimiento programado
Para estar al tanto de los eventos de mantenimiento de tu clúster, puedes configurar notificaciones por correo electrónico sobre el mantenimiento programado al menos una semana antes de que se lleve a cabo. Estas notificaciones tendrán el asunto "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".
También se envía una notificación cuando empieza el mantenimiento de tu clúster. El asunto del correo sería "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]".
Cuando finalice el mantenimiento, se enviará una notificación. El título del correo es "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]".
Si Memorystore reprograma el mantenimiento, recibirás un correo en el que se te notificará la cancelación. El asunto de este correo sería "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Debes habilitar la opción para recibir estas notificaciones de mantenimiento. Para suscribirte a las notificaciones de mantenimiento, sigue los pasos que se indican a continuación:
Para recibir notificaciones de mantenimiento de Memorystore, asegúrate de haber completado los pasos anteriores al menos una semana antes de la actualización de mantenimiento programada de tu instancia. Si no lo haces, el sistema no tendrá tiempo suficiente para notificarte el mantenimiento programado.
Las notificaciones se enviarán a la dirección de correo asociada a tu cuenta de Google. No es posible configurar un alias de correo personalizado (por ejemplo, un alias de correo de equipo). Por el momento, no se pueden enviar notificaciones a otra dirección de correo electrónico.
Si te suscribes a las notificaciones de mantenimiento, recibirás alertas de todos los clústeres de Memorystore que tengan programado un mantenimiento en un proyecto específico. Si te suscribes, recibirás una notificación independiente por cada clúster.
Para obtener instrucciones sobre cómo encontrar el mantenimiento programado, consulta Buscar mantenimiento programado.
Reprogramar el mantenimiento
En el caso de que las ventanas de mantenimiento estén configuradas en tu clúster, en esta sección se proporcionan directrices sobre cómo reprogramar el mantenimiento. Por ejemplo, si se va a lanzar un nuevo servicio durante tu ventana de mantenimiento actual, puede que quieras posponerla hasta unos días después del lanzamiento.
Puedes reprogramar el mantenimiento tantas veces como quieras en un plazo de dos semanas a partir de la hora programada originalmente. Puedes elegir una de las siguientes opciones al reprogramar la cita:
- Actualizar ahora. En lugar de esperar a la ventana de mantenimiento programada, puedes aplicar las actualizaciones a tu clúster inmediatamente.
- Día y hora personalizados. De esta forma, puedes elegir cualquier momento concreto en un plazo de dos semanas a partir de la hora de mantenimiento programada originalmente.
Al reprogramar el mantenimiento, se aplican las siguientes restricciones:
- Si queda menos de una hora para la hora de mantenimiento programada, no podrás reprogramarlo.
- Si se reprograma correctamente, se envía un correo para confirmar la cancelación del mantenimiento anterior y una nueva notificación del próximo mantenimiento con la programación actualizada.
Para obtener instrucciones sobre cómo reprogramar el mantenimiento, consulta Reprogramar el mantenimiento.
Preguntas frecuentes
A continuación, se incluyen algunas preguntas frecuentes sobre la política de mantenimiento de Memorystore para Redis Cluster:
¿Cómo puedo saber cuándo se ha programado el mantenimiento de mi clúster?
Te recomendamos que te suscribas a las notificaciones y configures una ventana de mantenimiento para saber cuándo se ha programado el mantenimiento de tu instancia. También puedes comprobarlo manualmente con Find Scheduled Maintenance para ver si el campo maintenance_schedule está definido en la respuesta.
¿Cuándo se me notifica el mantenimiento programado?
Si te has suscrito a las notificaciones de mantenimiento y has configurado una ventana de mantenimiento, recibirás un correo al menos una semana antes de que se produzca un evento de mantenimiento.
¿Durante cuánto tiempo puedo aplazar el mantenimiento?
Una vez que se haya programado el mantenimiento de tu clúster, podrás iniciar la actualización de tu instancia inmediatamente o aplazarla hasta 2 semanas a partir de la hora de mantenimiento programada originalmente. Por ejemplo, si el mantenimiento está programado para el 11 de octubre a las 23:15, puedes aplazarlo hasta el 25 de octubre a las 23:15. El mantenimiento se aplicará a la hora programada si no se toma ninguna medida.
Para obtener más información, consulta Reprogramar el mantenimiento.
¿Qué prácticas recomendadas debo seguir para disfrutar de una experiencia de actualización de mantenimiento fluida?
Te recomendamos que tomes las siguientes medidas para que la experiencia de actualización y mantenimiento sea fluida:
- Sigue las instrucciones para configurar tu aplicación cliente.
- Debes definir tu ventana de mantenimiento en un momento en el que no se aplique el mantenimiento durante las horas punta de uso de Redis.
- Debes habilitar las notificaciones de mantenimiento para recibir un correo al menos siete días antes de que se programe una actualización de mantenimiento para tu instancia.
- Si no tienes una hora de bajo impacto o sin impacto para el uso de tu aplicación, te recomendamos que utilices el valor predeterminado del servicio de los lanzamientos graduales, que incorpora prácticas recomendadas. Para obtener más información, consulta Mantenimiento programado.
¿Cuándo debo aplicar el mantenimiento inmediatamente?
Un caso en el que podrías aplicar la actualización de mantenimiento inmediatamente es en un clúster de prueba para ver cómo afecta a tu aplicación. De esta forma, puedes observar el impacto que tiene y aplazar el mantenimiento de los clústeres de producción según sea necesario o permitido.
También puedes programar el mantenimiento inmediatamente si la hora actual te viene bien y prevés que tu clúster tendrá una carga alta en el futuro.
¿Las actualizaciones de mantenimiento siempre se completan dentro de la ventana de mantenimiento?
Una actualización se inicia dentro de la ventana de mantenimiento que especifiques. La actualización suele completarse en ese periodo, pero no se garantiza.
¿Puedo inhabilitar el mantenimiento o programarlo primero en determinados clústeres?
No, no puedes inhabilitar el mantenimiento ni controlar el orden de mantenimiento de tus clústeres. Sin embargo, cuando recibas la notificación inicial de mantenimiento, podrás reprogramar el mantenimiento para aplazarlo hasta 2 semanas.
Siguientes pasos
- Consulta los permisos necesarios para gestionar las ventanas de mantenimiento de tu clúster de Redis.