Ovog proljeća već smo razgovarali o nekim uvodnim temama, npr. и . U drugom od njih, čak smo obećali da ćemo nastaviti proučavati performanse različitih multi-disk topologija u ZFS-u. Ovo je sljedeća generacija datotečnog sistema koji se sada implementira svuda do .
Pa, danas je najbolji dan za upoznavanje sa ZFS-om, radoznali čitaoci. Samo znajte da je po skromnoj procjeni OpenZFS programera Matta Ahrensa "stvarno teško."
Ali prije nego što dođemo do brojeva – a bit će ih, obećavam – za sve varijante ZFS konfiguracije sa osam diskova, moramo razgovarati o kako Općenito, ZFS pohranjuje podatke na disk.
Zpool, vdev i uređaj
Ovaj puni dijagram bazena uključuje tri pomoćna vdev-a, po jedan iz svake klase i četiri za RAIDz2
Obično nema razloga da kreirate skup neusklađenih vdev tipova i veličina - ali ako želite, ništa vas ne sprečava da to učinite
Da biste zaista razumjeli ZFS sistem datoteka, morate pažljivo pogledati njegovu stvarnu strukturu. Prvo, ZFS objedinjuje tradicionalne nivoe upravljanja volumenom i sistemom datoteka. Drugo, koristi transakcioni mehanizam kopiranja na upisivanje. Ove karakteristike znače da se sistem strukturno veoma razlikuje od konvencionalnih sistema datoteka i RAID nizova. Prvi skup osnovnih građevnih blokova koje treba razumjeti su spremište za pohranu (zpool), virtualni uređaj (vdev) i pravi uređaj (device).
zpool
Zpool spremište je najviša ZFS struktura. Svaki bazen sadrži jedan ili više virtuelnih uređaja. Zauzvrat, svaki od njih sadrži jedan ili više stvarnih uređaja (uređaja). Virtuelni bazeni su samostalne jedinice. Jedan fizički računar može sadržavati dva ili više odvojenih skupova, ali svaki je potpuno nezavisan od drugih. Pulovi ne mogu dijeliti virtuelne uređaje.
ZFS redundantnost je na razini virtualnog uređaja, a ne na razini bazena. Ne postoji apsolutno nikakva redundancija na nivou bazena—ako se izgubi vdev ili namenski vdev, gubi se i ceo bazen zajedno sa njim.
Moderna spremišta za pohranu mogu preživjeti gubitak keš memorije ili dnevnika virtuelnog uređaja - iako mogu izgubiti malu količinu prljavih podataka ako izgube vdev dnevnik tokom nestanka struje ili pada sistema.
Postoji uobičajena zabluda da su ZFS "trake podataka" ispisane po cijelom bazenu. Ovo nije istina. Zpool nije smiješan RAID0, više je smiješan sa složenim mehanizmom varijabilne distribucije.
Unosi su uglavnom raspoređeni između dostupnih virtuelnih uređaja prema raspoloživom slobodnom prostoru, tako da će u teoriji svi biti popunjeni u isto vrijeme. U kasnijim verzijama ZFS-a, trenutna upotreba (iskorišćenost) vdev-a se uzima u obzir - ako je jedan virtuelni uređaj značajno zauzetiji od drugog (na primjer, zbog opterećenja čitanja), privremeno će biti preskočen za pisanje, unatoč tome što ima najveću slobodnu prostorni odnos.
Mehanizam za otkrivanje recikliranja ugrađen u moderne ZFS metode dodjeljivanja pisanja može smanjiti kašnjenje i povećati propusnost tokom perioda neobično visokog opterećenja - ali ne carte blanche do nevoljnog miješanja sporih HDD-a i brzih SSD-ova u jednom bazenu. Takav nejednak bazen će i dalje raditi brzinom najsporijeg uređaja, odnosno kao da je u potpunosti sastavljen od takvih uređaja.
vdev
Svako spremište za pohranu sastoji se od jednog ili više virtualnih uređaja (virtualni uređaj, vdev). Zauzvrat, svaki vdev sadrži jedan ili više stvarnih uređaja. Većina virtuelnih uređaja se koristi za jednostavno skladištenje podataka, ali postoji nekoliko vdev pomoćnih klasa, uključujući CACHE, LOG i SPECIAL. Svaki od ovih vdev tipova može imati jednu od pet topologija: jedan uređaj (single-device), RAIDz1, RAIDz2, RAIDz3 ili ogledalo (ogledalo).
RAIDz1, RAIDz2 i RAIDz3 su posebne varijante onoga što bi oldtajmeri nazvali RAID sa dvostrukim (dijagonalnim) paritetom. 1, 2 i 3 odnose se na koliko paritetnih blokova je dodijeljeno za svaku traku podataka. Umjesto odvojenih diskova za paritet, RAIDz virtuelni uređaji distribuiraju ovaj paritet poluravnomjerno po diskovima. RAIDz niz može izgubiti onoliko diskova koliko ima paritetnih blokova; ako izgubi još jedan, srušit će se i sa sobom ponijeti spremište.
U preslikanim virtuelnim uređajima (mirror vdev), svaki blok je pohranjen na svakom uređaju u vdev-u. Iako su dvoširoka ogledala najčešća, bilo koji proizvoljan broj uređaja može biti u ogledalu - trostruki se često koriste u velikim instalacijama radi poboljšanja performansi čitanja i tolerancije grešaka. Vdev ogledalo može preživjeti svaki kvar sve dok barem jedan uređaj u vdev-u nastavi da funkcionira.
Pojedinačni vdev-ovi su sami po sebi opasni. Takav virtualni uređaj neće preživjeti niti jedan kvar - a ako se koristi kao skladište ili poseban vdev, onda će njegov kvar dovesti do uništenja cijelog bazena. Budite veoma, veoma oprezni ovde.
CACHE, LOG i SPECIAL virtuelni uređaji mogu se kreirati u bilo kojoj od gore navedenih topologija - ali zapamtite da gubitak SPECIAL virtuelnog uređaja znači gubitak spremišta, tako da se redundantna topologija jako preporučuje.
uređaj
Ovo je vjerovatno najlakši termin za razumjeti u ZFS-u - to je doslovno blok uređaj sa slučajnim pristupom. Zapamtite da se virtuelni uređaji sastoje od pojedinačnih uređaja, a skup je napravljen od virtuelnih uređaja.
Diskovi, bilo magnetni ili čvrsti, najčešći su blok uređaji koji se koriste kao građevni blokovi vdev-a. Međutim, bilo koji uređaj s deskriptorom u /dev će to učiniti - tako da se cijeli hardverski RAID nizovi mogu koristiti kao zasebni uređaji.
Jednostavna sirova datoteka je jedan od najvažnijih alternativnih blok uređaja od kojih se može izgraditi vdev. Test pools from je vrlo zgodan način da provjerite komande spremišta i vidite koliko je prostora dostupno u spremištu ili virtuelnom uređaju date topologije.
Možete kreirati probni skup od rijetkih datoteka za samo nekoliko sekundi - ali ne zaboravite nakon toga izbrisati cijeli bazen i njegove komponente
Recimo da želite server sa osam diskova i planirate da koristite diskove od 10 TB (~9300 GiB) - ali niste sigurni koja topologija najbolje odgovara vašim potrebama. U gornjem primjeru, izgradili smo testni skup od rijetkih datoteka za nekoliko sekundi - i sada znamo da RAIDz2 vdev od osam diskova od 10 TB pruža 50 TiB korisnog kapaciteta.
Druga posebna klasa uređaja je SPARE. Zamjenjivi uređaji, za razliku od običnih uređaja, pripadaju cijelom skupu, a ne jednom virtuelnom uređaju. Ako bilo koji vdev u spremištu ne uspije, a rezervni uređaj je povezan na spremište i dostupan, tada će se automatski pridružiti zahvaćenom vdevu.
Jednom kada se poveže na zahvaćeni vdev, zamjenski uređaj počinje primati kopije ili rekonstrukcije podataka koji bi trebali biti na uređaju koji nedostaje. U tradicionalnom RAID-u to se zove "rebuilding", au ZFS-u je "resilvering".
Važno je napomenuti da zamjenski uređaji ne zamjenjuju trajno neispravne uređaje. Ovo je samo privremena zamjena za smanjenje vremena potrebnog da se vdev degradira. Nakon što administrator zamijeni neuspjeli vdev uređaj, redundantnost se vraća na taj stalni uređaj, a SPARE se isključuje iz vdev-a i vraća se kao rezervni za cijeli skup.
Skupovi podataka, blokovi i sektori
Sljedeći skup gradivnih blokova koje treba razumjeti na našem ZFS putovanju se manje odnosi na hardver, a više na način na koji su sami podaci organizirani i pohranjeni. Ovdje preskačemo nekoliko slojeva – kao što je metaslab – kako bismo izbjegli zatrpavanje detalja, a istovremeno zadržali razumijevanje cjelokupne strukture.
Skup podataka
Kada prvi put kreiramo skup podataka, on pokazuje sav raspoloživi prostor bazena. Zatim postavljamo kvotu - i mijenjamo tačku montiranja. Magic!
Zvol je uglavnom samo skup podataka lišen sloja sistema datoteka, koji ovdje zamjenjujemo sa potpuno normalnim ext4 sistemom datoteka
ZFS skup podataka je otprilike isti kao standardni montirani sistem datoteka. Poput običnog sistema datoteka, na prvi pogled izgleda da je "samo još jedan folder". Ali baš kao i obični montirani sistemi datoteka, svaki ZFS skup podataka ima svoj vlastiti skup osnovnih svojstava.
Prije svega, skup podataka može imati dodijeljenu kvotu. Ako je postavljeno zfs set quota=100G poolname/datasetname, tada nećete moći pisati u montirani folder /poolname/datasetname više od 100 GiB.
Primjećujete prisustvo—i odsustvo—kosih crta na početku svakog reda? Svaki skup podataka ima svoje mjesto u ZFS hijerarhiji i hijerarhiji montiranja sistema. U ZFS hijerarhiji nema vodeće kose crte - počinjete s imenom skupa, a zatim stazom od jednog skupa podataka do sljedećeg. Na primjer, pool/parent/child za skup podataka pod nazivom child pod roditeljskim skupom podataka parent u bazenu sa kreativnim imenom pool.
Prema zadanim postavkama, tačka montiranja skupa podataka bit će ekvivalentna njegovom imenu u ZFS hijerarhiji, s vodećim kosom crtom - bazenom pod nazivom pool montiran kao /pool, skup podataka parent montiran u /pool/parent, i dječji skup podataka child montiran u /pool/parent/child. Međutim, sistemska tačka montiranja skupa podataka može se promijeniti.
Ako specificiramo zfs set mountpoint=/lol pool/parent/child, zatim skup podataka pool/parent/child montiran na sistem kao /lol.
Pored skupova podataka, treba spomenuti i volumene (zvols). Volumen je otprilike isti kao skup podataka, osim što zapravo nema sistem datoteka – to je samo blok uređaj. Možete na primjer kreirati zvol S imenom mypool/myzvol, zatim ga formatirajte sa ext4 sistemom datoteka, a zatim montirajte taj sistem datoteka - sada imate ext4 sistem datoteka, ali sa svim sigurnosnim karakteristikama ZFS-a! Ovo može izgledati glupo na jednom računaru, ali ima mnogo više smisla kao backend kada izvozite iSCSI uređaj.
Blokovi
Datoteka je predstavljena jednim ili više blokova. Svaki blok je pohranjen na jednom virtuelnom uređaju. Veličina bloka je obično jednaka parametru recordsize, ali se može svesti na 2^smjenaako sadrži metapodatke ili malu datoteku.
Mi zaista stvarno ne šalim se sa velikom kaznom učinka ako postavite premali pomak
U ZFS bazenu, svi podaci, uključujući metapodatke, pohranjuju se u blokovima. Maksimalna veličina bloka za svaki skup podataka je definirana u svojstvu recordsize (veličina zapisa). Veličina zapisa se može promijeniti, ali to neće promijeniti veličinu ili lokaciju blokova koji su već upisani u skup podataka - to utječe samo na nove blokove kako su upisani.
Osim ako nije drugačije navedeno, trenutna zadana veličina unosa je 128 KiB. To je nekako težak kompromis gdje performanse neće biti savršene, ali neće biti strašne u većini slučajeva. Recordsize može se postaviti na bilo koju vrijednost od 4K do 1M (uz dodatna podešavanja recordsize možete instalirati još više, ali ovo je rijetko dobra ideja).
Bilo koji blok se odnosi na podatke samo jedne datoteke—ne možete stisnuti dvije različite datoteke u jedan blok. Svaka datoteka se sastoji od jednog ili više blokova, ovisno o njegovoj veličini. Ako je veličina datoteke manja od veličine zapisa, ona će biti pohranjena u manjem bloku - na primjer, blok sa datotekom od 2 KiB će zauzeti samo jedan sektor od 4 KiB na disku.
Ako je datoteka dovoljno velika da zahtijeva nekoliko blokova, tada će svi unosi u tu datoteku biti veličine recordsize - uključujući zadnji unos, čiji glavni dio može biti .
zvols nemaju svojstvo recordsize — umjesto toga imaju ekvivalentno svojstvo volblocksize.
Sektori
Posljednji, najosnovniji građevinski blok je sektor. To je najmanja fizička jedinica na koju se može pisati ili čitati sa glavnog uređaja. Nekoliko decenija većina diskova je koristila sektore od 512 bajta. Ovih dana, većina disk jedinica je konfigurisana za 4 KiB sektora, a neki - posebno SSD-ovi - su konfigurisani za 8 KiB sektora ili čak i veće.
ZFS ima funkciju koja vam omogućava da ručno postavite veličinu sektora. Ova nekretnina ashift. Pomalo zbunjujuće, ashift je stepen dvojke. Na primjer, ashift=9 znači veličinu sektora od 2^9, ili 512 bajtova.
ZFS traži od operativnog sistema detaljne informacije o svakom blok uređaju kada se doda novom vdevu, i teoretski automatski postavlja asshift na odgovarajući način na osnovu tih informacija. Nažalost, mnogi diskovi lažu o veličini svog sektora kako bi održali kompatibilnost sa Windows XP (koji nije mogao razumjeti diskove s drugim veličinama sektora).
To znači da je jako preporučljivo da ZFS administrator zna stvarnu veličinu sektora svojih uređaja i ručno podesi ashift. Ako je asshift postavljen premali, broj operacija čitanja/pisanja se astronomski povećava. Dakle, pisanje "sektora" od 512 bajta u pravi sektor od 4 KiB znači da morate napisati prvi "sektor", zatim pročitati sektor od 4 KiB, modificirati ga drugim "sektorom" od 512 bajta, zapisati ga nazad u novi 4 KiB sektor, i tako dalje za svaki unos.
U stvarnom svetu, takva kazna pogađa Samsung EVO SSD, za šta ashift=13, ali ovi SSD-ovi lažu o veličini svog sektora, pa je stoga zadana vrijednost postavljena na ashift=9. Osim ako iskusni administrator sistema ne promijeni ovu postavku, ovaj SSD radi sporije konvencionalni magnetni HDD.
Za poređenje, za preveliku veličinu ashift kazne praktično nema. Nema stvarnog udara u performansama, a povećanje neiskorištenog prostora je beskonačno malo (ili nula ako je kompresija omogućena). Stoga toplo preporučujemo da se instaliraju čak i diskovi koji koriste sektore od 512 bajta ashift=12 ili čak ashift=13da se sa samopouzdanjem suočimo sa budućnošću.
Vlasništvo ashift je postavljen za svaki vdev virtuelni uređaj, i ne za bazen, kako mnogi pogrešno misle - i ne mijenja se nakon instalacije. Ako slučajno udarite ashift Kada dodate novi vdev u bazen, nepovratno ste ga zagadili uređajem niskih performansi i, po pravilu, ne postoji druga opcija osim da uništite bazen i počnete ispočetka. Čak i brisanje vdev neće vas spasiti od neispravne postavke ashift!
Mehanizam kopiranja na pisanje
Ako običan sistem datoteka treba da prepiše podatke, on mijenja svaki blok u kojem se nalazi
Datotečni sistem kopiranja na upisivanje upisuje novu verziju bloka, a zatim otključava staru verziju
Apstraktno, ako zanemarimo stvarni fizički raspored blokova, naša „kometa podataka“ se pojednostavljuje u „podatkovnog crva“ koji se kreće s lijeva na desno preko karte dostupnog prostora.
Sada možemo dobiti dobru predstavu o tome kako funkcionišu snimci kopiranja na upisivanje - svaki blok može pripadati više snimaka i postojat će sve dok se svi povezani snimci ne unište
Mehanizam Copy on Write (CoW) je temeljna osnova onoga što ZFS čini tako nevjerovatnim sistemom. Osnovni koncept je jednostavan - ako tražite od tradicionalnog sistema datoteka da promijeni datoteku, on će učiniti upravo ono što ste tražili. Ako zamolite sistem datoteka za kopiranje-upisivanje da uradi istu stvar, on će reći „u redu”—ali će vas lagati.
Umjesto toga, sistem datoteka kopiraj-na-piši piše novu verziju izmijenjenog bloka, a zatim ažurira metapodatke datoteke da bi prekinuo vezu sa starim blokom i povezao ga s novim blokom koji ste upravo napisali.
Prekidanje veze starog bloka i povezivanje novog se vrši u jednoj operaciji, tako da se ne može prekinuti - ako resetujete napajanje nakon što se ovo desi, imate novu verziju fajla, a ako resetujete napajanje ranije, onda imate stara verzija. U svakom slučaju, neće biti sukoba u sistemu datoteka.
Kopiranje-upisivanje u ZFS-u se dešava ne samo na nivou sistema datoteka, već i na nivou upravljanja diskom. To znači da ZFS nije podložan razmacima u zapisu () - fenomen kada je traka bila samo djelimično snimljena prije pada sistema, sa oštećenjem niza nakon ponovnog pokretanja. Ovdje je traka napisana atomski, vdev je uvijek sekvencijalan, i .
ZIL: ZFS dnevnik namjere
ZFS rukuje sinhronim zapisima na poseban način - pohranjuje ih privremeno, ali odmah u ZIL prije nego što ih kasnije trajno upiše zajedno sa asinhronim upisima.
Obično se podaci upisani u ZIL nikada više ne čitaju. Ali to je moguće nakon kvara sistema
SLOG ili sekundarni LOG uređaj je jednostavno poseban - i po mogućnosti vrlo brz - vdev gdje se ZIL može pohraniti odvojeno od glavne memorije
Nakon pada, svi prljavi podaci u ZIL-u se reproduciraju - u ovom slučaju ZIL je na SLOG-u, pa se tamo reproducira
Postoje dvije glavne kategorije upisa: sinhrono (sinhrono) i asinhrono (asinhrono). Za većinu radnih opterećenja, velika većina upisivanja je asinhrona – sistem datoteka omogućava njihovo agregiranje i izdavanje u serijama, smanjujući fragmentaciju i značajno povećavajući propusnost.
Sinhroni snimci su sasvim druga stvar. Kada aplikacija zatraži sinhrono upisivanje, ona saopštava sistemu datoteka: "Morate ovo predati u nepromjenjivu memoriju upravo sada, a do tada ništa više ne mogu učiniti.” Stoga, sinhroni zapisi moraju odmah biti predani na disk - i ako to povećava fragmentaciju ili smanjuje propusnost, neka bude tako.
ZFS upravlja sinhronim upisima drugačije od običnih sistema datoteka – umjesto da ih odmah isprazni u uobičajenu memoriju, ZFS ih upisuje u posebno područje skladištenja koje se zove ZFS Intent Log, ili ZIL. Trik je u tome da ovi zapisi takođe ostaju u memoriji, agregiraju se zajedno sa normalnim asinhronim zahtjevima za pisanje, da bi se kasnije izbacili u memoriju kao potpuno normalni TXG (transakcione grupe).
Tokom normalnog rada, ZIL se upisuje i nikada više ne čita. Kada se, nakon nekoliko trenutaka, zapisi iz ZIL-a predaju u glavnu memoriju u regularnim TXG-ovima iz RAM-a, oni se odvajaju od ZIL-a. Jedini put kada se nešto čita iz ZIL-a je prilikom uvoza bazena.
Ako dođe do kvara ZFS-a — pada operativnog sistema ili nestanka struje — dok postoje podaci u ZIL-u, ti podaci će biti pročitani tokom sljedećeg uvoza spremišta (na primjer, kada se sistem za prelazak na grešku ponovo pokrene). Sve što je u ZIL-u će biti pročitano, grupisano u TXG-ove, predano u glavnu prodavnicu, a zatim će se odvojiti od ZIL-a tokom procesa uvoza.
Jedna od vdev pomoćnih klasa se zove LOG ili SLOG, sekundarni uređaj LOG-a. Ima jednu svrhu - da obezbedi bazenu sa zasebnim, i po mogućnosti mnogo bržim, veoma otpornim vdev-om za pohranjivanje ZIL-a, umesto pohranjivanja ZIL-a u glavnu vdev prodavnicu. Sam ZIL se ponaša isto bez obzira gdje je pohranjen, ali ako LOG vdev ima vrlo visoke performanse pisanja, sinkrono upisivanje će biti brže.
Dodavanje vdev sa LOG-om u bazen ne radi ne mogu poboljšajte performanse asinhronog pisanja - čak i ako prisilite sve zapise u ZIL pomoću zfs set sync=always, oni će i dalje biti povezani sa glavnom memorijom u TXG na isti način i istim tempom kao i bez dnevnika. Jedino direktno poboljšanje performansi je latencija sinhronog pisanja (pošto veće brzine dnevnika čine operacije bržima sync).
Međutim, u okruženju koje već zahtijeva puno sinhronog upisivanja, vdev LOG može indirektno ubrzati asinkrono upisivanje i nekeširano čitanje. Prebacivanje ZIL zapisa u poseban vdev LOG znači manje sukoba za IOPS na primarnoj memoriji, što u određenoj mjeri poboljšava performanse svih čitanja i pisanja.
Snimci
Mehanizam kopiranja-upisivanja je također neophodna osnova za ZFS atomske snimke i inkrementalnu asinhronu replikaciju. Aktivni sistem datoteka ima stablo pokazivača koje označava sve unose trenutnim podacima - kada napravite snimak, jednostavno napravite kopiju ovog stabla pokazivača.
Kada se zapis prepiše na aktivnom sistemu datoteka, ZFS prvo upisuje novu verziju bloka u neiskorišteni prostor. Zatim odvaja staru verziju bloka od trenutnog sistema datoteka. Ali ako se neki snimak poziva na stari blok, on i dalje ostaje nepromijenjen. Stari blok zapravo neće biti vraćen kao slobodan prostor dok se ne unište svi snimci koji se odnose na taj blok!
Replikacija
Moja Steam biblioteka u 2015. bila je 158 GiB i uključivala je 126 fajlova. Ovo je prilično blizu optimalnoj situaciji za rsync - ZFS replikacija preko mreže bila je "samo" 927% brža.
Na istoj mreži, repliciranje jedne datoteke slike virtualne mašine Windows 40 od 7 GB je potpuno druga priča. ZFS replikacija je 289 puta brža od rsync—ili "samo" 161 puta brža ako ste dovoljno pametni da pozovete rsync pomoću prekidača --inplace.
Kada se slika VM-a skalira, rsync izdaje skaliranje s njom. Veličina od 1,9 TiB nije toliko velika za modernu VM sliku—ali je dovoljno velika da ZFS replikacija bude 1148 puta brža od rsync, čak i sa argumentom rsync --inplace
Jednom kada shvatite kako funkcionišu snimke, biće lako shvatiti suštinu replikacije. Budući da je snimak jednostavno stablo pokazivača zapisa, slijedi da ako to učinimo zfs send snimak, zatim šaljemo ovo stablo i sve zapise povezane s njim. Kad prođemo ovo zfs send в zfs receive na ciljnom objektu, zapisuje i stvarni sadržaj bloka i stablo pokazivača koji upućuju blokove na ciljni skup podataka.
Stvari postaju još zanimljivije u drugom zfs send. Sada imamo dva sistema, od kojih svaki sadrži poolname/datasetname@1, a vi napravite novi snimak poolname/datasetname@2. Dakle, u originalnom bazenu imate datasetname@1 и datasetname@2, a u ciljnom bazenu do sada samo prvi snimak datasetname@1.
Pošto imamo zajednički snimak između izvora i cilja datasetname@1, mi to možemo uraditi inkrementalno zfs send preko toga. Kada kažemo sistemu zfs send -i poolname/datasetname@1 poolname/datasetname@2, upoređuje dva stabla pokazivača. Svi pokazivači koji postoje samo u @2, očito se odnosi na nove blokove - pa će nam trebati sadržaj tih blokova.
Na udaljenom sistemu, obrada inkrementalnog send isto tako jednostavno. Prvo, pišemo sve nove unose uključene u stream send, a zatim dodajte pokazivače na te blokove. Voila, imamo @2 u novom sistemu!
ZFS asinhrona inkrementalna replikacija je veliko poboljšanje u odnosu na ranije metode koje nisu zasnovane na snapshot-u, kao što je rsync. U oba slučaja prenose se samo promijenjeni podaci - ali prvo mora rsync čitati sa diska sve podatke sa obe strane da proverite zbir i uporedite ga. Nasuprot tome, ZFS replikacija ne čita ništa osim stabala pokazivača—i svih blokova koji nisu predstavljeni u cjelokupnom snimku.
Ugrađena kompresija
Mehanizam kopiranja na upisivanje također pojednostavljuje ugrađeni sistem kompresije. U tradicionalnom sistemu datoteka, kompresija je problematična - i stara verzija i nova verzija izmijenjenih podataka nalaze se u istom prostoru.
Ako uzmemo u obzir dio podataka u sredini datoteke koji počinje život kao megabajt nula od 0x00000000 i tako dalje, vrlo je lako komprimirati ga u jedan sektor na disku. Ali šta se dešava ako taj megabajt nula zamenimo megabajtom nestišljivih podataka kao što je JPEG ili pseudo-slučajni šum? Neočekivano, ovaj megabajt podataka će zahtijevati ne jedan, već 256 4 KiB sektora, a na ovom mjestu na disku je rezerviran samo jedan sektor.
ZFS nema ovaj problem, jer se izmijenjeni zapisi uvijek upisuju u neiskorišteni prostor - originalni blok zauzima samo jedan sektor od 4 KiB, a novi zapis će zauzeti 256, ali to nije problem - nedavno izmijenjeni fragment iz " sredina" datoteke bi bila upisana u neiskorišteni prostor bez obzira da li se njegova veličina promijenila ili ne, tako da je za ZFS ovo sasvim uobičajena situacija.
Ugrađena ZFS kompresija je podrazumevano onemogućena, a sistem nudi algoritme koji se mogu priključiti - trenutno uključujući LZ4, gzip (1-9), LZJB i ZLE.
- LZ4 je algoritam za striming koji nudi izuzetno brzu kompresiju i dekompresiju i prednosti performansi za većinu slučajeva upotrebe - čak i na prilično sporim procesorima.
- GZIP je poštovan algoritam koji svi korisnici Unixa poznaju i vole. Može se implementirati sa nivoima kompresije 1-9, sa omjerom kompresije i korištenjem CPU-a koji se povećava kako se približava nivou 9. Algoritam je dobro prikladan za sve tekstualne (ili druge vrlo kompresibilne) slučajeve upotrebe, ali inače često uzrokuje probleme s procesorom - koristite ga pažljivo, posebno na višim nivoima.
- LZJB - originalni algoritam u ZFS-u. Zastario je i ne treba ga više koristiti, LZ4 je superioran u svakom pogledu.
- LOŠE — kodiranje nultog nivoa, kodiranje nultog nivoa. Uopšte ne dotiče normalne podatke, ali komprimira velike nizove nula. Korisno za komplete podataka koji nisu u potpunosti kompresibilni (kao što su JPEG, MP4 ili drugi već komprimovani formati) jer zanemaruje nestišljive podatke, ali komprimuje neiskorišćeni prostor u rezultujućim zapisima.
Preporučujemo LZ4 kompresiju za gotovo sve slučajeve upotrebe; kazna performansi kada se radi sa nestišljivim podacima je vrlo mala, i rast performanse za tipične podatke su značajne. Kopiranje slike virtuelne mašine za novu instalaciju operativnog sistema Windows (svježe instaliran OS, još nema podataka) sa compression=lz4 prošao 27% brže nego sa compression=none, in .
ARC - adaptivna zamjenska keš memorija
ZFS je jedini moderni sistem datoteka za koji znamo koji koristi vlastiti mehanizam za keširanje čitanja, umjesto da se oslanja na keš stranice operativnog sistema za pohranjivanje kopija nedavno pročitanih blokova u RAM-u.
Iako izvorni keš nije bez problema - ZFS ne može odgovoriti na nove zahtjeve za dodjelu memorije tako brzo kao kernel, tako da novi poziv malloc() dodjela memorije može propasti ako zahtijeva RAM koji trenutno zauzima ARC. Ali postoje dobri razlozi za korištenje vlastite keš memorije, barem za sada.
Svi poznati moderni operativni sistemi, uključujući MacOS, Windows, Linux i BSD, koriste LRU (Least Recently Used) algoritam za implementaciju keša stranica. Ovo je primitivni algoritam koji gura keširani blok "gore u redu" nakon svakog čitanja i gura blokove "niže u redu" prema potrebi za dodavanje novih promašaja keša (blokova koji su trebali biti pročitani s diska, a ne iz keša) gore.
Obično algoritam radi dobro, ali na sistemima sa velikim skupovima radnih podataka, LRU lako dovodi do razbijanja — izbacivanja često potrebnih blokova kako bi se napravio prostor za blokove koji više nikada neće biti pročitani iz keša.
je mnogo manje naivan algoritam koji se može smatrati "ponderisanim" kešom. Svaki put kada se čita keširani blok, postaje malo teži i teži za izbacivanje - čak i nakon što je blok izbačen tracked tokom određenog vremenskog perioda. Blok koji je izbačen, ali ga onda treba ponovo pročitati u keš memoriju također će postati teži.
Krajnji rezultat svega ovoga je keš sa mnogo većim omjerom pogodaka, omjerom između pogodaka iz keša (čitanja iz keša) i promašaja keša (čitanja s diska). Ovo je izuzetno važna statistika - ne samo da se sami keš pogoci serviraju za red veličine brže, već se i promašaji keša mogu poslužiti brže, jer što je više pogodaka u keš memoriji, to je manje istovremenih zahtjeva za diskom i manja je latencija za one preostale promašaje koji moraju biti serviran sa diskom.
zaključak
Sada kada smo pokrili osnovnu semantiku ZFS-a – kako funkcionira kopiranje na upisivanje, kao i odnose između spremišta za pohranu, virtualnih uređaja, blokova, sektora i datoteka – spremni smo razgovarati o performansama u stvarnom svijetu sa realni brojevi.
U sljedećem dijelu ćemo pogledati stvarne performanse zrcaljenih vdev i RAIDz bazena, u usporedbi jedni s drugima, kao i u poređenju sa tradicionalnim RAID topologijama jezgre Linuxa koje smo ispitali .
U početku smo željeli pokriti samo osnove - same ZFS topologije - ali kasnije takva Bićemo spremni da razgovaramo o naprednijoj konfiguraciji i podešavanju ZFS-a, uključujući upotrebu pomoćnih vdev tipova kao što su L2ARC, SLOG i Special Allocation.
izvor: www.habr.com