bootstrapping/deploying metrics db

Charles Crouch ccrouch at redhat.com
Wed Sep 26 15:05:02 UTC 2012



----- Original Message -----
> We could provide documentation to folks on how to add new standalone
> cassandara nodes if they so choose. I'm more worried about the guy
> who just wants to install RHQ and try it out - or the small shop
> that just wants a simple RHQ environment to manage his half-dozen or
> so machines/app servers whatever. In that case, an embedded solution
> would work nice, assuming cassandra doesn't gobble up all resources
> that the RHQ Server needs.
> 
> When you say "embedded", I assume you mean inside the same VM as the
> RHQ Server? Perhaps we don't have it in the same VM? Perhaps just
> have rhq-server.sh start two things - the RHQ Server itself and its
> "embedded" cassandra node (where "embedded" just means its running
> on the same machine as RHQ Server and its started/stopped by the
> same script as the RHQ Server (i.e. rhq-server.sh)

We need to decide on our nomenclature re:embedded, but a single machine install of RHQ and all its persistence stores is a requirement.

> 
> ----- Original Message -----
> > I have previously mentioned that I am not inclined to pursue
> > embedding cassandra in large part because I have read that it is
> > discourage for production environments. Cassandra like other server
> > applications uses a lot of resources, e.g., threads, memory, etc.
> > cassandra would be competing for those resources with the RHQ
> > server. Either or both cassandra and the RHQ server would likely
> > suffer in performance. cassandra uses default garbage collector
> > settings that are tuned for its caching, and those settings may not
> > be optimal for RHQ, and settings we use for RHQ might not optimal
> > for cassandra.
> > 
> > The other issue with embedding is that we do want to support stand
> > alone, non-embedded nodes. For users that need the scalability and
> > are collecting a high volume of metrics, they are going to want
> > stand alone nodes that are not competing for resources with another
> > application in the same JVM. So if we have both embedded and stand
> > alone, we have two deployment models to support. I prefer to stick
> > with one, at least for now.
> > 
> > I have briefly talked about adding hooks. CassandraDaemon is the
> > entry point for cassandra. It defines the main method that is
> > invoked when you start a node. It is designed to be extensible. I
> > have already mentioned that I think we will want to extend
> > CassandraDaemon for a few reasons. I suppose this might be
> > considered an embedded solution.
> > 
> > On Sep 26, 2012, at 10:26 AM, Lukas Krejci <lkrejci at redhat.com>
> > wrote:
> > 
> > > On Wednesday, September 26, 2012 10:15:12 Simeon Pinder wrote:
> > > <... snip ... >
> > >> Any reason why we can't do both?  For production installations,
> > >> we
> > >> add an
> > >> optional installation step that provisions a Cassandra node on a
> > >> remote
> > >> box.
> > > 
> > > I think this is exactly the problem that John describes. It's a
> > > chicken-and-
> > > egg problem (if you want to have Cassandra provisioned by our
> > > provisioning
> > > subsystem).
> > > 
> > > If we have to implement a way of provisioning cassandra at
> > > installation time
> > > (i.e. WITHOUT an actual RHQ server running and offering its
> > > services) then we
> > > might just use that always and not bother with bundles for
> > > cassandra
> > > provisioning.
> > > 
> > >> For dev mode and non-production installs we prepare to embed a
> > >> Cassandra server but have the startup code check for an existing
> > >> Cassandra
> > >> node indicated by some server property, before defaulting to the
> > >> embedded
> > >> Cassandra node.  Probably want to disable the startup check
> > >> after
> > >> you've
> > >> chosen local or remote so you don't have the primary metric
> > >> store
> > >> node
> > >> flip-flopping locations after install.  Either way before
> > >> startup
> > >> you have
> > >> your Cassandra node.
> > > 
> > > <... snip ...>
> > > 
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list