En esta página, se explica cómo Memorystore para Redis Cluster realiza 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 for Redis Cluster. Estas recomendaciones se aplican a los clústeres altamente disponibles y a los clústeres sin réplicas. Sin embargo, recomendamos la configuración de alta disponibilidad para todos los casos de uso de producción.
Memorystore para Redis Cluster actualiza las instancias de forma rutinaria para garantizar que el servicio sea confiable, seguro, esté actualizado y tenga un buen rendimiento. Estas actualizaciones se denominan mantenimiento. El servicio administra por completo el mantenimiento y está diseñado para no generar tiempo de inactividad.
Por lo general, el mantenimiento se clasifica en las siguientes categorías:
- Funciones de Memorystore. Para lanzar algunas funciones, Memorystore requiere una actualización de mantenimiento.
- Parches del sistema operativo. Supervisamos de forma continua las vulnerabilidades de seguridad recién identificadas en el sistema operativo. Después de la detección, aplicamos un parche al sistema operativo para protegerte de los riesgos nuevos.
- Parches de bases de datos. El mantenimiento puede incluir una actualización de Redis para mejorar las características de seguridad, rendimiento y confiabilidad de la instancia más allá de lo que proporciona Redis OSS.
Configura tu aplicación cliente
Para configurar tu aplicación cliente y obtener el mejor rendimiento y disponibilidad posibles durante el mantenimiento, sigue estos pasos:
- Usa y configura tu cliente de clúster de Redis OSS según la guía de prácticas recomendadas para clientes de Redis para asegurarte de que el mantenimiento programado no afecte tu aplicación cliente. Nuestras configuraciones de cliente recomendadas pueden evitar los restablecimientos de conexión a través de actualizaciones periódicas de la topología intercalada y rotaciones de conexión en segundo plano.
- Prueba tu aplicación cliente con una serie de operaciones de actualización (como el ajuste de escala hacia adentro o hacia afuera, o cambios en el recuento de réplicas) mientras ejecutas una carga de trabajo representativa en los nodos principales y de réplica, y supervisa el impacto en el cliente. Estas actualizaciones prueban la lógica de actualización de la topología intercalada en los clientes, el impacto de la sincronización completa, el descubrimiento de nodos nuevos y la capacidad de quitar nodos existentes. Las pruebas ayudan a garantizar que el cliente del clúster de Redis de OSS esté configurado correctamente para evitar cualquier impacto negativo en tu aplicación.
Mantenimiento programado
Memorystore for Redis Cluster aprovecha una estrategia de ciclo de vida de implementación gradual y de creación antes de la destrucción para evitar cualquier impacto de tiempo de inactividad causado por el mantenimiento. El mantenimiento sin tiempo de inactividad se logra utilizando las capacidades de redireccionamiento 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 correcta de nodos para permitir que los clientes se pongan al día con las actualizaciones de la topología del clúster sin afectar la disponibilidad
- El mantenimiento no afecta los extremos de Private Service Connect del clúster. Para obtener más información sobre estos extremos, consulta Extremos del clúster.
El comportamiento del servicio que se describe en las siguientes secciones se aplica solo al mantenimiento programado. Para obtener información sobre el impacto de los eventos no planificados, como las fallas de hardware, consulta Comportamiento del cliente durante una conmutación por error no planificada.
Estrategia de implementación gradual
Las implementaciones de mantenimiento de Memorystore for Redis Cluster se realizan con un alcance cada vez mayor y a un ritmo que permite detectar fallas con la suficiente anticipación para mitigar el impacto y establecer la confianza en la estabilidad. Los tiempos de confirmación (el tiempo durante el cual se aplica y supervisa la actualización antes de considerarla exitosa y continuar) se integran en toda la flota de clústeres de Memorystore a escala del servicio. Además, los tiempos de cocción se integran en el clúster en todas las zonas de una región (varios dominios de falla) para reducir el alcance del impacto, si lo hubiera.
En el caso de tu clúster configurado para alta disponibilidad, se actualiza, como máximo, un dominio de falla o una zona en un momento determinado para garantizar que un fragmento del clúster, incluidas las réplicas y la instancia principal, tenga alta disponibilidad durante toda la actualización. Además, solo se actualizan unos pocos nodos de Redis en un momento determinado. Las actualizaciones usan un mecanismo de ciclo de vida de crear antes de destruir para maximizar la estabilidad del clúster. Esta estrategia proporciona la mayor cantidad de beneficios cuando se actualiza un clúster con muchos fragmentos. Aplicar las actualizaciones solo a una pequeña parte del espacio de claves general del usuario en un momento determinado maximiza la disponibilidad de los datos.
Estrategia de ciclo de vida de crear antes de destruir
Un clúster de Redis tiene varios fragmentos. Cada fragmento tiene un nodo principal y cero o más nodos de réplica. Memorystore usa el siguiente proceso para actualizar cualquier nodo de Redis principal o de réplica existente en un fragmento:
- Primero, Memorystore for Redis Cluster agrega 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 existente, para garantizar que se conserve la capacidad aprovisionada en caso de una falla inesperada del proceso de arranque.
- Si un nodo dentro de la partición que se actualizará es un nodo principal, primero se convierte en una réplica antes de quitarlo con una conmutación por error coordinada.
- A continuación, Memorystore quita 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 de forma local, pero genera 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 primero aprovisiona una réplica nueva, coordina la conmutación por error y, por último, reemplaza el nodo principal existente de la partición.
Paso 1: Agrega una réplica de Redis
El primer paso del mecanismo de creación antes de la destrucción es agregar un nodo de réplica con el software más reciente usando el mecanismo de Redis OSS de sincronización completa para copiar los datos del nodo principal al nodo 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 escalamiento horizontal del clúster, puedes aprovisionar una mayor cantidad de fragmentos para reducir el tamaño del espacio de claves dentro de 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 principal coordinada
Si el nodo de Redis que se debe actualizar es un nodo principal, Memorystore primero ejecuta una conmutación por error coordinada al nodo de réplica agregado recientemente y, luego, continúa con la eliminación del nodo. Durante la conmutación por error coordinada, el cliente y los nodos de Redis trabajan en conjunto y usan las siguientes estrategias para evitar el tiempo de inactividad de la aplicación:
- Las solicitudes entrantes del cliente se bloquean temporalmente en el nodo principal, lo que proporciona una ventana para garantizar que la réplica existente esté sincronizada al 100% con el nodo 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 existentes y las redirecciona al nodo principal recién elegido con el protocolo de clúster de Redis de OSS. Las solicitudes nuevas que se envíen al nodo de réplica anterior seguirán redireccionándose al nodo principal nuevo.
- Tu cliente compatible con Redis Cluster actualiza su topología en la memoria. Aprende la dirección del nuevo extremo principal y ya no requiere redireccionamientos.
Por lo general, las conmutaciones por error coordinadas deberían 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 la convergencia en los nodos principales, lo que afecta la toma de decisiones sobre la elección del nuevo nodo principal.
Paso 3: Quita la réplica de Redis
El último paso del mecanismo de creación previa a la destrucción es quitar el nodo de réplica del software anterior. La eliminación abrupta de un nodo tendría un impacto en las aplicaciones cliente, ya que los clientes almacenan en caché la información del extremo y la topología del clúster. Memorystore for Redis Cluster diseñó la eliminación de una réplica de Redis para que sea correcta y permitir que las aplicaciones cliente actualicen su topología antes de experimentar un cierre forzado del nodo. La topología se personaliza para permitir que los clientes conozcan la nueva réplica. La topología también olvida la réplica que se quitará antes de que se quite.
El nodo de réplica que ejecuta el software anterior se mantiene durante un cierto período de vaciado, por lo general, del orden de minutos, durante el cual comienza a redireccionar las solicitudes de lectura entrantes al nodo principal de su fragmento. Permite que el cliente del clúster de Redis de OSS actualice la topología del clúster y obtenga información sobre los nuevos extremos de réplica. Si el cliente intenta acceder a un nodo quitado después del período de vaciado, el intento falla, lo que, a su vez, activa una actualización de la topología del clúster en el cliente del clúster para que conozca el cambio de réplica. Las actualizaciones nuevas de la topología del clúster no ven el nodo de réplica que se quitará.
Configuración de mantenimiento
Con Memorystore, puedes personalizar los programas de mantenimiento para que se alineen con las necesidades de tu aplicación y minimizar las interrupciones. Para ello, configura un período de mantenimiento para tu clúster.
Los períodos de mantenimiento se establecen por clúster de Memorystore y permiten las siguientes opciones de configuración:
- Día de la semana. Designa el día en que se realiza el mantenimiento.
- Hora de inicio. Hora en que comienza el mantenimiento.
El período de mantenimiento dura 1 hora. Ten en cuenta que, en algunos casos, el mantenimiento puede extenderse más allá del período que seleccionaste.
Una vez que se configura un período de mantenimiento para una instancia de clúster, el mantenimiento automático futuro se programará según las preferencias establecidas para los períodos de mantenimiento.
Períodos de mantenimiento predeterminados
Si no configuras un período de mantenimiento, Memorystore actualizará tu clúster en uno de los siguientes períodos según la zona horaria del clúster:
Período de días de la semana (de lunes a viernes) De 10 p.m. a 6 a.m.
Período de fin de semana. Del viernes a las 10 p.m. al lunes a las 6 a.m.
Ejemplo de mantenimiento
Como desarrollador que administra un servicio de carrito de compras en un comercio minorista, tienes la responsabilidad de supervisar un entorno de producción que incluye una instancia de Memorystore para Redis Cluster. Para garantizar un rendimiento óptimo durante el mantenimiento, debes programarlo para cuando el clúster experimente un tráfico mínimo, lo que suele ocurrir alrededor de la medianoche los domingos.
En este caso, puedes establecer el período de mantenimiento de tu clúster de producción de la siguiente manera:
- Día de la semana. Domingo
- Hora de inicio. 1 a.m.
Próximas notificaciones de mantenimiento
Para asegurarte de estar al tanto de los eventos de mantenimiento en tu clúster, puedes configurar notificaciones por correo electrónico sobre el próximo mantenimiento al menos una semana antes de que se programe. 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 comienza el mantenimiento del clúster. El asunto del correo electrónico sería "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]".
Cuando se completa el mantenimiento, se envía una notificación de finalización. El título del correo electrónico es "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]".
Si Memorystore reprograma el mantenimiento, recibirás un correo electrónico en el que se te notificará sobre la cancelación del mantenimiento. El asunto de este correo electrónico sería "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Debes habilitar la opción para recibir estas notificaciones de mantenimiento. Para registrarte y recibir notificaciones de mantenimiento, sigue los pasos que se indican a continuación:
Para recibir notificaciones de mantenimiento de Memorystore, asegúrate de completar los pasos anteriores al menos una semana antes de la actualización de mantenimiento programada para tu instancia. Si no lo haces, el sistema no tendrá tiempo suficiente para notificarte sobre el próximo mantenimiento.
Las notificaciones se enviarán a la dirección de correo electrónico asociada con tu Cuenta de Google. No se puede configurar un alias de correo electrónico personalizado (por ejemplo, un alias de correo electrónico del equipo). Por el momento, no admitimos el envío de notificaciones a otra dirección de correo electrónico.
Si te suscribes a las notificaciones de mantenimiento, recibirás alertas para todos los clústeres de Memorystore con mantenimiento programado dentro de un proyecto especificado. Si te suscribiste, recibirás una notificación independiente para cada clúster.
Para obtener instrucciones sobre cómo encontrar el mantenimiento programado, consulta Cómo encontrar el mantenimiento programado.
Reprograma el mantenimiento
En el caso en que se configuren períodos de mantenimiento para tu clúster, en esta sección, se proporcionan lineamientos sobre cómo reprogramar el mantenimiento. Por ejemplo, si se programó el lanzamiento de un servicio nuevo durante el período de mantenimiento actual, es posible que desees posponer el período de mantenimiento hasta unos días después del lanzamiento.
Puedes reprogramar el mantenimiento tantas veces como quieras dentro de las dos semanas posteriores a la hora programada originalmente. Cuando reprogrames la cita, puedes elegir una de las siguientes opciones:
- Actualizar ahora En lugar de esperar el período de mantenimiento programado, puedes aplicar las actualizaciones a tu clúster de inmediato.
- Día y hora personalizados Esto te permite elegir cualquier horario específico en un plazo de dos semanas a partir de la hora de mantenimiento programada originalmente.
Cuando reprogrames el mantenimiento, se aplicarán las siguientes restricciones:
- Si queda menos de una hora antes del horario de mantenimiento programado actual, no podrás reprogramar el mantenimiento.
- Cuando se reprograma correctamente, se envía un correo electrónico para confirmar la cancelación del mantenimiento anterior y se envía una nueva notificación del próximo mantenimiento con el programa actualizado.
Para obtener instrucciones sobre cómo reprogramar el mantenimiento, consulta Reprograma el mantenimiento.
Preguntas frecuentes
A continuación, se incluyen algunas preguntas frecuentes sobre la política de mantenimiento del clúster de Memorystore para Redis:
¿Cómo puedo saber cuándo se programa el mantenimiento de mi clúster?
Te recomendamos que te suscribas a las notificaciones y configures un período de mantenimiento para saber cuándo está programado el mantenimiento para tu instancia. También puedes verificar manualmente con Find Scheduled Maintenance para ver si el campo maintenance_schedule está configurado en la respuesta.
¿Cuándo se me notifica sobre el próximo mantenimiento?
Si te suscribiste para recibir notificaciones de mantenimiento y configuraste un período de mantenimiento, recibirás una alerta por correo electrónico al menos 1 semana antes de un evento de mantenimiento.
¿Por cuánto tiempo puedo diferir el mantenimiento?
Una vez que se programó el mantenimiento de tu clúster, puedes iniciar la actualización de inmediato o aplazarla hasta 2 semanas desde la hora de mantenimiento programada en un principio. Por ejemplo, si el mantenimiento está programado para el 11 de octubre a las 11:15 p.m., puedes diferir el mantenimiento hasta el 25 de octubre a las 11:15 p.m. El mantenimiento se aplicará a la hora programada si no se realiza ninguna acción.
Para obtener más detalles, consulta Reprograma el mantenimiento.
¿Qué prácticas recomendadas debo seguir para tener una experiencia de actualización de mantenimiento sin problemas?
Te recomendamos que realices las siguientes acciones para garantizar una experiencia de actualización de mantenimiento sin problemas:
- Sigue las instrucciones para configurar tu aplicación cliente.
- Debes configurar tu período de mantenimiento para un momento en el que se garantice que el mantenimiento no se aplique en las horas pico de uso de Redis.
- Debes habilitar las notificaciones de mantenimiento para recibir alertas por correo electrónico al menos siete días antes de que se programe la actualización de mantenimiento de tu instancia.
- Si no tienes una hora de impacto bajo o nulo para el uso de tu aplicación, te recomendamos que uses la configuración predeterminada del servicio de lanzamientos graduales, que incluye prácticas recomendadas. Para obtener más información, consulta Mantenimiento programado.
¿Cuándo debo aplicar el mantenimiento de inmediato?
Una situación en la que podrías aplicar la actualización de mantenimiento de inmediato es en un clúster de prueba para ver cómo afecta a tu aplicación. Esto te permite observar el impacto que tiene y aplazar el mantenimiento en los clústeres de producción según sea necesario o esté permitido.
También puedes programar el mantenimiento de inmediato si la hora actual es adecuada para tu clúster y esperas una carga alta en el futuro.
¿Siempre se completan las actualizaciones de mantenimiento dentro del período de mantenimiento?
Una actualización comienza dentro del período de mantenimiento que especifiques. Por lo general, la actualización se completa dentro del período, pero esto no está garantizado.
¿Puedo inhabilitar el mantenimiento o programar el mantenimiento en ciertos clústeres primero?
No, no puedes inhabilitar el mantenimiento ni controlar el orden del mantenimiento de tus clústeres. Sin embargo, una vez que recibas la notificación de mantenimiento inicial, puedes reprogramar el mantenimiento para diferirlo hasta por 2 semanas.
¿Qué sigue?
- Consulta los permisos necesarios para administrar los períodos de mantenimiento de tu clúster de Redis.