Compute4PUNCH & Storage4PUNCH: Infraestrutura Federada para Física de Partículas, Astrofísica e Física Nuclear

1. Introdução

O consórcio alemão Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure (PUNCH4NFDI), financiado pela DFG (Deutsche Forschungsgemeinschaft), representa aproximadamente 9.000 cientistas das comunidades de física de partículas, astrofísica, astropartículas, hadrões e física nuclear. O seu principal objetivo é estabelecer uma plataforma federada de dados científicos FAIR (Findable, Accessible, Interoperable, Reusable). Esta plataforma visa fornecer acesso unificado aos diversos e heterogéneos recursos de computação e armazenamento contribuídos pelas suas instituições membro em toda a Alemanha, abordando o desafio comum de analisar volumes de dados que crescem exponencialmente com algoritmos complexos.

2. Infraestrutura Federada de Computação Heterogénea – Compute4PUNCH

O conceito Compute4PUNCH aborda o desafio de fornecer acesso contínuo a uma vasta gama de recursos de computação de alto rendimento (HTC), computação de alto desempenho (HPC) e cloud, contribuídos em espécie. Estes recursos variam em arquitetura, sistema operativo, software e autenticação, e já estão operacionais e partilhados, exigindo uma abordagem de integração não intrusiva.

3. Infraestrutura Federada de Armazenamento – Storage4PUNCH

Paralelamente à computação, o conceito Storage4PUNCH federa sistemas de armazenamento fornecidos pela comunidade, baseados principalmente nas tecnologias dCache e XRootD, que são bem estabelecidas na Física de Altas Energias (HEP).

4. Detalhes Técnicos e Enquadramento Matemático

O desafio central de agendamento pode ser modelado como um problema de otimização de recursos. Seja $R = \{r_1, r_2, ..., r_n\}$ o conjunto de recursos heterogéneos, cada um com atributos como arquitetura, núcleos disponíveis $c_i$, memória $m_i$ e tempo de espera na fila $w_i$. Seja $J = \{j_1, j_2, ..., j_m\}$ o conjunto de tarefas com requisitos $\hat{c}_j, \hat{m}_j$.

O meta-agendador (COBalD/TARDIS) visa maximizar a utilidade ou o rendimento global. Uma função objetivo simplificada para a colocação de tarefas pode ser minimizar o makespan ou maximizar a utilização de recursos, considerando as restrições:

$\text{Minimizar } \max_{r \in R} (\text{completionTime}(r))$

sujeito a: $\sum_{j \in J_r} \hat{c}_j \leq c_r \quad \text{e} \quad \sum_{j \in J_r} \hat{m}_j \leq m_r \quad \forall r \in R$

onde $J_r$ é o conjunto de tarefas atribuídas ao recurso $r$. A natureza dinâmica é tratada pelo TARDIS, que "engana" o HTCondor para ver os recursos remotos como parte do seu conjunto local.

5. Resultados Experimentais e Estado do Protótipo

O artigo relata o estado atual e as primeiras experiências com aplicações científicas em protótipos disponíveis. Embora números de benchmark específicos não sejam detalhados no excerto fornecido, a execução bem-sucedida de cargas de trabalho científicas reais está implícita. A integração do HTCondor com o COBalD/TARDIS foi demonstrada para integrar dinamicamente recursos de diferentes domínios administrativos. O acesso inicial do utilizador via JupyterHub e AAI baseado em tokens foi testado, fornecendo uma prova de conceito para o ponto de entrada unificado. A utilização do CVMFS foi validada para fornecer os ambientes de software necessários em toda a infraestrutura federada.

6. Enquadramento de Análise: Um Estudo de Caso Conceptual

Considere uma análise de astrofísica multi-mensageira que procura contrapartes de neutrinos para explosões de raios gama. O fluxo de trabalho envolve:

1. Descoberta de Dados: Um investigador utiliza o catálogo federado de metadados (em avaliação no Storage4PUNCH) para localizar dados relevantes de eventos de neutrinos do IceCube e dados de raios gama do Fermi-LAT, armazenados em instâncias dCache no DESY e em Bielefeld.
2. Submissão do Fluxo de Trabalho: Através da interface JupyterHub, o investigador define uma análise de varredura de parâmetros. Os requisitos da tarefa (software: Python, conjunto de software IceCube via CVMFS; computação: 1000 horas de CPU) são especificados.
3. Orquestração: O overlay HTCondor, orientado pelo COBalD/TARDIS, combina e despacha dinamicamente centenas de tarefas para slots disponíveis no HPC do KIT, no HTC de Bona e em recursos cloud. O token AAI trata da autenticação de forma contínua.
4. Execução e Acesso a Dados: As tarefas obtêm software do CVMFS, leem dados de entrada diretamente do armazenamento federado via portas XRootD e escrevem resultados intermédios num espaço de armazenamento temporário.
5. Agregação de Resultados: Os resultados finais são agregados e escritos de volta para um repositório persistente e compatível com FAIR dentro da federação Storage4PUNCH.

Este caso demonstra a proposta de valor: um cientista interage com um sistema único e coerente para aproveitar recursos heterogéneos dispersos nacionalmente, sem gerir a complexidade subjacente.

7. Perspetivas de Aplicação e Direções Futuras

A infraestrutura combinada Compute4PUNCH e Storage4PUNCH tem um potencial significativo para além das comunidades PUNCH iniciais:

• Federação Transversal: O modelo poderia ser estendido a outros consórcios NFDI ou iniciativas da European Open Science Cloud (EOSC), criando uma verdadeira infraestrutura federada pan-europeia.
• Integração da Computação na Periferia: Para áreas como a radioastronomia ou monitorização de detetores, a integração de recursos de computação na periferia, perto dos sensores, poderia ser um próximo passo lógico.
• Suporte a Cargas de Trabalho de IA/ML: Melhorar o agendador para suportar nativamente recursos GPU/aceleradores e frameworks como Kubernetes para tarefas de treino de ML em grande escala.
• Gestão Avançada de Dados: Integração mais profunda de colocação inteligente de dados, gestão do ciclo de vida e catálogos de metadados ativos para otimizar fluxos de trabalho intensivos em dados.
• Híbrido com Computação Quântica: À medida que a computação quântica amadurece, a federação poderia incorporar processadores quânticos como recursos especializados para passos específicos de algoritmos.

O sucesso desta federação dependerá de financiamento sustentável, robustez operacional e da contínua adesão da comunidade ao modelo federado em detrimento da otimização local.

8. Referências

1. Consórcio PUNCH4NFDI. "PUNCH4NFDI – Particles, Universe, NuClei and Hadrons for the NFDI." White Paper, 2021.
2. Thain, D., Tannenbaum, T., & Livny, M. "Distributed computing in practice: the Condor experience." Concurrency and Computation: Practice and Experience, 17(2-4), 323-356, 2005.
3. Blomer, J., et al. "CernVM-FS: delivering scientific software to globally distributed computing resources." Journal of Physics: Conference Series, 396(5), 052018, 2012.
4. Fuhrmann, P., & Gulzow, V. "dCache, storage system for the future." In European Conference on Parallel Processing (pp. 1106-1113). Springer, Berlin, Heidelberg, 2006.
5. XRootD Collaboration. "XRootD – A highly scalable architecture for data access." WSEAS Transactions on Computers, 10(11), 2011.
6. Isard, M., et al. "Quincy: fair scheduling for distributed computing clusters." In Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles (pp. 261-276), 2009. (Para contexto teórico de agendamento).
7. Wilkinson, M. D., et al. "The FAIR Guiding Principles for scientific data management and stewardship." Scientific data, 3(1), 1-9, 2016.

9. Análise Original: Ideia Central, Fluxo Lógico, Pontos Fortes e Fracos, Ideias Acionáveis

Ideia Central: O PUNCH4NFDI não está a construir um novo supercomputador; está a conceber uma camada de federação de intrusão mínima viável. Esta é uma resposta pragmática e politicamente astuta à restrição real do panorama fragmentado e comunitário da computação de investigação na Alemanha. A verdadeira inovação não está nas tecnologias individuais — HTCondor, dCache, CVMFS são tecnologias comprovadas — mas na sua orquestração num sistema nacional coerente com uma AAI baseada em tokens como cola. É uma clássica estratégia de "rede overlay" aplicada à ciberinfraestrutura, reminiscente de como a própria internet foi construída sobre diversas redes físicas. Enquanto a European Open Science Cloud (EOSC) lida com desafios de federação semelhantes, a abordagem do PUNCH oferece um plano operacional concreto.

Fluxo Lógico: A lógica é convincentemente simples: 1) Aceitar a heterogeneidade como um estado permanente, não um problema a eliminar. 2) Utilizar meta-agendamento leve (COBalD/TARDIS) para criar um conjunto virtual, evitando a necessidade de modificar agendadores locais entrincheirados (SLURM, PBS, etc.). 3) Desacoplar a gestão de identidade e acesso via tokens, contornando o pesadelo de reconciliar contas institucionais. 4) Desacoplar o software da infraestrutura via CVMFS/contentores. 5) Aplicar a mesma lógica de federação ao armazenamento. O fluxo vai da simplicidade voltada para o utilizador (JupyterHub) para baixo, através de camadas de abstração, até à complexidade subjacente.

Pontos Fortes e Fracos: O ponto forte esmagador é a capacidade de implementação prática. Ao exigir alterações mínimas dos fornecedores de recursos, reduz a barreira à participação, o que é crucial para arrancar um consórcio. Aproveitar ferramentas HEP maduras garante fiabilidade e reduz o risco de desenvolvimento. No entanto, as falhas estão nas compensações. O modelo overlay pode introduzir sobrecargas de desempenho no despacho de tarefas e no acesso a dados, em comparação com um sistema totalmente integrado. A abstração do "mínimo denominador comum" pode limitar o acesso a funcionalidades únicas de sistemas HPC específicos. Mais criticamente, o modelo de sustentabilidade a longo prazo não está comprovado — quem paga pela coordenação central, pela manutenção do meta-agendador e pelo suporte ao utilizador? O projeto corre o risco de construir um protótipo brilhante que murcha após o financiamento inicial de 5 anos da DFG.

Ideias Acionáveis: Para outros consórcios, a principal lição é começar com governança e integração leve, não com um grande redesenho técnico. 1) Adotar imediatamente uma AAI baseada em tokens; é o facilitador fundamental. 2) Priorizar a experiência do utilizador (JupyterHub) para impulsionar a adoção; os cientistas não usarão um sistema complicado. 3) Instrumentar tudo desde o primeiro dia. Para garantir financiamento futuro, devem gerar métricas convincentes sobre o aumento da utilização de recursos, colaboração interinstitucional e rendimento científico. 4) Planear a "segunda federação" — como interligar com outros consórcios NFDI ou a EOSC. A arquitetura técnica deve ser explicitamente concebida para federação aninhada. Finalmente, devem desenvolver um modelo claro de partilha de custos para os serviços centrais, passando de subsídios de projeto para um modelo de financiamento operacional cooperativo semelhante ao WLCG (Worldwide LHC Computing Grid). A tecnologia está pronta; o desafio duradouro é sociotécnico.