Início inesperado dos processos do servidor já primário quando o heartbeat no secundário é interrompido

2

Eu tenho um cluster de Heartbeat ativo-passivo com Apache, MySQL, ActiveMQ e DRBD.

Hoje, eu queria realizar manutenção de hardware no nó secundário (node04), então parei o serviço de heartbeat antes de desligá-lo.

Em seguida, o nó primário (node03) recebeu um aviso de desligamento do nó secundário (node04).

Este registro vem do nó primário: node03

heartbeat[4458]: 2010/03/08_08:52:56 info: Received shutdown notice from 'node04.companydomain.nl'.
heartbeat[4458]: 2010/03/08_08:52:56 info: Resources being acquired from node04.companydomain.nl.
harc[27522]:    2010/03/08_08:52:56 info: Running /etc/ha.d/rc.d/status status
heartbeat[27523]: 2010/03/08_08:52:56 info: Local Resource acquisition completed.
mach_down[27567]:       2010/03/08_08:52:56 info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
mach_down[27567]:       2010/03/08_08:52:56 info: mach_down takeover complete for node node04.companydomain.nl.
heartbeat[4458]: 2010/03/08_08:52:56 info: mach_down takeover complete.
harc[27620]:    2010/03/08_08:52:56 info: Running /etc/ha.d/rc.d/ip-request-resp ip-request-resp
ip-request-resp[27620]: 2010/03/08_08:52:56 received ip-request-resp drbddisk OK yes
ResourceManager[27645]: 2010/03/08_08:52:56 info: Acquiring resource group: node03.companydomain.nl drbddisk Filesystem::/dev/drbd0::/data::ext3 mysql apache::/etc/httpd/conf/httpd.conf LVSSyncDaemonSwap::master monitor activemq tivoli-cluster MailTo::[email protected]::DRBDFailureAcc MailTo::[email protected]::DRBDFailureAcc 1.2.3.212
ResourceManager[27645]: 2010/03/08_08:52:56 info: Running /etc/ha.d/resource.d/drbddisk  start
Filesystem[27700]:      2010/03/08_08:52:57 INFO:  Running OK
ResourceManager[27645]: 2010/03/08_08:52:57 info: Running /etc/ha.d/resource.d/mysql  start
mysql[27783]:   2010/03/08_08:52:57 Starting MySQL[ OK ]
apache[27853]:  2010/03/08_08:52:57 INFO:  Running OK
ResourceManager[27645]: 2010/03/08_08:52:57 info: Running /etc/ha.d/resource.d/monitor  start
monitor[28160]: 2010/03/08_08:52:58
ResourceManager[27645]: 2010/03/08_08:52:58 info: Running /etc/ha.d/resource.d/activemq  start
activemq[28210]:        2010/03/08_08:52:58 Starting ActiveMQ Broker... ActiveMQ Broker is already running.
ResourceManager[27645]: 2010/03/08_08:52:58 ERROR: Return code 1 from /etc/ha.d/resource.d/activemq
ResourceManager[27645]: 2010/03/08_08:52:58 CRIT: Giving up resources due to failure of activemq
ResourceManager[27645]: 2010/03/08_08:52:58 info: Releasing resource group: node03.companydomain.nl drbddisk Filesystem::/dev/drbd0::/data::ext3 mysql apache::/etc/httpd/conf/httpd.conf LVSSyncDaemonSwap::master monitor activemq tivoli-cluster MailTo::[email protected]::DRBDFailureAcc MailTo::[email protected]::DRBDFailureAcc 1.2.3.212
ResourceManager[27645]: 2010/03/08_08:52:58 info: Running /etc/ha.d/resource.d/IPaddr 1.2.3.212 stop
IPaddr[28329]:  2010/03/08_08:52:58 INFO: ifconfig eth0:0 down
IPaddr[28312]:  2010/03/08_08:52:58 INFO:  Success
ResourceManager[27645]: 2010/03/08_08:52:58 info: Running /etc/ha.d/resource.d/MailTo [email protected] DRBDFailureAcc stop
MailTo[28378]:  2010/03/08_08:52:58 INFO:  Success
ResourceManager[27645]: 2010/03/08_08:52:58 info: Running /etc/ha.d/resource.d/MailTo [email protected] DRBDFailureAcc stop
MailTo[28433]:  2010/03/08_08:52:58 INFO:  Success
ResourceManager[27645]: 2010/03/08_08:52:58 info: Running /etc/ha.d/resource.d/tivoli-cluster  stop
ResourceManager[27645]: 2010/03/08_08:52:58 info: Running /etc/ha.d/resource.d/activemq  stop
activemq[28503]:        2010/03/08_08:53:01 Stopping ActiveMQ Broker... Stopped ActiveMQ Broker.
ResourceManager[27645]: 2010/03/08_08:53:01 info: Running /etc/ha.d/resource.d/monitor  stop
monitor[28681]: 2010/03/08_08:53:01
ResourceManager[27645]: 2010/03/08_08:53:01 info: Running /etc/ha.d/resource.d/LVSSyncDaemonSwap master stop
LVSSyncDaemonSwap[28714]:       2010/03/08_08:53:02 info: ipvs_syncmaster down
LVSSyncDaemonSwap[28714]:       2010/03/08_08:53:02 info: ipvs_syncbackup up
LVSSyncDaemonSwap[28714]:       2010/03/08_08:53:02 info: ipvs_syncmaster released
ResourceManager[27645]: 2010/03/08_08:53:02 info: Running /etc/ha.d/resource.d/apache /etc/httpd/conf/httpd.conf stop
apache[28782]:  2010/03/08_08:53:03 INFO: Killing apache PID 18390
apache[28782]:  2010/03/08_08:53:03 INFO: apache stopped.
apache[28771]:  2010/03/08_08:53:03 INFO:  Success
ResourceManager[27645]: 2010/03/08_08:53:03 info: Running /etc/ha.d/resource.d/mysql  stop
mysql[28851]:   2010/03/08_08:53:24 Shutting down MySQL.....................[ OK ]
ResourceManager[27645]: 2010/03/08_08:53:24 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /data ext3 stop
Filesystem[29010]:      2010/03/08_08:53:25 INFO: Running stop for /dev/drbd0 on /data
Filesystem[29010]:      2010/03/08_08:53:25 INFO: Trying to unmount /data
Filesystem[29010]:      2010/03/08_08:53:25 ERROR: Couldn't unmount /data; trying cleanup with SIGTERM
Filesystem[29010]:      2010/03/08_08:53:25 INFO: Some processes on /data were signalled
Filesystem[29010]:      2010/03/08_08:53:27 INFO: unmounted /data successfully
Filesystem[28999]:      2010/03/08_08:53:27 INFO:  Success
ResourceManager[27645]: 2010/03/08_08:53:27 info: Running /etc/ha.d/resource.d/drbddisk  stop
heartbeat[4458]: 2010/03/08_08:53:29 WARN: node node04.companydomain.nl: is dead
heartbeat[4458]: 2010/03/08_08:53:29 info: Dead node node04.companydomain.nl gave up resources.
heartbeat[4458]: 2010/03/08_08:53:29 info: Link node04.companydomain.nl:eth0 dead.
heartbeat[4458]: 2010/03/08_08:53:29 info: Link node04.companydomain.nl:eth1 dead.
hb_standby[29193]:      2010/03/08_08:53:57 Going standby [foreign].
heartbeat[4458]: 2010/03/08_08:53:57 info: node03.companydomain.nl wants to go standby [foreign]

Soo ... O que aconteceu aqui ???

  • O heartbeat no node04 parou e disse ao node03, que era o nó ativo no momento.
  • De alguma forma, o node03 decidiu iniciar os processos do cluster que já estavam em execução. (Para os processos que não são críticos, sempre retorno um 0 do script de inicialização para que ele não pare todo o cluster quando uma parte não essencial falhar).
  • Ao iniciar o ActiveMQ, ele retorna o status 1 porque já está em execução.
  • Isso falha no nó e desliga tudo. Como o heartbeat não está em execução no nó secundário, não é possível fazer failover para lá.

Quando tentei executar o ha_takeover para reiniciar os recursos, absolutamente nada aconteceu.

Somente depois que reiniciei o heartbeat no nó primário, os recursos podem ser iniciados (após um atraso de 2 minutos).

Estas são as minhas perguntas:

  • Por que o heartbeat no nó primário tenta iniciar os processos do cluster novamente?
  • Por que o ha_takeover não funcionou?
  • O que posso fazer para evitar que isso aconteça?

Configuração do servidor:

DRBD:

version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by [email protected], 2010-01-20 09:14:48
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r----
    ns:0 nr:6459432 dw:6459432 dr:0 al:0 bm:301 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

uname -a

Linux node04 2.6.18-164.11.1.el5 #1 SMP Wed Jan 6 13:26:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

fontes de dados

node03.companydomain.nl \
          drbddisk \
          Filesystem::/dev/drbd0::/data::ext3 \
          mysql \
          apache::/etc/httpd/conf/httpd.conf \
          LVSSyncDaemonSwap::master \
          monitor \
          activemq \
          tivoli-cluster \
          MailTo::[email protected]::DRBDFailureAcc \
          MailTo::[email protected]::DRBDFailureAcc \
          1.2.3.212

ha.cf

debugfile /var/log/ha-debug
logfile /var/log/ha-log
keepalive 500ms
deadtime 30
warntime 10
initdead 120
udpport 694
mcast eth0 225.0.0.3 694 1 0
mcast eth1 225.0.0.4 694 1 0
auto_failback off
node    node03.companydomain.nl
node    node04.companydomain.nl

respawn hacluster /usr/lib64/heartbeat/dopd
apiauth dopd gid=haclient uid=hacluster

Muito obrigado antecipadamente,

Ger Apeldoorn

    
por Ger Apeldoorn 08.03.2010 / 10:22

2 respostas

0

Por que vale a pena, sinto sua dor. Parece que o heartbeat considera a perda do nó passivo igual a uma aquisição do nó passivo, portanto, ele inicia seus serviços. Quando os scripts de início falharam e não havia outro nó para o qual o failover, a pulsação permaneceu primária e encerrou todos os serviços. A única maneira de voltar a subir é reiniciar a pulsação quando isso acontece.

Nós lidamos com esse problema fazendo um script único que inicia todos os serviços de cluster (IP, montagem de FS, ipvsadm, Apache, etc) somente se eles ainda não estiverem em execução. Certificamo-nos de que o script de inicialização "all in one" só retorne zero para falhas de inicialização reais (e não para avisos como "já em execução") para evitar problemas como este.

    
por 10.03.2010 / 20:25
1

Este não é um bug de heartbeat. Este é um erro comum em alguns scripts de inicialização. RTFM : a norma diz:

  • Parar um recurso parado não é um erro
  • Iniciar um recurso iniciado não é um erro

Então, o que deu errado? O ActiveMQ foi iniciado e já está em execução.

Isso não é um erro! Mas: Ele retornou 1 = erro em vez de 0 = ok - então a pulsação concluiu que houve um erro e interrompeu todo o grupo de recursos.

Portanto, se você usar scripts de inicialização para pulsação, verifique se eles estão em conformidade com o LSB.

    
por 13.07.2011 / 21:32