Baie mense is vertroud met die PostgreSQL DBMS, en dit het homself bewys in klein installasies. Die neiging na Oopbron het egter al hoe duideliker geword, selfs wanneer dit by groot maatskappye en ondernemingsvereistes kom. In hierdie artikel sal ons jou vertel hoe om Postgres in 'n korporatiewe omgewing te integreer en ons ervaring van die skep van 'n rugsteunstelsel (BSS) vir hierdie databasis te deel deur die Commvault-rugsteunstelsel as 'n voorbeeld te gebruik.
PostgreSQL het reeds sy waarde bewys - die DBMS werk uitstekend, dit word gebruik deur modieuse digitale besighede soos Alibaba en TripAdvisor, en die gebrek aan lisensiegelde maak dit 'n aanloklike alternatief vir sulke monsters soos MS SQL of Oracle DB. Maar sodra ons aan PostgreSQL in die Enterprise-landskap begin dink, kom ons dadelik teë streng vereistes: “Wat van konfigurasiefouttoleransie? rampweerstand? waar is die omvattende monitering? Wat van outomatiese rugsteun? Wat van die gebruik van bandbiblioteke direk en op sekondêre berging?”
Aan die een kant het PostgreSQL nie ingeboude rugsteuninstrumente nie, soos "volwasse" DBMS'e soos RMAN in Oracle DB of SAP Database Backup. Aan die ander kant, verskaffers van korporatiewe rugsteunstelsels (Veeam, Veritas, Commvault), hoewel hulle PostgreSQL ondersteun, werk hulle in werklikheid net met 'n sekere (gewoonlik selfstandige) konfigurasie en met 'n stel verskeie beperkings.
Rugsteunstelsels wat spesiaal vir PostgreSQL ontwerp is, soos Barman, Wal-g, pg_probackup, is uiters gewild in klein installasies van die PostgreSQL DBMS of waar swaar rugsteun van ander elemente van die IT-landskap nie nodig is nie. Byvoorbeeld, bykomend tot PostgreSQL, kan die infrastruktuur fisiese en virtuele bedieners, OpenShift, Oracle, MariaDB, Cassandra, ens. Dit is raadsaam om dit alles met 'n algemene instrument te rugsteun. Die installering van 'n aparte oplossing eksklusief vir PostgreSQL is 'n slegte idee: die data sal iewers na skyf gekopieer word, en dan moet dit na band verwyder word. Hierdie dubbele rugsteun verhoog die rugsteuntyd, en ook, meer krities, die hersteltyd.
In 'n ondernemingsoplossing vind rugsteun van die installasie plaas met 'n sekere aantal nodusse in 'n toegewyde groepering. Terselfdertyd kan Commvault byvoorbeeld slegs met 'n twee-nodus-kluster werk, waarin Primêr en Sekondêr streng aan sekere nodusse toegewys is. En dit maak net sin om van Primêr te rugsteun, want rugsteun van Sekondêr het sy beperkings. As gevolg van die eienaardighede van die DBBS word 'n storting nie op Sekondêr geskep nie, en daarom bly slegs die moontlikheid van 'n lêerrugsteun oor.
Om die risiko van stilstand te verminder, wanneer 'n foutverdraagsame stelsel geskep word, word 'n "lewendige" groepkonfigurasie geskep, en Primêr kan geleidelik migreer tussen verskillende bedieners. Byvoorbeeld, Patroni-sagteware loods self Primêr op 'n ewekansige geselekteerde groepknoop. Die IBS het geen manier om dit uit die boks op te spoor nie, en as die konfigurasie verander, breek die prosesse. Dit wil sê, die bekendstelling van eksterne beheer verhoed dat die ISR doeltreffend werk, omdat die beheerbediener eenvoudig nie verstaan waar en van watter data gekopieer moet word nie.
Nog 'n probleem is die implementering van rugsteun in Postgres. Dit is moontlik deur dump, en dit werk op klein databasisse. Maar in groot databasisse neem die storting lank, verg baie hulpbronne en kan lei tot die mislukking van die databasisinstansie.
Lêerrugsteun maak die situasie reg, maar op groot databasisse is dit stadig omdat dit in enkeldraadmodus werk. Boonop het verkopers 'n aantal bykomende beperkings. Óf jy kan nie lêer- en stortrugsteun terselfdertyd gebruik nie, óf deduplisering word nie ondersteun nie. Daar is baie probleme, en meestal is dit makliker om 'n duur maar bewese DBBS in plaas van Postgres te kies.
Daar is nêrens om terug te trek nie! Moskou-ontwikkelaars is agter!
Ons span het egter onlangs 'n moeilike uitdaging in die gesig gestaar: in die projek om AIS OSAGO 2.0 te skep, waar ons die IT-infrastruktuur geskep het, het die ontwikkelaars PostgreSQL vir die nuwe stelsel gekies.
Dit is baie makliker vir groot sagteware-ontwikkelaars om “nuieuse” oopbronoplossings te gebruik. Facebook het genoeg spesialiste om die werking van hierdie DBBS te ondersteun. En in die geval van RSA het al die take van die “tweede dag” op ons skouers geval. Ons was verplig om foutverdraagsaamheid te verseker, 'n groep saam te stel en natuurlik rugsteun op te stel. Die logika van aksie was soos volg:
- Leer die SRK om rugsteun te maak vanaf die Primêre nodus van die groepering. Om dit te doen, moet die SRK dit vind - wat beteken dat integrasie met een of ander PostgreSQL-klusterbestuursoplossing nodig is. In die geval van RSA is Patroni-sagteware hiervoor gebruik.
- Besluit op die tipe rugsteun gebaseer op die volume data en herstelvereistes. Byvoorbeeld, wanneer jy bladsye korrelig moet herstel, gebruik 'n storting, en as die databasisse groot is en korrelige herstel nie nodig is nie, werk op die lêervlak.
- Heg die moontlikheid van blokrugsteun aan die oplossing om 'n rugsteunkopie in multi-draadmodus te skep.
Terselfdertyd het ons aanvanklik 'n doeltreffende en eenvoudige stelsel geskep sonder 'n monsteragtige harnas van bykomende komponente. Hoe minder krukke, hoe minder werkslading op personeel en hoe laer is die risiko van IBS-mislukking. Ons het benaderings wat Veeam en RMAN gebruik het onmiddellik uitgesluit, want 'n stel van twee oplossings dui reeds op die onbetroubaarheid van die stelsel.
'n Bietjie magie vir onderneming
Dus, ons moes betroubare rugsteun waarborg vir 10 groepe van 3 nodusse elk, met dieselfde infrastruktuur wat in die rugsteundatasentrum weerspieël word. Datasentrums in terme van PostgreSQL werk op die aktief-passiewe beginsel. Die totale databasisgrootte was 50 TB. Enige beheerstelsel op korporatiewe vlak kan dit maklik hanteer. Maar die waarskuwing is dat Postgres aanvanklik nie 'n benul het vir volle en diep versoenbaarheid met rugsteunstelsels nie. Daarom moes ons soek na 'n oplossing wat aanvanklik maksimum funksionaliteit gehad het in samewerking met PostgreSQL, en die stelsel verfyn.
Ons het 3 interne "hackathons" gehou - ons het na meer as vyftig ontwikkelings gekyk, dit getoets, veranderinge aangebring in verband met ons hipoteses en dit weer getoets. Nadat ons die beskikbare opsies nagegaan het, het ons Commvault gekies. Uit die boks kon hierdie produk met die eenvoudigste PostgreSQL-klusterinstallasie werk, en sy oop argitektuur het hoop (wat geregverdig was) vir suksesvolle ontwikkeling en integrasie laat ontstaan. Commvault kan ook PostgreSQL-logboeke rugsteun. Veritas NetBackup kan byvoorbeeld in terme van PostgreSQL slegs volledige rugsteun maak.
Meer oor argitektuur. Commvault-bestuurbedieners is in elk van die twee datasentrums in 'n CommServ HA-konfigurasie geïnstalleer. Die stelsel word weerspieël, deur een konsole bestuur en, vanuit die HA-oogpunt, voldoen aan alle ondernemingsvereistes.
Ons het ook twee fisiese mediabedieners in elke datasentrum bekendgestel, waaraan ons skyfskikkings en bandbiblioteke gekoppel het wat spesifiek vir rugsteun via SAN via Fibre Channel toegewy is. Uitgebreide dedupliseringsdatabasisse het fouttoleransie van mediabedieners verseker, en die koppeling van elke bediener aan elke CSV het deurlopende werking moontlik gemaak indien enige komponent misluk het. Die stelselargitektuur laat rugsteun voort, selfs al val een van die datasentrums.
Patroni definieer 'n Primêre nodus vir elke groepering. Dit kan enige gratis nodus in die datasentrum wees - maar net meestal. In die rugsteun is alle nodusse Sekondêr.
Ten einde Commvault te verstaan watter groepknoop Primêr is, het ons die stelsel (danksy die oop argitektuur van die oplossing) met Postgres geïntegreer. Vir hierdie doel is 'n skrip geskep wat die huidige ligging van die Primêre nodus aan die Commvault-bestuurbediener rapporteer.
Oor die algemeen lyk die proses soos volg:
Patroni kies Primêr → Keepalived tel die IP-groepering op en voer die skrif uit → die Commvault-agent op die geselekteerde groepknoop ontvang 'n kennisgewing dat dit die Primêre is → Commvault herkonfigureer outomaties die rugsteun binne die pseudo-kliënt.
Die voordeel van hierdie benadering is dat die oplossing nie die konsekwentheid, korrektheid van logs of herstel van die Postgres-instansie beïnvloed nie. Dit is ook maklik skaalbaar, want dit is nie meer nodig om die Commvault Primêre en Sekondêre nodusse reg te stel nie. Dit is genoeg dat die stelsel verstaan waar Primêr is, en die aantal nodusse kan tot byna enige waarde verhoog word.
Die oplossing gee nie voor om ideaal te wees nie en het sy eie nuanses. Commvault kan slegs die hele instansie rugsteun, en nie individuele databasisse nie. Daarom is 'n aparte instansie vir elke databasis geskep. Regte kliënte word gekombineer in virtuele pseudo-kliënte. Elke Commvault pseudo-kliënt is 'n UNIX-kluster. Daardie groepknooppunte waarop die Commvault-agent vir Postgres geïnstalleer is, word daarby gevoeg. Gevolglik word alle virtuele nodusse van die pseudo-kliënt as een geval gerugsteun.
Binne elke pseudo-kliënt word die aktiewe nodus van die cluster aangedui. Dit is wat ons integrasie-oplossing vir Commvault definieer. Die beginsel van die werking daarvan is redelik eenvoudig: as 'n groep-IP op 'n nodus opgewek word, stel die skrip die "aktiewe node"-parameter in die Commvault-agent-binêr - in werklikheid stel die skrip "1" in die vereiste deel van die geheue . Die agent stuur hierdie data na CommServe, en Commvault maak 'n rugsteun vanaf die verlangde nodus. Daarbenewens word die korrektheid van die konfigurasie op die skrifvlak nagegaan, wat help om foute te vermy wanneer 'n rugsteun begin word.
Terselfdertyd word groot databasisse in blokke oor verskeie drade gerugsteun, wat voldoen aan RPO- en rugsteunvenstervereistes. Die las op die stelsel is onbeduidend: Volle kopieë kom nie so gereeld voor nie, op ander dae word slegs logs versamel, en tydens periodes van lae vrag.
Terloops, ons het aparte beleide toegepas vir die rugsteun van PostgreSQL-argieflogboeke - dit word volgens verskillende reëls gestoor, volgens 'n ander skedule gekopieer, en deduplisering is nie daarvoor geaktiveer nie, aangesien hierdie logboeke unieke data bevat.
Om konsekwentheid oor die hele IT-infrastruktuur te verseker, word afsonderlike Commvault-lêerkliënte op elk van die klusternodusse geïnstalleer. Hulle sluit Postgres-lêers uit van rugsteun en is slegs bedoel vir bedryfstelsel- en toepassingsrugsteun. Hierdie deel van die data het ook sy eie beleid en bergingstydperk.
Tans beïnvloed IBS nie produktiwiteitsdienste nie, maar as die situasie verander, kan Commvault vragbeperking aktiveer.
Is dit goed? Goed!
Dus, ons het nie net 'n werkbare nie, maar ook 'n volledig outomatiese rugsteun vir 'n PostgreSQL-kluster-installasie ontvang, en dit voldoen aan al die vereistes vir ondernemingsoproepe.
Die RPO- en RTO-parameters van 1 uur en 2 uur word met 'n marge bedek, wat beteken dat die stelsel daaraan sal voldoen selfs met 'n aansienlike toename in die volume gestoorde data. In teenstelling met baie twyfel, het PostgreSQL en die ondernemingsomgewing redelik versoenbaar geblyk te wees. En nou weet ons uit eie ervaring dat rugsteun vir sulke DBBS'e moontlik is in 'n wye verskeidenheid konfigurasies.
Natuurlik moes ons langs hierdie pad sewe paar ysterstewels dra, 'n aantal probleme oorkom, verskeie harke trap en 'n aantal foute regstel. Maar nou is die benadering reeds getoets en kan dit gebruik word om Open Source in plaas van eie DBMS te implementeer in moeilike ondernemingsomstandighede.
Het jy al probeer om met PostgreSQL in 'n korporatiewe omgewing te werk?
Skrywers:
Oleg Lavrenov, ontwerpingenieur van databergingstelsels, Jet Infosystems
Dmitry Erykin, ontwerpingenieur van rekenaarstelsels by Jet Infosystems
Bron: will.com