www.onsi.com.

ar

Cluster en Ubuntu 8.04

Autor: ganis at onsi dot com dot ar Versin: 1.0 Septiembre 2008

Introduccin:
Balanceo de carga y alta disponibilidad en Ubuntu. Dado que hay poca informacin en internet sobre este tema, decid documentar una implementacin. Palabras clave: Cluster en Linux, Load balancing, High Availability, HA con LVS, Direct Routing, Keepalived.

Mini-Howto:
Si conoce la teora, este mini-howto ahorra tiempo. ________ | | | client | (local o internet) |________| | (GW)-------------+ | | VIP | | | +--------+-------+ | ____|_____ ____|_____ | | | | | | | director | | director | | | master | | backup | | |__________| |__________| | DIP1 DIP2 | | | | +--------+---------+ | | | +----------------+---------------+ RIP1,VIP RIP2,VIP RIP3,VIP ____________ ____________ ____________ | | | | | | | realserver | | realserver | | realserver | |____________| |____________| |____________| Terminologa: VIP (IP Virtual): 192.168.6.240 DIP1 (Director Master): 192.168.6.2 DIP2 (Director Backup): 192.168.6.3 RIP1 (Servidor Real 1): 192.168.6.4 RIP2 (Servidor Real 2): 192.168.6.5 RIP3 (Servidor Real 3): 192.168.6.6

Configuracin En los directores: 1. # apt-get install keepalived 2. # nano /etc/keepalived/keepalived.conf

1-7

www.onsi.com.ar

######### /etc/keepalived/keepalived.conf #################### global_defs { notification_email { root@dominio.com } notification_email_from root@dominio.com smtp_server 127.0.0.1 smtp_connect_timeout 30 lvs_id LVS1 } virtual_server 192.168.6.240 80 { delay_loop 30 lb_algo rr lb_kind DR persistence_timeout 50 protocol TCP real_server 192.168.6.4 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 } } real_server 192.168.6.5 80 { weight 2 TCP_CHECK { connect_port 80 connect_timeout 3 } } } vrrp_instance VI_1 { state MASTER interface eth0 lvs_sync_daemon_inteface eth0 virtual_router_id 51 priority 150 advert_int 1 smtp_alert authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 192.168.6.240 } } ####### fin /etc/keepalived/keepalived.conf ############ 3. # echo 1 > /proc/sys/net/ipv4/ip_forward 4. # /etc/init.d/keepalived start En los servidores reales: 5. 6. 7. 8. 9. # # # # # ifconfig lo:0 192.168.6.240 netmask 255.255.255.255 broadcast 192.168.6.240 up route add -host 192.168.6.240 dev lo:0 echo "net/ipv4/conf/all/arp_ignore = 1" >> /etc/sysctl.conf echo "net/ipv4/conf/all/arp_announce = 2" >> /etc/sysctl.conf sysctl -p

Listo!. Si tiene ms tiempo, puede leer la forma larga de hacer lo mismo.

2-7

www.onsi.com.ar

Descripcin extensa:
Hasta el momento (primavera 2008) hay poca documentacin sobre Linux Virtual Server (LVS) en Ubuntu o Debian. La idea es la siguiente: implementar un cluster de computadoras con balanceo de carga y alta disponibilidad. El sistema tendr una sola IP, llamada IP Virtual, en esta caso 192.168.6.240. El requerimiento inicial lo atiende el director o balanceador de carga (192.168.6.2), pero redirecciona el paquete para que los servicios sean atendidos por N servidores reales. Para que este director no se convierta en un nico punto de falla, creamos la alta disponibilidad con un director backup (192.168.6.3). Lleva mas tiempo leer este artculo que poner en funcionamiento el cluster.

Imagen de http://www.estrellateyarde.es/discover/cluster-lvs-keepalived-en-linux Software: El balanceo de carga se logra con LVS. La alta disponibilidad de varias formas: Heartbeat con Ldirector, Piranha, Ultramonkey o Keepalived (hay mas formas). Usaremos Keepalived porque permite manejar el cluster con una sola herramienta. Empecemos por el balanceo de carga: LVS, ipvsadm y keepalived. Linux Virtual Server (LVS) viene integrado en el kernel de Ubuntu 8.04, por lo que no tenemos que recompilar. Slo hay que instalar la herramienta ipvsadm para agregar reglas de balanceo de carga. Ms adelante, cuando configuremos la alta disponibilidad, Keepalived instalar todo de un solo paso. La red del cluster: Existen 3 tcnicas para configurar la red de clusters con balanceo de carga: NAT, TUN y DR. Hay informacin en www.linuxvirtualserver.org. Aqu implementaremos Direct Routing (DR), porque es el ms sencillo y rpido. Tiene la limitacin de que los servidores reales y el director deben estar en el mismo segmento de red. El paquete es enviado a la IP Virtual y es atendido por el director. Este reenva a los servidores reales de acuerdo a un algoritmo de balanceo de carga (hay 7 disponibles). El servidor real contesta directamente al cliente, sin pasar por el director. La IP Virtual debe estar configurada tanto en el director como en los servidores reales. El problema ARP: Una situacin a resolver en esta configuracin es el "Problema ARP". Como varios servidores tienen la misma IP, si la publican ante un requerimiento ARP habr una competencia por el paquete, llamado "Race Condition". Para evitar eso, debemos asegurarnos que el nico que publica la direccin IP Virtual es el director, por lo que debemos deshabilitar la publicacin ARP en los servidores reales.

3-7

www.onsi.com.ar

Algoritmos de balanceo de carga Tenemos disponibles 7 algoritmos. Podemos empezar por Round Robin hasta ver que funcione, despus pasamos a Weighted Least-Connection. Podemos probar con todos: rr: Robin Robin: distribuye la carga en forma equitativa entre los servidores, una peticin a cada uno. wrr: Weighted Round Robin: proporcional a su peso. Servidores con mas peso reciben mas carga. A igual peso, igual carga. lc: Least-Connection: ms carga a servidores con menos conexiones. wlc: Weighted Least-Connection: mas carga a servidores con menos conexiones y relativo al peso. Otros: lblc: Locality-Based Least-Connection dh: Destination Hashing sh: Source Hashing Implementacin Suficiente teora. Vamos a implementar el cluster: un web server. Asumiremos que los servidores reales tienen Apache funcionando con el mismo sitio :), ya sea con un storage centralizado, mirror a travs de red (DRDB) o NFS. Ese tema no es parte de este artculo. Los directores master y backup deben tener keepalived instalado y configurado, la IP virtual configurada y habilitado el forwarding IP. Los servidores reales deben tener el servicio andando :), la IP virtual configurada en lo:0, deshabilitada la publicacin ARP y configurada una ruta esttica. 1. Instalamos Keepalived, el cual instalar ipvsadm como dependencia. # apt-get install keepalived 2. creamos el archivo de configuracin # nano /etc/keepalived/keepalived.conf Y aqu copiamos el archivo que est en el mini-howto ms arriba. 4. Habilitar ip forwarding: esto s hay que hacerlo manualmente # echo 1 > /proc/sys/net/ipv4/ip_forward 4. Arrancamos keepalived # /etc/init.d/keepalived start Starting Keepalived for LVS: 5. Comprobar la IP virtual: # ip addr sh eth0 Debemos ver algo as: inet 192.168.6.3/24 brd 192.168.6.255 scope global eth0 inet 192.168.6.240/32 scope global eth0 6. Comprobamos el cluster # ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags
4-7

[ OK ]

www.onsi.com.ar

-> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.6.240:80 wrr -> 192.168.6.4:80 Route 1 0 0 -> 192.168.6.5:80 Route 2 0 0 Esto es lo que hace keepalived: # ipvsadm -A -t 192.168.6.240:80 -s wrr # ipvsadm -a -t 192.168.6.240:80 -r 192.168.6.4 -g # ipvsadm -a -t 192.168.6.240:80 -r 192.168.6.5 -g El primer comando agrega un servicio con ip virtual y puerto (-A) protocolo TCP (-t) y algoritmo (-s) Weighted Round Robin. El segundo agrega un server real al servicio (-a) con ip real (-r) y balanceo tipo direct routing. 7. En el server real configuramos la IP Virtual y la ruta esttica: # ifconfig lo:0 192.168.6.240 netmask 255.255.255.255 broadcast 192.168.6.240 up # route add -host 192.168.6.240 dev lo:0 Para hacer la configuracin permanente, creamos un script: # nano /etc/network/if-up.d/lvs Con lo siguiente: #!/bin/sh /sbin/ifconfig lo:0 192.168.6.240 netmask 255.255.255.255 broadcast 192.168.6.240 up /sbin/route add -host 192.168.6.240 dev lo:0 Y lo hacemos ejecutable # chmod 755 /etc/network/if-up.d/static-routes 8. Deshabilitamos la publicacin ARP en /etc/sysctl.conf: # echo "net/ipv4/conf/all/arp_ignore = 1" >> /etc/sysctl.conf # echo "net/ipv4/conf/all/arp_announce = 2" >> /etc/sysctl.conf Finalmente ejecutamos: # sysctl -p 9. Listo. Simular el fallo del director master: # /etc/init.d/keepalived stop Simular el fallo en algun servidor real: # /etc/init.d/apache2 stop

Comentarios: Este archivo /etc/keepalived/keepalived.conf tiene 3 partes: global_defs: Definiciones globales.

5-7

www.onsi.com.ar

global_defs { notification_email { root@dominio.com } notification_email_from root@dominio.com smtp_server 127.0.0.1 smtp_connect_timeout 30 lvs_id LVS1 } notification_email: quin recibe el email de alerta. notification_email_from: remite del email de alerta. lvs_id: identificador del director. virtual_server: directivas de cada servidor virtual. Por ejemplo, para un servidor web en la IP virtual 192.168.6.240, puerto 80: virtual_server 192.168.6.240 80 { delay_loop 15 lb_algo rr lb_kind DR persistence_timeout 50 protocol TCP real_server 192.168.6.4 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 } } real_server 192.168.6.5 80 { weight 2 TCP_CHECK { connect_port 80 connect_timeout 3 } } } Lo importante es: lb_algo: algoritmo de balanceo de carga: rr|wrr|lc|wlc|lblc|sh|dh lb_kind: tipo de balanceo: NAT|DR|TUN real_server: servidor real perteneciente al pool. weight: peso relativo del servidor para balancear la carga. TCP_CHECK: mtodo para chequear la disponibilidad del servidor. Si tenemos ms IPs virtuales o servicios agregamos otras secciones virtual_server: por ejemplo, en la misma IP virtual 192.168.6.240 un servidor de correo en el puerto 25: virtual_server 192.168.6.240 25 { delay_loop 15 lb_algo wlc lb_kind DR persistence_timeout 50 protocol TCP sorry_server 192.168.6.2 25 real_server 192.168.6.6 25 { weight 1 TCP_CHECK { connect_port 25 connect_timeout 3 }

6-7

www.onsi.com.ar

} real_server 192.168.6.7 25 { weight 2 TCP_CHECK { connect_port 25 connect_timeout 3 } } } vrrp_instance: directivas para monitorizar los directores: vrrp_instance VI_1 { state MASTER interface eth0 lvs_sync_daemon_inteface eth0 virtual_router_id 51 priority 150 advert_int 1 smtp_alert authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 192.168.6.240 } } state: MASTER o BACKUP. priority: el master debe tener mayor prioridad. El archivo de configuracin de Keepalived en el backup es casi igual al del master, slo se diferencia en tres lneas: lvs_id: LVS2, el id debe ser distinto. priority: 100, inferior a la prioridad del master. state: BACKUP. Hay informacin completa con el comando: # man keepalived.conf

Conclusin Fin de la implementacin LVS en Ubuntu.

7-7