Newsgroup: it.comp.os.linux.sys
Titolo: Copia bit-to-bit di un grosso file in uso

 
Salve a tutti, sono alla ricerca di un software o un servizio che sia in 
grado di copiarmi dei file da un host all' altro in modalità bit-to-bit. 
Questo perchè i files sono in uso da un servizio e devo creare una copia 
costante di questi file.
Si tratta di una grossa quantita di dati, decine di file da 2GB l'uno, sono 
dischi virtuali di VMWare GSX server, il tutto mi serve per creare una 
macchina immediatamente attivabile in caso di stop della macchina primaria, 
di conseguenza il servizio deve fare anche del caching dei bit che deve 
passare.
In ambiente M$ è possibile acquistare un software che si chiama  NSI 
Doubletake  che fa il lavoro, ma in ambiente Linux esiste qualcosa?
grazie a tutti ovviamente e buona serata 

Forse posso dire una gran c...a.
Hai un server con linux installato e presuppongo con gli hard disk in 
mirroring.
Hai pensato l'eventualità di costruire un cluster HA? Dovrebbe essere la 
soluzione hai tuoi problemi. Io condividererei un array di dischi (raid1 + 
stripe) tra le due macchine...
Vedi tu cosa puoi fare e sopratutto il budget a tua disposizione. Sai che 
con linux le vie sono infinite...
Spero solo di non averla fatta fuori dal vaso...
Ciao, Keres.

 Doubletake  che fa il lavoro, ma in ambiente Linux esiste qualcosa?
se vuoi una soluzione supportata usi il vmotion di vmware , in alternativa
un semplice cp/ftp/scp funziona lo stesso , con il difetto che comunque le
vm ripartono come se gli avessi staccato la spina.
ps: x fare questi giochi di solito si usa esx in cluster con uno storage
fibra.
ciao.
-- 
SVENIRE - Avere un orgasmo al di fuori della sede piu' ideonea.

 dischi virtuali di VMWare GSX server,
non puo' funzionare, e se funziona e' per puro culo.
La copia di un file da 2G non e' "istantanea" , neanche con le macchine di
oggi.
Se il file e' "in uso"  [1]
vuol dire che un programma ci sta lavorando sopra, lo sta modificando in
varie sue zone,
(puo' essere una tabella di un database, o un'immagine di vmware) fatto sta
che presa una istantanea del file in un certo momento, non e' certa la
"congruenza" dei dati ivi contenuti per il
software che lo deve usare.
Mi spiego: anche se riesci a fare una foto di una tabella mysql da 2G, chi
ti dice che nel bel mezzo della foto
mysql non stesse facendo una query che stava modificando una valanga di
record, e non avesse finito?
chi ti dice che non stesse aggiungendo un singolo record, e che nel momento
della foto il lavoro
non fosse svolto "a meta' "?
Chi ti dice che quando copi il file da 2G di vmware tu non l'abbia colto in
una operazione di memory swap
lasciata a meta' cosi' quando riaprirai la copia con vmware ti andra' in
crash perche' il file e' copiato si',
ma i dati non sono congruenti?
Nota: se fai un backup con tar di un grosso file e un altro programma lo
modifica nel mentre,
tar esce dicendo che qualcuno ha modificato il file mentre lo stava
copiando...
Le soluzioni sono varie:
se puoi interrompere l'erogazione del servizio, lo stoppi, fai il backup, lo
riattivi
(io faccio cosi' con un db mysql, perche' una volta al giorno, di notte, non
e' importante se non e' accessibile per 2 minuti)
Se non puoi interrompere l'erogazione, ti serve una soluzione RAID,
perche' le fread e fwrite contenute nel software che sta girando diventano
atomiche
rispetto alla scrittura contemporanea su piu' dischi.
Avere qualcosa di analogo al RAID ma su macchine diverse e con operazione di
copia,
e' direi io, ciarlataneria.
Altro che "Doubletake". Al massimo, questo software permette la copia di
files lockati sotto windows,
ma la congruenza rimane a tuo carico.
[1] "in uso" uguale "un programma lo sta usando e modificando"
    "in uso" diverso da "esistono meccanismi di lock di qualche tipo"

 atomiche rispetto alla scrittura contemporanea su piu' dischi.
Whaaat?
-- 
 Daniele Orlandi                                                        つづく

 vm ripartono come se gli avessi staccato la spina.
Non è vero, possono essere molto più inconsistenti.
Se usi un filesystem journalled questo si aspetta che gli "fsync" sul log e
sui dati siano onorati in *sequenza* ma la sequenza non corrisponde
all'ordine fisico dei settori.
Ciao,
-- 
 Daniele Orlandi                                                        つづく

> Whaaat?
Forse e' troppo criptica.
fopen(file)
fwrite(tanta roba)
fsync(file)
dalla man page di fsync/fdatasync:
"fsync copies all ic-core parts of a file to a disk, and waits until the
device reports that all parts are on
a stable storage"
Essendo il raid gestito a livello hardware (o software, di kernel),
io interpreto un raid come un device unitario dal punto di vista dei
programmi user,
per cui mi aspetto che dopo fsync il file sia stato scritto su *tutti* i
dischi del raid.
Correzioni da chi ne sa di piu' sono ben accette...

 dischi del raid.
certo solo se il raid e' di un certo tipo etc etc etc...

 dischi del raid.
Ok, ma questo cosa ha a che fare con il poter fare uno snapshot consistente
di un file in uso?
Ciao,
-- 
  Daniele Orlandi

 di un file in uso?
il senso era questo:
se vuoi avere una "forma" di backup (intesa come sicurezza) dei dati su
diversi supporti fisici (diversi hd)
quando i dati sono perennemente in uso e senza interrompere il servizio,
puoi considerare solamente il raid (del tipo adeguato).
Ovviamente non si parla piu' di snapshot di un file in uso (e non c'entra
nulla);
voleva solo indicare una soluzione al problema originario, che era parasi il
sederino
se l'unico supporto fisico usato va in malora..
e sottolineare come la banale copia-dei-files *non potesse* essere una
soluzione,
in qualunque salsa..
ciao.

 passare.
Su ESX si usa 
vmsnap.pl
 per fare snapshot di macchine virtuali.
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 soluzione, in qualunque salsa..
Può essere una soluzione, devi solo assicurarti che la copia sia
consistente, siamo d'accordo che in questo caso una copia con "cp" non può
esserlo.
Ciao,
-- 
  Daniele Orlandi

 all'ordine fisico dei settori.
di solito non ho mai avuto grossi problemi , tanto il check è obbligatorio ,
cmq in alternativa c'è un tool che tramite l' uso dei dischi virtuali non
persistenti fa' il backup a caldo , non l'ho mai provato ma mi pare si
chiami vmback o qualcosa del genere.
-- 
"Le lacrime sul viso sono utili perche' lavano la faccia."
                -- Mastroianni

 grado di copiarmi dei file da un host all' altro in modalità bit-to-bit. 
Con il drbd puoi configurare un mirroring via rete di dispositivi,
quindi puoi sincronizzare la partizione contenente i dischi virtuali tra
due host.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 passare.
Puoi vedere DRDB (è un progetto collaterale di 
linux-ha.org
), e per ridurre
la quantità dei dati da copiare puoi o provare a usare degli snapshot di
LVM2 come dischi dati di VMWare, oppure vedere se VMWare stesso ha una
modalità di snapshot (QEmu ce l'ha).
Non so come sia l'interazione tra gli snapshot di LVM2 e DRDB.
In ogni caso, mi pare una configurazione assai strana la tua, i dati
dovrebbero essere non ospitati sui server ma su una NAS/SAN e le due
macchine operanti in alta affidabilità.
-- 
Per rispondermi, togli il nome del poeta

 nulla);
Veramente è proprio la soluzione da adottare: una copia di una immagine
"zero" e la sincronia delle differenze (snapshot) di quella immagine.


 dischi del raid.
Questo non è certo sufficiente, perchè se il filesystem non ti offre il
concetto di transazione non hai nessuna garanzia. Peraltro, nel caso di raid
software, non c'è nemmeno una reale garanzia sul fatto che una operazione di
scrittura sia stata eseguita su tutti i dischi, tanto che i sistemi RAID
hardware hanno non casualmente memorie cache alimentate a batteria.
