Այսօր մենք կխոսենք Unity / Unity XT պահեստավորման համակարգում ներդրված հետաքրքիր տեխնոլոգիայի մասին՝ FAST VP: Եթե առաջին անգամ եք լսել Unity-ի մասին, ապա հոդվածի վերջում տեղադրված հղումը կարող է օգտագործվել համակարգի բնութագրերին ծանոթանալու համար: Ես ավելի քան մեկ տարի աշխատել եմ FAST VP-ում Dell EMC նախագծի թիմում: Այսօր ես ուզում եմ ավելի մանրամասն խոսել այս տեխնոլոգիայի մասին և բացահայտել դրա ներդրման որոշ մանրամասներ: Իհարկե, միայն նրանք, որոնց բացահայտումը թույլատրվում է։ Եթե դուք հետաքրքրված եք տվյալների արդյունավետ պահպանման հարցերով կամ պարզապես ամբողջությամբ չեք հասկացել փաստաթղթերը, ապա այս հոդվածը, անշուշտ, օգտակար և հետաքրքիր կլինի:
Ես ձեզ անմիջապես կասեմ այն, ինչը չի լինի նյութում: Մրցակիցների որոնում և նրանց հետ համեմատություն չի լինելու։ Ես նույնպես չեմ նախատեսում բաց կոդով նմանատիպ տեխնոլոգիաների մասին խոսել, քանի որ հետաքրքրասեր ընթերցողն արդեն գիտի դրանց մասին։ Եվ, իհարկե, չեմ պատրաստվում որևէ բան գովազդել։
պահեստային շերտավորում: FAST VP-ի նպատակներն ու խնդիրները
FAST VP-ն նշանակում է Լիովին ավտոմատացված պահեստավորում վիրտուալ լողավազանի համար: Դժվա՞ր է։ Ոչինչ, մենք կպարզենք: Tiering-ը տվյալների պահպանման կազմակերպման միջոց է, որում կան մի քանի մակարդակներ (մակարդակներ), որտեղ այդ տվյալները պահվում են։ Յուրաքանչյուրն ունի իր առանձնահատկությունները: Ամենակարևորը՝ տեղեկատվության միավորի պահպանման կատարումը, ծավալը և գինը: Նրանց միջեւ, իհարկե, կա հարաբերություն։
Tiering-ի կարևոր առանձնահատկությունն այն է, որ տվյալների հասանելիությունն ապահովվում է միատեսակ՝ անկախ այն բանից, թե ներկայումս ինչ մակարդակի վրա է այն գտնվում, և լողավազանի չափը հավասար է դրանում ներառված ռեսուրսների չափերի գումարին: Այստեղ է գտնվում քեշի տարբերությունը. քեշի չափը չի ավելացվում ռեսուրսի ընդհանուր քանակին (այս դեպքում՝ լողավազան), և քեշի տվյալները կրկնօրինակում են որոշ տվյալներ հիմնական միջավայրից (կամ կկրկնօրինակվեն, եթե քեշից տվյալները դեռ չեն գրվել): Նաև տվյալների բաշխումն ըստ մակարդակների թաքնված է օգտագործողից: Այսինքն, նա չի տեսնում, թե կոնկրետ ինչ տվյալներ են գտնվում յուրաքանչյուր մակարդակում, թեև նա կարող է անուղղակիորեն ազդել դրա վրա՝ քաղաքականություն սահմանելով (դրանց մասին ավելի ուշ):
Հիմա եկեք նայենք Unity-ում պահեստավորման մակարդակի իրականացման առանձնահատկություններին: Unity-ում կա 3 մակարդակ կամ մակարդակ.
- Ծայրահեղ կատարում (SSD)
- Գործողություն (SAS HDD 10k/15k RPM)
- Տարողություն (NL-SAS HDD 7200 RPM)
Դրանք ներկայացված են կատարողականի և գնի նվազման կարգով: Ծայրահեղ կատարողականությունը ներառում է միայն պինդ վիճակի կրիչներ (SSD): Մյուս երկու մակարդակներում կան մագնիսական սկավառակակիրներ, որոնք տարբերվում են ռոտացիայի արագությամբ և, համապատասխանաբար, կատարողականությամբ:
Նույն մակարդակի և նույն չափի պահեստային կրիչները միավորվում են RAID զանգվածի մեջ՝ ձևավորելով RAID խումբ (RAID խումբ, կրճատ՝ RG); Դուք կարող եք կարդալ առկա և առաջարկվող RAID մակարդակների մասին պաշտոնական փաստաթղթերում: Մեկ կամ մի քանի մակարդակների RAID խմբերից ձևավորվում են պահեստային լողավազաններ, որոնցից այնուհետև բաժանվում է ազատ տարածք: Իսկ արդեն լողավազանից հատկացված է ֆայլային համակարգերի և LUN-ների համար։
Ինչու՞ ինձ պետք է Tiering:
Կարճ և վերացական. նվազագույն ռեսուրսներով ավելի շատ արդյունքների հասնելու համար: Ավելի կոնկրետ, արդյունքը սովորաբար հասկացվում է որպես պահեստավորման համակարգի բնութագրերի մի շարք՝ մուտքի արագություն և ժամանակ, պահեստավորման արժեքը և այլն: Ռեսուրսների նվազագույն քանակը նշանակում է նվազագույն ծախսեր՝ փող, էներգիա և այլն։ FAST VP-ն պարզապես իրականացնում է Unity / Unity XT պահեստավորման համակարգում տվյալների վերաբաշխման մեխանիզմները տարբեր մակարդակներում: Եթե հավատում եք ինձ, կարող եք բաց թողնել հաջորդ պարբերությունը։ Մնացածի համար մի քիչ էլ կասեմ։
Տվյալները պատշաճ կերպով դասավորելով՝ դուք կարող եք խնայել պահպանման ընդհանուր ծախսերը՝ զոհաբերելով որոշ հազվադեպ օգտագործվող տեղեկությունների հասանելիության արագությունը, և բարելավել կատարողականությունը՝ հաճախակի հասանելի տվյալներն ավելի արագ կրիչներ տեղափոխելով: Այստեղ ինչ-որ մեկը կարող է առարկել, որ նույնիսկ առանց մակարդակի, նորմալ ադմինը գիտի, թե որտեղ տեղադրի ինչ տվյալներ, պահեստավորման համակարգի ինչ բնութագրիչներ են ցանկալի իր առաջադրանքի համար և այլն: Իհարկե, դա ճիշտ է, բայց տվյալների «ձեռքով» բաշխումն ունի իր թերությունները.
- պահանջում է ադմինիստրատորի ժամանակ և ուշադրություն.
- միշտ չէ, որ հնարավոր է «վերաձեւել» պահեստային ռեսուրսները փոփոխվող պայմաններում.
- անհետանում է մի կարևոր առավելություն՝ պահեստավորման տարբեր մակարդակներում տեղակայված ռեսուրսների միասնական հասանելիություն:
Որպեսզի պահեստավորման ադմինները ավելի քիչ անհանգստանան աշխատանքի անվտանգության մասին, ես կավելացնեմ, որ այստեղ անհրաժեշտ է նաև ռեսուրսների իրավասու պլանավորում: Այժմ, երբ աստիճանավորման առաջադրանքները համառոտ նկարագրված են, եկեք տեսնենք, թե ինչ կարող եք ակնկալել FAST VP-ից: Սա սահմանմանը վերադառնալու ժամանակն է: Առաջին երկու բառերը՝ Լիովին ավտոմատացված, բառացիորեն թարգմանվում են որպես «լիովին ավտոմատացված» և նշանակում են, որ մակարդակների բաշխումը տեղի է ունենում ավտոմատ կերպով: Դե, Virtual Pool-ը տվյալների ֆոնդ է, որը ներառում է ռեսուրսներ պահեստավորման տարբեր մակարդակներից: Ահա թե ինչ տեսք ունի այն.
Նայելով առաջ՝ ես կասեմ, որ FAST VP-ն տվյալները տեղափոխում է միայն մեկ լողավազանի ներսում, և ոչ մի քանի լողավազանների միջև:
Առաջադրանքները լուծվել են FAST VP-ի կողմից
Եկեք նախ խոսենք վերացական. Մենք ունենք լողավազան և որոշակի մեխանիզմ, որը կարող է վերաբաշխել տվյալները այս լողավազանի ներսում: Նկատի ունենալով, որ մեր խնդիրն է հասնել առավելագույն արտադրողականության, եկեք ինքներս մեզ հարց տանք՝ ի՞նչ ճանապարհներով կարելի է դրան հասնել։ Դրանցից կարող են լինել մի քանիսը, և այստեղ FAST VP-ն ինչ-որ բան ունի առաջարկելու օգտվողին, քանի որ տեխնոլոգիան ավելին է, քան պարզապես պահեստավորման մակարդակը: Ահա մի քանի ուղիներ FAST VP-ն կարող է բարձրացնել լողավազանի աշխատանքը.
- Տվյալների բաշխում տարբեր տեսակի սկավառակների, մակարդակների վրա
- Տվյալների բաշխում նույն տեսակի սկավառակների միջև
- Լողավազանն ընդլայնելիս տվյալների բաշխում
Նախքան տեսնելը, թե ինչպես են այս առաջադրանքները կատարվում, մենք պետք է իմանանք որոշ էական փաստեր այն մասին, թե ինչպես է աշխատում FAST VP-ն: FAST VP-ն աշխատում է որոշակի չափի բլոկներով՝ 256 մեգաբայթ: Սա տվյալների ամենափոքր հարակից «կտորն» է, որը կարելի է տեղափոխել: Փաստաթղթերում այն կոչվում է այսպես՝ կտոր։ FAST VP-ի տեսանկյունից բոլոր RAID խմբերը բաղկացած են նման «կտորների» մի շարքից։ Համապատասխանաբար, I/O բոլոր վիճակագրությունը կուտակվում է տվյալների նման բլոկների համար: Ինչու՞ է ընտրվել այս բլոկի չափը և արդյո՞ք այն կնվազի: Բլոկը բավականին մեծ է, բայց սա փոխզիջում է տվյալների մանրակրկիտության (փոքր բլոկի չափը - ավելի ճշգրիտ բաշխում) և առկա հաշվողական ռեսուրսների միջև. RAM-ի առկա խիստ սահմանափակումների և մեծ թվով բլոկների դեպքում վիճակագրական տվյալները կարող են չափազանց շատ պահանջել, և հաշվարկների թիվը համամասնորեն կաճի։
Ինչպես FAST VP-ն է տվյալները տեղադրում լողավազանում: Քաղաքական գործիչներ
FAST VP-ով միացված լողավազանում տվյալների տեղադրումը վերահսկելու համար կան հետևյալ քաղաքականությունները.
- Ամենաբարձր մատչելի մակարդակ
- Ավտոմատ մակարդակ
- Սկսեք բարձր, ապա ավտոմատ մակարդակ (կանխադրված)
- Ամենացածր մատչելի մակարդակ
Դրանք ազդում են ինչպես սկզբնական բլոկի տեղաբաշխման վրա (տվյալները սկզբում գրվում են), այնպես էլ հետագա վերաբաշխման վրա։ Երբ տվյալները արդեն տեղադրված են սկավառակների վրա, վերաբաշխումը կսկսվի ըստ ժամանակացույցի կամ ձեռքով:
Ամենաբարձր հասանելի մակարդակը փորձում է տեղադրել նոր բլոկը ամենաբարձր կատարողական մակարդակում: Եթե դրա վրա բավականաչափ տեղ չկա, հաջորդը կատարողականի առումով, բայց այդ դեպքում տվյալները կարող են տեղափոխվել ավելի արդյունավետ մակարդակ (եթե կա տարածք կամ խլել այլ տվյալները): Auto-Tier-ը նոր տվյալներ է տեղադրում տարբեր մակարդակներում՝ ելնելով առկա տարածքի քանակից, և դրանք վերաբաշխում է՝ ելնելով պահանջարկից և ազատ տարածությունից: Սկսեք բարձր, ապա Auto-Tier-ը լռելյայն քաղաքականությունն է և նաև առաջարկվում է: Սկզբում աշխատում է որպես ամենաբարձր հասանելի մակարդակ, այնուհետև տեղափոխում է տվյալները՝ հիմնվելով օգտագործման վիճակագրության վրա: Ամենացածր մատչելի մակարդակի քաղաքականությունը ձգտում է տեղադրել տվյալները ամենաքիչ կատարողական մակարդակում:
Տվյալների փոխանցումը կատարվում է ցածր առաջնահերթությամբ, որպեսզի չխանգարի պահեստավորման համակարգի օգտակար աշխատանքին, այնուամենայնիվ, կա «Տվյալների տեղափոխման արագություն» պարամետր, որը փոխում է առաջնահերթությունը: Այստեղ կա մի յուրահատկություն՝ ոչ բոլոր տվյալների բլոկներն ունեն վերաբաշխման նույն կարգը։ Օրինակ, որպես մետատվյալներ նշված բլոկները նախ կտեղափոխվեն ավելի արագ մակարդակ: Մետատվյալները, այսպես ասած, «տվյալներ են տվյալների մասին», որոշ լրացուցիչ տեղեկություններ, որոնք օգտվողի տվյալներ չեն, բայց պահպանում են դրանց նկարագրությունը: Օրինակ, ֆայլային համակարգում առկա տեղեկատվությունը, թե կոնկրետ ֆայլը որ բլոկում է գտնվում: Սա նշանակում է, որ տվյալների հասանելիության արագությունը կախված է մետատվյալների հասանելիության արագությունից: Հաշվի առնելով, որ մետատվյալները սովորաբար շատ ավելի փոքր են, ակնկալվում է, որ դրանք ավելի արագ սկավառակներ տեղափոխելու առավելություններն ավելի մեծ կլինեն:
Չափանիշներ, որոնք Fast VP-ն օգտագործում է իր աշխատանքում
Յուրաքանչյուր բլոկի հիմնական չափանիշը, եթե շատ կոպիտ է, տվյալների «պահանջարկի» հատկանիշն է, որը կախված է տվյալների հատվածի կարդալու և գրելու գործողությունների քանակից։ Այս հատկանիշը կոչվում է «Ջերմաստիճան»: Կան թեժ տվյալներ, որոնք ավելի թեժ են, քան չպահանջված տվյալները: Այն հաշվարկվում է պարբերաբար, լռելյայն մեկ ժամ ընդմիջումով։
Ջերմաստիճանի հաշվարկման ֆունկցիան ունի հետևյալ հատկությունները.
- I/O-ի բացակայության դեպքում տվյալները ժամանակի ընթացքում «սառչում են»:
- Ժամանակի ընթացքում քիչ թե շատ նույն բեռի դեպքում ջերմաստիճանը սկզբում բարձրանում է, ապա կայունանում որոշակի միջակայքում:
Բացի այդ, հաշվի են առնվում վերը նկարագրված քաղաքականությունները և յուրաքանչյուր մակարդակի ազատ տարածությունը: Պարզության համար կտամ նկար փաստաթղթից։ Այստեղ կարմիր, դեղին և կապույտ գույները ցույց են տալիս համապատասխանաբար բարձր, միջին և ցածր ջերմաստիճան ունեցող բլոկները:
Բայց վերադառնանք առաջադրանքներին: Այսպիսով, մենք կարող ենք սկսել վերլուծել, թե ինչ է արվում FAST VP-ի խնդիրները լուծելու համար:
A. Տվյալների բաշխում տարբեր տեսակի սկավառակների, մակարդակների վրա
Փաստորեն, սա FAST VP-ի հիմնական խնդիրն է: Մնացածը, ինչ-որ իմաստով, դրա ածանցյալներն են։ Կախված ընտրված քաղաքականությունից՝ տվյալները կբաշխվեն պահեստավորման տարբեր մակարդակներում: Առաջին հերթին հաշվի է առնվում տեղաբաշխման քաղաքականությունը, այնուհետև բլոկների ջերմաստիճանը և RAID խմբերի չափը / արագությունը:
Ամենաբարձր/ամենացածր մատչելի մակարդակի քաղաքականության համար ամեն ինչ բավականին պարզ է: Մյուս երկուսի դեպքում այդպես է։ Տվյալները բաշխվում են տարբեր մակարդակներում՝ հաշվի առնելով RAID խմբերի չափն ու կատարումը. այնպես որ բլոկների ընդհանուր «ջերմաստիճանի» և յուրաքանչյուր RAID խմբի «պայմանական առավելագույն կատարման» հարաբերակցությունը մոտավորապես նույնն է: Այսպիսով, բեռը քիչ թե շատ հավասարաչափ բաշխվում է։ Ավելի մեծ պահանջարկ ունեցող տվյալները տեղափոխվում են ավելի արագ մեդիա, հազվադեպ օգտագործվող տվյալները տեղափոխվում են ավելի դանդաղ կրիչներ: Իդեալում, բաշխումը պետք է նման լինի հետևյալին.
Բ. Տվյալների բաշխում նույն տեսակի սկավառակների միջև
Հիշեք, սկզբում ես գրել էի, որ տեղեկատվական կրիչները մեկ կամ ավելի մակարդակները համակցված են մեկ լողավազանի մեջ. Մեկ մակարդակի դեպքում FAST VP-ն նույնպես անելիք ունի: Ցանկացած մակարդակում կատարողականությունը առավելագույնի հասցնելու համար ցանկալի է տվյալների հավասարաչափ բաշխումը սկավառակների վրա: Սա թույլ կտա (տեսականորեն) ստանալ IOPS-ի առավելագույն քանակը: RAID խմբի տվյալները կարելի է համարել հավասարաչափ բաշխված սկավառակների վրա, բայց դա միշտ չէ, որ այդպես է RAID խմբերի միջև: Անհավասարակշռության դեպքում FAST VP-ն տվյալները կտեղափոխի RAID խմբերի միջև՝ համաչափ դրանց չափի և «պայմանական կատարման» (թվային արտահայտությամբ): Պարզության համար ես ցույց կտամ վերաբալանսի սխեման երեք RAID խմբերի միջև.
Գ. Լողավազանն ընդլայնելիս տվյալների բաշխում
Այս առաջադրանքը նախորդի հատուկ դեպքն է և կատարվում է, երբ RAID խումբ է ավելացվում լողավազանում: Որպեսզի նոր ավելացված RAID խումբը չգործի, տվյալների մի մասը կփոխանցվի դրան, ինչը նշանակում է, որ բոլոր RAID խմբերի բեռը կվերաբաշխվի:
SSD մաշվածության հարթեցում
Մաշվածության հարթեցման միջոցով FAST VP-ը կարող է երկարացնել SSD-ի կյանքը, թեև այս հատկությունն ուղղակիորեն կապված չէ Storage Tiering-ի հետ: Քանի որ արդեն կան ջերմաստիճանի տվյալներ, հաշվի է առնվում նաև գրելու գործողությունների քանակը, մենք գիտենք, թե ինչպես տեղափոխել տվյալների բլոկները, տրամաբանական կլինի, որ FAST VP-ն լուծի նաև այս խնդիրը։
Եթե RAID խմբի մեկ գրառումների թիվը զգալիորեն գերազանցում է մյուսին գրվածների թիվը, FAST VP-ն տվյալները կվերաբաշխի ըստ գրությունների քանակի: Սա, մի կողմից, հեռացնում է բեռը և խնայում է որոշ սկավառակների ռեսուրսը, մյուս կողմից՝ ավելացնում է «աշխատանք» ավելի քիչ բեռնվածների համար՝ մեծացնելով ընդհանուր կատարումը:
Այսպիսով, FAST VP-ն իր վրա է վերցնում Storage Tiering-ի ավանդական առաջադրանքները և անում է դրանից մի փոքր ավելին: Այս ամենը թույլ է տալիս արդյունավետ կերպով պահել տվյալները Unity պահեստավորման համակարգում:
Մի քանի խորհուրդներ
- Մի անտեսեք փաստաթղթերի ընթերցումը: Կան լավագույն փորձեր, և դրանք բավականին լավ են աշխատում: Եթե հետեւում եք դրանց, ապա լուրջ խնդիրներ, որպես կանոն, չեն առաջանում։ Մնացած խորհուրդները հիմնականում կրկնում կամ լրացնում են դրանք:
- Եթե դուք կարգավորել և միացրել եք FAST VP-ն, ապա թողեք այն միացված: Թող այն հատկացնի տվյալներ հատկացված ժամկետում և տարին մեկ անգամից քիչ-քիչ և լուրջ ազդեցություն ունենա այլ խնդիրների կատարման վրա։ Նման դեպքերում տվյալների վերաբաշխումը կարող է երկար տևել:
- Զգույշ եղեք տեղափոխման պատուհան ընտրելիս: Թեև դա ակնհայտ է, փորձեք ընտրել Unity-ի վրա նվազագույն ծանրաբեռնվածություն և բավականաչափ ժամանակ հատկացնել:
- Պլանավորեք ձեր պահեստի ընդլայնումը, արեք դա ժամանակին: Սա ընդհանուր առաջարկություն է, որը նույնպես կարևոր է FAST VP-ի համար: Եթե ազատ տարածության քանակը շատ փոքր է, ապա տվյալների տեղաշարժը կդանդաղի կամ անհնար կդառնա: Հատկապես, եթե դուք անտեսել եք 2-րդ կետը:
- FAST VP-ով միացված լողավազանն ընդլայնելիս մի սկսեք ամենադանդաղ կրիչներով: Այսինքն՝ կա՛մ մենք միանգամից ավելացնում ենք բոլոր պլանավորված RAID խմբերը, կա՛մ նախ ավելացնում ենք ամենաարագ սկավառակները։ Այս դեպքում տվյալների վերաբաշխումը նոր «արագ» սկավառակների վրա կբարձրացնի լողավազանի ընդհանուր արագությունը: Հակառակ դեպքում, սկսած «դանդաղ» սկավառակներից, կարող եք շատ տհաճ իրավիճակ ստանալ։ Նախ՝ տվյալները կփոխանցվեն նոր, համեմատաբար դանդաղ սկավառակների վրա, իսկ հետո՝ ավելի արագ սկավառակներ ավելացնելիս՝ հակառակ ուղղությամբ։ Կան նրբերանգներ, որոնք կապված են FAST VP-ի տարբեր քաղաքականության հետ, բայց ընդհանուր դեպքում այս իրավիճակը հնարավոր է:
Եթե դուք նայում եք այս արտադրանքին, ապա կարող եք անվճար փորձել Unity in action-ը՝ ներբեռնելով Unity VSA վիրտուալ սարքը:
Հոդվածի վերջում ես կիսում եմ մի քանի օգտակար հղումներ.
- Page
- - ֆունկցիայի համառոտ նկարագրությունը
- , pdf ձևաչափով
Ամփոփում
Շատ եմ ուզում գրել, բայց հասկանում եմ, որ ոչ բոլոր մանրամասներն են հետաքրքրելու ընթերցողին։ Օրինակ, դուք կարող եք ավելի մանրամասն խոսել այն չափանիշների մասին, որոնցով FAST VP-ն որոշում է կայացնում տվյալների փոխանցման, I/O վիճակագրության վերլուծության գործընթացների մասին: Նաև հետ փոխգործակցության թեման , և սա ձգում է առանձին հոդված: Դուք նույնիսկ կարող եք երևակայել այս տեխնոլոգիայի զարգացման մասին: Հուսով եմ, որ դա ձանձրալի չէր, և ես չեմ ձանձրացրել ձեզ: Կհանդիպենք շուտով:
Source: www.habr.com