Veel mensen zijn bekend met het PostgreSQL DBMS en het heeft zichzelf bewezen in kleine installaties. De trend naar Open Source is echter steeds duidelijker geworden, zelfs als het gaat om grote bedrijven en bedrijfsvereisten. In dit artikel vertellen we u hoe u Postgres in een bedrijfsomgeving kunt integreren en delen we onze ervaringen met het maken van een back-upsysteem (BSS) voor deze database met het Commvault-back-upsysteem als voorbeeld.
PostgreSQL heeft zijn waarde al bewezen: het DBMS werkt uitstekend, het wordt gebruikt door modieuze digitale bedrijven als Alibaba en TripAdvisor, en het gebrek aan licentiekosten maakt het een verleidelijk alternatief voor monsters als MS SQL of Oracle DB. Maar zodra we in het Enterprise-landschap aan PostgreSQL gaan denken, lopen we meteen tegen strenge eisen aan: “Hoe zit het met de configuratiefouttolerantie? rampenbestendigheid? waar is de uitgebreide monitoring? Hoe zit het met geautomatiseerde back-ups? Hoe zit het met het gebruik van tapebibliotheken, zowel rechtstreeks als op secundaire opslag?”
Aan de ene kant heeft PostgreSQL geen ingebouwde back-uptools, zoals ‘volwassen’ DBMS’en zoals RMAN in Oracle DB of SAP Database Backup. Aan de andere kant werken leveranciers van bedrijfsback-upsystemen (Veeam, Veritas, Commvault), hoewel ze PostgreSQL ondersteunen, in feite alleen met een bepaalde (meestal standalone) configuratie en met een reeks verschillende beperkingen.
Back-upsystemen speciaal ontworpen voor PostgreSQL, zoals Barman, Wal-g, pg_probackup, zijn enorm populair in kleine installaties van het PostgreSQL DBMS of waar zware back-ups van andere elementen van het IT-landschap niet nodig zijn. Naast PostgreSQL kan de infrastructuur bijvoorbeeld fysieke en virtuele servers, OpenShift, Oracle, MariaDB, Cassandra, enz. omvatten. Het is raadzaam om van dit alles een back-up te maken met een gemeenschappelijk hulpmiddel. Het installeren van een aparte oplossing exclusief voor PostgreSQL is een slecht idee: de gegevens worden ergens naar schijf gekopieerd en moeten vervolgens naar tape worden verwijderd. Deze dubbele back-up verhoogt de back-uptijd en, nog belangrijker, de hersteltijd.
In een bedrijfsoplossing vindt de back-up van de installatie plaats met een bepaald aantal knooppunten in een speciaal cluster. Tegelijkertijd kan Commvault bijvoorbeeld alleen werken met een cluster met twee knooppunten, waarbij Primary en Secondary strikt aan bepaalde knooppunten zijn toegewezen. En het heeft alleen maar zin om een back-up te maken van het primaire systeem, omdat het maken van een back-up van het secundaire systeem zijn beperkingen heeft. Vanwege de eigenaardigheden van het DBMS wordt er geen dump gemaakt op Secondary en blijft daarom alleen de mogelijkheid van een bestandsback-up over.
Om het risico op downtime te verminderen, wordt bij het creëren van een fouttolerant systeem een “live” clusterconfiguratie gecreëerd, en Primary kan geleidelijk migreren tussen verschillende servers. Patroni-software start bijvoorbeeld zelf Primary op een willekeurig geselecteerd clusterknooppunt. De IBS kan dit niet out-of-the-box volgen, en als de configuratie verandert, breken de processen. Dat wil zeggen dat de introductie van externe controle verhindert dat de ISR effectief werkt, omdat de controleserver eenvoudigweg niet begrijpt waar en welke gegevens moeten worden gekopieerd.
Een ander probleem is de implementatie van back-up in Postgres. Het is mogelijk via dump en het werkt op kleine databases. Maar in grote databases duurt de dump lang, vereist veel bronnen en kan leiden tot het mislukken van de database-instantie.
Bestandsback-up corrigeert de situatie, maar op grote databases is het traag omdat het in single-threaded-modus werkt. Bovendien hebben leveranciers een aantal aanvullende beperkingen. Ofwel kunt u niet tegelijkertijd back-ups van bestanden en dumps gebruiken, ofwel wordt deduplicatie niet ondersteund. Er zijn veel problemen, en meestal is het gemakkelijker om een duur maar beproefd DBMS te kiezen in plaats van Postgres.
Er is geen plek om je terug te trekken! Moskou-ontwikkelaars staan achter!
Onlangs stond ons team echter voor een moeilijke uitdaging: in het project om AIS OSAGO 2.0 te creëren, waarbij we de IT-infrastructuur creëerden, kozen de ontwikkelaars voor PostgreSQL voor het nieuwe systeem.
Voor grote softwareontwikkelaars is het veel gemakkelijker om ‘trendy’ open source-oplossingen te gebruiken. Facebook beschikt over voldoende specialisten om de werking van dit DBMS te ondersteunen. En in het geval van RSA vielen alle taken van de “tweede dag” op onze schouders. We moesten zorgen voor fouttolerantie, een cluster samenstellen en uiteraard een back-up opzetten. De logica van de actie was als volgt:
- Leer de SRK om back-ups te maken vanaf het primaire knooppunt van het cluster. Om dit te doen moet de SRK het vinden, wat betekent dat integratie met een of andere PostgreSQL-clusterbeheeroplossing nodig is. In het geval van RSA werd hiervoor Patroni-software gebruikt.
- Bepaal het type back-up op basis van het gegevensvolume en de herstelvereisten. Als u bijvoorbeeld pagina's gedetailleerd wilt herstellen, gebruikt u een dump, en als de databases groot zijn en gedetailleerd herstel niet nodig is, werk dan op bestandsniveau.
- Voeg de mogelijkheid van blokback-up toe aan de oplossing om een back-upkopie te maken in multi-threaded modus.
Tegelijkertijd wilden we in eerste instantie een effectief en eenvoudig systeem creëren zonder een monsterlijk geheel van extra componenten. Hoe minder krukken, hoe minder werkdruk voor het personeel en hoe kleiner de kans op falen van het IBS. We hebben benaderingen waarbij gebruik werd gemaakt van Veeam en RMAN onmiddellijk uitgesloten, omdat een set van twee oplossingen al duidt op de onbetrouwbaarheid van het systeem.
Een beetje magie voor ondernemen
We moesten dus een betrouwbare back-up garanderen voor 10 clusters van elk 3 knooppunten, met dezelfde infrastructuur gespiegeld in het back-updatacenter. Datacenters werken in termen van PostgreSQL volgens het actief-passief principe. De totale databasegrootte was 50 TB. Elk controlesysteem op bedrijfsniveau kan hier gemakkelijk mee omgaan. Maar het voorbehoud is dat Postgres aanvankelijk geen idee heeft van volledige en diepe compatibiliteit met back-upsystemen. Daarom moesten we op zoek naar een oplossing die aanvankelijk maximale functionaliteit had in combinatie met PostgreSQL, en het systeem verfijnen.
We hebben drie interne “hackathons” gehouden: we hebben ruim vijftig ontwikkelingen bekeken, getest, wijzigingen aangebracht in verband met onze hypothesen en opnieuw getest. Na het bekijken van de beschikbare opties hebben we voor Commvault gekozen. Out of the box kon dit product werken met de eenvoudigste PostgreSQL-clusterinstallatie, en de open architectuur wekte hoop (die terecht was) op een succesvolle ontwikkeling en integratie. Commvault kan ook een back-up maken van PostgreSQL-logboeken. Veritas NetBackup kan in termen van PostgreSQL bijvoorbeeld alleen volledige back-ups maken.
Meer over architectuur. In elk van de twee datacenters zijn Commvault-beheerservers geïnstalleerd in een CommServ HA-configuratie. Het systeem is gespiegeld, wordt beheerd via één console en voldoet vanuit HA-oogpunt aan alle bedrijfsvereisten.
We hebben ook twee fysieke mediaservers in elk datacenter gelanceerd, waarop we disk-arrays en tapebibliotheken hebben aangesloten die specifiek bedoeld zijn voor back-ups via SAN via Fibre Channel. Uitgebreide deduplicatiedatabases zorgden voor fouttolerantie van mediaservers, en het verbinden van elke server met elke CSV maakte een continue werking mogelijk als een onderdeel uitviel. Dankzij de systeemarchitectuur kan de back-up doorgaan, zelfs als een van de datacenters uitvalt.
Patroni definieert voor elk cluster een primair knooppunt. Het kan elk vrij knooppunt in het datacenter zijn, maar alleen meestal. In de back-up zijn alle knooppunten secundair.
Om Commvault te laten begrijpen welk clusterknooppunt primair is, hebben we het systeem (dankzij de open architectuur van de oplossing) geïntegreerd met Postgres. Hiervoor is een script gemaakt dat de huidige locatie van het primaire knooppunt rapporteert aan de Commvault-beheerserver.
Over het algemeen ziet het proces er als volgt uit:
Patroni selecteert Primair → Keepalived pakt het IP-cluster op en voert het script uit → de Commvault-agent op het geselecteerde clusterknooppunt ontvangt een melding dat dit het Primaire is → Commvault configureert automatisch de back-up binnen de pseudo-client.
Het voordeel van deze aanpak is dat de oplossing geen invloed heeft op de consistentie, correctheid van logboeken of herstel van de Postgres-instantie. Bovendien is het eenvoudig schaalbaar, omdat het niet langer nodig is om de primaire en secundaire knooppunten van Commvault te repareren. Het is voldoende dat het systeem begrijpt waar Primary zich bevindt, en het aantal knooppunten kan tot vrijwel elke waarde worden verhoogd.
De oplossing pretendeert niet ideaal te zijn en heeft zijn eigen nuances. Commvault kan alleen een back-up maken van het gehele exemplaar, en niet van individuele databases. Daarom is voor elke database een afzonderlijk exemplaar gemaakt. Echte klanten worden gecombineerd tot virtuele pseudo-clients. Elke Commvault-pseudo-client is een UNIX-cluster. De clusterknooppunten waarop de Commvault-agent voor Postgres is geïnstalleerd, worden eraan toegevoegd. Als gevolg hiervan wordt van alle virtuele knooppunten van de pseudo-client een back-up gemaakt als één exemplaar.
Binnen elke pseudo-client wordt het actieve knooppunt van het cluster aangegeven. Dit is wat onze integratieoplossing voor Commvault definieert. Het principe van de werking ervan is vrij eenvoudig: als een cluster-IP op een knooppunt wordt aangemaakt, stelt het script de parameter "actief knooppunt" in het binaire bestand van de Commvault-agent in - in feite stelt het script "1" in het vereiste deel van het geheugen in . De agent verzendt deze gegevens naar CommServe en Commvault maakt een back-up vanaf het gewenste knooppunt. Bovendien wordt de juistheid van de configuratie op scriptniveau gecontroleerd, waardoor fouten bij het starten van een back-up worden voorkomen.
Tegelijkertijd worden grote databases in blokken over meerdere threads geback-upt, zodat wordt voldaan aan de RPO- en back-upvenstervereisten. De belasting van het systeem is onbeduidend: volledige kopieën komen niet zo vaak voor, op andere dagen worden alleen logboeken verzameld en tijdens perioden van lage belasting.
We hebben trouwens afzonderlijk beleid toegepast voor het maken van back-ups van PostgreSQL-archieflogboeken - ze worden opgeslagen volgens verschillende regels, gekopieerd volgens een ander schema, en deduplicatie is niet ingeschakeld, omdat deze logs unieke gegevens bevatten.
Om consistentie binnen de gehele IT-infrastructuur te garanderen, worden op elk van de clusterknooppunten afzonderlijke Commvault-bestandsclients geïnstalleerd. Ze sluiten Postgres-bestanden uit van back-ups en zijn alleen bedoeld voor back-ups van besturingssystemen en applicaties. Ook dit deel van de gegevens kent een eigen beleid en bewaartermijn.
Momenteel heeft IBS geen invloed op de productiviteitsdiensten, maar als de situatie verandert, kan Commvault belastingbeperking inschakelen.
Is het goed? Goed!
We hebben dus niet alleen een werkbare, maar ook een volledig geautomatiseerde back-up ontvangen voor een PostgreSQL-clusterinstallatie, en deze voldoet aan alle eisen voor enterprise-gesprekken.
De RPO- en RTO-parameters van 1 uur en 2 uur worden afgedekt met een marge, wat betekent dat het systeem hieraan zal voldoen, zelfs bij een aanzienlijke toename van het volume aan opgeslagen gegevens. In tegenstelling tot veel twijfels bleken PostgreSQL en de bedrijfsomgeving behoorlijk compatibel. En nu weten we uit eigen ervaring dat back-up voor dergelijke DBMS's mogelijk is in een grote verscheidenheid aan configuraties.
Natuurlijk moesten we op dit pad zeven paar ijzeren laarzen verslijten, een aantal moeilijkheden overwinnen, op verschillende harken stappen en een aantal fouten corrigeren. Maar nu is de aanpak al getest en kan deze worden gebruikt om Open Source te implementeren in plaats van eigen DBMS onder zware ondernemingsomstandigheden.
Heb je geprobeerd met PostgreSQL te werken in een bedrijfsomgeving?
Auteurs:
Oleg Lavrenov, ontwerpingenieur van gegevensopslagsystemen, Jet Infosystems
Dmitry Erykin, ontwerpingenieur van computersystemen bij Jet Infosystems
Bron: www.habr.com