Esiste un modo per forzare il battito cardiaco ad aggiungere nuovi indirizzi IP al sistema senza un riavvio completo?

8

Utilizziamo il battito cardiaco per l'alta disponibilità. Vorrei aggiungere un ulteriore indirizzo IP al cluster heartbeat, ma non voglio fare un riavvio completo del cluster nel processo. C'è un segnale che posso inviare al battito cardiaco che lo spingerebbe a analizzare nuovamente il file "haresources" e ad agire su di esso? il battito cardiaco -r non sembra fare il trucco.

linux high-availability heartbeat

— Peter Grace
fonte

6

Il problema era che non ho aspettato abbastanza a lungo dopo aver eseguito "heartbeat -r" (il comando che viene eseguito nello script init.d quando si esegue "service heartbeat reload"). Dopo alcuni minuti, l'IP è apparso su l'interfaccia come previsto.

— Peter Grace
fonte

Il battito cardiaco applica il cambiamento stesso eh? Che in realtà ha un quoziente di aspirazione molto basso! Se scopri quanto tempo ci faccia sapere :-)

— voretaq7,

Mi sono reso conto dopo aver letto questo commento che era piuttosto fuorviante; Ho cancellato l'intera risposta e l'ho riscritta.

— Peter Grace,

mmh, è più sensato - Devi innescare la ricarica, ma non è istantaneo. (Ed è più deterministico, il che mi rende felice.)

— voretaq7,

2

Non è necessario ricaricare Heartbeat. Aggiungi semplicemente la nuova risorsa IPaddr al tuo file haresources, qualcosa del genere

IPaddr::xx.xx.xx.xx

e poi avviarlo

/etc/ha.d/resource.d/IPaddr xx.xx.xx.xx start

Naturalmente, è necessario assicurarsi di avviare IPaddr sul nodo attivo. Ora dovresti essere in grado di inviare e ricevere traffico sull'indirizzo IP appena aggiunto.

— Kendall
fonte

Tratterò l'accettazione della mia risposta come corretta, poiché anche se quello che ho fatto ha funzionato, il tuo suggerimento sembra molto più elegante. Voglio provarlo, ma se funziona, vota e la risposta accettata sarà tua.

— Peter Grace,

OK, ecco l'affare. Ho provato questo e basso ed ecco, ha funzionato! Il problema è che farlo senza ricaricare il battito cardiaco lascerebbe il cluster in uno stato incoerente. Ho controllato la fonte e ci sono solo tre posti in cui il battito cardiaco replica il file haresources e tutte e tre queste condizioni sono durante un riavvio richiesto. Di conseguenza, se un cluster dovesse eseguire il failover e il failback, l'ip inserito nelle haresource e istanziato manualmente con IPaddr <x> start non verrebbe ricreato nel failover. Sentiti libero di dimostrarmi che mi sbaglio, ma sembra che questo metodo sia pericoloso su cui contare.

— Peter Grace,

Abbastanza bene, Heartbeat non mantiene sincronizzati i file di configurazione (ad es. Haresources) per te - devi escogitare il tuo metodo. Nel mio ambiente, in genere utilizziamo l'unisono per questo, e sembra funzionare bene. Il file haresources non viene memorizzato nella cache e viene quindi letto nuovamente quando deve essere letto. Tutte le voci nelle haresource verranno avviate al riavvio degli eventi (o eventi che causano la lettura delle haresource); questo include il failover.

— Kendall,

0

Hearbeat deve essere riavviato solo sul computer secondario, evitando così tempi di inattività relativi alla gestione delle risorse.

In questo caso, il nodo primario rileva che la macchina slave è "morta" e forza un "failover" che ricarica il file delle risorse e avvia le risorse mancanti.

I log sono abbastanza espliciti quando si esegue questa operazione:

May  9 12:10:40 gw2 heartbeat: [3684]: info: Received shutdown notice from 'gw1'.
May  9 12:10:40 gw2 heartbeat: [3684]: info: Resources being acquired from gw1.
May  9 12:10:40 gw2 heartbeat: [26469]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
May  9 12:10:40 gw2 harc[26469]: info: Running /etc/ha.d//rc.d/status status
May  9 12:10:40 gw2 mach_down[26521]: info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
May  9 12:10:40 gw2 mach_down[26521]: info: mach_down takeover complete for node gw1.
May  9 12:10:40 gw2 heartbeat: [3684]: info: mach_down takeover complete.
May  9 12:10:40 gw2 heartbeat: [3684]: debug: StartNextRemoteRscReq(): child count 1
May  9 12:10:40 gw2 IPaddr2[26520]: INFO:  Running OK
May  9 12:10:40 gw2 IPaddr2[26640]: INFO:  Running OK
May  9 12:10:40 gw2 IPaddr2[26725]: INFO:  Running OK
May  9 12:10:40 gw2 IPaddr2[26805]: INFO:  Running OK
May  9 12:10:40 gw2 IPaddr2[26890]: INFO:  Resource is stopped
May  9 12:10:40 gw2 heartbeat: [26470]: info: Local Resource acquisition completed.
May  9 12:10:40 gw2 heartbeat: [3684]: debug: StartNextRemoteRscReq(): child count 1
May  9 12:10:40 gw2 heartbeat: [26953]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
May  9 12:10:40 gw2 harc[26953]: info: Running /etc/ha.d//rc.d/ip-request-resp ip-request-resp
May  9 12:10:40 gw2 ip-request-resp[26953]: received ip-request-resp IPaddr2::1.2.3.4 OK yes
May  9 12:10:40 gw2 ResourceManager[26976]: info: Acquiring resource group: gw2 IPaddr2::1.2.3.4
May  9 12:10:40 gw2 IPaddr2[27006]: INFO:  Resource is stopped
May  9 12:10:40 gw2 ResourceManager[26976]: info: Running /etc/ha.d/resource.d/IPaddr2 1.2.3.4 start
May  9 12:10:40 gw2 IPaddr2[27115]: INFO: ip -f inet addr add 1.2.3.4/24 brd 1.2.3.255 dev brwan
May  9 12:10:40 gw2 IPaddr2[27115]: INFO: ip link set brwan up
May  9 12:10:40 gw2 IPaddr2[27115]: INFO: /usr/lib/heartbeat/send_arp -i 200 -r 5 -p /var/run/resource-agents/send_arp-1.2.3.4 brwan 1.2.3.4 auto not_used not_used
May  9 12:10:40 gw2 IPaddr2[27091]: INFO:  Success

May  9 12:10:47 gw2 heartbeat: [3684]: WARN: node gw1: is dead
May  9 12:10:47 gw2 heartbeat: [3684]: info: Dead node gw1 gave up resources.
May  9 12:10:47 gw2 heartbeat: [3684]: info: Link gw1:eth0 dead.

May  9 12:10:59 gw2 heartbeat: [3684]: info: Heartbeat restart on node gw1
May  9 12:10:59 gw2 heartbeat: [3684]: info: Link gw1:eth0 up.
May  9 12:10:59 gw2 heartbeat: [3684]: info: Status update for node gw1: status init
May  9 12:10:59 gw2 heartbeat: [3684]: info: Status update for node gw1: status up
May  9 12:10:59 gw2 heartbeat: [3684]: debug: StartNextRemoteRscReq(): child count 1
May  9 12:10:59 gw2 heartbeat: [28604]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
May  9 12:10:59 gw2 heartbeat: [3684]: debug: get_delnodelist: delnodelist= 
May  9 12:10:59 gw2 harc[28604]: info: Running /etc/ha.d//rc.d/status status
May  9 12:10:59 gw2 heartbeat: [3684]: info: Status update for node gw1: status active
May  9 12:10:59 gw2 heartbeat: [3684]: debug: StartNextRemoteRscReq(): child count 1
May  9 12:10:59 gw2 heartbeat: [28619]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
May  9 12:10:59 gw2 harc[28619]: info: Running /etc/ha.d//rc.d/status status
May  9 12:10:59 gw2 heartbeat: [28634]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
May  9 12:10:59 gw2 harc[28634]: info: Running /etc/ha.d//rc.d/status status
May  9 12:11:00 gw2 heartbeat: [3684]: info: remote resource transition completed.

— Cyril Bouthors
fonte