Balanceo de Carga en Centos

UNIVERSIDAD ALFREDO PÉREZ GUERRERO UNAP

CARRERA: SISTEMAS DE INFORMACION Y NETWORKING

PROYECTO DE GRADO

PARA LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN SISTEMAS INFORMATICOS Y NETWORKING

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

Autor: Flavio Mauricio Gallardo Padilla Director: Ing. Nelio Brito

Mayo del 2011

Quito, 13 de mayo del 2011

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

De nuestras consideraciones: Por medio de la presente CERTIFICAMOS, que el señor estudiante – egresado Flavio Mauricio Gallardo Padilla, identificado con el número de cédula 1710049139 estudiante de la carrera de Ingeniería en Sistemas y Networking de la UNAP, una vez realizada la dirección y las evaluaciones correspondientes según la normativa de la universidad, ha concluido satisfactoriamente con el trabajo de grado Titulado “DISEÑO DE UNA SOLUCIÓN PARA SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON OPEN SOURCE”. Por consiguiente, otorgamos la aptitud para la presentación del grado oral del mencionado estudiante.

Agradeciendo su atención

Ing. Nelio Brito Director

Ing. Fredy Molina Evaluador

Ing. Rommel Caicedo Evaluador

Quito, 13 de mayo del 2011

Señores: Universidad Alfredo Pérez Guerrero UNAP Presente.-

De mis consideraciones:

Yo, Flavio Mauricio Gallardo Padilla, identificado con el número de cédula 1710049139, estudiante egresado de la UNAP de la Carrera de Ingeniería en Sistemas y Networking, por medio de la presente CERTIFICO que el presente Trabajo

de

Grado

titulado:

“DISEÑO

DE

UNA

SOLUCIÓN

PARA

SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON OPEN SOURCE”; es de mi plena autoría y no constituye plagio ni copia alguna constituyéndose un documento único.

Es todo en cuanto puedo decir en honor a la verdad

Agradeciendo su atención

Mauricio Gallardo C.I. 1710049139 Estudiante Egresado de la UNAP

AGRADECIMIENTO

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

DEDICATORIA

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

INDICE

INTRODUCCION ................................................................................................. i CAPITULO 1 ....................................................................................................... 1 GENERALIDADES ............................................................................................. 1 1.1. PLANEAMIENTO DEL PROBLEMA ............................................................ 1 1.2. FORMULACION DEL PROBLEMA .............................................................. 2 1.3. SISTEMATIZACION .................................................................................... 2 1.4. OBJETIVO GENERAL ................................................................................. 2 1.5. OBJETIVOS ESPECIFICOS ........................................................................ 3 1.6. JUSTIFICACIÓN .......................................................................................... 3 1.7. ALCANCE .................................................................................................... 4 CAPITULO 2 ....................................................................................................... 6 INTRODUCCION ................................................................................................ 6 FUNDAMENTACION TEORICA ......................................................................... 6 MARCOS DE REFERENCIA (Teórico, Conceptual) ........................................... 6 2.1. MARCO TEORICO ...................................................................................... 6 2.1.1. Clustering .................................................................................................. 6 2.1.1.1. Antecedentes ......................................................................................... 6 2.1.1.2 Que es el clustering? .............................................................................. 7 2.1.1.3. Tipos de clúster ...................................................................................... 8 2.1.1.4. High Performance .................................................................................. 8 2.1.1.5. Clúster Activo/Pasivo ........................................................................... 14 2.1.1.6. Clúster Activo/Activo ............................................................................ 14 2.1.2. Arquitectura de Clustering....................................................................... 15 2.1.2.1. Alta disponibilidad ................................................................................ 16 2.1.2.2. Escalabilidad ........................................................................................ 20 2.1.3. Funcionamiento de un clúster ................................................................. 22 2.1.3.1. Balanceador de carga .......................................................................... 22 2.1.3.2. Sistema para la detección de fallos en los nodos del clúster ............... 24 2.1.3.3. Recursos del clúster ............................................................................ 25 2.1.3.4. Servicio a clusterizar ............................................................................ 25

2.1.4. Balanceo de Carga ................................................................................. 26 2.1.4.1. Balanceadores hardware ..................................................................... 29 2.1.4.2. Balanceadores software....................................................................... 30 2.1.4.3. Linux Virtual Server - LVS .................................................................... 30 2.1.5. Detección de fallos en los nodos del clúster ........................................... 32 2.1.5.1. Heartbeat ............................................................................................. 32 2.1.5.2. Disco de quorum .................................................................................. 34 CAPITULO 3 ..................................................................................................... 36 INTRODUCCION .............................................................................................. 36 DIAGNOSTICO ................................................................................................. 36 3.1. Herramientas de open source para la construcción del Clúster ................. 36 3.2. Comparación de las herramientas de balanceo de carga y alta disponibilidad .................................................................................................... 40 3.2.1. Herramientas de balanceo de carga y alta disponibilidad ....................... 44 3.2.1.1. Piranha................................................................................................. 44 3.2.1.2. Linux Virtual Server .............................................................................. 45 3.2.1.3. Ultramonkey ......................................................................................... 47 3.2.1.3.1. Componentes Ultramonkey ............................................................... 47 3.2.1.3.1.1. Heartbeat ....................................................................................... 48 3.2.1.3.1.2. Ldirectord ....................................................................................... 48 3.2.1.3.1.3. Mon (Service Monitoring Daemon)................................................. 49 CAPITULO 4 ..................................................................................................... 50 INTRODUCCION .............................................................................................. 50 DISEÑO ............................................................................................................ 50 4.1. Tipos de balanceo de carga ....................................................................... 50 4.1.1. Modos de balanceo de carga en LVS ..................................................... 51 4.1.2. Resumen de los métodos de balanceo ................................................... 56 4.1.3. Planificación del balanceo de carga ........................................................ 57 4.2. Elección de una herramienta para balanceo de carga y alta disponibilidad .......................................................................................................................... 62 CAPITULO 5 ..................................................................................................... 69 INTRODUCCION .............................................................................................. 69 IMPLEMENTACION EN MAQUINAS VIRTUALES ........................................... 69

5.1 INSTALACION Y CONFIGURACION DEL CLUSTER ................................ 69 5.1.1 SELECCIÓN DE NODOS PARA EL CLÚSTER ...................................... 71 5.1.2 Instalación de los nodos........................................................................... 74 5.1.3. Configuración de los servidores web ...................................................... 76 5.2. Instalación de CentOs ................................................................................ 78 5.3. Instalación de Ultramonkey ........................................................................ 78 5.3.1. Selección de topología de instalación de ultamonkey ............................. 79 5.3.1.1. Directores Linux o Nodos de balanceo ................................................ 80 5.3.1.2. Nodos servidores o servidores reales .................................................. 81 5.4. Configuración de Heartbeat en los nodos de balanceo ............................. 81 5.5. Configuración de la red de trabajo ............................................................. 81 5.6. Configuración del clúster ........................................................................... 82 5.6.1. Directores Linux, nodos de balanceo ...................................................... 82 5.6.2. Heartbeat ................................................................................................ 82 5.7. Instalar y configurar IPROUTE en los nodos servidores ............................ 83 5.8. Pruebas de desempeño ............................................................................. 84 5.8.1. Herramientas para medición de rendimiento .......................................... 86 5.8.1.1. Selección de una herramienta para medición de rendimiento ............. 86 CONCLUSIONES ............................................................................................. 91 Anexo 1 Instalación de Centos ......................................................................... 95 Anexo 2 Instalación de la Solución ................................................................. 118

INDICE DE FIGURAS

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

Figura 5.8. Tráfico en la red con tcpdump. .................................................... 89 Figura 5.9. Salida de tráfico en la red con tcpdump. ..................................... 90

INDICE DE TABLAS

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

i

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

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

Un clúster es un conjunto de maquinas, conectadas entre sí en red y funcionando en paralelo y compartiendo recursos para cooperar en cargas de trabajo complejas y conseguir mayor eficacia que un solo equipo.

Al hablar de clúster, tenemos un numeroso listado de diversas aplicaciones que implementan distintos tipos de clúster, dependiendo de las necesidades que posee la organización y la aplicación a clusterizar.

Dentro de los clúster más comunes, se encuentra el clúster de alta disponibilidad, en el cual uno de los nodos actúa pasivamente mientras el nodo activo recibe todas las peticiones a los servicios que ofrece. En caso de que el nodo activo tenga alguna falla en los servicios, el nodo pasivo toma el control

ii

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

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

1

CAPITULO 1 GENERALIDADES

1.1. PLANEAMIENTO DEL PROBLEMA Las empresas actualmente se han visto en el problema de suspender temporalmente sus operaciones debido a incidentes ocurridos en los servidores de servicios tales como proxy, correo electrónico, ftp, web, etc., dando origen a prestar servicios de baja calidad a sus clientes poniendo en riesgo la continuidad del negocio, lo que ocasiona pérdidas económicas.

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

Existen equipos que permiten balanceo de carga y alta disponibilidad mediante hardware, pero la adquisición de estos significa una inversión para las empresas contrariamente a las soluciones de software open source que no necesitan pagar ningún valor de licenciamiento.

De no contar con una solución al problema de alta disponibilidad y balanceo de carga por software se perderá la opción de contribuir a una investigación e implementación de este tipo.

Mediante la implementación de la solución, las empresas aseguran el normal desenvolvimiento de sus operaciones, minimizando sustancialmente el riesgo tecnológico dando continuidad al negocio y por consiguiente a sus operaciones, se centrará en la técnica de obtener una alta disponibilidad y balanceo de carga

2

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

1.2. FORMULACION DEL PROBLEMA ¿Encontrar la solución que permita mantener un alto nivel de disponibilidad y balanceo de carga, con herramientas open source, dando continuidad a los servicios?. Considerando la experiencia adquirida en la implementación, administración y mantenimiento de servidores Linux en los últimos años de servicio profesional.

1.3. SISTEMATIZACION ¿Qué herramientas open source nos permiten aplicar alta disponibilidad y balanceo de carga? ¿Qué herramientas open souce se utilizarán para la implementación de la solución? ¿Qué necesitan las empresas para solucionar su problema de alta disponibilidad y balanceo de carga?

1.4. OBJETIVO GENERAL Diseñar una solución de alta disponibilidad y balanceo de carga, para dotar de servicios que permitan dar continuidad al negocio en las operaciones realizadas por las empresas, con software open source.

3

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

Diseñar una solución que permita ofrecer servidores de alta disponibilidad y balanceo de carga mediante software libre.

Implementar en un ambiente de laboratorio la solución diseñada, para asegurar el normal desenvolvimiento de las operaciones en cualquier empresa. Dicho laboratorio se lo implementará en máquinas virtuales.

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

4

Para poder incrementar la base científica relacionada con proyectos de software open source y minimizar el riesgo tecnológico. Se utiliza open source por que es software libre, es decir no se debe incurrir en gastos de licenciamiento para su uso. Desde

el

punto

de

vista

metodológico,

esta

investigación

generará

conocimiento válido y confiable dentro del área de las TICS , para futuras implementaciones. Esta investigación abrirá nuevos caminos en empresas que presenten situaciones similares sirviendo a estas como marco referencial.

1.7. ALCANCE El proyecto abarcará la investigación sobre las herramientas de clúster que nos ofrece el software libre, para de esta manera analizar la mejor opción para ser implementada, esta investigación permitirá además adquirir conocimiento para futuras implementaciones. Después de conocer las opciones de cluster con open source, se realizará un diagnostico sobre las herramientas disponibles para proponer una solución que permita de forma adecuada implementar la tecnología elegida, tomando en cuenta siempre la mejor alternativa.

Se creará un laboratorio con máquinas virtuales para la implementación en un ambiente de pruebas, que contendrá servicios como http, mail, ftp, proxy, además se obtendrá pruebas de los resultados de funcionamiento de la solución.

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

5

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

6

CAPITULO 2

INTRODUCCION Este capítulo contiene conceptos fundamentales que son necesarios conocer para la elaboración del proyecto como: clustering, tipos de clúster, arquitectura de clustering, alta disponibilidad, balanceo de carga. Adicionalmente se relata una breve historia del inicio, desarrollo y evolución de la tecnología relacionada con los clúster.

FUNDAMENTACION TEORICA

MARCOS DE REFERENCIA (Teórico, Conceptual)

2.1. MARCO TEORICO 2.1.1. Clustering 2.1.1.1. Antecedentes En el verano de 1994 Thomas Sterling y Don Becker, trabajando para el CESDIS (Center of Excellence in Space Data and Informarion Sciencies) bajo el patrocinio del Proyecto de las Ciencias de la Tierra y el Espacio (ESS) de la NASA, construyeron un Clúster de Computadoras que consistía en 16 procesadores DX4 conectados por una red Ethernet a 10Mbps, ellos llamaron a su máquina Beowulf. La máquina fue un éxito inmediato y su idea de proporcionar sistemas basados en COTS (equipos de sobremesa) para satisfacer requisitos de cómputo específicos se propagó rápidamente a través de la NASA y en las comunidades académicas y de investigación. El esfuerzo del desarrollo para esta primera máquina creció rápidamente en lo que ahora llamamos el Proyecto Beowulf. Este Beowulf construido en la NASA en 1994 fue el primer clúster de la historia, y su finalidad era el cálculo masivo de datos. Desde entonces, la tecnología de clusters se ha desarrollado enormemente.

7

2.1.1.2 Que es el clustering? Clustering es un conjunto de maquinas, conectadas entre sí en red y funcionando en paralelo y compartiendo recursos para cooperar en cargas de trabajo complejas y conseguir mayor eficacia que un solo equipo. Dado que se comporta como un único gran recurso. Cada una de las máquinas que forman el clúster recibe el nombre de nodo.

Figura 2.1 Clúster de computadores

Esta tecnología ha evolucionado para beneficio de diversas actividades que requieren el poder de cómputo y aplicaciones de misión crítica.

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

8

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

2.1.1.3. Tipos de clúster Dependiendo del tipo de solución que busquemos podemos clasificar los clusters en varios tipos:

High Performance High Availability Load Balancing

2.1.1.4. High Performance

Tipo de Clúster

Descripción

Alto rendimiento

Conjunto de computadoras diseñado para brindar

(High Performance)

altas prestaciones en cuanto a capacidad de cálculo. Conjunto de dos o más computadoras que se

Alta disponibilidad

caracterizan por mantener una serie de servicios

(High Availability)

disponibles y compartidos, se caracterizan por estar constantemente monitorizándose entre sí. Compuesto por una o más computadoras que actúan

Balanceo de carga

como interfaces primarias del clúster y se ocupan de

(Load Balancing)

repartir las peticiones de servicio que recibe el clúster a los nodos que lo conforman.

Tabla 2.1 Tipos de Clúster

9

Además de la clasificación general de los tipos de clúster que se pueden encontrar, es preciso destacar que se pueden tener los siguientes subtipos en cada una de las categorías según se muestra en la tabla 2.2.

Subtipo Homogéneo

Descripción Es donde todos los nodos poseen una configuración de hardware y software iguales.

Semi-

Es donde se poseen arquitecturas y sistemas

homogéneo

operativos similares pero de diferente rendimiento.

Heterogéneo

Es donde se poseen hardware y software distintos para cada nodo.

Tabla 2.2 Subtipos de Clúster

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

Figura 2.2 Componentes de un clúster

10

Para entender mejor estos componentes, es recomendable el análisis mediante la tabla 2.3, en ella se puede observar cada componente y una descripción del mismo comenzando por la interconexión de los equipos.

Componente

Descripción Estas son las conexiones de los nodos a la red de trabajo

Conexiones de red.

del clúster siendo tan complejas como lo sean las tecnologías y medios utilizados en su instalación.

Protocolos de comunicación y

Aquí

normalmente

se

cuenta

con

el

protocolo

de

comunicaciones TCP/IP y servicios de transporte de datos.

servicios. Son simples computadoras o sistemas multiprocesador; en Nodos.

estos se hospedan el Sistema Operativo, el middleware y lo necesario para la comunicación a través de una red. Se define a grandes rasgos como un programa o conjunto

Sistema Operativo.

de ellos que están destinados a gestionar de manera eficaz los recursos de una computadora. Como ejemplo se tiene Unix, Mac OSX. Es un software que actúa entre el Sistema Operativo y las aplicaciones con la finalidad de proveer a un clúster las

Middleware.

características de interfaz, herramientas de optimización y mantenimiento del sistema, como también un crecimiento o escalabilidad. Entre los más populares se encuentra openMosix. Son todos aquellos programas que se ejecutan sobre el

Aplicaciones.

middleware; estos son diseñados para su ejecución en entornos de cómputo paralelo o aprovechamiento del tipo de clúster. Tabla 2.3 Componentes de un Clúster

11

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

normalmente

en

los

sistemas

multiprocesadores

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

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

Cuando

los

nuevos

dispositivos,

incluyendo

procesadores, memoria, disco y redes están disponibles se pueden integrar a los nodos del clúster de manera fácil y rápida permitiendo que sean los sistemas paralelos que primero se benefician de tales avances. Lo mismo se cumple para los beneficios de un mejoramiento constante en el rubro de precio-rendimiento en la tecnología. Los clústers son actualmente la mejor opción para seguir la pista de los adelantos tecnológicos y responder rápidamente a las ofertas de nuevos componentes.

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

normalmente

en

los

sistemas

multiprocesadores

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

Un clúster puede ser usado para solucionar una variedad de problemas dependiendo del tipo que se tenga, como ya se dijo existen los de alto rendimiento, balanceo de carga y alta disponibilidad. Los dos primeros resuelven problemas como:

12



Cálculos matemáticos.



Rendering (construcción/generación) de gráficos.



Compilación de programas.



Compresión de datos.



Descifrado de códigos.



Rendimiento del sistema operativo, (incluyendo en él, el rendimiento de los recursos de cada nodo).



En general cualquier problema de propósito general que requiera de gran capacidad de procesamiento.

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



Sistemas de información redundante.



Sistemas tolerantes a fallos.



Balance de procesos entre varios servidores.



Balance de conexiones entre varios servidores.



En general cualquier problema que requiera almacenamiento de datos siempre disponible con tolerancia a fallos.

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

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

13

Realmente no hay sistemas que puedan asumir la alta disponibilidad en realidad, se requiere que el clúster sea tolerante a los fallos. En dicho caso se pretende ocultar al usuario final la presencia de los fallos del sistema empleando redundancia en el hardware y en el software e incluso redundancia temporal.

La redundancia en el hardware consiste en añadir componentes replicados para encubrir los posibles fallos mientras que la redundancia de software incluye la administración del hardware redundante para asegurar su correcto funcionamiento al hacer frente a la caída de algún elemento. Y por último la redundancia en el tiempo hace referencia a la repetición de la ejecución de un conjunto de instrucciones para asegurar el comportamiento correcto en caso de que ocurra un fallo.

Por su parte, el balanceo de carga en el contexto del servicio web es la toma de decisión de cuál nodo deberá hacerse cargo de las peticiones de servicio de otro que está con un mayor número de peticiones de servicio que él, con el objetivo de que éstas se encuentren equilibradas entre el total de nodos que conforman el clúster. Cuando se genera una creciente demanda de trabajo en este servicio se hace uso del balanceo de carga, creciendo el número de nodos que mantienen el servicio a medida que la carga de trabajo aumenta no siendo requisito el incorporar nodos con los últimos avances tecnológicos.

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

14

menor, puesto que sólo son manejadas las direcciones IP y no datos adicionales como el manejo de sesiones e información de control de la aplicación; por ello en el manejo a nivel de dirección IP, un cuello de botella es menos factible.

Así pues, para lograr que un sistema tenga características de alta disponibilidad se hace uso de componentes de hardware redundante y un software capaz de unir tales componentes. Estos sistemas poseen dos posibles configuraciones que se listan en la tabla 2.4. Un clúster de alta disponibilidad puede componerse de uno o varios nodos para sustentar el acceso al servicio ofrecido, sin embargo se debe prestar atención cuando sólo se cuenta con un nodo pues este representa un punto único de fallo lo que se traduce en un nodo que al fallar, el acceso se ve interrumpido.

Una estructura de alta disponibilidad de este tipo está conformada como se muestra en la tabla 2.5.

2.1.1.5. Clúster Activo/Pasivo

2.1.1.6. Clúster Activo/Activo

Configuración

Descripción Las aplicaciones se ejecutan sobre un conjunto de nodos

Activo

–

Pasivo

activos mientras que los nodos restantes actúan como respaldos redundantes. Todos los nodos actúan como servidores activos de una o más

Activo Activo

–

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

15

Elemento

Descripción 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:

Infraestructura de



Monitorización de nodos y procesos.



Control de acceso a recursos compartidos.



Satisfacción de requerimientos del usuario.

alta disponibilidad. Esta puede ser parte del núcleo del sistema operativo o una capa situada sobre éste, las ventajas de dichas integraciones son: En forma de capa, una solución independiente del sistema operativo. En el sistema operativo, una eficiencia y facilidad de uso. Son clientes de la infraestructura y usan las facilidades Servicios de alta

que exporta ese nivel para mantener en todo momento el

disponibilidad.

servicio. Usualmente existe una degradación del sistema cuando un nodo falla pero no una interrupción del servicio.

Tabla 2.5 Estructura de Alta Disponibilidad

2.1.2. Arquitectura de Clustering

16

Figura 2.3 Arquitectura de un Clúster

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

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

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

Se necesita que el clúster sea tolerante a los fallos, en este caso se encubre la presencia de los fallos del sistema empleando redundancia en el hardware, el software e incluso redundancia temporal. La redundancia en el hardware consiste en añadir componentes replicados para encubrir los posibles fallos. La 1

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

17

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

Definiremos un clúster de alta disponibilidad como un sistema capaz de encubrir los fallos que se producen en él para mantener una prestación de servicio continua.

El clúster de alta disponibilidad va a poder diseñarse con distintas configuraciones. Una posible configuración es activo – pasivo en el cuál las aplicaciones se ejecutan sobre el conjunto de nodos activos, mientras que los nodos restantes actúan como backups redundantes para los servicios ofrecidos.

En el otro extremo, tenemos otra posible configuración, activo activo: en este caso, todos los nodos actúan como servidores activos de una o más aplicaciones y potencialmente como backups para las aplicaciones que se ejecutan en otros nodos. Cuando un nodo falla, las aplicaciones que se ejecutaba en él se migran a uno de sus nodos backup. Esta situación podría producir una sobrecarga de los nodos de respaldo, con lo que se ejecutarían las aplicaciones con más retardo. Sin embargo es aceptable una degradación del servicio y también suele ser preferible a una caída total del sistema. Otro caso particular de clúster de alta disponibilidad sería el de un clúster de un solo nodo, tratándose en este caso, simplemente, de evitar los puntos únicos de fallo.

18

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

relacionados

ya

que

el

concepto

de

alta

disponibilidad de servicios implica directamente una solución mediante clustering.

La principal prestación de un sistema de alta disponibilidad es que el fallo de un nodo derive en que las aplicaciones que se ejecutaban en él sean migradas a otro nodo del sistema. Este migrado puede ser automático (failover) o manual (switchover).”2

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

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

Desde un punto de vista general, una solución de alta disponibilidad consiste en dos partes: la infraestructura de alta disponibilidad y los servicios.

La infraestructura consiste en componentes software que cooperan entre sí para permitir que el cluster aparezca como un único sistema. Sus funciones incluyen monitorizar los nodos, los procesos de interrelación entre nodos, controlar el acceso a los recursos 2

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

19

compartidos y asegurar la integridad de los datos y la satisfacción de los requerimientos del usuario. La infraestructura debe proveer de estas funcionalidades cuando el cluster está en estado estable y, lo que es más importante, cuando algunos nodos dejan de estar operativos.

Los servicios de alta disponibilidad son clientes de la infraestructura, y usan las facilidades que exporta ese nivel para mantener en todo momento el servicio a los usuarios. Normalmente hay una degradación del sistema cuando algún nodo cae, pero no una interrupción del servicio.

Los servicios que se mantienen típicamente sobre este tipo de clusters son las bases de datos, los sistemas de ficheros, los servidores de correo y los servidores web. Y en general, serán utilizados para tareas críticas o servicios ofrecidos por una empresa, grupo de investigación o institución académica, que no puedan, por sus características concretas, interrumpir el servicio.

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

La infraestructura puede ser parte del núcleo del sistema operativo o puede ser una capa situada encima. “Integrar la infraestructura en el sistema operativo tiene como ventaja la eficiencia y la facilidad de uso. La principal ventaja de una capa separada es que se independiza la solución de alta disponibilidad del sistema operativo,

20

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

Figura 2.4 Alta disponibilidad

2.1.2.2. Escalabilidad

La escalabilidad es la capacidad de un equipo para hacer frente a volúmenes de trabajo cada vez mayores brindando siempre nivel de rendimiento aceptable. Existen dos tipos de escalabilidad:

Escalabilidad del hardware (denominada también «escalamiento vertical»). Se basa en la utilización de un gran equipo cuya capacidad se aumenta a medida que lo exige la carga de trabajo existente. 3

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

21

Escalabilidad del software (denominada también «escalamiento horizontal»). Se basa, en cambio, en la utilización de un clúster compuesto de varios equipos de mediana potencia que funcionan en tándem de forma muy parecida a como lo hacen las unidades de un RAID (Redundant Array of Inexpensive Disks o Array redundante de discos de bajo coste).

Se utilizan el término RAC (Redundant Array of Computers o Array redundante de equipos) para referirse a los clúster de escalamiento horizontal. Del mismo modo que se añaden discos a un array RAID para aumentar su rendimiento, se pueden añadir nodos a un clúster para aumentar también su rendimiento.

La disponibilidad y la fiabilidad son dos conceptos que, si bien se encuentran íntimamente relacionados, difieren ligeramente. La disponibilidad es la calidad de estar presente, listo para su uso, a mano, accesible; mientras que la fiabilidad es la probabilidad de un funcionamiento correcto.

Pero hasta el más fiable de los equipos acaba fallando, lo que genera que los fabricantes de hardware intenten anticiparse a los fallos aplicando la redundancia en áreas clave como son las unidades de disco, las fuentes de alimentación, las controladoras de red y los ventiladores, pero dicha redundancia no protege a los usuarios de los fallos de las aplicaciones. De poco servirá, por lo tanto, que un servidor sea fiable si el software de base de datos que se ejecuta en dicho servidor falla, ya que el resultado no será otro que la ausencia de disponibilidad. Ésa es la razón de que un solo equipo no pueda ofrecer los niveles de escalabilidad, disponibilidad y fiabilidad necesarios que sí ofrece un clúster.

22

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

2.1.3. Funcionamiento de un clúster

El funcionamiento de los clusters es muy simple: se trata de un conjunto de piezas, por ejemplo, de varios microprocesadores a través de una red de alta velocidad que los vincula de forma tal que funcionan como un único ordenador pero de una potencia mayor al convencional.

Un clúster se implementa básicamente con varias computadoras similares

de

capacidades

no

necesariamente

altas.

Las

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

Un servicio de clúster consta de: 

Balanceador de carga.



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



Servicio a clusterizar.



Recursos del clúster.

2.1.3.1. Balanceador de carga

Los balanceadores de carga permiten optimizar la utilización de los recursos de un clúster mediante la asignación de tareas a los

23

nodos con menor carga de trabajo, o con mayor cantidad de recursos libres. Son necesarios en las configuraciones que sean Activo / Activo y/o balanceo de carga.

La función de los balanceadores, también conocidos como network dispatcher es redireccionar las peticiones a los servidores que las están atendiendo.

Figura 2.5 Balanceador de Carga

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

En caso de aparición de fallo en algún componente, la tolerancia a fallos busca que el sistema siga trabajando, aunque esté funcionando en modo degradado, hasta que acabe la ejecución, lo que podrá incidir en mayor o menor medida en sus prestaciones.

24

La tolerancia a fallos en un sistema se logra mediante la inclusión de técnicas deredundancia. Puede haber redundancia en cualquier nivel: utilización de componentes hardware extra (redundancia en el hardware), repetición de las operaciones y comparación

de

los

resultados

(redundancia

temporal),

codificación de los datos (redundancia en la información) e incluso la realización de varias versiones de un mismo programa y del uso de técnicas de Replicación de Datos (redundancia de datos) o de checkpoint (redundancia de estados).

Los mecanismos para tolerancia a fallos pueden tener un soporte hardware o software, o bien una combinación de ambos. En sistemas en que la incidencia de fallos sea escasa puede ser recomendable emplear mecanismos de bajo coste con soporte software, siempre que el algoritmo pueda proporcionar la garantía de que acabe la ejecución correctamente aunque se degraden sus prestaciones. Es necesario un sistema que detecte cuando existen nodos en el clúster que no están disponibles para ofrecer el servicio. En este caso no se enviarán peticiones para ser atendidas si el clúster es Activo / Activo o no se balanceará el servicio sobre ellos si es Activo / Pasivo.

Para detectar esta situación se utilizan dos técnicas: 1. Heartbeat. 2. Disco de quorum. Estos conceptos serán detallados más adelante.

2.1.3.3. Recursos del clúster Son todos aquellos recursos necesarios para el servicio: IP de servicio.

25

Filesystems. Scripts para arrancar el servicio

Figura 2.6 Recursos del Clúster

2.1.3.4. Servicio a clusterizar

Es el servicio que se quiere clusterizar. Algunos de los servicios que pueden ser clusterizados son los siguientes: • Servidores de Bases de Datos. • Servidores Web. • Servidores de Balanceo de Carga. • Servidores de Correo. • Servidores Firewall. • Servidores de Archivos. • Servidores DNS. • Servidores DHCP.

26

• Servidores Proxy Cache

2.1.4. Balanceo de Carga

Con el crecimiento de Internet en los últimos años el tráfico en la red ha aumentado de forma radical y con él, la carga de trabajo que ha de ser soportada por los servidores de servicios, especialmente por los servidores web.

Para soportar estos requerimientos hay dos soluciones: o bien el servidor se basa en una máquina de altas prestaciones, que a largo plazo probablemente quede obsoleta por el crecimiento de la carga, o bien se encamina la solución a la utilización de la tecnología de clustering para mantener un clúster de servidores de tal manera que cuando la carga de trabajo crezca, se añadirán más servidores al clúster.

Hay varias formas de construir un clúster de balanceo de carga. Una solución basada en mantener varios servidores aunque no se trate de un clúster propiamente es utilizar un balanceo de carga por DNS. En este caso, se asigna un mismo nombre a distintas direcciones IP y se realiza un round robin a nivel de DNS entre ellas.

En una situación ideal la carga se repartirá equitativamente entre los distintos servidores. Sin embargo, los clientes “cachean” los datos del DNS, con lo que la carga no va a repartirse equitativamente y quedaría desbalanceada.

27

Figura 2.7 Balanceo de Carga

Además, aún cuando el balanceo de los accesos de los clientes a los servicios se haga de forma balanceada, estos clientes pueden solicitar cargas muy distintas de trabajo al servidor al que se conectan: mientras un cliente puede querer tan sólo ver una página, otro puede solicitar un buen número de ellas. Por otra parte, si un servidor cae, se van a seguir redirigiendo peticiones a él.

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

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

28

necesidades del problema al que hacemos frente. El Linux Virtual Server utiliza balanceo a nivel IP.

El proyecto Linux Virtual Server (LVS) ofrece parches y aplicaciones de mantenimiento y gestión que permiten construir un cluster de servidores que implementa alta disponibilidad y balanceo de carga sobre el sistema operativo GNU/Linux. El sistema aparece al usuario externo como un único servidor (en realidad, como un único servidor virtual).

Cada uno de los servidores reales que forman el cluster, es controlado por un nodo director que se encarga de realizar el balanceo de carga. Este director corre un sistema operativo GNU/Linux con un kernel parcheado para incluir el código ipvs, que es la herramienta más importante ofrecida por el proyecto LVS. El director puede ser entendido en términos generales como un router con un conjunto concreto de reglas de enrutamiento.

Cuando un cliente solicita un servicio al servidor virtual, el director escoge un servidor real para que lo ofrezca. Desde ese momento el director debe mantener la comunicación entre el cliente y el servidor real. Esta asociación entre cliente y servidor real va a durar sólo lo que dure la conexión tcp establecida; cuando se inicie una nueva conexión el director escogerá de nuevo un servidor real que puede ser distinto del anterior. Así, si el servicio ofrecido es una página web, el cliente podría obtener las imágenes o los textos desde distintos servidores reales ocultos por el servidor virtual.

Con esta arquitectura, además del balanceo de carga, estamos permitiendo que los servidores reales individuales puedan ser

29

extraídos del LVS, actualizados o reparados y devueltos al clúster sin interrumpir la prestación de servicio.

Asimismo, el sistema es fácilmente escalable y la

alta

disponibilidad en LVS se diseña utilizando software mon, heartbeat, fake y coda, que se utilizan para gestionar la alta disponibilidad

y

para

mantener

una

gestión

segura,

la

comunicación (hearbeat) entre máquinas y un sistema de ficheros tolerante a fallos, respectivamente.

2.1.4.1. Balanceadores hardware

Los balanceadores de carga de Hardware son máquinas con el propósito específico de balancear la carga.

Este tipo de balanceadores tiene ventajas en cuanto a potencia, estabilidad y escalabilidad.

Las principales desventajas de este tipo de balanceadores es el precio que se incurra en el equipo y mantenimiento, así como también que se desperdicia recursos ya que son exclusivamente dedicadas al balanceo de carga.

Algunas de estas soluciones hardware de balanceo de carga son: WebMux Load Balancing, de CAI Networks. Big IP Local Traffic Manager, de F5. Quizás sea la principal alternativa. Barracuda Load Balancer, de Barracuda Networks. Cisco Arrowpoint.

30

2.1.4.2. Balanceadores software

Los balanceadores de software son servidores configurados para realizar la tarea del balanceo. Esto implica instalar en un computador, un sistema operativo y una aplicación que se encargue del balanceo de carga.

Las ventajas que tenemos en estos balanceadores es en cuanto al precio y que cuando necesitemos un servidor más potente para el balanceo de carga, este servidor puede ser reciclado y utilizado para otra tarea.

En cuanto a sus desventajas se tiene que estos balanceadores cuentan con una menor potencia y un mayor tiempo de mantenimiento.

2.1.4.3. Linux Virtual Server - LVS

Linux Virtual Server es una solución para poder implementar un servidor virtual altamente escalable y en alta disponibilidad.

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

31

Figura 2.8 Balanceadores de Carga

Se obtiene escalabilidad en el servicio añadiendo nodos, mientras que la disponibilidad se lograra identificando al balanceador que no funciona, y que el nodo añadido tome la función de balanceador, para que el servicio no se vea interrumpido.

Esta solución nos permitirá tener el servicio funcionando casi continuamente ya que no se verá afectado por posibles caídas de las máquinas debido a fallos en el suministro eléctrico o bien cortes en el ISP de una determinada granja.

Cualquiera de estos fallos, u otros que pudieran ocurrir, afectarán a una o varias granjas, pero nunca a todas con lo cual el servicio seguirá funcionando aunque los clientes podrán experimentar cierta demora en el servicio.

Para los clientes existirá un único servidor (el balanceador) que se encargará de distribuir la carga entre los servidores reales.

32

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

2.1.5. Detección de fallos en los nodos del clúster Un clúster debe conocer cuando algún nodo no está disponible para no enviarle peticiones de servicio. Por lo cual, un sistema de detección de fallos en los nodos del Clúster es vital para su funcionamiento. Esto se hace de dos formas: Heartbeat Disco de quórum

2.1.5.1. Heartbeat

Figura 2.9 Heartbeat

33

Es la técnica más habitual. Consiste en comunicarse o bien a través de una interface de red o puerto serie cada cierto tiempo. Si se pierde la comunicación durante un determinado tiempo se supone que el nodo ha caído.

Para implementar esta técnica los nodos tiene líneas dedicadas, bien sea por red o conexiones serie por las que se comunican de forma continua para verificar el correcto funcionamiento de los nodos.

El funcionamiento de Heartbeat se basa en el envío y recepción de señales enviadas por los demonios de Hearbeat que se ejecutan en ambas máquinas, a estas señales se les conocen como “latidos”.

La diferencia entre el servidor maestro y el esclavo, radica en la prioridad que tienen para ofrecer un servicio. Aquí, el esclavo solo ofrecerá el servicio cuando deje de escuchar los latidos del maestro durante periodo de tiempo determinado, pasado el cual se supondrá que el servidor maestro dejó de funcionar.

Una vez que el esclavo vuelva a escuchar los latidos del maestro, este tomará el control nuevamente, a menos que dentro de la configuración

de

Heartbeat

se

haya

colocado

la

directiva

auto_failback en off. Esta directiva puesta en off, quiere decir que si la máquina que era maestro vuelve a funcionar, ya no retomará el control del servicio, sino se convertirá en la nueva esclava.

El maestro y esclavo pueden comunicarse por medio de dos interfaces, el puerto serial (RS-232) o las tarjetas Ethernet.

Puede darse el caso de un error en la interfaz que une a ambas máquinas que imposibilita la llegada de latidos hacia el esclavo. Si

34

sucede esto, el esclavo interpretará erróneamente que el servidor maestro ha caído y tratara de tomar el control de la prestación del servicio, cuando el servicio nunca ha dejado de prestarse.

2.1.5.2. Disco de quorum

Disco de quorum es una técnica complementaria que lo que se hace es que todos los nodos del clúster escriben su estado en un disco y de esa forma se determina quien está disponible para dar el servicio.

Si un nodo tiene problemas de red y no llega a los otros nodos pensará que los otros nodos no están disponibles e intentará hacerse con el servicio.

Si disponemos de dispositivos serie para el heartbeat entonces dispondremos de una forma de comprobar que los otros nodos están funcionando correctamente y el problema es nuestro. De no disponerlo se asumirá de forma incorrecta que los otros nodos han fallado, intentando asumir el control del clúster. Para evitar esto se utiliza el disco de quorum.

Cada nodo escribe de forma continua su estado en el disco y de esta forma se puede verificar que nodos están disponibles para hacerse con el servicio en el clúster.

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

35

Figura 2.10 Disco de Quorum

36

CAPITULO 3

INTRODUCCION En este capítulo se presentarán las soluciones de software libre para mitigar el problema de alta disponibilidad y balanceo de carga, se expondrán sus características así como las herramientas que hacen posible la construcción de dichas soluciones.

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

DIAGNOSTICO

3.1. Herramientas de open source para la construcción del Clúster Podemos encontrar una amplia variedad de aplicaciones para la creación de clústers, la utilización de una u otra de estas dependerá de la complejidad de instalación, uso específico y ventajas de este sobre otras herramientas. De las opciones que se pueden encontrar están: 

openMosix.



Oscar.



Piranha.



Linux Virtual Server.



Ultramonkey.

A continuación la tabla 3.1 muestra las principales características de cada herramienta para la construcción de clústers.

37

Herramienta.

Características. 

Parche al kernel de GNU/Linux.



Algoritmo interno de balance de carga que migra

openMosix

los procesos entre nodos. 

Migración de procesos totalmente transparente.



Auto descubrimiento de nuevos nodos openMosix en la red del clúster.



Permite instalar un clúster tipo Beowulf.



Contiene todo el conjunto de paquetes necesarios

OSCAR

para programar y administrar el clúster. 

Formado por dos componentes principales SIS (System Installation Suite) y ODA (OSCAR Database API).

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.



Constituido por un servidor altamente escalable y de alta disponibilidad.



Linux Virtual Server – LVS

Balance de carga mediante nodo dedicado con sistema operativo GNU/Linux.



Clúster completamente transparente al usuario final.



Mecanismo para que el clúster funcione con una IP pública.



Permite balance de carga y alta disponibilidad.



Incluye monitorización de servidores reales y nodos de balance.



Permite el manejo de protocolos como HTTP, FTP,

38

DNS, entre otros. Ultramonkey



Permite usar iptables o ipchains para marcar los paquetes que pertenezcan al servicio prestado por el clúster.



Usado desde clústers de dos nodos hasta grandes sistemas.

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

Por último, se mostrarán las ventajas y desventajas de cada una de las herramientas anteriormente mencionadas, pues es importante tener

presente

esta

comparativa

para

hacer

una

primera

aproximación a la elección de una sola herramienta para llevar a cabo una implantación eficaz y sencilla que cubra las necesidades solicitadas; esto se refleja en la tabla 3.2.

Herramienta.

Ventaja. 

openMosix



Desventaja.

No se requieren paquetes



Depende del kernel.

adicionales.



No migra todos los

No son necesarias modificaciones en el

procesos siempre. 

código de openMosix. 

Problemas con memoria compartida.

Migración de procesos. 

Falla la detección de algunos componentes





Es una compilación auto

de hardware en

instalable.

versiones anteriores a

Infraestructura de software

la 3.

para instalar y administrar OSCAR 



Soporte para

un clúster.

distribuciones basadas

Posee bibliotecas y

en RPMs solamente

39

compiladores para uso en

para versiones

clústers.

anteriores a la 5. 

Requiere que la LAN no sea usada para instalar software en el clúster.





Piranha 

Soporte por parte de Red





Al momento solo

Hat Inc.

disponible para

Fácil instalación debido al

versiones

formato de distribución.

empresariales de Red

Administración y manejo

Hat.

mediante interfaz web. 





Dependiente del

Monitorización de

sistema operativo Red

servidores reales.

Hat Enterprise.

Fácil comprensión de



Algunos esquemas se

funcionamiento.

ven afectados por la

Amplia gama de

cantidad de servidores

configuraciones.

reales que se pueden utilizar.

Linux Virtual Server



Funciona a nivel TCP/IP.

- LVS



Manejo de varios tipos de



Cuando el número de

protocolos como HTTP,

servidores reales es

DNS, FTP entre otros.

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.







Los nodos directores

Varios formatos para su

tienen que ejecutar

instalación.

estrictamente el

Amplia documentación

sistema operativo

sobre cada componente.

GNU/Linux.

40

Ultramonkey



Instrucciones de

Según el esquema de

instalación para las

configuración puede

distribuciones de

llegar a ser complejo.

GNU/Linux más comunes







Mismas que en LVS

en servidores.

para los componentes

Se apoya en el proyecto

que sean utilizados de

LVS para algunos

dicho proyecto.

componentes. 

No es dependiente de una distribución de GNU/Linux en particular.

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

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

Formato

Distribucione

Balanceo de

Herramient

de

s Soportadas

carga y Alta

a

Distribució

Ventajas

Desventajas

disponibilidad

n No requiere

Dependiente

Balanceo de

paquetes

del kernel y

carga de

adicionales y

posee

Código

procesos sin

hace

problemas con

fuente.

alta

migración de

memoria

disponibilidad.

procesos.

compartida.

openMosix RPM,

Todas.

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

41

OSCAR

RPM,

Red Hat y

Balanceo de

con bibliotecas hardware y no

Código

basadas en

carga de

y

permite usar la

fuente.

esta.

procesos sin

compiladores

red interna

alta

para computo para

disponibilidad.

paralelo.

instalación de software.

Red Hat Piranha

RPM.

Posee

Soporte de

Actualmente

Red Hat,

disponible solo

Enterprise 4 o herramientas

administración en formato

posteriores.

propias para

y manejo

RPM y para

ambos

mediante

versiones

aspectos.

interfaz web.

empresariales. Instalación por

Amplia gama

segmentos;

Incluye

de

con un gran

Linux

RPM, DEB, Todas.

herramientas

configuracione número de

Virtual

Código

de código

s, función a

Server

fuente.

abierto para

nivel TCP/IP y reales el

ambos

manejo de

tráfico crece

aspectos.

distintos

de manera

protocolos.

significativa.

servidores

Los nodos de Múltiples Basadas en

Uso de

configuracione carga deberán

Debian, Red

componentes

s, manejo de

ejecutar el

distintos

sistema

ambos

protocolos,

operativo

compilación

aspectos

función a nivel GNU/Linux;

de código

añadiendo

TCP/IP,

dependiendo

fuente.

algunas

marcas de

del esquema

mejoras y

firewall y

llega a ser

Hat Enterprise de LVS para RPM. DEB, 4 y mediante Ultramonke Código y

fuente.

balance de

42

herramientas.

ampliación de complejo de LVS.

configurar.

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

Una de las herramientas las más usadas es Piranha de la empresa Red Hat., que incorpora balance de carga mediante direcciones IP y también hace la inclusión de código del proyecto LVS, en esta herramienta Red Hat incorporó mejoras; para poder hacer uso eficiente de Piranha es recomendado el uso de Red Hat Enterprise Linux 4 o posterior, su sencillez en instalación y amplio soporte por parte

de

dicha

empresa

brinda

satisfacción

al

hacer

una

implementación con esta. Fuera del pago de la licencia para el sistema operativo el software de Piranha está disponible de manera gratuita para usuarios registrados de esta distribución.

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

La siguiente opción es Ultramonkey, siendo una de las herramientas más completas en cuanto a balanceo de carga y alta disponibilidad; ya en su tercera versión cuenta con formatos de instalación para

43

diversas distribuciones de GNU/Linux como Debian y Red Hat. Esta herramienta solo puede ser usada en estaciones cuyo sistema operativo

sea

GNU/Linux

siendo

este

uno

de

sus

pocos

inconvenientes en lo que respecta a la independencia de plataforma. Hace uso de las tecnologías de LVS, Linux-HA y Ldirectord para lograr ambas metas que son el balance de carga y la alta disponibilidad. De entre los posibles esquemas de configuración se cuenta con soluciones separadas o una que incorpore ambas, así como también un esquema estándar o uno más completo.

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

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

44

Dadas las características vistas con anterioridad en la tabla 3.3 y esto aunado a los fines que persiguen hacen inclinar la balanza por las siguientes opciones mejor adaptadas a este campo que son: 

Piranha.



Linux Virtual Server.



Ultramonkey.

Se procederá ahora a describir cada una de las tres herramientas más comunes, cabe destacar que cada una es revisada de manera breve resaltando mediante figuras el funcionamiento de cada una de ellas así como mencionando los componentes de cada una.

3.2.1. Herramientas de balanceo de carga y alta disponibilidad 3.2.1.1. Piranha Es un conjunto de aplicaciones en un ambiente bien unido para los administradores que desean instalar servicios de clúster en ambientes GNU/Linux. Un clúster piranha se compone de los siguientes elementos: 

El parche IPVS para el kernel.



El demonio LVS para manejar las tablas IPVS a través de ipvsadm.



El demonio nanny para monitorizar servicios y servidores.



El demonio pulse para controlar el estado del resto de demonios del clúster y la entrada en funcionamiento del nodo de balance de carga de respaldo en caso de fallo del primario.



La interfaz gráfica piranha para administrar el clúster.

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

45

de funcionamiento de cada servidor.

En la figura 3.1 se aprecia

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

Figura 3.1 Esquema de funcionamiento de Piranha.

3.2.1.2. Linux Virtual Server Es un software para el balanceo de carga que permite crear un clúster de forma rápida y eficaz sin hacer grandes inversiones en hardware dedicado. Es una solución ideal para aquellas empresas que quieren ahorrar costos permitiendo tener tras una única dirección IP pública muchos servidores reales y servicios de forma transparente a los usuarios.

Es implementado como un conjunto de parches al kernel de GNU/Linux y un programa denominado ipvsadm. La principal meta de LVS es proveer un mecanismo de migración de sockets. Un clúster de este tipo está formado por dos tipos de máquinas, los nodos o servidores reales que corren con los servicios habituales que estos suelen proveer y los nodos directores o de balanceo de

46

los cuales uno de ellos será el principal y el resto estarán preparados para actuar de respaldo del principal para cuando este falle. LVS funciona a nivel TCP/IP, lo que se conoce como un switch de nivel 4 o mejor conocido como capa 4. Lo que en realidad administra LVS son direcciones y puertos de origen y destino, y toma decisiones para balancear la carga con esta información.

LVS soporta tres modos de trabajo distintos, estos modos definen el método

en

que

el

nodo

de

balanceo

retransmitirá

las

comunicaciones provenientes de los usuarios a los servidores reales definidos. LVS permite balancear muchos protocolos distintos. LVS se ha usado con HTTP, HTTPS, FTP, etc. En la figura 1.10 se muestra su funcionamiento.

Figura 3.2 Esquema de funcionamiento de LVS.

47

3.2.1.3. Ultramonkey Es un proyecto que integra diferentes herramientas de software libre para conseguir alta disponibilidad y balanceo de carga en redes LAN redes de área local. Estas herramientas son: LVS, Heartbeat, Ldirectord y MON como lo muestra la figura 3.3.

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

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

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

48

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

3.2.1.3.1.3. Mon (Service Monitoring Daemon) Es un software para la monitorización del sistema. Este permite definir una serie de alarmas y acciones a ejecutar cuando un servicio deja de funcionar y se utiliza ampliamente como componente de monitorización de recursos para Heartbeat.

Figura 3.3 Componentes de Ultramonkey.

Mientras el software Ultramonkey funciona por sí mismo en GNU/Linux, este puede proporcionar servicios de clúster para

49

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

La figura 3.4 muestra un esquema típico de funcionamiento de Ultramonkey en el cual existe balanceo de carga y alta disponibilidad.

Figura 3.4 Esquema de funcionamiento de Ultramonkey.

50

CAPITULO 4

INTRODUCCION En este capítulo se llevará a cabo un análisis de los métodos existentes de balanceo de carga, dado que estos llegan a ser complejos solamente se tratará la teoría más básica de operación; adicionalmente se realizará la toma de decisión de una herramienta para su implementación.

DISEÑO

4.1. Tipos de balanceo de carga Existen dos formas simples para montar un clúster y distribuir la carga entre los equipos mostradas en la tabla 4.1 a continuación.

Método

Ventajas

Desventajas El

DNS Round – Robin.

cache

de

la

información

en

la

Distribución de la carga

jerarquía

entre servidores reales

servidores DNS y la

de

forma

forma

pseudo-

de

simple

de

aleatoria.

tomar decisiones por

Es el más simple de

parte

implementar.

DNS restringen su

del

servidor

utilidad. “Los servidores no pueden

ser

51

seleccionados según el URL solicitado.”4 Este nodo distribuye las

Llega a convertirse

conexiones.

en cuello de botella.

Se

aumenta

Uso de nodo

sensación

de balanceo

del clúster.

de carga.

Única

de

la unidad

Hace uso de un nodo adicional

para

proveer el balanceo

dirección

IP

de carga.

pública a la cual dirigir

Al

existir

las peticiones.

nodo

Es sencillo enmascarar

este se convierte en

fallas de los servidores.

un punto único de

de

solo

un

balanceo

fallo.

Tabla 4.1 Métodos de balanceo de carga.

4.1.1. Modos de balanceo de carga en LVS LVS permite realizar el reenvío de paquetes a los servidores reales de tres formas. En la tabla 4.2 se muestran los tres modos de balanceo.

Modo de

Ventajas

Desventajas

balanceo Aprovecha

Balanceo mediante NAT.

la

El

nodo

posibilidad del kernel

balanceo se llega a

de Linux de funcionar

convertir en cuello

como router con NAT.

de botella.

Los servidores reales

Tiene que reescribir

pueden

todos los paquetes

ejecutar

(Network 4

de

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

52

Address

cualquier

Translation).

sistema

TCP/IP.

operativo que soporte

Número

TCP/IP.

servidores

Uso

de

una

solamente

dirección

IP

pública.

de reales

dependiente de la velocidad

de

conexión del nodo de balanceo. No

Escalado

los

hasta

sistemas operativos

Balanceo

100 servidores o más.

son soportados por

mediante

Se evita que el nodo

este modo.

de

Los

encapsulado IP (IP Tunneling)

de

todos

balanceo

se

convierta en cuello de

reales

botella.

tener

servidores necesitan una

IP

pública. Todos

los

servidores poseer

deben una

IP

Balanceo

El nodo de balanceo

pública en el mismo

mediante

no

segmento de

es

cuello

de

red

enrutamiento

botella.

del

directo (Direct

No se sobrecarga al

balanceo.

Routing)

nodo de balanceo en

No

reescribir

sistemas operativos

TCP/IP.

paquetes

nodo

todos

de

los

permiten configurar una IP o dispositivo para responder a comandos ARP.

Tabla 4.2 Modos de balanceo de carga en LVS.

53

Balanceo mediante NAT “NAT (es un mecanismo utilizado por routers IP para intercambiar paquetes

entre

dos

redes

que

se

asignan

mutuamente

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

Figura 4.1 Balanceo mediante NAT.

5

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

54

Balanceo mediante encapsulamiento IP De acuerdo a la figura 4.2 el proceso es el siguiente: 1.

El usuario realiza una petición de servicio a la IP pública del clúster (la del nodo de balanceo de carga o IP virtual del clúster).

2.

El nodo de balanceo planifica a qué servidor real se va a enviar la petición, reescribe las cabeceras de las tramas TCP/IP y las envía al servidor.

3.

El servidor recibe la petición, la procesa, genera la respuesta y la envía al nodo de balanceo de carga.

4.

El nodo de balanceo reescribe de nuevo las cabeceras de las tramas TCP/IP con la respuesta del servidor, y las envía de vuelta al usuario.

5.

La respuesta llega al usuario, como si la hubiese generado la IP pública del clúster.

En el modo de balanceo por encapsulamiento IP, su función se ilustra a continuación con la figura 4.2:

55

Figura 4.2 Balanceo mediante encapsulado IP.

El nodo de balanceo recibe todas las conexiones de entrada al clúster, y decide a qué servidor enviárselas. Para hacer esto, utiliza el encapsulado IP para enviar cada trama que recibe a la IP del servidor que vaya a encargarse de ella. Cuando el servidor elegido recibe el paquete, lo desencapsula y al tener configurada la IP pública del clúster como propia, acepta la trama original y se encarga de servir la petición que contuviera enviando éste servidor la respuesta al cliente directamente.

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

Figura 4.3 Balanceo mediante enrutamiento directo.

56

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

4.1.2. Resumen de los métodos de balanceo En la tabla 4.3 a continuación se resumen las características principales de los tres métodos de direccionamiento que puede utilizar el balanceador de carga de Linux Virtual Server:

NAT

Servidor

Red de servidores

Cualquiera

Red Privada

Encapsulamiento IP

Necesita Encapsulamiento

LAN/WAN

Enrutamiento Directo

Dispositivo no-ARP

LAN

57

Escalabilidad

Baja (10~20)

Salida hacia

Nodo

Internet

de

balanceo

Alta

Alta

Router

Router

Tabla 4.3 Métodos de direccionamiento.

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

Algoritmo

Funcionamiento Cada petición se envía a un servidor y la siguiente

Round Robin

petición al siguiente servidor de la lista hasta llegar al último tras lo cual se vuelve a enviar al primero, véase la figura 4.4. Igual que el anterior algoritmo pero añadiendo un peso a cada servidor, este peso es un entero que indica la

Round Robin

potencia de cálculo del servidor, de modo que la cola

Ponderado

Round Robin se modificará para que aquellos servidores con mayor capacidad de cálculo reciban peticiones más a menudo que el resto, véase la figura 4.5. Este mecanismo de distribución consulta a los servidores

Servidor con

para revisar en cada momento cuántas conexiones

menos

abiertas posee cada uno con los clientes, y envía cada

conexiones

petición al servidor que menos conexiones tenga en ese

activas. Servidor con

momento, véase la figura 4.6. Igual que el algoritmo anterior pero se le añaden pesos a

58

menos

los servidores para que de alguna forma se mida su

conexiones

capacidad de cálculo para modificar la preferencia al

activas

momento de hacer una elección, véase la figura 4.7.

Ponderado. Este algoritmo dirige todas las peticiones a un mismo Menos

servidor, hasta que se sobrecarga (su número de

conectado

conexiones activas es mayor que su peso) y entonces

basado en

pasa a una estrategia de menos conexiones activas

servicio.

ponderada sobre el resto de servidores del clúster, véase la figura 4.8. En estos algoritmos se dispone de una tabla de

Tablas Hash por

asignaciones fijas, en las que bien por la IP de origen o

origen y destino.

destino, se indica qué servidor deberá atender la petición. El nodo de balanceo compara las direcciones de las tramas TCP/IP que reciba con estas tablas y actúa en consecuencia, véase la figura 4.9.

Conexiones

A todos los algoritmos de planificación anteriores se les

Persistentes.

puede añadir el hecho cuando un cliente se ha conectado con un servidor, siempre se le dirija al mismo servidor.

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

59

Figura 4.4 Round Robin.

Figura 4.5 Round Robin Ponderado.

60

Figura 4.6 Servidor con menos conexiones activas.

Figura 4.7 Servidor con menos conexiones activas ponderado.

61

Figura 4.8 Menos conectado basado en servicio.

Figura 4.9 Tablas Hash por origen y destino.

62

La elección de una u otra técnica depende principalmente del servicio que se quiera proveer, los conocimientos que se posean de los sistemas, el sistema operativo de los servidores, los recursos económicos que se estén dispuestos a gastar, y consideraciones de rendimiento que afectan al sistema en conjunto.

4.2. Elección de una herramienta para balanceo de carga y alta disponibilidad Para poder tomar una decisión acerca de cuál herramienta es la mejor opción se debe tomar en cuenta factores como: estabilidad, fiabilidad, costos de implementación (tanto en hardware como en conocimientos), escalabilidad entre otros. Como parámetros para poder evaluar dichas herramientas se usará la cantidad de requisitos por cada herramienta, facilidad de comprensión e implementación así como también su disponibilidad para su adquisición. Las herramientas evaluadas son Piranha, Linux Virtual Server y Ultramonkey. Como punto de partida se compararán los requisitos mínimos para la implementación de cada una en cuanto a los equipos que actúan como coordinadores o directores.

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

63

y en particular de una versión empresarial. La tabla 4.5 muestra los requisitos mínimos de hardware requeridos.

Procesador

Pentium II 300 MHz

Memoria RAM

64 MB

Espacio en Disco Duro

+2 GB recomendado

Interfaz de Red

10 Mbps

Tabla 4.5 Requisitos mínimos de hardware para Piranha.

Linux Virtual Server: Este es muy simple de implementar y debido a sus características los nodos directores o de balanceo pueden poseer o no una interfaz gráfica ya que su administración es vía línea de comandos. Como se ha visto, LVS es un parche al kernel de GNU/Linux y esto es importante de verificar puesto que algunas versiones del kernel pudiesen no contar con dicho parche de manera activa siendo uno de los casos todos aquellos kernels personalizados. Su mayor ventaja es su independencia de la distribución del sistema operativo (siempre y cuando sea GNU/Linux, la distribución puede variar) pues está más ligado con el kernel que con la distribución. Para su implementación bastará con un equipo que cubra los mínimos requisitos en hardware para una distribución basada en un kernel 2.4.27 o superior siendo un ejemplo el de la tabla 4.6.

Procesador

Pentium MMX 166 MHz

Memoria RAM

64 MB

Espacio en Disco Duro

+1 GB (sin interfaz gráfica)

Interfaz de Red

10 Mbps

64

Tabla 4.6 Requisitos mínimos de hardware para LVS.

Ultramonkey: Ultramonkey está pensado como una solución muy económica tanto a nivel de software como en hardware y por tal motivo su crecimiento se ha dado en gran medida por las contribuciones de los usuarios de este proyecto dado que es un requisitos dentro de la comunidad de software libre el compartir sus conocimientos y estos aportes vienen desde programadores aficionados hasta los gurúes de la informática. En la tabla 4.7 siguiente se aprecian los mínimos de hardware para ultramonkey.

Procesador

Pentium MMX 166 MHz

Memoria RAM

64 MB

Espacio en Disco Duro

+512 MB (recomendados +1GB)

Interfaz de Red

10 Mbps

Tabla 4.7 Requisitos mínimos de hardware para Ultramonkey.

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

Herramienta.

Procesador.

Memori

Espacio

Interfaz

a RAM.

en

de Red.

Disco Duro. Piranha.

Pentium II 300MHz

64 MB

+2GB

10 Mbps

65

LVS.

Pentium MMX

64 MB

+1GB

166MHz Ultramonkey.

Pentium MMX

10 Mbps

64 MB

+512MB

166MHz

10 Mbps

Tabla 4.8 Comparación de requisitos.

El siguiente punto a evaluar es la complejidad de instalación, tómese en cuenta que todos los parámetros que se están evaluando son sobre los nodos principales, sin tomar en cuenta los servidores reales.

Ultramonkey: Esta es la herramienta más simple de instalación de las 3, no es necesario revisar dependencias o instalar paquetes adicionales manualmente,

es

un

proceso

totalmente

automatizado

y

sumamente útil, pero si el sistema que actúa como nodo director posee un sistema diferente tendrá que llevarse a cabo la instalación de dos formas distintas dependiendo de: Basado en Red Hat: mediante paquetes RPM con la instrucción “rpm -iv *.rpm” estando dentro del directorio que contenga todos los paquetes de Ultramonkey. Basados en código fuente: tendrán que descargarse todos los paquetes que conformen Ultramonkey, luego se procede a descomprimir cada uno y posteriormente se procede a su compilación e instalación.

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

66

no poseer tal licencia se deben adquirir los paquetes por separado y proceder con una instalación manual en la cual dependerá el tipo de paquete adquirido, si es en formato RPM o en forma de código fuente. La instalación del conjunto de aplicaciones que conforman Piranha resulta especialmente compleja si no se posee la licencia del sistema operativo Red Hat Enterprise en donde se vaya a realizar la instalación.

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

Se concluye que Ultramonkey es la herramienta que posee los mecanismos de instalación más simplificados, ahorrando tiempo y esfuerzo dada la automatización de los procesos y la facilidad de acceso a los paquetes que conforman la herramienta. Por último se verá que tan complejo es obtener las aplicaciones que conforman la herramienta y los diferentes métodos que posee cada una para su distribución.

67

Ultramonkey: Este proyecto es de fácil adquisición puesto que se encuentra empaquetado en diversos formatos, basta con agregar un repositorio al archivo y actualizar dichos repositorios para tener acceso a los paquetes que conforman Ultramonkey, el sistema de gestión de paquetes hará notar que debe instalar otros paquetes que son dependencias y ubicará los archivos en los sitios correspondientes; esta es la manera más fácil de instalar Ultramonkey, es limpia, rápida y muy eficiente. Si se desea instalar sobre una distribución como Red Hat se cuenta con los paquetes necesarios en formato RPM y se deben de descargar todos los paquetes y llevar a cabo la instalación de forma manual, en caso de usar una distribución distinta a estas dos, se procederá a descargar los paquetes en formato GZIP o BZIP2 dependiendo de las necesidades. Se concluye de lo anterior que la herramienta Ultramonkey posee una amplia variedad de medios de distribución y adquisición para varios sistemas operativos GNU/Linux eliminando la restricción de dependencia de una distribución en especial. Aunque LVS se distribuye como código fuente y Piranha en paquetes RPM o código fuente, la herramienta Ultramonkey brinda una mejor variedad de formatos y medios de adquisición siendo este punto el que le brinda ventaja sobre las anteriores y siendo esta la mejor elección.

Como se puede apreciar por estos tres indicadores, la mejor opción para elección es Ultramonkey debido a su sistema de instalación, variedad de formatos de distribución así como sus requisitos mínimos de hardware muy bajos. Sin duda las otras opciones son muy viables, pero presentan limitantes; con esto presente

queda

establecido

que

la

mejor

opción

para

68

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

69

CAPITULO 5

INTRODUCCION Este capítulo tiene como finalidad describir la manera de cómo se lleva a cabo el proceso de construcción del clúster, así como también de hacer notar cuales aspectos se deberán tomar en cuenta para su configuración.

IMPLEMENTACION EN MAQUINAS VIRTUALES

5.1 INSTALACION Y CONFIGURACION DEL CLUSTER El clúster funcionará de la siguiente manera (figura 5.1), el usuario realizará una petición de una página web al servicio (el usuario desconoce que se trata de un clúster), al llegar la petición al nodo de balance este redireccionará dicha petición a uno de los servidores reales mediante al algoritmo de balanceo de carga establecido. El servidor real que atiende dicha petición tiene como origen de la misma al nodo de balanceo y no al usuario debido al método de direccionamiento empleado y su respuesta va dirigida a éste nodo. Una vez el nodo de balanceo recibe la respuesta del servidor real solicitado, la envía al usuario que la solicitó teniendo como su dirección la IP virtual del clúster y no la IP real del nodo de balanceo, esto es así porque al hacer el cliente la petición, se hace a la IP virtual del clúster y es de esta misma dirección de donde se obtiene la respuesta haciendo creer al usuario que es atendido por un solo equipo y no por un clúster. Tabla 5.1. En caso de existir una falla en uno de los servidores reales el balanceador verifica cuál se encuentra brindando el servicio y lo direccion hacia dicho servidor. Para el usuario esto es transparente ya que no afecta el servicio simplemente se ve afectado el rendimiento pero nunca en una pérdida de servicio, ésta se da cuando todos los nodos servidores fallan.

70

Figura 5.1 Funcionamiento del Clúster.

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

71

5.1.1 SELECCIÓN DE NODOS PARA EL CLÚSTER Para la selección de los nodos que conforman el clúster es importante hacer notar que aquellos destinados a tomar la función de nodos de balanceo no necesariamente serán los de mayores prestaciones (con mayores recursos), con esto en mente se procederá a listar los componentes primordiales para dicha elección. Primero los nodos que actuarán como nodos de balanceo tendrán, como mínimo, que cubrir lo siguiente mostrado en la tabla 5.2: Procesador Pentium MMX a 166Mhz. Memoria RAM de 64MB. Unidad de Disco duro de 2GB. Tarjeta de Red Ethernet. Unidad de CDROM 8X (solo para instalación).

Tabla 5.2 Especificaciones del nodo de balanceo.

En lo concerniente a los nodos que funcionan como servidores web, estos deberán contar con una mayor capacidad que los nodos de balanceo pues son estos los que realizan el verdadero trabajo de atención a usuarios. Los requisitos mínimos aquí pueden variar dependiendo de la complejidad de los servicios web; un punto medio es la siguiente lista de requisitos mostrada en la tabla 5.3:

Procesador Pentium II 233Mhz. Memoria RAM de 128MB. Unidad de Disco duro de 4GB. Tarjeta de Red Fast Ethernet. Unidad de CDROM 8X (solo para instalación).

72

Tabla 5.3 Especificaciones de nodo servidor.

A continuación la tabla 5.4 indica las herramientas utilizadas para los nodos de balanceo, nodos servidores y los nodos clientes.

Tipo de Nodo

Herramientas Utilizadas Sistema Operativo (Windows, etc.) Navegador Web.

Cliente

Sistema Operativo GNU/Linux CentOs 5.3. Aplicaciones IPROUTE, IPTABLES, TCPDUMP [Tcpdump]. Balanceo de

Editor de textos VIM.

Carga Sistema Operativo GNU/Linux CentOs 5.3. Aplicaciones IPROUTE, IP RULE e IPTABLES. Editor de textos VIM. Servidor Real

Servidor de páginas web Apache2.

Tabla 5.4 Herramientas utilizadas en cada nodo.

Herramienta.

Características.

Características Principales.

Balanceo de carga. Escalabilidad. Bajo consumo de recursos.

Suite

Diversos esquemas de

Balanceo de carga.

configuración.

Alta disponibilidad.

73

Ultramonkey

Manejo de diversos protocolos

Escalabilidad.

como HTTP, FTP, etc. Crear y editar archivos de texto. Manejo de pestañas para múltiples documentos.

Editor de textos VIM.

Uso de números de línea.

Crear y editar archivos

Búsqueda de patrones dentro del

de texto.

documento.

Uso de números de

Ejecución de comandos sin salir

línea.

del editor.

Búsqueda de patrones dentro del documento.

Soporte de lenguajes de programación mediante módulos. Soporte para HTTPS. Servidor de

Soporte para SSL (Secure Socket

Páginas web

Layer) mediante módulo.

Apache2.

Permite crear host virtuales. Amplia gama de configuraciones.

Soporte de módulos para lenguajes y otras aplicaciones. Soporte de SSL. Creación de host virtuales.

Calidad de servicio. Mantenimiento de varias tablas de ruteo. Aplicación

Balanceo de carga.

IPROUTE.

Definición de túneles.

Balanceo de carga. Mantenimiento de varias tablas de ruteo.

Permite interceptar y manejar paquetes de red. Permite el manejo de paquetes en

Aplicación

diferentes estados del

Intercepción y manejo

procesamiento.

de paquetes de red.

Permite construir firewalls basados

Construcción de

en GNU/Linux.

firewalls basados en

74

IPTABLES.

Realiza traducción de direcciones

GNU/Linux.

(NAT).

Traducción de direcciones (NAT).

Permite depurar aplicaciones que utilizan la red para comunicar. Permite depurar la red misma. Aplicación

Permite capturar y leer datos

Permite capturar y leer

TCPDUMP.

enviados por otros usuarios o

datos enviados por otros

computadoras.

usuarios o computadoras.

Tabla 5.5 Características de herramientas utilizadas.

5.1.2 Instalación de los nodos Antes de iniciar, es necesario revisar la tabla 5.4 donde se indican las herramientas necesarias a instalar en cada nodo, la instalación se llevará a cabo en dos partes, la primera comprende la instalación del sistema operativo tanto en nodos de balanceo como en nodos servidores y la segunda parte comprende la instalación del software para el balanceo de carga. En cuanto a la primer parte que comprende la instalación del sistema operativo, se debe tomar en cuenta que se realiza con un entorno gráfico, por tanto se procederá conforme a la tabla 5.6.

Proceso de instalación del Sistema Operativo. 

Creación de máquina virtual en VMware



Selección de medio de instalación.



Proceso de instalación del sistema base.



Instalación de paquetes adicionales.

Tabla 5.6 Proceso de instalación del Sistema Operativo.

75

El primer punto a cubrir nos brinda una variedad de medios de instalación como pueden ser los listados en la tabla 5.7.

Medios de Instalación. 

DVDROM básico para instalación mediante red.



DVD del juego de la distribución.



Juego completo de discos de la distribución.



Archivo ISO guardado en el disco de la máquina virtual

Tabla 5.7 Medios de instalación.

Es importante contar con una conexión a Internet para hacer las actualizaciones pertinentes y facilitar la instalación de la herramienta de balanceo de carga. El segundo punto, la instalación del sistema base cuyo proceso se cubre en la tabla 5.8 a continuación:

Aspecto.

Descripción. Debe especificarse a qué zona horaria pertenece el

Zona Horaria.

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

Contraseña de

Simplemente se pedirán las contraseñas para la

administrador y

cuenta de administrador y la(s) cuenta(s) de los

usuario(s).

usuarios comunes que utilizarán el sistema. Muestra las opciones de configuración automática mediante el protocolo DHCP; de forma manual en la

76

cual se proporcionan datos como la dirección IP y la Configuración de la red.

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

Aquí se marcarán aquellos servicios que sean Selección de aplicaciones.

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

Tabla 5.8 Proceso de instalación del sistema base.

El resto del proceso de instalación y detalles relacionados se cubren en el anexo 1 (Instalación del sistema operativo en maquinas virtuales). La tabla 5.9 a continuación muestra los servicios que se deberán activar en los nodos servidores. 

Servidor de páginas web Apache.



Editor de textos VIM.



Aplicaciones IPROUTE e IPTABLES.

Tabla 5.9 Servicios activados en los nodos servidores.

5.1.3. Configuración de los servidores web Los servidores reales deben ser configurados para ejecutar el servicio web provisto por el clúster usando como aplicación para tal efecto un software como Apache. Cuando se trabaja con servidores web es altamente recomendable hacer uso de direcciones IP estáticas y para ello se debe editar la configuración del dispositivo de red; para mayor detalle debe consultarse el Anexo 2, sobre el manejo de la interfaz de red. Se deben configurar los servidores reales para que acepten peticiones en la dirección IP virtual dado que estos no responden al cliente de

77

manera directa (ver figura 5.1). Para ello el servidor real deberá contar con la aplicación iproute (ésta aplicación se compone de un conjunto de herramientas muy potentes para administrar interfaces de red y conexiones en sistemas GNU/Linux). Las características que brinda esta configuración de balanceo de carga (ver figura 5.2) en primera instancia son brindar un equilibrio de la carga de trabajo en cuanto a las conexiones que puede atender cada servidor real haciendo posible, dependiendo del algoritmo de balanceo, el asignar más trabajo a un servidor con mayor capacidad que otro, repartir el total de conexiones si todos los servidores son iguales en características para no saturar ninguno y poder atender de manera eficiente al usuario final. Después permite que al incorporarse nuevos nodos servidores con mayores prestaciones estos sean quienes atiendan las peticiones con mayores prioridades y consumo de recursos dejando al resto libre para atender a otros usuarios finales. Las aplicaciones IPROUTE e IPTABLES son necesarios de configurar, pues las configuraciones que posee por defecto al instalarse no son suficientes. En lo que respecta a la alta disponibilidad cabe señalar que esta se brinda mediante la redundancia de nodos de balanceo pues es aquí donde reside el balanceo de la carga ya que tales nodos son los encargados de distribuir las conexiones. Esta alta disponibilidad requiere que no solo exista la redundancia en los nodos de balanceo sino también cierto grado en los servidores reales pues aunque con solo un servidor real se puede todavía brindar el servicio, en realidad no existe ningún balanceo de esta manera, siendo primordial la existencia de por lo menos dos nodos para tal efecto. Como las conexiones son redirigidas a los servidores reales usando NAT es importante que la ruta de regreso para tales conexiones sea a través del nodo de balanceo. Esto es así porque NAT puede revertir el proceso, de otra forma el paquete de retorno que es recibido por el usuario final será del servidor real y no del nodo de balanceo y por lo tanto la conexión será abandonada.

78

Figura 5.2. Configuración final de nodos.

5.2. Instalación de CentOs Para la instalación del sistema operativo utilizado (CentOs 5.3), es necesario tener el dvd con la distribución respectiva, para el caso de este proyecto se utilizó el archivo ISO de la distribución el mismo que se lo tiene guardado en un directorio del equipo principal. Cabe señalar que se utilizó en software de virtualización VMware Workstation en la versión 6.0.0. Este proceso se lo realizó para todos los servidores utilizados en el proyecto. El proceso de instalación del sistema operativo CentOs se encuentra detallado en el Anexo 1 Instalación de CentOs.

5.3. Instalación de Ultramonkey En cuanto a los medios de instalación de Ultramonkey, los podemos encontrar en forma de paquetes de código fuente, paquetes pre-

79

compilados que se pueden descargar desde la página web del proyecto y también en el repositorio siguiente:

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

La manera más sencilla de llevar a cabo la instalación ejecutar como superusuario el comando yum install para instalar la lista de paquetes disponibles. Este método es el que se utilizará para su instalación. Si no se cuenta con una conexión a Internet en el momento de instalar los paquetes que se proveen, se puede optar por descargar en otro equipo con acceso a Internet los paquetes que conforma la herramienta desde la página del proyecto, en este caso se entraría a la sección de descargas y se especifica que los paquetes a descargar son para la distribución GNU/Linux Redhat (cabe señalar que CentOs es la versión liberada de Redhat Enterprise, por esta razón su usan los paquetes disponibles para Redhat). Por último se puede optar por adquirir los paquetes en formato de código fuente comprimidos, una vez descargados se procederá a copiarlos en la estación donde se necesiten y se llevará a cabo todo el proceso de compilación e instalación. Como se puede apreciar, existen métodos de instalación para casi todas las distribuciones o preferencias; la mejor forma es mediante los repositorios, pero si se desea conservar un respaldo de dichos paquetes se sugiere su descarga y posterior respaldo en medios como discos compactos o en un servidor de respaldos.

5.3.1. Selección de topología de instalación de ultamonkey Aquí se determina como instalar la solución de alta disponibilidad y balanceo de carga que provee Ultramonkey de acuerdo a un esquema determinado, posteriormente se detallará el proceso de instalación. Como muestra la figura 5.2. “Configuración final de nodos”, la red está compuesta por 3 computadoras unidas mediante un router. Las direcciones IP 192.168.1.20 y 192.168.22.2 están asignadas al nodo director del clúster y las direcciones IP 192.168.22.4 y 192.168.22.5 a los

80

servidores reales. La VIP (dirección IP 192.168.1.20.

virtual) del clúster es

Esta topología permite el máximo rendimiento (en cuanto a tasa de transferencia) a través de la red, ya que el tráfico de retorno ya no tiene que viajar a través de un nodo de balanceo.

5.3.1.1. Directores Linux o Nodos de balanceo En cualquier momento uno de los nodos directores está activo, mientras el otro está en una espera atenta. El nodo de balanceo activo acepta el tráfico desde una IP virtual. Ésta es la IP que es anunciada a los usuarios finales. La carga de conexiones es balanceada hacia uno de los servidores reales usando LVS. Los dos nodos de balanceo se monitorean el uno al otro usando Heartbeat y en el evento de que el nodo de balanceo activo falle, el que está en espera asume la dirección virtual y el servicio se mantiene. Las conexiones son sincronizadas entre el nodo de balanceo activo y los que están en espera, de tal forma que cuando una falla ocurre las conexiones existentes pueden continuar. Cuando un nodo de balanceo recibe una conexión desde un usuario final, éste toma la decisión acerca de a cuál nodo servidor enviar la conexión. Todos los paquetes del tiempo de vida de esta conexión son enviados al mismo servidor real de tal forma que la integridad de la conexión entre el usuario final y el servidor real se mantiene. El director monitorea la salud o estado de los servidores reales, por medio de consultas periódicas de una página conocida y verificando que la respuesta contenga una cadena esperada. Si el servidor real falla, entonces el servidor es sacado del pool (los servidores reales seleccionables) de los servidores reales y se reinserta una vez que vuelve a estar en línea. Como el nodo de balanceo no es el router de entrada para los servidores reales, el tráfico no tiene que viajar a través del nodo de balanceo en el retorno si es que se usa “ruteo directo” o “tunneling”. Esto permite un mayor rendimiento (tasa de transferencia) ya que el nodo de balanceo no tiene que manejar los paquetes de retorno. Puede ser posible enviar tráfico de retorno a través de diferentes routers y/o switch cuando la conectividad externa lo permita.

81

5.3.1.2. Nodos servidores o servidores reales Los servidores reales pueden ejecutar una variedad de servicios incluyendo el servidor web HTTP Apache. Más servidores reales pueden ser añadidos a la red si se requiere capacidad extra dado que este esquema permite escalabilidad.

5.4. Configuración de Heartbeat en los nodos de balanceo Ultramonkey viene con paquetes adicionales. Estos paquetes sólo son requeridos para los nodos de balanceo que van a ejecutar Heartbeat. Pueden ser obtenidos usando el comando yum: yum install ultramonkey Otra alternativa para obtener los paquetes es desde el directorio de descargas en la página: http://www.ultramonkey.org/download/3/ El proceso de instalación de toda la solución se encuentra documentado en el Anexo 2 Instalación de la solución.

5.5. Configuración de la red de trabajo Como muestra la figura 5.1, la red está compuesta por 4 computadoras unidas mediante un switch. Las direcciones IP 192.168.1.20 y 192.168.22.2 están asignadas a al nodo director del clúster (nodo de balanceo) y las direcciones IP 192.168.22.4 y 192.168.22.5 a los nodos servidores A y B). La VIP del clúster LVS es 192.168.1.20. Para editar la configuración de un dispositivo de red usamos las herramientas administrativas para esto: system-config-network. Después de los cambios en el archivo es necesario reiniciar los servicios de red para que estos surtan efecto mediante el comando service network restart.

82

5.6. Configuración del clúster 5.6.1. Directores Linux, nodos de balanceo Los directores deben estar habilitados para enrutar el tráfico hacia los servidores reales. Específicamente, se debe habilitar el seguimiento IPv4. Esto se hace mediante el comando: echo 1 > /proc/sys/net/ipv4/ip_forward Para que los cambios tengan efecto se debe usar el comando sysctl: sysctl –p Configuramos el componente IPVS de ultramonkey para designar la dirección IP virtual y los servidores reales, además indicamos que se lo realizará mediante NAT y con el algoritmo round robin. ipvsadm -A -t 192.168.1.20:80 -s rr ipvsadm -a -t 192.168.1.20:80 -r 192.168.22.4:80 -m -w1 ipvsadm -a -t 192.168.1.20:80 -r 192.168.22.5:80 -m -w1

5.6.2. Heartbeat Para configurar el Heartbeat, deben estar instalados los archivos /etc/ha.d/ha.cf, /etc/ha.d/haresources y /etc/ha.d/authkeys. Para visualizar el archivo /etc/ha.d/ha.cf se debe ejecutar el siguiente comando: vim /etc/ha.d/ha.cf El monitoreo de los servidores reales y su inserción y eliminación del conjunto de servidores disponibles es controlado por ldirectord, el cual es ejecutado por Heartbeat. Para configurar ldirectord, el archivo /etc/ha.d/ldirectord.cf debe estar instalado.

83

vim /etc/ha.d/ldirectord.cf Al recibir una petición de conexión desde un cliente, el nodo de balanceo asigna un servidor real al cliente basado en un algoritmo. El tipo del algoritmo se define en este archivo. Algunos de los algoritmos disponibles son: RR, WRR: round robin, weighted round robin (con manejo de pesos). LC, WLC: least connection (menos conexiones), weighted least connection (el director tiene una tabla con el número de conexiones para cada servidor real). Los algoritmos RR, WRR, LC y WLC deberían todos funcionar de forma similar cuando el nodo de balanceo está dirigiendo servidores reales idénticos con servicios idénticos. El algoritmo LC será mejor manejando situaciones donde las máquinas son dadas de baja y activadas nuevamente. Si los servidores reales están ofreciendo diferentes servicios y algunos tienen usuarios conectados por un largo tiempo mientras otros están conectados por un corto periodo, entonces ninguno de los algoritmos va a hacer un buen trabajo distribuyendo la carga entre los servidores reales. Como el clúster a implementar posee servidores reales idénticos con servicios idénticos, se optó por implementarlo con un algoritmo RR (round robin).

5.7. Instalar y configurar IPROUTE en los nodos servidores Finalmente debemos configurar los nodos servidores 1 y 2 para que acepten peticiones de la IP 192.168.22.2. En los nodos 1 y 2 ejecutamos: ip route add default via 192.168.22.2 table 1 ip rule add fwmark 80 table 1 Es necesario utilizar firewall iptables para marcar todo el tráfico http, y luego la ruta es a través de una tabla de rutas alternativas. iptables -t mangle -I PREROUTING -p tcp --dport 80 -j MARK --set-mark 80 Aceptar conexiones web en los servidores por el puerto 80 y la interface de red eth1.

84

iptables -A INPUT –i eth1 -p tcp --dport 80 -j ACCEPT Guardamos la configuración de las reglas iptables. service iptables save Configuramos que el servicio de iptables en los nodos servidores este corriendo y se active en el inicio: chkconfig iptables on Iniciamos el servicio iptables service iptables start Configuramos para que el servicio http en los nodos servidores este corriendo y se active en el inicio, con el comando: chkconfig httpd on Iniciamos el servicio http service httpd start Asegurarse que los servidores reales (192.168.22.4 y 192.168.22.5) reenvíen los paquetes a través del linux director (192.168.22.2), es decir, los servidores reales deben tener como default gw a linux director. Encontrar toda la documentación acerca de la instalación en el Anexo 2.

5.8. Pruebas de desempeño Los servidores reales poseen una página web alojada en /var/www/html/ la misma que simplemente es informativa y nos indica que servidor es el que está mostrando la página así (servidor 1, servidor 2). Ver figuras 5.3 y 5.4 respectivamente.

85

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

Figura 5.3. Página del servidor 1

86

Figura 5.4. Página del servidor 2

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

Figura 5.5. Detención del servicio httpd

Observamos que ahora el balanceador muestra solamente la página del servidor 2 en todas las peticiones.

5.8.1. Herramientas para medición de rendimiento 5.8.1.1. Selección de una herramienta para medición de rendimiento Existen varias herramientas para comprobar el correcto funcionamiento del clúster entre todas estas se ha decidido utilizar ipvmsad, tcpdump, tomando en cuenta que ipvsadm en el administrador de LVS componente de ultramonkey usado en la implementación.

87

Ipvsadm Ipvsadm se utiliza para establecer, mantener o inspeccionar la tabla del servidor virtual en el kernel de Linux. El Servidor Virtual Linux puede ser utilizado para construir los servicios de red escalable basada en un conjunto de dos o más nodos. El nodo activo del clúster redirecciona las peticiones de servicio a un nodo del clúster, un servidor que va a entregar los servicios. Entre sus características soportadas incluyen dos protocolos (TCP y UDP), tres métodos de reenvío de paquetes (NAT, túneles, y el encaminamiento directo), y ocho algoritmos de balanceo. El comando tiene dos formatos básicos para la ejecución: ipvsadm COMMAND [protocol] service-address [scheduling-method] [persistence options] ipvsadm command [protocol] service-address server-address [packet-forwarding-method] [weight options]

El primer formato manipula un servicio virtual y el algoritmo para la asignación de las solicitudes de servicio a los servidores reales. De manera opcional, un tiempo de espera persistentes y la máscara de red para la granularidad de un servicio persistente puede ser especificado. El segundo formato manipula un servidor real que está asociado con un servicio virtual existente. Cuando se especifica un servidor real, el método de reenvío de paquetes y el peso del servidor real, en comparación con otros servidores reales para el servicio virtual, se puede especificar, de lo contrario se usará por defecto. Ejemplos: Ipvsamd -l Lista la tabla del servidor virtual, las conexiones activas e inactivas existentes en el servidor. Ipvsamd –lnc Lista las conexiones entrantes, el estado de la conexión, el origen y el destino de la conexión.

88

Tcpdump Tcpdump es una excelente herramienta que nos permite monitorear a través de la consola de Linux todos los paquetes que atraviesen una interfaz indicada. A su vez, los múltiples filtros, parámetros y opciones que tcpdump nos ofrece, nos permite infinidades de combinaciones, al punto de poder monitorear todo el tráfico completo que pase por la interfaz, como el tráfico que ingrese de una ip, un host o una página específica, podemos solicitar el tráfico de un puerto específico o pedirle a la herramienta que nos muestre todos los paquetes cuyo destino sea una dirección MAC específica. Ejemplos: tcpdump –i eth0 port 80 Muestra todo el tráfico por la interface de red eth0 y el puerto 80. De las pruebas obtenidas con estas herramientas podemos verificar el estado de los servidores asi:

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

89

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

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

90

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

91

CONCLUSIONES Una vez instalado todo el conjunto de paquetes necesario, (paquetes RPM, tipo de paquete utilizado en distribuciones Centos), la configuración resulta sencilla y solo se tienen que ejecutar comandos para especificar el algoritmo a utilizar para el balanceo de carga, datos sobre los servidores reales y nodos de balanceo como también los servicios que proporcionan y las páginas para control esperadas (servicio en este caso particular de páginas web o HTTP solamente). Para las pruebas de funcionamiento se utilizó configuraciones generales del clúster que incluye los nodos de balanceo, los algoritmos para balanceo de carga, instalación y configuración del servidor de páginas web Apache, pruebas simples para nodos de balanceo e instalación y configuración del paquete iproute en los nodos servidores. Sobre las pruebas realizadas, estas me ofrecen un panorama muy general, puesto que la mayoría de ellas son bien controladas y se esperan ciertos resultados, la mejor parte de las pruebas se pudo explorar esos aspectos no previstos e investigar el comportamiento del clúster en dichos casos; en las pruebas llevadas a cabo se contaba con un cliente con un sistema operativo distinto al utilizado para la construcción del clúster (recuérdese que el cliente solamente necesita un navegador web) el cual realiza las peticiones de la página web principal alojada en el clúster, de esta manera se pudo observar cual servidor real es el que atiende la petición (en un sistema en producción esto no deberá ser así ya que la intención es que los usuarios vean al sitio web como un solo equipo). La página web solicitada en las pruebas solamente contiene una cadena indicando a que nodo servidor real pertenece. Es importante aclarar que debido a las características de los nodos de balanceo empleados, estos no pueden procesar miles de peticiones sin embargo las pruebas realizadas demuestran que son suficientemente competentes para el

92

manejo de un sitio de dimensiones bajas a medias como lo son las pequeñas empresas. En el transcurso de las pruebas se observó que existían problemas no previstos en la elaboración del proyecto como la seguridad que debe mantenerse en los servidores lo cual fue solventado denegando la aceptación de paquetes y puertos por parte de los nodos servidores. Al final del proyecto se concluye que la solución desarrollada es aplicable en pequeñas empresas tomando en cuenta el correcto funcionamiento, la fácil instalación y mantenimiento del sistema además que, por tratarse de open source las empresas no incurre en gastos por licenciamiento.

BIBLIOGRAFIA

2007, José Angel de Bustos Pérez, GNU/Linux, software libre para la comunidad universitaria, 2007. Septiembre 2001, Vicente José Aguilar Roselló, Clustering de Alta Disponibilidad bajo GNU/Linux, septiembre 2001 2005, Rosa María Yánez Gómez, Introducción a las tecnologías de clustering en GNU/Linux, 2005. 30 de diciembre de 2003, Emilio José Plaza Nieto, Cluster Heterogéneo de computadoras, 30 de diciembre de 2003. Edición junio 2010, Joel Barrios Dueñas, Implementación de Servidores con GNU/Linux, 26 de junio 2010. 2007, Red Hat, Inc., Linux Clustering Building and Maintaining Linux Clusters, 2007 2004, Federico Esteban Pereda, Mini-Howto Servidores de Alta Disponibilidad (heartbeat + drbd), 2004. Junio 30, 2007, Tom Adestein, Bill Lubanovic, Administración de sistemas Linux, junio 30, 2007, Anaya Multimedia 2005, Charles Bookman, Clustering con Linux, 2005, Pearson Educación 2007, José Angel de Bustos Pérez, GNU/Linux, software libre para la comunidad universitaria, 2007. Septiembre 2001, Vicente José Aguilar Roselló, Clustering de Alta Disponibilidad bajo GNU/Linux, septiembre 2001 http://www.codigolibre.org/index.php?option=com_content&view=article& id=5389:clustering&catid=36:gnu-cat&Itemid=53 http://www.jumpingbean.co.za/linux-cluster-load-balancing-highavailability http://crysol.org/node/339 http://www.taringa.net/posts/linux/8289874/Monitoreo-de-trafico-en-red_tcpdump.html

http://linuxmanpages.com/man8/ipvsadm.8.php http://bulma.net/body.phtml?nIdNoticia=1615&nIdPage=3 http://www.adslfaqs.com.ar/que-es-nat-network-address-translation/ http://wiki.itlinux.cl/doku.php?id=cluster:ultramonkey-lbs http://mmc.geofisica.unam.mx/LuCAS/Manuales-LuCAS/doc-cursosalamanca-clustering/html/ch03s04.html http://www.wikilearning.com/tutorial/el_manual_para_el_clustering_con_ openmosix-clusters_ha_ii/9756-15 http://www.estrellateyarde.org/discover/cluster-ultramonkey-en-linux http://www.tcpdump.com/ http://linuxmanpages.com/man8/ipvsadm.8.php http://www.ultramonkey.org http://www.centos.org