Pages

Subscribe:

Ads 468x60px

Labels

miércoles, 9 de mayo de 2012

Reporte de Actividades

Esta semana se trabajo en tener la interfaz para el portal del Cluster se integro una web basada en SSH :

http://en.wikipedia.org/wiki/Web-based_SSH
http://liftoffsoftware.com/Products/GateOne
http://code.google.com/p/shellinabox/



También se hicieron pruebas sobre PVM

Se instalo y se corrieron ejemplos 
(Esta en proceso un tutorial para la instalacion de PVM) Para compilar Codigo Esclavo Compilar

Nominaciones:

Juan Carlos http://jcecdps.blogspot.mx/2012/05/dps-class-benchmarks.html
Osvaldo : http://4imedio.blogspot.mx/2012/05/reporte-semana-14-paralelos.html

Parallel Processing Clusters & PVM


PVM (Parallel Virtual Machine) is a software package that permits a heterogeneous collection of Unix and/or Windows computers hooked together by a network to be used as a single large parallel computer. Thus large computational problems can be solved more cost effectively by using the aggregate power and memory of many computers. The software is very portable. The source, which is available free thru netlib, has been compiled on everything from laptops to CRAYs.
PVM enables users to exploit their existing computer hardware to solve much larger problems at minimal additional cost. Hundreds of sites around the world are using PVM to solve important scientific, industrial, and medical problems in addition to PVM's use as an educational tool to teach parallel programming. With tens of thousands of users, PVM has become the de facto standard for distributed computing world-wide.

freely available network clustering software (http://www.csm.ornl.gov/pvm/) that provides a scalable network for parallel processing. Developed at the Oak Ridge National Lab and similar in purpose to the Beowulf cluster, PVM supports applications written in Fortran and C/C++. In this article, I explain how to set up parallel processing clusters and present C++ applications that demonstrate multiple tasks executing in parallel.

Setting up PVM-based parallel processing clusters is straightforward and can be done with existing workstations that are also used for other purposes. There is no need to dedicate computers to the cluster; the only requirements are that the workstations must be on a network and use UNIX/Linux. PVM creates a single logical host from multiple workstations and uses message passing for task communication and synchronization 

My motivation for setting up a parallel processing cluster was to provide a system that students could use for coursework and research projects in parallel processing. My specific goals were to set up a working cluster and demonstrate with test software that multiple tasks could execute in parallel using the cluster.

Why Use PVM?
Granted, there is other software—most notably Beowulf—for clustering workstations together for parallel processing. So why PVM? The main reasons I decided to use PVM were that it is freely available, requires no special hardware, is portable, and that many UNIX/Linux platforms are supported. The fact that I could use Linux workstations that were already available in our computer lab without dedicating the use of those machines to PVM was a major advantage for it.

Other important PVM features include:

A PVM cluster can be heterogeneous, combining workstations of different architectures. For example, Intel-based computers, Sun SPARC workstations, and Cray supercomputers could all be in the same cluster. Also, workstations from different types of networks could be combined into one cluster. 
PVM is scalable. The cluster can become more robust and powerful by just adding additional workstations to the cluster. 
PVM can be configured dynamically by using the PVM console utility or under program control using the PVM API. For example, workstations can be added or deleted while the cluster is operational. 
PVM supports both the SPMD and MPMD parallel processing models. SPMD is single program/multiple data. With PVM, multiple copies of the same task can be spawned to execute on different sets of data. MPMD is multiple program/multiple data. With PVM, different tasks can be spawned to execute with their own set of data. 
How PVM Works

A PVM background task is installed on each workstation in the cluster. The pvm daemon (pvmd) is used for interhost communication. Each pvmd communicates with the other pvm daemons via User Datagram Protocol (UDP). PVM tasks written using the PVM API communicate with pvmd via Transmission Control Protocol (TCP). Parallel-executing PVM tasks can also communicate with each other using TCP. Communication between tasks using UDP or TCP is commonly referred to as "communication using sockets"

The pvmd task also acts as a task scheduler for user-written PVM tasks using available workstations (hosts) in the cluster. In addition, each pvmd manages the list of tasks that are running on its host computer. When a parent task spawns a child task, the parent can specify which host computer the child task runs on, or the parent can defer to the PVM task scheduler which host computer is used.

A PVM console utility gives users access to the PVM cluster. Users can spawn new tasks, check the cluster configuration, and change the cluster using the PVM console utility. For example, a typical cluster change would be to add/delete a workstation to/from the cluster. Other console commands list all the current tasks that are running on the cluster. The halt command kills all pvm daemons running on the cluster. In short, haltessentially shuts the cluster down.

The PVM console utility can be started from any workstation in the cluster. For example, if workstations in the cluster are separated by some physical distance, access to the cluster may be from different locations. However, when the cluster is shut down, the first use of the PVM console utility restarts the PVM software on the cluster. The machine on which the first use of the console utility occurs is the "master host." The console utility starts the pvmd running on the master host, then starts pvmd running on all the other workstations in the cluster. The original pvmd (running on the master host) can stop or start the pvm daemon on the other machines in the cluster. All console output from PVM tasks is directed to the master host. Any machine in the cluster can be a master host. Once the cluster is started up, only one machine in the cluster is considered the master host.

Examples



Example2


miércoles, 2 de mayo de 2012

Reporte de actividades

Esta semana se esta trabajando en diseñar el portal para ejecutar los trabajos del cluster se realizaron pruebas de cliente y servidor SSH

Cliente:
http://code.google.com/p/shellinabox/

Servidor
https://github.com/liftoff/GateOne/blob/master/gateone/terminal.py


Tecnologia Grid


INTRODUCCIÓN

Las tecnologías grid permiten que los ordenadores compartan a través de Internet u otras redes de telecomunicaciones no sólo información, sino también poder de cálculo (grid computing) y capacidad de almacenamiento (grid data). Es decir, en el grid no sólo se comparten contenidos, sino también capacidad de procesamiento, aplicaciones e incluso dispositivos totalmente heterogéneos (sensores, redes, ordenadores, etc.).
El término grid computing viene a raíz de la analogía con la red eléctrica (electric power grid): nos podemos enchufar al grid para obtener potencia de cálculo sin preocuparnos de dónde viene al igual que hacemos cuando enchufamos un aparato eléctrico. Este innovador paradigma de computación distribuida es propuesto por Lan Foster y Carl Kesselman a mediados de los años 90, como una revolucionaría técnica para resolver problemas complejos entre diversas organizaciones optimizando costes y tiempo.
Un caso típico de entorno grid sería el descrito a continuación. Imaginemos a un científico que quiere ejecutar un programa creado por un colega. Si contase con una infraestructura como la de grid, no necesitaría instalar dicho programa en su máquina. En lugar de ello, solicitaría al grid que lo ejecutase remotamente en la computadora que almacena ese programa. En el caso de que la máquina estuviese ocupada, el sistema grid buscará automáticamente a través de Internet una copia del programa deseado en otras computadoras desocupadas, sin importar que dichas máquinas estuviesen situadas en otro punto del planeta, y lo ejecutaría allí.
Evidentemente, hacer esto no es nada trivial, y surgen preguntas como: ¿Cómo decido qué recursos forman parte del grid o no? ¿Cómo decido a qué recurso se dirige un programa o problema concreto? ¿Cómo divido un programa que va a ejecutarse en estas condiciones? ¿Cómo sabe una organización que sus recursos no están siendo abusados o empleados de forma maliciosa?... La computación grid, precisamente, se centra en solucionar todas estas cuestiones.

EVOLUCIÓN DE LA COMPUTACIÓN

En la computación “tradicional” basada en sistemas centralizados una organización tenía que hacerse cargo de todas sus necesidades computaciones utilizando sus propios recursos, empleando para ello grandes y costosos servidores con una enorme potencia de cálculo. Es más, no podía hacer paralelismo ni balanceo de carga entre sus distintos servidores, pudiendo haber casos de recursos sobrecargados y ociosos al mismo tiempo; además de tener otros inconvenientes como: falta de escalabilidad, equipos muy caros, o falta de fiabilidad y robustez.
Parte de estos problemas son resueltos gracias a los sistemas paralelos, enmarcados habitualmente dentro de una única organización. En general, la mayoría de los trabajos sobre computación paralela y optimización están centrados en dos tipos de sistemas paralelos:
  • Sistemas multiprocesador de memoria compartida. En este caso, los servicios ofrecidos por el sistema operativo son suficientes para desarrollar programas paralelos: se pueden usar lenguajes secuenciales con bibliotecas de threads o llamadas al sistema para escribir aplicaciones multithread o multiproceso que utilicen los distintos procesadores del sistema operativo. Otra opción consiste en usar lenguajes paralelos como Java.
  • Sistemas distribuidos basados en clusters o redes de área local. En los sistemas distribuidos existe una cantidad enorme de aspectos a considerar, como la red de conexión (Ethernet, ATM, etc.), las distintas topologías (anillo, árbol, malla, etc.), los modelos de programación (paso de mensajes, RPC, memoria compartida distribuida, etc.), las bibliotecas de comunicación (MPI, PVM, sockets, etc.), lenguajes paralelos (Java, C++, etc.), middleware (CORBA, DCOM, RMI, etc.), e incluso tecnologías de Internet (XML, SOAP, Servicios Web, etc.).
En cambio, en la computación grid intervienen varias organizaciones, cada una con sus propios recursos computaciones, luego la complejidad se multiplica respecto a los sistemas distribuidos convencionales. Es importante aclarar, que aunque el grid y el P2P (Peer-To-Peer) parecen tener el mismo objetivo final (la organización coordinada de los recursos compartidos dentro de comunidades virtuales), se centran en distintas comunidades, por lo cual tienen distintos requerimientos y siguen caminos evolutivos distintos. Mientras los sistemas grid proporcionan varios servicios sofisticados a comunidades relativamente pequeñas y se centran en la integración de recursos muy potentes para proporcionar grandes calidades de servicio dentro de un entorno de confianza limitada; los famosos sistemas P2P tratan con muchos más participantes pero ofrecen servicios más limitados y especializados, están menos preocupados por la calidad del servicio, y hacen menos asunciones en cuanto a las relaciones de confianza entre recursos y usuarios.
Concepto de grid computing

.

FUNCIONAMIENTO DE LA COMPUTACIÓN GRID

El grid descansa sobre un software, denominado middleware, que asegura la comunicación transparente entre diferentes dispositivos repartidos por todo el mundo. La infraestructura grid integra un motor de búsqueda que no sólo encontrará los datos que el usuario necesite, sino también las herramientas para analizarlos y la potencia de cálculo necesaria para utilizarlas. Al final del proceso, el grid distribuirá las tareas de computación a cualquier lugar de la red en la que haya capacidad disponible y enviará los resultados al usuario.
El objetivo final del grid es poder utilizar recursos remotos que nos permitan realizar tareas que no podríamos abordar en nuestra máquina o centro de trabajo. La idea va más allá del simple intercambio de ficheros, se trata del acceso directo a software, ordenadores y datos remotos, así como el acceso y control de otros dispositivos (sensores, telescopios, etc.). Los recursos son agrupados dinámicamente para resolver problemas concretos, formando organizaciones virtuales. La existencia de conexiones de red rápidas y fiables es un requisito indispensable para poder exportar el grid a escala mundial y esto es algo que ahora por fin es viable, gracias a la proliferación de las redes de banda ancha (xDSL, HFC, LMDS, UMTS/HSDPA, satélite, etc.).
El verdadero interés del grid radica en el uso eficiente de los recursos. Se necesitan mecanismos para repartir el trabajo de forma automática y eficiente entre una gran cantidad de recursos, reduciendo las colas de espera de los distintos usuarios. En principio, tendremos información sobre los diferentes trabajos que se han enviado y, ya que todo se está ejecutando en ordenadores, podemos calcular cuál sería la asignación óptima de recursos.
Puesto que los recursos que son compartidos pertenecen a personas muy distintas, la seguridad es esencial, y se centra en los siguientes aspectos: política de accesos (qué es lo que se va a compartir, a quién se le permite el acceso, y bajo qué condiciones), autenticación (mecanismos para garantizar la identidad de un usuario o de un recurso concreto), y autorización (procedimiento para averiguar si una determinada operación es consistente con las relaciones que se han definido previamente de cara a compartir recursos). Otro aspecto muy importante es la estandarización: todas las aplicaciones que se ejecuten en un grid, deben poder funcionar en cualquier otro.
En la segunda generación de la red de acceso multimedia de banda ancha basado en ADSL, supone la consolidación de ésta tecnología y se pretende emplear servicios basados sólo en IP: como difusión de video sobre IP o telefonía de calidad sobre IP. Hoy en día, las interfaces Ethernet son mucho más baratas que las ATM y prácticamente igual de eficientes; además, es una tecnología menos compleja y más conocida. Precisamente, la introducción de ADSL se ha visto ralentizada, sobre todo en sus inicios, debido a los costes de infraestructura, así como a la lentitud y coste de su instalación y configuración.

ARQUITECTURA DE GRID

Habitualmente se describe la arquitectura del grid en términos de “capas”, ejecutando cada una de ellas una determinada función. Las capas más altas son las más cercanas al usuario y las inferiores las más próximas a las redes de computación, distinguiendo entre:
  • Capa de aplicación. Formada por todas las aplicaciones de los usuarios, portales y herramientas de desarrollo que soportan esas aplicaciones. Es la capa que ve el usuario y que proporciona el llamado serviceware, que recoge las funciones generales de gestión tales como la contabilidad del uso del grid que hace cada usuario.
  • Capa de middleware. Responsable de proporcionar herramientas que permiten que los distintos recursos participen de forma coordinada y segura en un entorno grid unificado.
  • Capa de recursos. Constituida por los recursos que son parte del grid: ordenadores, supercomputadoras, sistemas de almacenamiento, catálogos electrónicos de datos, bases de datos, sensores, etc.
  • Capa de red. Encargada de asegurar la conexión entre los recursos que forman el grid.
Para poder hacer todo lo anterior, las aplicaciones que se desarrollen para ser ejecutadas en un ordenador concreto, tendrán que adaptarse para poder invocar los servicios adecuados y utilizar los protocolos correctos. Sin embargo, una vez adaptadas al grid, miles de usuarios podrán usar las mismas aplicaciones, utilizando las capas de middleware para adaptarse a los posibles cambios en el tejido del grid.

Middleware

De todas estas capas, la más interesante es el middleware, el auténtico cerebro del grid, que se ocupa de las siguientes funciones:
  • Encontrar el lugar conveniente para ejecutar la tarea solicitada por el usuario.
  • Optimizar el uso de recursos que pueden estar muy dispersos.
  • Organizar el acceso eficiente a los datos.
  • Autenticar los diferentes elementos.
  • Ejecutar las tareas.
  • Monitorizar el progreso de los trabajos en ejecución.
  • Gestionar automáticamente la recuperación frente a fallos.
  • Avisar cuando se haya terminado la tarea y devolver los resultados.
El middleware está formado por muchos programas software; algunos de estos programas actúan como agentes (agents) y otros como intermediarios(brokers), negociando entre sí, de forma automática, en representación de los usuarios del grid y de los proveedores de recursos. Un elemento fundamental del middleware son los metadatos (datos sobre los datos), que contienen, entre otras cosas, toda la información sobre el formato de los datos y dónde se almacenan (a veces en varios sitios distintos). Los agentes individuales presentan los metadatos referidos a los usuarios, datos y recursos. Por otro lado, los intermediarios se encargan de las negociaciones entre máquinas para la autenticación y autorización de los usuarios, de definir los acuerdos de acceso a los datos y recursos y, en caso de que corresponda, el pago por los mismos. Cuando queda establecido el acuerdo, un intermediario planifica y las tareas de cómputo y supervisa las transferencias de datos necesarias para acometer cada trabajo concreto. Al mismo tiempo, una serie de agentes supervisores especiales optimizan las rutas a través de la red y monitorizan la calidad del servicio.
Concepto de middleware


ESTANDARIZACIÓN

Actualmente, los estándares de grid los desarrolla el OGF (Open Grid Forum), organización nacida de la integración del GGF (Global Grid Forum) y la EGA (Enterprise Grid Alliance). El Foro es una comunidad de usuarios, desarrolladores, y vendedores liderando los esfuerzos de estandarización mundial del grid computing. La comunidad consiste en miles de individuos de la industria e investigación, representando más de 400 organizaciones en más de 50 países. El trabajo del OGF es llevado a cabo a través de grupos de trabajo organizados en comunidades, que desarrollan estándares y especificaciones en cooperación con otras organizaciones de estandarización, desarrolladores de software, y usuarios.
La arquitectura de sistemas grid basada en Servicios Web, conocida como OGSA (Open Grid Services Architecture), aparece como la referencia clave para los proyectos en desarrollo grid. Los Servicios Web es una arquitectura del W3C (Word Wide Web Consortium) para el desarrollo de servicios avanzados, a través de interfaces y protocolos consistentes y estándar, como: XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language), y UDDI (Universal Description, Discovery and Integration). La implementación más famosa de Servicios Web es .NET, un proyecto de Microsoft para crear una nueva plataforma de desarrollo de software con énfasis en la transparencia de redes, independiente de la plataforma, y que permite un rápido desarrollo de aplicaciones.
La principal implementación de OGSA es el Globus Toolkit, una infraestructura de código abierto gratuita desarrollada por la Globus Alliance, que proporciona un conjunto de herramientas de programación Java (librerías, servicios y API), para construir fácil y rápidamente sistemas y aplicacionesgrid basándose en sus servicios y capacidades básicas; tales como la seguridad, la localización y gestión de los recursos y las comunicaciones. Los principales proyectos relacionados con grid, se están desarrollando en base al Globus Toolkit.

APLICACIONES DEL GRID

Las instituciones y organismos más interesadas en el desarrollo del grid son, principalmente, las que comparten un objetivo común y que, para poder alcanzarlo, lo más efectivo es compartir sus recursos: Gobiernos y organizaciones internacionales (respuesta a desastres, planificación urbana, etc.); sanidad (análisis rápido de imágenes médicas complejas, etc.); educación (creación de aulas virtuales, teleconferencias, etc.), empresas y grandes corporaciones (cálculos complejos, reuniones virtuales, etc.).
Los beneficios del grid, gracias a la integración de recursos distribuidos, están teniendo repercusión en muchísimos campos, de entre los que cabe destacar: medicina (imágenes, diagnosis y tratamiento), ingeniería genética y biotecnología (estudios en genómica y proteómica), nanotecnología (diseño de nuevos materiales a escala molecular), ingeniería (diseño, simulación, análisis de fallos y acceso remoto a instrumentos de control), y recursos naturales y medio ambiente (previsión meteorológica, observación del planeta, modelos y predicción de sistemas complejos).
Aplicación del grid en la bioingeniería


El grid en los centros académicos y de investigación

La computación distribuida empezó a ser escalada a niveles globales con la madurez de Internet en los años 90. Dos proyectos en particular han demostrado que el concepto es totalmente viable y eficiente, incluso más de lo que los expertos auguraban en un principio: Distributed.net y SETI@home.
Distributed.net emplea miles de ordenadores distintos para crackear códigos de encriptación (RC5-64, CSC, DES-III, DES-II-1, DES-II-1, RC5-56, etc.). Fundado en 1997, el proyecto ha crecido hasta abarcar hoy en día más de 60.000 usuarios alrededor de todo el mundo. El poder de cómputo de Distributed.net ha ido creciendo hasta llegar a ser el equivalente a más de 160.000 computadoras PII 266MHz trabajando 24 horas al día, 7 días a la semana, y 365 días al año.
SETI@home ha sido el proyecto de computación distribuida más popular de la historia, cuyo objetivo era la búsqueda de vida extraterreste mediante la detección de su tecnología de comunicaciones, buscando patrones que demuestren inteligencia en las ondas de radio procedentes del espacio. Para ello, cualquier persona que quisiera colaborar podía descargarse un salvapantallas gratuito (de este modo aprovechaba los ciclos del ordenador sólo cuando éste no estaba en uso), que instalado en su ordenador analiza señales del espacio captadas con el radiotelescopio de Arecibo en Puerto Rico. El software se hizo público el 17 de mayo del 1999 y, desde entonces hasta su finalización el 15 de diciembre de 2005, más de 5 millones de voluntarios han instalado el programa en su ordenador, se han conseguido un total acumulado de dos millones de años de tiempo de CPU y se han analizado alrededor de 50 TB de datos, convirtiendo al proyecto en el mayor computador virtual de la historia de la humanidad por análisis realizados. En la actualidad, SETI@Home sigue en funcionamiento pero integrado en BOINC (Berkeley Open Infrastructure for Network Computing), un proyecto basado en recursos de redes abiertas con los mismos principios que el proyecto original. La nueva infraestructura continuará con la búsqueda de señales de radio extraterrestres, pero ahora además la potencia de CPU de los participantes se dedicará también a investigar sobre otras tareas, como el cambio climático, la astronomía y la cura de enfermedades.
El sector más involucrado en todo el mundo en la puesta a punto de plataformas grid en el desarrollo de aplicaciones adaptadas a esta nueva tecnología es, sin lugar a dudas, el de la investigación. En España las principales universidades e instituciones de investigación han participado intensamente en diversos proyectos sobre grid, tanto nacionales como internacionales, entre otros: “IRISGrid”, “Damien", “HealthGrid”, “CrossGrid”, “Enabling Grids for e-Science in Europe”, etc. Existen ya varios agentes grid disponibles para colaborar activamente en este tipo de proyectos, por ejemplo, en Grid.org de United Devices, cualquiera puede bajarse uno, instalarlo y configurarlo, para colaborar activamente en el desarrollo de esta fascinante tecnología y, a la vez, desempeñar una labor altamente solidaria (por ejemplo, ayudando al descubrimiento de nuevos fármacos y vacunas contra algunas de las enfermedades más terribles de nuestra Era).
Projecto SETI@home