Šį pavasarį jau aptarėme kai kurias įvadines temas, pavyzdžiui, и . Antrajame iš jų netgi pažadėjome toliau tirti įvairių kelių diskų topologijų veikimą ZFS. Tai naujos kartos failų sistema, kuri dabar diegiama visur: nuo į .
Na, o šiandien pati geriausia diena susipažinti su ZFS, smalsiais skaitytojais. Tiesiog žinokite, kad nuolankiai OpenZFS kūrėjo Matto Ahrenso nuomone, „tai tikrai sunku“.
Tačiau prieš pereidami prie skaičių – pažadu, jie bus – dėl visų aštuonių diskų ZFS konfigūracijos variantų turime pakalbėti apie kaip Paprastai ZFS saugo duomenis diske.
Zpool, vdev ir įrenginys
Šioje viso telkinio diagramoje yra trys pagalbiniai vdev, po vieną kiekvienos klasės ir keturis RAIDz2
Paprastai nėra jokios priežasties kurti nesutampančių Vdev tipų ir dydžių telkinį, tačiau niekas netrukdo to daryti, jei to norite.
Norėdami iš tikrųjų suprasti ZFS failų sistemą, turite atidžiai išnagrinėti tikrąją jos struktūrą. Pirma, ZFS suvienija tradicinius apimties ir failų sistemos valdymo lygius. Antra, jis naudoja operacijų kopijavimo ir rašymo mechanizmą. Šios funkcijos reiškia, kad sistema struktūriškai labai skiriasi nuo įprastų failų sistemų ir RAID masyvų. Pirmasis pagrindinių sudedamųjų dalių rinkinys, kurį reikia suprasti, yra saugojimo baseinas (zpool), virtualus įrenginys (vdev) ir tikrasis įrenginys (įrenginys).
zpool
„Zpool“ saugyklos baseinas yra aukščiausia ZFS struktūra. Kiekviename telkinyje yra vienas ar daugiau virtualių įrenginių. Savo ruožtu kiekviename iš jų yra vienas ar keli realūs įrenginiai (įrenginys). Virtualūs baseinai yra savarankiški blokai. Viename fiziniame kompiuteryje gali būti du ar daugiau atskirų telkinių, tačiau kiekvienas yra visiškai nepriklausomas nuo kitų. Baseinai negali bendrinti virtualių įrenginių.
ZFS perteklius yra virtualaus įrenginio lygiu, o ne baseino lygiu. Baseino lygiu visiškai nėra pertekliaus – jei prarandamas koks nors diskas vdev ar specialus vdev, kartu su juo prarandamas ir visas baseinas.
Šiuolaikinės saugyklos gali išgyventi praradus talpyklą arba virtualaus įrenginio žurnalą – nors jie gali prarasti nedidelį kiekį nešvarių duomenų, jei praras „vdev“ žurnalą elektros tiekimo nutraukimo ar sistemos gedimo metu.
Yra paplitusi klaidinga nuomonė, kad ZFS „duomenų juostelės“ rašomos visame telkinyje. Tai netiesa. „Zpool“ visai nejuokingas RAID0, tai gana juokingas su sudėtingu kintamo paskirstymo mechanizmu.
Įrašai didžiąja dalimi paskirstomi tarp turimų virtualių įrenginių pagal turimą laisvą vietą, tad teoriškai jie visi bus pildomi vienu metu. Vėlesnėse ZFS versijose atsižvelgiama į esamą „vdev“ naudojimą (naudojimą) – jei vienas virtualus įrenginys yra žymiai užimtesnis už kitą (pavyzdžiui, dėl skaitymo apkrovos), jis bus laikinai praleistas rašyti, nepaisant to, kad turi didžiausią laisvą erdvės santykis.
Šiuolaikiniuose ZFS rašymo paskirstymo metoduose įmontuotas panaudojimo aptikimo mechanizmas gali sumažinti delsą ir padidinti pralaidumą neįprastai didelės apkrovos laikotarpiais, bet tai ne carte blanche apie priverstinį lėtų HDD ir greitų SSD sumaišymą viename telkinyje. Toks nevienodas baseinas vis tiek veiks lėčiausio įrenginio greičiu, tai yra, tarsi jis būtų visiškai sudarytas iš tokių įrenginių.
vdev
Kiekvieną saugyklos telkinį sudaro vienas ar keli virtualūs įrenginiai (virtualus įrenginys, vdev). Savo ruožtu kiekvienas vdev turi vieną ar daugiau tikrų įrenginių. Dauguma virtualių įrenginių yra naudojami paprastam duomenų saugojimui, tačiau yra keletas vdev pagalbinių klasių, įskaitant CACHE, LOG ir SPECIAL. Kiekvienas iš šių vdev tipų gali turėti vieną iš penkių topologijų: vienas įrenginys (vienas įrenginys), RAIDz1, RAIDz2, RAIDz3 arba veidrodis (veidrodis).
RAIDz1, RAIDz2 ir RAIDz3 yra ypatingos atmainos, kurias senbuviai vadintų dvigubo (įstrižainės) pariteto RAID. 1, 2 ir 3 nurodo, kiek pariteto blokų yra skirta kiekvienai duomenų juostai. Vietoj atskirų diskų paritetui, RAIDz virtualūs įrenginiai paskirsto šį lygumą pusiau tolygiai tarp diskų. RAIDz masyvas gali prarasti tiek diskų, kiek turi pariteto blokų; jei jis praras kitą, jis sudužs ir pasiims saugyklos baseiną.
Veidrodiniuose virtualiuose įrenginiuose (veidrodiniame vdev) kiekvienas blokas yra saugomas kiekviename vdev įrenginyje. Nors dažniausiai naudojami dviejų pločių veidrodžiai, veidrodyje gali būti bet koks įrenginių skaičius – trigubai dažnai naudojami dideliuose įrenginiuose, siekiant pagerinti skaitymo našumą ir atsparumą gedimams. Vdev veidrodis gali išgyventi bet kokį gedimą tol, kol veikia bent vienas vdev įrenginys.
Pavieniai vaizdo įrašai yra pavojingi. Toks virtualus įrenginys neišgyvens nė vieno gedimo – o jei bus naudojamas kaip saugykla ar specialus vdev, jo gedimas sukels viso baseino sunaikinimą. Būkite čia labai, labai atsargūs.
CACHE, LOG ir SPECIAL VA gali būti sukurti naudojant bet kurią iš aukščiau išvardytų topologijų, tačiau atminkite, kad SPECIAL VA praradimas reiškia telkinio praradimą, todėl labai rekomenduojama naudoti perteklinę topologiją.
prietaisas
Tai bene lengviausiai suprantamas terminas ZFS – tai tiesiogine prasme blokuojamas laisvosios prieigos įrenginys. Atminkite, kad virtualius įrenginius sudaro atskiri įrenginiai, o telkinį sudaro virtualūs įrenginiai.
Diskai – arba magnetiniai, arba kietojo kūno – yra labiausiai paplitę blokiniai įrenginiai, naudojami kaip vdev elementai. Tačiau tiks bet kuris įrenginys, kurio deskriptorius yra /dev, todėl visas aparatinės įrangos RAID matricas galima naudoti kaip atskirus įrenginius.
Paprastas neapdorotas failas yra vienas iš svarbiausių alternatyvių blokinių įrenginių, iš kurių galima sukurti vdev. Išbandykite baseinus nuo yra labai patogus būdas patikrinti telkinio komandas ir pamatyti, kiek vietos yra baseine arba virtualiame tam tikros topologijos įrenginyje.
Galite sukurti bandomąjį telkinį iš negausių failų vos per kelias sekundes, bet nepamirškite vėliau ištrinti viso telkinio ir jo komponentų
Tarkime, kad norite įdėti serverį į aštuonis diskus ir planuojate naudoti 10 TB diskus (~9300 GiB), bet nesate tikri, kuri topologija geriausiai atitinka jūsų poreikius. Aukščiau pateiktame pavyzdyje bandomąjį telkinį sukuriame iš negausių failų per kelias sekundes – ir dabar žinome, kad aštuonių 2 TB diskų RAIDz10 vdev suteikia 50 TiB naudingos talpos.
Kita speciali prietaisų klasė yra SPARE (atsarginis). Karštuoju būdu keičiami įrenginiai, skirtingai nei įprasti įrenginiai, priklauso visam telkiniui, o ne vienam virtualiam įrenginiui. Jei telkinyje esantis Vdev sugenda, o atsarginis įrenginys yra prijungtas prie telkinio ir yra pasiekiamas, jis automatiškai prisijungs prie paveikto VDE.
Prisijungus prie paveikto vdev, atsarginis įrenginys pradeda gauti duomenų, kurie turėtų būti trūkstamame įrenginyje, kopijas arba rekonstrukcijas. Tradiciniame RAID tai vadinama atkūrimu, o ZFS – perdabravimu.
Svarbu pažymėti, kad atsarginiai įrenginiai visam laikui nepakeičia sugedusių įrenginių. Tai tik laikinas pakeitimas, siekiant sutrumpinti vdev degradacijos laiką. Administratoriui pakeitus sugedusį vdev, atkuriamas to nuolatinio įrenginio perteklius, o SPARE atjungiamas nuo vdev ir grąžinamas dirbti kaip atsarginis visame telkinyje.
Duomenų rinkiniai, blokai ir sektoriai
Kitas sudedamųjų dalių rinkinys, kurį reikia suprasti mūsų ZFS kelionėje, yra mažiau apie aparatinę įrangą, o daugiau apie tai, kaip tvarkomi ir saugomi patys duomenys. Čia praleidžiame kelis lygius, pvz., metaslab, kad neužgriozdintume detalių ir išlaikytume supratimą apie bendrą struktūrą.
Duomenų rinkinys (duomenų rinkinys)
Kai pirmą kartą sukuriame duomenų rinkinį, jame rodoma visa galima telkinio vieta. Tada nustatome kvotą ir keičiame prijungimo tašką. Magija!
„Zvol“ dažniausiai yra tik duomenų rinkinys, iš kurio pašalintas failų sistemos sluoksnis, kurį čia pakeičiame visiškai įprasta ext4 failų sistema.
ZFS duomenų rinkinys yra maždaug toks pat kaip standartinė prijungta failų sistema. Kaip ir įprasta failų sistema, iš pirmo žvilgsnio ji atrodo kaip „tik dar vienas aplankas“. Bet kaip ir įprastos montuojamos failų sistemos, kiekvienas ZFS duomenų rinkinys turi savo pagrindinių savybių rinkinį.
Visų pirma, duomenų rinkiniui gali būti priskirta kvota. Jei nustatyta zfs set quota=100G poolname/datasetname, tada negalėsite rašyti į prijungtą aplanką /poolname/datasetname daugiau nei 100 GiB.
Pastebite, kad kiekvienos eilutės pradžioje yra ir nėra pasvirųjų brūkšnių? Kiekvienas duomenų rinkinys turi savo vietą ZFS hierarchijoje ir sistemos prijungimo hierarchijoje. ZFS hierarchijoje nėra pasvirojo brūkšnio – pradedate nuo telkinio pavadinimo, o tada – kelio nuo vieno duomenų rinkinio iki kito. Pavyzdžiui, pool/parent/child duomenų rinkiniui, pavadintam child pagal pirminį duomenų rinkinį parent baseine kūrybiniu pavadinimu pool.
Pagal numatytuosius nustatymus duomenų rinkinio prijungimo taškas bus lygiavertis jo pavadinimui ZFS hierarchijoje su pasviruoju brūkšniu priekyje – telkinys pavadintas pool montuojamas kaip /pool, duomenų rinkinys parent sumontuotas /pool/parentir antrinis duomenų rinkinys child sumontuotas /pool/parent/child. Tačiau duomenų rinkinio sistemos prijungimo tašką galima pakeisti.
Jei nurodysime zfs set mountpoint=/lol pool/parent/child, tada duomenų rinkinys pool/parent/child montuojamas ant sistemos kaip /lol.
Be duomenų rinkinių, turėtume paminėti apimtis (zvols). Tomas yra maždaug toks pat kaip duomenų rinkinys, išskyrus tai, kad jis iš tikrųjų neturi failų sistemos – tai tik blokuojamas įrenginys. Galite, pavyzdžiui, sukurti zvol Su vardu mypool/myzvol, tada suformatuokite jį naudodami ext4 failų sistemą ir prijunkite tą failų sistemą – dabar turite ext4 failų sistemą, tačiau su visomis ZFS saugos funkcijomis! Tai gali atrodyti kvaila viename kompiuteryje, bet yra daug prasmingesnė kaip užpakalinė programa eksportuojant iSCSI įrenginį.
Blokai
Failas pavaizduotas vienu ar daugiau blokų. Kiekvienas blokas saugomas viename virtualiame įrenginyje. Bloko dydis paprastai yra lygus parametrui rekordo dydžio, bet gali būti sumažintas iki 2^ pamainajei jame yra metaduomenų arba nedidelis failas.
Mes tikrai tikrai nejuokaujame apie didžiulę baudą už atliktus darbus, jei nustatote per mažą poslinkį
ZFS telkinyje visi duomenys, įskaitant metaduomenis, saugomi blokuose. Didžiausias bloko dydis kiekvienam duomenų rinkiniui yra apibrėžtas nuosavybėje recordsize (rekordinio dydžio). Įrašo dydį galima keisti, tačiau tai nepakeis jokių blokų, kurie jau buvo įrašyti į duomenų rinkinį, dydžio ar vietos – tai paveiks tik naujus blokus, kai jie įrašomi.
Jei nenurodyta kitaip, dabartinis numatytasis įrašo dydis yra 128 KiB. Tai savotiškas sudėtingas kompromisas, kai našumas nėra tobulas, tačiau daugeliu atvejų jis taip pat nėra baisus. Recordsize galima nustatyti bet kokią reikšmę nuo 4K iki 1M (su išplėstiniais nustatymais recordsize galite įdiegti dar daugiau, bet tai retai būna gera idėja).
Bet kuris blokas nurodo tik vieno failo duomenis – į vieną bloką negalima sugrūsti dviejų skirtingų failų. Kiekvienas failas susideda iš vieno ar daugiau blokų, priklausomai nuo dydžio. Jei failo dydis yra mažesnis nei įrašo dydis, jis bus saugomas mažesniu bloko dydžiu – pavyzdžiui, blokas su 2 KiB failu užims tik vieną 4 KiB sektorių diske.
Jei failas yra pakankamai didelis ir reikalauja kelių blokų, tada visi įrašai su šiuo failu bus tokio dydžio recordsize - įskaitant paskutinį įrašą, kurio pagrindinė dalis gali būti .
zvolai nuosavybės neturi recordsize — vietoj to jie turi lygiavertę savybę volblocksize.
Sektoriai
Paskutinis, pats pagrindinis elementas yra sektorius. Tai mažiausias fizinis vienetas, kurį galima įrašyti į pagrindinį įrenginį arba nuskaityti iš jo. Keletą dešimtmečių dauguma diskų naudojo 512 baitų sektorius. Pastaruoju metu dauguma diskų yra nustatyti į 4 KiB sektorius, o kai kurie – ypač SSD – turi 8 KiB sektorius ar net daugiau.
ZFS sistema turi savybę, leidžiančią rankiniu būdu nustatyti sektoriaus dydį. Šis turtas ashift. Šiek tiek painu, kad ashift yra dviejų galia. Pavyzdžiui, ashift=9 reiškia 2^9 arba 512 baitų sektoriaus dydį.
ZFS prašo operacinės sistemos išsamios informacijos apie kiekvieną blokinį įrenginį, kai jis pridedamas prie naujo vdev, ir teoriškai automatiškai tinkamai įdiegia ashift pagal šią informaciją. Deja, daugelis diskų meluoja apie savo sektoriaus dydį, kad išlaikytų suderinamumą su Windows XP (kuri nesugebėjo suprasti diskų su kitų sektorių dydžiais).
Tai reiškia, kad ZFS administratoriui primygtinai rekomenduojama žinoti tikrąjį savo įrenginių sektoriaus dydį ir nustatyti jį rankiniu būdu ashift. Jei poslinkis nustatytas per mažas, skaitymo / rašymo operacijų skaičius astronomiškai padidėja. Taigi 512 baitų „sektorių“ rašymas į tikrą 4 KiB sektorių reiškia, kad reikia parašyti pirmąjį „sektorių“, tada perskaityti 4 KiB sektorių, modifikuoti jį antruoju 512 baitų „sektoriumi“, įrašyti jį atgal į naują. 4 KiB sektorius ir tt kiekvienam įrašui.
Realiame pasaulyje tokia bauda sulaukia Samsung EVO SSD, už kurią ashift=13, tačiau šie SSD yra susiję su savo sektoriaus dydžiu, todėl nustatytas numatytasis nustatymas ashift=9. Jei patyręs sistemos administratorius nepakeičia šio nustatymo, šis SSD veikia lėčiau Įprastas magnetinis HDD.
Palyginimui, per dideliam dydžiui ashift baudos praktiškai nėra. Nėra realios našumo nuobaudos, o nepanaudotos vietos padidėjimas yra be galo mažas (arba nulis, kai įjungtas glaudinimas). Todėl primygtinai rekomenduojame įdiegti net tuos diskus, kuriuose naudojami 512 baitų sektoriai ashift=12 или даже ashift=13su pasitikėjimu žvelgti į ateitį.
Nuosavybė ashift yra nustatytas kiekvienam „vdev“ virtualiam įrenginiui ir ne baseinui, kaip daugelis klaidingai galvoja – ir po įdiegimo nesikeičia. Jei netyčia pataikėte ashift Kai pridedate naują vdev prie baseino, jūs negrįžtamai užteršėte tą baseiną žemo našumo įrenginiu ir paprastai nelieka kito pasirinkimo, kaip tik sunaikinti baseiną ir pradėti iš naujo. Netgi pašalinus vdev neapsaugosite nuo sugadintos konfigūracijos ashift!
Kopijavimo ant rašymo mechanizmas
Jei įprastai failų sistemai reikia perrašyti duomenis, ji pakeičia kiekvieną bloką ten, kur jis yra
Kopijavimo ir rašymo failų sistema įrašo naują bloko versiją ir atrakina senąją versiją
Abstrakčiai, jei ignoruosime tikrąją fizinę blokų vietą, mūsų „duomenų kometa“ supaprastinama iki „duomenų kirmino“, kuris juda iš kairės į dešinę per laisvos erdvės žemėlapį.
Dabar galime gerai suprasti, kaip veikia kopijavimo ir rašymo momentinės nuotraukos – kiekvienas blokas gali priklausyti kelioms momentinėms nuotraukoms ir išliks tol, kol bus sunaikintos visos susijusios momentinės nuotraukos.
„Copy on Write“ (CoW) mechanizmas yra pagrindinis pagrindas, dėl kurio ZFS yra tokia nuostabi sistema. Pagrindinė koncepcija paprasta – jei paprašysite tradicinės failų sistemos pakeisti failą, ji padarys būtent tai, ko prašėte. Jei paprašysite kopijavimo ir rašymo failų sistemos padaryti tą patį, ji pasakys „gerai“, bet meluos jums.
Vietoj to, kopijavimo ir rašymo failų sistema įrašo naują modifikuoto bloko versiją ir atnaujina failo metaduomenis, kad atsietų seną bloką ir susietų naują bloką, kurį ką tik parašėte.
Senojo bloko atjungimas ir naujo susiejimas atliekamas viena operacija, todėl jo negalima nutraukti – jei po to išjungsite maitinimą, turėsite naują failo versiją, o jei išjungsite anksčiau, turėsite senąją versiją. . Bet kokiu atveju failų sistemoje nebus konfliktų.
Kopijavimas rašant ZFS vyksta ne tik failų sistemos, bet ir disko valdymo lygiu. Tai reiškia, kad ZFS neturi įtakos tarpas () – reiškinys, kai juosta spėjo tik iš dalies įrašyti prieš sistemos gedimą, o masyvai buvo pažeisti po perkrovimo. Čia juostelė parašyta atomiškai, vdev visada yra nuosekli ir .
ZIL: ZFS ketinimų žurnalas
ZFS sistema sinchroninius įrašus apdoroja ypatingu būdu – laikinai, bet iš karto išsaugo juos ZIL, o vėliau visam laikui įrašo kartu su asinchroniniais įrašais.
Paprastai duomenys, įrašyti į ZIL, daugiau niekada neskaitomi. Bet tai įmanoma po sistemos gedimo
SLOG arba antrinis LOG įrenginys yra tik specialus ir pageidautina labai greitas vdev, kuriame ZIL galima laikyti atskirai nuo pagrindinės saugyklos.
Po avarijos visi nešvarūs ZIL duomenys atkuriami iš naujo – šiuo atveju ZIL yra SLOG, taigi jie atkuriami iš ten
Yra dvi pagrindinės rašymo operacijų kategorijos – sinchroninė (sinchronizacija) ir asinchroninė (asinchroninė). Daugumai darbo krūvių didžioji dauguma įrašų yra asinchroniniai – failų sistema leidžia juos apibendrinti ir išleisti partijomis, taip sumažinant suskaidymą ir labai padidinant pralaidumą.
Sinchronizuoti įrašai yra visiškai kitas dalykas. Kai programa reikalauja sinchroninio įrašymo, ji failų sistemai praneša: „Turite tai įrašyti į nepastovią atmintį dabariki tol nieko daugiau negaliu padaryti“. Todėl sinchroninis įrašymas turėtų būti nedelsiant įtrauktas į diską, o jei tai padidina susiskaidymą arba sumažina pralaidumą, tebūnie.
ZFS sinchroninį įrašymą tvarko kitaip nei įprastos failų sistemos – užuot iš karto įtraukę juos į įprastą saugyklą, ZFS įkelia juos į specialią saugojimo sritį, vadinamą ZFS Intent Log arba ZIL. Apgaulė ta, kad šie įrašai taip pat lieka atmintyje, sujungiami kartu su įprastomis asinchroninio rašymo užklausomis, kad vėliau būtų išplauti į saugyklą kaip visiškai įprastos TXG (operacijų grupės).
Įprastai veikiant, ZIL įrašomas ir daugiau niekada neskaitomas. Kai po kelių akimirkų ZIL įrašai perkeliami į pagrindinę atmintį įprastuose TXG iš RAM, jie atjungiami nuo ZIL. Vienintelis kartas, kai kas nors nuskaitomas iš ZIL, yra importuojant telkinį.
Jei ZFS nepavyksta – operacinės sistemos gedimas arba elektros energijos tiekimas nutrūksta – kol ZIL yra duomenų, tie duomenys bus nuskaitomi kito telkinio importavimo metu (pavyzdžiui, iš naujo paleidžiant avarinę sistemą). Viskas, kas yra ZIL, bus nuskaityta, sugrupuota į TXG, priskirta pagrindinei saugyklai, o tada importavimo proceso metu atskirta nuo ZIL.
Viena iš vdev pagalbinių klasių vadinama LOG arba SLOG, antriniu LOG įrenginiu. Jis turi vieną tikslą – aprūpinti baseiną atskiru, o pageidautina daug greitesniu, labai atspariu įrašymui vdev, kad būtų galima saugoti ZIL, o ne saugoti ZIL pagrindinėje vdev parduotuvėje. Pats ZIL elgiasi taip pat, kad ir kur būtų saugomas, bet jei LOG vdev turi labai aukštą rašymo našumą, sinchroninis rašymas bus greitesnis.
Vdev su LOG pridėjimas prie baseino neveikia negaliu pagerinti asinchroninio rašymo našumą – net jei priverstumėte visus rašyti į ZIL su zfs set sync=always, jie vis tiek bus susieti su pagrindine TXG saugykla taip pat ir tokiu pat greičiu kaip ir be žurnalo. Vienintelis tiesioginis našumo patobulinimas yra sinchroninio rašymo delsa (nes greitesnis žurnalas pagreitina operacijas). sync).
Tačiau aplinkoje, kuriai jau reikia daug sinchroninių įrašų, „vdev LOG“ gali netiesiogiai pagreitinti asinchroninį rašymą ir skaitymą ne talpykloje. ZIL įrašų perkėlimas į atskirą vdev LOG reiškia mažiau ginčų dėl IOPS pirminėje saugykloje, o tai tam tikru mastu pagerina visų skaitymo ir rašymo našumą.
Momentinės nuotraukos
Kopijavimo ir rašymo mechanizmas taip pat yra būtinas ZFS atominių momentinių nuotraukų ir laipsniško asinchroninio replikavimo pagrindas. Aktyvi failų sistema turi rodyklės medį, žymintį visus įrašus su dabartiniais duomenimis – kai darote momentinę nuotrauką, jūs tiesiog sukuriate šio rodyklės medžio kopiją.
Kai įrašas perrašomas aktyvioje failų sistemoje, ZFS pirmiausia įrašo naują bloko versiją į nepanaudotą vietą. Tada ji atskiria senąją bloko versiją nuo dabartinės failų sistemos. Bet jei kuri nors momentinė nuotrauka yra susijusi su senu bloku, ji vis tiek lieka nepakitusi. Senasis blokas iš tikrųjų nebus atkurtas kaip laisva vieta, kol nebus sunaikintos visos su šiuo bloku susijusios momentinės nuotraukos!
Replikacija
Mano „Steam“ biblioteka 2015 m. buvo 158 GiB ir joje buvo 126 927 failai. Tai gana artima optimaliai rsync situacijai – ZFS replikacija tinkle buvo „tik“ 750% greitesnė.
Tame pačiame tinkle vieno 40 GB „Windows 7“ virtualios mašinos vaizdo failo kopijavimas yra visiškai kitokia istorija. ZFS replikacija yra 289 kartus greitesnė nei rsync – arba „tik“ 161 kartą greitesnė, jei esate pakankamai išprusę, kad iškviestumėte rsync naudodami --inplace.
Kai keičiamas VM vaizdas, rsync problemos keičiasi su juo. 1,9 TiB nėra toks didelis šiuolaikiniam VM vaizdui, tačiau jis pakankamai didelis, kad ZFS replikacija būtų 1148 kartus greitesnė nei rsync, net ir naudojant rsync argumentą --inplace
Kai suprasite, kaip veikia momentinės nuotraukos, turėtų būti lengva suprasti replikacijos esmę. Kadangi momentinė nuotrauka yra tik nuorodų į įrašus medis, tai reiškia, kad jei tai padarysime zfs send momentinę nuotrauką, tada siunčiame ir šį medį, ir visus su juo susijusius įrašus. Kai atsiųsime tai zfs send в zfs receive taikinyje jis įrašo ir tikrąjį bloko turinį, ir rodyklių medį, nurodantį blokus į tikslinį duomenų rinkinį.
Antrą kartą viskas tampa dar įdomiau zfs send. Dabar turime dvi sistemas, kurių kiekvienoje yra poolname/datasetname@1, ir padarysite naują momentinę nuotrauką poolname/datasetname@2. Todėl originaliame baseine turite datasetname@1 и datasetname@2, o tiksliniame telkinyje kol kas tik pirmoji momentinė nuotrauka datasetname@1.
Kadangi turime bendrą momentinį vaizdą tarp šaltinio ir tikslo datasetname@1, mes galime tai padaryti Inkrementinis zfs send virš jo. Kai sakome sistemai zfs send -i poolname/datasetname@1 poolname/datasetname@2, lygina du rodyklės medžius. Bet kokios nuorodos, kurios egzistuoja tik @2, akivaizdu, kad kalbama apie naujus blokus, todėl mums reikia šių blokų turinio.
Nuotolinėje sistemoje apdorojamas prieaugis send lygiai taip pat paprasta. Pirmiausia įrašome visus naujus įrašus, įtrauktus į srautą send, tada pridėkite rodyklių prie tų blokų. Voila, mes turime @2 naujoje sistemoje!
ZFS asinchroninis laipsniškas replikavimas yra didžiulis patobulinimas, palyginti su ankstesniais ne momentiniais metodais, tokiais kaip rsync. Abiem atvejais perduodami tik pakeisti duomenys – bet pirmiausia turi rsync skaityti iš disko visus duomenis iš abiejų pusių, kad patikrintumėte sumą ir palygintumėte. Priešingai, ZFS replikacija neskaito nieko kito, tik rodyklės medžius – ir visus blokus, kurių nėra bendrinamame momentiniame vaizde.
Integruotas suspaudimas
Kopijavimo rašant mechanizmas taip pat supaprastina glaudinimo sistemą. Tradicinėje failų sistemoje glaudinimas yra problemiškas – tiek senoji, tiek naujoji modifikuotų duomenų versija yra toje pačioje erdvėje.
Jei laikytume duomenų fragmentą failo viduryje, kuris pradeda gyvuoti kaip megabaitas nulių nuo 0x00000000 ir t. t., labai lengva juos suspausti į vieną sektorių diske. Bet kas nutiks, jei tą megabaitą nulių pakeisime megabaitu nesuspaudžiamų duomenų, tokių kaip JPEG arba pseudoatsitiktinis triukšmas? Netikėtai šiam megabaitui duomenų reikės ne vieno, o 256 4 KiB sektorių, o šioje disko vietoje rezervuotas tik vienas sektorius.
ZFS neturi šios problemos, nes modifikuoti įrašai visada įrašomi į nepanaudotą erdvę – pradinis blokas užima tik vieną 4 KiB sektorių, o naujas įrašas – 256, tačiau tai nėra problema – neseniai modifikuotas fragmentas iš „ vidurio“ failas būtų įrašytas į nepanaudotą vietą, nepaisant to, ar jo dydis pasikeitė, ar ne, todėl ZFS tai yra gana įprasta situacija.
Vietinis ZFS glaudinimas pagal numatytuosius nustatymus yra išjungtas, o sistema siūlo prijungiamus algoritmus – šiuo metu LZ4, gzip (1-9), LZJB ir ZLE.
- LZ4 yra srautinio perdavimo algoritmas, siūlantis itin greitą glaudinimą ir išskleidimo bei našumo pranašumus daugeliu atvejų – net ir esant gana lėtam procesoriui.
- GZIP yra garbingas algoritmas, kurį žino ir mėgsta visi Unix vartotojai. Jis gali būti įgyvendintas su 1-9 glaudinimo lygiais, kai suspaudimo laipsnis ir procesoriaus naudojimas didėja artėjant prie 9 lygio. Algoritmas puikiai tinka visiems teksto (ar kitiems labai suspaudžiamiems) naudojimo atvejams, tačiau kitu atveju dažnai sukelia procesoriaus problemų – naudokite jį atsargiai, ypač aukštesniuose lygiuose.
- LZJB yra originalus ZFS algoritmas. Jis yra pasenęs ir neturėtų būti naudojamas, LZ4 jį pranoksta visais atžvilgiais.
- BLOGAI - nulinio lygio kodavimas, nulinio lygio kodavimas. Jis visiškai neliečia įprastų duomenų, bet suspaudžia dideles nulių sekas. Naudinga visiškai nesuspaudžiamiems duomenų rinkiniams (pvz., JPEG, MP4 ar kitiems jau suspaustiems formatams), nes nepaiso nesuspaudžiamų duomenų, bet suspaudžia nepanaudotą vietą gautuose įrašuose.
Mes rekomenduojame LZ4 suspaudimą beveik visais naudojimo atvejais; našumo bauda susidūrus su nesuspaudžiamais duomenimis yra labai maža ir augimas Įprastų duomenų našumas yra reikšmingas. Virtualios mašinos vaizdo kopijavimas naujam „Windows“ operacinės sistemos diegimui (naujai įdiegta OS, dar nėra duomenų) su compression=lz4 praėjo 27% greičiau nei su compression=noneĮ .
ARC – adaptyvi pakaitinė talpykla
ZFS yra vienintelė mums žinoma moderni failų sistema, kuri naudoja savo skaitymo talpyklos mechanizmą, o ne pasikliauja operacinės sistemos puslapio talpykla, kad saugotų neseniai nuskaitytų blokų kopijas RAM.
Nors savoji talpykla nėra be problemų – ZFS negali reaguoti į naujas atminties paskirstymo užklausas taip greitai kaip branduolys, todėl naujas iššūkis malloc() atminties paskirstymas gali nepavykti, jei jam reikia RAM, kurią šiuo metu užima ARC. Tačiau yra rimtų priežasčių naudoti savo talpyklą, bent jau dabar.
Visos žinomos šiuolaikinės operacinės sistemos, įskaitant „MacOS“, „Windows“, „Linux“ ir BSD, naudoja LRU (mažiausiai naudotas) algoritmą, kad įdiegtų puslapio talpyklą. Tai primityvus algoritmas, kuris po kiekvieno skaitymo stumia talpykloje saugomą bloką „aukštyn eilėje“ ir stumia blokus „žemyn eilėje“, jei reikia, kad būtų pridėta naujų talpyklos praleidimų (blokų, kurie turėjo būti nuskaityti iš disko, o ne iš talpyklos). aukštyn.
Algoritmas paprastai veikia gerai, tačiau sistemose su dideliais veikiančiais duomenų rinkiniais LRU lengvai sulaužoma – iškeldinami dažnai reikalingi blokai, kad būtų vietos blokams, kurie daugiau niekada nebus nuskaitomi iš talpyklos.
yra daug mažiau naivus algoritmas, kurį galima laikyti „svertine“ talpykla. Kiekvieną kartą, kai nuskaitomas talpykloje saugomas blokas, jis tampa šiek tiek „sunkesnis“ ir jį sunkiau iškeldinti – net ir iškeldinus bloką sekamas per tam tikrą laikotarpį. Blokas, kuris buvo iškeldintas, bet vėliau turi būti nuskaitytas atgal į talpyklą, taip pat taps „sunkesnis“.
Galutinis viso to rezultatas yra talpykla su daug didesniu pataikymo koeficientu, santykis tarp talpyklos pataikymo (nuskaitymai atliekami iš talpyklos) ir talpyklos praleidimų (skaitymai iš disko). Tai nepaprastai svarbi statistika – ne tik patys talpyklos įvykiai pateikiami daug greičiau, bet ir talpyklos praleidimai gali būti pateikiami greičiau, nes kuo daugiau talpyklos įvykių, tuo mažiau vienu metu pateikiamų disko užklausų ir tuo mažesnis tų likusių praleidimų vėlavimas. patiekiamas su disku.
išvada
Išmokę pagrindinę ZFS semantiką – kaip veikia kopijavimo ir rašymo funkcija, taip pat ryšius tarp saugyklų telkinių, virtualių įrenginių, blokų, sektorių ir failų – esame pasirengę aptarti realaus pasaulio našumą su realiais skaičiais.
Kitoje dalyje apžvelgsime tikrąjį telkinių su veidrodiniais vdevs ir RAIDz našumą, palyginti vienas su kitu, taip pat palyginti su tradicinėmis Linux branduolio RAID topologijomis, kurias ištyrėme. .
Iš pradžių norėjome aprėpti tik pagrindinius dalykus – pačias ZFS topologijas, bet vėliau tokia Pasiruoškime kalbėti apie pažangesnę ZFS sąranką ir derinimą, įskaitant pagalbinių vdev tipų, tokių kaip L2ARC, SLOG ir specialusis paskirstymas, naudojimą.
Šaltinis: www.habr.com