Understanding High Availability & How to achieve it?
High availability refers to systems that are durable and likely to operate continuously without failure for a long time. This also implies that the system is fully tested and there are accommodations for the failure of the redundant components. In a simple way, Our application must have the ability to handle and overcome the Single Point of Failure.
Usually, High availability is achieved by scaling the servers those up and down based on the load and availability of the application server. Although it is done mostly outside the application(at Server Level), Several characteristics of application have to be compatible for this to work seamlessly.
Scaling
There are two types of scaling, (google for more details)
- Horizontal Scaling
Adding more machines into your pool of resources - Vertical Scaling
Adding more power (CPU, RAM) to an existing machine.
Most applications will be hosted on the multiple servers and they will be connected via Application Load Balancer, so when a client requests for a resource or action to the application it will be passed to Load Balancer and it decides to which server the request must be routed based on the defined set of algorithms(Configurations). We can Scale the applications based on the load balancer listeners.
High availability is a quality of infrastructure design at scale that addresses the increased system load is a common concern, decreasing downtime and eliminating single points of failure. — Erika Heidi
What is Load Balancer ?
A load balancer is a device that acts as a reverse proxy and distributes network or application traffic across a number of servers. They are used to increase the capacity and reliability of the applications. Also, there are different types of load balancers. (Check the Reference Section).
Let us see what are the components we need to have a look to make our applications scalable,
Web Applications
To enable High availability in the Web Application, We have to consider and reevaluate the below points.
- Session State
- File Storage (files uploaded to the server, Application Logs, etc.)
Session State
Web Applications usually maintains session state to remember the users logged in, these are usually stored inside the application server. In case if the request is redirected to another server when it comes via load balancer where the session is not available then that request will fail.
To handle this failure, We need to isolate the session state to different storage like SQL databases, NoSQL DB’s or any other temporary storage(Redis).
File Storage
If we have user-uploaded files stored in the server and suddenly server crashes, Single Point of Failure occurs as we cannot recover them.
Do not store any file in the application server because it cannot be always recovered if that server goes down. Do have separate file servers to upload the files like AWS S3, Azure BLOB, Google Cloud Storage, etc.
Logs can also be written on the file server or use any DB storage different from what the application is using.
Scheduled Services
Every project will have a service that listens to a particular event or data and process the data based on input. When multiple services are listening to one event or data, it can be processed multiple times.
So these services code should be idempotent, else we must have the resource locking mechanism so that if the event or the data is already processed we must skip them.
Databases
This is the most important element of the application, Each and every screen or Action on the application fetches data from the DB. Enabling high availability on the database server is so challenging, We have to be very careful on enabling load balancing or Scaling.
To achieve high availability on the DB side we will use the Replication strategies.
Master-Master (or multi-master) Replication
Any server can update the database. It is usually taken care of by a different module within the database.
- The downside is that it is very hard to do well, and some systems lose ACID properties when in this mode of replication.
- The upside is that it is flexible and you can support the failure of any server while still having the database updated.
Master-Slave Replication
There is only a single copy of authoritative data, which is pushed to the slave servers.
- The downside is that it is less fault-tolerant, if the master dies, there are no further changes in the slaves.
Load Balancing can also be done on the database side Like we can redirect the writes to the master and reads to the slaves using load balancing.
Check the links in the reference section to find the detailed information on the topics covered.
