2

The setup is one server (Windows 2008) at one location with two incoming connections. As the server has to interface with various on-site devices, and will have a small number of incoming connections, a data center is not an option, and instead cable/dsl connections must be used.

The goal is that users visit https://service.site.com and are sent to either the primary IP address or a secondary IP if the primary is down.

I've seen advice to use round robin DNS for this, but caching an IP for a downed interface is something I'd like to avoid.

Is something like this possible with these constraints?

3
  • Hmm... but you only have one server. If it's down where are you going to send incoming connections to?
    – joeqwerty
    Oct 27, 2012 at 15:00
  • At the moment the concern is for the cable/dsl links going down, as this has been the case historically. In the future a second server will be added, but also at the same physical location.
    – CrassHoppr
    Oct 27, 2012 at 15:12
  • Use dynamic DNS - see my answer here: serverfault.com/questions/169525/…
    – Sandman4
    Oct 28, 2012 at 8:30

2 Answers 2

1

Most browsers will try alternate available addresses, if the first connection attempt fails. But this is obviously implementation-dependent, there is no RFC directive or recommendation for it. So if you need to be sure, you would have to modify your DNS zone and remove the failed link's IP address. The caching issue can be handled by decreasing the TTL to a low value - 300 seconds are rather common and a good trade-off between caching efficiency and currentness of data.

A possible issue with DNS RR is that there is no way to specify any kind of priority for DNS records (short of being able to use DNS SRV records due to lack of browser support), so clients are going to send requests to both addresses due to rotation of records in a DNS response. If one of your links is more "expensive" (in whatever terms) than the other and you would not have it used unless the primary link fails, DNS RR is not the right solution for your problem.

Another option would be using a reverse proxy at an alternate location / over an alternate link (supposedly having a better uptime than your DSL/cable link - e.g. a virtual machine in a data centre) which would actively monitor your two connections and handle the failover automatically without the need to change DNS records.

1
0

Is something like this possible with these constraints?

No.

When you have a load balancer with multiple servers behind it, there is a requirement that the load balancer will always be online. There are multiple ways to have this, for example, the load balancer might not actually be one server - it might be many that are pretending to be one. If one fails, another takes over.

However, there is the assumption that at the remote end, there is something there to serve the request.

If you find yourself in the situation where the link goes dead, then packets will not reach your server - and there is absolutely nothing you can do about this. DNS RR is the next best thing, because you are telling the client to go and try another IP address. Otherwise, the client will merrily retry the same IP, and get no response, and give up.

The frontmost service must always be accessible for any of this to work. Without that, it simply cannot. HA solutions generally assume the links are good. Yes, there are things like datacenter level failover (e.g. for a country level powercut), but they also have associated downtime will the traffic converges to a different set of IPs - it will never be instant.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .