This is a little late, but a possibility, If you have the High availability in aata-center A, to protect against hardware issue/fail, then a 3rd offsite server to serve as backup in case of data-center failure. The latter being more of a "oh crap" kind of save, using a combination of backups and rsync you can keep it very up to date. and even a fail-over page in case your main data-center is offline. so it can be brought online or have a simple landing page with im sorry we are having technical issues sort of response and posting ETA/time. and it would give you a fail-over location for email continuity very similar to your suggestion. On Fri, May 21, 2010 at 10:49 AM, keith smith wrote: > > > 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 * wrote: > > > From: Alex Dean > Subject: Re: load balanced configuration > To: "Main PLUG discussion list" > 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 > -- A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button. Stephen