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
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
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
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.
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.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
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
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
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
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
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.
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
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.
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.
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
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.
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.
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.
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.
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:
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.
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:
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.
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
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.
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
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
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.
“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
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,
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
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.
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
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.
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.
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 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.
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
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
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.
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.
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.
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
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
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.
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.
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.
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
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.
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
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
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
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.
