\newpage
%===========================================================================
%       x.12 > Qu\'e es realmente openMosix
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
       \includegraphics[bb = -250 220 0 0, scale=1.1]{./TuXes/tux-biz.jpg}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
       \includegraphics[-280,630][0,0]{./TuXes/tux-biz}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{?`QU\'E ES REALMENTE OPENMOSIX?}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em There are two ways of constructing a software design;}}

\hspace{1in}\textcolor{blue_omosix}{{\em  one way is to make it so simple that there are obviously no deficiencies, }}

\hspace{1in}\textcolor{blue_omosix}{{\em and the other way is to make it so complicated that there are no obvious deficiencies.}}

\hspace{1in}\textcolor{blue_omosix}{{\em The first method is far more difficult.}}

\hspace{4in}\textcolor{blue_omosix}{{\em C. A. R. Hoare}}
\vspace{0.5in}
\end{latexonly}
%===========================================================================
\subsection{Una muy breve introducci\'on al clustering}
\hspace{0.5in}La mayor parte del tiempo tu computadora permanece ociosa. Si lanzas un programa de monitorizaci\'on del sistema
como {\tt xload} o {\tt top}, ver\'as probablemente que la lectura de la carga de tu procesador permanece generalmente por debajo del 10\%.

Si tienes al alcance varias computadoras los resultados ser\'an los mismos ya que no podr\'as interactuar 
con m\'as de una de ellas al mismo tiempo. Desafortunadamente cuando realmente necesites
potencia computacional (como por ejemplo para comprimir un fichero {\em Ogg Vorbis}, o para una gran compilaci\'on)
no podr\'as disponer de la potencia conjunta que te proporcionar\'\i  an todas ellas como un todo.

La idea que se esconde en el trasfondo del {\em clustering} es precisamente poder contar con todos los recursos que puedan
brindarte el conjunto de computadoras de que puedas disponer para poder aprovechar aquellos que permanecen sin usar, basicamente 
en otras computadoras.

La unidad b\'asica de un cluster es una computadora simple, tambi\'en denominada {\bf nodo}.
Los clusters pueden crecer en tama\~no (o mejor dicho, pueden {\em escalar}) a\~{n}adiendo m\'as m\'aquinas.

Un cluster como un todo puede ser m\'as potente que la m\'as veloz de las m\'aquinas con las que cuenta, factor que estar\'a ligado
irremediablemente a la velocidad de conexi\'on con la que hemos construido las comunicaciones entre nodos.

Adem\'as, el sistema operativo del cluster puede hacer un mejor uso del hardware disponible en respuesta al cambio de condiciones.
Esto produce un reto a un cluster heterog\'eneo (compuesto por m\'aquinas de diferente arquitectura) tal como iremos viendo paso a paso. 
%---------------------------------------------------------------------------------------------------------
\subsubsection{HPC, Fail-over y Load-balancing}
\hspace{0.5in}B\'asicamente existen tres tipos de clusters: {\em Fail-over}, {\em Load-balancing} y {\em HIGH Performance Computing}.

Los clusters {\bf Fail-over} consisten en dos o m\'as computadoras conectadas en red con una conexi\'on {\em heartbeat} separada entre ellas.
La conexi\'on heartbeat entre las computadoras es usualmente utilizada para monitorear cu\'al de todos los
servicios est\'a en uso, as\'\i \ como la sustituci\'on de una m\'aquina por otra cuando uno de sus servicios haya ca\'\i  do.

El concepto en los {\bf Load-balancing} se basa en que cuando haya una petici\'on entrante al servidor web, el cluster
verifica cu\'al de las m\'aquinas disponibles posee mayores recursos libres, para luego asignarle el trabajo pertinente.

Actualmente un cluster {\em load-balancing} es tambi\'en {\em fail-over} con el extra del balanceo de la carga y a menudo con mayor n\'umero de nodos.

La \'ultima variaci\'on en el clustering son los {\bf High Performance Computing}.

Estas m\'aquinas han estado configuradas especialmente para centros de datos que requieren una potencia de computaci\'on extrema.

Los clusters {\bf Beowulf} han sido dise\~{n}ados espec\'\i  ficamente para estas tareas de tipo masivo, teniendo en contrapartida otras limitaciones que no lo hacen tan accesible para el usuario como un openMosix.
%---------------------------------------------------------------------------------------------------------
\subsubsection{Mainframes y supercomputadoras vs. clusters}
\hspace{0.5in}Tradicionalmente los {\em mainframes} y las supercomputadoras han estado construidas solamente por 
unos fabricantes muy concretos y para un colectivo elitista que necesitaba gran potencia de c\'alculo, como pueden ser empresas o universidades.

Pero muchos colectivos no pueden afrontar el costo econ\'omico que supone adquirir una m\'aquina de estas caracter\'\i  sticas, 
y aqu\'\i \ es donde toma la m\'axima importancia la idea de poder disponer de esa potencia de c\'alculo, pero a un precio muy inferior.

El concepto de cluster naci\'o cuando los pioneros de la supercomputaci\'on intentaban difundir diferentes procesos entre varias
computadoras, para luego poder recoger los resultados que dichos procesos deb\'\i  an producir.
Con un hardware m\'as barato y f\'acil de conseguir se pudo perfilar que podr\'\i  an conseguirse resultados
muy parecidos a los obtenidos con aquellas m\'aquinas mucho m\'as costosas, como se ha venido probando desde entonces.
%---------------------------------------------------------------------------------------------------------
\subsubsection{Modelos de clusters NUMA, PVM y MPI}
\hspace{0.5in}Hay diferentes formas de hacer procesamiento paralelo, entre las m\'as conocidas y usadas podemos destacar NUMA, PVM y MPI.
 
Las m\'aquinas de tipo NUMA (Non-Uniform Memory Access) tienen acceso compartido a la memoria donde pueden ejecutar su c\'odigo de programa.
En el kernel de Linux hay ya implementado NUMA, que hace variar el n\'umero de accesos a las diferentes regiones de memoria.

PVM / MPI son herramientas que han estado ampliamente utilizadas y son muy conocidas por la gente que entiende de supercomputaci\'on basada en GNU/Linux.

MPI es el est\'andar abierto de bibliotecas de paso de mensajes. MPICH es una de las implementaciones m\'as usadas de MPI, tras MPICH se puede encontrar LAM,
otra implementaci\'on basada en MPI tambi\'en con bibliotecas de c\'odigo abierto.

PVM (Parallel Virtual Machine) es un primo de MPI que tambi\'en es ampliamente usado para funcionar en entornos Beowulf.

PVM habita en el espacio de usuario y tiene la ventaja que no hacen falta modificaciones en el kernel de Linux, basicamente cada usuario con derechos suficientes
puede ejecutar PVM.
\subsection{Una aproximaci\'on histo\'orica}
\subsubsection{Desarrollo hist\'orico}
\hspace{0.5in}Algunos rumores hablaban que MOSIX ven\'\i  a de Moshe Unix.
Inicialmente Mosix empez\'o siendo una aplicaci\'on para BSD/OS 3.0, como podemos leer en este email:

\begin{verbatim}
Announcing MO6 for BSD/OS 3.0
Oren Laadan (orenl@cs.huji.ac.il)
Tue, 9 Sep 1997 19:50:12 +0300 (IDT)

Hi:

We are pleased to announce the availability of MO6 Version 3.0
Release 1.04 (beta-4) - compatible with BSD/OS 3.0, patch level
K300-001 through M300-029.

MO6 is a 6 processor version of the MOSIX multicomputer enhancements
of BSD/OS for a PC Cluster. If you have 2 to 6 PC's connected by a
LAN, you can experience truly multi-computing environment by using
the MO6 enhancements.

The MO6 Distribution
--------------------
MO6 is available either in "source" or "binary" distribution. It is
installed as a patch to BSD/OS, using an interactive installation
script.

MO6 is available at http://www.cnds.jhu.edu/mirrors/mosix/
or at our site: http://www.cs.huji.ac.il/mosix/

Main highlights of the current release:
--------------------------------------
- Memory ushering (depletion prevention) by process migration.
- Improved installation procedure.
- Enhanced migration control.
- Improved administration tools.
- More user utilities.
- More documentation and new man pages.
- Dynamic configurations.

Please send feedback and comments to mosix@cs.huji.ac.il.
-------------------
\end{verbatim}

La plataforma GNU/Linux para el desarrollo de posteriores versiones fue elegida en la s\'eptima reencarnaci\'on, en 1999.

A principios de 1999 Mosix M06 fue lanzado para el kernel de Linux 2.2.1.

Entre finales de 2001 e inicios de 2002 nac\'\i  a openMosix, la versi\'on de c\'odigo abierto, de forma separada.
%---------------------------------------------------------------------------------------------------------
\subsubsection{openMosix != MOSIX}
\hspace{0.5in}openMosix en principio ten\'ia que ser una ampliaci\'on a lo que a\~{n}os atr\'as ya se pod\'\i  a encontrar en {\tt www.mosix.org}, respetando todo el trabajo llevado a cabo
por el Prof. Barak y su equipo.

Moshe Bar estuvo ligado al proyecto Mosix, en la Universidad Hebrea de Jerusalem, durante bastantes a\~{n}os.
Era el co-administrador del proyecto y el principal administrador de los asuntos comerciales de {\em Mosix company}.

Tras algunas diferencias de opini\'on sobre el futuro comercial de Mosix, Moshe Bar empez\'o un nuevo proyecto de {\em clustering} alzando la empresa {\em Qlusters, Inc.}
en la que el profesor A. Barak\footnote{{\tt \htmladdnormallink{http://www.cs.huji.ac.il/\~{}amnon/}{http://www.cs.huji.ac.il/\~{}amnon/}}} decidi\'o no participar ya que no quer\'\i  a poner Mosix bajo licencia GPL.

Como hab\'\i  a una significativa base de usuarios clientes de la tecnologia Mosix (unas 1000 instalaciones a lo ancho del planeta) Moshe Bar
decidi\'o continuar el desarrollo de Mosix pero bajo otro nombre, openMosix, totalmente bajo licencia GPL2.

openMosix es un parche ({\em patch}) para el kernel de linux que proporciona compatibilidad completa con el estardard de Linux para plataformas IA32. Actualmente se est\'a trabajando para portarlo a IA64.

El algoritmo interno de balanceo de carga migra, transparentemente para el usuario, los procesos entre los nodos del cluster.
La principal ventaja es una mejor compartici\'on de recursos entre nodos, as\'\i \ como un mejor aprovechamiento de los mismos.

El cluster escoge por s\'\i \ mismo la utilizaci\'on \'optima de los recursos que son necesarios en cada momento, y de forma autom\'atica.

Esta caracter\'\i  stica de migraci\'on transparente hace que el cluster funcione a todos los efectos como un gran sistema SMP ({\em Symmetric Multi Processing}) con varios
procesadores disponibles. Su estabilidad ha sido ampliamente probada aunque todav\'\i  a se est\'a trabajando en diversas l\'\i  neas para aumentar su eficiencia.

openMosix est\'a respaldado y siendo desarrollado por personas muy competentes y respetadas en el mundo del {\em open source}, trabajando juntas en todo el mundo.

El punto fuerte de este proyecto es que intenta crear un est\'andar en el entorno del clustering para todo tipo de aplicaciones HPC.

openMosix tiene una p\'agina web\footnote{{\tt
\htmladdnormallink{http://www.openmosix.org}{http://www.openmosix.org}}}
con un \'arbol CVS\footnote{{\tt
\htmladdnormallink{http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openmosix/}{http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openmosix/}}}
y un par de listas de correo para los desarrolladores y para los
usuarios.
\subsubsection{openMosix en acci\'on: un ejemplo}
\hspace{0.5in}Los clusters openMosix pueden adoptar varias formas. Para demostrarlo intentad imaginar que compartes el piso de estudiante
con un chico adinerado que estudia ciencias de la computaci\'on. Imaginad tambi\'en que ten\'eis las computadoras conectadas en red para formar un cluster openMosix.

Asume tambi\'en que te encuentras convirtiendo ficheros de m\'usica desde tus CDs de audio a Ogg Vorbis para tu uso privado, cosa que resulta ser legal en tu pa\'\i  s.

Tu compa\~{n}ero de habitaci\'on se encuentra trabajando en un proyecto de C++ que seg\'un dice podr\'a traer la paz mundial, pero en este justo momento
est\'a en el servicio cantando cosas ininteligibles, y evidentemente su computadora est\'a a la espera de ser intervenida de nuevo.

Resulta que cuando inicias un programa de compresi\'on, como puede ser {\tt bladeenc} para convertir un preludio de Bach desde el fichero {\em .wav} al {\em .ogg}, las rutinas de openMosix
en tu m\'aquina comparan la carga de procesos en tu m\'aquina y en la de tu compa\~{n}ero y deciden que es mejor migrar las tareas de compresi\'on ya que el otro nodo es m\'as
potente debido a que el chico dispon\'\i  a de m\'as medios econ\'omicos para poderse permitir una computadora m\'as potente, a la vez que en ese momento permanece ociosa 
ya que no se encuentra frente a ella.

As\'\i \ pues lo que normalemte en tu pentium233 tardar\'\i  a varios minutos te das cuenta que ha terminado en pocos segundos.

\hspace{0.5in}Lo que ha ocurrido es que gran parte de la tarea ha sido ejecutada en el AMD AthlonXP de tu compa\~{n}ero, de forma transparente a ti.

Minutos despu\'es te encuentras escribiendo y tu compa\~{n}ero de habitaci\'on vuelve del servicio. \'Este reanuda sus pruebas de compilaci\'on utilizando {\tt pmake}, una versi\'on
del {\tt make} optimizada para arquitecturas paralelas. Te das cuenta que openMosix est\'a migrando hacia tu m\'aquina algunos subprocesos con el fin de equilibrar la carga.

Esta configuraci\'on se llama {\em single-pool}: todas las computadoras est\'an dispuestas como un \'unico cluster.
La ventaja o desventaja de esta disposici\'on es que tu computadora es parte del {\em pool}: tus procesos ser\'an ejecutados, al menos en parte, en otras
computadoras, pudiendo atentar contra tu privacidad de
datos. Evidentemente las tareas de los dem\'as tambi\'en podr\'an ser
ejecutadas en la tuya.
