Redis Sentinel es un sistema distribuido diseñado para supervisar instancias de Redis en una arquitectura de replicación (Maestro-Esclavo). Su función principal es garantizar la alta disponibilidad mediante la monitorización constante, el envío de notificaciones y la ejecución de procesos automáticos de recuperación ante fallos.

Funciones Principales del Centinela

• Monitorización: Verifica de forma continua si los nodos maestros y sus réplicas operan correctamente.
• Notificación: Informa a otros procesos o administradores mediante una API cuando se detecta una anomalía en alguno de los nodos monitorizados.
• Conmutación por error (Failover) automática: Si un nodo maestro falla, Sentinel inicia un proceso de votación para promover una réplica a maestro, reconfigura las demás réplicas para que sigan al nuevo líder e informa a las aplicaciones sobre la nueva dirección IP.

Es importante destacar que el proceso Sentinel funciona como un servidor Redis especializado que no almacena datos de usuario. Para garantizar la integridad del sistema de votación, se recomienda desplegar un número impar de centinelas (mínimo 3).

Configuración y Despliegue

Para habilitar este modo, es necesario contar con una estructura previa de replicación. Una vez configurado el esquema maestro-esclavo, se procede a iniciar los procesos centinela utilizando archivos de configuración específicos.

# Ejemplo de inicio de un nodo Sentinel
redis-sentinel /etc/redis/sentinel_26379.conf

Un archivo de configuración básico (sentinel.conf) define a quién monitorear y bajo qué condiciones considerar que el maestro ha caído:

# Ejemplo de directiva principal
# sentinel monitor <nombre-master> <ip> <puerto> <quorum>
sentinel monitor mi-cluster 127.0.0.1 6379 2

Arquitectura de Funcionamiento

El ciclo de vida de Redis Sentinel se divide en tres etapas operativas críticas: Monitoreo, Notificación y Failover.

1. Fase de Monitoreo y Descubrimiento

En esta etapa, los centinelas sincronizan el estado de toda la red de nodos:

1. Conexión con el Maestro: Cada Sentinel establece una conexión con el nodo maestro y envía el comando INFO periódicamente para obtener datos del rol, el runid y la lista de réplicas conectadas.
2. Descubrimiento de Réplicas: Con la información obtenida del maestro, el centinela se conecta a cada réplica para conocer su estado de sincronización (offset) y disponibilidad.
3. Interconexión entre Centinelas: Los centinelas utilizan el mecanismo de Publicación/Suscripción (Pub/Sub) de Redis para descubrirse entre sí. Crean un canal interno donde intercambian sus direcciones IP y puertos, formando una red de confianza donde comparten la visión del clúster.

2. Fase de Notificación

Los centinelas mantienen conexiones activas para intercambiar mensajes sobre el estado de salud de las instancias. Cualquier cambio detectado por un nodo es propagado rápidamente al resto de la red de centinelas para mantener una vista global coherente.

3. Fase de Failover (Conmutación por Error)

Esta fase se activa cuando un maestro deja de responder y se divide en varios pasos lógicos:

Detección de Fallo (SDOWN y ODOWN)

• SDOWN (Subjective Down): Ocurre cuando un único centinela detecta que el maestro no responde a los comandos PING durante un tiempo determinado.
• ODOWN (Objective Down): Se alcanza cuando el número de centinelas definido en el quorum confirma que el maestro está fuera de línea. Solo en este punto se inicia el proceso de recuperación.

Elección del Líder (Sentinel Leader Election)

Mediante un algoritmo de consenso basado en votación, los centinelas eligen a uno de ellos como "Líder" para gestionar la transición. Cada centinela propone su candidatura y los demás votan; el primero en obtener la mayoría toma el control del proceso de failover.

Selección y Promoción del Nuevo Maestro

El centinela líder evalúa a las réplicas disponibles bajo los siguientes criterios de filtrado:

• Se descartan nodos desconectados o con latencia excesiva.
• Se prioriza el nodo con mayor slave-priority (configurable).
• Si hay empate, se elige el nodo con el offset de replicación más avanzado (el que tiene los datos más recientes).
• Como último recurso, se selecciona el nodo con el runid lexicográficamente menor.

Finalemnte, el líder ejecuta el comando SLAVEOF NO ONE en la réplica elegida para convertirla en maestro y envía la instrucción SLAVEOF <Nuevo-IP> <Puerto> al resto de las réplicas para que se vinculen al nuevo líder.