Hey, today I will explain to you, What is high availability? How do you make replications highly available? And what is all the talk about those nines? Let’s find out.
High availability is a huge topic. So we’re not going to be able to cover everything in this post. So we’ll make a serious out of this. And today, we will only look at the definition of high availability. Then we’ll talk about the nines, triple nines, quadruple lines, we’ll see a sample architecture and you can see how easy it is to build a highly available infrastructure and a highly available, maybe a web service or an application with cloud technology in multiple availability zones and multiple regions.
So what is high availability or HA as it's sometimes called essentially when we're talking about an application, a web service, a website, whatever. We want to make it available right. Available to your customers, to your users. And when it's functioning properly, the way you intend for your application to function, we talk about uptime. So it's available. It's online. People can reach it when something is not available, which can be planned maintenance or, you know, some issues during the deployment or whatever.
Table of Contents
Five Things You Need To Know About What Is High Availability
Then we’re talking about downtime and high availability, so we want to maximize our uptime and minimize the downtime. And this brings us immediately to all of those nine strip lines for Drupal lines. This is just a number, a percentage number that describes the percentage of time that your application, your web service is in a full year.
So with 90% availability, we’re talking about 90% of a full year. So 365 days, in a year. And with 90%, it means the replication is down, not available for 10% of this whole year, which results in 36 and a half. So this is huge, right? No modern application would be okay. And customers would use it if it was offline for a full month, more than a month in a calendar year.
So in modern applications, we strive, for example, for 99.9% of availability in the full year, which results in about nine hours of downtime. And this is what we call a triple nine. And for example, in quadruple nine, 99.99, we would only be allowed to have planned or unplanned downtime for about 52 minutes for a full year.
So you can already see that both nine hours and 52 minutes are not a lot of downtimes. So in both of those cases, we cannot. Take our flying for, you know, let’s say weekly plan maintenance as we would do in the past. Frequently, um, it’s just not enough time. So we have to find ways to not only make us, or minimize our unplanned maintenance, you know, box broken deployments, network issues.
We also have to plan our planned maintenance. How do we make, you know, let’s say, database updates and these kinds of things. So. Our availability stays high. We cannot afford to take out or take offline our database. If it’s a single master database for a few hours every week or every month, we have to consider many aspects for an application to be highly available. So there is an architectural aspect.
Design High Availability Infrastructure
How do we design our systems and our infrastructure? How do we connect it in a way that ensures high availability? Then we need to take care of testing and QA. So how do we make sure that the architectural decisions and mechanisms that we put in place are being tested on an ongoing basis every day or every week or whatever?
It may be third. We have to think about deployment strategies and change management strategies because things change, you know, database chemos change code changes all the time. Capacity changes. How do you make it that even if all of the teams in an application or, you know, contributing to an application, maybe in a microservice environment, can deploy without affecting each other in their uptime?
And lastly, we have to cover organizational aspects. How do you have, or how do you make people aware if things go wrong? We talk about monitoring and alarming, but also having people on, let’s say, PagerDuty developers or operations folks that if something goes wrong and you know, maybe it’s in the middle of the night that they are available.
High availability Architecture
Before we jump into a simpler architecture, let’s talk about some of the prerequisites of making architecture highly of. In the past, if you think about an on-premise environment where you would run your hardware, or maybe you would rent a space and hardware somewhere. You would deploy your applications your code to those on-premise environments.
If you wanted to make your infrastructure highly available, you would need to have multiple of those physical locations. Because what if, you know, one of those buildings, one of those data centres, burns down. It happens. What if, um, there are, you know, power outages or somebody trips over a cable, All of that stuff can happen. So we need to distribute our application and our code on multiple machines and across multiple physical locations.
And you can already see where I’m going in today’s world. This is possible even for small companies and, you know, even freelance developers because they can leverage cloud technologies. For example, AWS offers 25 geographical regions for you to use, and really with a few clicks, you can take your applications, and you can make it so that they run and deploy.
Benefits of high availability
Let’s say America in Europe and next. And there is absolutely no, you know, the effort for you to be at those physical locations. Have people there employ people there, no maintenance for you. It makes it easier to design and build a highly available system because you can leverage those regions, those Datacenters in very, you know, distributed and diverse geographically.
Its cloud technology is an enabler here. And for example, with AWS, Right now, as we're speaking, five new regions are coming up: Switzerland, Spain, we have Jakarta, we have, and have Melbourne. So that brings us to 30 regions. And if you keep thinking along those lines, you will see that this opens up more interesting possibilities and options.
With multiple regions, you don’t have to leave you, let’s say failover region, just there as a, as a standby. It can take traffic as well. Right? So you could have, let’s say, one region in Europe and one in Asia and, region. So your application in that Asian region would be taking trips.
This area is great for your customers because they’re closer to that region. And so latency would decrease. And on top of that, you can think of interesting deployment strategies. So instead of deploying, you know, all of your new code to a single machine, so essentially taking out that single machine and replacing the code on that machine with the new code, you can now do.
You know, gradual deployments, maybe you switch only, the code on one of the easy two instances in one availability zone. Then gradually, you deploy to the other machines after a certain time. So you want to make sure that your code is running in a productive environment. It's running fine there. It doesn't trigger any alarms.
And then you would start deploying into those other availability zones or even into those other regions. So what’s the idea here. We want to take our application, which may run only on a single machine today, and we want to deploy it to multiple so-called availability zones. So, in other words, in multiple, for example, data centres, and on top, we even want to deploy it into multiple regions so that your application, your, and your data store.
In multiple data centres. It’s also stored on different continents, for example, and many big companies. And also, you know, small companies do that today because it’s so easy and you can do it as well.
learn more: what is the log4j vulnerability | What is XDR Technology | Cyber Security
elearninginfoit youtube Channel |if you have any Query | elearninginfoit |