Kuidas mage «vaba» PostgreSQL karmidesse ettevõtte keskkondadesse

Paljud tunnevad PostgreSQL andmebaasi, ja see on suurepäraselt tõestanud end väikestes installatsioonides. Kuid avatud lähtekoodiga lahendustele ülemineku trend on saanud üha selgemaks, isegi suurte ettevõtete ja ettevõtte nõudmiste puhul. Selles artiklis räägime, kuidas PostgreSQL-i ettevõtte keskkonda integreerida ning jagame kogemusi varukoopiate loomise süsteemi (VKS) loomisel antud andmebaasi jaoks Commvault'i varukoopiate süsteemi näitel.

PostgreSQL on juba tõestanud oma usaldusväärsuse - andmebaas töötab suurepäraselt, seda kasutavad tuntud digitaalsed ärid nagu Alibaba ja TripAdvisor ning litsentsitasude puudumine teeb sellest ahvatleva alternatiivi sellistele hiiglastele nagu MS SQL või Oracle DB. Kuid niipea kui hakkame mõtlema PostgreSQL-ile ettevõtte maastikus, satume kohe rangete nõudmiste otsa: "Kuidas on olukord konfiguratsiooni talitlushäirete üleelamisega? katastroofide üleelamisega? kus on terviklik jälgimine? ja automatiseeritud varukoopiad? ja teipekogu kasutamine otse ja teise taseme salvestusena?"


Ühest küljest ei ole PostgreSQL-il sisseehitatud varundusvahendeid, nagu näiteks Oracle DB RMAN või SAP andmebaasi varukoopia. Teisest küljest toetavad ettevõtete varundussüsteemide pakkujad (Veeam, Veritas, Commvault) PostgreSQL-i, kuid tegelikult töötavad nad ainult teatud (tavaliselt iseseisva) konfiguratsiooni ja erinevate piirangutega.

PostgreSQLile spetsiaalselt välja töötatud varundussüsteemid, nagu Barman, Wal-g, pg_probackup, on äärmiselt populaarsed väikestes PostgreSQL andmebaasi installatsioonides või seal, kus ei ole vaja raskete tagavarade teisi IT-maastiku elemente. Näiteks, lisaks PostgreSQL-ile võib infrastruktuuris olla füüsilisi ja virtuaalseid komponente. serverid, OpenShift, Oracle, MariaDB, Cassandra jne. Kõike seda on soovitav varundada ühise tööriistaga. Eraldi lahenduse seadmine vaid PostgreSQL-ile on kehv idee: andmed kopeeritakse kuhugi ketastele ja seejärel tuleb need lindile asetada. Selline varunduse dubleerimine pikendab varukoopiate aega ning veelgi kriitilisemalt - taastamisaega.

Enterprise lahenduses toimuvad installatsioonide varukoopiad pühendatud klastrite teatud arvu sõlmedelt. Näiteks suudab Commvault töötada vaid kahe sõlmega klastriga, kus Primary ja Secondary on kindlalt määratud teatud sõlmedele. Varukoopia tegemiseks on mõtet kasutada ainult Primary't, kuna varukoopiad Secondary'lt üldiselt ei toimi. Andmebaasi eripära tõttu ei tehta Secondary-l dump'i, seega jääb alles vaid failide varukoopia võimalus.

Aasta seisaku riski vähendamiseks luuakse ebaõnnestumisvastane süsteem, mis loob „elava” klastrikonfiguratsiooni ning Primary võib järk-järgult migreeruda erinevate serverite vahel. Näiteks tarkvara Patroni käivitab ise Primary'st juhuslikult valitud sõlmel. SRK-l ei ole selle „kastist väljas” jälgimise meetodit ja konfiguratsiooni muutudes puruneb protsess. See tähendab, et väline juhtimine takistab SRK tõhusat tööd, sest juhtimisserver lihtsalt ei mõista, kust ja milliseid andmeid kopeerida.

Veel üks probleem on varukoopia teostamine Postgreses. See on võimalik dump'i kaudu ja väikeste andmebaaside puhul toimib see hästi. Kuid suurte andmebaaside puhul kestab dump'imine kaua, nõuab palju ressursse ja võib põhjustada andmebaasi eksemplari kokkuvarisemise.

Faili varukoopia lahendab probleemi, kuid suurte andmebaaside puhul kulgeb see aeglaselt, kuna see töötab ühesuunaliselt. Lisaks tekib tootjatel terve rida täiendavaid piiranguid. Ükski ei tohi samaaegselt kasutada faili- ja dump-varukoopiat ning dedupeerimist ei toetata. Probleeme on palju ja tihti on lihtsam valida kallis, kuid tõestatud andmebaas Postgresi asemel.

Taganeda pole kuhugi! Tagapool on Moskvas arendajad!

Kuid hiljuti seisis meie meeskond keerulise väljakutse ees: projektis AISI OSAGO 2.0, kus me tegime IT-infrastruktuuri, valisid arendajad uue süsteemi jaoks PostgreSQL-i.

Suurtel tarkvaraarendajatel on palju lihtsam kasutada „moodsaid” avatud lähtekoodiga lahendusi. Facebooki töötajaskonnas on piisavalt spetsialiste, kes hooldavad selle andmebaasi tööd. RSA puhul langesid kõik „teise päeva” ülesanded meie õlule. Meilt nõuti ebaõnnestumisvastasuse tagamist, klastrite loomist ja loomulikult varukoopia seadistamist. Tegevuse loogika oli järgmine:

• Koolitada SRK-d tegema varukoopiaid klastrite peanoodist. Selleks peab SRK suutma seda leida - seega on vajalik integratsioon mõne PostgreSQL klastrihalduse lahendusega. RSC puhul kasutati selleks tarkvara nimega Patroni.
• Määrata bükapi tüüp, lähtudes andmemahtudest ja taastamise nõudmistest. Näiteks, kui tuleb lehti taastada granulaarselt, tuleks kasutada dump’i, aga kui andmebaasid on suured ja granulaarne taastamine ei ole vajalik - töötada failitasemel.
• Lisada lahendusele võimalus plokkvargus, et luua varukoopiaid mitme lõime režiimis.

Kuna alguses seadsime eesmärgiks luua tõhus ja lihtne süsteem ilma tohutu täiendava komponentide koormata. Mida vähem tugivahendeid, seda vähem koormust personali jaoks ja madalam risk SRK tõrgeteks. Lähenemised, kus kasutati Veeam ja RMAN, jätsime kohe välja, kuna kahekäteline lahendus viitab juba süsteemi ebausaldusväärsusele.

Veidi maagiat ettevõtete jaoks

Nii et meil tuli tagada usaldusväärne varundamine 10 klastrile, igaühes 3 nööbid, samal ajal kui varu-andmesaalis asub identne infrastruktuur. Andmesaalid toimivad PostgreSQL osas aktiiv-passiiv printsipil. Andmebaaside kogumaht oli 50 TB. Sellega suudab hakkama saada igasugune ettevõtte taseme SRK. Kuid nüanss on selles, et PostgreSQL-l puudub algselt igasugune tugivõimalus täielikuks ja süvitsi integreeritud varundamissüsteemidega. Seetõttu pidime leidma lahenduse, mis algselt pakuks maksimaalset funktsionaalsust PostgreSQL-iga ning täiustama süsteemi.

Viisime läbi 3 sisemist "hackathoni" - vaatasime üle rohkem kui poolteist tosinat arendust, testisime neid, tegime muudatusi oma hüpoteeside tõttu, kontrollisime uuesti. Analüüsinud saadaval olevad valikud, valisime Commvault. See toode suutis "karbist välja" töötada kõige lihtsama klastritehelndusega PostgreSQLiga, ja selle avatud arhitektuur tekitas lootusi (mis osutusid õigeks) edukaks täiustamiseks ja integreerimiseks. Commvault suudab ka PostgreSQL logide varundamist teha. Näiteks Veritas NetBackup suudab PostgreSQL osas teha ainult täis varukoopiaid.

Lisaks arsitektuurist. Commvault'i haldussüsteemid on paigaldatud igas kahe andmekeskuse CommServ HA konfiguratsioonis. Süsteem on peegeldav, seda haldatakse ühe konsooli kaudu ja HA seisukohalt vastab see kõigile ettevõtte nõuetele.

Samuti oleme igas andmekeskuses käivitanud kaks füüsilist meediaserverit, millele on SAN kaudu ühendatud spetsiaalselt varukoopiate jaoks ette nähtud diskiriiulid ja lintraamatukogud. Jagatud dedupikatsioonibaasid tagavad meediaserverite rikke taluvuse, ning iga serveri ühendamine igasse CSV-sse võimaldab katkematut tööd, isegi kui mõni komponent ebaõnnestub. Süsteemi arhitektuur võimaldab jätkata varukoopiate tegemist isegi siis, kui üks andmekeskus kukub välja.

Patroni määrab igas klastris Primary sõlme. See võib olla iga vaba sõlm andmekeskuses - aga ainult põhiklastris. Varuklastris on kõik sõlmed - Secondary.

Kuna Commvault peab teadma, milline klastrisõlm on Primary, integreerisime süsteemi (tänu avatud arhitektuurile) Postgressiga. Selleks loodi skript, mis edastab teavet hetke Primary sõlme asukoha kohta haldussüsteemile. serveri Commvault.

Kokkuvõttes näeb protsess välja selline:

Patroni valib Primary → Keepalived tõstab IP-klastri ja käivitab skripti → Commvaulti agent valitud klastrisõlmes saab teate, et see on Primary → Commvault kohandab automaatselt varukoopiat psühhokliendi raames.

Selle meetodi pluss on see, et lahendus ei mõjuta ei järjepidevust, ei logide korrektsust, ega Postgressi instantsi taastamist. See on samuti kergesti skaleeritav, kuna Commvault ei pea enam fikseerima Primary ja Secondary sõlmi. Piisab, et süsteem mõistab, kus on Primary, ning sõlmede arvu saab peaaegu piiramatus mahus suurendada.

Lahendus ei pretendeeri ideaalile ja tal on oma nüansid. Commvault oskab varundada ainult kogu instantsi, mitte eraldi andmebaase. Seetõttu on iga andmebaasi jaoks loodud eraldi instants. Reaalsed kliendid on ühendatud virtuaalseteks psühhoklientideks. Iga psühhokliendi Commvault on UNIX klaster. Sellesse lisatakse need klastrisõlmed, kus on installitud Commvaulti agent Postgres jaoks. Tulemuseks on see, et kõik virtuaalsed psühhokliendi sõlmed varundatakse kui üks instants.

Iga iga valeklient sisaldab aktiivset klastrinoodi. Just seda määratleb meie integreerimislahendus Commvaultile. Selle tööpõhimõte on piisavalt lihtne: kui nodis aktiveeritakse klastripõhine IP, seadistab skript Commvault'i agendi binaaris „aktiivne nod“, mille stsenaarium sisuliselt paneb „1“ vajaliku mälukoha. Agent edastab need andmed CommServe'ile ja Commvault teeb varukoopia soovitud sõlmel. Lisaks sellele kontrollib skript konfiguratsiooni korrektsust, vältides varukoopiate käivitamisel vigu.

Selle käigus varukoopiatakse suured andmebaasid plokkide järgi mitmes voos, vastates RPO ja varukoopiate akna nõuetele. Koormus süsteemile on väike: Täiskoopiad toimuvad mitte nii sageli, ülejäänud päevadel kogutakse ainult logisid, ja need tehakse madala koormuse perioodidel.

Muide, oleme rakendanud eraldi poliitikaid PostgreSQL arhiivilogide varundamiseks - need säilitatakse muude reeglite kohaselt, kopeeritakse muude ajakavade järgi ning nende jaoks ei aktiveerita deduplicationi, kuna need logid sisaldavad unikaalseid andmeid.

Konsistentsuse tagamiseks kogu IT infrastruktuuris on Commvault'i eraldi failiklientide installatsioon iga klastrinoodi peal. Need välistavad varukoopiatest Postgres failid ja on mõeldud ainult OSu ja rakenduslike programmide varundamiseks. Selle andmegrupi jaoks on ette nähtud ka oma poliitika ja hoidmise periood.

Praegu ei mõjuta SRK tootlikke teenuseid, kuid kui olukord muutub, saab Commvaultis aktiveerida koormuse piiramise süsteemi.

Sobib? Sobib!

Nii oleme saanud mitte ainult funktsionaalse, vaid ka täielikult automatiseeritud varukoopia PostgreSQL klastripaigaldusest, vastates kõikidele ettevõtte nõudmistele.

RPO ja RTO parameetrid 1 tunni ja 2 tunni kohta on ületatud varuga, mis tähendab, et süsteem vastab neile ka andmehulga oluliselt suurenemise korral. Vastupidiselt paljudele kahtlustele osutus PostgreSQL ja ettevõtte keskkond täiesti ühilduvaks. Ja nüüd teame oma kogemusel, et varundamine selliste andmebaasisüsteemide jaoks on võimalik kõige mitmekesisemates konfiguratsioonides.

Muidugi pidime sellel teel kulutama seitse paari metalljalatseid, ületama mitmeid raskusi, astuma mitmeid miine ja parandama hulgaliselt vigu. Kuid nüüd on meetod juba katsetatud ja seda saab kasutada Open Source'i rakendamiseks mitte-kasutajate andmebaaside asemel äritegevuse karmides tingimustes.

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

Autorid:

Oleg Lavrenov, andmesalvestussüsteemide projekteerimise insener «Infosystemid Jet»

Dmitri Erikin, arvutuskomplekside projekteerimise insener «Infosystemid Jet»

Allikas: habr.com