Shumë njerëz e njohin SGBD PostgreSQL, dhe ajo ka treguar performancë të shkëlqyer në instalime të vogla. Megjithatë, tendenca për të kaluar në Open Source është bërë gjithnjë e më e dukshme, edhe kur flitet për kompanitë e mëdha dhe kërkesat e sipërmarrjes. Në këtë artikull, ne do të tregojmë se si ta integrojmë Postgres në ambientin e korporatave dhe do të ndajmë përvojën tonë në krijimin e një sistemi rezervë (SRK) për këtë bazë të dhënash, duke u bazuar në sistemin e rezervimit Commvault.
PostgreSQL tashmĂ« ka provuar vlerĂ«n e saj â SGBD funksionon shkĂ«lqyeshĂ«m, e pĂ«rdorin biznese dixhitale tĂ« njohura si Alibaba dhe TripAdvisor, dhe mungesa e tarifave licencuese e bĂ«n atĂ« njĂ« alternativĂ« tĂ«rheqĂ«se ndaj monstruve si MS SQL ose Oracle DB. Por sapo fillojmĂ« tĂ« mendojmĂ« pĂ«r PostgreSQL nĂ« peizazhin e SipĂ«rmarrjes, menjĂ«herĂ« pĂ«rballemi me kĂ«rkesa tĂ« rrepta: âSi Ă«shtĂ« qĂ«ndrueshmĂ«ria e konfiguracionit? qĂ«ndrueshmĂ«ria nĂ« rast katastrofe? ku Ă«shtĂ« monitorimi i gjithanshĂ«m? a Ă«shtĂ« automatizimi i rezervimit? a Ă«shtĂ« pĂ«rdorimi i bibliotekave tĂ« kasetave si direkt, ashtu edhe si njĂ« depo e dytĂ«?â
Nga njĂ«ra anĂ«, PostgreSQL nuk ka mjete tĂ« integruara pĂ«r rezervim, siç janĂ« ato âtĂ« rrituraâ tĂ« SGBD-ve si RMAN pĂ«r Oracle DB ose SAP Database Backup. Nga ana tjetĂ«r, ofruesit e sistemeve korporative tĂ« rezervimit (Veeam, Veritas, Commvault) megjithĂ«se mbĂ«shtesin PostgreSQL, nĂ« tĂ« vĂ«rtetĂ« punojnĂ« vetĂ«m me njĂ« konfiguracion tĂ« caktuar (zakonisht standalone) dhe me njĂ« grup tĂ« ndryshĂ«m kufizimesh.
Sistemet e rezervimit tĂ« dizajnuara posaçërisht pĂ«r PostgreSQL, si Barman, Wal-g, pg_probackup, janĂ« shumĂ« tĂ« njohura nĂ« instalime tĂ« vogla tĂ« SGBD PostgreSQL ose atje ku nuk nevojiten rezervime tĂ« rĂ«nda tĂ« elementeve tĂ« tjera tĂ« peizazhit IT. PĂ«r shembull, pĂ«rveç PostgreSQL, nĂ« infrastrukturĂ« mund tĂ« kenĂ« fizik dhe virtual, OpenShift, Oracle, MariaDB, Cassandra, etj. TĂ« gjitha kĂ«to preferohet tĂ« rezervohen 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 çosh nĂ« kasetĂ«. Ky dyfishim i rezervimeve rrit kohĂ«n e rezervimit dhe, mĂ« kritikisht, kohĂ«n e rikuperimit. serverĂ«t, OpenShift, Oracle, MariaDB, Cassandra etj. TĂ« gjitha kĂ«to preferohet tĂ« rezervohen me njĂ« mjet tĂ« pĂ«rbashkĂ«t. Vendosja e njĂ« zgjidhjeje tĂ« veçantĂ« vetĂ«m pĂ«r PostgreSQL Ă«shtĂ« njĂ« ide e pasuksesshme: tĂ« dhĂ«nat do tĂ« kopjohen diku nĂ« disk, e mĂ« pas do tĂ« duhet tĂ« zhvendosen nĂ« shirit. NjĂ« dyfishim i tillĂ« i kopjeve rezervĂ« rrit kohĂ«n e backup-it dhe, çâĂ«shtĂ« mĂ« kritike, edhe kohĂ«n e rikuperimit.
Në zgjidhjet enterprise, kopjimi i rezervës së instalimit ndodh me një numër nodash që i janë kushtuar një klasteri të dedikuar. Për shembull, Commvault funksionon vetëm me një klaster dy-nodësh, ku Primary dhe Secondary janë të ngjitura fort pas nodave të caktuar. Dhe ka kuptim të bësh backup vetëm nga Primary, sepse kopjimi i rezervës nga Secondary ka kufizimet e veta. Për shkak të veçorive të DBMS-së, dump-i në Secondary nuk krijohet, prandaj mbetet vetëm opsioni i backup-it të skedarëve.
PĂ«r tĂ« ulur rrezikun e ndalesave, gjatĂ« krijimit tĂ« njĂ« sistemi me qĂ«ndrim tĂ« qĂ«ndrueshĂ«m formohet njĂ« konfigurim klaster âtĂ« gjallĂ«â, dhe Primary mund tĂ« migrojĂ« gradualisht midis serverĂ«ve tĂ« ndryshĂ«m. PĂ«r shembull, softueri Patroni 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 kutiaâ, dhe, nĂ«se ndĂ«rlikohet konfigurimi, proceset prishen. Pra, implementimi i menaxhimit tĂ« jashtĂ«m pengon SRK-tĂ« qĂ« tĂ« funksionojnĂ« efikas, sepse serveri menaxhues thjesht nuk kupton se nga ku dhe cilat tĂ« dhĂ«na duhet tĂ« kopjohen.
Një problem tjetër është implementimi i backup-it në Postgres. Ai është i mundur përmes dump-it, dhe në bazat e dhënave të vogla funksionon. Por në BD të mëdha, dump-i bëhet ngadalë, kërkon shumë burime dhe mund të çojë në dështimin e instancës së BD-së.
Backup-i i skedarëve e ndihmon situatën, por në bazat e mëdha ai realizohet ngadalë, sepse funksionon në modin me një thread. Për më tepër, për furnizuesit shfaqen një mori kufizimesh të tjera. Nganjë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. Problematika është e madhe, dhe shpesh herë është më e thjeshtë të zgjidhesh një DBMS të shtrenjtë, por të provuar se sa të përdorësh Postgres.
Nuk ka ku të kthehemi! Pas nesh janë zhvilluesit e Moskës!
Megjithatë, kohët e fundit ekipi ynë u përball me një sfidë të vështirë: në projektin për krijimin e AIS OSAGO 2.0, ku ne po krijonim infrastrukturën IT, zhvilluesit për sistemin e ri zgjodhën PostgreSQL.
PĂ«r zhvilluesit e mĂ«dhenj tĂ« softuerit, Ă«shtĂ« shumĂ« mĂ« e lehtĂ« tĂ« pĂ«rdorin zgjidhje âmoderneâ open-source. NĂ« stafin e Facebook-ut ka mjaft specialistĂ« qĂ« mbĂ«shtesin punĂ«n e kĂ«tij DBMS. NĂ« rastin e RSA, tĂ« gjitha detyrat e âditĂ«s sĂ« dytĂ«â ranĂ« mbi supet tona. Na nevojitej tĂ« siguronim qĂ«ndrueshmĂ«rinĂ«, tĂ« krijonim klasterin dhe, sigurisht, tĂ« rregullonim backup-in. Logjika e veprimit ishte kĂ«shtu:
- TĂ« mĂ«sojmĂ« SRK-nĂ« tĂ« krijojĂ« kopje rezervĂ« nga nodi Kryesor i klasterit. PĂ«r kĂ«tĂ«, SRK-ja duhet ta gjejĂ« atĂ« â kĂ«shtu qĂ« Ă«shtĂ« e nevojshme njĂ« integrim me njĂ« zgjidhje pĂ«r menaxhimin e klasterit PostgreSQL. NĂ« rastin e RSA-s, pĂ«r kĂ«tĂ« ishte pĂ«rdorur software-i Patroni.
- TĂ« pĂ«rcaktojmĂ« llojin e kopjes rezervĂ«, duke u mbĂ«shtetur nĂ« volumin e tĂ« dhĂ«nave dhe kĂ«rkesat pĂ«r rivendosje. PĂ«r shembull, kur kĂ«rkohet rikthimi i faqeve nĂ« mĂ«nyrĂ« granulare, pĂ«rdoret dump-i, dhe nĂ«se bazat janĂ« tĂ« mĂ«dha dhe rikthimi granular nuk nevojitet â punojmĂ« nĂ« nivelin e skedarĂ«ve.
- Të shtojmë në zgjidhje mundësinë e kopjes rezervë bllokuese, që të krijojmë kopje rezervë në mënyrë multi-thread.
Megjithatë, fillimisht ne patëm si qëllim të krijonim një sistem efektiv dhe të thjeshtë pa mbështetje monstruoze nga komponentë të tjerë. Sa më pak mbështetje, aq më pak ngarkesë për stafin dhe rreziku më i ulët i dështimit të SRK-së. Qasjet që përfshinin Veeam dhe RMAN, i përjashtuam menjëherë, sepse kompleti i dy zgjidhjeve sugjeron already një sistem të pasigurt.
Pak magji për enterprise
Pra, na duhej tĂ« garantonim njĂ« kopje rezervĂ« tĂ« besueshme pĂ«r 10 klastera me nga 3 node secili, pĂ«r mĂ« tepĂ«r, nĂ« QendrĂ«n e DhĂ«nash rezervĂ« Ă«shtĂ« ndĂ«rtuar njĂ« infrastrukturĂ« identike. Qendrat e tĂ« DhĂ«nave nĂ« aspektin e PostgreSQL punojnĂ« sipas parimit aktiv-pasiv. VĂ«llimi i pĂ«rgjithshĂ«m i bazave tĂ« tĂ« dhĂ«nave ishte 50 TB. Ădo SRK e nivelit tĂ« korporatave mund ta pĂ«rballojĂ« atĂ« lehtĂ«sisht. Por thelbi Ă«shtĂ« se fillimisht nĂ« Postgres nuk ka asnjĂ« lidhje pĂ«r compatibilitetin e plotĂ« dhe tĂ« thellĂ« me sistemet e kopjes rezervĂ«. Prandaj, na duhej tĂ« kĂ«rkonim njĂ« zgjidhje qĂ« fillimisht kishte maksimumin e funksionalitetit nĂ« lidhje me PostgreSQL, dhe ta pĂ«rmirĂ«sonim sistemin.
Ne organizuam 3 «hackathons» tĂ« brendshĂ«m â shqyrtuam mĂ« shumĂ« se njĂ« gjysmĂ« mĂ« shumĂ« angazhimesh, i testuam ato, bĂ«mĂ« ndryshime sipas hipotezave tona dhe i verifikonim pĂ«rsĂ«ri. Pas analizimit tĂ« opsioneve tĂ« disponueshme, ne zgjodhĂ«m Commvault. Ky produkt mund tĂ« punonte «nga kutia» me njĂ« instalim tĂ« thjeshtĂ« tĂ« klasterit PostgreSQL, dhe arkitektura e tij e hapur krijoi shpresĂ« (e cila u realizua) pĂ«r njĂ« pĂ«rmirĂ«sim dhe integrim tĂ« suksesshĂ«m. Po ashtu, Commvault dinte tĂ« bĂ«nte kopje rezervĂ« tĂ« regjistrimeve tĂ« PostgreSQL. PĂ«r shembull, Veritas NetBackup nĂ« lidhje me PostgreSQL di vetĂ«m tĂ« kryejĂ« kopje rezervĂ« tĂ« plota.
Më shumë mbi arkitekturën. Serverët menaxhues të Commvault janë vendosur në secilën nga dy qendrat e të dhënave në konfigurimin CommServ HA. Sistemi është i miratuar, menaxhohet përmes një konsolë dhe nga pikëpamja e HA përmbush të gjitha kërkesat e ndërmarrjeve.
Po ashtu, në secilën qendër të të dhënave kemi nisur nga dy servera fizikë të mediave, të cilët janë lidhur përmes SAN përmes Fibre Channel me sisteme diskesh dhe biblioteka kasetash të dedikuara veçmas për backup. Bazat e shpërndara të deduplikimit siguruan që media-serverët të ishin të qëndrueshëm ndaj dështimit, dhe lidhja e çdo serveri me çdo CSV mundësoi vazhdimësinë e funksionit në rast se ndonjë komponent dështon. Arkitektura e sistemit lehtëson kopjimin e rezervës, edhe nëse ndonjë nga qendrat e të dhënave dështojnë.
Patroni pĂ«rcakton nodĂ«n kryesore pĂ«r çdo klaster. Ajo mund tĂ« jetĂ« çfarĂ«do nodĂ« tĂ« lirĂ« nĂ« qendrĂ«n e tĂ« dhĂ«nave â por vetĂ«m nĂ« ato kryesore. NĂ« ato rezervĂ«, tĂ« gjitha nodat janĂ« Sekondare.
Që Commvault të kuptonte se cila nodë e klasterit është Kryesore, ne integromë sistemin (falë arkitekturës së hapur të zgjidhjes) me Postgres. Për këtë është krijuar një skenar që njofton për vendndodhjen aktuale të nodës Kryesore menaxhuesin. serverit Commvault.
Në përgjithësi, procesi duket kështu:
Patroni zgjedh Kryesoren â Keepalived ndez IP-klasterin dhe fillon skenarin â agjenti Commvault nĂ« nodĂ«n e zgjedhur tĂ« klasterit merr njoftimin se kjo Ă«shtĂ« Kryesore â Commvault automatikisht rikonfiguron backupin brenda pseudoklientit.
Përparësia e këtij qasjes është se zgjidhja nuk ndikon as në konsistencën, as në korrektësinë e logeve, as në rikuperimin e instancës së Postgres. Ajo gjithashtu lehtësohet për t'u shkallëzuar, pasi tani nuk është e nevojshme të regjistrohen për Commvault nodat Kryesore dhe Sekondare. Mjafton që sistemi të kuptojë se ku është Kryesore dhe numri i nyjeve mund të rritet praktikisht në çdo vlerë.
Zgjidhja nuk pretendon tĂ« jetĂ« e pĂ«rsosur dhe ka nuanca tĂ« saj. Commvault di tĂ« bĂ«jĂ« backup vetĂ«m tĂ« instancĂ«s sĂ« plotĂ«, jo tĂ« bazave tĂ« veçanta. Prandaj pĂ«r çdo DB Ă«shtĂ« krijuar njĂ« instancĂ« tĂ« veçantĂ«. KlientĂ«t e vĂ«rtetĂ« janĂ« tĂ« grupuar nĂ« pseudoklientĂ« virtualĂ«. Ădo pseudoklient Commvault pĂ«rbĂ«n njĂ« klaster UNIX. NĂ« tĂ« shtohen ato nodat e klasterit, mbi tĂ« cilat Ă«shtĂ« instaluar agjenti Commvault pĂ«r Postgres. Si rezultat, tĂ« gjitha nyjat virtuale tĂ« pseudoklientit bĂ«hen backup si njĂ« instancĂ«.
Brenda çdo pseudoklienti Ă«shtĂ« e shĂ«nuar njĂ« nod aktiv tĂ« klasterit. Ky Ă«shtĂ« ai qĂ« zgjidhja jonĂ« integruese pĂ«r Commvault e pĂ«rcakton. Principi i funksionimit tĂ« saj Ă«shtĂ« mjaft i thjeshtĂ«: nĂ«se nĂ« nodĂ« ngrihet njĂ« IP klasteri, skripta vendos nĂ« binarin e agentit Commvault parametrin "nod aktiv" â me tĂ« vĂ«rtetĂ« skripta vendos "1" nĂ« pjesĂ«n e nevojshme tĂ« memories. Agenti i dĂ«rgon kĂ«to tĂ« dhĂ«na nĂ« CommServe dhe Commvault bĂ«n backup nga nodi i nevojshĂ«m. MĂ« tej, nĂ« nivelin e skriptit kontrollohet saktĂ«sia e konfigurimit, duke ndihmuar nĂ« shmangien e gabimeve gjatĂ« lançimit tĂ« kopjimit rezervĂ«.
Në të njëjtën kohë, bazat e mëdha të të dhënave rezervohen në blloqe me disa rrjedha, duke përmbushur kërkesat RPO dhe dritaren e kopjimit rezervë. Ngarkesa në sistem është e pakët: kopjet e plota nuk ndodhin shpesh, në ditët e tjera mblidhen vetëm loge, për më tepër në periudhat e ngarkesës së ulët.
Tani, ne kemi aplikuar politika tĂ« veçanta pĂ«r kopjimin e log-eve arkivore tĂ« PostgreSQL â ato ruhen sipas rregullave tĂ« tjera, kopjohen sipas njĂ« orari tĂ« ndryshĂ«m dhe pĂ«r to nuk aktivizohet deduplikimi, pasi kĂ«to loge mbajnĂ« tĂ« dhĂ«na unike.
Për të siguruar konsistencën e tërë infrastrukturës IT, klientë të veçantë të Commvault janë instaluar në çdo nod të klasterit. Ata përjashtojnë nga kopjet rezervë skedarët Postgres dhe janë të dedikuar vetëm për backup të OS-së dhe aplikacioneve. Për këtë pjesë të të dhënave është parashikuar gjithashtu një politikë e saj, dhe një periudhë ruajtjeje.
Aktualisht SRK nuk ndikon në shërbimet prodhuese, por nëse situata ndryshon, në Commvault mund të aktivizohet sistemi për kufizimin e ngarkesës.
ĂshtĂ« nĂ« rregull? ĂshtĂ« nĂ« rregull!
Pra, ne kemi marrë jo vetëm një backup funksional, por gjithashtu një backup të plotë të automatizuar për instalimin e klasterit PostgreSQL, për më tepër që i përmbush të gjitha kërkesat për sfidat enterprise.
Parametrat RPO dhe RTO në 1 orë dhe 2 orë janë mbuluar me një rezerva, prandaj sistemi do të përmbushë ato edhe në rritjen e konsiderueshme të volumit të të dhënave të ruajtura. Pavarësisht nga shumë dyshime, PostgreSQL dhe ambienti enterprise rezultuan të jenë të përputhshëm. Dhe tani ne nga eksperienca jona dimë se backup-i për të tilla DBMS është i mundur në konfiguracione shumë të ndryshme.
Sigurisht, në këtë rrugë na duhej të konsumonim shtatë palë çizme hekuri, të kalonim një sërë vështirësish, të hidheshim mbi disa gure dhe të korrigjonim një sasi të caktuar gabimesh. Por tani metoda tashmë është provuar dhe mund të aplikohet për implementimin e Open Source në vend të DBMS-ve pronësor në kushtet e ashpra të enterprise.
A e keni provuar të punoni me PostgreSQL në një mjedis të korporatës?
Autorët:
Oleg Lavrenov, inxhinier i sistemit të projektimit të ruajtjes së të dhënave «Infosisitemes Jet»
Dmitry Yerikin, inxhinier i projektimit të komplekseve kompjuterike «Infosisitemes Jet»
Burimi: habr.com
