Como posso solucionar o erro “nfs: server 127.0.0.1 not responding” (nfs: servidor 127.0.0.1 não responde) ao montar o sistema de arquivos do EFS?

Breve descrição

A seguir estão os motivos comuns pelos quais você pode ver o erro server not responding (servidor não responde):

• O cliente do NFS não consegue se conectar ao servidor do EFS.
• Ocorreu uma reinicialização ou desligamento da instância. Ou ocorreu alguma outra desconexão da instância do EC2. Essas ocorrências causam uma desconexão de rede entre o cliente do NFS e o servidor do EFS. Esse comportamento não está em conformidade com o RFC TCP. As desconexões podem fazer com que as respostas do Amazon EFS a uma instância do Amazon Elastic Compute Cloud (Amazon EC2) ou a um cliente do NFS fiquem bloqueadas por vários minutos.
• A opção de montagem noresvport não foi usada ao montar o sistema de arquivos usando um cliente do NFS.
• Pode haver um problema com a versão do kernel causando falha na montagem do EFS. Por exemplo, há vários problemas conhecidos do cliente do NFS com o RHEL6 que causam sintomas semelhantes à falta de resposta dos sistemas de arquivos. Nas versões anteriores do kernel do RHEL6.X, o sistema de arquivos poderia ficar indisponível e não ser remontado. Podem ocorrer travamentos de conexão do NFS no Amazon EFS se você estiver executando:

• RHEL ou CentOS 7.6 ou posterior (kernel versão 3.10.0-957).
• Qualquer outra distribuição do Linux com o kernel versão 4.16 a 4.19.

Resolução

1.    Use a opção de montagem noresvport ao montar seu sistema de arquivos. Essa opção garante que o cliente do NFS use a nova porta TCP de origem quando uma conexão de rede precisar ser restabelecida. O uso de noresvport garante que o sistema de arquivos do EFS tenha disponibilidade ininterrupta após um evento de recuperação da rede.

$   sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport mount-target-ip:/ mnt

Se você estiver usando o auxiliar de montagem do EFS, a opção noresvport estará presente por padrão. Se você estiver usando o NFS para montar, deverá adicionar esse parâmetro explicitamente. Para obter mais informações, consulte Opções de montagem de NFS recomendadas.

2.    Verifique a versão do kernel. Pode haver problemas com a versão específica do kernel, como RHEL ou CentOS 7.6 ou posterior (versão do kernel 3.10.0-957), que podem causar falha na montagem do sistema de arquivos. Se você estiver executando uma dessas versões do kernel, reinicialize para recuperar o acesso ao sistema de arquivos. Para confirmar se a versão do kernel é o problema, verifique a saída do comando ps quando não conseguir executar ls:

$ ps auxwwwm | grep <mount_point_IP>

Se a versão do kernel for o problema, atualize o kernel. É prática recomendada usar o cliente Linux NFS4v.1 da geração atual ou posterior para um melhor desempenho.

3.    Verifique se o cliente pode se conectar ao servidor executando o seguinte comando:

telnet <ip-of-efs> 2049

Verifique se há erros nos logs do cliente do NFS (logs do sistema operacional da instância do EC2) em /var/log/messages. Os logs podem estar no diretório /var/log/syslog ou /var/log/dmesg, dependendo do sistema operacional.

Além disso, se você montou o sistema de arquivos usando o auxiliar de montagem do EFS, revise os logs de util. do EFS no diretório /var/log/amazon/efs. O auxiliar de montagem do EFS tem um mecanismo de registro integrado.

4.    Verifique se você pode se conectar à instância do EC2.

5.    Verifique se o EC2 está sendo sobrecarregado devido à utilização excessiva de recursos. Você pode fazer isso monitorando as métricas do EC2 no Amazon CloudWatch, como CPUUtilization e as métricas relacionadas à rede. Os recursos podem incluir problemas de CPU, memória, problemas no nível de aplicativo etc.

• Uso excessivo de memória: isso pode ocorrer quando a RAM é superutilizada. A utilização excessiva significa que a instância está ficando sem espaço de memória, se, por exemplo, uma aplicação começar a consumir mais RAM. A utilização excessiva causa erros de falta de memória (OOM). Quando iniciados, esses erros encerram os processos que têm uma pontuação de OOM alta ou que estão consumindo mais memória. Idealmente, quando os erros de OOM são iniciados, a instância permanece inacessível.
  Para resolver temporariamente os erros de OOM, reinicialize o sistema para liberar espaço na memória.
  Para uma solução de longo prazo, monitore o uso de recursos do sistema usando ferramentas como “atop” e “top”. Em seguida, mude para um outro tipo de instância que se adeque melhor à workload. Para obter mais informações, consulte Por que minha instância do Linux do EC2 deixa de responder devido à superutilização de recursos?
• Desempenho da rede: analise o desempenho de rede da instância. Às vezes, mesmo que as métricas do CloudWatch mostrem baixa utilização da rede, pode haver micro-bursting. O micro-bursting envia uma grande quantidade de tráfego de uma workload em poucos segundos. O micro-bursting normalmente dura menos de um minuto. Esse burst não fica evidente nos gráficos do CloudWatch e nas estatísticas do Amazon Elastic Block Store (Amazon EBS) porque o menor intervalo usado nessas ferramentas é de um minuto. Monitore o comportamento de micro-bursting usando ferramentas como sar, nload, iftop. Para obter mais informações, consulte Por que minha instância do Amazon Elastic Compute Cloud (Amazon EC2) está excedendo seus limites de rede quando a utilização média é baixa?

6.    Analise as métricas do CloudWatch do EFS e verifique se o controle de utilização ocorre no nível do EFS. Isso significa que o EFS está tendo um desempenho além de sua capacidade. Se você estiver usando o modo de throughput Bursting, analise a métrica BurstBalance do CloudWatch para determinar se o saldo de burst está esgotado. Além disso, analise as métricas de throughput permitidas do CloudWatch para determinar se você está usando um throughput maior do que a quantidade provisionada. Para obter mais informações sobre créditos de burst, consulte Como funcionam os créditos de burst do Amazon EFS?

Se as aplicações precisarem de um throughput quase contínuo, use o modo de throughput provisionado. Antes de alternar do modo de throughput de bursting para o provisionado, considere quanto throughput deve ser provisionado. Para determinar a quantidade mínima necessária de throughput provisionado, verifique o uso médio de throughput para o sistema de arquivos nas duas semanas anteriores. Considere a maior quantidade de pico arredondada para cima. Para obter mais informaçõess, consulte Quais modos de throughput estão disponíveis no EFS e qual é o modo de throughput correto para minha workload?

---

Informações relacionadas

Solução de problemas de montagem

Solução de problemas do Amazon EFS