Quoting Vali Dragnuta <[email protected]>:
Pt. fraza asta geniala, care exprima cel mai bine, ideea de baza din topic iti multumesc din tot sufletul! Daca vrei sa testezi zfs, te ajut cu tot ce stiu eu mai bine. > Culmea e ca eu la rindul meu sint zfs sceptic, atit pentru motivul de > mai sus referitor la sansele de recovery atunci cind chiar se duce in > balarii cit si pentru ca nu-l pot folosi "normal" sau "oficial" pe > kerneluri linux (sa stau sa-l builduiesc de mina nu mi se pare > convenabil). Se pot evita astfel de situatii cred eu(sau se poate reduce impactul). ZFS stie ceva ce se numeste send/recive. Daca ai minim 2 masini cu ZFS, dresezi masina A sa faca snapshoot-ri incrementale din x in x minute(0 downtime, resurse consumate aproape zero, dureaza cateva secunde, de exemplu la un pool cu 1 Tb de date).Apoi de pe A se face send catre B care face receive(e practic un stream de blockuri) pe ce transport vrei tu(ssh,netcat,etc). Evident prima data dureaza mult(daca volumul de date e mare). Eu ma duc cu send/recevie via ssh cam la 7-800 mbits. Daca pool-ul respectiv are activata si compresia(si datetele pe care le pui in pool sunt comprimabile gen fisiere text), volumul de date de transferat se reduce. Alta varianta e faptul ca poti face sapshoot-ri la un intreg pool sau la un data-set anume din acel pool(complet sau incremental, sau combinatii). Eu de exemplu fac cate un snapshot complet saptamanal, si in rest fac incrementale(din 5 in 5 minute, si retin toate snapshot-le din ultimile 48 ore, ultimile 14 zile, ultimile 6 luni). Snapsot-le se pot monta RO sau RW, sau chiar din ele se poate face un roll-back la un pool/data-set intreg. Deci daca se corupe ceva, ai sanse ca sa si recuperezi la o adica. Urmaresc lista de discutii de la zfs-onlinux, cam de aproape un an(cred ca citesc cam 80% din mesajele care apar), dar nu imi aduc aminte, ca careva sa se fi plans ca s-ar fi corupt datele deodata, si in volume mari, incat sa piarda tot, decat in cazuri normale(raid5=raidz, pe 3 HDD-ri, si a pierdut 2 HDD-ri). Nici eu nu exclud totusi ca ar putea exista aceasta varianta. De aceea, cel putin deocamdata, ma asigur asa(sunt toma necredinciosul): - snapshot-ri cum am zis; - send-recive intre masini cu zfs; - update de kernel nu pe toate masinile odata(cate o masina la 3 zile); - backup cu rsnapshot(zilnic, noaptea); - verificari ale pool-lor saptamanal(zfs scrub pool -> erori pe mail) - scripturi care ruleaza din 5/5 minute si-mi trimit erorile care sunt raportate de ZFS(zpool status -v) in timpul operarii ; Deocamdata am mare incredere in ZFS, dovada ca am in regim de productie 8 servere(la clienti diferiti). Motivele pentru care am trecut la ZFS su fost: - managementul extraordinar si detailat la nivel de volum manager(quota, compresie, rezervare de spatiu), si partea de snapshot. - folosesc multe montari separate, deci am aplicatii/servicii pe propriul file-sistem sau block-device(fiecare container openvz pe un block-device separat formatat ext4, samba pe un data-set=FS nativ ZFS, squid, samd) - am sisteme cu 20-30 de data-set-ri, fiecare cu proprietati potrivite pt. acel serviciu(la FS-ul de squid, am activata compresia, la niste containere KVM bazate pe win nu am compresie activata, la un container openvz care are mysql am /var/lib/mysql recordsize=8K (ZFS default is 128k), samd). Eu folosesc / am in ograda in general servere no-name, achizitonate pe criteriul pret, si cu probleme la curentul electric(spatamanal pica curentul, in special iarna si toamna). De fapt sunt desktop-ri mai rasarite, cu HDD-ri de tip desktop(nu green). Aveam md raid1, si mi se intampla des(1 data la 2 luni/sistem), sa-mi iasa din raid discuri-le. Si al mano', le bagam din nou, si asteptam cateva ore pana se re-sincronizau(si o resincronizare in timpul zilei insemna telefoane ca "merge incet copierea pe ..."). Acum pe ZFS nu mai am problema asta. Am clienti care isi sterg des fisiere(inclusiv mail-ri), si apoi le vor inapoi(le restaurez din snapshot). Am testat si asa: masina cu ZFS, reinstalat SO, pus suport de zfs, datele au ramas si au fost OK. Am luat disc-ri cu ZFS, si le-am montat pe alta masina, cu ZFS, am avut datele OK.... Din tot ce am zis eu, nu inseamna ca ZFS-ul nu are probleme, are in special pe partea de performanta. Dar si aici se poate imbunati situatia, daca bagi un SSD(folosit pe post de cache de citire, in stilul squid). Nu are viteze extraordinare la scriere. As zice ca este acceptabil, in special acolo unde sunt date compresibile(baze de date, care fiind text se comprima f. bine). Uite o "inginerie" facuta pe ZFS, care mi-ar fi luat o groaza de timp pe altceva: - aveam un ZFS cu mirror(2 disk-ri); - am trecut de la mirror la raidz(3 disk-ri, rid5 cu paritate); - apoi am trecut de la raidz la raidz2(4 disk-ri, raid5 cu paritate dubla); Scuze daca te-am plictisit, si inca odata MULTUMESC. Daca treci prin Brasov, esti invitatul meu la o bere!!! > Dar trebuie a recunosc ca cel putin la capitolul asta cu > validarea datelor citite are un avantaj, si mi se pare o prostie sa > argumentezi ca un sistem de securitate in plus este prost pentru ca tu > tii la datele tale si ai cabluri bune si hardware de top. > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ================================ ATENTIONARI ============================= - pentru atasamente tip Office va rugam sa folositi format OFFICE 97; - nu trimiteti date personale (CNP, copii dupa acte de identitate etc). O lista completa cu reguli de utilizare exista la: http://gw.casbv.ro/forum_smf/index.php?topic=2000.msg3106#msg3106 C.A.S.J. Brasov - B-dul Mihail Kogalniceanu, nr. 11,Brasov [web-site]: http://www.casbv.ro [forum]: http://gw.casbv.ro/forum_smf/index.php ========================================================================== _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
