VISITAS:

miércoles, 30 de marzo de 2016

Funcionamiento de Redis Sentinel

Características de sentinel

Sentinel da alta disponibilidad a redis, permitiendo a redis recuperarse de algunos fallos sin intervención humana.
Estas son las características de sentinel:

  • Monitorización: sentinel está continuamente monitorizando si los redis master y slave están arriba y funcionando.
  • Notificación: sentinel puede avisar a los administradores del sistema o a otros programas, de caídas de instancias redis.
  • Failover automático: si la instancia master de redis no está funcionando adecuadamente, sentinel puede iniciar un proceso de failover donde un slave es promocionado a master y los demás slaves se reconfiguran para utilizar el nuevo master
  • Proveedor de configuración: sentinel actúa como descubridor de la instancia master de redis. Los clientes se conectan a sentinel, y éste les indica a qué instancia de redis se tienen que conectar. Cuando se realiza un failover, sentinel informa a sus clientes del nuevo master.

Sentinel es un sistema distribuido

Sentinel funciona de forma distribuida, es decir, varias instancias de sentinel se comunican entre sí cooperando. Las ventajas de tener varios sentinel ejecutando conjuntamente son:
  • la detección de fallos se realiza cuando varias instancias sentinel acuerdan que la instancia master ya no está disponible. Esto disminuye la probabilidad de falsos positivos.
  • sentinel puede funcionar incluso aunque no todas las instancias de sentinel estén disponibles, haciendo al sistema más robusto.

Ejecutar sentinel

Sentinel se ejecuta de la siguiente forma:

    redis-sentinel sentinel-config-file

Es obligatorio especificar un fichero de configuración para ejecutar sentinel, ya que este fichero puede ser reescrito por sentinel para guardar el estado actual, y se utilizará después de una caída. Además, el proceso sentinel tiene que tener permisos de escritura en este fichero.
Las distintas instancias de sentinel se comunican entre sí por el puerto configurado en sentinel.

Criterios de despliegue de sentinel

  1. Se recomienda desplgar al menos 3 instancias de sentinel
  2. Las 3 instancias de sentinel deben ejecutar en máquinas independientes desde el punto de vista de fallos
  3. No se garantiza que todas las escrituras permanezcan después de la caída de un master, ya que redis utiliza un sistema asíncrono de replicación
  4. No todas las librerías cliente soportan sentinel (jedis sí lo soporta)

Configuración de sentinel

La configuración mínima de una instancia sentinel sería como la siguiente:
sentinel monitor nombre_del_grupo 127.0.0.1 6379 2
sentinel down-after-milliseconds  60000
sentinel failover-timeout  180000
sentinel parallel-syncs  1 1
Se especifica el nombre de un grupo de instancias redis. Este nombre es el que se utilizará para el grupo. Se especifica también la IP de la instancias redis master. No es necesario especificar las instancias slaves de redis, ya que sentinel es capaz de descubrirlas (preguntando al master). Cuando sentinel autodetecta esclavos, los escribe en su fichero de configuración:

    sentinel known-slave my_redis_group 168.190.1.45 6379

También se reescribe el fichero de configuración cuando después de un failover, cambia el master y cada vez que se descubre un nuevo sentinel:

    sentinel known-sentinel my_redis_group 168.190.1.47 26379 xxxxxxx

Detección de master caído

El último argumento de sentinel monitor, un 2 en este ejemplo, se denomina quorum, y su significado es el siguiente:

  • quorum es el número mínimo de instancias sentinel que es necesario que acuerden que un master no está disponible.
  • quorum sólo se utiliza para detectar un fallo del master, no para iniciar un failover. Para realmente iniciar un failover, una de las instancias sentinel es elegida como líder, pero debe ser autorizada para iniciar el failover. Esto sólo ocurre con el voto de la mayoría de las instancias sentinel.
Se puede entender con un ejemplo. Tenemos 5 instancias de sentinel vigilando un master reds y el quorum es 2. Si dos instancias de sentinel detectan que el master se ha caído, entonces uno de los dos es elegido para intentar iniciar el proceso de failover. Pero es necesario que al menos 3 instancias estén de acuerdo en iniciar el failover para realmente llevarlo a cabo.
Ya que es necesario que la mayoría de los sentinel decidan iniciar un failover, se RECOMIENDA/OBLIGA que haya al menos 3 instancias de sentinel en 3 máquinas distintas.

Otras opciones de sentinel

Las otras opciones de sentinel tienen el siguiente formato:

    sentinel

  • down-after-milliseconds es el tiempo que una instancia de redis no es alcanzable (no responde a pings o responde con error) para que sentinel piense que está caída
  • parallel-syncs determina el número de slaves que pueden ser reconfigurados en paralelo para usar el nuevo master después de un failover

Pérdidas de datos en failover

Ya que redis replica asíncronamente (no espera la confirmación), siempre hay un riesgo de perder algún dato cuando se cae el master, ya que éste puede caerse justo después de una escritura y justo antes de replicar esa escritura en los slaves.
Otro caso que puede ocurrir es que el master no se caiga, pero se interrumpa su conexión de red con los slaves. Entonces, podría ocurrir que los sentinel pensaran que se ha caído el master (ya que no responde, aunque realmente no se ha caído) y promocionaran a otra instancia de redis como master. El problema es que si había clientes conectados al master anterior y que no han perdido la conexión con él, pueden seguir escribiendo datos en el antiguo master. Mientras tanto, el master nuevo también puede recibir nuevos datos. Los datos escritos en el master antiguo se perderán cuando la conexión se arregle, ya que éste va a convertirse en slave y va a sincronizarse con el nuevo master.
Este problema puede reducirse bastante utilizando la siguiente configuración:

    min-slaves-to-write 1
    min-slaves-max-lag 10

Con esta configuración, una instancia redis actuando como master, dejará de aceptar escrituras si no puede escribir en al menos un slave en un máximo de 10 segundos. De esta forma, el antiguo master dejará de funcionar en 10 segundos. La desventaja es que si se pierde la conexión con los slaves, la instancia master dejará de funcionar.