Këtë pranverë kemi diskutuar tashmë disa tema hyrëse, p.sh. и . Në të dytën prej tyre, ne madje premtuam të vazhdojmë të studiojmë performancën e topologjive të ndryshme me shumë disqe në ZFS. Ky është sistemi i skedarëve të gjeneratës së ardhshme që tani po vendoset kudo nga tek .
Epo, sot është dita më e mirë për t'u njohur me ZFS, lexues kureshtarë. Vetëm dijeni se në vlerësimin modest të zhvilluesit të OpenZFS Matt Ahrens, "është vërtet e vështirë".
Por, përpara se të arrijmë te numrat - dhe do të ketë, premtoj - për të gjitha opsionet e konfigurimit të ZFS me tetë disqe, duhet të flasim për si Në përgjithësi, ZFS ruan të dhënat në disk.
Zpool, vdev dhe pajisja
Ky diagram i plotë i grupit përfshin tre vdevs ndihmëse, një nga çdo klasë dhe katër për RAIDz2
Zakonisht nuk ka asnjë arsye për të krijuar një grup llojesh dhe madhësish të papërputhshme vdev - por nëse dëshironi, nuk ka asgjë që ju ndalon ta bëni këtë
Për të kuptuar me të vërtetë sistemin e skedarëve ZFS, duhet të shikoni nga afër strukturën e tij aktuale. Së pari, ZFS unifikon shtresat tradicionale të menaxhimit të vëllimit dhe sistemit të skedarëve. Së dyti, ai përdor një mekanizëm transaksional kopje-në-shkrim. Këto veçori nënkuptojnë se sistemi është strukturor shumë i ndryshëm nga sistemet konvencionale të skedarëve dhe grupet RAID. Grupi i parë i blloqeve bazë të ndërtimit për të kuptuar janë grupi i ruajtjes (zpool), pajisja virtuale (vdev) dhe pajisja reale (pajisja).
zpool
Pishina e ruajtjes së zpool është struktura më e lartë e ZFS. Çdo pishinë përmban një ose më shumë pajisje virtuale. Nga ana tjetër, secila prej tyre përmban një ose më shumë pajisje (pajisje) reale. Pishinat virtuale janë njësi të pavarura. Një kompjuter fizik mund të përmbajë dy ose më shumë grupe të veçanta, por secili është plotësisht i pavarur nga të tjerët. Pools nuk mund të ndajnë pajisjet virtuale.
Teprica e ZFS është në nivelin e pajisjes virtuale, jo në nivelin e grupit. Nuk ka absolutisht asnjë tepricë në nivelin e pishinës - nëse një vdev ose vdev i dedikuar humbet, i gjithë grupi humbet bashkë me të.
Pishinat moderne të ruajtjes mund t'i mbijetojnë humbjes së cache-it ose regjistrit të një pajisjeje virtuale - megjithëse ato mund të humbasin një sasi të vogël të dhënash të pista nëse humbasin regjistrin e vdev gjatë një ndërprerjeje të energjisë ose ndërprerjes së sistemit.
Ekziston një keqkuptim i zakonshëm që "shiritat e të dhënave" të ZFS shkruhen në të gjithë grupin. Kjo nuk eshte e vertete. Zpool nuk është një RAID0 qesharak, është më shumë një qesharak me një mekanizëm kompleks të shpërndarjes së ndryshueshme.
Në pjesën më të madhe, të dhënat shpërndahen midis pajisjeve virtuale të disponueshme sipas hapësirës së lirë në dispozicion, kështu që në teori ato do të plotësohen të gjitha në të njëjtën kohë. Versionet më të fundit të ZFS marrin parasysh përdorimin (përdorimin) aktual të vdev - nëse një pajisje virtuale është dukshëm më e ngarkuar se një tjetër (për shembull, për shkak të ngarkesës së leximit), ajo do të anashkalohet përkohësisht për shkrime, pavarësisht se ka raportin më të lartë të hapësirës së lirë.
Mekanizmi i zbulimit të riciklimit i ndërtuar në metodat moderne të shpërndarjes së shkrimit ZFS mund të zvogëlojë vonesën dhe të rrisë xhiron gjatë periudhave me ngarkesë jashtëzakonisht të lartë—por nuk e bën. carte blanche për përzierjen e pavullnetshme të HDD-ve të ngadalta dhe SSD-ve të shpejta në një grup. Një pishinë e tillë e pabarabartë do të vazhdojë të funksionojë me shpejtësinë e pajisjes më të ngadaltë, domethënë, sikur të ishte tërësisht e përbërë nga pajisje të tilla.
vdev
Çdo grup ruajtjeje përbëhet nga një ose më shumë pajisje virtuale (vdev). Nga ana tjetër, çdo vdev përfshin një ose më shumë pajisje reale. Shumica e pajisjeve virtuale përdoren për ruajtjen e thjeshtë të të dhënave, por ka disa klasa ndihmëse të vdev, duke përfshirë CACHE, LOG dhe SPECIAL. Secili prej këtyre llojeve vdev mund të ketë një nga pesë topologjitë: me një pajisje, RAIDz1, RAIDz2, RAIDz3 ose pasqyrë.
RAIDz1, RAIDz2 dhe RAIDz3 janë varietete të veçanta të asaj që njerëzit e vjetër do ta quanin RAID me barazi të dyfishtë (diagonale). 1, 2 dhe 3 i referohen numrit të blloqeve të barazisë për secilën korsi të dhënash. Në vend që të kenë disqe të veçantë për të siguruar barazi, pajisjet virtuale RAIDz shpërndajnë paritetin gjysmë të barabartë nëpër disqe. Një grup RAIDz mund të humbasë aq disqe sa ka blloqe pariteti; nëse humbet një tjetër, do të dështojë dhe do të marrë me vete pishinën e ruajtjes.
Në pajisjet virtuale të pasqyrës (mirror vdev), çdo bllok ruhet në secilën pajisje në vdev. Megjithëse pasqyrat me dy gjerësi janë më të zakonshmet, një pasqyrë mund të ketë çdo numër arbitrar pajisjesh - në instalime më të mëdha, shpesh përdoren treshe për të përmirësuar performancën e leximit dhe tolerancën e gabimeve. Një pasqyrë vdev mund t'i mbijetojë çdo dështimi për sa kohë të paktën një pajisje në vdev mbetet funksionale.
Vdev-të e vetme janë në thelb të rrezikshme. Një pajisje e tillë virtuale nuk do t'i mbijetojë një dështimi të vetëm - dhe nëse përdoret si ruajtje ose një vdev special, atëherë dështimi i tij do të çojë në shkatërrimin e të gjithë pishinës. Jini shumë, shumë të kujdesshëm këtu.
Pajisjet virtuale CACHE, LOG dhe SPECIAL mund të krijohen në cilëndo nga topologjitë e mësipërme - por mbani mend se humbja e një pajisjeje virtuale SPECIAL do të thotë humbje e grupit, kështu që rekomandohet shumë një topologji e tepërt.
pajisje
Ky është ndoshta termi më i lehtë për t'u kuptuar në ZFS - është fjalë për fjalë një pajisje bllokimi me akses të rastësishëm. Mos harroni se pajisjet virtuale përbëhen nga pajisje individuale dhe një grup përbëhet nga pajisje virtuale.
Disqet, qoftë magnetike ose të ngurta, janë pajisjet më të zakonshme të bllokut që përdoren si blloqe ndërtimi të vdev. Sidoqoftë, çdo pajisje me një përshkrues në /dev do ta bëjë këtë - kështu që të gjithë grupet RAID të harduerit mund të përdoren si pajisje individuale.
Një skedar i thjeshtë i papërpunuar është një nga pajisjet më të rëndësishme të bllokut alternativ nga i cili mund të ndërtohet një vdev. Pishina testuese nga është një mënyrë shumë e përshtatshme për të kontrolluar komandat e grupit dhe për të parë sa hapësirë është e disponueshme në një pishinë ose pajisje virtuale të një topologjie të caktuar.
Ju mund të krijoni një grup testimi nga skedarë të rrallë në vetëm disa sekonda - por mos harroni të fshini të gjithë grupin dhe përbërësit e tij më pas
Le të themi se dëshironi një server me tetë disqe dhe planifikoni të përdorni disqe 10TB (~9300 GiB), por nuk jeni të sigurt se cila topologji i përshtatet më mirë nevojave tuaja. Në shembullin e mësipërm, ne ndërtojmë një grup provë me skedarë të rrallë në sekonda - dhe tani e dimë se një RAIDz2 vdev prej tetë disqe 10 TB ofron 50 TiB kapacitet të përdorshëm.
Një klasë tjetër e veçantë e pajisjeve është SPARE. Pajisjet me shkëmbim të nxehtë, ndryshe nga pajisjet e zakonshme, i përkasin të gjithë grupit dhe jo një pajisjeje të vetme virtuale. Nëse ndonjë vdev në pishinë dështon dhe një pajisje rezervë është e lidhur me pishinën dhe e disponueshme, atëherë ajo do të bashkohet automatikisht me vdevin e prekur.
Pasi të lidhet me vdev-në e prekur, pajisja zëvendësuese fillon të marrë kopje ose rindërtim të të dhënave që duhet të jenë në pajisjen që mungon. Në RAID tradicionale kjo quhet "rindërtim", dhe në ZFS është "resilvering".
Është e rëndësishme të theksohet se pajisjet zëvendësuese nuk zëvendësojnë përgjithmonë pajisjet e dështuara. Ky është vetëm një zëvendësim i përkohshëm për të reduktuar kohën që duhet që vdev të degradojë. Pasi administratori zëvendëson pajisjen e dështuar vdev, teprica rikthehet në atë pajisje të përhershme dhe SPARE shkëputet nga vdev dhe kthehet në rezervë për të gjithë grupin.
Grupet e të dhënave, blloqet dhe sektorët
Grupi tjetër i blloqeve të ndërtimit për t'u kuptuar në udhëtimin tonë ZFS lidhet më pak me harduerin dhe më shumë me mënyrën se si organizohen dhe ruhen vetë të dhënat. Ne po anashkalojmë disa shtresa këtu - të tilla si metaslab - për të shmangur rrëmujën e detajeve duke ruajtur një kuptim të strukturës së përgjithshme.
Grupi i të dhënave
Kur krijojmë për herë të parë një grup të dhënash, ai tregon të gjithë hapësirën e disponueshme të pishinës. Pastaj vendosim kuotën - dhe ndryshojmë pikën e montimit. Magjike!
Zvol është kryesisht vetëm një grup të dhënash i zhveshur nga shtresa e tij e sistemit të skedarëve, të cilin ne e zëvendësojmë këtu me një sistem skedarësh krejtësisht normal ext4
Grupi i të dhënave ZFS është afërsisht i njëjtë me një sistem skedarësh të montuar standard. Ashtu si një sistem i rregullt skedarësh, në shikim të parë duket se është "vetëm një dosje tjetër". Por ashtu si sistemet e skedarëve të montuar të rregullt, çdo grup i të dhënave ZFS ka grupin e vet të vetive themelore.
Para së gjithash, një grup të dhënash mund të ketë një kuotë të caktuar. Nëse instaloni zfs set quota=100G poolname/datasetname, atëherë nuk do të mund të shkruani në dosjen e montuar /poolname/datasetname më shumë se 100 GiB.
Vini re praninë dhe mungesën e prerjeve në fillim të çdo rreshti? Çdo grup i të dhënave ka vendin e vet si në hierarkinë ZFS ashtu edhe në hierarkinë e montimit të sistemit. Nuk ka asnjë prerje kryesore në hierarkinë ZFS - ju filloni me emrin e grupit dhe më pas shtegun nga një grup i të dhënave në tjetrin. Për shembull, pool/parent/child për një grup të dhënash të emërtuar child nën grupin e të dhënave mëmë parent në një pishinë me një emër krijues pool.
Si parazgjedhje, pika e montimit të një grupi të dhënash do të jetë ekuivalente me emrin e saj në hierarkinë ZFS, me një prerje kryesore - grupi i quajtur pool montuar si /pool, grup i të dhënave parent montuar në /pool/parent, dhe grupin e të dhënave të fëmijës child montuar në /pool/parent/child. Megjithatë, pika e montimit të sistemit të grupit të të dhënave mund të ndryshohet.
Nëse tregojmë zfs set mountpoint=/lol pool/parent/child, pastaj grupi i të dhënave pool/parent/child montuar në sistem si /lol.
Përveç grupeve të të dhënave, duhet të përmendim vëllimet (zvols). Një vëllim është përafërsisht i njëjtë me një grup të dhënash, përveç se në fakt nuk ka një sistem skedarësh - është thjesht një pajisje bllokimi. Për shembull, mund të krijoni zvol Me emër mypool/myzvol, pastaj formatoni atë me një sistem skedarësh ext4 dhe më pas montoni atë sistem skedarësh - tani keni një sistem skedarësh ext4, por me të gjitha veçoritë e sigurisë të ZFS! Kjo mund të duket budallallëk në një kompjuter, por ka shumë më tepër kuptim si një sfond kur eksportoni një pajisje iSCSI.
blloqe
Një skedar përfaqësohet nga një ose më shumë blloqe. Çdo bllok ruhet në një pajisje virtuale. Madhësia e bllokut zakonisht është e barabartë me parametrin madhësia e regjistrimit, por mund të reduktohet në 2^ashift, nëse përmban meta të dhëna ose një skedar të vogël.
Ne me të vërtetë vërtet Nuk po bëjmë shaka për dënimin e madh të performancës nëse vendosni zhvendosjen shumë të ulët
Në një grup ZFS, të gjitha të dhënat, duke përfshirë metadatat, ruhen në blloqe. Madhësia maksimale e bllokut për çdo grup të dhënash përcaktohet në veti recordsize (madhësia rekord). Madhësia e rekordit mund të ndryshojë, por kjo nuk do të ndryshojë madhësinë ose vendndodhjen e ndonjë blloku që është shkruar tashmë në grupin e të dhënave - ndikon vetëm blloqet e reja ashtu siç janë shkruar.
Nëse nuk specifikohet ndryshe, madhësia aktuale e paracaktuar e hyrjes është 128 KiB. Është një lloj kompromisi i vështirë ku performanca nuk do të jetë perfekte, por nuk do të jetë e tmerrshme në shumicën e rasteve. Recordsize mund të vendoset në çdo vlerë nga 4K në 1M (me cilësime shtesë recordsize mund të instaloni edhe më shumë, por kjo rrallë është një ide e mirë).
Çdo bllok i referohet të dhënave të vetëm një skedari - nuk mund të shtrydhni dy skedarë të ndryshëm në një bllok. Çdo skedar përbëhet nga një ose më shumë blloqe, në varësi të madhësisë së tij. Nëse madhësia e skedarit është më e vogël se madhësia e regjistrimit, ajo do të ruhet në një bllok më të vogël—për shembull, një bllok që përmban një skedar 2KiB do të zërë vetëm një sektor 4KiB në disk.
Nëse skedari është mjaft i madh për të kërkuar disa blloqe, atëherë të gjitha hyrjet në atë skedar do të jenë të madhësisë recordsize - duke përfshirë hyrjen e fundit, pjesa kryesore e së cilës mund të jetë .
vëllimet zvol nuk kanë pronë recordsize - në vend të kësaj ata kanë pronën ekuivalente volblocksize.
Sektorët
Blloku i fundit, më themelor i ndërtimit është sektori. Është njësia fizike më e vogël që mund të shkruhet ose lexohet nga një pajisje pritës. Për disa dekada, shumica e disqeve përdorën sektorë 512 byte. Këto ditë, shumica e disqeve janë konfiguruar për sektorë 4KiB, dhe disa - veçanërisht SSD - janë konfiguruar për sektorë 8KiB ose edhe më të mëdhenj.
ZFS ka një veçori që ju lejon të vendosni manualisht madhësinë e sektorit. Kjo pronë ashift. Në mënyrë disi konfuze, zhvendosja është një fuqi prej dysh. Për shembull, ashift=9 do të thotë madhësia e sektorit 2^9, ose 512 bajt.
ZFS i kërkon sistemit operativ informacion të detajuar për çdo pajisje bllok kur shtohet në një vdev të ri dhe teorikisht vendos automatikisht zhvendosjen në mënyrë të përshtatshme bazuar në atë informacion. Fatkeqësisht, shumë disqe gënjejnë për madhësinë e sektorit të tyre për të ruajtur përputhshmërinë me Windows XP (i cili nuk ishte në gjendje të kuptonte disqet me madhësi të sektorëve të tjerë).
Kjo do të thotë se rekomandohet shumë që administratori i ZFS të dijë madhësinë aktuale të sektorit të pajisjeve të tyre dhe të vendosë manualisht ashift. Nëse zhvendosja është vendosur shumë e vogël, numri i operacioneve të leximit/shkrimit rritet në mënyrë astronomike. Pra, të shkruash "sektorë" 512 bajt në një sektor real 4KiB do të thotë të duhet të shkruash "sektorin" e parë, më pas të lexosh sektorin 4KiB, ta modifikosh me një "sektor" të dytë 512 bajt, ta kthesh në sektorin e ri 4KiB. , dhe kështu me radhë për çdo hyrje.
Në botën reale, një ndëshkim i tillë prek SSD-të e Samsung EVO, për të cilat duhet të aplikohet ashift=13, por këto SSD gënjejnë për madhësinë e sektorit të tyre, dhe për këtë arsye parazgjedhja është vendosur në ashift=9. Nëse një administrator i sistemit me përvojë nuk e ndryshon këtë cilësim, ky SSD funksionon më i ngadalshëm HDD i rregullt magnetik.
Për krahasim, për të qenë shumë i madh ashift praktikisht nuk ka asnjë penallti. Nuk ka asnjë goditje reale të performancës dhe rritja e hapësirës së papërdorur është infinite e vogël (ose zero nëse kompresimi është i aktivizuar). Prandaj, ne rekomandojmë fuqimisht që edhe ato disqe që përdorin sektorë 512 bajt të instalohen ashift=12 ose madje ashift=13për të parë me besim në të ardhmen.
Prona ashift është instaluar për çdo pajisje virtuale vdev, dhe jo për pishinë, siç mendojnë gabimisht shumë njerëz, dhe nuk ndryshon pas instalimit. Nëse goditni aksidentalisht ashift Kur shtoni një vdev të ri në një pishinë, ju e keni ndotur në mënyrë të pakthyeshme atë pishinë me një pajisje me performancë të ulët dhe, si rregull, nuk ka zgjidhje tjetër përveçse të shkatërroni pishinën dhe të filloni nga e para. Edhe fshirja e vdev nuk do t'ju shpëtojë nga një cilësim i prishur ashift!
Mekanizmi kopjimi në shkrim
Nëse një sistem skedari të rregullt duhet të rishkruajë të dhënat, ai modifikon çdo bllok ku ndodhet
Një sistem skedari kopjimi në shkrim shkruan një version të ri të bllokut dhe më pas zhbllokon versionin e vjetër
Në mënyrë abstrakte, nëse injorojmë rregullimin aktual fizik të blloqeve, "kometa jonë e të dhënave" thjeshtohet në një "krimb të dhënash" që lëviz nga e majta në të djathtë përgjatë hartës së hapësirës së disponueshme.
Tani mund të kemi një ide të mirë se si funksionojnë fotografitë e fotokopjimit në shkrim - çdo bllok mund t'i përkasë disa fotografive të çastit dhe do të vazhdojë derisa të shkatërrohen të gjitha fotot e lidhura
Mekanizmi Copy on Write (CoW) është baza themelore e asaj që e bën ZFS një sistem kaq të mahnitshëm. Koncepti bazë është i thjeshtë - nëse i kërkoni një sistemi skedar tradicional të ndryshojë një skedar, ai do të bëjë pikërisht atë që keni kërkuar. Nëse i kërkoni një sistemi skedarësh kopje-në-shkrim të bëjë të njëjtën gjë, ai do të thotë "në rregull" - por do t'ju gënjejë.
Në vend të kësaj, një sistem skedari kopjimi në shkrim shkruan një version të ri të bllokut të modifikuar dhe më pas përditëson meta të dhënat e skedarit për të shkëputur bllokun e vjetër dhe për ta lidhur atë me bllokun e ri që sapo keni shkruar.
Çlidhja e bllokut të vjetër dhe lidhja e bllokut të ri bëhet me një operacion, kështu që nuk mund të ndërpritet - nëse rivendosni energjinë pasi të ndodhë kjo, keni një version të ri të skedarit dhe nëse rivendosni energjinë më parë, atëherë keni versionin e vjetër. Në çdo rast, nuk do të ketë konflikte në sistemin e skedarëve.
Kopjimi në shkrim në ZFS ndodh jo vetëm në nivelin e sistemit të skedarëve, por edhe në nivelin e menaxhimit të diskut. Kjo do të thotë që ZFS nuk është i ndjeshëm ndaj hapësirës së bardhë në regjistrim () - një fenomen kur shiriti ishte regjistruar vetëm pjesërisht përpara se sistemi të rrëzohej, me dëmtim të grupit pas një rindezjeje. Këtu shiriti shkruhet në mënyrë atomike, vdev është gjithmonë vijues, dhe .
ZIL: Regjistri i synimeve të ZFS
ZFS trajton shkrimet sinkrone në një mënyrë të veçantë - i ruan ato përkohësisht, por menjëherë në ZIL përpara se më vonë t'i shkruajë ato përgjithmonë së bashku me shkrimet asinkrone.
Në mënyrë tipike, të dhënat e shkruara në ZIL nuk lexohen më. Por kjo është e mundur pas një dështimi të sistemit
Një SLOG, ose pajisje dytësore LOG, është thjesht një vdev special - dhe mundësisht shumë i shpejtë - ku ZIL mund të ruhet veçmas nga ruajtja kryesore
Pas një përplasjeje, të gjitha të dhënat e pista në ZIL riluhen - në këtë rast, ZIL është në SLOG, kështu që ja ku riluhet
Ekzistojnë dy kategori kryesore të shkrimeve - sinkron (sinkron) dhe asinkron (asinkron). Për shumicën e ngarkesave të punës, shumica dërrmuese e shkrimeve janë asinkrone - sistemi i skedarëve lejon që ato të grumbullohen dhe lëshohen në grupe, duke zvogëluar fragmentimin dhe duke rritur ndjeshëm xhiron.
Regjistrimet e sinkronizuara janë një çështje krejtësisht e ndryshme. Kur një aplikacion kërkon një shkrim sinkron, ai i thotë sistemit të skedarëve: "Duhet ta kryeni këtë në memorie jo të paqëndrueshme tani, dhe deri atëherë nuk mund të bëj asgjë më shumë.” Prandaj, shkrimet sinkrone duhet të angazhohen menjëherë në disk - dhe nëse kjo rrit fragmentimin ose zvogëlon xhiron, kështu qoftë.
ZFS i trajton shkrimet sinkrone ndryshe nga sistemet e skedarëve të zakonshëm - në vend që t'i shpërndajë ato menjëherë në ruajtje të rregullt, ZFS i angazhon ato në një zonë të veçantë ruajtjeje të quajtur ZFS Intent Log, ose ZIL. Truku është se këto të dhëna edhe mbeten në memorie, duke u grumbulluar së bashku me kërkesat normale të shkrimit asinkron, për t'u futur më vonë në ruajtje si TXG plotësisht normale (Grupet e Transaksionit).
Gjatë funksionimit normal, ZIL shkruhet dhe nuk lexohet më. Kur, pas disa çastesh, të dhënat nga ZIL vendosen në ruajtjen kryesore në TXG të rregullt nga RAM, ato shkëputen nga ZIL. E vetmja herë që lexohet diçka nga ZIL është kur importoni një pishinë.
Nëse ndodh një përplasje e ZFS - një përplasje e sistemit operativ ose një ndërprerje e energjisë - ndërkohë që ka të dhëna në ZIL, ato të dhëna do të lexohen gjatë importit të radhës të grupit (për shembull, kur sistemi i përplasjes riniset). Çfarëdo që është në ZIL do të lexohet, do të grupohet në TXG, do të vendoset në dyqanin kryesor dhe më pas do të shkëputet nga ZIL gjatë procesit të importit.
Një nga klasat ndihmëse të vdev quhet LOG ose SLOG, një pajisje dytësore LOG. Ai ka një qëllim - të sigurojë një pishinë me një pajisje vdev të veçantë dhe mundësisht shumë më të shpejtë, shumë rezistente ndaj shkrimit për ruajtjen e ZIL, në vend që të ruajë ZIL në ruajtjen kryesore të vdev. Vetë ZIL sillet njësoj pavarësisht vendndodhjes së ruajtjes, por nëse vdev me LOG ka performancë shumë të lartë të shkrimit, atëherë shkrimet sinkrone do të jenë më të shpejta.
Shtimi i vdev me LOG në pishinë nuk funksionon nuk mund të përmirësoni performancën e shkrimit asinkron - edhe nëse i detyroni të gjitha shkrimet në ZIL me zfs set sync=always, ato do të jenë ende të lidhura me ruajtjen kryesore në TXG në të njëjtën mënyrë dhe me të njëjtin ritëm si pa regjistrin. I vetmi përmirësim i drejtpërdrejtë i performancës është vonesa sinkron e shkrimit (pasi shpejtësitë më të larta të regjistrit i bëjnë operacionet më të shpejta sync).
Megjithatë, në një mjedis që tashmë kërkon shumë shkrime sinkrone, vdev LOG mund të përshpejtojë në mënyrë indirekte shkrimet asinkrone dhe leximet e pakapshme. Shkarkimi i regjistrimeve ZIL në një LOG të veçantë vdev do të thotë më pak grindje për IOPS në memorien kryesore, gjë që përmirëson në një farë mase performancën e të gjitha leximeve dhe shkrimeve.
Fotot e çastit
Mekanizmi kopjimi në shkrim është gjithashtu një bazë e nevojshme për fotografitë atomike ZFS dhe replikimin asinkron në rritje. Sistemi aktiv i skedarëve ka një pemë treguese që shënon të gjitha hyrjet me të dhënat aktuale - kur bëni një fotografi, thjesht bëni një kopje të asaj peme treguese.
Kur një rekord mbishkruhet në sistemin e skedarëve aktiv, ZFS fillimisht shkruan versionin e ri të bllokut në hapësirën e papërdorur. Më pas shkëput versionin e vjetër të bllokut nga sistemi aktual i skedarëve. Por nëse disa fotografi i referohen një blloku të vjetër, ai ende mbetet i pandryshuar. Blloku i vjetër në fakt nuk do të rikthehet si hapësirë e lirë derisa të shkatërrohen të gjitha fotografitë që i referohen atij blloku!
Replikimi
Biblioteka ime Steam në 2015 ishte 158 GiB dhe përfshinte 126 skedarë. Kjo është shumë afër situatës optimale për rsync - riprodhimi i ZFS në rrjet ishte "vetëm" 927% më i shpejtë.
Në të njëjtin rrjet, riprodhimi i një skedari të vetëm imazhi të makinës virtuale 40 GB Windows 7 është një histori krejtësisht e ndryshme. Replikimi i ZFS është 289 herë më i shpejtë se rsync—ose "vetëm" 161 herë më i shpejtë nëse jeni mjaftueshëm i zgjuar për të thirrur rsync me çelësin --inplace.
Kur një imazh i VM-së përshkallëzohet, rsync çështjet në shkallë me të. Madhësia 1,9 TiB nuk është aq e madhe për një imazh modern të VM-së - por është mjaft e madhe që riprodhimi i ZFS të jetë 1148 herë më i shpejtë se rsync, edhe me argumentin rsync --inplace
Pasi të kuptoni se si funksionojnë fotografitë e çastit, do të jetë e lehtë të kuptoni thelbin e përsëritjes. Meqenëse një fotografi është thjesht një pemë e treguesve të rekordeve, rrjedh se nëse e bëjmë këtë zfs send snapshot, më pas ne dërgojmë këtë pemë dhe të gjitha të dhënat që lidhen me të. Kur ta kalojmë këtë zfs send в zfs receive në objektin e synuar, ai shkruan si përmbajtjen aktuale të bllokut ashtu edhe pemën e treguesve që i referohen blloqeve në grupin e të dhënave të synuar.
Gjërat bëhen edhe më interesante në të dytën zfs send. Tani kemi dy sisteme, secili përmban poolname/datasetname@1, dhe ju bëni një fotografi të re poolname/datasetname@2. Prandaj, në grupin burimor që keni datasetname@1 и datasetname@2, dhe në grupin e synuar ka vetëm fotografinë e parë datasetname@1.
Sepse midis burimit dhe objektivit kemi një pamje të përbashkët datasetname@1, ne mund ta bëjmë në rritje zfs send mbi të. Kur i themi sistemit zfs send -i poolname/datasetname@1 poolname/datasetname@2, ai krahason dy pemë treguese. Çdo tregues që ekziston vetëm në @2, padyshim i referohen blloqeve të reja - kështu që do të na duhet përmbajtja e atyre blloqeve.
Në një sistem të largët, përpunimi në rritje send po aq e thjeshtë. Së pari ne shkruajmë të gjitha hyrjet e reja të përfshira në transmetim send, dhe më pas shtoni tregues në këto blloqe. Voila, kemi @2 në sistemin e ri!
Replikimi asinkron në rritje i ZFS është një përmirësim i madh në krahasim me metodat e mëparshme jo të bazuara në fotografi, si p.sh. rsync. Në të dyja rastet, transferohen vetëm të dhënat e ndryshuara - por fillimisht duhet rsync lexoj nga disku të gjitha të dhënat në të dyja anët për të kontrolluar shumën dhe për ta krahasuar atë. Në të kundërt, replikimi ZFS nuk lexon asgjë tjetër përveç pemëve të treguesve - dhe çdo blloqe që nuk përfaqësohet në pamjen e përgjithshme.
Kompresim i integruar
Mekanizmi kopjimi-në-shkrim thjeshton gjithashtu sistemin e integruar të kompresimit. Në një sistem skedar tradicional, kompresimi është problematik - si versioni i vjetër ashtu edhe versioni i ri i të dhënave të ndryshuara qëndrojnë në të njëjtën hapësirë.
Nëse konsideroni një pjesë të të dhënave në mes të një skedari që fillon jetën e tij si një megabajt zero nga 0x00000000 e kështu me radhë, është shumë e lehtë ta kompresoni atë në një sektor të vetëm në disk. Por çfarë ndodh nëse e zëvendësojmë këtë megabajt zero me një megabajt të dhënash të pakompresueshme, të tilla si JPEG ose zhurmë pseudo-rastësore? Papritur, ai megabajt i të dhënave do të kërkonte jo një, por 256 sektorë 4KiB, dhe vetëm një sektor ishte i rezervuar në atë hapësirë disku.
ZFS nuk e ka këtë problem sepse shkrimet e modifikuara shkruhen gjithmonë në hapësirën e papërdorur - blloku origjinal merr vetëm një sektor 4 KiB, por një shkrim i ri do të zërë 256, por ky nuk është problem - një pjesë e modifikuar së fundi nga " mes" i skedarit do të ishte shkruar në hapësirën e papërdorur pavarësisht nëse madhësia e tij ka ndryshuar apo jo, kështu që kjo është një situatë krejtësisht normale për ZFS.
Kompresimi i integruar i ZFS-së është i çaktivizuar si parazgjedhje dhe sistemi ofron algoritme të lidhura—aktualisht duke përfshirë LZ4, gzip (1-9), LZJB dhe ZLE.
- LZ4 është një algoritëm transmetimi që ofron kompresim dhe dekompresim jashtëzakonisht të shpejtë dhe përfitime të performancës për shumicën e rasteve të përdorimit - edhe në CPU mjaft të ngadalta.
- GZIP është një algoritëm i nderuar që të gjithë përdoruesit e Unix-it e njohin dhe e duan. Mund të zbatohet me nivelet e kompresimit 1-9, me rritjen e raportit të kompresimit dhe përdorimit të CPU-së ndërsa i afroheni nivelit 9. Algoritmi është i përshtatshëm për të gjitha rastet e përdorimit të tekstit (ose të tjera shumë të kompresueshme), por shpesh shkakton probleme të CPU-së ndryshe. Përdoreni atë me kujdes, veçanërisht në nivele më të larta.
- LZJB - algoritmi origjinal në ZFS. Është i vjetëruar dhe nuk duhet të përdoret më, LZ4 është superior në çdo drejtim.
- KEQE — kodimi i nivelit zero, kodimi i nivelit zero. Nuk prek fare të dhënat normale, por ngjesh sekuenca të mëdha zerosh. I dobishëm për grupe të dhënash plotësisht të pakompresueshme (të tilla si JPEG, MP4 ose formate të tjera tashmë të ngjeshur) pasi injoron të dhënat e pakompresueshme, por ngjesh hapësirën e papërdorur në regjistrimet që rezultojnë.
Ne rekomandojmë kompresimin LZ4 për pothuajse të gjitha rastet e përdorimit; dënimi i performancës kur kemi të bëjmë me të dhëna të pakompresueshme është shumë i vogël, dhe rritje performanca për të dhënat tipike është e rëndësishme. Kopjimi i një imazhi të makinës virtuale për një instalim të ri të sistemit operativ Windows (OS i sapo instaluar, nuk ka ende të dhëna brenda) me compression=lz4 kaloi 27% më shpejt se me compression=none, në .
ARC - Adaptive Replacement Cache
ZFS është i vetmi sistem skedar modern për të cilin ne njohim që përdor mekanizmin e tij të memorizimit të leximit, në vend që të mbështetet në cache-in e faqeve të sistemit operativ për të ruajtur kopjet e blloqeve të lexuara së fundmi në RAM.
Megjithëse cache-i vendas nuk është pa probleme - ZFS nuk mund t'u përgjigjet kërkesave të reja për ndarjen e memories aq shpejt sa kerneli, kështu që një thirrje e re malloc() Shpërndarja e memories mund të dështojë nëse kërkon RAM të zënë aktualisht nga ARC. Por ka arsye të mira për të përdorur cache-in tuaj, të paktën tani për tani.
Të gjitha sistemet operative të njohura moderne, duke përfshirë MacOS, Windows, Linux dhe BSD, përdorin algoritmin LRU (Last Recently Used) për të zbatuar cache-in e faqeve. Ky është një algoritëm primitiv që shtyn një bllok memorie të fshehtë "në krye të radhës" pas çdo leximi dhe shtyn blloqet "në fund të radhës" sipas nevojës për të shtuar gabime të reja të memories (blloqe që duhet të ishin lexuar nga disku në vend të nga cache) në krye.
Zakonisht algoritmi funksionon mirë, por në sistemet me grupe të mëdha të dhënash pune, LRU çon lehtësisht në rrahje - duke nxjerrë blloqe të nevojshme shpesh për të krijuar vend për blloqe që nuk do të lexohen më kurrë nga cache.
është një algoritëm shumë më pak naiv që mund të konsiderohet si një cache "e ponderuar". Sa herë që lexohet një bllok i ruajtur në memorie, ai bëhet pak më "i rëndë" dhe bëhet më i vështirë për t'u nxjerrë - dhe madje edhe pasi blloku të jetë nxjerrë gjurmuar gjatë një periudhe të caktuar kohore. Një bllok që është nxjerrë, por më pas duhet të lexohet përsëri në cache, do të bëhet gjithashtu më i rëndë.
Rezultati përfundimtar i gjithë kësaj është një cache me një raport shumë më të lartë të goditjes - raporti midis goditjeve të cache (lexime nga cache) dhe gabimeve (lexime nga disku). Kjo është një statistikë jashtëzakonisht e rëndësishme - jo vetëm që goditjet e cache-it shërbehen me urdhra të madhësisë më të shpejta, por edhe gabimet e cache-it mund të shërbehen më shpejt, pasi sa më shumë goditje në cache të ketë, aq më pak kërkesa të njëkohshme në disk dhe aq më i ulët është vonesa për ato gabime të mbetura. që duhet të servisohet me disk.
Përfundim
Tani që kemi mbuluar semantikën bazë të ZFS - si funksionon kopjimi në shkrim, si dhe marrëdhëniet midis grupeve të ruajtjes, pajisjeve virtuale, blloqeve, sektorëve dhe skedarëve - jemi gati të diskutojmë performancën e botës reale me numra realë.
Në pjesën tjetër, ne do të shikojmë performancën aktuale të grupeve të pasqyruara vdev dhe RAIDz, krahasuar me njëri-tjetrin, dhe gjithashtu krahasuar me topologjitë tradicionale të kernelit të Linux RAID që kemi ekzaminuar .
Në fillim donim të mbulonim vetëm bazat - vetë topologjitë ZFS - por më pas kjo Ne do të jemi gati të flasim për konfigurimin dhe akordimin më të avancuar të ZFS, duke përfshirë përdorimin e llojeve ndihmëse të vdev si L2ARC, SLOG dhe Special Alocation.
Burimi: www.habr.com