Sokan ismerik a PostgreSQL adatbázis-kezelőt, amely jól teljesít a kisebb telepítéseken. Azonban a nyílt forráskódú megoldásokra való átállás egyre nyilvánvalóbbá vált, még a nagy cégek és az enterprise követelmények esetén is. Ebben a cikkben bemutatjuk, hogyan lehet beépíteni a Postgres-t a vállalati környezetbe, és megosztjuk tapasztalatainkat a Commvault mentési rendszer példáján keresztül egy adatbázis mentési rendszerének létrehozásáról.
A PostgreSQL már bizonyította életképességét – az adatbázis-kezelő remekül működik, divatos digitális vállalkozások, mint az Alibaba és a TripAdvisor használják, míg a licencdíjak hiánya vonzó alternatívát kínál olyan óriásokkal, mint az MS SQL vagy az Oracle DB. De amint elkezdjük mérlegelni a PostgreSQL-t az Enterprise tájában, rögtön szembesülünk a szigorú követelményekkel: "De mi van a konfiguráció megbízhatóságával? Mi a helyzet a katasztrófák ellenállásával? Hol van a széleskörű monitorozás? Automatikus mentés? Hogyan használhatóak a szalagtárak közvetlenül és mint másodlagos tároló?"
Egyrészt a PostgreSQL nem rendelkezik beépített mentési eszközökkel, mint például az Oracle DB RMAN vagy a SAP Database Backup. Másrészt a vállalati mentési rendszerek szolgáltatói (Veeam, Veritas, Commvault) ugyan támogják a PostgreSQL-t, de valójában csak egy adott (általában önálló) konfigurációval működnek, különféle korlátozások mellett.
Az olyan PostgreSQL-ra külön fejlesztett mentési rendszerek, mint a Barman, Wal-g, pg_probackup, rendkívül népszerűek a kisebb PostgreSQL telepítéseknél, vagy ahol nem szükségesek egyéb IT táj elemeinek nehéz mentései. Például a PostgreSQL mellett az infrastruktúrában lehetnek fizikai és virtuális szerverek, OpenShift, Oracle, MariaDB, Cassandra stb. Mindezeket célszerű egy közös eszközzel menteni. Külön megoldást alkalmazni kizárólag a PostgreSQL-hez – rossz ötlet: az adatok valahova a lemezre fognak másolódni, majd azokat szalagra kell tenni. Az ilyen kettős mentés megnöveli a mentés időtartamát, és ami még kritikusabb, – a helyreállítási időt is.
Az enterprise megoldásban a telepítés biztonsági másolatai a dedikált klaszter egyes csomópontjain történnek. Például a Commvault csak egy kétcsomópontos klaszteren tud működni, ahol a Primary és a Secondary szigorúan hozzárendelésre kerül egy adott csomóponthoz. A biztonsági másolat készítése csak a Primary esetében van értelme, mert a Secondary biztonsági másolatának készítése korlátozásokkal jár. A DBMS sajátosságai miatt a Secondary-n nem készül dump, így csak a fájlbiztonsági másolat lehetőség marad.
A leállás kockázatának csökkentése érdekében a hibátlan rendszer létrehozásakor egy "élő" klaszterkonfiguráció alakul ki, és a Primary fokozatosan migrálhat különböző szerverek között. Például a Patroni szoftver automatikusan elindítja a Primary-t a klaszter véletlenszerűen kiválasztott csomópontján. A cluster management rendszer (CMS) nem képes ezt "do the box" nyomon követni, és ha a konfiguráció megváltozik, a folyamatok megszakadnak. Ezért a külső menedzsment bevezetése megnehezíti a CMS hatékony működését, mivel a vezérlő szerver egyszerűen nem érti, honnan és milyen adatokat kell másolni.
Egy másik probléma a Postgres biztonsági másolatának megvalósítása. Ez dump segítségével lehetséges, és kis adatbázisokban ez működik. De nagyobb adatbázisokban a dump késlekedik, sok erőforrást igényel, és a DB instanciájának leállásához vezethet.
A fájlbiztonsági másolat javítja a helyzetet, de nagy adatbázisoknál lassan halad, mert egyszálú módban működik. Ezen kívül a szállítóknak számos további korlátozással kell szembenézniük. Néha nem lehet egyszerre fájlbiztonsági másolatot és dump biztonsági másolatot készíteni, máskor pedig a deduplikálást nem támogatják. Sok probléma merül fel, és a legtöbbször egyszerűbb egy drága, de bevált DBMS-t választani a Postgres helyett.
Nincs visszalépés! Mögöttünk Moszkva a fejlesztők!
Nemrég a csapatunk nehéz kihívás elé került: az OSAGO 2.0 informatikai infrastruktúrájának létrehozásában a fejlesztők a PostgreSQL-t választották az új rendszerhez.
A nagy szoftverfejlesztők számára sokkal könnyebb használni a "divatos" open-source megoldásokat. A Facebook-nál elegendő szakember van, aki támogatja a DBMS működését. A RSA esetében azonban minden "másnapi" feladat a mi vállainkra nehezedett. Tőlünk elvárták a hibátlan működés biztosítását, a klaszter felépítését és természetesen a biztonsági másolatok beállítását. Az eljárás logikája a következő volt:
- A SRK-t meg kell tanítani arra, hogy a cluster Primary node-járól készítsen biztonsági másolatot. Ehhez a SRK-nak meg kell találni azt — vagyis szükség van integrációra egy vagy másik PostgreSQL cluster kezelési megoldással. A RSA esetében ezt a Patroni szoftverrel valósították meg.
- Meg kell határozni a biztonsági másolat típusát az adatmennyiségek és a helyreállítási követelmények alapján. Például, ha szükséges a lapok granuláris helyreállítása, dump-ot kell használni, míg ha a tárolók nagyok és granuláris helyreállításra nincs szükség — fájl szinten kell dolgozni.
- Integrálni kell a megoldáshoz a blokk alapú biztonsági másolat készítési lehetőséget, hogy több szálon készíthessünk biztonsági másolatot.
Először is az volt a célunk, hogy egy hatékony és egyszerű rendszert hozzunk létre, amely nem terheli meg felesleges összetevőkkel. Minél kevesebb a kiegészítő, annál kisebb a dolgozókra nehezedő teher, és alacsonyabb a SRK meghibásodásának kockázata. Azokat az megoldásokat, amelyek Veeam-et és RMAN-t használtak, azonnal kizártuk, mert a két megoldásból álló csomag már önmagában is a rendszer megbízhatatlanságára utal.
Egy kis varázslat az enterprise számára
Tehát biztosítani kellett a megbízható biztonsági másolat készítését 10 klaszterhez, mindegyik 3 nodával, miközben a biztonsági adatközpontban tükrözött infrastruktúra van. Az adatközpontok a PostgreSQL esetében az aktív-passzív elven működnek. Az adatbázisok összesített mérete 50 TB volt. Ezt bármilyen vállalati szintű SRK könnyedén kezelni tudta volna. De van egy csavar: a Postgres-ben kezdetben nincs meg a teljes és mély kompatibilitás a biztonsági mentési rendszerekkel. Ezért olyan megoldást kellett keresnünk, amely kezdetben maximális funkcionalitást nyújt a PostgreSQL-lel kapcsolatosan, és az akkor is kiegészítette a rendszert.
Három belső "hackatont" tartottunk — több mint egy tucat fejlesztést átnéztünk, teszteltük őket, módosításokat végeztünk a hipotéziseink alapján, majd újra ellenőriztük. Az elérhető lehetőségek elemzése után a Commvault-ot választottuk. Ez a termék már "dobozból" képes volt működni a legegyszerűbb PostgreSQL cluster telepítéssel, és nyitott architektúrája reményt (amely bevált) adott a sikeres kiegészítésre és integrációra. A Commvault emellett képes PostgreSQL naplók biztonsági másolatának készítésére is. Például a Veritas NetBackup a PostgreSQL tekintetében csak teljes biztonsági másolatot tud készíteni.
További információ az architektúráról. A Commvault irányító szervereit mindkét adatközpontban telepítettük CommServ HA konfigurációban. A rendszer tükrözött, és egy konzolon keresztül irányítják, HA szempontjából megfelel minden vállalati követelménynek.
Minden adatközpontban két fizikai média szervert indítottunk, melyek SAN-on keresztül, Fibre Channel-en csatlakoznak a biztonsági mentésekhez dedikált lemezgyűjteményekhez és szalagos könyvtárakhoz. A terjesztett deduplikációs tárolók biztosították a média szerverek hibatűrését, míg minden szerver mindegyik CSV-hez való csatlakozása lehetővé tette a folyamatos működést, még ha bármelyik komponens meghibásodik. A rendszer architektúrája lehetővé teszi a biztonsági mentés folytatását, még akkor is, ha az egyik adatközpont leáll.
A Patroni minden klaszterhez meghatározza a Primary csomópontot. Ez bármely szabad csomópont lehet az adatközpontban — de csak a főben. A tartalékban minden csomópont Secondary.
Ahhoz, hogy a Commvault megértse, melyik klaszter csomópont a Primary, integráltuk a rendszert (köszönjük a megoldás nyílt architekturáját) a Postgres-el. Ehhez egy szkriptet készítettünk, amely tájékoztat a Primary csomópont aktuális helyéről az irányító számára. szerverhez Commvault.
Összességében a folyamat így néz ki:
A Patroni választja a Primary-t → A Keepalived felállítja az IP klasztert és elindítja a szkriptet → A Commvault ügynök a kiválasztott klaszter csomópontján értesítést kap, hogy ez a Primary → A Commvault automatikusan átkonfigurálja a biztonsági mentést a téves kliensek keretein belül.
A megközelítés előnye, hogy a megoldás nem befolyásolja sem a konzisztenciát, sem a helyes naplózást, sem a Postgres példány visszaállítását. Emellett könnyen skálázható, mivel már nem szükséges a Commvault számára a Primary és Secondary csomópontok rögzítése. Elég, ha a rendszer tudja, hol van a Primary, és a csomópontok száma gyakorlatilag bármekkora értékre növelhető.
A megoldás nem tökéletes, és vannak saját árnyoldalai. A Commvault csak az egész példányt tudja biztonsági menteni, nem a különálló adatbázisokat. Ezért minden adatbázishoz külön példányt hoztunk létre. A valós ügyfelek virtuális téves kliensekbe vannak összegyűjtve. Minden Commvault téves kliens egy UNIX klasztert képvisel. Azok a csomópontok kerülnek be, ahol a Commvault ügynök a Postgres számára telepítve van. Ennek eredményeként az összes virtuális csomópont a téves kliensben egy példányként kerül biztonsági mentésre.
Minden egyes álnéven meg van határozva egy aktív klaszternód. Ezt határozza meg integrációs megoldásunk a Commvault számára. Az elve viszonylag egyszerű: ha a nódon klaszternév jelenik meg, a szkripttel beállítjuk a Commvault ágense binárisában az 'aktív nód' paramétert — gyakorlatilag a szkript '1'-et állít be a memória megfelelő részén. Az ügynök továbbítja ezeket az adatokat a CommServe-nak, és a Commvault a megfelelő csomópontból végez biztonsági másolatot. Ezen kívül a szkriptnél ellenőrizzük a konfiguráció helyességét, segítve a biztonsági mentés indításakor történő hibák elkerülését.
Eközben a nagy adatbázisok tömbösítve, több folyamatban készülnek, megfelelve az RPO és a biztonsági mentési ablak követelményeinek. A rendszerre nehezedő terhelés elhanyagolható: a teljes biztonsági másolatok nem olyan gyakoriak, a többi napon csak a naplókat gyűjtik, mégpedig az alacsony terhelés időszakaiban.
Mellesleg külön politikákat alkalmaztunk az archív PostgreSQL naplók biztonsági mentésére - ezeket más szabályok szerint tárolják, más ütemezés szerint másolják, és a deduplikálás nem kapcsolódik be, mivel ezek a naplók egyedi adatokat hordoznak.
A teljes IT-infrastruktúra konzisztenciájának biztosítása érdekében a Commvault külön fájlügyfelei minden klaszternódon telepítve vannak. Ezek 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ásolatára szolgálnak. Ezen adatrészhez is külön politika és saját megőrzési idő van előírva.
Jelenleg a SRK nem befolyásolja a produktív szolgáltatásokat, de ha a helyzet változik, a Commvault-ban bekapcsolható a terheléskorlátozó rendszer.
Jó? Jó!
Tehát nemcsak működőképes, hanem teljesen automatikus biztonsági mentést kaptunk a PostgreSQL klaszteres telepítéshez, amely megfelel az összes vállalati követelménynek.
Az 1 órás RPO és 2 órás RTO paraméterek bőségesen biztosítják, hogy a rendszer megfeleljen nekik, még a tárolt adatok jelentős növekedése esetén is. A sok kétség ellenére a PostgreSQL és a vállalati környezet viszonylag kompatibilisnek bizonyult. Most már tapasztalatainkból tudjuk, hogy a biztonsági mentés ilyen adatbázisok esetén a legkülönfélébb konfigurációkban lehetséges.
Természetesen, ezen az úton hét pár vascipőt kellett elhasználni, számos nehézséget leküzdeni, néhány hibát elkövetni és kijavítani. De most már a megközelítés bevált, és alkalmazható az Open Source bevezetésére a proprietális DBMS-ek helyett a vállalati környezetek nehéz feltételei között.
Próbáltad már a PostgreSQL-t vállalati környezetben használni?
Szerzők:
Oleg Lavrenov, az Infószisztémák Jet adattárolási rendszereinek tervezőmérnöke
Dmitry Erikin, az Infószisztémák Jet számítástechnikai komplexumainak tervezőmérnöke
Forrás: habr.com
