Այս հոդվածը գրվել է, որպեսզի օգնի ձեզ ընտրել ճիշտ լուծումը ձեզ համար և հասկանալ SDS-ի տարբերությունները, ինչպիսիք են Gluster-ը, Ceph-ը և Vstorage-ը (Virtuozzo):
Տեքստը օգտագործում է հոդվածների հղումներ՝ որոշակի խնդիրների ավելի մանրամասն բացահայտմամբ, ուստի նկարագրությունները կլինեն հնարավորինս հակիրճ՝ առանց ավելորդ բմբուլների և ներածական տեղեկությունների, որոնք կարող եք, եթե ցանկանում եք, ինքնուրույն ձեռք բերել ինտերնետում:
Իրականում, իհարկե, բարձրացված թեմաները պահանջում են տեքստի հնչերանգներ, բայց ժամանակակից աշխարհում ավելի ու ավելի շատ մարդիկ չեն սիրում շատ կարդալ))), այնպես որ կարող եք արագ կարդալ և ընտրություն կատարել, և եթե ինչ-որ բան կա. պարզ չէ, հետևեք հղումներին կամ google-ում անհասկանալի բառեր))), և այս հոդվածը նման է թափանցիկ փաթաթան այս խորը թեմաների համար, որը ցույց է տալիս լրացումը `յուրաքանչյուր որոշման հիմնական առանցքային կետերը:
Գլուսթեր
Սկսենք Gluster-ից, որն ակտիվորեն օգտագործվում է SDS-ով հիպերկոնվերգացիոն պլատֆորմների արտադրողների կողմից՝ հիմնված վիրտուալ միջավայրերի համար բաց կոդով և կարելի է գտնել RedHat կայքում պահեստավորման բաժնում, որտեղ կարող եք ընտրել SDS-ի երկու տարբերակներից՝ Gluster կամ Ceph:
Gluster-ը բաղկացած է թարգմանիչների կույտից՝ ծառայություններ, որոնք կատարում են ֆայլերի բաշխման բոլոր աշխատանքները և այլն։ Brick-ը ծառայություն է, որը սպասարկում է մեկ սկավառակ, Volume-ը հատոր է (ավազան), որը միավորում է այս աղյուսները: Հաջորդը գալիս է DHT (բաշխված հեշ աղյուսակ) ֆունկցիայի միջոցով ֆայլերը խմբերի բաշխելու ծառայությունը: Մենք չենք ներառի Sharding ծառայությունը նկարագրության մեջ, քանի որ ստորև բերված հղումները նկարագրելու են դրա հետ կապված խնդիրները:
Գրելիս ամբողջ ֆայլը պահվում է աղյուսով և դրա պատճենը միաժամանակ գրվում է աղյուսի վրա երկրորդ սերվերի վրա: Հաջորդը, երկրորդ ֆայլը կգրվի երկու աղյուսներից բաղկացած երկրորդ խմբին (կամ ավելի) տարբեր սերվերների վրա:
Եթե ֆայլերը մոտավորապես նույն չափի են, և ծավալը բաղկացած է միայն մեկ խմբից, ապա ամեն ինչ լավ է, բայց այլ պայմաններում նկարագրություններից կառաջանան հետևյալ խնդիրները.
- Խմբերում տարածքն օգտագործվում է անհավասարաչափ, դա կախված է ֆայլերի չափից, և եթե խմբում բավարար տարածք չկա ֆայլ գրելու համար, դուք սխալ կստանաք, ֆայլը չի գրվի և չի վերաբաշխվի մեկ այլ խմբի։ ;
- մեկ ֆայլ գրելիս IO-ն գնում է միայն մեկ խումբ, մնացածը պարապ են.
- Դուք չեք կարող ստանալ ամբողջ ծավալի IO մեկ ֆայլ գրելիս.
- և ընդհանուր հայեցակարգը ավելի քիչ արդյունավետ է թվում բլոկների մեջ տվյալների բաշխման բացակայության պատճառով, որտեղ ավելի հեշտ է հավասարակշռել և լուծել միասնական բաշխման խնդիրը, և ոչ այնպես, ինչպես հիմա ամբողջ ֆայլը գնում է բլոկ:
Պաշտոնական նկարագրությունից մենք նաև ակամա հասկանում ենք, որ gluster-ը գործում է որպես ֆայլերի պահեստավորում դասական ապարատային RAID-ի վերևում: Եղել են մշակման փորձեր՝ ֆայլերը բլոկների կտրելու (Sharding), բայց այս ամենը հավելում է, որը պարտադրում է կատարողականի կորուստներ արդեն գոյություն ունեցող ճարտարապետական մոտեցմանը, գումարած ազատ բաշխված բաղադրիչների օգտագործումը՝ կատարողականի սահմանափակումներով, ինչպիսին է Fuse-ը: Չկան մետատվյալների ծառայություններ, որոնք սահմանափակում են պահեստի կատարողականը և սխալների հանդուրժողականության հնարավորությունները՝ ֆայլերը բլոկների մեջ բաշխելիս: Ավելի լավ կատարողական ցուցանիշներ կարելի է դիտարկել «Բաշխված կրկնօրինակված» կոնֆիգուրացիայի միջոցով, և հանգույցների թիվը պետք է լինի առնվազն 6՝ բեռնվածքի օպտիմալ բաշխմամբ հուսալի կրկնօրինակ 3 կազմակերպելու համար:
Այս բացահայտումները կապված են նաև օգտագործողի փորձի նկարագրության հետ և երբ համեմատվում է , և կա նաև փորձի նկարագրություն, որը հանգեցնում է այս ավելի արդյունավետ և հուսալի կազմաձևի ըմբռնմանը
Նկարը ցույց է տալիս բեռնվածության բաշխումը երկու ֆայլ գրելիս, որտեղ առաջին ֆայլի պատճենները բաշխվում են առաջին երեք սերվերների վրա, որոնք միավորվում են ծավալ 0 խմբի մեջ, իսկ երկրորդ ֆայլի երեք օրինակը տեղադրվում է երկրորդ խմբի 1 հատորի վրա։ սերվերներ. Յուրաքանչյուր սերվեր ունի մեկ սկավառակ:
Ընդհանուր եզրակացությունն այն է, որ դուք կարող եք օգտագործել Gluster, բայց հասկանալով, որ կլինեն սահմանափակումներ կատարման և սխալների հանդուրժողականության մեջ, որոնք դժվարություններ են ստեղծում հիպերկոնվերգացված լուծման որոշակի պայմաններում, որտեղ ռեսուրսներ են անհրաժեշտ նաև վիրտուալ միջավայրերի հաշվողական բեռների համար:
Կան նաև Gluster-ի որոշ կատարողական ցուցանիշներ, որոնք կարելի է ձեռք բերել որոշակի պայմաններում՝ սահմանափակվելով միայն
Կեֆ
Հիմա եկեք նայենք Ceph-ին այն ճարտարապետության նկարագրություններից, որոնք ես կարողացա Կա նաև համեմատություն , որտեղ դուք կարող եք անմիջապես հասկանալ, որ նպատակահարմար է տեղադրել Ceph-ը առանձին սերվերների վրա, քանի որ նրա ծառայությունները պահանջում են բեռնվածության տակ գտնվող բոլոր ապարատային ռեսուրսները:
ճարտարապետություն ավելի բարդ, քան Gluster-ը, և կան ծառայություններ, ինչպիսիք են մետատվյալների ծառայությունները, բայց բաղադրիչների ամբողջ փաթեթը բավականին բարդ է և այնքան էլ ճկուն չէ այն վիրտուալացման լուծումներում օգտագործելու համար: Տվյալները պահվում են բլոկներում, որոնք ավելի արդյունավետ են թվում, բայց բոլոր ծառայությունների (բաղադրիչների) հիերարխիայում կան կորուստներ և ուշացումներ որոշակի բեռների և արտակարգ իրավիճակների պայմաններում, օրինակ՝ հետևյալը.
Ճարտարապետության նկարագրությունից սիրտը CRUSH է, որի շնորհիվ ընտրվում է տվյալների պահպանման վայրը։ Հաջորդը գալիս է PG - սա ամենադժվար աբստրակցիան (տրամաբանական խումբ) հասկանալն է: PG-ները անհրաժեշտ են CRUSH-ն ավելի արդյունավետ դարձնելու համար: PG-ի հիմնական նպատակն է խմբավորել օբյեկտները՝ նվազեցնելու ռեսուրսների սպառումը, բարձրացնելու կատարողականությունը և մասշտաբայնությունը: Օբյեկտներին ուղղակիորեն, առանձին-առանձին հասցեագրելը, առանց դրանք PG-ի մեջ միավորելու, շատ թանկ կարժենա: OSD-ն ծառայություն է յուրաքանչյուր առանձին սկավառակի համար:
Կլաստերը կարող է ունենալ մեկ կամ շատ տվյալների լողավազան տարբեր նպատակների համար և տարբեր կարգավորումներով: Լողավազանները բաժանված են տեղաբաշխման խմբերի. Տեղադրման խմբերը պահում են այն օբյեկտները, որոնց հասանելի են հաճախորդները: Այստեղ ավարտվում է տրամաբանական մակարդակը, և սկսվում է ֆիզիկական մակարդակը, քանի որ տեղաբաշխման յուրաքանչյուր խմբին հատկացվում է մեկ հիմնական սկավառակ և մի քանի կրկնօրինակ սկավառակներ (թե քանիսը կախված է լողավազանի կրկնօրինակման գործակիցից): Այլ կերպ ասած, տրամաբանական մակարդակում օբյեկտը պահվում է որոշակի տեղաբաշխման խմբում, իսկ ֆիզիկական մակարդակում՝ այն սկավառակների վրա, որոնք իրեն վերագրված են: Այս դեպքում սկավառակները կարող են ֆիզիկապես տեղակայվել տարբեր հանգույցներում կամ նույնիսկ տարբեր տվյալների կենտրոններում:
Այս սխեմայում տեղաբաշխման խմբերը կարծես անհրաժեշտ մակարդակ են ամբողջ լուծման ճկունության համար, բայց միևնույն ժամանակ որպես այս շղթայի լրացուցիչ օղակ, որն ակամա հուշում է արտադրողականության կորուստ: Օրինակ՝ տվյալներ գրելիս համակարգը պետք է բաժանի դրանք այս խմբերի, այնուհետև ֆիզիկական մակարդակում՝ հիմնական սկավառակի և կրկնօրինակների համար նախատեսված սկավառակների: Այսինքն՝ Hash ֆունկցիան աշխատում է օբյեկտ որոնելիս և տեղադրելիս, բայց կա մի կողմնակի էֆեկտ՝ դա շատ մեծ ծախսեր և սահմանափակումներ է հեշը վերակառուցելու համար (սկավառակ ավելացնելիս կամ հեռացնելիս): Հաշի մեկ այլ խնդիր տվյալների հստակ գամված տեղակայումն է, որը հնարավոր չէ փոխել: Այսինքն, եթե ինչ-որ կերպ սկավառակը գտնվում է ավելացված ծանրաբեռնվածության տակ, ապա համակարգը հնարավորություն չունի դրան չգրելու (այլ սկավառակ ընտրելով), հեշ ֆունկցիան պարտավորեցնում է, որ տվյալները տեղակայվեն ըստ կանոնի, որքան էլ վատ լինի: սկավառակն է, ուստի Ceph-ը շատ հիշողություն է ուտում, երբ վերակառուցում է PG-ն ինքնաբուժման կամ պահեստավորման ավելացման դեպքում: Եզրակացությունն այն է, որ Ceph-ը լավ է աշխատում (թեև դանդաղ), բայց միայն այն դեպքում, երբ չկա մասշտաբներ, արտակարգ իրավիճակներ կամ թարմացումներ:
Կան, իհարկե, տարբերակներ՝ քեշավորման և քեշի փոխանակման միջոցով արդյունավետության բարձրացման համար, բայց դա պահանջում է լավ սարքավորում, և դեռ կորուստներ կլինեն: Բայց ընդհանուր առմամբ, Ceph-ը արտադրողականության համար ավելի գայթակղիչ տեսք ունի, քան Gluster-ը: Նաև այս ապրանքներն օգտագործելիս անհրաժեշտ է հաշվի առնել մի կարևոր գործոն՝ սա իրավասության, փորձի և պրոֆեսիոնալիզմի բարձր մակարդակ է՝ մեծ շեշտադրումով Linux-ի վրա, քանի որ շատ կարևոր է ամեն ինչ ճիշտ տեղակայել, կարգավորել և աջակցել, որն էլ ավելի մեծ պատասխանատվություն ու բեռ է դնում ադմինիստրատորի վրա։
Vstorage
Ճարտարապետությունն էլ ավելի հետաքրքիր է թվում , որը կարող է օգտագործվել հիպերվիզորի հետ միասին նույն հանգույցների վրա, նույնի վրա , բայց շատ կարևոր է ամեն ինչ ճիշտ կարգավորել լավ կատարման հասնելու համար: Այսինքն, ցանկացած կոնֆիգուրացիայի վրա տուփից նման արտադրանքի տեղակայումը, առանց ճարտարապետությանը համապատասխան առաջարկությունները հաշվի առնելու, շատ հեշտ կլինի, բայց ոչ արդյունավետ:
Ի՞նչ կարող է գոյակցել kvm-qemu հիպերվիզորի ծառայությունների կողքին պահեստավորման համար, և սրանք ընդամենը մի քանի ծառայություններ են, որտեղ հայտնաբերվել է բաղադրիչների կոմպակտ օպտիմալ հիերարխիա. հաճախորդների սպասարկում՝ տեղադրված FUSE-ի միջոցով (փոփոխված, ոչ բաց կոդով), MDS մետատվյալների ծառայություն: (Մետատվյալների ծառայություն), ծառայության Chunk ծառայության տվյալների բլոկներ, որոնք ֆիզիկական մակարդակում հավասար են մեկ սկավառակի և վերջ։ Արագության առումով, իհարկե, օպտիմալ է օգտագործել անսարքության հանդուրժող սխեման երկու կրկնօրինակներով, բայց եթե դուք օգտագործում եք քեշավորում և գրանցամատյաններ SSD կրիչներում, ապա սխալների նկատմամբ հանդուրժող կոդավորումը (ջնջել կոդավորումը կամ raid6) կարող է պատշաճ կերպով գերկլոկացվել: հիբրիդային սխեման կամ նույնիսկ ավելի լավ բոլոր ֆլեշի վրա: EC-ի հետ կապված որոշակի թերություն կա (ջնջել կոդավորումը). տվյալների մեկ բլոկը փոխելիս անհրաժեշտ է վերահաշվարկել հավասարաչափ գումարները: Այս գործողության հետ կապված կորուստները շրջանցելու համար Ceph-ը հետաձգված գրում է EC-ին, և որոշակի հարցման ժամանակ կարող են առաջանալ աշխատանքի հետ կապված խնդիրներ, երբ, օրինակ, անհրաժեշտ է կարդալ բոլոր բլոկները, իսկ Virtuozzo Storage-ի դեպքում կատարվում է փոփոխված բլոկների գրում: օգտագործելով «log-structured file system» մոտեցումը, որը նվազագույնի է հասցնում հավասարության հաշվարկման ծախսերը: Մոտավորապես գնահատելու համար EC-ով և առանց աշխատանքի արագացման տարբերակները կան – թվերը կարող են մոտավոր լինել՝ կախված սարքավորումների արտադրողի ճշգրտության գործակիցից, սակայն հաշվարկների արդյունքը լավ օգնություն է կազմաձևումը պլանավորելու հարցում:
Պահպանման բաղադրիչների պարզ դիագրամը չի նշանակում, որ այդ բաղադրիչները չեն ներծծվում բայց եթե նախապես հաշվարկեք բոլոր ծախսերը, կարող եք հույս դնել հիպերվիզորի կողքին համագործակցության վրա:
Գոյություն ունի Ceph և Virtuozzo պահեստավորման ծառայությունների կողմից ապարատային ռեսուրսների սպառումը համեմատելու սխեմա:
Եթե նախկինում հնարավոր էր համեմատել Gluster-ն ու Ceph-ը՝ օգտագործելով հին հոդվածները՝ օգտագործելով դրանցից ամենակարևոր տողերը, ապա Virtuozzo-ի հետ դա ավելի դժվար է։ Այս ապրանքի վերաբերյալ շատ հոդվածներ չկան, և տեղեկատվություն կարելի է քաղել միայն փաստաթղթերից կամ ռուսերեն, եթե Vstorage-ը դիտարկենք որպես պահեստ, որն օգտագործվում է որոշ հիպերկոնվերգացված լուծումներում այնպիսի ընկերություններում, ինչպիսիք են և Ակրոնիսը։
Ես կփորձեմ օգնել այս ճարտարապետության նկարագրությանը, այնպես որ մի փոքր ավելի շատ տեքստ կլինի, բայց փաստաթղթերը ինքներդ հասկանալու համար շատ ժամանակ է պահանջվում, և առկա փաստաթղթերը կարող են օգտագործվել միայն որպես հղում՝ վերանայելով աղյուսակը: բովանդակության կամ որոնում ըստ բանալի բառի:
Եկեք դիտարկենք ձայնագրման գործընթացը հիբրիդային ապարատային կոնֆիգուրացիայի մեջ վերը նկարագրված բաղադրիչներով. ձայնագրությունը սկսում է գնալ դեպի այն հանգույցը, որտեղից այն սկսել է հաճախորդը (FUSE mount point ծառայություն), բայց մետատվյալների ծառայության (MDS) հիմնական բաղադրիչը, իհարկե, կգնա: հաճախորդին ուղղակիորեն ուղղեք դեպի ցանկալի հատվածի ծառայություն (պահպանման ծառայության CS բլոկներ), այսինքն՝ MDS-ը չի մասնակցում ձայնագրման գործընթացին, այլ պարզապես ծառայությունն ուղղորդում է պահանջվող հատվածին: Ընդհանրապես, կարելի է անալոգիա տալ տակառների մեջ ջուր լցնելով ձայնագրությանը։ Յուրաքանչյուր տակառը 256 ՄԲ տվյալների բլոկ է:
Այսինքն՝ մեկ սկավառակը նման տակառների որոշակի քանակ է, այսինքն՝ սկավառակի ծավալը՝ բաժանված 256 ՄԲ-ի։ Յուրաքանչյուր պատճենը բաժանվում է մի հանգույցի, երկրորդը գրեթե զուգահեռ մեկ այլ հանգույցի և այլն... Եթե մենք ունենք երեք կրկնօրինակ, և կան SSD սկավառակներ քեշի համար (տեղեկամատյանները կարդալու և գրելու համար), ապա գրելու հաստատումը տեղի կունենա գրելուց հետո: գրանցամատյանը դեպի SSD, և SSD-ից զուգահեռ վերականգնումը կշարունակվի HDD-ի վրա, կարծես հետին պլանում: Երեք կրկնօրինակների դեպքում գրառումը կկատարվի երրորդ հանգույցի SSD-ից հաստատելուց հետո: Կարող է թվալ, որ երեք SSD-ի գրելու արագության գումարը կարելի է բաժանել երեքի և մենք կստանանք մեկ կրկնօրինակի գրելու արագություն, բայց պատճենները գրվում են զուգահեռ, և ցանցի հետաձգման արագությունը սովորաբար ավելի մեծ է, քան SSD-ի արագությունը, և իրականում գրելու կատարումը կախված կլինի ցանցից: Այս առումով իրական IOPS տեսնելու համար անհրաժեշտ է ճիշտ բեռնել ամբողջ Vstorage-ը , այսինքն՝ իրական բեռի փորձարկում, և ոչ թե հիշողություն և քեշ, որտեղ անհրաժեշտ է հաշվի առնել տվյալների բլոկի ճիշտ չափը, թելերի քանակը և այլն։
SSD-ի վրա վերը նշված ձայնագրման գրանցամատյանը աշխատում է այնպես, որ հենց որ տվյալները մտնում են դրա մեջ, այն անմիջապես ընթերցվում է ծառայության կողմից և գրվում HDD-ի վրա։ Յուրաքանչյուր կլաստերի համար կան մի քանի մետատվյալների ծառայություններ (MDS), և դրանց թիվը որոշվում է քվորումով, որն աշխատում է Paxos ալգորիթմի համաձայն: Հաճախորդի տեսանկյունից FUSE մոնտաժային կետը կլաստերի պահեստավորման թղթապանակ է, որը միաժամանակ տեսանելի է կլաստերի բոլոր հանգույցներին, յուրաքանչյուր հանգույց ունի մոնտաժված հաճախորդ այս սկզբունքով, ուստի այս պահեստը հասանելի է յուրաքանչյուր հանգույցի համար:
Վերը նկարագրված մոտեցումներից որևէ մեկի կատարման համար պլանավորման և տեղակայման փուլում շատ կարևոր է ցանցի ճիշտ կազմաձևումը, որտեղ հավասարակշռություն կլինի ագրեգացիայի և ճիշտ ընտրված ցանցային կապուղու թողունակության շնորհիվ: Համախմբման մեջ կարևոր է ընտրել ճիշտ հեշինգի ռեժիմը և շրջանակի չափերը: Նաև շատ մեծ տարբերություն կա վերը նկարագրված SDS-ից, սա Virtuozzo Storage-ում արագ ուղու տեխնոլոգիայի ապահովիչ է: Ինչը, բացի արդիականացված ապահովիչից, ի տարբերություն բաց կոդով այլ լուծումների, զգալիորեն մեծացնում է IOPS-ը և թույլ է տալիս չսահմանափակվել հորիզոնական կամ ուղղահայաց մասշտաբով: Ընդհանուր առմամբ, համեմատած վերը նկարագրված ճարտարապետությունների հետ, այս մեկն ավելի հզոր է թվում, բայց նման հաճույքի համար, իհարկե, պետք է լիցենզիաներ գնել՝ ի տարբերություն Ceph-ի և Gluster-ի։
Ամփոփելու համար մենք կարող ենք առանձնացնել երեքի վերին մասը. Virtuozzo Storage-ը զբաղեցնում է առաջին տեղը՝ կատարողականության և ճարտարապետության հուսալիության առումով, Ceph-ը՝ երկրորդ, իսկ Gluster-ը՝ երրորդ:
Չափանիշները, որոնցով ընտրվել է Virtuozzo Storage-ը. այն ճարտարապետական բաղադրիչների օպտիմալ հավաքածու է, արդիականացված այս Fuse մոտեցման համար արագ ճանապարհով, ապարատային կոնֆիգուրացիաների ճկուն շարք, ռեսուրսների ավելի քիչ սպառում և հաշվարկների հետ կիսվելու կարողություն (հաշվարկներ/վիրտուալացում): այսինքն, այն լիովին հարմար է հիպերկոնվերգացված լուծման համար, որի մի մասն է նա: Երկրորդ տեղը Ceph-ն է, քանի որ այն Gluster-ի համեմատ ավելի արդյունավետ ճարտարապետություն է՝ շնորհիվ իր բլոկներում գործողության, ինչպես նաև ավելի ճկուն սցենարների և ավելի մեծ կլաստերներում աշխատելու հնարավորության:
Նախատեսվում է համեմատություն գրել vSAN-ի, Space Direct Storage-ի, Vstorage-ի և Nutanix Storage-ի միջև, փորձարկել Vstorage-ը HPE-ի և Huawei-ի սարքավորումների վրա, ինչպես նաև Vstorage-ը արտաքին ապարատային պահեստավորման համակարգերի հետ ինտեգրելու սցենարներ, այնպես որ, եթե հոդվածը ձեզ դուր եկավ, դա կլինի: հաճելի է ստանալ ձեր կարծիքը, որը կարող է մեծացնել նոր հոդվածների մոտիվացիան՝ հաշվի առնելով ձեր մեկնաբանությունները և ցանկությունները:
Source: www.habr.com