Այս գարնանը մենք արդեն քննարկել ենք մի քանի ներածական թեմաներ, օրինակ. и . Դրանցից երկրորդում մենք նույնիսկ խոստացանք շարունակել ZFS-ում տարբեր բազմասկավառակ տոպոլոգիաների աշխատանքի ուսումնասիրությունը։ Սա հաջորդ սերնդի ֆայլային համակարգն է, որն այժմ ներդրվում է ամենուր՝ սկսած դեպի .
Դե, այսօր լավագույն օրն է ծանոթանալու ZFS-ին, հետաքրքրասեր ընթերցողներին։ Պարզապես իմացեք, որ OpenZFS-ի մշակող Մեթ Արենսի համեստ կարծիքով, «դա իսկապես դժվար է»:
Բայց նախքան թվերին հասնելը, և խոստանում եմ, որ դրանք կանեն, ութ սկավառակի ZFS կազմաձևման բոլոր տարբերակների համար, մենք պետք է խոսենք դրա մասին. ինչպես Ընդհանուր առմամբ, ZFS-ը տվյալները պահում է սկավառակի վրա:
Zpool, vdev և սարք
Այս ամբողջական լողավազանի դիագրամը ներառում է երեք օժանդակ vdevs, յուրաքանչյուր դասից մեկը և չորսը RAIDz2-ի համար
Սովորաբար պատճառ չկա ստեղծելու անհամապատասխան vdev տեսակների և չափերի լողավազան, բայց ոչինչ չի խանգարում ձեզ դա անել, եթե ցանկանում եք:
ZFS ֆայլային համակարգը իսկապես հասկանալու համար դուք պետք է ուշադիր նայեք դրա իրական կառուցվածքին: Նախ, ZFS-ը միավորում է ծավալի և ֆայլային համակարգի կառավարման ավանդական մակարդակները: Երկրորդ, այն օգտագործում է գործարքային պատճենման վրա գրելու մեխանիզմ: Այս հատկանիշները նշանակում են, որ համակարգը կառուցվածքային առումով շատ է տարբերվում սովորական ֆայլային համակարգերից և RAID զանգվածներից: Հիմնական շինանյութերի առաջին հավաքածուն, որը պետք է հասկանալ, են պահեստային լողավազանը (zpool), վիրտուալ սարքը (vdev) և իրական սարքը (սարք):
zpool
Zpool պահեստավորման լողավազանը ZFS-ի ամենաբարձր կառույցն է: Յուրաքանչյուր լողավազան պարունակում է մեկ կամ մի քանի վիրտուալ սարքեր: Իր հերթին դրանցից յուրաքանչյուրը պարունակում է մեկ կամ մի քանի իրական սարքեր (սարք): Վիրտուալ լողավազանները ինքնուրույն բլոկներ են: Մեկ ֆիզիկական համակարգիչը կարող է պարունակել երկու կամ ավելի առանձին լողավազաններ, բայց յուրաքանչյուրը լիովին անկախ է մյուսներից: Լողավազանները չեն կարող համօգտագործել վիրտուալ սարքերը:
ZFS-ի ավելորդությունը վիրտուալ սարքի մակարդակում է, ոչ թե լողավազանի մակարդակում: Լողավազանի մակարդակում բացարձակապես ավելորդություն չկա. եթե որևէ դրայվ vdev կամ հատուկ vdev կորչում է, ապա ամբողջ լողավազանը կորչում է դրա հետ մեկտեղ:
Ժամանակակից պահեստային լողավազանները կարող են գոյատևել քեշի կամ վիրտուալ սարքի գրանցամատյանի կորստից, չնայած նրանք կարող են կորցնել փոքր քանակությամբ կեղտոտ տվյալներ, եթե կորցնեն vdev մատյանը հոսանքի անջատման կամ համակարգի խափանման ժամանակ:
Տարածված սխալ պատկերացում կա, որ ZFS «տվյալների շերտերը» գրված են ամբողջ լողավազանում: Սա ճիշտ չէ. Zpool-ը ամենևին էլ զվարճալի RAID0 չէ, այն բավականին զվարճալի է բարդ փոփոխական բաշխման մեխանիզմով։
Գրառումները մեծ մասամբ բաշխվում են հասանելի վիրտուալ սարքերի միջև՝ ըստ առկա ազատ տարածության, ուստի տեսականորեն դրանք բոլորը կլցվեն միաժամանակ։ ZFS-ի ավելի ուշ տարբերակներում հաշվի է առնվում vdev-ի ընթացիկ օգտագործումը (օգտագործումը). եթե մի վիրտուալ սարքը զգալիորեն ավելի զբաղված է, քան մյուսը (օրինակ՝ կարդալու բեռնվածության պատճառով), այն ժամանակավորապես կբացակայվի գրելու համար՝ չնայած ամենաբարձր անվճար լինելուն: տարածության հարաբերակցությունը.
Օգտագործման հայտնաբերման մեխանիզմը, որը ներկառուցված է ZFS գրելու տեղաբաշխման ժամանակակից մեթոդներում, կարող է նվազեցնել ուշացումը և մեծացնել թողունակությունը անսովոր բարձր բեռի ժամանակաշրջաններում, բայց դա այդպես չէ: քարտ բլանշ դանդաղ HDD-ների և արագ SSD-ների ակամա խառնման վրա մեկ լողավազանում: Նման անհավասար լողավազանը դեռ կաշխատի ամենադանդաղ սարքի արագությամբ, այսինքն՝ կարծես այն ամբողջությամբ կազմված լինի նման սարքերից։
վդև
Յուրաքանչյուր պահեստային լողավազան բաղկացած է մեկ կամ մի քանի վիրտուալ սարքերից (վիրտուալ սարք, vdev): Իր հերթին, յուրաքանչյուր vdev պարունակում է մեկ կամ մի քանի իրական սարքեր: Վիրտուալ սարքերի մեծ մասն օգտագործվում է պարզ տվյալների պահպանման համար, սակայն կան vdev օգնականների մի քանի դասեր, այդ թվում՝ CACHE, LOG և SPECIAL: Այս vdev տեսակներից յուրաքանչյուրը կարող է ունենալ հինգ տոպոլոգիաներից մեկը՝ մեկ սարք (մեկ սարք), RAIDz1, RAIDz2, RAIDz3 կամ հայելի (հայելի):
RAIDz1-ը, RAIDz2-ը և RAIDz3-ը հատուկ տարատեսակներ են, որոնք հին ժամանակները կկոչեին կրկնակի (անկյունագծային) հավասարաչափ RAID: 1-ը, 2-ը և 3-ը վերաբերում են այն բանին, թե որքան հավասարաչափ բլոկ է հատկացվել յուրաքանչյուր տվյալների շերտի համար: Հավասարության համար առանձին սկավառակների փոխարեն, RAIDz վիրտուալ սարքերը կիսահավասարաչափ բաշխում են այս հավասարությունը սկավառակների վրա: RAIDz զանգվածը կարող է կորցնել այնքան սկավառակ, որքան ունի հավասարության բլոկներ; եթե այն կորցնի ևս մեկը, այն կվթարի և իր հետ կտանի պահեստային ավազանը:
Հայելային վիրտուալ սարքերում (mirror vdev) յուրաքանչյուր բլոկ պահվում է vdev-ի յուրաքանչյուր սարքի վրա: Չնայած երկլայն հայելիները ամենատարածվածն են, ցանկացած կամայական թվով սարքեր կարող են լինել հայելու մեջ. եռյակները հաճախ օգտագործվում են մեծ տեղակայանքներում՝ բարելավելու ընթերցման կատարումը և սխալների հանդուրժողականությունը: Vdev հայելին կարող է գոյատևել ցանկացած խափանում, քանի դեռ vdev-ի առնվազն մեկ սարքը շարունակում է գործել:
Միայնակ vdev-ները ի սկզբանե վտանգավոր են: Նման վիրտուալ սարքը չի կարող գոյատևել մեկ ձախողում, և եթե օգտագործվի որպես պահեստ կամ հատուկ vdev, ապա դրա ձախողումը կհանգեցնի ամբողջ լողավազանի ոչնչացմանը: Այստեղ շատ, շատ զգույշ եղեք։
CACHE, LOG և SPECIAL VA-ները կարող են ստեղծվել՝ օգտագործելով վերը նշված տոպոլոգիաներից որևէ մեկը, բայց հիշեք, որ SPECIAL VA-ի կորուստը նշանակում է լողավազանի կորուստ, ուստի ավելորդ տոպոլոգիան խիստ խորհուրդ է տրվում:
սարք
Սա, հավանաբար, ZFS-ում հասկանալու ամենահեշտ տերմինն է. դա բառացիորեն բլոկային պատահական մուտքի սարք է: Հիշեք, որ վիրտուալ սարքերը կազմված են առանձին սարքերից, մինչդեռ լողավազանը կազմված է վիրտուալ սարքերից:
Սկավառակները՝ կա՛մ մագնիսական, կա՛մ պինդ վիճակում, ամենատարածված բլոկային սարքերն են, որոնք օգտագործվում են որպես vdev-ի կառուցման բլոկներ: Այնուամենայնիվ, ցանկացած սարք, որն ունի /dev-ի նկարագրիչ, կգործի, այնպես որ ամբողջ ապարատային RAID զանգվածները կարող են օգտագործվել որպես առանձին սարքեր:
Պարզ չմշակված ֆայլը ամենակարևոր այլընտրանքային բլոկ սարքերից մեկն է, որից կարելի է կառուցել vdev: Փորձնական լողավազաններ շատ հարմար միջոց է լողավազանի հրամանները ստուգելու և տեսնելու, թե որքան տարածք է հասանելի լողավազանում կամ տվյալ տոպոլոգիայի վիրտուալ սարքում:
Դուք կարող եք ստեղծել թեստային լողավազան նոսր ֆայլերից ընդամենը մի քանի վայրկյանում, բայց մի մոռացեք ջնջել ամբողջ լողավազանը և դրա բաղադրիչները դրանից հետո:
Ենթադրենք, դուք ցանկանում եք սերվեր տեղադրել ութ սկավառակների վրա և նախատեսում եք օգտագործել 10 ՏԲ սկավառակներ (~ 9300 ԳԲ), բայց դուք վստահ չեք, թե որ տոպոլոգիան լավագույնս համապատասխանում է ձեր կարիքներին: Վերոնշյալ օրինակում մենք նոսր ֆայլերից վայրկյանների ընթացքում կառուցում ենք թեստային լողավազան, և այժմ մենք գիտենք, որ RAIDz2 vdev ութ 10 ՏԲ սկավառակից ապահովում է 50 TiB օգտագործելի հզորություն:
Սարքերի մեկ այլ հատուկ դաս է SPARE (պահեստային): Hot-swap սարքերը, ի տարբերություն սովորական սարքերի, պատկանում են ամբողջ լողավազանին, այլ ոչ թե մեկ վիրտուալ սարքին: Եթե լողավազանում գտնվող vdev-ը ձախողվի, և պահեստային սարքը միացված է լողավազանին և հասանելի է, ապա այն ավտոմատ կերպով կմիանա տուժած vdev-ին:
Տուժած vdev-ին միանալուց հետո պահեստային սարքը սկսում է ստանալ տվյալների կրկնօրինակները կամ վերակառուցումները, որոնք պետք է լինեն բացակայող սարքում: Ավանդական RAID-ում դա կոչվում է վերակառուցում, մինչդեռ ZFS-ում այն կոչվում է resilvering:
Կարևոր է նշել, որ պահեստային սարքերը մշտապես չեն փոխարինում ձախողված սարքերին: Սա միայն ժամանակավոր փոխարինում է՝ նվազեցնելու vdev-ի դեգրադացման ժամանակը: Այն բանից հետո, երբ ադմինիստրատորը փոխարինում է ձախողված vdev-ը, ավելորդությունը վերականգնվում է այդ մշտական սարքում, և SPARE-ն անջատվում է vdev-ից և վերադարձվում աշխատանքի որպես պահեստային ամբողջ լողավազանի համար:
Տվյալների հավաքածուներ, բլոկներ և հատվածներ
Մեր ZFS ճամփորդության ընթացքում հասկանալու համար կառուցողական բլոկների հաջորդ հավաքածուն ավելի քիչ է վերաբերում սարքավորմանը և ավելի շատ այն մասին, թե ինչպես են տվյալներն իրենք կազմակերպվում և պահվում: Մենք այստեղ բաց ենք թողնում մի քանի մակարդակներ, ինչպիսիք են metaslab-ը, որպեսզի չխճճվեն մանրամասները` միաժամանակ պահպանելով ընդհանուր կառուցվածքի ըմբռնումը:
Տվյալների հավաքածու (տվյալների հավաքածու)
Երբ մենք առաջին անգամ ստեղծում ենք տվյալների բազա, այն ցույց է տալիս լողավազանի ողջ հասանելի տարածքը: Այնուհետև մենք սահմանում ենք քվոտան և փոխում ենք տեղադրման կետը: Magic!
Zvol-ը մեծ մասամբ ընդամենը տվյալների բազա է, որը զրկված է իր ֆայլային համակարգի շերտից, որը մենք այստեղ փոխարինում ենք միանգամայն նորմալ ext4 ֆայլային համակարգով:
ZFS տվյալների բազան մոտավորապես նույնն է, ինչ ստանդարտ տեղադրված ֆայլային համակարգը: Ինչպես սովորական ֆայլային համակարգը, առաջին հայացքից այն կարծես «պարզապես մեկ այլ թղթապանակ»: Բայց ինչպես սովորական մոնտաժվող ֆայլային համակարգերը, յուրաքանչյուր ZFS տվյալների բազա ունի հիմնական հատկությունների իր հավաքածուն:
Նախևառաջ, տվյալների բազան կարող է ունենալ նշանակված քվոտա: Եթե սահմանված է zfs set quota=100G poolname/datasetname, ապա դուք չեք կարողանա գրել տեղադրված թղթապանակում /poolname/datasetname ավելի քան 100 ԳԲ:
Ուշադրություն դարձրե՞լ եք յուրաքանչյուր տողի սկզբում թեքությունների առկայությունը և բացակայությունը: Յուրաքանչյուր տվյալների հավաքածու ունի իր ուրույն տեղը և՛ ZFS-ի հիերարխիայում, և՛ համակարգի տեղադրման հիերարխիայում: ZFS-ի հիերարխիայում առաջատար շեղ չկա. դուք սկսում եք լողավազանի անունից և այնուհետև մի տվյալների բազայից մյուս ուղուց: Օրինակ, pool/parent/child անունով տվյալների բազայի համար child մայր տվյալների բազայի տակ parent ստեղծագործական անունով լողավազանում pool.
Լռելյայնորեն տվյալների բազայի մոնտաժման կետը համարժեք կլինի իր անվանմանը ZFS հիերարխիայում՝ առաջատար շեղով. pool տեղադրված է որպես /pool, տվյալների հավաքածու parent տեղադրված է /pool/parent, և երեխայի տվյալների հավաքածուն child տեղադրված է /pool/parent/child. Այնուամենայնիվ, տվյալների բազայի համակարգի ամրացման կետը կարող է փոխվել:
Եթե հստակեցնենք zfs set mountpoint=/lol pool/parent/child, ապա տվյալների հավաքածուն pool/parent/child տեղադրված է համակարգի վրա որպես /lol.
Բացի տվյալների հավաքածուներից, պետք է նշել հատորներ (zvols): Ծավալը մոտավորապես նույնն է, ինչ տվյալների հավաքածուն, բացառությամբ, որ այն իրականում չունի ֆայլային համակարգ, դա պարզապես բլոկ սարք է: Դուք կարող եք, օրինակ, ստեղծել zvol Անունով mypool/myzvol, ապա ձևաչափեք այն ext4 ֆայլային համակարգով, այնուհետև տեղադրեք այդ ֆայլային համակարգը. այժմ դուք ունեք ext4 ֆայլային համակարգ, բայց ZFS-ի անվտանգության բոլոր հատկանիշներով: Սա կարող է հիմար թվալ մեկ մեքենայի վրա, բայց շատ ավելի իմաստալից է որպես հետին պլան iSCSI սարք արտահանելիս:
Բլոկներ
Ֆայլը ներկայացված է մեկ կամ մի քանի բլոկներով: Յուրաքանչյուր բլոկ պահվում է մեկ վիրտուալ սարքի վրա: Բլոկի չափը սովորաբար հավասար է պարամետրին գրառումների չափը, բայց կարող է կրճատվել 2^ հերթափոխեթե այն պարունակում է մետատվյալներ կամ փոքր ֆայլ:
Մենք իսկապես իրականում Չկատակեք կատարման հսկայական տուգանքի մասին, եթե դուք չափազանց փոքր տեղաշարժ եք սահմանել
ZFS լողավազանում բոլոր տվյալները, ներառյալ մետատվյալները, պահվում են բլոկներում: Բլոկի առավելագույն չափը յուրաքանչյուր տվյալների հավաքածուի համար սահմանվում է սեփականության մեջ recordsize (ռեկորդային չափս): Գրառման չափը կարող է փոխվել, բայց դա չի փոխի որևէ բլոկների չափը կամ գտնվելու վայրը, որոնք արդեն գրվել են տվյալների բազայում. այն ազդում է միայն նոր բլոկների վրա, ինչպես դրանք գրված են:
Եթե այլ բան նշված չէ, ընթացիկ լռելյայն ռեկորդային չափը 128 ԿԲ է: Դա մի տեսակ բարդ փոխզիջում է, որտեղ կատարումը կատարյալ չէ, բայց շատ դեպքերում դա նույնպես սարսափելի չէ: Recordsize կարող է սահմանվել ցանկացած արժեքի 4K-ից մինչև 1M (ընդլայնված կարգավորումներով recordsize դուք կարող եք ավելի շատ տեղադրել, բայց դա հազվադեպ է լավ գաղափար):
Ցանկացած բլոկ վերաբերում է միայն մեկ ֆայլի տվյալներին. դուք չեք կարող երկու տարբեր ֆայլեր խցկել մեկ բլոկի մեջ: Յուրաքանչյուր ֆայլ բաղկացած է մեկ կամ մի քանի բլոկներից՝ կախված չափից: Եթե ֆայլի չափը փոքր է, քան ռեկորդային չափը, այն կպահվի ավելի փոքր բլոկի չափով. օրինակ, 2 ԿԲ ֆայլով բլոկը կզբաղեցնի սկավառակի միայն մեկ 4 ԿԲ հատված:
Եթե ֆայլը բավականաչափ մեծ է և պահանջում է մի քանի բլոկ, ապա այս ֆայլով բոլոր գրառումները կլինեն չափի recordsize - ներառյալ վերջին մուտքը, որի հիմնական մասը կարող է լինել .
զվոլները սեփականություն չունեն recordsize — փոխարենը նրանք ունեն համարժեք սեփականություն volblocksize.
Ոլորտներ
Վերջին, ամենահիմնական շինանյութը ոլորտն է: Դա ամենափոքր ֆիզիկական միավորն է, որը կարելի է գրել կամ կարդալ հիմքում ընկած սարքից: Մի քանի տասնամյակների ընթացքում սկավառակների մեծ մասն օգտագործում էր 512 բայթանոց հատվածներ: Վերջերս սկավառակների մեծ մասը կազմաձևված է 4 KiB սեկտորների համար, իսկ որոշները, հատկապես SSD-ները, ունեն 8 KiB հատված կամ նույնիսկ ավելին:
ZFS համակարգն ունի հատկություն, որը թույլ է տալիս ձեռքով սահմանել հատվածի չափը: Այս գույքը ashift. Ինչ-որ չափով շփոթեցնող է, որ տեղաշարժը երկուսի ուժ է: Օրինակ, ashift=9 նշանակում է հատվածի չափը 2^9 կամ 512 բայթ:
ZFS-ը հարցնում է օպերացիոն համակարգին՝ յուրաքանչյուր բլոկ սարքի մասին մանրամասն տեղեկություններ ստանալու համար, երբ այն ավելացվում է նոր vdev-ին, և տեսականորեն ավտոմատ կերպով տեղադրում է ashift-ը՝ հիմնվելով այդ տեղեկատվության վրա: Ցավոք սրտի, շատ կրիչներ ստում են իրենց հատվածի չափերը՝ Windows XP-ի հետ համատեղելիությունը պահպանելու համար (որն անկարող էր հասկանալ սեկտորի այլ չափերի կրիչներ):
Սա նշանակում է, որ ZFS-ի ադմինիստրատորին խստորեն խորհուրդ է տրվում իմանալ իրենց սարքերի իրական հատվածի չափերը և ձեռքով սահմանել ashift. Եթե տեղաշարժը շատ ցածր է դրված, ապա կարդալու/գրելու գործողությունների թիվը աստղաբաշխականորեն ավելանում է: Այսպիսով, 512 բայթանոց «սեկտորներ» գրել իրական 4 ԿԲ սեկտորում, նշանակում է, որ պետք է գրել առաջին «սեկտորը», այնուհետև կարդալ 4 ԿԲ սեկտորը, փոփոխել այն երկրորդ 512 բայթանոց «սեկտորով», հետ գրել այն նորին: 4 KiB հատված և այլն յուրաքանչյուր մուտքի համար:
Իրական աշխարհում նման տուգանք հարվածում է Samsung EVO SSD-ներին, որոնց համար ashift=13, բայց այս SSD-ները ստում են իրենց հատվածի չափի մասին, և, հետևաբար, լռելյայն սահմանված է ashift=9. Եթե փորձառու համակարգի ադմինիստրատորը չի փոխում այս կարգավորումը, ապա այս SSD-ն աշխատում է ավելի դանդաղ սովորական մագնիսական HDD:
Համեմատության համար՝ չափազանց մեծ չափի համար ashift գործնականում տուգանք չկա. Չկա իրական կատարողականի տույժ, և չօգտագործված տարածքի ավելացումը անսահման փոքր է (կամ զրոյական՝ սեղմումը միացված է): Հետևաբար, մենք խստորեն խորհուրդ ենք տալիս տեղադրել նույնիսկ այն կրիչներ, որոնք օգտագործում են 512 բայթ հատվածներ ashift=12 կամ նույնիսկ ashift=13վստահությամբ դիմակայել ապագային.
Գույքը ashift սահմանված է յուրաքանչյուր vdev վիրտուալ սարքի համար, և ոչ լողավազանի համար, ինչպես շատերը սխալմամբ կարծում են, և տեղադրվելուց հետո չի փոխվում: Եթե դուք պատահաբար հարվածել եք ashift երբ լողավազանում նոր vdev եք ավելացնում, դուք անդառնալիորեն աղտոտել եք այդ լողավազանը ցածր արդյունավետությամբ սարքով, և սովորաբար այլ ելք չի մնում, քան քանդել լողավազանը և սկսել նորից: Նույնիսկ vdev-ի հեռացումը ձեզ չի փրկի կոտրված կոնֆիգուրացիայից ashift!
Պատճենել-գրելու մեխանիզմ
Եթե սովորական ֆայլային համակարգը պետք է վերագրանցի տվյալները, այն փոխում է յուրաքանչյուր բլոկի գտնվելու վայրը
Պատճենել-գրելու ֆայլային համակարգը գրում է նոր բլոկ տարբերակը և ապակողպում է հին տարբերակը
Վերացականում, եթե անտեսենք բլոկների իրական ֆիզիկական դիրքը, ապա մեր «տվյալների գիսաստղը» պարզեցվում է «տվյալների ճիճու», որը շարժվում է ձախից աջ հասանելի տարածության քարտեզի վրա։
Այժմ մենք կարող ենք լավ պատկերացում կազմել այն մասին, թե ինչպես են աշխատում պատճենահանման վրա գրված ակնոցները. յուրաքանչյուր բլոկ կարող է պատկանել մի քանի ակնթարթների և կպահպանվի այնքան ժամանակ, մինչև չոչնչացվեն բոլոր հարակից նկարները:
Copy on Write (CoW) մեխանիզմը հիմնարար հիմքն է այն բանի, թե ինչն է ZFS-ին դարձնում նման զարմանալի համակարգ: Հիմնական հայեցակարգը պարզ է. եթե դուք խնդրեք ավանդական ֆայլային համակարգին փոխել ֆայլը, այն կանի հենց այն, ինչ դուք խնդրել եք: Եթե դուք նույնը խնդրեք պատճենել-գրելու ֆայլային համակարգից, նա կասի «ok», բայց կստի ձեզ:
Փոխարենը, պատճենահանման վրա գրելու ֆայլային համակարգը գրում է փոփոխված բլոկի նոր տարբերակը և այնուհետև թարմացնում ֆայլի մետատվյալները՝ հին բլոկն անջատելու և նոր բլոկը, որը դուք գրել եք դրան:
Հին բլոկը անջատելը և նորը կապելը կատարվում է մեկ գործողությամբ, ուստի այն չի կարող ընդհատվել. եթե դա տեղի ունենա հետո անջատեք, դուք ունեք ֆայլի նոր տարբերակը, իսկ եթե շուտ անջատեք, ապա ունեք հին տարբերակը: . Ամեն դեպքում, ֆայլային համակարգում կոնֆլիկտներ չեն լինի։
ZFS-ում պատճենահանումը տեղի է ունենում ոչ միայն ֆայլային համակարգի, այլև սկավառակի կառավարման մակարդակում: Սա նշանակում է, որ ZFS-ի վրա չի ազդում սպիտակ տարածությունը () - երևույթ, երբ շերտը ժամանակ ուներ միայն մասամբ ձայնագրելու մինչև համակարգի խափանումը, վերագործարկումից հետո զանգվածի վնասով: Այստեղ շերտագիծը գրված է ատոմային, vdev միշտ հաջորդական է, և .
ZIL: ZFS մտադրությունների մատյան
ZFS համակարգը հատուկ ձևով է վերաբերվում համաժամանակյա գրություններին. այն ժամանակավորապես, բայց անմիջապես պահում է դրանք ZIL-ում, նախքան դրանք ընդմիշտ գրելը հետագայում ասինխրոն գրությունների հետ միասին:
Սովորաբար, ZIL-ում գրված տվյալները այլևս երբեք չեն կարդացվում: Բայց դա հնարավոր է համակարգի խափանումից հետո
SLOG-ը կամ երկրորդական LOG սարքը պարզապես հատուկ և ցանկալի է շատ արագ vdev է, որտեղ ZIL-ը կարող է պահվել հիմնական պահեստից առանձին:
Խափանումից հետո ZIL-ի բոլոր կեղտոտ տվյալները վերարտադրվում են. այս դեպքում ZIL-ը գտնվում է SLOG-ի վրա, ուստի այն վերարտադրվում է այնտեղից:
Գոյություն ունեն գրելու գործողությունների երկու հիմնական կատեգորիա՝ համաժամանակ (համաժամ) և ասինխրոն (ասինխրոն): Աշխատանքային բեռների մեծ մասի համար գրությունների ճնշող մեծամասնությունը ասինխրոն են. ֆայլային համակարգը թույլ է տալիս դրանք խմբավորվել և թողարկվել խմբաքանակով՝ նվազեցնելով մասնատումը և զգալիորեն մեծացնելով թողունակությունը:
Սինխրոնիզացված ձայնագրությունները բոլորովին այլ խնդիր են։ Երբ հավելվածը պահանջում է համաժամանակյա գրություն, այն ֆայլային համակարգին ասում է. հենց հիմամինչ այդ ես այլ բան չեմ կարող անել»: Հետևաբար, համաժամանակյա գրառումները պետք է անհապաղ միացվեն սկավառակին, և եթե դա մեծացնում է մասնատումը կամ նվազեցնում թողունակությունը, ապա այդպես էլ լինի:
ZFS-ն այլ կերպ է մշակում համաժամանակյա գրությունները, քան սովորական ֆայլային համակարգերը. դրանք անմիջապես սովորական պահեստավորմանը հանձնելու փոխարեն, ZFS-ը դրանք հանձնում է հատուկ պահեստային տարածքի, որը կոչվում է ZFS Intent Log կամ ZIL: Խաբեությունն այն է, որ այս գրառումները նույնպես մնում են հիշողության մեջ՝ միավորվելով սովորական ասինխրոն գրելու հարցումների հետ միասին, որոնք հետագայում պետք է լցվեն պահեստում՝ որպես միանգամայն նորմալ TXG (Գործարքի խմբեր):
Նորմալ աշխատանքի դեպքում ZIL-ը գրվում է և այլևս երբեք չի կարդացվում: Երբ մի քանի պահից հետո ZIL-ի գրառումները տեղադրվում են RAM-ից սովորական TXG-ների հիմնական պահեստում, դրանք անջատվում են ZIL-ից: Միակ անգամ ZIL-ից ինչ-որ բան կարդացվում է լողավազանի ներմուծման ժամանակ:
Եթե ZFS-ը ձախողվի՝ օպերացիոն համակարգի խափանում կամ հոսանքազրկում, քանի դեռ կան տվյալներ ZIL-ում, այդ տվյալները կկարդան հաջորդ լողավազանի ներմուծման ժամանակ (օրինակ, երբ վթարային համակարգը վերագործարկվի): ZIL-ի ցանկացած բան կկարդացվի, կխմբավորվի TXG-ների մեջ, կհանձնվի հիմնական պահեստին և այնուհետև կկտրվի ZIL-ից ներմուծման գործընթացում:
vdev օգնական դասերից մեկը կոչվում է LOG կամ SLOG՝ LOG-ի երկրորդական սարքը։ Այն ունի մեկ նպատակ՝ լողավազանին տրամադրել առանձին, և ցանկալի է շատ ավելի արագ, շատ գրելու դիմացկուն vdev՝ ZIL-ը պահելու համար, ZIL-ը հիմնական vdev խանութում պահելու փոխարեն: ZIL-ն ինքն իրեն նույնն է պահում, անկախ նրանից, թե որտեղ է այն պահվում, բայց եթե LOG vdev-ն ունի գրելու շատ բարձր կատարողականություն, համաժամանակյա գրառումներն ավելի արագ կլինեն:
Լողավազանում LOG-ով vdev ավելացնելը չի աշխատում չի կարող բարելավել ասինխրոն գրելու կատարումը, նույնիսկ եթե բոլոր գրառումները պարտադրեք ZIL-ին zfs set sync=always, դրանք դեռ կկապվեն TXG-ի հիմնական պահեստին նույն ձևով և նույն արագությամբ, ինչ առանց գրանցամատյանի: Միակ ուղղակի կատարողականի բարելավումը համաժամանակյա գրումների ուշացումն է (քանի որ գրանցամատյանների արագությունը արագացնում է գործողությունները): sync).
Այնուամենայնիվ, մի միջավայրում, որն արդեն պահանջում է շատ համաժամանակյա գրություններ, vdev LOG-ը կարող է անուղղակիորեն արագացնել ասինխրոն և ոչ քեշավորված ընթերցումները: ZIL-ի գրառումները առանձին vdev LOG-ում բեռնաթափելը նշանակում է ավելի քիչ վիճաբանություն IOPS-ի համար առաջնային պահեստավորման վրա, ինչը որոշ չափով բարելավում է բոլոր ընթերցումների և գրելու կատարումը:
Պատկերներ
Պատճեն-գրելու մեխանիզմը նաև անհրաժեշտ հիմք է ZFS ատոմային նկարահանումների և աճող ասինխրոն կրկնօրինակման համար: Ակտիվ ֆայլային համակարգն ունի ցուցիչի ծառ, որը նշում է բոլոր գրառումները ընթացիկ տվյալներով. երբ լուսանկարում եք լուսանկարը, դուք պարզապես պատճենում եք այս ցուցիչի ծառը:
Երբ գրառումը վերագրվում է ակտիվ ֆայլային համակարգում, ZFS-ը նախ գրում է նոր բլոկ տարբերակը չօգտագործված տարածության մեջ: Այնուհետև այն անջատում է բլոկի հին տարբերակը ընթացիկ ֆայլային համակարգից: Բայց եթե որոշ պատկեր վերաբերում է հին բլոկին, այն դեռ մնում է անփոփոխ: Հին բլոկը իրականում չի վերականգնվի որպես ազատ տարածություն, մինչև չոչնչացվեն այս բլոկին վերաբերող բոլոր ակնարկները:
Վերօրինակման
Իմ Steam գրադարանը 2015-ին 158 ԳԲ էր և ներառում էր 126 ֆայլ: Սա բավականին մոտ է rsync-ի համար օպտիմալ իրավիճակին. ZFS-ի վերարտադրությունը ցանցում եղել է «միայն» 927%-ով ավելի արագ:
Նույն ցանցում Windows 40 վիրտուալ մեքենայի մեկ 7 ԳԲ պատկերի ֆայլի կրկնօրինակումը բոլորովին այլ պատմություն է: ZFS-ի կրկնօրինակումը 289 անգամ ավելի արագ է, քան rsync-ը, կամ «միայն» 161 անգամ ավելի արագ, եթե բավականաչափ խելամիտ եք rsync կանչելու համար --inplace-ով:
Երբ VM-ի պատկերը մասշտաբավորվում է, rsync-ի խնդիրները մեծանում են դրա հետ: 1,9 TiB-ն այնքան էլ մեծ չէ ժամանակակից VM պատկերի համար, բայց բավականաչափ մեծ է, որ ZFS-ի կրկնօրինակումը 1148 անգամ ավելի արագ է, քան rsync-ը, նույնիսկ rsync-ի --inplace արգումենտի դեպքում:
Երբ հասկանաք, թե ինչպես են աշխատում նկարները, պետք է հեշտ լինի հասկանալ կրկնօրինակման էությունը: Քանի որ snapshot-ը պարզապես գրանցումների ցուցիչների ծառ է, հետևում է, որ եթե մենք անենք zfs send snapshot, ապա մենք ուղարկում ենք և՛ այս ծառը, և՛ դրա հետ կապված բոլոր գրառումները: Երբ սա ուղարկենք zfs send в zfs receive թիրախի վրա այն գրում է և՛ բլոկի իրական բովանդակությունը, և՛ ցուցիչների ծառը, որոնք վերաբերում են թիրախային տվյալների բլոկներին:
Երկրորդում ամեն ինչ ավելի հետաքրքիր է դառնում zfs send. Այժմ մենք ունենք երկու համակարգ, որոնցից յուրաքանչյուրը պարունակում է poolname/datasetname@1, և դուք նոր լուսանկար եք անում poolname/datasetname@2. Հետեւաբար, բնօրինակ լողավազանում դուք ունեք datasetname@1 и datasetname@2, իսկ թիրախային լողավազանում առայժմ միայն առաջին նկարը datasetname@1.
Քանի որ մենք ունենք ընդհանուր պատկեր աղբյուրի և թիրախի միջև datasetname@1, մենք կարող ենք դա անել աստիճանական zfs send դրա վրայով։ Երբ համակարգին ասում ենք zfs send -i poolname/datasetname@1 poolname/datasetname@2, այն համեմատում է երկու ցուցիչ ծառեր: Ցանկացած ցուցիչ, որը միայն գոյություն ունի @2, ակնհայտորեն վերաբերում են նոր բլոկներին, ուստի մեզ անհրաժեշտ է այս բլոկների բովանդակությունը:
Հեռավոր համակարգի վրա, վերամշակելով աճող send նույնքան պարզ: Սկզբում մենք գրում ենք հոսքի մեջ ներառված բոլոր նոր գրառումները send, այնուհետև ավելացրեք ցուցիչներ այդ բլոկներին: Voila, մենք ունենք @2 նոր համակարգում!
ZFS-ի ասինխրոն աճող կրկնօրինակումը հսկայական բարելավում է ավելի վաղ ոչ ակնթարթային մեթոդների համեմատ, ինչպիսին է rsync-ը: Երկու դեպքում էլ փոխանցվում են միայն փոփոխված տվյալները, բայց նախ պետք է rsync-ը կարդալ սկավառակից բոլոր տվյալները երկու կողմերից՝ գումարը ստուգելու և համեմատելու համար: Ի հակադրություն, ZFS-ի կրկնօրինակումը ոչինչ չի կարդում, բացի ցուցիչի ծառերից, և բոլոր բլոկներից, որոնք առկա չեն ընդհանուր նկարում:
Ներկառուցված սեղմում
Պատճեն-գրելու մեխանիզմը նաև պարզեցնում է ներկառուցված սեղմման համակարգը: Ավանդական ֆայլային համակարգում սեղմումը խնդրահարույց է. փոփոխված տվյալների և՛ հին տարբերակը, և՛ նոր տարբերակը գտնվում են նույն տարածքում:
Եթե դիտարկենք ֆայլի մեջտեղում գտնվող տվյալների մի մասը, որը սկսում է կյանքը որպես զրոյական մեգաբայթ 0x00000000-ից և այլն, ապա շատ հեշտ է այն սեղմել սկավառակի մեկ հատվածի վրա: Բայց ի՞նչ տեղի կունենա, եթե այդ զրոյական մեգաբայթը փոխարինենք JPEG-ի կամ կեղծ պատահական աղմուկի նման չսեղմվող տվյալների հետ: Անսպասելիորեն, տվյալների այս մեգաբայթը կպահանջի ոչ թե մեկ, այլ 256 4 KiB սեկտոր, և սկավառակի այս վայրում միայն մեկ հատված է վերապահված:
ZFS-ն այս խնդիրը չունի, քանի որ փոփոխված գրառումները միշտ գրվում են չօգտագործված տարածության մեջ. սկզբնական բլոկը զբաղեցնում է միայն մեկ 4 ԿԲ սեկտոր, իսկ նոր գրառումը կզբաղեցնի 256, բայց սա խնդիր չէ. վերջերս փոփոխված հատվածը միջին» ֆայլը կգրվի չօգտագործված տարածության մեջ՝ անկախ նրանից՝ դրա չափը փոխվել է, թե ոչ, ուստի ZFS-ի համար սա բավականին սովորական իրավիճակ է։
Native ZFS սեղմումն անջատված է լռելյայնորեն, և համակարգը առաջարկում է միացնելի ալգորիթմներ՝ ներկայումս LZ4, gzip (1-9), LZJB և ZLE:
- LZ4 հոսքային ալգորիթմ է, որն առաջարկում է չափազանց արագ սեղմում և ապակոմպրեսիա և արդյունավետության առավելություններ օգտագործման դեպքերի մեծ մասի համար՝ նույնիսկ բավականին դանդաղ պրոցեսորների վրա:
- GZIP հարգելի ալգորիթմ է, որը բոլոր Unix օգտագործողները գիտեն և սիրում են: Այն կարող է իրականացվել սեղմման 1-9 մակարդակներով, սեղմման գործակիցը և պրոցեսորի օգտագործումը մեծանում են, քանի որ այն մոտենում է 9-րդ մակարդակին: Ալգորիթմը հարմար է բոլոր տեքստի (կամ այլ խիստ սեղմելի) օգտագործման դեպքերի համար, բայց հակառակ դեպքում հաճախ առաջացնում է պրոցեսորի խնդիրներ. խնամքով, հատկապես բարձր մակարդակներում:
- LZJB ZFS-ի բնօրինակ ալգորիթմն է: Այն հնացած է և այլևս չպետք է օգտագործվի, LZ4-ն ամեն կերպ գերազանցում է նրան։
- ՎԱՏ - զրոյական մակարդակի կոդավորում, զրոյական մակարդակի կոդավորում: Այն ընդհանրապես չի դիպչում նորմալ տվյալներին, այլ սեղմում է զրոների մեծ հաջորդականությունը: Օգտակար է ամբողջովին չսեղմվող տվյալների հավաքածուների համար (օրինակ՝ JPEG, MP4 կամ այլ արդեն սեղմված ձևաչափեր), քանի որ այն անտեսում է չսեղմվող տվյալները, բայց սեղմում է չօգտագործված տարածքը ստացված գրառումներում:
Մենք առաջարկում ենք LZ4 սեղմում գրեթե բոլոր օգտագործման դեպքերի համար; կատարման տույժը, երբ բախվում է անսեղմելի տվյալներին, շատ փոքր է, և աճը բնորոշ տվյալների համար կատարողականը նշանակալի է: Windows օպերացիոն համակարգի նոր տեղադրման համար վիրտուալ մեքենայի պատկերի պատճենում (նոր տեղադրված ՕՀ, ներսում դեռ տվյալներ չկան) compression=lz4 անցել է 27%-ով ավելի արագ, քան հետ compression=noneՄեջ .
ARC - հարմարվողական փոխարինող քեշ
ZFS-ը միակ ժամանակակից ֆայլային համակարգն է, որի մասին մենք գիտենք, որն օգտագործում է իր կարդալու քեշավորման մեխանիզմը, այլ ոչ թե հենվում է օպերացիոն համակարգի էջի քեշի վրա՝ RAM-ում վերջերս կարդացած բլոկների պատճենները պահելու համար:
Չնայած հայրենի քեշը առանց խնդիրների չէ, ZFS-ը չի կարող պատասխանել հիշողության բաշխման նոր հարցումներին այնքան արագ, որքան միջուկը, ուստի նոր մարտահրավեր է malloc() հիշողության վրա տեղաբաշխումը կարող է ձախողվել, եթե նրան անհրաժեշտ է RAM-ը, որը ներկայումս զբաղեցնում է ARC-ը: Բայց կան լավ պատճառներ ձեր սեփական քեշը օգտագործելու համար, գոնե առայժմ:
Բոլոր հայտնի ժամանակակից օպերացիոն համակարգերը, ներառյալ MacOS-ը, Windows-ը, Linux-ը և BSD-ն, օգտագործում են LRU (Last Recently Used) ալգորիթմը՝ էջի քեշը իրականացնելու համար: Սա պարզունակ ալգորիթմ է, որը յուրաքանչյուր ընթերցումից հետո մղում է քեշավորված բլոկը «վերև հերթում» և բլոկները մղում է «հերթի ներքև»՝ ըստ անհրաժեշտության՝ ավելացնելու նոր քեշի բաց թողած (բլոկներ, որոնք պետք է կարդացվեին սկավառակից, ոչ թե քեշից): վերև.
Ալգորիթմը սովորաբար լավ է աշխատում, բայց մեծ աշխատանքային տվյալների շտեմարաններով համակարգերում LRU-ն հեշտությամբ հանգեցնում է թրաշման՝ հաճախակի անհրաժեշտ բլոկների հեռացում, որպեսզի տեղ բացվի բլոկների համար, որոնք այլևս երբեք չեն կարդացվի քեշից:
շատ ավելի քիչ միամիտ ալգորիթմ է, որը կարելի է դիտարկել որպես «կշռված» քեշ: Ամեն անգամ, երբ քեշավորված բլոկը կարդացվում է, այն դառնում է մի փոքր ավելի «ծանր» և դժվարանում է հեռացնել, և նույնիսկ բլոկը հեռացնելուց հետո: հետեւել որոշակի ժամանակահատվածում։ Այն բլոկը, որը հեռացվել է, բայց այնուհետև պետք է նորից կարդալ քեշի մեջ, նույնպես կդառնա «ավելի ծանր»:
Այս ամենի վերջնական արդյունքը քեշն է շատ ավելի բարձր հարվածների հարաբերակցությամբ, քեշի հարվածների հարաբերակցությունը (ընթերցվում է քեշից) և քեշի բացթողումները (ընթերցվում է սկավառակից): Սա չափազանց կարևոր վիճակագրություն է. ոչ միայն քեշի հարվածներն ավելի արագ են մատուցվում, այլ նաև քեշի բացթողումները կարող են ավելի արագ սպասարկվել, քանի որ որքան շատ են քեշի հարվածները, այնքան քիչ են սկավառակի միաժամանակյա հարցումները և այնքան ցածր է մնացած բացթողումները, որոնք պետք է: մատուցել սկավառակով։
Ամփոփում
ZFS-ի հիմնական իմաստաբանությունը սովորելուց հետո՝ ինչպես է աշխատում պատճենումը գրելու վրա, ինչպես նաև պահեստային լողավազանների, վիրտուալ սարքերի, բլոկների, սեկտորների և ֆայլերի միջև փոխհարաբերությունները, մենք պատրաստ ենք իրական թվերի հետ քննարկել իրական աշխատանքը:
Հաջորդ մասում մենք կանդրադառնանք հայելային vdevs-ով և RAIDz-ով լողավազանների իրական աշխատանքին՝ ընդդեմ միմյանց, ինչպես նաև՝ ընդդեմ մեր ուսումնասիրած Linux միջուկի ավանդական RAID տոպոլոգիաների: .
Սկզբում մենք ուզում էինք լուսաբանել միայն հիմունքները՝ իրենք՝ ZFS տոպոլոգիաները, բայց հետո այդպիսին Եկեք պատրաստվենք խոսել ZFS-ի ավելի առաջադեմ տեղադրման և թյունինգի մասին, ներառյալ օժանդակ vdev տեսակների օգտագործումը, ինչպիսիք են L2ARC, SLOG և Special Allocation:
Source: www.habr.com