Sel kevadel arutasime juba mõningaid sissejuhatavaid teemasid, näiteks kuidas kontrollida oma ketaste kiirus ja mis on RAID. Teises neist lubasime isegi jätkata ZFS-s erinevate mitme ketta topoloogiate jõudluse uurimist. See on järgmise põlvkonna failisüsteem, mida rakendatakse praegu laialdaselt, alates Apple kuni Ubuntu.

Noh, täna on kõige sobivam päev ZFS-iga tutvumiseks, uudishimulikkud lugejad. Lihtsalt teadke, et OpenZFS arendaja Matt Ahrens on tagasihoidlikult öelnud, et 'see on tõeliselt keeruline'.

Kuid enne, kui jõuame numbrite juurde – ja need tulevad, luban – ZFS-i kaheksakettilise konfiguratsiooni kõikide variantide osas, peame rääkima sellest, kuidas kuidas ZFS tõeliselt andmeid kettale salvestab.

Zpool, vdev ja seade

See diagramm sisaldab täielikku puuli, kus on kolm abivahendit vdev'i, üks igast klassist, ja neli RAIDz2 jaoks

Tavaliselt pole põhjust luua puu, mis koosneb sobimatutest tüüpidest ja suurustest vdev'idest – aga kui soovite, ei takista teid miski selle tegemiselt

Kuna ZFS failisüsteemi tõeliselt mõistmiseks peate hoolikalt vaatama selle tegelikku struktuuri. Esiteks, ZFS ühildab traditsioonilised mahtude ja failisüsteemi halduse tasemed. Teiseks kasutab ta kirjutamise ajal koopiate tegemise tehingumehhanismi. Need omadused tähendab, et süsteem on struktuuriliselt väga erinev tavalisest failisüsteemist ja RAID-massiividest. Esimene põhiehituse elementide komplekt, mida mõista: see on salvestuspuu (zpool), virtuaalne seade (vdev) ja tegelik seade (seade).

zpool

Salvestuspuu zpool on ZFS-i kõige ülemine struktuur. Iga puu sisaldab ühte või mitut virtuaalset seadet. See omakorda sisaldab ühte või mitut tegelikku seadet (seade). Virtuaalsed puud on iseseisvad üksused. Üks füüsiline arvuti võib sisaldada kahte või enamat eraldi puud, kuid igaüks neist on teistest täielikult sõltumatu. Puid ei saa ühiselt kasutada virtuaalseid seadmeid.

ZFS-i üleliigusus asub virtuaalsete seadmete tasemel, mitte puude tasemel. Puu tasemel ei ole absoluutselt mingit üleliigsust – kui mõni vdev või eelnevalt määratud vdev kaob, kaob koos sellega ka kogu puu.

Kaasaegsed salvestuspaigid võivad taluda virtuaalse seadme vahemälu või logi kaotust, kuigi nad võivad kaduda väikese hulga räpaste andmete, kui nad kaotavad vdev logi voolukatkestuse või süsteemirikkega.

On levinud väärarusaam, et ZFS andmepaarid (stripes) kirjutatakse kogu paiki. See ei ole tõsi. Zpool ei ole lihtsalt lõbus RAID0, see on pigem lõbus. JBOD keerulise muutliku jaotamismehhanismiga.

Suur osa kirjutamist jagatakse kergesti saadavail virtuaalsetel seadmetel, lähtudes olemasolevast vaba ruumist, nii et teoreetiliselt täidetakse need kõik samaaegselt. Uuemates ZFS versioonides arvestatakse jooksva kasutuse (utiliseerimise) vdev'i - kui üks virtuaalne seade on palju rohkem koormatud kui teine (näiteks lugemise koormuse tõttu), siis selle kirjutamise ajutiselt mööda minnakse, hoolimata kõrgeimast vabast ruumist.

Kaasaegse ZFS kirjutamise jaotamismehhanismis sisseehitatud(utiliseerimise) seire võib vähendada viivitust ja suurendada läbilaskevõimet ebatavaliselt kõrgete koormuste ajal - kuid see ei ole karantsi aeglaste HDD-de ja kiirete SSD-de tahtmatu segamise vastu ühes paigis. Selline ebaühtlane paigaldus töötab siiski kõige aeglasema seadme kiirusel, see tähendab, et see toimib nagu oleks see täielikult koostatud sellistest seadmetest.

vdev

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

RAIDz1, RAIDz2 ja RAIDz3 on erilised variandid sellest, mida vanad nimetavad kahekordseks (diagonaalseks) pariteediks. 1, 2 ja 3 viitavad sellele, kui palju pariteetplokke on eraldatud iga andmete ribale. Erinevalt eraldiseisvatest kettadest, mis tagavad pariteedi, jaotavad RAIDz virtuaalsed seadmed pariteedi kettale ühtlaselt. RAIDz massiiv suudab kaotada nii palju kettasid, kui tal on pariteetplokke; kui ta kaotab veel ühe, lakkab ta olemast ja viib endaga kaasa salvestusalu.

Peegeldavatel virtuaalsetel seadmetel (mirror vdev) hoitakse iga plokk iga seadme peal vdev-is. Kuigi kõige levinumad on kaksikpeeglid (two-wide), võib peeglis olla mis tahes arvu seadmeid - suurtes seadistustes, et suurendada lugemise jõudlust ja talitlushäirete vastupidavust, kasutatakse sageli kolmikpeegleid. Vdev peegeldus suudab taluda mis tahes rikkeid, seni kuni vähemalt üks seade vdev-is töötab.

Üksikud vdev-id on oma olemuselt ohtlikud. Selline virtuaalne seade ei talunda ühtegi riket - ja kui seda kasutatakse salvestusala või spetsiaalse vdev-i jaoks, toob tema rike kaasa kogu ala hävimise. Olge selle osas väga, väga ettevaatlik.

Virtuaalsed seadmed CACHE, LOG ja SPECIAL võivad olla loodud mis tahes ülaltoodud topoloogiate põhjal - kuid pidage meeles, et virtuaalse seadme SPECIAL kaotamine tähendab kogu ala kaotamist, seetõttu on tungivalt soovitatav üleliigne topoloogia.

seade

See on tõenäoliselt kõige lihtsam mõistetav termin ZFS-is - see on sõna-sõnalt juhusliku juurdepääsu blokiseade. Pidage meeles, et virtuaalsed seadmed koosnevad eraldi seadmetest ja ala on loodud virtuaalsetest seadmetest.

Kettad - magnetilised või tahked - on kõige levinumad blokiseadmestena, mida kasutatakse vdev-i ehitamiseks. Siiski sobib iga seade, millel on kirjeldus /dev-is - seega võib eraldi seadmetena kasutada ka terveid riistvara RAID-massiive.

Lihtne raw-fail on üks kõige olulisemaid alternatiivseid blokiseadmeid, millest vdev-i saab ehitada. Testimisalad haruldased failid on väga mugav viis kontrolida ala käske ja näha, kui palju ruumi on saadaval antud topoloogia ala või virtuaalse seadme jaoks.

Saate luua testkasti hõredatest failidest vaid mõne sekundiga — kuid ärge unustage seejärel kustutada kogu kasti ja selle komponente.

Oletame, et soovite seadistada serveri kaheksa ketta peale ja plaanite kasutada 10 TB (~9300 GiB) kettaid — kuid te ei ole kindel, milline topoloogia vastab teie vajadustele kõige paremini. Ülaltoodud näites loome testkasti hõredatest failidest mõne sekundiga — ja nüüd teame, et kaheksa 10 TB kettaga RAIDz2 vdev tagab 50 TiB kasulikku mahtu.

Teine eriline seadme klasse on SPARE (varu). Soojavarustusseadmed, erinevalt tavapärastest seadmetest, kuuluvad kogu kasti, mitte ühele virtuaalsele seadmele. Kui mõni vdev kastis ebaõnnestub ja varuseade on kasti ühendatud ja saadaval, liitub see automaatselt kahjustatud vdev'iga.

Pärast kahjustatud vdev'iga ühendamist hakkab varuseade saama koopiaid või andmete rekonstrueerimist, mis peaksid puuduvatel seadmetel olema. Traditsioonilises RAID-is nimetatakse seda taastamiseks (rebuilding) ja ZFS-is on see "ülemineku taastamine" (resilvering).

Oluline on märkida, et varuseadmed ei asenda püsivalt rikutud seadmeid. Need on vaid ajutised asendajad, et vähendada aega, mille jooksul vdev degradeerub. Pärast seda, kui administraator on asendanud riknenud seadme vdev'is, toimub taastamine uuele seadmele ja varu seade eraldatakse vdev'ist ning naaseb varuseadmest tööle kogu kasti jaoks.

Andmekogud, plokid ja sektorid

Järgmised alusloomaelemendid, mida meie ZFS-i teekonnal mõista, ei seondu nii palju riistvaraga, kui selle kohapealse andmete korralduse ja salvestamisega. Üksikute tasemete loomine, nagu metaslab, jäi meil selgelt mõistmise huvides vahele.

Andmekogud (dataset)

Kui me esmakordselt loome andmekogu, kuvab see kogu saadaoleva kasti ruumi. Seejärel seadistame kvoodi — ja muudame mount-punkti. Imeline!

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

ZFS andmegrupp on enam-vähem sarnane tavalise monteeritud failisüsteemiga. Nagu tavaline failisüsteem, näeb see esmapilgul välja nagu "üks tavaline kaust". Kuid nagu tavalistel monteeritud failisüsteemidel, on igal ZFS andmegrupil oma põhivarade kogum.

Esiteks võib andmegrupile määrata kvoodi. Kui seadistate zfs set quota=100G poolname/datasetname, siis ei saa te kirjutada monteeritud kausta /poolname/datasetname rohkem kui 100 GiB.

Kas märkate, et iga rea alguses on olemas ja puudub kaldkriips? Igal andmegrupil on oma koht nii ZFS hierarhias kui ka süsteemi monteerimise hierarhias. ZFS hierarhias ei ole esimest kaldkriipsu — alustate ankrust ning seejärel teeülesande andmegrupi juurde. Näiteks, pool/vanem/laps andmegrupi kohta nimega laps vanema andmegrupi all vanem loovalt nimetatud ankrus pool.

Vaikimisi on andmegrupi monteerimispunkt ZFS hierarhias tema nimega ekvivalentne, alustades kaldkriipsust — ankur nimega pool monteeritakse kui /pool, andmegrupp vanem monteeritakse /pool/parent, ja alamandmegrupp laps monteeritakse /pool/parent/child. Siiski on võimalik muuta andmegrupi süsteemi monteerimispunkti.

Kui me määrame zfs set mountpoint=/lol pool/vanem/laps, siis andmegrupp pool/vanem/laps monteeritakse süsteemi kui /lol.

Lisaks andmegruppidele peame mainima ka mahtusid (zvols). Mahu struktuur on sarnane andmegrupile, välja arvatud see, et seal ei ole tegelikult failisüsteemi — see on lihtsalt plokiseade. Näiteks saate luua zvol nimega mypool/myzvol, seejärel vormindada selle ext4 failisüsteemiga ja siis monteerida see failisüsteem — nüüd on teil ext4 failisüsteem, kuid kõigi ZFS turvafunktsioonide toetusega! See võib tunduda mõttetu ühel arvutil, kuid omab palju rohkem tähendust iSCSI seadme eksportimise taustana.

Jaotusseadmed

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

Me tõesti, tõeliselt ei naljasta tohutu jõudluse kaotuse üle, kui seada ashift liiga madalaks.

ZFS-i baselines salvestatakse kõik andmed, sealhulgas metaandmed plokkidesse. Iga andmestiku maksimaalne ploki suurus määratakse omaduses recordsize (salvestusväli). Salvestusvälja saab muuta, kuid see ei muuda ega asenda ühtegi plokki, mis on juba andmestikku kirjutatud - see kehtib ainult uute plokkide puhul nende kirjutamise ajal.

Kui pole määratud muud, on praegune salvestusväli vaikesuurus 128 KiB. See on omamoodi keeruline kompromiss, kus jõudlus ei ole ideaalne, kuid pole ka kohutav enamikes olukordades. Salvestusväli saab seadistada väärtuseks vahemikus 4K kuni 1M (lisaseadetega recordsize saab seadistada ka suuremaks, kuid see on harva hea mõte).

Iga plokk viitab ainult ühe faili andmetele - sa ei saa kahe erineva faili andmeid ühte plokki suruda. Iga fail koosneb ühest või mitmest plokist, sõltuvalt suurusest. Kui faili suurus on väiksem kui salvestusväli, salvestatakse see väiksemas plokis - näiteks 2 KiB faili plokk hõivab ainult ühe 4 KiB sektori kettal.

Kui fail on piisavalt suur ja vajab mitmeid plokke, on kõik salvestused, mis sisaldavad seda faili, suurusega recordsize - sealhulgas viimane salvestus, mille peamine osa võib olla kasutamata ruum.

Zvoli mahutitel ei ole omadust recordsize - selle asemel on neil ekvivalentne omadus volblocksize.

Sektorid

Viimane ja kõige põhjalikum ehitusplokk on sektor. See on väikseim füüsiline üksus, mida saab aluseks olevast seadmega kirjutada või lugeda. Aastakümneid on enamus ketastest kasutanud 512-baidiseid sektoreid. Viimasel ajal on enamus ketastest seadistatud 4 KiB sektoriteks, ja mõnedes - eriti SSD-de puhul - 8 KiB sektoriteks või isegi rohkem.

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

ZFS küsib operatsioonisüsteemilt iga plokiseadmest üksikasjalikku teavet, kui see lisatakse uude vdev'i, ja teoreetiliselt seadistab ashifti automaatselt selle teabe põhjal. Kahjuks valetavad paljud kettad oma sektori suuruse kohta, et säilitada ühilduvus Windows XP-ga (millel oli probleeme teiste sektori suurustega kettaste mõistmisega).

See tähendab, et ZFS-i administraator peab teadma oma seadmete tegelikku sektori suurust ja seadistama selle käsitsi. ashift. Kui ashift on seadistatud liiga väikseks, suureneb lugemis-/kirjutamisoperatsioonide arv erakordsetes ulatustes. Nii tuleb 512-baidiseid "sektoore" kirjutada reaalsetesse 4 KiB-sektoritesse, mis tähendab, et esmalt tuleb kirjutada esimene "sektor", siis lugeda 4 KiB sektor, muuta see teise 512-baidise "sektoriga", kirjutada see tagasi uude 4 KiB-sektorisse ja nii edasi iga kirje puhul.

Tegelikus maailmas on selline trahv tuntav Samsung EVO tahkete ketaste puhul, mille jaoks peaks olema kehtiv ashift=13, kuid need SSD-d valetavad oma sektori suuruse kohta, seega on see seadistatud ashift=9. Kui kogenud süsteemiadministraator seda parameetrit ei muuda, siis töötab see SSD aeglase tavalise magnet HDD-ga.

Võrdluseks, liiga suure suuruse korral ashift pole praktiliselt mingit trahvi. Tegelikku jõudluse vähenemist ei ole ning kasutamata ruumi suurenemine on äärmiselt väike (või null, kui tihendamine on sisse lülitatud). Seetõttu soovitame tungivalt isegi neile kettastele, mis tegelikult kasutavad 512-baidiseid sektoore, seadistada ashift=12 või isegi ashift=13, et kindlalt tulevikku vaadata.

Omadus ashift seadetakse iga virtuaalse seadme vdev jaoks, mitte pooli, nagu paljud ekslikult arvavad - ja pärast seadistamist ei muutu. Kui sa kogemata seaded ümber ajasid ashift uue vdev'i lisamisel paiku, siis olete selle mahu madala jõudlusega seadmega pöördumatult saastanud ja tavaliselt pole muud lahendust, kui purustada maht ja alustada kõik otsast. Isegi vdev'i eemaldamine ei päästa vale seadistuse eest. ashift!

Kopeerimise mehhanism kirjutamisel

Kui tavaline failisüsteem peab andmeid uuesti kirjutama, muudab ta iga ploki seal, kus see asub.

Failisüsteem, kus toimub kirjutamise käigus kopeerimine, salvestab uue ploki versiooni ja seejärel vabastab vana versiooni.

Üldiselt, kui ignoreerida plokkide reaalsest füüsilisest asukohast, lihtsustub meie "andmete komeet" "andmeussiks", mis liigub vasakult paremale saadaval oleva ruumi kaartidel.

Nüüd saame hästi aru, kuidas kirjutamise käigus kopeerimise snäppshotid töötavad — iga plokk võib kuuluda mitmele snäppshotile ja jääb alles seni, kuni kõik seotud snäppshotid on hävitatud.

Kirjutamise käigus kopeerimise mehhanism (Copy on Write, CoW) on ZFS-i unikaalse süsteemi aluseks. Põhikontseptsioon on lihtne — kui palute traditsiooniliselt failisüsteemil faili muuta, teeb ta nõutud. Kui aga palute kirjutamise käigus kopeerimise failisüsteemil sama teha, ütleb ta "okei" — kuid petab teid.

Selle asemel kirjutab kirjutamise käigus kopeerimise failisüsteem uue versiooni muudetud plokist ja seejärel uuendab faili metaandmeid, et katkestada side vana plokiga ja siduda sellega uus plokk, mille just salvestasite.

Vana ploki eraldamine ja uue sidumine toimub ühes operatsioonis, seega ei saa seda katkestada — kui lülitate pärast selle toimumist välja, on teil uus faili versioon, kuid kui lülitate varem välja, on teil vana versioon. Igatahes ei teki failisüsteemi konfliktide.

Kirjutamise käigus kopeerimine ZFS-is toimub mitte ainult failisüsteemi tasandil, vaid ka ketaste halduse tasemel. See tähendab, et ZFS ei ole vastuvõtlik kirjutamise tühikule (RAID augule) — nähtusele, kus riba on salvestatud ainult osaliselt enne süsteemi tõrget, mis kahjustab massiivi pärast taaskäivitamist. Siin kirjutatakse riba aatomaarseks, vdev on alati järjepidev, ja Bob on su onu..

ZIL: ZFS-i kavatsuste žurnal.

ZFS süsteem käsitleb sünkroonseid kirjeid eriliselt — see salvestab need ajutiselt, kuid koheselt ZIL-i, enne kui salvestab need hiljem püsivalt koos asünkroonsete kirjetega.

Tavaliselt ei loeta ZIL-i salvestatud andmeid enam kunagi. Kuid pärast süsteemi tõrget on see võimalik.

SLOG, või sekundaarne LOG-seade, on lihtsalt eriline - ja eelistatavalt väga kiire - vdev, kus ZIL võib olla eraldi peamisest salvestusruumist.

Pärast viga taastatakse kõik määrdunud andmed ZIL-is - antud juhul asub ZIL SLOG-is, seega taastatakse need just sealt.

On olemas kaks peamist kirjutamistoimingu kategooriat - sünkroonsed (sync) ja asünkroonsed (async). Enamikus töökoormustes on absoluutne enamik kirjutamistoimingutest asünkroonsed - failisüsteem võimaldab neid koondada ja edastada partiitena, vähendades fragmenteerimist ja suurendades oluliselt läbilaskevõimet.

Sünkroonsed kirjutamised on täiesti teistsugune asi. Kui rakendus küsib sünkroonset kirjutamist, ütleb see failisüsteemile: "Sa pead selle salvestama energiat mittekaotavasse mällu, right now, ja kuni selle ajani ei saa ma midagi muud teha." Seega peavad sünkroonsed kirjutamised olema kohe ketta peale salvestatud - ja kui see suurendab fragmenteerimist või vähendab läbilaskevõimet, siis olgu nii.

ZFS käsitleb sünkroonseid kirjutamisi teistmoodi kui tavalised failisüsteemid - selle asemel, et kohe neid tavalisse salvestusse laadida, salvestab ZFS need spetsiaalsesse salvestusala, mida nimetatakse ZFS-i kavatsuste logiks - ZFS Intent Log, või ZIL. Kiirus on selles, et need kirjutised samuti jäävad mällu, kui need on koondatud koos tavaliste asünkroonsete kirjutamisvõimetega, et hiljem neid salvestada nagu täiesti normaalsed TXG (tehingugrupid, Transaction Groups).

Normaalses töös on ZIL salvestatud ja ei loeta enam kunagi. Kui mõne hetke pärast ZIL-i kirjutised salvestatakse põhiseadmesse tavalisetes TXG-des mälust, eraldatakse need ZIL-ist. Ainus hetk, mil midagi ZIL-ist loetakse, on siis, kui importitakse aed.

Kui ZFS-l on tõrge - operatsioonisüsteemi tõrge või toite lõppemine - kui ZIL-is on andmeid, loetakse need andmed järgmise aeda importimise ajal (näiteks avariiseadmest taaskäivitamisel). Kõik, mis on ZIL-is, loetakse, koondatakse TXG-deks, salvestatakse põhiseadmesse ja seejärel eraldatakse ZIL-ist importimise käigus.

Üks vdev abiklassidest on LOG või SLOG, sekundaarne LOG seade. Selle ainus ülesanne on tagada basseinile eraldi ja eelistatult palju kiirema, väga kõrge kirjutamisvastupidavusega vdev seade ZIL-i salvestamiseks, selle asemel, et salvestada ZIL põhivdev-i peamisse salvestusse. Isegi ZIL käitub sõltumata salvestus kohast ühtemoodi, kuid kui LOG-iga vdev-l on väga kõrge kirjutamiskiirus, siis sünkroonsed kirjutamised toimuvad kiiremini.

LOG-iga vdev lisamine basseini ei paranda ei suuda asünkroonsete kirjutamiste jõudlust - isegi kui sunnid kõiki kirjutamisi ZIL-i kaudu zfs set sync=always, need on ikkagi seotud põhiseadmest TXG-ga samamoodi ja samas tempos nagu ilma päevikuta. Ainus otsene jõudluse parendamine on sünkroonsest kirjutamisest tulenev viivitus (kuna päeviku suurem kiirus kiirendab operatsioonide täitmist. sync).

Kuid keskkonnas, mis juba nõuab suurt hulka sünkroonseid kirjutamisi, võib vdev LOG kaudselt kiirendada asünkroonset kirjutamist ja vahemäluta lugemist. ZIL-i kirjutiste laadimine eraldi vdev LOG-i tähendab vähem konkurentsi IOPS-i nimel põhiseadmes, mis omakorda suurendab kõikide lugemise ja kirjutamise operatsioonide jõudlust.

Snapshoot'id

Kirjutamise ajal kopeerimise mehhanism on samuti vajalik alus ZFS-i aatomiliste hetkeseisude ja inkrementaalse asünkroonse replikatsiooni jaoks. Aktiivses failisüsteemis on punktiiride puu, mis märgib kõik kirjutised praeguste andmete osas - kui teete hetktõmmise, teete lihtsalt koopia sellest punktiiride puust.

Kui aktiivses failisüsteemis kirjutatakse mingi kirjutis üle, salvestab ZFS esmalt uue versiooni plokist kasutamata ruumi. Seejärel eemaldab vana ploki versiooni praegusest failisüsteemist. Kuid kui mõni hetktõmmis viitab vanale plokile, jääb see siiski muutumatuks. Vana plokk ei taastata tegelikult vabaks ruumiks, kuni kõik sellele plokile viitavad hetktõmmised ei hävitata!

Replikatsioon

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

Samas võrgu sees Windows 7 virtuaalmasina 40-gigabaidise pildifaili replikatsioon on täiesti teine lugu. ZFS replikatsioon toimub 289 korda kiiremini kui rsync, või "ainult" 161 korda kiiremini, kui teate, kuidas rsync'i käivitada koos võtmega --inplace.

Kui virtuaalmasina pilt ulatub, siis probleemid rsync'iga ulatuvad koos sellega. 1,9 TiB suurus ei ole tänapäeva virtuaalmasina pildi jaoks nii suur – ent see on piisavalt suur, et ZFS replikatsioon osutuks 1148 korda kiiremini kui rsync, isegi kui kasutada rsync'i argumenti --inplace.

Kuna te mõistate, kuidas töödeldakse snapshots'e, pole raske tabada replikatsiooni olemust. Kuna snapshot on lihtsalt viidete puu märgete, tähendab see, et kui me teeme zfs send snapshot'i, edastame me nii selle puu, kui kõik seotud märkmed. Kui me edastame selle zfs send ja zfs receive sihtkohta, salvestab see nii tegeliku ploki sisu kui ka viidete puu, mis viitab plokkidele, sihtkohta andmete kogusse.

Asjad muutuvad veelgi huvitavamaks teisel zfs send. Nüüd on meil kaks süsteemi, millest igal on poolname/datasetname@1, ja võtate uue snapshot'i poolname/datasetname@2. Seega on teie algses puulis datasetname@1 ja datasetname@2, ja sihtpuulis on praegu alles esimene snapshot. datasetname@1.

Kuna allika ja sihtkoha vahel on meil ühine snapshot datasetname@1, saame teha inkrementaalse zfs send selle peal. Kui me räägime süsteemile zfs send -i poolname/datasetname@1 poolname/datasetname@2, siis võrdleb see kahte viidete puud. Kõik viidatud, mis eksisteerivad ainult @2, viitavad ilmselgelt uutele plokkidele - seega vajame nende plokkide sisu.

Kaug-süsteemis on inkrementaalne töötlemine sama lihtne. Esmalt salvestame kõik uued märkmed, mis on voolus, ja seejärel lisame viidatud need plokkidele. Voilà, meil on send uues süsteemis! sendAsünkroonne inkrementaalne ZFS replikatsioon on tohutu parandamine võrreldes varasemate mitte-snapshot meetoditega, nagu rsync. Mõlemal juhul edastatakse ainult muudetud andmed - kuid rsync peab esmalt @2 kõik andmed mõlemalt poolt kettalt lugema, et kontrollida summeerimist ja võrrelda seda. Selle vastu, ZFS replikatsioon ei loe midagi, välja arvatud viidete puud - ja kõik plokid, mis ei ole esindatud ühises snapshot'is.

Asünkroonne inkrementaalne replikatsioon ZFS on tohutu täiustus varasemate, snapshot'e mitte kasutavate meetodite, näiteks rsync, suhtes. Mõlemal juhul edastatakse ainult muutunud andmed - kuid rsync peab esmalt lugeda kõik andmed kettalt mõlemal poolel lugema, et kontrollida summat ja võrrelda seda. Erinevalt sellest ei loe ZFS replikatsioon midagi muud kui viidete puid - ja kõik plokid, mis ei ole esindatud ühises snapshot'is.

Sisseehitus

Kirjutamise kopeerimismehanism lihtsustab samuti sisseehitatud kompressioonisüsteemi. Traditsioonilises failisüsteemis on kompressioon probleemne — nii vana kui ka uus muudetud versioon andmetest asuvad samas ruumis.

Kui me vaatame andmefragmenti faili keskosas, mis alustab oma elu megabaidiga nullidest 0x00000000 ja edasi — on seda väga lihtne kokku suruda ühe sekundi suurusesse. Kuid mis juhtub, kui asendame selle megabaidi nullidega megabaidi mittekompressitavate andmetega, näiteks JPEG või pseudo-juhusliku müra? Ühtäkki vajab see megabaidi andmete jaoks mitte ühte, vaid 256 sektori suurust 4 KiB, ja sellel kohal on kettal reserveeritud vaid üks sektor.

ZFS-l pole sellist probleemi, kuna muudetud kirjad kirjutatakse alati kasutamata ruumi — algne plokk hõivab vaid ühe 4 KiB sektori, kuid uus kirje võtab 256, kuid see pole probleem — hiljuti muudetud fragment "faili keskelt" kirjutataks kasutamata ruumi, sõltumata sellest, kas selle suurus muutus või mitte, seega on ZFS jaoks see täiesti tavapärane olukord.

ZFS sisseehitatud kompressioon on vaikimisi keelatud ja süsteem pakub ühendatavaid algoritme — praegu on nende hulgas LZ4, gzip (1-9), LZJB ja ZLE.

• LZ4 — see on vooluhulga algoritm, mis pakub äärmiselt kiiret kompressiooni ja dekompressiooni ning jõudluse kasvu enamikus kasutusjuhtudes — isegi üsna aeglastel CPU-del.
• GZIP — austatud algoritm, mida tunnevad ja armastavad kõik Unix-süsteemide kasutajad. Seda saab kasutada kompressioonitasemete 1-9 juures, kompressioonitaseme suurenemise ja CPU kasutamise kasvu tõttu, kui lähenduda tasemele 9. Algoritm sobib hästi kõikide tekstiliste (või muude äärmiselt kompressitavate) kasutusjuhtude jaoks, kuid vastasel korral tekitab see sageli probleeme CPU-ga — kasutage seda ettevaatlikult, eriti kõrgematel tasemetel.
• LZJB — originaalalgoritm ZFS-is. See on vananenud ja ei tohiks enam kasutada, LZ4 ületab selle igas mõõtmes.
• ZLE — null-taseme kodeerimine, Zero Level Encoding. See ei muuda normaalseid andmeid, vaid pigem tihendab suurte nullide järjestusi. See on kasulik täiesti tihendamatute andmestike jaoks (nt JPEG, MP4 või muude juba tihendatud formaatide jaoks), kuna see ignoreerib tihendamatu sisu, kuid tihendab kasutamata ruumi lõplikest kirjetest.

Soovitatav on LZ4 tihendamine praktiliselt kõigi kasutusjuhtumite puhul; jõudluse kokkupuude tihendamatute andmetega on väga väike ja kasv tüüpiliste andmete jaoks on see märkimisväärne. Virtuaalse masina pildi kopeerimine uue Windowsi operatsioonisüsteemi installeerimise jaoks (värskelt installitud OS, andmeid sees ei ole) compression=lz4 oli 27% kiirem kui compression=none, in selles 2015. aasta testis..

ARC - adaptiivne asenduskate

ZFS on ainus kaasaegne failisüsteem, millest me teame, mis kasutab oma lugemiskäitlemise mehhanismi, mitte ei tugi operatsioonisüsteemi lehtede vahemikule, et hoida hiljuti loetud blokke RAM-is.

Kuigi sellel omal vahemälu ei ole oma probleemid - ZFS ei saa reageerida uusi mälu eraldamise päringuid nii kiiresti kui kernel, seega uus mälu eraldamise kutse võib ebaõnnestuda, kui see vajab RAM-i, mille ARC praegu kasutab. Kuid on kaalukaid põhjuseid kasutada oma vahemälu, vähemalt praegu. malloc() Kõik tuntud kaasaegsed operatsioonisüsteemid, sealhulgas MacOS, Windows, Linux ja BSD, kasutavad lehtede vahemälu rakendamiseks LRU (Mitte Hiljuti Kasutatud) algoritmi. See on primitiivne algoritm, mis tõstab vahemällu talletatud bloki "järjekorra tippu" pärast igat lugemist ja eemaldab bloki "järjekorrast alla", et vajadusel lisada uusi vahemälu puuduolekuid (bloke, mis oleks pidanud lugema kettalt, mitte vahemälust) tippu.

Tavaliselt töötab algoritm hästi, kuid suurte tööandmete kogumitega süsteemides viib LRU kergesti trashingu - sageli vajalike blokide eemaldamiseni, et vabastada ruumi blokeeringutele, mis ei loeta kunagi enam vahemälust.

ARC

ARC — oluliselt vähem naivne algoritm, mida võib käsitleda kui "kaalutud" vahemälu. Iga kord, kui vahemälust loetakse plokk, muutub see veidi "raskemaks" ja on keerulisem kõrvaldada — ning isegi pärast eemaldamist plokk jälgitakse teatud aja jooksul. Plokk, mis on kõrvaldatud, kuid peab seejärel taas loetakse vahemälusse, muutub samuti "raskemaks".

Kõikide nende tegevuste lõpptulemus on vahemälu, millel on palju suurem kätte saamise koefitsient (hit ratio) — suhe vahemälus toimuva lugemise (vahemälust lugemine) ja puude (lugemine kettalt) vahel. See on äärmiselt oluline statistika — mitte ainult see, et vahemälu hitid teenindatakse kordades kiiremini, vaid ka vahemälu puudud saavad samuti kiiremini teenindatud, kuna mida rohkem on vahemälu hiti, seda vähem on paralleelseid päringuid kettale ja seda vähem on viivitusi nende jääkpuudude teenindamisel, mis peavad olema teenindatud kettalt.

Kokkuvõte

Pärast ZFS põhisemantika uurimist — kuidas toimib kirjutamisprotsess ning suhete uurimist salvestusreservide, virtuaalsete seadmete, plokkide, sektorite ja failide vahel — oleme valmis arutama tegelikku jõudlust koos tegelike numbritega.

Järgmisel osal vaatame võrreldavat tegelikku jõudlust peegeldava vdev ja RAIDz vahel, samuti traditsiooniliste Linuxi tuuma RAID-topoloogiate vahel, mida oleme uurinud. artiklis.

Alguses soovisime vaadelda ainult põhiteemasid — ZFS topoloogiaid endid — kuid pärast nii oleme valmis rääkima keerukamatest seadistustest ja ZFS häälestusest, sealhulgas abistavate vdev tüüpide, nagu L2ARC, SLOG ja Special Allocation, kasutamisest.

Allikas: habr.com