bootstrapping/deploying metrics db

John Mazzitelli mazz at redhat.com
Wed Sep 26 15:02:42 UTC 2012


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)

----- 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
> 


More information about the rhq-devel mailing list