Många är bekanta med PostgreSQL DBMS, och det har visat sig i små installationer. Trenden mot öppen källkod har dock blivit allt tydligare, även när det gäller stora företag och företagskrav. I den här artikeln kommer vi att berätta hur du integrerar Postgres i en företagsmiljö och delar vår erfarenhet av att skapa ett backupsystem (BSS) för denna databas med hjälp av Commvaults backup-system som exempel.
PostgreSQL har redan bevisat sitt värde - DBMS fungerar utmärkt, det används av fashionabla digitala företag som Alibaba och TripAdvisor, och avsaknaden av licensavgifter gör det till ett frestande alternativ till sådana monster som MS SQL eller Oracle DB. Men så fort vi börjar tänka på PostgreSQL i Enterprise-landskapet stöter vi genast på stränga krav: "Hur är det med konfigurationsfeltolerans? katastrofmotstånd? var är den omfattande övervakningen? Hur är det med automatiserade säkerhetskopieringar? Vad sägs om att använda bandbibliotek både direkt och på sekundär lagring?”
Å ena sidan har PostgreSQL inte inbyggda säkerhetskopieringsverktyg, som "vuxna" DBMS:er som RMAN i Oracle DB eller SAP Database Backup. Å andra sidan, leverantörer av företags backup-system (Veeam, Veritas, Commvault) även om de stöder PostgreSQL, fungerar de faktiskt bara med en viss (vanligtvis fristående) konfiguration och med en uppsättning olika restriktioner.
Säkerhetskopieringssystem speciellt designade för PostgreSQL, såsom Barman, Wal-g, pg_probackup, är extremt populära i små installationer av PostgreSQL DBMS eller där tunga säkerhetskopior av andra delar av IT-landskapet inte behövs. Till exempel, förutom PostgreSQL, kan infrastrukturen innehålla fysiska och virtuella servrar, OpenShift, Oracle, MariaDB, Cassandra, etc. Det är tillrådligt att säkerhetskopiera allt detta med ett gemensamt verktyg. Att installera en separat lösning exklusivt för PostgreSQL är en dålig idé: data kommer att kopieras någonstans till disken och sedan måste den tas bort till tejp. Denna dubbla säkerhetskopiering ökar säkerhetskopieringstiden och, mer kritiskt, återställningstiden.
I en företagslösning sker säkerhetskopiering av installationen med ett visst antal noder i ett dedikerat kluster. Samtidigt kan till exempel Commvault bara fungera med ett kluster med två noder, där primära och sekundära är strikt tilldelade vissa noder. Och det är bara vettigt att säkerhetskopiera från primär, eftersom säkerhetskopiering från sekundär har sina begränsningar. På grund av DBMS:s egenheter skapas inte en dump på Secondary, och därför återstår bara möjligheten till en filsäkerhetskopiering.
För att minska risken för driftstopp, när man skapar ett feltolerant system, skapas en "live" klusterkonfiguration, och Primary kan gradvis migrera mellan olika servrar. Till exempel startar Patroni-programvaran själv Primary på en slumpmässigt vald klusternod. IBS har inget sätt att spåra detta direkt, och om konfigurationen ändras bryter processerna. Det vill säga, införandet av extern kontroll förhindrar ISR från att fungera effektivt, eftersom kontrollservern helt enkelt inte förstår var och vilken data som behöver kopieras från.
Ett annat problem är implementeringen av backup i Postgres. Det är möjligt genom dump, och det fungerar på små databaser. Men i stora databaser tar dumpningen lång tid, kräver mycket resurser och kan leda till att databasinstansen misslyckas.
Filsäkerhetskopiering rättar till situationen, men på stora databaser går det långsamt eftersom det fungerar i entrådigt läge. Dessutom har leverantörer ett antal ytterligare begränsningar. Antingen kan du inte använda fil- och dumpsäkerhetskopior samtidigt, eller så stöds inte deduplicering. Det finns många problem, och oftast är det lättare att välja en dyr men beprövad DBMS istället för Postgres.
Det finns ingenstans att dra sig tillbaka! Moskva-utvecklare ligger bakom!
Men nyligen stod vårt team inför en svår utmaning: i projektet att skapa AIS OSAGO 2.0, där vi skapade IT-infrastrukturen, valde utvecklarna PostgreSQL för det nya systemet.
Det är mycket lättare för stora mjukvaruutvecklare att använda "trendiga" lösningar med öppen källkod. Facebook har tillräckligt med specialister för att stödja driften av detta DBMS. Och i fallet med RSA föll alla uppgifter för den "andra dagen" på våra axlar. Vi var tvungna att säkerställa feltolerans, sätta ihop ett kluster och, naturligtvis, ställa in backup. Handlingslogiken var följande:
- Lär SRK att göra säkerhetskopior från klustrets primära nod. För att göra detta måste SRK hitta det - vilket innebär att integration med en eller annan PostgreSQL-klusterhanteringslösning behövs. När det gäller RSA användes Patroni programvara för detta.
- Bestäm vilken typ av backup baserat på datavolymen och återställningskrav. Till exempel, när du behöver återställa sidor granulärt, använd en dump, och om databaserna är stora och granulär återställning inte krävs, arbeta på filnivå.
- Bifoga möjligheten att blockera säkerhetskopiering till lösningen för att skapa en säkerhetskopia i flertrådsläge.
Samtidigt satte vi oss initialt för att skapa ett effektivt och enkelt system utan en monstruös sele av ytterligare komponenter. Ju färre kryckor, desto mindre arbetsbelastning på personalen och desto lägre risk för IBS-fel. Vi uteslöt omedelbart tillvägagångssätt som använde Veeam och RMAN, eftersom en uppsättning av två lösningar redan antyder systemets opålitlighet.
Lite magi för företaget
Så vi behövde garantera tillförlitlig backup för 10 kluster med 3 noder vardera, med samma infrastruktur speglad i backupdatacentret. Datacenter i form av PostgreSQL arbetar efter aktiv-passiv princip. Den totala databasstorleken var 50 TB. Alla kontrollsystem på företagsnivå kan enkelt hantera detta. Men varningen är att Postgres initialt inte har en aning om full och djup kompatibilitet med backupsystem. Därför var vi tvungna att leta efter en lösning som initialt hade maximal funktionalitet i samband med PostgreSQL, och förfina systemet.
Vi höll 3 interna "hackathons" - vi tittade på mer än femtio utvecklingar, testade dem, gjorde ändringar i samband med våra hypoteser och testade dem igen. Efter att ha granskat de tillgängliga alternativen valde vi Commvault. Ur lådan kunde den här produkten fungera med den enklaste PostgreSQL-klusterinstallationen, och dess öppna arkitektur väckte förhoppningar (vilka var berättigade) om framgångsrik utveckling och integration. Commvault kan också säkerhetskopiera PostgreSQL-loggar. Till exempel kan Veritas NetBackup vad gäller PostgreSQL bara göra fullständiga säkerhetskopior.
Mer om arkitektur. Commvault-hanteringsservrar installerades i vart och ett av de två datacentren i en CommServ HA-konfiguration. Systemet speglas, hanteras via en konsol och uppfyller, ur HA-synpunkt, alla företagskrav.
Vi lanserade också två fysiska mediaservrar i varje datacenter, till vilka vi kopplade diskarrayer och bandbibliotek dedikerade specifikt för säkerhetskopiering via SAN via Fibre Channel. Utökade dedupliceringsdatabaser säkerställde feltolerans för mediaservrar, och anslutning av varje server till varje CSV möjliggjorde kontinuerlig drift om någon komponent misslyckades. Systemarkitekturen gör att säkerhetskopieringen kan fortsätta även om ett av datacentren faller.
Patroni definierar en primär nod för varje kluster. Det kan vara vilken ledig nod som helst i datacentret – men bara det mesta. I säkerhetskopian är alla noder sekundära.
För att Commvault ska förstå vilken klusternod som är Primär integrerade vi systemet (tack vare lösningens öppna arkitektur) med Postgres. För detta ändamål skapades ett skript som rapporterar den aktuella platsen för den primära noden till Commvault-hanteringsservern.
I allmänhet ser processen ut så här:
Patroni väljer Primär → Keepalved hämtar IP-klustret och kör skriptet → Commvault-agenten på den valda klusternoden får ett meddelande om att detta är den primära → Commvault konfigurerar automatiskt om säkerhetskopian inom pseudo-klienten.
Fördelen med detta tillvägagångssätt är att lösningen inte påverkar konsistensen, korrektheten hos loggarna eller återställningen av Postgres-instansen. Det är också lätt skalbart, eftersom det inte längre är nödvändigt att fixa Commvaults primära och sekundära noder. Det räcker att systemet förstår var Primary är, och antalet noder kan ökas till nästan vilket värde som helst.
Lösningen utger sig inte för att vara idealisk och har sina egna nyanser. Commvault kan bara säkerhetskopiera hela instansen och inte enskilda databaser. Därför skapades en separat instans för varje databas. Riktiga klienter kombineras till virtuella pseudo-klienter. Varje Commvault pseudo-klient är ett UNIX-kluster. De klusternoder på vilka Commvault-agenten för Postgres är installerad läggs till. Som ett resultat säkerhetskopieras alla virtuella noder för pseudoklienten som en instans.
Inom varje pseudo-klient indikeras klustrets aktiva nod. Detta är vad vår integrationslösning för Commvault definierar. Principen för dess funktion är ganska enkel: om en kluster-IP höjs på en nod, ställer skriptet parametern "aktiv nod" i Commvault-agentens binär - i själva verket sätter skriptet "1" i den nödvändiga delen av minnet . Agenten överför dessa data till CommServe och Commvault gör en säkerhetskopia från den önskade noden. Dessutom kontrolleras konfigurationens korrekthet på skriptnivå, vilket hjälper till att undvika fel när du startar en säkerhetskopiering.
Samtidigt säkerhetskopieras stora databaser i block över flera trådar, vilket uppfyller kraven på RPO och säkerhetskopiering. Belastningen på systemet är obetydlig: Fulla kopior förekommer inte så ofta, andra dagar samlas bara stockar och under perioder med låg belastning.
Förresten, vi har tillämpat separata policyer för säkerhetskopiering av PostgreSQL-arkivloggar - de lagras enligt olika regler, kopieras enligt ett annat schema och deduplicering är inte aktiverat för dem, eftersom dessa loggar innehåller unika data.
För att säkerställa konsekvens över hela IT-infrastrukturen installeras separata Commvault-filklienter på var och en av klusternoderna. De utesluter Postgres-filer från säkerhetskopior och är endast avsedda för säkerhetskopiering av operativsystem och program. Denna del av data har också sin egen policy och lagringstid.
För närvarande påverkar inte IBS produktivitetstjänster, men om situationen förändras kan Commvault aktivera belastningsbegränsning.
Är det bra? Bra!
Så vi har inte bara fått en fungerande, utan också en helautomatisk säkerhetskopia för en PostgreSQL-klusterinstallation, och den uppfyller alla krav för företagssamtal.
RPO- och RTO-parametrarna på 1 timme och 2 timmar är täckta med en marginal, vilket innebär att systemet kommer att följa dem även med en betydande ökning av mängden lagrad data. Tvärtemot många tvivel visade sig PostgreSQL och företagsmiljön vara ganska kompatibla. Och nu vet vi av egen erfarenhet att säkerhetskopiering för sådana DBMS:er är möjlig i en mängd olika konfigurationer.
Naturligtvis, längs den här vägen var vi tvungna att slita ut sju par järnstövlar, övervinna ett antal svårigheter, trampa på flera krattor och rätta till ett antal misstag. Men nu har tillvägagångssättet redan testats och kan användas för att implementera öppen källkod istället för proprietärt DBMS under svåra företagsförhållanden.
Har du testat att arbeta med PostgreSQL i en företagsmiljö?
Författare:
Oleg Lavrenov, designingenjör av datalagringssystem, Jet Infosystems
Dmitry Erykin, designingenjör av datorsystem på Jet Infosystems
Källa: will.com