[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rhq-users
Subject:    Sizing guidelines for future RHQ inventories
From:       Lukas Krejci <lkrejci () redhat ! com>
Date:       2014-10-27 16:31:51
Message-ID: 2041360.xNNiR4fGlO () localhost ! localdomain
[Download RAW message or body]

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-for-rhqnext \
(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

_______________________________________________
rhq-users mailing list
rhq-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-users


[prev in list] [next in list] [prev in thread] [next in thread]