O failover de pulsação / DRBD não funcionou como esperado. Como eu faço o failover mais robusto?

5

Eu tive um cenário em que uma configuração de pulsação do DRBD tinha um nó com falha, mas não fazia failover. O que aconteceu foi que o nó primário travou, mas não caiu diretamente (era inacessível via ssh ou com a montagem nfs, mas podia ser pingado). O comportamento desejado seria detectar isso e fazer failover para o nó secundário, mas parece que, como o primário não foi totalmente desativado (há uma conexão de rede dedicada de servidor para servidor), o mecanismo de detecção de pulsação não atendeu sobre isso e, portanto, não fez failover.

Alguém viu isso? Existe algo que eu preciso configurar para ter um failover de cluster mais robusto? O DRBD parece funcionar bem (tive que ressincronizar quando reinicializei o antigo primário), mas sem um bom failover, seu uso é limitado.

  • pulsação 3.0.4
  • drbd84
  • RHEL 6.1
  • Não estamos usando o marcapasso

nfs03 é o servidor primário nesta configuração, e nfs01 é o secundário.

ha.cf

  # Hearbeat Logging
logfacility daemon
udpport 694


ucast eth0 192.168.10.47
ucast eth0 192.168.10.42

# Cluster members
node nfs01.openair.com
node nfs03.openair.com

# Hearbeat communication timing.
# Sets the triggers and pulse time for swapping over.
keepalive 1
warntime 10
deadtime 30
initdead 120


#fail back automatically
auto_failback on

e aqui está o arquivo haresources:

nfs03.openair.com   IPaddr::192.168.10.50/255.255.255.0/eth0      drbddisk::data  Filesystem::/dev/drbd0::/data::ext4 nfs nfslock
    
por Quinn Murphy 19.06.2012 / 22:09

2 respostas

2

Eu acho que você terá que implementar algum monitoramento para verificar se o seu sistema primário se comporta como esperado. Se alguma verificação falhar, você deverá desligar o servidor (por meio do IPMI / ILO ou de uma PDU comutada) e permitir que o heartbeat execute seu trabalho.

Acho que você sempre encontrará uma situação em que não funcione como você esperaria.

    
por 19.06.2012 / 23:08
2

não é uma solução perfeita, mas eu tive esse problema há uns 2 ou 3 anos com um drbd mais antigo. O que eu fiz foi adicionar em ambos os hosts um script em cron que verificou se o host real é um mestre ativo ou um escravo. Se estava em um escravo, ele verifica se algum arquivo conhecido no diretório NFS está disponível. Se não; Eu assumi que o NFS está quebrado; ele envia o comando ssh power off . Você pode tentar trabalhar nesta linha. Tenho certeza de que eles são melhores maneiras. Este foi bom o suficiente para mim.

    
por 19.06.2012 / 23:04