RE: BGP / GSLB and HAProxy

Willy,

> It's very
> common to see HTTP proxies configured with DNS caching for 24
> hours.

We have noticed some issues with this, however, thankfully, they don't seem to have a major impact on our customer base. It seems clear that we will want to address it with this iteration of our edge farm design.

> 1) multiple RRs

> But in this case, use BGP and manipulate
> the weights so that one site can never take over the other
> one as long as the other one is up.

This is interesting, and something I hadn't considered before. In the event that a users's ISP lost connectivity with our primary hosting center, they would then be routed to the secondary site as announced by BGP. So we would still see some traffic coming to the secondary site?

> But if you want to improve locality, then you cannot play
> with multiple RRs.

Unfortunate, it seems clear we'll need to stick with the current strategy of country specific URLs. On the upside, if service is down for an given international location with locally hosted site, they can still access the main site.

> 2) direct access from the browser to the RR records

Hadn't considered the proxy aspect, doesn't impact too many of our customers, but it's an important point.

>
> 3) TTL
> as said in 2) you have very little control over what people
> do with the TTL,
> and there is even a risk of being blacklisted by some
> providers if you run
> with too low TTLs which put a lot of stress on their DNS
> forwarders (eg: one
> minute).

I've never heard of this type of policy, by provider do you mean a external DNS provider that is hosting your DNS; or a customer's ISP DNS might blacklist us (rather than just bumping the TTL like some do).

> > at multiple sites. There are articles on the subject [1]
> that suggest
> > that this is relatively low risk (1 in 10000 requests?),
> but I always
> > fear the consequences for a client who has a route flap.
>
> I agree with this and honnestly it's not what I'd recommend
> the most.

I'm glad to see that I'm not the only person concerned with this :)

> you were speaking about the closest site, so... In fact, you
> must keep in
> mind that you will never have more than 2 out of the 3
> following features :
>
> 1) availability
> 2) nearest site
> 3) scalability
>

An interesting twist on the usual pick 3. I think we'll concentrate on 1 & 3, and then, for targeted geographic regions, deploy a domain specific solution to address locality. Thankfully, for us, the site that a customer connects to has little impact on our scalability.

> Also, if you can afford a dedicated link (redudant) between
> your front routers
> and set up a local preference for each IP, then you've won,
> because you can
> announce your IPs from wherever you want, and the final step
> will be performed
> by those routers for customers entering via the wrong site.

Thankfully, I do enjoy a very high capacity, redundant link that between our primary and secondary site. We have a third site that is not linked in such a manner, but we don't necessarily need to route so much front end traffic into it, and could instead switch over to it in case of cataastrophic failure.

By encapsulated, I had meant a GRE, IPSec or similar tunnel over the Internet, which would of course break if you lost internet access.

>
> > Of course, another approach would be a high speed redundant back end
> > link, independent of your internet service. In such a case,
> you could
> > use anycast, but have the IPs answered by HAProxy only at the local
> > site. As long as you don't drop your the backend link the potential
> > route flapping issues of anycast would be completely mitigated.
>
> Yes that's true too. But sometimes it's harder to provide big
> backend links
> because data may circulate unciphered there, or might be
> considered more
> sensible.

I also have the means to provider secure encapsulation on the backend link, so we can have this public network traffic transit there, in a secure fashion.

>
> If your sites are really far apart, you should avoid layer 2
> as much as
> possible. The latencies you can encounter on long distance links may
> sometimes cause some IPs to appear for a short time on a site then
> disappear.

None of the sites are really far apart. The third site is 200km away, the first two are quite close. Is 200km "really" far apart?

> Yes it is interesting, but unfortunately it is hard to find
> people to discuss this subject.

Couldn't agree more. On this subject, if you are speaking at or attending any relevant conventions? Let me / the list know.

> BTW, you may be interested in a short article I
> wrote last year
> as an introduction to load balancing. Maybe you will like to

I read it when I was considering different content load balancing options. Interesting indeed.

Thanks for all your help,

-JohnF Received on 2007/12/20 23:30