O cliente NFS não atende ao servidor após a reinicialização

Question

EDITAR:

Para resumir o problema, isso é um problema com o servidor NFS alterando o endereço IP e os clientes NFS não pegando o novo endereço. Eu posso ver via tcpdump que o cliente ainda tenta entrar em contato com o endereço IP antigo na porta 2049.

Temos vários pontos de montagem do NFS definidos como este em /etc/fstab . Como você pode ver, este é o NFS v3.

storage-1:/data/medias/media /var/www/myproject/data/media nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/medias/secure /var/www/myproject/web/secure nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/tobeprocessed /var/www/myproject/data/tobeprocessed nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/ftp /var/ftp nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0

Quando reiniciamos o servidor, temos que desmontar e remontar cada nó de extremidade, caso contrário os clientes não poderão acessar o servidor NFS. Eu tentei até 5 minutos após a reinicialização antes de desmontar e remontar.

Após a reinicialização do servidor NFS, um simples ls /var/www/myproject/data/media faz o console parar.

Eu também posso ver as seguintes mensagens em /var/log/syslog :

Sep 16 11:24:36 encoder-1 kernel: [69688.160102] nfs: server storage-1 not responding, still trying
Sep 16 11:30:15 encoder-1 kernel: [70027.744042] nfs: server storage-1 not responding, still trying

Quando eu umount e, em seguida, mount um dos diretórios nfs no cliente, posso acessá-lo. Mas não consigo acessar os outros, a menos que eu também umount e mount .

Eu qualquer um sabe uma solução possível para isso, eu sou todo ouvidos. Observe que rpcinfo mostra que o cliente pode entrar em contato com o servidor, conforme mostrado abaixo.

Existe um servidor NFS, 4 clientes NFS para um total de 12 pontos de montagem.

O resultado de rpcinfo -p storage-1 de um cliente:

[0]root@encoder-1:/var/log # rpcinfo -p storage-1
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  52115  status
    100024    1   tcp  57907  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  59603  nlockmgr
    100021    3   udp  59603  nlockmgr
    100021    4   udp  59603  nlockmgr
    100021    1   tcp  47716  nlockmgr
    100021    3   tcp  47716  nlockmgr
    100021    4   tcp  47716  nlockmgr
    100005    1   udp    892  mountd
    100005    1   tcp    892  mountd
    100005    2   udp    892  mountd
    100005    2   tcp    892  mountd
    100005    3   udp    892  mountd
    100005    3   tcp    892  mountd

Ao ativar os rastreamentos de depuração do NFS conforme explicado aqui , recebemos a seguinte mensagem de log:

Sep 17 05:35:00 encoder-1 kernel: [135112.160230] nfs: server storage-1 not responding, still trying
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS: nfs_lookup_revalidate(///) is valid
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS: revalidating (0:12/5242881)
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS call  getattr

    

Answer 1

Eu acho que pode ser um problema para resolver o nome do host. Tenho notado que mesmo que a resolução pareça funcionar bem, caso contrário, no sistema e na rede, os processos de montagem do NFS parecem ocasionalmente ter um problema com ela. Eu mudaria o nome do host para o endereço IP real e tentaria fazer isso. Vamos dizer que o FQDN é storage-1.example.org e ele resolveria para 192.0.2.11 e então:

192.0.2.11:/data/medias/media /var/www/myproject/data/media nfs bg,rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0

Mesmo que isso não corrija o problema, eu pessoalmente considero o uso do endereço IP em vez do nome do host ou FQDN como preferível. Mas eu entendo que pode haver razões para você não querer fazer isso.

Observação : adicionei a opção bg , que será usada como base do processo de montagem, caso demore mais tempo para montar, a fim de acelerar inicialização. Cabe a você se você preferir isso. Eu pensei em mencioná-lo desde quando há um número de pontos de montagem NFS com cada um demorando mais (ou tempo limite) para montar o tempo de inicialização pode facilmente tornar-se mais de uma hora.