La herramienta Pvm, es un conjunto de librerias necesarias para trabajar con el concepto de clusters y crear una maquina paralela virtual. Para que Pvm funcione necesariamente tiene que estar funcionando la red de computadores, permitiendo la conexión de los mismos y el inicio de sesiones en hosts remotos.
La maquina paralela virtual es una maquina que no existe, pero un API apropiado nos permite programar como si existiese. El modelo abstracto que nos permite usar el API de
Demonio Pvm
La arquitectura de la pvm se compone de dos partes. La primera parte es el demonio, llamado Pvmd. El demonio ha de estar funcionando y configurado en todas las maquinas que vayan a compartir sus recursos computacionales con la maquina paralela virtual. A diferencia de otros demonios y programas del sistema, el demonio de Pvm puede ser instalado por el usuario en su directorio particular (de hecho, la instalacion por defecto es asi). Esto nos va a permitir hacer supercomputacion como usuarios, sin tener que discutir con el administrador de la red que programas vamos a poder ejecutar. Una vez que un usuario instalo en un directorio Pvm todo los usuarios pueden hacer uso de esa instalacion con el requisito de que el directorio donde esté instalada Pvm sea de lectura al usuario que quiera hacer uso de ella.
El demonio Pvmd es el responsable de la maquina virtual de por sí, es decir, de que se ejecuten nuestros programas para Pvm y de gerenciar los mecanismos de comunicación entre máquinas, la conversión automatica de datos y de ocultar la red al programador. Por ello, una vez que Pvm esté en marcha, el paralelismo es independiente de la arquitectura de la maquina, y solo depende de la arquitectura ed la maquina virtual creada por Pvm. Esto nos va a evitar el problema que teniamos con los Sockets, ya que teniamos que hacer una rutina de codificacion y otra de decodificacion, al menos, por cada arquitectura distinta del sistema.
Cada usuario, arrancará el demonio como si de un programa normal se tratase, para ejecutar el codigo de Pvm. Este programa se queda residente, realizando las funciones anteriores.
Biblioteca de desarrollo
La segunda parte es la biblioteca de desarrollo. Contiene las rutinas para operar con los procesos, transmitir mensajes entre procesadores y alterar las propiedades de la maquina virtual. Toda aplicación se ha de enlazar a la biblioteca para poderse ejecutar después. Tendremos tres ficheros de bibliotecas, la libpvm3.a (biblioteca basica en C), la libgpvm3.a (biblioteca de tratamiento de grupos) y la libfpvm3.a (biblioteca para fortran)
Tareas
Un programa para Pvm va a ser un conjunto de tareas que cooperan entre si. Las tareas se van a intercambiar información empleando paso de mensajes. Pvm, de forma transparente al programador, nos va a ocultar las transformaciones de tipos asociadas al paso de mensajes entre maquinas heterogeneas. Toda tarea de Pvm puede incluir o eliminar maquinas, arrancar o parar otras tareas, mandar datos a otras tareas o sincronizarse con ellas.
TIDs
Cada tarea en Pvm tiene un número que lo identifica inequívocamente, denominado TID (Task Identification Number). Es el numero al que se mandan los mensajes habitualmente. Sin embargo, no es el unico metodo de referenciar una tarea en Pvm. Muchas aplicaciones paralelas necesitan hacer el mismo conjunto de acciones sobre un conjunto de tareas. Por ello, Pvm incluye una abstracción nueva, el grupo
Grupos
Un grupo es un conjunto de tareas a las que nos podemos referir con el mismo codigo, el identificador de grupo. Para que una tarea entre o salga de un grupo, basta con avisar de la salida o entrada al grupo. Esto nos va a dotar de un mecanismo muy comodo y potente para realizar programas empleando modelos SIMD (Single Instruction, Multiple Data), en el que vamos a dividir nuestros datos en muchos datos pequeños que sean faciles de tratar, y después vamos a codificar la operación simple y replicarla tantas veces como datos unitarios tengamos de vivir el problema. Para trabajar con grupos, ademas de enlazar la biblioteca de Pvm (libpvm3.a) tenemos que enlazar tambien la de grupos (libgpvm3.a)
Funcionamiento
Habitualmente para arrancar un programa para Pvm, se lanzará manualmente desde un ordenador contenido en el conjunto de maquinas una tarea madre. La tarea se lanzará con el comando spawn desde un monitor de la maquina virtual, que a su vez se activará con el comando pvm. Esta tarea se encargará de iniciar todas las demás tareas, bien desde su funcion main (que va a ser la primera en ejecutarse), bien desde alguna subrutina invocada por ella. Para lanzar nuevas tareas se emplea la funcion pvm‗spawn, que devolverá un código de error, asociado a si pudo o no crearla, y el TID de la nueva tarea.
Clases de Arquitectura
Para evitar el problema de andar realizando transformaciones continuas de datos, Pvm define clases de arquitectura. Si es la misma, no necesita convertir datos, con lo que se tiene un gran incremento en el rendimiento. En caso que sean distintas las clases de arquitectura se emplea el protocolo XDR para codificar el mensaje.
Las clases de arquitectura están mapeadas en números de codificacion de datos, que son los que realmente se transmiten y, por lo tanto, los que realmente determinan la necesidad de la conversión
Paso de Mensajes
El modelo de paso de mensajes es transparente a la arquitectura para el programador, por la comprobación de las clases de arquitectura y la posterior codificación con XDR de no coincidir las arquitecturas. Los mensajes son etiquetados al ser enviados con un número entero definido por el usuario, y pueden ser seleccionados por el receptor tanto por dirección de origen como por el valor de la etiqueta.
El envío de mensajes no es bloqueante. Esto quiere decir que el que envía el mensaje no tiene que esperar a que el mensaje llegue, sino que solamente espera a que el mensaje sea puesto en la cola de mensajes. La cola de mensajes, además, asegura que los mensajes de una misma tarea llegarán en orden entre si. Esto no es trivial, ya que empleando UDP puede que enviemos dos mensajes y que lleguen fuera de orden (UDP es un protocolo no orientado a conexión). TCP, por ser un protocolo orientado a la conexión, realiza una reordenación de los mensajes antes de pasarlos a la capa superior, sin embargo, tiene el inconveniente que establecer las conexiones entre nodos empleando TCP supone, si tenemos n nodos, tendremos un mínimo de
($n)(n$-1) conexiones TCP activas. Provocando esto que hasta para números ridículos de $n$ nos quedamos sin puertos por éste planteamiento. Establecer conexiones TCP entre procesos en lugar de entre nodos es peor todavía, por las mismas razones que en el caso de los nodos.
La comunicación de las tareas con el daemon se hace empleando TCP. Esto se debe a que, al ser comunicaciones locales, la carga derivada de la apertura y cierre de un canal es muy pequeño. Además, no vamos a tener tantas conexiones como en el caso de la conexión entre daemons, ya que las tareas no se conectan entre sí ni con nada fuera del nodo, por lo que sólo hablan directamente con su daemon. Esto determina que serán n conexiones TCP, que sí es una cifra razonable.
La recepción de los mensajes podemos hacerla mediante primitivas bloqueantes, no bloqueantes o con un tiempo máximo de espera.
Si deseamos trabajar en otros lenguajes puede ser un poco más complejo. Si el lenguaje permite incorporar funciones nativas en lenguaje C (como es el caso, por ejemplo, de Java) no hay ningún problema; ya que podemos invocar la función; bien directamente si el lenguaje lo permite, bien haciendo alguna pequeña rutina para adaptar el tipo de los datos, el formato de llamada a función o cualquiera de las restricciones que nos imponga el lenguaje que empleemos para invocar funciones en C.
Hemos de destacar que toda función en C pvm_alguna cosa tiene como equivalente en Fortran pvmfalgunacosa, y viceversa.
El programa PVM corresponde al interprete de comandos de nuestra máquina virtual. Algunos de los comandos más importantes son:
* add máquina: Incorpora la máquina indicada a la máquina paralela virtual.
* delete máquina: Elimina la máquina indicada del conjunto de máquinas
asociadas a la máquina paralela virtual. Como es lógico, no podremos
eliminar la máquina desde la que estamos ejecutando el interprete de
comandos.
* conf: Configuración actual de la máquina paralela virtual.
* ps: Listado de procesos de la máquina paralela virtual. ps -a lista todos los
procesos.
* halt: Apaga la máquina paralela virtual. Esto significa que mata todas las
tareas de
programa pvm.
* help: Lista los comandos del programa.
* id: Imprime el TID de la consola.
* jobs: Genera un listado de los trabajos en ejecución.
* kill: Mata un proceso de
* mstat: Muestra el estado de una máquina de las pertenecientes a
* pstat: Muestra el estado de un proceso de los pertenecientes a
* quit: Sale de la máquina paralela virtual sin apagarla.
* reset: Inicializa la máquina. Eso supone matar todos los procesos de
salvo los programas monitores en ejecuciónón, limpiar las colas de
mensajes y las tablas internas y pasar a modo de espera todos los
servidores.
* setenv: Lista todas las variables de entorno del sistema.
* sig señal tarea: Manda una señal a una tarea.
* spawn: Arranca una aplicación bajo PVM. Es un comando bastante
complejo cuyas opciones veremos en una sección aparte.
* trace: Actualiza o visualiza la máscara de eventos traceados.
* alias: Define un alias predefinido, es decir, un atajo para teclear un
comando.
* unalias: Elimina un alias predefinido.
* version: Imprime la versión usada de
0 comentarios:
Publicar un comentario