Mange mennesker kender til PostgreSQL DBMS, og det har bevist sig selv i små installationer. Tendensen mod Open Source er dog blevet mere og mere tydelig, selv når det kommer til store virksomheder og virksomhedskrav. I denne artikel vil vi fortælle dig, hvordan du integrerer Postgres i et virksomhedsmiljø og deler vores erfaring med at skabe et backup-system (BSS) til denne database ved at bruge Commvault backup-systemet som eksempel.
PostgreSQL har allerede bevist sit værd - DBMS'et fungerer godt, det bruges af fashionable digitale virksomheder som Alibaba og TripAdvisor, og manglen på licensgebyrer gør det til et fristende alternativ til sådanne monstre som MS SQL eller Oracle DB. Men så snart vi begynder at tænke på PostgreSQL i Enterprise-landskabet, løber vi straks ind i strenge krav: “Hvad med konfigurationsfejltolerance? katastrofemodstand? hvor er den omfattende overvågning? Hvad med automatisk sikkerhedskopiering? Hvad med at bruge båndbiblioteker både direkte og på sekundært lager?"
På den ene side har PostgreSQL ikke indbyggede sikkerhedskopieringsværktøjer, såsom "voksne" DBMS'er såsom RMAN i Oracle DB eller SAP Database Backup. På den anden side, leverandører af virksomhedens backup-systemer (Veeam, Veritas, Commvault), selvom de understøtter PostgreSQL, fungerer de faktisk kun med en bestemt (normalt selvstændig) konfiguration og med et sæt forskellige restriktioner.
Sikkerhedskopieringssystemer specielt designet til PostgreSQL, såsom Barman, Wal-g, pg_probackup, er ekstremt populære i små installationer af PostgreSQL DBMS, eller hvor der ikke er behov for tunge backups af andre elementer i IT-landskabet. For eksempel kan infrastrukturen ud over PostgreSQL omfatte fysiske og virtuelle servere, OpenShift, Oracle, MariaDB, Cassandra osv. Det er tilrådeligt at sikkerhedskopiere alt dette med et fælles værktøj. Det er en dårlig idé at installere en separat løsning udelukkende til PostgreSQL: dataene vil blive kopieret et sted til disken, og derefter skal de fjernes til tape. Denne dobbelte sikkerhedskopiering øger sikkerhedskopieringstiden og, mere kritisk, gendannelsestiden.
I en virksomhedsløsning sker backup af installationen med et vist antal noder i en dedikeret klynge. Samtidig kan Commvault for eksempel kun arbejde med en to-node klynge, hvor Primær og Sekundær er strengt tildelt bestemte noder. Og det giver kun mening at tage backup fra Primary, fordi backup fra Secondary har sine begrænsninger. På grund af de særlige kendetegn ved DBMS oprettes der ikke et dump på Secondary, og derfor er der kun mulighed for en fil backup.
For at reducere risikoen for nedetid, når der oprettes et fejltolerant system, oprettes en "live" klyngekonfiguration, og Primary kan gradvist migrere mellem forskellige servere. For eksempel lancerer Patroni-softwaren selv Primary på en tilfældigt valgt klynge node. IBS'en har ingen måde at spore dette ud af boksen, og hvis konfigurationen ændres, går processerne i stykker. Det vil sige, at indførelsen af ekstern kontrol forhindrer ISR i at fungere effektivt, fordi kontrolserveren simpelthen ikke forstår, hvor og hvilke data der skal kopieres fra.
Et andet problem er implementeringen af backup i Postgres. Det er muligt gennem dump, og det virker på små databaser. Men i store databaser tager dumpet lang tid, kræver mange ressourcer og kan føre til fejl i databaseinstansen.
Sikkerhedskopiering af filer retter op på situationen, men på store databaser er den langsom, fordi den fungerer i enkelttrådstilstand. Derudover har leverandører en række yderligere begrænsninger. Enten kan du ikke bruge fil- og dump-sikkerhedskopier på samme tid, eller også understøttes deduplikering ikke. Der er mange problemer, og oftest er det nemmere at vælge et dyrt men gennemprøvet DBMS i stedet for Postgres.
Der er ingen steder at trække sig tilbage! Moskva-udviklere er bagud!
Men for nylig stod vores team over for en vanskelig udfordring: I projektet med at skabe AIS OSAGO 2.0, hvor vi skabte IT-infrastrukturen, valgte udviklerne PostgreSQL til det nye system.
Det er meget nemmere for store softwareudviklere at bruge "trendy" open source-løsninger. Facebook har nok specialister til at understøtte driften af dette DBMS. Og i tilfældet med RSA faldt alle opgaver på "anden dag" på vores skuldre. Vi skulle sikre fejltolerance, samle en klynge og selvfølgelig opsætte backup. Handlingslogikken var som følger:
- Lær SRK'en at lave sikkerhedskopier fra klyngens Primære node. For at gøre dette skal SRK finde det - hvilket betyder integration med en eller anden PostgreSQL klyngehåndteringsløsning er nødvendig. I tilfælde af RSA blev der brugt Patroni-software til dette.
- Beslut dig for typen af backup baseret på mængden af data og gendannelseskrav. For eksempel, når du skal gendanne sider granulært, skal du bruge et dump, og hvis databaserne er store og granulær gendannelse ikke er påkrævet, skal du arbejde på filniveau.
- Vedhæft muligheden for blokering af backup til løsningen for at oprette en sikkerhedskopi i multi-threaded mode.
Samtidig satte vi os i første omgang for at skabe et effektivt og enkelt system uden en monstrøs sele af ekstra komponenter. Jo færre krykker, jo mindre arbejdsbyrde på personalet og jo lavere er risikoen for IBS-fejl. Vi udelukkede straks tilgange, der brugte Veeam og RMAN, fordi et sæt af to løsninger allerede antyder systemets upålidelighed.
Lidt magi for virksomheden
Så vi var nødt til at garantere pålidelig backup for 10 klynger med 3 noder hver, med den samme infrastruktur spejlet i backupdatacentret. Datacentre i form af PostgreSQL arbejder efter det aktive-passive princip. Den samlede databasestørrelse var 50 TB. Ethvert kontrolsystem på virksomhedsniveau kan nemt klare dette. Men forbeholdet er, at Postgres i første omgang ikke har en anelse om fuld og dyb kompatibilitet med backup-systemer. Derfor måtte vi lede efter en løsning, der i starten havde maksimal funktionalitet i forbindelse med PostgreSQL, og forfine systemet.
Vi afholdt 3 interne "hackathons" - vi så på mere end halvtreds udviklinger, testede dem, lavede ændringer i forbindelse med vores hypoteser og testede dem igen. Efter at have gennemgået de tilgængelige muligheder, valgte vi Commvault. Ud af boksen kunne dette produkt fungere med den enkleste PostgreSQL-klyngeinstallation, og dets åbne arkitektur rejste håb (som var berettiget) om succesfuld udvikling og integration. Commvault kan også sikkerhedskopiere PostgreSQL-logfiler. For eksempel kan Veritas NetBackup i form af PostgreSQL kun lave fuld backup.
Mere om arkitektur. Commvault-administrationsservere blev installeret i hvert af de to datacentre i en CommServ HA-konfiguration. Systemet spejles, styres gennem én konsol og opfylder fra et HA-synspunkt alle virksomhedens krav.
Vi lancerede også to fysiske medieservere i hvert datacenter, hvortil vi tilsluttede diskarrays og båndbiblioteker dedikeret specifikt til sikkerhedskopiering via SAN via Fibre Channel. Udvidede deduplikeringsdatabaser sikrede fejltolerance for medieservere, og tilslutning af hver server til hver CSV aktiverede kontinuerlig drift, hvis en komponent fejlede. Systemarkitekturen tillader backup at fortsætte, selvom et af datacentrene falder.
Patroni definerer en Primær node for hver klynge. Det kan være en hvilken som helst ledig node i datacentret – men kun det meste. I sikkerhedskopien er alle noder sekundære.
For at Commvault kan forstå, hvilken klynge node der er Primær, integrerede vi systemet (takket være løsningens åbne arkitektur) med Postgres. Til dette formål blev der oprettet et script, der rapporterer den aktuelle placering af den primære node til Commvault-administrationsserveren.
Generelt ser processen sådan ud:
Patroni vælger Primær → Keepalved henter IP-klyngen og kører scriptet → Commvault-agenten på den valgte klynge node modtager en meddelelse om, at dette er den Primære → Commvault omkonfigurerer automatisk sikkerhedskopien i pseudo-klienten.
Fordelen ved denne tilgang er, at løsningen ikke påvirker konsistensen, korrektheden af logfiler eller gendannelse af Postgres-instansen. Den er også let skalerbar, fordi det ikke længere er nødvendigt at rette Commvault Primære og Sekundære noder. Det er nok, at systemet forstår, hvor Primary er, og antallet af noder kan øges til næsten enhver værdi.
Løsningen foregiver ikke at være ideel og har sine egne nuancer. Commvault kan kun sikkerhedskopiere hele instansen og ikke individuelle databaser. Derfor blev der oprettet en separat instans for hver database. Rigtige klienter kombineres til virtuelle pseudo-klienter. Hver Commvault pseudo-klient er en UNIX-klynge. De klynge noder, hvor Commvault-agenten til Postgres er installeret, føjes til den. Som et resultat heraf sikkerhedskopieres alle virtuelle noder i pseudo-klienten som én instans.
Inden for hver pseudo-klient er klyngens aktive node angivet. Dette er, hvad vores integrationsløsning til Commvault definerer. Princippet for dets drift er ret simpelt: hvis en klynge-IP er rejst på en node, sætter scriptet parameteren "active node" i Commvault-agentens binære - faktisk sætter scriptet "1" i den nødvendige del af hukommelsen . Agenten sender disse data til CommServe, og Commvault laver en sikkerhedskopi fra den ønskede node. Derudover kontrolleres rigtigheden af konfigurationen på script-niveau, hvilket hjælper med at undgå fejl ved start af en backup.
Samtidig sikkerhedskopieres store databaser i blokke på tværs af flere tråde, der opfylder kravene til RPO og sikkerhedskopiering. Belastningen på systemet er ubetydelig: Fuld kopier forekommer ikke så ofte, andre dage indsamles kun logs, og i perioder med lav belastning.
I øvrigt har vi anvendt separate politikker for sikkerhedskopiering af PostgreSQL-arkivlogfiler - de er gemt i henhold til forskellige regler, kopieret efter en anden tidsplan, og deduplikering er ikke aktiveret for dem, da disse logfiler indeholder unikke data.
For at sikre ensartethed på tværs af hele it-infrastrukturen er separate Commvault-filklienter installeret på hver af klyngens noder. De udelukker Postgres-filer fra sikkerhedskopier og er kun beregnet til sikkerhedskopiering af OS og applikationer. Denne del af dataene har også sin egen politik og opbevaringsperiode.
I øjeblikket påvirker IBS ikke produktivitetstjenester, men hvis situationen ændrer sig, kan Commvault aktivere belastningsbegrænsning.
Er det godt? Godt!
Så vi har ikke bare modtaget en brugbar, men også en fuldautomatisk backup til en PostgreSQL-klyngeinstallation, og den opfylder alle kravene til virksomhedsopkald.
RPO- og RTO-parametrene på 1 time og 2 timer er dækket med en margin, hvilket betyder, at systemet vil overholde dem selv med en betydelig stigning i mængden af lagrede data. I modsætning til mange tvivl viste PostgreSQL og virksomhedsmiljøet sig at være ret kompatible. Og nu ved vi fra vores egen erfaring, at backup til sådanne DBMS'er er mulig i en lang række forskellige konfigurationer.
Selvfølgelig skulle vi ad denne vej slide syv par jernstøvler, overvinde en række vanskeligheder, træde på flere river og rette en række fejl. Men nu er tilgangen allerede testet og kan bruges til at implementere Open Source i stedet for proprietær DBMS under barske virksomhedsforhold.
Har du prøvet at arbejde med PostgreSQL i et virksomhedsmiljø?
Forfattere:
Oleg Lavrenov, designingeniør af datalagringssystemer, Jet Infosystems
Dmitry Erykin, designingeniør af computersystemer hos Jet Infosystems
Kilde: www.habr.com