Článek přečtěte do 3 min.

Provozování monitorovací platformy, jako je Zabbix, v produkčním prostředí vyžaduje neprůstřelnou dostupnost na úrovni databáze. Jakýkoli výpadek v PostgreSQL, byť jen na několik sekund, může narušit viditelnost monitorování a způsobit slepá místa v upozorněních a sběru dat.

Tento příspěvek představuje zjednodušenou architekturu vysoké dostupnosti (HA) pro Zabbix s využitím PostgreSQL, pg_auto_failover, HAProxy a PgBackRest. Tato architektura, postavená na RHEL 9 nebo jeho derivátech, odstraňuje jednotlivé body selhání a automatizuje failover s minimálními externími závislostmi, což z ní činí silného kandidáta pro moderní backendy s vysokou dostupností.

Přehled architektury

Tento návrh HA zjednodušuje nasazení pomocí vyhrazeného monitorovacího uzlu pro orchestraci automatického failoveru mezi dvěma uzly databáze PostgreSQL. S pg_auto_failover se vyhýbáme potřebě složitých konsenzuálních vrstev, jako je etcd nebo Consul, a zároveň dosahujeme rychlého a spolehlivého failoveru a obnovy.

Databázová vrstva

Dva uzly PostgreSQL jsou nasazeny v konfiguraci primární/sekundární. Tyto uzly jsou registrovány u vyhrazeného monitoru pg_auto_failover, který průběžně kontroluje stav uzlu a stav replikace. V případě selhání monitor přepne sekundární uzl na primární bez nutnosti ručního zásahu.

Každý uzel je bezpečně nakonfigurován pomocí ověřování scram-sha-256 a certifikátů SSL s vlastním podpisem/nebo vlastním podpisem, aby byla zajištěna šifrovaná komunikace v rámci clusteru.

Monitorovací uzel (arbitr)

Monitorovací uzel je odlehčená instance PostgreSQL, která spouští rozšíření pgautofailover. Uchovává informace o stavu všech zúčastněných uzlů a funguje jako arbitr během failover událostí. Vyžaduje pouze jeden uzel, což snižuje složitost ve srovnání s konsenzuálními systémy DCS (Distributed Configuration Store), jako jsou etcd nebo ZooKeeper.

Vrstva vyvažování zátěže

Dva uzly HAProxy směrují všechna připojení klientů (Zabbix) na aktuální primární server PostgreSQL. Lehká HTTP služba na každém uzlu databáze hlásí jeho aktuální roli (primární či nikoli) a umožňuje HAProxy určit, který uzel je zapisovatelný. Tyto proxy servery jsou vysoce dostupné pomocí služby Keepalived, která spravuje sdílenou virtuální IP adresu (VIP) napříč oběma proxy servery.

Tímto způsobem se aplikace jako Zabbix vždy připojují ke stabilnímu koncovému bodu, a to i během failoveru.

Záložní vrstva

Zálohy se zpracovávají pomocí PgBackRest, který je nasazen na dedikovaném zálohovacím serveru. Tento server se připojuje k oběma uzlům PostgreSQL přes SSH a provádí následující:

  • Úplné a inkrementální zálohy
  • Archivace WAL
  • Obnova v daném bodě (PITR)

SSH bez hesla a správné mapování pgbackrest.conf jsou nastaveny tak, aby podporovaly bezproblémovou interakci bez ohledu na to, který uzel je aktuálně primární.

Přehled komponent

Komponent Role
PostgreSQL Relační backend ukládající všechny metriky, upozornění a události Zabbixu
pg_auto_failover Zajišťuje nepřetržitou dostupnost automatickým povyšováním replik
Monitorovací uzel Rozhoduje o failoveru na základě kontrol stavu a stavu clusteru.
HAProxy Směruje klientský provoz na aktuální primární server.
Udržováno Poskytuje VIP failover mezi uzly HAProxy.
PgBackRest Provádí zálohy s podporou PITR z libovolného uzlu
Zabbix server Připojuje se k PostgreSQL přes VIP pro zajištění kontinuity

Topologie v kostce

Design

Na rozdíl od Patroni, který vyžaduje distribuované úložiště konfigurace, jako je etcd, pg_auto_failover používá vyhrazený monitorovací uzel, který zjednodušuje orchestraci. Toto nastavení snižuje provozní zátěž a zároveň poskytuje robustní zabezpečení proti selhání, automatické rekonfiguraci a synchronizaci, včetně:

  • Synchronous_standby_names pro vynucení integrity replikace.
  • Integrace služeb se systemd pro spolehlivé restarty.
  • Detekce failoveru s minimální latencí.

Tento návrh také zajišťuje šifrovanou komunikaci s podporou SSL, samoopravné změny rolí a plnou sledovatelnost pomocí samotného Zabbixu, který lze nakonfigurovat pro monitorování clusteru PostgreSQL prostřednictvím odhalených koncových bodů stavu.

Úvahy z reálného světa

  • Plánování upgradu: Verze pg_auto_failover v RPM repozitářích může zaostávat za nejnovějšími upstreamovými funkcemi, jako je set_monitor_setting. Pokud je vyžadována konzistence, uložte verzi balíčku.
  • Zabezpečení sítě: Pouze uzly HAProxy mohou dotazovat interní API pro kontrolu rolí na uzlech databáze pomocí vlastních pravidel firewallu.
  • Hygiena clusteru: Vždy vyčistěte konfigurační složky (~postgres/.config/pg_autoctl/…), pokud je uzel špatně nakonfigurován nebo se potřebuje znovu připojit.
  • SELinux: Nakonfigurujte SELinux, použijte semanage a audit2allow k opravě vlastních portů (např. 9877 pro kontroly stavu).
  • Hybridní logování: Nastavte PostgreSQL pro logování do journald i tradičních logovacích souborů pomocí stderr + logging_collector.

Závěrem

Tato architektura dosahuje rovnováhy mezi jednoduchostí a odolností. Zatímco Patroni je skvělý pro rozsáhlá, víceregionální nastavení vyžadující distribuovaný konsenzus, pg_auto_failover nabízí lehčí řešení, které pokrývá většinu podnikových potřeb bez složitých závislostí.

Vrstvením následujících…

  • PostgreSQL 17.
  • Pg_auto_failover s jedním monitorem.
  • HAProxy + Keepalived pro VIP failover.
  • PgBackRest pro zálohy.

…pak můžete s jistotou provozovat Zabbix vysoce dostupným a bezpečným způsobem s minimálními provozními režijními náklady.

Pokud zvažujete implementaci tohoto nastavení nebo migraci z databázového backendu s jedním uzlem, kontaktuje nás.

Zdroj: Zabbix