That can be addressed with DNS round robin. The only issue is how the user's OS responds to no response from one IP address. Check out how irc.freenode.com does i
On Wed, May 19, 2010 at 9:09 PM, Ed Knapp <[email protected]> wrote: > One thing struck me here with your description... > > “and a change to the DNS and we are off and running” > > While your DNS records might be changed relatively quickly during an > incident, the change > Itself can take quite a while to trickle down to the end users/clients out > in the cloud. > Any client’s DNS resolution that has not expired in the cache nor manually > refreshed will > still fail to properly resolve/connect. It doesn’t usually, but I tell > clients to plan for 48 hours > Estimated time for the change to completely propagate. > > I would hate for you to get blindsided with a person hovering over you > asking how much longer > It is going to take before the site is back up and operational. It is > frustrating when you have > Fixed the issue [ problem :-) ] but have to just sit and wait for it to > complete. > > There are certainly strategies to mitigate this risk and I do not know if > you maintain your > Own DNS servers or do you work through a hosting provider/domain registrar. > > I hope this helps a bit. > > Ed > > > On 5/19/10 2:07 PM, "keith smith" <[email protected]> wrote: > > > > Currently we have two servers in our main data center. One serves our > shopping cart. The other contains quite a bit of content that is data > driven (reads). The content site is very active. The orders on the > shopping cart are spread apart by one or two minutes during the busiest part > of the day. We store a lot of data with each order so most of this is > writing. The shopping cart is backed up to the server in the other data > center. Supposedly if there is a problem, a few things need to be done to > the backup server in preparation to make it live, and a change to the DNS > and we are off and running. > > The problem I am trying to solve is the other server (content site) is not > currently backed up automatically. > > Another layer of this is these are managed servers. We have an excellent > relationship with the data center owner and have 24/7 access to him and his > staff. He manages all three servers and has always done a good job. > > I am the one tasked with keeping our sites online 24/7. > > I was hoping by configuring two servers, each in a different location, that, > in the event of one of the data centers being completely severed from the > Internet that the other server would automatically, without any human > intervention, take over the full load of the other server and those visiting > either of our sites would not know there had been an issue. > > In a nutshell I am trying to create an automated backup that is a automated > fail over solution. > > I appreciate all your feedback! > > ------------------------ > Keith Smith > > --- On Wed, 5/19/10, Dan Dubovik <[email protected]> wrote: > > From: Dan Dubovik <[email protected]> > Subject: Re: load balanced configuration > To: "Main PLUG discussion list" <[email protected]> > Date: Wednesday, May 19, 2010, 1:45 PM > > The question I have, are you trying to actually load balance things? Or just > have a remote location that you can fire up with live data at a moments > notice? Basically, are you wanting an active/active configuration, or > active/passive? > active/active across DC's can get kind of hairy depending on what the > network looks like. active/passive won't give you any performance gains, > but can simplify the configuration, while providing the HA you seem to be > after. As Kaia pointed out, what the traffic looks like (reads vs writes) > is a consideration. If it is something that users don't write to, and data > doesn't have to be replicated across DCs frequently, this further simplifies > things. > > Ultimately, the configuration will depend on what the application and > network looks like currently, and what level of redundancy you want / need. > > -- Dan. > > On Wed, May 19, 2010 at 1:40 PM, Matt Iavarone <[email protected] > </mc/[email protected]> > wrote: > > I think the original question was around stateless load balancing, not > clustering. Cross DC clustering is a headache, but HA web sites aren't > exactly terchnical challenges these days. > > On May 19, 2010 4:33 PM, "Alex Dean" <[email protected] > </mc/[email protected]> > wrote: > > > On May 19, 2010, at 2:47 PM, keith smith wrote: > >> >> >> Hi Plug, >> >> I am considering combining the ... You're entering a world of pain. :) > > HA is cool, but is no panacea. If you haven't actually experienced downtime > due to your server crashing or your datacenter losing connectivity, I > recommend thinking long and hard about it. Don't solve a problem you don't > have. The downtime created from unneeded failovers will likely exceed the > actual/real downtime caused by either a server or datacenter being offline. > Managing the cluster itself (as distinct from the services provided by the > cluster) needs to be accounted for as an expense/responsibility. > > I don't want to sound overly pessimistic. I've set up quite a few HA > clusters, and actually enjoy it most of the time. But it WILL cause you > headaches in the middle of the night which you wouldn't have had if you only > had a single server. > > Leave yourself lots of time to set up a development/test cluster, and abuse > it in many ways. Pull out network cables, kill the switch, yank out power > cables, etc. Do this with real hardware, not VMs. > > When the cluster nodes lose contact with each other, both will decide to > become primary. This is a split brain. This can happen when the switch > in-between them gets busy and starts dropping pings. Now, you can always > recover from such things. I'm just recommending you become very familiar > with these issues before going live with this setup. > > http://clusterlabs.org/wiki/Main_Page > http://people.linbit.com/~florian/heartbeat-users-guide/ > <http://people.linbit.com/%7Eflorian/heartbeat-users-guide/> > > Let me/us know if you have specific questions once you start setting things > up. Good luck! > > alex > --------------------------------------------------- > PLUG-discuss mailing list - [email protected] > </mc/[email protected]> > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > --------------------------------------------------- > PLUG-discuss mailing list - [email protected] > </mc/[email protected]> > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > > -----Inline Attachment Follows----- > > --------------------------------------------------- > PLUG-discuss mailing list - [email protected] > </mc/[email protected]> > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > > ________________________________ > --------------------------------------------------- > PLUG-discuss mailing list - [email protected] > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > --------------------------------------------------- > PLUG-discuss mailing list - [email protected] > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > --------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
