Mnoho lidí zná PostgreSQL DBMS a osvědčil se v malých instalacích. Trend směrem k Open Source je však stále zřetelnější, i když jde o velké společnosti a podnikové požadavky. V tomto článku vám řekneme, jak integrovat Postgres do podnikového prostředí a podělíme se o naše zkušenosti s vytvořením zálohovacího systému (BSS) pro tuto databázi na příkladu zálohovacího systému Commvault.
PostgreSQL se již osvědčil – DBMS funguje skvěle, používají jej módní digitální podniky jako Alibaba a TripAdvisor a absence licenčních poplatků z něj dělá lákavou alternativu k takovým monstrům, jako je MS SQL nebo Oracle DB. Ale jakmile začneme přemýšlet o PostgreSQL v prostředí Enterprise, okamžitě narazíme na přísné požadavky: „A co odolnost proti chybám konfigurace? odolnost proti katastrofám? kde je komplexní monitoring? A co automatické zálohování? A co použití páskových knihoven přímo i na sekundárním úložišti?
Na jedné straně PostgreSQL nemá vestavěné nástroje pro zálohování, jako jsou „dospělé“ DBMS, jako je RMAN v Oracle DB nebo SAP Database Backup. Na druhou stranu dodavatelé podnikových zálohovacích systémů (Veeam, Veritas, Commvault) sice PostgreSQL podporují, ale ve skutečnosti pracují pouze s určitou (obvykle samostatnou) konfigurací a sadou různých omezení.
Záložní systémy speciálně navržené pro PostgreSQL, jako jsou Barman, Wal-g, pg_probackup, jsou extrémně oblíbené v malých instalacích PostgreSQL DBMS nebo tam, kde není potřeba těžké zálohování jiných prvků IT prostředí. Například kromě PostgreSQL může infrastruktura zahrnovat fyzické a virtuální servery, OpenShift, Oracle, MariaDB, Cassandra atd. To vše je vhodné zálohovat běžným nástrojem. Instalace samostatného řešení výhradně pro PostgreSQL je špatný nápad: data se zkopírují někam na disk a pak je třeba je odstranit na pásku. Tato dvojitá záloha prodlužuje dobu zálohování a také, což je důležitější, dobu obnovy.
V podnikovém řešení dochází k zálohování instalace s určitým počtem uzlů ve vyhrazeném clusteru. Přitom například Commvault umí pracovat pouze s dvouuzlovým clusterem, ve kterém jsou primární a sekundární striktně přiřazeny k určitým uzlům. A má smysl zálohovat pouze z Primárního, protože zálohování z Sekundárního má svá omezení. Vzhledem ke zvláštnostem DBMS se nevytváří výpis na Sekundární, a proto zůstává pouze možnost zálohy souborů.
Aby se snížilo riziko výpadků, při vytváření systému odolného proti chybám se vytvoří „živá“ konfigurace clusteru a Primární může postupně migrovat mezi různými servery. Například samotný software Patroni spouští Primární na náhodně vybraném uzlu clusteru. IBS nemá žádný způsob, jak to po vybalení sledovat, a pokud se konfigurace změní, procesy se přeruší. To znamená, že zavedení externí kontroly brání efektivnímu fungování ISR, protože řídicí server prostě nerozumí, odkud a jaká data je třeba kopírovat.
Dalším problémem je implementace zálohování v Postgresu. Je to možné přes výpis a funguje to na malých databázích. Ve velkých databázích však výpis trvá dlouho, vyžaduje mnoho zdrojů a může vést k selhání instance databáze.
Zálohování souborů situaci napravuje, ale na velkých databázích je pomalé, protože funguje v režimu s jedním vláknem. Kromě toho mají prodejci řadu dalších omezení. Buď nemůžete používat zálohy souborů a výpisů současně, nebo deduplikace není podporována. Problémů je mnoho a nejčastěji je jednodušší zvolit místo Postgresu drahý, ale osvědčený DBMS.
Není kam ustoupit! Moskevští vývojáři jsou pozadu!
Nedávno však náš tým čelil obtížné výzvě: v projektu vytvoření AIS OSAGO 2.0, kde jsme vytvářeli IT infrastrukturu, zvolili vývojáři pro nový systém PostgreSQL.
Pro velké softwarové vývojáře je mnohem jednodušší používat „trendy“ open-source řešení. Facebook má dostatek specialistů na podporu fungování tohoto DBMS. A v případě RSA padly všechny úkoly „druhého dne“ na naše bedra. Měli jsme zajistit odolnost proti chybám, sestavit cluster a samozřejmě nastavit zálohování. Logika jednání byla následující:
- Naučte SRK vytvářet zálohy z primárního uzlu clusteru. K tomu jej musí SRK najít – což znamená, že je nutná integrace s jedním či druhým řešením správy clusteru PostgreSQL. V případě RSA k tomu posloužil software Patroni.
- Rozhodněte se o typu zálohy na základě objemu dat a požadavků na obnovu. Pokud například potřebujete obnovit stránky podrobně, použijte výpis a pokud jsou databáze velké a podrobné obnovení není vyžadováno, pracujte na úrovni souboru.
- Připojte k řešení možnost blokového zálohování a vytvořte záložní kopii ve vícevláknovém režimu.
Zároveň jsme se zpočátku rozhodli vytvořit efektivní a jednoduchý systém bez monstrózního svazku dalších komponent. Čím méně berliček, tím menší zátěž personálu a tím nižší riziko selhání IBS. Okamžitě jsme vyloučili přístupy, které využívaly Veeam a RMAN, protože soubor dvou řešení již naznačuje nespolehlivost systému.
Malé kouzlo pro podnikání
Potřebovali jsme tedy zaručit spolehlivé zálohování pro 10 clusterů po 3 uzlech, se stejnou infrastrukturou zrcadlenou v zálohovacím datovém centru. Datová centra v rámci PostgreSQL fungují na aktivním-pasivním principu. Celková velikost databáze byla 50 TB. S tím si snadno poradí jakýkoli řídicí systém na podnikové úrovni. Ale varováním je, že zpočátku Postgres nemá ponětí o plné a hluboké kompatibilitě se záložními systémy. Museli jsme proto hledat řešení, které mělo zpočátku maximální funkčnost ve spojení s PostgreSQL, a systém vylepšovat.
Uspořádali jsme 3 interní „hackathony“ – podívali jsme se na více než padesát vývojů, otestovali je, provedli změny v souvislosti s našimi hypotézami a znovu je otestovali. Po zkontrolování dostupných možností jsme zvolili Commvault. Po vybalení mohl tento produkt pracovat s nejjednodušší instalací clusteru PostgreSQL a jeho otevřená architektura vzbuzovala naděje (které byly oprávněné) na úspěšný vývoj a integraci. Commvault může také zálohovat protokoly PostgreSQL. Například Veritas NetBackup z hlediska PostgreSQL může provádět pouze úplné zálohy.
Více o architektuře. Servery pro správu Commvault byly nainstalovány v každém ze dvou datových center v konfiguraci CommServ HA. Systém je zrcadlený, spravovaný přes jednu konzoli a z pohledu HA splňuje všechny podnikové požadavky.
V každém datovém centru jsme také spustili dva fyzické mediální servery, ke kterým jsme připojili disková pole a páskové knihovny určené speciálně pro zálohování přes SAN přes Fibre Channel. Rozšířené deduplikační databáze zajišťovaly odolnost mediálních serverů proti chybám a připojení každého serveru ke každému CSV umožnilo nepřetržitý provoz, pokud některá komponenta selhala. Architektura systému umožňuje zálohování pokračovat, i když jedno z datových center spadne.
Patroni definuje primární uzel pro každý cluster. Může to být jakýkoli volný uzel v datovém centru – ale jen většinou. V záloze jsou všechny uzly sekundární.
Aby Commvault pochopil, který uzel clusteru je primární, integrovali jsme systém (díky otevřené architektuře řešení) s Postgres. Za tímto účelem byl vytvořen skript, který oznamuje aktuální umístění primárního uzlu serveru pro správu Commvault.
Obecně proces vypadá takto:
Patroni vybere Primární → Keepalived vyzvedne IP cluster a spustí skript → agent Commvault na vybraném uzlu clusteru obdrží upozornění, že se jedná o primární → Commvault automaticky překonfiguruje zálohu v rámci pseudoklienta.
Výhodou tohoto přístupu je, že řešení neovlivňuje konzistenci, správnost logů ani obnovu instance Postgres. Je také snadno škálovatelný, protože již není nutné opravovat primární a sekundární uzly Commvault. Stačí, aby systém pochopil, kde je Primární, a počet uzlů lze zvýšit na téměř libovolnou hodnotu.
Řešení se netváří jako ideální a má své vlastní nuance. Commvault může zálohovat pouze celou instanci, nikoli jednotlivé databáze. Proto byla pro každou databázi vytvořena samostatná instance. Skuteční klienti se spojují do virtuálních pseudoklientů. Každý pseudo-klient Commvault je cluster UNIX. Jsou do něj přidány ty uzly clusteru, na kterých je nainstalován agent Commvault pro Postgres. V důsledku toho jsou všechny virtuální uzly pseudoklienta zálohovány jako jedna instance.
V rámci každého pseudoklienta je označen aktivní uzel clusteru. To definuje naše integrační řešení pro Commvault. Princip jeho fungování je poměrně jednoduchý: pokud je na uzlu vyvolána IP clusteru, skript nastaví parametr „aktivní uzel“ v binárním kódu agenta Commvault – ve skutečnosti skript nastaví „1“ do požadované části paměti. . Agent přenese tato data do CommServe a Commvault vytvoří zálohu z požadovaného uzlu. Kromě toho je správnost konfigurace kontrolována na úrovni skriptu, což pomáhá předcházet chybám při spouštění zálohy.
Zároveň jsou velké databáze zálohovány v blocích napříč více vlákny, čímž splňují požadavky RPO a okna zálohování. Zatížení systému je zanedbatelné: Úplné kopie se nevyskytují tak často, v jiné dny se shromažďují pouze protokoly a v obdobích nízkého zatížení.
Mimochodem, pro zálohování protokolů archivu PostgreSQL jsme použili samostatné zásady - jsou uloženy podle jiných pravidel, kopírovány podle jiného plánu a není pro ně povolena deduplikace, protože tyto protokoly obsahují jedinečná data.
Aby byla zajištěna konzistence v celé infrastruktuře IT, jsou na každý z uzlů clusteru nainstalováni samostatný souboroví klienti Commvault. Vylučují soubory Postgres ze záloh a jsou určeny pouze pro zálohy OS a aplikací. Tato část dat má také své vlastní zásady a dobu uchovávání.
V současné době IBS neovlivňuje služby produktivity, ale pokud se situace změní, může Commvault povolit omezení zatížení.
Je to dobré? Dobrý!
Obdrželi jsme tedy nejen funkční, ale také plně automatizovanou zálohu pro instalaci clusteru PostgreSQL, která splňuje všechny požadavky pro podniková volání.
Parametry RPO a RTO 1 hodina a 2 hodiny jsou pokryty rezervou, což znamená, že je systém dodrží i při výrazném nárůstu objemu uložených dat. Navzdory mnoha pochybnostem se PostgreSQL a podnikové prostředí ukázaly jako docela kompatibilní. A nyní z vlastní zkušenosti víme, že zálohování pro takové DBMS je možné v široké škále konfigurací.
Samozřejmě jsme na této cestě museli opotřebovat sedm párů železných bot, překonat řadu obtíží, šlápnout na několik hrábí a opravit řadu chyb. Nyní však byl tento přístup již otestován a lze jej použít k implementaci Open Source namísto proprietárního DBMS v drsných podnikových podmínkách.
Vyzkoušeli jste si práci s PostgreSQL ve firemním prostředí?
Autoři:
Oleg Lavrenov, konstruktér systémů pro ukládání dat, Jet Infosystems
Dmitrij Erykin, konstruktér počítačových systémů ve společnosti Jet Infosystems
Zdroj: www.habr.com