IPCIISA - Prof.

: Juan Fco Huichipoco

Alta disponibilidad para

cluster de Apache
Informe técnico
Carlos Fuentealba / Bastian Salinas / Jimmy Rojas

N.O.S.
INDICE

I. OBJETIVO ......................................................................................................................................... 3

II. RECURSOS UTILIZADOS .................................................................................................................. 3

III. DISEÑO ........................................................................................................................................... 3

IV. IMPLEMENTACIóN ......................................................................................................................... 5

V. CONCLUSIÓN ................................................................................................................................ 11

VI. REFERENCIA ................................................................................................................................. 11

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

 I. OBJETIVO
El objetivo de este proyecto, consiste en utilizar software libre para disponibilizar de una solución
de HA (High-Availability) ó Alta Disponibilidad en español para un Cluster Apache, el cual brindara
de una disponibilidad continua al servicio sin interrupciones para el usuario final.

Debido a los recursos disponibles, esta solución se desarrollo bajo maquinas virtuales (4) mas un
cliente que se utilizó para realizar las pruebas finales de aceptación, lo que en total nos deja con 5
maquinas virtuales.

II. RECURSOS UTILIZADOS

Para implementar esta solución se utilizaron los siguientes softwares y S.O.

 VirtualBox, fue el software escogido para realizar el levantamiento de las maquinas

virtuales utilizadas para este piloto.
 UltraMonkey, es el software que brinda la solución de Heartbeat y H.A. para los servicio
que sean necesarios (WWW, FTP, SSH, etc.)
 Apache, Demonio para publicar contenido en la web.
 Debian, Sistema operativo virtualizado que se utilizo para montar la solución.
 Windows 7, Sistema operativo huésped en el cual se monto la solución}

III. DISEÑO
El sistema cuenta con un diseño limitado dada la estructura base en la cual se ha montado, pero
dentro de sus capacidades, esta puede soportar un sinnúmero de equipos trabajando
sincronizadamente, el cual permite un crecimiento lineal y exponencial a la plataforma en
cuestión.

Además, la configuración de red aplicada en este piloto no es imperativa para otro tipo de
soluciones, los equipos pueden trabajar dentro de redes privadas y públicas, permitiendo
optimizar la utilización de recursos en la empresa.

En la siguiente imagen (ref.: img. 1) podemos observar como la solución se compone de 5 nodos,
los cuales se dividen en:

- 2 Balanceadores (OpenMonkey)
- 2 WebServer (Apache v2)
- 1 PC Cliente.

Los balanceadores funcionan en modalidad activo/pasivo (master/slave), dentro de su

3
configuración se destaca la opción de comunicación entre ellos, generando un heartbeat (latido),
el cual permite de cada uno de ellos sepa si su contraparte se encuentra disponible o no.

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

Por lo tanto, solo un equipo mantiene disponible la IP Virtual y el otro se encuentra en reposo
hasta que deba tomar el mando de la atención de requerimientos por parte de los clientes.

Luego se encuentran los 2 Webserver, los cuales cumplen como función simplemente hospedar
contenido web. Esta solución puede ser complementada con un NAS para optimizar y asegurar la
disponibilidad de contenido (no aplicado en este piloto).

Img. 1

http://10.0.0.2/index.html

VIP: 10.0.0.2

Se realiza Heartbeat
para comprobar la
disponibilidad

10.0.0.3 10.0.0.4

cluster Apache

10.0.0.10 10.0.0.20

Solución Virtualizada

El cliente o consola virtual, será el responsable de visualizar el contenido y verificar que se esté
realizando la alta disponibilidad y balanceo de información.

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

 IV. IMPLEMENTACIóN
El sistema de nodos virtuales Linux, se implemento bajo el S.O. Debian 5.04 (Lenny) versión
estable. Se escogió este S.O. debido a su fácil administrador de aplicaciones (apt) lo que facilita de
sobremanera la implantación de las aplicaciones.

Nos referiremos a los nodos de la siguiente manera:

- Nodo Apache 1 (ws01): 10.0.0.10 Documentos de Apache: /var/www

- Nodo Apache 2 (ws02): 10.0.0.20 Documentos de Apache: /var/www
- Nodo Balanceador 1 (lb01): 10.0.0.3
- Nodo Balanceador 2 (lb02): 10.0.0.4
- IP Virtual ó VIP: 10.0.0.2

1. Habilitar IPVS en los balanceadores de carga

IPVS (que quiere decir IP Virtual Server), es utilizado para realizar el balanceo de carga a
nivel del kernel de Linux, lo cual nos permite un IO optimizado (esto quiere decir que se
implementa una capa de transporte en capa 4 del modelo OSI).
Esta configuración es aplicada en los nodos lb01 y lb02

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

Una vez realizado esto, procedemos a cargar los modulos en el sistema (esto también se
puede realizar reiniciando la maquina, el problema es que al hacer esta opción, podríamos
no ver posibles errores que envíe el sistema al no tener soportada la funcionalidad de
IPVS).

modprobe ip_vs_dh
modprobe ip_vs_ftp
modprobe ip_vs 5
modprobe ip_vs_lblc
modprobe ip_vs_lblcr
modprobe ip_vs_lc
modprobe ip_vs_nq

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

 modprobe ip_vs_rr
modprobe ip_vs_sed
modprobe ip_vs_sh
modprobe ip_vs_wlc
modprobe ip_vs_wrr

En caso de obtener algún tipo de error, quiere decir que el kernel no soporta IPVS, por lo
cual se debe obtener una versión que si lo haga.

2. Instalar UltraMonkey en los balanceadores de carga

Ultra Monkey es un software desarrollado para montar una solución de balanceo de carga
(ldirectord) y alta disponibilidad (heartbeat) usando los componentes que contiene el
kernel del S.O. Linux.
Para esto, editaremos nuestro archivo de configuración de apt, el cual cuenta con los
repositorios de aplicaciones ubicado en /etc/apt/sources.list y añadiremos lo siguiente:

deb http://www.ultramonkey.org/download/3/ sarge main

deb-src http://www.ultramonkey.org/download/3 sarge main

Una vez realizado esto, actualizaremos nuestra lista de paquetes disponibles:

apt-get update

E instalaremos Ultra Monkey

apt-get install ultramonkey

3. Habilitar “Packet Forwarding” en los balanceadores de carga

Utilizaremos esta opción para que los balanceadores de carga sean capaces de redirigir
tráfico hacia nuestro cluster de Apache. Esto lo realizamos añadiendo las siguientes líneas
en nuestro archivo /etc/sysctl.conf

vi /etc/sysctl.conf

Descomentar la línea siguiente línea

# Enables packet forwarding

net.ipv4.ip_forward = 1

Una vez realizado, guarder y ejecutar el siguiente commando (para que el sistema vuelva a 6
leer el archivo de configuración

sysctl –p

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

4. Configurar Heartbeat y Ldirector

Recuerden que estos archivos deben ser idénticos en todos los balanceadores de carga
que tengan.

vi /etc/ha.d/ha.cf

logfacility local0
bcast eth0 # Linux
mcast eth0 225.0.0.1 694 1 0
auto_failback off
node loadb1
node loadb2
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

Donde lb01 es el nombre del balanceador que estarán ocupando y la IP 10.0.0.2 es la VIP.

vi /etc/ha.d/haresources

lb01 \
ldirectord::ldirectord.cf \
LVSSyncDaemonSwap::master \
IPaddr2::10.0.0.2/24/eth0/10.0.0.255

Ahora configuraremos nuestra llave compartida, la cual permitirá a los sistemas

comunicarse entre sí.

vi /etc/ha.d/authkeys

auth 3
3 md5 cualquierstring

Donde “cualquierstring” como su nombre lo dice, puede ser cualquier palabra que se
desee, solo recorder que esto debe estar configurado en todos los nodos que utilizará para
implementar balanceo de carga.
Además modificaremos los privilegios del archive para que solo pueda ser visto por el
usuario root.

chmod 600 /etc/ha.d/authkeys

Procederemos a configurar el demonio ldirectord el cual cumple la función de definir cual

el balanceador que mantendrá su estado de “activo/pasivo” en la arquitectura. Esto lo
realizaremos modificando el archivo que se encuentra en /etc/ha.d/ldirectord.cf el cual 7
debe ser equivalente en los “n” balanceadores de carga con cuales se cuente.

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

 vi /etc/ha.d/ldirectord.cf

checktimeout=10
checkinterval=2
autoreload=no
logfile="local0"
quiescent=yes

virtual=10.0.0.2:80
real=10.0.0.10:80 gate
real=10.0.0.20:80 gate
fallback=127.0.0.1:80 gate
service=http
request="ldirector.html"
receive="Test Page"
scheduler=rr
protocol=tcp

Ahora para que nuestro demonio se arranque cada vez que iniciamos el S.O. deberemos
instanciarlo en la estructura de arranque de la siguiente manera:

update-rc.d heartbeat start 75 2 3 4 5 . stop 05 0 1 6 .

update-rc.d -f ldirectord remove

5. Realizar pruebas en los balanceadores de carga

Para verificar que nuestras configuraciones sean adecuadas y el chequeo de nuestros

demonios se encuentre operativo, realizaremos las siguientes pruebas en los
balanceadores.

ip addr sh eth0

De lo cual obtendremos (desde el servidor activo o master)

2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 00:16:3e:40:18:e5 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.3/24 brd 10.0.0.255 scope global eth0
inet 10.0.0.2/24 brd 10.0.0.255 scope global secondary eth0

Para el servidor inactive o slave

2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 00:16:3e:50:e3:3a brd ff:ff:ff:ff:ff:ff
inet 10.0.0.4/24 brd 10.0.0.255 scope global eth0
8

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

6. Configurar los nodos con Apache

Para esto, descargaremos los aplicativos a través de apt-get y realizaremos modificaciones

en los archivos de configuración del S.O. con lo cual permitiremos recibir trafico
redireccionado por nuestros balanceadores de carga.

(En los “n” servidores apache a utilizar)

vi /etc/sysctl.conf

# Enable configuration of arp_ignore option

net.ipv4.conf.all.arp_ignore = 1

# When an arp request is received on eth0, only respond if that address

# is configured on eth0. In particular, do not respond if the address is
# configured on lo
net.ipv4.conf.eth0.arp_ignore = 1

# Ditto for eth1, add for all ARPing interfaces

#net.ipv4.conf.eth1.arp_ignore = 1

# Enable configuration of arp_announce option

net.ipv4.conf.all.arp_announce = 2

# When making an ARP request sent through eth0 Always use an address
# that is configured on eth0 as the source address of the ARP request.
# If this is not set, and packets are being sent out eth0 for an address
# that is on lo, and an arp request is required, then the address on lo
# will be used. As the source IP address of arp requests is entered into
# the ARP cache on the destination, it has the effect of announcing this
# address. This is not desirable in this case as adresses on lo on the
# real-servers should be announced only by the linux-director.
net.ipv4.conf.eth0.arp_announce = 2

# Ditto for eth1, add for all ARPing interfaces

#net.ipv4.conf.eth1.arp_announce = 2

Para que el sistema vuelva a leer la configuración del demonio, ejecutamos el siguiente
comando.

sysctl –p

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

Una vez realizado lo anterior, deberemos habilitar una interfaz virtual en el equipo, el cual
nos permitira aceptar requerimientos de Servicios a través de ella (redireccionadas desde
nuestros balanceadores de carga).

vi /etc/network/interfaces

auto lo:0
iface lo:0 inet static
address 192.168.0.105
netmask 255.255.255.255
pre-up sysctl -p > /dev/null

ifup lo:0

Como último, escribiremos nuestra página web a mostrar al cliente final.

vi /var/www/ldirector.html

Test Page

10

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público

V. CONCLUSIÓN
La arquitectura presentada podría ser una de las formas de interpretar la computación a nivel
distribuido o la famosamente llamada “Cloud Computing”, aplicando tecnologías libres como
lo son los software que acabamos de manipular.

Nos permiten igualar soluciones pagadas a un costo mínimo y potenciar nuestra

infraestructura como único fin, mejorar la disponibilidad de la información hacia el usuario
final.

Desde el punto de vista de virtualización, se debe tener claro si se planea virtualizar alguno de
estas funcionalidades, los requerimientos técnicos del huésped deben ser de muy alta
capacidad, con el fin de no estancar la capacidad de computo de cada nodo que preste
servicios, además deben ser capaces de ser sostenibles en el tiempo (es decir, tener holgura).

VI. REFERENCIA

El material ilustrado en este documento fue obtenido desde Internet desde sitios como
Wikipedia, Apache Foundation, Ultra Monkey (sitio oficial), y conocimiento personal de todos
los involucrados.

Links:

- (Ultra Monkey) http://www.ultramonkey.org/

- (IPVS, IP Virtual Server) http://en.wikipedia.org/wiki/IP_Virtual_Server
- (Apache) http://httpd.apache.org/
- (Debian) http://www.debian.org/

11

IPCIISA - Prof.: Juan Fco Huichipoco | Material de uso público