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 <
klsmith2020@yahoo.com> 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 <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<http://mc/compose?to=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
---------------------------------------------------
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)