Este documento describe el uso de computación paralela y distribuida a través de una red de computadoras conocida como Grid. Explica cómo herramientas como MPI y el Globus Toolkit permiten ejecutar aplicaciones paralelas en múltiples máquinas de forma coordinada. También presenta ejemplos de cómo programar aplicaciones MPI para usar los servicios del Globus Toolkit y ejecutar en una red Grid.
2. Por qué usar el GRID?
• Han aparecido nuevas aplicaciones basadas en el uso
coordinado de gente, computadoras, bases de datos,
sensores, instrumentos, pero a ALTA VELOCIDAD
• Instrumentos manejados por computadoras
• Ingeniería colaborativa
• Exploración de bases de datos remotas
• Uso de software remoto
• Computación que usa data en forma intensiva
• Simulación a enormes escalas
• Estudios con parámetros de gran escala
2
3. Ejemplo: SF express
• Simulación distribuida e interactiva
• Necesita:
• Descubrir recursos de cómputo
• Configuración
• Muchos métodos de
comunicación
• MPI
• Escalabilidad
• Tolerancia a fallos
3
4. El Grid
• “Acceso fiable, consistente, pervasivo y difundido a
recursos de alta performance”
• Fiable: puede proporcionar garantías de performance y
funcionalidad.
• Consistente: interfaces uniformes para acceder a una
gran variedad de recursos
• Difundido: habilidad de “enchufarse” al Grid desde
cualquier lugar
4
5. Desafíos técnicos
• Estructuras de las aplicaciones son complejas,
combinando aspectos de computo paralelo, multimedia,
computo distribuido, computo colaborativo.
• Las características de los recursos varían
dinámicamente, tanto en el tiempo como en el espacio
• Se necesita una garantía de alta performance de
“extremo a extremo”, a pesar de lo heterogéneo de los
recursos y la falta de control global
• Seguridad, políticas de uso, pago por el uso.
5
6. Globus
• Investigación básica en tecnologías de Grid
• Administración de recursos, QoS, redes, almacenamiento,
seguridad, adaptación, políticas, etc.
• Se ha hecho el TOOLKIT GLOBUS
• Servicios centrales para programación usando Grid (de
aplicaciones y de herramientas)
• Hay un “test bed” grande: GUSTO
• Muy grande en términos de sites y aplicaciones
• Experimentos con varias aplicaciones
• Tele inmersión, computo distribuido, etc.
6
7. Enfoque del Globus
• Un toolkit y una colección de servicios que
soluciona varios problemas técnicos vitales
• Modelo de “bolsa de servicios”
• No es una solución integrada verticalmente
(no cubre todas las necesidad a lo largo del
desarrollo del software)
• Se distingue entre servicios locales y
remotos
• Modelo de “reloj de arena”
• Se enfoca en la arquitectura
• Servicios centrales son la infraestructura
básica.
• Las soluciones más específicas y de mayor
nivel se construye sobre esos servicios
como base.
• Principios de su diseño
• Bajo costo de participación
• Control local
7
• Adaptación
9. Servicios centrales de Globus
• Infraestructura de comunicación (Nexus, IO)
• Servicios de Información (MDS)
• Monitoreo de la performance de la red (Gloperf)
• Monitoreo de proceso (HBM)
• Administración de archivos y ejecutables remotos
(GASS y GEM)
• Administración de recursos (GRAM)
• Seguridad (GSI)
9
10. Ejemplo de servicios de alto nivel
• Librerías de comunicación y de I/O
• MPICH, PAWS, MPI-IO, PPFS, MOL
• Lenguajes paralelos
• CC++, HPC++
• Ambientes colaborativos
• CavernSoft, ManyWorlds
• Otros
• MetaNEOS, NetSolve, LSA, Autopilot, WebFlow
• OJO: el testbed de GUSTO permite probar el GRID con
máquinas en USA, Europa y Asia.
10
11. MPICH-G2
• Es una implementación de MPI con capacidad de usar
Grid, específicamente, de usar servicios del Globus
Toolkit
• Permite usar máquinas remotas en grupos MPI y correr
aplicaciones MPI
• La conversión de datos en diferentes arquitecturas y
formatos es automática.
• Entre máquinas de diferentes arquitecturas o sites la
comunicación es vía TCP. En un site, puede ser por
otros mecanismos.
• Está implementada como un MPI que corre usando un
dispositivo virtual de comunicación “globus2”
• Ejemplos de uso: Cactus (framework para simulaciones
numéricas)
11
12. Instalación de MPICH-G2
• La librería del Globus toolkit v.2.x debe estar instalada
• Probar que Globus v.2.x o posterior funcione con el
programa “hello world”
• La variable GLOBUS_LOCATION debe apuntar al
directorio donde está instalado Globus
• Bajarse el MPICH v.1.2.5.3 o posterior, descomprimir
• Configurar el MPICH especificando que use el device
globus2 y alguno de los “flavors” instalados
• ./configure -device=globus2:-flavor=gcc32dbg
• Construir el MPICH con “make” o “make install”
12
13. Pasos extra
• Tener una cuenta en Globus
• En las maquinas en que se corra el mpirun debe
hacerse antes:
• source $GLOBUS_LOCATION/etc/globus-user-env.csh, ó
• $GLOBUS_LOCATION/etc/globus-user-env.sh
• El deamon Globus con por lo menos un servicio de job
manager debe estar activo
• Compilar con mpicc o similar, para cada arquitectura
donde se desee correr la aplicación.
• Ejecutar con mpirun
• Se debe crear un script RSL. Se puede dejar que el
mpirun lo haga por uno (solo si todas las maquinas ya
tienen una copia del ejecutable compilado para la CPU
respectiva)
13
15. RSL
• Y se ejecuta así:
• mpirun -globusrsl archivo.rsl
• Si se quiere ver el RSL pero no ejecutar nada, correr el
mpirun con opción –dumprsl
• Componentes del RSL:
• resourceManagerContact = valor , dirección de la
máquina y job manager bajo el cuál el job empieza
• count = valor, número de CPUs
• label = “subjob N”, una etiqueta única como identificar
de este subjob
• environment = valores, son las variables de ambiente
del job
• directory = … es el path donde se corre el programa
• executable = … es el programa con todo y path en la
computadora remota
15
16. RSL
• maxMemory = … , tamaño de memoría a usar en Mb
• maxWallTime = …, tiempo asignado en minutos
• jobType= single | multiple | mpi | condor
• Arguments = valores, son los argumentos de la línea de
comandos
16
17. Modificando el archivo RSL
• Una modificación típica es para que las comunicaciones
colectivas del MPICH-G2 sepan más sobre la topología
del grid.
• Otra, cuando varias computadoras quieren escribir su
output a su propia pantalla en vez de al mismo
dispositivo (pantalla del procesador 0). A veces, por
razones de supervisión o monitoreo, es mejor que sean
los administradoes locales los que vena el stdout y el
stderr.
• Ver siguiente ejemplo
17
19. Programa ejemplo MPI
#include <mpi.h>
#include <stdio.h>
void main(int argc, char*argv[]) {
intrank, nprocs, number;
charbuf[1024]; MPI_Status report;
MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD,&rank);
MPI_Comm_size(MPI_COMM_WORLD,&nprocs);
gethostname(buf,sizeof(buf));
printf("hello from %d/%d name %sn",rank,nprocs,buf);
if (rank < (nprocs/2)) {
number=(rank+1)*10+rank+1;
MPI_Send(&number,1,MPI_INT,nprocs-
(rank+1),12,MPI_COMM_WORLD);
} else {
MPI_Recv(&number,1,MPI_INT,MPI_ANY_SOURCE,12,MPI_COMM
_WORLD,&report);
}
printf("P:%d my number=%dn",rank,number);
MPI_Finalize(); } 19
20. Programa ejemplo
• El output de ese ejemplo es:
hello from 0/6 comp1.uni.edu.pe
P:0 my number=11
hello from 1/6 comp0
P:1 my number=22
hello from 2/6 comp0.unmsm.edu.pe
P:2 my number=33
hello from 3/6 comp1.uni.edu.pe
P:3 my number=33
hello from 4/6 comp0
P:4 my number=22
hello from 5/6 comp0. unmsm.edu.pe
P:5 my number=11
20
21. Programa ejemplo
• Si vemos la salida, ha habido transferencia de datos
entre 2 sites remotos, uni y unmsm
• MPICH-G2 agrupa a las comunicaciones de las más
lentas a las más rápidas:
• WAN-TCP
• LAN-TCP
• Intra-machine-TCP
• vMPI
• Los mensajes en WAN-TCP (ejemplo: Internet) cuando
son largos hay la opción de pasarlos por el streaming
(múltiples conexiones)
• Para eso, consulta “MPI communicator attributes”
21