Infraestrutura Federada de Computação e Armazenamento Heterogênea para o PUNCH4NFDI

1. Introdução

O PUNCH4NFDI (Partículas, Universo, Núcleos e Hadrões para a Infraestrutura Nacional de Dados de Investigação) é um grande consórcio alemão 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 objetivo principal do consórcio é estabelecer uma plataforma federada de dados científicos FAIR (Findable, Accessible, Interoperable, Reusable). Esta contribuição detalha especificamente os conceitos arquitetónicos — Compute4PUNCH e Storage4PUNCH — concebidos para unificar o acesso aos recursos altamente heterogéneos de computação (HPC, HTC, Cloud) e armazenamento, contribuídos em espécie pelas instituições membro em toda a Alemanha.

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

A iniciativa Compute4PUNCH aborda o desafio de fornecer acesso transparente a um conjunto diversificado de recursos de computação existentes, sem impor grandes alterações aos modelos operacionais dos fornecedores de recursos.

3. Infraestrutura Federada de Armazenamento – Storage4PUNCH

O Storage4PUNCH visa federar sistemas de armazenamento comunitários, baseados principalmente nas tecnologias dCache e XRootD, que estão bem estabelecidas na Física de Altas Energias (HEP).

4. Detalhes Técnicos e Enquadramento Matemático

A lógica central de agendamento no COBalD/TARDIS pode ser modelada como um problema de otimização. Seja $R = \{r_1, r_2, ..., r_n\}$ o conjunto de pedidos de recursos da pool HTCondor, e $B = \{b_1, b_2, ..., b_m\}$ o conjunto de tipos de recursos de backend disponíveis (ex.: nó HPC, VM Cloud). Cada pedido $r_i$ tem requisitos (cores, memória, software). Cada backend $b_j$ tem uma função de custo $C_j(r_i)$ e um tempo de provisionamento $T_j(r_i)$.

O objetivo do meta-agendador é encontrar um mapeamento $M: R \rightarrow B$ que minimize uma função de custo total, frequentemente uma soma ponderada do custo financeiro e do tempo de conclusão, sujeito a restrições como quotas de backend e disponibilidade de software:

$$\min_{M} \sum_{r_i \in R} \left[ \alpha \cdot C_{M(r_i)}(r_i) + \beta \cdot T_{M(r_i)}(r_i) \right]$$

onde $\alpha$ e $\beta$ são fatores de ponderação. Isto formaliza o desafio de integração "dinâmico e transparente".

5. Resultados do Protótipo e Desempenho

O artigo relata experiências iniciais com aplicações científicas a correr em protótipos disponíveis. Embora benchmarks quantitativos específicos não sejam detalhados no excerto fornecido, a execução bem-sucedida implica:

• Integração Funcional: A stack HTCondor/COBalD/TARDIS encaminhou com sucesso jobs para diferentes sistemas de backend (HTC, HPC, Cloud).
• Fornecimento de Software: O CVMFS e os contentores forneceram de forma fiável os ambientes de software necessários através de nós de trabalho heterogéneos.
• Acesso do Utilizador: O JupyterHub e os nós de login serviram como pontos de entrada eficazes para os investigadores.

Diagrama Conceptual: A arquitetura do sistema pode ser visualizada como um modelo de três camadas:

1. Camada de Acesso do Utilizador: JupyterHub, Nós de Login, AAI de Token.
2. Camada de Federação e Agendamento: Pool HTCondor + Meta-agendador COBalD/TARDIS.
3. Camada de Recursos: Backends heterogéneos (clusters HPC, farms HTC, VMs Cloud) e armazenamento federado (instâncias dCache, XRootD).

6. Enquadramento de Análise: Um Cenário de Caso de Uso

Cenário: Um investigador de física nuclear precisa de processar 10.000 tarefas de simulação de Monte Carlo, cada uma exigindo 4 núcleos de CPU, 16 GB de RAM e uma stack de software específica (Geant4, ROOT).

1. Submissão: O investigador faz login no JupyterHub do PUNCH, escreve um script de análise e submete 10.000 jobs para o agendador HTCondor local.
2. Meta-Agendamento: O COBalD/TARDIS monitoriza a fila do HTCondor. Avalia os backends disponíveis: a farm HTC da Universidade A (baixo custo, tempo de fila elevado), o cluster HPC do Instituto B (custo moderado, hardware especializado) e uma cloud comercial (custo elevado, disponibilidade imediata).
3. Decisão e Execução: Usando o seu modelo de custo, o TARDIS pode decidir lançar 2.000 jobs imediatos para a cloud para começar rapidamente, enquanto drena constantemente o resto na farm HTC mais barata. Utiliza o AAI de token para autenticação em todos os sistemas.
4. Software e Dados: Cada job, independentemente do backend, obtém o seu ambiente Geant4/ROOT do CVMFS. Os dados de entrada são obtidos do espaço de nomes federado Storage4PUNCH (ex.: via XRootD), e a saída é escrita de volta para um endpoint de armazenamento designado.
5. Conclusão: O investigador monitoriza e agrega resultados da única fila de jobs do HTCondor, alheio à execução multi-infraestrutura subjacente.

7. Análise Crítica e Perspetiva de Especialista

Ideia Central: O PUNCH4NFDI não está a construir outra cloud; está a conceber uma camada de federação de notável pragmatismo político e técnico. A sua verdadeira inovação reside no meta-agendador COBalD/TARDIS, que atua como um "tradutor diplomático" para a partilha de recursos, não como um unificador conquistador. Isto reconhece a soberania dos clusters institucionais existentes — uma realidade não negociável na academia alemã — enquanto ainda cria um supra-recurso funcional.

Fluxo Lógico: A lógica é impecável: começar com o utilizador (JupyterHub/login), abstrair o caos através de um agendador testado em batalha (HTCondor), depois usar um intermediário inteligente (TARDIS) para mapear pedidos abstratos em backends concretos e politicamente viáveis. A dependência do CVMFS e dos contentores para o software é um golpe de mestre, resolvendo o problema do "inferno das dependências" que assola a maioria das federações. A estratégia de armazenamento é sabiamente conservadora, construindo sobre a dupla comprovada dCache/XRootD da HEP, evitando o atoleiro de tentar forçar uma única tecnologia nova.

Pontos Fortes e Fracos:

• Pontos Fortes: A invasão mínima é o seu superpoder. Não exige que os fornecedores alterem as suas políticas locais. A utilização de ferramentas maduras e orientadas pela comunidade (HTCondor, CVMFS, dCache) reduz drasticamente o risco e aumenta a sustentabilidade, ao contrário de projetos construídos sobre frameworks personalizados. O foco nos princípios FAIR alinha-se perfeitamente com os mandatos de financiamento modernos.
• Fracos e Riscos: A abordagem do meta-agendador introduz um ponto único de complexidade e potencial falha. O COBalD/TARDIS, embora promissor, não é tão testado em batalha como os outros componentes. A "avaliação" da tecnologia de cache/metadados (como o Rucio) sugere que a parte mais difícil está à frente: a gestão inteligente de dados. Sem ela, isto é uma federação de computação com um diretório de armazenamento anexado, não uma plataforma coesa centrada em dados. Há também um risco latente de imprevisibilidade de desempenho para os utilizadores, à medida que os seus jobs saltam entre arquiteturas fundamentalmente diferentes.

Insights Acionáveis:

1. Para os Arquitetos do PUNCH: Reforcem a robustez e observabilidade do TARDIS. As suas métricas e registos de decisão são ouro para otimização e construção de confiança. Priorizem a integração de uma camada de gestão de dados (como o Rucio) a seguir; computação sem dados inteligentes é meia solução.
2. Para Outros Consórcios: Este é um modelo digno de emulação, especialmente a filosofia de "integração sobre substituição". No entanto, avaliem se a vossa comunidade tem um equivalente ao CVMFS — se não, essa é a vossa primeira decisão de construir/comprar.
3. Para Fornecedores de Recursos: Este modelo é de baixo risco para vocês. Envolvam-se com ele. O AAI baseado em tokens é uma forma limpa de oferecer acesso sem comprometer a segurança local. É um ganho líquido em termos de visibilidade e utilização.

8. Aplicações Futuras e Roteiro de Desenvolvimento

A infraestrutura PUNCH4NFDI estabelece as bases para várias aplicações avançadas e direções de investigação:

• Fluxos de Trabalho Transdomínio: Permitir pipelines de análise complexos e multi-etapa que se movem de forma transparente entre simulação (HPC), processamento de eventos de alto débito (HTC) e treino de machine learning (GPUs Cloud).
• Agendamento Centrado em Dados: Integrar a federação de armazenamento mais profundamente com o agendador de computação. Versões futuras do COBald/TARDIS poderiam fatorar a localidade dos dados (minimizando transferências WAN) e pré-posicionamento na sua função de custo, caminhando para um agendamento consciente dos dados.
• Integração com Repositórios de Dados FAIR: Servir como a espinha dorsal de computação de alto desempenho para repositórios nacionais de dados FAIR, permitindo que os investigadores analisem grandes conjuntos de dados diretamente onde estão armazenados, seguindo o paradigma "computação para os dados".
• AI/ML como Serviço: A interface JupyterHub e o backend escalável poderiam ser estendidos com ambientes curados para frameworks especializados de AI/ML (PyTorch, TensorFlow) e acesso a recursos GPU, democratizando a IA para as ciências físicas.
• Expansão para Recursos Internacionais: O modelo de federação poderia ser estendido para incorporar recursos de iniciativas europeias como a European Open Science Cloud (EOSC) ou sites da grelha de computação do LHC (WLCG), criando uma verdadeira infraestrutura de investigação pan-europeia.

O roteiro provavelmente envolve consolidar o protótipo atual, escalar o número de recursos integrados, implementar as soluções de metadados/cache avaliadas e desenvolver mecanismos de política e contabilização mais sofisticados para a utilização de recursos de partilha justa em todo o consórcio.

9. Referências

1. Consórcio PUNCH4NFDI. (2024). PUNCH4NFDI White Paper. [Documento Interno do Consórcio].
2. Thain, D., Tannenbaum, T., & Livny, M. (2005). Distributed computing in practice: the Condor experience. Concurrency and computation: practice and experience, 17(2-4), 323-356.
3. Blomer, J., et al. (2011). The CernVM file system. Journal of Physics: Conference Series, 331(5), 052004.
4. COBalD/TARDIS Documentation. (n.d.). Retrieved from https://tardis.readthedocs.io/
5. dCache Collaboration. (n.d.). dCache: A distributed storage system. https://www.dcache.org/
6. XRootD Collaboration. (n.d.). XRootD: High performance, scalable fault tolerant access to data. http://xrootd.org/
7. Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific data, 3(1), 1-9.
8. European Open Science Cloud (EOSC). (n.d.). https://eosc-portal.eu/
9. Worldwide LHC Computing Grid (WLCG). (n.d.). https://wlcg.web.cern.ch/