Veliko ljudi pozna DBMS PostgreSQL in izkazal se je v majhnih namestitvah. Vendar pa je trend v smeri odprte kode postal vse bolj očiten, tudi ko gre za velika podjetja in zahteve podjetij. V tem članku vam bomo povedali, kako integrirati Postgres v poslovno okolje, in delili našo izkušnjo pri ustvarjanju sistema za varnostno kopiranje (BSS) za to bazo podatkov na primeru sistema za varnostno kopiranje Commvault.
PostgreSQL je že dokazal svojo vrednost - DBMS deluje odlično, uporabljajo ga modna digitalna podjetja, kot sta Alibaba in TripAdvisor, zaradi pomanjkanja licenčnin pa je mamljiva alternativa pošastim, kot sta MS SQL ali Oracle DB. Toda takoj, ko začnemo razmišljati o PostgreSQL v okolju Enterprise, takoj naletimo na stroge zahteve: »Kaj pa toleranca napak konfiguracije? odpornost na nesreče? kje je celovit nadzor? Kaj pa samodejne varnostne kopije? Kaj pa uporaba tračnih knjižnic tako neposredno kot v sekundarnem pomnilniku?«
Po eni strani PostgreSQL nima vgrajenih orodij za varnostno kopiranje, kot so "odrasli" DBMS-ji, kot je RMAN v Oracle DB ali SAP Database Backup. Po drugi strani pa ponudniki korporativnih sistemov za varnostno kopiranje (Veeam, Veritas, Commvault), čeprav podpirajo PostgreSQL, dejansko delujejo le z določeno (običajno samostojno) konfiguracijo in z naborom različnih omejitev.
Sistemi za varnostno kopiranje, zasnovani posebej za PostgreSQL, kot so Barman, Wal-g, pg_probackup, so izjemno priljubljeni v majhnih namestitvah DBMS PostgreSQL ali kjer niso potrebne obsežne varnostne kopije drugih elementov okolja IT. Na primer, poleg PostgreSQL lahko infrastruktura vključuje fizične in virtualne strežnike, OpenShift, Oracle, MariaDB, Cassandra itd. Priporočljivo je, da vse to varnostno kopirate z običajnim orodjem. Namestitev ločene rešitve izključno za PostgreSQL je slaba ideja: podatki bodo kopirani nekje na disk, nato pa jih je treba odstraniti na trak. To dvojno varnostno kopiranje podaljša čas varnostnega kopiranja in, kar je še bolj kritično, čas obnovitve.
V rešitvi podjetja se varnostna kopija namestitve izvede z določenim številom vozlišč v namenski gruči. Hkrati lahko na primer Commvault deluje samo z gručo z dvema vozliščema, v kateri sta Primary in Secondary strogo dodeljena določenim vozliščem. In smiselno je varnostno kopirati samo iz primarnega, ker ima varnostno kopiranje iz sekundarnega svoje omejitve. Zaradi posebnosti DBMS se na sekundarnem ne ustvari izpis, zato ostane le možnost varnostne kopije datoteke.
Za zmanjšanje tveganja izpadov se pri ustvarjanju sistema, odpornega na napake, ustvari "živa" konfiguracija gruče, primarni pa se lahko postopoma seli med različnimi strežniki. Programska oprema Patroni na primer sama zažene Primary na naključno izbranem vozlišču gruče. IBS temu ne more takoj slediti in če se konfiguracija spremeni, se procesi prekinejo. To pomeni, da uvedba zunanjega nadzora onemogoča učinkovito delovanje ISR, ker nadzorni strežnik preprosto ne razume, od kod in iz katerih podatkov je treba kopirati.
Druga težava je implementacija varnostnega kopiranja v Postgres. Možno je prek dumpa in deluje na majhnih bazah podatkov. Toda v velikih bazah podatkov izpis traja dolgo, zahteva veliko virov in lahko privede do okvare primerka baze podatkov.
Varnostno kopiranje datotek popravi situacijo, vendar je v velikih bazah podatkov počasno, ker deluje v enonitnem načinu. Poleg tega imajo prodajalci številne dodatne omejitve. Ali ne morete hkrati uporabljati varnostnih kopij datoteke in izpisa ali pa odstranjevanje podvojitev ni podprto. Težav je veliko in najpogosteje je namesto Postgresa lažje izbrati drago, a preverjeno DBMS.
Ni se kam umakniti! Moskva razvijalci so za!
Pred kratkim pa se je naša ekipa soočila s težkim izzivom: v projektu izdelave AIS OSAGO 2.0, kjer smo ustvarili IT infrastrukturo, so razvijalci za nov sistem izbrali PostgreSQL.
Velikim razvijalcem programske opreme je veliko lažje uporabljati »trendi« odprtokodne rešitve. Facebook ima dovolj strokovnjakov za podporo delovanja tega DBMS. In v primeru RSA so vse naloge "drugega dne" padle na naša ramena. Zagotoviti smo morali toleranco napak, sestaviti gručo in seveda vzpostaviti varnostno kopiranje. Logika delovanja je bila naslednja:
- Naučite SRK, da naredi varnostne kopije iz primarnega vozlišča gruče. Da bi to naredil, ga mora najti SRK - kar pomeni, da je potrebna integracija z eno ali drugo rešitvijo za upravljanje gruč PostgreSQL. V primeru RSA je bila za to uporabljena programska oprema Patroni.
- Odločite se za vrsto varnostne kopije glede na količino podatkov in zahteve po obnovitvi. Na primer, ko morate zrnato obnoviti strani, uporabite izpis, in če so baze podatkov velike in zrnata obnova ni potrebna, delajte na ravni datoteke.
- Rešitvi priložite možnost blokovnega varnostnega kopiranja, da ustvarite varnostno kopijo v večnitnem načinu.
Hkrati smo se prvotno odločili ustvariti učinkovit in preprost sistem brez pošastnega snopa dodatnih komponent. Manj kot je bergel, manjša je delovna obremenitev osebja in manjše je tveganje za odpoved IBS. Takoj smo izločili pristope, ki so uporabljali Veeam in RMAN, saj že nabor dveh rešitev namiguje na nezanesljivost sistema.
Malo čarovnije za podjetja
Zato smo morali zagotoviti zanesljivo varnostno kopiranje za 10 gruč s po 3 vozlišči, z isto infrastrukturo, ki se zrcali v rezervnem podatkovnem centru. Podatkovni centri v smislu PostgreSQL delujejo po principu aktivno-pasivno. Skupna velikost baze podatkov je bila 50 TB. Vsak nadzorni sistem na ravni podjetja se zlahka spopade s tem. Toda opozorilo je, da Postgres na začetku nima pojma o popolni in globoki združljivosti s sistemi za varnostno kopiranje. Zato smo morali poiskati rešitev, ki je imela na začetku maksimalno funkcionalnost v povezavi s PostgreSQL in sistem dodelati.
Izvedli smo 3 interne “hackathone” - ogledali smo si več kot petdeset razvoja, jih testirali, spreminjali v povezavi z našimi hipotezami in jih ponovno testirali. Po pregledu razpoložljivih možnosti smo izbrali Commvault. Ta izdelek je lahko takoj deloval z najpreprostejšo namestitvijo gruče PostgreSQL, njegova odprta arhitektura pa je vzbujala upanje (ki je bilo upravičeno) za uspešen razvoj in integracijo. Commvault lahko tudi varnostno kopira dnevnike PostgreSQL. Na primer, Veritas NetBackup v smislu PostgreSQL lahko naredi samo popolne varnostne kopije.
Več o arhitekturi. Strežniki za upravljanje Commvault so bili nameščeni v vsakem od dveh podatkovnih centrov v konfiguraciji CommServ HA. Sistem je zrcaljen, upravljan preko ene konzole in z vidika HA izpolnjuje vse zahteve podjetja.
Zagnali smo tudi dva fizična medijska strežnika v vsakem podatkovnem centru, na katera smo povezali diskovna polja in tračne knjižnice, namenjene posebej za varnostno kopiranje prek SAN prek Fibre Channel. Razširjene baze podatkov za deduplikacijo so zagotovile odpornost na napake medijskih strežnikov, povezava vsakega strežnika z vsakim CSV pa je omogočila neprekinjeno delovanje, če katera koli komponenta odpove. Sistemska arhitektura omogoča nadaljevanje varnostnega kopiranja, tudi če eden od podatkovnih centrov pade.
Patroni definira primarno vozlišče za vsako gručo. Lahko je katero koli prosto vozlišče v podatkovnem centru – vendar le večinoma. V varnostni kopiji so vsa vozlišča sekundarna.
Da bi Commvault razumel, katero vozlišče gruče je primarno, smo sistem integrirali (zahvaljujoč odprti arhitekturi rešitve) s Postgresom. V ta namen je bil ustvarjen skript, ki strežniku za upravljanje Commvault poroča o trenutni lokaciji primarnega vozlišča.
Na splošno je postopek videti takole:
Patroni izbere Primarni → Keepalived prevzame gručo IP in zažene skript → agent Commvault na izbranem vozlišču gruče prejme obvestilo, da je to primarno → Commvault samodejno znova konfigurira varnostno kopijo znotraj psevdo odjemalca.
Prednost tega pristopa je, da rešitev ne vpliva na doslednost, pravilnost dnevnikov ali obnovitev primerka Postgres. Prav tako je enostavno razširljiv, ker ni več treba popravljati primarnih in sekundarnih vozlišč Commvault. Dovolj je, da sistem razume, kje je primarno, in število vozlišč se lahko poveča na skoraj vsako vrednost.
Rešitev se ne pretvarja, da je idealna in ima svoje nianse. Commvault lahko varnostno kopira samo celotno instanco in ne posameznih baz podatkov. Zato je bil za vsako zbirko podatkov ustvarjen ločen primerek. Realne stranke so združene v virtualne psevdo stranke. Vsak psevdo odjemalec Commvault je gruča UNIX. Dodana so tista vozlišča gruče, na katerih je nameščen agent Commvault za Postgres. Posledično so vsa navidezna vozlišča psevdoodjemalca varnostno kopirana kot en primerek.
Znotraj vsakega psevdo odjemalca je navedeno aktivno vozlišče gruče. To definira naša integracijska rešitev za Commvault. Načelo njegovega delovanja je precej preprosto: če se na vozlišču dvigne IP gruče, skript nastavi parameter »aktivno vozlišče« v binarnem zapisu agenta Commvault - pravzaprav skript nastavi »1« v zahtevanem delu pomnilnika . Agent posreduje te podatke v CommServe, Commvault pa naredi varnostno kopijo iz želenega vozlišča. Poleg tega se pravilnost konfiguracije preveri na ravni skripta, kar pomaga preprečiti napake pri zagonu varnostnega kopiranja.
Hkrati se velike baze podatkov varnostno kopirajo v blokih v več nitih, kar izpolnjuje zahteve RPO in okna varnostnega kopiranja. Obremenitev sistema je nepomembna: popolne kopije se ne pojavljajo tako pogosto, druge dni se zbirajo samo dnevniki in v obdobjih nizke obremenitve.
Mimogrede, uporabili smo ločena pravila za varnostno kopiranje arhivskih dnevnikov PostgreSQL - shranjeni so po različnih pravilih, kopirani po drugačnem urniku in deduplikacija zanje ni omogočena, saj ti dnevniki vsebujejo edinstvene podatke.
Da bi zagotovili doslednost v celotni infrastrukturi IT, so ločeni datotečni odjemalci Commvault nameščeni na vsako od vozlišč gruče. Datoteke Postgres izključujejo iz varnostnih kopij in so namenjene samo varnostnim kopijam OS in aplikacij. Tudi ta del podatkov ima svojo politiko in obdobje hrambe.
Trenutno IBS ne vpliva na storitve produktivnosti, če pa se situacija spremeni, lahko Commvault omogoči omejitev obremenitve.
Je dober? Dobro!
Tako smo prejeli ne le delujočo, ampak tudi popolnoma avtomatizirano varnostno kopijo za namestitev gruče PostgreSQL, ki izpolnjuje vse zahteve za poslovne klice.
Parametra RPO in RTO 1 ura in 2 uri sta pokrita z rezervo, kar pomeni, da ju bo sistem upošteval tudi ob občutnem povečanju količine shranjenih podatkov. V nasprotju s številnimi dvomi se je izkazalo, da sta PostgreSQL in poslovno okolje precej združljiva. In zdaj iz lastnih izkušenj vemo, da je varnostno kopiranje za takšne DBMS mogoče v najrazličnejših konfiguracijah.
Seveda smo morali na tej poti obuti sedem parov železnih škornjev, premagati vrsto težav, stopiti na več grabelj in popraviti vrsto napak. Zdaj pa je pristop že preizkušen in ga je mogoče uporabiti za implementacijo odprtokodnega namesto lastniškega DBMS v težkih poslovnih pogojih.
Ste poskusili delati s PostgreSQL v poslovnem okolju?
Avtorji:
Oleg Lavrenov, oblikovalec sistemov za shranjevanje podatkov, Jet Infosystems
Dmitry Erykin, oblikovalec računalniških sistemov pri Jet Infosystems
Vir: www.habr.com