Redis es un sistema de gestión de base de datos de clase NoSQL (DBMS no relacional) que está completamente en RAM. Para acceder a los datos, se utiliza el modelo "clave" - "valor". Tal DBMS se usa a menudo para almacenar cachés en servicios escalables, para almacenar imágenes y datos pequeños.
Redis DBMS es ampliamente utilizado debido a:
- alta velocidad, porque todos los datos se almacenan en la RAM;
- multiplataforma;
- distribución bajo la licencia BSD (se aplica al software de código abierto).
La amplitud de distribución y aplicabilidad de Redis se puede estimar por la gran cantidad de documentación con todo tipo de casos en el
sitio web oficial del proyecto .
Si usa la escala horizontal de los servicios de DirectumRX, debe usar la instalación a prueba de fallas de Redis para que funcione correctamente con el servicio de almacenamiento DirectumRX y el servicio de acceso web DirectumRX.
Redis almacenará datos operativos, cachés y otra información que sea necesaria para la operación de los servicios en modo de escala para que el proceso de interacción del usuario con el sistema no dependa de la instalación con la que está trabajando actualmente.
Redis no almacenará datos confidenciales y no estará bajo una gran carga. Pero en el caso de una falla de Redis, los usuarios experimentarán muchos errores al cambiar entre instalaciones.
En el sitio web oficial de Redis, hay 2 formas de garantizar la escala horizontal y la tolerancia a fallos:
- Usando Redis Sentiel .
- Usando Redis Cluster .
Considere personalizar estas opciones.
Configurar Redis Sentiel
La opción que usa Redis Sentiel (Redis Tracking Node) se implementó en Redis 2.4 y consiste en usar el servicio adicional Redis Sentiel para monitorear la disponibilidad del asistente. También realiza la configuración de nodos de réplica en caso de falla del asistente. Determina cuál de los nodos SLAVE se convertirá en MAESTRO y realizará la reconfiguración sobre la marcha.
Implementa el esquema clásico:
Puede haber muchos nodos SLAVE (hasta 1000 según el sitio web oficial), para un trabajo productivo se recomienda utilizar al menos dos nodos SLAVE.
Normalmente, el esquema se configura de tal manera que el servicio Redis Sentiel se configura en los nodos MAESTRO y ESCLAVO, y si el nodo MAESTRO falla, los nodos de monitoreo restantes deciden introducir un nuevo MAESTRO.
La versión actual de Redis está disponible para su descarga desde el
sitio web oficial del desarrollador del producto . Sin embargo, el sitio de distribución solo está disponible para Linux. En un momento,
el proyecto de Microsoft para portar Redis a Windows se estaba desarrollando, pero en la actualidad el proyecto detuvo el desarrollo en la versión 3.2.100, por lo que en este artículo consideraremos la opción de implementación más relevante: en Linux.
Como nodos de prueba, utilizaremos dos hosts virtuales redis1 y redis2 con la distribución Linux instalada de Debian 10.
Primero, actualice las listas de paquetes desde el repositorio predeterminado e instale Redis:
apt-get update && apt-get upgrade apt install redis-server
Comprueba la versión:
root@redis1:/home/user
Deje que redis1 actúe como un nodo MAESTRO y redis2 actúe como un nodo ESCLAVO.
Para hacer esto, escribimos en los archivos de configuración de Redis los parámetros necesarios que le permitirán crear una réplica (aún no tolerante a fallas).
Para redis1 en el archivo de configuración /etc/redis/redis.conf, especifique:
Para redis2 en el archivo de configuración /etc/redis/redis.conf, especifique:
Reinicie los servicios de redis-server en ambos nodos:
root@redis1:/etc/redis
Verificamos en el lado MAESTRO que los nodos se convirtieron en réplicas y recibieron los roles necesarios:
root@redis1:/etc/redis
En el lado ESCLAVO, vemos la misma situación:
root@redis2:/etc/redis
Ahora debe configurar la réplica para que se restaure automáticamente en caso de falla de uno de los nodos. Para hacer esto, necesitamos el servicio de seguimiento Redis Sentinel.
Según la
documentación , el servicio de monitoreo de Redis Sentinel puede realizar las siguientes operaciones:
- Comprueba la disponibilidad de los nodos MAESTRO y ESCLAVO y puede enviar alertas sobre la inaccesibilidad de los nodos.
- Si el nodo MAESTRO falla, el nodo testigo puede poner el nodo ESCLAVO en modo MAESTRO, así como reconfigurar los nodos ESCLAVO restantes y comenzar a trabajar con el nuevo MAESTRO.
- Realiza cambios en los archivos de configuración de los nodos MAESTRO y ESCLAVO.
Para la pureza del experimento, colocaremos un servicio de testigos en una VM redis3 separada.
Conectamos el repositorio de Redis de la misma manera e instalamos el paquete redis-sentinel:
apt install redis-sentinel
Después de la instalación, debe realizar la configuración en el archivo de configuración del nodo de supervisión /etc/redis/sentinel.conf:
Reinicie el servicio después de realizar la configuración:
root@redis3:/etc/redis
Compruebe que el servicio de seguimiento vio MASTER y SLAVE:
root@redis3:/etc/redis
Comenzamos los experimentos.
Simulamos una falla, detenemos el servicio redis-server en el nodo redis1 y obtenemos la información actual del nodo testigo:
root@redis3:/etc/redis
Vemos que MASTER ha cambiado.
Restauraremos el funcionamiento del nodo redis1 y verificaremos su estado:
root@redis3:/var/log/redis
Vemos que el nodo recibió el rol ESCLAVO, y el nodo redis2 es un nodo MAESTRO.
Simule la falla del nodo redis2 y verifique el estado del nodo testigo:
root@redis3:/var/log/redis
Y el estado del nodo redis1:
root@redis3:/var/log/redis
Genial, el mecanismo funciona. Pero ahora ha surgido la pregunta de cómo conectaremos nuestros servicios DirectumRX, porque necesitan una dirección de nodo único. Resolveremos la situación utilizando el servicio HAProxy.
Redis Node Proxying
Cualquier servicio proxy tcp puede actuar como un proxy inverso para los nodos Redis. En este artículo, consideraremos el uso de HAProxy, ya que es una herramienta especializada diseñada para proporcionar alta disponibilidad y equilibrio de carga, y es utilizada por servicios en línea universalmente conocidos. Lea más sobre HAProxy
en la página del desarrollador .
Instale HAProxy en el nodo redis3:
root@redis3:/var/log/redis
En el archivo de configuración de HAProxy /etc/haproxy/haproxy.cfg, agregue la configuración para las solicitudes de proxy a los nodos de Redis:
… frontend ft_redis bind *:6379 name redis mode tcp default_backend bk_redis backend bk_redis mode tcp option tcp-check tcp-check connect
En esta configuración, se indica que enviaremos cualquier solicitud que llegue a todas las interfaces de la máquina virtual actual en la dirección del puerto 6379. Transferiremos las solicitudes al nodo que responderá que tiene el rol MAESTRO.
Reinicie el servicio de haproxy:
root@redis3:/etc/haproxy
Intentemos conectarnos usando el cliente redis-cli y creemos una clave de prueba:
root@redis3:/etc/haproxy
Detenga el nodo redis1 y vuelva a consultar la lista de claves:
127.0.0.1:6379> info keyspace Error: Server closed the connection (3.01s) 127.0.0.1:6379> info keyspace
Vemos que durante algún tiempo la conexión se desconectó, pero luego la conexión se restableció nuevamente y todos los datos permanecieron en su lugar.
Ahora es suficiente registrar la dirección del proxy inverso en los archivos de configuración de los servicios de DirectumRX para conectarse a Redis.
Configurar Redis Cluster
La opción de agrupación en clúster de Redis, implementada para la versión redis 3.0 y superior, es una solución para crear y administrar un clúster con segmentación y replicación de datos. Realiza tareas de gestión de nodos, replicación, sincronización de datos en nodos y garantiza el acceso de la aplicación del cliente al nodo MAESTRO en caso de falla de uno de varios nodos MAESTROS.
Redis Cluster funciona en modo multimaestro, cada nodo MAESTRO puede tener uno o más nodos ESCLAVO (hasta 1000).
El escalado es la función principal del clúster. Además, el clúster puede garantizar la tolerancia a fallas del servicio Redis:
- si algunos nodos no funcionan, el clúster redistribuye la carga de ellos a otros nodos;
- Si los nodos clave no funcionan, todo el clúster finaliza.
Puede surgir una situación cuando el Cliente 2 escribe en el nodo M2. M2 responde "OK" e intenta escribir en S2. Al mismo tiempo, M2 no espera la finalización correcta del intercambio de datos con S2, sino que responde al cliente de inmediato. En este caso, la réplica S2 puede no tener todos los datos. Por lo tanto, se recomienda usar varias réplicas de SLAVE.
También puede surgir una situación cuando M1, M3 dejan de "ver" M2 y el cliente continúa escribiendo datos en M2. Si la indisponibilidad continuará por un tiempo bastante largo (parámetro cluster-node-timeout), en este caso S2 se pondrá en modo MASTER y M2 dejará de funcionar por sí solo.
La documentación oficial recomienda usar 6 nodos, una instancia de Redis por nodo, lo que permite
una mayor confiabilidad, pero nadie prohíbe usar tres nodos con la siguiente topología de conexión:
Si falla uno de los nodos físicos, las réplicas de SLAVE correspondientes entrarán en modo MAESTRO y la operación no se interrumpirá.
Implementamos 3 máquinas virtuales (redis1, redis2 y redis3) en el banco de pruebas, cada una de las cuales ejecutará 2 instancias de Redis.
La aplicación cliente se conectará a un puerto específico especificado en el archivo de configuración del cliente, por lo tanto, los pares MAESTRO - ESCLAVO deberían funcionar en los mismos puertos.
Para el par M1 - S1 usaremos el puerto 6381
Para el par M2 - S2 usaremos el puerto 6382
Para el par M3 - S3 usaremos el puerto 6383
Prepara los archivos de configuración
En redis1:
cp /etc/redis/redis.conf /etc/redis/m1_redis.conf cp /etc/redis/redis.conf /etc/redis/s2_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
En redis2:
cp /etc/redis/redis.conf /etc/redis/m2_redis.conf cp /etc/redis/redis.conf /etc/redis/s3_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
En redis3:
cp /etc/redis/redis.conf /etc/redis/m3_redis.conf cp /etc/redis/redis.conf /etc/redis/s1_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak
Complete los archivos de configuración de acuerdo con la plantilla:
bind <IP- > protected-mode no
Vamos a lanzar los nodos Redis:
Nodo redis1:
root@redis1:/etc/redis
Redis2 nodo:
root@redis2:/etc/redis
Redis3 nodo:
root@redis3:/etc/redis
Para configurar el clúster, debe usar la utilidad de cliente redis-cli, pasándole una lista de ip: pares de servidores de puertos que desempeñarán los roles de MAESTRO y ESCLAVO:
redis-cli --cluster create redis1-ip:6381 redis2-ip:6382 redis3-ip:6383 redis1-ip:6382 redis2-ip:6383 redis3-ip:6381 --cluster-replicas 1
, donde la opción --cluster-replicas 1 le indica cuántos ESCLAVOS tendrá cada maestro, y se seleccionan automáticamente de la lista de réplicas transferidas.
root@redis1:~/redis/src
El clúster está construido correctamente. Mostraremos información sobre el clúster:
root@redis1:~/redis/src
Para probar una réplica específica, como con Redis Sentiel, puede usar el comando de replicación INFO:
root@redis1:~/redis/src
Intentemos crear varias claves y verifiquemos que estas claves aparecieron en las réplicas:
192.168.9.51:6381> SET key1 test1 -> Redirected to slot [9189] located at 192.168.9.52:6382 OK 192.168.9.52:6382> SET key2 test2 -> Redirected to slot [4998] located at 192.168.9.51:6381 OK 192.168.9.51:6381> SET key3 test3 OK 192.168.9.51:6381>
Compruebe en M2:
root@redis2:/home/user
Y en el M3:
root@redis3:/home/user
Desactivaremos el nodo redis1 y comprobaremos cómo funciona S1:
192.168.9.52:6382> CLUSTER NODES <b>182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave,fail d499af3672b3063c7239572ec311ad3160f280ae 1569509904727 1569509900000 4 connected</b> 485ffb786e9763955e6f10ffc59247690ad9bc11 <i>192.168.9.53:6381@16381 master</i> - 0 1569510017272 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569510018274 5 connected <b>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 master,fail - 1569509906731 1569509901721 1 connected</b> 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569510019275 3 connected 10923-16383 d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 myself,master - 0 1569510017000 2 connected 5461-10922
Vemos información sobre la falla de M1 y S2 y que S3 ha cambiado al modo MAESTRO.
Verifique dónde están almacenadas las claves:
192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6381> GET key3 "test3" 192.168.9.53:6381>
Las claves que se almacenaron anteriormente en redis1 ahora están disponibles en redis3.
Restaure el funcionamiento del nodo redis1 y verifique el estado de los nodos M1 y S2:
192.168.9.53:6381> CLUSTER NODES <i>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 slave 485ffb786e9763955e6f10ffc59247690ad9bc11 0 1569511658217 7 connected 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave d499af3672b3063c7239572ec311ad3160f280ae 0 1569511657000 4 connected</i> d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 master - 0 1569511656000 2 connected 5461-10922 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569511656000 3 connected 10923-16383 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381@16381 myself,master - 0 1569511656000 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569511657216 5 connected
La salud de M1 y S2 se ha recuperado, pero ahora M1 está en modo ESCLAVO.
Y las claves también están en el nodo redis3:
192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6383> GET key3 -> Redirected to slot [935] located at 192.168.9.53:6381 "test3"
El clúster está configurado y se prueba la recuperación de Redis.
Para acceder a los servicios de DirectumRX, también necesitará configurar proxies inversos, como en el caso de configurar Redis Sentiel.
En lugar de una conclusión
Este artículo no consideró otra forma de aumentar la tolerancia a fallas de Redis: usar un administrador de recursos de clúster de terceros, por ejemplo,
Pacemaker . En este caso, será posible sobrevivir con dos nodos, sin embargo, existe una alta probabilidad de pérdida de datos en caso de emergencia.
Para un proxy inverso (en este caso, HAProxy), también es deseable proporcionar tolerancia a fallas, pero este problema también estaba más allá del alcance de este artículo. Si está interesado en el tema, estas opciones de implementación también se pueden considerar en artículos separados con ajuste y prueba paso a paso de los resultados.
Puede encontrar los enlaces a continuación para obtener más información sobre el tema:
Tutorial de clúster de RedisDocumentación de Redis SentinelManual de configuración de HAProxy .