TECNOLÓGICO NACIONAL DE MÉXICO
Instituto Tecnológico de Colima
VILLA DE ÁLVAREZ, COL., MARZO DE 2017
OPCIÓN I
TESIS PROFESIONAL
QUE PARA OBTENER EL TÍTULO DE
INGENIERO EN SISTEMAS COMPUTACIONALES
PRESENTA
RAFAEL SALAZAR SALAZAR
ASESOR:
DR. JESÚS ALBERTO VERDUZCO RAMÍREZ
PROYECTO
ESTUDIAR PARA PREVER Y PREVER PARA ACTUAR
S G C
S N E S T
IMNC-RSGC-617 IMNC-RSGC-617
IMNC-RSGC-617
CERTIFICADO BAJO LA NORMA ISO 9001:2008
CERTIFICADO BAJO LA NORMA ISO 9001:2008
ISO 9001:2008 PROCESO EDUCATIVO
Agradecimientos
A mis padres, Rafael Salazar Aviña y María Isabel Salazar Cárdenas, por todos los apoyos, sacrificios, consejos y paciencia en este largo proceso que ha sido mi educación, y a lo largo de toda mi vida.
Al Doctor Jesús Alberto Verduzco Ramírez, por la oportunidad de poder unirme al desarrollo de este proyecto y por haberme encauzado a la especialidad a la que he decidido dedicarme.
Índice General
Agradecimientos………..………...i
Índice General……….……….………...ii
Índice de Figuras……….………...iii
Índice de Tablas……..……….……….……….………..iv
Resumen………..……….……….…….v
Abstract …..………...vi
CAPÍTULO I ... 9
Contexto del Proyecto ... 9
1.1 Introducción ... 9
1.2 Datos de la institución ... 9
1.3 Estudio de la situación actual ... 10
1.4 Planteamiento del problema ... 11
1.5 Propuesta de solución ... 11
1.6 Justificación ... 12
1.7 Objetivos ... 13
1.7.1 Objetivo general ... 13
1.7.2 Objetivos específicos ... 13
1.8 Análisis de requerimientos ... 13
1.9 Estudio de factibilidad ... 14
1.9.1 Factibilidad técnica ... 14
1.9.2 Factibilidad operativa ... 14
1.9.3 Factibilidad económica ... 15
1.9.4 Factibilidad legal ... 15
1.10 Análisiscosto-beneficio ... 16
1.11 Análisis de alternativas ... 17
1.12 Alcances y limitaciones del proyecto ... 18
1.13 Ventajas competitivas ... 19
1.14 Organización del documento ... 19
CAPÍTULO II ... 21
Estado del Campo del Conocimiento ... 21
2.1 Introducción ... 21
2.4.1 Computación distribuida ... 24
2.4.2 Clúster ... 24
2.4.3 Lenguajes de programación paralela ... 26
2.4.3.1 MPI ... 26
2.4.3.2 OpenMP ... 26
2.4.4 Sistema embebido ... 27
CAPÍTULO III ... 28
Metodología Aplicada ... 28
3.1 Introducción ... 28
3.2 Fases de la metodología: ... 28
3.2.1 Recolección y refinamiento de requisitos ... 28
3.2.2 Modelado, diseño rápido ... 28
3.2.3 Construcción del Prototipo ... 28
3.2.5Refinamiento del prototipo ... 29
3.2.6 Producto de Ingeniería ... 29
CAPÍTULO IV ... 30
Desarrollo del Proyecto ... 30
4.1 Introducción ... 30
4.2 Recolección y refinamiento de requisitos ... 30
4.3 Modelado, diseño rápido ... 31
4.4 Construcción del Prototipo ... 31
4.5 Evaluación del prototipo por el cliente ... 37
4.6 Refinamiento del prototipo ... 38
4.7 Producto de Ingeniería ... 39
Conclusiones y Trabajos a Futuro ... 43
5.1 Conclusiones ... 43
Índice de Figuras
Figura 1.1 Ubicación del Laboratorio de Cómputo de Alto Rendimiento. ... 10
Figura 1.2 Diagrama general de la solución. ... 12
Figura 2.1 Taxonomía de Flynn. ... 23
Figura 4.1 Diagrama conceptual del Cluster. ... 31
Figura 4.2 Laboratorio de Cómputo de Alto Rendimiento. ... 39
Figura 4.3 Nodos del clúster. ... 40
Figura 4.4 Distribución de carga. ... 41
Figura 4.5 Distribución de carga ... 41
Figura 4.6 Vista de particiones de slurm-web ... 42
Figura 4.7 Vista de trabajos de slurm-web ... 42
Índice de Tablas
Tabla 1.1 Requerimientos del proyecto. ... 14
Tabla 1.2 Costo de los requerimientos del proyecto. ... 15
Resumen
Actualmente la necesidad de plataformas que proporcionen soporte a las aplicaciones denominadas intensivas son cada vez mayores, ya que la demanda de plataformas de supercómputo se han ido incrementando de manera acelerada, debido al aumento en la cantidad de aplicaciones que manejan una cantidad de datos tan grande que no pueden ser procesados por una sola computadora. Como solución, han surgido los clústers: conjuntos de computadoras que trabajan juntas en una red para ejecutar programas que son demasiado demandantes para una sola computadora. Sin embargo, a pesar de ser más económicas que las supercomputadoras, un clúster puede llegar a tener un precio poco accesible, tanto por sus componentes como por su consumo energético.
Abstract
Currently the need for platforms to provide support for the so-called intensive applications are increasing thanks tothe rise in the number of applications that manipulate a quantity of data so big it cannot be processed by a single computer. As a solution, the clusters emerged: groups of computers working together in a net to execute software that is way too demanding for one singe computer. However, despite being less expensive than supercomputers, a cluster can have an unaffordable price, both for its components and its energy consumption.
CAPÍTULO I
Contexto del Proyecto
1.1 Introducción
En este capítulo se hablará acerca de los datos de la institución donde se realizará el proyecto, así como también se describirá un poco del proyecto, sus alcances, limitaciones, los análisis que se necesitaron realizar para conocer que el proyecto es factible y las ventajas que brinda.
1.2 Datos de la institución
Laboratorio de Cómputo de Alto Rendimiento y Visualización del Edificio de Posgrado del Instituto Tecnológico de Colima.
Misión:
Estudiar y desarrollar soluciones de hardware y software de alto
rendimiento y visualización para usos didácticos y de investigación en el Instituto Tecnológico de Colima.
Visión:
Ser un grupo líder en la investigación y desarrollo de sistemas de cómputo de alto rendimiento y de visualización en el estado de Colima y en la formación de alumnos para su capacitación en ésta clase de sistemas.
Actividades Principales:
• Diseño, desarrollo e implementación de sistemas Cómputo de Alto
Rendimiento para uso del ITC.
• Investigación del estado del arte del Cómputo de Alto Rendimiento y de Sistemas de Visualización en el ámbito nacional e internacional.
• Administración y mantenimiento del equipo de cómputo de alto rendimiento.
Dirección:
Laboratorio de Cómputo de Alto Rendimiento y Visualización, Edificio de Posgrado, Instituto Tecnológico de Colima
Dirección: Avenida Tecnológico No. 1, Colonia Liberación, Villa de Álvarez,
Colima.
Código Postal: 28017
Correo: [email protected]
Página Web:https://itcolima.edu.mx/posgrado/
Figura 1.1 Ubicación del Laboratorio de Cómputo de Alto Rendimiento.
1.3 Estudio de la situación actual
Actualmente, no se cuenta con un sistema de Cómputo de Alto Rendimiento, lo que limita seriamente las actividades académicas del Instituto Tecnológico de Colima en el ámbito del software de alto rendimiento.
1.4 Planteamiento del problema
Los clústers disponibles actualmente se basan en arquitecturas que, a pesar de que cumplen perfectamente las demandas de poder de procesamiento, suelen ser relaticamente caras y de un alto consumo energético, haciendo su desplegado y uso costoso. Esta situación se acentúa cuando el clúster usa como nodos computadoras de arquitecturas obsoletas, lo que hace que, en comparación con arquitecturas modernas, tengan un mayor consumo energético y menor poder de procesamiento.
A esto hay que agregar que este tipo de sistemas suelen generar una cantidad considerable de calor cuando se usan de manera intensiva, lo que genera gastos extra en cuanto a su refrigeración. En el caso del Laboratorio de Cómputo de Alto Rendimiento, este gasto se manifiesta en el uso de aire acondicionado para el laboratorio.
Estas limitantes tienen como resultado que muchas instituciones de carácter educativo carezcan con los recursos para poder desplegar clústers, limitando sus posibilidades para realizar investigaciones, ejercicios u otras actividades académicas en el ámbito de cómputo de alto rendimiento.
1.5 Propuesta de solución
Con el fin de resolver el problema planteado, se propone utilizar sistemas de cómputo embebido para implementar y poner en marcha un clúster de computadoras. La estructura de este clúster hibrido está integrada por cuatro
tarjetas Cubieboard 4 y tres tarjetas RaspBerry Pi, configuradas para trabajar
pero agregando tanto el bajo consumo energético y como la mínima generación de calor.
Así mismo, una computadora llamada nodo maestro funcionará como el punto de acceso por medio de Internet, permitiendo a los usuarios hacer uso de la infraestructura del clúster por medio de conexiones SSH. El esquema general del proyecto se muestra en la figura 1.2.
Figura 1.2 Diagrama general de la solución.
1.6 Justificación
Como se mencionó en el apartado 1.2, se requiere la implementación de este proyecto para dotar de la infraestructura de supercómputo de bajo costo a la institución, con la principal finalidad de dotar a los estudiantes y personal docente de una plataforma de enseñanza e investigación del supercómputo.
Con la implementación del clúster se pretende ofrecer el acceso a una infraestructura funcional de alto rendimiento para su utilización en las diversas asignaturas que lo requieran o proyectos de investigación que necesiten un alto poder de procesamiento.
1.7 Objetivos
A continuación se describen los objetivos que se alcanzarán al término del proyecto.
1.7.1 Objetivo general
Diseñar, implementar, probar y desplegar un clúster computacional basado en tecnologías embebidas que sea capaz de ejecutar tareas de cálculos de alta capacidad.
1.7.2 Objetivos específicos
• Estudiar el estado del arte del cómputo paralelo embebido.
• Diseñar e implementar el clúster.
• Configurar los equipos pertenecientes al clúster.
• Aplicar pruebas de funcionamiento
• Implementar el sistema.
1.8 Análisis de requerimientos
Tabla 1.1 Requerimientos del proyecto.
Requerimientos
Recursos físicos
4 Tarjetas Cubieboard 4.
3 Tarjetas Raspberry Pi 2 modelo B. 1 Regulador de voltaje
1 Laptop.
1 Switch con puerto.
Recursos humanos 1 Estudiante de ingeniería en sistemas computacionales de décimo
semestre.
Otros recursos
Instalaciones eléctricas. Instalaciones de Internet. Cables de red.
1.9 Estudio de factibilidad
Se realizaron cuatro estudios de factibilidad, los cuales son: económica, técnica, operativa y legal para determinar si el proyecto es factible. A continuación se describen con detalle el resultado de cada una de los estudios de factibilidad.
1.9.1 Factibilidad técnica
Debido a que todo el software requerido para la configuración de un clúster se encuentra disponible para plataformas embebidas con arquitectura ARM, y a que ya se cuenta con todo el hardware necesario para la implementación del proyecto, el proyecto puede definirse como técnicamente viable.
1.9.2 Factibilidad operativa
sistema, debido a que los usuarios contarían con los suficientes conocimientios para usar el sistema, haciéndolo operativamente factible.
1.9.3 Factibilidad económica
La tabla 2.2 muestra el costo del equipo y material necesarios para el desarrollo de este proyecto.
Tabla 1.2 Costo de los requerimientos del proyecto.
Concepto Requerimientos Costo
Recursos físico
4 Tarjetas Cubieboard 4.
3 Tarjetas Raspberry Pi 2 modelo B 1 Regulador de voltaje
1 Laptop.
1 Switch con puerto.
$9324 $1,148 $250 $10,000 $721 Recursos humanos
1 Estudiante de Ingeniería en Sistemas Computacionales
$0
Otros recursos
Instalaciones eléctricas. Infraestructura de red.
Mínimos requeridos
Total $21,443
Puesto que en el Edificio de Posgrado del Instituto Tecnológico de Colima ya cuenta con todos estos requerimientos y el estudiante que desarrolló el proyecto forma parte del Instituto Tecnológico de Colima, los costos serán prácticamente cero. Al tomar esto en cuenta, podemos decir que el proyecto es económicamente factible.
1.9.4 Factibilidad legal
1.10 Análisiscosto-beneficio
1.10.1 Costo
El costo del sistema se determinó en base al costo del hardware así como al costo de implementación. Para ello, se sumó el total del costo de los componentes del cluster y se calculó el salario de un empleado encargado de la configuración.
1.10.2 Costo del hardware
4 Tarjetas Cubieboard 4 = $9324
3 Tarjetas Raspberry Pi 2 modelo B = $1,148 1 Regulador de voltaje = $250
1 Laptop = $10,000
1 Switch con puerto = $721 Total = $21,443
1.10.3 Costo de implementación
Salario del programador por hora=$60.50 CS=60.50 * 8 horas diarias =$484.00
CS=484.00 * 5 días de la semana=$2,420.00
CS= 2,420.00 * 16 semanas (Tiempo estimado de desarrollo)=$38,720.00
1.10.4 Precio total del sistema
1.11 Análisis de alternativas
En la tabla 1.3, se mencionan las alternativas, ventajas y desventajas del proyecto.
Tabla 1.3 Análisis de alternativas para el desarrollo del proyecto.
Alternativa Ventajas Desventajas
Clúster basado en computadoras disponibles
No se generan gastos por la adquisición de componentes.
Poder de cómputo limitado debido a los recursos de computadoras relativamente antiguas.
Relativamente alto consumo
energético, debido al uso de microarquitecturas obsoletas e ineficientes.
Comprar una súper computadora
Contar con equipo propio del Tecnológico con el cual podría
experimentarse, realizar
pruebas, modificarse si es necesario
Infraestructura lo
suficientemente poderosa
como para uso tanto
académico como comercial.
Precio muy alto: en la magnitud de los millones de pesos.
No se cuenta con un entorno específico para este tipo de equipo. Gastos generados por corriente
eléctrica, aire acondicionado,
mantenimiento técnico.
Rentar un acceso a uno de estos súper
computadores.
No se necesita de un entorno para implantarlo.
Mantenimiento por parte del prestador de servicios.
Acceso a realizar pruebas.
No se puede configurar a las necesidades del plantel.
Limitado a tiempos de uso.
1.12 Alcances y limitaciones del proyecto
Alcances:
• Tanto los alumnos como los profesores tendrán acceso a esta
infraestructura la cual será gestionada por ellos mismos.
• Se podrán subir trabajos para el sistema de manera remota.
• Capacidad de poder agregar más nodos o computadoras para que se
pueda utilizar en nuevas aplicaciones o proyectos a futuro.
Limitaciones:
• Se requiere acceso a una red local para poder mantener los nodos
interconectados.
• Se tiene considerado desarrollarlo, hasta el momento con los nodos
1.13 Ventajas competitivas
• El precio, debido a que una placa computadora tiene un costo menor a
$2500, siendo significativamente menor en costo a alternativas X86 sin perder mucho rendimiento en comparación.
• El software (SO, librerías, herramientas) requerido para el sistema son de
distribución libre y gratuito, en comparación con otras soluciones de caracter privativo y/o de costo.
• La escalabilidad del sistema, ya que se puede expandir su capacidad
simplemente aumentando el número de nodos.
• El consumo energético y la generación de calor son menores debido al uso
de la arquitectura ARM, de bajo consumo.
1.14 Organización del documento
Este documento de tesis se encuentra conformado de la siguiente forma:
El Capítulo I “Investigación preliminar” describe el contexto del proyecto,
así como establece los objetivos, la hipótesis del trabajo y la justificación.
En el Capítulo II “Estado del campo del conocimiento” mostramos los
marcos histórico, contextual y teórico de los proyectos existentes que son similares a nuestro trabajo.
En el Capítulo III “Metodología aplicada” se describe la metodología
utilizada en el desarrollo de este proyecto de tesis.
En el Capítulo IV “Desarrollo del sistema” se presenta de manera
detallada el desarrollo de la librería.
En el Capítulo V “Pruebas al prototipo” las pruebas de realizadas para
comprobar el correcto funcionamiento de la librería.
En el capítulo VI “Análisis de resultados” se muestran datos estadísticos
CAPÍTULO II
Estado del Campo del Conocimiento
2.1 Introducción
Para poder desarrollar este proyecto, se requirió investigar diferentes áreas y tópicos de la programación, ya que los clústers y la programación paralela son temas más especializados de la Ingeniería en Sistemas, y por lo tanto la experiencia en dichos tópicos antes de realizar este trabajo era limitada.
Antes de proceder con el desarrollo de este sistema, se procedió a buscar la historia del procesamiento paralelo, el contexto y la terminología básica en el hámbito del cómputo de alto rendimiento.
2.2 Marco histórico
Desde la invención de la computadora moderna con la arquitectura de Von Neumann, la ejecución de código había sido de manera secuencial: una instrucción de código se ejecutaba en un sólo procesador.
El procesamiento paralelo se empezó a investigar desde los años 50’s, en donde los avances en supercomputadoras de múltiples procesadores y memoria compartida abrieron paso a nuevos paradigmas [2]. En los años 80’s, los clústers empezaron a hacerse campo en el área del cómputo paralelo, y desde entonces se han mantenido como la principal arquitectura de los data centers y la base de la computación científica.
Debido a la variedad de soluciones de cómputo paralelo, en 1966 el profesor e investigador Michael J. Flynn desarrolló una caracterización para dichos sistemas que es popular hasta nuestros días: la Taxonomía de Flynn [3]. Esa taxonomía clasifica a los diversos tipos de sistemas de cómputo paralelo y secuencial en cuatro categorías: único flujo de instrucciones y único flujo de datos (single instruction stream, single data stream, SISD), único flujo de instrucciones y
múltiples flujos de datos (single instruction stream, multiple data streams, SIMD),
múltiples flujos de instrucciones y único flujo de datos (multiple instruction streams,
single data stream, MISD), y múltiples flujos de instrucciones y múltiples flujos de
datos (multiple instruction streams, multiple data streams, MIMD).
Los sistemas SISD son sistemas convencionales y secuenciales de un sólo procesador, en la que una instrucción realiza una operación sobre un dato tomado de un único flujo de datos [3]. Los sistemas SIMD son sistemas con un procesador
y múltiples unidades de procesamiento de datos (conocidos como processing
elements o PEs), en la cual el procesador obtiene datos de los PEs para realizar operaciones con ellos en una intrucción. Los sistemas MISD son redes de
pequeños elementos computacionales conectados en un grid y controlados por un
reloj global. En cada ciclo de reloj, uno de los procesadores del grid lee y modifica
En la siguiente imagen se muestran los esquemas de la Taxonomía de Flynn:
Figura 2.3 Taxonomía de Flynn.
2.3 Marco contextual
Este trabajo se enfoca a investigar el potencial de los sistemas embebidos de arquitectura ARM para poder formar un clúster de cálculo basado en CPU, por lo que en este trabajo en específico no se evalúan procesos de cálculo en base a GPGPU, o procesos de visualización. El principal fin de este proyecto es el de determinar la viabilidad de tener un clúster de decenas de nodos basados en sistemas de cómputo embebido que sea comparable en desempeño computacional con alternativas basadas en arquitecturas X86.
Para determinar el potencial, se medirán diferentes aspectos del sistema, como su precio total, consumo energético, poder computacional, disponibilidad de software y escalabilidad.
2.4 Marco teórico
2.4.1 Computación distribuida
La computación distribuída es el campo de las ciencias computacionales encargado de estudiar el diseño y el comportamiento de sistemas que involucran componentes débilmente acoplados [5]. Dichos componentes pueden ser múltiples hilos de ejecución en un programa, múltiples procesos de una computadora o múltiples procesadores conectados a través de memoria compartida o de una red.
Entre los sistemas de computación distribuída, se encuentran los clústers,
los sistemas cliente-servidor, sistemas P2P (peer-to-peer), grids computacionales
y bases de datos distribuidas.
2.4.2 Clúster
componen el clúster se les conoce individualmente como nodos, y normalmente se conectan por redes LAN.
En un clúster, los diferentes procesadores trabajan en paralelo, y cada procesador suele tener más de un núcleo, haciendo que el grado de paralelismo sea muy alto, requiriendo que su software sea dependiente de lenguajes de programación paralela.
Los clústers suelen ser clasificados en base al grupo de usuarios al que está dirigido y a los requerimientos de éstos. En base a esto, se derivaron tres
grandes grupos de clústers: los de Alto Rendimiento (High Performance), Alta
Disponibilidad (High Availability) y Alto Volumen de Trabajo (High Throughput) [6].
2.4.3 Lenguajes de programación paralela
Estos son lenguajes de programación diseñados para programar algoritmos y aplicaciones para sistemas paralelos [7]. Por lo regular, tienden a ser extensiones de lenguajes de programación secuencial, elaborados con el fin de aprovechar al máximo la arquitectura de sistemas de cómputo paralelo sin necesidad de aprender un nuevo lenguaje.
Los principales lenguajes de programación paralela son MPI, OpenMP, CUDA y OpenCL.
2.4.3.1 MPI
MPI es un conjunto de APIs llamados por programas escritos en C, C++, Fortran y Python [8]. MPI fue desarrollado con el fin de crear un conjunto de herramientas estandarizadas basadas en el paradigma de pase de mensajaes para transmitir directivas entre los nodos de los clústers a través de la red.
2.4.3.2 OpenMP
OpenMP (Open Multi-Processing) es un conjunto de directivas que se añaden al código de un programa de C, C++ o Fortran para manipular hilos de ejecución sin la necesidad de que el programador tenga que lidiar con ellos
directamente [8]. Las directivas de OpenMP se expresan vía pragmas para
controlar el flujo de la aplicación.
2.4.3.3CUDA
CUDA es un lenguaje de programación diseñado para ser el vehículo a
través del cual se pueda programar las unidades de procesamiento gráfico (GPU)
[8]. Un programa de CUDA se compone de código a ejecutarse en el host (CPU) y
dispositivo se denomina kernel. Los hilos de las aplicaciones de CUDA se agrupan
en bloques, y a la totalidad de los bloques se le conoce como grid.
2.4.3.3OpenCL
Es un lenguaje de programación y estándar industrial para la computación heterogénea con paralelismo de datos y de tareas, que puede ser ejecutado sobre CPUs, GPUs, procesadores digitales de señales (DSPs) y otros diseños de procesadores [9]. OpenCL provee un lenguaje común, interfaces de programación y abstracciones de hardware para permitir la aceleración de aplicaciones en
ambientes de computación heterogénea, que consiste en el host (CPU) y los
dispositivos (GPUs, DSPs y otros tipos de procesadores).
2.4.4 Sistema embebido
CAPÍTULO III
Metodología Aplicada
3.1 Introducción
En este capítulo se procede a decribir las fases de la metodología seleccionada para el desarrollo del proyecto, que fue la de Modelo de Prototipos.
Modelo Prototipal es una metodología iterativa basada en la idea de crear un sistema entero o una parte en base a una versión piloto, llamada prototipo. Su meta es la de producir múltiples versiones del sistema y refinar consistentemente dichas versiones hasta que una versión final es alcanzada [11].
3.2 Fases de la metodología:
3.2.1 Recolección y refinamiento de requisitos
En esta fase, se identifican y analizan las las necesidades del usuario. Esta fase produce una lista de requisitos como artefacto.
3.2.2 Modelado, diseño rápido
Se realiza un diseño del sistema enfocado en los aspectos del sistema que serán tangibles para el usuario [12]. Aquí se lleva a cabo la fase del análisis de requisitos y se determinan los alcances y limitaciones del sistema y se produce un diseño lógico.
3.2.3 Construcción del Prototipo
Se desarrolla e implementa una versión funcional del prototipo [11]. Aquí se hace el proceso de desarrollo, la implementación y las pruebas internas.
El prototipo implementado es presentado al cliente para que éste lo pruebe y le de al desarrollador retroalimentación en tiempo real, para que pueda ser usada por los desarrolladores para refinar y corregir el prototipo.
3.2.5Refinamiento del prototipo
Si se encuentran mejoras y cambios sugeridos por el cliente, se procede a corregir y refinar el prototipo con el fin de crear un nuevo prototipo para volver a ser evaluado.
3.2.6 Producto de Ingeniería
CAPÍTULO IV
Desarrollo del Proyecto
4.1 Introducción
En este capítulo se describe el desarrollo del proyecto en base a las etapas de la metodología establecida en el Capítulo III.
4.2 Recolección y refinamiento de requisitos
Los elementos necesarios para el desarrollo del clúster se establecieron en base a los requerimientos del Departamento de Posgrado e Investigación, la principal parte interesada en el proyecto. Los requisitos funcionales para el sistema son los que se muestran a continuación:
1. Gestión de cuentas: capacidad de crear cuentas necesarias para el uso tanto de usuarios como alumnos o maestros, capacidad para restringir acceso a datos privados para cada usuario. Restringir el uso de recursos como Procesamiento, RAM o disco duro.
2. Monitoreo de recursos: Medición del uso de los recursos con los que cuenta el clúster, mostrando graficas con los siguientes datos uso de: Carga, Memoria,
CPU y network, también se pueden crear tareas o planificar estas.
4. Interfaz web: El sistema debe ser capaz de realizar todas sus funciones (monitoreo, cargado de archivos, gestión de usuarios) desde una interfaz gráfica web.
4.3 Modelado, diseño rápido
Con los requerimientos ya establecidos, se pasó a trabajar en la arquitectura que debía tener el sistema. Tras estudiar el diseño de sistemas de cómputo paralelo anteriores del ITC y algunas limitaciones del hardware, se llegó a la conclusión de usar un diseño en el cual los nodos estén conectados a un
switch que a su vez se conecte a internet, como se muestra en la figura 4.1:
Figura 4.4 Diagrama conceptual del Cluster.
4.4 Construcción del Prototipo
mediante un hostfile hecho por el usuario, el segundo con todos los nodos Raspberry Pi y CubieBoard con las capacidades del primer prototipo además de ser capaz de monitorear el desempeño del clúster, y el tercer y último prototipo con las capacidades del segundo junto con la capacidad de administrar diversas cuestiones del clúster (ejecución, planificación, administración de recursos)
mediante un scheduler y un sistema de archivos de red NFS.
4.4.1 Primer Prototipo
Para el desarrollo del prototipo inicial, se pasó a conectar los cuatro nodos Raspberry Pi a la red del ITC a través de un ruteador sencillo. Tras esto, se pasó a descargar e instalar el SO Raspbian mediante el uso de una tarjeta MicroSD: primero se copia la imagen de Raspbian a la MicroSD, después se inserta la tarjeta a la Raspberry Pi para después conectar la computadora a la corriente y
finalmente acceder a la Raspberry Pi vía SSH (debido a que al inicio se
desconocía la dirección IP de las Raspberry Pi y a la cantidad de dispositivos en la
red local, se usó la herramienta arp-scan para localizar la IP de los nodos).
Una vez conectados al nodo, se usó la herramienta raspi-config para
expandir el sistema de archivos de Raspbian para que use todo el espacio de la
tarjeta SD (16 GB) y se editó el archivo /etc/network/interfaces para que la
dirección IP de los nodos fuera estática, así como para agregar la máscara de red, la dirección de la red, de broadcast y del ruteador (obtenidas mediante el comando netstat -nr). Además se editó el hostname del nodo para facilitar su reconocimento en la red.
Para los nodos Raspberry Pi, el rango de direcciones IP es el de 198.162.132.X, iniciando en el 192.168.132.1 con el nodo maestro, mientras que los hostnames son raspi-master para el nodo maestro y raspi-nodeX para los
esclavos, iniciando desde el raspi-node1.
contraseña, lo que haría que una comunicación entre nodos independiente del usuario fuera complicada.
Una vez que todos los nodos estaban configurados e interconectados vía SSH, se pasó a instalar la librería MPICH para la ejecución de código paralelo. Se instaló la librería directamente desde los repositorios de Debian y se probaron códigos de prueba para asegurar su funcionamiento. Al determinar que todo funcionaba correctamente, se dió por concluído el desarrollo del primer prototipo.
4.4.2 Segundo Prototipo
Para el segundo prototipo, se pasó a instalar el monitor de rendimiento Ganglia, además de incorporar los cuatro nodos CubieBoard al clúster.
Antes de poder configurar Ganglia, se requería instalar un servidor web
para la ejecución de la interfaz web, por lo que se seleccionó el servidor Lighttpd
debido a su bajos requerimientos de recursos. Una vez comprobado el correcto
funcionamiento del servidor web, se pasó a instalar el Ganglia Monitor en todos los
nodos y el Ganglia Meta Daemon y Ganglia Web Frontend en el nodo maestro,
siendo todos los paquetes obtenidos del repositorio de Debian.
Para configurar Ganglia, se requiere editar principalmente el archivo
gmetad.conf en /etc/ganglia/ en el nodo maestro; en este archivo se requiere añadir las direcciones IP de los nodos del clúster, así como el nombre del nodo al
que pertenecen. Además, se debe editar el archivo gmond.conf en /etc/ganglia/
para especificar a qué clúster pertenece cada nodo.
Para configurar la la interfaz web de Ganglia, se requirió copiar el contenido
de la carpeta /usr/share/ganglia-webfrontend a la dirección /var/www/ganglia, todo
esto en el nodo maestro. Además, se configuró Lighttpd para que referencie
fastcgi y fastcgi-php de Lighttpd, todo esto con el fin de que el servidor web estuviera configurado para el desplegado de la interfaz web de monitoreo de Ganglia.
Una vez que el clúster funcionaba correctamente con los nodos Raspberry Pi, se decidió agregar los nodos CubieBoard. Al principio, se había decidido usar el SO Ubuntu Linaro Server debido a la incapacidad de encontrar una imagen de Debian para las CubieBoard, pero tras ver la discrepancia en la versión de los paquetes (lo que en algunos casos causaba que no funcionaran correctamente con las versiones diferentes de las Raspberry Pi, como SLURM) y descubrir una imagen funcional de Debian, se pasó a instalar Debian Server en las CubieBoard
y cambiar la versión de los repositorios de Debian en las Raspberry Pi de Wheezy
(versión legacy de Debian) a Jessie (estable, misma versión en la que se
encontraba Debian Server en las CubieBoard) y actualizar el sistema (comando apt-get update).
Una vez que ambas clases de nodos tenían paridad de sistemas (Debian Jessie), se pasó a configurar las CubieBoard de la misma manera que las Raspberry Pi: configuración de IP estática (en el rango 192.168.133.X), cambio de
hostname (cubie-nodeX), generación de llaves SSH y el envío de llaves públicas a
los demás nodos del clúster, instalación de MPICH y de Ganglia Monitor en todos
los nodos, así como la edición del archivo gmond.conf en los respectivos nodos.
Una vez que que se probó el funcionamiento del monitor Ganglia en todos los nodos, así como la ejecución de código MPI en los siete nodos a la vez, se dió por finalizado el desarrollo del segundo prototipo.
4.4.3 Tercer Prototipo
maestro y planificador. Al principio, se pensaba usar una CubieBoard 2 disponible, pero debido a que tras su configuración se descubrió que carecía de poder computacional para la tarea, se decidió usar un nodo CubieBoard 4 como nodo maestro y planificador en lugar de las CubieBoard 2 planeada y Raspberry Pi hasta entonces en ese rol.
Por lo tanto, se pasó a configurar el nodo 1 del clúster de CubieBoard (cubie-node1), por lo que se modificó este nodo como maestro, y el nodo maestro
del clúster de Raspberry Pi (raspi-master) como un nodo esclavo. Para eso, se
pasó a modificar el hostname de los nodos de ambos clústers para reflejar la nueva estructura del clúster (tres Raspberry Pi esclavos, tres CubieBoard esclavos y el CubieBoard maestro), instalar y configurar Lighttpd, Ganglia Meta Daemon y Ganglia Web Frontend en el nuevo nodo maestro y copiar sus archivos de configuración del viejo nodo maestro al nuevo para después modificarlos, y desinstalar dichos paquetes del antiguo maestro.
Una vez que se realizaron las configuraciones pertinentes y se comprobó que el clúster funcionaba correctamente, se procedió a instalar SLURM. Para esto, primero se requirió la instalación y ejecución del servicio NTP para sincronizar la hora de los siete nodos; algo que es requerido para el correcto funcionamiento de SLURM [13].
Acto seguido, se pasó a instalar el paquete de SLURM desde el repositorio (slurm-llnl) en todos los nodos, y la creación del script de configuración usando la
plantilla HTML (slurm-wlm-configurator.html en /usr/share/doc/slurmctld) en el
nodo maestro.
Como SLURM usa llaves MUNGE en vez de las SSH para su comunicación, se procedió a crear dichas llaves (comando create-munge-key) en el nodo maestro y se copiaron al resto de los nodos. Después, se activó el servicio
Ya con el servicio MUNGE activo, se pasó a activar los servicios de
SLURM: el de cómputo (slurmd) en todos los nodos y el de administración
(slurmctld) en el nodo maestro. Una vez activo, se puede comprobar el estado de
los nodos con el comando sinfo y ejecutar código con srun.
Una vez que SLURM se encontraba funcionando correctamente, se decidió instalar el sistema de archivos de red NFS con el fin de evitar el proceso de copiar el código a ejecutar en cada nodo, y tener un sistema de archivos que se comparta entre los siete nodos. Para esto, se instalaron las herramientas de
cliente NFS (nfs-common) en todos los nodos, y las de servidor (nfs-server) en el
nodo maestro. Después de eso, se crearon las directorios donde se encontarán los archivos a compartir vía NFS por parte del servidor y en el que se montará el
sistema de archivos en los clientes(en ambos casos, ~/Cluster).
Además, en el nodo maestro se requirió editar el archivo /etc/exports para añadir el directorio a compartir, junto con la IP del cliente al que se le va a compartir el directorio, y las opciones del sistema de archivo entre paréntesis, siendo usadas en este caso las ociones rw (para que el cliente tenga opciones de lectura y escritura), sync (que hace que se permitan peticiones al directorio compartido sólo hasta que los cambios se hayan guardado) y no_root_squash (que permite que el usuario root pueda conectarse al directorio) y después se
actualiza la tabla de directorios de NFS (comando exportfs).
En los clientes, se usa el comando showmount para verificar que el servidor
NFS tiene directorios para compartir, y si los tiene, se agregan al archivo fstab
como si de una partición común se tratase, teniendo el cuidado de anteponer la dirección IP del servidor a la dirección de la partición, y de declarar el formato de
la partición como nfs. Con esto, la configuración de NFS quedó completa, y se
Finalmente, se procedieron a instalar todos los requerimientos para la
interfaz web de SLURM (slurm-web), que eran Python Flask, JQuery, Clustershell,
Bootstrap, Flot, Cython, libslurm-dev, libslurmdb-dev y PySLURM (este último
desde su repositorio de Github: github.com/gingergeeks/pyslurm).Una vez
instalados, se procedió a descargar e instalar todos los paquetes incluídos en
slurm-web (comando dpkg -i).
Una vez instalado, procedió a modificar el archivo /etc/slurm-web/racks.xml,
encargado de desplegar un gráfico de la representación del rack del clúster, usado
para las vistas de rack y estado de los nodos.
Después de que se editaron algunas configuraciones de archivos
JavaScript por cuestiones estéticas (mostrar tamaños de nodos en la vista de rack
más cercanas a la realidad, desplegado del nombre de los nodos) y se corrigieron algunos errores de sintaxis, se procedó a visualizar slurm-web en el navegador y hacer pruebas. Una vez que se determinó que funcionaba correctamente, se dió por finalizado el tercer y último prototipo.
4.5 Evaluación del prototipo por el cliente
Durante la prueba de los tres prototipos, se probaron diferentes programas en C con código MPI; los dos primeros prototipos ejecutaron copias individuales e idénticas de cada código mediante ejecutables, y en el tercer prototipo mediante una copia del código compartida a todos los nodos por NFS y ejecutada con el
comando srun de SLURM.
Por último, en el tercer prototipo, se evaluaron funciones de SLURM como
la capacidad de ejecutar programas con MPI mediante srun, ver el estado de los
nodos con sinfo, reservar recursos con salloc y ver trabajos activos con squeue,
además de probar el funcionamiento correcto del sistema de archivos NFS del clúster.
Los programas MPI ejecutados para probar el funcionamiento del cluster fueron:
Integral de una funcion mediante sumas de areas de trapecios. Suma, resta y multiplicación de matrices de 10,240,000 elementos. Simulación de una red Token Ring.
Prueba de mensajes broadcast.
Prueba Linpack.
4.6 Refinamiento del prototipo
En la prueba del primer prototipo, todos los nodos del clúster fueron capaces de reconocer y acceder al resto de los nodos sin requerir nombre de usuario y contraseña y ejecutar todos los programas de prueba se ejecutaron correctamente. Sin embargo, fue notado que era poco conveniente la constante necesidad de copiar el código a los diferentes nodos, por lo que se tomó la decisión de usar un sistema de archivos de red, aunque este requerimiento no fue cumplido hasta el tercer prototipo.
En la prueba del segundo prototipo, se probó la ejecución de programas MPI en el clúster y el monitoreo de los nodos en la interfaz web de Ganglia. La ejecución del código volvió a ser satisfactoria, a pesar de que los detalles señalados en la primera revisión se mantuvieron. El funcionamiento de Ganglia también fue satisfactorio, aunque se señalaron algunos detalles como el hecho de
que en el archivo gmetad.conf deben de añadirse los nodos por su hostname para
La prueba del tercer prototipo fue la más complicada, debido de a pesar de que el nuevo nodo maestro, SLURM y el sistema de archivos NFS funcionaron correctamente, hubo algunos problemas con slurm-web, que requirieron que se editaran algunos archivos JavaScript para que la interfaz web funcionara adecuadamente.
4.7 Producto de Ingeniería
El resultado del último prototipo fue un clúster de 3 nodos Raspberry Pi 2B y 4 nodos CubieBoard 4 con un rendimiento computacional de 24.295 GFLOPS en desempeño multinúcleo, capaz de ejecutar código MPI sin necesidad de copiar el código a todos los nodos debido al uso de un sistema de archivos NFS, monitorear el rendimiento del clúster o de nodos individuales, ver la disponibilidad y estado de los recursos del clúster así como con la opción de asignar un número específico de recursos para el uso posterior de un programa.
En la figura 4.2, se puede apreciar una imagen del Laboratorio de Cómputo de Alto Rendimiento y Visualización:
Las figuras 4.3 y 4.4 muestran de cerca el clúster, compuesto por los cuatro nodos CubieBoard y los tres nodos Raspberry Pi:
Figura 4.3 Vista frontal del clúster.
La figura 4.5 muestra la interfaz web de Ganglia mostrando los nodos del clúster sin ninguna carga de trabajo.
Figura 4.5 Distribución de carga.
A continuación se mostrara la figura 4.6 en donde se puede observar la carga en cada nodo que compone el clúster.
En las figuras 4.7 y 4.12 se muestra la interfaz de slurm-web, mostrando la página de particiones y de trabajos, donde adicionalmente se puede apreciar el acomodo de los nodos.
Figura 4.7 Vista de particiones de slurm-web
CAPÍTULO V
Conclusiones y Trabajos a Futuro
5.1 Conclusiones
Tras ver el resultado de las pruebas realizadas en el clúster, se puede llegar a la conclusión de que se pueden crear Sistemas de Cómputo de Alto Rendimiento basados en sistemas embebidos de arquitectura ARM con poder de cómputo y precio competitivos.
Además, la carencia de software no es ningún problema; ya que al usar los repositorios adecuados, todo el software requerido para la creación del clúster fue encontrado e instalado sin problemas,por lo que en este rubro no sufre ningún tipo de desventaja frente a sistemas X86.
5.2 Trabajos a futuro
El clúster desarrollado en este trabajo está planeado para formar parte de un sistema de Cómputo de Alto Rendimiento capaz de realizar tareas de cálculo, visualización y minería de datos, con fines tanto de investigación como de aprendizaje en tópicos de programación paralela, visualización y minería de datos.
Este sistema está pensado para llevarse a cabo exculsivamente con sistemas de cómputo embebido, con el fin de seguir demostrando la viabilidad de la arquitectura ARM como alternativa para su uso en sistemas de cómputo de alto rendimiento.
[1] Q. F. Stout, “What is Parallel Computing? A Not Too Serious Explanation”, Computer
Science and Engineering, University of Michigan, 2000. [En línea] Disponibe en:
https://web.eecs.umich.edu/~qstout/parallel.html. [Accesado el 6 de Marzo del 2017].
[2] Microsoft. “Parallel Computing: Background”, Intel. [En línea] Disponible en:
http://www.intel.com/pressroom/kits/upcrc/ParallelComputing_backgrounder.pdf. [Accesado el 8 de Marzo del 2017].
[3] CSEP. “3.1 Flynn's Taxonomy”, Computational Science Education Project. [En línea]
Disponible en: http://www.phy.ornl.gov/csep/ca/node11.html. [Accesado el 10 de Marzo del 2017].
[4] Yale University. “Distributed Computing”, Yale University Computer Science. [En línea]
Disponible en: http://cpsc.yale.edu/research/distributed-computing. [Accesado el 8 de Marzo del 2017].
[5] F. Tao, L. Zhang, Y. Laili. Configurable Intelligent Optimization Algorithm: Design and
Practice in Manufacturing. Beijing: Springer, 2014, 132. [En línea] Disponible en
http://books.google.com.mx/books?id=wQZPBAAAQBAJ. [Accesado el 12 de Marzo del 2017].
[6] I. Bernal, D. Mejía, D. Fernández.“Computación de Alto Rendimiento con Clusters de PCs”. Escuela Politécnica Nacional. [En Línea]. Disponible en:
http://clusterfie.epn.edu.ec/clusters/Publicaciones/HTML/articulo1.htm. [Accesado el 11 de Marzo del 2017].
[7] D. Talia. “Parallel Programming Languages”, Dipartimento di Ingegneria Informatica,
Modellistica, Elettronica e Sistemistica, Università della Calabria. [En Línea]. Disponible
en: http://si.deis.unical.it/~talia/CL.html. [Accesado el 10 de Marzo del 2017].
[8] N. Matloff. “Programming on Parallel Machines”. Computer Science, University of California, Davis Campus. [En Línea]. Disponible en:
http://heather.cs.ucdavis.edu/~matloff/158/PLN/ParProcBook.pdf. [Accesado el 10 de Mayo del 2017].
[9] J. E. Stone, D. Gohara, G. Shi. “OpenCL: A Parallel Programming Standard for
Heterogeneous Computing Systems”, Computing in Science & Engineering, vol. 12, no. 3,
[11] P. Isaias, T. Issa. High Level Models and Methodologies for Information Systems.
Springer, 2014, 33. [En Línea]. Disponible en:
http://books.google.com.mx/books?id=mgKcBAAAQBAJ [Accesado el 12 de Marzo del 2017].
[12] B. B. Agarwal & S. P. Tayal. Software Engineering. Nueva Delhi: Laxmi Publications,
2007, 32. [En Línea]. Disponible en: https://books.google.com.mx/books?id=r-SH73Cuc-IC. [Accesado el 12 de Marzo del 2017].
[13] SchedMD. “Quick Start Administrator Guide”, SLURM Workload Manager. [En Línea].
