DRDB e NFS: existe alguma maneira eficiente de tornar o failover transparente para o NFS

Question

Estamos implementando o heartbeat DRDB + com dois servidores para ter um sistema de arquivos com failover. Esses servidores expõem um serviço NFS para outros servidores

Atualmente, o DRDB está funcionando muito bem, mas ao testarmos a mudança de um servidor para outro, as pastas montadas pelo NFS nos outros servidores simplesmente travam.

Existe alguma maneira transparente de fazer esse failover? Torná-lo transparente para o NFS ou precisamos re-montar essas pastas montadas pelo nfs?

    

Answer 1

O problema aqui é que você fez um storage array redundante usando o DRBD, mas você tem dois daemons NFS separados que executam com os mesmos dados compartilhados. O NFS é stateful - contanto que você não possa transferir o estado também, você terá sérios problemas com o failover. As configurações de Solaris HA têm daemons que cuidam desse problema . Para uma instalação Linux, você terá que se certificar de que seu diretório de estado NFS (configurável, tipicamente / var / lib / nfs) esteja localizado no disco compartilhado para ambos os servidores.

Stick com pulsação ou corosync para detecção de falhas e failover - que geralmente faz a coisa certa (tm), quando configurado com um Quorum . Outras técnicas de failover podem estar muito focadas em apenas fornecer um IP virtual (por exemplo, VRRP) e não atender às suas necessidades. Veja o link para obter mais detalhes e componentes adicionais para uma configuração de cluster.

    

Answer 2

Eu recomendo que você leia este guia em NFS altamente disponível usando NFSv4, DRBD e Pacemaker. Ele contém instruções detalhadas e explicações, além de detalhes importantes sobre como fornecer um serviço NFS altamente disponível. Nós colocamos algumas configurações de HA-NFS em produção agora e elas funcionam muito bem.

Parte de tal configuração de HA é se afastar do antigo sistema Heartbeat (aquele que usa /etc/ha.d/haresources e /etc/ha.d/ha.cf ) e usar a muito pilha de Marcapasso mais robusta e capaz. É um pouco de transição do antigo Heartbeat e bastante uma curva de aprendizado, mas eventualmente significa que você tem um cluster em execução que vale o seu nome.

O HOWTO é escrito pela Linbit, a empresa que criou e mantém o DRBD e contribui muito para toda a pilha de HA do Linux. Infelizmente, o registro (gratuito) em seu site é necessário para acessar os guias técnicos, mas eles são bem escritos e muito úteis.

    

Answer 3

A melhor maneira que posso pensar para tornar isso transparente é usar um IP virtual e um endereço MAC virtual, e os switches estão cientes de que essa transição pode acontecer / fazer a coisa certa quando há um ARP gratuito (para que você não o faça) t tem que esperar por um cache ARP para limpar, o que pode demorar o suficiente para tornar obsoletos seus montes NFS).

Algo como CARP é provavelmente o caminho para o failover de IP - isso está disponível em todos os * BSDs, e, tanto quanto sei, também está no kernel do Linux. Obviamente, faça alguns testes para ter certeza de que funciona da maneira que você quer (parece que você está fazendo testes, então você está em um bom lugar).

    

Answer 4

Verifique se os sistemas de arquivos estão localizados no mesmo número de dispositivo maior / menor (se você usar o mesmo dispositivo drbd em ambos os lados, isso deve ser verdade) e use um IP virtual para seu serviço NFS.

Em Heartbeat, use esta ordem de recursos:

1. Dispositivo DRBD
2. ponto de montagem local
3. todos os serviços relacionados a nfs na ordem correta
4. Última: VIP

É importante colocar o VIP por último - senão seus clientes perderão a conexão NFS em vez de tentar novamente continuamente.

BTW: Colocar um IP como recurso no batimento cardíaco também será uma parte gratificante do failover - então você não precisa se preocupar com isso (normalmente).