Արդյո՞ք տվյալների բազաները ապրում են Kubernetes-ում:

Ինչ-որ կերպ, պատմականորեն, ՏՏ ոլորտը ինչ-ինչ պատճառով բաժանված է երկու պայմանական ճամբարի. նրանք, ովքեր «կողմ» են և նրանք, ովքեր «դեմ են»: Ընդ որում, վեճերի առարկան կարող է լինել միանգամայն կամայական։ Ո՞ր ՕՀ-ն է ավելի լավ՝ Win, թե Linux: Android կամ iOS սմարթֆոնի վրա: Պե՞տք է ամեն ինչ պահել ամպերի մեջ, թե՞ տեղադրել սառը RAID պահեստի վրա և պտուտակները դնել պահարանի մեջ: PHP մարդիկ իրավունք ունե՞ն ծրագրավորող կոչվելու: Այս վեճերը, երբեմն, ունեն բացառապես էկզիստենցիալ բնույթ և չունեն որևէ այլ հիմք, քան մարզական հետաքրքրությունը:

Պարզապես պատահեց, որ բեռնարկղերի և այս ամբողջ սիրելի խոհանոցի հայտնվելով docker-ով և պայմանական k8-ներով, սկսվեցին բանավեճերը «կողմ» և «դեմ» հետին պլանի տարբեր ոլորտներում նոր հնարավորությունների օգտագործման համար: (Եկեք նախապես վերապահում անենք, որ չնայած Kubernetes-ը ամենից հաճախ կնշվի որպես նվագախումբ այս քննարկման ժամանակ, այս կոնկրետ գործիքի ընտրությունը հիմնարար նշանակություն չունի: Փոխարենը, դուք կարող եք փոխարինել ցանկացած այլով, որը ձեզ առավել հարմար և ծանոթ է թվում: .)

Եվ, թվում է, սա պարզ վեճ կլիներ նույն մետաղադրամի երկու կողմերի միջև։ Նույնքան անիմաստ և անողոք, ինչպես Win-ի ընդդեմ Linux-ի հավերժական դիմակայությունը, որտեղ ադեկվատ մարդիկ կան ինչ-որ տեղ մեջտեղում: Բայց կոնտեյներացման դեպքում ամեն ինչ այդքան էլ պարզ չէ։ Սովորաբար նման վեճերում ճիշտ կողմ չկա, բայց տվյալների բազաները պահելու համար «օգտագործել» կամ «չօգտագործել» կոնտեյներների դեպքում ամեն ինչ տակնուվրա է լինում։ Որովհետև ինչ-որ առումով ճիշտ են այս մոտեցման և՛ կողմնակիցները, և՛ հակառակորդները։

Լուսավոր կողմ

The Light Side-ի փաստարկը կարելի է համառոտ նկարագրել մեկ արտահայտությամբ. «Բարև, 2k19-ը պատուհանից դուրս է»: Դա, իհարկե, պոպուլիզմ է թվում, բայց եթե մանրամասն խորամուխ ես լինում իրավիճակի մեջ, դա իր առավելություններն ունի։ Եկեք հիմա դասավորենք դրանք:

Ենթադրենք, դուք ունեք մեծ վեբ նախագիծ: Այն կարող էր ի սկզբանե կառուցվել միկրոսերվիսային մոտեցման հիման վրա, կամ ինչ-որ պահի այն հասել է էվոլյուցիոն ճանապարհով. իրականում դա այնքան էլ կարևոր չէ: Դուք ցրեցիք մեր նախագիծը առանձին միկրոծառայությունների մեջ, ստեղծեցիք նվագախումբը, բեռի հավասարակշռումը և մասշտաբը: Եվ հիմա, հանգիստ խղճով, հաբրա էֆեկտների ժամանակ մոխիտո եք խմում ցանցաճոճում՝ ընկած սերվերները բարձրացնելու փոխարեն: Բայց բոլոր գործողություններում դուք պետք է հետևողական լինեք։ Շատ հաճախ միայն հավելվածն ինքնին` կոդը, կոնտեյներացված է: Կոդից բացի ուրիշ ի՞նչ ունենք։

Ճիշտ է, տվյալներ: Ցանկացած նախագծի սիրտը նրա տվյալներն են. սա կարող է լինել կա՛մ տիպիկ DBMS՝ MySQL, Postgre, MongoDB, կա՛մ որոնման համար օգտագործվող պահեստ (ElasticSearch), բանալի-արժեքի պահեստավորում՝ քեշավորման համար, օրինակ՝ redis և այլն: Ներկայումս մենք չենք մենք կխոսենք հետին պլանի կատարման ծուռ տարբերակների մասին, երբ տվյալների բազան խափանում է վատ գրված հարցումների պատճառով, և փոխարենը կխոսենք հենց այս տվյալների բազայի սխալների հանդուրժողականության ապահովման մասին՝ հաճախորդի ծանրաբեռնվածության ներքո: Ի վերջո, երբ մենք կոնտեյներային ենք դարձնում մեր հավելվածը և թույլ ենք տալիս այն ազատորեն մասշտաբավորել ցանկացած թվով մուտքային հարցումներ մշակելու համար, դա բնականաբար մեծացնում է տվյալների բազայի բեռը:

Փաստորեն, տվյալների շտեմարան մուտք գործելու ալիքը և այն սերվերը, որի վրա այն աշխատում է, դառնում են ասեղի աչքը մեր գեղեցիկ կոնտեյներային հետնամասում: Միևնույն ժամանակ, կոնտեյներների վիրտուալացման հիմնական շարժառիթը կառուցվածքի շարժունակությունն ու ճկունությունն է, ինչը մեզ թույլ է տալիս հնարավորինս արդյունավետ կազմակերպել պիկ բեռների բաշխումը մեզ հասանելի ողջ ենթակառուցվածքով: Այսինքն, եթե մենք չտարածենք և չտարածենք համակարգի բոլոր առկա տարրերը կլաստերի վրա, մենք շատ լուրջ սխալ ենք թույլ տալիս:

Շատ ավելի տրամաբանական է կլաստերավորել ոչ միայն բուն հավելվածը, այլև տվյալների պահպանման համար պատասխանատու ծառայությունները։ Կլաստերավորելով և տեղակայելով վեբ սերվերները, որոնք աշխատում են ինքնուրույն և բաշխում են բեռը k8s-ում, մենք արդեն լուծում ենք տվյալների համաժամացման խնդիրը՝ նույն գրառումների մեկնաբանությունները, եթե որպես օրինակ վերցնենք որևէ լրատվամիջոց կամ բլոգ հարթակ: Ամեն դեպքում, մենք ունենք տվյալների բազայի ներկլաստերային, նույնիսկ վիրտուալ ներկայացում որպես ExternalService։ Հարցն այն է, որ տվյալների բազան ինքնին դեռ կլաստերացված չէ. խորանարդում տեղակայված վեբ սերվերները փոփոխությունների մասին տեղեկատվություն են վերցնում մեր ստատիկ մարտական ​​տվյալների բազայից, որը պտտվում է առանձին:

Զգո՞ւմ եք բռնում: Մենք օգտագործում ենք k8s կամ Swarm բեռը բաշխելու և հիմնական վեբ սերվերի խափանումից խուսափելու համար, բայց մենք դա չենք անում տվյալների բազայի համար: Բայց եթե տվյալների բազան խափանում է, ապա մեր ամբողջ կլաստերային ենթակառուցվածքն անիմաստ է.

Այդ իսկ պատճառով անհրաժեշտ է կլաստերավորել ոչ միայն վեբ սերվերները, ինչպես սովորաբար արվում է, այլ նաև տվյալների բազայի ենթակառուցվածքը։ Միայն այս կերպ մենք կարող ենք ապահովել կառույց, որը լիովին կաշխատի մեկ թիմում, բայց միևնույն ժամանակ միմյանցից անկախ։ Ավելին, նույնիսկ եթե մեր հետնամասի կեսը «փլուզվի» ծանրաբեռնվածության տակ, մնացածը կպահպանվի, և կլաստերի ներսում տվյալների բազաները միմյանց հետ համաժամեցնելու համակարգը և նոր կլաստերներ անվերջ մասշտաբավորելու և տեղակայելու հնարավորությունը կօգնեն արագ հասնել պահանջվող հզորությանը. եթե միայն տվյալների կենտրոնում դարակաշարեր լինեին:

Բացի այդ, կլաստերներում բաշխված տվյալների բազայի մոդելը թույլ է տալիս հենց այս տվյալների բազան տանել այնտեղ, որտեղ այն անհրաժեշտ է. Եթե ​​մենք խոսում ենք գլոբալ ծառայության մասին, ապա միանգամայն անտրամաբանական է վեբ կլաստերը պտտել Սան Ֆրանցիսկոյի տարածքում ինչ-որ տեղ և միևնույն ժամանակ փաթեթներ ուղարկել մոսկովյան տարածաշրջանի տվյալների բազա մուտք գործելիս և հակառակ ուղղությամբ:

Նաև տվյալների բազայի կոնտեյներացումը թույլ է տալիս կառուցել համակարգի բոլոր տարրերը վերացականության նույն մակարդակում: Ինչն իր հերթին հնարավորություն է տալիս կառավարել հենց այս համակարգը անմիջապես կոդից՝ մշակողների կողմից՝ առանց ադմինիստրատորների ակտիվ ներգրավման։ Մշակողները կարծում էին, որ նոր ենթանախագծի համար անհրաժեշտ է առանձին DBMS՝ հեշտ: գրել է yaml ֆայլ, այն վերբեռնել է կլաստերի մեջ, և դուք ավարտել եք:

Եվ, իհարկե, ներքին գործառնությունը շատ պարզեցված է: Ասա ինձ, քանի՞ անգամ եք փակել ձեր աչքերը, երբ թիմի նոր անդամը ձեռքերը դրել է մարտական ​​տվյալների բազան աշխատանքի համար: Ո՞րն է, փաստորեն, միակն է, որ ունեք և հիմա պտտվում է: Իհարկե, մենք բոլորս այստեղ չափահաս ենք, և ինչ-որ տեղ ունենք թարմ պահուստ, և նույնիսկ ավելի հեռու՝ տատիկի վարունգներով և հին դահուկներով դարակի հետևում, ևս մեկ պահեստային պահեստ, գուցե նույնիսկ սառնարանում, քանի որ ձեր գրասենյակը մի անգամ արդեն վառվել էր: Բայց միևնույն է, մարտական ​​ենթակառուցվածքին և, իհարկե, մարտական ​​տվյալների բազան հասանելիությամբ թիմի նոր անդամի յուրաքանչյուր մուտքը վալիդոլի մի դույլ է շրջապատի բոլորի համար: Դե, ո՞վ է ճանաչում նրան, նորեկ, գուցե նա խաչաձև է: Սարսափելի է, կհամաձայնեք։

Կոնտեյներացումը և, փաստորեն, ձեր նախագծի տվյալների բազայի բաշխված ֆիզիկական տոպոլոգիան օգնում է խուսափել նման վավերացման պահերից: Չե՞ք վստահում նորեկին: ԼԱՎ! Եկեք նրան տանք իր սեփական կլաստերը՝ աշխատելու և տվյալների բազան անջատելու մյուս կլաստերներից՝ համաժամացում միայն ձեռքով սեղմելով և երկու ստեղների համաժամանակյա պտտմամբ (մեկը թիմի առաջատարի համար, մյուսը՝ ադմինիստրատորի համար): Եվ բոլորը երջանիկ են:

Եվ հիմա ժամանակն է վերածվել տվյալների բազայի կլաստերավորման հակառակորդների:

Մութ կողմ

Վիճաբանելով, թե ինչու չարժե տվյալների բազան պարունակել և շարունակել այն գործարկել մեկ կենտրոնական սերվերի վրա, մենք չենք ընկրկի ուղղափառությունների հռետորաբանությանը և այնպիսի հայտարարություններին, ինչպիսին է «պապերը տվյալների բազաները սարքավորում էին սարքավորում, և մենք նույնպես»: Փոխարենը, եկեք փորձենք ստեղծել մի իրավիճակ, երբ կոնտեյներացումը իրականում շոշափելի շահաբաժիններ կվճարի:

Համաձայն եմ, այն նախագծերը, որոնք իսկապես կոնտեյներով հիմքի կարիք ունեն, կարող են մի ձեռքի մատների վրա հաշվել ոչ լավագույն ֆրեզերային մեքենայի օպերատորը: Մեծ մասամբ, նույնիսկ k8-ների կամ Docker Swarm-ի օգտագործումն ինքնին ավելորդ է. շատ հաճախ այդ գործիքներին դիմում են տեխնոլոգիաների ընդհանուր աղմուկի և «ամենակարողի» վերաբերմունքի պատճառով՝ ի դեմս սեռերի՝ ամեն ինչ մղելու համար: ամպեր և տարաներ. Դե, քանի որ հիմա դա նորաձև է, և բոլորը դա անում են:

Դեպքերի առնվազն կեսում նախագծում Kubernetis-ի կամ պարզապես Docker-ի օգտագործումը ավելորդ է: Խնդիրն այն է, որ հաճախորդի ենթակառուցվածքը պահպանելու համար վարձված ոչ բոլոր թիմերը կամ աութսորսինգ ընկերությունները տեղյակ են այս մասին: Ավելի վատ է, երբ բեռնարկղերը դրվում են, քանի որ հաճախորդին դա արժենում է որոշակի քանակությամբ մետաղադրամ:

Ընդհանրապես, կարծիք կա, որ դոկեր/խորանարդային մաֆիան հիմարաբար ջախջախում է այն հաճախորդներին, ովքեր ենթակառուցվածքային հարցերը արտասորսինգ են անում: Ի վերջո, կլաստերների հետ աշխատելու համար մեզ պետք են ինժեներներ, որոնք ընդունակ են դրան և ընդհանուր առմամբ հասկանում են իրականացվող լուծման ճարտարապետությունը։ Մենք մի անգամ արդեն նկարագրել ենք մեր գործը «Republic» հրապարակման հետ. այնտեղ մենք վերապատրաստել ենք հաճախորդի թիմին աշխատել Կուբերնետիսի իրողություններում, և բոլորը գոհ մնացին: Եվ դա պարկեշտ էր: Հաճախ k8s «իրականացնողները» պատանդ են վերցնում հաճախորդի ենթակառուցվածքը, քանի որ հիմա միայն նրանք են հասկանում, թե ինչպես է ամեն ինչ աշխատում այնտեղ, հաճախորդի կողմից մասնագետներ չկան:

Հիմա պատկերացրեք, որ այս կերպ մենք արտասուրս ենք անում ոչ միայն վեբ սերվերի մասը, այլև տվյալների բազայի սպասարկումը։ Մենք ասացինք, որ ԲԴ-ն սիրտն է, իսկ սրտի կորուստը մահացու է ցանկացած կենդանի օրգանիզմի համար։ Մի խոսքով, հեռանկարները լավագույնը չեն։ Այսպիսով, Hype Kubernetis-ի փոխարեն, շատ նախագծեր պարզապես չպետք է անհանգստանան AWS-ի նորմալ սակագնով, որը կլուծի իրենց կայքի/նախագծի ծանրաբեռնվածության հետ կապված բոլոր խնդիրները: Բայց AWS-ն այլևս մոդայիկ չէ, և ցուցադրական ցուցադրություններն ավելին արժեն, քան փողը, ցավոք սրտի, նաև ՏՏ միջավայրում:

ԼԱՎ. Միգուցե նախագիծն իրոք կլաստերի կարիք ունի, բայց եթե քաղաքացիություն չունեցող հավելվածների դեպքում ամեն ինչ պարզ է, ապա ինչպե՞ս կարող ենք պատշաճ ցանցային կապ կազմակերպել կլաստերային տվյալների բազայի համար:

Եթե ​​մենք խոսում ենք անխափան ինժեներական լուծման մասին, որը հենց դա է k8s-ին անցումը, ապա մեր գլխավոր գլխացավանքը տվյալների կրկնօրինակումն է կլաստերային տվյալների բազայում: Որոշ DBMS-ներ սկզբում բավականին հավատարիմ են տվյալների բաշխմանը իրենց առանձին օրինակների միջև: Շատ ուրիշներ այնքան էլ ողջունելի չեն: Եվ շատ հաճախ մեր նախագծի համար DBMS ընտրելու հիմնական փաստարկը ռեսուրսների և ինժեներական նվազագույն ծախսերով կրկնօրինակելու ունակությունը չէ: Հատկապես, եթե նախագիծը ի սկզբանե նախատեսված չէր որպես միկրոսերվիս, այլ պարզապես զարգացավ այս ուղղությամբ:

Կարծում ենք՝ կարիք չկա խոսել ցանցային կրիչների արագության մասին՝ դրանք դանդաղ են։ Նրանք. Մենք դեռ իրական հնարավորություն չունենք, եթե ինչ-որ բան պատահի, վերագործարկելու DBMS օրինակն ինչ-որ տեղ, որտեղ ավելի շատ կա, օրինակ՝ պրոցեսորի հզորությունը կամ ազատ RAM-ը: Մենք շատ արագ կբախվենք վիրտուալացված սկավառակի ենթահամակարգի աշխատանքին: Համապատասխանաբար, DBMS-ը պետք է գամված լինի մոտակայքում տեղակայված մեքենաների իր անձնական հավաքածուին: Կամ անհրաժեշտ է ինչ-որ կերպ առանձին սառեցնել տվյալների բավական արագ համաժամացումը ենթադրյալ պահուստների համար:

Շարունակելով վիրտուալ ֆայլային համակարգերի թեման. Docker Volumes-ը, ցավոք, անխնդիր չէ: Ընդհանուր առմամբ, այնպիսի հարցում, ինչպիսին է տվյալների երկարաժամկետ հուսալի պահպանումը, ես կցանկանայի բավարարվել տեխնիկապես ամենապարզ սխեմաներով: Եվ կոնտեյների FS-ից նոր վերացական շերտ ավելացնելը մայր հյուրընկալողի FS-ին ինքնին ռիսկ է: Բայց երբ կոնտեյներացման աջակցության համակարգի գործարկումը նույնպես դժվարություններ է ունենում այս շերտերի միջև տվյալների փոխանցման հետ կապված, ապա դա իսկապես աղետ է: Այս պահին առաջադեմ մարդկությանը հայտնի խնդիրների մեծ մասը կարծես արմատախիլ է արված։ Բայց հասկանում եք, որքան բարդ է մեխանիզմը, այնքան ավելի հեշտ է կոտրվում:

Այս բոլոր «արկածների» լույսի ներքո շատ ավելի շահավետ և հեշտ է տվյալների բազան մեկ տեղում պահելը, և եթե նույնիսկ ձեզ անհրաժեշտ է հավելվածը կոնտեյներավորել, թույլ տվեք, որ այն ինքնուրույն աշխատի և բաշխման դարպասի միջոցով միաժամանակյա հաղորդակցություն ստանա ծրագրի հետ: տվյալների բազա, որը կկարդացվի և գրվի միայն մեկ անգամ և մեկ տեղում: Այս մոտեցումը նվազագույնի է հասցնում սխալների և ապասինխրոնիզացիայի հավանականությունը:

Ինչի՞ ենք մենք տանում. Ավելին, տվյալների բազայի կոնտեյներացումը տեղին է այնտեղ, որտեղ դրա իրական անհրաժեշտությունը կա: Դուք չեք կարող լրացնել ամբողջական հավելվածի տվյալների բազան և պտտել այն այնպես, կարծես երկու տասնյակ միկրոծառայություններ ունեք, դա այդպես չի աշխատում: Եվ սա պետք է հստակ հասկանալ.

Արտադրանքի փոխարեն

Եթե ​​դուք սպասում եք հստակ եզրակացության «վիրտուալացնել տվյալների բազան, թե ոչ», ապա մենք ձեզ հիասթափեցնենք. այն այստեղ չի լինի: Որովհետեւ ցանկացած ենթակառուցվածքային լուծում ստեղծելիս պետք է առաջնորդվել ոչ թե նորաձեւությամբ ու առաջընթացով, այլ առաջին հերթին ողջախոհությամբ։

Կան նախագծեր, որոնց սկզբունքներն ու գործիքները, որոնք գալիս են Kubernetis-ի հետ, հիանալի տեղավորվում են, և նման նախագծերում խաղաղություն է տիրում առնվազն հետնախորշի տարածքում։ Եվ կան նախագծեր, որոնք ոչ թե կոնտեյներացման կարիք ունեն, այլ նորմալ սերվերային ենթակառուցվածքի, քանի որ դրանք սկզբունքորեն չեն կարող վերամշակվել միկրոսերվիսների կլաստերի մոդելի, քանի որ դրանք կընկնեն։

Source: www.habr.com