En esta página, se explica cómo Memorystore para Valkey 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 para Valkey. Estas recomendaciones se aplican a las instancias de alta disponibilidad y a las instancias sin réplicas. Sin embargo, recomendamos la configuración de alta disponibilidad para todos los casos de uso de producción.
Memorystore para Valkey actualiza las instancias de forma periódica para garantizar que el servicio sea confiable, tenga un buen rendimiento, sea seguro y esté actualizado. Estas actualizaciones se denominan mantenimiento. El servicio administra completamente el mantenimiento y está diseñado para no tener ningún impacto en el 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 continuamente las vulnerabilidades de seguridad recientemente identificadas en el sistema operativo. Luego del descubrimiento, aplicamos un parche en el sistema operativo para protegerte de riesgos nuevos.
- Parches de la base de datos. El mantenimiento puede incluir una actualización de Valkey para mejorar las características de seguridad, rendimiento y confiabilidad de la instancia más allá de lo que proporciona el Valkey de 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 terceros según la guía de Prácticas recomendadas para clientes a fin de asegurarte de que el mantenimiento programado no afecte la aplicación cliente. Nuestras configuraciones de cliente recomendadas pueden evitar los restablecimientos de conexión a través de actualizaciones periódicas de 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 reducir o reducir la escala verticalmente, y 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, la detección de nodos nuevos y la capacidad de eliminación de nodos existentes. Las pruebas te ayudan a garantizar que el cliente de terceros esté configurado correctamente para evitar cualquier impacto negativo en tu aplicación.
Mantenimiento programado
Memorystore for Valkey aprovecha una implementación gradual y una estrategia de ciclo de vida de creación antes de la destrucción para evitar cualquier impacto en el tiempo de inactividad del mantenimiento programado de Memorystore en tus instancias de Valkey. El mantenimiento sin tiempo de inactividad se logra usando las capacidades de redireccionamiento de solicitudes del protocolo de clúster de OSS Valkey 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 de nodo sin ningún impacto en la disponibilidad
- Los extremos de PSC de la instancia no se ven afectados por el mantenimiento. Para obtener más información sobre los extremos de PSC, consulta Extremos de instancias.
El comportamiento del servicio descrito 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.
Períodos de mantenimiento predeterminados
De forma predeterminada, Memorystore actualiza tu instancia en los siguientes entornos: ventanas según la zona horaria de tu instancia:
Período de días de la semana (de lunes a viernes): De 10 p.m. a 6 a.m.
Período de fines de semana: Del viernes a las 10 p.m. al lunes a las 6 a.m.
Estrategia de implementaciones graduales
Las implementaciones de Memorystore para Valkey se realizan con un alcance que aumenta de forma progresiva y a una velocidad que permite detectar fallas con la suficiente antelación para mitigar el impacto y establecer la confianza en la estabilidad. Los tiempos de preparación (el tiempo durante el cual se aplica y supervisa la actualización antes de considerarla un éxito y continuar) se integran en la flota de instancias de Memorystore a escala del servicio. Además, los tiempos de preparación se integran en las instancias de distintas zonas de una región (múltiples dominios con fallas) para reducir el alcance del impacto, si lo hubiera.
En el caso de las instancias configuradas para alta disponibilidad, se actualiza como máximo un dominio o una zona con fallas en cualquier momento para garantizar que una instancia fragmentada, incluidas la principal y la réplica, tenga alta disponibilidad durante la actualización. Además, solo se actualizan unos pocos nodos de Valkey en un momento determinado. Las actualizaciones usan un mecanismo de ciclo de vida de creación antes de destrucción para maximizar la estabilidad de la instancia. Esta estrategia proporciona los mayores beneficios cuando se actualiza una instancia con muchos fragmentos. Aplicar solo las actualizaciones 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
Una instancia de Valkey 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 Valkey principal o réplica existente en un fragmento:
- Memorystore for Valkey primero agrega una réplica completamente nueva con la actualización de software más reciente para el fragmento. Memorystore crea un nodo completamente nuevo, en lugar de actualizar uno existente, para garantizar que tu capacidad aprovisionada se conserve en caso de una falla de arranque inesperada.
- Si un nodo dentro del fragmento que se actualizará es un nodo principal, primero se convierte en una réplica antes de quitarlo con una conmutación por error coordinada.
- Luego, Memorystore quita la réplica que usa el software anterior.
- El proceso se repite para cada nodo de la instancia.
La estrategia de crear antes de destruir ayuda a retener la capacidad aprovisionada de la instancia, en comparación con una implementación continua típica que se actualiza de forma in situ, pero genera una interrupción de disponibilidad (y, a veces, pérdida de datos) para la aplicación cliente. En el caso de los fragmentos sin réplicas, Memorystore para Valkey sigue aprovisionando una réplica nueva primero, coordina la conmutación por error y, por último, reemplaza el nodo principal existente del fragmento.
Paso 1: Agrega una réplica de Valkey
El primer paso del mecanismo crear antes de la destrucción es agregar un nodo de réplica con el software más reciente a través del mecanismo de sincronización completa de OSS Valkey para copiar los datos del nodo principal al de réplica. Para ello, se crea un proceso secundario y se aprovecha la replicación sin disco para iniciar la réplica.
Puedes aprovechar mejor la arquitectura de escala horizontal de la instancia aprovisionando 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 la 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 Valkey que se debe actualizar es uno principal, Memorystore primero ejecuta una conmutación por error coordinada en el nodo de réplica recién agregado y, luego, procede con la eliminación del nodo. Durante la conmutación por error coordinada, el cliente y los nodos de Valkey trabajan juntos y usan las siguientes estrategias para evitar el tiempo de inactividad en la aplicación:
- Las solicitudes de clientes entrantes se bloquean temporalmente en el nodo principal, lo que proporciona un período para garantizar que la réplica existente esté 100% sincronizada con la 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 principal elegido recientemente con el protocolo de clúster de Valkey de OSS. Las solicitudes nuevas que se envíen al nodo de réplica anterior se seguirán redireccionando al nuevo nodo principal.
- Tu cliente compatible con Valkey actualiza su topología en memoria. Aprende la dirección del nuevo extremo principal y ya no requiere redireccionamientos.
Las conmutaciones por error coordinadas suelen tardar decenas de milisegundos. Sin embargo, los datos en tránsito pendientes de vaciado a réplicas y el tamaño total de tu instancia pueden aumentar la latencia de conmutación por error. El tamaño de la instancia puede afectar la convergencia entre los nodos principales, lo que afecta la toma de decisiones sobre la elección de la nueva instancia principal.
Paso 3: Quita la réplica de Valkey
El último paso del mecanismo de creación antes de destruir es quitar el nodo de réplica del software anterior. Una eliminación abrupta de nodos tendría un impacto en las aplicaciones cliente, ya que los clientes almacenan en caché la información del extremo y la topología de la instancia. Memorystore for Valkey diseñó la eliminación de una réplica de Valkey para que sea correcta a fin de permitir que las aplicaciones cliente actualicen su topología antes de experimentar el cierre de un nodo por presión. La topología se personaliza para permitir que los clientes conozcan la réplica nueva, pero también olviden la que se quitará con anticipación.
El nodo de réplica que ejecuta el software anterior se mantiene durante un período de drenaje determinado, por lo general, de unos minutos, durante el cual comienza a redireccionar las solicitudes de lectura entrantes al nodo principal de su fragmento. Permite que el cliente externo actualice la topología del nodo y obtenga información sobre los nuevos extremos de réplica. Si el cliente intenta llegar 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 de nodo en el cliente que se conecta para que aprenda sobre el cambio de réplica. Las nuevas actualizaciones de la topología de nodos no ven el nodo de réplica que se quitará.