Shumë njerëz janë të njohur me PostgreSQL DBMS, dhe ai e ka provuar veten në instalime të vogla. Megjithatë, tendenca drejt Open Source është bërë gjithnjë e më e qartë, edhe kur bëhet fjalë për kompanitë e mëdha dhe kërkesat e ndërmarrjeve. Në këtë artikull ne do t'ju tregojmë se si të integroni Postgres në një mjedis të korporatës dhe të ndajmë përvojën tonë për krijimin e një sistemi rezervë (BSS) për këtë bazë të dhënash duke përdorur si shembull sistemin rezervë Commvault.
PostgreSQL e ka dëshmuar tashmë vlerën e tij - DBMS funksionon shkëlqyeshëm, përdoret nga bizneset dixhitale në modë si Alibaba dhe TripAdvisor, dhe mungesa e tarifave të licencimit e bën atë një alternativë joshëse ndaj përbindëshave të tillë si MS SQL ose Oracle DB. Por, sapo fillojmë të mendojmë për PostgreSQL në peizazhin e Ndërmarrjeve, menjëherë hasim kërkesa strikte: “Po toleranca e gabimeve të konfigurimit? rezistencë ndaj fatkeqësive? ku është monitorimi gjithëpërfshirës? Po në lidhje me rezervimet e automatizuara? Po në lidhje me përdorimin e bibliotekave të shiritit si drejtpërdrejt ashtu edhe në ruajtje dytësore?”
Nga njëra anë, PostgreSQL nuk ka mjete rezervë të integruar, si DBMS-të "të rritura", si RMAN në Oracle DB ose SAP Database Backup. Nga ana tjetër, furnizuesit e sistemeve rezervë të korporatave (Veeam, Veritas, Commvault) megjithëse mbështesin PostgreSQL, në fakt ata punojnë vetëm me një konfigurim të caktuar (zakonisht të pavarur) dhe me një sërë kufizimesh të ndryshme.
Sistemet rezervë të krijuara posaçërisht për PostgreSQL, të tilla si Barman, Wal-g, pg_probackup, janë jashtëzakonisht të njohura në instalimet e vogla të PostgreSQL DBMS ose ku nuk nevojiten kopje rezervë të rëndë të elementeve të tjerë të peizazhit të IT. Për shembull, përveç PostgreSQL, infrastruktura mund të përfshijë serverë fizikë dhe virtualë, OpenShift, Oracle, MariaDB, Cassandra, etj. Këshillohet që të kopjoni të gjitha këto me një mjet të përbashkët. Instalimi i një zgjidhjeje të veçantë ekskluzivisht për PostgreSQL është një ide e keqe: të dhënat do të kopjohen diku në disk dhe më pas duhet të hiqen në kasetë. Ky kopje rezervë e dyfishtë rrit kohën e rezervimit, dhe gjithashtu, në mënyrë më kritike, kohën e rikuperimit.
Në një zgjidhje të ndërmarrjes, rezervimi i instalimit ndodh me një numër të caktuar nyjesh në një grup të dedikuar. Në të njëjtën kohë, për shembull, Commvault mund të punojë vetëm me një grup me dy nyje, në të cilin Primar dhe Sekondar janë caktuar rreptësisht për nyje të caktuara. Dhe ka kuptim vetëm të bëni kopje rezervë nga Primar, sepse rezervimi nga Sekondari ka kufizimet e veta. Për shkak të veçorive të DBMS, një hale nuk krijohet në Sekondar, dhe për këtë arsye mbetet vetëm mundësia e një kopje rezervë të skedarit.
Për të zvogëluar rrezikun e ndërprerjes, kur krijohet një sistem tolerant ndaj gabimeve, krijohet një konfigurim "live" i grupit dhe Primar mund të migrojë gradualisht midis serverëve të ndryshëm. Për shembull, vetë softueri Patroni lëshon Primary në një nyje grupi të zgjedhur rastësisht. IBS nuk ka asnjë mënyrë për ta gjurmuar këtë jashtë kutisë, dhe nëse konfigurimi ndryshon, proceset prishen. Kjo do të thotë, futja e kontrollit të jashtëm parandalon që ISR të funksionojë në mënyrë efektive, sepse serveri i kontrollit thjesht nuk e kupton se nga dhe nga cilat të dhëna duhet të kopjohen.
Një problem tjetër është zbatimi i kopjimit në Postgres. Është e mundur përmes hale, dhe funksionon në baza të të dhënave të vogla. Por në bazat e të dhënave të mëdha, deponimi kërkon një kohë të gjatë, kërkon shumë burime dhe mund të çojë në dështimin e shembullit të bazës së të dhënave.
Rezervimi i skedarit korrigjon situatën, por në bazat e të dhënave të mëdha është i ngadalshëm sepse funksionon në modalitetin me një fije. Për më tepër, shitësit kanë një numër kufizimesh shtesë. Ose nuk mund të përdorni kopje rezervë të skedarëve dhe skedarëve në të njëjtën kohë, ose nuk mbështetet dublikimi. Ka shumë probleme, dhe më shpesh është më e lehtë të zgjidhni një DBMS të shtrenjtë, por të provuar në vend të Postgres.
Nuk ka ku të tërhiqet! Zhvilluesit e Moskës janë prapa!
Megjithatë, kohët e fundit ekipi ynë u përball me një sfidë të vështirë: në projektin për të krijuar AIS OSAGO 2.0, ku krijuam infrastrukturën e TI-së, zhvilluesit zgjodhën PostgreSQL për sistemin e ri.
Është shumë më e lehtë për zhvilluesit e mëdhenj të softuerit të përdorin zgjidhje "të modës" me burim të hapur. Facebook ka mjaft specialistë për të mbështetur funksionimin e kësaj DBMS. Dhe në rastin e RSA, të gjitha detyrat e "ditës së dytë" ranë mbi supet tona. Na kërkuan të siguronim tolerancën e gabimeve, të mblidhnim një grup dhe, natyrisht, të krijonim kopje rezervë. Logjika e veprimit ishte si më poshtë:
- Mësoni SRK-në të bëjë kopje rezervë nga nyja kryesore e grupimit. Për ta bërë këtë, SRK duhet ta gjejë atë - që do të thotë se nevojitet integrimi me një ose një zgjidhje tjetër të menaxhimit të grupimeve PostgreSQL. Në rastin e RSA, softueri Patroni është përdorur për këtë.
- Vendosni për llojin e rezervës bazuar në vëllimin e të dhënave dhe kërkesat e rikuperimit. Për shembull, kur ju duhet të rivendosni faqet në mënyrë të grimcuar, përdorni një deponim dhe nëse bazat e të dhënave janë të mëdha dhe nuk kërkohet restaurimi i grimcuar, punoni në nivelin e skedarit.
- Bashkangjisni mundësinë e kopjimit të bllokut në zgjidhje për të krijuar një kopje rezervë në modalitetin me shumë fije.
Në të njëjtën kohë, ne fillimisht vendosëm të krijonim një sistem efektiv dhe të thjeshtë pa një parzmore monstruoze të komponentëve shtesë. Sa më pak paterica, aq më pak ngarkesë pune për personelin dhe aq më i ulët është rreziku i dështimit të IBS. Ne përjashtuam menjëherë qasjet që përdorën Veeam dhe RMAN, sepse një grup prej dy zgjidhjesh tashmë lë të kuptohet për mosbesueshmërinë e sistemit.
Pak magji për sipërmarrjen
Pra, na duhej të garantonim kopje rezervë të besueshme për 10 grupe me 3 nyje secila, me të njëjtën infrastrukturë të pasqyruar në qendrën e të dhënave rezervë. Qendrat e të dhënave për sa i përket PostgreSQL punojnë në parimin aktiv-pasiv. Madhësia totale e bazës së të dhënave ishte 50 TB. Çdo sistem kontrolli i nivelit të korporatës mund ta përballojë lehtësisht këtë. Por paralajmërimi është se fillimisht Postgres nuk ka një të dhënë për pajtueshmërinë e plotë dhe të thellë me sistemet rezervë. Prandaj, na u desh të kërkonim një zgjidhje që fillimisht kishte funksionalitet maksimal në lidhje me PostgreSQL dhe të përsosim sistemin.
Ne mbajtëm 3 "hackathone" të brendshme - shikuam më shumë se pesëdhjetë zhvillime, i testuam ato, bëmë ndryshime në lidhje me hipotezat tona dhe i testuam përsëri. Pas shqyrtimit të opsioneve të disponueshme, ne zgjodhëm Commvault. Nga kutia, ky produkt mund të funksiononte me instalimin më të thjeshtë të grupit PostgreSQL dhe arkitektura e tij e hapur ngriti shpresat (të cilat u justifikuan) për zhvillim dhe integrim të suksesshëm. Commvault gjithashtu mund të rezervojë regjistrat e PostgreSQL. Për shembull, Veritas NetBackup për sa i përket PostgreSQL mund të bëjë vetëm kopje rezervë të plotë.
Më shumë rreth arkitekturës. Serverët e menaxhimit Commvault u instaluan në secilën nga dy qendrat e të dhënave në një konfigurim CommServ HA. Sistemi pasqyrohet, menaxhohet përmes një tastierë dhe, nga pikëpamja HA, plotëson të gjitha kërkesat e ndërmarrjes.
Ne gjithashtu lançuam dy serverë të mediave fizike në secilën qendër të të dhënave, me të cilët lidhëm vargje disqesh dhe biblioteka shiritash të dedikuara posaçërisht për kopje rezervë përmes SAN-it nëpërmjet Fiber Channel. Bazat e të dhënave të zgjeruara të dedulikimit siguruan tolerancë ndaj gabimeve të serverëve të medias dhe lidhja e secilit server me çdo CSV mundësoi funksionimin e vazhdueshëm nëse ndonjë komponent dështonte. Arkitektura e sistemit lejon që kopjimi të vazhdojë edhe nëse një nga qendrat e të dhënave bie.
Patroni përcakton një nyje primare për çdo grup. Mund të jetë çdo nyje e lirë në qendrën e të dhënave - por vetëm kryesisht. Në rezervë, të gjitha nyjet janë Sekondare.
Në mënyrë që Commvault të kuptojë se cila nyje e grupit është Primar, ne kemi integruar sistemin (në sajë të arkitekturës së hapur të zgjidhjes) me Postgres. Për këtë qëllim, u krijua një skript që raporton vendndodhjen aktuale të nyjes Primar në serverin e menaxhimit Commvault.
Në përgjithësi, procesi duket si ky:
Patroni zgjedh Primary → Keepalived merr grupin IP dhe ekzekuton skriptin → agjenti Commvault në nyjen e grupit të zgjedhur merr një njoftim se kjo është Primary → Commvault rikonfiguron automatikisht kopjen rezervë brenda pseudo-klientit.
Avantazhi i kësaj qasjeje është se zgjidhja nuk ndikon në qëndrueshmërinë, korrektësinë e regjistrave ose rikuperimin e shembullit Postgres. Është gjithashtu lehtësisht i shkallëzueshëm, sepse nuk është më e nevojshme të rregullohen nyjet primare dhe sekondare Commvault. Mjafton që sistemi të kuptojë se ku është Primar dhe numri i nyjeve mund të rritet në pothuajse çdo vlerë.
Zgjidhja nuk pretendon të jetë ideale dhe ka nuancat e veta. Commvault mund të kopjojë vetëm të gjithë shembullin, dhe jo bazat e të dhënave individuale. Prandaj, u krijua një shembull i veçantë për secilën bazë të dhënash. Klientët realë kombinohen në pseudo-klientë virtualë. Çdo pseudo-klient Commvault është një grup UNIX. Ato nyje grupore në të cilat është instaluar agjenti Commvault për Postgres janë shtuar në të. Si rezultat, të gjitha nyjet virtuale të pseudo-klientit rezervohen si një shembull.
Brenda çdo pseudo-klienti, tregohet nyja aktive e grupit. Kjo është ajo që përcakton zgjidhja jonë e integrimit për Commvault. Parimi i funksionimit të tij është mjaft i thjeshtë: nëse një IP grupi ngrihet në një nyje, skripti vendos parametrin "nyja aktive" në binarin e agjentit Commvault - në fakt, skripti vendos "1" në pjesën e kërkuar të memories. . Agjenti i transmeton këto të dhëna në CommServe dhe Commvault bën një kopje rezervë nga nyja e dëshiruar. Për më tepër, korrektësia e konfigurimit kontrollohet në nivelin e skriptit, duke ndihmuar në shmangien e gabimeve kur filloni një kopje rezervë.
Në të njëjtën kohë, bazat e të dhënave të mëdha rezervohen në blloqe nëpër fije të shumta, duke përmbushur kërkesat e RPO dhe dritares rezervë. Ngarkesa në sistem është e parëndësishme: Kopjet e plota nuk ndodhin aq shpesh, në ditët e tjera mblidhen vetëm regjistrat dhe gjatë periudhave me ngarkesë të ulët.
Meqë ra fjala, ne kemi aplikuar politika të veçanta për rezervimin e regjistrave të arkivit PostgreSQL - ato ruhen sipas rregullave të ndryshme, kopjohen sipas një orari të ndryshëm dhe deduifikimi nuk është i aktivizuar për ta, pasi këto regjistra përmbajnë të dhëna unike.
Për të siguruar qëndrueshmëri në të gjithë infrastrukturën e TI-së, klientë të veçantë të skedarëve Commvault janë instaluar në secilën prej nyjeve të grupimit. Ato përjashtojnë skedarët Postgres nga kopjet rezervë dhe janë të destinuara vetëm për kopje rezervë të OS dhe aplikacioneve. Kjo pjesë e të dhënave ka gjithashtu politikën e vet dhe periudhën e ruajtjes.
Aktualisht, IBS nuk ndikon në shërbimet e produktivitetit, por nëse situata ndryshon, Commvault mund të mundësojë kufizimin e ngarkesës.
A është mirë? Mirë!
Pra, ne kemi marrë jo vetëm një kopje rezervë të zbatueshme, por edhe plotësisht të automatizuar për një instalim grupi PostgreSQL, dhe ai plotëson të gjitha kërkesat për thirrjet e ndërmarrjeve.
Parametrat RPO dhe RTO prej 1 orë dhe 2 orë janë të mbuluara me një diferencë, që do të thotë se sistemi do të përputhet me to edhe me një rritje të konsiderueshme të vëllimit të të dhënave të ruajtura. Ndryshe nga shumë dyshime, PostgreSQL dhe mjedisi i ndërmarrjes doli të ishin mjaft të pajtueshëm. Dhe tani ne e dimë nga përvoja jonë se rezervimi për DBMS të tilla është i mundur në një shumëllojshmëri të gjerë konfigurimesh.
Natyrisht, gjatë kësaj rruge na u desh të vishnim shtatë palë çizme hekuri, të kapërcejmë një sërë vështirësish, të shkelnim disa grabujë dhe të korrigjonim një sërë gabimesh. Por tani qasja tashmë është testuar dhe mund të përdoret për të zbatuar Open Source në vend të DBMS të pronarit në kushte të vështira të ndërmarrjes.
A keni provuar të punoni me PostgreSQL në një mjedis korporativ?
Autorët:
Oleg Lavrenov, inxhinier projektues i sistemeve të ruajtjes së të dhënave, Jet Infosystems
Dmitry Erykin, inxhinier projektues i sistemeve kompjuterike në Jet Infosystems
Burimi: www.habr.com