Monitorando montagens do NFS para existência

Question

O problema que estamos vendo é que alguns de nossos diretórios montados pelo NFS estão desaparecendo. Literalmente apenas desaparecendo. Eles continuam existindo no final do servidor.

No cliente (CentOS 7.4, usando o kernel-ml de el-repo na versão 4.16.6, nfs-utils -1: 1.3.0-0.48.el7) o fim da unidade não responde. Chamadas para ls /mountpoint apenas são interrompidas. O SO ainda acha que a unidade está montada - a reinicialização de um servidor requer uma reinicialização a frio, porque o processo de desligamento trava ao desmontar a unidade.

Nos logs, estamos vendo muito pouco - no servidor, não vemos nada. Alguns, mas não todo tempo, vemos algo assim em / var / log / messages no cliente:

May 29 16:55:22 papr-res-compute06 kernel: INFO: task STAR:1370 blocked for more than 120 seconds. May 29 16:55:22 papr-res-compute06 kernel: Not tainted 4.16.6-1.el7.elrepo.x86_64 #1 May 29 16:55:22 papr-res-compute06 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 29 16:55:22 papr-res-compute06 kernel: STAR D 0 1370 1351 0x00000080 May 29 16:55:22 papr-res-compute06 kernel: Call Trace: May 29 16:55:22 papr-res-compute06 kernel: __schedule+0x290/0x890 May 29 16:55:22 papr-res-compute06 kernel: ? out_of_line_wait_on_atomic_t+0x110/0x110 May 29 16:55:22 papr-res-compute06 kernel: schedule+0x36/0x80 May 29 16:55:22 papr-res-compute06 kernel: io_schedule+0x16/0x40 May 29 16:55:22 papr-res-compute06 kernel: bit_wait_io+0x11/0x50 May 29 16:55:22 papr-res-compute06 kernel: __wait_on_bit+0x66/0x90 May 29 16:55:22 papr-res-compute06 kernel: out_of_line_wait_on_bit+0x91/0xb0 May 29 16:55:22 papr-res-compute06 kernel: ? bit_waitqueue+0x40/0x40 May 29 16:55:22 papr-res-compute06 kernel: nfs_wait_on_request+0x4b/0x60 [nfs] May 29 16:55:22 papr-res-compute06 kernel: nfs_lock_and_join_requests+0x12a/0x540 [nfs] May 29 16:55:22 papr-res-compute06 kernel: ? radix_tree_lookup_slot+0x22/0x50 May 29 16:55:22 papr-res-compute06 kernel: nfs_updatepage+0x120/0x9f0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: ? nfs_flush_incompatible+0xc5/0x1c0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: nfs_write_end+0xe2/0x3c0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: generic_perform_write+0x10b/0x1c0 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: nfs_file_write+0xd4/0x250 [nfs] May 29 16:55:22 papr-res-compute06 kernel: do_iter_readv_writev+0x109/0x170 May 29 16:55:22 papr-res-compute06 kernel: do_iter_write+0x7f/0x190 May 29 16:55:22 papr-res-compute06 kernel: vfs_writev+0x84/0xf0 May 29 16:55:22 papr-res-compute06 kernel: ? handle_mm_fault+0x102/0x220 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: do_writev+0x61/0xf0 May 29 16:55:22 papr-res-compute06 kernel: SyS_writev+0x10/0x20 May 29 16:55:22 papr-res-compute06 kernel: do_syscall_64+0x79/0x1b0 May 29 16:55:22 papr-res-compute06 kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 May 29 16:55:22 papr-res-compute06 kernel: RIP: 0033:0x7f0cc1563230 May 29 16:55:22 papr-res-compute06 kernel: RSP: 002b:00007fff6f75f2c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014 May 29 16:55:22 papr-res-compute06 kernel: RAX: ffffffffffffffda RBX: 0000000000002025 RCX: 00007f0cc1563230 May 29 16:55:22 papr-res-compute06 kernel: RDX: 0000000000000002 RSI: 00007fff6f75f300 RDI: 000000000000000a May 29 16:55:22 papr-res-compute06 kernel: RBP: 000000001a7b0860 R08: 0000000000000000 R09: 00007f0cc15b8a00 May 29 16:55:22 papr-res-compute06 kernel: R10: cccccccccccccccd R11: 0000000000000293 R12: 000000000000000a May 29 16:55:22 papr-res-compute06 kernel: R13: 00007fff6f75f300 R14: 0000000000000028 R15: 0000000000001ffd

Não podemos reproduzir este erro de forma confiável. Há muito pouco no caminho do commonalty entre instâncias da queda de drives - isso é em um HPC com cerca de 40 servidores e 100 usuários. Geralmente afeta apenas um único servidor, mas aconteceu em todo o hardware (Cisco UCSB-B200-M4 w 368GB e UCSME-142-M4 w 32GB). A única coisa que é comum é que as unidades em questão contêm dados biológicos, que podem ser arquivos muito grandes (às vezes, mais de metade da TB).

Portanto, gostaríamos de monitorar se as unidades NFS estão ativas, porque o SLURM continua atribuindo tarefas a servidores com esse problema, e essas tarefas nunca serão concluídas.

Meu colega preparou alguns scripts de shell que ping this e ls e que gravam em arquivo e email quando necessário. É inteligente e teria sido divertido escrever (awk !, cut!), Mas é absolutamente o (na minha opinião) maneira errada de fazê-lo.

Um rápido google mostra que nfsiostat pode ser útil, mas há pouco em termos de boa instrução, o que não parece mapear para o nosso sistema operacional (em particular, "count" é necessário, apesar da página man diz) e o mais importante, não queremos estatísticas sobre o uso. Eu quero informação de existência. Literalmente "você está aí nsdrive, sou eu raiz?" Eu admito que preciso ler mais sobre o nfsiostat.

Outra solução que já vi é passar das montagens do nfs listadas no fstab para o uso do autofs. Os documentos do CentOS terminam há duas versões mas diga:

This is not a problem with one or two mounts, but when the system is maintaining mounts to many systems at one time, overall system performance can be affected.

Dado que temos cerca de 10 a 12 pontos de montagem, isso é considerado? Meu colega sugeriu que muitos estavam mais no reino dos 100 anos. Independentemente disso, esta informação já é antiga. Analisando os documentos do Redhat , vemos que é um copiar / colar.

Eu vi essas duas erratas / bugs

• link
• link

mas não conseguimos atualizar imediatamente porque os servidores são de produção e em ambiente clínico. Além disso, não há nenhuma indicação de que isso seja explicitamente nosso problema, e dado que não podemos reproduzir o problema à vontade, não podemos testar em nossas máquinas dev - embora eu tenha tentado reproduzir em nossas máquinas dev. Há também versões mais recentes de kernel-ml do El Repo, mas o mesmo problema existe - não é possível apenas atualizá-lo durante a noite - esses servidores geralmente estão em 100% 24/7.

Então, acho que tenho duas perguntas:

• qual é o melhor método que as pessoas conhecem para monitorar a existência de uma unidade (ou seja, a montagem grepping é uma resposta inaceitável)
• devemos migrar de / etc / fstab para autofs (o que, se o fizermos, provavelmente incluirá também um kernel e uma atualização do sistema operacional)