41. Overview of Route53 for Multi-Site Failover
Hey everyone, and welcome back. Now, in the early lectures, we were looking at various disaster recovery models that can be feasible while designing a DR for an organization. Now today we will have an overview of the demo related to the multiregional active base failure capabilities. So let’s go ahead and understand what I mean by that. So let’s assume that you have one server in the Oregon region and a backup server in the Singapore region or the Mumbai region. Now you are following the multisite-based disaster recovery model. So both of the servers or both of the architectures will look very similar, which includes the instance types as well. And both of the servers will be in running condition. Now that we have a Route 53 record set, all the traffic that will be coming to your website will go to the servers in your primary region. Now let’s assume that, due to some reason, a disaster has occurred and the server within your primary region has gone down.
Now, in the ideal scenario, what you would have to do is, in the middle of the night, get an alarm that the server is down, and then go to your DNS provider to manually change the A records of your host name to point to the backup region. However, when it comes to Route 53, Route 53 has excellent services for failures and health checks. So Route 53 can check to see if the server is up and running. If the server does not respond, Route53 assumes that the server is down and will stop sending traffic over here, instead sending traffic to the backup region in the multi-site based configuration. So definitely, the first time we have to tell Route 53 what the primary region is and what the secondary region is, After that, Route 53 will take care of everything on its own. So let’s go ahead and look into exactly what that would look like. So far, I’ve only got one EC2 instance running. So this is the EC-2 instance running in the Oregon region. Now this is going to be our primary EC2 instance. So this primary EC2 instance is the one that is running over here. And we have one more EC2 instance running in the Mumbai region. Drought 53 will automatically switch all traffic to the secondary site if the primary region goes down or the EC instance in the primary region stops responding. So let’s try this out. So our domain is this one, which is multi-site, this one.
So if I hear it loudly, I’m sure my neighbours will start to laugh. And this is the reason why I just ignore that. So I’ll copy this and paste it into the browser. And now you have a basic NGINX welcome on the Amazon Linux AMI. So this is the index HTML page, which is loading from the primary EC instance. So we have a primary and a secondary based on Mumbai. So I’ll just put Mumbai over here. Perfect. So let us do one thing: slog into primary and then stop. In fact, instead of logging in, let me go directly ahead and stop the instance by itself. So I’ll stop the EC. To instance. So this is basically a disaster in production. So anything that impacts the continuity of business might be a networking issue, an EC2 instance issue, an entire region going down, or your application going down. So all of those are disasters.
So we have stopped the instance. So this can be a scenario of an availability zone going down, the host on which the EC2 instance is running going down, or the entire Oregon region going down. So now what will happen is that route 53 will verify whether the EC-2 instance is responding or not. And if it is not responding, then it will automatically route the traffic to the EC2 instance in the Mumbai region. So let’s quickly verify. Now, within the Route 53 console, let me just click on “refresh,” which takes a certain amount of time. I set it to 30 seconds, but you can certainly reduce it further. After 30 seconds, it will send various checks from various locations, and if it receives a response, it will assume that the AC2 instance is healthy. If it does not, then it will assume that the AC 2 instance has stopped working. So let’s just wait a few seconds for the health check to update. Perfect. If you look at the status of the health check update, you can see that the health check is now unhealthy. So what Route 53 should be doing is automatically routing all the new traffic that comes to that domain to the secondary server. So let’s try this out. And now you can see the message has changed. It has evolved into a multisite architecture. So now this is the failure domain, which is running in the secondary region. So this is exactly how you can design a multi-site architecture. You don’t really need to stick to AWS. It can be between on-premises and AWS as well. Or it can be between OnPremise and other cloud providers.
42. Advanced Route53 Configurations
Hey everyone, and welcome back to the Knowledge Pool video series. And in today’s lecture, we’ll be looking into the advanced Route 53 features that are being provided. So let’s look into what I mean by this. Now, when you look into the managed DNS providers, they generally give a basic set of functionality like domains, registration, and a GUI that allows us to put various types of DNS records like A records, C names, et cetera.
Then it gives us the ability to map and resolve domain names to various types of DNS records, as well as tell us who is in charge. So here’s a screenshot of the name. This is the DNS provider that I use for my domain. So, just to show you, I’ve brought a very interesting domain name. Now, if you look over here, this name.com has a basic set of functionalities, like within the DNS record, you can add various types of records like a Record MX, Record C, and so on. So this is the basic functionality that has been provided by a managed DNS provider. Now, currently, I am using Name, but you can use various other DNS providers like GoDaddy et cetera, and all of them will provide this basic set of functionality. Now, the question that really comes up is that even though route53 is the managed DNS service, if it provides these basic functionalities, then there is no use for me switching my domain from Name.com to Route 53. As a result, there must be some compelling reasons why I should take Route 53. And this is precisely what we will be speaking about today. Now, Route 53 does a lot more. Not only will it perform the basic functions that we just discussed, but it also supports a wide range of advanced features. So the first thing that makes Route 53 really unique is the support of both public and private hosted zones.
So this is something that we already know about. So whenever you create a hosted zone, it can either be public or private, which is connected to the VPC. So this is one thing that we already know. Apart from this, it does a lot of things like latency-based routing, GeoDNS, supports health checks and monitoring, supports DNS failure, and supports weighted routing. Many organizations, particularly startups, now use route 53 as a load balancer. So, because of the great features that route 53 provides, in fact, half of the route 53 documentation in AWS is about the additional features of route 53. So let me just show you this. So, when you go into the Route 53 console, a hosted zone is something that we already know about. So whenever you create a hosted zone, it can be public or private. And if you’re using a private hosted zone, you can attach it to a specific VPC. Now, apart from this, let me show you. Route 53 is home to my domains Mu and Mu.com. And if you go into the “Create record set” option, this is the basic record set that a DNS provider provides. So, if you look over here within name, you’ll notice that when I try to add a record, there are several DNS record types available. Similar record types are available in Route53 with some additional parameters like aliasRecord that we’ll be discussing anyway. So apart from this, if you go a bit deeper, there is a routing policy, and within routing policies there are various types of policies that are present, namely weighted, latency, failure, and geolocation. So these routing policies make Route53 a really strong competitor. Aside from this, there are also health checks. So health checks are basically something that monitors your website, which is where Route 53 sends that traffic.
So this is something that we will be discussing. Along with that, you have great traffic flow functionality where you can actually create traffic policies via a GUI. So this is a visual editor through which you can configure some complex routing policies. So these are some of the additional features of Route 53, and because of this, organisations are now moving their domains from Name.com or from other providers to Route 53. And this is something that I have already done. So if you look into the name servers, currently I am using the name servers of the AWS Route 53 service. So even though my domain is hosted here, the entire name server setup and DNS management are done through Route 53. So this is a high-level overview of some of the advanced features that are being supported by Route 53. In the upcoming lectures, we’ll be discussing some of these and really looking into how an enterprise can use these advanced features for the organization.
43. Route53 – Understanding Health Checks
Hello, and welcome back to the Knowledge Pool video series, where we will continue our lecture journey on advanced Route 53 features. Today we’ll be speaking about a very important feature called “health checks.” So let’s go ahead and talk more about this. So if you remember from the earlier lectures, we were discussing some of the features that Route 53 provides, and one of them is the health checks and the monitoring part. So this is something that we will be looking at in today’s lecture. So let’s begin. Now, Route 53 has a great feature called “health checks.” And health checks are responsible for monitoring the health of a specific endpoint.
So let’s look into what I mean by this. So let’s assume this is the route53 DNS and I have a website. Now, DNS is sending or resolving the domain name to the IP address of the specific website on route 53. So generally, what we want is that if the website is up or not, that monitoring part should be there, and that monitoring part is done with Route 53. So let’s assume that we have enabled the health check. So what Route 53 will do is, either constantly or at a specific time interval, send a request to my website, and if my website is responding back with a 200 or a similar status code, then it will consider that the website is up and running. If my website is not up and running, then Route53 can be integrated with Cloud Watch or SNS to send me an alarm saying the website is down. So let’s look at how that would work. So this is route 53, and this is my website. My website stopped working. Route 53 can send me an alarm, or it can do a lot of different things. So one of the examples I can show you is that it can automatically route all my traffic from this domain to my backup domain, which will have a “We’ll be back soon” page. So this is something that routes 53 can do automatically because if your website is down, you will not get this page directly. You might get some kind of 500 internal server error or something similar. So if you have a static page in your S3, route 53 can do failover routing.
That is, if this website goes down, it can automatically redirect to another server. So this is something very interesting that route 53 already does. So we’ll be looking into this in the upcoming lectures. But before we get into the timing, let’s take a look at how we can configure basic health checks. So this is my Route 53 console, and these are my health checks, if you look at my console. And if you’ll see, I have a OneHealth check that has already been created. If I show you, this health check is for Mu and Mu.com. Now the protocol is http, and let’s look at what exactly it does. So this is basically my server, where my website is hosted. I’ll just open this up in my browser, and you’ll see it will have a default NGINX page. Let me echo the VAR log and the NGINX access log now. And let us do a tail on this one. And as you can see over here, you’re getting a lot of get requests. You see a lot of requests from the Amazon Route53 health check service and the associated domain name associated.
If you see that you’re getting the health check requests from various IP addresses, which are quite different, So this ends with 13. Then you have 237, and you have 173. Then you see that you have 177 IP addresses. So you’re getting requests from a lot of IP addresses. And basically, this is the response code. So whenever these IPs get the response code 200, which means everything is okay, then Route53 will consider the website to be up. So let’s do one thing. The time interval is currently 30 seconds if you see it as healthy by default. So let me manually shut down my NGINX server. So now, whatever request comes to my blog, let me just show it to you. See, if I just refresh, you can see the site can’t be reached because I have stopped my NGENX. Now, essentially what would happen here is that the health check that I have created should fail. So currently, the status is healthy. Let’s wait for some time. Currently, the time interval is 30 seconds. We’ll wait for the 30 seconds to complete, and then we’ll see whether the status is updated or not. See, you can always increase the time limit. So currently, if you see the request interval is every 30 seconds, you can increase it at any time or decrease it, but it comes with a price. So this is really what it’s all about. Perfect.
So now you see, Route 53 is basically showing a status of “unhealthy.” That means that Route 53 sent certain requests. The Route 53 Health Checker Service If you see this, this is the Route 53 health check service. It sends certain requests to my domain, but I did not get a response back. So you go to the site, and it appears that no response has been received. And this is the reason why Route 53 is down, considering that the website is down. Now, along with this, you can definitely integrate the Route 53 health check with an alarm. So this is integrated with Cloud Watch and SNS services. So let me just try and open up my email, and I can show you that I have received an alert from the Route 53 health check service. So you will see that this is an alert saying that my website is down. So this is the basic information about Route 53 health checks and monitoring. In the upcoming lectures, we will look into how we can actually configure this specific hatch that we have been having a demo about. So this is it for this lecture.
44. Route53 – Implementing Health Checks on NGINX
Hey everyone, and welcome back. Now, in the earlier lecture, we were discussing Route 53 hell checks. And we had done a simple demo on how exactly a health check would really work. So what we’ll be doing today is configuring our first health check. So before we do that, let me actually delete the health check that I had configured earlier. Now now before we do that, we have tomake sure that our website is up and running. So what I’ll do is start my NGINX. So I’ll say System CTL, start NGINX, and just quickly verify our domain is up and running. Perfect. So once that domain is up and running, you can go to Route 53, go to Hell Checks, and click on Create a Health Check.
You must now give the hell checks a name. So I’ll say the KP Labs video course. For the time being, I’ll just call this Endpoint and monitor it. Now, within the second section, which is Monitor and Endpoint, you have two options. One is the IP address, and one is the domain name. So for my case, I’ll use the domain name directly, and I’ll copy the domain name that I have within the domain name section. Let’s remove this. As a result, the protocol will be http. Since I don’t really have an https for Munmu.com, I’ll use the http domain. This is the port, and within the advanced configuration, you have a request interval. So the request interval is simply how long Route 53 should wait before checking to see if my domain is operational. So the standard is 30 seconds. But you also have Fast, which runs every 10 seconds.
But remember, everything comes at a specific price. So since we are doing a demo, we’ll be using a standard of 30 seconds. The failure threshold will leave it alone for the time being. And the next thing that is very important is the health of the reproductive regions. So the “health checker region” is basically the region from which the request will be sent to my server. So by default, if you must have seen, I was actually getting requests from various IP addresses. So, somewhere between 54 and 177. So Route 53 Health Checker Service was actually sending me traffic from various servers. And these servers actually belong to a specific region. Now, you can customise it according to your needs, but for the time being, I’ll use the recommended one I’ll go to next. Now, if the question is, “What happens once the health check fails?” Should you get notified? And the answer is yes, I would like to be notified if my website is not working. So for this, you need to click on Create Alarm.
And here you have to put a SNS topic data.So I’ll select a new SNS topic. I’ll say KP Labs, and the recipient will be the instructors at KP Labs, and I’ll click on Create Hell Check. As a result, this is the hell that we have created. Now, the status is unknown right now because it will take a certain amount of seconds for this to get updated. Now, since we have created an alarm, let me select. We have created an alarm. We have to approve the SNS-related functionality. So if you go to an email, you will see that I have received the AWS notification. Everything is fine after I click on “Confirm notification.” So now the notification is confirmed. As a result, SNS will now be able to send us email flawlessly. So let’s wait for some time—I would say a few seconds—for this status to get updated. For now, let’s perform an audit on the Warlock NGINX access log. As you can see, you’ll now begin to receive requests from the Route 53 service for the domain. And you see that the status is now healthy. So let’s do one thing. Let’s verify both the scenarios. Now I’ll stop the NGINX. I’ll say “system cs: stop NGINX.” And again, since we have a threshold of 30 seconds over here, we need to wait for 30 seconds for the Route53 held check service to send requests to our domain. So let’s wait. As a result, alarm is currently one of one in OK. Now let’s wait a few seconds, and we’ll see the alarm go off. So let’s quickly verify that munu.com is not working. Perfect. And patience is a virtue.
So let’s wait for some time. Perfect. So now you will see that the status is currently unhealthy. And the reason for this is that Route 53 sent a request to a domain where no web server was listening, so no one responded. And this is why the status has deteriorated. Now, if you go into the monitoring section and just click on the monitoring section, it will actually give you a nice little graph related to the healthcheck status related to our domain. So this is one important part that we need to look into. Now, the second part that we have to look at is the alarm section. So, once the website is unhealthy, we should either receive an alarm via email or even SMS saying that the website is unhealthy. So if you go into the alarms, you see now that the alarm went from one of “okay” to one of “alarm.” So this is the state. As you can see, the state has shifted from OK to alarm. So now, since this cloud watch is configured with SNS, we should ideally receive an alarm saying that the website is down. So if I go into my Gmail, you’ll see that Route 53 has sent us an alarm. Basically, SCS and SNS both sent us a notification that my website was down. So this is one of the methods for making Route 53 Hell checks. Now, there are a lot of interesting things that you can do once the “Hell Check” part is up and running. As a result, some of these topics will be covered in upcoming lectures. I hope you got the basic overview of the practical aspect of how you can configure Route 53 hell checks. I would really recommend that you try this out because these are some interesting things that are very useful in organizations. So this is it. About this lecture: I hope this has been formative for you, and I look forward to seeing you in the next lecture.
45. Route53 – Understanding Failover Routing Policy
Hey everyone, and welcome back to the Knowledge Full video series. Now, in the earlier lecture, we were discussing how we could create a basic health check in Route 53 that would send us an email alert when the domain was down. Now, this is a very simple way of doing it. There are a lot of additional things that you can do after the domain goes down.
So let’s look at the PowerPoint presentation. So this is something that we discussed earlier as well. So you have Route 53 over here, and you have a server. So you’ve configured a health check from Route 53 to your server. If your server goes down, Route 53 will send you an email informing you that it is down. So this is something that we have looked for. Now, one additional thing that we can do is, once Route 53 sees that the server is down, instead of sending the traffic to this server, which is not working, it can automatically do a failover to another server, which might have a similar website or a maintenance page saying that we will be back soon. And this is something called “failure routing.” Now, this is something that you will find on most of the websites, because if the website itself is down, then you will get a temporary maintenance page saying that the website is coming soon.
So this is something that we’ll look into to see how exactly it will work based on Route 53’s failure. So let’s do one thing. I have my Route 53 over here, and within the health check, you will see that I have the status “healthy,” and Alarm is also one of them. And okay, now what I have done is create a domain called Failure Munmu.com.And when I press Enter, you will see that I have an NGINX page up and running. Perfect. So what I’ll do is stop my NGENX systemctl. Stop NGINX. Perfect. So now we have stopped our NGINX web server. So what we are simulating right now is a web server that is not working. So after Route 53 HealthCheck detects that this web server is not working, it will automatically fail over to another website that I have configured in the failover routing policy. So let’s quickly refresh the page and wait a few seconds because our interval is 30 seconds. So we’ll wait for the status to become unhealthy. Perfect.
So now the status has become unhealthful after a few seconds. So now what has happened is that this web server has stopped working. As a result, Route 53 will now handle any subsequent requests for this specific domain, failover munme.com. It will not send it to the web server. It will send it to the maintenance space that we have configured. So let me just refresh this page again and see what exactly has happened. Now, as you can see, it has gone to the maintenance page, saying the site is under maintenance. So this is the page that we can configure accordingly. I’m too lazy to write decent HTML code. So this is a simple text file that I have written for our text purposes. Now, you might be wondering how we did that. Let me just quickly show you the overview. So within Route 53, there are two policies that I have configured. You see, there are two records for the failover subdomain.
Now, this is the primary record, and if the page stops working, then it will fall to the secondary record. So if you will see over here, the failover record type is secondary, and in the first, the failover record type is primary. So if the primary goes down, then route 53 will switch to the secondary record set, and it will go to the alias target that is configured over here. So this is exactly how the failure routing policy really works. So, this is it. In this lecture, I hope it has been informative for you and has given you an overview of what a failure configuration might really look like. So in our case, this is a maintenance page, but depending upon your configuration, this can be another web server in some other region as well. So, depending on the policies and SLAs that your website has, the way you do routing may vary greatly. So this is it for this lecture. I hope this has been formative for you, and I look forward to seeing you in the next lecture.
