From reading, it seems like DNS failover is pas recommended juste parce que DNS n'était pas designed for it. But si you have two webservers on différent subnets hosting redundant content, what autre methods are there to ensure that tous traffic gets routed to le live server si one server goes down?
To me it seems like DNS failover is le seulement failover option here, mais le consensus is c'est pas a good option. Yet services like DNSmadeeasy.com provide it, so there must be merit to it. Any comments?
Pourquoi le basculement DNS n'est-il pas recommandé ?
Re: Pourquoi le basculement DNS n'est-il pas recommandé ?
By 'DNS failover' I take it you mean DNS Round Robin combined avec certains monitoring, i.e. publishing multiple IP addresses for a DNS hostname, et removing a dead address quand monitoring detects that a server is down. Cela peut be workable for small, less trafficked websites.
By design, quand you answer a DNS request you aussi provide a Time To Live (TTL) for le response you hand out. In autre words, you're telling autre DNS servers et caches "you may store this answer et use it for x minutes avant checking back avec me". The drawbacks come depuis this:
- With DNS failover, a unknown percentage of votre users will have votre DNS data cached avec varying amounts of TTL left. Until le TTL expires these may connect to le dead server. **Il y a faster ways of completing failover than this.**
- Because of le above, you're inclined to définissez le TTL assez low, say 5-10 minutes. But setting it higher gives a (very small) performance benefit, et may help votre DNS propagation work reliably even si there is a short glitch in network traffic. So using DNS based failover goes against high TTLs, mais high TTLs are a part of DNS et can be useful.
The more common methods of getting good uptime involve:
- Placing servers together on le même LAN.
- Place le LAN in a datacenter avec highly disponible power et network planes.
- Use a HTTP load balancer to spread load et fail over on individual server failures.
- Get le level of redundancy / expected uptime you require for votre firewalls, load balancers et switches.
- Have a communication strategy in place for full-datacenter failures, et le occasional failure of a switch / database server / autre resource that cannot easily be mirrored.
A très small minority of web sites use multi-datacenter setups, avec 'geo-balancing' entre datacenters.
By design, quand you answer a DNS request you aussi provide a Time To Live (TTL) for le response you hand out. In autre words, you're telling autre DNS servers et caches "you may store this answer et use it for x minutes avant checking back avec me". The drawbacks come depuis this:
- With DNS failover, a unknown percentage of votre users will have votre DNS data cached avec varying amounts of TTL left. Until le TTL expires these may connect to le dead server. **Il y a faster ways of completing failover than this.**
- Because of le above, you're inclined to définissez le TTL assez low, say 5-10 minutes. But setting it higher gives a (very small) performance benefit, et may help votre DNS propagation work reliably even si there is a short glitch in network traffic. So using DNS based failover goes against high TTLs, mais high TTLs are a part of DNS et can be useful.
The more common methods of getting good uptime involve:
- Placing servers together on le même LAN.
- Place le LAN in a datacenter avec highly disponible power et network planes.
- Use a HTTP load balancer to spread load et fail over on individual server failures.
- Get le level of redundancy / expected uptime you require for votre firewalls, load balancers et switches.
- Have a communication strategy in place for full-datacenter failures, et le occasional failure of a switch / database server / autre resource that cannot easily be mirrored.
A très small minority of web sites use multi-datacenter setups, avec 'geo-balancing' entre datacenters.