Está en la página 1de 6

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:

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 á

que tengamos mucha seguridad en lo que estamos haciendo, debemos activar esta opci ́ n de compilaci ́ n.

colgar un nodo del antiguo proyecto Mosix s ́ lo haci ́ ndole un escaneo de puertos UDP. Salvo

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 ó

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.

de estas excepciones est ́ desactivado para todos los procesos, y cada proceso

Disable OOM Killer (NEW): Las ultimas versiones del kernel de Linux incluyen una caracter

sticá

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 simá

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

sabemos recompilar el kernel e instalar un kernel nuevo no tendremos ning ́ n problema con el kernel de openMosix.

de cualquier forma, si