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

1. Introdução

O Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure (PUNCH4NFDI) é 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, física hadrónica e física nuclear. O objetivo principal do consórcio é estabelecer uma plataforma federada de dados científicos FAIR (Findable, Accessible, Interoperable, Reusable). Esta plataforma visa fornecer acesso transparente aos diversos e heterogéneos recursos de computação e armazenamento distribuídos pelas instituições participantes, abordando os desafios comuns dos volumes massivos de dados e dos algoritmos complexos e intensivos em recursos. Este documento centra-se nos conceitos arquitetónicos — Compute4PUNCH e Storage4PUNCH — desenvolvidos para federar estes recursos contribuídos em espécie.

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

O conceito Compute4PUNCH aborda o desafio de fornecer acesso unificado a uma vasta gama de recursos existentes de Computação de Alto Débito (HTC), Computação de Alto Desempenho (HPC) e Cloud, contribuídos por várias instituições. Estes recursos diferem em arquitetura, sistema operativo, software e autenticação. A principal restrição é minimizar alterações aos sistemas operacionais existentes, partilhados por múltiplas comunidades.

2.1 Arquitetura Central e Estratégia de Integração

A estratégia emprega um sistema de lote federado sobreposto. Em vez de modificar os gestores de recursos locais (como SLURM, PBS), é criado um pool sobreposto baseado em HTCondor. O meta-agendador de recursos COBalD/TARDIS integra dinâmica e transparentemente backends heterogéneos (clusters HPC, farms HTC, VMs cloud) neste pool unificado. Atua como um sistema "piloto", submetendo trabalhos de reserva para reivindicar recursos e depois implementando as cargas de trabalho reais do utilizador.

2.2 Acesso do Utilizador e Ambiente de Software

O acesso é fornecido através de nós de login tradicionais e de um serviço JupyterHub, que servem como pontos de entrada centrais. 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 (Docker, Singularity/Apptainer) e do CERN Virtual Machine File System (CVMFS), que fornece pilhas de software pré-configuradas e específicas da comunidade de forma escalável e só de leitura.

3. Infraestrutura Federada de Armazenamento – Storage4PUNCH

O Storage4PUNCH visa federar sistemas de armazenamento fornecidos pela comunidade, baseados principalmente nas tecnologias dCache ou XRootD, que são bem estabelecidas na Física de Altas Energias (HEP). A federação cria um espaço de nomes comum e uma camada de acesso. O conceito também avalia tecnologias existentes para caching (para reduzir latência e tráfego WAN) e gestão de metadados, visando uma integração mais profunda para facilitar a descoberta e gestão de dados através do armazenamento federado.

4. Implementação Técnica e Componentes Centrais

4.1 Federação de Computação: HTCondor e COBalD/TARDIS

HTCondor: Fornece a camada de gestão de trabalhos, filas e agendamento dentro do pool federado. O seu mecanismo ClassAd permite combinar requisitos complexos de trabalhos com propriedades dinâmicas dos recursos.
COBalD/TARDIS: Situa-se entre o HTCondor e os backends heterogéneos. O TARDIS traduz "pilotos" do HTCondor em comandos de submissão específicos do backend (por exemplo, um script de trabalho SLURM). O COBalD implementa a lógica de decisão sobre quando e onde lançar estes pilotos com base em política, custo e estado das filas. A função central pode ser modelada como um problema de otimização: $\text{Maximizar } U = \sum_{r \in R} (w_r \cdot u_r(\text{alloc}_r)) \text{ sujeito a } \text{alloc}_r \leq \text{cap}_r, \forall r \in R$, onde $U$ é a utilidade total, $R$ é o conjunto de tipos de recursos, $w_r$ é um peso, $u_r$ é uma função de utilidade para o tipo de recurso $r$, $\text{alloc}_r$ é a capacidade alocada e $\text{cap}_r$ é a capacidade total.

4.2 Federação de Armazenamento: dCache e XRootD

dCache: Um sistema de gestão hierárquica de armazenamento, frequentemente usado como frontend para arquivos de fita. Fornece interfaces do tipo POSIX (NFS, WebDAV) e protocolos específicos da HEP (xrootd, gridftp).
XRootD: Um protocolo e conjunto de ferramentas para acesso a dados escalável e tolerante a falhas. O seu componente "redirector" permite construir federações onde uma consulta do cliente é direcionada para o servidor de dados apropriado.
A federação cria uma camada lógica que apresenta múltiplas instâncias físicas como um único sistema, crucial para o agendamento com consciência da localidade dos dados.

4.3 Distribuição de Software e Dados: Contentores e CVMFS

Contentores: Garantem ambientes de software reproduzíveis em diversos sistemas hospedeiros. Encapsulam dependências complexas (por exemplo, versões específicas de ROOT, Geant4).
CVMFS: Um sistema de ficheiros global e distribuído para distribuição de software. Utiliza HTTP e caching agressivo. O seu conteúdo é publicado uma vez e fica disponível em todo o lado, resolvendo o problema da implementação de software em larga escala. O processo de publicação envolve um servidor "estrato 0" e replicação para espelhos "estrato 1".

5. Estado do Protótipo e Experiências Iniciais

O artigo relata que os protótipos para o Compute4PUNCH e o Storage4PUNCH foram implementados. Aplicações científicas iniciais foram executadas com sucesso nos protótipos disponíveis, demonstrando a viabilidade dos conceitos. Métricas de desempenho específicas ou estudos de caso detalhados não são fornecidos no resumo, mas a execução bem-sucedida valida a abordagem de integração e a pilha tecnológica escolhida.

7. Análise Original: Ideia Central, Fluxo Lógico, Pontos Fortes e Fracos, Conclusões Práticas

Ideia Central: O PUNCH4NFDI não está a construir um novo supercomputador; está a orquestrar uma sinfonia de instrumentos existentes e díspares. A sua verdadeira inovação reside na meta-camada — o "maestro da orquestra" composto pelo COBalD/TARDIS e pelos protocolos de federação — que cria um pool de recursos unificado sem exigir homogeneidade dos fornecedores subjacentes. Este é um golpe de mestre estratégico para colaborações multi-institucionais politicamente complexas, reminiscente do paradigma de aprendizagem federada em IA (como no trabalho da Google sobre Federated Averaging) onde os dados permanecem distribuídos, mas os modelos são agregados.

Fluxo Lógico: A arquitetura segue uma separação clara de responsabilidades. 1) Acesso e Identidade: A AAI baseada em tokens autentica os utilizadores. 2) Abstração de Computação: O utilizador submete um trabalho ao HTCondor. O COBalD/TARDIS monitoriza as filas, decide qual backend (por exemplo, um cluster HPC de uma universidade) tem capacidade e implementa um trabalho piloto para "reivindicar" esses recursos para o pool HTCondor. O trabalho real do utilizador é então executado dentro deste piloto. 3) Ambiente de Software: O trabalho obtém a sua pilha de software específica via CVMFS ou de um registo de contentores. 4) Acesso a Dados: O trabalho lê/escreve dados através da camada de armazenamento federada (dCache/XRootD), que redireciona os pedidos para a localização real dos dados.

Pontos Fortes e Fracos: O ponto forte é um pragmatismo inegável. Ao envolver sistemas existentes, consegue uma implementação rápida e a adesão dos proprietários dos recursos. O uso de uma pilha tecnológica comprovada pela HEP (validada pelo sucesso da Worldwide LHC Computing Grid do CERN) é um grande mitigador de risco. No entanto, as fraquezas residem na complexidade inerente da camada de meta-agendamento. O COBalD/TARDIS deve tomar decisões inteligentes de provisionamento através de sistemas heterogéneos com políticas, custos (por exemplo, créditos cloud) e perfis de desempenho diferentes. Uma política mal ajustada pode levar a uma utilização ineficiente dos recursos ou à inanição de trabalhos. Além disso, embora a federação de armazenamento forneça acesso unificado, funcionalidades avançadas de gestão de dados como indexação de espaço de nomes global, federação de catálogos de metadados e colocação inteligente de dados (semelhante a ideias no sistema de ficheiros paralelo Lustre ou em investigação sobre tiering automático de dados) parecem ser itens de avaliação futura, representando uma limitação atual.

Conclusões Práticas: Para outros consórcios (por exemplo, em bioinformática ou ciências climáticas), a lição é investir fortemente no meta-agendador e no design da camada de abstração desde o primeiro dia. A abordagem PUNCH sugere começar com uma federação mínima viável usando uma tecnologia estável como o HTCondor, em vez de tentar uma construção do zero. Os fornecedores de recursos devem ser envolvidos com requisitos claros e mínimos, semelhantes a APIs (por exemplo, "deve suportar SSH ou um comando específico do sistema de lote"). Crucialmente, o projeto deve desenvolver ferramentas robustas de monitorização e auditoria para a própria camada federada — compreender a utilização entre locais e diagnosticar falhas nesta cadeia complexa será de importância operacional máxima. O roteiro futuro deve abordar explicitamente a integração de gestores de fluxo de trabalho (como Nextflow ou Apache Airflow) e o desenvolvimento dos serviços de caching e metadados avaliados para passar de uma federação simples para uma logística de dados inteligente e otimizada para o desempenho.

8. Detalhes Técnicos e Enquadramento Matemático

O problema de alocação de recursos abordado pelo COBalD/TARDIS pode ser enquadrado como uma otimização online. Seja $Q(t)$ a fila de trabalhos pendentes no HTCondor no tempo $t$, cada um com tempo de execução estimado $\hat{r}_i$ e vetor de pedido de recursos $\vec{c}_i$ (CPU, memória, GPU). Seja $B$ o conjunto de backends, cada um com uma capacidade disponível variável no tempo $\vec{C}_b(t)$ e uma função de custo $f_b(\vec{c}, \Delta t)$ para alocar recursos $\vec{c}$ durante a duração $\Delta t$. O objetivo do meta-agendador é minimizar o tempo médio de conclusão dos trabalhos $T_{ta}$ respeitando as políticas dos backends e uma restrição orçamental. Uma regra de decisão heurística simplificada para lançar um piloto no backend $b$ poderia ser: $\text{Lançar se } \frac{|\{j \in Q(t): \vec{c}_j \preceq \vec{C}_b(t)\}|}{\text{Custo}_b} > \theta$, onde $\preceq$ denota "cabe dentro", $\text{Custo}_b$ é um custo normalizado e $\theta$ é um limiar. Isto captura o compromisso entre a procura na fila e o custo de provisionamento.

9. Resultados Experimentais e Métricas do Protótipo

Embora o resumo do PDF fornecido não inclua resultados quantitativos específicos, um protótipo bem-sucedido implica resultados qualitativos chave e potenciais resultados quantitativos:

• Sucesso Funcional: Capacidade demonstrada de submeter um único trabalho via HTCondor/JupyterHub e tê-lo executado de forma transparente num recurso HPC ou HTC remoto, com software do CVMFS e dados do armazenamento federado.
• Métricas Chave a Acompanhar (Futuro):
  • Taxa de Sucesso de Trabalhos: Percentagem de trabalhos que terminam com sucesso através da federação.
  • Tempo Médio de Espera: Tempo desde a submissão até ao início, comparado com as filas nativas dos backends.
  • Utilização de Recursos: Horas de CPU agregadas fornecidas através do pool federado.
  • Eficiência de Transferência de Dados: Débito e latência para trabalhos que acedem a armazenamento remoto através da camada de federação.
• Descrição do Diagrama: Um diagrama de arquitetura conceptual mostraria: Utilizadores a interagir com JupyterHub/Nós de Login. Estes ligam-se a um Gestor Central HTCondor. O componente COBalD/TARDIS interage tanto com o HTCondor como com múltiplos Backends de Recursos (Cluster HPC A, Farm HTC B, Cloud C). Cada backend tem um sistema de lote local (SLURM, PBS, etc.). Setas indicam submissão de trabalhos e implementação de pilotos. Uma secção separada mostra Armazenamento Federado (instâncias dCache, XRootD) ligado aos backends e acessível pelos trabalhos. Espelhos CVMFS Estrato 1 são mostrados como uma camada acessível por todos os backends.

10. Enquadramento de Análise: Exemplo Conceptual de Fluxo de Trabalho

Cenário: Um físico de astropartículas precisa de processar 1.000 imagens de telescópio usando um pipeline de análise complexo e personalizado (baseado em Python/ROOT).

1. Entrada do Utilizador: O investigador faz login no JupyterHub do PUNCH.
2. Configuração do Ambiente: Num notebook Jupyter, seleciona um kernel pré-definido suportado por um contentor Singularity que contém a sua pilha de software específica (publicada no CVMFS).
3. Definição do Trabalho: Escreve um script que define a tarefa de análise e usa uma biblioteca auxiliar do PUNCH para criar uma descrição de submissão HTCondor, especificando CPUs, memória e referências de dados de entrada necessárias (por exemplo, `root://fed-storage.punch.org/path/to/images_*.fits`).
4. Submissão e Agendamento: O trabalho é submetido ao pool HTCondor. O COBalD/TARDIS, vendo 1.000 trabalhos curtos, decide lançar múltiplos trabalhos piloto numa farm de alto débito (Backend B) com cache de armazenamento local rápido para os dados de entrada.
5. Execução: Os pilotos reivindicam slots no Backend B. Cada piloto obtém o contentor, busca os seus ficheiros de entrada atribuídos através da federação XRootD (que pode redirecionar para uma cache local), executa a análise e escreve os resultados de volta para o armazenamento federado.
6. Conclusão: O HTCondor agrega o estado de conclusão dos trabalhos. O notebook do investigador pode agora consultar e visualizar os resultados a partir da localização de armazenamento de saída.

Este exemplo destaca a abstração completa: o utilizador nunca precisou de saber sobre comandos SLURM no Backend B, como instalar o ROOT lá, ou a localização física dos ficheiros de dados.

11. Aplicações Futuras e Roteiro de Desenvolvimento

A infraestrutura PUNCH4NFDI prepara o terreno para aplicações transformadoras:

• Fluxos de Trabalho de Astrofísica Multi-Mensageira: Análises de correlação em tempo real entre dados de observatórios de ondas gravitacionais (LIGO/Virgo), neutrinos (IceCube) e eletromagnéticos, exigindo computação urgente através de recursos geograficamente distribuídos.
• Treino de Modelos AI/ML em Escala: Experiências de aprendizagem federada onde o próprio processo de treino é distribuído pela federação de computação, com modelos agregados centralmente — um paralelo computacional à federação de dados.
• Gémeos Digitais de Experiências Complexas: Executar conjuntos massivos de simulações para criar contrapartes digitais de detetores de partículas ou conjuntos de telescópios, aproveitando HPC para simulação e HTC para varrimentos de parâmetros.

Roteiro de Desenvolvimento:

1. Curto Prazo (1-2 anos): Consolidar a implementação de nível de produção dos serviços centrais do Compute4PUNCH e Storage4PUNCH. Integrar monitorização avançada (Prometheus/Grafana) e ferramentas de faturação/contabilização.
2. Médio Prazo (3-4 anos): Implementar e integrar os serviços de caching e catálogo global de metadados avaliados. Desenvolver uma integração mais apertada com sistemas de gestão de fluxo de trabalho. Explorar "rebentamento" (bursting) para clouds comerciais durante picos de procura.
3. Longo Prazo (5+ anos): Evoluir para um "intelligent data lakehouse" para a ciência PUNCH, incorporando descoberta de dados, rastreio de proveniência e gestão automatizada do ciclo de vida de dados alimentada pelos metadados federados. Servir como um modelo para outros consórcios NFDI e colaborações internacionais.

12. Referências

1. Consórcio PUNCH4NFDI. (2024). PUNCH4NFDI White Paper. [Documentação Oficial 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. https://doi.org/10.1002/cpe.938
3. Krebs, K., et al. (2022). COBalD/TARDIS – A dynamic resource provisioning framework for heterogeneous computing environments. Journal of Physics: Conference Series, 2438(1), 012045. (Referência para o meta-agendador).
4. Blomer, J., et al. (2011). The CernVM File System. Journal of Physics: Conference Series, 331(5), 052004. https://doi.org/10.1088/1742-6596/331/5/052004
5. Colaboração dCache. (2023). dCache.org [Software e Documentação]. https://www.dcache.org
6. Colaboração XRootD. (2023). XRootD Documentation. http://xrootd.org/docs.html
7. McMahan, B., Moore, E., Ramage, D., Hampson, S., & y Arcas, B. A. (2017). Communication-Efficient Learning of Deep Networks from Decentralized Data. Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS). (Citado para analogia com aprendizagem federada).
8. Organização Europeia para a Investigação Nuclear (CERN). (2023). Worldwide LHC Computing Grid (WLCG). https://wlcg.web.cern.ch (Citado como precedente para federação em larga escala).