Falha na montagem de I / O (ocasionalmente) - o servidor expirou

Question

Eu tenho um servidor de arquivos (ark) baseado em Linux que exporta um volume de ataque sobre o nfs4.

Às vezes, ao realizar grandes operações de cópia, o tempo limite será atingido.

[nathan@ebisu /mnt/extra/disk] rsync -a --progress . /mnt/raid/backup/backup.extra/disk
sending incremental file list
BSD.0/
BSD.0/BSD.0.vdi
   411336704  12%   48.60MB/s    0:00:56
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/mnt/raid/backup/backup.extra/disk/BSD.0/BSD.0.vdi": Input/output error (5)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (32 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

Eu sei que este é um tempo limite porque o dmesg me diz:

 [nathan@ebisu ~] dmesg | tail
 [52722.138132] nfs: server ark not responding, timed out
 [52722.138137] nfs: server ark not responding, timed out
 [52722.138145] nfs: server ark not responding, timed out
 [52722.138150] nfs: server ark not responding, timed out
 [52722.138154] nfs: server ark not responding, timed out

Caso você ache que isso seja um bug relacionado ao rsync, também tentei fazer uma cópia normal:

[nathan@ebisu /mnt/extra/disk] cp BSD.0/BSD.0.vdi /mnt/raid/backup/backup.extra/disk
cp: error writing ‘/mnt/raid/backup/backup.extra/disk/BSD.0.vdi’: Input/output error
cp: failed to extend ‘/mnt/raid/backup/backup.extra/disk/BSD.0.vdi’: Input/output error

Eu nem sei por onde começar a procurar para corrigir esse problema. Ambos estão conectados via gigabit ethernet através de um switch gigabit. Eu usei o ethtool para validar que ambos estão realmente rodando em velocidades de gigabit. A maioria das operações entre o host e o servidor funciona bem; é apenas no meio de grandes transferências que ele morre.

Nada no dmesg do servidor de arquivos se destaca como sendo desajeitado.

[root@ark ~]# dmesg | tail
[    7.088959] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[    7.266363] NFSD: starting 90-second grace period (net ffffffff81880e80)
[ 8492.222871] type=1326 audit(1365926452.334:2): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=336 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fe1be17edc7 code=0x0
[ 8492.314714] type=1326 audit(1365926452.424:3): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=338 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fe30fd9ddc7 code=0x0
[ 8492.405336] type=1326 audit(1365926452.514:4): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=340 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f6bb032ddc7 code=0x0
[ 8492.501048] type=1326 audit(1365926452.611:5): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=342 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f81d7c2fdc7 code=0x0
[ 8492.603056] type=1326 audit(1365926452.714:6): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=344 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f97c8bc9dc7 code=0x0
[ 8492.703732] type=1326 audit(1365926452.814:7): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=346 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f0661b2fdc7 code=0x0
[ 8492.837977] type=1326 audit(1365926452.947:8): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=348 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fd024f8cdc7 code=0x0
[54125.173195] type=1326 audit(1365972085.286:9): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=353 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f390a6b9dc7 code=0x0

O syslog é similarmente desprovido de quaisquer problemas.

Mais algumas informações diagnósticas aleatórias que reuni:

[root@ebisu etc]# nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
1057273    34163      1050608 

Isso é um monte de retrans.

Eu verifiquei se estava saturando meus tópicos nfsd, mas não, eles estavam quase ociosos.

Apenas por diversão, eu fiz uma transferência semelhante completamente localmente, para ver se estava atingindo erros de disco ou lentidão:

[root@ark ~]# rsync --progress test.img /mnt/bigraid/backup/backup.ark/
test.img
  8589934592 100%   48.38MB/s    0:02:49 (xfer#1, to-check=0/1)

sent 8590983238 bytes  received 31 bytes  50386998.65 bytes/sec
total size is 8589934592  speedup is 1.00

Parece que atingiu um pouco menos de 50MB / s, que é aproximadamente a velocidade que eu estava recebendo no rsync remoto.

Eu tentei fazer a transferência enquanto estava executando o htop no servidor, e notei que depois de um tempo parece que o nfsd pode ter solicitado mais buffers de memória. Pode estar relacionado à memória, já que, pelos padrões modernos, o servidor não é um sistema de alta memória. Mas parece-me que isso deve apenas fazer com que a transferência seja mais lenta, não para expirar completamente.

    

Answer 1

Esta não é realmente uma resposta, mas algumas dicas de solução de problemas:

1. Verifique se o problema está conectado ao NFS, exporte o mesmo volume usando outro protocolo, SMB, por exemplo (veja aqui para instruções). Você recebe os mesmos erros? Como alternativa, tente copiar com scp :

   [nathan@ebisu ~] scp root@ark:/mnt/bigraid/backup/backup.ark/test.img .
   

2. Isso acontece apenas ao copiar um único arquivo grande ou você também recebe os mesmos erros se copiar a mesma quantidade de dados em muitos arquivos pequenos?

   split test.img
   rsync -a --progress x* /mnt/raid/backup/backup.extra/disk
   

3. De acordo com esta página , valores altos de retransmissão indicam

   that the number of available NFS kernel threads on the server is insufficient to handle the requests from this client

   Portanto, tente aumentar o número de segmentos definindo a variável RPCNFSDCOUNT . Dependendo da sua distribuição, isso pode ser definido em /etc/sysconfig/nfs ou /etc/default/nfs-kernel-server (é onde está no meu Debian). Tente algo como

   RPCSVCGSSDOPTS=16
   

4. A mesma página também sugere que você defina o tamanho do bloco como 32 no cliente. Supondo que você esteja montando o compartilhamento de seu /etc/fstab , adicione essas opções à linha relevante:

   rsize=32768,wsize=32768,intr,noatime
   

   Além de aumentar o tamanho do bloco de leitura / gravação, essas opções

   also ensure that NFS operations can be interrupted if there is a hang and will also ensure that the atime won’t be constantly updated on files accessed on remote NFS file systems.

Answer 2

Isso parece muito com um problema de rede para mim. Algumas placas de rede (especialmente se são chips Realtek) não são muito compatíveis com o padrão, especialmente em 1Gbps e com um switch no meio. Então você deveria tentar:

• conectando os dois sem um comutador
• mudando os cabos Ethernet
• forçar a velocidade de conexão para 1000Mbps Full duplex e verificar se o problema persiste
• forçar a velocidade de conexão para 100Mbps Full duplex e verificar se o problema persiste (na maioria das vezes a instabilidade não será mostrada em 100Mbps e, mesmo que essa não seja a configuração desejada, ela ajudará a restringir a incompatibilidade)
• verificar ifconfig e ethtool -S ethX para erros
• verificar o MTU usando ifconfig e defini-lo como 1500 se for maior
• usando ping -f para verificar pacotes descartados entre os dois, especialmente com valores altos de -s (tamanho do pacote de ping) - conexões instáveis exibirão perda de pacotes quando você executar algo como ping -f -s 10000 por alguns segundos

Answer 3

Eu tive a mesma mensagem de erro (mas não é o mesmo problema, já que eu poderia reproduzir o erro a cada vez!).

A execução do rsync com mais detalhes ( rsync -vv ) tornou óbvio que o sistema de arquivos de destino estava cheio!

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) test/file1 is uptodate test/file2 is uptodate test/file3 is uptodate rsync: recv_generator: mkdir "test/file4" failed: No space left on device (28) * Skipping any contents from this failed directory * rsync: recv_generator: mkdir "test/file5" failed: No space left on device (28) rsync: close failed on "test/file6": Input/output error (5) rsync: connection unexpectedly closed (78708 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]