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