On Mon, Dec 14, 2009 at 09:26:01AM +0000, Daniel Pocock wrote:
> Vladimir Vuksan wrote:
> > I think you guys are complicating much :-). Can't you simply have
> > multiple gmetads in different sites poll a single gmond. That way if
> > one gmetad fails data is still available and updated on the other
> > gmetads. That is what we used to do.
>
> That is a good solution under two conditions:
>
> a) you are only concerned with redundancy and not looking for
> scalability - when I say scalability, I refer to the idea of maybe 3 or
> more gmetads running in parallel collecting data from huge numbers of agents
what is the bottleneck here?, CPUs for polling or IO?, if IO using memory
would be most likely all you really need (specially considering RAM is really
cheap and RRDs are very small), if CPUs then there might be somethings we
can do to help with that, but vertical scalability is what gmetad has, and
for that usually means going to a bigger box if you hit the limit on the
current one.
> b) you can afford to have duplicate storage - if your storage
> requirements are huge (retaining a lot of historic data or lot's of data
> at short polling intervals), you may not want to duplicate everything
if you are planning to store a lot of historic data then you should be
using instead some sort of database, not RRDs and so I think this shouldn't
be an issue unless you explode the RRAs and try to abuse the RRDs as a RDBMs
of course that means you have to add a process to gather your metric data
out of the RRDs to begin with and into your RDBMs but there shouldn't be a
need to be concerned with RRDs storage size, when you are most likely going
to be spending a lot more in that RDBMs storage (including snapshots and
mirrors and all those things that make DBAs feel warm inside, regardless of
budget)
Carlo
PS. I like the ideas on this thread, don't get me wrong, just that I agree
with Vladimir that gmetad and RRDtool are probably not the sweet spot
(cost wise) for scalability work even if I also agree that the vertical
scalability of gmetad is suboptimal to say the least.
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
