Balanceamento de Carga · 6 min read · Oct 08, 2025

O Cluster Web Perfeito com Balanceamento de Carga e Alta Disponibilidade com 2 Servidores Executando Xen no Ubuntu 8.04 Hardy Heron - Página 6

12. Configurando os balanceadores de carga (lb1, lb2)

12.1 Habilitar IPVS nos Balanceadores de Carga

Primeiro, devemos habilitar o IPVS em nossos balanceadores de carga. IPVS (IP Virtual Server) implementa balanceamento de carga na camada de transporte dentro do kernel do Linux, chamado de comutação de Camada 4.

echo ip_vs_dh >> /etc/modules
echo ip_vs_ftp >> /etc/modules
echo ip_vs >> /etc/modules
echo ip_vs_lblc >> /etc/modules
echo ip_vs_lblcr >> /etc/modules
echo ip_vs_lc >> /etc/modules
echo ip_vs_nq >> /etc/modules
echo ip_vs_rr >> /etc/modules
echo ip_vs_sed >> /etc/modules
echo ip_vs_sh >> /etc/modules
echo ip_vs_wlc >> /etc/modules
echo ip_vs_wrr >> /etc/modules

Então fazemos isso:

modprobe ip_vs_dh
modprobe ip_vs_ftp
modprobe ip_vs
modprobe ip_vs_lblc
modprobe ip_vs_lblcr
modprobe ip_vs_lc
modprobe ip_vs_nq
modprobe ip_vs_rr
modprobe ip_vs_sed
modprobe ip_vs_sh
modprobe ip_vs_wlc
modprobe ip_vs_wrr

12.2 Instalar Ultra Monkey (pacotes) nos Balanceadores de Carga

Instale o Ultra Monkey (pacotes) nos balanceadores de carga fazendo o seguinte:

apt-get install ipvsadm ldirectord heartbeat

12.3 Habilitar Encaminhamento de Pacotes nos Balanceadores de Carga

Os balanceadores de carga devem ser capazes de rotear o tráfego para os nós Apache. Portanto, devemos habilitar o encaminhamento de pacotes nos balanceadores de carga. Adicione as seguintes linhas ao /etc/sysctl.conf:

vi /etc/sysctl.conf

# Habilita o encaminhamento de pacotes
net.ipv4.ip_forward = 1

Então faça isso:

sysctl -p

12.4 Configurar heartbeat e ldirectord

Agora precisamos criar três arquivos de configuração para o heartbeat (cuidado com espaços e tabs se você editar em alguns editores de texto, o ldirectord é muito exigente!):

no lb1 e lb2

vi /etc/ha.d/ha.cf

logfacility local0
bcast eth0 # Linux
mcast eth0 225.0.0.1 694 1 0
auto_failback on
node lb1.example.com
node lb2.example.com
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

Importante: Como nomes de nó, devemos usar a saída de ambos:

uname -n

vi /etc/ha.d/haresources

lb1.example.com \
 ldirectord::ldirectord.cf \
 LVSSyncDaemonSwap::master \
 IPaddr2::192.168.1.106/24/eth0/192.168.1.255 \
 IPaddr2::192.168.1.107/24/eth0/192.168.1.255

Os IPs 192.168.1.106 e 107 serão usados mais tarde para websites (example.com e yoursite.com).

Este arquivo deve ser o mesmo em ambos os nós, não importa se você começar a criar o arquivo no lb1 ou lb2!

vi /etc/ha.d/authkeys

auth 3 3 md5 somerandomstring

somerandomstring é uma senha que os dois daemons do heartbeat no lb1 e lb2 usam para se autenticar um contra o outro. Use sua própria string aqui. Você tem a escolha entre três mecanismos de autenticação. Eu uso md5, pois acredito que seja o mais seguro.

/etc/ha.d/authkeys deve ser legível apenas pelo root, portanto fazemos isso:

chmod 600 /etc/ha.d/authkeys

ldirectord é o balanceador de carga real. Vamos configurar nossos dois balanceadores de carga (lb1.example.com e lb2.example.com) em uma configuração ativa/passiva, o que significa que temos um balanceador de carga ativo, e o outro é um hot-standby e se torna ativo se o ativo falhar. Para que funcione, devemos criar o arquivo de configuração do ldirectord /etc/ha.d/ldirectord.cf que novamente deve ser idêntico no lb1 e lb2.

vi /etc/ha.d/ldirectord.cf

checktimeout=5
checkinterval=5
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
#fork=yes

#PARA SMTP
virtual=192.168.1.106:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect
virtual=192.168.1.107:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect

#PARA DNS - CONECTAR NÃO FUNCIONA, DEVE SER CORRIGIDO MAS PING ESTÁ OK
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=none
        scheduler=wlc
        checktype=ping
        protocol=udp
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=dns
        scheduler=wlc
        checktype=ping
        protocol=tcp
#PARA HTTP
virtual=192.168.1.106:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Conectado ao MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800
virtual=192.168.1.107:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Conectado ao MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800

#PARA WEBMAIL
virtual=192.168.1.106:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Conectado ao MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
virtual=192.168.1.107:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Conectado ao MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
#PARA POP3
virtual=192.168.1.106:110
        real=192.168.1.104:110 gate
        fallback=192.168.1.105:110 gate
        service=pop
        checktype = connect
        scheduler=wlc
        protocol=tcp
#PARA IMAP
virtual=192.168.1.106:143
        real=192.168.1.104:143 gate
        fallback=192.168.1.105:143 gate
        service=imap
        scheduler=wlc
        protocol=tcp
#PARA HTTPS
###Descomente esta parte se você for usar HTTPS
#virtual=192.168.1.106:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirectord.php"
#        receive="Conectado ao MySQL"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#
#virtual=192.168.1.107:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirector.html"
#        receive="Página de Teste"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#PARA IMAP SSL
virtual=192.168.1.106:993
        real=192.168.1.104:993 gate
        fallback=192.168.1.105:993 gate
        service=imaps
        scheduler=wlc
        protocol=tcp
#PARA POP3 SSL
virtual=192.168.1.106:995
        real=192.168.1.104:995 gate
        fallback=192.168.1.105:995 gate
        service=pops
        checktype = ping
        scheduler=wlc
        protocol=tcp
#PARA MONIT MONITORAMENTO #1
virtual=192.168.1.106:10001
        real=192.168.1.104:10001 gate
        checktype = on
#PARA MONIT MONITORAMENTO #2
virtual=192.168.1.106:20001
        real=192.168.1.105:20001 gate
        checktype = on

virtual é o IP virtual dos serviços (por exemplo, 192.168.1.106 e 107)

real são os IPs dos servidores reais no cluster (192.168.1.104 e 105)

fallback é o servidor de backup. Se o IP real falhar, as solicitações são encaminhadas para o IP de fallback, mas não são balanceadas.

Esta configuração é baseada na minha experiência pessoal. Alguns serviços são balanceados, outros não. Tudo relacionado a e-mail não é balanceado. Você não quer que uma mensagem chegue ao primeiro servidor e a segunda no outro (a menos que você tenha armazenamento compartilhado). Se você não tiver um tráfego muito alto de e-mail, não há sentido em balancear e-mails (mas ainda é altamente disponível), o mesmo para DNS. Mais tarde, iremos rsync as mensagens no segundo servidor para que tenhamos um backup no caso de o primeiro servidor falhar.

Sobre a porta 81. Usaremos para webmail. Também a uso para a administração do nosso site de e-commerce por causa do upload de imagens. Mais tarde, configuraremos rsync de web1.example.com para web2.example.com, mas não o contrário. Basicamente, você não quer fazer upload de um arquivo em web2.example.com (a menos que use armazenamento compartilhado).

Se você quiser mais informações sobre o assunto, procure por “ldirectord man”.

Depois, criamos os links de inicialização do sistema para o heartbeat e removemos os do ldirectord porque o ldirectord será iniciado pelo daemon heartbeat:

update-rc.d -f ldirectord remove

Finalmente, iniciamos o heartbeat (e com ele o ldirectord):

/etc/init.d/ldirectord stop
/etc/init.d/heartbeat start

12.5 Testando os balanceadores de carga

Vamos verificar se ambos os balanceadores de carga funcionam como esperado:

ip addr sh eth0

O balanceador de carga ativo lb1.example.com deve listar os endereços IP virtuais (192.168.1.106 e 192.168.1.107):

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.102/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.106/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.107/24 brd 192.168.1.255 scope global secondary eth0

O hot-standby (lb2.example.com) deve mostrar algo assim:

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:34:d7:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global eth0

Agora tente:

ldirectord ldirectord.cf status

Saída no balanceador de carga ativo (lb1):

ldirectord para /etc/ha.d/ldirectord.cf está rodando com pid: 5321

Saída no balanceador de carga hot standby (lb2):

ldirectord está parado para /etc/ha.d/ldirectord.cf

Agora vamos verificar se as portas estão encaminhadas corretamente:

ipvsadm -L -n | grep :80

Você deve ver algo assim em lb1.example.com:

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

E nada em lb2.example.com.

Um último teste:

/etc/ha.d/resource.d/LVSSyncDaemonSwap master status

Saída no balanceador de carga ativo:

master rodando (ipvs_syncmaster pid: 5470)

Saída no hot-standby:

master parado

12.6 Testando a falha dos balanceadores de carga

lb1.example.com

/etc/init.d/heartbeat stop

O comando ipvsadm:

ipvsadm -L -n | grep :80

deve não retornar nada.

Em lb2.example.com

ipvsadm -L -n | grep :80

e você deve ver o seguinte:

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

Reinicie o serviço heartbeat em lb1.example.com:

/etc/init.d/heartbeat start

Se você tentar novamente o comando ipvsadm em ambos, verá que lb1.example.com agora está ativo enquanto lb2.example.com voltou ao modo standby.

Se seu teste foi bem, você pode prosseguir.

Share: X/Twitter LinkedIn
#Balanceamento de Carga

Receba novas postagens na sua caixa de entrada

Sem spam. Cancele a assinatura a qualquer momento.