Newsgroup: it.comp.os.linux.sys
Titolo: HA con linux... file aperti?

scenario:
un server con DRDB (
http://www.complang.tuwien.ac.at/reisner/drbd/
) e 
heartbeat che fornisce un servizio di file server tramite samba ad una 
rete di client windows.
domanda:
come si comporta drbd se dovesse replicare dei files che sono aperti da 
un client? nello specifico, dove lavoro ci sono dei frontend che 
accedono a paradox, che usa file .db  e file di indici condivisi in rete 
su un'unica macchina novell (al momento).
tnx
-- 
signature: No such file or directory


Ci stavo giusto guardando ma sto ancora cercando di capire bene cosa fa nel
dettaglio, comunque da write access a solo un server alla volta, quindi
credo che non li replichi .... se riesci a scoprire 
q.sa
 di più fammi
sapere, lo stesso farò io.
Dave
--------------------------------
Inviato via 
http://usenet.libero.it

Sgranocchiando il cranio di Denny, vi trovai inciso:

Poco gli frega che il file sia aperto o chiuso (o anche corrotto), visto
che si occupa di replicare il block device e non i files in sč...
Ammesso che io abbia capito correttamente la domanda...
-- 
Emanuele Balla  aka Skull -  Public Key #661E5CBF on 
www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

 Ammesso che io abbia capito correttamente la domanda...
si, credo che tu abbia capito correttamente la domanda. temo invece di 
non aver ben capito io la risposta :)
se un file e' aperto in scrittura, ma le (eventuali) modifiche non 
ancora scritte su disco e drdb replica il block device, cosa mi trovero' 
sulla macchina slave?



temo il file senza modifiche finche non sono scritte su disco, ma c'č as
esempio l'opzione sync che scrive tutto subito su disco (opzione di mount),
dovrebbe andare bene per te. In quel caso lower performance ma piů garanzie
di replicazione dei dati.
Dav


 il block device, cosa mi trovero' sulla macchina slave?
Esattamente quello che ti ritroveresti su una macchina normale
staccandogli la spina mentre lavora.
Ovvero un filesystem in stato non coerente.
Questo è il motivo principale per cui qualsiasi shared media di un
cluster HA utilizza un filesystem dotato di journaling.
Se poi i dati non sono scritti perchè l'applicazione li tiene in ram,
beh, è un problema dell'applicazione, che non va bene per essere
clusterizzata.
Se chi invece si sta tenendo i dati in ram è una applicazione client, la
quale sta aspettando di scrivere sulla network share esportata dal tuo
samba, beh il problema è diverso:
il file sullo shared media è nello stato in cui dovrebbe essere.
Il problema è casomai il fatto che samba, traslando da un nodo all'altro,
non ha modo di traslare anche quanto tiene in ram per suo uso interno
(es: le struct dei vari socket aperti, i lock, e così via). Per cui il
client potrebbe poi non essere in grado di scrivere correttamente su
samba perchè fa uso di una sessione che samba non conosce (gliela aveva
assegnata l'altro...).
Qui però ci allontaniamo dal topic...


 di replicazione dei dati.
sync funziona solo con ext2 e 3, pero'... o sbaglio? effettivamente 
leggendo la doc di drbd, l'opzione sync permette ai dati in memoria di 
essere scritti immediatamente. la cosa e' trasparente (e funziona) se 
utilizzata attraverso samba o c'e' qualche problema?
ri-tnx.


 assegnata l'altro...).
giusto... mi stai dicendo che non c'e' soluzione definitiva ad un 
problema di questo tipo, eh? :) ipotizzando di migrare l'applicazione su 
un dbms come mysql o postgresql la situzione cambierebbe in meglio, o no?
grazie mille, ciao.


 no?
AFAIK i dbms transazionali sono nati per questo, praticamente...


 un client?
Dipende ovviamente dall'applicazione. Tutto quello che viene scritto sul 
disco della macchina master verra` replicato sul disco della macchina slave.
E ovvio che se l'applicazione non scrive sul disco non avrai la replica.
In particolare Drbd ti permette di scegliere tre livelli di rapporto
prestazioni/sicurezza di replica:
Protocol  Description
A         A write operation is complete as soon as the data is written to 
          disk and sent to the network.
B         A write operation is complete as soon as a reception 
          acknowledgement arrives.
C         A write operation is complete as soon as a write acknowledgement 
          arrives.
Il protocollo C e` il piu` lento ma e` quello che ti offre la maggiore
sicurezza sulla replica.
Tieni conto che le partizioni replicate *non* sono montate sulla macchina
slave e per accedere ai dati sullo slave bisogna fare (in qualche modo)
un fsck. Quindi o ext2+fsck o fs journaled.
-- 
Vincenzo

 un fsck. Quindi o ext2+fsck o fs journaled.
heartbeat non dovrebbe supplire a questo? o meglio, non dovrebbe rendere 
disponibile la macchina slave in caso di downtime della macchina master?


 AFAIK i dbms transazionali sono nati per questo, praticamente...
nono, ok. intendevo usare *comunque* una soluzione di clustering; un 
dbms, una volta eseguita una query o una serie di query INSERT, scrive i 
dati su disco (chiaramente a patto che la transazione sia andata a buon 
fine). anche se la connessione con il client e' attiva, i dati sono gia' 
scritti, quindi pronti per essere replicati via drbd. non c'e' la 
necessita di tenere files aperti a lungo.
comunque mi hai chiarito un paio di concetti su cui ero dubbioso. ti 
ringrazio :)
ciao!


 disponibile la macchina slave in caso di downtime della macchina master?
Certo, volevo solo far notare che le partizioni replicate sullo slave sono 
'monopolizzate' da Drbd e non 'montabili' finche` il master funziona.
Questo fornisce una discreta garanzia sul fatto che le partizioni slave
saranno una replica fedele di quelle master.
-- 
Vincenzo

 c'e' la necessita di tenere files aperti a lungo.
Si, ok, ma io mi riferivo al fatto che i DBMS transazionali tendono ad
essere più robusti da questo punto di vista, poichè il log è la prima
cosa che viene scritta; nè più nè meno che per i filesystem journaled.
Chiaro che non ti salva da un crash della macchina, ma ti dovrebbe
garantire, in linea di massima, che quello che è stato scritto sia
ancora lì quando vai a rimontare il disco (fs permettendo).
Per inciso, fossi in te considererei anche il clustering tramite
replicazione del db (nella maniera nativa che il dbms ti consente, se
te lo consente), che come soluzione tende a essere più fault tolerant
rispetto al clustering HA con drbd o shared storage, visto che si
affida a metodi "meno empirici" ;-)
Va da sè che ha i suoi svantaggi e che si applica solo al db...
Sta a te (detto da chi 'sto lavoro l'ha fatto comunque con postgres su
shared storage scsi)...
Ciao!


 scritti, quindi pronti per essere replicati via drbd. non c'e' la
Di piu`, usando il protocollo C hai la certezza assoluta che i dati siano
stati replicati gia` alla fine dell'operazione di write.
Con il protocollo C ogni write del sistema operativo viene completata
solo quando i dati sono stati correttamente scritti anche sulla partizione 
slave.
-- 
Vincenzo

 shared storage scsi)...
:) ok, grazie!
