Անցյալ տարեվերջին տեղի ունեցավ ռուսական PostgreSQL համայնքի հերթական ուղիղ հեռարձակումը , որի ընթացքում դրա համահիմնադիր Նիկոլայ Սամոխվալովը խոսել է Flant-ի տեխնիկական տնօրեն Դմիտրի Ստոլյարովի հետ այս DBMS-ի մասին Kubernetes-ի համատեքստում։
Հրապարակում ենք այս քննարկման հիմնական մասի սղագրությունը, և ժ Ամբողջական տեսանյութը տեղադրված է.
Տվյալների բազաներ և Kubernetes
НСԱյսօր մենք չենք խոսի ՎԱԿՈՒՈՒՄԻ և ԱՆԵԿՏԵՂԵՐԻ մասին: Մենք ուզում ենք խոսել Kubernetes-ի մասին։ Գիտեմ, որ երկար տարիների փորձ ունես։ Ես դիտեցի ձեր տեսանյութերը և նույնիսկ նորից դիտեցի դրանցից մի քանիսը... Եկեք անմիջապես անցնենք կետին. ինչու՞ ընդհանրապես Postgres կամ MySQL K8-ներում:
ԴՍԱյս հարցին միանշանակ պատասխան չկա և չի կարող լինել։ Բայց ընդհանուր առմամբ սա պարզություն է ու հարմարավետություն... ներուժ։ Բոլորը ցանկանում են կառավարվող ծառայություններ:
НС: Ինչպես , միայն տանը?
ԴՍԱյո. RDS-ի նման, ամենուր:
НС«Ամենուր» լավ կետ է: Խոշոր ընկերություններում ամեն ինչ գտնվում է տարբեր վայրերում։ Ինչո՞ւ այդ դեպքում, եթե դա խոշոր ընկերություն է, չընդունել պատրաստի լուծում։ Օրինակ՝ Nutanix-ն ունի իր մշակումները, մյուս ընկերությունները (VMware...) ունեն նույն «RDS, միայն տանը»։
ԴՍԲայց մենք խոսում ենք առանձին իրականացման մասին, որը կաշխատի միայն որոշակի պայմաններում։ Եվ եթե մենք խոսում ենք Kubernetes-ի մասին, ապա գոյություն ունի ենթակառուցվածքների հսկայական բազմազանություն (որը կարող է լինել K8-ներում): Ըստ էության, սա ստանդարտ է API-ների համար ամպի համար...
НС: Դա նաև անվճար է:
ԴՍ- Դա այնքան էլ կարևոր չէ։ Ազատությունը կարևոր է շուկայի ոչ շատ մեծ հատվածի համար։ Կարևոր է մեկ այլ բան... Հավանաբար հիշում եք զեկույցը «»:
НС:Այո։
ԴՍԵս հասկացա, որ այն շատ երկիմաստ է ընդունվել։ Ոմանք կարծում էին, որ ես ասում եմ. «Տղե՛րք, եկեք բոլոր տվյալների շտեմարանները մտցնենք Kubernetes», իսկ ոմանք որոշեցին, որ դրանք բոլորը սարսափելի հեծանիվներ են: Բայց ես լրիվ այլ բան էի ուզում ասել. «Տեսեք, թե ինչ է կատարվում, ինչ խնդիրներ կան և ինչպես կարելի է դրանք լուծել։ Հիմա պե՞տք է օգտագործենք Kubernetes տվյալների բազաները: Արտադրություն? Դե, միայն եթե ձեզ դուր է գալիս... որոշակի բաներ անել: Բայց մշակողի համար կարող եմ ասել, որ խորհուրդ եմ տալիս: Մշակողի համար միջավայրեր ստեղծելու/ջնջելու դինամիզմը շատ կարևոր է»:
Ն.Ս.: Dev ասելով, դուք նկատի ունեք բոլոր այն միջավայրերը, որոնք արտադրված չեն: Բեմականացում, ՈԱ…
ԴՍԵթե մենք խոսում ենք պերֆի ստենդների մասին, ապա հավանաբար ոչ, քանի որ այնտեղ պահանջները հատուկ են: Եթե մենք խոսում ենք հատուկ դեպքերի մասին, երբ բեմադրման համար անհրաժեշտ է շատ մեծ տվյալների բազա, ապա, հավանաբար, ոչ... Եթե սա ստատիկ, երկարակյաց միջավայր է, ապա ո՞րն է K8s-ում տեղակայված տվյալների բազայի օգուտը:
НС: Ոչ ոք. Բայց որտե՞ղ ենք մենք տեսնում ստատիկ միջավայրեր: Վաղը ստատիկ միջավայրը հնանալու է:
ԴՍԲեմադրությունը կարող է լինել ստատիկ: Մենք ունենք հաճախորդներ...
НС- Այո, ես էլ ունեմ: Մեծ խնդիր է, եթե ունես 10 ՏԲ տվյալների բազա և 200 ԳԲ բեմադրություն...
ԴՍ: Ես շատ լավ դեպք ունեմ: Բեմադրության վրա կա ապրանքների տվյալների բազա, որտեղ փոփոխություններ են կատարվում: Եվ կա կոճակ. «Գլորվել դեպի արտադրություն»: Այս փոփոխությունները՝ դելտաները, ավելացվում են (կարծես թե դրանք պարզապես համաժամացվում են API-ի միջոցով) արտադրության մեջ։ Սա շատ էկզոտիկ տարբերակ է։
НСԵս տեսել եմ ստարտափներ հովտում, որոնք նստած են RDS-ում կամ նույնիսկ Հերոկուում, սրանք 2-3 տարի առաջվա պատմություններ են, և նրանք ներբեռնում են աղբավայրը իրենց նոութբուքում: Քանի որ տվյալների բազան դեռ ընդամենը 80 ԳԲ է, իսկ նոութբուքի վրա տեղ կա: Հետո բոլորի համար հավելյալ սկավառակներ են գնում, որ 3 շտեմարան ունենան տարբեր մշակումներ իրականացնելու համար։ Այսպես էլ է լինում. Ես նաև տեսա, որ նրանք չեն վախենում բեմադրության մեջ պատճենել պրոդը, դա շատ է կախված ընկերությունից: Բայց ես նաև տեսա, որ նրանք շատ են վախենում, և որ հաճախ ժամանակ ու ձեռքեր չեն ունենում։ Բայց մինչ այս թեմային անցնելը, ես ուզում եմ լսել Kubernetes-ի մասին: Ես ճի՞շտ եմ հասկանում, որ դեռ ոչ ոք պրոդում չի անում։
ԴՍՄենք ունենք փոքր տվյալների բազաներ արտադրության մեջ: Խոսքը տասնյակ գիգաբայթների ծավալների և ոչ կարևոր ծառայությունների մասին է, որոնց համար մենք շատ ծույլ էինք կրկնօրինակներ պատրաստելու համար (և նման անհրաժեշտություն չկա): Եվ պայմանով, որ Kubernetes-ի տակ նորմալ պահեստ կա։ Այս տվյալների բազան աշխատել է վիրտուալ մեքենայի մեջ՝ պայմանականորեն VMware-ում, պահեստավորման համակարգի վերևում: Մենք տեղադրեցինք այն և այժմ մենք կարող ենք այն փոխանցել մեքենայից մեքենա:
НСԱյս չափի տվյալների բազաները՝ մինչև 100 ԳԲ, կարող են մի քանի րոպեում տեղադրվել լավ սկավառակների և լավ ցանցի վրա, այնպես չէ՞: Վայրկյանում 1 ԳԲ արագությունն այլևս էկզոտիկ չէ։
ԴՍԱյո, գծային գործողության համար դա խնդիր չէ:
НСԼավ, մենք պարզապես պետք է մտածենք արդյունահանման մասին: Եվ եթե մենք դիտարկում ենք Kubernetes-ը ոչ արտադրական միջավայրերի համար, ի՞նչ պետք է անենք: Ես դա տեսնում եմ Զալանդոյում , Crunchy-ում , կան մի քանի այլ տարբերակներ։ Եվ կա - Սա մեր լավ ընկեր Ալվարոն է Իսպանիայից. այն, ինչ նրանք անում են, ըստ էության, պարզապես պարզապես չեն և ամբողջ բաշխումը (), որի մեջ, բացի հենց Postgres-ից, նրանք նաև որոշեցին լցոնել պահեստային՝ Էնվեյ վստահված անձի...
ԴՍԲանագնաց ինչի՞ համար: Հատկապես հավասարակշռո՞ւմ եք Postgres-ի տրաֆիկը:
НС:Այո։ Այսինքն, նրանք դա տեսնում են այսպես. եթե վերցնում եք Linux բաշխում և միջուկ, ապա սովորական PostgreSQL-ը միջուկն է, և նրանք ցանկանում են այնպիսի բաշխում պատրաստել, որը կլինի ամպային և կաշխատի Kubernetes-ով: Նրանք հավաքում են բաղադրիչներ (կրկնօրինակներ և այլն) և կարգաբերում են դրանք, որպեսզի լավ աշխատեն։
ԴՍ: Շատ լավ! Ըստ էության, սա ձեր սեփական կառավարվող Postgres-ը ստեղծելու ծրագիր է:
НСLinux-ի բաշխումները հավերժական խնդիրներ ունեն. ինչպես ստեղծել դրայվերներ, որպեսզի բոլոր սարքավորումներն ապահովվեն: Եվ նրանք գաղափար ունեն, որ աշխատելու են Կուբերնետեսում։ Ես գիտեմ, որ Zalando օպերատորում մենք վերջերս տեսանք կապ AWS-ի հետ, և սա այլևս այնքան էլ լավ չէ: Չպետք է կապ լինի կոնկրետ ենթակառուցվածքի հետ. ո՞րն է այդ դեպքում իմաստը:
ԴՍԵս չգիտեմ, թե կոնկրետ ինչ իրավիճակի մեջ է հայտնվել Զալանդոն, բայց Kubernetes-ում պահեստավորումն այժմ այնպես է արված, որ անհնար է սկավառակի կրկնօրինակում կատարել ընդհանուր մեթոդով: Վերջերս ստանդարտ - վերջին տարբերակում — Մենք հնարավոր դարձրինք նկարահանումներ, բայց որտե՞ղ է այն իրականացվում։ Անկեղծ ասած, ամեն ինչ դեռ այնքան հում է... Մենք փորձում ենք CSI-ն AWS-ի, GCE-ի, Azure-ի, vSphere-ի վերևում, բայց հենց որ սկսեք օգտագործել, տեսնում եք, որ այն դեռ պատրաստ չէ։
НСԱհա թե ինչու մենք երբեմն ստիպված ենք լինում ապավինել ենթակառուցվածքներին: Կարծում եմ՝ սա դեռ վաղ փուլ է՝ աճող ցավեր։ Հարց. Ի՞նչ խորհուրդ կտաք նորեկներին, ովքեր ցանկանում են փորձել PgSQL K8-ում: Ինչ օպերատոր գուցե:
ԴՍԽնդիրն այն է, որ Postgres-ը մեզ համար 3% է: Մենք նաև ունենք տարբեր ծրագրերի շատ մեծ ցուցակ Kubernetes-ում, ես նույնիսկ չեմ թվարկի ամեն ինչ: Օրինակ, Elasticsearch. Օպերատորները շատ են՝ ոմանք ակտիվորեն զարգանում են, մյուսները՝ ոչ։ Մենք մեզ համար պահանջներ ենք կազմել, թե ինչ պետք է լինի օպերատորի մեջ, որ մենք դրան լուրջ վերաբերվենք։ Հատուկ Kubernetes-ի համար օպերատորում, ոչ թե «Amazon-ի պայմաններում ինչ-որ բան անելու օպերատորում»... Փաստորեն, մենք բավականին լայնորեն (= գրեթե բոլոր հաճախորդները) օգտագործում ենք մեկ օպերատոր. (նրա մասին հոդված կհրապարակենք շուտով).
НСԵվ ոչ MySQL-ի համար: Ես գիտեմ, որ Percona-ն... քանի որ նրանք այժմ աշխատում են MySQL-ի, MongoDB-ի և Postgres-ի վրա, նրանք պետք է ստեղծեն ինչ-որ ունիվերսալ լուծում՝ բոլոր տվյալների բազաների համար, բոլոր ամպային մատակարարների համար:
ԴՍՄենք ժամանակ չունեինք MySQL-ի օպերատորներին նայելու: Այս պահին մեր հիմնական ուշադրությունը սա չէ: MySQL-ը լավ է աշխատում ինքնուրույն: Ինչու՞ օգտագործել օպերատորը, եթե դուք կարող եք պարզապես գործարկել տվյալների բազա... Դուք կարող եք գործարկել Docker կոնտեյներ Postrges-ով, կամ կարող եք գործարկել այն պարզ ձևով:
НСՍրա մասին էլ հարց կար. Օպերատոր ընդհանրապես չկա՞
ԴՍԱյո, մեզանից 100%-ը PostgreSQL-ն աշխատում է առանց օպերատորի: Առայժմ այդպես: Մենք ակտիվորեն օգտագործում ենք օպերատորը Պրոմեթևսի և Ռեդիսի համար: Մենք պլաններ ունենք գտնելու օպերատոր Elasticsearch-ի համար. դա այն մեկն է, որն ամենաշատն է «այրվում», քանի որ մենք ցանկանում ենք այն տեղադրել Kubernetes-ում 100% դեպքերում: Ճիշտ այնպես, ինչպես մենք ցանկանում ենք ապահովել, որ MongoDB-ն նույնպես միշտ տեղադրված է Kubernetes-ում: Այստեղ որոշակի ցանկություններ են հայտնվում՝ զգացողություն կա, որ այս դեպքերում ինչ-որ բան կարելի է անել։ Եվ մենք նույնիսկ չնայեցինք Պոստգրեսին: Իհարկե, մենք գիտենք, որ կան տարբեր տարբերակներ, բայց իրականում մենք ունենք ինքնուրույն:
DB Kubernetes-ում փորձարկման համար
НСԱնցնենք թեստավորման թեմային։ Ինչպես կատարել փոփոխություններ տվյալների բազայում՝ DevOps-ի տեսանկյունից: Կան միկրոսերվիսներ, բազմաթիվ տվյալների բազաներ, ինչ-որ տեղ անընդհատ ինչ-որ բան փոխվում է։ Ինչպես ապահովել նորմալ CI/CD, որպեսզի ամեն ինչ կարգին լինի DBMS-ի տեսանկյունից: Ո՞րն է ձեր մոտեցումը:
ԴՍՉի կարող մեկ պատասխան լինել: Կան մի քանի տարբերակներ. Առաջինը հիմքի չափն է, որը մենք ցանկանում ենք գլորել: Դուք ինքներդ նշեցիք, որ ընկերությունները տարբեր վերաբերմունք ունեն dev-ի և բեմի վրա prod տվյալների բազայի պատճեն ունենալու նկատմամբ:
НСԻսկ GDPR-ի պայմաններում, կարծում եմ, գնալով ավելի ուշադիր են... Կարող եմ ասել, որ Եվրոպայում արդեն սկսել են տուգանքներ կիրառել։
ԴՍԲայց հաճախ դուք կարող եք գրել այնպիսի ծրագրակազմ, որը հեռացնում է արտադրությունից և խեղաթյուրում այն: Արդյունքների տվյալները ստացվում են (պատկերապատում, աղբանոց, երկուական պատճեն...), բայց դրանք անանուն են: Փոխարենը, կարող են լինել սերնդի սցենարներ. դրանք կարող են լինել հարմարանքներ կամ պարզապես սկրիպտ, որը ստեղծում է մեծ տվյալների բազա: Խնդիրն այն է, թե որքան ժամանակ է պահանջվում բազային պատկեր ստեղծելու համար: Իսկ որքա՞ն ժամանակ է պահանջվում այն ցանկալի միջավայրում տեղակայելու համար:
Մենք եկել ենք մի սխեմայի. եթե հաճախորդն ունի ֆիքսված տվյալների հավաքածու (շտեմարանի նվազագույն տարբերակը), ապա մենք դրանք օգտագործում ենք լռելյայն: Եթե մենք խոսում ենք վերանայման միջավայրերի մասին, երբ մենք ստեղծեցինք մասնաճյուղ, մենք տեղակայեցինք հավելվածի օրինակ. մենք այնտեղ բացում ենք փոքրիկ տվյալների բազա: Բայց լավ ստացվեց , երբ մենք արտադրությունից օրական մեկ անգամ (գիշերը) աղբանոց ենք վերցնում և դրա հիման վրա այս բեռնված տվյալներով PostgreSQL-ով և MySQL-ով կառուցում ենք Docker կոնտեյներ։ Եթե Ձեզ անհրաժեշտ է ընդլայնել տվյալների բազան 50 անգամ այս պատկերից, ապա դա արվում է բավականին պարզ և արագ:
НС: Պարզ պատճենո՞վ։
ԴՍՏվյալները պահվում են անմիջապես Docker պատկերում: Նրանք. Մենք ունենք պատրաստի պատկեր, թեկուզ 100 ԳԲ։ Docker-ի շերտերի շնորհիվ մենք կարող ենք արագ տեղակայել այս պատկերը այնքան անգամ, որքան անհրաժեշտ է: Մեթոդը հիմար է, բայց լավ է աշխատում։
НСՀետո, երբ փորձարկում եք, այն փոխվում է հենց Docker-ի ներսում, այնպես չէ՞: Պատճենել-գրել Docker-ի ներսում - դեն նետեք այն և նորից գնացեք, ամեն ինչ լավ է: Դաս! Իսկ դուք արդեն արդյո՞ք այն ամբողջությամբ օգտագործում եք:
ԴՍ: Երկար ժամանակով.
НСՄենք շատ նման բաներ ենք անում: Միայն մենք չենք օգտագործում Docker-ի պատճենը գրելու վրա, այլ մեկ այլ:
ԴՍ: Դա ընդհանուր չէ: Իսկ Docker-ն աշխատում է ամենուր:
НСՏեսականորեն՝ այո։ Բայց այնտեղ էլ ունենք մոդուլներ, կարելի է տարբեր մոդուլներ պատրաստել ու աշխատել տարբեր ֆայլային համակարգերով։ Ինչպիսի՜ պահ է այստեղ։ Պոստգրեսի կողմից մենք այս ամենին այլ կերպ ենք նայում։ Հիմա ես նայեցի Docker-ի կողմից և տեսա, որ ամեն ինչ աշխատում է ձեզ համար: Բայց եթե տվյալների բազան հսկայական է, օրինակ՝ 1 ՏԲ, ապա այս ամենը երկար ժամանակ է պահանջում՝ վիրահատություններ գիշերը, և ամեն ինչ լցնում Docker-ի մեջ... Իսկ եթե 5 ՏԲ լցնում են Docker-ի մեջ... Թե՞ ամեն ինչ կարգին է։
ԴՍՈ՞րն է տարբերությունը. սրանք բլիթներ են, ընդամենը բիթ և բայթ:
НСՏարբերությունը սա է. դա անում եք աղբանոցով և վերականգնո՞ւմ եք:
ԴՍ: Բոլորովին անհրաժեշտ չէ: Այս պատկերի ստեղծման մեթոդները կարող են տարբեր լինել:
НСՈրոշ հաճախորդների համար մենք այնպես ենք արել, որ կանոնավոր կերպով բազային պատկեր ստեղծելու փոխարեն մենք անընդհատ թարմացնում ենք այն: Այն ըստ էության կրկնօրինակ է, բայց տվյալներ ստանում է ոչ թե անմիջականորեն վարպետից, այլ արխիվի միջոցով։ Երկուական արխիվ, որտեղ WAL-ները ներբեռնվում են ամեն օր, որտեղ պահուստային պատճեններ են արվում... Այս WAL-ները հետո մի փոքր ուշացումով (բառացիորեն 1-2 վայրկյան) հասնում են հիմնական պատկերին: Մենք ամեն կերպ կլոնավորում ենք դրանից. այժմ մենք լռելյայն ունենք ZFS:
ԴՍԲայց ZFS-ով դուք սահմանափակվում եք մեկ հանգույցով:
НС:Այո։ Բայց ZFS-ն ունի նաև կախարդական բան Դրանով դուք կարող եք ուղարկել լուսանկար և նույնիսկ (ես դեռ իսկապես չեմ փորձարկել սա, բայց ...) կարող եք ուղարկել դելտա երկուսի միջև: PGDATA. Փաստորեն, մենք ունենք մեկ այլ գործիք, որը մենք իրականում չենք դիտարկել նման առաջադրանքների համար: PostgreSQL-ն ունի , որն աշխատում է որպես «խելացի» rsync՝ բաց թողնելով այն, ինչ դուք պետք չէ դիտել, քանի որ այնտեղ ոչինչ չի փոխվել: Մենք կարող ենք արագ սինխրոնիզացիա անել երկու սերվերների միջև և նույն կերպ հետ շրջել։
Այսպիսով, այս, ավելի շատ DBA-ի կողմից, մենք փորձում ենք ստեղծել մի գործիք, որը թույլ է տալիս մեզ անել նույնը, ինչ դուք ասացիք. մենք ունենք մեկ տվյալների բազա, բայց մենք ուզում ենք ինչ-որ բան փորձարկել 50 անգամ, գրեթե միաժամանակ:
ԴՍ50 անգամ նշանակում է, որ դուք պետք է պատվիրեք 50 Spot դեպք:
НСՈչ, մենք ամեն ինչ անում ենք մեկ մեքենայի վրա:
ԴՍԲայց ինչպե՞ս եք ընդլայնելու 50 անգամ, եթե այս տվյալների բազան, ասենք, տերաբայթ է: Ամենայն հավանականությամբ նրան պետք է պայմանական 256 ԳԲ RAM:
НСԱյո, երբեմն ձեզ շատ հիշողություն է պետք, դա նորմալ է: Բայց սա օրինակ է կյանքից։ Արտադրական մեքենան ունի 96 միջուկ և 600 ԳԲ: Միևնույն ժամանակ տվյալների բազայի համար օգտագործվում է 32 միջուկ (այժմ երբեմն նույնիսկ 16 միջուկ) և 100-120 ԳԲ հիշողություն:
ԴՍԵվ այնտեղ տեղավորվում է 50 օրինակ:
НСՈւրեմն կա միայն մեկ պատճեն, այնուհետև աշխատում է պատճենել գրելու վրա (ZFS)... Ես ձեզ ավելի մանրամասն կպատմեմ:
Օրինակ, մենք ունենք 10 ՏԲ տվյալների բազա: Սրա համար դիսկ են սարքել, ZFS-ն էլ չափը սեղմել է 30-40 տոկոսով։ Քանի որ մենք չենք կատարում բեռնման փորձարկում, մեզ համար կարևոր չէ պատասխանի ճշգրիտ ժամանակը. թող այն լինի մինչև 2 անգամ ավելի դանդաղ, դա լավ է:
Մենք հնարավորություն ենք տալիս ծրագրավորողներին, QA, DBA և այլն։ կատարել թեստավորում 1-2 թելերով: Օրինակ, նրանք կարող են իրականացնել ինչ-որ միգրացիա: Այն չի պահանջում միանգամից 10 միջուկ. անհրաժեշտ է 1 Postgres backend, 1 միջուկ: Միգրացիան կսկսվի – միգուցե դեռ կսկսվի, ապա կօգտագործվի երկրորդ միջուկը: Մենք ունենք 16-32 միջուկ հատկացված, այնպես որ 10 հոգի կարող է միաժամանակ աշխատել, խնդիր չկա։
Քանի որ ֆիզիկապես PGDATA նույնը, պարզվում է, որ մենք իրականում խաբում ենք Պոստգրեսին։ Խաբեությունը սա է՝ օրինակ, 10 Postgres գործարկվում են միաժամանակ։ Ո՞րն է սովորաբար խնդիրը: Նրանք դրեցին , ասենք 25%։ Համապատասխանաբար, սա 200 ԳԲ է: Դուք չեք կարողանա գործարկել դրանցից երեքից ավելին, քանի որ հիշողությունը կսպառվի:
Բայց ինչ-որ պահի մենք հասկացանք, որ դա անհրաժեշտ չէ. մենք shared_buffers սահմանեցինք 2 ԳԲ: PostgreSQL-ն ունի , իսկ իրականում դա միակն է, որ ազդում է . Մենք սահմանել ենք այն 0,5 ՏԲ: Եվ նույնիսկ կարևոր չէ, որ դրանք իրականում գոյություն չունեն. նա այնպիսի ծրագրեր է կազմում, կարծես դրանք գոյություն ունեն:
Համապատասխանաբար, երբ մենք փորձարկենք ինչ-որ միգրացիա, մենք կարող ենք հավաքել բոլոր պլանները. մենք կտեսնենք, թե ինչպես դա տեղի կունենա արտադրության մեջ: Այնտեղ վայրկյանները տարբեր կլինեն (ավելի դանդաղ), բայց տվյալները, որոնք մենք իրականում կարդում ենք, և պլաններն իրենք (ինչ JOIN-ներ կան և այլն) ստացվում են ճիշտ նույնը, ինչ արտադրության մեջ: Եվ դուք կարող եք բազմաթիվ նման ստուգումներ իրականացնել զուգահեռ մեկ մեքենայի վրա:
ԴՍՉե՞ք կարծում, որ այստեղ մի քանի խնդիրներ կան: Առաջինը լուծում է, որն աշխատում է միայն PostgreSQL-ում: Այս մոտեցումը շատ մասնավոր է, այն ընդհանուր չէ: Երկրորդն այն է, որ Kubernetes-ը (և այն ամենը, ինչին այժմ պատրաստվում են ամպային տեխնոլոգիաները) ներառում է բազմաթիվ հանգույցներ, և այդ հանգույցները ժամանակավոր են: Իսկ ձեր դեպքում դա պետական, համառ հանգույց է: Այս բաներն ինձ հակամարտություն են առաջացնում:
НСՆախ, ես համաձայն եմ, սա զուտ Պոստգրեսի պատմություն է: Կարծում եմ, եթե մենք ունենանք ինչ-որ ուղղակի IO և բուֆերային լողավազան գրեթե ամբողջ հիշողության համար, այս մոտեցումը չի աշխատի. ծրագրերը տարբեր կլինեն: Բայց առայժմ մենք աշխատում ենք միայն Postgres-ի հետ, չենք մտածում ուրիշների մասին:
Kubernetes-ի մասին. Դուք ինքներդ մեզ ամենուր ասում եք, որ մենք ունենք մշտական տվյալների բազա: Եթե օրինակը ձախողվի, հիմնականը սկավառակը պահպանելն է: Այստեղ մենք ունենք նաև ամբողջ հարթակը Kubernetes-ում, և Postgres-ի հետ բաղադրիչն առանձին է (չնայած այն մի օր այնտեղ կլինի): Հետևաբար, ամեն ինչ այսպես է՝ ինստանցիան ընկավ, բայց մենք պահպանեցինք նրա ՖՎ-ն և ուղղակի միացրինք մեկ այլ (նոր) ատյանի, կարծես ոչինչ էլ չի եղել։
ԴՍԻմ տեսանկյունից, մենք pods ենք ստեղծում Kubernetes-ում: K8-ներ՝ առաձգական՝ ըստ անհրաժեշտության պատվիրվում են հանգույցներ։ Խնդիրն այն է, որ պարզապես ստեղծել պատիճ և ասել, որ դրա համար անհրաժեշտ է X քանակի ռեսուրս, և այնուհետև K8-ն ինքնուրույն կհասկանա դա: Բայց Kubernetes-ում պահեստավորման աջակցությունը դեռևս անկայուն է. Մեջ (այս թողարկումը թողարկվել է Շաբաթվա առաջ) այս հատկանիշները դառնում են միայն բետա:
Կանցնի վեց ամսից մինչև մեկ տարի՝ քիչ թե շատ կայուն կդառնա, կամ գոնե այդպիսին կհայտարարվի։ Այնուհետև snapshot-ի և չափափոխելու հնարավորությունը լիովին լուծում է ձեր խնդիրը: Քանի որ դուք հիմք ունեք: Այո, դա կարող է շատ արագ չլինել, բայց արագությունը կախված է նրանից, թե ինչ է «կապակի տակ», քանի որ որոշ իրականացումներ կարող են պատճենել և պատճենել-գրել սկավառակի ենթահամակարգի մակարդակում:
НСԱնհրաժեշտ է նաև, որ բոլոր շարժիչները (Amazon, Google...) սկսեն աջակցել այս տարբերակին. սա նույնպես որոշ ժամանակ է պահանջում:
ԴՍՄենք դեռ չենք օգտագործում դրանք: Մենք օգտագործում ենք մերը:
Տեղական զարգացում Kubernetes-ի համար
НСՀանդիպե՞լ եք նման ցանկության, երբ անհրաժեշտ է տեղադրել բոլոր պատյանները մեկ մեքենայի վրա և կատարել այդքան փոքր փորձարկում: Հայեցակարգի ապացույցն արագ ստանալու համար տեսեք, որ հավելվածն աշխատում է Kubernetes-ում՝ առանց դրա համար մի շարք մեքենաներ հատկացնելու: Կա Minikube, այնպես չէ՞:
ԴՍԻնձ թվում է, որ այս գործը, որը տեղակայված է մեկ հանգույցի վրա, բացառապես տեղական զարգացման մասին է: Կամ նման օրինաչափության որոշ դրսեւորումներ: Ուտել , կա , . Մենք գնում ենք Kubernetes IN Docker-ի օգտագործմանը: Այժմ մենք սկսեցինք աշխատել դրա հետ թեստերի համար:
НСԺամանակին ես կարծում էի, որ սա փորձ է փաթաթել բոլոր պատյանները մեկ Docker պատկերի մեջ: Բայց պարզվեց, որ խոսքը բոլորովին այլ բանի մասին է։ Ինչևէ, կան առանձին բեռնարկղեր, առանձին պատիճներ՝ հենց Docker-ում։
ԴՍ:Այո։ Եվ բավականին զվարճալի իմիտացիա է արված, բայց իմաստը սա է... Մենք տեղակայման համար օգտակար ծրագիր ունենք. . Մենք ուզում ենք դա դարձնել պայմանական ռեժիմ werf up«Տե՛ր ինձ տեղական Kubernetes»: Եվ հետո գործարկեք պայմանականը այնտեղ werf follow. Այնուհետև մշակողը կկարողանա խմբագրել IDE-ն, և համակարգում կգործարկվի գործընթաց, որը տեսնում է փոփոխությունները և վերակառուցում պատկերները՝ դրանք վերատեղակայելով տեղական K8-ներում: Այսպես ենք ուզում փորձել լուծել տեղական զարգացման խնդիրը։
Snapshots և տվյալների բազայի կլոնավորում K8s իրականության մեջ
НСԵթե վերադառնանք պատճենահանման-գրելու: Նկատեցի, որ ամպերն էլ ակնթարթներ ունեն։ Նրանք տարբեր կերպ են աշխատում: Օրինակ, GCP-ում դուք ունեք մի քանի տերաբայթանոց օրինակ Միացյալ Նահանգների արևելյան ափին: Դուք պարբերաբար նկարներ եք անում: Դուք լուսանկարից վերցնում եք արևմտյան ափի սկավառակի պատճենը - մի քանի րոպեից ամեն ինչ պատրաստ է, այն շատ արագ է աշխատում, միայն քեշը պետք է լրացվի հիշողության մեջ: Բայց այս կլոնները (պատկերները) նոր հատոր տրամադրելու համար են։ Սա հիանալի է, երբ անհրաժեշտ է ստեղծել շատ օրինակներ:
Բայց թեստերի համար ինձ թվում է, որ snapshot-ները, որոնց մասին դու խոսում ես Docker-ում, կամ ես խոսում եմ ZFS-ում, btrfs-ում և նույնիսկ LVM-ում... - դրանք թույլ են տալիս չստեղծել իսկապես նոր տվյալներ մեկ մեքենայի վրա: Ամպի մեջ դուք դեռ կվճարեք դրանց համար ամեն անգամ և կսպասեք ոչ թե վայրկյաններ, այլ րոպեներ (և դեպքում , հնարավոր է ժամացույց):
Փոխարենը, դուք կարող եք ստանալ այս տվյալները մեկ-երկու վայրկյանում, փորձարկել և դեն նետել այն: Այս լուսանկարները լուծում են տարբեր խնդիրներ: Առաջին դեպքում՝ մեծացնել և ստանալ նոր կրկնօրինակներ, իսկ երկրորդում՝ թեստերի համար:
ԴՍ: Համաձայն չեմ: Ծավալի կլոնավորման ճիշտ աշխատանքը ամպի խնդիրն է: Ես չեմ նայել դրանց իրականացմանը, բայց ես գիտեմ, թե ինչպես ենք մենք դա անում սարքաշարի վրա: Մենք ունենք Ceph, այն թույլ է տալիս ցանկացած ֆիզիկական ծավալ () ասա clone և ստացեք նույն բնութագրերով երկրորդ հատորը տասնյակ միլիվայրկյաններով, «ամի և այլն» Դուք պետք է հասկանաք, որ ներսում գրելու-պատճենման բարդ խնդիր կա: Ինչու՞ ամպը չպետք է անի նույնը: Համոզված եմ, որ նրանք այսպես թե այնպես փորձում են դա անել:
НСԲայց նրանցից դեռ վայրկյաններ, տասնյակ վայրկյաններ կպահանջվեն օրինակ բարձրացնելու, Docker-ին այնտեղ բերելու համար և այլն:
ԴՍԻնչո՞ւ է պետք մի ամբողջ ատյան բարձրացնել։ Մենք ունենք 32 միջուկով օրինակ, 16... և այն կարող է տեղավորվել դրա մեջ, օրինակ՝ չորս: Երբ պատվիրենք հինգերորդը, ինստանցիան արդեն կբարձրացվի, հետո կջնջվի։
НСԱյո, հետաքրքիր է, Kubernetes-ը այլ պատմություն է: Մեր տվյալների բազան K8-ում չէ, և մենք ունենք մեկ օրինակ: Սակայն բազմաթերաբայթանոց տվյալների բազայի կլոնավորումը տևում է ոչ ավելի, քան երկու վայրկյան:
ԴՍ: Սա շատ լավ է. Բայց իմ նախնական միտքն այն է, որ սա ընդհանուր լուծում չէ: Այո, դա հիանալի է, բայց այն հարմար է միայն Postgres-ի համար և միայն մեկ հանգույցի համար:
НСԴա հարմար է ոչ միայն Postgres-ի համար. այս պլանները, ինչպես ես նկարագրեցի, միայն կաշխատեն դրանում: Բայց եթե մենք չենք անհանգստանում պլաններից, և մեզ պարզապես անհրաժեշտ են բոլոր տվյալները ֆունկցիոնալ փորձարկման համար, ապա սա հարմար է ցանկացած DBMS-ի համար:
ԴՍՇատ տարիներ առաջ մենք նմանատիպ մի բան արեցինք LVM-ի snapshot-ներում: Սա դասական է: Այս մոտեցումը շատ ակտիվորեն կիրառվեց։ Պետական հանգույցները պարզապես ցավ են: Որովհետև դրանք չպետք է գցես, պետք է միշտ հիշել նրանց...
НСԴուք այստեղ հիբրիդային հնարավորություն տեսնո՞ւմ եք: Ենթադրենք, stateful-ը ինչ-որ պատիճ է, այն աշխատում է մի քանի մարդկանց համար (շատ փորձարկողներ): Մենք ունենք մեկ հատոր, բայց ֆայլային համակարգի շնորհիվ կլոնները տեղական են։ Եթե պատիճը ընկնում է, բայց սկավառակը մնում է, պատիճը կբարձրանա, կհաշվի տեղեկատվությունը բոլոր կլոնների մասին, նորից վերցնում է ամեն ինչ և ասում.
ԴՍՏեխնիկապես սա նշանակում է, որ Kubernetes-ում այն մեկ պատիճ է, որի ներսում մենք գործարկում ենք բազմաթիվ Postgres:
НС:Այո։ Նա սահման ունի. ասենք, նրա հետ միաժամանակ աշխատում է ոչ ավելի, քան 10 մարդ: Եթե Ձեզ անհրաժեշտ է 20, մենք կգործարկենք նման երկրորդ պատիճը: Մենք այն ամբողջությամբ կկլոնավորենք՝ ստանալով երկրորդ ամբողջական հատորը, այն կունենա նույն 10 «բարակ» կլոնները։ Չե՞ք տեսնում այս հնարավորությունը։
ԴՍՄենք պետք է այստեղ ավելացնենք անվտանգության խնդիրները: Կազմակերպության այս տեսակը ենթադրում է, որ այս pod ունի բարձր արտոնություններ (կարողություններ), քանի որ այն կարող է ոչ ստանդարտ գործողություններ կատարել ֆայլային համակարգում... Բայց կրկնում եմ. կարծում եմ, որ միջնաժամկետ հեռանկարում նրանք կշտկեն պահեստավորումը Kubernetes-ում, և ամպերը նրանք կուղղեն ամբողջ պատմությունը ծավալներով. ամեն ինչ «պարզապես կաշխատի»: Կլինի չափափոխում, կլոնավորում... Մի հատոր կա՝ ասում ենք՝ «Ստեղծիր նորը դրա հիման վրա», ու վայրկյան ու կես հետո ստանում ենք այն, ինչ մեզ պետք է։
НСԵս չեմ հավատում մեկուկես վայրկյանին շատ տերաբայթերի համար: Ceph-ի վրա դուք ինքներդ եք դա անում, բայց խոսում եք ամպերի մասին: Գնացեք ամպի մոտ, EC2-ում EBS-ի բազմաբայթանոց ծավալի կլոն պատրաստեք և տեսեք, թե ինչպիսին կլինի կատարողականը: Դա մի քանի վայրկյան չի տևի: Ինձ շատ է հետաքրքրում, թե երբ նրանք կհասնեն այս մակարդակին։ Ես հասկանում եմ, թե ինչ եք ասում, բայց խնդրում եմ տարբերվել.
ԴՍԼավ, բայց ես ասել եմ միջնաժամկետ, ոչ կարճաժամկետ: Մի քանի տարի շարունակ։
Zalando-ից PostgreSQL-ի օպերատորի մասին
Այս հանդիպման կեսին Ալեքսեյ Կլյուկինը՝ Զալանդոյից նախկին ծրագրավորողը, նույնպես միացավ և խոսեց PostgreSQL օպերատորի պատմության մասին.
Հիանալի է, որ այս թեման առհասարակ շոշափվում է՝ և՛ Postgres, և՛ Kubernetes: Երբ մենք սկսեցինք դա անել Zalando-ում 2017 թվականին, դա մի թեմա էր, որը բոլորն ուզում էին անել, բայց ոչ ոք չարեց: Բոլորն արդեն ունեին Kubernetes, բայց երբ նրանք հարցնում էին, թե ինչ անել տվյալների բազաների հետ, նույնիսկ մարդկանց դուր է գալիս , ով քարոզում էր K8-ները, այսպիսի բան ասաց.
«Գնացեք կառավարվող ծառայություններ և օգտագործեք դրանք, մի գործարկեք տվյալների բազան Kubernetes-ում: Հակառակ դեպքում, ձեր K8-ները կորոշեն, օրինակ, կատարել թարմացում, անջատել բոլոր հանգույցները, և ձեր տվյալները կթռչեն շատ հեռու, հեռու»:
Մենք որոշեցինք ստեղծել օպերատոր, որը, հակառակ այս խորհրդին, կգործարկի Postgres տվյալների բազա Kubernetes-ում: Եվ մենք լավ պատճառ ունեինք. . Սա PostgreSQL-ի ավտոմատ ձախողում է, որը կատարվել է ճիշտ, այսինքն. օգտագործելով etcd-ը, հյուպատոսը կամ ZooKeeper-ը որպես կլաստերի մասին տեղեկատվության պահեստ: Այնպիսի շտեմարան, որը բոլորին, ովքեր հարցնում են, օրինակ, թե որն է ներկայիս ղեկավարը, կտա նույն տեղեկությունը, չնայած նրան, որ մեզ մոտ ամեն ինչ բաշխված է, որպեսզի ուղեղի պառակտում չլինի։ Գումարած մենք ունեինք նրա համար.
Ընդհանուր առմամբ, ընկերության ավտոմատ ձախողման կարիքն առաջացել է ներքին ապարատային տվյալների կենտրոնից ամպ տեղափոխելուց հետո: Ամպը հիմնված էր սեփական PaaS (Platform-as-a-Service) լուծման վրա: Այն բաց կոդով է, բայց այն գործարկելու համար մեծ աշխատանք պահանջվեց: Այն կոչվում էր .
Ի սկզբանե Kubernetes չկար։ Ավելի ճիշտ, երբ մեր սեփական լուծումը տեղակայվեց, K8-ն արդեն կային, բայց այնքան հում էր, որ պիտանի չէր արտադրության համար։ Դա, իմ կարծիքով, 2015 կամ 2016 թվականն էր։ Մինչեւ 2017 թվականը Կուբերնետեսը քիչ թե շատ հասունացել էր. այնտեղ գաղթելու անհրաժեշտություն կար:
Եվ մենք արդեն ունեինք Docker կոնտեյներ: Կար PaaS, որն օգտագործում էր Docker-ը: Ինչու չփորձել K8-ները: Ինչու՞ չգրել ձեր սեփական օպերատորը: Մուրատ Կաբիլովը, ով մեզ մոտ եկավ Ավիտոյից, սա սկսեց որպես նախագիծ իր սեփական նախաձեռնությամբ՝ «խաղալ», և նախագիծը «տարավ»։
Բայց ընդհանուր առմամբ, ես ուզում էի խոսել AWS-ի մասին: Ինչու է եղել պատմական AWS կոդ...
Երբ ինչ-որ բան եք աշխատում Kubernetes-ում, դուք պետք է հասկանաք, որ K8-ն այդպիսի աշխատանք է: Այն անընդհատ զարգանում է, բարելավվում և ժամանակ առ ժամանակ նույնիսկ քայքայվում: Դուք պետք է ուշադիր հետևեք Kubernetes-ի բոլոր փոփոխություններին, դուք պետք է պատրաստ լինեք սուզվել դրա մեջ, եթե ինչ-որ բան պատահի և մանրամասնորեն սովորեք, թե ինչպես է այն աշխատում, գուցե ավելին, քան կցանկանայիք: Սա, սկզբունքորեն, վերաբերում է ցանկացած հարթակին, որի վրա դուք գործարկում եք ձեր տվյալների բազաները...
Այսպիսով, երբ մենք կատարեցինք հայտարարությունը, մենք ունեինք Postgres-ը, որն աշխատում էր արտաքին ծավալով (այս դեպքում EBS, քանի որ մենք աշխատում էինք AWS-ի վրա): Տվյալների բազան մեծացավ, ինչ-որ պահի անհրաժեշտ եղավ չափափոխել. օրինակ, EBS-ի նախնական չափը 100 ՏԲ էր, բազան հասավ դրան, հիմա ուզում ենք EBS-ը դարձնել 200 ՏԲ: Ինչպե՞ս: Ենթադրենք, դուք կարող եք կատարել աղբահանություն/վերականգնում նոր օրինակի վրա, բայց դա երկար ժամանակ կպահանջի և կներառի անգործության ժամանակ:
Հետևաբար, ես ուզում էի չափափոխել, որը կմեծացնի EBS միջնորմը, այնուհետև ֆայլային համակարգին կասեր օգտագործել նոր տարածությունը: Եվ մենք դա արեցինք, բայց այն ժամանակ Kubernetes-ը չուներ API չափափոխման գործողության համար: Քանի որ մենք աշխատում էինք AWS-ի վրա, մենք կոդ գրեցինք դրա API-ի համար:
Ոչ ոք չի խանգարում ձեզ նույնն անել այլ հարթակների համար: Հայտարարության մեջ որևէ ակնարկ չկա, որ այն կարող է գործարկվել միայն AWS-ով, և այն չի աշխատի մնացած ամեն ինչի վրա: Ընդհանուր առմամբ, սա բաց կոդով նախագիծ է. եթե որևէ մեկը ցանկանում է արագացնել նոր API-ի կիրառումը, ապա ողջունում եք: Ուտել , քաշեք հարցումները - Zalando թիմը փորձում է բավականին արագ արձագանքել դրանց և խթանել օպերատորին: Որքան գիտեմ՝ նախագիծը Google Summer of Code-ում և նմանատիպ այլ նախաձեռնություններում: Զալանդոն շատ ակտիվ է աշխատում դրա վրա։
P.S. Բոնուս
Եթե ձեզ հետաքրքրում է PostgreSQL-ի և Kubernetes-ի թեման, ապա խնդրում ենք նաև նշել, որ հաջորդ Postgres երեքշաբթի տեղի է ունեցել անցյալ շաբաթ, որտեղ ես խոսեցի Նիկոլայի հետ: Ալեքսանդր Կուկուշկին Զալանդոյից. Տեսանյութը հասանելի է դրանից .
PPS
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «";
- «.
Source: www.habr.com