Fiquei com a impressão de que, com o NFS sobre TCP, você não pode ir de A- > B- > A em um curto período de tempo. Veja, por exemplo, o link
Imagine se você tiver um Cluster NFS do Red Hat com 2 nós; cada nó é RHEL5.4 de 64 bits e compartilham um SAN LUN para os dados. A interface primária em cada servidor é HA failover bonded (bond0, eth0 + eth1) e há um IP de recurso de cluster flutuante padrão para NFS. A configuração do cluster é configurada com ferramentas padrão da Red Hat e o NFS tem portas estáticas definidas em / etc / sysconfig / nfs para funcionar através de um firewall. Até aí tudo bem, certo? Muito pelo livro, melhores práticas - nada de funky ou estranho usado no servidor ou na configuração do cluster.
O núcleo do problema é quando os clientes estão usando TCP para montar o compartilhamento NFSv4 exportado; em um serviço de cluster realocado para o outro nó, o nó recém-passivo retém uma conexão ESTABALHADA 2049 / tcp (daemon nfs) usando o IP de cluster ausente nos clientes, embora isso seja tecnicamente impossível (até onde eu sei). A “solução” foi migrar para o UDP ao montar os clientes, pois não conseguimos descobrir o que estava acontecendo (e, mais importante, como consertá-lo). Qualquer pista sobre por que são bem-vindos, detalhes abaixo.
Cluster IP: 1.1.1.10
Client IP: 2.2.2.100
Iniciando, o serviço NFS está em execução no nó-A, o nó-A tem o IP do cluster com alias como bond0: 0 e a SAN montada. O cliente NFS está conectado via TCP NFSv4 ao IP do cluster e as coisas estão funcionando bem. Em nosso netstat no nó A, vemos:
1.1.1.10:2049 2.2.2.2.100:915 ESTABLISHED
Tudo é como deveria ser. No node-A, execute um comando padrão ' clusvcadm -r nfs-svc -m nó-B ' para mover o NFS para o nó-B; nos dois syslogs do nó-A e no nó-B, você vê as mensagens adequadas - NFS sendo parado, o IP sendo liberado / movido, SAN desmontado / montado e assim por diante. No cliente NFS você vê algumas mensagens syslog sobre o servidor NFS não estar respondendo, então ele volta OK e está tudo bem. Basicamente, o NFS realocar para o nó-B funciona bem.
No entanto , de volta ao nó-A, que não possui mais o IP 1.1.1.10 do cluster, você ainda vê no netstat uma conexão em 2049! Um rápido " rcpinfo -p " confirma que ainda é nfsd nessa porta.
1.1.1.10:2049 2.2.2.2.100:915 ESTABLISHED
É claro que no nó B você vê a mesma coisa que está correta. A questão dos 10 milhões de dólares é por que ainda está aparecendo no nó-A? Assim que o IP for embora, ele deve ter sido liberado ... se você simplesmente reiniciar o nfsd, o estado da conexão no nó-A mudará para FIN_WAIT1 e, eventualmente, terminará. O IP do cluster não aparece como uma interface no nó-A para ficar claro, apenas no netstat.
E aqui é onde se torna importante - se esta conexão fantasma TCP 2049 ainda estiver no nó-A e você agora realocar o serviço NFS de volta ao nó-A (para que o IP do cluster seja novamente), todos os clientes parem e morram com o NFS mount, independentemente de a conexão fantasma estar no estado ESTABLISHED ou FIN_WAIT1. Somente quando essa conexão fantasma finalmente desaparecer do nó-A os clientes NFS podem recuperar sua montagem NFS - isso é da ordem de 5 a 15 minutos.
Testamos isso várias vezes, garantindo que ele não estava relacionado a firewall e era repetível como um problema e não apenas como um acaso. No final de muitas horas, a única solução viável era mover os clientes para UDP e evitar completamente o problema. Eu realmente quero saber o que está quebrado e como consertar isso.
Fiquei com a impressão de que, com o NFS sobre TCP, você não pode ir de A- > B- > A em um curto período de tempo. Veja, por exemplo, o link
Use netstat -p para descobrir o PID do processo que está escutando (ou, bem, você disse que era nfsd, então encontre o PID de ps ) e então faça um strace nele e você pode talvez descubra o que está acontecendo com isso. Ou talvez você possa fazer o strace antes de executar o comando clusvcadm e ver se recebe algum sinal ou algo do tipo (talvez esteja pendurado em um manipulador de sinal ou esperar que alguma chamada do sistema retorne ...) .
Se o pior acontecer, você pode criar uma versão de depuração do nfsd e executá-la em gdb e fazer o clusvcadm e ver exatamente o que está fazendo ...