Newsgroup: it.comp.os.linux.sys
Titolo: GlusterFS Cluster Zimbra 2 nodi

Mi sto per cimentare in un clusterino 
composto da due nodi per far girare
Zimbra in HA.
 
Ho un dubbio, posso usare ext4 sotto glusterFS solo se il cluster è Attivo/Passivo o anche nel caso di Attivo/Attivo ?
 
Altra cosuccia,
come procedura, pensavo di installare il SO,
installare GlusterFS,
Condividere con GlusterFS /opt e /var/lib/mysql
 
a questo punto installare mysql-server e Zimbra.
 
Corretto ?
Thankss
 
-- Yena --
 
 

 Corretto ?
 
In teoria sï¿œ, in pratica non ho grande esperienza di glusterfs.
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 In teoria sì, in pratica non ho grande esperienza di glusterfs.
 
/var/lib/mysql con accesso concorrenziale, in modalità attivo/attivo ?? 
Gulp!
Io non conosco Zimbra, e il problema non è nemmeno il clustered-filesystem. 
Il problema è che qui stiamo parlando di qualcosa di paragonabile al RAC 
di Oracle, cosa assolutamente non supportata da MySQL e/o PostGres.

 di Oracle, cosa assolutamente non supportata da MySQL e/o PostGres.
 
Anche a me questa cosa non convince molto.
Perchè non metti MySQL in HA e /opt/zimbra sotto GlusterFS?
Per switchare da un nodo all'altro cosa pensavi di usare?

 di Oracle, cosa assolutamente non supportata da MySQL e/o PostGres.
 
Mi sono un po' documentato.. sembra che ci siano installazioni in produzione che funzionino ... io comunque opterei per un Attivo / Passivo..
 
-- Yena --


Con MySQL in HA intendi le Repliche ?
 
Normalmente faccio così .. e devo dire che non vanno male, ma è una soluzione che non mi ha mai sfagioalto al 100% per tanti motivi che non sto qui ad elencare..
Sinceramente visti i pochi account (35), se andasse su Gluster mi sembrerebbe più pulita come soluzione e più semplice da manutenere.
 
Un personaggio gentile sul forum di Gluster mi raccontava che ha una soluzione così fatta in produzione, ma con migliaia di account .. mi diceva che il sistema funziona , che incontra qualche problema solo in caso di "rename" .. e molto di rado .. sinceramente non ho capito cosa intendesse..con "rename".
 
Per lo switch userei Pacemaker + Corosync, che già uso su soluzioni Rsync + Repliche e si è sempre dimostrato affidabile.
 
C'è anche DRDB .. ma non lo conosco abbastanza e quindi mi spaventa un po'.
Gluster sono due mesetti che lo provo in stage e mi fa impazzire la possibilità di "disabilitarlo" banalmente tornando ad un sistema basico su ext4.
 
Grazie !
 
-- Yena --
 


Se vuoi lo faccio pure, poi lo scrivo su una wiki pubblica e così troverai 
un'altra fonte in più :)
 
Che possa anche partire, e dare anche parvenza di funzionamento ci posso 
anche credere. 
Che quelli di ScaleDB si siano inventati un lavoro inutile mi pare un po' 
meno credibile.
 
ScaleDB è un prodotto a pagamento che mette a disposizione la tecnologia 
di tipo RAC per MySQL. Cosa lo avrebbero fatto a fare se bastava un 
semplice filesystem clustered?

 intendesse..con "rename".
 
 
cerchiamo di capire che le cose che scrive il tipo del forum sono 
"stronzate", senza se e senza ma:
 
http://forums.mysql.com/read.php?94,269113,269113
 
- Hi, We are launching the beta test of our shared-disk clustering engine. 
Like Oracle RAC and IBM mainframe DB2, we enable multiple nodes to operate 
against a single physical database. This delivers scalability, high-
availability and you don't have to partition your data! 
 
http://www.scaledb.com/
 
ScaleDB is a pluggable storage engine for MySQL. It turns your MySQL 
application into an enterprise-class, highly-available, clustered database 
that scales elastically in a public cloud, private cloud, or on premise. 
ScaleDB is a NewSQL pioneer, delivering the advantages of both SQL and 
NoSQL, while targeting the cloud.
 
Perché la gente usa il partizionamento dei dati che - per dirla con 
Albanese - è uno sfracanamento di cugghiuna?
Perché ScaleDB mette in vendita qualcosa che - secondo l'amico del forum - 
mysql fa già di suo?
 
Pensaci bene prima di mettere in piedi questa cosa.

 Pensaci bene prima di mettere in piedi questa cosa.
 
fai una cosa invece ... va va.... sottoscrivi subito il "beta program" di 
ScaleDB. Magari puoi usare una beta, che è pur sempre meno beta che 
mettere MySQL in RAC :-)  
http://www.scaledb.com/join.html
 

 un'altra fonte in più :)
 
In realtà è un setup supportato ed esistente, ma estremamente limitato:
si appoggiano i datastore su FS clustered e si configura mysql per usare
i meccanismi di locking propri del filesystem (--external-locking) in
luogo dei propri.
 
Si fa e funziona (ma ho i miei dubbi che possa funzionare con gluster:
di sicuro sì con OCFS2/GFS).
 
La limitazione è che supporta solamente MyISAM, ed è comunque setup
sconsigliato da parecchio...
 
 

 
 
ma qui parto con un dubbio, stupido come non mai.
se io apro una tabella per fare operazione_di_modifica_qualsiasi (insert/
alter/drop):
- il DB con Oracle RAC ha l'intelligenza per capire che io sto "loccando" 
solo una tabella.
- il filesystem che intelligenza ha in questo senso? Il DB ti blocca 
l'intero datafile di 40 petabyte :-)
 
Per cui - stupido come sono - mi aspetto che con un lock a livello di 
filesystem, io blocco tutto il DB in fase di scrittura.
 
E QUINDI: che vantaggi ho dal punto di vista delle performance con un 
sistema simile :)
Ecco perché qualcuno (ScaleDB) sta seriamente pensando di lavorare a 
livello DB su questa cosa.
 
Dico bene oppure ho detto una sciocchezza?

 l'intero datafile di 40 petabyte
 
ovviamente volevo scrivere: il filesystem ti blocca l'interno datafile.

 filesystem, io blocco tutto il DB in fase di scrittura.
 
In myISAM 1 tabella == 1 file
 
 


cribbio hai ragione.
Bisogna però vedere come viene acquisito un eventuale lock sui log in fase 
di modifica ... che corrisponderebbe ad un lock dell'intero DB.

 di modifica ... che corrisponderebbe ad un lock dell'intero DB.
 
Quale log? Come detto da Skull, MySQL = 1file per tabella (in myisam, ma tramite l'opportuno settaggio anche in InnoDB). Se il log al quale fai riferimento è il binario usato dalla repliche, voglio sperare che una configurazione del genere non venga anche sottoposta a replica. E comunque sia non credo che un lock del binary blocchi l'intero database (e poi rientriamo nella gestione gluster, ci pensa lui a fare il lock)
 
Piuttosto non mi è chiara una cosa, avendo usato gluster in passato per alcuni test: siam sicuri che gestisca scritture concorrenti sullo stesso file? In soldoni, posso usare un mbox condiviso da 15 nodi?

 stesso file? In soldoni, posso usare un mbox condiviso da 15 nodi?
 
Indipendentemente dal fatto che usi gluster o no, un setup del genere
con mbox � suicida :-D
 
Anzi, oggi come oggi il fatto stesso di usare mbox � suicida...
 
Ma a parte quello boh: in tutta sincerit� non lo userei mai per un setup
che comprenda un DB, n� in failover n� (mai e poi mai) in active/active
(quand'anche mysql o qualsiasi altro db supportasse un setup di questo
genere).
Piuttosto il classico setup in failover con datastore in drbd...
 
 
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 

 Piuttosto il classico setup in failover con datastore in drbd...
 
Anche io.

 file? In soldoni, posso usare un mbox condiviso da 15 nodi?
 
Non so quanto sia evoluto GlusterFS. 
GPFS gestisce la scrittura concorrente e la gestisce in modo atomico. Pertanto una scrittura o va tutta, o viene rifiutata del tutto e FIN QUANDO NON VA TUTTA, sull'altro nodo non vedi nulla.

 GPFS gestisce la scrittura concorrente e la gestisce in modo atomico. Pertanto una scrittura o va tutta, o viene rifiutata del tutto e FIN QUANDO NON VA TUTTA, sull'altro nodo non vedi nulla.
 
Sono due software diversi per due usi diversi.
Appunto che mi stupisce il fatto di poter scrivere in simultanea sullo stesso file con glusterfs.
 
AFAIK, Gluster si usa per creare una SAN distribuita e scalabile orizzontalmente con hardware commodity.

 orizzontalmente con hardware commodity.
 
Appunto: per una SAN è sicuramente OTTIMO. Ma tu mi vuoi mettere una 
tecnologia tipo RAC in una SAN, con il collo di bottiglia dei protocolli 
di rete?

 di rete?
 
Io? Io non voglio fare nulla, non sono io l'autore del thread. :)
Io sono in primo a dire che usare GlusterFS per ridondare un datastore MySQL significa mettersi a 90.
 
e sono anche un accanito sostenitore del: "secondo me gluster non protegge l'accesso concorrente in scrittura allo stesso file", ma su questo potrei sbagliarmi
 
IMHO, GlusterFS va inteso come versione scalabile e resiliente di NFS e non come FS clustered tipo OCFS e simili.