Límites de la Computación Científica en Sistemas Desktop Grid

(1)

UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIER´IA Departamento de Sistemas y Computaci ´on

Grupo de Investigaci ´on de Comunicaciones y Tecnolog´ıa de Informaci ´on COMIT

L´ımites de la Computaci ´on Cient´ıfica

en Sistemas Desktop Grid

Aurelio Vivas

Trabajo de grado presentado para optar

por el t´ıtulo de Mag´ıster en Ingenier´ıa de Sistemas y Computaci ´on en la Universidad de los Andes

Julio, 2020

(2)

(3)

Abstract

Since simulation became the third pillar of scientific research, several ting paradigms have emerged to support scientific research conducted in compu-ters. The practice of solving scientific problems in computers received the name of scientific computing. Nowadays, paradigms such as high performance compu-ting and high throughput compucompu-ting have become the de facto paradigms to conduct scientific computing. Each paradigm setting its own rules about how powerful computers can be build using distributed systems, but also, these pa-radigms have placed rules about how scientific applications must be developed to take advantage of the vast amount of computing power reachable through each paradigm. Accordingly, scientific applications developed to be addressed on high performance computing systems (e.g., Supercomputers) are called HPC applications, while applications developed to be addressed on high throughput computing systems (e.g., Desktop Grids) are called HTC applications.

In particular, high throughput computing systems such as Desktop Grids have proven to be attractive systems for scientific computing because they are capa-ble of reaching a computing capacity comparacapa-ble to supercomputers. Also these computing systems have a better cost/benefit ratio compared to supercomputers. In June 2019, the Desktop Grid platform BOINC registered a computational ca-pacity of 29.717 PetaFLOPs. On the same date, the fastest supercomputer in the world recorded a computational capacity of 148,600.0 TeraFLOPs. Likewi-se, several antecedents are presented in history demonstrating the potential of Desktop Grid computing systems.

However, characteristics such as heterogeneity, volatility, and limited connecti-vity intrinsic to computing resources in Desktop Grid systems limit the range of scientific applications that can be easily addressed in these kinds of computing systems. HTC applications have proven to be successfully addressed, while HPC applications have proven to be a great challenge.

In this master’s thesis, we identified and characterized those HPC applications that can be addressed in Enterprise Desktop Grid computing systems (a spe-cial kind of Desktop Grid system) when overcoming the limitations that hinder the execution of these applications on this kind of systems. For those HPC ap-plications identified, we designed a Desktop Grid computing system which is “theoretically” able to provide a greater reliability for the execution of these applications on enterprise and universitary environments.

Another result of this thesis was materialized in a methodology called communi-cativeness analysis which extends the performance analysis that can be conduc-ted in HPC applications. This novel analysis allows the estimation of coupling

(4)

ii

of a computing system, but also reveals a profile that describes the strengths and weaknesses of a computer system (such as a supercomputer, a conventional cluster or desktop grid among others) to address different types of scientific ap-plications.

(5)

Resumen

Desde que la simulación se convirtió en el tercer pilar de la investigación cient´ıfica, múltiples paradigmas de computación han surgido para apoyar el pro-ceso de investigación cient´ıfica realizado en computadoras. As´ı, la práctica de re-solver problemas cient´ıficos en computadoras recibió el nombre de computación cient´ıfica. Hoy en d´ıa, paradigmas de computación como high performance com-puting y high throughput comcom-puting se han convertido en los paradigmas de facto para llevar a cabo computación cient´ıfica. En este aspecto, cada paradigma es-tablece sus propias reglas acerca de cómo construir computadores poderosos a partir de sistemas distribuidos, as´ı mismo, cada paradigma establece sus propias reglas acerca de cómo deben ser desarrolladas las aplicaciones cient´ıficas para tomar ventaja del poder computacional que puede ser alcanzado por medio de cada paradigma. Por consiguiente, las aplicaciones cient´ıficas desarrolladas para ser abordadas en sistemas de cómputo high performance computing (p. Ej., los supercomputadores) son denominadas aplicaciones HPC, mientras que aplica-ciones desarrolladas para ser abordadas en sistemas de cómputo high throughput computing (p. Ej., Desktop Grids) son denominadas aplicaciones HTC.

En particular, sistemas de cómputo high throughput computing como los Desktop Grids han demostrado ser sistemas atractivos para computación cient´ıfica porque son capaces de alcanzar capacidades computacionales comparables con la dispo-nible en los supercomputadores. Además, estos sistemas de cómputo presentan una mejor relación costo/beneficio en comparación con los supercomputadores. En Junio de 2020, la plataforma Desktop Grid BOINC registró una capacidad computacional de 27.145 PetaFLOPs. Mientras que el séptimo supercomputador más rápido del mundo, Selene, registró una capacidad de 27.580 PetaFLOPs. As´ı mismo, se presentan varios antecedentes en la historia que demuestran el potencial de los sistemas Desktop Grid para llevar a cabo cómputo cient´ıfico. Sin embargo, caracter´ısticas como la heterogeneidad, la volatilidad y la conec-tividad limitada intr´ınseca a los recursos de cómputo en sistemas Desktop Grid limitan el rango de aplicaciones cient´ıficas que pueden ser abordadas fácilmente en este tipo de sistemas. Las aplicaciones HTC han demostrado ser abordadas con éxito, mientras que las aplicaciones HPC han demostrado ser un gran desaf´ıo para estos sistemas.

En esta tesis de maestr´ıa, identificamos y caracterizamos aquellas aplicaciones HPC que pueden ser abordadas en sistemas Desktop Grid Empresariales (un tipo especial de sistema Desktop Grid), al superar las limitaciones que dificultan la ejecución de estas aplicaciones en este tipo de sistemas. Para aquellas aplica-ciones HPC identificadas, diseñamos un sistema de computación Desktop Grid que ‘permita su ejecución en entornos empresariales y universitarios.

(6)

iv

Otro resultado de esta tesis se materializó en una metodolog´ıa llamada análisis de comunicatividad que ampl´ıa el análisis de rendimiento que se puede realizar en aplicaciones HPC. Este novedoso análisis permite la estimación del acoplamiento de un sistema cómputo, además revela un perfil computacional que describe las fortalezas y debilidades de un sistema de cómputo (como una supercomputado-ra, un clúster convencional o una grilla de escritorio, entre otros) para abordar diferentes tipos de aplicaciones cient´ıficas.

(7)

Agradecimientos

Me gustar´ıa expresar mi m´as sincera gratitud a las siguientes personas y or-ganizaciones:

A Harold Castro, mi asesor de maestr´ıa, por su paciencia, acompa˜namiento, sentido del humor, y sentido de la cr´ıtica, rara vez log´re convencerlo de algo.

A John Sanabria, Arturo Arg¨uelles y Carlos Arango quienes me han inspira-do y forjainspira-do como investigainspira-dor y como persona.

A mi familia, especialmente a mis hermanas Yovana y Karen, y mis padres Nicolasa y Aurelio por que en definitiva su apoyo incondicional es inconmensura-ble. En este aspecto quiero exaltar el trabajo de mi madre quien tomó las riendas del hogar y supo conducirme por el camino de la educación y por ende a lograr la culminación de mi trabajo de maestr´ıa.

A la familia Arizala, en particular, a mi dulce y fiel compa˜nera de vida Jac-keline, por su paciencia y apoyo incondicional durante mis estudios.

A la Se˜nora Mireya y su familia quienes desde la distancia han estado obser-vando mis pasos y apoy´andome para seguir adelante.

A mis compa˜neros de maestr´ıa, en especial a Carolina Pardo, Arnold Lara y David Bonilla. Espero que sigamos almorzando juntos.

A mis compañeros de atletismo, en especial a mis entrenadores José Bernard y Jorge Benitéz por recibirme en su equipo y formarme primero como persona y luego como deportista.

Al comité organizador de International Supercomputing, primero por haber-me escogido entre tantos participantes en el mundo para asistir becado a la conferencia ISC 2019 y por último, brindarme su apoyo al presentarme nuevas oportunidades en mi área de estudio.

A Dina Rosero, Yaned Ocor´o y a todas esas personas que han hecho parte de mi vida, mis compa˜neros de infancia, entre otros que he conocido. Aunque pudo haber sido poco el contacto, lograron aportes significativos en mi vida.

Por ´ultimo, pero no menos importante, la Universidad de los Andes por financiar mis estudios de maestr´ıa.

(8)

Art´ıculos de Investigaci´

on

Art´ıculos sometidos en revista indexada

1. Estimating the degree of coupling of a distributed system that follows the cluster architecture.

Aurelio Vivas and Harold Castro. Art´ıculos sometidos en conferencia

1. Communicativeness: A Measure of Coupling for Distributed Sys-tems Exhibiting the Cluster Architecture.

Aurelio Vivas and Harold Castro.

(9)

´Indice general

Abstract I

Resumen III

Agradecimientos V

Art´ıculos de Investigaci´on VI

Tabla de Contenidos VII

´_{Indice de Figuras} _IX

´_{Indice de Tablas} _X

1 Planteamiento 1

1.1 Planteamiento del Problema . . . 1

1.2 Metodolog´ıa . . . 3

1.3 Organizaci´on del Documento . . . 3

2 Introducci´on 4 2.1 Computaci´on Cient´ıfica . . . 4

2.2 Aplicaci´on Paralela . . . 4

2.2.1 Programaci´on Paralela . . . 5

2.2.2 Paradigmas de Programaci´on Paralela . . . 5

2.3 High Performance Computing . . . 7

2.3.1 Sistema de C´omputo HPC . . . 8

2.3.2 Aplicaci´on HPC . . . 12

2.4 High Throughput Computing . . . 13

2.4.1 Sistemas de c´omputo HTC . . . 14

2.4.2 Aplicaciones HTC . . . 14

2.5 Desktop Grids . . . 15

2.5.1 Sistema de C´omputo Desktop Grid . . . 16

2.5.2 Aplicaciones para Sistemas Desktop Grid . . . 17

2.6 Discusi´on . . . 18

3 Estado del Arte 19 3.1 Tolerancia a Fallos . . . 19

3.1.1 Retry . . . 20

3.1.2 Replication . . . 21

3.1.3 Checkpointing/Recovery . . . 21

3.1.4 Fault Tolerant Scheduling . . . 22 vii

(10)

viii ´Indice general

3.2 Estudio Sistemas Desktop Grid y Similares . . . 22

3.2.1 BOINC . . . 23 3.2.2 Aneka . . . 25 3.2.3 InteGrade . . . 26 3.2.4 Condor . . . 28 3.2.5 UnaCloud . . . 30 3.2.6 Grid’5000 Testbed . . . 35

3.2.7 AWS Parallel Cluster . . . 40

3.3 An´alisis de Literatura . . . 46

3.4 Conclusi´on . . . 51

4 Siete Algoritmos de la Computaci´on Cient´ıfica 53 4.1 Clase Algor´ıtmica . . . 54

4.2 Clases Algor´ıtmicas . . . 55

4.2.1 Algebra Lineal Densa´ . . . 55

4.2.2 Algebra Lineal Dispersa . . . .´ 55

4.2.3 M´etodos Espectrales . . . 56

4.2.4 M´etodos N-Body . . . 56

4.2.5 Mallas Estructuradas . . . 57

4.2.6 Mallas no Estructuradas . . . 59

4.2.7 Monte Carlo . . . 60

4.3 Estudio de las Siete Clases Algor´ıtmicas . . . 60

4.3.1 Caso de Estudio . . . 61

4.3.2 Configuraci´on Experimental . . . 62

4.3.3 An´alisis y Resultados Cl´uster HPC . . . 65

4.3.4 Análisis y Resultados Clústeres de Estaciones de Trabajo 69 4.3.5 Análisis de Latencia y Ancho de Banda . . . 72

4.3.6 An´alisis Aplicaci´on Embarazosamente Paralela . . . 74

4.3.7 An´alisis de Comunicatividad en Cl´usteres . . . 75

4.3.8 Conclusi´on . . . 76

5 Comunicatividad en Sistemas Distribuidos 81 5.1 Arquitectura Cl´uster . . . 82

5.2 Definici´on de Comunicatividad . . . 82

5.2.1 Medici´on de la Comunicatividad . . . 83

5.2.2 Valores de la Comunicatividad . . . 85

5.2.3 Limitaciones de la Comunicatividad . . . 86

5.3 Perfil de Rendimiento de un Cl´uster . . . 87

6 Dise˜no Sistema Desktop Grid Universitario 91 6.1 Justificaci´on . . . 91

6.2 Aspectos que Considera el Dise˜no . . . 92

6.3 Dise˜no . . . 94

7 Conclusi´on 99

(11)

´Indice de figuras

2.1 Ejemplo Paradigma Master-Worker [145, p. 20] . . . 6

2.2 Ejemplo Paradigma SPMD [145, p. 21] . . . 7

3.1 Tecnicas de Tolerancia a Fallos . . . 21

3.2 Estructura de Planificaci´on de Condor [107, p. 106] [119, p. 23] . 28 3.3 El Kernel de UnaCloud [37, p. 401] . . . 31

3.4 Sitios Asociados a Grid’5000 hasta el 2009 [58, p. 30] . . . 36

3.5 Arquitectura Cl´uster Tradicional [144] . . . 42

3.6 Arquitectura Basada en Batch [144] . . . 43

4.1 Modelo de Din´amica de Fluidos Computacional en Mallas Estruc-turadas y No EstrucEstruc-turadas [39] . . . 57

4.2 Interconexi´on entre Puntos o Elementos del Dominio en el Enfoque de V´ertices y Celdas . . . 58

4.3 Intercambio de Informaci´on en un C´omputo de tipo Stencil [101, p. 3] . . . 58

4.4 Interconexi´on entre Elementos en Mallas Estructuradas y No Es-tructuradas [2, p. 6] . . . 60

4.5 Arquitectura Cl´uster de Estaciones de Trabajo Cw1 . . . 63

4.6 Arquitectura Cl´uster de Estaciones de Trabajo Cw2 . . . 63

4.7 Rendimiento de la Aplicaciones en el Cl´uster Chpc . . . 66

4.8 Rendimiento de la Aplicaciones en el Cl´uster Cw1 . . . 70

4.9 Rendimiento de la Aplicaciones en el Cl´uster Cw2 . . . 71

4.10 Uso Promedio de la Interfaz de Red para 1, 2 y 4 Nodos en el Cl´uster Cw1 . . . 73

4.11 Tiempo de Ejecución y Rendimiento de EP en 1 Nodo de cómputo 75 5.1 Metodolog´ıa Análisis de Comunicatividad . . . 83

5.2 Ejemplo Acoplamiento en un Sistema Distribuido Fuertemente Acoplado . . . 84

5.3 Ejemplo Acoplamiento en un Sistema Distribuido D´ebilmente Aco-plado . . . 84

5.4 Valores de la Comunicatividad . . . 85

6.1 Dise˜no UnaCloud 3 . . . 95

6.2 Diagrama de Secuencia Fase de Despliegue Ambientes de Ejecu-ci´on EEs . . . 97

6.3 Dise˜no UnaCloud 3 Integrado con Snapshot Global . . . 98

(12)

´Indice de cuadros

2.1 Caracter´ısticas de un Sistema de c´omputo HPC . . . 10

2.2 Perfil General de una Aplicaci´on HPC . . . 12

2.3 Caracter´ısticas de un Sistema de C´omputo HTC . . . 15

2.4 Perfil General de una Aplicaci´on HTC . . . 15

2.5 Caracter´ısticas Sistemas Desktop Grid Empresariales y Voluntarios. 17 3.1 Comparaci´on de las Caracter´ısticas de Infraestructura en las Pla-taformas Desktop Grid y Similares . . . 46

3.2 Comparaci´on Soporte en la Ejecuci´on de Aplicaciones Cient´ıficas en los Sistemas Estudiados (Desktop Grid/Cloud, Cloud y Grid) 47 3.3 Estrategias para Mitigar el Efecto de la Volatilidad, Heterogenei-dad y ConectiviHeterogenei-dad Limitada en Aplicaciones HTC . . . 48

3.4 Estrategias para Mitigar el Efecto de la Volatilidad, Heterogenei-dad y ConectiviHeterogenei-dad Limitada en Aplicaciones HPC . . . 49

4.1 Especificaci´on de los Nodos en cada Cl´uster . . . 64

4.2 Especificación de la Interconexión Empleada en cada Clúster . . 64

4.3 Perfil de Rendimiento - Comunicatividad Cl´uster Chpc . . . 75

4.4 Perfil de Rendimiento - Comunicatividad Cl´uster Cw1 . . . 75

5.1 Perfil de Rendimiento Cl´uster Chpc . . . 88

5.2 Perfil de Rendimiento Cl´uster Cw1 . . . 88

5.3 Perfil de Rendimiento Cl´uster Cw2 . . . 89

(13)

1

Planteamiento

1.1 Planteamiento del Problema

Para tomar ventaja del poder computacional ofrecido por los supercompu-tadores, las aplicaciones cient´ıficas deben ser diseñadas como aplicaciones para-lelas. En el proceso de diseño e implementación de una aplicación paralela, el domino (o espacio) del problema es divido en tareas. Dependiendo de la natura-leza del problema, se mantienen algunas dependencias entre estas tareas. Si es posible remover estas dependencias, entonces, se obtiene una aplicación compren-dida por tareas que son independientes y no requieren comunicación entre ellas, es decir, una aplicación paralela sin comunicación entre tareas, también conocida en la literatura como una aplicación embarazosamente paralela. Por el contra-rio, cuando no es posible remover estas dependencias, resulta una aplicación que comprende tareas que deben comunicarse entre si, es decir, una aplicación para-lela con comunicación entre tareas.

Las aplicaciones cient´ıficas han sido ampliamente abordadas en supercomputado-res. No obstante, el costo de operar y mantener un sistema de supercomputación es elevado en comparación a otras formas de computación. Lo anterior, hace que formas de computación emergentes y de bajo costo como la computación Desktop Grid empiecen a ser consideradas. La computación Desktop Grid ha mostrado ser apropiada para abordar aplicaciones paralelas sin comunicación entre tareas. Sin embargo, esta forma de computación ha evidenciado grandes dificultades para abordar aplicaciones paralelas con comunicación entre tareas. Lo anterior, porque estas aplicaciones son sensibles a varios de los aspectos que caracterizan las plataformas de cómputo Desktop Grid tales como la volatilidad, heterogeneidad y conectividad limitada [154, p. 37].

Este trabajo recoge la experiencia de muchos años de computación basada en Desktop Grid para computación cient´ıfica. En este aspecto se estudian las dife-rentes problemáticas que enfrentan las plataformas Desktop Grid para abordar aplicaciones cient´ıficas y cómo estas plataformas han abordado estas problem´

(14)

2 1.1. Planteamiento del Problema

cas. Finalmente, basado en las diferentes soluciones propuestas, se propone una nueva soluci´on materializada en un sistema Desktop Grid para entornos univer-sitarios.

A continuaci´on se describen los lineamientos bajo los cuales se desarrolla el pre-sente trabajo de grado.

Justificaci´on

Estudios han demostrado que los usuarios de computadores ubicados en salas de cómputo de universidades y organizaciones no hacen uso de toda la capacidad de cómputo de estos sistemas [117, p. 8]. Incluso, se han realizado estudios del uso de CPU durante el d´ıa con un reporte de uso cercano al 5 % [124] [120]. Luego de detectar la necesidad de utilizar estos recurso, se ha mostrado en la literatura cómo diferentes tipos de computación (ejemplo: cient´ıfica, de prop´ osi-to general) podr´ıan osi-tomar ventaja de esosi-tos recursos computacionales conociendo las restricciones latentes en plataformas Desktop Grid. Es relevante determinar bajo qué escenarios es útil el uso de un Desktop Grid, sobre todo para abordar aplicaciones cient´ıficas. Del mismo modo, determinar aquéllos aspectos que limi-tan el uso de estas alternativas de computación en un campus universitario. La información resultante puede ser útil en la decisión de usar plataformas HPC ´

o optar por el enfoque que provee el Desktop Grid para abordar aplicaciones cient´ıficas.

Objetivo General

Determinar qu´e tipo de aplicaciones cient´ıficas consideradas com´unmente en supercomputadores pueden ser abordadas en sistemas desktop grid desplegados en ambientes universitarios.

Objetivos Espec´ıficos

1. Identificar caracter´ısticas, requerimientos, ventajas y desventajas de las diferentes soluciones Desktop Grid que han sido consideradas en la litera-tura para ejecutar aplicaciones cient´ıficas com´unmente abordadas en su-percomputadores.

2. Identificar qué tipo de aplicaciones cient´ıficas consideradas comúnmente en supercomputación pueden ser abordadas en sistemas Desktop Grids Universitarios.

3. Diseñar un sistema Desktop Grid que permita la ejecución confiable de aplicaciones cient´ıficas consideradas comúnmente en supercomputación. 4. Desarrollar un sistema Desktop Grid a partir del diseño propuesto y

eje-cutar un conjunto de pruebas de rendimiento que permitan validar la la soluci´on.

(15)

Planteamiento 3

Resultados Esperados

1. Revisi´on de literatura de las diferentes soluciones de software propues-tas para el despliegue de plataformas Desktop Grid identificando carac-ter´ısticas, requerimientos, ventajas, desventajas y soporte para aplicaciones cient´ıficas.

2. Estudio de los tipos de aplicaciones cient´ıficas, consideradas com´unmente en supercomputadores, en sistemas Desktop Grid Universitarios.

3. Dise˜no de una herramienta que permita el despliegue de sistemas Desktop Grid en ambientes universitarios.

4. Resultados de la validaci´on de la herramienta propuesta.

1.2 Metodolog´ıa

La metodolog´ıa planteada para el desarrollo de esta tesis consiste de las siguientes cuatro etapas:

1. Identificar las principales problemáticas que enfrentan las plataformas Desk-top Grid para abordar aplicaciones cient´ıficas y cómo estas plataformas han abordado estas problemáticas.

2. Identificar los principales algoritmos o métodos numéricos empleados en aplicaciones cient´ıficas y determinar las problemáticas que estos presentan en plataformas Desktop Grid.

3. Basados en los estudios anteriores, dise˜nar e implementar una herramienta para el despliegue de Desktop Grid para abordar aplicaciones cient´ıficas en ambientes Universitarios.

4. Realizar las respectivas pruebas de la herramienta desarrollada.

1.3 Organizaci´

on del Documento

El presente trabajo de grado se compone de 7 cap´ıtulos. Cada cap´ıtulo, a excepción del primero, concluye con una sección de discusión o conclusión del cap´ıtulo. En este aspecto el lector puede remitirse a la conclusión y luego leer los aspectos que soportan dicha conclusión. As´ı mismo cada cap´ıtulo inicia indi-cando el objetivo del ca´pitulo y su relación con cap´ıtulos anteriores. Lo anterior cumple el objetivo de marcar el flujo de investigación tomado.

El cap´ıtulo 2 compila aquellos conceptos necesarios para comprender el conteni-do del presente conteni-documento. Finalmente, describe porqu´e el problema abordado en el presente trabajo de grado es importante.

Los cap´ıtulos 3, 4 y 6 soportan el cumplimiento de los primeros 3 objetivos plan-teados, respectivamente. El ´ultimo objetivo no fue alcanzado y por ende no hay un capitulo dedicado al mismo. El cap´ıtulo 5 presenta una de las contribuciones m´as relevantes del presente trabajo de grado. Finalmente, el presente trabajo concluye en el cap´ıtulo 7, donde presentamos un resumen de todo el trabajo realizado, conclusiones, contribuciones y trabajo futuro.

(16)

2

Introducci´

on

El objetivo de este cap´ıtulo es definir algunos conceptos relevantes para el presente trabajo de grado y definir el contexto del problema. En particular, introducimos los conceptos de computaci´on cient´ıfica, aplicaci´on paralela, high performance computing, high throughput computing, y desktop grid computing.

2.1 Computaci´

on Cient´ıfica

“La computación cient´ıfica es la colección de herramientas, técnicas y teor´ıas necesarias para desarrollar y resolver en una computadora, modelos matem´ ati-cos de problemas en ciencia e ingenier´ıa” [46]. De manera alternativa, se puede definir como el uso de computadores para la solución de modelos matemáticos. Ejemplos de problemas tratados en computación cient´ıfica son encontrados en diferentes disciplinas de la ciencia como qu´ımica, f´ısica, matemáticas y biolog´ıa. As´ı mismo, en ingenier´ıa se emplea computación cient´ıfica para asistir procesos de diseño de aeronaves, veh´ıculos, entre otros procesos mediante simulación. La computación cient´ıfica implica la construcción de modelos matemáticos y técnicas en métodos numéricos para la solución de problemas. Estos modelos a menudo demandan una gran capacidad de cómputo, para la realización de experimentos a gran escala dentro de un plazo de tiempo razonable [66, p. 1]. Dos paradigmas de computación denominados high performance computing y high throughput computing son los paradigmas dominantes que han permitido suplir las necesidades computacionales latentes en computación cient´ıfica. Para tomar ventaja de estos paradigmas de computación las aplicaciones cient´ıficas son desarrolladas como aplicaciones paralelas.

2.2 Aplicaci´

on Paralela

Una aplicación paralela es como su nombre lo indica una aplicación que es capaz de tomar ventaja de los recursos computacionales de un computador pa-ralelo con el objetivo de reducir su tiempo de ejecución. Para la construcción de

(17)

Introducci´on 5

aplicaciones paralelas se emplean algoritmos, modelos y paradigmas de progra-mación paralela. Al final, una aplicación paralela es la combinación de todo lo anterior.

2.2.1. Programaci´on Paralela

La programación paralela consiste en el diseño y implementación de progra-mas que tengan la capacidad de usar múltiples unidades de procesamiento, dispo-nible en computadores paralelos (sistemas de memoria compartida y distribuida). En el proceso de diseño e implementación de una aplicación paralela, el dominio (o espacio) del problema a abordar es dividido en tareas [80] [26, p. 211]. Depen-diendo de la naturaleza del problema, algunas dependencias se mantienen entre las tareas. Cuando es posible remover estas dependencias, entonces, se obtiene una aplicación que se constituye de la ejecución de varias tareas independientes. Este tipo de aplicaciones son conocidas como aplicaciones embarazosamente paralelas. Por otro lado, cuando no es posible remover las dependencias, se ob-tiene una aplicación conformada por tareas que deben comunicarse entre s´ı para pasarse información unas con otras y de esta forma mantener la consistencia de la solución. Este último tipo de aplicaciones paralelas se conoce como apli-caciones no embarazosamente paralela. Note que una aplicación paralela, que a su vez se compone de muchas tareas, se enfoca en la solución de un único problema [26, p. 31].

2.2.2. Paradigmas de Programaci´on Paralela

Una aplicación paralela se constituye de una colección de tareas relacionadas a la solución de un único problema. Estas tareas son eventualmente mapeadas a varia unidades de procesamiento disponibles en un computador paralelo. En consecuencia, un paradigma o estilo de programación paralela es la forma de estructurar un algoritmo paralelo seleccionando una técnica de descomposición del problema y posteriormente una técnica para el mapeo de las tareas subya-centes en un computador paralelo [145, p. 16] [80, sección. 3.6]. Varias técnicas de descomposición del problema son mostradas en [80]. Por otro lado, los para-digmas de programación más comunes para el diseño de aplicaciones paralelas en computación cient´ıfica son bag-of-tasks, parameter-sweep, master-worker y single program multiple data.

De acuerdo con las caracter´ısticas de una aplicación paralela, es decir, si es embarazosamente paralela o no, esta puede ser más adecuada para un grupo determinado de paradigmas. Aplicaciones cient´ıficas embarazosamente paralelas son desarrolladas con mayor frecuencia en base a los paradigmas bag-of-task, parameter-sweep y master-worker. Mientras aplicaciones cient´ıficas no embara-zosamente paralelas emplean de manera recurrente sigle program multiple data. A continuación se explica de forma breve cada paradigma.

Bag of Tasks

Bag of Tasks (BoT), una aplicaci´on que sigue este paradigma se compone de una colecci´on de tareas independientes o “bolsa de tareas”. Cada tarea cuenta con sus propios archivos de entrada y produce sus propios archivos de salida. Las

(18)

6 2.2. Aplicaci´on Paralela

tareas pueden ser ejecutadas en cualquier orden.

Por lo general, este tipo de aplicaciones emplea un middleware que es el encar-gado de mantener las tareas en una bolsa o cola, mapear las tareas a los recursos de cómputo y además es el responsable de recolectar los resultados de cada tarea individual [26, p. 154,p. 211] [136]. Los middleware también son conocidos como batch-scheduler.

Ejemplos de aplicaciones que siguen el paradigma BoT incluye simulaciones Mon-te Carlo, búsquedas masivas, manipulación de imágenes y miner´ıa de datos [136, p. 1].

Parameter-Sweep

Parameter Sweep (PS) es una forma particular de bag of tasks. En PS las tareas son idénticas, pero var´ıan los parámetros provistos para la ejecución de cada una [26, p. 217]. Aplicaciones bajo este paradigma se caracterizan porque las tareas consideran el mismo problema pero con diferentes parámetros. Master-Worker

Master-Slave o Master-Worker (MW), es una forma no trivial de bag of tasks [30, p. 33]. Una aplicación que sigue este paradigma distingue dos actores o entidades el maestro y los trabajadores. El maestro se encarga de descomponer el problema o archivo de entrada en pequeñas tareas y las distribuye entre los trabajadores. El trabajador recibe la tarea del maestro, la ejecuta y env´ıa los resultados al maestro [30, p. 60] [53, p. 35]. Normalmente, el maestro después de recibir los resultados genera un único resultado como resultado de toda la aplicación. En algunas implementaciones no hay un maestro explicito presente [111]. Información adicional de este paradigma puede encontrarse en [151]. La Figura 2.1 ilustra la estructura de una aplicación MW.

Master

distribute tasks

Slave 1 Slave 2 Slave 3 Slave 4

Collect Results

Communications

(19)

Introducci´on 7

Single Program Multiple Data

Este paradigma es ampliamente usado en simulaciones donde los problemas abordados tienen una representación geométrica en el mundo real. Ejemplos de este tipo de problemas son (1) distribución del calor o evolución del calor en el tiempo; (2) electromagnetismo; (3) predicción del clima. Estos problemas usan una representación geométrica del dominio del problema en dos o tres dimen-siones. El dominio se considera como una cuadr´ıcula de celdas, cada una de las cuales t´ıpicamente se refiere a una ubicación f´ısica o parte del espacio en el que se simula un fenómeno determinado [53, p. 39-55]. Eventualmente el dominio del problema es dividido en subdominios, dado que cada subdominio por lo general requiere información de los subdominios vecinos, estos deben comunicarse. En este caso cada subdominio puede ser visto como una tarea en una aplicación paralela, as´ı mismo la necesidad de comunicación entre subdominios, implica la necesidad de comunicación entre tareas. La Figura 2.2 ilustra la estructura de una aplicación que sigue el paradigma SPMD.

Distribute Data Calculate Exchange Calculate Collect Results Calculate Exchange Calculate Calculate Exchange Calculate Calculate Exchange Calculate

Figura 2.2 Ejemplo Paradigma SPMD [145, p. 21]

En el paradigma Single Program Multiple Data (SPMD), todos los procesos alo-jados en un computador paralelo (sistema de memoria compartida o distribuida), ejecutan el mismo programa (Single Program) en paralelo, pero cada proceso se encarga del procesamiento de un subdominio distinto del problema (Multiple Da-ta) [111]. Es decir, m´ultiples instancias del mismo programa son ejecutadas en diferentes procesadores, cada instancia opera en una parte del dominio del pro-blema [129, p. 6]. Por lo general, los procesos que corren en paralelo se comunican para intercambiar informaci´on y sincronizarse durante el procesamiento.

2.3 High Performance Computing

High Performance Computing (HPC) denota todas las actividades involu-cradas en el diseño, manufactura, o uso de supercomputadores. En particular, HPC es el uso de supercomputadores para la solución, en principio, de aplicacio-nes cient´ıficas de gran relevancia, los “grand challenges”. La solución a este tipo de problemas requiere una gran cantidad de poder computacional. El término “high performance compiting” es sinónimo de “supercomputación” y “high-end computing”. La definición anterior es un consenso a partir del estudio de varias definiciones dadas en [52, p. 20] [95, p. 3-4] [64, p. 1,p. 4] [26, p. 213] [97] [21, p. 103] [60, p. 3] [87] [52, p. 67]. Sin embargo, una definición más conveniente se presenta como sigue. La supercomputación es un paradigma de computación

(20)

8 2.3. High Performance Computing

que define: (1) cómo deben ser construidos los supercomputadores para alcan-zar una elevada capacidad de cómputo y (2) cómo deben ser desarrolladas las aplicaciones para este tipo de sistemas para tomar ventaja de esta capacidad computacional.

Los grandes desaf´ıos de la computación o “grand challenges” son problemas en diferentes áreas de la ciencia e ingenier´ıa cuya solución generar´ıa alto impacto cient´ıfico, económico, pol´ıtico ó social [95, p. 3-4] [13, p. 2]. Este listado de proble-mas es actualizado en la medida en que la solución para los distintos problemas es habilitado con los avances en computación [13, p. 5].

Las aplicaciones de la supercomputación se extienden por muchos dominios im-portantes en ciencia, ingenier´ıa, negocios, educación, atención médica, control de tráfico, Internet y servicios web, militares y aplicaciones gubernamentales [96, p. 9-10]. En particular, en el dominio de la ciencia e ingenier´ıa la supercompu-tación es empleada constantemente para la solución a problemas relacionados con f´ısica cuántica, el pronóstico del tiempo, la investigación climática, el mode-lado molecular (cálculo de las estructuras y propiedades de compuestos qu´ımicos, macromoléculas biológicas, pol´ımeros y cristales), simulaciones f´ısicas (como la simulación de aviones en túneles de viento, cosmolog´ıa, simulación de la detona-ción de armas nucleares, investigación en fusión nuclear) y como nueva área de aplicación, miner´ıa de datos o big data [116, p. 10].

2.3.1. Sistema de C´omputo HPC

Un supercomputador o sistema de cómputo HPC, es un sistema de cómputo que está a la vanguardia en tecnolog´ıa conocida en computación para la solución de problemas en ciencia e ingeniar´ıa [48, p. 1] [48, p. 1] [74, p. 465]. Lo anterior hace que un supercomputador sea: (1) un sistema de cómputo que proporciona un rendimiento sostenido significativamente mayor que el disponible en la ma-yor´ıa de sistemas de cómputo contemporáneos [52, p. 21] y (2) un sistema de cómputo que funciona a una velocidad muy superior a la de otras computadoras contemporáneas [116, p. 3].

El aspecto “tecnológico” en la definición de supercomputador hace que lo que co-nocemos como “supercomputador” sea susceptible al tiempo. Dado que la tecno-log´ıa empleada en computación está en constante cambio, un sistema de cómputo considerado como “supercomputador” el d´ıa de hoy, puede perder su etiqueta el d´ıa de mañana. El efecto de la tecnolog´ıa en la evolución de los computadores es descrito por Gordon Bell y se conoce como la ley de Bell [19].

Un sistema de cómputo adquiere su etiqueta de “supercomputador” si prue-ba estar entre los computadores más veloces vigentes en la actualidad. En la actualidad, los computadores mas veloces del mundo o supercomputadores se encuentran consignados en el TOP5001. Para clasificar en este listado y en efec-to obtener la etiqueta de “supercomputador”, el sistema de cómputo debe correr el benchmark Linkpack2. Linkpack mide la capacidad de un sistemas de cómputo para resolver sistemas densos de ecuaciones lineales. Como resultado de ejecutar

1_{https://www.top500.org/} 2

(21)

Introducci´on 9

Linkpack se obtiene la velocidad del sistema de cómputo expresada en cantidad de operaciones flotante que puede llevar a cabo el sistema de cómputo por segun-do, FLOPS por float operations per second. Para Noviembre de 2019 el super-computador más rápido del mundo libera una velocidad de 148, 600.0 TFlop/s, donde T es la sigla de Tera.

Con respecto a Linkpack y al TOP500 dos criticas se han presentado en la literatura. En primera instancia, Linkpack únicamente mide la capacidad de un sistema de cómputo para resolver sistemas de ecuaciones lineales. Lo anterior hacer que esta medida no sea diciente respecto a la capacidad que tiene un sistema de cómputo para abordar problemas reales [116, p. 17] [52, p. 45,p. 289] [66]. Sin embargo, el argumento que plantean los expertos para considerar Linkpack como ´

unica métrica, radica en que este enfoque de clasificación, además de ser el más simple, ha tenido gran nivel de aceptación al punto que impulsa el desarrollo de la tecnolog´ıa en computadores, promoviendo la competencia entre fabricantes [153]. En segundo lugar, algunos sistemas de cómputo no son reportados en el TOP500. En algunos casos, las organizaciones no desean que se conozca el potencial de sus sistemas de cómputo, ya sea por razones de seguridad, competitividad o costos que implican la realización de Linkpack [52, p. 45].

Caracter´ısticas

Las caracter´ısticas de los supercomputadores han cambiado constantemente de generación en generación. Anteriormente un supercomputador era un sistema de cómputo de gran tamaño con múltiples unidades de procesamiento. En la actualidad, un supercomputador es un sistema distribuido que se compone de muchos computadores autónomos interconectados por una red de altas prestacio-nes. Para describir los caracter´ısticas de los supercomputadores consideramos 11 aspectos que surgen a partir de las diferentes formas empleadas en la literatura para describir los supercomputadores [96, p. 5,p. 7-8,p. 27,p. 66-69,p. 568] [148, p. 633] [165]. En el Cuadro 2.1 se muestran las caracter´ısticas más comunes de los supercomputadores.

Clase de sistema distribuido, cuatro tipos de sistemas distribuidos son men-cionados en la literatura Peer-to-peer, Clústers Computacionales, Grid Compu-tacionales y Plataformas Cloud [157] [96, p. 27], donde los clústers son empleados con mayor frecuencia para la construcción de supercomputadores.

Acoplamiento de los Componentes, es una de las caracter´ısticas más con-sideradas en la literatura para referirse a supercomputadores. Un sistema de cómputo distribuido puede ser fuerte o débil -mente acoplado, considerando las cualidades de la red que interconecta los nodos o componentes del sistema. Según Bal y col. [1] un sistema distribuido fuertemente acoplado presenta una red de comunicación confiable y de alta velocidad, mientras que un sistema débilmente acoplado presenta un canal de comunicación no confiable y de baja velocidad de comunicación.

Un sistema distribuido fuertemente acoplado es por lo general un sistema de c´omputo compacto donde los nodos son empaquetados en estructuras llamadas blade servers o racks. Cada nodo es llamado de forma indistinta como blade.

(22)

Cuadro 2.1 Caracter´ısticas de un Sistema de c´omputo HPC

Caracter´ıstica Descripci´on

Clase de Sistema Distribuido Cl´uster

Acoplamiento de los Componentes Fuerte

Localizaci´on de los componentes LAN

Costo de los Componentes Alto

Control del Sistema Centralizado

Volatilidad de los Componentes Alta

Capacidad de los Componentes Homog´enea

Prop´osito de los Componentes Especifico

Dedicaci´on de los Componentes Dedicados

Flexibilidad en el Despliegue de Aplicaciones No Embarazosamente Paralelas y

Embarazosamente Paralelas

Modelos de Programaci´on Distribuida MPI, PVM

Paradigmas de Programaci´on Distribuida SPMD, Master-Worker,

Bag-of-Task, Parameter Sweep

As´ı mismo, cada blade o nodo de procesamiento cuenta con procesadores, me-moria, y disco duro [148, p. 638]. Los blades y blade servers son interconectados mediante protocolos y tecnolog´ıas de red optimizados para reducir la latencia de comunicación entre nodos. La red de interconexión entre nodos emplea tec-nolog´ıas de red basadas en el estándar InfiniBand3 o Gigabit Ethernet4 (10G, 25G y 40G) [45, p. 41-49] [45, p. 35]. Ambas son las tecnolog´ıas de interconexión que dominan en el diseño de supercomputadores según el TOP500, sin embargo, InfiniBand es la tecnolog´ıa que presenta mejor desempeño hasta la fecha. Un sistema distribuido débilmente acoplado a diferencia del anterior, no es un sistema compacto. La tecnolog´ıa de interconexión entre nodos es de mediano o bajo costo y se basa en estándares de red como Gigabit Ethernet en el mejor de los casos [156, p. 17], o Ethernet en el peor caso.

Localización de los componentes, los componentes de un sistema distribuido pueden localizarse en una red de área local LAN, una red más amplia WAN o Internet.

Costo de los componentes, los nodos de un sistema distribuido pueden ser de bajo o alto costo. Lo anterior dependiendo de qué tan especializados son los componentes como procesadores, interconexión, etc. Por lo general, los nodo de alto costo comprenden componentes diseñados exclusivamente para computación

3_{Es un est´}_{andar para el dise˜}_{no de redes de gran ancho de banda y baja latencia, que}

per-mite la comunicaci´on entre nodos a altas velocidades. Provee mecanismos como Remote Direct Memory Access, kernel bypass, Zero Copy, y Transport offload [45, p. 41-43].

4

Es una extensión de Ethernet tradicional para proveer mayor ancho de banda en la comu-nicación, funciona bajo el protocolo TCP/IP. As´ı mismo es una solución de bajo costo para la interconexión de clústers. A pesar de reducir la latencia de comunicación entre nodos, estu-dios en el 2009 como [50] demuestran que presenta mayores latencias frente a InfiniBand. Sin embargo, para el 2013, el estudio [132] muestra que InfiniBand y Gigabit Ethernet pueden ser comparables con la introducción de la tecnolog´ıa iWARP para Gigabit Ethernet que habilita soporte para Remote Direct Memory Access (RDMA). Mas información relacionada puede ser encontrada en [103, p. 186].

(23)

Introducci´on 11

cient´ıfica. Mientras que los nodos de bajo costo comprenden componentes como procesadores y memoria que son de uso comercial [148, p. 633].

Control del Sistema, un sistema distribuido puede ser controlado o adminis-trado de manera centralizada o descentralizada. El control es centralizado cuando el sistema en general es administrado por una organizaci´on o propietario. Por otro lado, el sistema tiene control descentralizado si los componentes (nodos) tienen propietarios individuales [96, p. 66-69].

Volatilidad de los Componentes, hace referencia a la probabilidad de que un componente deje de formar parte del sistema de manera repentina o no es-perada. Por lo general, esta probabilidad es baja en sistemas administrados por una organizaci´on y alta en sistemas distribuidos donde los componentes tienen propietarios individuales.

Capacidad de los Componentes, describe si los componentes del sistema distribuido en general poseen capacidades de cómputo equivalente, es decir son homogéneos o por el contrario las capacidades de los componentes varia, es decir, es heterogénea [96, p. 5].

Propósito de los Componentes, se refiere al objetivo con el cual los compo-nentes del sistema distribuido son diseñados. En este aspecto, los componentes pueden ser de propósito espec´ıfico o de propósito general. Por ejemplo, los compo-nentes de un supercomputador son diseñados exclusivamente para computación cient´ıfica. Mientras que los componentes de otro tipo de sistemas son diseñados para computación de propósito general.

Dedicación de los Componentes, indica si los componentes o el mismo siste-ma distribuido es un recurso de cómputo dedicado o no dedicado [96, p. 66-69]. En este ámbito, dedicado significa que si una aplicación es ejecutada en un grupo de nodos del sistema distribuido, esta aplicación tiene uso exclusivo de estos recur-sos. Lo anterior implica que: (1) la aplicación no comparte recursos y no puede ser removida del sistema hasta haber finalizado. Por otro lado, no dedicado significa que una aplicación no tiene uso exclusivo de los recursos de cómputo que emplea y además, la ejecución de la aplicación puede ser detenida en cualquier momento. Flexibilidad en el despliegue de aplicaciones paralelas, considera el ti-po de aplicaciones paralelas que son abordadas con gran facilidad en el sistema distribuido. Los supercomputadores funcionan bien tanto para aplicaciones em-barazosamente paralelas como aquellas que no lo son [96, p. 7-8].

Modelos de Programación, en supercomputación, las aplicaciones paralelas generalmente son desarrolladas en base al estándar MPI [45, p. 50]. MPI describe una serie de operaciones que permiten el desarrollo de aplicaciones paralelas que corren en sistemas distribuidos, t´ıpicamente clústers catalogados como super-computadores. Los supercomputadores brindan un gran soporte pero no están limitados a aplicaciones basadas en MPI.

(24)

paralelas existentes, los mas relevantes son mencionados en la Secci´on 2.2.2. En particular, los supercomputadores soportan todos estos paradigmas.

2.3.2. Aplicaci´on HPC

Una aplicación HPC es una aplicación paralela, t´ıpicamente cient´ıfica, que es desarrollada para ser ejecutada en un supercomputador. Lo anterior implica que este tipo de aplicaciones emplean algoritmos, modelos y paradigmas de progra-mación orientados a supercomputadores. Las aplicaciones HPC son programadas por lo general bajo el estándar MPI5_{. En consecuencia, aplicaciones HPC son}

en-contradas en la literatura como aplicaciones MPI. Los términos aplicación HPC y aplicación MPI son empleados de forma intercambiable en el presente trabajo. Las caracter´ısticas de una aplicación HPC se muestran a continuación.

Caracter´ısticas

Del amplio número de caracter´ısticas empleadas para describir una aplica-ción HPC en el presente trabajo consideramos 5. Creemos estas 5 caracter´ısticas permiten describir las propiedades esenciales de una aplicación HPC. Estas 5 caracter´ısticas se basan en [26, p. 213] [49] [163, p. 1714] [144]. El Cuadro 2.2 muestra el perfil general de una aplicación HPC basado en las 5 caracter´ısticas mencionadas.

Cuadro 2.2 Perfil General de una Aplicaci´on HPC

Tipo de Aplicaci´on Paralela No Embarazosamente Paralela

Acoplamiento de las Tareas Fuerte

Intensidad en el uso de CPU Alta

Intensidad en el uso de I/O Baja

Sensibilidad a los retrasos en la comunicaci´on entre Tareas Alta

Tipo de Aplicaci´on Paralela, aunque los supercomputadores soportan tan-to aplicaciones embarazosamente paralelas como no-embarazosamente paralelas. Las aplicaciones HPC son com´unmente aplicaciones no-embarazosamente para-lelas.

Acoplamiento de las Tareas, las tareas de una aplicación paralela pueden requerir comunicación entre las mismas como no requerir comunicación. En con-secuencia, aplicaciones paralelas que requieren comunicación entre tareas son comúnmente llamadas aplicaciones fuertemente acopladas. El término acopla-miento también puede relacionarse al nivel de interdependencia entre las tareas de la aplicación paralela. Por otro lado, aplicaciones paralelas que no requieren comunicación entre tareas son llamadas en la literatura como aplicaciones d´ ebil-mente acopladas. As´ı mismo, este termino puede ser asociado a que la falla de una tarea puede no afectar el funcionamiento de toda la aplicación.

5

MPI (Message Passing Interface) es el estándar de facto para la implementación de apli-caciones HPC. De forma breve, MPI permite el desarrollo de apliapli-caciones paralelas que serán ejecutadas, eventualmente, en sistemas distribuidos tales como los supercomputadores. En una aplicación MPI, los múltiples procesos de la aplicación cooperan bajo el paradigma de paso de mensajes para la solución de un único problema.

(25)

Introducci´on 13

Por lo general, el tipo de aplicaci´on paralela determina el acoplamiento de la mis-ma. Aplicaciones no-embarazosamente paralelas son implementadas como apli-caciones fuertemente acopladas, mientras que apliapli-caciones embarazosamente pa-ralelas son implementadas como aplicaciones d´ebilmente acopladas.

Intensidad en el uso de CPU, una aplicación es intensiva en el uso de CPU si los procesos empleados para la ejecución de la aplicación realizan más operacio-nes aritméticas que operaciones de entrada/salida (I/O) [69, p. G-8,p. 112]. Las aplicaciones HPC son por lo general aplicaciones cient´ıficas que abordan modelos matemáticos. El cómputo matemático demanda uso intensivo, elevado o alto de las unidades de punto flotante en los procesadores. Aplicaciones que realizan más operaciones de entrada/salida presentan una intensidad baja en el uso de la CPU. Intensidad en el uso de I/O, considera la cantidad de operaciones de entra-da y salientra-da que lleva a cabo una aplicación HPC. Por lo general, para acelerar el cómputo, las aplicaciones cargan la información necesaria a la memoria para evitar lecturas a disco cuyo costo computacional es elevado.

Al aumentar la cantidad de operaciones I/O, se reduce la intensidad de uso de CPU.

Sensibilidad a los retrasos en la comunicaci´on entre Tareas, las aplicacio-nes HPC pueden ser sensibles a dos aspectos intr´ınsecos en la red que interconecta los nodos de un supercomputador o sistema distribuido: la latencia y el ancho de banda. Hay una gran cantidad de aplicaciones HPC que requieren redes de baja latencia y un alto ancho de banda. Estas aplicaciones son altamente sensibles a cualquier cambio en las caracter´ısticas de las red. Un cambio en las caracter´ısti-cas de la red pueden aumentar de manera importante el rendimiento como puede disminuirlo considerablemente [49] [26, p. 213] [60] [100].

Aplicaciones HPC sensibles a los retrasos de comunicaci´on en la red se dice que son aplicaciones sensibles a la latencia, o latency-sensitive applications.

2.4 High Throughput Computing

High-throughput computing (HTC) es el uso de sistemas distribuidos para aplicaciones que requieren una cantidad elevada de poder computacional por periodos de tiempo prolongados (semanas, meses) [108] [26, p. 213-214] [151]. El principal desaf´ıo al que se enfrenta un entorno HTC es cómo maximizar la cantidad de recursos accesibles a los usuarios [108, p. 36] [18]. Para maximizar la capacidad computacional del entorno, un entorno HTC debe utilizar recursos heterogéneos [18]. Tradicionalmente, los Grids que se componen de recursos he-terogéneos (clústers, estaciones de trabajo, desktop voluntarios) han sido usados para soportar HTC [26, p. 213-214]. En resumen, high throughput computing es un paradigma de computación que define: (1) cómo usar los recursos computacio-nales disponibles en un sistema distribuido para formar un sistema de cómputo de gran capacidad computacional y (2) cómo deben ser desarrolladas las apli-caciones para este tipo de sistemas y, en efecto puedan tomar ventaja de esta capacidad computacional.

(26)

14 2.4. High Throughput Computing

2.4.1. Sistemas de c´omputo HTC

Un sistema distribuido empleado para hacer computación HTC es cataloga-do como sistema de cómputo HTC. Lo anterior implica que cualquier sistema distribuido siempre que sea usado con frecuencia para hacer computación HTC puede ser catalogado como sistema de cómputo HTC.

Un sistema de cómputo HTC debe emplea un administrador de recursos, resource management framework o middleware [18]. Este administrador de recursos como m´ınimo tiene dos propósitos: (1) mantener información de los recursos compu-tacionales disponibles para hacer cómputo y (2) brindar a los usuarios acceso a esta capacidad computacional. Dependiendo de las implementaciones particula-res, este administrador de recursos puede tener más funcionalidades.

Los recursos de un sistema de cómputo HTC pueden ser dedicados como no de-dicados. En este sentido, de manera cambiante, los recursos pueden estar dispo-nibles total, parcial o no estar dispodispo-nibles en el sistema. As´ı mismo, se asume que los recursos poseen propietarios individuales, es decir el control de los recursos es descentralizado. La propiedad descentralizada a menudo resulta en un man-tenimiento descentralizado, cuando los propietarios de los recursos mantienen y configuran cada recurso para un uso espec´ıfico. Para maximizar la capacidad computacional, el sistema HTC debe utilizar gran cantidad de recursos compu-tacionales existentes en la red, por lo general, recursos con diferentes capacidades y caracter´ısticas. Por todo lo anterior, los sistemas HTC deben superar varios desaf´ıos entre los cuales se listan: (1) utilización de recursos heterogéneos, (2) la utilización de recursos no dedicados y (3) proveer un ambiente de cómputo con-fiable para las aplicaciones de los usuarios y garantizar al propietario del recurso total control sobre el mismo [108, p. 36] [18].

Caracter´ısticas

Las caracter´ısticas más comunes de un sistema de cómputo HTC son mos-tradas en el Cuadro 2.3. Este cuadro considera los mismos aspectos empleados para describir un sistema de cómputo HPC (Sección 2.3.1).

Note que los sistemas de cómputo HTC no están limitados a estas caracter´ısticas (Cuadro 2.3), dado que estas dependen del sistema distribuido considerado. Sin embargo, sistemas distribuidos considerados con mayor frecuencia como sistemas de cómputo HTC, cumplen con estas caracter´ısticas.

2.4.2. Aplicaciones HTC

Una aplicación HTC es una aplicación paralela, comúnmente cient´ıfica, que es desarrollada para se ejecutada en un sistema de cómputo HTC. En general, una aplicación HTC es una aplicación paralela que comprende una gran cantidad de tareas. Es común que dichas tareas sean independientes y por lo tanto, pueden ser distribuidas a lo largo de recursos de cómputo ubicados en una Red de Área Local (LAN) ó Internet. Aplicaciones HTC son soportadas tradicionalmente por

(27)

Introducci´on 15

Cuadro 2.3 Caracter´ısticas de un Sistema de C´omputo HTC

Clase de Sistema Distribuido Peer-to-peer, Cl´usters

Computacio-nales, Grid Computacionales y Pla-taformas Cloud

Acoplamiento de los Componentes D´ebil

Localizaci´on de los Componentes LAN, WAN, Internet

Costo de los Componentes Bajo

Control del Sistema Distribuido

Volatilidad de los Componentes Baja

Capacidad de los Componentes Heterog´enea

Prop´osito de los Componentes General

Dedicaci´on de los Componentes Dedicados y No Dedicados

Flexibilidad en el Despliegue de Aplicaciones Embarazosamente Paralelas

Modelos de Programaci´on Distribuida Depende del Sistema

Paradigmas de Programaci´on Distribuida Bag-of-Task, Master-Worker,

Para-meter Sweep

clústeres de estaciones de trabajo, sistemas de computación voluntarios, siste-mas Desktop Grid, entre otros sistesiste-mas distribuidos [26, p. 213-214] [9, p. 100]. Ejemplos clásicos de este tipo de aplicaciones son análisis de sensibilidad, estu-dios paramétricos, simulaciones para establecer la confianza estad´ıstica o análisis basados en Monte Carlo [94] [26, p. 213-214].

Caracter´ısticas

Para describir las caracter´ısticas de una aplicación HTC, empleamos los 5 aspectos considerados para caracterizar aplicaciones HPC (Sección 2.3.2). Las caracter´ısticas t´ıpicas de una aplicación HTC se muestran en el Cuadro 2.4.

Cuadro 2.4 Perfil General de una Aplicaci´on HTC

Tipo de Aplicaci´on Paralela Embarazosamente Paralela

Acoplamiento de las Tareas D´ebil

Intensidad en el uso de CPU Alta

Intensidad en el uso de I/O Baja

Sensibilidad a los retrasos en la comunicaci´on entre Tareas Baja

2.5 Desktop Grids

Los Desktop Grids (DGs) son sistemas distribuidos que utilizan la capaci-dad de cómputo disponible en computadores de escritorio (PCs, Estaciones de Trabajo) distribuidos a lo largo de redes de área local en organizaciones o, In-ternet [56, p. 261-262] [6] [17]. Los Desktop Grids son un tipo particular de Grid [154, p. 35] [6], además son plataformas de computación apropiadas para high throughput computing (HTC) [65, p. 171] [102].

Varios estudios han demostrado que las computadoras personales permanecen frecuentemente inactivas o al menos su capacidad no es empleada por comple-to [154, p. 35] [30, p. 32]. Con el desarrollo de computadores multi-n´ucleo, y

(28)

16 2.5. Desktop Grids

con la estandarizaci´on en el uso de GPUs para las computadoras personales, la capacidad disponible en recursos computacionales probablemente aumente [154, p. 35]. Entre las diferentes aproximaciones ideadas para tomar ventaja de estos recursos, nace el Desktop Grid Computing.

Los Desktop Grid han mostrado ser sistemas atractivos para la computación cient´ıfica porque son capaces de alcanzar una capacidad computacional equiva-lente o superior a la de los supercomputadores para cierto tipo de aplicaciones. En Junio de 2019, la plataforma Desktop Grid BOINC6 registró una capacidad computacional de 29.717 PetaFLOPS. En esa misma fecha el supercomputador más rápido en el mundo registro una capacidad computacional de 148, 600.0 Te-raFLOPs7. As´ı mismo en la historia se presentan varios antecedentes como [20] [51, p. 6] [150] que demuestran el potencial de las plataformas Desktop Grid. Aunque, no todas las aplicaciones cient´ıficas son abordadas con la misma efi-ciencia que ofrecen los supercomputadores [51, p. 6].

Considerando a la localización de los recursos, red LAN o Internet, los siste-mas Desktop Grid pueden ser clasificados como Desktop Grid Empresariales (DGE) o Desktop Grid Voluntarios (DGV) [41] [65, p. 175] [17, p. 18-19] [117, p. 11-13]. Los DGV se basan en recursos de cómputo donados de forma voluntaria por participantes provenientes de Internet. Por otra parte, los DGE se basan en recursos de cómputo alojados en una organización o Universidad comprendidos en una red de área local LAN [41].

2.5.1. Sistema de C´omputo Desktop Grid

Básicamente un sistema Desktop Grid (DG) se constituye a partir de tres componentes: clientes, que env´ıan tareas para ser ejecutadas en el sistema DG; un coordinador, también llamado Desktop Grid Middleware [56, p. 264], en-cargado de asignar las diferentes tareas sometidas por los clientes a los diferentes trabajadores disponibles, as´ı mismo se encarga de la recolección de los resulta-dos; y trabajadores o computadores de escritorio, encargados de ejecutar las tareas de los clientes y retornar resultados; [30, p. 33] [65, p. 175].

Adicional a los componentes mencionados anteriormente, los sistemas Desktop Grid deben contar con un mecanismo de control de impacto y de manera deseable una herramienta de monitoreo de los recursos. El mecanismo de control de impacto debe asegurarse de que las tareas que provienen del siste-ma Desktop Grid no afecten la integridad y rendimiento de las tareas de los propietarios de los recursos. Por otra parte, las herramientas de monitoreo de recursos son deseables para la detecci´on de fallas y otros aspectos que permiten el fortalecimiento de la confiabilidad del sistema Desktop Grid [134, p. 54-55].

Caracter´ısticas

Los sistemas Desktop Grid en general comparten muchas de las caracter´ısti-cas que presenta los sistemas de cómputo usados comúnmente para computación

6_{https://boinc.berkeley.edu/} 7

(29)

Introducci´on 17

HTC. Las caracter´ısticas de los sistemas Desktop Grid Voluntarios y Empresa-riales se muestran en el Cuadro 2.5. Estas caracter´ısticas fueron tomadas de [102] [6] [17] [65], [154] y [117, p. 11-13].

Cuadro 2.5 Caracter´ısticas Sistemas Desktop Grid Empresariales y Voluntarios.

Caracter´ıstica Desktop Grid Voluntario (DGV) Desktop Grid Empresarial (DGE)

Clase de Sistema Distribuido Desktop Grid Desktop Grid

Acoplamiento de los Componentes Deb´ıl Deb´ıl

Localizaci´on de los Componentes* Internet LAN

Costo de los Componentes Bajo Bajo

Administraci´on de los Componentes* Decentralizado Casi Centralizado

Volatilidad de los Componentes* Alta Media (Menor que en DGV)

Capacidad de los Componentes* Heterogenea Homogenea

Prop´osito de los Componentes General General

Dedicaci´on de los Componentes No Dedicado No Dedicado

Flexibilidad en el Despliege de Aplicaciones Embarazosamente Paralelas Embarazosamente Paralelas Modelos de Programación Distribuida No hay un estándar No hay un estándar

Paradigmas de Programaci´on Distribuida Bag-of-Task, Master-Worker, Parameter Sweep Bag-of-Task, Master-Worker, Parameter Sweep

Trieflinger [154, p. 36-37], de manera simplificada, propone tres caracter´ısticas que describen las propiedades de los sistemas Desktop Grid de manera general: (1) volatilidad, (2) heterogeneidad y conectividad limitada. En el presente trabajo hacemos ´enfasis en estas caracter´ısticas de forma recurrente.

Lo que respecta a la volatilidad, los recursos de un sistema de c´omputo Desk-top Grid al ser recursos no dedicados, pueden unirse o abandonar el sistema de manera impredecible [65, p. 174]. Los recursos pueden presentar fallas o ser requeridos por sus respectivos propietarios para uso exclusivo. Los dos aspectos anteriores hacen que este tipo de sistemas presenten una baja confiabilidad [6] [117, p. 13] [154, p. 36].

Con relación a la conectividad limitada, la red que interconecta los recursos computacionales en un sistema Desktop Grid son diseñadas con protocolos con-vencionales para computación de propósito general, pero no para computación cient´ıfica [65, p. 174]. Esto hace que muchas de las aplicaciones cient´ıficas que hacen uso intensivo de la red no experimenten un buen rendimiento. Las apli-caciones cient´ıficas que hacen uso intensivo de la red requieren bajas latencias y alto ancho de banda. El requerimiento anterior es dif´ıcil de encontrar en sistemas Desktop Grid [154, p. 36-41].

Finalmente, la heterogeneidad en sistemas Desktop Grid Voluntarios es eleva-da tanto en las capacieleva-dades de los recursos de cómputo como en la red que interconecta los recursos. Por el contrario, los sistemas Desktop Grid Empresa-riales presentan por lo general uniformidad en las capacidades de los recursos de cómputo, pero las capacidades de red siguen siendo heterogéneas. En efecto al-gunas aplicaciones cient´ıficas son sensibles a la heterogeneidad [154, p. 36-37] [41].

2.5.2. Aplicaciones para Sistemas Desktop Grid

Las caracter´ısticas intr´ınsecas en sistemas Desktop Grid (heterogeneidad, vo-latilidad y conectividad limitada) hacen que este tipo de plataformas sean consi-deradas con éxito para aplicaciones cient´ıficas que son embarazosamente parale-las, también conocidas como aplicaciones HTC. Prácticamente, las aplicaciones HTC toleran aspectos como la heterogeneidad y la conectividad limitada, pero

(30)

18 2.6. Discusi´on

pueden fallar al presentarse la volatilidad. Sin embargo, el hecho de que las apli-caciones HTC sean apliapli-caciones embarazosamente paralelas permite que este tipo de aplicaciones sea integrado con mecanismos simples de detección y tolerancia a fallos [65, p. 172]. Estos mecanismos se basan en el hecho de que la falla de una tareas de la aplicación no compromete la integridad de la misma, dado que estas tareas son independientes y pueden ser recuperadas de forma independiente. Por otra lado, aplicaciones cient´ıficas no-embarazosamente paralelas, que termi-nan convirtiéndose en aplicaciones HPC, son menos tolerantes a la heterogenei-dad, conectividad limitada y volatilidad. Por lo anterior, soportar este tipo de aplicaciones en sistemas Desktop Grid es prácticamente un reto. El hecho de que las tareas que comprenden una aplicación HPC guarden dependencias entre si, implica que la falla de una tareas compromete la integridad de toda la aplicación. Como consecuencia, los Desktop Grid ha sido usados principalmente para High Throughput Computing (HTC) [154, p. 37].

2.6 Discusi´

on

Los Desktop Grid han mostrado ser sistemas atractivos para la computaci´on cient´ıfica porque son capaces de alcanzar una capacidad computacional equi-valente o superior a la de los supercomputadores. Sin embargo, caracter´ısticas como heterogeneidad, volatilidad y conectividad limitada intr´ınsecas en sistemas Desktop Grid limitan el rango de aplicaciones cient´ıficas que pueden ser abor-dadas con facilidad en este tipo de sistemas. Las aplicaciones HTC han probado ser abordadas de manera exitosa, mientras que las aplicaciones HPC han demos-trado ser un gran reto para este tipo de sistemas.

Lo cierto es que existe un creciente interés por abordar aplicaciones que son con-sideradas en supercomputación, aplicaciones HPC, en sistemas Desktop Grid. Lo anterior, porque los sistemas Desktop Grid presentan una mejor relación costo beneficio con respecto a los supercomputadores. En este aspecto varios trabajos se han presentado en la literatura con el objeto de brindar soporte a aplicaciones HPC en sistemas Desktop Grid.

En el presente trabajo de grado, hacemos una revisión de los esfuerzos empleados en la literatura enfocados al soporte de aplicaciones HPC en sistemas Desktop Grid. Es decir, estudiamos cómo los sistemas Desktop Grid existentes han miti-gado problemáticas como la heterogeneidad, volatilidad y conectividad limitada para el soporte de aplicaciones HPC. A partir del conocimiento obtenido pro-ponemos un sistema Desktop Grid que permita abordar aplicaciones HPC en ambientes Universitarios.

(31)

3

Estado del Arte

En el presente cap´ıtulo estudiamos cómo algunos sistemas Desktop Grid y similares han mitigado problemáticas como la heterogeneidad, volatilidad y co-nectividad limitada para la ejecución de aplicaciones cient´ıficas. En particular, hacemos énfasis en el soporte provisto a aplicaciones HPC. Al finalizar el cap´ıtulo resaltamos aspectos que hacen falta por resolver en el estado del arte y, respecto a estos identificamos el aspecto abordado en el presente trabajo de grado. El cap´ıtulo se organiza como sigue: la Sección 3.1 introduce el concepto de to-lerancia a fallos que es un aspecto fundamental para el soporte de aplicaciones cient´ıficas en sistemas Desktop Grid y similares que presentan alta probabili-dad de fallo. La Sección 3.2 presenta una revisión de literatura detallada acerca de cómo los sistemas Desktop Grid y similares soportan aplicaciones cient´ıficas HTC como HPC. La Sección 3.3 presenta un análisis de los aspectos relevantes identificados en la literatura. Para finalizar, se presentan las conclusiones del cap´ıtulo en la Sección 3.4.

3.1 Tolerancia a Fallos

En un sistema de cómputo desktop grid los recursos de cómputo pueden unir-se y/o dejar el sistema de manera impredecible. Un recurso de cómputo puede dejar el sistema por varias razones entre las cuales se listan: falla en el recursos, perdida de la conectividad del recurso con el servidor del sistema, el propietario o usuario del recurso ha retirado el recurso del sistema al apagar el equipo o reque-rir uso exclusivo del mismo. También puede suceder que el usuario por accidente desconecte de la red o del suministro energético el recursos computacional [78]. En consecuencia, aplicaciones cient´ıficas que son abordadas en sistemas desktop grid pueden presentar fallos con mayor probabilidad en comparación a sistemas de cómputo dedicado [154, p. 209]. Por lo tanto la implementación de estrategias de tolerancia a fallos en sistemas desktop grid se convierte en un requerimiento casi que inevitable [130] [16, p. 1].

(32)

20 3.1. Tolerancia a Fallos

Estudios de las diferentes fallas que se pueden presentar en sistemas desktop grid se evidencia en trabajos como el de Montoya [117] y Haider y col. [91, p. 9]. Donde el primero menciona las diferentes fallas que tienen lugar en sistemas Desktop Cloud y los otros se centran en Grid Computing. Por lo general, gran parte de las fallas que se presentan en sistemas Desktop Cloud y Grid Computing se presentan de igual forma en Desktop Grid dado que estos sistemas comparten algunas propiedades. Según Choi [41], los Desktop Grid son un tipo particular de Grid, pero estos difieren en muchos aspectos respecto a las caracter´ısticas de los recursos y la forma de compartir los recursos. Por otro lado, Montoya [117, p. 14] y Alwabel y col. [5] dicen que los Desktop Cloud surgen de la combinación entre la tecnolog´ıa de virtualización y los Desktop Grid.

La tolerancia a fallos es la propiedad que garantiza la entrega de los servicios esperados incluso en presencia de fallas [135, p. 101] [117, p. 20]. Permite que la aplicación continúe incluso en caso de falla [130]. De acuerdo al estudio de diferentes autores [93] [96, p. 101-104] [122, p. 48] [16, p. 1-2] [4, 860] [130, p. 37-38] [72, p. 89-91] [91, p. 6-7] [135] respecto a la tolerancia a fallos en Desktop Cloud, Desktop Grid, y Grid Computing, las técnicas o mecanismos de tolerancia a fallos empleaos de manera recurrente en la literatura son Fault-Tolerant Scheduling , Checkpoint/Recovery , Retry , y Replication . Donde Checkpoint/Recovery es el mecanismo más popular en la actualidad para la im-plementación de sistemas de cómputo tolerantes a fallos [91, p. 6-7] [72, p. 89-91]. En la Figura 3.1 se muestran los mecanismos empleados con mayor frecuencia en la literatura. Como se muestra en la figura, las técnicas de tolerancia a fa-llos se clasifican en pro-activas y post-activas en función de si el mecanismo de tolerancia a fallos actúa antes o después de estar la aplicación en ejecución en el sistema desktop grid [122, p. 47]. Las técnicas pro-activas intentan tomar de-cisiones acerca de cómo y dónde se ejecutará una aplicación, asumiendo que la decisión tomada implique que la aplicación no fallará.

Las técnicas pro-activas necesitan información sobre los recursos, tipos de fallas que se presentan en los recursos, y ocurrencia de fallas entre otros para tomar una decisión. Por otro lado, las técnicas de tolerancia a fallos post-activas manejan las fallas de la aplicación o de sus tareas después de que han ocurrido. Es decir, la falla se puede tolerar solo después de su detección [130, p. 37-38]. A continuación se describen de manera breve los diferentes mecanismos de tolerancia a fallos que pueden presentarse en sistemas desktop grid.

3.1.1. Retry

Retry es la técnica más simple para proporcionar tolerancia a fallos en un sistema desktop grid y en muchos casos a nivel de aplicación. En este caso, desde el punto de vista del desktop grid middleware cuando la aplicación o una tarea de la misma falla, entonces, el desktop grid middleware la vuelve a ejecutar con la esperanza de que la falla que ocasionó la no terminación de la aplicación no se vuelva a repetir [91, p. 6-7]. Desde el punto de vista de la aplicación, un algoritmo de tolerancia a fallos puede ser implementado en una aplicación paralela. Este algoritmo al detectar que una de sus tareas ha fallado entonces es capaz de volver a ejecutar dicha tarea en un recurso que no haya presentado