Está en la página 1de 38

ACSO 2010 Clustering Administracin y Configuracin de Sistemas Operativos

Clustering
Configuracin de clsters y anlisis de productos.

Loxo Lueiro Astray Cstor Snchez Chao

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 1

ACSO 2010 Clustering

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 2

ACSO 2010 Clustering

Tabla de contenido
1 Introduccin........................................................................................................................... 5 1.1 Objetivos del proyecto .................................................................................................... 5 1.2 Trasfondo ........................................................................................................................ 5 1.3 Metodologa.................................................................................................................... 5 2 Estado del Arte....................................................................................................................... 8 2.1 Introduccin al clustering ................................................................................................ 8 2.1.1 Concepto de cluster ................................................................................................. 8 2.2 Tipos de clusters .............................................................................................................. 9 2.2.1 Clusters HPCC (High Performance Computing Cluster): Cluster de Alto Rendimiento 9 2.2.2 Clusters HA (High Availability): Cluster de Alta Disponibilidad ................................. 10 2.3 Paso de Mensajes .......................................................................................................... 11 2.3.1 PVM ....................................................................................................................... 12 2.3.2 MPI......................................................................................................................... 15 2.4 Arquitecturas utilizadas para el proyecto....................................................................... 17 2.4.1 OpenMosix ............................................................................................................. 17 2.4.2 Beowulf .................................................................................................................. 18 3 Descripcin Tcnica.............................................................................................................. 19 3.1 Plataforma hardware..................................................................................................... 19 3.2 Implementacin de cluster OpenMosix ......................................................................... 19 3.2.1 Instalacin de un Kernel con soporte OpenMosix.................................................... 20 3.2.2 Errores ms frecuentes a la hora de compilar e instalar el Kernel............................ 22 3.2.3 Administracin de los nodos ................................................................................... 23 3.2.4 Herramientas de Monitorizacin: OpenMosixView ................................................. 24 3.3 Implementacin de cluster Beowulf .............................................................................. 25 3.3.1 Instalacin y configuracin de PVM ........................................................................ 26 3.3.2 Consola de PVM ..................................................................................................... 28 3.3.3 Entorno grfico XPVM............................................................................................. 30 4 Pruebas Experimentales ....................................................................................................... 33 4.1 Clculo de la multiplicacin de matrices en Beowulf ...................................................... 33 4.1.1 Descripcin ............................................................................................................. 33 4.1.2 Herramientas.......................................................................................................... 33 4.1.3 Ejecucin ................................................................................................................ 33 4.1.4 Resultados .............................................................................................................. 33 Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 3

ACSO 2010 Clustering 4.1.5 Conclusiones .......................................................................................................... 34 4.2 Test de Balanceo de Carga en OpenMosix ..................................................................... 34 4.2.1 Descripcin ............................................................................................................. 34 4.2.2 Herramientas......................................................................................................... 34 4.2.3 Ejecucin ................................................................................................................ 34 4.2.4 Resultados Obtenidos ............................................................................................. 35 4.3 Ejecucin de una compilacin multi-hilo........................................................................ 35 4.3.1 Descripcin ............................................................................................................. 36 4.3.2 Herramientas.......................................................................................................... 36 4.3.3 Ejecucin ................................................................................................................ 36 4.3.4 Resultados Obtenidos ............................................................................................. 37 5. Conclusiones ...................................................................................................................... 38

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 4

ACSO 2010 Clustering

1 Introduccin
1.1 Objetivos del proyecto
En este proyecto se ha definido como objetivo inicial realizar una instalacin, configuracin, y anlisis comparativo de rendimiento de dos arquitecturas de clstering, una de ellas basada en OpenMosix, y la otra correspondiente a un tipo Beowulf. El propsito del proyecto consiste en realizar una introduccin al mbito del clstering, explorando los diferentes tipos, arquitecturas y tecnologas que los soportan, y finalmente escogiendo dos productos (en nuestro caso arquitecturas) para implementar y realizar una serie de pruebas analticas que nos permitan discernir sobre las ventajas/inconvenientes de cada uno de ellos, mbitos de aplicacin con mejor proyeccin para su implementacin, y para terminar, comparar los resultados obtenidos para sacar nuestras propias conclusiones.

1.2 Trasfondo
Como veremos en el apartado siguiente, donde se entrar en ms detalles, una definicin fugaz de clster podra ser un conjunto de ordenadores que se comportan como uno solo. La construccin de los ordenadores del clster es ms fcil y econmica debido a su flexibilidad: pueden tener todos la misma configuracin de hardware y sistema operativo (clster homogneo), diferente rendimiento pero con arquitecturas y sistemas operativos similares (clster semi-homogneo), o tener diferente hardware y sistema operativo (clster heterogneo), lo que hace ms fcil y econmica su construccin. Para que un clster funcione como tal, no basta solo con conectar entre s los ordenadores, sino que es necesario proveer un sistema de manejo del clster, el cual se encargue de interactuar con el usuario y los procesos que corren en l para optimizar el funcionamiento. El clustering es una tcnica muy utilizada en grandes corporaciones y organizaciones que necesitan disponer de una gran capacidad y potencia de clculo, bien para la obtencin de resultados o para la ejecucin de aplicaciones muy costosas computacionalmente. La tecnologa de clustering permite a las organizaciones incrementar su capacidad de procesamiento usando tecnologa estndar, tanto en componentes de hardware como de software que pueden adquirirse a un coste relativamente bajo.

1.3 Metodologa
Para la consecucin de este proyecto, nuestra intencin ser realizar una implementacin de dos arquitecturas de clustering, concretamente OpenMosix y Beowulf. Una vez instaladas y configuradas, el procedimiento inicial que habamos planteado consiste en realizar una serie de pruebas de carga del sistema para obtener datos concretos acerca de su rendimiento, y de esa forma poder establecer segn el comportamiento observado, en qu mbitos es mejor una solucin u otra. Antes de continuar, es necesario realizar explicar brevemente un ajuste realizado entre las pruebas propuestas y las pruebas que finalmente se han realizado. Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 5

ACSO 2010 Clustering En nuestro esquema inicial, proponamos la realizacin de dos pruebas significativas con el fin de establecer una comparativa de rendimiento entre ambos tipos de clsters. En concreto las pruebas que pretendamos realizar eras las siguientes: Integracin de Montecarlo: Ejecutar un programa para clculo de reas basado en la integracin de Monte Carlo, pasando como parmetros variables la funcin a integrar y el nmero de puntos aleatorios. Apache Benchmarking: Configurar un servidor apache sobre los clster y estresarlo utilizando la suite de ApacheBench para estimar en qu tipo de clster se comporta mejor.

Basados en la documentacin previa, nuestras estimaciones eran que para el clster tipo Beowulf se comportaran mejor las aplicaciones que requiriesen una gran potencia de clculo, mientras que en el tipo OpenMosix se comportaran mejor las basadas en balanceo de cargas y servicios. Sin embargo, y debido a razones tcnicas explicadas en los apartados posteriores, durante la realizacin de este trabajo nos hemos visto obligados a variar la naturaleza de las pruebas, y en consecuencia de las conclusiones y datos obtenidos. Dado que los tipos de clster (Beowulf-PVM vs OpenMosix-MPI) estn basados en arquitecturas distintas (PVM vs MPI) y en una filosofa no transparente vs transparente, no tiene sentido realizar las mismas pruebas sobre uno y otro. Esto es as porque, concretamente para el clster Beowulf (no transparente, montado sobre PVM) es necesario manejar las funciones de la propia librera PVM en nuestros programas para conseguir la paralelizacin del cdigo. Por tanto, un cdigo con estas caractersticas no tendra sentido ejecutarlo en un clster que no utilice la librera PVM. De forma anloga, pruebas de balanceo de carga que no utilicen la librera PVM se pueden ejecutar sobre un clster de tipo OpenMosix, que est basado en MPI, y que adems proporciona transparencia al usuario, de forma que es el propio kernel el que distribuye tareas de forma totalmente transparente, sin necesidad de que las aplicaciones estn implcitamente programadas para efectuar llamadas a la librera MPI. Como aadido, destacar la complejidad de re implementar el algoritmo de Integracin de Montecarlo haciendo uso de la librera de paralelizacin PVM. Por ello hemos optado por un ejemplo ms sencillo consistente en la multiplicacin de matrices, que para nuestro caso ilustra perfectamente el objetivo de la prueba que hemos redefinido. Por lo tanto, hemos centrado nuestro trabajo en elaborar una amplia documentacin acerca de los tipos de clster y su configuracin, as como pruebas especficas para cada uno con el objetivo de comprobar su comportamiento, reparto de cargas y consumo de recursos. Por lo tanto las pruebas finales que se han definido para su aplicacin sobre los dos tipos de clusters son las siguientes: Clculo de la multiplicacin de matrices: Esta prueba se ejecutar sobre el clster Beowulf-PVM, dado que el propio cdigo lleva implcitas las llamadas a las funciones de la librera PVM. Es por ello que no tiene sentido ejecutarla sobre OpenMosix, dado que la versin en particular no hace uso de las libreras PVM. El objetivo de la prueba Pgina 6

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

ACSO 2010 Clustering ser comprobar cmo realiza el balanceo de cargas el clster PVM, introduciendo como objeto condicionante el nmero de nodos, as como comprobar la respuesta ante una inusual cada de alguno de los nodos de procesamiento. Prueba de carga de sistema: Esta prueba se ejecutar sobre el clster OpenMosix. Se ejecutar un script en multihilo para estresar el sistema y poder comprobar cmo se realiza el balanceo de cargas en un sistema transparente como OpenMosix, sin necesidad de que la implementacin haga uso explcito de las libreras MPI. Ejecucin de una compilacin multihilo: Esta prueba se ejecutar sobre el clster OpenMosix-MPI. El condicionante variable ser el nmero de nodos. As mismo, comprobaremos el comportamiento del clster ante la inusual cada de alguno de los nodos de procesamiento.

Una vez obtenidos los resultados, y tomando en consideracin la documentacin realizada en los pasos previos acerca del estado del arte, elaboraremos nuestras propias conclusiones.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 7

ACSO 2010 Clustering

2 Estado del Arte


2.1 Introduccin al clustering
El trmino clster se aplica a los conjuntos o conglomerados de computadoras construidos mediante la utilizacin de componentes de hardware comunes y que se comportan como si fuesen una nica computadora. Hoy en da desempean un papel importante en la solucin de problemas de las ciencias, las ingenieras y del comercio moderno. La tecnologa de clusters ha evolucionado en apoyo de actividades que van desde aplicaciones de supercomputacin y software de misiones crticas, servidores Web y comercio electrnico, hasta bases de datos de alto rendimiento, entre otros usos. El cmputo con clusters surge como resultado de la convergencia de varias tendencias actuales que incluyen la disponibilidad de microprocesadores econmicos de alto rendimiento y redes de alta velocidad, el desarrollo de herramientas de software para cmputo distribuido de alto rendimiento, as como la creciente necesidad de potencia computacional para aplicaciones que la requieran. Simplemente, clster es un grupo de mltiples ordenadores unidos mediante una red de alta velocidad, de tal forma que el conjunto es visto como un nico ordenador, ms potente que los comunes de escritorio. Los clusters son usualmente empleados para mejorar el rendimiento y/o la disponibilidad por encima de la que es provista por un solo computador tpicamente siendo ms econmico que computadores individuales de rapidez y disponibilidad comparables. La construccin de los ordenadores del clster es ms fcil y econmica debido a su flexibilidad: pueden tener todos la misma configuracin de hardware y sistema operativo (clster homogneo), diferente hardware pero con arquitecturas y sistemas operativos similares (clster semi-homogneo), o tener diferente hardware y sistema operativo (clster heterogneo), lo que hace ms fcil y econmica su construccin. Para que un clster funcione como tal, no basta solo con conectar entre s los ordenadores, sino que es necesario proveer un sistema de manejo del clster, el cual se encargue de interactuar con el usuario y los procesos que corren en l para optimizar el funcionamiento. 2.1.1 Concepto de clster Aunque parezca sencillo de definir no lo es en absoluto. Podra incluirse alguna definicin de algn libro, pero el problema es que ni los expertos en clusters ni la gente que los implementa se ponen de acuerdo en qu es aquello en lo que trabajan. Un clster se puede entender como un conjunto de mquinas unidas por una red de comunicacin trabajando por un servicio conjunto. Segn el servicio puede ser dar alta disponibilidad, alto rendimiento, etc. Hay definiciones que distinguen entre clster de mquinas SMP y clusters formados por nodos monoprocesadores. Hay arquitecturas clusters que se denominan constelaciones y se caracterizan por que cada nodo contiene ms procesadores que el nmero de nodos. A pesar de todo, las constelaciones siguen siendo clusters de componentes o nodos aventajados y Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 8

ACSO 2010 Clustering caros. De hecho entre las mquinas que aparecen en el top500 existen unos pocos clusters que pertenecen a organizaciones que no son gigantes de la informtica, lo cual indica el precio que pueden llegar a tener estos sistemas. A continuacin se refleja un repertorio de diferentes definiciones de clster que se han encontrado: Un clster consiste en un conjunto de mquinas y un servidor de clster dedicado, para realizar los relativamente infrecuentes accesos a los recursos de otros procesos, se accede al servidor de clster de cada grupo del libro Operating System Concepts de Silberschatz Galvin. Un clster es la variacin de bajo precio de un multiprocesador masivamente paralelo (miles de procesadores, memoria distribuida, red de baja latencia), con las siguientes diferencias: cada nodo es una mquina quizs sin algo del hardware (monitor, teclado, mouse, etc.), el nodo podra ser SMP. Los nodos se conectan por una red de bajo precio como Ethernet o ATM aunque en clusters comerciales se pueden usar tecnologas de red propias. El interfaz de red no est muy acoplado al bus I/O. Todos los nodos tienen disco local. Cada nodo tiene un sistema operativo UNIX con una capa de software para soportar todas las caractersticas del clster del libro Scalable Parallel Computing de Kai Hwang y Khiwei Xu. Es una clase de arquitectura de computador paralelo que se basa en unir mquinas independientes cooperativas integradas por medio de redes de interconexin para proveer un sistema coordinado, capaz de procesar una carga del autor Dr. Thomas Sterling.

2.2 Tipos de clusters


2.2.1 Clusters HPCC (High Performance Computing Cluster): Cluster de Alto Rendimiento Un clster de alto rendimiento es un conjunto de ordenadores que est diseado para dar altas prestaciones en cuanto a capacidad de clculo. Los motivos para utilizar un clster de alto rendimiento son: El tamao del problema por resolver El precio de la mquina necesaria para resolverlo.

Por medio de un clster se pueden conseguir capacidades de clculo superiores a las de un ordenador ms caro que el costo conjunto de los ordenadores del clster. Para garantizar esta capacidad de clculo, los problemas necesitan ser paralelizables, ya que el mtodo con el que los clusters agilizan el procesamiento es dividir el problema en problemas ms pequeos y calcularlos en los nodos, por lo tanto, si el problema no cumple con esta caracterstica, no puede utilizarse el clster para su clculo. Se hacen distinciones entre los que se implementan a nivel de sistema operativo y los que se implementan a nivel de libreras. El objetivo de este tipo de clusters es, como su propio nombre indica mejorar el rendimiento en la obtencin de la solucin de un problema, en trminos bien del tiempo de respuesta bien de su precisin. Dentro de esta definicin no se engloba restriccin concreta. Esto supone que cualquier clster que haga que el rendimiento del sistema aumente respecto al de uno de los nodos individuales

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 9

ACSO 2010 Clustering puede ser considerado clster HP. Generalmente estos problemas de cmputo suelen estar ligados a: Clculos matemticos Renderizaciones 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)

Existen otros muchos problemas ms que se pueden solucionar con clusters HP, donde cada uno aplica de una manera u otra las tcnicas necesarias para habilitar la paralelizacin del problema, su distribucin entre los nodos y obtencin del resultado. Las tcnicas utilizadas dependen de a qu nivel trabaje el clster. Los clusters implementados a nivel de aplicacin no suelen implementar balanceo de carga. Suelen basar todo su funcionamiento en una poltica de localizacin que sita las tareas en los diferentes nodos del clster, y las comunica mediante las libreras abstractas. Resuelven problemas de cualquier tipo de los que se han visto en el apartado anterior, pero se deben disear y codificar aplicaciones propias para cada tipo para poderlas utilizar en estos clusters. Por otro lado estn los sistemas de alto rendimiento implementados a nivel de sistema. Estos clusters basan todo su funcionamiento en comunicacin y colaboracin de los nodos a nivel de sistema operativo, lo que implica generalmente que son clusters de nodos de la misma arquitectura, con ventajas en lo que se refiere al factor de acoplamiento, y que basan su funcionamiento en la comparticin de recursos a cualquier nivel, balanceo de la carga de manera dinmica, funciones de planificacin especiales y otros tantos factores que componen el sistema. Se intentan acercar a sistemas SSI, el problema est en que para obtener un sistema SSI hay que ceder en el apartado de compatibilidad con los sistemas actuales, por lo cual se suele llegar a un factor de compromiso. 2.2.2 Clusters HA (High Availability): Cluster de Alta Disponibilidad Son otro tipo de clusters completamente distintos a los anteriores. Son los ms solicitados por las empresas ya que estn destinados a mejorar los servicios que stas ofrecen cara a los clientes en las redes a las que pertenecen, tanto en redes locales como en redes como Internet. Los clusters de alta disponibilidad han sido diseados para la mxima disponibilidad sobre los servicios que presenta el clster. Este tipo de clusters son la competencia que abarata los sistemas redundantes, de manera que ofrecen una serie de servicios durante el mayor tiempo posible. Para poder dar estos servicios los clusters de este tipo se implementan en base a tres factores. Alta disponibilidad de infraestructura: Si se produce un fallo de hardware en alguna de las mquinas del clster, el software de alta disponibilidad es capaz de arrancar automticamente los servicios en cualquiera de las otras mquinas del Pgina 10

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

ACSO 2010 Clustering clster (failover). Y cuando la mquina que ha fallado se recupera, los servicios son nuevamente migrados a la mquina original (failback). Esta capacidad de recuperacin automtica de servicios nos garantiza la alta disponibilidad de los servicios ofrecidos por el clster, minimizando as la percepcin del fallo por parte de los usuarios. Alta disponibilidad de aplicacin: Si se produce un fallo del hardware o de las aplicaciones de alguna de las mquinas del clster, el software de alta disponibilidad es capaz de arrancar automticamente los servicios que han fallado en cualquiera de las otras mquinas del clster. Y cuando la mquina que ha fallado se recupera, los servicios son nuevamente migrados a la mquina original. Esta capacidad de recuperacin automtica de servicios nos garantiza la integridad de la informacin, ya que no hay prdida de datos, y adems evita molestias a los usuarios, que no tienen por qu notar que se ha producido un problema.

La mayora de estos problemas estn ligados a la necesidad de dar servicio continuado de cualquier tipo a una serie de clientes de manera ininterrumpida. En una construccin real se suelen producir fallos inesperados en las mquinas, estos fallos provocan la aparicin de dos eventos en el tiempo: el tiempo en el que el servicio est inactivo y el tiempo de reparacin del problema. Entre los problemas que solucionan se encuentran: 1. Sistemas de informacin redundante 2. Sistemas tolerantes a fallos 3. Balanceo de carga entre varios servidores 4. Balanceo de conexiones entre varios servidores En general todos estos problemas se ligan en dos fuentes de necesidad de las empresas u organizaciones; Tener un servicio disponible y ahorrar econmicamente todo lo que sea posible. El servicio puede ser diverso. Desde un sistema de ficheros distribuidos de carcter muy barato, hasta grandes clusters de balanceo de carga y conexiones para los grandes portales de Internet. Cualquier funcionalidad requerida en un entorno de red puede ser colocada en un clster e implementar mecanismos para hacer que esta obtenga la mayor disponibilidad posible. Se suelen proponer sistemas desde SSI que plantean serias dudas en lo que se refiere a localizacin de un servidor, hasta balanceo de carga o de conexiones. Tambin suelen contener secciones de cdigo que realizan monitorizacin de carga o monitorizacin de servicios para activar las acciones necesarias para cuando estos caigan. Se basan en principios muy simples que pueden ser desarrollados hasta crear sistemas complejos especializados para cada entorno particular. En cualquier caso, las tcnicas de estos sistemas suelen basarse en excluir del sistema aquellos puntos crticos que pueden producir un fallo y por tanto la prdida de disponibilidad de un servicio. Para esto se suelen implementar desde enlaces de red redundantes hasta disponer de N mquinas para hacer una misma tarea de manera que si caen N-1 mquinas el servicio permanece activo sin prdida de rendimiento.

2.3 Paso de Mensajes


Para conseguir que las tareas se ejecuten de manera colaborativa y de forma sincronizada se Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 11

ACSO 2010 Clustering utiliza el concepto de paso de mensajes. Los mensajes son pasados entre los procesos de forma ms o menos efectiva en un clster. Se pueden enviar en forma de paquete IP y el ordenador destino desempaqueta el mensaje y decide a que proceso va dirigido. Una vez hecho esto, enva la informacin al proceso en cuestin. Existen varias libreras que implementan el paso de mensajes para la implementacin de computacin distribuida, sobre las que se montan los sistemas de clustering. Las ms conocidas son MPI y PVM. En MPI, en particular, se necesita conocer de forma bsica los mecanismos de paso de mensajes. Hay tres mecanismos bsicos de paso de mensajes: 1. Paso de mensajes sncrono: cuando un proceso P ejecuta un envo sncrono a un proceso Q, tiene que esperar hasta que el proceso Q ejecuta el correspondiente recibo de informacin sncrono. Ambos procesos no volvern del envo o el recibo hasta que el mensaje est a la vez enviado y recibido. Cuando el enviar y recibir acaban, el mensaje original puede ser inmediatamente sobrescrito por el nuevo mensaje de vuelta y ste puede ser inmediatamente ledo por el proceso que envi originariamente el mensaje. No se necesita un buffer extra en el mismo buffer donde se encuentra el mensaje de ida, se escribe el mensaje de vuelta. 2. Enviar/Recibir bloqueante: un envo bloqueante es ejecutado cuando un proceso lo alcanza sin esperar el recibo correspondiente. Esta llamada bloquea hasta que el mensaje es efectivamente enviado, lo que significa que el mensaje (el buffer donde se encuentra el mensaje) puede ser reescrito sin problemas. Cuando la operacin de enviar ha acabado no es necesario que se haya ejecutado una operacin de recibir. Slo sabemos que el mensaje fue enviado, puede haber sido recibido o puede estar en un buffer del nodo que lo enva, o en un buffer de algn lugar de la red de comunicaciones o puede que est en el buffer del nodo receptor. Un recibo bloqueante es ejecutado cuando un proceso lo alcanza, sin esperar a su correspondiente envo. Sin embargo no puede acabar sin recibir un mensaje. Quizs el sistema est proveyendo un buffer temporal para los mensajes. 3. Envo/recibo no bloqueante: un envo no bloqueante es ejecutado cuando un proceso lo alcanza, sin esperar al recibo. Puede acabar inmediatamente tras notificar al sistema que debe enviar el mensaje. Los datos del mensaje no estn necesariamente fuera del buffer del mensaje, por lo que es posible incurrir en error si se sobrescriben los datos. Un recibo no bloqueante es ejecutado cuando un proceso lo alcanza, sin esperar el envo. Puede volver inmediatamente tras notificar al sistema que hay un mensaje que se debe recibir. El mensaje puede que no haya llegado an, puede estar todava en trnsito o puede no haber sido enviado an. 2.3.1 PVM PVM es un conjunto de herramientas y libreras que emulan un entorno de propsito general compuesto de nodos interconectados de distintas arquitecturas. El objetivo es conseguir que ese conjunto de nodos pueda ser usado de forma colaborativa para el procesamiento paralelo. El modelo en el que se basa PVM es dividir las aplicaciones en distintas tareas (igual que ocurre con openMosix). Son los procesos los que se dividen por las mquinas para aprovechar todos los recursos. Cada tarea es responsable de una parte de la carga que conlleva esa aplicacin. PVM soporta tanto paralelismo en datos, como funcional o una mezcla de ambos. PVM permite que las tareas se comuniquen y sincronicen con las dems tareas de la mquina virtual, enviando y recibiendo mensajes, muchas tareas de una aplicacin pueden cooperar

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 12

ACSO 2010 Clustering para resolver un problema en paralelo. Cada tarea puede enviar un mensaje a cualquiera de las otras tareas, sin lmite de tamao ni de nmero de mensajes. El sistema PVM se compone de dos partes. La primera es un demonio, llamado pvmd que residen en todas los nodos que forman parte de la mquina virtual. Cuando un usuario quiere ejecutar una aplicacin PVM, primero crea una mquina virtual para arrancar PVM. Entonces se puede ejecutar la aplicacin PVM en cualquiera de los nodos. Muchos usuarios pueden configurar varias mquinas virtuales aunque se mezclen unas con las otras y se pueden ejecutar varias aplicaciones PVM simultneamente. Cada demonio es responsable de todas las aplicaciones que se ejecutan en su nodo. As, el control est totalmente distribuido excepto por un demonio maestro, que es el primero que se ejecuto a mano por el usuario, los dems nodos fueron iniciados por el maestro y son esclavos. En todo momento siempre hay un pvmd maestro. Por tanto la mquina virtual mnima es de un miembro, el maestro. La segunda parte del sistema es la librera de PVM. Contiene un repertorio de primitivas que son necesarias para la cooperacin entre los procesos o threads de una aplicacin. Esta librera contiene rutinas para inicializacin y terminacin de tareas, envo y recepcin de mensajes, coordinar y sincronizar tareas, broadcast, modificar la mquina virtual. Cuando un usuario define un conjunto de nodos, PVM abstrae toda la complejidad que tenga el sistema y toda esa complejidad se ve como un gran computador de memoria distribuida llamada mquina virtual. Esta mquina virtual es creada por el usuario cuando se comienza la operacin. Es un conjunto de nodos elegidos por el usuario. En cualquier momento durante la operacin puede elegir nuevos nodos para la mquina virtual. Esto puede ser de gran ayuda para mejorar la tolerancia a fallos pues se tiene unos cuantos nodos de reserva (PVM no tiene migracin) para si alguno de los nodos fallara. O si se ve que un conjunto de nodos de una determinada red estn fallando se pueden habilitar nodos de otra red para solucionarlo. Para conseguir abstraer toda la complejidad de las diferentes configuraciones, soporta la heterogeneidad de un sistema a tres niveles: Aplicaciones: las subtareas pueden estar hechas para aprovechar las arquitecturas sobre la que funcionan. Por tanto como se puede elegir en que conjunto de nodos se ejecutarn unas tareas especficas, podemos hacer nuestras aplicaciones con la arquitectura al mximo por lo que se puede optimizar y hacer que funcionen aplicaciones hechas para arquitecturas especficas con PVM. Mquinas: nodos con distintos formatos de datos estn soportados, incluyendo arquitecturas secuenciales, vectoriales, SMP. Abstrae little endian y big endian. Redes: la mquina virtual puede ser interconectada gracias a distintas tecnologas de red. Para PVM, bajo l existe una red punto a punto, no fiable y no secuencial. Esto abstrae cualquier tecnologa de red. Utiliza UDP e implementa toda la confiabilidad y todas las dems operaciones como broadcast en la propia librera PVM. Cuando una tarea se quiere comunicar con otra ocurren una serie de cosas, los datos que la tarea ha enviado con una operacin send, son transferidos a su demonio local quien decodifica Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 13

ACSO 2010 Clustering el nodo de destino y transfiere los datos al demonio destino. Este demonio decodifica la tarea destino y le entrega los datos. Este protocolo necesita 3 transferencias de datos de las cuales solamente una es sobre la red. Tambin se puede elegir una poltica de encaminado directo (dependiente de los recursos disponibles). En esta poltica tras la primera comunicacin entre dos tareas los datos sobre el camino a seguir por los datos son guardados en una cach local. Las siguientes llamadas son hechas directamente gracias a esta informacin. De esta manera las transferencias se reducen a una transferencia sobre la red. Para comunicar entre s los demonios pvmd se usa UDP pues es mucho ms sencillo, slo consume un descriptor de fichero, y con un simple socket UDP se puede comunicar a todos los dems demonios. Adems es muy sencillo colocar temporizadores sobre UDP para detectar fallos de nodo, pvmd o red. La comunicacin entre las tareas y los pvmd es mediante TCP puesto que se necesita tener la seguridad de que los datos llegarn. En el caso de que slo se haga una trasferencia sta es TCP por lo que hay que establecer la conexin primero por lo que realmente tampoco es tan beneficioso. En la siguiente figura se puede observar como los distintos mtodos de comunicacin de PVM.

Ilustracin 1: Comunicaciones en PVM


Cada nodo tiene una estructura llamada host table. Esta tabla tiene una entrada (host descriptor) por cada nodo de la mquina virtual. El descriptor del nodo mantiene la informacin de la configuracin del host, las colas de paquetes y los buffer de mensajes. Inicialmente la tabla slo tiene la entrada del nodo maestro. Cuando un nuevo esclavo es incluido a la mquina virtual, la tabla del nodo maestro es actualizada para aadir al nuevo esclavo. Entonces esta nueva informacin es enviada por broadcast a todos los nodos que pertenezcan a la mquina virtual. De esta manera se actualizan todas las tablas y se mantienen consistentes. Las aplicaciones pueden ver el hardware como una coleccin de elementos de proceso virtuales sin atributos o pueden intentar explotar las capacidades de mquinas especficas, intentando posicionar ciertas tareas en los nodos ms apropiados para ejecutarlas.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 14

ACSO 2010 Clustering PVM no tiene requisa de procesos dinmico, esto quiere decir que una vez que un proceso empieza en una determinada mquina seguir en ella hasta que se muera. Esto tiene graves inconvenientes, puesto que hay que tener en cuenta que las cargas suelen variar y que, a no ser que todos los procesos que se estn ejecutando sean muy homogneos entre s, se est descompensando el clster. Por lo tanto tenemos unos nodos ms cargados que otros y seguramente unos nodos terminen su ejecucin antes que otros, con lo que se podran tener nodos muy cargados mientras otros nodos estn libres. Esto lleva a una prdida de rendimiento general. Otro problema de PVM es que est implementado a nivel de usuario, esto no es malo de por s pero teniendo en cuenta el tipo de operaciones que lleva s lo es, puesto que son operaciones de bastante bajo nivel como puedan ser paso de mensajes entre aplicaciones y la capa sobre UDP. Esto aade complejidad y latencia a las comunicaciones que se tienen que producir sobre las comunicaciones del kernel. Por lo que es una capa de software extra que carga bastante. Se necesita un conocimiento amplio del sistema, tanto los programadores como los administradores tienen que conocer el sistema para sacar el mximo rendimiento de l. No existe un programa que se ejecute de forma ideal en cualquier arquitectura ni configuracin de clster. Por lo tanto para paralelizar correcta y eficazmente se necesita que los programadores y administradores conozcan a fondo el sistema. El paralelismo es explcito, esto quiere decir que se programa de forma especial para poder usar las caractersticas especiales de PVM. Los programas deben ser reescritos. Si a esto se une que, como se necesita que los desarrolladores estn bien formados, se puede decir que migrar una aplicacin a un sistema PVM no es nada econmico. 2.3.2 MPI MPI ("Message Passing Interface", Interfaz de Paso de Mensajes) es un estndar que define la sintaxis y la semntica de las funciones contenidas en una biblioteca de paso de mensajes diseada para ser usada en programas que exploten la existencia de mltiples procesadores. Su principal caracterstica es que no precisa de memoria compartida, por lo que es muy importante en la programacin de sistemas distribuidos. La Interfaz de Paso de Mensajes (conocido ampliamente como MPI, siglas en ingls de Message Passing Interface) es un protocolo de comunicacin entre computadoras. Es el estndar para la comunicacin entre los nodos que ejecutan un programa en un sistema de memoria distribuida. Las implementaciones en MPI consisten en un conjunto de bibliotecas de rutinas que pueden ser utilizadas en programas escritos en los lenguajes de programacin C, C++, Fortran y Ada. La ventaja de MPI sobre otras bibliotecas de paso de mensajes, es que los programas que utilizan la biblioteca son portables (dado que MPI ha sido implementado para casi toda arquitectura de memoria distribuida), y rpidos, (porque cada implementacin de la biblioteca ha sido optimizada para el hardware en la cual se ejecuta). 2.3.2.1 Fundamentos de MPI MPI es una especificacin estndar para una librera de funciones de paso de mensajes. MPI fue desarrollado por el MPI Forum, un consorcio de vendedores de ordenadores paralelos, Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 15

ACSO 2010 Clustering escritores de libreras y especialistas en aplicaciones. Consigue portabilidad proveyendo una librera de paso de mensajes estndar independiente de la plataforma y de dominio pblico. La especificacin de esta librera est en una forma independiente del lenguaje y proporciona funciones para ser usadas con C y Fortran. Abstrae los sistemas operativos y el hardware. Hay implementaciones MPI en casi todas las mquinas y sistemas operativos. Esto significa que un programa paralelo escrito en C o Fortran usando MPI para el paso de mensajes, puede funcionar sin cambios en una gran variedad de hardware y sistemas operativos. Por estas razones MPI ha ganado gran aceptacin dentro el mundillo de la computacin paralela. MPI tiene que ser implementado sobre un entorno que se preocupe del manejo de los procesos y la E/S por ejemplo, puesto que MPI slo se ocupa de la capa de comunicacin por paso de mensajes. Necesita un ambiente de programacin paralelo nativo. Con MPI el nmero de procesos requeridos se asigna antes de la ejecucin del programa, y no se crean procesos adicionales mientras la aplicacin se ejecuta. A cada proceso se le asigna una variable que se denomina rank, la cual identifica a cada proceso, en el rango de 0 a p-1, donde p es el nmero total de procesos. El control de la ejecucin del programa se realiza mediante la variable rank; la variable rank permite determinar qu proceso ejecuta determinada porcin de cdigo. En MPI se define un comunicator como una coleccin de procesos, los cuales pueden enviar mensajes el uno al otro; el comunicator bsico se denomina MPI_COMM_WORLD y se define mediante un macro del lenguaje C. MPI_COMM_WORLD agrupa a todos los procesos activos durante la ejecucin de una aplicacin. Las llamadas de MPI se dividen en cuatro clases: Llamadas utilizadas para inicializar, administrar y finalizar comunicaciones. Llamadas utilizadas para transferir datos entre un par de procesos. Llamadas para transferir datos entre varios procesos. Llamadas utilizadas para crear tipos de datos definidos por el usuario.

La primera clase de llamadas permiten inicializar la biblioteca de paso de mensajes, identificar el nmero de procesos (size) y el rango de los procesos (rank). La segunda clase de llamadas incluye operaciones de comunicacin punto a punto, para diferentes tipos de actividades de envo y recepcin. La tercera clase de llamadas son conocidas como operaciones grupales, que proveen operaciones de comunicaciones entre grupos de procesos. La ltima clase de llamadas provee flexibilidad en la construccin de estructuras de datos complejos. En MPI, un mensaje est conformado por el cuerpo del mensaje, el cual contiene los datos a ser enviados, y su envoltura, que indica el proceso fuente y el destino. El cuerpo del mensaje en MPI se conforma por tres piezas de informacin: buffer, tipo de dato y count. El buffer, es la localidad de memoria donde se encuentran los datos de salida o donde se almacenan los datos de entrada. El tipo de dato, indica el tipo de los datos que se envan en el mensaje. En casos simples, ste es un tipo bsico o primitivo, por ejemplo, un nmero entero, y que en aplicaciones ms avanzadas puede ser un tipo de dato construido a travs de datos primitivos. Los tipos de datos derivados son anlogos a las estructuras de C.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 16

ACSO 2010 Clustering El count es un nmero de secuencia que junto al tipo de datos permiten al usuario agrupar tems de datos de un mismo tipo en un solo mensaje. MPI estandariza los tipos de datos primitivos, evitando que el programador se preocupe de las diferencias que existen entre ellos, cuando se encuentran en distintas plataformas. La envoltura de un mensaje en MPI tpicamente contiene la direccin destino, la direccin de la fuente, y cualquier otra informacin que se necesite para transmitir y entregar el mensaje. La envoltura de un mensaje en MPI, consta de cuatro partes: la fuente, el destino, el comunicator y una etiqueta. La fuente identifica al proceso transmisor. El destino identifica al proceso receptor. El comunicator especifica el grupo de procesos a los cuales pertenecen la fuente y el destino. La etiqueta (tag) permite clasificar el mensaje. El campo etiqueta es un entero definido por el usuario que puede ser utilizado para distinguir los mensajes que recibe un proceso.

2.4 Arquitecturas utilizadas para el proyecto


2.4.1 OpenMosix OpenMosix es un parche para el Kernel de Linux que dota en la mquina en la que se corre de la capacidad de trabajar como un nodo del clster. Su misin es convertir una red de ordenadores en un clster. El algoritmo interno de balanceo de carga se ocupa de migrar automticamente y de forma transparente al usuario los procesos entre los dems nodos del clster, lo cual proporciona una comparticin ptima de la carga entre los distintos nodos. Esta migracin se realiza de acuerdo a la velocidad de CPU de cada nodo, a su carga de procesos actual y a la conexin de red que lo une a los dems nodos, ya que aunque todos deben utilizar el protocolo TCP/IP para comunicarse entre ellos, no todos tienen que estar conectados en la misma subred, ni utilizar los mismos medios fsicos de unin (ethernet, PPP, etc...). OpenMosix tambin permite al administrador del clster puede realizar la migracin de procesos de forma manual gracias a las herramientas que de software que acompaas al clster (Userland tools o Userspace tools). Asimismo, los nodos pueden aadirse o quitarse de la red sin que los procesos en ejecucin se vean afectados. Debido a que OpenMosix forma parte del kernel, ya que se aade al cdigo fuente de ste antes de compilarlo, es totalmente compatible con Linux, sus programas y sus ficheros. No es posible distinguir entre una mquina normal y corriente ejecutando Linux y una mquina utilizando Linux como nodo de un clster OpenMosix. El sistema de migracin de procesos hace trabajar al conjunto de nodos como un enorme sistema de procesadores (o multiprocesadores en el caso de que se trate de cores procesadores dual o quad en cada mquina). OpenMosix utiliza un sistema de ficheros llamado oMFS (OpenMosix File System) que, al contrario que el sistema de ficheros NFS, proporciona cache, "time stamp" y consistencia de enlace.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 17

ACSO 2010 Clustering 2.4.2 Beowulf Existen tantas definiciones de Beowulf as como personas que han construido o usado supercomputadores Beowulf. Algunos autores afirman que se debe llamar Beowulf slo aquellos computadores construidos de la misma forma que el computador original de la NASA. Otros autores, un tanto extremistas, llaman Beowulf a cualquier sistema de computadores que ejecute cdigo paralelo. Sin embargo, hay autores que coinciden con la siguiente definicin: Beowulf es una arquitectura conformada por mltiples computadores que puede usarse para computacin paralela. En 1994 bajo el patrocinio del Proyecto de la Tierra y Ciencias del Espacio (ESS Earth and Space Sciences) del Centro de Excelencia en Datos del Espacio y Ciencias de la Informacin (CESDIS - Center of Excellence in Space Data and Information Sciences), Thomas Sterling y Don Becker crearon el primer clster Beowulf con fines de investigacin. Thomas Sterling nombr Beowulf al proyecto en honor al hroe de un cuento ingls, quien liber a Danes of Heorot del monstruo opresivo Grendel. A manera de metfora, se nombr Beowulf a esta nueva estrategia en computacin de alto rendimiento que hace uso de tecnologa bien difundida en el mercado, para derrotar a los costos opresores en tiempo y dinero de la supercomputacin. Un sistema Beowulf usualmente consiste de un nodo servidor (maestro) y uno o ms nodos clientes (esclavos), interconectados a travs de una red Ethernet u otro tipo de red. Un clster Beowulf se construye usando componentes de hardware y de software bien conocidos (commodities). Para establecer las diferencias entre los distintos tipos de sistemas Beowulf, se presenta la siguiente clasificacin: Clase I. Son sistemas compuestos por computadores cuyos componentes cumplen con la prueba de certificacin Computer Shopper, lo que significa que sus elementos son de uso comn, y pueden ser adquiridos muy fcilmente en cualquier tienda distribuidora. Clase II. Son sistemas compuestos por computadores cuyos componentes no pasan la prueba de certificacin Computer Shopper, lo que significa que sus componentes no son de uso comn y por tanto no pueden encontrarse con la misma facilidad que los componentes de sistemas de la clase anterior. Los equipos ubicados en esta categora pueden presentar un nivel de prestaciones superior al de la Clase I. Por lo general, los clusters Beowulf se basan en hardware bien conocido, con una infraestructura de software de cdigo abierto (Linux). Los nodos que conforman el clster se encuentran dedicados nicamente a tareas del clster. Los programas estn escritos en C o en Fortran, utilizando libreras de paso de mensajes para realizar operaciones paralelas.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 18

ACSO 2010 Clustering

3 Descripcin Tcnica
Una vez finalizada la introduccin al mbito, describiendo con detalle las bases conceptuales y tecnolgicas sobre las que se asienta este trabajo, en este apartado se desglosaran los aspectos tcnicos relativos a la implementacin y configuracin de las dos arquitecturas de clstering que se han implementado.

3.1 Plataforma hardware


La plataforma hardware fsica sobre la que se han implementado los dos tipos de clster consta de cuatro mquinas con las siguientes especificaciones: Hostname Nodo1 Nodo2 Pollux Loxo-mach Modelo Clnico Dell Optiplex 330 Dell Optiplex 330 Clnico Modelo Procesador Intel Pentium IV Intel Core 2Duo E4500 Intel Core 2Duo E4500 Intel Pentium D Cores 1 2 2 2 Frecuencia 3.0 Ghz 2.2 Ghz 2.2 Ghz 3.0 Ghz RAM 2 GB 3 GB 3 GB 2 GB

Las mquinas estn integradas en una red LAN que sigue las especificaciones IEEE 802.3, a una velocidad de 100Mbbs.

3.2 Implementacin de clster OpenMosix


Dado que el proyecto OpenMosix est actualmente cerrado, nos hemos visto obligados a implementar la instalacin de un clster de este tipo utilizando software un poco antiguo. Concretamente las versiones de utilizadas han sido: Linux Debian 3.0 con un Kernel 2.4 Parche OpenMosix 2.4.20

Este hecho ha condicionado tambin el desarrollo tanto de las pruebas como de las configuraciones finales, dado que en muchas ocasiones no pudimos conseguir el soporte adecuado para partes del software. Debido a la gran dificultad que hemos encontrado para configurar correctamente esta distribucin en mquinas heterogneas, se ha optado por realizar una instalacin sobre una mquina virtual y replicarla sobre diferentes equipos La construccin de un clster openMosix se compone de varios pasos. El primero es compilar e instalar un kernel con soporte openMosix. El segundo, compilar e instalar las herramientas de rea de usuario. El tercer paso es configurar los demonios del sistema para que cada mquina del clster siga el comportamiento que esperamos. El cuarto paso es crear el fichero del mapa del clster. Este cuarto paso slo es necesario si no usamos la herramienta de autodeteccin de nodos.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 19

ACSO 2010 Clustering 3.2.1 Instalacin de un Kernel con soporte OpenMosix. El primer paso para instalar el kernel de openMosix es descargar el tarball. Es posible descargarse el tarball del parche del kernel de OpenMosix en SourceForge. Una vez descargado el parche, hay que descomprimirlo: # gunzip openMosix-2.4.20-2.gz Despus de descargar el parche openMosix, habr que descargar el kernel de Linux. (http://www.kernel.org). Hay que descargar el kernel correspondiente a la versin del parche que hemos descargado. Esto quiere decir que un parche 2.4.X-Y valdr para el kernel 2.4.X. Por ejemplo, el parche 2.4.20-2 slo puede ser aplicado sobre el kernel 2.4.20. Una vez descargado el kernel de Linux lo descomprimimos, y por comodidad, lo movemos al directorio linux-openmosix, y a continuacin aplicamos el parche de OpenMosix: # tar -zxf linux-2.4.20.tar.gz # mv linux-2.4.20 linux-openmosix # patch -p0 < openMosix-2.4.20-2 Una vez hecho esto, entramos en el directorio linux-openmosix y lanzamos el men de configuracin del kernel. # cd linux-openmosix # make menuconfig Para la configuracin a travs de X-Windows se puede ejecutar el comando make xconfig.

3.2.1.1 Parmetros de configuracin del Kernel El siguiente paso para configurar el kernel de openMosix es entrar en la opcin openMosix -la primera opcin del men principal de la pantalla de configuracin del kernel. All encontraremos un men con todas las opciones propias de openMosix. Estas opciones son: openMosix process migration support: Esta opcin permite activar el soporte a la migracin de procesos en openMosix. Esto incluye tanto la migracin forzada por el administrador como la migracin transparente automtica de procesos, el algoritmo de equilibrado de carga y el Memory Ushering. Si no activamos esta opcin, no tenemos openMosix. Support clusters with a complex network topology: Las mquinas que pertenecen al clster openMosix pueden pertenecer a la misma red IP, estando conectadas por un hub o por un switch. En este caso, openMosix considera que la topologa de la red es simple, lo que permite realizar algunas modificaciones en los algoritmos de clculo de la funcin de coste del algoritmo, y de equilibrado de carga que hacen muchsimo ms eficiente su clculo. Tambin mejora la eficiencia del algoritmo de colecta automtica de informacin del clster. Si tenemos todas las mquinas del clster conectadas a Pgina 20

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

ACSO 2010 Clustering travs de hubs o switchs -es decir, que un paquete openMosix nunca necesitar pasar por un router- se puede aumentar sensiblemente el rendimiento de nuestro clster desactivando esta opcin. Maximum network-topology complexity to support (2-10): Si se activa la opcin anterior, aparecer esta opcin. En esta opcin se pregunta cuantos niveles de complejidad hay entre las dos mquinas ms lejanas del clster, entendiendo por niveles de complejidad el nmero de routers intermedios ms uno. Si se pone un nmero ms alto de la cuenta, no tendremos todo el rendimiento que se podra tener en nuestro clster. Si se pone un nmero ms bajo de la cuenta, no podrn verse entre s las mquinas que tengan ms routers intermedios que los indicados en este par metro menos uno. Stricter security on openMosix ports: Esta opcin permite una comprobacin adicional sobre los paquetes recibidos en el puerto de openMosix, y unas comprobaciones adicionales del remitente. Aunque esto suponga una pequea prdida de rendimiento, permite evitar que mediante el envo de paquetes quebrantados se pueda colgar un nodo del clster. De hecho, hasta hace poco tiempo se poda colgar un nodo del antiguo proyecto Mosix slo hacindole un escaneo de puertos UDP. Salvo que tengamos mucha seguridad en lo que estamos haciendo, debemos activar esta opcin de compilacin. Level of process-identity disclosure (0-3): Este parmetro indica la informacin que va a tener el nodo de ejecucin real de la tarea sobre el proceso remoto que est ejecutando. Aqu se debe destacar que esta informacin siempre estar disponible en el nodo raz ( nodo en el que se origin la tarea). Este es un parmetro de compromiso: valores ms bajos aseguran mayor privacidad, a cambio de complicar la administracin. Valores ms altos hacen ms cmoda la administracin del clster y su uso, pero en algunos escenarios pueden violar la poltica de privacidad del departamento o de la empresa. o Un 0 significa que el nodo remoto que ejecuta el proceso migrado no tiene ninguna informacin relativa al proceso migrado que se ejecuta en dicho nodo. o Un 1 significa que el nodo remoto que ejecuta el proceso migrado tiene como nica informacin el PID del proceso. o Un 2 significa que el nodo remoto que ejecuta el proceso migrado conoce PID, el usuario propietario y el grupo propietario del proceso. o Un 3 significa que en el nodo remoto que ejecuta el proceso migrado se tiene exactamente la misma informacin de los procesos migrados que de los procesos locales. Esto significa que para la informacin de los procesos el sistema se comporta realmente como un sistema SSI. Create the kernel with a -openmosix extension: Si se activa esta opcin, el nombre simblico del kernel llevar la extensin -openmosix. Esto es importante a la hora de buscar y enlazar los mdulos. Se Debe activar esta opcin si, teniendo la misma versin de kernel base y de kernel para openMosix, se quiere que los mdulos del kernel openMosix y los mdulos del kernel antiguo no sean compartidos. openMosix File-System: Si se activa esta opcin podremos usar el sistema de ficheros oMFS, por lo que debemos activar esta opcin slo si vamos a usar el oMFS. Pgina 21

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

ACSO 2010 Clustering Poll/Select exceptions on pipes: Esta opcin es interesante, aunque separa a openMosix de una semntica SSI pura. En Unix, un proceso que escriba en un pipe en principio no es interrumpido si otro proceso abre el mismo pipe para leer o ya lo tena abierto y lo cierra. Activando esta opcin nos separamos de Posix: un proceso escritor en un pipe puede recibir una excepcin cuando otro proceso abra un pipe para leer dicho pipe, y puede recibir tambin una excepcin si el pipe se queda sin lectores. Disable OOM Killer (NEW): Algunas versiones del kernel de Linux incluyen una caracterstica bastante discutida: el OOM Killer. Esta opcin nos permite inhabilitar el OOM Killer, y evitar los problemas que este suele causar. En caso de duda, es recomendable habilitar esta opcin -es decir, inhabilitar el OOM Killer-.

Por ltimo, cabe destacar que todos los nodos del clster deben tener el mismo tamao mximo de memoria, o si no las tareas no migrarn. Para ello, hay que entrar en la opcin Processor type and features, y en la opcin High Memory Support se asigna el mismo valor a todos los nodos del clster.

3.2.1.2 Compilando finalmente el kernel Despus de esto, el kernel est listo para poder usar openMosix. Ahora se seleccionan las opciones adicionales del kernel que coinciden con nuestro hardware y el uso que se le quiera dar a nuestro Linux, se grabamos la configuracin y ejecutamos un make dep para calcular las dependencias entre las partes del kernel. A continuacin ejecutamos un make clean para limpiar restos de compilaciones anteriores y finalmente compilamos el kernel ejecutando make bzImage. # make dep # make clean # make bzImage Se compilan e instalan los mdulos: # make modules # make modules install Finalmente se copia el nuevo kernel en el directorio /boot. Por ltimo, es necesario crear una entrada en lilo.conf para el nuevo kernel.

3.2.2 Errores ms frecuentes a la hora de compilar e instalar el Kernel. Los errores ms frecuentes a la hora de configurar el kernel de openMosix son: Las aplicaciones no migran de todos los nodos a todos los nodos: La causa de este error suele ser que no se ha puesto todas las mquinas el mismo tamao mximo de memoria.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 22

ACSO 2010 Clustering El parche no se aplica correctamente: Es necesario utilizar un vanilla kernel, es decir, un kernel tal y como Linus Torvalds lo distribuye. Particularmente, los kernels que vienen con las distribuciones de Linux no valen ya que estn demasiado parcheados. No existe el directorio /proc/hpc: O no se ha arrancado con el kernel openMosix, o se ha olvidado el activar la primera opcin de openMosix process migration support al compilar el kernel. Uso la ltima versin del gcc, y el kernel de openMosix no compila: es un problema del kernel de Linux. Cualquier versin de gcc que compile el kernel de Linux compila el kernel de openMosix; y casi todas las distribuciones de Linux modernas traen un paquete con una versin del backend de gcc para compilar el kernel de Linux.

3.2.3 Administracin de los nodos 3.2.3.1 Configuracin manual de los nodos Para la configuracin manual de los nodos, es necesario modificar el fichero /etc/openmosix.map indicando una serie de parmetros en columna como se detalla a continuacin: En el ejemplo se detalla el fichero para nuestra mquina op3 (192.168.20.3) # fichero openmosix.map 1 192.168.20.1 1 2 192.168.20.2 1 3 127.0.0.1 1

La primera columna establece el nmero del nodo dentro del rango de nodos de OpenMosix. A continuacin se establece la IP del nodo asociado. La ltima columna indica el nmero de nodos dentro de ese rango. Una vez configurado el mapeado de los nodos en cada uno de los equipos, el clster estara listo para funcionar.

3.2.3.2 Deteccin automtica de los nodos

El demonio de auto-deteccin de nodos, omdiscd, proporciona un camino automtico para la configuracin de nuestro clster openMosix. Con l se puede eliminar la necesidad de configuraciones manuales como son la edicin del fichero /etc/openmosix. Omdiscd genera un envo de paquetes multicast (a todas las direcciones, en nuestro caso, nodos) para notificar a los otros nodos que hemos aadido uno nuevo. Esto significa que al aadir un nodo slo hay que iniciar omdiscd en l. Es necesario ocuparse de algunos requisitos previos como pueden ser una buena configuracin de la red de interconexin de los nodos, principalmente para el correcto enrutamiento de paquetes.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 23

ACSO 2010 Clustering 3.2.4 Herramientas de Monitorizacin: OpenMosixView OpenMosixView es una cmoda y amigable aplicacin de monitorizacin de un clster OpenMosix. OpenMosixView necesita otras bibliotecas instaladas para ejecutarse y compilarse. Sin embargo es una excelente herramienta y de gran utilidad, y debera ser instalada en la mquina desde la que se inspecciona todo el clster. La suite OpenMosixView contiene siete aplicaciones altamente tiles y eficaces tanto para la administracin como para la monitorizacin del clster. OpenMosixView: principal aplicacin de monitorizacin y administracin. OpenMosixprocs: aplicacin para la administracin de procesos. OpenMosixcollector: captura la informacin del clster proporcionada por los demonios. OpenMosixanalyzer: analizador de la informacin capturada por OpenMosixcollector. OpenMosixhistory: historial de monitorizacin de procesos del clster. OpenMosixmigmon: visor que representa la migracin de procesos. 3dmosmon: visor para monitorizacin de datos en 3D.

Ejemplo de OpenMosixmimon.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 24

ACSO 2010 Clustering Todos los componentes son accesibles desde la ventana de la aplicacin principal. Este entorno facilita la interaccin con el usuario puesto que le permite ejecutar los comandos de consola ms comunes con unos pocos clics de ratn.

Esta imagen muestra la ventana de la aplicacin. El usuario puede interactuar con OpenMosix a travs de sus controles. Para cada nodo del clster (cada fila): una luz, un botn, un slider, un nmero lcd, dos barras de progreso y un par de etiquetas. Las luces de la izquierda nos muestran el ID del nodo y su estado. En color rojo significa que el nodo no se encuentra operativo, y verde lo contrario. Si se hace clic en el botn que muestra la direccin IP de un nodo se invoca al dilogo de configuracin que mostrar los botones para ejecutar los comandos de mosctl ms comunes. Con los sliders de velocidad podemos establecer la velocidad que considerar el clster para cada nodo. Este parmetro se muestra en el display lcd. Se puede intervenir tambin en el balanceo de carga de cada nodo cambiando sus valores. Los procesos en un clster openMosix migran ms fcilmente hacia un nodo cuya velocidad sea ms elevada. Recordemos que este concepto de velocidad no tiene que ser el que realmente posea la computadora, es simplemente el parmetro que queremos que openMosix considere para cada mquina. Las barras de progreso, que conforman el par de columnas en la mitad de la ventana, dan una idea general de la carga de cada nodo del clster. La primera se refiere a la carga del procesador y muestra un porcentaje que ser una aproximacin del valor escrito por openMosix en el fichero /proc/hpc/nodes/x/load. La segunda barra nos muestra la memoria utilizada en cada nodo. El box de la izquierda nos muestra el total de memoria disponible. Finalmente la caja de ms a la derecha nos muestra el nmero de procesadores de cada nodo. En la esquina superior-izquierda podemos ver el box load-balancing efficiency, ste es un indicador de la eficiencia del algoritmo de balanceo de carga. Un valor prximo al 100 % indica que la carga computacional ha podido dividirse equitativamente entre los nodos.

3.3 Implementacin de clster Beowulf


Para la implementacin del clster tipo Beowulf, se ha decidido utilizar las libreras PVM, que se encuentran disponibles en una gran cantidad de repositorios para las diferentes distribuciones del sistema operativo GNU/Linux. La mquina virtual paralela (PVM) permite realizar computacin paralela y estar formada por todos los nodos en los que est activo el demonio pvmd. Consta de los siguientes componentes: Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 25

ACSO 2010 Clustering El demonio pvmd El archivo de configuracin ~/pvm.hosts La consola interactiva de PVM (pvm) y su fron-end grfico XPVM (xpvm) Las libreras de PVM Herramientas de desarrollo ( aimk, )

3.3.1 Instalacin y configuracin de PVM Para realizar el experimento, se ha utilizado en todas las mquinas el mismo sistema operativo. En este caso la distribucin escogida ha sido GNU/Linux Ubuntu 9.10. Los pasos seguidos para proceder a la instalacin y configuracin han sido los siguientes: Instalacin de las libreras: El primer paso consiste en instalar los paquetes pvm y pvm-dev. En la fecha actual, la ltima revisin de los paquetes para la distribucin de Ubuntu, que est disponible en los repositorios oficiales es la 3.4.5-12. Esta operacin debe hacerse en todas las mquinas del clster.

#apt-get install pvm pvm-dev Ajustar las variables de entorno: es necesario definir dos nuevas variables de entorno PVM_ROOT y PVM_ARCH, que definen el directorio de instalacin de PVM y la arquitectura de la mquina respectivamente. Una vez establecida, es necesario ampliar el contenido de la variable PATH, aadiendo la ruta de los ejecutables de PVM. Esta operacin debe hacerse en todas las mquinas del clster.

export PVM_ROOT=/usr/lib/pvm3 export PVM_ARCH=LINUX export PATH=$PATH:$PVM_ROOT/bin:$HOME/pvm3/bin Configuracin del directorio para los ejecutables: Creamos un directorio, que previamente ya ha sido referenciado en PATH, en el que se almacenarn los ejecutables compilados que se ejecutarn en el clster de forma paralela. Este directorio ser en nuestro caso el directorio ~/pvm3/bin/LINUX. Esta operacin debe ejecutarse en todas las mquinas. Resolucin de nombres: Bien mediante un DNS, o configurando directamente el fichero /etc/hosts, ser necesario que la mquina maestra conozca los hostname de las mquinas asociadas al clster. Para este experimento se ha modificado directamente el /etc/hosts aadiendo las entradas de IP asociadas a los hostname, includo s mismo. Es importante que la direccin de loopback en el propio fichero NO est referenciada al propio hostname.

#/etc/hosts 10.0.32.193 Pollux 10.0.32.176 nodo1 Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 26

ACSO 2010 Clustering 10.0.32.195 nodo2 10.0.32.99 loxo-machine

Habilitar SSH sin password: para que el nodo maestro pueda ejecutar comandos remotos en los esclavos, PVM utiliza SSH. Para disponer de SSH es necesario instalar el paquete openssh-server y en todas las mquinas esclavo y configurarlo para que acepten conexiones desde la mquina maestra sin pedir contrasea ni pass-phrase. Para ello, la solucin adoptada ser la de crear una clave RSA en la mquina maestra y repartirla a los esclavos para que sus respectivos servidores SSH la autoricen y permitan el acceso sin clave. Adems, deberemos activar el ssh-agent en la mquina maestra para que no nos pida la pass-phrase. Lo ms cmodo resulta crear el mismo usuario con la misma clave en todas las mquinas involucradas en el clster. En nuestro caso Pollux ejerce como mquina maestra del clster. Creamos una clave RSA en la mquina maestro.

figado@Pollux$ ssh-keygen t rsa f ~/.ssh/id_rsa Activamos el ssh-agent en la mquina maestro para que no pida la passfrase.

figado@Pollux$ eval `ssh-agent s ` Agent pid 18293 figado@Pollux$ ssh-add Enter passphrase for /home/figado/.ssh/id_rsa: Identity added: /home/figado/.ssh/id_rsa (/home/figado/.ssh/id_rsa) Copiar la clave pblica en todos los esclavos y aadirla al final del fichero ~/.authorized_keys

figado@Pollux$ scp ~/.ssh/id_rsa.pub figado@nodo1:~/.ssh/id_rsa.pub figado@nodo1$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Para levantar los nodos del clster es necesario que en todos ellos est corriendo el demonio pvmd. Para poder arrancarlos de forma automtica, es necesario generar un fichero pvm.hosts en el que se indicar la lista de nodos del clster. # ejemplo de pvm.hosts # Master PVM Pollux # Esclavos Nodo 1 Loxo-machine Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 27

ACSO 2010 Clustering Una vez llegados a este punto, el clster est preparado para ser lanzado e ir aadiendo tantos nodos como mquinas esclavo hayamos configurado. Para comenzar inicializar el clster, podemos utilizar dos herramientas, bien la consola propia de PVM, o bien la interfaz grfica XPVM como veremos en los puntos siguientes. 3.3.2 Consola de PVM Para ejecutar la consola interactiva de PVM, simplemente tecleamos pvm y tendremos acceso al prompt. En caso de que el demonio pvmd no estuviese corriendo, se lanza automticamente.

A travs del comando help se muestra un listado de todos los comandos disponibles en la Shell de PVM. Mediante la utilizacin de estos comandos es posible configurar el clster aadiendo nuevos nodos o eliminando nodos existentes, monitorizando las tareas y trazando los hilos.

Para mostrar la configuracin actual del clster, se utiliza el comando conf, que muestra el nmero de nodos que estn activos y parmetros relacionados.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 28

ACSO 2010 Clustering

Para aadir un nuevo nodo al clster se utiliza el comando add. En el ejemplo verificamos la configuracin inicial, y ejecutamos un add loxo-machine para aadir esa mquina como nodo del clster.

Para eliminar un nodo del clster se utiliza el comando delete. En el ejemplo, verificamos la configuracin del clster y a continuacin ejecutamos un delete loxo-machine para eliminar la mquina del clster.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 29

ACSO 2010 Clustering

3.3.3 Entorno grfico XPVM Para el entorno grfico disponemos de un frontal para la consola que nos permite administrar y monitorizar el clster. Para arrancarlo ejecutamos el comando xpvm. Una vez lanzado, arranca el demonio pvmd en la mquina maestra y en todos los nodos listados en el fichero pvm.hosts. En la siguiente captura se puede observar el front-end de XPVM, donde se observa la configuracin del clster, compuesta por un nodo maestro (Pollux) y dos nodos esclavos (nodo1 y loxo-machine).

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 30

ACSO 2010 Clustering

En la parte superior, podemos observar la ventana de Network que muestra la actividad de cada uno de los nodos del clster. Cada nodo est representado por una imagen que muestra el nombre del host y la arquitectura. Las imgenes se iluminan indicando el status de la mquina/nodo: Verde: Activa, lo que significa que al menos una tarea est siendo procesada en el nodo.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 31

ACSO 2010 Clustering Amarilla: System, significa las tareas no se est ejecutando en el nodo porque la cola de rutinas del clster estn saturadas. Blanco: Sin tareas asignadas ni en ejecucin.

En la parte inferior, podemos observar la ventana de Space-Time que muestra el estado de las tareas que se estn ejecutando a lo largo del clster, en cada uno de los nodos. Cada tarea se representa por una barra horizontal a lo largo del eje x que corresponde al tiempo. Los colores utilizados para indicar el estado de las tareas son los siguientes: Verde: Computing, que significa que se estn ejecutando tareas tiles del usuario. Amarillo: Overhead, que indica que se estn ejecutando rutinas de sistema de PVM para comunicaciones, control de tareas, etc. Blanco: Waiting, Indica que se est a la espera de recibir mensajes. Rojo: Mensaje indicando comunicacin entre tareas.

En la ventana anterior podemos observar las algunas de las funcionalidades bsicas para configurar el clster. Los iconos de los diferentes mens ofrecen la posibilidad de realizar diferentes tareas sobre el clster y configurarlo variando sus parmetros: Hosts: Este men permite configurar el clster aadiendo o eliminando nodos. Permite adems seleccionar los nodos de una determinada lista, o bien seleccionarlos por nombre. Tasks: este men permite spawnear, enviar seales o matar procesos. Reset: permite resetear el clster, las vistas de la interfaz grfica y los trazados en los ficheros de log. Help: proporciona ayuda para la mayora de las caractersticas de la interfaz.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 32

ACSO 2010 Clustering

4 Pruebas Experimentales
4.1 Clculo de la multiplicacin de matrices en Beowulf
En esta prueba se va a realizar una ejecucin de un programa de clculo de matrices que tiene por objetivo comprobar el rendimiento del clster Beowulf introduciendo como parmetro variable el nmero de nodos que procesan as como el nmero de hilos que se generan para procesar, y que consecuentemente son repartidos a lo largo del clster. Como aadido, se realizar una prueba de ejecucin para comprobar el comportamiento del clster en el momento en el que uno de los nodos se cae durante la ejecucin del programa. 4.1.1 Descripcin Creamos un programa que recibe como parmetros la dimensin de una matriz y el nmero de hilos que se van a generar. El programa hace uso de la librera PVM para paralelizar el problema. Subdivide la matriz en renglones que pasa como parmetros a los distintos procesos que se crean, de forma que los renglones son tratados de forma independiente por cada uno de los procesos paralelos, que se comunican con el proceso padre mediante el envo de mensajes, utilizando los mecanismo proporcionados por la librera PVM. 4.1.2 Herramientas Programa de multiplicacin de matrices matrix2.c Consola de pvm

4.1.3 Ejecucin Lanzamos el programa teniendo en cuenta que el fichero debe de estar copiado en todos los nodos esclavo que van a ser lanzados dentro del clster. 4.1.4 Resultados Tamao de Matriz 500 500 500 500 500 500 500 500 1000 1000 1000 1000 1000 1000 1000 1000 Nodos 2 2 2 2 3 3 3 3 2 2 2 2 3 3 3 3 N Procesos 2 5 10 15 3 5 10 15 2 5 10 15 3 5 10 15 Tiempo 2.680 3.966 4.501 4.976 1.91 2.188 2.824 3.462 14.7673 15.713 15.674 15.678 12.315 16.744 14.935 18.929 Pgina 33

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

ACSO 2010 Clustering 4.1.5 Conclusiones La tnica general que se observa es que a mayor nmero de procesos, mayor tiempo de ejecucin se necesita para completar la tarea. Esto es debido a que la gran cantidad de cambios de contexto, as como la gestin del paso de mensajes entre los diferentes procesos, comprometen en gran medida el rendimiento general del clster. Por lo tanto, es necesario llegar a un acuerdo respecto del nmero de procesadores que se van a disponer en la mquina virtual, es decir, procesadores fsicos de las distintas mquinas, y el nmero de procesos que se van a generar para ser consumidos por esos procesadores fsicos. Adquiriendo un compromiso razonable cercano a 1 o 2 Threads por cada Core fsico, es cuando se observan mejores resultados.

4.2 Test de Balanceo de Carga en OpenMosix


Con la realizacin de esta prueba se pretende demostrar como OpenMosix es capaz de realizar un reparto del procesamiento entre sus nodos, haciendo este balanceo de una forma transparente, es decir sin una codificacin especifica por parte de un programador, lo que le ofrece la posibilidad a un usuario de hacer uso de toda la capacidad del clster. 4.2.1 Descripcin Creamos un simple script de AWK con un bucle for anidado que ser ejecutado un elevado nmero de veces. Gracias a las herramientas grficas que proporciona OpenMosix, comprobaremos como el clster es capaz de auto-gestionarse y balancear la carga de procesamiento entre los distintos nodos que conforman el clster. 4.2.2 Herramientas Script de AWK: se crea un script que lo llamaremos testOpenMosix con el siguiente cdigo.

# awk 'BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}' &

OpenMosixMigmon y OpenMosixView: se emplean estas dos herramientas grficas para la comprobacin del balanceo de carga entre los nodos del clster.

4.2.3 Ejecucin Con el comando openmosixview iniciamos la aplicacin grfica para el control de los nodos. Mediante ella se observar el comportamiento de cada nodo. Con el comando openmosixmigmon iniciamos la aplicacin grfica que nos proporciona una visin global del reparto de procesos a lo largo de los nodos del clster. Para realizar la ejecucin del script, crearemos un bucle for para realizar mltiples llamadas sobre el mismo. Lo realizamos de la siguiente manera: $ for i in `ls /etc/` ; do ./test_mosix ; done Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 34

ACSO 2010 Clustering

4.2.4 Resultados Obtenidos En la siguiente ilustracin se observa como el nodo maestro esta balanceando los procesos entre los nodos esclavos.

A continuacin, en la imagen posterior se observa el reparto de los procesos por los nodos del clster, cubriendo al 100% la capacidad de procesamiento mismo, manteniendo todos los procesadores disponibles a pleno rendimiento.

Con los resultados obtenidos podemos asegurar que OpenMosix es capaz de distribuir la carga de proceso entre los nodos de una manera transparente.

4.3 Ejecucin de una compilacin multi-hilo


Con la realizacin de esta prueba se pretende determinar el comportamiento del clster OpenMosix a la hora de realizar una bzImage de un kernel. Se realizara varias veces el test,

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 35

ACSO 2010 Clustering aumenta el nmero de nodos conectados al clster. Finalmente se realizar una tabla comparativa con los resultados obtenidos del test.

4.3.1 Descripcin Se llevarn a cabo 3 interacciones distintas del test: con un solo nodo en el clster. se aadir un segundo nodo al clster y se ejecutar la compilacin con 2 procesos. tres nodos activos en el clster y se ejecutar la compilacin con 3 procesos.

En cada una de las interacciones se medir el tiempo total de ejecucin de la creacin de la imagen del kernel. Se compararn los resultados de las interacciones.

4.3.2 Herramientas - Sentencia make: $ make bzImage - para aumentar el nmero de procesos ejecutamos make con parmetro j <nmero de procesos -1> de la siguiente manera: $ make bzImage -j 3 - Para mostrar el tiempo en consola ejecutamos un time antes del comando make: $ time make Adems, se emplearn las herramientas grficas para el control del estado del clster proporcionadas por OpenMosix.

4.3.3 Ejecucin Antes de cada una de las iteraciones se realiza: $ make clean $ make dep

Iteracin 1 2 3

Comando $ time make bzImage $ time make bzImage -j 3 $ time make bzImage -j 4

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 36

ACSO 2010 Clustering 4.3.4 Resultados Obtenidos

La tabla de resultados obtenidos es la siguiente: Nmero de Nodos en el Cluster 1 solo nodo 2 nodos 3 nodos Tiempo de Ejecucin 13m 9 14m 30 14m 57

En la tabla se observa que a medida que aumentamos los nodos en el clster, el tiempo tambin aumenta. En la herramienta grafica se observa como el nodo maestro apenas enva procesos a los nodos esclavos para realizar la tarea.

Con los resultados obtenidos podemos asegurar que OpenMosix no es rentable para este tipo de procesamiento, puesto que no aprovecha toda la capacidad de procesamiento de la que dispone. Se supone que no se hacen uso de los nodos debido a que el nodo principal no consigue mantenerse durante el tiempo suficiente con una carga de trabajo suficiente como para necesitar derivar el procesamiento a los otros nodos. Se asume que el aumento de los tiempos, al mismo tiempo que aumentamos los nodos, se produce por el hecho de que el nodo Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010 Pgina 37

ACSO 2010 Clustering maestro ha de dedicar ms tiempo a la gestin de los nodos, lo que le resta recursos al proceso de creacin de la bzImage.

5. Conclusiones
El propsito de este proyecto inicialmente era el de comparar dos tipos de arquitecturas para la creacin de clusters, es decir, comparar dos maneras de conseguir un procesamiento paralelo interconectando entre s varias mquinas que colaboran para la consecucin de tareas. Tras un largo proceso de adquisicin de conocimientos sobre las arquitecturas y tecnologas utilizadas por las distintas distribuciones de clusters, se concluy que la mayora de ellas estn basadas en una arquitectura muy similar y que su principal diferenciacin radica en los sistemas de interconexin entre los nodos y la transparencia o no de la gestin de los procesos y recursos. Una vez identificadas las caractersticas exactas de las distintas distribuciones para la realizacin de un clster, se concluy que los resultados que se obtendran de una comparativa directa entre ellos no seran significativos debido a sus distintas especializaciones. Con todo este anlisis del estado del arte de las distribuciones de clustering, se adopta la postura de analizar cada una de las dos distribuciones por separado, ofreciendo resultados en cuanto a sus capacidades de adaptacin y a su funcionamiento, creando para ello dos tipos distintos de clusters y sometiendo estos a distintas pruebas adaptadas para cada uno. De los test realizados a los distintos tipos de clster, se han llevado a cabo ms test de los que se documentaron y con distintas distribuciones, se puede llegar a las siguientes conclusiones: La mayora siguen un enfoque no transparente, lo que genera que estn fuertemente ligados a los desarrollos de software especfico para ellos. Es decir, no todo programa ejecutado en un clster va a ser posible gestionarlo de manera paralela, no se aprovechar las capacidades del clster. Solo Mosix y OpenMosix (fuera de desarrollo) ofrecen un claro enfoque transparente, ofreciendo la ejecucin paralela de los programas pero con ciertas restricciones. Sobre posibles mejoras se destacara la de generar las pruebas con un mayor nmero de nodos y con aplicaciones ms complejas y adaptadas a cada clster, mejoras que por falta de tiempo y de recursos no se pudieron realizar en este proyecto. Sugerir adicionalmente que sera de un gran inters someter a estas y otras pruebas a la distribucin Mosix que existe comercialmente pero que es de distribucin gratuita siempre y cuando sea para fines acadmicos.

Loxo Lueiro Astray Cstor Snchez Chao - ACSO 2010

Pgina 38

También podría gustarte