Alternativas de computacin paralela en arquitecturas Grid OGSA

Julin Roln Vidal

Universidad Distrital, Maestra en Ciencias de la Informacin y las Comunicaciones

julian.rolon@gmail.com
asocian a procesadores. La computacin distribuida aade el elemento de que estas unidades de procesamiento pueden situarse en sistemas independientes y conectados a travs de redes de comunicacin, en contraste, los sistemas tipo supercomputador son monolticos e integran muchas unidades de procesamiento en un sistema nico. Es natural entonces que los conceptos de computacin paralela puedan ser aplicados tanto a sistemas integrados como a sistemas distribuidos, sin embargo, las arquitecturas de uno u otro tipo imponen restricciones, en particular, el concepto de memoria compartida o distribuida determina que tcnicas pueden ser aplicadas y de qu forma. El principal objetivo de la computacin paralela es mejorar el rendimiento de una aplicacin, al permitir que varias tareas sean ejecutadas simultneamente, el tiempo de ejecucin global de la aplicacin disminuir, sin embargo, el rendimiento no puede ser mejorado indefinidamente simplemente mediante la adicin de unidades de procesamiento, la ley de Ahmdal[3] y posteriormente la ley de Gustafson[4] efectivamente limitan esta ganancia en rendimiento. A nivel de sistema operativo, el paralelismo permite la ejecucin de varias aplicaciones simultneamente conducindonos al concepto de sistemas operativos multitarea. Otros beneficios, asociados ms con la computacin distribuida son la alta disponibilidad, la tolerancia a fallos y el balanceo de carga, para lograr estos objetivos generalmente se sigue un esquema en el cual se tienen recursos redundantes a distintos niveles. Muchos lenguajes de programacin incorporan elementos para controlar esta replicacin, la cual puede ser encontrada tambin a nivel de motores de bases de datos o sistemas operativos. Existe una amplia documentacin al respecto y los distintos proveedores de software constantemente proporcionan soluciones orientadas en este sentido.

RESUMEN
En este artculo se exploran y discuten las diferentes alternativas para desarrollar aplicaciones paralelas en un ambiente Grid que se ajuste a una arquitectura OGSA. Se inicia con una exposicin de los antecedentes de la computacin paralela, luego se hace nfasis en la aplicacin de estos conceptos en la Grid, posteriormente se discute sobre las ventajas y desventajas de los distintos enfoques y los escenarios de aplicacin de los mismos, y por ltimo se hace nfasis en MPICH-G2 la implementacin de MPI para infraestrucuturas Grid basadas en Globus.

Categoras y Descriptores de Temas

C.1.4 [Processor Architectures]: Parallel Architectures distributed architectures.

Trminos Generales
Performance, Languages

Palabras Clave
Computacin Paralela, Programacin Paralela, Grid, OGSA, Arquitecturas.

1.

INTRODUCCIN

La computacin paralela es un campo que ha sido investigado profusamente por lo comunidad cientfica. Con el advenimiento de numerosas arquitecturas distribuidas, las distintas tcnicas de computacin paralela permiten aprovechar los recursos de hardware para lograr alto desempeo y alta disponibilidad en los sistemas. Las arquitecturas tipo Grid se sitan como una de las propuestas con mayor difusin y potencial al permitir acomodar recursos muy heterogneos y diversos utilizando redes de todo tipo incluyendo Internet. Las arquitecturas Grid pueden entonces subsumir otras arquitecturas como las basadas en Clustering o los Supercomputadores y es natural entonces que se conviertan en plataformas ideales para implementar tcnicas de computacin paralela. OGSA[1][2] es una propuesta de estandarizacin de arquitecturas Grid y contiene varias aproximaciones a los temas de computacin paralela susceptibles de ser usadas segn el contexto y segn las caractersticas del problema a resolver, es necesario contar con criterios tcnicos para la aplicacin de una u otra alternativa.

2.1

Taxonoma de Flynn[5]

En 1966, Michael J. Flynn cre una taxonoma para arquitecturas de computadores, aunque muchos de los sistemas actuales no pueden ser fcilmente clasificados, los conceptos subyacentes a la taxonoma an se aplican en los temas de computacin paralela. La taxonoma de Flynn se resume en la siguiente tabla. Tabla 1. Taxonoma de Flynn Una instruccin SISD SIMD Mltiples Instrucciones MISD MIMD

Un dato Mtiples datos

2.

CONCEPTOS

La computacin paralela ocurre cuando un programa puede ser dividido en segmentos los cuales pueden ser ejecutados al mismo tiempo, es decir concurrentemente, para poder ejecutar concurrentemente estos segmentos de cdigo o tareas es necesario contar con varias unidades de procesamiento que en general se

La clasificacin se basa en si se tienen mltiples instrucciones concurrentes o no y si se tienen mltiples fuentes de datos o no, as:

SISD: Computadores secuenciales sin paralelismo en instrucciones o en datos, son la mayora de los computadores personales (antes del advenimiento de los procesadores de doble ncleo). SIMD: Se aplican mltiples entradas de datos a una sola secuencia de instrucciones, se encuentra en computadores vectoriales y en hardware especfico como aceleradoras de grficas. MISD: Se aplica un sola entrada de datos a mltiples secuencias de instrucciones concurrentes. No es muy comn pero podran encontrarse aplicaciones en sistemas redundantes de muy alta disponibilidad y seguridad. MIMD: Se aplican diferentes entradas de datos a diferentes secuencias de instrucciones concurrentes, bajo esta denominacin se encuentran la mayora de sistemas distribuidos y paralelos.

Un tercer tipo de sistemas son los llamados de memoria compartida distribuida, en este caso se busca que las memorias propias de cada uno de los nodos en un sistema distribuido se conjuguen en una sola gran memoria compartida a la cual todos los nodos pueden acceder. Este tipo de sistemas se basa fuertemente en esquemas de sincronizacin y replicacin de estado para garantizar que todos los nodos del sistema tengan una visin consistente de la memoria. Por lo general esta sincronizacin se basa en el paso de mensajes por lo cual la programacin involucrada en este tipo de sistemas suele ser de alto nivel abstrayendo los detalles de sincronizacin y replicacin de estado cuyo manejo se deja a las capas que implementan las funciones de comunicacin del lenguaje de programacin o del sistema operativo. Evidentemente, todos estos esquemas pueden ser combinados para producir arquitecturas complejas en distintos niveles de abstraccin Aunque el trmino hilo y el trmino proceso pueden ser asociados al concepto tarea y como tal son aplicables en todos los mbitos de la computacin paralela la connotacin de los mismos suele ser la siguiente. Un programa multihilo es aquel que divide su ejecucin en varios caminos los cuales acceden a un conjunto de variables compartidas, los hilos son controlados programticamente y pertenecen a una misma aplicacin. Los procesos son controlados en parte por el sistema operativo y en parte por la aplicacin y suelen pertenecer a diferentes aplicaciones. El concepto de hilo suele ser asociado a sistemas de memoria compartida la cual es vista como variables de programacin, el concepto de proceso puede ser usado en sistemas de memoria compartida accediendo a la memoria del sistema o en sistemas de memoria distribuida usando mecanismos de comunicacin entre procesos. Se observa entonces tambin que los hilos son de alto nivel mientras que los procesos son de bajo.

Siguiendo las ideas de esta taxonoma surgen entonces dos posibles clases de paralelismo: Paralelismo Funcional: Los programas son divididos en mltiples tareas distintas que son ejecutadas en paralelo. Paralelismo en Datos: Un mismo programa es aplicado paralelamente a distintos conjuntos de datos.

2.2 Memoria compartida vs memoria distribuida

Una clasificacin importante en las arquitecturas de hardware y software es el sistema de memoria, como se ver esta clasificacin tiene importantes consecuencias para los esquemas de computacin paralela. Los sistemas de memoria compartida se caracterizan porque todas las unidades de procesamiento tienen un acceso a un espacio de memoria comn que sirve para mantener el estado de ejecucin de las aplicaciones, en este esquema todas las unidades de procesamiento pueden escribir y leer en memoria concurrentemente y es esta memoria el mecanismo principal de comunicacin entre tareas. Los computadores tienen un esquema de memoria compartida en el cual todos los procesadores acceden a una misma memoria a travs de buses del sistema por lo general. Los sistemas de memoria distribuida se caracterizan porque las unidades de procesamiento solo tienen acceso a un espacio de memoria propio y no se les permite acceder a otros espacios de memoria o que otras unidades de procesamiento accedan al suyo propio. En este esquema el mecanismo principal de comunicacin entre procesos es el paso de mensajes entre ellos, en general, estos mensajes deben seguir un protocolo determinado o en general son enviados utilizando una pila de protocolos especfica, los mensajes pueden variar entonces dependiendo del nivel de abstraccin del protocolo utilizado para enviarlos y en este sentido se tienen entonces mensajes de bajo nivel o de alto nivel, dependiendo del lenguaje de programacin utilizado y de la aplicacin en cuestin. Los sistemas distribuidos se acomodan muy bien a este esquema puesto que se tienen mltiples computadores independientes (comnmente llamados nodos) cada uno de ellos con un espacio de memoria propio los cuales se comunican enviando mensajes a travs de redes de comunicaciones con protocolos de uso comn ej. TCP/IP.

2.3

Programacin paralela

La creacin de programas paralelas involucra una serie de cuestiones que pueden ocasionar errores de funcionamiento en los programas y por tanto deben ser controladas. La causa de estos posibles inconvenientes es el posible surgimiento de dependencias entre las tareas, expresadas en funcin de las variables manejadas y que representan el estado de ejecucin y los recursos accedidos. Dos tareas o algoritmos i y j son independientes, es decir no hay dependencias entre ellos, si se cumplen las llamadas ecuaciones de Bernstein[6]:

Donde I son variables de entrada, O son variables de salida y los subndices indican el proceso i o j al que pertenecen las variables. Cuando dos procesos no resultan ser independientes pueden producirse errores entre los cuales se encuentran los siguientes: Condiciones de carrera: Este tipo de problemas se producen en sistemas de memoria compartida o memoria distribuida compartida. Suceden cuando dos tareas intentan acceder a variables compartidas y el orden en el cual las tareas acceden a estas variables no est determinado. Para evitar este tipo de errores se debe garantizar que las tareas accedan a las variables en un orden especfico logrando lo que es llamado exclusin mutua (las tareas no acceden a las variables

crticas al mismo tiempo). Los segmentos de cdigo donde el acceso a las variables puede provocar problemas se denominan secciones crticas, la exclusin mutua se logra en general garantizando que solo una tarea pueda acceder a la vez a una seccin crtica, la opcin bsica para lograr esto es que la tarea adquiera un candado sobre la seccin crtica, este candado es controlado por el lenguaje de programacin o por el sistema operativo y garantiza que ningn otro hilo ejecute la seccin crtica mientras la tarea que adquiri el candado la est ejecutando. A partir de este concepto se crean construcciones de control ms avanzadas como los semforos, los monitores y las transacciones. Abrazos mortales: En sistemas de memoria compartida suceden cuando varias tareas intentan obtener candados sobre mltiples variables y estas variables crean interdependencias, dependiendo del modelo de control de concurrencia puede ocurrir entonces que dos variables se queden esperando eternamente por obtener candados dependiendo uno del otro. En sistemas de memoria distribuida ocurren cuando una tarea se bloquea esperando por un mensaje de otra tarea y la otra a su vez tambin bloquea esperando un mensaje de la primera. Por lo general esta condicin debe ser controlada por el programador basado en su experiencia y pericia, sin embargo existen mecanismos como los perros guardianes que pueden detectar ciclos de dependencias y actuar consecuentemente por ejemplo mediante la eliminacin de una de las tareas.

3. 3.1

LENGUAJES Y HERRAMIENTAS Sistemas operativos

Inicialmente, la computacin paralela se desarrollo a partir de los lenguajes de programacin y de los sistemas operativos dentro de los cuales fue Unix en sus diversas versiones el ms preponderante. La creacin de un sistema multitarea como Unix sent las bases para la construccin de sistemas paralelos complejos, en Unix y posteriormente en Linux, el concepto de proceso es fundamental y gracias a que los diversos servicios del sistema operativo estn disponibles como libreras al programador, este concepto de proceso pudo ser fcilmente integrado en los lenguajes de programacin soportados nativamente tales como C y Fortran, es as como un programador puede acceder a los comandos exec para ejecutar aplicaciones y fork para crear programas paralelos, esta integracin natural entre sistema operativo y lenguaje de programacin potenci la produccin de programas paralelos en mquinas multiprocesador que en la poca llegaron a ser bastante grandes y complejas. Igualmente, estos sistemas empezaron a incorporar los conceptos de computacin distribuida mediante el uso de RPC, sockets y el desarrollo de sistemas de archivos en red como NFS.

3.2

Paso de mensajes

2.4

Arquitecturas paralelas

Las principales arquitecturas que permiten computacin paralela se exponen a continuacin: Sistemas multincleo: Son procesadores que incorporan varias unidades de ejecucin o ncleos, el paralelismo se logra aqu a nivel de instruccin de mquina y se realiza al interior del procesador, evidentemente, los ncleos comparten la misma memoria. Mquinas de multiprocesadores simtricos (SMP): Estos sistemas combinan mltiples procesadores iguales, en este caso es el sistema operativo el encargado de controlar el paralelismo, igual que el caso anterior, el sistema tiene un nico espacio de memoria compartido Clusters: Estos sistemas unen muchos computadores generalmente similares e independientes, lgicamente, este conglomerado de computadores se ven como una sola unidad y es un software especializado el que se encarga de realizar el paralelismo, generalmente todos los computadores tienen las mismas copia de sistema operativo pero existe un computador o nodo que se encarga de controlar a todos los dems. Cada computador tiene su memoria independiente en consecuencia se tiene un modelo de memoria distribuida y las comunicaciones se realizan a travs de redes. Procesamiento masivo paralelo (MPP): Esta arquitectura es similar a la de clusters pero involucra un nmero mayor de computadores conectados por redes de muy alta velocidad. Computacin Grid: En este modelo, los computadores o nodos son totalmente heterogneos y por lo general se tienen interconexiones de alta latencia (Internet). El paralelismo se implementa usando software middleware especializados que engloban y abstraen los recursos de cada uno de los nodos.

Los programas construidos utilizando RPC o Sockets tendan a ser de muy bajo nivel dificultando las labores de programacin, en respuesta a esto surgieron nuevas herramientas que proporcionaban una plataforma uniforme para la comunicacin entre procesos, los principales fabricante produjeron plataformas propietarias, pero gracias a la difusin de sistemas operativos de software libre como Linux, dos herramientas tambin de software libre se popularizaron, estas herramientas son PVM y MPI PVM (Parallel Virtual Machine)[7] tiene dos elementos principales, el primero es un demonio del sistema que se encarga de manejar todo lo concerniente a las comunicaciones entre procesos, la creacin de buffers de comunicacin y el manejo de tipos de datos. El segundo componente son las libreras que permiten incorporar las primitivas PVM en programas paralelos. PVM permite entonces crear procesos, buffers y enviar mensajes entre estos procesos, una de las principales ventajas de PVM es que permite acomodar sistemas heterogneos solo mediante la instalacin de la plataforma. La segunda iniciativa es MPI[8] (Message Passing Interface), MPI en realidad surge de la idea de estandarizar las herramientas de comunicacin entre procesos en consecuencia MPI se basa en las ideas previas de las plataformas existentes incluyendo PVM. La importancia de MPI radica justamente en la estandarizacin que provee lo que conduce a programas paralelos portables y a una mejora en rendimiento puesto que cada arquitectura puede implementar la especificacin de una manera ptima. Al igual que PVM, MPI proporciona primitivas que permiten el envo de mensajes entre procesos y el control de las semnticas de comunicacin, por ejemplo, MPI permite el envo de mensajes sincrnicos y asincrnicos en distintos niveles de confiabilidad, tambin permite el envo de mensajes BroadCast. Se han desarrollado implementaciones de MPI para muchas plataformas entre las cuales se destacan los clusters Beowulf[9] y Globus Toolkit[10], una plataforma Grid que se adhiere a la arquitectura OGSA.

3.3

Lenguajes MultiHilo

Con el surgimiento de lenguajes de programacin de ms alto nivel tambin se hicieron avances en la programacin paralela, es

as como lenguajes de programacin como Java[11] fueron concebidos desde su inicio para soportar programacin multihilo y las semnticas propias de este modelo estn soportadas desde las mismas races del lenguaje, al ser un lenguaje de programacin de alto nivel, la construccin de programas paralelos multihilo se facilita enormemente, adicionalmente, la portabilidad inherente de Java proporciona una alternativa muy atractiva para la produccin de programas paralelos, es necesario sin embargo aclarar que los programas desarrollados en Java bajo este esquema bsico estn orientados a sistemas de memoria compartida. Otros lenguajes populares como Phyton o C-Sharp soportan tambin este tipo de construcciones.

3.4

Programacin distribuida

Al mismo tiempo Java y otros lenguajes como .Net empezaron a incorporar conceptos de computacin distribuida entre los cuales se destacaron RMI y posteriormente EJB que es el caballo de batalla de Java para computacin distribuida. Los componentes desarrollados con EJB estn diseados para poder ser replicados en varias computadores en esquemas redundantes que permiten balanceo de cargo y tolerancia a fallas. Todas estas tendencias, resumidas bajo la idea de tener objetos distribuidos, confluyeron en la creacin de el estandar CORBA[12] para permitir interoperabilidad entre lenguajes y plataformas. Las expectativas generadas sobre CORBA en su momento fueron muy altas, sin embargo, la especificacin no prosper en gran parte por su complejidad y por problemas de escalabilidad.

JavaGroups[13] es una de estas especificaciones y permite el intercambio de mensajes entre procesos, a diferencia de MPI, aqu los procesos se refieren ms bien a servicios expuestos en la red utilizando el popular esquema de direccionamiento IP compuesto de direcciones y puertos. JavaGroups es similar en funcionalidad a MPI sin embargo su estructura es de alto nivel y como tal abstrae muchos de los detalles que se deben manejar en MPI, adems incluye operaciones para la replicacin de estado entre los nodos, la contrapartida es que la comunicacin debe ser realizada entre mquinas virtuales Java lo que limita la integracin de herramientas y aplicaciones construidas en otros lenguajes y la invocacin de servicios del sistema operativo de cada uno de los nodos. Cabe anotar que JavaGroups puede ser utilizado para cualquier aplicacin que requiera el intercambio de mensajes entre nodos Java no solamente para la replicacin de estado. Otra especificacin es JavaSpaces[14] la cual es an de ms alto nivel y est enfocada exclusivamente a la replicacin de estado entre nodos, como tal JavaSpaces puede verse como una plataforma de memoria distribuida compartida entre mquinas virtuales Java.

3.6

Servicios Web

3.5

Servidores de aplicaciones Web

El uso de componentes distribuidos como EJBs est enfocado a la produccin de aplicaciones empresariales y habilitadas para la Web, el modelo impuesto por Internet se basa en peticiones a servidores usando HTTP, estas peticiones se caracterizan por carecer de estado y por invocar operaciones que puedan ser respondidas en tiempos cortos, con base en esto, las plataformas empresariales como J2EE o .NET definen esquemas tipo cluster donde se instalan componentes distribuidos replicados como EJBs y Servlets a los cuales se les envan las peticiones HTTP bajo polticas de balanceo de carga. Ntese entonces que este tipo de cluster est optimizado para la solucin de los problemas de escalabilidad y desempeo inherentes a aplicaciones tipo Web donde potencialmente miles de usuarios estn generando peticiones Web que deben ser respondidas rpidamente, en contraste, otros clusters como los BeoWulf funcionan a nivel de sistema operativo con herramientas tipo MPI y son de propsito general optimizando un rango de aplicaciones mucho ms grande pero requiriendo de programacin a ms bajo nivel. Aunque el modelo Web original no tiene estado, y en parte esa es una razn para lograr gran escalabilidad, con el tiempo ha surgido la necesidad de asociar un estado para mantener la historia de las interacciones con los usuarios, es as como surgi el concepto de sesin WEB siendo las Cookies y la reescritura de URLs con identificadores de sesin, el mecanismo de facto para asociar una sesin de usuario en el cliente con los datos mantenidos en el servidor, adicionalmente, los componentes distribuidos tambin pueden llegar a necesitar mantener un estado interno, estas cuestiones conllevan entonces a la necesidad de mantener un estado consistente cuando los componentes estn distribuidos de forma similar a los sistemas de memoria distribuida compartida. Respondiendo a esta necesidad han surgido herramientas que permiten esta replicacin de estado utilizando primitivas de alto nivel definidas mediante especificaciones y que por lo tanto pueden ser utilizadas uniformemente por cualquier servidor de aplicaciones que necesite implementar esta funcionalidad.

A partir de la enorme difusin de Internet como una plataforma computacional universal los paradigmas de computacin distribuida y paralela migraron desde los esquemas de computacin distribuida basados en objetos como CORBA a una visin de servicios bajo la cual la Web se puede ver como una inmensa plataforma distribuida conformada por servicios computacionales que pueden ser accedidos de forma uniforme a travs de protocolos como HTTP. El acceso a estos servicios fue estandarizado por organizaciones como el World Wide Web Consortium y OASIS lo cual permiti integrar de forma transparente la diversidad de plataformas y lenguajes de programacin existentes, de esta forma los servicios Web triunfaron donde otras iniciativas como CORBA no pudieron. Los servicios Web se caracterizan por ser independientes, desacoplados, autodescritos y por estar definidos exclusivamente a nivel funcional ocultando su implementacin real pero con la posibilidad de ser ligados a distintos protocolos de mensajera tambin abiertos. Esto se logr con la adopcin de estndares como XML, SOAP, WSDL y UDDI. Los servicios Web son en general pequeas unidades computacionales que realizan tareas muy especficas, eso los hace susceptibles a ser compuestos utilizando lenguajes de orquestacin y coreografa como BPEL, el enfoque de paralelismo y distribucin es entonces crear servicios independientes con tareas especficas que luego son combinados para lograr funcionalidades ms complejas. Este esquema se adapta perfectamente a las arquitecturas WEB mencionadas antes y al igual que estas arquitecturas, los servicios WEB inicialmente carecan de la nocin de estado, sin embargo, pronto surgieron iniciativas para asociar estado de las cuales la ms importante es WSRF.

4.

Arquitecturas Grid OGSA

La idea detrs de las arquitecturas Grid es integrar recursos computaciones heterogneos y conectados a travs de todo tipo de redes incluyendo redes de alta latencia como Internet. La Grid est gobernada entonces por el principio de computacin en demanda bajo el cual se busca proporcionar no solo servicios computacionales especficos sino tambin recursos como pueden ser poder de cmputo, memoria, capacidad de almacenamiento o ancho de banda. Esto nos sugiere entonces que las arquitecturas

de Grid integran conceptos de alto y bajo nivel de cierta forma subsumiendo toda la evolucin de computacin distribuida y paralela que hasta ahora ha sido discutida en este artculo. No es de extraar entonces que una implementacin Grid pueda integrar transparentemente sistemas que van desde computadores personales hasta clusters de cientos de mquinas. OGSA es una propuesta de estandarizacin de las arquitecturas Grid mantenida por el Open Grid Forum. OGSA proporciona una visin unificada a travs de servicios Web con estado (WSRF) de los recursos de los diferentes nodos que pueden conformar una Grid, de esta forma, OGSA proporciona acceso a recursos computacionales como poder de cmputo, memoria, disco y ancho de banda, junto con aplicaciones especficas a travs de una interfaz unificada de servicios Web llamados concordantemente servicios Grid. Los servicios Grid de OGSA aaden condiciones que los diferencian de los servicios Web tradicionales, primero que todo los servicios Grid siempre tienen asociada informacin de estado lo cual permite modelar un recurso junto con sus propiedades y caractersticas. Segundo los servicios Grid deben implementar una serie de interfaces o tipos de puerto, estas interfaces estn orientadas a la creacin de los servicios en demanda vindose entonces como servicios temporales a los cuales se les puede controlar su ciclo de vida, hacerles seguimiento y naturalmente acceder a los recursos que engloban. La especificacin OGSA surge a partir del artculo introductorio en el cual sus autores delinean los objetivos y caractersticas de la arquitectura en mencin, as: Construida sobre los conceptos y tecnologas de las comunidades de Grid y Web Services, esta arquitectura define las semnticas de un servicio expuesto uniformemente (El servicio Grid); define mecanismos estndares para crear, nombrar y descubrir instancias de servicios Grid; proporciona transparencia de localizacin y mltiples ligados a protocolos para las instancias de servicios; y soporta integracin con las facilidades de las plataformas nativas subyacentes[2] Esta especificacin describe una Grid OGSA en trminos de los siguientes componentes Servicios de Infraestructura Servicios de administracin de ejecucin Servicios de datos Servicios de administracin de recursos Servicios de seguridad Servicios de auto administracin Servicios de informacin

4.2

Globus Toolkit[10]

Globus Toolkit es un kit de herramientas de software libre que se constituyen como la implementacin de referencia de la arquitectura OGSA es producido y mantenido por Globus Alliance. La arquitectura de Globus se muestra en la siguiente figura.

Figura 1: Arquitectura Globus La arquitectura est compuesta por los siguientes elementos

4.2.1

Servicios de infraestructura

Aqu se incluyen todos los servicios que permiten crear soluciones Grid, cabe decir que estos servicios pueden ser accedidos como Web Services usando el protocolo SOAP y son descritos por WSDL, adicionalmente siguen la especificacin WSRF. Los principales servicios son: GRAM[21]: Se encarga de la administracin de ejecucin, GRAM permite iniciar, monitorear y cancelar trabajos de ejecucin sobre los recursos en la Grid. GRAM hace parte de GARA[22] (Globus Arquitecture for Reservation and Allocation) que es la arquitectura que permite reservar y asignar recursos, GARA permite el descubrimiento dinmico de recursos y la asignacin inmediata o previa de estos recursos los cuales se caracterizan por ser heterogneos, distribuidos y administrados y controlados independientemente. Es particularmente complejo el problema de correservacin de recursos[23] donde es necesario reservar simultneamente recursos de muchos sitios nodos diferentes en la Grid y evitar los conflictos que se puedan presentar. GridFTP[24][25][26]: Sirve para mover, copiar ,eliminar y obtener informacin sobre archivos eficientemente, Globus no incluye una interfaz de Web Services para el servicio GridFTP. RFT[27]: Reliable File Transfer, similar a GridFTP pero incluye semnticas para la transferencia confiable de archivos y adicionalmente incluye una interfaz de Web Services conforme a WSRF. OGSA-DAI[28][29][30]: Es una herramienta que sigue las especificaciones del DAIS-WG (DataBase Access and Integration Services WorkGroup) del Open Grid Forum, se utiliza para acceder a bases de datos relacionales, XML o archivos planos. RLS y DRS[31][32]: RLS (Replica Location Service) permite el registro y descubrimiento de rplicas de datos para manejo de rplicas y DRS (Data Replication Service) utiliza RFT y RLS para crear y registrar rplicas de datos.

4.1

WSRF

WSRF permite el manejo explcito y estandarizado de estado en los Web Services y est conformada por las siguientes especificaciones WS-Resource specification [15] WS-ResourceProperties (WSRF-RP) specification [16] WS-ResourceLifetime (WSRF-RL) specification [17] WS-ServiceGroup (WSRF-SG) specification [18] WS-BaseFaults (WSRF-BF) specification [19]

WSRF reemplazo a la propuesta inicial del Open Grid Forum que era OGSI[20] (Open Grid Service Infrastructure).

MDS[33], Index y Trigger: MDS es un servicios de informacin y monitoreo sobre los recursos Grid en cuando a su estado y disponibilidad, utiliza Index que recolecta la informacin y Trigger que puede ejecutar acciones automticamente con base en notificaciones. MyProxy[34], Delegation y SimpleCA: Permiten la creacin de certificados de usuario y de mquina y la creacin de certificados temporales para el acceso a los recursos, tambin la delegacin de tareas en nombre de un usuario o mquina. MyProxy y SimpleCA no tienen interfaz Web Service mientras que Delegation si.

esquema y el de paso de mensajes para crear poderosas aplicaciones.

5.2

Servidores de aplicaciones Web

Una Grid puede integrar servidores de aplicaciones Web con lo cual se puede beneficiar del esquema distribuido de los mismos, tal como se describi en la seccin anterior, este tipo de computacin distribuida es adecuado para modelos de aplicaciones Web que involucran muchos usuarios haciendo peticiones concurrentes de bajo costo computacional pero que deben ser respondidas en poco tiempo. En realidad no existen diferencias entre el paralelismo a nivel de servicios Web no integrados a una Grid y aquellos que s, excepto tal vez que la Grid puede asociar informacin sobre la capacidad de procesamiento de los servidores de aplicaciones y de esta forma implementar esquemas de balanceo de carga y alta disponibilidad, sin embargo esto se puede lograr tambin con software especfico. Evidentemente, las mismas tcnicas de replicacin usadas con los servidores de aplicaciones tradicionales pueden ser incluidas en un entorno Grid, si se integran a estas tcnicas las propiedades de distribucin y de computacin por demanda de la Grid se lograra un esquema de paralelizacin muy poderoso para aplicaciones Web. El desarrollo en este campo es muy poco y puede ser una lnea de investagacin muy promisoria, sin embargo, es necesario hacer notar que en este caso seran los servidores de aplicaciones los que utilizaran las prestaciones de la Grid y no al contrario. En conclusin, en la actualidad, la integracin de servidores de aplicaciones replicados en una Grid no es un esquema de paralelizacin muy adecuado, adems solo cobra sentido con aplicaciones Web con muchos usuarios concurrentes y con operaciones de corta duracin. Sin embargo, en el futuro se podran ver servidores que utilizaran las prestaciones de una Grid para mejorar desempeo en el proceso de las peticiones concurrentes.

4.2.2

Contenedores

Existen tres contenedores que permiten el desarrollo e instalacin de Servicios Grid creados por los desarrolladores, estos contenedores permiten crear Servicios Web que se ajustan a WSRF en Java, Phyton y C.

4.2.3

Libreras cliente

Globus proporciona una serie de libreras que permiten invocar los servicios de infraestructura y los creados por los desarrolladores en los contenedores, estas libreras proporcionan funcionalidad comn como el acceso a travs de mensajera SOAP, el sistema de seguridad y autorizacin, el monitoreo y descubrimiento y la administracin del tiempo de vida de los recursos

5.

Paralelismo en la Grid

Dada la posible heterogeneidad de los recursos integrados en la Grid se vislumbran entonces mltiples escenarios donde se podra lograr paralelismo.

5.1

Lenguajes multihilo

La Grid permite la ejecucin de aplicaciones construidas con un lenguaje que permita programacin multihilo, naturalmente esta aplicacin podr ejecutarse paralelamente dependiendo de si el nodo consta con varias unidades de procesamiento. En principio, no existe diferencia entre la ejecucin de una aplicacin multihilo en un entorno Grid o en uno que no lo es, de hecho el paralelismo asociado a estas aplicaciones requiere de sistemas de memoria compartida y aisladamente no es posible aprovechar las caractersticas distribuidas de la Grid. Sin embargo, lenguajes como MPI en su versin 2, incluye soporte para hilos en el sentido de que un proceso involucrado en una aplicacin MPI puede estar compuesto por varios hilos (por ejemplo escribiendo una aplicacin MPI en C y usando las propiedades multihilo del lenguaje), MPI permite el envo de mensajes a los distintos hilos de la aplicacin integrando entonces poderosamente los mecanismos de paso de mensajes y programacin multihilo. El soporte para hilos en MPI 2 se limita a la posibilidad de enviar mensajes a los hilos, sin embargo, iniciativas como TeMPI trabajan sobre MPI y permiten tambin la comunicacin y sincronizacin de hilos con lo cual se pueden explotar muy bien las propiedades de la programacin multihilo y por paso de mensajes. En resumen, el conjunto de aplicaciones atacables utilizando programacin multihilo est determinado por las caractersticas del lenguaje de programacin utilizado, los conceptos de programacin multihilo son simples y fciles de implementar y existe un amplio desarrollo en las tcnicas de control. Por si sola, la programacin multihilo est limitada a sistemas de memoria compartida pero es posible utilizar desarrollos que conjuguen este

5.3

Trabajos

OGSA incluye un mecanismo para colocar trabajos en la Grid, estos trabajos estn descritos por un lenguaje estndar denominado JSDL[35] que permite la invocacin de aplicaciones especficas instaladas en los nodos componentes de la Grid. La colocacin de trabajos es un proceso que puede ser ejecutado concurrentemente por mltiples usuarios o incluso por un nico usuario pero de manera concurrente. La infraestructura Grid se encarga entonces de realizar el trabajo bajo unos contratos de calidad de servicio y garantizando la disponibilidad de recursos fsicos especficos descritos en el documento JSDL. Es natural entonces pensar que la ejecucin concurrente de los trabajos es una forma de computacin paralela sin embargo requiere que el problema pueda ser dividido en trabajos individuales cuyos resultados pueden ser posteriormente integrados, claramente, este esquema permite aprovechar las prestaciones de la Grid pero requiere que un problema pueda ser dividido adecuadamente en trabajos y subtrabajos, la comunicacin entre trabajos es complicada y solo puede hacerse utilizando un esquema de persistencia como archivos o bases de datos que almacenen los datos de entrada y los resultados. Este esquema puede ser aplicado muy fcilmente a paralelismo en datos ya que se permite que un mismo trabajo sea ejecutado concurrentemente en varios nodos con subconjuntos de datos diferentes cuyos resultados pueden ser unidos al finalizar la ejecucin de los trabajos. La desventaja es que no existe un mecanismo uniforme para lograr comunicacin entre trabajos, lo cual limita su aplicacin a

trabajos que puedan ser ejecutados independientemente y sin mucha colaboracin entre ellos.

5.4

Clusters

Al ser capaz la Grid de integrar sistemas tipo Cluster los cuales son vistos como nodos Grid individuales, la invocacin de un servicio o la ejecucin de un trabajo en estos nodos se beneficiar inmediatamente de las propiedades de paralelizacin de estos sistemas. Este esquema es bastante general pero se limita a las propiedades de paralelizacin del cluster en cuestin. Mas an el nivel de paralelismo obtenido est limitado al cluster donde se ejecuta el trabajo y que es visto como un nodo independiente, por lo cual, sin la ayuda de otras capas de integracin, el nivel de paralelizacin proporcionado por un cluster integrado a una Grid es el mismo obtenido con el mismo cluster aislado. Dada su arquitectura distribuida, la paralelizacin en un cluster se puede lograr utilizando programas basados en mecanismos de paso de mensajes como MPI de forma similar a los mecanismos utilizados en una Grid, la diferencia entonces se encuentra ms a nivel de la arquitectura del sistema en el sentido que un cluster incluye mquinas mucho ms homogneas y conectadas con redes de mucha ms velocidad y localizadas mucho ms cercanamente (por lo general redes LAN o conmutadores de fibra ptica), por lo contrario, la Grid integra recursos muy heterogneos y que pueden estar distribuidos sobre un rea mucho mas extensa (redes WAN, Internet).

estos conceptos en el momento de disear aplicaciones paralelas basadas en servicios, ms an, se deben invocar los componentes de manejo de asignacin de recursos que naturalmente deben estar expuestos tambin como servicios Grid, Globus por ejemplo, incluye WS-GRAM como un servicio Grid que expone las funcionalidades de su manejador de recursos GRAM. En resumen, el uso de servicios Grid para lograr paralelismo es aplicable cuando los problemas pueden ser divididos en tareas funcionales de alto nivel, independientes y muy bien definidas que se comunican tambin usando mensajes especficos de alto nivel, esto tiene la ventaja de que el paralelismo se puede lograr fcilmente simplemente mediante la composicin de servicios pero por otro lado, limita el rango de problemas atacables y dificulta el paralelismo en datos.

5.6

MPI para Grid

OGSA permite la ejecucin de programas escritos con operaciones MPI, las operaciones MPI expresamente permiten crear programas paralelos al integrar las semnticas de concurrencia por paso de mensajes que como se ha visto es la forma ms adecuada de lograr programacin paralela sobre arquitecturas distribuidas como la Grid. Ms all, las sentencias MPI son incluidas e invocadas desde programas escritos en C, C++ y Fortran principalmente, aunque existen implementaciones tambin para otros lenguajes de ms alto nivel como Java a travs de la invocacin de mtodos nativos, esto redunda que las semnticas de paso de mensajes pueda ser incluida en cualquier programa que pueda ser escrito en alguno de estos lenguajes lo cual permite que virtualmente cualquier aplicacin pueda ser paralelizada donde sea que esa paralelizacin sea posible en funcin de la naturaleza de la aplicacin. En resumen, MPI puede ser aplicado en un gran rango de aplicaciones haciendo este mecanismo el ms general de todos, esto unido a la portabilidad que proporciona MPI gracias a que es un estndar, hacen que este enfoque sea el ms adecuado para crear computacin paralela. Algunas implementaciones MPI propias de la Grid, tal como MPICH-G2 incluida en Globus adicionan dos ventajas adicionales. La primera es que MPICH-G2 permite aprovechar transparentemente las propiedades de paralelizacin de los clusters integrados en la Grid al permitir la aprovechacin de las implementaciones MPI propias de los Clusters, lo mismo sucede con las implementaciones MPI incluidas en las mquinas de multiprocesadores simtricos y en general con cualquier implementacin MPI propia de un nodo integrado en la Grid, de esta forma MPICH-G2 permite el aprovechamiento uniforme de todo el poder de paralelizacin de los nodos integrados en la Grid de una forma natural y transparente. La segunda, como ya se mencion, es la posibilidad de interactuar con los hilos de un programa multihilo (a partir de MPI 2) con lo cual se obtienen las ventajas de ambos mecanismos. La desventaja de este enfoque es que las operaciones de MPI son de bajo nivel lo que aumenta la complejidad de los programas creados, al respecto se han hecho esfuerzos para lograr un mayor nivel de abstraccin, estas iniciativas que se pueden encontrar en desarrollos como Ensemble o Cactus buscan proporcionar un entorno ms modular y aaden capas de ms alto nivel donde el nivel de abstraccin es mayor, ocultando los detalles especficos de comunicacin en el intercambio de mensajes.

5.5

Servicios Grid

Es posible desarrollar servicios Grid con funcionalidad especfica similar a los servicios Web tradicionales, el mecanismo de paralelizacin ac es entonces similar al ofrecido por los servicios Web tradicionales y consiste en generar muchos artefactos con tareas pequeas y especficas que luego pueden ser combinadas para lograr funcionalidades ms complejas. La invocacin a estas funcionalidades especficas puede ser hecha concurrentemente con lo cual se logra un cierto grado de paralelizacin. Como es de esperar, este caso es aplicable a aquellas aplicaciones que sean susceptibles de ser divididas en muchas tareas independientes que puedan ser modeladas como servicios, cada una aportando un pedazo de la funcionalidad y combinadas bajo esquemas de orquestacin. La necesidad de modelar la aplicacin como un conjunto de servicios independientes limita a que el rango de problemas atacables sean problemas de paralelismo funcional, para lograr paralelismo en datos es necesario contar con un servicio que separe los datos en conjuntos ms pequeos y contar con servicios Grid iguales pero instalados en diferentes nodos que procesen cada uno de los subconjuntos de datos, luego es necesario contar con otro servicio que reuna los resultados producidos por los servicios, este esquema suele ser de difcil implementacin. Los servicios involucrados en el procesamiento paralelo deben comunicarse y sincronizarse usando mensajera SOAP, esta mensajera puede estar controlada por un orquestador como un motor BPEL o estar modelada ms bien por un esquema coreogrfico, la interaccin entre servicios, que en ltima instancia determina el nivel de paralelismo, est expresada en trminos de alto nivel (servicio, mensaje, coreografa, orquestacin) siguiendo el conocido paradigma SOA. La diferencia entre un esquema SOA tradicional y uno aplicado a las grids OGSA est justamente determinado por la diferencia entre servicios Web tradicionales y servicios Grid (Manejo de estado con WSRF y semnticas especficas de manejo de ciclo de vida y monitoreo de recursos). Para poder aprovechar adecuadamente las prestaciones de la Grid se deben incorporar

Como se ve, el uso de MPI en Grids es el mejor mecanismo para crear programas paralelos al permitir aprovechar uniformemente la arquitectura distribuida de la Grid, al tener gran nivel de portabilidad y al poder integrar programas multihilo, aunque los programas suelen ser de bajo nivel, existen herramientas que pueden aliviar la complejidad asociada a este aspecto de MPI. Los servicios Grid tambin son una excelente alternativa cuando se pueda contar con aplicaciones que pueden ser divididas en tareas de alto nivel expresadas como servicios colaborando con mensajes tambin de alto nivel.

distribuidas donde es necesario ejecutar el procesamiento en las mquinas que contienen los datos. El otro grupo son los programas distribuidos por diseo en los cuales se ha escogido una opcin de computacin distribuida para aprovechar especficamente las caractersticas distribuidas de una plataforma Grid para lograr mayor desempeo. En cualquier caso MPICH-G2 permite la ejecucin de programas paralelos construidos con base en el intercambio de mensajes entre procesos. MPICH-G2 ya es utilizado en varias herramientas que facilitan el desarrollo de programas paralelos, entre los ms destacados estn Cactus y Overflow, Cactus en particular permite la creacin de mdulos, llamados espinas, que pueden integrar diferentes aspectos de la infraestructura Grid de una manera transparente. Los problemas que se presentan al tratar de ejecutar problemas paralelos en un entorno Grid son derivados de la heterogeneidad de los recursos integrados y de la diversidad de redes de comunicacin involucradas que pueden variar entre redes LAN de muy alta velocidad (GigaBit, Fibra ptica) hasta conexiones de muy alta latencia como Internet, en particular, los autores de MPICH-G2 enfrentaron los siguientes problemas: Mtodos de autenticacin diferentes entre sitios Sistemas de archivos diferentes y aislados Agendadores diferentes y no compatibles entre s La necesidad de reservar recursos en mltiples partes y hacerlos parte de un mismo ambiente computacional La necesidad de manejar las comunicaciones eficientemente utilizando protocolos adecuados segn la topologa de los recursos participantes

5.7

Cuadro comparativo
Aplicabilidad Sistemas de Memoria compartida Aplicaciones Web Trabajos Independientes y aislados General General a Alto Nivel Nivel de abstraccin Medio Integracin con Grid Medio (usando MPI o Ensemble) Muy Bajo

Se presenta aqu un cuadro comparativo de las diferentes alternativas de paralelizacin en una Grid OGSA Alternativa Lenguajes Multihilo Servidores Aplicacione s Trabajos

Alto

Bajo

Muy Alto

Clusters Servicios Grid

Bajo Muy Alto Bajo

Alto (Usando MPI) Alto Muy Alto

MPI en Grid General

6.1
6.1.1

Elementos de MPICH-G2
MPICH

Los principales elementos de la implementacin son

6.

MPICH-G2[36][37]

La mejor forma de explotar la arquitectura distribuida de la Grid es ejecutando programas paralelos los cuales pueden estar escritos en MPI. A tal respecto Globus Toolkit incluye una implementacin de la interfaz MPI llamada MPICH-G2. MPICH- G2 est construida sobre la popular implementacin MPICH pero est adaptada para aprovechas las funciones de asignacin y reserva proporcionadas por GRAM, en particular, WS-GRAM permite exponer la funcionalidad MPI como un servicio Grid integrando de esta forma la ejecucin paralela en la Grid. Una de las mejores caractersticas de MPICH-G2 es que es multiprotocolo, gracias a esto la librera escoge automticamente TCP para comunicaciones entre nodos o implementaciones propias, si existen, para comunicaciones dentro de una mquina (o cluster), de esta forma se puede explotar toda las implementaciones MPI de los nodos conformantes de la Grid. Otra caracterstica importante es la conversin automtica de datos entre mquinas para atacar el problema de las distintas representaciones que puedan tener los datos en los nodos de la Grid acomodando de esta forma la heterogeneidad inherente de la arquitectura. En general MPICH-G2 sirve para atacar dos tipos de problemas el primer grupo son los llamados problemas inherentemente distribuidos en los cuales la definicin misma del problema incluye elementos de distribucin, por ejemplo, una aplicacin grfica que necesite de procesamiento intensivo en un lugar y de la visualizacin en otra, o el proceso de datos en bases de datos

Es la implementacin ms popular de MPI, est construida en forma de capas lo cual aumenta grandemente su portabilidad. La capa superior proporciona la funcionalidad MPI de una forma independiente de los protocolos de comunicaciones y sus detalles, esta capa implementa las operaciones MPI basndose en un API llamado Abstract Device Interface (ADI). Las capas inferiores estn conformadas por dispositivos que se adhieren a la interfaz de programacin del ADI, estos dispositivos manejan los detalles de comunicacin y protocolos segn la implementacin en particular. Diversos dispositivos han sido escritos entre los cuales estn el dispositivo de comunicaciones Globus que se encarga de integrar los servicios de la Grid en la implementacin MPI.

6.1.2

Globus

Muchos componentes de Globus estn involucrados en la ejecucin de un programa paralelo MPI en una Grid, estos componentes se encargan de manejar la heterogeneidad y la distribucin de los nodos y los problemas que conllevan estos dos factores al ejecutarse un programa paralelo. Los principales componentes involucrados son Globus Communications: Se encarga del intercambio de mensajes permitiendo multiprotocolo. Inicialmente se utilizaba Nexus pero en la versin 2 se rescribi este componente por razones de desempeo y confiabilidad. Servicios de Manejo de Recursos: GRAM y DUROC

Servicios de seguridad (GSI): Permiten autenticacin y autorizacin entre nodos a travs de entidades certificadoras, certificados y certificados proxy o temporales, manejan el hecho de que un usuario pueda tener distintas credenciales entre nodos. Servicios de acceso a archivos: GridFTP y RFT. Servicio de Informacin: MDS. Servicio de deteccin de fallas con notificacin Servicios de manejo de ejecucin para mover y ejecutar programas remotamente.

Una vez se inicia la aplicacin en cada nodo MPICH-G2 selecciona el mejor protocolo de comunicacin posible que puede ser una implementacin MPI propia o TCP usando Globus Communication junto con Globus Data Conversin. DUROC y GRAM tambin interactan para monitorear y manejar la aplicacin, por ejemplo cada uno de los servidores GRAM monitorea el ciclo de vida de su porcin de aplicacin y enva eventos a DUROC. En cuanto a propiedades de rendimiento MPICH-G2 utiliza un rbol multinivel donde se asignan profundidades a los procesos para permitir optimizar las comunicaciones con base en la topologa que gobierna a los nodos de la red, [38] detalla los mecanismos de este proceso. La principal diferencia entre MPICH-G y MPICH-G2 es que en la segunda versin se reemplaz la librera Nexus por una implementacin propia, aunque Nexus proporcionaba funcionalidad multiprotocolo, dependa de un mecanismo de polling de TCP en el que se deba estar revisando buffers constantemente por la llegada de mensajes TCP en el destino que concordaran con el mensaje esperado en una operacin mpi_recv. Globus Communication reimplementa las buenas funciones de Nexus como el soporte multiprotocolo pero disminuye el uso de polling en los buffers, junto con otras mejoras que se detallan en [37]. Se tienen entonces tres modos de operacin Specified: mpi_recv especifica la fuente del mensaje y esa fuente es un proceso en la misma mquina, adicionalmente no hay peticiones asncronas que no hayan sido atendidas. En este caso no es necesario hacer polling. Specified-pending: Es similar al anterior modo pero hay peticiones sin atender, en este caso es necesario invocar el mecanismo de polling en el MPI propietario de la mquina. Multimethod: En este caso no est especificada la fuente o hay peticiones pendientes que pueden no provenir de procesos en la misma mquina. En este caso es necesario hacer polling TCP que es costoso

La siguiente figura ilustra los componentes involucrados y el proceso de invocar y ejecutar un programa MPI

Figura 2. Arquitectura Globus MPICH-G2 y proceso de ejecucin de un programa MPI. El usuario empieza solicitando un certificado temporal proxy a la infraestructura de seguridad de la Grid (Grid Security Infrastructure GSI), este certificado le permitir autenticarse en todos los nodos proporcionando funcionalidad de Single Sign On. El usuario puede opcionalmente invocar el servicio de informacin (Monitoring and Discovery Service MDS) para seleccionar los nodos con base en factores como disponibilidad, recursos y conectividad. Luego el usuario invoca mpirun, este comando que es estndar en la interfaz MPI tiene diversas implementaciones de igual forma que los dispositivos, en el caso de MPICH- G2, el comando invoca a globusrun el cual se encarga de leer un archivo escrito en un lenguaje de especificacin de recursos (Resource Specification Language RSL) que permite especificar los nodos que se utilizarn para ejecutar el programa y los requerimientos propios tales como nmero de CPUs en cada nodo, memoria o espacio de almacenamiento. La informacin de este archivo es leda por DUROC (Dynamically-Updated Request Online Coallocator), esta librera se encarga de agendar e iniciar la aplicacin en los distintos nodos, para ello enva peticiones GRAM a servidores GRAM remotos que se encargan de interactuar con los agendadores locales en cada nodo. Una vez se logra esto DUROC se encarga de unir todos los nodos y presentarlos como una misma unidad de ejecucin MPI (MPI_COMM_WORLD). Cuando es necesario mover ejecutables a nodos remotos, GRAM utiliza GASS (Global Access To Secondary Storage) el cual tambin se encarga de redirigir la salida estndar y de errores a la terminal del usuario.

Tambin en [37] se incluyen anlisis de rendimiento de la implementacin MPI utilizando la herramienta mpitest. Se incluyen aqu dos grficas para consulta rpida donde se comparan los distintos modos.

Figura 3. Latencia para mensajes cortos

procesos y la localizacin de fuentes, ejecutables y archivos de entrada y de salida. La arquitectura de Ensemble se aprecia en la siguiente figura:

Figura 4. Ancho de banda logrado Como se puede observar el rendimiento de MPICH-G2 es cercano al de un MPI propietario lo cual es conveniente para la programacin paralela va MPI en Grid. Por ltimo es menester mencionar que existe una especificacin para poder definir calidad de servicio en el servicio MPICH-G2 este tema se encuentra muy bien tratado en [39]

6.2
6.2.1

Desarrollos sobre MPI

Ensemble[40] 6.2.2 TeMPI[41]
TeMPI es un desarrollo que busca aadir programacin multihilo a la programacin MPI extendiendo el modelo de hilos introducido por MPI 2. MPI 2 simplemente acomoda el concepto de hilo permitiendo que los mensajes lleguen a los distintos hilos, TeMPI aade operaciones para la creacin de hilos bloqueantes y no bloqueantes y para la sincronizacin y comunicacin entre esos hilos, adems permite programacin con variables dataflow que permite la ejecucin de TeMPI en entornos que no tienen ejecucin de hilos segura. TeMPI est diseado para funcionar encima de MPI o de otro entorno de ejecucin que soporte hilos as:

Ensemble es una metodologa que permite crear componentes paralelizados basados en MPI, busca abstraer las topologas de procesos y de esta forma poderla aplicar en una gran variedad de problemas. La arquitectura Ensemble est dividida en dos capas, la primera se llama Abstract Design and Implementation (AD&I) que proporciona un entorno para que los desarrolladores creen los componentes paralelos independientemente de la implementacin MPI en particular. La segunda se denomina Arquitecture Specific Implementation (ASI) es generada a partir de AD&I y es transparente al programador. En AD&I el programador crea una aplicacin paralela completa pero abstracta que es transformada en una ASI especfica en un ambiente de ejecucin determinado ya sea Cluster, MPP o Grid. AD&I consiste de tres partes bien diferenciadas Componentes Virtuales: Son abstracciones de programas paralelos construidos en funcin de tres atributos: Un sobre que contiene nombres abstractos para contextos (comunicadores en MPI), races abstractas para comunicaciones colectivas (conjuntos de rangos MPI) y puertos para comunicaciones punto a punto que son tripletas de Contexto, etiquetas de mensajes y rangos destino; argumentos: Se aplican a los argumentos a pasar a las aplicaciones o describen caractersticas de la topologa como tamao del anillo de procesos por ejemplo; y cdigo fuente que son los programas MPI pero refirindose a los elementos abstractos del sobre. Topologa Simblica: Es una abstraccin que define la topologa de procesos de la aplicacin e incluye el nmero de procesos, la interfaz de cada proceso y la forma como cada proceso interacta con los otros. Asignacin de recursos: Ya no es abstracta y define el mapeo entre los componentes abstractos y la implementacin real especificando el mapeo de

Figura 5: Contexto de ejecucin de TeMPI

6.2.3

GRIDL[42]

GridL es un esfuerzo para integrar lenguajes cientficos de cuarta generacin como IDL, para ello GRIDL crea envoltorios en C/C+ + para las funciones IDL que luego son registrados en IDL, si estos envoltorios incluyen llamadas a operaciones MPI se obtienen aplicaciones paralelas IDL que pueden ser ejecutadas en una arquitectura Grid

7.

CONCLUSIONES

La computacin paralela y distribuida ha estado presente en gran parte de la evolucin de los sistemas de hardware y software y existen muchos enfoques al tema.

Las arquitecturas Grid recogen muchos de estos conceptos y los integran de igual forma como integran diversas y heterogneas arquitecturas computacionales. Por esta razn, las arquitecturas Grid y en particular OGSA permite muchas formas de computacin paralela y distribuida, la escogencia de una u otra depende del tipo de problema que se quiera solucionar y de los elementos que conforman la implementacin Grid en particular. La investigacin en computacin paralela y distribuida es un campo abierto susceptible de ser explotado mucho ms, de igual forma la computacin Grid es una de los temas con mayor potencial y futuro y naturalmente los esquemas de computacin paralela que le apliquen tambin son temas de investigacin emocionantes y estimulantes. La ms clara tendencia para desarrollar aplicaciones paralelas en la Grid es MPI y al respecto MPICH- G2 es la implementacin MPI ms madura, estable y con mayor velocidad de desarrollo, MPICH- G2 permite integrar transparentemente los servicios ofrecidos por una Grid OGSA como Globus pero a la vez otorga mucho campo para mejorar el rendimiento de las aplicaciones, en sntesis MPICH-G2 se constituye como la mejor alternativa para la creacin de programas paralelos eficientes en la Grid.

[12] S. Vinoski, CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments. [13] B. Ban, JavaGroups Groups Communication Patterns in Java

TM [14] Sun Microsystems, JavaSpaces Service Specification

[15] Steve Graham, Anish Karmarkar, Jeff Mischkinsky, Ian Robinson, Igor Sedukhin, Web Services Resource 1.2, 2006. [16] Steve Graham, Jem Treadwell, Web Services Resource Properties 1.2, 2006. [17] Latha Srinivasan, Tim Banks, Web Services Resource Lifetime 1.2, 2006. [18] Tom Maguire, David Snelling, Tim Banks, Web Services Service Group 1.2, 2006. [19] Lily Liu, Sam Meder, Web Services Base Faults 1.2, 2006. [20] S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maguire, T. Sandholm, D. Snelling, P. Vanderbilt, Open Grid Services Infrastructure, 2003. [21] M. Feller, I. Foster, and S. Martin, GT4 GRAM: A Functionality and Performance Study, 2007 [22] I. Foster, C. Kesselman, C. Lee, R. Lindell, K. Nahrstedt, A. Roy, A Distributed Resource Management Architecture that Supports Advance Reservations and Co-Allocation, 1999 [23] K. Czajkowski, I. Foster, and C. Kesselman, Resource Co-Allocation in Computational Grids, 1999 [24] W. Allcock, J. Bresnahan, R. Kettimuthu, M. Link, C. Dumitrescu, I. Raicu, I. Foster, The Globus Striped GridFTP Framework and Server, 2005 [25] W. Allcock, GridFTP: Protocol Extensions to FTP for the Grid, 2003 [26] I. Mandrichenko, W. Allcock, T.Perelmutov, GridFTP v2 Protocol Description, 2005 [27] W.E. Allcock, I. Foster, R. Madduri, Reliable Data Transport: A Critical Service for the Grid, 2004 [28] M.P.Atkinson, V.Dialani, L.Guy, I.Narang, N.W. Paton, D.Pearson, T.Storey, P.Watson, Grid Database Access and Integration: Requirements and Functionalities, 2003 [29] N. Paton, M.P. Atkinson, V. Dialani, D. Pearson, T. Storey, and P. Watson, Data Access and Integration Services on the Grid, 2002 [30] M. Antonioletti, M.P. Atkinson, R. Baxter, A. Borley, N.P. Chue Hong, B. Collins, N. Hardman, A. Hume, A. Knox, M. Jackson, A. Krause, S. Laws, J. Magowan, N.W. Paton, D. Pearson, T. Sugden, P. Watson, and M. Westhead, The Design and Implementation of Grid Database Services in OGSA-DAI. [31] M. Ripeanu, I. Foster, A Decentralized, Adaptive, Replica Location Service, 2002

8.

REFERENCIAS

[1] I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Grimshaw, B. Horn, F. Maciel, F. Siebenlist, R. Subramaniam, J. Treadwell, J. Von Reich, The Open Grid Services Architecture, Version 1.5, 2006. [2] I. Foster, C. Kesselman, J. Nick, S. Tuecke, The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration, 2002. [3] G. Amdahl, The validity of the single processor approach to achieving large-scale computing capabilities, 1967. [4] J. Gustafson, Reevaluating Amdahl's Law, 1988. [5] Flynn, M., Some Computer Organizations and Their Effectiveness, IEEE Trans. Comput., Vol. C-21, pp. 948, 1972. [6] A. J. Bernstein, Program Analysis for Parallel Processing, 1966. [7] A. Geist, A. Beguelin, J. Dongarra, W. Jiang, R. Manchek, and V. Sunderam. PVM: Parallel Virtual Machine---A Users' Guide and Tutorial for Networked Parallel Computing. Scientific and Engineering Series. MIT Press. [8] Foster, Ian (1995) Designing and Building Parallel Programs (Online) Addison-Wesley, chapter 8 Message Passing Interface [9] D Ridge, D Becker, P Merkey, T Sterling - Aerospace Conference, 1997. Proceedings., IEEE, 1997. [10] I. Foster, Globus Toolkit Version 4: Software for Service-Oriented Systems, 2005. [11] J. Gosling, H. McGilton., The Java Language Environment

[32] A. Chervenak, E. Deelman, I. Foster, L. Guy, W. Hoschek, A. Iamnitchi, C. Kesselman, P. Kunst, M. Ripeanu, B, Schwartzkopf, H, Stockinger, K. Stockinger, B. Tierney, Giggle: A Framework for Constructing Sclable Replica Location Services, 2002 [33] K. Czajkowski, S. Fitzgerald, I. Foster, C. Kesselman, Grid Information Services for Distributed Resource Sharing, 2001 [34] V. Welch, I. Foster, C. Kesselman, O. Mulmo, L. Pearlman, S. Tuecke, J. Gawor, S. Meder, F. Siebenlist, X.509 Proxy Certificates for Dynamic Delegation, 2004. [35] A. Anjomshoaa, F. Brisard, M. Drescher, D. Fellows, A. Ly, S. McGough, D. Pulsipher, A. Savva. Job Submission Description Language (JSDL) Specification v1.0. [36] I. Foster, N. Karonis. A Grid-Enabled MPI: Message Passing in Heterogeneous Distributed Computing Systems. Proc. 1998 SC Conference, November, 1998. [37] N. Karonis, B. Toonen, and I. Foster. MPICH-G2: A Grid-Enabled Implementation of the Message Passing Interface. Journal of Parallel and Distributed Computing, 2003. [38] N. Karonis, B. de Supinski, I. Foster, W. Gropp, E. Lusk, J. Bresnahan. Exploiting Hierarchy in Parallel Computer Networks to Optimize Collective Operation Performance. Proceedings of the 14th International Parallel Distributed Processing Symposium (IPDPS '00), pp 377-84, Cancun, Mexico, May 2000. [39] A. Roy, I. Foster, W. Gropp, N. Karonis, V. Sander, and B. Toonen. MPICH-GQ: Quality-of-Service for Message Passing Programs. Proceedings of the IEEE/ACM SC2000 Conference, November 4-10, 2000. [40] J.Y. Cotronis. Modular MPI Components and the Composition of Grid Applications. Proceedings of the 10th Euromicro Workshop on Parallel, Distributed and Network-based Processing, 2002 [41] A.C. Sodan. Towards Asynchronous Metacomputing in MPI. Proceedings of the 16th Annual International Symposium on High Performance Computing Systems and Applications. 2002 [42] S. G. Shasharina, O. Volberg, P. Stoltz and S. Veitzer. GRIDL: High-Performance and Distributed Interactive Data Language. 2005