UNIVERSIDAD ALFREDO PÉREZ GUERRERO

UNAP

CARRERA: SISTEMAS DE INFORMACION Y

NETWORKING

PROYECTO DE GRADO

PARA LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN

SISTEMAS INFORMATICOS Y NETWORKING

TEMA:
“DISEÑO DE UNA SOLUCIÓN PARA SERVIDORES DE
ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON
OPEN SOURCE”

Autor: Flavio Mauricio Gallardo Padilla

Director: Ing. Nelio Brito

Mayo del 2011

Quito, 13 de mayo del 2011

Señor:
Coordinador de Tesis y Proyectos de Grado UNAP
Presente.-

De nuestras consideraciones:

Por medio de la presente CERTIFICAMOS, que el señor estudiante – egresado

Flavio Mauricio Gallardo Padilla, identificado con el número de cédula
1710049139 estudiante de la carrera de Ingeniería en Sistemas y Networking
de la UNAP, una vez realizada la dirección y las evaluaciones correspondientes
según la normativa de la universidad, ha concluido satisfactoriamente con el
trabajo de grado Titulado “DISEÑO DE UNA SOLUCIÓN PARA SERVIDORES
DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON OPEN SOURCE”.

Por consiguiente, otorgamos la aptitud para la presentación del grado oral del
mencionado estudiante.

Agradeciendo su atención

Ing. Nelio Brito Ing. Fredy Molina Ing. Rommel Caicedo

Director Evaluador Evaluador
Quito, 13 de mayo del 2011

Señores:

Universidad Alfredo Pérez Guerrero UNAP

Presente.-

De mis consideraciones:

Yo, Flavio Mauricio Gallardo Padilla, identificado con el número de cédula

1710049139, estudiante egresado de la UNAP de la Carrera de Ingeniería en
Sistemas y Networking, por medio de la presente CERTIFICO que el presente
Trabajo de Grado titulado: “DISEÑO DE UNA SOLUCIÓN PARA
SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON
OPEN SOURCE”; es de mi plena autoría y no constituye plagio ni copia alguna
constituyéndose un documento único.

Es todo en cuanto puedo decir en honor a la verdad

Agradeciendo su atención

Mauricio Gallardo

C.I. 1710049139

Estudiante Egresado de la UNAP

AGRADECIMIENTO

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

A mis hijas, quienes comprendieron que el tiempo que debía entregarles a ellas
lo ocupaba en culminar mi carrera, quiero que este logro sea para ellas un
ejemplo de perseverancia y sacrificio y que sea también un ejemplo para la
culminación de sus carreras profesionales en su momento, entiendan que todo
lo que uno se propone en la vida es posible con dedicación y esfuerzo.
INDICE

INTRODUCCION ................................................................................................. i
CAPITULO 1 ....................................................................................................... 1
GENERALIDADES ............................................................................................. 1
1.1. PLANEAMIENTO DEL PROBLEMA ............................................................ 1
1.2. FORMULACION DEL PROBLEMA .............................................................. 2
1.3. SISTEMATIZACION .................................................................................... 2
1.4. OBJETIVO GENERAL ................................................................................. 2
1.5. OBJETIVOS ESPECIFICOS ........................................................................ 3
1.6. JUSTIFICACIÓN .......................................................................................... 3
1.7. ALCANCE .................................................................................................... 4
CAPITULO 2 ....................................................................................................... 6
INTRODUCCION ................................................................................................ 6
FUNDAMENTACION TEORICA ......................................................................... 6
MARCOS DE REFERENCIA (Teórico, Conceptual) ........................................... 6
2.1. MARCO TEORICO ...................................................................................... 6
2.1.1. Clustering .................................................................................................. 6
2.1.1.1. Antecedentes ......................................................................................... 6
2.1.1.2 Que es el clustering? .............................................................................. 7
2.1.1.3. Tipos de clúster ...................................................................................... 8
2.1.1.4. High Performance .................................................................................. 8
2.1.1.5. Clúster Activo/Pasivo ........................................................................... 14
2.1.1.6. Clúster Activo/Activo ............................................................................ 14
2.1.2. Arquitectura de Clustering....................................................................... 15
2.1.2.1. Alta disponibilidad ................................................................................ 16
2.1.2.2. Escalabilidad ........................................................................................ 20
2.1.3. Funcionamiento de un clúster ................................................................. 22
2.1.3.1. Balanceador de carga .......................................................................... 22
2.1.3.2. Sistema para la detección de fallos en los nodos del clúster ............... 24
2.1.3.3. Recursos del clúster ............................................................................ 25
2.1.3.4. Servicio a clusterizar ............................................................................ 25
2.1.4. Balanceo de Carga ................................................................................. 26
2.1.4.1. Balanceadores hardware ..................................................................... 29
2.1.4.2. Balanceadores software....................................................................... 30
2.1.4.3. Linux Virtual Server - LVS .................................................................... 30
2.1.5. Detección de fallos en los nodos del clúster ........................................... 32
2.1.5.1. Heartbeat ............................................................................................. 32
2.1.5.2. Disco de quorum .................................................................................. 34
CAPITULO 3 ..................................................................................................... 36
INTRODUCCION .............................................................................................. 36
DIAGNOSTICO ................................................................................................. 36
3.1. Herramientas de open source para la construcción del Clúster ................. 36
3.2. Comparación de las herramientas de balanceo de carga y alta
disponibilidad .................................................................................................... 40
3.2.1. Herramientas de balanceo de carga y alta disponibilidad ....................... 44
3.2.1.1. Piranha................................................................................................. 44
3.2.1.2. Linux Virtual Server .............................................................................. 45
3.2.1.3. Ultramonkey ......................................................................................... 47
3.2.1.3.1. Componentes Ultramonkey ............................................................... 47
3.2.1.3.1.1. Heartbeat ....................................................................................... 48
3.2.1.3.1.2. Ldirectord ....................................................................................... 48
3.2.1.3.1.3. Mon (Service Monitoring Daemon)................................................. 49
CAPITULO 4 ..................................................................................................... 50
INTRODUCCION .............................................................................................. 50
DISEÑO ............................................................................................................ 50
4.1. Tipos de balanceo de carga ....................................................................... 50
4.1.1. Modos de balanceo de carga en LVS ..................................................... 51
4.1.2. Resumen de los métodos de balanceo ................................................... 56
4.1.3. Planificación del balanceo de carga ........................................................ 57
4.2. Elección de una herramienta para balanceo de carga y alta disponibilidad
.......................................................................................................................... 62
CAPITULO 5 ..................................................................................................... 69
INTRODUCCION .............................................................................................. 69
IMPLEMENTACION EN MAQUINAS VIRTUALES ........................................... 69
5.1 INSTALACION Y CONFIGURACION DEL CLUSTER ................................ 69
5.1.1 SELECCIÓN DE NODOS PARA EL CLÚSTER ...................................... 71
5.1.2 Instalación de los nodos........................................................................... 74
5.1.3. Configuración de los servidores web ...................................................... 76
5.2. Instalación de CentOs ................................................................................ 78
5.3. Instalación de Ultramonkey ........................................................................ 78
5.3.1. Selección de topología de instalación de ultamonkey ............................. 79
5.3.1.1. Directores Linux o Nodos de balanceo ................................................ 80
5.3.1.2. Nodos servidores o servidores reales .................................................. 81
5.4. Configuración de Heartbeat en los nodos de balanceo ............................. 81
5.5. Configuración de la red de trabajo ............................................................. 81
5.6. Configuración del clúster ........................................................................... 82
5.6.1. Directores Linux, nodos de balanceo ...................................................... 82
5.6.2. Heartbeat ................................................................................................ 82
5.7. Instalar y configurar IPROUTE en los nodos servidores ............................ 83
5.8. Pruebas de desempeño ............................................................................. 84
5.8.1. Herramientas para medición de rendimiento .......................................... 86
5.8.1.1. Selección de una herramienta para medición de rendimiento ............. 86
CONCLUSIONES ............................................................................................. 91
Anexo 1 Instalación de Centos ......................................................................... 95
Anexo 2 Instalación de la Solución ................................................................. 118
INDICE DE FIGURAS

Figura 2.1 Clúster de computadores ............................................................... 7

Figura 2.2 Componentes de un clúster ............................................................ 9
Figura 2.3 Arquitectura de un Clúster ............................................................ 15
Figura 2.4 Alta disponibilidad ......................................................................... 20
Figura 2.5 Balanceador de Carga .................................................................. 23
Figura 2.6 Recursos del Clúster .................................................................... 25
Figura 2.7 Balanceo de Carga ....................................................................... 27
Figura 2.8 Balanceadores de Carga .............................................................. 31
Figura 2.9 Heartbeat ...................................................................................... 32
Figura 2.10 Disco de Quorum ........................................................................ 35
Figura 3.1 Esquema de funcionamiento de Piranha. ..................................... 45
Figura 3.2 Esquema de funcionamiento de LVS. .......................................... 46
Figura 3.3 Componentes de Ultramonkey. .................................................... 48
Figura 3.4 Esquema de funcionamiento de Ultramonkey. ............................. 49
Figura 4.1 Balanceo mediante NAT. .............................................................. 53
Figura 4.2 Balanceo mediante encapsulado IP. ............................................ 54
Figura 4.3 Balanceo mediante enrutamiento directo. .................................... 55
Figura 4.4 Round Robin................................................................................. 59
Figura 4.5 Round Robin Ponderado. ............................................................. 59
Figura 4.6 Servidor con menos conexiones activas. ..................................... 60
Figura 4.7 Servidor con menos conexiones activas ponderado. ................... 60
Figura 4.8 Menos conectado basado en servicio. ......................................... 61
Figura 4.9 Tablas Hash por origen y destino. ................................................ 61
Figura 5.1 Funcionamiento del Clúster. ......................................................... 70
Figura 5.2. Configuración final de nodos. ...................................................... 78
Figura 5.3. Página del servidor 1 ................................................................... 85
Figura 5.4. Página del servidor 2 ................................................................... 85
Figura 5.5. Detención del servicio httpd......................................................... 86
Figura 5.6. Verificación de servidores y conexiones con ipvsadm –l. ............ 88
Figura 5.7. Verificación de servidores y conexiones con ipvsadm –lnc. ........ 89
Figura 5.8. Tráfico en la red con tcpdump. .................................................... 89
Figura 5.9. Salida de tráfico en la red con tcpdump. ..................................... 90
INDICE DE TABLAS

Tabla 2.1 Tipos de Clúster ........................................................................... 8

Tabla 2.2 Subtipos de Clúster ...................................................................... 9
Tabla 2.3 Componentes de un Clúster ....................................................... 10
Tabla 2.4 Configuración de un Clúster ....................................................... 14
Tabla 2.5 Estructura de Alta Disponibilidad ................................................ 15
Tabla 3.1 Características de Herramientas para Clústers. ......................... 38
Tabla 3.2 Ventajas y Desventajas de las Herramientas para Clúster. ........ 40
Tabla 3.3 Comparación de herramientas para clúster. ............................... 42
Tabla 4.1 Métodos de balanceo de carga. ................................................. 51
Tabla 4.2 Modos de balanceo de carga en LVS......................................... 52
Tabla 4.3 Métodos de direccionamiento. .................................................... 57
Tabla 4.4 Algoritmos de planificación de balanceo de carga. .................... 58
Tabla 4.5 Requisitos mínimos de hardware para Piranha. ......................... 63
Tabla 4.6 Requisitos mínimos de hardware para LVS. .............................. 64
Tabla 4.7 Requisitos mínimos de hardware para Ultramonkey. ................. 64
Tabla 4.8 Comparación de requisitos. ........................................................ 65
Tabla 5.1 Funcionamiento del Clúster. ....................................................... 70
Tabla 5.2 Especificaciones del nodo de balanceo. ..................................... 71
Tabla 5.3 Especificaciones de nodo servidor. ............................................ 71
Tabla 5.4 Herramientas utilizadas en cada nodo. ...................................... 72
Tabla 5.5 Características de herramientas utilizadas. ................................ 74
Tabla 5.6 Proceso de instalación del Sistema Operativo. .......................... 74
Tabla 5.7 Medios de instalación. ................................................................ 75
Tabla 5.8 Proceso de instalación del sistema base. ................................... 76
Tabla 5.9 Servicios activados en los nodos servidores. ............................. 76
 i

INTRODUCCION

Para que un servicio sea eficiente es necesario que se mantenga en

funcionamiento constante y que no ocurran retardos en la entrega de la
información. Así pues se da paso a la investigación y desarrollo de nuevas
tecnologías que garanticen tales sucesos; en este trabajo se presentarán las
soluciones para tales problemas y se expondrán sus características así como
las herramientas que hacen posible la construcción de dichas soluciones de
software con open source.

Un servidor juega un papel muy importante dentro de una organización, y al

mismo tiempo se transforma en un servicio crítico al ser utilizado por la gran
mayoría de los usuarios para acceder a todos los servicios que este brinda,
siendo necesario la implementación de un sistema de clúster que permita
mantener el servicio disponible en caso de que falle un servidor así como
mantener un sistema de balanceo de carga evitando la saturación del propio
servidor.

Un clúster es un conjunto de maquinas, conectadas entre sí en red y

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

Al hablar de clúster, tenemos un numeroso listado de diversas aplicaciones que

implementan distintos tipos de clúster, dependiendo de las necesidades que
posee la organización y la aplicación a clusterizar.

Dentro de los clúster más comunes, se encuentra el clúster de alta

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

de los servicios y pasa a ser el activo para que los servicios ofrecidos estén
siempre disponibles.

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

los servicios, es necesario también aprovechar los nodos pertenecientes al
clúster, para que estos pasen a ser activos y la carga se pueda dividir entre
todos los nodos del clúster, constituyendo así un clúster de balanceo de carga.
 1

CAPITULO 1

GENERALIDADES

1.1. PLANEAMIENTO DEL PROBLEMA

Las empresas actualmente se han visto en el problema de suspender

temporalmente sus operaciones debido a incidentes ocurridos en los servidores
de servicios tales como proxy, correo electrónico, ftp, web, etc., dando origen a
prestar servicios de baja calidad a sus clientes poniendo en riesgo la
continuidad del negocio, lo que ocasiona pérdidas económicas.

Actualmente en el país existen pocas empresas que han optado por instalar
open source en sus servidores debido al poco personal técnico capacitado,
pese a que el gobierno nacional promueve el uso de open source en las
entidades públicas. Este trabajo se enfoca en el uso de software libre para la
implementación de la solución planteada.

Existen equipos que permiten balanceo de carga y alta disponibilidad mediante

hardware, pero la adquisición de estos significa una inversión para las
empresas contrariamente a las soluciones de software open source que no
necesitan pagar ningún valor de licenciamiento.

De no contar con una solución al problema de alta disponibilidad y balanceo de

carga por software se perderá la opción de contribuir a una investigación e
implementación de este tipo.

Mediante la implementación de la solución, las empresas aseguran el normal

desenvolvimiento de sus operaciones, minimizando sustancialmente el riesgo
tecnológico dando continuidad al negocio y por consiguiente a sus operaciones,
se centrará en la técnica de obtener una alta disponibilidad y balanceo de carga
 2

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

sólo (se realizará la implementación en máquinas virtuales), que sean capaces
de trabajar en paralelo y de asumir las caídas de algunos de sus compañeros,
y podremos añadir y quitar servidores al grupo (clúster) según las necesidades.

1.2. FORMULACION DEL PROBLEMA

¿Encontrar la solución que permita mantener un alto nivel de disponibilidad y

balanceo de carga, con herramientas open source, dando continuidad a los
servicios?. Considerando la experiencia adquirida en la implementación,
administración y mantenimiento de servidores Linux en los últimos años de
servicio profesional.

1.3. SISTEMATIZACION

¿Qué herramientas open source nos permiten aplicar alta disponibilidad y

balanceo de carga?

¿Qué herramientas open souce se utilizarán para la implementación de la

solución?
¿Qué necesitan las empresas para solucionar su problema de alta
disponibilidad y balanceo de carga?

1.4. OBJETIVO GENERAL

Diseñar una solución de alta disponibilidad y balanceo de carga, para dotar de

servicios que permitan dar continuidad al negocio en las operaciones
realizadas por las empresas, con software open source.
 3

1.5. OBJETIVOS ESPECIFICOS

Investigar las distintas posibilidades que nos ofrece hoy en día el mundo del
Software Libre para disponer de servidores de alta disponibilidad y balanceo de
carga en el terreno empresarial y orientado principalmente a servicios IP
(servidores HTTP, SMTP, POP, FTP, etc), basados en la replicación de
servidores (clustering) con máquinas virtuales y bajo el Sistema Operativo
GNU/Linux.

Diagnosticar el estado actual de la tecnología utilizada en las empresas, que

necesitan balanceo de carga y alta disponibilidad.

Diseñar una solución que permita ofrecer servidores de alta disponibilidad y

balanceo de carga mediante software libre.

Implementar en un ambiente de laboratorio la solución diseñada, para asegurar

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

1.6. JUSTIFICACIÓN

Con el actual ritmo de crecimiento del comercio y el movimiento de datos de

todo tipo en Internet, web 2.0, con el establecimiento no formal de un protocolo
mundial IP generalizo y la incuestionable importancia de las tecnologías de la
información en las empresas actuales de cualquier tamaño, es cada día más
importante que los servicios puedan funcionar con un alto nivel de SLA (calidad
de servicio) , ya sea para dar soporte interno, como para ofrecer servicios a
través de Internet e Intranet (http, correo, ftp, etc). A esta necesidad de un
servicio ininterrumpido y fiable se le conoce como alta disponibilidad, de igual
forma evitar la sobre carga existente en los servidores debido al gran número
de usuarios y que estos no sean saturados, compartiendo con otros la
responsabilidad de dar los servicios conocemos como balanceo de carga.
 4

Para poder incrementar la base científica relacionada con proyectos de

software open source y minimizar el riesgo tecnológico. Se utiliza open source
por que es software libre, es decir no se debe incurrir en gastos de
licenciamiento para su uso.
Desde el punto de vista metodológico, esta investigación generará
conocimiento válido y confiable dentro del área de las TICS , para futuras
implementaciones. Esta investigación abrirá nuevos caminos en empresas que
presenten situaciones similares sirviendo a estas como marco referencial.

1.7. ALCANCE

El proyecto abarcará la investigación sobre las herramientas de clúster que nos

ofrece el software libre, para de esta manera analizar la mejor opción para ser
implementada, esta investigación permitirá además adquirir conocimiento para
futuras implementaciones.

Después de conocer las opciones de cluster con open source, se realizará un

diagnostico sobre las herramientas disponibles para proponer una solución que
permita de forma adecuada implementar la tecnología elegida, tomando en
cuenta siempre la mejor alternativa.

Se creará un laboratorio con máquinas virtuales para la implementación en un

ambiente de pruebas, que contendrá servicios como http, mail, ftp, proxy,
además se obtendrá pruebas de los resultados de funcionamiento de la
solución.

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

construcción del clúster (el cliente solamente necesita un navegador web) el
cual realiza las peticiones de la página web principal alojada en el clúster, de
esta manera se puede observar cual servidor real es el que atiende la petición
(en un sistema en producción esto no deberá ser así ya que la intención es que
los usuarios vean al sitio web como un solo equipo). En lo concerniente a las
 5

pruebas de alta disponibilidad, serán realizadas de 3 maneras, la primera es

desconectando un nodo de balanceo, la segunda es detener la ejecución de las
aplicaciones encargadas de monitorear el estado de los nodos de balanceo en
uno de los nodos para simular un fallo físico del nodo y tercera es apagando
uno de los nodos y revisar si el servicio sigue en funcionamiento. Esto nos dará
una visión certera del real funcionamiento de servidores de este tipo en
ambientes de producción.
 6

CAPITULO 2

INTRODUCCION

Este capítulo contiene conceptos fundamentales que son necesarios conocer

para la elaboración del proyecto como: clustering, tipos de clúster, arquitectura
de clustering, alta disponibilidad, balanceo de carga.

Adicionalmente se relata una breve historia del inicio, desarrollo y evolución de

la tecnología relacionada con los clúster.

FUNDAMENTACION TEORICA

MARCOS DE REFERENCIA (Teórico, Conceptual)

2.1. MARCO TEORICO

2.1.1. Clustering
2.1.1.1. Antecedentes
En el verano de 1994 Thomas Sterling y Don Becker, trabajando
para el CESDIS (Center of Excellence in Space Data and Informarion
Sciencies) bajo el patrocinio del Proyecto de las Ciencias de la Tierra
y el Espacio (ESS) de la NASA, construyeron un Clúster de
Computadoras que consistía en 16 procesadores DX4 conectados
por una red Ethernet a 10Mbps, ellos llamaron a su máquina
Beowulf.

La máquina fue un éxito inmediato y su idea de proporcionar

sistemas basados en COTS (equipos de sobremesa) para satisfacer
requisitos de cómputo específicos se propagó rápidamente a través
de la NASA y en las comunidades académicas y de investigación. El
esfuerzo del desarrollo para esta primera máquina creció
rápidamente en lo que ahora llamamos el Proyecto Beowulf.
Este Beowulf construido en la NASA en 1994 fue el primer clúster de
la historia, y su finalidad era el cálculo masivo de datos. Desde
entonces, la tecnología de clusters se ha desarrollado enormemente.
 7

2.1.1.2 Que es el clustering?

Clustering es un conjunto de maquinas, conectadas entre sí en red y

funcionando en paralelo y compartiendo recursos para cooperar en
cargas de trabajo complejas y conseguir mayor eficacia que un solo
equipo. Dado que se comporta como un único gran recurso. Cada
una de las máquinas que forman el clúster recibe el nombre de nodo.

Figura 2.1 Clúster de computadores

Esta tecnología ha evolucionado para beneficio de diversas

actividades que requieren el poder de cómputo y aplicaciones de
misión crítica.

El uso de los clústers es el resultado de una convergencia de

múltiples tecnologías que abarcan la disponibilidad de procesadores
económicos de alto rendimiento y las redes de alta velocidad, como
lo son las redes de fibra óptica así como también el desarrollo de
herramientas de software diseñadas para cómputo distribuido de alto
desempeño.
 8

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

2.1.1.3. Tipos de clúster

Dependiendo del tipo de solución que busquemos podemos clasificar

los clusters en varios tipos:

High Performance
High Availability
Load Balancing

2.1.1.4. High Performance

Tipo de Clúster Descripción

Alto rendimiento Conjunto de computadoras diseñado para brindar
(High Performance) altas prestaciones en cuanto a capacidad de cálculo.
Conjunto de dos o más computadoras que se
Alta disponibilidad caracterizan por mantener una serie de servicios
(High Availability) disponibles y compartidos, se caracterizan por estar
constantemente monitorizándose entre sí.
Compuesto por una o más computadoras que actúan
Balanceo de carga como interfaces primarias del clúster y se ocupan de
(Load Balancing) repartir las peticiones de servicio que recibe el
clúster a los nodos que lo conforman.

Tabla 2.1 Tipos de Clúster

 9

Además de la clasificación general de los tipos de clúster que se

pueden encontrar, es preciso destacar que se pueden tener los
siguientes subtipos en cada una de las categorías según se muestra
en la tabla 2.2.

Subtipo Descripción
Homogéneo Es donde todos los nodos poseen una
configuración de hardware y software iguales.
Semi- Es donde se poseen arquitecturas y sistemas
homogéneo operativos similares pero de diferente rendimiento.
Heterogéneo Es donde se poseen hardware y software distintos
para cada nodo.

Tabla 2.2 Subtipos de Clúster

Un clúster posee varios componentes de software y hardware para
poder funcionar, la figura 2.2 muestra dichos componentes:

Figura 2.2 Componentes de un clúster

 10

Para entender mejor estos componentes, es recomendable el

análisis mediante la tabla 2.3, en ella se puede observar cada
componente y una descripción del mismo comenzando por la
interconexión de los equipos.

Componente Descripción
Estas son las conexiones de los nodos a la red de trabajo
Conexiones de red. del clúster siendo tan complejas como lo sean las
tecnologías y medios utilizados en su instalación.
Protocolos de Aquí normalmente se cuenta con el protocolo de
comunicación y comunicaciones TCP/IP y servicios de transporte de datos.
servicios.
Son simples computadoras o sistemas multiprocesador; en
Nodos. estos se hospedan el Sistema Operativo, el middleware y lo
necesario para la comunicación a través de una red.
Se define a grandes rasgos como un programa o conjunto
Sistema Operativo. de ellos que están destinados a gestionar de manera eficaz
los recursos de una computadora. Como ejemplo se tiene
Unix, Mac OSX.
Es un software que actúa entre el Sistema Operativo y las
aplicaciones con la finalidad de proveer a un clúster las
Middleware. características de interfaz, herramientas de optimización y
mantenimiento del sistema, como también un crecimiento o
escalabilidad. Entre los más populares se encuentra
openMosix.
Son todos aquellos programas que se ejecutan sobre el
Aplicaciones. middleware; estos son diseñados para su ejecución en
entornos de cómputo paralelo o aprovechamiento del tipo
de clúster.
Tabla 2.3 Componentes de un Clúster
 11

Los clústers permiten una flexibilidad de configuración que no se

encuentra normalmente en los sistemas multiprocesadores
convencionales. El número de nodos, la capacidad de memoria por
nodo, el número de procesadores por nodo y la topología de
interconexión, son todos parámetros de la estructura del sistema que
puede ser especificada en detalle en una base por nodo sin incurrir
en costos adicionales debidos a la configuración personalizada.

Además, permiten una rápida respuesta a las mejoras en la

tecnología. Cuando los nuevos dispositivos, incluyendo
procesadores, memoria, disco y redes están disponibles se pueden
integrar a los nodos del clúster de manera fácil y rápida 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
tecnología. Los clústers son actualmente la mejor opción para seguir
la pista de los adelantos tecnológicos y responder rápidamente a las
ofertas de nuevos componentes.

Los clústers permiten una flexibilidad de configuración que no se

encuentra normalmente en los sistemas multiprocesadores
convencionales. El número de nodos, la capacidad de memoria por
nodo, el número de procesadores por nodo y la topología de
interconexión, son todos parámetros de la estructura del sistema que
puede ser especificada en detalle en una base por nodo sin incurrir
en costos adicionales debidos a la configuración personalizada.

Un clúster puede ser usado para solucionar una variedad de

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

 Cálculos matemáticos.
 Rendering (construcción/generación) de gráficos.
 Compilación de programas.
 Compresión de datos.
 Descifrado de códigos.
 Rendimiento del sistema operativo, (incluyendo en él, el
rendimiento de los recursos de cada nodo).
 En general cualquier problema de propósito general que
requiera de gran capacidad de procesamiento.

En el caso de los clúster de alta disponibilidad resuelven:

 Sistemas de información redundante.

 Sistemas tolerantes a fallos.
 Balance de procesos entre varios servidores.
 Balance de conexiones entre varios servidores.
 En general cualquier problema que requiera almacenamiento
de datos siempre disponible con tolerancia a fallos.

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

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

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

archivos distribuidos de carácter muy barato, hasta grandes clústers
de balanceo de carga y conexiones para los grandes portales de
Internet lo que lleva a que la funcionalidad requerida en un entorno
de red puede ser colocada en un clúster e implementar mecanismos
para hacer que éste obtenga la mayor disponibilidad posible.
 13

Realmente no hay sistemas que puedan asumir la alta disponibilidad

en realidad, se requiere que el clúster 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 añadir componentes

replicados para encubrir los posibles fallos mientras que la
redundancia de software incluye la administración del hardware
redundante para asegurar su correcto funcionamiento al hacer frente
a la caída de algún elemento. Y por último la redundancia en el
tiempo hace referencia a la repetición de la ejecución 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 decisión de cuál nodo deberá hacerse cargo de las
peticiones de servicio de otro que está con un mayor número de
peticiones de servicio que él, con el objetivo de que éstas se
encuentren equilibradas entre el total de nodos que conforman el
clúster. Cuando se genera una creciente demanda de trabajo en
este servicio se hace uso del balanceo de carga, creciendo el
número de nodos que mantienen el servicio a medida que la carga
de trabajo aumenta no siendo requisito el incorporar nodos con los
últimos avances tecnológicos.

En el balanceo de carga en un nodo (o varios según sea el caso) es

una tarea que controlará la distribución entre los servidores que
componen el clúster. Cabe aclarar que dicha labor se puede efectuar
a nivel de aplicación; lo que puede llevar a cuellos de botella si el
número de nodos servidores es grande y en un nivel de dirección IP,
en el cual la cantidad de información que es manejada es mucho
 14

menor, puesto que sólo son manejadas las direcciones IP y no datos

adicionales como el manejo de sesiones e información de control de
la aplicación; por ello en el manejo a nivel de dirección IP, un cuello
de botella es menos factible.

Así pues, para lograr que un sistema tenga características 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
clúster de alta disponibilidad puede componerse de uno o varios
nodos para sustentar el acceso al servicio ofrecido, sin embargo se
debe prestar atención cuando sólo se cuenta con un nodo pues este
representa un punto único de fallo lo que se traduce en un nodo que
al fallar, el acceso se ve interrumpido.

Una estructura de alta disponibilidad de este tipo está conformada

como se muestra en la tabla 2.5.

2.1.1.5. Clúster Activo/Pasivo

2.1.1.6. Clúster Activo/Activo

Configuración Descripción

Las aplicaciones se ejecutan sobre un conjunto de nodos

Activo – activos mientras que los nodos restantes actúan como
Pasivo respaldos redundantes.

Todos los nodos actúan como servidores activos de una o más

Activo – aplicaciones y potencialmente como respaldos para las
Activo aplicaciones que se ejecutan en otros nodos.
Tabla 2.4 Configuración de un Clúster
 15

Elemento Descripción

Consiste en componentes de software que cooperan

entre sí para permitir que el clúster parezca como un
sistema único. Entre sus funciones se encuentran:
 Monitorización de nodos y procesos.
 Control de acceso a recursos compartidos.
Infraestructura de  Satisfacción de requerimientos del usuario.
alta disponibilidad. Esta puede ser parte del núcleo del sistema operativo o
una capa situada sobre éste, las ventajas de dichas
integraciones son:
En forma de capa, una solución independiente del
sistema operativo.
En el sistema operativo, una eficiencia y facilidad
de uso.

Son clientes de la infraestructura y usan las facilidades

Servicios de alta que exporta ese nivel para mantener en todo momento el
disponibilidad. servicio. Usualmente existe una degradación del sistema
cuando un nodo falla pero no una interrupción del
servicio.

Tabla 2.5 Estructura de Alta Disponibilidad

2.1.2. Arquitectura de Clustering

 16

Figura 2.3 Arquitectura de un Clúster

El propósito de un cluster es:

Redundancia frente a fallos (alta disponibilidad).
Aumento de potencia (escalabilidad).
Estos propósitos no son excluyentes.
Importante.- A la hora de escoger que tipo de clúster se va a
utilizar hay que tener en cuenta las características que nos ofrece
cada tipo y cuál es el que más encaja en nuestro entorno.

2.1.2.1. Alta disponibilidad

“La alta disponibilidad ha sido tradicionalmente un requerimiento

exigido a aquellos sistemas que realizaban misiones críticas. Sin
embargo, actualmente, está siendo cada vez más importante exigir
esta disponibilidad en sistemas comerciales y en áreas académicas
donde el objetivo de prestar los servicios en el menor tiempo posible
es cada vez más perseguido.

El concepto de clúster de disponibilidad continua, se basa en la idea

de mantener la prestación del servicio en todo momento. Esto
representa una situación ideal, sería necesario que el sistema
estuviera compuesto de componentes perfectos que no fallaran
nunca, tanto en hardware como en software. Realmente no hay
sistemas que puedan asumir este tipo de disponibilidad.”1

Se necesita que el clúster 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 añadir
componentes replicados para encubrir los posibles fallos. La

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

redundancia software incluye la administración del hardware

redundante para asegurar su correcto funcionamiento al hacer frente
a la caída de algún elemento. La redundancia en el tiempo hace
referencia a la repetición de la ejecución de un conjunto de
instrucciones para asegurar el comportamiento correcto en caso de
que ocurra un fallo.

Definiremos un clúster de alta disponibilidad como un sistema capaz

de encubrir los fallos que se producen en él para mantener una
prestación de servicio continua.

El clúster de alta disponibilidad va a poder diseñarse con distintas

configuraciones. Una posible configuración es activo – pasivo en el
cuál las aplicaciones se ejecutan sobre el conjunto de nodos activos,
mientras que los nodos restantes actúan como backups redundantes
para los servicios ofrecidos.

En el otro extremo, tenemos otra posible configuración, activo -

activo: en este caso, todos los nodos actúan como servidores activos
de una o más 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 situación podría producir una sobrecarga de los
nodos de respaldo, con lo que se ejecutarían las aplicaciones con
más retardo.

Sin embargo es aceptable una degradación del servicio y también

suele ser preferible a una caída total del sistema. Otro caso particular
de clúster de alta disponibilidad sería el de un clúster de un solo
nodo, tratándose en este caso, simplemente, de evitar los puntos
únicos de fallo.
 18

“Los conceptos de alta disponibilidad y de clustering están

profundamente relacionados ya que el concepto de alta
disponibilidad de servicios implica directamente una solución
mediante clustering.

La principal prestación 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
automático (failover) o manual (switchover).”2

Generalmente este tipo de cluster integra un número relativamente

pequeño de nodos (entre 2 y 8), aunque existen soluciones
comerciales que trabajan en clusters de mayor tamaño. En este
caso, la escalabilidad no sería un objetivo prioritario, en contraste
con el caso de los clusters computacionales.

Las aplicaciones usadas para el diseño y la implementación de este

tipo de clusters no tienen porqué escalar. Sin embargo, actualmente,
existe una cierta tendencia a perseguir la escalabilidad también en
los clusters de alta disponibilidad lo que lleva a que cada vez se
busca más tener un cluster de mayor número de nodos pero más
pequeños en tamaño y prestaciones.

Desde un punto de vista general, una solución 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
interrelación entre nodos, controlar el acceso a los recursos

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

compartidos y asegurar la integridad de los datos y la satisfacción de

los requerimientos del usuario. La infraestructura debe proveer de
estas funcionalidades cuando el cluster está en estado estable y, lo
que es más 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
degradación del sistema cuando algún nodo cae, pero no una
interrupción del servicio.

Los servicios que se mantienen típicamente 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, serán
utilizados para tareas críticas o servicios ofrecidos por una empresa,
grupo de investigación o institución académica, que no puedan, por
sus características concretas, interrumpir el servicio.

La adaptación más común que debe sufrir una aplicación para poder
ser ejecutada en un clúster de alta disponibilidad implementado
sobre GNU/Linux, es añadir scripts. Existen APIs para trabajar
cómodamente con alta disponibilidad; todas ellas incluyen métodos
que permiten el switchover y el failover y que permiten arrancar,
parar o monitorizar una aplicación por mencionar algunas de sus
funcionalidades.

La infraestructura puede ser parte del núcleo 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 solución de alta disponibilidad del sistema operativo,
 20

con lo que resulta más portable. En cualquier caso el sistema debe

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

Figura 2.4 Alta disponibilidad

2.1.2.2. Escalabilidad

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

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

Escalabilidad del hardware (denominada también «escalamiento

vertical»). Se basa en la utilización de un gran equipo cuya
capacidad se aumenta a medida que lo exige la carga de trabajo
existente.

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

Escalabilidad del software (denominada también «escalamiento

horizontal»). Se basa, en cambio, en la utilización de un clúster
compuesto de varios equipos de mediana potencia que funcionan en
tándem 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 término RAC (Redundant Array of Computers o Array

redundante de equipos) para referirse a los clúster de escalamiento
horizontal. Del mismo modo que se añaden discos a un array RAID
para aumentar su rendimiento, se pueden añadir nodos a un clúster
para aumentar también 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 más 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 alimentación, 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 razón de que un solo
equipo no pueda ofrecer los niveles de escalabilidad, disponibilidad y
fiabilidad necesarios que sí ofrece un clúster.
 22

Importante
En un clúster activo / pasivo el incrementar el número de nodos
disponibles en el clúster no incrementa la potencia del clúster ya que
únicamente un nodo estará ofreciendo el servicio.

2.1.3. Funcionamiento de un clúster

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

conjunto de piezas, por ejemplo, de varios microprocesadores a
través 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 clúster se implementa básicamente con varias computadoras

similares de capacidades no necesariamente altas. Las
computadoras deben conectarse en una LAN compartida dedicada
sólo para el clúster. El clúster de alto rendimiento opera bajo
circunstancias en el que las tareas a procesar se reparten
paralelamente a las computadoras.

Un servicio de clúster consta de:

 Balanceador de carga.
 Sistema para la detección de fallos en los nodos del
clúster.
 Servicio a clusterizar.
 Recursos del clúster.

2.1.3.1. Balanceador de carga

Los balanceadores de carga permiten optimizar la utilización de

los recursos de un clúster mediante la asignación de tareas a los
 23

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

recursos libres.

Son necesarios en las configuraciones que sean Activo / Activo

y/o balanceo de carga.

La función de los balanceadores, también conocidos como

network dispatcher es redireccionar las peticiones a los servidores
que las están atendiendo.

Figura 2.5 Balanceador de Carga

2.1.3.2. Sistema para la detección de fallos en los nodos del clúster

En caso de aparición de fallo en algún componente, la tolerancia a

fallos busca que el sistema siga trabajando, aunque esté
funcionando en modo degradado, hasta que acabe la ejecución, lo
que podrá incidir en mayor o menor medida en sus prestaciones.
 24

La tolerancia a fallos en un sistema se logra mediante la inclusión

de técnicas deredundancia. Puede haber redundancia en
cualquier nivel: utilización de componentes hardware extra
(redundancia en el hardware), repetición de las operaciones y
comparación de los resultados (redundancia temporal),
codificación de los datos (redundancia en la información) e incluso
la realización de varias versiones de un mismo programa y del
uso de técnicas de Replicación 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 combinación 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 garantía
de que acabe la ejecución correctamente aunque se degraden
sus prestaciones.

Es necesario un sistema que detecte cuando existen nodos en el

clúster que no están disponibles para ofrecer el servicio. En este
caso no se enviarán peticiones para ser atendidas si el clúster es
Activo / Activo o no se balanceará el servicio sobre ellos si es
Activo / Pasivo.

Para detectar esta situación se utilizan dos técnicas:

1. Heartbeat.
2. Disco de quorum.
Estos conceptos serán detallados más adelante.

2.1.3.3. Recursos del clúster

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

Filesystems.
Scripts para arrancar el servicio

Figura 2.6 Recursos del Clúster

2.1.3.4. Servicio a clusterizar

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

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

• Servidores Proxy Cache

2.1.4. Balanceo de Carga

Con el crecimiento de Internet en los últimos años el tráfico 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 máquina de altas prestaciones, que a
largo plazo probablemente quede obsoleta por el crecimiento de
la carga, o bien se encamina la solución a la utilización de la
tecnología de clustering para mantener un clúster de servidores
de tal manera que cuando la carga de trabajo crezca, se añadirán
más servidores al clúster.

Hay varias formas de construir un clúster de balanceo de carga.

Una solución basada en mantener varios servidores aunque no se
trate de un clúster 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 situación 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 quedaría desbalanceada.
 27

Figura 2.7 Balanceo de Carga

Además, aún 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 sólo ver una
página, otro puede solicitar un buen número de ellas. Por otra
parte, si un servidor cae, se van a seguir redirigiendo peticiones a
él.

Una solución mejor es utilizar un balanceador de carga para

distribuir ésta entre los servidores de un clúster. En este caso el
balanceo queda a nivel de conexión, con una granularidad más
fina y con mejores resultados. Además, se podrán enmascarar
más fácilmente las posibles caídas de los nodos del clúster.

El balanceo de carga puede hacerse a dos niveles: de aplicación

y a nivel IP. Sin embargo, el balanceo a nivel de aplicación puede
provocar efectos de cuello de botella si el número de nodos es
grande. Cada solución debe elegirse en función de las
 28

necesidades del problema al que hacemos frente. El Linux Virtual

Server utiliza balanceo a nivel IP.

El proyecto Linux Virtual Server (LVS) ofrece parches y

aplicaciones de mantenimiento y gestión 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 código ipvs,
que es la herramienta más importante ofrecida por el proyecto
LVS. El director puede ser entendido en términos 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 comunicación entre el cliente y el
servidor real. Esta asociación entre cliente y servidor real va a
durar sólo lo que dure la conexión tcp establecida; cuando se
inicie una nueva conexión el director escogerá de nuevo un
servidor real que puede ser distinto del anterior. Así, si el servicio
ofrecido es una página web, el cliente podría obtener las
imágenes o los textos desde distintos servidores reales ocultos
por el servidor virtual.

Con esta arquitectura, además del balanceo de carga, estamos

permitiendo que los servidores reales individuales puedan ser
 29

extraídos del LVS, actualizados o reparados y devueltos al clúster

sin interrumpir la prestación de servicio.

Asimismo, el sistema es fácilmente escalable y la alta

disponibilidad en LVS se diseña utilizando software mon,
heartbeat, fake y coda, que se utilizan para gestionar la alta
disponibilidad y para mantener una gestión segura, la
comunicación (hearbeat) entre máquinas y un sistema de ficheros
tolerante a fallos, respectivamente.

2.1.4.1. Balanceadores hardware

Los balanceadores de carga de Hardware son máquinas con el

propósito específico 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
también 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. Quizás sea la principal
alternativa.
Barracuda Load Balancer, de Barracuda Networks.
Cisco Arrowpoint.
 30

2.1.4.2. Balanceadores software

Los balanceadores de software son servidores configurados para

realizar la tarea del balanceo. Esto implica instalar en un
computador, un sistema operativo y una aplicación 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 más potente para
el balanceo de carga, este servidor puede ser reciclado y utilizado
para otra tarea.

En cuanto a sus desventajas se tiene que estos balanceadores

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

2.1.4.3. Linux Virtual Server - LVS

Linux Virtual Server es una solución para poder implementar un

servidor virtual altamente escalable y en alta disponibilidad.

Esta solución consiste en un balanceador de carga, también

conocido como director, que será la máquina que será accesible
directamente para los clientes y luego tendremos los servidores
que serán aquellos que recibirán las peticiones de los clientes, vía
el balanceador de carga, y responderán a las peticiones. Para los
clientes, existirán solo los balanceadores de carga, los cuales
distribuirán la carga entre los servidores reales.
 31

Figura 2.8 Balanceadores de Carga

Se obtiene escalabilidad en el servicio añadiendo nodos, mientras

que la disponibilidad se lograra identificando al balanceador que
no funciona, y que el nodo añadido tome la función de
balanceador, para que el servicio no se vea interrumpido.

Esta solución nos permitirá tener el servicio funcionando casi

continuamente ya que no se verá afectado por posibles caídas de
las máquinas debido a fallos en el suministro eléctrico o bien
cortes en el ISP de una determinada granja.

Cualquiera de estos fallos, u otros que pudieran ocurrir, afectarán

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

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

encargará de distribuir la carga entre los servidores reales.
 32

La escalabilidad en el servicio la conseguiremos añadiendo

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

2.1.5. Detección de fallos en los nodos del clúster

Un clúster debe conocer cuando algún nodo no está disponible para

no enviarle peticiones de servicio. Por lo cual, un sistema de
detección de fallos en los nodos del Clúster es vital para su
funcionamiento.

Esto se hace de dos formas:

Heartbeat
Disco de quórum

2.1.5.1. Heartbeat

Figura 2.9 Heartbeat

 33

Es la técnica más habitual. Consiste en comunicarse o bien a través

de una interface de red o puerto serie cada cierto tiempo. Si se
pierde la comunicación durante un determinado tiempo se supone
que el nodo ha caído.

Para implementar esta técnica los nodos tiene líneas 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 envío y recepción de

señales enviadas por los demonios de Hearbeat que se ejecutan en
ambas máquinas, a estas señales 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
configuración de Heartbeat se haya colocado la directiva
auto_failback en off. Esta directiva puesta en off, quiere decir que si
la máquina 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

máquinas que imposibilita la llegada de latidos hacia el esclavo. Si
 34

sucede esto, el esclavo interpretará erróneamente que el servidor

maestro ha caído y tratara de tomar el control de la prestación del
servicio, cuando el servicio nunca ha dejado de prestarse.

2.1.5.2. Disco de quorum

Disco de quorum es una técnica complementaria que lo que se hace

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

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

pensará que los otros nodos no están 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 están
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 clúster. 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 están disponibles para hacerse
con el servicio en el clúster.

Importante
El disco de quorum no es una técnica que sustituya al heartbeat es
una técnica que debe usarse como complemento al heartbeat.
 35

Figura 2.10 Disco de Quorum

 36

CAPITULO 3

INTRODUCCION

En este capítulo se presentarán las soluciones de software libre para

mitigar el problema de alta disponibilidad y balanceo de carga, se
expondrán sus características así como las herramientas que hacen
posible la construcción de dichas soluciones.

Además se llevará a cabo una comparativa de las herramientas

existentes para la realización del clúster, además de ello, se describirán
tales herramientas de forma breve en cuanto a sus componentes y su
funcionamiento.

DIAGNOSTICO

3.1. Herramientas de open source para la construcción del Clúster

Podemos encontrar una amplia variedad de aplicaciones para la

creación de clústers, la utilización de una u otra de estas dependerá
de la complejidad de instalación, uso específico y ventajas de este
sobre otras herramientas. De las opciones que se pueden encontrar
están:

 openMosix.
 Oscar.
 Piranha.
 Linux Virtual Server.
 Ultramonkey.
A continuación la tabla 3.1 muestra las principales características de
cada herramienta para la construcción de clústers.
 37

Herramienta. Características.

 Parche al kernel de GNU/Linux.

 Algoritmo interno de balance de carga que migra
openMosix los procesos entre nodos.
 Migración de procesos totalmente transparente.
 Auto descubrimiento de nuevos nodos openMosix
en la red del clúster.

 Permite instalar un clúster tipo Beowulf.

 Contiene todo el conjunto de paquetes necesarios
OSCAR para programar y administrar el clúster.
 Formado por dos componentes principales SIS
(System Installation Suite) y ODA (OSCAR
Database API).

 Implementación de software de alta disponibilidad.

 Interfaz web para control completo del clúster.
Piranha  Posee herramientas para su monitorización.
 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 con
Linux Virtual Server – LVS sistema operativo GNU/Linux.
 Clúster completamente transparente al usuario
final.
 Mecanismo para que el clúster funcione con una IP
pública.

 Permite balance de carga y alta disponibilidad.

 Incluye monitorización de servidores reales y
nodos de balance.
 Permite el manejo de protocolos como HTTP, FTP,
 38

DNS, entre otros.

Ultramonkey  Permite usar iptables o ipchains para marcar los
paquetes que pertenezcan al servicio prestado por
el clúster.
 Usado desde clústers de dos nodos hasta grandes
sistemas.

Tabla 3.1 Características de Herramientas para Clústers.

Por último, se mostrarán las ventajas y desventajas de cada una de

las herramientas anteriormente mencionadas, pues es importante
tener presente esta comparativa para hacer una primera
aproximación a la elección de una sola herramienta para llevar a
cabo una implantación eficaz y sencilla que cubra las necesidades
solicitadas; esto se refleja en la tabla 3.2.

Herramienta. Ventaja. Desventaja.

 No se requieren paquetes  Depende del kernel.

adicionales.  No migra todos los
openMosix  No son necesarias procesos siempre.
modificaciones en el  Problemas con
código de openMosix. memoria compartida.
 Migración de procesos.

 Falla la detección de
algunos componentes
 Es una compilación auto de hardware en
instalable. versiones anteriores a
 Infraestructura de software la 3.
para instalar y administrar  Soporte para
OSCAR un clúster. distribuciones basadas
 Posee bibliotecas y en RPMs solamente

compiladores para uso en
clústers.
 Soporte por parte de Red
Hat Inc.
 Fácil instalación debido al
Piranha formato de distribución.
 Administración y manejo
mediante interfaz web.
 Monitorización de
servidores reales.
 Fácil comprensión de
funcionamiento.
 Amplia gama de
configuraciones.
Linux Virtual Server  Funciona a nivel TCP/IP.
- LVS  Manejo de varios tipos de
protocolos como HTTP,
DNS, FTP entre otros.
 Múltiples esquemas de
configuración.
 Reúne varias herramientas
de una manera sencilla.
 Varios formatos para su
instalación.
 Amplia documentación
sobre cada componente.
39
para versiones
anteriores a la 5.
 Requiere que la LAN no
sea usada para instalar
software en el clúster.
 Al momento solo
disponible para
versiones
empresariales de Red
Hat.
 Dependiente del
sistema operativo Red
Hat Enterprise.
 Algunos esquemas se
ven afectados por la
cantidad de servidores
reales que se pueden
utilizar.
 Cuando el número de
servidores reales es
elevado se genera
mucho tráfico en la red
de trabajo.
 Los nodos directores
tienen que ejecutar
estrictamente el
sistema operativo
GNU/Linux.
 40

Ultramonkey  Instrucciones de  Según el esquema de

instalación para las
distribuciones de
GNU/Linux más comunes
en servidores.
 Se apoya en el proyecto
LVS para algunos
componentes.
 No es dependiente de una
distribución de GNU/Linux
en particular.
configuración puede
llegar a ser complejo.
 Mismas que en LVS
para los componentes
que sean utilizados de
dicho proyecto.

Tabla 3.2 Ventajas y Desventajas de las Herramientas para Clúster.

3.2. Comparación de las herramientas de balanceo de carga y alta

disponibilidad

Formato Distribucione Balanceo de

Herramient de s Soportadas carga y Alta Ventajas Desventajas
a Distribució disponibilidad
n

No requiere Dependiente
Balanceo de paquetes del kernel y
openMosix RPM, Todas. carga de adicionales y posee
Código procesos sin hace problemas con
fuente. alta migración de memoria
disponibilidad. procesos. compartida.

En versiones
anteriores a la
tercera falla la
Auto instalable detección de
 41

RPM, Red Hat y Balanceo de con bibliotecas hardware y no

OSCAR Código basadas en carga de y permite usar la
fuente. esta. procesos sin compiladores red interna
alta para computo para
disponibilidad. paralelo. instalación de
software.

Soporte de Actualmente
Red Hat Posee Red Hat, disponible solo
Piranha RPM. Enterprise 4 o herramientas administración en formato
posteriores. propias para y manejo RPM y para
ambos mediante versiones
aspectos. interfaz web. empresariales.

Instalación por
Amplia gama segmentos;
Incluye de con un gran
Linux RPM, DEB, Todas. herramientas configuracione número de
Virtual Código de código s, función a servidores
Server fuente. abierto para nivel TCP/IP y reales el
ambos manejo de tráfico crece
aspectos. distintos de manera
protocolos. significativa.

Los nodos de
Múltiples balance de
Basadas en Uso de configuracione carga deberán
Debian, Red componentes s, manejo de ejecutar el
Hat Enterprise de LVS para distintos sistema
RPM. DEB, 4 y mediante ambos protocolos, operativo
Ultramonke Código compilación aspectos función a nivel GNU/Linux;
y fuente. de código añadiendo TCP/IP, dependiendo
fuente. algunas marcas de del esquema
mejoras y firewall y llega a ser
 42

herramientas. ampliación de complejo de

LVS. configurar.

Tabla 3.3 Comparación de herramientas para clúster.

Una de las herramientas las más usadas es Piranha de la empresa

Red Hat., que incorpora balance de carga mediante direcciones IP y
también hace la inclusión de código del proyecto LVS, en esta
herramienta Red Hat incorporó mejoras; para poder hacer uso
eficiente de Piranha es recomendado el uso de Red Hat Enterprise
Linux 4 o posterior, su sencillez en instalación y amplio soporte por
parte de dicha empresa brinda satisfacción al hacer una
implementación con esta. Fuera del pago de la licencia para el
sistema operativo el software de Piranha está disponible de manera
gratuita para usuarios registrados de esta distribución.

Junto a la anterior herramienta se puede encontrar el proyecto LVS

el cual fue iniciado por Wensong Zhang en Mayo de 1998 y su
principal objetivo era desarrollar un servidor GNU/Linux de alto
rendimiento que proporcione un buena escalabilidad, confianza y
robustez usando la tecnología de clúster. De los avances más
importantes de LVS es el desarrollo de un sistema IP avanzado de
balanceo de carga por software (IPVS), balance de carga por
software a nivel de aplicación y componentes para la gestión de
clúster. Se puede usar LVS como solución para construir sistemas
altamente escalables, donde se garantiza una alta disponibilidad de
los servicios de red como el correo electrónico, voz sobre IP y el
servicio web.

La siguiente opción es Ultramonkey, siendo una de las herramientas

más completas en cuanto a balanceo de carga y alta disponibilidad;
ya en su tercera versión cuenta con formatos de instalación para
 43

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

herramienta solo puede ser usada en estaciones cuyo sistema
operativo sea GNU/Linux siendo este uno de sus pocos
inconvenientes en lo que respecta a la independencia de plataforma.
Hace uso de las tecnologías 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 configuración se
cuenta con soluciones separadas o una que incorpore ambas, así
como también un esquema estándar o uno más completo.

La herramienta OSCAR es una colección de software de código

abierto para crear un clúster sobre GNU/Linux desarrollada por el
Grupo de Clústers Abiertos (OCG – Open Clúster Group). El objetivo
primario del grupo de trabajo OSCAR es conseguir que la
instalación, la configuración y la administración de un clúster de
tamaño modesto, sea fácil. Cualquier cosa necesaria para un clúster
como instalación y configuración, mantenimiento, programación
(paralela), sistemas de encolamiento, programación de tareas, está
incluida en OSCAR. Su principal labor es para cómputo de alto
rendimiento.

En Open Mosix los procesos no saben en qué nodo del clúster se

ejecutan, y es el propio Open Mosix el responsable de "engañarlos",
y redirigir las llamadas al sistema al nodo del clúster en el que se
lanzó el proceso. Open Mosix implementa un algoritmo de balance
de carga que permite repartir de forma óptima la carga, si está el
clúster bien calibrado. Open Mosix puede migrar cualquier proceso
mientras que no haga uso de los segmentos de memoria
compartida. Según la calibración, migrarán procesos más ligeros, o
más pesados.
 44

Dadas las características vistas con anterioridad en la tabla 3.3 y

esto aunado a los fines que persiguen hacen inclinar la balanza por
las siguientes opciones mejor adaptadas a este campo que son:
 Piranha.
 Linux Virtual Server.
 Ultramonkey.

Se procederá ahora a describir cada una de las tres herramientas

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

3.2.1. Herramientas de balanceo de carga y alta disponibilidad

3.2.1.1. Piranha

Es un conjunto de aplicaciones en un ambiente bien unido para los

administradores que desean instalar servicios de clúster en
ambientes GNU/Linux. Un clúster piranha se compone de los
siguientes elementos:

 El parche IPVS para el kernel.

 El demonio LVS para manejar las tablas IPVS a través de
ipvsadm.
 El demonio nanny para monitorizar servicios y servidores.
 El demonio pulse para controlar el estado del resto de
demonios del clúster y la entrada en funcionamiento del nodo
de balance de carga de respaldo en caso de fallo del primario.
 La interfaz gráfica piranha para administrar el clúster.

Todos estos demonios utilizan el mismo archivo de configuración

ubicado en el directorio /etc/lvs.cf para su funcionamiento. Como un
valor añadido a piranha este es capaz de adaptar los pesos de los
algoritmos de planificación automáticamente según las estadísticas
 45

de funcionamiento de cada servidor. En la figura 3.1 se aprecia

cómo se compone un clúster con Piranha.

Figura 3.1 Esquema de funcionamiento de Piranha.

3.2.1.2. Linux Virtual Server

Es un software para el balanceo de carga que permite crear un

clúster de forma rápida y eficaz sin hacer grandes inversiones en
hardware dedicado. Es una solución ideal para aquellas empresas
que quieren ahorrar costos permitiendo tener tras una única
dirección IP pública 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 migración de sockets. Un
clúster de este tipo está formado por dos tipos de máquinas, los
nodos o servidores reales que corren con los servicios habituales
que estos suelen proveer y los nodos directores o de balanceo de
 46

los cuales uno de ellos será el principal y el resto estarán 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 información.

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

método en que el nodo de balanceo retransmitirá las
comunicaciones provenientes de los usuarios a los servidores reales
definidos.
LVS permite balancear muchos protocolos distintos. LVS se ha
usado con HTTP, HTTPS, FTP, etc. En la figura 1.10 se muestra su
funcionamiento.

Figura 3.2 Esquema de funcionamiento de LVS.

 47

3.2.1.3. Ultramonkey

Es un proyecto que integra diferentes herramientas de software libre

para conseguir alta disponibilidad y balanceo de carga en redes LAN
redes de área local. Estas herramientas son: LVS, Heartbeat,
Ldirectord y MON como lo muestra la figura 3.3.

3.2.1.3.1. Componentes Ultramonkey

LVS realiza balanceo de carga y facilita la alta disponibilidad entre

los servidores reales. Sin embargo, el nodo de balanceo de carga se
convierte en un punto único de fallo, si se quiere alta disponibilidad
se deberá añadir otro nodo de balanceo de respaldo y usar software
de alta disponibilidad que le permita tomar el papel del nodo de
balanceo de carga principal.

3.2.1.3.1.1. Heartbeat

Funciona enviando periódicamente un paquete, que si no llegara,

indicaría que un servidor no está disponible, por lo tanto se sabe que
el servidor ha caído y se toman las medidas necesarias. Se
recomienda el uso de puertos serie puesto que están aislados de las
tarjetas de red. Soporta múltiples direcciones IP y un modelo
servidor primario/secundario.

Los mensajes de Heartbeat se envían por todas las líneas de

comunicación a la vez, de esta manera, si una línea de apoyo cae,
se avisará de ese problema antes de que la línea principal caiga y no
haya una línea secundaria para continuar el servicio. Heartbeat
también se preocupa por la seguridad, permitiendo firmar los
paquetes con CRC de 32 bits, MD5 y SHA1.
 48

3.2.1.3.1.2. Ldirectord

Se encarga de monitorizar que los servidores reales permanezcan

funcionando periódicamente, enviando una petición a una dirección
URL (Uniform Resource Locator) conocida y comprobando que la
respuesta contenga una cadena concreta. Si un servidor real falla,
entonces el servidor es quitado del conjunto de servidores reales y
será reinsertado cuando vuelva a funcionar correctamente. Si todos
los servidores fallan, se insertará un servidor de fallos, que será
quitado una vez que los servidores vuelvan a funcionar.

3.2.1.3.1.3. Mon (Service Monitoring Daemon)

Es un software para la monitorización 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
monitorización 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 clúster para
 49

virtualmente cualquier red de servicios corriendo en un sistema

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

La figura 3.4 muestra un esquema típico de funcionamiento de

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

Figura 3.4 Esquema de funcionamiento de Ultramonkey.

 50

CAPITULO 4

INTRODUCCION

En este capítulo se llevará a cabo un análisis de los métodos

existentes de balanceo de carga, dado que estos llegan a ser
complejos solamente se tratará la teoría más básica de operación;
adicionalmente se realizará la toma de decisión de una herramienta
para su implementación.

DISEÑO

4.1. Tipos de balanceo de carga

Existen dos formas simples para montar un clúster y distribuir la

carga entre los equipos mostradas en la tabla 4.1 a continuación.

Método Ventajas Desventajas

El cache de la
información en la
Distribución de la carga jerarquía de
DNS entre servidores reales servidores DNS y la
Round – de forma pseudo- forma simple de
Robin. aleatoria. tomar decisiones por
Es el más simple de parte del servidor
implementar. DNS restringen su
utilidad.
“Los servidores no
pueden ser
 51

seleccionados según
el URL solicitado.”4
Este nodo distribuye las Llega a convertirse
conexiones. en cuello de botella.
Se aumenta la Hace uso de un nodo
Uso de nodo sensación de unidad adicional para
de balanceo del clúster. proveer el balanceo
de carga. Única dirección IP de carga.
pública a la cual dirigir Al existir solo un
las peticiones. nodo de balanceo
Es sencillo enmascarar este se convierte en
fallas de los servidores. un punto único de
fallo.

Tabla 4.1 Métodos de balanceo de carga.

4.1.1. Modos de balanceo de carga en LVS

LVS permite realizar el reenvío de paquetes a los servidores

reales de tres formas. En la tabla 4.2 se muestran los tres modos
de balanceo.

Modo de Ventajas Desventajas

balanceo
Aprovecha la El nodo de
posibilidad del kernel balanceo se llega a
de Linux de funcionar convertir en cuello
como router con NAT. de botella.
Balanceo Los servidores reales Tiene que reescribir
mediante NAT. pueden ejecutar todos los paquetes
(Network

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

Address cualquier sistema TCP/IP.

Translation). operativo que soporte Número de
TCP/IP. servidores reales
Uso de solamente dependiente de la
una dirección IP velocidad de
pública. conexión del nodo
de balanceo.
No todos los
Escalado de hasta sistemas operativos
Balanceo 100 servidores o más. son soportados por
mediante Se evita que el nodo este modo.
encapsulado IP de balanceo se Los servidores
(IP Tunneling) convierta en cuello de reales necesitan
botella. tener una IP
pública.
Todos los
servidores deben
poseer una IP
Balanceo El nodo de balanceo pública en el mismo
mediante no es cuello de segmento de red
enrutamiento botella. del nodo de
directo (Direct No se sobrecarga al balanceo.
Routing) nodo de balanceo en No todos los
reescribir paquetes sistemas operativos
TCP/IP. permiten configurar
una IP o dispositivo
para responder a
comandos ARP.

Tabla 4.2 Modos de balanceo de carga en LVS.

 53

Balanceo mediante NAT

“NAT (es un mecanismo utilizado por routers IP para intercambiar
paquetes entre dos redes que se asignan mutuamente
direcciones incompatibles. Consiste en convertir en tiempo real
las direcciones utilizadas en los paquetes transportados. También
es necesario editar los paquetes para permitir la operación de
protocolos que incluyen información de direcciones dentro de la
conversación del protocolo)”.5
A continuación se explica mediante figuras el funcionamiento de
cada uno de los modos de balanceo, en la figura 4.1 siguiente se
puede ver todo el proceso para el modo NAT:

Figura 4.1 Balanceo mediante NAT.

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

Balanceo mediante encapsulamiento IP

De acuerdo a la figura 4.2 el proceso es el siguiente:
1. El usuario realiza una petición de servicio a la IP pública
del clúster (la del nodo de balanceo de carga o IP virtual
del clúster).
2. El nodo de balanceo planifica a qué servidor real se va a
enviar la petición, reescribe las cabeceras de las tramas
TCP/IP y las envía al servidor.
3. El servidor recibe la petición, la procesa, genera la
respuesta y la envía 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
envía de vuelta al usuario.
5. La respuesta llega al usuario, como si la hubiese generado
la IP pública del clúster.
En el modo de balanceo por encapsulamiento IP, su función se
ilustra a continuación con la figura 4.2:
 55

Figura 4.2 Balanceo mediante encapsulado IP.

El nodo de balanceo recibe todas las conexiones de entrada al

clúster, y decide a qué servidor enviárselas. 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 pública del clúster como propia, acepta la trama original y se
encarga de servir la petición que contuviera enviando éste
servidor la respuesta al cliente directamente.

Balanceo mediante enrutamiento Directo

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

Figura 4.3 Balanceo mediante enrutamiento directo.

 56

Todos los equipos tendrán configurado una interfaz con la IP

pública del clúster: el nodo de balanceo la tendrá en su acceso a
Internet y será el punto de entrada al clúster; el resto de equipos
estarán conectados al nodo de balanceo en la misma red física y
en la interfaz conectada a ésta red tendrán configurada la IP
pública del clúster, pero configurando la interfaz para que no
responda a comandos ARP (todos los equipos responderían por
la misma IP con distintas direcciones físicas). Al llegar una
petición al nodo de balanceo éste decide a qué servidor
enviársela y redirige el paquete a nivel de enlace a la dirección
física del servidor elegido en lugar de modificar o encapsular el
paquete TCP/IP. Cuando llega al servidor con la dirección física
de destino y se analiza hasta el nivel de red (TCP/IP), como el
servidor también tiene configurada la IP pública del clúster, acepta
sin más el paquete y genera la respuesta que enviará
directamente al cliente.

4.1.2. Resumen de los métodos de balanceo

En la tabla 4.3 a continuación se resumen las características

principales de los tres métodos de direccionamiento que puede
utilizar el balanceador de carga de Linux Virtual Server:

Enrutamiento
NAT Encapsulamiento IP
Directo

Necesita
Servidor Cualquiera Dispositivo no-ARP
Encapsulamiento

Red de
Red Privada LAN/WAN LAN
servidores
 57

Escalabilidad Baja (10~20) Alta Alta

Salida hacia Nodo de

Router Router
Internet balanceo

Tabla 4.3 Métodos de direccionamiento.

4.1.3. Planificación del balanceo de carga

Al momento de configurar el nodo de balanceo se podrá elegir

entre una serie de algoritmos para ver cómo se distribuirá la carga
entre los servidores y cómo se elegirá el servidor al que se envía
cada petición. Linux Virtual Server permite utilizar los siguientes
algoritmos que se muestran en la tabla 4.4:

Algoritmo Funcionamiento
Cada petición se envía a un servidor y la siguiente
Round Robin petición al siguiente servidor de la lista hasta llegar al
último tras lo cual se vuelve a enviar al primero, véase la
figura 4.4.
Igual que el anterior algoritmo pero añadiendo un peso a
cada servidor, este peso es un entero que indica la
Round Robin potencia de cálculo del servidor, de modo que la cola
Ponderado Round Robin se modificará para que aquellos servidores
con mayor capacidad de cálculo reciban peticiones más
a menudo que el resto, véase la figura 4.5.
Este mecanismo de distribución consulta a los servidores
Servidor con para revisar en cada momento cuántas conexiones
menos abiertas posee cada uno con los clientes, y envía cada
conexiones petición al servidor que menos conexiones tenga en ese
activas. momento, véase la figura 4.6.
Servidor con Igual que el algoritmo anterior pero se le añaden pesos a
 58

menos los servidores para que de alguna forma se mida su

conexiones capacidad de cálculo para modificar la preferencia al
activas momento de hacer una elección, véase la figura 4.7.
Ponderado.
Este algoritmo dirige todas las peticiones a un mismo
Menos servidor, hasta que se sobrecarga (su número de
conectado conexiones activas es mayor que su peso) y entonces
basado en pasa a una estrategia de menos conexiones activas
servicio. ponderada sobre el resto de servidores del clúster,
véase la figura 4.8.
En estos algoritmos se dispone de una tabla de
Tablas Hash por asignaciones fijas, en las que bien por la IP de origen o
origen y destino. destino, se indica qué servidor deberá atender la
petición. El nodo de balanceo compara las direcciones
de las tramas TCP/IP que reciba con estas tablas y
actúa en consecuencia, véase la figura 4.9.
Conexiones A todos los algoritmos de planificación anteriores se les
Persistentes. puede añadir el hecho cuando un cliente se ha
conectado con un servidor, siempre se le dirija al mismo
servidor.

Tabla 4.4 Algoritmos de planificación de balanceo de carga.

 59

Figura 4.4 Round Robin.

Figura 4.5 Round Robin Ponderado.

 60

Figura 4.6 Servidor con menos conexiones activas.

Figura 4.7 Servidor con menos conexiones activas ponderado.

 61

Figura 4.8 Menos conectado basado en servicio.

Figura 4.9 Tablas Hash por origen y destino.

 62

La elección de una u otra técnica depende principalmente del

servicio que se quiera proveer, los conocimientos que se posean
de los sistemas, el sistema operativo de los servidores, los
recursos económicos que se estén dispuestos a gastar, y
consideraciones de rendimiento que afectan al sistema en
conjunto.

4.2. Elección de una herramienta para balanceo de carga y alta

disponibilidad

Para poder tomar una decisión acerca de cuál herramienta es la

mejor opción se debe tomar en cuenta factores como: estabilidad,
fiabilidad, costos de implementación (tanto en hardware como en
conocimientos), escalabilidad entre otros. Como parámetros para
poder evaluar dichas herramientas se usará la cantidad de
requisitos por cada herramienta, facilidad de comprensión e
implementación así como también su disponibilidad para su
adquisición. Las herramientas evaluadas son Piranha, Linux
Virtual Server y Ultramonkey.

Como punto de partida se compararán los requisitos mínimos

para la implementación de cada una en cuanto a los equipos que
actúan como coordinadores o directores.

Piranha:
Esta herramienta solamente requiere el uso de un navegador web
para configurarse pero una de sus críticas es el hecho de estar
fuertemente ligada a las versiones empresariales de Red Hat y
por tal motivo los mínimos en hardware dependerán de la versión
de dicha distribución que se utilice. Como un punto a favor,
Piranha posee esa extrema sencillez de configuración brindada
por su interfaz que se basa en web. Para implementarse se tiene
que poseer una licencia de uso del sistema operativo de Red Hat
 63

y en particular de una versión empresarial. La tabla 4.5 muestra

los requisitos mínimos de hardware requeridos.

Procesador Pentium II 300 MHz

Memoria RAM 64 MB

Espacio en Disco Duro +2 GB recomendado

Interfaz de Red 10 Mbps

Tabla 4.5 Requisitos mínimos de hardware para Piranha.

Linux Virtual Server:

Este es muy simple de implementar y debido a sus características
los nodos directores o de balanceo pueden poseer o no una
interfaz gráfica ya que su administración es vía línea 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
distribución del sistema operativo (siempre y cuando sea
GNU/Linux, la distribución puede variar) pues está más ligado con
el kernel que con la distribución. Para su implementación bastará
con un equipo que cubra los mínimos requisitos en hardware para
una distribución basada en un kernel 2.4.27 o superior siendo un
ejemplo el de la tabla 4.6.

Procesador Pentium MMX 166 MHz

Memoria RAM 64 MB

Espacio en Disco Duro +1 GB (sin interfaz gráfica)

Interfaz de Red 10 Mbps

 64

Tabla 4.6 Requisitos mínimos de hardware para LVS.

Ultramonkey:
Ultramonkey está pensado como una solución muy económica
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
gurúes de la informática. En la tabla 4.7 siguiente se aprecian los
mínimos de hardware para ultramonkey.

Procesador Pentium MMX 166 MHz

Memoria RAM 64 MB

Espacio en Disco Duro +512 MB (recomendados +1GB)

Interfaz de Red 10 Mbps

Tabla 4.7 Requisitos mínimos de hardware para Ultramonkey.

Se concluye que Ultramonkey es la herramienta que requiere la

menor cantidad de recursos para su instalación y funcionamiento,
la tabla 4.8 compara los requisitos mínimos de hardware de
Piranha, LVS y Ultramonkey.

Memori Espacio Interfaz

Herramienta. Procesador. a RAM. en de Red.
Disco
Duro.
Piranha. Pentium II 300MHz 64 MB +2GB 10
Mbps
 65

LVS. Pentium MMX 64 MB +1GB 10

166MHz Mbps
Ultramonkey. Pentium MMX 64 MB +512MB 10
166MHz Mbps

Tabla 4.8 Comparación de requisitos.

El siguiente punto a evaluar es la complejidad de instalación,

tómese en cuenta que todos los parámetros que se están
evaluando son sobre los nodos principales, sin tomar en cuenta
los servidores reales.

Ultramonkey:
Esta es la herramienta más simple de instalación 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 actúa como nodo director
posee un sistema diferente tendrá que llevarse a cabo la
instalación de dos formas distintas dependiendo de:
Basado en Red Hat: mediante paquetes RPM con la
instrucción “rpm -iv *.rpm” estando dentro del directorio
que contenga todos los paquetes de Ultramonkey.
Basados en código fuente: tendrán que descargarse
todos los paquetes que conformen Ultramonkey, luego
se procede a descomprimir cada uno y posteriormente
se procede a su compilación e instalación.

Piranha:
Esta herramienta es sencilla de instalar si se posee una licencia
del sistema operativo Red Hat Enterprise utilizado, su instalación
puede realizarme mediante un administrador de paquetes gráfico
propio del sistema operativo o bien, mediante la línea de
comandos con el administrador indicado (en este caso yum). De
 66

no poseer tal licencia se deben adquirir los paquetes por separado

y proceder con una instalación manual en la cual dependerá el
tipo de paquete adquirido, si es en formato RPM o en forma de
código fuente. La instalación 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 instalación.

LVS:
Para llevar a cabo la instalación de LVS es necesario activar los
módulos de LVS en el kernel de la distribución utilizada,
posteriormente se debe instalar la aplicación ipvsadm pues esta
será nuestra interfaz de comunicación con LVS. Una vez activado
el soporte y la interfaz con LVS se procede a su configuración y
pruebas pertinentes. Es importante notar que de no contar con un
kernel con soporte activado las alternativas existentes son una
recompilación del mismo kernel o la compilación de uno
totalmente nuevo habilitando dicho soporte en ambos casos; si la
distribución utilizada posee mecanismos para instalar un kernel
con soporte incluido esto facilita la tarea, de otra manera el
proceso de configuración, activación del soporte, compilación e
instalación deberá realizarse de forma manual.

Se concluye que Ultramonkey es la herramienta que posee los

mecanismos de instalación más simplificados, ahorrando tiempo y
esfuerzo dada la automatización 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 métodos que posee
cada una para su distribución.
 67

Ultramonkey:
Este proyecto es de fácil adquisición 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
gestión de paquetes hará notar que debe instalar otros paquetes
que son dependencias y ubicará los archivos en los sitios
correspondientes; esta es la manera más fácil de instalar
Ultramonkey, es limpia, rápida y muy eficiente. Si se desea
instalar sobre una distribución 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 instalación de forma manual,
en caso de usar una distribución 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 distribución y adquisición para
varios sistemas operativos GNU/Linux eliminando la restricción de
dependencia de una distribución en especial. Aunque LVS se
distribuye como código fuente y Piranha en paquetes RPM o
código fuente, la herramienta Ultramonkey brinda una mejor
variedad de formatos y medios de adquisición siendo este punto
el que le brinda ventaja sobre las anteriores y siendo esta la mejor
elección.

Como se puede apreciar por estos tres indicadores, la mejor

opción para elección es Ultramonkey debido a su sistema de
instalación, variedad de formatos de distribución así como sus
requisitos mínimos de hardware muy bajos. Sin duda las otras
opciones son muy viables, pero presentan limitantes; con esto
presente queda establecido que la mejor opción para
 68

implementación es Ultramonkey ya que está bien acoplado con la

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

CAPITULO 5

INTRODUCCION

Este capítulo tiene como finalidad describir la manera de cómo se lleva a

cabo el proceso de construcción del clúster, así como también de hacer
notar cuales aspectos se deberán tomar en cuenta para su
configuración.

IMPLEMENTACION EN MAQUINAS VIRTUALES

5.1 INSTALACION Y CONFIGURACION DEL CLUSTER

El clúster funcionará de la siguiente manera (figura 5.1), el usuario

realizará una petición de una página web al servicio (el usuario
desconoce que se trata de un clúster), al llegar la petición al nodo de
balance este redireccionará dicha petición a uno de los servidores reales
mediante al algoritmo de balanceo de carga establecido. El servidor real
que atiende dicha petición tiene como origen de la misma al nodo de
balanceo y no al usuario debido al método 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 envía al
usuario que la solicitó teniendo como su dirección la IP virtual del clúster
y no la IP real del nodo de balanceo, esto es así porque al hacer el
cliente la petición, se hace a la IP virtual del clúster y es de esta misma
dirección de donde se obtiene la respuesta haciendo creer al usuario
que es atendido por un solo equipo y no por un clúster. Tabla 5.1.

En caso de existir una falla en uno de los servidores reales el

balanceador verifica cuál se encuentra brindando el servicio y lo
direccion hacia dicho servidor. Para el usuario esto es transparente ya
que no afecta el servicio simplemente se ve afectado el rendimiento pero
nunca en una pérdida de servicio, ésta se da cuando todos los nodos
servidores fallan.
 70

Figura 5.1 Funcionamiento del Clúster.

Se hace una petición de página a la IP virtual del clúster.

La petición se envía al nodo de balanceo, éste mediante un
algoritmo envía la petición al servidor real correspondiente.
El servidor real que recibe la petición la procesa y envía el
resultado al nodo de balanceo.
El nodo de balanceo envía la respuesta a la petición al cliente
indicando que la dirección IP del paquete que sale es la IP
virtual del clúster y no la IP del nodo de balanceo.
El cliente recibe la respuesta a su petición por parte de la IP
virtual del clúster, el cliente en ningún momento se da cuenta
que es atendido por un clúster.
Tabla 5.1 Funcionamiento del Clúster.
 71

5.1.1 SELECCIÓN DE NODOS PARA EL CLÚSTER

Para la selección de los nodos que conforman el clúster es importante

hacer notar que aquellos destinados a tomar la función de nodos de
balanceo no necesariamente serán los de mayores prestaciones (con
mayores recursos), con esto en mente se procederá a listar los
componentes primordiales para dicha elección. Primero los nodos que
actuarán como nodos de balanceo tendrán, como mínimo, 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 instalación).

Tabla 5.2 Especificaciones del nodo de balanceo.

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

estos deberán contar con una mayor capacidad que los nodos de
balanceo pues son estos los que realizan el verdadero trabajo de
atención a usuarios. Los requisitos mínimos 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 instalación).

 72

Tabla 5.3 Especificaciones de nodo servidor.

A continuación la tabla 5.4 indica las herramientas utilizadas para los

nodos de balanceo, nodos servidores y los nodos clientes.

Tipo de Nodo Herramientas Utilizadas

Sistema Operativo (Windows, etc.)

Navegador Web.
Cliente

Sistema Operativo GNU/Linux CentOs 5.3.

Aplicaciones IPROUTE, IPTABLES, TCPDUMP
[Tcpdump].
Balanceo de Editor de textos VIM.
Carga

Sistema Operativo GNU/Linux CentOs 5.3.

Aplicaciones IPROUTE, IP RULE e IPTABLES.
Editor de textos VIM.
Servidor Real Servidor de páginas web Apache2.

Tabla 5.4 Herramientas utilizadas en cada nodo.

Herramienta. Características. Características Principales.

Balanceo de carga.
Escalabilidad.
Bajo consumo de recursos.
Diversos esquemas de Balanceo de carga.
configuración. Alta disponibilidad.
Suite
 73

Ultramonkey Manejo de diversos protocolos Escalabilidad.

como HTTP, FTP, etc.
Crear y editar archivos de texto.
Manejo de pestañas para múltiples
documentos.
Uso de números de línea. Crear y editar archivos
Búsqueda de patrones dentro del de texto.
Editor de textos
documento. Uso de números de
VIM.
Ejecución de comandos sin salir línea.
del editor. Búsqueda de patrones
dentro del documento.
Soporte de lenguajes de
programación mediante módulos.
Soporte de módulos
Soporte para HTTPS.
para lenguajes y otras
Servidor de Soporte para SSL (Secure Socket
aplicaciones.
Páginas web Layer) mediante módulo.
Soporte de SSL.
Apache2. Permite crear host virtuales.
Creación de host
Amplia gama de configuraciones.
virtuales.
Calidad de servicio.
Mantenimiento de varias tablas de
Balanceo de carga.
ruteo.
Mantenimiento de varias
Aplicación Balanceo de carga.
tablas de ruteo.
IPROUTE. Definición de túneles.

Permite interceptar y manejar

paquetes de red.
Permite el manejo de paquetes en
diferentes estados del Intercepción y manejo
procesamiento. de paquetes de red.
Permite construir firewalls basados Construcción de
Aplicación en GNU/Linux. firewalls basados en
 74

IPTABLES. Realiza traducción de direcciones GNU/Linux.

(NAT). Traducción de
direcciones (NAT).
Permite depurar aplicaciones que
utilizan la red para comunicar.
Permite depurar la red misma.
Aplicación Permite capturar y leer datos Permite capturar y leer
TCPDUMP. enviados por otros usuarios o datos enviados por otros
computadoras. usuarios o
computadoras.

Tabla 5.5 Características de herramientas utilizadas.

5.1.2 Instalación 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 instalación se
llevará a cabo en dos partes, la primera comprende la instalación del
sistema operativo tanto en nodos de balanceo como en nodos servidores
y la segunda parte comprende la instalación del software para el
balanceo de carga.

En cuanto a la primer parte que comprende la instalación del sistema

operativo, se debe tomar en cuenta que se realiza con un entorno
gráfico, por tanto se procederá conforme a la tabla 5.6.

Proceso de instalación del Sistema Operativo.

 Creación de máquina virtual en VMware

 Selección de medio de instalación.
 Proceso de instalación del sistema base.
 Instalación de paquetes adicionales.

Tabla 5.6 Proceso de instalación del Sistema Operativo.

 75

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

instalación como pueden ser los listados en la tabla 5.7.

Medios de Instalación.

 DVDROM básico para instalación mediante red.

 DVD del juego de la distribución.
 Juego completo de discos de la distribución.
 Archivo ISO guardado en el disco de la máquina virtual

Tabla 5.7 Medios de instalación.

Es importante contar con una conexión a Internet para hacer las

actualizaciones pertinentes y facilitar la instalación de la herramienta de
balanceo de carga.

El segundo punto, la instalación del sistema base cuyo proceso se cubre

en la tabla 5.8 a continuación:

Aspecto. Descripción.

Debe especificarse a qué zona horaria pertenece el

servidor seleccionando el país/estado/ciudad en
Zona Horaria.
donde se ubica el servidor y esto ajustará el reloj del
sistema sin necesidad de saber la franja horaria.

Contraseña de Simplemente se pedirán las contraseñas para la

administrador y cuenta de administrador y la(s) cuenta(s) de los
usuario(s). usuarios comunes que utilizarán el sistema.

Muestra las opciones de configuración automática

mediante el protocolo DHCP; de forma manual en la
 76

cual se proporcionan datos como la dirección IP y la

puerta de enlace y por último permite dejar de
Configuración de la
momento sin configuración la interfaz de red.
red.

Aquí se marcarán aquellos servicios que sean

necesarios de los presentes en la lista mostrada, si
Selección de
alguno no se encuentra en dicha lista, posteriormente
aplicaciones.
se podrá instalar. Algunos de estos servicios son
bases de datos y servidores web.

Tabla 5.8 Proceso de instalación del sistema base.

El resto del proceso de instalación y detalles relacionados se cubren en

el anexo 1 (Instalación del sistema operativo en maquinas virtuales). La
tabla 5.9 a continuación muestra los servicios que se deberán activar en
los nodos servidores.

 Servidor de páginas web Apache.

 Editor de textos VIM.
 Aplicaciones IPROUTE e IPTABLES.

Tabla 5.9 Servicios activados en los nodos servidores.

5.1.3. Configuración de los servidores web

Los servidores reales deben ser configurados para ejecutar el servicio

web provisto por el clúster usando como aplicación para tal efecto un
software como Apache.

Cuando se trabaja con servidores web es altamente recomendable hacer

uso de direcciones IP estáticas y para ello se debe editar la
configuración 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 dirección IP virtual dado que estos no responden al cliente de
 77

manera directa (ver figura 5.1). Para ello el servidor real deberá contar
con la aplicación iproute (ésta aplicación se compone de un conjunto de
herramientas muy potentes para administrar interfaces de red y
conexiones en sistemas GNU/Linux).

Las características que brinda esta configuración 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
más trabajo a un servidor con mayor capacidad que otro, repartir el total
de conexiones si todos los servidores son iguales en características para
no saturar ninguno y poder atender de manera eficiente al usuario final.

Después 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 señalar 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
también cierto grado en los servidores reales pues aunque con solo un
servidor real se puede todavía brindar el servicio, en realidad no existe
ningún 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 través
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
conexión será abandonada.
 78

Figura 5.2. Configuración final de nodos.

5.2. Instalación de CentOs

Para la instalación del sistema operativo utilizado (CentOs 5.3), es

necesario tener el dvd con la distribución respectiva, para el caso de
este proyecto se utilizó el archivo ISO de la distribución el mismo que se
lo tiene guardado en un directorio del equipo principal. Cabe señalar que
se utilizó en software de virtualización VMware Workstation en la versión
6.0.0. Este proceso se lo realizó para todos los servidores utilizados en
el proyecto.

El proceso de instalación del sistema operativo CentOs se encuentra

detallado en el Anexo 1 Instalación de CentOs.

5.3. Instalación de Ultramonkey

En cuanto a los medios de instalación de Ultramonkey, los podemos

encontrar en forma de paquetes de código fuente, paquetes pre-
 79

compilados que se pueden descargar desde la página web del proyecto

y también en el repositorio siguiente:

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

La manera más sencilla de llevar a cabo la instalación ejecutar como

superusuario el comando yum install para instalar la lista de paquetes
disponibles. Este método es el que se utilizará para su instalación.

Si no se cuenta con una conexión 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 página del proyecto, en este caso se entraría a la sección de
descargas y se especifica que los paquetes a descargar son para la
distribución GNU/Linux Redhat (cabe señalar que CentOs es la versión
liberada de Redhat Enterprise, por esta razón su usan los paquetes
disponibles para Redhat).

Por último se puede optar por adquirir los paquetes en formato de código
fuente comprimidos, una vez descargados se procederá a copiarlos en la
estación donde se necesiten y se llevará a cabo todo el proceso de
compilación e instalación.

Como se puede apreciar, existen métodos de instalación para casi todas

las distribuciones o preferencias; la mejor forma es mediante los
repositorios, pero si se desea conservar un respaldo de dichos paquetes
se sugiere su descarga y posterior respaldo en medios como discos
compactos o en un servidor de respaldos.

5.3.1. Selección de topología de instalación de ultamonkey

Aquí se determina como instalar la solución de alta disponibilidad y

balanceo de carga que provee Ultramonkey de acuerdo a un esquema
determinado, posteriormente se detallará el proceso de instalación.

Como muestra la figura 5.2. “Configuración 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 están asignadas al nodo
director del clúster y las direcciones IP 192.168.22.4 y 192.168.22.5 a los
 80

servidores reales. La VIP (dirección IP virtual) del clúster es

192.168.1.20.

Esta topología permite el máximo rendimiento (en cuanto a tasa de

transferencia) a través de la red, ya que el tráfico de retorno ya no tiene
que viajar a través de un nodo de balanceo.

5.3.1.1. Directores Linux o Nodos de balanceo

En cualquier momento uno de los nodos directores está activo, mientras

el otro está en una espera atenta. El nodo de balanceo activo acepta el
tráfico 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 dirección virtual y el servicio se mantiene. Las
conexiones son sincronizadas entre el nodo de balanceo activo y los que
están en espera, de tal forma que cuando una falla ocurre las
conexiones existentes pueden continuar.

Cuando un nodo de balanceo recibe una conexión desde un usuario

final, éste toma la decisión acerca de a cuál nodo servidor enviar la
conexión. Todos los paquetes del tiempo de vida de esta conexión son
enviados al mismo servidor real de tal forma que la integridad de la
conexión 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 periódicas de una página 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 línea.

Como el nodo de balanceo no es el router de entrada para los servidores

reales, el tráfico no tiene que viajar a través 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
tráfico de retorno a través de diferentes routers y/o switch cuando la
conectividad externa lo permita.
 81

5.3.1.2. Nodos servidores o servidores reales

Los servidores reales pueden ejecutar una variedad de servicios

incluyendo el servidor web HTTP Apache. Más servidores reales pueden
ser añadidos a la red si se requiere capacidad extra dado que este
esquema permite escalabilidad.

5.4. Configuración de Heartbeat en los nodos de balanceo

Ultramonkey viene con paquetes adicionales. Estos paquetes sólo 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 página: http://www.ultramonkey.org/download/3/

El proceso de instalación de toda la solución se encuentra documentado

en el Anexo 2 Instalación de la solución.

5.5. Configuración 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 están asignadas a al nodo director del clúster (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 clúster LVS es 192.168.1.20.

Para editar la configuración de un dispositivo de red usamos las

herramientas administrativas para esto: system-config-network.

Después de los cambios en el archivo es necesario reiniciar los servicios

de red para que estos surtan efecto mediante el comando service
network restart.
 82

5.6. Configuración del clúster

5.6.1. Directores Linux, nodos de balanceo

Los directores deben estar habilitados para enrutar el tráfico hacia los
servidores reales. Específicamente, 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

dirección IP virtual y los servidores reales, además indicamos que se lo
realizará mediante NAT y con el algoritmo round robin.

ipvsadm -A -t 192.168.1.20:80 -s rr

ipvsadm -a -t 192.168.1.20:80 -r 192.168.22.4:80 -m -w1

ipvsadm -a -t 192.168.1.20:80 -r 192.168.22.5:80 -m -w1

5.6.2. Heartbeat

Para configurar el Heartbeat, deben estar instalados los archivos

/etc/ha.d/ha.cf, /etc/ha.d/haresources y /etc/ha.d/authkeys.

Para visualizar el archivo /etc/ha.d/ha.cf se debe ejecutar el siguiente

comando:

vim /etc/ha.d/ha.cf

El monitoreo de los servidores reales y su inserción y eliminación del

conjunto de servidores disponibles es controlado por ldirectord, el cual
es ejecutado por Heartbeat. Para configurar ldirectord, el archivo
/etc/ha.d/ldirectord.cf debe estar instalado.
 83

vim /etc/ha.d/ldirectord.cf

Al recibir una petición de conexión 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 número de conexiones para
cada servidor real).

Los algoritmos RR, WRR, LC y WLC deberían todos funcionar de forma

similar cuando el nodo de balanceo está dirigiendo servidores reales
idénticos con servicios idénticos. El algoritmo LC será mejor manejando
situaciones donde las máquinas son dadas de baja y activadas
nuevamente. Si los servidores reales están ofreciendo diferentes
servicios y algunos tienen usuarios conectados por un largo tiempo
mientras otros están 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 clúster a implementar posee servidores reales idénticos con

servicios idénticos, se optó por implementarlo con un algoritmo RR
(round robin).

5.7. Instalar y configurar IPROUTE en los nodos servidores

Finalmente debemos configurar los nodos servidores 1 y 2 para que

acepten peticiones de la IP 192.168.22.2. En los nodos 1 y 2
ejecutamos:

ip route add default via 192.168.22.2 table 1

ip rule add fwmark 80 table 1

Es necesario utilizar firewall iptables para marcar todo el tráfico http, y

luego la ruta es a través de una tabla de rutas alternativas.

iptables -t mangle -I PREROUTING -p tcp --dport 80 -j MARK --set-mark

80

Aceptar conexiones web en los servidores por el puerto 80 y la interface

de red eth1.
 84

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

Guardamos la configuración de las reglas iptables.

service iptables save

Configuramos que el servicio de iptables en los nodos servidores este

corriendo y se active en el inicio:

chkconfig iptables on

Iniciamos el servicio iptables

service iptables start

Configuramos para que el servicio http en los nodos servidores este

corriendo y se active en el inicio, con el comando:

chkconfig httpd on

Iniciamos el servicio http

service httpd start

Asegurarse que los servidores reales (192.168.22.4 y 192.168.22.5)

reenvíen los paquetes a través del linux director (192.168.22.2), es decir,
los servidores reales deben tener como default gw a linux director.

Encontrar toda la documentación acerca de la instalación en el Anexo 2.

5.8. Pruebas de desempeño

Los servidores reales poseen una página web alojada en /var/www/html/

la misma que simplemente es informativa y nos indica que servidor es el
que está mostrando la página así (servidor 1, servidor 2). Ver figuras 5.3
y 5.4 respectivamente.
 85

El cliente realiza una petición al servidor director mediante la dirección IP

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

Figura 5.3. Página del servidor 1

 86

Figura 5.4. Página del servidor 2

Simulamos una caída del servidor 1 deteniendo el servicio http asi:

service httpd stop

Figura 5.5. Detención del servicio httpd

Observamos que ahora el balanceador muestra solamente la página del

servidor 2 en todas las peticiones.

5.8.1. Herramientas para medición de rendimiento

5.8.1.1. Selección de una herramienta para medición de rendimiento

Existen varias herramientas para comprobar el correcto funcionamiento

del clúster entre todas estas se ha decidido utilizar ipvmsad, tcpdump,
tomando en cuenta que ipvsadm en el administrador de LVS
componente de ultramonkey usado en la implementación.
 87

Ipvsadm

Ipvsadm se utiliza para establecer, mantener o inspeccionar la tabla del

servidor virtual en el kernel de Linux. El Servidor Virtual Linux puede ser
utilizado para construir los servicios de red escalable basada en un conjunto
de dos o más nodos. El nodo activo del clúster redirecciona las peticiones
de servicio a un nodo del clúster, un servidor que va a entregar los
servicios. Entre sus características soportadas incluyen dos protocolos
(TCP y UDP), tres métodos de reenvío de paquetes (NAT, túneles, y el
encaminamiento directo), y ocho algoritmos de balanceo.

El comando tiene dos formatos básicos para la ejecución:

ipvsadm COMMAND [protocol] service-address

[scheduling-method] [persistence options]

ipvsadm command [protocol] service-address

server-address [packet-forwarding-method]

[weight options]

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

asignación de las solicitudes de servicio a los servidores reales. De manera
opcional, un tiempo de espera persistentes y la máscara de red para la
granularidad de un servicio persistente puede ser especificado. El segundo
formato manipula un servidor real que está asociado con un servicio virtual
existente. Cuando se especifica un servidor real, el método de reenvío de
paquetes y el peso del servidor real, en comparación con otros servidores
reales para el servicio virtual, se puede especificar, de lo contrario se usará
por defecto.

Ejemplos:

Ipvsamd -l

Lista la tabla del servidor virtual, las conexiones activas e inactivas

existentes en el servidor.

Ipvsamd –lnc

Lista las conexiones entrantes, el estado de la conexión, el origen y el

destino de la conexión.
 88

Tcpdump

Tcpdump es una excelente herramienta que nos permite monitorear a

través de la consola de Linux todos los paquetes que atraviesen una
interfaz indicada. A su vez, los múltiples filtros, parámetros y opciones que
tcpdump nos ofrece, nos permite infinidades de combinaciones, al punto de
poder monitorear todo el tráfico completo que pase por la interfaz, como el
tráfico que ingrese de una ip, un host o una página específica, podemos
solicitar el tráfico de un puerto específico o pedirle a la herramienta que nos
muestre todos los paquetes cuyo destino sea una dirección MAC específica.

Ejemplos:

tcpdump –i eth0 port 80

Muestra todo el tráfico por la interface de red eth0 y el puerto 80.

De las pruebas obtenidas con estas herramientas podemos verificar el

estado de los servidores asi:

Figura 5.6. Verificación de servidores y conexiones con ipvsadm –l.

 89

Figura 5.7. Verificación de servidores y conexiones con ipvsadm –lnc.

Figura 5.8. Tráfico en la red con tcpdump.

 90

Figura 5.9. Salida de tráfico en la red con tcpdump.

 91

CONCLUSIONES

Una vez instalado todo el conjunto de paquetes necesario, (paquetes RPM, tipo
de paquete utilizado en distribuciones Centos), la configuración resulta sencilla
y solo se tienen que ejecutar comandos para especificar el algoritmo a utilizar
para el balanceo de carga, datos sobre los servidores reales y nodos de
balanceo como también los servicios que proporcionan y las páginas para
control esperadas (servicio en este caso particular de páginas web o HTTP
solamente).

Para las pruebas de funcionamiento se utilizó configuraciones generales del

clúster que incluye los nodos de balanceo, los algoritmos para balanceo de
carga, instalación y configuración del servidor de páginas web Apache, pruebas
simples para nodos de balanceo e instalación y configuración del paquete
iproute en los nodos servidores.

Sobre las pruebas realizadas, estas me ofrecen un panorama muy general,

puesto que la mayoría de ellas son bien controladas y se esperan ciertos
resultados, la mejor parte de las pruebas se pudo explorar esos aspectos no
previstos e investigar el comportamiento del clúster en dichos casos; en las
pruebas llevadas a cabo se contaba con un cliente con un sistema operativo
distinto al utilizado para la construcción del clúster (recuérdese que el cliente
solamente necesita un navegador web) el cual realiza las peticiones de la
página web principal alojada en el clúster, de esta manera se pudo observar
cual servidor real es el que atiende la petición (en un sistema en producción
esto no deberá ser así ya que la intención es que los usuarios vean al sitio web
como un solo equipo). La página web solicitada en las pruebas solamente
contiene una cadena indicando a que nodo servidor real pertenece. Es
importante aclarar que debido a las características de los nodos de balanceo
empleados, estos no pueden procesar miles de peticiones sin embargo las
pruebas realizadas demuestran que son suficientemente competentes para el
 92

manejo de un sitio de dimensiones bajas a medias como lo son las pequeñas

empresas.

En el transcurso de las pruebas se observó que existían problemas no

previstos en la elaboración del proyecto como la seguridad que debe
mantenerse en los servidores lo cual fue solventado denegando la aceptación
de paquetes y puertos por parte de los nodos servidores.

Al final del proyecto se concluye que la solución desarrollada es aplicable en

pequeñas empresas tomando en cuenta el correcto funcionamiento, la fácil
instalación y mantenimiento del sistema además que, por tratarse de open
source las empresas no incurre en gastos por licenciamiento.
 BIBLIOGRAFIA

2007, José Angel de Bustos Pérez, GNU/Linux, software libre para la

comunidad universitaria, 2007.

Septiembre 2001, Vicente José Aguilar Roselló, Clustering de Alta

Disponibilidad bajo GNU/Linux, septiembre 2001

2005, Rosa María Yánez Gómez, Introducción a las tecnologías de

clustering en GNU/Linux, 2005.

30 de diciembre de 2003, Emilio José Plaza Nieto, Cluster Heterogéneo

de computadoras, 30 de diciembre de 2003.

Edición junio 2010, Joel Barrios Dueñas, Implementación de Servidores

con GNU/Linux, 26 de junio 2010.

2007, Red Hat, Inc., Linux Clustering Building and Maintaining Linux
Clusters, 2007

2004, Federico Esteban Pereda, Mini-Howto Servidores de Alta

Disponibilidad (heartbeat + drbd), 2004.

Junio 30, 2007, Tom Adestein, Bill Lubanovic, Administración de

sistemas Linux, junio 30, 2007, Anaya Multimedia

2005, Charles Bookman, Clustering con Linux, 2005, Pearson Educación

2007, José Angel de Bustos Pérez, GNU/Linux, software libre para la

comunidad universitaria, 2007.

Septiembre 2001, Vicente José Aguilar Roselló, Clustering de Alta

Disponibilidad bajo GNU/Linux, septiembre 2001

http://www.codigolibre.org/index.php?option=com_content&view=article&
id=5389:clustering&catid=36:gnu-cat&Itemid=53

http://www.jumpingbean.co.za/linux-cluster-load-balancing-high-
availability

http://crysol.org/node/339

http://www.taringa.net/posts/linux/8289874/Monitoreo-de-trafico-en-red_-
tcpdump.html
http://linuxmanpages.com/man8/ipvsadm.8.php

http://bulma.net/body.phtml?nIdNoticia=1615&nIdPage=3

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

http://wiki.itlinux.cl/doku.php?id=cluster:ultramonkey-lbs

http://mmc.geofisica.unam.mx/LuCAS/Manuales-LuCAS/doc-curso-
salamanca-clustering/html/ch03s04.html

http://www.wikilearning.com/tutorial/el_manual_para_el_clustering_con_
openmosix-clusters_ha_ii/9756-15

http://www.estrellateyarde.org/discover/cluster-ultramonkey-en-linux

http://www.tcpdump.com/

http://linuxmanpages.com/man8/ipvsadm.8.php

http://www.ultramonkey.org

http://www.centos.org