Compute4PUNCH & Storage4PUNCH: Infraestructura Federada para Física de Partículas, Astrofísica y Física Nuclear

1. Introducción

El consorcio PUNCH4NFDI (Partículas, Universo, Núcleos y Hadrones para la Infraestructura Nacional de Datos de Investigación), financiado por la Fundación Alemana para la Investigación (DFG), representa aproximadamente a 9.000 científicos de las comunidades de física de partículas, astrofísica, astropartículas, hadrones y física nuclear en Alemania. Integrado en la iniciativa nacional NFDI, su objetivo principal es establecer una plataforma de datos científicos federada y FAIR (Localizable, Accesible, Interoperable, Reutilizable). Esta plataforma pretende proporcionar acceso sin fisuras a los diversos y heterogéneos recursos de computación y almacenamiento aportados por sus instituciones miembros, abordando el desafío común de analizar volúmenes de datos que crecen exponencialmente con algoritmos complejos. Este documento se centra en los conceptos técnicos de Compute4PUNCH y Storage4PUNCH, que forman la columna vertebral de esta infraestructura federada.

2. Infraestructura Federada de Computación Heterogénea – Compute4PUNCH

Compute4PUNCH aborda el desafío de utilizar eficazmente una amplia gama de recursos de computación de alto rendimiento (HPC), computación de alto rendimiento (HTC) y recursos en la nube distribuidos por toda Alemania, aportados en especie. Estos recursos varían en arquitectura, sistemas operativos, pilas de software y mecanismos de autenticación.

2.1. Arquitectura Central y Sistema de Superposición

La piedra angular de Compute4PUNCH es la creación de un sistema por lotes federado de superposición basado en HTCondor. La innovación clave es el uso del meta-planificador de recursos COBalD/TARDIS. TARDIS (TARDIS Actúa como un Despachador de Recursos para la Planificación In Situ) integra de forma dinámica y transparente recursos externos y heterogéneos en el grupo de HTCondor. Actúa como un sistema "piloto", enviando trabajos de marcador de posición a clústeres externos (como sistemas HPC basados en Slurm) que luego extraen y ejecutan trabajos reales de usuarios de la cola central de HTCondor. Este enfoque minimiza la intrusión en las configuraciones operativas existentes de los proveedores de recursos, un requisito crítico para su adopción.

La lógica de emparejamiento y planificación de recursos puede representarse de forma abstracta mediante una función de optimización. Sea $R = \{r_1, r_2, ..., r_n\}$ el conjunto de recursos heterogéneos disponibles, cada uno con atributos como arquitectura $arch(r_i)$, núcleos disponibles $c(r_i)$, memoria $m(r_i)$ y tiempo de espera en cola $w(r_i)$. Sea $J = \{j_1, j_2, ..., j_m\}$ el conjunto de trabajos de usuario con requisitos $req(j_k)$. El objetivo del meta-planificador es encontrar un mapeo $M: J \rightarrow R$ que maximice una función objetivo $F$, a menudo una suma ponderada de eficiencia y equidad:

$F(M) = \alpha \cdot \sum_{j_k} U(j_k, M(j_k)) - \beta \cdot \sum_{r_i} L(r_i, M^{-1}(r_i))$

donde $U$ es una función de utilidad que mide cómo un recurso satisface los requisitos de un trabajo (considerando la compatibilidad del entorno de software a través de CVMFS), y $L$ es una función de carga que penaliza la sobresuscripción de cualquier recurso individual. COBalD/TARDIS resuelve heurísticamente este problema de planificación dinámica y en línea.

2.2. Acceso y Entorno de Software

El acceso de los usuarios se estandariza mediante una Infraestructura de Autenticación y Autorización (AAI) basada en tokens. Los puntos de entrada principales son los nodos de inicio de sesión tradicionales y un servicio JupyterHub, que proporciona una interfaz web familiar para análisis interactivo y creación de prototipos.

Para manejar diversas dependencias de software, la infraestructura aprovecha las tecnologías de contenedores (por ejemplo, Docker, Singularity/Apptainer) y el Sistema de Archivos de Máquina Virtual del CERN (CVMFS). CVMFS proporciona un espacio de nombres escalable, de solo lectura y distribuido globalmente para instalaciones de software. Las pilas de software específicas de cada comunidad se publican en repositorios CVMFS, garantizando que cualquier nodo de computación, independientemente de su ubicación física, pueda acceder al entorno de software requerido de forma instantánea y consistente, eliminando la sobrecarga de instalación local.

3. Infraestructura Federada de Almacenamiento – Storage4PUNCH

Storage4PUNCH se centra en federar los sistemas de almacenamiento proporcionados por la comunidad, que se basan predominantemente en las tecnologías dCache o XRootD, ambas bien establecidas en la Física de Altas Energías (HEP).

3.1. Estrategias de Federación y Caché

La federación crea un espacio de nombres unificado, permitiendo a los usuarios acceder a datos a través de múltiples elementos de almacenamiento institucionales como si fueran un solo sistema. Se emplean tecnologías como el protocolo de federación de XRootD y la agrupación de frontales de dCache para lograr esto. El sistema realiza una localización y enrutamiento inteligente de datos.

Un componente crítico en evaluación es el caché. Una capa de caché global o regional puede reducir significativamente la latencia y la carga de la red de área extensa para conjuntos de datos de acceso frecuente. La tasa de aciertos $H$ de un caché de tamaño $S$ para un patrón de acceso a datos puede modelarse. Si la probabilidad de acceder al elemento de datos $d_i$ sigue una distribución tipo Zipf $P(i) \sim 1 / i^{\alpha}$, la tasa de aciertos esperada para un caché LRU es aproximadamente:

$H(S) \approx \sum_{i=1}^{S} P(i)$

donde $\alpha$ es el parámetro de asimetría. Para flujos de trabajo científicos con alta reutilización de datos (común en cadenas de análisis), incluso cachés de tamaño moderado pueden producir una $H$ alta, justificando su despliegue. El proyecto también está evaluando soluciones de manejo de metadatos para una integración más profunda, con el objetivo de proporcionar no solo acceso a archivos, sino también capacidades de descubrimiento de datos a través de la federación.

4. Detalles Técnicos y Marco Matemático

El rendimiento de la federación depende del descubrimiento y planificación eficiente de recursos. El estado del sistema puede modelarse como un grafo $G=(V,E)$, donde los vértices $V$ representan recursos (nodos de computación, endpoints de almacenamiento) y las aristas $E$ representan enlaces de red con ancho de banda $bw(e)$ y latencia $lat(e)$. Un flujo de trabajo $W$ es un Grafo Acíclico Dirigido (DAG) de tareas $T$ con dependencias de datos $D$.

El problema de planificación se convierte en: Colocar cada tarea $t \in T$ en un recurso de computación $r_c \in V_c$ y enrutar sus datos de entrada requeridos desde recursos de almacenamiento $r_s \in V_s$ de tal manera que el tiempo total de ejecución (tiempo de finalización del flujo de trabajo) se minimice, sujeto a restricciones:

$\text{minimizar } \max_{t \in T} (ft(t))$
sujeto a:
$\forall r \in V_c, \sum_{t colocada\ en\ r} c(t) \leq C(r)$ (capacidad de CPU)
$\forall d \in D, \text{tiempo\_transferencia}(d) = \frac{tamaño(d)}{\min\_bw(ruta)} + \sum_{e \in ruta} lat(e)$

Donde $ft(t)$ es el tiempo de finalización de la tarea $t$, $c(t)$ su demanda de CPU y $C(r)$ la capacidad del recurso $r$. El sistema federado utiliza algoritmos heurísticos dentro de HTCondor y COBalD/TARDIS para aproximar soluciones a este problema NP-duro en tiempo real.

5. Resultados Experimentales y Rendimiento del Prototipo

El documento informa sobre las experiencias iniciales con prototipos operativos. Si bien no se detallan puntos de referencia cuantitativos específicos en el extracto proporcionado, el texto implica la ejecución exitosa de aplicaciones científicas en la infraestructura federada.

Descripción del Gráfico (Métricas de Rendimiento Inferidas): Un gráfico de rendimiento hipotético probablemente mostraría dos métricas clave a lo largo del tiempo: 1) Utilización Agregada de Recursos en todo el grupo federado, demostrando cómo el sistema de superposición llena efectivamente las brechas de capacidad entre los diferentes centros contribuyentes. 2) Tiempo de Respuesta de los Trabajos comparando un escenario federado contra el uso aislado de recursos. El sistema federado mostraría un promedio y una varianza más bajos en el tiempo de respuesta, especialmente para trabajos con requisitos de recursos flexibles, ya que pueden enrutarse a recursos con la cola más corta. La integración de recursos HPC a través de TARDIS mostraría una curva distinta, agregando inicialmente latencia debido al mecanismo de trabajos piloto, pero proporcionando acceso a nodos de alto número de núcleos que de otro modo no estarían disponibles para cargas de trabajo adecuadas.

Se informa que el uso de CVMFS proporciona con éxito entornos de software uniformes, un factor crítico de éxito para la adopción por parte de los usuarios. La AAI basada en tokens ha sido implementada, proporcionando la base necesaria para un acceso seguro y multi-institucional.

6. Marco de Análisis: Un Caso de Estudio Conceptual

Caso: Análisis de Astrofísica de Multi-Mensajeros. Un astrofísico de partículas necesita analizar datos de un estallido de rayos gamma (GRB) detectado por Fermi-LAT e IceCube, correlacionándolo con observaciones ópticas de seguimiento de ASAS-SN. El flujo de trabajo implica: A) Procesar terabytes de datos de fotones en bruto (Fermi) en una granja HTC optimizada para E/S alta. B) Ejecutar simulaciones de Monte Carlo para la reconstrucción de eventos de neutrinos (IceCube) en un clúster HPC con muchos núcleos. C) Realizar análisis de imágenes en datos ópticos utilizando nodos GPU.

Ejecución Federada a través de Compute4PUNCH/Storage4PUNCH:
1. El usuario envía una única descripción de flujo de trabajo de alto nivel (por ejemplo, usando el Common Workflow Language - CWL) a través de JupyterHub.
2. El token AAI autentica al usuario en todos los sistemas.
3. La superposición de HTCondor, guiada por COBalD/TARDIS, analiza el DAG del flujo de trabajo:
- La Tarea A se empareja y envía a trabajadores HTC cercanos al almacenamiento respaldado por dCache en DESY.
- El requisito de la Tarea B de 10.000 horas-CPU activa a TARDIS para provisionar espacios en un clúster HPC basado en Slurm en KIT.
- La Tarea C se envía a una partición GPU en la Universidad de Bonn.
4. Todas las tareas extraen la misma pila de software de análisis (Python, bibliotecas científicas específicas) del repositorio PUNCH CVMFS.
5. Los datos intermedios se intercambian a través del espacio de nombres federado Storage4PUNCH (por ejemplo, usando XRootD), con archivos de calibración de acceso frecuente servidos desde un caché regional.
6. Los resultados finales se agregan y devuelven al usuario.

Este caso demuestra la propuesta de valor: el físico interactúa con una única infraestructura lógica en lugar de gestionar inicios de sesión separados, instalaciones de software y transferencias de datos en tres sistemas distintos.

7. Perspectiva Central y del Analista

Perspectiva Central: PUNCH4NFDI no está construyendo otro supercomputador monolítico; está diseñando una capa de federación—un "meta-sistema operativo" para la computación de investigación a escala nacional y heterogénea. Su verdadera innovación es la orquestación pragmática de recursos existentes, políticamente aislados, en una utilidad coherente, priorizando la mínima intrusión sobre la pureza tecnológica. Esto se parece menos al Borg de Google y más a un sofisticado sistema de control de tráfico aéreo a nivel de la UE para trabajos de computación.

Flujo Lógico: La lógica es elegantemente recursiva. Comienza con la restricción no negociable: no interrumpir las operaciones comunitarias existentes. Esto fuerza una arquitectura de superposición basada en extracción (pull) (HTCondor + TARDIS) en lugar de un planificador centralizado basado en inserción (push). Esa superposición, a su vez, requiere un mecanismo universal de entrega de software (CVMFS/Contenedores) y una capa de identidad unificada (Token AAI). La federación de almacenamiento sigue una vía paralela, aprovechando herramientas probadas en HEP (dCache/XRootD). Todo el flujo es una clase magistral de diseño impulsado por restricciones, donde cada elección técnica es una consecuencia directa de la realidad socio-política de la colaboración multi-institucional.

Fortalezas y Debilidades:
Fortalezas: La arquitectura es brillantemente federable. Escala la gobernanza horizontalmente por diseño, reduciendo las barreras para nuevos proveedores de recursos. El uso de HTCondor y CVMFS aprovecha décadas de confianza de la comunidad y experiencia operativa de las colaboraciones del LHC, reduciendo el riesgo técnico. El enfoque en recursos "en especie" es financieramente sostenible, convirtiendo un problema de fragmentación en una ventaja de diversidad.
Debilidades: El elefante en la habitación es la sobrecarga de rendimiento. La doble planificación (meta-planificador + sistema por lotes local) y el modelo de trabajos piloto inevitablemente agregan latencia, haciéndolo inadecuado para trabajos MPI de grano fino y estrechamente acoplados—una limitación significativa para cargas de trabajo HPC puras. La dependencia de CVMFS, aunque robusta, crea un único punto de fallo para la entrega de software y puede tener dificultades con códigos altamente propietarios o con licencia. Además, como se señala en los principios de datos FAIR, la verdadera interoperabilidad requiere metadatos ricos; la descripción actual de Storage4PUNCH parece muy centrada en el acceso a nivel de bytes, no en el descubrimiento semántico.

Perspectivas Accionables:
1. Para el Equipo PUNCH: Redoblar la caracterización del rendimiento. Publicar puntos de referencia transparentes comparando el rendimiento y la latencia de trabajos federados versus nativos para flujos de trabajo canónicos. Estos datos son cruciales para convencer a los gestores y usuarios escépticos de los centros HPC. Desarrollar proactivamente un modelo de soporte de "Nivel 1" para la propia capa de federación; su complejidad se convierte en una dependencia crítica.
2. Para Otros Consorcios (por ejemplo, en Bioinformática o Ciencias del Clima): No solo copien la pila tecnológica. Copien el modelo de gobernanza que la hizo posible. La lección clave es el acuerdo de "contribución en especie" que alinea los incentivos institucionales. Comiencen federando la autenticación y la distribución de software, como hizo PUNCH; estos son fundamentales.
3. Para Agencias de Financiación (DFG, UE): Este modelo debería ser el plan para futuras convocatorias de infraestructuras nacionales de investigación. Financien el "pegamento" (coordinación, desarrollo central de devops para la capa de federación) y dejen que las instituciones financien los "ladrillos" (computación/almacenamiento real). Esto aprovecha las inversiones de capital existentes de manera más efectiva que construir nuevas instalaciones centralizadas, un principio reflejado en la visión estratégica de la Nube Europea de Ciencia Abierta (EOSC).

En conclusión, Compute4PUNCH y Storage4PUNCH representan un modelo maduro, pragmático y altamente replicable para la infraestructura científica a gran escala del siglo XXI. Intercambia algo de rendimiento teórico por enormes ganancias en accesibilidad, resiliencia y viabilidad política. Su éxito no se medirá en FLOPS, sino en el número de estudiantes de doctorado que puedan completar su análisis sin convertirse en administradores de sistemas expertos para cinco clústeres diferentes.

8. Aplicaciones Futuras y Hoja de Ruta de Desarrollo

La infraestructura PUNCH4NFDI sienta las bases para varios avances futuros:

Integración con Flujos de Trabajo de Aprendizaje Automático: La federación puede extenderse para soportar aceleradores especializados de IA/ML (por ejemplo, pods NVIDIA DGX, TPUs de Google) como un tipo de recurso. Marcos como Kubeflow podrían integrarse junto con HTCondor, con TARDIS gestionando la colocación híbrida de trabajos entre recursos HTC tradicionales y recursos centrados en ML.
Colocación Proactiva de Datos y Planificación Consciente del Flujo de Trabajo: Más allá del caché, el sistema podría implementar la preparación predictiva de datos. Al analizar los DAGs de flujo de trabajo enviados por los usuarios, podría pre-cargar los conjuntos de datos requeridos desde endpoints remotos de Storage4PUNCH a cachés locales cerca de los recursos de computación programados antes de que comience la ejecución del trabajo, ocultando efectivamente la latencia de transferencia de datos. Esto requiere una integración más estrecha entre el meta-planificador de computación y el espacio de nombres y los datos de monitoreo de la federación de almacenamiento.
Expansión a la Computación en el Borde: Para campos como la radioastronomía o la física de neutrinos, donde los sensores generan vastos flujos de datos, el modelo de federación podría incorporar sitios de computación en el borde. Agentes TARDIS ligeros podrían ejecutarse en observatorios, extrayendo tareas de preprocesamiento de la cola central para filtrar y reducir datos in situ antes de transmitir solo eventos relevantes al almacenamiento central.
Computación Verde y Planificación Consciente del Carbono: El meta-planificador podría mejorarse con datos de intensidad de carbono de las redes eléctricas en toda Alemania. Luego podría enrutar preferentemente trabajos a centros de datos en regiones con alta penetración de energía renovable (por ejemplo, energía eólica en el norte) en momentos de producción máxima, minimizando la huella de carbono de las computaciones a gran escala—una prioridad emergente para las infraestructuras de investigación como destaca la iniciativa Carbon Call de la Linux Foundation.
Inter-Federación con Socios Internacionales: El siguiente paso lógico es conectar la federación alemana PUNCH con infraestructuras similares en el extranjero, como la Worldwide LHC Computing Grid (WLCG), la Open Science Grid (OSG) o la European Open Science Cloud (EOSC). Esto crearía una infraestructura de investigación global y multidisciplinaria, aunque plantearía desafíos significativos en alineación de políticas, seguridad y contabilidad.

9. Referencias

Consorcio PUNCH4NFDI. "PUNCH4NFDI - Particles, Universe, NuClei and Hadrons for the NFDI." Libro Blanco, 2021.
Thain, D., Tannenbaum, T., & Livny, M. "Distributed computing in practice: the Condor experience." Concurrency - Practice and Experience, 17(2-4), 323-356, 2005. https://doi.org/10.1002/cpe.938
Blomer, J., et al. "CernVM-FS: delivering scientific software to globally distributed computing resources." International Journal of High Performance Computing Applications, 28(2), 158-174, 2014. https://doi.org/10.1177/1094342013509700
Giffels, M., et al. "COBalD/TARDIS – Dynamic, Pilot-based Resource Provisioning for a Federated HTCondor Pool." En Proceedings of CHEP 2018, 2018.
Wilkinson, M. D., et al. "The FAIR Guiding Principles for scientific data management and stewardship." Scientific Data, 3:160018, 2016. https://doi.org/10.1038/sdata.2016.18
Comisión Europea. "European Open Science Cloud (EOSC) Strategic Implementation Roadmap." 2018.
Linux Foundation. "Carbon Call: A Global Initiative for Reliable Carbon Accounting." 2022. https://www.linuxfoundation.org/research/carbon-call
Zhu, J.-Y., Park, T., Isola, P., & Efros, A. A. "Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks." En Proceedings of the IEEE International Conference on Computer Vision (ICCV), 2017. (Citado como ejemplo de una carga de trabajo computacional compleja que podría beneficiarse del acceso federado y heterogéneo a recursos).