Jende askok ezagutzen du PostgreSQL DBMSa, eta instalazio txikietan frogatu du. Hala ere, Kode Irekirako joera gero eta argiagoa da, baita enpresa handiei eta enpresen eskakizunei dagokienez ere. Artikulu honetan Postgres ingurune korporatibo batean nola integratu eta datu-base honetarako babeskopia sistema (BSS) sortzeko esperientzia partekatuko dugu Commvault backup sistema adibide gisa erabiliz.
PostgreSQL-k dagoeneko frogatu du bere balioa - DBMS-k bikain funtzionatzen du, Alibaba eta TripAdvisor bezalako modako negozio digitalek erabiltzen dute eta lizentzia-tasarik ezak MS SQL edo Oracle DB bezalako munstroen alternatiba tentagarri bihurtzen du. Baina PostgreSQL enpresaren panoraman pentsatzen hasi bezain laster, berehala baldintza zorrotzekin topo egiten dugu: "Zer gertatzen da konfigurazio akatsen tolerantziarekin? hondamendien erresistentzia? non dago jarraipen integrala? Zer gertatzen da babeskopia automatizatuekin? Zer gertatzen da zinta liburutegiak zuzenean eta bigarren mailako biltegian erabiltzea?
Alde batetik, PostgreSQL-k ez ditu babeskopia-tresna barneratuak, esaterako, "helduen" DBMSak, esaterako, RMAN Oracle DBn edo SAP Database Backup-en. Bestalde, babeskopia-sistemen korporatiboen hornitzaileak (Veeam, Veritas, Commvault) PostgreSQL onartzen duten arren, izan ere, konfigurazio jakin batekin (normalean autonomoa) eta hainbat murrizketarekin soilik funtzionatzen dute.
PostgreSQLrentzat bereziki diseinatutako babeskopia-sistemak, hala nola, Barman, Wal-g, pg_probackup, oso ezagunak dira PostgreSQL DBMSaren instalazio txikietan edo IT paisaiaren beste elementu batzuen babeskopia handiak behar ez diren tokietan. Adibidez, PostgreSQLz gain, azpiegiturak zerbitzari fisikoak eta birtualak izan ditzake, OpenShift, Oracle, MariaDB, Cassandra, etab. Honen guztiaren babeskopiak tresna komun batekin egitea komeni da. PostgreSQL-rentzat esklusiboki soluzio bereizia instalatzea ideia txarra da: datuak diskora nonbait kopiatuko dira, eta gero zintara kendu behar dira. Babeskopia bikoitz honek babeskopia-denbora handitzen du, eta, modu kritikoagoan, berreskuratzeko denbora ere.
Enpresa-soluzio batean, instalazioaren babeskopia dedikatu kluster batean nodo kopuru jakin batekin egiten da. Aldi berean, adibidez, Commvault-ek bi nodoko kluster batekin bakarrik lan egin dezake, zeinetan Lehena eta Bigarrena nodo jakin batzuei zorrozki esleituta dauden. Eta lehen mailako babeskopiak egitea bakarrik du zentzua, Bigarren Hezkuntzako babeskopiak bere mugak dituelako. DBMSaren berezitasunak direla eta, ez da iraulketarik sortzen Bigarren Hezkuntzan, eta, beraz, fitxategien babeskopia egiteko aukera bakarrik geratzen da.
Hutsegite-denbora arriskua murrizteko, akats-tolerantzia-sistema bat sortzean, "zuzeneko" kluster konfigurazioa sortzen da, eta Primary pixkanaka-pixkanaka migratu daiteke zerbitzari ezberdinen artean. Adibidez, Patroni softwareak berak abiarazten du Primary ausaz hautatutako kluster-nodo batean. IBS-k ez du hau kutxatik kanpo jarraitzeko modurik, eta konfigurazioa aldatzen bada, prozesuak apurtzen dira. Hau da, kanpoko kontrola ezartzeak ISR eraginkortasunez funtzionatzea eragozten du, kontrol zerbitzariak ez baitu ulertzen non eta zer datu kopiatu behar diren.
Beste arazo bat Postgres-en babeskopia ezartzea da. Dump bidez posible da, eta datu-base txikietan funtzionatzen du. Baina datu-base handietan, zabortegiak denbora luzea hartzen du, baliabide asko behar ditu eta datu-basearen instantziaren porrota ekar dezake.
Fitxategien babeskopiak egoera zuzentzen du, baina datu-base handietan motela da, hari bakarreko moduan funtzionatzen duelako. Horrez gain, saltzaileek murrizketa gehigarri batzuk dituzte. Edo ezin dituzu fitxategien eta iraultzeko babeskopiak aldi berean erabili, edo desbikoizpena ez da onartzen. Arazo asko daude, eta gehienetan errazagoa da Postgres-en ordez DBMS garestia baina frogatua aukeratzea.
Ez dago inon atzera egiteko! Moskuko garatzaileak atzean daude!
Hala ere, duela gutxi gure taldeak erronka zail bati aurre egin zion: AIS OSAGO 2.0 sortzeko proiektuan, non IT azpiegitura sortu genuen, garatzaileek PostgreSQL aukeratu zuten sistema berrirako.
Askoz errazagoa da software-garatzaile handientzat kode irekiko irtenbide "modan daudenak" erabiltzea. Facebook-ek nahikoa espezialista ditu DBMS honen funtzionamenduan laguntzeko. Eta RSAren kasuan, βbigarren egunekoβ zeregin guztiak gure sorbaldetan erori ziren. Akatsen tolerantzia bermatu, kluster bat muntatu eta, noski, babeskopia konfiguratu behar genuen. Ekintzaren logika honako hau zen:
- Irakatsi SRK-ri klusterreko nodo nagusitik babeskopiak egiten. Horretarako, SRK-k aurkitu behar du, hau da, PostgreSQL kluster kudeaketa-soluzio batekin edo beste batekin integratzea beharrezkoa da. RSAren kasuan, Patroni softwarea erabili zen horretarako.
- Erabaki segurtasun kopia mota datuen bolumenaren eta berreskuratzeko eskakizunen arabera. Esate baterako, orriak modu zehatzean leheneratu behar dituzunean, erabili iraulketa bat, eta datu-baseak handiak badira eta leheneratzea beharrezkoa ez bada, fitxategi mailan lan egin.
- Erantsi irtenbideari blokeo babeskopia egiteko aukera, hari anitzeko moduan segurtasun kopia bat sortzeko.
Aldi berean, hasiera batean sistema eraginkor eta sinple bat sortzeari ekin genion osagai osagarrien arnes izugarririk gabe. Zenbat eta makulu gutxiago, orduan eta lan karga gutxiago langileek eta orduan eta txikiagoa da IBS porrota izateko arriskua. Veeam eta RMAN erabiltzen zituzten planteamenduak berehala baztertu genituen, bi soluzio multzo batek jada sistemaren fidagarritasuna igartzen duelako.
Magia apur bat enpresarentzat
Beraz, babeskopia fidagarria bermatu behar genuen 10 nodoko 3 klusterrentzat, babeskopia datu-zentroan islatuta dagoen azpiegitura berarekin. PostgreSQL-ri dagokionez datu-zentroek printzipio aktibo-pasiboan lan egiten dute. Datu-basearen guztizko tamaina 50 TB zen. Enpresa mailako edozein kontrol sistema erraz aurre egin diezaioke horri. Baina ohartarazpena da hasieran Postgres-ek ez duela babeskopia sistemekin bateragarritasun osoa eta sakona izateko arrastorik. Hori dela eta, hasiera batean funtzionalitate maximoa zuen irtenbide bat bilatu behar izan dugu PostgreSQLrekin batera, eta sistema findu.
Barneko 3 "hackathon" egin genituen: berrogeita hamar garapen baino gehiago aztertu, probatu, gure hipotesiekin lotutako aldaketak egin eta berriro probatu genituen. Eskuragarri dauden aukerak aztertu ondoren, Commvault aukeratu dugu. Kutxatik kanpo, produktu honek PostgreSQL kluster instalazio errazenarekin funtziona zezakeen, eta bere arkitektura irekiak garapen eta integrazio arrakastatsurako itxaropenak (justifikatuak zeuden) sortu zituen. Commvault-ek PostgreSQL erregistroen babeskopia ere egin dezake. Adibidez, Veritas NetBackup-ek PostgreSQL-ri dagokionez babeskopia osoak soilik egin ditzake.
Arkitekturari buruz gehiago. Commvault kudeaketa zerbitzariak bi datu-zentro bakoitzean CommServ HA konfigurazio batean instalatu ziren. Sistema ispilu egiten da, kontsola baten bidez kudeatzen da eta, HAren ikuspuntutik, enpresaren eskakizun guztiak betetzen ditu.
Datu-zentro bakoitzean bi multimedia zerbitzari fisiko ere abiarazi genituen, eta haietara konektatu genituen disko-matrizeak eta zinta-liburutegiak babeskopiak egiteko bereziki SAN bidez Fibre Channel bidez. Desduplicazio hedatutako datu-baseek multimedia zerbitzarien akatsen tolerantzia bermatzen zuten, eta zerbitzari bakoitza CSV bakoitzarekin konektatzeak etengabeko funtzionamendua ahalbidetzen zuen osagairen batek huts egiten bazuen. Sistemaren arkitekturak babeskopiak jarraitzea ahalbidetzen du datu-zentroren bat erori arren.
Patronik nodo Nagusi bat definitzen du kluster bakoitzeko. Doako edozein nodo izan daiteke datu-zentroan, baina gehienetan bakarrik. Babeskopian, nodo guztiak Bigarren mailakoak dira.
Commvault-ek zein cluster-nodo den Primarioa uler dezan, sistema (soluzioaren arkitektura irekiari esker) Postgres-ekin integratu dugu. Horretarako, Commvault kudeaketa zerbitzariari Nodo Nagusiaren uneko kokapenaren berri ematen dion script bat sortu zen.
Oro har, prozesua honelakoa da:
Patroni-k Lehen mailakoa hautatzen du β Keepalived-ek IP klusterra jasotzen du eta script-a exekutatzen du β Hautatutako kluster-nodoko Commvault agenteak hau Lehen mailakoa dela dioen jakinarazpena jasotzen du β Commvault-ek automatikoki berriro konfiguratzen du babeskopia sasi-bezeroaren barruan.
Ikuspegi honen abantaila da irtenbideak ez duela eragiten Postgres instantziaren koherentzian, erregistroen zuzentasunean edo berreskurapenean. Gainera, erraz eskalagarria da, jada ez baita beharrezkoa Commvault nodo nagusi eta sekundarioak konpontzea. Nahikoa da sistemak Primary non dagoen ulertzea, eta nodo kopurua ia edozein balioraino handitu daiteke.
Irtenbideak ez du ideala denik eta bere Γ±abardurak ditu. Commvault-ek instantzia osoaren babeskopia egin dezake, eta ez datu-base indibidualak. Horregatik, datu-base bakoitzeko instantzia bereizia sortu zen. Benetako bezeroak sasi-bezero birtualetan konbinatzen dira. Commvault sasi-bezero bakoitza UNIX kluster bat da. Postgres-erako Commvault agentea instalatuta dagoen kluster-nodo horiek gehitzen zaizkio. Ondorioz, sasi-bezeroaren nodo birtual guztien babeskopia instantzia bakar gisa egiten da.
Sasi-bezero bakoitzaren barruan, klusterraren nodo aktiboa adierazten da. Hau da Commvault-erako gure integrazio-soluzioak definitzen duena. Bere funtzionamenduaren printzipioa nahiko erraza da: kluster IP bat nodo batean planteatzen bada, script-ak "nodo aktiboa" parametroa ezartzen du Commvault agente bitarrean; hain zuzen ere, scriptak "1" ezartzen du memoriaren beharrezko zatian. . Agenteak datu hauek CommServe-ra igortzen ditu, eta Commvault-ek babeskopia bat egiten du nahi den nodotik. Horrez gain, konfigurazioaren zuzentasuna egiaztatzen da script mailan, babeskopia bat abiaraztean akatsak saihesten lagunduz.
Aldi berean, datu-base handien babeskopia blokeetan egiten da hainbat haritan, RPO eta babeskopia-leihoen eskakizunak betez. Sistemaren karga hutsala da: kopia osoak ez dira hainbestetan gertatzen, beste egun batzuetan erregistroak bakarrik biltzen dira eta karga baxuko aldietan.
Bide batez, PostgreSQL artxiboen erregistroen babeskopiak egiteko politika bereiziak aplikatu ditugu: arau ezberdinen arabera gordetzen dira, beste programazio baten arabera kopiatzen dira eta desduplicazioa ez dago gaituta, erregistro horiek datu bakarrak dituztelako.
IT azpiegitura osoan koherentzia bermatzeko, Commvault fitxategi-bezero bereiziak instalatzen dira cluster-nodo bakoitzean. Postgres fitxategiak babeskopietatik kanpo uzten dituzte eta OS eta aplikazioen babeskopietarako soilik daude pentsatuta. Datuen zati honek bere politika eta biltegiratze epea ere baditu.
Gaur egun, IBSk ez du produktibitate zerbitzuetan eragiten, baina egoera aldatzen bada, Commvault-ek karga mugatzea gaitu dezake.
Ona al da? Ona!
Beraz, egingarria ez ezik, guztiz automatizatutako babeskopia ere jaso dugu PostgreSQL kluster instalazio baterako, eta enpresa-deietarako baldintza guztiak betetzen ditu.
Ordu 1 eta 2 orduko RPO eta RTO parametroak marjina batekin estaltzen dira, hau da, sistemak horiek beteko ditu gordetako datuen bolumena nabarmen handitu bada ere. Zalantza askoren aurka, PostgreSQL eta enpresa ingurunea nahiko bateragarriak izan ziren. Eta orain gure esperientziatik dakigu horrelako DBMSen babeskopia posible dela hainbat konfiguraziotan.
Noski, bide horretan, burdinazko zazpi bota pare agortu behar izan ditugu, hainbat zailtasun gainditu, hainbat rastrilu zapaldu eta hainbat akats zuzendu. Baina orain ikuspegia dagoeneko probatu da eta Iturburu Irekia ezartzeko erabil daiteke jabedun DBMSen ordez enpresa baldintza gogorretan.
Saiatu al zara PostgreSQLrekin lan egiten ingurune korporatibo batean?
Egileak:
Oleg Lavrenov, Jet Infosystems datuak biltegiratzeko sistemen diseinu ingeniaria
Dmitry Erykin, Jet Infosystems-en informatika sistemen diseinu ingeniaria
Iturria: www.habr.com