Embed Size (px)
DESCRIPTION
Balanceo de Carga con open source en Centos - Ing. Mauricio Gallardo
Citation preview
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
(High Performance)
Conjunto de computadoras diseñado para brindar
altas prestaciones en cuanto a capacidad de cálculo.
Alta disponibilidad
(High Availability)
Conjunto de dos o más computadoras que se
caracterizan por mantener una serie de servicios
disponibles y compartidos, se caracterizan por estar
constantemente monitorizándose entre sí.
Balanceo de carga
(Load Balancing)
Compuesto por una o más computadoras que actúan
como interfaces primarias del clúster y se ocupan de
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-
homogéneo
Es donde se poseen arquitecturas y sistemas
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
Conexiones de red.
Estas son las conexiones de los nodos a la red de trabajo
del clúster siendo tan complejas como lo sean las
tecnologías y medios utilizados en su instalación.
Protocolos de
comunicación y
servicios.
Aquí normalmente se cuenta con el protocolo de
comunicaciones TCP/IP y servicios de transporte de datos.
Nodos.
Son simples computadoras o sistemas multiprocesador; en
estos se hospedan el Sistema Operativo, el middleware y lo
necesario para la comunicación a través de una red.
Sistema Operativo.
Se define a grandes rasgos como un programa o conjunto
de ellos que están destinados a gestionar de manera eficaz
los recursos de una computadora. Como ejemplo se tiene
Unix, Mac OSX.
Middleware.
Es un software que actúa entre el Sistema Operativo y las
aplicaciones con la finalidad de proveer a un clúster las
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.
Aplicaciones.
Son todos aquellos programas que se ejecutan sobre el
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
Activo –
Pasivo
Las aplicaciones se ejecutan sobre un conjunto de nodos
activos mientras que los nodos restantes actúan como
respaldos redundantes.
Activo –
Activo
Todos los nodos actúan como servidores activos de una o más
aplicaciones y potencialmente como respaldos para las
aplicaciones que se ejecutan en otros nodos.
Tabla 2.4 Configuración de un Clúster
15
Elemento Descripción
Infraestructura de
alta disponibilidad.
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.
Satisfacción de requerimientos del usuario.
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.
Servicios de alta
disponibilidad.
Son clientes de la infraestructura y usan las facilidades
que exporta ese nivel para mantener en todo momento el
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.
openMosix
Parche al kernel de GNU/Linux.
Algoritmo interno de balance de carga que migra
los procesos entre nodos.
Migración de procesos totalmente transparente.
Auto descubrimiento de nuevos nodos openMosix
en la red del clúster.
OSCAR
Permite instalar un clúster tipo Beowulf.
Contiene todo el conjunto de paquetes necesarios
para programar y administrar el clúster.
Formado por dos componentes principales SIS
(System Installation Suite) y ODA (OSCAR
Database API).
Piranha
Implementación de software de alta disponibilidad.
Interfaz web para control completo del clúster.
Posee herramientas para su monitorización.
Balance mediante direcciones IP.
Requiere el sistema operativo Red Hat Enterprise.
Linux Virtual Server – LVS
Constituido por un servidor altamente escalable y
de alta disponibilidad.
Balance de carga mediante nodo dedicado con
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
Ultramonkey
DNS, entre otros.
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.
openMosix
No se requieren paquetes
adicionales.
No son necesarias
modificaciones en el
código de openMosix.
Migración de procesos.
Depende del kernel.
No migra todos los
procesos siempre.
Problemas con
memoria compartida.
OSCAR
Es una compilación auto
instalable.
Infraestructura de software
para instalar y administrar
un clúster.
Posee bibliotecas y
Falla la detección de
algunos componentes
de hardware en
versiones anteriores a
la 3.
Soporte para
distribuciones basadas
en RPMs solamente
39
compiladores para uso en
clústers.
para versiones
anteriores a la 5.
Requiere que la LAN no
sea usada para instalar
software en el clúster.
Piranha
Soporte por parte de Red
Hat Inc.
Fácil instalación debido al
formato de distribución.
Administración y manejo
mediante interfaz web.
Monitorización de
servidores reales.
Al momento solo
disponible para
versiones
empresariales de Red
Hat.
Dependiente del
sistema operativo Red
Hat Enterprise.
Linux Virtual Server
- LVS
Fácil comprensión de
funcionamiento.
Amplia gama de
configuraciones.
Funciona a nivel TCP/IP.
Manejo de varios tipos de
protocolos como HTTP,
DNS, FTP entre otros.
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.
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.
Los nodos directores
tienen que ejecutar
estrictamente el
sistema operativo
GNU/Linux.
40
Ultramonkey Instrucciones 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.
Según el esquema de
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
Herramient
a
Formato
de
Distribució
n
Distribucione
s Soportadas
Balanceo de
carga y Alta
disponibilidad
Ventajas
Desventajas
openMosix
RPM,
Código
fuente.
Todas.
Balanceo de
carga de
procesos sin
alta
disponibilidad.
No requiere
paquetes
adicionales y
hace
migración de
procesos.
Dependiente
del kernel y
posee
problemas con
memoria
compartida.
Auto instalable
En versiones
anteriores a la
tercera falla la
detección de
41
OSCAR
RPM,
Código
fuente.
Red Hat y
basadas en
esta.
Balanceo de
carga de
procesos sin
alta
disponibilidad.
con bibliotecas
y
compiladores
para computo
paralelo.
hardware y no
permite usar la
red interna
para
instalación de
software.
Piranha
RPM.
Red Hat
Enterprise 4 o
posteriores.
Posee
herramientas
propias para
ambos
aspectos.
Soporte de
Red Hat,
administración
y manejo
mediante
interfaz web.
Actualmente
disponible solo
en formato
RPM y para
versiones
empresariales.
Linux
Virtual
Server
RPM, DEB,
Código
fuente.
Todas.
Incluye
herramientas
de código
abierto para
ambos
aspectos.
Amplia gama
de
configuracione
s, función a
nivel TCP/IP y
manejo de
distintos
protocolos.
Instalación por
segmentos;
con un gran
número de
servidores
reales el
tráfico crece
de manera
significativa.
Ultramonke
y
RPM. DEB,
Código
fuente.
Basadas en
Debian, Red
Hat Enterprise
4 y mediante
compilación
de código
fuente.
Uso de
componentes
de LVS para
ambos
aspectos
añadiendo
algunas
mejoras y
Múltiples
configuracione
s, manejo de
distintos
protocolos,
función a nivel
TCP/IP,
marcas de
firewall y
Los nodos de
balance de
carga deberán
ejecutar el
sistema
operativo
GNU/Linux;
dependiendo
del esquema
llega a ser
42
herramientas. ampliación de
LVS.
complejo de
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
DNS
Round –
Robin.
Distribución de la carga
entre servidores reales
de forma pseudo-
aleatoria.
Es el más simple de
implementar.
El cache de la
información en la
jerarquía de
servidores DNS y la
forma simple de
tomar decisiones por
parte del servidor
DNS restringen su
utilidad.
“Los servidores no
pueden ser
51
seleccionados según
el URL solicitado.”4
Uso de nodo
de balanceo
de carga.
Este nodo distribuye las
conexiones.
Se aumenta la
sensación de unidad
del clúster.
Única dirección IP
pública a la cual dirigir
las peticiones.
Es sencillo enmascarar
fallas de los servidores.
Llega a convertirse
en cuello de botella.
Hace uso de un nodo
adicional para
proveer el balanceo
de carga.
Al existir solo un
nodo de balanceo
este se convierte en
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
balanceo
Ventajas Desventajas
Balanceo
mediante NAT.
(Network
Aprovecha la
posibilidad del kernel
de Linux de funcionar
como router con NAT.
Los servidores reales
pueden ejecutar
El nodo de
balanceo se llega a
convertir en cuello
de botella.
Tiene que reescribir
todos los paquetes
4 http://www.wikilearning.com/monografia/balance_de_carga-la_aproximacion_via_dns/20837-2
52
Address
Translation).
cualquier sistema
operativo que soporte
TCP/IP.
Uso de solamente
una dirección IP
pública.
TCP/IP.
Número de
servidores reales
dependiente de la
velocidad de
conexión del nodo
de balanceo.
Balanceo
mediante
encapsulado IP
(IP Tunneling)
Escalado de hasta
100 servidores o más.
Se evita que el nodo
de balanceo se
convierta en cuello de
botella.
No todos los
sistemas operativos
son soportados por
este modo.
Los servidores
reales necesitan
tener una IP
pública.
Balanceo
mediante
enrutamiento
directo (Direct
Routing)
El nodo de balanceo
no es cuello de
botella.
No se sobrecarga al
nodo de balanceo en
reescribir paquetes
TCP/IP.
Todos los
servidores deben
poseer una IP
pública en el mismo
segmento de red
del nodo de
balanceo.
No todos los
sistemas operativos
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:
NAT Encapsulamiento IP Enrutamiento
Directo
Servidor Cualquiera Necesita
Encapsulamiento Dispositivo no-ARP
Red de
servidores Red Privada LAN/WAN LAN
57
Escalabilidad Baja (10~20) Alta Alta
Salida hacia
Internet
Nodo de
balanceo Router Router
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
Round Robin
Cada petición se envía a un servidor y la siguiente
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.
Round Robin
Ponderado
Igual que el anterior algoritmo pero añadiendo un peso a
cada servidor, este peso es un entero que indica la
potencia de cálculo del servidor, de modo que la cola
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.
Servidor con
menos
conexiones
activas.
Este mecanismo de distribución consulta a los servidores
para revisar en cada momento cuántas conexiones
abiertas posee cada uno con los clientes, y envía cada
petición al servidor que menos conexiones tenga en ese
momento, véase la figura 4.6.
Servidor con Igual que el algoritmo anterior pero se le añaden pesos a
58
menos
conexiones
activas
Ponderado.
los servidores para que de alguna forma se mida su
capacidad de cálculo para modificar la preferencia al
momento de hacer una elección, véase la figura 4.7.
Menos
conectado
basado en
servicio.
Este algoritmo dirige todas las peticiones a un mismo
servidor, hasta que se sobrecarga (su número de
conexiones activas es mayor que su peso) y entonces
pasa a una estrategia de menos conexiones activas
ponderada sobre el resto de servidores del clúster,
véase la figura 4.8.
Tablas Hash por
origen y destino.
En estos algoritmos se dispone de una tabla de
asignaciones fijas, en las que bien por la IP de origen o
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
Persistentes.
A todos los algoritmos de planificación anteriores se les
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.
Herramienta.
Procesador.
Memori
a RAM.
Espacio
en
Disco
Duro.
Interfaz
de Red.
Piranha. Pentium II 300MHz 64 MB +2GB 10
Mbps
65
LVS. Pentium MMX
166MHz
64 MB +1GB 10
Mbps
Ultramonkey. Pentium MMX
166MHz
64 MB +512MB 10
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
Cliente
Sistema Operativo (Windows, etc.)
Navegador Web.
Balanceo de
Carga
Sistema Operativo GNU/Linux CentOs 5.3.
Aplicaciones IPROUTE, IPTABLES, TCPDUMP
[Tcpdump].
Editor de textos VIM.
Servidor Real
Sistema Operativo GNU/Linux CentOs 5.3.
Aplicaciones IPROUTE, IP RULE e IPTABLES.
Editor de textos VIM.
Servidor de páginas web Apache2.
Tabla 5.4 Herramientas utilizadas en cada nodo.
Herramienta. Características. Características Principales.
Suite
Balanceo de carga.
Escalabilidad.
Bajo consumo de recursos.
Diversos esquemas de
configuración.
Balanceo de carga.
Alta disponibilidad.
73
Ultramonkey Manejo de diversos protocolos
como HTTP, FTP, etc.
Escalabilidad.
Editor de textos
VIM.
Crear y editar archivos de texto.
Manejo de pestañas para múltiples
documentos.
Uso de números de línea.
Búsqueda de patrones dentro del
documento.
Ejecución de comandos sin salir
del editor.
Crear y editar archivos
de texto.
Uso de números de
línea.
Búsqueda de patrones
dentro del documento.
Servidor de
Páginas web
Apache2.
Soporte de lenguajes de
programación mediante módulos.
Soporte para HTTPS.
Soporte para SSL (Secure Socket
Layer) mediante módulo.
Permite crear host virtuales.
Amplia gama de configuraciones.
Soporte de módulos
para lenguajes y otras
aplicaciones.
Soporte de SSL.
Creación de host
virtuales.
Aplicación
IPROUTE.
Calidad de servicio.
Mantenimiento de varias tablas de
ruteo.
Balanceo de carga.
Definición de túneles.
Balanceo de carga.
Mantenimiento de varias
tablas de ruteo.
Aplicación
Permite interceptar y manejar
paquetes de red.
Permite el manejo de paquetes en
diferentes estados del
procesamiento.
Permite construir firewalls basados
en GNU/Linux.
Intercepción y manejo
de paquetes de red.
Construcción de
firewalls basados en
74
IPTABLES. Realiza traducción de direcciones
(NAT).
GNU/Linux.
Traducción de
direcciones (NAT).
Aplicación
TCPDUMP.
Permite depurar aplicaciones que
utilizan la red para comunicar.
Permite depurar la red misma.
Permite capturar y leer datos
enviados por otros usuarios o
computadoras.
Permite capturar y leer
datos enviados por otros
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.
Zona Horaria.
Debe especificarse a qué zona horaria pertenece el
servidor seleccionando el país/estado/ciudad en
donde se ubica el servidor y esto ajustará el reloj del
sistema sin necesidad de saber la franja horaria.
Contraseña de
administrador y
usuario(s).
Simplemente se pedirán las contraseñas para la
cuenta de administrador y la(s) cuenta(s) de los
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
Configuración de la
red.
cual se proporcionan datos como la dirección IP y la
puerta de enlace y por último permite dejar de
momento sin configuración la interfaz de red.
Selección de
aplicaciones.
Aquí se marcarán aquellos servicios que sean
necesarios de los presentes en la lista mostrada, si
alguno no se encuentra en dicha lista, posteriormente
se podrá instalar. Algunos de estos servicios son
bases de datos y servidores web.
Tabla 5.8 Proceso de 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
