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 incluye en las siguientes categorías:
- Funciones de Memorystore. Para iniciar 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 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 la mayor disponibilidad posible durante el mantenimiento, sigue estos pasos:
- Usa y configura tu cliente externo según las instrucciones que se indican en Prácticas recomendadas para clientes para asegurarte de que cualquier mantenimiento programado no afecte a 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 escalamiento hacia arriba o hacia abajo, cambios en el recuento de réplicas) mientras ejecutas una carga de trabajo representativa en nodos principales y de réplicas, y supervisa el impacto en el cliente. Estas actualizaciones prueban la lógica de actualización de 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 externo esté configurado correctamente para evitar cualquier impacto negativo en tu aplicación.
Mantenimiento programado
Memorystore for Valkey aprovecha una estrategia de ciclo de vida de creación antes de destrucción y una implementación gradual para evitar cualquier impacto del tiempo de inactividad del mantenimiento programado de Memorystore en tus instancias de Valkey. El mantenimiento sin tiempo de inactividad se logra mediante las capacidades de redireccionamiento de solicitudes del protocolo de clúster de Valkey de OSS junto con los siguientes mecanismos de Memorystore:
- Conmutación por error coordinada sin pérdida de datos
- Eliminación elegante de nodos para permitir que los clientes se pongan al día con las actualizaciones de la topología de nodos 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 que se describe en las siguientes secciones solo se aplica a los mantenimientos programados. 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 períodos según la zona horaria de la 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 compilación se integran en las instancias de las zonas de una región (varios dominios de fallas) para reducir el alcance del impacto, si lo hubiera.
En el caso de tu instancia configurada para alta disponibilidad, se actualiza como máximo un dominio o zona de fallas en un momento determinado para garantizar que un fragmento de instancia, incluidas las réplicas y la principal, tenga alta disponibilidad durante la actualización. Además, solo se actualizan algunos 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 de réplica existente en un fragmento:
- Memorystore para Valkey primero 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 retenga la capacidad aprovisionada en caso de que se produzca una falla inesperada de inicio.
- 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.
- A continuación, 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 de creación antes de la destrucción es agregar un nodo de réplica con el software más reciente mediante el mecanismo de Valkey de OSS de sincronización completa 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.
Para aprovechar al máximo la arquitectura de escalamiento horizontal de la instancia, aprovisiona 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 primaria coordinada
Si el nodo de Valkey 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 Valkey trabajan juntos y usan las siguientes estrategias para evitar el tiempo de inactividad de 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.
Por lo general, las conmutaciones por error coordinadas deben tardar decenas de milisegundos. Sin embargo, los datos en tránsito pendientes de borrarse en las réplicas y el tamaño total de la 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 para elegir el nuevo principal.
Paso 3: Quita la réplica de Valkey
El último paso del mecanismo de creación antes de la destrucción es quitar el nodo de réplica en el 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 para Valkey diseñó la eliminación de una réplica de Valkey para que sea elegante y permita que las aplicaciones cliente actualicen su topología antes de experimentar un cierre de nodo duro. 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 conectarse a un nodo quitado después del período de drenaje, el intento fallará, lo que, a su vez, activará una actualización de la topología del nodo en el cliente que se conecta para que conozca el cambio de réplica. Las nuevas actualizaciones de la topología de nodos no ven el nodo de réplica que se quitará.