2011/7/24 Willy Tarreau <w(_at_)1wt(_dot_)eu>:
Ok, but what would be the failover solution then? any failover
solution can take some time until redirects the client's request to a
working server, it's not just a client problem.
This is already addressed by existing web architectures. DNS provides
geolocation and proposes you the closest working datacenter. BGP ensures
that this datacenter is always reachable via multiple links and multiple
providers. Load balancers on the site ensure that only valid servers are
used. I know some people who configure their load balancers so that a
server is removed from the pool less than 50ms after a failure or slowdown
has been noticed. You will never be able to offer that quality of service
using DNS only, because those 50ms are less than the time it takes for
most visitors to ping the site.
Yes, but those are expensive server side solutions. I wouldn't like
that a scalable architecture requires so complex solutions (which are
not very suitable in case of usual web hostings). DNS SRV provides a
cheaper way of doing something similar (both ways can live together
Anyhow, don't forget that SRV is not just for failover, but also for
load-balancing (you can state that a more powerful server-01 receives
80% of the traffic and server-02 the remaining 20%).
This is already addressed by DNS round robin and used by a lot of sites.
I consider that a hack.
But keep in mind that DNS is used between *sites* and not *servers*. If
you use it for servers, you'll fail because you won't be able to silently
put them in maintenance without disturbing visitors.
SRV provides load-balancing and failover. I never said that SRV is a
solution for temporaly put in maintenance a server.
Load balancers are
used for servers. And between sites, people are not seeking imbalanced
distribution. If they really do, then it's easy using multiple addresses.
Don't take this as an attack (it is not), but you accused Roy of not
knowing SRV, but I think that you're not much experienced with web
infrastructures and that may be why you think that SRV is the *only*
solution to many problems that have been dealt with for ages.
Right, but I'm used to scalable and big SIP infrastructures and DNS
SRV is used for that (along with server side solutions as SIP load
balancers). What I say is that web infraestructures cannot use SRV
mechanism so it's not valid for me that just current HTTP solutions
are valid for any other new protocol.
In contrast it seems that for many people the hacks existing in HTTP
world (www.facebook.com resolves to a single IP) is the only way to go
for a scalable infraestructure "so DNS SRV is not needed". Why so many
efforts in disallowing an *optional* mechanism like SRV? If somebody
does not like it, just don't use it.
Iñaki Baz Castillo
Ietf mailing list