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 configuraciondefaults
.
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 /gitLas 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 deuse_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 configuraciondefaults
.
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
*