1. Introdução
O consórcio PUNCH4NFDI (Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure), financiado pela Fundação Alemã de Pesquisa (DFG), representa aproximadamente 9.000 cientistas das comunidades de física de partículas, astrofísica, física de astropartículas, física hadrónica e física nuclear. Integrado na iniciativa mais ampla da NFDI, o seu principal objetivo é estabelecer uma plataforma federada de dados científicos FAIR (Findable, Accessible, Interoperable, Reusable). Esta plataforma visa fornecer acesso transparente aos diversos recursos de computação e armazenamento das instituições envolvidas, enfrentando os desafios comuns impostos pelos volumes de dados que crescem exponencialmente e pelos algoritmos de análise computacionalmente intensivos. Este documento centra-se nos conceitos arquitetónicos — Compute4PUNCH e Storage4PUNCH — concebidos para federar a infraestrutura de investigação heterogénea da Alemanha.
2. Infraestrutura Federada de Computação Heterogênea – Compute4PUNCH
O Compute4PUNCH aborda o desafio de utilizar eficazmente uma vasta gama de recursos contribuídos em espécie, incluindo sistemas de Computação de Alto Débito (HTC), Computação de Alto Desempenho (HPC) e Cloud, distribuídos pela Alemanha. Estes recursos variam em arquitetura, sistemas operativos, pilhas de software e políticas de acesso. O princípio de conceção central é criar um sistema de sobreposição unificado com intrusão mínima nos fornecedores de recursos operacionais existentes.
2.1. Arquitetura Central e Integração
A federação é construída em torno do HTCondor como o sistema de lote central de sobreposição. Os recursos heterogéneos são integrados dinamicamente utilizando o meta-agendador de recursos COBalD/TARDIS. O COBalD/TARDIS atua como um intermediário inteligente, pilotando tarefas para backends adequados (por exemplo, clusters Slurm, Kubernetes) com base na disponibilidade de recursos, requisitos das tarefas e políticas. Isto cria um único pool de recursos lógico a partir de sistemas fisicamente distintos.
2.2. Acesso do Utilizador e Ambiente de Software
Os pontos de entrada do utilizador são fornecidos através de nós de login tradicionais e de um serviço JupyterHub. Uma Infraestrutura de Autenticação e Autorização (AAI) baseada em tokens padroniza o acesso. A complexidade do ambiente de software é gerida através de tecnologias de contentores (por exemplo, Docker, Singularity/Apptainer) e do CERN Virtual Machine File System (CVMFS), que distribui repositórios de software escaláveis e só de leitura para os nós de computação a nível global.
3. Infraestrutura Federada de Armazenamento – Storage4PUNCH
O Storage4PUNCH visa federar sistemas de armazenamento fornecidos pela comunidade, baseados principalmente nas tecnologias dCache e XRootD, que estão bem estabelecidas na Física de Altas Energias (HEP). A federação emprega espaços de nomes e protocolos comuns (como xrootd, WebDAV) para apresentar uma camada unificada de acesso a dados. O conceito também avalia a integração de soluções de cache e serviços de gestão de metadados para melhorar a localidade e a capacidade de descoberta dos dados em toda a federação.
4. Implementação Técnica e Componentes
4.1. Autenticação e Autorização (AAI)
Uma AAI baseada em tokens (provavelmente alavancando os padrões OAuth 2.0/OpenID Connect, semelhante ao WLCG IAM ou INDIGO IAM) proporciona uma experiência de início de sessão único. Mapeia identidades da comunidade para permissões de recursos locais, abstraindo os sistemas de autenticação locais heterogéneos (por exemplo, Kerberos, chaves SSH).
4.2. Meta-agendamento de Recursos: COBalD/TARDIS
O COBalD (o Coordenador) e o TARDIS (o Transparent Adaptive Resource Dynamic Integration System) trabalham em conjunto. O COBalD toma decisões de agendamento de alto nível, enquanto o TARDIS gere o ciclo de vida de "pilotos" ou "tarefas de marcador de posição" nos recursos-alvo. Este desacoplamento permite a aplicação flexível de políticas (por exemplo, custo, equidade, prioridade) e a adaptação dinâmica a estados de recursos flutuantes. O agendamento pode ser modelado como um problema de otimização, minimizando uma função de custo $C_{total} = \sum_{i}(w_i \cdot T_i) + \lambda \cdot R$, onde $T_i$ é o tempo de processamento para a tarefa $i$, $w_i$ é o seu peso de prioridade, $R$ representa o custo de utilização do recurso e $\lambda$ é um parâmetro de equilíbrio.
4.3. Camada de Dados e Software
O CVMFS é crítico para a distribuição de software. Utiliza um modelo de armazenamento endereçável por conteúdo e cache agressivo (com servidores Stratum 0/1 e caches locais Squid) para distribuir repositórios de software de forma eficiente. A federação provavelmente emprega uma hierarquia de estratos CVMFS, com um estrato 0 central do repositório PUNCH e espelhos de estrato 1 institucionais. O acesso a dados segue um modelo federado semelhante, com elementos de armazenamento (SEs) a publicar os seus endpoints num diretório global (como Rucio ou um simples serviço REST), permitindo que os clientes resolvam as localizações dos dados de forma transparente.
5. Estado do Protótipo e Experiências Iniciais
O documento indica que os protótipos do Compute4PUNCH e do Storage4PUNCH estão operacionais. Aplicações científicas iniciais foram executadas, fornecendo feedback valioso sobre desempenho, usabilidade e pontos problemáticos de integração. Embora números de benchmark específicos não sejam fornecidos no excerto, a execução bem-sucedida implica que a funcionalidade básica do sistema de lote de sobreposição, a integração AAI e a entrega de software via CVMFS foram validadas. As experiências estão a orientar refinamentos na configuração de políticas, no tratamento de erros e na documentação do utilizador.
6. Principais Conclusões e Análise Estratégica
Conclusão Central: O PUNCH4NFDI não está a construir um novo supercomputador; está a conceber um "tecido de federação" que une pragmaticamente recursos existentes e fragmentados. Esta é uma mudança estratégica de uma infraestrutura monolítica para uma agregação de recursos ágil e definida por software, espelhando tendências na cloud comercial, mas adaptada às restrições e cultura da academia financiada publicamente.
Fluxo Lógico: A arquitetura segue uma lógica clara, orientada por dependências: 1) Unificar Identidade (AAI) para resolver o problema do "quem", 2) Abstrair Recursos (COBalD/TARDIS + HTCondor) para resolver o problema do "onde", e 3) Desacoplar Ambiente (Contentores + CVMFS) para resolver o problema do "com quê". Esta abstração em camadas é engenharia de sistemas clássica, reminiscente do sucesso da Worldwide LHC Computing Grid (WLCG), mas aplicada a um conjunto de recursos mais diversificado.
Pontos Fortes e Fracos: O principal ponto forte é o seu modelo de adoção não disruptivo. Ao utilizar tecnologias de sobreposição e respeitar a autonomia dos locais, reduz a barreira para os fornecedores de recursos — um fator de sucesso crucial para os consórcios. No entanto, este é também o seu calcanhar de Aquiles. A sobrecarga de desempenho do meta-agendamento e a complexidade inerente da depuração em sistemas heterogéneos e geridos de forma independente podem ser significativas. O mandato de "interferência mínima" pode limitar a capacidade de implementar funcionalidades avançadas, como o acoplamento profundo armazenamento-computação ou o provisionamento dinâmico de rede, potencialmente limitando os ganhos de eficiência. Em comparação com um sistema centralizado e construído para um propósito específico, como o Borg da Google ou um cluster Kubernetes, a federação terá sempre uma latência mais elevada e uma previsibilidade de utilização mais baixa.
Conclusões Acionáveis: Para outros consórcios que considerem este caminho: 1) Investir fortemente em monitorização e observabilidade desde o primeiro dia. Ferramentas como Grafana/Prometheus para a infraestrutura e APM (Application Performance Monitoring) para as tarefas dos utilizadores são não negociáveis para gerir a complexidade. 2) Padronizar um conjunto restrito de imagens base de contentores para reduzir a carga de manutenção do CVMFS. 3) Desenvolver um modelo de suporte claro e hierarquizado que distinga problemas ao nível da federação de problemas locais do local. O verdadeiro teste não será a viabilidade técnica — a comunidade HEP já provou isso — mas a sustentabilidade operacional e a satisfação do utilizador em escala.
7. Análise Técnica Aprofundada
Modelo Matemático para Agendamento de Recursos: O sistema COBalD/TARDIS pode ser conceptualizado como a resolução de um problema de otimização com restrições. Seja $J$ o conjunto de tarefas, $R$ o conjunto de recursos e $S$ o conjunto de estados dos recursos (por exemplo, inativo, ocupado, drenado). O agendador visa maximizar uma função de utilidade $U$ que considera a prioridade da tarefa $p_j$, a eficiência do recurso $e_{j,r}$ e o custo $c_r$: $$\max \sum_{j \in J} \sum_{r \in R} x_{j,r} \cdot U(p_j, e_{j,r}, c_r)$$ sujeito às restrições: $$\sum_{j} x_{j,r} \leq C_r \quad \forall r \in R \quad \text{(Capacidade do Recurso)}$$ $$\sum_{r} x_{j,r} \leq 1 \quad \forall j \in J \quad \text{(Atribuição da Tarefa)}$$ $$x_{j,r} \in \{0,1\} \quad \text{(Variável de Decisão Binária)}$$ onde $x_{j,r}=1$ se a tarefa $j$ for atribuída ao recurso $r$. O TARDIS gere dinamicamente a viabilidade das atribuições com base no estado em tempo real $S$.
Resultados Experimentais e Descrição do Diagrama: Embora o excerto do PDF fornecido não contenha gráficos de desempenho específicos, uma avaliação típica incluiria diagramas comparando:
1. Débito de Tarefas ao Longo do Tempo: Um gráfico de linhas mostrando o número de tarefas concluídas por hora no pool federado versus clusters de recursos individuais, demonstrando o benefício da agregação.
2. Mapa de Calor de Utilização de Recursos: Uma visualização em grelha mostrando a percentagem de CPUs/GPUs utilizados em diferentes fornecedores de recursos (KIT, DESY, Bielefeld, etc.) ao longo de uma semana, destacando a eficácia do balanceamento de carga.
3. CDF da Latência de Início da Tarefa: Um gráfico da Função de Distribuição Cumulativa comparando o tempo desde a submissão da tarefa até ao início da execução no sistema federado versus a submissão direta a um sistema de lote local, revelando a sobrecarga do meta-agendamento.
4. Desempenho de Acesso a Dados: Um gráfico de barras comparando velocidades de leitura/escrita para dados acedidos localmente, a partir de um elemento de armazenamento federado na mesma região e a partir de um elemento federado remoto, ilustrando o impacto da cache e da rede.
8. Estrutura de Análise e Modelo Conceptual
Estudo de Caso: Análise Federada de Dados de Levantamento Astronómico
Cenário: Um grupo de investigação na Thüringer Landessternwarte Tautenburg precisa de processar 1 PB de dados de imagem do Sloan Digital Sky Survey (SDSS) para identificar aglomerados de galáxias, uma tarefa computacionalmente intensiva que requer ~100.000 horas de CPU.
Processo via Compute4PUNCH/Storage4PUNCH:
1. Autenticação: O investigador inicia sessão no JupyterHub do PUNCH utilizando as suas credenciais institucionais (através da AAI baseada em tokens).
2. Ambiente de Software: O kernel do seu notebook Jupyter é executado a partir de uma imagem de contentor alojada no CVMFS, contendo todos os pacotes de astronomia necessários (Astropy, SExtractor, etc.).
3. Definição e Submissão da Tarefa: Eles definem uma tarefa de varredura de parâmetros no notebook. O notebook utiliza uma biblioteca cliente PUNCH para submeter estas como um DAG (Directed Acyclic Graph) do HTCondor para o pool federado.
4. Correspondência de Recursos e Execução: O COBalD/TARDIS avalia os requisitos da tarefa (CPU, memória, possivelmente GPU) e pilota-as para slots disponíveis em, por exemplo, pools HTC no KIT, filas HPC na Universidade de Bielefeld e nós cloud no DESY. As tarefas leem os dados de entrada através do espaço de nomes XRootD federado a partir da localização de armazenamento mais próxima, possivelmente alavancando uma cache.
5. Agregação de Resultados: Os ficheiros de saída são escritos de volta para o armazenamento federado. O investigador monitoriza o progresso através de um painel web unificado e finalmente agrega os resultados no seu notebook para análise.
Este caso demonstra a integração transparente de identidade, computação, armazenamento e gestão de software.
9. Aplicações Futuras e Roteiro de Desenvolvimento
A infraestrutura PUNCH4NFDI estabelece as bases para várias aplicações avançadas:
1. Treino Federado de Aprendizagem Automática: O pool de recursos heterogéneo, incluindo potenciais clusters de GPU, poderia suportar frameworks de treino ML distribuídos como PyTorch ou TensorFlow através de fronteiras institucionais, abordando necessidades de treino que preservam a privacidade onde os dados não podem ser centralizados.
2. Análise e Visualização Interativa: Melhorar o serviço JupyterHub com ferramentas de visualização interativa escaláveis e alimentadas por backend (por exemplo, widgets Jupyter conectados a clusters Dask na federação) para exploração de grandes conjuntos de dados.
3. Integração com Clouds Externas e Centros HPC: Estender o modelo de federação para incorporar créditos de cloud comercial (por exemplo, AWS, GCP) ou centros nacionais de supercomputação (por exemplo, JUWELS no JSC) através de uma camada comum de faturação/contabilização, criando uma verdadeira cloud híbrida para a ciência.
4. Integração de Metadados e Data Lake: Ir além da simples federação de ficheiros para uma arquitetura integrada de data lake, onde a camada de armazenamento é acoplada a um catálogo de metadados unificado (por exemplo, baseado em Rucio ou iRODS), permitindo a descoberta de dados e o rastreamento de proveniência entre comunidades.
5. Workflow-as-a-Service: Oferecer serviços de plataforma de nível superior como REANA (Reproducible Analysis Platform) ou Apache Airflow sobre a infraestrutura federada, permitindo que os cientistas definam e executem pipelines de análise complexos e reproduzíveis sem gerir a infraestrutura subjacente.
O roteiro de desenvolvimento provavelmente focar-se-á em consolidar o serviço de produção, expandir o pool de recursos, integrar ferramentas de gestão de dados mais sofisticadas e desenvolver APIs e SDKs amigáveis para reduzir a barreira de adoção para utilizadores não especialistas.
10. Referências
- Consórcio PUNCH4NFDI. (2024). PUNCH4NFDI White Paper. [Documento Interno do Consórcio].
- Thain, D., Tannenbaum, T., & Livny, M. (2005). Distributed computing in practice: the Condor experience. Concurrency - Practice and Experience, 17(2-4), 323-356. https://doi.org/10.1002/cpe.938
- Blomer, J., et al. (2011). Distribution of software in the CernVM file system with Parrot. Journal of Physics: Conference Series, 331(4), 042009. https://doi.org/10.1088/1742-6596/331/4/042009
- Giffels, M., et al. (2022). COBalD and TARDIS – Dynamic resource overlay for opportunistic computing. EPJ Web of Conferences, 251, 02009. https://doi.org/10.1051/epjconf/202225102009
- Colaboração dCache. (2023). dCache: A distributed storage data caching system. Obtido de https://www.dcache.org/
- Colaboração XRootD. (2023). XRootD: High performance, scalable fault tolerant access to data. Obtido de http://xrootd.org/
- Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3, 160018. https://doi.org/10.1038/sdata.2016.18
- Verma, A., et al. (2015). Large-scale cluster management at Google with Borg. Proceedings of the Tenth European Conference on Computer Systems (EuroSys '15). https://doi.org/10.1145/2741948.2741964