DEL DOCUMENTO OFICIAL:

Copyright c miKeL a.k.a.mc2 & Kris Buytaert. 
Permission is granted to copy, distribute and/or modify this document 
under the terms of the GNU Free Documentation License, Version 1.2 
or any later version published by the Free Software Foundation; 
with no Invariant Sections, no Front­Cover Texts, and no Back­Cover Texts. 
A copy of the license is included in the section entitled GNU 
Free Documentation License. 

          

INSTALACION DE UN CLUSTER OPENMOSIX 
  
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. 

1. El primero es compilar e instalar un kernel con soporte openMosix; 
2. El segundo, compilar e instalar las herramientas de area de usuario. 
́
3. El tercer paso es configurar los demonios del sistema para que cada m  quina del cluster siga  
el comportamiento que esperamos.
4. Y el cuarto paso es crear el fichero del mapa del cluster. Este cuarto paso es necesario si no 
usamos la herramienta de autodetección de nodos. 

1 ­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 SourceForge.
     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
   Descargamos el archivo con el parche:

sudo wget http://switch.dl.sourceforge.net/sourceforge/openmosix/openMosix-2.4.20-2.gz

    
     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. 
 Descargamos el archivo con el kernel:

sudo wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.20.tar.gz

     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 open­ Mosix 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 open­ Mosix 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 unica 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 util 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 util 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 ultimo lector ha cerrado el pipe con  
́
ioctl(pipefd, TCSBRK, 2). Por ultimo, 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 ultimas 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 ultimo, 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 ultimo, 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.