Introduction
Downtime is unavoidable in IT infrastructure and there are so many factors which can cause downtime to our applications that may be due to some physical risks such as natural disasters or some technology failure or even a security breach. But we can make our applications highly available if we design our system highly available and highly reliable. Here in this blog, let’s see how we can make our application highly available with a sample illustration.
What is High Availability?
Availability is used to describe the period of time when a service is available, as well as the time required by a system to respond to a request made by a user. High availability is a quality of a system or component that assures a high level of operational performance for a given period of time. Such as the system will be up for 99% or 99.9% or 99.999% of the time. We must have some SLA’s configured for this as well.
What makes the system Highly Available?
Avoiding single point of failure. Check your system design and see where all you have single point of failure and avoid everything with better design approach. That doesn’t mean you can put load balancer on each and every service you run in your infrastructure. As mentioned above, you should always look for better design approach with minimal downtime, operational maintenance with better performance in a cost effective manner. Let’s see how we can do that for the below architecture.
Architecture of sample application
Let’s say you have an application called app.example.com which resolves to the load balancer and load balancer will send the request to the group of application servers and it is backed up by the primary and backup database servers. The architecture looks pretty decent and seems Highly Available (HA). But when you look for single point of failure, you can easily find it in this type of architecture. Yes, you guessed it right! The load balancer is a single point of failure. If load balancer is not available due to any reason your whole application will be gone, even though your application and database server works fine, still the users may think that the application is down, since no body remembers the ip address of the server and that is not constant too.
HA load balancing using AWS Route53
Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. It is designed to give developers and businesses an extremely reliable and cost effective way to route end users to Internet applications by translating names like app.example.com into the numeric IP addresses like 192.0.2.1.
There are various routing policies which are available in Route53 which helps us to achieve high availability. Here we are going to see 2 routing policies.
- Failover Routing (Active-Passive architecture )
- Mutivalue Answer Routing (Active-Active architecture )
Failover Routing
Create new public domain in AWS Route53 and create record set for your application. Here we created a domain example.com and creating record set for our application server. Also, we are adding a new health check so that route53 detects the failure of the service and switch the failover.
Health Check
Repeat the same for failover record also, just change the ip address to the secondary server.
I used private ip for demonstration, you can use your application public ip while creating record set and health checks. This failover routing is basically active-passive mode, and the secondary server (i.e. the failover server) will never take any traffic till when there is a failure happens in the primary. It’s more like we are keeping the infrastructure and not using it fully. To overcome this we have multivalue routing policy is available in Route53.
Multivalue Answer
As the name mentioned, it will provide multiple value as answer when Route53 is queried. Also create health check as mentioned earlier for both the record sets.
How is this better than failover policy?
Since Multivalue Answer Routing policy always returns for all the ip addresses, the traffic will be automatically routed to all the load balancers behind it, thus enables always active-active mode of high availability. Also if there is any issue with any servers, health check will detect it and report to route53, so that when resolving for the next time route53 will not respond the failed server and will respond the ip addresses of the server where health check is passing. Using this policy you can utilize your infrastructure fully and create highly available infrastructure.
