Sistema de arquivos de rede falha durante altas velocidades de E / S

Question

Eu sou um usuário em um cluster usando o 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 pensamos estar causando o problema é chamado de Bowtie, um alinhador em pipelines Bioinformáticos. Em suma, temos seqüências alfabéticas em arquivos fragmentados de 1 milhão de linhas por arquivo que são comparados a outro arquivo que contém o dicionário inteiro. (Isso é uma simplificação excessiva do algoritmo)

Este dicionário é mapeado pela 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: Nó1 Nó2 Nó3

Número de Processadores disponíveis para mim: 128 processadores ou 128 slots de fila em execução.

Para execução no cluster, o arquivo principal é dividido em blocos de 1 milhão de linhas cada e, em seguida, todos os trabalhos são iniciados usando 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 a ser executado 1 arquivo de código contendo o código de saída do processo 1 arquivo STDOUT gerado pelo SGE 1 SGE gerou o arquivo STDERR 1 pedaço de arquivo 1 arquivo de saída

Isso significa que durante esse processo eu tenho 768 + 3 manipuladores de arquivos abertos no armazenamento de dados remoto, embora os primeiros quatro arquivos sejam constantes para cada script no pipeline.

Sempre que isso acontece, o servidor NFS no armazenamento de dados falha e todo o cluster fica inativo porque o armazenamento não responde.

Nossa equipe de TI sugeriu que isso pode ser devido à alta E / S durante esse processo e possivelmente o NFS foi destinado apenas a clusters pequenos e não a clusters grandes.

Portanto, trabalhamos em torno de uma solução em que estamos planejando executar esse processo em um dos nós. Mas o ponto de ter um cluster à nossa disposição é negado porque estaríamos escrevendo no disco do Nó e não no armazenamento de dados compartilhado em todos os clusters.

Não consigo acreditar que o NFS foi criado para clusters de pequena escala e nunca foi implementado com sucesso em grandes soluções de escala empresarial. Pode existir outra razão para o NFS soltar a conexão de rede?

Estou certo de que o processo é 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á experimentou tal problema anteriormente? Uma migração de protocolo completa é a única solução que temos?

    

Answer 1

Algumas sugestões aprendidas ao longo dos anos.

1. Minimize a carga no servidor NFS:

define as opções de exportação do NFS: async,insecure,no_subtree_check

definir opções de montagem do NFS soft,noatime,nodiratime,nolock,vers=3

também define: noatime,nodiratime em montagens de dados / tmp / scratch. Certifique-se de que a criptografia NFS esteja desativada para reduzir a carga. Parar o processo de bloqueio do NFS.

2. Tente ativar os quadros JUMBO para a rede em todos os hosts (se suportado pelo equipamento de rede) - defina o MTU para 9k ou mais.

3. Certifique-se de que o armazenamento raid10 seja usado (evite raid5 / 6 em TODOS os custos) para E / S de gravação aleatória. Qualquer SSD?

4. Maximize o número de identificadores de FS abertos (o padrão é 2K em alguns sistemas), defina-o como 1M ou mais.

5. Alguma chance de copiar o banco de dados de mapeamento com dados de entrada para o armazenamento local do nó temporário e de combinar / classificar os arquivos sam resultantes como uma etapa separada?

6. Aumente o tamanho do bloco processado (por isso, ele está sendo processado por pelo menos 30 minutos ou mais.

7. Se possível, separar trabalhos em um 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). Tentativa de verificação, uma vez que todos os processos tenham terminado.

8. Modifique uma fonte de programa, para que ela leia dados em blocos maiores, como 1M em vez de 4k.

9. Esteja ciente da contenção de interconexão de CPU / RAM (especialmente em sistemas de soquete AMD 4-8), às vezes executando 12-24 threads na caixa de 48 núcleos é muito mais rápido do que 48 threads. Experimente diferentes níveis de utilização. Certifique-se de que o NUMA esteja em & configurado para sistemas com múltiplas CPUs. Recompile com NUMA ativado.

PS: Gerenciar um cluster eficiente é semelhante ao planejamento / gerenciamento de um canteiro de obras com 1k + trabalhadores ...