Utilizando openMosixview
Aplicación principal
Figura: openMosixview: Aplicación principal
 |
La Figura ![[*]](http://www.wikilearning.com/imagescc/9756/crossref.png)
muestra la ventana de la aplicación. El usuario podrá interaccionar con el API de openMosix a través de sus controles. Para cada nodo del cluster -cada fila-: una luz, un botón, un speed-slider, un número lcd, dos barras de progreso porcentual y un par de etiquetas.
Las luces de la izquierda nos muestran el ID del nodo y su estado. El fondo rojo significa que el nodo no se encuentra operativo, y verde lo contrario.
Si hacemos clic en el botón que muestra la dirección IP de un nodo habremos invocado al diálogo de configuración que nos mostrará los botones para ejecutar los comandos de mosctl más comunes -ver sección Las herramientas de área de usuario del capítulo 5.
Con los speed-sliders podemos establecer la velocidad que considerará el cluster para cada nodo. Este parámetro se muestra numéricamente en el display lcd dse su derecha. Hay que tener en cuenta que estos ajustes tienen un efecto directo sobre el algoritmo de balanceo de carga de openMosix, puesto que intervienen en la ponderación de velocidad que se debe considerar para cada nodo. De esta manera los procesos migrarán más fácilmente hacia un nodo cuya velocidad sea más elevada. Recordemos que este concepto de velocidad no tiene que ser el que realmente posea la computadora, es simplemente el parámetro que queremos que openMosix considere para cada máquina.
Las barras de progreso dan una idea general de la carga de cada nodo del cluster. La primera se refiere a la carga del procesador y muestra un porcentaje que será una aproximación del valor escrito por openMosix en el fichero /proc/hpc/nodes/x/load. La segunda barra nos muestra la memoria utilizada en cada nodo. El box de la izquierda nos muestra el total de memoria -en megabytes- que posee cada nodo. Finalmente el último box muestra el número de procesadores de cada nodo.
Hasta ahora se ha definido la interfaz para cada nodo en particular, no obstante la misma aplicación muestra información general del cluster.
El box load-balancing efficiency es un indicador de la eficiencia del algoritmo de balanceo de carga. Un valor próximo al 100% indica que la carga computacional ha podido dividirse equitativamente entre los nodos; este es precisamente el fin que persigue openMosix.
Bajo la barra de menús existen varios iconos que lanzan las demás aplicaciones del entorno openMosixview. Podemos utilizar los menús de collector- y analyzer- para administrar openMosixcollector y openMosixanalyzer, respectivamente.
Estas dos partes de las aplicaciones openMosixview son muy adecuadas para construir un historial del trabajo hecho -y la manera en como se ha hecho- en el cluster. Cuando hagamos iniciado la captura de datos el led etiquetado como openMosixcollector status se mostrará verde.
La ventana de configuración
Figura: openMosixview: Propiedades de los nodos
 |
Esta ventana emergente de la Figura aparecerá tras hacer clic en el botón de la IP de cualquier nodo, permite una fáci configuración de la máquina con dicha dirección.
Todos los comandos que esta ventana invoca pueden ser ejecutados a través de rsh o ssh en los nodos remotos -y también en el nodo local, evidentemente- siendo root y sin necesidad de contraseñas.
Si hay instalado openMosixprocs en los nodos remotos del cluster podremos clicar en el botón remote proc-box para invocar openMosixprocs remotamente.
Se nos mostrará en pantalla los parámetros [xhost+hostname] y serán configurados para apuntar a nuestro nodo local. Además el cliente es ejecutado en el remoto con rsh o ssh (recordemos que tendríamos que tener copiados los binarios de openmsoxiprocs en el directorio /usr/bin de cada nodo).
openMosixprocs nos permitirá una administración de nuestros programas.
Si hemos entrado a nuestro cluster desde una estación de trabajo remota podremos introducir nuestro nombre de nodo local en la edit-box, debajo de la remote proc-box. Luego openMosixprocs se nos mostrará en nuestra estación de trabajo y no en el nodo del cluster donde hemos entrado (podemos configurar [xhost+clusternode] en nuestra estación de trabajo). Podemos encontrar un historial en el combo-box así como el nombre de nodo que hayamos escrito.
Ejecución avanzada
Si queremos iniciar trabajos en nuestro cluster el diálogo de advanced execution mostrado en la Figura 3 podrá ayudarnos para convertirlo a modo gráfico.
Figura: openMosixview: Ejecución avanzada
 |
Elegiremos el programa a iniciar con el botón run-prog (en File-Open-Icon) y especificaremos cuál y donde se encuentra el trabajo que queremos iniciar en este diálogo de ejecución. Hay diferentes opciones que se describen en la próxima tabla.
La línea de comandos
Podremos especificar los argumentos a los que antes podíamos acceder gráficamente a través de comandos en el lineedit-widget en la parte superior de la ventana, tal como se muestra en la Figura 3.
Tabla: openMosixview: Condiciones de inicio avanzadas para procesos
| no migration |
iniciar un proceso local que no migrará |
| run home |
iniciar un proceso local |
| run on |
iniciar un trabajo en el nodo que elijamos con "nodo-chooser" |
| cpu job |
iniciar un proceso cpu-intensivo en el nodo (nodo-chooser) |
| io job |
iniciar un proceso IO-intensivo en el nodo (nodo-chooser) |
| no decay |
iniciar un proceso sin decay (nodo-chooser) |
| slow decay |
iniciar un proceso con decay lento (nodo-chooser) |
| fast decay |
iniciar un proceso con decay rápido (nodo-chooser) |
| parallel |
iniciar un proceso paralelo en todos o algunos nodos (special nodo-chooser) | |
El host-chooser
Para todas las tareas que ejecutemos de manera remota sólo tenemos que elegir un nodo que la hospede con el dial-widget. El ID de openMosix del nodo se nos muestra también en forma de lcd. Luego pulsaremos execute para iniciar el trabajo.
El host-chooser paralelo
Podemos configurar el primer y el último nodo con 2 spinboxes. Luego el comando será ejecutado en todos los nodos, desde el primero hasta el último. Podremos también invertir esta opción.
openMosixprocs
La ventana de procesos mostrada en la Figura 4 es muy útil para la administración de los procesos de nuestro cluster.
Figura: openMosixprocs: Administración de procesos
 |
Deberemos instalar esta aplicación en cada nodo. La lista de procesos da una idea de lo que se está ejecutando y donde. La segunda columna informa del ID del nodo donde se está ejecutando la tarea. Con un doble clic sobre cualquier proceso invocaremos la ventana para administrar su migración (siguiente figura).
Un '0' significa 'local', los demás valores significan 'remoto'. Los procesos migrados están marcados con un icono verde y a los procesos que no pueden migrar se les añade un cerradero.
Hay también varias opciones para migrar el proceso remoto: enviarle las señales SIGSTOP y SIGCONT o simplemente cambiarle la prioridad, con el comando nice por ejemplo.
Si hacemos clic en el botón manage procs from remote invocaremos a una ventana emergente (llamada remote-procs windows) que nos mostrará el proceso actualmente migrado hacia ese nodo.
La ventana de migración
El diálogo de la Figura 5 emergerá si clicamos sobre cualquier proceso en la ventana anterior.
Figura: openMosixprocs: La ventana de migrado de un proceso(1)
 |
La ventana openMosixview-migrator muestra todos los nodos de nuestro cluster, arriba a la izquierda. Esta ventana sirve para administrar un proceso (con información adicional).
Si hacemos doble clic en un nodo migrará a este nodo.
Tras breves instantes el icono del proceso cambiará a verde, lo que significa que está siendo ejecutado remotamente.
El botón home envia un proceso a su nodo raíz. Con el botón best el proceso será enviado hacia el mejor nodo disponible en el cluster.
Esta migración se ve influenciada por la carga, velocidad, número de procesadores y su mayor o menor velocidad. Con el botón kill mataremos al proceso.
Para pausar un programa sólo tendremos que pulsar en el botón etiquetado como SIGSTOP y para reanudarlo, en SIGCONT.
Con el slider de renice podremos cambiar la prioridad de los procesos para una administración más completa, así el valor -20 se traduce en una mayor prioridad para terminar el trabajo, 0 le da prioridad normal y 20 le sitúa en una prioridad muy baja para tratarlo.
Administrando procesos remotamente
El diálogo mostrado en la Figura 6 aparecerá si clicamos en el botón manage procs from remote.
Figura: openMosixprocs: La ventana de migrado de un proceso(2)
 |
Las pestañas muestran los procesos que han migrado al nodo local. De forma parecida a los 2 botones en la ventana de migrado, el proceso será enviado a su nodo raíz si pulsamos goto home node y enviado al mejor nodo si pulsamos goto best node.
openMosixcollector
openMosixcollector es un daemon (demonio) que debe/puede ser invocado en cualquier miembro del cluster.
Genera un historial de la carga de cada nodo del cluster al directorio /tmp/openMosixcollector/* Este historial puede servir de entrada para openMosixanalyser (explicado posteriormente) para ofrecer una vista general de la carga, memoria y procesos en nuestro nodo durante un intervalo de tiempo.
Existe otro historial principal llamado /tmp/openMosixcollector/cluster
Y adicionalemnte a éstos existen ficheros en los directorios donde se escriben los datos.
Al iniciar, openMosixcollector escribe su PID (ID del proceso) en /var/run/openMosixcollector.pid
El demonio de openMosixcollector reinicia cada 12 horas y guarda el actual historial a /tmp/openMosixcollector[date]/* Estos backups se hacen automaticamente pero siempre podremos lanzarlos manualmente.
Hay una opción que permite escribir un checkpoint al historial. Estos checkpoints podemos verlos gráficamente como una fina línea azul vertical si analizamos el historial con openMosixanalyser. Por ejemplo podemos poner un checkpoint cuando iniciamos cierto trabajo en el cluster y otro cuando éste finaliza.
Aquí tenemos una referencia de los posibles argumentos para la consola:
openMosixcollector -d //inicia el collector como un daemon
openMosixcollector -k //detiene el collector
openMosixcollector -n //escribe un checkpoint en el historial
openMosixcollector -r //guarda el actual historial y empieza uno de nuevo
openMosixcollector //saca por la salida estándar una ayuda rápida
Podemos iniciar este demonio con su script de iniciación, que se encuentra en /etc/init.d o en /etc/rc.d/init.d Hemos de tener un enlace simbólico a uno de los runlevels para un inicio automático.
La forma para analizar los historiales creados la describimos en la siguiente sección, el openMosixanalyzer.
