Շատերը ծանոթ են PostgreSQL DBMS-ին, և այն իրեն ապացուցել է փոքր տեղադրություններում: Այնուամենայնիվ, դեպի բաց կոդով միտումը գնալով ավելի պարզ է դառնում, նույնիսկ երբ խոսքը վերաբերում է խոշոր ընկերություններին և ձեռնարկությունների պահանջներին: Այս հոդվածում մենք ձեզ կպատմենք, թե ինչպես կարելի է ինտեգրել Postgres-ը կորպորատիվ միջավայրում և կիսվել այս տվյալների բազայի համար պահեստային համակարգ (BSS) ստեղծելու մեր փորձով, օգտագործելով Commvault կրկնօրինակման համակարգը որպես օրինակ:
PostgreSQL-ն արդեն ապացուցել է իր արժեքը. DBMS-ը հիանալի է աշխատում, այն օգտագործվում է նորաձև թվային բիզնեսների կողմից, ինչպիսիք են Alibaba-ն և TripAdvisor-ը, և արտոնագրման վճարների բացակայությունը այն դարձնում է գայթակղիչ այլընտրանք այնպիսի հրեշներին, ինչպիսիք են MS SQL-ը կամ Oracle DB-ն: Բայց հենց որ սկսենք մտածել PostgreSQL-ի մասին Enterprise-ի լանդշաֆտում, մենք անմիջապես բախվում ենք խիստ պահանջների. աղետների դիմադրություն? որտեղ է համապարփակ մոնիտորինգը. Ի՞նչ կասեք ավտոմատացված կրկնօրինակումների մասին: Ի՞նչ կասեք ժապավենային գրադարանների օգտագործման մասին և՛ ուղղակիորեն, և՛ երկրորդական պահեստում»:
Մի կողմից, PostgreSQL-ը չունի ներկառուցված պահուստավորման գործիքներ, ինչպիսիք են «մեծահասակների» DBMS-ները, ինչպիսիք են RMAN-ը Oracle DB-ում կամ SAP տվյալների բազայի կրկնօրինակում: Մյուս կողմից, կորպորատիվ պահեստային համակարգերի մատակարարները (Veeam, Veritas, Commvault), թեև աջակցում են PostgreSQL-ին, իրականում նրանք աշխատում են միայն որոշակի (սովորաբար ինքնուրույն) կոնֆիգուրացիայով և տարբեր սահմանափակումներով:
Պահուստային համակարգերը, որոնք հատուկ նախագծված են PostgreSQL-ի համար, ինչպիսիք են Barman, Wal-g, pg_probackup, չափազանց տարածված են PostgreSQL DBMS-ի փոքր տեղակայանքներում կամ որտեղ ՏՏ լանդշաֆտի այլ տարրերի ծանր կրկնօրինակումներ անհրաժեշտ չեն: Օրինակ, բացի PostgreSQL-ից, ենթակառուցվածքը կարող է ներառել ֆիզիկական և վիրտուալ սերվերներ, OpenShift, Oracle, MariaDB, Cassandra և այլն: Ցանկալի է այս ամենը կրկնօրինակել ընդհանուր գործիքով։ Բացառապես PostgreSQL-ի համար առանձին լուծում տեղադրելը վատ գաղափար է. տվյալները կպատճենվեն ինչ-որ տեղ սկավառակի վրա, այնուհետև դրանք պետք է հեռացվեն ժապավենի վրա: Այս կրկնակի կրկնօրինակումը մեծացնում է պահուստավորման ժամանակը, ինչպես նաև, ավելի կարևոր է, վերականգնման ժամանակը:
Ձեռնարկությունների լուծումներում տեղադրման կրկնօրինակումը տեղի է ունենում հատուկ կլաստերի որոշակի քանակությամբ հանգույցներով: Միևնույն ժամանակ, օրինակ, Commvault-ը կարող է աշխատել միայն երկու հանգույցներից բաղկացած կլաստերի հետ, որտեղ Primary-ը և Secondary-ը խստորեն վերագրվում են որոշակի հանգույցների: Եվ իմաստ ունի միայն առաջնայինից կրկնօրինակել, քանի որ երկրորդականից կրկնօրինակումն ունի իր սահմանափակումները: DBMS-ի առանձնահատկություններից ելնելով Երկրորդականի վրա աղբավայր չի ստեղծվում, և հետևաբար մնում է միայն ֆայլի կրկնօրինակման հնարավորությունը:
Անգործության ռիսկը նվազեցնելու համար սխալներին հանդուրժող համակարգ ստեղծելիս ստեղծվում է «կենդանի» կլաստերի կոնֆիգուրացիա, և առաջնայինը կարող է աստիճանաբար տեղափոխել տարբեր սերվերների միջև: Օրինակ, Patroni ծրագրակազմն ինքն է գործարկում առաջնայինը պատահականորեն ընտրված կլաստերային հանգույցի վրա: IBS-ը հնարավորություն չունի հետևելու դրան, և եթե կոնֆիգուրացիան փոխվի, գործընթացները կոտրվում են: Այսինքն՝ արտաքին հսկողության ներդրումը խանգարում է ISR-ին արդյունավետ աշխատել, քանի որ կառավարման սերվերը պարզապես չի հասկանում, թե որտեղից և ինչ տվյալներից պետք է պատճենել։
Մեկ այլ խնդիր է Postgres-ում կրկնօրինակի իրականացումը։ Դա հնարավոր է dump-ի միջոցով, և այն աշխատում է փոքր տվյալների բազաների վրա։ Բայց մեծ տվյալների բազաներում աղբավայրը երկար ժամանակ է պահանջում, պահանջում է շատ ռեսուրսներ և կարող է հանգեցնել տվյալների բազայի օրինակի ձախողման:
Ֆայլի պահուստավորումը շտկում է իրավիճակը, բայց մեծ տվյալների բազաներում այն դանդաղ է, քանի որ այն աշխատում է մեկ թելային ռեժիմով: Բացի այդ, վաճառողներն ունեն մի շարք լրացուցիչ սահմանափակումներ: Կամ դուք չեք կարող միաժամանակ օգտագործել ֆայլերի և պահուստային պատճենները, կամ կրկնօրինակումը չի ապահովվում: Խնդիրները շատ են, և ամենից հաճախ Postgres-ի փոխարեն ավելի հեշտ է ընտրել թանկ, բայց ապացուցված DBMS:
Նահանջելու տեղ չկա։ Մոսկվայի մշակողները հետ են մնում.
Այնուամենայնիվ, վերջերս մեր թիմը բախվեց դժվարին մարտահրավերի. AIS OSAGO 2.0-ի ստեղծման նախագծում, որտեղ մենք ստեղծեցինք ՏՏ ենթակառուցվածքը, մշակողները նոր համակարգի համար ընտրեցին PostgreSQL-ը:
Խոշոր ծրագրեր մշակողների համար շատ ավելի հեշտ է օգտագործել «գերժամանակակից» բաց կոդով լուծումներ: Facebook-ն ունի բավականաչափ մասնագետներ այս DBMS-ի աշխատանքին աջակցելու համար։ Իսկ ՌՍԱ-ի դեպքում «երկրորդ օրվա» բոլոր գործերն ընկան մեր ուսերին։ Մեզնից պահանջվում էր ապահովել անսարքությունների հանդուրժողականություն, հավաքել կլաստեր և, իհարկե, ստեղծել պահուստավորում: Գործողության տրամաբանությունը հետևյալն էր.
- Սովորեցրեք SRK-ին կրկնօրինակներ ստեղծել կլաստերի Հիմնական հանգույցից: Դա անելու համար SRK-ը պետք է գտնի այն, ինչը նշանակում է, որ անհրաժեշտ է ինտեգրում PostgreSQL կլաստերի կառավարման այս կամ այն լուծման հետ: RSA-ի դեպքում դրա համար օգտագործվել է Patroni ծրագրակազմը:
- Որոշեք կրկնօրինակման տեսակը՝ հիմնվելով տվյալների ծավալի և վերականգնման պահանջների վրա: Օրինակ, երբ անհրաժեշտ է էջերը հատիկորեն վերականգնել, օգտագործեք աղբավայր, և եթե տվյալների բազաները մեծ են, և հատիկավոր վերականգնում չի պահանջվում, աշխատեք ֆայլի մակարդակով:
- Բազմաթելային ռեժիմով կրկնօրինակ պատճեն ստեղծելու համար լուծումին կցեք արգելափակման կրկնօրինակման հնարավորությունը:
Միևնույն ժամանակ, մենք ի սկզբանե ձեռնամուխ եղանք ստեղծելու արդյունավետ և պարզ համակարգ առանց լրացուցիչ բաղադրիչների հրեշավոր զրահի: Որքան քիչ հենակներ, այնքան ավելի քիչ ծանրաբեռնվածություն անձնակազմի վրա և ցածր IBS-ի ձախողման ռիսկը: Մենք անմիջապես բացառեցինք մոտեցումները, որոնք օգտագործում էին Veeam և RMAN, քանի որ երկու լուծումների հավաքածուն արդեն հուշում է համակարգի անվստահելիության մասին:
Մի փոքր կախարդանք ձեռնարկության համար
Այսպիսով, մենք պետք է երաշխավորեինք հուսալի պահուստավորում յուրաքանչյուր 10 հանգույցներից բաղկացած 3 կլաստերների համար՝ նույն ենթակառուցվածքով, որոնք արտացոլված էին պահեստային տվյալների կենտրոնում: Տվյալների կենտրոնները PostgreSQL-ի առումով աշխատում են ակտիվ-պասիվ սկզբունքով: Տվյալների բազայի ընդհանուր չափը 50 ՏԲ էր: Ցանկացած կորպորատիվ մակարդակի վերահսկման համակարգ կարող է հեշտությամբ հաղթահարել դա: Բայց նախազգուշացումն այն է, որ ի սկզբանե Postgres-ը տեղեկություն չունի պահեստային համակարգերի հետ լիարժեք և խորը համատեղելիության մասին: Հետևաբար, մենք պետք է փնտրեինք լուծում, որն ի սկզբանե ուներ առավելագույն ֆունկցիոնալություն PostgreSQL-ի հետ համատեղ, և կատարելագործեինք համակարգը:
Մենք անցկացրեցինք 3 ներքին «հեքըթոն». մենք դիտեցինք ավելի քան հիսուն զարգացումներ, փորձարկեցինք դրանք, փոփոխություններ կատարեցինք մեր վարկածների հետ կապված և նորից փորձարկեցինք: Առկա տարբերակները ուսումնասիրելուց հետո մենք ընտրեցինք Commvault-ը: Այս արտադրանքը կարող էր աշխատել ամենապարզ PostgreSQL կլաստերի տեղադրման հետ, և նրա բաց ճարտարապետությունը հույսեր էր արթնացնում (որոնք արդարացված էին) հաջող զարգացման և ինտեգրման համար: Commvault-ը կարող է նաև կրկնօրինակել PostgreSQL տեղեկամատյանները: Օրինակ, Veritas NetBackup-ը PostgreSQL-ի առումով կարող է միայն ամբողջական կրկնօրինակումներ անել:
Ավելին ճարտարապետության մասին: Commvault կառավարման սերվերները տեղադրվել են տվյալների երկու կենտրոններից յուրաքանչյուրում՝ CommServ HA կոնֆիգուրացիայի մեջ: Համակարգը արտացոլված է, կառավարվում է մեկ վահանակի միջոցով և, HA-ի տեսանկյունից, համապատասխանում է ձեռնարկության բոլոր պահանջներին:
Մենք նաև գործարկեցինք երկու ֆիզիկական մեդիա սերվեր յուրաքանչյուր տվյալների կենտրոնում, որոնց միացրինք սկավառակների զանգվածներ և ժապավենային գրադարաններ, որոնք հատուկ նախատեսված էին SAN-ի միջոցով օպտիկամանրաթելային ալիքի միջոցով կրկնօրինակումների համար: Ընդլայնված կրկնօրինակման տվյալների բազաները ապահովում էին մեդիա սերվերների սխալների հանդուրժողականությունը, և յուրաքանչյուր սերվերի միացումը յուրաքանչյուր CSV-ին հնարավորություն էր տալիս շարունակական աշխատանքը, եթե որևէ բաղադրիչ ձախողվեր: Համակարգի ճարտարապետությունը թույլ է տալիս կրկնօրինակումը շարունակել, նույնիսկ եթե տվյալների կենտրոններից մեկն ընկնում է:
Patroni-ն յուրաքանչյուր կլաստերի համար սահմանում է Առաջնային հանգույց: Դա կարող է լինել ցանկացած ազատ հանգույց տվյալների կենտրոնում, բայց միայն հիմնականում: Կրկնօրինակում բոլոր հանգույցները երկրորդական են:
Որպեսզի Commvault-ը հասկանա, թե որ կլաստերային հանգույցն է առաջնային, մենք համակարգը ինտեգրեցինք (լուծման բաց ճարտարապետության շնորհիվ) Postgres-ի հետ։ Այդ նպատակով ստեղծվել է սկրիպտ, որը հաղորդում է առաջնային հանգույցի ընթացիկ գտնվելու վայրը Commvault կառավարման սերվերին:
Ընդհանուր առմամբ, գործընթացը նման է հետևյալին.
Patroni-ն ընտրում է Primary → Keepalived-ը վերցնում է IP կլաստերը և գործարկում սկրիպտը → Commvault գործակալը ընտրված կլաստերի հանգույցի վրա ծանուցում է ստանում, որ սա Primary → Commvault-ն ավտոմատ կերպով վերակազմավորում է կրկնօրինակը կեղծ հաճախորդի ներսում:
Այս մոտեցման առավելությունն այն է, որ լուծումը չի ազդում Postgres օրինակի հետևողականության, տեղեկամատյանների ճշգրտության կամ վերականգնման վրա: Այն նաև հեշտությամբ մասշտաբելի է, քանի որ այլևս անհրաժեշտ չէ շտկել Commvault առաջնային և երկրորդական հանգույցները: Բավական է, որ համակարգը հասկանա, թե որտեղ է առաջնայինը, և հանգույցների թիվը կարելի է հասցնել գրեթե ցանկացած արժեքի։
Լուծումը չի հավակնում իդեալական լինել և ունի իր նրբությունները։ Commvault-ը կարող է կրկնօրինակել միայն ամբողջ օրինակը, այլ ոչ թե առանձին տվյալների բազաները: Հետեւաբար, յուրաքանչյուր տվյալների բազայի համար ստեղծվել է առանձին օրինակ: Իրական հաճախորդները միավորվում են վիրտուալ կեղծ հաճախորդների մեջ: Յուրաքանչյուր Commvault կեղծ-հաճախորդ UNIX կլաստեր է: Այն կլաստերային հանգույցները, որոնց վրա տեղադրված է Postgres-ի Commvault գործակալը, ավելացվում են դրան: Արդյունքում, կեղծ հաճախորդի բոլոր վիրտուալ հանգույցները կրկնօրինակվում են որպես մեկ օրինակ:
Յուրաքանչյուր կեղծ հաճախորդի ներսում նշվում է կլաստերի ակտիվ հանգույցը: Սա այն է, ինչ սահմանում է Commvault-ի մեր ինտեգրացիոն լուծումը: Դրա գործողության սկզբունքը բավականին պարզ է. եթե հանգույցի վրա բարձրացվում է կլաստերային IP, ապա սցենարը սահմանում է «ակտիվ հանգույց» պարամետրը Commvault գործակալի երկուականում. փաստորեն, սցենարը սահմանում է «1» հիշողության անհրաժեշտ մասում: . Գործակալը փոխանցում է այս տվյալները CommServe-ին, իսկ Commvault-ը կրկնօրինակում է ցանկալի հանգույցից։ Բացի այդ, կոնֆիգուրացիայի ճշգրտությունը ստուգվում է սցենարի մակարդակով, ինչը օգնում է խուսափել սխալներից, երբ սկսում եք կրկնօրինակում:
Միևնույն ժամանակ, մեծ տվյալների բազաները կրկնօրինակվում են բլոկներով մի քանի թելերով՝ բավարարելով RPO-ի և պահեստային պատուհանի պահանջները: Համակարգի վրա ծանրաբեռնվածությունն աննշան է. ամբողջական պատճեններն այնքան էլ հաճախ չեն լինում, մյուս օրերին հավաքվում են միայն տեղեկամատյանները, այն էլ՝ ցածր ծանրաբեռնվածության ժամանակ:
Ի դեպ, մենք կիրառել ենք առանձին քաղաքականություն PostgreSQL արխիվային տեղեկամատյանները կրկնօրինակելու համար. դրանք պահվում են տարբեր կանոնների համաձայն, պատճենվում են այլ ժամանակացույցի համաձայն, և կրկնօրինակումը միացված չէ նրանց համար, քանի որ այդ տեղեկամատյանները պարունակում են եզակի տվյալներ:
Ամբողջ ՏՏ ենթակառուցվածքում հետևողականություն ապահովելու համար կլաստերային հանգույցներից յուրաքանչյուրի վրա տեղադրվում են առանձին Commvault ֆայլերի հաճախորդներ: Դրանք բացառում են Postgres ֆայլերը կրկնօրինակումներից և նախատեսված են միայն ՕՀ-ի և հավելվածների կրկնօրինակների համար։ Տվյալների այս մասն ունի նաև իր քաղաքականությունը և պահպանման ժամկետը:
Ներկայումս IBS-ը չի ազդում արտադրողականության ծառայությունների վրա, բայց եթե իրավիճակը փոխվի, Commvault-ը կարող է միացնել բեռի սահմանափակումը:
Լա՞վ է։ Լավ!
Այսպիսով, մենք ստացել ենք ոչ միայն գործունակ, այլև լիովին ավտոմատացված պահուստավորում PostgreSQL կլաստերի տեղադրման համար, և այն համապատասխանում է ձեռնարկության զանգերի բոլոր պահանջներին:
RPO և RTO 1 ժամ և 2 ժամ պարամետրերը ծածկված են մարժայով, ինչը նշանակում է, որ համակարգը կհամապատասխանի դրանց նույնիսկ պահեստավորված տվյալների ծավալի զգալի ավելացման դեպքում: Հակառակ շատ կասկածների, PostgreSQL-ը և ձեռնարկության միջավայրը բավականին համատեղելի էին։ Եվ հիմա մենք մեր սեփական փորձից գիտենք, որ նման DBMS-ների կրկնօրինակումը հնարավոր է տարբեր կոնֆիգուրացիաներով:
Իհարկե, այս ճանապարհին մենք պետք է մաշեինք յոթ զույգ երկաթե երկարաճիտ կոշիկներ, հաղթահարեինք մի շարք դժվարություններ, ոտք դնելով մի քանի փոցխի և ուղղել մի շարք սխալներ։ Բայց այժմ մոտեցումն արդեն փորձարկվել է և կարող է օգտագործվել բաց կոդով ներդնելու համար սեփականության իրավունքով DBMS-ի փոխարեն ձեռնարկության ծանր պայմաններում:
Փորձե՞լ եք աշխատել PostgreSQL-ի հետ կորպորատիվ միջավայրում:
Հեղինակներ:
Օլեգ Լավրենով, Jet Infosystems-ի տվյալների պահպանման համակարգերի նախագծող ինժեներ
Դմիտրի Էրիկին, Jet Infosystems-ի համակարգչային համակարգերի նախագծող ինժեներ
Source: www.habr.com