Puede construirse físicamente un cluster openMosix de la misma forma que se construye un cluster Beowulf. Por otro lado, desde el punto de vista del programario, la construcción de un cluster openMosix es distinta.
La construcción de un cluster openMosix se compone de varios pasos.
- el primero es compilar e instalar un kernel con soporte openMosix;
- el segundo, compilar e instalar las herramientas de área de usuario.
- El tercer paso es configurar los demonios del sistema para que cada máquina del cluster siga el comportamiento que esperamos,
- y el cuarto paso es crear el fichero del mapa del cluster. Este cuarto paso sólo es necesario si no usamos la herramienta de autodetección de nodos.
Instalación del kernel de openMosix
El primer paso para instalar el kernel de openMosix es descargar el tarball. No es conveniente usar la versión del kernel del CVS, ya que suele no ser muy estable. Puede descargarse el tarball del parche del kernel de openMosix de la dirección en SourceForge5.5.
En las fechas en las que se escribe este capítulo, la versión del kernel openMosix para el kernel de Linux 2.4.20 va por su versión 2.
Una vez descargado el parche del kernel openMosix habrá que descomprimirlo:
gunzip openMosix-2.4.20-2.gz
Después de descargar el parche openMosix, habrá que descargar el kernel de Linux. Un posible sitio para descargarlo es http://www.kernel.org .
Hay que descargar el kernel correspondiente a la versión del parche que hemos descargado. Esto quiere decir que un parche 2.4.X-Y valdrá para el kernel 2.4.X. Por ejemplo, el parche 2.4.20-2 sólo puede ser aplicado sobre el kernel 2.4.20.
Una vez descargado el kernel de Linux lo descomprimimos:
tar -zxf linux-2.4.20.tar.gz
Movemos el directorio donde hemos descomprimido el kernel a linux-openmosix:
mv linux-2.4.20 linux-openmosix
y aplicamos el parche de openMosix:
patch -p0 
openMosix-2.4.20-2
Entramos en el directorio del kernel de Linux:
cd linux-openmosix
Y lanzamos el menú de configuración del kernel:
make menuconfig
para la configuración a través de menús con ncurses, o:
make xconfig
para la configuración a través de X-Window.
Opciones del kernel de openMosix
El siguiente paso para configurar el kernel de openMosix es entrar en la opción openMosix -la primera opción del menú principal de la pantalla de configuración del kernel-. Allí encontraremos un menú con todas las opciones propias de openMosix. Estas opciones son:
openMosix process migration support: Esta opción permite activar el soporte a la migración de procesos en openMosix. Esto incluye tanto la migración forzada por el administrador como la migración transparente automática de procesos, el algoritmo de equilibrado de carga y el Memory Ushering. Si no activamos esta opción, no tenemos openMosix. Por ello, si estamos leyendo este documento, nos interesa tener esta opción activada.
Support clusters with a complex network topology: Las máquinas que pertenecen al cluster openMosix pueden pertenecer a la misma red IP, estando conectadas por un hub o por un switch. En este caso, en openMosix consideramos que la topología de la red es simple, lo que permite realizar algunas modificaciones en los algoritmos de calculo de la función de coste del algoritmo de equilibrado de carga que hacen muchísimo más eficiente su cálculo. También mejora la eficiencia del algoritmo de colecta automática de información del cluster. Si tenemos todas las máquinas del cluster conectadas a través de hubs o switchs -es decir, que un paquete openMosix nunca necesitará pasar por un router- podemos aumentar sensiblemente el rendimiento de nuestro cluster desactivando esta opción.
Maximum network-topology complexity to support (2-10): Si activamos la opción anterior, aparecerá esta opción. En esta opción se nos pregunta cuantos niveles de complejidad hay entre las dos máquinas más lejanas del cluster, entendiendo por niveles de complejidad el número de routers intermedios más uno. Si ponemos un número más alto de la cuenta, no tendremos todo el rendimiento que podríamos tener en nuestro cluster. Si ponemos un número más bajo de la cuenta, no podrán verse entre sí las máquinas que tengan más routers intermedios que los indicados en este parámetro menos uno.
Stricter security on openMosix ports: Esta opción permite un chequeo adicional sobre los paquetes recibidos en el puerto de openMosix, y unas comprobaciones adicionales del remitente. Aunque esto suponga una pequeña pérdida de rendimiento, permite evitar que mediante el envio de paquetes quebrantados se pueda colgar un nodo del cluster. De hecho, hasta hace poco tiempo se podía colgar un nodo del antiguo proyecto Mosix sólo haciéndole un escaneo de puertos UDP. Salvo que tengamos mucha seguridad en lo que estamos haciendo, debemos activar esta opción de compilación.
Level of process-identity disclosure (0-3): Este parámetro indica la información que va a tener el nodo de ejecución real de la tarea sobre el proceso remoto que está ejecutando. Aquí debemos destacar que esta información siempre estará disponible en el nodo raíz -en el nodo en el que se originó la tarea-; limitamos la información sólo en el nodo en el que se ejecuta la tarea si este es distinto del nodo raíz. Este es un parámetro de compromiso: valores más bajos aseguran mayor privacidad, a cambio de complicar la administración. Valores más altos hacen más cómoda la administración del cluster y su uso, pero en algunos escenarios pueden violar la política de privacidad del departamento o de la empresa.
Un 0 significa que el nodo remoto que ejecuta el proceso migrado no tiene ninguna información relativa al proceso migrado que se ejecuta en dicho nodo. Este modo paranoico hace la administración del cluster realmente complicada, y no hay ninguna razón objetiva para recomendarlo.
Un 1 significa que el nodo remoto que ejecuta el proceso migrado tiene como única información el PID del proceso. Este es un modo paranoico, pero que permite al menos al administrador del cluster saber con un poco de más comodidad qué es lo que está pasando en caso de problemas. Es un nodo útil cuando usamos máquinas no dedicadas que estén en los despachos de los usuarios del cluster, y no queremos protestas entre los usuarios del cluster sobre quién está haciendo más uso del cluster.
Un 2 significa que el nodo remoto que ejecuta el proceso migrado conoce PID , el usuario propietario y el grupo propietario del proceso. Este es un modo útil en clusters dedicados y no dedicados cuando sabemos que no va a haber discusiones entre los usuarios porque alguien use los recursos del cluster más de la cuenta. Es una buena opción si tenemos nodos no dedicados en despachos de usuarios donde cualquier usuario no tiene cuentas en las máquinas de los otros, para asegurar una cantidad razonable de privacidad.
Un 3 significa que en el nodo remoto que ejecuta el proceso migrado se tiene exactamente la misma información de los procesos migrados que de los procesos locales. Esto significa que para la información de los procesos el sistema se comporta realmente como un sistema SSI. Este modo es recomendable en los escenarios donde todos los usuarios tienen cuentas en todas las máquinas del cluster, con lo que mantener la privacidad del espacio de procesos ya es de por si imposible, y bloquear esta información solo complica el uso y la administración del cluster. Este es el escenario más habitual de uso de un cluster, por lo que en caso de dudas es mejor que usemos este nivel de privacidad. De cualquier forma, cualquier proceso puede variar su nivel particular de privacidad grabando desde el propio proceso su nuevo nivel de privacidad en el archivo /proc/self/disclosure.
Create the kernel with a -openmosix extension: Si activamos esta opción, el nombre simbólico del kernel llevará la extensión -openmosix. Esto es importante a la hora de buscar y enlazar los módulos. Debemos activar esta opción si, teniendo la misma versión de kernel base y de kernel para openMosix, queremos que los módulos del kernel openMosix y los módulos del kernel antiguo no sean compartidos. En nuestro caso significa que si activamos esta opción podemos tener un kernel 2.4.20 en el sistema y un kernel openMosix 2.4.20-2 al mismo tiempo, y que cada uno tendrá sus módulos por separado y guardados en directorios distintos. En principio, es una buena idea activar esta opción para evitar problemas de efectos laterales con un kernel ya existente en el sistema.
openMosix File-System: Si activamos esta opción podremos usar el sistema de ficheros oMFS, por lo que debemos activar esta opción sólo si vamos a usar el oMFS.
Poll/Select exceptions on pipes: Esta opción es interesante, aunque separa a openMosix de una semántica SSI pura. En Unix, un proceso que escriba en un pipe en principio no es interrumpido si otro proceso abre el mismo pipe para leer o ya lo tenía abierto y lo cierra. Activando esta opción nos separamos de Posix: un proceso escritor en un pipe puede recibir una excepción cuando otro proceso abra un pipe para leer dicho pipe, y puede recibir también una excepción si el pipe se queda sin lectores.
Activamos el lanzamiento de la excepción de lectura del pipe con la llamada al kernel ioctl(pipefd, TCSBRK, 1), y activamos la señal de que el último lector ha cerrado el pipe con ioctl(pipefd, TCSBRK, 2). Por último, podemos tener una estimación aproximada de la cantidad de información que los procesos lectores han pedido leer de un pipe en particular con la llamada al sistema ioctl(pipefd, TIOCGWINSZ, 0). Esta llamada no da un valor exacto, y puede equivocarse -pensemos que nos da apenas una estimación a la baja-. Por lo tanto, en caso de equivocación de la llamada, suele ser porque el proceso lector lee más de lo estimado. Aunque activemos esta opción, por defecto, el envío de estas excepciones está desactivado para todos los procesos, y cada proceso que quiera usar estas excepciones debe activar su posibilidad con ioctl. En principio no activamos esta opción, salvo que queramos usarla para nuestros propios programas.
Disable OOM Killer (NEW): Las últimas versiones del kernel de Linux incluyen una característica bastante discutida: el OOM Killer. Esta opción nos permite inhabilitar el OOM Killer, y evitar los problemas que este suele causar. En caso de duda, es recomendable habilitar esta opción -es decir, inhabilitar el OOM Killer-.
Por último, no debemos olvidar que todos los nodos del cluster deben tener el mismo tamaño máximo de memoria, o si no las tareas no migrarán. Para ello, entramos en la opción Processor type and features, y en la opción High Memory Support asignamos el mismo valor a todos los nodos del cluster.
Después de esto, nuestro kernel estará listo para poder usar openMosix. Ahora seleccionamos las opciones adicionales del kernel que coincidan con nuestro hardware y el uso que le queramos dar a nuestro Linux, grabamos la configuración y hacemos:
make dep
lo que calcula las dependencias entre partes del kernel -qué se compila y qué no se compila, entre otras cosas-. Después limpiamos el kernel de restos de compilaciones anteriores, que pudieran tener una configuración distinta:
make clean
Compilamos el kernel:
make bzImage
Compilamos los módulos:
make modules
Instalamos los módulos:
make modules_install
y ahora copiamos el nuevo kernel en el directorio /boot:
cp arch/i386/boot/bzImage /boot/kernelopenMosix
por último, creamos una entrada en lilo.conf para el nuevo kernel; por ejemplo:
image=/boot/kernelopenMosix
label=om
root=/dev/hda1
initrd=/boot/initrd.img
append=" devfs=mount"
read-only
donde /dev/hda1 es el dispositivo de bloques donde encontramos el directorio raíz de Linux; en nuestro sistema puede cambiar. Compilamos la tabla del LILO con el comando:
lilo
y listo. Ya tenemos un kernel listo para poder usarlo en un nodo openMosix.
Errores más frecuentes al compilar e instalar el kernel
Los errores más frecuentes a la hora de configurar el kernel de openMosix son:
Las aplicaciones no migran de todos los nodos a todos los nodos: La causa de este error suele ser que hemos olvidado poner en todas las máquinas el mismo tamaño máximo de memoria.
El parche no se aplica correctamente: Tenemos que usar un vanilla kernel, es decir, un kernel tal y como Linus Torvalds lo distribuye. Particularmente, los kernels que vienen con las distribuciones de Linux no valen ya que están demasiado parcheados.
No existe el directorio/proc/hpc: O no hemos arrancado con el kernel openMosix, o se nos ha olvidado activar la primera opción de openMosix process migration support al compilar el kernel.
Uso la ultimísima versión del gcc, y el kernel de openMosix no compila: No es un problema de openMosix, es un problema del kernel de Linux. Cualquier versión de gcc que compile el kernel de Linux compila el kernel de openMosix; y casi todas las distribuciones de Linux modernas traen un paquete con una versión del backend de gcc para compilar el kernel de Linux.
Además de estos problemas, tendremos los problemas habituales de instalar un kernel nuevo: olvidarnos de ejecutar el comando lilo, olvidarnos de instalar los módulos... de cualquier forma, si sabemos recompilar el kernel e instalar un kernel nuevo no tendremos ningún problema con el kernel de openMosix.
