You are on page 1of 107

UNIVERSIDAD ALFREDO PREZ GUERRERO UNAP

CARRERA: SISTEMAS DE INFORMACION Y NETWORKING

PROYECTO DE GRADO

PARA LA OBTENCIN DEL TTULO DE INGENIERO EN SISTEMAS INFORMATICOS Y NETWORKING

TEMA: DISEO DE UNA SOLUCIN PARA SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON OPEN SOURCE

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

Mayo del 2011

Quito, 13 de mayo del 2011

Seor: Coordinador de Tesis y Proyectos de Grado UNAP Presente.-

De nuestras consideraciones: Por medio de la presente CERTIFICAMOS, que el seor estudiante egresado Flavio Mauricio Gallardo Padilla, identificado con el nmero de cdula 1710049139 estudiante de la carrera de Ingeniera en Sistemas y Networking de la UNAP, una vez realizada la direccin y las evaluaciones correspondientes segn la normativa de la universidad, ha concluido satisfactoriamente con el trabajo de grado Titulado DISEO DE UNA SOLUCIN PARA SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON OPEN SOURCE. Por consiguiente, otorgamos la aptitud para la presentacin del grado oral del mencionado estudiante.

Agradeciendo su atencin

Ing. Nelio Brito Director

Ing. Fredy Molina Evaluador

Ing. Rommel Caicedo Evaluador

Quito, 13 de mayo del 2011

Seores: Universidad Alfredo Prez Guerrero UNAP Presente.-

De mis consideraciones:

Yo, Flavio Mauricio Gallardo Padilla, identificado con el nmero de cdula 1710049139, estudiante egresado de la UNAP de la Carrera de Ingeniera en Sistemas y Networking, por medio de la presente CERTIFICO que el presente Trabajo de Grado titulado: DISEO DE UNA SOLUCIN PARA

SERVIDORES DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA CON OPEN SOURCE; es de mi plena autora y no constituye plagio ni copia alguna constituyndose un documento nico.

Es todo en cuanto puedo decir en honor a la verdad

Agradeciendo su atencin

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

AGRADECIMIENTO

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

DEDICATORIA

A mis hijas, quienes comprendieron que el tiempo que deba entregarles a ellas lo ocupaba en culminar mi carrera, quiero que este logro sea para ellas un ejemplo de perseverancia y sacrificio y que sea tambin un ejemplo para la culminacin de sus carreras profesionales en su momento, entiendan que todo lo que uno se propone en la vida es posible con dedicacin y esfuerzo.

INDICE

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

2.1.4. Balanceo de Carga ................................................................................. 26 2.1.4.1. Balanceadores hardware ..................................................................... 29 2.1.4.2. Balanceadores software....................................................................... 30 2.1.4.3. Linux Virtual Server - LVS .................................................................... 30 2.1.5. Deteccin de fallos en los nodos del clster ........................................... 32 2.1.5.1. Heartbeat ............................................................................................. 32 2.1.5.2. Disco de quorum .................................................................................. 34 CAPITULO 3 ..................................................................................................... 36 INTRODUCCION .............................................................................................. 36 DIAGNOSTICO ................................................................................................. 36 3.1. Herramientas de open source para la construccin del Clster ................. 36 3.2. Comparacin de las herramientas de balanceo de carga y alta disponibilidad .................................................................................................... 40 3.2.1. Herramientas de balanceo de carga y alta disponibilidad ....................... 44 3.2.1.1. Piranha................................................................................................. 44 3.2.1.2. Linux Virtual Server .............................................................................. 45 3.2.1.3. Ultramonkey ......................................................................................... 47 3.2.1.3.1. Componentes Ultramonkey ............................................................... 47 3.2.1.3.1.1. Heartbeat ....................................................................................... 48 3.2.1.3.1.2. Ldirectord ....................................................................................... 48 3.2.1.3.1.3. Mon (Service Monitoring Daemon)................................................. 49 CAPITULO 4 ..................................................................................................... 50 INTRODUCCION .............................................................................................. 50 DISEO ............................................................................................................ 50 4.1. Tipos de balanceo de carga ....................................................................... 50 4.1.1. Modos de balanceo de carga en LVS ..................................................... 51 4.1.2. Resumen de los mtodos de balanceo ................................................... 56 4.1.3. Planificacin del balanceo de carga ........................................................ 57 4.2. Eleccin de una herramienta para balanceo de carga y alta disponibilidad .......................................................................................................................... 62 CAPITULO 5 ..................................................................................................... 69 INTRODUCCION .............................................................................................. 69 IMPLEMENTACION EN MAQUINAS VIRTUALES ........................................... 69

5.1 INSTALACION Y CONFIGURACION DEL CLUSTER ................................ 69 5.1.1 SELECCIN DE NODOS PARA EL CLSTER ...................................... 71 5.1.2 Instalacin de los nodos........................................................................... 74 5.1.3. Configuracin de los servidores web ...................................................... 76 5.2. Instalacin de CentOs ................................................................................ 78 5.3. Instalacin de Ultramonkey ........................................................................ 78 5.3.1. Seleccin de topologa de instalacin de ultamonkey ............................. 79 5.3.1.1. Directores Linux o Nodos de balanceo ................................................ 80 5.3.1.2. Nodos servidores o servidores reales .................................................. 81 5.4. Configuracin de Heartbeat en los nodos de balanceo ............................. 81 5.5. Configuracin de la red de trabajo ............................................................. 81 5.6. Configuracin del clster ........................................................................... 82 5.6.1. Directores Linux, nodos de balanceo ...................................................... 82 5.6.2. Heartbeat ................................................................................................ 82 5.7. Instalar y configurar IPROUTE en los nodos servidores ............................ 83 5.8. Pruebas de desempeo ............................................................................. 84 5.8.1. Herramientas para medicin de rendimiento .......................................... 86 5.8.1.1. Seleccin de una herramienta para medicin de rendimiento ............. 86 CONCLUSIONES ............................................................................................. 91 Anexo 1 Instalacin de Centos ......................................................................... 95 Anexo 2 Instalacin de la Solucin ................................................................. 118

INDICE DE FIGURAS

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

Figura 5.8. Trfico en la red con tcpdump. .................................................... 89 Figura 5.9. Salida de trfico en la red con tcpdump. ..................................... 90

INDICE DE TABLAS

Tabla 2.1 Tipos de Clster ........................................................................... 8 Tabla 2.2 Subtipos de Clster ...................................................................... 9 Tabla 2.3 Componentes de un Clster ....................................................... 10 Tabla 2.4 Configuracin de un Clster ....................................................... 14 Tabla 2.5 Estructura de Alta Disponibilidad ................................................ 15 Tabla 3.1 Caractersticas de Herramientas para Clsters. ......................... 38 Tabla 3.2 Ventajas y Desventajas de las Herramientas para Clster. ........ 40 Tabla 3.3 Comparacin de herramientas para clster. ............................... 42 Tabla 4.1 Mtodos de balanceo de carga. ................................................. 51 Tabla 4.2 Modos de balanceo de carga en LVS......................................... 52 Tabla 4.3 Mtodos de direccionamiento. .................................................... 57 Tabla 4.4 Algoritmos de planificacin de balanceo de carga. .................... 58 Tabla 4.5 Requisitos mnimos de hardware para Piranha. ......................... 63 Tabla 4.6 Requisitos mnimos de hardware para LVS. .............................. 64 Tabla 4.7 Requisitos mnimos de hardware para Ultramonkey. ................. 64 Tabla 4.8 Comparacin de requisitos. ........................................................ 65 Tabla 5.1 Funcionamiento del Clster. ....................................................... 70 Tabla 5.2 Especificaciones del nodo de balanceo. ..................................... 71 Tabla 5.3 Especificaciones de nodo servidor. ............................................ 71 Tabla 5.4 Herramientas utilizadas en cada nodo. ...................................... 72 Tabla 5.5 Caractersticas de herramientas utilizadas. ................................ 74 Tabla 5.6 Proceso de instalacin del Sistema Operativo. .......................... 74 Tabla 5.7 Medios de instalacin. ................................................................ 75 Tabla 5.8 Proceso de instalacin del sistema base. ................................... 76 Tabla 5.9 Servicios activados en los nodos servidores. ............................. 76

INTRODUCCION Para que un servicio sea eficiente es necesario que se mantenga en funcionamiento constante y que no ocurran retardos en la entrega de la informacin. As pues se da paso a la investigacin y desarrollo de nuevas tecnologas que garanticen tales sucesos; en este trabajo se presentarn las soluciones para tales problemas y se expondrn sus caractersticas as como las herramientas que hacen posible la construccin de dichas soluciones de software con open source.

Un servidor juega un papel muy importante dentro de una organizacin, y al mismo tiempo se transforma en un servicio crtico al ser utilizado por la gran mayora de los usuarios para acceder a todos los servicios que este brinda, siendo necesario la implementacin de un sistema de clster que permita mantener el servicio disponible en caso de que falle un servidor as como mantener un sistema de balanceo de carga evitando la saturacin del propio servidor.

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

Al hablar de clster, tenemos un numeroso listado de diversas aplicaciones que implementan distintos tipos de clster, dependiendo de las necesidades que posee la organizacin y la aplicacin a clusterizar.

Dentro de los clster ms comunes, se encuentra el clster de alta disponibilidad, en el cual uno de los nodos acta pasivamente mientras el nodo activo recibe todas las peticiones a los servicios que ofrece. En caso de que el nodo activo tenga alguna falla en los servicios, el nodo pasivo toma el control

ii

de los servicios y pasa a ser el activo para que los servicios ofrecidos estn siempre disponibles.

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

CAPITULO 1 GENERALIDADES

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

Actualmente en el pas existen pocas empresas que han optado por instalar open source en sus servidores debido al poco personal tcnico capacitado, pese a que el gobierno nacional promueve el uso de open source en las entidades pblicas. Este trabajo se enfoca en el uso de software libre para la implementacin de la solucin planteada.

Existen equipos que permiten balanceo de carga y alta disponibilidad mediante hardware, pero la adquisicin de estos significa una inversin para las empresas contrariamente a las soluciones de software open source que no necesitan pagar ningn valor de licenciamiento.

De no contar con una solucin al problema de alta disponibilidad y balanceo de carga por software se perder la opcin de contribuir a una investigacin e implementacin de este tipo.

Mediante la implementacin de la solucin, las empresas aseguran el normal desenvolvimiento de sus operaciones, minimizando sustancialmente el riesgo tecnolgico dando continuidad al negocio y por consiguiente a sus operaciones, se centrar en la tcnica de obtener una alta disponibilidad y balanceo de carga

por medio de la redundancia, instalando servidores completos en lugar de uno slo (se realizar la implementacin en mquinas virtuales), que sean capaces de trabajar en paralelo y de asumir las cadas de algunos de sus compaeros, y podremos aadir y quitar servidores al grupo (clster) segn las necesidades.

1.2. FORMULACION DEL PROBLEMA Encontrar la solucin que permita mantener un alto nivel de disponibilidad y balanceo de carga, con herramientas open source, dando continuidad a los servicios?. Considerando la experiencia adquirida en la implementacin, administracin y mantenimiento de servidores Linux en los ltimos aos de servicio profesional.

1.3. SISTEMATIZACION Qu herramientas open source nos permiten aplicar alta disponibilidad y balanceo de carga? Qu herramientas open souce se utilizarn para la implementacin de la solucin? Qu necesitan las empresas para solucionar su problema de alta disponibilidad y balanceo de carga?

1.4. OBJETIVO GENERAL Disear una solucin de alta disponibilidad y balanceo de carga, para dotar de servicios que permitan dar continuidad al negocio en las operaciones realizadas por las empresas, con software open source.

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

Disear una solucin que permita ofrecer servidores de alta disponibilidad y balanceo de carga mediante software libre.

Implementar en un ambiente de laboratorio la solucin diseada, para asegurar el normal desenvolvimiento de las operaciones en cualquier empresa. Dicho laboratorio se lo implementar en mquinas virtuales.

1.6. JUSTIFICACIN Con el actual ritmo de crecimiento del comercio y el movimiento de datos de todo tipo en Internet, web 2.0, con el establecimiento no formal de un protocolo mundial IP generalizo y la incuestionable importancia de las tecnologas de la informacin en las empresas actuales de cualquier tamao, es cada da ms importante que los servicios puedan funcionar con un alto nivel de SLA (calidad de servicio) , ya sea para dar soporte interno, como para ofrecer servicios a travs de Internet e Intranet (http, correo, ftp, etc). A esta necesidad de un servicio ininterrumpido y fiable se le conoce como alta disponibilidad, de igual forma evitar la sobre carga existente en los servidores debido al gran nmero de usuarios y que estos no sean saturados, compartiendo con otros la responsabilidad de dar los servicios conocemos como balanceo de carga.

Para poder incrementar la base cientfica relacionada con proyectos de software open source y minimizar el riesgo tecnolgico. Se utiliza open source por que es software libre, es decir no se debe incurrir en gastos de licenciamiento para su uso. Desde el punto de vista metodolgico, esta investigacin generar

conocimiento vlido y confiable dentro del rea de las TICS , para futuras implementaciones. Esta investigacin abrir nuevos caminos en empresas que presenten situaciones similares sirviendo a estas como marco referencial.

1.7. ALCANCE El proyecto abarcar la investigacin sobre las herramientas de clster que nos ofrece el software libre, para de esta manera analizar la mejor opcin para ser implementada, esta investigacin permitir adems adquirir conocimiento para futuras implementaciones. Despus de conocer las opciones de cluster con open source, se realizar un diagnostico sobre las herramientas disponibles para proponer una solucin que permita de forma adecuada implementar la tecnologa elegida, tomando en cuenta siempre la mejor alternativa.

Se crear un laboratorio con mquinas virtuales para la implementacin en un ambiente de pruebas, que contendr servicios como http, mail, ftp, proxy, adems se obtendr pruebas de los resultados de funcionamiento de la solucin.

Se contar con un cliente con un sistema operativo distinto al utilizado para la construccin del clster (el cliente solamente necesita un navegador web) el cual realiza las peticiones de la pgina web principal alojada en el clster, de esta manera se puede observar cual servidor real es el que atiende la peticin (en un sistema en produccin esto no deber ser as ya que la intencin es que los usuarios vean al sitio web como un solo equipo). En lo concerniente a las

pruebas de alta disponibilidad, sern realizadas de 3 maneras, la primera es desconectando un nodo de balanceo, la segunda es detener la ejecucin de las aplicaciones encargadas de monitorear el estado de los nodos de balanceo en uno de los nodos para simular un fallo fsico del nodo y tercera es apagando uno de los nodos y revisar si el servicio sigue en funcionamiento. Esto nos dar una visin certera del real funcionamiento de servidores de este tipo en ambientes de produccin.

CAPITULO 2

INTRODUCCION Este captulo contiene conceptos fundamentales que son necesarios conocer para la elaboracin del proyecto como: clustering, tipos de clster, arquitectura de clustering, alta disponibilidad, balanceo de carga. Adicionalmente se relata una breve historia del inicio, desarrollo y evolucin de la tecnologa relacionada con los clster.

FUNDAMENTACION TEORICA

MARCOS DE REFERENCIA (Terico, Conceptual)

2.1. MARCO TEORICO 2.1.1. Clustering 2.1.1.1. Antecedentes En el verano de 1994 Thomas Sterling y Don Becker, trabajando para el CESDIS (Center of Excellence in Space Data and Informarion Sciencies) bajo el patrocinio del Proyecto de las Ciencias de la Tierra y el Espacio (ESS) de la NASA, construyeron un Clster de Computadoras que consista en 16 procesadores DX4 conectados por una red Ethernet a 10Mbps, ellos llamaron a su mquina Beowulf. La mquina fue un xito inmediato y su idea de proporcionar sistemas basados en COTS (equipos de sobremesa) para satisfacer requisitos de cmputo especficos se propag rpidamente a travs de la NASA y en las comunidades acadmicas y de investigacin. El esfuerzo del desarrollo para esta primera mquina creci rpidamente en lo que ahora llamamos el Proyecto Beowulf. Este Beowulf construido en la NASA en 1994 fue el primer clster de la historia, y su finalidad era el clculo masivo de datos. Desde entonces, la tecnologa de clusters se ha desarrollado enormemente.

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

Figura 2.1 Clster de computadores

Esta tecnologa ha evolucionado para beneficio de diversas actividades que requieren el poder de cmputo y aplicaciones de misin crtica.

El uso de los clsters es el resultado de una convergencia de mltiples tecnologas que abarcan la disponibilidad de procesadores econmicos de alto rendimiento y las redes de alta velocidad, como lo son las redes de fibra ptica as como tambin el desarrollo de herramientas de software diseadas para cmputo distribuido de alto desempeo.

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

2.1.1.3. Tipos de clster Dependiendo del tipo de solucin que busquemos podemos clasificar los clusters en varios tipos:

High Performance High Availability Load Balancing

2.1.1.4. High Performance

Tipo de Clster Alto rendimiento (High Performance)

Descripcin Conjunto de computadoras diseado para brindar altas prestaciones en cuanto a capacidad de clculo. Conjunto de dos o ms computadoras que se

Alta disponibilidad (High Availability)

caracterizan por mantener una serie de servicios disponibles y compartidos, se caracterizan por estar constantemente monitorizndose entre s. Compuesto por una o ms computadoras que actan

Balanceo de carga (Load Balancing)

como interfaces primarias del clster y se ocupan de repartir las peticiones de servicio que recibe el clster a los nodos que lo conforman.

Tabla 2.1 Tipos de Clster

Adems de la clasificacin general de los tipos de clster que se pueden encontrar, es preciso destacar que se pueden tener los siguientes subtipos en cada una de las categoras segn se muestra en la tabla 2.2.

Subtipo Homogneo

Descripcin Es donde todos los nodos poseen una configuracin de hardware y software iguales.

Semihomogneo Heterogneo

Es donde se poseen arquitecturas y sistemas operativos similares pero de diferente rendimiento. Es donde se poseen hardware y software distintos para cada nodo.

Tabla 2.2 Subtipos de Clster

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

Figura 2.2 Componentes de un clster

10

Para entender mejor estos componentes, es recomendable el anlisis mediante la tabla 2.3, en ella se puede observar cada componente y una descripcin del mismo comenzando por la interconexin de los equipos.

Componente

Descripcin Estas son las conexiones de los nodos a la red de trabajo

Conexiones de red.

del clster siendo tan complejas como lo sean las tecnologas y medios utilizados en su instalacin.

Protocolos de comunicacin y servicios.

Aqu

normalmente

se

cuenta

con

el

protocolo

de

comunicaciones TCP/IP y servicios de transporte de datos.

Son simples computadoras o sistemas multiprocesador; en Nodos. estos se hospedan el Sistema Operativo, el middleware y lo necesario para la comunicacin a travs de una red. Se define a grandes rasgos como un programa o conjunto Sistema Operativo. de ellos que estn destinados a gestionar de manera eficaz los recursos de una computadora. Como ejemplo se tiene Unix, Mac OSX. Es un software que acta entre el Sistema Operativo y las aplicaciones con la finalidad de proveer a un clster las Middleware. caractersticas de interfaz, herramientas de optimizacin y mantenimiento del sistema, como tambin un crecimiento o escalabilidad. Entre los ms populares se encuentra openMosix. Son todos aquellos programas que se ejecutan sobre el Aplicaciones. middleware; estos son diseados para su ejecucin en entornos de cmputo paralelo o aprovechamiento del tipo de clster.
Tabla 2.3 Componentes de un Clster

11

Los clsters permiten una flexibilidad de configuracin que no se encuentra normalmente en los sistemas multiprocesadores

convencionales. El nmero de nodos, la capacidad de memoria por nodo, el nmero de procesadores por nodo y la topologa de interconexin, son todos parmetros de la estructura del sistema que puede ser especificada en detalle en una base por nodo sin incurrir en costos adicionales debidos a la configuracin personalizada.

Adems, permiten una rpida respuesta a las mejoras en la tecnologa. Cuando los nuevos dispositivos, incluyendo

procesadores, memoria, disco y redes estn disponibles se pueden integrar a los nodos del clster de manera fcil y rpida permitiendo que sean los sistemas paralelos que primero se benefician de tales avances. Lo mismo se cumple para los beneficios de un mejoramiento constante en el rubro de precio-rendimiento en la tecnologa. Los clsters son actualmente la mejor opcin para seguir la pista de los adelantos tecnolgicos y responder rpidamente a las ofertas de nuevos componentes.

Los clsters permiten una flexibilidad de configuracin que no se encuentra normalmente en los sistemas multiprocesadores

convencionales. El nmero de nodos, la capacidad de memoria por nodo, el nmero de procesadores por nodo y la topologa de interconexin, son todos parmetros de la estructura del sistema que puede ser especificada en detalle en una base por nodo sin incurrir en costos adicionales debidos a la configuracin personalizada.

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

12

Clculos matemticos. Rendering (construccin/generacin) de grficos. Compilacin de programas. Compresin de datos. Descifrado de cdigos. Rendimiento del sistema operativo, (incluyendo en l, el rendimiento de los recursos de cada nodo).

En general cualquier problema de propsito general que requiera de gran capacidad de procesamiento.

En el caso de los clster de alta disponibilidad resuelven:

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

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

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

13

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

La redundancia en el hardware consiste en aadir componentes replicados para encubrir los posibles fallos mientras que la redundancia de software incluye la administracin del hardware redundante para asegurar su correcto funcionamiento al hacer frente a la cada de algn elemento. Y por ltimo la redundancia en el tiempo hace referencia a la repeticin de la ejecucin de un conjunto de instrucciones para asegurar el comportamiento correcto en caso de que ocurra un fallo.

Por su parte, el balanceo de carga en el contexto del servicio web es la toma de decisin de cul nodo deber hacerse cargo de las peticiones de servicio de otro que est con un mayor nmero de peticiones de servicio que l, con el objetivo de que stas se encuentren equilibradas entre el total de nodos que conforman el clster. Cuando se genera una creciente demanda de trabajo en este servicio se hace uso del balanceo de carga, creciendo el nmero de nodos que mantienen el servicio a medida que la carga de trabajo aumenta no siendo requisito el incorporar nodos con los ltimos avances tecnolgicos.

En el balanceo de carga en un nodo (o varios segn sea el caso) es una tarea que controlar la distribucin entre los servidores que componen el clster. Cabe aclarar que dicha labor se puede efectuar a nivel de aplicacin; lo que puede llevar a cuellos de botella si el nmero de nodos servidores es grande y en un nivel de direccin IP, en el cual la cantidad de informacin que es manejada es mucho

14

menor, puesto que slo son manejadas las direcciones IP y no datos adicionales como el manejo de sesiones e informacin de control de la aplicacin; por ello en el manejo a nivel de direccin IP, un cuello de botella es menos factible.

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

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

2.1.1.5. Clster Activo/Pasivo

2.1.1.6. Clster Activo/Activo

Configuracin

Descripcin Las aplicaciones se ejecutan sobre un conjunto de nodos

Activo Pasivo

activos mientras que los nodos restantes actan como respaldos redundantes. Todos los nodos actan como servidores activos de una o ms

Activo Activo

aplicaciones y potencialmente como respaldos para las aplicaciones que se ejecutan en otros nodos.
Tabla 2.4 Configuracin de un Clster

15

Elemento

Descripcin Consiste en componentes de software que cooperan entre s para permitir que el clster parezca como un sistema nico. Entre sus funciones se encuentran:

Monitorizacin de nodos y procesos. Control de acceso a recursos compartidos. Satisfaccin de requerimientos del usuario.

Infraestructura de

alta disponibilidad. Esta puede ser parte del ncleo del sistema operativo o una capa situada sobre ste, las ventajas de dichas integraciones son: En forma de capa, una solucin independiente del sistema operativo. En el sistema operativo, una eficiencia y facilidad de uso. Son clientes de la infraestructura y usan las facilidades Servicios de alta disponibilidad. que exporta ese nivel para mantener en todo momento el servicio. Usualmente existe una degradacin del sistema cuando un nodo falla pero no una interrupcin del servicio.

Tabla 2.5 Estructura de Alta Disponibilidad

2.1.2. Arquitectura de Clustering

16

Figura 2.3 Arquitectura de un Clster

El propsito de un cluster es: Redundancia frente a fallos (alta disponibilidad). Aumento de potencia (escalabilidad). Estos propsitos no son excluyentes. Importante.- A la hora de escoger que tipo de clster se va a utilizar hay que tener en cuenta las caractersticas que nos ofrece cada tipo y cul es el que ms encaja en nuestro entorno.

2.1.2.1. Alta disponibilidad La alta disponibilidad ha sido tradicionalmente un requerimiento exigido a aquellos sistemas que realizaban misiones crticas. Sin embargo, actualmente, est siendo cada vez ms importante exigir esta disponibilidad en sistemas comerciales y en reas acadmicas donde el objetivo de prestar los servicios en el menor tiempo posible es cada vez ms perseguido.

El concepto de clster de disponibilidad continua, se basa en la idea de mantener la prestacin del servicio en todo momento. Esto representa una situacin ideal, sera necesario que el sistema estuviera compuesto de componentes perfectos que no fallaran nunca, tanto en hardware como en software. Realmente no hay sistemas que puedan asumir este tipo de disponibilidad.1

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

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

17

redundancia software incluye la administracin del hardware redundante para asegurar su correcto funcionamiento al hacer frente a la cada de algn elemento. La redundancia en el tiempo hace referencia a la repeticin de la ejecucin de un conjunto de instrucciones para asegurar el comportamiento correcto en caso de que ocurra un fallo.

Definiremos un clster de alta disponibilidad como un sistema capaz de encubrir los fallos que se producen en l para mantener una prestacin de servicio continua.

El clster de alta disponibilidad va a poder disearse con distintas configuraciones. Una posible configuracin es activo pasivo en el cul las aplicaciones se ejecutan sobre el conjunto de nodos activos, mientras que los nodos restantes actan como backups redundantes para los servicios ofrecidos.

En el otro extremo, tenemos otra posible configuracin, activo activo: en este caso, todos los nodos actan como servidores activos de una o ms aplicaciones y potencialmente como backups para las aplicaciones que se ejecutan en otros nodos. Cuando un nodo falla, las aplicaciones que se ejecutaba en l se migran a uno de sus nodos backup. Esta situacin podra producir una sobrecarga de los nodos de respaldo, con lo que se ejecutaran las aplicaciones con ms retardo. Sin embargo es aceptable una degradacin del servicio y tambin suele ser preferible a una cada total del sistema. Otro caso particular de clster de alta disponibilidad sera el de un clster de un solo nodo, tratndose en este caso, simplemente, de evitar los puntos nicos de fallo.

18

Los conceptos de alta disponibilidad y de clustering estn profundamente relacionados ya que el concepto de alta

disponibilidad de servicios implica directamente una solucin mediante clustering.

La principal prestacin de un sistema de alta disponibilidad es que el fallo de un nodo derive en que las aplicaciones que se ejecutaban en l sean migradas a otro nodo del sistema. Este migrado puede ser automtico (failover) o manual (switchover).2

Generalmente este tipo de cluster integra un nmero relativamente pequeo de nodos (entre 2 y 8), aunque existen soluciones comerciales que trabajan en clusters de mayor tamao. En este caso, la escalabilidad no sera un objetivo prioritario, en contraste con el caso de los clusters computacionales.

Las aplicaciones usadas para el diseo y la implementacin de este tipo de clusters no tienen porqu escalar. Sin embargo, actualmente, existe una cierta tendencia a perseguir la escalabilidad tambin en los clusters de alta disponibilidad lo que lleva a que cada vez se busca ms tener un cluster de mayor nmero de nodos pero ms pequeos en tamao y prestaciones.

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

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

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

19

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

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

Los servicios que se mantienen tpicamente sobre este tipo de clusters son las bases de datos, los sistemas de ficheros, los servidores de correo y los servidores web. Y en general, sern utilizados para tareas crticas o servicios ofrecidos por una empresa, grupo de investigacin o institucin acadmica, que no puedan, por sus caractersticas concretas, interrumpir el servicio.

La adaptacin ms comn que debe sufrir una aplicacin para poder ser ejecutada en un clster de alta disponibilidad implementado sobre GNU/Linux, es aadir scripts. Existen APIs para trabajar cmodamente con alta disponibilidad; todas ellas incluyen mtodos que permiten el switchover y el failover y que permiten arrancar, parar o monitorizar una aplicacin por mencionar algunas de sus funcionalidades.

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

20

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

Figura 2.4 Alta disponibilidad

2.1.2.2. Escalabilidad

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

Escalabilidad del hardware (denominada tambin escalamiento vertical). Se basa en la utilizacin de un gran equipo cuya capacidad se aumenta a medida que lo exige la carga de trabajo existente.
3

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

21

Escalabilidad del software (denominada tambin escalamiento horizontal). Se basa, en cambio, en la utilizacin de un clster compuesto de varios equipos de mediana potencia que funcionan en tndem de forma muy parecida a como lo hacen las unidades de un RAID (Redundant Array of Inexpensive Disks o Array redundante de discos de bajo coste).

Se utilizan el trmino RAC (Redundant Array of Computers o Array redundante de equipos) para referirse a los clster de escalamiento horizontal. Del mismo modo que se aaden discos a un array RAID para aumentar su rendimiento, se pueden aadir nodos a un clster para aumentar tambin su rendimiento.

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

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

22

Importante En un clster activo / pasivo el incrementar el nmero de nodos disponibles en el clster no incrementa la potencia del clster ya que nicamente un nodo estar ofreciendo el servicio.

2.1.3. Funcionamiento de un clster

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

Un clster se implementa bsicamente con varias computadoras similares de capacidades no necesariamente altas. Las

computadoras deben conectarse en una LAN compartida dedicada slo para el clster. El clster de alto rendimiento opera bajo circunstancias en el que las tareas a procesar se reparten paralelamente a las computadoras.

Un servicio de clster consta de:

Balanceador de carga. Sistema para la deteccin de fallos en los nodos del clster. Servicio a clusterizar. Recursos del clster.

2.1.3.1. Balanceador de carga

Los balanceadores de carga permiten optimizar la utilizacin de los recursos de un clster mediante la asignacin de tareas a los

23

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

La funcin de los balanceadores, tambin conocidos como network dispatcher es redireccionar las peticiones a los servidores que las estn atendiendo.

Figura 2.5 Balanceador de Carga

2.1.3.2. Sistema para la deteccin de fallos en los nodos del clster

En caso de aparicin de fallo en algn componente, la tolerancia a fallos busca que el sistema siga trabajando, aunque est funcionando en modo degradado, hasta que acabe la ejecucin, lo que podr incidir en mayor o menor medida en sus prestaciones.

24

La tolerancia a fallos en un sistema se logra mediante la inclusin de tcnicas deredundancia. Puede haber redundancia en cualquier nivel: utilizacin de componentes hardware extra (redundancia en el hardware), repeticin de las operaciones y comparacin de los resultados (redundancia temporal),

codificacin de los datos (redundancia en la informacin) e incluso la realizacin de varias versiones de un mismo programa y del uso de tcnicas de Replicacin de Datos (redundancia de datos) o de checkpoint (redundancia de estados).

Los mecanismos para tolerancia a fallos pueden tener un soporte hardware o software, o bien una combinacin de ambos. En sistemas en que la incidencia de fallos sea escasa puede ser recomendable emplear mecanismos de bajo coste con soporte software, siempre que el algoritmo pueda proporcionar la garanta de que acabe la ejecucin correctamente aunque se degraden sus prestaciones. Es necesario un sistema que detecte cuando existen nodos en el clster que no estn disponibles para ofrecer el servicio. En este caso no se enviarn peticiones para ser atendidas si el clster es Activo / Activo o no se balancear el servicio sobre ellos si es Activo / Pasivo.

Para detectar esta situacin se utilizan dos tcnicas: 1. Heartbeat. 2. Disco de quorum. Estos conceptos sern detallados ms adelante.

2.1.3.3. Recursos del clster Son todos aquellos recursos necesarios para el servicio: IP de servicio.

25

Filesystems. Scripts para arrancar el servicio

Figura 2.6 Recursos del Clster

2.1.3.4. Servicio a clusterizar

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

26

Servidores Proxy Cache

2.1.4. Balanceo de Carga

Con el crecimiento de Internet en los ltimos aos el trfico en la red ha aumentado de forma radical y con l, la carga de trabajo que ha de ser soportada por los servidores de servicios, especialmente por los servidores web.

Para soportar estos requerimientos hay dos soluciones: o bien el servidor se basa en una mquina de altas prestaciones, que a largo plazo probablemente quede obsoleta por el crecimiento de la carga, o bien se encamina la solucin a la utilizacin de la tecnologa de clustering para mantener un clster de servidores de tal manera que cuando la carga de trabajo crezca, se aadirn ms servidores al clster.

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

En una situacin ideal la carga se repartir equitativamente entre los distintos servidores. Sin embargo, los clientes cachean los datos del DNS, con lo que la carga no va a repartirse equitativamente y quedara desbalanceada.

27

Figura 2.7 Balanceo de Carga

Adems, an cuando el balanceo de los accesos de los clientes a los servicios se haga de forma balanceada, estos clientes pueden solicitar cargas muy distintas de trabajo al servidor al que se conectan: mientras un cliente puede querer tan slo ver una pgina, otro puede solicitar un buen nmero de ellas. Por otra parte, si un servidor cae, se van a seguir redirigiendo peticiones a l.

Una solucin mejor es utilizar un balanceador de carga para distribuir sta entre los servidores de un clster. En este caso el balanceo queda a nivel de conexin, con una granularidad ms fina y con mejores resultados. Adems, se podrn enmascarar ms fcilmente las posibles cadas de los nodos del clster.

El balanceo de carga puede hacerse a dos niveles: de aplicacin y a nivel IP. Sin embargo, el balanceo a nivel de aplicacin puede provocar efectos de cuello de botella si el nmero de nodos es grande. Cada solucin debe elegirse en funcin de las

28

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

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

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

Cuando un cliente solicita un servicio al servidor virtual, el director escoge un servidor real para que lo ofrezca. Desde ese momento el director debe mantener la comunicacin entre el cliente y el servidor real. Esta asociacin entre cliente y servidor real va a durar slo lo que dure la conexin tcp establecida; cuando se inicie una nueva conexin el director escoger de nuevo un servidor real que puede ser distinto del anterior. As, si el servicio ofrecido es una pgina web, el cliente podra obtener las imgenes o los textos desde distintos servidores reales ocultos por el servidor virtual.

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

29

extrados del LVS, actualizados o reparados y devueltos al clster sin interrumpir la prestacin de servicio.

Asimismo, el sistema es fcilmente escalable y la

alta

disponibilidad en LVS se disea utilizando software mon, heartbeat, fake y coda, que se utilizan para gestionar la alta disponibilidad y para mantener una gestin segura, la

comunicacin (hearbeat) entre mquinas y un sistema de ficheros tolerante a fallos, respectivamente.

2.1.4.1. Balanceadores hardware

Los balanceadores de carga de Hardware son mquinas con el propsito especfico de balancear la carga.

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

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

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

30

2.1.4.2. Balanceadores software

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

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

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

2.1.4.3. Linux Virtual Server - LVS

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

Esta solucin consiste en un balanceador de carga, tambin conocido como director, que ser la mquina que ser accesible directamente para los clientes y luego tendremos los servidores que sern aquellos que recibirn las peticiones de los clientes, va el balanceador de carga, y respondern a las peticiones. Para los clientes, existirn solo los balanceadores de carga, los cuales distribuirn la carga entre los servidores reales.

31

Figura 2.8 Balanceadores de Carga

Se obtiene escalabilidad en el servicio aadiendo nodos, mientras que la disponibilidad se lograra identificando al balanceador que no funciona, y que el nodo aadido tome la funcin de balanceador, para que el servicio no se vea interrumpido.

Esta solucin nos permitir tener el servicio funcionando casi continuamente ya que no se ver afectado por posibles cadas de las mquinas debido a fallos en el suministro elctrico o bien cortes en el ISP de una determinada granja.

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

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

32

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

2.1.5. Deteccin de fallos en los nodos del clster Un clster debe conocer cuando algn nodo no est disponible para no enviarle peticiones de servicio. Por lo cual, un sistema de deteccin de fallos en los nodos del Clster es vital para su funcionamiento. Esto se hace de dos formas: Heartbeat Disco de qurum

2.1.5.1. Heartbeat

Figura 2.9 Heartbeat

33

Es la tcnica ms habitual. Consiste en comunicarse o bien a travs de una interface de red o puerto serie cada cierto tiempo. Si se pierde la comunicacin durante un determinado tiempo se supone que el nodo ha cado.

Para implementar esta tcnica los nodos tiene lneas dedicadas, bien sea por red o conexiones serie por las que se comunican de forma continua para verificar el correcto funcionamiento de los nodos.

El funcionamiento de Heartbeat se basa en el envo y recepcin de seales enviadas por los demonios de Hearbeat que se ejecutan en ambas mquinas, a estas seales se les conocen como latidos.

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

Una vez que el esclavo vuelva a escuchar los latidos del maestro, este tomar el control nuevamente, a menos que dentro de la configuracin de Heartbeat se haya colocado la directiva

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

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

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

34

sucede esto, el esclavo interpretar errneamente que el servidor maestro ha cado y tratara de tomar el control de la prestacin del servicio, cuando el servicio nunca ha dejado de prestarse.

2.1.5.2. Disco de quorum

Disco de quorum es una tcnica complementaria que lo que se hace es que todos los nodos del clster escriben su estado en un disco y de esa forma se determina quien est disponible para dar el servicio.

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

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

Cada nodo escribe de forma continua su estado en el disco y de esta forma se puede verificar que nodos estn disponibles para hacerse con el servicio en el clster.

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

35

Figura 2.10 Disco de Quorum

36

CAPITULO 3

INTRODUCCION En este captulo se presentarn las soluciones de software libre para mitigar el problema de alta disponibilidad y balanceo de carga, se expondrn sus caractersticas as como las herramientas que hacen posible la construccin de dichas soluciones.

Adems se llevar a cabo una comparativa de las herramientas existentes para la realizacin del clster, adems de ello, se describirn tales herramientas de forma breve en cuanto a sus componentes y su funcionamiento.

DIAGNOSTICO

3.1. Herramientas de open source para la construccin del Clster Podemos encontrar una amplia variedad de aplicaciones para la creacin de clsters, la utilizacin de una u otra de estas depender de la complejidad de instalacin, uso especfico y ventajas de este sobre otras herramientas. De las opciones que se pueden encontrar estn:

openMosix. Oscar. Piranha. Linux Virtual Server. Ultramonkey.

A continuacin la tabla 3.1 muestra las principales caractersticas de cada herramienta para la construccin de clsters.

37

Herramienta.

Caractersticas. Parche al kernel de GNU/Linux. Algoritmo interno de balance de carga que migra los procesos entre nodos.

openMosix

Migracin de procesos totalmente transparente. Auto descubrimiento de nuevos nodos openMosix en la red del clster.

Permite instalar un clster tipo Beowulf. Contiene todo el conjunto de paquetes necesarios para programar y administrar el clster.

OSCAR

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

Implementacin de software de alta disponibilidad. Interfaz web para control completo del clster. Posee herramientas para su monitorizacin. Balance mediante direcciones IP. Requiere el sistema operativo Red Hat Enterprise. Constituido por un servidor altamente escalable y de alta disponibilidad.

Piranha

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

Linux Virtual Server LVS

Clster completamente transparente al usuario final.

Mecanismo para que el clster funcione con una IP pblica.

Permite balance de carga y alta disponibilidad. Incluye monitorizacin de servidores reales y nodos de balance.

Permite el manejo de protocolos como HTTP, FTP,

38

DNS, entre otros. Ultramonkey

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

Usado desde clsters de dos nodos hasta grandes sistemas.

Tabla 3.1 Caractersticas de Herramientas para Clsters.

Por ltimo, se mostrarn las ventajas y desventajas de cada una de las herramientas anteriormente mencionadas, pues es importante tener presente esta comparativa para hacer una primera

aproximacin a la eleccin de una sola herramienta para llevar a cabo una implantacin eficaz y sencilla que cubra las necesidades solicitadas; esto se refleja en la tabla 3.2.

Herramienta.

Ventaja. No se requieren paquetes adicionales.


Desventaja. Depende del kernel. No migra todos los procesos siempre.

openMosix

No son necesarias modificaciones en el cdigo de openMosix.

Problemas con memoria compartida.

Migracin de procesos.

Falla la deteccin de algunos componentes

Es una compilacin auto instalable.

de hardware en versiones anteriores a la 3.

Infraestructura de software para instalar y administrar

Soporte para distribuciones basadas en RPMs solamente

OSCAR

un clster. Posee bibliotecas y

39

compiladores para uso en clsters.

para versiones anteriores a la 5. Requiere que la LAN no sea usada para instalar software en el clster.

Soporte por parte de Red Hat Inc.

Al momento solo disponible para versiones empresariales de Red Hat.

Fcil instalacin debido al formato de distribucin.

Piranha

Administracin y manejo mediante interfaz web.

Dependiente del sistema operativo Red Hat Enterprise.

Monitorizacin de servidores reales.

Fcil comprensin de funcionamiento.

Algunos esquemas se ven afectados por la cantidad de servidores reales que se pueden utilizar.

Amplia gama de configuraciones.

Linux Virtual Server - LVS

Funciona a nivel TCP/IP. Manejo de varios tipos de protocolos como HTTP, DNS, FTP entre otros.

Cuando el nmero de servidores reales es elevado se genera mucho trfico en la red de trabajo.

Mltiples esquemas de configuracin.

Rene varias herramientas de una manera sencilla.

Los nodos directores tienen que ejecutar estrictamente el sistema operativo GNU/Linux.

Varios formatos para su instalacin.

Amplia documentacin sobre cada componente.

40

Ultramonkey

Instrucciones de instalacin para las distribuciones de GNU/Linux ms comunes en servidores.

Segn el esquema de configuracin puede llegar a ser complejo.

Mismas que en LVS para los componentes que sean utilizados de dicho proyecto.

Se apoya en el proyecto LVS para algunos componentes.

No es dependiente de una distribucin de GNU/Linux en particular.

Tabla 3.2 Ventajas y Desventajas de las Herramientas para Clster.

3.2. Comparacin de las herramientas de balanceo de carga y alta disponibilidad

Formato Herramient a de Distribuci n

Distribucione s Soportadas

Balanceo de carga y Alta disponibilidad Ventajas Desventajas

No requiere Balanceo de openMosix RPM, Cdigo fuente. Todas. carga de procesos sin alta disponibilidad. paquetes adicionales y hace migracin de procesos.

Dependiente del kernel y posee problemas con memoria compartida. En versiones anteriores a la tercera falla la

Auto instalable deteccin de

41

RPM, OSCAR Cdigo fuente.

Red Hat y basadas en esta.

Balanceo de carga de procesos sin alta disponibilidad.

con bibliotecas hardware y no y compiladores permite usar la red interna

para computo para paralelo. instalacin de software. Soporte de Actualmente disponible solo

Red Hat Piranha RPM.

Posee

Red Hat,

Enterprise 4 o herramientas posteriores. propias para ambos aspectos.

administracin en formato y manejo mediante interfaz web. RPM y para versiones empresariales. Instalacin por Amplia gama segmentos; con un gran

Incluye Linux Virtual Server RPM, DEB, Todas. Cdigo fuente. herramientas de cdigo abierto para ambos aspectos.

de

configuracione nmero de s, funcin a servidores

nivel TCP/IP y reales el manejo de distintos protocolos. trfico crece de manera significativa. Los nodos de Mltiples balance de

Basadas en Debian, Red

Uso de componentes

configuracione carga debern s, manejo de distintos protocolos, ejecutar el sistema operativo

Hat Enterprise de LVS para RPM. DEB, 4 y mediante Ultramonke Cdigo y fuente. compilacin de cdigo fuente. ambos aspectos aadiendo algunas mejoras y

funcin a nivel GNU/Linux; TCP/IP, marcas de firewall y dependiendo del esquema llega a ser

42

herramientas.

ampliacin de complejo de LVS. configurar.

Tabla 3.3 Comparacin de herramientas para clster.

Una de las herramientas las ms usadas es Piranha de la empresa Red Hat., que incorpora balance de carga mediante direcciones IP y tambin hace la inclusin de cdigo del proyecto LVS, en esta herramienta Red Hat incorpor mejoras; para poder hacer uso eficiente de Piranha es recomendado el uso de Red Hat Enterprise Linux 4 o posterior, su sencillez en instalacin y amplio soporte por parte de dicha empresa brinda satisfaccin al hacer una

implementacin con esta. Fuera del pago de la licencia para el sistema operativo el software de Piranha est disponible de manera gratuita para usuarios registrados de esta distribucin.

Junto a la anterior herramienta se puede encontrar el proyecto LVS el cual fue iniciado por Wensong Zhang en Mayo de 1998 y su principal objetivo era desarrollar un servidor GNU/Linux de alto rendimiento que proporcione un buena escalabilidad, confianza y robustez usando la tecnologa de clster. De los avances ms importantes de LVS es el desarrollo de un sistema IP avanzado de balanceo de carga por software (IPVS), balance de carga por software a nivel de aplicacin y componentes para la gestin de clster. Se puede usar LVS como solucin para construir sistemas altamente escalables, donde se garantiza una alta disponibilidad de los servicios de red como el correo electrnico, voz sobre IP y el servicio web.

La siguiente opcin es Ultramonkey, siendo una de las herramientas ms completas en cuanto a balanceo de carga y alta disponibilidad; ya en su tercera versin cuenta con formatos de instalacin para

43

diversas distribuciones de GNU/Linux como Debian y Red Hat. Esta herramienta solo puede ser usada en estaciones cuyo sistema operativo sea GNU/Linux siendo este uno de sus pocos

inconvenientes en lo que respecta a la independencia de plataforma. Hace uso de las tecnologas de LVS, Linux-HA y Ldirectord para lograr ambas metas que son el balance de carga y la alta disponibilidad. De entre los posibles esquemas de configuracin se cuenta con soluciones separadas o una que incorpore ambas, as como tambin un esquema estndar o uno ms completo.

La herramienta OSCAR es una coleccin de software de cdigo abierto para crear un clster sobre GNU/Linux desarrollada por el Grupo de Clsters Abiertos (OCG Open Clster Group). El objetivo primario del grupo de trabajo OSCAR es conseguir que la instalacin, la configuracin y la administracin de un clster de tamao modesto, sea fcil. Cualquier cosa necesaria para un clster como instalacin y configuracin, mantenimiento, programacin (paralela), sistemas de encolamiento, programacin de tareas, est incluida en OSCAR. Su principal labor es para cmputo de alto rendimiento.

En Open Mosix los procesos no saben en qu nodo del clster se ejecutan, y es el propio Open Mosix el responsable de "engaarlos", y redirigir las llamadas al sistema al nodo del clster en el que se lanz el proceso. Open Mosix implementa un algoritmo de balance de carga que permite repartir de forma ptima la carga, si est el clster bien calibrado. Open Mosix puede migrar cualquier proceso mientras que no haga uso de los segmentos de memoria compartida. Segn la calibracin, migrarn procesos ms ligeros, o ms pesados.

44

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

Piranha. Linux Virtual Server. Ultramonkey.

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

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

El parche IPVS para el kernel. El demonio LVS para manejar las tablas IPVS a travs de ipvsadm.

El demonio nanny para monitorizar servicios y servidores. El demonio pulse para controlar el estado del resto de demonios del clster y la entrada en funcionamiento del nodo de balance de carga de respaldo en caso de fallo del primario.

La interfaz grfica piranha para administrar el clster.

Todos estos demonios utilizan el mismo archivo de configuracin ubicado en el directorio /etc/lvs.cf para su funcionamiento. Como un valor aadido a piranha este es capaz de adaptar los pesos de los algoritmos de planificacin automticamente segn las estadsticas

45

de funcionamiento de cada servidor.

En la figura 3.1 se aprecia

cmo se compone un clster con Piranha.

Figura 3.1 Esquema de funcionamiento de Piranha.

3.2.1.2. Linux Virtual Server Es un software para el balanceo de carga que permite crear un clster de forma rpida y eficaz sin hacer grandes inversiones en hardware dedicado. Es una solucin ideal para aquellas empresas que quieren ahorrar costos permitiendo tener tras una nica direccin IP pblica muchos servidores reales y servicios de forma transparente a los usuarios.

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

46

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

LVS soporta tres modos de trabajo distintos, estos modos definen el mtodo en que el nodo de balanceo retransmitir las

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

Figura 3.2 Esquema de funcionamiento de LVS.

47

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

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

3.2.1.3.1.1. Heartbeat Funciona enviando peridicamente un paquete, que si no llegara, indicara que un servidor no est disponible, por lo tanto se sabe que el servidor ha cado y se toman las medidas necesarias. Se recomienda el uso de puertos serie puesto que estn aislados de las tarjetas de red. Soporta mltiples direcciones IP y un modelo servidor primario/secundario.

Los mensajes de Heartbeat se envan por todas las lneas de comunicacin a la vez, de esta manera, si una lnea de apoyo cae, se avisar de ese problema antes de que la lnea principal caiga y no haya una lnea secundaria para continuar el servicio. Heartbeat tambin se preocupa por la seguridad, permitiendo firmar los paquetes con CRC de 32 bits, MD5 y SHA1.

48

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

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

Figura 3.3 Componentes de Ultramonkey.

Mientras el software Ultramonkey funciona por s mismo en GNU/Linux, este puede proporcionar servicios de clster para

49

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

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

Figura 3.4 Esquema de funcionamiento de Ultramonkey.

50

CAPITULO 4

INTRODUCCION En este captulo se llevar a cabo un anlisis de los mtodos existentes de balanceo de carga, dado que estos llegan a ser complejos solamente se tratar la teora ms bsica de operacin; adicionalmente se realizar la toma de decisin de una herramienta para su implementacin.

DISEO

4.1. Tipos de balanceo de carga Existen dos formas simples para montar un clster y distribuir la carga entre los equipos mostradas en la tabla 4.1 a continuacin.

Mtodo

Ventajas

Desventajas El cache de en la la de

informacin Distribucin de la carga DNS Round Robin. entre servidores reales de forma pseudojerarqua

servidores DNS y la forma simple de

aleatoria. Es el ms simple de implementar.

tomar decisiones por parte del servidor

DNS restringen su utilidad. Los servidores no pueden ser

51

seleccionados segn el URL solicitado.4 Este nodo distribuye las conexiones. Se Uso de nodo de balanceo de carga. aumenta de la unidad Llega a convertirse en cuello de botella. Hace uso de un nodo adicional para

sensacin del clster. nica

proveer el balanceo IP de carga. Al existir de solo un

direccin

pblica a la cual dirigir las peticiones. Es sencillo enmascarar fallas de los servidores.

nodo

balanceo

este se convierte en un punto nico de fallo.

Tabla 4.1 Mtodos de balanceo de carga.

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

Modo de balanceo

Ventajas

Desventajas

Aprovecha

la

El

nodo

de

posibilidad del kernel de Linux de funcionar como router con NAT. Balanceo mediante NAT. (Network
4

balanceo se llega a convertir en cuello de botella. Tiene que reescribir todos los paquetes

Los servidores reales pueden ejecutar

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

52

Address Translation).

cualquier

sistema

TCP/IP. Nmero servidores de reales

operativo que soporte TCP/IP. Uso una de solamente IP

dependiente de la velocidad de

direccin

pblica.

conexin del nodo de balanceo. No todos los

Escalado Balanceo mediante encapsulado IP (IP Tunneling)

de

hasta

sistemas operativos son soportados por este modo. Los reales tener pblica. Todos servidores poseer los deben una IP servidores necesitan una IP

100 servidores o ms. Se evita que el nodo de balanceo se

convierta en cuello de botella.

Balanceo mediante enrutamiento directo (Direct Routing)

El nodo de balanceo no es cuello de

pblica en el mismo segmento de del nodo red de

botella. No se sobrecarga al nodo de balanceo en reescribir TCP/IP. paquetes

balanceo. No todos los

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

Tabla 4.2 Modos de balanceo de carga en LVS.

53

Balanceo mediante NAT NAT (es un mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que se asignan mutuamente

direcciones incompatibles. Consiste en convertir en tiempo real las direcciones utilizadas en los paquetes transportados. Tambin es necesario editar los paquetes para permitir la operacin de protocolos que incluyen informacin de direcciones dentro de la conversacin del protocolo).5 A continuacin 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.

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 peticin de servicio a la IP pblica del clster (la del nodo de balanceo de carga o IP virtual del clster).

2.

El nodo de balanceo planifica a qu servidor real se va a enviar la peticin, reescribe las cabeceras de las tramas TCP/IP y las enva al servidor.

3.

El servidor recibe la peticin, la procesa, genera la respuesta y la enva 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 enva de vuelta al usuario.

5.

La respuesta llega al usuario, como si la hubiese generado la IP pblica del clster.

En el modo de balanceo por encapsulamiento IP, su funcin se ilustra a continuacin con la figura 4.2:

55

Figura 4.2 Balanceo mediante encapsulado IP.

El nodo de balanceo recibe todas las conexiones de entrada al clster, y decide a qu servidor envirselas. 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 pblica del clster como propia, acepta la trama original y se encarga de servir la peticin 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 tendrn configurado una interfaz con la IP pblica del clster: el nodo de balanceo la tendr en su acceso a Internet y ser el punto de entrada al clster; el resto de equipos estarn conectados al nodo de balanceo en la misma red fsica y en la interfaz conectada a sta red tendrn configurada la IP pblica del clster, pero configurando la interfaz para que no responda a comandos ARP (todos los equipos responderan por la misma IP con distintas direcciones fsicas). Al llegar una peticin al nodo de balanceo ste decide a qu servidor envirsela y redirige el paquete a nivel de enlace a la direccin fsica del servidor elegido en lugar de modificar o encapsular el paquete TCP/IP. Cuando llega al servidor con la direccin fsica de destino y se analiza hasta el nivel de red (TCP/IP), como el servidor tambin tiene configurada la IP pblica del clster, acepta sin ms el paquete y genera la respuesta que enviar directamente al cliente.

4.1.2. Resumen de los mtodos de balanceo En la tabla 4.3 a continuacin se resumen las caractersticas principales de los tres mtodos de direccionamiento que puede utilizar el balanceador de carga de Linux Virtual Server:

NAT

Encapsulamiento IP

Enrutamiento Directo

Servidor

Cualquiera

Necesita Encapsulamiento

Dispositivo no-ARP

Red de servidores

Red Privada

LAN/WAN

LAN

57

Escalabilidad Salida hacia Internet

Baja (10~20) Nodo balanceo de

Alta

Alta

Router

Router

Tabla 4.3 Mtodos de direccionamiento.

4.1.3. Planificacin del balanceo de carga Al momento de configurar el nodo de balanceo se podr elegir entre una serie de algoritmos para ver cmo se distribuir la carga entre los servidores y cmo se elegir el servidor al que se enva cada peticin. Linux Virtual Server permite utilizar los siguientes algoritmos que se muestran en la tabla 4.4:

Algoritmo

Funcionamiento Cada peticin se enva a un servidor y la siguiente

Round Robin

peticin al siguiente servidor de la lista hasta llegar al ltimo tras lo cual se vuelve a enviar al primero, vase la figura 4.4. Igual que el anterior algoritmo pero aadiendo un peso a cada servidor, este peso es un entero que indica la

Round Robin Ponderado

potencia de clculo del servidor, de modo que la cola Round Robin se modificar para que aquellos servidores con mayor capacidad de clculo reciban peticiones ms a menudo que el resto, vase la figura 4.5. Este mecanismo de distribucin consulta a los servidores

Servidor con menos conexiones activas. Servidor con

para revisar en cada momento cuntas conexiones abiertas posee cada uno con los clientes, y enva cada peticin al servidor que menos conexiones tenga en ese momento, vase la figura 4.6. Igual que el algoritmo anterior pero se le aaden pesos a

58

menos conexiones activas Ponderado.

los servidores para que de alguna forma se mida su capacidad de clculo para modificar la preferencia al momento de hacer una eleccin, vase la figura 4.7.

Este algoritmo dirige todas las peticiones a un mismo Menos conectado basado en servicio. servidor, hasta que se sobrecarga (su nmero de conexiones activas es mayor que su peso) y entonces pasa a una estrategia de menos conexiones activas ponderada sobre el resto de servidores del clster, vase la figura 4.8. En estos algoritmos se dispone de una tabla de Tablas Hash por origen y destino. asignaciones fijas, en las que bien por la IP de origen o destino, se indica qu servidor deber atender la peticin. El nodo de balanceo compara las direcciones de las tramas TCP/IP que reciba con estas tablas y acta en consecuencia, vase la figura 4.9. Conexiones Persistentes. A todos los algoritmos de planificacin anteriores se les puede aadir el hecho cuando un cliente se ha conectado con un servidor, siempre se le dirija al mismo servidor.

Tabla 4.4 Algoritmos de planificacin 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 eleccin de una u otra tcnica depende principalmente del servicio que se quiera proveer, los conocimientos que se posean de los sistemas, el sistema operativo de los servidores, los recursos econmicos que se estn dispuestos a gastar, y consideraciones de rendimiento que afectan al sistema en conjunto.

4.2. Eleccin de una herramienta para balanceo de carga y alta disponibilidad Para poder tomar una decisin acerca de cul herramienta es la mejor opcin se debe tomar en cuenta factores como: estabilidad, fiabilidad, costos de implementacin (tanto en hardware como en conocimientos), escalabilidad entre otros. Como parmetros para poder evaluar dichas herramientas se usar la cantidad de requisitos por cada herramienta, facilidad de comprensin e implementacin as como tambin su disponibilidad para su adquisicin. Las herramientas evaluadas son Piranha, Linux Virtual Server y Ultramonkey. Como punto de partida se compararn los requisitos mnimos para la implementacin de cada una en cuanto a los equipos que actan como coordinadores o directores.

Piranha: Esta herramienta solamente requiere el uso de un navegador web para configurarse pero una de sus crticas es el hecho de estar fuertemente ligada a las versiones empresariales de Red Hat y por tal motivo los mnimos en hardware dependern de la versin de dicha distribucin que se utilice. Como un punto a favor, Piranha posee esa extrema sencillez de configuracin 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 versin empresarial. La tabla 4.5 muestra los requisitos mnimos de hardware requeridos.

Procesador Memoria RAM Espacio en Disco Duro Interfaz de Red

Pentium II 300 MHz 64 MB +2 GB recomendado 10 Mbps

Tabla 4.5 Requisitos mnimos de hardware para Piranha.

Linux Virtual Server: Este es muy simple de implementar y debido a sus caractersticas los nodos directores o de balanceo pueden poseer o no una interfaz grfica ya que su administracin es va lnea 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 distribucin del sistema operativo (siempre y cuando sea GNU/Linux, la distribucin puede variar) pues est ms ligado con el kernel que con la distribucin. Para su implementacin bastar con un equipo que cubra los mnimos requisitos en hardware para una distribucin basada en un kernel 2.4.27 o superior siendo un ejemplo el de la tabla 4.6.

Procesador Memoria RAM Espacio en Disco Duro Interfaz de Red

Pentium MMX 166 MHz 64 MB +1 GB (sin interfaz grfica) 10 Mbps

64

Tabla 4.6 Requisitos mnimos de hardware para LVS.

Ultramonkey: Ultramonkey est pensado como una solucin muy econmica 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 gures de la informtica. En la tabla 4.7 siguiente se aprecian los mnimos de hardware para ultramonkey.

Procesador Memoria RAM Espacio en Disco Duro Interfaz de Red 64 MB

Pentium MMX 166 MHz

+512 MB (recomendados +1GB) 10 Mbps

Tabla 4.7 Requisitos mnimos de hardware para Ultramonkey.

Se concluye que Ultramonkey es la herramienta que requiere la menor cantidad de recursos para su instalacin y funcionamiento, la tabla 4.8 compara los requisitos mnimos de hardware de Piranha, LVS y Ultramonkey.

Memori Herramienta. Procesador. a RAM.

Espacio en Disco Duro.

Interfaz de Red.

Piranha.

Pentium II 300MHz

64 MB

+2GB

10 Mbps

65

LVS.

Pentium MMX 166MHz

64 MB

+1GB

10 Mbps

Ultramonkey.

Pentium MMX 166MHz

64 MB

+512MB

10 Mbps

Tabla 4.8 Comparacin de requisitos.

El siguiente punto a evaluar es la complejidad de instalacin, tmese en cuenta que todos los parmetros que se estn evaluando son sobre los nodos principales, sin tomar en cuenta los servidores reales.

Ultramonkey: Esta es la herramienta ms simple de instalacin 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 acta como nodo director posee un sistema diferente tendr que llevarse a cabo la instalacin de dos formas distintas dependiendo de: Basado en Red Hat: mediante paquetes RPM con la instruccin rpm -iv *.rpm estando dentro del directorio que contenga todos los paquetes de Ultramonkey. Basados en cdigo fuente: tendrn que descargarse todos los paquetes que conformen Ultramonkey, luego se procede a descomprimir cada uno y posteriormente se procede a su compilacin e instalacin.

Piranha: Esta herramienta es sencilla de instalar si se posee una licencia del sistema operativo Red Hat Enterprise utilizado, su instalacin puede realizarme mediante un administrador de paquetes grfico propio del sistema operativo o bien, mediante la lnea 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 instalacin manual en la cual depender el tipo de paquete adquirido, si es en formato RPM o en forma de cdigo fuente. La instalacin 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 instalacin.

LVS: Para llevar a cabo la instalacin de LVS es necesario activar los mdulos de LVS en el kernel de la distribucin utilizada, posteriormente se debe instalar la aplicacin ipvsadm pues esta ser nuestra interfaz de comunicacin con LVS. Una vez activado el soporte y la interfaz con LVS se procede a su configuracin y pruebas pertinentes. Es importante notar que de no contar con un kernel con soporte activado las alternativas existentes son una recompilacin del mismo kernel o la compilacin de uno totalmente nuevo habilitando dicho soporte en ambos casos; si la distribucin utilizada posee mecanismos para instalar un kernel con soporte incluido esto facilita la tarea, de otra manera el proceso de configuracin, activacin del soporte, compilacin e instalacin deber realizarse de forma manual.

Se concluye que Ultramonkey es la herramienta que posee los mecanismos de instalacin ms simplificados, ahorrando tiempo y esfuerzo dada la automatizacin 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 mtodos que posee cada una para su distribucin.

67

Ultramonkey: Este proyecto es de fcil adquisicin 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 gestin de paquetes har notar que debe instalar otros paquetes que son dependencias y ubicar los archivos en los sitios correspondientes; esta es la manera ms fcil de instalar Ultramonkey, es limpia, rpida y muy eficiente. Si se desea instalar sobre una distribucin 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 instalacin de forma manual, en caso de usar una distribucin 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 distribucin y adquisicin para varios sistemas operativos GNU/Linux eliminando la restriccin de dependencia de una distribucin en especial. Aunque LVS se distribuye como cdigo fuente y Piranha en paquetes RPM o cdigo fuente, la herramienta Ultramonkey brinda una mejor variedad de formatos y medios de adquisicin siendo este punto el que le brinda ventaja sobre las anteriores y siendo esta la mejor eleccin.

Como se puede apreciar por estos tres indicadores, la mejor opcin para eleccin es Ultramonkey debido a su sistema de instalacin, variedad de formatos de distribucin as como sus requisitos mnimos de hardware muy bajos. Sin duda las otras opciones son muy viables, pero presentan limitantes; con esto presente queda establecido que la mejor opcin para

68

implementacin es Ultramonkey ya que est bien acoplado con la distribucin Centos la cual tiene un elevado reconocimiento en cuanto a estabilidad y seguridad como en el aprovechamiento de recursos de una estacin, sistema de gestin 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 captulo tiene como finalidad describir la manera de cmo se lleva a cabo el proceso de construccin del clster, as como tambin de hacer notar cuales aspectos se debern tomar en cuenta para su configuracin.

IMPLEMENTACION EN MAQUINAS VIRTUALES

5.1 INSTALACION Y CONFIGURACION DEL CLUSTER El clster funcionar de la siguiente manera (figura 5.1), el usuario realizar una peticin de una pgina web al servicio (el usuario desconoce que se trata de un clster), al llegar la peticin al nodo de balance este redireccionar dicha peticin a uno de los servidores reales mediante al algoritmo de balanceo de carga establecido. El servidor real que atiende dicha peticin tiene como origen de la misma al nodo de balanceo y no al usuario debido al mtodo 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 enva al usuario que la solicit teniendo como su direccin la IP virtual del clster y no la IP real del nodo de balanceo, esto es as porque al hacer el cliente la peticin, se hace a la IP virtual del clster y es de esta misma direccin de donde se obtiene la respuesta haciendo creer al usuario que es atendido por un solo equipo y no por un clster. Tabla 5.1. En caso de existir una falla en uno de los servidores reales el balanceador verifica cul 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 prdida de servicio, sta se da cuando todos los nodos servidores fallan.

70

Figura 5.1 Funcionamiento del Clster.

Se hace una peticin de pgina a la IP virtual del clster. La peticin se enva al nodo de balanceo, ste mediante un algoritmo enva la peticin al servidor real correspondiente. El servidor real que recibe la peticin la procesa y enva el resultado al nodo de balanceo. El nodo de balanceo enva la respuesta a la peticin al cliente indicando que la direccin IP del paquete que sale es la IP virtual del clster y no la IP del nodo de balanceo. El cliente recibe la respuesta a su peticin por parte de la IP virtual del clster, el cliente en ningn momento se da cuenta que es atendido por un clster.
Tabla 5.1 Funcionamiento del Clster.

71

5.1.1 SELECCIN DE NODOS PARA EL CLSTER Para la seleccin de los nodos que conforman el clster es importante hacer notar que aquellos destinados a tomar la funcin de nodos de balanceo no necesariamente sern los de mayores prestaciones (con mayores recursos), con esto en mente se proceder a listar los componentes primordiales para dicha eleccin. Primero los nodos que actuarn como nodos de balanceo tendrn, como mnimo, 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 instalacin).

Tabla 5.2 Especificaciones del nodo de balanceo.

En lo concerniente a los nodos que funcionan como servidores web, estos debern contar con una mayor capacidad que los nodos de balanceo pues son estos los que realizan el verdadero trabajo de atencin a usuarios. Los requisitos mnimos 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 instalacin).

72

Tabla 5.3 Especificaciones de nodo servidor.

A continuacin 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.)

Cliente

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

Balanceo de Carga

Editor de textos VIM.

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

Tabla 5.4 Herramientas utilizadas en cada nodo.

Herramienta.

Caractersticas. Balanceo de carga. Escalabilidad. Bajo consumo de recursos. Diversos esquemas de

Caractersticas Principales.

Balanceo de carga. Alta disponibilidad.

Suite

configuracin.

73

Ultramonkey

Manejo de diversos protocolos como HTTP, FTP, etc. Crear y editar archivos de texto. Manejo de pestaas para mltiples documentos. Uso de nmeros de lnea.

Escalabilidad.

Crear y editar archivos de texto. Uso de nmeros de lnea. Bsqueda de patrones dentro del documento.

Editor de textos VIM.

Bsqueda de patrones dentro del documento. Ejecucin de comandos sin salir del editor. Soporte de lenguajes de programacin mediante mdulos. Soporte para HTTPS.

Soporte de mdulos para lenguajes y otras aplicaciones. Soporte de SSL. Creacin de host virtuales.

Servidor de Pginas web Apache2.

Soporte para SSL (Secure Socket Layer) mediante mdulo. Permite crear host virtuales. Amplia gama de configuraciones. Calidad de servicio. Mantenimiento de varias tablas de ruteo.

Balanceo de carga. Mantenimiento de varias tablas de ruteo.

Aplicacin IPROUTE.

Balanceo de carga. Definicin de tneles. Permite interceptar y manejar paquetes de red. Permite el manejo de paquetes en diferentes estados del procesamiento. Permite construir firewalls basados

Intercepcin y manejo de paquetes de red. Construccin de firewalls basados en

Aplicacin

en GNU/Linux.

74

IPTABLES.

Realiza traduccin de direcciones (NAT).

GNU/Linux. Traduccin de direcciones (NAT).

Permite depurar aplicaciones que utilizan la red para comunicar. Permite depurar la red misma. Aplicacin TCPDUMP. Permite capturar y leer datos enviados por otros usuarios o computadoras. Permite capturar y leer datos enviados por otros usuarios o computadoras.

Tabla 5.5 Caractersticas de herramientas utilizadas.

5.1.2 Instalacin 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 instalacin se llevar a cabo en dos partes, la primera comprende la instalacin del sistema operativo tanto en nodos de balanceo como en nodos servidores y la segunda parte comprende la instalacin del software para el balanceo de carga. En cuanto a la primer parte que comprende la instalacin del sistema operativo, se debe tomar en cuenta que se realiza con un entorno grfico, por tanto se proceder conforme a la tabla 5.6.

Proceso de instalacin del Sistema Operativo.


Creacin de mquina virtual en VMware Seleccin de medio de instalacin. Proceso de instalacin del sistema base. Instalacin de paquetes adicionales.

Tabla 5.6 Proceso de instalacin del Sistema Operativo.

75

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

Medios de Instalacin.

DVDROM bsico para instalacin mediante red. DVD del juego de la distribucin. Juego completo de discos de la distribucin. Archivo ISO guardado en el disco de la mquina virtual

Tabla 5.7 Medios de instalacin.

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

Aspecto.

Descripcin. Debe especificarse a qu zona horaria pertenece el

Zona Horaria.

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

Contrasea de administrador y usuario(s).

Simplemente se pedirn las contraseas para la cuenta de administrador y la(s) cuenta(s) de los usuarios comunes que utilizarn el sistema. Muestra las opciones de configuracin automtica mediante el protocolo DHCP; de forma manual en la

76

cual se proporcionan datos como la direccin IP y la Configuracin de la red. puerta de enlace y por ltimo permite dejar de momento sin configuracin la interfaz de red.

Aqu se marcarn aquellos servicios que sean Seleccin 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 instalacin del sistema base.

El resto del proceso de instalacin y detalles relacionados se cubren en el anexo 1 (Instalacin del sistema operativo en maquinas virtuales). La tabla 5.9 a continuacin muestra los servicios que se debern activar en los nodos servidores.

Servidor de pginas web Apache. Editor de textos VIM. Aplicaciones IPROUTE e IPTABLES.

Tabla 5.9 Servicios activados en los nodos servidores.

5.1.3. Configuracin de los servidores web Los servidores reales deben ser configurados para ejecutar el servicio web provisto por el clster usando como aplicacin para tal efecto un software como Apache. Cuando se trabaja con servidores web es altamente recomendable hacer uso de direcciones IP estticas y para ello se debe editar la configuracin 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 direccin 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 aplicacin iproute (sta aplicacin se compone de un conjunto de herramientas muy potentes para administrar interfaces de red y conexiones en sistemas GNU/Linux). Las caractersticas que brinda esta configuracin 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 ms trabajo a un servidor con mayor capacidad que otro, repartir el total de conexiones si todos los servidores son iguales en caractersticas para no saturar ninguno y poder atender de manera eficiente al usuario final. Despus 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 sealar 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 tambin cierto grado en los servidores reales pues aunque con solo un servidor real se puede todava brindar el servicio, en realidad no existe ningn 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 travs 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 conexin ser abandonada.

78

Figura 5.2. Configuracin final de nodos.

5.2. Instalacin de CentOs Para la instalacin del sistema operativo utilizado (CentOs 5.3), es necesario tener el dvd con la distribucin respectiva, para el caso de este proyecto se utiliz el archivo ISO de la distribucin el mismo que se lo tiene guardado en un directorio del equipo principal. Cabe sealar que se utiliz en software de virtualizacin VMware Workstation en la versin 6.0.0. Este proceso se lo realiz para todos los servidores utilizados en el proyecto. El proceso de instalacin del sistema operativo CentOs se encuentra detallado en el Anexo 1 Instalacin de CentOs.

5.3. Instalacin de Ultramonkey En cuanto a los medios de instalacin de Ultramonkey, los podemos encontrar en forma de paquetes de cdigo fuente, paquetes pre-

79

compilados que se pueden descargar desde la pgina web del proyecto y tambin en el repositorio siguiente:

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

La manera ms sencilla de llevar a cabo la instalacin ejecutar como superusuario el comando yum install para instalar la lista de paquetes disponibles. Este mtodo es el que se utilizar para su instalacin. Si no se cuenta con una conexin 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 pgina del proyecto, en este caso se entrara a la seccin de descargas y se especifica que los paquetes a descargar son para la distribucin GNU/Linux Redhat (cabe sealar que CentOs es la versin liberada de Redhat Enterprise, por esta razn su usan los paquetes disponibles para Redhat). Por ltimo se puede optar por adquirir los paquetes en formato de cdigo fuente comprimidos, una vez descargados se proceder a copiarlos en la estacin donde se necesiten y se llevar a cabo todo el proceso de compilacin e instalacin. Como se puede apreciar, existen mtodos de instalacin 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. Seleccin de topologa de instalacin de ultamonkey Aqu se determina como instalar la solucin de alta disponibilidad y balanceo de carga que provee Ultramonkey de acuerdo a un esquema determinado, posteriormente se detallar el proceso de instalacin. Como muestra la figura 5.2. Configuracin 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 estn asignadas al nodo director del clster y las direcciones IP 192.168.22.4 y 192.168.22.5 a los

80

servidores reales. La VIP (direccin IP 192.168.1.20.

virtual) del clster es

Esta topologa permite el mximo rendimiento (en cuanto a tasa de transferencia) a travs de la red, ya que el trfico de retorno ya no tiene que viajar a travs 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 trfico 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 direccin virtual y el servicio se mantiene. Las conexiones son sincronizadas entre el nodo de balanceo activo y los que estn en espera, de tal forma que cuando una falla ocurre las conexiones existentes pueden continuar. Cuando un nodo de balanceo recibe una conexin desde un usuario final, ste toma la decisin acerca de a cul nodo servidor enviar la conexin. Todos los paquetes del tiempo de vida de esta conexin son enviados al mismo servidor real de tal forma que la integridad de la conexin 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 peridicas de una pgina 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 lnea. Como el nodo de balanceo no es el router de entrada para los servidores reales, el trfico no tiene que viajar a travs 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 trfico de retorno a travs 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. Ms servidores reales pueden ser aadidos a la red si se requiere capacidad extra dado que este esquema permite escalabilidad.

5.4. Configuracin de Heartbeat en los nodos de balanceo Ultramonkey viene con paquetes adicionales. Estos paquetes slo 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 pgina: http://www.ultramonkey.org/download/3/ El proceso de instalacin de toda la solucin se encuentra documentado en el Anexo 2 Instalacin de la solucin.

5.5. Configuracin 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 estn asignadas a al nodo director del clster (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 clster LVS es 192.168.1.20. Para editar la configuracin de un dispositivo de red usamos las herramientas administrativas para esto: system-config-network. Despus 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. Configuracin del clster 5.6.1. Directores Linux, nodos de balanceo Los directores deben estar habilitados para enrutar el trfico hacia los servidores reales. Especficamente, 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 direccin IP virtual y los servidores reales, adems 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 insercin y eliminacin 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 peticin de conexin 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 nmero de conexiones para cada servidor real). Los algoritmos RR, WRR, LC y WLC deberan todos funcionar de forma similar cuando el nodo de balanceo est dirigiendo servidores reales idnticos con servicios idnticos. El algoritmo LC ser mejor manejando situaciones donde las mquinas son dadas de baja y activadas nuevamente. Si los servidores reales estn ofreciendo diferentes servicios y algunos tienen usuarios conectados por un largo tiempo mientras otros estn 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 clster a implementar posee servidores reales idnticos con servicios idnticos, 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 trfico http, y luego la ruta es a travs 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 configuracin 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) reenven los paquetes a travs del linux director (192.168.22.2), es decir, los servidores reales deben tener como default gw a linux director. Encontrar toda la documentacin acerca de la instalacin en el Anexo 2.

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

85

El cliente realiza una peticin al servidor director mediante la direccin IP Virtual del mismo 192.168.1.20 (www.tesismg.com), el servidor director realiza el balanceo y redirecciona la peticin al servidor real disponible, si realizamos nuevamente una peticin veremos que ahora es el otro servidor el que est mostrando su pgina.

Figura 5.3. Pgina del servidor 1

86

Figura 5.4. Pgina del servidor 2

Simulamos una cada del servidor 1 deteniendo el servicio http asi: service httpd stop

Figura 5.5. Detencin del servicio httpd

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

5.8.1. Herramientas para medicin de rendimiento 5.8.1.1. Seleccin de una herramienta para medicin de rendimiento Existen varias herramientas para comprobar el correcto funcionamiento del clster 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 implementacin.

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 ms nodos. El nodo activo del clster redirecciona las peticiones de servicio a un nodo del clster, un servidor que va a entregar los servicios. Entre sus caractersticas soportadas incluyen dos protocolos (TCP y UDP), tres mtodos de reenvo de paquetes (NAT, tneles, y el encaminamiento directo), y ocho algoritmos de balanceo. El comando tiene dos formatos bsicos para la ejecucin: 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 asignacin de las solicitudes de servicio a los servidores reales. De manera opcional, un tiempo de espera persistentes y la mscara 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 mtodo de reenvo de paquetes y el peso del servidor real, en comparacin 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 conexin, el origen y el destino de la conexin.

88

Tcpdump Tcpdump es una excelente herramienta que nos permite monitorear a travs de la consola de Linux todos los paquetes que atraviesen una interfaz indicada. A su vez, los mltiples filtros, parmetros y opciones que tcpdump nos ofrece, nos permite infinidades de combinaciones, al punto de poder monitorear todo el trfico completo que pase por la interfaz, como el trfico que ingrese de una ip, un host o una pgina especfica, podemos solicitar el trfico de un puerto especfico o pedirle a la herramienta que nos muestre todos los paquetes cuyo destino sea una direccin MAC especfica. Ejemplos: tcpdump i eth0 port 80 Muestra todo el trfico 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. Verificacin de servidores y conexiones con ipvsadm l.

89

Figura 5.7. Verificacin de servidores y conexiones con ipvsadm lnc.

Figura 5.8. Trfico en la red con tcpdump.

90

Figura 5.9. Salida de trfico 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 configuracin 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 tambin los servicios que proporcionan y las pginas para control esperadas (servicio en este caso particular de pginas web o HTTP solamente). Para las pruebas de funcionamiento se utiliz configuraciones generales del clster que incluye los nodos de balanceo, los algoritmos para balanceo de carga, instalacin y configuracin del servidor de pginas web Apache, pruebas simples para nodos de balanceo e instalacin y configuracin del paquete iproute en los nodos servidores. Sobre las pruebas realizadas, estas me ofrecen un panorama muy general, puesto que la mayora 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 clster en dichos casos; en las pruebas llevadas a cabo se contaba con un cliente con un sistema operativo distinto al utilizado para la construccin del clster (recurdese que el cliente solamente necesita un navegador web) el cual realiza las peticiones de la pgina web principal alojada en el clster, de esta manera se pudo observar cual servidor real es el que atiende la peticin (en un sistema en produccin esto no deber ser as ya que la intencin es que los usuarios vean al sitio web como un solo equipo). La pgina web solicitada en las pruebas solamente contiene una cadena indicando a que nodo servidor real pertenece. Es importante aclarar que debido a las caractersticas 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 pequeas empresas. En el transcurso de las pruebas se observ que existan problemas no previstos en la elaboracin del proyecto como la seguridad que debe mantenerse en los servidores lo cual fue solventado denegando la aceptacin de paquetes y puertos por parte de los nodos servidores. Al final del proyecto se concluye que la solucin desarrollada es aplicable en pequeas empresas tomando en cuenta el correcto funcionamiento, la fcil instalacin y mantenimiento del sistema adems que, por tratarse de open source las empresas no incurre en gastos por licenciamiento.

BIBLIOGRAFIA

2007, Jos Angel de Bustos Prez, 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 Mara Ynez Gmez, Introduccin a las tecnologas de clustering en GNU/Linux, 2005. 30 de diciembre de 2003, Emilio Jos Plaza Nieto, Cluster Heterogneo de computadoras, 30 de diciembre de 2003. Edicin junio 2010, Joel Barrios Dueas, Implementacin 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, Administracin de sistemas Linux, junio 30, 2007, Anaya Multimedia 2005, Charles Bookman, Clustering con Linux, 2005, Pearson Educacin 2007, Jos Angel de Bustos Prez, 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