<div><span class="gmail_quote">On 2/19/07, <b class="gmail_sendername">Henrik Stoerner</b> <<a href="mailto:henrik@hswn.dk">henrik@hswn.dk</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Scott,<br><br>you're always asking interesting questions :-)</blockquote>
<div> </div>
<div> </div>
<div>Thanks.  I changed majors to Philosophy since returning to college to finish my undergraduate degree.  I'm glad to see it's paying off ;)</div>
<div><br>> Some tasks can run on any of the available servers. E.g. analyzing the<br>> client data can be done on any server running the hobbitd_client module;<br>> so it doesn't matter which of the available "client task" servers is
<br>> invoked. (Obviously, the config files must be kept in sync on the<br>> servers, but that's why we have tools like rsync).</div>
<div> </div>
<div> </div>
<div>Hmmm...since you already have a "task master" it might be convenient to make it the "config master" as well.  Similar to the hobbit-client.cfg?</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Some tasks store data - e.g. the RRD files. Those tasks can run on<br>multiple servers, BUT: For any given host, there will be only one server
<br>holding the data. It's no good feeding the RRD updates to server A at<br>10:00 AM, and server B at 10:05 - because that would break the RRD data.<br>So if the RRD files for "<a href="http://www.foo.com">www.foo.com
</a>" lives on server A, and that server<br>crashes, then you will lose access to the RRD files for <a href="http://www.foo.com">www.foo.com</a> -<br>but RRD files for hosts on the other servers will still be available.
<br>History logs are handled like RRD files. Now, you can argue that it<br>would be nice if you could replicate the RRD- or history-updates to<br>multiple servers so you would have a complete failover where you<br>wouldn't lose access to some of the data. If there's enough requests
<br>it can be added - there's nothing in the design that prevents it. But<br>perhaps it would just be simpler to mirror those files between the<br>servers at regular intervals through some other program.</blockquote>
<div> </div>
<div>Yes, that's the million dollar question:  Should HA with integrity of RRD/history files be part of of Hobbit?  Even if you do put the history-updates to multiple servers, you still have the nightmare of how to sync things up when the "dead" server comes back up.
</div>
<div><br>> Those are my ideas. Feedback is very welcome from anyone; this is a<br>> relatively new area for me to be working with (at least from a<br>> programmer perspective), so any input will be appreciated.<br>
 </div>
<div>Because of the complexity of HA solutions and data integrity, I am not sure the hobbit code is the right place for the logic.  Similar to the database backend, you'll open yourself up to a lot of potential debugging.  I am a keep it simple stupid kinda guy and I am reminded of a saying, "A man with one watch always knows what time it is."
</div>
<div> </div>
<div>I'd rather see the hobbit tool improve monitoring, reports, and other features that really matter.  Let the HA happen outside of hobbit.</div>
<div> </div>
<div>I also believe you should only cluster/load-balance when one box can't do the job.  Introducing those complexities to increase availability are usually counterproductive -- you end up taking your system down because it's so hard to configure/maintain.  And then it usually doesn't work anyway when it's supposed to.
</div>
<div> </div>
<div>Scott Walters</div>
<div>-PacketPusher<br><br> </div></div><br>