trabajo-final-beowulf

1

Universidad Católica de TemucoFacultad de Ciencias e Ingeniería

Escuela de InformáticaIngeniería Civil en Informática

SISTEMAS DISTRIBUIDOS

“ESTRUCTURACION DE UN CLUSTER BEOWULF”

Miguel Abarca CastroProf. 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 DISKLESS.

3

INDICEIntroducció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 (Diskless) 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ónEl 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 backend 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 semihomogé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),

http://es.wikipedia.org/wiki/SSI

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, checkpointrestart (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

proxycaché, 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 BEOWULFBeowulf 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 RAID0: 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 RAID1: 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 RAID1 con un disco de 100 MB y otro

de 1 GB no se puede considerar como una buena idea.

• Modo RAID4: En este nivel, un disco se encarga de almacenar información de paridad

en un disco y escribe los datos en otro disco.

• Modo RAID5: 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 (Diskless)

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

Diskless 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 (fixedaddress). É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 (nextserver). 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 tftpserver. 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 clienteservidor 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/hostsEl 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 DHCPserver-identifier tornado;

#Opciones comunes a todas las subredes soportadasoption 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";}

trabajo-final-beowulf

Documents

Transcript of trabajo-final-beowulf