launchpad-dev team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 17 August 2010 02:00, Elliot Murphy <elliot@xxxxxxxxxxxxx> 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 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...