Margir kannast við PostgreSQL DBMS og það hefur sannað sig í litlum uppsetningum. Hins vegar hefur þróunin í átt að Open Source orðið æ skýrari, jafnvel þegar kemur að stórum fyrirtækjum og kröfum fyrirtækja. Í þessari grein munum við segja þér hvernig á að samþætta Postgres í fyrirtækjaumhverfi og deila reynslu okkar af því að búa til öryggisafritunarkerfi (BSS) fyrir þennan gagnagrunn með því að nota Commvault afritunarkerfið sem dæmi.
PostgreSQL hefur þegar sannað gildi sitt - DBMS virkar frábærlega, það er notað af smart stafrænum fyrirtækjum eins og Alibaba og TripAdvisor, og skortur á leyfisgjöldum gerir það að freistandi valkosti við skrímsli eins og MS SQL eða Oracle DB. En um leið og við förum að hugsa um PostgreSQL í Enterprise landslaginu lendum við strax í ströngum kröfum: „Hvað með villuþol í stillingum? hamfaraviðnám? hvar er alhliða eftirlitið? Hvað með sjálfvirkt öryggisafrit? Hvað með að nota segulbandasafn bæði beint og á aukageymslu?
Annars vegar er PostgreSQL ekki með innbyggð öryggisafritunarverkfæri, eins og „fullorðna“ DBMS eins og RMAN í Oracle DB eða SAP Database Backup. Á hinn bóginn, birgjar öryggisafritunarkerfa fyrirtækja (Veeam, Veritas, Commvault) þó að þeir styðji PostgreSQL, virka þeir í raun aðeins með ákveðna (venjulega sjálfstæða) uppsetningu og með ýmsum takmörkunum.
Öryggisafritunarkerfi sem eru sérstaklega hönnuð fyrir PostgreSQL, eins og Barman, Wal-g, pg_probackup, eru afar vinsæl í litlum uppsetningum á PostgreSQL DBMS eða þar sem ekki er þörf á miklum öryggisafritum af öðrum þáttum upplýsingatæknilandslagsins. Til dæmis, auk PostgreSQL, geta innviðirnir innihaldið líkamlega og sýndarþjóna, OpenShift, Oracle, MariaDB, Cassandra o.s.frv. Það er ráðlegt að taka öryggisafrit af þessu öllu með sameiginlegu tóli. Að setja upp sérstaka lausn eingöngu fyrir PostgreSQL er slæm hugmynd: gögnin verða afrituð einhvers staðar á diskinn og síðan þarf að fjarlægja þau á segulband. Þetta tvöfalda öryggisafrit eykur öryggisafritunartímann, og einnig, það sem meira er, endurheimtartímann.
Í fyrirtækjalausn á sér stað öryggisafrit af uppsetningunni með ákveðnum fjölda hnúta í sérstökum klasa. Á sama tíma, til dæmis, getur Commvault aðeins unnið með tveggja hnúta þyrping, þar sem aðal og framhaldsskóla er stranglega úthlutað ákveðnum hnútum. Og það er bara skynsamlegt að taka öryggisafrit frá Primary, vegna þess að öryggisafrit frá Secondary hefur sínar takmarkanir. Vegna sérkenni DBMS er sorphaugur ekki búinn til á Secondary og því er aðeins möguleikinn á skráarafriti eftir.
Til að draga úr hættu á niður í miðbæ, þegar búið er til bilunarþolið kerfi, er búið til „lifandi“ klasastillingu og Primary getur smám saman flutt á milli mismunandi netþjóna. Til dæmis setur Patroni hugbúnaðurinn sjálfur Primary á slembivalinn klasahnút. IBS hefur enga leið til að rekja þetta út úr kassanum og ef uppsetningin breytist brotna ferlarnir. Það er að segja að innleiðing ytri eftirlits kemur í veg fyrir að ISR virki á skilvirkan hátt, vegna þess að eftirlitsþjónninn skilur einfaldlega ekki hvar og hvaða gögn þarf að afrita.
Annað vandamál er innleiðing öryggisafritunar í Postgres. Það er mögulegt í gegnum sorphaugur og það virkar á litlum gagnagrunnum. En í stórum gagnagrunnum tekur sorphaugurinn langan tíma, krefst mikils fjármagns og getur leitt til bilunar í gagnagrunnstilvikinu.
Afritun skráa leiðréttir ástandið, en á stórum gagnagrunnum er það hægt vegna þess að það virkar í einþráðum ham. Að auki hafa söluaðilar ýmsar viðbótartakmarkanir. Annaðhvort geturðu ekki notað afrit af skrám og afritum á sama tíma eða aftvíföldun er ekki studd. Það eru mörg vandamál og oftast er auðveldara að velja dýrt en sannað DBMS í stað Postgres.
Það er hvergi að hörfa! Moskvu verktaki eru á bak við!
Hins vegar nýlega stóð teymi okkar frammi fyrir erfiðri áskorun: í verkefninu að búa til AIS OSAGO 2.0, þar sem við bjuggum til upplýsingatækniinnviðina, völdu verktaki PostgreSQL fyrir nýja kerfið.
Það er miklu auðveldara fyrir stóra hugbúnaðarframleiðendur að nota „töff“ opinn uppspretta lausnir. Facebook hefur nóg af sérfræðingum til að styðja við rekstur þessa DBMS. Og í tilviki RSA féllu öll verkefni „annar dagsins“ á herðar okkar. Okkur var gert að tryggja bilanaþol, setja saman klasa og að sjálfsögðu setja upp öryggisafrit. Rökfræði aðgerða var sem hér segir:
- Kenndu SRK að taka öryggisafrit frá aðalhnút klasans. Til að gera þetta verður SRK að finna það - sem þýðir að samþætting við eina eða aðra PostgreSQL klasastjórnunarlausn er nauðsynleg. Í tilviki RSA var Patroni hugbúnaður notaður til þess.
- Ákveðið tegund öryggisafrits byggt á gagnamagni og endurheimtarkröfum. Til dæmis, þegar þú þarft að endurheimta síður í smáatriðum, notaðu dump, og ef gagnagrunnarnir eru stórir og ekki er þörf á nákvæmri endurheimt skaltu vinna á skráarstigi.
- Hengdu möguleika á að loka öryggisafriti við lausnina til að búa til öryggisafrit í fjölþráðum ham.
Á sama tíma ætluðum við upphaflega að búa til skilvirkt og einfalt kerfi án voðalegrar beislis viðbótarþátta. Því færri hækjur, því minna álag á starfsfólk og því minni hætta á IBS bilun. Við útilokuðum strax aðferðir sem notuðu Veeam og RMAN, vegna þess að sett af tveimur lausnum gefur nú þegar vísbendingar um óáreiðanleika kerfisins.
Smá galdur fyrir framtakið
Þannig að við þurftum að tryggja áreiðanlegt öryggisafrit fyrir 10 þyrpingar með 3 hnútum hver, með sama innviði sem speglast í öryggisafritunargagnaverinu. Gagnaver með tilliti til PostgreSQL vinna á virku-aðgerðalausu meginreglunni. Heildarstærð gagnagrunnsins var 50 TB. Hvaða stjórnkerfi sem er á fyrirtækjastigi getur auðveldlega ráðið við þetta. En fyrirvarinn er sá að upphaflega hefur Postgres ekki hugmynd um fullan og djúpan eindrægni við afritunarkerfi. Þess vegna þurftum við að leita að lausn sem upphaflega hafði hámarksvirkni í tengslum við PostgreSQL og betrumbæta kerfið.
Við héldum 3 innri „hackaþon“ - við skoðuðum meira en fimmtíu þróun, prófuðum þær, gerðum breytingar í tengslum við tilgátur okkar og prófuðum þær aftur. Eftir að hafa skoðað tiltæka valkostina völdum við Commvault. Upp úr kassanum gæti þessi vara unnið með einföldustu PostgreSQL klasauppsetningu og opinn arkitektúr hennar vakti vonir (sem voru réttlætanlegar) um árangursríka þróun og samþættingu. Commvault getur einnig tekið afrit af PostgreSQL annálum. Til dæmis, Veritas NetBackup hvað PostgreSQL varðar getur aðeins gert fullt afrit.
Meira um arkitektúr. Commvault stjórnunarþjónar voru settir upp í hvoru tveggja gagnaveranna í CommServ HA uppsetningu. Kerfið er speglað, stjórnað í gegnum eina leikjatölvu og, frá sjónarhóli HA, uppfyllir allar kröfur fyrirtækja.
Við opnuðum líka tvo efnismiðla netþjóna í hverri gagnaver, sem við tengdum diskafylki og segulbandasöfn sem eru sérstaklega tileinkuð afritum í gegnum SAN í gegnum Fibre Channel. Framlengdir gagnagrunnar af tvítekningu tryggðu bilanaþol miðlunarþjóna og að tengja hvern netþjón við hvern CSV gerði samfellda aðgerð kleift ef einhver íhluti bilaði. Kerfisarkitektúrinn gerir öryggisafritinu kleift að halda áfram jafnvel þótt eitt af gagnaverunum falli.
Patroni skilgreinir aðalhnút fyrir hvern klasa. Það getur verið hvaða ókeypis hnút sem er í gagnaverinu - en aðeins að mestu leyti. Í öryggisafritinu eru allir hnútar Secondary.
Til þess að Commvault geti skilið hvaða klasahnút er aðal, samþættum við kerfið (þökk sé opnum arkitektúr lausnarinnar) við Postgres. Í þessu skyni var búið til forskrift sem tilkynnir núverandi staðsetningu aðalhnútsins til Commvault stjórnunarþjónsins.
Almennt séð lítur ferlið svona út:
Patroni velur Primary → Keepalved tekur upp IP-þyrpinguna og keyrir handritið → Commvault umboðsmaðurinn á völdum klasahnút fær tilkynningu um að þetta sé Primary → Commvault endurstillir sjálfkrafa öryggisafritið innan gervi-viðskiptavinarins.
Kosturinn við þessa nálgun er að lausnin hefur ekki áhrif á samræmi, réttmæti annála eða endurheimt Postgres tilviksins. Það er líka auðvelt að skala, vegna þess að það er ekki lengur nauðsynlegt að laga Commvault aðal- og aukahnúta. Það er nóg að kerfið skilji hvar Primary er og hægt er að auka fjölda hnúta í nánast hvaða gildi sem er.
Lausnin þykist ekki vera tilvalin og hefur sín blæbrigði. Commvault getur aðeins afritað allt tilvikið, en ekki einstaka gagnagrunna. Þess vegna var sérstakt tilvik búið til fyrir hvern gagnagrunn. Raunverulegir viðskiptavinir eru sameinaðir í sýndar gerviviðskiptavini. Hver Commvault gerviviðskiptavinur er UNIX þyrping. Þeim klasahnútum sem Commvault umboðsmaðurinn fyrir Postgres er settur upp á er bætt við hann. Þess vegna eru allir sýndarhnútar gerviviðskiptavinarins afritaðir sem eitt tilvik.
Innan hvers gervi-viðskiptavinar er virkur hnútur klasans sýndur. Þetta er það sem samþættingarlausnin okkar fyrir Commvault skilgreinir. Meginreglan um rekstur þess er frekar einföld: ef IP-tölu þyrpingar er sett upp á hnút, setur handritið „virka hnútinn“ færibreytuna í Commvault umboðsmann tvíundaranum - í raun setur skriftin „1“ í nauðsynlegum hluta minnisins . Umboðsmaðurinn sendir þessi gögn til CommServe og Commvault gerir öryggisafrit frá viðkomandi hnút. Að auki er réttmæti stillinganna athugað á skriftustigi, sem hjálpar til við að forðast villur þegar öryggisafrit er hafið.
Á sama tíma eru stórir gagnagrunnar afritaðir í blokkum yfir marga þræði, sem uppfylla kröfur um RPO og öryggisafritunarglugga. Álagið á kerfið er óverulegt: Full afrit koma ekki svo oft fyrir, aðra daga er eingöngu safnað annálum og á tímabilum með litlum álagi.
Við the vegur, við höfum beitt aðskildum reglum til að taka öryggisafrit af PostgreSQL skjalasafnsskrám - þær eru geymdar samkvæmt mismunandi reglum, afritaðar samkvæmt annarri áætlun og aftvíföldun er ekki virkjuð fyrir þær, þar sem þessar annálar innihalda einstök gögn.
Til að tryggja samræmi í öllum upplýsingatækniinnviðum eru aðskildir Commvault skráarbiðlarar settir upp á hverjum klasahnútum. Þeir útiloka Postgres skrár frá afritum og eru aðeins ætlaðar fyrir stýrikerfi og afrit af forritum. Þessi hluti gagnanna hefur einnig sína eigin stefnu og geymslutíma.
Eins og er hefur IBS ekki áhrif á framleiðniþjónustu, en ef ástandið breytist getur Commvault virkjað álagstakmörkun.
Er það gott? Góður!
Þannig að við höfum ekki bara fengið framkvæmanlegt, heldur líka fullkomlega sjálfvirkt öryggisafrit fyrir PostgreSQL klasauppsetningu og það uppfyllir allar kröfur um fyrirtækjasímtöl.
RPO og RTO færibreytur 1 klukkustund og 2 klukkustundir eru þakin framlegð, sem þýðir að kerfið mun fara að þeim jafnvel með verulegri aukningu á magni geymdra gagna. Þvert á efasemdir reyndust PostgreSQL og fyrirtækjaumhverfið vera nokkuð samhæft. Og nú vitum við af eigin reynslu að öryggisafrit fyrir slík DBMS er möguleg í margs konar stillingum.
Á þessari leið þurftum við að sjálfsögðu að klæðast sjö pör af járnstígvélum, yfirstíga ýmsa erfiðleika, stíga á nokkrar hrífur og leiðrétta fjölda mistaka. En nú hefur nálgunin þegar verið prófuð og hægt að nota hana til að innleiða Open Source í stað séreignar DBMS við erfiðar fyrirtækjaaðstæður.
Hefur þú prófað að vinna með PostgreSQL í fyrirtækjaumhverfi?
Höfundar:
Oleg Lavrenov, hönnunarverkfræðingur gagnageymslukerfa, Jet Infosystems
Dmitry Erykin, hönnunarverkfræðingur tölvukerfa hjá Jet Infosystems
Heimild: www.habr.com