Dise˜no y evaluación de un clúster HPC: Hardware

Diseño y evaluación de un clúster HPC: Hardware
Autor:
David Trilla Rodrı́guez
Grado en Ingenierı́a Informática
Especialidad en Ingenierı́a de Computadores
26 de Junio de 2014
Director:
Josep Llosa Espuny, Arquitectura de computadores
Facultad de Informática de Barcelona
Universidad Politécnica de Cataluña (UPC) - BarcelonaTech
Resumen
La sección de hardware de este proyecto da a conocer un análisis de los dispositivos
fı́sicos más usados en el mundo de la supercomputación.
Detalla los componentes necesarios y el hardware requerido para poder construir un
computador de tipo clúster y evalúa los posibles rendimientos obtenidos.
Incluye también la especificación del hardware usado finalmente para la construcción
de un clúster, ası́ como su configuración y puesta a punto para las secciones de software
de sistema y aplicaciones.
Finalmente se evalúa la plataforma construida desde el punto de vista hardware y
se contrasta su eficacia con la teorı́a usada para diseñar el clúster inicial.
Los objetivos del trabajo se sitúan en la construcción y montaje de un clúster de placas
Arndale Octa con chips de Samsung Exynos 5420, y en el aprendizaje en la materia de
hardware de computación de alto rendimiento.
Resum
La secció de hardware d’aquest projecte dona a coneixer un anàlisi dels dispositius
fı́sics més usats en el món de la supercomputació.
Detalla els components necessaris i el hardware requerit per poder construir un computador de tipus clúster i evalúa els possibles rendiments obtinguts.
Inclòu també l’especificació del hardware usat finalment per a la construcció d’un
clúster, aixı́ com la seva configuració i posada a punt per a les seccions de software
de sistema i aplicacions.
Finalment s’evalúa la plataforma construida des del punt de vista hardware i es contrasta la seva eficàcia amb la teoria usada per dissenyar el clúster inicial.
Els objectius del treball es situen en la construcció i montatge d’un clúster de plaques Arndale Octa amb chips Samsung Exynos 5420, i en l’aprenentatge en la matèria
de hardware de computació d’alt rendiment.
1
Abstract
The hardware section of this project shows an analysis of the most used physical
devices in the supercomputing world.
The project specifies the parts and hardware needed to build a type cluster computer, and evaluates the possible performance measures to be obtained.
It also includes the specification of the hardware used in last instance to build a cluster,
its configuration and set up for the other sections of this project, system software and
applications.
Finally, the project evaluates the built platform from the hardware point of view, and
compare its efficiency against the initial hypothetical cluster disgned.
The goals of the project is to build and construct a cluster of Arndale Octa boards
with Samsung Exynos 5420 chips, and learn about the hardware issue in high performance computing.
2
Índice general
Resumen
2
Prefacio
12
1. Introducción
1.1. Orı́genes . . . . . . . . . . . .
1.2. Problemática . . . . . . . . .
1.3. Student Cluster Challenge . .
1.4. Objetivos . . . . . . . . . . .
1.4.1. Objetivos Generales .
1.4.2. Objetivos individuales
2. Gestión del Proyecto
2.1. Planificación . . . . . . . .
2.1.1. Estudio Teórico . . .
2.1.2. Aplicación Práctica .
2.2. Estimación temporal . . . .
2.2.1. Listado de Tareas .
2.2.2. Diagrama de Gantt .
2.2.3. Recursos . . . . . . .
2.3. Presupuesto . . . . . . . . .
2.3.1. Recursos humanos .
2.3.2. Hardware . . . . . .
2.3.3. Software . . . . . . .
2.3.4. Gastos generales . .
2.3.5. Presupuesto total . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Estado del Arte
3.1. Metodologı́a y Top 500 . . . . . .
3.2. Arquitectura . . . . . . . . . . .
3.2.1. Clúster . . . . . . . . . .
3.2.2. MPP . . . . . . . . . . . .
3.3. Red de Interconexión . . . . . . .
3.3.1. InfiniBand . . . . . . . . .
3.3.2. Ethernet . . . . . . . . . .
3.3.3. Otras tecnologı́as . . . . .
3.4. Unidad Central de Procesamiento
3.4.1. Intel Xeon . . . . . . . . .
3.4.2. IBM Power BQC . . . . .
.
.
.
.
.
.
.
.
.
.
.
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
14
14
14
15
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
17
18
19
20
21
21
22
22
23
23
24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
. . . . . . . . . . . 25
. . . . . . . . . . . 25
. . . . . . . . . . . 26
. . . . . . . . . . . 27
. . . . . . . . . . . 27
. . . . . . . . . . . 28
. . . . . . . . . . . 29
. . . . . . . . . . . 30
. . . . . . . . . . . 30
. . . . . . . . . . . 30
. . . . . . . . . . . 30
3.4.3. AMD Opteron . . . . . . . .
3.5. Aceleradores . . . . . . . . . . . . . .
3.5.1. Coprocesador Intel Xeon Phi
3.5.2. Nvidia Tesla . . . . . . . . .
3.6. Almacenamiento . . . . . . . . . . .
3.6.1. Hard Disk Drive . . . . . . .
3.6.2. Solid-state Drive . . . . . . .
3.7. Estado del arte en el SCC . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Diseño de un Clúster Teórico
4.1. Restricciones . . . . . . . . . . . . . . . .
4.2. Parámetros de decisión . . . . . . . . . . .
4.2.1. CPU . . . . . . . . . . . . . . . . .
4.2.2. GPU . . . . . . . . . . . . . . . . .
4.2.3. Red de Interconexión . . . . . . . .
4.2.4. Configuración y número de nodos .
4.2.5. Colocación . . . . . . . . . . . . .
4.2.6. Sumario . . . . . . . . . . . . . . .
4.3. Métricas Teóricas . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Hardware del Clúster
5.1. Arndale Octa . . . . . . . . . . . . . . . . .
5.1.1. SoC Samsung Exynos 5420 . . . . .
5.1.2. Interfaz de Red: 100Mbps Ethernet .
5.1.3. Almacenamiento: Tarjeta microSD +
5.2. Red de Interconexión: 100Mb Ethernet . . .
5.3. Almacenamiento: NFS . . . . . . . . . . . .
5.4. Limitaciones del hardware . . . . . . . . . .
5.4.1. OpenCL . . . . . . . . . . . . . . . .
5.4.2. OpenGL Compute Shaders . . . . .
5.4.3. big.LITTLE . . . . . . . . . . . . . .
5.4.4. Interfaz Ethernet . . . . . . . . . . .
5.4.5. Escalar la frecuencia de la CPU . . .
5.5. Sumario del Hardware . . . . . . . . . . . .
5.6. Clúster de Arndale Octa . . . . . . . . . . .
6. Diseño y Configuración del Clúster ARM
6.1. Emplazamiento del hardware . . . . . . .
6.2. Diseño de la red de interconexión . . . . .
6.3. Configuración del hardware . . . . . . . .
6.4. Arranque: Configuración de U-boot . . . .
6.5. Gestión del hardware . . . . . . . . . . . .
6.6. Configuración de la Red . . . . . . . . . .
6.6.1. DHCP . . . . . . . . . . . . . . . .
6.6.2. Disco en NFS . . . . . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
31
31
32
33
33
33
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
38
40
40
41
42
42
43
. . . . .
. . . . .
. . . . .
eMMC
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
46
49
49
49
49
49
50
50
50
51
51
51
52
.
.
.
.
.
.
.
.
55
55
56
58
58
59
60
60
62
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7. Evaluación del Clúster
7.1. Metodologı́a . . . . . . . . . . . . .
7.1.1. Configuración de Yokogawa
7.2. Tests de estrés . . . . . . . . . . .
7.3. Rendimiento pico esperado . . . .
7.4. Rendimiento obtenido . . . . . . .
7.5. Mediciones de Consumo . . . . . .
7.6. Comparación con el clúster teórico
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
. . . . . . 64
. . . . . . 64
. . . . . . 66
. . . . . . 66
. . . . . . 67
. . . . . . 69
. . . . . . 71
8. Conclusiones Propias
8.1. Que le hace falta al hardware para ganar . . . . . . . . . . . . . . . . . .
8.2. Propuestas de continuidad . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
73
73
74
9. Conclusiones de equipo
9.1. Conclusiones de cara a la competición . . . . . . . . . . . . . . . . . . .
9.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
75
76
Agradecimientos
77
5
Índice de figuras
2.1. Listado de Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Estado del Laboratorio C6-103 al llegar. . . . . . . . . . . . . . . . . . .
19
20
23
3.1. Tabla con la configuración hardware de los clústers del Student Cluster
Challenge (SCC) edición de 2013 . . . . . . . . . . . . . . . . . . . . . .
3.2. Equipo de Costa Rica durante la competición del año 2013 . . . . . . .
34
35
4.1. Tabla comparativa de procesadores Intel: Generación E5-2600 vs E54600[20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Esquema de la placa base[24] . . . . . . . . . . . . . . . . . . . . . . . .
39
42
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
5.7.
5.8.
5.9.
Esquema de la arquitectura de la placa Arndale Octa .
Pipeline del Cortex-A15 . . . . . . . . . . . . . . . . .
Esquema de la arquitectura de la Mali-T628 MP6 . . .
Esquema de la arquitectura de los shaders de la Mali .
Vista del clúster (cerveza para comparar la escala) . .
Vista del clúster (cerveza para comparar la escala) . .
Vista cercana del clúster . . . . . . . . . . . . . . . . .
Vista del switch de interconexión . . . . . . . . . . . .
Vista general del clúster . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
6.1.
6.2.
6.3.
6.4.
6.5.
Distribución del hardware en el laboratorio . . . . . .
Configuración de la red del clúster del laboratorio . . .
Configuración para arranque desde la eMMC integrada
Configuración para arranque desde la tarjeta SD . . .
Vista de la interfaz RS-232 . . . . . . . . . . . . . . .
. . .
. . .
(por
. . .
. . .
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
Vista del Yokogawa tomando medidas del consumo del switch . . . . . .
Esquema de la conexión del Yokogawa a las tomas de corriente del clúster
Gráfico rendimiento de 1 nodo . . . . . . . . . . . . . . . . . . . . . . .
Gráfico rendimiento del clúster . . . . . . . . . . . . . . . . . . . . . . .
Distribución del consumo total estimado . . . . . . . . . . . . . . . . . .
Gráfico consumo en 1 nodo . . . . . . . . . . . . . . . . . . . . . . . . .
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
47
48
48
52
52
53
53
54
. . . . .
. . . . .
defecto)
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
55
57
58
58
59
65
65
67
68
70
71
Índice de cuadros
2.1.
2.2.
2.3.
2.4.
2.5.
Distribución de horas de trabajo según rol.
Costes asociados a recursos humanos. . . .
Costes derivados de la compra de Hardware.
Desglose de los gastos generales. . . . . . .
Resumen presupuesto total. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
18
22
22
24
24
3.1. Ancho de banda total de Infiniband en Gbps . . . . . . . . . . . . . . .
3.2. Ancho de banda efectivo de Infiniband en Gbps . . . . . . . . . . . . . .
28
29
4.1. Sumario del hardware del clúster teórico . . . . . . . . . . . . . . . . . .
43
6.1. Asignación de direcciones para los nodos . . . . . . . . . . . . . . . . . .
60
7.1.
7.2.
7.3.
7.4.
7.5.
67
68
69
69
70
Mediciones de rendimiento con DGEMM . . .
Mediciones de rendimiento con DGEMM . . .
Mediciones de Ancho de Banda con VECOP .
Consumo medio de los componentes hardware
Mediciones de consumo con DGEMM . . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Glosario
Arquitectura x86 Conjunto de instrucciones utilizadas en la microarquitectura de un
procesador. Creada por la compañı́a Intel, y de las más extendidas actualmente.
31
Floating Point Operations Per Second Las siglas de FLOPS se usan para medir
y comparar el rendimiento de los computadores, y se corresponden a la cantidad
de operaciones con decimales que es capaz de hacer una máquina cada segundo.
31, 37
High Performance Linpack Versión para HPC del benchmark de Linpack. 14, 25,
35, 36, 67, 69, 75
Simple Instruction Multiple Data Técnica empleada para conseguir paralelismo a
nivel de datos. Un conjunto de instrucciones que son capaces de ejecutar la misma
operación en datos distintos. 31, 32, 38, 46
Symmetric Multiprocessing Tipo de arquitectura que implica disponer de dos o
más procesadores idénticos conectados a una memoria principal compartida única
y controlados por un mismo sistema operativo. 27
System on a Chip Técnica que implica construir circuitos que integren todos los
componentes necesarios de un computador en un único chip. 45–47, 51, 66, 73
8
Siglas
API Aplication Programming Interface. 50
BSC Barcelona Supercomputing Center. 21, 45
cm centı́metros. 26
CPD Centro de Procesamiento de Datos. 33
CPU Central Processing Unit. 26, 27, 30, 31, 35, 41, 43, 46, 50, 51, 56, 66
DAC Departament d’Arquitectura de Computadors. 56, 60, 61
DAS Direct Attached Storage. 27
DDR Double Data Rate. 28, 29
DHCP Dynamic Host Configuration Protocol. 55, 56, 60–62
DNS Domain Name Service. 61
ECC Error Correcting Code. 32
EDR Enhanced Data Rate. 28, 29
eMMC Embedded Multi-Media Card. 51
FDR Fourteen Data Rate. 28, 29, 34, 40, 41, 43
GB Gigabyte. 31, 32, 34, 35, 41, 45, 46, 49, 51, 56, 73
GB/s Gigabyte por segundo. 31
Gbps GigaBit Por Segundo. 28, 29, 40, 51, 56, 68, 69, 73
GFLOPS Gigaflops. 38, 48, 66–68, 71, 72
GFLOPS/e Gigaflops por euro. 32
GFLOPS/W Gigaflops por vatio. 32, 38, 40, 71
GHz Gigahercios. 31, 46, 51, 66
GPGPU General-Porpouse Computing on Graphics Processing Unit. 31, 32
GPU Graphics Processing Unit. 31, 32, 42, 43, 46, 50, 51, 56, 66
9
HCA Host Channel Adapter. 29
HDD Hard Disk Drive. 33, 36
HDMI High-Definition Multimedia Interface. 45
HPC High Performance Computing. 12, 14–17, 21, 27, 28, 30–33, 40, 46, 49, 51, 66,
69, 71, 74, 75
HPCC High-Performance Computing Cluster. 66
ISC International Supercomputing Conference. 12–14, 25
KB Kilobyte. 29
MAC Media Access Control. 55, 56, 60–62
Mbps Mega Bits Por Segundo. 45, 49, 51, 56, 69, 73
MHz Megahercios. 46, 48, 51, 56, 68, 73, 74
MPP Massive Parallel Processessor. 25, 27, 30, 38
NAS Network Attached Storage. 27, 49
NFS Network File System. 37, 49, 56, 58, 62, 63, 75
ns Nanosegundos. 29
OSI Open System Interconnection. 29, 40
PFLOPS Petaflops. 30
PVP Precio de Venta al Público. 32
QDR Quad Data Rate. 28, 29
QSFP Quad Small Form-factor Pluggable. 40
RAID Redundant Array of Independent Disks. 36
RPM Revoluciones Por Minuto. 33
SAN Storage Area Network. 27
SCC Student Cluster Challenge. 6, 12–15, 17, 25, 34, 35, 37, 38, 40, 43, 71–74
SD Secure Digital. 49, 51, 58, 75
SDR Single Data Rate. 28, 29
SSD Solid-State Drive. 33, 36, 41
TB TeraByte. 35
10
TCA Target Channel Adapter. 29
TFLOPS Teraflops. 31, 32, 36, 40, 43, 71, 75
UPC Universitat Politécnica de Catalunya. 55
USB Universal Serial Bus. 45, 49, 51, 64
W Vatios. 13, 14, 32, 37, 38, 40, 42–44, 69–72
11
Prefacio
Este trabajo forma parte de un proyecto colaborativo de investigación entre estudiantes que se ubica en el área de la informática conocida como High Performance
Computing (HPC). Comparte tı́tulo y se complementa con el trabajo de tres compañeros de proyecto: David Trilla en el ámbito del hardware, Cristóbal Ortega en el de
software de sistema y Constantino Gómez por el apartado de aplicaciones. Por tanto,
los siguientes capı́tulos son compartidos a nivel de proyecto: este prefacio, introducción, planificación y presupuestos, sostenibilidad y por último conclusiones de equipo.
Estos capı́tulos son compartidos porque aportan información esencial común a todo el
proyecto, ası́ como una descripción del trabajo conjunto que ha realizado el equipo.
Hoy en dı́a el HPC es una de las herramientas principales para el desarrollo de la
ciencia. Por norma general las aplicaciones HPC comparten una caracterı́stica común,
se pueden desmenuzar en subtareas para poder ası́ ejecutarse de manera paralela en
gran cantidad de procesadores.
El principal exponente de este tipo de investigación son los supercomputadores, máquinas con capacidades de cómputo muy por encima de la mayorı́a de ordenadores, y que
son imprescindibles para casi cualquier campo cientı́fico e investigación. El HPC se
encarga de que estas máquinas sigan evolucionando para permitir que la ciencia siga
avanzando a pasos cada vez mayores.
Una de las conferencias más importantes en materia HPC es la International Supercomputing Conference (ISC). Los asistentes, mayoritariamente profesionales del sector,
participan en charlas técnicas, conferencias y talleres entre otros. Para este trabajo, no
es el evento principal el que resulta de interés, sino la competición HPC: SCC. En esta
competición, que participan universidades de todo el mundo, equipos de estudiantes
compiten por conseguir los mejores resultados de rendimiento.
La creación del grupo responde a dos necesidades: la de dar cabida a los tres aspectos
técnicos más importantes de la tecnologı́a HPC en un proyecto común, y segundo, la
de formar un equipo y las opciones que se tendrı́an para ganar una competición como
la Student Cluster.
12
Capı́tulo 1
Introducción
1.1.
Orı́genes
A principios de septiembre de 2013, Álex Ramı́rez reúne a 7 estudiantes de la especialidad de ingenierı́a de computadores, entre ellos los 3 integrantes del grupo, y nos
propone formar un equipo con intención de participar en la ISC ‘14 que se celebra en
Liepzig del 21 al 25 de Junio en 2014
A lo largo de septiembre y octubre se estudian los requerimientos de la competición
y elaboramos el documento de inscripción con información de los participantes y un
primer planteamiento del clúster.
A principios de diciembre la organización nos comunica que no hemos sido admitidos en la competición sin aportar mayor explicación.
En enero de 2014 acordamos seguir con el proyecto a modo de TFG pese a no estar
admitido. El grupo se reduce a 3 personas: Constan Gómez, David Trilla y Cristobal
Ortega.
1.2.
Problemática
Por un lado la problemática que se plantea es la siguiente: en caso de querer competir en el futuro en una competición como el SCC, qué competencias de equipo y
conocimientos técnicos deberı́amos desarrollar.
Por otro lado, nos encontramos otro problema, más general y de más alcance, como es
el consumo de los supercomputadores hoy en dı́a. Actualmente, el mantenimiento de
los centros de computación tiene un coste muy elevado. Gran parte del coste se debe
al consumo eléctrico de sus equipos y la refrigeración necesaria para mantenerlos funcionando. Este problema es atacado de forma indirecta en el SCC por la limitación de
consumo a 3.000 Vatios (W), y en el clúster que construiremos con hardware de bajo
consumo.
Para ayudarnos a definir los objetivos del trabajo, veamos primero en detalle en que
consiste la competición.
13
CAPÍTULO 1. INTRODUCCIÓN
1.3.
Student Cluster Challenge
El SCC es una competición que se celebra en el ámbito del ISC, el escaparate sobre
HPC en Europa. El evento ISC ‘14 tiene lugar entre los dı́as 21 y 25 de Junio en Liepzig, Alemania. Esta competición será nuestro marco de referencia, dirigiendo nuestro
proyecto como si fuéramos a participar en ella, usando sus directrices y parámetros. El
evento consiste en reunir a varios equipos, de hasta 6 estudiantes sin graduar, que junto
con un pequeño sistema para supercomputación y a lo largo de 4 dı́as, compitan entre
ellos en diferentes categorı́as para determinar el sistema ganador, mediante el montaje
y la optimización de los parámetros de las aplicaciones.
Existen 3 categorı́as a las cuales se opta a premio, la de mejor resultado con High
Performance Linpack, que es la versión para HPC del software de benchmarking LINPACK, la de votación a favorito, y la categorı́a general donde cuenta la puntuación
total de todos los benchmarks.
La caracterı́stica de la competición de premiar al eficiencia da lugar a la principal restricción que se impone en la competición, que limita el “presupuesto para el consumo”.
Esto limita el consumo de cualquier clúster en competición, incluyendo sus elementos
para interconexión, a un total de 3.000W. [1]
Debido a todas las anteriores normas, nuestra intención es diseñar dos clústeres pensados para presentar al concurso. Un clúster teórico, que cumpla los requisitos anteriores,
y que nos permitirá liberarnos de la necesidad de depender del coste de su creación,
y posteriormente, con el hardware disponible, crear un clúster que pueda ejecutar eficientemente los benchmarks del concurso, con especial atención en el High Performance
Linpack, y que también cumpla la restricción de consumo.
1.4.
Objetivos
A continuación se desglosan los objetivos generales del proyecto y los objetivos individuales de cada uno de los tres trabajos.
1.4.1.
Objetivos Generales
Basándonos en los requerimientos vistos en la sección anterior se establecen los siguientes objetivos generales y su justificación. Hemos dividido el proyecto en dos fases.
Objetivos de la primera fase
Estudio del estado del arte HPC
Diseñar y montar un clúster con un consumo inferior a los 3kW.
Para poder diseñar adecuadamente un clúster necesitamos realizar previamente un estudio del estado del arte. De esta manera podremos extraer cuales son los elementos
indispensables para su montaje, y además, adquirir otros conocimientos relacionados
14
CAPÍTULO 1. INTRODUCCIÓN
que nos ayudarán durante todo el desarrollo del proyecto.
El segundo objetivo se aborda de dos maneras diferentes. Por un lado se realiza el
diseño teórico de un clúster con procesadores y aceleradores convencionales. Por otro,
el diseño y montaje de un prototipo de clúster con procesadores móviles de bajo consumo.
Dada la necesidad de asistir con un clúster propio a la competición, es necesario trabajar de primera mano con el hardware y el software de sistema para ser más competitivos.
Objetivos de la segunda fase
Evaluación del clúster basado en procesadores de bajo consumo.
En este momento, mediante benchmarks y aplicaciones, realizaremos las pruebas empı́ricas que demostrarán que nuestra solución al problema está a la altura de la competición.
En caso de que no estarlo, se buscará poder señalar de manera precisa la causa de las
deficiencias de rendimiento (cuellos de botella) ya sean de diseño, de configuración o
de uso incorrecto de las herramientas de evaluación.
Dado que ningún integrante del grupo ha participado en algún proyecto similar anteriormente, el proceso de evaluación servirá también para el desarrollo de las habilidades
de equipo necesarias en la competición, ya que, gran parte de las técnicas y los test
aplicados con el fin de optimizar la máquina y las aplicaciones de este trabajo son extrapolables a otras configuraciones de hardware y otros programas.
1.4.2.
Objetivos individuales
Objetivos de la sección de hardware
Fase 1
Investigación sobre el estado del arte del hardware en el mundo de HPC, cuáles
son las tecnologı́as más usadas y los componentes necesarios para construir un
clúster.
Crear un clúster para HPC de manera conceptual para poder competir en el SCC,
sin limitación económica.
Evaluar la tecnologı́a usada en el SCC y las capacidades del clúster teórico diseñado.
Fase 2
Analizar el hardware a nuestro alcance, disponible para construir un clúster para
HPC.
Montar y configurar el hardware para tener una plataforma funcional con múltiples nodos sobre la que poder ejecutar software
15
CAPÍTULO 1. INTRODUCCIÓN
Evaluar el rendimiento del hardware, las diferencias entre los resultados esperados
y los reales, y comparar con el clúster conceptual de la primera fase y otros
sistemas con tecnologı́as distintas.
Objetivos de la sección de software de sistema
Fase 1
Investigar que software de sistema es necesario habitualmente para correr aplicaciones del tipo HPC.
Estudiar el estado actual en los sistemas de supercomputación para saber que
stack de software usan.
Seleccionar el software de sistema que necesitemos y elegir el que mejor se nos
adapte a nosotros, ya sea por compatibilidad con el hardware o aplicaciones a
correr, por documentación existente o requisitos diversos.
Fase 2
Basado en la fase 1, instalar y configurar todo el stack de software para crear
un clúster totalmente funcional. Es posible que haya que seleccionar otro tipo de
software por la plataforma usada.
Experimentar con distintas versiones de paso de mensajes MPI para saber realmente cuál se adapta a nuestro sistema
Objetivos de la sección de aplicaciones
Fase 1
Investigar las aplicaciones en el estado del arte actual y analizar las más relevantes
para nuestro proyecto.
Averiguar que opciones existen de cara a optimizar las aplicaciones que se ejecutarán en el clúster.
Fase 2
Evaluar el rendimiento de las aplicaciones descritas a nivel de nodo y a nivel de
clúster.
16
Capı́tulo 2
Gestión del Proyecto
2.1.
2.1.1.
Planificación
Estudio Teórico
La primera fase, es de investigación activa, sobre HPC y el SCC, e información
sobre todo lo necesario para la instalación y preparación de un clúster. Esto incluye
hardware, software de sistema y aplicaciones. Esta parte del proyecto recabará la información necesaria para elaborar un clúster teórico con el que ir a competir en el SCC.
No se esperan grandes contratiempos durante esta fase. Los problemas que puedan
surgir serán derivados de la poca información disponible sobre algunos componentes
del clúster.
2.1.2.
Aplicación Práctica
La segunda fase, basada en la experimentación, es en la cual usamos la información
recogida en la fase anterior para crear un clúster totalmente funcional. En esta fase es
donde es más probable que surjan dificultades técnicas, ya que al ser un mundo casi
nuevo, como por ejemplo, que la información recogida en la fase anterior no se ajuste
a nuestra arquitectura o software escogido.
Los posibles retrasos de ponernos a montar el clúster, instalación de software y benchmarks deberemos tenerlos en cuenta y aplazar el resto de tareas que tengamos, como
es la optimización de software y aplicaciones, esto implica que obtendremos peores
rendimientos de los que realmente podrı́amos conseguir. Ya que para poder obtener
las métricas de rendimiento necesitamos un clúster funcionando. Y aunque no sea un
clúster optimizado todo lo posible, el objetivo de tener un clúster de HPC estará conseguido. Los posibles retrasos que aparezcan en esta sección puede aparecer de errores e
incompatibilidades en la fase de instalación del clúster, el tiempo adicional será recortado de las tareas más opcionales dispuestas al final del proyecto, correspondientes a
la parte de optimización, lo que implicará que obtendremos peores rendimientos de los
que realmente podemos conseguir, ya que la instalación y puesta en marcha del clúster
es esencial, sin embargo el proyecto estará finalizado ya que tendremos un clúster totalmente funcional.
17
CAPÍTULO 2. GESTIÓN DEL PROYECTO
2.2.
Estimación temporal
La temporización en este proyecto toma especial importancia por dos motivos: hay
un gran volumen de tareas a realizar que requieren un esfuerzo conjunto y la alta incertidumbre que albergan algunas de ellas. Debido a las fuertes dependencias entre tareas
es imprescindible tener en mente las fechas comprometidas para garantizar que todo el
grupo cumple con sus objetivos.
Desde el principio se acuerdan unas horas fijas de dedicación semanal en grupo. Por un
lado, nos ayudará a empezar con buen ritmo con la parte teórica y a funcionar como
un equipo, y por otro, tener margen de reacción de cara al final del proyecto donde se
prevén más problemas.
Tarea
Dedicación por persona
Estudio previo
Montaje y configuración
Benchmarking
Análisis de resultados
125h
155h
35h
60h
Cuadro 2.1: Distribución de horas de trabajo según rol.
18
CAPÍTULO 2. GESTIÓN DEL PROYECTO
2.2.1.
Listado de Tareas
Figura 2.1: Listado de Tareas
19
2.2.2.
Diagrama de Gantt
Figura 2.2: Diagrama de Gantt
20
CAPÍTULO 2. GESTIÓN DEL PROYECTO
2.2.3.
Recursos
Los recursos que tendremos para este proyecto serán principalmente humanos,
tendrán un papel importante para el estudio teórico, el montaje y configuración del
clúster.
Para la parte de estudio, nos apoyaremos en publicaciones cientı́ficas, revistas y papers,
además de sitios online especializados de este tipo de hardware y software. También se
hará uso de libros que puedan tratar los temas de HPC o clústeres, pese a que estos se
prevén en menor medida.
Para la parte práctica del montaje del clúster dispondremos principalmente del hardware que nos ofrezca el departamento de computadores y el sitio en el que nos permita
colocarlo. Para realizar las medidas de consumo energético se ha dispuesto de un medidor de potencia Yokogawa cedido por el Barcelona Supercomputing Center (BSC).
Finalmente, otros recursos utilizados son los ordenadores personales para la redacción
de la memoria y conectar en remoto al hardware de desarrollo.
2.3.
Presupuesto
El proyecto se basa en montar un clúster y configurarlo de manera correcta para
poder ejecutar aplicaciones HPC en él. En este documento se hace una estimación del
precio de los recursos que se usarán a lo largo del trabajo. Las amortizaciones se calcularán respecto a 6 meses.
21
CAPÍTULO 2. GESTIÓN DEL PROYECTO
2.3.1.
Recursos humanos
Se necesitan técnicos que se encarguen de diseñar, instalar y configurar dicho clúster.
Siendo 3 personas en este proyecto, repartiremos las mismas horas para todos. Dentro
de cada bloque de horas, cada uno se centrará en una de las divisiones lógicas que
hemos establecido: hardware, software de sistema y aplicaciones.
Para las decisiones de elección de componentes se han considerado horas de Director de proyecto. Para el montaje e instalación del clúster se necesitarán competencias
de Administrador de Sistema. Para realizar los benchmarks adecuados e interpretar resultados se han considerado horas de Analista. Los datos que utilizamos están basados
en portales online de ofertas laborales.
Rol
Director de proyecto
Administrador de sistema
Analista
Total
Horas
estimadas
Precio
por hora
Total
por persona
Total
grupo
125h
155h
95h
375h
50e/h
26e/h
30e/h
6.250e
4.030e
2.850e
18.750e
12.090e
8.550e
39.390e
Cuadro 2.2: Costes asociados a recursos humanos.
2.3.2.
Hardware
Para la segunda parte del proyecto será esencial el hardware que adquiramos para
poder trabajar con él. Datos obtenidos de tiendas online.
Producto
Arndale Octa(Exynos 5420)
Fuentes de alimentacion
Tarjetas SD
Power meter Yokogawa
Switch Netgear 100-Mbit
1TB Hard Drive Storage
125M cat 5E FTP
Total
Precio
unitario
Unidades
150e
5e
7,5e
1.830e
89e
70e
68e
6
6
12
1
1
1
1
Vida
útil
5
5
5
15
10
7
20
Amortización
total
años
años
años
años
años
años
años
Cuadro 2.3: Costes derivados de la compra de Hardware.
22
90e
3e
9e
61e
4,45e
5e
1,7e
174,15e
CAPÍTULO 2. GESTIÓN DEL PROYECTO
Tanto las placas Arndale Octa como las fuentes de alimentación y el medidor de
potencia Yokogawa han sido cedidos por el BSC. El resto del material ha sido cedido
por el departamento de Arquitectura de Computadores. Al final de la realización del
proyecto se espera deshacer el montaje y retornar ı́ntegro todo el material para su posterior reutilización en otras actividades de investigación o proyectos.
2.3.3.
Software
El software requerido para la instalación, benchmarking y análisis de la máquina es
de acceso gratuito. Gran parte de de los programas tienen licencias de Software Libre, y
las que no, disponen de versiones gratuitas con propósito no comercial. Necesitaremos
distinto software de sistema para gestionar la máquina como aplicaciones para medir
su rendimiento.
2.3.4.
Gastos generales
Necesitaremos un sitio donde instalar el clúster fı́sicamente, para ello necesitaremos
un sitio con espacio y una instalación eléctrica adecuada además de Internet para tener
acceso a los sistemas desde fuera.
El laboratorio C6-103 cedido también por el departamento de AC cuenta con todo
lo necesario para la realización del proyecto. Se ha hecho una estimación del coste que
supondrı́a disponer de un espacio similar.
Figura 2.3: Estado del Laboratorio C6-103 al llegar.
23
CAPÍTULO 2. GESTIÓN DEL PROYECTO
Concepto
Espacio fı́sico
Electricidad
Internet
Total
Coste
hora
Coste
total
0,368e
0,083e
0,07e
1.590e
358e
300e
2.248e
Cuadro 2.4: Desglose de los gastos generales.
2.3.5.
Presupuesto total
Concepto
Recursos humanos
Hardware
Software
Gastos generales
Total
Coste estimado
+ Impuestos
39.390e
174,15e
625e
2.248e
42.437,15e
51.600,9e(31 % S.S.)
210,7e(21 % IVA)
300e(21 % IVA)
2.720,08e(21 % IVA)
54.831,68e
Cuadro 2.5: Resumen presupuesto total.
24
Capı́tulo 3
Estado del Arte
3.1.
Metodologı́a y Top 500
Para realizar el análisis sobre el estado del arte en la supercomputación actual se
ara un estudio sobre los sistemas más representativos en la lista del Top 500 de Noviembre de 2013. Las secciones se dividirán para representar los distintos componentes
necesarios para construir un supercomputador.
El Top 500 es un proyecto para clasificar los 500 supercomputadores más potentes del
mundo. El proyecto se inicio en el año 1993, y dos meses al año, en Noviembre y Junio,
publica listas actualizadas. El sistema de clasificación se basa en la puntuación que sacan las máquinas que se presentan en el benchmark de High Performance Linpack.[2] [3]
El estado del arte, no se centrará tanto en la representación de rendimiento que ofrece cada sistema diferente, si no en su representatividad frente al total de máquinas.
El impacto que tenga cada sistema sobre el rendimiento se analizará posteriormente
cuando se deba decidir el hardware que integrará el clúster teórico candidato al SCC.
Respecto al estado del arte de la competición, se basará en su edición europea, la que
forma parte del ISC.
3.2.
Arquitectura
A lo largo de la historia del Top 500, ha habido una gran diversidad de arquitecturas, en cuanto al montaje del supercomputador se refiere. Actualmente solo compiten 2
”filosofı́as”distintas de supercomputador referente a la arquitectura, la de tipo clúster
y la de tipo Massive Parallel Processessor (MPP). La representatividad de los supercomputadores de tipo clúster indica que un 84,6 % de los sistemas del Top 500, son de
este tipo, mientras que el 15,4 % restante, son de tipo MPP. A pesar de que el proyecto esta directamente enfocado a un tipo de arquitectura, es necesario explicar las dos
tendencias que dominan el Top 500 actualmente.
25
CAPÍTULO 3. ESTADO DEL ARTE
3.2.1.
Clúster
La arquitectura de tipo clúster comprende a dos o más ordenadores interconnectados entre ellos para trabajar comportándose como uno solo. La caracterı́stica principal
de este tipo de máquinas, es que cada uno de estos ordenadores, no deja de ser una
máquina indepentiende, que puede trabajar por sı́ sola, y ejecutar programas completamente distintos a todas las demás. Una caracterı́stica importante de los clústers, es
que, pueden ser máquinas heterogéneas, es decir, sus nodos de cálculo no necesariamente tiene que ser idénticos, si no que se puede construir supercomputadores con nodos
variables en cuanto al hardware.
Las máquinas clúster se componen principalmente de las siguientes partes[4]:
Nodo de cálculo: Cada una de las máquinas ı̈ndependientes”de las que se compone
el clúster.
• Soportes para Procesadores(sockets): Cada nodo de cálculo se puede componer de una o más Central Processing Unit (CPU), dando lugar a nodos
multi-núcleo que a su vez pueden contener procesadores, también multinúcleo.
• Memoria: Dividida en distintos canales, se usará para almacenar y ejecutar
los programas.
• Aceleradores: Componentes opcionales para ayudar en la computación.
• Interfaces de Red: Soportes para permitir la conexión entre nodos.
• Almacenamiento: Los nodos pueden tener almacenamiento local y usarlo
para distintos propósitos, como por ejemplo, guardar datos temporalmente.
• Colocación: Los supercomputadores de tipo clúster, acostumbran a usar medidas estandarizadas para poner sus nodos en armarios. Las principales configuraciones que usan son:
◦ Bastidores: Si los nodos van en bastidores, que son marcos de metal
donde se fijan los componentes hardware, se usan armarios llamados
racks, para su colocación. La medida estándar usada en este caso, es la U,
equivalente a 44,45 centı́metros (cm) (1,75”) de altura. Habitualmente
los racks tienen una altura de 42 U. La medida del bastidor puede variar,
1 U, 2 U, 1,5 U, ... dependiendo del hardware que deba soportar.
◦ Hojas(Blades):Otra opción para la colocación, es tener nodos de tamaño
inferior, e insertarlos en vertical. En éste caso se insertan por hojas
(blades) y estas hojas van en los llamados bladecenter, que agrupan los
nodos. La altura habitual de un bladecenter, es de 7 U.
Interconexión: Éste es el elemento necesario para poder coordinar y comunicar
todos los nodos entre si. Construye una red entre ellos y permite que un supercomputador ejecute un mismo programa entre todos sus nodos y sea fácilmente
escalable y ampliable.
Almacenamiento: El clúster necesita opciones de almacenamiento para poder
guardar el software de sistema, y los programas que vayan a ejecutarse, las principales configuraciones son:
26
CAPÍTULO 3. ESTADO DEL ARTE
• Direct Attached Storage (DAS): Este tipo de configuración de almacenamiento es la más básica, y consiste simplemente en anexar un dispositivo de
almacenamiento directamente al nodo, sin una red de por medio.
• Network Attached Storage (NAS): Para esta configuración, existe un disco en
una red, que es tratado como un servidor de ficheros, y el sistema operativo lo
identifica como tal. Es decir el almacenamiento viaja a través de protocolos
como TCP/IP en la capa de aplicación.
• Storage Area Network (SAN): A diferencia del anterior, los discos en SAN,
son discos en red tratados como dispositivos de bloques, de manera que el
sistema operativo lo identifica como si de un disco conectado directamente se tratara y por lo tanto es el propio sistema de ficheros el que envı́a
directamente los mensajes al servidor de almacenamiento.
3.2.2.
MPP
Las arquitecturas de tipo MPP son una vuelta de tuerca a losSymmetric Multiprocessing. Es una arquitectura de multi-procesador que consiste en tener cada CPU con
su propia memoria, copia del sistema operativo y aplicaciones, normalmente interconectados con una red especı́fica propia del fabricante o usando una forma de interconexión
más compleja, como por ejemplo torus de varias dimensiones.
Un ejemplo de supercomputadores tipo MPP, son los BluGene/Q de IBM, o los ordenadores Cray. Su diferencia básica respecto a los computadores de tipo clúster reside
en el concepto de ver a cada nodo de un clúster como una máquina muy independiente,
mientras que los nodos de los MPP son prácticamente CPU. Mientras que el clúster
son muchas máquinas actuando como una, el MPP es una única máquina con una gran
cantidad de procesadores, esto se hace extensible en cuanto a sus modelos de memoria
o de interconexión.
3.3.
Red de Interconexión
Las redes de interconexión son elementos esenciales en los supercomputadores. Permiten la comunicación entre los nodos y procesadores de un supercomputador, para
coordinar sus aplicaciones. Las redes de interconexión han ido ganando importancia
con la transformación hacia supercomputadores de tipologı́a clúster, pues permiten un
modelo mucho más escalable y genérico cuando se tiene que programar.
En la lista de los supercomputadores más potentes, la interconexión de sus procesadores es uno de los elementos con mayor diversidad. Dado que con la construcción de
un computador de estas caracterı́sticas no siempre se recurre a una tecnologı́a genérica, si no que, muchas veces se diseña una red de interconexión a medida para cada
máquina. Sin embargo si que existen grandes familias de interconexión que dibujan un
mapa de tendencia. Los tipos de interconexión más extendidos en el mundo de HPC
son InfiniBand y Ethernet, que abarcan casi la totalidad de los 500 sistemas de la lista
del top500 con un 83,8 % de los sistemas. Aproximadamente un 10 % incorporan interconexión personalizada y el resto son otro tipo de redes como,redes propietarias o
Myrinet entre otras.[3]
27
CAPÍTULO 3. ESTADO DEL ARTE
3.3.1.
InfiniBand
InfiniBand representa el 41,4 % de las redes de interconexión del Top 500. La tecnologı́a es actualmente regulada por la Infiniband Trade Association, un consorcio de
empresas que juntaron dos tecnologı́as que se estaban desarrollando por separado, para
crear InfiniBand.
InfiniBand es una tecnologı́a de interconexión conmutada serie, de alta velocidad pensada en su aplicación en HPC. La tecnologı́a permite conexiones punto a punto bidireccionales serie, y dispone de 3 diferentes niveles de rendimiento, dependiendo de la
anchura de los canales de datos (1X, 2X, 12X). Cada uno de estos canales ofrece un
pico de 2,5 GigaBit Por Segundo (Gbps). Por ejemplo, el nivel 1X, ofrece un canal de
2,5 Gbps en cada dirección, el nivel 4X, ofrece 4 canales por cada dirección y el nivel
12X, ofrece hasta 12 canales por cada dirección, lo que otorga solo con estos niveles,
una velocidad pico de hasta 30 Gbps en cada dirección. Esta velocidad de transmisión
se corresponden a bits ”brutos”, debido a la codificación usada por InfiniBand, cada
mensaje se empaqueta con bits para corrección de errores que no son información útil.
La relación de codificación más usada es la que obtiene 8 bits de información por cada
diez bits enviados. Esto sitúa la velocidades pico de Infiniband para información real
en 2 Gbps para enlaces de nivel 1X, o 24 Gbps para enlaces de nivel 12X.
Cada uno de estos canales InfiniBand, actúa como un enlace serie que puede operar
a una de 5 relaciones de transmisión, dependiendo del hardware, el Single Data Rate
(SDR), es el mı́nimo de 2,5 Gbps, el resto de relaciones de transmisión son: Double
Data Rate (DDR), Quad Data Rate (QDR), Fourteen Data Rate (FDR) y Enhanced
Data Rate (EDR). Para cada una de esta relaciones de transmisión existe una codificación distinta que reduce los bits efectivos enviados. Para las relaciones SDR,DDR
y QDR, se usa la codificación de 8bits/10bits (8 bits de información efectiva por cada
10 enviados), esto significa que la velocidad pica efectiva es cuatro quintas partes de
la velocidad real. Para las relaciones FDR y EDR, la codificación usa transmisiones
de 64bits/66bits. Esto significa, que un enlace InfiniBand de nivel 1X, operando a una
relación de transmisión doble (DDR) comunicara mensajes a una velocidad de 5 Gbps
en ambas direcciones, que se reducen a 4 Gbps de bits de información efectivos. A
continuación se muestran las velocidades de transmisión, de información efectiva i total
de los enlaces InfiniBand, dependiendo de el nivel y la relación de transmisión. [5][6][7]
1X
4X
12X
SDR
DDR
QDR
FDR
EDR
2,5
10
30
5
20
60
10
40
120
14,0625
56,25
168,75
25,78125
103,125
309,375
Cuadro 3.1: Ancho de banda total de Infiniband en Gbps
28
CAPÍTULO 3. ESTADO DEL ARTE
1X
4X
12X
SDR
DDR
QDR
FDR
EDR
2
8
24
4
16
48
8
32
96
13,64
54,54
116,36
25
100
300
Cuadro 3.2: Ancho de banda efectivo de Infiniband en Gbps
La latencia en pico de InfiniBand varı́a dependiendo de la relación de transmisión
usada, desde 200 Nanosegundos (ns) con SDR a 100 ns con QDR, unos 10 veces más
lento que una memoria DDR3. Al ser una tecnologı́a conmutada, todos los mensajes
deben empezar y terminar en un .adaptador de canal”. Cada nodo dispone de un Host
Channel Adapter (HCA), y los periféricos usan un Target Channel Adapter (TCA)
para conectarse a la red. Los mensajes InfiniBand pueden tener una longitud de hasta
4 Kilobyte (KB).
3.3.2.
Ethernet
Ethernet es la tecnologı́a de comunicación entre ordenadores por antonomasia,
prácticamente la totalidad de los ordenadores personales, disponen de esta tecnologı́a
para conectarse a Internet. En el mundo de la supercomputación actualmente el 42,4 %
de los ordenadores del Top 500 usan este tipo de interconexión.
Ethernet es una tecnologı́a estandarizada para redes de área local. Este estándar define
ciertas caracterı́sticas del nivel fı́sico y de enlace del modelo Open System Interconnection (OSI). Ethernet mejora a medida que las especificaciones se van definiendo,
básicamente se diferencian y mejoran entre ellas por cuatro conceptos, la velocidad de
transmisión, el tipo de cableado, la longitud máxima y la topologı́a.
En el mundo de los supercomputadores las opciones Ethernet varı́an en gran medida, sin embargo existen dos especificaciones de tiene un gran peso. Un 27 % de los
supercomputadores de la lista del Top 500 usan Gigabit Ethernet, y el 15,5 % usan la
especificación más moderna de 10 Gigabit Ethernet.
Ethernet funciona mediante computadores con acceso al medio por detección de la
onda portadora y con detección de colisiones, y las distintas especificaciones dan a esta
red múltiples soportes fı́sicos, como fibra óptica, o cobre. Las nuevas especificaciones
que están por venir podrı́an elevar la velocidad de esta tecnologı́a hasta 40 y 100 Gbps.
29
CAPÍTULO 3. ESTADO DEL ARTE
3.3.3.
Otras tecnologı́as
Actualmente las dos tecnologı́as anteriores son las dominantes en los supercomputadores, sin embargo aún existe una variedad importante de tipos de interconexión,
debido a que esta tendencia no ha sido siempre ası́, y aún se conservan algunas tecnologı́as más antiguas.
Dos de las redes más llamativas y que dominaron durante un tiempo en el mundo
de HPC fueron las de los ordenadores de la empresa Cray, Cray Interconnect, o la red
de interconexión de clústers de altas prestaciones Myrinet. Actualmente estas tecnologı́as se están quedando fuera del panorama HPC y cada vez se usan menos.
3.4.
Unidad Central de Procesamiento
La CPU es el cerebro de toda la máquina, llevan años perfeccionando su tecnologı́a
y a pesar de que los aceleradores son la fuerza bruta de las máquinas, no se les saca
tanto provecho como a estas unidades.
3.4.1.
Intel Xeon
Los Intel Xeon, son los procesadores para servidores que distribuye Intel, actualmente ocupan una gran parte de la lista del Top 500, concretamente el 79,2 % de las
máquinas disponen de estos procesadores. La gama de Xeon es muy variada, permitiendo procesadores de hasta 12 núcleos, o otros de bajo consumo y la cantidad de hardware
estandarizado para este tipo de arquitectura es enorme.
3.4.2.
IBM Power BQC
Los llamados BlueGene son un proyecto de IBM, enfocado a conseguir rendimientos
de Petaflops (PFLOPS) en un ámbito de bajo consumo. Debido a que estos procesadores son de máquinas tipo MPP, y estas máquinas son muy caras y especı́ficas, su
presencia en el Top 500 es algo menor, un 4,8 % de las máquinas son de tipo BlueGene.
Sin embargo su potencia es bastante relevante pues a pesar de tener tan pocas máquinas, solo estas representan el 18,6 % del rendimiento total de la lista.
3.4.3.
AMD Opteron
AMD es el competidor más directo de Intel en procesadores, sin embargo en el Top
500 no consiguen tener mucha relevancia. Todos los supercomputadores que llevan modelos de procesador AMD son alrededor de un 8 % de las máquinas.
30
CAPÍTULO 3. ESTADO DEL ARTE
3.5.
Aceleradores
Los aceleradores, o coprocesadores, son microprocesadores utilizados como suplemento y apoyo al cálculo de la CPU.
La idea de los aceleradores y coprocesadores, desciende del concepto de los procesadores vectoriales, que se convirtieron es una apuesta firme para la supercomputación
en los inicios de ésta.[3] El uso de un gran nivel de paralelismo fue heredado para las
aplicaciones gráficas, y de esta manera surgieron las Graphics Processing Unit (GPU),
que explotan las pocas dependencias de datos de las aplicaciones gráficas, para ejecutar
algoritmos paralelos masivos. En los últimos años, estos dispositivos se han transformado para volverse en la ”fuerza bruta”de la computación. Estos dispositivos, para HPC,
han perdido su sentido en el mundo de procesamiento gráfico y se han convertido en,
General-Porpouse Computing on Graphics Processing Unit (GPGPU). Actualmente
son uno de los componentes clave para crear los supercomputadores más potentes del
mundo.
Aproximadamente un 11 % de los sistemas en la lista del Top500 disponen de coprocesadores para acelerar sus cálculos. Los sistemas aceleradores más relevantes en la lista
son las GPU de Nvidia en sus distintas arquitecturas, que representan el 72 % aproximadamente, de los sistemas aceleradores, seguidos por los coprocesadores de Intel, Xeon
Phi, que representan un 25 % aproximadamente, del total de aceleradores. El resto de
aceleradores son ATI Radeon, instalados en 2 supercomputadores.[8]
3.5.1.
Coprocesador Intel Xeon Phi
La familia de aceleradores de Intel, lleva por nombre Xeon Phi. Es su particular
apuesta para HPC. Descienden directamente del proyecto Larrabe, que era el intento
de la empresa para adentrarse en el mundo de las GPU. Sin embargo el proyecto fue
cancelado antes de su lanzamiento debido a sus bajos resultados de rendimiento. Fue
entonces cuando se redirigió el proyecto al actual Xeon Phi.
El abanico de modelos se compone de aceleradores de entre 57 i 61 núcleos de procesamiento, basados en la Arquitectura x86, comunicados mediante un bus de interconexión
de tipo anillo y bidireccional. Este bus se compone de 3 buses independientes que se
corresponden con un bus para los datos de 64 Bytes de ancho,un bus de dirección y
finalmente un anillo para los mensajes de confirmación.
Todos estos núcleos disponen de una cache L2 privada y coherente a través de un
sistema de directorios. Los núcleos disponen soporte hardware para hasta 4 hilos.[9]
La frecuencia de estos núcleos esta alrededor de los 1,1 Gigahercios (GHz) y, dependiendo del modelo, dispone de entre 6 i 16 Gigabyte (GB) de memoria. Dos de las mejoras
importantes que incorporan estos aceleradores, son la posibilidad de ejecutar operaciones Simple Instruction Multiple Data de 512 bits, y la memoria de alta velocidad,
que permite un ancho de banda pico de entre 240 i 352 Gigabyte por segundo (GB/s).
El rendimiento pico oscila entre 1,003 i 1,208 Teraflops (TFLOPS) dependiendo de los
distintos modelos.[10]
31
CAPÍTULO 3. ESTADO DEL ARTE
Según los datos anteriores y los Precio de Venta al Público (PVP) que da Intel[11],
los aceleradores de Intel, producen un rendimiento pico de 4,493 Gigaflops por vatio
(GFLOPS/W), en el modelo que dispone de un consumo eléctrico más bajo, y llegan
a los 4,027 GFLOPS/W, en los modelos con mayor consumo eléctrico. El rendimiento
que ofrecen estos aceleradores teniendo en cuenta su coste se sitúa entre 0,397Gigaflops
por euro (GFLOPS/e) y 0,802GFLOPS/e.
3.5.2.
Nvidia Tesla
La rama de hardware Tesla, es la apuesta de Nvidia para HPC, ya diseñada con
objetivos más allá de los gráficos. Es la intención de Nvidia de diseñar GPGPU y el
competidor directo a los coprocesadores de Intel, los Xeon Phi. Actualmente, y debido
a ser de los primeros dispositivos de aceleración en entrar en el mundo HPC, conviven
dos arquitecturas distintas. La arquitectura de Nvidia, Fermi, es la más antigua, i esta
presente en el Top 500 en un 41,15 %, mientras que la arquitectura más actual, Kepler,
ocupa el resto de máquinas con Nvidia.
La arquitectura de las tarjetas gráficas para HPC, parte de la arquitectura del hardware
para hacer gráficos, y de la unificación de los pequeños elementos de procesamiento de
las GPU, los shaders. Estos elementos, eran distintos para cada instancia del pipeline
gráfico, y la evolución de este tipo de hardware, llevo a estos pequeños núcleos a unificarse creando un único núcleo de procesamiento.
La función de procesar gráficos derivó en grupos de grandes de núcleos de procesamiento, divididos por bloques ejecutando cada uno la misma instrucción de código
sobre datos distintos, algo parecido a Simple Instruction Multiple Data. La poca lógica
de control, da la ventaja a las tarjetas gráficas para procesar datos de manera masiva,
pero obliga en caso de tener dependencias, o tratamientos más complejos de los datos,
a tener gran cantidad de núcleos de procesamiento ejecutando código no útil.
Nvidia dispone de 4 generaciones de GPGPU para la última de sus arquitecturas,
Kepler, K10, K20, K20x y K40. Cada una de ellas aumenta el rendimiento pico de la
anterior, que actualmente sitúa su máximo en 1,43 TFLOPS, de la K40, para operaciones de doble precisión, el rendimiento de la primera Tesla con arquitectura Kepler
no llega al teraflop y se queda con 0.19, esto es debido a que la K10, habı́a sido creada
para realizar operaciones con precisión simple y no doble.
Los 4 modelos disponen de 12, 6, 5 y 8 GB de memoria GDDR5 total respectivamente, que en realidad es algo menor, pues si se activan los códigos Error Correcting
Code (ECC), se reduce en un 6,25 % la capacidad efectiva de la memoria. El consumo
eléctrico de estas tarjetas se sitúa por los 235 W en la última de sus versiones, y 225
W en la primera de sus versiones preparada para doble precisión. Esto deja a las tarjetas de Nvidia ofreciendo para las tarjetas con doble precisión y en orden de las más
potente en términos de rendimiento pico a la menos potente: 0,4276 GFLOPS/e[12],
0,5436GFLOPS/e [13] y 0,5945 GFLOPS/e[14]. [15]
32
CAPÍTULO 3. ESTADO DEL ARTE
3.6.
Almacenamiento
Las unidades de almacenamiento permiten mantener grandes cantidades de datos
a largo plazo y permanentemente. Últimamente este elemento esta siendo el cuello de
botella de muchos Centro de Procesamiento de Datos (CPD) pues hasta ahora, las únicas maneras de mantener datos de manera persistente eran mecánicas, y esto provoca
dispositivos lentos, susceptibles a fallos y poco eficientes. Con la irrupción de las memorias flash, y en concreto, los Solid-State Drive (SSD), el panorama de la tecnologı́a de
almacenamiento esta cambiando. Dadas las caracterı́sticas de nuestro CPD dedicado a
HPC, la necesidad de tener unos datos persistentes de manera accesible rápidamente,
no es tan crı́tica como en otro tipo de situaciones, como granjas de servidores web, o
de máquinas virtuales.
3.6.1.
Hard Disk Drive
A dı́a de hoy, la tecnologı́a dominante en cuanto a almacenamiento son los Discos
Duros, o por sus siglas en inglés Hard Disk Drive (HDD). Ésta, es una tecnologı́a de
almacenamiento mecánica que se basa en almacenar los datos en discos magnéticos. El
desarrollo de esta técnica ha permitido conseguir grandes cantidades de memoria a un
coste muy bajo, actualmente a unos 0,2 epor Byte.
Sin embargo el mayor problema de esta, es el hecho de tener una parte mecánica.
Para acceder a los datos es necesario hacer girar los discos magnéticos, y desplazar el
cabezal sobre ellos para poder iniciar las lecturas y escrituras, de manera que, la velocidad a la que se pueden leer depende de la velocidad a la cual se puedan hacer girar.
Esto implica también un consumo importantes de electricidad y producción de ruido.
Actualmente las velocidades de discos más comunes son de 5.400, 7.200, 10.000 y 15.000
Revoluciones Por Minuto (RPM), siendo las dos primeras normalmente aplicadas en
soluciones para portátiles y ordenadores personales de sobremesa respectivamente, y
las dos últimas para el mundo de CPD.
3.6.2.
Solid-state Drive
La tecnologı́a SSD justo empieza a quitar sitio a los HDD por sus infinitas ventajas
respecto estos últimos y principalmente a que se esta consiguiendo bajar el coste por
Byte. Este tipo de almacenamiento no consta de partes mecánicas, por lo que ofrece
velocidades de acceso muy superiores a los dispositivos de almacenamiento mecánicos,
ası́ como consumos mucho más bajos. El limite de ésta tecnologı́a actualmente es su
coste por Byte, alrededor de los 2,8 e, y la capacidad máxima de estos dispositivos.
33
CAPÍTULO 3. ESTADO DEL ARTE
3.7.
Estado del arte en el SCC
Analizar la situación de la competición en los últimos años nos dará una idea general de cual es el hardware dedicado a la competición, que esta ganando y obteniendo
los mejores resultados.
A lo largo de las competiciones, el hardware estandarizado y el hecho de tener que
presentar máquinas de tipo clúster, ha producido el efecto de tener equipos con máquinas bastante parecidas, sin embargo son las pequeñas diferencias las que deciden al
vencedor.
El gran salto del año 2013, en el SCC europeo ha sido la incorporación de los aceleradores en los clústers. Todas las máquinas de la edición de 2013 llevaban algún tipo
de acelerador, a diferencia de su edición anterior, en el que solo una máquina llevaba
aceleradores. La discrepancia entre los aceleradores era entre los sistemas Intel Xeon
Phi y Nvidia Kepler y la cantidad de ellos.
Todas las máquinas llevaban el mismo planteamiento base, dos sockets por nodo, con
dos Intel Xeon E5 de 8 núcleos cada uno, junto con una interconexión InfiniBand FDR.
La gran diferencia entre ellos residı́a en el número de nodos y la cantidad de memoria
de la que disponı́an. Los clústers tenı́an entre 4 y 8 nodos, lo que dejaba el número
total de núcleos entre 64 y 128. Finalmente las cantidades de memoria total diferı́an
bastante entre equipos, situándose en cantidades de entre 256 y hasta 2014 GB.[16][17]
Figura 3.1: Tabla con la configuración hardware de los clústers del SCC edición de 2013
34
CAPÍTULO 3. ESTADO DEL ARTE
Los ganadores de las categorı́as generales del SCC 2013, fueron los equipos sur
africano y chino, en primera y segundo posición respectivamente. Ambos se vieron
beneficiados por tener una mayor cantidad de nodos que sus competidores, y como
consecuencia tener los mayores números de CPUs totales. Sin embargo, la diferencia
entre ellos, llama la atención, pues el equipo que quedó en segundo lugar, a pesar de
llevar 1 TeraByte (TB) de memoria, y disponer de 8 GB por núcleo, fue sobrepasado en
puntuación general, por una máquina con la mitad de memoria por núcleo disponible,
sólo 4 GB por núcleo. En contraposición, encontramos que el equipo con mayor rendimiento en el benchmark High Performance Linpack, disponı́a de una gran cantidad de
memoria por núcleo, 8 GB, como el equipo en segundo lugar en la clasificación general.
Esto hace pensar que, para las aplicaciones del SCC, la memoria no sea un recurso tan
determinante, como la cantidad de nodos de cálculo, y que sean aplicaciones concretas
las que obtengan cierta ventaja de tener grandes cantidades de memoria.
Respecto a los aceleradores, los equipos ganadores de las distintas categorı́as (primera y
segunda posición de la puntuación general, y mejor High Performance Linpack) comparten el hardware de aceleración, todos llevaban Nvidia Tesla con la Arquitectura Kepler
K20. La cantidad de aceleradores varı́a entre equipos, e impacta en el rendimiento de
forma curiosa, pues los equipos ganadores de la categorı́a general, no necesariamente
tenı́an mayores cantidades de aceleradores.
El equipo alemán, concretamente, tenı́a 16 aceleradores, 8 Xeon Phi y 8 Nvidia K20c, y
a pesar de tener todo este potencial de cálculo, no pudieron sacar todo el provecho, sobretodo al tener que ejecutar aplicaciones en ambos aceleradores, por lo que decidieron
ejecutar algunas aplicaciones especı́ficas, en las CPU Nvidia, y otras en los coprocesadores de Intel, dando como resultado un clúster con un gran consumo eléctrico pero sin
ser de los primeros en rendimiento, tal vez el efecto de llevar solo 4 nodos, y en consecuencia, tener 4 aceleradores por nodo, hizo que el cóctel no diera todo su potencial.
Figura 3.2: Equipo de Costa Rica durante la competición del año 2013
35
CAPÍTULO 3. ESTADO DEL ARTE
Los equipos con mejor rendimiento llevaban 1 acelerador por nodo, a excepción de
los dos equipos con mejor rendimiento High Performance Linpack,que llevaban 2 aceleradores por nodo, con 10 aceleradores en total en el caso de mejor rendimiento High
Performance Linpack y 8 en total, en el segundo lugar.[18] En rendimiento para Linpack los 3 primeros puestos estaban muy reñidos con 8,455 TFLOPS, 8,321 TFLOPS
y 8,132 TFLOPS, siendo este último resultado el del segundo equipo en la clasificación
general. La diferencia con la edición anterior es significativa, pues a pesar de llevar, en
general, mayor número de nodos, pero ir sin aceleradores, el mejor rendimiento Linpack
que se obtuvo fue de 2,561 TFLOPS.[19]
Por último, respecto al almacenamiento existen diferencias significativas entres los equipos, tanto como en el ámbito de la tecnologı́a, SSD o HDD, como en el de la configuración, pues algunos llevaban alguna configuración de Redundant Array of Independent
Disks (RAID).
36
Capı́tulo 4
Diseño de un Clúster Teórico
Para presentarse al SCC, hay que llevar un clúster que puede llegar a costar decenas
de miles de euros. En este capı́tulo, aprovechando los conocimientos del estado del arte
de la supercomputación, crearemos un clúster participante, con infinita disponibilidad
de dinero y con el objetivo de obtener la mayor puntuación posible.
4.1.
Restricciones
Las restricciones principales bajo las que debemos estar, siguen las normas del SCC.
En primer lugar, el consumo de los componentes del clúster en funcionamiento en
cualquier momento de la competición no debe exceder los 3.000 W. En caso de que en
algún momento el consumo exceda esa cantidad, una alarma saltara en la mesa de los
jueces, y se descontara puntuación.
Los elementos que cuentan dentro del lı́mite de consumo, serán todos los nodos y
switchs, cualquier computador que pudiera estar monitorizando el sistema y servidores
de Network File System (NFS) o cualquier tipo de refrigeración.
4.2.
Parámetros de decisión
Para escoger los componentes del clúster nos basaremos en varios parámetros. Debido a que estamos simulando la creación de un clúster teórico, no tenemos un techo de
gasto, ası́ los parámetros de coste monetario serán ignorados, no se tendrá muy cuenta
la cantidad de dinero invertido y por lo tanto, no será una prioridad.
La restricción del gasto energético, es un lı́mite importante en el diseño de nuestro
clúster, condiciona el techo de rendimiento, por este motivo, se usarán los parámetros
de coste por vatio y rendimiento en Floating Point Operations Per Second en consonancia, como principales parámetros de decisión.
El consumo de los componentes se indica , al igual que su rendimiento, en pico, eso
37
CAPÍTULO 4. DISEÑO DE UN CLÚSTER TEÓRICO
significa que muy probablemente nunca lleguen a consumir ese pico, de manera que
muy probablemente el cálculo teórico del consumo supere el lı́mite de los 3.000 W, pero
corresponderı́a a la experimentación y el ajuste de parámetros de los benchmarks evitar
superar ese lı́mite.
4.2.1.
CPU
La supremacı́a de Intel en el concurso es indiscutible, absolutamente todos los participantes llevaban un procesador Intel, y los escogeremos también por estar acostumbrados a trabajar con ellos y tener cierta ventaja sobre los AMD. Los sistemas MPP
BluGene aparte de no ser considerados clúster serı́a difı́cil disponer de uno de menos
de 3.000 W.
Durante el último concurso, todos los procesadores eran Intel E5, versiones 2650, 2660,
2670 y 2680, con 8 núcleos cada uno. La evolución de estos procesadores ha llevado a
nuevas implementaciones mejoradas, para analizar esto escogemos las 4 versiones del
anterior SCC y las comparamos con 4 versiones actualizadas de estos procesadores. En
la figura 4.1 se puede apreciar la comparativa entre algunos procesadores de Intel.
El procesador E5-4624L v2 cumple las caracterı́sticas que necesitamos. Para empezar de su gama es el que menor consumo pico tiene, esto compensa en gran medida el
gran consumo de las gráficas. Además incorpora 2 núcleos más que los procesadores
que se usaron en ediciones anteriores, y procesar datos dentro de un mismo procesador
suele ser más rápido. A cambio perdemos velocidad, pero se dispone de aceleradores
para realizar los cálculos a gran velocidad y paralelamente. Con la especificación Simple Instruction Multiple Data dispone de un pico de 200 Gigaflops (GFLOPS) de doble
precisión y ofrece el mayor rendimiento por W con 1,43 GFLOPS/W.
38
Figura 4.1: Tabla comparativa de procesadores Intel: Generación E5-2600 vs E5-4600[20]
39
CAPÍTULO 4. DISEÑO DE UN CLÚSTER TEÓRICO
4.2.2.
GPU
Los resultados de los últimos SCC indican que tener aceleradores en los clústers
aportan un rendimiento adicional suficientemente importante como para pagar su coste en consumo y precio, sin embargo como se ha podido observar, deben ser agregados
de manera inteligente, arrojar toda esa potencia de calculo sin ningún tipo de control
no acaba dando resultados esperados. Es esencial por lo tanto disponer de la cantidad
apropiada de aceleradores.
En la anterior edición del concurso, los aceleradores de Nvidia estuvieron en los equipos
ganadores y con mayor rendimiento, sin una gran diferencia que pueda confirmar que
los aceleradores de Nvidia dan mejor rendimiento en ese tipo de aplicaciones que los
de Intel, pero suficiente para escogerlos como aceleradores para instalar. Dentro de los
aceleradores Tesla, los que mejor rendimiento ofrecen son las últimas versiones, K40,
con 1,43 TFLOPS y 6,085 GFLOPS/W.
Escogeremos estos aceleradores pues se imponen sobre los otros en rendimiento pico, y
en rendimiento por vatio, aunque un consumen un poco más ( 10 W más que sus modelos más avanzados usados en el último SCC, los k20x). Su consumo pico es de 235 W.
4.2.3.
Red de Interconexión
El tipo de red de interconexión que usarı́amos para un clúster, serı́a una red InfiniBand, por varias razones. La tecnologı́a InfiniBand esta expresamente desarrollada
para el mundo de HPC, por lo que incorpora los mejores anchos de banda y latencias.
También nos permite mayor flexibilidad respecto al uso de la torre de capas del modelo
OSI que puede causar cuellos de botella software en el caso de Ethernet.
Para poder ser realmente competitivos, debemos apostar por un máximo número de
nodos, esto permite maximizar la velocidad del uso de la memoria, y dividir el trabajo
entre más procesadores, por lo que instalaremos 8 nodos, para igualar al máximo de
las ediciones anteriores del SCC.
Necesitamos conectar un total de 8 nodos entre ellos, al ser un clúster de tamaño
reducido, con un switch de pocos puertos será suficiente y contribuirá a tener un consumo reducido. El switch de Mellanox SX6005, cumple con los requisitos. Dispone de
interfaces Quad Small Form-factor Pluggable (QSFP)+, tiene 12 puertos, con tamaño
de 1 U,y tiene un consumo de 137 W por cable activo y 110 W por cable pasivo. La
elección de este modelo se justifica por la cantidad de puertos más ajustada, y el soporte
para las velocidades FDR. Esto último dispara el consumo pero nos permite usar la
tecnologı́a más rápida del momento y ya ha sido usada por unanimidad en la anterior
edición del SCC.[21]
Además de un switch para interconectar los nodos, necesitaremos adaptadores para
poder usar los conectores InfiniBand, que admitan un protocolo de 4x y FDR. Con
esta configuración aseguramos una interconexión de 54,54 Gbps de ancho de banda.
Las tarjetas AOC-UIBF-m1 cumplen las especificaciones.[22]
Finalmente para conectar los nodos al switch usaremos los cables InfiniBand pasivos,
40
CAPÍTULO 4. DISEÑO DE UN CLÚSTER TEÓRICO
MC2207130-001, con soporte para velocidades FDR y 1 metro de longitud, suficiente
para conectar dos puntos separados por hasta 22 U.
4.2.4.
Configuración y número de nodos
Para soportar los anteriores elementos de cálculo e interconexión debemos establecer
el número de nodos del que dispondremos, y de hardware de colocación y almacenamiento.
Dado el consumo elevado de las Nvidia Tesla, contaremos con un máximo de 8 de
ellas, una por nodo. Esto implica que será necesaria una placa base, que soporte 2 procesadores de 10 núcleos cada uno, y que tenga como mı́nimo, 2 puertos PCI-express,
uno de ellos de anchura x16 y el otro de x8, para el acelerador y la tarjeta InfiniBand
respectivamente.
El modelo X9QRi-F+ cumple con los requisitos, pues dispone de los puertos necesarios para alojar los dispositivos anteriores, y 4 sockets, de los cuales sólo usaremos
2, para poner las CPU. Se aprovecharán las capacidades de la placa base respecto a la
memoria e instalaremos una memoria muy rápida de 1866 MHz, y una capacidad total
de 1024 GB que dará 6,4 GB por núcleo. Instalaremos DIMMs de 16 GB para poder
utilizar las de máxima velocidad, pues la placa base pide que se use como mucho un
DIMM por canal si se quieren tener velocidades de 1866 MHz.[23]
En cuanto al almacenamiento se refiere, nos decantaremos por la tecnologı́a SSD, por
ser mucho más eficiente y rápida que los discos duros sumado a que no tenemos un
limite de gasto. El modelo de Intel S3700 de 800 GB de capacidad nos servirá.
41
CAPÍTULO 4. DISEÑO DE UN CLÚSTER TEÓRICO
Figura 4.2: Esquema de la placa base[24]
Finalmente, nos hará falta una fuente de alimentación. El consumo pico estimado
de un nodo es de unos 505,8 W, por lo tanto usaremos una fuente que ofrezca 600 W
para alimentar nuestros componentes. La fuente de Athena Power Zippy P2M-6600P
cumple los requisitos.
4.2.5.
Colocación
Debido al gran tamaño de las placas base, y a la altura de las tarjetas gráficas, no
podremos utilizar cajas para servidores estándar, en su lugar usaremos estantes capacitados para ser instalados en racks. En cuanto a la altura, dejaremos un espacio de 3
U entre bases, para que quepan las GPU. Los estantes de Rackmount VSD-1u sirven a
nuestro propósito.
El espacio que suman todos los elementos, es de unas 24 U, que se corresponden a
los 8 nodos de 3 U cada uno, más un espacio adicional para el switch de 1 U también.
El rack PHP 7032 dispone de una altura de 32 U y la anchura necesaria para nuestros
estantes.
Por último, pero no menos importante, añadiremos algunos ventiladores a los nodos,
para que se puedan refrigerar de manera adecuada.
4.2.6.
Sumario
Los consumos estimados se basan en referencias externas a los productos escogidos.
Los consumos no estimados son la potencia consumida máxima que indica el fabricante.
Algunos consumos no ha sido posible tenerlos en cuenta.
42
CAPÍTULO 4. DISEÑO DE UN CLÚSTER TEÓRICO
Hardware
CPU: Intel Xeon E5-4624L
GPU: Nvidia Tesla K40
Memoria: MEM-DR316L-SL02-ER18 (16 GB)
Placa Base: X9QRi-F+
Interfaz de Red: AOC-UIBF-M1
Almacenamiento: Intel SSD DC S3700 (800 GB)
Fuente de Alimentación: Athena P2M-6600P (600 W)
Cables: Mellanox MC2207130-001
Switch: Mellanox SX6005
Refrigeración: Ventilador 120x120x38
Chasis: Rackmount VSD-1u
Rack: PHP 7032 (32 U)
Total
Unidades
Consumo Pico
Precio
16
8
64
8
8
8
8
8
1
24
8
1
1120 W
1880 W
W (estimado)
W (estimado)
Sin datos
W (estimado)
Sin datos
Sin datos
880 W
W (estimado)
0W
0W
4.866,4 W
28.224,64 e
26.094,96 e[12]
13.603,84 e[25]
5.210,18 e[26]
4.104,77 e[27]
11.548,64 e[28]
947,76 e[29]
351,66 e[30]
3.480,30 e[31]
380,16 e[32]
436,95 e[33]
287,81 e[34]
94.671,67 e
192
648
22,4
144
Cuadro 4.1: Sumario del hardware del clúster teórico
4.3.
Métricas Teóricas
Con todo el hardware del clúster teórico definido podemos evaluar el rendimiento
que esperamos de éste. En rendimientos pico, tenemos los procesadores a 0,2 TFLOPS y
las GPU a 1,43 TFLOPS, con 16 procesadores y 8 GPU disponemos de 14,64 TFLOPS.
Si participáramos en el SCC, usando los datos de la edición de 2013, las máquina
con mayor rendimiento en LINPACK tiene su pico en 12,06 TFLOPS, y consigue un
rendimiento con LINPACK de 8,455 TFLOPS, esto implica que en caso de obtener
la misma eficiencia que ellos, dispondrı́amos de una máquina de unos 10,26 TFLOPS
reales para el test de LINPACK.
Respecto al consumo, obtendrı́amos un clúster que podrı́a llegar a consumir hasta
4.866,4 W. De todo este consumo, para comparar con los otros participante de la edición anterior solo tendremos en cuenta el de los elementos que difieren, es decir, CPU,
GPU y el numero de ambos componentes en el clúster, pues para los demás componentes como InfiniBand FDR o placas base consideraremos que consumen mas o menos lo
mismo que nuestros posibles competidores. Esto nos deja pues, con un consumo de las
unidades de computo de 3.000 W.
A pesar de que obtendrı́amos un buen rendimiento, existe a priori, un consumo que
sobrepasa el lı́mite de 3.000 W. Hay que tratar de interpretar pues, que los datos de
consumo han sido escogidos de manera conservadora y en pico, por lo que para alcanzar
este consumo, necesitarı́amos un hardware ocupado a niveles del 100 %, usando todas
sus funcionalidades a la vez, cosa que a la práctica es muy improbable, pues hay recursos que no se usan mientras se esta haciendo computo, y a la inversa.
43
CAPÍTULO 4. DISEÑO DE UN CLÚSTER TEÓRICO
Aún ası́, calculando el consumo pico de los participantes de la edición anterior, y
únicamente teniendo en cuenta el consumo de los componentes de cálculo, sitúa su
máximo en 4.520 y para el equipo con mejor rendimiento LINPACK en 3.200. Debemos dejar constancia entonces que ninguno de los equipos, dispone de un consumo pico
inferior a los 3.000 W y que aún siendo una posibilidad remota alcanzar más de ese
consumo por la definición de pico, son los participantes, los que deben gestionar los
recursos de su clúster para evitar que supere esa cuota. De manera que en caso de ir
al concurso, un entrenamiento previo con el hardware nos ayudarı́a a determinar que
dispositivos podemos estar usando de manera simultanea y en que cantidad.
44
Capı́tulo 5
Hardware del Clúster
A continuación se detallan los elementos hardware que constituyen el clúster que se
ha construido.
5.1.
Arndale Octa
Las placas Arndale Octa, del fabricante In Signal, cedidas por el BSC, son el hardware que usaremos a modo de nodo en nuestro clúster. Integran los componentes necesarios de computación. El principal componente es el System on a Chip Exynos 5420,
que lleva la capacidad de computo de la placa. Ademas integra también una pequeña
memória NAND de 4 GB, KLM4G1FE3B-B001, que almacena un sistema operativo
preinstalado. También dispone de las interficies de comunicación necesarias, como un
puerto Ethernet de 100 Mega Bits Por Segundo (Mbps) de ancho de banda, Universal
Serial Bus (USB) 3.0, High-Definition Multimedia Interface (HDMI) y también de una
interfaz de conexión serie RS-232.
Figura 5.1: Esquema de la arquitectura de la placa Arndale Octa
45
CAPÍTULO 5. HARDWARE DEL CLÚSTER
5.1.1.
SoC Samsung Exynos 5420
El principal componente de la placa Arndale Octa es el System on a Chip de Samsung, Exynos 5420. Éste, integra dos CPU multi-núcleo ARM, el Cortex-A15 y el
Cortex-A7 con cuatro núcleos de cada uno. Además incorpora una GPU de ARM, la
Mali-T628. Junto con estos últimos elementos de procesamiento. El chip dispone de 2
GB de memoria principal a una velocidad de hasta 933 Megahercios (MHz).
CPU: ARM Cortex-A15 MP + Cortex-A7 MP
Los Cortex-A15 y A7 en su versión multi-núcleo son las CPU del Exynos. Se trata de dos clusters de 4 núcleos de cada uno de los procesadores de ARM, ambos con
la penúltima especificación del lenguaje máquina de ARM, el ARMv7. Los núcleos
Cortex-A15 tienen una velocidad máxima de 1,8 GHz i los Cortex-A7 de 1,2 GHz.
El conjunto de instrucciones que soporta empieza a tener un buen soporte para el
mundo HPC, en la versión de ARMv7 han añadido capacidades especiales. Como la
capacidad de usar operaciones vectoriales NEON (el Simple Instruction Multiple Data
de ARM) y la extensión de las instrucciones a 32 bits. Además incluye las unidades de
coma flotante por hardware que aumentan significativamente la velocidad en comparación con la coma flotante basada en software.
A pesar de haber añadido todas las funcionalidades anteriores, aún hará falta esperar a la nueva especificación del lenguaje máquina de ARM, el ARMv8, para disponer
de avances vitales si esta tecnologı́a tiene que entrar en el mercado de HPC. De la
ARMv8 se espera disponer de una arquitectura de 64 bits ası́ como operaciones vectoriales para coma flotante de doble precisión. También implica disponer de mayor
cantidad de registros.
La arquitectura del Cortex-A15 tiene caracterı́sticas interesantes. Observando la figura
5.2 podemos observar como el procesador es capaz de enviar a ejecutar 3 instrucciones
a la vez, y que mientras no sean saltos o instrucciones de multiplicación y acumulación
2 de las 3 instrucciones enviadas pueden ser las mismas.
46
CAPÍTULO 5. HARDWARE DEL CLÚSTER
Figura 5.2: Pipeline del Cortex-A15
GPU: Mali-T628 MP6
La Mali-T628 es la tarjeta gráfica que incorpora el System on a Chip. La especificación permite crear chips con hasta 8 shaders de cálculo, en concreto, en el Exynos
5420 la Mali dispone de 6 de ellos.
47
CAPÍTULO 5. HARDWARE DEL CLÚSTER
Figura 5.3: Esquema de la arquitectura de la Mali-T628 MP6
Cada uno de estos núcleos de proceso, o shader cores, dispone de 4 unidades funcionales que pueden actuar en paralelo, 2 de para operaciones aritméticas y 2 más, para
diferentes operaciones de carga de datos o texturas.[35]
Figura 5.4: Esquema de la arquitectura de los shaders de la Mali
La versión de Mali que implementa el chip Exynos de la Arndale Octa opera a una
velocidad de 533 MHz y ofrece un rendimiento de hasta 109 GFLOPS.[36]
48
CAPÍTULO 5. HARDWARE DEL CLÚSTER
5.1.2.
Interfaz de Red: 100Mbps Ethernet
La interfaz de red que ofrece la placa Arndale Octa, es Ethernet a una velocidad
de 10/100 Mbps para conectores RJ-45. La interfaz está conectada al Exynos en el
mismo lugar que el USB 2.0, por lo que implica tener un hub entre el procesador y las
2 interfaces. Esto se puede apreciar en la figura 5.1.
5.1.3.
Almacenamiento: Tarjeta microSD + eMMC
Respecto al almacenamiento la placa Arndale Octa, ofrece dos maneras distintas
de almacenar datos de manera persistente. La placa incorpora un chip de memoria, el
Samsung KLM4G1FE3B-B001, con una capacidad de 4 GB, y con un sistema operativo Android preinstalado en él. Otra posibilidad es usar el puerto especializado para
tarjetas microSecure Digital (SD).
En nuestro caso, dispondremos de tarjetas microSD de 16 GB para usar a modo de
disco duro, donde instalaremos el software de sistema y ciertas aplicaciones concretas
de la pila de software necesaria para usar el clúster.
5.2.
Red de Interconexión: 100Mb Ethernet
Para realizar la interconexión tenemos a nuestra disposición la tecnologı́a Ethernet,
usaremos 6 cables Ethernet de cobre pasivos de 1,5 metros para conectar la interfaz
de red de la placa Arndale Octa con nuestro switch de interconexión. El switch es un
modelo de NetGear FS524 de 24 puertos.
5.3.
Almacenamiento: NFS
Para poder ejecutar las aplicaciones de tipo HPC es necesario disponer de más almacenamiento que el que nos pudiera dar una tarjeta microSD de 16 GB. Para solucionar
este problema instalaremos un sistema NAS a través de la red por NFS, y usaremos
parte del espacio que tenemos disponible en el disco del PC1.
El hardware para almacenamiento que compartiremos de PC1 con el clúster es un
disco duro de 500 GB de capacidad, modelo Seagate ST3500418AS.
5.4.
Limitaciones del hardware
Debido a que es un hardware bastante nuevo y de entrenamiento, hay muchas utilidades a las cuales no se les puede sacar todo el provecho que se podrı́a, o simplemente
aún no están disponibles. A través de la experimentación y documentación hemos determinado cuales de estas utilidades que nos hubieran permitido mejorar el rendimiento
de los nodos.
49
CAPÍTULO 5. HARDWARE DEL CLÚSTER
5.4.1.
OpenCL
OpenCL es una especificación de una Aplication Programming Interface (API) y
lenguaje de programación que permite crear aplicaciones que exploten el paralelismo
y puedan ser ejecutadas tanto en CPU como en GPU. Esto nos permitirı́a explotar el
poder de cálculo de la tarjeta gráfica.
A pesar de que la Mali soporta OpenCL 1.1, los drivers para poder usarlo no están
disponibles aún para la Arndale Octa.Existen, y es posible disponer de los drivers para
usar el espacio de usuario y kernel de la memoria en la Mali, pero en este momento no
se han distribuido los drivers para el núcleo de OpenCL.
5.4.2.
OpenGL Compute Shaders
Otra opción para aprovechar la capacidad de computo del procesador gráfico, esta
en usar OpenGL. OpenGL es una API pensado para producir gráficos 2D y 3D por
ordenador. En las últimas especificaciones de OpenGL han añadido la funcionalidad
de los Compute Shaders, se trata de usar operaciones de OpenGL, pero sin tener el
enfoque de entrada y salida, permitir realizar operaciones para cálculo.
Arndale Octa ofrece soporte para OpenGl hasta la versión 3.0, sin embargo los Compute Shaders han sido añadidos para la versión 4.3, de modo que se debe descartar esta
opción como modo para usar la capacidad de computo de la Mali.
5.4.3.
big.LITTLE
big.LITTLE es el nombre que recibe la tecnologı́a de ARM que permite coordinar
sus procesadores de mayor rendimiento con los de mayor eficiencia para exprimir la
capacidad de procesamiento del hardware. Esta tecnologı́a permitirı́a a los Cortex-A15
y Cortex-A7 trabajar conjuntamente y hace disponer de 8 núcleos a las placas Arndale
Octa.
Para activar la tecnologı́a big.LITTLE y poder hacer uso de los 8 núcleos del Exynos 5, no es suficiente con encontrar una imagen compatible con la tecnologı́a. Las
últimas imágenes precreadas del sistema operativo para estas placas no llevan las opciones de soporte de big.LITTLE activadas, de manera que se debe bajar el código
fuente de las imágenes, y realizar una compilación propia, activando las opciones para
incluir en el kernel el soporte para big.LITTLE.
A pesar de haber intentado generar una imagen del sistema operativo con soporte
para big.LITTLE, no se obtuvo éxito al intentar arrancar dicha imagen, por lo que no
se puede disponer de esta tecnologı́a.
50
CAPÍTULO 5. HARDWARE DEL CLÚSTER
5.4.4.
Interfaz Ethernet
La interfaz de Ethernet es uno de los mayores cuellos de botella que tenemos en
el sistema hardware. Para empezar el estándar es de tan sólo 100 Mbps, en HPC actualmente se están instalando para Ethernet interfaces en los nodos de hasta 40 Gbps.
También existe un problema respecto a la arquitectura de la placa Arndale Octa. Las
conexiones Ethernet y los puertos USB están conectados a un hub y usan el mismo
hardware de interfaz. Esto significa que necesitan pasar por un chip controlador que
reduce la velocidad a la que podemos mandar mensajes.
Debido a estos problemas, es altamente probable, que la comunicación entre nodos,
sea a una velocidad tan lenta que haga que sea más factible ejecutar un programa en
un único nodo, que distribuirlo entre los demás mediante un sistema de paso de mensajes.
5.4.5.
Escalar la frecuencia de la CPU
A pesar que la velocidad máxima de las CPU se sitúa en 1,8 GHz en el caso de los
Cortex A-15 o 1,2 GHz para los A7, la experimentación con el hardware y su evaluación
nos ha dado resultados inferiores a los esperados. La mayor culpa de ello lo tiene la
frecuencia de operación de a la que operan los procesadores, que esta definida por unos
registros que inicializa el kernel que usamos para arrancar las placas. Las imágenes de
este sistema operativo limitan la velocidad del procesador a 0,8 GHz. Hay que pensar
que estas placas no disponen de ningún sistema de refrigeración, por lo que tenerlas
a máxima frecuencia muy probablemente producirı́a un apagado de emergencia por
temperatura a los pocos minutos.
5.5.
Sumario del Hardware
En resumen el hardware usado que constituye al clúster es el siguiente:
Nodo: Arndale Octa (x6)
• System on a Chip: Samsung Eynos 5420
◦ CPU: ARM Cortex-A15 (x4) + ARM Cortex-A7 (x4)
◦ GPU: Mali T-628
◦ Memoria: 2 GB 933 MHz
• 100 Mbps Interfaz Ethernet
• Almacenamiento:
◦ 4 GB Embedded Multi-Media Card (eMMC)
◦ 16 GB SD
Switch: NetGear FS524
Cables Ethernet Cobre (x6)
Transformadores (x6)
51
CAPÍTULO 5. HARDWARE DEL CLÚSTER
5.6.
Clúster de Arndale Octa
Figura 5.5: Vista del clúster (cerveza para comparar la escala)
Figura 5.6: Vista del clúster (cerveza para comparar la escala)
52
CAPÍTULO 5. HARDWARE DEL CLÚSTER
Figura 5.7: Vista cercana del clúster
Figura 5.8: Vista del switch de interconexión
53
CAPÍTULO 5. HARDWARE DEL CLÚSTER
Figura 5.9: Vista general del clúster
54
Capı́tulo 6
Diseño y Configuración del
Clúster ARM
6.1.
Emplazamiento del hardware
La localización del clúster es en el edificio C6 del Campus Nord de la Universitat
Politécnica de Catalunya (UPC), concretamente el laboratorio 103. El edificio pertenece al departamento de arquitectura de computadores, y dispone de una red interna con
un servidor Dynamic Host Configuration Protocol (DHCP) que únicamente da acceso
a las Media Access Control (MAC) registradas. Por este motivo las Arndale Octa no
pueden tener un acceso directo a la red.
El laboratorio dispone de suelo técnico por toda su superficie y parte de él está separado por cristales formando una pequeña ”pecera”.La distribución del hardware en
el laboratorio es la siguiente:
Figura 6.1: Distribución del hardware en el laboratorio
55
CAPÍTULO 6. DISEÑO Y CONFIGURACIÓN DEL CLÚSTER ARM
En este laboratorio, disponemos de dos ordenadores comunes para realizar el trabajo, el hardware que llevan instalado es el siguiente:
PC1:
• CPU: Intel Core i5-650
• Placa Base: HP 304Ah
• Memoria: 8 GB 1333 MHz
• Interfaz de Red: 2 Tarjetas 100 Mbps Ethernet
• Almacenamiento: Seagate ST3500418AS (500 GB)
PC2:
• CPU: Intel Core 2 Duo E8500
• GPU: ATI Radeon HD 3450
• Placa Base: HP 3031h
• Memoria: 4 GB 800MHz
• Interfaz de Red: Tarjeta 1 Gbps Ethernet
• Almacenamiento: Western Digital WD500AAKS-6 (500 GB)
6.2.
Diseño de la red de interconexión
Debemos conectar todos los elementos de nuestro clúster para poder disponer de
diversas utilidades. El acceso a Internet, aunque no deberı́a ser estrictamente necesario,
lo usaremos para dos propósitos distintos, el acceso al clúster de manera remota, sin
necesidad de acceso al switch de interconexión, y la descarga de paquetes y programas
necesarios. Esto facilitará y agilizara la instalación de software. También usaremos la
interconexión para poder montar un sistema de archivos a través de la red NFS y mantener un servidor de monitorización del clúster.
Debido a las caracterı́sticas de la red interna del Departament d’Arquitectura de Computadors (DAC) y a que únicamente los dos ordenadores que tenemos para trabajar disponen de dirección MAC registrada, debemos conectar el clúster a la red a través de
uno de ellos. Esto implicará configurar un servidor DHCP en uno de los ordenadores
para asignar las IP de la red del clúster a los nodos y activar la opción de forwarding
para los paquetes que vengan de tal red.
56
CAPÍTULO 6. DISEÑO Y CONFIGURACIÓN DEL CLÚSTER ARM
Figura 6.2: Configuración de la red del clúster del laboratorio
Para configurar forwarding en PC1 hace falta modificar el fichero /etc/iptables.sav:
Hay que añadir básicamente dos lı́neas:
-A FORWARD -s 192.168.0.0/24 -i eth1 -o eth0 -m conntrack --ctstate NEW -j ACCEPT
Esto le dice a la máquina que todos los paquetes que entren por la interfaz eth1,
de la red 192.168.0.0/24 salgan por la interfaz eth0 y que las conexiones que tengan un
estado de ”nuevo”sean aceptadas y se tome constancia de ellas.
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Este comando establece que se acepten los paquetes de las conexiones que ya han sido
establecidas, independientemente de donde vengan. Esto permite que las únicas conexiones las establezca el clúster desde dentro, y solo se acepten paquetes que llegan desde
fuera cuando la ya se ha establecido la conexión previamente por petición de algún nodo.
57
CAPÍTULO 6. DISEÑO Y CONFIGURACIÓN DEL CLÚSTER ARM
6.3.
Configuración del hardware
En primera instancia, para poder arrancar el software que nosotros queremos instalar en la tarjeta SD, debemos configurar unos pequeños pines en forma de switch como
señala la figura 6.4 para indicar-le al hardware que arranque desde la tarjeta externa,
y no desde su chip de almacenamiento integrado.
Figura 6.3: Configuración para arranque desde la eMMC integrada (por defecto)
Figura 6.4: Configuración para arranque desde la tarjeta SD
Una vez configurados los pines y insertada la tarjeta SD al dar alimentación a la
placa esta arrancara y cargará el bootloader para arquitectura ARM que encuentre en
la SD, el u-boot.
6.4.
Arranque: Configuración de U-boot
Cuando la placa Arndale Octa recibe potencia, siguiendo la configuración de pines
anteriormente mencionada carga desde la tarjeta SD un bootloader. Este programa tiene
la misión de cargar el kernel del sistema operativo e inicializar el sistema de ficheros
raı́z, ya sea desde una memoria flash, NFS u otros métodos. Para que U-boot cargue
correctamente nuestro sistema operativo hay ciertas opciones a especificar durante el
procesa de arranque, una vez U-boot a cargado y se puede configurar con su interfaz.
Los comandos a ejecutar para configurar un arranque de nuestra imagen son los siguientes:
$ setenv bootcmd "run addmac; fatload mmc 0:2 0x20007000 uImage; \
fatload mmc 0:2 0x22000000 uInitrd; fatload mmc 0:2 0x21f00000 \
board.dtb; bootm 0x20007000 0x22000000 0x21f00000"
$ setenv bootargs "console=tty0 console=ttySAC3,115200n8 \
root=UUID=41e0aae3-60d8-4fc2-bec4-fb486f5352ed rootwait ro"
58
CAPÍTULO 6. DISEÑO Y CONFIGURACIÓN DEL CLÚSTER ARM
6.5.
Gestión del hardware
Para poder gestionar el hardware sin necesidad de un sistema operativo, y poder
hacer arrancar al U-boot, es necesario tener una conexión fı́sica con la placa. Esta conexión nos la ofrece una interfaz serie a través de RS-232 de la que dispone la placa,
en la figura 6.5 se puede observar el tipo de interfaz especificada. Para poder iniciar la
comunicación necesitamos un programa de comunicación serie.
$ sudo apt-get install minicom
Este comando instala el programa de comunicación por serie.
Los parámetros para establecer la conexión serie con la placa son:
115200 bits por segundo.
8 bits de datos.
1 bit de parada.
Sin bit de paridad.
Figura 6.5: Vista de la interfaz RS-232
59
CAPÍTULO 6. DISEÑO Y CONFIGURACIÓN DEL CLÚSTER ARM
6.6.
Configuración de la Red
Para configurar la red del clúster, hemos usado los siguientes criterios:
La red usara la máscara 255.255.255.0 que determina los 8 últimos bits de cada
dirección como la dirección de host.
La numeración de la dirección de red será 192.168.0.0.
La IP del ordenador que servirá de router y salida a la red del departamento
será 192.168.0.1, este ordenador será el PC1 por ser el más potente.
Las direcciones IP asignadas a los nodos o placas, corresponderán con los dos
últimos dı́gitos de la numeración impresa de fábrica, de manera que para la placa
con numeración AOP1402170681A se le asignará el número de placa 81 y la IP
192.168.0.81.
Cualquier otro dispositivo que se conecte a esta red a través del switch se le
asignará una IP a través del servidor DHCP.
Número de Placa
81
82
83
84
85
86
Dirección MAC
Dirección IP
02:0e:0c:d6:94:24
02:35:8c:d6:94:24
02:b5:0c:d6:94:24
02:f6:0c:d6:94:24
02:75:cc:56:94:24
02:b6:2c:56:94:24
192.168.0.81
192.168.0.82
192.168.0.83
192.168.0.84
192.168.0.85
192.168.0.86
Cuadro 6.1: Asignación de direcciones para los nodos
6.6.1.
DHCP
La configuración del servidor DHCP tendrá dos objetivos. Permitir la conexión de
equipos y su correspondiente asignación de IP, a la red interna del clúster de manera
automática, y asignar direcciones IP de manera estática a los nodos del clúster mediante el uso de sus direcciones MAC.
El primer objetivo será necesario para la gestión del clúster desde dentro, o cuando
no sea posible de manera remota. Se consigue montando un servidor DHCP en nuestro
ordenador de salida de la red. Es de vital importancia que este servidor solo actúe en
la red interna del clúster, si estuviese funcionando con la interfaz de salida a la red del
DAC podrı́amos producir colisiones y errores en todo el departamento.
60
CAPÍTULO 6. DISEÑO Y CONFIGURACIÓN DEL CLÚSTER ARM
La instalación del servicio DHCP se realiza mediante los repositorios de la distribución de Linux correspondiente:
$ sudo apt-get install isc-dhcp-server
Esto permitirá tener el servidor y el daemon listo, y generará ciertos ficheros de configuración que debemos modificar:
/etc/dhcp/dhcpd.conf (en el servidor PC1):
• Parámetros del servidor DHCP:
default-lease-time 600;
max-lease-time 7200;
Estas lineas especifican los tiempos que se mantendrán reservadas las IP.
• Definir la red sobre la que actuara el servidor DHCP:
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.100 192.168.0.150;
option routers 192.168.0.1;
option domain-name-servers 8.8.8.8, 8.8.4.4;
option domain-name "clusterocta.org";
}
La primera linea permitirá que el servidor identifique cual de las dos interfaces esta conectada a la red del clúster y responda a las peticiones de los
nodos, pero no actúe sobre las red del DAC. Dentro de la definición de la
red, se encuentra en primer lugar el rango de direcciones IP que se asignarán a las peticiones que procedan de esta red, seguido de los parámetros
de información de los que se informará el servidor, como la dirección de los
servidores de Domain Name Service (DNS) o el router de salida a la red
exterior.
El segundo objetivo, nos permitirá tener acceso a los nodos de manera controlada, siendo conscientes en cada momento de cual es su dirección IP y
siendo esta inmutable a pesar de cambiar los kernels o sistemas operativos
que instalemos.
• Otorgar IP estática para los nodos del clúster mediante dirección MAC:
host octa-81 {
hardware ethernet 02:0e:0c:d6:94:24;
fixed-address 192.168.0.81;
}
host octa-82 {
hardware ethernet 02:35:8c:d6:94:24;
fixed-address 192.168.0.82;
}
host octa-83 {
hardware ethernet 02:b5:0c:d6:94:24;
fixed-address 192.168.0.83;
}
host octa-84 {
61
CAPÍTULO 6. DISEÑO Y CONFIGURACIÓN DEL CLÚSTER ARM
hardware ethernet 02:f6:0c:d6:94:24;
fixed-address 192.168.0.84;
}
host octa-85 {
hardware ethernet 02:75:cc:56:94:24;
fixed-address 192.168.0.85;
}
host octa-86 {
hardware ethernet 02:b6:2c:56:94:24;
fixed-address 192.168.0.86;
}
La directiva host nos permite especificar opciones para un dispositivo que
realice peticiones DHCP en nuestra red. Para otorgar IP estáticas usamos
la directiva fixed-address y especificamos la MAC que debe coincidir con ese
dispositivo mediante hardware ethernet. Ahora, a pesar de que conectemos y
desconectemos los nodos de la red, siempre tienen una IP fija y controlada.
/etc/network/interfaces (en los nodos):
• Configurar la interfaz de red para que use la asignación automatica de IP
por DHCP cuando se active la interfaz Ethernet:
auto eth0
iface eth0 inet dhcp
Las sentencias de este fichero le indican al nodo que cuando se configure
automáticamente cuando se active la interfaz Ethernet y que use mensajes
de DHCP para que le digan que IP tiene que asignar a su interfaz.
6.6.2.
Disco en NFS
Se ha escogido el nombre de /ancient para montar la unidad en red. Para poder
configurar un sistema de ficheros en red, y poder disponer de más capacidad de almacenamiento para nuestro clúster hemos seguido estos pasos:
Instalación del servicio NFS en el PC1:
$ sudo apt-get install nfs-kernel-server nfs-common
Este comando instala los servicios para NFS.
/etc/exports (en el servidor PC1):
• Configuración del PC1 para que exporte un directorio de disco para la red:
/ancient 192.168.0.0/255.255.255.0(async,rw,no_root_squash,
\no_subtree_check)
Este comando permite anunciar la unidad /ancient a través de la red 192.168.0.0.
/etc/fstab (en los nodos):
• Configuración de los nodos para importar el directorio por red:
UUID=41e0aae3-60d8-4fc2-bec4-fb486f5352ed / ext4 errors=remount-ro 0 1
192.168.0.1:/ancient /media/ancient nfs rsize=8192,wsize=8192,timeo=14,$
62
CAPÍTULO 6. DISEÑO Y CONFIGURACIÓN DEL CLÚSTER ARM
Esta lı́nea le dice al nodo que monte en su directorio /media/ancient por
NFS el directorio en red con dirección 192.168.0.1.
63
Capı́tulo 7
Evaluación del Clúster
7.1.
Metodologı́a
El Yokogawa WT230 es el equipo que usaremos para realizar las mediciones de
consumo, se trata de un dispositivo medidor de potencia que permite tomar medidas
de tensión, intensidad y potencia de las tomas de corriente que se desee.
Usaremos ciertos test para estresar el clúster y comprobar la eficacia del hardware.
7.1.1.
Configuración de Yokogawa
Yokogawa dispone de una pantalla de control donde se pueden visualizar las medidas de intensidad, tensión y potencia, sin embargo ofrece también un método más
fiable, para poder recopilar todas las muestras en un ordenador. Esta opción se realiza
mediante la comunicación serie con una conexión USB/RS232. Para poder comunicar
el ordenador portátil que usaremos y Yokogawa los parámetros de la la conexión serie
deben ser los siguientes:
9600 bits por segundo.
8 bits de datos.
1 bit de parada.
Sin bit de paridad.
64
CAPÍTULO 7. EVALUACIÓN DEL CLÚSTER
Figura 7.1: Vista del Yokogawa tomando medidas del consumo del switch
Usando un pequeño programa en Python, tomaremos las mediciones que Yokogawa
nos enviará (3 por segundo) y se calculará una media de las muestras tomadas durante
40 segundos.
Para poder usar el Yokogawa hace falta instalar su voltı́metro y su amperı́metro, de la
forma correspondiente en cada caso, a la misma toma de corriente que el ladrón usado
para conectar todos los transformadores y el switch.
Figura 7.2: Esquema de la conexión del Yokogawa a las tomas de corriente del clúster
65
CAPÍTULO 7. EVALUACIÓN DEL CLÚSTER
7.2.
Tests de estrés
Los programas que se usarán para poner a prueba las caracterı́sticas de las placas
son los siguientes:
Benchmark kernels de Montblanc:
• DGEMM: Multiplicación de matrices de coma flotante AxB.
• VECOP: Copia de un vector en memoria.
Benchmark de High-Performance Computing Cluster (HPCC):
• Stream: Calculo del ancho de banda con memoria.
• Tests Ancho de Banda para Red.
Una descripción más detallada de los benchmarks y su funcionamiento se puede
encontrar en el trabajo de Constan, Diseño de un clúster HPC: Aplicaciones.[37]
7.3.
Rendimiento pico esperado
Analizando todo el abanico de hardware del que eventualmente disponemos, básicamente dos dispositivos contribuyen a la potencia de cálculo del System on a Chip
Exynos 5420, la GPU y las CPU.
El rendimiento pico de la GPU se sitúa en los 109 GFLOPS. Para los procesadores
tenemos, 4 ARM Cortex-A15, cuyo pico teórico de velocidad es 1,8 GHz puede enviar
a ejecutar 3 instrucciones por ciclo, pero solo dispone de dos unidades funcionales para
ejecutar instrucciones de coma flotante al mismo tiempo, esto sitúa el rendimiento pico
de los 4 Cortex-A15 en 14,4 GFLOPS.
Por último están los Cortex-A7, que suponiendo una velocidad máxima de 1,2 GHz,
y siendo capaces de enviar 2 instrucciones a ejecutar pero solo 1 instrucción de coma
flotante a la vez, proporciona 4,8 GFLOPS entre los 4 Cortex-A7.[36]
Esto sitúa el rendimiento pico del System on a Chip Exynos 5420 en 128,2 GFLOPS
disponiendo de todo el hardware.
Sin embargo debemos tener en consideración diversas limitaciones del hardware descritas en el capı́tulo anterior. Esto implica, no poder usar la Mali por falta de controladores,renunciar también a los Cortex-A7 pues requieren una compilación concreta del
kernel para poder activar el sistema big.LITTLE y poderlos usar, finalmente también
tenemos una frecuencia de operación reducida en los Cortex-A15 a 0,8 GHz lo que nos
deja en total un rendimiento pico por placa Arndale de únicamente 6,4 GFLOPS.
El pico de nuestro clúster, con 6 nodos, se sitúa por lo tanto, en los 38,4 GFLOPS
habiendo descartado el hardware que no hemos podido activar.
66
CAPÍTULO 7. EVALUACIÓN DEL CLÚSTER
7.4.
Rendimiento obtenido
Potencia de cálculo
Ejecuciones de DGEMM en un único nodo:
Tipo de datos
Número de trheads
float
1
2
3
4
1
2
3
4
double
Mejor Rendimiento
1,36
2,69
3,56
5,2
1,26
2,38
2,96
4,36
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
Cuadro 7.1: Mediciones de rendimiento con DGEMM
Figura 7.3: Gráfico rendimiento de 1 nodo
A nivel de un nodo, podemos observar como el hardware tiene una buena escalabilidad y presenta un buen rendimiento, pues casi obtenemos rendimientos cercanos
al pico. En concreto usando el máximo de núcleos disponibles se obtiene un 81 % de
eficiencia en estos benchmarks, que desciende cuando el tipo de datos es de doble precisión, lo que podrı́a estar indicando que puede haber un bajada de rendimiento debido
a la memoria y su ancho de bus de 32 bits, o a un hardware de cálculo para la doble
precisión no tan optimizado.
Ejecuciones de High Performance Linpack en el clúster:
67
CAPÍTULO 7. EVALUACIÓN DEL CLÚSTER
Número de trheads
Rendimiento
1
2
4
6
8
10
12
14
16
18
20
22
24
1,25
2,36
4,27
5,11
5,94
6,1
6,44
7,24
7,91
8,57
8,8
9,39
10,64
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
GFLOPS
Cuadro 7.2: Mediciones de rendimiento con DGEMM
Figura 7.4: Gráfico rendimiento del clúster
Aunque a primera vista, pueda parecer que hay un buen incremento en el rendimiento, se puede observar como el crecimiento de éste cambı́a bruscamente cuando los
threads tiene que empezar a usar la red Ethernet, para ejecutarse en otros nodos, a
partir de los 4 threads. Esto se presenta como un problema mayor, pues mina significativamente la capacidad de escalar el clúster.
Ancho de banda con memoria
Ejecuciones de VECOP en un único nodo:
En comparación a las memorias actuales, que ofrecen hasta 14 Gbps, la memoria
del Exynos es algo más modesta, pues tiene una frecuencia de tan solo 933 MHz. En
otros tests se han conseguido anchos de banda de hasta 6 Gbps que aproxima un poco
más a la velocidad pico de la memoria.
68
CAPÍTULO 7. EVALUACIÓN DEL CLÚSTER
Tipo de datos
Número de trheads
float
Mejor Rendimiento
1
2
4
1
2
4
double
2,09
3,17
4,13
3
4,12
4,52
Gbps
Gbps
Gbps
Gbps
Gbps
Gbps
Cuadro 7.3: Mediciones de Ancho de Banda con VECOP
Rendimiento de la red de interconexión
Los tests de ancho de banda sobre la red Ethernet, nos dan máximos de 93,2 Mbps,
cosa que nos indica que se esta aprovechando de buena manera el máximo ancho de
banda de la red, sin embargo ésta no da para más, y se queda corta en velocidad, pues
obtenemos latencias de 0,33 milisegundos, que comparados con los 6 microsegundos
de media que ofrecen algunas redes InifiniBand, dejan al clúster en cierta desventaja,
sobretodo desde el punto de vista de ampliar el número de nodos. La red 100 Mbps no
ofrece la capacidad deseada para HPC y rápidamente se satura con altas latencias.
7.5.
Mediciones de Consumo
Consumo de los componentes hardware del clúster:
Consumo medio
Hardware
Yokogawa
Transformador
Nodo sin carga
Switch (7 puertos activos)
High Performance Linpack en 1 nodo con 4 threads
High Performance Linpack en 6 nodos con switch
0.025
0,14
3,48
19,71
7,73
62,58
Cuadro 7.4: Consumo medio de los componentes hardware
69
W
W
W
W
W
W
CAPÍTULO 7. EVALUACIÓN DEL CLÚSTER
Figura 7.5: Distribución del consumo total estimado
Como se puede observar en la figura 7.5, el consumo perdido por la eficiencia de
los transformadores es bastante pequeña, aún ası́, probablemente podrı́a mejorar si
se diseñase una fuente de alimentación única, y una manera de alimentar las placas
unificada. Al consumo de los transformadores, le sigue el del switch que responde a un
31 % del total, aún teniendo en cuenta que hay un nodo de control de más (PC1).
Ejecuciones de DGEMM en un único nodo:
Tipo de datos
Número de trheads
float
1
2
3
4
1
2
3
4
double
Consumo medido
4.28
5.02
5.69
6.59
4.67
5.55
6.16
7.25
Cuadro 7.5: Mediciones de consumo con DGEMM
70
W
W
W
W
W
W
W
W
CAPÍTULO 7. EVALUACIÓN DEL CLÚSTER
Figura 7.6: Gráfico consumo en 1 nodo
La escalabilidad del consumo de un único nodo es bastante buena y proporcional. El
hardware escala su consumo de forma lineal con la ventaja de partir de un punto muy
inferior a los dispositivos comunes. se puede observar en la figura 7.6 que el consumo
”basal”de la placa es de unos 3 W pero que ir activando núcleos solo aumenta su
consumo en mas o menos 0,5 W por thread, lo que abre una importante ventana en el
tema de reproducir este hardware sin el lastre que representa la placa de entrenamiento
y los componentes que no tienen ningún uso o sentido en HPC.
7.6.
Comparación con el clúster teórico
En el capı́tulo de diseño de un clúster teórico, con el que participar en el SCC
siguiendo un modelo basado en el estado actual de los clústers, se concluye que obtendrı́amos un clúster de 14,64 TFLOPS en pico con 4.866,4 W.
A pesar de que en el concurso no podrı́amos superar los 3.000 W usaremos las cifras
pico para mayor comodidad y tomar el número mı́nimo de suposiciones. De esta manera
la eficiencia por vatio del clúster entero diseñado serı́a de unos 3,01 GFLOPS/W.
El mayor rendimiento que se ha podido observar en todo el clúster de ARM es aproximadamente 14,38 GFLOPS, esto indica una clara tendencia, que existe un gran problema
en la red de interconexión, pues la escalabilidad en un único nodo es bastante buena,
y llega a los 4,36 GFLOPS con 1 nodo,tan solo se triplica, en el mejor de los casos, al
usar 6.
Frente a nuestro pico real, que era de 38,4 GFLOPS, esto nos da una eficiencia del
clúster de 37 %, bastante baja viendo que por separado los nodos dan hasta un 80 %.
Tal vez el hecho de tener una memoria demasiado pequeña, provoca muchos intercambios y pasos de mensajes, y a su vez, al ser a través de una red de baja velocidad
incrementan la perdida de rendimiento en gran medida.
71
CAPÍTULO 7. EVALUACIÓN DEL CLÚSTER
Si nos abstraemos de los datos pico y haciendo la estimación correspondiente por la
parte del clúster teórico. Frente a éste último en caso de tener un clúster de únicamente 6 nodos, por un lado nos situamos frente a una reducción de más de 730 veces su
rendimiento, y por otro lado en más de 775 veces menos consumo y 75 veces un precio
menor. Sin duda es un trade-off que tiene su problema al escalar la complejidad del
clúster.
Si intentamos escalar nuestro clúster, asemejándolo al teórico y llenándolo de nodos, a
7,5 W por nodo y 2,8 W por puerto Ethernet, dentro del limite de los 3.000 W podemos
incrustar 291 nodos, que con la misma eficiencia que el clúster (37 %) nos darı́an un
rendimiento de 689,08 GFLOPS. Sin embargo, si pudiésemos obtener eficiencias semejantes a las de 1 nodo, nos situarı́amos en 1.508,54 GFLOPS, sobrepasando el TFLOP,
cosa que empieza a proporcionar ordenes de magnitud similares a los clústers del SCC
y subraya la necesidad de producir un hardware completamente activo y funcional y
con una red de interconexión más adecuada.
72
Capı́tulo 8
Conclusiones Propias
8.1.
Que le hace falta al hardware para ganar
Sin ninguna duda, un clúster de éste tipo no hubiera podido competir con opciones
en una posible candidatura al SCC. No obstante, no deja de ser hardware de entrenamiento y con ciertos ajustes, se podrı́a conseguir un buen hardware innovador para
participar en este concurso.
Uno de los principales problemas para alcanzar buenos rendimientos, se halla en la
memoria, al ser un System on a Chip no podemos escalar su capacidad ni ampliarla, de
manera que el chip debe diseñarse con un tamaño de memoria fijo, que actualmente, es
escaso, pues con 2 GB por nodo no podemos ejecutar cargas de trabajo muy grandes,
en comparación con los clústers actuales. Otro problema es la velocidad de ésta, que
se sitúa en 933 MHz, esto implica una memoria que es el doble de lenta que las más
actuales, que llegan ya a 1833 MHz.
La red de interconexión es otro motivo, por el cual la escalabilidad de nuestro clúster
ha sido muy limitada, solo 100 Mbps contra los 56 Gbps de los que se puede disponer
con una red InfiniBand y sus bajas latencias, añaden una gran desventaja a nuestro
hardware por no mencionar el hecho de compartir las entradas entre Ethernet y USB
a través de un HUB.
El hardware de computo necesita de un soporte adecuado, para poder hacer máximo uso de él, pues tiene una gran ventaja en la eficiencia. Tal vez el acelerador Mali
requiera un desarrollo más avanzado, si se contrasta con los actuales que ofrecen hasta
13 veces más rendimiento.
8.2.
Propuestas de continuidad
La temática del trabajo es extensa pero el tiempo ha sido limitado, esto permite
crear muchos temas posibles sobre los cuales ampliar y seguir la investigación de este
trabajo, especialmente en aquellos puntos donde una investigación profunda hubiera
llevado demasiado tiempo en resolver.
Muchas de las incógnitas sobre las cuales seguir trabajando están relacionadas sobre
73
CAPÍTULO 8. CONCLUSIONES PROPIAS
poder desbloquear elementos del hardware que hubieran podido sacar máximo partido a los dispositivos. Conseguir compilar un kernel que diera soporte para activar los
8 núcleos al mismo tiempo hubiera dado una gran ventaja en rendimiento al clúster,
ası́ como también poder desbloquear la baja frecuencia de 800 MHz a la que funciona
el procesador. Ésto hubiera derivado a la necesidad de diseñar un sistema eficiente de
refrigeración.
La optimización general del clúster también puede ser un tema ampliable, por ejemplo,
en la vertiente más hardware, unificar los transformadores para alimentar las placas
usando una única fuente de alimentación, puede ser una manera de mejorar la eficiencia evitando perdidas en el consumo de tantos transformadores.
Combinar el clúster con otro tipo de arquitecturas o elementos hardware que ayuden en la computación de forma eficiente puede ser una buena ampliación debido a su
relación con todo el tema de HPC.
8.3.
Conclusiones
Finalmente podemos concluir que en primera instancia se han cumplido los objetivos
marcados al inicio del proyecto. Se han estudiado los componentes hardware más usados
en HPC actualmente y se ha realizado una simulación del diseño de un clúster para el
SCC. También se ha conseguido la construcción de un clúster real, con tecnologı́a de
bajo consumo, y se ha logrado su puesta en marcha y configuración junto con su análisis.
La idea de usar este tipo de hardware para dar una vuelta de tuerca al mundo de
HPC puede tener sentido en unos años si se desarrolla mejor este tipo de planteamiento
tecnológico. Con una mayor eficiencia energética se pueden lograr resultados similares
a los actuales pero a un coste menor, y reduciendo en gran medida la huella ecológica
del sector. Esto tendrı́a un impacto muy positivo tanto de manera ecológica como social.
Sin embargo, habrá que estar atento al lı́mite del silicio como material de fabricación
para procesadores, dado que la era del silicio se acaba, habrá que ver que estrategia
adopta el mundo de HPC y como se adapta a una nueva época tecnológica y a los
nuevos desafı́os de eficiencia.
74
Capı́tulo 9
Conclusiones de equipo
9.1.
Conclusiones de cara a la competición
En el estado actual de nuestro proyecto resulta inviable participar en la competición por varios motivos.
No reboot - Always Up. La normativa de la competición establece que las máquinas
no se pueden reiniciar ni apagar durante toda la competición (excepto por motivos de
seguridad). Nuestro sistema es todavı́a inestable, hasta el punto que resulta improbable sobrevivir cinco dı́as sin reiniciar o que alguno de los nodos falle, de hecho serı́a
improbable aguantar uno. Además se prevé tener que instalar nuevo software e incluso
alguna librerı́a dado que hay un set de aplicaciones a ejecutar que se darán a conocer
durante la competición. Sin duda, este serı́a un objetivo prioritario y una manera de
abordar este problema serı́a abandonar el uso de tarjetas SD hacı́a un sistema de inicio
y ficheros en red mediante NFS.
Rendimiento. El rendimiento no es bueno, al menos no suficiente. En ediciones pasadas de la competición se alcanzaron los 8,5 TFLOPS en High Performance Linpack que,
en el peor caso, suponen 2,8 GFLOPS/W, 12 veces más que nuestros 0,229 GFLOPS/W
actuales. No serı́a realista esperar asistir por primera vez con una máquina preparada
para competir por los primeros puestos, pero si que podamos competir por no quedar
últimos. Consideramos que una primera meta serı́a desarrollar un prototipo con unas
previsiones de rendimiento mı́nimas de 6 TFLOPS en HPL para plantear seriamente el
asistir.
Preparación. tanto de los componentes del equipo como del clúster. Aún teniendo
la formación adecuada, tomar decisiones de diseño, montar una máquina y prepararla a nivel de software de sistema y aplicaciones requiere mucho tiempo. Contar que
además el equipo deberı́a ser de seis personas, por un lado agiliza el desarrollo pero por
otro lado requiere mayor nivel de coordinación. Además entendemos que, para formar
un equipo estable, se requerirı́a una persona vinculada a la FIB con conocimiento de
primera mano del estado del arte HPC. Asumirı́a el rol de director equipo y además
de coordinar deberı́a garantizar la continuidad de la representación de la facultad en
sucesivas ediciones.
Recursos. Este proyecto ha podido llevarse a cabo únicamente con recursos cedidos
75
por el departamento de AC y por el BSC. Creemos que el desarrollo de un prototipo
competitivo a pequeña escala podrı́a hacerse con un coste no mucho mayor, pero en el
caso de asistir a la competición, harı́a falta un desembolso de dinero considerable. Es
en este punto en el que entran en juego los sponsors. Todos los equipos que asisten a
la competición están esponsorizados por grandes fabricantes de hardware que aprovechan la competición a modo de escaparate. Nuestro plan serı́a conseguir uno o varios
sponsors que financiaran como mı́nimo, el coste total de los componentes del clúster y
el desplazamiento y alojamiento durante el evento.
9.2.
Trabajo futuro
Este trabajo, pese a demostrar no estar preparados para la competición, ha servido
para sentar las bases a partir de las cuales poder seguir trabajando y mejorar los puntos
débiles de nuestro prototipo.
De cara al futuro, la primera acción a realizar serı́a valorar todas las opciones y decidir si continuamos desarrollando un clúster basado en tecnologı́a móvil, si se decide
abandonar en favor de tecnologı́a HPC más habitual (p.ej: Intel Xeon y aceleradores
Nvidia) o valorar otras opciones menos estudiadas y no mencionadas como por ejemplo:
procesadores móviles con aceleradores externos Nvidia.
Personalmente creemos que en el ámbito de procesadores móviles queda mucho trabajo por hacer y que lo mejor está por venir. En esta lı́nea, por tanto, tenemos mucho
trabajo futuro sobre la mesa. A corto plazo empezarı́amos por abordar el problema
de la red de interconexión de nodos, y a la vez, tratarı́amos de hacer un mejor uso
del hardware disponible: aceleradores, ocho núcleos y máxima frecuencia de procesador
entre otros. A medio plazo se buscarı́a obtener nuevas placas de desarrollo con arquitectura ARMv8 de 64-bits y profundizar en el análisis y optimización profunda de las
aplicaciones.
Agradecimientos
Para finalizar este proyecto solo falta agradecer a todas aquellas personas que han
hecho capaz que este proyecto terminara en buen puerto.
A Álex Ramı́rez, por proporcionarnos tal oportunidad, darnos los recursos necesarios,
la confianza y las directrices que han permitido realizar gran parte de nuestro análisis.
A Nikola Rajovic, por el trato tan cordial y proporcionarnos la información y el material para usar el Yokogawa y los benchmarks de Montblanc.
A Josep Llosa Espuny, mi director de proyecto, por proporcionar el soporte y directrices
necesarias para realizar el proyecto.
A nuestro compañero de grado Oriol por habernos hechado una mano en ciertos puntos
del trabajo.
A mis compañeros de proyecto, Cristobal y Constan por hacer tan fácil la organización y coordinación de este proyecto, y realizar un buen trabajo.
Y finalmente a mis padres, por ser el apoyo que me permite llegar tan lejos en mi
educación y como persona.
77
Bibliografı́a
[1]
HPC Advisory Council. International Supercomputing Conference - Student Cluster Competition. 2014. url: http://www.hpcadvisorycouncil.com/events/
2014/isc14-student-cluster-competition/index.php (visitado 16-04-2014).
[2]
Douglas Eadline. High Performance Computing for Dummies. Estados Unidos
de América: Wiley Publishing, Inc, 2009. isbn: 978-0-470-49008-2. url: http:
//hpc.fs.uni-lj.si/sites/default/files/HPC_for_dummies.pdf.
[3]
Hans Meuer y col. Top500 List Statistics. 2013. url: http://www.top500.org/
statistics/list/ (visitado 24-03-2014).
[4]
Álex Ramı́rez. Computación de Altas Prestaciones. Sin miedo, es más fácil de lo
que parece. 2011. url: http://www.bsc.es/sites/default/files/public/
mare_nostrum/hpc-events/4966.pdf (visitado 27-04-2014).
[5]
PCMag, ed. Hihg-Performance Buses and Interconnects (8 de nov. de 2001).
url: http://www.pcmag.com/article2/0, 2817, 1154809, 00.asp (visitado
08-05-2014).
[6]
Gene Risi y Philip Bender. Understanding InfiniBand. 2002. url: http://ftp.
dell.com/app/4q02-Inf.pdf (visitado 08-05-2014).
[7]
Wikipedia. InfiniBand. 2014. url: http://en.wikipedia.org/wiki/Infiniband.
[8]
Erich Strohmaier. Top 500 Press Release. China’s Tianhe-2 Supercomputer Maintains Top Spot on 42nd TOP500 List. 18 de nov. de 2013. url: http://s.top500.
org/static/lists/2013/11/PressRelease201311.pdf (visitado 04-03-2014).
[9]
R Xeon PhiTM Coprocessor - the ArchiIntel Corporation George Chrysos. Intel
TM
R Xeon Phi
tecture. Intel
Coprocessor - the Architecture. 2012. url: https:
//software.intel.com/en- us/articles/intel- xeon- phi- coprocessorcodename-knights-corner (visitado 21-04-2014).
[10]
Intel Corporation. Intel Xeon Phi Product Family Brief. 2013. url: http : / /
www . intel . com / content / dam / www / public / us / en / documents / product briefs / high - performance - xeon - phi - coprocessor - brief . pdf (visitado
05-04-2014).
[11]
Intel Corporation. Intel Xeon Phi Coprocessors list. 2014. url: http : / / ark .
intel . com / products / family / 71840 / Intel - Xeon - Phi - Coprocessors #
@Server (visitado 15-04-2014).
[12]
Amazon. Precio referencia Nvidia Tesla K40. 2014. url: http://www.amazon.
com/NVIDIA- 900- 22081- 0040- 000- Tesla- K40- Computing/dp/B00GPAWTE4
(visitado 02-06-2014).
[13]
Amazon. Página de compra de Tesla K20x. 2014. url: http://www.amazon.
com/Tesla-K20X-Graphic-Card-Express/dp/B00AM0FD00.
78
BIBLIOGRAFÍA
[14]
Amazon. Página de compra de Tesla K20. 2014. url: http://www.amazon.com/
NVIDIA-Tesla-K20-Accelerator-900-22081-2220-000/dp/B00AA2C1DC.
[15]
Nvidia Corporation. Nvidia Tesla GPU accelerators. 2013. url: http://www.
nvidia.com/content/PDF/kepler/Tesla-KSeries-Overview-LR.pdf (visitado 14-05-2014).
[16]
Dan Olds. ISC’13 Configurations Revealed: Kepler vs. Phi Face-Off. 2013. url:
http://www.studentclustercomp.com/isc13- configurations- revealedkepler-vs-phi-face-off/ (visitado 25-04-2014).
[17]
Dan Olds. ISC’12 System Configurations. 2012. url: http://www.studentclustercomp.
com/isc12-system-configurations/ (visitado 25-04-2014).
[18]
Dan Olds. ISC’13 Results Sliced, Diced, and Pulverized: Who won and why? 2013.
url: http://www.studentclustercomp.com/isc13-results-sliced-dicedand-pulverized-who-won-and-why/ (visitado 25-04-2014).
[19]
Administrador. Results from the ISC’13 Student Cluster Challenge in Leipzig.
2013. url: http://www.studentclustercomp.com/isc13-honor-roll/ (visitado 28-04-2014).
[20]
Intel. Comparativa procesadores Intel. 2014. url: http : / / ark . intel . com /
compare/64584,64595,64590,64583,75264,76350,75289,75286.
[21]
Mellanox. SX6005 Overview. 2014. url: http://www.mellanox.com/relateddocs/prod_ib_switch_systems/PB_SX6005.pdf.
[22]
Supermicro. 2014. Especificaciones tarjeta InfiniBand. url: http://www.supermicro.
nl/products/accessories/addon/AOC-UIBF-m1.cfm.
[23]
Supermicro. Especificaiones placa base. 2014. url: http://www.supermicro.nl/
products/motherboard/Xeon/C600/X9QRi-F_.cfm (visitado 25-05-2014).
[24]
Supermicro. Especificaciones placa base. 2014. url: http://www.supermicro.
com/manuals/motherboard/C606_602/MNL-1324.pdf (visitado 06-06-2014).
[25]
Amazon. Página de compra de la memoria. 2014. url: http://www.amazon.
com/Supermicro- Certified- MEM- DR316L- SL02- ER18- Samsung- Memory/dp/
B00G3YFZLQ.
[26]
Amazon. Página de compra de la placa base. 2014. url: http://www.amazon.
com/Supermicro-X9QRI-F-Motherboard/dp/B00B2W81LK.
[27]
Amazon. Página de compra de tarjeta InfiniBand. 2014. url: http : / / www .
amazon.com/Supermicro-AOC-UIBF-M1-Compact-Powerful-InfiniBand/dp/
B00GX3IMR6.
[28]
Amazon. Página de compra del almcenamiento. 2014. url: http://www.amazon.
com/S3700-Internal- Solid-State-Drive/dp/B00APLB6G6/ref=sr_1_4?s=
electronics&ie=UTF8&qid=1402222234&sr=1- 4&keywords=Intel+SSD+DC+
S3700.
[29]
NewEGG. Página de compra de la fuente de alimentación. 2014. url: http :
//www.newegg.com/Product/Product.aspx?Item=N82E16817338073.
[30]
Amazon. Página de compra de los cables. 2014. url: http://www.amazon.com/
Mellanox-Technologies-Passive-Copper-Cables/dp/B008GVRAXK.
[31]
Amazon. Página de compra del switch. 2014. url: http://www.amazon.com/
Mellanox-InfiniBand-SX6005-unmanaged-rack-mountable/dp/B00KOHNWJK.
79
BIBLIOGRAFÍA
[32]
PCimagine. Página de compra de ventilador. 2014. url: http://store.pcimagine.
com/ventilador-de-chasis-de-220-vac-y-120x120x38-mm-con-cable-p69191.html.
[33]
RackMount. Página de compra de los chases. 2014. url: http://www.rackmountsolutions.
net/Rackmount_Shelves_4_Point.asp#848.
[34]
HiperRack. Página de compra del rack. 2014. url: http : / / hiperrack . com /
Bastidor-rack/Bastidor-rack-doble-19/Bandeja-abierta-19-de-suelo-600x600--negro---32-U-PHP-7032.
[35]
Comunidad ARM. Blog sobre las tarjetas Mali. 2014. url: http://community.
arm.com/groups/arm-mali-graphics/blog.
[36]
Wikipedia. Página Wikipedia sobre los chips Exynos. 2014. url: http : / / en .
wikipedia.org/wiki/Exynos.
[37]
Constantino Gómez. Diseño de un Cluster HPC: Aplicaciones. UPC - FIB, 2014.
80