1

Universidad Católica de Temuco

Facultad de Ciencias e Ingeniería
Escuela de Informática
Ingeniería Civil en Informática

SISTEMAS DISTRIBUIDOS
“ESTRUCTURACION DE UN CLUSTER BEOWULF”

Miguel Abarca Castro

Prof. Alejandro Mellado G.

Temuco, 24 de Noviembre 2008

 2

RESUMEN

               En muchas ramas de la ciencia, la complejidad de los problemas que se estudian requiere 
contar con acceso a una máquina que sea capaz de desarrollar varios miles de millones de
operaciones por segundo para esto la tecnología de Cluster nos dan una excelente solución.

En el desarrollo de este informe veremos los elementos que componen un cluster así como 
asi como las consideraciones que se deben tener en cuenta al momento de construir uno. 

Básicamente se hablara del cluster BEOWULF, sus componentes y parte de la configuración 
de uno con clientes de clase DISK­LESS.
 3

INDICE
Introducción                 
                
               
               
               
               
               
               
               
               
               
    5

I. ¿Que es un cluster?
1.1. Definición                
               
               
               
               
               
               
               
               
               
    6
1.2. Beneficios de la Tecnología Cluster             
               
               
               
               
               
               
    7
1.3. Clasificación de los Clusters           
               
               
               
               
               
               
               
    8
1.4  Componentes de un Cluster             
               
               
               
               
               
               
               
    9
1.5. Uso de los Clusters             
               
               
               
               
               
               
               
               
    10
1.5.1. Clusters en Aplicaciones Científicas         
               
               
               
               
               
    10
1.5.2. Clusters en Aplicaciones Empresariales    
               
               
               
               
               
    11

II. Cluster BEOWULF
2.1. Hardware                 
                
               
               
               
               
               
               
               
               
    12
2.2. Software    
               
               
               
               
               
               
               
               
               
               
    14
2.3. Clasificaciones de BEOWULF       
               
               
               
               
               
               
               
    15
2.3.1. Clase I                   
                
               
               
               
               
               
               
               
    15
2.3.2. Clase II   
              
               
               
               
               
               
               
               
               
    16

III. Elementos de un Cluster BEOWULF
3.1 Disco          
               
               
               
               
               
               
               
               
               
               
    17
3.1.1. Clientes sin disco (Disk­less)        
               
               
               
               
               
               
    17
3.1.2. Instalación Local Completa en los Clientes           
               
               
               
               
    17
3.1.3. Instalación NFS Estándar             
               
               
               
               
               
               
    18
3.1.4. Sistemas de Archivos Distribuidos            
               
               
               
               
               
    18
3.2. Memoria                 
                
               
               
               
               
               
               
               
               
    18
3.3. Procesador             
               
               
               
               
               
               
               
               
               
    19
3.4. Simetric MultiProcessor (SMP)      
               
               
               
               
               
               
               
    19
3.6. Massively Parallel Processing (MPP)          
               
               
               
               
               
               
    20
3.6. Red            
               
               
               
               
               
               
               
               
               
               
    20
 4

IV. Implementación y Construcción
4.1. Consideraciones     
               
               
               
               
               
               
               
               
               
    21
4.2. HARDWARE
4.2.1. Comunicación entre nodos           
               
               
               
               
               
               
    22
4.2.2. Consideraciones para equipos sin disco duro        
               
               
               
               
    22
4.3. SOFTWARE
4.3.1. Instalación y arranque del sistema operativo en el servidor central                
     23
4.3.2. Instalación y conf. de software de inicialización en los nodos (diskless)       23
4.3.2.1. Asignación automática de dirección IP        
              
              
              
    24
4.3.2.2. Servidor de archivos de arranque TFTP      
              
              
              
    25
4.3.2.3. Cargador de arranque           
              
              
              
              
              
    26
4.3.2.4 Creación del kernel para los nodos                
               
              
              
    26
4.3.3. Organización de sistemas de archivos para NFS        
              
              
              
    27
4.3.4. Servidor NFS   
             
              
              
              
              
              
              
              
    30
4.3.5. Configuración por nodo
4.3.5.1. Montaje de los sistemas de archivos remotos          
              
              
    31
4.3.5.2. Configuración cliente NIS                
               
              
              
              
    32
4.3.6. Archivo /etc/hosts        
              
              
              
              
              
              
              
    34

CONCLUSION        
              
              
              
              
              
              
              
              
              
              
    35

REFERENCIAS      
              
              
              
              
              
              
              
              
              
              
    36

ANEXO         
              
              
              
              
              
              
              
              
              
              
              
    37
 5

Introducción 

El   surgimiento   de   plataformas   computacionales   de   comunicación   y   procesamiento  

estándares de bajo costo, le ha brindado la oportunidad a los programadores académicos de 
crear herramientas computacionales (sistemas de operación, compiladores, depuradores ) del 
dominio público o de costo razonable. Esta realidades permiten la implantación de códigos 
paralelizados   sobre   este   tipo   de   plataformas   obteniendo   un  rendimiento  competitivo   en  
relación a equipos paralelos especializados cuyos costos de operación y mantenimiento son 
elevados. 

Una de las herramientas de más auge en la actualidad son los llamados cluster Beowulf, los 
cuales   presentan   diversas   capacidades   para   el   cómputo   paralelo   con   un   relativo   alto  
rendimiento. 
 6

I.  ¿Que es un Cluster?
1.1. Definición
El término cluster se aplica a los conjuntos o conglomerados de computadoras construidos 
mediante la utilización de componentes de hardware comunes y que se comportan como si 
fuesen una única computadora. Hoy en día juegan un papel importante en la solución de  
problemas de las ciencias, las ingenierías y del comercio moderno.

La   tecnología   de   clusters   ha   evolucionado   en   apoyo   de   actividades   que   van   desde  

aplicaciones de supercómputo y software de misiones críticas, servidores Web y comercio 
electrónico, hasta bases de datos de alto rendimiento, entre otros usos.

El  cómputo con  clusters  surge como resultado  de la convergencia  de varias  tendencias  

actuales   que   incluyen   la   disponibilidad   de   microprocesadores   económicos   de   alto  
rendimiento   y   redes   de   alta   velocidad,   el   desarrollo   de   herramientas   de   software   para  
cómputo   distribuido   de   alto   rendimiento,   así   como   la   creciente   necesidad   de   potencia  
computacional para aplicaciones que la requieran.
Simplemente, cluster es un grupo de múltiples computadores unidos mediante una red de 
alta velocidad, de tal forma que el conjunto es visto como un único ordenador, más potente 
que los comunes de escritorio.

Clusters son usualmente empleados para mejorar el rendimiento y/o la disponibilidad por  
encima de la que es provista por un solo computador típicamente siendo más económico que 
computadores individuales de rapidez y disponibilidad comparables.

De un cluster se espera que presente combinaciones de los siguientes servicios:
● Alto Rendimiento
Un  cluster de alto rendimiento  es un conjunto de computadores que está diseñado  
para dar altas prestaciones en cuanto a capacidad de cálculo.
● Alta Disponibilidad
Es un conjunto de dos o más máquinas que se caracterizan por mantener una serie de 
servicios compartidos y por estar constantemente monitorizándose entre sí.
● Equilibrio de la carga
Un cluster de balanceo de carga o de cómputo adaptativo está compuesto por uno o 
más computadores (llamados nodos) que actúan como frontend del cluster, y que se 
 7

ocupan   de   repartir   las   peticiones   de   servicio   que   reciba   el   cluster,   a   otros 

computadores del cluster que forman el back­end de éste.
● Escalabilidad
La escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que 
indica   su   habilidad   para,   o   bien   manejar   el   crecimiento   continuo   de   trabajo   de 
manera   fluida,   o   bien   para   estar   preparado   para   hacerse   más   grande   sin   perder 
calidad en los servicios ofrecidos

La construcción de los computadores del cluster es más fácil y económica debido a su  
flexibilidad: pueden tener todos la misma configuración de hardware y sistema operativo  
(cluster homogéneo), diferente rendimiento pero con arquitecturas y sistemas operativos  
similares (cluster semi­homogéneo), o tener diferente hardware y sistema operativo (cluster 
heterogéneo)., lo que hace más fácil y económica su construcción.

Para que un cluster funcione como tal, no basta solo con conectar entre sí los computadores, 
sino que es necesario proveer un sistema de manejo del cluster, el cual se encargue de  
interactuar con el usuario y los procesos que corren en él para optimizar el funcionamiento.

1.2. Beneficios de la Tecnología Cluster
Las   aplicaciones   paralelas   escalables   requieren:   buen   rendimiento,   baja   latencia,  
comunicaciones que dispongan de gran ancho de banda, redes escalables y acceso rápido a 
archivos. Un cluster puede satisfacer estos requerimientos usando los recursos que tiene  
asociados a él.

Construir un cluster puede aportar importantes ventajas en gran variedad de aplicaciones  
y ambientes:

● Incremento   de   velocidad   de   procesamiento   ofrecido   por   los   clusters   de   alto 

rendimiento.
● Incremento del número de transacciones o velocidad de respuesta ofrecido por los 
clusters de balanceo de carga. 
● Incremento   de   la   confiabilidad   y   la   robustez   ofrecido   por   los   clusters   de 
alta disponibilidad.
 8

La   tecnología   cluster   permite   a   las   organizaciones   incrementar   su   capacidad   de  

procesamiento usando tecnología estándar, tanto en componentes de hardware como  de  
software que pueden adquirirse a un costo relativamente bajo.

1.3. Clasificación de los Clusters
El término cluster tiene diferentes connotaciones para diferentes grupos de personas. Los 
tipos de clusters, establecidos en base al uso que se de a los clusters y los servicios que 
ofrecen, determinan el significado del término para el grupo que lo utiliza. Los clusters 
pueden clasificarse con base en sus características. Se pueden tener clusters de alto 
rendimiento (HPC – High Performance Clusters), clusters de alta disponibilidad (HA – High 
Availability) o clusters de alta eficiencia (HT – High Throughput).

● Alto Rendimiento (HPC): Son clusters en los cuales se ejecutan tareas que requieren de 
gran capacidad computacional, grandes cantidades de memoria, o ambos a la vez. El 
llevar a cabo estas tareas puede comprometer los recursos del cluster por largos periodos 
de tiempo.

● Alta Disponibilidad (HA): Son clusters cuyo objetivo de diseño es el de proveer 
disponibilidad y confiabilidad. Estos clusters tratan de brindar la máxima disponibilidad 
de los servicios que ofrecen. La confiabilidad se provee mediante software que detecta 
fallos y permite recuperarse frente a los mismos, mientras que en hardware se evita tener 
un único punto de fallos.

● Alta Eficiencia (HT): Son clusters cuyo objetivo de diseño es el ejecutar la mayor 
cantidad de tareas en el menor tiempo posible. Existe independencia de datos entre las 
tareas individuales. El retardo entre los nodos del cluster no es considerado un gran 
problema.

Los   clusters   pueden   también   clasificar   como   Clusters   de   IT   Comerciales   (Alta  

disponibilidad, Alta eficiencia) y Clusters Científicos (Alto rendimiento). A pesar de las  
discrepancias a nivel de requerimientos de las aplicaciones, muchas de las características de 
las arquitecturas de hardware y software, que están por debajo de las aplicaciones en todos 
 9

estos clusters, son las mismas. Más aún, un cluster de determinado tipo, puede también  
presentar características de los otros.

1.4. Componentes de un Cluster
En general, un cluster necesita de varios componentes de software y hardware para poder  
funcionar. Que son los siguientes:
● Nodos:  Pueden ser simples computadores, sistemas multi procesador o estaciones de 
trabajo (workstations). En informática, de forma muy general, un nodo es un punto de 
intersección o unión de varios elementos que confluyen en el mismo lugar.
Bajo el contexto de cluster tenemos dos tipos de nodos, que son:
Nodos Dedicados:  los nodos no disponen de teclado, mouse ni monitor y su uso está 
exclusivamente dedicado a realizar tareas relacionadas con el cluster. 
Nodos no dedicados: los nodos disponen de teclado, mouse y monitor y su uso no está 
exclusivamente dedicado a realizar tareas relacionadas con el cluster, el cluster hace uso 
de los ciclos de reloj que el usuario del computador no esta utilizando para realizar sus 
tareas.
● Almacenamiento:El   almacenamiento   puede   consistir   en   una   NAS,   una   SAN,   o 
almacenamiento interno en el servidor. El protocolo más comúnmente utilizado es NFS 
(Network File System), sistema de ficheros compartido entre servidor y los nodos. Sin 
embargo existen sistemas  de ficheros  específicos  para clusters  como  Lustre (CFS)   y 
PVFS2.
● Sistemas   Operativos:  Debe   ser   multiproceso,   multiusuario.   Otras   características 
deseables   son   la   facilidad   de   uso   y   acceso   y   permitir   además   múltiples   procesos   y 
usuarios.
● Conexiones de Red:  Los nodos de un cluster pueden conectarse mediante una simple 
red Ethernet con placas comunes (adaptadores de red o NICs), o utilizarse tecnologías 
especiales de alta velocidad como Fast Ethernet, Gigabit Ethernet, Myrinet, Infiniband, 
SCI, etc.
● Middleware: Es un software que generalmente actúa entre el sistema operativo y las 
aplicaciones con la finalidad de proveer a un cluster lo siguiente:
✔ Una interfaz única de acceso al sistema, denominada SSI (Single System Image), 
 10

la cual genera la sensación al usuario de que utiliza un único ordenador muy 
potente; 
✔ Herramientas para la optimización y mantenimiento del sistema: migración de 
procesos,  checkpoint­restart  (congelar   uno   o   varios   procesos,   mudarlos   de 
servidor y continuar su funcionamiento en el nuevo host), balanceo de carga, 
tolerancia a fallos, etc.; 
✔ Escalabilidad:   debe   poder   detectar   automáticamente   nuevos   servidores 
conectados al cluster para proceder a su utilización. 

Existen diversos tipos de middleware, como por ejemplo: MOSIX, OpenMOSIX, Condor, 
OpenSSL, etc.

● Protocolos de Comunicación y servicios
● Aplicaciones
● Ambientes   de   Programación   Paralela:  Los   ambientes   de   programación   paralela 
permiten implementar algoritmos que hagan uso de recursos compartidos: CPU (Central 
Processing Unit), memoria, datos y servicios.

1.5. Uso de los Clusters
1.5.1. Clusters en Aplicaciones Científicas

• Se suelen caracterizar por ser aplicaciones computacionalmente intensivas 
• Sus   necesidades   de   recursos   son   muy   importantes   en   almacenamiento   y 
especialmente memoria. 
• Requieren nodos y sistemas dedicados, en entornos HPC y HTC. 
• Suelen   estar   controlados   los   recursos   por  planificadores   tipo  Maui   y  gestores   de 
recursos tipo PBS. 
• Son en muchas ocasiones códigos legacy, difíciles de mantener, ya que los dominios 
de aplicación suelen ser difícilmente paralelizables. 
Ejemplos:   Simulaciones   (earth   simulator),   genómica   computacional,   predicción 
meteorológica,   simulación   de   corrientes   y   vertidos   en   el   mar,   aplicaciones   en 
química computacional.
 11

1.5.2. Clusters en Aplicaciones Empresariales

• Suelen ser aplicaciones no especialmente intensivas computacionalmente, pero que 
demandan alta disponibilidad y respuesta inmediata, con lo que los servicios se están 
ejecutando continuamente y no controlados por un sistema de colas 

• Es usual que un sistema provea varios servicios. Una primera aproximación  para 
realizar una distribución 

• Del trabajo es separar los servicios:
• Un servidor web con la BD en un nodo, el contenedor EJB en otro y el servidor 
de páginas web en otro constituye un 
• claro ejemplo de distribución en el ámbito empresarial. 
• Otra aproximación es instalar una aplicación web en un clúster squid como 
proxy­caché,   apache/tomcat   como   servidor   web   de   aplicaciones   web, 
memcached como caché de consultas a la base de datos y mysql como base de 
datos. Estos servicios pueden estar replicados en varios nodos del clúster. 

• Ejemplos: flickr, wikipedia y google. 
 12

II. Cluster BEOWULF
Beowulf no es un paquete de software especial, ni una nueva topología de red ni un núcleo 
modificado. Beowulf es una tecnología para agrupar computadores basados en el sistema  
operativo Linux para formar un supercomputador virtual paralelo. En 1994 bajo el patrocinio 
del proyecto ESS del Centro de la Excelencia en Ciencias de los Datos y de la Informacion 
del Espacio (CESDIS), Thomas Sterling y Don Becker crearon el primer cluster Beowulf  
con fines de investigación. 
A continuación se describe los componentes de hardware y software que conforman un  
cluster Beowulf. 

2.1. Hardware
Beowulf posee una arquitectura basada en multicomputadores el cual puede ser utilizado  
para computación paralela. Este sistema consiste de un nodo maestro y uno o más nodos  
esclavos conectados a través de una red ethernet u otra topología de red. Esta construido con 
componentes de hardware comunes en el mercado, similar a cualquier PC capaz de ejecutar 
Linux,   adaptadores   de   Ethernet   y   switches   estándares.   Como   no   contiene   elementos  
especiales, es totalmente reproducible. 

Una de las diferencias principales entre Beowulf y un cluster de estaciones de trabajo (COW, 
cluster   of   workstations)   es   el   hecho   de   que   Beowulf   se   comporta   más   como   una   sola  
máquina que muchas estaciones de trabajo. En la mayoría de los casos los nodos esclavos no 
tienen monitores o teclados y son accedidos solamente vía remota o por terminal serial. 

El nodo maestro controla el cluster entero y presta servicios de sistemas de archivos a los 
nodos esclavos. Es también la consola del cluster y la conexión hacia el mundo exterior. Las 
máquinas grandes de Beowulf pueden tener más de un nodo maestro, y otros nodos  
dedicados   a   diversas   tareas   específicas,   como   por   ejemplo,   consolas   o   estaciones   de  
supervisión. En la mayoría de los casos los nodos esclavos de un sistema Beowulf son  
estaciones simples. Los nodos son configurados y controlados por el nodo maestro, y hacen 
solamente lo que éste le indique. En una configuración de esclavos sin disco duro, estos  
incluso no saben su dirección IP hasta que el maestro les dice cuál es. 
 13

Arquitectura del Cluster Beowulf

Entre de las configuraciones de hardware utilizadas para armar este tipo de cluster cluster 
son los arreglos de discos o RAID. RAID quiere decir “Redundance Array Inexpansibles  
Disk'”, que en español significa “arreglo redundante de discos no expandibles”, es decir un 
arreglo construido a  partir de discos de mediana capacidad que se encuentran comúnmente 
en el mercado. 

Generalmente los dispositivos1  utilizados para construir un arreglo RAID son particiones  
hechas sobre la agrupación de varios discos. Comúnmente las particiones que forman parte 
del RAID se encuentran en diferentes discos. 

Dependiendo   de   las   características   que   se   le   quiera   dar   al   arreglo   de   discos   (RAID),  

podemos clasificar los arreglos por niveles o modos. Estos niveles o modos son: 

• Modo Líneal: Es la combinación de dos o más discos, para formar un disco físico , es 
decir los discos son concatenados para formar un disco con mayor capacidad, pero al 
escribir   en   el   arreglo,   primero   se   llena   el   primer   disco,   después   el   segundo   y   así 
sucesivamente, en forma líneal. 
• Modo   RAID­0:  También   es   llamado   modo   stripe.   Es   similar   al   modo   anterior,   sin 

1 la palabra dispositivo, puede referirse a una unidad de disco completa, a una partición de disco o incluso a un 
conjunto de particiones y de discos enteros agrupados en un arreglo RAID. 
 14

embargo no actúa como una concatenación de discos, sino que realiza un balance de 
carga I/O entre los discos, como resultado se obtiene un alto rendimiento. Por ello esta 
configuración es seleccionada cuando se desea mayor velocidad de lectura y escritura. 
• Modo   RAID­1:  En   este   modo   presenta   redundancia   de   datos,   es   decir   que   la 
información se dúplica en todos los dispositivos que forman parte del RAID, por lo tanto 
la capacidad del arreglo es igual a la capacidad del disco más pequeño (el denominador 
común más bajo). En otras palabras: realizar un RAID­1 con un disco de 100 MB y otro 
de 1 GB no se puede considerar como una buena idea. 
• Modo RAID­4: En este nivel, un disco se encarga de almacenar información de paridad 
en un disco y escribe los datos en otro disco. 
• Modo RAID­5: Este nivel es similar a lo anterior, con la diferencia que el almacenaje de 
la paridad se hace de forma distribuida, es decir que la información de la paridad es 
almacenada entre los dispositivos que forman parte del arreglo. 
Se recomienda que los dispositivos que van a formar parte del arreglo, sean de la misma  
capacidad.

2.2. Software
Beowulf   utiliza   como   sistema   operativo   cualquier   distribución   Linux.   Además   usa  
bibliotecas  de pase de mensajes como PVM (Parallel Virtual Machine), MPI (Message  
Pasing Interface)2. En sus inicios, Beowulf empleaba la distribucion de linux Slackware,  
ahora   la   mayoría   de   los   cluster   ha   migrado   a   la   distribución   de   RedHat   por   su   fácil  
administración del sistema. 

Sin   lugar  a duda  los   cluster  presenta  una  alternativa importante  para  varios   problemas  
particulares, no solo por su economía, sino también porque pueden ser diseñados y ajustados 
para aplicaciones específicas. 

Una de las alternativas para manejar los recursos de un cluster beowulf es MOSIX.

Mosix   es   una   herramienta   desarrollada   para   sistemas   tipo   UNIX,   cuya   característica  
resaltante es el uso de algoritmos compartidos, los cuales están diseñados para responder al 
instante a las variaciones en los recursos disponibles, realizando el balanceo efectivo de la 
2 Bibliotecas de programación paralela
 15

carga en el cluster mediante la migración automática de procesos o programas de un nodo a 
otro en forma sencilla y transparente. 
El uso de Mosix3 en un cluster de PC's hace que éste trabaje de manera tal, que los nodos 
funcionan como partes de un solo computador. El principal objetivo de esta herramienta es 
distribuir la carga generada por aplicaciones secuenciales o paralelizadas. 

Una aproximación de balanceo de carga es realizada por los usuarios a la hora de asignar los 
diferentes procesos de un trabajo paralelo a cada nodo, habiendo hecho una revisión previa 
de forma manual del estado de dichos nodos. 

Los paquetes utilizados generalmente para tal labor son PVM y MPI. Este tipo de software, 
dispone de herramientas para la asignación inicial de procesos a cada nodo, sin considerar la 
carga existente en los mismos ni la disponibilidad de la memoria libre de cada uno. Estos 
paquetes corren a nivel de usuario como aplicaciones ordinarias, es decir son incapaces de 
activar otros recursos o de distribuir la carga de trabajo en el cluster dinámicamente. La  
mayoría de las veces es el propio usuario el responsable del manejo de los recursos en los 
nodos y de la ejecución manual de la distribución o migración de programas. 

A diferencia de estos paquetes, Mosix realiza la localización automática de los recursos  
globales disponibles y ejecuta la migración dinámica “on line”' de procesos o programas  
para asegurar el aprovechamiento al máximo de cada nodo. 

2.3. Clasificaciones de BEOWULF

Para establecer las diferencias entre los distintos tipos de sistemas Beowulf se presenta la 
siguiente clasificación: 

2.3.1. Clase I

Son   sistemas   compuestos   por  máquinas   cuyos   componentes   cumplen   con   la   prueba   de  
certificación "Computer Shopper" lo que significa que sus elementos son de uso común, y 
pueden ser adquiridos muy fácilmente en cualquier tienda distribuidora. De esta manera,  
3 Esta   tecnología   basada   en   Linux,   permite   realizar   balanceo   de   carga   para   procesos  particulares   en   un   cluster.  
Aumenta así la capacidad y velocidad de cómputo, pero, internamente tan sólo balancea la carga de las tareas en 
varias máquinas.
 16

estos clusters no están diseñados para ningún uso ni requerimientos en particular. 

2.3.2. Clase II

Son   sistemas   compuestos   por   máquinas   cuyos   componentes   no   pasan   la   prueba   de  

certificación "Computer Shopper" lo que significa que sus componentes no son de uso  
común y por tanto no pueden encontrarse con la misma facilidad que los componentes de 
sistemas   de  la  clase  anterior.  De  tal  manera,  pueden   estar   diseñados   para  algún   uso   o  
requerimiento en particular. Las máquinas ubicadas en esta categoría pueden presentar un 
nivel de prestaciones superior a las de la clase I. 
 17

III. Elementos de un Cluster BEOWULF
A la hora de construir un cluster Beowulf es necesario tener en cuenta diversos factores para 
el diseño del mismo para tomar decisiones que contribuyan al mejor desenvolvimiento de la 
máquina según nuestros propósitos. 

Los diferentes puntos que se deben estudiar en el diseño de un cluster Beowulf son los  
siguientes. 

3.1 Disco
Existen   varios   métodos   para   configurar   los   medios   de   almacenamiento   en   un   cluster  
Beowulf, los cuales difieren en rendimiento, precio y facilidades en la administración. 

3.1.1. Clientes sin disco (Disk­less)
Los nodos esclavos o clientes no poseen disco duro interno y toman todos los sistemas de 
archivos a través de la red. Es el nodo maestro el que proporciona a través de NFS los  
sistemas de archivos para los nodos esclavos. 

La principal ventaja de esta configuración es la facilidad en la administración del cluster ya 
que al agregar un nuevo nodo sólo hay que modificar unos archivos en el servidor. Además, 
proporciona un alto nivel de escalabilidad. 

La desventaja de tener clientes o esclavos sin disco es que el tráfico NFS se incrementa.  
Dependiendo de la red instalada esta puede ser una configuración poco adecuada para el  
cluster. 

3.1.2. Instalación Local Completa en los Clientes
Todo el software, tanto el sistema operativo como las aplicaciones, son instaladas en los  
discos internos de cada nodo cliente. Esta configuración reduce a cero el tráfico NFS para 
obtener el sistema operativo o cualquier otra aplicación por parte de los nodos esclavos. 
 18

3.1.3. Instalación NFS Estándar
Esta configuración es el punto medio de las dos anteriores. El sistema operativo se encuentra 
en los discos internos de los nodos esclavos y estos obtienen los directorios hogar de los  
usuarios y los sistemas de archivos que contienen las aplicaciones, a través de NFS, desde el 
nodo maestro. 

3.1.4. Sistemas de Archivos Distribuidos
Los sistemas de archivos son aquellos que son compartidos por todos los nodos, es decir,  
cada nodo posee un pedazo del sistema de archivos lo cual incrementa la velocidad en los 
accesos a la información debido a la presencia de más  de un dispositivo físico para el  
manejo de los datos. Sin embargo, esta configuración esta en fase experimental y por esta 
razón no es recomendada. 

3.2. Memoria
La selección de la cantidad de memoria depende de dos factores primordialmente: 

• Los recursos económicos con que se cuentan
• Los requerimientos de memoria de las aplicaciones que se ejecutarán en el cluster

La razón principal para contar con una capacidad de memoria razonable es evitar que las  
aplicaciones   necesiten   de   áreas   de  swap  para   continuar   con   su   ejecución   normal.  
Intercambiar localidades de memoria hacia el área de  swap  reduce considerablemente el  
rendimiento de los programas. Se debe tomar en cuenta que la configuración para un cluster 
Disk­less no es posible contar con particiones destinadas para memoria virtual debida a la 
ausencia de discos locales, lo cual impone una razón de peso para instalar memoria RAM 
suficiente. 

La   velocidad   de   la   memoria   también   es   importante.   Memoria   de   accesos   lento   puede  

convertirse en un cuello de botella a la hora de ejecutar aplicaciones con altas exigencias de 
este recurso. 
 19

3.3. Procesador
Los   clusters   generalmente   son   construidos   con   procesadores   Alpha   o   Intel   x86.   La  
utilización de otro tipo de procesador es permitido, sin embargo, no se consideran de uso 
común,   ya   que   se   elimina   una   de   las   principales   características   de   Beowulf   (uso   de  
componentes   comunes),   la   cual   permite   reemplazar   de   forma   fácil   y   con   bajos   costos  
cualquier componente del sistema. 

3.4. Simetric MultiProcessor (SMP)
Las máquinas con más de un procesador son utilizadas comúnmente en clusters Beowulf  
debido a la gran capacidad de prestaciones que proporcionan. Una de las principales ventajas 
en la utilización de SMP, además del incremento de poder, es la reducción de la cantidad de 
tarjetas de red y por supuesto el tráfico en la red. 

Estructura SMP

Debido a que SMP comparte globalmente la memoria RAM, tiene solamente un espacio de 
memoria, lo que simplifica tanto el sistema físico como la programación de aplicaciones.  
Este espacio de memoria único permite que un  Sistema Operativo con Multiconexión 
(multithreaded operating system) distribuya las tareas entre varios procesadores, o permite 
que una aplicación obtenga la memoria que necesita para una simulación compleja. La  
memoria globalmente compartida también vuelve fácil la sincronización de los datos.
 20

3.5. Massively Parallel Processing (MPP)
El Procesamiento masivamente paralelo es otro  diseño de procesamiento paralelo. Para  
evitar los cuellos de botella en el bus de memoria,  MPP no utiliza memoria compartida. En 
su lugar, distribuye la memoria RAM entre los procesadores de modo que se semeja a  una 
red (cada procesador con su memoria distribuida asociada es similar a un computador dentro 
de una red de procesamiento distribuido).  Debido a la distribución dispersa de los recursos 
RAM, esta arquitectura es también  conocida   como  dispersamente   acoplada  (loosely  
coupled), o compartiendo nada (shared nothing).

Estructura MPP
Para  tener acceso a la memoria fuera de su propia RAM, los  procesadores utilizan   un  
esquema de paso de mensajes análogo a los paquetes de datos en redes. Este sistema reduce 
el tráfico del bus, debido a que cada sección de memoria observa únicamente aquellos  
accesos que le están destinados, en lugar de observar todos los accesos, como ocurre en un 
sistema SMP. Únicamente cuando un procesador no dispone de la memoria RAM suficiente, 
utiliza la memoria RAM sobrante de los otros procesadores. Esto permite sistemas MPP de 
gran tamaño con cientos y aún miles de procesadores. MPP es una tecnología escalable.

3.6. Red
La topología de red recomendada es un Bus o barra, debido a la facilidad para proporcionar 
escalabilidad a la hora de agregar nuevos nodos al cluster. Protocolos como Ethernet, Fast 
Ethernet, 10/100 Mbps Switched Ethernet, etc, son tecnologías apropiadas para ser utilizadas 
en Beowulf.
 21

IV. Implementación y Construcción
Mayoritariamente   se   hablara   sobre   la   construcción   de   la   configuración   de   un   cluster  
Beowulf con clientes diskless

4.1. Consideraciones
¿Qué se necesita para tener un  Beowulf? Como se ha mencionado, para un  Beowulf  se  
requieren   los   nodos   como   tales,   así   como   una   red   local   de   interconexión;   un   sistema  
operativo en los nodos, que en la mayoría de los casos es Linux; y un método para que los 
programas aprovechen la naturaleza paralela del Beowulf. 

Interesantemente, en la mayoría de los casos estos serán los únicos elementos necesarios.  
Desde   el   principio,   el   proyecto  Beowulf  ha   buscado   integrarse   estrechamente   con   el  
desarrollo normal de Linux, así como interferir lo menos posible con una instalación de  
Linux tradicional. 

Así, la mayoría del software requerido para construir un Beowulf se proporciona como una 
adición a alguna distribución públicamente disponible de Linux. El proyecto Beowulf se  
enfoca  a  la   distribución   Red  Hat   Linux,  si  bien   sus  componentes  pueden   instalarse   en  
cualquier distribución. Cualquier distribución moderna incluye los componentes necesarios 
para la configuración del equipo como una estación de trabajo en red; esto incluye el kernel 
de Linux, el conjunto de utilerías y software GNU, y una serie de programas y aplicaciones 
como compiladores y herramientas de cómputo científico. 

Aquellos elementos que un Beowulf requiere adicionar a la distribución, están disponibles 
como paquetes adicionales y bibliotecas de desarrollo.

Cabe notar que, como producto del apoyo que el proyecto Beowulf ha dado al desarrollo de 
Linux,   todas   las   mejoras   a   los   controladores   de   red   de   Linux   realizadas   por   los  
desarrolladores de Beowulf han sido incorporadas a cada nueva versión del kernel de Linux, 
de modo que estos controladores no necesitan obtenerse de manera externa.
 22

4.2. HARDWARE

4.2.1. Comunicación entre nodos
El uso de la red Ethernet tiene ciertas ventajas y características interesantes. Una de ellas es 
su   facilidad de  instalación  y bajo costo. Por otro lado,  la popularidad  de la  tecnología  
Ethernet ha llevado a desarrollos que permiten incrementar el desempeño según crezcan las 
necesidades. Un cluster puede beneficiarse con el uso de switches, que segmentan el tráfico 
en el bus Ethernet y reducen la saturación y colisiones en el mismo. Y se puede contar con 
incrementos   de   desempeño   inmediatos   utilizando   Fast   Ethernet   (100   Mbps)   y   Gigabit  
Ethernet (1 Gbps). 

4.2.2. Consideraciones para equipos sin disco duro
El   uso  de  estaciones  diskless  (sin   disco),  como   se  conocen  comúnmente,  está  bastante  
difundido, pues permite un desempeño aceptable para terminales que normalmente fungen 
como despliegue del trabajo realizado en un servidor multiusuario. Las terminales diskless 
requieren  un mínimo  de  trabajo de  mantenimiento  y configuración,  y  éstos  se realizan  
básicamente en un servidor central, facilitando estas tareas. 

Mayoritariamente el recurso de interés en las estaciones es su procesador y memoria, como 
elementos de trabajo básicos del cluster. Adicionalmente, no se pretende que los usuarios 
tengan acceso a estas estaciones directamente. La técnica de arranque diskless proporciona 
ventajas, como son la centralización de todos los archivos de los nodos en un servidor  
central, y cierta economía en los requerimientos de equipo, pues se evita la necesidad de  
contar con disco duro en cada uno de ellos. 
El uso de esta técnica es una extensión del uso del sistema de archivos por red (Network File 
System o NFS). NFS normalmente se emplea para compartir los directorios de usuarios en 
redes de estaciones de trabajo, y en clusters suele emplearse para facilitar la distribución de 
los programas a ejecutar. 

Esta técnica presenta dos desventajas:
1. La primera es que se incrementa el uso de disco duro en el servidor central.
2. La segunda es un bajo desempeño en el acceso a archivos por parte de los nodos. 
Como los nodos no cuentan con almacenamiento secundario local, todo intento de 
 23

acceso a disco se realiza a través de la red y si no se tiene un red lo suficientemente 
rápida estos accesos pueden tomar bastante tiempo.

4.3. SOFTWARE

4.3.1. Instalación y arranque del sistema operativo en el servidor central
El   sistema   operativo   en   el   servidor   central   servirá   como   base   para   la   creación   de   los  
directorios o sistemas de archivos para los nodos. Este servidor debe contar con el software 
para proporcionar los servicios requeridos para el arranque y operación de los nodos.

4.3.2. Instalación y configuración de software de inicialización en los nodos  (diskless)
El arranque remoto de estaciones sin disco duro, es una técnica que se puede emplearse en 
los   nodos,   puede   emplearse   para   diversos   sistemas   operativos   de   red,   como   Novell   y  
variantes de Unix. El método tradicional con redes Unix involucra 4 etapas: 

1. Al arrancar la computadora, se carga un programa conocido como “arrancador de 
red”. Este es un programa que tradicionalmente reside en una ROM de arranque que 
se encuentra en la tarjeta de red. 

2. El arrancador de red obtiene su dirección IP de un servidor, utilizando los protocolos 
BOOTP  o DHCP. Con los  datos  entregados por el servidor el arrancador de  red 
realiza configuración básica de la tarjeta de red para hacer transferencias por TCP/IP.

 
3. El arrancador de red utiliza el protocolo TFTP para transferir un archivo desde el 
servidor, cuya ubicación normalmente se especifica como parte de la configuración 
recibida por BOOTP o DHCP. Este archivo comúnmente es el kernel que debe cargar 
la estación para realizar su arranque. 

4. Una vez cargado el kernel, termina el trabajo del arrancador de red; el kernel se carga 
normalmente y realiza su procedimiento de inicio. 
 24

Como se puede apreciar, esto involucra configuración de tres elementos básicos: 
● el arrancador de red a ejecutar en los nodos
● el servidor BOOTP o DHCP
● y el servidor de TFTP

Estos dos últimos elementos se configuran en el servidor. 

4.3.2.1 Asignación automática de dirección IP
Tanto   el   protocolo   BOOTP   (Bootstrap   Protocol)   como   el   DHCP   (Dynamic   Host  
Configuration   Protocol)   permiten   la   asignación   de   información   de   configuración   para  
estaciones   de  trabajo   desde   un  servidor   central.   En   ambos   casos   el   cliente   realiza   una  
transmisión  broadcast  con   su   dirección   de  hardware  (dirección   MAC4).   El   servidor  
BOOTP  o DHCP  toma esta petición y regresa al cliente la información requerida, que  
básicamente consta de la dirección IP que el cliente deberá utilizar, y algunos otros datos. De 
particular importancia es un nombre de archivo que ayudará al cliente a realizar su arranque. 

DHCP es un protocolo más sofisticado y cuya configuración es más clara que la de BOOTP. 
DHCP proporciona la posibilidad de enviar más información al cliente que BOOTP, y cuenta 
con algunas características como asignación dinámica de direcciones. 

El archivo de configuración es relativamente sencillo, sin embargo es un tanto extenso ya 
que   se   requiere   una   sección  host  para   cada   nodo   del  cluster.   El   archivo   completo   se  
encuentra en el anexo (A).
En general el archivo consta de varias secciones host que tienen el formato mostrado en el 
siguiente ejemplo: 

host nodo1 {
fixed-address 192.168.10.68;
hardware ethernet 00:60:08:0B:5A:9E;
filename "/tftpboot/vmlinuz-nbi-2.2";
next-server 192.168.10.1;
option host-name "nodo1";
}

4 Media Access Control, control de acceso al medio. Todo dispositivo de red debe contar con una dirección MAC 
única para identificación. 
 25

Se puede apreciar las mas importantes que en cada sección host se asignan:
• La dirección MAC (indicada por el parámetro hardware ethernet).
• La dirección IP de cada nodo (fixed­address).  Éstas se asignan de manera progresiva 
y cuidando que sean únicas para cada host.
• El nombre (hostname).
• El   nombre   del   archivo   a   cargar   para   el   arranque   (filename),   que   en   este   caso 
especifica la ruta, dentro del servidor TFTP, de un  kernel  Linux adecuado para el 
arranque de los nodos.
• Y el servidor que entregará este archivo a los clientes (next­server). La razón de este 
último  parámetro es  que en ocasiones  se puede  tener  un servidor TFTP  que  sea 
distinto del servidor DHCP.

4.3.2.2. Servidor de archivos de arranque TFTP
El protocolo TFTP (Trivial File Transfer Protocol) es un protocolo muy sencillo, basado en 
UDP, que permite bajar archivos de un servidor. Su principal utilidad es, precisamente, para 
proporcionar archivos de arranque a equipos que no cuentan con almacenamiento local.  
TFTP no cuenta con ninguna clase de control de acceso (contraseñas o nombres de usuario). 

En el caso de usar RedHat Linux, este proporciona un servidor de tftp, contenido en el  
paquete  tftp­server. Este paquete se encuentra instalado con la configuración de paquetes  
descrita   anteriormente,   sin   embargo   se   encuentra   normalmente   deshabilitado.   Para  
habilitarlo se debe agregar la siguiente línea en el archivo de configuración /etc/inetd.conf 

tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot

Esta es una línea de configuración tradicional del servidor inetd. En este caso se hace notar 
que el último parámetro (/tftpboot) indica el directorio que contiene los archivos a compartir 
por medio de TFTP. 
 26

4.3.2.3. Cargador de arranque
El programa encargado de iniciar la interfaz de red, obtener los datos de configuración  
básicos, y cargar por medio de TFTP el archivo especificado en esta configuración, es el  
cargador de arranque. 

Para realizar acabo esto existen dos paquetes que son Netboot y Etherboot.

Históricamente Netboot fue el primero en aparecer. Netboot utiliza los  manejadores  de  
paquetes (packet drivers) que se incluyen con casi cualquier tarjeta de red en el mercado,  
teniendo de esta manera gran compatibilidad con una extensa gama de tarjetas.

Etherboot es un desarrollo posterior, basado hasta cierto punto en Netboot, pero que ha sido 
reescrito proporcionando una base de código más limpia y compacta que la de Netboot.  
Etherboot utiliza manejadores internos y genera una imagen ROM para cada tipo de tarjeta 
de red soportada. El uso de manejadores internos permite que la imagen tenga un tamaño 
muy reducido que no da problemas con ninguna tarjeta de red soportada. Además, ya que los 
manejadores   fueron   desarrollados   explícitamente   para   Etherboot,   cuentan   con  
autoconfiguración para tarjetas tipo ISA, lo que permite utilizar una sola imagen de arranque 
para cada tipo de tarjetas.  

El uso de Etherboot no se recomienda si se tienen tarjetas de red que no estén soportadas, ya 
que el soporte de Netboot es más extenso.  ara utilizarlo se debe obtener el código fuente de 
la página http://etherboot.sourceforge.net.

4.3.2.4 Creación del kernel para los nodos
El archivo que el servidor TFTP entregará a los nodos es un kernel de Linux funcional. Éste 
asume el control del sistema y realiza el arranque normal. Ya que la configuración en las 
estaciones   es   bastante   particular,   el  kernel  debe   contar   internamente   con   las   funciones  
necesarias para inicializar el dispositivo de red, obtener su configuración de un servidor  
remoto, y montar su sistema de archivos raíz a través de NFS. Una vez realizadas estas  
funciones, el kernel invoca al proceso init (funcionamiento tradicional en un sistema Unix) y 
el arranque prosigue normalmente. 
 27

La naturaleza modular del kernel de Linux permite una gran eficiencia y versatilidad en el 
manejo de los módulos que controlan a los dispositivos e implementan ciertas características 
a nivel kernel. Esto es práctico si se cuenta con almacenamiento local, pero en el caso de un 
nodo   sin   dichas   facilidades,   se   requiere   que   el   kernel   contenga   internamente   todas   las  
funciones necesarias para su arranque, al menos hasta el montaje del sistema de archivos  
raíz.   En   el   ámbito   de   Linux,   se   dice   que   los   módulos   necesarios   deben   compilarse  
monolíticamente dentro del kernel. En este caso necesitamos compilar monolíticamente las 
siguientes opciones en el kernel: 

• Kernel   level   autoconfiguration.   Permite   al  kernel  obtener   su   información   de 

configuración a través de algún protocolo como DHCP o BOOTP.
• DHCP support 

• BOOTP support 

• NFS Filesystem Support. Ya que todos los sistemas de archivos montados por los 
nodos residirán en un servidor NFS, esta opción es indispensable para la operación 
de los nodos. 

• Root File System on NFS. Por medio de esta opción, el kernel monta un sistema de 
archivos en un servidor NFS como su sistema raíz.

• Soporte para las tarjetas de red que se vallan a utilizar.

4.3.3. Organización de sistemas de archivos para NFS

Cada   nodo   requiere   un   sistema   de   archivos   raíz   que   utilizará   para   el   arranque.   Estos  
directorios se exportarán a través de NFS y deben contener los archivos necesarios para el 
arranque del sistema. 

La mayoría de las distribuciones de Linux se adhieren a un estándar conocido como FHS 
(Filesystem Hierarchy Standard, estándar de jerarquía del sistema de archivos). El objetivo 
de contar con este estándar es el homologar la organización de los sistemas de archivos entre 
las   distribuciones   de   Linux,   para   mejorar   la   interoperabilidad   entre   las   aplicaciones,  
herramientas de administración de sistemas, herramientas de desarrollo y scripts, así como 
 28

contar   con   una   mayor   uniformidad   de   uso   y   documentación   para   los   sistemas   que   se  
adhieren el estándar. 

FHS intenta mantener la cantidad de archivos en el directorio raíz al mínimo (salvo para los 
directorios /usr, /opt y /var y /home) obedeciendo a algunos criterios básicos. Uno de ellos 
es particularmente importante para estaciones diskless: el sistema de archivos raíz contiene 
muchos archivos de configuración específicos a cada sistema, como puede ser configuración 
de red o nombre del host. Esto implica que el sistema de archivos raíz no siempre se puede 
compartir entre sistemas en red. El mantener el sistema de archivos raíz lo más compacto 
posible minimiza el espacio desperdiciado por archivos no compartibles. También permite 
minimizar el tamaño del sistema de archivos inicial, sea local o remoto. 

Los directorios de nivel superior, como lo especifica FHS, son los siguientes: 
• bin binarios de comandos esenciales (uso público) 
• boot archivos estáticos de arranque del sistema 
• dev archivos de dispositivos 
• etc configuración específica del sistema 
• home directorios de usuarios 
• lib bibliotecas compartidas esenciales 
• mnt punto de montaje para otros sistemas de archivos 
• opt software de aplicación adicional 
• root directorio del superusuario 
• sbin binarios esenciales del sistema 
• tmp archivos temporales 
• usr jerarquía secundaria 
• var datos variables 

Para los sistemas de archivos de los nodos, se omitirán los directorios /usr y /home, ya que 
estos serán compartidos entre todos los nodos y el servidor central. 
 29

A fin de generar el sistema de archivos para cada nodo, bajo el directorio /tftpboot se crean 
directorios con el hostname correspondiente a cada nodo, por ejemplo: /tftpboot/nodo1. 
Bajo cada uno de estos se debe crear la jerarquía raíz para cada nodo. Para esto simplemente 
se copian los subdirectorios necesarios del servidor. Los directorios a copiar son: 
• bin 
• dev 
• etc 
• lib 
• proc 
• root 
• sbin 
• tmp 
• var 

Inicialmente se realiza únicamente una copia del directorio. Posteriormente la configuración 
por nodo se realiza en esta copia, y finalmente se crean tantas copias del primer directorio 
como nodos se tengan. 

Inicialmente se realiza únicamente una copia del directorio. Posteriormente la configuración 
por nodo se realiza en esta copia, y finalmente se crean tantas copias del primer directorio 
como nodos se tengan. 

No se requiere copiar el directorio /boot, que contiene las imágenes ejecutables del kernel 
para el server, puesto que los nodos ya han cargado su kernel a través de TFTP.

Según   la  especificación  FHS,  el  directorio  /usr  debe   contener   únicamente   información  

compartible y de sólo lectura. Esto nos garantiza que al compartirlo entre todos los nodos, no 
se tendrán problemas de inconsistencia o sincronización. El directorio /home se comparte 
bajo el mismo mecanismo. De esta manera todas las entradas y administración de usuarios 
se realizan en el servidor central, los cambios y archivos de los usuarios se comparten entre 
todos los nodos. 
 30

4.3.4. Servidor NFS
El   sistema   de   archivos   en   red   (NFS)   permite   acceder   a   archivos   ubicados   en   sistemas  
remotos tal como si se encontraran localmente. En este caso es de gran importancia ya que a 
través de NFS se proporcionarán los sistemas de archivos raíz y un área compartida para los 
nodos del  cluster. El protocolo NFS fue desarrollado por Sun Microsystems, aunque está  
también publicado en el RFC 1094, por lo tanto su uso está muy difundido como uno de los 
principales mecanismos para compartir archivos en redes de área local. 

Linux cuenta con implementaciones NFS tanto para clientes como para servidores. Como se 
explicó, el soporte para cliente NFS se compila directamente en el  kernel. Así el kernel  
puede montar directamente sistemas de archivos que residen en otros servidores.

El software que permite a Linux fungir como servidor NFS está contenido en el paquete nfs­
utils. Éste se incluye en la distribución Red Hat, sin embargo no se instala por default por lo 
que se debe agregar posteriormente. Tambien se debe habilitar el servicio NFS, de modo que 
al iniciar el sistema arranque el “demonio” NFS. 

El  demonio  NFS  requiere  un archivo  de configuración  que  le  indique  qué sistemas   de  
archivos y directorios debe exportar, o hacer disponibles, así como varios parámetros que 
controlan el acceso que los clientes tendrán a estos sistemas de archivos. 

El archivo de configuración que se debe crear es  /etc/exports. Este archivo queda como  
sigue: 

/tftpboot 192.168.10.0/255.255.255.0(rw,no_root_squash)
/home 192.168.10.0/255.255.255.0(rw,no_root_squash)
/usr 192.168.10.0/255.255.255.0(rw,no_root_squash)

Cada línea indica el directorio a exportar, seguido de opciones que controlan el acceso al 
recurso. En este caso estamos especificando que los directorios solo podrán ser exportados a 
hosts  con dirección IP dentro de la subred 192.168.10.0 y máscara 255.255.255.0 (lo cual  
corresponde precisamente a la subred que estamos empleando para los nodos del cluster). 
 31

Los parámetros entre paréntesis indican los privilegios con que se exporta el recurso. 

En este caso especificamos  rw  (read/write), lo cual indica que se permiten peticiones de  

lectura y escritura en el sistema exportado. Comúnmente se especifica la opción ro (read 
only), pero en este caso se requiere acceso total porque los nodos requerirán la capacidad de 
escribir en sus sistemas de archivos remotos. 

El   parámetro  no_root_squash  desactiva   el   “aplastamiento   de  root”,   que   es   el  

comportamiento por omisión al exportar por NFS. Normalmente, para evitar que un sistema 
remoto monte un sistema de archivos y el superusuario de ese sistema tenga acceso total a 
nuestro sistema, el NFS mapea las peticiones realizadas por el usuario con  uid  0 a un  
usuario anónimo con privilegios mínimos. En este caso se desea que los accesos con uid 0 
no   tengan   un   mapeo   a   un  uid5  diferente,   pues   en   los   nodos   sí   se   requieren   accesos  
privilegiados. Esto no representa un riesgo de seguridad porque en este caso los accesos  
privilegiados   están   restringidos   a   los   nodos,   sobre   los   cuales   se   tiene   bastante   control  
administrativo. 

4.3.5. Configuración por nodo
4.3.5.1.Montaje de los sistemas de archivos remotos
No es necesario tomar pasos adicionales para que cada nodo monte su sistema de archivos 
raíz.   Como   parte   del   arranque,   el  kernel  montará   el   directorio   NFS  
192.168.10.1:/tftpboot/hostname como su directorio raíz. 

El archivo que indica los sistemas de archivos a montar una vez iniciado el sistema es el  
/etc/fstab. Ya que la configuración será la misma para todos los nodos, es conveniente  
realizar   el   cambio   primero   en   el   directorio  nodo1  que   se   creó   para   su   posterior  
duplicación. 

5 En sistemas UNIX, cada usuario es identificado por un valor numérico conocido como uid o User ID. 
 32

Para que los nodos monten los sistemas de archivos compartidos (/home y /usr), el archivo 
/etc/fstab debe quedar como sigue: 

none /proc proc defaults 0 0

none /dev/pts devpts gid=5,mode=620 0 0
192.168.10.1:/usr /usr nfs defaults 0 0
192.168.10.1:/home /home nfs defaults 0 0

Cada línea debe tener 6 elementos separados por espacios. 

El   primer   elemento  es   el  nombre  o  identificador   del   dispositivo  a  montar.  El  segundo  

elemento es el directorio sobre el cual se debe montar. El tercero indica el tipo de sistema de 
archivos que se encuentra en el dispositivo. El cuarto indica parámetros de montaje para el 
dispositivo. Los dos últimos elementos indican el orden en que se debe respaldar el sistema 
de archivos utilizando el comando dump. 

En este caso las dos primeras líneas están configuradas de antemano. La primera indica el 
montaje del sistema de archivos proc, que contiene información de tiempo de ejecución del 
sistema y se genera dinámicamente. La segunda indica el montaje del sistema de archivos 
devpts, que genera dinámicamente las terminales virtuales para acceso remoto al sistema. 

Las dos líneas siguientes indican el montaje de los sistemas /usr y /home. Éstos se montan a 
través de NFS (nótese el tercer parámetro especificando el tipo de sistema de archivos). La 
sintaxis para denotar el dispositivo a montar es servidor:directorio. Estas dos líneas montan 
los directorios /usr y /home del servidor en la misma ubicación en cada nodo. 

4.3.5.2. Configuración cliente NIS6 

A fin de que un nodo cliente pueda compartir la información de un servidor NIS, se requiere 
ejecutar un programa que lo enlace al dominio NIS correspondiente, de modo que, cuando 

6 Network Information Service (conocido por su acrónimo NIS, que en español significa Sistema de Información de 
Red), es el nombre de un protocolo de servicio de directorios cliente­servidor desarrollado por Sun Microsystems 
para el envío de datos de configuración en sistemas distribuidos tales como nombres de usuarios y hosts entre 
computadoras sobre una red.
 33

algún programa solicite información de las bases de datos compartidas, ésta pueda obtenerse 
del   servidor   NIS,   y   no   de   los   archivos   locales.   De   esta   manera   se   asegura   que   existe  
consistencia de información entre los clientes del dominio NIS, que como se mencionaba  
anteriormente, es necesaria, en particular para asegurar que la información de los permisos 
sobre los archivos sea la misma para todos los nodos. 

El cliente NIS requiere fijar el nombre de dominio NIS al que va a pertenecer, de manera 
similar a la del servidor NIS, por medio del programa domainname: 

# domainname DOMINIO

De esta manera se indica al sistema que pertenece al dominio tornado. Para no tener que 
realizar este procedimiento cada vez que se inicia el sistema se puede añadir la siguiente  
línea en el archivo /etc/sysconfig/network: 

NISDOMAIN="DOMINIO"

Se observa que este procedimiento es igual tanto en el cliente como en el servidor. 

Una vez que se ha fijado el valor de la variable NISDOMAIN, se requiere indicar el servidor 
que atenderá las peticiones NIS. Esto se configura en el archivo /etc/yp.conf. Se agrega la 
siguiente línea al archivo: 

ypserver 192.168.10.1

Obsérvese que 192.168.10.1 es la dirección IP del servidor NIS. 

Finalmente el cliente NIS debe ejecutar el programa que ejecuta las peticiones al servidor 
NIS, llamado  ypbind. De nuevo se observa el prefijo  yp, en este caso el nombre de la  
utilería   indica   que   se   “amarra”   o   “une”   (bind)   el   cliente   al   dominio   NIS   previamente  
especificado. 
 34

4.3.6. Archivo /etc/hosts
El   archivo  /etc/hosts  contiene   una   lista   de   mapeos   de   nombres   a   direcciones   IP.   Esta  
información   es   necesaria   para   la   correcta   operación   del   sistema.   Adicionalmente,   este  
archivo es uno de los archivos compartidos a través de NIS, de modo que únicamente se  
necesita   modificar   en   el   servidor   central   para   que   todos   los   nodos   tengan   la   misma  
información. 

El archivo contiene una lista de direcciones IP seguidas de nombres simbólicos. El contenido 
del archivo puede ser como sigue: 

127.0.0.1 localhost
192.168.10.1 DOMINIO
#nodos
192.168.10.68 nodo1
192.168.10.69 nodo2
192.168.10.70 nodo3
192.168.10.71 nodo4

Una vez agregada información al archivo, es importante recrear los mapas de NIS, como se 
menciona en la sección anterior, ejecutando el comando make en el directorio /var/yp. De 
otro   modo  los  nodos  no tendrán acceso a esta  información y el  sistema  no funcionará  
adecuadamente. 
 35

CONCLUSION

Básicamente   este  informe   estuvo  destinado   a   conocer   los   elementos   necesarios   para   la  
construcción   de   un   cluster   Beowulf,   no   tanto   en   su   aplicación   practica   pero   si  
mayoritariamente   teórica   debido   a  los   pocos   recursos   con   los   que   se  contaban   para   el  
desarrollo del tema.

Además se dieron a conocer algunas de las configuraciones necesarias para instalar nodos de 
tipo   diskless   que   son   los   mas   usados   en   aplicaciones   que   trabajan   con   procesamiento  
paralelo.
 36

REFERENCIAS

• http://es.wikipedia.org/wiki/Cluster_(informC3%A1tica)#Componentes_de_un_Cluster

• http://www.cecalc.ula.ve/documentacion/tutoriales/beowulf/node1.html

• http://publiespe.espe.edu.ec/articulos/sistemas/arquitectura/arquitectura.htm

• http://www.tomechangosubanana.com/tesis/escrito-1-split/node1.html

• http://talika.eii.us.es/~rosa/clustering.pdf

• http://www.bioingenieria.edu.ar/grupos/cibernetica/milone/pubs/cluster_RCDT2002draf
t.pdf
 37

ANEXO

A. EJEMPLO DE CONFIGURACION DEL DEMONIO DHCP
server-identifier tornado;

#Opciones comunes a todas las subredes soportadas

option domain-name "unam.mx";
option domain-name-servers 132.248.10.2;

#asignacion dinamica.. notese que en este caso solo

#especificamos las subredes en las que se encuentra el
#servidor, puesto que no vamos a realizar asignación
#dinámica hay dos declaraciones de subred
#correspondientes a cada una de las interfases que
#tenemos.

shared-network DOMINIO{
subnet 192.168.10.0 netmask 255.255.255.0 {
option broadcast-address 192.168.10.255;
}
}
subnet 192.168.1.0 netmask 255.255.255.0 { }

# A partir de aquí especificamos la configuración por

# host. cada bloque especifica un host, notar la
# dirección IP fija, el hostname que se asignará a
# cada nodo, y la direccion hardware ethernet que
# especifica a que direccion MAC se asignarán
# estos datos.

host nodo1 {
fixed-address 192.168.10.68;
hardware ethernet 00:60:08:0B:5A:9E;
filename "/tftpboot/vmlinuz-nbi-2.2";
next-server 192.168.10.1;
option host-name "nodo1";
}

host nodo2 {
fixed-address 192.168.10.69;
hardware ethernet 00:80:AD:30:49:D4;
filename "/tftpboot/vmlinuz-nbi-2.2";
next-server 192.168.10.1;
option host-name "nodo2";
}