\newpage
%===========================================================================
%       x.12 > OPENMOSIX INTERNALS
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
%      \includegraphics[bb = -250 220 0 0, scale=1]{./TuXes/tux-.jpg}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
%      \includegraphics[-275,650][0,0]{./TuXes/tux-}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{{\em The openMosix internals} (Moshe Bar)}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em In the good old days physicists
    repeated each other's experiments, just to be sure.}}

\hspace{1in}\textcolor{blue_omosix}{{\em Today they stick to FORTRAN, so that
    they can share each other's programs, bugs included.}}

\hspace{4in}\textcolor{blue_omosix}{{\em Edsger W. Dijkstra}}
%\vspace{0.5in}

\end{latexonly}
%===========================================================================
\subsection*{Aspectos generales de openMosix}
Un cluster openMosix es del tipo
SSI. Se ha argumentado mucho sobre si estas arquitecturas pueden considerarse un cluster
como tal. Los primeros clusters SSI fueron el IBM
SySPlex y un cluster de DEC. En el cluster DEC se pod\'\i a acceder
con telnet a la direcci\'on del cluster y trabajar desde all\'\i\
hasta que decidi\'eramos terminar la conexi\'on. El usuario nunca
ten\'\i a consciencia sobre en cual de los nodos se encontraba y
cualquier programa que se lanzara se ejecutaba en el nodo que
mejor pudiera servir las necesidades del proceso.

Bien, openMosix es exactamente lo mismo. S\'olo que funciona sobre
nuestro sistema operativo favorito: Linux!

openMosix es una extensi\'on del kernel. Antes de instalar openMosix
tendremos que lanzar el {\em script} de instalaci\'on que har\'a
efectivos los cambios necesarios al kernel de linux -por lo tanto
deberemos disponer de las fuentes del kernel en nuestro disco-. Los
cambios se traducen entorno a un 3\% del c\'odigo total del n\'ucleo, lo que
realmente no es muy significativo.

Cuando habremos recompilado el nuevo kernel y tras arrancarlo,
dispondremos de un nuevo nodo openMosix. Haciendo r\'eplicas de este proceso en las m\'aquinas que
tengamos en nuestra red llegaremos a crear el cluster.

Hay un fichero de configuraci\'on en {\em /etc/openmosix.map} que debe ser
configurado para dejar ver en el nodo local -el poseedor del fichero- los
dem\'as nodos. Cada nodo env\'\i a su estado de carga actual a una lista
aleatoria de otros nodos, para hacerlo conocer.
La mejor caracter\'\i stica de openMosix es que podemos ejecutar un
programa y el mismo cluster decide d\'onde debe ejecutarse.

openMosix nos brinda una nueva dimensi\'on de la escalabilidad de un
cluster bajo linux. Permite la construcci\'on de arquitecturas de alto
rendimiento, donde la escalabilidad nunca se convierte en un cuello de
botella para el rendimiento general del cluster. Otra ventaja de los
sistemas openMosix es la respuesta en condiciones de alta
impredicibilidad producida por distintos usuarios y/o situaciones.

Entre las caracter\'\i sticas m\'as relevantes se encuentra su pol\'\i
tica de distribuci\'on adaptativa y la simetr\'\i a y flexibilidad de su
configuraci\'on. El efecto combinado de estas propiedades implica que
los usuarios no tengan que saber el estado actual de los distintos
nodos, ni tan siquiera su n\'umero. Las aplicaciones paralelas pueden
ser ejecutadas permitiendo el asignamiento del lugar de ejecuci\'on de
los procesos a openMosix. Como puede darse en sistemas SMP.

No obstante hay \'areas donde openMosix no genera grandes
beneficios. Para aplicaciones que usen memoria compartida (como
servidores de web o de bases de datos) los procesos no podr\'an migrar
y por tanto permanecer\'an en el nodo desde el cual se han invocado.

\subsection*{Detalles de openMosix}
openMosix es una herramienta para kernels Unix, como
Linux, consistente en unos algoritmos para adaptaci\'on de recursos
compartidos. Permite m\'ultiples nodos uniprocesadores -UPs- y/o SMPs que
funcionen bajo la misma versi\'on del kernel para cooperar
conjuntamente. Los algoritmos de openMosix se han dise\~{n}ado para
responder a variaciones a tiempo real en el uso de los recursos de
varios nodos. Esto es posible migrando procesos de un nodo a otro
transparentemente, teniendo en cuenta la carga de cada uno de ellos y
evitando errores debido al uso de memoria {\em swap}. El \'exito es
una mejora en el rendimiento total y la creaci\'on de un entorno
multiusuario y de tiempo compartido para la ejecuci\'on de
aplicaciones, tanto secuenciales como paralelas. El entorno de trabajo
est\'andar de openMosix es un cluster donde se encuentran disponibles
todos y cada uno de los recursos de cada nodo.

La implementaci\'on actual de openMosix se ha dise\~{n}ado para
configurar clusters con m\'aquinas basadas en x86 conectadas en redes
LAN est\'andar. Las posibles configuraciones abarcan desde
peque\~{n}os clusters con redes de 10Mbps hasta entornos con servidores
SMP y redes ATM, Gigabit LAN o Myrinet.
La tecnolog\'\i a openMosix consiste en dos partes:
\begin{enumerate}
  \item un {\bf mecanismo de migraci\'on de procesos} llamado Migraci\'on Preferente de Procesos (PPM),
  \item un conjunto de dos {\bf algoritmos para la compartici\'on adaptativa
  de recursos},
  \item y un sistema para el {\bf acceso a ficheros} de cualquier nodo del cluster.
\end{enumerate}

Ambas partes est\'an implementadas a nivel de kernel utilizando m\'odulos,
la interfaz del kernel permanece sin modificar. Todo
ello permanece transparente a nivel de aplicaci\'on. Se profundiza sobre cada
una de ellas en las pr\'oximas subsecciones.

La PPM puede migrar cualquier proceso, en cualquier instante de tiempo
y a cualquier nodo disponible. Usualmente las migraciones estan
basadas en informaci\'on provinente de uno de los algoritmos de
compartici\'on de recursos, pero los usuarios pueden invalidar
cualquier decisi\'on autom\'atica y hacer las migraciones manualmente.

Una migraci\'on debe ser iniciada por el proceso o por una
petici\'on expl\'\i cita de otro proceso del mismo usuario (o del
super-usuario root). Las migraciones manuales de procesos pueden ser
\'utiles para implementar una pol\'\i tica particular o para testear
diferentes algoritmos de planificaci\'on ({\em scheduling}). Cabe
destacar que el super-usuario tiene privilegios adicionales sobre la
PPM, como la definici\'on de pol\'\i ticas generales o qu\'e nodos
podr\'an ser incluidos en el cluster y cu\'ales no.

Cada proceso tiene un \'unico nodo de origen (UHN, {\em unique home node})
donde es creado. Normalmente \'este es el nodo en el cual el usuario ha
logado. El modelo SSI de openMosix es un modelo CC ({\em cache
  coherent}), en el cual cualquier proceso parece ejecutarse en su
nodo local y donde todos los procesos de una sesi\'on de  usuario
comparten el entorno de la ejecuci\'on del UHN. Los procesos que
migran a otro nodo usar\'an los recursos de \'este, siempre que sea
posible, pero interaccionar\'an con el usuario a trav\'es del UHN. Por
ejemplo, podemos suponer que un usuario invoca ciertos procesos,
algunos de los cuales pasan a migrarse a nodos remotos. Si el usuario ejecuta a
continuaci\'on el comando {\tt ps} podr\'a ver el estado de todos sus
procesos, incluy\'endose los procesos migrados. Si alguno de los
procesos migrados pide la hora actual a trav\'es de la primitiva
{\tt gettimeofday()} obtendr\'a la hora del UHN.

La pol\'\i tica que implementa PPM es la principal herramienta para los algoritmos de gesti\'on de
los recursos. Mientras recursos como el uso de procesador o de memoria
principal se encuentren bajo cierto umbral, los procesos ser\'an
confinados al UHN. Cuando los requerimientos de los recursos exceda de
ciertos niveles, algunos procesos se migrar\'an a otros nodos para
aprovechar las ventajas de los recursos remotos. La principal meta es
maximizar la eficiencia de recursos a trav\'es de la red. La unidad de 
granularidad del trabajo de distribuci\'on en openMosix es el
proceso\footnote{Algunos clusters experimentales disponen de una
  granularidad m\'as fina, permitiendo la migraci\'on de {\em threads}
  (hilos).}.
 Los usuarios pueden ejecutar aplicaciones paralelas
inicializando m\'ultiples procesos en un nodo, y luego permitiendo al
sistema la asignaci\'on de dichos procesos a los mejores nodos
disponibles. Si durante la ejecuci\'on de los procesos aparecen nuevos
recursos usables, los algoritmos de gesti\'on de recursos compartidos
se encargar\'an de tenerlos en cuenta. Esta capacidad para asignar y
reasignar procesos es particularmente importante para facilitar la
ejecuci\'on y proporcionar un entorno multiusuario y de tiempo
compartido  eficiente.

openMosix no dispone de un control centralizado -o jerarquizado en
maestros/esclavos-: cada nodo puede operar como un sistema aut\'onomo,
y establece independientemente sus propias decisiones. Este
dise\~{n}o permite la configuraci\'on din\'amica, donde los nodos
pueden a\~{n}adirse o dejar el cluster con interrupciones m\'\i nimas. Adicionalmente permite una gran escalabilidad y asegura que el sistema
permanezca funcionando correctamente en grandes o peque\~{n}as
  configuraciones. Dicha escalabilidad se consigue incorporando
  aleatoriedad en los algoritmos de control del sistema, donde cada
  nodo basa sus decisiones en un conocimiento parcial sobre el estado
  de cada uno de los dem\'as nodos. Por ejemplo, en el algoritmo
  probabil\'\i stico de difusi\'on de informaci\'on, cada nodo env\'\i a, a intervalos regulares, informaci\'on sobre sus recursos
  disponibles a un conjunto de nodos elegidos
  aleatoriamente\footnote{Si enviase la informaci\'on de su carga a
    todos los nodos, el nodo con menor carga pronto se ver\'\i a
    sobrecargado.}.
 Al mismo tiempo, mantiene una peque\~{n}a ventana
  con la informaci\'on llegada m\'as reciente. Este esquema soporta
  escalabilidad, difusi\'on de informaci\'on uniforme y
  configuraciones din\'animcas.
%---------------------------------------------------------------------------------------
\subsubsection*{Mecanismo de migraci\'on de procesos PPM}
La mejor aportaci\'on de openMosix es un nuevo algoritmo para
seleccionar en qu\'e nodo debe ejecutarse un proceso ya iniciado. {\bf El
modelo matem\'atico para este algoritmo de planificaci\'on ({\em scheduling}) se debe al campo de la investigaci\'on econ\'omica}.
Determinar la localizaci\'on \'optima para un trabajo es un problema
complicado. La complicaci\'on m\'as importante es que los recursos
disponibles en el cluster de computadoras Linux son heterog\'eneos. En
efecto, el coste para memoria, procesadores, comunicaci\'on entre
procesos son incomparables: no se miden con las
mismas unidades. Los recursos de comunicaci\'on se miden en t\'erminos
de ancho de banda, la memoria en t\'erminos de espacio libre y los
procesadores en t\'erminos de ciclos por segundo. 
%La estrategia natural de equilibrado de los recursos a lo ancho de todas las
%computadoras no est\'a bien definido. El nuevo algoritmo empleado por
%openMosix es muy interesante ya que intenta reconciliar estas
%diferencias entre unidades (y posiblemente puede ser aplicado a
%planificadores de sistemas no clusters) basadas en principios
%econ\'omicos y an\'alisis de competitividad.

%La idea clave de esta estrategia es convertir el uso total de ciertos
%recursos heterog\'eneos (memoria y procesador, por ejemplo) en
%t\'erminos homog\'eneos de coste. Luego los trabajos ser\'an asignados a la
%computadora donde supongan un menor coste. Justo como se hace en el
%mercado de la econom\'\i a.

%Esta estrategia econ\'omica unifica el marco de algoritmos para la
%asignaci\'on de la computaci\'on, comunicaci\'on, memoria y recursos
%de E/S (entrada/salida). Ello permite el desarrollo de algoritmos
%de a tiempo real cercanos a ser \'optimos, para la asignaci\'on de
%estos recursos.

%El modelo matem\'atico no es trivial, pero es ciertamente
%coherente. Es de hecho un importante invento y me parece que puede
%aplicarse a proyectos como al planificador de Linux SMP.

openMosix implementa la migraci\'on de procesos completamente
transparente al usuario, al nodo y al proceso. Tras su migraci\'on el proceso contin\'ua
interaccionando con el entorno de su localizaci\'on. Para implementar
PPM la migraci\'on de procesos se divide en dos \'areas: 
\begin{enumerate}
  \item {\bf remote:} es el \'area de usuario y puede ser migrada.
  \item {\bf deputy:} es el \'area de sistema, que es dependiente del UHN y que no puede migrar.
\end{enumerate}
A continuaci\'on se detalla sobre cada una de ellas.

\vspace{.2in}
{\bf\sc i.- Remote}

\vspace{.1in}
Contiene el c\'odigo del
programa, el {\bf stack}, los {\bf datos}, los {\bf mapas de memoria} y
los {\bf registros de los procesos}. {\em Remote} encapsula el proceso
cuando est\'a ejecut\'andose a nivel de usuario. 

\vspace{.2in}
{\bf\sc ii.- Deputy}

\vspace{.1in}
El \'area de  sistema, llamada tambi\'en {\em parte delegada}, contiene una descripci\'on de los
recursos a los que el proceso est\'a ligado y un {\em kernel-stack}
para la ejecuci\'on del {\bf c\'odigo de sistema del proceso}. {\em Deputy} encapsula el proceso cuando est\'a ejecut\'andose en el
kernel. Mantiene la dependencia de las partes del contexto del sistema
de los procesos, por lo tanto debe mantenerse en el UHN. Mientras el
proceso puede migrar -y varias veces- entre nodos diferentes, el
{\em deputy} nunca lo har\'a. La interf\'\i cie entre las dos \'areas
est\'a bien definida en la capa de enlace, con un canal de comunicaci\'on
especial para la interacci\'on de tipo {\em mosix\_link}.

\vspace{.2in}
El tiempo de migraci\'on tiene dos componentes:
\begin{itemize}
    \item un componente fijo, para establecer un
nuevo marco de proceso en el remoto,
    \item y un componente linear, proporcional al n\'umero de p\'aginas de
 memoria a transferir.
\end{itemize}
 Para
minimizar el tr\'afico de migraciones s\'olo se transfieren las tablas de p\'aginas y
las p\'aginas ocupadas por los procesos.

Las llamadas al sistema
son una forma s\'\i ncrona de interacci\'on entre las dos
\'areas. Todas las que son ejecutadas por el
proceso son interceptadas por la capa de enlace del remoto. Si la
llamada de sistema no depende del UHN se ejecuta -localmente- en
el nodo remoto. Si no, la llamada de sistema es redirigida al
{\em deputy} el cual ejecuta la llamada a sistema del proceso.

Otras formas de interacci\'on entre las dos \'areas son la entrega de
se\~{n}ales y los eventos para reactivar procesos, a medida que
lleguen datos por la red. Estos eventos requieren que el {\em deputy}
localice e interaccione as\'\i ncronamente con el remoto.

Este requisito de localizaci\'on {\em mosix\_link} es resuelto por el canal de
comunicaciones existente entre ellos. En un escenario t\'\i pico, el
kernel del UHN informa al {\em deputy} del evento. {\em Remote} monitoriza el canal de comunicaci\'on para percatarse de
eventos as\'\i ncronos, como pudieran ser se\~{n}ales, justo antes de
volver a la ejecuci\'on de nivel de usuario.

Una desventaja es la sobrecarga en
la ejecuci\'on de las llamadas al sistema y sobretodo por accesos a la red. Todos los enlaces
de red -{\em sockets}- son creados en el UHN,
as\'\i\ se impone comunicaci\'on a trav\'es de ellos si el proceso
migra fuera del UHN. Para solucionar este problema el equipo de la
Universidad Hebrea est\'a desarrollando los {\bf socketa migrables}, los
cuales migran con el proceso y as\'\i\ permite un enlace directo entre
los procesos migrados. Normalmente esta carga que a\~{n}adimos puede
reducirse significativamente con una distribuci\'on inicial de los
procesos de comunicaci\'on en nodos diferentes, como en PVM. Si el
sistema se desequilibra, los algoritmos de openMosix
reasignar\'an los procesos para mejorar la eficiencia del sistema.
%---------------------------------------------------------------------------------------
\subsubsection*{Los algoritmos para la compartici\'on adaptativa de recursos}
Los algoritmos de compartici\'on de recursos en
openMosix son dos:
\begin{enumerate}
  \item el de {\bf equilibrado din\'amico de carga:} {\em Load Balancing},
  \item y el encargado de la {\bf gesti\'on de memoria:} {\em Memory Ushering}.
\end{enumerate}

\vspace{.2in}
{\bf\sc i.- Load Balancing}

\vspace{.1in}
El algoritmo de equilibrado
din\'amico de carga continuamente intenta reducir la diferencia de
carga entre pares de nodos, migrando procesos desde los m\'as cargados
hacia los menos cargados, independientemente del par de nodos. El
n\'umero de procesadores de cada nodo y su velocidad son factores
importantes para tomar este tipo de decisiones. Este algoritmo
responde a cambios en la carga de los nodos o a las caracter\'\i
sticas en la ejecuci\'on de los procesos. A lo largo de este proceso de
toma de decisiones prevalece el porcentage de memoria libre o la carga
de procesos y no la escasez de recursos.

\vspace{.2in}
{\bf\sc ii.- Memory Ushering}

\vspace{.1in}
{\em Memory Ushering} inspira su nombre en una pol\'\ tica que los
desarrolladores de openMosix llaman {\em prevenci\'on de
agotamiento}. Intenta disponer el m\'aximo n\'umero de procesos en
la RAM del sistema -entendi\'endose la totalidad de la memoria del cluster- para evitar en lo posible el {\em thrashing} y el {\em
  swapping} de los procesos. El algoritmo se invoca cuando un nodo
empieza una paginaci\'on excesiva, debida generalmente a una escasez
de memoria libre.
%---------------------------------------------------------------------------------------
\subsubsection*{Acceso a ficheros}
Uno de los mayores problemas de los clusters SSI es que
cada nodo tiene que ser capaz de ver el mismo sistema de ficheros que
cualquier otro nodo. Pongamos por ejemplo un programa que abre
el fichero {\em /tmp/moshe} para escritura y lectura, y luego este
proceso migra a otro nodo del cluster. El fichero en cuesti\'on deber\'a ser capaz de permanecer
como de lectura y escritura.

Hasta ahora hab\'\i a dos opciones para hacer esto. Una es que el
cluster openMosix interceptara todas las E/S de los trabajos
migrados, y las reenviara a su correspondiente UHN para su procesamiento posterior.

Alternativamente podr\'\i a crearse una visi\'on global de un sistema de
ficheros a trav\'es de NFS. La primera es m\'as dif\'\i cil de
desarrollar, pero m\'as f\'acil de gestionar. La segunda es m\'as
f\'acil de implementar, pero puede ser un rompecabezas montar todos
los sistemas de ficheros de manera inteligente, permitiendo que cada
nodo pueda acceder a cualquier otro nodo. Adicionalmente, se tendr\'\i
a que asegurar que todos los identificadores de usuario y de grupo son
consistentes entre todos los nodos del cluster, de otro modo nos
topar\'\i amos con  serios problemas de permisos.

Buscando entre las mejores investigaciones de los modernos sistemas de
ficheros y aplicando estas ideas a openMosix surgi\'o DFSA (Direct
File System Access). El DFSA fue dise\~{n}ado para reducir el exceso
de carga de la ejecuci\'on de llamadas de sistema orientadas a E/S de
los procesos migrados. Esto se consigui\'o permitiendo la ejecuci\'on
de la mayor\'\i a de llamadas a sistema de forma local, es decir, en el nodo
donde se encuentre el proceso. En adici\'on a DFSA se gener\'o un
nuevo algoritmo que hace un recuento de las operaciones de E/S. Este algoritmo se basa en
que a un proceso que requiera un n\'umero medio/alto de
operaciones de E/S se le tiende a migrar al nodo donde realizar\'a la
mayor\'\i a de estas operaciones. Una ventaja obvia es que los
procesos de E/S tienen mayor flexibilidad para migrar desde su
respectivo UHN para mejorar el equilibrado de carga. No obstante, a
diferencia de NFS que sirve los datos desde el servidor hacia los nodos,
openMosix intentar\'a migrar el proceso al nodo
en el que el fichero resida en aquel momento.

\subsection*{La implementaci\'on}
\subsubsection*{Mecanismos en el {\em remote} y en el {\em deputy}}
El {\em deputy} es la parte que representa al proceso remoto
en el UHN. Debido a que la totalidad del espacio de usuario en memoria
reside en el nodo remoto, el {\em deputy} no mantiene un mapa de memoria
de \'el mismo. En lugar de esto comparte el mapa principal del kernel de forma
similar a una hebra del kernel.

En algunas actividades del kernel, como pueden ser la ejecci\'on de
las llamadas de sistema, se hace necesario transferir datos entre el
espacio de usuario y el espacio de kernel. En openMosix cualquier operaci\'on de memoria del
kernel que implique acceso al espacio de usuario requiere que el {\em deputy}
comunique con su correspondiente {\em remote} para transferir los datos necesarios.

Con el fin de poder eliminar excesivas copias
remotas se implement\'o una cache especial que
reduce el n\'umero de interacciones requeridas con {\em pre-fetching},
transfiriendo el mayor volumen de datos posible durante la petici\'on
inicial de llamada a sistema, mientras se almacenan datos parciales en el
{\em deputy} para devolverlos al remoto al final de la llamada a sistema.

Los procesos remotos no son accesibles por los otros procesos que se
ejecutan en el mismo nodo y {\em vice versa}. No pertenecen a ning\'un usuario en particular en el nodo
donde se ejecutan ni pueden recibir se\~{n}ales desde el nodo
en el que se estan ejecutando. Su
memoria no puede ser accedida y solo pueden ser forzados, por parte
del propio administrador del nodo en el que se est\'an ejecutando, a
migrar fuera del nodo.
%-----------------------------------------------------------------------------------
\subsubsection*{Cuando no puede aplicarse la migraci\'on}
Ciertas funciones del kernel de Linux no son compatibles
con la divisi\'on de \'areas de los procesos, para que estas se ejecuten remotamente. Algunos ejemplos obvios
son las manipulaciones directas de dispositivos de E/S, tales como
accesos directos a instrucciones privilegiadas del bus de E/S, o el
acceso directo a la memoria del dispositivo. Otros ejemplos incluyen
memoria compartida de escritura y planificadores a tiempo real.

Un proceso que usa alguna de estas funciones es asignado indefinidamente
a su UHN. Si el proceso ya hab\'\i a estado migrado, se retorna al UHN.
%-----------------------------------------------------------------------------------
\subsection*{Muestreo de informaci\'on}
Las estad\'\i sticas acerca del comportamiento del
cluster son muestreadas regularmente. Estas incluyen todas las llamadas
de sistema o cada vez que un proceso accede a datos de usuario. Esta
informaci\'on es usada para determinar si el proceso debe devolverse a
su UHN. Estas estad\'\i sticas caducan en el tiempo, para ajustarse a
procesos que cambian su perfil de ejecuci\'on. 

Cada proceso tiene cierto control sobre el muestreo de informaci\'on
y sobre la caducidad de sus estad\'\i sticas. Toda la informaci\'on acerca del
API de openMosix puede encontrarse en la secci\'on {\em El API de openMosix}.


