Principio del mecanismo centinela avanzado de alta disponibilidad de Redis

Principio del mecanismo centinela avanzado de alta disponibilidad de Redis

(I. Resumen

En el último artículo, hablamos principalmente sobre el contenido de la replicación maestro-esclavo de Redis, pero la replicación maestro-esclavo de Redis tiene una deficiencia. Cuando el maestro deja de funcionar, debemos resolverlo manualmente, como usar el esclavo de ningún comando. De hecho, la replicación maestro-esclavo no logra una verdadera alta disponibilidad. La alta disponibilidad se centra en las máquinas de respaldo, utilizando la redundancia del sistema en el clúster. Cuando una máquina en el sistema se daña, otras máquinas de respaldo pueden tomar el control rápidamente para iniciar el servicio. Obviamente, necesitamos un mecanismo para mejorar la replicación maestro-esclavo para que realmente pueda estar altamente disponible, por lo que se creó el modo centinela.

Redis Sentinel (Sentinel) es una arquitectura distribuida, que contiene varios nodos Sentinel y nodos de base de datos de Redis. Cada nodo de Sentinel monitorea el nodo de la base de datos y otros nodos de Sentinel. Cuando encuentra que el nodo es inaccesible, hará lo siguiente Logotipo de línea. Si se identifica el nodo principal, también "negociará" con otros nodos de Sentinel. Cuando la mayoría de los nodos de Sentinel piensan que el nodo principal es inalcanzable, elegirán un nodo de Sentinel para completar el trabajo de conmutación por error automático. La aplicación Redis será notificada de este cambio en tiempo real. Todo el proceso es completamente automático y no requiere intervención humana, por lo que esta solución resuelve eficazmente el problema de alta disponibilidad de Redis.

(Dos) proceso de conmutación por error

1. Fallo del nodo primario

El nodo maestro falla. En este momento, los dos nodos esclavos pierden la conexión con el nodo maestro y falla la replicación maestro-esclavo:

De acuerdo con la arquitectura general de replicación maestro-esclavo, necesitamos convertir manualmente un nodo esclavo en un nodo maestro. Pero con el modo centinela, podemos dejar que se haga de forma automática sin intervención manual.

2. Monitoreo multi-centinela

Cada nodo Sentinel descubre que el nodo principal ha fallado a través del monitoreo regular:

Cada Sentinel envía un comando PING al Maestro, Esclavo y otras instancias de Sentinel que conoce una vez por segundo. Si una instancia supera el valor especificado por la opción own-after-milliseconds de la última respuesta válida al comando PING, Sentinel marcará la instancia como subjetiva fuera de línea. Si un Maestro está marcado como subjetivamente fuera de línea, todos los Centinelas que están monitoreando a este Maestro deben confirmar que el Maestro efectivamente ha entrado en el estado subjetivo fuera de línea con una frecuencia de una vez por segundo. Cuando un número suficiente de Sentinel (mayor o igual al valor especificado en el archivo de configuración) confirme que el Maestro ha entrado en el estado subjetivo fuera de línea dentro del rango de tiempo especificado, el Maestro se marcará como objetivamente fuera de línea.

En general, cada Sentinel enviará un comando INFO a todos los Maestros y Esclavos que conozca con una frecuencia de una vez cada 10 segundos. Cuando Sentinel marca al Maestro como objetivamente fuera de línea, la frecuencia de envío de comandos INFO de todos los esclavos del Maestro fuera de línea por Sentinel cambiará de una vez cada 10 segundos a una vez cada segundo. Si no hay suficientes instancias de Sentinel para aceptar que el maestro se ha desconectado, se eliminará el estado objetivo fuera de línea del maestro. Si el Maestro devuelve una respuesta válida al comando Sentinel PING nuevamente, se eliminará el estado subjetivo fuera de línea del Maestro.

3. Elección de líderes

Después de descubrir la falla del nodo maestro, varios nodos Sentinel llegan a un acuerdo sobre la falla del nodo maestro y luego uno de los nodos será elegido como líder responsable de la operación de conmutación por error:

Cuando se considera que un servicio de redis está objetivamente fuera de línea, varios centinelas que supervisan el servicio negocian y eligen a un centinela líder para que sea responsable de las operaciones de conmutación por error del servicio de redis. El centinela líder electoral sigue las siguientes reglas:

• Todos los centinelas tienen las calificaciones para ser elegidos justamente como líderes.
• Todos los centinelas tienen y solo tienen una oportunidad de elegir a cierto centinela como líder (en una ronda de elecciones). Una vez que un cierto centinela es elegido como líder, no se puede cambiar.
• Sentinel establece al líder centinela por orden de llegada. Una vez que el centinela actual establece al líder centinela, otras solicitudes de centinela para convertirse en el líder en el futuro serán rechazadas.
• Cada centinela que descubra que el servicio está objetivamente fuera de línea le pedirá a otros centinelas que se establezcan como líderes.
• Cuando un centinela (centinela de origen) envía el comando is-master-down-by-addr ip port current_epoch runid a otro centinela (centinela de destino), el parámetro runid no es *, sino el ID de ejecución de centinela, lo que significa que el centinela de origen requiere el objetivo Sentinel lo eligió como líder.
• El centinela de origen verificará la respuesta del centinela objetivo a su solicitud de ser establecido como líder. Si el líder_runid y el líder_epoch devueltos son el centinela de origen, significa que el centinela objetivo acepta establecer el centinela de origen como líder.
• Si un centinela se establece como líder por más de la mitad de los centinelas, entonces el centinela se convierte en el líder.
• Si el líder centinela no es elegido dentro del límite de tiempo, se establecerá un período de tiempo tentativo para la elección.

Entonces, ¿por qué Redis diseña este proceso de selección de líderes? En pocas palabras, se debe a que solo un nodo centinela puede completar la conmutación por error.

4. Conmutación por error automática

El nodo líder de Sentinel realizó una operación de conmutación por error. Todo el proceso es básicamente el mismo que nuestro ajuste manual, pero se realiza automáticamente:

El llamado failover es la operación de seleccionar un esclavo adecuado para ser promovido al maestro cuando el maestro está inactivo, centinela lo completará automáticamente y no es necesario implementarlo manualmente. Una operación de conmutación por error se divide aproximadamente en los siguientes procesos:

• Descubrió que el servidor principal ha entrado en un estado objetivo fuera de línea.
• Incrementa el grupo actual e intenta ser elegido en este grupo.
• Si la elección falla, intentará ser elegido nuevamente después del doble del tiempo de espera de migración de falla establecido. Si tiene éxito, realice los siguientes pasos:
• Seleccione un servidor esclavo y actualícelo al servidor maestro.
• Envíe el comando SLAVEOF NADIE al servidor esclavo seleccionado para convertirlo en el servidor maestro.
• A través de la función de publicación y suscripción, la configuración actualizada se propaga a todos los demás Sentinels y los demás Sentinels actualizan sus propias configuraciones.
• Envíe el comando SLAVEOF a los servidores esclavos del servidor maestro fuera de línea para permitirles replicar el nuevo servidor maestro.
• Cuando todos los servidores esclavos han comenzado a replicar el nuevo servidor maestro, el líder Sentinel finaliza la operación de conmutación por error.

Siempre que se reconfigura una instancia de Redis, ya sea que esté configurada como un servidor maestro, un servidor esclavo o un servidor esclavo configurado para otro servidor maestro, Sentinel enviará un comando CONFIG REWRITE a la instancia reconfigurada, por lo tanto Asegúrese de que estas configuraciones persistan en el disco duro.

Los pasos anteriores mencionaron la selección de un nuevo nodo maestro. Echemos un vistazo a las reglas que usa Sentinel para seleccionar un nuevo servidor maestro:

• Entre los servidores esclavos bajo el servidor maestro fallado, se eliminarán aquellos que están marcados como subjetivamente fuera de línea, desconectados o la última vez que respondieron a un comando PING durante más de cinco segundos.
• Entre los servidores esclavos bajo el servidor maestro fallido, se eliminarán aquellos servidores esclavos que se han desconectado del servidor maestro fallido durante más de diez veces la duración especificada por la opción down-after.
• Después de pasar por las dos rondas de eliminación anteriores, seleccionamos el servidor esclavo con el mayor desplazamiento de replicación como el nuevo servidor maestro. Si el desplazamiento de replicación no está disponible, o el desplazamiento de replicación del servidor esclavo es el mismo, el servidor esclavo con el ID de ejecución más pequeño se convierte en el nuevo servidor maestro.

5. Reelección del nodo principal

Después de la conmutación por error, toda la estructura de Redis Sentinel reeligió un nuevo nodo maestro:

(3) Resumen

Sentinel es la garantía para que Redis alcance una alta disponibilidad. La función del sistema Sentinel es monitorear el clúster de servidores de Redis. Puede obtener continuamente el estado del clúster de redis. Cuando un nodo maestro deja de funcionar, la operación de conmutación por error seleccionará un nuevo nodo maestro de los nodos esclavos. Aquí, la conmutación por error es dirigida por Sentinel. Terminado.

No piense en Sentinel demasiado complicado, en realidad es un servidor Redis con un modo de trabajo especial. Redis se implementa en un clúster. Aquí Sentinel también debe implementarse en un clúster. Si es una implementación de un solo punto, Sentinel está inactivo. En este momento, el clúster de Redis Solo cuelga.

18 de septiembre de 2020