Hi all,
we are starting to re-think RHQ to bring it forward to the cloud-ready, IoT
and other brave new worlds and would like to hear your feedback on what an RHQ
inventory might "look like" in the future.
I am basing the below on the forum article
https://developer.jboss.org/en/rhq/blog/2014/09/25/thoughts-on-inventory-...
(including comments and links) which describes in high level our
current thinking about the architecture of the new inventory.
I just pulled some random numbers almost out of thin air (the sizing is based
on the anecdotal evidence I gathered from the community about the sizes of the
larger inventories people are managing).
I'd like gather feedback on both the numbers and the structure of the
inventory.
To mimick the basic, still important, tree structure of the classic RHQ
inventory:
* there is 1000 agents (machines)
* There are 50 resource types
* Hierarchy is 7 elements deep
* There are 10 types of top level resources
* 5 of the top level resources have children (think servers per machine)
* only 2 resources have full 7 element deep hierarchy
* There are 10 resource groups
* All resources are part of at least 1 group (either explicitly or implicitly)
* Every resource has 5-10 metric schedules, 2 operations
* Plugin config of each resource has 2-20 properties
* Resource config of each resource has 2-20 properties
To mimick the new requirements:
* Each resource is part of 1 application (either explicitly or implicitly)
(did I hear these are the same as mixed groups? ;) )
* 1% of the resources is part of 10 applications (shared infra like db server)
* Each resource has 5-10 versions (to mimick changes in config/schedules)
* There are 10000 "miniagents" (some on machines managed by the "real"
agents,
some outside of them)
* Each miniagent defines 1-10 resource types
* 5 of these resource types are equivalent to the resource types from full-
blown agents
* mini-agent defines 1-20 resources which have metrics and configs with the
same sizing as on the real agent. No operations though.
WDYT?
I am going to use these guidelines as a basis for a benchmark that should help
us choose the right storage solution for the data.
The benchmark will be mostly focused on query performance because the inflow
of the data won't be that huge with rhq-inventory (meaning the rate of change
of the inventory itself is not going to be big). The rhq-inventory endpoint
will have a high throughput component that will establish identity of the
input data but that is mostly not going to end up being persisted. It is most
probably going to be merely routed somewhere else (metrics, audit, alerts,
...).
Thanks,
Lukas