\newpage
%===========================================================================
%       x.14 > Instalaci\'n de un cluster openMosix
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
 \scalebox{1.2}[1.2]{\includegraphics[bb = -150 150 0 0, scale=1.2]{./TuXes/tux-tweaking.png}}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
%       \includegraphics[-250,650][0,0]{./TuXes/tux-tweaking}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{INSTALACI\'ON DE UN CLUSTER OPENMOSIX}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em A good traveler has no fixed plans,}}

\hspace{1in}\textcolor{blue_omosix}{{\em and is not intent on arriving. }}

\hspace{4in}\textcolor{blue_omosix}{{\em Lao Tzu}}

\vspace{0.5in}
\end{latexonly}
%===========================================================================
 Puede construirse f\'\i 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\'on de un cluster
 openMosix es distinta.

 La construcci\'on de un cluster openMosix se compone de varios pasos.
\begin{enumerate}
  \item el primero es compilar e instalar un kernel con soporte openMosix;
  \item  el segundo, compilar e instalar las herramientas de \'area de
  usuario. 
  \item El tercer paso es configurar los demonios del sistema para que
  cada m\'aquina del cluster siga el comportamiento que esperamos, 
  \item y el cuarto paso es crear el fichero del mapa del
  cluster. Este cuarto paso s\'olo es necesario si no usamos la
  herramienta de autodetecci\'on de nodos.
\end{enumerate}
%===========================================================================
\subsection{Instalaci\'on del kernel de openMosix}
El primer paso para instalar el kernel de openMosix es descargar el
tarball. No es conveniente usar la versi\'on del kernel del CVS, ya
que suele no ser muy estable. Puede descargarse el tarball del parche
del kernel de openMosix de la direcci\'on en SourceForge\footnote{\htmladdnormallink{http://sourceforge.net/project/showfiles.php?group\_id=46729}{http://sourceforge.net/project/showfiles.php?group_id=46729}}.

 En las fechas en las que se escribe este cap\'\i tulo, la versi\'on
 del kernel openMosix para el kernel de Linux 2.4.20 va por su
 versi\'on 2.

 Una vez descargado el parche del kernel openMosix habr\'a que descomprimirlo:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt gunzip openMosix-2.4.20-2.gz}}
\vspace{.1in}

 Despu\'es de descargar el parche openMosix, habr\'a que descargar el kernel de
 Linux. Un posible sitio para descargarlo es
 \htmladdnormallink{http://www.kernel.org}{http://www.kernel.org} .

\vspace{.2in}
 Hay que descargar el kernel correspondiente a la versi\'on del parche
 que hemos descargado. Esto quiere decir que un parche 2.4.X-Y
 valdr\'a para el kernel 2.4.X. Por ejemplo, el parche 2.4.20-2 s\'olo
 puede ser aplicado sobre el kernel 2.4.20.

\vspace{.2in}
 Una vez descargado el kernel de Linux lo descomprimimos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt tar -zxf linux-2.4.20.tar.gz}}
\vspace{.1in}

 Movemos el directorio donde hemos descomprimido el kernel a {\em linux-openmosix}:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mv linux-2.4.20 linux-openmosix}}
\vspace{.1in}

 y aplicamos el parche de openMosix:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt patch -p0 $<$ openMosix-2.4.20-2}}
\vspace{.1in}

 Entramos en el directorio del kernel de Linux:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cd linux-openmosix}}
\vspace{.1in}

 Y lanzamos el men\'u de configuraci\'on del kernel:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt make menuconfig}}
\vspace{.1in}

 para la configuraci\'on a trav\'es de men\'us con {\em ncurses}, o:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt make xconfig}}
\vspace{.1in}

 para la configuraci\'on a trav\'es de X-Window.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Opciones del kernel de openMosix}}
 El siguiente paso para configurar el kernel de openMosix es entrar en
 la opci\'on {\tt openMosix} -la primera opci\'on del men\'u principal de
 la pantalla de configuraci\'on del kernel-. All\'\i\  encontraremos un
 men\'u con todas las opciones propias de openMosix. Estas opciones
 son:

\vspace{.1in}
{\bf openMosix process migration support}: Esta opci\'on permite activar
el soporte a la migraci\'on de procesos en openMosix. Esto incluye
tanto la migraci\'on forzada por el administrador como la migraci\'on
transparente autom\'atica de procesos, el algoritmo de equilibrado de
carga y el {\em Memory Ushering}. Si no activamos esta opci\'on, no
tenemos openMosix. Por ello, si estamos leyendo este documento,
nos interesa tener esta opci\'on activada.

\vspace{.1in}
{\bf Support clusters with a complex network topology}: Las m\'aquinas 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\'\i a de la red es simple, lo
que permite realizar algunas modificaciones en los algoritmos de
calculo de la funci\'on de coste del algoritmo de equilibrado de carga
que hacen much\'\i simo m\'as eficiente su c\'alculo. Tambi\'en mejora
la eficiencia del algoritmo de colecta autom\'atica de informaci\'on
del cluster. Si tenemos todas las m\'aquinas del cluster conectadas a
trav\'es de hubs o switchs -es decir, que un paquete openMosix nunca
necesitar\'a pasar por un router- podemos aumentar sensiblemente el
rendimiento de nuestro cluster desactivando esta opci\'on.

\vspace{.1in}
{\bf Maximum network-topology complexity to support (2-10)}: Si activamos
la opci\'on anterior, aparecer\'a esta opci\'on. En esta opci\'on se
nos pregunta cuantos niveles de complejidad hay entre las dos
m\'aquinas m\'as lejanas del cluster, entendiendo por niveles de
complejidad el n\'umero de routers intermedios m\'as uno. Si ponemos
un n\'umero m\'as alto de la cuenta, no tendremos todo el rendimiento
que podr\'\i amos tener en nuestro cluster. Si ponemos un n\'umero
m\'as bajo de la cuenta, no podr\'an verse entre s\'\i\ las m\'aquinas
que tengan m\'as routers intermedios que los indicados en este
par\'ametro menos uno.

\vspace{.1in}
{\bf Stricter security on openMosix ports}: Esta opci\'on permite un
chequeo adicional sobre los paquetes recibidos en el puerto de
openMosix, y unas comprobaciones adicionales del remitente. Aunque
esto suponga una peque\~{n}a p\'erdida 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\'\i a colgar un
nodo del antiguo proyecto Mosix s\'olo haci\'endole un escaneo de
puertos UDP. Salvo que tengamos mucha seguridad en lo que estamos
haciendo, debemos activar esta opci\'on de compilaci\'on.

\vspace{.1in}
{\bf Level of process-identity disclosure (0-3)}: Este par\'ametro indica
la informaci\'on que va a tener el nodo de ejecuci\'on real de la
tarea sobre el proceso remoto que est\'a ejecutando. Aqu\'\i\  debemos
destacar que esta informaci\'on siempre estar\'a disponible en el nodo
ra\'\i z -en el nodo en el que se origin\'o la tarea-; limitamos la
informaci\'on s\'olo en el nodo en el que se ejecuta la tarea si este
es distinto del nodo ra\'\i z. Este es un par\'ametro de compromiso:
valores m\'as bajos aseguran mayor privacidad, a cambio de complicar
la administraci\'on. Valores m\'as altos hacen m\'as c\'omoda la
administraci\'on del cluster y su uso, pero en algunos escenarios
pueden violar la pol\'\i tica de privacidad del departamento o de la
empresa. 

\vspace{.1in}
 Un {\bf 0} significa que el nodo remoto que ejecuta el proceso migrado no
 tiene ninguna informaci\'on relativa al proceso migrado que se
 ejecuta en dicho nodo.  Este modo paranoico hace la administraci\'on
 del cluster realmente complicada, y no hay ninguna raz\'on
 objetiva para recomendarlo.

\vspace{.1in}
 Un {\bf 1} significa que el nodo remoto que ejecuta el proceso migrado
 tiene como \'unica informaci\'on el PID del proceso.  Este es un modo
 paranoico, pero que permite al menos al administrador del cluster
 saber con un poco de m\'as comodidad qu\'e es lo que est\'a pasando
 en caso de problemas. Es un nodo \'util cuando usamos m\'aquinas no
 dedicadas que est\'en en los despachos de los usuarios del cluster, y
 no queremos protestas entre los usuarios del cluster sobre qui\'en
 est\'a haciendo m\'as uso del cluster.

\vspace{.1in}
 Un {\bf 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\'as de la cuenta. Es
 una buena opci\'on si tenemos nodos no dedicados en despachos de
 usuarios donde cualquier usuario no tiene cuentas en las m\'aquinas
 de los otros, para asegurar una cantidad razonable de privacidad.

\vspace{.1in}
 Un {\bf 3} significa que en el nodo remoto que ejecuta el proceso migrado
 se tiene exactamente la misma informaci\'on de los procesos migrados
 que de los procesos locales. Esto significa que para la informaci\'on
 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\'aquinas del cluster, con lo
 que mantener la privacidad del espacio de procesos ya es de por si
 imposible, y bloquear esta informaci\'on solo complica el uso y la
 administraci\'on del cluster. Este es el escenario m\'as 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
 {\em /proc/self/disclosure}.

\vspace{.1in}
{\bf Create the kernel with a {\em -openmosix} extension}: Si activamos esta
opci\'on, el nombre simb\'olico del kernel llevar\'a la extensi\'on
{\em -openmosix}. Esto es importante a la hora de buscar y enlazar los
m\'odulos. Debemos activar esta opci\'on si, teniendo la misma
versi\'on de kernel base y de kernel para openMosix, queremos que los
m\'odulos del kernel openMosix y los m\'odulos del kernel antiguo no
sean compartidos. En nuestro caso significa que si activamos esta
opci\'on 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\'a sus
m\'odulos por separado y guardados en directorios distintos. En
principio, es una buena idea activar esta opci\'on para evitar
problemas de efectos laterales con un kernel ya existente en el
sistema.

\vspace{.1in}
{\bf openMosix File-System}: Si activamos esta opci\'on podremos usar el
sistema de ficheros oMFS, por lo que debemos activar esta opci\'on
s\'olo si vamos a usar el oMFS.

\vspace{.1in}
{\bf Poll/Select exceptions on pipes}: Esta opci\'on es interesante,
aunque separa a openMosix de una sem\'antica 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\'\i a abierto y lo
cierra. Activando esta opci\'on nos separamos de Posix: un proceso
escritor en un pipe puede recibir una excepci\'on cuando otro proceso
abra un pipe para leer dicho pipe, y puede recibir tambi\'en una
excepci\'on si el pipe se queda sin lectores.

Activamos el lanzamiento
de la excepci\'on de lectura del pipe con la llamada al kernel
{\em ioctl(pipefd, TCSBRK, 1)}, y activamos la se\~{n}al de que el
\'ultimo lector ha cerrado el pipe con {\em ioctl(pipefd, TCSBRK, 2)}.
Por \'ultimo, podemos tener una estimaci\'on aproximada de la cantidad
de informaci\'on que los procesos lectores han pedido leer de un pipe
en particular con la llamada al sistema {\em ioctl(pipefd, TIOCGWINSZ,
0)}. Esta llamada no da un valor exacto, y puede equivocarse -pensemos
que nos da apenas una estimaci\'on a la baja-. Por lo tanto, en caso
de equivocaci\'on de la llamada, suele ser porque el proceso lector
lee m\'as de lo estimado. Aunque activemos esta opci\'on, por defecto,
el env\'\i o de estas excepciones est\'a desactivado para todos los
procesos, y cada proceso que quiera usar estas excepciones debe
activar su posibilidad con {\tt ioctl}. En principio no activamos esta
opci\'on, salvo que queramos usarla para nuestros propios programas.

\vspace{.1in}
{\bf Disable OOM Killer (NEW)}: Las \'ultimas versiones del kernel de
Linux incluyen una caracter\'\i stica bastante discutida: el {\em OOM
Killer}. Esta opci\'on nos permite  inhabilitar
el OOM Killer, y evitar los problemas que este suele causar. En caso
de duda, es recomendable habilitar esta opci\'on -es decir,
inhabilitar el {\em OOM Killer}-.

\vspace{.2in}
 Por \'ultimo, no debemos olvidar que todos los nodos del cluster
 deben tener el mismo tama\~{n}o m\'aximo de memoria, o si no las
 tareas no migrar\'an. Para ello, entramos en la opci\'on {\em Processor
 type and features}, y en la opci\'on {\em High Memory Support} asignamos
 el mismo valor a todos los nodos del cluster.

 Despu\'es de esto, nuestro kernel estar\'a 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\'on y hacemos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt make dep}}
\vspace{.1in}

 lo que calcula las dependencias entre partes del kernel -qu\'e se
 compila y qu\'e no se compila, entre otras cosas-. Despu\'es
 limpiamos el kernel de restos de compilaciones anteriores, que
 pudieran tener una configuraci\'on distinta:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt make clean}}
\vspace{.1in}

 Compilamos el kernel:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt make bzImage}}
\vspace{.1in}

 Compilamos los m\'odulos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt make modules}}
\vspace{.1in}

 Instalamos los m\'odulos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt make modules\_install}}
\vspace{.1in}

 y ahora copiamos el nuevo kernel en el directorio {\em /boot}:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cp arch/i386/boot/bzImage /boot/kernelopenMosix}}
\vspace{.1in}

\vspace{.2in}
 por \'ultimo, creamos una entrada en {\em lilo.conf} para el nuevo kernel; por ejemplo:

\begin{verbatim}
image=/boot/kernelopenMosix
        label=om
        root=/dev/hda1
        initrd=/boot/initrd.img
        append=" devfs=mount"
        read-only
\end{verbatim}

donde {\em /dev/hda1} es el dispositivo de bloques donde encontramos
el directorio ra\'\i z de Linux; en nuestro sistema puede
cambiar. Compilamos la tabla del LILO con el comando:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt lilo}}
\vspace{.1in}

 y listo. Ya tenemos un kernel listo para poder usarlo en un nodo openMosix.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Errores m\'as frecuentes al compilar e instalar el kernel}}
 Los errores m\'as frecuentes a la hora de configurar el kernel de openMosix son:

\vspace{.1in}
{\bf 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\'aquinas el mismo tama\~{n}o m\'aximo de memoria.

\vspace{.1in}
{\bf El parche no se aplica correctamente:} Tenemos que usar un {\em 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\'an demasiado parcheados.

\vspace{.1in}
{\bf No existe el directorio{\em /proc/hpc}:} O no hemos arrancado con el
 kernel openMosix, o se nos ha olvidado activar la primera opci\'on de
 {\em openMosix process migration support}  al compilar el kernel.

\vspace{.1in}
{\bf Uso la ultim\'\i sima versi\'on del gcc, y el kernel de openMosix no
 compila:} No es un problema de openMosix, es un problema del kernel de
 Linux. Cualquier versi\'on 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\'on del backend de gcc
 para compilar el kernel de Linux.

\vspace{.1in}
 Adem\'as de estos problemas, tendremos los problemas habituales de
 instalar un kernel nuevo: olvidarnos de ejecutar el comando {\em lilo},
 olvidarnos de instalar los m\'odulos... de cualquier forma, si
 sabemos recompilar el kernel e instalar un kernel nuevo no tendremos
 ning\'un problema con el kernel de openMosix.
%===========================================================================
\subsection{Instalaci\'on de las herramientas de \'area de usuario}
 Para configurar e instalar correctamente las herramientas de \'area
 de usuario no es necesario recompilar el kernel de openMosix; pero es
 fundamental tener descargado el kernel de openMosix, ya que
 necesitaremos sus cabeceras para compilar correctamente las
 herramientas de \'area de usuario.

 El primer paso para instalar las herramientas de \'area de usuario
 del proyecto openMosix es descargarlas. Podemos descargar las
 herramientas de \'area de usuario de
 \htmladdnormallink{http://www.orcero.org/irbis/openmosix}{http://www.orcero.org/irbis/openmosix} .

 Podemos descargar tambi\'en las herramientas de \'area de usuario de
 Sourceforge.

  Descargamos la \'ultima versi\'on -en la fecha en la que se escribe
  este documento, la \'ultima versi\'on de las herramientas de \'area
  de usuario son las 0.2.4-. La descomprimimos con:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt tar -zxf openMosixUserland-0.2.4.tgz}}
\vspace{.1in}

entramos en el directorio creado:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cd openMosixUserland-0.2.4}}
\vspace{.1in}

 y, antes de cualquier otro paso, leemos el archivo de instalaci\'on:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cat Installation  | more}}
\vspace{.1in}

\vspace{.2in}
 para la 0.2.4, la informaci\'on que tenemos en el es la misma que
 veremos en este cap\'\i tulo; pero versiones posteriores de las
 herramientas de \'area de usuario pueden tener opciones de
 configuraci\'on distintas.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Configurando las herramientas de \'area de usuario}}
 El paso siguiente para configurar las herramientas de \'area de
 usuario ser\'a editar el archivo {\em configuration} con nuestro editor
 de textos favorito.  Hay una opci\'on que debemos modificar
 obligatoriamente si queremos recompilar openMosix, y otras  opciones
 que no debemos tocar salvo que estemos muy seguros de lo que queremos
 hacer.

\vspace{.2in}
 Para una instalaci\'on est\'andar de openMosix en los directorios
 est\'andares apenas debemos modificar el valor de la variable
 {\em OPENMOSIX}. Esta variable debe contener el camino completo absoluto
 -no el camino relativo- del kernel de openMosix. Por ejemplo,
 {\em /usr/src/openmosix} es un camino v\'alido, y
 {\em /home/irbis/openMosix/linux-openmosix} tambi\'en lo
 es. {\em ../../linux-openmosix} no es un camino v\'alido, ya que es un
 camino relativo, y debe ser un camino absoluto. 

 En casi todos los casos, ahora solo tenemos que hacer:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt make all}}
\vspace{.1in}

 y los {\em Makefile} que acompa\~{n}an a openMosix se encargar\'an del
 resto: compilar\'an e instalar\'an las herramientas de \'area de
 usuario de openMosix y sus p\'aginas del manual. A pesar de que el
 c\'odigo nuevo tiene muy pocos warnings y no tiene errores -al menos,
 que se sepa-, el c\'odigo antiguo heredado de Mosix esta programado
 de una forma muy poco ortodoxa -por decirlo de una forma educada-,
 por lo que hay activadas todas las opciones de warning para
 buscar los errores existentes en el c\'odigo y eliminarlos.

\vspace{.2in}
 Una vez que la ejecuci\'on del {\em make all} est\'e terminada, las
 herramientas de \'area de usuario estar\'an instaladas y bien
 configuradas. 
%---------------------------------------------------------------------------
\subsubsection*{\underline{Otras opciones de configuraci\'on}}
 La opci\'on que hemos visto es la \'unica que deberemos modificar
 manualmente en condiciones normales. Pero hay otras opciones que
 pueden ser interesantes para algunos usuarios con necesidades muy
 espec\'\i ficas.  Otras opciones del archivo {\em configuration} son:

\vspace{.1in}
{\bf MONNAME:} nombre del programa monitor de openMosix. El programa monitor
del proyecto Mosix se llamaba {\tt mon}, lo que era un problema ya que
compart\'\i a nombre con una herramienta muy com\'un en Linux de
monitoramiento del sistema. La gente de Debian lo solucion\'o
cambiando el nombre de la aplicaci\'on para Debian de {\tt mon} a {\tt mmon};
pero en openMosix la aplicaci\'on la llamamos {\tt mosmon}. En principio,
es recomendable dejarlo en {\tt mosmon}, salvo que por razones de
compatibilidad inversa con algun script de Mosix queramos llamar a
esta aplicaci\'on {\tt mon} o {\tt mmon}.

\vspace{.1in}
{\bf CC:} Nombre del compilador de C. Casi siempre es {\tt gcc}.

\vspace{.1in}
{\bf INSTALLBASEDIR:} Ruta completa absoluta donde est\'a el
directorio ra\'\i z del sistema de ficheros donde queremos instalar
openMosix. Casi siempre es {\em /} .

\vspace{.1in}
{\bf INSTALLEXTRADIR:} Ruta completa absoluta donde est\'a el directorio
donde est\'an los directorios con las aplicaciones del sistema y su
documentaci\'on donde queremos instalar openMosix. Casi siempre es
{\em /usr} .

\vspace{.1in}
{\bf INSTALLMANDIR:} Ruta completa absoluta donde est\'a el directorio donde
est\'an las p\'aginas del manual donde queremos instalar
openMosix. Casi siempre es {\em /usr/man} .

\vspace{.1in}
{\bf CFLAGS:} Opciones de compilaci\'on en C para las herramientas de \'area
de usuario. Las opciones {\em -i./}, {\em -i/usr/include} y
{\em -i\$(OPENMOSIX)/include} son obligatorias; el resto la pondremos
seg\'un nuestro inter\'es particular -las opciones por defecto que
encontramos en el archivo de configuraci\'on son v\'alidas, y debemos
mantenerlas salvo que haya una buena raz\'on para no hacerlo-.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Errores frecuentes en la compilaci\'on e instalaci\'on de las herramientas}}
 Hay un conjunto de errores en la instalaci\'on de las herramientas de
 \'area de usuario que debemos conocer bien, ya que son objeto de
 frecuentes preguntas en la lista de correos. Estos errores son:

\vspace{.1in}
{\bf  Las herramientas de \'area de usuario no compilan:} ?`Hemos puesto
 correctamente el valor de la variable {\tt OPENMOSIX} en el archivo
 {\em configuration}? ?`Esta variable realmente apunta al kernel de
 openMosix? ?`Es realmente el kernel de openMosix, o un kernel normal?
 Recordemos que la variable {\tt OPENMOSIX} debe ser forzosamente un
 camino absoluto. Por \'ultimo, ?`tenemos instalado un compilador de C?

\vspace{.1in}
{\bf  Error {\em This is not Mosix!}} Este error se da cuando usamos las
 herramientas de \'area de usuario del proyecto Mosix sobre un kernel
 normal, o sobre un kernel openMosix. Tambi\'en se da si usamos el
 {\tt setpe} de una versi\'on de las herramientas de \'area de usuario
 anterior a la 0.2.4 sobre un kernel que no tiene soporte
 openMosix. Si es este \'ultimo caso, es muy recomendable usar una
 versi\'on de herramientas de \'area de usuario 0.2.4 o posterior; la
 0.2.4 es conocida por ser realmente estable, y no hay ninguna raz\'on
 objetiva para usar una versi\'on anterior. En cualquier otro caso,
 recordemos que las herramientas de \'area de usuario del proyecto Mosix
 no son libres; y que, de cualquier forma, no funcionan en openMosix.

\vspace{.1in}
{\bf  Error {\em This is not openMosix!}} Este error se da cuando usamos las
 herramientas de \'area de usuario de openMosix en un equipo que no
 est\'a usando un kernel con soporte openMosix. O estamos usando las
 herramientas de \'area de usuario de openMosix sobre un kernel Mosix,
 o no hemos arrancado con el kernel nuevo, o el kernel nuevo no tiene
 soporte a migraci\'on de procesos openMosix.
%===========================================================================
\subsection{Configurando la topolog\'\i a del cluster}
 Una vez que ya tenemos instalado nuestro kernel de openMosix y
 nuestras utilidades de \'area de usuario de openMosix, el siguiente
 paso que daremos ser\'a configurar la topolog\'\i a del cluster.

 Para configurar la topolog\'\i a del cluster openMosix tenemos dos
 procedimientos distintos.
\begin{enumerate}
\item  El primero es el procedimiento tradicional,
 consistente en un archivo por nodo donde se especifican las IPs de
 todos los nodos del cluster.
\item El segundo procedimiento consiste en
 emplear el demonio de autodetecci\'on de nodos. 
\end{enumerate}
Cada procedimiento tiene sus ventajas y sus inconvenientes.

\vspace{.2in}
 La configuraci\'on tradicional manual tiene como inconveniente que es
 m\'as laboriosa en clusters grandes: cada vez que queramos introducir
 un nodo nuevo en el cluster, debemos tocar el archivo de
 configuraci\'on de todos los nodos de dicho cluster para actualizar
 la configuraci\'on. Este m\'etodo nos permite, por otro lado, tener
 topolog\'\i as arbitrariamente complejas y grandes; tambi\'en es el
 m\'etodo m\'as eficiente.

\vspace{.2in}
 El segundo m\'etodo para configurar los nodos de un cluster openMosix
 es usar el demonio de detecci\'on autom\'atica de nodos, el
 {\em omdiscd}. Este m\'etodo es el m\'as c\'omodo, ya que el cluster casi
 se configura solo. Por otro lado, tiene dos pegas:
\begin{enumerate}
\item la primera, que todas las m\'aquinas del cluster deben estar en el mismo segmento
 f\'\i sico. Esto impide que el demonio de autodetecci\'on pueda ser
 usado en redes muy complejas.
\item La segunda, que todos los nodos cada
 cierto tiempo deben mandar un paquete de broadcast a todos los otros
 nodos de la red para escanear los nodos openMosix de la red.
\end{enumerate}
  Para pocos nodos, estos paquetes no afectan al rendimiento; pero en caso
 de clusters de tama\~{n}o medio o grande, la p\'erdida de rendimiento
 puede ser cr\'\i tica.

\vspace{.2in}
 Realmente el demonio de autodetecci\'on de nodos no detecta nodos
 openMosix, sino que detecta otros demonios de autodetecci\'on de
 nodos. Esto significa en la pr\'actica que el demonio de
 autodetecci\'on de nodos no es capaz de detectar nodos openMosix
 configurados mediante el m\'etodo manual. Tampoco debemos mezclar los
 dos tipos de configuraci\'on en el cluster, ya que esto nos dar\'a
 bastantes dolores de cabeza en la configuraci\'on de la topolog\'\i a.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Configuraci\'on autom\'atica de topolog\'\i a}}
 La forma autom\'atica de configurar la topolog\'\i a de un cluster
 openMosix es mediante un demonio recientemente Incorporado en las
 herramientas de \'area de usuario, que permite la detecci\'on
 autom\'atica de nodos del cluster. 

 El nombre del demonio es {\em omdiscd}. Para ejecutarlo, si hemos
 instalado correctamente las herramientas de \'area de usuario, basta
 con hacer:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt omdiscd}}
\vspace{.1in}

 y este programa crear\'a autom\'aticamente una lista con las
 m\'aquinas existentes en la red que tienen un demonio de
 autodetecci\'on de nodos v\'alido y funcionando correctamente, e
 informar\'a al kernel openMosix de estas m\'aquinas para que las
 tenga en cuenta.

 Podemos consultar la lista generada por el demonio de autodetecci\'on de nodos con el comando:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt showmap}}
\vspace{.1in}

 este comando muestra una lista de los nodos que han sido dados de
 alta en la lista de nodos local al  nodo que ejecuta el demonio
 {\em omdiscd}. Cuidado, ya que el hecho de que un nodo sea reconocido por
 un segundo no implica el caso rec\'\i proco: alguno de los nodos de
 la lista pueden no habernos reconocido a\'un como nodo v\'alido del
 cluster.

\vspace{.2in}
  Podemos informar a openMosix sobre por cual de los interfaces de red
  queremos mandar el paquete de broadcast. Esto es especialmente
  interesante en el caso particular de que el nodo donde lanzaremos el
  demonio de autodetecci\'on de nodos no tenga una ruta por defecto
  definida, caso en el que {\em omdiscd} parece fallar para algunos
  usuarios; aunque  hay otros escenarios donde tambi\'en es necesario
  controlar manualmente por que interfaz de red se manda el paquete de
  broadcast. Para forzar a {\em omdiscd} a mandar la informaci\'on por un
  interfaz en particular tenemos que usar la opci\'on {\tt -i}. Por
  ejemplo, llamamos al demonio de autodetecci\'on de nodos en este caso
  con el comando:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt omdiscd -i eth0,eth2}}
\vspace{.1in}

 lo que significa que mandaremos el paquete de broadcast por {\tt
 eth0} y por {\tt eth2}, y solamente por estos dos interfaces de red.

\vspace{.2in}
 Otro caso particular que es interesante conocer es el de algunas
 tarjetas PCMCIA que por un error en el driver del kernel no sean
 capaces de recibir correctamente los paquetes de broadcast -existen
 algunas as\'\i\  en el mercado-. La \'unica soluci\'on que podemos
 tener en la actualidad es poner el interfaz de dicha tarjeta con un
 mal driver en modo promiscuo, con lo que la tarjeta leer\'a y
 analizar\'a todos los paquetes, incluidos los de broadcast; y el
 as\'\i\  el kernel podr\'a acceder a dichos paquetes de broadcast. No
 es un problema del c\'odigo de openMosix, sino de los drivers de
 algunas tarjetas; pero el demonio de autodetecci\'on de nodos lo sufre
 directamente.  Ponemos la tarjeta con un driver que tenga problemas
 con los paquetes de broadcast en modo promiscuo con:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt ifconfig eth0 promisc}}
\vspace{.1in}

suponiendo que {\tt eth0} es nuestro interfaz de red. En otro caso,
sustituiremos {\tt eth0} por nuestro interfaz de red. En caso de que el
ordenador tenga varios interfaces de red, usamos esta instrucci\'on
con todos aquellos interfaces por los que esperamos recibir paquetes
de openMosix -puede ser m\'as de un interfaz- y que tengan este
problema. S\'olo root puede poner en modo promiscuo un interfaz.


 Para verificar con comodidad la autodetecci\'on viendo que hace el
 demonio de autodetecci\'on de nodos, podemos lanzarla en primer plano
 con la opci\'on {\tt -n}, con la sintaxis:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt omdiscd -n}}
\vspace{.1in}

 as\'\i\  se lanzar\'a en primer plano, y veremos en todo momento lo
 que est\'a pasando con el demonio.

\vspace{.2in}
 Otro modificador que es interesante conocer en algunos escenarios es
 {\tt -m}. Lleva como par\'ametro un \'unico n\'umero entero, que ser\'a
 el TTL de los paquetes de broadcast que enviemos a otros demonios de
 autodetecci\'on de nodos.
 
 Se aconseja pues que usemos la herramienta de detecci\'on
 autom\'atica de nodos s\'olo para clusters de prueba. A pesar de el
 gran inter\'es que han mostrado Moshe Bar y Martin Hoy en ella, al
 hacerle pruebas algunas veces no ha detectado todos los nodos. Es una
 herramienta a\'un experimental,  y esto es algo que no debemos
 olvidar.

 Finalmente debemos destacar que este demonio debe ser lanzado en todos
 los nodos del cluster, o en ninguno de ellos. Mezclar los dos
 mecanismos de configuraci\'on de la topolog\'\i a de un cluster en el
 mismo cluster no es una buena idea.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Configuraci\'on manual de topolog\'\i a}}
 El sistema de autodetecci\'on tiene muchos problemas que lo hacen
 inconveniente para determinadas aplicaciones. No funciona si hay algo
 entre dos nodos que bloquee los paquetes de broadcast, puede
 sobrecargar la red si tenemos muchos nodos en el cluster, supone un
 demonio m\'as que debe correr en todos los nodos del cluster, lo que
 complica la administraci\'on; y, quiz\'as lo m\'as importante, a\'un
 es software beta y no siempre detecta todos los nodos. Por todo ello,
 muchas veces un fichero compartido de configuraci\'on, com\'un a
 todos los nodos, es la soluci\'on m\'as simple a nuestro problema.

\vspace{.2in}
 En openMosix llamamos a nuestro fichero  {\em /etc/openmosix.map}. El
 script de arranque de openMosix -que estudiaremos m\'as adelante- lee
 este archivo, y lo utiliza para informar al kernel de openMosix sobre
 cuales son los nodos del cluster.

\vspace{.2in}
 El fichero {\em /etc/openmosix.map} contiene una lista con los rangos de
 direcciones IP que pertenecen al cluster. Adem\'as de indicar que
 rangos de direcciones IP pertenecen al cluster, nos permite asignar
 un n\'umero de nodo \'unico a cada IP de la red. Este n\'umero ser\'a
 empleado internamente por el kernel de openMosix y por las
 herramientas de usuario; tambi\'en lo emplearemos como identificador
 en comandos como {\tt migrate} para referenciar de forma un\'\i vocamente
 cada nodo. Tanto el sistema de ficheros {\em /proc/hpc} como las
 herramientas de \'area de usuario usan estos n\'umeros
 identificativos de nodo, en lugar de la IP, ya que un nodo del
 cluster openMosix puede tener m\'as de una IP, y solo uno de estos
 n\'umeros.

 Cada linea del fichero {\em /etc/openmosix.map} corresponde a un rango de
 direcciones correlativas que pertenecen al cluster. La sintaxis de
 una linea es:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt numeronodo IP tama\~{n}orango}}
\vspace{.1in}

 donde {\tt numeronodo} es el primer n\'umero de la primera IP del
 rango, {\tt IP} es la primera IP del rango, y {\tt tama\~{n}orango}
 es el tama\~{n}o del rango.

\vspace{.2in}
 Por ejemplo, en el archivo {\em /etc/openmosix.map} con el contenido:

\begin{verbatim}
1 10.1.1.100 16
17 10.1.1.200 8
\end{verbatim}

  estamos diciendo que nuestro cluster openMosix tiene 24 nodos. En la
  primera linea decimos que los 16 nodos primeros, que comenzamos a
  numerar por el n\'umero 1, comienzan desde la IP 10.1.1.100; y
  contin\'uan con 10.1.1.101, 10.1.1.102... as\'\i\ hasta 10.1.1.115.

\vspace{.2in}
 En la segunda linea decimos que, comenzando por el nodo n\'umero 17,
 tenemos 8 nodos m\'as; comenzando por la IP 10.1.1.200,
 10.1.1.201...hasta la IP 10.1.1.207.

 Podemos tambi\'en Incluir comentarios en este fichero. A partir del
 car\'acter \#, todo lo que siga en la misma linea del car\'acter \#
 es un comentario. Por ejemplo, podemos escribir:

\begin{verbatim}
# redes 10.1.1
 1 10.1.1.100 16 # Los 16 nodos del laboratorio
17 10.1.1.200 8 # El core cluster
\end{verbatim}

 Este archivo es exactamente igual para openMosix que el archivo anterior.

\vspace{.2in}
 La sintaxis de la declaraci\'on de la topolog\'\i a del cluster en el
 archivo {\em /etc/openmosix.map} necesita una explicaci\'on adicional
 cuando tenemos alguna m\'aquina con m\'as de una direcci\'on IP. En
 este archivo deben aparecer todas las IPs que puedan enviar y recibir
 paquetes openMosix, y s\'olo ellas. Esto significa que no pondremos
 en este archivo las IPs que no se usen para enviar y recibir los
 mensajes; pero tambi\'en supone un problema cuando una misma
 m\'aquina puede enviar y recibir mensajes de openMosix por varias IPs
 distintas. No podemos poner varias entradas como las que hemos visto,
 ya que el identificador de nodo es \'unico para cada nodo,
 independientemente del n\'umero de IPs que tenga un nodo. 

\vspace{.2in}
 Por todo esto, para solucionar el problema de que un nodo tenga
 varias direcciones IPs v\'alidas en uso en el cluster openMosix,
 tenemos la palabra clave ALIAS, que usamos para indicar que la
 definici\'on de la direcci\'on IP asignada a un n\'umero
 identificador de nodo est\'a replicada porque dicho identificador
 tiene m\'as de una IP v\'alida.

 Lo vamos a ver m\'as claro con un ejemplo. Supongamos, por ejemplo,
 que un nodo particular en el cluster descrito en el ejemplo anterior
 -el nodo 8- comparte simult\'aneamente una direcci\'on de las
 10.1.1.x y otra de las 10.1.2.x. Este segmento 10.1.2.x tiene a su
 vez m\'as nodos openMosix con los que tenemos que
 comunicarnos. Tendr\'\i amos el fichero:

\begin{verbatim}
# redes 10.1.1
 1 10.1.1.100 16 # Los 16 nodos del laboratorio
17 10.1.1.200 8 # El core cluster
\end{verbatim}

\begin{verbatim}
# redes 10.1.2
18 10.1.2.100 7
8 10.1.2.107 ALIAS # Nodo de interconexion con la red 10.1.1
25 10.1.2.108 100
\end{verbatim}
 
 es decir, estamos definiendo la IP del nodo 8 dos veces. La primera vez en la l\'\i nea:

\begin{verbatim}
 1 10.1.1.100 16 # Los 16 nodos del laboratorio
\end{verbatim}

 y la segunda vez en la linea:

\begin{verbatim}
8 10.1.2.107 ALIAS # Nodo de interconexion con la red 10.1.1
\end{verbatim}

en la primera l\'\i nea el nodo 8 est\'a definido dentro del rango
entre el nodo 1 y el nodo 16. En la Segunda l\'\i nea vemos como
decimos con ALIAS que  el nodo 8, adem\'as de la IP ya definida,
tiene una IP adicional: la IP 10.1.2.107.

 Hay que destacar un concepto clave al usar ALIAS:  tenemos que
 separar forzosamente la IP de la entrada ALIAS del rango donde esta
 ha sido definida. Por ejemplo, en el escenario anteriormente
 comentado es err\'oneo hacer:

\begin{verbatim}
# redes 10.1.1
 1 10.1.1.100 16 # Los 16 nodos del laboratorio
17 10.1.1.200 8 # El core cluster
# redes 10.1.2
18 10.1.2.100 108
8 10.1.2.107 ALIAS # Nodo de interconexion con la red 10.1.1
\end{verbatim}

 Esto no funciona, ya que definimos un identificador para la IP
 10.1.2.107 dos veces. Por ello, tenemos que resolver este escenario
 como en el ejemplo completo anteriormente comentado.

\vspace{.2in}
 Por \'ultimo, debemos recordar que todos los nodos del cluster
 openMosix deben tener el mismo archivo {\em /etc/openmosix.map}, y de que
 la direcci\'on local 127.0.0.1, por lo tanto, jam\'as debe aparecer
 en el archivo {\em /etc/openmosix.map}, ya que los ficheros deben ser
 iguales; y, en caso de incluir la direcci\'on IP local 127.0.0.1,
 cada archivo asignar\'\i a al mismo n\'umero distinto una m\'aquina
 distinta.
%---------------------------------------------------------------------------
\subsubsection*{\underline{El script de inicializaci\'on}}
 Podemos activar el archivo anteriormente citado con el comando
 {\tt setpe} -m\'as tarde veremos c\'omo hacerlo-; pero en
 openMosix tenemos un mejor procedimiento para configurar la
 topolog\'\i a del cluster: su script de inicializaci\'on.

\vspace{.2in}
 En el directorio de instalaci\'on de las herramientas de \'area de
 usuario tenemos un subdirectorio llamado {\em scripts}. En este
 directorio tenemos un script que se llama {\em openmosix}, que es el
 script encargado de configurar nuestro nodo cuando este entre en el
 runlevel que determinemos, suponiendo scripts de configuraci\'on {\em
 à la System V} -que son los que usan casi todas las distribuciones
 modernas de Linux-. Para activarlo, entramos en el directorio
 {\em scripts} y hacemos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cp openmosix /etc/rc.d/init.d}}
\vspace{.1in}

 ahora tenemos que decidir en qu\'e runlevels queremos lanzar
 openMosix. Si queremos lanzar openMosix en el runlevel 3, hacemos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt ln -s /etc/rc.d/init.d/openmosix
 /etc/rc.d/rc3.d/S99openmosix}}
\vspace{.1in}

 y si queremos lanzarlo en el runlevel 5 hacemos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt ln -s /etc/rc.d/init.d/openmosix
/etc/rc.d/rc5.d/S99openmosix}}
\vspace{.1in}

 Si queremos lanzar openMosix al arrancar una m\'aquina, debemos
 determinar cual es el runlevel de arranque del nodo. Para saber cual
 es el runlevel de arranque de nuestra m\'aquina, hacemos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cat /etc/inittab  | grep :initdefault:}}
\vspace{.1in}

o

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cat /etc/inittab  | grep id:}}
\vspace{.1in}

 saldr\'a algo como:

\begin{verbatim}
id:5:initdefault:
\end{verbatim}

 en este caso, el runlevel de arranque ser\'a el 5, y ser\'a el
 runlevel donde tendremos que activar el script de openMosix como
 hemos visto anteriormente. Por otro lado, si sale:

\begin{verbatim}
id:3:initdefault:
\end{verbatim}

 el runlevel de arranque ser\'a el 3, y usaremos el comando
 anteriormente estudiado para lanzar el script de inicializaci\'on en
 el runlevel 3.

\vspace{.2in}
 La pr\'oxima vez que la m\'aquina arranque, openMosix estar\'a
 correctamente configurado. De cualquier forma, podemos en cualquier
 momento reiniciar la configuraci\'on de openMosix sin reiniciar la
 m\'aquina haciendo:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt /etc/rc.d/init.d/openmosix restart}}
\vspace{.1in}
%---------------------------------------------------------------------------
\subsubsection*{\underline{Migrando tareas}}
 En principio, los procesos migrar\'an solos seg\'un el algoritmo de
 equilibrado autom\'atico de carga. Sin embargo, podemos tener
 inter\'es en recomendar una migraci\'on, o en forzar que un proceso
 vuelva a su nodo ra\'\i z. Vamos a repasar las utilidades de \'area
 de usuario; y comenzaremos con la utilidad que permite controlar las
 migraciones: la utilidad  {\tt migrate}.

 Esta utilidad nos permite solicitar la migraci\'on de un proceso
 determinado a un nodo determinado. Su sintaxis es:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt migrate PID numnodo}}
\vspace{.1in}

 donde {\tt PID} es el PID del proceso, y {\tt numnodo} el n\'umero del nodo
 al que queremos que el proceso migre. Si queremos forzar que el
 proceso migre a su nodo ra\'\i z, hacemos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt migrate PID home}}
\vspace{.1in}

 por otro lado, si queremos que el proceso migre a un nodo
 indeterminado que el kernel de openMosix debe decidir seg\'un el
 algoritmo de equilibrado autom\'atico de carga, hacemos:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt migrate PID balance}}
\vspace{.1in}

  s\'olo puede solicitar la migraci\'on de una tarea root,  el usuario
  propietario de la tarea y el usuario efectivo de la tarea. La
  migraci\'on es solo solicitada; y la tarea puede no migrar si hay
  alguna raz\'on de fuerza mayor que impida la
  migraci\'on. Particularmente, la \'unica migraci\'on de cualquier
  proceso que tendremos completa seguridad de que se realizar\'a es la
  migraci\'on al nodo ra\'\i z con el par\'ametro {\em home}. Las otras
  pueden no ocurrir.
%===========================================================================
\subsection{Las herramientas de \'area de usuario}
%---------------------------------------------------------------------------
\subsubsection*{\underline{Monitorizando el cluster}}
 La  herramienta usada para monitorizar un cluster openMosix es
 {\tt mosmon}. Esta herramienta nos permite ver un gr\'afico de barras con
 la carga asociada a cada nodo del cluster. Esta informaci\'on
 podr\'\i amos obtenerla haciendo un {\tt top} en cada uno de los nodos,
 pero para clusters de m\'as de ocho nodos la soluci\'on del {\tt top} es
 inviable, y la soluci\'on de {\tt mosmon} es especialmente buena. 

\vspace{.2in}
 {\tt 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\'en o no activos, podemos ver el
 n\'umero de nodos activos y adem\'as, en caso de que el n\'umero 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 {\tt mosmon} una
 herramienta realmente imprescindible para el administrador del
 cluster.

\vspace{.2in}
 De entre las opciones disponibles que podemos usar al llamar a
 {\tt mosmon}, las m\'as importantes son:

\vspace{.1in}
{\bf -d:} incluye en el gr\'afico todos los nodos, incluso aquellos
que est\'an desactivados. Esta opci\'on es muy \'util, ya que as\'\i\
el administrador ve cuando entran en el cluster estos nodos
desactivados.

\vspace{.1in}
{\bf -t:} lista un el n\'umero de nodos activos del cluster. Esta
opci\'on es especialmente \'util 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\'\i as
falla el hardware de alg\'un nodo-.

\vspace{.2in}
 Una vez que estamos dentro del programa {\tt mosmon}, con la pulsaci\'on
 de algunas teclas podemos conseguir funciones extra. De entre las
 teclas activas de {\tt mosmon}, destacamos:

\vspace{.1in}
{\bf d:} lista tambi\'en aquellos nodos que no est\'an activos. Hace
lo mismo que arrancar {\tt mosmon} con la opci\'on {\tt -d}. 

\vspace{.1in}
{\bf D:} lista s\'olo aquellos nodos que est\'an activos. Por ello,
hace lo mismo que arrancar {\tt mosmon} sin la opci\'on {\tt -d}.

\vspace{.1in}
{\bf h:} muestra la ayuda de {\tt mosmon}.

\vspace{.1in}
{\bf l:} permite visualizar la carga de cada nodo. Este es el modo de
visualizaci\'on con el que arranca {\tt mosmon}, por lo que esta opci\'on
se usa para volver a la visualizaci\'on de carga despu\'es de haber
cambiado la vista con {\tt m}, {\tt r}, {\tt s}, {\tt t} o {\tt u}.

\vspace{.1in}
{\bf m:} permite visualizar la memoria l\'ogica 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\'aquina, en lugar de la
carga. La barra corresponde con la memoria l\'ogica ocupada, mientras
que los {\tt +}, sumados a la barra, corresponden a la memoria total. Los
{\tt +} 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\'\i sica usada sea menor que la memoria
l\'ogica usada; por otro lado, el kernel y los dispositivos hacen que
no toda la memoria no usada por los procesos est\'e realmente
libre. Todas las cantidades se muestran en megabytes. 

\vspace{.1in}
{\bf q:} sale del programa {\tt mosmon}.

\vspace{.1in}
{\bf r:} permite visualizar la memoria f\'\i sica usada, la memoria
libre  y la memoria total por cada m\'aquina, en lugar de la carga. La
barra corresponde con la memoria f\'\i sica usada en un nodo, mientras
que los {\tt +} corresponden a la memoria libre. Por ello los {\tt +}, sumados
a la barra, corresponden a la memoria total. Todas las cantidades se
muestran en megabytes.

\vspace{.1in}
{\bf s:} permite ver las velocidades de los procesadores y el n\'umero de
procesadores por cada m\'aquina en lugar de la carga.

\vspace{.1in}
{\bf t:} lista un el n\'umero de nodos activos del cluster, si no
est\'a visible, o desactiva la visi\'on si se est\'an viendo el
n\'umero de nodos activos del cluster. Est\'a relacionado con la
opci\'on de arranque {\tt -t}.

\vspace{.1in}
{\bf u:} permite ver el grado de utilizaci\'on del procesador de cada
nodo. En el caso de que el cuello de botella de un nodo est\'e en su
procesador, este valor estar\'a 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\'on neta del
procesador. Un valor por debajo del 100\%, por lo tanto, significa que
un procesador est\'a infrautilizado, por lo que podr\'\i a aceptar
migraciones de entrada -aunque puede tener migraciones de salida del
nodo de procesos que usen mucha memoria o mucho disco-.

\vspace{.2in}
 Adem\'as de todo esto, la tecla {\em Enter} nos permite redibujar la
 pantalla, {\tt p} hace lo mismo que el cursor izquierdo -mover la vista
 de nodos a la izquierda-, y {\tt n} nos permite hacer lo mismo que el
 cursor derecho -mover la vista de nodos a la derecha-.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Configurando los nodos en openMosix}}
 La herramienta para configurar los nodos de un cluster openMosix es
 {\tt setpe}. Esta herramienta es llamada por los scripts de
 inicializaci\'on y parada de openMosix, as\'\i\ como por numerosos
 scripts de openMosix y herramientas auxiliares.  A pesar de que
 habitualmente no la llamaremos directamente, es interesante su
 estudio.

 {\tt setpe} se encarga de determinar la configuraci\'on de nodos del
 cluster. Su par\'ametro principal es el archivo donde estar\'a
 especificado el mapa de nodos. {\tt setpe} habitualmente es llamado de
 tres formas; la primera es con el modificador {\tt -f nombrefichero},
 que tomar\'a como archivo de configuraci\'on {\tt nombrefichero}. La
 segunda forma es pasando como  par\'ametro {\tt -}, en cuyo caso leer\'a
 el archivo de configuraci\'on de la entrada est\'andar. Esto es
 \'util para hacer pruebas de configuraci\'on, o para hacer pipes de
 {\tt setpe} con otras aplicaciones. Por \'ultimo, puede ser llamado con
 un \'unico par\'ametro, {\tt -off}, para sacar el nodo del cluster.

\vspace{.2in}
 De entre los par\'ametros de {\tt setpe} destacamos:

\vspace{.1in}
{\bf -w:}  carga la configuraci\'on del fichero indicado con los
par\'ametros 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\'olo actualiza la configuraci\'on si
el nodo no ejecuta ning\'un proceso de otro nodo, ni ning\'un proceso
de el nodo local se ejecuta en un nodo remoto. En cualquiera de estos
dos casos, {\tt -w} dar\'a un error y no actualizar\'a la
configuraci\'on.

\vspace{.1in}
{\bf -W:} carga la configuraci\'on del fichero indicado con los
par\'ametros especificados en dicho fichero sobre el kernel, cueste lo
que cueste. Esto puede significar expulsar procesos y mandarlos a sus
nodos de vuelta, as\'\i  como traerse al nodo local todos los procesos
remotos lanzados localmente. Internamente, con un {\tt -W}, realmente
{\tt setpe} hace primero un {\tt -off} -vemos m\'as adelante c\'omo funciona
-off-, y despu\'es hace un {\tt -w}.

\vspace{.1in}
{\bf -c:} realiza toda la operativa que realizar\'\i a {\tt -w}, solo que
no graba el resultado en el kernel. Esta opci\'on es \'util para
verificar una configuraci\'on sin instalarla en la m\'aquina.

\vspace{.2in}
 Cualquiera de estas tres opciones puede ser acompa\~{n}ada por la
 opci\'on {\tt -g numero}. Si la utilizamos, {\tt septe} informar\'a al
 kernel que el n\'umero m\'aximo de gateways que se interponen entre
 el nodo local y el m\'as remoto de los nodos es, a lo sumo,
 {\tt n\'umero}. Si no indicamos esta opci\'on, simplemente no modificamos
 el par\'ametro del kernel de n\'umero m\'aximo de gateways, quedando
 como estaba. El n\'umero m\'aximo de gateways intermedio que podemos
 especificar es {\tt 2}.

\vspace{.2in}
 Adem\'as de estas opciones, tenemos otras opciones interesantes de
 {\tt setpe}. Estas son:

\vspace{.1in}
{\bf -r:} lee la configuraci\'on del nodo actual, y la vuelca en la
salida est\'andar, o en un archivo determinado con la opci\'on {\tt -f
nombrearchivo}. Esta opci\'on es muy \'util para ver errores en la
configuraci\'on en clusters muy grandes, en los que no hemos hecho un
seguimiento de  la configuraci\'on de todos y cada uno de sus nodos y
hemos empleado cualquier mecanismo automatizado de configuraci\'on.

\vspace{.1in}
{\bf -off:} esta opci\'on 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 \'ultimo,
inhabilita openMosix en el nodo local.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Controlando los nodos con {\tt mosctl}}}
 Del mismo modo que {\tt setpe} nos permite ver la configuraci\'on de un
 nodo openMosix  y configurarlo, {\tt mosctl} nos permite editar el
 comportamiento de un nodo ya configurado, y verlo.

\vspace{.2in}
 De entre las opciones del comando {\tt mosctl}, destacamos:

\vspace{.1in}
{\bf block:} en el nodo local, bloquea la entrada de los procesos
generados en otro nodo.  

\vspace{.1in}
{\bf noblock}: deshace los efectos de {\tt block}.

\vspace{.1in}
{\bf mfs:} activa el soporte a MFS en openMosix.

\vspace{.1in}
{\bf nomfs:} inhabilita el soporte a MFS en openMosix.

\vspace{.1in}
{\bf lstay:} bloquea la migraci\'on autom\'atica hacia fuera de los
procesos generados localmente.

\vspace{.1in}
{\bf nolstay:} deshace los efectos de {\tt lstay}.

\vspace{.1in}
{\bf stay:} bloquea la migraci\'on autom\'atica hacia fuera de
cualquier proceso.

\vspace{.1in}
{\bf nostay:} deshace los efectos de {\tt stay}.

\vspace{.1in}
{\bf quiet:} el nodo local no informar\'a a los otros nodos de su
status.

\vspace{.1in}
{\bf noquiet:} deshace los efectos de {\tt quiet}.

\vspace{.2in}
  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:

\vspace{.1in}
{\bf bring:} trae de vuelta a todos los procesos que se han generado
localmente pero que se ejecutan en un nodo remoto. Adem\'as,
internamente realiza primero la misma operaci\'on que {\tt lstay}, y deja
el estado en {\tt lstay}. No retorna hasta que no han vuelto todos los
procesos remotos generados localmente.

\vspace{.1in}
{\bf 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\'as, internamente realiza primero la misma operaci\'on
que {\tt block}, y deja el estado en {\tt block}. No retorna hasta que no han
salido todos los procesos remotos del nodo local. 

\vspace{.2in}
 Por ejemplo, para apagar ordenadamente un nodo en un cluster
 openMosix sin perder ning\'un proceso, debemos hacer:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mosctl expel}}
\vspace{.1in}

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mosctl bring}}
\vspace{.1in}

 Despu\'es de estos comandos, el nodo no aceptar\'a ni que migren al
 nodo local procesos generados en un nodo externo, ni que ning\'un
 nodo local migre a otro nodo. Adem\'as, no se ejecutar\'a ning\'un
 proceso remoto en el nodo local ni ning\'un proceso local en el nodo
 remoto. Es decir, nuestra m\'aquina est\'a desligada del cluster
 openMosix, por lo que si se apaga la m\'aquina de un tir\'on de cable
 no afectar\'a al resto del cluster.

\vspace{.2in}
 Existen, adem\'as de estos, un conjunto de modificadores que tienen
 un par\'ametro adicional: el identificador de un nodo dentro del
 cluster. Estos modificadores permiten obtener informaci\'on sobre
 cualquier nodo del cluster. Estos modificadores son:

\vspace{.1in}
{\bf getload nodo:} siendo {\tt nodo} un nodo v\'alido en el cluster, este
modificador nos devuelve la carga que actualmente tiene dicho
nodo. Este par\'ametro de carga no corresponde al par\'ametro de carga
del kernel al que estamos acostumbrados, sino al par\'ametro de carga
que calcula openMosix y usa openMosix.

\vspace{.1in}
{\bf 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.

\vspace{.1in}
{\bf getmem nodo:} da la memoria l\'ogica libre y la memoria l\'ogica
total de un nodo particular del cluster.

\vspace{.1in}
{\bf getfree nodo:} da la memoria f\'\i sica libre y la memoria f\'\i
sica total de un nodo particular del cluster. Como estudiamos
anteriormente al hablar de {\tt mosmon}, la memoria f\'\i sica libre y la
memoria l\'ogica libre pueden no coincidir.

\vspace{.1in}
{\bf getutil nodo:} siendo {\tt nodo} un nodo v\'alido en el cluster,  nos
da el grado de uso de dicho nodo en el cluster. Discutimos el
par\'ametro de grado de uso de un nodo al hablar del comando {\tt mosmon}.

\vspace{.1in}
{\bf isup nodo:} nos indica si el nodo indicado est\'a activo o no.

\vspace{.1in}
{\bf getstatus nodo:} nos dar\'a el estado del nodo indicado. En este
estado incluye tambi\'en informaci\'on sobre si el nodo permite
migraciones de entrada, si permite migraciones de salida, si bloquea
todas las migraciones, si est\'a activo, y si est\'a propagando
informaci\'on sobre su carga.

\vspace{.2in}
 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:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mosctl whois direcci\'on}}
\vspace{.1in}

 y podemos tener como par\'ametro {\tt direcci\'on} el identificador de
 nodo, en cuyo caso este comando nos devolver\'a la IP, o la IP, en
 cuyo caso nos devolver\'a el identificador de nodo, o el nombre de la
 m\'aquina, en cuyo caso nos devolver\'a el identificador de
 nodo. Este comando tambi\'en nos indica si la m\'aquina indicada no
 pertenece al cluster openMosix.

 Si llamamos a {\tt mosctl whois} sin ning\'un par\'ametro adicional, este
 comando nos devolver\'a el identificador del nodo local. 
%---------------------------------------------------------------------------
\subsubsection*{\underline{Forzando migraciones}}
 Para forzar una migraci\'on en un cluster openMosix, debemos usar el
 comando {\tt migrate}.

 El comando {\tt migrate} toma dos par\'ametros: el primero es el PID del
 proceso que queremos hacer migrar, y el segundo par\'ametro es donde
 queremos que migre. Este segundo par\'ametro debe ser el
 identificador v\'alido de un nodo en el cluster.

 Existen, sin embargo, dos par\'ametros que podemos colocar en lugar
 del identificador v\'alido de un nodo del cluster. Estos dos
 modificadores modelan dos  casos especiales, y son:

\vspace{.1in}
{\bf home:} fuerza a migrar a un proceso al nodo donde fue generado.

\vspace{.1in}
{\bf balance:} fuerza a migrar a un proceso al nodo donde la
migraci\'on suponga minimizar el desperdicio de recursos dentro del
cluster openMosix. Es una forma de indicar que se eval\'ue el
algoritmo de migraci\'on autom\'atica de carga de openMosix, pero
dando preferencia a la migraci\'on del proceso del que hemos indicado
el PID.

\vspace{.2in}
 A la hora de lanzar esta migraci\'on, en caso de que el proceso sea
 un proceso lanzado en la m\'aquina donde ejecutamos el comando
 {\tt migrate}, debemos ser el administrador de la m\'aquina, el usuario
 propietario del proceso, el usuario efectivo del proceso, miembro del
 grupo propietario del proceso o miembro del grupo efectivo del
 proceso.

\vspace{.2in}
 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
 {\tt migrate}. En caso de que no migre, algunas veces recibiremos un
 mensaje de error avisando que el comando no funcion\'o, pero unas
 pocas veces no migrar\'a, y no recibiremos dicho
 mensaje. Particularmente esto se da cuando forzamos una migraci\'on
 posible pero p\'esima: el proceso ser\'a mandado de vuelta al nodo
 local incluso antes de que salga, porque el algoritmo de
 optimizaci\'on de carga considerar\'a inaceptable la migraci\'on.

\vspace{.2in}
 La \'unica migraci\'on que realmente podemos forzar siempre es la de
 vuelta a casa, siempre que el nodo de origen no acepte salidas de su
 nodos con {\tt mosctl lstay}  y no bloqueemos la entrada en el nodo de
 destino con {\tt mosctl block}.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Recomendando nodos de ejecuci\'on}}
 Cuando lanzamos un proceso, podemos indicar como se va a comportar
 frente a la migraci\'on, o donde preferimos que se ejecute. Para
 ello, contamos con el comando {\tt mosrun}. Este comando no se suele
 llamar directamente, sino a trav\'es de un conjunto de scripts que
 facilitan su uso. Con este comando podemos transmitir a openMosix la
 informaci\'on sobre qu\'e hace el proceso, informaci\'on que ser\'a
 fundamental para que openMosix minimice el desperdicio de recursos
 del cluster al m\'\i nimo. Tambi\'en podemos indicar un conjunto de
 nodos entre los cuales estar\'a el nodo donde migrar\'a el proceso
 despu\'es de lanzado, si esta migraci\'on es posible. En un sistema
 que no sea openMosix, {\tt mosrun}  lanza el proceso en la m\'aquina local
 de forma correcta.

 El comando {\tt mosrun} siempre tiene la misma estructura de llamada:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mosrun  donde migracion tipo comando argumentos}}
\vspace{.1in}

\vspace{.2in}
 Donde los par\'ametros son:

{\tt donde}: nodo al que el proceso va a migrar inmediatamente
despu\'es de ser lanzado, si esto es posible. 

{\tt migracion}: si se bloquea o no el proceso en el nodo de destino.

{\tt tipo}: tipo de proceso que se lanzar\'a.

{\tt comando}: nombre del proceso que se va a lanzar.

{\tt argumentos}: argumentos del proceso que se va a lanzar

\vspace{.2in}
 El modificador {\tt donde} puede ser:

Un nodo de destino, al que el proceso migrar\'a inmediatamente
despu\'es de ser lanzado, si esto es posible.

{\bf -h}, en cuyo caso ser\'a el nodo local.

{\bf -jlista}: en este caso, inmediatamente despu\'es de lanzar el
proceso, lo migrar\'a a un nodo escogido aleatoriamente dentro de la
lista de rangos {\tt 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\'on. Por ejemplo, si indicamos el par\'ametro
{\tt -j1,4-6,8,19-21}, inmediatamente despu\'es de lanzar el proceso, de
poder migrar el proceso, este migrar\'\i a a un nodo aleatorio entre
los nodos: 1,4,5,6,8,19,20 y 21.

\vspace{.2in}
El valor de la opci\'on de {\tt migracion} puede ser:

{\bf -l}: el algoritmo de equilibrado autom\'atico de carga puede forzar
una migraci\'on del proceso despu\'es de haber migrado dicho proceso
al nodo de destino.

{\bf -L}: una vez migrado al nodo de destino, el proceso se quedar\'a en
\'el y no podr\'a migrar de forma autom\'atica.

{\bf -k}: el proceso heredar\'a la propiedad de migrabilidad de su padre.

\vspace{.2in}
  El valor de {\tt tipo} es un dato muy importante que sirve de ayuda al
  algoritmo de migraci\'on autom\'atica de carga, y este puede ser:

{\bf -c}: en un nodo de memoria infinita, el proceso tiene como cuello de
botella la velocidad del procesador. 

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

\vspace{.2in}
Adem\'as de los modificadores anteriormente citados, con {\tt mosrun} 
tambi\'en podemos informar a openMosix sobre la forma en que openMosix
debe mantener las estad\'\i sticas de uso de los recursos del sistema
del proceso, datos fundamentales para  que el algoritmo de equilibrado
autom\'atico de carga tome decisiones correctas.  Estos modificadores
son:

\vspace{.1in}
{\bf -f:} mantiene las estad\'\i sticas de uso de los recursos del sistema
del proceso durante poco tiempo. Esto hace que las {\em predicciones} de
openMosix sobre el comportamiento de un proceso sean mejores ante
procesos que tienen durante su evoluci\'on comportamientos similares
durante largos periodos de tiempo.

\vspace{.1in}
{\bf -s:} mantiene las estad\'\i sticas de uso de los recursos del
sistema del proceso a largo plazo. Esto hace que las {\em
predicciones} de
openMosix sobre el comportamiento de un proceso sean mejores ante
procesos que cambian constantemente de comportamiento.

\vspace{.1in}
{\bf -n:} mantiene las estad\'\i sticas de uso de los recursos del
sistema del proceso desde el principio del programa hasta su
finalizaci\'on. Esto hace que las {\em predicciones}  de openMosix sobre el
comportamiento de un proceso sean mejores en procesos que est\'an
constantemente cambiando su comportamiento, y no podemos confiar en lo
que hac\'\i an hace poco.
     
 Hay tambi\'en un conjunto de shell scripts que ayudan a no
 enfrentarse contra las complejidades de {\tt mosrun} al lanzar una tarea
 en el uso diario del cluster, y que nos permiten realizar las tareas
 m\'as frecuentes de {\tt mosrun} de forma c\'omoda. Estas utilidades
 tienen siempre la misma sintaxis, que es:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt utilidad proceso argumentos}}
\vspace{.1in}

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

\vspace{.1in}
{\bf cpujob}: ejecuta un proceso, indicando a openMosix que si la memoria
del nodo fuera infinita su cuello de botella ser\'\i a el procesador.

\vspace{.1in}
{\bf iojob}: ejecuta un proceso, indicando a openMosix que si la memoria
del nodo fuera infinita su cuello de botella ser\'a el acceso a
disco.

\vspace{.1in}
{\bf nomig}: ejecuta un comando en el nodo local de forma que este no
podr\'a migrar de forma autom\'atica.

\vspace{.1in}
{\bf nunhome}: ejecuta un comando de forma que preferencialmente no migrar\'a.

\vspace{.1in}
{\bf omrunon}: ejecuta un proceso, e inmediatamente despu\'es lo migra, si
es posible, al nodo especificado. La sintaxis de llamada es la de
lanzar un proceso directamente desde l\'\i nea de comando. \'Util para
lanzar un proceso desde l\'\i nea de comandos recomendando un nodo de
ejecuci\'on.

\vspace{.1in}
{\bf omsh}: ejecuta un proceso, e inmediatamente despu\'es lo migra, si es
posible, al nodo especificado. La sintaxis de llamada es la de {\tt sh}
como cuando lanzamos el proceso con {\tt sh -c}, lo que lo hace
especialmente \'util para sustituir a sh en shell scripts.

\vspace{.1in}
{\bf fastdecay}: ejecuta un proceso, indicando a openMosix que mantenga
las estad\'\i sticas de uso de los recursos del sistema del proceso
durante poco tiempo. Esto hace que las {\tt predicciones} de openMosix
sobre el comportamiento de un proceso sean mejores ante procesos que
tienen durante su evoluci\'on comportamientos similares durante largos
periodos de tiempo.

\vspace{.1in}
{\bf slowdecay}: ejecuta un proceso, indicando a openMosix que mantenga
las estad\'\i sticas de uso de los recursos del sistema del proceso a
largo plazo. Esto hace que las {\tt predicciones} de openMosix sobre el
comportamiento de un proceso sean mejores ante procesos que cambian
constantemente de comportamiento.

\vspace{.1in}
{\bf nodecay}: ejecuta un proceso, indicando a openMosix que mantenga las
estad\'\i sticas de uso de los recursos del sistema del proceso desde
el principio del programa hasta su finalizaci\'on. Esto hace que las
{\em predicciones} de openMosix sobre el comportamiento de un proceso sean
mejores en procesos que est\'an constantemente cambiando su
comportamiento, y no podemos confiar en lo que hac\'\i an hace poco.

\vspace{.2in}
 Como suced\'\i a en el caso de {\tt mosrun}, si lanzamos un proceso con
 una de estas utilidades en una m\'aquina sin soporte openMosix
 habilitado, o con este mal configurado, el proceso se lanzar\'a
 perfectamente de forma local.
%---------------------------------------------------------------------------
\subsubsection*{\underline{openMosixView}}
 No podemos hablar de openMosix pasando por alto openMosixView, que es
 una c\'omoda y amigable aplicaci\'on de monitorizaci\'on de un
 cluster openMosix.

 openMosixView no est\'a en las herramientas de \'area de usuario de
 openMosix por defecto. Y la raz\'on es muy simple: las herramientas
 de \'area de usuario son lo m\'\i 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 {\em cajas}  sin  monitor, rat\'on o teclado con una
 instalaci\'on m\'\i nima de Linux, por lo que en principio
 openMosixView solo ser\'\i a un problema para el administrador, que
 puede no tener inter\'es en instalar las QT y KDE en una m\'aquina
 que s\'olo va a servir procesos. A diferencia de las herramientas de
 \'area de usuario, que tienen una necesidad de bibliotecas y
 compiladores preinstalados m\'\i nima, openMosixView necesita muchas
 bibliotecas instaladas para ejecutarse y m\'as a\'un para compilar,
 lo que hace poco pr\'actico compilar y usar openMosixView en un nodo
 minimal.

\vspace{.2in}
 Sin embargo, esto no quita que openMosixView  sea una excelente
 herramienta de gran utilidad, y que todo administrador de  openMosix
 podr\'\i a tenerla instalada en la m\'aquina 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\'afico del cluster.
%===========================================================================
\subsection{Optimizando el cluster}
%---------------------------------------------------------------------------
\subsubsection*{\underline{Ayudando al algoritmo de equilibrado de carga}}
 El primer paso que podemos dar para mejorar a\'un m\'as el
 rendimiento es ayudar al algoritmo de equilibrado de carga
 provey\'endole de m\'as informaci\'on sobre las caracter\'\i sticas
 de los nodos que forman el cluster. En el caso de los clusters
 heterog\'eneos esto es fundamental; ya que queremos que los procesos
 migren preferentemente a los nodos m\'as potentes, y que la
 migraci\'on libere a los nodos menos potentes.

 Tal y como queda el cluster cuando acabamos de instalar openMosix, el
 cluster ya optimiza el aprovechamiento de recursos en un cluster
 homog\'eneo -es decir,  en el que todas las m\'aquinas son iguales en
 potencia-. Sin embargo, el aprovechamiento de los recursos en un
 cluster heterog\'eneo a\'un no llega al \'optimo. Para solucionar
 esto, podemos modificar la potencia relativa que un nodo considera
 que tiene. En la fecha en la que se escribe este art\'\i culo no
 existe una herramienta de calibraci\'on automatizada, por lo que
 debemos hacer esto nodo a nodo con la herramienta manual de
 calibraci\'on, {\tt mosctl}, con el modificador {\tt setspeed}.

 {\tt mosctl} con el modificador {\tt setspeed} es una herramienta que,
 ejecutada sobre un nodo, permite alterar el par\'ametro de la
 potencia computacional que un nodo cree que tiene. Junto con la
 informaci\'on de la carga, el nodo transmite tambi\'en este
 par\'ametro al resto de los nodos del cluster, por lo que cada nodo
 debe lanzar {\tt mosctl setspeed} en alg\'un punto de la ejecuci\'on de
 los scripts de inicializaci\'on si el cluster tiene m\'aquinas
 distintas y queremos aprovechar el cluster al m\'aximo.

 Actualmente en openMosix empleamos como unidad una diezmil\'esima de
 la potencia de c\'alculo de un Pentium-III a 1.4GHz. Esto es una
 unidad arbitraria, ya que la potencia depende tambi\'en de la
 velocidad de memoria, de si el bus es de 33MHz o de 66MHz, y de la
 tecnolog\'\i a de la memoria. Adem\'as, para algunas tareas un
 procesador de Intel es m\'as r\'apido que uno de AMD, mientras que
 para otras el mismo procesador de AMD puede ser m\'as r\'apido que el
 mismo procesador de Intel.

 Actualmente lo mejor que podemos hacer es estimar {\em a ojo} cuanto
 puede ser el procesador de cada nodo m\'as lento o r\'apido que un
 Pentium-III a 1.4GHz para el tipo de tareas que lanzaremos en el
 cluster; y despu\'es asignamos dicha potencia relativa de prueba para
 cada nodo, usando para ello el comando:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mosctl setspeed valor}}
\vspace{.1in}

donde {\tt valor} es la potencia computacional del procesador as\'\i\  calculada.

\vspace{.2in}
 Una vez que ya tenemos el cluster en pruebas o en producci\'on,
 siempre podemos ajustar el valor para que el cluster tenga el
 comportamiento que queremos. En esta segunda etapa, por lo tanto,
 ajustamos los valores {\tt a ojo}  en valores emp\'\i ricos: si notamos
 que un nodo suele estar demasiado cargado, le bajamos el factor de
 potencia de c\'omputo. Por otro lado, si notamos que un nodo suele
 estar desocupado mientras que los otros nodos trabajan demasiado,
 siempre podemos subir su potencia computacional estimada con este
 comando. Esto se puede hacer tambi\'en con el cluster en
 producci\'on, sin ning\'un problema adicional, usando el comando
 anteriormente citado.

\vspace{.2in}
 Un truco habitual en openMosix es jugar con la potencia computacional
 estimada del nodo para mejorar la respuesta del cluster al
 usuario. Para ello, aumentamos un 10\% de forma artificial la
 potencia computacional estimada de los nodos sin monitor ni teclado,
 que s\'olo se dedican al c\'alculo, mientras que bajamos un 10\% la
 potencia computacional estimada de los nodos con monitor y teclado en
 los que el usuario lanza tareas. De hecho, en algunos nodos espec\'\i
 ficos que sabemos que van muy justos porque tienen ya problemas para
 responder a un usuario com\'un, bajamos un 20\% la potencia
 computacional estimada. Con esto estamos forzando a priori algunos
 sentidos de migraciones.

El desperdicio de recursos del cluster
 ser\'a ligeramente mayor, ya que estamos dando datos err\'oneos de
 forma intencionada al algoritmo de equilibrado autom\'atico de
 carga. A cambio, el usuario observar\'a una mejor respuesta al
 teclado y al rat\'on, ya que los nodos de acceso con m\'as frecuencia
 tendr\'an un porcentaje de procesador libre para responder a una
 petici\'on instant\'anea del usuario, sobre todo con carga media en
 el cluster. De cualquier forma, este truco s\'olo es \'util cuando
 tenemos un cluster mixto, con nodos dedicados y no dedicados.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Modificando las estad\'\i sticas de carga}}
 El subsistema de migraci\'on autom\'atica de procesos necesita
 informaci\'on sobre como evoluciona el comportamiento del
 cluster. Esta informaci\'on con el tiempo se tiene que descartar, ya
 que lo que pasaba en el cluster hace varias horas no deber\'\i a
 afectar al comportamiento actual del cluster.

\vspace{.2in}
 La informaci\'on no se almacena de forma {\tt eterna}. Se va acumulando
 de forma temporal, pero la importancia de los hist\'oricos de los
 sucesos  va decreciendo seg\'un se van haciendo estas estad\'\i
 sticas m\'as antiguas. El hecho de mantener la informaci\'on de los
 hist\'oricos durante un tiempo permite que los picos de
 comportamiento an\'omalo en el uso del cluster no nos enmascaren el
 comportamiento real del cluster. Pero, por otro lado, la
 informaci\'on debe desaparecer con el tiempo, para evitar que
 tengamos en cuenta sucesos que ocurrieron hace mucho tiempo, pero que
 ahora no tienen importancia.

Hemos aprendimos como ajustar la estad\'\i
 stica de los procesos, proceso por proceso. Sin embargo, ahora
 estamos hablando de un concepto distinto: ahora hablamos de la
 estad\'\i stica de uso de los recursos de un nodo, y no de la
 estad\'\i stica de un proceso en particular. Del mismo modo que en el
 art\'\i culo anterior aprendimos a ajustar el tiempo que se
 manten\'\i an las estad\'\i sticas de un proceso, ahora veremos como
 se ajusta el par\'ametro para un nodo en concreto.

 El comando que usamos para determinar el tiempo que se mantienen las
 estad\'\i sticas de un nodo es {\tt mosctl}, con el modificador
 {\tt setdecay}.

 El uso de los recursos de un nodo en un cluster openMosix es una
 medida compuesta del uso de los recursos por los procesos que tienen
 un ritmo de deca\'\i da de la estad\'\i sticas lento, y el uso de los
 recursos por  los procesos que tienen un ritmo de deca\'\i das
 r\'apido. La sintaxis de la instrucci\'on que determina el c\'alculo
 de la medida ser\'a:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mosctl setdecay intervalo procentajelento porcentajer\'apido}}
\vspace{.1in}

 Donde {\tt intervalo} ser\'a el intervalo en segundos entre rec\'alculos
 de las estad\'\i sticas, {\tt porcentajelento} el tanto por mil de uso
 que se almacena originado por procesos con deca\'\i da lenta de
 estad\'\i sticas, y {\tt porcentajer\'apido} el tanto por mil que se
 almacena de procesos con deca\'\i da r\'apida de estad\'\i sticas.

 Como lo hemos explicado aqu\'\i  queda un poco dif\'\i cil de
 entender, as\'\i  que lo veremos con un ejemplo:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mosctl setdecay 60 900 205}}
\vspace{.1in}

 Esto hace que las estad\'\i sticas hist\'oricas por nodo se
 recalculen cada 60 segundos. Se recalculan utilizando para acumular
 resultados como factor de ponderaci\'on un 90\% para la carga de los
 procesos de deca\'\i da lenta de antes de los \'ultimos 60 segundos,
 un 20,5\% para la carga de los procesos de deca\'\i da r\'apida de
 antes de los \'ultimos 60 segundos, y la carga del sistema de los
 \'ultimos 60 segundos sin ponderaci\'on.

 Esto nos permite hacer que las estad\'\i sticas por nodo -no por
 proceso- evolucionen a m\'as velocidad -lo que mejora el
 aprovechamiento cuando la carga del cluster m\'as frecuente son
 procesos largos y de naturaleza constante-, o que sean las estad\'\i
 sticas m\'as constantes en el tiempo -lo que mejora el
 aprovechamiento en clusters donde hay muchos procesos muy
 peque\~{n}os ejecut\'andose de forma aleatoria-.

 Podemos tambi\'en obtener la informaci\'on de los par\'ametros de
 permanencia de hist\'oricos en un cluster openMosix para un nodo
 particular con el comando {\tt mosctl} y el modificador {\tt getdecay}. La
 sintaxis del comando es:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mosctl getdecay}}
\vspace{.1in}
%---------------------------------------------------------------------------
\subsubsection*{\underline{Programando openMosix}}
 Para programar openMosix a bajo nivel -es decir, tomando el control
 del cluster y de la migraci\'on- podemos emplear tres mecanismos:

Hacer uso de las herramientas de \'area de usuario. Este es el
mecanismo recomendado para scripts en Perl,  o  para usar en
shell-scripts.
Hacer uso del sistema de ficheros {\em /proc}. En Linux tenemos un sistema
de ficheros virtual en {\em /proc}. Este sistema de ficheros no existe
f\'\i sicamente en el disco, y no ocupa espacio; pero los archivos y
los directorios que en \'el nos encontramos nos 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\'en podemos obtener
informaci\'on sobre su comportamiento y darle \'ordenes a trav\'es de
{\em /proc}. Este m\'etodo de operaci\'on es ideal en cualquier lenguaje
que no tiene un m\'etodo c\'omodo para llamar a procesos externos,
pero nos permite acceder con facilidad a archivos, leyendo y
escribiendo su contenido. Este es el caso de la pr\'actica totalidad
de los lenguajes de programaci\'on compilados. Encontramos en los
cuadros adjuntos algunos de los ficheros m\'as importantes del {\em /proc}
de openMosix que podemos tener inter\'es en leer o escribir.
Hacer uso de la biblioteca de openMosix. El \'area de usuario de
openMosix incluye una biblioteca en C que puede ser utilizada para
hacer todo aquello que pueden hacer las herramientas de \'area de
usuario.  Este mecanismo s\'olo funciona en C, pero es el m\'as
c\'omodo para los programadores en este lenguaje. No hablaremos m\'as
de \'el, aunque tenemos documentaci\'on disponible en el proyecto
openMosix sobre como funciona. Las bibliotecas est\'an obsoletas, y
estoy trabajando en unas bibliotecas de \'area de usuario nuevas.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Planes futuros de openMosix}}
 En la fecha de la escritura de este art\'\i culo, el equipo de
 openMosix est\'a trabajando en varias caracter\'\i sticas nuevas de
 gran inter\'es para la comunidad.

 El equipo de \'area de kernel est\'a trabajando en el porting de
 openMosix a IA64. Este porting est\'a siendo subvencionado por HP, y
 supondr\'a el salto a los 64 bits de openMosix. Es un proyecto
 pensado para que openMosix sea un elemento clave en el campo de la
 industria.

 Werner Almesberger ha desarrollado un parche para hacer los sockets
 migrables. El parche a\'un no est\'a muy probado, aunque hablaremos
 de los sockets migrables bajo openMosix en el momento que este parche
 sea estable.

 Por otro lado, David Santo Orcero est\'a trabajando en una nueva biblioteca de \'area
 de usuario con soporte a sem\'antica de grid. Tiene compatibilidad
 inversa con la biblioteca actual, por lo que tendremos SSI
 transparente tambi\'en con la nueva biblioteca; pero para usar las
 nuevas caracter\'\i sticas de grid ser\'\i a necesario usar el nuevo
 API.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Ficheros en {\em /proc/hpc}}}

 Los ficheros y directorios y directorios m\'as importantes que
 encontramos en {\em /proc/hpc} son:


{\em /proc/hpc/admin}: contiene algunos ficheros importantes de
administraci\'on.

{\em /proc/hpc/config}: configuraci\'on del cluster openMosix.

{\em /proc/hpc/gateways}: n\'umero de saltos m\'aximo entre redes para un
paquete de openMosix.

{\em /proc/hpc/nodes}: directorio que contiene un subdirectorio por cada
nodo del cluster, y que permite administrar el cluster desde cada
nodo.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Ficheros en {\em /proc/hpc/admin}}}
 Los ficheros m\'as importantes que tenemos en el directorio {\em /proc/hpc/admin} son:

{\em /proc/hpc/admin/bring}: si escribimos en este fichero un {\tt 1} desde un
nodo, los procesos lanzados desde dicho nodo volver\'an al nodo ra\'\i
z.
{\em /proc/hpc/admin/block}: si escribimos en este fichero un {\tt 1} desde un
nodo, bloqueamos la llegada al nodo de cualquier proceso que se haya
generado en un nodo externo. 
%---------------------------------------------------------------------------
\subsubsection*{\underline{Ficheros de configuraci\'on e informaci\'on de cada proceso}}
 En Linux, cada proceso tiene un subdirectorio en {\em /proc}, cuyo nombre
 es el PID del proceso, que contiene importante informaci\'on del
 proceso. Si tenemos openMosix activado, encontraremos algunos
 ficheros adicionales para cada proceso en su directorio. De entre
 estos ficheros adicionales, destacamos:

{\em /proc/PID/cantmove}: si el fichero no puede migrar fuera del nodo,
 encontramos en este archivo la raz\'on por la que el proceso no puede
 emigrar en el momento en el que se consulta este archivo. Esta
 condici\'on puede cambiar si el proceso cambia su comportamiento, o
 entra/sale de modo virtual 8086.

 {\em /proc/PID/nmigs}: n\'umero de veces que un proceso ha migrado. Si
 este n\'umero es demasiado alto, probablemente tenemos mal calibrado
 el cluster, y tenemos que aumentar el coste de migraci\'on.

{\em /proc/PID/goto}: si escribimos un n\'umero en este fichero, openMosix
 intentar\'a que el proceso al que fichero {\tt goto} le corresponda migre
 al nodo cuyo n\'umero de nodo sea el que hemos grabado en el
 fichero. Puede no migrar a donde hemos pedido que migre: la
 migraci\'on en este caso nunca es obligatoria, y el sistema, aunque
 har\'a lo que pueda por migrarlo, puede no hacerlo.

{\em /proc/PID/where}: d\'onde un proceso se est\'a ejecutando en la
 actualidad. Observamos que mientras que {\em /proc/PID/goto} es de
 escritura, {\em /proc/PID/where} es de lectura.
%---------------------------------------------------------------------------
\subsubsection*{\underline{Ficheros de configuraci\'on e informaci\'on de cada nodo}}
Al igual que tenemos un directorio por proceso desde el que podemos
manipular cada proceso, tenemos un directorio por nodo desde el que
podemos manipular cada nodo. Los directorios est\'an en
{\tt /proc/hpc/nodes}, y tienen como nombre de directorio el n\'umero de
nodo openMosix.

 Los ficheros m\'as importantes que encontramos dentro del directorio
 de cada nodo son: 

{\em /proc/hpc/nodes/identificadornodo/CPUs}: El n\'umero de procesadores
que tiene el nodo cuyo identificador es {\tt identificadornodo}, si es un
nodo con m\'as de un procesador y adem\'as tiene el soporte SMP
activado en el kernel. Dos veces el n\'umero de procesadores que tiene
el nodo, si es un nodo con procesadores Pentium IV e hyperthreading
activado. {\tt 1} en otro caso no listado anteriormente.

{\em /proc/hpc/nodes/identificadornodo/load}: Carga asociada al nodo cuyo
identificador es {\tt identificadornodo}.

{\em /proc/hpc/nodes/identificadornodo/mem}: memoria disponible l\'ogica
para openMosix en el nodo cuyo identificador es {\tt identificadornodo}. 

{\em /proc/hpc/nodes/identificadornodo/rmem}: memoria disponible f\'\i
sica para openMosix en el nodo cuyo identificador es
{\tt identificadornodo}. 

{\em /proc/hpc/nodes/identificadornodo/tmem}: memoria total de la
m\'aquina, libre o no, en el nodo cuyo identificador es
{\tt identificadornodo}.

{\tt /proc/hpc/nodes/identificadornodo/speed}: potencia del nodo cuyo
identificador es {\tt identificadornodo}. Recordemos que es el valor que
hemos dicho al nodo que tiene. No es un valor calculado, se lo damos
nosotros como administradores del cluster. Es el valor de velocidad
del que hablamos en este art\'\i culo.

{\em /proc/hpc/nodes/identificadornodo/status}: estado del nodo cuyo
identificador es {\tt identificadornodo}. Estudiamos los estados de un
nodo con detalle en el art\'\i culo anterior.

{\em /proc/hpc/nodes/identiciadornodo/util}: coeficiente de utilizaci\'on
del nodo cuyo identificador es {\tt identificadornodo}. Estudiamos el
coeficiente de utilizaci\'on de un nodo en el art\'\i culo anterior.
