Sel kevadel oleme juba arutanud mitmeid algteemasid, nagu näiteks kuidas kontrollida oma kõvakettaste kiirus ja mis on RAID. Teises osas lubasime jätkata arutelusid ZFS erinevate mitme ketta topoloogiate jõudluse üle. See on järgmise põlvkonna failisüsteem, mida rakendatakse praegu igal pool: alates Apple kuni Ubuntu.

Noh, täna on meeste ja naiste õige päev ZFS-iga tutvumiseks, uudishimu tekitavad lugejad. Lihtsalt teadke, et OpenZFS arendaja Matt Ahrens'i tagasihoidlikul hinnangul "see on tõeliselt keeruline".

Enne kui jõuame numbriteni - ja need tulevad, luban - kõikide ZFS kaheksa ketta konfigureerimise võimaluste osas, peame rääkima sellest, kuidas ZFS üldiselt andmeid kettal salvestab.

Zpool, vdev ja seade

See diagramm täispunktide kogumist sisaldab kolme abivahendit vdev-i, ühe igast klassist ja neli RAIDz2 jaoks

Tavaliselt pole põhjust luua kogumit erinevat tüüpi ja suurusega vdevidest - kuid kui soovite, ei takista teid see kindlasti.

ZFS failisüsteemi tõeliseks mõistmiseks tuleb tähelepanelikult vaadata selle tegelikku struktuuri. Esiteks ühendab ZFS traditsioonilise mahuhalduse ja failisüsteemide tasemed. Teiseks kasutab see kirjutamise ajal koopia loomise tehingu mehhanismi. Need omadused tähendavad, et süsteem on struktuuri poolest väga erinev tavalistest failisüsteemidest ja RAID-massiividest. Esimene mõistmise põhielement on salvestuspank (zpool), virtuaalne seade (vdev) ja reaalne seade (device).

zpool

Salvestuspank zpool on ZFS kõige ülemine struktuur. Iga pank sisaldab ühte või mitut virtuaalset seadet. Omakorda sisaldab igaüks neist ühte või mitut reaalset seadet (device). Virtuaalsed pangad on iseseisvad plokid. Üks füüsiline arvuti võib sisaldada kahte või enamat eraldi panka, kuid igaühel on täielik sõltumatus teistest. Pangad ei saa jagada virtuaalseid seadmeid.

ZFS-i ülekandmine toimub virtuaalsete seadmete tasandil, mitte reservuaaride tasandil. Reservuaaride tasandil ei ole mingit ülekandsüsteemi - kui mõni vdev või erivdev kaob, kaob koos sellega kogu reservuaar.

Kaasaegsed salvestusreservuaarid suudavad taluda virtuaalse seadme vahemälu või žurnali kaotust - kuigi nad võivad kaotada väikese hulga rikutud andmeid, kui nad kaotavad vdevi žurnali voolukatkestuse või süsteemi rikke ajal.

On levinud väärarusaam, et ZFS-i "andmeriidud" (stripe'id) salvestatakse kogu reservuaari ulatuses. See ei ole tõsi. Zpool ei ole sugugi naljakas RAID0, vaid pigem naljakas JBOD keerulise ja muutuva jaotamismechanismiga.

Peamiselt jaotatakse salvestused saadavalolevate virtuaalsete seadmete vahel olemasoleva vaba ruumi alusel, nii et seeoretiseeritult täidavad need kõik korraga. Uuemates ZFS versioonides arvestatakse praegust kasutust (utiliseerimist) vdev'i puhul — kui üks virtuaalne seade on oluliselt koormatum kui teine (näiteks lugemise koormuse tõttu), jäetakse selle kirjutamiseks vahepeal kõrvale, hoolimata kõrgeimast vabade ruumide osakaalust.

Utiliseerimise määramise mehhanism, mis on integreeritud kaasaegsetesse ZFS salvestusmeetoditesse, võib vähendada viivitust ja suurendada läbilaskevõimet ebatavaliselt kõrgete koormuste perioodidel — kuid see ei blankett kui juhuslik segu aeglastest HDD-dest ja kiiretest SSD-dest ühes soos. Selline ebaühtlane soe töötab siiski aeglaseima seadme kiirusel, nagu oleks see täielikult koos sellistest seadmetest.

vdev

Iga salvestuspools koosneb ühest või mitmest virtuaalsest seadmest (virtual device, vdev). Iga vdev omakorda sisaldab ühte või mitut füüsilist seadet. Enamik virtuaalseid seadmeid kasutatakse andmete lihtsaks salvestamiseks, kuid on olemas ka mitmeid abiklasse vdev, sealhulgas CACHE, LOG ja SPECIAL. Igal neist vdev-i tüüpide puhul võib olla üks viiest topoloogiast: ühes seadmest (single-device), RAIDz1, RAIDz2, RAIDz3 või peegel (mirror).

RAIDz1, RAIDz2 ja RAIDz3 on erilised variandid, mida vanad inimesed nimetasid RAID kahekordseks (diagonaalseks) pariteediks. 1, 2 ja 3 viitavad sellele, kui palju pariteediblokeerimist on eraldatud iga andmevoo jaoks. Selle asemel, et kasutada eraldi kettaid pariteedi tagamiseks, jaotavad RAIDz virtuaalsed seadmed selle pariteedi ühtlaselt diskide vahel. RAIDz-massiiv võib kaotada sama arvu kettaid, kui tal on pariteediblokeerimisi; kui see kaotab veel ühe, siis see lakkab töötamast ja viib kaasa salvestuspooli.

Peegeldavad virtuaalsed seadmed (mirror vdev) salvestavad iga ploki igas seadmes vdev'is. Kuigi kõige levinumad on topeltpeeglid (two-wide), võib peeglis olla meelevaldne arv seadmeid — suuremates seadmetes kasutatakse sageli kolmikuid lugemisvõimekuse ja tõrke taluvuse parandamiseks. Vdev peegel suudab üle elada mis tahes tõrke, kui vdev'is töötab vähemalt üks seade.

Üksikud vdev'id on oma olemuselt ohtlikud. Selline virtuaalne seade ei talleta tõrget — ja kui seda kasutatakse salvestusena või spetsiaalse vdev'ina, toob selle tõrge kaasa kogu basseini hävimise. Olge siin väga ettevaatlik.

Virtuaalsed seadmed CACHE, LOG ja SPECIAL võivad olla loodud mis tahes eespool mainitud topoloogiate põhjal — kuid pidage meeles, et virtuaalse seadme SPECIAL kaotus tähendab basseini kadumist, seetõttu on soovitatav üleliigne topoloogia.

device

Tõenäoliselt on see ZFS-i kontekstis kõige arusaadavam termin – see viitab tegelikult juhusliku ligipääsu blokiseadmestikule. Pea meeles, et virtuaalsed seadmed koosnevad eraldi seadmetest ning bassein koosneb virtuaalsetest seadmetest.

Kettad – kas magnetilised või SSD-d – on kõige levinumad blokeeringuseadmestikud, mida kasutatakse vdev-i ehitusplokkidena. Kuid sobib iga seade, millel on kirjeldus /dev-s – seega võivad eraldi seadmetena kasutada isegi terveid riistvaralisi RAID-massiive.

Lihtne raw-fail on üks tähtsamaid alternatiivseid blokeeringuseadmestikke, mille baasil võib vdev-i luua. Testbasseinid, mis on tühjad failid – on väga mugav viis käskude testimiseks ja jälgimiseks, kui palju ruumi on basses või antud topoloogias virtuaalses seadmes saadaval.

Sa saad luua testbasseini tühjadest failidest vaid mõne sekundiga – aga ära unusta seejärel kogu basseini ja selle komponente kustutada.

Oletame, et soovite seadistada serverit kaheksa kõvakettaga ja kavatsete kasutada 10 TB (~9300 GiB) kettaid — kuid te ei ole kindel, milline topoloogia vastab kõige paremini teie vajadustele. Ülaltoodud näites loome mõne sekundi jooksul katsepilu hajutatud failideks — ja nüüd teame, et kaheksast 10 TB ketast koosnev RAIDz2 vdev pakub 50 TiB kasulikku mahutavust.

Veel üks eriline seadmete klass on SPARE (varu). Kuumalt vahetatavad seadmed erinevad tavapärastest seadmetest, kuna need kuuluvad kogu pilvele, mitte ainult ühele virtuaalseadmele. Kui mõni vdev pilves ebaõnnestub ja reserveeritud seade on pilvega ühendatud ja saadaval, liitub see automaatselt kahjustatud vdev-iga.

Pärast kahjustatud vdev-iga ühendamist hakkab reserveeritud seade saama koopiaid või ümber ehitusi andmetest, mis peaksid olema puuduvatel seadmetel. Traditsioonilises RAID-is nimetatakse seda taastamiseks (rebuilding), ZFS-is aga „ülejäägi taastamiseks“ (resilvering).

Oluline on märkida, et varuteenused ei asenda riknenud seadmeid igaveseks. Need on vaid ajutised asendused, et vähendada vdev-degrdeerimise ajal kadumisaega. Kui administraator asendab riknenud seadme vdev-is, toimub üleliigsuse taastamine sellele püsivale seadmele, SPARE ühendus katkestatakse vdev-ist ja naaseb varuna kogu basseini jaoks.

Andmekogud, blokk ja sektorid

Järgmine ehitusplokkide kogum, mida on vajalik meie ZFS-i teekonna jooksul mõista, ei puuduta niivõrd riistvara, vaid seda, kuidas andmed on organiseeritud ja salvestatud. Me jätame siit vahele mõned tasemed, nagu metaslab, et mitte detailidega üle koormata, säilitades samas üldise struktuuri mõistmise.

Andmekogud (dataset)

Kui loome andmekogu esmakordselt, näitab see kogu basseini saadaval olevat ruumi. Siis seadistame kvoodi ja muudame mount-punkti. Võlu!

Zvol on suuresti lihtsalt andmekogu, millel puudub oma failisüsteemi kiht, mida asendame siin täiesti normaalse failisüsteemiga ext4.

ZFSi andmekogum sarnaneb standardse monteeritud failisüsteemiga. Nagu tavaline failisüsteem, näib see esmapilgul "lihtsalt veel ühe kausta". Kuid nagu tavalistel monteeritud failisüsteemidel, on igal ZFSi andmekogumil oma põhiväärtuste kogum.

Esiteks võib andmekogumile olla määratud kvoot. Kui seadistada zfs set quota=100G poolname/datasetname, siis ei saa te monteeritud kausta /poolname/datasetname kirjutada rohkem kui 100 GiB.

Kas olete märganud, et iga rea alguses on olemas - ja puuduvad - kaldkriipsud? Igal andmekogumil on oma koht nii ZFSi hierarhias kui ka süsteemi monteerimise hierarhias. ZFSi hierarhias ei ole algset kaldkriipsu - alustate puu nimest ja seejärel tee järgmisest andmekogumist järgmisse. Näiteks, pool/vanem/laps andmekogumi nimega laps vanema andmekogumi vanem loomingulise nimega pool.

Vaikimisi on andmekogumi monteerimispunkt võrreldav selle nimega ZFSi hierarhias, algse kaldkriipsuga - puu nimega pool monteeritakse kui /pool, andmekogum vanem monteeritakse /pool/parent, ja alandmikuna andmekogum laps monteeritakse /pool/parent/child. Siiski saab süsteemi andmestiku mount-punkti muuta.

Kui määrame zfs set mountpoint=/lol pool/parent/child, siis andmestik pool/vanem/laps mountitakse süsteemi kui /lol.

Lisaks andmestikele peame mainima ka mahtu (zvols). Maht on ligikaudu sarnane andmestikule, välja arvatud see, et tal ei ole tegelikult failisüsteemi — see on lihtsalt plokkseade. Näiteks võite luua zvol nimega mypool/myzvol, seejärel vormindada selle failisüsteemiga ext4 ja seejärel mountida selle failisüsteemi — nüüd on teil ext4 failisüsteem, kuid ZFS-i terviklikkuse funktsioonidega! See võib tunduda rumal ühe arvuti puhul, kuid on palju mõistlikum iSCSI seadme eksportimise tagasiside osana.

Plokid

Fail esindab ühte või mitut plokki. Iga plokk salvestatakse ühel virtuaalsel seadmel. Ploki suurus on tavaliselt seadistuse recordsize, kuid võib olla vähendatud 2^ashift, kui see sisaldab metaandmeid või väikest faili.

Me tõesti, tõesti ei nalja tohutu jõudluse kaotuse osas, kui seadistate liiga väikese ashift'i

ZFS-i kontekstis salvestatakse kõik andmed, sealhulgas metainformatsioon, plokkides. Iga andmehulgaga seotud ploki maksimaalne suurus määratakse atributi kaudu recordsize (sisalduse suurus). Andmeüksuse suurus võib varieeruda, kuid see ei muuda juba salvestatud plokkide suurust ega asukohta — see kehtib ainult uute plokkide jaoks nende salvestamisel.

Kui ei ole määratud teisiti, on vaikimisi andmesalvestuse suurus 128 KiB. See on omamoodi keeruline kompromiss, kus jõudlus on enamasti küllaltki hea, kuid mitte ideaalne. Sisalduse suurus võib seada vahemikku 4K kuni 1M (täiendavate seadistustega recordsize võib seadistada isegi suuremaks, kuid see ei ole sageli hea idee).

Iga plokk viitab ainult ühe faili andmetele — teist faili ei saa sama plokki mahutada. Iga fail koosneb ühest või mitmest plokist, olenevalt suurusest. Kui faili suurus on väiksem kui andmesalvestuse suurus, salvestatakse see väiksemas plokis — näiteks 2 KiB faili sisaldav plokk võtab kettal ära vaid ühe 4 KiB sektori.

Kui fail on piisavalt suur ja vajab mitut plokki, siis kõik selle failiga seotud kirjed on suurusega recordsize — sealhulgas viimane rekord, mille peamine osa võib olla kasutamata ruum.

Zvol volumentidel ei ole omadust recordsize — selle asemel on neil võrdne omadus volblocksize.

Sektsioonid

Viimane ja kõige elementaarsem ehitusplokk on sektsioon. See on väikseim füüsiline ühik, mida saab salvestada või lugeda algsest seadmest. Aastakümnete jooksul on enamik diskidest kasutanud 512-baidiseid sektsioone. Viimasel ajal on enamik diskidest seadistatud 4 KiB sektsioonide peale, samas kui mõned — eriti SSD-d — kasutavad sektsioone, mis on 8 KiB või isegi rohkem.

ZFS süsteemis on omadus, mis võimaldab manuaalselt seadistada sektsiooni suuruse. See omadus ashift. Veidi segane on see, et ashift on kahe astme. Näiteks, ashift=9 tähendab sektsiooni suurust 2^9 ehk 512 bahti.

ZFS küsib operatsioonisüsteemilt igasugust teavet iga plokiseadmest, kui see lisatakse uut tüüpi vdev-ile, ning teoreetiliselt seab see automaatselt ashifti õigeks, tuginedes sellele teabele. Kahjuks valevad paljud kettad oma sektorite suuruses, et säilitada ühilduvus Windows XP-ga (mis ei suutnud mõista kettaid, millel on erinevad sektorite suurused).

See tähendab, et ZFS administraator peab kindlasti teadma oma seadmete tegelikku sektorite suurust ja seadma selle käsitsi ashift. Kui ashift on seatud liiga väikeseks, siis suureneb lugemise/kirjutamise operatsioonide arv astronoomiliselt. Näiteks 512-aatomiliste "sektorite" kirjutamine tegelikku 4 KiB-sektorisse tähendab, et tuleb kirjutada esimene "sektor", seejärel lugeda 4 KiB sektorit, muuta seda teise 512-aatomilise "sektoriga", kirjutada see tagasi uude 4 KiB sektorisse ja nii edasi iga kirjutise jaoks.

Tegelikus maailmas tabab selline trahv Samsung EVO tahkiskettaid, mille puhul peaks kehtima ashift=13, kuid need SSD-d valetavad oma sektorite suuruse kohta, seetõttu on see vaikimisi seatud ashift=9. Kui kogenud süsteemiadministraator seda parameetrit ei muuda, töötab see SSD aeglasemalt tavalise magnetse HDD-ga.

Võrdluseks, liiga suure suuruse eest ashift praktiliselt ei tule mingeid karistusi. Tegelikku jõudluse langust ei esine ja kasutamata ruumi suurenemine on äärmiselt väike (või null, kui on sisse lülitatud tihendamine). Seetõttu soovitame tungivalt isegi neile ketastele, mis tõeliselt kasutavad 512-baidiseid sektoreid, seadistada ashift=12 või isegi ashift=13, et kindlalt tulevikku vaadata.

Omadus ashift seatakse iga virtuaalse seadme vdev jaoks, mitte pala, nagu paljud ekslikult arvavad — ja seda ei muudeta pärast seadistamist. Kui te juhuslikult rikkusite ashift uue vdev-i lisamisega pala, siis olete jäädavalt saastanud selle pala madala jõudlusega seadmega ja tavaliselt pole teisi võimalusi, välja arvatud pale hävitamine ja uuesti alustamine. Isegi vdev-i eemaldamine ei päästa vale seadistuse eest ashift!

Kirjutamise ajal kopeerimise mehhanism

Kui tavaline failisüsteem peab andmeid üle kirjutama — muudab see iga ploki seal, kus see asub

Failosüsteem kopeerimise kirjutamisel salvestab uue ploki versiooni ja seejärel vabastab vana versiooni.

Abstraktselt öeldes, kui ignoreerida plokkide tegelikku füüsilist asukohta, lihtsustub meie 'andmete komeet' 'andmete ussiks', mis liigub vasakult paremale saadaval oleva ruumi kaardil.

Nüüd saame hästi aru, kuidas kopeerimise kirjutamise snäppšotid töötavad — iga plokk võib kuuluda mitmesse snäppšotti ning püsib, kuni kõik seotud snäppšotid on hävitatud.

Kopeerimise kirjutamise mehhanism (Copy on Write, CoW) on fundamentaalne alus, mis teeb ZFSi nii uskumatuks süsteemiks. Peamine kontseptsioon on lihtne — kui palute traditsioonilisel failisüsteemil faili muuta, teeb ta just seda, mida palusite. Kui palute kopeerimise kirjutamise failisüsteemil sama teha, ütleb ta 'hea küll' — aga valetab teile.

Selle asemel kirjutab failisüsteem kirjutamise kopeerimisega uue versiooni muudetud blokkist ning seejärel uuendab faili metaandmed, et katkestada seos vana blokiga ja siduda see uue blotiga, mille just kirjutasite.

Vana bloki lahtiühendamine ja uue sidumine toimub ühe operatsiooni käigus, mistõttu ei saa seda katkestada — kui lülitate toite välja pärast seda, kui see on toimunud, on teil uus failiversioon, ja kui lülitate toite välja enne seda, on teil vana versioon. Igatahes ei teki failisüsteemis konflikte.

Kirjutamise kopeerimine ZFS-is toimub mitte ainult failisüsteemi tasandil, vaid ka ketaste haldamise tasandil. See tähendab, et ZFS ei ole tundlik kirjutamispuuduste suhtes (RAID-i augu) — fenomen, kus riba õnnestus osaliselt kirjutada enne süsteemi tõrget, kahjustades massiivi pärast taaskäivitamist. Siin kirjutatakse riba aatomaariselt, vdev on alati järjekindel, ja Bob on sinu onu.

ZIL: ZFS-i kavatsuste ajakiri

ZFS süsteem töötleb sünkroonne kirjutisi eriliselt – see salvestab need ajutiselt, kuid kohe ZIL-i, enne kui kirjutab need hiljem püsivalt koos asünkroonsete kirjutistega.

Tavaliselt ei loeta ZIL-is salvestatud andmeid enam kunagi välja. Kuid see on võimalik pärast süsteemi riket.

SLOG ehk sekundaarne LOG-seade on lihtsalt eriline – ja eelistatavalt väga kiire – vdev, kus ZIL-i saab salvestada eraldi peamisest salvestusruumist.

Pärast riket loetakse kõik määrdunud andmed ZIL-ist taastatavaks – antud juhul asub ZIL SLOG-is, nii et need loetakse sealt.

On olemas kaks peamist kirjutamise operatsiooni kategooriat – sünkroonsed (sync) ja asünkroonsed (async). Enamikus töökoormustes on enamus kirjutamistegevusi asünkroonsed – failisüsteem võimaldab neid koguda ja välja anda pakettidena, vähendades fragmenteerimist ja oluliselt suurendades läbilaskevõimet.

Sünkroonsed kirjutised on hoopis midagi muud. Kui rakendus nõuab sünkrooni kirjutamist, ütleb see failisüsteemile: „Peate selle kohe salvestama energiakindlasse mällu. just praegu, ja kuni siis ei saa ma midagi muud teha.” Seetõttu peavad sünkroonsed kirjed koheselt ketta peale salvestuma – ja kui see suurendab fragmenteerimist või vähendab läbilaskevõimet, siis nii peabki olema.

ZFS käsitleb sünkroone kirjeid teisiti kui tavalised failisüsteemid – selle asemel, et need kohe tavalisse salvestusse laadida, salvestab ZFS need spetsiaalsesse salvestuspiirkonda, mida nimetatakse ZFS-i kavatsuste ajaks (ZFS Intent Log, või ZIL). Trikk on selles, et need kirjed ka jäävad mällu, olles kogutud koos tavaliste asünkroonsete kirjutamisotsega, et hiljem salvestada need salvestusse täiesti normaalses TXG (tehingugrupid, Transaction Groups) vormis.

Tavaliselt salvestatakse ZIL ja seda ei loeta enam kunagi. Kui pärast mõnda hetke ZIL-st salvestatud kirjed kinnitatakse peamisse salvestusse tavapärases TXG-s mälust, eraldatakse need ZIL-ist. Ainsad korrad, kui ZIL-ist midagi loetakse, on siis, kui tehakse basseini import.

Kui ZFS-i süsteem või toitekatkestus põhjustab vea, kui ZIL-is on andmeid, loetakse need andmed järgmise basseini impordi ajal (näiteks pärast avariilise süsteemi taaskäivitamist). Kõik, mis on ZIL-is, loetakse, kogutakse TXG gruppidesse, salvestatakse põhiahendisse ja seejärel eemaldatakse ZIL-ist impordi käigus.

Üks vdev-i abikliendi kategooriaid on LOG või SLOG, teisejärguline LOG seade. Selle ainus ülesanne on anda basseini eraldi ja, eelistatavalt, palju kiiream vdev, mille kirjutamisvastupidavus on väga kõrge, ZIL-i salvestamiseks, mitte peahoidlas vdev-s. Isegi kui ZIL käitub sõltumatult salvestuskohtadest, siis kui LOG-vdev-il on kirjutamise osas väga kõrge jõudlus, toimuvad sünkroonsed kirjutised kiiremini.

LOG vdev-i lisamine basseini ei saa parandada asünkroonsete kirjutiste sooritust — isegi kui sunnite kõik kirjutised ZIL-i tegema zfs set sync=always, nad siiski on nad endiselt seotud peamise salvestusega TXG samamoodi ja samas tempos nagu ilma päevikuta. Ainus otsene jõudluse parendamine on sünkroonselte kirjutuste viivitus (kuna päeva suurem kiirus kiirendab toimingute täitmist sync).

Kuid keskkonnas, kus on juba vaja suurt hulka sünkroonseid kirjeid, võib vdev LOG kaudselt kiirendada asünkroonset kirjutamist ja vahemäluta lugemist. ZIL-i kirjeid eraldi vdev LOG-i laadides on vähem konkurentsi IOPS-i pärast põhilises salvestuses, mis tõstab teatud määral kõigi lugemis- ja kirjutamistoimingute jõudlust.

Snaipid

Kirjutamisel kopeerimise mehhanism on samuti vajalik alus ZFS-i aatomiliste hetkepiltide ja inkrementaalse asünkroonse replikatsiooni jaoks. Aktiivses failisüsteemis on olemas viidete puu, mis tähistab kõiki kirjeid koos praeguste andmetega — kui teete snaipi, teete lihtsalt koopia sellest viidete puust.

Aktive failisüsteemi kirje uuendamisel kirjutab ZFS esmalt uue ploki versiooni kasutamata ruumi. Seejärel eraldab see vana ploki versiooni praegusest failisüsteemist. Kuid kui mõni snapshot viitab vanale plokile, jääb see siiski muutumatuks. Vana plokk ei muutu tegelikult vabaks ruumiks, kuni kõik snapshotid, mis viitavad sellele plokile, on kustutatud!

Replikatsioon

Minu Steam'i raamatukogu 2015. aastal oli 158 GiB ja sisaldas 126 927 faili. See on üsna lähedal optimaalsele olukorrale rsync'i jaoks — ZFS replikatsioon võrgu kaudu oli "ainult" 750% kiiremini.

Samas võrgus on 40 GiB suuruse Windows 7 virtuaalmasina pildi faili replikatsioon täiesti teine lugu. ZFS replikatsioon toimub 289 korda kiiremini kui rsync — või "ainult" 161 korda kiiremini, kui olete piisavalt tundlik, et käivitada rsync koos võtit —inplace.

Kui virtuaalmasina pilt suureneb, kaasnevad probleemid rsynciga samuti. 1,9 TiB suurus ei ole tänapäeva virtuaalmasina pildi jaoks ülemäära suur — aga see on piisavalt suur, et ZFS-i replikatsioon toimuks 1148 korda kiiremini kui rsync, isegi rsynci argumentidega —inplace.

Kui olete aru saanud, kuidas snapshots töötavad, on replikatsiooni olemuse mõistmine lihtne. Kuna snapshot on lihtsalt salvestuste teedepuu, tuleneb sellest, et kui teeme zfs send snapshot'i, saatme selle puu ja kõik sellega seotud salvestused. Kui edastame selle zfs send ühes zfs receive sihtobjekti, salvestab see nii tegeliku ploki sisu kui ka puu, mis osutab plokkidele, sihtkoha andmekogusse.

Asjad muutuvad veelgi huvitavamaks teises zfs send. Nüüd on meil kaks süsteemi, igal neist on poolname/datasetname@1, ja te teete uue snapshot'i poolname/datasetname@2. Seega on algses puus datasetname@1 ja datasetname@2, samas kui sihtpuus on ainult esimene snapshot. datasetname@1.

Kuna meil on allika ja sihtkoha vahel ühine snapshot datasetname@1, saame luua inkrementaalse zfs send selle peale. Kui me räägime süsteemist zfs send -i poolname/datasetname@1 poolname/datasetname@2, see võrreldakse kahte näidiku puud. Kõik näidikud, mis eksisteerivad ainult @2, viitavad selgelt uutele plokkidele — seega vajame nende plokkide sisu.

Kaugsüsteemis inkrementaalse töötlemine send on samuti lihtne. Esiteks kirjutame kõik uued kirjed, mis on voos send, ja seejärel lisame viidatud need plokid. Voilà, meil on @2 uus süsteem!

ZFS asünkroonne inkrementaalne replikatsioon on suur edasiminek võrreldes varasemate meetoditega, mis ei põhine snäpšottidel, näiteks rsync. Mõlemal juhul edastatakse ainult muudetud andmed — kuid rsync peab kõigepealt lugema kõik andmed mõlemast küljest kettalt, et kontrollida kokkuvõtte ja võrrelda seda. Erinevalt sellest ei loe ZFS replikatsioon midagi muud kui näidiku puid — ja mis tahes plokke, mis ei ole esitatud üldises snäpšotis.

Sisseehitatud pakkimine

Kopeerimise mehhanism salvestamise ajal lihtsustab ka sisseehitatud tõhukeskkonna süsteemi. Traditsioonilisest failisüsteemist on tihendamine probleemne — nii vana kui ka uus muudetud andmete versioon asub samas ruumis.

Kui vaatame andmefraktsiooni faili keskel, mis alustab oma elu megabaidi nullidest alates 0x00000000 ja nii edasi — on seda väga lihtne tihendada ühe ketta sektorini. Kuid mis juhtub, kui asendame selle megabaidi nullid mittetihendatavate andmetega, nagu JPEG või pseudojuhuslik müra? Ühtäkki nõuab see megabait andmeid mitte ühte, vaid 256 sektorit, igaüks 4 KiB, samas kui sellel kohal kettal on reserveeritud ainult üks sektor.

ZFS-il pole sellist probleemi, kuna muudetud kirjed kirjutatakse alati kasutamata ruumi — algne plokk võtab ainult ühe 4 KiB sektori, samas kui uus kirje võtab 256, kuid see pole probleem — hiljuti muudetud fraktsioon failist 'keskel' kirjutataks alati kasutamata ruumi sõltumata selle suuruse muutumisest, seega on see ZFS-i jaoks täiesti normaalne olukord.

ZFS-i sisseehitatud tihendamine on vaikimisi välja lülitatud ning süsteem pakub lahtiselt ühendatavaid algoritme — nende seas on nüüd LZ4, gzip (1-9), LZJB ja ZLE.

• LZ4 on voolualgoritm, mis pakub äärmiselt kiiret tihendamist ja dekompressiooni ning parendust enamike kasutusjuhtude jaoks — isegi üsna aeglastel CPU-del.
• GZIP on austatud algoritm, mida tunnevad ja armastavad kõik Unix-süsteemide kasutajad. Seda saab rakendada tihendustasemetes 1-9, kus tihendustase ja CPU kasutamine suurenevad, kui läheneda tasemele 9. Algoritm sobib hästi kõigile tekstilistele (või muudele ülihästi tihendatavatele) kasutusviisidele, kuid muidu sageli tekitab probleeme CPU-ga — kasutage seda ettevaatlikult, eriti kõrgematel tasemetel.
• LZJB on ZFS-i originaalalgoritm. See on vananenud ja seda ei tohiks enam kasutada, LZ4 ületab selle kõigis näitajates.
• ZLE — nulltaseme kodeering, Zero Level Encoding. See ei mõjuta tavapäraseid andmeid, kuid tihendab suuri nullide järjestusi. See on kasulik täiesti tihendamatute andmekogumite jaoks (nt JPEG, MP4 või teiste juba tihendatud formaatide puhul), kuna see ignoreerib tihendamatuid andmeid, kuid tihendab kasutamata ruumi lõppsalvestistes.

Soovitame LZ4 tihendust praktiliselt kõigi kasutusvõimaluste jaoks; performantsi karistus tihendamatute andmete korral on väga väike, samas kui kasv tavapäraste andmete jaoks on see märkimisväärne. Virtuaalmasina pildi kopeerimine uue Windows operatsioonisüsteemi installatsiooni jaoks (värskelt installitud OS, sees pole veel andmeid) koos compression=lz4 toimus 27% kiiremini kui compression=none, in selles 2015. aasta testis.

ARC — kohandatud asenduskühvelduse vahemälu

ZFS on ainus kaasaegne failisüsteem, millest me teame, mis kasutab oma lugemise vahemälumehhanismi, mitte ei toetunud operatsioonisüsteemi lehe vahemälule, et salvestada hiljuti loetud blokke mällu.

Kuigi enda vahemälu ei ole probleemideta — ZFS ei saa uusi mälukasutuse soove sama kiiresti töödelda kui tuum, mistõttu uus kutse malloc() mäluekspressioon võib ebaõnnestuda, kui see vajab hetkel ARC-is hõivatud töömälu. Siiski on tungiv vajadus kasutada enda vahemälu, vähemalt praegu.

Kõik tuntud kaasaegsed operatsioonisüsteemid, sealhulgas MacOS, Windows, Linux ja BSD, kasutavad lehekülgede vahemälu rakendamiseks LRU (Least Recently Used) algoritmi. See on primitiivne algoritm, mis tõstab pärast iga lugemist vahemälustatud ploki „järjekorras üles” ja asendab plokke „järjekorras alla” vastavalt vajadusele, et lisada uusi vahemälu puudeid (plokid, mida oleks pidanud lugema diskilt, mitte vahemälust) kõrgemasse.

Tavaliselt töötab algoritm korralikult, kuid suurte andmekogumite süsteemides toob LRU kergesti kaasa thrashing'i — sageli vajalike plokkide asendamine, et vabastada ruumi plokkidele, mida enam vahemälust ei loeta.

ARC — tunduvalt vähem naiivne algoritm, mida saab vaadelda kui 'kaalutud' vahemälu. Pärast iga vahemälublooki lugemist muutub see veidi 'raskemaks' ja on raskem kõrvaldada — isegi pärast kõrvaldamist muutub plokk jälgitud teatud aja jooksul. Plokk, mis on kõrvaldada, kuid peab seejärel uuesti vahemällu lugema, muutub samuti 'raskemaks'.

Kõikide nende tulemusena on vahemälu palju suurema tabamussuhtega (hit ratio) — suhe vahemälu tabamiste (lugemine, mis toimub vahemälust) ja vahelejätmiste (lugemine kettalt). See on äärmiselt oluline statistika — mitte ainult, et vahemälu tabamised teenindatakse järsult kiiremini, vaid ka vahelejätmised võivad saada kiiremini teenindatud, kuna mida rohkem vahemälu tabamisi — seda vähem on paralleelseid päringuid kettale ja seda väiksem on viivitus nende jääkide vahelejätmiste jaoks, mis tuleb teenindada kettalt.

Kokkuvõte

Pärast ZFS põhisemantika uurimist — kuidas toimub kirjutamise käigus kopeerimine ning suhetest salvestuspaikade, virtuaalsete seadmete, plokkide, sektorite ja failidega — oleme valmis arutama tegelikku jõudlust ja reaalseid numbreid.

Järgmisest osast vaatame, kuidas toimivad peegeldava vdev ja RAIDz salvestuspaigad üksteisega võrreldes, samuti võrreldes traditsiooniliste Linuxi RAID-topoloogiatega, mida me oleme uurinud. oleme teada saanud.

Alguses soovisime arutada ainult põhitõdesid — ZFS enda topoloogiaid — kuid pärast sellist oleme valmis rääkima edasise ZFS seadistamise ja häälestamise üle, sealhulgas abiseadmete vdev-tüüpide kasutamisest, nagu L2ARC, SLOG ja Special Allocation.

Allikas: habr.com