“nfsd peername falhou” mas funções de serviço NFSv4

1

Minha configuração atual: 2 servidores NFS compartilhando o mesmo diretório com conteúdo idêntico, 1 keepalived server como SLB (ou melhor, para failover neste cenário) e 1 montagem de cliente NFSv4 por meio de VIP. Todos os sistemas executam o CentOS 6 (2.6.32-573.26.1.el6.x86_64). E como esse é um ambiente de teste, todas as máquinas estão na mesma sub-rede (192.168.66.xx). Para referência, os IPs são os seguintes.

99 VIP
100 nfs01
101 nfs02
102 client
103 keepalived01

Os servidores NFS são configurados como:

/root/share 192.168.66.0/24(ro,fsid=0,sync,no_root_squash

Quanto a keepalived , estou executando no modo DR (o modo NAT falha em funcionar).

vrrp_instance nfs {
        interface eth0
                state MASTER
                virtual_router_id 51
                priority 103    # 103 on master, 101 on backup
                authentication {
                        auth_type PASS
                        auth_pass hiServer
                }
        virtual_ipaddress {
                192.168.66.99/24 dev eth0
        }
}

virtual_server 192.168.66.99 2049 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    protocol TCP

    real_server 192.168.66.100 2049 {
            weight 100
            TCP_CHECK {
                    connect_timeout 6
                    connect_port 2049
            }
    }

    real_server 192.168.66.101 2049 {
            weight 102
            TCP_CHECK {
                    connect_port 2049
                    connect_timeout 6
            }
    }
}

Por fim, o cliente é montado por meio deste comando:

mount -t nfs4 192.168.66.99:/ /nfsdata

A montagem do NFSv4 parece funcionar, embora eu não tenha testado o estresse. Uma coisa que noto é um período de tempo durante o failover, ou seja, encerrei um dos servidores NFS forçando o keepalived a mover o serviço para outro servidor NFS, que o cliente parecerá travar por algum tempo antes de responder. Acredito que isso se deva ao período de carência de 90 segundos.

O problema que me incomoda é que nos servidores NFS, essa linha de log continua mostrando a cada segundo, inundando os logs.

kernel: nfsd: peername failed (err 107)!

Eu tentei usar tcpdump para ver o que está causando o tráfego e as repetições repetidas entre o servidor NFS e o keepalived server. No começo eu pensei que iptables poderia ser o culpado, mas liberá-los em ambas as máquinas não impede o erro.

Se houver uma maneira de suprimir o erro, posso chamá-lo por dia (existe?), mas minhas perguntas de curiosidade: o servidor NFS tem um motivo para tentar se comunicar com o servidor keepalived nesse cenário? Ou talvez haja algo fundamentalmente errado ao configurar o NFS HA dessa forma, mesmo que pareça funcionar?

    
por yongtw123 23.05.2016 / 12:21

1 resposta

1

Após uma inspeção mais detalhada, o erro kernel: nfsd: peername failed (err 107)! aparece aproximadamente a cada 6 segundos. O número parece corresponder à opção connection_timeout no arquivo conf e, de fato, ao parar keepalived service, o erro deixa de aparecer completamente.

Parece que usando TCP_CHECK na porta 2049, os servidores NFS registrarão as tentativas de conexão "incorretas", pois keepalived não está enviando mensagens NFS de acordo com o protocolo.

No final, uso MISC_CHECK para verificar a integridade dos servidores NFS (com um script de shell personalizado chamando rpcinfo ).

    
por 01.06.2016 / 09:21