cluster redhat, dipendenze tra risorse

[ZeroUno]

Sto configurando un servizio su un cluster redhat.

In particolare ho un processo che che ha i dati su un filesystem clusterizzato.
Chiaramente il processo non deve venire startato se il filesystem non è montato.

Questa è la prima soluzione:

/etc/cluster/cluster.conf
..
<service name="mioservizio">
<fs ref="miofs"> (in cui miofs è definito in <resources>...</resources>)
<script ref="scriptdistart"/> (in cui scriptdistart è definito come script in <resources>...</resources>)
</fs>
</service>
...

e così startando mioservizio mi parte filesystem e processo.

Però se per qualche motivo voglio vedere solo i dati senza tirare su il processo (per troubleshooting per esempio) sono costretto a fermarlo e montare il filesystem a mano che non è una cosa bella.

Allora la soluzione che è logica è quella di fare due servizi separati, uno per il fs e uno per il processo.
<service name="serviziofs">
<fs ref="miofs"/>
</service>
<service name="sevizioprocesso">
<script ref="scriptdistart">
</service>

Ma questo mi consente di avviare il processo senza il filesystem. Allora ho corretto il secondo servizio in
<service name="servizioprocesso" depend="serviziofs">
e difatti non mi permette di avviare il processo se non ho il filesystem montato perchè effettua il controllo se il serviziofs è down o up

Però non effettua il controllo del nodo di residenza, il ché significa che mi consente di avviare il processo sul nodo A anche se il filesystem è montato sul nodo B.

Chi conosce la soluzione?

L'ideale sarebbe
<service name="mioservizio">
<fs ref="miofs"> (in cui miofs è definito in <resources>...</resources>)
<script ref="scriptdistart"/> (in cui scriptdistart è definito come script in <resources>...</resources>)
</fs>
</service>
ma con la possibilità di stoppare solamente scriptdistart (da command line parlo; però clusvcadm mi consente solo di specificare "mioservizio")


Grazie,
01

[masalapianta]

che io sappia (ma vado a memoria, non ho controllato la documentazione, quindi piglia quel che ti dico con le molle) non puoi, l'attributo 'depend' di un service, come hai scoperto, serve a garantire la dipendenza di due servizi, ma ai client non per i servizi stessi (per questo la dipendenza non include il medesimo nodo di esecuzione), il che è corretto che sia così perchè a livello logico non ha alcun senso creare due servizi separati per due risorse che logicamente dovrebbero appartenere allo stesso servizio (se hanno quel tipo di interdipendenza); l'interdipendenza delle risorse è garantita dall'appartenenza al medesimo servizio, il che, come hai scoperto non consente di gestire separatamente le risorse, anche perchè quest'ultima non è un'operazione che si dovrebbe fare quotidianamente ma solo in caso di problemi o in situazioni rare; in questi ultimi casi è possibile fare quel che chiedi (e altro) freezando il servizio con 'clusvcadm -Z', dopodichè puoi avviare/stoppare a mano le risorse appartenenti a quel servizio senza che il rgmanager si incazzi.

[ZeroUno]

su veritas cluster è possibile farlo.

anche lì definisco un gruppo e relative risorse annidati per dipendenza

gruppo
ip
filesystem
applicazione
/filesystem
/ip
/gruppo

ma a differenza di redhat cluster, i comandi di start e stop hanno accesso anche alle singole risorse. così se starto applicazione automaticamente si starta anche ip e filesystem e se stoppo ip allora si stoppa anche filesystem e applicazione, mentre se starto filesystem allora si starta anche ip ma non applicazione.

Però al di là della condizione attuale in cui voglio tenere giù solo il demone per troubleshooting, possono esistere casi in cui ci sono due servizi separati, senza legami di dipendenza (su chi può essere up senza che lo sia l'altro), ma che tuttavia quando sono up devono trovarsi sullo stesso nodo, e quando switcha uno deve in automatico switchare anche l'altro.

Ho trovato in giro questo:

Codice: Seleziona tutto

<rm>
<events>
<event class="service" name="service-ers">
notice("Event service triggered!");
evalfile("/usr/share/cluster/follow-service.sl");
follow_service("service:svc1", "service:svc2", "service:mastersvc");
</event>
<event class="node" name="node-ers">
notice("Event node triggered!");
evalfile("/usr/share/cluster/follow-service.sl");
follow_service("service:svc1", "service:svc2", "service:mastersvc");
</event>
</events>
</rm>

ma non funziona.

Comunque, sul depend, non sono riuscito a fare in modo che se starto il secondo allora automaticamente mi starta il primo; lo devo fare per forza a mano.

Al momento l'unica cosa che mi viene in mente per forzare filesystem e servizio sullo stesso nodo è quello di mettere nello script di status del demone il controllo dell'esistenza di un file nel filesystem e ritornare un fallimento in caso questo non venga trovato, così se il fs è sul secondo nodo e tento lo start del servizio sul primo nodo, questo va in errore e il cluster lo switcha automaticamente sul secondo nodo.
Non è tra le soluzioni più belle ma dovrebbe essere funzionale.

[masalapianta]

su veritas cluster è possibile farlo.
...
ma a differenza di redhat cluster, i comandi di start e stop hanno accesso anche alle singole risorse. così se starto applicazione automaticamente si starta anche ip e filesystem e se stoppo ip allora si stoppa anche filesystem e applicazione, mentre se starto filesystem allora si starta anche ip ma non applicazione.

imho è un bel modo di complicarsi la vita per ottenere benefici irrilevanti nel 99,(9)% dei casi

Però al di là della condizione attuale in cui voglio tenere giù solo il demone per troubleshooting, possono esistere casi in cui ci sono due servizi separati, senza legami di dipendenza (su chi può essere up senza che lo sia l'altro), ma che tuttavia quando sono up devono trovarsi sullo stesso nodo, e quando switcha uno deve in automatico switchare anche l'altro.

non mi viene in mente nessun caso in cui possa servire una cosa del genere; se i servizi non sono interdipendenti a che gli serve girare sullo stesso nodo?

Al momento l'unica cosa che mi viene in mente per forzare filesystem e servizio sullo stesso nodo è quello di mettere nello script di status del demone il controllo dell'esistenza di un file nel filesystem e ritornare un fallimento in caso questo non venga trovato, così se il fs è sul secondo nodo e tento lo start del servizio sul primo nodo, questo va in errore e il cluster lo switcha automaticamente sul secondo nodo.
Non è tra le soluzioni più belle ma dovrebbe essere funzionale.

superporcata
ma non ti conviene fare un unico servizio con dentro entrambe le risorse (come logica vorrebbe) e poi, le poche volte che ti capita di dover montare il fs con il servizio giu, freezare il cluster? ci metti 5 secondi a dare un 'clusvcadm -Z', qual'è il problema?

[ZeroUno]

Però non capisco una cosa..
se il servizio è stoppato ( -s o -d ) che mi cambia da -Z ? cioè posso montare a mano il fs e avviare a mano il servizio anche senza freezare il cluster no?

cioè, se il servizio non mi funziona, non è che lo starto e poi freezo il cluster.

Mi sarebbe più utile piuttosto disabilitare lo status check lasciandomi però la possibilità di fare lo stop e start con i comandi del cluster (-e -d -s -R).


Quello che non mi andrebbe, anche in caso di troubleshooting, sarebbe quello di montare a mano il filesystem

[masalapianta]

Però non capisco una cosa..
se il servizio è stoppato ( -s o -d ) che mi cambia da -Z ? cioè posso montare a mano il fs e avviare a mano il servizio anche senza freezare il cluster no?

se è stoppato o disabilitato _non_dovrebbe_ cambiare nulla (ma non ho mai provato, di solito freezo il cluster se devo smanacciare a mano le risorse) perchè l'rgmanager in tal caso _non_dovrebbe_ monitorare quelle risorse

cioè, se il servizio non mi funziona, non è che lo starto e poi freezo il cluster.

se non funziona su un dato nodo viene switchato su un altro nodo (e allora non puoi fare troubleshooting senza prima freezare il servizio sul nodo dove è attivo perchè l'rgmanager lo vedrebbe salire su un nodo ove non dovrebbe essere), se non funziona su alcun nodo comunque ti conviene freezarlo per evitare che l'rgmanager cerchi di restartarlo mentre tu stai lavorando o si crei qualche situazione imprevista dal fatto che l'rgmanager veda in piedi un servizio/risorsa che si aspetta non esserlo.
In ogni caso (a parte quando un servizio viene stoppato/disabilitato, ma verifica) ti conviene freezare un servizio se ci devi lavorare a mano; ma soprattutto ricordati sempre che se freezi un servizio in un dato stato (attivo ad esempio) poi quando fai l'unfreeze il servizio _deve_ essere nel medesimo stato.

Mi sarebbe più utile piuttosto disabilitare lo status check lasciandomi però la possibilità di fare lo stop e start con i comandi del cluster (-e -d -s -R).

guarda, non sono sicuro che non si possa fare, quello che fa il freeze è proprio disabilitare lo status check, però non so (perchè non ho mai provato, di solito preferisco freezare e lavorare manualmente) se contestualmente disabiliti anche la gestione dei servizi tramite il cluster o meno; prova e lo saprai (poi fammi sapere che mi interessa )

Quello che non mi andrebbe, anche in caso di troubleshooting, sarebbe quello di montare a mano il filesystem

perchè? è così che si fa troubleshooting, se una funzionalità automatica non funziona, si comincia a provare manualmente la stessa cosa dal livello più basso possibile a salire

[ZeroUno]

Mi sarebbe più utile piuttosto disabilitare lo status check lasciandomi però la possibilità di fare lo stop e start con i comandi del cluster (-e -d -s -R).

guarda, non sono sicuro che non si possa fare, quello che fa il freeze è proprio disabilitare lo status check, però non so (perchè non ho mai provato, di solito preferisco freezare e lavorare manualmente) se contestualmente disabiliti anche la gestione dei servizi tramite il cluster o meno; prova e lo saprai (poi fammi sapere che mi interessa )

Codice: Seleziona tutto

[root@pfr-cec-cal2 ~]# clusvcadm -Z myservice
Local machine freezing service:myservice...Success
[root@pfr-cec-cal2 ~]# clusvcadm -e myservice
Local machine trying to enable service:myservice...Failure: Service is frozen

e mi sembra logico.
Il freeze non credo che disabiliti solo lo status check ma qualsiasi comando cluster su quel servizio.

Quello che non mi andrebbe, anche in caso di troubleshooting, sarebbe quello di montare a mano il filesystem

perchè? è così che si fa troubleshooting, se una funzionalità automatica non funziona, si comincia a provare manualmente la stessa cosa dal livello più basso possibile a salire

Il mount di un filesystem sharato tra due sistemi è sempre delicato. Un piccolo errore e lo monti su entrambe le macchine.

Credo che mi farò qualche script ad hoc per il troubleshooting.

[ZeroUno]

mmm
Finalmente ho disponibile l'applicativo da mettere in cluster.

Però mi ritrovo con il problema che immaginavo.

starto l'applicativo, e ok.
mi metto in tail sui log che sono sul filesystem condiviso
stoppo l'applicativo (clusvcadm -s)... chiaramente fallisce perchè il filesystem è busy.

questo è quello che intendevo.
Mi sembra troppo restrittiva la cosa. Non può essere che per effettuare un semplice restart dell'applicativo (-s, -R) devo anche smontare e rimontare il filesystem ricordandomi di stoppare eventuali tail, fare cd / e chiamare tutti quelli connessi per fargli fare la stessa cosa; mentre se voglio fare il restart monitorando i log devo freezare il cluster, ed effettuare il restart a mano dell'applicativo.
Possibile che non ci sia una soluzione più decente al problema?

[masalapianta]

uh? di solito gli script che fanno l'unmount di un fs sharato, prima di fare l'unmount, killano tutti i processi che hanno descrittori di file aperti su quel filesystem; btw valuta se non ti conviene passare a gfs2 (immagino che tu stia usando uno zozzo nfs)

[ZeroUno]

nessun nfs. Il filesystem è SAN ed è montato esclusivamente sul nodo che detiene il servizio

ok, avevo dimenticato il force_unmount="1"

resta di fatto però che il restart dell'applicativo stando in tail sui log non lo posso fare.

[masalapianta]

nessun nfs. Il filesystem è SAN ed è montato esclusivamente sul nodo che detiene il servizio
ok, avevo dimenticato il force_unmount="1"
resta di fatto però che il restart dell'applicativo stando in tail sui log non lo posso fare.

1) come ho detto sta agli script di unmount fare il kill di tutti i processi che hanno descrittori di file aperti sul file system da smontare; se di default non lo fanno (non ricordo), basta fare una piccola modifica ma questo non dovrebbe esser necessario su un cluster ben progettato e ben gestito (vedi punto 2)
2) non dovrebbe essere necessario arrivare a situazioni del genere (file system busy), perchè le risorse e la configurazione del cluster vanno progettati in modo che, quando il cluster arriva a smontare il fs, non ci siano più processi con descrittori aperti su esso (tutte le risorse che aprono descrittori sul fs devono essere fermate prima di smontare il fs); se poi qualcuno ha aperto "a mano" (con un tail o semplicemente con un cd o vattelappesca come) dei descrittori sul fs, sono affari suoi, esattamente come sono affari suoi quando fa un rm di troppo; così funziona la gestione dei fs sui cluster HA.
3) nel caso specifico del tail si rientra nell'ambito di operazioni di troubleshooting che vengono normalmente fatte freezando il servizio e lavorando a mano sulle risorse
4) avevo inteso che stessi studiando redhat cluster per conto tuo e non fosse una questione lavorativa; di solito lo do per scontato (personalmente non mi sognerei mai di chiedere aiuto su un forum di hobbysti per le mie beghe lavorative), ma l'uso di una SAN mi fa pensare altrimenti; se effettivamente è un problema lavorativo ti pregherei di dirlo, in quanto non troverei corretto continuare ad aiutarti (o provare a farlo) in tal caso.

[ZeroUno]

1) come ho detto sta agli script di unmount fare il kill di tutti i processi che hanno descrittori di file aperti sul file system da smontare; se di default non lo fanno (non ricordo)

con il force_unmount="1" lo fa. Provato e funziona.

3) nel caso specifico del tail si rientra nell'ambito di operazioni di troubleshooting

a volte si a volte no.
Capita a volte di dover semplicemente restartare un processo. Nel farlo di solito monitorizzo il log per assicurarmi che risalga correttamente.
Diverso invece è se non ce la fa a restartarsi. Allora si ha senzo freezare ecc.
L'altro scenario in cui è utile effettuare una separazione delle risorse è quello in cui si hanno più processi separati che insistono sullo stesso filesystem.
Per esempio apache+mysql. Non mi sembra sensato dover restartare mysql se ho fatto una modifica al file di conf di apache (che HA sarebbe).

Lo scenario che richiede la possibilità di operare in modo separato le risorse è anche quello in cui, avendo due servizi residenti sullo stesso filesystem, si può decidere di metterne uno in autostart e uno no. E tale scenario non è poi così tanto raro in grandi architetture (due servizi mutuamente esclusivi, due servizi in cui per startarne uno è necessario fare operazioni manuali come avviare un altro server prima, due servizi di cui uno temporaneamente non funzionante quindi da tenere giù per un certo tempo ma non perdere l'HA sull'altro...).


Il cluster è fatto solo per dare una forma di HA, e vero, ma non per questo deve complicare la vita ai sistemisti.
Se per ogni piccola cosa devo freezare il cluster e operare a manina (rischiando errori, soprattutto su risorse con agent standard non scritti da me) lo vedo utile si ma poco pratico.

In passato ho usato il cluster Linux-HA (se ricordo bene) e questo consentiva di fare gruppi di risorse e l'amministratore era in grado di gestire tutte manualmente (nel rispetto delle opportune dipendenze opportunamente configurate)

4) avevo inteso che stessi studiando redhat cluster per conto tuo e non fosse una questione lavorativa; di solito lo do per scontato (personalmente non mi sognerei mai di chiedere aiuto su un forum di hobbysti per le mie beghe lavorative), ma l'uso di una SAN mi fa pensare altrimenti; se effettivamente è un problema lavorativo ti pregherei di dirlo, in quanto non troverei corretto continuare ad aiutarti (o provare a farlo) in tal caso.

Uso il cluster al lavorio, mi sembrava chiaro.
Per quanto potessi decidere di studiare un cluster a livello hobbistico (in tal caso non avrei scelto redhat, come puoi immaginare, visto che uso slackware), lo vedo poi immediato il passaggio di tale studio al mondo lavorativo. Quanta è la gente che ha bisogno di un cluster professionale a casa, e quanti sono disposti a pagare un cluster (redhat si paga) casalingo?

Ritengo la qualità di ciò che si scrive in questo forum sicuramente superiore a quella semplicemente hobbistica e spesso superiore a quella di molti forum professionali, e dando una occhiata ai vari topic credo che non siano pochi quelli che (espliciti o impliciti) chieda no per esigenze professionali.

Ovviamente se non vuoi aiutarmi rispetterò le tue scelte. Quando sicrivo su un forum sono ben cosciente di non pretendere risposte. Credo che sia uno dei primi fondamenti e regole più importanti di un forum.

Personalmente (tempo permettendo) aiuto gli utenti del forum indistintamente dall'uso che ne farà delle conoscenze che riceve in un determinato topic.

[masalapianta]

4) avevo inteso che stessi studiando redhat cluster per conto tuo e non fosse una questione lavorativa; di solito lo do per scontato (personalmente non mi sognerei mai di chiedere aiuto su un forum di hobbysti per le mie beghe lavorative), ma l'uso di una SAN mi fa pensare altrimenti; se effettivamente è un problema lavorativo ti pregherei di dirlo, in quanto non troverei corretto continuare ad aiutarti (o provare a farlo) in tal caso.

Uso il cluster al lavorio, mi sembrava chiaro.
Per quanto potessi decidere di studiare un cluster a livello hobbistico (in tal caso non avrei scelto redhat, come puoi immaginare, visto che uso slackware), lo vedo poi immediato il passaggio di tale studio al mondo lavorativo. Quanta è la gente che ha bisogno di un cluster professionale a casa, e quanti sono disposti a pagare un cluster (redhat si paga) casalingo?

un sacco di gente studia determinate tecnologie (come RH cluster ad esempio) per poi applicarle in ambito lavorativo (purtroppo in Italia poche aziende investono in formazione e quindi quest'ultima procede con il fai da te), in tal caso non ho alcun problema a dare una mano, anche se lo studio poi viene applicato nel lavoro, non è esso stesso un lavoro per il quale si viene direttamente pagati

Ritengo la qualità di ciò che si scrive in questo forum sicuramente superiore a quella semplicemente hobbistica e spesso superiore a quella di molti forum professionali, e dando una occhiata ai vari topic credo che non siano pochi quelli che (espliciti o impliciti) chieda no per esigenze professionali.

mi son spiegato male, quando dico "hobbystico" non mi riferisco alla qualita tecnica degli interventi, ma al fatto che non siano collegati a problemi, per risolvere i quali, si viene pagati; a mio avviso non è etico sottoporre ad hobbysti dei problemi lavorativi; non è questo il modo in cui personalmente intendo la comunità del software libero e non è questo il modo in cui intendo la professionalità.
Ma questa ovviamente è la _mia_ etica, non pretendo che tutti la vedano così o che venga impedito di sottoporre su forum hobbystici problemi lavorativi; chiedo solo di dichiararlo esplicitamente quando si sottopone un problema lavorativo, in modo che, chi come me non lo trova etico, possa evitare di rispondere sapendolo in anticipo.