En primer lugar, Sentinel no es un equilibrador de carga ni un proxy para Redis.
En segundo lugar, no todas las fallas son la muerte del host. A veces, el servidor se bloquea brevemente, a veces se desconecta un cable de red, etc. Debido a esto, no es una buena práctica ejecutar Sentinel en los mismos hosts que su instancia de Redis. Si está utilizando Sentinel para administrar la conmutación por error, cualquier cosa que no sea más de tres centinelas ejecutándose en nodos que no sean su redis maestro y esclavo(s) está causando problemas.
Sentinel utiliza un mecanismo de quórum para votar sobre una conmutación por error y un esclavo. Con menos de dos centinelas, corre el riesgo de dividir el cerebro donde dos o más servidores Redis se creen maestros.
Imagine el escenario en el que ejecuta dos servidores y ejecuta Sentinel en cada uno. Si pierde uno, pierde la capacidad de conmutación por error confiable.
Los clientes solo se conectan a Sentinel para conocer la información de conexión maestra actual. Cada vez que el cliente pierde la conectividad, repite este proceso. Sentinel no es un proxy para Redis; los comandos para Redis van directamente a Redis.
La única razón confiable para ejecutar Sentinel con menos de tres centinelas es para el descubrimiento de servicios, lo que significa no usarlo para la administración de conmutación por error.
Considere el escenario de dos anfitriones:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Si el Host B pierde temporalmente la conectividad de red con el Host A en este escenario, el HostB se promoverá a sí mismo como maestro. Ahora tienes:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
A cualquier cliente que se conecte a Sentinel 2 se le indicará que el Host B es el maestro, mientras que a los clientes que se conecten a Sentinel 1 se le informará al Host A que es el maestro (lo que, si tiene sus Sentinel detrás de un balanceador de carga, significa la mitad de sus clientes).
Por lo tanto, lo que debe ejecutar para obtener una administración de conmutación por error mínima aceptable y confiable es:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Sus clientes se conectan a los centinelas y obtienen el maestro actual para la instancia de Redis (por nombre), luego se conectan a él. Si el maestro muere, el cliente debe interrumpir la conexión, después de lo cual el cliente se conectará/deberá conectarse a Sentinel nuevamente y obtener la nueva información.
Lo bien que cada biblioteca cliente maneje esto depende de la biblioteca.
Idealmente, los hosts C, D y E están en los mismos hosts desde los que se conecta a Redis (es decir, el host del cliente). o representan una buena muestra de ellos. El objetivo principal aquí es asegurarse de que está comprobando desde dónde necesita conectarse a Redis. De lo contrario, colóquelos en el mismo DC/Rack/Región que los clientes.
Si desea que sus clientes hablen con un balanceador de carga, intente tener sus Sentinels en esos nodos LB si es posible, agregando hosts que no sean LB adicionales según sea necesario para obtener un número impar de Sentinels> 2. Una excepción a esto es si su los hosts de los clientes son dinámicos en el sentido de que el número de ellos es inconsistente (se amplían para el tráfico, se reducen para períodos lentos, por ejemplo). En este escenario, prácticamente debe ejecutar sus Sentinels en hosts que no sean clientes ni servidores Redis.
Tenga en cuenta que si hace esto, necesitará escribir un daemon que monitoree el canal Sentinel PUBSUB para el evento de cambio maestro para actualizar el LB, que debe configurar para hablar solo con el maestro actual (nunca intente hablar con ambos). Es más trabajo hacer eso, pero hace uso de Sentinel transparente para el cliente, que solo sabe hablar con la IP/Puerto de LB.
