Design Question - Separate Frontend

[whitekitten]

Hello Members,

I am planning to do a POC where we have separate servers for FE, Zabbix and DB.

The idea is to separate provisioning of hosts which will be done through API and retrieval of metrics through API.

I am thinking of below design so that we keep separate verticals for provisioning/monitoring and retrieving performance data

The LHS zabbix will be responsible for collecting data using multiple proxies and its sole function is to provision and monitor the hosts

DB01 - is the primary database and will be performing replication to DB02

DB02 will be used for retrieving data for reporting and data presentation.

Not sure we need extra zabbix server on the RHS to help with the API functions.

The goal is to separate monitoring / polling and data retrieval and optimize API loads which will be higher when the data is retrieved.

Please provide your suggestions and feedback.



Thanks in advance.

[cyber]

This will never work...
First of all, frontend talks to DB directly, not to server..
You can have separate frontends for users and api, we do it also... but it will work with RW DB not with RO. Its never meant to work with RO DB...

[whitekitten]

Thanks for your inputs and this what is thought.

I tried to play around with the PostgreSQL replication server and tried to connect FE to backup DB but as it is read only, I get errors.

Is there any way to dump all Zabbix data to a warehouse and then connect secondary FE to it? OR May be create a writable replica from PostgreSQL..?

Any pointers are appreciated.

Cheers!

[cyber]

Seems like you are trying to overengineer stuff here and make things work in a way they are not supposed to work... Do you really have issues, what you want to solve, or you just think, that there may be an issue?

Active-active is not easy... https://www.redhat.com/architect/pos...ctive-database
My gut feeling says, that even if you build your active-active DB somehow, your application has to support it also. I am no developer or DBA, but I seriously doubt you can leave everything here just to DB layer...

Why do you think you really need that kind of separation? I doubt your host provisioning (I suppose you mean configuring zabbix and its hosts??) will make any significant load compared to any normal use (user using the GUI). And server doing its things for collecting data from proxies and calculating triggers etc... There are caches for keeping data and not doing constant queries towards DB.

[whitekitten]

Thanks for your inputs cyber, seriously I am just trying to keep separate DB for users as there are significant number of users who will be accessing metrics via API. I don't think provisioning of hosts will be an issue in terms of load on the API, its just that i want to have separate DB which can be accessed through API and doesn't fiddle with the live DB of Zabbix and its operation.

so in an event of significant user load of accessing API's we don't interrupt the normal DB RW operations done by zabbix. so in an event of high user access load, if things go southbound it will only affect the users who can not access the metrics and Zabbix continues to perform its duties.

Usually in a larger FE/BE environment, reporting / analysis is not performed on the live production DB instead it is done on the DB ware house or replica of the DB.

Please advise if this makes sense.

Cheers

[cyber]

I have not experiencced UI users (and a lot of UI works anyway based on API calls, IIRC) affecting rest of the servers work... But then again your setup may be times bigger, with more users and different demands... my 4300+ nvps with 1M items and ~40 everyday users manage without issues..

I think one way you can give them RO DB copy, would be giving them a different tool to visualise and report... Like Grafana with a zabbix plugin. Point it to db replica...

In Zabbix roadmap (https://www.zabbix.com/roadmap), there is this for v7...

Scalable history storage
It will include standard API for storage of history and trend data as well as support of new time-series storage engines.

Maybe it will help, maybe not...

[whitekitten]

I think i have an option to create an RO DB and that should suffice. Anyways thanks for all your pointers and they were extremely helpful

Cheers