UNIVERSIDAD PRIVADA ANTENOR ORREGO

FACULTAD DE INGENIERA

ESCUELA PROFESIONAL DE INGENIERA DE COMPUTACIN Y SISTEMAS

SERVIDOR HAPROXY PARA BALANCEO DE REDIS

SISTEMAS OPERATIVOS

ALUMNO: OLIVARES YAMUNAQU, VICTOR ALFONSO

PROFESOR: LOZANO CHU, ALI ALFONSO

TRUJILLO - PER

2017
 SERVIDOR HAPROXY PARA BALANCEO DE REDIS

HAPROXY: Un balanceador de carga es un dispositivo que acta como proxy inverso

distribuyendo el trfico de red o de una aplicacin a varios servidores.

Los balanceadores se utilizan para incrementar la capacidad de

procesamiento y confiabilidad.
Los balanceadores aseguran la disponibilidad monitorizando el estado de las
aplicaciones y enviando las peticiones a los servidores que puedan
responder.
Los balanceadores se agrupan en 2 categoras:
Layer4: actan sobre los datos de la red y protocolos IP, TCP, FTP y UDP.
Layer7: distribuyen peticiones en la capa de aplicacin con protocolos como
HTTP o TCP
Los balanceadores de tipo Layer7 pueden distribuir las peticiones en datos
de aplicacin como cookies, headers HTPP, datos del mensaje.
HAPROXY es un software libre que acta como balanceador de carga ofreciendo
alta disponibilidad, balanceo de carga y proxy para comunicaciones TCP y HTTP.

REDIS: es un motor de base de datos en memoria, basado en el almacenamiento en

tablas de hashes (clave/valor) pero que opcionalmente puede ser usada como una base
de datos durable o persistente.
Chef CookBook es un sistema de gestin de configuracin diseado para permitirle
automatizar y controlar un gran nmero de computadoras de manera automatizada,
confiable y escalable.
Los libros de cocina son las unidades de configuracin que nos permiten configurar y
realizar tareas especficas dentro de Chef en nuestros nodos remotos. Construimos
libros de cocina y luego le decimos al Chef qu nodos queremos que sigan los pasos
delineados en el libro de cocina.

2
Usaremos tres componentes:
Redis/Sentinel: La base de Datos con su sistema de monitorizacin propio, monitoriza
que nodo es master o esclavo en el cluster (el cambio ser automtico cuando Sentinel
detecte un problema).
HaProxy: Un balanceador de carga que permite chequear los tres nodos Redis y ver en
cada momento cual es el Master. Permitir que el trfico sea siempre dirigido al nodo
Master.

KeepAlived: Un balanceador de carga de red publicar un nico punto de red (Virtual

IP) y balancear entre las mquinas.

*Comenzaremos la instalacin, por las piezas que sern las que ataquen los clientes para
llegar a la BBDD, HaProxy y KeepAlived.
Este montaje est basado en 3 mquinas Debian Net Install
SERVIDOR MAESTRO: IP 10.0.2.15

SERVIDOR ESCLAVO 1: IP 192.168.1.38

SERVIDOR ESCLAVO 2: IP 192.168.1.40

3
El HaProxy y los Keepalive solo irn en las primeras y Redis/Sentinel en las tres, es decir
la ltima mquina solo entrara en nuestro HA como rplica de BBDD y de Sentinel.
En las dos primeras mquinas instalaremos estos componentes:

- sudo apt-get update

- sudo apt-get install keepalived haproxy

Es importante tras la instalacin editar el archivo /etc/sysctl.conf para permitir a

haproxy usar la vip incluso si est asignada al nodo en funcionamiento.

- nano /etc/sysctl.conf > net.ipv4.ip_nonlocal_bind=1

Editamos el archivo de configuracin de haproxy y aadimos lo siguiente en ambos

nodos:

nano /etc/haproxy/haproxy.cfg

global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
defaults
log global
mode tcp
option httplog
option dontlognull

timeout connect 5000

timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

4
 frontend redis
bind 10.20.0.5:6380 name redis_prod
default_backend redis_backend_prod
backend redis_backend_prod
option tcp-check
tcp-check send PING\r\n
tcp-check expect string +PONG
tcp-check send info\ replication\r\n
tcp-check expect string role:master
tcp-check send QUIT\r\n
tcp-check expect string +OK
server redis1 10.0.2.15:6379 check inter 1s
server redis2 192.168.1.38:6379 check inter 1s
server redis3 192.168.1.40:6379 check inter 1s

Como vemos, en la ltima parte de la configuracin de HaProxy conecta la IP virtual y

chequea en los tres nodos de Redis quien es el master cada segundo.

- /etc/init.d/haproxy reload

Posteriormente, configuraremos la herramienta keepalived, entre los dos servidores

para levantar la vip a la que se conectaran nuestros clientes:

- nano /etc/keepalived/keepalived.conf
vrrp_script chk_haproxy {
script killall -0 haproxy
interval 2 weight }
vrrp_instance VI_1 {
interface ens32 #nombre interfaz puede cambiar dependiendo de la
instalacin
state MASTER
virtual_router_id 51
priority 101
virtual_ipaddress {
10.20.0.5 # virtual IP
} track_script {
chk_haproxy}

- /etc/init.d/keepalived start

5
Con esto, ya tenemos preparada la alta disponibilidad a nivel de red, tenemos una
herramienta que nos chequea quien es el master en cada momento y nos balancea y
una IP comn a la que se pueden conectar nuestros clientes y que estar balanceada
entre dos nodos, por si hubiera un problema de red en alguno.
El siguiente paso ser instalar las BBDD Redis y configurar Sentinel, esta parte
debemos hacerla en los tres nodos:

- sudo apt-get install redis-server

- nano /etc/redis/redis.conf

bind 127.0.0.1 10.0.2.15 (redis1)

bind 127.0.0.1 192.168.1.38 (redis2)

slaveof 192.168.1.38 6379 (redis2)

bind 127.0.0.1 192.168.1.40 (redis3)

slaveof 192.168.1.40 6379 (redis3)

Con el parmetro slaveof lo que estaremos dicindole a Redis que replique la BBDD y
la persista en los nodos esclavos.
Ahora, antes de configurar Sentinel tenemos que tener arrancado Redis y
comprobaremos que la rplica est activa (ejemplo):

redis-cli
info
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.38,port=6379,state=online,offset=71,lag=0
slave1:ip=192.168.1.38,port=6379,state=online,offset=71,lag=1
master_repl_offset:71
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:70

6
El ltimo paso, es configurar Sentinel, tenemos que crear el archivo de configuracin
en cada nodo y seleccionar el master y sus esclavos. Sentinel tiene auto
descubrimiento es decir si aadimos nodos visibles a nivel de red con el mismo
nombre de grupo los aadir como esclavos.
El archivo de configuracin quedar como sigue:

port 6390
daemonize yes
loglevel warning
logfile /var/log/redis/redis-sentinel.log
#MASTER SETUP
sentinel monitor sentinelgroup 10.0.2.15 6379 2
sentinel down-after-milliseconds sentgti 5000
sentinel failover-timeout sentgti 900000
sentinel down-after-milliseconds sentinelgroup 5000
sentinel config-epoch sentinelgroup 0
sentinel leader-epoch sentinelgroup 0

#SLAVE SETUP
sentinel known-slave sentinelgroup 192.168.1.38 6379
sentinel known-slave sentinelgroup 192.168.1.40 6379
sentinet known-sentinel sentinelgroup 192.168.1.38 6390
sentinet known-sentinel sentinelgroup 192.168.1.40 6390
sentinel monitor resque 10.0.2.15 6379 2

A grandes rasgos, con una configuracin similar a esta, tendrais un cluster de Redis
con alta disponibilidad de red, todos los clientes se conectaran a nuestra vip y podr
balancear entre los dos nodos si a uno le pasa algo. Y con disponibilidad de BBDD,
HaProxy se dar cuenta si Sentinel cambia un nodo de master a esclavo y balancear
las peticiones al nuevo activo.