UNIVERSIDAD NACIONAL

PEDRO RUIZ GALLO

FACULTAD DE INGENIERA CIVIL, SISTEMAS Y DE

ARQUITECTURA
ESCUELA PROFESIONAL DE INGENIERA DE
SISTEMAS

INFORME DE INGENIERIA PARA OPTAR EL

TTULO PROFESIONAL DE INGENIERO DE
SISTEMAS POR LA MODALIDAD DE
ACTUALIZACIN DE CONOCIMIENTOS

Diseo
Diseo dede un
un Servidor
Servidor Web
Web con
con un
un
Cluster
Clusterde
deAlta
AltaDisponibilidad
DisponibilidadyyBalanceo
Balanceo
de
de Carga en Linux para el Colegio de
Carga en Linux para el Colegio de
Ingenieros
Ingenieros del
del Per
Per Consejo
Consejo
Departamental
Departamentalde deLambayeque
Lambayeque- -2011
2011
AUTOR
Bach. Rolly Seward Villegas Delgado

ASESOR
Ing. Robert Puican Gutirrez

LAMBAYEQUE PER
Julio, 2011
INTRODUCCIN

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 mquinas, 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 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 I: GENERALIDADES DEL PROYECTO

1. DESCRIPCIN DEL CIP CD LAMBAYEQUE

1.1. Breve Resea Histrica

Consejo Departamental de Lambayeque, antes filial Lambayeque,
tiene como antecedente de su formacin a la Sociedad del Hogar del
Ingeniero fundada el 27 de Octubre de 1948.
Aquella sociedad era integrada por las esposas de los Ingenieros de
aquel entonces, siendo su primera presidenta la Sra. Otilia Mesones
de Carrera. Esta base que funcionaba en el local del Hotel Royal de
nuestra Ciudad permitira ms tarde la formacin de la Sociedad de
Ingenieros el 14 de Mayo de 1954 bajo la presidencia del Ing. Jos
Carrera Cordiano.
El 20 de Agosto de 1966 con una Asamblea de ms de 60 ingenieros,
entre Agrnomos y Civiles, se crea la Filial Lambayeque del Colegio de
Ingenieros del Per. La filial tuvo como primer Decano al Ing. Germn
Paz Coopn y su sede funcionaba en el cuarto piso del Edificio Atlas.
En 1987 se producen cambios en el Estatuto del Colegio de Ingenieros
del Per, reemplazndose el trmino Filial por Consejo Departamental
de Lambayeque. Adems se estableci un perodo de dos aos para
cada gestin de Decanato.
Desde el inicio de nuestro Consejo Departamental (1966) hasta la
fecha, 19 Decanos estuvieron al frente de nuestra Orden.

1.2. Misin
Somos una institucin deontolgico, sin fines de lucro, que
representa y agrupa a los ingenieros profesionales del Per, de
todas las especialidades, que cautela y preserva el comportamiento
tico de sus miembros, y debe asegurar al Per que cuenta con una
profesin nacional que ejerce la ingeniera en un contexto de orden,
respeto, competitividad, calidad y tica, y que est enraizada en sus
valores sociales, culturales y polticos, como base fundamental en el
proceso de desarrollo de la nacin.

1.3. Visin
 Ser reconocida como una institucin slida, que patrocina el manejo
eficiente del conocimiento, con la finalidad de orientar a la sociedad
peruana en las grandes decisiones, fomentando la prctica de
valores y comportamiento tico de los ingenieros profesionales, as
como elevando la calidad de la ingeniera, apoyando el crecimiento
del pas en el contexto de la globalizacin.

1.4. Ubicacin
El Colegio de Ingenieros del Per Consejo Departamental de
Lambayeque est ubicado en la Av. Balta N 581 - Chiclayo

1.5. Naturaleza
Es una institucin autnoma con personera jurdica de derecho
pblico interno, representativa de la profesin de la ingeniera en el
Per, integrado por los profesionales de las distintas especialidades
de la ingeniera creadas o por crease, graduados en universidades
oficialmente autorizadas para otorgar nombre de la Nacin en el
ttulo de ingeniero.

1.6. Organizacin
2. DESCRIPCIN DE PROBLEMA

2.1. Situacin Problemtica

El Colegio de Ingenieros del Per Consejo Departamental de
Lambayeque, actualmente cuenta con el servicio de Hosting
Compartido, en este tipo de servicio se alojan clientes de
varios sitios en un mismo servidor.

El Hosting Compartido es una alternativa muy buena para pequeos y

medianos clientes, es un servicio econmico debido a la reduccin de
costos ya que se comparte un servidor con cientos miles o millones.

Entre las desventajas de este tipo de hospedaje web hay que

mencionar sobre todo el hecho de que compartir los recursos
de hardware de un servidor entre cientos o miles de usuarios
disminuye notablemente el desempeo del mismo. Es muy usual
tambin que las fallas ocasionadas por un usuario repercutan en los
dems por lo que el administrador del servidor debe tener suma
cautela al asignar permisos de ejecucin y escritura a los usuarios.

En resumen las desventajas son: disminucin de los recursos del

servidor, de velocidad, de desempeo, y principalmente de seguridad
y de estabilidad.

Los costos econmicos para contar con una gran computadora

(Mainframes) que entregue un servicio como el que se necesita en
este caso, son bastantes elevados si se les compara con los costos
que implica la implementacin de Cluster.

2.2. Justificacin e Importancia del Proyecto

Para implementar un servidor Web eficiente que funcione 24x7x365
das del ao, se necesita considerar varios puntos importantes como:
computadoras con buenas caractersticas, un lugar adecuado donde
se deben instalarse las computadoras, una unidad de respaldo de
energa, y personal idneo para el mantenimiento del servidor.
 Esto nos lleva a pensar que tan caro es poner un servidor y si
realmente es justificable la inversin inicial, porque debemos de
comprar una computadora con las ltimas caractersticas como: son
la velocidad de respuesta, almacenamiento primario, capacidad de
presentar informacin en pantalla, entre otras cosas.
Pero esto ya no es problema con la tecnologa llamada clustering que
implica construir un servidor con equipo homogneo y no homogneo
que cumpla con las mismas funciones que una sola maquina. El
equipo homogneo y no homogneo puede ser de diferentes
caractersticas.

Es importante reconocer que uno de los medios de comunicacin con

gran cantidad de informacin, fcil acceso y econmico es el Internet,
el cual permite mostrar informacin de una manera rpida y
actualizada.

2.3. Objetivos del Proyecto

Objetivo General
Disear un Cluster de Alta Disponibilidad que permita el
Balanceo de Cargas en los servidores web.

Objetivos Especficos
Definir que es un Cluster
Investigar las diferentes clases de Cluster existentes.
Seleccionar un Tipo de Cluster
Seleccionar la plataforma tecnolgica para la implementacin
Proponer un diseo para la implementacin de una arquitectura
de Clster de Software, que contenga la documentacin
necesaria para ser considerada como una alternativa de
solucin; sobre balanceo de carga y alta disponibilidad
Definir los requerimientos de hardware y software necesarios
para la implementacin de arquitecturas basadas en Clster
sobre balanceo de carga y alta disponibilidad
Demostrar que se puede construir un Clster de software
utilizando un mnimo presupuesto por medio de la utilizacin
del equipo existente y software libre que han sido diseados
para trabajar en ambientes de Clster.
 CAPITULO II: MARCO TERICO

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.

2.1. CLUSTERING
2.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.2.Qu es Clustering?
Los clusters de equipos vienen siendo utilizados por ms de
diez aos. G. Pfister uno de los pioneros de la Tecnologa de
conglomerados mencion que un Cluster es: " un sistema
paralelo o distribuido que consta de una coleccin de equipos
 completos conectados entre s que se utiliza como un recurso
de equipos nico y unificado" 1

Clustering es un conjunto de mquinas, 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.

1
Para mayor informacin recurrir al texto In Search of Clusters, Gregory F. Pfister, Prentice-
Hall,1998. Visitar sitio Web: http://www.microsoft.com/latam/technet/articulos/windows2k/clustsrv/.
 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.3.Tipos de Cluster
Dependiendo del tipo de solucin que busquemos podemos
clasificar los clusters en varios tipos:
High Performance
High Availability
Load Balancing

2.1.4.High Performance
TIPO DE CLSTER DESCRIPCIN
Conjunto de computadoras
diseado para brindar altas
Alto rendimiento
prestaciones en cuanto a
(High Performance)
capacidad de clculo.

Conjunto de dos o ms
computadoras que se
caracterizan por mantener una

Alta disponibilidad serie de servicios disponibles y

(High Availability) compartidos, se caracterizan
por estar constantemente
monitorizndose entre s.

Compuesto por una o ms

computadoras que actan
como interfaces primarias del

Balanceo de carga clster y se ocupan de repartir

(Load Balancing) 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 DESCRIPCIN
Es donde todos los nodos
Homogneo poseen una configuracin de
hardware y software iguales.
Es donde se poseen
arquitecturas y sistemas
Semi-Homogneo
operativos similares pero de
diferente rendimiento.
Es donde se poseen hardware
Heterogneo 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
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 del
clster siendo tan complejas
Conexiones de red
como lo sean las tecnologas y
medios utilizados en su
instalacin.
Aqu normalmente se cuenta con
Protocolos de el protocolo de comunicaciones
comunicacin y servicios TCP/IP y servicios de transporte
de datos.
Nodos Son simples computadoras o
sistemas multiprocesador; en
 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 de ellos
que estn destinados a gestionar
Sistema Operativo
de manera eficaz los recursos de
una computadora. Como ejemplo
se tiene Unix, Mac OSX.
Middleware Es un software que acta entre
el Sistema Operativo y las
aplicaciones con la finalidad de
proveer a un clster las
caractersticas de:

Interfaz nica de acceso al

sistema, denominada SSI (Single
System Image), la cual genera la
sensacin al usuario de que
utiliza un nico ordenador muy
potente.

Herramientas de optimizacin y
mantenimiento del sistema:
migracin de procesos,
checkpoint-restart (congelar uno
o varios procesos, mudarlos de
servidor y continuar su
funcionamiento en el nuevo
host), balanceo de carga,
tolerancia a fallos, etc.

Escalabilidad: debe poder

detectar automticamente
nuevos servidores conectados al
Cluster para proceder a su
 utilizacin.
Son todos aquellos programas
que se ejecutan sobre el
middleware; estos son diseados
Aplicaciones para su ejecucin en entornos de
cmputo paralelo o
aprovechamiento del tipo de
clster.
Tabla 2.3 Componentes de un Clster

2.1.5.Cluster Activo/Pasivo
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:
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.

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

2.1.6.Cluster Activo / Activo

Esta configuracin tiene dos actividades en los nodos que
componen el Cluster, los activos son aquellos que se encargan
de ejecutar las aplicaciones encomendadas, mientras que los
nodos restantes actan como respaldos redundantes para los
servicios ofrecidos.

2.1.7.Cluster Activo / Pasivo

En este caso, todos los nodos actan como servidores activos
de una o ms aplicaciones y potencialmente como respaldos
para las aplicaciones que se ejecutan en otros nodos. Cuando
un nodo falla las aplicaciones que se ejecutaba en l migran a
uno de los nodos de respaldo.

ELEMENTO DESCRIPCIN
Infraestructura de Consiste en componentes de software
alta que cooperan entre s para permitir que
disponibilidad. el clster parezca como un sistema
nico. Entre sus funciones se
encuentran:
Monitorizacin de nodos y
procesos.
 Control de acceso a recursos
compartidos.
Satisfaccin de requerimientos del
usuario.
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 que exporta ese nivel
para mantener en todo momento el
Servicios de alta
servicio. Usualmente existe una
disponibilidad.
degradacin del sistema cuando un nodo
falla pero no una interrupcin del
servicio.
Tabla 2.4 Estructura de Alta Disponibilidad

2.2. Arquitectura del Cluster

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

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

2
http://www.eurogaran.com/index.php/es/servidores-linux/clusteres/de-alta-disponibilidad
 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.

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).3

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 por qu 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.

3
http://www.seccperu.org/files/Clustering%20and%20Grid%20Computing.pdf
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 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, 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. 4

Figura 2.4 Alta disponibilidad

2.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:

4
http://www.redes-linux.com/manuales/cluster/clustering.pdf
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.

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.

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.3. Funcionamiento de un Cluster

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.3.1.Balanceo de Carga
Los balanceadores de carga permiten optimizar la utilizacin de
los recursos de un clster mediante la asignacin de tareas a
los 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.3.2.Sistemas para la deteccin de fallos en los nodos del
cluster
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.

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:

Heartbeat.
Disco de quorum.

2.3.3.Recursos del Cluster

Son todos aquellos recursos necesarios para el servicio:
IP de servicio.
Filesystems.
Scripts para arrancar el servicio
 Figura 2.6 Recursos del Clster

2.3.4.Servicios 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.
Servidores Proxy Cache

2.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.
 Figura 2.7 Balanceo de Carga

Adems, aun 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 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 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 y para mantener una gestin
segura, la comunicacin (hearbeat) entre mquinas y un sistema de
ficheros tolerante a fallos, respectivamente.

2.4.1.Balanceadores de 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.

2.4.2.Balanceadores de 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.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.
 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.
 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.5. Deteccin de fallos en los nodos del Cluster

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.5.1.Heartbeat
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.
 Figura 2.9 Heartbeat

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 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.5.2.Disco de qurum
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.
 Figura 2.10 Disco de Quorum

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.

2.6. Software Libre5

CONSERVAMOS ESTA DEFINICIN DE SOFTWARE LIBRE para expresar
claramente el verdadero significado de los programas de software libre.

El software libre es una cuestin de libertad, no de precio. Para

comprender este concepto, debemos pensar en la acepcin de libre
como en libertad de expresin y no como en barra libre de cerveza.

Con software libre nos referimos a la libertad de los usuarios para

ejecutar, copiar, distribuir, estudiar, modificar y mejorar el software.

Nos referimos especialmente a cuatro clases de libertad para los

usuarios de software:

Libertad 0: la libertad para ejecutar el programa sea cual sea

nuestro propsito.

5
Escrito originalmente en 1996, esta versin forma parte de Software libre para una sociedad
libre, editorial Traficantes de sueos, 2004 (http://www.traficantes.net, ISBN 84-933555-1-8.
 Libertad 1: la libertad para estudiar el funcionamiento del
programa y adaptarlo a tus necesidades el acceso al cdigo fuente
es condicin indispensable para esto.
Libertad 2: la libertad para redistribuir copias y ayudar as a tu
vecino.
Libertad 3: la libertad para mejorar el programa y luego
publicarlo para el bien de toda la comunidad el acceso al cdigo
fuente es condicin indispensable para esto.

Software libre es cualquier programa cuyos usuarios gocen de estas

libertades. De modo que deberas ser libre de redistribuir copias con o
sin modificaciones, de forma gratuita o cobrando por su distribucin, a
cualquiera y en cualquier lugar. Gozar de esta libertad significa, entre
otras cosas, no tener que pedir permiso ni pagar para ello.

Cuando hablamos de software libre, es preferible evitar expresiones

como regalar o gratis, porque entonces caeremos en el error de
interpretarlo como una mera cuestin de precio y no de libertad.

Trminos de uso frecuente como el de piratera encarnan opiniones La

definicin de software libre que esperamos no compartas

2.7. Servidores Linux

Qu es un servidor web?
Un servidor web es un programa de aplicacin que satisface las
solicitudes HTTP6 realizadas por los navegadores. Para ello, el ordenador
que la soporta debe estar conectado a la Internet y, por lo tanto, ha de
tener asignada una direccin IP.

6
HTTP .- HyperText Transfer Protocol .- Protocolo utilizado para la transferencia de contenido
web entre un servidor y un cliente web
 Figura 2.11 Servidor Web

Un servidor web debe soportar los protocolos estndar en la Internet. Por

ejemplo HTTP (protocolo de transferencia de hipertexto) que facilita el
intercambio de datos entre el servidor web y el navegador. Adems, para
publicar una pgina se suele utilizar un protocolo ms antiguo, el FTP
(Protocolo de transferencia de archivos).

Adicionalmente, deben ofrecer soporte a scripts y aplicaciones en los

lenguajes ms comunes utilizados en aplicaciones de Internet, como
Java, PHP y otros.

Finalmente, debe contener algunos elementos de seguridad.

Los navegadores, por su parte, pueden recibir archivos mediante HTTP y

FTP y poseer capacidad para interpretar scripts en lenguajes con Java y
Javascript.

SERVIDOR DESCRIPCION
Servidor Web Dentro de Linux el servidor WEB ms potente
es el Apache que est diseado para ser muy
flexible y funcionar en una gran variedad de
 plataformas y entornos
Es una herramienta preventiva contra
Servidor Firewall
ataques, que realiza una inspeccin del trfico
(Cortafuegos)
entrante y saliente
El correo electrnico (E-mail) es
probablemente la aplicacin TCP/IP ms
Servidor de Correo
usada. Los protocolos bsicos de correo,
Electrnico
proporcionan intercambio de mensajes entre
hosts TCP/IP hosts.
Un servidor AntiVirus y AntiSpam,
conjuntamente con el servidor de correo
Servidor Antivirus y
electrnico forman la pareja perfecta en
Antispam
cuanto a seguridad en el filtrado de correo
entrante y saliente.
DHCP (Dynamic Host Configuration Protocol)
son las siglas que identifican a un protocolo
empleado para que los clientes, en una red
puedan obtener su configuracin de forma
Servidor DHCP dinmica a travs de un servidor del
protocolo. Los datos obtenidos pueden ser: la
direccin IP, la mscara de red, la direccin de
broadcast, las caractersticas del DNS, entre
otros.
Samba es en s un paquete muy complejo,
que brinda a los usuarios Linux de un sin fin
Servidor Samba de posibilidades a la hora de interactuar con
equipos Windows y Linux que estn
coexistiendo en redes heterogneas.
Squid es el software para servidor Proxy, ms
popular y extendido entre los sistemas
Servidor Proxy
operativos basados sobre UNIX. Es muy
confiable, robusto y verstil.
Servidor DNS Un servidor de DNS (Domain Name System)
es capaz de recibir y resolver peticiones
relacionadas con el sistema de nombres. Un
servidor DNS sirve, por tanto, para traducir su
nombre de dominio en una direccin IP y para
asignar nombres a todas las mquinas de una
 red y trabajar con nombres de dominio en
lugar de IPs.
MySQL es un sistema de administracin de
bases de datos (Database Management
Servidor Base de System, DBMS) para bases de datos
Datos relacionales. Como base de datos relacional,
utiliza mltiples tablas para almacenar y
organizar la informacin.
NFS, (Network File System), que en espaol se
llama Sistema de Ficheros en Red, es
probablemente el servicio ms complejo de
Servidor NFS
los que se ofrecen usando RPC. Permite
acceder a los ficheros remotos exactamente
igual que si fueran locales.
LDAP ("Lightweight Directory Access
Protocol"), Protocolo de Acceso Ligero a
Directorios es un protocolo de tipo cliente-
servidor para acceder a un servicio de
directorio. Este se encuentra condensado en
el estndar de Internet, el RFC 1777. Para su
desempeo, el cliente se conecta a los
Servidor LDAP servidores y les formula preguntas. Los
servidores responden con una respuesta o
con un puntero donde el cliente puede
obtener informacin adicional (normalmente
otro servidor LDAP). No importa a que
servidor LDAP se conecte un cliente, este
siempre obtendr la misma visin del
directorio.
Con una de las alternativas ms importantes
que nos permite Internet es la transferencia
de archivos de una computadora a otra desde
Servidor FTP
cualquier parte del mundo. Para ello se utiliza
el protocolo de transferencia de archivos o
FTP.

Tabla 2.6 Servidores Linux

Apache Web Server
El servidor HTTP Apache es un servidor web HTTP de cdigo abierto para
plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras,
que implementa el protocolo HTTP/1.1 y la nocin de sitio virtual. Cuando
comenz su desarrollo en 1995 se bas inicialmente en el cdigo del
popular NCSA HTTPd 1.3, pero ms tarde fue reescrito por completo. Su
nombre se debe a que Behelendorf eligi ese nombre porque quera que
tuviese la connotacin de algo que es firme y enrgico pero no agresivo,
y la tribu Apache fue la ltima en rendirse al que pronto se convertira el
gobierno de EEUU, y en esos momentos la preocupacin de su grupo era
que llegasen las empresas y "civilizasen" el paisaje que haban creado
los primeros ingenieros de internet. Adems Apache consista solamente
en un conjunto de parches a aplicar al servidor de NCSA. Era, en ingls, a
patchy server (un servidor "parcheado").

Caractersticas:
Multiplataforma.
Es un servidor de web que cumple con el protocolo HTTP 1.1
Es modular, es decir, puede ser adaptado a diferentes entornos y
necesidades, con los diferentes mdulos de apoyo que
proporciona, y con la API de programacin de mdulos, para el
desarrollo de mdulos especficos.
Basado en hebras en la versin 2.0
Incentiva la realimentacin de los usuarios, obteniendo nuevas
ideas, informes de fallos y parches para la solucin de los mismos.
Se desarrolla de forma abierta.
Extensible: gracias a ser modular se han desarrollado diversas
extensiones entre las que destaca PHP, un lenguaje de
programacin del lado del servidor.

Tomcat
Tomcat es un servidor web con soporte de servlets y JSPs. Tomcat no es
un servidor de aplicaciones, como JBoss o JOnAS. Incluye el compilador
Jasper, que compila JSPs convirtindolas en servlets. El motor de servlets
de Tomcat a menudo se presenta en combinacin con el servidor web
Apache.
Tomcat puede funcionar como servidor web por s mismo. En sus inicios
existi la percepcin de que el uso de Tomcat de forma autnoma era
slo recomendable para entornos de desarrollo y entornos con requisitos
mnimos de velocidad y gestin de transacciones. Hoy en da ya no
existe esa percepcin y Tomcat es usado como servidor web autnomo
en entornos con alto nivel de trfico y alta disponibilidad.

Dado que Tomcat fue escrito en Java, funciona en cualquier sistema

operativo que disponga de la mquina virtual Java. (Tambin se puede
usar con xampp)
 CAPITULO III: DIAGNOSTICO

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.

3.1. Herramientas de Open Source para la construccin de

Cluster
Podemos encontrar una amplia variedad de aplicaciones para la
creacin de clusters, 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.

Caractersticas
Herramienta
openMosix Parche al kernel de GNU/Linux.
Algoritmo interno de balance de carga que
migra 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 para programar y administrar el
OSCAR
clster.
Formado por dos componentes principales
SIS (System Installation Suite) y ODA
(OSCAR Database API).
Implementacin de software de alta
disponibilidad.
Interfaz web para control completo del

Piranha 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.
Balance de carga mediante nodo dedicado
Linux Virtual con sistema operativo GNU/Linux.
Server LVS
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
Ultramonkey
HTTP, FTP,DNS, entre otros.
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 Desventaja

No se requieren paquetes adicionales.

Depende del kernel.
No son necesarias modificaciones en el
openMosix No migra todos los procesos siempre.
cdigo de openMosix.
Problemas con memoria compartida.
Migracin de procesos.
Falla la deteccin de algunos componentes
Es una compilacin auto instalable. de hardware en versiones anteriores a la 3.
Infraestructura de software para Soporte para distribuciones basadas en
Oscar instalar y administrar un clster. RPMs solamente para versiones anteriores a
Posee bibliotecas y compiladores para la 5.
uso en clsters. Requiere que la LAN no sea usada para
instalar software en el clster.
Soporte por parte de Red Hat Inc.
Fcil instalacin debido al formato de Al momento solo disponible para versiones
distribucin. empresariales de Red Hat.
Piranha
Administracin y manejo mediante Dependiente del sistema operativo Red Hat
interfaz web. Enterprise.
Monitorizacin de servidores reales.
Linux Virtual Server Fcil comprensin de funcionamiento. Algunos esquemas se ven afectados por la
LVS Amplia gama de configuraciones. cantidad de servidores reales que se pueden
 utilizar.
Funciona a nivel TCP/IP.
Cuando el nmero de servidores reales es
Manejo de varios tipos de protocolos
elevado se genera mucho trfico en la red
como HTTP, DNS, FTP entre otros.
de trabajo.
Mltiples esquemas de configuracin.
Rene varias herramientas de una
manera sencilla.
Varios formatos para su instalacin. Los nodos directores tienen que ejecutar
Amplia documentacin sobre cada estrictamente el sistema operativo
componente. GNU/Linux.
Ultramonkey Instrucciones de instalacin para las Segn el esquema de configuracin puede

distribuciones de GNU/Linux ms llegar a ser complejo.

comunes en servidores. Mismas que en LVS para los componentes
Se apoya en el proyecto LVS para que sean utilizados de dicho proyecto.
algunos 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 de Distribucion Balanceo de
Herramienta Distribuci es Carga y Alta Ventajas Desventajas
n Soportadas Disponibilidad
Balanceo de carga No requiere paquetes Dependiente del kernel
RPM, Cdigo
openMosix Todas de procesos sin adicionales y hace y posee problemas con
fuente.
alta disponibilidad. migracin de procesos. memoria compartida.
En versiones anteriores
Auto instalable con a la tercera falla la
RPM, Cdigo Red Hat y Balanceo de carga
bibliotecas y deteccin de hardware
Oscar basadas en de procesos sin
fuente. compiladores para y no permite usar la red
esta. alta disponibilidad.
computo paralelo. interna para instalacin
de software.
Actualmente disponible
Red Hat Posee herramientas Soporte de Red Hat,
solo en formato RPM y
Piranha RPM Enterprise 4 o propias para ambos administracin y manejo
para versiones
posteriores. aspectos. mediante interfaz web.
empresariales.
Instalacin por
Incluye Amplia gama de segmentos; con un
Linux Virtual RPM, DEB,
herramientas de configuraciones, funcin gran nmero de
Cdigo Todas.
Server - LVS cdigo abierto para a nivel TCP/IP y manejo servidores reales el
fuente.
ambos aspectos de distintos protocolos. trfico crece de manera
significativa.
 Basadas en Uso de Los nodos de balance
Mltiples
Debian, Red componentes de de carga debern
configuraciones, manejo
RPM. DEB, Hat Enterprise LVS para ambos ejecutar el sistema
de distintos protocolos,
Ultramonkey Cdigo 4 y mediante aspectos operativo NU/Linux;
funcin a nivel TCP/IP,
fuente. compilacin aadiendo algunas dependiendo del
marcas de firewall y
de cdigo mejoras y esquema llega a ser
ampliacin de LVS.
fuente. herramientas. complejo de configurar.
Tabla 3.3 Comparacin de herramientas para clster.
 Ultramonkey, es 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 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.

3.3. Herramientas para el balanceo de carga y alta

disponibilidad

3.3.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 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.3.2.Linux Virtul 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 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.

3.3.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.3.3.1. Componentes de 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.3.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.

3.3.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.3.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 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.
 CAPITULO IV: DISEO

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.

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.
METODO VENTAJAS DESVENTAJAS
DNS Distribucin de la carga El cache de la
Round- entre servidores reales informacin en la
Robin de forma pseudo- jerarqua de servidores
aleatoria. DNS y la forma simple
Es el ms simple de de tomar decisiones
implementar. por parte del servidor
DNS restringen su
utilidad.
Los servidores no
pueden ser
seleccionados segn el
URL solicitado.7
Uso del Este nodo distribuye las Llega a convertirse en
Nodo de conexiones. cuello de botella.
balanceo Se aumenta la Hace uso de un nodo
de carga sensacin de unidad del adicional para proveer
clster. nica direccin el balanceo de carga.
IP pblica a la cual Al existir solo un nodo
dirigir las peticiones. de balanceo este se
Es sencillo enmascarar convierte en un punto
fallas de los servidores. nico de fallo.

Tabla 4.1 Mtodos de balanceo de carga.

7
http://www.wikilearning.com/monografia/balance_de_carga-la_aproximacion_via_dns/20837-2
 4.2. Modos de balanceo de carga en LVS
LVS permite realizar el reenvo de paquetes a los servidores reales de
tres formas:

4.2.1.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). 8

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:

8
http://www.adslfaqs.com.ar/que-es-nat-network-address-translation/
 Figura 4.1 Balanceo mediante NAT.

4.2.2.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:
 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.

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

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.3. Resumen de los modos de balanceo

En la tabla 4.2 a continuacin se resumen las caractersticas
principales de los tres mtodos de direccionamiento que puede
utilizar el balanceador de carga de Linux Virtual Server:
Encapsulamien Enrutamiento
NAT
to IP Directo
Necesita
Servidor Cualquiera Dispositivo no-ARP
encapsulamiento
Red de
Servidore Red Privada LAN/WAN LAN
s
Escalabili
Baja (10-20) Alta Alta
dad
Salida
Nodo de
hacia Router Router
balanceo
Internet

Tabla 4.2 Mtodos de direccionamiento

4.4. 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 y en particular de una versin
empresarial. La tabla 4.4 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.4 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.5.
 Procesador Pentium MMX 166
MHz
Memoria RAM 64 MB
Espacio en Disco Duro +1 GB
(sin interfaz grafica)
Interfaz de red 10 Mbps
Tabla 4.5 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.6
siguiente se aprecian los mnimos de hardware para
ultramonkey.

Procesador Pentium MMX 166

MHz
Memoria RAM 64 MB
Espacio en Disco Duro +512 GB
(recomendado +
1GB)
Interfaz de red 10 Mbps

Tabla 4.6 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.

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

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
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.
 DESCRIPCI ALTERNATIVAS DISTRIBUCI ELECCIO JUSTIFICACION DE LA ELECCION
ONES
N N
Pirhana
Es una de las mejores herramientas para
ALTA OpenMosix Ultramon
Clster, es GNU. Con Hearbeat podemos
Linux Virtual
DISPONIBILI key determinar si el servidor ha dejado de
Server
funcionar y levantar los servicios en el
DAD Oscar Hearbeat
servidor de respaldo.
Ultramonkey
Pirhana Ultramon
OpenMosix
BALANCEO Linux Virtual key Se ha elegido por ser una solucin gratis,
SOFTWA confiable, muy rpida ofreciendo balanceo
DE CARGA Server Ldirector de carga.
RE PARA Oscar
Ultramonkey d
CLUSTER SUSE
ING Red Hat
SISTEMA Fedora El sistema operativo a utilizar en nuestro
GNU/Linux Centos
OPERATIVO Ubuntu proyecto ser Centos 5.5.
Debian
Centos
Apache
Servidor WEB ms potente est diseado
SERVIDORE iplanet Apache para ser muy flexible y funcionar en una
Netscape
S WEB Tomcat gran variedad de plataformas y entornos
SunOne
Tomcat

Tabla 4.7. Software a utilizar en el clster

 CAPITULO V: IMPLEMENTACIN

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.

5.1. Instalacin y Configuracin 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
direccin 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.

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 Cluster

 Figura 5.1 Funcionamiento del Cluster
5.2. Seleccin de Nodos para el Cluster
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).
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.)
Cliente
Navegador Web.
Sistema Operativo GNU/Linux CentOs 5.5.
Balanceo de Aplicaciones IPROUTE, IPTABLES, TCPDUMP
Carga [Tcpdump].
Editor de textos VIM.
Servidor Real Sistema Operativo GNU/Linux CentOs 5.5.
Aplicaciones IPROUTE, IP RULE e IPTABLES.
Editor de textos VIM.
 Servidor de pginas web Apache2.
Tabla 5.4 Herramientas utilizadas en cada nodo

Caractersticas Caractersticas
Herramientas
Principales
Balanceo de carga.
Escalabilidad.
Balanceo de
Bajo consumo de
Suite carga.
recursos.
Alta disponibilidad.
Diversos esquemas de
configuracin.
Manejo de diversos
Ultramonkey protocolos como HTTP, Escalabilidad
FTP, etc.
Crear y editar archivos
de texto.
Manejo de pestaas
Crear y editar
para mltiples
archivos de texto.
documentos.
Uso de nmeros
Editor de Textos Uso de nmeros de
de lnea.
VIM lnea.
Bsqueda de
Bsqueda de patrones
patrones dentro
dentro del documento.
del documento.
Ejecucin de
comandos sin salir del
editor.
Servidor Web Soporte de lenguajes Soporte de
Apache - de programacin mdulos para
Tomcat mediante mdulos. lenguajes y otras
Soporte para HTTPS. aplicaciones.

Soporte para SSL Soporte de SSL.

(Secure Socket Layer) Creacin de host

mediante mdulo. virtuales.
Permite crear host
virtuales.
Amplia gama de
 configuraciones.
Calidad de servicio. Balanceo de
Mantenimiento de carga.
Aplicacin
varias tablas de ruteo. Mantenimiento de
IPROUTE
Balanceo de carga. varias tablas de
Definicin de tneles. ruteo.
Permite interceptar y
manejar paquetes de
red. Intercepcin y
Permite el manejo de manejo de
paquetes en paquetes de red.
Aplicacin diferentes estados del Construccin de
IPTABLES procesamiento. firewalls basados
Permite construir en GNU/Linux.
firewalls basados en Traduccin de
GNU/Linux. direcciones (NAT).
Realiza traduccin de
direcciones (NAT).
Permite depurar
aplicaciones que
utilizan la red para
Permite capturar y
comunicar.
leer datos
Aplicacin Permite depurar la red
TCPDUMP. enviados por otros
misma.
usuarios o
Permite capturar y
computadoras.
leer datos enviados
por otros usuarios o
computadoras.
Tabla 5.5 Caractersticas de herramientas utilizadas

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

Seleccin de medio de instalacin.

Proceso de instalacin del sistema
base.
Tabla 5.6 Proceso de
Instalacin de paquetes adicionales.
instalacin del
Sistema Operativo

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
Zona Horaria Debe especificarse a qu zona horaria pertenece
el 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 usuarios comunes que utilizarn el sistema.
Muestra las opciones de configuracin
automtica mediante el protocolo DHCP; de
Configuracin de forma manual en la cual se proporcionan datos
Red como la direccin IP y la puerta de enlace y por
ltimo permite dejar de momento sin
configuracin la interfaz de red.
Aqu se marcarn aquellos servicios que sean
necesarios de los presentes en la lista mostrada,
Seleccin de si alguno no se encuentra en dicha lista,
Aplicaciones 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).

La tabla 5.9 a continuacin muestra los servicios que se debern

activar en los nodos servidores.
Servidor de pginas web Apache -
Tomcat.
Editor de textos VIM.
Aplicaciones IPROUTE e IPTABLES.
Tabla 5.9 Servicios activados en los nodos servidores

5.4. Configuracin del Servidor 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
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.
Figura 5.2. Configuracin final de nodos.
5.5. Instalacin de Centos
Para la instalacin del sistema operativo utilizado (CentOs 5.5), 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.6. Instalacin de Ultramonkey

En cuanto a los medios de instalacin de Ultramonkey, los podemos
encontrar en forma de paquetes de cdigo fuente, paquetes pre-
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.6.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 servidores reales. La VIP
(direccin IP virtual) del clster es 192.168.1.20.

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

5.6.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.7. 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.8. 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.

5.9. Configuracin del clster

5.9.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.9.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.

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.10. 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.
iptables -A INPUT i eth1 -p tcp --dport 80 -j ACCEPT

Guardamos la configuracin de las reglas iptables.

service iptables sabe
 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.11. Pruebas de desempeo

Bibliografa

http://www.utpl.edu.ec/eccblog/wp-content/uploads/2007/04/articulo-
tecnico-cluster-de-balanceo-de-craga-y-alta-disponibilidad-para-
servicios-web-y-mail.pdf

http://biblioteca.epn.edu.ec/catalogo/fulltext/CD-0691.pdf

http://digeset.ucol.mx/tesis_posgrado/Pdf/Felix_Ortigosa_Martinez.pdf

http://wwwisis.ufg.edu.sv/wwwisis/documentos/TE/005.1-P855c/005.1-
P855c-Capitulo%20IV.pdf

http://biblioteca.epn.edu.ec/catalogo/fulltext/CD-2725.pdf

http://www.gnu.org/philosophy/free-sw.es.html

http://www.gnu.org/philosophy/fsfs/free_software.es.pdf

http://es.scribd.com/doc/57937293/45/Heartbeat#page=14