Administración del cluster

Una vez que se ha instalado el cluster, tanto físicamente como lógicamente, es necesario tener el control de éste para su mejor aprovechamiento posible. En este capítulo se describen algunas de las herramientas para administrar, supervisar y migrar los procesos en el cluster OpenMosix.

Herramientas de área de usuario de OpenMosix

Las herramientas de área de usuario son lo mínimo que necesita cualquier administrador o usuario de OpenMosix para poder trabajar y aprovechar de manera eficiente el cluster.

Monitorizando el cluster

La herramienta usada para monitorizar un cluster OpenMosix es mosmon. Esta herramienta nos permite ver un gráfico de barras con la carga asociada a cada nodo del cluster. De una forma tradicional esta información puede obtenerse mediante el comando top en cada uno de los nodos, pero para clusters de más de ocho nodos la solución del top es no viable, y la solución de mosmon es especialmente buena.

Mosmon es una utilidad especialmente interesante por varios puntos adicionales, que no todos sus usuarios conocen, y que lo hacen indispensable para cualquier administrador de sistemas OpenMosix: con ella puede verse todos los nodos definidos en el cluster, estén o no activos, podemos ver el número de nodos activos e inactivos. Aunque este número de nodos sea mayor del que se puede ver en una pantalla, podemos con el cursor derecho y el cursor izquierdo movernos un nodo a la derecha o un nodo a la izquierda, con lo que podrán verse grandes cantidades de nodos en una pantalla cualquiera. Todo esto hace a mosmon una herramienta realmente imprescindible para el administrador del cluster (figura ).

Figura: Herramienta mosmon

Configurando los nodos en OpenMosix

La herramienta para configurar los nodos de un cluster OpenMosix es setpe. Esta herramienta es ejecutada por los scripts de inicialización y parada de OpenMosix, así como por numerosos scripts de OpenMosix y herramientas auxiliares. A pesar de que habitualmente no la llamaremos directamente, es interesante su estudio.

Setpe se encarga de determinar la configuración de nodos del cluster. Su parámetro principal es el archivo donde estará especificado el mapa de nodos. Setpe habitualmente es llamado de tres formas; la primera es con el modificador -f nombrearchivo, que tomará como archivo de configuración nombrearchivo; la segunda forma es pasando como parámetro -, en cuyo caso leerá el archivo de configuración de la entrada estándar. Esto es útil para hacer pruebas de configuración. Por último, puede ser llamado con un único parámetro -off, para sacar el nodo del cluster.

Controlando los nodos con mosctl

Del mismo modo que setpe nos permite ver la configuración de un nodo OpenMosix y modificarla, mosctl nos permite auditar el comportamiento de un nodo ya configurado y verlo.

De entre las opciones del comando mosctl, se destacan:

• block: en el nodo local, bloquea la entrada de los procesos generados en otro nodo.
• noblock: deshace los efectos de block.
• mfs: activa el soporte MFS en OpenMosix.
• nomfs: inhabilita el soporte MFS en OpenMosix.
• lstay: bloquea la migración automática hacia fuera de los procesos generados localmente.
• nolstay: deshace los efectos de lstay.
• stay: bloquea la migración automática hacia fuera de cualquier proceso.
• nostay: deshace los efectos de stay.
• quiet: el nodo local no informará a los otros nodos de su estado.
• noquiet: deshace los efectos de quiet.

Migraciones

Para forzar una migración de un proceso en un cluster OpenMosix debemos usar el comando migrate. El comando migrate toma dos parámetros: el primero es el PID (Identificador de proceso) que queremos hacer migrar, y el segundo parámetro es donde queremos que migre. Este segundo parámetro debe ser el identificador valido de un nodo en el cluster.

Existen, sin embargo, dos parámetros que podemos colocar en lugar del identificador válido de un nodo del cluster. Estos dos modificadores modelan dos casos especiales, que son:

• home: forza la migración de un proceso al nodo donde fue generado.
• balance: forza la migración de un proceso al nodo donde la migración suponga minimizar el desperdicio de recursos dentro del cluster OpenMosix.

Es una forma de indicar que se evalúe el algoritmo de migración automática de carga de OpenMosix, pero dando preferencia a la migración del proceso del que hemos indicado el PID.

A la hora de lanzar esta migración, en caso de que el proceso sea un proceso lanzado en la máquina donde ejecutamos el comando migrate, debemos ser el administrador de la máquina, el usuario propietario del proceso, el usuario efectivo del proceso, miembro del grupo propietario del proceso o miembro del grupo efectivo del proceso.

Por otro lado, el administrador del sistema de un nodo cualquiera del cluster siempre puede lanzar este comando sobre cualquier proceso que se ejecute en dicho nodo, independientemente de que se haya generado en el nodo local o en un nodo remoto.

En principio, el proceso puede no migrar aunque le lancemos la orden migrate. En caso de que no migre, algunas veces recibiremos un mensaje de error avisando que el comando no funcionó, pero unas pocas veces no migrará, y no recibiremos dicho mensaje. Particularmente esto se da cuando forzamos una migración posible pero pésima: el proceso será mandado de vuelta al nodo local incluso antes de que salga, porque el algoritmo de optimización de carga considerará inaceptable la migración.

La única migración que realmente podemos forzar es la de vuelta a casa, siempre que el nodo de origen no acepte salidas de su nodos con mosctl lstay y no bloqueemos la entrada en el nodo de destino con mosctl block.

Recomendando nodos de ejecución

Cuando lanzamos un proceso, podemos indicar cómo se va a comportar frente a la migración, o dónde se prefiere que se ejecute; para ello, contamos con el comando mosrun. Este comando no se suele llamar directamente, sino a través de un conjunto de scripts que facilitan su uso. Con este comando podemos transmitir a OpenMosix la información sobre qué hace el proceso, información que será fundamental para que OpenMosix minimice el desperdicio de recursos del cluster. También podemos indicar un conjunto de nodos entre los cuales estará el nodo donde migrará el proceso después de lanzado, si esta migración es posible.

En un sistema que no sea OpenMosix, mosrun lanza el proceso en la máquina local de forma correcta.

El comando mosrun siempre tiene la misma estructura de llamada.

[fontfamily=courier,fontshape=it,fontsize=\small,baselinestretch=0.3]
# mosrun  donde  migración  tipo  comando  argumentos

Donde los parámetros son:

• donde: nodo al que el proceso va a migrar inmediatamente después de ser lanzado, si esto es posible.
• migración: si se bloquea o no el proceso en el nodo de destino.
• tipo: tipo de proceso que se lanzaría.
• comando: nombre del proceso que se va a lanzar.
• argumentos: argumentos del proceso que se va a lanzar.

A continuación se muestran dos ejemplos de cómo utilizar mosrun.

[fontfamily=courier,fontshape=it,fontsize=\small,baselinestretch=0.3]
# mosrun -h ./programa

Obliga a ejecutar el programa en el nodo local.

[fontfamily=courier,fontshape=it,fontsize=\small,baselinestretch=0.3]
# mosrun -j2-4 ./programa

Obliga a ejecutar el programa en los nodos 2, 3 y 4.

Herramientas de monitoreo

OpenMosixView

No podemos hablar de OpenMosix pasando por alto OpenMosixView, que es una cómoda y amigable aplicación de monitoreo de un cluster OpenMosix.

OpenMosixView no está en las herramientas de área de usuario de OpenMosix por defecto. Y la razón es muy simple: las herramientas de área de usuario son lo mínimo que necesita cualquier administrador o usuario de OpenMosix para poder trabajar. En la mayoría de las instalaciones de OpenMosix, los nodos son cajas sin monitor, ratón o teclado con una instalación mínima de Linux, por lo que en principio OpenMosixView sólo será un problema para el administrador, que puede no tener interés en instalar las librerías QT y KDE en una máquina que sólo va a servir procesos.

A diferencia de las herramientas de área de usuario, que tienen una dependencia mínima de bibliotecas y compiladores preinstalados, OpenMosixView necesita otras bibliotecas instaladas para ejecutarse y compilarse.

Sin embargo, esto no quita que OpenMosixView sea una excelente herramienta y de gran utilidad, que todo administrador de OpenMosix podría tenerla instalada en la máquina desde la que inspecciona todo el cluster. Por ello, aunque no la haya incluido, se recomienda a todo administrador que la descargue y la instale en los nodos que quiera utilizar como terminal gráfico del cluster.

Figura: Herramienta openMosixMigmon

La suite OpenMosixView contiene siete aplicaciones altamente útiles y eficaces tanto para la administración como para la monitorización del cluster.

• OpenMosixView: principal aplicación de monitorización y administración.
• OpenMosixprocs: aplicación para la administración de procesos.
• OpenMosixcollector: captura la información del cluster proporcionada por los demonios.
• OpenMosixanalyzer: analizador de la información capturada por OpenMosixcollector.
• OpenMosixhistory: historial de monitorización de procesos del cluster.
• OpenMosixmigmon: visor que representa la migración de procesos (figura ).
• 3dmosmon: visor para monitorización de datos en 3D.

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 clic de ratón.

Figura: Herramienta openMosixView

La figura muestra la ventana de la aplicación. El usuario podrá interactuar con OpenMosix a través de sus controles. Para cada nodo del cluster (cada fila): una luz, una barra de velocidad, un número que indica la velocidad de procesamiento, dos barras de progreso porcentual que indican la eficiencia de balanceo de carga y de uso de memoria, también un par de etiquetas que indican la cantidad de memoria y el número de procesadores por nodo.

Programando OpenMosix

Para programar OpenMosix a bajo nivel, es decir, tomando el control del cluster y de la migración, podemos emplear tres mecanismos:

• Hacer uso de las herramientas de área de usuario. Este es el mecanismo recomendado para scripts en Perl, o para usar en shell-scripts.

• Hacer uso del sistema de archivos /proc. En Linux tenemos un sistema de archivos virtual en /proc. Este sistema de archivos no existe físicamente en el disco, y no ocupa espacio; pero los archivos y los directorios que en el encontramos, modelan distintos aspectos del sistema, tales como la memoria virtual de cada proceso, la red, las interrupciones o la memoria del sistema, entre otras cosas. OpenMosix no puede ser menos, y también podemos obtener información sobre su comportamiento y darle órdenes a través de /proc. Este método de operación es ideal en cualquier lenguaje que no tiene un método cómodo para llamar a procesos externos, y nos permite acceder con facilidad a archivos, leyendo y escribiendo su contenido. Este es el caso de la práctica totalidad de los lenguajes de programación compilados.

• Hacer uso de la biblioteca de OpenMosix. El área de usuario de OpenMosix incluye una biblioteca en C que puede ser utilizada para hacer todo aquello que pueden hacer las herramientas de área de usuario. Este mecanismo sólo funciona en C, pero es el más cómodo para los programadores en este lenguaje.