Embed Size (px)
Citation preview
TECNOLÓGICO NACIONAL DE MÉXICO
Instituto Tecnológico de Colima
VILLA DE ÁLVAREZ, COL., MARZO DE 2017
OPCIÓN ITESIS PROFESIONAL
QUE PARA OBTENER EL TÍTULO DE INGENIERO EN SISTEMAS COMPUTACIONALES
PRESENTARAFAEL SALAZAR SALAZAR
ASESOR:DR. JESÚS ALBERTO VERDUZCO RAMÍREZ
PROYECTO
ESTUDIAR PARA PREVERY PREVER PARA ACTUAR
S G C
S N E S T
IMNC-RSGC-617
IMNC-RSGC-617IMNC-RSGC-617
CERTIFICADO BAJO LANORMA ISO 9001:2008
CERTIFICADO BAJO LANORMA ISO 9001:2008
ISO 9001:2008
PROCESO EDUCATIVO
PLANIFICADOR DE TAREAS PARA UN
CLUSTER DE HPC EMBEBIDO
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.
Al Instituto Tecnológico de Colima, por proveerme de la educación y
recursos que tuvieron como resultado el desarrollo de mis habilidades y
conocimientos.
Í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.2 Marco histórico ........................................................................................................ 21
2.4 Marco teórico ........................................................................................................... 24
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
5.2 Trabajos a futuro ...................................................................................................... 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 Tabla 1.3 Análisis de alternativas para el desarrollo del proyecto. ............................ 17
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.
En la presente tesis se evalúa la viabilidad de la creación de un clúster
basado en sistemas embebidos, con el fin de disponer de un sistema de alto
rendimiento cuyos nodos tengan un precio asequible y bajo consumo energético,
pero manteniendo un poder de cómputo considerable, con el fin de que
instituciones que no tienen los recursos para adquirir un clúster bajo condiciones
normales puedan disfrutar de los beneficios de un sistema de cómputo de alto
rendimiento.
8
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.
In the current thesis examines the feasibility of creating a cluster based on
embedded systems, with the purpose of having a high performance system whose
nodes have an affordable price and low energetic consumption while keeping a
considerable computing power, in order that institutions that lack the resources to
acquire one under normal circumstances can enjoy the benefits of a high
performance computing system.
9
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.
• Diseño, desarrollo e implementación de sistemas de visualización.
10
• 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
El Laboratorio de Cómputo de Alto Rendimiento y Visualización cuenta con
un clúster compuesto por 6 computadoras de arquitectura X86 con procesadores
Xeon, aunque de microarquitecturas antiguas, aunque actualmente no está en
servicio.
11
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
como una sola unidad de procesamiento, para aplicaciones de carga mediana
12
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.
Es bien sabido que existen otras opciones para contar con este servicio
pero en su gran mayoría implican costos importantes que la institución no puede
solventar.
13
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
Los requerimientos de equipo necesarios para elaborar el proyecto se muestran en la tabla 1.1.
14
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
Debido a que el clúster será utilizado principalmente por alumnos de las
carreras de Ingeniería en Sistemas Computacionales y Mastría en Sistemas
Computacionales, así como por personal académico del área de Sistemas y
Computación, sólo bastaría con una pequeña capacitación para poder usar el
15
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 El Sistema Operativo y todo el software que se requiere para la
configuración del clúster es software libre (bajo diferentes versiones de la licencia
GPL), sólo se requiere publicar de manera libre el código en caso de modificación
y comercialización, dicho esto el proyecto es legalmente factible.
16
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
� Total = $21,443 + $38,720
� Total = $60,163
17
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.
� Gestión de datos o recursos
dedicados a los proyectos del
platel por parte del prestador del
servicio.
18
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
mencionados en la tabla de requisitos.
19
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
acerca de los resultados obtenidos.
20
Finalmente en el capítulo VII “Conclusiones” se recopilan las conclusiones
finales sobre el proyecto.
21
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.
Pero el surgimiento de nuevas arquitecturas de computación, una nueva
disciplina surgió en el campo de la computación: la computación paralela. La
computación paralela puede describirse brevemente como el uso de múltiples
procesadores o núcleos de manera combinada para resolver un problema único
[1].
22
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
un elemento simple del flujo de datos y lo prepara para que otro procesador lo
modifique. Por último, los sistemas MIMD son los cuales en los que diferentes
hilos de ejecución (núcleos, procesadores, computadoras) usan diferentes datos
provenientes de diferentes memorias o segmentos de memoria.
23
En la siguiente imagen se muestran los esquemas de la Taxonomía de
Flynn:
Figura 2.3 Taxonomía de Flynn.
En la actualidad, la computación paralela se ha vuelto cotidiana en equipos
comerciales para usuarios comunes, debido al desarrollo y adopción en masa de
procesadores multinúcleo [2], incentivando el desarrollo de programas que
aprovechen la mayor cantidad de recursos computacionales disponibles al público
general.
24
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 Un clúster es un sistema computacional especial compuesto por hardware y
software débilmente integrado, que colabora de manera integral para completar
trabajos computacionales de manera eficiente [5]. A las computadoras que
25
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].
Los clústers de alto desempeño suelen ser relacionados con la computación
científica, demandante de alto rendimiento y muchos recursos, donde las tareas
requieren mucho poder computacional y pueden consumir recursos del clúster por
mucho tiempo. Los clústers de alta disponibilidad son más frecuentes en la
industria de los servicios web, donde se requieren sistemas de alta disponibilidad,
tolerantes a fallos y con un rendimiento sostenido. Los clústers de alto volumen de
trabajo son más frecuentes en usuarios que requieren ejecutar múltiples tareas
independientes en paralelo, con independencia de datos entre ellas.
26
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
en el dispositivo (GPU). Las funciones que el host llama para ejecutarse en el
27
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
Es un sistema que tiene tres componentes principales embebidos en él:
hardware similar al de una computadora, software de aplicación principal y un
sistema operativo [10]. Un sistema embebido se caracteriza por funcionar en
tiempo real, reacciona a eventos, interrupciones y tareas programadas, controla
latencias y limitada memoria y poder computacional.
28
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.
3.2.4 Evaluación del prototipo por el cliente
29
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
Cuando el prototipo es aceptado por el cliente y no se requieren más
cambios sustanciales, se lanza una versión final que puede ser entregada al
cliente.
30
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.
3. Cómputo paralelo: Capacidad que debe de tener el proyecto para lanzar
ejecuciones en los distintos nodos, además de contener compatibilidad con
lenguajes de programación paralela como MPI, OpenMP o CUDA.
31
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
Durante el proceso de desarrollo del proyecto que concluyó en este trabajo,
se elaboraron tres prototipos; el primero con los nodos Raspberry Pi
interconectados y con capacidad de ejecutar programas con MPI multinodo
32
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.
Tras la configuración de red de los nodos, se pasó a generar las llaves SSH
para poder lograr que los nodos se comuniquen sin requerir el usuario y
33
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
/var/www/ganglia como directorio raíz de las páginas web en la opción
server.document-root de /etc/lighttpd/lighttpd.conf y se activaron los módulos
34
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
Para el tercer prototipo, se procedió a instalar el planificador de tareas
SLURM, con el fin de que éste lleve a cabo las labores de ejecución de programas
y gestión de recursos en el clúster, así como el uso de un nuevo nodo como
35
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
de MUNGE (munged) en todos los nodos.
36
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
reiniciaron los servicios y agregaron archivos al sistema de archivos para
comprobar su funcionamiento.
37
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.
Además, en el segundo y tercer prototipo, se monitoreó el rendimiento de
los nodos mediante Ganglia antes, durante y después de la ejecución de los
programas de prueba.
38
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
que se muestre dicho nombre en la interfaz de Ganglia en vez de su dirección IP.
39
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:
Figura 4.2 Laboratorio de Cómputo de Alto Rendimiento.
40
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.
Figura 4.4 Nodos del clúster.
41
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.
Figura 4.6 Distribución de carga
42
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
Figura 4.8 Vista de trabajos de slurm-web
43
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.
Bibliografía
44
[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,
pp. 66-73, Mayo-Junio del 2010.
45
[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].
Disponible en: https://slurm.schedmd.com/quickstart_admin.html. [Accesado el 08 de
Marzo del 2017].
