ProHoster > Blogs > Administrācija > ZFS pamati: glabāŔana un veiktspēja

ZFS pamati: glabāŔana un veiktspēja

ZFS pamati: glabāŔana un veiktspēja

Å opavasar jau apspriedām dažas ievada tēmas, piem. kā pārbaudÄ«t savu disku ātrumu Šø kas ir RAID. Otrajā no tiem mēs pat apsolÄ«jām turpināt pētÄ«t dažādu vairāku disku topoloÄ£iju veiktspēju ZFS. Å Ä« ir nākamās paaudzes failu sistēma, kas tagad tiek izvietota visur no Manzana lÄ«dz Ubuntu.

Nu, Å”odien ir labākā diena, lai iepazÄ«tos ar ZFS, zinātkārie lasÄ«tāji. VienkārÅ”i ziniet, ka OpenZFS izstrādātāja Meta Ahrensa pazemÄ«gajā novērtējumā "tas ir patieŔām grÅ«ti".

Bet pirms mēs nonākam pie skaitļiem - un es apsolu, ka tie būs - par visiem astoņu disku ZFS konfigurācijas variantiem mums ir jārunā par kā Kopumā ZFS saglabā datus diskā.

Zpool, vdev un ierīce

ZFS pamati: glabāŔana un veiktspēja
Šajā pilnajā pūla diagrammā ir iekļauti trīs papildu Vdevs, viens no katras klases un četri RAIDz2

ZFS pamati: glabāŔana un veiktspēja
Parasti nav iemesla izveidot neatbilstoÅ”u vdev veidu un izmēru kopu, taču, ja vēlaties, nekas neliedz jums to darÄ«t.

Lai patieŔām izprastu ZFS failu sistēmu, jums rÅ«pÄ«gi jāizpēta tās faktiskā struktÅ«ra. Pirmkārt, ZFS apvieno tradicionālos apjoma un failu sistēmas pārvaldÄ«bas slāņus. Otrkārt, tas izmanto transakciju kopÄ“Å”anas un rakstÄ«Å”anas mehānismu. Å Ä«s funkcijas nozÄ«mē, ka sistēma strukturāli ļoti atŔķiras no parastajām failu sistēmām un RAID masÄ«viem. Pirmā pamata elementu kopa, kas jāsaprot, ir krātuves baseins (zpool), virtuālā ierÄ«ce (vdev) un reālā ierÄ«ce (ierÄ«ce).

zpool

Zpool krātuves baseins ir augstākā ZFS struktÅ«ra. Katrā pÅ«lā ir viena vai vairākas virtuālās ierÄ«ces. Savukārt katrā no tām ir viena vai vairākas reālas ierÄ«ces (ierÄ«ce). Virtuālie baseini ir autonomas vienÄ«bas. Viens fiziskais dators var saturēt divus vai vairākus atseviŔķus baseinus, taču katrs ir pilnÄ«gi neatkarÄ«gs no pārējiem. PÅ«li nevar koplietot virtuālās ierÄ«ces.

ZFS dublÄ“Å”ana ir virtuālās ierÄ«ces lÄ«menÄ«, nevis pÅ«la lÄ«menÄ«. Baseina lÄ«menÄ« nav nekādas atlaiÅ”anas ā€” ja tiek pazaudēts vdev vai speciāls vdev, lÄ«dz ar to tiek zaudēts arÄ« viss pÅ«ls.

MÅ«sdienu krātuves pÅ«li var izturēt virtuālās ierÄ«ces keÅ”atmiņas vai žurnāla zaudÄ“Å”anu, lai gan tie var zaudēt nelielu daudzumu netÄ«ro datu, ja tie pazaudē vdev žurnālu strāvas padeves pārtraukuma vai sistēmas avārijas laikā.

Pastāv izplatīts nepareizs uzskats, ka ZFS "datu svītras" ir rakstītas visā baseinā. Tā nav taisnība. Zpool nav smieklīgs RAID0, tas ir vairāk smieklīgs JBOD ar sarežģītu mainīgu sadales mehānismu.

Lielākoties ieraksti tiek sadalÄ«ti starp pieejamajām virtuālajām ierÄ«cēm atbilstoÅ”i pieejamajai brÄ«vajai vietai, tāpēc teorētiski tie visi tiks aizpildÄ«ti vienlaicÄ«gi. Jaunākās ZFS versijās tiek ņemts vērā paÅ”reizējais vdev lietojums (iznÄ«cināŔana) ā€” ja viena virtuālā ierÄ«ce ir ievērojami noslogotāka par citu (piemēram, lasÄ«Å”anas slodzes dēļ), tā tiks Ä«slaicÄ«gi izlaista rakstÄ«Å”anai, neskatoties uz to, ka tai ir visaugstākā brÄ«vās vietas attiecÄ«ba. .

MÅ«sdienu ZFS rakstÄ«Å”anas pieŔķirÅ”anas metodēs iebÅ«vētais otrreizējās pārstrādes noteikÅ”anas mehānisms var samazināt latentumu un palielināt caurlaidspēju neparasti lielas slodzes periodos, taču tas tā nav carte blanche lÄ«dz patvaļīgai lēnu HDD un ātro SSD sajaukÅ”anai vienā baseinā. Šāds nevienlÄ«dzÄ«gs baseins joprojām darbosies ar lēnākās ierÄ«ces ātrumu, tas ir, it kā tas pilnÄ«bā sastāvētu no Ŕādām ierÄ«cēm.

vdev

Katrs krātuves kopums sastāv no vienas vai vairākām virtuālajām ierÄ«cēm (vdev). Savukārt katrs vdev ietver vienu vai vairākas reālas ierÄ«ces. Lielākā daļa virtuālo ierīču tiek izmantotas vienkārÅ”ai datu glabāŔanai, taču ir vairākas vdev palÄ«gu klases, tostarp CACHE, LOG un SPECIAL. Katram no Å”iem vdev tipiem var bÅ«t viena no piecām topoloÄ£ijām: vienas ierÄ«ces, RAIDz1, RAIDz2, RAIDz3 vai spogulis.

RAIDz1, RAIDz2 un RAIDz3 ir Ä«paÅ”as Ŕķirnes, ko vecie ļaudis dēvētu par dubultās (diagonālās) paritātes RAID. 1, 2 un 3 attiecas uz to, cik paritātes bloku ir pieŔķirti katrai datu joslai. Tā vietā, lai nodroÅ”inātu atseviŔķu disku paritāti, virtuālās RAIDz ierÄ«ces sadala paritāti daļēji vienmērÄ«gi pa diskiem. RAIDz masÄ«vs var zaudēt tik daudz disku, cik tam ir paritātes bloki; ja tas zaudēs vēl vienu, tas neizdosies un paņems sev lÄ«dzi krātuves baseinu.

Spoguļa virtuālajās ierÄ«cēs (spoguļa vdev) katrs bloks tiek saglabāts katrā vdev ierÄ«cē. Lai gan visizplatÄ«tākie ir divu platumu spoguļi, spogulis var saturēt jebkuru ierīču skaitu ā€” lielās instalācijās bieži izmanto trÄ«skārÅ”us, lai uzlabotu lasÄ«Å”anas veiktspēju un kļūdu toleranci. Vdev spogulis var izturēt jebkuru kļūmi, ja vien darbojas vismaz viena vdev ierÄ«ce.

AtseviŔķi Vdevi pēc bÅ«tÄ«bas ir bÄ«stami. Šāda virtuāla ierÄ«ce neizdzÄ«vos vienu kļūmi - un, ja to izmantos kā krātuvi vai Ä«paÅ”u vdev, tad tās kļūme novedÄ«s pie visa baseina iznÄ«cināŔanas. Esiet Å”eit ļoti, ļoti uzmanÄ«gi.

CACHE, LOG un SPECIAL virtuālās ierÄ«ces var izveidot jebkurā no iepriekÅ” minētajām topoloÄ£ijām, taču atcerieties, ka ÄŖPAÅ AS virtuālās ierÄ«ces pazaudÄ“Å”ana nozÄ«mē pÅ«la zaudÄ“Å”anu, tāpēc ļoti ieteicama ir lieka topoloÄ£ija.

ierīce

Tas, iespējams, ir visvieglāk saprotamais termins ZFS ā€” tā burtiski ir bloķēta brÄ«vpiekļuves ierÄ«ce. Atcerieties, ka virtuālās ierÄ«ces veido atseviŔķas ierÄ«ces, un pÅ«ls sastāv no virtuālajām ierÄ«cēm.

Magnētiskie vai cietvielu diski ir visizplatÄ«tākās blokierÄ«ces, ko izmanto kā vdev pamatelementus. Taču derēs jebkura ierÄ«ce, kuras deskriptors mapē /dev ā€” tādējādi veselus aparatÅ«ras RAID masÄ«vus var izmantot kā atseviŔķas ierÄ«ces.

VienkārÅ”s neapstrādāts fails ir viena no svarÄ«gākajām alternatÄ«vajām bloku ierÄ«cēm, no kuras var izveidot vdev. Testa baseini no reti faili ir ļoti ērts veids, kā pārbaudÄ«t pÅ«la komandas un redzēt, cik daudz vietas ir pieejamas noteiktās topoloÄ£ijas baseinā vai virtuālajā ierÄ«cē.

ZFS pamati: glabāŔana un veiktspēja
Varat izveidot testa pūlu no retajiem failiem tikai dažu sekunžu laikā, taču neaizmirstiet pēc tam izdzēst visu pūlu un tā komponentus.

Pieņemsim, ka vēlaties astoņu disku serveri un plānojat izmantot 10 TB (~ 9300 GiB) diskus, taču neesat pārliecināts, kura topoloÄ£ija vislabāk atbilst jÅ«su vajadzÄ«bām. IepriekÅ” minētajā piemērā mēs dažu sekunžu laikā izveidojam testa pÅ«lu no retajiem failiem ā€” un tagad mēs zinām, ka RAIDz2 vdev ar astoņiem 10 TB diskiem nodroÅ”ina 50 TiB izmantojamās ietilpÄ«bas.

Vēl viena Ä«paÅ”a ierīču klase ir SPARE. Hot-swap ierÄ«ces, atŔķirÄ«bā no parastajām ierÄ«cēm, pieder visam kopumam, nevis vienai virtuālai ierÄ«cei. Ja kāds pÅ«la vdev neizdodas un rezerves ierÄ«ce ir pievienota pÅ«lam un ir pieejama, tā automātiski pievienosies ietekmētajam vdev.

Kad ir izveidots savienojums ar ietekmēto vdev, rezerves ierÄ«ce sāk saņemt to datu kopijas vai rekonstrukcijas, kuriem vajadzētu bÅ«t trÅ«kstoÅ”ajā ierÄ«cē. Tradicionālajā RAID to sauc par "pārbÅ«vi", un ZFS to sauc par "pārveidoÅ”anu".

Ir svarÄ«gi atzÄ«mēt, ka rezerves ierÄ«ces neatgriezeniski neaizstāj bojātas ierÄ«ces. Tas ir tikai pagaidu nomaiņa, lai samazinātu laiku, kas nepiecieÅ”ams vdev degradācijai. Pēc tam, kad administrators ir nomainÄ«jis neveiksmÄ«go vdev ierÄ«ci, Å”ai pastāvÄ«gajai ierÄ«cei tiek atjaunota dublÄ“Å”ana, un SPARE tiek atvienots no vdev un atgriežas kā rezerves ierÄ«ce visam pÅ«lam.

Datu kopas, bloki un sektori

Nākamais pamatelementu kopums, kas jāizprot mÅ«su ZFS ceļojumā, ir mazāk saistÄ«ts ar aparatÅ«ru, bet vairāk ar to, kā tiek organizēti un uzglabāti paÅ”i dati. Å eit mēs izlaižam dažus slāņus, piemēram, metaslab, lai izvairÄ«tos no detaļu pārblÄ«vÄ“Å”anas, vienlaikus saglabājot izpratni par vispārējo struktÅ«ru.

Datu kopa

ZFS pamati: glabāŔana un veiktspēja
Kad mēs pirmo reizi izveidojam datu kopu, tajā tiek parādÄ«ta visa pieejamā baseina vieta. Tad mēs iestatām kvotu un mainām piestiprināŔanas punktu. MaÄ£ija!

ZFS pamati: glabāŔana un veiktspēja
Zvol pārsvarā ir tikai datu kopa, kurai ir noņemts failu sistēmas slānis, kuru mēs Å”eit aizstājam ar pilnÄ«gi normālu ext4 failu sistēmu.

ZFS datu kopa ir aptuveni tāda pati kā standarta uzstādÄ«tā failu sistēma. Tāpat kā parasta failu sistēma, no pirmā acu uzmetiena Ŕķiet, ka tā ir ā€œtikai vēl viena mapeā€. Bet, tāpat kā parastajām pievienotajām failu sistēmām, katrai ZFS datu kopai ir savs pamata rekvizÄ«tu kopums.

Pirmkārt, datu kopai var bÅ«t pieŔķirta kvota. Ja instalējat zfs set quota=100G poolname/datasetname, tad nevarēsit rakstÄ«t pievienotajā mapē /poolname/datasetname vairāk nekā 100 GiB.

Vai ievērojat slÄ«psvÄ«tru esamÄ«bu un neesamÄ«bu katras rindas sākumā? Katrai datu kopai ir sava vieta gan ZFS hierarhijā, gan sistēmas stiprinājuma hierarhijā. ZFS hierarhijā nav slÄ«psvÄ«tras ā€” jÅ«s sākat ar pÅ«la nosaukumu un pēc tam ceļu no vienas datu kopas uz nākamo. Piemēram, pool/parent/child datu kopai ar nosaukumu child zem vecākdatu kopas parent baseinā ar radoÅ”u nosaukumu pool.

Pēc noklusējuma datu kopas pievienoÅ”anas punkts bÅ«s lÄ«dzvērtÄ«gs tās nosaukumam ZFS hierarhijā ar slÄ«psvÄ«tru sākumā ā€” kopas nosaukums pool uzstādÄ«ts kā /pool, datu kopa parent uzstādÄ«ts iekŔā /pool/parentun bērna datu kopu child uzstādÄ«ts iekŔā /pool/parent/child. Tomēr datu kopas sistēmas stiprinājuma punktu var mainÄ«t.

Ja mēs norādām zfs set mountpoint=/lol pool/parent/child, tad datu kopa pool/parent/child uzstādīts sistēmā kā /lol.

Papildus datu kopām jāmin apjomi (zvols). Sējums ir aptuveni tāds pats kā datu kopa, izņemot to, ka tam faktiski nav failu sistēmas ā€” tā ir tikai bloka ierÄ«ce. Piemēram, varat izveidot zvol Ar nosaukumu mypool/myzvol, pēc tam formatējiet to ar ext4 failu sistēmu un pēc tam pievienojiet Å”o failu sistēmu ā€” tagad jums ir ext4 failu sistēma, taču ar visiem ZFS droŔības lÄ«dzekļiem! Tas var Ŕķist muļķīgi vienā datorā, taču tas ir daudz saprātÄ«gāks kā aizmugursistēma, eksportējot iSCSI ierÄ«ci.

Bloki

ZFS pamati: glabāŔana un veiktspēja
Failu attēlo viens vai vairāki bloki. Katrs bloks tiek saglabāts vienā virtuālajā ierīcē. Bloka izmērs parasti ir vienāds ar parametru rekordlielums, bet to var samazināt līdz 2^ashift, ja tajā ir metadati vai neliels fails.

ZFS pamati: glabāŔana un veiktspēja
Mēs tieŔām tieŔām Mēs nejokojam par milzÄ«go sodu par veiktspēju, ja iestatāt pārāk zemu pārbÄ«di

ZFS pÅ«lā visi dati, tostarp metadati, tiek glabāti blokos. Maksimālais bloka lielums katrai datu kopai ir definēts Ä«paÅ”umā recordsize (rekordizmērs). Ieraksta lielums var mainÄ«ties, taču tas nemainÄ«s neviena bloka lielumu vai atraÅ”anās vietu, kas jau ir ierakstÄ«ta datu kopā ā€” tas ietekmē tikai jaunus blokus, kad tie tiek ierakstÄ«ti.

Ja nav norādÄ«ts citādi, paÅ”reizējais noklusējuma ieraksta lielums ir 128 KiB. Tas ir sava veida grÅ«ts kompromiss, kurā sniegums nebÅ«s ideāls, taču vairumā gadÄ«jumu tas nebÅ«s briesmÄ«gi. Recordsize var iestatÄ«t uz jebkuru vērtÄ«bu no 4K lÄ«dz 1M (ar papildu iestatÄ«jumiem recordsize varat instalēt vēl vairāk, taču tā reti ir laba ideja).

JebkurÅ” bloks attiecas tikai uz viena faila datiem ā€” jÅ«s nevarat saspiest divus dažādus failus vienā blokā. Katrs fails sastāv no viena vai vairākiem blokiem atkarÄ«bā no tā lieluma. Ja faila lielums ir mazāks par ieraksta lielumu, tas tiks saglabāts mazākā blokā ā€“ piemēram, bloks ar 2 KiB failu aizņems tikai vienu 4 kiB sektoru diskā.

Ja fails ir pietiekami liels, lai prasÄ«tu vairākus blokus, visi Ŕī faila ieraksti bÅ«s lieli recordsize - ieskaitot pēdējo ierakstu, kura galvenā daļa var bÅ«t neizmantota telpa.

zvol sējumiem Ä«paÅ”uma nav recordsize - tā vietā viņiem ir lÄ«dzvērtÄ«gs Ä«paÅ”ums volblocksize.

Sektori

Pēdējais, visvienkārŔākais elements ir sektors. Tā ir mazākā fiziskā vienÄ«ba, ko var ierakstÄ«t resursdatorā vai nolasÄ«t no tās. Vairākas desmitgades lielākajā daļā disku tika izmantoti 512 baitu sektori. MÅ«sdienās lielākā daļa disku ir konfigurēti 4 KiB sektoriem, un daži ā€“ Ä«paÅ”i SSD ā€“ ir konfigurēti 8 KiB vai pat lielākiem sektoriem.

ZFS ir funkcija, kas ļauj manuāli iestatÄ«t sektora izmēru. Å is Ä«paÅ”ums ashift. Nedaudz mulsinoÅ”i, ashift ir divu jauda. Piemēram, ashift=9 nozÄ«mē sektora lielumu 2^9 jeb 512 baiti.

ZFS pieprasa operētājsistēmai detalizētu informāciju par katru blokierÄ«ci, kad tā tiek pievienota jaunam vdev, un teorētiski automātiski iestata ashift atbilstoÅ”i, pamatojoties uz Å”o informāciju. Diemžēl daudzi diskdziņi melo par sava sektora lielumu, lai saglabātu saderÄ«bu ar Windows XP (kas nespēja saprast diskus ar cita lieluma sektoru).

Tas nozÄ«mē, ka ZFS administratoram ir ļoti ieteicams zināt savu ierīču faktisko sektora lielumu un manuāli iestatÄ«t ashift. Ja pārbÄ«de ir iestatÄ«ta pārāk maza, lasÄ«Å”anas/rakstÄ«Å”anas operāciju skaits astronomiski palielinās. Tātad 512 baitu "sektoru" rakstÄ«Å”ana reālam 4 KiB sektoram nozÄ«mē, ka ir jāieraksta pirmais "sektors", pēc tam jāizlasa 4 KiB sektors, jāmaina tas ar otru 512 baitu "sektoru", jāraksta atpakaļ uz jauno. 4 KiB sektors un tā tālāk katram ierakstam.

Reālajā pasaulē Ŕāds sods ietekmē Samsung EVO SSD, uz kuriem tas bÅ«tu jāattiecina ashift=13, taču Å”ie SSD melo par to sektora lielumu, un tāpēc noklusējuma vērtÄ«ba ir iestatÄ«ta uz ashift=9. Ja vien pieredzējis sistēmas administrators nemaina Å”o iestatÄ«jumu, Å”is SSD darbojas lēnāk parastais magnētiskais HDD.

SalÄ«dzinājumam, par lielu ashift soda praktiski nav. Nav reāla veiktspējas trāpÄ«juma, un neizmantotās vietas pieaugums ir bezgalÄ«gi neliels (vai nulle, ja ir iespējota saspieÅ”ana). Tāpēc mēs ļoti iesakām instalēt pat tos diskus, kas izmanto 512 baitu sektorus ashift=12 vai pat ashift=13ar pārliecÄ«bu raudzÄ«ties nākotnē.

ÄŖpaÅ”ums ashift ir instalēta katrai virtuālajai ierÄ«cei vdev, un ne baseinam, kā daudzi cilvēki kļūdaini domā - un pēc instalÄ“Å”anas nemainās. Ja nejauÅ”i trāpÄ«ja ashift Kad baseinam pievienojat jaunu vdev, jÅ«s esat neatgriezeniski piesārņojis Å”o baseinu ar zemas veiktspējas ierÄ«ci, un parasti nav citas iespējas, kā iznÄ«cināt baseinu un sākt no jauna. Pat vdev dzÄ“Å”ana neglābs jÅ«s no bojāta iestatÄ«juma ashift!

KopÄ“Å”anas uz rakstÄ«Å”anas mehānisms

ZFS pamati: glabāŔana un veiktspēja
Ja parastajai failu sistēmai ir jāpārraksta dati, tā modificē katru bloku, kur tas atrodas

ZFS pamati: glabāŔana un veiktspēja
KopÄ“Å”anas un rakstÄ«Å”anas failu sistēma ieraksta jaunu bloka versiju un pēc tam atbloķē veco versiju

ZFS pamati: glabāŔana un veiktspēja
Abstrakti, ja mēs ignorējam bloku faktisko fizisko izvietojumu, mÅ«su ā€œdatu komētaā€ vienkārÅ”ojas lÄ«dz ā€œdatu tārpamā€, kas pārvietojas no kreisās puses uz labo pieejamās telpas kartē.

ZFS pamati: glabāŔana un veiktspēja
Tagad mēs varam iegÅ«t labu priekÅ”statu par kopÄ“Å”anas un rakstÄ«Å”anas momentuzņēmumu darbÄ«bu ā€” katrs bloks var piederēt vairākiem momentuzņēmumiem, un tas saglabāsies, lÄ«dz tiks iznÄ«cināti visi saistÄ«tie momentuzņēmumi.

Copy on Write (CoW) mehānisms ir galvenais pamats tam, kas padara ZFS par tik pārsteidzoÅ”u sistēmu. Pamatjēdziens ir vienkārÅ”s ā€“ ja jÅ«s lÅ«dzat tradicionālajai failu sistēmai mainÄ«t failu, tā darÄ«s tieÅ”i to, ko lÅ«dzāt. Ja prasÄ«sit kopÄ“Å”anas-uzrakstÄ«Å”anas failu sistēmai izdarÄ«t to paÅ”u, tā pateiks ā€œlabiā€, taču tā jums melos.

Tā vietā kopÄ“Å”anas un rakstÄ«Å”anas failu sistēma ieraksta jaunu modificētā bloka versiju un pēc tam atjaunina faila metadatus, lai atsaistÄ«tu veco bloku un saistÄ«tu to ar jauno bloku, kuru tikko uzrakstÄ«jāt.

Vecā bloka atsaistÄ«Å”ana un jaunā bloka saistÄ«Å”ana tiek veikta ar vienu darbÄ«bu, tāpēc to nevar pārtraukt - ja atiestatÄ«sit baroÅ”anu pēc tam, kad tas ir noticis, jums ir jauna faila versija, un, ja jÅ«s atiestatāt baroÅ”anu iepriekÅ”, tad jums ir vecā versija. Jebkurā gadÄ«jumā failu sistēmā nebÅ«s konfliktu.

KopÄ“Å”ana uz rakstÄ«Å”anas ZFS notiek ne tikai failu sistēmas lÄ«menÄ«, bet arÄ« diska pārvaldÄ«bas lÄ«menÄ«. Tas nozÄ«mē, ka ZFS ierakstā nav jutÄ«gs pret atstarpēm (caurums RAID) ā€” parādÄ«ba, kad josla tika ierakstÄ«ta tikai daļēji pirms sistēmas avārijas, un masÄ«vs tika bojāts pēc pārstartÄ“Å”anas. Å eit svÄ«tra ir rakstÄ«ta atomiski, vdev vienmēr ir secÄ«ga, un Bobs ir tavs onkulis.

ZIL: ZFS nodomu žurnāls

ZFS pamati: glabāŔana un veiktspēja
ZFS apstrādā sinhrono ierakstu Ä«paŔā veidā - tas uz laiku, bet nekavējoties saglabā tos ZIL, pirms vēlāk tos pastāvÄ«gi ieraksta kopā ar asinhronajiem rakstiem.

ZFS pamati: glabāŔana un veiktspēja
Parasti ZIL ierakstītie dati nekad netiek atkārtoti lasīti. Bet tas ir iespējams pēc sistēmas kļūmes

ZFS pamati: glabāŔana un veiktspēja
SLOG jeb sekundārā LOG ierÄ«ce ir vienkārÅ”i Ä«paÅ”s un vēlams ļoti ātrs vdev, kurā ZIL var glabāt atseviŔķi no galvenās krātuves.

ZFS pamati: glabāŔana un veiktspēja
Pēc avārijas visi netÄ«rie dati ZIL tiek atskaņoti atkārtoti ā€” Å”ajā gadÄ«jumā ZIL ir ieslēgts SLOG, tāpēc tas tiek atskaņots tur.

Ir divas galvenās rakstÄ«Å”anas kategorijas: sinhronā (sinhronā) un asinhronā (asinhronā). Lielākajai daļai darba slodžu lielākā daļa ierakstu ir asinhroni ā€” failu sistēma ļauj tos apkopot un izdot pa daļām, samazinot sadrumstalotÄ«bu un ievērojami palielinot caurlaidspēju.

Sinhronie ieraksti ir pavisam cita lieta. Kad lietojumprogramma pieprasa sinhronu rakstÄ«Å”anu, tā paziņo failu sistēmai: "Jums tas ir jāievieto nemainÄ«gā atmiņā tieÅ”i tagad, un lÄ«dz tam es neko vairāk nevaru darÄ«t. Tāpēc sinhronā rakstÄ«Å”ana nekavējoties jāievieto diskā ā€” un, ja tas palielina sadrumstalotÄ«bu vai samazina caurlaidspēju, lai tā bÅ«tu.

ZFS apstrādā sinhrono rakstÄ«Å”anu savādāk nekā parastās failu sistēmas ā€” tā vietā, lai nekavējoties izskalotu tos parastajā krātuvē, ZFS ievieto tos Ä«paŔā krātuves apgabalā, ko sauc par ZFS nolÅ«ku žurnālu jeb ZIL. ViltÄ«ba ir tāda, ka Å”ie ieraksti arÄ« paliek atmiņā, tiek apkopoti kopā ar parastajiem asinhronās rakstÄ«Å”anas pieprasÄ«jumiem, lai vēlāk tiktu izskaloti krātuvē kā pilnÄ«gi parastas TXG (transakciju grupas).

Normālas darbības laikā ZIL tiek rakstīts un nekad vairs netiek lasīts. Kad pēc dažiem mirkļiem ZIL ieraksti tiek ievietoti galvenajā krātuvē parastajos TXG no RAM, tie tiek atdalīti no ZIL. Vienīgais gadījums, kad kaut kas tiek nolasīts no ZIL, ir, importējot pūlu.

Ja notiek ZFS kļūme ā€” operētājsistēmas avārija vai strāvas padeves pārtraukums ā€”, kamēr ZIL ir dati, Å”ie dati tiks nolasÄ«ti nākamās pÅ«la importÄ“Å”anas laikā (piemēram, kad tiek restartēta kļūmjpārlēces sistēma). Viss, kas atrodas ZIL, tiks nolasÄ«ts, sagrupēts TXG, pievienots galvenajam veikalam un pēc tam importÄ“Å”anas procesa laikā atdalÄ«ts no ZIL.

Viena no vdev palÄ«gu klasēm tiek saukta par LOG vai SLOG, sekundāro LOG ierÄ«ci. Tam ir viens uzdevums - nodroÅ”ināt baseinu ar atseviŔķu un, vēlams, daudz ātrāku, ar ļoti augstu rakstÄ«Å”anas pretestÄ«bu, vdev ierÄ«ci ZIL glabāŔanai, nevis glabāt ZIL galvenajā vdev krātuvē. Pats ZIL uzvedas vienādi neatkarÄ«gi no uzglabāŔanas vietas, bet, ja vdev ar LOG ir ļoti augsta rakstÄ«Å”anas veiktspēja, tad sinhronā rakstÄ«Å”ana bÅ«s ātrāka.

Vdev ar LOG pievienoÅ”ana pÅ«lam nedarbojas nevar uzlabot asinhronās rakstÄ«Å”anas veiktspēju - pat ja jÅ«s piespiežat visas rakstÄ«Å”anas uz ZIL ar zfs set sync=always, tie joprojām bÅ«s saistÄ«ti ar galveno TXG krātuvi tādā paŔā veidā un tādā paŔā tempā kā bez žurnāla. VienÄ«gais tieÅ”ais veiktspējas uzlabojums ir sinhronais rakstÄ«Å”anas latentums (jo lielāks žurnāla ātrums padara darbÄ«bas ātrākas sync).

Tomēr vidē, kurā jau ir nepiecieÅ”ams daudz sinhrono ierakstu, vdev LOG var netieÅ”i paātrināt asinhrono rakstÄ«Å”anu un nekeÅ”atmiņā saglabāto lasÄ«Å”anu. ZIL ierakstu izkrauÅ”ana atseviŔķā vdev LOG nozÄ«mē mazāku strÄ«du par IOPS primārajā krātuvē, kas zināmā mērā uzlabo visu lasÄ«Å”anas un rakstÄ«Å”anas veiktspēju.

Momentuzņēmumi

KopÄ“Å”anas un rakstÄ«Å”anas mehānisms ir arÄ« nepiecieÅ”ams pamats ZFS atomu momentuzņēmumiem un pakāpeniskai asinhronai replikācijai. AktÄ«vajai failu sistēmai ir rādÄ«tāja koks, kas atzÄ«mē visus ierakstus ar paÅ”reizējiem datiem ā€” veicot momentuzņēmumu, jÅ«s vienkārÅ”i izveidojat Ŕī rādÄ«tāja koka kopiju.

Kad ieraksts tiek pārrakstÄ«ts aktÄ«vajā failu sistēmā, ZFS vispirms ieraksta jauno bloka versiju neizmantotā vietā. Pēc tam atdala bloka veco versiju no paÅ”reizējās failu sistēmas. Bet, ja kāds momentuzņēmums atsaucas uz vecu bloku, tas joprojām paliek nemainÄ«gs. Vecais bloks faktiski netiks atjaunots kā brÄ«va vieta, kamēr netiks iznÄ«cināti visi momentuzņēmumi, kas atsaucas uz Å”o bloku!

Replikācija

ZFS pamati: glabāŔana un veiktspēja
Mana Steam bibliotēka 2015. gadā bija 158 GiB, un tajā bija 126 927 faili. Tas ir diezgan tuvu rsync optimālajai situācijai - ZFS replikācija tīklā bija "tikai" par 750% ātrāka.

ZFS pamati: glabāŔana un veiktspēja
Tajā paŔā tÄ«klā viena 40 GB Windows 7 virtuālās maŔīnas attēla faila replicÄ“Å”ana ir pavisam cits stāsts. ZFS replikācija ir 289 reizes ātrāka nekā rsync ā€” vai ā€œtikaiā€ 161 reizi ātrāka, ja esat pietiekami gudrs, lai izsauktu rsync, izmantojot slēdzi --inplace.

ZFS pamati: glabāŔana un veiktspēja
Kad VM attēls tiek mērogots, rsync problēmas ar to mērogo. 1,9 TiB izmērs nav tik liels mÅ«sdienu virtuālās maŔīnas attēlam, taču tas ir pietiekami liels, lai ZFS replikācija bÅ«tu 1148 reizes ātrāka nekā rsync, pat ar argumentu rsync --inplace.

Kad bÅ«sit sapratis, kā darbojas momentuzņēmumi, bÅ«s viegli saprast replikācijas bÅ«tÄ«bu. Tā kā momentuzņēmums ir vienkārÅ”i ierakstu norādes koks, no tā izriet, ka, ja mēs to darām zfs send momentuzņēmums, tad mēs nosÅ«tām Å”o koku un visus ar to saistÄ«tos ierakstus. Kad mēs izturēsim Å”o zfs send Š² zfs receive mērÄ·a objektā tas ieraksta gan faktisko bloka saturu, gan rādÄ«tāju koku, kas atsaucas uz blokiem uz mērÄ·a datu kopu.

Otrajā viss kļūst vēl interesantāks zfs send. Tagad mums ir divas sistēmas, no kurām katra satur poolname/datasetname@1, un jÅ«s uzņemat jaunu momentuzņēmumu poolname/datasetname@2. Tāpēc jÅ«su avota baseinā datasetname@1 Šø datasetname@2, un mērÄ·a pÅ«lā ir tikai pirmais momentuzņēmums datasetname@1.

Jo starp avotu un mērÄ·i mums ir kopÄ«gs momentuzņēmums datasetname@1, mēs to varam papildu zfs send tam virsÅ«. Kad mēs sakām sistēmai zfs send -i poolname/datasetname@1 poolname/datasetname@2, tas salÄ«dzina divus rādÄ«tāju kokus. Visas norādes, kas pastāv tikai @2, protams, attiecas uz jauniem blokiem ā€” tāpēc mums bÅ«s nepiecieÅ”ams Å”o bloku saturs.

Attālā sistēmā, apstrāde pakāpeniski send tikpat vienkārÅ”i. Vispirms mēs ierakstām visus straumē iekļautos jaunos ierakstus sendun pēc tam pievienojiet norādes Å”iem blokiem. Voila, mums ir @2 jaunajā sistēmā!

ZFS asinhronā inkrementālā replikācija ir milzÄ«gs uzlabojums salÄ«dzinājumā ar iepriekŔējām metodēm, kas nav balstÄ«tas uz momentuzņēmumiem, piemēram, rsync. Abos gadÄ«jumos tiek pārsÅ«tÄ«ti tikai mainÄ«tie dati, taču vispirms ir jāveic rsync lasÄ«t no diska visus datus abās pusēs, lai pārbaudÄ«tu summu un salÄ«dzinātu to. Turpretim ZFS replikācija nelasa neko citu kā tikai rādÄ«tāju kokus un visus blokus, kas nav attēloti kopējā momentuzņēmumā.

Iebūvēta kompresija

KopÄ“Å”anas-uz-rakstÄ«Å”anas mehānisms arÄ« vienkārÅ”o iebÅ«vēto saspieÅ”anas sistēmu. Tradicionālā failu sistēmā saspieÅ”ana ir problemātiska - gan vecā versija, gan jaunā mainÄ«to datu versija atrodas vienā telpā.

Ja uzskatāt, ka faila vidÅ« ir datu fragments, kas sāk darboties kā nulles megabaits no 0x00000000 un tā tālāk, to ir ļoti viegli saspiest vienā diska sektorā. Bet kas notiks, ja Å”o nulles megabaitu aizstāsim ar megabaitu nesaspiežamu datu, piemēram, JPEG vai pseidogadÄ«juma troksni? PēkŔņi Å”im datu megabaitam bÅ«s nepiecieÅ”ams nevis viens, bet 256 4 KiB sektori, un Å”ajā diska vietā ir rezervēts tikai viens sektors.

ZFS Ŕīs problēmas nav, jo modificētie ieraksti vienmēr tiek ierakstÄ«ti neizmantotā vietā - sākotnējais bloks aizņem tikai vienu 4 KiB sektoru, un jauna ierakstÄ«Å”ana aizņems 256, taču tā nav problēma - nesen modificēts fragments no faila "vidus" tiktu ierakstÄ«ts neizmantotā vietā neatkarÄ«gi no tā, vai tā lielums ir mainÄ«jies vai nē, tāpēc tā ir pilnÄ«gi normāla situācija ZFS.

IebÅ«vētā ZFS saspieÅ”ana pēc noklusējuma ir atspējota, un sistēma piedāvā pievienojamus algoritmus, tostarp LZ4, gzip (1-9), LZJB un ZLE.

  • LZ4 ir straumÄ“Å”anas algoritms, kas piedāvā ārkārtÄ«gi ātru saspieÅ”anu un dekompresiju, kā arÄ« veiktspējas priekÅ”rocÄ«bas vairumam lietoÅ”anas gadÄ«jumu ā€” pat ar diezgan lēniem CPU.
  • GZIP ir cienÄ«jams algoritms, ko zina un mÄ«l visi Unix lietotāji. To var ieviest ar saspieÅ”anas lÄ«meni no 1 lÄ«dz 9, palielinot saspieÅ”anas pakāpi un CPU lietojumu, tuvojoties 9. lÄ«menim. Algoritms ir labi piemērots visiem teksta (vai citiem ļoti saspiežamiem) lietoÅ”anas gadÄ«jumiem, taču bieži vien rada CPU problēmas pretējā gadÄ«jumā - izmantojiet to piesardzÄ«gi, Ä«paÅ”i augstākā lÄ«menÄ«.
  • LZJB - oriÄ£ināls algoritms ZFS. Tas ir novecojis un vairs nevajadzētu lietot, LZ4 ir visādā ziņā pārāks.
  • SLIKTI ā€” nulles lÄ«meņa kodējums, nulles lÄ«meņa kodējums. Tas vispār neskar parastos datus, bet saspiež lielas nulles. NoderÄ«ga pilnÄ«bā nesaspiežamām datu kopām (piemēram, JPEG, MP4 vai citiem jau saspiestiem formātiem), jo tā ignorē nesaspiežamos datus, bet saspiež neizmantoto vietu iegÅ«tajos ierakstos.

Mēs iesakām LZ4 kompresiju gandrÄ«z visos lietoÅ”anas gadÄ«jumos; veiktspējas sods, strādājot ar nesaspiežamiem datiem, ir ļoti mazs, un izaugsmi tipisku datu veiktspēja ir nozÄ«mÄ«ga. Virtuālās maŔīnas attēla kopÄ“Å”ana jaunai Windows operētājsistēmas instalÄ“Å”anai (svaigi instalēta operētājsistēma, pagaidām nav datu) ar compression=lz4 pagāja par 27% ātrāk nekā ar compression=noneUz Å”is tests no 2015.

ARC - adaptÄ«vā nomaiņas keÅ”atmiņa

ZFS ir vienÄ«gā mums zināmā modernā failu sistēma, kas izmanto savu lasÄ«Å”anas keÅ”atmiņas mehānismu, nevis paļaujas uz operētājsistēmas lapas keÅ”atmiņu, lai saglabātu nesen lasÄ«to bloku kopijas RAM.

Lai gan vietējā keÅ”atmiņa nav bez problēmām, ZFS nevar atbildēt uz jauniem atmiņas pieŔķirÅ”anas pieprasÄ«jumiem tikpat ātri kā kodols, tāpēc jauns izsaukums malloc() atmiņas pieŔķirÅ”ana var neizdoties, ja tai nepiecieÅ”ama RAM, ko paÅ”laik aizņem ARC. Bet ir labi iemesli, lai vismaz Å”obrÄ«d izmantotu savu keÅ”atmiņu.

Visas zināmās mÅ«sdienu operētājsistēmas, tostarp MacOS, Windows, Linux un BSD, izmanto LRU (vismazāk izmantoto) algoritmu, lai ieviestu lapas keÅ”atmiņu. Å is ir primitÄ«vs algoritms, kas pēc katras lasÄ«Å”anas nospiež keÅ”atmiņā saglabāto bloku "rindas augÅ”daļā" un pēc vajadzÄ«bas nospiež blokus "rindas apakŔā", lai pievienotu jaunas keÅ”atmiņas kļūdas (blokus, kas bÅ«tu jālasa no diska, nevis no keÅ”atmiņas) uz augÅ”u.

Parasti algoritms darbojas labi, taču sistēmās ar lielām darba datu kopām LRU viegli noved pie sagrauÅ”anas ā€” tiek izspiesti bieži nepiecieÅ”amie bloki, lai atbrÄ«votu vietu blokiem, kas nekad vairs netiks nolasÄ«ti no keÅ”atmiņas.

ARC ir daudz mazāk naivs algoritms, ko var uzskatÄ«t par ā€œsvērtuā€ keÅ”atmiņu. Katru reizi, kad tiek nolasÄ«ts keÅ”atmiņā saglabāts bloks, tas kļūst nedaudz smagāks un grÅ«tāk izlikt, un pat pēc bloka izlikÅ”anas izsekots noteiktā laika periodā. Bloks, kas ir izlikts, bet pēc tam jālasa atpakaļ keÅ”atmiņā, arÄ« kļūs smagāks.

Tā visa gala rezultāts ir keÅ”atmiņa ar daudz augstāku trāpÄ«jumu attiecÄ«bu ā€” attiecÄ«ba starp keÅ”atmiņas trāpÄ«jumiem (nolasÄ«ti no keÅ”atmiņas) un garām (nolasÄ«ti no diska). Å Ä« ir ārkārtÄ«gi svarÄ«ga statistika ā€” ne tikai paÅ”i keÅ”atmiņas trāpÄ«jumi tiek apkalpoti par lieluma kārtām ātrāk, bet arÄ« keÅ”atmiņas kļūdas var tikt apkalpotas ātrāk, jo jo vairāk ir keÅ”atmiņas trāpÄ«jumu, jo mazāk vienlaicÄ«gu pieprasÄ«jumu diskā un mazāks latentums Å”iem atlikuÅ”ajiem izlaidumiem. kas jāapkopj ar disku.

Secinājums

Tagad, kad esam apskatÄ«juÅ”i ZFS pamata semantiku ā€” kā darbojas kopÄ“Å”ana un rakstÄ«Å”ana, kā arÄ« attiecÄ«bas starp krātuves pÅ«liņiem, virtuālajām ierÄ«cēm, blokiem, sektoriem un failiem ā€” esam gatavi apspriest reālo veiktspēju ar reāli skaitļi.

Nākamajā daļā mēs apskatÄ«sim spoguļattēlu vdev un RAIDz kopu faktisko veiktspēju, salÄ«dzinot savā starpā, kā arÄ« salÄ«dzinājumā ar tradicionālajām Linux kodola RAID topoloÄ£ijām, kuras esam pārbaudÄ«juÅ”i. pirms tam.

Sākumā mēs vēlējāmies aptvert tikai pamata lietas - paÅ”as ZFS topoloÄ£ijas, bet pēc tam tāds Mēs bÅ«sim gatavi runāt par progresÄ«vāku ZFS konfigurāciju un noregulÄ“Å”anu, tostarp par vdev papildu tipu izmantoÅ”anu, piemēram, L2ARC, SLOG un Special Allocation.

Avots: www.habr.com

Pievieno komentāru