Openmosix

Por Abián & AcidBorg
Versión 1.0
Proyecto OpenMosix - 1
LICENCIA
Copyright (c) 2004 Abián & AcidBorg
Permission is granted to copy, distribute and/or modify this document

under the terms of the GNU Free Documentation License, Version 1.2 or any
later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.
GNU Free Documentation License

Version 1.2, November 2002
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.

59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other

functional and useful document "free" in the sense of freedom: to assure
everyone the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially. Secondarily, this
License preserves for the author and publisher a way to get credit for their
work, while not being considered responsible for modifications made by
others.
This License is a kind of "copyleft", which means that derivative works

of the document must themselves be free in the same sense. It complements the
GNU General Public License, which is a copyleft license designed for free
software.
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free program
should come with manuals providing the same freedoms that the software does.
But this License is not limited to software manuals; it can be used for any
textual work, regardless of subject matter or whether it is published as a
printed book. We recommend this License principally for works whose purpose
is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be distributed
under the terms of this License. Such a notice grants a world-wide, royalty-
free license, unlimited in duration, to use that work under the conditions
stated herein. The "Document", below, refers to any such manual or work.
Any member of the public is a licensee, and is addressed as "you". You accept
the license if you copy, modify or distribute the work in a way requiring
permission under copyright law.
A "Modified Version" of the Document means any work containing the

Document or a portion of it, either copied verbatim, or with modifications
and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the publishers
or authors of the Document to the Document's overall subject (or to related
matters) and contains nothing that could fall directly within that overall
subject. (Thus, if the Document is in part a textbook of mathematics, a
Secondary Section may not explain any mathematics.) The relationship could be
a matter of historical connection with the subject or with related matters,
or of legal, commercial, philosophical, ethical or political position
regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles

are designated, as being those of Invariant Sections, in the notice that says
that the Document is released under this License. If a section does not fit
the above definition of Secondary then it is not allowed to be designated as
Invariant. The Document may contain zero Invariant Sections. If the Document
does not identify any Invariant Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that the
Document is released under this License. A Front-Cover Text may be at most 5
words, and a Back-Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy,

represented in a format whose specification is available to the general
public, that is suitable for revising the document straightforwardly with
generic text editors or (for images composed of pixels) generic paint
programs or (for drawings) some widely available drawing editor, and that is
suitable for input to text formatters or for automatic translation to a
variety of formats suitable for input to text formatters. A copy made in an
otherwise Transparent file format whose markup, or absence of markup, has
been arranged to thwart or discourage subsequent modification by readers is
not Transparent. An image format is not Transparent if used for any
substantial amount of text. A copy that is not "Transparent" is called
"Opaque".
Examples of suitable formats for Transparent copies include plain ASCII

without markup, Texinfo input format, LaTeX input format, SGML or XML using a
publicly available DTD, and standard-conforming simple HTML, PostScript or
PDF designed for human modification. Examples of transparent image formats
include PNG, XCF and JPG. Opaque formats include proprietary formats that can
be read and edited only by proprietary word processors, SGML or XML for which
the DTD and/or processing tools are not generally available, and the
machine-generated HTML, PostScript or PDF produced by some word processors
for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus
such following pages as are needed to hold, legibly, the material this
License requires to appear in the title page. For works in formats which do
not have any title page as such, "Title Page" means the text near the most
prominent appearance of the work's title, preceding the beginning of the body
of the text.
A section "Entitled XYZ" means a named subunit of the Document whose

title either is precisely XYZ or contains XYZ in parentheses following text
that translates XYZ in another language. (Here XYZ stands for a specific
section name mentioned below, such as "Acknowledgements", "Dedications",
"Endorsements", or "History".) To "Preserve the Title" of such a section when
you modify the Document means that it remains a section "Entitled XYZ"
according to this definition.
The Document may include Warranty Disclaimers next to the notice which
states that this License applies to the Document. These Warranty Disclaimers
are considered to be included by reference in this License, but only as
regards disclaiming warranties: any other implication that these Warranty
Disclaimers may have is void and has no effect on the meaning of this
License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the copyright
notices, and the license notice saying this License applies to the Document
are reproduced in all copies, and that you add no other conditions whatsoever
to those of this License. You may not use technical measures to obstruct or
control the reading or further copying of the copies you make or distribute.
However, you may accept compensation in exchange for copies. If you
distribute a large enough number of copies you must also follow the
conditions in section 3.
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have
printed covers) of the Document, numbering more than 100, and the Document's
license notice requires Cover Texts, you must enclose the copies in covers
that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on
the front cover, and Back-Cover Texts on the back cover. Both covers must
also clearly and legibly identify you as the publisher of these copies. The
front cover must present the full title with all words of the title equally
prominent and visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve the
title of the Document and satisfy these conditions, can be treated as
verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit reasonably) on
the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering

more than 100, you must either include a machine-readable Transparent copy
along with each Opaque copy, or state in or with each Opaque copy a computer-
network location from which the general network-using public has access to
download using public-standard network protocols a complete Transparent copy
of the Document, free of added material. If you use the latter option, you
must take reasonably prudent steps, when you begin distribution of Opaque
copies in quantity, to ensure that this Transparent copy will remain thus
accessible at the stated location until at least one year after the last time
you distribute an Opaque copy (directly or through your agents or retailers)
of that edition to the public.
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give them
a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release the
Modified Version under precisely this License, with the Modified Version
filling the role of the Document, thus licensing distribution and
modification of the Modified Version to whoever possesses a copy of it. In
addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has fewer than five),
unless they release you from this requirement.
C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title, and add
to it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section Entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the "History" section.
You may omit a network location for a work that was published at
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications",
Preserve the Title of the section, and preserve in the section all
the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
M. Delete any section Entitled "Endorsements". Such a section
may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled "Endorsements"
or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material copied
from the Document, you may at your option designate some or all of these
sections as invariant. To do this, add their titles to the list of Invariant
Sections in the Modified Version's license notice. These titles must be
distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains

nothing but endorsements of your Modified Version by various parties--for
example, statements of peer review or that the text has been approved by an
organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a

passage of up to 25 words as a Back-Cover Text, to the end of the list of
Cover Texts in the Modified Version. Only one passage of Front-Cover Text and
one of Back-Cover Text may be added by (or through arrangements made by) any
one entity. If the Document already includes a cover text for the same cover,
previously added by you or by arrangement made by the same entity you are
acting on behalf of, you may not add another; but you may replace the old
one, on explicit permission from the previous publisher that added the old
one.
The author(s) and publisher(s) of the Document do not by this License

give permission to use their names for publicity for or to assert or imply
endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified versions,
provided that you include in the combination all of the Invariant Sections of
all of the original documents, unmodified, and list them all as Invariant
Sections of your combined work in its license notice, and that you preserve
all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single copy. If
there are multiple Invariant Sections with the same name but different
contents, make the title of each such section unique by adding at the end of
it, in parentheses, the name of the original author or publisher of that
section if known, or else a unique number. Make the same adjustment to the
section titles in the list of Invariant Sections in the license notice of the
combined work.
In the combination, you must combine any sections Entitled "History" in

the various original documents, forming one section Entitled "History";
likewise combine any sections Entitled "Acknowledgements", and any sections
Entitled "Dedications". You must delete all sections Entitled "Endorsements".
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other

documents released under this License, and replace the individual copies of
this License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and

distribute it individually under this License, provided you insert a copy of
this License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate

and independent documents or works, in or on a volume of a storage or
distribution medium, is called an "aggregate" if the copyright resulting from
the compilation is not used to limit the legal rights of the compilation's
users beyond what the individual works permit. When the Document is included
in an aggregate, this License does not apply to the other works in the
aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these

copies of the Document, then if the Document is less than one half of the
entire aggregate, the Document's Cover Texts may be placed on covers that
bracket the Document within the aggregate, or the electronic equivalent of
covers if the Document is in electronic form. Otherwise they must appear on
printed covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute

translations of the Document under the terms of section 4. Replacing
Invariant Sections with translations requires special permission from their
copyright holders, but you may include translations of some or all Invariant
Sections in addition to the original versions of these Invariant Sections.
You may include a translation of this License, and all the license notices in
the Document, and any Warranty Disclaimers, provided that you also include
the original English version of this License and the original versions of
those notices and disclaimers. In case of a disagreement between the
translation and the original version of this License or a notice or
disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements",

"Dedications", or "History", the requirement (section 4) to Preserve its
Title (section 1) will typically require changing the actual title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to copy,
modify, sublicense or distribute the Document is void, and will automatically
terminate your rights under this License. However, parties who have received
copies, or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the
GNU Free Documentation License from time to time. Such new versions will be
similar in spirit to the present version, but may differ in detail to address
new problems or concerns. See http://www.gnu.org/copyleft/ .
Each version of the License is given a distinguishing version number.

If the Document specifies that a particular numbered version of this License
"or any later version" applies to it, you have the option of following the
terms and conditions either of that specified version or of any later version
that has been published (not as a draft) by the Free Software Foundation. If
the Document does not specify a version number of this License, you may
choose any version ever published (not as a draft) by the Free Software
Foundation.
1. INTRODUCCIÓN
1.1 ¿Qué es un cluster?
1.2 ¿Qué es un nodo?
1.3 ¿Qué características tiene un cluster?
1.4 ¿Clusters homogéneos o clusters heterogéneos?
1.5 ¿Qué software necesita un cluster?
1.6 ¿Clusters vs Superordenadores?
1.7 ¿Qué es la escalabilidad?
1.8 ¿Qué tipos de clusters existen?
1.9 ¿Qué es el procesamiento paralelo?
1.10 ¿Qué problemas se pueden resolver mediante paralelización?
1.11 ¿Qué es un sistema distribuido?
1.12 ¿Qué es un sistema operativo distribuido?
1.13 ¿Por qué elegimos GNU/Linux para nuestro clúster?
1.14 ¿Qué es OpenMosix?
1.15 ¿Por qué hemos elegido OpenMosix?
1.16 ¿Cuales son las desventajas de OpenMosix?
1.17 ¿Se puede solucionar el problema de memoria compartida?
1.18 ¿Cuál es el objetivo de este proyecto?
2 CONFIGURACIÓN
2.1 Hardware
2.1.1 Nodos
2.1.2 Router
2.1.3 Topología de red y cableado
2.2Versiones del software
2.2.1 Distribución de linux
2.2.2 Openmosix
2.2.3 Versión del kernel
2.2.4 Userspace Tools
2.2.5 Openmosixview
2.2.6 Librerías MPI
2.3 Opciones de compilación del kernel
2.4 Configuración de la red local
2.4.1 Seguridad en el cluster
2.4.2 Configuración del router
2.4.3 Uso de la red por parte de openMosix
2.5 Openmosix.map
2.6 Openmosix.config
2.7 Scripts
2.8 Sistemas de ficheros
2.9 Detección automática de nodos
2.10El algoritmo de migracion
2.11Consideraciones finales
3. HERRAMIENTAS DE ADMINISTRACIÓN
3.1Openmosix Tools
3.1.1. Mostcl
3.1.2. Mosrun
3.1.3. Migrate
3.1.4. Mosmon
3.1.5. Moslimit
3.1.6. Mps
3.1.7. Setpe
3.2 Openmosixview
3.3 Consideraciones finales
4. TESTS Y BENCHMARKS
4.3 Codificación de ficheros de audio .wav a .mp3
4.4 Cisilia
4.5 Openmosix Stress Test
4.6 NAS Parallel Benchmarks 2.0
4.7 Compilación del kernel
4.8 Pallas MPI Benchmarks (PMB-MPI1)
5. CONCLUSIONES Y OPINIÓN PERSONAL
6. REFERENCIAS
6.1 Webs
6.2 Libros
6.3 Revistas
6.4 Otros
7. AGRADECIMIENTOS
1. INTRODUCCIÓN
¿Qué es un cluster?
Es difícil encontrar una definición formal de cluster y más aún definirlo

por nosotros mismos, por lo que añadimos una definición de un especialista
en la materia:
"Un cluster es una clase de arquitectura de computador paralelo que

se basa en unir máquinas independientes integradas por medio de redes de
interconexión, para proveer un sistema coordinado, capaz de procesar una
carga" ( Dr. Thomas Sterling).
¿Qué es un nodo?
Un nodo es cada uno de los ordenadores que forma parte de un

cluster. Se excluye de esta definición a los hubs,switchs,routers y cualquier
otro dispositivo de interconexión que no participe en la ejecución de los
procesos ni puedan migrarse procesos hacia él.
¿Qué características tiene un cluster?
1. Debe estar compuesto de 2 o más nodos.

2. Sus nodos deben estar conectados entre sí formando una red
Esto excluye a los SMP, los Mainframes y a un sólo nodo, ya que no

disponen de red y no se ajustan a la definición de cluster.Una máquina SMP
(Symetric MultiProcessing) sigue una modelo de paralelismo al utilizar más
de un microprocesador simultáneamente. La memoria y el disco son
igualmente accesibles desde cualquiera de los procesadores).
Un Mainframe es supercomputador con varios procesadores

trabajando en paralelo, cuya memoria puede ser compartida por todos los
procesadores o poseer cada cual la suya propia. La interconexión se realiza
mediante un bus de datos cuya velocidad supera con creces la de cualquier
red.
¿Clusters homogéneos o clusters heterogéneos?
No existe nada que obligue a un cluster a ser homogéneo, es decir,

que todos sus nodos sean iguales. Es más, encontramos en los clusters SSI
la respuesta a esta pregunta. SSI (System Single Image) es la propiedad de
un sistema de ocultar la naturaleza heterogénea y distribuida de los
recursos disponibles y presentarlos a los usuarios y a las aplicaciones como
un sólo recurso unificado de cómputo. Con la SSI los usuarios tienen una
imagen globalizada de los recursos que hay disponibles, sin importar el
nodo al cual están físicamente asociados. También asegura que el sistema
se mantenga balanceado proporcionando un multiprocesamiento común.
Los objetivos en el diseño de una SSI para sistemas clusters se
enfocan principalmente en la total transparencia en el manejo de recursos,
el rendimiento escalable y la disponibilidad del sistema para soportar las
aplicaciones del usuario. Una SSI puede definirse como la ilusión, creada por
hardware o por software, que presenta una colección de recursos como un
sólo, y más poderoso, recurso unificado.
En definitiva, no importa que los nodos sean diferentes, ya que la

abstracción a la que se ven sometidos los habilita para formar parte de un
mismo cluster. Eso sí, es mucho más fácil y cómodo de administrar un
cluster homogéneo que uno heterogéneo ya que nos podemos beneficiar de
la clonación de sistemas y de un proceso de monitorización más claro.
¿Qué software necesita un cluster?
A nivel de sistema se necesita un parche o modificación del kernel del

sistema operativo que permita la utilización de los ordenadores como nodos
del cluster, gestionando la migración de procesos, evaluando la carga del
sistema y tomando decisiones para lograr su balanceo.
A nivel de aplicación se utiliza software generado apoyándose en

bibliotecas especializadas para clusters y procesamiento paralelo, que
persiguen la abstracción de los nodos a un sistema conjunto, permitiendo
crear entornos distribuidos transparentes. Los programas generados suelen
crear subprocesos o subrutinas que son las que se migran a los demás
nodos del cluster logrando el balanceo de carga.
¿Clusters vs Superordenadores?
Las principales ventajas entre un cluster y un superordenador como

puede ser un mainframe son: precio, reutilización, escalabilidad.
En primer lugar, el precio de un cluster con una capacidad de cálculo

similar a la de un mainframe es un 10% menor, lo que permite el ahorro de
ese capital o su inversión en la adquisición de nodos más potentes.
La posibilidad de reutilizar máquinas antiguas para la construcción del

cluster y su gran escalabilidad son circunstancias que favorecen la decisión
del sector empresarial en la adquisición de un cluster, ya que cuando un
mainframe se queda "pequeño" respecto a su capacidad de cálculo no cabe
otra solución que comprar otro mainframe nuevo.
¿Qué es la escalabilidad?
La escalabilidad es una característica de un sistema que consiste en

ser capaz de acomodar sus recursos y rendimiento a las necesidades que se
le exijan. Aquí hablaremos de escalabilidad hacia arriba, es decir, los
sistemas crecen en tamaño, costes, rendimiento y recursos, aunque
también se puede dar una escalabilidad hacia abajo, esto es, reducir costes
mediante la reutilización de componentes.
La escalabilidad ideal es de complejidad lineal, es decir, si un sistema

aumenta en N su número de elementos se espera de él un rendimiento N
veces el inicial y un coste N veces el coste inicial. Esto se aproxima a la
realidad en los sistemas distribuidos ya que el precio de obtener el doble de
procesamiento en uno de estos sistemas es ligeramente superior al comprar
una máquina el doble.
En OpenMosix la escalabilidad permite un cluster con un número

máximo de 65536 nodos trabajando a la vez.
¿Qué tipos de clústers existen?
Existen 3 tipos de clusters de acuerdo a su utilidad: de alta

disponibilidad, de balanceo de carga y de alto rendimiento.
Un cluster de alta disponibilidad (High Availability) consisten en varias

máquinas que comparten los discos duros y se monitorizan entre sí
constantemente. Su utilidad deriva de la necesidad de tener un sistema
capaz de reponerse de un fallo de hardware y de la necesidad de abaratar
los costes de los sistemas redundantes y tolerantes a fallos. Cuando uno de
los equipos cae, los demás migran sus procesos hacia ellos mismos para
que no haya pérdidas de datos y de disponibilidad del conjunto. A su vez, se
encargan de rearrancar al ordenador caído y, tras lograrlo, le devuelven su
carga correspondiente para volver a la normalidad.
La aplicación más común para este tipo de diseño son servidores de

páginas web o de bases de datos tolerantes a fallos y que necesiten estar
operativos las 24 horas del día todos los días del año.
Los clusters de alto rendimiento son los que hemos escogido para
nuestro proyecto. Éstos se basan en un conjunto de máquinas diseñadas
para lograr una capacidad de cálculo máxima al repartirse la carga de los
procesos entre los nodos de acuerdo a las reglas escogidas. Con ésto se
consigue mejorar el rendimiento en la obtención de la solución de un
problema.
Normalmente se utilizan en la resolución de algoritmos científicos, en

las granjas de compilación (conjunto de ordenadores destinados a compilar
una misma cosa entre todos), granjas de renderizado (grupo de máquinas
que se dedican a la visualización, modificación y reproducción de imágenes
en 3D) y en la compresión o cifrado de códigos.
Por último están los clusters de alta confiabilidad, que son una mezcla
de los de alta disponibilidad y los de alto rendimiento. Tienen como objetivo
evitar que las aplicaciones se caigan. No existe otra manera de conservar el
estado de las aplicaciones que mediante la inclusión de puntos de parada
(checkpoints), pero en conexiones de tiempo real no son suficientes, ya que
no se trata únicamente de utilizar el último checkpoint del sistema y
relanzar el servicio.
Estos clusters necesitan tener un único reloj de sistema conjunto. No

pueden ser implementados de manera eficiente, en tiempo real, únicamente
mediante software, debido a problemas de latencia de red. Este tipo de
clusters no son fácilmente implementables en la actualidad.
Todos los clusters mencionados anteriormente hacen uso de un

sistema de balanceo de carga que reparte los procesos entre todos los
nodos del cluster de forma que no haya ningún nodo saturado.
Si hablamos de la transparencia de los clusters,nos topamos con 2

tipos:
Por una parte, los clusters no transparentes requieren una

programación paralela explícita y el conocimiento de la topología de la red
del cluster por adelantado(Beowulf) y/o la utilización de librerías para el
paso de mensajes entre tareas,que pueden estar ( PVM MPI)
Dentro de los clusters no transparentes destaca el proyecto Beowulf.

Se trata de una arquitectura multicomputador utilizada para procesamiento
paralelo que opera sobre un cluster, cuya jerarquía se basa en un nodo
servidor y uno o más nodos cliente en red. Este sistema se apoya en un
sistema distribuido y utiliza mecanismos de paso de mensajes.
También cabe destacar aquí las librerías para el paso de mensajes en

programación paralela como son las MPI.
Por otra parte, en los clusters transparentes el programador no

necesita saber la topología de la red, ni necesita utilizar técnicas de
programación paralela explícita, ya que ni siquiera necesita saber que su
programa va a funcionar en un cluster. Simplemente con adoptar la
metodología de programación en multiprocesador es suficiente.
Un ejemplo de clusters transparentes son Mosix y OpenMosix.

Mosix es un cluster SSI a nivel de sistema transparente. Se utiliza
principalmente para el aumento de procesamiento del sistema y permite la
utilización de antiguos programas hechos para monoprocesadores en un
cluster. El principal inconveniente de Mosix es que hace 2 años que el
desarrollo del mismo ha disminuido considerablemente. Además, desde
hace 2 años se ha convertido en un proyecto de código cerrado por lo que
no se pueden hacer modificaciones del mismo.
¿Qué es el procesamiento paralelo?
Por procesamiento paralelo se entiende la capacidad de utilizar varios

procesadores para ejecutar diferentes partes del mismo programa
simultáneamente. El objetivo principal del paralelismo es reducir el número
de ciclos de ejecución de un programa en relación al número de
procesadores que existen en el sistema, es decir, "divide y vencerás". En
esta idea es en la que se apoyan los clusters de alto rendimiento para lograr
su cometido.
¿Qué problemas se pueden resolver mediante paralelización?
Los programas convencionales no cuentan con ninguna manera de

paralelizar su código. La mayoría de los programas son pensados y
implementados de manera secuencial. Aun así, existen muchos campos
donde el desarrollo de programas que hagan uso de una manera u otra de
paralelismo está creciendo cada vez más. Entre estos campos se
encuentran:
● Granjas de compilación
● Granjas de renderización
● Procesos matemáticos
➢ Multiplicación de matrices
➢ Suma de vectores por componentes
➢ Multiplicación de matrices o vectores por escalares o funciones
escalares.
➢ Integrales definidas (creando intervalos más pequeños como
elementos de proceso)
● Compresión
● Aplicación a nuevos paradigmas inherentemente paralelos
➢ Redes neuronales
➢ Algoritmos genéticos
¿Qué es un sistema distribuido?
Un sistema distribuido es un conjunto de ordenadores o procesadores

independientes (nodos) que de cara al usuario funcionan como uno solo.
Está formado por varios componentes que cooperan estrechamente para
dar un servicio único.
¿Qué es un sistema operativo distribuido?
Un sistema operativo distribuido es el encargado de cumplir lo

anterior. Hay un particionado y cooperación entre todos los componentes,
ninguno sobrevive solo, el propio kernel está distribuido por las máquinas. El
hardware no da ninguna facilidad, es el software el que determina que un
sistema sea distribuido o no. El usuario no sabe dónde se están ejecutando
los procesos ni dónde están los recursos.
Llevar a la práctica la idea de un kernel global distribuido es muy
difícil, pues podría haber inconsistencias de datos en el kernel, además se
necesita al menos el kernel mínimo para enviar y recibir información y un
mecanismo robusto de comunicación y eficiente para evitar latencias
demasiado elevadas. Lo que se han desarrollado hasta ahora son los
llamados sistemas operativos en red. En estos sistemas cada máquina tiene
su propio kernel. Los sistemas están conectados por una red y se puede
hacer login remoto en ellos, en todo momento el usuario sabe donde se
encuentran todos los recursos (ficheros, procesos, etc.). No es un sistema
distribuido,pero actualmente se está caminando desde los sistemas
operativos en red a los sistemas distribuidos. Aunque aún no se han
cumplido los objetivos de un sistema distribuido completamente tenemos ya
algunos avances.
Existen grandes avances en sistemas de ficheros para conseguir que

exista un solo directorio raíz al igual que la existencia de una ubicación
automática por parte del sistema de los ficheros. Se puede implementar un
balanceo de la capacidad y redundancia en los datos para minimizar el
impacto de posibles caídas de nodos.
¿Por qué elegimos GNU/Linux para nuestro cluster?
La principal razón es su licencia GPL que permite la libre difusión,

copia y modificación del código fuente de los programas liberados bajo este
tipo de licencia. También porque se evita cualquier tipo de problema con las
patentes ya que la distribución elegida para el proyecto (Debian) sólo
incorpora programas compatibles con licencias de software libre.
También cabe destacar el enorme esfuerzo que está realizando la

comunidad Linux mundial en la difusión de documentación, ya sea a nivel
de HOWTO's, F.A.Q (Frecuently Asked Questions), manuales, tutoriales paso
a paso para principiantes o textos especializados para auténticos gurús de
la materia. La comunidad linux también ha visto en el clustering una de las
utilidades a sus máquinas y ha desarrollado numerosos proyectos para
enfocar al sistema operativo por los caminos de la supercomputación. Los
proyectos más relevantes en el campo del clustering de alto rendimiento
son: Mosix, OpenMosix y Beowulf.
¿Qué es OpenMosix?
OpenMosix es un parche para el Kernel de Linux que le dota de la

capacidad de trabajar como nodo, es decir, como máquina que forma parte
del cluster. Su misión es convertir una red de ordenadores en un cluster.
El algoritmo interno de balanceo de carga se ocupa de migrar

automáticamente y de forma transparente al usuario los procesos entre los
demás nodos del cluster, lo que proporciona una compartición óptima de la
carga entre los nodos. Esta migración se realiza de acuerdo a la velocidad
de CPU de cada nodo, a su carga de procesos actual y a la conexión de red
que lo una a los demás nodos, ya que aunque todos deben utilizar el
protocolo TCP/IP para comunicarse entre ellos, no todos tienen que estar
conectados en la misma subred, ni utilizar los mismos medios físicos de
unión(ethernet, PPP,etc...).
Por supuesto, el administrador del cluster puede realizar la migración

de procesos de forma manual gracias a las herramientas que de software
que acompañas al cluster (Userland tools o Userspace tools). Asimismo, los
nodos pueden añadirse o quitarse de la red sin que los procesos en
ejecución se vean afectados.
Debido a que OpenMosix forma parte del kernel, ya que se añade al

código fuente de éste antes de compilarlo, es totalmente compatible con
Linux, sus programas y sus ficheros. No es posible distinguir entre una
máquina normal y corriente ejecutando linux y una máquina utilizando linux
como nodo de un cluster OpenMosix. El sistema de migración de procesos
hace trabajar al conjunto de nodos como un enorme sistema de
procesadores (o multiprocesadores en el caso de que se trate de
procesadores dual o quad en cada máquina).
OpenMosix utiliza un sistema de ficheros llamado oMFS (OpenMosix

File System) que, al contrario que el sistema de ficheros NFS, proporciona
cache, "time stamp" y consistencia de enlace.
¿Por qué hemos elegido OpenMosix?
Hemos elegido de entre las posibles opciones OpenMosix debido a que

corre en GNU/LINUX , es un proyecto con licencia GPL y es uno de los más
desarrollados en la actualidad, además de ser el que cuenta con mayor
documentación en internet.
Originalmente deriva del proyecto MOSIX. Debido a las diferencias de

opiniones entre los desarrolladores del proyecto a la hora de liberar el
código bajo una licencia no libre, los que optaron por liberarlo bajo licencia
GPL se separaron del proyecto original para continuar un desarrollo paralelo,
dando lugar a OpenMosix.
Numerosas mejoras fueron añadidas al proyecto, como su

acomodación a la estructura de Linux, un código y un algoritmo de
migración de procesos más limpio, un método de balanceo de carga más
eficiente, menores latencias en el kernel, soporte para más arquitecturas
(incluidas algunas de 64 bits) y, sobre todo, muchísima documentación.
¿Cuáles son las desventajas de OpenMosix?
Entre sus desventajas más notables se encuentran:
• Es dependiente del kernel y, por tanto, de la versión de éste que se

esté utilizando.
• No migra procesos que utilicen memoria compartida
• No migra procesos que utilicen múltiples “threads”
• No migra procesos únicos, como son la mayoría de los programas

que utilizamos diariamente
¿Se puede solucionar el problema de la memoria compartida?
Sí,para ello existe Migshm. Migshm es un parche para hacer que

funciones la memoria compartida de forma distribuida(DSM - Distributed
Shared Memory). Con ello se consigue que puedan migrar los procesos que
utilicen memoria compartida.
Para conseguirlo se utilizan las llamadas al sistema: shmget(), shmat

(), shmdt() y shmctl(). Los threads creados a partir de la llamada al sistema
clone() también pueden ser migrados aplicando este parche.
Hemos decidido no aplicar este parche porque no existe una versión

que corresponda con la versión de OpenMosix que hemos utilizado y porque
está en una fase muy experimental (alpha), por lo que el rendimiento total
del cluster puede verse perjudicado y los resultados de los benchmarks y
pruebas pueden verse alterados.
¿Cuál es el objetivo de este proyecto?
Nuestro principal objetivo es comprobar si se puede ahorrar tiempo en

la ejecución de programas al reutilizar en casa los ordenadores viejos
formando un cluster de alto rendimiento. Para ello hemos tenido en cuenta
que el ordenador respecto al que se hacen las comparaciones es el más
potente, ya que sería el que se utilizaría en solitario si no existiera el
cluster.
2. CONFIGURACIÓN
2.1 Hardware
2.1.1 Nodos
En esta sección vamos a describir cada uno de los nodos

centrándonos en sus características fundamentales: Velocidad de
procesador, memoria, tarjeta de red…
Cada uno de los nodos ha sido bautizado con un nombre dentro del
cluster, los integrantes serían Shadowland, Asimov y salon.
Para conseguir información útil en cuando al hardware de cada equipo

miramos el archivo /proc/cpuinfo obteniendo las siguiente propiedades:
NODO1: Llamado Shadowland.
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model :8
model name: AMD Athlon(tm) XP 2000+
stepping :0
cpu MHz : 1679.042
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception: yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext
3dnowext 3dnow
bogomips : 3348.88
Como podemos ver se trata de un AMD Athlon XP 2000+ a 1679 MHz,

el tamaño de la memoria cache es de 256 KB, también averiguamos el
número de bogomips de este ordenador que es de 3348.88.
Además de estos datos, que son los que consideramos más

importantes para describir la capacidad de cómputo de nuestra CPU, vamos
a describir otros valores para tener una visión más concreta de los equipos
que forman nuestro cluster:
Dispone de 256Mb de memoria RAM, con tecnología DDR a 333MHz,
80 Gb de disco duro distribuido en dos discos duros de 40 Gb, la tarjeta de
red que tiene instalada es una Tarjeta de red PCI Fast Ethernet 10/100MB
con chipset Realtek. Los tres ordenadores disponen del mismo modelo de
tarjeta, para permitir que este modelo concreto funcione bajo nuestro
sistema operativo al recompilar el kernel activamos dentro de la sección
Network Device Support ->Ethernet 10/100 -> Realteck RTL-8139 PCI Fast
Ethernet Adapter Support.
NODO 2: Llamado Asimov.
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model :4
model name: AMD Athlon(tm) Processor
stepping :2
cpu MHz : 1212.223
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception: yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext
3dnow
bogomips : 2392.06
En este caso nos encontramos con un AMD Athlon K7 Thunderbird a

1212 MHz, el tamaño de la memoria cache es de 256 KB, también
averiguamos el número de bogomips de este ordenador que es de 2392.06.
Dispone de 128Mb de memoria RAM, con tecnología SDR a 133MHz,

25 Gb de disco duro distribuido en dos discos duros: uno de ellos de 20 Gb y
otro de 5 Gb, la tarjeta de red que tiene instalada es una Tarjeta red PCI
Fast Ethernet 10/100MB con chipset Realtek.
NODO 3: Llamado salon.
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model :7
model name: Pentium III (Katmai)
stepping :3
cpu MHz : 501.167
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception: yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips : 999.42
En este caso nos encontramos con un procesador que utiliza la

tecnología Intel Pentium a 500 MHz, el tamaño de la memoria cache es de
512 KB. También averiguamos el número de bogomips de este ordenador
que es de 999.42.
Dispone de 320Mb de memoria RAM, con tecnología SDR a 133MHz,

10 Gb de disco, la tarjeta de red que tiene instalada es una Tarjeta red PCI
Fast Ethernet 10/100MB con chipset Realtek.
En la información anterior hay un campo que nos llama la atención, se

trata de los bogomips. Lo más usual sería medir la potencia de un
computador mediante los MIPS. Este es el momento de explicar ambos
conceptos.
MIPS: es la abreviatura de “Millions of Instructions Per Second o

Millones de Instrucciones Por Segundo''. Es una medida de la velocidad de
ejecución de un programa. Como la mayoría de tales medidas,
frecuentemente se abusa de ella en vez de usarse correctamente (es difícil
comparar con justicia MIPS para diferentes tipos de ordenadores).
BogoMIPS: son una invención de Linus Torvalds. El núcleo necesita

un bucle de temporización (el tiempo es demasiado corto y/o necesita ser
demasiado exacto para poder emplear un método de espera no basado en
bucles de retardo), que tiene que ser calibrado con la velocidad de
procesador de la máquina. Por lo tanto, el núcleo mide durante la secuencia
de arranque cómo de rápido se ejecuta en el ordenador un determinado tipo
de bucle de retardo denominado “BOGO”. Por consiguiente, el valor de los
BogoMIPS da una cierta indicación acerca de la velocidad del procesador,
pero de forma escasamente científica como para ser utilizado seriamente en
cuanto a comparación de rendimiento de máquinas distintas.
Este bucle de retardo se ejecuta en el arranque para depurar y

comprobar las caches y se encuentra definido en /usr/src/linux-
openmosix/init/main.c. La variable correspondiente del núcleo loops_per_sec
se usa en varios controladores de dispositivo en las secciones net, scsi y
char. Las verdaderas funciones de retardo están en ensamblador, y por lo
tanto cada plataforma tiene su propia función en include/asm/delay.h
Una guía muy aproximada sobre los BogoMIPS podría ser:
Sistema BogoMIPS Comparación
Intel 8088 frecuencia_reloj * (0.004 ± 0.001) 0.02

Intel/AMD 386SX frecuencia_reloj * (0.14 ± 0.01) 0.8
Intel/AMD 386DX frecuencia_reloj * (0.18 ± 0.01) 1
Motorola 68030 frecuencia_reloj * (0.25 ± 0.005) 1.4
Cyrix/IBM 486 frecuencia_reloj * (0.34 ± 0.065) 1.8
Intel Pentium frecuencia_reloj * (0.40 ± 0.035) 2.2
Intel 486/AMD 5x86 frecuencia_reloj * (0.50 ± 0.01) 2.8
Mips R4000/R4400 frecuencia_reloj * (0.50 ± 0.015) 2.3
Nexgen Nx586 frecuencia_reloj * (0.75 ± 0.010) 4.2
PowerPC 601 frecuencia_reloj * (0.84 ± 0.015) 4.7
Alpha (todos) frecuencia_reloj * (0.99 ± 0.005) 5.5
Intel Pentium Pro frecuencia_reloj * (0.99 ± 0.005) 5.5
Cyrix 5x86/6x86 frecuencia_reloj * (1.00 ± 0.005) 5.6
Mips R4600 frecuencia_reloj * (1.00) 5.6
AMD 5k86 frecuencia_reloj * (2.00 ± 0.010) 11.1
Motorola 68060 frecuencia_reloj * (2.01) 11.2
El bucle de cálculo de los BogoMIPS no hace uso de paralelismo en

procesadores por lo que no podemos utilizarlo para conseguir los BogoMIPS
totales de nuestro cluster, tan solo podríamos aproximarlos mediante la
suma de los BogoMIPS parciales de los tres nodos, obteniendo 6740.36.
2.1.2 Router
Se trata de un router 3Com ADSL 11g Wireless Router, las

características más importantes de este aparato es que pueden conectar a
una red local cuatro ordenadores mediante un cable de red junto con otros
clientes wireless dándoles una conexión a internet.
El uso que nosotros hemos dado a este router es de hub, es decir,

concentrador. Un hub es un dispositivo hardware que integra distintas
clases de cables, arquitecturas o tipos de redes de área local. Utilizamos
este dispositivo como conexión central de la red que tiene configuración en
estrella.
2.1.3 Topología de red y cableado
Existen tres tipologías de red, la primera de ellas

sería una red en anillo, la segunda sería la topología de
bus o árbol y la tercera sería la topología en estrella.
La siguiente imagen es una aclaración para
comprender el tipo de esquema utilizado en esta red.
El router (o nodo central) tiene la funcionalidad de transmitir por

todas las salidas cualquier información que le llegue por la entrada
(actuando a modo de repetidor). Le hemos desactivado la conexión Wireless
debido a que ninguno de nuestros nodos se conecta mediante dicha
tecnología.
Otro componente importante de la red es el cableado utilizado para

comunicar a los nodos con el hub central. Dependiendo del tipo de cable
utilizado podremos transmitir a distintas velocidades. Tendremos que tener
en cuenta a la hora de elegirlo: El área que va a ocupar nuestra red, la
velocidad de transmisión deseada, el número de nodos que vamos a
utilizar...
Nuestra elección se ha decantado por cables de red de par trenzado

UTP de categoría 5, también denominados cable de calidad de datos,
soporta una velocidad de transmisión de hasta 100Mbps en distancias
limitadas de hasta 100 metros.
Este tipo de cable es el más económico, ofrece mayores limitaciones

de velocidad de transmisión y alcance que otras soluciones como podrían
ser la fibra óptica o el cable coaxial. Existen dos modelos dentro del cable
de par trenzado:
UTP: Par trenzado sin apantallar, se trata del modelo más extendido
debido a su menor coste. Hay distintas calidades dentro de este modelo que
van de la 1 a la 5 siendo la calidad 5 la mejor de todas ellas.
STP: Par trenzado apantallado, este modelo es el de mayor calidad

debido a que está recubierto por una malla metálica que lo aisla aún más de
las interferencias de los pares cercanos.
2.2 Versiones del software:
Es muy importante instalar las mismas versiones del software en cada

uno de los ordenadores para evitar problemas de incompatibilidad y para
que el trabajo del cluster sea óptimo consiguiendo mejorar su rendimiento.
2.2.1 Distribución de linux
Para trabajar con el cluster hemos instalado la misma distribución de

linux en los tres equipos. Nuestra elección ha recaído en una Debian Sid,
que se trata de la versión inestable pero la más actualizada.
Actualizamos la lista de archivos simultáneamente en los tres nodos a

día de 15 de febrero de 2004 a las 21:00. Conseguimos tener las mismas
versiones de todos los paquetes instalados para evitar problemas de
incompatibilidades y para conseguir unos resultados mas fiables a la hora
de realizar las pruebas y mediciones posteriores.
2.2.2 OpenMosix
Una de las fases de la instalación del cluster consiste en el parcheado

del kernel de linux, es decir, aplicar una serie de cambios en la
configuración original del núcleo del sistema para que nos permita utilizar
las características computacionales del cluster de alto rendimiento.
Parar poder llevar a cabo el proceso de parcheado del kernel debemos

descargar el fichero de texto que contiene los cambios con respecto al
kernel estándar, es decir las nuevas funcionalidades que vamos a agregar al
sistema.
Este archivo se encuentra en la página web del proyecto OpenMosix

(www.openmosix.org), en esta página podemos encontrar todo lo referente
al proyecto junto con los programas y archivos necesarios para su uso.
La última versión del proyecto se encuentra en el kernel 2.4.22 y su

parche fue publicado el día 30 de noviembre de 2003. Hemos elegido esta
versión por ser la más actual y haber corregido posibles errores de
versiones anteriores. En base a esta elección tendremos que optar por una
versión del kernel.
2.2.3Versión del kernel
El kernel de linux, es decir el núcleo del sistema, es la parte mas

importante del sistema operativo pues se encarga de llevar el control de la
memoria, los procesos y el hardware del sistema. Existen distintas versiones
del kernel debido a las nuevas mejoras y nuevas prestaciones que se van
añadiendo periódicamente.
Al tratarse de un sistema operativo libre, las actualizaciones son
constantes y cada actualización lleva consigo un cambio en el nombre del
núcleo. La última versión estable fue publicada a finales de diciembre de
2003 y se trata de la rama 2.6, sin embargo no vamos a trabajar con ella
debido a que estamos sujetos a la utilización de la versión de la que hemos
elegido el parche.
Por lo tanto la versión del núcleo de linux con la que trabajamos se

trata de la 2.4.22.
2.2.4 Userspace Tools
También conocidas como Userland Tools, se trata de una colección de

herramientas administrativas cuyo cometido es examinar y controlar cada
nodo. La versión utilizada de esta herramienta es la 0.3.5.
2.2.5 Openmosixview
Se trata de una interfaz gráfica de usuario que nos va a permitir

monitorizar, controlar y dirigir cada uno de los nodos. Se trata de una
herramienta que tan sólo es necesario en uno de los equipos, sin embargo,
para llevar un control correcto de cada uno de los nodos hemos optado por
instalarlo en los tres equipos. La versión instalada de esta aplicación es la
1.5.
2.2.6Librerías MPI
MPI responde a las siglas de Message Passing Interface (Interfaz de

Paso de Mensajes) y se utiliza en el desarrollo de programas paralelos. Se
trata de un estándar desarrollado para permitirnos escribir aplicaciones de
paso de mensajes portables. Esta librería nos aporta funciones para cambiar
mensajes y también otras muchas actividades. Al tratarse de una librería
tenemos muchas implementaciones posibles.
Dado que utilizamos Debian para instalar estas librerías utilizamos el

programa apt-get, el nombre de estas librerías para Debian es mpich:
$ apt-get install mpich
Ahora ya estamos preparados para compilar programas paralelos y

ejecutar instrucciones paralelas. Para compilar programas manualmente
utilizamos una de las siguientes ordenes:
$ mpicc -o exec [options] sources.c

$ mpif77 -o exec [options] sources.f
Sin embargo, en los benchmark que hemos utilizado todas estas

opciones venían reunidas en un Makefile en el que tuvimos que modificar la
ruta del compilador ya que la ruta por defecto no coincidía con la que
nosotros teníamos. Para averiguar la ruta utilizamos el comando whereis del
siguiente modo:
$ whereis mpif77
mpif77: /usr/bin/mpif77
$ whereis mpicc
mpicc: /usr/bin/mpicc
$ whereis mpich
mpich: /usr/lib/mpich
Con lo visto hasta ahora ya podemos crear nuestras aplicaciones

paralelas compiladas con estas librerías. Ahora veremos como podemos
ejecutar estas aplicaciones para poder aprovechar las funcionalidades que
hemos añadido al hacerlas paralelas. Tenemos que utilizar el comando
mpirun, que tiene las siguientes opciones:
$ mpirun -np <num de procs> comando
Al ejecutar mpirun hay dos opciones que se ejecutan por defecto:
-nger: Deshabilita el GER (Guaranteed Envelope Resources).
-w: Espera a que todas las aplicaciones acaben antes de salir del
programa mpirun.
El único argumento que hemos utilizado a parte de los dos por defecto
es el siguiente:
-np: con este proceso le indicamos cuantos subprocesos debe crear

del comando que ha de ejecutar. Llegados a este punto entendemos la
importancia de la compilación con las librerías mpich, ya que en la mayor
parte de los casos necesitamos especificar en tiempo de compilación el
número de procesos en los que vamos a dividir el problema principal.
2.3 Opciones del compilación del kernel
Una vez parcheado, nos disponemos a configurar las opciones que va

a tener nuestro cluster, para ello nos dirigimos al directorio /usr/src/linux-
openmosix.
Ejecutamos la orden:
$ make xconfig
Nos encontramos con una ventana en la que aparecen por secciones

todas las opciones de nuestro sistema operativo. El primer botón de todos
es exactamente el que contiene todas las opciones de nuestro cluster. Al
hacer click en él nos encontramos con la siguiente pantalla.
En ella hemos marcado:
openMosix process migration support: Esta es la opción que

permite activar el soporte para la migración de procesos, la hemos marcado
porque sin ella no funcionaría el cluster. Incluye la migración forzada por el
administrador y la migración transparente al usuario.
Support clusters with a complex network topology: Con esta

opción activada permitimos a nuestro cluster trabajar en redes en las que
los paquetes deban viajar a través de routers. Nuestra topología de red está
centralizada con un router pero al no conectar redes distintas tan solo lo
utilizamos como un hub, por lo tanto desactivamos esta opción para
conseguir mejoras en la eficiencia, mejorando el rendimiento de nuestro
cluster.
Maximum network-topology complexity to support (2-10): Al

tener la opción anterior desactivada ésta se nos muestra oculta. Si se diera
el caso de una topología de red compleja en esta opción deberíamos marcar
el nivel de complejidad de los ordenadores más lejanos del cluster (se trata
del número de routers que hay entre ellos más uno).
Stricter security on openMosix ports: Esta opción permite un

chequeo sobre los paquetes enviados y recibidos por los nodos del cluster.
Para conseguir un rendimiento más alto hemos desactivado esta opción ya
que todas las comprobación consumirían recursos al sistema.
Level of process-identity disclosure (0-3): Este parámetro indica

la información que va a tener el nodo de ejecución real de la tarea remota
que está ejecutando. Hemos de distinguir entre el nodo raíz (nodo que
ejecutó la tarea y que tiene toda la información) y el resto de los nodos (que
será donde reciban una información parcial). Hemos decidido dejar el nivel
de identidad de procesos en 1 : nivel en el que tan solo enviamos el PID,
identificador de proceso. Nos hemos decantado por esta opción debido a
que queremos enviar la mínima cantidad de datos posibles a través de la
red, evitando el tiempo innecesario de transferencia de datos redundantes.
Create the kernel with a -openmosix extension: Esta opción

venía activada por defecto y su utilidad se uso se justifica por la siguiente
razón. Si tenemos la misma versión del kernel parcheada con el OpenMosix
y sin parchear, nos guarda y enlaza los módulos en directorios distintos para
evitar incompatibilidades.
openMosix File-System: Si activamos esta opción podremos usar el

sistema de ficheros oMFS. Nuestro cluster ha sido diseñado para utilizar
dicho sistema de ficheros, por lo tanto activaremos esta opción.
Poll/Select exceptions on pipes: Esta opción es una mera

adaptación para soportar procesos no estandarizados por Posix ya que en
Unix, un proceso que escriba en un pipe, en principio, no es interrumpido si
otro proceso abre el mismo pipe para leer o ya lo tenía abierto y lo cierra.
Mientras que en Posix, un proceso escritor en un pipe puede recibir una
excepción cuando otro proceso abra un pipe para leer dicho pipe, y puede
recibir también una excepción si el pipe se queda sin lectores.
Disable OOM Killer (NEW): No hemos marcado esta opción pues el

uso del OOM Killer ya es gestionada por otras partes del kernell que no
tienen que ver con el cluster.
En este momento ya tenemos las opciones de nuestro cluster

marcadas para poder migrar y controlar los procesos una vez hayamos
acabo el proceso de compilación. A continuación debemos completar la
selección de opciones para el resto del kernel. Dado que el objetivo de
montar el cluster es monitorizar todas las ejecuciones de algoritmos y
pasarle múltiples benchmarks hemos decidido compilar un kernel muy
básico para no añadir errores a las medidas que realicemos. Por supuesto
los tres equipos tienen la misma configuración a excepción de la
arquitectura del ordenador, debido a que uno de los nodos tiene un
procesador de Intel y los otros dos trabajan con procesadores AMD.
Tan solo mantenemos activadas las opciones del soporte de CD-Rom,

el Floppy, los drivers de red, el sistema de ficheros ext3, soporte PCI para
las tarjetas de red, manteniendo desactivadas opciones superfluas como
pueden ser el soporte para la tarjeta de sonido, USB, SCSI, bluetooh, etc.
Una vez configuradas nuestras opciones tecleamos la siguiente orden

en la línea de comandos de cada uno de los ordenadores:
$ make dep && make clean && make bzImage
Llegados a este punto movemos el archivo con el kernel ya compilado
hasta la carpeta /boot y modificamos el gestor de arranque de los
ordenadores para permitir que al reiniciar nuestros sistemas podamos
iniciar nuestros nodos con la configuración del cluster activada.
2.4 Configuración de la red local
Para que los procesos puedan migrar necesitan un soporte TCP/IP de

transmisión de datos, para permitir dicha comunicación tenemos que
configurar una red local que permita una comunicación ininterrumpida entre
nuestros nodos. Para ello hemos de modificar los siguientes archivos:
/etc/hosts: En este archivo deben aparecer las IPs de todos los

ordenadores pertenecientes a nuestra red local junto con sus nombres para
poder identificarlos. El archivo /etc/hosts de nuestra red tendría el siguiente
contenido:
127.0.0.1 localhost
192.168.2.2 nodo2
192.168.2.10 nodo1
192.168.2.20 nodo3
192.168.2.1 router
/etc/network/interfaces: En este archivo guardamos la información

sobre la interfaz de red que utilizamos, en nuestro caso los tres ordenadores
están configurados con eth0. El aspecto del archivo /etc/network/interfaces
es el siguiente:
iface eth0 inet static

address 192.168.2.X
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
La única diferencia entre este archivo de un nodo y cualquiera de los

otros dos nodos es la “X”, se trata del último campo de IP, que sirve para
distinguir a un ordenador de otro dentro de la misma subred. Esta variable
tiene el siguiente valor en cada uno de los nodos:
X = 10 en el nodo 1.
X = 2 en el nodo 2.
X = 20 en el nodo 3.
La elección de estas ips podría haber sido distinta mientras que se

declarara en estos ficheros. La ip del router venía por defecto para actuar
como puerta de enlace de la red.
2.4.1 Seguridad en el cluster
Anteriormente hemos comentado que en las opciones del kernel

tenemos desactivada la seguridad. Al tenerla desactivada estamos
expuestos a ciertas vulnerabilidades que permitirían colgar uno o varios de
los nodos mediante el envío de paquetes mal formados. Según tenemos la
red configurada hasta el momento estaríamos expuestos a estos ataques.
Para solucionarlo hemos creado reglas con los TCPWrappers, modificando
dos archivos.
El primero es el /etc/hosts.allow cuyo contenido tiene que ser el

siguiente:
192.168.2.2
192.168.2.10
192.168.2.20
El segundo archivo que debemos modificar es el /etc/hosts.deny en el

que aparecerá tan solo una línea:
ALL PARANOID
Al haber realizado estos cambios hemos conseguido que ningún

ordenador con una IP distinta a las que hemos definido anteriormente pueda
utilizar nuestra red, sus conexiones no serán admitidas ni ejecutadas. De
este modo solucionamos el problema de la seguridad en la red. Otra
característica de la red que hemos montado es que cuando está trabajando
el cluster desactivamos la conexión a internet para impedir que disminuya
el rendimiento del router y las colisiones dentro de la red.
2.4.2 Configuración del router
Una vez llegados a este punto ya tenemos montada y configurada la

red en cada uno de los nodos, sin embargo no hemos de olvidar que
tenemos que modificar también la configuración del router para que
nuestros ordenadores se puedan conectar a él, nos referimos al sistema de
filtrado de IPs y direcciones MAC que internamente controla el router. Para
ello hemos de conectarnos desde nuestro navegador a la IP del router y
navegar por la página de configuración hasta llegar al filtrado de IPs donde
añadiremos las de nuestros nodos. Hemos añadido del mismo modo las
direcciones MAC de las tres tarjetas de red para posibilitar el tráfico de
datos.
2.4.3 Uso de la red por parte de openMosix
La importancia de la red es grandísima debido a que es el modo que

utiliza el cluster para enviarse las tareas que deben realizar los nodos
remotos y para devolver los resultados de esas operaciones. Tenemos que
tener en cuenta que en clusters con un gran número de nodos la congestión
de la red y las colisiones son problemas que realmente pueden restar gran
cantidad de eficiencia al cluster. En nuestro caso, al tratarse tan sólo de tres
nodos con un hub que gestiona el tráfico de la red, es presumible que no
perderemos eficiencia debido a estos problemas.
La red sobre la que hemos montado el cluster es una red Ethernet que
se caracteriza por tener una velocidad teórica de transmisión de 10Mb/seg.
El protocolo Ethernet está especificado en el estándar IEEE 802.3. Es half
duplex, significa que tenemos un medio físico (cable de red) que se
comparte como soporte de la red tanto para el envío como para la recepción
de datos. El acceso a la red se gestiona mediante el protocolo CSMA/CD.
Básicamente este protocolo se encarga de escuchar la red antes de enviar
los datos para comprobar si ya hay paquetes en la red. Con este
procedimiento evitamos las colisiones en la red y mejoramos su
rendimiento.
Este es el momento de explicar cuáles son los protocolos de

transporte que utiliza openMosix. Principalmente se trata de los protocolos
TCP (Transfer Control Protocol) y UDP (User Datagram Protocol).
El protocolo que utiliza openMosix es UDP. Es el protocolo de

transporte no fiable estándar en Internet. Es un protocolo no orientado a
conexión (de ahí su nombre, se envían datagramas) y no es fiable. La
cabecera que incluye al mensaje es la mínima para poder distinguir a que
puerto se dirige y un pequeño checksum de la cabecera. Es usado para las
típicas aplicaciones de los servicios no conectivos. Se usan para enviar
pocos datos (se consigue más rendimiento puesto que no se necesita gastar
tiempo en conectar y desconectar) y en multidifusión.
UDP, al contrario de TCP, no puede realizar fragmentaciones de los

mensajes puesto que no tiene campos para ello. Por tanto es la aplicación
quien debe dividir los mensajes como crea oportuno. Cuando uno de los
fragmentos de un mensaje UDP se pierde se tendría que retransmitir. En el
caso de UDP será la aplicación la encargada, gracias a unos temporizadores,
de retransmitirlo. En el caso de TCP, es este protocolo el que detecta y
soluciona el problema. El protocolo de internet (IP) si no puede recomponer
un datagrama, lo tira, no tratando el problema y dejando la solución a capas
superiores.
Frente a estas características, el protocolo TCP es un protocolo fiable

de conexión. TCP recibe mensajes de cualquier tamaño y los divide en
trozos de un máximo de 64Kb y se envía cada uno de estos trozos como un
mensaje TCP separado. También es misión de TCP ordenar todos los
segmentos que hayan llegado separados y ensamblarlos para obtener el
mensaje inicial. Tiene la ventaja de que las aplicaciones no tienen que
preocuparse de tratar los errores de la comunicación puesto que para la
aplicación el canal de comunicación es perfecto y siempre llega la
información integra.
El demonio de migrado de aplicaciones escucha constantemente en la
red utilizando el puerto 4660 que es de tipo TCP, también se encuentra
abierto el puerto 5428, este puerto es del tipo UDP y es utilizado por un
demonio de información de migrado. Eventualmente utiliza otro puerto, el
723 que es de tipo TCP. La siguiente información es la que obtenemos al
hacer un netstat:
$ netstat -tupan
Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:723 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:4660 0.0.0.0:* LISTEN
udp 0 1020 0.0.0.0:5428 0.0.0.0:*
2.5 Openmosix.map
Antes de arrancar el cluster debemos modificar este archivo de

configuración cuyo objetivo es hacer un mapeado del cluster, es decir,
guardar información sobre el número de nodos y la IP de cada uno de ellos
dentro de la red local. Esto se encuentra en /etc/openmosix.map. Debe
contener los siguientes parámetros y debe ser idéntico en cada uno de los
nodos:
MOSIX IP NUMBER OF NODES

1 192.168.2.10 1
2 192.168.2.2 1
3 192.168.2.20 1
El primer campo es el identificador de cada nodo, es decir, un nombre

único que nos servirá para diferenciarle del resto cuando hagamos la
monitorización del sistema. El segundo campo es donde se encuentra la
información sobre la IP que tiene asignada cada uno de los nodos mientras
que en el tercer campo nos encontramos con un número entero cuya
finalidad es contar el número de nodos consecutivos del cluster. Es más
sencillo de comprender con un ejemplo, si tuviéramos un hipotético archivo
con esta forma:
1 192.168.1.200 4
Significaría que hay cuatro nodos con ips consecutivas a partir de

192.168.1.200, es decir …201, …202, …203, …204.
En nuestro caso éste campo va a contener siempre el valor uno dado

que tan solo tenemos tres nodos y cada uno tiene una ip no consecutiva.
2.6 Openmosix.config
Antes de tocar la configuración de este archivo debemos haber

instalado las UserTools ya que éste es uno de los archivos que nos brinda
este paquete de software. Tenemos que crear un directorio dentro de /etc/
llamado openmosix que es donde situaremos el archivo openmosix.config.
Se trata de un archivo de configuración que será leído cada vez que se

arranque el cluster y en el que indicaremos las opciones concretas que
deseamos cumpla cada uno de los nodos. Se encuentra en la ruta descrita
anteriormente : /etc/openmosix/openmosix.config. Al editar este archivo nos
encontramos con todas las posibles opciones de ejecución del cluster
OpenMosix. Nosotros hemos dejado desactivadas las siguientes opciones:
Autodisc: Se trata de un de demonio que está escuchando la red para

comprobar si se han añadido nuevos nodos.
Autodiscif: Especificamos el interfaz ethernet en el que el demonio

anterior estará buscando los nuevos nodos.
Myomid: Permite poner un identificador al nodo.
Mosgates: Permite especificar el número de gateways que hay en

nuestro cluster.
Las siguientes opciones son las que hemos activado:
Nodespeed: especifica la velocidad de procesador de cada nodo,

escribimos las unidades de velocidad de cada nodo.Estas unidades se
explican posteriormente.
Migrate: hemos puesto como valor “yes” ya que de este modo

conseguimos cumplir la funcionalidad principal que es la migración de
aplicaciones entre los distintos ordenadores de nuestro cluster.
Block: El valor elegido es “no” ya que con esta opción permitimos que
no hay ningún tipo de bloqueo de entrada de los procesos en los nodos.
Mfs: Este valor lo hemos establecido a “yes” debido a que nosotros

hemos decidido planificar nuestro cluster con el sistema de ficheros Mfs que
explicaremos más adelante.
2.7 Scripts
Nuestro cluster se puede levantar a manualmente con la siguiente

orden ejecutándola en cada uno de los nodos con privilegios de root:
$ setpe –w –f /etc/openmosix.map
Ejecutando esta orden en cada uno de los nodos del cluster le
obligamos a hacer un mapeado del fichero /etc/openmosix.map
configurando cada nodo a lo largo del cluster.
Podemos apagar el nodos que se desee utilizando la siguiente orden

desde dicho nodo:
$ setpe –off
Sin embargo, dentro del paquete de las UserTools tenemos el script de

control del OpenMosix que nos permite iniciarlo, pararlo o reiniciarlo. Para
que este script (se trata de un archivo de texto llamado openmosix)
funcione hemos de copiarlo al directorio /etc/init.d/ y cambiarle los
permisos ejecutando la siguiente orden:
$ chmod 755 openmosix
Con esta orden le asignamos permiso de lectura, escritura y ejecución

al superusuario (root) pero también le asignamos permiso de lectura y
ejecución al resto de usuarios. El objetivo es que pueda ser utilizado por
cualquier usuario que esté trabajando con la máquina. De todos modos
nosotros siempre trabajamos con root para evitar problemas de negación de
permisos al ejecutar ciertas tareas.
En este momento podemos situarnos en el directorio /etc/init.d y

cambiar el estado del cluster tan solo ejecutando los siguientes comandos:
openmosix start: Inicia la interfaz openmosix del nodo.

openmosix stop: Para la ejecución de la interfaz openmosix.
openmosix restart: Reinicia los servicios del cluster.
Para permitir que se arranque la interfaz cuando se inicia el ordenador

creamos un enlace simbólico en el siguiente directorio: /etc/rc2.d/
$ ln –s /etc/init.d/openmosix /etc/rc2.d/S99openmosix
Le ponemos el número 99 para que se ejecute al final de todo el

proceso de arranque cuando ya tengamos todas los demás scripts de inicio
ejecutados.
En el nivel de arranque 2, el que hemos elegido para nuestros

sistemas, hemos borrado los enlaces simbólicos a aplicaciones que no
íbamos a necesitar para disminuir la carga de procesos residuales del
sistema, de este modo conseguimos ajustar más las medidas de
monitorización que realicemos. Dos de los enlaces que dejamos son el
correspondiente al arranque del OpenMosix detallado anteriormente y el
correspondiente al servidor de ssh ya que la comunicación entres los nodos
se basa en túneles ssh para algunas de las aplicaciones utilizadas. Este
apartado de ssh será explicado posteriormente con mayor profundidad.
Con motivo similar al anterior también hemos realizado cambios en el
fichero de configuración de arranque /etc/inittab. Mediante la siguiente línea
le decimos al sistema que tan solo arranque en el nivel dos:
id:2:default
Además tan sólo dejamos permitidos los niveles 0, 2,6. El nivel 0 es el

nivel del halt o apagado del sistema, el nivel 2 es el nivel en el que
queremos arrancar y el nivel 6 es el correspondiente al reboot o reiniciado
del sistema.
Igualmente comentamos las líneas del fichero en la que nos permitía

abrir múltiples consolas, dejando tan solo F1, F2 y F3; junto con la consola
F4 que el sistema reserva al modo gráfico.
El objetivo de estas configuraciones extras no es otro que el de

conseguir un sistema con la mínima carga de procesos posibles, es decir,
dejar nuestro sistema operativo con las opciones más básicas para dedicar
la máxima potencia de la CPU a realizar los procedimientos de cálculo y
demás algoritmos que ejecutaremos posteriormente en el cluster.
2.8 Sistemas de ficheros
Las particiones raíz de los tres nodos están formateadas con el

sistema de ficheros ext3. Se trata del sistema de fichero estándar de linux
mejorado con journaling, es decir, la evolución de ext2. Hemos elegido este
sistema de ficheros en lugar de otros posibles como ResizerFS, XFS o ext2
por las siguientes razones:
Journaling: Ext3 tiene la opción de journalig que se trata de un

sistema que periódicamente salva los archivos que están abiertos para
impedir pérdidas de información o corrupción de datos si se produce una
desconexión no esperada del ordenador, como por ejemplo si se cuelga el
sistema o se hay un apagón de luz. La elección de este sistema de ficheros
nos aporta la seguridad y robustez que buscamos, sin embargo dicha
seguridad conlleva una lacra: Tenemos un proceso que se está ejecutando
en segundo plano y que consume ciertos recursos en nuestras máquinas
que hemos considerado aceptable dada la fiabilidad que nos reporta.
Realizando un top en una línea de comando vemos que el proceso

llamado kjounald no consume recursos de CPU mientras está latente pero
que cada cinco minutos realiza el salvado de datos consumiendo un 0.3 %
de uso de CPU.
Velocidad: Este sistema de ficheros al tener una implementación

mejorada con respecto a su predecesor ext2, trata la lectura y escritura de
archivos de modo optimizado reduciendo tiempos de acceso a los mismos.
Hasta el momento tenemos nuestro sistema de ficheros montado en la
partición “/” de cada uno de los nodos. Al instalar el parche del openMosix
vimos la opción de su sistema de ficheros. Ha llegado el momento de
explicar lo que es y el porqué de su uso en este cluster.
oMfs es el sistema de archivos usado por los kernels parcheados con

openMosix. El funcionamiento básico de este sistema de ficheros consiste
en compartir un directorio en cada uno de los nodos en el que puedan leer y
escribir el resto de los nodos del cluster. Existe una optimización para este
sistema de ficheros llamada DFSA (Direct Filesystem Access, sistema de
ficheros de acceso directo). A partir de ahora explicaremos más a fondo en
qué consiste ambas funcionalidades.
El uso y administración del sistema de ficheros oMFS es muy similar al

NFS (Network File System) pero aportando las siguientes diferencias:
• Consistencia de cache.
• Consistencia de “Time stamp”.
• Consistencia de enlace.
El uso de oMFS está relacionado con el uso de DFSA. Hemos de

recordar que al compilar el kernel también activamos la opción DFSA, en
este momento toma sentido aquella elección. Combinando las prestaciones
de oMFS y DFSA permitimos a los procesos migrados hacer diversas
llamadas locales al sistema en los nodos remotos, sin estar obligado a
retornar al nodo de origen.
Una aclaración a la frase anterior sería que si migramos un proceso

desde el nodo 1 al nodo 2 y resulta que este proceso migrado necesita tener
acceso a los datos que se encuentran en el nodo 1, no es necesario que este
proceso retorne al nodo 1 sino que tiene acceso total a los datos
independientemente del nodo en el que se encuentre.
Utilizando la combinación de ambos sistemas de ficheros conseguimos

un ahorro de tiempo y recursos considerable, consiguiendo una optimización
en el tiempo de acceso a disco en nuestro cluster.
Llegados a este punto ya tenemos una base teórica sobre el uso del
sistema de ficheros en nuestro cluster. Ahora nos disponemos a explicar qué
pasos hemos dado para conseguir que nuestros nodos reconozcan el
espacio de disco compartido y permitir a los procesos migrados utilizar de
forma útil el nuevo espacio de disco destinado para ellos.
El primer paso consiste en la modificación del archivo /etc/fstab. Se

trata de un fichero del sistema en el que indicamos el sistema de archivos
de cada partición y la ruta en la que será montada y las opciones de
montaje de cada partición. En este archivo hemos de añadir una línea que
contenga la siguiente información:
mfs_mnt /mfs mfs dfsa=1 00
Ahora nos disponemos a crear dos directorios, uno de ellos será el
mismo para los tres nodos. El segundo tendrá un nombre distinto
dependiendo del nodo. Ambos colgarán del directorio raíz, el primero de
ellos se llamara mfs y el segundo se llamara de forma distinta dependiendo
del nodo,para posteriormente crear enlaces simbólicos desde el resto de los
nodos:
En el nodo 1: $ mkdir /work1

Dentro del directorio /mfs nos encontramos con un árbol de directorios

que contiene tres directorios sobre los que prestaremos especial atención.
Se llaman 1,2,3 respectivamente. Se trata de puntos de montaje con los que
enlazaremos los otros nodos y el propio nodo local.
Dentro del directorio /mfs tenemos:
/mfs/1: Punto de montaje de la partición “/” del nodo 1.

/mfs/here: Guarda los procesos que ejecuta el nodo local.
/mfs/home: El directorio home del nodo local.
/mfs/magic: Usado para crear archivos temporales.
/mfs/lastexec: Nodo en el cual el último proceso obtuvo con éxito
una llamada al sistema.
/mfs/selected: El nodo que se seleccionó o bien por nuestro proceso
o bien por alguno de sus antecesores.
Esta estructura es la misma en los tres nodos del cluster, la única

diferencia en la ruta a la que apuntan los enlaces simbólicos.
Basaremos la explicación sobre la utilidad de estos directorios en un

ejemplo que será mucho más ilustrativo que pura teoría.
Nos vamos a centrar exclusivamente en el nodo 1.En dicho nodo

creamos enlaces simbólicos a los directorios de trabajo /work2 y /work3 que
se encuentran respectivamente en los nodos 2 y 3 del siguiente modo:
$ ln –s /mfs/2/work2 /work2
$ ln –s /mfs/3/work3 /work3
En este momento tenemos en el directorio raíz una carpeta llamada

/work1 y dos enlaces simbólicos llamados /work2 y /work3. En el resto de los
nodos debemos realizar un proceso análogo adaptando según sea
conveniente el nombre y ruta de los enlaces simbólicos. El objetivo final de
estas operaciones es conseguir que cada nodo tenga localmente una
carpeta llamada /work + [ID de nodo] y dos enlaces simbólicos que apunten
a la ruta de esta misma carpeta en los otros nodos del cluster.
2.9 Detección automática de nodos
Si no sabemos el número de nodos que vamos a utilizar o vamos a

estar añadiendo y quitando nodos continuamente, compensa habilitar el
demonio de auto-detección de nodos: omdiscd.
Omdiscd se encarga de gestionar la adición y supresión de nodos

ahorrándonos la edición y mantención del archivo de configuración de
direcciones /etc/openmosix.map .Para ello envía paquetes multicast a todo
el rango de IPs de la red para notificar a los demás nodos que hemos
añadido uno nuevo, es decir, sólo tendremos que iniciar omdiscd en el nodo
que añadimos.
Para poder aprovecharnos de esta característica debemos indicarle a

omdiscd la interface de red que vamos a utilizar para mandar los paquetes
multicast, así como la dirección multicast del tipo de red que tengamos. En
nuestro caso la interface sería eth0 y la dirección de broadcast es
192.168.2.255
El omdiscd se puede ejecutar como demonio (opción por defecto) o

como proceso en el background (opción -n)
Después, mediante el comando showmap podemos ver como ha

quedado la configuración de la red en su estado actual:
$ showmap
My Node-Id: 0x0001
Base Node-Id Address Count
---------- ----------------------- --------
0x0001 192.168.2.10 1
0x0002 192.168.2.2 1
0x0003 192.168.2.20 1
Esta solución conlleva algunos problemas porque puede que algunas

tarjetas de red no vean el tráfico multicast de su interface. Esto se soluciona
poniendo dichas tarjetas en modo promiscuo:
$ ifconfig eth0 promisc
Esto pondría en modo promiscuo la tarjeta que escuche en el interface

de red eth0 que corresponde a la primera tarjeta Ethernet.
Nosotros no hemos utilizado el demonio de autodetección de nodos ya

que siempre vamos a tener 3 nodos fijos y, en el momento que queramos
eliminar alguno para realizar alguna prueba, desconectamos su interface de
red o su cable de red y rearrancamos el script de inicio de OpenMosix en los
demás nodos, ya que lo tenemos configurado de tal forma que comprueba
la existencia de todos los nodos del fichero /etc/openmosix.map al
ejecutarse.
La razón por la que no hemos utilizado el sistema de autodetección de
nodos es porque es mucho más seguro confiar la topología del cluster a un
fichero de configuración que a un demonio que puede fallar en un momento
determinado. Además los paquetes multicast empeoran (aunque sea
insignificantemente) el trafico de la red produciendo colisiones.
2.10EL ALGORITMO DE MIGRACIÓN
El migrado de procesos se realiza de forma automática, aunque

también pueden forzarse migraciones manuales mediante el comando
migrate. El algoritmo que lo controla tiene complejidad constante O(n),
siendo n el número de nodos del cluster.
El modelo de migración se conoce como "fork and forget" y es

heredado del proyecto Mosix. Consiste en que cuando un nodo esta
suficientemente cargado y los procesos pendientes puedan ser migrados a
otro nodo, se realiza dicha migración. Esto da lugar a que un proceso pueda
ser ejecutado en diversos nodos del cluster desde su inicio hasta su final sin
que sufra modificación alguna ni haya pérdida de información.
Cada proceso en el cluster tiene un único nodo raíz, que corresponde

con el nodo en el cual se lanza originalmente el proceso y donde éste
empieza a ejecutarse. Desde el punto de vista de los identificadores de
procesos (PIDS - Program IDs), cada proceso parece ejecutarse en su nodo
raíz. Esto se debe a que cuando un proceso es migrado a otro nodo, no usa
un PID del nodo de ejecución, sino que aparece como un subproceso del
kernel. Cualquier tipo de interacción con dicho proceso migrado sólo puede
ser realizado desde el nodo raíz del proceso. En cambio, la migración a otro
nodo o el retorno al nodo raíz se puede dirigir tanto desde el nodo raíz como
desde el nodo en el cual se está ejecutando el proceso.
Los procesos susceptibles de migrar pueden ser lanzados por

cualquier usuario. Éstos le pertenecerán y podrá manejarlos con los mismos
privilegios que tendría sobre ese proceso en un ordenador sin
cluster,aunque dicho proceso se encuentre en otro nodo. Sin embargo, la
migración manual y la vuelta al nodo de origen sólo puede ser llevada a
cabo por el administrador del nodo raíz o el del nodo en ejecución.
La migración de procesos en OpenMosix es completamente

transparente, por lo que el propio proceso no tiene constancia de estar
ejecutándose en un nodo distinto al raíz en el caso de que se le migre, con
lo cual la lectura/escritura de disco se lleva a cabo en el nodo raíz, aunque
sea remotamente.
Para que un proceso sea migrable debe cumplir las siguientes
condiciones:
● No debe utilizar memoria compartida.

● No puede utilizar instrucciones en ensamblador que posea el nodo raíz
y el de destino no.
● No puede mapear memoria de un dispositivo a la RAM, ni acceder
directamente a los registros de un dispositivo.
● No puede funcionar en modo de emulación VM86
Como estas condiciones no se pueden saber a priori, la política de

migrado es la migración por defecto y en el momento en el que algún
proceso deje de cumplirlas se devuelve a su nodo raíz hasta que termina de
ejecutarse o vuelve a cumplir las condiciones de migración. Respecto a los
clusters heterogéneos, sólo se permiten migraciones a nodos que tengan la
misma arquitectura que el nodo raíz. Nuestros ordenadores comparten la
misma arquitectura, la i386, aunque cada uno tenga las optimizaciones del
kernel adaptadas a su modelo (AMD o Pentium).
La comunicación entre el área de usuario y la del kernel se produce

cuando el proceso realiza llamadas al sistema. La política a seguir en estos
casos es la ejecución en el nodo destino de dicha llamada si es posible, es
decir, se realiza de manera local sin tener que utilizar la red. En el caso de
que la llamada no pueda ser atendida por el kernel del nodo destino ya que,
por ejemplo, se requiera comunicación con el hardware del nodo raíz, se
requiere interactuar con el kernel del nodo raíz. Para ello se manda la
petición junto con los parámetros y los datos del nodo raíz que se necesiten.
El nodo raíz procesará la llamada y devolverá al nodo destino el valor del
éxito/fracaso de la llamada, la información necesaria para actualizar sus
segmentos de datos, de pila y de heap y el estado del proceso si se
estuviera ejecutando en el nodo raíz.
Esta comunicación también puede ser generada por el nodo raíz. El

kernel de dicho nodo contacta con el kernel del nodo destino y le avisa de
que ha ocurrido un evento asíncrono. El kernel del nodo destino para el
proceso migrado y el nodo raíz atiende el código del área del kernel que
correspondería a la señal asíncrona. Una vez realizada todo lo necesario en
el kernel del nodo raíz, éste envía al nodo destino el aviso detallado de la
llamada y todo aquello que el proceso necesite saber (anteriormente
enumerado) cuando recibió la señal y el proceso migrado finalmente
recuperará el control.
Todo esto simula la existencia del proceso en el nodo raíz cuando

realmente se encuentra en el modo destino. Únicamente hay que hacer que
el proceso se suspenda esperando un recurso a nivel de kernel cuando hay
llamadas al sistema raíz.
Con esto se consigue la transparencia tanto a nivel de proceso
migrado como a nivel del resto de procesos que cohabitan en el nodo raíz
sin tener que reescribir el programa paralelamente ni conocer la topología
del cluster.
La pega a la transparencia lograda mediante este sistema es que las

llamadas al kernel raíz sobrecargan la red debido a la constante transmisión
de datos entre el nodo raíz y el nodo destino, especialmente cuando se
trabaja con sockets y acceso al disco duro.
2.11 Consideraciones finales
Llegados a este punto y habiendo realizado secuencialmente todas las

instrucciones descritas con anterioridad, tenemos un cluster de alto
rendimiento montado y configurado listo para trabajar con programas
paralelos. Los siguientes pasos de esta práctica consisten en ejecutar
distintos programas y benchmark con los que obtendremos unas medidas
objetivas de la capacidad de cómputo de nuestro cluster.
3. HERRAMIENTAS DE ADMINISTRACIÓN
3.1 OpenMosix Tools
Las openmosix tools son un conjunto de herramientas que nos

permiten administrar nuestro cluster, mediante su correcto uso podremos
realizar las operaciones de migrado de procesos, comprobar el estado de los
nodos o cambiar la configuración de un nodo sin necesidad de tocar ningún
archivo de configuración o de reiniciar la máquina. Hemos dedicado este
apartado a su explicación ya que las hemos utilizado para realizar las
pruebas en nuestro cluster.
3.1.1MOSCTL
Se trata de la principal herramienta de configuración de OpenMosix.

Su sintaxis es la siguiente:
[stay|nostay]: Con estos dos parámetros le indicamos al programa

que permita el migrado automático de procesos (nostay) o que lo impida
(stay).
[lstay|nolstay]: Con estas opciones le indicamos lo que queremos

que haga con los procesos locales. Con lstay le obligamos a que los
procesos locales no migren mientras que con nolstay permitimos que los
procesos locales migren.
[block|noblock]: Éstas son las opciones que le indican al nodo si

puede o no puede aceptar procesos entrantes. Si utilizamos noblock el nodo
aceptará procesos que hayan migrado desde otros ordenadores
pertenecientes al cluster.
[quiet|noquiet]: Nos permite activar o desactivar la recolección del

información sobre el balanceo de la carga de los nodos.
[nomfs|mfs]: Habilita o deshabilita el uso del sistema de ficheros

oMFS.
[expel|bring]: Con la opción expel enviamos de vuelta todos los

procesos que hayan sido aceptados por el nodo local en el que ejecutemos
la orden. Por otro lado, con la opción bring lo que conseguimos es traer a la
máquina local todos los procesos que hayan sido enviados a otros nodos. Si
queremos evitar una pérdida de información a la hora de apagar un equipo
deberemos ejecutar mosctl con estas opciones junto con la opción block
para impedir que mientras traemos o devolvemos los procesos nuestro nodo
local acepte otros nuevos.
[gettune|getdecay]: Mediante la opción gettune podemos mostrar
el valor actual del parámetro overhead que es usado en el kernel para
estimar el valor de Entrada/Salida en el balanceo de carga del cluster. Estos
valores se miden en microsegundos.
Vamos a mostrar un ejemplo de lo que imprime por pantalla la

siguiente orden en nuestro cluster:
$ mosctl gettune
OpenMosix Kernel Tuning Parameters (microseconds):
Home-node overhead in processing a demand-page = 81

Remote overhead in processing a demand-page = 150
Home-node overhead in processing a system call = 39
Remote overhead in processing a system call = 38
Basic home-node overhead for reading data =0
Home-node overhead per 1KB read = 11
Basic remote overhead for reading data = 0
Remote overhead per 1KB read = 18
Basic home-node overhead for writing data =0
Home-node overhead per 1KB written = 18
Basic remote overhead for writing data =0
Remote overhead per 1KB written = 12
Migration time of an empty process = 8141
Extra migration time per dirty page = 351
Mediante la opción getdecay podemos observar los parámetros

actuales de decaimiento del cluster. Estos parámetros controlan el
decaimiento gradual de las estadísticas de procesos antiguos. Solo se
guardan una porción de las estadísticas y esta porción es distinta para el
decaimiento lento y para el decaimiento rápido.
A continuación mostramos el resultado de estos valores en nuestro

cluster.
$ mosctl getdecay
Decaying statistics of active processes occurs every 2

seconds.
Slow decay leaves 975/1000.
Fast decay leaves 926/1000.
mosctl whois [openMosix_ID|IP-address|hostname]
Esta orden nos permite averiguar información concerniente a uno de

los nodos de nuestro cluster. Si sabemos su IP podemos averiguar el
identificador que tiene dentro del cluster, si conocemos el nombre del host
podemos averiguar su IP y si por el contrario solo sabemos el identificador
del nodo podemos averiguar su IP. Este procedimiento busca en los archivos
de configuración como el /etc/openmosix.map o el /etc/hosts para averiguar
los datos que hemos de consultar.
$ mosctl whois 3
192.168.2.20
$ mosctl whois 192.168.2.20

192.168.2.20 is openMosix #3
$ mosctl whois salon

salon is openMosix #3
mosctl [getload|getspeed|status|isup|getmem|getfree|getutil]
[openMosix_ID]
Con esta orden podemos conseguir una valiosa información sobre el

funcionamiento del cluster ya que utilizando estas opciones averiguamos
desde si el nodo está caído o funcionando hasta la memoria libre que tiene
cada nodo. Desde un único nodo local averiguamos información de
cualquiera de los nodos que estén conectados y configurados en nuestro
cluster. Este comando es muy importante debido a que con un uso
adecuado podemos monitorizar todo el sistema sin prácticamente influir en
él.
Podemos hacer esta afirmación de que prácticamente no influimos en

el sistema al utilizar este comando porque se trata tan solo de una línea
escrita en la consola, no necesitamos abrir las X que siempre consumen
recursos influyendo en la carga de nuestro sistema y quitando fiabilidad a
los datos que tomemos.
A continuación vamos a explicar qué tipo de información nos muestra

cada parámetro:
• getload: Nos muestra la carga del nodo especificado. Aunque la carga

pueda parecer una función compleja, bajo condiciones normales, una
carga de 100 representa un proceso que constantemente requiere el
uso de CPU con una determinada medida de velocidad. Si ejecutamos
el mismo proceso en un procesador más rápido la carga sería inferior a
100 mientras que si ejecutamos ese proceso en un procesador más
lento el valor de carga superaría las 100 unidades.
• getspeed: Nos muestra la velocidad de un nodo. Las unidades de

velocidad con las que trabajamos en el cluster OpenMosix se mide del
siguiente modo, la velocidad relativa de un Pentium III a 500 MHz se
consideran 5000 unidades de velocidad, del mismo modo, las de un
Pentium IV a 1,4 GHz serían 14000 unidades de velocidad.
• getmem: Muestra la memoria lógica disponible en el nodo
especificado.
• getfree: Muestra la memoria total disponible acumulando la memoria

lógica disponible y la memoria física que no está siendo usada.
• getutil: Nos muestra la usabilidad de un procesador en el nodo

especificado, el valor normal de esta propiedad debe ser 100 % y solo
debe cambiar cuando se esté accediendo a páginas de memoria o
cuando la memoria sea forzada.
A continuación mostramos algunos de estos valores de nuestro

cluster:
$ mosctl getload 3
load=0
$ mosctl getspeed 1
speed=17000.
$ mosctl getspeed 3
speed=5000.
$ mosctl isup 2
no
$ mosctl getmem 3
free memory = 324362240 of 335478784
$ mosctl getutil 1
Utilizability = 100%
mosctl setspeed interger-value
Este comando nos permite cambiar las unidades de velocidad del

nodo local en el que estemos trabajando. Las unidades de velocidad siguen
las mismas reglas que ya fueron explicadas anteriormente.
mosctl setdecay interval [slow fast]
Anteriormente explicamos como podíamos averiguar el tiempo de

retardo de nuestro cluster. Mediante esta orden en lugar de averiguar el
retardo podemos modificar su valor poniendo el que más nos interese
dependiendo de las operaciones que vayamos a monitorizar.
3.1.2 MOSRUN
Esta herramienta nos permite ejecutar un comando con una

configuración de nodos específica. Nos permite indicar el número de nodo
en el que se va a ejecutar o un rango de nodos, nos permite bloquear el
migrado de procesos. Asimismo podemos indicar al cluster como va a ser el
trabajo que vamos a ejecutar para permitirle mejorar el rendimiento, es
decir, si el trabajo va a tener una carga muy pesada de CPU lo va a saber
antes de ejecutarla permitiendo un mejor aprovechamiento de los ciclos de
reloj del procesador.
mosrun [-{h | openMosix_ID | jID1-ID2 [,ID3-ID4] ... } [-F]]

[-{l|L|k}] [-{c|i|n|s|f| [-t tt] [-d dec] } [-{e|E}] [-{r|R}]] [-z]
command [ arg ... ]
La opción -h especifica que el trabajo ha de volver al nodo de origen

cuando haya finalizado. La opción -c le indica al cluster que se trata de un
trabajo pesado de CPU y obliga a desactivar las estadísticas de
entrada/salida y otras llamadas del sistema.
Como podemos comprobar hay multitud de argumentos
nomig [-z] command [ arg ... ]: Ejecutar un comando que no

migrará.
runhome [-z] command [ arg ... ]: Ejecutar un comando que

quedará restringido a su nodo de origen.
runon openMosix_ID [-z] command [ arg ... ]: Ejecuta un

comando que será directamente migrado al nodo indicado.
cpujob [-{h|openMosix_id}] [-z] command [ arg ... ]: Esta orden

le indica al sistema que se trata de un trabajo computacional muy intensivo.
iojob [-{h|openMosix_id}] [-z] command [ arg ... ]: Ejecuta un

programa advirtiendo a OpenMosix de que se trata de un proceso con gran
carga de entrada/salida.
nodecay [-{h|openMosix_id}] [-z] command [ arg ... ]: Ejecuta

un comando sin tener en cuenta sus estadísticas.
slowdecay [-{h|openMosix_id}] [-z] command [ arg ... ]: Ejecuta

un programa advirtiendo a OpenMosix de aplicar un decaimiento de
estadísticas bajo.
fastdecay [-{h|openMosix_id}] [-z] command [ arg ... ]:Ejecuta

un programa advirtiendo a OpenMosix de aplicar un decaimiento de
estadísticas alto.
3.1.3 MIGRATE
Esta aplicación nos permite migrar un proceso específico a un nodo de

nuestro cluster una vez que ha sido ejecutada. La diferencia con la
aplicación mosrun es que en este caso no le indicamos al cluster las
opciones de ejecución sino que una vez ejecutada decidimos qué queremos
cambiar la carga de procesos a otro nodo.
Su sintaxis es la siguiente:
migrate pid {openMosix_ID|home|balance}
pid: identificador de proceso.

OpenMosix ID: número de nodo al que dirigimos la ejecución del
proceso.
Los pasos que hemos de seguir para utilizar convenientemente este

programa son los siguientes: Ejecutamos la aplicación y realizamos un top,
con esto averiguamos el pid del proceso que queremos migrar. Una vez que
tenemos el pid escribimos en la consola:
$ migrate pid 2
Con esta línea hemos conseguido migrar el proceso al nodo 2 de

nuestro cluster.
3.1.4MOSMON
Se trata de una aplicación que nos permite monitorizar el cluster de

manera cómoda y rápida. Este programa se ejecuta desde la consola en
modo texto, nos permite visualizar las propiedades de varios nodos
simultáneamente y sus opciones son las siguientes:
-v/-w/-V/-a: Son parámetros cuya única finalidad es conseguir una

representación de los datos más amigable dependiendo de la funcionalidad
que queramos estudiar. Sólo admite estas opciones en clusters con más de
10 nodos. Con -w conseguimos restringir el número de nodos que
aparecerán en el eje X. Con -v/-V restringimos la capacidad de carga, es
decir, restringimos el eje Y. Con -a mostramos todos los nodos.
-h: Muestra el menú de ayuda.
-t: Muestra el número de nodos del cluster.
-d: Muestra todos los nodos, incluso aquellos que no responden por
estar apagados o tener la opción de openMosix deshabilitada
temporalmente.
La siguiente imagen es una capturación del programa mosmon con la
opción -d. Como podemos observar nos muestra la carga actual de los
nodos del cluster, para mostrar el uso de la opción -d hemos desactivado el
nodo 2.
Utilizando este monitor agrupamos todas las opciones de la

herramienta mosctl ya que nos muestra la misma información que si
utilizásemos la orden mosctl getspeed ID siendo ID el identificador de cada
nodo (en nuestro caso 1,2,3).
El mosmon ha sido nuestro monitor elegido para realizar las

comprobaciones de migrado de procesos y uso de memoria debido a su
facilidad de uso y debido a que nos muestra la información de forma rápida
como barras de un gráfico, lo que nos permite comprobar a simple vista el
funcionamiento de nuestro cluster.
Una vez que hemos ejecutado el programa podemos cambiar la

visualización de datos pulsando una de las siguientes letras:
l: Muestra la carga de cada nodo, es la información que aparece por

defecto.
s: Nos muestra la velocidad de cada procesador.
u: Muestra el porcentaje de uso de cada CPU. Además se ha añadido

la opción “t” con lo que se pueden observar el número total de nodos y
CPUs del cluster.
m: Muestra por pantalla la memoria lógica utilizada frente al total de

memoria disponible.
r: Muestra la memoria física utilizada frente a la disponible en cada
nodo.
3.1.5 MOSLIMIT
Se trata de otra herramienta de administración de openMosix cuyo

objetivo es modificar los parámetros de carga de cada uno de los nodos,
tanto local como remoto, las opciones que hemos utilizado a la hora de
administrar nuestro cluster son las siguientes:
moslimit { getloadlocal | getloadremote | getcpulocal |

getcpuremote |getllimitmode | getcpulimitmode | getloadlimit |
getcpulimit } [ openMosix-ID ]
moslimit { setloadlimit | setcpulimit | setllimitmode |

setcpulimitmode } numeric-value
El primer grupo de opciones sirven todas para captar cierta

información específica del nodo especificado. Con dichas opciones podemos
observar la carga de cualquiera de los nodos y su uso de CPU. En este
programa se diferencia entre el uso local de un recurso y el uso remoto de
un recurso.
Por ejemplo, el uso local de la CPU sería el porcentaje de trabajo de la

CPU con los procesos que están corriendo en el nodo local. Sin embargo, el
uso remoto de CPU sería el trabajo que está realizando nuestra CPU para
resolver procesos que se han originado en otro nodo del cluster.
El segundo grupo de opciones tienen como objetivo cambiar alguno de

los valores de configuración del cluster para poder limitar el uso de CPU o
de carga de un determinado nodo sin necesidad de reiniciar el ordenador o
de reiniciar el script del openMosix.
Con el uso adecuado de estas opciones podríamos hacer que un

ordenador no estuviera compartiendo el 100 % de su CPU, podríamos
indicarle que tan sólo prestara para el resto del cluster un porcentaje menor
de CPU y permitir que los procesos locales se ejecutaran con mayor
prioridad.
Según la planificación de nuestro cluster no vemos necesario restringir

el uso de memoria, carga o CPU de ninguno de los nodos ya que nuestro
objetivo es solucionar los problemas en un tiempo más reducido.
3.1.6 MPS
Dentro de esta herramienta nos encontramos con dos aplicaciones: La

primera de ellas se llama mtop y se trata de una modificación del comando
top de linux pero nos muestra los procesos que se están ejecutando en
nuestro nodo junto con su uso de CPU y memoria, pero además nos muestra
mediante un campo extra los procesos que ha migrado a otro nodo.
La segunda herramienta que nos encontramos se llama ompsinfo, al

ejecutarla nos muestra las distintas aplicaciones que se están ejecutando en
nuestro sistema y si cabe la posibilidad de migrarla o es una operación que
no se puede migrar. Un ejemplo de la salida que obtenemos al ejecutarla
sería el siguiente:
$ ompsinfo
CMD PID NODE NMIGS LOCK CANTMOVE

init 1 0 0 0 init_proc
keventd 2 0 0 0 clone_vm
ksoftirqd_CPU0 3 0 0 0 clone_vm
kswapd 4 0 0 0 clone_vm
bdflush 5 0 0 0 clone_vm
kupdated 6 0 0 0 clone_vm
kjournald 7 0 0 0 clone_vm
oMfs_main_serve 8 0 0 0 daemon, clone_vm, rt_sched
oMFS_gc 9 0 0 0 daemon, clone_vm
oM_migd 10 0 0 0 daemon, clone_vm
oM_infoD 11 0 0 0 daemon, clone_vm, rt_sched
memsorter 12 0 0 0 daemon, clone_vm
eth0 117 0 0 0 clone_vm
syslogd 187 0 0 0 migratable
klogd 190 0 0 0 migratable
cron 193 0 0 0 migratable
bash 206 0 0 0 migratable
getty 208 0 0 0 migratable
mfs_server 212 0 0 0 daemon, clone_vm, rt_sched
mfs_server 213 0 0 0 daemon, clone_vm, rt_sched
sshd 347 0 0 0 migratable
mosmon 1555 0 0 0 migratable
xfs 1876 0 0 0 migratable
startx 1877 0 0 0 migratable
xinit 1888 0 0 0 migratable
XFree86 1889 0 0 0 monkey, mmap_dev, direct_io
x-session-manag 1892 0 0 0 monkey
ssh-agent 1923 0 0 0 migratable
gconfd-2 1926 0 0 0 migratable
bonobo-activati 1928 0 0 0 migratable
gnome-smproxy 1930 0 0 0 migratable
gnome-settings- 1932 0 0 0 monkey
metacity 1946 0 0 0 monkey
gnome-panel 1948 0 0 0 monkey
wnck-applet 1950 0 0 0 monkey
notification-ar 1952 0 0 0 migratable
gnome-terminal 1984 0 0 0 monkey
gnome-pty-helpe 1985 0 0 0 migratable
mozilla-bin 2027 0 0 0 monkey, clone_vm
abiword 2117 0 0 0 monkey
ompsinfo 2189 0 0 0 migratable
De este modo averiguamos si una determinada aplicación se puede

migrar en nuestro cluster openMosix, el número de veces que ha migrado,
el nodo en el que se está ejecutando,etc
Otras opciones de este programa nos permiten mostrar los procesos

de un usuario determinado o un proceso en concreto que es lo que
observamos en el siguiente ejemplo:
$ ompsinfo 1
CMD NODE NMIGS LOCK CANTMOVE

init 0 0 0 init_proc
3.1.7SETPE
Se trata de una aplicación que nos permite indicar la pertenencia o no

de un nodo a nuestro cluster, podríamos hacer una analogía de esta orden
con el script del openMosix que hemos situado en la siguiente ruta /
etc/init.d/openmosix. Mediante la orden:
$ setpe -s -f /etc/openmosix.map
Indicamos la pertenencia de nuestro nodo local al cluster, a partir de

este momento estará dispuesto a migrar procesos y a recibir los procesos
que hayan sido generados en otros nodos.
Con esta orden indicamos que nuestro nodo local ya no pertenecerá al
cluster:
$ setpe -off
Con la opción -r obtenemos la tabla siguiente que nos muestra las

máquinas que tiene actualmente nuestro cluster:
$ setpe -r
This is OpenMosix node #1

Network protocol: 2 (AF_INET)
OpenMosix range 1-1 begins at Shadowland
OpenMosix range 2-2 begins at Asimov
OpenMosix range 3-3 begins at salon
Total configured: 3
3.2 OPENMOSIXVIEW
Se trata de una aplicación para la monitorización de nuestro cluster

con la que también podemos obligar el migrado de procesos y la ejecución
de programas en un nodo determinado o en varios nodos simultáneamente.
La explicación de este monitor la vamos a realizar mediante las

capturaciones de pantalla que hemos ido observando a lo largo de la
realización del proyecto.
Ésta es la apariencia del programa con los tres nodos operativos:
En la primera columna vemos el identificador de cada nodo sobre

color verde, esto significa que el nodo está funcionando correctamente, si
hubiera algún problema en la detección del nodo o se encontrara apagado
el ordenador, el color de fondo sería rojo. A continuación nos encontramos
con una segunda columna en la que vemos las ips asignadas a cada uno de
los ordenadores del cluster.
Los deslizadores nos permiten modificar la velocidad del nodo y en la

siguiente columna vemos la carga que soporta cada uno de los nodos.
Si hacemos click en uno de los botones con la ip de un nodo podemos

visualizar o modificar las opciones "mosctl" del nodo elegido.
Modificando las barras de desplazamiento podemos cambiar la

velocidad de un nodo, un proceso migrará más fácilmente a un nodo con
mayor velocidad que a otro con menos velocidad. Al modificar estas barras
no estamos cambiando la velocidad física/real del procesador sino que
cambiamos la velocidad que openMosix "cree" que tiene el nodo con lo que
podemos limitar el uso de CPU de un nodo específico.
En la parte superior podemos ver una barra con el nombre de load

balancing efficiency, se trata de la eficiencia de balanceo que conseguimos
con la configuración actual de los nodos del cluster, cuando la configuración
es buena conseguimos eficiencias cercanas al 100%.
En la parte superior de la ventana del openmosixview tenemos un

menú que nos permite guardar la configuración actual del cluster y lanzar
unas aplicación para comprobar las estadísticas del uso de CPU de cada
nodo o del migrado de procesos. Estas aplicaciones las explicamos
brevemente a continuación:
openMosixprocs: Lista los procesos que tenemos actualmente en el

cluster y nos permite ver el número de veces que ha migrado.
openMosixCollector: Se trata de un demonio que se encarga de

guardar los logs del cluster junto con información sobre los nodos. Esta
información será posteriormente utilizada por el openMosixanalyzer para
generar las estadísticas.
openMosixanalyzer: Se trata de una aplicación que nos muestra

gráficos sobre el uso de CPU y gráficos sobre la carga de cada nodo y el
total. Esta es una capturación de pantalla que hemos tomado mientras
estaba corriendo la aplicación cisilia, nos muestra el visualizador de carga.
Si hiciéramos click sucesivamente en los botones del menú nos mostraría el
uso de memoria y la lista de procesos que se están ejecutando.
En la primera barra horizontal vemos la gráfica del cluster en conjunto
mientras que en las tres porciones restantes de pantalla tenemos el
balanceo de carga de los tres nodos del cluster. Como ejemplo hemos hecho
click en la lupa del grupo "All" nos aparece una nueva ventana con las
estadísticas del balanceo de carga con barras verticales de distintos colores
que nos indican el valor mínimo, medio y máximo respectivamente.
openMosixhistory: Se trata de una aplicación semejante a la

anterior, la diferencia es que con el openMosixanalyzer tan solo vemos las
estadísticas de la sesión actual, mientras que con esta aplicación también
tenemos acceso a los archivos de logs antiguos.
openMosixmigmon: Se trata de un monitor para observar las

migraciones dentro del cluster openMosix. La siguiente imagen es un
ejemplo de lo que hemos visto al ejecutar esta aplicación:
Podemos ver mediante esta capturación que cada uno de los nodos
está representado por un círculo. Los puntos negros son los procesos que se
están ejecutando localmente (en este caso el nodo 2 tendría dos procesos
locales), los puntos verdes son los procesos que hemos migrado (los nodos
1 y 3 habrían obtenido procesos del nodo 2). Las líneas discontinuas nos
indican el origen del proceso.
Para realizar el proceso de migrado tan solo tenemos que hacer click
sobre uno de los punto y arrastrar el proceso hasta el ordenador que
queremos que lo ejecute.
openMosixpidlog: Monitor que nos muestra los procesos simples que

están corriendo en nuestro nodo local.
Para poder utilizar la gestión remota de los nodos mediante

OpenMosixView se necesita que todos los nodos tengan un servidor SSH
(sshd). Dicho servidor se utiliza para conectarse a él por ssh al puerto 22/tcp
y mandarle las órdenes desde el ordenador donde se ejecute el
OpenMosixView.
Para lograr que este proceso sea transparente al usuario se necesitan

2 cosa: que se cargue el servidor SSH al inicio y que los nodos no pidan la
contraseña cada vez que se realiza una conexión ssh a ellos.
La primera condición se resuelve de forma sencilla creando un enlace

simbólico ($ ln -s /etc/init.d/ssh /etc/rc2.d/S99ssh)que hace que al
arranque se ejecute el script que inicia el servidor ssh (esto se debe a que
en la estructura de directorios de Debian en /etc/init.d se guardan todos los
scripts de inicio de todos los servidores).
La segunda condición es algo más complicada de resolver. Para ello se
necesita crear una llave RSA de root para cada nodo que contenga una
contraseña vacía:
$ ssh-keygen -t rsa
Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): (en blanco)
Enter passphrase (empty for no passphrase): (en blanco)
Enter same passphrase again: (en blanco)
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
b1:ea:e8:2a:7d:a8:58:6d:c2:4c:c1:15:ed:7c:eb:26 root@Asimov
Un vez hecho eso, tenemos que mandar el archivo de llave pública

generado (id_rsa.pub ) a los demás nodos de la red y volcar dicho archivo de
cada nodo al archivo /root/.ssh/authorized2_keys .A continuación se muestra
como queda dicho archivo:
$ cat authorized2_keys
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAvXq55KQTpnwK9Bhn9a9edx9Ab
TNoNqdTzwhxMJRvzrqohYfq16Wv09qgK6WvE5IH5v/WT+92xuAR6iU
kB5aMysd4yOhdiu6FHpSK6wGhgVSdpFJsd6s+1A4eoRKwMFRtqRG/b
QPn5758BiFDuAhSbVMLTYiFyTy4iI1I0pP19qs= root@Asimov
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEA2k+KKxLkmkqvgf9sdWFcsBKnoY
zJj4mTKNeXixBT+4ec5NcOQ4/LgXHfYizQHos0wilfGwBAipHe8OIzhaN
t7z+ofWD3Vo7ocV3P3Kuuu3ONAtGKrX5lglaIOq3NTBv5GGClKtDXwK
V+msn5rgK+Z0LOILj1eHa/HVgEZwblQP0= root@Shadowland
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEA5bpT0iVDZ7dS2zltjl30+3RArZYG
I0PTTHAXrh54RZtdmCBsUVdUzbvONEjoO7qj/FA4l/LPgG/woDlLXnBpy
f2CQ2NGcc0S5QSAEqnCzd79RTiM+e8J+aTV3VWgzoAIbTwQduHzmA
447p1zH1JK9JAguVCE4wmv3bhKEgTC9qM= root@salon
Con ello se consigue que sólo los ordenadores cuya llave pública se
encuentre en este archivo puedan conectarse a nosotros. Esta medida es
importante ya que hay que tener en cuenta que vamos a utilizar un clave
ssh vacía y cualquiera podría entrar en un nuestro ordenador como root
(superusuario) y hacer de él lo que se le antoje.
A continuación vamos al directorio /etc/ssh y configuramos el archivo

ssh_config (archivo de configuración del cliente ssh) dejando todas las líneas
tal cual están y retocando únicamente la siguiente línea:
PasswordAuthentication yes
Después pasamos a configurar el archivo sshd_config (archivo de
configuración del servidor sshd) cambiando únicamente las siguientes
líneas:
PermitRootLogin yes
(permite conectarse al root remotamente)
RSAAuthentication no
(no realiza autentificación de llaves RSA)
PubkeyAuthentication yes
(realiza autentificación de llaves públicas)
AuthorizedKeysFile %h/.ssh/authorized2_keys
(indica al servidor que las claves públicas de los ordenadores a los que
se permite acceder están en %h/.ssh/authorized2_keys. %h=nombre del
usuario.)
PermitEmptyPasswords yes
(permite claves vacías,es decir, sin caracteres)
PasswordAuthentication yes
(requiere autentificación de claves)
Con esto se obliga a las máquinas a autentificarse por clave pública,

se permite el login remoto del root (medida nada recomendable en
cualquier política de seguridad pero imprescindible para la administración
remota de los nodos) y se permiten contraseñas vacías.
Tras esto ya se pueden realizar login remotos sin tener que introducir
ninguna clave:
Shadowland:~# ssh 192.168.2.2

The authenticity of host '192.168.2.2 (192.168.2.2)' can't be
established.
RSA key fingerprint is
1c:01:ac:15:e6:92:8d:96:b5:f3:c3:5f:1f:2f:41:9d.
Are you sure you want to continue connecting (yes/no)?
(contestamos "yes" y ya no nos preguntará nunca más ya que
queda guardado en el archivo /root/.ssh/known_hosts)
Warning: Permanently added '192.168.2.2' (RSA) to the list of
known hosts.
Last login: Sat Feb 21 18:38:03 2004
Asimov: ~#
Como se ve,de acceso en el nodo 2 (Asimov) sin pedir ningún

password, con lo que hemos conseguido nuestro objetivo. También se
podría haber desactivado la utilización de cualquier tipo de autentificación
en el ssh, pero esto lo transformaría en un simple telnet y le haría perder su
esencia de shell segura, con lo que cualquier usuario desde el exterior
podría acceder a los nodos y manipularlos a su gusto.
Para finalizar vamos a ilustrar el uso habitual del openmosixview con

una capturación de pantalla general.
3.3 CONSIDERACIONES FINALES
A la hora de realizar la monitorización del sistema tenemos varios

modos a elegir, podemos realizar todas las medidas a mano con las
herramientas que nos proporciona el comando "mosctl", podemos utilizar el
mosmon o el openmosixview.
En nuestro caso hemos decidido utilizar el mosmon por varias razones,

realizar todo el proceso de monitorización con la herramienta mosctl es
incómodo y no podemos ver de forma conjunta los resultados.
En este momento nos preguntamos porqué no utilizar el

openmosixview que de forma rápida y cómoda nos muestra todos los datos
y nos da las estadísticas.
La respuesta es que si utilizamos el openMosixview necesitamos tener
arrancados algunos demonios como el openMosixcollector que se está
ejecutando constantemente modificando la carga de nuestro sistema,
además necesitamos arrancar el servidor X con algún gestor como el
Gnome o Kde, eso implica tener cargadas librerías y procesos que no
necesitamos para llevar a cabo la monitorización del cluster.
Hemos elegido el mosmon porque podemos ejecutarlo en modo texto

y porque nos muestra una información adecuada de nuestro cluster sin ser
una gran carga para nuestro sistema.
4.TESTS Y BENCHMARKS
4.1CODIFICACIÓN DE FICHEROS DE AUDIO WAV A MP3
Otra de las aplicaciones que pueden darse a un cluster de alto

rendimiento es la conversión de ficheros de audio de un formato a otro. En
esta ocasión hemos elegido un CD de música original ( Bob Marley & The
Wailers - Natural Mystic ) para evitar problemas de piratería. Este CD consta
de 15 canciones que ripeamos a WAV con el programa cdda2wav:
Nº DE CANCIÓN DURACIÓN
1 3:27
2 2:55
3 3:13
4 3:23
5 3:58
6 3:31
7 2:54
8 4:10
9 4:21
10 4:35
11 4:17
12 3:52
13 3:31
14 3:27
15 3:29
$ cdda2wav -x -D /dev/cdrom -t 1+15 -O wav -B
-x : Máxima calidad (stereo/16-bit/44.1 KHz)

-D /dev/cdrom: Ubicación del CD que se va a ripear
-t 1+15 : Ripea de la canción 1 a la 15 (todo el CD)
-O wav : Lo deja en formato wav
-B : Ripea cada canción en un archivo distinto
$ cdda2wav -x -D /dev/cdrom -t 1+15 -O wav
Lo mismo que en el anterior pero ripea todo el CD en un solo fichero.

No hemos ripeado directamente en MP3 porque este programa no soporta
subprocesos y, por tanto, no se pueden realizar las migraciones a los
distintos nodos del cluster. Para ello utilizamos el programa bladeenc que se
encarga de convertir de .WAV a .MP3 y sí que crea subprocesos que se
pueden migrar. La sintaxis del comando de conversión es:
$ bladeenc cancion.wav (la transforma a cancion.mp3)
Para realizar la prueba de convertir los 15 archivos de forma

secuencial basta con ejecutar:
$ bladeenc cancion*.wav
para que convierta los 15 archivos (cada uno de ellos tiene el formato
cancion??.wav donde ?? es un número de 2 dígitos).
Sin embargo para la realización de la conversión de los 15 archivos de

forma paralela es necesaria la creación del "shell script" test.sh :
#!/bin/sh
echo "Comienza la conversión de los 15 archivos"
bladeenc cancion1.wav &
echo "Ya se han mandado a convertir los 15 procesos (pero no
han acabado) "
Para la conversión del archivo con todo el Cd se ejecuta:
$ bladeenc entero.wav
CON CLUSTER SIN CLUSTER

Convertir los 15
archivos de forma 7 min 56.04 s 7 min 56.04 s
secuencial
Convertir los 15
archivos de forma 6 min 13.8 s 8 min 5.59 s
paralela
Convertir el archivo que
7 min 57.1 s 7 min 57.1 s
comprende todo el CD
La conclusión más inmediata de este test es que la conversión de los
15 archivos de forma paralela en cluster es un 23.02% más rápida respecto
a la prueba homóloga sin cluster. Sin embargo, el dato que más llama la
atención es que tarde lo mismo tanto en cluster como en solitario en la
conversión de forma secuencial y en la conversión de un sólo archivo que
contenga todo el CD.
A partir de este test se puede afirmar que el algoritmo de migración

además de transparente al usuario también es rápido y eficiente en la toma
de decisiones,por lo que no consumiría ningún tiempo extra considerable en
el caso de ejecutar procesos no diseñados para aprovecharse del cluster.
4.2CISILIA
La ruptura de contraseñas mediante fuerza bruta (ir probando una a

una hasta dar con la adecuada)requiere contar con velocidades de
procesamiento muy elevadas. Esto puede lograrse, o bien contando con una
supercomputadora o bien conectando muchas computadoras de bajo costo,
uniendo sus capacidades de procesamiento formando un cluster.
Cisilia es un sistema de obtención de contraseñas en paralelo,

ejecutable sobre plataformas Linux, puramente escrita en lenguaje C.
Obtiene contraseñas de sistemas Windows NT/2000/XP o Samba mediante
el cálculo de hashes DES/MD4 por fuerza bruta en paralelo.
Por ese motivo está programado como sistema multiproceso con la

capacidad de ejecutarse tanto en sistemas multiprocesador (SMP) como en
clusters de PC´s del tipo "balanceo de carga". Dicha ejecución en paralelo
se realiza a través de la función fork() [BUSCAR O ELIMINAR]. Cisilia asigna
dinámicamente los espacios discretos de contraseñas que va a calcular cada
subproceso y crea los "n" subprocesos hijos.
Si cisilia se ejecuta en un cluster del tipo "balanceo de carga", los

diferentes subprocesos son migrados automáticamente a los diferentes
nodos aumentando así la velocidad total de cálculo. Ésto se debe a que
cumple con las condiciones que OpenMosix establece para que un sistema
de esta naturaleza pueda ejecutarse en paralelo sin problemas.
Para esta prueba hemos utilizado la siguiente sintaxis en la ejecución

del programa,tanto para un sólo ordenador como para todo el cluster:
$ cisilia -V -n 6 fichero-claves
-V : Modo "verbose". Muestra más información por pantalla de los que

realiza el programa en cada momento.
-n 6 : Número de subprocesos que genera el programa. En el modo de

un solo ordenador asume él mismo los 6 procesos y en el modo cluster se
migran los que sean necesarios.
El alfabeto se ha dejado por defecto en alfanumérico [A-Z] y [0-9] ya
que las contraseñas normalmente utilizadas por los usuarios medios no
llevan caracteres no alfanuméricos.
Primero ejecutamos el comando sobre el ATHLON 2000XP trabajando

él solo y después, tras reiniciar para que no quedasen rastros de los cálculos
en la memoria, pasamos a ejecutarlo con el cluster funcionando. Los
resultados obtenidos son los siguientes:
CON CLUSTER SIN CLUSTER

CLAVE 4 CARACTERES
00:00:00.515 00:00:0.175
(zape)
CLAVE 6 CARACTERES
00:12:25.915 00:20:16.168
(poster)
CLAVE 8 CARACTERES
07:08:20.346 10:32:37.948
(alberto1)
Como se puede apreciar en la tabla, para claves cortas (4 caracteres)

no compensa hacer funcionar al ordenador dentro de un cluster. Esto es
obvio ya que lo que tarda el kernel en sopesar si realiza la migración o no
conlleva un tiempo inútil,ya que para realizar un proceso tan rápido no
compensa realizar una migración a ningún otro nodo.
En cambio, cuando se trata de procesos que consuman mucho tiempo

y CPU (ruptura de claves de 6 y 8 caracteres), si que se nota el rendimiento
del cluster frente a un ordenador en solitario,ya que el tiempo empleado en
romper la misma contraseña se ve reducido en un 38.67% respecto a la
claves de 6 caracteres y en un 32.29% respecto a la clave de 8 caracteres.
4.3 OPENMOSIX STRESS TEST
Se trata de un test desarrollado para evaluar el rendimiento del

cluster, su estabilidad y debido funcionamiento en todos los aspectos, ya
sea en llamadas al kernel, migración de procesos, utilización del sistema de
ficheros mfs,etc. Consta de 7 partes:
DISTKEYGEN : Se encarga de generar 4000 pares de llaves RSA de

1024 bits utilizando todos los nodos del cluster.
PORTFOLIO : Programa en PERL que simula conjuntos de acciones

distintos para un periodo de tiempo determinado.
EATMEN : Calcula funciones sinusoidales y raíces cuadradas un millón

de veces mientras escribe en un archivo el valor del contador del bucle. Se
ejecuta tantas veces como nodos haya en el cluster.
FORKIT : Similar a EATMEN con la excepción de que utiliza la llamada
al sistema "fork()" para crear múltiples procesos(3 veces el número de
nodos del cluster) y no escribe en ningún archivo.
MFSTEST : Programa que se encarga de chequear el oMFS mediante

la creación de un archivo de 10 MB y la copia hacia y desde todos los nodos.
MOVING : Mueve el script de arranque de todos los test

(start_openMosix_test.sh) a cada nodo del cluster una vez por minuto
durante su ejecución.
TIMEWASTER : Realiza determinados cálculos numéricos.
Para iniciarlo basta con ejecutar desde el directorio de su instalación:

$ ./start_openMosix_test.sh
Los tiempos de ejecución de los distintos test son los siguientes:
starting distkeygen at Thu Feb 26 20:44:23 CET 2004

finished distkeygen at Thu Feb 26 20:52:21 CET 2004
starting portfolio at Thu Feb 26 20:52:21 CET 2004
finished portfolio at Thu Feb 26 20:59:45 CET 2004
starting eatmem at Thu Feb 26 20:59:45 CET 2004
finished eatmem at Thu Feb 26 21:01:28 CET 2004
starting forkit at Thu Feb 26 21:01:28 CET 2004
finished forkit at Thu Feb 26 21:04:14 CET 2004
starting timewaster at Thu Feb 26 21:04:15 CET 2004
finished timewaster at Thu Feb 26 21:09:44 CET 2004
starting oMFStest at Thu Feb 26 21:09:44 CET 2004
finished oMFStest at Thu Feb 26 21:15:30 CET 2004
TEST TIEMPO
DISTKEYGEN 7 min 58 s
PORTFOLIO 7 min 24 s
EATMEM 1 min 43 s
FORKIT 2 min 46 s
TIMEWASTER 5 min 29 s
OMFSTEST 5 min 46 s
Los resultados de los diversos test se guardaron en un fichero de texto

plano con cada una de las operaciones/comprobaciones que realizaba, así
como si se había superado correctamente o no. Los únicos problemas que
se encontraron fue a la hora de ejecutar el OMFSTEST , ya que al
encontrarse el sistema de ficheros de OpenMosix todavía en fase de
experimentación (beta) detecto alguno errores de punteros nulos en
llamadas al sistema. Omitimos volcar el fichero de resultados ya que ocupa
12802 líneas de texto (489605 bytes).
3.4 NAS PARALLEL BENCHMARKS 2.0
Este conjunto de benchmarks está basado en FORTRAN 77 y la librería

de paso de mensajes MPI. Los test incluidos son los siguientes:
• EMBARRASINGLY PARALLEL (EP) : mide las limitaciones del

rendimiento en punto flotante del cluster.
• MULTIGRID (MG) : testea la comunicación a larga y corta distancia del

cluster a nivel de kernel.
• CONJUGATE GRADIENT (CG) : mide las comunicaciones irregulares a

larga distancia a nivel de kernel.
• 3-DFFT PDE (FT) : Comprueba las comunicaciones a larga distancia a

nivel de kernel.
• INTEGER SORT (IS) : mide la capacidad y velocidad de cálculo con

enteros.
• LU SOLVER (LU) : testea el rendimiento del paso masivo de mensajes

cortos de la librería MPI.
• PENTADIAGONAL SOLVER (SP) y BLOCK TRIDIAGONAL SOLVER (BT)

realizan diversos tests a nivel de aplicación para medir el rendimiento del
cluster.
Cada uno de los tests se puede ejecutar para distintos tamaños de

problema:
TEST CLASE A CLASE B CLASE C

EP 2^28 2^30 2^32
MG 256^3 256^3 512^3
CG 14000 75000 150000
FT 256^2*128 512*256^2 512^3
IS 2^23 2^25 2^27
LU 64^3 102^3 162^3
SP 64^3 102^3 162^3
BT 64^3 102^3 162^3
IS Benchmark
Class = A Class = B
Size = 8388608 Size = 33554432
Iterations = 10 Iterations = 10
Time in seconds = 16.71 Time in seconds = 3945.41
Total processes = 4 Total processes = 4
Compiled procs = 4 Compiled procs = 4
Mop/s total = 5.02 Mop/s total = 0.09
Mop/s/process = 1.26 Mop/s/process = 0.02
Operation type = keys ranked Operation type = keys ranked
Verification = SUCCESSFUL Verification = SUCCESSFUL
Version = 2.3 Version = 2.3
Compile date = 24 Feb 2004 Compile date = 24 Feb 2004
Class = S Class = W
Size = 65536 Size = 1048576
Operation type = keys ranked Operation type = keys ranked
EP Benchmark
Class = A Class = B
Size = 536870912 Size = 2147483648
Operation type = Random numbers Operation type = Random numbers
generated generated
Class = S Class = W
Size = 33554432 Size = 67108864
Operation type = Random numbers Operation type = Random numbers
generated generated
MG Benchmark
Class = A Class = B
Size = 64x 64x 64 Size = 256x256x256
Operation type = floating point Operation type = floating point
Class = S Class = W
Size = 32x 32x 32 Size = 64x 64x 64
CG Benchmark
Class = A Class = B
Size = 14000 Size = 75000
Class = S Class = W
Size = 1400 Size = 7000
FT Benchmark
Class = A El tamaño B no fue capaz de terminar

Size = 256x256x128 dándonos el siguiente error:
Iterations = 6 No input file inputft.data. Using
Time in seconds = 1445.69 compiled defaults
Total processes = 4 Size : 512x256x256
Compiled procs = 4 Iterations : 20
Mop/s total = 4.94 Number of processes: 4
Mop/s/process = 1.23 Processor array: 1x 4
Operation type = floating point Layout type: 1D
Verification = SUCCESSFUL bm_list_1440:(497.524240)
Version = 2.3 wakeup_slave: unable to interrupt
Compile date = 24 Feb 2004 slave 0 pid 1439
p1_1444: p4_error: net_recv read:
probable EOF on socket: 1
Class = S Class = W
Size = 64x 64x 64 Size = 128x128x 32
LU Benchmark
Class = A Class = B
Size = 64x 64x 64 Size = 102x102x102
Class = S Class = W
Size = 12x 12x 12 Size = 33x 33x 33
SP Benchmark
Class = A El tamaño B no ha terminado de

Size = 64x 64x 64 ejecutarse dándonos este error: No
Iterations = 400 input file inputsp.data. Using
Total processes = 4 Size: 102x102x102
Compiled procs = 4 Iterations: 400 dt: 0.001000
Mop/s total = 55.58 Number of active processes: 4
Mop/s/process = 13.90
Operation type = floating point
Verification = SUCCESSFUL
Version = 2.3
Compile date = 24 Feb 2004
Class = S Class = W
Size = 12x 12x 12 Size = 36x 36x 36
BT Benchmark
Class = A El problema de tamaño B nos dio el

Size = 64x 64x 64 siguiente error:
Iterations = 200 No input file inputbt.data. Using
Total processes = 4 Size: 102x102x102
Compiled procs = 4 Iterations: 200 dt: 0.000300
Mop/s total = 70.17 Number of active processes: 4
Mop/s/process = 17.54
Operation type = floating point bm_list_665: (570.230195)
Verification = SUCCESSFUL wakeup_slave: unable to interrupt
Version = 2.3 slave 0 pid 664
Compile date = 24 Feb 2004 bm_list_665: (570.230515)
wakeup_slave: unable to interrupt
slave 0 pid 664
p1_669: (566.557414) net_recv failed
for fd = 3
p1_669: p4_error: net_recv read,
errno = : 104
p2_676: (564.246951) net_recv failed
for fd = 3
p2_676: p4_error: net_recv read,
errno = : 104
Class = S Class = W
Size = 12x 12x 12 Size = 24x 24x 24
Una vez vistos todos los resultados de los tests vamos a explicar el
significado de cada uno de los valores para averiguar el rendimiento de
nuestro cluster.
Class: Se trata del tamaño del problema que ejecuta el benchmark, el

orden de tamaño es el siguiente: el S (sample) es el más pequeño, a
continuación va el W (workstation), posteriormente el A, B y C. El tiempo
que tarda el programa en ejecutarse es directamente proporcional al
tamaño del problema que debe resolver. A la hora de ejecutar el benchmark
FT y SP con el tamaño B encontramos problemas sin obtener los resultados
esperados.
Hemos encontrado problemas similares en la ejecución de todos los

benchmarks con tamaño C por lo que podemos concluir que nuestros
equipos no están preparados para ejecutar problemas de tal tamaño.
Size: En este campo se especifica el tamaño exacto de la aplicación.
Iterations: Se trata del número de veces que repite el problema.
Time in seconds: Es el tiempo que ha tardado el cluster en ejecutar

cada uno de los benchmark, como ya explicamos anteriormente este tiempo
está estrechamente relacionado con el tamaño de problema.
Total processes: Se trata del número de procesos con el que lo

hemos ejecutado, es el número que aparece como argumento en la orden:
$ mpirun -np 4 comando
Todas las ejecuciones coinciden en que el número de procesos es

cuatro. Este número no ha sido elegido al azar sino que cada uno de los
benchmark tienen especificaciones concretas sobre el número de procesos
con el que se puede ejecutar.
Compiled procs: Este valor está relacionado con el campo anterior.
Este número está relacionado con el número de CPU's que tenemos. En
nuestro caso tenemos tres procesadores en los que vamos a ejecutar las
pruebas sin embargo no podemos elegir el número tres ya que en los
benchmark estamos obligados a poner números de procesos que sean
potencias de dos o cuadrados perfectos.
Mop/s total y Mop/s/process: En este campo se indican los Mflops

que ha alcanzado el cluster al ejecutar los benchmark. Los Mflops son
millones de operaciones en punto flotante que realiza el ordenador por
segundo. En estos benchmarks este valor es una estimación realizada sin
las optimizaciones del compilador. Estos benchmarks necesitan ser
compilados para un tamaño de problema específico y para un número de
procesos específico. El objetivo de los Mflops es poder comparar el
rendimiento de dos ordenadores distintos. Para utilizar estos valores como
comparaciones válidas entre equipos debemos haberlos compilado con las
mismas opciones de tamaño y número de procesos.
Operation type: En este campo se especifica el tipo de operación

que realiza el programa de prueba. Los tipos que tenemos son: Punto
flotante, rango de claves y números aleatorios.
Verification: Nos indica si el test se ha realizado con éxito o si por el

contrario ha fracasado en su ejecución.
Version: Nos informa de la versión del test.
Compile date: Muestra la fecha en la que fue compilado.
A la hora de compilar los diversos test tuvimos que modificar el

Makefile de algunos de ellos para que consiguieran compilar (error de
desbordamiento de tamaño de variable). La modificación fue cambiar en el
make.def el campo RAND = randi8 por RAND=randi8_safe. Los tests que
necesitaron de esta modificación fueron: EP, MG, CG y FT.
Los tamaños de test S y W son triviales de resolver incluso para

ordenadores con un único microprocesador. El tamaño de problema A y B
pasaría las pruebas sin problema igualmente en ordenadores
monoprocesador aunque con un coste de tiempo mucho mayor. Por último,
el tamaño de problema C es una innovación respecto a la versión anterior
de este benchmark. Se basa en la idea de que los clusters a gran escala
necesitan tests mucho más pesados de ejecutar para poder comprobar su
rendimiento con grandes cargas.
3.5COMPILACIÓN DEL KERNEL
Debido a que uno de los posibles usos de los clusters de alto

rendimiento son las granjas de compilación, hemos compilado el kernel de
Linux en cluster (como ejemplo de compilación larga) para comprobarlo.
Para ello hemos utilizado el parámetro -j del comando make. Éste especifica
el número de trabajos (órdenes) que se deben ejecutar simultáneamente. Si
se da la opción -j sin ningún argumento, make no pondrá límites al número
de trabajos que puedan ejecutarse simultáneamente.
Los resultados en tiempo medidos mediante el comando time

ejecutado desde el nodo 1 ( 1.7 Ghz) :
COMANDO TIEMPO SIN CLUSTER TIEMPO CON CLUSTER

$ make -j 3 clean 1 m 3.567 s 1 m 31.130 s
$ make -j 3 dep 0 m 7.168 s 0 m 7.236 s
$ make -j 3 bzImage 3 m 18.696 s 3 m 19.668 s
La duración de los procesos en cluster es superior respecto a los

mismos procesos sin cluster, lo cual demuestra que la compilación del
kernel está diseñada secuencialmente.
Asimismo, la utilización del parámetro -j del make para simular la

paralelización de la compilación no tiene el mismo rendimiento que si
ejecutásemos un programa linkado con librerías paralelas como MPI y
diseñado específicamente para realizar compilaciones paralelas.
3.6 PALLAS MPI BENCHMARKS (PMB-MPI1)
Los objetivos de este conjunto de benchmarks son:

• Medir el rendimiento de las funciones más importantes de las librerías
MPI
• Utilizar una metodología de benchmarking precisa
• Mostrar los tiempos y resultados tal cual los obtiene, sin realizar
interpretaciones de los mismo.
Los test que componen este benchmark son:
• PingPong: utiliza un patrón clásico de inicialización y alto rendimiento

para mandar mensaje simples entre 2 procesos.
• PingPing: básicamente igual que el anterior con la diferencia de que
los mensajes son obstruidos por los que viajan en sentido contrario.
• Sendrecv: los procesos forman una cadena periódica de comunicación.
Cada proceso manda mensajes al proceso que se encuentra a su
derecha en la cadena y recibe los mensajes del que se encuentra a su
izquierda.
• Exchange: Igual que el anterior salvo que el paso de mensajes se
realiza en ambas direcciones tanto a derecha como a izquierda de cada
eslabón en la cadena.
• Reduce: reduce la longitud de un vector de reales con una longitud
determinada.
• Reduce_scatter: realiza los mismo que el test anterior pero de forma
dispersa y progresiva
• Allreduce: similar al test Reduce pero con funciones de MPI diferentes
• Allgather: cada proceso pasa un número concreto de bytes y recibe
ese mismo número de bytes multiplicado por el número de procesos.
• Allgatherv: similar a Allgather pero utilizando funciones de MPI
diferentes.
• Alltoall: similar a Allgather pero se envían y reciben el número de
bytes multiplicados por el número de procesos.
• Bcast: manda un proceso con un número concreto de bytes a todos los
nodos.
• Barrier: no se menciona su función en la documentación.
Benchmarking PingPong
( #processes = 3 )
#bytes #repetitions t[usec] Mbytes/sec

0 1000 17.26 0.00
1 1000 17.21 0.06
2 1000 17.36 0.11
4 1000 17.55 0.22
8 1000 17.91 0.43
16 1000 17.42 0.88
32 1000 18.16 1.68
64 1000 18.46 3.31
128 1000 18.19 6.71
256 1000 18.66 13.08
512 1000 18.54 26.34
1024 1000 20.24 48.25
2048 1000 28.21 69.25
4096 1000 26.15 149.38
8192 1000 38.54 202.73
16384 1000 76.05 205.46
32768 1000 163.81 190.77
65536 640 1009.48 61.91
131072 320 1889.57 66.15
262144 160 3378.61 74.00
524288 80 6482.03 77.14
1048576 40 12413.89 80.55
2097152 20 26927.25 74.27
4194304 10 51420.75 77.79
Benchmarking PingPing
( #processes = 3 )
#bytes #repetitions t[usec] Mbytes/sec

0 1000 36.25 0.00
1 1000 36.18 0.03
2 1000 35.27 0.05
4 1000 36.22 0.11
8 1000 35.68 0.21
16 1000 35.64 0.43
32 1000 40.97 0.74
64 1000 36.03 1.69
128 1000 37.14 3.29
256 1000 36.95 6.61
512 1000 41.42 11.79
1024 1000 41.53 23.51
2048 1000 45.01 43.40
4096 1000 53.52 72.99
8192 1000 74.20 105.29
16384 1000 119.03 131.27
32768 1000 804.83 38.83
65536 640 2710.05 23.06
131072 320 4648.75 26.89
262144 160 9305.66 26.87
524288 80 16600.91 30.12
1048576 40 31416.72 31.83
2097152 20 66321.05 30.16
4194304 10 140949.50 28.38
Benchmarking Sendrecv
( #processes = 3 )
#bytes #repetitions t_min[usec] t_max[usec] t_avg[usec] Mbytes/sec

0 1000 3196.36 3196.48 3196.42 0.00
1 1000 3192.01 3192.10 3192.05 0.00
2 1000 3191.57 3191.65 3191.60 0.00
4 1000 1752.64 1752.73 1752.68 0.00
8 1000 3191.40 3191.49 3191.44 0.00
16 1000 3151.97 3152.05 3152.01 0.01
32 1000 3191.39 3191.50 3191.43 0.02
64 1000 3191.93 3192.01 3191.97 0.04
128 1000 3151.95 3152.04 3151.99 0.08
256 1000 3191.09 3191.11 3191.10 0.15
512 1000 65.16 65.25 65.19 14.97
1024 1000 66.73 66.82 66.77 29.23
2048 1000 73.00 73.10 73.03 53.44
4096 1000 88.25 88.36 88.32 88.41
8192 1000 123.07 123.39 123.23 126.63
16384 1000 403.45 403.51 403.48 77.45
32768 1000 1612.22 1613.11 1612.56 38.75
65536 640 3139.85 3141.76 3140.72 39.79
131072 320 6213.04 6218.62 6216.49 40.20
262144 160 14945.15 14965.11 14957.61 33.41
524288 80 25781.81 25851.29 25824.07 38.68
1048576 40 50571.72 50852.00 50747.18 39.33
2097152 20 95722.25 96985.15 96486.37 41.24
4194304 10 200033.50 205010.80 202891.33 39.02
Benchmarking Exchange
( #processes = 3 )
#bytes #repetitions t_min[usec] t_max[usec] t_avg[usec] Mbytes/sec

0 1000 108.17 108.20 108.19 0.00
1 1000 107.15 107.30 107.21 0.04
2 1000 103.60 103.68 103.63 0.07
4 1000 99.47 99.66 99.57 0.15
8 1000 113.69 113.73 113.70 0.27
16 1000 113.98 114.03 114.00 0.54
32 1000 110.50 110.59 110.53 1.10
64 1000 109.39 109.40 109.40 2.23
128 1000 114.19 114.23 114.22 4.27
256 1000 109.90 110.01 109.95 8.88
512 1000 118.64 118.80 118.69 16.44
1024 1000 125.45 125.61 125.54 31.10
2048 1000 138.26 138.43 138.37 56.43
4096 1000 165.63 166.01 165.83 94.12
8192 1000 285.00 285.30 285.18 109.53
16384 1000 1540.05 1541.09 1540.61 40.56
32768 1000 3389.15 3389.70 3389.47 36.88
65536 640 9161.54 9162.99 9162.33 27.28
131072 320 15663.08 15669.69 15666.21 31.91
262144 160 28676.91 28705.62 28689.83 34.84
524288 80 47463.22 47510.55 47480.44 42.10
1048576 40 89626.13 89681.93 89662.33 44.60
2097152 20 189389.65 190777.55 190121.42 41.93
4194304 10 443464.90 445792.70 444611.27 35.89
Benchmarking Reduce
( #processes = 3 )
#bytes #repetitions t_min[usec] t_max[usec] t_avg[usec]

0 1000 0.11 0.12 0.11
4 1000 40.95 41.06 40.99
8 1000 42.00 42.02 42.01
16 1000 40.39 40.48 40.43
32 1000 39.56 39.59 39.58
64 1000 38.77 38.92 38.84
128 1000 42.94 43.12 43.04
256 1000 43.35 43.51 43.45
512 1000 47.02 47.17 47.08
1024 1000 50.30 50.53 50.42
2048 1000 57.98 58.24 58.13
4096 1000 82.22 82.49 82.32
8192 1000 184.73 185.17 184.88
16384 1000 548.34 549.54 548.96
32768 1000 1270.24 1271.06 1270.61
65536 640 4147.31 4151.49 4149.54
131072 320 7878.52 7902.08 7893.80
262144 160 15484.58 15521.51 15499.79
524288 80 28665.71 28894.01 28768.57
1048576 40 55463.03 56511.05 56019.19
2097152 20 111966.20 114332.80 113007.47
4194304 10 210619.10 224543.20 217639.97
Benchmarking Reduce_scatter
( #processes = 3 )
0 1000 138.99 139.05 139.02

4 1000 155.96 156.21 156.08
8 1000 159.82 159.96 159.87
16 1000 160.43 160.60 160.49
32 1000 164.65 164.73 164.70
64 1000 166.55 166.73 166.61
128 1000 170.18 170.37 170.27
256 1000 173.17 173.43 173.30
512 1000 183.45 183.59 183.53
1024 1000 151.40 151.58 151.51
2048 1000 162.12 162.19 162.17
4096 1000 180.51 180.67 180.57
8192 1000 219.36 219.53 219.46
16384 1000 384.03 384.60 384.35
32768 1000 1276.50 1277.21 1276.82
65536 640 2706.09 2708.63 2707.68
131072 320 7420.45 7424.29 7421.97
262144 160 15513.75 15533.39 15520.66
524288 80 29802.40 29826.89 29818.03
1048576 40 61424.03 61610.35 61486.67
2097152 20 118582.75 118951.20 118815.27
4194304 10 217162.40 220073.60 218998.80
Benchmarking Allreduce
( #processes = 3 )
0 1000 0.09 0.10 0.10

4 1000 118.03 118.15 118.08
8 1000 117.87 117.97 117.92
16 1000 117.77 117.85 117.80
32 1000 116.86 116.98 116.93
64 1000 116.82 116.94 116.90
128 1000 120.18 120.27 120.24
256 1000 124.87 124.96 124.91
512 1000 136.08 136.28 136.17
1024 1000 149.65 149.90 149.77
2048 1000 165.60 165.84 165.71
4096 1000 214.62 214.83 214.73
8192 1000 434.85 435.38 435.16
16384 1000 1294.25 1294.73 1294.44
32768 1000 3746.76 3748.43 3747.48
65536 640 10807.59 10811.00 10809.16
131072 320 22907.94 22919.36 22914.26
262144 160 60061.63 60085.31 60073.45
524288 80 97978.15 98097.34 98056.07
1048576 40 179311.80 179617.88 179415.07
2097152 20 340824.05 341427.65 341218.18
4194304 10 656198.00 666212.70 662068.57
Benchmarking Allgather
( #processes = 3 )

0 1000 0.15 0.16 0.15
1 1000 113.35 113.43 113.38
2 1000 113.11 113.23 113.16
4 1000 114.16 114.24 114.19
8 1000 111.47 111.53 111.50
16 1000 112.12 112.18 112.15
32 1000 112.80 112.93 112.88
64 1000 115.24 115.40 115.33
128 1000 117.71 117.75 117.73
256 1000 116.31 116.36 116.34
512 1000 123.77 123.97 123.88
1024 1000 130.92 130.98 130.94
2048 1000 145.96 146.21 146.11
4096 1000 192.89 193.13 192.99
8192 1000 535.32 535.77 535.61
16384 1000 1581.99 1582.78 1582.43
32768 1000 4077.44 4078.52 4077.98
65536 640 12404.02 12407.77 12405.57
131072 320 23314.54 23322.06 23318.29
262144 160 41735.94 42127.51 41996.05
524288 80 98304.08 98887.34 98690.51
1048576 40 158952.95 159321.28 159126.10
2097152 20 301434.10 306385.00 304542.93
4194304 10 608130.10 611835.50 609821.80
Benchmarking Allgatherv
( #processes = 3 )

0 1000 0.16 0.17 0.16
1 1000 141.45 141.58 141.52
2 1000 142.98 143.08 143.04
4 1000 142.17 142.19 142.18
8 1000 142.23 142.42 142.33
16 1000 142.45 142.58 142.53
32 1000 144.72 144.88 144.80
64 1000 146.23 146.23 146.23
128 1000 148.86 149.03 148.93
256 1000 150.52 150.64 150.59
512 1000 160.59 160.74 160.68
1024 1000 181.04 181.06 181.05
2048 1000 199.88 200.16 200.04
4096 1000 303.49 303.52 303.51
8192 1000 1078.45 1079.14 1078.71
16384 1000 2445.36 2446.80 2446.20
32768 1000 6208.50 6210.45 6209.28
65536 640 19117.73 19126.89 19121.86
131072 320 18690.44 18701.54 18697.77
262144 160 30760.87 30769.91 30763.97
524288 80 56258.27 56296.64 56272.46
1048576 40 114924.87 115078.62 114992.87
2097152 20 210129.10 211339.10 210598.00
4194304 10 464678.50 471773.30 469341.53
Benchmarking Alltoall
( #processes = 3 )

0 1000 138.75 138.82 138.78
1 1000 144.42 144.56 144.47
2 1000 140.12 140.30 140.20
4 1000 141.63 141.76 141.68
8 1000 143.21 143.34 143.26
16 1000 143.88 144.05 143.95
32 1000 141.33 141.42 141.39
64 1000 121.10 121.25 121.16
128 1000 134.80 134.85 134.82
256 1000 123.63 123.72 123.68
512 1000 137.11 137.31 137.21
1024 1000 141.79 141.94 141.85
2048 1000 159.00 159.33 159.16
4096 1000 212.16 212.60 212.34
8192 1000 776.61 777.39 777.05
16384 1000 2123.65 2124.52 2124.20
32768 1000 4562.88 4563.54 4563.31
65536 640 11177.27 11179.13 11178.04
131072 320 19933.91 19936.83 19935.28
262144 160 30336.55 30364.96 30349.18
524288 80 56461.93 56508.87 56478.91
1048576 40 101610.85 101782.75 101724.65
2097152 20 207691.30 208400.00 208136.57
4194304 10 434746.60 436072.50 435508.80
Benchmarking Bcast
( #processes = 3 )

0 1000 0.08 0.09 0.09
1 1000 36.78 36.82 36.80
2 1000 37.88 37.95 37.92
4 1000 36.72 36.83 36.78
8 1000 38.36 38.41 38.38
16 1000 37.83 37.87 37.85
32 1000 36.20 36.22 36.21
64 1000 36.98 37.09 37.04
128 1000 38.33 38.37 38.35
256 1000 38.47 38.50 38.48
512 1000 40.26 40.30 40.28
1024 1000 50.96 51.01 50.98
2048 1000 45.43 45.48 45.45
4096 1000 56.29 56.38 56.32
8192 1000 100.24 100.43 100.36
16384 1000 404.30 404.76 404.57
32768 1000 1076.04 1076.67 1076.42
65536 640 2649.60 2650.27 2649.94
131072 320 7783.21 7894.13 7856.71
262144 160 26137.14 26144.54 26139.93
524288 80 35217.28 35270.45 35238.20
1048576 40 54568.80 54697.53 54627.21
2097152 20 84842.70 85576.40 85275.55
4194304 10 172108.50 173921.00 172910.60
Benchmarking Barrier
( #processes = 3 )
#repetitions t_min[usec] t_max[usec] t_avg[usec]

1000 78.19 78.30 78.26
5.CONCLUSIONES Y OPINIÓN PERSONAL
Vamos a distinguir tres niveles en nuestras conclusiones: nivel casero,

nivel empresarial y nivel científico/académico.
A nivel casero ha quedado demostrado que no compensa la

instalación de un cluster de alto rendimiento del estilo de OpenMosix por
diversos motivos. El más importante de ellos es que se requiere unos
conocimientos de GNU/Linux , redes locales e informática en general como
para descartar su instalación/administración por parte de un usuario medio,
que debería invertir un tiempo bastante considerable en su aprendizaje.
Además, no se va a aprovechar el cluster como tal, ya que la mayoría

de las aplicaciones de uso diario no están diseñadas de forma paralela,
evitando las posibles migraciones entre distintos nodos. También cabe
destacar la dependencia de OpenMosix respecto al kernel, lo que te impide
actualizar el mismo asiduamente porque las nuevas versiones de
OpenMosix llevan varios meses de retraso frente a las nuevas versiones del
kernel. Esta diferencia se acrecenta aún más con la nueva rama 2.6 del
kernel para la que aún no hay parche de OpenMosix.
El espacio físico que se requiere para el montaje del cluster no está al

alcance de todos. Durante su instalación y montaje se necesitan
irremediablemente una pantalla para cada uno de los nodos, ya que no
resulta nada funcional compartir una pantalla para todos ellos. Una vez
conseguida la instalación completa, se puede llevar a cabo su
mantenimiento y administración desde una sola máquina mediante el uso
de SSH, ahorrándonos todo el espacio ocupado por las pantallas de los
nodos.
Al tratarse de un cluster de alto rendimiento, se requiere un uso

intensivo de las CPUs de los nodos de forma intensiva y constante, lo cual
obliga a disponer de un sistema de refrigeración/ventilación que lo permita.
Esto se traduce en ventiladores más grandes y rápidos, disipadores más
amplios y la utilización de pasta térmica para dificultar el calentamiento del
core del microprocesador.
Por otra parte, la reutilización de los ordenadores antiguos y su

hardware es una gran idea tanto a nivel ecológico como económico. Como
ya se comentó anteriormente respecto a los mainframes,también montar un
cluster de ordenadores convencionales es más económico que comprar un
PC o Mac con una capacidad de cálculo equivalente.
A nivel empresarial, la decisión de la instalación de un cluster de alto

rendimiento depende del campo en el que trabaje la empresa. Salvo en
contadas excepciones como puedan ser las empresas de animación, que
requieran de un grid de renderización en 3D o las que trabajen con
simulaciones que requieran manejar una gran cantidad de datos, no se le
daría un uso eficiente y rentable.
Se requiere la contratación de personal cualificado para su instalación
y mantenimiento, por lo que se genera un gasto innecesario por parte del
empresario. Además el uso del sistema operativo GNU/Linux en las
empresas es todavía limitado aunque se está experimentando un pequeño
“boom” en España a raíz de la introducción del software libre en las
administraciones de algunas comunidades autónomas.
En cambio, la inversión en clusters de alta disponibilidad sí es rentable

si se piensa en tener servidores de páginas web, de correo electrónico, de
bases de datos y, al fin y al cabo, cualquier aplicación que requiera un
funcionamiento permanente.
Por último, a nivel científico-académico es donde realmente se

aprovecha esta tecnología, ya que en estas instituciones es donde
realmente se trabaja con programas que pueden ser paralelizables, no sólo
algoritmos matemáticos sino también en campos como la biología, química,
la medicina, etc.
El dinero que se destina a investigación siempre es limitado y cada

vez se requieren máquinas de cálculo más potentes y avanzadas. La
mayoría de los problemas de cálculo matemático se podrían solucionar en
un tiempo inferior al que obtenemos al realizarlos en ordenadores
individuales.
El problema de la complejidad en cuanto a su instalación y

mantenimiento se ve aquí minimizado, dado que cualquier institución
científica o académica que se precie dispone de profesionales capacitados
para ello.
Respecto al futuro de OpenMosix cabe señalar que se presenta

bastante esperanzador, ya que planean sacar un parche para la rama 2.6
del kernel con el problema de la memoria compartida y la migración de
threads corregidos, así como numerosas mejoras en cuanto a balanceo de
carga y utilización de recursos, dando lugar a un paquete de software capaz
de competir con otros clusters con software propietario a todos los niveles.
En cuanto a la opinión personal, el montaje del cluster no ha sido tan

complicados como nos esperábamos y donde más problemas hemos
encontrado ha sido en la compilación de los programas y benchmark ya que
todos exigían parches y personalizaciones.
6.REFERENCIAS
6.1 WEBS
http://www.openmosix.org
Web oficial del proyecto OpenMosix. Documentación extraída del
F.A.Q (Frecently Asked Questions) y del HowTo oficiales.
http://www.openmosixview.org
Monitor para el cluster openmosixview y documentación sobre el
mismo.
http://openmosix.gulo.org
Benchmark PMB y documentación en formato PDF
http://es.tldp.org/Manuales-LuCAS/manual-openMosix-
ES/howTo_openMosixES_html/
Manual en castellano sobre clustering en OpenMosix
http://www.nas.nasa.gov/Software/NPB/
Benchmark NPB y documentación sobre el mismo.
http://www.cisiar.org/proyectos/cisilia/home_es.php
Cisilia y documentación sobre dicho programa.
http://openssi.org
Documentación sobre los clusters SSI
http://www.hispacluster.org/
Documentación diversa sobre clustering
http://howto.ipng.be/openMosixWiki/index.php/work%
20smoothly
Información sobre los diversos programas que funcionan en clusters
OpenMosix.
http://www.beowulf.org
Web oficial del proyecto Beowulf
http://www.linux-ha.org
Proyecto sobre clusters de alta disponibilidad en Linux
6.2 LIBROS
Título: Redes locales. Conceptos básicos

Autor: José Félix Rábago
Editorial: Anaya multimedia
Año: 1993
ISBN: 84-7614-216-1
Título: Manual Práctico Redes Área Local

Autor: Rafael Moreno Vozmediano
Editorial: Belenguer
Año: 2001
ISBN: 84-95281-12-0
6.3 REVISTAS
Revista: Linux Free Magazine Nº 3

Editorial: Kernel Produktion
Año: 2002
6.4 OTROS
Hemos utilizado con asiduidad el buscador Google y las páginas

MAN de ayuda de cada programa para conocer a fondo los argumentos
y opciones utilizados, así como su funcionamiento. También hemos
hecho uso de listas de correo (la lista oficial de OpenMosix y la lista
oficial del Hacklab de Vallecas) que trataban sobre el tema.
7.AGRADECIMIENTOS
Este trabajo ha sido realizado por nosotros (Abián y AcidBorg),

pero hubiese sido imposible sin la aportación desinteresada de
diversas personas. Por ello, queremos darle las gracias a Soy_HeatoN
por aportar posibles programas paralelizables, a la infinita paciencia de
Death Master a la hora de hacer de “redireccionador de e-mails
humano” entre Soy_Heaton y nosotros, a Carlos García Sánchez por
proporcionarnos los benchmarks NAS (aunque al final nos falló a la hora
de poner la nota...), a los familiares de Abián por el transporte de los
equipos, al compañero de piso de AcidBorg por aguantar que
sacrificásemos su conexión a internet en pos de la fiabilidad de los
resultados de los tests y muy especialmente a la novia de AcidBorg por
tener que aguantar oir hablar del dichoso cluster a todas horas.
A todos ellos: GRACIAS
¡Sonreíd para la foto!

Openmosix

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Openmosix

Diunggah oleh

Hak Cipta:

Format Tersedia

Por Abián & AcidBorg

Copyright (c) 2004 Abián & AcidBorg

Permission is granted to copy, distribute and/or modify this document

GNU Free Documentation License

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.

The purpose of this License is to make a manual, textbook, or other

This License is a kind of "copyleft", which means that derivative works

1. APPLICABILITY AND DEFINITIONS

A "Modified Version" of the Document means any work containing the

The "Invariant Sections" are certain Secondary Sections whose titles

A "Transparent" copy of the Document means a machine-readable copy,

Examples of suitable formats for Transparent copies include plain ASCII

A section "Entitled XYZ" means a named subunit of the Document whose

If you publish or distribute Opaque copies of the Document numbering

You may add a section Entitled "Endorsements", provided it contains

You may add a passage of up to five words as a Front-Cover Text, and a

The author(s) and publisher(s) of the Document do not by this License

In the combination, you must combine any sections Entitled "History" in

You may make a collection consisting of the Document and other

You may extract a single document from such a collection, and

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate

If the Cover Text requirement of section 3 is applicable to these

Translation is considered a kind of modification, so you may distribute

If a section in the Document is Entitled "Acknowledgements",

Each version of the License is given a distinguishing version number.

5. CONCLUSIONES Y OPINIÓN PERSONAL

Es difícil encontrar una definición formal de cluster y más aún definirlo

"Un cluster es una clase de arquitectura de computador paralelo que

Un nodo es cada uno de los ordenadores que forma parte de un

¿Qué características tiene un cluster?

1. Debe estar compuesto de 2 o más nodos.

Esto excluye a los SMP, los Mainframes y a un sólo nodo, ya que no

Un Mainframe es supercomputador con varios procesadores

¿Clusters homogéneos o clusters heterogéneos?

No existe nada que obligue a un cluster a ser homogéneo, es decir,

En definitiva, no importa que los nodos sean diferentes, ya que la

¿Qué software necesita un cluster?

A nivel de sistema se necesita un parche o modificación del kernel del

A nivel de aplicación se utiliza software generado apoyándose en

Las principales ventajas entre un cluster y un superordenador como

En primer lugar, el precio de un cluster con una capacidad de cálculo

La posibilidad de reutilizar máquinas antiguas para la construcción del

La escalabilidad es una característica de un sistema que consiste en

La escalabilidad ideal es de complejidad lineal, es decir, si un sistema

En OpenMosix la escalabilidad permite un cluster con un número

¿Qué tipos de clústers existen?

Existen 3 tipos de clusters de acuerdo a su utilidad: de alta

Un cluster de alta disponibilidad (High Availability) consisten en varias

La aplicación más común para este tipo de diseño son servidores de

Normalmente se utilizan en la resolución de algoritmos científicos, en

Estos clusters necesitan tener un único reloj de sistema conjunto. No

Todos los clusters mencionados anteriormente hacen uso de un

Si hablamos de la transparencia de los clusters,nos topamos con 2

Por una parte, los clusters no transparentes requieren una

Dentro de los clusters no transparentes destaca el proyecto Beowulf.

También cabe destacar aquí las librerías para el paso de mensajes en

Por otra parte, en los clusters transparentes el programador no

Un ejemplo de clusters transparentes son Mosix y OpenMosix.

Por procesamiento paralelo se entiende la capacidad de utilizar varios

¿Qué problemas se pueden resolver mediante paralelización?

Los programas convencionales no cuentan con ninguna manera de