← Back to team overview

launchpad-dev team mailing list archive

Re: SSL sessions: start-up latency and renegotiations

 

On Aug 16, 2010, at 6:00 PM, Elliot Murphy wrote:

> On Mon, Aug 16, 2010 at 7:47 PM, Michael Hudson
> <michael.hudson@xxxxxxxxxxxxx> wrote:
>> On Fri, 13 Aug 2010 11:56:47 +0100, Gavin Panella <gavin.panella@xxxxxxxxxxxxx> 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
> 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?).
> 

DNS RR's really only have one good place anymore, and that is cheap
multi-site failover. Even then, they suck because when one site
goes down, some clients will keep retrying it, slowing their site
responsiveness. Newer browsers at least will wait a very short time
to try all of the RR's, but this also creates issues as the request
may actually be half-complete when the browser decides it is time
to switch (to be fair, I've only seen that from ie).

Basically, the loss of active-active is probably a tiny little trade
off of utilization for a huge payback of predictability.

Given that there's only two IP's per node that I looked up, I doubt
active-active is even worth it, given that in a 2 node active-active
cluster, each node has to be able to handle all of the traffic
anyway, otherwise a failure takes the whole service down.




Follow ups

References