Meatware Heartbeat STONITH no pânico do kernel

Question

Eu tenho um cluster de dois nós com heartbeat e DRBD gerenciando um recurso mysql. O failover funciona muito bem se eu parar o primário, reiniciá-lo ou desconectar a conexão de rede.

No entanto, se o primário sofre de um kernel panic (simulado executando echo c > /proc/sysrq-trigger ), o secundário não toma os recursos.

É assim que o log de pulsação no secundário se parece:

Jul 11 21:33:32 rad11 heartbeat: [7519]: WARN: node rad10: is dead
Jul 11 21:33:32 rad11 heartbeat: [7519]: info: Link rad10:eth0 dead.
Jul 11 21:33:32 rad11 heartbeat: [8442]: info: Resetting node rad10 with [Meatware STONITH device]
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: OPERATOR INTERVENTION REQUIRED to reset rad10.
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: Run "meatclient -c rad10" AFTER power-cycling the machine.

Alguém tem alguma idéia do motivo pelo qual o secundário não assume o controle nesta situação? Normalmente, o failover funciona muito bem, mas estou tentando simular um kernel panic no nó primário.

EDIT: Aqui está a minha configuração de pulsação, ha.cf

# /etc/ha.d/ha.cf

logfile /var/log/ha-log

keepalive 1

deadtime 10

udpport 695

ucast eth0 rad11
auto_failback on
stonith_host rad10 meatware rad11
stonith_host rad11 meatware rad10
node rad10 rad11

    

Answer 1

Quando os nós do cluster perdem contato uns com os outros, para evitar um cenário split-brain , onde ambos os nós acham que são primários e tentam executar simultaneamente o recurso compartilhado com um possível desastre como resultado (isso é especialmente um grande problema em dois clusters de nó, porque quem tem quorum se ambos os nós tiverem um votar cada?), para atenuar isso, alguns clusters implementam várias formas de esgrima.

Na página wiki

Fencing is the process of locking resources away from a node whose status is uncertain.

There are a variety of fencing techniques available.

One can either fence nodes - using Node Fencing, or fence resources using Resource Fencing. Some types of resources are Self Fencing Resources, and some aren't damaged by simultaneous use, and don't require fencing at all.

Quando um nó pré-forma um desligamento limpo, ele deixará o cluster e, assim, os outros saberão o que está acontecendo e, portanto, apenas assumirão quaisquer serviços que o nó possa estar executando e, em seguida, continuará. Quando o nó, em vez de deixar o cluster, obter um kernel panic, os outros membros do cluster não saberão o status do outro nó. Ele será "incerto" do ponto de vista deles, então, eles executarão as ações "esgrima" configuradas, o que no caso de STONITH significa tentar remover o nó falso pela força do cluster (por ciclo de energia, etc.).

Examinando seus registros, parece que o mecanismo meatware STONITH foi escolhido para sua configuração de cluster. Como o nome sugere, isso significa ativar manualmente o ciclo do outro nó e depois executar o comando. De doc :

meatware

Strange name and a simple concept. meatware requires help from a human to operate. Whenever invoked, meatware logs a CRIT severity message which should show up on the node’s console. The operator should then make sure that the node is down and issue a meatclient(8) command to tell meatware that it’s OK to tell the cluster that it may consider the node dead. See README.meatware for more information.

Existem outras maneiras de configurar o fence. Ao criar um cluster, normalmente recebo dois switches APC para a PSU: se configure "fence da APC" ( stonith -t apcmaster -h ). Dessa forma, quando um nó falha, o outro executará uma reinicialização por ciclo-energia do membro defeituoso através do login na interface APC e enviando o comando shutdown / reboot nos slots PSU conectados (recebo dois para evitar um único ponto de falha) .