El manual para el clustering con openMosix - OpenMosix View (II)

Utilizando openMosixview

Aplicación principal

Figura: openMosixview: Aplicación principal

La Figura 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

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

El host-chooser

El host-chooser paralelo

openMosixprocs

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

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

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

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.