PDF de programación - EL PROYECTO DE CLUSTER SSI OPENMOSIX

EL PROYECTO DE CLUSTER SSI OPENMOSIX

David Santo Orcero

Mantenedor de las herramientas de área de usuario del proyecto OpenMosix

[email protected], http://www.orcero.org/irbis

RESUMEN

OpenMosix es el único proyecto con licencia GPL con su-
ficiente calidad para ser usado en entornos de producción
capaz de implementar un cluster con un modelo SSI, frente
a otros proyectos no libres –MOSIX– o que aún están en
fase alfa –SSI-C– existentes en el mercado.

En este artículo vamos a estudiar los conceptos claves

de OpenMosix, así como su historia y su funcionamiento.

1. LOS SISTEMAS SSI

Denominamos sistemas SSI –Single System Image– [1]
a aquellos sistemas de clustering en los que todo el cluster
ofrece al usuario la imagen de un único sistema, es decir,
que el cluster entero se comportará para el usuario como
una única máquina.

Desde un punto de vista menos formal, la idea de un
cluster SSI es poder administrar y usar un cluster completo
como si se tratara de una máquina SMP o, en el peor de los
casos, de una máquina NUMA.

Los sistemas SSI siempre han sido de interés de la in-
dustria informática, y actualmente son objeto de investiga-
ción intensa en el área de los sistemas operativos distribui-
dos y de gran interés en la comunidad general, con espacio
dentro de los foros de en clustering [2]. El problema que
los SSI deben resolver es bastante complejo, ya que se su-
pone que un sistema operativo SSI puro debe ser capaz de
hacer transparente el paralelismo del cluster al proceso y
al administrador. Esto significa que cualquier proceso debe
poder migrar desde cualquier nodo del cluster a cualquier
otro nodo y ejecutarse en él, independientemente de donde
haya sido lanzado; y que puede hacerlo tantas veces como
quiera, para así aprovechar mejor los recursos del sistema.
Las aplicaciones, además, deben ser capaces de poder usar
esta capacidad de migrar sin necesidad de ser recompiladas
ni de enlazar ninguna biblioteca específica de migración.

De entre los sistemas con alguna de las características
de un sistema SSI que han existido –y existen– en el me-
cado, debemos destacar el VMS para VAX, de Digital, el
Sysplex de IBM para su OS/390, o el sistema MOSIX [3].
Sin embargo, ninguno de estos sistemas SSI son libres.

Por otro lado, tenemos el SSI de Compaq, que ha toma-
do muchas ideas y código de MOSIX –como OpenMosix–,
de la época en que MOSIX era libre; pero aún esta muy lejos
de ser lo suficientemente estable como para poder ejecutarse
en un cluster en producción.

En este artículo vamos a revisar el sistema libre SSI

OpenMosix.

2. EL ORIGEN DE OPENMOSIX

El proyecto OpenMosix [4] es un fork libre del proyecto
MOSIX. Por ello, vamos a comenzar estudiando la historia
del proyecto MOSIX.

El proyecto MOSIX fue desarrollado por el profesor
Amnon Barak y su equipo –Oren La’adan, Ammon Shiloh
y Moshe Bar, entre otros– en la Universidad Hebrea de Je-
rusalén. Su desarrollo original fue parte de un proyecto fi-
nanciado originalmente por el DARPA para un cluster de
máquinas PDP-11/45 usado en las fuerzas aéreas norteame-
ricanas. Después este sistema se adaptó también a clusters
PDP-11/10. El sistema operativo era el Unix 6 de Bell Labs,
y fue desarrollando entre 1977 y 1979. En aquella época, el
proyecto se llamaba “UNIX with Satellite Processors”. La
idea de este proyecto era parchear masívamente el kernel
para permitir la migración automática de procesos según un
algoritmo de equilibrado de carga del que hablaremos más
adelante, de tal forma que el aprovechamiento de los recur-
sos del cluster sea el mayor posible –y, por lo tanto, mayor la
probabilidad de que un proceso determinado de uno de los
nodos con más carga termine más deprisa, al no tener que
competir por procesador con tantos procesos como compe-
tiría sin MOSIX–.

El resultado de este primer desarrollo fue excelente, y,
tras un año dedicado a otras actividades, el prof. Barak co-
menzó a trabajar en el nuevo proyecto MOS. Este proyecto
siguió con las ideas del proyecto anterior; y supuso en la
práctica una reimplementación completa del antiguo pro-
yecto “UNIX with Satellite Processors” -‘‘reencarnaci ón”,
tal y como el profesor Barak denominará las reimplementa-
ciones de MOSIX en su bibliografía-. MOS fue desarrollado
entre los años 1981 y 1982 para las máquinas PDP-11/45 y
PDP-11/23, parcheando masívamente el sistema operativo

Unix 7, también de Bell Labs.

En una tercera fase, que se desarrolló durante los años
1983 y 1984, el proyecto MOS fue portado a una máquina
CADMUS/PCS MC68K, que ejecutaba el Unix 7 de Bell
Labs con algunas extensiones de BSD 4.1.

Después de su adaptación a CADMUS/PCS MC68K, el
proyecto MOS, aún completamente SSI, estubo completa-
mente detenido durante dos años. Pero en 1987 el profe-
sor Barak retomó el desarrollo, ahora llamando a la nueva
reencarnación de MOS con el nombre “NSMOS”. NSMOS
fue desarrollado sobre una máquina NS32332, que ejecu-
taba AT&T Unix system V release 2. El proyecto NSMOS
comenzó a dejar el área de kernel de cada proceso en el
nodo raíz, ya que ya no era posible modificar todos los pro-
gramas de área de usuario de Unix que eran precisos para
mantener el área de kernel migrable. Este cambio, que se ha
mantenido hasta nuestros dias, permite que no sea necesario
modificar ninguna de las aplicaciones de Unix para que sean
ejecutadas en un cluster MOSIX/OpenMosix satisfactoria-
mente, a cambio de que el área de kernel de los procesos se
ejecute siempre en su nodo raiz.

En 1998, el equipo del profesor Barak porta NSMOS a
las arquitecturas VAX-780 y VAX-750, que también ejecu-
taban el AT&T Unix system V release 2. Como en el caso
anterior, no es parcheado masívamente el sistema operativo,
sino apenas su kernel. El proyecto pasa a llamarse MOSIX,
nombre que conservaría hasta hoy en dia.

Aún en 1988, el sistema SSI MOSIX es portado a arqui-
tecturas NS32532, también con AT&T Unix system V re-
lease 2. Este porting llevó dos años, seguidos por dos años
en que el profesor Barak paró el proyecto.

Ya entrando en los noventa, el profesor Barak comien-
za a trabajar con arquitecturas Intel. En 1991 comienza el
porting de MOSIX a BSD/OS sobre 486, porting que lle-
varía tres años en completarse. Entre 1994 y 1997, volvería
otra vez el profesor Barak a parar el proyecto, ahora durante
cinco años.

En 1998, el profesor Barak vió que BSD/OS estaba desa-
pareciendo, y decidió portar MOSIX a un sabor de Unix
bastante popular en la época: Linux. Esta reencarnación de
MOSIX sólo funcionaba para máquinas i80486 o superio-
res, y usaba el kernel 2.2. Un año más tarde de la reencar-
nación de MOSIX en Linux, por la naturaleza vírica de la
licencia GPL con la que fue desarrollado el kernel de Li-
nux, el profesor Barak se vió legalmente forzado a liberar
el código de MOSIX. Este hecho fue aplaudido por alguno
de los colaboradores del profesor Barak, tales como Moshe
Bar; aunque el profesor Barak no se quedó muy convencido
del hecho. Las herramientas de area de usuario, imprescin-
dibles para configurar y administrar un cluster MOSIX, no
fueron liberadas hasta medio año más tarde; y debido a la
presión de la comunidad Linuxera, no a ningún plan deter-
minado del profesor Barak. Estas herramientas de area de

usuario permanecieron libres hasta final del 2001.

Una vez liberadas las herramientas de área de usuario, el
proyecto MOSIX se popularizó rápidamente, ya que permi-
tia SSI real en clusters Linux, algo que otros paquetes aún
sólo prometen. MOSIX fue incluido por defecto en la ma-
yor parte de las distribuciones importantes, tales como De-
bian o Mandrake, y una parte importante de la comunidad
intentó apoyar el proyecto MOSIX enviando parches y nue-
vas funcionalidades, sin que ninguno despertase el interés
del profesor Barak.

En el año 2000 comenzó el porting al kernel 2.4 de Li-
nux, que terminó un año más tarde. Este código también
estaba liberado bajo GPL, pero el hecho de que MOSIX no
avanzara durante todo el 2001 y que el profesor Barak no
aceptaba cualquier tipo de ayuda externa que él no contro-
lase directamente, terminó desencadenando el fork.

En el año 2002, la situación terminó estallando en las
manos del profesor Barak. El profesor Barak decidió cam-
biar la licencia de MOSIX retirando el derecho a adaptar
el código al uso propio allí donde le fue posible modificar
la licencia sin violar la GPL. Además, el proyecto MOSIX
llevaba un año parado, el profesor Barak estaba rechazando
los parches que aportaban mejoras y nuevas funcionalidades
a MOSIX, y estaba ocultando este hecho a sus colaborado-
res, entre ellos a Moshe Bar –el antiguo alumno del profesor
Barak más brillante–, en esta época ya la mano derecha del
profesor Barak y coresponsable del proyecto.

Todo esto originó que grupo importante del equipo que
había desarrollado MOSIX y de usuarios de MOSIX entre
los que se encontraba Moshe Bar –coadministrador del pro-
yecto MOSIX y mano derecha del profesor Barak, y au-
tor del MFS, y del DFSA–, Mark Veltzer –Windows2Linux,
sgmltools-lite, contribuciones al CPAN–, Muli Ben Yehu-
da –Syscalltrack, pptp–, Brian Bilbrey –LinuxBook, gran
cantidad de documentación libre para Linux–, Brian Pontz
–Apache log rotator–, Louis Zechtzer, Michael Farnbach,
Bruce Knox, y David Santo Orcero –el autor de este artículo–
tomaron la última versión de Mosix que era posible demos-
trar en un tribunal que era GPL, y comenzaron a trabajar por
su cuenta. Con modelo de desarrollo de bazar, bajo GPL y
con CVS abierto a todos. Y, sorprendentemente, comenza-
ron masivamente las descargas de OpenMosix y las cola-
boraciones en forma de parches y localización de errores.
Había comenzado el proyecto OpenMosix.

Actualmente el proyecto MOSIX tiene una licencia de
código cerrado para una parte muy importante del código
por la que no es legal modificarlo –y mucho menos distri-
buir las mejoras–, y