Instalacion y configuracion de HAProxy en CentOS/RHEL 6/7

haproxy

HaProxy

Instalacion de HaProxy

El servicio haproxy es parte del paquete “haproxy” que podemos instalar via yum

yum install -y haproxy

El archivo de configuracion principal del servicio es el /etc/haproxy/haproxy.cfg dicho archivo esta separado en 3 partes, global, defaults y luego las configuraciones de los distintos servicios, los mismos pueden ser de tipo frontend, backend o listen

Abajo un ejemplo de configuracion basico de global:

global
    log             127.0.0.1 local2
    chroot          /var/lib/haproxy
    pidfile         /var/run/haproxy.pid
    maxconn         4000
    user            haproxy
    group           haproxy
    stats socket    /var/lib/haproxy/stats
    daemon

log : Direccion IP y facility que utilizara el demonio para guardar registros via Syslog
chroot : Ruta de ejecucion y enjaulamiento del demonio
pidfile : Ruta del archivo PID
maxconn : Numero maximo de conexiones concurrentes que aceptara el demonio
user : Usuario con el cual se ejecuta el demonio
group : Grupo con el cual se ejecuta el demonio
daemon : Modo en el que se levantara el proceso, por defecto daemon ya que se utiliza como servicio del S.O.
stats socket : Ruta del archivo socket para las estadisticas, el mismo puede ser consultado con el comando socat


Ejemplo de configuracion basica de defaults

Las configuraciones defaults son las que se setean por defecto para cada frontend, backend o listen que creemos.

defaults
    mode        http
    maxconn     3000
    option      dontlognull
    option      http-server-close
    option      redispatch
    retries     3
    timeout http-request        1m
    timeout queue               1m
    timeout connect             10s
    timeout client              10m
    timeout server              10m
    timeout http-keep-alive     10s
    timeout check               10s
    tcplog

mode : El modo default en el cual trabajaran los frontend, backend y listen, puede ser tcp o http
maxconn *: Cantidad maxima de conexiones para cada frontend, backend o listen *
option dontlognull : Evita que se registre en los logs repuestas nulas o vacias
option http-server-close : Fuerza el cierre de la conexion una vez que se recibio la respuesta del servidor backend
option redispatch : Activa la redistribución de sesión en caso de fallo de conexión
retries : Numero de intentos sobre un servidor luego de un fallo de conexion
timeout http-request *: Tiempo de espera para recibir la respuesta HTTP completa *
timeout queue : Tiempo de espera para las conexiones que estan en espera
timeout connect : Tiempo de espera para que el servidor acepte la conexion
timeout client : Tiempo maximo de inactividad del lado del cliente
timeout server : Tiempo maximo de inactividad del lado del servidor
timeout http-keep-alive : Tiempo maximo de espera para reutilizar una conexion HTTP
timeout check : Tiempo maximo de espera para que los servidores respondan los chequeos luego de abrir la conexion
tcplog : Modo de logueo, los mas utilizados son tcplog y httplog, tcplog registra las peticiones y que nodo atendio la misma, httplog registra la URL solicitada por el cliente


Definicion de frontend

El frontend es la parte de en la cual se especifica el tipo de aplicacion, los puertos y direcciones IP en las que escuchara el servicio, tambien se establecen las primeras reglas para las conexiones, el frontend seria el encargado de recibir las conexiones de los clientes.
Ejemplo de frontend para balancear conexiones HTTP:

frontend f_webfarm
    bind 192.168.1.1:80
    bind 192.168.1.2:80
    mode http
    acl acl_nagios hdr_end(host) -i nagios.infratic.com
    acl acl_git url_beg /git
    use_backend b_nagios if acl_nagios
    use_backend b_git if acl_git
    default_backend b_webfarm

bind : IP:Puerto que debe abrir el HaProxy para dicho frontend, pueden ser distintas direcciones IP y distintos puertos, tambien se puede poner 0.0.0.0:80 para que abra el puerto 80 de todas las IPs que tiene configurado el S.O.
mode : Modo en el que trabajara , si no se especifica hereda de la configuracion defaults.
acl : acl se utilizan para crear reglas o politicas, por ejemplo en el primer caso crea una acl para cuando se consulta a git.infratic.com, luego se crea una acl para cuando se consulta al /git

Las acl’s mas comunes son:
url_beg: String con el cual inicia la URL.
url_sub: String del subfolder.
url_end: String con el cual termina la URL.
hdr_end(host): Nombre al cual intenta conectarse el cliente.

use_backend : Se utiliza para determinar cual sera el backend a utilizar en caso de que se cumplan una o varias acl’s.
default_backend : Hace referencia al nombre del backend que se utilizara en caso de que no se cumpla ninguna regla de use_backend.


Definicion de backend

La configuracion backend es donde se determinan cuales son los nodos, cuales son los metodos de chequeo de vida y cuales son las opcion o metodos de balanceo
Ejemplo basico de backend

backend backend_web
    mode http
    balance source
    option http-server-close
    option httpclose
    option forceclose
    cookie SERVERID insert nocache indirect
    option httpchk GET /test HTTP/1.1\r\nHost:\ lb.infratic.com\r\n
    server jb1 jb1.infratic.com:8280 check cookie JB1 inter 10s
    server jb2 jb2.infratic.com:8280 check cookie JB2 inter 10s

mode : Modo en el que trabajara , si no se especifica hereda de la configuracion defaults.
balance : Se establece el tipo de balanceo a utilizar.

Los metodos mas utilizados son:
roundrobin: Distribuye la carga entre los nodos de manerae equitativa, es decir si tenemos 2 nodos para cada 10 conexiones caeran 5 a cada nodo.
source: Realiza el balanceo basandose en la direccion IP del cliente, es decir cada vez que un cliente se conecte ira al mismo nodo al cual fue en la primera conexion (siempre y cuando el nodo este activo)

option http-server-close : Fuerza a cerrar las conexiones http entre el balanceador y el nodo
option httpclose : Cierra la conexion http entre el cliente y el balanceador (Agregar el header Connection:Close)
option forceclose : Fuerza el cierre de las conexiones http entre el cliente y el balanceador
cookie SERVERID : Establece el ID del cookie para cada nodo backend
option httpchk : Se establece el metodo PING, seria el metodo por el cual el balanceador se dara cuenta cuando un nodo caiga, en el caso de HTTP el balanceador espera una respuesta diferente al codigo HTTP 500, si un nodo retorna HTTP 500 dicho nodo sera marcado como caido
server : Se configura cada nodo backend, la sintaxis es “server nombre fqdn_o_ip opciones”.

Las opciones mas usadas son:
check: Establece que se debe chequear el nodo
check port: Establece el puerto en el cual se realizara el chequeo
cookie: Establece el ID para los cookies de dicho nodo
inter: Intervalo entre chequeos
maxconn: Cantidad maxima de conexiones para dicho nodo
weight: Peso del nodo, mientras mas peso tengo, mas conexiones le caeran
backup: Se establece el nodo como backup, es decir que solo le caeran conexiones al momento que todos los nodos activos caigan


Definicion de listen

La configuracion listen es una mezcla entre frontend y backend, dentro del listen se establecen las direcciones IPs y puertos donde se escuchanb y a la vez se determinan cuales son los nodos, a diferencias del frontend tiene cierta limitaciones a la hora de tener varios backends basandose en la url para discriminar a que backend debe ir
Ejemplo basico de listen

listen MariaDB_farm 0.0.0.0:3306
    mode tcp
    option mysql-check user haproxy_check
    option tcplog
    balance source
    server  av-db1 av-db1.infratic.com:3306 check inter 5s
    server  av-db2 av-db2.infratic.com:3306 check inter 5s

Las opciones utilizadas en listen tienen el mismo significado tanto en backend como en frontend*