Es una interfície gráfica (GUI) libre para la adminstración y mantenimiento de un cluster openMosix que podemos bajarnos de la web del proyecto5.9.
La suite openMosixview contiene 7 aplicaciones altamente útiles y eficaces tanto para la administración como para la monitorización del cluster.
Todos los componentes son accesibles desde la ventana de la aplicación principal. Este entorno facilita la interacción con el usuario puesto que le permite ejecutar los comandos de consola más comunes con unos pocos clicks de ratón.
versión
.
Tras bajar la última versión de los paquetes RPM de openMosixview, habrá
que instalarlos como cualquier otro paquete, sea desde l'inea de comandos:
rpm -i openMosixview-versión-distribución.rpm
Esto nos instalará los ficheros binarios en el directorio /usr/bin/. Para desinstalarlos ejecutaremos
rpm -e openMosixview
tar -zxvf openMosixview-versión.tar.gz
SCRIPT DE CONFIGURACIÓN AUTOMÁTICO
Sólo será necesario entrar al directorio openMosixview y ejecutar:
./setup [directorio_de_instalación_qt_versión]
COMPILACIÓN MANUAL
Será necesario situar la variable QTDIR hacia el directorio de la distribución QT, por ejemplo:
export QTDIR=/usr/lib/qt-2.3.0 (para bash)
ó
setenv QTDIR /usr/lib/qt-2.3.0 (para csh)
Tras lo qual tendría que ejecutar con éxito la configuración y la compilación:
./configure
make
Luego será necesario hacer lo mismo en los subdirectorios de openMosixcollector, openMosixanalyzer,
openMosixhistory and openMosixviewprocs, para poder disponer de los binarios ejecutables
de estas aplicaciones. Tras este procedimiento copiaremos todos los binarios a
/usr/bin/ siguiendo:
cp openMosixview/openMosixview /usr/bin
cp openMosixviewproc/openMosixviewprocs/mosixviewprocs /usr/bin
cp openMosixcollector/openMosixcollector/openMosixcollector /usr/bin
cp openMosixanalyzer/openMosixanalyzer/openMosixanalyzer /usr/bin
cp openMosixhistory/openMosixhistory/openMosixhistory /usr/bin
y el script de iniciación de openMosixcollector en el directorio de
iniciación5.10:
cp openMosixcollector/openMosixcollector.init /etc/init.d/openMosixcollector
Ahora, si queremos que estas aplicaciones de monitorización puedan
ejecutarse localmente en cualquier nodo, tendrán que copiarse los binarios a
cada nodo del cluster -en el directorio /usr/bin/
La Figura ![[*]](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.
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.
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.
|
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 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.
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.
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.
Con el openMosixanalyzer tendremos un historial contínuo de nuestro cluster. Los historiales generados por openMosixcollector se mostrarán ahora de forma gráfica, además de contínua, lo que nos permitirá ver la evolución del rendimiento y demás parámetros de nuestro cluster a través del tiempo. openMosixanalyzer puede analizar los historiales a tiempo real (datos generados a tiempo real) y evidentemente también puede abrir antiguos backups con el menu File.
Los historiales serán guardados en /tmp/openMosixcollector/* (y los backups los tendremos en
/tmp/openMosixcollector[date]/*)
y sólo tendremos que abrir el historial principal del cluster para visualizar antiguos historiales de informaciones de carga.
(el campo [date] en los ficheros de backup se refiere a la fecha en que han sido guardados)
La hora de inicio del backup podemos verla en la parte superior.
Si utilizamos openMosixanalyzer para tratar historiales a tiempo real tendremos que activar el check refresh para que se actualice automáticamente.
Las líneas que indican la carga son normalmente de color negro. Si la carga se incrementa a 75 las líneas se volverán rojas.
Estos valores se obtienen desde los ficheros /proc/hpc/nodes/[openMosix ID]/*
El botón Find-out de cada nodo calcula diversos valores para las estadísticas. Si lo clicamos abriremos una nueva ventana en la cual veremos las medias de la carga y memoria y algunas informaciones adicionales (estáticas y dinámicas) sobre el nodo en concreto.
Si hay checkpoints escritos en el historial (generado por openMosixcollector) podremos verlos traducidos como líneas azules verticales. Esto permite comparar valores de carga a posteriori de forma fácil. Véase la Figura 8.
La Figura 9 muestra las gráficas de memoria proporcionadas por openMosixanalyzer
La filosofía de monitorización de la memoria es idéntica a la explicada anteriormente con la carga y evidentemente sirven también para poder ver como se ha comportado openMosix para administrar nuestros recursos de memoria, en este caso.
Igualmente podemos tener un monitorización a tiempo real o abrir antiguos historiales.
Para mostrar sus gráficas, openMosixnalyzer obtiene información de estos ficheros
/proc/hpc/nodes/[openMosix-ID]/mem.
/proc/hpc/nodes/[openMosix-ID]/rmem.
/proc/hpc/nodes/[openMosix-ID]/tmem.
Los checkpoints se muestran de igual forma que en la carga, con fina líneas verticales de color azul.
Con openMosixhistory podremos acceder a la lista de procesos ejecutados en el pasado, véase Figura 10. Conseguiremos un lista de los procesos que se ejecutaron en cada nodo. openMosixcollector guarda la lista de procesos de cada nodo cuando lo iniciamos y con el openMosixhistory podremos navegar en dicha información para ver el comportamiento que desarrolló nuestro cluster.
Podremos cambiar facilmente el tiempo de navegación con un slider situado en la parte superior, para así ajustar la ventana del pasado.
openMosixhistory puede analizar en tiempo real los historiales, y también abrir antiguos de forma idéntica a como lo hemos podido hacer en los otros analizadores de datos explicados anteriormente.
Los historiales se obtienen nuevamente de /tmp/openMosixcollector/* y sólo tendremos que abrir el historial principal para poder navegar en los ficheros de información sobre la carga dada tiempo atrás.
El tiempo de inicio del monitorización podemos verlo en la parte superior y tenemos 12 horas de vista.
Usted puede leer la razón por la que debe usar SSH en vez de RSH cada día en el diario, cuando otro script-kiddy haya hackeado un sistema/red inseguro. Entonces se dará cuenta que SSH es una buena decisión después de todo.
Es por eso que es un poco difícil de instalar SSH.
SSH es seguro incluso si usted lo usa para logarse
sin usar contraseña. Seguidamente daremos una forma de como configuralo.
En principio es requerido que este corriendo el demonio del secure-shell.
Si no está instalado instálelo.
rpm -i [sshd_rpm_package_from_your_linux_distribution_cd]
Si no está ya corriendo inícielo con:
/etc/init.d/ssh start
Ahora usted debe generar en su computadora un par de llaves para el ssh hagalo con:
ssh-keygen
Se le pedirá una frase de contraseña para ese par de llaves creado.
La frase de contraseña es normalmente más larga que la contraseña
incluso llegando quizás a ser una oración completa. El par de llaves
es encriptado con esa frase de contraseña y guardado en:
root/.ssh/identity//su llave privada
/root/.ssh/identity.pub//su llave pública
¡¡No le entregue su llave privada a nadie!!
Ahora copie el contenido completo de /root/.ssh/identity.pub (su llave pública que debería tener una longitud de una línea) en /root/.ssh/authorized_keys al host remoto (también copie el contenido de /root/.ssh/identity.pub a su (local)/root/.ssh/authorized_keys como usted hizo con el nodo remoto, debido a que openMosixview necesita logar al nodo local sin que se le pida una contraseña.
Si ahora usted se trata de conectar mediante ssh al
host remoto se le preguntará por la frase de
contraseña de su llave pública respondiendo
correctamente debería poder loguearse. ¿Cuál es la
ventaja entonces?
La frase de contraseña es normalmente más larga que
la contraseña.
La ventaja usted la puede obtener usando el
ssh-agent. Éste maneja la frase de contraseña durante
el ssh login: ssh-agent
El ssh-agent es iniciado y entrega 2 variables de entorno
Usted debe configurarlas (si no lo estan ya), escriba:
echo $SSH_AUTH_SOCK
y
echo $SSH_AGENT_PID
para ver si han sido exportadas a su shell. Si esto
no es así corte y péguelas desde su terminal de la
siguiente forma:
SSH_AUTH_SOCK=/tmp/ssh-XXYqbMRe/agent.1065 export SSH_AUTH_SOCK SSH_AGENT_PID=1066 export SSH_AGENT_PID
setenv SSH_AUTH_SOCK /tmp/ssh-XXYqbMRe/agent.1065 setenv SSH_AGENT_PID 1066
Usted apenas tiene que agregar su llave pública al ssh-agent con el comando ssh-add:
ssh-add
Ahora usted debe poder logarse usando ssh al host
remoto sin que se le pida contraseña alguna.
Usted puede (debe) agregar los comandos ssh-agent y
ssh-add a su login profile:
eval `ssh-agent`
ssh-add
Con ello será iniciado cada vez que se loguee en su estación de trabajo local. Felicidades, le deseo que tenga logins seguros de ahora en más con openMosixview.
Finalmente y ya para terminar con este COMO, hay una
entrada en el menú de openmosixView que permite
seleccionar con que trabajar rsh/ssh, actívela y
usted prodrá usar openMosixview incluso en redes
inseguras.También debe grabar esta configuración, (la
posibilidad de grabar la configuración actual en
openMosixview fue agregada a partir de la versión
0.7), porque toma datos de inicio del esclavo usando
rsh ó ssh ( como usted lo haya configurado). Si usted
elige un servicio que no está instalado correctamente
openMosixview no funcionará.
Si usted no se puede conectar mediante rsh a un
esclavo sin que se le pida una contraseña usted no
podrá usar openMosixview con RSH.
Si usted no se puede conectar mediante ssh a un
esclavo sin que se le pida una contraseña usted no
podrá usar openMosixview con SSH.
Como creado por M. Rechenburg. Me olvidé de algo?
Seguro. Envíeme un mail seguramente será agregado.
¡No puedo compilar openMosixview en mi equipo!
Antes que nada, como ya se ha comentado, es fundamental disponer de las librerías QT=2.3.x.
La variable de entorno QTDIR tiene que estar configurada en QT-installation como se describe en el fichero de instalación INSTALL.
En versiones anteriores a la 0.6 podemos ejecutar make clean y borrar los dos ficheros:
/openmosixview/Makefile /openmosixview/config.cache
y probar ahora de compilar otra vez ya que el autor, Matt Rechenburg, ha dejado los binarios y los objetos en estas versiones más antiguas.
En caso de tener otro tipo de problemas podemos postear en la lista de correo o directamente informar al autor.
¿Puedo utilizar openMosixview con SSH?
Sí desde la versión 0.7 se ha incorporado soporte para SSH.
Tendr'iamos que ser capaces de acceder con ssh a cada nodo del cluster sin contraseña (lo mismo que es requerido para un acceso con rsh).
He intentado iniciar openMosixview pero se me bloquea antes de iniciarse. ¿Qué he hecho mal?
No deberemos ejecutar openMosixview en background, esto es llamarlo desde la consola con el comando openMosixview&.
También puede darse el caso que no podamos acceder a él a través de rsh/ssh (dependiendo de lo que usemos) como root sin contraseñas. Entonces deberíamos probar el comando rsh hostname como root. No se nos debería pedir ninguna contraseña pero se nos mostrará el shell para entrar nuestro login (nombre de usuario). Si estamos utilizando SSH el comando sería ssh hostname.
Tendremos que poder acceder como root en el sistema porque es el único modo de poder ejecutar los comandos administrativos que openMosixview requiere.
Si sólo tuviéramos instalado SSH en nuestro cluster, crearemos el fivhero /root/.openMosixview y escribiremos 1111 en él.
Éste es el fichero de configuración principal y el último 1 se refiere a utilizar ssh en lugar de rsh.
El cliente openMosixviewprocs/mosixview_client no funciona.
El cliente openMosixview_client se ejecuta por rsh (o ssh, lo que tengamos configurado) en el host remoto. Debe estar instalado en /usr/bin/ en cada nodo.
Si usamos RSH podemos probar
xhost +hostname
rsh hostname /usr/bin/openMosixview_client -display nombre_de_host_local:0.0
y si usamos SSH
xhost +hostname
ssh hostname /usr/bin/openMosixview_client -display nombre_de_host_local:0.0
Si esto funciona funcionará también en openMosixview.
openMosixview genera un segmentation fault
Puede que estemos utilizando versiones antiguas de openMosixview.
¿Por qué los botones del diálogo openMosixview-configuration no están preseleccionados? (automigración on/off, bloqueo on/off...)
Sería preferible que estuviesen preseleccionados, el problema se encuentra al obtener información del nodo.
Tenemos que logar en cada nodo ya que esta información no se encuentra dentro del cluster en sí .
El estado de cada nodo se guarda en el directorio /proc/hpc/admin/ de cada nodo.
