launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04334
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