Date: Thu, 3 Oct 1996 13:25:23 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: richard@pegasus.com (Richard Foulk) Cc: jgreco@brasil.moneng.mei.com, jeff@mercury.jorsm.com, freebsd-isp@FreeBSD.ORG Subject: Re: RAID Controller Product Message-ID: <199610031825.NAA07158@brasil.moneng.mei.com> In-Reply-To: <199610031815.IAA13726@pegasus.com> from "Richard Foulk" at Oct 3, 96 08:14:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> } The other non-obvious downside to this is that the reason you are > } doing it in the first place is so that newsreaders can connect. However > } once connected they like to stay connected for a long time... and when > } you bring the other machine back online, you are going to have a SECOND > } service disruption. > > Hadn't thought of that. In that light, more reliable servers (with > RAID, etc.) may be more appropriate than multiple/redundant servers > (since that's where this thread started.) Is it, though? If you take a machine from 98% to 99% reliability by introducing RAID, etc., you have just halved your downtime. That is good. However, you still have 1% to worry about. If you have completely redundant servers, as long as they do not all go down simultaneously, you have 0% to worry about BUT you may have some minor transitional hiccups due to cached DNS entries, etc. Therefore... The way I look at it: More reliable single machine = good chance for occasional total failures Multiple machines = small chance for total failures, but there may be a few bumps along the way through the transition due to caching DNS, crappy clients, etc. So, it would seem to me that the latter is preferable particularly if you minimize the "bumps" by reducing TTL, etc. I would rather be able to tell a customer that they simply need to try to connect again than have to tell them the news server is dead and the ETA is 18 hours because an expensive RAID SCSI controller failed. ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610031825.NAA07158>