Redundantný PostgreSQL a jeho monitorovanie

Používate v svojich riešeniach redundanciu? Pokiaľ sa jedná o „mission critical“ aplikácie, odpoveď našich zákazníkov je štandardne áno. Redundantné D2000 aplikačné servery, redundantné LAN, redundantné archívy, komunikačné procesy aj komunikačné trasy – podľa povahy aplikácie používajú niektoré alebo aj všetky typy redundancie, ktoré aplikačný server D2000 podporuje.

 

Ale ako je to s externými databázami, na ktoré sa pristupuje pomocou procesu D2000 DbManager?

 

V minulosti sme v aplikáciách vyžadujúcich redundantnú databázu použivali Oracle RAC (Real Application Cluster). Súčasný stav technológie nám umožňuje dodávať výkonné riešenia postavené na databáze PostgreSQL implementujúce vysokú dostupnosť.

 

Obr: Dvojnodová Active/Standby architektúra vysokodostupnej PostgreSQL databázy

 

Ako to funguje?

  • na spodnej úrovni sú 2 linuxové servery (fyzické alebo virtualizované)
  • replikáciu dát medzi servermi zabezpečuje vrstva DRBD
  • vyššie je Linux clusterware Corosync a správca clustrových zdrojov Pacemaker
  • na zdieľanej virtuálnej IP adrese je spustená PostgreSQL databáza

DRBD (Distributed Replicated Block Device) zabezpečuje uloženie databázových dát na obidvoch linuxových serveroch, takže sú dostupné aj v prípade výpadku jedného zo serverov.

 

Clusterware zabezpečuje štartovanie PostgreSQL databázy na aktívnom node. Zároveň sa stará o to, aby boli dostupné potrebné zdroje (IP adresa a disk s databázou replikovaný DRBD). Pokiaľ dôjde k výpadku aktívneho servera, standby server prevezme jeho funkciu. To znamená, že DRBD na tomto serveri sa stane primárnym, serveru sa pridelí zdieľaná virtuálna IP adresa, pripojí sa zdieľaný súborový systém a spustí sa PostgreSQL.

 

Redundantné riešenie je samozrejme nutné aj monitorovať – v opačnom prípade sa môže stať, že keď sa jeden zo serverov stane nefunkčným, celé vysokodostupné riešenie funguje (čo je želaný stav), ale nikto nevie, že treba niečo opravovať (čo je neželané). Následne vypadne aj druhý server – to už užívatelia pocítia ako nedostupnosť databázy.

 

Monitorovanie jednotlivých komponentov riešenia je možné ručne (príslušnými konfiguračnými nástrojmi) alebo pomocou rôznych utilít. Keďže naše riešenia používajú vlastný profylaktický modul podporujúci monitorovanie jednotlivých častí riešenia (od úrovne hardvéru, cez operačné systémy, databázy až po aplikačnú funkcionalitu), bolo logické ísť touto cestou.

 

Takže minulý týždeň sme úspešne integrovali monitorovanie PostgreSQL clustra do našeho profylaktického modulu, ktorý je nasadený na niekoľkých desiatkách servisovaných aplikácií. Jednotlivé komponenty vysokodostupného riešenia (DRBD, Pacemaker/Corosync, virtuálna IP adresa, zdieľaný súborový systém a samotná PostgreSQL databáza) sú periodicky dotazované a je vyhodnocovaný ich stav.

 

V prípade zistených problémov sú tieto zobrazené na profylaktickej schéme (viď obrázok nižšie). Informácia je následne poslaný aj na profylaktický server Ipesoftu, kde sa riešeniu problému môže venovať jeden z našich špecialistov zameraných na Linux a PostgreSQL. Prípadné problémy je tak možné analyzovať a riešiť bez dopadu na prevádzku.

 

Obr: grafické zobrazenie stavu komponentov vysokodostupného PostgreSQL.
Server vľavo je sekundárny (Standby), server vpravo je primárny (Active).

 

Záver

 

V súčasnosti vieme našim zákazníkom v rámci dodávaných riešení ponúkať nielen redundanciu samotného aplikačného servera  reálneho času D2000, ale aj externých databáz. Popri databáze Oracle ponúkame aj vysokodostupné riešenia postavené na najpokročilejšej open-source databáza PostgreSQL. Takéto riešenia vieme nielen konfigurovať a spravovať, ale aj priebežne monitorovať a sledovať stav jednotlivých komponentov.

 

Za IPESOFT pre Vás napísal

Peter Humaj

Peter Humaj

e-mail: humaj.peter@ipesoft.com