Mnoho ľudí pozná PostgreSQL DBMS a osvedčilo sa v malých inštaláciách. Trend smerom k Open Source je však čoraz zreteľnejší, aj keď ide o veľké spoločnosti a podnikové požiadavky. V tomto článku vám povieme, ako integrovať Postgres do podnikového prostredia a podelíme sa o naše skúsenosti s vytvorením záložného systému (BSS) pre túto databázu pomocou záložného systému Commvault ako príkladu.
PostgreSQL sa už osvedčil – DBMS funguje skvele, používajú ho módne digitálne podniky ako Alibaba a TripAdvisor a chýbajúce licenčné poplatky z neho robia lákavú alternatívu k takým monštrám ako MS SQL alebo Oracle DB. Akonáhle však začneme premýšľať o PostgreSQL v prostredí Enterprise, okamžite narazíme na prísne požiadavky: „A čo odolnosť proti chybám konfigurácie? odolnosť voči katastrofám? kde je komplexný monitoring? A čo automatické zálohovanie? A čo používanie páskových knižníc priamo aj na sekundárnom úložisku?
Na jednej strane PostgreSQL nemá vstavané nástroje na zálohovanie, ako sú „dospelé“ DBMS, ako napríklad RMAN v Oracle DB alebo SAP Database Backup. Na druhej strane dodávatelia firemných zálohovacích systémov (Veeam, Veritas, Commvault) síce podporujú PostgreSQL, ale v skutočnosti pracujú len s určitou (zvyčajne samostatnou) konfiguráciou a súborom rôznych obmedzení.
Záložné systémy špeciálne navrhnuté pre PostgreSQL, ako sú Barman, Wal-g, pg_probackup, sú mimoriadne obľúbené v malých inštaláciách PostgreSQL DBMS alebo tam, kde nie sú potrebné veľké zálohy iných prvkov IT prostredia. Napríklad okrem PostgreSQL môže infraštruktúra zahŕňať fyzické a virtuálne servery, OpenShift, Oracle, MariaDB, Cassandra atď. Toto všetko je vhodné zálohovať bežným nástrojom. Inštalácia samostatného riešenia výhradne pre PostgreSQL je zlý nápad: údaje sa skopírujú niekde na disk a potom sa musia odstrániť na pásku. Táto dvojitá záloha zvyšuje čas zálohovania a, čo je ešte dôležitejšie, čas obnovy.
V podnikovom riešení sa záloha inštalácie uskutočňuje s určitým počtom uzlov vo vyhradenom klastri. Zároveň napríklad Commvault dokáže pracovať len s dvojuzlovým klastrom, v ktorom sú primárne a sekundárne striktne priradené k určitým uzlom. A má zmysel zálohovať iba z Primárneho, pretože zálohovanie zo sekundárneho má svoje obmedzenia. Kvôli zvláštnostiam DBMS sa nevytvára výpis na sekundárnom, a preto zostáva len možnosť zálohy súboru.
Aby sa znížilo riziko výpadkov, pri vytváraní systému odolného voči chybám sa vytvorí „živá“ konfigurácia klastra a Primárny môže postupne migrovať medzi rôznymi servermi. Napríklad samotný softvér Patroni spustí Primary na náhodne vybranom uzle klastra. IBS to nemá ako sledovať hneď po vybalení a ak sa konfigurácia zmení, procesy sa prerušia. To znamená, že zavedenie externej kontroly bráni efektívnemu fungovaniu ISR, pretože riadiaci server jednoducho nerozumie, odkiaľ a aké údaje je potrebné skopírovať.
Ďalším problémom je implementácia zálohovania v Postgrese. Je to možné cez výpis a funguje to na malých databázach. Vo veľkých databázach však výpis trvá dlho, vyžaduje veľa zdrojov a môže viesť k zlyhaniu inštancie databázy.
Zálohovanie súborov situáciu napravuje, ale na veľkých databázach je pomalé, pretože funguje v režime s jedným vláknom. Okrem toho majú predajcovia množstvo dodatočných obmedzení. Buď nemôžete používať zálohy súborov a výpisov súčasne, alebo deduplikácia nie je podporovaná. Problémov je veľa a najčastejšie je jednoduchšie vybrať si drahý, ale overený DBMS namiesto Postgresu.
Nie je kam ustúpiť! Moskovskí vývojári sú pozadu!
Nedávno však náš tím čelil neľahkej výzve: v projekte vytvorenia AIS OSAGO 2.0, kde sme vytvárali IT infraštruktúru, si vývojári vybrali pre nový systém PostgreSQL.
Pre veľkých vývojárov softvéru je oveľa jednoduchšie používať „trendové“ open-source riešenia. Facebook má dostatok špecialistov na podporu fungovania tohto DBMS. A v prípade RSA padli všetky úlohy „druhého dňa“ na naše plecia. Boli sme povinní zabezpečiť odolnosť voči chybám, zostaviť klaster a samozrejme nastaviť zálohovanie. Logika konania bola nasledovná:
- Naučte SRK vytvárať zálohy z primárneho uzla klastra. Na to ho musí SRK nájsť – čo znamená, že je potrebná integrácia s jedným alebo druhým riešením správy klastrov PostgreSQL. V prípade RSA bol na to použitý softvér Patroni.
- Rozhodnite sa o type zálohy na základe objemu údajov a požiadaviek na obnovu. Napríklad, keď potrebujete obnoviť stránky podrobne, použite výpis a ak sú databázy veľké a nevyžaduje sa podrobné obnovenie, pracujte na úrovni súboru.
- Pripojte k riešeniu možnosť blokového zálohovania na vytvorenie záložnej kópie vo viacvláknovom režime.
Zároveň sme sa pôvodne rozhodli vytvoriť efektívny a jednoduchý systém bez monštruózneho zväzku ďalších komponentov. Čím menej barlí, tým menšie zaťaženie personálu a nižšie riziko zlyhania IBS. Okamžite sme vylúčili prístupy, ktoré používali Veeam a RMAN, pretože súbor dvoch riešení už naznačuje nespoľahlivosť systému.
Malé kúzlo pre podnikanie
Potrebovali sme teda zaručiť spoľahlivé zálohovanie pre 10 klastrov, každý s 3 uzlami, s rovnakou infraštruktúrou zrkadlenou v záložnom dátovom centre. Dátové centrá v zmysle PostgreSQL fungujú na aktívno-pasívnom princípe. Celková veľkosť databázy bola 50 TB. Každý riadiaci systém na podnikovej úrovni si s tým ľahko poradí. Varovanie však spočíva v tom, že Postgres spočiatku nemá potuchy o úplnej a hlbokej kompatibilite so záložnými systémami. Preto sme museli hľadať riešenie, ktoré malo spočiatku maximálnu funkčnosť v spojení s PostgreSQL a systém vylepšiť.
Uskutočnili sme 3 interné „hackathony“ – pozreli sme si viac ako päťdesiat vývojov, otestovali ich, urobili zmeny v súvislosti s našimi hypotézami a znova ich otestovali. Po preskúmaní dostupných možností sme si vybrali Commvault. Po vybalení by tento produkt mohol pracovať s najjednoduchšou inštaláciou klastra PostgreSQL a jeho otvorená architektúra vzbudzovala nádeje (ktoré boli oprávnené) na úspešný vývoj a integráciu. Commvault môže tiež zálohovať denníky PostgreSQL. Napríklad Veritas NetBackup v zmysle PostgreSQL môže robiť iba úplné zálohy.
Viac o architektúre. Servery na správu Commvault boli nainštalované v každom z dvoch dátových centier v konfigurácii CommServ HA. Systém je zrkadlený, spravovaný cez jednu konzolu a z pohľadu HA spĺňa všetky podnikové požiadavky.
V každom dátovom centre sme spustili aj dva fyzické mediálne servery, ku ktorým sme pripojili diskové polia a páskové knižnice určené špeciálne na zálohovanie cez SAN cez Fibre Channel. Rozšírené deduplikačné databázy zaisťovali odolnosť mediálnych serverov voči chybám a pripojenie každého servera ku každému CSV umožnilo nepretržitú prevádzku, ak niektorý komponent zlyhal. Architektúra systému umožňuje pokračovať v zálohovaní, aj keď jedno z dátových centier spadne.
Patroni definuje primárny uzol pre každý klaster. Môže to byť akýkoľvek voľný uzol v dátovom centre – ale len väčšinou. V zálohe sú všetky uzly sekundárne.
Aby Commvault pochopil, ktorý uzol klastra je primárny, integrovali sme systém (vďaka otvorenej architektúre riešenia) s Postgres. Na tento účel bol vytvorený skript, ktorý oznamuje aktuálne umiestnenie primárneho uzla riadiacemu serveru Commvault.
Vo všeobecnosti proces vyzerá takto:
Patroni vyberie Primárny → Keepalived vyberie klaster IP a spustí skript → Agent Commvault na vybranom uzle klastra dostane upozornenie, že ide o Primárny → Commvault automaticky prekonfiguruje zálohu v rámci pseudoklienta.
Výhodou tohto prístupu je, že riešenie neovplyvňuje konzistenciu, správnosť logov ani obnovu inštancie Postgres. Je tiež ľahko škálovateľný, pretože už nie je potrebné opravovať primárne a sekundárne uzly Commvault. Stačí, aby systém pochopil, kde je Primary, a počet uzlov môže byť zvýšený na takmer akúkoľvek hodnotu.
Riešenie sa netvári ako ideálne a má svoje nuansy. Commvault môže zálohovať iba celú inštanciu a nie jednotlivé databázy. Preto bola pre každú databázu vytvorená samostatná inštancia. Skutoční klienti sa spájajú do virtuálnych pseudoklientov. Každý pseudo-klient Commvault je klaster UNIX. Tie uzly klastra, na ktorých je nainštalovaný agent Commvault pre Postgres, sa doň pridajú. Výsledkom je, že všetky virtuálne uzly pseudoklienta sú zálohované ako jedna inštancia.
V rámci každého pseudoklienta je označený aktívny uzol klastra. Toto definuje naše integračné riešenie pre Commvault. Princíp jeho fungovania je pomerne jednoduchý: ak sa na uzle zvýši IP klastra, skript nastaví parameter „aktívny uzol“ v binárnom kóde agenta Commvault – v skutočnosti skript nastaví „1“ do požadovanej časti pamäte. . Agent odošle tieto údaje do CommServe a Commvault vytvorí zálohu z požadovaného uzla. Okrem toho sa správnosť konfigurácie kontroluje na úrovni skriptu, čo pomáha predchádzať chybám pri spúšťaní zálohy.
Zároveň sú veľké databázy zálohované v blokoch naprieč viacerými vláknami, čím spĺňajú požiadavky RPO a zálohovacieho okna. Zaťaženie systému je zanedbateľné: Úplné kópie sa nevyskytujú tak často, v iné dni sa zbierajú iba protokoly a počas období nízkej záťaže.
Mimochodom, na zálohovanie archívov PostgreSQL sme aplikovali samostatné pravidlá - sú uložené podľa iných pravidiel, kopírujú sa podľa iného plánu a nie je pre ne povolená deduplikácia, keďže tieto záznamy obsahujú jedinečné údaje.
Na zabezpečenie konzistentnosti v celej IT infraštruktúre sú na každý z klastrových uzlov nainštalovaní oddelení súboroví klienti Commvault. Vylučujú Postgres súbory zo záloh a sú určené len na zálohovanie OS a aplikácií. Táto časť údajov má tiež svoju vlastnú politiku a dobu uchovávania.
V súčasnosti IBS neovplyvňuje služby produktivity, ale ak sa situácia zmení, Commvault môže povoliť obmedzenie zaťaženia.
Je to dobré? Dobre!
Dostali sme teda nielen funkčnú, ale aj plne automatizovanú zálohu pre inštaláciu klastra PostgreSQL, ktorá spĺňa všetky požiadavky na podnikové hovory.
Parametre RPO a RTO 1 hodina a 2 hodiny sú kryté rezervou, čo znamená, že ich systém dodrží aj pri výraznom náraste objemu uložených dát. Napriek mnohým pochybnostiam sa PostgreSQL a podnikové prostredie ukázali ako celkom kompatibilné. A teraz z vlastnej skúsenosti vieme, že zálohovanie pre takéto DBMS je možné v širokej škále konfigurácií.
Samozrejme, na tejto ceste sme museli opotrebovať sedem párov železných čižiem, prekonať množstvo ťažkostí, vyšliapať niekoľko hrablí a opraviť množstvo chýb. Teraz je však tento prístup už otestovaný a možno ho použiť na implementáciu Open Source namiesto proprietárneho DBMS v náročných podnikových podmienkach.
Vyskúšali ste si prácu s PostgreSQL vo firemnom prostredí?
Autori:
Oleg Lavrenov, konštruktér systémov na ukladanie dát, Jet Infosystems
Dmitrij Erykin, konštruktér počítačových systémov v Jet Infosystems
Zdroj: hab.com