Se os trabalhos demoram mais do que a conta de processamento sugere, o problema costuma estar em outro lugar.
Existe um sintoma que aparece em quase todo cluster de pesquisa depois de algum tempo de uso: o trabalho demora mais do que deveria, e ninguém consegue explicar por quê.
A CPU não está saturada. A GPU fica ociosa em pedaços. A memória sobra. E ainda assim o resultado sai devagar.
Na maior parte das vezes, o gargalo está no armazenamento.
Um cluster tem dezenas ou centenas de processos rodando ao mesmo tempo. Em um sistema de arquivos comum, todos eles pedem dado ao mesmo servidor.
Enquanto a capacidade de cálculo cresceu de forma acelerada nos últimos anos, o caminho até o dado nem sempre acompanhou. O resultado é um ambiente caro que passa boa parte do tempo esperando leitura e escrita.
Um cluster com centenas de núcleos não adianta se todos eles esperam na fila pelo mesmo arquivo.
O último item é o teste mais revelador. Se mover o dado para perto resolve, o problema é o caminho até ele.
Em vez de guardar cada arquivo inteiro em um servidor, um sistema de arquivos paralelo divide o arquivo em pedaços e distribui esses pedaços entre vários servidores de armazenamento.
Quando um processo pede o arquivo, ele chega de várias fontes ao mesmo tempo, somando a banda de todas elas. Precisa de mais desempenho? Acrescenta servidor, e a capacidade e a velocidade crescem juntas.
Existe uma segunda camada do problema que passa despercebida: a estrutura de diretórios e permissões.
Aplicação que abre milhões de arquivos pequenos, comum em bioinformática e em processamento de imagem, sofre menos com o volume de dado e mais com a quantidade de operações de abertura. Sistemas paralelos como o BeeGFS separam os metadados do conteúdo e distribuem também essa camada, e é isso que evita o estrangulamento.
O BeeOND cria um sistema de arquivos temporário usando os discos dos próprios nós reservados para um trabalho. Ele nasce quando o trabalho começa e desaparece quando ele termina.
Serve como área de rascunho ultrarrápida para simulações que geram muito arquivo intermediário, tirando essa carga do armazenamento principal. Para grupos que rodam trabalhos com muita escrita temporária, costuma ser o ganho de desempenho mais barato disponível, porque aproveita disco que já existe.
Aplicação que lê milhões de arquivos pequenos pede uma configuração. Simulação que escreve poucos arquivos gigantes pede outra. O ajuste é feito sobre o uso real, não sobre o catálogo.
Se o cluster está lento, o instinto costuma ser acrescentar capacidade de cálculo. Vale medir antes.
Acrescentar nós a um ambiente limitado por armazenamento piora a situação: mais processos disputando o mesmo caminho até o dado. O investimento vai para o lugar errado e o problema aumenta.
Medir o perfil de leitura e escrita das aplicações do grupo é barato e responde a pergunta em pouco tempo.
A PerfilGlobal projeta, importa e implanta infraestrutura de supercomputação para pesquisa científica no Brasil.