PROYECTO DE TI

GOBIERNO REGIONAL DE LAMBAYEQUE

MANUAL

CONFIGURACIN DE CLSTER GRL DE BALANCEO DE

CARGA

CON ALTA DISPONIBILIDAD A NIVEL DE

BALANCEADORES

1
 CONTENIDO

1. DESCRIPCIN GENERAL................................................................................ 3

2. ACCESO A LOS NODOS Y BALANCEADORES DEL CLSTER...........................7

3. SERVIDORES COMPONENTES DEL CLSTER:.................................................8

4. MAQUINAS VIRTUALES KVM........................................................................10

5. BALANCEO DE CARGA LVS..........................................................................11

6. MONITORIZACIN DEL CLSTER:................................................................14

7. MANTENIMIENTO DEL CLSTER:.................................................................17

8. CONCLUSIONES Y SUGERENCIAS................................................................19

9. MATERIAL WEB DE CONSULTA:....................................................................20

2
1. DESCRIPCIN GENERAL

El presente manual pretende introducir al usuario en la utilizacin y

mantenimiento del sistema clster configurado en los servidores del
Gobierno Regional de Lambayeque (GRL).

El GRL posee ahora un sistema clster de balanceo de carga con alta

disponibilidad a nivel de balanceadores, para los servicios web apache y
tomcat. Est clster permitir la continuidad de los servicios en casos de
fallos o por mantenimiento.

Este clster est configurado sobre un IBM Bladecenter HS23, utilizando

para ello dos cuchillas, en cada cuchilla una mquina virtual y para el
almacenamiento de scripts y documentos un storage IBM Storwize V7000.
Cada servidos fsico o virtual trabaja bajo el sistema operativo Red Hat
Enterprise Linux Versin 6.3.

DIAGRAMA FSICO DEL CLSTER RGL (Diagrama N 1)

3
El diagrama N 1 muestra la distribucin fsica de los equipos y servidores
que contiene el clster, donde:
- B1-BSW1 es la cuchilla N 1 del chasis del bladecenter que brindar los
servicios Apache y Tomcat.
- B8-DB2 es la cuchilla N 8 del chasis del bladecenter que brindar los
servicios Apache y Tomcat.
- B1-sv-bsw1 es una mquina virtual de la cuchilla 1 que funcionar como
balanceador, reenviando las peticiones hacia los servidores B1-BSW1 y
B8-DB2. Utilizando la solucin de virtualizacin KVM Kernel-based Virtual
Machine y el software de balanceo de carga LVS Linux Virtual Server.
- B8-sv-bsw2 o (piranha2) es una mquina virtual de la cuchilla 8 que
funcionar como balanceador, reenviando las peticiones hacia los
servidores B1-BSW1 y B8-DB2. Utilizando la solucin de virtualizacin
KVM Kernel-based Virtual Machine y el software de balanceo de carga
LVS Linux Virtual Server.
- Las direcciones IP 172.16.0.150 y 172.16.0.155 son direcciones virtuales
que se utilizarn para brindar los servicios web Apache y Tomcat
respectivamente.

4
DIAGRAMA LGICO DEL CLUSTER GRL (Diagrama N 02)

5
El software utilizado para el balanceo en Linux se llama Linux Virtual Server
(LVS) la cul es una solucin de cdigo abierto de alto rendimiento en
clustering.

En el grfico lgico del clster, las solicitudes de los usuarios llegan al

balancedor LVS en nuestro caso al servidor virtual b1-sv-bsw1, quien posee
las direcciones virtuales (VIP) y el software que utiliza LVS, una direccin
VIP migra de un balanceador a otro durante el proceso de recuperacin de
fallos, de esa forma se mantiene la direccin VIP activa.

El rol del balanceador activo es de redirigir las solicitudes de la direccin IP

Virtual a los servidores reales, esta redireccin est basada en un algoritmo
de balanceo de carga. Este balanceador sondea dinmicamente la salud de
los servicios especificados en los servidores reales a travs de un script de
envi y espera, si un servicio en un servidor real no funciona

6
adecuadamente, el balanceador activo no enva solicitudes a este servidor
hasta que retorne la operacin normal.

El balanceador backup (en nuestro caso b8-sv-bsw2) ejecuta el rol de

sistema en espera, peridicamente los balanceadores LVS intercambian
mensajes mediante el servicio PULSE y en caso de fallos, Si el enrutador
LVS de respaldo no recibe un mensaje dentro de un intervalo de tiempo
esperado, este inicia un proceso de recuperacin contra fallos y asume el
rol de balanceador activo, durante el proceso de recuperacin contra fallos,
el enrutador de respaldo obtiene las direcciones VIP servidas por el
enrutador fallido.

Cada uno de los servidores reales accede a la fuente de datos del Storage
mediante canal de fibra y utilizando el sistema de archivos distribuido GFS2
(Global File System), este sistema de archivos permite el trabajo
simultaneo de los datos, necesario para el clster.

7
 2. ACCESO A LOS NODOS Y BALANCEADORES DEL
CLSTER
Los servidores configurados tienen comunicacin directa con la red LAN del
GRL as que ser necesario solamente una conexin SSH (Secure SHell)
desde un terminal Linux o Windows, las distintas interfaces y direcciones IP
se muestran a continuacin:

SERVIDO INTERFA DIRECCI MSCARA FUNCIN

R CE N IP
B1-bsw1 Eth2 - - Componente del Bridge
br2
B1-bsw1 Eth3 - - Componente del Bridge
br3
B1-bsw1 Br2 - - Interface de salida de
mquina virtual b1-sv-
bsw1
B1-bsw1 Br3 172.16.0.15 255.255.25 Direccin IP principal del
1 4.0 equipo
B1-bsw1 Br3 172.16.50.3 255.255.25 Direccin IP del blade
5 5.0 que interconecta con el
AMM (Advanced
Management Module)
B1-sv- Eth0 - - Componente del Bridge
bsw1 br0
B1-sv-bsw1 Br0 172.16.0.17 255.255.25 Direccin IP principal del
3 4.0 servidor
B1-sv- Br0:1 172.16.0.15 255.255.25 Direccin IP Virtual del
bsw1 0 4.0 Clster
B1-sv- Br0:2 172.16.0.15 255.255.25 Direccin IP Virtual del
bsw1 5 4.0 Clster
B8-db2 Eth2 - - Componente del Bridge
br2
B8-db2 Eth3 - - Componente del Bridge
br3
B8-db2 Br2 - - Interface de salida de
mquina virtual b8-sv-
bsw2
B8-db2 Br3 172.16.0.15 255.255.25 Direccin IP principal del
3 4.0 equipo
B8-db2 Br3 172.16.50.3 255.255.25 Direccin IP del blade

8
 6 5.0 que interconecta con el
AMM (Advanced
Management Module)
B8-sv- Eth0 - - Componente del Bridge
bsw2 br0
B8-sv- Br0 172.16.0.16 255.255.25 Direccin IP principal del
bsw2 0 4.0 equipo

3. SERVIDORES COMPONENTES DEL CLSTER:

El IBM Storwize exporta 3 (tres) LUN o Logical Unit Number, que son
vistas como unidades de discos duros en los servidores B1-bsw1 y B8-
db2, estas LUN son formateadas y montadas como GFS2:

En B1-bsw1:

Dispositivo Punto de Montaje

/ /var/www/html
dev/mapper/mpathdp1
/ /var/lib/tomcat6
dev/mapper/mpathcp1
/ /var/www/docs
dev/mapper/mpathbp1

En B8-db2

Dispositivo Punto de Montaje

/dev/mapper/mpathip1 /var/www/html
/ /var/www/docs
dev/mapper/mpathhp1
/ /var/lib/tomcat6
dev/mapper/mpathgp1

El sistema de archivos GFS2 necesita ser formateado sobre un clster es

por esto que es necesario la suite de clustering llamada Conga, de Red

9
 Hat. Conga se encarga de formar el clster (necesario) y configurar los
servicios de alta disponibilidad, los cuales no ser necesario utilizar ya
que el clster lo conformar el sistema de balanceo LVS.

El archivo de configuracin del clster en ambas cuchillas se encuentra

en /etc/cluster/cluster.conf:

<?xml version="1.0"?>
<cluster config_version="28" name="cluster01">
<clusternodes>
<clusternode name="172.16.0.151" nodeid="1">
<fence>
<method name="1">
<device name="fencing_bladecenter"
port="1"/>
</method>
</fence>
</clusternode>
<clusternode name="172.16.0.153" nodeid="2">
<fence>
<method name="1">
<device name="fencing_bladecenter"
port="8"/>
</method>
</fence>
</clusternode>
</clusternodes>
<cman expected_votes="1" two_node="1"/>
<fencedevices>
<fencedevice agent="fence_bladecenter"
ipaddr="172.16.50.10" login="USERID" name="fencing_bladecenter"
passwd="PASSW0RD" power_wait="10"/>
</fencedevices>
</cluster>

Dnde:

- cluster config_version="28" : Es el identificador de cambios, si se

realiza un cambio este nmero debe aumentar en 1.
- Clusternode : Identifica un nodo, el nodo 1 se llama
"172.16.0.151" y el nodo 2 se llama "172.16.0.153".
- Method : Indica el mtodo de bloqueo o fencing, en
nuestro caso usamos "fencing_bladecenter", mientras que port
indica el nmero de la cuchilla en nuestro caso cuchilla 1 y cuchilla
8.

10
- Fencedevices : Indica el dispositivo utilizado para
fencing, como se trata de un bladecenter usamos el AMM, configurando
su direccin IP, login y password

Es necesario que ambos nodos tengan el mismo archivo de configuracin.

Los servicios necesarios para el correcto funcionamiento del

cluster son:

Libvirtd: Daemon principal para la gestin de mquinas virtuales KVM

Rgmanager: Gestiona y supervisa los recursos del clster definidos por el

usuario, si un recurso falla en un nodo, rgmanager se encarga de mover el
recurso a otro nodo (alta disponibilidad utilizando conga).

Modclusterd: Utilizado para la gestin remota del clster

Cman: Una abreviatura de cluster manager, realiza la gestin de clusters

en la adicin de Alta disponibilidad para Red Hat Enterprise Linux

Gfs2: Daemon principal del sistema de archivos distribuido GFS2

Clvmd: Es el demonio que distribuye las actualizaciones LVM en un clster.

Se debe ejecutar en todos los nodos del clster.

4. MAQUINAS VIRTUALES KVM

Son las encargadas del balanceo de carga, los servicios necesarios para
su correcto funcionamiento son:
Pulse - daemon para el seguimiento del estado de los
balanceadores
Piranha-gui - servicio de entorno web para administracin del
sistema de balanceo

Caractersticas de las mquinas virtuales:

Mquina virtual de la cuchilla 1:
Nombre: b1-sv-bsw1
UUID: 676d924f-830a-8927-2e0a-e9ad970830b9
Tipo de sistema operativo: hvm
Estado: ejecutando
CPU(s): 2
hora del CPU: 26595,1s
Memoria mxima: 4194304 KiB
Memoria utilizada: 4194304 KiB

11
 Persistente: si
Autoinicio: activar

Mquina virtual de la cuchilla 8:

Name: piranha2
UUID: 3caeabbe-14e4-e731-915f-5a6d9dc32c32
OS Type: hvm
State: running
CPU(s): 2
CPU time: 59733.0s
Max memory: 8388608 kB
Used memory: 8388608 kB
Persistent: yes
Autostart: enable

5. BALANCEO DE CARGA LVS

El archivo de configuracin principal del balanceo, el mismo que debe estar
sincronizado entre ambos balanceadores es /etc/sysconfig/ha/lvs.cf:

serial_no = 49
primary = 172.16.0.173
service = lvs
backup_active = 1
backup = 172.16.0.160
heartbeat = 1
heartbeat_port = 539
keepalive = 6
deadtime = 18
network = direct
debug_level = NONE
monitor_links = 0
syncdaemon = 0
virtual webserver {
active = 1
address = 172.16.0.150 br0:1
vip_nmask = 255.255.254.0
port = 80
persistent = 120

12
 send = "GET / HTTP/1.0\r\n\r\n"
expect = "HTTP"
use_regex = 0
load_monitor = none
scheduler = sh
protocol = tcp
timeout = 6
reentry = 15
quiesce_server = 0
server webserver1 {
address = 172.16.0.151
active = 1
port = 80
weight = 1
}
server webserver2 {
address = 172.16.0.153
active = 1
port = 80
weight = 1
}
}
virtual apachetomcat {
active = 1
address = 172.16.0.155 br0:2
vip_nmask = 255.255.254.0
port = 8080
persistent = 120
send = "GET / HTTP/1.0\r\n\r\n"
expect = "HTTP"
use_regex = 0
load_monitor = none
scheduler = sh
protocol = tcp
timeout = 6
reentry = 15
quiesce_server = 0
server apachetomcat1 {
address = 172.16.0.151
active = 1
port = 8080
weight = 1
}
server apachetomcat2 {
address = 172.16.0.153
active = 1
port = 8080
weight = 1
}
}

13
Dnde:

- primary = 172.16.0.173 Servidor balanceador primario

- backup = 172.16.0.160 Servidor balanceador secundario
- deadtime = 18 - Tiempo de espera del pulse hasta cambiar el
balanceador
- virtual webserver, virtual apachetomcat Servicios clusterizados
- address = 172.16.0.150 br0:1, address = 172.16.0.155 br0:2
Interfaces iguales en ambos servidores
- persistent = 120 - Amarra la direcciones IP origen con las de los
servidores fsicos por 120 segundos, por seguridad.
- scheduler = sh - Algoritmo de balanceo: source hashing
scheduling algorithm

Adicionalmente para el balanceo utilizando enrutamiento directo se utiliza

IPtables, esta regla est agregada al archivo /etc/rc.local de ambas cuchillas de
la siguiente manera:

iptables -t nat -A PREROUTING -p tcp -d 172.16.0.150 --dport 80 -j REDIRECT

iptables -t nat -A PREROUTING -p tcp -d 172.16.0.155 --dport 8080 -j REDIRECT

14
6. MONITORIZACIN DEL CLSTER:
Para monitorizar los diferentes servidores que conforman el clster es
necesario conocer las IPs principales:

"Blade 1" - B1-BSW1 - 172.16.0.151 (Cuchilla 1)

"Balanceador1" - B1-SV-BSW1 - 172.16.0.173
"Blade8" - B8-DB2 - 172.16.0.153 (Cuchilla 8)
"Balanceador2" - B8-SV-BSW2 - 172.16.0.160

- El panorama bsico del clster se puede mostrar en el balanceador

activo, el balanceador activo es el que posee las direcciones IPV
(Virtuales) activas: br0:1 172.16.0.150 y br0:2 172.16.0.155 con
ifconfig o ip addr show

Ejemplo:

[root@b1-sv-bsw1 ~]# ip addr show

3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN
link/ether 52:54:00:7a:53:cb brd ff:ff:ff:ff:ff:ff
inet 172.16.0.173/23 brd 172.16.1.255 scope global br0
inet 172.16.0.155/23 brd 172.16.1.255 scope global secondary br0:2
inet 172.16.0.150/23 brd 172.16.1.255 scope global secondary br0:1

[root@b8-sv-bsw2 ~]# ip addr show

3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN
link/ether 52:54:00:0b:80:a8 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.160/23 brd 172.16.1.255 scope global br0

En este caso notamos que las IPV se encuentran en el balanceador 1

(b1-sv-bsw1)

- Ubicados en el balanceador activo escribimos el comando ipvsadm -ln

y nos mostrar algo como:

15
 [root@b1-sv-bsw1 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.16.0.150:80 sh persistent 120
-> 172.16.0.151:80 Route 1 11 35
-> 172.16.0.153:80 Route 1 38 63
TCP 172.16.0.155:8080 sh persistent 120
-> 172.16.0.151:8080 Route 1 0 0
-> 172.16.0.153:8080 Route 1 0 0

Dnde:
1. Estn funcionando las dos IPV, la 150 con el servicio Apache
(puerto 80) y la 155 con el servicio tomcat (puerto 8080)
2. Las dos cuchillas estn en funcionamiento la 151 y la 153, ambas
estn sirviendo correctamente los servicios por sus puertos
respectivos, si algn servicio fallara en cualquier cuchilla es ac
donde no se mostrara una lnea.

A continuacin un ejemplo donde la cuchilla 1 dej de servir el apache

(zend-server) Soluci

[root@b1-sv-bsw1 ~]# ipvsadm -ln

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.16.0.150:80 sh persistent 120
-> 172.16.0.153:80 Route 1 38 63
TCP 172.16.0.155:8080 sh persistent 120
-> 172.16.0.151:8080 Route 1 0 0
-> 172.16.0.153:8080 Route 1 0 0

En este caso se tendr que acceder a la cuchilla 1 y solucionar el

problema, tras esto el balanceador automticamente reconocer el
servicio cado.

- Otro comando til es clustat, este comando se debe ejecutar en la

cuchilla 1 o en la cuchilla 8, y muestra si el cluster est formado y el
status de los nodos:

[root@b1-bsw1 ~]# clustat

Cluster Status for cluster01 @ Sat Sep 10 00:13:50 2014
Member Status: Quorate

Member Name ID Status

------ ---- ---- ------
172.16.0.151 1 Online, Local
172.16.0.153 2 Online

16
 Esto nos indica que el clster est formado y funcionando.
- Verificar que los servicios necesarios es necesario en caso de algn
problema, usando el comando /etc/init.d/nombredelservicio status

Ejemplo:
[root@b1-bsw1 ~]# /etc/init.d/cman status
cluster is running.

[root@b1-bsw1 ~]# /etc/init.d/rgmanager status

Se est ejecutando rgmanager (pid 4931)...

[root@b1-bsw1 ~]# /etc/init.d/gfs2 status

Configured GFS2 mountpoints:
/var/www/html
/var/lib/tomcat6
/var/www/docs
Active GFS2 mountpoints:
/var/www/html
/var/lib/tomcat6
/var/www/docs

[root@b1-bsw1 ~]# /etc/init.d/clvmd status

Se est ejecutando clvmd (pid 4148)...
Clustered Volume Groups: (none)
Active clustered Logical Volumes: (none)

[root@b1-bsw1 ~]# /etc/init.d/libvirtd status

Se est ejecutando libvirtd (pid 4674)...

[root@b1-bsw1 ~]# /etc/init.d/zend-server status

[20.09.2014 00:09:19 SYSTEM] Apache is running.
[ 20.09.2014 00:21:19 SYSTEM] watchdog for lighttpd is running.
[ 20.09.2014 00:21:19 SYSTEM] lighttpd is running.

[root@b1-bsw1 ~]# /etc/init.d/tomcat6 status

tomcat6 (pid 4494) is running... [ OK ]

17
7. MANTENIMIENTO DEL CLSTER:

- Dejar offline un nodo:

Para esto el clster funcionar con un solo nodo:
1. Detener y desactivar el inicio automtico de los siguientes
servicios:
service rgmanager stop
chkconfig grmanager off
service gfs2 stop (umount l /var/www/html,umount -l
/var/lib/tomcat6)
chkconfig gfs2 off
service clvmd stop
chkconfig clvmd off
service cman stop
chkconfig cman off
shutdown r now

Al ejecutar clustat en el otro nodo mostrar:

[root@b1-bsw1 ~]# clustat

Cluster Status for cluster01 @ Sat Sep 10 00:13:50 2014
Member Status: Quorate

Member Name ID Status

------ ---- ---- ------
172.16.0.151 1 Online, Local
172.16.0.153 2 Offline

- Utilizando fencing:
1. Testear status de una cuchilla:
[root@b1-bsw1 ~]# fence_bladecenter -a 172.16.50.10 -l USERID
-p PASSW0RD -n 2 -o status
Status: ON

Donde: n = nmero de cuchilla

2. - Reiniciar una cuchilla:

[root@b1-bsw1 ~]# fence_bladecenter -a 172.16.50.10 -l USERID
-p PASSW0RD -n 2 -o reboot

3. - Apagar una cuchilla:

[root@b1-bsw1 ~]# fence_bladecenter -a 172.16.50.10 -l USERID
-p PASSW0RD -n 2 -o off

4. - Encender una cuchilla:

[root@b1-bsw1 ~]# fence_bladecenter -a 172.16.50.10 -l USERID
-p PASSW0RD -n 2 -o on

- Reinicio o apagado directo de una cuchilla:

18
 Si utilizamos directamente reboot o halt el sistema de bloqueo
(fencing) funcionar automticamente mostrando los siguientes logs:

Sep 12 19:21:11 b1-bsw1 fenced[4016]: fencing node 172.16.0.153

Sep 12 19:21:11 b1-bsw1 kernel: GFS2: fsid=cluster01:disco02.1: jid=0:
Trying to acquire journal lock...
Sep 12 19:21:34 b1-bsw1 fenced[4016]: fence 172.16.0.153 success

8. CONCLUSIONES Y SUGERENCIAS

- Se presenta de esta manera, al gobierno regional de Lambayeque una

configuracin de clster que permitir la continuidad de los sistemas
web.

19
- Este manual permitir a los integrantes de la oficina de tecnologas de
informacin tener a la mano una gua de funcionamiento para poder
realizar cambios o solucionar algn inconveniente.
- Se sugiere, debido a la falta de licenciamiento Red Hat, adquirir las
licencias respectivas debido a los problemas que puede traer tener las
aplicaciones desactualizadas.

9. MATERIAL WEB DE CONSULTA

20
http://www.eduardocamposjimenez.es/2011/06/configurando-fencing-en-
un-cluster-red-hat/

http://www.eduardocamposjimenez.es/2011/01/montando-un-red-hat-
cluster-para-servir-apache-usando-conga-gfs2-e-iscsi/

https://access.redhat.com/site/documentation/es-
ES/Red_Hat_Enterprise_Linux/6/html-
single/Cluster_Administration/index.html#s1-clust-svc-ov-CA

https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/6/html/Load_Balancer_Administration/index.ht
ml

21