AWS Route53: DNS Failover Now Supports Elastic Load Balancer
Hello friends! 
Just recently, an astlock article about DNS filer was released. The feature is certainly cool and comfortable, but those who hosted AWS big projects with ELB did not feel the new at all. If the filer does not work with ELB, then this function is absolutely useless to me personally.
But then the day came when it became possible to use the benefits of Route53 together with ELB. Adjusting the record in the Failover mode and connecting it to the ELB, we thereby enable the automatic monitoring of the ELB. Switching the recording from Primary to Secondary will occur automatically in the following situations:
Route53 now allows you to automatically move in case of failure of the entire region,
')
In this article I will tell you how I tested the new functionality.
So, for tests I set up 2 ELBs and one instance under each of them. On one, I put Apache, and on the other nginx, to distinguish between them.
Route54 was configured as follows:
As you can see, one entry is Primary, the other is Secondary.
In the normal state, the domain test.kozhokaru.com shows the Apache page, i.e. our live application.
Domain point:
For the test, we go to the host and stew the apache, thereby imitating the fall of the application. And we begin to look at what is happening on our web page:
After about 40 seconds, ELB understands that the instance under it is not healthy:
And after another 2 minutes we get a filer page:
IP address has changed:
We return everything back by running Apache on the first host. Depending on your helchek on ELB, the host will be healthy after a certain amount of time:
And after 1 minute 40 seconds, the domain returned to the main ELB.
IP address changed back:
The automatic domain name file takes about two minutes , returning back somewhere.
Now we have a great feature in our hands that will undoubtedly help us in building highly accessible distributed systems .
Just recently, an astlock article about DNS filer was released. The feature is certainly cool and comfortable, but those who hosted AWS big projects with ELB did not feel the new at all. If the filer does not work with ELB, then this function is absolutely useless to me personally.
But then the day came when it became possible to use the benefits of Route53 together with ELB. Adjusting the record in the Failover mode and connecting it to the ELB, we thereby enable the automatic monitoring of the ELB. Switching the recording from Primary to Secondary will occur automatically in the following situations:
- failure and unavailability of ELB
- lack of healthy instances under ELB
Route53 now allows you to automatically move in case of failure of the entire region,
')
In this article I will tell you how I tested the new functionality.
So, for tests I set up 2 ELBs and one instance under each of them. On one, I put Apache, and on the other nginx, to distinguish between them.
Route54 was configured as follows:
As you can see, one entry is Primary, the other is Secondary.
In the normal state, the domain test.kozhokaru.com shows the Apache page, i.e. our live application.
Domain point:
$ host test.kozhokaru.com test.kozhokaru.com has address 23.21.77.253 For the test, we go to the host and stew the apache, thereby imitating the fall of the application. And we begin to look at what is happening on our web page:
After about 40 seconds, ELB understands that the instance under it is not healthy:
And after another 2 minutes we get a filer page:
IP address has changed:
$ host test.kozhokaru.com test.kozhokaru.com has address 107.21.245.152 We return everything back by running Apache on the first host. Depending on your helchek on ELB, the host will be healthy after a certain amount of time:
And after 1 minute 40 seconds, the domain returned to the main ELB.
IP address changed back:
$ host test.kozhokaru.com test.kozhokaru.com has address 23.21.77.253 findings
The automatic domain name file takes about two minutes , returning back somewhere.
Now we have a great feature in our hands that will undoubtedly help us in building highly accessible distributed systems .
Source: https://habr.com/ru/post/181942/
All Articles