O Heartbeat tenta o nó de failover, mas o primário ainda está em execução

Question

Eu tenho uma configuração de failover primário para o HAProxy em dois servidores usando o Heartbeat. Ele tem funcionado bem por um tempo agora. Hoje nosso serviço ficou inativo por alguns minutos quando o servidor secundário achou que o primário estava inativo. Ele tentou assumir o IP compartilhado, mas não conseguiu, já que o servidor principal ainda estava mantendo-o. No entanto, de acordo com os registros, o principal parece ter se comunicado com o secundário em relação à aquisição, por isso não faz sentido.

Depois de resolver o problema reiniciando o Heartbeat no primário, notei que a hora no primário estava desligada em cerca de 5 minutos em comparação com o secundário. O Heartbeat usa o tempo para distinguir se um recurso está inativo?

Syslog ServerNode1:

Jun  8 14:25:51 serverNode heartbeat: [15461]: ERROR: Both machines own our resources!
Jun  8 14:25:52 serverNode heartbeat: [15461]: ERROR: Both machines own our resources!
Jun  8 14:25:56 serverNode heartbeat: [15461]: info: Received shutdown notice from 'serverNode2'.
Jun  8 14:25:56 serverNode heartbeat: [15461]: info: Resources being acquired from serverNode2.
Jun  8 14:25:56 serverNode heartbeat: [15461]: debug: StartNextRemoteRscReq(): child count 1
Jun  8 14:25:56 serverNode heartbeat: [18058]: info: acquire local HA resources (standby).
Jun  8 14:25:56 serverNode ResourceManager[18087]: info: Acquiring resource group: serverNode xxx.xxx.xxx.88
Jun  8 14:25:56 serverNode IPaddr[18124]: INFO:  Running OK
Jun  8 14:25:56 serverNode IPaddr[18138]: INFO:  Running OK
Jun  8 14:25:56 serverNode heartbeat: [18059]: info: Local Resource acquisition completed.
Jun  8 14:25:56 serverNode heartbeat: [18058]: info: local HA resource acquisition completed (standby).
Jun  8 14:25:56 serverNode heartbeat: [15461]: info: Standby resource acquisition done [foreign].
Jun  8 14:25:56 serverNode heartbeat: [15461]: debug: StartNextRemoteRscReq(): child count 1
Jun  8 14:25:56 serverNode heartbeat: [18184]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
Jun  8 14:25:56 serverNode harc[18184]: info: Running /etc/ha.d//rc.d/status status
Jun  8 14:25:56 serverNode mach_down[18199]: info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
Jun  8 14:25:56 serverNode mach_down[18199]: info: mach_down takeover complete for node serverNode2.
Jun  8 14:25:56 serverNode heartbeat: [15461]: info: mach_down takeover complete.

Syslog ServerNode2:

Jun  8 14:31:33 serverNode2 heartbeat: [1407]: WARN: node serverNode: is dead
Jun  8 14:31:33 serverNode2 heartbeat: [1407]: WARN: No STONITH device configured.
Jun  8 14:31:33 serverNode2 heartbeat: [1407]: WARN: Shared disks are not protected.
Jun  8 14:31:33 serverNode2 heartbeat: [1407]: info: Resources being acquired from serverNode.
Jun  8 14:31:33 serverNode2 heartbeat: [1407]: info: Link serverNode:eth0 dead.
Jun  8 14:31:33 serverNode2 heartbeat: [30881]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
Jun  8 14:31:33 serverNode2 harc[30881]: info: Running /etc/ha.d//rc.d/status status
Jun  8 14:31:33 serverNode2 heartbeat: [30882]: info: No local resources [/usr/share/heartbeat/ResourceManager listkeys serverNode2] to acquire.
Jun  8 14:31:33 serverNode2 heartbeat: [1407]: debug: StartNextRemoteRscReq(): child count 1
Jun  8 14:31:33 serverNode2 mach_down[30909]: info: Taking over resource group xxx.xxx.xxx.88
Jun  8 14:31:33 serverNode2 ResourceManager[30934]: info: Acquiring resource group: serverNode xxx.xxx.xxx.88
Jun  8 14:31:33 serverNode2 IPaddr[30961]: INFO:  Resource is stopped
Jun  8 14:31:33 serverNode2 ResourceManager[30934]: info: Running /etc/ha.d/resource.d/IPaddr xxx.xxx.xxx.88 start
Jun  8 14:31:33 serverNode2 IPaddr[31019]: INFO: Using calculated nic for xxx.xxx.xxx.88: eth0
Jun  8 14:31:33 serverNode2 IPaddr[31019]: INFO: Using calculated netmask for xxx.xxx.xxx.88: 255.255.255.0
Jun  8 14:31:33 serverNode2 IPaddr[31019]: INFO: eval ifconfig eth0:0 xxx.xxx.xxx.88 netmask 255.255.255.0 broadcast xxx.xxx.xxx.255
Jun  8 14:31:33 serverNode2 IPaddr[31007]: INFO:  Success
Jun  8 14:31:33 serverNode2 mach_down[30909]: info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
Jun  8 14:31:33 serverNode2 heartbeat: [1407]: info: mach_down takeover complete.
Jun  8 14:31:33 serverNode2 mach_down[30909]: info: mach_down takeover complete for node serverNode.

    

Answer 1

Não, os relógios desligados não quebrarão o relacionamento. No entanto, se os relógios mudassem drasticamente, isso causaria erros no log, eles se pareceriam com:

heartbeat: 2004/11/10_21:08:49 info: Clock jumped backwards. Compensating.

Mas isso não mataria o primário.

O que parece é a comunicação entre os servidores. Especificamente, parece que o server1 não podia mais enviar dados ou o server2 não estava recebendo corretamente. Isso pode ser devido a algum problema de buffer. Você está rastreando o espaço do buffer de rede? (via snmp ou netstat) Ou talvez um problema de rede em algum lugar, erros switchport?

Quando você diz que o site estava inoperante, você tem monitoramento testando o serviço em cada servidorX para um IP específico para esse servidor? Ele indicava se algum dos servidores estava inativo durante esse período, além do VIP não estar funcionando? Os gráficos de tráfego ou as contagens de erro / queda mostram algo interessante para esse período de tempo?

    

Answer 2

Precisa de mais informações.

1. Topologia física. Como esses hosts são fisicamente conectados uns aos outros?
2. Configuração do heartbeat (ha.cf) e regras do iptables para cada host. Em particular, você está usando broadcast (bcast), multicast (mcast) ou unicast (ucast). Além disso, especifique qual versão do heartbeat.

Minha suspeita é que algo está filtrando o tráfego entre seus nós hearbeat. Iptables é uma possibilidade. Dependendo da sua topologia física, outros dispositivos também podem ser suspeitos.