balanceo de carga en centos
TRANSCRIPT
-
UNIVERSIDAD ALFREDO PREZ GUERRERO
UNAP
CARRERA: SISTEMAS DE INFORMACION Y
NETWORKING
PROYECTO DE GRADO
PARA LA OBTENCIN DEL TTULO DE INGENIERO EN
SISTEMAS INFORMATICOS Y NETWORKING
TEMA:
DISEO DE UNA SOLUCIN PARA SERVIDORES DE
ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON
OPEN SOURCE
Autor: Flavio Mauricio Gallardo Padilla
Director: Ing. Nelio Brito
Mayo del 2011
-
Quito, 13 de mayo del 2011 Seor: Coordinador de Tesis y Proyectos de Grado UNAP Presente.- De nuestras consideraciones: Por medio de la presente CERTIFICAMOS, que el seor estudiante egresado Flavio Mauricio Gallardo Padilla, identificado con el nmero de cdula 1710049139 estudiante de la carrera de Ingeniera en Sistemas y Networking de la UNAP, una vez realizada la direccin y las evaluaciones correspondientes segn la normativa de la universidad, ha concluido satisfactoriamente con el trabajo de grado Titulado DISEO DE UNA SOLUCIN PARA SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON OPEN SOURCE. Por consiguiente, otorgamos la aptitud para la presentacin del grado oral del mencionado estudiante. Agradeciendo su atencin Ing. Nelio Brito Ing. Fredy Molina Ing. Rommel Caicedo Director Evaluador Evaluador
-
Quito, 13 de mayo del 2011
Seores:
Universidad Alfredo Prez Guerrero UNAP
Presente.-
De mis consideraciones:
Yo, Flavio Mauricio Gallardo Padilla, identificado con el nmero de cdula
1710049139, estudiante egresado de la UNAP de la Carrera de Ingeniera en
Sistemas y Networking, por medio de la presente CERTIFICO que el presente
Trabajo de Grado titulado: DISEO DE UNA SOLUCIN PARA
SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON
OPEN SOURCE; es de mi plena autora y no constituye plagio ni copia alguna
constituyndose un documento nico.
Es todo en cuanto puedo decir en honor a la verdad
Agradeciendo su atencin
Mauricio Gallardo
C.I. 1710049139
Estudiante Egresado de la UNAP
-
AGRADECIMIENTO
A mi esposa, por ser el pilar y soporte en todo lo que hago en mi vida, por ser
la persona que me ha brindado su apoyo y comprensin incondicional en la
culminacin de mi carrera, sin lugar a duda es parte esencial para haber
terminado mis estudios universitarios, gracias por todo lo que has hecho para
alcanzar esta meta, este logro tambin es tuyo.
-
DEDICATORIA
A mis hijas, quienes comprendieron que el tiempo que deba entregarles a ellas
lo ocupaba en culminar mi carrera, quiero que este logro sea para ellas un
ejemplo de perseverancia y sacrificio y que sea tambin un ejemplo para la
culminacin de sus carreras profesionales en su momento, entiendan que todo
lo que uno se propone en la vida es posible con dedicacin y esfuerzo.
-
INDICE
INTRODUCCION ................................................................................................. i
CAPITULO 1 ....................................................................................................... 1
GENERALIDADES ............................................................................................. 1
1.1. PLANEAMIENTO DEL PROBLEMA ............................................................ 1
1.2. FORMULACION DEL PROBLEMA .............................................................. 2
1.3. SISTEMATIZACION .................................................................................... 2
1.4. OBJETIVO GENERAL ................................................................................. 2
1.5. OBJETIVOS ESPECIFICOS ........................................................................ 3
1.6. JUSTIFICACIN .......................................................................................... 3
1.7. ALCANCE .................................................................................................... 4
CAPITULO 2 ....................................................................................................... 6
INTRODUCCION ................................................................................................ 6
FUNDAMENTACION TEORICA ......................................................................... 6
MARCOS DE REFERENCIA (Terico, Conceptual) ........................................... 6
2.1. MARCO TEORICO ...................................................................................... 6
2.1.1. Clustering .................................................................................................. 6
2.1.1.1. Antecedentes ......................................................................................... 6
2.1.1.2 Que es el clustering? .............................................................................. 7
2.1.1.3. Tipos de clster ...................................................................................... 8
2.1.1.4. High Performance .................................................................................. 8
2.1.1.5. Clster Activo/Pasivo ........................................................................... 14
2.1.1.6. Clster Activo/Activo ............................................................................ 14
2.1.2. Arquitectura de Clustering ....................................................................... 15
2.1.2.1. Alta disponibilidad ................................................................................ 16
2.1.2.2. Escalabilidad ........................................................................................ 20
2.1.3. Funcionamiento de un clster ................................................................. 22
2.1.3.1. Balanceador de carga .......................................................................... 22
2.1.3.2. Sistema para la deteccin de fallos en los nodos del clster ............... 24
2.1.3.3. Recursos del clster ............................................................................ 25
2.1.3.4. Servicio a clusterizar ............................................................................ 25
-
2.1.4. Balanceo de Carga ................................................................................. 26
2.1.4.1. Balanceadores hardware ..................................................................... 29
2.1.4.2. Balanceadores software....................................................................... 30
2.1.4.3. Linux Virtual Server - LVS .................................................................... 30
2.1.5. Deteccin de fallos en los nodos del clster ........................................... 32
2.1.5.1. Heartbeat ............................................................................................. 32
2.1.5.2. Disco de quorum .................................................................................. 34
CAPITULO 3 ..................................................................................................... 36
INTRODUCCION .............................................................................................. 36
DIAGNOSTICO ................................................................................................. 36
3.1. Herramientas de open source para la construccin del Clster ................. 36
3.2. Comparacin de las herramientas de balanceo de carga y alta
disponibilidad .................................................................................................... 40
3.2.1. Herramientas de balanceo de carga y alta disponibilidad ....................... 44
3.2.1.1. Piranha ................................................................................................. 44
3.2.1.2. Linux Virtual Server .............................................................................. 45
3.2.1.3. Ultramonkey ......................................................................................... 47
3.2.1.3.1. Componentes Ultramonkey ............................................................... 47
3.2.1.3.1.1. Heartbeat ....................................................................................... 48
3.2.1.3.1.2. Ldirectord ....................................................................................... 48
3.2.1.3.1.3. Mon (Service Monitoring Daemon)................................................. 49
CAPITULO 4 ..................................................................................................... 50
INTRODUCCION .............................................................................................. 50
DISEO ............................................................................................................ 50
4.1. Tipos de balanceo de carga ....................................................................... 50
4.1.1. Modos de balanceo de carga en LVS ..................................................... 51
4.1.2. Resumen de los mtodos de balanceo ................................................... 56
4.1.3. Planificacin del balanceo de carga ........................................................ 57
4.2. Eleccin de una herramienta para balanceo de carga y alta disponibilidad
.......................................................................................................................... 62
CAPITULO 5 ..................................................................................................... 69
INTRODUCCION .............................................................................................. 69
IMPLEMENTACION EN MAQUINAS VIRTUALES ........................................... 69
-
5.1 INSTALACION Y CONFIGURACION DEL CLUSTER ................................ 69
5.1.1 SELECCIN DE NODOS PARA EL CLSTER ...................................... 71
5.1.2 Instalacin de los nodos........................................................................... 74
5.1.3. Configuracin de los servidores web ...................................................... 76
5.2. Instalacin de CentOs ................................................................................ 78
5.3. Instalacin de Ultramonkey ........................................................................ 78
5.3.1. Seleccin de topologa de instalacin de ultamonkey ............................. 79
5.3.1.1. Directores Linux o Nodos de balanceo ................................................ 80
5.3.1.2. Nodos servidores o servidores reales .................................................. 81
5.4. Configuracin de Heartbeat en los nodos de balanceo ............................. 81
5.5. Configuracin de la red de trabajo ............................................................. 81
5.6. Configuracin del clster ........................................................................... 82
5.6.1. Directores Linux, nodos de balanceo ...................................................... 82
5.6.2. Heartbeat ................................................................................................ 82
5.7. Instalar y configurar IPROUTE en los nodos servidores ............................ 83
5.8. Pruebas de desempeo ............................................................................. 84
5.8.1. Herramientas para medicin de rendimiento .......................................... 86
5.8.1.1. Seleccin de una herramienta para medicin de rendimiento ............. 86
CONCLUSIONES ............................................................................................. 91
Anexo 1 Instalacin de Centos ......................................................................... 95
Anexo 2 Instalacin de la Solucin ................................................................. 118
-
INDICE DE FIGURAS
Figura 2.1 Clster de computadores ............................................................... 7
Figura 2.2 Componentes de un clster ............................................................ 9
Figura 2.3 Arquitectura de un Clster ............................................................ 15
Figura 2.4 Alta disponibilidad ......................................................................... 20
Figura 2.5 Balanceador de Carga .................................................................. 23
Figura 2.6 Recursos del Clster .................................................................... 25
Figura 2.7 Balanceo de Carga ....................................................................... 27
Figura 2.8 Balanceadores de Carga .............................................................. 31
Figura 2.9 Heartbeat ...................................................................................... 32
Figura 2.10 Disco de Quorum ........................................................................ 35
Figura 3.1 Esquema de funcionamiento de Piranha. ..................................... 45
Figura 3.2 Esquema de funcionamiento de LVS. .......................................... 46
Figura 3.3 Componentes de Ultramonkey. .................................................... 48
Figura 3.4 Esquema de funcionamiento de Ultramonkey. ............................. 49
Figura 4.1 Balanceo mediante NAT. .............................................................. 53
Figura 4.2 Balanceo mediante encapsulado IP. ............................................ 54
Figura 4.3 Balanceo mediante enrutamiento directo. .................................... 55
Figura 4.4 Round Robin. ................................................................................ 59
Figura 4.5 Round Robin Ponderado. ............................................................. 59
Figura 4.6 Servidor con menos conexiones activas. ..................................... 60
Figura 4.7 Servidor con menos conexiones activas ponderado. ................... 60
Figura 4.8 Menos conectado basado en servicio. ......................................... 61
Figura 4.9 Tablas Hash por origen y destino. ................................................ 61
Figura 5.1 Funcionamiento del Clster. ......................................................... 70
Figura 5.2. Configuracin final de nodos. ...................................................... 78
Figura 5.3. Pgina del servidor 1 ................................................................... 85
Figura 5.4. Pgina del servidor 2 ................................................................... 85
Figura 5.5. Detencin del servicio httpd ......................................................... 86
Figura 5.6. Verificacin de servidores y conexiones con ipvsadm l. ............ 88
Figura 5.7. Verificacin de servidores y conexiones con ipvsadm lnc. ........ 89
-
Figura 5.8. Trfico en la red con tcpdump. .................................................... 89
Figura 5.9. Salida de trfico en la red con tcpdump. ..................................... 90
-
INDICE DE TABLAS
Tabla 2.1 Tipos de Clster ........................................................................... 8
Tabla 2.2 Subtipos de Clster ...................................................................... 9
Tabla 2.3 Componentes de un Clster ....................................................... 10
Tabla 2.4 Configuracin de un Clster ....................................................... 14
Tabla 2.5 Estructura de Alta Disponibilidad ................................................ 15
Tabla 3.1 Caractersticas de Herramientas para Clsters. ......................... 38
Tabla 3.2 Ventajas y Desventajas de las Herramientas para Clster. ........ 40
Tabla 3.3 Comparacin de herramientas para clster. ............................... 42
Tabla 4.1 Mtodos de balanceo de carga. ................................................. 51
Tabla 4.2 Modos de balanceo de carga en LVS. ........................................ 52
Tabla 4.3 Mtodos de direccionamiento. .................................................... 57
Tabla 4.4 Algoritmos de planificacin de balanceo de carga. .................... 58
Tabla 4.5 Requisitos mnimos de hardware para Piranha. ......................... 63
Tabla 4.6 Requisitos mnimos de hardware para LVS. .............................. 64
Tabla 4.7 Requisitos mnimos de hardware para Ultramonkey. ................. 64
Tabla 4.8 Comparacin de requisitos. ........................................................ 65
Tabla 5.1 Funcionamiento del Clster. ....................................................... 70
Tabla 5.2 Especificaciones del nodo de balanceo. ..................................... 71
Tabla 5.3 Especificaciones de nodo servidor. ............................................ 71
Tabla 5.4 Herramientas utilizadas en cada nodo. ...................................... 72
Tabla 5.5 Caractersticas de herramientas utilizadas. ................................ 74
Tabla 5.6 Proceso de instalacin del Sistema Operativo. .......................... 74
Tabla 5.7 Medios de instalacin. ................................................................ 75
Tabla 5.8 Proceso de instalacin del sistema base. ................................... 76
Tabla 5.9 Servicios activados en los nodos servidores. ............................. 76
-
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
informacin. As pues se da paso a la investigacin y desarrollo de nuevas
tecnologas que garanticen tales sucesos; en este trabajo se presentarn las
soluciones para tales problemas y se expondrn sus caractersticas as como
las herramientas que hacen posible la construccin de dichas soluciones de
software con open source.
Un servidor juega un papel muy importante dentro de una organizacin, y al
mismo tiempo se transforma en un servicio crtico al ser utilizado por la gran
mayora de los usuarios para acceder a todos los servicios que este brinda,
siendo necesario la implementacin de un sistema de clster que permita
mantener el servicio disponible en caso de que falle un servidor as como
mantener un sistema de balanceo de carga evitando la saturacin del propio
servidor.
Un clster es un conjunto de maquinas, conectadas entre s en red y
funcionando en paralelo y compartiendo recursos para cooperar en cargas de
trabajo complejas y conseguir mayor eficacia que un solo equipo.
Al hablar de clster, tenemos un numeroso listado de diversas aplicaciones que
implementan distintos tipos de clster, dependiendo de las necesidades que
posee la organizacin y la aplicacin a clusterizar.
Dentro de los clster ms comunes, se encuentra el clster de alta
disponibilidad, en el cual uno de los nodos acta pasivamente mientras el nodo
activo recibe todas las peticiones a los servicios que ofrece. En caso de que el
nodo activo tenga alguna falla en los servicios, el nodo pasivo toma el control
-
ii
de los servicios y pasa a ser el activo para que los servicios ofrecidos estn
siempre disponibles.
Actualmente, debido a la gran cantidad de usuarios que necesitan acceder a
los servicios, es necesario tambin aprovechar los nodos pertenecientes al
clster, para que estos pasen a ser activos y la carga se pueda dividir entre
todos los nodos del clster, constituyendo as un clster de balanceo de carga.
-
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 electrnico, ftp, web, etc., dando origen a
prestar servicios de baja calidad a sus clientes poniendo en riesgo la
continuidad del negocio, lo que ocasiona prdidas econmicas.
Actualmente en el pas existen pocas empresas que han optado por instalar
open source en sus servidores debido al poco personal tcnico capacitado,
pese a que el gobierno nacional promueve el uso de open source en las
entidades pblicas. Este trabajo se enfoca en el uso de software libre para la
implementacin de la solucin planteada.
Existen equipos que permiten balanceo de carga y alta disponibilidad mediante
hardware, pero la adquisicin de estos significa una inversin para las
empresas contrariamente a las soluciones de software open source que no
necesitan pagar ningn valor de licenciamiento.
De no contar con una solucin al problema de alta disponibilidad y balanceo de
carga por software se perder la opcin de contribuir a una investigacin e
implementacin de este tipo.
Mediante la implementacin de la solucin, las empresas aseguran el normal
desenvolvimiento de sus operaciones, minimizando sustancialmente el riesgo
tecnolgico dando continuidad al negocio y por consiguiente a sus operaciones,
se centrar en la tcnica de obtener una alta disponibilidad y balanceo de carga
-
2
por medio de la redundancia, instalando servidores completos en lugar de uno
slo (se realizar la implementacin en mquinas virtuales), que sean capaces
de trabajar en paralelo y de asumir las cadas de algunos de sus compaeros,
y podremos aadir y quitar servidores al grupo (clster) segn las necesidades.
1.2. FORMULACION DEL PROBLEMA
Encontrar la solucin que permita mantener un alto nivel de disponibilidad y
balanceo de carga, con herramientas open source, dando continuidad a los
servicios?. Considerando la experiencia adquirida en la implementacin,
administracin y mantenimiento de servidores Linux en los ltimos aos de
servicio profesional.
1.3. SISTEMATIZACION
Qu herramientas open source nos permiten aplicar alta disponibilidad y
balanceo de carga?
Qu herramientas open souce se utilizarn para la implementacin de la
solucin?
Qu necesitan las empresas para solucionar su problema de alta
disponibilidad y balanceo de carga?
1.4. OBJETIVO GENERAL
Disear una solucin de alta disponibilidad y balanceo de carga, para dotar de
servicios que permitan dar continuidad al negocio en las operaciones
realizadas por las empresas, con software open source.
-
3
1.5. OBJETIVOS ESPECIFICOS
Investigar las distintas posibilidades que nos ofrece hoy en da el mundo del
Software Libre para disponer de servidores de alta disponibilidad y balanceo de
carga en el terreno empresarial y orientado principalmente a servicios IP
(servidores HTTP, SMTP, POP, FTP, etc), basados en la replicacin de
servidores (clustering) con mquinas virtuales y bajo el Sistema Operativo
GNU/Linux.
Diagnosticar el estado actual de la tecnologa utilizada en las empresas, que
necesitan balanceo de carga y alta disponibilidad.
Disear una solucin que permita ofrecer servidores de alta disponibilidad y
balanceo de carga mediante software libre.
Implementar en un ambiente de laboratorio la solucin diseada, para asegurar
el normal desenvolvimiento de las operaciones en cualquier empresa. Dicho
laboratorio se lo implementar en mquinas virtuales.
1.6. JUSTIFICACIN
Con el actual ritmo de crecimiento del comercio y el movimiento de datos de
todo tipo en Internet, web 2.0, con el establecimiento no formal de un protocolo
mundial IP generalizo y la incuestionable importancia de las tecnologas de la
informacin en las empresas actuales de cualquier tamao, es cada da ms
importante que los servicios puedan funcionar con un alto nivel de SLA (calidad
de servicio) , ya sea para dar soporte interno, como para ofrecer servicios a
travs de Internet e Intranet (http, correo, ftp, etc). A esta necesidad de un
servicio ininterrumpido y fiable se le conoce como alta disponibilidad, de igual
forma evitar la sobre carga existente en los servidores debido al gran nmero
de usuarios y que estos no sean saturados, compartiendo con otros la
responsabilidad de dar los servicios conocemos como balanceo de carga.
-
4
Para poder incrementar la base cientfica relacionada con proyectos de
software open source y minimizar el riesgo tecnolgico. Se utiliza open source
por que es software libre, es decir no se debe incurrir en gastos de
licenciamiento para su uso.
Desde el punto de vista metodolgico, esta investigacin generar
conocimiento vlido y confiable dentro del rea de las TICS , para futuras
implementaciones. Esta investigacin abrir nuevos caminos en empresas que
presenten situaciones similares sirviendo a estas como marco referencial.
1.7. ALCANCE
El proyecto abarcar la investigacin sobre las herramientas de clster que nos
ofrece el software libre, para de esta manera analizar la mejor opcin para ser
implementada, esta investigacin permitir adems adquirir conocimiento para
futuras implementaciones.
Despus de conocer las opciones de cluster con open source, se realizar un
diagnostico sobre las herramientas disponibles para proponer una solucin que
permita de forma adecuada implementar la tecnologa elegida, tomando en
cuenta siempre la mejor alternativa.
Se crear un laboratorio con mquinas virtuales para la implementacin en un
ambiente de pruebas, que contendr servicios como http, mail, ftp, proxy,
adems se obtendr pruebas de los resultados de funcionamiento de la
solucin.
Se contar con un cliente con un sistema operativo distinto al utilizado para la
construccin del clster (el cliente solamente necesita un navegador web) el
cual realiza las peticiones de la pgina web principal alojada en el clster, de
esta manera se puede observar cual servidor real es el que atiende la peticin
(en un sistema en produccin esto no deber ser as ya que la intencin es que
los usuarios vean al sitio web como un solo equipo). En lo concerniente a las
-
5
pruebas de alta disponibilidad, sern realizadas de 3 maneras, la primera es
desconectando un nodo de balanceo, la segunda es detener la ejecucin de las
aplicaciones encargadas de monitorear el estado de los nodos de balanceo en
uno de los nodos para simular un fallo fsico del nodo y tercera es apagando
uno de los nodos y revisar si el servicio sigue en funcionamiento. Esto nos dar
una visin certera del real funcionamiento de servidores de este tipo en
ambientes de produccin.
-
6
CAPITULO 2
INTRODUCCION
Este captulo contiene conceptos fundamentales que son necesarios conocer
para la elaboracin del proyecto como: clustering, tipos de clster, arquitectura
de clustering, alta disponibilidad, balanceo de carga.
Adicionalmente se relata una breve historia del inicio, desarrollo y evolucin de
la tecnologa relacionada con los clster.
FUNDAMENTACION TEORICA
MARCOS DE REFERENCIA (Terico, Conceptual)
2.1. MARCO TEORICO
2.1.1. Clustering
2.1.1.1. Antecedentes
En el verano de 1994 Thomas Sterling y Don Becker, trabajando
para el CESDIS (Center of Excellence in Space Data and Informarion
Sciencies) bajo el patrocinio del Proyecto de las Ciencias de la Tierra
y el Espacio (ESS) de la NASA, construyeron un Clster de
Computadoras que consista en 16 procesadores DX4 conectados
por una red Ethernet a 10Mbps, ellos llamaron a su mquina
Beowulf.
La mquina fue un xito inmediato y su idea de proporcionar
sistemas basados en COTS (equipos de sobremesa) para satisfacer
requisitos de cmputo especficos se propag rpidamente a travs
de la NASA y en las comunidades acadmicas y de investigacin. El
esfuerzo del desarrollo para esta primera mquina creci
rpidamente en lo que ahora llamamos el Proyecto Beowulf.
Este Beowulf construido en la NASA en 1994 fue el primer clster de
la historia, y su finalidad era el clculo masivo de datos. Desde
entonces, la tecnologa de clusters se ha desarrollado enormemente.
-
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 mquinas que forman el clster recibe el nombre de nodo.
Figura 2.1 Clster de computadores
Esta tecnologa ha evolucionado para beneficio de diversas
actividades que requieren el poder de cmputo y aplicaciones de
misin crtica.
El uso de los clsters es el resultado de una convergencia de
mltiples tecnologas que abarcan la disponibilidad de procesadores
econmicos de alto rendimiento y las redes de alta velocidad, como
lo son las redes de fibra ptica as como tambin el desarrollo de
herramientas de software diseadas para cmputo distribuido de alto
desempeo.
-
8
En este sentido para que una empresa pueda contar con un clster
es necesario considerar los diferentes tipos existentes dependiendo
de la tarea que se quiera realizar con este, como lo muestra la tabla
2.1.
2.1.1.3. Tipos de clster
Dependiendo del tipo de solucin que busquemos podemos clasificar
los clusters en varios tipos:
High Performance
High Availability
Load Balancing
2.1.1.4. High Performance
Tipo de Clster Descripcin
Alto rendimiento
(High Performance)
Conjunto de computadoras diseado para brindar
altas prestaciones en cuanto a capacidad de clculo.
Alta disponibilidad
(High Availability)
Conjunto de dos o ms computadoras que se
caracterizan por mantener una serie de servicios
disponibles y compartidos, se caracterizan por estar
constantemente monitorizndose entre s.
Balanceo de carga
(Load Balancing)
Compuesto por una o ms computadoras que actan
como interfaces primarias del clster y se ocupan de
repartir las peticiones de servicio que recibe el
clster a los nodos que lo conforman.
Tabla 2.1 Tipos de Clster
-
9
Adems de la clasificacin general de los tipos de clster que se
pueden encontrar, es preciso destacar que se pueden tener los
siguientes subtipos en cada una de las categoras segn se muestra
en la tabla 2.2.
Subtipo Descripcin
Homogneo Es donde todos los nodos poseen una
configuracin de hardware y software iguales.
Semi-
homogneo
Es donde se poseen arquitecturas y sistemas
operativos similares pero de diferente rendimiento.
Heterogneo Es donde se poseen hardware y software distintos
para cada nodo.
Tabla 2.2 Subtipos de Clster
Un clster posee varios componentes de software y hardware para
poder funcionar, la figura 2.2 muestra dichos componentes:
Figura 2.2 Componentes de un clster
-
10
Para entender mejor estos componentes, es recomendable el
anlisis mediante la tabla 2.3, en ella se puede observar cada
componente y una descripcin del mismo comenzando por la
interconexin de los equipos.
Componente Descripcin
Conexiones de red.
Estas son las conexiones de los nodos a la red de trabajo
del clster siendo tan complejas como lo sean las
tecnologas y medios utilizados en su instalacin.
Protocolos de
comunicacin 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 comunicacin a travs de una red.
Sistema Operativo.
Se define a grandes rasgos como un programa o conjunto
de ellos que estn destinados a gestionar de manera eficaz
los recursos de una computadora. Como ejemplo se tiene
Unix, Mac OSX.
Middleware.
Es un software que acta entre el Sistema Operativo y las
aplicaciones con la finalidad de proveer a un clster las
caractersticas de interfaz, herramientas de optimizacin y
mantenimiento del sistema, como tambin un crecimiento o
escalabilidad. Entre los ms populares se encuentra
openMosix.
Aplicaciones.
Son todos aquellos programas que se ejecutan sobre el
middleware; estos son diseados para su ejecucin en
entornos de cmputo paralelo o aprovechamiento del tipo
de clster.
Tabla 2.3 Componentes de un Clster
-
11
Los clsters permiten una flexibilidad de configuracin que no se
encuentra normalmente en los sistemas multiprocesadores
convencionales. El nmero de nodos, la capacidad de memoria por
nodo, el nmero de procesadores por nodo y la topologa de
interconexin, son todos parmetros de la estructura del sistema que
puede ser especificada en detalle en una base por nodo sin incurrir
en costos adicionales debidos a la configuracin personalizada.
Adems, permiten una rpida respuesta a las mejoras en la
tecnologa. Cuando los nuevos dispositivos, incluyendo
procesadores, memoria, disco y redes estn disponibles se pueden
integrar a los nodos del clster de manera fcil y rpida permitiendo
que sean los sistemas paralelos que primero se benefician de tales
avances. Lo mismo se cumple para los beneficios de un
mejoramiento constante en el rubro de precio-rendimiento en la
tecnologa. Los clsters son actualmente la mejor opcin para seguir
la pista de los adelantos tecnolgicos y responder rpidamente a las
ofertas de nuevos componentes.
Los clsters permiten una flexibilidad de configuracin que no se
encuentra normalmente en los sistemas multiprocesadores
convencionales. El nmero de nodos, la capacidad de memoria por
nodo, el nmero de procesadores por nodo y la topologa de
interconexin, son todos parmetros de la estructura del sistema que
puede ser especificada en detalle en una base por nodo sin incurrir
en costos adicionales debidos a la configuracin personalizada.
Un clster puede ser usado para solucionar una variedad de
problemas dependiendo del tipo que se tenga, como ya se dijo
existen los de alto rendimiento, balanceo de carga y alta
disponibilidad. Los dos primeros resuelven problemas como:
-
12
Clculos matemticos.
Rendering (construccin/generacin) de grficos.
Compilacin de programas.
Compresin de datos.
Descifrado de cdigos.
Rendimiento del sistema operativo, (incluyendo en l, el
rendimiento de los recursos de cada nodo).
En general cualquier problema de propsito general que
requiera de gran capacidad de procesamiento.
En el caso de los clster de alta disponibilidad resuelven:
Sistemas de informacin redundante.
Sistemas tolerantes a fallos.
Balance de procesos entre varios servidores.
Balance de conexiones entre varios servidores.
En general cualquier problema que requiera almacenamiento
de datos siempre disponible con tolerancia a fallos.
De esta manera, se afirma que el problema que se resuelve con el
balanceo de carga est estrechamente relacionado con los que se
pueden solucionar la alta disponibilidad, ya que generalmente se
desea que un servicio est disponible el mayor tiempo posible y con
la mejor respuesta que se pueda obtener.
Es as que el servicio puede ser diverso; desde un sistema de
archivos distribuidos de carcter muy barato, hasta grandes clsters
de balanceo de carga y conexiones para los grandes portales de
Internet lo que lleva a que la funcionalidad requerida en un entorno
de red puede ser colocada en un clster e implementar mecanismos
para hacer que ste obtenga la mayor disponibilidad posible.
-
13
Realmente no hay sistemas que puedan asumir la alta disponibilidad
en realidad, se requiere que el clster sea tolerante a los fallos. En
dicho caso se pretende ocultar al usuario final la presencia de los
fallos del sistema empleando redundancia en el hardware y en el
software e incluso redundancia temporal.
La redundancia en el hardware consiste en aadir componentes
replicados para encubrir los posibles fallos mientras que la
redundancia de software incluye la administracin del hardware
redundante para asegurar su correcto funcionamiento al hacer frente
a la cada de algn elemento. Y por ltimo la redundancia en el
tiempo hace referencia a la repeticin de la ejecucin de un conjunto
de instrucciones para asegurar el comportamiento correcto en caso
de que ocurra un fallo.
Por su parte, el balanceo de carga en el contexto del servicio web es
la toma de decisin de cul nodo deber hacerse cargo de las
peticiones de servicio de otro que est con un mayor nmero de
peticiones de servicio que l, con el objetivo de que stas se
encuentren equilibradas entre el total de nodos que conforman el
clster. Cuando se genera una creciente demanda de trabajo en
este servicio se hace uso del balanceo de carga, creciendo el
nmero de nodos que mantienen el servicio a medida que la carga
de trabajo aumenta no siendo requisito el incorporar nodos con los
ltimos avances tecnolgicos.
En el balanceo de carga en un nodo (o varios segn sea el caso) es
una tarea que controlar la distribucin entre los servidores que
componen el clster. Cabe aclarar que dicha labor se puede efectuar
a nivel de aplicacin; lo que puede llevar a cuellos de botella si el
nmero de nodos servidores es grande y en un nivel de direccin IP,
en el cual la cantidad de informacin que es manejada es mucho
-
14
menor, puesto que slo son manejadas las direcciones IP y no datos
adicionales como el manejo de sesiones e informacin de control de
la aplicacin; por ello en el manejo a nivel de direccin IP, un cuello
de botella es menos factible.
As pues, para lograr que un sistema tenga caractersticas de alta
disponibilidad se hace uso de componentes de hardware redundante
y un software capaz de unir tales componentes. Estos sistemas
poseen dos posibles configuraciones que se listan en la tabla 2.4. Un
clster de alta disponibilidad puede componerse de uno o varios
nodos para sustentar el acceso al servicio ofrecido, sin embargo se
debe prestar atencin cuando slo se cuenta con un nodo pues este
representa un punto nico de fallo lo que se traduce en un nodo que
al fallar, el acceso se ve interrumpido.
Una estructura de alta disponibilidad de este tipo est conformada
como se muestra en la tabla 2.5.
2.1.1.5. Clster Activo/Pasivo
2.1.1.6. Clster Activo/Activo
Configuracin Descripcin
Activo
Pasivo
Las aplicaciones se ejecutan sobre un conjunto de nodos
activos mientras que los nodos restantes actan como
respaldos redundantes.
Activo
Activo
Todos los nodos actan como servidores activos de una o ms
aplicaciones y potencialmente como respaldos para las
aplicaciones que se ejecutan en otros nodos.
Tabla 2.4 Configuracin de un Clster
-
15
Elemento Descripcin
Infraestructura de
alta disponibilidad.
Consiste en componentes de software que cooperan
entre s para permitir que el clster parezca como un
sistema nico. Entre sus funciones se encuentran:
Monitorizacin de nodos y procesos.
Control de acceso a recursos compartidos.
Satisfaccin de requerimientos del usuario.
Esta puede ser parte del ncleo del sistema operativo o
una capa situada sobre ste, las ventajas de dichas
integraciones son:
En forma de capa, una solucin independiente del
sistema operativo.
En el sistema operativo, una eficiencia y facilidad
de uso.
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 degradacin del sistema
cuando un nodo falla pero no una interrupcin del
servicio.
Tabla 2.5 Estructura de Alta Disponibilidad
2.1.2. Arquitectura de Clustering
-
16
Figura 2.3 Arquitectura de un Clster
El propsito de un cluster es:
Redundancia frente a fallos (alta disponibilidad).
Aumento de potencia (escalabilidad).
Estos propsitos no son excluyentes.
Importante.- A la hora de escoger que tipo de clster se va a
utilizar hay que tener en cuenta las caractersticas que nos ofrece
cada tipo y cul es el que ms encaja en nuestro entorno.
2.1.2.1. Alta disponibilidad
La alta disponibilidad ha sido tradicionalmente un requerimiento
exigido a aquellos sistemas que realizaban misiones crticas. Sin
embargo, actualmente, est siendo cada vez ms importante exigir
esta disponibilidad en sistemas comerciales y en reas acadmicas
donde el objetivo de prestar los servicios en el menor tiempo posible
es cada vez ms perseguido.
El concepto de clster de disponibilidad continua, se basa en la idea
de mantener la prestacin del servicio en todo momento. Esto
representa una situacin ideal, sera necesario que el sistema
estuviera compuesto de componentes perfectos que no fallaran
nunca, tanto en hardware como en software. Realmente no hay
sistemas que puedan asumir este tipo de disponibilidad.1
Se necesita que el clster sea tolerante a los fallos, en este caso se
encubre la presencia de los fallos del sistema empleando
redundancia en el hardware, el software e incluso redundancia
temporal. La redundancia en el hardware consiste en aadir
componentes replicados para encubrir los posibles fallos. La
1 http://www.eurogaran.com/index.php/es/servidores-linux/clusteres/de-alta-disponibilidad
-
17
redundancia software incluye la administracin del hardware
redundante para asegurar su correcto funcionamiento al hacer frente
a la cada de algn elemento. La redundancia en el tiempo hace
referencia a la repeticin de la ejecucin de un conjunto de
instrucciones para asegurar el comportamiento correcto en caso de
que ocurra un fallo.
Definiremos un clster de alta disponibilidad como un sistema capaz
de encubrir los fallos que se producen en l para mantener una
prestacin de servicio continua.
El clster de alta disponibilidad va a poder disearse con distintas
configuraciones. Una posible configuracin es activo pasivo en el
cul las aplicaciones se ejecutan sobre el conjunto de nodos activos,
mientras que los nodos restantes actan como backups redundantes
para los servicios ofrecidos.
En el otro extremo, tenemos otra posible configuracin, activo -
activo: en este caso, todos los nodos actan como servidores activos
de una o ms aplicaciones y potencialmente como backups para las
aplicaciones que se ejecutan en otros nodos. Cuando un nodo falla,
las aplicaciones que se ejecutaba en l se migran a uno de sus
nodos backup. Esta situacin podra producir una sobrecarga de los
nodos de respaldo, con lo que se ejecutaran las aplicaciones con
ms retardo.
Sin embargo es aceptable una degradacin del servicio y tambin
suele ser preferible a una cada total del sistema. Otro caso particular
de clster de alta disponibilidad sera el de un clster de un solo
nodo, tratndose en este caso, simplemente, de evitar los puntos
nicos de fallo.
-
18
Los conceptos de alta disponibilidad y de clustering estn
profundamente relacionados ya que el concepto de alta
disponibilidad de servicios implica directamente una solucin
mediante clustering.
La principal prestacin de un sistema de alta disponibilidad es que el
fallo de un nodo derive en que las aplicaciones que se ejecutaban en
l sean migradas a otro nodo del sistema. Este migrado puede ser
automtico (failover) o manual (switchover).2
Generalmente este tipo de cluster integra un nmero relativamente
pequeo de nodos (entre 2 y 8), aunque existen soluciones
comerciales que trabajan en clusters de mayor tamao. En este
caso, la escalabilidad no sera un objetivo prioritario, en contraste
con el caso de los clusters computacionales.
Las aplicaciones usadas para el diseo y la implementacin de este
tipo de clusters no tienen porqu escalar. Sin embargo, actualmente,
existe una cierta tendencia a perseguir la escalabilidad tambin en
los clusters de alta disponibilidad lo que lleva a que cada vez se
busca ms tener un cluster de mayor nmero de nodos pero ms
pequeos en tamao y prestaciones.
Desde un punto de vista general, una solucin de alta disponibilidad
consiste en dos partes: la infraestructura de alta disponibilidad y los
servicios.
La infraestructura consiste en componentes software que cooperan
entre s para permitir que el cluster aparezca como un nico sistema.
Sus funciones incluyen monitorizar los nodos, los procesos de
interrelacin entre nodos, controlar el acceso a los recursos
2 http://www.seccperu.org/files/Clustering%20and%20Grid%20Computing.pdf
-
19
compartidos y asegurar la integridad de los datos y la satisfaccin de
los requerimientos del usuario. La infraestructura debe proveer de
estas funcionalidades cuando el cluster est en estado estable y, lo
que es ms importante, cuando algunos nodos dejan de estar
operativos.
Los servicios de alta disponibilidad son clientes de la infraestructura,
y usan las facilidades que exporta ese nivel para mantener en todo
momento el servicio a los usuarios. Normalmente hay una
degradacin del sistema cuando algn nodo cae, pero no una
interrupcin del servicio.
Los servicios que se mantienen tpicamente sobre este tipo de
clusters son las bases de datos, los sistemas de ficheros, los
servidores de correo y los servidores web. Y en general, sern
utilizados para tareas crticas o servicios ofrecidos por una empresa,
grupo de investigacin o institucin acadmica, que no puedan, por
sus caractersticas concretas, interrumpir el servicio.
La adaptacin ms comn que debe sufrir una aplicacin para poder
ser ejecutada en un clster de alta disponibilidad implementado
sobre GNU/Linux, es aadir scripts. Existen APIs para trabajar
cmodamente con alta disponibilidad; todas ellas incluyen mtodos
que permiten el switchover y el failover y que permiten arrancar,
parar o monitorizar una aplicacin por mencionar algunas de sus
funcionalidades.
La infraestructura puede ser parte del ncleo del sistema operativo o
puede ser una capa situada encima. Integrar la infraestructura en el
sistema operativo tiene como ventaja la eficiencia y la facilidad de
uso. La principal ventaja de una capa separada es que se
independiza la solucin de alta disponibilidad del sistema operativo,
-
20
con lo que resulta ms portable. En cualquier caso el sistema debe
tener la capacidad de aparecer como un nico sistema (SSI Single
System Image). En caso de un clster de alta disponibilidad para
asegurar esta apariencia nica los elementos ms importantes son el
sistema de ficheros global, dispositivos globales y la red global.3
Figura 2.4 Alta disponibilidad
2.1.2.2. Escalabilidad
La escalabilidad es la capacidad de un equipo para hacer frente a
volmenes de trabajo cada vez mayores brindando siempre nivel de
rendimiento aceptable. Existen dos tipos de escalabilidad:
Escalabilidad del hardware (denominada tambin escalamiento
vertical). Se basa en la utilizacin de un gran equipo cuya
capacidad se aumenta a medida que lo exige la carga de trabajo
existente.
3 http://www.redes-linux.com/manuales/cluster/clustering.pdf
-
21
Escalabilidad del software (denominada tambin escalamiento
horizontal). Se basa, en cambio, en la utilizacin de un clster
compuesto de varios equipos de mediana potencia que funcionan en
tndem de forma muy parecida a como lo hacen las unidades de un
RAID (Redundant Array of Inexpensive Disks o Array redundante de
discos de bajo coste).
Se utilizan el trmino RAC (Redundant Array of Computers o Array
redundante de equipos) para referirse a los clster de escalamiento
horizontal. Del mismo modo que se aaden discos a un array RAID
para aumentar su rendimiento, se pueden aadir nodos a un clster
para aumentar tambin su rendimiento.
La disponibilidad y la fiabilidad son dos conceptos que, si bien se
encuentran ntimamente relacionados, difieren ligeramente. La
disponibilidad es la calidad de estar presente, listo para su uso, a
mano, accesible; mientras que la fiabilidad es la probabilidad de un
funcionamiento correcto.
Pero hasta el ms fiable de los equipos acaba fallando, lo que
genera que los fabricantes de hardware intenten anticiparse a los
fallos aplicando la redundancia en reas clave como son las
unidades de disco, las fuentes de alimentacin, las controladoras de
red y los ventiladores, pero dicha redundancia no protege a los
usuarios de los fallos de las aplicaciones. De poco servir, por lo
tanto, que un servidor sea fiable si el software de base de datos que
se ejecuta en dicho servidor falla, ya que el resultado no ser otro
que la ausencia de disponibilidad. sa es la razn de que un solo
equipo no pueda ofrecer los niveles de escalabilidad, disponibilidad y
fiabilidad necesarios que s ofrece un clster.
-
22
Importante
En un clster activo / pasivo el incrementar el nmero de nodos
disponibles en el clster no incrementa la potencia del clster ya que
nicamente un nodo estar ofreciendo el servicio.
2.1.3. Funcionamiento de un clster
El funcionamiento de los clusters es muy simple: se trata de un
conjunto de piezas, por ejemplo, de varios microprocesadores a
travs de una red de alta velocidad que los vincula de forma tal que
funcionan como un nico ordenador pero de una potencia mayor al
convencional.
Un clster se implementa bsicamente con varias computadoras
similares de capacidades no necesariamente altas. Las
computadoras deben conectarse en una LAN compartida dedicada
slo para el clster. El clster de alto rendimiento opera bajo
circunstancias en el que las tareas a procesar se reparten
paralelamente a las computadoras.
Un servicio de clster consta de:
Balanceador de carga.
Sistema para la deteccin de fallos en los nodos del
clster.
Servicio a clusterizar.
Recursos del clster.
2.1.3.1. Balanceador de carga
Los balanceadores de carga permiten optimizar la utilizacin de
los recursos de un clster mediante la asignacin de tareas a los
-
23
nodos con menor carga de trabajo, o con mayor cantidad de
recursos libres.
Son necesarios en las configuraciones que sean Activo / Activo
y/o balanceo de carga.
La funcin de los balanceadores, tambin conocidos como
network dispatcher es redireccionar las peticiones a los servidores
que las estn atendiendo.
Figura 2.5 Balanceador de Carga
2.1.3.2. Sistema para la deteccin de fallos en los nodos del clster
En caso de aparicin de fallo en algn componente, la tolerancia a
fallos busca que el sistema siga trabajando, aunque est
funcionando en modo degradado, hasta que acabe la ejecucin, lo
que podr incidir en mayor o menor medida en sus prestaciones.
-
24
La tolerancia a fallos en un sistema se logra mediante la inclusin
de tcnicas deredundancia. Puede haber redundancia en
cualquier nivel: utilizacin de componentes hardware extra
(redundancia en el hardware), repeticin de las operaciones y
comparacin de los resultados (redundancia temporal),
codificacin de los datos (redundancia en la informacin) e incluso
la realizacin de varias versiones de un mismo programa y del
uso de tcnicas de Replicacin de Datos (redundancia de datos) o
de checkpoint (redundancia de estados).
Los mecanismos para tolerancia a fallos pueden tener un soporte
hardware o software, o bien una combinacin de ambos. En
sistemas en que la incidencia de fallos sea escasa puede ser
recomendable emplear mecanismos de bajo coste con soporte
software, siempre que el algoritmo pueda proporcionar la garanta
de que acabe la ejecucin correctamente aunque se degraden
sus prestaciones.
Es necesario un sistema que detecte cuando existen nodos en el
clster que no estn disponibles para ofrecer el servicio. En este
caso no se enviarn peticiones para ser atendidas si el clster es
Activo / Activo o no se balancear el servicio sobre ellos si es
Activo / Pasivo.
Para detectar esta situacin se utilizan dos tcnicas:
1. Heartbeat.
2. Disco de quorum.
Estos conceptos sern detallados ms adelante.
2.1.3.3. Recursos del clster
Son todos aquellos recursos necesarios para el servicio:
IP de servicio.
-
25
Filesystems.
Scripts para arrancar el servicio
Figura 2.6 Recursos del Clster
2.1.3.4. Servicio a clusterizar
Es el servicio que se quiere clusterizar. Algunos de los servicios
que pueden ser clusterizados son los siguientes:
Servidores de Bases de Datos.
Servidores Web.
Servidores de Balanceo de Carga.
Servidores de Correo.
Servidores Firewall.
Servidores de Archivos.
Servidores DNS.
Servidores DHCP.
-
26
Servidores Proxy Cache
2.1.4. Balanceo de Carga
Con el crecimiento de Internet en los ltimos aos el trfico en la
red ha aumentado de forma radical y con l, la carga de trabajo
que ha de ser soportada por los servidores de servicios,
especialmente por los servidores web.
Para soportar estos requerimientos hay dos soluciones: o bien el
servidor se basa en una mquina de altas prestaciones, que a
largo plazo probablemente quede obsoleta por el crecimiento de
la carga, o bien se encamina la solucin a la utilizacin de la
tecnologa de clustering para mantener un clster de servidores
de tal manera que cuando la carga de trabajo crezca, se aadirn
ms servidores al clster.
Hay varias formas de construir un clster de balanceo de carga.
Una solucin basada en mantener varios servidores aunque no se
trate de un clster propiamente es utilizar un balanceo de carga
por DNS. En este caso, se asigna un mismo nombre a distintas
direcciones IP y se realiza un round robin a nivel de DNS entre
ellas.
En una situacin ideal la carga se repartir equitativamente entre
los distintos servidores. Sin embargo, los clientes cachean los
datos del DNS, con lo que la carga no va a repartirse
equitativamente y quedara desbalanceada.
-
27
Figura 2.7 Balanceo de Carga
Adems, an cuando el balanceo de los accesos de los clientes a
los servicios se haga de forma balanceada, estos clientes pueden
solicitar cargas muy distintas de trabajo al servidor al que se
conectan: mientras un cliente puede querer tan slo ver una
pgina, otro puede solicitar un buen nmero de ellas. Por otra
parte, si un servidor cae, se van a seguir redirigiendo peticiones a
l.
Una solucin mejor es utilizar un balanceador de carga para
distribuir sta entre los servidores de un clster. En este caso el
balanceo queda a nivel de conexin, con una granularidad ms
fina y con mejores resultados. Adems, se podrn enmascarar
ms fcilmente las posibles cadas de los nodos del clster.
El balanceo de carga puede hacerse a dos niveles: de aplicacin
y a nivel IP. Sin embargo, el balanceo a nivel de aplicacin puede
provocar efectos de cuello de botella si el nmero de nodos es
grande. Cada solucin debe elegirse en funcin de las
-
28
necesidades del problema al que hacemos frente. El Linux Virtual
Server utiliza balanceo a nivel IP.
El proyecto Linux Virtual Server (LVS) ofrece parches y
aplicaciones de mantenimiento y gestin que permiten construir
un cluster de servidores que implementa alta disponibilidad y
balanceo de carga sobre el sistema operativo GNU/Linux. El
sistema aparece al usuario externo como un nico servidor
(en realidad, como un nico servidor virtual).
Cada uno de los servidores reales que forman el cluster, es
controlado por un nodo director que se encarga de realizar el
balanceo de carga. Este director corre un sistema operativo
GNU/Linux con un kernel parcheado para incluir el cdigo ipvs,
que es la herramienta ms importante ofrecida por el proyecto
LVS. El director puede ser entendido en trminos generales como
un router con un conjunto concreto de reglas de enrutamiento.
Cuando un cliente solicita un servicio al servidor virtual, el director
escoge un servidor real para que lo ofrezca. Desde ese momento
el director debe mantener la comunicacin entre el cliente y el
servidor real. Esta asociacin entre cliente y servidor real va a
durar slo lo que dure la conexin tcp establecida; cuando se
inicie una nueva conexin el director escoger de nuevo un
servidor real que puede ser distinto del anterior. As, si el servicio
ofrecido es una pgina web, el cliente podra obtener las
imgenes o los textos desde distintos servidores reales ocultos
por el servidor virtual.
Con esta arquitectura, adems del balanceo de carga, estamos
permitiendo que los servidores reales individuales puedan ser
-
29
extrados del LVS, actualizados o reparados y devueltos al clster
sin interrumpir la prestacin de servicio.
Asimismo, el sistema es fcilmente escalable y la alta
disponibilidad en LVS se disea utilizando software mon,
heartbeat, fake y coda, que se utilizan para gestionar la alta
disponibilidad y para mantener una gestin segura, la
comunicacin (hearbeat) entre mquinas y un sistema de ficheros
tolerante a fallos, respectivamente.
2.1.4.1. Balanceadores hardware
Los balanceadores de carga de Hardware son mquinas con el
propsito especfico de balancear la carga.
Este tipo de balanceadores tiene ventajas en cuanto a potencia,
estabilidad y escalabilidad.
Las principales desventajas de este tipo de balanceadores es el
precio que se incurra en el equipo y mantenimiento, as como
tambin que se desperdicia recursos ya que son exclusivamente
dedicadas al balanceo de carga.
Algunas de estas soluciones hardware de balanceo de carga son:
WebMux Load Balancing, de CAI Networks.
Big IP Local Traffic Manager, de F5. Quizs sea la principal
alternativa.
Barracuda Load Balancer, de Barracuda Networks.
Cisco Arrowpoint.
-
30
2.1.4.2. Balanceadores software
Los balanceadores de software son servidores configurados para
realizar la tarea del balanceo. Esto implica instalar en un
computador, un sistema operativo y una aplicacin que se
encargue del balanceo de carga.
Las ventajas que tenemos en estos balanceadores es en cuanto
al precio y que cuando necesitemos un servidor ms potente para
el balanceo de carga, este servidor puede ser reciclado y utilizado
para otra tarea.
En cuanto a sus desventajas se tiene que estos balanceadores
cuentan con una menor potencia y un mayor tiempo de
mantenimiento.
2.1.4.3. Linux Virtual Server - LVS
Linux Virtual Server es una solucin para poder implementar un
servidor virtual altamente escalable y en alta disponibilidad.
Esta solucin consiste en un balanceador de carga, tambin
conocido como director, que ser la mquina que ser accesible
directamente para los clientes y luego tendremos los servidores
que sern aquellos que recibirn las peticiones de los clientes, va
el balanceador de carga, y respondern a las peticiones. Para los
clientes, existirn solo los balanceadores de carga, los cuales
distribuirn la carga entre los servidores reales.
-
31
Figura 2.8 Balanceadores de Carga
Se obtiene escalabilidad en el servicio aadiendo nodos, mientras
que la disponibilidad se lograra identificando al balanceador que
no funciona, y que el nodo aadido tome la funcin de
balanceador, para que el servicio no se vea interrumpido.
Esta solucin nos permitir tener el servicio funcionando casi
continuamente ya que no se ver afectado por posibles cadas de
las mquinas debido a fallos en el suministro elctrico o bien
cortes en el ISP de una determinada granja.
Cualquiera de estos fallos, u otros que pudieran ocurrir, afectarn
a una o varias granjas, pero nunca a todas con lo cual el servicio
seguir funcionando aunque los clientes podrn experimentar
cierta demora en el servicio.
Para los clientes existir un nico servidor (el balanceador) que se
encargar de distribuir la carga entre los servidores reales.
-
32
La escalabilidad en el servicio la conseguiremos aadiendo
nodos, mientras que la disponibilidad se lograr identificando el
nodo o el balanceador que no funciona y reconfigurando el
sistema de tal forma que el servicio no se vea interrumpido. Es
decir no enviando peticiones a un nodo que no pudiera dar
servicio en ese momento.
2.1.5. Deteccin de fallos en los nodos del clster
Un clster debe conocer cuando algn nodo no est disponible para
no enviarle peticiones de servicio. Por lo cual, un sistema de
deteccin de fallos en los nodos del Clster es vital para su
funcionamiento.
Esto se hace de dos formas:
Heartbeat
Disco de qurum
2.1.5.1. Heartbeat
Figura 2.9 Heartbeat
-
33
Es la tcnica ms habitual. Consiste en comunicarse o bien a travs
de una interface de red o puerto serie cada cierto tiempo. Si se
pierde la comunicacin durante un determinado tiempo se supone
que el nodo ha cado.
Para implementar esta tcnica los nodos tiene lneas dedicadas, bien
sea por red o conexiones serie por las que se comunican de forma
continua para verificar el correcto funcionamiento de los nodos.
El funcionamiento de Heartbeat se basa en el envo y recepcin de
seales enviadas por los demonios de Hearbeat que se ejecutan en
ambas mquinas, a estas seales se les conocen como latidos.
La diferencia entre el servidor maestro y el esclavo, radica en la
prioridad que tienen para ofrecer un servicio. Aqu, el esclavo solo
ofrecer el servicio cuando deje de escuchar los latidos del maestro
durante periodo de tiempo determinado, pasado el cual se supondr
que el servidor maestro dej de funcionar.
Una vez que el esclavo vuelva a escuchar los latidos del maestro,
este tomar el control nuevamente, a menos que dentro de la
configuracin de Heartbeat se haya colocado la directiva
auto_failback en off. Esta directiva puesta en off, quiere decir que si
la mquina que era maestro vuelve a funcionar, ya no retomar el
control del servicio, sino se convertir en la nueva esclava.
El maestro y esclavo pueden comunicarse por medio de dos
interfaces, el puerto serial (RS-232) o las tarjetas Ethernet.
Puede darse el caso de un error en la interfaz que une a ambas
mquinas que imposibilita la llegada de latidos hacia el esclavo. Si
-
34
sucede esto, el esclavo interpretar errneamente que el servidor
maestro ha cado y tratara de tomar el control de la prestacin del
servicio, cuando el servicio nunca ha dejado de prestarse.
2.1.5.2. Disco de quorum
Disco de quorum es una tcnica complementaria que lo que se hace
es que todos los nodos del clster escriben su estado en un disco y
de esa forma se determina quien est disponible para dar el servicio.
Si un nodo tiene problemas de red y no llega a los otros nodos
pensar que los otros nodos no estn disponibles e intentar
hacerse con el servicio.
Si disponemos de dispositivos serie para el heartbeat entonces
dispondremos de una forma de comprobar que los otros nodos estn
funcionando correctamente y el problema es nuestro. De no
disponerlo se asumir de forma incorrecta que los otros nodos han
fallado, intentando asumir el control del clster. Para evitar esto se
utiliza el disco de quorum.
Cada nodo escribe de forma continua su estado en el disco y de esta
forma se puede verificar que nodos estn disponibles para hacerse
con el servicio en el clster.
Importante
El disco de quorum no es una tcnica que sustituya al heartbeat es
una tcnica que debe usarse como complemento al heartbeat.
-
35
Figura 2.10 Disco de Quorum
-
36
CAPITULO 3
INTRODUCCION
En este captulo se presentarn las soluciones de software libre para
mitigar el problema de alta disponibilidad y balanceo de carga, se
expondrn sus caractersticas as como las herramientas que hacen
posible la construccin de dichas soluciones.
Adems se llevar a cabo una comparativa de las herramientas
existentes para la realizacin del clster, adems de ello, se describirn
tales herramientas de forma breve en cuanto a sus componentes y su
funcionamiento.
DIAGNOSTICO
3.1. Herramientas de open source para la construccin del Clster
Podemos encontrar una amplia variedad de aplicaciones para la
creacin de clsters, la utilizacin de una u otra de estas depender
de la complejidad de instalacin, uso especfico y ventajas de este
sobre otras herramientas. De las opciones que se pueden encontrar
estn:
openMosix.
Oscar.
Piranha.
Linux Virtual Server.
Ultramonkey.
A continuacin la tabla 3.1 muestra las principales caractersticas de
cada herramienta para la construccin de clsters.
-
37
Herramienta. Caractersticas.
openMosix
Parche al kernel de GNU/Linux.
Algoritmo interno de balance de carga que migra
los procesos entre nodos.
Migracin de procesos totalmente transparente.
Auto descubrimiento de nuevos nodos openMosix
en la red del clster.
OSCAR
Permite instalar un clster tipo Beowulf.
Contiene todo el conjunto de paquetes necesarios
para programar y administrar el clster.
Formado por dos componentes principales SIS
(System Installation Suite) y ODA (OSCAR
Database API).
Piranha
Implementacin de software de alta disponibilidad.
Interfaz web para control completo del clster.
Posee herramientas para su monitorizacin.
Balance mediante direcciones IP.
Requiere el sistema operativo Red Hat Enterprise.
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.
Clster completamente transparente al usuario
final.
Mecanismo para que el clster funcione con una IP
pblica.
Permite balance de carga y alta disponibilidad.
Incluye monitorizacin de servidores reales y
nodos de balance.
Permite el manejo de protocolos como HTTP, FTP,
-
38
Ultramonkey
DNS, entre otros.
Permite usar iptables o ipchains para marcar los
paquetes que pertenezcan al servicio prestado por
el clster.
Usado desde clsters de dos nodos hasta grandes
sistemas.
Tabla 3.1 Caractersticas de Herramientas para Clsters.
Por ltimo, se mostrarn las ventajas y desventajas de cada una de
las herramientas anteriormente mencionadas, pues es importante
tener presente esta comparativa para hacer una primera
aproximacin a la eleccin de una sola herramienta para llevar a
cabo una implantacin eficaz y sencilla que cubra las necesidades
solicitadas; esto se refleja en la tabla 3.2.
Herramienta. Ventaja. Desventaja.
openMosix
No se requieren paquetes
adicionales.
No son necesarias
modificaciones en el
cdigo de openMosix.
Migracin de procesos.
Depende del kernel.
No migra todos los
procesos siempre.
Problemas con
memoria compartida.
OSCAR
Es una compilacin auto
instalable.
Infraestructura de software
para instalar y administrar
un clster.
Posee bibliotecas y
Falla la deteccin de
algunos componentes
de hardware en
versiones anteriores a
la 3.
Soporte para
distribuciones basadas
en RPMs solamente
-
39
compiladores para uso en
clsters.
para versiones
anteriores a la 5.
Requiere que la LAN no
sea usada para instalar
software en el clster.
Piranha
Soporte por parte de Red
Hat Inc.
Fcil instalacin debido al
formato de distribucin.
Administracin y manejo
mediante interfaz web.
Monitorizacin de
servidores reales.
Al momento solo
disponible para
versiones
empresariales de Red
Hat.
Dependiente del
sistema operativo Red
Hat Enterprise.
Linux Virtual Server
- LVS
Fcil comprensin 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 nmero de
servidores reales es
elevado se genera
mucho trfico en la red
de trabajo.
Mltiples esquemas de
configuracin.
Rene varias herramientas
de una manera sencilla.
Varios formatos para su
instalacin.
Amplia documentacin
sobre cada componente.
Los nodos directores
tienen que ejecutar
estrictamente el
sistema operativo
GNU/Linux.
-
40
Ultramonkey Instrucciones de
instalacin para las
distribuciones de
GNU/Linux ms comunes
en servidores.
Se apoya en el proyecto
LVS para algunos
componentes.
No es dependiente de una
distribucin de GNU/Linux
en particular.
Segn el esquema de
configuracin 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 Clster.
3.2. Comparacin 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,
Cdigo
fuente.
Todas.
Balanceo de
carga de
procesos sin
alta
disponibilidad.
No requiere
paquetes
adicionales y
hace
migracin de
procesos.
Dependiente
del kernel y
posee
problemas con
memoria
compartida.
Auto instalable
En versiones
anteriores a la
tercera falla la
deteccin de
-
41
OSCAR
RPM,
Cdigo
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
instalacin de
software.
Piranha
RPM.
Red Hat
Enterprise 4 o
posteriores.
Posee
herramientas
propias para
ambos
aspectos.
Soporte de
Red Hat,
administracin
y manejo
mediante
interfaz web.
Actualmente
disponible solo
en formato
RPM y para
versiones
empresariales.
Linux
Virtual
Server
RPM, DEB,
Cdigo
fuente.
Todas.
Incluye
herramientas
de cdigo
abierto para
ambos
aspectos.
Amplia gama
de
configuracione
s, funcin a
nivel TCP/IP y
manejo de
distintos
protocolos.
Instalacin por
segmentos;
con un gran
nmero de
servidores
reales el
trfico crece
de manera
significativa.
Ultramonke
y
RPM. DEB,
Cdigo
fuente.
Basadas en
Debian, Red
Hat Enterprise
4 y mediante
compilacin
de cdigo
fuente.
Uso de
componentes
de LVS para
ambos
aspectos
aadiendo
algunas
mejoras y
Mltiples
configuracione
s, manejo de
distintos
protocolos,
funcin a nivel
TCP/IP,
marcas de
firewall y
Los nodos de
balance de
carga debern
ejecutar el
sistema
operativo
GNU/Linux;
dependiendo
del esquema
llega a ser
-
42
herramientas. ampliacin de
LVS.
complejo de
configurar.
Tabla 3.3 Comparacin de herramientas para clster.
Una de las herramientas las ms usadas es Piranha de la empresa
Red Hat., que incorpora balance de carga mediante direcciones IP y
tambin hace la inclusin de cdigo del proyecto LVS, en esta
herramienta Red Hat incorpor mejoras; para poder hacer uso
eficiente de Piranha es recomendado el uso de Red Hat Enterprise
Linux 4 o posterior, su sencillez en instalacin y amplio soporte por
parte de dicha empresa brinda satisfaccin al hacer una
implementacin con esta. Fuera del pago de la licencia para el
sistema operativo el software de Piranha est disponible de manera
gratuita para usuarios registrados de esta distribucin.
Junto a la anterior herramienta se puede encontrar el proyecto LVS
el cual fue iniciado por Wensong Zhang en Mayo de 1998 y su
principal objetivo era desarrollar un servidor GNU/Linux de alto
rendimiento que proporcione un buena escalabilidad, confianza y
robustez usando la tecnologa de clster. De los avances ms
importantes de LVS es el desarrollo de un sistema IP avanzado de
balanceo de carga por software (IPVS), balance de carga por
software a nivel de aplicacin y componentes para la gestin de
clster. Se puede usar LVS como solucin para construir sistemas
altamente escalables, donde se garantiza una alta disponibilidad de
los servicios de red como el correo electrnico, voz sobre IP y el
servicio web.
La siguiente opcin es Ultramonkey, siendo una de las herramientas
ms completas en cuanto a balanceo de carga y alta disponibilidad;
ya en su tercera versin cuenta con formatos de instalacin para
-
43
diversas distribuciones de GNU/Linux como Debian y Red Hat. Esta
herramienta solo puede ser usada en estaciones cuyo sistema
operativo sea GNU/Linux siendo este uno de sus pocos
inconvenientes en lo que respecta a la independencia de plataforma.
Hace uso de las tecnologas de LVS, Linux-HA y Ldirectord para
lograr ambas metas que son el balance de carga y la alta
disponibilidad. De entre los posibles esquemas de configuracin se
cuenta con soluciones separadas o una que incorpore ambas, as
como tambin un esquema estndar o uno ms completo.
La herramienta OSCAR es una coleccin de software de cdigo
abierto para crear un clster sobre GNU/Linux desarrollada por el
Grupo de Clsters Abiertos (OCG Open Clster Group). El objetivo
primario del grupo de trabajo OSCAR es conseguir que la
instalacin, la configuracin y la administracin de un clster de
tamao modesto, sea fcil. Cualquier cosa necesaria para un clster
como instalacin y configuracin, mantenimiento, programacin
(paralela), sistemas de encolamiento, programacin de tareas, est
incluida en OSCAR. Su principal labor es para cmputo de alto
rendimiento.
En Open Mosix los procesos no saben en qu nodo del clster se
ejecutan, y es el propio Open Mosix el responsable de "engaarlos",
y redirigir las llamadas al sistema al nodo del clster en el que se
lanz el proceso. Open Mosix implementa un algoritmo de balance
de carga que permite repartir de forma ptima la carga, si est el
clster bien calibrado. Open Mosix puede migrar cualquier proceso
mientras que no haga uso de los segmentos de memoria
compartida. Segn la calibracin, migrarn procesos ms ligeros, o
ms pesados.
-
44
Dadas las caractersticas vistas con anterioridad en la tabla 3.3 y
esto aunado a los fines que persiguen hacen inclinar la balanza por
las siguientes opciones mejor adaptadas a este campo que son:
Piranha.
Linux Virtual Server.
Ultramonkey.
Se proceder ahora a describir cada una de las tres herramientas
ms comunes, cabe destacar que cada una es revisada de manera
breve resaltando mediante figuras el funcionamiento de cada una de
ellas as como mencionando los componentes de cada una.
3.2.1. Herramientas de balanceo de carga y alta disponibilidad
3.2.1.1. Piranha
Es un conjunto de aplicaciones en un ambiente bien unido para los
administradores que desean instalar servicios de clster en
ambientes GNU/Linux. Un clster piranha se compone de los
siguientes elementos:
El parche IPVS para el kernel.
El demonio LVS para manejar las tablas IPVS a travs de
ipvsadm.
El demonio nanny para monitorizar servicios y servidores.
El demonio pulse para controlar el estado del resto de
demonios del clster y la entrada en funcionamiento del nodo
de balance de carga de respaldo en caso de fallo del primario.
La interfaz grfica piranha para administrar el clster.
Todos estos demonios utilizan el mismo archivo de configuracin
ubicado en el directorio /etc/lvs.cf para su funcionamiento. Como un
valor aadido a piranha este es capaz de adaptar los pesos de los
algoritmos de planificacin automticamente segn las estadsticas
-
45
de funcionamiento de cada servidor. En la figura 3.1 se aprecia
cmo se compone un clster con Piranha.
Figura 3.1 Esquema de funcionamiento de Piranha.
3.2.1.2. Linux Virtual Server
Es un software para el balanceo de carga que permite crear un
clster de forma rpida y eficaz sin hacer grandes inversiones en
hardware dedicado. Es una solucin ideal para aquellas empresas
que quieren ahorrar costos permitiendo tener tras una nica
direccin IP pblica muchos servidores reales y servicios de forma
transparente a los usuarios.
Es implementado como un conjunto de parches al kernel de
GNU/Linux y un programa denominado ipvsadm. La principal meta
de LVS es proveer un mecanismo de migracin de sockets. Un
clster de este tipo est formado por dos tipos de mquinas, los
nodos o servidores reales que corren con los servicios habituales
que estos suelen proveer y los nodos directores o de balanceo de
-
46
los cuales uno de ellos ser el principal y el resto estarn preparados
para actuar de respaldo del principal para cuando este falle. LVS
funciona a nivel TCP/IP, lo que se conoce como un switch de nivel 4
o mejor conocido como capa 4. Lo que en realidad administra LVS
son direcciones y puertos de origen y destino, y toma decisiones
para balancear la carga con esta informacin.
LVS soporta tres modos de trabajo distintos, estos modos definen el
mtodo en que el nodo de balanceo retransmitir las
comunicaciones provenientes de los usuarios a los servidores reales
definidos.
LVS permite balancear muchos protocolos distintos. LVS se ha
usado con HTTP, HTTPS, FTP, etc. En la figura 1.10 se muestra su
funcionamiento.
Figura 3.2 Esquema de funcionamiento de LVS.
-
47
3.2.1.3. Ultramonkey
Es un proyecto que integra diferentes herramientas de software libre
para conseguir alta disponibilidad y balanceo de carga en redes LAN
redes de rea local. Estas herramientas son: LVS, Heartbeat,
Ldirectord y MON como lo muestra la figura 3.3.
3.2.1.3.1. Componentes Ultramonkey
LVS realiza balanceo de carga y facilita la alta disponibilidad entre
los servidores reales. Sin embargo, el nodo de balanceo de carga se
convierte en un punto nico de fallo, si se quiere alta disponibilidad
se deber aadir otro nodo de balanceo de respaldo y usar software
de alta disponibilidad que le permita tomar el papel del nodo de
balanceo de carga principal.
3.2.1.3.1.1. Heartbeat
Funciona enviando peridicamente un paquete, que si no llegara,
indicara que un servidor no est disponible, por lo tanto se sabe que
el servidor ha cado y se toman las medidas necesarias. Se
recomienda el uso de puertos serie puesto que estn aislados de las
tarjetas de red. Soporta mltiples direcciones IP y un modelo
servidor primario/secundario.
Los mensajes de Heartbeat se envan por todas las lneas de
comunicacin a la vez, de esta manera, si una lnea de apoyo cae,
se avisar de ese problema antes de que la lnea principal caiga y no
haya una lnea secundaria para continuar el servicio. Heartbeat
tambin se preocupa por la seguridad, permitiendo firmar los
paquetes con CRC de 32 bits, MD5 y SHA1.
-
48
3.2.1.3.1.2. Ldirectord
Se encarga de monitorizar que los servidores reales permanezcan
funcionando peridicamente, enviando una peticin a una direccin
URL (Uniform Resource Locator) conocida y comprobando que la
respuesta contenga una cadena concreta. Si un servidor real falla,
entonces el servidor es quitado del conjunto de servidores reales y
ser reinsertado cuando vuelva a funcionar correctamente. Si todos
los servidores fallan, se insertar un servidor de fallos, que ser
quitado una vez que los servidores vuelvan a funcionar.
3.2.1.3.1.3. Mon (Service Monitoring Daemon)
Es un software para la monitorizacin del sistema. Este permite
definir una serie de alarmas y acciones a ejecutar cuando un servicio
deja de funcionar y se utiliza ampliamente como componente de
monitorizacin de recursos para Heartbeat.
Figura 3.3 Componentes de Ultramonkey.
Mientras el software Ultramonkey funciona por s mismo en
GNU/Linux, este puede proporcionar servicios de clster para
-
49
virtualmente cualquier red de servicios corriendo en un sistema
operativo que pueda comunicarse usando TCP o UDP. Soporta un
amplio rango de protocolos, con comprobacin nativa de integridad
para: Web, Mail, FTP, News, LDAP y DNS. Tambin provee de
paquetes binarios para una lista de distribuciones seleccionadas.
La figura 3.4 muestra un esquema tpico de funcionamiento de
Ultramonkey en el cual existe balanceo de carga y alta disponibilidad.
Figura 3.4 Esquema de funcionamiento de Ultramonkey.
-
50
CAPITULO 4
INTRODUCCION
En este captulo se llevar a cabo un anlisis de los mtodos
existentes de balanceo de carga, dado que estos llegan a ser
complejos solamente se tratar la teora ms bsica de operacin;
adicionalmente se realizar la toma de decisin de una herramienta
para su implementacin.
DISEO
4.1. Tipos de balanceo de carga
Existen dos formas simples para montar un clster y distribuir la
carga entre los equipos mostradas en la tabla 4.1 a continuacin.
Mtodo Ventajas Desventajas
DNS
Round
Robin.
Distribucin de la carga
entre servidores reales
de forma pseudo-
aleatoria.
Es el ms simple de
implementar.
El cache de la
informacin en la
jerarqua 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 segn
el URL solicitado.4
Uso de nodo
de balanceo
de carga.
Este nodo distribuye las
conexiones.
Se aumenta la
sensacin de unidad
del clster.
nica direccin IP
pblica 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.