FACULTAD DE INGENIERIA

ESCUELA DE INFORMATICA

Implementaci
on de un cl
uster
Beowoulf usando Mosix

Autores:
a
Yolanda Aucapin
rdenas
Juan Diego Ca
Andres Garca
Luis Lazo Pablo Sinchi

January 5, 2017

Docente:

squez
Angel
Va

Abstract
Existen ciertas aplicaciones que demandan grandes cantidades de
recursos para su ejecuci
on; una solucion viable en este caso es la implementaci
on de un cl
uster, para lo cual se requiere analizar la tecnologa y lenguajes de programacion necesarios para su correcta implementaci
on. Existen diferentes tipos de cl
usters, en este caso se considera el Beowulf que permite la implementacion en base a computadores
sencillos de caractersticas heterogeneas interconectados mediante una
red. El software a utilizar para la gestion y control del cl
uster es Mosix
que es una extensi
on del kernel Linux y varias libreras de apoyo como
Parallel Python. Las pruebas de rendimiento seran realizadas mediante un algoritmo que eval
ua una integral definida y el renderizado de
im
agenes utilizando la aplicacion Blender.

Introducci
on

Actualmente en diversas areas como la investigacion se hace uso de aplicaciones complejas, las cuales requieren grandes cantidades de recursos computacionales (CPU, memoria, etc.) para ser ejecutadas de manera adecuada
y obtener un resultado en un tiempo aceptable.
Para hacer frente a este tipo de aplicaciones, la tecnologa de cl
uster
permite integrar recursos de diversos computadores, que una vez integrados
se comportan como si se tratara de un solo computador de altas capacidades.
Cuando se requiere ejecutar una aplicacion, este sera dividida en tareas hacia
todos los computadores que conforman el cl
uster, de esta manera el tiempo
requerido para obtener una respuesta se reduce.
Las aplicaciones a ejecutar dependen del lenguaje de programacion y la
tecnologa empleada en el cl
uster; en algunos casos como MPI (Interfaz de
paso de mensajes) se requiere que la distribucion hacia los computadores
integrados al cluster sea programada dentro de la aplicacion; por otra parte
se puede permitir el acceso directo a recursos ubicados en diferentes zonas
geograficas y tener nodos dedicados a una tarea especfica como se realiza en
Grid Computing.
En el presente trabajo se hace uso del software Mosix, el cual es una
extension del Kernel Linux para formar un cl
uster mediante una red LAN
y medir su rendimiento en ejecuciones en serie y en paralelo, tanto con una
aplicacion de desarrollo propio, como una aplicacion existente en la web.
1

Cl
usters

En 1950 IBM presento el primer cl

uster denominado SAGE para la Fuerza
Aerea de los Estados Unidos de Norte America, este se basaba en la arquitectura MI T Whirlwind, la cual permita programar en paralelo. El hardware
estaba constituido de simples tubos de vaco, comunes en esta epoca.
Este cl
uster estaba formado basicamente de un conjunto de sistemas
autonomos, cooperando para emitir alarmas que advertan de posibles intrusiones al espacio aereo de Norte America.
El avance tecnologico tanto en hardware como en software aseguro el
futuro de la computacion en cl
uster. Para finales de la decada de los 70
se contaba con procesadores de mayor robustez, ademas la conectividad de
elementos que permitan formar el cl
uster se haba beneficiado de la tecnologa Ethernet, la cual haca posible conectar estaciones de trabajo. En
esta misma epoca AT&T lanzaba el sistema UNIX multiusuario, con capacidad de memoria virtual, MPI llego a ser el estandar de programacion para
aplicaciones en paralelo y adoptado por la gran mayora de vendedores de
sistemas de cl
uster.
En la actualidad existen diferentes tipos de cl
usters, dependiendo de la
tarea que se requiere realizar, entre algunas aplicaciones se destaca el campo
industrial, academico y cientfico [1].
A continuacion se describen tres tecnologas actualmente utilizadas para realizar tareas de clustering:

2.1

Cl
usters

En terminos generales un cl
uster es cualquier conjunto de elementos independientes integrados mediante alg
un medio, para coordinar un comportamiento
cooperativo, al igual que en los sistemas biologicos. Los cl
usters estan conectados entre s mediante un tipo de red, programadas para soportar acceso
concurrente, y para compartir recursos en tareas determinadas o trabajos
pesados, donde se requiere mayor capacidad y se puede aprovechar la integracion de m
ultiples CPUs, trabajando sobre la misma tarea [1].
2.1.1

Componentes generales

Los principales componentes de un cl

uster son:
2

1. Nodos: Son cada una de las maquinas que se encuentran interconectadas para formar el cl
uster.
2. Almacenamiento: El sistema de almacenamiento requerido puede ser
interno o externo y hacer uso de diversas tecnologas.
3. Sistema operativo: Debe soportar multiprocesamiento y facilitar la
administracion por parte del usuario.
4. Conexi
on de red: Se requiere que los nodos puedan comunicarse
entre si, esto se logra mediante conexiones de red.
5. Middleware: Es software que hace posible la comunicacion entre aplicaciones, hardware y otros sistemas operativos.
6. Ambiente de programaci
on paralela: Permiten hacer uso de los
diferentes recursos con los que se cuenta dentro del cl
uster.
2.1.2

Clasificaci
on

Los cl
uster pueden clasificarse en base a sus caractersticas en:
HPCC (High Performance Computing Clusters): Son clusters
de alto rendimiento que poseen grandes capacidades de procesamiento
y memoria.
HACC (High Availability Computing Clusters): Un cluster de
alta disponibilidad brinda alta tolerancia a fallos, lo cual deriva en una
confiabilidad permanente.
HPCC (High Througput Computing Clusters): Tienen la eficiencia como principal premisa, en este caso el rendimiento para un
objetivo especfico es primordial.

2.2

Cloud Computing

Se trata de un paradigma orientado a ofrecer servicios a traves de internet, los

cuales pueden ser software, plataformas de desarrollo, etc. Basicamente este
paradigma busca brindar servicios a quienes sobre demanda, sin la necesidad
de invertir grandes cantidades de dinero desarrollando su propia infraestructura tecnologica, cuyo mantenimiento por lo general resulta ser costoso. Las
3

empresas por lo general requieren acceder a sus datos independientemente del

lugar en el que se encuentren, Cloud Computing justamente busca brindar
estas facilidades mediante el accesos por internet [2].
Cloud Computing puede brinda software, plataformas e infraestructura
como un servicio, a continuacion se describen cada uno de ellos:
2.2.1

Sotware as service (SaaS)

En este tipo de servicio el cliente usa las aplicaciones que contrata al proveedor. Dichas aplicaciones se encuentran alojadas en las infraestructuras cloud
del proveedor y el usuario no tendra ning
un control sobre ellas. Un ejemplo
de este tipo de servicio es Google Docs.
2.2.2

Plataform as service (PaaS)

En este modelo los proveedores ofrecen todo lo necesario para soportar el

ciclo de vida completo de la construccion y puesta en marcha de aplicaciones y servicios web, sin que se requiera descargar e instalar software en los
equipos de los desarrolladores. Los usuarios de PaaS no tienen control sobre
la plataforma ni la infraestructura subyacente, pero si sobre sus aplicaciones.
Ejemplos de este tipo de tecnologa son: Google App Engine, Heroku.
2.2.3

Infraestructure as service (IaaS)

Al utilizar un servicio IaaS el usuario tendra mas control que en PaaS, pero
tendra que encargarse de la gestion de la infraestructura, es decir, el usuario
puede elegir que tipo de instancias desea usar (Linux o Windows), as como
la capacidad de memoria o procesador de cada una de las maquinas. El
hardware es transparente al usuario ya que se maneja utilizando maquinas
virtuales. Como ejemplos de IaaS se tienen: Amazon Web Service (AWS).

2.3

Grid Computing

Consiste en una arquitectura distribuida de computadores conectada a una

red para resolver un problema complejo, en esta arquitectura, los servidores
o computadores personales corren tareas independientes. El proposito de
dicha arquitectura es integrar m
ultiples recursos localizados en diferentes
zonas geograficas, para lograr un objetivo com
un dentro de la organizacion,
a diferencia de un cl
uster, en el cual los trabajos se distribuyen a los nodos;
4

en la arquitectura Grid Computing cada nodo esta dedicado a realizar una

tarea determinada o aplicacion, as tambien esta arquitectura tiende a ser
mucho mas heterogenea y dispersa geograficamente [3].

2.4

An
alisis comparativo de las tecnologas

Las tres tecnologas descritas anteriormente al parecer se enfocan en el uso

de un conjunto de computadores con fines especficos, pero de cada una de
ellas posee caractersticas y usos particulares.
Una clara diferencia entre cl
uster y Cloud Computing puede establecerse
si se consideran los objetivos que persiguen cada uno. El objetivo de un
cl
uster plantea la mejora del rendimiento y la disponibilidad de un servicio
mediante la interconexion de un conjunto de maquinas individuales formando
un u
nico recurso informatico integrado, mientras el objetivo de Cloud Computing se centra en la prestacion de servicios.
En el caso de Grid Computing y cl
uster conceptualmente son similares,
la diferencia entre ellos esta en la forma en que hacen uso de los recursos de
los nodos, ya que un grid aprovecha los tiempos muertos de procesamiento y
los elementos ociosos, mientras que un cl
uster utiliza balance de cargas para
realizar una distribucion adecuada hacia los nodos. Otra diferencia notable
esta en la ubicacion de los nodos ya que en un grid se tienen nodos dispersos
por cualquier parte del mundo, mientras en un cl
uster los nodos se encuentran
ubicados en un solo lugar.
La manera en que Cloud Computing es distribuido y utilizado constituye
una gran diferencia frente a la computacion en grid y cl
uster, ya que para
acceder a un servicio de cloud se requiere un proveedor como intermediario
y una vez contratado el servicio no se requiere la instalacion de un software
adicional pues todo esta almacenado en la nube y puede ser accedido mediante internet. En cambio para la computacion en grid y cl
uster no se tienen
proveedores y se requiere la instalacion de software que permita realizar la
gestion y monitoreo.
Las diferencias entre estas tecnologas son evidentes, pero cada una de
ellas posee puntos fuertes que le permiten hacer frente a distintos problemas;
por ejemplo: Cloud Computing nos permite contratar aplicaciones, plataformas o infraestructura seg
un se requiera, esto puede ser utilizado en el campo
de negocios, desarrollo de aplicaciones, etc. La tecnologa de cl
uster en cambio permite, al unir varias maquinas para obtener grandes capacidades de
procesamiento, ejecutar procesos complejos como modelos predictivos. Por
5

otra parte Grid Computing al aprovechar tiempos muertos de computadores

que pueden estar en cualquier lugar del mundo, hace posible ejecutar procesos que por lo general se encuentran en el campo cientfico, como es el caso
del proyecto SETI (Search for Extraterrestrial Intelligence), el cual intenta
encontrar vida extraterrestre intelligente.

Cl
uster Beowulf

La familia de cl
usters Beowulf, son sistemas de computo paralelo que se
basan en ordenadores personales interconectados mediante una red como
Ethernet, con el fin de formar una maquina de grandes capacidades que
emula el comportamiento de un supercomputador de multiprocesamiento.
La tecnologa Beowulf fue soportada por la comunidad Linux, razon por
la cual existen casi en todas las distribuciones Linux, parches que permiten
crear este tipo de cl
uster como es el caso de Mosix.

3.1

Arquitectura

La arquitectura de un cl
uster Beowulf se basa en multicomputadores, de los
cuales uno es usado como nodo principal denominado Maestro y los demas
son llamados Esclavos, conectados mediante una red, dicha arquitectura
se describe en la figura 1.
Nodo maestro:
Debido a que el cl
uster se comporta como una
sola maquina, el nodo maestro se utiliza como una consola y es el que
controla todo el cl
uster.
Nodo esclavo: Ejecuta las tareas asignadas por el nodo maestro. El
hardware de este tipo de nodos es simple, ya que no es necesario que
tengan teclado, mouse, ni monitor, inclusive pueden ser configurados
sin disco duro, lo mnimo que se requiere es un procesador, memoria y
tarjeta de red.
Red: Se deben considerar componentes que proporcionen una velocidad adecuada.
Software: Beowulf utiliza como sistema operativo alguna de las distribuciones de linux, adicionalmente se requiere software que realice la
6

distribucion de procesos mediante la red desde el nodo maestro hacia

los esclavos.

Figure 1: Arquitectura de un cl
uster Beowulf

3.1.1

Ventajas

Escalabilidad: El aumentar las capacidades del cl

uster unicamente
se requiere a
nadir mas nodos al sistema, esto a su vez permite que el
sistema pueda construirse en fases.
Relaci
on rendimiento/costo: El rendimiento de un cl
uster Beowulf
puede llegar a ser mas alto que una supercomputadora estandar, sin
los costos que este involucra. Un superordenador independiente podra
costar millones de dolares frente a unos pocos miles para construir un
cl
uster Beowulf. Esta ventaja es a
un mayor cuando se utiliza un sistema
operativo gratuito como lo es Linux.
Integraci
on de nuevas tecnologas: La agrupacion utilizada en
un cl
uster Beowulf proporciona un camino inmediato a la integracion
de las u
ltimas tecnologas, incluso las que nunca pueden ser adoptadas
por otras formas de sistemas informaticos de alto rendimiento.

 Alta disponibilidad: En un cl
uster Beowulf si un nodo falla, el
cl
uster en general seguira funcionando, esto es posible ya que esta formado por muchos nodos de configuraciones similares.
Facilidad de configuraci
on: Una vez que un nodo ha sido correctamente configurado se puede hacer una imagen del sistema y ponerlo
en los otros nodos.
3.1.2

Desventajas

Programaci
on m
as difcil: Los programas a ejecutar deben ser
escritos especficamente para sistemas paralelos con la finalidad de
aprovechar los recursos del cl
uster. Si el codigo esta mal escrito puede
eliminar todas las ventajas.
Limitaci
on de la red:
la velocidad de la red.

La velocidad del cl
uster se ve limitada por

Lenguajes de programaci
on para computaci
on
en paralelo

La programacion para computacion en paralelo hace referencia al uso de

varios procesadores que trabajan conjuntamente para dar solucion a una
tarea en com
un. El trabajo es dividido para cada uno de los procesadores
el cual realiza una parte del problema al poder intercambiar datos mediante
una red de interconexion o memoria.
El objetivo de este tipo de programacion es resolver problemas complejos
que no podran ser ejecutados en un solo procesador o el resultado tardara
demasiado tiempo en obtenerse.
En 1988 McGraw y Axelrod identificaron cuatro formas mediante las
cuales se puede desarrollar software para computacion paralela:
1. Extender un compilador existente con la finalidad de que pueda traducir
programas secuenciales a paralelos.
2. Extender un lenguaje existente con nuevas operaciones que permitan a
los usuarios expresar el paralelismo.

3. Agregar una nueva capa de lenguaje paralelo sobre un lenguaje secuencial existente.
4. Definir totalmente un nuevo lenguaje paralelo as como su compilador.
A continuacion se presentan dos ejemplos de lenguajes que cumplen el
punto 3 antes mencionado:
1. CODE: Es un lenguaje visual, que permite transformar un programa
secuencial en paralelo. El programa paralelo es representado mediante
un grafo dirigido, donde los datos fluyen a traves de los arcos que
conectan los nodos. Los programas secuenciales pueden estar escritos
en cualquier lenguaje de programacion y CODE producira programas
paralelos para una gran variedad de arquitecturas.
2. LINDA: Es un lenguaje basado en C y Fortran por lo cual puede
combinarse con estos lenguajes. Linda implementa el paralelismo utilizando un peque
no n
umero de operaciones simples sobre memoria virtual compartida para crear y coordinar procesos paralelos asignando
una distribucion maestro/esclavo para el algoritmo.
Como ejemplos de lenguajes que cumplen con el punto 4, es decir definen
totalmente un nuevo lenguaje y compilador, se pueden mencionar:
1. Chapel (Cray): Es un lenguaje paralelo emergente cuyo objetivo es
hacer que la programacion paralela sea mas productiva y de acceso general. Ofrece soporte a estructuras de control tradicionales como if-else,
for-loop, do-while, etc, pero ademas establece soporte para estructuras
de control con paralelismo implcito.
2. X10: Es un lenguaje de programacion paralela orientado a objetos e
influenciado principalmente por Java por lo cual da soporte a todos sus
tipos basicos, para la sincronizacion de las fases de ejecucion se hace
uso de relojes que son una clase definida dentro de X10, estos alertan
cuando todas las actividades han terminado y se puede continuar a la
siguiente fase.

Software para hacer benchmarking

Un benchmark (comparador de rendimiento) es un conjunto de procedimientos que permiten evaluar el rendimiento de un ordenador. Una de las mejores
9

formas para medir el rendimiento de un sistema en el mundo real consiste

en ejecutar aplicaciones y cronometrizar los tiempos requeridos para dicha
ejecucion.
En base a esto, en el presente trabajo se presenta el dise
no y configuracion
de un cl
uster mediante el software Mosix, el cual sera sometido a pruebas de
rendimiento utilizando:
Una aplicacion desarrollada con la finalidad de medir el rendimiento
del cl
uster, a cual tiene como objetivo resolver una integral definida
de forma paralela, haciendo uso de todos los nodos disponibles en el
cl
uster.
Una aplicacion disponible en la web y que requiera altas cantidades de
recursos.
Dichas aplicaciones seran ejecutadas en forma secuencial y paralelo con
la finalidad de visualizar las mejoras obtenidas con la ejecucion en paralelo
dentro del cl
uster.

Dise
no

La arquitectura del cl
uster estara formada por un nodo maestro y tres nodos
esclavos, conectados mediante una red LAN.
Las caractersticas de cada uno de los nodos se describe en la tabla de la
figura 2

Figure 2: Caractersticas de los nodos que formaran el cl

uster

10

Configuraci
on

7.1

Mosix

Mosix es un paquete de software para Linux que transforma maquinas independientes en un cl

uster que funciona como un u
nico sistema y realiza un
balanceo de carga para un proceso particular a traves de los nodos que lo
conforman.
El objetivo de Mosix es mejorar el kernel de Linux a
nadiendo capacidades
de computacion en cl
uster y proporcionando medios para gestionar de manera
eficiente los recursos del mismo.
Mosix es implementado como una capa de virtualizacion del sistema operativo que provee a los usuarios y sus aplicaciones una imagen de sistema
u
nico con un entorno de tiempo de ejecucion de Linux, permitiendo ejecutar
aplicaciones sin la necesidad de modificarlas o enlazarlas con alguna librera
especial [4].
7.1.1

Principales caractersticas

Transparencia de la red: Para todas las operaciones relacionadas

con la red, los programas en el nivel de aplicacion son provistos con
una maquina virtual que hace ver el cl
uster como una sola maquina.
Cuando un proceso emite una llamada al sistema el kernel local se
encargara de gestionar las operaciones en toda la red para ejecutar
dicha llamada.
Migraci
on preventiva de procesos: Se puede migrar un proceso de
forma transparente desde cualquier usuario hacia otro nodo disponible
en cualquier momento. La transparencia en la migracion hace referencia
que los aspectos funcionales del comportamiento del sistema no deben
ser alterados como resultado de la migracion.
Balanceo din
amico de carga: Este se lleva a cabo mediante la
migracion dinamica de procesos. Para dar soporte a la migracion de
procesos, la configuracion de hardware debe consistir en cl
usters de
procesadores homogeneos [5].
Control descentralizado: Logra un alto grado de disponibilidad al
no utilizar la relacion maestro-esclavo entre los nodo. Cada nodo es ca11

paz de operar como un sistema independiente y tomar sus propias decisiones de control; esta propiedad permite una configuracion dinamica,
donde los nodos pueden unirse o abandonar la red con interrupciones
mnimas [6].
7.1.2

Migraci
on de procesos

En Mosix cada uno de los procesos tiene un Unique Home Node (UHN) en el
cual fue creado [7]. Un proceso migrado a un nodo remoto utiliza los recursos
de este siempre que le sea posible, pero interact
ua con su entorno de usuario
mediante UHN.
Para implementar la migracion de procesos, el proceso a migrar es divido
en dos contextos:
1. Contexto de usuario (remote): Encapsula el proceso cuando este
se encuentra ejecutandose en el nivel de usuario. Contiene el codigo
del programa, datos y registros del proceso. Este contexto puede ser
migrado.
2. Contexto de sistema (deputy): Encapsula el proceso cuando se
ejecuta en el kernel. Contiene la descripcion de los recursos a los que
esta conectado el proceso, y la pila del kernel necesario para la ejecucion del codigo del sistema. Mientras el proceso puede ser migrado
entre diferentes nodos, el deputy nunca sera migrado, debido a su dependencia con el UHN.
En la figura 3 a la izquierda presenta un proceso regular en Linux, mientras que a la derecha el proceso es dividido y la parte remote es migrada a
otro nodo.

Figure 3: Un proceso local y un proceso migrado [8]

12

La transparencia de ubicacion existente durante la ejecucion de un proceso

en Mosix se logra mediante el envo de llamadas al sistema dependientes
del sitio al deputy en el UHN. Estas llamadas son una forma asncrona de
interaccion entre los dos contextos del proceso.
Todas las llamadas al sistema que son ejecutadas por el proceso son interceptadas por la capa de enlace del nodo remoto. Si la llamada es independiente del sitio es ejecutada localmente; de lo contrario la llamada se enva al
deputy que la ejecuta en nombre del proceso en la UHN y luego devuelve los
resultados al nodo remoto, el cual contin
ua ejecutando el codigo del usuario.
7.1.3

Ventajas

Mosix opera de forma transparente al usuario y permite la ejecucion

de aplicaciones tanto secuenciales como paralelas sin tener en cuenta
donde se estan ejecutando.
Los algoritmos Mosix son descentralizados, cada nodo es maestro para
los procesos que ha creado a nivel local y un esclavo para los procesos
migrados de otros nodos.
Mejora el rendimiento general mediante una mejor utilizacion de los
recursos de toda la red y haciendo que el sistema sea mas facil de usar.
7.1.4

Desventajas

Requiere que cada uno de los nodos que conformaran el cl

uster disponga
del mismo sistema operativo y version de Mosix.
Es un software propietario, la version gratuita provee soporte unicamente para seis nodos.
7.1.5

Instalaci
on y configuraci
on

La instalacion y posterior configuracion de Mosix requiere los siguientes pasos:

1. Instalacion del sistema operativo, en este caso Ubuntu Server 16 de 64
bits.
2. Actualizar repositorios mediante apt-get install update
13

3. Ejecutar apt-get install build-essetial

4. Ejecutar apt-get cmake
5. Crear los siguientes directorios para Mosix
mkdir /etc/mosix
mkdir /etc/mosix/var
6. Descargar el paquete Mosix mediante el comando wget www.mosix.cs.hjui.ac.il/mos4/mosix4.4.4.tbz
7. Instalar el paquete descargando utilizando tar ?xjvt mosix-4.4.4.tbz
8. Configurar la interfaz de red del nodo de tal manera que se encuentre
dentro de la red LAN, para ello se debera editar el archivo /etc/network/interfaces,
tal como se muestra en la figura 4

Figure 4: Parametros para configuracion de red

9. Ejecutar el comando mosconf y configurar los siguientes parametros:
N
umero de nodos pertenecientes al cl
uster
Direccion IP del nodo
Direccion IP inicial de los nodos
7.1.6

Pruebas de conectividad y levantamiento de nodos existentes en el cl

uster

Para comprobar el correcto funcionamiento del cl

uster se ha desarrollado
un codigo simple en el lenguaje de programacion Python, haciendo uso de
la librera Parallel Python, el cual realiza un sondeo de los nodos que se
encuentran ejecutando el servicio de procesamiento de Parallel Python.
14

Si la instalacion y configuracion ha sido realizada correctamente se obtiene una respuesta por cada nodo que haya establecido conexion (figura 5).
Ademas se muestran las direcciones IP de cada uno de los nodos que han
retornado una respuesta y el n
umero de procesadores disponibles en cada
uno de ellos.

Figure 5: Verificacion de funcionamiento del cl

uster

7.2
7.2.1

Aplicaciones
Lenguaje de programaci
on

Para el desarrollo de la aplicacion a ejecutar sobre el cl

uster se ha hecho uso
del lenguaje de programacion Python en su version 3.x, en conjunto con las
libreras Parallel Python version 1.6.4.4.
Python: Es un lenguaje de programacion interpretado, multiparadigma,
que utiliza tipado dinamico, ademas de ser multiplataforma. Posee una licencia de codigo abierto, y forma parte por defecto en las distribuciones mas
comunes de Linux.
Librera Parallel Python: La estructura basica de procesamiento
para esta librera esta definida por los siguientes elementos:
Imports: Realiza la importacion de todos los modulos o libreras
externas al script y requeridas para su funcionamiento.
Funciones a ser enviadas a los nodos: Es necesario definir todas
las funciones que seran utilizadas en el procesamiento del problema
paralelizable, incluyendo funciones de asistencia o secundarias.
L
ogica del servidor: Corresponde a la codificacion de cada una de
las funciones mencionadas.
15

 Recuperaci
on de resultados de los nodos: Los resultados de la
ejecucion de cada job o unidad de trabajo se almacena en variables.
La combinacion de estos elementos permite implementar un algoritmo
capaz de resolver las exigencias especficas de un problema dado. En este
caso particular, se ha implementado un algoritmo de calculo matematico
enfocado hacia dos formas de ejecucion: serie y paralelo.
7.2.2

Aplicaci
on desarrollada: C
alculo de una integral definida

El algoritmo implementado permite realizar la evaluacion de una integral

definida para una funcion matematica dada, en un intervalo de abscisas establecidas mediante parametrizacion al script.
La tecnica utilizada para resolver el problema de calculo es la conocida
como ?Metodo del trapecio?, y consiste en establecer un n
umero de divisiones
(lo mas grande posible), para un intervalo de abscisas a y b. En cada una
de las subdivisiones se toman los extremos y se eval
ua su valor funcional,
sumando dichos resultados y dividiendolos entre dos. Este resultado es multiplicado por la amplitud de dicha subdivision (delta X), generando as el
area bajo la curva para ese subintervalo delta X.

Figure 6: Descripcion del calculo del area bajo la curva

El resultado de la evaluacion de la integral correspondera al area bajo la

curva de toda la funcion en el intervalo [a,b], y sera calculado como la sumatoria del area bajo la curva de cada una de las subdivisiones delta X. Cabe
mencionar que la precision de este metodo dependera del n
umero de divisiones establecidas, siendo un mayor n
umero de divisiones el factor para una
mejor precision.
16

7.2.3

Programa de terceros: Blender

Para medir el rendimiento del cl

uster es necesario ejecutar una aplicacion que
requiera altas cantidades de recursos, para ello se ha optado por el software de
renderizado de objetos 3D y animaciones Blender, el cual es un software libre,
multiplataforma y dedicado al iluminado, renderizado, animacion y creacion
de graficos tridimensionales, ademas incluye edicion de audio y sincronizacion
de video.

7.3
7.3.1

Resultados y discusi
on
Evaluaci
on de la integral definida

Para el analisis del rendimiento del cl

uster, el programa desarrollado ha sido
ejecutado en dos escenarios:
1. En serie: Un solo equipo (ejecucion local).
2. En paralelo: Tres equipos (ejecucion local y dos nodos remotos)
La funcion a evaluar es f(x) = Sin (x), en intervalos de longitud . Puesto
que es conocido que el area bajo la curva entre 0 y es igual a 2, y entre y
2 es igual a -2, se han establecido los siguientes intervalos para la ejecucion
del script de calculo, en trabajos separados:
[0, ]
[2, 3]
[4, 5]
[6, 7]
[8, 9]
Las figuras 7 y 8 presentan la ejecucion de la aplicacion en serie y paralelo
respectivamente. El resultado obtenido para ambos casos es igual a 10.
La tabla presentada en la figura 9 muestra la diferencia en el rendimiento
en ambos escenarios.
Las relaciones presentadas en la figura 9 indican que la ejecucion en serie
es 93% mas lenta que la ejecucion en paralelo. Cabe mencionar que los resultados obtenidos pueden variar por factores como la velocidad de conexion de
17

Figure 7: Ejecucion de la aplicacion en serie

Figure 8: Ejecucion de la aplicacion en paralelo

la red LAN que comunica a los nodos del cl
uster y las capacidades establecidas para cada uno de los nodos.
18

Figure 9: Comparativa de rendimiento en serie y paralelo

Adicionalmente, el a
nadir mas nodos al cluster puede influir favorablemente en los resultados, disminuyendo el tiempo de ejecucion radicalmente.
Por otro lado, esta mejora puede ser observada u
nicamente en problemas
extensos que requieren grandes cantidades de tiempo de ejecucion, pues en
problemas muy cortos resultara desfavorable por el tiempo perdido en la
migracion de trabajos a los nodos del cluster.
7.3.2

Renderizado de im
agenes utilizando Blender

En este caso se hara uso de un archivo llamado blacksmith.blend que contiene

una escena de la cual se elige una parte llamada 04 06, la cual es la imagen
de una carroza.
Para llevar a cabo el renderizado se realizaran los siguientes pasos:
1. Configurar los parametros marcados en la figura 10, los cuales hacen
referencia a la resolucion (640x480), rango de escenas y formato de
salida de las imagenes a generar (.jpg).
2. Realizar el renderizado en base al script almacenado en el mismo directorio de la escena como render.gz, este recibe cuatro parametros:
Escena a renderizar
Primera imagen del rango de imagenes usadas para el render

Ultima
imagen del rango de imagenes usadas para el render
N
umero de nodos en los que se va a ejecutar el renderizado
Con estos parametros se analiza el total de imagenes por nodo y realiza
la distribucion respectiva hacia los distintos nodos. En este caso se
generan 231 imagenes en formato .jpg.
19

Figure 10: Configuracion de parametros previo al renderizado

La ejecucion del renderizado sera realizado tanto en serie como en paralelo con la finalidad de medir el rendimiento del cl
uster. La figura
11 presenta la ejecucion del renderizado sobre un solo nodo (en serie),
mientras en la figura 12 se realiza sobre 4 nodos (en paralelo).

Figure 11: Ejecucion del renderizado con 1 solo nodo

20

Figure 12: Ejecucion del renderizado utilizando 4 nodos

Como se puede observar en las figuras 11 y 12 existe una diferencia de

20 segundos en las ejecuciones, en este caso la diferencia no es notable
por la cantidad de nodos involucrados, en caso de tener mas nodos el
tiempo optimizado sera mayor.
3. Las imagenes generadas como resultado de la ejecucion de los comandos
anteriores se presenta en la figura 13
4. Las imagenes obtenidas en el punto anterior seran convertidas en video
con un formado .avi, utilizando la funcion mencoder que realiza la union
de las imagenes en video (figura 14); debido a que esta es una funcion
basica no requiere grandes cantidades de tiempo o recursos. tal como
se muestra en las figura 15.
5. Como resultado de la ejecucion del comando mencoder se obtiene el
video .avi presentado en la figura 16

21

Figure 13: Imagenes obtenidas al finalizar el renderizado con Blender

Figure 14: Conversion a formato .avi utilizando mencoder

22

Figure 15: Tiempo requerido para la conversion de las imagenes a video

Figure 16: Conversion de imagenes jpg a video .avi

23

Conclusiones
Mediante la ejecucion de la evaluacion de una integral definida tanto en
serie como en paralelo, se ha podido demostrar que cuando esta se realiza utilizando los nodos disponibles en el cl
uster existe una mejora considerable en el rendimiento, lo cual evidencia la utilidad de un cl
uster
para procesamiento de aplicaciones que requieren grandes cantidades
de recursos.
Mosix constituye una herramienta sumamente u
til a la hora de construir
una arquitectura de cl
uster ya que el programador no debe preocuparse
de distribuir las tareas entre los distintos nodos, sino que esta se realizara de forma automatica mediante la migracion de procesos entre
los nodos.
Al formar un cl
uster descentralizado Mosix ofrece una gran ventaja, ya
que permite que cada uno de los nodos sea maestro para los procesos
creados localmente y servidor para los procesos migrados. Ademas
puede brindar un gran aporte en centros de investigacion donde se
requiere ejecutar procesos que demandan altas cantidades de recursos.
En particular, resulta sumamente importante conocer las ventajas de
la utilizacion de la computacion distribuida con un cl
uster Beowulf
frente a una supercomputadora para la resolucion de problemas complejos, siendo las mas importantes el reducido costo de la infraestructura frente al elevado costo de una supercomputadora, y por otro lado
la facilidad de extender las capacidades del cl
uster conforme aumenta
la demanda del problema que se este tratando sin mayor dificultad, e
incluso permitiendo la adicion de nodos al cl
uster en caliente.

24

References
[1] T. Sterling, G. Bell, and K. B. Janusz, Beowulf cluster computing with
linux (scientific and engineering computation), 2001.
[2] A. Huth and J. Cebula, The basics of cloud computing (2011).
[3] I. Berstis, Redbooks paper, Fundamentals of Grid Computing, pp. 1
28, 2002.
[4] J. P. Caballero, L. Gutierrez, J. Echaiz, and J. R. Ardenghi, Mosix2: la
version grid de mosix para linux-2.6, in IX Workshop de Investigadores
en Ciencias de la Computacion, 2007.
[5] A. Barak and R. Wheeler, MOSIX: An integrated unix for multiprocessor
workstations. International Computer Science Institute, 1988.
[6] A. Barak, O. Laden, and Y. Yarom, The now mosix and its preemptive
process migration scheme, Bulletin of the IEEE Technical Committee on
Operating Systems and Application Environments, vol. 7, no. 2, pp. 511,
1995.
[7] M. R. Tera and S. Kota, Infrastructure for load balancing on mosix
cluster.
[8] A. Barak, O. Ladan, and A. Shiloh, Scalable cluster computing with
mosix for linux, Proc. 5-th Annual Linux Expo, vol. 100, 1999.

25