HA. Best Practice

[gunb1rd]

Hello Folks,

I'm interested to monitor my server infrastructure and I want to make a zabbix cluster high available.

I decided to use HAproxy, Keepalived, 2 zabbix proxies and 2 zabbix servers.

Actually, if 2 zabbix servers will be working, agents and proxies will be receiving the data twice, don't they?
How to avoid this situation if I don't want to stop the second servers?


Thanks for any information!

[pc99096]

http://zabbix.org/wiki/Docs/howto/high_availability

[hpeti2]

Hi!

We use this setup:
Corosync+Pacemaker with 2 Zabbix Server and 2 Proxy. One virtual IP address for each cluster. If zabbix 1 is down, zabbix 2 start polling.

The other role is the HA database. We use Percona Xtradb Cluster with HA Proxy.


Look at this.

[kloczek]

The other role is the HA database. We use Percona Xtradb Cluster with HA Proxy.

With growing NVPS bigger and bigger problem are not selects but updates and inserts.
Typically active-active clustering slows down all those crucial operations as data files must be updated on all cluster nodes before confirmation that insert or update is done.
Typically even with few thousands NVPS zabbix server is cummulating as much as possible data which needs to be added to DB so is doing not more than few inserts per second. Syncing so big inserts across more than one active node hurts dramatically latency of the inserts.

Your solution will be good enough up to few hundredths NVPS on low end current hardware. Above this only active-standby solution will be working.

Well architected DB backed should have almost none read IOs on storage layer (effectively almost all selects should be served from cached in memory data).

Best part about adding HA to zabbix is fact that while stack with at least one proxy provides quite high level of HA because proxy holds cyclic buffer of all monitoring data from up to 24h. With this even longer problems on zabbix server are not causing loosing monitoring data. During downtime it will be no reports from evaluating monitoring data against triggers (alarming layer) but monitoring data will be without gaps.
Such fact allows use master<>slave DB backend when time to time slave is promoted as new master and slave is rebuild from new master.
Having master<>slave DB backend solves all problems with hurting performance of the DB backend during database backups.