Monet ihmiset tuntevat PostgreSQL DBMS:n, ja se on osoittautunut hyväksi pienissä asennuksissa. Suuntaus avoimeen lähdekoodiin on kuitenkin tullut yhä selvemmäksi, vaikka kyse on suurista yrityksistä ja yritysten vaatimuksista. Tässä artikkelissa kerromme sinulle, kuinka Postgres integroidaan yritysympäristöön, ja jaamme kokemuksemme varmuuskopiojärjestelmän (BSS) luomisesta tälle tietokannalle käyttämällä esimerkkinä Commvault-varmuuskopiojärjestelmää.
PostgreSQL on jo osoittanut arvonsa - DBMS toimii loistavasti, sitä käyttävät muodikkaat digitaaliset yritykset, kuten Alibaba ja TripAdvisor, ja lisenssimaksujen puute tekee siitä houkuttelevan vaihtoehdon sellaisille hirviöille kuin MS SQL tai Oracle DB. Mutta heti kun alamme ajatella PostgreSQL:ää Enterprise-ympäristössä, kohtaamme heti tiukat vaatimukset: "Entä konfiguroinnin vikasietoisuus? katastrofin kestävyys? missä on kattava seuranta? Entä automaattiset varmuuskopiot? Entä nauhakirjastojen käyttäminen sekä suoraan että toissijaisessa tallennustilassa?"
Toisaalta PostgreSQL:ssä ei ole sisäänrakennettuja varmuuskopiointityökaluja, kuten "aikuisten" tietokantajärjestelmiä, kuten RMAN Oracle DB:ssä tai SAP Database Backup. Toisaalta yritysten varmuuskopiointijärjestelmien toimittajat (Veeam, Veritas, Commvault), vaikka ne tukevat PostgreSQL:ää, itse asiassa ne toimivat vain tietyllä (yleensä itsenäisellä) kokoonpanolla ja joukolla erilaisia rajoituksia.
Erityisesti PostgreSQL:lle suunnitellut varmuuskopiointijärjestelmät, kuten Barman, Wal-g, pg_probackup, ovat erittäin suosittuja pienissä PostgreSQL DBMS:n asennuksissa tai joissa ei tarvita raskaita varmuuskopioita muista IT-ympäristön elementeistä. Esimerkiksi Infrastruktuuri voi sisältää PostgreSQL:n lisäksi fyysisiä ja virtuaalisia palvelimia, OpenShift, Oracle, MariaDB, Cassandra jne. Kaikki tämä on suositeltavaa varmuuskopioida yhteisellä työkalulla. Erillisen ratkaisun asentaminen yksinomaan PostgreSQL:lle on huono idea: tiedot kopioidaan jonnekin levylle, jonka jälkeen ne on poistettava nauhalle. Tämä kaksinkertainen varmuuskopiointi pidentää varmuuskopiointiaikaa ja myös, mikä kriittisemmin, palautusaikaa.
Yritysratkaisussa asennuksen varmuuskopiointi tapahtuu tietyllä määrällä solmuja erillisessä klusterissa. Samaan aikaan esimerkiksi Commvault voi toimia vain kahden solmun klusterin kanssa, jossa ensisijainen ja toissijainen on tiukasti määritetty tietyille solmuille. Ja on järkevää varmuuskopioida vain ensisijaisesta, koska toissijaisesta varmuuskopioinnista on rajoituksensa. DBMS:n erityispiirteistä johtuen toissijaiseen järjestelmään ei luoda vedoskirjaa, joten jäljelle jää vain mahdollisuus tiedoston varmuuskopiointiin.
Katkosten riskin vähentämiseksi vikasietojärjestelmää luotaessa luodaan "live" klusterikonfiguraatio, ja ensisijainen voi vähitellen siirtyä eri palvelimien välillä. Esimerkiksi Patroni-ohjelmisto itse käynnistää ensisijaisen satunnaisesti valitussa klusterin solmussa. IBS ei pysty jäljittämään tätä heti, ja jos kokoonpano muuttuu, prosessit katkeavat. Toisin sanoen ulkoisen ohjauksen käyttöönotto estää ISR:ää toimimasta tehokkaasti, koska ohjauspalvelin ei yksinkertaisesti ymmärrä, mistä ja mitä tietoja on kopioitava.
Toinen ongelma on varmuuskopion toteuttaminen Postgresissa. Se on mahdollista dumpin kautta, ja se toimii pienissä tietokannoissa. Mutta suurissa tietokannoista dump kestää kauan, vaatii paljon resursseja ja voi johtaa tietokannan ilmentymän epäonnistumiseen.
Tiedostojen varmuuskopiointi korjaa tilanteen, mutta suurilla tietokannoilla se on hidasta, koska se toimii yksisäikeisessä tilassa. Lisäksi myyjillä on useita lisärajoituksia. Joko et voi käyttää tiedostojen ja vedosten varmuuskopioita samanaikaisesti, tai kopioiden poistamista ei tueta. Ongelmia on monia, ja useimmiten on helpompi valita kallis mutta todistettu DBMS Postgresin sijaan.
Ei ole minne perääntyä! Moskovan kehittäjät ovat takana!
Hiljattain tiimimme kohtasi kuitenkin vaikean haasteen: AIS OSAGO 2.0:n luomisprojektissa, jossa loimme IT-infrastruktuurin, kehittäjät valitsivat PostgreSQL:n uudeksi järjestelmäksi.
Suurten ohjelmistokehittäjien on paljon helpompaa käyttää "trendikkäitä" avoimen lähdekoodin ratkaisuja. Facebookilla on tarpeeksi asiantuntijoita tukemaan tämän DBMS:n toimintaa. Ja RSA:n tapauksessa kaikki "toisen päivän" tehtävät putosivat harteillemme. Meidän piti varmistaa vikasietoisuus, koota klusteri ja tietysti varmuuskopiointi. Toiminnan logiikka oli seuraava:
- Opeta SRK tekemään varmuuskopioita klusterin ensisijaisesta solmusta. Tätä varten SRK:n on löydettävä se - mikä tarkoittaa, että tarvitaan integrointi johonkin toiseen PostgreSQL-klusterinhallintaratkaisuun. RSA:n tapauksessa tähän käytettiin Patroni-ohjelmistoa.
- Päätä varmuuskopion tyyppi tietomäärän ja palautusvaatimusten perusteella. Jos esimerkiksi haluat palauttaa sivut rakeisesti, käytä vedostiedostoa, ja jos tietokannat ovat suuria eikä rakeista palautusta tarvita, työskentele tiedostotasolla.
- Liitä ratkaisuun lohkovarmuuskopion mahdollisuus luodaksesi varmuuskopion monisäikeisessä tilassa.
Samaan aikaan pyrimme alun perin luomaan tehokkaan ja yksinkertaisen järjestelmän ilman hirviömäisiä lisäkomponentteja. Mitä vähemmän kainalosauvoja, sitä pienempi on henkilöstön työtaakka ja sitä pienempi on IBS-häiriön riski. Jätimme heti pois lähestymistavat, joissa käytettiin Veeamia ja RMAN:ia, koska kahden ratkaisun sarja vihjaa jo järjestelmän epäluotettavuuteen.
Pientä taikuutta yritykselle
Joten meidän piti taata luotettava varmuuskopiointi 10 klusterille, joissa kussakin oli 3 solmua, ja sama infrastruktuuri peilattiin varmuuskopiointikeskuksessa. Datakeskukset PostgreSQL:n kannalta toimivat aktiivi-passiiviperiaatteella. Tietokannan kokonaiskoko oli 50 TB. Mikä tahansa yritystason ohjausjärjestelmä selviytyy tästä helposti. Mutta varoitus on, että Postgresilla ei alun perin ollut aavistustakaan täydellisestä ja syvästä yhteensopivuudesta varmuuskopiointijärjestelmien kanssa. Siksi jouduimme etsimään ratkaisua, joka oli alun perin mahdollisimman toiminnallinen yhdessä PostgreSQL:n kanssa, ja jalostaa järjestelmää.
Järjestimme 3 sisäistä "hackathonia" - katselimme yli viisikymmentä kehitystä, testasimme niitä, teimme muutoksia hypoteeseihimme ja testasimme niitä uudelleen. Käytettävissä olevien vaihtoehtojen tarkastelun jälkeen valitsimme Commvaultin. Pakkauksesta käsin tämä tuote voisi toimia yksinkertaisimman PostgreSQL-klusteriasennuksen kanssa, ja sen avoin arkkitehtuuri herätti toiveita (jotka olivat perusteltuja) onnistuneesta kehityksestä ja integraatiosta. Commvault voi myös varmuuskopioida PostgreSQL-lokit. Esimerkiksi Veritas NetBackup PostgreSQL:n suhteen voi tehdä vain täydellisiä varmuuskopioita.
Lisää arkkitehtuurista. Kumpaankin tietokeskukseen asennettiin Commvault-hallintapalvelimet CommServ HA -kokoonpanossa. Järjestelmä on peilattu, sitä hallitaan yhden konsolin kautta ja HA:n näkökulmasta se täyttää kaikki yrityksen vaatimukset.
Lisäksi lanseerasimme kussakin datakeskuksessa kaksi fyysistä mediapalvelinta, joihin liitimme levyryhmät ja nauhakirjastot, jotka on tarkoitettu erityisesti varmuuskopiointiin SAN:n kautta Fibre Channelin kautta. Laajennetut deduplikointitietokannat varmistivat mediapalvelimien vikasietoisuuden, ja jokaisen palvelimen yhdistäminen kuhunkin CSV:hen mahdollisti jatkuvan toiminnan, jos jokin komponentti epäonnistui. Järjestelmäarkkitehtuuri mahdollistaa varmuuskopioinnin jatkamisen, vaikka yksi datakeskuksista kaatuu.
Patroni määrittelee ensisijaisen solmun jokaiselle klusterille. Se voi olla mikä tahansa ilmainen solmu palvelinkeskuksessa - mutta vain enimmäkseen. Varmuuskopiossa kaikki solmut ovat toissijaisia.
Jotta Commvault ymmärtäisi, mikä klusterisolmu on ensisijainen, integroimme järjestelmän (ratkaisun avoimen arkkitehtuurin ansiosta) Postgresiin. Tätä tarkoitusta varten luotiin komentosarja, joka raportoi ensisijaisen solmun nykyisen sijainnin Commvault-hallintapalvelimelle.
Yleisesti ottaen prosessi näyttää tältä:
Patroni valitsee Ensisijainen → Keepalived poimii IP-klusterin ja suorittaa komentosarjan → Commvault-agentti valitussa klusterisolmussa vastaanottaa ilmoituksen, että tämä on ensisijainen → Commvault määrittää varmuuskopion automaattisesti uudelleen näennäisasiakkaan sisällä.
Tämän lähestymistavan etuna on, että ratkaisu ei vaikuta lokien johdonmukaisuuteen, oikeellisuuteen tai Postgres-instanssin palautumiseen. Se on myös helposti skaalautuva, koska Commvaultin ensisijaista ja toissijaista solmua ei enää tarvitse korjata. Riittää, että järjestelmä ymmärtää missä Primary on, ja solmujen lukumäärää voidaan kasvattaa melkein mihin tahansa arvoon.
Ratkaisu ei väitä olevan ihanteellinen ja siinä on omat vivahteensa. Commvault voi varmuuskopioida vain koko ilmentymän, ei yksittäisiä tietokantoja. Tästä syystä jokaiselle tietokannalle luotiin erillinen esiintymä. Todelliset asiakkaat yhdistetään virtuaalisiksi pseudo-asiakkaiksi. Jokainen Commvault-pseudo-asiakas on UNIX-klusteri. Ne klusterisolmut, joihin Postgresin Commvault-agentti on asennettu, lisätään siihen. Tämän seurauksena kaikki näennäisasiakkaan virtuaaliset solmut varmuuskopioidaan yhtenä esiintymänä.
Jokaisessa pseudo-asiakkaassa on osoitettu klusterin aktiivinen solmu. Tämän määrittelee Commvaultin integraatioratkaisumme. Sen toimintaperiaate on melko yksinkertainen: jos klusterin IP nostetaan solmuun, komentosarja asettaa "aktiivinen solmu" -parametrin Commvault-agentin binaariin - itse asiassa komentosarja asettaa "1" vaadittuun muistin osaan. . Agentti lähettää nämä tiedot CommServeen, ja Commvault tekee varmuuskopion halutusta solmusta. Lisäksi konfiguroinnin oikeellisuus tarkistetaan komentosarjatasolla, mikä auttaa välttämään virheet varmuuskopiointia käynnistettäessä.
Samaan aikaan suuret tietokannat varmuuskopioidaan lohkoina useiden säikeiden kautta, mikä täyttää RPO- ja varmuuskopiointiikkunan vaatimukset. Järjestelmän kuormitus on merkityksetön: Täydellisiä kopioita ei tapahdu niin usein, muina päivinä kerätään vain lokit ja alhaisen kuormituksen aikoina.
Olemme muuten soveltaneet erillisiä käytäntöjä PostgreSQL-arkistolokien varmuuskopiointiin - ne tallennetaan eri sääntöjen mukaan, kopioidaan eri aikataulun mukaan, eikä päällekkäisyyden poistaminen ole käytössä, koska nämä lokit sisältävät ainutlaatuisia tietoja.
Koko IT-infrastruktuurin johdonmukaisuuden varmistamiseksi kuhunkin klusterin solmuun asennetaan erilliset Commvault-tiedostoasiakkaat. Ne eivät sisällä Postgres-tiedostoja varmuuskopioista, ja ne on tarkoitettu vain käyttöjärjestelmän ja sovellusten varmuuskopiointiin. Tällä tietojen osalla on myös oma käytäntönsä ja säilytysaikansa.
Tällä hetkellä IBS ei vaikuta tuottavuuspalveluihin, mutta tilanteen muuttuessa Commvault voi ottaa käyttöön kuormituksen rajoittamisen.
Onko se hyvää? Hyvä!
Olemme siis saaneet paitsi toimivan, myös täysin automatisoidun varmuuskopion PostgreSQL-klusteriasennukseen, ja se täyttää kaikki yrityskutsujen vaatimukset.
RPO- ja RTO-parametrit 1 tunti ja 2 tuntia on peitetty marginaalilla, mikä tarkoittaa, että järjestelmä noudattaa niitä, vaikka tallennetun tiedon määrä kasvaisi merkittävästi. Vastoin monia epäilyksiä PostgreSQL ja yritysympäristö osoittautuivat varsin yhteensopiviksi. Ja nyt tiedämme omasta kokemuksestamme, että tällaisten DBMS-järjestelmien varmuuskopiointi on mahdollista useissa eri kokoonpanoissa.
Tietysti tätä polkua pitkin meidän piti käyttää seitsemän paria rautakaappaat, voittaa useita vaikeuksia, astua useiden haravojen päälle ja korjata useita virheitä. Mutta nyt lähestymistapa on jo testattu, ja sitä voidaan käyttää avoimen lähdekoodin toteuttamiseen patentoidun DBMS:n sijaan ankarissa yritysolosuhteissa.
Oletko kokeillut työskennellä PostgreSQL:n kanssa yritysympäristössä?
Tekijät:
Oleg Lavrenov, tietojen tallennusjärjestelmien suunnitteluinsinööri, Jet Infosystems
Dmitry Erykin, Jet Infosystemsin tietokonejärjestelmien suunnitteluinsinööri
Lähde: will.com