If this is true then I completely agree. While a cluster addresses
both concerns of availability and performance, setting up for just
availability is easier. In addition if one focuses on just
availability one can perform certain tricks to allow for increased
timeliness with catastrophic recovery by concurrently employing
various tricks to recover from different forms of disasters.

On Fri, May 21, 2010 at 8:23 AM, Alex Dean <alex@crackpot.org> wrote:
>
> On May 20, 2010, at 5:31 PM, Bryan O'Neal wrote:
>
>> Personally I vote for RRDNS so that your domain name has multiple IP's
>> associated with it. DynDNS polls every few minuets for availability
>> and will automatically remove dead servers. That is what clustering is
>> all about :)
>
> Keith originally mentioned wanting servers in 2 distinct locations, a
> primary site and a backup site, with the backup site able to take over
> automatically if the primary becomes unavailable.  To me, this sounds like a
> concern for availability, not performance, and my comments have been made in
> that frame of mind.
>
> 'clustering' can mean a lot of things.  Increasing performance, as in
> high-performance computing, is not the same as increasing availability.  The
> kind of load-balancing you can achieve through RRDNS does not necessarily
> increase availability.  You have to consider how well your current
> infrastructure is matched to your current workload.
>
> What I mean is this : If you have 2 servers doing an identical job (like 2
> web servers serving up the same website, to the same users, etc), you can
> load-balance through RRDNS, or through a dedicated load-balancer, or
> whatever.  That doesn't automatically do anything to increase your site's
> availability.  If your site's traffic load requires both servers to be
> functional in order to get decent performance for the user, then losing 1
> server means your site is effectively unavailable.  By contrast, if the 2
> servers are in an active/passive configuration, you aren't load-balancing at
> all, but you do have high-availability.  If the primary server dies, the old
> secondary can become primary and users should never know the difference.
>
> I think it's really important to keep these goals distinct, assign relative
> importances to each, and act accordingly.  High performance is not high
> availability.  High availability is not backup.  Decide which you need.
>  Hint: You ALWAYS need backup. :)
>
> I often hear people bemoan the fact that in a typical HA setup, they've
> spent money on all this backup hardware, and it's not 'doing anything'.
>  It's just sitting there waiting for the primary server to fail.  Yes, this
> is true.  You just have to keep in mind that if it were 'doing something',
> you'd miss it if it died, and that's not really high-availability.
>
> alex
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss