Mnogi su ljudi upoznati s PostgreSQL DBMS-om i dokazao se u malim instalacijama. Međutim, trend prema Open Sourceu postaje sve jasniji, čak i kada se radi o velikim tvrtkama i zahtjevima poduzeća. U ovom članku ćemo vam reći kako integrirati Postgres u korporativno okruženje i podijeliti naše iskustvo stvaranja sustava za sigurnosno kopiranje (BSS) za ovu bazu podataka koristeći Commvault sustav za sigurnosno kopiranje kao primjer.
PostgreSQL je već dokazao svoju vrijednost - DBMS radi odlično, koriste ga moderne digitalne tvrtke poput Alibabe i TripAdvisora, a nedostatak naknada za licenciranje čini ga primamljivom alternativom takvim čudovištima kao što su MS SQL ili Oracle DB. Ali čim počnemo razmišljati o PostgreSQL-u u Enterprise krajoliku, odmah nailazimo na stroge zahtjeve: “Što je s tolerancijom grešaka u konfiguraciji? otpornost na katastrofe? gdje je sveobuhvatni nadzor? Što je s automatskim sigurnosnim kopiranjem? Što je s korištenjem knjižnica traka i izravno i na sekundarnoj pohrani?”
S jedne strane, PostgreSQL nema ugrađene alate za sigurnosno kopiranje, poput "odraslih" DBMS-ova kao što je RMAN u Oracle DB ili SAP Database Backup. S druge strane, dobavljači korporativnih backup sustava (Veeam, Veritas, Commvault) iako podržavaju PostgreSQL, zapravo rade samo s određenom (obično samostalnom) konfiguracijom i uz niz raznih ograničenja.
Sustavi sigurnosnog kopiranja posebno dizajnirani za PostgreSQL, kao što su Barman, Wal-g, pg_probackup, izuzetno su popularni u malim instalacijama PostgreSQL DBMS-a ili gdje nisu potrebne teške sigurnosne kopije drugih elemenata IT okruženja. Na primjer, uz PostgreSQL, infrastruktura može uključivati fizičke i virtualne poslužitelje, OpenShift, Oracle, MariaDB, Cassandra itd. Preporučljivo je sve to sigurnosno kopirati uobičajenim alatom. Instaliranje zasebnog rješenja isključivo za PostgreSQL je loša ideja: podaci će se kopirati negdje na disk, a zatim ih treba ukloniti na traku. Ovo dvostruko sigurnosno kopiranje povećava vrijeme sigurnosnog kopiranja, a također, što je kritičnije, vrijeme oporavka.
U poslovnom rješenju, sigurnosna kopija instalacije događa se s određenim brojem čvorova u namjenskom klasteru. U isto vrijeme, na primjer, Commvault može raditi samo s klasterom od dva čvora, u kojem su primarni i sekundarni strogo dodijeljeni određenim čvorovima. A sigurnosno kopiranje ima smisla samo s primarnog, jer sigurnosno kopiranje sa sekundarnog ima svoja ograničenja. Zbog osobitosti DBMS-a, dump se ne stvara na sekundarnom, pa stoga ostaje samo mogućnost sigurnosne kopije datoteke.
Kako bi se smanjio rizik od zastoja, prilikom stvaranja sustava otpornog na greške, kreira se konfiguracija klastera "uživo", a primarni može postupno migrirati između različitih poslužitelja. Na primjer, sam softver Patroni pokreće Primary na nasumično odabranom čvoru klastera. IBS nema načina da to prati odmah, a ako se konfiguracija promijeni, procesi se prekidaju. Odnosno, uvođenje vanjske kontrole onemogućuje ISR-u da učinkovito radi, jer kontrolni poslužitelj jednostavno ne razumije odakle i od kojih podataka treba kopirati.
Drugi problem je implementacija sigurnosne kopije u Postgresu. Moguće je kroz dump, a radi na malim bazama podataka. Ali u velikim bazama podataka, dump traje dugo, zahtijeva puno resursa i može dovesti do kvara instance baze podataka.
Sigurnosno kopiranje datoteka ispravlja situaciju, ali na velikim bazama podataka je sporo jer radi u jednonitnom načinu rada. Osim toga, dobavljači imaju niz dodatnih ograničenja. Ili ne možete istovremeno koristiti sigurnosne kopije datoteke i ispisa ili deduplikacija nije podržana. Postoji mnogo problema, a najčešće je lakše odabrati skupi, ali provjereni DBMS umjesto Postgresa.
Nema se kamo povući! Moskva programeri su iza!
Međutim, nedavno se naš tim suočio s teškim izazovom: u projektu stvaranja AIS OSAGO 2.0, gdje smo izradili IT infrastrukturu, programeri su odabrali PostgreSQL za novi sustav.
Velikim programerima softvera puno je lakše koristiti "trendi" open-source rješenja. Facebook ima dovoljno stručnjaka koji podržavaju rad ovog DBMS-a. A u slučaju RSA, svi zadaci “drugog dana” pali su na naša pleća. Od nas se tražilo da osiguramo toleranciju na pogreške, sastavimo klaster i, naravno, postavimo backup. Logika djelovanja bila je sljedeća:
- Naučite SRK da pravi sigurnosne kopije iz primarnog čvora klastera. Da bi to učinio, SRK ga mora pronaći - što znači da je potrebna integracija s jednim ili drugim rješenjem za upravljanje PostgreSQL klasterom. U slučaju RSA, za to je korišten softver Patroni.
- Odlučite se o vrsti sigurnosne kopije na temelju količine podataka i zahtjeva za oporavak. Na primjer, kada trebate granularno vratiti stranice, upotrijebite dump, a ako su baze podataka velike i granularno vraćanje nije potrebno, radite na razini datoteke.
- Rješenju priložite mogućnost sigurnosne kopije bloka za izradu sigurnosne kopije u višenitnom načinu rada.
U isto vrijeme, prvotno smo krenuli u stvaranje učinkovitog i jednostavnog sustava bez monstruoznih dodatnih komponenti. Što je manje štaka, manje je opterećenje osoblja i manji je rizik od kvara IBS-a. Odmah smo isključili pristupe koji su koristili Veeam i RMAN, jer skup od dva rješenja već upućuje na nepouzdanost sustava.
Malo magije za poduzeća
Dakle, morali smo zajamčiti pouzdanu sigurnosnu kopiju za 10 klastera od po 3 čvora, s istom infrastrukturom koja se zrcali u rezervnom podatkovnom centru. Podatkovni centri u smislu PostgreSQL-a rade na aktivno-pasivnom principu. Ukupna veličina baze podataka bila je 50 TB. Svaki sustav kontrole na korporativnoj razini može se lako nositi s tim. Ali upozorenje je da u početku Postgres nema pojma o potpunoj i dubokoj kompatibilnosti sa sustavima za sigurnosno kopiranje. Stoga smo morali potražiti rješenje koje je u startu imalo maksimalnu funkcionalnost u sprezi s PostgreSQL-om i doraditi sustav.
Održali smo 3 interna “hackathona” - pogledali smo više od pedeset razvoja, testirali ih, napravili izmjene u vezi s našim hipotezama i ponovno ih testirali. Nakon pregleda dostupnih opcija, odabrali smo Commvault. Izvan kutije, ovaj je proizvod mogao raditi s najjednostavnijom instalacijom PostgreSQL klastera, a njegova otvorena arhitektura pobudila je nade (koje su bile opravdane) za uspješan razvoj i integraciju. Commvault također može sigurnosno kopirati PostgreSQL zapisnike. Na primjer, Veritas NetBackup u smislu PostgreSQL-a može napraviti samo potpune sigurnosne kopije.
Više o arhitekturi. Upravljački poslužitelji Commvault instalirani su u svaki od dva podatkovna centra u konfiguraciji CommServ HA. Sustav je zrcaljen, njime se upravlja preko jedne konzole i, sa stajališta HA, zadovoljava sve zahtjeve poduzeća.
Također smo pokrenuli dva fizička medijska poslužitelja u svakom podatkovnom centru, na koje smo povezali diskovne nizove i biblioteke traka namijenjene posebno za sigurnosne kopije putem SAN-a putem Fibre Channela. Proširene baze podataka za deduplikaciju osigurale su toleranciju na pogreške medijskih poslužitelja, a povezivanje svakog poslužitelja sa svakim CSV-om omogućilo je neprekidan rad u slučaju kvara bilo koje komponente. Arhitektura sustava omogućuje nastavak sigurnosnog kopiranja čak i ako jedan od podatkovnih centara padne.
Patroni definira primarni čvor za svaki klaster. To može biti bilo koji slobodni čvor u podatkovnom centru - ali samo većinom. U sigurnosnoj kopiji, svi čvorovi su sekundarni.
Kako bi Commvault razumio koji je čvor klastera primarni, integrirali smo sustav (zahvaljujući otvorenoj arhitekturi rješenja) s Postgresom. U tu svrhu stvorena je skripta koja prijavljuje trenutnu lokaciju primarnog čvora poslužitelju za upravljanje Commvault.
Općenito, proces izgleda ovako:
Patroni odabire Primarni → Keepalived preuzima IP klaster i pokreće skriptu → Commvault agent na odabranom čvoru klastera prima obavijest da je to primarni → Commvault automatski ponovno konfigurira sigurnosnu kopiju unutar pseudoklijenta.
Prednost ovog pristupa je u tome što rješenje ne utječe na dosljednost, ispravnost dnevnika ili oporavak Postgresove instance. Također je lako skalabilan jer više nije potrebno popravljati primarne i sekundarne čvorove Commvault. Dovoljno je da sustav razumije gdje je primarni, a broj čvorova se može povećati na gotovo bilo koju vrijednost.
Rješenje se ne pretvara da je idealno i ima svoje nijanse. Commvault može sigurnosno kopirati samo cijelu instancu, a ne pojedinačne baze podataka. Stoga je za svaku bazu podataka stvorena posebna instanca. Stvarni klijenti se spajaju u virtualne pseudo-klijente. Svaki Commvault pseudo-klijent je UNIX klaster. Dodani su mu oni čvorovi klastera na kojima je instaliran Commvault agent za Postgres. Kao rezultat toga, svi virtualni čvorovi pseudoklijenta sigurnosno su kopirani kao jedna instanca.
Unutar svakog pseudoklijenta, naznačen je aktivni čvor klastera. To je ono što naše integracijsko rješenje za Commvault definira. Načelo njegovog rada je prilično jednostavno: ako se IP klastera podigne na čvoru, skripta postavlja parametar "aktivni čvor" u binarnom Commvault agentu - zapravo, skripta postavlja "1" u potrebni dio memorije . Agent prenosi te podatke CommServeu, a Commvault pravi sigurnosnu kopiju sa željenog čvora. Osim toga, ispravnost konfiguracije provjerava se na razini skripte, što pomaže u izbjegavanju pogrešaka prilikom pokretanja sigurnosne kopije.
U isto vrijeme, velike baze podataka sigurnosno se kopiraju u blokovima kroz više niti, ispunjavajući zahtjeve RPO-a i sigurnosnog prozora. Opterećenje sustava je beznačajno: pune kopije se ne pojavljuju tako često, ostalim danima prikupljaju se samo zapisnici, au razdobljima niskog opterećenja.
Usput, primijenili smo odvojena pravila za sigurnosno kopiranje zapisnika PostgreSQL arhive - oni se pohranjuju prema različitim pravilima, kopiraju prema drugom rasporedu i deduplikacija im nije omogućena, budući da ti zapisnici sadrže jedinstvene podatke.
Kako bi se osigurala dosljednost u cijeloj IT infrastrukturi, zasebni klijenti datoteka Commvault instalirani su na svakom od čvorova klastera. Oni isključuju Postgres datoteke iz sigurnosnih kopija i namijenjeni su samo za sigurnosne kopije OS-a i aplikacija. I ovaj dio podataka ima svoju politiku i rok pohrane.
Trenutno IBS ne utječe na usluge produktivnosti, ali ako se situacija promijeni, Commvault može omogućiti ograničenje opterećenja.
Je li to dobro? Dobro!
Dakle, dobili smo ne samo funkcionalnu, već i potpuno automatiziranu sigurnosnu kopiju za instalaciju PostgreSQL klastera, koja ispunjava sve zahtjeve za poslovne pozive.
Parametri RPO i RTO od 1 sata i 2 sata pokriveni su s marginom, što znači da će ih sustav poštovati čak i uz značajno povećanje količine pohranjenih podataka. Suprotno mnogim sumnjama, pokazalo se da su PostgreSQL i poslovno okruženje prilično kompatibilni. A sada iz vlastitog iskustva znamo da je sigurnosna kopija za takve DBMS-ove moguća u širokom rasponu konfiguracija.
Naravno, na tom smo putu morali istrošiti sedam pari željeznih čizama, svladati niz poteškoća, stati na nekoliko grablji i ispraviti niz grešaka. Ali sada je pristup već testiran i može se koristiti za implementaciju otvorenog koda umjesto vlasničkog DBMS-a u teškim poslovnim uvjetima.
Jeste li probali raditi s PostgreSQL-om u poslovnom okruženju?
Autori:
Oleg Lavrenov, inženjer dizajna sustava za pohranu podataka, Jet Infosystems
Dmitry Erykin, inženjer dizajna računalnih sustava u Jet Infosystems
Izvor: www.habr.com