O servidor NFS parece chutar os nós sem disco

1

Atualmente, estou ajudando a configurar um laboratório que usará nós sem disco para algumas computações de MPI e CUDA.

A distribuição de escolha é o CentOS 7. Para configurar os nós sem disco, segui o guia aqui .

Eu consegui inicializar com êxito um nó sem disco e até executar alguns programas de teste MPI. Então, tudo funciona bem em termos de conectividade, firewalls, exportações nfs, etc.

O problema é que após ~ 12 horas de ter inicializado o nó diskless, o servidor principal que atua como um servidor dhcp, tftp e nfs parece chutar do nó diskless do serviço nfs que resulta com a mensagem kernel: nfs: server <servername> not responding, still trying aparecendo no cliente. Nesse ponto, também paro de receber respostas de ping dos clientes sem disco. Como o cliente tem sua raiz fs obtida pelo NFS, acho que isso deixa o cliente em um estado "corrompido", permitindo-me apenas reinicializar com Ctrl + Alt + Del ou a chave de reinicialização da máquina. Não importa quanto tempo passe o cliente não se conectará. Inspecionando / var / log / messages no servidor principal eu tenho isso interessante na minha linha de opinião: Oct 8 23:30:50 myhostname kernel: NFSD: purging unused client (clientid e87d62f6) .

Aqui está uma parte maior do log: Oct 8 23:30:17 myhostname kernel: nfsv4 compound op ffff885c713d4080 opcnt 4 #3: 3: status 0 Oct 8 23:30:17 myhostname kernel: nfsv4 compound op #4/4: 9 (OP_GETATTR) Oct 8 23:30:17 myhostname kernel: nfsd: fh_verify(36: 01070001 00260308 00000000 996a1153 334c49c8 b8768c81) Oct 8 23:30:17 myhostname kernel: nfsv4 compound op ffff885c713d4080 opcnt 4 #4: 9: status 0 Oct 8 23:30:17 myhostname kernel: nfsv4 compound returned 0 Oct 8 23:30:17 myhostname kernel: --> nfsd4_store_cache_entry slot ffff885c72a66000 Oct 8 23:30:17 myhostname kernel: renewing client (clientid 5bbb153f/e87d62f7) Oct 8 23:30:50 myhostname kernel: NFSD: laundromat service - starting Oct 8 23:30:50 myhostname kernel: NFSD: purging unused client (clientid e87d62f6) Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: cmd: remove Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: arg: 4c696e7578204e465376342e31206e6f64653033 Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: env0: (null) Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: env1: (null) Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: /sbin/nfsdcltrack return value: 0 Oct 8 23:30:50 myhostname kernel: NFSD: laundromat_main - sleeping for 57 seconds Oct 8 23:31:48 myhostname kernel: NFSD: laundromat service - starting Oct 8 23:31:48 myhostname kernel: NFSD: purging unused client (clientid e87d62f7) Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: cmd: remove Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: arg: 4c696e7578204e465376342e31206e76696469613031 Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: env0: (null) Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: env1: (null) Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: cmd: remove Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: arg: 4c696e7578204e465376342e31206e6f64653033 Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: env0: (null) Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: env1: (null) Oct 8 23:30:50 myhostname kernel: nfsd4_umh_cltrack_upcall: /sbin/nfsdcltrack return value: 0 Oct 8 23:30:50 myhostname kernel: NFSD: laundromat_main - sleeping for 57 seconds Oct 8 23:31:48 myhostname kernel: NFSD: laundromat service - starting Oct 8 23:31:48 myhostname kernel: NFSD: purging unused client (clientid e87d62f7) Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: cmd: remove Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: arg: 4c696e7578204e465376342e31206e76696469613031 Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: env0: (null) Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: env1: (null) Oct 8 23:31:48 myhostname kernel: nfsd4_umh_cltrack_upcall: /sbin/nfsdcltrack return value: 0 Oct 8 23:31:48 myhostname kernel: NFSD: laundromat_main - sleeping for 90 seconds Oct 8 23:33:18 myhostname kernel: NFSD: laundromat service - starting Oct 8 23:33:18 myhostname kernel: NFSD: laundromat_main - sleeping for 90 seconds Oct 8 23:34:48 myhostname kernel: NFSD: laundromat service - starting Oct 8 23:34:48 myhostname kernel: NFSD: laundromat_main - sleeping for 90 seconds

Depois, ele continua repetindo o loop da mensagem inicial / inativa do serviço da lavanderia para sempre.

nfsstat não revela nada de estranho no servidor como badcalls etc. Eu também tentei forçar o uso da versão NFSv3. Eu tenho o mesmo problema, no entanto, a mensagem não consumida do cliente e da lavanderia não aparece nos logs agora (supondo que ela foi adicionada na v4?).

Agora, veja alguns detalhes sobre como a conectividade é. O servidor principal possui 2 interfaces de rede. Um realtek (que funciona por padrão com os drivers do kernel) e um que é nvidia nforce e precisa do kmod-forcedeth do elrepo. Todos os serviços do servidor estão no cartão nvidia-nforce. O nó sem disco e o servidor conectam-se através de um switch gigabit (não se lembra do nome / modelo da marca).

    
por moihack 18.10.2018 / 10:37

0 respostas