Sokan ismerik a PostgreSQL DBMS-t, és kis telepítéseknél bevált. A nyílt forráskód irányába mutató tendencia azonban egyre egyértelműbbé vált, még akkor is, ha nagyvállalatokról és vállalati követelményekről van szó. Ebben a cikkben elmondjuk, hogyan integrálhatja a Postgres-t egy vállalati környezetbe, és megosztjuk tapasztalatainkat a biztonsági mentési rendszer (BSS) létrehozásával kapcsolatban ehhez az adatbázishoz a Commvault biztonsági mentési rendszer példájával.
A PostgreSQL már bevált – a DBMS remekül működik, olyan divatos digitális vállalkozások használják, mint az Alibaba és a TripAdvisor, és a licencdíjak hiánya csábító alternatívává teszi az olyan szörnyek számára, mint az MS SQL vagy az Oracle DB. De amint elkezdünk gondolkodni a PostgreSQL-ről az Enterprise környezetben, azonnal szigorú követelményekbe ütközünk: „Mi a helyzet a konfigurációs hibatűréssel? katasztrófaállóság? hol van az átfogó monitorozás? Mi a helyzet az automatikus biztonsági mentésekkel? Mi a helyzet a szalagos könyvtárak közvetlen és másodlagos tárolón történő használatával?"
Egyrészt a PostgreSQL nem rendelkezik beépített biztonsági mentési eszközökkel, mint például a „felnőtt” DBMS-ek, mint például az RMAN az Oracle DB-ben vagy az SAP Database Backup. Másrészt a vállalati biztonsági mentési rendszerek beszállítói (Veeam, Veritas, Commvault) bár támogatják a PostgreSQL-t, valójában csak egy bizonyos (általában önálló) konfigurációval és különféle korlátozásokkal dolgoznak.
A kifejezetten PostgreSQL-hez tervezett biztonsági mentési rendszerek, mint például a Barman, a Wal-g, a pg_probackup, rendkívül népszerűek a PostgreSQL DBMS kis telepítéseiben, vagy ahol nincs szükség az IT-környezet egyéb elemeinek súlyos biztonsági mentésére. Például a PostgreSQL mellett az infrastruktúra tartalmazhat fizikai és virtuális szervereket, OpenShift, Oracle, MariaDB, Cassandra stb. Célszerű minderről egy közös eszközzel biztonsági másolatot készíteni. Egy külön megoldás telepítése kizárólag a PostgreSQL-hez rossz ötlet: az adatokat valahova lemezre másolják, majd szalagra kell eltávolítani. Ez a kettős biztonsági mentés megnöveli a biztonsági mentés idejét, és ami még kritikusabb, a helyreállítási időt is.
Vállalati megoldásokban a telepítés biztonsági mentése egy dedikált fürt bizonyos számú csomópontjával történik. Ugyanakkor például a Commvault csak két csomópontos fürttel tud működni, amelyben az elsődleges és a másodlagos szigorúan hozzá van rendelve bizonyos csomópontokhoz. És csak az elsődlegesről van értelme biztonsági másolatot készíteni, mivel a másodlagos biztonsági mentésnek megvannak a korlátai. A DBMS sajátosságai miatt a Secondary-n nem jön létre kiírat, így csak a fájlmentés lehetősége marad meg.
Az állásidő kockázatának csökkentése érdekében a hibatűrő rendszer létrehozásakor „élő” fürtkonfiguráció jön létre, és az Elsődleges fokozatosan migrálhat a különböző szerverek között. Például a Patroni szoftver maga indítja el az elsődleges programot egy véletlenszerűen kiválasztott fürtcsomóponton. Az IBS-nek nincs módja ennek nyomon követésére, és ha a konfiguráció megváltozik, a folyamatok megszakadnak. Vagyis a külső vezérlés bevezetése megakadályozza az ISR hatékony működését, mert a vezérlőszerver egyszerűen nem érti, honnan és milyen adatokat kell másolni.
Egy másik probléma a biztonsági mentés végrehajtása a Postgresben. Ez a dump-en keresztül lehetséges, és kis adatbázisokon működik. De nagy adatbázisokban a kiíratás hosszú időt vesz igénybe, sok erőforrást igényel, és az adatbázispéldány meghibásodásához vezethet.
A fájlmentés javítja a helyzetet, de nagy adatbázisokon lassú, mert egyszálas módban működik. Ezenkívül a szállítóknak számos további korlátozása is van. Vagy nem használhatja egyszerre a fájlokat és a biztonsági másolatokat, vagy a deduplikáció nem támogatott. Sok probléma adódik, és leggyakrabban egyszerűbb egy drága, de bevált DBMS-t választani a Postgres helyett.
Nincs hova visszavonulni! Moszkvai fejlesztők mögött!
A közelmúltban azonban csapatunk egy nehéz kihívással szembesült: az AIS OSAGO 2.0 létrehozására irányuló projektben, ahol az IT infrastruktúrát hoztuk létre, a fejlesztők a PostgreSQL-t választották az új rendszerhez.
A nagy szoftverfejlesztők számára sokkal könnyebb a „trendi” nyílt forráskódú megoldások használata. A Facebooknak elegendő szakembere van a DBMS működésének támogatásához. Az RSA esetében pedig a „második nap” minden feladata a mi vállunkra hárult. A hibatűrést, a klaszter összeállítását és természetesen a biztonsági mentést is kötelesek voltunk biztosítani. A cselekvés logikája a következő volt:
- Tanítsa meg az SRK-t, hogy biztonsági másolatot készítsen a fürt elsődleges csomópontjáról. Ehhez az SRK-nak meg kell találnia – ami azt jelenti, hogy integrálni kell egyik vagy másik PostgreSQL-fürtkezelési megoldással. Az RSA esetében a Patroni szoftvert használták erre.
- Döntse el a biztonsági mentés típusát az adatmennyiség és a helyreállítási követelmények alapján. Például, ha részletesen kell visszaállítania az oldalakat, használjon kiíratást, és ha az adatbázisok nagyok, és nincs szükség részletes visszaállításra, akkor fájlszinten dolgozzon.
- Csatlakoztassa a blokkmentés lehetőségét a megoldáshoz, hogy többszálas módban készítsen biztonsági másolatot.
Ugyanakkor kezdetben arra törekedtünk, hogy egy hatékony és egyszerű rendszert hozzunk létre további komponensek szörnyű hevederei nélkül. Minél kevesebb mankó, annál kisebb a személyzet munkaterhelése, és annál kisebb az IBS meghibásodásának kockázata. Azonnal kizártuk a Veeam-et és az RMAN-t használó megközelítéseket, mert két megoldásból álló halmaz már a rendszer megbízhatatlanságára utal.
Egy kis varázslat a vállalkozáshoz
Tehát megbízható biztonsági mentést kellett garantálnunk 10, egyenként 3 csomópontból álló fürt számára, ugyanazzal az infrastruktúrával, amely tükröződik a biztonsági mentési adatközpontban. Az adatközpontok a PostgreSQL szempontjából az aktív-passzív elven működnek. Az adatbázis teljes mérete 50 TB volt. Bármely vállalati szintű irányítási rendszer könnyen megbirkózik ezzel. A figyelmeztetés azonban az, hogy a Postgresnek kezdetben fogalma sincs a biztonsági mentési rendszerekkel való teljes és mély kompatibilitásról. Ezért olyan megoldást kellett keresnünk, amely kezdetben a PostgreSQL-lel együtt maximális funkcionalitással rendelkezik, és finomítani kellett a rendszeren.
3 belső „hackathont” tartottunk - több mint ötven fejlesztést néztünk meg, teszteltünk, módosítottunk hipotéziseinken, és ismét teszteltük. A rendelkezésre álló lehetőségek áttekintése után a Commvaultot választottuk. Ez a termék a dobozból a legegyszerűbb PostgreSQL fürttelepítéssel működhetett, és nyitott architektúrája reményeket keltett (ami jogos volt) a sikeres fejlesztéshez és integrációhoz. A Commvault biztonsági másolatot is készíthet a PostgreSQL naplókról. Például a Veritas NetBackup a PostgreSQL szempontjából csak teljes biztonsági másolatot tud készíteni.
Bővebben az építészetről. A Commvault felügyeleti kiszolgálók CommServ HA konfigurációban kerültek telepítésre mind a két adatközpontba. A rendszer tükrözött, egyetlen konzolon keresztül kezelhető, és HA szempontból minden vállalati követelménynek megfelel.
Minden adatközpontban két fizikai médiaszervert is elindítottunk, amelyekhez kifejezetten a SAN-on keresztül, Fibre Channelen keresztül történő biztonsági mentésre szánt lemeztömböket és szalagos könyvtárakat csatlakoztattunk. A kiterjesztett deduplikációs adatbázisok biztosították a médiaszerverek hibatűrését, és az egyes kiszolgálók mindegyik CSV-hez való csatlakoztatása lehetővé tette a folyamatos működést, ha valamelyik összetevő meghibásodott. A rendszer architektúrája lehetővé teszi a biztonsági mentés folytatását akkor is, ha az egyik adatközpont leesik.
A Patroni minden fürthöz meghatároz egy elsődleges csomópontot. Bármely szabad csomópont lehet az adatközpontban – de csak többnyire. A biztonsági mentésben minden csomópont másodlagos.
Annak érdekében, hogy a Commvault megértse, melyik fürtcsomópont az elsődleges, integráltuk a rendszert (a megoldás nyílt architektúrájának köszönhetően) a Postgres-szel. Ebből a célból egy parancsfájl jött létre, amely jelenti az elsődleges csomópont aktuális helyét a Commvault felügyeleti kiszolgálónak.
Általában a folyamat így néz ki:
A Patroni kiválasztja az Elsődleges → Keepalived lehetőséget, felveszi az IP-fürtöt, és lefuttatja a szkriptet → a Commvault ügynök a kiválasztott fürtcsomóponton értesítést kap, hogy ez az elsődleges → Commvault automatikusan újrakonfigurálja a biztonsági mentést az álkliensen belül.
Ennek a megközelítésnek az az előnye, hogy a megoldás nem befolyásolja a naplók konzisztenciáját, helyességét vagy a Postgres példány helyreállítását. Könnyen skálázható is, mert már nincs szükség a Commvault elsődleges és másodlagos csomópontok javítására. Elég, ha a rendszer megérti, hol van az Elsődleges, és a csomópontok száma szinte bármilyen értékre növelhető.
A megoldás nem úgy tesz, mintha ideális lenne, és megvannak a maga árnyalatai. A Commvault csak a teljes példányról tud biztonsági másolatot készíteni, az egyes adatbázisokról nem. Ezért minden adatbázishoz külön példány jött létre. A valódi ügyfeleket virtuális álkliensekké egyesítik. Minden Commvault pszeudo-kliens UNIX-fürt. A rendszer hozzáadja azokat a fürtcsomópontokat, amelyeken a Postgres Commvault ügynöke telepítve van. Ennek eredményeként a pszeudokliens összes virtuális csomópontjáról egyetlen példányként készül biztonsági mentés.
Minden pszeudo-kliensen belül megjelenik a klaszter aktív csomópontja. Ezt határozza meg a Commvault integrációs megoldásunk. Működésének elve meglehetősen egyszerű: ha egy csomóponton egy fürt IP-címet emelnek, a szkript beállítja az „aktív csomópont” paramétert a Commvault ügynök binárisban - valójában a szkript „1”-et állít be a memória kívánt részében. . Az ügynök továbbítja ezeket az adatokat a CommServe-nek, és a Commvault biztonsági másolatot készít a kívánt csomópontról. Ezenkívül a konfiguráció helyességét a szkript szintjén ellenőrzik, ami segít elkerülni a hibákat a biztonsági mentés indításakor.
Ugyanakkor a nagy adatbázisokról blokkokban, több szálon keresztül készül biztonsági mentés, amelyek megfelelnek az RPO és a biztonsági mentési ablak követelményeinek. A rendszer terhelése jelentéktelen: a teljes másolatok ritkán fordulnak elő, más napokon csak a naplókat gyűjtik, és alacsony terhelés esetén.
A PostgreSQL archívumnaplóinak biztonsági mentésére egyébként külön házirendeket alkalmaztunk - ezek más szabályok szerint kerülnek tárolásra, más ütemezés szerint másolódnak, és a deduplikáció nincs engedélyezve náluk, mivel ezek a naplók egyedi adatokat tartalmaznak.
A teljes IT-infrastruktúra konzisztenciájának biztosítása érdekében külön Commvault fájlkliensek vannak telepítve minden egyes fürtcsomópontra. Kizárják a Postgres-fájlokat a biztonsági mentésekből, és csak az operációs rendszer és az alkalmazások biztonsági másolataihoz készültek. Az adatok ezen részének saját szabályzata és tárolási ideje is van.
Jelenleg az IBS nem érinti a termelékenységi szolgáltatásokat, de ha a helyzet megváltozik, a Commvault engedélyezheti a terheléskorlátozást.
Ez jó? Jó!
Tehát nem csak egy működőképes, hanem egy teljesen automatizált biztonsági mentést is kaptunk egy PostgreSQL-fürttelepítéshez, amely megfelel a vállalati hívások minden követelményének.
Az 1 órás és 2 órás RPO és RTO paramétereket margó borítja, ami azt jelenti, hogy a rendszer a tárolt adatok mennyiségének jelentős növekedése esetén is megfelel ezeknek. Sok kétséggel ellentétben a PostgreSQL és a vállalati környezet meglehetősen kompatibilisnek bizonyult. És most már saját tapasztalatunkból tudjuk, hogy az ilyen DBMS-ek biztonsági mentése számos konfigurációban lehetséges.
Természetesen ezen az úton hét pár vascsizmát kellett elkoptatni, számos nehézséget leküzdeni, több gereblyére lépni és számos hibát kijavítani. Most azonban a megközelítést már tesztelték, és használható nyílt forráskódú DBMS-ek megvalósítására durva vállalati körülmények között.
Próbáltál már PostgreSQL-lel dolgozni vállalati környezetben?
Szerzők:
Oleg Lavrenov, a Jet Infosystems adattároló rendszerek tervezőmérnöke
Dmitry Erykin, a Jet Infosystems számítógépes rendszerek tervezőmérnöke
Forrás: will.com