openMosixanalyzer
La siguiente figura nos muestra de forma gráfica la carga en el openMosixanalyzer.
Figura: openMosixanalyzer. Historial de actividad de procesamiento del cluster
 |
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.
Estadísticas sobre los nodos del cluster
Figura: openMosixanalyzer. Estadísticas de los nodos
 |
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.
Monitorización de la memoria
Figura: openMosixanalyzer. Historial de actividad de memoria de nuestro cluster
 |
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.
openMosixhistory
Figura: openMosixhistory. Un historial de los procesos ejecutados
 |
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.
openMosixview + SSH2
Texto original Matthias Rechenburg. Todo error tipográfico, gramatical, semántico u ortográfico envíenlo al traductor: Marcelo (kuntx@kx99.hn.org).
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.
Libertad x seguridad = constante (sacado de un grupo de noticias de seguridad.)
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:
Con estas variables el demonio sshd remoto puede conectarse a su ssh-agent local usando el archivo socket en /tmp (en este ejemplo /tmp/ssh-XXYqbMRe/agent.1065). El ssh-agent ahora puede darle la frase de contraseña al host remoto usando este socket (obviamente es una transferencia encriptada).
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.
FAQ de openMosixview -preguntas más frecuentes
¡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.