Roteamento e balanceamento HTTP básico com HAProxy

Posted on by

Olá de novo! Hoje vamos falar de encaminhamento e equilíbrio HTTP básico com HAProxy.

O que é HAProxy?

HAProxy é um software que nos permite executar o balanceamento de carga sobre HTTP ou TCP (não permite o balanceamento UDP).

Características

  • Permite SSL configurado em HAProxy e/ou no backend
  • Suporte IPv6
  • Admite ACL
  • Possibilita VirtualHosts
  • Pode configurar Healthchecks ou verificações de estado dos backends.
  • Permite o HTTP Keep-Alive

Principais modos de trabalho

Tem duas formas de trabalhar:

  • Modo TCP: Pode equilibrar entre múltiplos servidores SSH, MySQL, SMTP, etc.
  • Modo HTTP: Utilizando normas HTTP e HTTPS, pode efectuar o equilíbrio entre vários servidores web e modificar os cabeçalhos de ligação.

Formas de equilibrar

Pode equilibrar-se com base nas seguintes políticas:

  • Roundrobin: equilíbrio entre os diferentes servidores backend.
  • Leastconn: Equilíbrio tendo em conta que o número de ligações redireccionadas é feito de uma forma equilibrada entre os backends. Recomendado para ligações longas
  • Source: O pedido pode ser equilibrado para que, dependendo do PI do pedido, os seguintes pedidos vão sempre para o mesmo backend.

Sticky sessions

Algumas aplicações podem exigir que o utilizador se ligue ao mesmo servidor back end. Isto é conseguido através de Sessões Pegajosas utilizando o parâmetro de aplicação no backend que o requer.

Exemplo de equilíbrio por defeito

Por defeito, o rolo será roundrobin.

root@haproxy:~# cat /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 expose-fd listeners
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
	log	global
	mode	http
	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

frontend web1
       bind *:80
       mode http
       use_backend web1
       default_backend web1

backend web1
   mode http
   server s1 172.17.0.3:80 
   server s2 172.17.0.4:80
root@haproxy:~#

En el ejemplo se balancea el puerto 80 de todas las IPs de la maquina y se destinan al backend web1 que está compuesto por los servidores s1 (172.17.0.3) y s2 (172.17.0.4). Para verlo mejor en lo ejemplos que hagamos, el s1 es es Nginx y el s2 es Apache:

[ger-pc ~]# curl -s 172.17.0.3|grep nginx -i|head -n 1
<title>Welcome to nginx!</title>
[ger-pc ~]# curl -s 172.17.0.4|egrep "apache|nginx" -i|head -n 1
<address>Apache/2.4.52 (Debian) Server at 172.17.0.4 Port 80</address>
[ger-pc ~]#

O servidor haproxy é configurado no IP 172.17.0.2. Se lhe forem feitos pedidos, ele equilibra entre os 2 backends:

[ger-pc ~]# curl -s 172.17.0.2|egrep "apache|nginx" -i|head -n 1
<title>Welcome to nginx!</title>
[ger-pc ~]# curl -s 172.17.0.2|egrep "apache|nginx" -i|head -n 1
<address>Apache/2.4.52 (Debian) Server at 172.17.0.2 Port 80</address>
[ger-pc ~]# curl -s 172.17.0.2|egrep "apache|nginx" -i|head -n 1
<title>Welcome to nginx!</title>
[ger-pc ~]# curl -s 172.17.0.2|egrep "apache|nginx" -i|head -n 1
<address>Apache/2.4.52 (Debian) Server at 172.17.0.2 Port 80</address>
[ger-pc ~]#

Exemplo de vários tipos de balanceamento

Para modificar o tipo de equilíbrio, o balanço da declaração é especificado juntamente com o nome do tipo de equilíbrio:

Roundrobin

backend web1
    mode http
    balance roundrobin
        server s1 172.17.0.3:80 weight 2
        server s2 172.17.0.4:80 weight 1

Cada servidor tem um peso definido pela declaração de weight e o número do seu peso. Quanto mais alto for o número de peso, maior é a probabilidade de receber pedidos. No exemplo acima, o servidor s1 receberá mais pedidos.

Source

backend web1
    mode http
    balance source
        server s1 172.17.0.3:80 
        server s2 172.17.0.4:80

Leastconn

backend web1
    mode http
    balance leastconn
        server s1 172.17.0.3:80 
        server s2 172.17.0.4:80

Healthchecks

Os healthchecks são testes que são realizados para verificar o estado dos servidores backend para saber se estão disponíveis e assim redireccionar os pedidos apenas para aqueles que estão em boas condições.

Se um destes servidores for abaixo, com a configuração básica que estabelecemos acima, não fazendo verificações de saúde, os pedidos poderiam ser redireccionados para o backend que está abaixo.

Isto pode ser resolvido adicionando verificações ao back end usando o parâmetro de verificação na declaração do servidor que define o servidor back end:

backend web1
   mode http
   server s1 172.17.0.3:80 check
   server s2 172.17.0.4:80 check

Healthchecks activos

Os Healthchecks activos são aqueles que são realizados por defeito quando apenas especificamos a palavra verificação, como no exemplo acima. Este tipo de verificações são realizadas periodicamente para os backends.

A estrutura é a seguinte:

server nombre host:puerto check inter tiempo fall numero rise numero

Os parâmetros de verificação padrão são feitos desta forma com o :

backend web1 
mode http
server s1 172.17.0.3:80 check inter 2s fall 3 rise 2
server s2 172.17.0.4:80 check inter 2s fall 3 rise 2

O significado dos parâmetros de verificação são os seguintes:

  • inter: Define o tempo de separação entre as verificações (por defeito 2 segundos).
  • fall:Número de verificações a marcar como backend que estava a decorrer
  • rise:Número de verificações a marcar como óptimo um backend que estava em baixo.

Pode ver mais sobre healthchecks em https://www.haproxy.com/blog/how-to-enable-health-checks-in-haproxy/

 

Deixe um comentário