Shumica e njerëzve janë të njohur me DBMS PostgreSQL, dhe ajo ka treguar performancën e saj të shkëlqyer në instalimet e vogla. Megjithatë, tendenca për të kaluar në Open Source është bërë gjithnjë e më e qartë, madje edhe kur bëhet fjalë për kompanitë e mëdha dhe kërkesat enterprise. Në këtë artikull, do të flasim se si të integromi Postgres në një ambient korporatë dhe do të ndajmë përvojën tonë në krijimin e një sistemi të kopjeve rezervë (SRK) për këtë bazë të dhënash duke marrë shembullin e sistemit të kopjeve rezervë Commvault.
PostgreSQL ka dĂ«shmuar qĂ« Ă«shtĂ« e besueshme â DBMS funksionon nĂ« mĂ«nyrĂ« tĂ« shkĂ«lqyer, e pĂ«rdorin biznese moderne digjitale si Alibaba dhe TripAdvisor, dhe mungesa e tarifave tĂ« licencĂ«s e bĂ«n atĂ« njĂ« alternativĂ« tĂ«rheqĂ«se ndaj gjigantĂ«ve si MS SQL ose Oracle DB. Por sa herĂ« qĂ« fillojmĂ« tĂ« mendojmĂ« pĂ«r PostgreSQL nĂ« peizazhin e Enterprise, pĂ«rballemi me kĂ«rkesa tĂ« rrepta: "Si Ă«shtĂ« qĂ«ndrueshmĂ«ria e konfiguracionit? si pĂ«r qĂ«ndrueshmĂ«ri tĂ« fatkeqĂ«sive? ku Ă«shtĂ« monitorimi i gjithanshĂ«m? a ka backup automatizuar? a pĂ«rdoren bibliotekat e kasetave si direkt ashtu edhe si depo sekondare?"
Nga njëra anë, PostgreSQL nuk ka mjete të integruara për backup, siç ka DBMS të "rritura" si RMAN në Oracle DB ose SAP Database Backup. Nga ana tjetër, ofruesit e sistemeve të kopjeve rezervë për kompanitë (Veeam, Veritas, Commvault) megjithatë mbështesin PostgreSQL, por praktikisht punojnë vetëm me një konfigurim të caktuar (zakonisht standalone) dhe me një grup kufizimesh të ndryshme.
Sistemet e kopjeve rezervĂ« tĂ« dizajnuar posaçërisht pĂ«r PostgreSQL, si Barman, Wal-g, pg_probackup, janĂ« jashtĂ«zakonisht tĂ« njohura nĂ« instalimet e vogla tĂ« DBMS PostgreSQL ose atje ku nuk nevojiten kopje tĂ« mĂ«dha tĂ« elementeve tĂ« tjera tĂ« peizazhit IT. PĂ«r shembull, pĂ«rveç PostgreSQL, nĂ« infrastrukturĂ« mund tĂ« jenĂ« fizike dhe virtuale, OpenShift, Oracle, MariaDB, Cassandra, etj. TĂ« gjitha kĂ«to dĂ«shirojnĂ« tĂ« kopjohen me njĂ« mjet tĂ« pĂ«rbashkĂ«t. TĂ« vendosĂ«sh njĂ« zgjidhje tĂ« veçantĂ« vetĂ«m pĂ«r PostgreSQL Ă«shtĂ« njĂ« ide e keqe: tĂ« dhĂ«nat do tĂ« kopjohen diku nĂ« disk dhe pastaj duhet tâi transferosh nĂ« kasetĂ«. Ky dyfishim i kopjimit rezervĂ« rrit kohĂ«n e kopjimit, dhe mĂ« e rĂ«ndĂ«sishmja, - rikuperimin. falas. Kjo Ă«shtĂ« vetĂ«m njĂ« nga shumĂ« privilegjet qĂ« ofrojmĂ« pĂ«r klientĂ«t tanĂ« tĂ« rinj tĂ« web-hosting.NĂ« njĂ« zgjidhje enterprise, kopjimi rezervĂ« i instalimit ndodh me njĂ« numĂ«r nodash tĂ« dedikuar tĂ« klasterit. NĂ« kĂ«tĂ« rast, pĂ«r shembull, Commvault funksionon vetĂ«m me njĂ« klaster me dy node, nĂ« tĂ« cilin Primary dhe Secondary janĂ« ngushtĂ«sisht tĂ« lidhura me nodat specifike. Dhe ka kuptim tĂ« bĂ«sh backup vetĂ«m me Primary, sepse backup nga Secondary ka kufizimet e veta. PĂ«r shkak tĂ« veçorive tĂ« DBMS, dump nĂ« Secondary nuk krijohet, dhe kĂ«shtu mbetet vetĂ«m mundĂ«sia e backup-it tĂ« skedarĂ«ve.
Për të zvogëluar rreziqet e pezullimit, kur krijohet një sistem qëndresë, formohet një konfiguracion klasteri "i gjallë", dhe Primary mund të migrojë gradualisht mes serverëve të ndryshëm. Për shembull, softueri Patroni (në anglisht, 'Patroni') e aktivizon automatikisht Primary në një nod të zgjedhur rastësisht të klasterit. SRK nuk ka një mënyrë për të ndjekur këtë "nga kuti", dhe nëse konfigurimi ndryshon, proceset dështojnë. Kështu, implementimi i menaxhimit të jashtëm pengon SRK-në të funksionojë në mënyrë efektive, sepse serveri menaxhues thjesht nuk kupton se nga cili dhe cilat të dhëna duhet të kopjojë.
Një tjetër problem është realizimi i backup-it në Postgres. Ajo është e mundur përmes dump, dhe në bazat e vogla funksionon. Por në bazat e mëdha, dump bëhet ngadalë, kërkon shumë burime dhe mund të shkaktojë dështimin e ekzemplarit të DB.
Backup-i i skedarëve e korrigjon situatën, por në bazat e mëdha shkon ngadalë, sepse punon në modalitetin njëkanalësh. Po ashtu, ofruesit kanë një sërë kufizimesh të tjera. Ndonjëherë nuk mund të përdoren për njëkohësisht backup-i i skedarëve dhe dump-i, ndonjëherë nuk mbështetet deduplication. Problemet janë të shumta, dhe shpesh më e lehtë është të zgjidhni një DBMS të shtrenjtë, por të provuar në vend të Postgres.
Nuk ka ku të tërhiqemi! Prapa nesh është Moska me zhvilluesit!
Megjithatë, së fundmi ekipi ynë u përball me një sfidë të vështirë: në projektin e krijimit të AIS OSAGO 2.0, ku ne krijuam infrastrukturen IT, zhvilluesit për sistemin e ri zgjodhën PostgreSQL.
Zhvilluesit e mëdhenj të softuerit e kanë shumë më të lehtë të përdorin zgjidhje "trending" open-source. Në stafin e Facebook-ut ka mjaft specialistë që mbështesin funksionimin e kësaj DBMS. Ndërsa në rastin e RSA, të gjitha detyrat e "ditës së dytë" bien mbi supet tona. Na u kërkua të sigurojmë qëndrueshmërinë, të krijojmë një klaster dhe, natyrisht, të vendosim kopjimin rezervë. Logjika e veprimeve ishte kështu:
TĂ« mĂ«sojmĂ« SRK-nĂ« tĂ« bĂ«jĂ« backup nga nodi Primary i klasterit. PĂ«r kĂ«tĂ«, SRK duhet ta gjejĂ« atĂ« â dmth, Ă«shtĂ« e nevojshme integrimi me ndonjĂ« zgjidhje pĂ«r menaxhimin e klasterit PostgreSQL. NĂ« rastin e RSA pĂ«rdorej softueri Patroni.
- Mësojeni SRK të bëjë backup nga nodi kryesor i klasterit. Për këtë, SRK duhet të gjejë atë - do të thotë, nevojitet integrimi me një zgjidhje të caktuar për menaxhimin e klasterit PostgreSQL. Në rastin e RSA, u përdor softueri Patroni për këtë qëllim.
- Përcaktohet tipi i kopjes rezervë, bazuar në volumin e të dhënave dhe kërkesat për rikuperim. Për shembull, kur duhet të rikuperohen faqet në mënyrë granulare, përdor një dump, dhe nëse bazat janë të mëdha dhe rikuperimi granular nuk është i nevojshëm - puno në nivelin e skedarëve.
- Shto mundësinë e kopjimit bllokues në zgjidhje, për të krijuar kopje rezervë në modin shumëprocesor.
Qëllimi ynë fillestar ishte të krijonim një sistem të efektshëm dhe të thjeshtë pa shtrirje monstruoze të komponentëve të tjerë. Sa më pak zgjidhje anësore, aq më pak ngarkesë për staf dhe më i ulët rreziku i dështimit të SRK-së. Qasjet që përfshinin Veeam dhe RMAN i përjashtuam menjëherë, sepse paketa me dy zgjidhje tashmë sugjeron pasigurinë e sistemit.
Pak magji për enterprise
KĂ«shtu, na duhej tĂ« garantonim njĂ« kopje rezervĂ« tĂ« besueshme pĂ«r 10 klasterĂ« me nga 3 node secili, ku infrastrukturen e rezervuar nĂ« QendrĂ«n e tĂ« DhĂ«nave (ĐŠĐĐ) e kishte tĂ« njĂ«jtĂ«n konfigurim. ĐŠĐĐ-tĂ« nĂ« lidhje me PostgreSQL funksionojnĂ« nĂ« parimin aktiv-pasiv. VĂ«llimi total i bazave tĂ« tĂ« dhĂ«nave ishte 50 TB. Kjo Ă«shtĂ« e lehtĂ« pĂ«r t'u menaxhuar nga çdo SRK nivel enterprise. Por detaji Ă«shtĂ« se nĂ« fillim PostgreSQL nuk ka asnjĂ« mundĂ«si pĂ«r tĂ« qenĂ« plotĂ«sisht dhe thellĂ«sisht i pajtueshĂ«m me sistemet e kopjimit. Prandaj na duhej tĂ« kĂ«rkonim njĂ« zgjidhje qĂ« kishte maksimumin e funksionalitetit nĂ« lidhje me PostgreSQL dhe ta pĂ«rmirĂ«sonim atĂ«.
Kemi organizuar 3 âhackatonaâ tĂ« brendshme - kemi analizuar mĂ« shumĂ« se pesĂ«dhjetĂ« projekte, i kemi testuar ato, kemi bĂ«rĂ« ndryshime nĂ« pĂ«rputhje me hipotezat tona dhe kemi kontrolluar pĂ«rsĂ«ri. Pas analizimit tĂ« mundĂ«sive nĂ« dispozicion, zgjodhĂ«m Commvault. Ky produkt Ă«shtĂ« i aftĂ« qĂ« tĂ« funksionojĂ« me njĂ« instalim tĂ« thjeshtĂ« klasteri PostgreSQL dhe arkitektura e tij e hapur nxiste shpresĂ«n (e cila u realizua) pĂ«r pĂ«rmirĂ«sim dhe integrim tĂ« suksesshĂ«m. Gjithashtu, Commvault mund tĂ« kryejĂ« kopje rezervĂ« tĂ« log-eve tĂ« PostgreSQL. PĂ«r shembull, Veritas NetBackup nĂ« lidhje me PostgreSQL mund tĂ« bĂ«jĂ« vetĂ«m kopje rezervĂ« tĂ« plota.
MĂ« shumĂ« nĂ« lidhje me arkitekturĂ«n. ServerĂ«t menaxhues tĂ« Commvault ishin instaluar nĂ« secilĂ«n nga dy ĐŠĐĐ nĂ« konfigurimin CommServ HA. Sistemi Ă«shtĂ« mirror, menaxhohet nga njĂ« konsolĂ« dhe nĂ« lidhje me HA pĂ«rmbush tĂ« gjitha kĂ«rkesat enterprise.
Gjithashtu, nĂ« çdo ĐŠĐĐ kemi rithekur nga dy servera fizikĂ« mediatikĂ«, tĂ« cilĂ«t ishin lidhur nĂ«pĂ«rmjet SAN pĂ«rmes Fibre Channel me grupe disku tĂ« dedikuara posaçërisht pĂ«r kopje rezervĂ« dhe biblioteka prshetĂ«s. Bazat e tĂ« dhĂ«nave tĂ« shtrira prishin deduplication qĂ« siguron qĂ«ndrueshmĂ«ri pĂ«r serverat mediatikĂ«, dhe lidhja e secilit server me çdo CSV - mundĂ«sinĂ« pĂ«r vazhdimĂ«sinĂ« e punĂ«s edhe nĂ« rastin e dĂ«shtimit tĂ« ndonjĂ« komponenti. Arkitektura e sistemit lejon vazhdimin e kopjimit edhe nĂ«se ndonjĂ« ĐŠĐĐ dĂ«shton.
Patroni pĂ«rcakton Primary-nodĂ«n pĂ«r çdo klaster. Ajo mund tĂ« jetĂ« çdo nodĂ« e lirĂ« nĂ« ĐŠĐĐ - por vetĂ«m nĂ« ate kryesore. NĂ« rezervĂ«, tĂ« gjitha nodet janĂ« Sekondare.
Që Commvault të kuptojë se cila nodë e klasterit është Primary, ne integromëm sistemin (falë arkitekturës së hapur të zgjidhjes) me PostgreSQL. Për këtë, u krijua një skript që informon për vendndodhjen aktuale të Primary-nodës menaxhuese server Commvault.
Në përgjithësi, procesi duket kështu:
Patroni zgjedh Primary â Keepalived ngre IP-klasterin dhe aktivizon skriptin â agjenti Commvault nĂ« nodĂ«n e zgjedhur tĂ« klasterit merr njoftimin qĂ« kjo Ă«shtĂ« Primary â Commvault automatikisht rikonfiguron kopjen rezervĂ« brenda klientit tĂ« simuluar.
Avantazhi i këtij qasje është se zgjidhja nuk ndikon as në konsistencën, as në saktësinë e log-eve, as në rikuperimin e instancës së PostgreSQL. Gjithashtu, ajo është e lehtë për t'u zgjeruar, sepse tani nuk është e nevojshme të fiksojmë nodët Primary dhe Sekondare për Commvault. Mjafton që sistemi të kuptojë se ku është Primary, dhe numri i nodëve mund të rritet praktikisht deri në çdo vlerë.
Zgjidhja nuk pretendon pĂ«r pĂ«rsosmĂ«ri dhe ka nuanca tĂ« veta. Commvault mund tĂ« bĂ«jĂ« kopje rezervĂ« vetĂ«m tĂ« instancĂ«s nĂ« tĂ«rĂ«si, jo tĂ« bazave tĂ« veçanta. Prandaj pĂ«r çdo DB Ă«shtĂ« krijuar njĂ« instancĂ« e veçantĂ«. KlientĂ«t realĂ« janĂ« tĂ« kombinuar nĂ« klientĂ«t e simuluar virtualĂ«. Ădo klient i simuluar i Commvault pĂ«rfaqĂ«son njĂ« klaster UNIX. NĂ« tĂ«, shtohen ato nodet e klasterit mbi tĂ« cilat Ă«shtĂ« instaluar agjenti Commvault pĂ«r PostgreSQL. Si rezultat, tĂ« gjitha nodet virtuale tĂ« klientit tĂ« simuluar kopjohen si njĂ« instancĂ« e vetme.
Brenda çdo psevdoklienti Ă«shtĂ« e indikuar njĂ« node aktive e klasterit. Kjo Ă«shtĂ« ajo qĂ« zgjidhja jonĂ« e integrimit pĂ«r Commvault e pĂ«rcakton. Parimi i funksionimit Ă«shtĂ« mjaft i thjeshtĂ«: nĂ«se nĂ« node ngrihet njĂ« IP klasteri, skripta vendos nĂ« binarĂ«t e agjentit Commvault parametrin "node aktive" â nĂ« thelb, skripta vendos "1" nĂ« pjesĂ«n e nevojshme tĂ« memories. Agjenti i transmeton kĂ«to tĂ« dhĂ«na nĂ« CommServe, dhe Commvault bĂ«n backup nga node e nevojshme. PĂ«rveç kĂ«saj, nĂ« nivelin e skriptĂ«s kontrollohet saktĂ«sia e konfigurimit, duke ndihmuar nĂ« shmangien e gabimeve gjatĂ« nisjes sĂ« rezervimit.
Ndërkohë, bazat e mëdha të dhënash rezervohet bllok përmes disa rrjedhave, duke përmbushur kërkesat RPO dhe dritaren e rezervimit. Ngarkesa në sistem është e papërfillshme: Kopjet e plota ndodhin jo aq shpesh, ndërsa në ditët e tjera mblidhen vetëm log-et, madje në periudha të ngarkesës së ulët.
PĂ«r mĂ« tepĂ«r, ne kemi aplikuar politika tĂ« veçanta pĂ«r rezervimin e regjistrave arkivorĂ« PostgreSQL â ato ruhen sipas rregullave tĂ« tjera, kopjohen sipas njĂ« orari tĂ« ndryshĂ«m dhe pĂ«r to nuk aktivizohet deduplication, pasi kĂ«to regjistra mbajnĂ« tĂ« dhĂ«na unike.
Për të siguruar koherencën e gjithë infrastrukturës IT, klientët e veçantë të Commvault janë instaluar në çdo node të klasterit. Ata ekskludojnë nga rezervimet skedarët e Postgres dhe janë të destinuar vetëm për backup të OS dhe aplikacioneve. Për këtë pjesë të të dhënave është parashikuar gjithashtu një politikë e veçantë dhe një afat ruajtjeje.
Aktualisht, SRK nuk ndikon në shërbimet produktive, por nëse situata ndryshon, në Commvault mund të aktivizohet sistemi i kufizimit të ngarkesës.
ĂshtĂ« nĂ« rregull? ĂshtĂ« nĂ« rregull!
Prandaj, ne morëm një backup që jo vetëm funksionon, por është gjithashtu plotësisht i automatizuar për instalimin e klasterit PostgreSQL, duke përmbushur të gjitha kërkesat për sfidat enterprise.
Parametrat RPO dhe RTO në 1 orë dhe 2 orë janë mbuluar me rezerva, që do të thotë se sistema do t'i përmbushë ato edhe me rritjen e konsiderueshme të sasisë së të dhënave të ruajtura. Në kundërshtim me shumë dyshime, PostgreSQL dhe mjedisi enterprise rezultuan të jenë mjaft të përputhshëm. Dhe tani, nga përvoja jonë, dimë se backup për një DBMS të tillë është i mundshëm në konfiguracione të ndryshme.
Sigurisht, në këtë rrugë na duhej të shkelim mbi shtatë palë çizme hekuri, të kalojmë disa vështirësi, të përplasim disa herë dhe të rregullojmë një numër gabimesh. Por tani ky qasje është testuar dhe mund të zbatohet për implementimin e Open Source në vend të DBMS-ve pronar në kushte të ashpra enterprise.
A keni provuar të punoni me PostgreSQL në një mjedis korporativ?
Shkruar nga:
Oleg Lavrenov, inxhinier projektues i sistemeve të ruajtjes të të dhënave "Infosistemet Jet"
Dmitry Yerikin, inxhinier projektues i komplekseve kompjuterik "Infosistemet Jet"
Burimi: habr.com
