On 17 August 2010 02:00, Elliot Murphy <[email protected]> wrote: > On Mon, Aug 16, 2010 at 7:47 PM, Michael Hudson > <[email protected]> wrote: >> On Fri, 13 Aug 2010 11:56:47 +0100, Gavin Panella >> <[email protected]> wrote: >>> If what I am seeing is valid, then I can see two - I assume relatively >>> easy - things we can do to help: >>> >>> - Only publish one address for each vhost. >>> > I believe two addresses are published so that browsers round-robin > DNS support will failover to the second machine in the case of a > webapp FE server failure. Significantly speeding up SSL would be a > worthwhile reason for moving to another scheme, but you would > probably want to do something to replace the failover mechanism that > you are removing.
I don't know if browsers do failover. I /think/ they just alternate between the two addresses. If one of them fails, half the requests fail. I haven't tested this though. > I think a typical solution is to use a virtual IP with some kind of > heartbeat to let the second frontend takeover if the other one dies. > The downside of something like this is that you are no longer > running active-active on the front ends (I think?). In a previous job we did just that; a single endpoint was exposed to the world, but requests ended up going to any of 5 different web servers. However, these web servers did not share SSL sessions. I imagine there was a lot of session churn going on, but I didn't know what to look for at the time. We ought to be careful to avoid this. (It's possible that the inexplicably expensive piece of kit that presented the single endpoint provided some level of stickiness so that requests from the same source tended to get routed to the same web server.) That site also exposed low-TTL DNS entries, so that traffic could be directed over to another site in case of failure or, more often, during releases so that we could roll-out new code with zero down-time. > Speeding up SSL is a very worthwhile effort and it's awesome that > this is being investigated. I agree. It's almost a shame that, after so many years, there isn't a revered tome detailing all the best practices in this area. Or maybe there is... _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
