ZFS - sta se desava kad pobrljavi?

[orange47]

RAID5 i RAID0 ne mogu da se porede, jedan je za redudansu, drugi nije, ali tu je jedino tacno da je RAID0 brzi za upis (naravno, iskljucivo ako govorimo o istom broju diskova!).

pa ne, RAID5 ima disk vise.

 

[alfaunits]

Onda opet to pada u vodu, tj. nije upis sporiji, sem za random write access koji prevazilazi velicinu kesa sve vreme.

Previse ima tu slucajeva, nemoj dalje pokusavati....

 

[kovacm]

ali RAID5 drzi parnost i podatke na sva tri diska.

daj alfaunitse reci Orangu cime se bavis profesionalno!

alfaunits je, kao sto je npr. audiofreak za x86, profesionalac kad su u pitanju diskovi i fajl sistemi - to radi za zivot i ocigledno je odlican u tome (kad to radi vec... koliko godina)?

i alfaunitse, mogao bi malo da olabavis prema orangu* - ko zna za sta ce ti trebati njegove specijalnosti u buducnosti
(*mogao si nam reci, u kranjem slucaju, cime se bavis na pocetku threada ... ja znam, pa ne pametujem mnogo nego slusam sta kazes )

 

[alfaunits]

Jooooj, ja sam zaboravio da sam u threadu u LiMuxu pomenuo da vec 12+ godina PRAVIM file sisteme (Primarno clustered FS, i to u doba kada ni na Linuxu nije postojalo nista pametno)
Ja sam mislio da je to ovaj thread

Ja rekoh dovoljno je sto kovac prihvata sta kazem, cak i kada je Windows u pitanju

 

[zeleni_zub]

I u EMC-u rade profesionalci i ne slažu se sa alfaunits-om.
RAID5 zahteva više write IO operacija od RAIDa 10 ili 1. Pretpostavljati da će cache-a na storage-u uvek biti dovoljno je pogrešan pristup. Pogledajte stranu 13: https://www.emc.com/collateral/white-papers/h12682-vnx-best-practices-wp.pdf

Što se tiče ZFS-a, nemam iskustvo za OpenZFS-om ili ZOL-om (ZFS on Linux), ali sam dosta radio za Sun/Oracle ZFS-om na Solarisu. Da odgovorim na pitanje sa početka thread-a: ZFS je prilično robustan enterprise file system i vrlo je malo verovatno da će doći do oštećenja zpool-a (od Solarisa 11 je ovo jedini podržan fajl sistem za sistemske diskove). Prvo, svi blokovi imaju checksum koji se proverava pri svakoj operaciji. U slučaju da je došlo do korupcije podataka (zbog recimo neispravne memorije na kontroleru) ZFS će u pozadini kopirati taj blok sa druge lokacije (ako postoji redundansa) - ista operacija kao kada radi resilver zpool-a. Druga stvar koja ga čini prilično robusnim je to što je ZFS copy on write file system. Upisani podaci na disku se nikada ne modifikuju. Ako je potrebno izmeniti neke podatke, ceo blok se pročita, izmeni i ponovo upiše na novu lokaciju, izmene se pointeri i tek na kraju upiše novi uberblock koji pokazuje na to novo izmenjeno stablo. U slučaju da dođe do bilo kakvog problema u bilo kom koraku pri toj transakciji, uberblock i dalje pokazuje na staro stablo koje nije menjano. Zbog ovog mehanizma ZFS je uvek u konzistentnom stanju. Isti mehanizam koriste snapshot-ovi - jednostavno se prekopira uberblock u trenutku pravljenja snapshota, pošto se blokovi ne menjaju, ti blokovi koji se trenutno nalaze u stablu čine taj snapshot - i neće biti obrisani sve dok snapshot postoji. Takođe kod raidz-a je širina stripe-a dinamička tako da je svaki upis full stripe write i ne postoji write hole.

Ako nekim slučajem dođe do oštećenja zpool-a koje ZFS ne može sam da popravi (što ja u praksi nikada nisam video) ostaje ti samo da otvoriš service request kod Oracle-a. Ili ako koristiš OpenZFS da dobro proučiš kod i da kreneš da kopaš po fs-u zdb-om.

Kao što je ness1602 napisao ZFS je enterprise fs i zahteva prilično dosta resursa i relativno dobro poznavanje platforme na kojoj radiš. Napravljen je da bi omogućio neke prilično dobre feature u Solarisu i da zameni matoru UFS/SVM kombinaciju, a ne da bude jednostavan.

Zbog copy-on-write tehnologije, ZFS-u treba dosta više IOps-a ako se upisuju podaci u blokovima manjim od ZFS block siza-a. Recimo, default block size je 128k, a ti imaš random write operacije koje upisuju 2k. Svaki put kada upisuješ 2k, pročitaće se blok od 128k, i upisati novi blok od 128k. Takođe, vrlo često je potrebno promeniti dosta podešavanja na samom fs-u ili u Solaris kernelu da bi se dobile optimalne performanse, što zahteva dobro poznavanje ZFSa i operativnog sistema.

Definitivno nije bezbednije držati podatke na NTFS-u nego ZFS-u, samo je pitanje da li si spreman da platiš cenu u performansama. Ako se radi o home NAS-u, ja bih razmatrao neke druge opcije a ZFS bih ostavio za ovakve mašine: http://www.oracle.com/us/products/s...s/sparc/oracle-sparc/t5-4/overview/index.html.

edit: Jedini benefit koji bi imao je end-to-end checksums/selfhealing data i eventualno deduplikacija, kompresija i enkripcija, a to ti baš i nije preterano važno ako ti na njemu stoje filmovi. Svi ostali feature-i su relevantni samo ako koristiš Solaris.

edit2: Bez ECC memorije end2end checksums imaju vrlo malo smisla.

 

[alfaunits]

I u EMC-u rade profesionalci i ne slažu se sa alfaunits-om.
RAID5 zahteva više write IO operacija od RAIDa 10 ili 1. Pretpostavljati da će cache-a na storage-u uvek biti dovoljno je pogrešan pristup. Pogledajte stranu 13: https://www.emc.com/collateral/white-papers/h12682-vnx-best-practices-wp.pdf

A gde sam ja rekao da RAID5 ne zahteva vise WRITE IOP od RAID1/10?

Prvo, svi blokovi imaju checksum koji se proverava pri svakoj operaciji. U slučaju da je došlo do korupcije podataka (zbog recimo neispravne memorije na kontroleru) ZFS će u pozadini kopirati taj blok sa druge lokacije (ako postoji redundansa) - ista operacija kao kada radi resilver zpool-a.

Ovo nije obavezna stavka, tj. treba da se enabluje. A ECC samih PODATAKA je vec prilicno skupa operacija, i ubice IOPS. (drugo je metadata checksum, jer je to mnogo manje podataka)

 

[zeleni_zub]

A gde sam ja rekao da RAID5 ne zahteva vise WRITE IOP od RAID1/10?

Moguće da se radi o nesporazumu:

RAID5 nije sporiji od JBODa, osim u retkim specificnim slucajevima.
RAID5 nije sporiji od RAID1 za upise, opet osim u specificnim situacijama.

Meni "brzina storage sistema" označava koliko brzo storage može da izvrši IO zahteve koji dolaze od operativnog sistema u nekom generalnom slučaju (mix workload) ako nije naveden specifičan scenario. Čini mi se da u praksi ima mnogo više kombinovanog i iops intensive workload-a, a da su low iops/high throughput specifični slučajevi (bekapi recimo).

Ovo nije obavezna stavka, tj. treba da se enabluje. A ECC samih PODATAKA je vec prilicno skupa operacija, i ubice IOPS. (drugo je metadata checksum, jer je to mnogo manje podataka)

Na ZFS-u je checksum po default-u uključen (i za data i za metadata - za sve blokove). Postoji opcija da se isključi, ali apsolutno nije preporučeno od strane Oracle-a.

http://docs.oracle.com/cd/E26502_01/html/E29007/zfsover-2.html (Checksums and Self-Healing Data)

http://docs.oracle.com/cd/E26502_01/html/E29007/gazss.html#scrolltoc ili man zfs (checksum - Controls the checksum used to verify data integrity. The default value is on, which automatically selects an appropriate algorithm, currently fletcher4. The values are on, off, fletcher2, fletcher4, sha256, and sha256+mac. A value of off disables integrity checking on user data. A value of off is not recommended.)

Nisam još čuo za slučaj da je neko isključio checksum na produkcionim mašinama.


edit: Zaboravio sam da napomenem u prethodnom postu na još jednu stvar na koju treba obratiti pažnju. Kada se transakcija upiše u ZIL ZFS šalje flush cache komandu diskovima. Uglavnom storage sistemi koji imaju mirrorovan write cache ovu komandu ignorišu, ali kod sistema koji stvarno rade flush dolazi do ozbiljnog pada performansi.


Koga zanima:

Oracle Solaris 11.1 Administration: ZFS File Systems: http://docs.oracle.com/cd/E26502_01/html/E29007/toc.html
ZFS Evil Tuning Guide: http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide (malo stariji dokument, ali je dosta stvari i dalje aktuelno)

 

[alfaunits]

Moguće da se radi o nesporazumu:

Meni "brzina storage sistema" označava koliko brzo storage može da izvrši IO zahteve koji dolaze od operativnog sistema u nekom generalnom slučaju (mix workload) ako nije naveden specifičan scenario. Čini mi se da u praksi ima mnogo više kombinovanog i iops intensive workload-a, a da su low iops/high throughput specifični slučajevi (bekapi recimo).

Ne moze se generalno pricati o Mixu, jer je to specificno za svaku potrebu. Za potrebu ove teme je to samo sekvencijalno (u stvari za kovaceve potrebe), gde je RAID1 los izbor skroz.
A kada ce Mix biti vise u korist RAID1 naspram RAID5, ne znam napamet iskreno. Zavisi prilicno od cache-a, i kolicine workloada. Ako se cache retko puno, RAID5 je bolje resenje.

Na ZFS-u je checksum po default-u uključen (i za data i za metadata - za sve blokove). Postoji opcija da se isključi, ali apsolutno nije preporučeno od strane Oracle-a.

Za potrebe kucnog NAS uredjaj za filmove?
Ako to ima ukljuceno kovac, kladim se da to usporava debelo (ne 10x, ali ipak primetno - CPU intensive je)
Ali zasto je po defaultu kada nema redudanse? Odakle ce vratiti podatke?

Nisam još čuo za slučaj da je neko isključio checksum na produkcionim mašinama.

Verujem. Nema logike za ZFSom ako se iskljuce osnovne korisne stvari.

Uglavnom storage sistemi koji imaju mirrorovan write cache ovu komandu ignorišu, ali kod sistema koji stvarno rade flush dolazi do ozbiljnog pada performansi.

LSI bi trebao biti medju ovom grdjom grupom za performanse Ali ozbiljni serveri obicno traze sigurnost na prvom mestu.

 

[ness1602]

Ukratko, ZFS nije za korisnike ovog foruma a i sire verovatno. Mnogo je to ozbiljnija prica, a ako pravis kucni/soho server nema potrebe da to bude.

 

[zeleni_zub]

Ne moze se generalno pricati o Mixu, jer je to specificno za svaku potrebu. Za potrebu ove teme je to samo sekvencijalno (u stvari za kovaceve potrebe), gde je RAID1 los izbor skroz.
A kada ce Mix biti vise u korist RAID1 naspram RAID5, ne znam napamet iskreno. Zavisi prilicno od cache-a, i kolicine workloada. Ako se cache retko puno, RAID5 je bolje resenje.
Za potrebe kucnog NAS uredjaj za filmove?

Nisam pažljivo pročitao sve njegove postove. Da, ako će NAS koristiti za arhiviranje velikih fajlova RAID5/6 je najbolje rešenje.

Kovac, ti si napravio tri zpool-a od tri diska? Imaš po jedan disk u pool-u? Ili si od slajsova pravio pool-ove? U svakom slučaju nije dobra konfiguracija. Preporuka je da se celi diskovi koriste kao vdev-ovi, tako da bi trebao od tri cela diska da napraviš jedan raidz pool. Takođe ako koristiš velike SATA diskove proveri da li ti je ashift dobro podešen.

Ako to ima ukljuceno kovac, kladim se da to usporava debelo (ne 10x, ali ipak primetno - CPU intensive je)
Ali zasto je po defaultu kada nema redudanse? Odakle ce vratiti podatke?

Pretpostavka je da redundanse ima, tj. da ćeš imati bar dva diska u mirror-u u zpool-u. U slučaju da nema redundanse i dalje postoji detekcija silent data corruption grešaka, samo nije u stanju da ih koriguje. I to dosta znači - neće serveru vratiti pogrešan podatak, nego ćeš videti grešku i imaćeš priliku da vratiš podatke iz bekapa. Što se tiče CPU zahtevnosti, predviđen je da radi na serverima, tako da u tom kontekstu i nije puno zahtevan. Solaris se uglavnom koristi na SPARC mašinama - jedan T5 procesor ima 16 jezgara na 3.6Ghz sa po 8 tredova - ne primetiš uopšte zpool proces. Na novim Xeonima je slična priča (sporiji su, ali opet ne postoji neki problem sa zpool-om), mada su x86 Solaris instalacije dosta ređe.

ZFS možeš primarno da posmatraš kao file system na kome je instaliran Solaris: imaš jednostavan (za upotrebu) i vrlo moćan volume management, full checksum, enkripciju, deduplikaciju, mogućnost kreiranja blok device-ova (zvol) na već postojem zpool-u, integrisacija sa pkg managerom i boot environmentima, itd... Recimo kada uradiš neki apdejt, automatski se pravi novi zfs fs na kome je novi boot env., apdejtuje se sistem na u tom novom boot env.-u i samo se pri sledećem restartu Solaris podigne sa njega. U slučaju da moraš da uradiš rollback - samo podigneš sistem sa starog boot env-a. To su feature-i koje drugi file sistemi nemaju i koji mnogo znače u enterprise segmentu (ajde uradi rollback nekog velikog Windows apdejta ) U tom kontekstu radi se o verovatno najboljem file sistemu koji postoji danas.

@kovac:
Sve u svemu, na home NAS-u ti vrlo malo ovih funkcionalnosti treba i bolje performanse ćeš dobiti sa recimo ext4. Osim ako ne želiš da imaš zfs da bi se igrao sa njim.

 

[alfaunits]

Kovac, ti si napravio tri zpool-a od tri diska? Imaš po jedan disk u pool-u? Ili si od slajsova pravio pool-ove? U svakom slučaju nije dobra konfiguracija. Preporuka je da se celi diskovi koriste kao vdev-ovi, tako da bi trebao od tri cela diska da napraviš jedan raidz pool. Takođe ako koristiš velike SATA diskove proveri da li ti je ashift dobro podešen.

On ne koristi nikakvu redudansu, kako je rekao, znaci ni RAIDZ nece biti.

Pretpostavka je da redundanse ima, tj. da ćeš imati bar dva diska u mirror-u u zpool-u. U slučaju da nema redundanse i dalje postoji detekcija silent data corruption grešaka, samo nije u stanju da ih koriguje. I to dosta znači - neće serveru vratiti pogrešan podatak, nego ćeš videti grešku i imaćeš priliku da vratiš podatke iz bekapa.

Da, u kontekstu pravih servera cak i to ima smisla.

Što se tiče CPU zahtevnosti, predviđen je da radi na serverima, tako da u tom kontekstu i nije puno zahtevan. Solaris se uglavnom koristi na SPARC mašinama - jedan T5 procesor ima 16 jezgara na 3.6Ghz sa po 8 tredova - ne primetiš uopšte zpool proces. Na novim Xeonima je slična priča (sporiji su, ali opet ne postoji neki problem sa zpool-om), mada su x86 Solaris instalacije dosta ređe.

Ako imaju crypto instrukcije, da. Inace, za file+DB server, koji ionako srce CPU do maximuma, nije zanemarljivo.
Sa druge strane, ako storage moze da isporuci po 4+GB/s (sto uopste nije tesko na serverima kakve pominjes, jer takve performanse sam ja imao i na svom kucnom racunaru pre koju godinu, a danas serveri mogu da isporuce i preko 12GB/s file system podataka - ako ima kako da se iskoriste...), cak i da sva jezgra mogu da isporuce 16GB/s (gde ce mmeorija biti bottleneck ), to je opet barem 25% usporenja.

To su feature-i koje drugi file sistemi nemaju i koji mnogo znače u enterprise segmentu (ajde uradi rollback nekog velikog Windows apdejta )

Ti mene zezas ili stvarno mislis da ovo nije u kompletu moguce na vanilla Windows Serveru? (a da ne pricamo da admin nikada to nece tako ostaviti, vec da ce postojati uvek neki kvalitetan softver koji ce praviti mnogo bolji snapshot nego System Restore?)

 

[kovacm]

Nisam pažljivo pročitao sve njegove postove. Da, ako će NAS koristiti za arhiviranje velikih fajlova RAID5/6 je najbolje rešenje.

Kovac, ti si napravio tri zpool-a od tri diska? Imaš po jedan disk u pool-u? Ili si od slajsova pravio pool-ove? U svakom slučaju nije dobra konfiguracija. Preporuka je da se celi diskovi koriste kao vdev-ovi, tako da bi trebao od tri cela diska da napraviš jedan raidz pool. Takođe ako koristiš velike SATA diskove proveri da li ti je ashift dobro podešen.

prva opcija: "tri zpool-a od tri diska. Imam po jedan disk u pool-u"

nisam ni planirao da stavljam diskove u RAID jer mi ne treba backup (dupliranje podataka, tj. smanjenje ukupnog kapaciteta) vec pre svega hteo da koristim AFP zbog TimeMachine a FreeNAS je imao tu opciju pa reko ajde da stavim ZFS.


sto se tice OS i file systema: UPRAVO MI SE SJEBAO HFS+ NA EKSTERNOM USB DISKU.

sta se desilo? -
na 3TB disku mi je ostalo malo mesta (manje od 10GB).
Obrisem 3-4 fajla od po 10tak GB kako bih mogao da snimim 40GB fajl.
Iskopira se 40GB fajl.
uradim unmount
posle nekog vremena ga ponovo zakacim i nema ga! ne moze da se uradi mount
pustim check disk i dobijem: "Invalid B-tree node size"
...
e do qca.

u svakom slucaju, izgleda da root tabela (ili kako se vec zove u HFSu) za neke fajlove vise ne pokazuje prave lokacije sektora (ili to, ili je sadrzaj 40GB fajla zavrsio preko drugih fajlova)!

btw
ovo su mi bitni podaci. (ne znam da li sam napisao u nekom od prethodnih postova ali sam tacno pomislio: "izgubicu podatke u ovom silnom kopiranju tamo-vamo" sto se i desilo :|)

taman sad imamo real-life primer konzistentnosti fajl sistema...

 

[alfaunits]

Eto ti Apple
Jel' ti ceo disk invalid, ili samo neki PODACI?

Znas li koliko los treba biti FS da bi se tako nesto desilo a da nije hardverska greska? To mi se ni na FAT-u nije desavalo

 

[ness1602]

Pa nije hardver, digni neki getdataback i izvuci podatke.

 

[zeleni_zub]

Ti mene zezas ili stvarno mislis da ovo nije u kompletu moguce na vanilla Windows Serveru? (a da ne pricamo da admin nikada to nece tako ostaviti, vec da ce postojati uvek neki kvalitetan softver koji ce praviti mnogo bolji snapshot nego System Restore?)

Koliko ja znam nije moguće dobiti isti efekat na ni jednom drugom operativnom sistemu. Kaži mi koja kombinacija OS-a i dodatnog softvera pruža iste mogućnosti? Pazi, uradiš apdejt sistema (na novom BE dok sistem radi - nema potrebe za downtime-om), podigneš OS sa novog BE-a, korisnički podaci kreću da se menjaju, posle nekog vremena zaključiš da moraš da uradiš rollback. Ne moraš da vraćaš nikakav bekap, da vraćaš stare verzije fajlova, samo promeniš aktivan BE (1 sec), resetuješ server, podiže ti se stara verzija OS-a, ali ne gubiš ništa od izmena na podacima koji su na sistemskim diskovima.

Ako imaju crypto instrukcije, da. Inace, za file+DB server, koji ionako srce CPU do maximuma, nije zanemarljivo.

Imaju hardverske kripto akceleratore, ali mislim da ih ZFS ne koristi za checksum (nisam siguran).

Inače što se tiče procesora OLTP baze često nisu procesorski zahtevne i vrlo lepo rade sa relativno malim brojem T4/5 ili Power7/8 core-ova.

Evo ti primer koliko je checksum zahtevan.

Četiri jezgra, rpool na dva interna diska, checksum on, sync on, recordsize 128k. Kopiranje fajla od 4gb na isti zpool.

Zpool proces koji radi checksum koristi malo više CPUa od cp-a.

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
     5 root        0K    0K sleep   99  -20   6:01:14 0.5% zpool-rpool/198
 25416 root       10M 9392K sleep   59    0   0:00:07 0.4% cp/1

iostat:

                 extended device statistics                  
device     r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b 
vdc0     128.0  699.3 16256.9 89483.8  0.0  9.7   11.8   1  98 
vdc1      90.7  567.0 11393.6 72545.2  0.0  9.3   14.1   1  94

 

[ness1602]

Ovo ti je sve pretpostavljam za Oracle?
Njemu to nista ne treba, zavrsava mu i najobicniji 2x4TB Raid1 po meni. nema potrebe za Raid5 zato sto mu i ne treba neki read/write.

 

[alfaunits]

Koliko ja znam nije moguće dobiti isti efekat na ni jednom drugom operativnom sistemu. Kaži mi koja kombinacija OS-a i dodatnog softvera pruža iste mogućnosti? Pazi, uradiš apdejt sistema (na novom BE dok sistem radi - nema potrebe za downtime-om), podigneš OS sa novog BE-a, korisnički podaci kreću da se menjaju, posle nekog vremena zaključiš da moraš da uradiš rollback. Ne moraš da vraćaš nikakav bekap, da vraćaš stare verzije fajlova, samo promeniš aktivan BE (1 sec), resetuješ server, podiže ti se stara verzija OS-a, ali ne gubiš ništa od izmena na podacima koji su na sistemskim diskovima.

Pa System Restore na Windowsu to radi.... ne verujem da ga Admini koriste puno, jer nije toliko Admin-friendly, ali radi bas to sto sam te razumeo da radi na ZFSu.
Acronis-ov Secure Zone moze da radi bas ono sto ti hoces - izmenis, probas, ne radi, samo se uradi snapshot restore (koji je instant koliko i reboot) i gotovo. Ako prihvatas izmene, uradis live commit, nema downtime.

Siguran sam da na ZFSu cela ta integracija radi super OOTB, ali da to ne moze na Windowsu... no way. Inace, ja sam radio copy-on-write filter za Windows, koje bi mogao to da izvede sa mnogo vise snapshotova, sem bootmgr-a, ali avaj... to je file system level, nije storage level filter.

Evo ti primer koliko je checksum zahtevan.
Četiri jezgra, rpool na dva interna diska, checksum on, sync on, recordsize 128k. Kopiranje fajla od 4gb na isti zpool.
Zpool proces koji radi checksum koristi malo više CPUa od cp-a.

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
     5 root        0K    0K sleep   99  -20   6:01:14 0.5% zpool-rpool/198
 25416 root       10M 9392K sleep   59    0   0:00:07 0.4% cp/1

Posto ne radim nesto posebno u Linuxu, mozda lose razumem, ali... zar ne znaci ovo da:
- cp je radio 7 sekundi (CPU time)
- zpoolcheckum radi citavih 6 minuta?
A kopiranje 4 GB bi trebalo da traje oko 40 sekundi?

A ako je kopiranje islo ~11MB/s koliko ispada ako je 6 minuta kopirano, da li ti pokusavas da me ubedis da je ZFS sporiji od floppy-a ili da checksum nije spor?

 

[zeleni_zub]

Pa System Restore na Windowsu to radi.... ne verujem da ga Admini koriste puno, jer nije toliko Admin-friendly, ali radi bas to sto sam te razumeo da radi na ZFSu.
Acronis-ov Secure Zone moze da radi bas ono sto ti hoces - izmenis, probas, ne radi, samo se uradi snapshot restore (koji je instant koliko i reboot) i gotovo. Ako prihvatas izmene, uradis live commit, nema downtime.

Windows System Protection nije ni približno ista stvar, osim ako nešto drastično nisu izmenili u poslednje vreme (odavno se ne bavim Windows administracijom). System restore vraća određene fajlove iz bekapa, dok je boot environment nezavistan entitet u kome možeš instalirati/deinstalirati pakete, brisati fajlove itd... Acronis Secure Zone je takođe bekap mehanizam.

Neka se javi neko od Windows administratora i neka kaže da li je ikada puštao System Restore na mission critical produkcionim serverima i kako se osećao prilikom procesa.

Posto ne radim nesto posebno u Linuxu, mozda lose razumem, ali... zar ne znaci ovo da:
- cp je radio 7 sekundi (CPU time)
- zpoolcheckum radi citavih 6 minuta?
A kopiranje 4 GB bi trebalo da traje oko 40 sekundi?

Ne, to je ukupno procesorsko vreme koje je proces koristio do tog trenutka. zpool se pokrenuo pri boot-u i do sada je potrošio 6 CPU sati. cp je potrošio 7 CPU sekundi. Kopiranje može da traje i 2 sata, ali dok proces čeka da se završi IO on ne troši procesorsko vreme. Obrati pažnju na procenat koliko ta dva procesa troše CPU resursa na 4 jezgra (0.5% i 0.4%). Statistika je uzeta dok je cp radio (očigledno) - tako da se proces kopiranja još nije završio.

iostat pokazuje protok samo u tom trenutku, ceo proces kopiranja je trajao:

real 0m50.421s
user 0m0.008s
sys 0m12.723s

Znači 4096mb za 50.4sec = 81.2 mb/sec. Uzmi u obzir da je podatke čitao za zpool-a i da ih je upisivao u zpool - znači u tih 50sec je efektivno radio checksum za 162 MB/sec podataka sa zanemarljivim CPU resursima.


@ness1602: Da, rezultati su sa Solarisa. To sam mu već napisao, zfs mu u principu ne treba - dovoljan je ext4.

Što se tiče integriteta podataka treba još uzeti u obzir da bi u slučaju ext4 koristio implementaciju koja se nalazi u svim enterprise Linux distribucijama, a da trenutno koristiš OpenZFS koji je već 4-5 godina razvija zajednica (i gde je QA pod znakom pitanja).

 

[alfaunits]

Windows System Protection nije ni približno ista stvar, osim ako nešto drastično nisu izmenili u poslednje vreme (odavno se ne bavim Windows administracijom). System restore vraća određene fajlove iz bekapa, dok je boot environment nezavistan entitet u kome možeš instalirati/deinstalirati pakete, brisati fajlove itd... Acronis Secure Zone je takođe bekap mehanizam.

Ne, System Restore moze i System i Data da nezavisno vraca.
Acronis Secure Zone moze da se koristi kao DB log za particiju, i da se lako uradi rollback ili commit. U sustini cist transaction log je u pitanju.
(mozda nije Secure Zone, nego neki drugi, setices se mozda, OCZ ga je predlagao korisnicima za prve uzasne OCZ Core SSDove kao resenje)

Neka se javi neko od Windows administratora i neka kaže da li je ikada puštao System Restore na mission critical produkcionim serverima i kako se osećao prilikom procesa.

To je ono sto se slazemo Da postoje alati na Windowsu za tu svrhu, definitivno - da li se uopste koriste, ko zna

Ne, to je ukupno procesorsko vreme koje je proces koristio do tog trenutka. zpool se pokrenuo pri boot-u i do sada je potrošio 6 CPU sati. cp je potrošio 7 CPU sekundi. Kopiranje može da traje i 2 sata, ali dok proces čeka da se završi IO on ne troši procesorsko vreme. Obrati pažnju na procenat koliko ta dva procesa troše CPU resursa na 4 jezgra (0.5% i 0.4%). Statistika je uzeta dok je cp radio (očigledno) - tako da se proces kopiranja još nije završio.

Ajde onda pre+posle kopiranje CPU stats da vidimo.

Znači 4096mb za 50.4sec = 81.2 mb/sec. Uzmi u obzir da je podatke čitao za zpool-a i da ih je upisivao u zpool - znači u tih 50sec je efektivno radio checksum za 162 MB/sec podataka sa zanemarljivim CPU resursima.

Koji diskovi su u pitanju i koji CPU? (oba zpoola su po jedan disk?)

 

[zeleni_zub]

Ne, System Restore moze i System i Data da nezavisno vraca.

Ključna reč: "vraća iz bekapa" - operacija koja traje i koja modifikuje operativni sistem.

Ajde onda pre+posle kopiranje CPU stats da vidimo.

Pre i posle kopiranja taj proces je idle (pošto server ništa ne radi) - nema aktivnosti na diskovima:

   PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/NLWP  
     5 root     0.0 0.0 0.0 0.0 0.0 0.0 100 0.0   0   0   0   0 zpool-rpool/198

Da u idle modu troši neko procesorsko vreme to bi značilo da je izračunavanje checksum-a još manje zahtevna operacija od onih 0.5%.
Takođe treba uzeti u obzir da zpool ne radi samo izračunvanje checksum-a, tako da u to procesorsko vreme ulaze i ostale operacije.

Koji diskovi su u pitanju i koji CPU? (oba zpoola su po jedan disk?)

4 T4 jezgra, dva virtuelna diska (vdc0 i vdc1) čine jedan zpool (zfs mirror). Svaki virtuelni disk se nalazi na jednom internom SAS 10K HDDu. Overhead IO virtualizacije može da se zanemari. Ono šta je moguće da je neki drugi domen u tom trenutku koristio diskove, ali na osnovu protoka ne bih rekao.

 

[alfaunits]

Ključna reč: "vraća iz bekapa" - operacija koja traje i koja modifikuje operativni sistem.

E taj deo SR ne radi, medjutim Acronis moze.

Pre i posle kopiranja taj proces je idle (pošto server ništa ne radi) - nema aktivnosti na diskovima:

Mislio sam da i pre i posle kopiranja pokazes CPU time total (kao onih 6h od starta), pa se onda uporedi otprilike koliko je TOKOM kopiranja otislo na checksum (sto ne znaci da je toliko, ali je barem toliko).

Takođe treba uzeti u obzir da zpool ne radi samo izračunvanje checksum-a, tako da u to procesorsko vreme ulaze i ostale operacije.

Npr.? Sta je zahtevno od tih operacija koliko i checksums?

4 T4 jezgra, dva virtuelna diska (vdc0 i vdc1) čine jedan zpool (zfs mirror). Svaki virtuelni disk se nalazi na jednom internom SAS 10K HDDu. Overhead IO virtualizacije može da se zanemari. Ono šta je moguće da je neki drugi domen u tom trenutku koristio diskove, ali na osnovu protoka ne bih rekao.

Koji SAS 10K HDD konkretno? Neki mogu i preko 120 MB/s da rade @persistent rate, sto bi znacilo da ovih 80MB/s ispada ogromna razlika
Ili ti imas u sustini ZFS mirror na 2 fizicka diska, da tako uprostim? (u kom slucaju je 80MB/s nemoguce, jer SAS 10K nece dati 160MB/s effective sustained rate koliko bi morao dati u tom slucaju)

 

[zeleni_zub]

Mislio sam da i pre i posle kopiranja pokazes CPU time total (kao onih 6h od starta), pa se onda uporedi otprilike koliko je TOKOM kopiranja otislo na checksum (sto ne znaci da je toliko, ali je barem toliko).
Npr.? Sta je zahtevno od tih operacija koliko i checksums?

To nije relevantna informacija, mnogo bolji pokazatelj je koliki procenat ukupnog CPU vremena na sistemu koristi (0.5%).

Ali evo: pre 6:02:11 0.1%, posle 6:02:22 0.1%.

Koji SAS 10K HDD konkretno? Neki mogu i preko 120 MB/s da rade @persistent rate, sto bi znacilo da ovih 80MB/s ispada ogromna razlika
Ili ti imas u sustini ZFS mirror na 2 fizicka diska, da tako uprostim? (u kom slucaju je 80MB/s nemoguce, jer SAS 10K nece dati 160MB/s effective sustained rate koliko bi morao dati u tom slucaju)

Da, efektivno vdc0 i vdc1 možeš da posmatraš kao fizičke diskove. Od njih je napravljen jedan zfs mirror. Diskovi su ili Hitachi HUC106030CSS600/HUC109030CSS600 ili Seagate ST9300605SS.
Uzmi u obzir da ZFS radi round robin kada čita sa mirrorovanih diskova (ne čita samo sa jednog diska). Takođe ne mogu da budem siguran koliko podataka pročita iz ARC-a i da li još neko koristi diskove.

Jedino šta mogu da vidim je da se na diskovima smenjuju periodi u kojima radi read i write i da jedan disk može da izvuče 120-130Mb/sec.

Ovo sve u principu nije toliko važno za ono šta sam hteo da kažem: Oracle implementacija checksum-a je prilično dobro optimizovana i unosi zanemarljivi overhead. Verujem da je isti slučaj sa OpenZFSom. Jeste da je fork-ovan pre 5 godina, ali problema sa performansama pri uključenim checksum-ima nije bilo pre forka, tako da ne verujem da su taj deo pokvarili.

 

[alfaunits]

Nije mi to dovoljno da mogu tek tako da verujem da nije veliki overhead. Ako je ovo pokazatelj onda je veliki overhead. Ako je jos neko koristio diskove ili se koristi read cache, onda je preveliko "zagadjenje" testa

Recimo, na TrueCrypt-u se overhead uopste ne primeti, ako se ne prepuni cache ili ako se ne prepuni CPU usage. Medjutim, dovoljno je samo da kolicina kopiranih podataka predje cache size i vec se vidi preveliki overhead, ako nema AES-NI na masini, mada na SSD-ovima i tada nije zanemarljiv (posto u slucaju kopiranja radi single thread, perforamnse su cak i sa AES-NI ako se ne varam na nivou brzine SSD-a pa je to 50% usporenja)
https://blogs.oracle.com/BestPerf/entry/20110930_sparc_t4_crypto_umbk
AES-CBC, koji je najblizi AES-XTS koji TC koristi, ~500 MB/s single thread sa AES-NI.

Ako je tvoj T4 koristio 0.5% CPU time-a, pod pretpostavkom da uopste to znaci ono sto mislim da znaci , to dodje 200.-ti deo CPU-a, a T4 sa 64 jezgra moze oko 10GB/s da isporuci, znaci ovo je 200x manje, tj. oko 50MB/s
Ocigledno je da to nije to i da nema sanse da se toliko CPU time-a koristi.


Na diskovima se moze smenjivati read/write, medjutim na 4GB, ako cache ne udje u igru, ti ipak moras imati ukupno 4GB citanja i pisanja, i u najboljem slucaju se iskoristi puna brzina jednog diska za citanje i jednog za pisanje (vrlo slicne brzine). Ako to izadje 80MB/s, overhead je veliki, to budi siguran.

 

[zeleni_zub]

Ako je tvoj T4 koristio 0.5% CPU time-a, pod pretpostavkom da uopste to znaci ono sto mislim da znaci , to dodje 200.-ti deo CPU-a, a T4 sa 64 jezgra moze oko 10GB/s da isporuci, znaci ovo je 200x manje, tj. oko 50MB/s
Ocigledno je da to nije to i da nema sanse da se toliko CPU time-a koristi.

Pa ne baš. CPU vreme je vreme koje je potrošeno za obrađivanje instrukcija. Jednostavno, koliko vremena je procesor izvršavao instrukcije za dati proces i nema veze sa bilo kakvim protokom - proces može samo da sabira dva registra milion puta i da troši CPU vreme. Takođe, proces može relativno dugo da čeka da se IO završi, ali za to vreme procesor izvršava instrukcije nekog drugog procesa, i samim tim proces koji čeka na IO ne troši procesorsko vreme.


Ne postoje T4 serveri sa 64 jezgra, maksimalno mogu imati 4 procesora = 32 jezgra (T5 serveri imaju do 128 jezgara). Ako misliš na pristup memoriji - svaki T4 procesor ima dva MCUa od kojih svaki ima protok od 6.4Gbit/sec. Znači na sistemima sa dva procesora imaš ukupno 25.6Gbit/sec. Ako misliš da će računanje checksum-a preopteretiti MCUove i/ili coherence linkove - neće. Kada sam testirao OracleDB na ZFSu jedina stvar koja nije ni malo nije bila sporna su bili CPU resursi, a praktično se checksum dva puta računao - jednom na ZFSu i jednom u RDBMSu za database blokove.

edit: OK, tek sada vidim link koji postavio. To su rezultati za jedan procesor sa 8 jezgara i 64 treda i rezultati su za hardvesku akceleraciju AES enkripcije. A ovde pričamo o računanju checksum-a fletcher algoritmom.

Ako to izadje 80MB/s, overhead je veliki, to budi siguran.

80MB/s podataka prekopira - znači 80MB/sec pročita i 80MB/sec upiše - efektivno 160MB/sec protoka. Od toga 80 MB/sec mora da upiše na svaki disk, a 80MB/sec čita agregirano sa oba diska i iz ARCa.

IO overhead jeste značajan u odnosu na recimo UFS, ali se ne javlja zbog checksum-a nego zbog CoW-a i ZIL-a.


Uostalom možeš i sam da probaš - instaliraj Solaris u jednoj virtuelnoj mašini i vidi kako radi sa i bez checksum-a.

 

[alfaunits]

Nece kod mene u VMWare masini to biti merodavno... na SSDovima i VPU.

Koliko se secam (extra davno bese kada sam i probao RAID1), mada ispravi me ako imas negde hardverski RAID1 bez cache-a za probu, kada se kopira RAID1->RAID1 (isti RAID1) brzina je ravna brzini diska otprilike (nesto manja mizerno).
Mada mi ne zvuci logicno trenutno

 

[zeleni_zub]

Pa zavisi, dosta RAID1 implementacija ne čita podatke sa oba diska, nego samo sa prvog. U tom slučaju dobijaš praktično performanse jednog diska.

 

[alfaunits]

Za citanje.. ali iskljucimo tu losu situaciju, ovako bi trebalo da se cita sa oba diska, i upisuje na oba.
Ne valjda mi nesto ovde, treba nam real-world benchmark, bez "prljanja" rezultata.

 

[ness1602]

oVO BRE sve u Enterprise ,da se na miru raspravljamo

 

[alfaunits]

E, da, mogli bi da sav Reply dalje za ovaj thread bacimo u onaj drugi, sve je rasprava o performansama, a ne o konzistentnosti podataka

 

[ness1602]

Izasao OMV 1.0
Sad bi trebalo jos lakse da ti bude podesavanje