Kuidas sobitada „tasuta” PostgreSQL karmi ettevõttekeskkonda

Paljud inimesed tunnevad PostgreSQL DBMS-i ja see on end väikestes installides tõestanud. Avatud lähtekoodi suundumus on aga muutunud üha selgemaks, isegi kui tegemist on suurettevõtete ja ettevõtete nõuetega. Selles artiklis räägime teile, kuidas Postgres ettevõtte keskkonda integreerida, ja jagame oma kogemusi selle andmebaasi varundussüsteemi (BSS) loomisel, kasutades näitena Commvaulti varundussüsteemi.

PostgreSQL on end juba tõestanud – DBMS töötab suurepäraselt, seda kasutavad moodsad digiettevõtted nagu Alibaba ja TripAdvisor ning litsentsitasude puudumine muudab selle ahvatlevaks alternatiiviks sellistele koletistele nagu MS SQL või Oracle DB. Kuid niipea, kui hakkame Enterprise maastikul mõtlema PostgreSQL-ile, põrkame kohe karmide nõueteni: „Aga konfiguratsiooni veataluvus? katastroofi vastupanu? kus on terviklik seire? Aga automaatsed varukoopiad? Kuidas on lood lindiraamatukogude kasutamisega nii otse kui ka teiseses mälus?


Ühest küljest pole PostgreSQL-il sisseehitatud varundustööriistu, nagu "täiskasvanute" DBMS-id, nagu RMAN Oracle DB-s või SAP Database Backup. Teisest küljest, ettevõtete varusüsteemide tarnijad (Veeam, Veritas, Commvault), kuigi nad toetavad PostgreSQL-i, töötavad nad tegelikult ainult teatud (tavaliselt eraldiseisva) konfiguratsiooniga ja mitmesuguste piirangutega.

PostgreSQL-spetsiifilised varundussüsteemid, näiteks Barman, Wal-g ja pg_probackup, on äärmiselt populaarsed väikestes PostgreSQL-i installatsioonides või kohtades, kus pole vaja teha mahukaid varukoopiaid muudest IT-maastiku elementidest. Näiteks lisaks PostgreSQL-ile võib infrastruktuur hõlmata nii füüsilisi kui ka virtuaalseid varundussüsteeme. serverid, OpenShift, Oracle, MariaDB, Cassandra jne. Kõige parem on neid kõiki varundada ühise varundustööriista abil. Eraldi lahenduse juurutamine ainult PostgreSQL-i jaoks on halb mõte: andmed kopeeritakse kuhugi kettale ja seejärel tuleb need lindile teisaldada. See varukoopiate dubleerimine pikendab varundamise aega ja mis veelgi olulisem, taastamisaega.

Ettevõtluslahenduse puhul toimub installi varundamine teatud arvu sõlmedega spetsiaalses klastris. Samal ajal saab näiteks Commvault töötada ainult kahe sõlmega klastriga, kus Primary ja Secondary on rangelt määratud teatud sõlmedele. Ja varundamine on mõttekas ainult esmasest, kuna sekundaarsest varundamisel on oma piirangud. DBMS-i iseärasuste tõttu ei teki Secondary'is tõmmist ja seetõttu jääb alles vaid faili varundamise võimalus.

Seisakuohu vähendamiseks luuakse tõrketaluva süsteemi loomisel klastri „aktiivne“ konfiguratsioon ja Primary saab järk-järgult migreeruda erinevate serverite vahel. Näiteks Patroni tarkvara ise käivitab esmase suvaliselt valitud klastri sõlmel. IBS-il pole võimalust seda karbist välja võtta ja kui konfiguratsioon muutub, protsessid katkevad. See tähendab, et välise kontrolli kasutuselevõtt takistab ISR-i tõhusat töötamist, kuna juhtimisserver lihtsalt ei saa aru, kust ja milliseid andmeid tuleb kopeerida.

Teine probleem on varundamise rakendamine Postgresis. See on võimalik prügikasti kaudu ja see töötab väikestes andmebaasides. Kuid suurtes andmebaasides võtab dump kaua aega, nõuab palju ressursse ja võib põhjustada andmebaasi eksemplari rikke.

Failide varundamine parandab olukorra, kuid suurtes andmebaasides on see aeglane, kuna töötab ühe lõime režiimis. Lisaks on müüjatel mitmeid täiendavaid piiranguid. Te ei saa faile ja varukoopiaid samaaegselt kasutada või dubleerimist ei toetata. Probleeme on palju ja enamasti on Postgresi asemel lihtsam valida kallis, kuid end tõestanud DBMS.

Taganeda pole kuhugi! Moskva arendajad on selja taga!

Hiljuti seisis meie meeskond aga silmitsi keerulise väljakutsega: AIS OSAGO 2.0 loomise projektis, kus lõime IT-infrastruktuuri, valisid arendajad uueks süsteemiks PostgreSQL-i.

Suurtel tarkvaraarendajatel on palju lihtsam kasutada “trendikaid” avatud lähtekoodiga lahendusi. Facebookil on selle DBMS-i toimimise toetamiseks piisavalt spetsialiste. Ja RSA puhul langesid kõik “teise päeva” ülesanded meie õlule. Meilt nõuti tõrketaluvuse tagamist, klastri kokkupanemist ja loomulikult varukoopia seadistamist. Tegevuse loogika oli järgmine:

• Õpetage SRK-d tegema varukoopiaid klastri esmasest sõlmest. Selleks peab SRK selle üles leidma – mis tähendab, et on vaja integreerida ühe või teise PostgreSQL klastrihalduslahendusega. RSA puhul kasutati selleks Patroni tarkvara.
• Otsustage varukoopia tüüp andmete mahu ja taastamisnõuete põhjal. Näiteks kui teil on vaja lehti üksikasjalikult taastada, kasutage tõmmist ja kui andmebaasid on suured ja detailset taastamist pole vaja, töötage faili tasemel.
• Mitme lõimega režiimis varukoopia loomiseks ühendage lahendusele ploki varundamise võimalus.

Samal ajal püüdsime algselt luua tõhusa ja lihtsa süsteemi ilma lisakomponentide koletu rakmeteta. Mida vähem karkusid, seda väiksem on töötajate töökoormus ja seda väiksem on IBS-i ebaõnnestumise oht. Välistasime koheselt Veeami ja RMAN-i kasutanud lähenemised, sest juba kahest lahendusest koosnev komplekt vihjab süsteemi ebausaldusväärsusele.

Väike maagia ettevõtmiseks

Seega pidime tagama usaldusväärse varukoopia 10 klastri jaoks, millest igaühes oli 3 sõlme, kusjuures varuandmekeskuses peegeldub sama infrastruktuur. PostgreSQL-i andmekeskused töötavad aktiivse-passiivse põhimõttel. Andmebaasi kogumaht oli 50 TB. Iga ettevõtte tasemel juhtimissüsteem saab sellega hõlpsasti hakkama. Kuid hoiatus on see, et esialgu pole Postgresil aimugi täielikust ja sügavast ühilduvusest varusüsteemidega. Seetõttu pidime otsima lahendust, millel oli algselt maksimaalne funktsionaalsus koos PostgreSQL-iga, ja süsteemi viimistleda.

Tegime 3 sisemist “hackathoni” – vaatasime üle viiekümne arenduse, testisime neid, tegime seoses oma hüpoteesidega muudatusi ja testisime uuesti. Pärast saadaolevate valikute ülevaatamist valisime Commvaulti. Karbist välja võttes võiks see toode töötada lihtsa PostgreSQL-klastri installiga ning selle avatud arhitektuur tekitas lootusi (mis oli õigustatud) edukaks arendamiseks ja integreerimiseks. Commvault saab varundada ka PostgreSQL-i logisid. Näiteks Veritas NetBackup saab PostgreSQL-i osas teha ainult täielikke varukoopiaid.

Veel arhitektuurist. Commvaulti haldusserverid paigaldati mõlemasse andmekeskusesse CommServ HA konfiguratsioonis. Süsteem on peegelpildis, seda hallatakse ühe konsooli kaudu ja HA seisukohast vastab see kõigile ettevõtte nõuetele.

Samuti käivitasime igas andmekeskuses kaks füüsilist meediumiserverit, millega ühendasime spetsiaalselt SAN-i kaudu Fibre Channeli kaudu varundamiseks mõeldud kettamassiivid ja linditeegid. Laiendatud dubleerimise andmebaasid tagasid meediumiserverite tõrketaluvuse ja iga serveri ühendamine iga CSV-ga võimaldas pidevat tööd, kui mõni komponent ebaõnnestus. Süsteemi arhitektuur võimaldab varundamise jätkamist isegi siis, kui üks andmekeskustest kukub.

Patroni määrab iga klastri jaoks esmase sõlme. See võib olla andmekeskuse mis tahes vaba sõlm, kuid ainult enamasti. Varukoopias on kõik sõlmed sekundaarsed.

Selleks, et Commvault saaks aru, milline klastri sõlm on primaarne, integreerisime süsteemi (lahenduse avatud arhitektuuri tõttu) Postgresiga. Sel eesmärgil lõime skripti, mis teatab haldurile primaarse sõlme praeguse asukoha. server Commvault.

Üldiselt näeb protsess välja selline:

Patroni valib Primary → Keepalived valib IP-klastri ja käivitab skripti → Commvaulti agent valitud klastri sõlmel saab teate, et see on esmane → Commvault konfigureerib pseudokliendis varukoopia automaatselt ümber.

Selle lähenemisviisi eeliseks on see, et lahendus ei mõjuta Postgresi eksemplari järjepidevust, logide õigsust ega taastamist. Samuti on see hõlpsasti skaleeritav, kuna enam pole vaja Commvault primaarset ja sekundaarset sõlme parandada. Piisab, kui süsteem mõistab, kus on Primary, ja sõlmede arvu saab suurendada peaaegu iga väärtuseni.

Lahendus ei pretendeeri ideaalsele ja sellel on omad nüansid. Commvault saab varundada ainult kogu eksemplari, mitte üksikuid andmebaase. Seetõttu loodi iga andmebaasi jaoks eraldi eksemplar. Päriskliendid ühendatakse virtuaalseteks pseudoklientideks. Iga Commvaulti pseudoklient on UNIX-i klaster. Sellele lisatakse need klastri sõlmed, kuhu on installitud Postgresi Commvault agent. Selle tulemusena varundatakse kõik pseudokliendi virtuaalsed sõlmed ühe eksemplarina.

Igas pseudokliendis on näidatud klastri aktiivne sõlm. Seda määratleb meie Commvaulti integratsioonilahendus. Selle tööpõhimõte on üsna lihtne: kui sõlmel tõstetakse klastri IP-aadress, määrab skript Commvault agendi binaarfailis parameetri "aktiivne sõlm" - tegelikult määrab skript mälu vajalikus osas "1" . Agent edastab need andmed CommServe'ile ja Commvault teeb soovitud sõlmest varukoopia. Lisaks kontrollitakse konfiguratsiooni õigsust skripti tasemel, mis aitab vältida vigu varukoopia käivitamisel.

Samal ajal varundatakse suuri andmebaase mitme lõime kaupa plokkidena, mis vastavad RPO ja varundusakna nõuetele. Süsteemi koormus on ebaoluline: täiskoopiaid ei teki nii sageli, muudel päevadel kogutakse ainult logisid ja madala koormuse perioodil.

Muide, oleme PostgreSQL-i arhiivilogide varundamiseks rakendanud eraldi poliitikaid - neid salvestatakse erinevate reeglite järgi, kopeeritakse erineva ajakava järgi ja nende jaoks pole deduplikatsioon lubatud, kuna need logid sisaldavad unikaalseid andmeid.

Kogu IT infrastruktuuri järjepidevuse tagamiseks installitakse igasse klastri sõlme eraldi Commvaulti failikliendid. Need välistavad Postgresi failid varukoopiatest ja on mõeldud ainult OS-i ja rakenduste varundamiseks. Sellel andmete osal on ka oma poliitika ja säilitusaeg.

Praegu IBS tootlikkuse teenuseid ei mõjuta, kuid olukorra muutumisel saab Commvault lubada koormuse piiramist.

Kas see on hea? Hea!

Seega oleme saanud PostgreSQL-i klastri installimiseks mitte ainult toimiva, vaid ka täielikult automatiseeritud varukoopia, mis vastab kõigile ettevõtte kõnede nõuetele.

RPO ja RTO parameetrid 1 tund ja 2 tundi on kaetud marginaaliga, mis tähendab, et süsteem järgib neid isegi salvestatud andmete mahu olulise suurenemise korral. Vastupidiselt paljudele kahtlustele osutus PostgreSQL ja ettevõtte keskkond üsna ühilduvaks. Ja nüüd teame oma kogemusest, et selliste DBMS-ide varundamine on võimalik paljudes konfiguratsioonides.

Loomulikult tuli sel teel ära kulutada seitse paari raudsaapaid, ületada hulk raskusi, astuda mitme reha otsa ja parandada hulk vigu. Kuid nüüd on seda lähenemisviisi juba testitud ja seda saab kasutada avatud lähtekoodiga DBMS-i asemel karmides ettevõtte tingimustes.

Kas olete proovinud PostgreSQL-iga töötada ettevõtte keskkonnas?

Autorid:

Oleg Lavrenov, Jet Infosystemsi andmesalvestussüsteemide projekteerimisinsener

Dmitri Erõkin, Jet Infosystemsi arvutisüsteemide projekteerimisinsener

Allikas: www.habr.com