Պահպանում Kubernetes-ում. OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Թարմացրե՛ք. Մեկնաբանություններում ընթերցողներից մեկն առաջարկել է փորձել Լինսթոր (գուցե նա ինքն է աշխատում դրա վրա), այնպես որ ես ավելացրել եմ այս լուծման մասին բաժինը: Ես էլ եմ գրել տեղադրեք այն, թե ինչպես տեղադրել այն, քանի որ գործընթացը շատ է տարբերվում մնացածից։

Անկեղծ ասած՝ հանձնվեցի ու հանձնվեցի Կուբերնետես (գոնե առայժմ): Ես կօգտագործեմ Heroku. Ինչո՞ւ։ Պահպանման պատճառով: Ո՞վ կմտածեր, որ ես ավելի շատ կխփեմ պահեստավորման հետ, քան հենց Kubernetes-ի հետ: ես օգտագործում եմ Hetzner Cloudքանի որ դա էժան է, և կատարումը լավ է, և հենց սկզբից ես տեղակայում եմ կլաստերներ՝ օգտագործելով Ռանչեր. Ես չեմ փորձել Google/Amazon/Microsoft/DigitalOcean-ի կառավարվող Kubernetes ծառայությունները և այլն, և այլն, քանի որ ուզում էի ամեն ինչ սովորել ինքս: Ես էլ խնայող եմ։

Այսպիսով, այո, ես շատ ժամանակ ծախսեցի՝ փորձելով որոշել, թե որ պահեստն եմ ընտրել, երբ գնահատում էի Kubernetes-ի հնարավոր կույտը: Ես նախընտրում եմ բաց կոդով լուծումներ, ոչ միայն գնի պատճառով, այլ հետաքրքրությունից դրդված դիտարկել եմ վճարովի մի քանի տարբերակներ, քանի որ դրանք ունեն անվճար տարբերակներ՝ սահմանափակումներով: Ես նշել եմ որոշ թվեր վերջին թեստերից, երբ համեմատեցի տարբեր տարբերակներ, և դրանք կարող են հետաքրքրել նրանց, ովքեր սովորում են Kubernetes պահեստավորման մասին: Չնայած ես անձամբ առայժմ հրաժեշտ եմ տվել Կուբերնետեսին։ Ուզում եմ նաև նշել CSI վարորդ, որը կարող է ուղղակիորեն ապահովել Hetzner Cloud ծավալները, բայց ես դեռ չեմ փորձել: Ես նայեցի ամպային ծրագրաշարով սահմանված պահեստին, քանի որ ինձ անհրաժեշտ էր կրկնօրինակում և ցանկացած հանգույցի վրա կայուն ծավալներ արագ տեղադրելու հնարավորություն, հատկապես հանգույցների խափանումների և նմանատիպ այլ իրավիճակների դեպքում: Որոշ լուծումներ առաջարկում են ժամանակի ակնթարթներ և պահուստավորումներ կայքից դուրս, ինչը հարմար է:

Ես փորձարկել եմ 6-7 պահեստային լուծում.

OpenEBS

Ինչպես արդեն ասացի նախորդ գրառման մեջՓորձարկելով ցուցակի տարբերակների մեծ մասը, ես սկզբում հաստատվեցի OpenEBS-ի վրա: OpenEBS-ը շատ հեշտ է տեղադրել և օգտագործել, բայց ճիշտն ասած, բեռի տակ իրական տվյալների հետ փորձարկումից հետո ես հիասթափված էի դրա կատարումից: Սա բաց կոդ է, և մշակողները ինքնուրույն են Անփույթ ալիք միշտ շատ օգտակար է, երբ օգնության կարիք ունեմ: Ցավոք սրտի, այն ունի շատ վատ կատարողականություն՝ համեմատած այլ տարբերակների հետ, ուստի թեստերը պետք է վերագործարկվեին: OpenEBS-ը ներկայումս ունի 3 պահեստային շարժիչ, բայց ես տեղադրում եմ հենանիշային արդյունքներ cStor-ի համար: Ես դեռ թվեր չունեմ Jiva-ի և LocalPV-ի համար:

Մի խոսքով, Jiva-ն մի փոքր ավելի արագ է, իսկ LocalPV-ն ընդհանուր առմամբ արագ է, ոչ ավելի վատ, քան ուղղակիորեն սկավառակի չափանիշը: LocalPV-ի խնդիրն այն է, որ ծավալը հասանելի է միայն այն հանգույցում, որտեղ այն պատրաստվել է, և ընդհանրապես կրկնօրինակում չկա: Ես որոշ խնդիրներ ունեի կրկնօրինակը վերականգնելու միջոցով Առագաստանավ նոր կլաստերի վրա, քանի որ հանգույցների անունները տարբեր էին: Եթե ​​խոսենք կրկնօրինակումների մասին, ապա cStor-ն ունի plugin Velero-ի համար, որի միջոցով դուք կարող եք ժամանակի մի կետում կատարել ակնթարթային լուսանկարների պահուստավորումներ, ինչը ավելի հարմար է, քան ֆայլի մակարդակի կրկնօրինակումները Velero-Restic-ով: ես գրեցի մի քանի սցենար, այս փլագինով ավելի հեշտ դարձնելու պահուստավորումների և վերականգնումների կառավարումը: Ընդհանուր առմամբ, ինձ շատ է դուր գալիս OpenEBS-ը, բայց դրա կատարումը...

Քայլ

Rook-ը նաև բաց կոդով է, և այն, ինչ նրան առանձնացնում է ցանկի մնացած տարբերակներից, այն է, որ այն պահեստավորման նվագախմբ է, որը կատարում է պահեստավորման կառավարման բարդ առաջադրանքներ տարբեր հետին մասերով, օրինակ. Կեֆ, EdgeFS և այլն, ինչը մեծապես հեշտացնում է աշխատանքը: Ես խնդիրներ ունեի EfgeFS-ի հետ, երբ փորձեցի այն մի քանի ամիս առաջ, ուստի փորձեցի հիմնականում Ceph-ի հետ: Ceph-ը ոչ միայն առաջարկում է բլոկների պահեստավորում, այլ նաև օբյեկտների պահեստավորում, որը համատեղելի է S3/Swift-ի և բաշխված ֆայլային համակարգի հետ: Այն, ինչ ինձ դուր է գալիս Ceph-ում, ձայնային տվյալները մի քանի սկավառակների վրա տարածելու ունակությունն է, որպեսզի ծավալը կարողանա օգտագործել ավելի շատ սկավառակի տարածություն, քան կարող է տեղավորվել մեկ սկավառակի վրա: Հարմարավետ է։ Մեկ այլ հետաքրքիր առանձնահատկությունն այն է, որ երբ դուք սկավառակներ եք ավելացնում կլաստերին, այն ավտոմատ կերպով վերաբաշխում է տվյալները բոլոր սկավառակների վրա:

Ceph-ն ունի snapshots, բայց որքան ես գիտեմ, դրանք չեն կարող օգտագործվել անմիջապես Rook/Kubernetes-ում: Ճիշտ է, ես չեմ խորացել սրա մեջ: Բայց կայքից դուրս պահուստավորումներ չկան, այնպես որ դուք պետք է ինչ-որ բան օգտագործեք Velero/Restic-ի հետ, բայց կան միայն ֆայլի մակարդակի կրկնօրինակումներ, այլ ոչ թե ժամանակի ակնարկներ: Այն, ինչ ինձ շատ դուր եկավ Rook-ում, այն էր, թե որքան հեշտ է աշխատել Ceph-ի հետ. այն թաքցնում է գրեթե բոլոր բարդ իրերը և առաջարկում է գործիքներ՝ անմիջապես Ceph-ի հետ խոսելու համար՝ անսարքությունները վերացնելու համար: Ցավոք սրտի, Ceph հատորների սթրես թեստի ժամանակ ես շարունակում էի խնդիրներ ունենալ այս խնդիրը, որի պատճառով Ceph-ը դառնում է անկայուն: Դեռևս պարզ չէ՝ սա ինքնին Ceph-ի վրիպա՞կ է, թե՞ Ռուկը կառավարում է Ceph-ի հետ կապված խնդիր: Ես շտկեցի հիշողության կարգավորումները, և այն ավելի լավացավ, բայց խնդիրը ամբողջությամբ լուծված չէր: Ceph-ն ունի արժանապատիվ կատարում, ինչպես կարող եք տեսնել ստորև բերված հենանիշերում: Այն ունի նաև լավ վահանակ:

Rancher Longhorn

Ես շատ եմ սիրում Longhorn-ը: Իմ կարծիքով, սա խոստումնալից լուծում է։ Ճիշտ է, մշակողները իրենք (Rancher Labs) ընդունում են, որ այն դեռ հարմար չէ աշխատանքային միջավայրի համար, և դա ցույց է տալիս։ Այն բաց կոդով է և ունի արժանապատիվ կատարում (չնայած դեռ չեն օպտիմիզացրել), բայց ծավալները շատ երկար ժամանակ են պահանջում՝ միանալու համար, իսկ վատագույն դեպքերում՝ 15-16 րոպե, հատկապես մեծ պահեստային կամ մեծ կրկնօրինակը վերականգնելուց հետո։ ծանրաբեռնվածության բարձրացում: Այն ունի ակնթարթային պատկերներ և այս լուսանկարների պահուստավորումներ, բայց դրանք վերաբերում են միայն ծավալներին, այնպես որ ձեզ դեռևս պետք կլինի Velero-ի նման մի բան՝ այլ ռեսուրսներ կրկնօրինակելու համար: Կրկնօրինակումները և վերականգնումները շատ հուսալի են, բայց անպարկեշտորեն դանդաղ: Լուրջ, ուղղակի աներևակայելի դանդաղ: CPU-ի օգտագործումը և համակարգի ծանրաբեռնվածությունը հաճախ աճում են Longhorn-ում միջին քանակությամբ տվյալների հետ աշխատելիս: Լոնգհորնը կառավարելու համար հարմար վահանակ կա: Ես արդեն ասել եմ, որ ինձ դուր է գալիս Longhorn-ը, բայց այն որոշակի աշխատանքի կարիք ունի։

StorageOS

StorageOS-ը ցուցակի առաջին վճարովի արտադրանքն է: Այն ունի ծրագրավորող տարբերակ՝ 500 ԳԲ սահմանափակ կառավարվող պահեստի չափով, բայց չեմ կարծում, որ հանգույցների քանակի սահմանափակում կա։ Վաճառքի բաժնից ասացին, որ 125 ՏԲ-ի արժեքը սկսվում է ամսական 1 դոլարից, եթե ճիշտ եմ հիշում: Կա հիմնական վահանակ և հարմար CLI, բայց կատարման հետ կապված ինչ-որ տարօրինակ բան է տեղի ունենում. որոշ չափորոշիչներում դա բավականին պարկեշտ է, բայց ծավալի սթրես-թեստում ինձ ընդհանրապես դուր չեկավ արագությունը: Ընդհանրապես, ես չգիտեմ, թե ինչ ասել. Այսպիսով, ես իսկապես շատ բան չէի հասկանում: Այստեղ չկան պահեստային պատճեններ, և դուք նույնպես ստիպված կլինեք օգտագործել Velero-ն Restic-ի հետ՝ ծավալները կրկնօրինակելու համար: Տարօրինակ է, քանի որ ապրանքը վճարովի է: Եվ մշակողները չէին ցանկանում շփվել Slack-ով:

Շիկահավ

Ռոբինի մասին ես իմացա Reddit-ում նրանց տեխնիկական տնօրենից: Ես նախկինում երբեք չէի լսել նրա մասին։ Միգուցե այն պատճառով, որ ես անվճար լուծումներ էի փնտրում, բայց Ռոբինը վճարովի է։ Նրանք ունեն բավականին առատաձեռն անվճար տարբերակ՝ 10 ՏԲ պահեստով և երեք հանգույցով: Ընդհանուր առմամբ, արտադրանքը բավականին պարկեշտ է և ունի գեղեցիկ հատկություններ: Կա հիանալի CLI, բայց ամենաթեժն այն է, որ դուք կարող եք լուսանկարել և կրկնօրինակել ամբողջ հավելվածը (ռեսուրսների ընտրիչում դա կոչվում է Helm թողարկումներ կամ «flex apps»), ներառյալ ծավալները և այլ ռեսուրսները, այնպես որ կարող եք անել առանց Velero-ի: Եվ ամեն ինչ հիանալի կլիներ, եթե ոչ մի փոքր մանրուք. եթե վերականգնեք (կամ «ներմուծեք», ինչպես դա կոչվում է Ռոբինում) հավելվածը նոր կլաստերի վրա, օրինակ՝ աղետից վերականգնվելու դեպքում՝ վերականգնումը, իհարկե, աշխատում է, բայց շարունակեք կրկնօրինակել հավելվածը, դա արգելված է: Այս թողարկումում դա պարզապես հնարավոր չէ, քանի որ մշակողները հաստատել են: Սա, մեղմ ասած, տարօրինակ է, հատկապես հաշվի առնելով մյուս առավելությունները (օրինակ, աներևակայելի արագ կրկնօրինակում և վերականգնում): Մշակողները խոստանում են ամեն ինչ շտկել մինչև հաջորդ թողարկումը: Կատարումը, ընդհանուր առմամբ, լավ է, բայց ես նկատեցի տարօրինակություն. եթե հենանիշը գործարկեմ անմիջապես հոսթին կցված ձայնի վրա, ապա ընթերցման արագությունը շատ ավելի արագ է, քան նույն ձայնը ձայնասկավառակի ներսից: Մնացած բոլոր արդյունքները նույնական են, բայց տեսականորեն տարբերություն չպետք է լինի: Թեև նրանք աշխատում են դրա վրա, ես վրդովված էի վերականգնման և կրկնօրինակման հետ կապված խնդրից. ես մտածեցի, որ վերջապես գտել եմ համապատասխան լուծում, և ես նույնիսկ պատրաստ էի վճարել դրա համար, երբ ինձ ավելի շատ տարածք կամ ավելի շատ սերվեր է անհրաժեշտ:

Պորտվորքս

Այստեղ շատ բան չունեմ ասելու։ Սա վճարովի արտադրանք է, նույնքան զով և թանկ: Կատարումը պարզապես զարմանալի է. Սա մինչ այժմ լավագույն ցուցանիշն է։ Slack-ն ինձ ասաց, որ գինը սկսվում է ամսական $205-ից մեկ հանգույցի համար, ինչպես նշված է Google-ի GKE Marketplace-ում: Չգիտեմ, եթե ուղիղ գնեք, ավելի էժան կլինի: Ես դա, այնուամենայնիվ, չեմ կարող ինձ թույլ տալ, ուստի ես շատ, շատ հիասթափված էի, որ մշակողի լիցենզիան (մինչև 1 ՏԲ և 3 հանգույց) գործնականում անօգուտ է Kubernetes-ի հետ, քանի դեռ չեք բավարարվում ստատիկ տրամադրմամբ: Ես հույս ունեի, որ ծավալի լիցենզիան ավտոմատ կերպով կնվազեցվի ծրագրավորողի՝ փորձաշրջանի ավարտին, բայց դա տեղի չունեցավ: Մշակողի լիցենզիան կարող է օգտագործվել միայն Docker-ի հետ ուղղակիորեն, իսկ Kubernetes-ում կազմաձևումը շատ ծանր է և սահմանափակ: Իհարկե, ես նախընտրում եմ բաց կոդերը, բայց եթե փող ունենայի, անպայման կընտրեի Portworx-ը։ Մինչ այժմ դրա կատարումը պարզապես չի համեմատվում այլ տարբերակների հետ:

Լինսթոր

Այս բաժինը ավելացրել եմ գրառման հրապարակումից հետո, երբ մի ընթերցող առաջարկեց փորձել Linstor-ը։ Ես փորձեցի այն և հավանեցի։ Բայց պետք է ավելի խորանամ։ Առայժմ կարող եմ ասել, որ արդյունավետությունը բավականին լավ է (ես ստորև ավելացրել եմ չափանիշի արդյունքները)։ Իրականում, ես ստացա նույն արդյունավետությունը, ինչ ուղիղ սկավառակի չափանիշի դեպքում՝ առանց որևէ լրացուցիչ ծախսերի։ (Մի հարցրեք, թե ինչու են Portworx-ի թվերն ավելի լավ, քան ուղիղ սկավառակի չափանիշը։ Ես պատկերացում չունեմ։ Կախարդանք է, կարծում եմ)։ Այսպիսով, Linstor-ը մինչ այժմ շատ արդյունավետ է թվում։ Դրա կարգավորումը այդքան էլ դժվար չէ, բայց այն այնքան էլ հեշտ չէ, որքան մյուս տարբերակները։ Նախ, ես պետք է տեղադրեի Linstor-ը (միջուկի մոդուլը և գործիքները/ծառայությունները) և կարգավորեի LVM-ը Kubernetes-ից դուրս՝ անմիջապես հոսթի վրա, բարակ մատակարարման և snapshot աջակցության համար, ապա ստեղծեի Kubernetes-ից պահեստն օգտագործելու համար անհրաժեշտ ռեսուրսները։ Ես դժգոհ էի, որ այն չաշխատեց։ CentOS և ստիպված էր օգտագործել UbuntuԻհարկե, դա մեծ բան չէ, բայց մի փոքր նյարդայնացնող է, քանի որ փաստաթղթերում (որը, ի դեպ, գերազանց է) նշվում են մի քանի փաթեթներ, որոնք հասանելի չեն նշված Epel պահոցներում: Linstor-ը ունի snapshots, բայց ոչ կայքից դուրս պահուստավորումներ, ուստի ես ստիպված էի կրկին օգտագործել Velero-ն Restic-ի հետ ծավալային պահուստավորման համար: Ես կնախընտրեի snapshots-ը ֆայլային մակարդակի պահուստավորումների փոխարեն, բայց դա տանելի է, եթե լուծումը արդյունավետ և հուսալի է: Linstor-ը բաց կոդով է, բայց կա վճարովի աջակցություն: Եթե ճիշտ եմ հասկանում, կարող եք օգտագործել այն առանց սահմանափակումների, նույնիսկ եթե աջակցության պայմանագիր չունեք, բայց ես պետք է ստուգեմ դա: Ես չգիտեմ, թե որքանով է Linstor-ը փորձարկված Kubernetes-ի համար, բայց պահեստավորման շերտն ինքնին Kubernetes-ից դուրս է, և թվում է, թե այն որոշ ժամանակ գոյություն ունի, ուստի այն, հավանաբար, արդեն փորձարկվել է իրական աշխարհի պայմաններում: Կա՞ արդյոք այստեղ լուծում, որը կստիպի ինձ փոխել իմ միտքը և վերադառնալ Kubernetes-ին: Ես չգիտեմ: Ես պետք է մի փոքր ավելի խորանամ և սովորեմ կրկնօրինակման մասին։ Կտեսնենք։ Բայց առաջին տպավորությունը լավն է։ Ես անպայման կնախընտրեի օգտագործել իմ սեփական Kubernetes կլաստերները Heroku-ի փոխարեն՝ ավելի շատ ազատություն և նոր բաներ սովորելու համար։ Քանի որ Linstor-ը այնքան էլ հեշտ չէ տեղադրել, որքան մյուսները, շուտով կգրեմ այդ մասին գրառում։

Հենանիշներ

Ցավոք, համեմատության վերաբերյալ շատ գրառումներ չեմ արել, քանի որ չէի մտածում, որ այդ մասին կգրեմ: Ես ունեմ արդյունքներ միայն հիմնական fio-ի հենանիշներից և միայն մեկ հանգույցի կլաստերների համար, այնպես որ ես դեռևս չունեմ թվեր կրկնվող կոնֆիգուրացիաների համար: Բայց այս արդյունքներից դուք կարող եք մոտավոր պատկերացում կազմել, թե ինչ կարելի է ակնկալել յուրաքանչյուր տարբերակից, քանի որ ես դրանք համեմատեցի նույն ամպային սերվերների, 4 միջուկի, 16 ԳԲ RAM-ի, փորձարկված ծավալների համար լրացուցիչ 100 ԳԲ սկավառակի հետ: Ես երեք անգամ գործարկեցի հենանիշերը յուրաքանչյուր լուծման համար և հաշվարկեցի միջին արդյունքը, գումարած, ես վերակայեցի սերվերի կարգավորումները յուրաքանչյուր ապրանքի համար: Այս ամենը լիովին հակագիտական ​​է, պարզապես ընդհանուր պատկերացում տալու համար: Մյուս թեստերում ես ձայնագրել եմ 38 ԳԲ լուսանկարներ և տեսանյութեր ծավալից և ստուգել եմ կարդալ-գրելը, բայց, ավաղ, թվերը չեմ պահպանել։ Մի խոսքով, Portworkx-ը շատ ավելի արագ էր:

Ծավալի չափանիշի համար ես օգտագործել եմ այս մանիֆեստը.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

Ես սկզբում ստեղծեցի հատոր՝ համապատասխան պահեստավորման դասի հետ, իսկ հետո գործը վարեցի fio-ի հետ կուլիսներում: Ես վերցրեցի 1 ԳԲ, որպեսզի գնահատեմ կատարումը և շատ չսպասեմ: Ահա արդյունքները.

Ես ընդգծել եմ յուրաքանչյուր չափման լավագույն արժեքը կանաչով, իսկ վատագույնը՝ կարմիրով:

Ամփոփում

Ինչպես տեսնում եք, շատ դեպքերում Portworx-ը ավելի լավ է հանդես եկել, քան մյուսները: Բայց ինձ համար դա թանկ է։ Ես չգիտեմ, թե որքան արժե Robin-ը, բայց նրանք ունեն հիանալի անվճար տարբերակ, այնպես որ, եթե ցանկանում եք վճարովի արտադրանք, կարող եք փորձել այն (հուսով եմ, որ նրանք շուտով կլուծեն խնդիրը վերականգնելու և կրկնօրինակումների հետ կապված): Երեք անվճարներից ես ամենաքիչը խնդիրներ ունեի OpenEBS-ի հետ, բայց դրա կատարումը անդունդ է: Ափսոս, որ ավելի շատ արդյունքներ չպահեցի, բայց հուսով եմ, որ թվերն ու իմ մեկնաբանությունները կօգնեն ձեզ։

Source: www.habr.com