Di vê biharê de me berê jî li ser hin mijarên destpêkê nîqaş kir, wek mînak. и . Di ya duyemîn de, me tewra soz da ku em xwendina performansa cûrbecûr topolojiyên pir-dîskê yên li ZFS-ê bidomînin. Ev pergala pelê ya nifşa paşîn e ku naha li her deverê tê bicîh kirin ber .
Welê, îro roja çêtirîn e ku hûn bi ZFS, xwendevanên meraqdar re nas bikin. Tenê zanibin ku di nirxandina dilnizmî ya pêşdebirê OpenZFS Matt Ahrens de, "ew bi rastî dijwar e."
Lê berî ku em bigihîjin hejmaran - û dê hebe, ez soz didim - ji bo hemî guhertoyên veavakirina heşt-dîskê ZFS, divê em li ser biaxivin çawa Bi gelemperî, ZFS daneyên li ser dîskê hilîne.
Zpool, vdev û cîhaz
Ev diyagrama hewzê ya tevahî sê vdevên alîkar, yek ji her polê, û çar ji bo RAIDz2 vedihewîne.
Bi gelemperî sedemek tune ku meriv hewzek ji celeb û mezinahiyên vdev-ê yên lihevhatî biafirîne - lê heke hûn bixwazin, tiştek we tune ku hûn wiya bikin.
Ji bo ku hûn pergala pelê ZFS-ê bi rastî fêm bikin, hûn hewce ne ku ji nêz ve li avahiya wê ya rastîn binêrin. Pêşîn, ZFS qatên rêveberiya pergala pelê ya kevneşopî û pelan yek dike. Ya duyemîn, ew mekanîzmayek kopî-li-nivîsandinê ya danûstendinê bikar tîne. Van taybetmendiyan tê vê wateyê ku pergal ji hêla strukturel ve ji pergalên pelan ên kevneşopî û rêzikên RAID-ê pir cûda ye. Yekem komek blokên bingehîn ên ku têne fam kirin hewza hilanînê (zpool), cîhaza virtual (vdev) û cîhaza rastîn (cîhaz) ne.
zpool
Hewza hilanînê ya zpool avahiya ZFS ya herî jorîn e. Her hewzek yek an çend cîhazên virtual dihewîne. Di encamê de, her yek ji wan yek an çend amûrên rastîn (cîhaz) dihewîne. Hewzên virtual yekîneyên xweser in. Yek kompîturek laşî dikare du an zêdetir hewzên cihê hebin, lê her yek bi tevahî ji yên din serbixwe ye. Hewz nikarin cîhazên virtual parve bikin.
Zêdebûna ZFS di asta cîhaza virtual de ye, ne di asta hewzê de. Di asta hewzê de bêkêmasî zêde zêde tune - heke vdev an vdevek diyarî winda bibe, tevaya hewzê bi wê re winda dibe.
Hewzên hilanînê yên nûjen dikarin ji windabûna cache an têketinek amûrek virtual xilas bibin - her çend ew dikarin mîqdarek piçûk a daneya qirêj winda bikin heke di dema qutbûnek elektrîkê an têkçûna pergalê de têketina vdev winda bikin.
Nerazîbûnek hevpar heye ku ZFS "rêzikên daneyê" li seranserê hewzê têne nivîsandin. Ev ne rast e. Zpool ne RAID0-ek qeşeng e, ew bêtir yekî qeşeng e bi mekanîzmaya belavkirina guherbar a tevlihev.
Bi piranî, tomar li gorî cîhê belaş berdest di nav cîhazên virtual yên berdest de têne belav kirin, ji ber vê yekê di teoriyê de ew ê hemî di heman demê de bêne dagirtin. Guhertoyên nû yên ZFS-ê karanîna (hilweşandina) vdev-ê ya heyî li ber çavan digirin - heke amûrek virtual ji ya din pir mijûltir be (mînak, ji ber barkirina xwendinê), ew ê ji bo nivîsandinê bi demkî were paşguh kirin, tevî ku rêjeya cîhê belaş ya herî bilind hebe. .
Mekanîzmaya vezîvirandinê ya ku di nav awayên veqetandina nivîsandina ZFS-ya nûjen de hatî çêkirin dikare derengmayînê kêm bike û di heyamên bargiraniya ne normal de zêde bike - lê ew nake. carte blanche tevlihevkirina bê dilxwazî ya HDD-yên hêdî û SSD-yên bilez di yek hewzê de. Hewzek wusa newekhev dê dîsa jî bi leza cîhaza herî hêdî bixebite, ango mîna ku ew bi tevahî ji alavên weha pêk were.
vdev
Her hewza hilanînê ji yek an çend cîhazên virtual (vdev) pêk tê. Di encamê de, her vdev yek an çend amûrên rastîn vedihewîne. Piraniya cîhazên virtual ji bo hilanîna daneya hêsan têne bikar anîn, lê çend çînên alîkar ên vdev hene, di nav de CACHE, LOG, û TAYBETÎ. Her yek ji van celebên vdev dikare yek ji pênc topolojiyên xwe hebe: yek-cîhaz, RAIDz1, RAIDz2, RAIDz3 an neynikê.
RAIDz1, RAIDz2 û RAIDz3 celebên taybetî yên ku mirovên kevn jê re dibêjin RAID-a hevsengiya dualî (dagonal) ne. 1, 2 û 3 vedibêjin ka çend blokên hevsengiyê ji her rêça daneyê re têne veqetandin. Li şûna ku dîskên veqetandî hebin da ku hevsengiyê peyda bikin, cîhazên RAIDz yên virtual hevsengiyê li ser dîskan nîv-yekhev belav dikin. Rêzeyek RAIDz dikare bi qasî ku blokên hevsengiyê yên wê hebin bi qasî dîskê winda bike; ger yekî din wenda bike, dê têk biçe û hewza hilanînê bi xwe re bigire.
Di cîhazên virtual neynikê de (neynika vdev), her blok li ser her amûrek di vdevê de tê hilanîn. Her çend neynikên du-berfireh yên herî gelemperî ne, neynikek dikare her jimareyek kêfî ya amûran bigire - di sazgehên mezin de, sê caran bi gelemperî ji bo baştirkirina performansa xwendinê û tolerasyona xeletiyê têne bikar anîn. Neynikek vdev dikare ji her têkçûnê bijî heya ku bi kêmanî yek amûrek di vdevê de xebitî bimîne.
Vdevên yekane bi xwezayî xeternak in. Amûrek wusa virtual dê ji yek têkçûnek xilas nebe - û heke wekî hilanînê an vdevek taybetî were bikar anîn, wê hingê têkçûna wê dê bibe sedema hilweşandina tevahiyê. Li vir pir, pir baldar bin.
Amûrên virtual CACHE, LOG, û TAYBET dikarin di her yek ji topolojiyên jorîn de werin afirandin - lê ji bîr mekin ku windakirina amûrek virtual ya TAYBET tê wateya windakirina hewzê, ji ber vê yekê topolojîyek zêde tê pêşniyar kirin.
sazî
Dibe ku ev peyva herî hêsan e ku meriv di ZFS-ê de fêm bike - ew bi rastî amûrek gihîştina bêserûber a blokê ye. Bînin bîra xwe ku cîhazên virtual ji cîhazên kesane, û hewzek ji cîhazên virtual pêk tê.
Dîsk, an magnetîkî an jî statûya hişk, amûrên blokê yên herî gelemperî ne ku wekî blokên avakirina vdev têne bikar anîn. Lêbelê, her amûrek ku di nav / dev de ravekerek hebe dê wusa bike - ji ber vê yekê tevahiya rêzikên RAID-ê yên hardware dikarin wekî amûrên cûda werin bikar anîn.
Pelek xav a hêsan yek ji amûrên bloka alternatîf ên herî girîng e ku jê re vdev dikare were çêkirin. hewzên Test ji rêyek pir hêsan e ku meriv emrên hewzê kontrol bike û bibîne ka çiqas cîh di hewzek an amûrek virtual ya topolojiya diyarkirî de heye.
Hûn dikarin di nav çend hûrdeman de hewzek ceribandinê ji pelên kêm biafirînin - lê ji bîr nekin ku dûv re tevayî hewzê û pêkhateyên wê jêbirin.
Ka em bibêjin ku hûn serverek heşt-dîskê dixwazin û plan dikin ku hûn dîskên 10 TB (~ 9300 GiB) bikar bînin - lê hûn ne bawer in ku kîjan topolojî çêtirîn hewcedariyên we dike. Di mînaka li jor de, em di nav çend saniyan de hewzek ceribandinê ji pelên hûrsaz ava dikin - û naha em dizanin ku RAIDz2 vdev ji heşt dîskên 10 TB 50 TiB kapasîteya bikêr peyda dike.
Çînek din a cîhazên taybetî SPARE ye. Amûrên guheztina germ, berevajî cîhazên birêkûpêk, ne ji yek amûrek virtual, ji tevahiya hewzê ne. Ger yek vdev di hewzê de têk biçe û amûrek yedek bi hewzê ve were girêdan û peyda bibe, wê hingê ew ê bixweber tev li vdevê ya bandorkirî bibe.
Dema ku bi vdevê bandorkirî ve girêdayî ye, cîhaza veguheztinê dest bi wergirtina kopiyan an nûavakirina daneyên ku divê li ser cîhaza wenda bin dest pê dike. Di RAID-a kevneşopî de jê re "ji nû ve ava kirin" tê gotin, û di ZFS de ew "ji nûvekirin" e.
Girîng e ku were zanîn ku amûrên veguheztinê bi domdarî şûna cîhazên têkçûyî nagirin. Ev tenê veguheztinek demkî ye da ku wextê ku ji bo hilweşandina vdev digire kêm bike. Piştî ku rêvebir cîhêra vdevê ya têkçûyî diguhezîne, zêdebarî li wê cîhaza daîmî tê vegerandin, û SPARE ji vdevê tê qut kirin û vedigere ku ji bo tevaya hewzê bibe yedek.
Daneyên daneyan, blok û sektoran
Koma din a blokên avahîsaziyê yên ku di rêwîtiya meya ZFS-ê de têne fêm kirin kêmtir bi hardware ve girêdayî ne û bêtir bi wê yekê ve girêdayî ye ku çawa dane bixwe têne organîzekirin û hilanîn. Em li vir çend qatan diavêjin - wek metaslab - da ku ji tevlihevkirina hûrguliyan dûr nekevin dema ku têgihîştina avahiya giştî diparêzin.
Dataset
Dema ku em yekem danegehek diafirînin, ew hemî cîhê hewzê yê berdest nîşan dide. Dûv re em kota destnîşan dikin - û xala çiyê biguherînin. Sihr!
Zvol bi piranî tenê danehevek e ku ji qata pergala pelan a wê hatiye qutkirin, ku em li vir bi pergalek pelan a bi tevahî normal ext4 veguherînin.
Daneyên ZFS hema hema wekî pergala pelê ya standard a siwarkirî ye. Mîna pergalek pelê ya birêkûpêk, di nihêrîna pêşîn de ew "tenê peldankek din" xuya dike. Lê mîna pergalên pelan ên birêkûpêk ên siwarkirî, her komek daneya ZFS xwedan taybetmendiyên bingehîn e.
Berî her tiştî, dibe ku danesek xwedan kotayek diyarkirî be. Heke hûn saz bikin zfs set quota=100G poolname/datasetname, wê hingê hûn ê nikaribin li peldanka lêkirî binivîsin /poolname/datasetname zêdetir ji 100 GiB.
Di destpêka her rêzê de hebûna-û tunebûna-yên şikestî binihêrin? Her komek daneyê hem di hiyerarşiya ZFS û hem jî di hiyerarşiya mountkirina pergalê de cîhê xwe heye. Di hiyerarşiya ZFS de tixûbek sereke tune - hûn bi navê hewzê dest pê dikin û dûv re riya ji yek daneya berbi ya din. Bo nimûne, pool/parent/child ji bo daneya bi navê child di bin databasa dêûbav de parent di hewzeke bi navekî afirîner pool.
Bi xwerû, xala çîbûnê ya databasê dê bi navê wê re di hiyerarşiya ZFS-ê de, bi şiklê sereke - hewza bi navê pool siwar kirin wek /pool, berhevoka daneyan parent siwar kirin /pool/parent, û daneya zarokê child siwar kirin /pool/parent/child. Lêbelê, xala lêdana pergalê ya daneyên daneyê dikare were guheztin.
Ger em nîşan bidin zfs set mountpoint=/lol pool/parent/child, paşê daneyên daneyê pool/parent/child di sîstemê de hatiye siwarkirin wek /lol.
Ji bilî danehevan, divê em behsa cild (zvol) bikin. Hêjmarek bi qasî berhevokek daneyê wekhev e, ji bilî ku ew bi rastî pergala pelan tune - ew tenê amûrek blokê ye. Ji bo nimûne hûn dikarin çêbikin zvol Bi navê mypool/myzvol, dûv re wê bi pergalek pelan a ext4 format bikin, û dûv re wê pergala pelan siwar bikin - naha pergala pelan a we ya ext4 heye, lê digel hemî taybetmendiyên ewlehiyê yên ZFS! Dibe ku ev li ser yek komputerê bêaqil xuya bike, lê dema ku amûrek iSCSI derdixe wekî paşverûyek pir maqûltir e.
Blokan
Pelek bi yek an jî çend blokan tê temsîl kirin. Her blok li ser yek amûrek virtual tête hilanîn. Mezinahiya blokê bi gelemperî bi pîvanê re wekhev e recordsize, lê dikare were kêm kirin 2^ashift, heke ew metadata an pelek piçûk heye.
Em bi rastî rastî Ger hûn guheztinê pir kêm destnîşan bikin em bi cezayê performansa mezin henekan nakin
Di hewzek ZFS de, hemî dane, tevî metadata, di blokan de têne hilanîn. Mezinahiya blokê ya herî zêde ji bo her komek daneyê di xanî de tête diyar kirin recordsize (mezinahiya tomar). Mezinahiya tomarê dikare biguhere, lê ev ê mezinahî an cîhê blokên ku berê li berhevoka daneyê hatine nivîsandin neguhezîne - ew tenê bandorê li blokên nû dike ku ew têne nivîsandin.
Heya ku wekî din neyê destnîşankirin, mezinahiya têketina xwerû ya heyî 128 KiB e. Li ku derê performansa wê bêkêmasî nebe, lê ew ê pir caran ne tirsnak be. Recordsize dikare li her nirxek ji 4K heya 1M were danîn (bi mîhengên zêde recordsize hûn dikarin hê bêtir saz bikin, lê ev kêm kêm ramanek baş e).
Her blokek tenê daneyên yek pelê vedibêje - hûn nekarin du pelên cûda di yek blokekê de biqelişînin. Her pel ji yek an çend blokan pêk tê, li gorî mezinahiya wê. Ger mezinahiya pelê ji mezinahiya tomarê piçûktir be, ew ê di blokek piçûktir de were hilanîn - mînakî, blokek bi pelek 2 KiB dê tenê sektorek 4 KiB li ser dîskê dagir bike.
Ger pel têra xwe mezin be ku çend blokan hewce bike, wê hingê hemî navnîşên wê pelê dê mezin bin recordsize - di nav de têketina paşîn, ku beşa sereke ya ku dibe be .
cildên zvol ne xwedî milk in recordsize - li şûna wan xwedî milkê wekhev in volblocksize.
Sektorên
Avahiya dawîn, ya herî bingehîn sektor e. Ew yekîneya fizîkî ya herî piçûk e ku dikare ji amûrek mêvandar were nivîsandin an xwendin. Ji bo çend dehsalan, piraniya dîskan sektorên 512-byte bikar anîn. Van rojan, pir ajoker ji bo sektorên 4 KiB têne mîheng kirin, û hin - nemaze SSD - ji bo sektorên 8 KiB an jî mezintir têne mîheng kirin.
ZFS xwedan taybetmendiyek e ku dihêle hûn bi destan mezinahiya sektorê saz bikin. Ev milk ashift. Hinekî tevlihev, ashift hêza du ye. Bo nimûne, ashift=9 tê wateya mezinahiya sektora 2^9, an 512 bytes.
ZFS dema ku ew li vdevek nû tê zêdekirin ji pergala xebitandinê agahdariya hûrgulî dipirse û li ser bingeha wê agahiyê bi teorîkî veguheztina guncan destnîşan dike. Mixabin, gelek ajoker li ser mezinahiya sektora xwe derewan dikin da ku lihevhatina bi Windows XP-ê re biparêzin (ku nekaribû ajokarên bi mezinahiyên sektora din fam bike).
Ev tê vê wateyê ku pir tê pêşniyar kirin ku rêvebirê ZFS mezinahiya sektora rastîn a cîhazên xwe zanibe û bi destan saz bike. ashift. Ger ashift pir hindik were danîn, hejmara operasiyonên xwendin/nivîsandinê bi astronomî zêde dibe. Ji ber vê yekê, nivîsandina "sektorên" 512-byte li sektorek 4 KiB ya rastîn tê vê wateyê ku meriv "sektora" yekem binivîse, dûv re sektora 4 KiB bixwîne, bi "sektorek" 512-byte ya duyemîn re biguhezîne, wê vegere ya nû. 4 sektora KiB, û hwd ji bo her têketinê.
Di cîhana rastîn de, cezayek wusa bandorê li Samsung EVO SSD dike, ji bo ku ew pêdivî ye ashift=13, lê ev SSD li ser mezinahiya sektora xwe derewan dikin, û ji ber vê yekê xwerû tê danîn ashift=9. Heya ku rêveberek pergalê ya pispor vê mîhengê neguherîne, ev SSD dixebite hêdîtir HDD magnetîkî bi rêkûpêk.
Ji bo berhevdanê, ji bo ku pir mezin e ashift e bi rastî tu ceza hene. Performansa rast lêdan tune, û zêdebûna cîhê nekarandî bêsînor e (an jî sifir ger ku kompresyon were çalak kirin). Ji ber vê yekê, em bi tundî pêşniyar dikin ku tewra ew ajokarên ku sektorên 512-byte bikar tînin jî saz bikin ashift=12 an jî jî ashift=13ku bi bawerî li pêşerojê binêre.
Mal ashift ji bo her cîhaza virtual vdev tê sazkirin, û ne ji bo hewzê, wekî ku gelek kes bi xeletî difikirin - û piştî sazkirinê nayê guhertin. Heke hûn bi xeletî xistin ashift Gava ku hûn vdevek nû li hewzekê zêde bikin, we ew hewz bi amûrek kêm-performansa xwe bi awayekî bêveger qirêj kir û, wekî qaîdeyek, ji xerakirina hewzê û ji nû ve destpêkirinê vebijarkek din tune. Tewra jêbirina vdev jî dê we ji mîhengek şikestî xilas neke ashift!
Mekanîzmaya kopî-li-nivîsandinê
Ger pergalek pelê ya birêkûpêk hewce bike ku daneyan ji nû ve binivîsîne, ew her bloka ku lê ye diguhezîne
Pergalek pelê kopî-li-nivîsandinê guhertoyek nû ya blokê dinivîse û dûv re guhertoya kevn vedike
Bi kurtasî, heke em lihevhatina fizîkî ya rastîn a blokan paşguh bikin, "kometa daneyê" me hêsan dibe "kurmê daneyê" ku li seranserê nexşeya cîhê berdest ji çepê ber bi rastê ve diçe.
Naha em dikarin têgehek baş bistînin ka wêneyên kopî-li-nivîsandinê çawa dixebitin - her blok dikare bibe xwediyê gelek wêneyan, û dê berdewam bike heya ku hemî dîmenên têkildar neyên hilweşandin.
Mekanîzmaya Copy on Write (CoW) bingeha bingehîn a ku ZFS dike pergalek wusa ecêb e. Têgeha bingehîn hêsan e - heke hûn ji pergala pelan a kevneşopî bipirsin ku pelek biguhezîne, ew ê tam tiştê ku we xwestiye bike. Ger hûn ji pergala pelan a kopî-li-nivîsandinê bipirsin ku heman tiştî bike, ew ê bêje "baş e" - lê ew ê ji we re derewan bike.
Di şûna wê de, pergala pelan a kopî-li-nivîsandinê guhertoyek nû ya bloka hatî guheztin dinivîse, û dûv re metadata pelê nûve dike da ku bloka kevin veqetîne û wê bi bloka nû ya ku we nû nivîsandiye re têkildar bike.
Veqetandina bloka kevn û girêdana ya nû di yek operasyonê de pêk tê, ji ber vê yekê ew nikare were qut kirin - heke hûn piştî vê yekê hêzê ji nû ve bikin, we guhertoyek nû ya pelê heye, û heke we berê hêzê ji nû ve saz bike, wê hingê we heye guhertoya kevn. Di her rewşê de, dê di pergala pelê de pevçûn tune.
Kopî-li-nivîsandinê di ZFS de ne tenê di asta pergala pelan de, lê di asta rêveberiya dîskê de jî pêk tê. Ev tê vê wateyê ku ZFS di tomarê de ji cîhê spî re ne hesas e () - diyardeyek ku berî ku pergal têk biçe, şirît tenê bi qismî hatî tomar kirin, piştî rebootkirinê zirarê digihîne rêzê. Li vir xêzik bi atomî hatiye nivîsandin, vdev her dem rêzdar e û .
ZIL: Têketina niyeta ZFS
ZFS nivîsandinên hevdemî bi rengek taybetî digire - ew wan bi demkî lê tavilê di ZIL-ê de hilîne berî ku paşê bi domdarî wan bi nivîsên asynkron re binivîsîne.
Bi gelemperî, daneyên ku ji ZIL re hatine nivîsandin careke din nayên xwendin. Lê ev yek piştî têkçûna pergalê gengaz e
SLOG, an jî amûrek LOG-ya duyemîn, bi tenê vdevek taybetî ye - û bijare pir zû - ku ZIL dikare ji depoya sereke cuda were hilanîn.
Piştî têkçûnekê, hemî daneyên qirêj ên di ZIL-ê de têne dubare kirin - di vê rewşê de, ZIL li ser SLOG-ê ye, ji ber vê yekê ew li vir tê lîstin
Du kategoriyên sereke yên nivîsandinê hene: hevdem (hevdem) û asînkron (asynchronous). Ji bo piraniya barkêşan, pirraniya nivîsan asynkron in - pergala pelan dihêle ku ew kom bibin û bi koman werin derxistin, perçebûnê kêm dike û bi girîngî rêgez zêde dike.
Tomarkirina hevdemî mijarek bi tevahî cûda ye. Dema ku serîlêdanek nivîsandinek hevdem daxwaz dike, ew ji pergala pelê re dibêje: "Divê hûn vê yekê bi bîranîna ne-volatile re bikin a niha, û heta wê demê tiştekî din ez nikarim bikim." Ji ber vê yekê, nivîsandina hevdem divê tavilê bi dîskê ve were girêdan - û heke ev perçebûnê zêde bike an berbi kêm bike, wusa be.
ZFS ji pergalên pelan ên birêkûpêk cûda nivîsên hevdemî digire - li şûna ku tavilê wan biavêje hilanîna birêkûpêk, ZFS wan bi cîhek hilanînê ya taybetî ya bi navê ZFS Intent Log, an jî ZIL vedigire. The trick ew e ku ev tomar jî di bîranînê de bimîne, digel daxwazên nivîsandinê yên asînkron ên normal têne berhev kirin, da ku paşê wekî TXG-yên bi tevahî normal (Grûpên Danûstandinê) di hilanînê de werin rijandin.
Di dema xebata normal de, ZIL tê nivîsandin û careke din nayê xwendin. Dema ku, piştî çend kêliyan, tomarên ji ZIL-ê di hilanîna sereke ya di TXG-yên birêkûpêk ên RAM-ê de têne bicîh kirin, ew ji ZIL-ê têne veqetandin. Tenê dema ku tiştek ji ZIL tê xwendin dema îtxalkirina hewzek e.
Ger têkçûnek ZFS çêbibe - qezayek pergala xebitandinê an qutbûnek elektrîkê - dema ku di ZIL de dane hene, ew dane dê di dema importa hewzê ya din de were xwendin (mînak, dema ku pergala têkçûn ji nû ve were destpêkirin). Tiştê ku di ZIL-ê de hebe dê were xwendin, di TXG-an de were kom kirin, bi firotgeha sereke ve were girêdan, û dûv re di pêvajoya importê de ji ZIL-ê were veqetandin.
Yek ji çînên alîkarê vdev jê re LOG an SLOG, amûrek LOG ya duyemîn tê gotin. Yek peywirek wê heye - li şûna ku ZIL li ser hilanîna vdev-ê ya sereke were hilanîn, hewzek veqetandî û, bi tercîh, pir zûtir, bi berxwedana nivîsandinê ya pir bilind, amûrek vdev ji bo hilanîna ZIL peyda bike. ZIL bixwe bêyî cîhê hilanînê bi heman rengî tevdigere, lê heke vdev bi LOG xwedan performansa nivîsandinê pir bilind be, wê hingê nivîsandina hevdem dê zûtir be.
Zêdekirina vdev bi LOG li hewzê naxebite nikare performansa nivîsandina asînkron baştir bikin - her çend hûn zorê bidin hemî nivîsandinan li ZIL zfs set sync=always, ew ê hîn jî bi heman rengî û bi heman lezê wekî bêyî têketinê bi hilana sereke ya li TXG ve werin girêdan. Yekane başkirina performansa rasterast derengiya nivîsandina hevdem e (ji ber ku leza têketinê ya bilind operasyonan zûtir dike sync).
Lêbelê, li hawîrdorek ku jixwe gelek nivîsên hevdemî hewce dike, vdev LOG dikare bi awayekî nerasterast nivîsandina asynchron û xwendina necached lez bike. Daxistina tomarên ZIL li ser vdev LOG-a veqetandî tê vê wateyê ku ji bo IOPS-ê li ser hilanîna seretayî kêm nakokî heye, ku ev yek heya radeyekê performansa hemî xwendin û nivîsandinê baştir dike.
Snapshots
Mekanîzmaya kopî-li-nivîsandinê di heman demê de bingehek hewce ye ji bo dîmenên atomî yên ZFS û dubarekirina asynkron a zêde. Pergala pelê ya çalak darek nîşanker heye ku hemî navnîşan bi daneyên heyî nîşan dide - gava ku hûn wêneyek dikişînin, hûn tenê kopiyek vê dara nîşankerê çêdikin.
Dema ku tomarek li ser pergala pelê çalak tê nivîsandin, ZFS pêşî guhertoya nû ya blokê li cîhê nekarandî dinivîse. Dûv re guhertoya kevn a blokê ji pergala pelê ya heyî vediqetîne. Lê heke hin wêneyek bloka kevn referans dike, ew hîn jî neguherî dimîne. Dê bloka kevn bi rastî wekî cîhê belaş neyê vegerandin heya ku hemî dîmenên ku behsa wê blokê dikin neyên hilweşandin!
Replication
Pirtûkxaneya Steam ya min di sala 2015-an de 158 GiB bû û 126 pelan tê de hebûn. Ev ji bo rsyncê pir nêzîkê rewşa çêtirîn e - dubarekirina ZFS li ser torê "tenê" 927% zûtir bû.
Li ser heman torê, dubarekirina yek pelê wêneya makîneya virtual ya 40 GB Windows 7 çîrokek bi tevahî cûda ye. Replika ZFS 289 carî ji rsyncê zûtir e - an "tenê" 161 carî zûtir e heke hûn têra xwe jêhatî bin ku hûn bi guheztina --inplace gazî rsync bikin.
Dema ku wêneyek VM-ê mezin dibe, pirsgirêkên rsync bi wê re pîvanê dike. Mezinahiya 1,9 TiB ji bo wêneyek VM-ya nûjen ne ew qas mezin e - lê ew têra xwe mezin e ku dubarekirina ZFS 1148 carî ji rsync zûtir e, tewra digel argumana rsync --inplace
Gava ku hûn fêm bikin ka wêneyan çawa dixebitin, dê hêsan be ku hûn cewhera dubarekirinê fam bikin. Ji ber ku wêneyek bi tenê dara nîşangirên tomarê ye, diqewime ku heke em bikin zfs send snapshot, paşê em vê darê û hemî tomarên pê re têkildar dişînin. Dema ku em vê derbas bikin zfs send в zfs receive li ser mebesta armancê, ew hem naveroka rastîn a blokê û hem jî dara nîşangiran dinivîse ku blokan ji berhevoka daneya armancê re vedibêje.
Tiştên di ya duyemîn de hê balkêştir dibin zfs send. Niha du sîstemên me hene, her yek tê de ye poolname/datasetname@1, û hûn wêneyek nû digirin poolname/datasetname@2. Ji ber vê yekê, di hewza çavkaniya we de heye datasetname@1 и datasetname@2, û di hewza armancê de tenê wêneya yekem heye datasetname@1.
Ji ber ku di navbera çavkanî û armancê de dîmenek me ya hevpar heye datasetname@1, em dikarin bikin zêdebûnî zfs send li ser wê. Dema ku em ji pergalê re dibêjin zfs send -i poolname/datasetname@1 poolname/datasetname@2, ew du darên nîşanker dide ber hev. Nîşaneyên ku tenê di nav de hene @2, eşkere behsa blokên nû bikin - ji ber vê yekê em ê hewceyê naveroka wan blokan bin.
Li ser pergalek dûr, pêvajo zêde dibe send tenê bi hêsanî. Pêşî em hemî navnîşên nû yên ku di nav çemê de hene dinivîsin send, û paşê nîşankeran li van blokan zêde bikin. Voila, em hene @2 di pergala nû de!
Zêdekirina asînkron a ZFS li gorî rêgezên berê yên ne-snapshot-ê yên wekî rsync çêtirbûnek mezin e. Di her du rewşan de, tenê daneyên guhertî têne veguheztin - lê divê pêşî rsync bixwînin ji dîskê hemû daneyên li ser her du aliyan da ku berhevokê kontrol bikin û bidin ber hev. Berevajî vê, dubarekirina ZFS ji bilî darên nîşanker-û blokên ku di wêneya giştî de nayên temsîl kirin tiştek din naxwîne.
Pêvek çêkirî
Mekanîzmaya kopî-li-nivîsandinê di heman demê de pergala berhevkirinê ya çêkirî jî hêsan dike. Di pergalek pelê ya kevneşopî de, berhevkirin pirsgirêk e - hem guhertoya kevn û hem jî guhertoya nû ya daneya guhertî di heman cîhê de ne.
Ger hûn perçeyek daneyê di nîvê pelê de bihesibînin ku jiyana xwe wekî megabyte sifir ji 0x00000000 û hwd dest pê dike - pir hêsan e ku meriv wê di yek sektorek li ser dîskê de berhev bike. Lê çi diqewime ger em vê megabyte sifirê bi megabyte daneya neqemkirî biguhezînin, wek JPEG an dengê pseudo-random? Ji nişkê ve, ew megabyte daneyê dê ne yek, lê 256 4 KiB sektoran hewce bike, û tenê sektorek di wê cîhê dîskê de hate veqetandin.
ZFS ev pirsgirêk tune ye, ji ber ku tomarên guhertî her gav li cîhê neyên bikar anîn têne nivîsandin - bloka orîjînal tenê yek sektorek 4 KiB digire, û nivîsek nû dê 256 bigire, lê ev ne pirsgirêk e - parçeyek nû hatî guherandin ji "navîn" ya pelê dê li cîhê nekarkirî were nivîsandin bêyî ku mezinahiya wê guherî ye an na, ji ber vê yekê ev ji bo ZFS rewşek bi tevahî normal e.
Tevlihevkirina ZFS-ya çêkirî ji hêla xwerû ve neçalak e, û pergal algorîtmayên pêvekirî pêşkêşî dike - ku niha LZ4, gzip (1-9), LZJB û ZLE tê de hene.
- LZ4 algorîtmayek vekêşanê ye ku ji bo pir rewşên karanîna - tewra li ser CPU-yên pir hêdî jî, berhevkirin û dekompresyonek zehf bilez û feydeyên performansê pêşkêşî dike.
- GZIP algorîtmayek rêzdar e ku hemî bikarhênerên Unix dizanin û jê hez dikin. Ew dikare bi astên kompresyonê 1-9, bi zêdekirina rêjeya kompresyonê û karanîna CPU-yê dema ku hûn nêzikî asta 9-an dibin ve were bicîh kirin. Algorîtma ji bo hemî rewşên karanîna nivîsê (an jî yên din ên ku pir têkeldar) xweş e, lê pir caran dibe sedema pirsgirêkên CPU-yê wekî din - wê bikar bînin bi hişyarî, nemaze di astên bilind de.
- LZJB - algorîtmaya orîjînal di ZFS de. Ew qedîm e û divê êdî neyê bikar anîn, LZ4 di her warî de serwer e.
- BADLY - kodkirina asta sifir, şîfrekirina asta sifir. Ew bi ti awayî dest nade daneyên normal, lê ew rêzikên mezin ên sifiran berhev dike. Ji bo berhevokên daneya ku bi tevahî nayên pêçandî (wekî JPEG, MP4 an formatên din ên jixwe hatine pêçandin) bikêr e ji ber ku ew daneya neqewimin paşguh dike lê cîhê nekarandî di tomarên encam de berhev dike.
Em kompresyona LZ4 ji bo hema hema hemî rewşên karanîna pêşniyar dikin; cezayê performansa dema mijûlbûna bi daneya incompressible pir biçûk e, û mezinbûnî performansa ji bo daneyên tîpîk girîng e. Kopîkirina wêneyek makîneya virtual ji bo sazkirina nû ya pergala xebitandinê ya Windows-ê (OS-ya nû hatî saz kirin, hêj di hundurê de dane tune) bi compression=lz4 derbas 27% zûtir ji bi compression=nonein .
ARC - cache veguheztina adaptîv
ZFS yekane pergala pelê ya nûjen e ku em pê dizanin ku mekanîzmaya xweya cachkirina xwendinê bikar tîne, li şûna ku xwe bispêre cache rûpela pergala xebitandinê da ku kopiyên blokên xwendî yên vê dawiyê di RAM-ê de hilîne.
Her çend cache-ya xwemalî ne bê pirsgirêkên xwe ye - ZFS nikare bi qasî kernelê zû bersivê bide daxwazên veqetandina bîranîna nû, ji ber vê yekê bangek nû malloc() Dibe ku veqetandina bîranînê têk biçe ger pêdivî bi RAM-a ku niha ji hêla ARC ve hatî dagir kirin hewce bike. Lê sedemên baş hene ku hûn cache-ya xwe bikar bînin, bi kêmanî heya niha.
Hemî pergalên xebitandinê yên nûjen ên naskirî, di nav de MacOS, Windows, Linux û BSD, algorîtmaya LRU (Kêmtirîn Dawî Bikaranîn) bikar tînin da ku kaşê rûpelê bicîh bikin. Ev algorîtmayek seretayî ye ku piştî her xwendinê bloka cached "berbi jora rêzê" dixe û blokan dişoxilîne "ber bi binê dorê" wekî ku hewce dike ji bo lê zêde bike nesîbên cache yên nû (blokên ku diviyabû ji dîskê bihatana xwendin. ji cache) ber bi jor.
Bi gelemperî algorîtma baş dixebite, lê li ser pergalên bi daneyên mezin ên xebatê, LRU bi hêsanî rê li ber pelçiqandinê vedike - blokên ku pir caran hewce ne ji holê radike da ku cîh ji blokên ku dê çu carî ji cache neyên xwendin çêbike.
algorîtmayek pir hindiktir e ku meriv dikare wekî cache "giran" were hesibandin. Her gava ku blokek cached tê xwendin, derxistina wê hinekî girantir û dijwartir dibe - û tewra piştî ku blok tê derxistin şopandin li ser demeke diyarkirî. Bloka ku hatî derxistin lê dûv re pêdivî ye ku vegere nav cacheyê jî dê girantir bibe.
Encama dawî ya van hemiyan cacheyek e ku bi rêjeya lêdanek pir zêde ye - rêjeya di navbera lêdanên cache (ji cache dixwîne) û windayan (ji dîskê dixwîne). Ev îstatîstîkek pir girîng e - ne tenê lêdanên cache bi xwe bi fermanên mezinahiyê zûtir têne servîs kirin, lêbelêyên cache jî dikarin zûtir werin servîs kirin, ji ber ku her ku bêtir lêdanên cache hene, daxwazên paralel ji dîskê re hindiktir dibe û derengiya wan kêmasiyên mayî kêmtir dibe. ku divê bi dîskê re xizmet bike.
encamê
Naha ku me semantîka bingehîn a ZFS-ê-çawa kopî-li-nivîsandinê dixebite, û her weha têkiliyên di navbera hewzên hilanînê, cîhazên virtual, blokan, sektor û pelan de vegirtiye - em amade ne ku bi performansa cîhana rast re nîqaş bikin. hejmarên rastîn.
Di beşa paşîn de, em ê li performansa rastîn a hewzên vdev û RAIDz ên neynikê binêrin, li gorî hevûdu, û her weha li gorî topolojiyên RAID-ê yên kevneşopî yên Linux-ê ku me lêkolîn kiriye. .
Di destpêkê de me dixwest ku tenê bingehîn - topolojiyên ZFS bixwe - lê paşê wisa Em ê amade bin ku li ser veavakirin û ahenga pêşkeftî ya ZFS-ê biaxivin, di nav de karanîna celebên vdev ên alîkar ên wekî L2ARC, SLOG û Veqetandina Taybet.
Source: www.habr.com