Anexo I PPT.pdf - Ampliación del cluster HPC (High Perfor…

## ANEXO I PRESCRIPCIONES TÉCNICAS ## I.1. REQUISITOS FUNCIONALES DE LOS SUMINISTROS Este pliego técnico describe la ampliación del clúster HPC (High Performance Computing) Nord4 (basado en el hardware de MareNostrum4) para proveerle de capacidades de nodos con GPUs. Los departamentos científicos del BSC-CNS requieren la ejecución de simulaciones relacionadas con Large Language Models (LLMs) y otras ejecuciones que requieren del uso de GPUs. Esta infraestructura servirá para definir un piloto de Trusted Research Environment (TRE) para el BSC-CNS. El objetivo no es alcanzar un despliegue de producción completo sino establecer gobernanza, políticas y procesos, incluyendo la generación de documentación de alto estándar ajustada a los perfiles diferentes identificados, para establecer, mantener y modificar un TRE (Trusted Research Environment) en BSC-CNS a lo largo del tiempo. El proyecto incluye la prueba de procesos fundamentales como la ingestión de datos, el control de acceso y la vigilancia de seguridad; brindando ejemplos de prueba de concepto, por ejemplo, capacitar un modelo pequeño con datos sintéticos o de muestra; y validando la conformidad con la Regulación General sobre Protección de Datos (GDPR), la Ley del Mercado Único de Inteligencia Artificial y las políticas de seguridad de BSC-CNS. Además, el proyecto también garantizará la alineación con la Ley de Gobierno de los Datos de la Unión Europea, ya que establece requisitos para definir Entornos de Procesamiento Seguro (EPS), que luego son tomados por otras regulaciones como el Espacio de Datos de Salud Europeo (ESDS). El piloto buscará alineamiento técnico con la EuroHPC JU para coincidir los esfuerzos de este piloto con la red de supercomputación europea. Una vez terminado el piloto, se escalarán los marcos validados a nivel de producción completa y se mantendrán en el contexto de las operaciones de BSC-CNS. Para llevar a cabo dichas tareas de investigación se requiere la adquisición de los siguientes elementos: - -Clúster de cómputo - o Nodos de cómputo con GPUs que usen de forma nativa CUDA para la compatibilidad con los casos de usos actuales del centro de MareNostrum4 y 5 - -Elementos de administración - o Servidores de administración del clúster - -Elementos de red - o Switches para conectar los diversos elementos nuevos con el clúster actual, en concreto debería tener 3 redes físicas disjuntas: - Red de administración basada en ethernet - Red de alto rendimiento Ethernet basada en 25/100 Gb - Red de alto rendimiento basada en tecnología Infiniband NDR 400 Gbit que soporte RDMA de forma nativa a nivel de protocolo Toda la infraestructura deberá ser entregada 'llave en mano' tal como describe este pliego y con un mantenimiento mínimo incluido de 3 años, que corresponde con la vida útil estimada del mismo. El hardware entregado deberá ser nuevo y no se aceptará hardware reparado o usado previamente.     ## 1.- Hardware A continuación, pasamos a describir en detalle los requerimientos mínimos sobre el hardware que se demanda para la ampliación GPUs para nord4. ## 1.1.- Hardware Clúster cómputo y Servidores de administración | Ref | Descripción | |-------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R1 | Cluster con varios nodos de cómputo con las siguientes características cada uno: - 2 CPUs/Sockets por servidor de plataforma x86_64 - Cada CPU debería tener un mínimo de 48 cores (sin HyperThreading) a 2,5 GHz - 8 GPUs de la última generación disponible con la capacidad nativa de CUDA, cada GPU deberá tener un mínimo de 96 GB de memoria por GPU, y debe soportar la partición virtual de la GPU - Mínimo 2 TB RAM DDR5 - 8x NVME 3TB para datos locales - 2x NVME 960GB para Sistema operativo - Controladora RAID hardware para configurar RAID0,1,5,6 con los dispositivos NVME locales - 2x conexión 25Gb Ethernet - Varias tarjetas Infiniband NDR que permitan computaciones GPU-Direct | | R2 | Los nodos de cómputo aportados con sus GPUs deben tener una capacidad teórica mínima de 120 Petaflops en FP4. | | R5 | Todos los nodos de cómputo y login deberán cumplir los siguientes requisitos: - La configuración de memoria presentada deberá ser equilibrada desde/hacia todos los cores de un mismo socket a la memoria (DIMMs misma velocidad y tamaño) y la frecuencia de acceso a memoria deberá ser la más alta que la familia de los procesadores ofertados permita. - Los buses que interconectan los sockets de un nodo deberán ser equilibrados y tener el máximo ancho de banda que la familia de los procesadores ofertados permita, la cantidad de estos buses será evaluado. - Deberá de ofrecer los buses PCI Express independientes suficientes para poder soportar las conexiones a las diversas redes que se describen anteriormente, sin ser ningún factor limitante | | R6 | En caso de que los nodos estén empaquetados en un chasis: - La interfaz de gestión out-of-line podrá ser compartida por todos los nodos del chasis | | R7 | Se requiere un esquema de bloques de los nodos de cómputo ofertados con los anchos de banda entre los diferentes componentes de un nodo (máximo y útiles expresados |       | | en GB/s): procesadores, memoria, diversos buses PCI-Express, cualquier componente I/O, GPUs, etc. | |-----|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R8 | El siguiente conjunto mínimo de servidores/hardware se deberá proporcionar como servidores de administración, configurados con las características técnicas de acorde a las responsabilidades y servicios que van a proveer: • Almacenamiento administrativo: Almacenamiento para almacenar los datos como las imágenes de sistema operativo, configuración, datos de monitorización, base de datos clúster, registros del sistema, etc. Este espacio se puede implementar con el almacenamiento local de los servidores de clustering o un almacenamiento dedicado. • Servidores clustering: Servidores encargados de la gestión del clúster a nivel de instalación y servicios de clustering. También dispondrá de la gestión de rutas de la red Infiniband. | | R9 | Todos los servidores de administración no deberán tener un único punto de fallo (hardware o software) y deberán estar configurados en alta disponibilidad (activo- activo) o (activo-pasivo) los servicios que gestionen. | | R10 | Un elemento de Teclado-Mouse-Video deberá ser instalado en el rack de gestión que permita acceder a la consola de todos los servidores de administración. O en caso de no incluirlo se deberá de conectar al switch de consolas existente de nord4 para poder acceder a la consola de los servidores de administración desde el actual. | | R12 | Los nodos de cómputo y servidores de gestión deben proveer un Sistema out-of-band de gestión, incluyendo las siguientes características: • Power on/off/reset • Consola remota • Monitorización de ambiente (Temperatura, consumo eléctrico) • Generación de alarmas y exposición de resolución de problemas de cualquier problema hardware/firmware • Estado general y led de notificación en caso de problemas • Informe de inventario de todos los componentes hardware que componen el nodo de cómputo y sus números de seria • Reinicio remoto del Sistema de gestión fuera de línea (out-of-band) • Desconexión y reconexión virtual del nodo de cómputo en caso de estar integrado en un chasis • Registro de eventos Los firmwares de los nodos de cómputo deben proveer funcionalidades de RAS (Reliability, Availability and Serviceability) Fiabilidad, disponibilidad y facilidad de servicio. Debe registrar cualquier fallo recuperable o no recuperable (especialmente los relacionados con las memorias). Si cierto nivel de errores recuperables es alcanzado, una alerta deberá ser generada indicando el componente que debe ser sustituido antes que un fallo no recuperable ocurra. |     | R13 | Se requiere que se rellene las tablas (Tabla 1- Descripción clúster computo hardware) y (Tabla 2 - Servidores de administración), en ella se especifican los valores mínimos a cumplir, y se deberá indicar los valores ofertados por nodos de cómputo y por cada tipo de servidor de administración. | |-------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R14 | Se deberá de prever de un login nodo con las siguientes características: - 1 CPUs/Sockets por servidor de plataforma x86_64 - Cada CPU debería tener un mínimo de 16 cores (sin HyperThreading) a 2 GHz - 1 GPUs de última generación de la misma familia que las ofertadas en los nodos de cómputo con capacidad nativa de CUDA - Mínimo 256 GB GB RAM DDR5 - 2x NVME 960GB para Sistema operativo - Controladora RAID hardware para configurar RAID0,1 con los dispositivos NVME locales - 4x conexión 25Gb Ethernet - 1x Tarjeta Infiniband NDR | Tabla1 - Descripción hardware Cluster Cómputo (estas tablas están en un documento a parte) | Concepto | Valor mínimo | Valor ofertado | |--------------------------------------------------|-----------------------------|-----------------------------| | Descripción Nodo de cómputo | Descripción Nodo de cómputo | Descripción Nodo de cómputo | | Número chips o sockets por nodo | 2 | | | Modelo procesador | | | | Ancho de banda (GB/s) entre procesadores | | | | Cores por procesador ofertado | 48 | | | Frecuencia nominal de cada core | 2,5 | | | Frecuencia turboboost de cada core | | | | Frecuencia (modo vectorial) de cada core | | | | FLOPs pico por ciclo de cada core del procesador | | | | Número de GPUs | 8 | | | Modelo GPU | | | | Memoria por GPU | 96 GB | | | Tipo Memoria GPU | | | | GFLOP pico por procesador | | | | TFLOP pico por GPU | | | | TFLOP pico por nodo | | | | TFLOP ejecución Linpack HPL FP64 por nodo | | | | Consumo eléctrico ejecutando linpack por nodo | | | | Tecnología y frecuencia memoria RAM | | | | Frecuencia real funcionamiento memoria | | | | Memoria RAM por core ofertada | 21 GB | | | Memoria RAM ofrecida por nodo | 2 TB | | | Interfaces 25-100 GE incorporadas por nodo | 1 | | | Número de interfaces red baja latencia (IB) | | | | Tecnología interfaces red baja latencia (IB) | NDR | | | Ancho banda a red de baja latencia (IB) | | |     | Capacidad almacenamiento local para datos | 8x 3.2 TB | |-------------------------------------------------|-------------| | Capacidad almacenamiento local para SO | 2x 960 GB | | Tecnología almacenamiento local para SO y datos | NVME | Tabla2 - Descripción hardware por Servidor de gestión (estas tablas están en un documento a parte) | Concepto | Valor mínimo | Valor ofertado | |---------------------------------------------------------------------|---------------------------------------|---------------------------------------| | Características servidores de gestión | Características servidores de gestión | Características servidores de gestión | | Tipo de servidor de administración | | | | Número chips o sockets por nodo | | | | Modelo procesador | | | | Ancho de banda (GB/s) entre procesadores | | | | Cores por procesador ofertado | | | | Frecuencia nominal de cada core | | | | Frecuencia turboboost de cada core | | | | Frecuencia (modo vectorial) de cada core | | | | FLOPs pico por ciclo de cada core del procesador | | | | Tecnología y frecuencia memoria RAM | | | | Frecuencia real funcionamiento memoria | | | | Memoria RAM por core ofertada | | | | Memoria RAM ofrecida por nodo | | | | Interfaces 25-100 GE incorporadas por nodo | | | | Número de interfaces red baja latencia (IB) | | | | Tecnología interfaces red baja latencia (IB) | NDR | | | Ancho banda a red de baja latencia (IB) | | | | Capacidad almacenamiento local para SO | | | | Tecnología almacenamiento local para SO | NVME | | | Almacenamiento interno por servidor (# discos, tamaño y tecnología) | NVME | | | Controladora RAID | RAID1HW | | | Interfaces 1 Gbit Ethernet por servidor | | | | Interfaces 25 Gbit Ethernet por servidor | | | | Interfaces Infiniband por servidor | 1 | |    ## 1.2.- Switches y redes Todos los nodos de cómputo y login estarán conectados a través de 3 redes, con lo que se deberá proveer de todos los elementos para su formación: - -Red del clúster : Red basada en tecnología 25-100 Gbit Ethernet visible entre los nodos del clúster que permitirá el tráfico de los diversos servicios del clúster (NTP, DNS, tráfico filesystem paralelo, sistema de colas, etc.). - -Red gestión privada : Conectando todos los elementos de gestión del clúster y sólo accesible por los administradores de la infraestructura, basada en 1 Gbit Ethernet. Esta red se puede implementar físicamente en la misma fabric que la red del clúster. - -Red de baja latencia y alto rendimiento : Red con un ancho de banda de 400Gb que pueda soportar IB y se pueda configurar IPoIB, que será usado por las aplicaciones MPI (entre nodos de cómputo). Las redes del clúster y red de gestión privada se deberán integrar con las redes del mismo nombre que dispone actualmente el clúster nord4. A continuación, se detallan los requisitos comunes para todas las redes del clúster de cómputo del clúster y en las consiguientes tablas los requisitos específicos para cada una de las redes.      | Ref | Descripción | |-------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R1 | Todo switch instalable en rack de cualquier red del clúster, excepto los que provean 1 Gigabit Ethernet, deben tener N+N fuentes de alimentación y ventiladores intercambiables en caliente. Los cables que representen la misma red deberán usar siempre el mismo color, siempre que sea posible para diferenciarlos físicamente. | | R2 | Para cada red, debe existir un mínimo de 4% de puertos libres en cada nivel a excepción del nivel más bajo de la jerarquía | | R3 | Todos los switches que no sean del nivel más bajo de la jerarquía de una red deben ser redundantes, evitando un único punto de fallo. | | R4 | Todos los puertos de la misma velocidad de un switch deben ser line-rate sin ningún tipo de sobre subscripción. | | R5 | Todos los switches Ethernet propuestos, excepto los del nivel másbajo, deben soportar: • Jumbo Frames, Line-Rate L2 Switching, Spanning-Tree (MSTP & RSTP) • Filtering BPDUat physical port level, port mirroring, QoS, SNMP, SSH, Min. 256 VLANs • LACP (L3+L4), Flow control, más de 10K MACs en la tabla de forwarding, 802.1q, MC-LAG o VLT Todos los puertos deben estar licenciados y listos para ser usados | | R6 | El licitador debe de entregar: • Descripción física de la red (Mapa físico y topología) • Implementación a nivel lógico (VLANs) (y routing si fuera necesario) • Información sobre los valores claves de rendimiento y características técnicas de los switches propuestos Número y tipo de cables/fibras conectando cada rack de la solución. | A continuación, se describen los requisitos y deseables para cada una de las redes del clúster licitado. | Ref | Descripción | |-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Red cluster | Red cluster | | R7 | Se deberá proveer del hardware necesario (switches, cables, etc.) para poder establecer la red interna del clúster con tecnología 25-100 Gigabit Ethernet. | | R8 | En esta red física se configurarán un mínimo de 2 dominios de broadcast diferentes (2 VLANs): - 1 VLAN => Red Interna cluster (DHCP,Boot, …) - 1 VLAN => Red de datos de acceso al almacenamiento de MN5 |     | Ref | Descripción | |-------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R9 | En esta red física se conectará: - Cada nodo de cómputo - Servidores de administración/login - Los enlaces externos del nodo de login, y el enlace externo del servidor de administración - Uplinks hacia switches actuales nord4 | | R10 | El switch principal del clúster deberá estar conectado mediante 4 enlaces de 100Gb con el switch central de nord4 (Dell Z9264F-ON) mediante conectores LC monomodo. Se deberán de proporcionar los GBICs en ambos extremos como las fibras LC-LC. | | Red gestión privada | Red gestión privada | | R13 | Se deberá proveer del hardware necesario (switches, cables, etc.) para poder establecer la red para la gestión de todos los componentes hardware que componen el clúster de cómputo basado en tecnología Gigabit Ethernet. | | R14 | En esta red física se configurará 1 dominio de broadcast (1 VLANs), a conectar: - Red de gestión privada clúster - Red de gestión privada switches Infiniband | | R15 | En esta red física se conectará: - Cualquier interfaz de gestión de cualquiera de los componentes del clúster (racks, IPMI servers, puertas frías, PDU, switches, etc.) - Interfaz de gestión out-of-line de los nodos de cómputo y logins - Interfaz de gestión out-of-line de cualquier servidor de gestión - Interfaz de gestión switches Ethernet y Infiniband | | Red Interconexión MPI / Red datos bulk-transfer | Red Interconexión MPI / Red datos bulk-transfer | | R16 | Se deberá proveer del hardware necesario (switches, cables, etc., su esquema y etiquetado) para poder establecer la red interna de alto rendimiento y muy baja latencia sobre la cual se va enviar: - Comunicaciones MPI Esta red deberá ofrecer un mínimo de links de 400 Gb y soportar RDMA nativamente en su propio protocolo como Infiniband o equivalente. | | R17 | Todos los nodos de cómputo, nodos de administración y logins deberán estar conectados a esta red de interconexión, como los servidores de gestión que se encargue del routing y la monitorización de la red Infiniband. | | R18 | Dicha red será no bloqueante configurada en full-fat tree. | | R19 | Debe proveer de la capacidad de enviar paquetes IP. El bloque IP debe aportar un bajo coste a nivel de memoria y llevar un alto rendimiento para tamaños pequeños de datos (MTU 1.5K, 4K o 9K). | | R20 | Todos los switches de la red de baja latencia deberán poder ser gestionables desde la red ethernet gestión privada del clúster. |     Tabla 3 - Descripción hardware switches y redes (estas tablas están en un documento a parte) | Concepto | Valor mínimo | Valor ofertado | |------------------------------------|-----------------------------------|-----------------------------------| | Red cluster | Red cluster | Red cluster | | Número de switches proporcionados | | | | Marca switch | | | | Modelo switch | | | | Número de puertos 1GE por switch | | | | Número de puertos 25GE por switch | | | | Número de puertos 100GE por switch | | | | Número de puertos 200GE por switch | | | | Número de puertos libres | | | | Latencia introducida por el switch | | | | Red gestión | Red gestión | Red gestión | | Número de switches proporcionados | | | | Marca switch | | | | Modelo switch | | | | Número de puertos 1GE por switch | | | | Número de puertos 10GE por switch | | | | Número de puertos libres | | | | Latencia introducida por el switch | | | | Red Interconexión MPI / Red datos | Red Interconexión MPI / Red datos | Red Interconexión MPI / Red datos | | Número de switches proporcionados | | | | Marca switch | | | | Modelo switch | | | | Número de puertos por Switch | | | | Tecnología de conexión | | | | Ancho de banda por puerto | | | | Número de puertos libres | | | | Latencia introducida por el switch | | | ## 2.- Software En este apartado se describe el software a proporcionar en la ampliación de nord4. Todo software ofertado deberá recibir los parches de seguridad durante todo el periodo de mantenimiento del sistema. Donde aplique, el licitador deberá proveer las licencias de todo aquel software ofertada para la duración completa del mantenimiento y soporte descrito en este pliego. El licitador proveerá de una lista de las licencias que les aplica, cantidades y condiciones.    ## 2.1.- Sistema operativo | Ref | Descripción | |-------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R1 | El sistema operativo usado por todos los servidores del clúster debe estar basado en Linux. La distribución debe estar soportada por el hardware y el software propuesto. Para asegurar compatibilidad con cualquier hardware a integrar debe ser una distribución Enterprise. | | R2 | El sistema operativo de los nodos de cómputo, deben: • Estar especializado en la ejecución de trabajos con GPUs, si aplica, se deberá documentar en detalle de que difiere de una distribución standard de Linux. Deberá incluir funcionalidades avanzadas detraceo de rendimientoyconsumo eléctrico. • Soporte nativo para Performance Application Programming (PAPI) API • Soporte para ejecutar todo traceo y profiling de aplicaciones con la herramientas del BSC: https://www.bsc.es/discover- bsc/organisation/scientific-structure/performance-tools y https://tools.bsc.es/ Debe soportar la modificación del consumo eléctrico cambiando la frecuencia CPU/GPU o limitando el consumo máximo. Estas metodologías deben poder ser gestionados a través de la herramientas de control de consumo del BSC: https://www.bsc.es/research-and-development/software-and-apps/software- list/ear-energy-management-framework-hpc | | R3 | El sistema operativo propuesto debe soportar nativamente el uso de contenedores y máquinas virtuales (KVM). Tecnologías comunes de contenedores como docker, singularity o clústeres basados en kubernetes, deben estar soportados. | ## 2.2. Entorno de desarrollo y ejecución paralela | Ref | Descripción | |-------|-------------------------------------------------------------------------------------------------------------------------------| | R1 | Las implementaciones MPI y compiladores debe soportan versiones actuales de los estándares: | | | • MPI versión 3.0 o superior, • C ISO/IEC 9899:2011 o superior, • C++ ISO/IEC 14882:2014 o • Fortran ISO/IEC 1539-1:2010 (ej. | | | superior, | | | Fortran 2008) o superior, | | | • OpenMP 4.0 o superior |      | Ref | Descripción | |-------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | | Se deberá de proveer librería al menos de CUDA, OpenACC o OpenCL, e implementaciones de cuBLAS, cuFFT, etc. | | R2 | Librerías numéricas optimizadas: El licitador deberá proveer librerías numéricas altamente optimizadas, aportando un API compatible para rutinas BLAS, LAPACK y ScaLAPACK, y se debe incluir una librería optimizada de transformada de Fourier (FFT). | | R3 | Un debugger paralelo comercial se debe incluir que permita hacer análisis de aplicaciones paralelas corriendo en las GPUs. Debe estar licenciado con un mínimo de 128 procesos MPI. | | R4 | Las particiones de computo propuestas deben de poder usar los modos de programación y flujos de trabajo del BSC, como COMPSs y PyCOMPSs (https://www.bsc.es/research-and-development/software-and-apps/software- list/comp-superscalar), y GREASY, soportando la paralelización de ejecución de procesos secuenciales con dependencias simples (https://github.com/BSC-Support- Team/GREASY). | ## 3.2. Software de clustering En esta sección se describe los requisitos del software que será responsable de gestionar las configuraciones del clúster y las imágenes de sistema operativo. | Ref | Descripción | |-------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R1 | El candidato debe proveer de una solución software integrada para el manejo de todos los recursos del clúster, la instalación de todos los nodos y monitorización básica del hardware. El software debe ofrecer soporte a la gestión fuera de banda (out-of-band) de todo componente hardware y a la provisión de nodos. Una solución basada en xCAT el software de gestión de clústeres que usa BSC en el resto de clústeres es requerido. Se podrá delegar ciertas tareas de la gestión del clustering a otros softwares más adaptados o propietarios de las soluciones propuestas. Aun así, dichas delegaciones se minimizaran a favor del uso de xCAT como herramienta básica de gestión. | | R2 | Único manejo de la imagen de sistema operativo y su configuración para todos los nodos de cómputo que va a manejar. | | R3 | Debe soportar las siguientes metodologías de instalación: instalación en disco local (stateful), en memoria (stateless or diskless) e incluso nfs-root (statelite). Tiene que permitir la gestión uniforme independientemente de la forma de instalarse. | | R4 | Debe soportar una estructura jerárquica en el que exista unos nodos líderes o head nodes y luego varios servidores de servicio los cuales se encarguen de una porción |     | Ref | Descripción | |-------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R5 | headnode. Todos los servidores de servicio deben estar configurados en alta disponibilidad. Las siguientes funcionalidades se deben proveer a los nodos de computo: • Interacción con el sistema fuera de línea (out-of-band) de los nodos de | | R6 | Definición con reglas y expresiones regulares las diferentes configuraciones del clúster (DNS, IPs, aliases, etc.), autogeneración de los ficheros de configuración derivados de las definiciones realizadas. | | R7 | Toda operación a aplicar a todo el clúster debe ofrecer un comando a través de línea de comandos | | R8 | Los servidores de administración también debe ser instalados por el sistema de gestión del clúster propuesto. | ## 3.3. Sistema de colas La siguiente sección describe el sistema de colas a ser propuesto para el clúster GPUs para nord4. | Ref | Descripción | |-------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R1 | Un sistema de colas deberá ser proporcionado que se encargue del manejo de los Jobs de los usuarios, priorizándolos y realizando la contabilidad de horas de CPU/GPU usadas. |     | Ref | Descripción | |-------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R2 | La solución presentada debe estar basada en el sistema de colas de nord4 actual que está basado en Slurm | | R3 | El sistema de colas debe de proporcionar las siguientes funcionalidades: • Ejecución en paralelo del prólogo y epilogo y la instanciación de los procesos del usuario, siendo capaz de escalar a cientos o miles de cores por job • Configuración de prioridad basado en varios factores incluyendo políticas de 'fair-share'. Con la capacidad de definir varios niveles de árbol de 'fair-share' indicando las horas asignadas como los valores en el peso del árbol. • Definición de reservas, recurrentes y puntuales sin la necesidad de especificar los nodos. • Contabilidad de Jobs por tiempo, consumo eléctrico y energía • El sistema de colas debe de proveer de un mecanismo de plugins para extender sus funcionalidades. Por ejemplo, para integrarse con ElasticSearch o la instalación de EAR (Sistema de gestión de energía desarrollado en el BSC- CNS). • Asignación de recursos teniendo en cuenta la topología de las diversas redes existentes • Limitación de los recursos disponibles para cada job con límites y cgroups • Asignar GPUs como recursos consumibles, y tenerlos en cuenta a la hora de realizar la contabilidad de los Jobs • Establecer o cambiar la frecuencia de trabajo del procesador desde la definición del job • Contabilidad de energía por job Debe ser capaz de instanciar procesos MPI en todos los nodos del clúster en menos de diez segundos | | R4 | El sistema de colas debe soportar la ejecución de aplicaciones en contenedores, como puede ser Singularity. Debe disponer de interoperabilidad con clústeres de kubernetes. | | R5 | Integración con scripts que sean capaces de determinar la salud de cada nodo de cómputo y su predisposición para la ejecución de aplicaciones IA. El licitador debe facilitar aquellas herramientas y mecanismos para validar esa salud y validar la configuración hardware y software de los componentes sea completamente funcional. Donde se aplique, medidas de auto recuperación serás ejecutadas y apuntadas. | ## 3.4. Otro software | Ref | Descripción | |-------|--------------------------------------------------------------------------------| | R1 | Software para la monitorización debe ser entregado para las siguientes tareas: |     | Ref | Descripción | |-------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | | • Alertas de cualquier elemento administrativo (ej. Icinga/nagios) • Rendimiento de nodos de cómputo (ej. telegraf, influxdb, grafana) • Histórico de Jobs acabados (ej. ElasticSearch plugin + ElasticSearch + Kibana) • Monitorización de las redes Infiniband • Monitorización de los circuitos de refrigeración de agua DLC, como elementos adjuntos como CDUs La monitorización de los nuevos elementos se deberán de integrar en los servidores actuales de monitorización de nord4. | | R2 | Un sistema de ficheros paralelo basado en Storage Scale debe ser provisto para ser usado en todos los nodos de cómputo y login nodes, integrado con el resto de nodos del cluster actual de Nord4. | | R3 | Una solución software se debe de proveer para se encargue de la gestión de la gestión de rutas de las redes de alto rendimiento Infiniband, como la monitorización y gestión de cualquier otra tarea administrativa de dichas redes. La solución propuesta deberá estar soportada por el fabricante de la red Infiniband. La instalación deberá ser redundada en los servidores de administración para que no haya un único punto de fallo. | | R4 | La monitorización de rendimiento debe ser capaz de mostrar gráficamente la carga de las particiones de cómputo como una unidad e individualmente por nodo de cómputo. Un mínimo de grupo de métricas se debe proporcionar el cual deberá ser ampliado por el licitador en su propuesta: • CPU: carga, estado (user, idle, system, nice, wait), consumo, temperatura • GPU: carga, memoria usada, consumo, temperatura • Memoria: usado, cached, free, total • Red (cualquier interfaz): número de paquetes, bytes por segundo • Temperaturas de los diversos componentes Métricas específicas se deberán de configurar para diversos servicios, aquellas que sean relevantes, como ejemplo: • Sistema de colas: número de Jobs, en cada estado • Login nodes: Numero de sesiones interactivas Nodos cómputo y CDUs: Temperatura del agua DLC entrada, salida, y su presión | No serán admisibles en ningún caso soluciones de puesta a disposición de activos en la nube. Sólo estará permitida la conexión técnica a la nube de los equipos en los términos descritos en el apartado III.5 del PPT. Los licitadores se comprometen a que los equipos ofertados cumplen con las condiciones y límites definidos para este tipo de conexiones.   ## I.2. REQUISITOS NO FUNCIONALES DE LOS SUMINISTROS Los equipamientos suministrados deberán ser conformes con las previsiones recogidas en el apartado III.3 del PPT en materia de marcado CE y acreditación de los requisitos aplicables para su comercialización en la Unión Europea, así como el cumplimiento de la normativa española y europea que sea de aplicación a los mismos en relación a la comercialización de material eléctrico, compatibilidad electromagnética, seguridad de los productos, diseño ecológico, etc. El clúster se propone de instalar en el CPD del edificio TG en el sótano en una zona habilitada especialmente para su instalación, en la figura siguiente podría ocupar cualquiera de las dos posiciones indicadas con las letras RDHX. Nord4  El espacio destinado para la instalación de este clúster dispone de las siguientes características: - -2 posiciones de rack standard de 42U y 600mm de ancho - -Alimentaciones eléctricas con 4 líneas trifásicas de 32A sin SAI por cada rack | Ref | Descripción | |------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Requerimientos operacionales | Requerimientos operacionales | | R1 | El consumo total del clúster no podrá superar en ningún momento los 70 kW sin SAI con un PUE máximo de 1.08. El licitador deberá documentar el consumo eléctrico y como éste será mantenido por debajo del límite máximo antes indicado, ya sea por diseño hardware, o mediante algún componente software. | | R2 | Todos los racks deben de cumplir los siguientes requisitos: • Consumo máximo de 70 kW en pleno rendimiento • Conectores trifásicos redundantes y balanceados N+N (excepto por los racks de cómputo) |       | Ref | Descripción | |-------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | | • Todo elemento dentro de los racks deberá tener fuentes de alimentación redundantes N+N, los cuales deberán de poder trabajar perfectamente con la mitad de las PDUs funcionales (excepto los racks de cómputo) • La alimentación eléctrica se deberá realizar por las bandejas superiores • La conexión de datos será realizada por encima de los racks, usando las bandejas existentes. • Cada rack deberá tener sensor de temperatura y humedad, para cada circuito de agua de refrigeración (RDHX y DLC) deberá tener un sistema de purgado fácilmente accesible • Cada rack debe disipar un mínimo de 97% del calor generado • Las PDUs deberán ser monitorizables, con la posibilidad de parar cualquier conector remotamente. • La carga entre las diversas fases deberá ser mínima, dentro de cada rack y en conjunto con todos los racks de la misma partición • Un proceso de pruebas para evitar la muerte de hardware a la llegada se deberá de haber realizado en fábrica • Los racks se instalarán con puertas frontales y puerta trasera de refrigeración, ambas deberán poderse cerrar mediante llave • Los racks deberán llegar al BSC con todo el cableado intra-rack realizado y maximizar el número de componentes instalados en el rack. | | R4 | Los racks de cómputo (si hay más de uno) deben ser lo más idénticos posibles entre ellos a nivel de componentes (número de nodos, switches, cableado). | | R5 | Los racks de cómputo se refrigerarán por los circuitos de agua existentes (de temperatura a 18ºC), y deben ser térmicamente pasivos (no aportar calor al entorno ambiente del CPD). Dicho circuito de agua deberá alimentar las puertras traseras de los racks a instalar, como a su vez las CDUs (Cooling Distribution Units). El licitador deberá proveer e instalar CDUs (cooling distribution units) redundantes las cuales crearan un circuito aislado de refrigeración directa a chip mediante agua (Diect Liquid Cooling) para los nodos de cómputo, en caso que sea necesario. Se aconseja la instalación de una unidad CDU in-rack. El proyecto deberá incluir cualquier modificación del datacenter para poder instalar el sistema de refrigeración propuesto y el uso del circuito de agua de refrigeración actual. | | R6 | El sistema de refrigeración dentro de los racks de cómputo (circuitos DLC, puertas traseras (RDHX), CDUs, …) y sus componentes se considerarán parte del supercomputador. El licitador deberá ser responsable del mantenimiento de esos circuitos (anti-bacterias, corrosión, pérdidas, etc.) Adicionalmente para esos circuitos se debe proveer: • Equipos redundantes siempre que sea posible (bombas redundantes, filtros en las CDUs, etc.) |     | Ref | Descripción | |-------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | | • Regulación automática del flujo de agua dependiendo de la carga del rack • Sistema de monitorización de sus sensores (pH, temperatura, flujo de agua, estado, …) integrados con el resto de métricas del superordenador. • Se deberán generar alarmas en caso de fallos, y permitir el vaciado automático de los nodos de cómputo afectados por el fallo para evitar que los nodos se dañen. • Configuración, instalación y mantenimiento de estos elementos, realizados por un único proveedor para asegurar la responsabilidad delante de cualquier incidencia • El mantenimiento de los circuitos de agua, su pureza y buen funcionamiento, serán parte de las tareas de mantenimiento del superordenador. Es esperable el poder disponer de segmentación de los circuitos internos de refrigeración de agua, con tal de reducir los mantenimientos globales en caso de realizar tareas de mantenimiento. | | R7 | Todos los componentes deberán estar etiquetados para ser identificados físicamente (rack, servidor, switch cables, etc.) | | R9 | El licitador deberá indicar en la oferta: • Tipos, número y características técnicas de los racks propuestos (dimensión, peso, consumo eléctrico, …) • Plano de los componentes instalados por cada tipo de rack • Plano de las conexiones eléctricas dentro de cada tipo de rack • Plano general de cada datacenter, con los diferentes racks y componentes del superordenador (CDU, etc.) • Circuitos de DLC y otros circuitos de refrigeración propuestos indicando las características de los mismos Esquema para el cableado indicando el número de cables que llevarán las bandejas, y el número de cableado entrante/saliente de cada rack | | R10 | La alimentación del sistema debe cumplir con los estándares DIN-VD en el momento de la instalación. Los conectores deben ser conforme a IEC 60309/DIN EN 60309. |     | Ref | Descripción | |---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R13 | El candidato debe proveer las declaraciones necesarias respecto al cumplimiento de los estándares de seguridad. Para los conectores y PDUs se debe presentar conformidad y certificado con la marca EC según la directiva de voltaje bajo 2014/35/EU. Toda PDU debe trabajar con 400V a 50Hz, los conectores de alimentación de los racks de computo deben ser '400V, 32 A, 3L+N+PE' y los de gestión (bajo SAI) '230V, 32 A, 1L+N+PE . Todas las fuentes de alimentación deben soportar una tolerancia de voltaje mínimo de 5% (más alta o más baja). Para el paso de los cables de datos (entre filas), cables eléctricos, cables de agua de | | R14 | Toda entrega al BSC se deberá realizar con camiones con las características que indique el BSC-CNS durante el proyecto para el correcto acceso. Todo empleado o subcontratado por el licitador que tenga que desarrollar trabajos en los datacenters o transportes deberá cumplir con las normativas PRL (Prevención de Riesgos Laborales) del BSC-CNS. | | R15 | El licitador deberá de proveer de todos los elementos mecánicos hasta el posicionamiento del rack en la huella del datacenter, como cualquier operativa de mantenimiento posterior necesaria. | | R16 | Cualquier modificación/instalación en el datacenter sótano TG necesaria para la instalación y funcionamiento del clúster deberá estar incluida. Estas modificaciones deberán documentarse adecuadamente y presentarse a Industria para su certificación. | | R17 | Se provee la siguiente lista orientativa de tareas a realizar, los candidatos deberán validar todas las tareas a implementar en la visita a realizar: - Instalación de magneto térmicos y líneas eléctricas desde cuadros eléctricos, si las existentes no fueran suficientes para la solución presentada - Cualquier tarea relacionada con la instalación de las CDUs a proporcionar - Conexión de los racks y CDUs a los circuitos de agua de refrigeración existentes, picajes, tuberías, elementos de filtrado (si fueran necesarios), llaves de paso, válvulas, válvulas CNV, latiguillos hidráulicos, purgado, calibrado y puesta en marcha, etc. - Implantación del rack en la huella, fijado con patas niveladoras, y nivelado. | | | La instalación de tuberías de agua, cables de alimentación deberá hacerse ordenada y siguiendo un diseño similar a los de los racks ya existentes. Entre otras acciones implica el cortar tuberías y cables eléctricos para que tengan la medida justa y necesaria. Todo tubo/cable deberá ir etiquetado siguiendo la nomenclatura que indique el BSC. Los racks a proporcionar deberán tener una altura máxima de 2.1m, y un peso | | R18 R20 | máximo de 1200kg/m2, y se harán llegar al CPD por un montacargas exterior. Se deberá incluir todas las tareas de cableado de los componentes según el diseño |     | Ref | Descripción | |-------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | R21 | Los servidores deberán disponer de un sistema para poder consultar su temperatura de ambiente de trabajo, para poder definir alertas y avisos. De la misma manera, debe soportar la parada automática en caso de detectar temperatura muy alta. | | R22 | Se deberán conectar todos los racks a la red de equipotencial existente. O la modificación de dicha red si hiciera falta. | | R23 | La sala dispone de un punto de muestreo para la detección de humos por aspiración, que debe ser instalado en el interior de los racks, cualquier modificación o requerimiento deberá hacerse cargo la empresa adjudicataria. | | R24 | Se deberá incluir todos los elementos y componentes necesarios para el transporte y ubicación de los rack totalmente instalados en el espacio dedicado dentro sala CPD del edificio TG planta -1. | | R25 | Se deberá de realizar limpieza diaria del material sobrante a medida que se vaya instalando, la empresa licitadora se deberá hacer cargo de la limpieza del material sobrante y de la limpieza final de obra, la recogida de residuos se deberá realizar a un vertedero oficial para su correcto reciclaje. | | R26 | Con la finalización del proyecto se deberá presentar la siguiente documentación en formato Autocad 2000 o superior y PDF: - Planos Asbuilt con todos los elementos instalados. Fichas técnicas de todos los elementos instalados. | ## I.3. CARACTERÍSTICAS DE LA GARANTÍA OBLIGATORIA DEL FABRICANTE Todos los equipos suministrados están sujetos a una garantía que debe proporcionar el fabricante y que contará, como mínimo, con las siguientes características básicas, según queda recogido en el PPT: - -La garantía obligatoria del fabricante responderá del malfuncionamiento y averías de los equipos. - -El fabricante ofrecerá la posibilidad de recibir avisos en horario de 9h a 17h de lunes a viernes, salvo festivos nacionales. El tiempo máximo de respuesta del fabricante será de 8h dentro de este horario, y el tiempo máximo de reparación de la avería desde la comunicación de la incidencia por el organismo será de 5 días laborables según el calendario laboral aplicable en el lugar donde están instalados los equipamientos. - -Periodo de garantía mínimo de 3 años. ☒ Periodo de garantía superior: En el caso que el licitador ofrezca en su oferta mantenimiento superior al mínimo estipulado la garantía de fabricante también se deberá extender de la misma manera.     - ☒ Otras condiciones adicionales exigibles al fabricante: En la implantación de la solución presentada como durante la garantía se exigirá la participación activa y presencial (si se requiere) de los expertos de cada uno de los componentes hardware que forman la solución: Responsables de hardware/ desarrolladores de firmware, desarrolladores o responsables técnicos de redes o switches ethernet, desarrolladores o responsables técnicos de red Infiniband ofertada. Teniendo la posibilidad el personal del BSC poder intercambiar emails de forma directa con dichas personas con el fin de solucionar cualquier problema que surja durante el desarrollo e instalación de la máquina. Los licitadores deberán ofertar los equipamientos bajo una modalidad de garantía del fabricante que dé cuenta de las exigencias contenidas en este apartado. ## I.4. PERIODO DE VIGENCIA Y MODALIDAD DE LICENCIAMIENTO Vigencia de las licencias: | Programa | Periodo de vigencia del licenciamiento | |--------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------| | Linux Enterprise | 3 años (o mantenimiento mejorado ofertado por el licitador) desde la aceptación del mismo | | Debugger paralelo 128 MPI | 3 años (o mantenimiento mejorado ofertado por el licitador) desde la aceptación del mismo | | Monitorización y gestión rutas red de alto rendimiento (Infirniband o similar) | 3 años (o mantenimiento mejorado ofertado por el licitador) desde la aceptación del mismo | Las licencias deben conceder el derecho de uso del software para los equipos licitados para siempre. Se deberá poder seguir usando el software después de caducar la licencia, aunque ya no se pueda acceder a nuevas versiones o no se ofrezca soporte. Los programas deben bajo alguna modalidad de licenciamiento tal, que garantice al menos los siguientes derechos ante el fabricante : | Programa | Derechos durante la vigencia de las licencias | |------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | TODOS | • Derecho de actualización: parches de seguridad, versiones menores, versiones mayores, etc. • Derecho de acceso a documentación: sin limitación de tiempo • Derecho de consulta al fabricante (soporte del fabricante): o Con los mismos tiempos de respuesta y horario que el de cualquier otro componente |