El manual para el clustering con openMosix - Las herramientas de area de usuario

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. Esta información podríamos obtenerla haciendo un top en cada uno de los nodos, pero para clusters de más de ocho nodos la solución del top es inviable, 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: podemos ver las barras de forma horizontal y vertical, podemos listar todos los nodos definidos en el cluster, Estén o no activos, podemos ver el número de nodos activos y además, en caso de que el 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 podremos ver grandes cantidades de nodos en una pantalla cualquiera. Todo esto hace a mosmon una herramienta realmente imprescindible para el administrador del cluster.
De entre las opciones disponibles que podemos usar al llamar a mosmon, las más importantes son:

---

-d: incluye en el gráfico todos los nodos, incluso aquellos que están desactivados. Esta opción es muy útil, ya que así el administrador ve cuando entran en el cluster estos nodos desactivados.

---

-t: lista un el número de nodos activos del cluster. Esta opción es especialmente útil en clusters grandes o muy grandes, para hacernos una idea de cuantos nodos activo realmente tenemos -recordemos que en clusters realmente grandes, todos los días falla el hardware de algún nodo-.
Una vez que estamos dentro del programa mosmon, con la pulsación de algunas teclas podemos conseguir funciones extra. De entre las teclas activas de mosmon, destacamos:

---

d: lista también aquellos nodos que no están activos. Hace lo mismo que arrancar mosmon con la opción -d.

---

D: lista sólo aquellos nodos que están activos. Por ello, hace lo mismo que arrancar mosmon sin la opción -d.

---

h: muestra la ayuda de mosmon.

---

l: permite visualizar la carga de cada nodo. Este es el modo de visualización con el que arranca mosmon, por lo que esta opción se usa para volver a la visualización de carga después de haber cambiado la vista con m, r, s, t o u.

---

m: permite visualizar la memoria lógica usada por los procesos -lo que corresponde a suma de las memoria que los procesos creen que realmente usan- y la memoria total por cada máquina, en lugar de la carga. La barra corresponde con la memoria lógica ocupada, mientras que los +, sumados a la barra, corresponden a la memoria total. Los + corresponden a la suma entre la memoria libre y la memoria usada por cosas distintas de los procesos -kernel, Reservada por dispositivos hardware-. Puede ser menor O mayor que la memoria libre real, ya que por un lado varios procesos pueden compartir segmentos, lo que hace que la memoria física usada sea menor que la memoria lógica usada; por otro lado, el kernel y los dispositivos hacen que no toda la memoria no usada por los procesos esté realmente libre. Todas las cantidades se muestran en megabytes.

---

q: sale del programa mosmon.

---

r: permite visualizar la memoria física usada, la memoria libre y la memoria total por cada máquina, en lugar de la carga. La barra corresponde con la memoria física usada en un nodo, mientras que los + corresponden a la memoria libre. Por ello los +, sumados a la barra, corresponden a la memoria total. Todas las cantidades se muestran en megabytes.

---

s: permite ver las velocidades de los procesadores y el número de procesadores por cada máquina en lugar de la carga.

---

t: lista un el número de nodos activos del cluster, si no está visible, o desactiva la visión si se están viendo el número de nodos activos del cluster. Está relacionado con la opción de arranque -t.

---

u: permite ver el grado de utilización del procesador de cada nodo. En el caso de que el cuello de botella de un nodo esté en su procesador, este valor estará al 100%. Hay que destacar que un nodo puede estar saturado por muchas cosas, tales como acceso a disco o a swap, y no llegar dicho nodo al 100% de la utilización neta del procesador. Un valor por debajo del 100%, por lo tanto, significa que un procesador está infrautilizado, por lo que podría aceptar migraciones de entrada -aunque puede tener migraciones de salida del nodo de procesos que usen mucha memoria o mucho disco-.

---

Además de todo esto, la tecla Enter nos permite redibujar la pantalla, p hace lo mismo que el cursor izquierdo -mover la vista de nodos a la izquierda-, y n nos permite hacer lo mismo que el cursor derecho -mover la vista de nodos a la derecha-.

Configurando los nodos en openMosix

La herramienta para configurar los nodos de un cluster openMosix es setpe. Esta herramienta es llamada 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 nombrefichero, que tomará como archivo de configuración nombrefichero. 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, o para hacer pipes de setpe con otras aplicaciones. Por último, puede ser llamado con un único parámetro, -off, para sacar el nodo del cluster.

De entre los parámetros de setpe destacamos:

---

-w: carga la configuración del fichero indicado con los parámetros especificados en dicho fichero sobre el kernel, si es posible hacerlo sin necesidad de reinicializar la parte de openMosix del kernel. Esto significa que sólo actualiza la configuración si el nodo no ejecuta ningún proceso de otro nodo, ni ningún proceso de el nodo local se ejecuta en un nodo remoto. En cualquiera de estos dos casos, -w dará un error y no actualizará la configuración.

---

-W: carga la configuración del fichero indicado con los parámetros especificados en dicho fichero sobre el kernel, cueste lo que cueste. Esto puede significar expulsar procesos y mandarlos a sus nodos de vuelta, asícomo traerse al nodo local todos los procesos remotos lanzados localmente. Internamente, con un -W, realmente setpe hace primero un -off -vemos más adelante cómo funciona -off-, y después hace un -w.

---

-c: realiza toda la operativa que realizaría -w, solo que no graba el resultado en el kernel. Esta opción es útil para verificar una configuración sin instalarla en la máquina.
Cualquiera de estas tres opciones puede ser acompañada por la opción -g numero. Si la utilizamos, septe informará al kernel que el número máximo de gateways que se interponen entre el nodo local y el más remoto de los nodos es, a lo sumo, número. Si no indicamos esta opción, simplemente no modificamos el parámetro del kernel de número máximo de gateways, quedando como estaba. El número máximo de gateways intermedio que podemos especificar es 2.

Además de estas opciones, tenemos otras opciones interesantes de setpe. Estas son:

---

-r: lee la configuración del nodo actual, y la vuelca en la salida estándar, o en un archivo determinado con la opción -f nombrearchivo. Esta opción es muy útil para ver errores en la configuración en clusters muy grandes, en los que no hemos hecho un seguimiento de la configuración de todos y cada uno de sus nodos y hemos empleado cualquier mecanismo automatizado de configuración.

---

-off: esta opción desactiva openMosix en el nodo actual, es decir, bloquea las migraciones de salida de procesos locales, bloquea las migraciones de entrada de procesos remotos, manda las tareas que se ejecutan en el nodo actual de otros nodos de vuelta a sus nodos de origen, llama a los procesos remotos originados en el nodo local para que vuelvan, borra la tabla de nodos del nodo, y, por último, inhabilita openMosix en el nodo local.

Controlando los nodos con mosctl

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

De entre las opciones del comando mosctl, destacamos:

---

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 a MFS en openMosix.

---

nomfs: inhabilita el soporte a 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 status.

---

noquiet: deshace los efectos de quiet.
Como vemos, todas estas opciones tienen un modificador que habilita alguna propiedad, y otro modificador que la inhabilita. Hay otros modificadores de un solo comando para mosctl, que son:

---

bring: trae de vuelta a todos los procesos que se han generado localmente pero que se ejecutan en un nodo remoto. Además, internamente realiza primero la misma operación que lstay, y deja el estado en lstay. No retorna hasta que no han vuelto todos los procesos remotos generados localmente.

---

expel: manda de vuelta a sus nodos de origen a todos los nodos que se ejecutan en el nodo local pero fueron generados en un nodo remoto. Además, internamente realiza primero la misma operación que block, y deja el estado en block. No retorna hasta que no han salido todos los procesos remotos del nodo local.

---

Por ejemplo, para apagar ordenadamente un nodo en un cluster openMosix sin perder ningún proceso, debemos hacer:

---

mosctl expel

---

---

mosctl bring

---

Después de estos comandos, el nodo no aceptará ni que migren al nodo local procesos generados en un nodo externo, ni que ningún nodo local migre a otro nodo. Además, no se ejecutará ningún proceso remoto en el nodo local ni ningún proceso local en el nodo remoto. Es decir, nuestra máquina está desligada del cluster openMosix, por lo que si se apaga la máquina de un tirón de cable no afectará al resto del cluster.

Existen, además de estos, un conjunto de modificadores que tienen un parámetro adicional: el identificador de un nodo dentro del cluster. Estos modificadores permiten obtener información sobre cualquier nodo del cluster. Estos modificadores son:

---

getload nodo: siendo nodo un nodo válido en el cluster, este modificador nos devuelve la carga que actualmente tiene dicho nodo. Este parámetro de carga no corresponde al parámetro de carga del kernel al que estamos acostumbrados, sino al parámetro de carga que calcula openMosix y usa openMosix.

---

getspeed nodo: da la velocidad relativa de dicho nodo. Esta velocidad es relativa, y se supone que un Pentium-III a 1GHz es un procesador de 1000 unidades de velocidad.

---

getmem nodo: da la memoria lógica libre y la memoria lógica total de un nodo particular del cluster.

---

getfree nodo: da la memoria física libre y la memoria física total de un nodo particular del cluster. Como estudiamos anteriormente al hablar de mosmon, la memoria física libre y la memoria lógica libre pueden no coincidir.

---

getutil nodo: siendo nodo un nodo válido en el cluster, nos da el grado de uso de dicho nodo en el cluster. Discutimos el parámetro de grado de uso de un nodo al hablar del comando mosmon.

---

isup nodo: nos indica si el nodo indicado está activo o no.

---

getstatus nodo: nos dará el estado del nodo indicado. En este estado incluye también información sobre si el nodo permite migraciones de entrada, si permite migraciones de salida, si bloquea todas las migraciones, si está activo, y si está propagando información sobre su carga.

---

Por ultimo, tenemos un modificador que nos permite descubrir la IP y el identificador de nodo en openMosix asociado a un nodo en particular. Es:

---

mosctl whois dirección

---

y podemos tener como parámetro dirección el identificador de nodo, en cuyo caso este comando nos devolverá la IP, o la IP, en cuyo caso nos devolverá el identificador de nodo, o el nombre de la máquina, en cuyo caso nos devolverá el identificador de nodo. Este comando también nos indica si la máquina indicada no pertenece al cluster openMosix.

Si llamamos a mosctl whois sin ningún parámetro adicional, este comando nos devolverá el identificador del nodo local.

Forzando migraciones

Para forzar una migración en un cluster openMosix, debemos usar el comando migrate.

El comando migrate toma dos parámetros: el primero es el PID del proceso que queremos hacer migrar, y el segundo parámetro es donde queremos que migre. Este segundo parámetro debe ser el identificador válido 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, y son:

---

home: fuerza a migrar a un proceso al nodo donde fue generado.

---

balance: fuerza a migrar a 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 siempre 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 como se va a comportar frente a la migración, o donde preferimos 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 al mínimo. 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:

---

mosrun donde migracion 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.

migracion: si se bloquea o no el proceso en el nodo de destino.

tipo: tipo de proceso que se lanzará.

comando: nombre del proceso que se va a lanzar.

argumentos: argumentos del proceso que se va a lanzar

---

El modificador donde puede ser:
Un nodo de destino, al que el proceso migrará inmediatamente después de ser lanzado, si esto es posible.

-h, en cuyo caso será el nodo local.

-jlista: en este caso, inmediatamente después de lanzar el proceso, lo migrará a un nodo escogido aleatoriamente dentro de la lista de rangos lista. Esta lista es una lista de nodos y rangos, donde los rangos de nodos se determinan separando el menor y el mayor de rango por un guión. Por ejemplo, si indicamos el parámetro -j1,4-6,8,19-21, inmediatamente después de lanzar el proceso, de poder migrar el proceso, este migraría a un nodo aleatorio entre los nodos: 1,4,5,6,8,19,20 y 21.

---

El valor de la opción de migracion puede ser:
-l: el algoritmo de equilibrado automático de carga puede forzar una migración del proceso después de haber migrado dicho proceso al nodo de destino.

-L: una vez migrado al nodo de destino, el proceso se quedará en él y no podrá migrar de forma automática.

-k: el proceso heredará la propiedad de migrabilidad de su padre.

---

El valor de tipo es un dato muy importante que sirve de ayuda al algoritmo de migración automática de carga, y este puede ser:
-c: en un nodo de memoria infinita, el proceso tiene como cuello de botella la velocidad del procesador.

-i: en un nodo de memoria infinita, el proceso tiene como cuello de botella el acceso a disco.

---

Además de los modificadores anteriormente citados, con mosrun también podemos informar a openMosix sobre la forma en que openMosix debe mantener las estadísticas de uso de los recursos del sistema del proceso, datos fundamentales para que el algoritmo de equilibrado automático de carga tome decisiones correctas. Estos modificadores son:

---

-f: mantiene las estadísticas de uso de los recursos del sistema del proceso durante poco tiempo. Esto hace que las predicciones de openMosix sobre el comportamiento de un proceso sean mejores ante procesos que tienen durante su evolución comportamientos similares durante largos periodos de tiempo.

---

-s: mantiene las estadísticas de uso de los recursos del sistema del proceso a largo plazo. Esto hace que las predicciones de openMosix sobre el comportamiento de un proceso sean mejores ante procesos que cambian constantemente de comportamiento.

---

-n: mantiene las estadísticas de uso de los recursos del sistema del proceso desde el principio del programa hasta su finalización. Esto hace que las predicciones de openMosix sobre el comportamiento de un proceso sean mejores en procesos que están constantemente cambiando su comportamiento, y no podemos confiar en lo que hacían hace poco.
Hay también un conjunto de shell scripts que ayudan a no enfrentarse contra las complejidades de mosrun al lanzar una tarea en el uso diario del cluster, y que nos permiten realizar las tareas más frecuentes de mosrun de forma cómoda. Estas utilidades tienen siempre la misma sintaxis, que es:

---

utilidad proceso argumentos

---

Donde utilidad es el nombre del shell script, proceso el proceso que vamos a lanzar, y argumentos los argumentos del proceso que lanzaremos. Las utilidades que disponemos son:

---

cpujob: ejecuta un proceso, indicando a openMosix que si la memoria del nodo fuera infinita su cuello de botella sería el procesador.

---

iojob: ejecuta un proceso, indicando a openMosix que si la memoria del nodo fuera infinita su cuello de botella será el acceso a disco.

---

nomig: ejecuta un comando en el nodo local de forma que este no podrá migrar de forma automática.

---

nunhome: ejecuta un comando de forma que preferencialmente no migrará.

---

omrunon: ejecuta un proceso, e inmediatamente después lo migra, si es posible, al nodo especificado. La sintaxis de llamada es la de lanzar un proceso directamente desde línea de comando. Útil para lanzar un proceso desde línea de comandos recomendando un nodo de ejecución.

---

omsh: ejecuta un proceso, e inmediatamente después lo migra, si es posible, al nodo especificado. La sintaxis de llamada es la de sh como cuando lanzamos el proceso con sh -c, lo que lo hace especialmente útil para sustituir a sh en shell scripts.

---

fastdecay: ejecuta un proceso, indicando a openMosix que mantenga las estadísticas de uso de los recursos del sistema del proceso durante poco tiempo. Esto hace que las predicciones de openMosix sobre el comportamiento de un proceso sean mejores ante procesos que tienen durante su evolución comportamientos similares durante largos periodos de tiempo.

---

slowdecay: ejecuta un proceso, indicando a openMosix que mantenga las estadísticas de uso de los recursos del sistema del proceso a largo plazo. Esto hace que las predicciones de openMosix sobre el comportamiento de un proceso sean mejores ante procesos que cambian constantemente de comportamiento.

---

nodecay: ejecuta un proceso, indicando a openMosix que mantenga las estadísticas de uso de los recursos del sistema del proceso desde el principio del programa hasta su finalización. Esto hace que las predicciones de openMosix sobre el comportamiento de un proceso sean mejores en procesos que están constantemente cambiando su comportamiento, y no podemos confiar en lo que hacían hace poco.

---

Como sucedía en el caso de mosrun, si lanzamos un proceso con una de estas utilidades en una máquina sin soporte openMosix habilitado, o con este mal configurado, el proceso se lanzará perfectamente de forma local.

openMosixView

No podemos hablar de openMosix pasando por alto openMosixView, que es una cómoda y amigable aplicación de monitorización 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. Y en la mayor parte de las instalaciones de openMosix, la mayor parte de los nodos son cajas sin monitor, ratón o teclado con una instalación mínima de Linux, por lo que en principio openMosixView solo sería un problema para el administrador, que puede no tener interés en instalar las 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 necesidad de bibliotecas y compiladores preinstalados mínima, openMosixView necesita muchas bibliotecas instaladas para ejecutarse y más aún para compilar, lo que hace poco práctico compilar y usar openMosixView en un nodo minimal.

Sin embargo, esto no quita que openMosixView sea una excelente herramienta de gran utilidad, y 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, recomiendo a todo administrador que se la descargue y la instale en los nodos que quiera utilizar como terminal gráfico del cluster.