3 ms·

How does failover across zones work? The blog post says there's one static ip per zone. I suppose www.mydomain should have multiple A records each pointing to

How does failover across zones work? The blog post says there's one static ip per zone. I suppose www.mydomain should have multiple A records each pointing to an elastic ip in a zone. What happens when one zone entirely fails? Does it need a DNS change at this point? Or does the NLB have a different IP with which it can do BGP failover?

felipelemos 9y ago
This is a job for a CDN
krallin 9y ago
AWS provides you with a number of DNS records for each NLB: - One record per zone (which maps to the EIP for that zone) - A top-level record that includes all active zones (these are all zones you have registered targets in, IIRC) The latter record is health checked, so if an AZ goes down, it'll stop advertising it automatically (there will be latency of course, so you'll have some clients connecting to a dead IP, but if we're talking unplanned AZ failure, that's sort of expected). That said, this does mean you probably shouldn't advertise the IPs directly if you can avoid it, yes. (disclaimer: we evaluated NLB during their beta, so some of this information might be slightly outdated / inaccurate)
- deafcalculus 9y ago
  Won't DNS failover be painfully slow? Some clients ignore small TTL values. I've seen DNS updates taking several hours to propagate. I thought one of the advantages of multiple zones is that zonal failover can happen with "zero" downtime (this seems to be the case with Amazon RDS).
  - colmmacc 9y ago
    The default answer includes multiple A records, so if clients can't reach one of the IPs, they try another. There's no need for anything to propagate for that to kick in, it's just ordinary client retry behavior. We do also withdraw an IP from DNS if it fails; when we measure it, we see that over 99% of clients and resolvers do honor TTLs and the change is effected very quickly. We've been using this same process for www.amazon.com for a long time. Contrast to an alternative like BGP anycast, where it can take minutes for an update to propagate as BGP peers share it with each other in sequence.
  - mooreds 9y ago
    RDS failover still uses DNS and you still need to be aware of client TTLs: "Because the underlying IP address of a DB instance can change after a failover, caching the DNS data for an extended time can lead to connection failures if your application tries to connect to an IP address that no longer is in service." http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_B...
jon-wood 9y ago
I assume they intend for you to use Route53 on top of this. You could use a combination of geolocation routing and failovers to set it up so that by default people are routed to their nearest region, but if that region is currently offline send them somewhere else instead.

felipelemos 9y ago

This is a job for a CDN

krallin 9y ago

AWS provides you with a number of DNS records for each NLB: - One record per zone (which maps to the EIP for that zone) - A top-level record that includes all active zones (these are all zones you have registered targets in, IIRC) The latter record is health checked, so if an AZ goes down, it'll stop advertising it automatically (there will be latency of course, so you'll have some clients connecting to a dead IP, but if we're talking unplanned AZ failure, that's sort of expected). That said, this does mean you probably shouldn't advertise the IPs directly if you can avoid it, yes. (disclaimer: we evaluated NLB during their beta, so some of this information might be slightly outdated / inaccurate)

deafcalculus 9y ago
Won't DNS failover be painfully slow? Some clients ignore small TTL values. I've seen DNS updates taking several hours to propagate. I thought one of the advantages of multiple zones is that zonal failover can happen with "zero" downtime (this seems to be the case with Amazon RDS).
- colmmacc 9y ago
  The default answer includes multiple A records, so if clients can't reach one of the IPs, they try another. There's no need for anything to propagate for that to kick in, it's just ordinary client retry behavior. We do also withdraw an IP from DNS if it fails; when we measure it, we see that over 99% of clients and resolvers do honor TTLs and the change is effected very quickly. We've been using this same process for www.amazon.com for a long time. Contrast to an alternative like BGP anycast, where it can take minutes for an update to propagate as BGP peers share it with each other in sequence.
- mooreds 9y ago
  RDS failover still uses DNS and you still need to be aware of client TTLs: "Because the underlying IP address of a DB instance can change after a failover, caching the DNS data for an extended time can lead to connection failures if your application tries to connect to an IP address that no longer is in service." http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_B...

jon-wood 9y ago

I assume they intend for you to use Route53 on top of this. You could use a combination of geolocation routing and failovers to set it up so that by default people are routed to their nearest region, but if that region is currently offline send them somewhere else instead.