Balanceo de carga · 6 min read · Oct 08, 2025

El Clúster Web Perfecto Balanceado y de Alta Disponibilidad Con 2 Servidores Ejecutando Xen En Ubuntu 8.04 Hardy Heron - Página 6

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

12.1 Habilitar IPVS En Los Balanceadores De Carga

Primero debemos habilitar IPVS en nuestros balanceadores de carga. IPVS (IP Virtual Server) implementa balanceo de carga en la capa de transporte dentro del núcleo de Linux, conocido como conmutación de Capa-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

Luego hacemos esto:

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 (paquetes) En Los Balanceadores De Carga

Instalar Ultra Monkey (paquetes) en los balanceadores de carga haciendo lo siguiente:

apt-get install ipvsadm ldirectord heartbeat

12.3 Habilitar Reenvío De Paquetes En Los Balanceadores De Carga

Los balanceadores de carga deben ser capaces de enrutar el tráfico a los nodos de Apache. Por lo tanto, debemos habilitar el reenvío de paquetes en los balanceadores de carga. Agregue las siguientes líneas a /etc/sysctl.conf:

vi /etc/sysctl.conf

# Habilita el reenvío de paquetes
net.ipv4.ip_forward = 1

Luego haga esto:

sysctl -p

12.4 Configurar heartbeat Y ldirectord

Ahora tenemos que crear tres archivos de configuración para heartbeat (¡cuidado con los espacios y tabulaciones si editas en algunos editores de texto, ldirectord es muy exigente!) :

en lb1 y 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 nombres de nodo debemos usar la salida 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

Las IPs 192.168.1.106 y 107 se utilizarán más tarde para los sitios web (example.com y yoursite.com).

Este archivo debe ser el mismo en ambos nodos, ¡no importa si comienzas a crear el archivo en lb1 o lb2!

vi /etc/ha.d/authkeys

auth 3 3 md5 somerandomstring

somerandomstring es una contraseña que los dos demonios de heartbeat en lb1 y lb2 utilizan para autenticarse entre sí. Usa tu propia cadena aquí. Tienes la opción entre tres mecanismos de autenticación. Yo uso md5 ya que creo que es el más seguro.

/etc/ha.d/authkeys debe ser legible solo por root, por lo tanto hacemos esto:

chmod 600 /etc/ha.d/authkeys

ldirectord es el balanceador de carga real. Vamos a configurar nuestros dos balanceadores de carga (lb1.example.com y lb2.example.com) en una configuración activa/pasiva, lo que significa que tenemos un balanceador de carga activo, y el otro es un respaldo en caliente y se vuelve activo si el activo falla. Para que funcione, debemos crear el archivo de configuración de ldirectord /etc/ha.d/ldirectord.cf que nuevamente debe ser idéntico en lb1 y 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 NO FUNCIONA, DEBE SER PARCHEADO PERO PING ESTÁ BIEN
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 a 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 a 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 a 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 a 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
###Descomentar esta parte si vas a 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 a 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 Prueba"
#        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 MONITOREO #1
virtual=192.168.1.106:10001
        real=192.168.1.104:10001 gate
        checktype = on
#PARA MONIT MONITOREO #2
virtual=192.168.1.106:20001
        real=192.168.1.105:20001 gate
        checktype = on

virtual es la IP virtual de los servicios (por ejemplo 192.168.1.106 y 107)

real son las IPs de los servidores reales en el clúster (192.168.1.104 y 105)

fallback es el servidor de respaldo. Si la IP real falla, entonces las solicitudes se reenvían a la IP de respaldo, pero no están balanceadas.

Esta configuración se basa en mi experiencia personal. Algunos servicios están balanceados, otros no. Todo lo relacionado con el correo no está balanceado. No quieres que un mensaje llegue al primer servidor y el segundo al otro (a menos que tengas almacenamiento compartido). Si no tienes un tráfico de correo muy alto, no tiene sentido balancear el correo (pero sigue siendo altamente disponible), lo mismo para DNS. Más adelante sincronizaremos los mensajes en el segundo servidor, por lo que tendremos un respaldo en caso de que falle el primer servidor.

Sobre el puerto 81. Lo usaremos para webmail. También lo uso para la administración de nuestro sitio web de comercio electrónico debido a la carga de imágenes. Más adelante configuraremos rsync de web1.example.com a web2.example.com, pero no al revés. Básicamente, no quieres cargar un archivo en web2.example.com (a menos que uses almacenamiento compartido).

Si deseas obtener más información sobre el tema, busca “ldirectord man”.

Después creamos los enlaces de inicio del sistema para heartbeat y eliminamos los de ldirectord porque ldirectord será iniciado por el demonio de heartbeat:

update-rc.d -f ldirectord remove

Finalmente, iniciamos heartbeat (y con él ldirectord):

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

12.5 Probar los balanceadores de carga

Verifiquemos si ambos balanceadores de carga funcionan como se espera:

ip addr sh eth0

El balanceador de carga activo lb1.example.com debería listar las direcciones IP virtuales (192.168.1.106 y 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

El respaldo en caliente (lb2.example.com) debería mostrar algo como esto:

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

Ahora prueba:

ldirectord ldirectord.cf status

Salida en el balanceador de carga activo (lb1):

ldirectord for /etc/ha.d/ldirectord.cf is running with pid: 5321

Salida en el balanceador de carga en espera (lb2):

ldirectord is stopped for /etc/ha.d/ldirectord.cf

Ahora verificaremos si los puertos están reenviados correctamente:

ipvsadm -L -n | grep :80

Deberías ver algo como esto en 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

Y nada en lb2.example.com.

Una última prueba:

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

Salida en el balanceador de carga activo:

master running (ipvs_syncmaster pid: 5470)

Salida en el respaldo en caliente:

master stopped

12.6 Probar la conmutación por error de los balanceadores de carga

lb1.example.com

/etc/init.d/heartbeat stop

El comando ipvsadm:

ipvsadm -L -n | grep :80

debería no mostrar nada.

En lb2.example.com

ipvsadm -L -n | grep :80

y deberías ver lo siguiente :

  -> 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

Reinicia el servicio de heartbeat en lb1.example.com:

/etc/init.d/heartbeat start

Si vuelves a intentar el comando ipvsadm en ambos, verás que lb1.example.com ahora está activo mientras lb2.example.com volvió a estar en espera.

Si tu prueba fue bien, puedes continuar.

Share: X/Twitter LinkedIn
#Balanceo de carga

Recibe nuevas publicaciones en tu bandeja de entrada.

No spam. Cancela la suscripción en cualquier momento.