Հե՜յ Հաբր։
Հիշեցնում ենք, որ մենք հրապարակել ենք ևս մեկ չափազանց հետաքրքիր և օգտակար հոդված Կուբեռնետեսի նախշերի մասին։ Ամեն ինչ սկսվեց ««Բրենդան Բըրնսը, և, ի դեպ, մենք աշխատանք ունենք այս հատվածում Այսօր մենք ձեզ հրավիրում ենք կարդալ MinIO բլոգի հոդվածը, որը համառոտ ներկայացնում է Kubernetes-ում տվյալների պահպանման ձևերի միտումները և առանձնահատկությունները։
Kubernetes-ը հիմնովին փոխել է ավանդական ծրագրերի մշակման և տեղակայման ձևերը։ Թիմերը այժմ կարող են մշակել, փորձարկել և տեղակայել ծրագիր մի քանի օրվա ընթացքում՝ բազմաթիվ միջավայրերում, Kubernetes կլաստերների շրջանակներում։ Այս տեսակի աշխատանքը նախորդ սերունդների տեխնոլոգիայի հետ սովորաբար տևում էր շաբաթներ, եթե ոչ ամիսներ։
Այս արագացումը հնարավոր է Kubernetes-ի կողմից ապահովված աբստրակցիայի շնորհիվ, այսինքն՝ քանի որ Kubernetes-ն ինքն է մշակում ֆիզիկական կամ վիրտուալ մեքենաների ցածր մակարդակի մանրամասները՝ թույլ տալով օգտատերերին հայտարարել ցանկալի պրոցեսորը, հիշողության ցանկալի քանակը և կոնտեյներների օրինակների քանակը, ինչպես նաև այլ պարամետրեր: Kubernetes-ին աջակցող հսկայական համայնքի և դրա անընդհատ ընդլայնվող ընդունման շնորհիվ այն, անկասկած, ամենատարածված կոնտեյներների օրկեստրացման հարթակն է:
Քանի որ Kubernetes-ի ընդունումը մեծանում է, աճում է նաև դրա պահեստավորման ձևերի վերաբերյալ շփոթմունքը։.
Քանի որ բոլորը մրցում են Kubernetes-ի կարկանդակի (այսինքն՝ տվյալների պահպանման) մի կտորի համար, երբ խոսքը վերաբերում է տվյալների պահպանմանը, ազդանշանը խեղդվում է շատ աղմուկի պատճառով։
Kubernetes-ը մարմնավորում է հավելվածների մշակման, տեղակայման և կառավարման ժամանակակից մոդել: Այս ժամանակակից մոդելը առանձնացնում է պահեստային տեխնոլոգիաները հաշվարկայինից: Kubernetes-ի համատեքստում այս առանձնացումը լիովին հասկանալու համար պետք է նաև հասկանալ վիճակային և վիճակազուրկ հավելվածները, և թե ինչպես է պահեստային տեխնոլոգիաները տեղավորվում այս ամենում: Ահա թե որտեղ է S3-ի REST API մոտեցումը հստակ առավելություններ ունի այլ լուծումների POSIX/CSI մոտեցման նկատմամբ:
Այս հոդվածում մենք կխոսենք Kubernetes-ում պահեստավորման ձևերի մասին, մասնավորապես անդրադառնալով վիճակազուրկ/վիճակային հավելվածների բանավեճին՝ իսկապես հասկանալու համար երկուսի միջև եղած տարբերությունները և դրանց կարևորությունը: Հոդվածի մնացած մասը կանդրադառնա հավելվածներին և դրանց պահեստավորման ձևերին՝ կոնտեյներների և Kubernetes-ի լավագույն փորձի լույսի ներքո:
Անպետք կոնտեյներներ
Կոնտեյներները բնույթով թեթև և ժամանակավոր են։ Դրանք կարող են հեշտությամբ կանգնեցվել, ջնջվել կամ տեղակայվել մեկ այլ հանգույցում վայրկյանների ընթացքում։ Մեծ կոնտեյներային կազմակերպման համակարգում այս գործողությունները տեղի են ունենում անընդհատ, և օգտատերերը նույնիսկ չեն նկատում փոփոխությունները։ Այնուամենայնիվ, տեղափոխությունները հնարավոր են միայն այն դեպքում, եթե կոնտեյները կախվածություն չունի այն հանգույցից, որի վրա գտնվում է։ Նման կոնտեյներները կոչվում են աշխատող։ քաղաքացիություն չունեցող.
Stateful կոնտեյներներ
Եթե կոնտեյները տվյալները պահում է տեղական միացված սարքերի վրա (կամ բլոկային սարքի վրա), ապա խափանման դեպքում այն տվյալների պահոցը, որտեղ այն գտնվում է, պետք է տեղափոխվի նոր հանգույց՝ կոնտեյների հետ միասին։ Սա կարևոր է, քանի որ հակառակ դեպքում կոնտեյներում աշխատող ծրագիրը չի կարողանա պատշաճ կերպով գործել, քանի որ այն պետք է մուտք ունենա տեղական պահեստում պահված տվյալներին։ Նման կոնտեյներները կոչվում են աշխատող։ պետական.
Զուտ տեխնիկական տեսանկյունից, վիճակային կոնտեյներները կարող են տեղափոխվել նաև այլ հանգույցներ: Սա սովորաբար իրականացվում է բաշխված ֆայլային համակարգերի կամ ցանցին կցված բլոկային պահեստավորման միջոցով, որը կցված է բոլոր հանգույցներին, որտեղ կոնտեյներներն աշխատում են: Այս կերպ, կոնտեյներները հասանելիություն ունեն մշտական պահեստավորման ծավալներին, և տեղեկատվությունը պահվում է ցանցում տեղակայված սկավառակների վրա: Ես այս մեթոդը կանվանեմ «վիճակային կոնտեյներային մոտեցում«, և հոդվածի մնացած մասում ես դրան կանվանեմ այդպես՝ հետևողականության համար։»
Ստանդարտ կոնտեյներային մոտեցման դեպքում բոլոր հավելվածների պոդերը կցվում են մեկ բաշխված ֆայլային համակարգի՝ ստեղծելով մի տեսակ համատեղ պահեստ, որտեղ պահվում են բոլոր հավելվածների տվյալները: Չնայած կան որոշ տարբերակներ, սա բարձր մակարդակի մոտեցում է:
Հիմա եկեք նայենք, թե ինչու է վիճակային կոնտեյներների մոտեցումը հակաօրինաչափ ամպային աշխարհում։
Ամպային հավելվածների դիզայն
Ավանդաբար, ծրագրերը օգտագործում էին տվյալների բազաներ՝ տեղեկատվությունը կառուցվածքային եղանակով պահելու համար, և տեղական սկավառակներ կամ բաշխված ֆայլային համակարգեր՝ բոլոր չկառուցվածքային կամ նույնիսկ կիսակառուցվածքային տվյալները դրանց մեջ տեղափոխելու համար։ Քանի որ չկառուցվածքային տվյալների ծավալը մեծանում էր, մշակողները հասկացան, որ POSIX-ը չափազանց շատախոս էր, ուներ զգալի ծախսեր և, ի վերջո, խոչընդոտում էր ծրագրին, երբ այն իսկապես մեծանում էր։
Հենց սա է հիմնականում նպաստել նոր տվյալների պահպանման ստանդարտի՝ ամպային կողմնորոշված պահեստների ի հայտ գալուն, որոնք հիմնականում աշխատում են REST API-ի հիման վրա և ազատում են հավելվածը տեղական տվյալների պահեստի ծանրաբեռնված սպասարկումից։ Այս դեպքում հավելվածն իրականում անցնում է վիճակազուրկ ռեժիմի (քանի որ վիճակը գտնվում է հեռակա պահեստում)։ Ժամանակակից հավելվածները կառուցվում են զրոյից՝ արդեն հաշվի առնելով այս գործոնը։ Որպես կանոն, ցանկացած ժամանակակից հավելված, որը մշակում է այս կամ այն տեսակի տվյալներ (գրանցամատյաններ, մետատվյալներ, բլոբներ և այլն), կառուցվում է ամպային կողմնորոշված մոդելի վրա, որտեղ վիճակը փոխանցվում է դրա պահպանման համար հատուկ հատկացված ծրագրային համակարգին։
Վիճակային կոնտեյներների մոտեցումը ստիպում է այս ամբողջ մոդելին վերադառնալ հենց այնտեղ, որտեղից այն սկսվել էր։
POSIX ինտերֆեյսները տվյալներ պահելու համար օգտագործելով՝ հավելվածները գործում են այնպես, կարծես վիճակային լինեն, և այդպիսով հրաժարվում են ամպային դիզայնի ամենակարևոր սկզբունքներից, ինչպիսիք են՝ հավելվածի աշխատանքային թելերի չափը փոփոխելու՝ կախված մուտքային բեռից, ընթացիկ հանգույցի խափանման դեպքում նոր հանգույց տեղափոխվելու հնարավորությունը և այլն։
Այս իրավիճակն ավելի մանրամասն դիտարկելով՝ մենք տեսնում ենք, որ տվյալների պահեստ ընտրելիս կրկին բախվում ենք POSIX vs. REST API դիլեմայի հետ, ԲԱՅՑ Kubernetes միջավայրերի բաշխված բնույթի պատճառով POSIX խնդիրների լրացուցիչ սրմամբ։ Մասնավորապես,
- POSIX-ը շատախոս էPOSIX սեմանտիկան պահանջում է, որ մետատվյալները և ֆայլերի նկարագրիչները կապված լինեն յուրաքանչյուր գործողության հետ՝ գործողության վիճակը պահպանելու համար։ Սա ներմուծում է զգալի ծանրաբեռնվածություն, որը իրական արժեք չունի։ Օբյեկտների պահեստավորման API-ները, մասնավորապես S3 API-ը, ազատվել են այս պահանջներից՝ թույլ տալով ծրագրին կատարել, ապա «մոռանալ» կանչի մասին։ Պահեստավորման համակարգի պատասխանը ցույց է տալիս, թե արդյոք գործողությունը հաջողվել է, թե ձախողվել։ Եթե այն ձախողվում է, ծրագիրը կարող է կրկին փորձել։
- Ցանցի սահմանափակումներԲաշխված համակարգում ենթադրվում է, որ կարող են լինել մի քանի ծրագրեր, որոնք փորձում են տվյալներ գրել նույն կցված պահեստավորման կրիչում: Այսպիսով, ոչ միայն ծրագրերը կմրցեն միմյանց հետ թողունակության համար (տվյալներ պահեստավորման կրիչ ուղարկելու համար), այլև պահեստավորման համակարգն ինքը կմրցակցի այս թողունակության համար՝ տվյալներ ուղարկելով ֆիզիկական սկավառակների միջև: POSIX-ի խոսակցականության պատճառով ցանցային զանգերի քանակը մի քանի անգամ ավելանում է: Մյուս կողմից, S3 API-ն հստակ տարբերակում է ապահովում հաճախորդից սերվեր եկող ցանցային զանգերի և սերվերի ներսում տեղի ունեցողների միջև:
- БезопасностьPOSIX անվտանգության մոդելը հիմնված է ակտիվ մարդկային մասնակցության վրա. ադմինիստրատորները կարգավորում են յուրաքանչյուր օգտատիրոջ կամ խմբի համար մուտքի հատուկ մակարդակներ: Այս մոդելը դժվար է հարմարեցնել ամպակենտրոն աշխարհին: Ժամանակակից ծրագրերը կախված են API-ի վրա հիմնված անվտանգության մոդելներից, որտեղ մուտքի իրավունքները սահմանվում են որպես քաղաքականությունների, ծառայողական հաշիվների, ժամանակավոր հավատարմագրերի և այլնի ամբողջություն:
- ԿառավարելիությունՎիճակային կոնտեյներները գալիս են կառավարման լրացուցիչ ծախսերով: Տվյալների միաժամանակյա մուտքի համաժամեցումը, տվյալների համապատասխանության ապահովումը, այս ամենը պահանջում է ուշադիր քննարկում, թե որ տվյալների մուտքի ձևանմուշներն օգտագործել: Կա լրացուցիչ ծրագրակազմ տեղադրելու, կառավարելու և կարգավորելու կարիք, չհաշված լրացուցիչ մշակման ջանքերը:
Կոնտեյներային տվյալների պահպանման ինտերֆեյս
Թեև կոնտեյներային պահեստավորման ինտերֆեյսը (CSI) մեծ աշխատանք է կատարել Kubernetes-ի ծավալային շերտի տարածմանը նպաստելու գործում, մասամբ այն երրորդ կողմի պահեստավորման մատակարարներին հանձնելով, այն նաև ակամա նպաստել է այն համոզմունքին, որ վիճակային կոնտեյներային մոտեցումը Kubernetes-ում տվյալները պահելու առաջարկվող մեթոդն է։
CSI-ը մշակվել է որպես ստանդարտ՝ Kubernetes-ի վրա աշխատող հնացած հավելվածներին կամայական բլոկային և ֆայլերի պահեստավորման համակարգեր տրամադրելու համար: Եվ ինչպես ցույց է տվել այս հոդվածը, միակ իրավիճակը, երբ վիճակային կոնտեյներային մոտեցումը (և CSI-ն իր ներկայիս տեսքով) իմաստ ունի, այն է, երբ հավելվածն ինքնին հնացած համակարգ է, որը չի կարող ավելացնել օբյեկտների պահեստավորման API-ների աջակցություն:
Կարևոր է հասկանալ, որ CSI-ն իր ներկայիս տեսքով օգտագործելով, այսինքն՝ ժամանակակից ծրագրերի հետ աշխատելիս ծավալների մոնտաժման ժամանակ, մենք կհանդիպենք մոտավորապես նույն խնդիրներին, որոնք առաջացել են այն համակարգերում, որտեղ տվյալների պահպանումը կազմակերպված է POSIX ոճով։
Ավելի որակական մոտեցում
Այս դեպքում կարևոր է հասկանալ, որ ծրագրերի մեծ մասը նախատեսված չէ աշխատելու վիճակայնությամբ կամ առանց դրա։ Այս վարքագիծը կախված է համակարգի ընդհանուր ճարտարապետությունից և նախագծման ընթացքում ընտրված կոնկրետ տարբերակներից։ Եկեք մի փոքր խոսենք վիճակայնությամբ ծրագրերի մասին։
Սկզբունքորեն, բոլոր կիրառական տվյալները կարելի է բաժանել մի քանի լայն տեսակների.
- Գրանցամատյանի տվյալներ
- Ժամանակային նշման տվյալներ
- Գործարքի տվյալներ
- Մետատվյալներ
- Կոնտեյների պատկերներ
- Blob տվյալներ (երկուական մեծ օբյեկտներ)
Այս բոլոր տվյալների տեսակները շատ լավ են աջակցվում ժամանակակից պահեստավորման հարթակների կողմից, և կան մի քանի ամպային-բնիկ հարթակներ, որոնք ուղղված են տվյալների մատակարարմանը այս յուրաքանչյուր կոնկրետ ձևաչափով: Օրինակ, գործարքների տվյալները և մետատվյալները կարող են գտնվել ժամանակակից ամպային-բնիկ տվյալների բազայում, ինչպիսիք են CockroachDB-ն, YugaByte-ը և այլն: Կոնտեյներների պատկերները կամ blob տվյալները կարող են պահվել MinIO-ի վրա հիմնված docker ռեգիստրում: Ժամանակային նշման տվյալները կարող են պահվել ժամանակային շարքերի տվյալների բազայում, ինչպիսիք են InfluxDB-ն և այլն: Մենք այստեղ չենք խորանա յուրաքանչյուր տվյալների տեսակի և համապատասխան ծրագրերի մանրամասների մեջ, բայց ընդհանուր գաղափարն այն է, որ խուսափենք տեղական սկավառակի միացումների վրա հիմնված մշտական պահեստավորումից:
Բացի այդ, հաճախ արդյունավետ է ապահովել ժամանակավոր քեշավորման շերտ, որը ծառայում է որպես հավելվածների ժամանակավոր ֆայլերի պահեստ, սակայն հավելվածները չպետք է կախված լինեն այս շերտից որպես իրենց ճշմարտության աղբյուր։
Պահեստավորում վիճակային հավելվածների համար
Թեև օգտակար է հավելվածները պահել առանց վիճակի, տվյալներ պահող հավելվածները՝ ինչպիսիք են տվյալների բազաները, օբյեկտների պահեստները, բանալի-արժեքի պահեստները, պետք է լինեն վիճակի։ Եկեք նայենք, թե ինչու են այս հավելվածները տեղակայվում Kubernetes-ում։ Մենք կօգտագործենք MinIO-ն որպես օրինակ, բայց նույն սկզբունքները վերաբերում են ցանկացած խոշոր ամպային պահեստավորման համակարգի։
Ամպային հավելվածները նախագծված են կոնտեյներներին բնորոշ ճկունությունից լիարժեք օգտվելու համար, ինչը նշանակում է, որ դրանք որևէ ենթադրություն չեն անում այն միջավայրի վերաբերյալ, որտեղ դրանք կտեղակայվեն: Օրինակ, MinIO-ն օգտագործում է ներքին ջնջման կոդավորում՝ ապահովելու համար, որ համակարգը բավականաչափ դիմացկուն լինի գոյատևելու համար, նույնիսկ եթե սկավառակների կեսը խափանվի: MinIO-ն նաև կառավարում է տվյալների ամբողջականությունն ու անվտանգությունը՝ օգտագործելով իր սեփական սերվերային կողմի հեշավորումը և կոդավորումը:
Նման ամպային կիրառությունների համար տեղական մշտական հատորները (PV) ամենահարմարն են որպես պահուստային պահեստ: Տեղական PV-ն հնարավորություն է տալիս պահպանել հում տվյալներ, մինչդեռ այդ PV-ների վրա աշխատող կիրառությունները անկախ հավաքում են տեղեկատվություն, որը թույլ է տալիս նրանց մասշտաբավորել տվյալները և կառավարել տվյալների աճող պահանջները:
Այս մոտեցումը շատ ավելի պարզ է և շատ ավելի լավ է մասշտաբավորվում, քան CSI-ի վրա հիմնված PV-ները, որոնք համակարգում բերում են տվյալների կառավարման և ավելորդության իրենց սեփական շերտերը։ Խնդիրն այն է, որ այս շերտերը սովորաբար հակասում են վիճակայնության համար նախատեսված հավելվածներին։
Վստահ քայլ դեպի տվյալների հաշվարկներից անջատումը
Այս հոդվածում մենք խոսել ենք այն մասին, թե ինչպես են հավելվածները շարժվում դեպի պետականության բացակայություն, կամ, այլ կերպ ասած, տվյալների պահպանումը հաշվարկներից առանձնացնելուն։ Եզրափակելով՝ մենք կանդրադառնանք այս միտման իրական աշխարհի մի քանի օրինակների։
, որը հայտնի տվյալների վերլուծության հարթակ է, ավանդաբար եղել է վիճակային և տեղակայված է HDFS-ում: Այնուամենայնիվ, քանի որ Spark-ը տեղափոխվում է ամպային աշխարհ, այն ավելի ու ավելի է օգտագործվում առանց վիճակության՝ օգտագործելով `s3a`: Spark-ը օգտագործում է s3a-ն՝ վիճակը այլ համակարգերին փոխանցելու համար, մինչդեռ Spark կոնտեյներներն իրենք ամբողջությամբ առանց վիճակության են: Մեծ տվյալների վերլուծության այլ խոշոր ձեռնարկությունների խաղացողներ, մասնավորապես՝ , , նաև շարժվում են տվյալների պահպանման և դրա միջոցով հաշվարկների տարանջատման ուղղությամբ։
Նմանատիպ օրինաչափություններ կարելի է տեսնել այլ խոշոր վերլուծական հարթակներում, այդ թվում՝ Presto-ում, Tensorflow to R-ում, Jupyter-ում: Վիճակի բեռնաթափումը հեռակա ամպային պահեստավորման համակարգերին տեղափոխելով՝ ձեր հավելվածի կառավարումը և մասշտաբավորումը շատ ավելի հեշտ է դառնում: Այն նաև օգնում է հավելվածին լինել փոխադրելի տարբեր միջավայրերում:
Source: www.habr.com
