Newsgroup: it.comp.os.linux.sys
Titolo: high avaibility su linux red hat

ciao a tutti,
sto seguendo un progetto più dal lato manageriale che pratico e mi serve 
che due server linux redhat 5 gestiscano un servizio in high avaibility, 
nella fattispecie ldap.
la soluzione di clusterizzazione è basata sul prodotto di clustering di 
redhat, che io non conosco approfonditamente, anche se ho molta 
esperienza su altre soluzioni di clusterizzazione, come hacmp di aix e 
lifekeeper per linux.
la configurazione da implementare è molto semplice:
1) un ip di servizio che migra da un nodo all'altro con ldap
2) l'applicazione ldap
3) uno storage condiviso con filesystem ext3 (mi è stato detto da chi 
sta implementando la soluzione che gfs non è da prendersi in 
considerazione perché per sua esperienza diretta ha avuto solo 
problemi), che deve essere montato solo da un nodo alla volta.
ho dato un'occhiata alla descrizione della configurazione (non ho ancora 
accesso alle macchine) e ho notato che, a differenza di altri prodotti, 
la soluzione di clustering di redhat fa molto affidamento sulla 
possibilità di un nodo di poter spegnere l'altro, mi sapete spigare 
perché è così fondamentale? altra cosa strana che ho notato è che 
l'heart beat passa solo su una interfaccia di rete, io sono abituato ad 
averlo su almeno 2 interfaccie e su seriale e/o disco condiviso, mi 
sembra un po' riduttivo averlo solo su una rete lan dove ogni nodo ha 
solo una interfaccia.
abbiamo riscontrato due problemi
a) una volta il nodo dormiente, ritenendo erroneamente che il nodo 
attivo fosse down, si è montato lo storage condiviso facendo un vero macello
b) a volte le macchine vanno in loop e si spengono a vicenda.
conosco la persona che si sta occupando dell'implementazione e da quanto 
ho avuto modo di vedere in passato è una persona competente, quindi 
escluderei che sitratti di errori da novellino...
come dicevo, non avendo una specifica conoscenza della soluzione HA di 
redhat chiedo a chi ne ha conoscenza se lo devo configurare una 
soluzione accettabile per un servizio in produzione oppure meglio non 
perdere tempo e volgere lo sguardo altrove.
personalmente infatti, avendo implementato una soluzione HA per squid 
per una grossa istituzione pubblica, per cui mi è stato imposto di usare 
lifekeeper, prodotto che non conoscevo, devo dire di essermi trovato 
molto bene ad utilizzarlo: il prodotto si è comportato egregiamente in 
quasi 2 anni di onorato servizio.
quindi richiedo:
la soluzione di redhat per HA è affidabile?
voi cosa usate?
grazie per le risposte

 caterva.
perchè "però" ???
al massimo, "ed oltretutto"!

ma redhat cluster lo hai mai usato, o hai sentito di qualcuno che lo ha 
usato???

 usato???
Usai io, ma erano eoni fa (2001 o 2002), e probabilmente nel frattempo 
si è evoluto parechio.
E anche il quel caso, comunque, senza stonith: è vivamente consigliato e 
consigliabile per evitare corruzioni di filesystem nel caso di 
split-brain (cosa importante soprattutto se usi FS non clustered) ma non 
era obbligatorio.
Per quanto con l'hw attuale (oramai tutti i server degni di tal nome 
sono equipaggiati di schede Lights-Out), avere stonith non sia neanche 
lontanamente oneroso quanto lo era all'epoca...

 voi cosa usate?
Sun Cluster
Ciao,
Alberto

 perdere tempo e volgere lo sguardo altrove.
Non lo conosco direttamente, ma HA di redhat è molto utilizzato in
ambienti di produzione anche critici,
non penso sia così inaffidabile. Probabilmente è la particolare
installazione che avete fatto voi che ha
qualche flaw.
Cambiando discorso, so che non è quello che hai chiesto ma non posso
non farti notare che usare un cluster per gestire *solo* ldap, che è
un sistema che ha già una sua soluzione di availability nativa basata
sulle repliche, mi pare un po' strano... cosa ti impedisce di usare
due server normali e configurarli entrambi come ldap server, replicati
tra di sè? Se usi il sistema directory di redhat puoi anche metterli
entrambi master...
bye!

la stessa cosa che avevo sollevato io... non ricordo la ragione per cui 
non si può fare ma c'era qualche cosa nel disegno dell'architettura che 
lo impediva...

 
Forse era ... l'incompetenza di chi l'ha progettata?

 Io ho usato hearthbeat + drbd su RH 4 e non ho avuto grossi problemi di
[cut]
Anche io sto utilizzando una soluzione con drbd + heartbeat per un
cluster nfs basato su debian che fa da storage ad un altro cluster
mailserver basato su freebsd; sono abbastanza soddisfatto.
Ritengo in ogni caso che una qualunque scelta dipenda da quanto è
critica la situazione che devi gestire.
Partendo dal presupposto che openldap dalla 2.4 replica anche in
multimaster mode, il servizio viene già ridondato da sè.
Se l'implementazione è critica metterei 2 macchine, carp/heartbeat e
una SAN in mezzo (posto che ci siano i soldi)
Se l'implementazione non è TROPPO critica metti 2 macchine, carp/
heartbeat e drbd e vivi felice.
Considera anche l'utilizzo che andrai a fare di ldap, soprattutto in
termini prestazionali (drbd vs una SAN).

 grazie per le risposte
Grazie a Te per averci dato un così succulento spunto sul quale disquisire!!
Ciao.

 difettosa purtroppo può causare un casino del genere.
che centra la schermatura????

On Sep 19, 9:47 am, writethem <""poiuuuu

semplificavo, intendevo dire che se per caso il patch utilizzato per
l'interfaccia di heartbeat è difettoso per un motivo o per l'altro può
causare dei falsi allarmi sulla linea, a causa di qualche pacchetto
droppato di troppo.
bye!