Redis sentinel vs agrupamiento

Entiendo que redis sentinel es una forma de configurar HA (alta disponibilidad) entre múltiples instancias de redis. Como veo, hay una instancia de redis que atiende activamente las solicitudes del cliente en un momento dado. Hay dos servidores adicionales en espera (esperando que ocurra una falla, por lo que uno de ellos puede estar en acción nuevamente).

• ¿Es un desperdicio de recursos?
• ¿Existe una mejor manera de aprovechar al máximo los recursos disponibles?
• ¿Es la agrupación de Redis una alternativa al centinela de Redis?

Ya busqué la documentación de redis para centinela y agrupación , ¿alguien con experiencia puede explicarlo?

ACTUALIZAR

OKAY. En mi escenario de implementación real, tengo dos servidores dedicados para redis. Tengo otro servidor, mi servidor Jboss se está ejecutando. La aplicación que se ejecuta en Jboss está configurada para conectarse al servidor maestro de redis (M).

Escenario de conmutación por error

Idealmente, creo que cuando el servidor de caché maestro falla (el proceso de Redis falla o falla la máquina), la aplicación en Jboss necesita conectarse al servidor de caché esclavo. ¿Cómo configuraría los servidores de Redis para lograr esto?

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

Primero, hablemos de centinela.

Sentinel administra la conmutación por error, no configura Redis para HA. Es una distinción importante. En segundo lugar, el diagrama que publicó es en realidad una mala configuración: no desea ejecutar Sentinel en el mismo nodo que los nodos de Redis que está administrando. Cuando pierdes ese anfitrión, pierdes ambos.

En cuanto a "¿Es un desperdicio de recursos?" depende de su caso de uso. No necesita tres nodos de Redis en esa configuración, solo necesita dos. Tres aumenta su redundancia, pero no es obligatorio. Si necesita la redundancia adicional, no es una pérdida de recursos. Si no necesita redundancia, simplemente ejecute una sola instancia de Redis y califíquela como buena, ya que ejecutar más sería una "pérdida".

Otra razón para ejecutar dos esclavos sería dividir lecturas. Nuevamente, si lo necesita, no sería un desperdicio.

En cuanto a "¿Existe una mejor manera de utilizar al máximo los recursos disponibles?" no podemos responder eso ya que depende demasiado de su escenario y código específicos. Dicho esto, si la cantidad de datos para almacenar es "pequeña" y la tasa de comando no es excesivamente alta, recuerde que no necesita dedicar un host a Redis.

Ahora para "¿Redis es la agrupación en clústeres una alternativa al centinela de Redis?". Realmente depende completamente de su caso de uso. Redis Cluster no es una solución HA, es una solución de múltiples escritores / más grande que la memoria RAM. Si su objetivo es solo HA, es probable que no sea adecuado para usted. Redis Cluster viene con limitaciones, particularmente en las operaciones de múltiples claves, por lo que no es necesariamente una operación sencilla de "solo usar el clúster".

Si cree que tener tres hosts ejecutando Redis (y tres ejecutando Sentinel) es un desperdicio, probablemente considerará que Cluster lo es aún más, ya que requiere más recursos.

Las preguntas que ha formulado son probablemente demasiado amplias y basadas en opiniones para sobrevivir como están escritas. Si tiene un caso / problema específico que está resolviendo, actualice con eso para que podamos brindar asistencia e información específicas.

Actualización para detalles:

Para una gestión adecuada de la conmutación por error en su escenario, iría con 3 centinelas, uno que se ejecuta en su servidor JBoss. Si tiene 3 nodos JBoss, elija uno en cada uno. Tendría un módulo de Redis (maestro + esclavo) en nodos separados y dejaría que el centinela administrara la conmutación por error.

A partir de ahí, es cuestión de conectar JBoss / Jedis para usar Sentinel para su información y administración de conexiones. Como no los uso, una búsqueda rápida revela que Jedis tiene el soporte para ello, solo necesita configurarlo correctamente. Algunos ejemplos que encontré están en Buscando un ejemplo de Jedis con Sentinel y https://github.com/xetorthio/jedis/issues/725 que hablan sobre JedisSentinelPoolser la ruta para usar un grupo.

Cuando Sentinel ejecuta una conmutación por error, los clientes se desconectarán y Jedis (¿debería?) Manejar la reconexión preguntando a los Sentinels quién es el maestro actual.

La recomendación, en todas partes, es comenzar con un número impar de instancias, sin usar dos o un múltiplo de dos. Eso fue corregido, pero corrijamos algunos otros puntos.

Primero, decir que Sentinel proporciona conmutación por error sin HA es falso. Cuando tiene conmutación por error, tiene HA con el beneficio adicional de que se replica el estado de la aplicación. La distinción es que puede tener HA en un sistema sin replicación (es HA pero no es tolerante a fallas).

En segundo lugar, ejecutar un centinela en la misma máquina que su instancia de redis de destino no es una "mala configuración": si pierde su centinela, o su instancia de redis, o toda la máquina, los resultados son los mismos. Probablemente esa sea la razón por la que cada ejemplo de tales configuraciones muestra que ambos se ejecutan en la misma máquina.

Esta no es una respuesta directa a su pregunta, pero piense que es información útil para los novatos de Redis, como yo. Además, esta pregunta aparece como el primer enlace en google cuando se busca "Redis cluster vs sentinel".

Redis Sentinel es el nombre de la solución de alta disponibilidad de Redis ... No tiene nada que ver con Redis Cluster y está destinado a ser utilizado por personas que no necesitan Redis Cluster, sino simplemente una forma de realizar una conmutación por error automática cuando un maestro instancia no funciona correctamente.

Tomado del borrador de diseño 1.3 de Redis Sentinel

No es obvio cuando es nuevo en Redis y está implementando una solución de conmutación por error. Las documentaciones oficiales sobre centinela y agrupación no se comparan entre sí, por lo que es difícil elegir el camino correcto sin leer toneladas de documentación.

Este es mi entendimiento después de golpearme la cabeza a lo largo de la documentación.

Sentinel es una especie de solución de reserva en caliente en la que los esclavos se mantienen replicados y listos para ser promocionados en cualquier momento. Sin embargo, no admitirá escrituras de varios nodos. Los esclavos se pueden configurar para operaciones de lectura. NO es cierto que Sentinel no proporcionará HA, tiene todas las características de un clúster activo-pasivo típico (aunque ese no es el término correcto para usar aquí).

El clúster de Redis es más o menos una solución distribuida que funciona sobre fragmentos. Cada fragmento de datos se distribuye entre los nodos maestros y esclavos. Un factor de replicación mínimo de 2 garantiza que tenga dos fragmentos activos disponibles entre maestro y esclavos. Si conoce la fragmentación en Mongo o Elasticsearch, será fácil ponerse al día.

Redis puede operar en un clúster particionado (con muchos maestros y esclavos de esos maestros) o en un modo de instancia única (maestro único con esclavos de réplica).
El enlace aquí dice:

Cuando se usa Redis en modo de instancia única, en el que un solo servidor de Redis administra toda la base de datos sin particiones, Redis Sentinel se usa para administrar su disponibilidad.

También dice:

Un clúster de Redis, en el que los datos se dividen entre varias instancias primarias, administra la disponibilidad por sí mismo y no requiere componentes adicionales.

Por lo tanto, la HA puede garantizarse en los 2 escenarios mencionados. Espero que esto aclare las dudas. El cúmulo de Redis y los centinelas no son alternativos entre sí. Solo se utilizan para garantizar HA en diferentes casos de maestro particionado o no particionado.

Redis Sentinel realiza las réplicas de promoción de la conmutación por error cuando ven que un maestro no funciona. Por lo general, desea un número impar de ganglios centinela. Para el ejemplo de un maestro y una réplica, deben usarse 3 centinelas para que pueda haber un consenso sobre la decisión. Idealmente, el tercer centinela está en un tercer servidor para que la decisión no sea sesgada (dependiendo del fallo). Sentinel se encarga de cambiar la configuración del maestro / réplica en sus nodos para que la promoción y la sincronización ocurran en el orden correcto y usted no sobrescriba los datos al traer un maestro antiguo que falló que ahora contiene datos más antiguos.

Una vez que haya configurado sus nodos centinela para realizar conmutaciones por error, debe asegurarse de que está apuntando a la instancia correcta. Vea un ejemplo de configuración de HAProxy para esto . HAProxy realiza comprobaciones de estado y señalará al nuevo maestro si se produce una falla.

El agrupamiento le permitirá escalar horizontalmente y puede ayudar a manejar cargas elevadas. Se necesita un poco de trabajo para instalar y configurar por adelantado.

Hay una bifurcación de código abierto de Redis, "KeyDB" que ha eliminado la necesidad de nodos centinela con una opción de réplica activa. Esto permite que el nodo de réplica acepte lecturas y escrituras. Cuando ocurre una conmutación por error, HAProxy detiene las lecturas / escrituras con el nodo fallido y solo usa el nodo activo restante que ya está sincronizado. La marca de tiempo permite que los nodos fallidos se vuelvan a unir automáticamente y se vuelvan a sincronizar sin perder datos cuando vuelven a estar en línea. La configuración es simple y para un mayor tráfico no necesita una configuración inicial especial para dirigir las lecturas al nodo de réplica y las lecturas / escrituras al maestro. Vea un ejemplo de replicación activa aquí . KeyDB también es multiproceso, lo que para algunas aplicaciones podría ser una alternativa a la agrupación en clústeres, pero realmente depende de cuáles sean sus necesidades.

También hay un ejemplo de cómo configurar la agrupación en clústeres manualmente y con la herramienta de creación de clústeres . Estos son los mismos pasos si está utilizando Redis (reemplace 'keydb' con 'redis' en las instrucciones)

Información adicional a las respuestas anteriores

Clúster de Redis

• Uno de los objetivos principales del clúster de Redis es distribuir de manera equitativa / uniforme la carga de datos mediante la fragmentación

• Redis Cluster no usa hash consistente, sino una forma diferente de fragmentación donde cada clave es conceptualmente parte de lo que se llama ranura hash.

• Hay 16384 ranuras hash en Redis Cluster.Cada nodo en un Redis Cluster es responsable de un subconjunto de las ranuras hash, por lo que, por ejemplo, puede tener un clúster con 3 nodos, donde:

  El nodo A contiene ranuras hash de 0 a 5500, el nodo B contiene ranuras hash de 5501 a 11000, el nodo C contiene ranuras hash de 11001 a 16383

Esto nos permite agregar y eliminar nodos en el clúster fácilmente. Por ejemplo, si queremos agregar un nuevo nodo D, necesitamos mover alguna ranura hash de los nodos A, B, C a D

• El clúster de Redis admite la estructura maestro-esclavo, puede crear esclavos A1, B1, C2 junto con el maestro A, B, C al crear un clúster, por lo que cuando el maestro B deja de funcionar, el esclavo B1 se promueve como maestro

No necesita un manejo adicional de la conmutación por error cuando usa Redis Cluster y definitivamente no debe apuntar instancias de Sentinel en ninguno de los nodos del Cluster.

Entonces, en términos prácticos, ¿qué obtienes con Redis Cluster?

1.La capacidad de dividir automáticamente su conjunto de datos entre varios nodos.

2. La capacidad de continuar las operaciones cuando un subconjunto de los nodos experimenta fallas o no puede comunicarse con el resto del clúster.

Centinela de Redis

• Redis admite múltiples esclavos que replican datos desde un nodo maestro.
• Esto proporciona una copia de seguridad de los datos en el nodo principal.
• Redis Sentinel es un sistema diseñado para administrar maestro y esclavo. Funciona como programa independiente. El número mínimo de centinelas requerido en un sistema ideal es 3. Se comunican entre ellos y se aseguran de que el Maestro esté vivo, si no está vivo, promoverán a uno de los esclavos como maestro, por lo que más tarde, cuando el nodo muerto gire, será actuando como esclavo para el nuevo amo
• El quórum es configurable. Básicamente es el número de centinelas que deben estar de acuerdo cuando el maestro está caído. N / 2 +1 debería estar de acuerdo. N es la cantidad de nodos en el pod (tenga en cuenta que esta configuración se llama pod y no es un clúster)

Entonces, en términos prácticos, ¿qué obtienes con Redis Sentinel?

Se asegurará de que el maestro esté siempre disponible (si el maestro deja de funcionar, el esclavo será promovido como maestro)

Referencia:

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

https://redis.io/topics/cluster-tutorial