UNIVERSIDAD ALFREDO PREZ GUERRERO

UNAP

CARRERA: SISTEMAS DE INFORMACION Y

NETWORKING

PROYECTO DE GRADO

PARA LA OBTENCIN DEL TTULO DE INGENIERO EN

SISTEMAS INFORMATICOS Y NETWORKING

TEMA:
DISEO DE UNA SOLUCIN PARA SERVIDORES DE
ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON
OPEN SOURCE

Autor: Flavio Mauricio Gallardo Padilla

Director: Ing. Nelio Brito

Mayo del 2011

Quito, 13 de mayo del 2011

Seor:
Coordinador de Tesis y Proyectos de Grado UNAP
Presente.-

De nuestras consideraciones:
Por medio de la presente CERTIFICAMOS, que el seor estudiante egresado
Flavio Mauricio Gallardo Padilla, identificado con el nmero de cdula
1710049139 estudiante de la carrera de Ingeniera en Sistemas y Networking
de la UNAP, una vez realizada la direccin y las evaluaciones correspondientes
segn la normativa de la universidad, ha concluido satisfactoriamente con el
trabajo de grado Titulado DISEO DE UNA SOLUCIN PARA SERVIDORES
DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON OPEN SOURCE.
Por consiguiente, otorgamos la aptitud para la presentacin del grado oral del
mencionado estudiante.

Agradeciendo su atencin

Ing. Nelio Brito

Director

Ing. Fredy Molina

Evaluador

Ing. Rommel Caicedo

Evaluador

Quito, 13 de mayo del 2011

Seores:
Universidad Alfredo Prez Guerrero UNAP
Presente.-

De mis consideraciones:

Yo, Flavio Mauricio Gallardo Padilla, identificado con el nmero de cdula

1710049139, estudiante egresado de la UNAP de la Carrera de Ingeniera en
Sistemas y Networking, por medio de la presente CERTIFICO que el presente
Trabajo

de

Grado

titulado:

DISEO

DE

UNA

SOLUCIN

PARA

SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON

OPEN SOURCE; es de mi plena autora y no constituye plagio ni copia alguna
constituyndose un documento nico.

Es todo en cuanto puedo decir en honor a la verdad

Agradeciendo su atencin

Mauricio Gallardo
C.I. 1710049139
Estudiante Egresado de la UNAP

AGRADECIMIENTO

A mi esposa, por ser el pilar y soporte en todo lo que hago en mi vida, por ser
la persona que me ha brindado su apoyo y comprensin incondicional en la
culminacin de mi carrera, sin lugar a duda es parte esencial para haber
terminado mis estudios universitarios, gracias por todo lo que has hecho para
alcanzar esta meta, este logro tambin es tuyo.

DEDICATORIA

A mis hijas, quienes comprendieron que el tiempo que deba entregarles a ellas
lo ocupaba en culminar mi carrera, quiero que este logro sea para ellas un
ejemplo de perseverancia y sacrificio y que sea tambin un ejemplo para la
culminacin de sus carreras profesionales en su momento, entiendan que todo
lo que uno se propone en la vida es posible con dedicacin y esfuerzo.

INDICE

INTRODUCCION ................................................................................................. i
CAPITULO 1 ....................................................................................................... 1
GENERALIDADES ............................................................................................. 1
1.1. PLANEAMIENTO DEL PROBLEMA ............................................................ 1
1.2. FORMULACION DEL PROBLEMA .............................................................. 2
1.3. SISTEMATIZACION .................................................................................... 2
1.4. OBJETIVO GENERAL ................................................................................. 2
1.5. OBJETIVOS ESPECIFICOS ........................................................................ 3
1.6. JUSTIFICACIN .......................................................................................... 3
1.7. ALCANCE .................................................................................................... 4
CAPITULO 2 ....................................................................................................... 6
INTRODUCCION ................................................................................................ 6
FUNDAMENTACION TEORICA ......................................................................... 6
MARCOS DE REFERENCIA (Terico, Conceptual) ........................................... 6
2.1. MARCO TEORICO ...................................................................................... 6
2.1.1. Clustering .................................................................................................. 6
2.1.1.1. Antecedentes ......................................................................................... 6
2.1.1.2 Que es el clustering? .............................................................................. 7
2.1.1.3. Tipos de clster ...................................................................................... 8
2.1.1.4. High Performance .................................................................................. 8
2.1.1.5. Clster Activo/Pasivo ........................................................................... 14
2.1.1.6. Clster Activo/Activo ............................................................................ 14
2.1.2. Arquitectura de Clustering....................................................................... 15
2.1.2.1. Alta disponibilidad ................................................................................ 16
2.1.2.2. Escalabilidad ........................................................................................ 20
2.1.3. Funcionamiento de un clster ................................................................. 22
2.1.3.1. Balanceador de carga .......................................................................... 22
2.1.3.2. Sistema para la deteccin de fallos en los nodos del clster ............... 24
2.1.3.3. Recursos del clster ............................................................................ 25
2.1.3.4. Servicio a clusterizar ............................................................................ 25

2.1.4. Balanceo de Carga ................................................................................. 26

2.1.4.1. Balanceadores hardware ..................................................................... 29
2.1.4.2. Balanceadores software....................................................................... 30
2.1.4.3. Linux Virtual Server - LVS .................................................................... 30
2.1.5. Deteccin de fallos en los nodos del clster ........................................... 32
2.1.5.1. Heartbeat ............................................................................................. 32
2.1.5.2. Disco de quorum .................................................................................. 34
CAPITULO 3 ..................................................................................................... 36
INTRODUCCION .............................................................................................. 36
DIAGNOSTICO ................................................................................................. 36
3.1. Herramientas de open source para la construccin del Clster ................. 36
3.2. Comparacin de las herramientas de balanceo de carga y alta
disponibilidad .................................................................................................... 40
3.2.1. Herramientas de balanceo de carga y alta disponibilidad ....................... 44
3.2.1.1. Piranha................................................................................................. 44
3.2.1.2. Linux Virtual Server .............................................................................. 45
3.2.1.3. Ultramonkey ......................................................................................... 47
3.2.1.3.1. Componentes Ultramonkey ............................................................... 47
3.2.1.3.1.1. Heartbeat ....................................................................................... 48
3.2.1.3.1.2. Ldirectord ....................................................................................... 48
3.2.1.3.1.3. Mon (Service Monitoring Daemon)................................................. 49
CAPITULO 4 ..................................................................................................... 50
INTRODUCCION .............................................................................................. 50
DISEO ............................................................................................................ 50
4.1. Tipos de balanceo de carga ....................................................................... 50
4.1.1. Modos de balanceo de carga en LVS ..................................................... 51
4.1.2. Resumen de los mtodos de balanceo ................................................... 56
4.1.3. Planificacin del balanceo de carga ........................................................ 57
4.2. Eleccin de una herramienta para balanceo de carga y alta disponibilidad
.......................................................................................................................... 62
CAPITULO 5 ..................................................................................................... 69
INTRODUCCION .............................................................................................. 69
IMPLEMENTACION EN MAQUINAS VIRTUALES ........................................... 69

5.1 INSTALACION Y CONFIGURACION DEL CLUSTER ................................ 69

5.1.1 SELECCIN DE NODOS PARA EL CLSTER ...................................... 71
5.1.2 Instalacin de los nodos........................................................................... 74
5.1.3. Configuracin de los servidores web ...................................................... 76
5.2. Instalacin de CentOs ................................................................................ 78
5.3. Instalacin de Ultramonkey ........................................................................ 78
5.3.1. Seleccin de topologa de instalacin de ultamonkey ............................. 79
5.3.1.1. Directores Linux o Nodos de balanceo ................................................ 80
5.3.1.2. Nodos servidores o servidores reales .................................................. 81
5.4. Configuracin de Heartbeat en los nodos de balanceo ............................. 81
5.5. Configuracin de la red de trabajo ............................................................. 81
5.6. Configuracin del clster ........................................................................... 82
5.6.1. Directores Linux, nodos de balanceo ...................................................... 82
5.6.2. Heartbeat ................................................................................................ 82
5.7. Instalar y configurar IPROUTE en los nodos servidores ............................ 83
5.8. Pruebas de desempeo ............................................................................. 84
5.8.1. Herramientas para medicin de rendimiento .......................................... 86
5.8.1.1. Seleccin de una herramienta para medicin de rendimiento ............. 86
CONCLUSIONES ............................................................................................. 91
Anexo 1 Instalacin de Centos ......................................................................... 95
Anexo 2 Instalacin de la Solucin ................................................................. 118

INDICE DE FIGURAS

Figura 2.1 Clster de computadores ............................................................... 7

Figura 2.2 Componentes de un clster ............................................................ 9
Figura 2.3 Arquitectura de un Clster ............................................................ 15
Figura 2.4 Alta disponibilidad ......................................................................... 20
Figura 2.5 Balanceador de Carga .................................................................. 23
Figura 2.6 Recursos del Clster .................................................................... 25
Figura 2.7 Balanceo de Carga ....................................................................... 27
Figura 2.8 Balanceadores de Carga .............................................................. 31
Figura 2.9 Heartbeat ...................................................................................... 32
Figura 2.10 Disco de Quorum ........................................................................ 35
Figura 3.1 Esquema de funcionamiento de Piranha. ..................................... 45
Figura 3.2 Esquema de funcionamiento de LVS. .......................................... 46
Figura 3.3 Componentes de Ultramonkey. .................................................... 48
Figura 3.4 Esquema de funcionamiento de Ultramonkey. ............................. 49
Figura 4.1 Balanceo mediante NAT. .............................................................. 53
Figura 4.2 Balanceo mediante encapsulado IP. ............................................ 54
Figura 4.3 Balanceo mediante enrutamiento directo. .................................... 55
Figura 4.4 Round Robin................................................................................. 59
Figura 4.5 Round Robin Ponderado. ............................................................. 59
Figura 4.6 Servidor con menos conexiones activas. ..................................... 60
Figura 4.7 Servidor con menos conexiones activas ponderado. ................... 60
Figura 4.8 Menos conectado basado en servicio. ......................................... 61
Figura 4.9 Tablas Hash por origen y destino. ................................................ 61
Figura 5.1 Funcionamiento del Clster. ......................................................... 70
Figura 5.2. Configuracin final de nodos. ...................................................... 78
Figura 5.3. Pgina del servidor 1 ................................................................... 85
Figura 5.4. Pgina del servidor 2 ................................................................... 85
Figura 5.5. Detencin del servicio httpd......................................................... 86
Figura 5.6. Verificacin de servidores y conexiones con ipvsadm l. ............ 88
Figura 5.7. Verificacin de servidores y conexiones con ipvsadm lnc. ........ 89

Figura 5.8. Trfico en la red con tcpdump. .................................................... 89

Figura 5.9. Salida de trfico en la red con tcpdump. ..................................... 90

INDICE DE TABLAS

Tabla 2.1 Tipos de Clster ........................................................................... 8

Tabla 2.2 Subtipos de Clster ...................................................................... 9
Tabla 2.3 Componentes de un Clster ....................................................... 10
Tabla 2.4 Configuracin de un Clster ....................................................... 14
Tabla 2.5 Estructura de Alta Disponibilidad ................................................ 15
Tabla 3.1 Caractersticas de Herramientas para Clsters. ......................... 38
Tabla 3.2 Ventajas y Desventajas de las Herramientas para Clster. ........ 40
Tabla 3.3 Comparacin de herramientas para clster. ............................... 42
Tabla 4.1 Mtodos de balanceo de carga. ................................................. 51
Tabla 4.2 Modos de balanceo de carga en LVS......................................... 52
Tabla 4.3 Mtodos de direccionamiento. .................................................... 57
Tabla 4.4 Algoritmos de planificacin de balanceo de carga. .................... 58
Tabla 4.5 Requisitos mnimos de hardware para Piranha. ......................... 63
Tabla 4.6 Requisitos mnimos de hardware para LVS. .............................. 64
Tabla 4.7 Requisitos mnimos de hardware para Ultramonkey. ................. 64
Tabla 4.8 Comparacin de requisitos. ........................................................ 65
Tabla 5.1 Funcionamiento del Clster. ....................................................... 70
Tabla 5.2 Especificaciones del nodo de balanceo. ..................................... 71
Tabla 5.3 Especificaciones de nodo servidor. ............................................ 71
Tabla 5.4 Herramientas utilizadas en cada nodo. ...................................... 72
Tabla 5.5 Caractersticas de herramientas utilizadas. ................................ 74
Tabla 5.6 Proceso de instalacin del Sistema Operativo. .......................... 74
Tabla 5.7 Medios de instalacin. ................................................................ 75
Tabla 5.8 Proceso de instalacin del sistema base. ................................... 76
Tabla 5.9 Servicios activados en los nodos servidores. ............................. 76

INTRODUCCION
Para que un servicio sea eficiente es necesario que se mantenga en
funcionamiento constante y que no ocurran retardos en la entrega de la
informacin. As pues se da paso a la investigacin y desarrollo de nuevas
tecnologas que garanticen tales sucesos; en este trabajo se presentarn las
soluciones para tales problemas y se expondrn sus caractersticas as como
las herramientas que hacen posible la construccin de dichas soluciones de
software con open source.

Un servidor juega un papel muy importante dentro de una organizacin, y al

mismo tiempo se transforma en un servicio crtico al ser utilizado por la gran
mayora de los usuarios para acceder a todos los servicios que este brinda,
siendo necesario la implementacin de un sistema de clster que permita
mantener el servicio disponible en caso de que falle un servidor as como
mantener un sistema de balanceo de carga evitando la saturacin del propio
servidor.

Un clster es un conjunto de maquinas, conectadas entre s en red y

funcionando en paralelo y compartiendo recursos para cooperar en cargas de
trabajo complejas y conseguir mayor eficacia que un solo equipo.

Al hablar de clster, tenemos un numeroso listado de diversas aplicaciones que

implementan distintos tipos de clster, dependiendo de las necesidades que
posee la organizacin y la aplicacin a clusterizar.

Dentro de los clster ms comunes, se encuentra el clster de alta

disponibilidad, en el cual uno de los nodos acta pasivamente mientras el nodo
activo recibe todas las peticiones a los servicios que ofrece. En caso de que el
nodo activo tenga alguna falla en los servicios, el nodo pasivo toma el control

ii

de los servicios y pasa a ser el activo para que los servicios ofrecidos estn
siempre disponibles.

Actualmente, debido a la gran cantidad de usuarios que necesitan acceder a

los servicios, es necesario tambin aprovechar los nodos pertenecientes al
clster, para que estos pasen a ser activos y la carga se pueda dividir entre
todos los nodos del clster, constituyendo as un clster de balanceo de carga.

CAPITULO 1
GENERALIDADES

1.1. PLANEAMIENTO DEL PROBLEMA

Las empresas actualmente se han visto en el problema de suspender
temporalmente sus operaciones debido a incidentes ocurridos en los servidores
de servicios tales como proxy, correo electrnico, ftp, web, etc., dando origen a
prestar servicios de baja calidad a sus clientes poniendo en riesgo la
continuidad del negocio, lo que ocasiona prdidas econmicas.

Actualmente en el pas existen pocas empresas que han optado por instalar
open source en sus servidores debido al poco personal tcnico capacitado,
pese a que el gobierno nacional promueve el uso de open source en las
entidades pblicas. Este trabajo se enfoca en el uso de software libre para la
implementacin de la solucin planteada.

Existen equipos que permiten balanceo de carga y alta disponibilidad mediante

hardware, pero la adquisicin de estos significa una inversin para las
empresas contrariamente a las soluciones de software open source que no
necesitan pagar ningn valor de licenciamiento.

De no contar con una solucin al problema de alta disponibilidad y balanceo de

carga por software se perder la opcin de contribuir a una investigacin e
implementacin de este tipo.

Mediante la implementacin de la solucin, las empresas aseguran el normal

desenvolvimiento de sus operaciones, minimizando sustancialmente el riesgo
tecnolgico dando continuidad al negocio y por consiguiente a sus operaciones,
se centrar en la tcnica de obtener una alta disponibilidad y balanceo de carga

por medio de la redundancia, instalando servidores completos en lugar de uno

slo (se realizar la implementacin en mquinas virtuales), que sean capaces
de trabajar en paralelo y de asumir las cadas de algunos de sus compaeros,
y podremos aadir y quitar servidores al grupo (clster) segn las necesidades.

1.2. FORMULACION DEL PROBLEMA

Encontrar la solucin que permita mantener un alto nivel de disponibilidad y
balanceo de carga, con herramientas open source, dando continuidad a los
servicios?. Considerando la experiencia adquirida en la implementacin,
administracin y mantenimiento de servidores Linux en los ltimos aos de
servicio profesional.

1.3. SISTEMATIZACION
Qu herramientas open source nos permiten aplicar alta disponibilidad y
balanceo de carga?
Qu herramientas open souce se utilizarn para la implementacin de la
solucin?
Qu necesitan las empresas para solucionar su problema de alta
disponibilidad y balanceo de carga?

1.4. OBJETIVO GENERAL

Disear una solucin de alta disponibilidad y balanceo de carga, para dotar de
servicios que permitan dar continuidad al negocio en las operaciones
realizadas por las empresas, con software open source.

1.5. OBJETIVOS ESPECIFICOS

Investigar las distintas posibilidades que nos ofrece hoy en da el mundo del
Software Libre para disponer de servidores de alta disponibilidad y balanceo de
carga en el terreno empresarial y orientado principalmente a servicios IP
(servidores HTTP, SMTP, POP, FTP, etc), basados en la replicacin de
servidores (clustering) con mquinas virtuales y bajo el Sistema Operativo
GNU/Linux.
Diagnosticar el estado actual de la tecnologa utilizada en las empresas, que
necesitan balanceo de carga y alta disponibilidad.

Disear una solucin que permita ofrecer servidores de alta disponibilidad y

balanceo de carga mediante software libre.

Implementar en un ambiente de laboratorio la solucin diseada, para asegurar

el normal desenvolvimiento de las operaciones en cualquier empresa. Dicho
laboratorio se lo implementar en mquinas virtuales.

1.6. JUSTIFICACIN
Con el actual ritmo de crecimiento del comercio y el movimiento de datos de
todo tipo en Internet, web 2.0, con el establecimiento no formal de un protocolo
mundial IP generalizo y la incuestionable importancia de las tecnologas de la
informacin en las empresas actuales de cualquier tamao, es cada da ms
importante que los servicios puedan funcionar con un alto nivel de SLA (calidad
de servicio) , ya sea para dar soporte interno, como para ofrecer servicios a
travs de Internet e Intranet (http, correo, ftp, etc). A esta necesidad de un
servicio ininterrumpido y fiable se le conoce como alta disponibilidad, de igual
forma evitar la sobre carga existente en los servidores debido al gran nmero
de usuarios y que estos no sean saturados, compartiendo con otros la
responsabilidad de dar los servicios conocemos como balanceo de carga.

Para poder incrementar la base cientfica relacionada con proyectos de

software open source y minimizar el riesgo tecnolgico. Se utiliza open source
por que es software libre, es decir no se debe incurrir en gastos de
licenciamiento para su uso.
Desde

el

punto

de

vista

metodolgico,

esta

investigacin

generar

conocimiento vlido y confiable dentro del rea de las TICS , para futuras
implementaciones. Esta investigacin abrir nuevos caminos en empresas que
presenten situaciones similares sirviendo a estas como marco referencial.

1.7. ALCANCE
El proyecto abarcar la investigacin sobre las herramientas de clster que nos
ofrece el software libre, para de esta manera analizar la mejor opcin para ser
implementada, esta investigacin permitir adems adquirir conocimiento para
futuras implementaciones.
Despus de conocer las opciones de cluster con open source, se realizar un
diagnostico sobre las herramientas disponibles para proponer una solucin que
permita de forma adecuada implementar la tecnologa elegida, tomando en
cuenta siempre la mejor alternativa.

Se crear un laboratorio con mquinas virtuales para la implementacin en un

ambiente de pruebas, que contendr servicios como http, mail, ftp, proxy,
adems se obtendr pruebas de los resultados de funcionamiento de la
solucin.

Se contar con un cliente con un sistema operativo distinto al utilizado para la

construccin del clster (el cliente solamente necesita un navegador web) el
cual realiza las peticiones de la pgina web principal alojada en el clster, de
esta manera se puede observar cual servidor real es el que atiende la peticin
(en un sistema en produccin esto no deber ser as ya que la intencin es que
los usuarios vean al sitio web como un solo equipo). En lo concerniente a las

pruebas de alta disponibilidad, sern realizadas de 3 maneras, la primera es

desconectando un nodo de balanceo, la segunda es detener la ejecucin de las
aplicaciones encargadas de monitorear el estado de los nodos de balanceo en
uno de los nodos para simular un fallo fsico del nodo y tercera es apagando
uno de los nodos y revisar si el servicio sigue en funcionamiento. Esto nos dar
una visin certera del real funcionamiento de servidores de este tipo en
ambientes de produccin.

CAPITULO 2

INTRODUCCION
Este captulo contiene conceptos fundamentales que son necesarios conocer
para la elaboracin del proyecto como: clustering, tipos de clster, arquitectura
de clustering, alta disponibilidad, balanceo de carga.
Adicionalmente se relata una breve historia del inicio, desarrollo y evolucin de
la tecnologa relacionada con los clster.

FUNDAMENTACION TEORICA

MARCOS DE REFERENCIA (Terico, Conceptual)

2.1. MARCO TEORICO

2.1.1. Clustering
2.1.1.1. Antecedentes
En el verano de 1994 Thomas Sterling y Don Becker, trabajando
para el CESDIS (Center of Excellence in Space Data and Informarion
Sciencies) bajo el patrocinio del Proyecto de las Ciencias de la Tierra
y el Espacio (ESS) de la NASA, construyeron un Clster de
Computadoras que consista en 16 procesadores DX4 conectados
por una red Ethernet a 10Mbps, ellos llamaron a su mquina
Beowulf.
La mquina fue un xito inmediato y su idea de proporcionar
sistemas basados en COTS (equipos de sobremesa) para satisfacer
requisitos de cmputo especficos se propag rpidamente a travs
de la NASA y en las comunidades acadmicas y de investigacin. El
esfuerzo del desarrollo para esta primera mquina creci
rpidamente en lo que ahora llamamos el Proyecto Beowulf.
Este Beowulf construido en la NASA en 1994 fue el primer clster de
la historia, y su finalidad era el clculo masivo de datos. Desde
entonces, la tecnologa de clusters se ha desarrollado enormemente.

2.1.1.2 Que es el clustering?

Clustering es un conjunto de maquinas, conectadas entre s en red y
funcionando en paralelo y compartiendo recursos para cooperar en
cargas de trabajo complejas y conseguir mayor eficacia que un solo
equipo. Dado que se comporta como un nico gran recurso. Cada
una de las mquinas que forman el clster recibe el nombre de nodo.

Figura 2.1 Clster de computadores

Esta tecnologa ha evolucionado para beneficio de diversas

actividades que requieren el poder de cmputo y aplicaciones de
misin crtica.

El uso de los clsters es el resultado de una convergencia de

mltiples tecnologas que abarcan la disponibilidad de procesadores
econmicos de alto rendimiento y las redes de alta velocidad, como
lo son las redes de fibra ptica as como tambin el desarrollo de
herramientas de software diseadas para cmputo distribuido de alto
desempeo.

En este sentido para que una empresa pueda contar con un clster
es necesario considerar los diferentes tipos existentes dependiendo
de la tarea que se quiera realizar con este, como lo muestra la tabla
2.1.

2.1.1.3. Tipos de clster

Dependiendo del tipo de solucin que busquemos podemos clasificar
los clusters en varios tipos:

High Performance
High Availability
Load Balancing

2.1.1.4. High Performance

Tipo de Clster

Descripcin

Alto rendimiento

Conjunto de computadoras diseado para brindar

(High Performance)

altas prestaciones en cuanto a capacidad de clculo.

Conjunto de dos o ms computadoras que se

Alta disponibilidad

caracterizan por mantener una serie de servicios

(High Availability)

disponibles y compartidos, se caracterizan por estar

constantemente monitorizndose entre s.
Compuesto por una o ms computadoras que actan

Balanceo de carga

como interfaces primarias del clster y se ocupan de

(Load Balancing)

repartir las peticiones de servicio que recibe el

clster a los nodos que lo conforman.

Tabla 2.1 Tipos de Clster

Adems de la clasificacin general de los tipos de clster que se

pueden encontrar, es preciso destacar que se pueden tener los
siguientes subtipos en cada una de las categoras segn se muestra
en la tabla 2.2.

Subtipo
Homogneo

Descripcin
Es donde todos los nodos poseen una
configuracin de hardware y software iguales.

Semi-

Es donde se poseen arquitecturas y sistemas

homogneo

operativos similares pero de diferente rendimiento.

Heterogneo

Es donde se poseen hardware y software distintos

para cada nodo.

Tabla 2.2 Subtipos de Clster

Un clster posee varios componentes de software y hardware para

poder funcionar, la figura 2.2 muestra dichos componentes:

Figura 2.2 Componentes de un clster

10

Para entender mejor estos componentes, es recomendable el

anlisis mediante la tabla 2.3, en ella se puede observar cada
componente y una descripcin del mismo comenzando por la
interconexin de los equipos.

Componente

Descripcin
Estas son las conexiones de los nodos a la red de trabajo

Conexiones de red.

del clster siendo tan complejas como lo sean las

tecnologas y medios utilizados en su instalacin.

Protocolos de
comunicacin y

Aqu

normalmente

se

cuenta

con

el

protocolo

de

comunicaciones TCP/IP y servicios de transporte de datos.

servicios.
Son simples computadoras o sistemas multiprocesador; en
Nodos.

estos se hospedan el Sistema Operativo, el middleware y lo

necesario para la comunicacin a travs de una red.
Se define a grandes rasgos como un programa o conjunto

Sistema Operativo.

de ellos que estn destinados a gestionar de manera eficaz

los recursos de una computadora. Como ejemplo se tiene
Unix, Mac OSX.
Es un software que acta entre el Sistema Operativo y las
aplicaciones con la finalidad de proveer a un clster las

Middleware.

caractersticas de interfaz, herramientas de optimizacin y

mantenimiento del sistema, como tambin un crecimiento o
escalabilidad. Entre los ms populares se encuentra
openMosix.
Son todos aquellos programas que se ejecutan sobre el

Aplicaciones.

middleware; estos son diseados para su ejecucin en

entornos de cmputo paralelo o aprovechamiento del tipo
de clster.
Tabla 2.3 Componentes de un Clster

11

Los clsters permiten una flexibilidad de configuracin que no se

encuentra

normalmente

en

los

sistemas

multiprocesadores

convencionales. El nmero de nodos, la capacidad de memoria por

nodo, el nmero de procesadores por nodo y la topologa de
interconexin, son todos parmetros de la estructura del sistema que
puede ser especificada en detalle en una base por nodo sin incurrir
en costos adicionales debidos a la configuracin personalizada.

Adems, permiten una rpida respuesta a las mejoras en la

tecnologa.

Cuando

los

nuevos

dispositivos,

incluyendo

procesadores, memoria, disco y redes estn disponibles se pueden

integrar a los nodos del clster de manera fcil y rpida permitiendo
que sean los sistemas paralelos que primero se benefician de tales
avances. Lo mismo se cumple para los beneficios de un
mejoramiento constante en el rubro de precio-rendimiento en la
tecnologa. Los clsters son actualmente la mejor opcin para seguir
la pista de los adelantos tecnolgicos y responder rpidamente a las
ofertas de nuevos componentes.

Los clsters permiten una flexibilidad de configuracin que no se

encuentra

normalmente

en

los

sistemas

multiprocesadores

convencionales. El nmero de nodos, la capacidad de memoria por

nodo, el nmero de procesadores por nodo y la topologa de
interconexin, son todos parmetros de la estructura del sistema que
puede ser especificada en detalle en una base por nodo sin incurrir
en costos adicionales debidos a la configuracin personalizada.

Un clster puede ser usado para solucionar una variedad de

problemas dependiendo del tipo que se tenga, como ya se dijo
existen los de alto rendimiento, balanceo de carga y alta
disponibilidad. Los dos primeros resuelven problemas como:

12

Clculos matemticos.

Rendering (construccin/generacin) de grficos.

Compilacin de programas.

Compresin de datos.

Descifrado de cdigos.

Rendimiento del sistema operativo, (incluyendo en l, el

rendimiento de los recursos de cada nodo).

En general cualquier problema de propsito general que

requiera de gran capacidad de procesamiento.

En el caso de los clster de alta disponibilidad resuelven:

Sistemas de informacin redundante.

Sistemas tolerantes a fallos.

Balance de procesos entre varios servidores.

Balance de conexiones entre varios servidores.

En general cualquier problema que requiera almacenamiento

de datos siempre disponible con tolerancia a fallos.

De esta manera, se afirma que el problema que se resuelve con el

balanceo de carga est estrechamente relacionado con los que se
pueden solucionar la alta disponibilidad, ya que generalmente se
desea que un servicio est disponible el mayor tiempo posible y con
la mejor respuesta que se pueda obtener.

Es as que el servicio puede ser diverso; desde un sistema de

archivos distribuidos de carcter muy barato, hasta grandes clsters
de balanceo de carga y conexiones para los grandes portales de
Internet lo que lleva a que la funcionalidad requerida en un entorno
de red puede ser colocada en un clster e implementar mecanismos
para hacer que ste obtenga la mayor disponibilidad posible.

13

Realmente no hay sistemas que puedan asumir la alta disponibilidad

en realidad, se requiere que el clster sea tolerante a los fallos. En
dicho caso se pretende ocultar al usuario final la presencia de los
fallos del sistema empleando redundancia en el hardware y en el
software e incluso redundancia temporal.

La redundancia en el hardware consiste en aadir componentes

replicados para encubrir los posibles fallos mientras que la
redundancia de software incluye la administracin del hardware
redundante para asegurar su correcto funcionamiento al hacer frente
a la cada de algn elemento. Y por ltimo la redundancia en el
tiempo hace referencia a la repeticin de la ejecucin de un conjunto
de instrucciones para asegurar el comportamiento correcto en caso
de que ocurra un fallo.

Por su parte, el balanceo de carga en el contexto del servicio web es

la toma de decisin de cul nodo deber hacerse cargo de las
peticiones de servicio de otro que est con un mayor nmero de
peticiones de servicio que l, con el objetivo de que stas se
encuentren equilibradas entre el total de nodos que conforman el
clster. Cuando se genera una creciente demanda de trabajo en
este servicio se hace uso del balanceo de carga, creciendo el
nmero de nodos que mantienen el servicio a medida que la carga
de trabajo aumenta no siendo requisito el incorporar nodos con los
ltimos avances tecnolgicos.

En el balanceo de carga en un nodo (o varios segn sea el caso) es

una tarea que controlar la distribucin entre los servidores que
componen el clster. Cabe aclarar que dicha labor se puede efectuar
a nivel de aplicacin; lo que puede llevar a cuellos de botella si el
nmero de nodos servidores es grande y en un nivel de direccin IP,
en el cual la cantidad de informacin que es manejada es mucho

14

menor, puesto que slo son manejadas las direcciones IP y no datos

adicionales como el manejo de sesiones e informacin de control de
la aplicacin; por ello en el manejo a nivel de direccin IP, un cuello
de botella es menos factible.

As pues, para lograr que un sistema tenga caractersticas de alta

disponibilidad se hace uso de componentes de hardware redundante
y un software capaz de unir tales componentes. Estos sistemas
poseen dos posibles configuraciones que se listan en la tabla 2.4. Un
clster de alta disponibilidad puede componerse de uno o varios
nodos para sustentar el acceso al servicio ofrecido, sin embargo se
debe prestar atencin cuando slo se cuenta con un nodo pues este
representa un punto nico de fallo lo que se traduce en un nodo que
al fallar, el acceso se ve interrumpido.

Una estructura de alta disponibilidad de este tipo est conformada

como se muestra en la tabla 2.5.

2.1.1.5. Clster Activo/Pasivo

2.1.1.6. Clster Activo/Activo

Configuracin

Descripcin
Las aplicaciones se ejecutan sobre un conjunto de nodos

Activo

Pasivo

activos mientras que los nodos restantes actan como

respaldos redundantes.
Todos los nodos actan como servidores activos de una o ms

Activo
Activo

aplicaciones y potencialmente como respaldos para las

aplicaciones que se ejecutan en otros nodos.
Tabla 2.4 Configuracin de un Clster

15

Elemento

Descripcin
Consiste en componentes de software que cooperan
entre s para permitir que el clster parezca como un
sistema nico. Entre sus funciones se encuentran:

Infraestructura de

Monitorizacin de nodos y procesos.

Control de acceso a recursos compartidos.

Satisfaccin de requerimientos del usuario.

alta disponibilidad. Esta puede ser parte del ncleo del sistema operativo o
una capa situada sobre ste, las ventajas de dichas
integraciones son:
En forma de capa, una solucin independiente del
sistema operativo.
En el sistema operativo, una eficiencia y facilidad
de uso.
Son clientes de la infraestructura y usan las facilidades
Servicios de alta

que exporta ese nivel para mantener en todo momento el

disponibilidad.

servicio. Usualmente existe una degradacin del sistema

cuando un nodo falla pero no una interrupcin del
servicio.

Tabla 2.5 Estructura de Alta Disponibilidad

2.1.2. Arquitectura de Clustering

16

Figura 2.3 Arquitectura de un Clster

El propsito de un cluster es:

Redundancia frente a fallos (alta disponibilidad).
Aumento de potencia (escalabilidad).
Estos propsitos no son excluyentes.
Importante.- A la hora de escoger que tipo de clster se va a
utilizar hay que tener en cuenta las caractersticas que nos ofrece
cada tipo y cul es el que ms encaja en nuestro entorno.

2.1.2.1. Alta disponibilidad

La alta disponibilidad ha sido tradicionalmente un requerimiento
exigido a aquellos sistemas que realizaban misiones crticas. Sin
embargo, actualmente, est siendo cada vez ms importante exigir
esta disponibilidad en sistemas comerciales y en reas acadmicas
donde el objetivo de prestar los servicios en el menor tiempo posible
es cada vez ms perseguido.

El concepto de clster de disponibilidad continua, se basa en la idea

de mantener la prestacin del servicio en todo momento. Esto
representa una situacin ideal, sera necesario que el sistema
estuviera compuesto de componentes perfectos que no fallaran
nunca, tanto en hardware como en software. Realmente no hay
sistemas que puedan asumir este tipo de disponibilidad.1

Se necesita que el clster sea tolerante a los fallos, en este caso se

encubre la presencia de los fallos del sistema empleando
redundancia en el hardware, el software e incluso redundancia
temporal. La redundancia en el hardware consiste en aadir
componentes replicados para encubrir los posibles fallos. La
1

http://www.eurogaran.com/index.php/es/servidores-linux/clusteres/de-alta-disponibilidad

17

redundancia software incluye la administracin del hardware

redundante para asegurar su correcto funcionamiento al hacer frente
a la cada de algn elemento. La redundancia en el tiempo hace
referencia a la repeticin de la ejecucin de un conjunto de
instrucciones para asegurar el comportamiento correcto en caso de
que ocurra un fallo.

Definiremos un clster de alta disponibilidad como un sistema capaz

de encubrir los fallos que se producen en l para mantener una
prestacin de servicio continua.

El clster de alta disponibilidad va a poder disearse con distintas

configuraciones. Una posible configuracin es activo pasivo en el
cul las aplicaciones se ejecutan sobre el conjunto de nodos activos,
mientras que los nodos restantes actan como backups redundantes
para los servicios ofrecidos.

En el otro extremo, tenemos otra posible configuracin, activo activo: en este caso, todos los nodos actan como servidores activos
de una o ms aplicaciones y potencialmente como backups para las
aplicaciones que se ejecutan en otros nodos. Cuando un nodo falla,
las aplicaciones que se ejecutaba en l se migran a uno de sus
nodos backup. Esta situacin podra producir una sobrecarga de los
nodos de respaldo, con lo que se ejecutaran las aplicaciones con
ms retardo.
Sin embargo es aceptable una degradacin del servicio y tambin
suele ser preferible a una cada total del sistema. Otro caso particular
de clster de alta disponibilidad sera el de un clster de un solo
nodo, tratndose en este caso, simplemente, de evitar los puntos
nicos de fallo.

18

Los conceptos de alta disponibilidad y de clustering estn

profundamente

relacionados

ya

que

el

concepto

de

alta

disponibilidad de servicios implica directamente una solucin

mediante clustering.

La principal prestacin de un sistema de alta disponibilidad es que el

fallo de un nodo derive en que las aplicaciones que se ejecutaban en
l sean migradas a otro nodo del sistema. Este migrado puede ser
automtico (failover) o manual (switchover).2

Generalmente este tipo de cluster integra un nmero relativamente

pequeo de nodos (entre 2 y 8), aunque existen soluciones
comerciales que trabajan en clusters de mayor tamao. En este
caso, la escalabilidad no sera un objetivo prioritario, en contraste
con el caso de los clusters computacionales.

Las aplicaciones usadas para el diseo y la implementacin de este

tipo de clusters no tienen porqu escalar. Sin embargo, actualmente,
existe una cierta tendencia a perseguir la escalabilidad tambin en
los clusters de alta disponibilidad lo que lleva a que cada vez se
busca ms tener un cluster de mayor nmero de nodos pero ms
pequeos en tamao y prestaciones.

Desde un punto de vista general, una solucin de alta disponibilidad

consiste en dos partes: la infraestructura de alta disponibilidad y los
servicios.

La infraestructura consiste en componentes software que cooperan

entre s para permitir que el cluster aparezca como un nico sistema.
Sus funciones incluyen monitorizar los nodos, los procesos de
interrelacin entre nodos, controlar el acceso a los recursos
2

http://www.seccperu.org/files/Clustering%20and%20Grid%20Computing.pdf

19

compartidos y asegurar la integridad de los datos y la satisfaccin de

los requerimientos del usuario. La infraestructura debe proveer de
estas funcionalidades cuando el cluster est en estado estable y, lo
que es ms importante, cuando algunos nodos dejan de estar
operativos.

Los servicios de alta disponibilidad son clientes de la infraestructura,

y usan las facilidades que exporta ese nivel para mantener en todo
momento el servicio a los usuarios. Normalmente hay una
degradacin del sistema cuando algn nodo cae, pero no una
interrupcin del servicio.

Los servicios que se mantienen tpicamente sobre este tipo de

clusters son las bases de datos, los sistemas de ficheros, los
servidores de correo y los servidores web. Y en general, sern
utilizados para tareas crticas o servicios ofrecidos por una empresa,
grupo de investigacin o institucin acadmica, que no puedan, por
sus caractersticas concretas, interrumpir el servicio.

La adaptacin ms comn que debe sufrir una aplicacin para poder

ser ejecutada en un clster de alta disponibilidad implementado
sobre GNU/Linux, es aadir scripts. Existen APIs para trabajar
cmodamente con alta disponibilidad; todas ellas incluyen mtodos
que permiten el switchover y el failover y que permiten arrancar,
parar o monitorizar una aplicacin por mencionar algunas de sus
funcionalidades.

La infraestructura puede ser parte del ncleo del sistema operativo o

puede ser una capa situada encima. Integrar la infraestructura en el
sistema operativo tiene como ventaja la eficiencia y la facilidad de
uso. La principal ventaja de una capa separada es que se
independiza la solucin de alta disponibilidad del sistema operativo,

20

con lo que resulta ms portable. En cualquier caso el sistema debe

tener la capacidad de aparecer como un nico sistema (SSI Single
System Image). En caso de un clster de alta disponibilidad para
asegurar esta apariencia nica los elementos ms importantes son el
sistema de ficheros global, dispositivos globales y la red global.3

Figura 2.4 Alta disponibilidad

2.1.2.2. Escalabilidad

La escalabilidad es la capacidad de un equipo para hacer frente a

volmenes de trabajo cada vez mayores brindando siempre nivel de
rendimiento aceptable. Existen dos tipos de escalabilidad:

Escalabilidad del hardware (denominada tambin escalamiento

vertical). Se basa en la utilizacin de un gran equipo cuya
capacidad se aumenta a medida que lo exige la carga de trabajo
existente.
3

http://www.redes-linux.com/manuales/cluster/clustering.pdf

21

Escalabilidad del software (denominada tambin escalamiento

horizontal). Se basa, en cambio, en la utilizacin de un clster
compuesto de varios equipos de mediana potencia que funcionan en
tndem de forma muy parecida a como lo hacen las unidades de un
RAID (Redundant Array of Inexpensive Disks o Array redundante de
discos de bajo coste).

Se utilizan el trmino RAC (Redundant Array of Computers o Array

redundante de equipos) para referirse a los clster de escalamiento
horizontal. Del mismo modo que se aaden discos a un array RAID
para aumentar su rendimiento, se pueden aadir nodos a un clster
para aumentar tambin su rendimiento.

La disponibilidad y la fiabilidad son dos conceptos que, si bien se

encuentran ntimamente relacionados, difieren ligeramente. La
disponibilidad es la calidad de estar presente, listo para su uso, a
mano, accesible; mientras que la fiabilidad es la probabilidad de un
funcionamiento correcto.

Pero hasta el ms fiable de los equipos acaba fallando, lo que

genera que los fabricantes de hardware intenten anticiparse a los
fallos aplicando la redundancia en reas clave como son las
unidades de disco, las fuentes de alimentacin, las controladoras de
red y los ventiladores, pero dicha redundancia no protege a los
usuarios de los fallos de las aplicaciones. De poco servir, por lo
tanto, que un servidor sea fiable si el software de base de datos que
se ejecuta en dicho servidor falla, ya que el resultado no ser otro
que la ausencia de disponibilidad. sa es la razn de que un solo
equipo no pueda ofrecer los niveles de escalabilidad, disponibilidad y
fiabilidad necesarios que s ofrece un clster.

22

Importante
En un clster activo / pasivo el incrementar el nmero de nodos
disponibles en el clster no incrementa la potencia del clster ya que
nicamente un nodo estar ofreciendo el servicio.

2.1.3. Funcionamiento de un clster

El funcionamiento de los clusters es muy simple: se trata de un

conjunto de piezas, por ejemplo, de varios microprocesadores a
travs de una red de alta velocidad que los vincula de forma tal que
funcionan como un nico ordenador pero de una potencia mayor al
convencional.

Un clster se implementa bsicamente con varias computadoras

similares

de

capacidades

no

necesariamente

altas.

Las

computadoras deben conectarse en una LAN compartida dedicada

slo para el clster. El clster de alto rendimiento opera bajo
circunstancias en el que las tareas a procesar se reparten
paralelamente a las computadoras.

Un servicio de clster consta de:

Balanceador de carga.

Sistema para la deteccin de fallos en los nodos del

clster.

Servicio a clusterizar.

Recursos del clster.

2.1.3.1. Balanceador de carga

Los balanceadores de carga permiten optimizar la utilizacin de

los recursos de un clster mediante la asignacin de tareas a los

23

nodos con menor carga de trabajo, o con mayor cantidad de

recursos libres.
Son necesarios en las configuraciones que sean Activo / Activo
y/o balanceo de carga.

La funcin de los balanceadores, tambin conocidos como

network dispatcher es redireccionar las peticiones a los servidores
que las estn atendiendo.

Figura 2.5 Balanceador de Carga

2.1.3.2. Sistema para la deteccin de fallos en los nodos del clster

En caso de aparicin de fallo en algn componente, la tolerancia a

fallos busca que el sistema siga trabajando, aunque est
funcionando en modo degradado, hasta que acabe la ejecucin, lo
que podr incidir en mayor o menor medida en sus prestaciones.

24

La tolerancia a fallos en un sistema se logra mediante la inclusin

de tcnicas deredundancia. Puede haber redundancia en
cualquier nivel: utilizacin de componentes hardware extra
(redundancia en el hardware), repeticin de las operaciones y
comparacin

de

los

resultados

(redundancia

temporal),

codificacin de los datos (redundancia en la informacin) e incluso

la realizacin de varias versiones de un mismo programa y del
uso de tcnicas de Replicacin de Datos (redundancia de datos) o
de checkpoint (redundancia de estados).

Los mecanismos para tolerancia a fallos pueden tener un soporte

hardware o software, o bien una combinacin de ambos. En
sistemas en que la incidencia de fallos sea escasa puede ser
recomendable emplear mecanismos de bajo coste con soporte
software, siempre que el algoritmo pueda proporcionar la garanta
de que acabe la ejecucin correctamente aunque se degraden
sus prestaciones.
Es necesario un sistema que detecte cuando existen nodos en el
clster que no estn disponibles para ofrecer el servicio. En este
caso no se enviarn peticiones para ser atendidas si el clster es
Activo / Activo o no se balancear el servicio sobre ellos si es
Activo / Pasivo.

Para detectar esta situacin se utilizan dos tcnicas:

1. Heartbeat.
2. Disco de quorum.
Estos conceptos sern detallados ms adelante.

2.1.3.3. Recursos del clster

Son todos aquellos recursos necesarios para el servicio:
IP de servicio.

25

Filesystems.
Scripts para arrancar el servicio

Figura 2.6 Recursos del Clster

2.1.3.4. Servicio a clusterizar

Es el servicio que se quiere clusterizar. Algunos de los servicios

que pueden ser clusterizados son los siguientes:
Servidores de Bases de Datos.
Servidores Web.
Servidores de Balanceo de Carga.
Servidores de Correo.
Servidores Firewall.
Servidores de Archivos.
Servidores DNS.
Servidores DHCP.

26

Servidores Proxy Cache

2.1.4. Balanceo de Carga

Con el crecimiento de Internet en los ltimos aos el trfico en la

red ha aumentado de forma radical y con l, la carga de trabajo
que ha de ser soportada por los servidores de servicios,
especialmente por los servidores web.

Para soportar estos requerimientos hay dos soluciones: o bien el

servidor se basa en una mquina de altas prestaciones, que a
largo plazo probablemente quede obsoleta por el crecimiento de
la carga, o bien se encamina la solucin a la utilizacin de la
tecnologa de clustering para mantener un clster de servidores
de tal manera que cuando la carga de trabajo crezca, se aadirn
ms servidores al clster.

Hay varias formas de construir un clster de balanceo de carga.

Una solucin basada en mantener varios servidores aunque no se
trate de un clster propiamente es utilizar un balanceo de carga
por DNS. En este caso, se asigna un mismo nombre a distintas
direcciones IP y se realiza un round robin a nivel de DNS entre
ellas.

En una situacin ideal la carga se repartir equitativamente entre

los distintos servidores. Sin embargo, los clientes cachean los
datos del DNS, con lo que la carga no va a repartirse
equitativamente y quedara desbalanceada.

27

Figura 2.7 Balanceo de Carga

Adems, an cuando el balanceo de los accesos de los clientes a

los servicios se haga de forma balanceada, estos clientes pueden
solicitar cargas muy distintas de trabajo al servidor al que se
conectan: mientras un cliente puede querer tan slo ver una
pgina, otro puede solicitar un buen nmero de ellas. Por otra
parte, si un servidor cae, se van a seguir redirigiendo peticiones a
l.

Una solucin mejor es utilizar un balanceador de carga para

distribuir sta entre los servidores de un clster. En este caso el
balanceo queda a nivel de conexin, con una granularidad ms
fina y con mejores resultados. Adems, se podrn enmascarar
ms fcilmente las posibles cadas de los nodos del clster.

El balanceo de carga puede hacerse a dos niveles: de aplicacin

y a nivel IP. Sin embargo, el balanceo a nivel de aplicacin puede
provocar efectos de cuello de botella si el nmero de nodos es
grande. Cada solucin debe elegirse en funcin de las

28

necesidades del problema al que hacemos frente. El Linux Virtual

Server utiliza balanceo a nivel IP.

El proyecto Linux Virtual Server (LVS) ofrece parches y

aplicaciones de mantenimiento y gestin que permiten construir
un cluster de servidores que implementa alta disponibilidad y
balanceo de carga sobre el sistema operativo GNU/Linux. El
sistema aparece al usuario externo como un nico servidor
(en realidad, como un nico servidor virtual).

Cada uno de los servidores reales que forman el cluster, es

controlado por un nodo director que se encarga de realizar el
balanceo de carga. Este director corre un sistema operativo
GNU/Linux con un kernel parcheado para incluir el cdigo ipvs,
que es la herramienta ms importante ofrecida por el proyecto
LVS. El director puede ser entendido en trminos generales como
un router con un conjunto concreto de reglas de enrutamiento.

Cuando un cliente solicita un servicio al servidor virtual, el director

escoge un servidor real para que lo ofrezca. Desde ese momento
el director debe mantener la comunicacin entre el cliente y el
servidor real. Esta asociacin entre cliente y servidor real va a
durar slo lo que dure la conexin tcp establecida; cuando se
inicie una nueva conexin el director escoger de nuevo un
servidor real que puede ser distinto del anterior. As, si el servicio
ofrecido es una pgina web, el cliente podra obtener las
imgenes o los textos desde distintos servidores reales ocultos
por el servidor virtual.

Con esta arquitectura, adems del balanceo de carga, estamos

permitiendo que los servidores reales individuales puedan ser

29

extrados del LVS, actualizados o reparados y devueltos al clster

sin interrumpir la prestacin de servicio.

Asimismo, el sistema es fcilmente escalable y la

alta

disponibilidad en LVS se disea utilizando software mon,

heartbeat, fake y coda, que se utilizan para gestionar la alta
disponibilidad

para

mantener

una

gestin

segura,

la

comunicacin (hearbeat) entre mquinas y un sistema de ficheros

tolerante a fallos, respectivamente.

2.1.4.1. Balanceadores hardware

Los balanceadores de carga de Hardware son mquinas con el

propsito especfico de balancear la carga.

Este tipo de balanceadores tiene ventajas en cuanto a potencia,

estabilidad y escalabilidad.

Las principales desventajas de este tipo de balanceadores es el

precio que se incurra en el equipo y mantenimiento, as como
tambin que se desperdicia recursos ya que son exclusivamente
dedicadas al balanceo de carga.

Algunas de estas soluciones hardware de balanceo de carga son:

WebMux Load Balancing, de CAI Networks.
Big IP Local Traffic Manager, de F5. Quizs sea la principal
alternativa.
Barracuda Load Balancer, de Barracuda Networks.
Cisco Arrowpoint.

30

2.1.4.2. Balanceadores software

Los balanceadores de software son servidores configurados para

realizar la tarea del balanceo. Esto implica instalar en un
computador, un sistema operativo y una aplicacin que se
encargue del balanceo de carga.

Las ventajas que tenemos en estos balanceadores es en cuanto

al precio y que cuando necesitemos un servidor ms potente para
el balanceo de carga, este servidor puede ser reciclado y utilizado
para otra tarea.

En cuanto a sus desventajas se tiene que estos balanceadores

cuentan con una menor potencia y un mayor tiempo de
mantenimiento.

2.1.4.3. Linux Virtual Server - LVS

Linux Virtual Server es una solucin para poder implementar un

servidor virtual altamente escalable y en alta disponibilidad.

Esta solucin consiste en un balanceador de carga, tambin

conocido como director, que ser la mquina que ser accesible
directamente para los clientes y luego tendremos los servidores
que sern aquellos que recibirn las peticiones de los clientes, va
el balanceador de carga, y respondern a las peticiones. Para los
clientes, existirn solo los balanceadores de carga, los cuales
distribuirn la carga entre los servidores reales.

31

Figura 2.8 Balanceadores de Carga

Se obtiene escalabilidad en el servicio aadiendo nodos, mientras

que la disponibilidad se lograra identificando al balanceador que
no funciona, y que el nodo aadido tome la funcin de
balanceador, para que el servicio no se vea interrumpido.

Esta solucin nos permitir tener el servicio funcionando casi

continuamente ya que no se ver afectado por posibles cadas de
las mquinas debido a fallos en el suministro elctrico o bien
cortes en el ISP de una determinada granja.

Cualquiera de estos fallos, u otros que pudieran ocurrir, afectarn

a una o varias granjas, pero nunca a todas con lo cual el servicio
seguir funcionando aunque los clientes podrn experimentar
cierta demora en el servicio.

Para los clientes existir un nico servidor (el balanceador) que se

encargar de distribuir la carga entre los servidores reales.

32

La escalabilidad en el servicio la conseguiremos aadiendo

nodos, mientras que la disponibilidad se lograr identificando el
nodo o el balanceador que no funciona y reconfigurando el
sistema de tal forma que el servicio no se vea interrumpido. Es
decir no enviando peticiones a un nodo que no pudiera dar
servicio en ese momento.

2.1.5. Deteccin de fallos en los nodos del clster

Un clster debe conocer cuando algn nodo no est disponible para
no enviarle peticiones de servicio. Por lo cual, un sistema de
deteccin de fallos en los nodos del Clster es vital para su
funcionamiento.
Esto se hace de dos formas:
Heartbeat
Disco de qurum

2.1.5.1. Heartbeat

Figura 2.9 Heartbeat

33

Es la tcnica ms habitual. Consiste en comunicarse o bien a travs

de una interface de red o puerto serie cada cierto tiempo. Si se
pierde la comunicacin durante un determinado tiempo se supone
que el nodo ha cado.

Para implementar esta tcnica los nodos tiene lneas dedicadas, bien
sea por red o conexiones serie por las que se comunican de forma
continua para verificar el correcto funcionamiento de los nodos.

El funcionamiento de Heartbeat se basa en el envo y recepcin de

seales enviadas por los demonios de Hearbeat que se ejecutan en
ambas mquinas, a estas seales se les conocen como latidos.

La diferencia entre el servidor maestro y el esclavo, radica en la

prioridad que tienen para ofrecer un servicio. Aqu, el esclavo solo
ofrecer el servicio cuando deje de escuchar los latidos del maestro
durante periodo de tiempo determinado, pasado el cual se supondr
que el servidor maestro dej de funcionar.

Una vez que el esclavo vuelva a escuchar los latidos del maestro,
este tomar el control nuevamente, a menos que dentro de la
configuracin

de

Heartbeat

se

haya

colocado

la

directiva

auto_failback en off. Esta directiva puesta en off, quiere decir que si

la mquina que era maestro vuelve a funcionar, ya no retomar el
control del servicio, sino se convertir en la nueva esclava.

El maestro y esclavo pueden comunicarse por medio de dos

interfaces, el puerto serial (RS-232) o las tarjetas Ethernet.

Puede darse el caso de un error en la interfaz que une a ambas

mquinas que imposibilita la llegada de latidos hacia el esclavo. Si

34

sucede esto, el esclavo interpretar errneamente que el servidor

maestro ha cado y tratara de tomar el control de la prestacin del
servicio, cuando el servicio nunca ha dejado de prestarse.

2.1.5.2. Disco de quorum

Disco de quorum es una tcnica complementaria que lo que se hace

es que todos los nodos del clster escriben su estado en un disco y
de esa forma se determina quien est disponible para dar el servicio.

Si un nodo tiene problemas de red y no llega a los otros nodos

pensar que los otros nodos no estn disponibles e intentar
hacerse con el servicio.

Si disponemos de dispositivos serie para el heartbeat entonces

dispondremos de una forma de comprobar que los otros nodos estn
funcionando correctamente y el problema es nuestro. De no
disponerlo se asumir de forma incorrecta que los otros nodos han
fallado, intentando asumir el control del clster. Para evitar esto se
utiliza el disco de quorum.

Cada nodo escribe de forma continua su estado en el disco y de esta

forma se puede verificar que nodos estn disponibles para hacerse
con el servicio en el clster.

Importante
El disco de quorum no es una tcnica que sustituya al heartbeat es
una tcnica que debe usarse como complemento al heartbeat.

35

Figura 2.10 Disco de Quorum

36

CAPITULO 3

INTRODUCCION
En este captulo se presentarn las soluciones de software libre para
mitigar el problema de alta disponibilidad y balanceo de carga, se
expondrn sus caractersticas as como las herramientas que hacen
posible la construccin de dichas soluciones.

Adems se llevar a cabo una comparativa de las herramientas

existentes para la realizacin del clster, adems de ello, se describirn
tales herramientas de forma breve en cuanto a sus componentes y su
funcionamiento.

DIAGNOSTICO

3.1. Herramientas de open source para la construccin del Clster

Podemos encontrar una amplia variedad de aplicaciones para la
creacin de clsters, la utilizacin de una u otra de estas depender
de la complejidad de instalacin, uso especfico y ventajas de este
sobre otras herramientas. De las opciones que se pueden encontrar
estn:

openMosix.

Oscar.

Piranha.

Linux Virtual Server.

Ultramonkey.

A continuacin la tabla 3.1 muestra las principales caractersticas de

cada herramienta para la construccin de clsters.

37

Herramienta.

Caractersticas.

Parche al kernel de GNU/Linux.

Algoritmo interno de balance de carga que migra

openMosix

los procesos entre nodos.

Migracin de procesos totalmente transparente.

Auto descubrimiento de nuevos nodos openMosix

en la red del clster.

Permite instalar un clster tipo Beowulf.

Contiene todo el conjunto de paquetes necesarios

OSCAR

para programar y administrar el clster.

Formado por dos componentes principales SIS

(System Installation Suite) y ODA (OSCAR
Database API).

Piranha

Implementacin de software de alta disponibilidad.

Interfaz web para control completo del clster.

Posee herramientas para su monitorizacin.

Balance mediante direcciones IP.

Requiere el sistema operativo Red Hat Enterprise.

Constituido por un servidor altamente escalable y

de alta disponibilidad.

Linux Virtual Server LVS

Balance de carga mediante nodo dedicado con

sistema operativo GNU/Linux.

Clster completamente transparente al usuario

final.

Mecanismo para que el clster funcione con una IP

pblica.

Permite balance de carga y alta disponibilidad.

Incluye monitorizacin de servidores reales y

nodos de balance.

Permite el manejo de protocolos como HTTP, FTP,

38

DNS, entre otros.

Ultramonkey

Permite usar iptables o ipchains para marcar los

paquetes que pertenezcan al servicio prestado por
el clster.

Usado desde clsters de dos nodos hasta grandes

sistemas.

Tabla 3.1 Caractersticas de Herramientas para Clsters.

Por ltimo, se mostrarn las ventajas y desventajas de cada una de

las herramientas anteriormente mencionadas, pues es importante
tener

presente

esta

comparativa

para

hacer

una

primera

aproximacin a la eleccin de una sola herramienta para llevar a

cabo una implantacin eficaz y sencilla que cubra las necesidades
solicitadas; esto se refleja en la tabla 3.2.

Herramienta.

Ventaja.

openMosix

Desventaja.

No se requieren paquetes

Depende del kernel.

adicionales.

No migra todos los

No son necesarias
modificaciones en el

procesos siempre.

cdigo de openMosix.

Problemas con
memoria compartida.

Migracin de procesos.

Falla la deteccin de
algunos componentes

Es una compilacin auto

de hardware en

instalable.

versiones anteriores a

Infraestructura de software

la 3.

para instalar y administrar

OSCAR

Soporte para

un clster.

distribuciones basadas

Posee bibliotecas y

en RPMs solamente

39

compiladores para uso en

para versiones

clsters.

anteriores a la 5.

Requiere que la LAN no

sea usada para instalar
software en el clster.

Piranha

Soporte por parte de Red

Al momento solo

Hat Inc.

disponible para

Fcil instalacin debido al

versiones

formato de distribucin.

empresariales de Red

Administracin y manejo

Hat.

mediante interfaz web.

Dependiente del

Monitorizacin de

sistema operativo Red

servidores reales.

Hat Enterprise.

Fcil comprensin de

Algunos esquemas se

funcionamiento.

ven afectados por la

Amplia gama de

cantidad de servidores

configuraciones.

reales que se pueden

utilizar.

Linux Virtual Server

Funciona a nivel TCP/IP.

- LVS

Manejo de varios tipos de

Cuando el nmero de

protocolos como HTTP,

servidores reales es

DNS, FTP entre otros.

elevado se genera
mucho trfico en la red
de trabajo.

Mltiples esquemas de
configuracin.

Rene varias herramientas

de una manera sencilla.

Los nodos directores

Varios formatos para su

tienen que ejecutar

instalacin.

estrictamente el

Amplia documentacin

sistema operativo

sobre cada componente.

GNU/Linux.

40

Ultramonkey

Instrucciones de

Segn el esquema de

instalacin para las

configuracin puede

distribuciones de

llegar a ser complejo.

GNU/Linux ms comunes

Mismas que en LVS

en servidores.

para los componentes

Se apoya en el proyecto

que sean utilizados de

LVS para algunos

dicho proyecto.

componentes.

No es dependiente de una
distribucin de GNU/Linux
en particular.

Tabla 3.2 Ventajas y Desventajas de las Herramientas para Clster.

3.2. Comparacin de las herramientas de balanceo de carga y alta

disponibilidad

Formato

Distribucione

Balanceo de

Herramient

de

s Soportadas

carga y Alta

Distribuci

Ventajas

Desventajas

disponibilidad

n
No requiere

Dependiente

Balanceo de

paquetes

del kernel y

carga de

adicionales y

posee

Cdigo

procesos sin

hace

problemas con

fuente.

alta

migracin de

memoria

disponibilidad.

procesos.

compartida.

openMosix RPM,

Todas.

En versiones
anteriores a la
tercera falla la
Auto instalable deteccin de

41

OSCAR

RPM,

Red Hat y

Balanceo de

con bibliotecas hardware y no

Cdigo

basadas en

carga de

permite usar la

fuente.

esta.

procesos sin

compiladores

red interna

alta

para computo para

disponibilidad.

paralelo.

instalacin de
software.

Red Hat
Piranha

RPM.

Posee

Soporte de

Actualmente

Red Hat,

disponible solo

Enterprise 4 o herramientas

administracin en formato

posteriores.

propias para

y manejo

RPM y para

ambos

mediante

versiones

aspectos.

interfaz web.

empresariales.
Instalacin por

Amplia gama

segmentos;

Incluye

de

con un gran

Linux

RPM, DEB, Todas.

herramientas

configuracione nmero de

Virtual

Cdigo

de cdigo

s, funcin a

Server

fuente.

abierto para

nivel TCP/IP y reales el

ambos

manejo de

trfico crece

aspectos.

distintos

de manera

protocolos.

significativa.

servidores

Los nodos de
Mltiples
Basadas en

Uso de

configuracione carga debern

Debian, Red

componentes

s, manejo de

ejecutar el

distintos

sistema

ambos

protocolos,

operativo

compilacin

aspectos

funcin a nivel GNU/Linux;

de cdigo

aadiendo

TCP/IP,

dependiendo

fuente.

algunas

marcas de

del esquema

mejoras y

firewall y

llega a ser

Hat Enterprise de LVS para

RPM. DEB, 4 y mediante
Ultramonke Cdigo
y

fuente.

balance de

42

herramientas.

ampliacin de complejo de
LVS.

configurar.

Tabla 3.3 Comparacin de herramientas para clster.

Una de las herramientas las ms usadas es Piranha de la empresa

Red Hat., que incorpora balance de carga mediante direcciones IP y
tambin hace la inclusin de cdigo del proyecto LVS, en esta
herramienta Red Hat incorpor mejoras; para poder hacer uso
eficiente de Piranha es recomendado el uso de Red Hat Enterprise
Linux 4 o posterior, su sencillez en instalacin y amplio soporte por
parte

de

dicha

empresa

brinda

satisfaccin

al

hacer

una

implementacin con esta. Fuera del pago de la licencia para el

sistema operativo el software de Piranha est disponible de manera
gratuita para usuarios registrados de esta distribucin.

Junto a la anterior herramienta se puede encontrar el proyecto LVS

el cual fue iniciado por Wensong Zhang en Mayo de 1998 y su
principal objetivo era desarrollar un servidor GNU/Linux de alto
rendimiento que proporcione un buena escalabilidad, confianza y
robustez usando la tecnologa de clster. De los avances ms
importantes de LVS es el desarrollo de un sistema IP avanzado de
balanceo de carga por software (IPVS), balance de carga por
software a nivel de aplicacin y componentes para la gestin de
clster. Se puede usar LVS como solucin para construir sistemas
altamente escalables, donde se garantiza una alta disponibilidad de
los servicios de red como el correo electrnico, voz sobre IP y el
servicio web.

La siguiente opcin es Ultramonkey, siendo una de las herramientas

ms completas en cuanto a balanceo de carga y alta disponibilidad;
ya en su tercera versin cuenta con formatos de instalacin para

43

diversas distribuciones de GNU/Linux como Debian y Red Hat. Esta

herramienta solo puede ser usada en estaciones cuyo sistema
operativo

sea

GNU/Linux

siendo

este

uno

de

sus

pocos

inconvenientes en lo que respecta a la independencia de plataforma.

Hace uso de las tecnologas de LVS, Linux-HA y Ldirectord para
lograr ambas metas que son el balance de carga y la alta
disponibilidad. De entre los posibles esquemas de configuracin se
cuenta con soluciones separadas o una que incorpore ambas, as
como tambin un esquema estndar o uno ms completo.

La herramienta OSCAR es una coleccin de software de cdigo

abierto para crear un clster sobre GNU/Linux desarrollada por el
Grupo de Clsters Abiertos (OCG Open Clster Group). El objetivo
primario del grupo de trabajo OSCAR es conseguir que la
instalacin, la configuracin y la administracin de un clster de
tamao modesto, sea fcil. Cualquier cosa necesaria para un clster
como instalacin y configuracin, mantenimiento, programacin
(paralela), sistemas de encolamiento, programacin de tareas, est
incluida en OSCAR. Su principal labor es para cmputo de alto
rendimiento.

En Open Mosix los procesos no saben en qu nodo del clster se

ejecutan, y es el propio Open Mosix el responsable de "engaarlos",
y redirigir las llamadas al sistema al nodo del clster en el que se
lanz el proceso. Open Mosix implementa un algoritmo de balance
de carga que permite repartir de forma ptima la carga, si est el
clster bien calibrado. Open Mosix puede migrar cualquier proceso
mientras que no haga uso de los segmentos de memoria
compartida. Segn la calibracin, migrarn procesos ms ligeros, o
ms pesados.

44

Dadas las caractersticas vistas con anterioridad en la tabla 3.3 y

esto aunado a los fines que persiguen hacen inclinar la balanza por
las siguientes opciones mejor adaptadas a este campo que son:

Piranha.

Linux Virtual Server.

Ultramonkey.

Se proceder ahora a describir cada una de las tres herramientas

ms comunes, cabe destacar que cada una es revisada de manera
breve resaltando mediante figuras el funcionamiento de cada una de
ellas as como mencionando los componentes de cada una.

3.2.1. Herramientas de balanceo de carga y alta disponibilidad

3.2.1.1. Piranha
Es un conjunto de aplicaciones en un ambiente bien unido para los
administradores que desean instalar servicios de clster en
ambientes GNU/Linux. Un clster piranha se compone de los
siguientes elementos:

El parche IPVS para el kernel.

El demonio LVS para manejar las tablas IPVS a travs de

ipvsadm.

El demonio nanny para monitorizar servicios y servidores.

El demonio pulse para controlar el estado del resto de

demonios del clster y la entrada en funcionamiento del nodo
de balance de carga de respaldo en caso de fallo del primario.

La interfaz grfica piranha para administrar el clster.

Todos estos demonios utilizan el mismo archivo de configuracin

ubicado en el directorio /etc/lvs.cf para su funcionamiento. Como un
valor aadido a piranha este es capaz de adaptar los pesos de los
algoritmos de planificacin automticamente segn las estadsticas

45

de funcionamiento de cada servidor.

En la figura 3.1 se aprecia

cmo se compone un clster con Piranha.

Figura 3.1 Esquema de funcionamiento de Piranha.

3.2.1.2. Linux Virtual Server

Es un software para el balanceo de carga que permite crear un
clster de forma rpida y eficaz sin hacer grandes inversiones en
hardware dedicado. Es una solucin ideal para aquellas empresas
que quieren ahorrar costos permitiendo tener tras una nica
direccin IP pblica muchos servidores reales y servicios de forma
transparente a los usuarios.

Es implementado como un conjunto de parches al kernel de

GNU/Linux y un programa denominado ipvsadm. La principal meta
de LVS es proveer un mecanismo de migracin de sockets. Un
clster de este tipo est formado por dos tipos de mquinas, los
nodos o servidores reales que corren con los servicios habituales
que estos suelen proveer y los nodos directores o de balanceo de

46

los cuales uno de ellos ser el principal y el resto estarn preparados

para actuar de respaldo del principal para cuando este falle. LVS
funciona a nivel TCP/IP, lo que se conoce como un switch de nivel 4
o mejor conocido como capa 4. Lo que en realidad administra LVS
son direcciones y puertos de origen y destino, y toma decisiones
para balancear la carga con esta informacin.

LVS soporta tres modos de trabajo distintos, estos modos definen el

mtodo

en

que

el

nodo

de

balanceo

retransmitir

las

comunicaciones provenientes de los usuarios a los servidores reales

definidos.
LVS permite balancear muchos protocolos distintos. LVS se ha
usado con HTTP, HTTPS, FTP, etc. En la figura 1.10 se muestra su
funcionamiento.

Figura 3.2 Esquema de funcionamiento de LVS.

47

3.2.1.3. Ultramonkey
Es un proyecto que integra diferentes herramientas de software libre
para conseguir alta disponibilidad y balanceo de carga en redes LAN
redes de rea local. Estas herramientas son: LVS, Heartbeat,
Ldirectord y MON como lo muestra la figura 3.3.

3.2.1.3.1. Componentes Ultramonkey

LVS realiza balanceo de carga y facilita la alta disponibilidad entre
los servidores reales. Sin embargo, el nodo de balanceo de carga se
convierte en un punto nico de fallo, si se quiere alta disponibilidad
se deber aadir otro nodo de balanceo de respaldo y usar software
de alta disponibilidad que le permita tomar el papel del nodo de
balanceo de carga principal.

3.2.1.3.1.1. Heartbeat
Funciona enviando peridicamente un paquete, que si no llegara,
indicara que un servidor no est disponible, por lo tanto se sabe que
el servidor ha cado y se toman las medidas necesarias. Se
recomienda el uso de puertos serie puesto que estn aislados de las
tarjetas de red. Soporta mltiples direcciones IP y un modelo
servidor primario/secundario.

Los mensajes de Heartbeat se envan por todas las lneas de

comunicacin a la vez, de esta manera, si una lnea de apoyo cae,
se avisar de ese problema antes de que la lnea principal caiga y no
haya una lnea secundaria para continuar el servicio. Heartbeat
tambin se preocupa por la seguridad, permitiendo firmar los
paquetes con CRC de 32 bits, MD5 y SHA1.

48

3.2.1.3.1.2. Ldirectord
Se encarga de monitorizar que los servidores reales permanezcan
funcionando peridicamente, enviando una peticin a una direccin
URL (Uniform Resource Locator) conocida y comprobando que la
respuesta contenga una cadena concreta. Si un servidor real falla,
entonces el servidor es quitado del conjunto de servidores reales y
ser reinsertado cuando vuelva a funcionar correctamente. Si todos
los servidores fallan, se insertar un servidor de fallos, que ser
quitado una vez que los servidores vuelvan a funcionar.

3.2.1.3.1.3. Mon (Service Monitoring Daemon)

Es un software para la monitorizacin del sistema. Este permite
definir una serie de alarmas y acciones a ejecutar cuando un servicio
deja de funcionar y se utiliza ampliamente como componente de
monitorizacin de recursos para Heartbeat.

Figura 3.3 Componentes de Ultramonkey.

Mientras el software Ultramonkey funciona por s mismo en

GNU/Linux, este puede proporcionar servicios de clster para

49

virtualmente cualquier red de servicios corriendo en un sistema

operativo que pueda comunicarse usando TCP o UDP. Soporta un
amplio rango de protocolos, con comprobacin nativa de integridad
para: Web, Mail, FTP, News, LDAP y DNS. Tambin provee de
paquetes binarios para una lista de distribuciones seleccionadas.

La figura 3.4 muestra un esquema tpico de funcionamiento de

Ultramonkey en el cual existe balanceo de carga y alta disponibilidad.

Figura 3.4 Esquema de funcionamiento de Ultramonkey.

50

CAPITULO 4

INTRODUCCION
En este captulo se llevar a cabo un anlisis de los mtodos
existentes de balanceo de carga, dado que estos llegan a ser
complejos solamente se tratar la teora ms bsica de operacin;
adicionalmente se realizar la toma de decisin de una herramienta
para su implementacin.

DISEO

4.1. Tipos de balanceo de carga

Existen dos formas simples para montar un clster y distribuir la
carga entre los equipos mostradas en la tabla 4.1 a continuacin.

Mtodo

Ventajas

Desventajas
El

DNS
Round
Robin.

cache

de

la

informacin

en

la

Distribucin de la carga

jerarqua

entre servidores reales

servidores DNS y la

de

forma

forma

pseudo-

de

simple

de

aleatoria.

tomar decisiones por

Es el ms simple de

parte

implementar.

DNS restringen su

del

servidor

utilidad.
Los servidores no
pueden

ser

51

seleccionados segn
el URL solicitado.4
Este nodo distribuye las

Llega a convertirse

conexiones.

en cuello de botella.

Se

aumenta

Uso de nodo

sensacin

de balanceo

del clster.

de carga.

nica

de

la
unidad

Hace uso de un nodo

adicional

para

proveer el balanceo

direccin

IP

de carga.

pblica a la cual dirigir

Al

existir

las peticiones.

nodo

Es sencillo enmascarar

este se convierte en

fallas de los servidores.

un punto nico de

de

solo

un

balanceo

fallo.

Tabla 4.1 Mtodos de balanceo de carga.

4.1.1. Modos de balanceo de carga en LVS

LVS permite realizar el reenvo de paquetes a los servidores
reales de tres formas. En la tabla 4.2 se muestran los tres modos
de balanceo.

Modo de

Ventajas

Desventajas

balanceo
Aprovecha

Balanceo
mediante NAT.

la

El

nodo

posibilidad del kernel

balanceo se llega a

de Linux de funcionar

convertir en cuello

como router con NAT.

de botella.

Los servidores reales

Tiene que reescribir

pueden

todos los paquetes

ejecutar

(Network
4

de

http://www.wikilearning.com/monografia/balance_de_carga-la_aproximacion_via_dns/20837-2

52

Address

cualquier

Translation).

sistema

TCP/IP.

operativo que soporte

Nmero

TCP/IP.

servidores

Uso

de

una

solamente

direccin

IP

pblica.

de
reales

dependiente de la
velocidad

de

conexin del nodo

de balanceo.
No

Escalado

los

hasta

sistemas operativos

Balanceo

100 servidores o ms.

son soportados por

mediante

Se evita que el nodo

este modo.

de

Los

encapsulado IP
(IP Tunneling)

de

todos

balanceo

se

convierta en cuello de

reales

botella.

tener

servidores
necesitan
una

IP

pblica.
Todos

los

servidores
poseer

deben
una

IP

Balanceo

El nodo de balanceo

pblica en el mismo

mediante

no

segmento de

es

cuello

de

red

enrutamiento

botella.

del

directo (Direct

No se sobrecarga al

balanceo.

Routing)

nodo de balanceo en

No

reescribir

sistemas operativos

TCP/IP.

paquetes

nodo

todos

de

los

permiten configurar
una IP o dispositivo
para responder a
comandos ARP.

Tabla 4.2 Modos de balanceo de carga en LVS.

53

Balanceo mediante NAT

NAT (es un mecanismo utilizado por routers IP para intercambiar
paquetes

entre

dos

redes

que

se

asignan

mutuamente

direcciones incompatibles. Consiste en convertir en tiempo real

las direcciones utilizadas en los paquetes transportados. Tambin
es necesario editar los paquetes para permitir la operacin de
protocolos que incluyen informacin de direcciones dentro de la
conversacin del protocolo).5
A continuacin se explica mediante figuras el funcionamiento de
cada uno de los modos de balanceo, en la figura 4.1 siguiente se
puede ver todo el proceso para el modo NAT:

Figura 4.1 Balanceo mediante NAT.

http://www.adslfaqs.com.ar/que-es-nat-network-address-translation/

54

Balanceo mediante encapsulamiento IP

De acuerdo a la figura 4.2 el proceso es el siguiente:
1.

El usuario realiza una peticin de servicio a la IP pblica

del clster (la del nodo de balanceo de carga o IP virtual
del clster).

2.

El nodo de balanceo planifica a qu servidor real se va a

enviar la peticin, reescribe las cabeceras de las tramas
TCP/IP y las enva al servidor.

3.

El servidor recibe la peticin, la procesa, genera la

respuesta y la enva al nodo de balanceo de carga.

4.

El nodo de balanceo reescribe de nuevo las cabeceras de

las tramas TCP/IP con la respuesta del servidor, y las
enva de vuelta al usuario.

5.

La respuesta llega al usuario, como si la hubiese generado

la IP pblica del clster.

En el modo de balanceo por encapsulamiento IP, su funcin se

ilustra a continuacin con la figura 4.2:

55

Figura 4.2 Balanceo mediante encapsulado IP.

El nodo de balanceo recibe todas las conexiones de entrada al

clster, y decide a qu servidor envirselas. Para hacer esto,
utiliza el encapsulado IP para enviar cada trama que recibe a la IP
del servidor que vaya a encargarse de ella. Cuando el servidor
elegido recibe el paquete, lo desencapsula y al tener configurada
la IP pblica del clster como propia, acepta la trama original y se
encarga de servir la peticin que contuviera enviando ste
servidor la respuesta al cliente directamente.

Balanceo mediante enrutamiento Directo

El ltimo modo de balanceo es mediante enrutamiento directo que
se muestra en la figura 4.3:

Figura 4.3 Balanceo mediante enrutamiento directo.

56

Todos los equipos tendrn configurado una interfaz con la IP

pblica del clster: el nodo de balanceo la tendr en su acceso a
Internet y ser el punto de entrada al clster; el resto de equipos
estarn conectados al nodo de balanceo en la misma red fsica y
en la interfaz conectada a sta red tendrn configurada la IP
pblica del clster, pero configurando la interfaz para que no
responda a comandos ARP (todos los equipos responderan por
la misma IP con distintas direcciones fsicas). Al llegar una
peticin al nodo de balanceo ste decide a qu servidor
envirsela y redirige el paquete a nivel de enlace a la direccin
fsica del servidor elegido en lugar de modificar o encapsular el
paquete TCP/IP. Cuando llega al servidor con la direccin fsica
de destino y se analiza hasta el nivel de red (TCP/IP), como el
servidor tambin tiene configurada la IP pblica del clster, acepta
sin ms el paquete y genera la respuesta que enviar
directamente al cliente.

4.1.2. Resumen de los mtodos de balanceo

En la tabla 4.3 a continuacin se resumen las caractersticas
principales de los tres mtodos de direccionamiento que puede
utilizar el balanceador de carga de Linux Virtual Server:

NAT

Servidor

Red de
servidores

Cualquiera

Red Privada

Encapsulamiento IP

Necesita
Encapsulamiento

LAN/WAN

Enrutamiento
Directo

Dispositivo no-ARP

LAN

57

Escalabilidad

Baja (10~20)

Salida hacia

Nodo

Internet

de

balanceo

Alta

Alta

Router

Router

Tabla 4.3 Mtodos de direccionamiento.

4.1.3. Planificacin del balanceo de carga

Al momento de configurar el nodo de balanceo se podr elegir
entre una serie de algoritmos para ver cmo se distribuir la carga
entre los servidores y cmo se elegir el servidor al que se enva
cada peticin. Linux Virtual Server permite utilizar los siguientes
algoritmos que se muestran en la tabla 4.4:

Algoritmo

Funcionamiento
Cada peticin se enva a un servidor y la siguiente

Round Robin

peticin al siguiente servidor de la lista hasta llegar al

ltimo tras lo cual se vuelve a enviar al primero, vase la
figura 4.4.
Igual que el anterior algoritmo pero aadiendo un peso a
cada servidor, este peso es un entero que indica la

Round Robin

potencia de clculo del servidor, de modo que la cola

Ponderado

Round Robin se modificar para que aquellos servidores

con mayor capacidad de clculo reciban peticiones ms
a menudo que el resto, vase la figura 4.5.
Este mecanismo de distribucin consulta a los servidores

Servidor con

para revisar en cada momento cuntas conexiones

menos

abiertas posee cada uno con los clientes, y enva cada

conexiones

peticin al servidor que menos conexiones tenga en ese

activas.
Servidor con

momento, vase la figura 4.6.

Igual que el algoritmo anterior pero se le aaden pesos a

58

menos

los servidores para que de alguna forma se mida su

conexiones

capacidad de clculo para modificar la preferencia al

activas

momento de hacer una eleccin, vase la figura 4.7.

Ponderado.
Este algoritmo dirige todas las peticiones a un mismo
Menos

servidor, hasta que se sobrecarga (su nmero de

conectado

conexiones activas es mayor que su peso) y entonces

basado en

pasa a una estrategia de menos conexiones activas

servicio.

ponderada sobre el resto de servidores del clster,

vase la figura 4.8.
En estos algoritmos se dispone de una tabla de

Tablas Hash por

asignaciones fijas, en las que bien por la IP de origen o

origen y destino.

destino, se indica qu servidor deber atender la

peticin. El nodo de balanceo compara las direcciones
de las tramas TCP/IP que reciba con estas tablas y
acta en consecuencia, vase la figura 4.9.

Conexiones

A todos los algoritmos de planificacin anteriores se les

Persistentes.

puede aadir el hecho cuando un cliente se ha

conectado con un servidor, siempre se le dirija al mismo
servidor.

Tabla 4.4 Algoritmos de planificacin de balanceo de carga.

59

Figura 4.4 Round Robin.

Figura 4.5 Round Robin Ponderado.

60

Figura 4.6 Servidor con menos conexiones activas.

Figura 4.7 Servidor con menos conexiones activas ponderado.

61

Figura 4.8 Menos conectado basado en servicio.

Figura 4.9 Tablas Hash por origen y destino.

62

La eleccin de una u otra tcnica depende principalmente del

servicio que se quiera proveer, los conocimientos que se posean
de los sistemas, el sistema operativo de los servidores, los
recursos econmicos que se estn dispuestos a gastar, y
consideraciones de rendimiento que afectan al sistema en
conjunto.

4.2. Eleccin de una herramienta para balanceo de carga y alta

disponibilidad
Para poder tomar una decisin acerca de cul herramienta es la
mejor opcin se debe tomar en cuenta factores como: estabilidad,
fiabilidad, costos de implementacin (tanto en hardware como en
conocimientos), escalabilidad entre otros. Como parmetros para
poder evaluar dichas herramientas se usar la cantidad de
requisitos por cada herramienta, facilidad de comprensin e
implementacin as como tambin su disponibilidad para su
adquisicin. Las herramientas evaluadas son Piranha, Linux
Virtual Server y Ultramonkey.
Como punto de partida se compararn los requisitos mnimos
para la implementacin de cada una en cuanto a los equipos que
actan como coordinadores o directores.

Piranha:
Esta herramienta solamente requiere el uso de un navegador web
para configurarse pero una de sus crticas es el hecho de estar
fuertemente ligada a las versiones empresariales de Red Hat y
por tal motivo los mnimos en hardware dependern de la versin
de dicha distribucin que se utilice. Como un punto a favor,
Piranha posee esa extrema sencillez de configuracin brindada
por su interfaz que se basa en web. Para implementarse se tiene
que poseer una licencia de uso del sistema operativo de Red Hat

63

y en particular de una versin empresarial. La tabla 4.5 muestra

los requisitos mnimos de hardware requeridos.

Procesador

Pentium II 300 MHz

Memoria RAM

64 MB

Espacio en Disco Duro

+2 GB recomendado

Interfaz de Red

10 Mbps

Tabla 4.5 Requisitos mnimos de hardware para Piranha.

Linux Virtual Server:

Este es muy simple de implementar y debido a sus caractersticas
los nodos directores o de balanceo pueden poseer o no una
interfaz grfica ya que su administracin es va lnea de
comandos. Como se ha visto, LVS es un parche al kernel de
GNU/Linux y esto es importante de verificar puesto que algunas
versiones del kernel pudiesen no contar con dicho parche de
manera activa siendo uno de los casos todos aquellos kernels
personalizados. Su mayor ventaja es su independencia de la
distribucin del sistema operativo (siempre y cuando sea
GNU/Linux, la distribucin puede variar) pues est ms ligado con
el kernel que con la distribucin. Para su implementacin bastar
con un equipo que cubra los mnimos requisitos en hardware para
una distribucin basada en un kernel 2.4.27 o superior siendo un
ejemplo el de la tabla 4.6.

Procesador

Pentium MMX 166 MHz

Memoria RAM

64 MB

Espacio en Disco Duro

+1 GB (sin interfaz grfica)

Interfaz de Red

10 Mbps

64

Tabla 4.6 Requisitos mnimos de hardware para LVS.

Ultramonkey:
Ultramonkey est pensado como una solucin muy econmica
tanto a nivel de software como en hardware y por tal motivo su
crecimiento se ha dado en gran medida por las contribuciones de
los usuarios de este proyecto dado que es un requisitos dentro de
la comunidad de software libre el compartir sus conocimientos y
estos aportes vienen desde programadores aficionados hasta los
gures de la informtica. En la tabla 4.7 siguiente se aprecian los
mnimos de hardware para ultramonkey.

Procesador

Pentium MMX 166 MHz

Memoria RAM

64 MB

Espacio en Disco Duro

+512 MB (recomendados +1GB)

Interfaz de Red

10 Mbps

Tabla 4.7 Requisitos mnimos de hardware para Ultramonkey.

Se concluye que Ultramonkey es la herramienta que requiere la

menor cantidad de recursos para su instalacin y funcionamiento,
la tabla 4.8 compara los requisitos mnimos de hardware de
Piranha, LVS y Ultramonkey.

Herramienta.

Procesador.

Memori

Espacio

Interfaz

a RAM.

en

de Red.

Disco
Duro.
Piranha.

Pentium II 300MHz

64 MB

+2GB

10
Mbps

65

LVS.

Pentium MMX

64 MB

+1GB

166MHz
Ultramonkey.

Pentium MMX

10
Mbps

64 MB

+512MB

166MHz

10
Mbps

Tabla 4.8 Comparacin de requisitos.

El siguiente punto a evaluar es la complejidad de instalacin,

tmese en cuenta que todos los parmetros que se estn
evaluando son sobre los nodos principales, sin tomar en cuenta
los servidores reales.

Ultramonkey:
Esta es la herramienta ms simple de instalacin de las 3, no es
necesario revisar dependencias o instalar paquetes adicionales
manualmente,

es

un

proceso

totalmente

automatizado

sumamente til, pero si el sistema que acta como nodo director

posee un sistema diferente tendr que llevarse a cabo la
instalacin de dos formas distintas dependiendo de:
Basado en Red Hat: mediante paquetes RPM con la
instruccin rpm -iv *.rpm estando dentro del directorio
que contenga todos los paquetes de Ultramonkey.
Basados en cdigo fuente: tendrn que descargarse
todos los paquetes que conformen Ultramonkey, luego
se procede a descomprimir cada uno y posteriormente
se procede a su compilacin e instalacin.

Piranha:
Esta herramienta es sencilla de instalar si se posee una licencia
del sistema operativo Red Hat Enterprise utilizado, su instalacin
puede realizarme mediante un administrador de paquetes grfico
propio del sistema operativo o bien, mediante la lnea de
comandos con el administrador indicado (en este caso yum). De

66

no poseer tal licencia se deben adquirir los paquetes por separado

y proceder con una instalacin manual en la cual depender el
tipo de paquete adquirido, si es en formato RPM o en forma de
cdigo fuente. La instalacin del conjunto de aplicaciones que
conforman Piranha resulta especialmente compleja si no se posee
la licencia del sistema operativo Red Hat Enterprise en donde se
vaya a realizar la instalacin.

LVS:
Para llevar a cabo la instalacin de LVS es necesario activar los
mdulos de LVS en el kernel de la distribucin utilizada,
posteriormente se debe instalar la aplicacin ipvsadm pues esta
ser nuestra interfaz de comunicacin con LVS. Una vez activado
el soporte y la interfaz con LVS se procede a su configuracin y
pruebas pertinentes. Es importante notar que de no contar con un
kernel con soporte activado las alternativas existentes son una
recompilacin del mismo kernel o la compilacin de uno
totalmente nuevo habilitando dicho soporte en ambos casos; si la
distribucin utilizada posee mecanismos para instalar un kernel
con soporte incluido esto facilita la tarea, de otra manera el
proceso de configuracin, activacin del soporte, compilacin e
instalacin deber realizarse de forma manual.

Se concluye que Ultramonkey es la herramienta que posee los

mecanismos de instalacin ms simplificados, ahorrando tiempo y
esfuerzo dada la automatizacin de los procesos y la facilidad de
acceso a los paquetes que conforman la herramienta. Por ltimo
se ver que tan complejo es obtener las aplicaciones que
conforman la herramienta y los diferentes mtodos que posee
cada una para su distribucin.

67

Ultramonkey:
Este proyecto es de fcil adquisicin puesto que se encuentra
empaquetado en diversos formatos, basta con agregar un
repositorio al archivo y actualizar dichos repositorios para tener
acceso a los paquetes que conforman Ultramonkey, el sistema de
gestin de paquetes har notar que debe instalar otros paquetes
que son dependencias y ubicar los archivos en los sitios
correspondientes; esta es la manera ms fcil de instalar
Ultramonkey, es limpia, rpida y muy eficiente. Si se desea
instalar sobre una distribucin como Red Hat se cuenta con los
paquetes necesarios en formato RPM y se deben de descargar
todos los paquetes y llevar a cabo la instalacin de forma manual,
en caso de usar una distribucin distinta a estas dos, se
proceder a descargar los paquetes en formato GZIP o BZIP2
dependiendo de las necesidades.
Se concluye de lo anterior que la herramienta Ultramonkey posee
una amplia variedad de medios de distribucin y adquisicin para
varios sistemas operativos GNU/Linux eliminando la restriccin de
dependencia de una distribucin en especial. Aunque LVS se
distribuye como cdigo fuente y Piranha en paquetes RPM o
cdigo fuente, la herramienta Ultramonkey brinda una mejor
variedad de formatos y medios de adquisicin siendo este punto
el que le brinda ventaja sobre las anteriores y siendo esta la mejor
eleccin.

Como se puede apreciar por estos tres indicadores, la mejor

opcin para eleccin es Ultramonkey debido a su sistema de
instalacin, variedad de formatos de distribucin as como sus
requisitos mnimos de hardware muy bajos. Sin duda las otras
opciones son muy viables, pero presentan limitantes; con esto
presente

queda

establecido

que

la

mejor

opcin

para

68

implementacin es Ultramonkey ya que est bien acoplado con la

distribucin Centos la cual tiene un elevado reconocimiento en
cuanto a estabilidad y seguridad como en el aprovechamiento de
recursos de una estacin, sistema de gestin de paquetes muy
avanzado y sencillo de usar que resuelve por si mismo varias de
las dependencias de paquetes necesarias.

69

CAPITULO 5

INTRODUCCION
Este captulo tiene como finalidad describir la manera de cmo se lleva a
cabo el proceso de construccin del clster, as como tambin de hacer
notar cuales aspectos se debern tomar en cuenta para su
configuracin.

IMPLEMENTACION EN MAQUINAS VIRTUALES

5.1 INSTALACION Y CONFIGURACION DEL CLUSTER

El clster funcionar de la siguiente manera (figura 5.1), el usuario
realizar una peticin de una pgina web al servicio (el usuario
desconoce que se trata de un clster), al llegar la peticin al nodo de
balance este redireccionar dicha peticin a uno de los servidores reales
mediante al algoritmo de balanceo de carga establecido. El servidor real
que atiende dicha peticin tiene como origen de la misma al nodo de
balanceo y no al usuario debido al mtodo de direccionamiento
empleado y su respuesta va dirigida a ste nodo. Una vez el nodo de
balanceo recibe la respuesta del servidor real solicitado, la enva al
usuario que la solicit teniendo como su direccin la IP virtual del clster
y no la IP real del nodo de balanceo, esto es as porque al hacer el
cliente la peticin, se hace a la IP virtual del clster y es de esta misma
direccin de donde se obtiene la respuesta haciendo creer al usuario
que es atendido por un solo equipo y no por un clster. Tabla 5.1.
En caso de existir una falla en uno de los servidores reales el
balanceador verifica cul se encuentra brindando el servicio y lo
direccion hacia dicho servidor. Para el usuario esto es transparente ya
que no afecta el servicio simplemente se ve afectado el rendimiento pero
nunca en una prdida de servicio, sta se da cuando todos los nodos
servidores fallan.

70

Figura 5.1 Funcionamiento del Clster.

Se hace una peticin de pgina a la IP virtual del clster.

La peticin se enva al nodo de balanceo, ste mediante un
algoritmo enva la peticin al servidor real correspondiente.
El servidor real que recibe la peticin la procesa y enva el
resultado al nodo de balanceo.
El nodo de balanceo enva la respuesta a la peticin al cliente
indicando que la direccin IP del paquete que sale es la IP
virtual del clster y no la IP del nodo de balanceo.
El cliente recibe la respuesta a su peticin por parte de la IP
virtual del clster, el cliente en ningn momento se da cuenta
que es atendido por un clster.
Tabla 5.1 Funcionamiento del Clster.

71

5.1.1 SELECCIN DE NODOS PARA EL CLSTER

Para la seleccin de los nodos que conforman el clster es importante
hacer notar que aquellos destinados a tomar la funcin de nodos de
balanceo no necesariamente sern los de mayores prestaciones (con
mayores recursos), con esto en mente se proceder a listar los
componentes primordiales para dicha eleccin. Primero los nodos que
actuarn como nodos de balanceo tendrn, como mnimo, que cubrir lo
siguiente mostrado en la tabla 5.2:
Procesador Pentium MMX a 166Mhz.
Memoria RAM de 64MB.
Unidad de Disco duro de 2GB.
Tarjeta de Red Ethernet.
Unidad de CDROM 8X (solo para instalacin).

Tabla 5.2 Especificaciones del nodo de balanceo.

En lo concerniente a los nodos que funcionan como servidores web,

estos debern contar con una mayor capacidad que los nodos de
balanceo pues son estos los que realizan el verdadero trabajo de
atencin a usuarios. Los requisitos mnimos aqu pueden variar
dependiendo de la complejidad de los servicios web; un punto medio es
la siguiente lista de requisitos mostrada en la tabla 5.3:

Procesador Pentium II 233Mhz.

Memoria RAM de 128MB.
Unidad de Disco duro de 4GB.
Tarjeta de Red Fast Ethernet.
Unidad de CDROM 8X (solo para instalacin).

72

Tabla 5.3 Especificaciones de nodo servidor.

A continuacin la tabla 5.4 indica las herramientas utilizadas para los

nodos de balanceo, nodos servidores y los nodos clientes.

Tipo de Nodo

Herramientas Utilizadas
Sistema Operativo (Windows, etc.)
Navegador Web.

Cliente

Sistema Operativo GNU/Linux CentOs 5.3.

Aplicaciones IPROUTE, IPTABLES, TCPDUMP
[Tcpdump].
Balanceo de

Editor de textos VIM.

Carga
Sistema Operativo GNU/Linux CentOs 5.3.
Aplicaciones IPROUTE, IP RULE e IPTABLES.
Editor de textos VIM.
Servidor Real

Servidor de pginas web Apache2.

Tabla 5.4 Herramientas utilizadas en cada nodo.

Herramienta.

Caractersticas.

Caractersticas Principales.

Balanceo de carga.
Escalabilidad.
Bajo consumo de recursos.

Suite

Diversos esquemas de

Balanceo de carga.

configuracin.

Alta disponibilidad.

73

Ultramonkey

Manejo de diversos protocolos

Escalabilidad.

como HTTP, FTP, etc.

Crear y editar archivos de texto.
Manejo de pestaas para mltiples
documentos.

Editor de textos
VIM.

Uso de nmeros de lnea.

Crear y editar archivos

Bsqueda de patrones dentro del

de texto.

documento.

Uso de nmeros de

Ejecucin de comandos sin salir

lnea.

del editor.

Bsqueda de patrones
dentro del documento.

Soporte de lenguajes de
programacin mediante mdulos.
Soporte para HTTPS.
Servidor de

Soporte para SSL (Secure Socket

Pginas web

Layer) mediante mdulo.

Apache2.

Permite crear host virtuales.

Amplia gama de configuraciones.

Soporte de mdulos
para lenguajes y otras
aplicaciones.
Soporte de SSL.
Creacin de host
virtuales.

Calidad de servicio.
Mantenimiento de varias tablas de
ruteo.
Aplicacin

Balanceo de carga.

IPROUTE.

Definicin de tneles.

Balanceo de carga.
Mantenimiento de varias
tablas de ruteo.

Permite interceptar y manejar

paquetes de red.
Permite el manejo de paquetes en

Aplicacin

diferentes estados del

Intercepcin y manejo

procesamiento.

de paquetes de red.

Permite construir firewalls basados

Construccin de

en GNU/Linux.

firewalls basados en

74

IPTABLES.

Realiza traduccin de direcciones

GNU/Linux.

(NAT).

Traduccin de
direcciones (NAT).

Permite depurar aplicaciones que

utilizan la red para comunicar.
Permite depurar la red misma.
Aplicacin

Permite capturar y leer datos

Permite capturar y leer

TCPDUMP.

enviados por otros usuarios o

datos enviados por otros

computadoras.

usuarios o
computadoras.

Tabla 5.5 Caractersticas de herramientas utilizadas.

5.1.2 Instalacin de los nodos

Antes de iniciar, es necesario revisar la tabla 5.4 donde se indican las
herramientas necesarias a instalar en cada nodo, la instalacin se
llevar a cabo en dos partes, la primera comprende la instalacin del
sistema operativo tanto en nodos de balanceo como en nodos servidores
y la segunda parte comprende la instalacin del software para el
balanceo de carga.
En cuanto a la primer parte que comprende la instalacin del sistema
operativo, se debe tomar en cuenta que se realiza con un entorno
grfico, por tanto se proceder conforme a la tabla 5.6.

Proceso de instalacin del Sistema Operativo.

Creacin de mquina virtual en VMware

Seleccin de medio de instalacin.

Proceso de instalacin del sistema base.

Instalacin de paquetes adicionales.

Tabla 5.6 Proceso de instalacin del Sistema Operativo.

75

El primer punto a cubrir nos brinda una variedad de medios de

instalacin como pueden ser los listados en la tabla 5.7.

Medios de Instalacin.

DVDROM bsico para instalacin mediante red.

DVD del juego de la distribucin.

Juego completo de discos de la distribucin.

Archivo ISO guardado en el disco de la mquina virtual

Tabla 5.7 Medios de instalacin.

Es importante contar con una conexin a Internet para hacer las

actualizaciones pertinentes y facilitar la instalacin de la herramienta de
balanceo de carga.
El segundo punto, la instalacin del sistema base cuyo proceso se cubre
en la tabla 5.8 a continuacin:

Aspecto.

Descripcin.
Debe especificarse a qu zona horaria pertenece el

Zona Horaria.

servidor seleccionando el pas/estado/ciudad en

donde se ubica el servidor y esto ajustar el reloj del
sistema sin necesidad de saber la franja horaria.

Contrasea de

Simplemente se pedirn las contraseas para la

administrador y

cuenta de administrador y la(s) cuenta(s) de los

usuario(s).

usuarios comunes que utilizarn el sistema.

Muestra las opciones de configuracin automtica
mediante el protocolo DHCP; de forma manual en la

76

cual se proporcionan datos como la direccin IP y la

Configuracin de la
red.

puerta de enlace y por ltimo permite dejar de

momento sin configuracin la interfaz de red.

Aqu se marcarn aquellos servicios que sean

Seleccin de
aplicaciones.

necesarios de los presentes en la lista mostrada, si

alguno no se encuentra en dicha lista, posteriormente
se podr instalar. Algunos de estos servicios son
bases de datos y servidores web.

Tabla 5.8 Proceso de instalacin del sistema base.

El resto del proceso de instalacin y detalles relacionados se cubren en

el anexo 1 (Instalacin del sistema operativo en maquinas virtuales). La
tabla 5.9 a continuacin muestra los servicios que se debern activar en
los nodos servidores.

Servidor de pginas web Apache.

Editor de textos VIM.

Aplicaciones IPROUTE e IPTABLES.

Tabla 5.9 Servicios activados en los nodos servidores.

5.1.3. Configuracin de los servidores web

Los servidores reales deben ser configurados para ejecutar el servicio
web provisto por el clster usando como aplicacin para tal efecto un
software como Apache.
Cuando se trabaja con servidores web es altamente recomendable hacer
uso de direcciones IP estticas y para ello se debe editar la
configuracin del dispositivo de red; para mayor detalle debe consultarse
el Anexo 2, sobre el manejo de la interfaz de red.
Se deben configurar los servidores reales para que acepten peticiones
en la direccin IP virtual dado que estos no responden al cliente de

77

manera directa (ver figura 5.1). Para ello el servidor real deber contar
con la aplicacin iproute (sta aplicacin se compone de un conjunto de
herramientas muy potentes para administrar interfaces de red y
conexiones en sistemas GNU/Linux).
Las caractersticas que brinda esta configuracin de balanceo de carga
(ver figura 5.2) en primera instancia son brindar un equilibrio de la carga
de trabajo en cuanto a las conexiones que puede atender cada servidor
real haciendo posible, dependiendo del algoritmo de balanceo, el asignar
ms trabajo a un servidor con mayor capacidad que otro, repartir el total
de conexiones si todos los servidores son iguales en caractersticas para
no saturar ninguno y poder atender de manera eficiente al usuario final.
Despus permite que al incorporarse nuevos nodos servidores con
mayores prestaciones estos sean quienes atiendan las peticiones con
mayores prioridades y consumo de recursos dejando al resto libre para
atender a otros usuarios finales. Las aplicaciones IPROUTE e
IPTABLES son necesarios de configurar, pues las configuraciones que
posee por defecto al instalarse no son suficientes.
En lo que respecta a la alta disponibilidad cabe sealar que esta se
brinda mediante la redundancia de nodos de balanceo pues es aqu
donde reside el balanceo de la carga ya que tales nodos son los
encargados de distribuir las conexiones. Esta alta disponibilidad requiere
que no solo exista la redundancia en los nodos de balanceo sino
tambin cierto grado en los servidores reales pues aunque con solo un
servidor real se puede todava brindar el servicio, en realidad no existe
ningn balanceo de esta manera, siendo primordial la existencia de por
lo menos dos nodos para tal efecto.
Como las conexiones son redirigidas a los servidores reales usando NAT
es importante que la ruta de regreso para tales conexiones sea a travs
del nodo de balanceo. Esto es as porque NAT puede revertir el proceso,
de otra forma el paquete de retorno que es recibido por el usuario final
ser del servidor real y no del nodo de balanceo y por lo tanto la
conexin ser abandonada.

78

Figura 5.2. Configuracin final de nodos.

5.2. Instalacin de CentOs

Para la instalacin del sistema operativo utilizado (CentOs 5.3), es
necesario tener el dvd con la distribucin respectiva, para el caso de
este proyecto se utiliz el archivo ISO de la distribucin el mismo que se
lo tiene guardado en un directorio del equipo principal. Cabe sealar que
se utiliz en software de virtualizacin VMware Workstation en la versin
6.0.0. Este proceso se lo realiz para todos los servidores utilizados en
el proyecto.
El proceso de instalacin del sistema operativo CentOs se encuentra
detallado en el Anexo 1 Instalacin de CentOs.

5.3. Instalacin de Ultramonkey

En cuanto a los medios de instalacin de Ultramonkey, los podemos
encontrar en forma de paquetes de cdigo fuente, paquetes pre-

79

compilados que se pueden descargar desde la pgina web del proyecto

y tambin en el repositorio siguiente:

http://www.ultramonkey.org/download/3/

La manera ms sencilla de llevar a cabo la instalacin ejecutar como

superusuario el comando yum install para instalar la lista de paquetes
disponibles. Este mtodo es el que se utilizar para su instalacin.
Si no se cuenta con una conexin a Internet en el momento de instalar
los paquetes que se proveen, se puede optar por descargar en otro
equipo con acceso a Internet los paquetes que conforma la herramienta
desde la pgina del proyecto, en este caso se entrara a la seccin de
descargas y se especifica que los paquetes a descargar son para la
distribucin GNU/Linux Redhat (cabe sealar que CentOs es la versin
liberada de Redhat Enterprise, por esta razn su usan los paquetes
disponibles para Redhat).
Por ltimo se puede optar por adquirir los paquetes en formato de cdigo
fuente comprimidos, una vez descargados se proceder a copiarlos en la
estacin donde se necesiten y se llevar a cabo todo el proceso de
compilacin e instalacin.
Como se puede apreciar, existen mtodos de instalacin para casi todas
las distribuciones o preferencias; la mejor forma es mediante los
repositorios, pero si se desea conservar un respaldo de dichos paquetes
se sugiere su descarga y posterior respaldo en medios como discos
compactos o en un servidor de respaldos.

5.3.1. Seleccin de topologa de instalacin de ultamonkey

Aqu se determina como instalar la solucin de alta disponibilidad y
balanceo de carga que provee Ultramonkey de acuerdo a un esquema
determinado, posteriormente se detallar el proceso de instalacin.
Como muestra la figura 5.2. Configuracin final de nodos, la red est
compuesta por 3 computadoras unidas mediante un router. Las
direcciones IP 192.168.1.20 y 192.168.22.2 estn asignadas al nodo
director del clster y las direcciones IP 192.168.22.4 y 192.168.22.5 a los

80

servidores reales. La VIP (direccin IP

192.168.1.20.

virtual) del clster es

Esta topologa permite el mximo rendimiento (en cuanto a tasa de

transferencia) a travs de la red, ya que el trfico de retorno ya no tiene
que viajar a travs de un nodo de balanceo.

5.3.1.1. Directores Linux o Nodos de balanceo

En cualquier momento uno de los nodos directores est activo, mientras
el otro est en una espera atenta. El nodo de balanceo activo acepta el
trfico desde una IP virtual. sta es la IP que es anunciada a los
usuarios finales. La carga de conexiones es balanceada hacia uno de los
servidores reales usando LVS.
Los dos nodos de balanceo se monitorean el uno al otro usando
Heartbeat y en el evento de que el nodo de balanceo activo falle, el que
est en espera asume la direccin virtual y el servicio se mantiene. Las
conexiones son sincronizadas entre el nodo de balanceo activo y los que
estn en espera, de tal forma que cuando una falla ocurre las
conexiones existentes pueden continuar.
Cuando un nodo de balanceo recibe una conexin desde un usuario
final, ste toma la decisin acerca de a cul nodo servidor enviar la
conexin. Todos los paquetes del tiempo de vida de esta conexin son
enviados al mismo servidor real de tal forma que la integridad de la
conexin entre el usuario final y el servidor real se mantiene.
El director monitorea la salud o estado de los servidores reales, por
medio de consultas peridicas de una pgina conocida y verificando que
la respuesta contenga una cadena esperada. Si el servidor real falla,
entonces el servidor es sacado del pool (los servidores reales
seleccionables) de los servidores reales y se reinserta una vez que
vuelve a estar en lnea.
Como el nodo de balanceo no es el router de entrada para los servidores
reales, el trfico no tiene que viajar a travs del nodo de balanceo en el
retorno si es que se usa ruteo directo o tunneling. Esto permite un
mayor rendimiento (tasa de transferencia) ya que el nodo de balanceo
no tiene que manejar los paquetes de retorno. Puede ser posible enviar
trfico de retorno a travs de diferentes routers y/o switch cuando la
conectividad externa lo permita.

81

5.3.1.2. Nodos servidores o servidores reales

Los servidores reales pueden ejecutar una variedad de servicios
incluyendo el servidor web HTTP Apache. Ms servidores reales pueden
ser aadidos a la red si se requiere capacidad extra dado que este
esquema permite escalabilidad.

5.4. Configuracin de Heartbeat en los nodos de balanceo

Ultramonkey viene con paquetes adicionales. Estos paquetes slo son
requeridos para los nodos de balanceo que van a ejecutar Heartbeat.
Pueden ser obtenidos usando el comando yum:
yum install ultramonkey
Otra alternativa para obtener los paquetes es desde el directorio de
descargas en la pgina: http://www.ultramonkey.org/download/3/
El proceso de instalacin de toda la solucin se encuentra documentado
en el Anexo 2 Instalacin de la solucin.

5.5. Configuracin de la red de trabajo

Como muestra la figura 5.1, la red est compuesta por 4 computadoras
unidas mediante un switch. Las direcciones IP 192.168.1.20 y
192.168.22.2 estn asignadas a al nodo director del clster (nodo de
balanceo) y las direcciones IP 192.168.22.4 y 192.168.22.5 a los nodos
servidores A y B). La VIP del clster LVS es 192.168.1.20.
Para editar la configuracin de un dispositivo de red usamos las
herramientas administrativas para esto: system-config-network.
Despus de los cambios en el archivo es necesario reiniciar los servicios
de red para que estos surtan efecto mediante el comando service
network restart.

82

5.6. Configuracin del clster

5.6.1. Directores Linux, nodos de balanceo
Los directores deben estar habilitados para enrutar el trfico hacia los
servidores reales. Especficamente, se debe habilitar el seguimiento
IPv4. Esto se hace mediante el comando:
echo 1 > /proc/sys/net/ipv4/ip_forward
Para que los cambios tengan efecto se debe usar el comando sysctl:
sysctl p
Configuramos el componente IPVS de ultramonkey para designar la
direccin IP virtual y los servidores reales, adems indicamos que se lo
realizar mediante NAT y con el algoritmo round robin.
ipvsadm -A -t 192.168.1.20:80 -s rr
ipvsadm -a -t 192.168.1.20:80 -r 192.168.22.4:80 -m -w1
ipvsadm -a -t 192.168.1.20:80 -r 192.168.22.5:80 -m -w1

5.6.2. Heartbeat
Para configurar el Heartbeat, deben estar instalados los archivos
/etc/ha.d/ha.cf, /etc/ha.d/haresources y /etc/ha.d/authkeys.
Para visualizar el archivo /etc/ha.d/ha.cf se debe ejecutar el siguiente
comando:
vim /etc/ha.d/ha.cf
El monitoreo de los servidores reales y su insercin y eliminacin del
conjunto de servidores disponibles es controlado por ldirectord, el cual
es ejecutado por Heartbeat. Para configurar ldirectord, el archivo
/etc/ha.d/ldirectord.cf debe estar instalado.

83

vim /etc/ha.d/ldirectord.cf
Al recibir una peticin de conexin desde un cliente, el nodo de balanceo
asigna un servidor real al cliente basado en un algoritmo. El tipo del
algoritmo se define en este archivo. Algunos de los algoritmos
disponibles son:
RR, WRR: round robin, weighted round robin (con manejo de pesos).
LC, WLC: least connection (menos conexiones), weighted least
connection (el director tiene una tabla con el nmero de conexiones para
cada servidor real).
Los algoritmos RR, WRR, LC y WLC deberan todos funcionar de forma
similar cuando el nodo de balanceo est dirigiendo servidores reales
idnticos con servicios idnticos. El algoritmo LC ser mejor manejando
situaciones donde las mquinas son dadas de baja y activadas
nuevamente. Si los servidores reales estn ofreciendo diferentes
servicios y algunos tienen usuarios conectados por un largo tiempo
mientras otros estn conectados por un corto periodo, entonces ninguno
de los algoritmos va a hacer un buen trabajo distribuyendo la carga entre
los servidores reales.
Como el clster a implementar posee servidores reales idnticos con
servicios idnticos, se opt por implementarlo con un algoritmo RR
(round robin).

5.7. Instalar y configurar IPROUTE en los nodos servidores

Finalmente debemos configurar los nodos servidores 1 y 2 para que
acepten peticiones de la IP 192.168.22.2. En los nodos 1 y 2
ejecutamos:
ip route add default via 192.168.22.2 table 1
ip rule add fwmark 80 table 1
Es necesario utilizar firewall iptables para marcar todo el trfico http, y
luego la ruta es a travs de una tabla de rutas alternativas.
iptables -t mangle -I PREROUTING -p tcp --dport 80 -j MARK --set-mark
80
Aceptar conexiones web en los servidores por el puerto 80 y la interface
de red eth1.

84

iptables -A INPUT i eth1 -p tcp --dport 80 -j ACCEPT

Guardamos la configuracin de las reglas iptables.
service iptables save
Configuramos que el servicio de iptables en los nodos servidores este
corriendo y se active en el inicio:
chkconfig iptables on
Iniciamos el servicio iptables
service iptables start
Configuramos para que el servicio http en los nodos servidores este
corriendo y se active en el inicio, con el comando:
chkconfig httpd on
Iniciamos el servicio http
service httpd start
Asegurarse que los servidores reales (192.168.22.4 y 192.168.22.5)
reenven los paquetes a travs del linux director (192.168.22.2), es decir,
los servidores reales deben tener como default gw a linux director.
Encontrar toda la documentacin acerca de la instalacin en el Anexo 2.

5.8. Pruebas de desempeo

Los servidores reales poseen una pgina web alojada en /var/www/html/
la misma que simplemente es informativa y nos indica que servidor es el
que est mostrando la pgina as (servidor 1, servidor 2). Ver figuras 5.3
y 5.4 respectivamente.

85

El cliente realiza una peticin al servidor director mediante la direccin IP

Virtual del mismo 192.168.1.20 (www.tesismg.com), el servidor director
realiza el balanceo y redirecciona la peticin al servidor real disponible,
si realizamos nuevamente una peticin veremos que ahora es el otro
servidor el que est mostrando su pgina.

Figura 5.3. Pgina del servidor 1

86

Figura 5.4. Pgina del servidor 2

Simulamos una cada del servidor 1 deteniendo el servicio http asi:

service httpd stop

Figura 5.5. Detencin del servicio httpd

Observamos que ahora el balanceador muestra solamente la pgina del

servidor 2 en todas las peticiones.

5.8.1. Herramientas para medicin de rendimiento

5.8.1.1. Seleccin de una herramienta para medicin de rendimiento
Existen varias herramientas para comprobar el correcto funcionamiento
del clster entre todas estas se ha decidido utilizar ipvmsad, tcpdump,
tomando en cuenta que ipvsadm en el administrador de LVS
componente de ultramonkey usado en la implementacin.

87

Ipvsadm
Ipvsadm se utiliza para establecer, mantener o inspeccionar la tabla del
servidor virtual en el kernel de Linux. El Servidor Virtual Linux puede ser
utilizado para construir los servicios de red escalable basada en un conjunto
de dos o ms nodos. El nodo activo del clster redirecciona las peticiones
de servicio a un nodo del clster, un servidor que va a entregar los
servicios. Entre sus caractersticas soportadas incluyen dos protocolos
(TCP y UDP), tres mtodos de reenvo de paquetes (NAT, tneles, y el
encaminamiento directo), y ocho algoritmos de balanceo.
El comando tiene dos formatos bsicos para la ejecucin:
ipvsadm COMMAND [protocol] service-address
[scheduling-method] [persistence options]
ipvsadm command [protocol] service-address
server-address [packet-forwarding-method]
[weight options]

El primer formato manipula un servicio virtual y el algoritmo para la

asignacin de las solicitudes de servicio a los servidores reales. De manera
opcional, un tiempo de espera persistentes y la mscara de red para la
granularidad de un servicio persistente puede ser especificado. El segundo
formato manipula un servidor real que est asociado con un servicio virtual
existente. Cuando se especifica un servidor real, el mtodo de reenvo de
paquetes y el peso del servidor real, en comparacin con otros servidores
reales para el servicio virtual, se puede especificar, de lo contrario se usar
por defecto.
Ejemplos:
Ipvsamd -l
Lista la tabla del servidor virtual, las conexiones activas e inactivas
existentes en el servidor.
Ipvsamd lnc
Lista las conexiones entrantes, el estado de la conexin, el origen y el
destino de la conexin.

88

Tcpdump
Tcpdump es una excelente herramienta que nos permite monitorear a
travs de la consola de Linux todos los paquetes que atraviesen una
interfaz indicada. A su vez, los mltiples filtros, parmetros y opciones que
tcpdump nos ofrece, nos permite infinidades de combinaciones, al punto de
poder monitorear todo el trfico completo que pase por la interfaz, como el
trfico que ingrese de una ip, un host o una pgina especfica, podemos
solicitar el trfico de un puerto especfico o pedirle a la herramienta que nos
muestre todos los paquetes cuyo destino sea una direccin MAC especfica.
Ejemplos:
tcpdump i eth0 port 80
Muestra todo el trfico por la interface de red eth0 y el puerto 80.
De las pruebas obtenidas con estas herramientas podemos verificar el
estado de los servidores asi:

Figura 5.6. Verificacin de servidores y conexiones con ipvsadm l.

89

Figura 5.7. Verificacin de servidores y conexiones con ipvsadm lnc.

Figura 5.8. Trfico en la red con tcpdump.

90

Figura 5.9. Salida de trfico en la red con tcpdump.

91

CONCLUSIONES
Una vez instalado todo el conjunto de paquetes necesario, (paquetes RPM, tipo
de paquete utilizado en distribuciones Centos), la configuracin resulta sencilla
y solo se tienen que ejecutar comandos para especificar el algoritmo a utilizar
para el balanceo de carga, datos sobre los servidores reales y nodos de
balanceo como tambin los servicios que proporcionan y las pginas para
control esperadas (servicio en este caso particular de pginas web o HTTP
solamente).
Para las pruebas de funcionamiento se utiliz configuraciones generales del
clster que incluye los nodos de balanceo, los algoritmos para balanceo de
carga, instalacin y configuracin del servidor de pginas web Apache, pruebas
simples para nodos de balanceo e instalacin y configuracin del paquete
iproute en los nodos servidores.
Sobre las pruebas realizadas, estas me ofrecen un panorama muy general,
puesto que la mayora de ellas son bien controladas y se esperan ciertos
resultados, la mejor parte de las pruebas se pudo explorar esos aspectos no
previstos e investigar el comportamiento del clster en dichos casos; en las
pruebas llevadas a cabo se contaba con un cliente con un sistema operativo
distinto al utilizado para la construccin del clster (recurdese que el cliente
solamente necesita un navegador web) el cual realiza las peticiones de la
pgina web principal alojada en el clster, de esta manera se pudo observar
cual servidor real es el que atiende la peticin (en un sistema en produccin
esto no deber ser as ya que la intencin es que los usuarios vean al sitio web
como un solo equipo). La pgina web solicitada en las pruebas solamente
contiene una cadena indicando a que nodo servidor real pertenece. Es
importante aclarar que debido a las caractersticas de los nodos de balanceo
empleados, estos no pueden procesar miles de peticiones sin embargo las
pruebas realizadas demuestran que son suficientemente competentes para el

92

manejo de un sitio de dimensiones bajas a medias como lo son las pequeas

empresas.
En el transcurso de las pruebas se observ que existan problemas no
previstos en la elaboracin del proyecto como la seguridad que debe
mantenerse en los servidores lo cual fue solventado denegando la aceptacin
de paquetes y puertos por parte de los nodos servidores.
Al final del proyecto se concluye que la solucin desarrollada es aplicable en
pequeas empresas tomando en cuenta el correcto funcionamiento, la fcil
instalacin y mantenimiento del sistema adems que, por tratarse de open
source las empresas no incurre en gastos por licenciamiento.

BIBLIOGRAFIA

2007, Jos Angel de Bustos Prez, GNU/Linux, software libre para la

comunidad universitaria, 2007.
Septiembre 2001, Vicente Jos Aguilar Rosell, Clustering de Alta
Disponibilidad bajo GNU/Linux, septiembre 2001
2005, Rosa Mara Ynez Gmez, Introduccin a las tecnologas de
clustering en GNU/Linux, 2005.
30 de diciembre de 2003, Emilio Jos Plaza Nieto, Cluster Heterogneo
de computadoras, 30 de diciembre de 2003.
Edicin junio 2010, Joel Barrios Dueas, Implementacin de Servidores
con GNU/Linux, 26 de junio 2010.
2007, Red Hat, Inc., Linux Clustering Building and Maintaining Linux
Clusters, 2007
2004, Federico Esteban Pereda, Mini-Howto Servidores de Alta
Disponibilidad (heartbeat + drbd), 2004.
Junio 30, 2007, Tom Adestein, Bill Lubanovic, Administracin de
sistemas Linux, junio 30, 2007, Anaya Multimedia
2005, Charles Bookman, Clustering con Linux, 2005, Pearson Educacin
2007, Jos Angel de Bustos Prez, GNU/Linux, software libre para la
comunidad universitaria, 2007.
Septiembre 2001, Vicente Jos Aguilar Rosell, Clustering de Alta
Disponibilidad bajo GNU/Linux, septiembre 2001
http://www.codigolibre.org/index.php?option=com_content&view=article&
id=5389:clustering&catid=36:gnu-cat&Itemid=53
http://www.jumpingbean.co.za/linux-cluster-load-balancing-highavailability
http://crysol.org/node/339
http://www.taringa.net/posts/linux/8289874/Monitoreo-de-trafico-en-red_tcpdump.html

http://linuxmanpages.com/man8/ipvsadm.8.php
http://bulma.net/body.phtml?nIdNoticia=1615&nIdPage=3
http://www.adslfaqs.com.ar/que-es-nat-network-address-translation/
http://wiki.itlinux.cl/doku.php?id=cluster:ultramonkey-lbs
http://mmc.geofisica.unam.mx/LuCAS/Manuales-LuCAS/doc-cursosalamanca-clustering/html/ch03s04.html
http://www.wikilearning.com/tutorial/el_manual_para_el_clustering_con_
openmosix-clusters_ha_ii/9756-15
http://www.estrellateyarde.org/discover/cluster-ultramonkey-en-linux
http://www.tcpdump.com/
http://linuxmanpages.com/man8/ipvsadm.8.php
http://www.ultramonkey.org
http://www.centos.org