trabajo-final-beowulf
TRANSCRIPT
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),
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";}