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 и т.д. Всё это желательно бэкапить общим инструментом. Ставить отдельное решение исключительно для PostgreSQL— неудачная затея: данные будут копироваться куда-то на диск, а потом их нужно убирать на ленту. Такое задвоение резервного копирования увеличивает время бэкапа, а также, что более критично, — восстановления.
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. серверу 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
