Sou usuário de um cluster que usa NFS para nossas necessidades de armazenamento de dados. Recentemente, tenho executado um pipeline que possui E/S muito alta durante algumas operações.
O programa que acreditamos estar causando o problema se chama Bowtie, um alinhador em pipelines de bioinformática. Resumindo temos sequências alfabéticas em arquivos fragmentados de 1 milhão de linhas por arquivo que são comparados a outro arquivo contendo o dicionário inteiro. (Esta é uma simplificação exagerada do algoritmo)
Este dicionário é mapeado na memória durante o procedimento. Tenho direitos de envio de fila para três nós no cluster.
Nós: Nó1 Nó2 Nó3 Nó4 Nó5 Nó6 Nó7
Meu direito: Node1 Node2 Node3
Número de processadores disponíveis para mim: 128 processadores ou 128 slots de fila em execução.
Para rodar no cluster, o arquivo principal é dividido em Chunks de 1 milhão de linhas cada e então todos os jobs são iniciados utilizando SGE.
O Dicionário neste ponto é carregado na memória em cada nó, ou seja, Nó1 2 e 3
Para cada trabalho ativo no slot da fila, tenho os seguintes manipuladores de arquivos abertos
1 arquivo de trabalho contendo o código para executar 1 arquivo de código contendo o código de saída do processo 1 arquivo STDOUT gerado por SGE 1 arquivo STDERR gerado por SGE 1 pedaço de arquivo 1 arquivo de saída
O que significa que durante esse processo tenho 768+3 manipuladores de arquivos abertos no armazenamento remoto de dados, embora os primeiros quatro arquivos sejam constantes para cada script no pipeline.
Sempre que isso acontece, o servidor NFS no armazenamento de dados trava e todo o nosso cluster fica inativo porque o armazenamento deixa de responder.
Nosso pessoal de TI sugeriu que isso pode ser devido à alta E/S durante esse processo e possivelmente o NFS só foi planejado para clusters pequenos e não para clusters de grande escala.
Portanto, trabalhamos em torno de uma solução em que planejamos executar esse processo em um dos próprios nós. Mas então o objetivo de ter um cluster à nossa disposição é negado porque estaríamos gravando no disco do Node e não no armazenamento de dados compartilhado por todos os clusters.
Não consigo acreditar que o NFS foi construído para clusters de pequena escala e nunca foi implementado com sucesso em soluções de grande escala empresarial. Pode existir outro motivo para o NFS interromper repentinamente a conexão de rede?
Tenho certeza de que o processo em questão é a causa do congelamento do cluster, mas não estou convencido de que a velocidade de leitura/gravação exigida seja a causa da falha. Algum de vocês já teve esse problema anteriormente? Uma migração completa de protocolo é a única solução que temos?
Responder1
Algumas sugestões aprendidas ao longo dos anos.
- Minimize a carga no servidor NFS:
defina as opções de exportação NFS:async,insecure,no_subtree_check
definir opções de montagem NFSsoft,noatime,nodiratime,nolock,vers=3
também definido: noatime,nodiratimeem montagens de dados/tmp/scratch. Certifique-se de que a criptografia NFS esteja desativada para reduzir a carga. Pare o processo de bloqueio do NFS.
Tente habilitar os frames JUMBO para a rede em todos os hosts (se suportado pelo equipamento de rede) - defina MTU para 9k ou mais.
Certifique-se de que o armazenamento raid10 seja usado (evite raid5/6 a TODOS os custos) para E/S de gravação aleatória. Algum SSD?
Maximize o número de identificadores FS abertos (o padrão é 2K em alguns sistemas), defina-o para 1M ou mais.
Alguma chance de copiar o banco de dados de mapeamento com dados de entrada para o armazenamento do nó temporário local e combinar/classificar os arquivos Sam resultantes como uma etapa separada?
Aumente o tamanho do pedaço processado (para que ele seja processado por pelo menos 30 minutos ou mais).
Se possíveldividir trabalhos no nível mais alto possível(tente mapear/classificar 10 genomas/amostras separados em 10 nós diferentes em paralelo, em vez de tentar mapear cada genoma em série usando 10 hosts). Tente fazer checkpoint, assim que todos os processos forem concluídos.
Modifique uma fonte de programa para que ele leia os dados em pedaços maiores - como 1M em vez de 4k.
Esteja ciente da contenção de interconexão CPU/RAM (especialmente em sistemas de soquete AMD 4-8), às vezes a execução de 12 a 24 threads em uma caixa de 48 núcleos é muito mais rápida que 48 threads. Experimente diferentes níveis de utilização. Certifique-se de que o NUMA esteja ativado e configurado para sistemas com várias CPUs. Recompile com NUMA habilitado.
PS: Gerenciar um cluster eficiente é semelhante a planejar/gerenciar um canteiro de obras com mais de 1 mil trabalhadores...