Carne di cuore STONITH sul panico del kernel

Ho un cluster di due nodes con battito cardiaco e DRBD che gestisce una risorsa mysql. Il failover funziona ottimamente se interrompere il primario, riavviarlo o scolbind la connessione di networking.

Tuttavia, se il primario soffre di un panico del kernel (simulato eseguendo echo c > /proc/sysrq-trigger ), il secondario non assume le risorse.

Questo è ciò che registra il battito cardiaco sul secondario:

 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. 

Qualcuno ha idea di perché il secondario non riesca a prendere in questa situazione? Normalmente il failover funziona ottimamente, ma sto cercando di simulare un panico del kernel nel nodo primario.

EDIT: Ecco il mio config heartbeat, 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 

  • Heartbeat vs UCarp
  • Perché utilizzare la scherma quando hai già collegamenti di comunicazione ridondanti?
  • relazione tra battito cardiaco, openais, corosinccio
  • uso dell'indirizzo multicast in corosync
  • Mixing Multiple Master Replication (MMR) con Linux-HA
  • command crm (gestione cluster per pacemaker) non trovato negli ultimi Centos 6
  • Architettura per MySQL altamente accessibile con failover automatico in località fisicamente diverse
  • One Solution collect form web for “Carne di cuore STONITH sul panico del kernel”

    Quando i nodes di cluster perdono contatti tra loro, per evitare uno scenario a crosta divisa , where entrambi i nodes pensano che siano primari e tenta di eseguire simultaneamente la risorsa condivisa con un potenziale disastro (questo è particolarmente un grosso problema in due cluster di nodes , perché chi ha il quorum se entrambi i nodes hanno un voto ciascuno?), per attenuare questo, alcuni cluster implementano varie forms di scherma.

    Su linux-ha wiki page:

    Il recinto è il process di bloccaggio delle risorse da un nodo il cui stato è incerto.

    Sono disponibili diverse tecniche di scherma.

    Si può anche recinare i nodes – utilizzando il Nodo Fencing, o le risorse di recinzione utilizzando il Resource Fencing. Alcuni tipi di risorse sono risorse di autoescavazione e alcune non sono danneggiate dall'utilizzo simultaneo e non richiedono la scherma.

    Quando un nodo preforms un arresto pulito, sarà comunque abbandonato il cluster, e quindi gli altri sapranno cosa succede e pertanto prenderà in considerazione i servizi che il nodo potrebbe essere in esecuzione e quindi proseguire. Quando il nodo invece di lasciare il cluster ottiene bene un panico del kernel, gli altri membri del cluster non conoscono lo stato dell'altro nodo. Saranno "incerti" dal loro punto di vista, in modo che invece eseguiranno le azioni di "scherma" configurate, che nel caso di STONITH significa cercare di rimuovere il nodo fisso dalla forza dal cluster (da power-cycling ecc.).

    Guardando nei tuoi registri, sembra che il meccanismo meatware carne sia scelto per la configuration del cluster. Come suggerisce il nome, implica manualmente il potere di ciclare l'altro nodo e quindi eseguire tale command. Da doc :

    materiale umano

    Nome strano e un concetto semplice. il carne di carne richiede aiuto da parte di un essere umano. Ogni volta che viene richiamato, il programma di carni registra un messaggio di gravità CRIT che dovrebbe essere visualizzato sulla console del nodo. L'operatore dovrà quindi assicurarsi che il nodo sia in discesa ed emettere un command meatclient (8) per indicare ai carceri che è giusto indicare al cluster che potrebbe considerare il nodo morto. Vedere README.meatware per ulteriori informazioni.

    Ci sono altri modi per configurare la scherma. Quando faccio un cluster, ho solitamente due switch APC per i PSU e configurare "scherma APC" ( stonith -t apcmaster -h ). In questo modo, quando un nodo non riesce, l'altro preformsrà un riavvio duro facendo ricaricare il membro difettoso accedendo all'interface APC e inviando il command di arresto / riavvio in slot PSU collegati (ottengo due per evitare un singolo punto di errore) .

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.