Temos um "farm de computação" interno com cerca de 100 servidores CentOS (redistribuição gratuita do RHEL) de 5,7 e 6,5 x86_64. (Estamos no processo de atualizar todas as caixas 5.7 para 6.5.) Todas estas máquinas fazem duas montagens NFSv4 (com sec = krb5p) para dois servidores CentOS 6.5. Um servidor NFS é para diretórios iniciais do usuário, o outro contém vários dados para processos do usuário.
Aleatoriamente, uma das máquinas clientes entrará em um estado ruim, de modo que qualquer acesso à montagem do NFSv4 seja interrompido ("ls", por exemplo). Isso significa que ninguém (exceto o root) pode efetuar login e todos os processos do usuário que exigem acesso aos compartilhamentos ficam bloqueados. Em outras palavras, até agora isso é não-determinístico e não pode ser replicado.
Eu tenho o log NFS muito detalhado habilitado nos clientes e nos servidores, mas nunca recebo erros. No entanto, quando esse estado é acionado, recebo esses erros de rastreio do kernel nas máquinas clientes:
Mar 25 00:49:48 servername kernel: INFO: task ProcessName:8230 blocked for more than 120 seconds.
Mar 25 00:49:48 servername kernel: Not tainted 2.6.32-431.el6.x86_64 #1
Mar 25 00:49:48 servername kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 25 00:49:48 servername kernel: ProcessName D 0000000000000000 0 8230 8229 0x00000000
Mar 25 00:49:48 servername kernel: ffff8804792cdb68 0000000000000046 ffff8804792cdae8 ffffffffa0251940
Mar 25 00:49:48 servername kernel: ffff88010cdc8080 ffff8804792cdb18 ffff88010cdc8130 ffff88010ea5c208
Mar 25 00:49:48 servername kernel: ffff88047b011058 ffff8804792cdfd8 000000000000fbc8 ffff88047b011058
Mar 25 00:49:48 servername kernel: Call Trace:
Mar 25 00:49:48 servername kernel: [<ffffffffa0251940>] ? rpc_execute+0x50/0xa0 [sunrpc]
Mar 25 00:49:48 servername kernel: [<ffffffff810a70a1>] ? ktime_get_ts+0xb1/0xf0
Mar 25 00:49:48 servername kernel: [<ffffffff8111f930>] ? sync_page+0x0/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff815280a3>] io_schedule+0x73/0xc0
Mar 25 00:49:48 servername kernel: [<ffffffff8111f96d>] sync_page+0x3d/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff81528b6f>] __wait_on_bit+0x5f/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff8111fba3>] wait_on_page_bit+0x73/0x80
Mar 25 00:49:48 servername kernel: [<ffffffff8109b320>] ? wake_bit_function+0x0/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff81135bf5>] ? pagevec_lookup_tag+0x25/0x40
Mar 25 00:49:48 servername kernel: [<ffffffff8111ffcb>] wait_on_page_writeback_range+0xfb/0x190
Mar 25 00:49:48 servername kernel: [<ffffffff81120198>] filemap_write_and_wait_range+0x78/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff811baa3e>] vfs_fsync_range+0x7e/0x100
Mar 25 00:49:48 servername kernel: [<ffffffff811bab2d>] vfs_fsync+0x1d/0x20
Mar 25 00:49:48 servername kernel: [<ffffffffa02cf8b0>] nfs_file_flush+0x70/0xa0 [nfs]
Mar 25 00:49:48 servername kernel: [<ffffffff81185b6c>] filp_close+0x3c/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff81074e0f>] put_files_struct+0x7f/0xf0
Mar 25 00:49:48 servername kernel: [<ffffffff81074ed3>] exit_files+0x53/0x70
Mar 25 00:49:48 servername kernel: [<ffffffff81076f4d>] do_exit+0x18d/0x870
Mar 25 00:49:48 servername kernel: [<ffffffff81077688>] do_group_exit+0x58/0xd0
Mar 25 00:49:48 servername kernel: [<ffffffff81077717>] sys_exit_group+0x17/0x20
Mar 25 00:49:48 servername kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
Neste ponto, a única maneira confiável de tornar a máquina utilizável novamente é reinicializá-la. (E mesmo isso requer um ciclo de energia strong, já que a reinicialização do software trava quando tenta desmontar os sistemas de arquivos NFS.)
parece como este problema está correlacionado com um processo que avaria e começa a escrever dados como um louco. Por exemplo, um segfault que gera um arquivo principal enorme ou um bug com um loop de impressão apertado.
No entanto, tentei duplicar esse problema em um ambiente de laboratório com vários processos "dd" martelando o servidor NFS, mas todas as máquinas funcionam bem.
O problema existia com o kernel 2.6.32-431.el6 do CentOS 6.5. No momento em que a questão foi colocada, este era um kernel bastante antigo. Analisamos o changelog para os kernels RHEL / CentOS e vimos muitas atividades relacionadas a NFS. Então nós atualizamos para (o que era) o mais novo kernel do CentOS 6.6, 2.6.32-504.12.2.el6 , e não tivemos o problema desde então.