Mange er kjent med PostgreSQL DBMS, og det har vist seg i små installasjoner. Trenden mot åpen kildekode har imidlertid blitt stadig tydeligere, selv når det gjelder store selskaper og bedriftskrav. I denne artikkelen vil vi fortelle deg hvordan du integrerer Postgres i et bedriftsmiljø og dele vår erfaring med å lage et backupsystem (BSS) for denne databasen ved å bruke Commvault backup-systemet som eksempel.
PostgreSQL har allerede bevist sin verdi - DBMS fungerer utmerket, det brukes av fasjonable digitale virksomheter som Alibaba og TripAdvisor, og mangelen på lisensavgifter gjør det til et fristende alternativ til slike monstre som MS SQL eller Oracle DB. Men så snart vi begynner å tenke på PostgreSQL i Enterprise-landskapet, møter vi umiddelbart strenge krav: «Hva med konfigurasjonsfeiltoleranse? katastrofemotstand? hvor er den omfattende overvåkingen? Hva med automatisk sikkerhetskopiering? Hva med å bruke båndbiblioteker både direkte og på sekundærlagring?»
På den ene siden har ikke PostgreSQL innebygde sikkerhetskopieringsverktøy, som "voksne" DBMS-er som RMAN i Oracle DB eller SAP Database Backup. På den annen side, leverandører av bedriftssikkerhetskopieringssystemer (Veeam, Veritas, Commvault) selv om de støtter PostgreSQL, fungerer de faktisk bare med en viss (vanligvis frittstående) konfigurasjon og med et sett av forskjellige begrensninger.
Sikkerhetskopieringssystemer spesialdesignet for PostgreSQL, som Barman, Wal-g, pg_probackup, er ekstremt populære i små installasjoner av PostgreSQL DBMS eller hvor tunge sikkerhetskopier av andre elementer i IT-landskapet ikke er nødvendig. For eksempel, i tillegg til PostgreSQL, kan infrastrukturen inkludere fysiske og virtuelle servere, OpenShift, Oracle, MariaDB, Cassandra, etc. Det anbefales å sikkerhetskopiere alt dette med et felles verktøy. Å installere en separat løsning eksklusivt for PostgreSQL er en dårlig idé: dataene vil bli kopiert et sted til disken, og deretter må de fjernes til tape. Denne doble sikkerhetskopien øker sikkerhetskopieringstiden, og også, mer kritisk, gjenopprettingstiden.
I en bedriftsløsning skjer sikkerhetskopiering av installasjonen med et visst antall noder i en dedikert klynge. Samtidig kan for eksempel Commvault bare fungere med en to-node-klynge, der primær og sekundær er strengt tilordnet visse noder. Og det gir bare mening å sikkerhetskopiere fra primær, fordi sikkerhetskopiering fra sekundær har sine begrensninger. På grunn av særegenhetene til DBMS opprettes ikke en dump på Secondary, og derfor gjenstår bare muligheten for en sikkerhetskopi av filer.
For å redusere risikoen for nedetid, når du oppretter et feiltolerant system, opprettes en "live" klyngekonfigurasjon, og Primary kan gradvis migrere mellom forskjellige servere. For eksempel starter Patroni-programvaren selv Primær på en tilfeldig valgt klyngennode. IBS har ingen måte å spore dette ut av esken, og hvis konfigurasjonen endres, bryter prosessene. Det vil si at innføringen av ekstern kontroll hindrer ISR fra å fungere effektivt, fordi kontrollserveren rett og slett ikke forstår hvor og hvilke data som skal kopieres fra.
Et annet problem er implementeringen av backup i Postgres. Det er mulig gjennom dump, og det fungerer på små databaser. Men i store databaser tar dumpingen lang tid, krever mye ressurser og kan føre til svikt i databaseforekomsten.
Sikkerhetskopiering av filer retter opp situasjonen, men på store databaser går det tregt fordi det fungerer i entrådsmodus. I tillegg har leverandørene en rekke tilleggsbegrensninger. Enten kan du ikke bruke fil- og dump-sikkerhetskopier samtidig, eller deduplisering støttes ikke. Det er mange problemer, og som oftest er det lettere å velge et dyrt, men velprøvd DBMS i stedet for Postgres.
Det er ingen steder å trekke seg tilbake! Moskva-utviklere ligger bak!
Imidlertid sto teamet vårt nylig overfor en vanskelig utfordring: i prosjektet for å lage AIS OSAGO 2.0, hvor vi opprettet IT-infrastrukturen, valgte utviklerne PostgreSQL for det nye systemet.
Det er mye enklere for store programvareutviklere å bruke "trendy" åpen kildekode-løsninger. Facebook har nok spesialister til å støtte driften av dette DBMS. Og når det gjelder RSA, falt alle oppgavene på "den andre dagen" på skuldrene våre. Vi ble pålagt å sikre feiltoleranse, sette sammen en klynge og selvfølgelig sette opp backup. Handlingslogikken var som følger:
- Lær SRK å lage sikkerhetskopier fra den primære noden til klyngen. For å gjøre dette må SRK finne det - noe som betyr at det er nødvendig med integrasjon med en eller annen PostgreSQL klyngeadministrasjonsløsning. Når det gjelder RSA, ble Patroni-programvare brukt til dette.
- Bestem deg for typen sikkerhetskopiering basert på datavolumet og krav til gjenoppretting. For eksempel, når du trenger å gjenopprette sider granulert, bruk en dump, og hvis databasene er store og granulær restaurering ikke er nødvendig, arbeid på filnivå.
- Legg ved mulighet for blokkering av sikkerhetskopiering til løsningen for å lage en sikkerhetskopi i flertrådsmodus.
Samtidig satte vi oss i utgangspunktet for å lage et effektivt og enkelt system uten en monstrøs sele av tilleggskomponenter. Jo færre krykker, jo mindre arbeidsbelastning på personalet og jo lavere er risikoen for IBS-svikt. Vi ekskluderte umiddelbart tilnærminger som brukte Veeam og RMAN, fordi et sett med to løsninger allerede antyder systemets upålitelighet.
Litt magi for bedriften
Så vi trengte å garantere pålitelig sikkerhetskopiering for 10 klynger med 3 noder hver, med samme infrastruktur speilet i backupdatasenteret. Datasentre i form av PostgreSQL arbeider etter det aktive-passive prinsippet. Den totale databasestørrelsen var 50 TB. Ethvert kontrollsystem på bedriftsnivå kan enkelt takle dette. Men forbeholdet er at Postgres i utgangspunktet ikke har en anelse om full og dyp kompatibilitet med backup-systemer. Derfor måtte vi se etter en løsning som i utgangspunktet hadde maksimal funksjonalitet i forbindelse med PostgreSQL, og avgrense systemet.
Vi holdt 3 interne "hackathons" - vi så på mer enn femti utviklinger, testet dem, gjorde endringer i forbindelse med hypotesene våre og testet dem på nytt. Etter å ha gjennomgått de tilgjengelige alternativene, valgte vi Commvault. Ut av esken kunne dette produktet fungere med den enkleste PostgreSQL-klyngeinstallasjonen, og dens åpne arkitektur vakte forhåpninger (som var berettiget) om vellykket utvikling og integrasjon. Commvault kan også sikkerhetskopiere PostgreSQL-logger. For eksempel kan Veritas NetBackup når det gjelder PostgreSQL bare ta fullstendige sikkerhetskopier.
Mer om arkitektur. Commvault-administrasjonsservere ble installert i hvert av de to datasentrene i en CommServ HA-konfigurasjon. Systemet er speilvendt, administrert gjennom én konsoll og oppfyller fra HA-synspunkt alle bedriftskrav.
Vi lanserte også to fysiske medieservere i hvert datasenter, som vi koblet til diskarrayer og båndbiblioteker dedikert spesifikt for sikkerhetskopiering via SAN via Fibre Channel. Utvidede dedupliseringsdatabaser sikret feiltoleranse for medieservere, og tilkobling av hver server til hver CSV muliggjorde kontinuerlig drift hvis noen komponent sviktet. Systemarkitekturen gjør at sikkerhetskopieringen kan fortsette selv om et av datasentrene faller.
Patroni definerer en primærnode for hver klynge. Det kan være hvilken som helst ledig node i datasenteret – men bare det meste. I sikkerhetskopien er alle noder sekundære.
For at Commvault skal forstå hvilken klyngennode som er Primær, integrerte vi systemet (takket være den åpne arkitekturen til løsningen) med Postgres. For dette formålet ble det opprettet et skript som rapporterer gjeldende plassering av primærnoden til Commvault-administrasjonsserveren.
Generelt ser prosessen slik ut:
Patroni velger Primær → Keepalved henter IP-klyngen og kjører skriptet → Commvault-agenten på den valgte klyngenoden mottar en melding om at dette er den primære → Commvault rekonfigurerer automatisk sikkerhetskopien i pseudo-klienten.
Fordelen med denne tilnærmingen er at løsningen ikke påvirker konsistensen, riktigheten av logger eller gjenoppretting av Postgres-forekomsten. Den er også lett skalerbar, fordi det ikke lenger er nødvendig å fikse Commvault Primære og Sekundære noder. Det er nok at systemet forstår hvor Primær er, og antallet noder kan økes til nesten hvilken som helst verdi.
Løsningen later ikke til å være ideell og har sine egne nyanser. Commvault kan bare sikkerhetskopiere hele forekomsten, og ikke individuelle databaser. Derfor ble det opprettet en egen instans for hver database. Ekte klienter kombineres til virtuelle pseudo-klienter. Hver Commvault pseudo-klient er en UNIX-klynge. De klyngenodene som Commvault-agenten for Postgres er installert på legges til. Som et resultat blir alle virtuelle noder til pseudo-klienten sikkerhetskopiert som én forekomst.
Innenfor hver pseudo-klient er den aktive noden til klyngen indikert. Dette er hva vår integrasjonsløsning for Commvault definerer. Prinsippet for driften er ganske enkelt: hvis en klynge-IP er hevet på en node, setter skriptet parameteren "aktiv node" i Commvault-agent-binæren - faktisk setter skriptet "1" i den nødvendige delen av minnet . Agenten overfører disse dataene til CommServe, og Commvault tar en sikkerhetskopi fra ønsket node. I tillegg kontrolleres konfigurasjonens korrekthet på skriptnivå, noe som bidrar til å unngå feil når du starter en sikkerhetskopi.
Samtidig sikkerhetskopieres store databaser i blokker på tvers av flere tråder, og oppfyller kravene til RPO og sikkerhetskopiering. Belastningen på systemet er ubetydelig: Fulle kopier forekommer ikke så ofte, andre dager samles det kun tømmerstokker, og i perioder med lav belastning.
Forresten, vi har brukt separate retningslinjer for sikkerhetskopiering av PostgreSQL-arkivlogger - de lagres i henhold til forskjellige regler, kopieres i henhold til en annen tidsplan, og deduplisering er ikke aktivert for dem, siden disse loggene inneholder unike data.
For å sikre konsistens på tvers av hele IT-infrastrukturen, er separate Commvault-filklienter installert på hver av klyngenodene. De ekskluderer Postgres-filer fra sikkerhetskopier og er kun ment for OS- og applikasjonssikkerhetskopier. Denne delen av dataene har også sin egen policy og lagringsperiode.
Foreløpig påvirker ikke IBS produktivitetstjenester, men hvis situasjonen endrer seg, kan Commvault aktivere belastningsbegrensning.
Er det bra? Flink!
Så vi har mottatt ikke bare en brukbar, men også en helautomatisert sikkerhetskopi for en PostgreSQL-klyngeinstallasjon, og den oppfyller alle kravene til bedriftsanrop.
RPO- og RTO-parametrene på 1 time og 2 timer er dekket med en margin, noe som betyr at systemet vil overholde dem selv med en betydelig økning i volumet av lagrede data. I motsetning til mange tvil, viste PostgreSQL og bedriftsmiljøet seg å være ganske kompatible. Og nå vet vi fra egen erfaring at sikkerhetskopiering for slike DBMS-er er mulig i en lang rekke konfigurasjoner.
Selvfølgelig, langs denne stien måtte vi slite ut syv par jernstøvler, overvinne en rekke vanskeligheter, tråkke på flere raker og rette en rekke feil. Men nå er tilnærmingen allerede testet og kan brukes til å implementere åpen kildekode i stedet for proprietær DBMS under tøffe bedriftsforhold.
Har du prøvd å jobbe med PostgreSQL i et bedriftsmiljø?
Forfattere:
Oleg Lavrenov, designingeniør for datalagringssystemer, Jet Infosystems
Dmitry Erykin, designingeniør for datasystemer hos Jet Infosystems
Kilde: www.habr.com