Alex you are 100% correct. We do not have a performance concern at this time. I think we could combine all our sites onto one server and we would be able to handle the load without any issue. Availability and adequate backups are our main concern.
We have two servers in our main data center and a 3rd in an off site data center. We use resync to backup server 1's content and data regularly to the off site server. Server 2 is backed up manually on a regular basis by one of my peers.
When I stared on this journey I was looking for the best way to provide fail over given two live servers and 1 backup server. As I got involved in this discovery process you guys pointed out many options and exposed many of the weaknesses of our current system and the options at hand. For that I am very grateful!
After reading every post again yesterday afternoon I wrote the following in preparation for submitting a suggested course of action to my bosses. It has not been submitted yet because I still feel I might have missed something.
---
No matter how we configure our 3 servers, there will be a vulnerability.
If we have all three servers in the same data center then we are vulnerable to having the data center loose Internet connectivity all together. According to several of my peers, this is not so likely. I still would like to prepare for this possibility.
If we go to a load balanced configuration where we have two servers in different data centers, this could become problematic if the controlling DNS degrades and each server thinks it has become the main server (split brain). I would think given the nature of the Internet that trying to replicated data real time could become a challenge. According to one of the people giving me feedback this arrangement is high maintenance and a headache.
If we expend on our current setup by adding the backing up of server 2 to the off site server, make the off site server a backup email server, and do external backups we still have a DNS caching issue if we make the off site server live. While this solution could be problematic in a fail over situation it would require the lease amount of maintenance. I think this is the solution we should follow.
---
These few short paragraphs is what I have taken away from our conversion over the past 3 days.
If you feel I have missed something or do not understand fully what my options are, please let me know. This has been a great learning experience and I am thankful to everyone who gave input. Thank!
------------------------
Keith Smith
--- On Fri, 5/21/10, Alex Dean <
alex@crackpot.org> wrote:
From: Alex Dean <
alex@crackpot.org>
Subject: Re: load balanced configuration
To: "Main PLUG discussion list" <
plug-discuss@lists.plug.phoenix.az.us>
Date: Friday, May 21, 2010, 8:23 AM
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 
(text/plain)