Best practice for OpenVoxDB with multiple compilers

[bwitt]

In https://voxpupuli.org/docs/arch_load_balanced/ and using multiple compilers, what's the best practice for where to run OpenVoxDB? The diagram does not show OpenVoxDB at all.

I think this should be

• If the latency to the actual DB is low from all compilers, run one OpenVoxDB per compiler
• If latency is high from any of the compilers, have a separate pool of OpenVoxDBs with low latency to the actual DB

One OpenVoxDB is configured for garbage collection (gc-interval > 0); the rest do not (gc-interval == 0)
https://help.puppet.com/pdb/current/topics/configure.htm#gc-interval

One OpenVoxDB does schema upgrades (migrate == true); the rest do not (migrate == false)
https://help.puppet.com/pdb/current/topics/configure.htm#migrate

What other considerations are there when running multiple OpenVoxDBs?

[bastelfreak]

short version: It depends.

Long: You can connect multiple compilers to a single OpenVoxDB. This can run on a standalone box, or together with postgresql or on your primary. Now how much load do you expect, can a single instance handle that? Is it okay if this instance is down (plannend or unplannend)? It's a common approach to run a compiler + OpenVoxDB on the same node. You can also have a central loadbalancer with multiple OpenVoxDB instances behind. There are always some constraints like the latency between different locations, the amount of reports per hour, the report/fact/catalog size and the expected availability. Also there are often network constraints.That makes it a bit tricky to make a generic recommendation.

As a start, it's always good to setup https://github.com/puppetlabs/puppet_operational_dashboards/tree/main , so you know the load on your compilers and OpenVoxDB and postgresql.

@binford2k @austb also have some thoughts here.