Re: load balanced configuration

Rsynch for Near Continues Data Protection of files - RSnapshpt for time
based snapshots / fault recovery - Cluterd databse server for continues data
protection on the databse level with regular backups + logs to accommodate
required rollbacks on slave server (Thus allowing you to never lock the
master server)

Always have your data in 3 place one of which must be remote from the other
two. Use different accounts/passwords to gain root level / data level access
on each box. Set up your web app to use restricted database accounts that
perform segmented duties and only at the level of privilege required.

On Fri, May 21, 2010 at 2:34 PM, keith smith <klsmith2020@yahoo.com> wrote:

>
> Hi Stephen,
>
> Actually it is not too late. It is still in the research phase. That was
> were I was going however through this discussion I'm thinking there would
> still be a DNS cache issue due to routers storing DNS for some period of
> time that might be up to 72 hours. Have I misunderstood?
>
> ------------------------
> Keith Smith
>
> --- On *Fri, 5/21/10, Stephen <cryptworks@gmail.com>* wrote:
>
>
> From: Stephen <cryptworks@gmail.com>
>
> Subject: Re: load balanced configuration
> To: "Main PLUG discussion list" <plug-discuss@lists.plug.phoenix.az.us>
> Date: Friday, May 21, 2010, 2:28 PM
>
>
> 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<http://mc/compose?to=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<http://mc/compose?to=alex@crackpot.org>
>> >* wrote:
>>
>>
>> From: Alex Dean <alex@crackpot.org<http://mc/compose?to=alex@crackpot.org>
>> >
>> Subject: Re: load balanced configuration
>> To: "Main PLUG discussion list" <plug-discuss@lists.plug.phoenix.az.us<http://mc/compose?to=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<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
>>
>
>
>
> --
> 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
>
> -----Inline Attachment Follows-----
>
>
> ---------------------------------------------------
> 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
>
---------------------------------------------------
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