Implement Ac i on de Clusters

IMPLEMENTACIN DE CLUSTER DE COMPUTADORAS

PARA APLICACIONES DE INGENIERA.

AUTORES CUEVAS VALENCIA, REN EDMUNDO FELICIANO MORALES, SEVERINO MOLINA NGEL, FLIX

Responsable de la publicacin digital: M en C. Flix Molina ngel. Gestin del ISBN: RENE EDMUNDO CUEVAS VALENCIA. Diseo de portada: Ren Edmundo Cuevas Valencia. Responsables de la Reproduccin en Discos Compactos: Cuevas Valencia Ren Edmundo. Financiamiento para la Reproduccin del EBook: M. en C. Juan Carlos Medina Martnez, Director de la U A de Ingeniera. Sitio WEB: http://ingenieria.uagro.mx/catics ISBN: 978-607-00-3902-7 El contenido de este EBook, es con fines educativos que impacten en el programa de Ingeniero en Computacin de la UAI de la UAGro. Se permite la reproduccin total o parcial del mismo por cualquier medio, siempre y cuando se cite a los autores. Chilpancingo de los Bravo, Guerrero, Mxico. Diciembre de 2010.

CONTENIDO

! "!

CONTENIDO Pg. INTRODUCCIN 1 1. DESCRIPCIN DE LOS CLUSTER 2 1.2. Caractersticas de los cluster 4 1.3. Tipos de acoplamiento en un cluster 7 1.4. Esquema y otras caractersticas 10 1.4.1. El factor de control del cluster 10 1.4.2. Seguridad 11 1.4.3. Homogeneidad 11 1.4.3.1. Homogeneidad de un cluster 11 1.5. Clasificacin de los cluster 12 1.5.1. Alto rendimiento (HP High Performance) 12 1.5.1.1. Problemas que solucionan 13 1.5.1.2. Tcnicas que utilizan 13 1.5.2. Alta disponibilidad (HA High Availability) 14 1.5.2.1. Problemas que solucionan 14 1.5.2.2. Tcnicas que utilizan 15 1.5.3. Alta confiabilidad (HR High Reliability) 15 1.6. Tecnologas similares a cluster tipo Beowulf 16 1.7. Estado del arte 16 !2. CLUSTER DE APLICACIN #$!2.1. Conceptos de Migracin y Balanceo #$!2.1.2. PVM (Parallel Virtual Machine) y MPI (Message Passing Interface)

%&!2.1.3. Paso de mensajes %'!2.2. PVM %(!2.3. MPI %$!2.4. Beowulf )*!2.5. OpenMosix )*! !3. CLUSTER DE SISTEMA )%!3.1. Introduccin )%!3.2. Mainframes, Supercomputadoras y Cluster ))!3.3. De MOSIX a openMosix ))!3.3.1. Caractersticas de openMosix ))!3.3.2. Algoritmo de migracin )'!3.3.3. El nodo raz )'!3.3.4. El mecanismo de migracin )(!3.3.5. Cundo podr migrar un proceso? )(!3.3.6. La comunicacin entre usuario y kernel )(!3.3.7. Instalacin de un cluster openMosix )+!3.3.8. Instalacin del kernel de openMosix )+!3.3.8.1. Opciones del kernel de openMosix )$!3.4. Administracin del cluster &)!3.4.1. Administracin bsica &)!3.4.2 Configuracin &)!

CONTENIDO

! ""!

3.4.3. Las herramientas de rea de usuario &'!3.4.4. Deteccin automtica de nodos &,!3.4.5. Compilaciones &$!3.4.6. Problemas &$!3.5. Testeo de rendimiento con Stress-Test '*!3.5.1. Descripcin general '*!3.5.2. Descripcin detallada '*!3.5.3. openMosixview '*!3.5.3.1. Instalacin '*!3.5.3.2. Instalacin desde paquetes RPM '#!3.5.3.3. Instalacin desde las fuentes '#!3.5.3.4. Script de configuracin automtico '#!3.5.3.5. Compilacin manual '#!3.6. Utilizando openMosixview '%!3.6.1. Aplicacin principal '%!3.6.2. La ventana de configuracin ')!3.6.3. Ejecucin avanzada '&!3.6.4. La lnea de comandos ''!3.6.4.1. El host-chooser '(!3.6.4.2. El host-chooser paralelo '(!3.6.5. openMosixprocs '(!3.6.5.1. La ventana de migracin '(!3.6.5.2. Administrando procesos remotamente '+!3.6.6. openMosixcollector '+!3.6.7. openMosixanalyzer '$!3.6.7.1. Una visin general de la carga del sistema '$!3.6.7.2. Estadsticas sobre los nodos del cluster (*!3.6.7.3. Monitorizacin de la memoria (*!3.6.7.4. openMosixhistory (#! !4. OPERATIVIDAD DE CLUSTER CON APLICACIONES DE INGENIERA.

(%!4.1. Hardware requerido (%!4.2. Software utilizado ()!4.3. Herramientas que se utilizan en los cluster (&!4.3.1. Informacin general sobre Software Libre ('!4.3.2. Herramientas de software / Software tools (Windows 98/XP y LINUX)

('!4.4. Estructura interna de un archivo tipo POV ($!4.4.1. Estructura interna de un archivo tipo INI ,*! !5. ANLISIS DE RESULTADOS ,#!5.1. Resultados obtenidos de una sola computadora ,#!5.1.1. Categora: advanced ,#!5.1.2. Categora: animation ,&!5.2. Resultados obtenidos utilizando el cluster +#!5.2.1 Categora: advanced +%!5.2.2. Categora: animation ++!5.3. Ejecucin mltiple usando cluster $,!5.3.1. Categora: Advanced $,!5.3.2. Categora: animation #*%!

CONTENIDO

! """!

5.4. Anlisis de resultados #*+!5.4.1. Ejecucin sin utilizacin del cluster #*+!5.4.2. Ejecucin utilizando el cluster #*$! !ANEXO 1. Glosario de Trminos ###!ANEXO 2. Errores ms frecuentes al compilar e instalar el kernel

##$!ANEXO 3. Instalacin de las herramientas de rea de usuario #%*!ANEXO 4. Errores frecuentes en la compilacin e instalacin de las herramientas

#%#!ANEXO 5. Configurando la topologa del cluster #%%!ANEXO 6 Las herramientas de rea de usuario #%(!ANEXO 7 Optimizando el cluster #)%!ANEXO 8 Descripcin detallada Stress-Test #)&!ANEXO 9 abyss.pov #)(!ANEXO 10 chess2.pov #&+!ANEXO 11 grenadine.pov #'+!ANEXO 12 landscape.pov #(*!ANEXO 13 camera2.pov, camera2.ini #((!ANEXO 14 float4.pov, float4.ini #($!ANEXO 15 vect1.pov, vect1.ini #,#! ! !!

INTRODUCCIN.

1

INTRODUCCIN El presente libro gira en torno a la investigacin de los Cluster usando la tecnologa Beowulf y manipulando el sistema operativo Linux en su distribucin Red Hat versin 9.0, realizando las modificaciones necesarias en el Kernel para trabajar con OpenMosix, para lograr con ello un proceso paralelo de tareas cada vez que se ejecute alguna aplicacin, analizndose aplicaciones de ingenieria para posteriormente proporcionar resultados, realizando cuadros comparativos en base a tiempo maquina y destacando la importancia de compartir tareas con n equipos de computo para la obtencin de resultados en tiempos cortos. As tambin se describen los tipos de clusters de aplicacin que se manejan, proporcionando caractersticas que los diferencian; agregando los pasos a seguir para tener una adecuada instalacin y configuracin de un cluster de sistema. Con todo lo anterior se lograr presentar un anlisis de las aplicaciones de ingenieria que se utilizaron para desarrollar este trabajo. El presente libro se inscribe en el marco de la investigacin experimental en el rea de los Sistemas Distribuidos; donde se instalar, programar y experimentar con diversos sistemas que fueron pensados para resolver problemas complejos que involucran tiempos de demora y que se pretende optimizar su desempeo bajo el uso de los clusters de alto rendimiento. Los cambios que se observan en el Hardware, han motivado pensar que los equipos que se adquieren en un futuro relativamente corto tal Hardware ser obsoleto; ya que la presencia de nuevos programas (Software) hacen necesario tener mayores requerimientos y en su defecto reemplazarlos por otro equipo con caractersticas superiores. La necesidad de estar a la vanguardia referente al Hardware lleva a las Instituciones Educativas a destinar parte de su presupuesto para la adquisicin de equipos de cmputo ms sofisticados, considerando los escasos recursos econmicos con los que se cuenta en las Instituciones Pblicas, es necesario implementar estrategias para la reutilizacin de la infraestructura de Hardware existente. Muchas aplicaciones en el rea de las Ciencias de la Computacin requieren de la ejecucin de programas en tiempos cortos, esto lleva a que cada da se tenga que dar soluciones a distintas reas del conocimiento de la ingenieria. La implementacin de clusters es una solucin que ayuda en gran medida a optimizar los recursos que se tienen y explotarlos al mximo, ya que su objetivo es el de dividir el problema en tareas para darle solucin en menor tiempo. Es por ello que se pretende explicar la instalacin de un cluster y buscar entre distintas aplicaciones alguna que permita demostrar el rendimiento y potencial que se tendra en una institucin educativa de nivel superior, vinculndose con las materias afines, con el objeto de darle un uso prctico para los programas de estudio de licenciatura y postgrado.

1. DESCRIPCIN DE LOS CLUSTER

2

1. DESCRIPCIN DE LOS CLUSTER Al principio las necesidades de las empresas e instituciones eran cubiertas con el uso de una computadora personal, conforme se fue avanzando y explotando los recursos tanto de Hardware como de Software, se empezaron a tener otras necesidades como la comunicacin entre computadoras, con ello nace y se desarrollan las Redes de computadoras de forma local y a medida que se requera comunicarse a grandes distancias se desarrollaron las redes en toda la extensin, dando paso a la evolucin del Internet con los alcances que ya conocemos. A medida que crece la necesidad de estar comunicados, tambin evolucionan las distintas reas de la investigacin cientfica, educativa, mdica, etc; esto conlleva al desarrollo de programas software diseados a la medida para resolver problemas especficos obteniendo al mximo los requerimientos fsicos del equipo y adaptndose a los lenguajes de programacin que existan en el momento. La potencialidad del Hardware no ha dejado de crecer, esto es resultado de las necesidades y demandas de los usuarios para lograr mayor capacidad de procesamiento (esto ayuda a ejecutar las operaciones de los programas en un tiempo menor), de almacenamiento temporal (que se usa para que coordinadamente con el procesador pueda realizar con mayor rapidez las tareas solicitadas), de almacenamiento secundario (el cual aumenta en proporciones gigantescas, ya que la necesidad de guardar volmenes de informacin de forma permanente se vuelve una prioridad en cualquier rea) y de comunicacin usando la red (comunicarse al mundo exterior o simplemente compartir la informacin que se tiene de una computadora a otra). La necesidad de reutilizar equipos de cmputo ha dado paso a que distintas reas del conocimiento computo evolucionen, una de ellas es el proceso distribuido, la necesidad de implementar programas que se puedan ejecutar en distintas computadoras. La programacin seriada y la programacin paralela han logrado que se generen aplicaciones aportando beneficios significativos al mundo de la computacin. La necesidad de comunicarse a travs de computadoras unidas por una red de comunicacin para realizar un trabajo, esto puede ser el resultado de obtener alta disponibilidad, alto rendimiento, en aplicaciones que por si solas consumiran tiempos considerables. Una solucin a estas necesidades es la implementacin de clusters de computadoras. Un cluster es un grupo de equipos independientes que ejecutan una serie de aplicaciones de forma conjunta y se muestran ante clientes y aplicaciones como un solo sistema. Existen diversas interpretaciones para definir un cluster, a continuacin se citan solo algunas definiciones:


3

Un cluster consiste en un conjunto de computadoras y un servidor de cluster dedicado, para realizarlos relativamente infrecuentes accesos a los recursos de otros procesos, se accede al servidor de cluster de cada grupo. (Silberschatz & Galvn, 2003). Un cluster 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 computadora 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 cluster comerciales se pueden usar tecnologas de red propias. El interfaz de red no est muy acoplado al bus I/O. Los nodos tienen disco local. Cada nodo tiene un sistema operativo UNIX con una capa de software para soportar todas las caractersticas del cluster. (Hwang & Xu,1998). Es una clase de arquitectura de computador paralelo que se basa en unir computadoras independientes cooperativas integradas por medio de redes de interconexin para proveer un sistema coordinado, capaz de procesar una carga. (Sterling, 2001). En 1994 Thomas Sterling y Don Becker, bajo el patrocinio del proyecto ESS del Centro de la Excelencia en Ciencias de los Datos y de la Informacin del Espacio (CESDIS) construyeron el primer Cluster de Computadoras el cual llamaron Beowulf con fines de investigacin. Beowulf no es un paquete de Software especial, no es una topologa de red diferente, tampoco un ncleo modificado. Beowulf es una tecnologa que permite agrupar computadoras basadas en el sistema operativo Linux para formar una supercomputadora virtual paralela. Figura 1.1.

Figura 1.1. Representacin de un Cluster Beowulf

Beowulf esta basada en multicomputadoras el cual puede ser utilizado para la computacin paralela. Este sistema consiste de un nodo maestro y uno o ms nodos esclavos conectados a travs de una red Ethernet u otra topologa de red. Est construido con componentes de Hardware comunes, solo debe tener la capacidad de ejecutar el sistema operativo Linux, as como tambin contar con tarjetas de red Ethernet y switches estndares. Como no cuenta con elementos de Hardware especiales, resulta totalmente reproducible.


4

Una de las diferencias ms significativas entre un cluster Beowulf y un COW (Cluster Of Workstations, Cluster de estaciones de trabajo) es el hecho de que un Beowulf se comporta como una sola computadora y el COW como muchas estaciones de trabajo conectadas y en la mayora de los casos los nodos esclavos no tienen monitores o teclados y son accesados de forma remota o por una terminal serial; donde el nodo maestro controla el cluster entero y presta servicios de sistemas de archivos a los nodos esclavos, es tambin la consola del cluster y la conexin hacia el exterior. Las computadoras grandes de Beowulf pueden tener ms de un nodo maestro y otros nodos dedicados a diversas tareas especficas como por ejemplo consolas o estaciones de supervisin. En la mayora de los casos los nodos esclavos de un sistema Beowulf son estaciones simples. Los nodos son configurados y controlados por el nodo maestro y hacen solamente lo que ste le indique. En una configuracin de esclavos sin disco duro, estos incluso no saben su direccin IP hasta que el maestro les dice cul es. La topologa de red recomendada es de tipo Bus, debido a la facilidad para proporcionar escalabilidad a la hora de agregar nuevos nodos al cluster. Protocolos como Ethernet, Fast Ethernet, Giga Ethernet, 10/100 Mbps, Switch Ethernet, son tecnologas consideradas apropiadas para ser utilizadas en Beowulf. Beowulf utiliza como sistema operativo cualquier distribucin Linux. La distribucin en la cual se han realizado ms trabajos Beowulf es con la conocida como Red Hat en cualquiera de sus versiones existentes. Sin lugar a duda los cluster presenta una alternativa importante para diversos problemas particulares, no solo por su economa, sino tambin porque pueden ser diseados y ajustados para aplicaciones especficas (Beowulf,2003). 1.2. Caractersticas de los cluster Para crear un cluster se necesitan al menos dos nodos. Una de las caractersticas principales de estas arquitecturas es que exista un medio de comunicacin (red) donde los procesos puedan migrar para computarse en diferentes estaciones paralelamente. Un solo nodo no cumple este requerimiento por su condicin de aislamiento para poder compartir informacin. Las arquitecturas con distintos procesadores en una sola tarjeta madre tampoco se consideran cluster, bien sean computadoras SMP (multiprocesamiento simtrico) o Mainframes, debido a que el bus de comunicacin no puede ser de red, sino interno. Los cluster permiten aumentar la escalabilidad, disponibilidad y fiabilidad de mltiples niveles de red.


5

La escalabilidad es la capacidad de un equipo para hacer frente a volmenes de trabajo cada vez mayores sin, por ello, dejar de prestar un nivel de rendimiento aceptable. Existen dos tipos de escalabilidad:

a) Escalabilidad del Hardware: denominada 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.

b) Escalabilidad del Software: denominada escalamiento horizontal. Se basa, en

la utilizacin de un cluster compuesto de diversos equipos de mediana potencia que funcionan de forma muy parecida a como lo hacen las unidades de un RAID (Arreglo Redundante de Discos de Bajo Costo). Se utiliza el trmino RAC (Arreglo Redundante de Equipos) para referirse a los cluster de escalamiento horizontal. Del mismo modo que se aaden discos a un arreglo RAID para aumentar su rendimiento, se pueden aadir nodos a un cluster 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. Los fabricantes de Hardware intentan anticiparse a las fallas aplicando la redundancia en reas clave como son las unidades de disco, las fuentes de alimentacin, las tarjetas controladoras de red y los ventiladores, pero dicha redundancia no protege a los usuarios de las fallas de las aplicaciones. De poco servira, por lo tanto, que un servidor sea confiable si el software de base de datos que se ejecuta en dicho servidor falla, ya que el resultado no seria otro que la ausencia de disponibilidad. Esa es la razn de que un solo equipo no pueda ofrecer los niveles de escalabilidad, disponibilidad y fiabilidad necesarios que s ofrece un cluster. Una de las herramientas de auge en la actualidad son los llamados cluster Beowulf, los cuales presentan diversas capacidades para el computo paralelo con un relativo alto rendimiento. Por consiguiente se describen las tres caractersticas de un cluster: ! Consta de 2 o ms nodos. ! Los nodos de un cluster estn conectados entre s por al menos un canal

de comunicacin. ! Los cluster necesitan software de control especializado.

El problema tambin se plantea por los distintos tipos de cluster, cada uno de ellos requiere un modelado y diseo del Software distinto. Las caractersticas del cluster son completamente dependientes del Software, parte de este software se debe dedicar a la comunicacin entre los nodos. Existen diferentes tipos de software que pueden conformar un cluster:


6

A. Software a nivel de aplicacin.

Situado a nivel de aplicacin, se utilizan generalmente bibliotecas de carcter general que permiten la abstraccin de un nodo a un sistema conjunto, permitiendo crear aplicaciones en un entorno distribuido de manera lo ms abstracta posible. Este tipo de software genera elementos de proceso del tipo rutinas, procesos o tareas, que se ejecutan en cada nodo del cluster y se comunican entre s a travs de la red. Figura 1.2.

B. Software a nivel de sistema.

Situado a nivel de sistema, esta implementado como parte del sistema operativo de cada nodo, o ser la totalidad de ste. Es ms crtico y complejo, por otro lado resuelve problemas de carcter ms general que los anteriores y su eficiencia, es mayor. Figura 1.3.

A pesar de esta divisin existen casos de implementaciones hbridas donde un cluster puede tener implementado a nivel de Kernel como parte del sistema y otra parte estar preparada a nivel de usuario. Para establecer las diferencias entre los distintos tipos de sistemas Beowulf se presenta la siguiente clasificacin. Clase I.

Son sistemas compuestos por computadoras 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. De esta manera, estos cluster no estn diseados para ningn uso ni requerimientos en particular.

Figura 1.2. Cluster a nivel de aplicacin


7

Figura 1.3. Cluster a nivel de sistema

Clase II.

Son sistemas compuestos por computadoras 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. De tal manera, pueden estar diseados para algn uso o requerimiento en particular. Las computadoras ubicadas en esta categora pueden presentar un nivel de prestaciones superior a las de la clase I (miKel & Buytaert, 2004).

1.3. Tipos de acoplamiento en un cluster Dependiendo del tipo de software, el sistema puede estar ms o menos acoplado. Se entiende por acoplamiento del software a la integracin que tengan los elementos software que existan en cada nodo. Gran parte de la integracin del sistema la produce la comunicacin entre los nodos y es por esta razn por la que se define el acoplamiento; otra parte es la que implica que tan crtico es el software y su capacidad de recuperacin ante fallas. Es importante mencionar que depende que el sistema se encuentre centralizado o distribuido. En cualquiera de los dos casos el acoplamiento es una medida subjetiva basada en la integracin de un sistema a nivel general de cluster. Se distinguen entre 3 tipos de acoplamiento: ! Acoplamiento fuerte

Para esta categora se tiene software cuyos elementos se interrelacionan mucho unos con otros y posibilitan la mayora de las funcionalidades del cluster de manera altamente cooperativa. El caso de acoplamiento ms fuerte que se puede dar es que solamente haya una imagen del Kernel del sistema operativo,


8

distribuida entre un conjunto de nodos que la compartirn. Por supuesto algo fundamental es poder acceder a todas las partes de este sistema operativo, estrechamente relacionadas entre s y distribuidas entre los nodos. Este caso es el que se considera como ms acoplado, de hecho no est catalogado como cluster, sino como sistema operativo distribuido. Otro ejemplo son los cluster SSI (Single System Image), en estos cluster los nodos ven una misma imagen del sistema, pero los nodos tienen su propio sistema operativo, aunque estos sistemas estn estrechamente relacionados para dar la sensacin a las aplicaciones que los nodos son idnticos y se acceda de una manera homognea a los recursos del sistema total. Si ejecuta una aplicacin, sta ver un sistema homogneo, por lo tanto los Kernels tienen que conocer los recursos de otros nodos para presentarle al sistema local los recursos que encontrara si estuviera en otro nodo. Es necesario un sistema de nombres nico, manejado de sistema distribuida o centralizada y un mapeo de los recursos fsicos a este sistema de nombres. Figura 1.4.

Figura 1.4. Acoplamiento fuerte

! Acoplamiento medio

A este grupo pertenece un Software que no necesita un conocimiento tan exhaustivo de los recursos de otros nodos, pero que sigue usando el Software de otros nodos para aplicaciones de muy bajo nivel. Como es el caso de OpenMosix y Linux-HA. Un cluster OpenMosix necesita que los Kernels sean de la misma versin. Por otro lado no est tan acoplado como el caso anterior: no necesita un sistema de nombres comn en los nodos, y su capacidad de dividir los procesos en una parte local y otra remota consigue que por un lado se necesite el Software del


9

otro nodo donde est la parte del archivo que falta en el nodo local y por otro que no se necesite un SSI para hacer otras tareas. Figura 1.5.

Figura 1.5. Acoplamiento medio

Acoplamiento dbil

Generalmente se basan en aplicaciones construidas por bibliotecas preparadas para aplicaciones distribuidas. Es el caso de PVM, MPI o CORBA. stos por s mismos no funcionan en modo alguno con las caractersticas que antes se han descrito (como Beowulf) y hay que dotarles de una estructura superior que utilice las capacidades del cluster para que ste funcione. Figura 1.6. (miKel & Buytaert, 2004).

Figura 1.6. Acoplamiento dbil


10

1.4. Esquema y otras caractersticas Las caractersticas bsicas de un cluster de carcter general se resumen en el siguiente esquema:

1. Un cluster consta de 2 o ms nodos conectados entre s por un canal de comunicacin funcional.

2. En cada nodo es imprescindible un elemento de proceso, memoria y un interfaz

para comunicarse con la red del cluster. 3. Los cluster necesitan software especializado. Este software y las computadoras

conforman el cluster. El software puede ser:

a. Aplicacin b. Sistema

4. Se define acoplamiento de un cluster como nivel de colaboracin que une los elementos del cluster. De este modo se clasifican en:

a. Acoplamiento fuerte b. Acoplamiento medio o moderado c. Acoplamiento dbil

5. Todos los elementos del cluster trabajan para cumplir una funcionalidad conjunta, sea esta la que sea. Es la funcionalidad la que caracteriza el sistema.

Adems de las presentadas anteriormente se agregan otra serie de caractersticas necesarias: ! Mejora sobre la disponibilidad ! Mejora del rendimiento

En general la manera de catalogar a los cluster se hace en base a cuatro factores de diseo bastante ortogonales entre s: ! Acoplamiento (definido anteriormente en el inciso 1.3) ! Control ! Homogeneidad ! Seguridad

1.4.1. El factor de control del cluster El parmetro de control implica el modelo de gestin que propone el cluster. Este modelo de gestin hace referencia a la manera de configurar el cluster y es dependiente del modelo de conexionado o colaboracin que surgen entre los nodos. Puede ser de dos tipos:


11

! Control centralizado: se hace uso de un nodo maestro desde el cual se puede configurar el comportamiento de todo el sistema. Este nodo es un punto crtico del sistema aunque es una ventaja para una mejor gestin del cluster.

! Control descentralizado: en un modelo distribuido donde cada nodo debe administrarse y gestionarse. Tambin pueden ser gestionados mediante aplicaciones de ms alto nivel de manera centralizada, pero la mayora de la gestin que hace el nodo local es leer archivos de configuracin de su propio nodo.

1.4.2. Seguridad

Es propio de sistemas distribuidos, como ventaja tiene que presenta ms tolerancia a fallas como sistema global y como desventajas que la gestin y administracin de los equipos requiere ms tiempo.

1.4.3. Homogeneidad En la homogeneidad de un cluster se ha demostrado que es posible crear sistemas de una sola imagen o heterogneos con una implementacin prctica. En cualquier caso, hay que entender por homogeneidad del cluster a la homogeneidad de los equipos y recursos que conforman a ste. Los cluster heterogneos son ms difciles de conseguir ya que se necesitan notaciones abstractas de transferencias e interfaces especiales entre los nodos para que stas se entiendan, por otro lado los cluster homogneos obtienen ms beneficios de estos sistemas y pueden ser implementados directamente a nivel de sistema (miKel & Buytaert, 2004). 1.4.3.1. Homogeneidad de un cluster ! Homogneos: estn formados por equipos de la misma arquitectura. Los nodos

tienen una arquitectura y recursos similares, de manera que no existen muchas diferencias entre cada nodo.

! Heterogneos: formados por nodos con distinciones que pueden estar en los siguientes puntos.

o Tiempos de acceso distintos o Arquitectura distinta o Sistema operativo distinto o Rendimiento de los procesadores o recursos sobre una misma

arquitectura distintos El uso de arquitecturas distintas o distintos sistemas operativos, impone que exista una biblioteca que haga de interfaz, e incluso una sintaxis de notacin abstracta del tipo ASN.1 o XDR en la capa de presentacin que utilice la interfaz de comunicacin de


12

nuestro sistema distribuido o cluster. Esto hace que este tipo de cluster se consideren implementados a nivel de aplicacin. Existen otros factores de diseo que limitan el comportamiento y modelado de un cluster. La imposibilidad de llegar a cluster que paralelicen cualquier proceso se basa en que la mayora de las aplicaciones hacen uso, en mayor o menor medida, de algoritmos secuenciales no paralelizables (Hwang & Xu, 1998). 1.5. Clasificacin de los cluster Los cluster son diseados para dar solucin a problemas donde apliquen una mejora en rendimiento, el costo de implementar un cluster comparndolo con el de adquirir un Mainframe es realmente accesible y el rendimiento que proporciona un cluster puede llegar a ser igualado. Por otro lado esta la distribucin de riesgos. La mayora de los usuarios tienen sus servicios, aplicaciones, bases de datos o recursos en una sola computadora o son dependientes de una sola computadora. Otro aspecto importante es colocar las bases de datos replicadas sobre sistemas de archivos distribuidos de manera que estos no se pierdan por que los datos son un recurso importante. Actualmente el mercado de la informtica exige no solo que los datos sean crticos sino que los servicios estn activos constantemente. Esto exige medios y tcnicas que permitan que el tiempo en el que una computadora est inactiva sea el menor posible. La distribucin de factores de riesgo a lo largo de un cluster (o la distribucin de funcionalidades en casos ms generales) permite de una forma nica obtener la funcionalidad de una manera ms confiable: si una computadora cae otras podrn dar el servicio.

Por ltimo est el factor de escalabilidad, cuanto ms escalable es un sistema menos costar mejorar el rendimiento, lo cual abarata el costo y en el caso de que el cluster lo implemente distribuye ms el riesgo de cada de un sistema (Coulouris & Dollimore, 2003).

1.5.1. Alto rendimiento (HP High Performance)

Los cluster de alto rendimiento han sido creados para compartir el recurso ms valioso de una computadora, es decir, el tiempo de proceso. Cualquier operacin que necesite altos tiempos de CPU puede ser utilizada en un cluster de alto rendimiento, siempre que se encuentre un algoritmo que sea paralelizable (ejecucin de distintas actividades desde procesadores diferentes).

Existen cluster que pueden ser denominados de alto rendimiento tanto a nivel de sistema como a nivel de aplicacin. A nivel de sistema tenemos OpenMosix, mientras que a nivel de aplicacin se encuentran otros como MPI, PVM, Beowulf, entre otros. En cualquier caso, estos cluster hacen uso de la capacidad de procesamiento que pueden tener varias computadoras (Coulouris & Dollimore, 2003).


13

1.5.1.1. Problemas que solucionan

Generalmente estos problemas de cmputo estn ligados a:

Clculos matemticos Renderizaciones de grficos (generacin de grficos vectoriales) Compilacin de programas Compresin de datos Descifrado de cdigos Rendimiento del sistema operativo (incluyendo, el rendimiento de los recursos de

cada nodo)

Existen otros problemas que se pueden solucionar con cluster 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 (Fink & Sherer, 2003).

1.5.1.2. Tcnicas que utilizan

Las tcnicas utilizadas dependen de a qu nivel trabaje el cluster.

Los cluster implementados a nivel de aplicacin no implementan balanceo de carga. Los cluster basar todo su funcionamiento en una poltica de localizacin que sita las tareas en los diferentes nodos del cluster y las comunica mediante las libreras abstractas. Resuelven problemas de cualquier tipo, pero se deben disear y codificar aplicaciones propias para cada tipo para poderlas utilizar en estos cluster.

Por otro lado estn los sistemas de alto rendimiento implementados a nivel de sistema. Estos cluster basan su funcionamiento en comunicacin y colaboracin de los nodos a nivel de sistema operativo, lo que implica generalmente que son cluster de nodos de la misma arquitectura, con ventajas en lo que se refiere al factor de acoplamiento y que basan su funcionamiento en compartir los recursos a cualquier nivel, balanceo de la carga de manera dinmica, funciones de planificacin especiales y otros tantos factores que componen el sistema. Se acerca a sistemas SSI (Single System Image), 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 llega a un factor de compromiso.

Entre las limitaciones que existen actualmente est la incapacidad de balancear la carga dinmica de las libreras PVM o la incapacidad de OpenMosix de migrar procesos que hacen uso de memoria compartida. Una tcnica que obtiene mayor ventaja es cruzar ambos sistemas: PVM + OpenMosix. Se obtiene un sistema con un factor de acoplamiento elevado que presta las ventajas de uno y otro, con una pequea limitacin por desventajas de cada uno (Fink & Sherer, 2003).


14

1.5.2. Alta disponibilidad (HA High Availability)

Los cluster de alta disponibilidad son bastante ortogonales en lo que se refieren a funcionalidad a un cluster de alto rendimiento.

Pretenden dar servicios de cualquier tipo los 365 das del ao, son cluster donde la principal funcionalidad es estar controlando y actuando para que un servicio u otros se encuentren activos durante el mximo periodo de tiempo posible. En estos casos se puede comprobar como la monitorizacin de otros es parte de la colaboracin entre los nodos del cluster.

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 cluster de alta disponibilidad han sido diseados para la mxima disponibilidad sobre los servicios que presenta el cluster. Este tipo de cluster es 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 cluster de este tipo se implementan en base a tres factores: ! Fiabilidad ! Disponibilidad ! Dotacin de servicio

Mediante estos tres tipos de actuaciones y los mecanismos que lo implementan se asegura que un servicio est el mximo tiempo disponible y que ste funcione de una manera fiable. Respecto al tercer punto, se refiere a la dotacin de uno de estos cluster de un servicio que provea a clientes externos (miKel & Buytaert, 2004). 1.5.2.1. Problemas que solucionan La mayora de estos problemas estn ligados a la necesidad de dar servicio continuo de cualquier tipo a una serie de clientes de manera ininterrumpida. En una construccin real se producen fallas inesperadas en las computadoras, estas fallas 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: ! Sistemas de informacin redundante ! Sistemas tolerantes a fallas ! Balanceo de carga entre distintos servidores ! Balanceo de conexiones entre distintos servidores

En general estos problemas se ligan en dos fuentes de necesidad de las empresas u organizaciones:


15

! Tener un servicio disponible ! Ahorrar econmicamente todo lo que sea posible

El servicio puede ser diverso. Desde un sistema de archivos distribuidos de carcter muy barato, hasta grandes cluster 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 cluster e implementar mecanismos para hacer que esta obtenga la mayor disponibilidad posible (miKel & Buytaert, 2004). 1.5.2.2. Tcnicas que utilizan Como se ha estado mencionando los servicios y el funcionamiento de los mismos son de carcter distinto, en cualquier caso, se proponen 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 contienen 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 que pueden ser desarrollados hasta crear sistemas complejos especializados para cada entorno particular. En cualquier caso, las tcnicas de estos sistemas se basan en excluir del sistema aquellos puntos crticos que pueden producir una falla y por lo tanto la prdida de disponibilidad de un servicio. Para esto se implementan desde enlaces de red redundantes hasta disponer de N computadoras para hacer una misma tarea de manera que si caen N-1 computadoras el servicio permanece activo sin prdida de rendimiento. 1.5.3. Alta confiabilidad (HR High Reliability) Por ltimo, estn los cluster de alta confiabilidad. Estos cluster tratan de aportar la mxima confiabilidad en un entorno, en la cual se necesite saber que el sistema se va a comportar de una manera determinada. Puede tratarse por ejemplo de sistemas de respuesta en tiempo real. Este tipo de cluster son los ms difciles de implementar. No se basan solamente en conceder servicios de alta disponibilidad, sino en ofrecer un entorno de sistema altamente confiable. Esto implica demasiada sobrecarga en el sistema, son tambin cluster muy acoplados. Dar a un cluster SSI capacidad de alta confiabilidad implica gastar recursos necesarios para evitar que aplicaciones interrumpan su funcionalidad. En los cluster de alta disponibilidad generalmente una vez que el servicio ha cado ste se relanza, y no existe manera de conservar el estado del servidor anterior, ms que mediante puntos de parada o checkpoints, pero que en conexiones en tiempo real no son suficientes. Por otro lado, los cluster confiables tratan de mantener el estado de las


16

aplicaciones, no simplemente de utilizar el ltimo checkpoint del sistema y relanzar el servicio. Generalmente este tipo de cluster se utiliza para entornos de tipo empresarial y esta funcionalidad solamente puede ser efectuada por Hardware especializado. Por el momento no existe ninguno de estos cluster implementados como Software. Esto se debe a limitaciones de la latencia de la red, as como a la complejidad de mantener los estados. Se hacen necesarias caractersticas de cluster SSI, tener un nico reloj de sistema conjunto y otras ms. Dada la naturaleza asncrona actual en el campo de los cluster, este tipo de cluster an ser difcil de implementar hasta que no se abaraten las tcnicas de comunicacin (miKel & Buytaert, 2004). 1.6. Tecnologas similares a cluster tipo Beowulf Adicionalmente a los Cluster tipo Beowulf, existen las siguientes tecnologas similares: MOSIX. Esta tecnologa basada en Linux, permite realizar balance de carga para procesos particulares en un cluster. Trabaja como un Cluster de Alto Rendimiento en el sentido de que est diseado para tomar ventaja del hardware ms rpido disponible en el cluster para cualquier tarea que le sea asignada; pero, lo realiza balanceando la carga de las distintas tareas en varias computadoras. Una de las grandes ventajas de MOSIX es que no requiere la elaboracin de Software especial como lo requiere los cluster tipo Beowulf. Los usuarios ejecutan sus programas normalmente y el sistema MOSIX se encarga del resto. Otra tecnologa de cluster es el paquete Piranha, que permite a los servidores Linux proveer alta disponibilidad sin la necesidad de invertir cantidades mayores en Hardware. La tecnologa de cluster es basado completamente en Software, donde los servidores se comunican en una red de alta velocidad. Se puede configurar para trabajar como Cluster de Alta Disponibilidad o de Balance de Carga. El Piranha puede configurar un servidor de respaldo en caso de falla de la contraparte. Tambin puede hacer que el cluster aparezca como un servidor virtual (Beowulf,2003). 1.7. Estado del arte A continuacin se listan los centros de trabajo donde se encuentran implementados cluster tipo Beowulf de alto rendimiento en el pas:

1. Implementacin de Sistemas de Cmputo de Alto Rendimiento de Aplicaciones Cientficas en la Universidad de Sonora

Tiene como objetivos:


17

! Formar personal en construccin de Clusters de PCs con el sistema operativo Linux, para apoyar las actividades de Supercmputo en la Universidad de Sonora

! Apoyar la investigacin interdisciplinaria en Ciencias de la Computacin, Fsica y Matemticas Computacionales, y Geocomputacin

! Desarrollar sistemas de cmputo distribuido de apoyo acadmico al rea de Redes y Sistemas Distribuidos de la Licenciatura en Ciencias de la Computacin de la Universidad de Sonora (Lizarraga, 2002).

Metas ! Construir Clusters Clase Beowulf de aplicaciones cientficas en la Universidad de

Sonora ! Integrar bibliotecas de software de fuente abierta de aplicaciones cientficas ! Formar estudiantes de Ciencias de la Computacin del rea de Sistemas

Distribuidos en Clusters Cuenta con un grupo de apoyo en Supercmputo en las reas de Ciencias e Ingeniera (Lizarraga, 2002). Se colaborar en el ACARUS de la Direccin de Investigacin y Postgrado de la Universidad de Sonora en los siguientes proyectos: ! Instalacin y configuracin de las bibliotecas MPI en el sistema Digital UNIX de

multiprocesadores, para aplicaciones de cmputo paralelo ! Construccin de la biblioteca de software libre de fuente abierta de aplicaciones

de supercmputo ! Construccin y configuracin del Cluster ACARUS tipo Beowulf de 16 nodos ! Dar apoyo en soporte de cmputo acadmico, para la migracin de programas al

Cluster Beowulf (Lizarraga,2002).

2. Universidad Autnoma de Baja California Instituto de Investigaciones Oceanolgicas. Cluster UABC

Objetivos: El CICESE y la UABC se unan a la iniciativa hecha por la Cmara Nacional de la Industria Electrnica, de Telecomunicaciones e Informtica (CANIETI) y el Colegio de Profesionales de Tecnologas de Informacin en Baja California (CPTI) para desarrollar un cluster de software en el estado (Velsquez, 2004). La vinculacin con organismos empresariales nacionales e internacionales y la participacin en las decisiones de la industria son objetivos de la cmara de Tecnologas de Informacin de la CANIETI. El Hardware que utiliza es de un cluster de 26 procesadores (duales): ! 16 de ellos Pentium III a 550MHz con 256MB RAM y Fast Ethernet ! 10 de ellos Pentium III a 600MHZ con 512MB RAM y Fast Ethernet

Facultad de Ciencias


18

! Cluster de 5 Dual-Penitum II a 550MHz con 256 MB RAM y Fast Ethernet Facultad de Ingeniera

! Cluster de 5 Dual-Penitum II a 550MHz con 256 MB RAM y Fast Ethernet Conectados con switches de 16 puertos y 24 puertos.

3. Instituto de Fsica, UNAM Este proyecto es responsable de la implementacin, desarrollo y operacin de un cluster de computadoras paralelas de clase Beowulf dividido en dos subclusters, uno de ellos integrado por 16 nodos con 32 procesadores Pentium III y el otro por 4 nodos con 8 procesadores Alpha. Ambos proporcionan una capacidad total de supercmputo de gigaflops (Moreno, 2000). El cluster es utilizado por investigadores y estudiantes del IFUNAM para el estudio de temas de frontera en fsica y temas afines (Moreno, 2000). Software El software de cada una de los clusters fue preinstalado por el distribuidor, el cual bsicamente es el sistema operativo GNU/Linux Red Hat con algunas modificaciones al kernel para un mejor desempeo y bibliotecas MPICH, MPI LAM y PVM para programacin en paralelo. Tiene instalado software principalmente para la administracin del cluster y el compilador de Fortran de absoft, absoft es conocido por sus series de compiladores de alto desempeo en clusters de computadoras (Moreno, 2000).

4. El Instituto de Astronoma de la UNAM Tiene implementado un cluster de nombre Emong, es un cluster tipo Beowulf, el uso es principalmente para la simulacin hidrodinmica por el Grupo Terico de Estrellas de Neutrones, el Hardware que se implemento esta conformado por 20 CPUs Pentium III con una velocidad de 450 Mhz (Lizarraga, 2002).

5. El departamento de Matemticas y Mecnica del IIMAS de la UNAM Tiene implementado un cluster tipo Beowulf, este cluster es utilizado para ejecutar aplicaciones de alto rendimiento utilizando, el Hardware que se implemento esta formado por 5 nodos con 2 procesadores Pentium III a 750 Mhz cada uno y con 256 MB de RAM, el sistema operativo que se utiliza es Linux RedHat 7.1 con kernel 2.4.2. (supercomputo, 2003). En un apartado denominado ANEXO 1, se incluyen los conceptos bsicos de los Cluster, clasificados por tipos de cluster, definiciones bsicas, cmputo paralelo y componentes de los cluster.

2. CLUSTER DE APLICACIN.

19

2. CLUSTER DE APLICACIN. 2.1. Conceptos de Migracin y Balanceo Los clusters de Alto Rendimiento (HP) estn dedicados a dar el mayor rendimiento computacional posible y existen diversas formas de implementarlos. Las implementaciones se dividen en soluciones que funcionan a nivel de aplicacin y a nivel de Kernel. Las implementaciones que funcionan a nivel de aplicacin se presentan en forma de librera. Se realizan programas donde se reutiliza el cdigo ya existente y para mejorar su rendimiento se reescribe alguna parte. Este tipo de implementaciones presentan diversos inconvenientes, entre los cuales se mencionan:

La variedad de las aplicaciones que necesitan grandes tiempos de cmputo se realizaron hace dcadas en lenguaje Fortran

Los programas existentes enfocados a aplicaciones matemticas fsicas, son

difciles de comprender

La migracin es difcil en el nuevo entorno distribuido Por otro lado una ventaja de implementarse es:

Son econmicos respecto a las supercomputadoras En las implementaciones que funcionan a nivel de Kernel, es el Software el que se encarga del HP; para este caso no se necesitan cambiar las aplicaciones del usuario, ya que internamente el Kernel es le que se encarga de distribuir el trabajo de forma que resulte transparente para la aplicacin (Barroso & at all, 2003). Las desventajas que se tienen son:

El Kernel se vuelve complejo y esta expuesto a fallas

Las soluciones son especficas de un Kernel, esto indica que si las aplicaciones no estn diseadas para el sistema operativo para el que fue elaborado tendr fallas

La ventaja radica en que no hay necesidad de una inversin econmica para cambiar aplicaciones, ya que cualquier aplicacin puede ser distribuida, un factor que hay que considerar de manera permanente es la programacin de la aplicacin.


20

Existen dos formas que permiten conseguir que los HP migren procesos, dividir las aplicaciones grandes en procesos y ejecutar cada proceso en un nodo distinto, logrando el mximo uso de los recursos en todo momento, especialmente con los procesadores:

1. Asignar estticamente cada proceso a un nodo en particular

Para esta forma es importante saber la localizacin. Se elige estticamente el nodo donde el proceso estar en uso, esto implica saber elegir el o los nodos; la mayora de las veces esto implicara que se requiera de un administrador, el cual decidir donde debe ir cada proceso. Un caso considerado como simple es tener los nodos con la misma potencia de clculo y dividir el nico programa al que se quiera dedicar los recursos en un nmero de procesos que debe ser igual al nmero de nodos con los que se disponen. De esa forma se asignara cada proceso a uno de los nodos. Es importante que se tome en cuenta que esta configuracin resulta lejana a lo normal y que una falla en el algoritmo de eleccin de nodo puede inutilizar diversos recursos, la configuracin manual es algo habitual en estos algoritmos. Cuando se utiliza este tipo de proceso, teniendo la configuracin inicial se pretende que los procesos estn ejecutndose durante aos si as se requiere.

2. Asignar dinmicamente procesos a los nodos

Los procesos una vez iniciados en un nodo pueden migrar a otro nodo dinmicamente. En estos tambin es importante la poltica de localizacin para minimizar el gasto de recursos, as como la poltica de migracin. Esto facilita ubicar los procesos manualmente, con la ventaja de que se puede ubicar en cualquier momento durante el tiempo de ejecucin del proceso. Si la poltica de migracin es correcta y los procesos tienen una vida larga y se ha dividido correctamente la aplicacin, debera haber al comienzo de la ejecucin de los procesos un periodo de reordenacin de los procesos, con varias migraciones, una vez el sistema llegara a una condicin estable, no deberan producirse apenas migraciones hasta que los procesos finalizaran. Igual que ocurre en el caso anterior, esta configuracin es lejana a la habitual, pero al contrario del caso anterior, aqu no es necesaria la configuracin manual (si el algoritmo de migracin es suficientemente bueno). Cuando se desbalancea el sistema ste se encarga de que se vuelva a balancear, de tal forma de que se aprovechen los recursos al mximo. Por tanto estos algoritmos intentan tener un fundamento matemtico fuerte que intenta minimizar el tiempo de cmputo. Estos sistemas usan fundamentos estadsticos, como por ejemplo openMosix.

OpenMosix intenta maximizar el uso de los recursos. Intentar solamente balancear respecto al procesador puede dar lugar a decisiones errneas, porque se pueden enviar procesos que no hagan mucho uso del procesador a uno de los nodos, si estos


21

procesos estn haciendo entrada/salida y son procesos grandes, es muy posible que el nodo empiece a hacer trashing e implicara quedarse sin memoria, con lo que los procesos no podrn ejecutar su funcin (Byna& ALL, 2003). En la tabla 2.1 se muestran las posibles formas que existen para clusters. Con ello se listan las diversas posibilidades de decidir que es lo que se hace cuando se implementa un cluster de este tipo.

Tabla 2.1. Clusters HP. Aspectos de implementacin Tema Problemas que genera

Sin requisa de procesos Mayor latencia para procesos de alta prioridad Con requisa de procesos Sobrecarga, implementacin compleja Balanceo esttico Mal balanceo de carga Balanceo dinmico Sobrecarga, implementacin compleja Nivel de aplicacin Sobrecarga, falta de informacin Nivel de Kernel Dificultad de implementacin Nodos dedicados Infrautilizacin de recursos Nodos comparten espacio Se necesita una poltica eficiente de localizacin Nodos comparten tiempo Sobrecarga cambio de contexto Scheduling independiente Prdida de rendimiento Scheduling de grupo Implementacin compleja Con carga externa, quedarse Prdida de rendimiento en trabajos locales Ante carga externa, migrar Sobrecarga de migracin, lmites de migracin

Requisa se refiere a poder parar el proceso y tomar sus recursos (bsicamente los registros del procesador y memoria). La requisa de los procesos puede existir o no. Cuando un sistema es multitarea normalmente se implementa algn sistema de requisa para poder parar procesos y hacer que otros procesos tomen el procesador para dar la sensacin al usuario de que los procesos se estn ejecutando concurrentemente. Si no se implementa requisa, un proceso de baja prioridad puede tomar el procesador y otro proceso de alta prioridad no podr tomarlo hasta que el proceso de baja prioridad lo ceda a otros procesos. Este esquema puede ser injusto con las prioridades y un error en un programa, puede llegar a dejar sin funcionar la computadora pues nunca devolvera el control, pero tampoco hara ningn trabajo til. Adems para sistemas que necesitan tiempo real, simplemente es inaceptable que procesos de baja prioridad estn dejando a los procesos de tiempo real sin tiempo de procesador y quizs con esta latencia extra se est haciendo que el sistema no pueda cumplir sus operaciones en tiempo real, haciendo que el sistema sea intil. Hoy en da la requisa se implementa al menos a un nivel elemental en los sistemas que necesiten hacer funcionar ms de un proceso.


22

Algunos sistemas lo que hacen es no esperar a que cumpla un temporizador y realizar la requisa sino a esperar que el proceso haga alguna llamada al sistema para aprovechar, tomar el procesador y cederlo a otro proceso. Esta aproximacin sigue teniendo el problema de que si un proceso maligno o mal programado no hace llamadas a sistema porque haya quedado en un bucle, nunca se ejecutar nada en ese ambiente. Si se implementa la requisa hay que tener en cuenta que la implementacin ms simple que se puede dar necesita un temporizador que marque cuando se acab el tiempo del proceso y requisar ese proceso para asignar a otro proceso. Esto impone una sobre carga pues hay que tratar una interrupcin, actualizar unas variables para saber cuanto tiempo lleva un proceso trabajando. Hay una implementacin ms compleja que trata de que siempre que haya un proceso de una prioridad mayor al que se est ejecutando se quite el procesador al proceso y se d el procesador al proceso con mayor prioridad. Estos son sistemas en tiempo real que tambin pueden tener otras exigencias como tiempos mnimos de latencia para ciertos procesos. Para conseguir esto, el Kernel no solamente tiene que requisar procesos de baja prioridad en favor de los procesos de tiempo real sino que tiene que ser capaz de requisar su propio cdigo. Esto puede significar cualquier porcin del cdigo del Kernel se pueda ejecutar entre dos instrucciones de este mismo cdigo. Esto presenta problemas a la hora de programar, se tiene que evitar condiciones de carrera dentro del propio Kernel que antes por ser cdigo no requisable no se podan dar. Por tanto implementar requisa, puede hacer que un sistema sea tiempo real pero complica tremendamente el ncleo del sistema. (miKel & Buytaert, 2004) Las siguientes tres lneas de la tabla 2.1 tratan sobre los recursos del cluster, estos son los nodos. Existen tres modos en los que se puede dedicar los nodos del cluster, estos modos son: a) Modo dedicado Con este modo solamente es asignado a un nodo en cualquier momento un trabajo est siendo ejecutado en el cluster y solo un proceso se est ejecutando, este trabajo no liberar el cluster hasta que acabe completamente aun cuando solo quede un proceso por ejecutarse. Los recursos se dedican a este trabajo, esta forma de uso de un cluster lleva a una prdida importante de potencia sobre todo si no todos los nodos acaban el trabajo al mismo tiempo. b) Modo de divisin en el espacio Con este modo, n-trabajos se pueden ejecutar en distintas particiones del cluster los cuales son considerados como grupos de nodos. Un proceso puede estar asignado a un cluster, las particiones se dedican a un trabajo, la interconexin y el sistema de entrada/salida pueden estar compartidos por los trabajos, logrando aprovechar los recursos. Los grupos de los nodos son estticos y los programas para ejecutarse necesitan un nmero especfico de nodos, teniendo con ello por consideraciones:


23

Puede haber trabajos donde no haya una divisin lo suficientemente grande por lo cual no puedan ser ejecutados

Puede haber trabajos donde se aprovechen nodos y desperdiciando una divisin

considerable de nodos. Para evitar esto se tienen que usar tcnicas para ser elegidos los nodos donde se ejecutaran los trabajos, esto para minimizar el nmero de nodos ociosos

Tambin puede ocurrir que un trabajo muy largo tome los recursos del cluster

evitando que otros trabajos ms rpidos acaben, esto consigue aumentar la latencia

c) Modo de divisin en el tiempo En cada nodo pueden estar ejecutndose diversos procesos a la vez por lo que se solucionan los problemas anteriores. Este es el modo ms usado normalmente ya que no tiene tantas restricciones como el modo de divisin en el espacio y si se eligen correctamente los procesos se pueden equilibrar (miKel & Buytaert, 2004). Los dos siguientes puntos de la tabla 2.1. tratan sobre scheduling, esta planificacin solo se da cuando el modo que se ha elegido es el modo de divisin en el tiempo. Hay dos tipos de scheduling en cuanto a clusters se refiere:

1. Scheduling independiente

Es el caso ms sencillo y ms implementado, se usa un sistema operativo en cada nodo del cluster para hacer scheduling de los distintos procesos en un nodo tradicional, esto tambin es llamado scheduling local. Sin embargo, el rendimiento de los trabajos paralelos que est llevando a cabo el cluster puede verse degradado en gran medida. Cuando uno de los procesos del trabajo paralelo quiera hacer cualquier tipo de interaccin con otro proceso como sincronizarse con l, puede suceder que este proceso no est ejecutndose en esos momentos y que an se tarde un tiempo hasta que se ejecute por otro tanto de tiempo. Esto quiere decir que el primer proceso tendr que esperar y cuando el segundo proceso est listo para interactuar quizs el primer proceso est en swap y tenga que esperar a ser elegido otra vez para funcionar. (miKel & Buytaert, 2004)

2. Scheduling de grupo

Cuando uno de los procesos est activo, todos los procesos estn activos. Este tipo de scheduling puede aumentar el rendimiento en uno o dos puntos de magnitud. Los nodos del cluster no estn perfectamente sincronizados. De hecho, la mayora de los clusters son sistemas asncronos (que no usan el mismo reloj).


24

Para lograr los resultados de rendimiento se debe dejar que los procesos se ejecuten de forma continua por un tiempo considerable en su defecto la diferencia que exista entre la ejecucin de un proceso y el ltimo sea relativamente corto (miKel & Buytaert, 2004).

Por tanto hacer scheduling en un cluster grande, siendo el scheduling una operacin compleja y que tiene que estar optimizada al mximo es una operacin bastante difcil de lograr, se necesitara la informacin de los nodos para tomar buenas decisiones, esto implicara contar con redes rpidas. Las dos ltimas filas de la tabla 2.1. se refieren a que se trata de que deben hacer los procesos cuando se encuentran que en su nodo local ya que hay otros procesos que provienen de otros nodos. Estos pueden venir por alguna poltica de migracin o porque se est ejecutando el scheduler de grupo. Los trabajos locales podran tener prioridad sobre trabajos externos, por decir los procesos de usuario interactivos donde no se quiere que se degrade el rendimiento deben mantener mayor prioridad. Hay dos formas de tratar esta situacin:

a) El trabajo externo migra: si el proceso migra, el proceso puede ir a un nodo donde se ejecute de forma ms eficiente.

b) El trabajo externo se mantiene en el cluster: si el proceso se mantiene en el

nodo donde se encuentra se evita la sobrecarga que conlleva la migracin, para no afectar a los procesos de ese nodo se les da muy poca prioridad (miKel & Buytaert, 2004).

2.1.2. PVM (Parallel Virtual Machine) y MPI (Message Passing Interface) Hay diferentes formas de hacer procesamiento paralelo, entre las ms conocidas y usadas se encuentran: NUMA, PVM y MPI.

Las computadoras de tipo NUMA (Non-Uniform Memory Access) tienen acceso compartido a la memoria donde pueden ejecutar su cdigo de programa. En el Kernel de Linux hay ya implementado NUMA, que hace variar el nmero de accesos a las diferentes regiones de memoria.

PVM/MPI son herramientas que han estado ampliamente utilizadas y son muy conocidas por la gente que entiende de supercomputacin basada en GNU/Linux.

MPI es el estndar abierto de bibliotecas de paso de mensajes. MPICH es una de las implementaciones ms usadas de MPI, tras MPICH se puede encontrar LAM, otra implementacin basada en MPI tambin con bibliotecas de cdigo abierto.

PVM es una variante de MPI que tambin es ampliamente usado para funcionar en entornos Beowulf.


25

PVM habita en el espacio de usuario y tiene la ventaja que no hacen falta modificaciones en el Kernel de Linux, bsicamente cada usuario con derechos suficientes puede ejecutar PVM (Carns& all, 2000). 2.1.3. Paso de mensajes PVM como MPI se basan en el concepto de paso de mensajes. Los mensajes son pasados entre los procesos para conseguir que se ejecuten de manera colaborativa y de forma sincronizada. Los mensajes se pueden implementar de una forma efectiva en un cluster, los mensajes se envan en forma de paquete IP y la computadora destino desempaqueta el mensaje decidiendo a que proceso va dirigido. Una vez hecho esto, enva la informacin al proceso en cuestin. 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 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


26

mensaje que se debe recibir. El mensaje puede que no haya llegado an, puede estar todava en transito o puede no haber sido enviado an (Carns& all,2000).

2.2. 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 computadoras para aprovechar los recursos. Cada tarea es responsable de una parte de la carga que conlleva esa aplicacion. 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 computadora virtual, enviando y recibiendo mensajes, muchas tareas de una aplicacin puedan cooperar 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 los nodos que forman parte de la computadora virtual. Cuando un usuario quiere ejecutar una aplicacin PVM, primero crea una computadora virtual para arrancar PVM. Entonces se puede ejecutar la aplicacin PVM en cualquiera de los nodos. Los usuarios pueden configurar varias computadoras 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 computadora 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 computadora 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 una gran computadora de memoria distribuida llamada computadora virtual. Esta computadora virtual es creada por el


27

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 computadora virtual. Esto puede ser de gran ayuda para mejorar la tolerancia a fallas ya que se tienen nodos de reserva (PVM no tiene migracin) por si alguno de los nodos fallara. 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, se pueden hacer aplicaciones con la arquitectura al mximo por lo que se puede optimizar y hacer que funcionen aplicaciones hechas para arquitecturas especficas con PVM.

Computadoras: nodos con distintos formatos de datos estn soportados,

incluyendo arquitecturas secuenciales, vectoriales, SMP. Abstrae little endian y big endian.

Redes: la computadora 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.

PVM tiene un conjunto de interfaces que est basado en la observacin de las necesidades de la mayora de las aplicaciones, que estn escritas en C y Fortran. Los enlaces para C y C++ para la librera PVM estn implementados como funciones, siguiendo las reglas usadas por la mayora de los sistemas que usan C, incluyendo los sistemas operativos tipo UNIX. Los enlaces para Fortran estn implementados como subrutinas ms que funciones. Todas las tareas estn identificadas con un nico identificador de tarea TID (Task IDentifier). Los mensajes son enviados y recibidos por TIDs. Son nicos en toda la computadora virtual y estn determinados por el pvmd local y no se pueden elegir por el usuario. Varias funciones devuelven estos TIDs (pvm_mytid(), pvm_parent(), etc.) para permitir que las aplicaciones de los usuarios conozcan datos de las otras tareas. Existen grupos nombrados por los usuarios, que son agrupaciones lgicas de tareas. Cuando una tarea se une al grupo, a sta se le asigna un nico nmero dentro de ese grupo. Estos nmeros empiezan en 0 y hasta el nmero de tareas que disponga el grupo. Cualquier tarea puede unirse o dejar cualquier grupo en cualquier momento sin tener que informar a ninguna otra tarea del grupo. Los grupos se pueden superponer y las tareas pueden enviar mensajes multicast a grupos de los que no son miembro. 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 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


28

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 que es ms sencillo, slo consume un descriptor de archivo y con un simple socket UDP se puede comunicar a los dems demonios. Adems resulta sencillo colocar temporizadores sobre UDP para detectar fallas 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 transferencia sta es TCP por lo que hay que establecer la conexin primero por lo que resulta no ser benfico. En la figura 2.1. se observan los distintos mtodos de comunicacin de PVM. Cada nodo tiene una estructura llamada host table. Esta tabla tiene una entrada (host descriptor) por cada nodo de la computadora 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 computadora virtual, la tabla del nodo maestro es actualizada para aadir al nuevo esclavo. Entonces esta nueva informacin es enviada por broadcast a los nodos que pertenezcan a la computadora virtual. De esta manera se actualizan todas las tablas y se mantienen consistentes.

Figura: 2.1. Clusters HP. Comunicaciones en PVM Las aplicaciones pueden ver el Hardware como una coleccin de elementos de proceso virtuales sin atributos o pueden intentar explotar las capacidades de computadoras especficas, intentando posicionar ciertas tareas en los nodos ms apropiados para ejecutarlas. PVM no tiene requisa de procesos dinmico, esto quiere decir que una vez que un proceso empieza en una determinada computadora seguir en ella hasta que se muera. Esto tiene graves inconvenientes ya que se debe tener en cuenta que las cargas varan y a no ser que los procesos que se estn ejecutando sean muy homogneos entre s, el cluster se descompensa. Por lo tanto se tendrn unos nodos ms cargados que otros y


29

con seguridad algunos nodos terminaran su ejecucin antes, esto dara como resultado tener nodos cargados y libres. Dando como resultado una perdida de rendimiento general. Otro problema de PVM es que est implementado a nivel de usuario, esto resulta contraproducente ya que se encontraran operaciones de bajo nivel como lo es el paso de mensajes entre las aplicaciones y la capa sobre UDP. Esto aadir complejidad y latencia a las comunicaciones que se producen sobre el Kernel, por lo que se tendr una capa extra de software. 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 cluster. 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 por lo anteriormente expuesto y que conozcan adems PVM, se puede decir que migrar una aplicacin a un sistema PVM no resulta econmica (Ong & all, 2001). 2.3. 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 computadoras en paralelo, 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 computadoras 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. MPI slo se ocupa de la capa de comunicacin por paso de mensajes. Necesita un ambiente de programacin paralelo nativo. Los procesos son creados cuando se carga el programa paralelo y estn vivos hasta que el programa termina. Hay un grupo de procesos por defecto que consiste en esos procesos, identificado por MPI_COMM_WORLD. Los procesos MPI son procesos como se han considerado tradicionalmente, del tipo pesados, cada proceso tiene su propio espacio de direcciones, por lo que otros procesos no pueden acceder directamente a las variables del espacio de direcciones de otro proceso. La intercomunicacin de procesos se hace va paso de mensajes.


30

Las desventajas de MPI son las mismas que se han citado en PVM, realmente son desventajas del modelo de paso de mensajes y de la implementacin en espacio de usuario. Adems aunque es un estndar y debera tener un API estndar, cada una de las implementaciones vara, no en las llamadas sino en el nmero de llamadas implementadas (MPI tiene unas 200 llamadas). Esto hace que en la prctica los diseadores del sistema y los programadores tengan que conocer el sistema particular de MPI para sacar el mximo rendimiento. Adems como slo especifica el mtodo de paso de mensajes, el resto del entorno puede ser totalmente distinto en cada implementacin con lo que otra vez se impide esa portabilidad que en teora se tiene (Gropp & all, 1996). 2.4. Beowulf El proyecto Beowulf este proyecto se basa en usar PVM y MPI, aadiendo algn programa ms que se usan para monitorizar, realizar benchmarks y facilitar el manejo del cluster. Entre las posibilidades que integra este proyecto se encuentra la posibilidad de que se tengan equipos que no necesiten discos duros, por eso se consideran que no son un cluster de estaciones de trabajo, sino que dicen que pueden introducir nodos heterogneos. Esta posibilidad la da otro programa y Beowulf lo aade a su distribucin. Beowulf puede verse como un empaquetado de PVM/MPI junto con ms software para facilitar el da a da del cluster pero no aporta realmente nada nuevo con respecto a tecnologa (Beowulf,2003). 2.5. OpenMosix OpenMosix es un software para conseguir clustering en GNU/Linux, migrando los procesos de forma dinmica con requisa. Consiste en unos algoritmos de comparticin de recursos adaptativos a nivel de Kernel, que estn enfocados a conseguir alto rendimiento, escalabilidad con baja sobrecarga y un cluster fcil de utilizar. La idea es que los procesos colaboren de forma que parezca que estn en un mismo nodo. Los algoritmos de openMosix son dinmicos lo que contrasta y es una fuerte ventaja frente a los algoritmos estticos de PVM/MPI, responden a las variaciones en el uso de los recursos entre los nodos migrando procesos de un nodo a otro, con requisa y de forma transparente para el proceso, para balancear la carga y para evitar falta de memoria en un nodo. OpenMosix, al contrario que PVM/MPI, no necesita una adaptacin de la aplicacin ni siquiera que el usuario sepa nada sobre el cluster. Por otro lado openMosix puede balancear una nica aplicacin si esta est dividida en procesos lo que ocurre en gran nmero de aplicaciones hoy en da. Y tambin puede balancear las aplicaciones entre s, lo que balancea openMosix son procesos, es la mnima unidad de balanceo. Cuando un nodo est muy cargado por sus


31

procesos y otro no, se migran procesos del primer nodo al segundo. Con lo que openMosix se puede usar con todo el software actual si bien la divisin en procesos ayuda al balanceo gran cantidad del software de gran carga ya dispone de esta divisin. El usuario en PVM/MPI tiene que crear la computadora virtual decidiendo qu nodos del cluster usar para correr sus aplicaciones cada vez que las arranca y se debe conocer bastante bien la topologa y caractersticas del cluster en general. Sin embargo en openMosix una vez que el administrador del sistema que es quien realmente conoce el sistema, lo ha instalado, cada usuario puede ejecutar sus aplicaciones y seguramente no descubra que se est balanceando la carga, simplemente ver que sus aplicaciones acabaron en un tiempo record. OpenMosix funciona a nivel de Kernel por tanto puede conseguir toda la informacin que necesite para decidir cmo est de cargado un sistema y qu pasos se deben seguir para aumentar el rendimiento, adems puede realizar ms funciones que cualquier aplicacin a nivel de usuario, por ejemplo puede migrar procesos, lo que necesita una modificacin de las estructuras del Kernel (miKel & Buytaert, 2004).

3. CLUSTER DE SISTEMA

32

3. CLUSTER DE SISTEMA 3.1. Introduccin El concepto principal del clustering es poder contar con los recursos que puedan brindar el conjunto de computadoras con las que se cuenten. La unidad bsica de un cluster es una computadora, tambin denominada nodo. Los cluster pueden escalar aadiendo computadoras. Un cluster como un todo puede ser ms potente que la ms veloz de las computadoras con las que se pueda contar, factor que esta ligado irremediablemente a la velocidad de conexin con la que se han construido las comunicaciones entre nodos. As como el sistema operativo del cluster puede hacer un mejor uso del hardware disponible, teniendo como reto en un cluster diferentes arquitecturas (miKel & Buytaert, 2004). Bsicamente existen tres tipos de clusters: Fail-over, Load-balancing y HIGH Performance Computing, los cuales se describen a continuacin: . ! Cluster Fail-over.

Consisten en dos o ms computadoras conectadas en red con una conexin heartbeat separada entre ellas. La conexin heartbeat entre las computadoras es utilizada para monitorear cul de los servicios est en uso, as como la sustitucin de una computadora por otra cuando uno de sus servicios haya cado.

! Cluster Load-balancing.

Se basa en que cuando haya una peticin entrante al servidor web, el cluster verifica cul de las computadoras disponibles posee mayores recursos libres, para luego asignarle el trabajo pertinente. Actualmente un cluster load-balancing es tambin fail-over con el extra del balanceo de la carga y a menudo con mayor nmero de nodos.

! Cluster High Performance Computing.

Estas computadoras han estado configuradas especialmente para centros de datos que requieren una potencia de computacin extrema. Los clusters Beowulf han sido diseados especficamente para estas tareas de tipo masivo, teniendo en contrapartida otras limitaciones que no lo hacen tan accesible para el usuario como un openMosix (miKel & Buytaert, 2004).


33

3.2. Mainframes, Supercomputadoras y Cluster

Los Mainframes y las Supercomputadoras han estado construidas solamente por unos fabricantes muy concretos y para empresas o universidades que requieren gran potencia de clculo.

El costo econmico que se tiene al adquirir un equipo de estas caractersticas, la mayora de las veces supera las expectativas y esto hace que tome mayor importancia la idea de poder adquirir algn equivalente a un menor costo.

El concepto de cluster naci cuando los pioneros de la supercomputacin intentaban difundir diferentes procesos entre varias computadoras, para luego poder recoger los resultados que dichos procesos deban producir. Con un Hardware ms barato y fcil de conseguir se pudo perfilar que podran conseguirse resultados muy parecidos a los obtenidos con aquellas computadoras costosas.

3.3. De MOSIX a openMosix

Primero fue MOSIX, ahora es openMosix, un proyecto que mejora los trminos de la licencia GPL que mantena a MOSIX bajo cdigo propietario.

OpenMosix es un parche (patch) para el kernel de linux que proporciona compatibilidad completa con el estndar de Linux para plataformas IA32. Actualmente se est trabajando para portarlo a IA64.

El algoritmo interno de balanceo de carga para migrar los procesos entre los nodos, es transparente para el usuario. La principal ventaja es una mejor comparticin de recursos entre nodos, as como un mejor aprovechamiento de los mismos.

El cluster escoge por s mismo la utilizacin ptima de los recursos que son necesarios en cada momento, y de forma automtica.

Esta caracterstica de migracin transparente hace que el cluster funcione para los efectos como un gran sistema SMP (Symmetric Multi Processing) con varios procesadores disponibles.

El punto fuerte de openmosix es que intenta crear un estndar en el entorno del clustering para todo tipo de aplicaciones HPC. (miKel & Buytaert, 2004)

3.3.1. Caractersticas de openMosix ! Ventajas

o No se requieren programas extras. o No son necesarias modificaciones en el cdigo.


34

! Desventajas

o Es dependiente del kernel. o No siempre migra los procesos, tiene limitaciones de funcionamiento. o Problemas con memoria compartida. o Los procesos con mltiples threads no se obtiene demasiada eficiencia. o Cuando se ejecuta un solo proceso no hay mejora, por decir el navegador.

OpenMosix se divide hasta hoy en cuatro subsistemas dentro del kernel, los subsistemas son:

1. Mosix File System (MFS)

Permite un acceso a sistemas de archivos (FS) remotos (de cualquier otro nodo) si est localmente montado.

El sistema de archivos debern de ser montados en el directorio /mfs , de esta forma se podr, acceder al directorio /home desde cualquier nodo del cluster.

2. Migracin de procesos

Con openMosix se puede lanzar un proceso en una computadora y ver si se ejecuta en otra. Cada proceso tiene su nico nodo raz (UHN, unique home node) que corresponde con el que lo ha generado. El concepto de migracin significa que un proceso se divide en dos partes: la parte del usuario y la del sistema. La parte, o rea, de usuario ser movida al nodo remoto mientras el rea de sistema espera en la raz. OpenMosix se encargar de establecer la comunicacin entre estos 2 procesos.

3. Direct File System Access (DFSA Acceso de Sistema de Archivo directo)

OpenMosix proporciona MFS con las opciones DFSA que permite acceso a los sistemas de archivos, tanto locales como remotas.

4. Memory ushering ( Introduciendo Memoria)

Este subsistema se encarga de migrar las tareas que superan la memoria disponible en el nodo en el que se ejecutan. Las tareas que superan dicho lmite se migran forzosamente a un nodo destino de entre los nodos del cluster que tengan suficiente memoria como para ejecutar el proceso sin necesidad de hacer swap a disco, ahorrando as la gran prdida de rendimiento que esto supone.


35

El subsistema de memory ushering es un subsistema independiente del subsistema de equilibrado de carga y por ello se le considera por separado (miKel & Buytaert, 2004).

3.3.2. Algoritmo de migracin

Las propiedades compartidas entre Mosix y openMosix se pueden considerar el mecanismo de migracin, en el que puede migrarse cualquier proceso a cualquier nodo del cluster de forma completamente transparente al proceso migrado. La migracin tambin puede ser automtica: el algoritmo que lo implementa tiene una complejidad computacional del orden de O(n), siendo n el nmero de nodos del cluster.

Para implementarlo openMosix utiliza el modelo fork-and-forget (tener y olvidar), desarrollado en un principio dentro de Mosix para computadoras PDP11/45 empleadas en las fuerzas areas norteamericanas. La idea de este modelo es que la distribucin de tareas en el cluster la determina openMosix de forma dinmica, conforme se van creando tareas. Cuando un nodo est demasiado cargado y las tareas que se estn ejecutando puedan migrar a cualquier otro nodo del cluster. As desde que se ejecuta una tarea hasta que sta muere, podr migrar de un nodo a otro, sin que el proceso sufra mayores cambios (miKel & Buytaert, 2004).

3.3.3. El nodo raz

Cada proceso ejecutado en el cluster tiene un nico nodo raz. El nodo raz es el nodo en el cual se lanza originalmente el proceso y donde ste empieza a ejecutarse.

Desde el punto de vista del espacio de procesos de las computadoras del cluster, cada proceso (con su correspondiente PID) parece ejecutarse en su nodo raz. El nodo de ejecucin puede ser el nodo raz u otro diferente, hecho que da lugar a que el proceso no use un PID del nodo de ejecucin, sino que el proceso migrado se ejecutar en ste como una hebra del kernel. La interaccin con un proceso, por ejemplo enviarle seales desde cualquier otro proceso migrado, se puede realizar exclusivamente desde el nodo raz.

El usuario que ejecuta un proceso en el cluster ha accedido al cluster desde el nodo raz del proceso. El propietario del proceso en cuestin tendr control en todo momento del mismo como si se ejecutara localmente.

Por otra parte la migracin y el retorno al nodo raz de un proceso se puede realizar tanto desde el nodo raz como desde el nodo dnde se ejecuta el proceso. Esta tarea la puede llevar a trmino el administrador de cualquiera de los dos sistemas (miKel & Buytaert, 2004).


36

3.3.4. El mecanismo de migracin

La migracin de procesos en openMosix es completamente transparente. Esto significa que al proceso migrado no se le avisa de que ya no se ejecuta en su nodo de origen. Es ms, este proceso migrado seguir ejecutndose como si siguiera en el nodo origen: si escribiera o leyera al disco, lo hara en el nodo origen, hecho que supone leer o grabar remotamente en este nodo.

3.3.5. Cundo podr migrar un proceso?

No todos los procesos pueden migrar en cualquiera circunstancia. El mecanismo de migracin de procesos puede operar sobre cualquier tarea de un nodo sobre el que se cumplen algunas condiciones predeterminadas. stas son:

! El proceso no puede ejecutarse en modo de emulacin VM86 ! El proceso no puede ejecutar instrucciones en ensamblador propias de la

computadora donde se lanza y que no tiene la computadora destino (en un cluster heterogneo)

! El proceso no puede mapear memoria de un dispositivo a la RAM, ni acceder directamente a los registros de un dispositivo

! El proceso no puede usar segmentos de memoria compartida

Cumpliendo todas estas condiciones el proceso puede migrar y ejecutarse migrado. No obstante, openMosix no sabe si alguno de los procesos que pueden migrar tendr algunos de estos problemas.

Por esto en un principio openMosix migra los procesos que puedan hacerlo si por el momento cumplen todas las condiciones, y en caso de que algn proceso deje de cumplirlas, lo devuelve de nuevo a su nodo raz para que se ejecute en l mientras no pueda migrar de nuevo.

Todo esto significa que mientras el proceso est en modo de emulacin VM86, mapee memoria de un dispositivo RAM, acceda a un registro o tenga reservado/bloqueado un puntero a un segmento de memoria compartida, el proceso se ejecutar en el nodo raz y cuando acabe la condicin que lo bloquea volver a migrar.

Con el uso de instrucciones asociadas a procesadores no compatibles entre ellos, openMosix tiene un comportamiento diferente: solo p

Implement Ac i on de Clusters

Documents

Transcript of Implement Ac i on de Clusters